From xen-devel-bounces@lists.xen.org Sat Sep 01 00:43:31 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 01 Sep 2012 00: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 1T7bnj-0001Ms-RL; Sat, 01 Sep 2012 00:43:03 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Santosh.Jodh@citrix.com>) id 1T7bni-0001Mn-0I
	for xen-devel@lists.xen.org; Sat, 01 Sep 2012 00:43:02 +0000
Received: from [85.158.139.83:34915] by server-11.bemta-5.messagelabs.com id
	6B/92-24658-51A51405; Sat, 01 Sep 2012 00:43:01 +0000
X-Env-Sender: Santosh.Jodh@citrix.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1346460179!20768308!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNjc1NTc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20832 invoked from network); 1 Sep 2012 00:43:00 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-11.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Sep 2012 00:43:00 -0000
X-IronPort-AV: E=Sophos;i="4.80,351,1344211200"; d="scan'208";a="36493191"
Received: from sjcpmailmx02.citrite.net ([10.216.14.75])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Sep 2012 00:42:31 +0000
Received: from SJCPMAILBOX01.citrite.net ([10.216.4.72]) by
	SJCPMAILMX02.citrite.net ([10.216.14.75]) with mapi; Fri, 31 Aug 2012
	17:42:29 -0700
From: Santosh Jodh <Santosh.Jodh@citrix.com>
To: Sander Eikelenboom <linux@eikelenboom.it>
Date: Fri, 31 Aug 2012 17:42:06 -0700
Thread-Topic: Using debug-key 'o:  Dump IOMMU p2m table, locks up machine
Thread-Index: Ac2Hzqq+LRXFiknsRxabJDC8y7W61AAALregAAK8FuA=
Message-ID: <7914B38A4445B34AA16EB9F1352942F1012F0F6F4B5B@SJCPMAILBOX01.citrite.net>
References: <647712821.20120831234512@eikelenboom.it>
	<7914B38A4445B34AA16EB9F1352942F1012F0F6F4AE2@SJCPMAILBOX01.citrite.net>
	<723041396.20120901004249@eikelenboom.it>
	<7914B38A4445B34AA16EB9F1352942F1012F0F6F4B01@SJCPMAILBOX01.citrite.net>
	<1377403931.20120901011625@eikelenboom.it> 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Cc: "wei.wang2@amd.com" <wei.wang2@amd.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Using debug-key 'o:  Dump IOMMU p2m table,
	locks up machine
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

BTW, I should add that 1:1 mapping for the VM seems very suspicious. Wei can comment for sure.

> -----Original Message-----
> From: Santosh Jodh
> Sent: Friday, August 31, 2012 4:58 PM
> To: 'Sander Eikelenboom'
> Cc: wei.wang2@amd.com; xen-devel@lists.xen.org
> Subject: RE: Using debug-key 'o: Dump IOMMU p2m table, locks up machine
> 
> 1:1 mapping is not the common case for gfn-mfn. It is hard to say how much
> output would shrink by dumping contiguous ranges instead of individual pfns
> in the general case.
> 
> > -----Original Message-----
> > From: Sander Eikelenboom [mailto:linux@eikelenboom.it]
> > Sent: Friday, August 31, 2012 4:16 PM
> > To: Santosh Jodh
> > Cc: wei.wang2@amd.com; xen-devel@lists.xen.org
> > Subject: Re: Using debug-key 'o: Dump IOMMU p2m table, locks up
> > machine
> >
> >
> > Saturday, September 1, 2012, 12:57:45 AM, you wrote:
> >
> > > The dump should complete - would be curious to see how long it takes
> > > on
> > serial console. What baudrate is the console running at?
> >
> > I think for ages, this part seems only to cover a bit of the first of
> > 3 pv guests which have devices passed through.
> > 38400
> >
> > And i wonder if the information is very valuable, gfn == mfn for every line
> ...
> > at an increment of 1 ...
> > Perhaps a uhmmm more compact way of getting the interesting data
> would
> > be handy ?
> > Or is this the intended output ?
> >
> > > The code does allow processing of pending softirqs quite frequently.
> > > I am
> > not sure why you are still seeing SATA errors.
> >
> > The machine is completely unresponsive in every way.
> >
> > And using it with "xl debug-keys o" is never going to work i guess,
> > since the information flood is far larger than "xl dmesg" keeps ?
> >
> >
> >
> > >> -----Original Message-----
> > >> From: Sander Eikelenboom [mailto:linux@eikelenboom.it]
> > >> Sent: Friday, August 31, 2012 3:43 PM
> > >> To: Santosh Jodh
> > >> Cc: wei.wang2@amd.com; xen-devel@lists.xen.org
> > >> Subject: Re: Using debug-key 'o: Dump IOMMU p2m table, locks up
> > >> machine
> > >>
> > >>
> > >> Saturday, September 1, 2012, 12:24:32 AM, you wrote:
> > >>
> > >> > Depending on how many VMs you have and the size of the IOMMU
> > p2m
> > >> table, it can take a while. It should not be infinite though.
> > >>
> > >> > How many VMs do you have running?
> > >>
> > >> 15
> > >>
> > >> > Can you please send the serial output when you press 'o'?
> > >>
> > >> Attached, to the end you will see the s-ata errors coming through
> > >> while the dump still runs.
> > >> This is not a complete dump, only a few minutes after which i did a
> > >> hard reset.
> > >>
> > >> > Santosh
> > >>
> > >> >> -----Original Message-----
> > >> >> From: Sander Eikelenboom [mailto:linux@eikelenboom.it]
> > >> >> Sent: Friday, August 31, 2012 2:45 PM
> > >> >> To: Santosh Jodh; wei.wang2@amd.com
> > >> >> Cc: xen-devel@lists.xen.org
> > >> >> Subject: Using debug-key 'o: Dump IOMMU p2m table, locks up
> > >> >> machine
> > >> >>
> > >> >>
> > >> >> I was trying to use the 'o' debug key to make a bug report about
> > >> >> an "AMD-
> > >> Vi:
> > >> >> IO_PAGE_FAULT".
> > >> >>
> > >> >> The result:
> > >> >> - When using "xl debug-keys o", the machine seems in a infinite
> > >> >> loop, can hardly login, eventually resulting in a kernel RCU
> > >> >> stall and complete
> > >> lockup.
> > >> >> - When using serial console: I get a infinite stream of "gfn:  mfn: "
> > >> >> lines, mean while on the normal console, S-ATA devices are
> > >> >> starting to
> > >> give errors.
> > >> >>
> > >> >> So either option trashes the machine, other debug-keys work fine.
> > >> >>
> > >> >> Machine has a 890-fx chipset and AMD phenom x6 proc.
> > >> >>
> > >> >> xl dmesg with bootup and output from some other debug-keys is
> > >> attached.
> > >> >>
> > >> >> --
> > >> >>
> > >> >> Sander
> > >>
> > >>
> > >>
> > >>
> > >> --
> > >> Best regards,
> > >>  Sander                            mailto:linux@eikelenboom.it
> >
> >
> >
> >
> > --
> > 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 Sat Sep 01 00:43:31 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 01 Sep 2012 00: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 1T7bnj-0001Ms-RL; Sat, 01 Sep 2012 00:43:03 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Santosh.Jodh@citrix.com>) id 1T7bni-0001Mn-0I
	for xen-devel@lists.xen.org; Sat, 01 Sep 2012 00:43:02 +0000
Received: from [85.158.139.83:34915] by server-11.bemta-5.messagelabs.com id
	6B/92-24658-51A51405; Sat, 01 Sep 2012 00:43:01 +0000
X-Env-Sender: Santosh.Jodh@citrix.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1346460179!20768308!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNjc1NTc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20832 invoked from network); 1 Sep 2012 00:43:00 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-11.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Sep 2012 00:43:00 -0000
X-IronPort-AV: E=Sophos;i="4.80,351,1344211200"; d="scan'208";a="36493191"
Received: from sjcpmailmx02.citrite.net ([10.216.14.75])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Sep 2012 00:42:31 +0000
Received: from SJCPMAILBOX01.citrite.net ([10.216.4.72]) by
	SJCPMAILMX02.citrite.net ([10.216.14.75]) with mapi; Fri, 31 Aug 2012
	17:42:29 -0700
From: Santosh Jodh <Santosh.Jodh@citrix.com>
To: Sander Eikelenboom <linux@eikelenboom.it>
Date: Fri, 31 Aug 2012 17:42:06 -0700
Thread-Topic: Using debug-key 'o:  Dump IOMMU p2m table, locks up machine
Thread-Index: Ac2Hzqq+LRXFiknsRxabJDC8y7W61AAALregAAK8FuA=
Message-ID: <7914B38A4445B34AA16EB9F1352942F1012F0F6F4B5B@SJCPMAILBOX01.citrite.net>
References: <647712821.20120831234512@eikelenboom.it>
	<7914B38A4445B34AA16EB9F1352942F1012F0F6F4AE2@SJCPMAILBOX01.citrite.net>
	<723041396.20120901004249@eikelenboom.it>
	<7914B38A4445B34AA16EB9F1352942F1012F0F6F4B01@SJCPMAILBOX01.citrite.net>
	<1377403931.20120901011625@eikelenboom.it> 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Cc: "wei.wang2@amd.com" <wei.wang2@amd.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Using debug-key 'o:  Dump IOMMU p2m table,
	locks up machine
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

BTW, I should add that 1:1 mapping for the VM seems very suspicious. Wei can comment for sure.

> -----Original Message-----
> From: Santosh Jodh
> Sent: Friday, August 31, 2012 4:58 PM
> To: 'Sander Eikelenboom'
> Cc: wei.wang2@amd.com; xen-devel@lists.xen.org
> Subject: RE: Using debug-key 'o: Dump IOMMU p2m table, locks up machine
> 
> 1:1 mapping is not the common case for gfn-mfn. It is hard to say how much
> output would shrink by dumping contiguous ranges instead of individual pfns
> in the general case.
> 
> > -----Original Message-----
> > From: Sander Eikelenboom [mailto:linux@eikelenboom.it]
> > Sent: Friday, August 31, 2012 4:16 PM
> > To: Santosh Jodh
> > Cc: wei.wang2@amd.com; xen-devel@lists.xen.org
> > Subject: Re: Using debug-key 'o: Dump IOMMU p2m table, locks up
> > machine
> >
> >
> > Saturday, September 1, 2012, 12:57:45 AM, you wrote:
> >
> > > The dump should complete - would be curious to see how long it takes
> > > on
> > serial console. What baudrate is the console running at?
> >
> > I think for ages, this part seems only to cover a bit of the first of
> > 3 pv guests which have devices passed through.
> > 38400
> >
> > And i wonder if the information is very valuable, gfn == mfn for every line
> ...
> > at an increment of 1 ...
> > Perhaps a uhmmm more compact way of getting the interesting data
> would
> > be handy ?
> > Or is this the intended output ?
> >
> > > The code does allow processing of pending softirqs quite frequently.
> > > I am
> > not sure why you are still seeing SATA errors.
> >
> > The machine is completely unresponsive in every way.
> >
> > And using it with "xl debug-keys o" is never going to work i guess,
> > since the information flood is far larger than "xl dmesg" keeps ?
> >
> >
> >
> > >> -----Original Message-----
> > >> From: Sander Eikelenboom [mailto:linux@eikelenboom.it]
> > >> Sent: Friday, August 31, 2012 3:43 PM
> > >> To: Santosh Jodh
> > >> Cc: wei.wang2@amd.com; xen-devel@lists.xen.org
> > >> Subject: Re: Using debug-key 'o: Dump IOMMU p2m table, locks up
> > >> machine
> > >>
> > >>
> > >> Saturday, September 1, 2012, 12:24:32 AM, you wrote:
> > >>
> > >> > Depending on how many VMs you have and the size of the IOMMU
> > p2m
> > >> table, it can take a while. It should not be infinite though.
> > >>
> > >> > How many VMs do you have running?
> > >>
> > >> 15
> > >>
> > >> > Can you please send the serial output when you press 'o'?
> > >>
> > >> Attached, to the end you will see the s-ata errors coming through
> > >> while the dump still runs.
> > >> This is not a complete dump, only a few minutes after which i did a
> > >> hard reset.
> > >>
> > >> > Santosh
> > >>
> > >> >> -----Original Message-----
> > >> >> From: Sander Eikelenboom [mailto:linux@eikelenboom.it]
> > >> >> Sent: Friday, August 31, 2012 2:45 PM
> > >> >> To: Santosh Jodh; wei.wang2@amd.com
> > >> >> Cc: xen-devel@lists.xen.org
> > >> >> Subject: Using debug-key 'o: Dump IOMMU p2m table, locks up
> > >> >> machine
> > >> >>
> > >> >>
> > >> >> I was trying to use the 'o' debug key to make a bug report about
> > >> >> an "AMD-
> > >> Vi:
> > >> >> IO_PAGE_FAULT".
> > >> >>
> > >> >> The result:
> > >> >> - When using "xl debug-keys o", the machine seems in a infinite
> > >> >> loop, can hardly login, eventually resulting in a kernel RCU
> > >> >> stall and complete
> > >> lockup.
> > >> >> - When using serial console: I get a infinite stream of "gfn:  mfn: "
> > >> >> lines, mean while on the normal console, S-ATA devices are
> > >> >> starting to
> > >> give errors.
> > >> >>
> > >> >> So either option trashes the machine, other debug-keys work fine.
> > >> >>
> > >> >> Machine has a 890-fx chipset and AMD phenom x6 proc.
> > >> >>
> > >> >> xl dmesg with bootup and output from some other debug-keys is
> > >> attached.
> > >> >>
> > >> >> --
> > >> >>
> > >> >> Sander
> > >>
> > >>
> > >>
> > >>
> > >> --
> > >> Best regards,
> > >>  Sander                            mailto:linux@eikelenboom.it
> >
> >
> >
> >
> > --
> > 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 Sat Sep 01 02:02:11 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 01 Sep 2012 02:02:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T7d1j-0008RF-PF; Sat, 01 Sep 2012 02:01:35 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1T7d1g-0007q4-Rq
	for xen-devel@lists.xen.org; Sat, 01 Sep 2012 02:01:33 +0000
Received: from [85.158.139.83:21971] by server-11.bemta-5.messagelabs.com id
	95/C4-24658-C7C61405; Sat, 01 Sep 2012 02:01:32 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1346464887!20653542!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-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15837 invoked from network); 1 Sep 2012 02:01:29 -0000
Received: from mail-pz0-f45.google.com (HELO mail-pz0-f45.google.com)
	(209.85.210.45)
	by server-16.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Sep 2012 02:01:29 -0000
Received: by dadn15 with SMTP id n15so2190608dad.32
	for <xen-devel@lists.xen.org>; Fri, 31 Aug 2012 19:01: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=UXb5GfLrw9FZGF5G4fVaAVaTnPRdlVjPi0oSItOxV+g=;
	b=rhmTKZvMnvHaoH3cVkCB+kG6bi+qALxRF7/1gxfZVj5ALo0eZ4gIEQ81+9lCEWowOj
	Q7tBQ2URodIM1LfAPe8wjRZV7iRHCnGivkNP17qdIMX2kcQo/JG6Jqh5CiR53HVE42Ho
	fSYECI9/M00iTlgmVV49e6ChZhEpIJ6c8lx6uUf5nYtTEbsKp8XCl4ujBvLkXrbUM6aQ
	Fu5Ermk0WO8qr1nkyTaUnphoWxw24J6pXMDDAWzeM1urVe7pWrwqMW087txKa7EBYRqu
	emSH9Q/DBzoEb7/NIGADvp5SRGKtBoXt/01XHpx9Ts7p1yYvzb/tDTxlLVvkYmrrXoxI
	2qJw==
Received: by 10.68.218.72 with SMTP id pe8mr21328756pbc.33.1346464887085;
	Fri, 31 Aug 2012 19:01:27 -0700 (PDT)
Received: from [10.20.235.159] ([204.239.250.1])
	by mx.google.com with ESMTPS id wh7sm4602909pbc.33.2012.08.31.19.01.23
	(version=SSLv3 cipher=OTHER); Fri, 31 Aug 2012 19:01:25 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Sat, 01 Sep 2012 03:01:13 +0100
From: Keir Fraser <keir.xen@gmail.com>
To: Sander Eikelenboom <linux@eikelenboom.it>,
	Santosh Jodh <Santosh.Jodh@citrix.com>
Message-ID: <CC672AF9.3D8E2%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] Using debug-key 'o:  Dump IOMMU p2m table, locks up
	machine
Thread-Index: Ac2H5anSA9JOwrAdv0yUGY6DtFwLdQ==
In-Reply-To: <1377403931.20120901011625@eikelenboom.it>
Mime-version: 1.0
Cc: "wei.wang2@amd.com" <wei.wang2@amd.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Using debug-key 'o:  Dump IOMMU p2m table,
 locks up machine
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/09/2012 00:16, "Sander Eikelenboom" <linux@eikelenboom.it> wrote:

> 
> Saturday, September 1, 2012, 12:57:45 AM, you wrote:
> 
>> The dump should complete - would be curious to see how long it takes on
>> serial console. What baudrate is the console running at?
> 
> I think for ages, this part seems only to cover a bit of the first of 3 pv
> guests which have devices passed through.
> 38400
> 
> And i wonder if the information is very valuable, gfn == mfn for every line
> ... at an increment of 1 ...
> Perhaps a uhmmm more compact way of getting the interesting data would be
> handy ?
> Or is this the intended output ?
> 
>> The code does allow processing of pending softirqs quite frequently. I am not
>> sure why you are still seeing SATA errors.
> 
> The machine is completely unresponsive in every way.

It might schedule softirqs but that won't include scheduling or running any
guest vcpus. The vcpu that happens to be running on that cpu at the time the
debug dump starts, will be stuck unrunnable until the dump completes.

Well, anyway, I don't know how useful a massive dump of the entire p2m is
going to be for debugging anyway. If investigating an IOMMU page fault, I'd
just want the info pertaining to that fault, and all the mapping information
for that IO virtual address, dumped. :)

 -- Keir

> And using it with "xl debug-keys o" is never going to work i guess, since the
> information flood is far larger than "xl dmesg" keeps ?
> 
> 
> 
>>> -----Original Message-----
>>> From: Sander Eikelenboom [mailto:linux@eikelenboom.it]
>>> Sent: Friday, August 31, 2012 3:43 PM
>>> To: Santosh Jodh
>>> Cc: wei.wang2@amd.com; xen-devel@lists.xen.org
>>> Subject: Re: Using debug-key 'o: Dump IOMMU p2m table, locks up machine
>>> 
>>> 
>>> Saturday, September 1, 2012, 12:24:32 AM, you wrote:
>>> 
>>>> Depending on how many VMs you have and the size of the IOMMU p2m
>>> table, it can take a while. It should not be infinite though.
>>> 
>>>> How many VMs do you have running?
>>> 
>>> 15
>>> 
>>>> Can you please send the serial output when you press 'o'?
>>> 
>>> Attached, to the end you will see the s-ata errors coming through while the
>>> dump still runs.
>>> This is not a complete dump, only a few minutes after which i did a hard
>>> reset.
>>> 
>>>> Santosh
>>> 
>>>>> -----Original Message-----
>>>>> From: Sander Eikelenboom [mailto:linux@eikelenboom.it]
>>>>> Sent: Friday, August 31, 2012 2:45 PM
>>>>> To: Santosh Jodh; wei.wang2@amd.com
>>>>> Cc: xen-devel@lists.xen.org
>>>>> Subject: Using debug-key 'o: Dump IOMMU p2m table, locks up machine
>>>>> 
>>>>> 
>>>>> I was trying to use the 'o' debug key to make a bug report about an "AMD-
>>> Vi:
>>>>> IO_PAGE_FAULT".
>>>>> 
>>>>> The result:
>>>>> - When using "xl debug-keys o", the machine seems in a infinite loop,
>>>>> can hardly login, eventually resulting in a kernel RCU stall and complete
>>> lockup.
>>>>> - When using serial console: I get a infinite stream of "gfn:  mfn: "
>>>>> lines, mean while on the normal console, S-ATA devices are starting to
>>> give errors.
>>>>> 
>>>>> So either option trashes the machine, other debug-keys work fine.
>>>>> 
>>>>> Machine has a 890-fx chipset and AMD phenom x6 proc.
>>>>> 
>>>>> xl dmesg with bootup and output from some other debug-keys is
>>> attached.
>>>>> 
>>>>> --
>>>>> 
>>>>> Sander
>>> 
>>> 
>>> 
>>> 
>>> --
>>> 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 Sat Sep 01 02:02:11 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 01 Sep 2012 02:02:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T7d1j-0008RF-PF; Sat, 01 Sep 2012 02:01:35 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1T7d1g-0007q4-Rq
	for xen-devel@lists.xen.org; Sat, 01 Sep 2012 02:01:33 +0000
Received: from [85.158.139.83:21971] by server-11.bemta-5.messagelabs.com id
	95/C4-24658-C7C61405; Sat, 01 Sep 2012 02:01:32 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1346464887!20653542!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-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15837 invoked from network); 1 Sep 2012 02:01:29 -0000
Received: from mail-pz0-f45.google.com (HELO mail-pz0-f45.google.com)
	(209.85.210.45)
	by server-16.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Sep 2012 02:01:29 -0000
Received: by dadn15 with SMTP id n15so2190608dad.32
	for <xen-devel@lists.xen.org>; Fri, 31 Aug 2012 19:01: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=UXb5GfLrw9FZGF5G4fVaAVaTnPRdlVjPi0oSItOxV+g=;
	b=rhmTKZvMnvHaoH3cVkCB+kG6bi+qALxRF7/1gxfZVj5ALo0eZ4gIEQ81+9lCEWowOj
	Q7tBQ2URodIM1LfAPe8wjRZV7iRHCnGivkNP17qdIMX2kcQo/JG6Jqh5CiR53HVE42Ho
	fSYECI9/M00iTlgmVV49e6ChZhEpIJ6c8lx6uUf5nYtTEbsKp8XCl4ujBvLkXrbUM6aQ
	Fu5Ermk0WO8qr1nkyTaUnphoWxw24J6pXMDDAWzeM1urVe7pWrwqMW087txKa7EBYRqu
	emSH9Q/DBzoEb7/NIGADvp5SRGKtBoXt/01XHpx9Ts7p1yYvzb/tDTxlLVvkYmrrXoxI
	2qJw==
Received: by 10.68.218.72 with SMTP id pe8mr21328756pbc.33.1346464887085;
	Fri, 31 Aug 2012 19:01:27 -0700 (PDT)
Received: from [10.20.235.159] ([204.239.250.1])
	by mx.google.com with ESMTPS id wh7sm4602909pbc.33.2012.08.31.19.01.23
	(version=SSLv3 cipher=OTHER); Fri, 31 Aug 2012 19:01:25 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Sat, 01 Sep 2012 03:01:13 +0100
From: Keir Fraser <keir.xen@gmail.com>
To: Sander Eikelenboom <linux@eikelenboom.it>,
	Santosh Jodh <Santosh.Jodh@citrix.com>
Message-ID: <CC672AF9.3D8E2%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] Using debug-key 'o:  Dump IOMMU p2m table, locks up
	machine
Thread-Index: Ac2H5anSA9JOwrAdv0yUGY6DtFwLdQ==
In-Reply-To: <1377403931.20120901011625@eikelenboom.it>
Mime-version: 1.0
Cc: "wei.wang2@amd.com" <wei.wang2@amd.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Using debug-key 'o:  Dump IOMMU p2m table,
 locks up machine
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/09/2012 00:16, "Sander Eikelenboom" <linux@eikelenboom.it> wrote:

> 
> Saturday, September 1, 2012, 12:57:45 AM, you wrote:
> 
>> The dump should complete - would be curious to see how long it takes on
>> serial console. What baudrate is the console running at?
> 
> I think for ages, this part seems only to cover a bit of the first of 3 pv
> guests which have devices passed through.
> 38400
> 
> And i wonder if the information is very valuable, gfn == mfn for every line
> ... at an increment of 1 ...
> Perhaps a uhmmm more compact way of getting the interesting data would be
> handy ?
> Or is this the intended output ?
> 
>> The code does allow processing of pending softirqs quite frequently. I am not
>> sure why you are still seeing SATA errors.
> 
> The machine is completely unresponsive in every way.

It might schedule softirqs but that won't include scheduling or running any
guest vcpus. The vcpu that happens to be running on that cpu at the time the
debug dump starts, will be stuck unrunnable until the dump completes.

Well, anyway, I don't know how useful a massive dump of the entire p2m is
going to be for debugging anyway. If investigating an IOMMU page fault, I'd
just want the info pertaining to that fault, and all the mapping information
for that IO virtual address, dumped. :)

 -- Keir

> And using it with "xl debug-keys o" is never going to work i guess, since the
> information flood is far larger than "xl dmesg" keeps ?
> 
> 
> 
>>> -----Original Message-----
>>> From: Sander Eikelenboom [mailto:linux@eikelenboom.it]
>>> Sent: Friday, August 31, 2012 3:43 PM
>>> To: Santosh Jodh
>>> Cc: wei.wang2@amd.com; xen-devel@lists.xen.org
>>> Subject: Re: Using debug-key 'o: Dump IOMMU p2m table, locks up machine
>>> 
>>> 
>>> Saturday, September 1, 2012, 12:24:32 AM, you wrote:
>>> 
>>>> Depending on how many VMs you have and the size of the IOMMU p2m
>>> table, it can take a while. It should not be infinite though.
>>> 
>>>> How many VMs do you have running?
>>> 
>>> 15
>>> 
>>>> Can you please send the serial output when you press 'o'?
>>> 
>>> Attached, to the end you will see the s-ata errors coming through while the
>>> dump still runs.
>>> This is not a complete dump, only a few minutes after which i did a hard
>>> reset.
>>> 
>>>> Santosh
>>> 
>>>>> -----Original Message-----
>>>>> From: Sander Eikelenboom [mailto:linux@eikelenboom.it]
>>>>> Sent: Friday, August 31, 2012 2:45 PM
>>>>> To: Santosh Jodh; wei.wang2@amd.com
>>>>> Cc: xen-devel@lists.xen.org
>>>>> Subject: Using debug-key 'o: Dump IOMMU p2m table, locks up machine
>>>>> 
>>>>> 
>>>>> I was trying to use the 'o' debug key to make a bug report about an "AMD-
>>> Vi:
>>>>> IO_PAGE_FAULT".
>>>>> 
>>>>> The result:
>>>>> - When using "xl debug-keys o", the machine seems in a infinite loop,
>>>>> can hardly login, eventually resulting in a kernel RCU stall and complete
>>> lockup.
>>>>> - When using serial console: I get a infinite stream of "gfn:  mfn: "
>>>>> lines, mean while on the normal console, S-ATA devices are starting to
>>> give errors.
>>>>> 
>>>>> So either option trashes the machine, other debug-keys work fine.
>>>>> 
>>>>> Machine has a 890-fx chipset and AMD phenom x6 proc.
>>>>> 
>>>>> xl dmesg with bootup and output from some other debug-keys is
>>> attached.
>>>>> 
>>>>> --
>>>>> 
>>>>> Sander
>>> 
>>> 
>>> 
>>> 
>>> --
>>> 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 Sat Sep 01 05:21:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 01 Sep 2012 05: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 1T7g8N-000613-7g; Sat, 01 Sep 2012 05:20:39 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <linux@eikelenboom.it>) id 1T7Zvy-0008FL-HL
	for xen-devel@lists.xen.org; Fri, 31 Aug 2012 22:43:28 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-14.tower-27.messagelabs.com!1346452977!2165777!1
X-Originating-IP: [188.40.164.121]
X-SpamReason: No, hits=3.0 required=7.0 tests=ML_RADAR_551,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13596 invoked from network); 31 Aug 2012 22:42:58 -0000
Received: from static.121.164.40.188.clients.your-server.de (HELO
	smtp.eikelenboom.it) (188.40.164.121)
	by server-14.tower-27.messagelabs.com with AES256-SHA encrypted SMTP;
	31 Aug 2012 22:42:58 -0000
Received: from 26-69-ftth.onsneteindhoven.nl ([88.159.69.26]:50972
	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 1T7ZsN-0000Fk-St; Sat, 01 Sep 2012 00:39:45 +0200
Date: Sat, 1 Sep 2012 00:42:49 +0200
From: Sander Eikelenboom <linux@eikelenboom.it>
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <723041396.20120901004249@eikelenboom.it>
To: Santosh Jodh <Santosh.Jodh@citrix.com>
In-Reply-To: <7914B38A4445B34AA16EB9F1352942F1012F0F6F4AE2@SJCPMAILBOX01.citrite.net>
References: <647712821.20120831234512@eikelenboom.it>
	<7914B38A4445B34AA16EB9F1352942F1012F0F6F4AE2@SJCPMAILBOX01.citrite.net>
MIME-Version: 1.0
Content-Type: multipart/mixed;
 boundary="----------03F05B075321531C3"
X-Mailman-Approved-At: Sat, 01 Sep 2012 05:20:38 +0000
Cc: "wei.wang2@amd.com" <wei.wang2@amd.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Using debug-key 'o:  Dump IOMMU p2m table,
	locks up machine
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

------------03F05B075321531C3
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit


Saturday, September 1, 2012, 12:24:32 AM, you wrote:

> Depending on how many VMs you have and the size of the IOMMU p2m table, it can take a while. It should not be infinite though. 

> How many VMs do you have running?

15

> Can you please send the serial output when you press 'o'?

Attached, to the end you will see the s-ata errors coming through while the dump still runs.
This is not a complete dump, only a few minutes after which i did a hard reset.

> Santosh

>> -----Original Message-----
>> From: Sander Eikelenboom [mailto:linux@eikelenboom.it]
>> Sent: Friday, August 31, 2012 2:45 PM
>> To: Santosh Jodh; wei.wang2@amd.com
>> Cc: xen-devel@lists.xen.org
>> Subject: Using debug-key 'o: Dump IOMMU p2m table, locks up machine
>> 
>> 
>> I was trying to use the 'o' debug key to make a bug report about an "AMD-Vi:
>> IO_PAGE_FAULT".
>> 
>> The result:
>> - When using "xl debug-keys o", the machine seems in a infinite loop, can
>> hardly login, eventually resulting in a kernel RCU stall and complete lockup.
>> - When using serial console: I get a infinite stream of "gfn:  mfn: " lines, mean
>> while on the normal console, S-ATA devices are starting to give errors.
>> 
>> So either option trashes the machine, other debug-keys work fine.
>> 
>> Machine has a 890-fx chipset and AMD phenom x6 proc.
>> 
>> xl dmesg with bootup and output from some other debug-keys is attached.
>> 
>> --
>> 
>> Sander




-- 
Best regards,
 Sander                            mailto:linux@eikelenboom.it
------------03F05B075321531C3
Content-Type: text/plain;
 name="output-debug-keys-o.txt"
Content-transfer-encoding: base64
Content-Disposition: attachment;
 filename="output-debug-keys-o.txt"

DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMxOjU0XSAqKiogU2VyaWFsIGlucHV0IC0+IFhl
biAodHlwZSAnQ1RSTC1hJyB0aHJlZSB0aW1lcyB0byBzd2l0Y2ggaW5wdXQgdG8gRE9NMCkN
Cg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzE6NTZdIA0KDQooWEVOKSBbMjAxMi0wOC0zMSAy
MTozMTo1Nl0gZG9tYWluMSBJT01NVSBwMm0gdGFibGU6IA0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMTo1Nl0gcDJtIHRhYmxlIGhhcyAzIGxldmVscw0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMTo1Nl0gDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMxOjU2XSBkb21haW4yIElP
TU1VIHAybSB0YWJsZTogDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMxOjU2XSBwMm0gdGFi
bGUgaGFzIDMgbGV2ZWxzDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMxOjU2XSANCg0KKFhF
TikgWzIwMTItMDgtMzEgMjE6MzE6NTZdIGRvbWFpbjMgSU9NTVUgcDJtIHRhYmxlOiANCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzE6NTZdIHAybSB0YWJsZSBoYXMgMyBsZXZlbHMNCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzE6NTZdIA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
MTo1Nl0gZG9tYWluNCBJT01NVSBwMm0gdGFibGU6IA0KDQooWEVOKSBbMjAxMi0wOC0zMSAy
MTozMTo1Nl0gcDJtIHRhYmxlIGhhcyAzIGxldmVscw0KDQooWEVOKSBbMjAxMi0wOC0zMSAy
MTozMTo1Nl0gDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMxOjU2XSBkb21haW41IElPTU1V
IHAybSB0YWJsZTogDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMxOjU2XSBwMm0gdGFibGUg
aGFzIDMgbGV2ZWxzDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMxOjU2XSANCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzE6NTZdIGRvbWFpbjYgSU9NTVUgcDJtIHRhYmxlOiANCg0KKFhF
TikgWzIwMTItMDgtMzEgMjE6MzE6NTZdIHAybSB0YWJsZSBoYXMgMyBsZXZlbHMNCg0KKFhF
TikgWzIwMTItMDgtMzEgMjE6MzE6NTZdIA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMTo1
Nl0gZG9tYWluNyBJT01NVSBwMm0gdGFibGU6IA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
MTo1Nl0gcDJtIHRhYmxlIGhhcyAzIGxldmVscw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
MTo1Nl0gDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMxOjU2XSBkb21haW44IElPTU1VIHAy
bSB0YWJsZTogDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMxOjU2XSBwMm0gdGFibGUgaGFz
IDMgbGV2ZWxzDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMxOjU2XSANCg0KKFhFTikgWzIw
MTItMDgtMzEgMjE6MzE6NTZdIGRvbWFpbjkgSU9NTVUgcDJtIHRhYmxlOiANCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzE6NTZdIHAybSB0YWJsZSBoYXMgMyBsZXZlbHMNCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzE6NTZdIA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMTo1Nl0g
ZG9tYWluMTAgSU9NTVUgcDJtIHRhYmxlOiANCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzE6
NTZdIHAybSB0YWJsZSBoYXMgMyBsZXZlbHMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzE6
NTZdIA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMTo1Nl0gZG9tYWluMTEgSU9NTVUgcDJt
IHRhYmxlOiANCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzE6NTZdIHAybSB0YWJsZSBoYXMg
MyBsZXZlbHMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzE6NTZdICAgZ2ZuOiAwMDAwNDAw
MCAgbWZuOiAwMDAwNDAwMA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMTo1Nl0gICBnZm46
IDAwMDA0MDAxICBtZm46IDAwMDA0MDAxDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMxOjU2
XSAgIGdmbjogMDAwMDQwMDIgIG1mbjogMDAwMDQwMDINCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzE6NTZdICAgZ2ZuOiAwMDAwNDAwMyAgbWZuOiAwMDAwNDAwMw0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMTo1Nl0gICBnZm46IDAwMDA0MDA0ICBtZm46IDAwMDA0MDA0DQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMxOjU2XSAgIGdmbjogMDAwMDQwMDUgIG1mbjogMDAwMDQw
MDUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzE6NTZdICAgZ2ZuOiAwMDAwNDAwNiAgbWZu
OiAwMDAwNDAwNg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMTo1Nl0gICBnZm46IDAwMDA0
MDA3ICBtZm46IDAwMDA0MDA3DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMxOjU2XSAgIGdm
bjogMDAwMDQwMDggIG1mbjogMDAwMDQwMDgNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzE6
NTZdICAgZ2ZuOiAwMDAwNDAwOSAgbWZuOiAwMDAwNDAwOQ0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMTo1Nl0gICBnZm46IDAwMDA0MDBhICBtZm46IDAwMDA0MDBhDQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMxOjU2XSAgIGdmbjogMDAwMDQwMGIgIG1mbjogMDAwMDQwMGINCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzE6NTZdICAgZ2ZuOiAwMDAwNDAwYyAgbWZuOiAwMDAw
NDAwYw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMTo1Nl0gICBnZm46IDAwMDA0MDBkICBt
Zm46IDAwMDA0MDBkDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMxOjU2XSAgIGdmbjogMDAw
MDQwMGUgIG1mbjogMDAwMDQwMGUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzE6NTZdICAg
Z2ZuOiAwMDAwNDAwZiAgbWZuOiAwMDAwNDAwZg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
MTo1Nl0gICBnZm46IDAwMDA0MDEwICBtZm46IDAwMDA0MDEwDQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMxOjU2XSAgIGdmbjogMDAwMDQwMTEgIG1mbjogMDAwMDQwMTENCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzE6NTZdICAgZ2ZuOiAwMDAwNDAxMiAgbWZuOiAwMDAwNDAxMg0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMTo1Nl0gICBnZm46IDAwMDA0MDEzICBtZm46IDAw
MDA0MDEzDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMxOjU2XSAgIGdmbjogMDAwMDQwMTQg
IG1mbjogMDAwMDQwMTQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzE6NTZdICAgZ2ZuOiAw
MDAwNDAxNSAgbWZuOiAwMDAwNDAxNQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMTo1Nl0g
ICBnZm46IDAwMDA0MDE2ICBtZm46IDAwMDA0MDE2DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMxOjU2XSAgIGdmbjogMDAwMDQwMTcgIG1mbjogMDAwMDQwMTcNCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzE6NTZdICAgZ2ZuOiAwMDAwNDAxOCAgbWZuOiAwMDAwNDAxOA0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMTo1Nl0gICBnZm46IDAwMDA0MDE5ICBtZm46IDAwMDA0MDE5
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMxOjU2XSAgIGdmbjogMDAwMDQwMWEgIG1mbjog
MDAwMDQwMWENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzE6NTZdICAgZ2ZuOiAwMDAwNDAx
YiAgbWZuOiAwMDAwNDAxYg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMTo1Nl0gICBnZm46
IDAwMDA0MDFjICBtZm46IDAwMDA0MDFjDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMxOjU2
XSAgIGdmbjogMDAwMDQwMWQgIG1mbjogMDAwMDQwMWQNCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzE6NTZdICAgZ2ZuOiAwMDAwNDAxZSAgbWZuOiAwMDAwNDAxZQ0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMTo1Nl0gICBnZm46IDAwMDA0MDFmICBtZm46IDAwMDA0MDFmDQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMxOjU2XSAgIGdmbjogMDAwMDQwMjAgIG1mbjogMDAwMDQw
MjANCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzE6NTZdICAgZ2ZuOiAwMDAwNDAyMSAgbWZu
OiAwMDAwNDAyMQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMTo1Nl0gICBnZm46IDAwMDA0
MDIyICBtZm46IDAwMDA0MDIyDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMxOjU2XSAgIGdm
bjogMDAwMDQwMjMgIG1mbjogMDAwMDQwMjMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzE6
NTZdICAgZ2ZuOiAwMDAwNDAyNCAgbWZuOiAwMDAwNDAyNA0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMTo1Nl0gICBnZm46IDAwMDA0MDI1ICBtZm46IDAwMDA0MDI1DQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMxOjU2XSAgIGdmbjogMDAwMDQwMjYgIG1mbjogMDAwMDQwMjYNCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzE6NTZdICAgZ2ZuOiAwMDAwNDAyNyAgbWZuOiAwMDAw
NDAyNw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMTo1Nl0gICBnZm46IDAwMDA0MDI4ICBt
Zm46IDAwMDA0MDI4DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMxOjU2XSAgIGdmbjogMDAw
MDQwMjkgIG1mbjogMDAwMDQwMjkNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzE6NTZdICAg
Z2ZuOiAwMDAwNDAyYSAgbWZuOiAwMDAwNDAyYQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
MTo1Nl0gICBnZm46IDAwMDA0MDJiICBtZm46IDAwMDA0MDJiDQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMxOjU2XSAgIGdmbjogMDAwMDQwMmMgIG1mbjogMDAwMDQwMmMNCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzE6NTZdICAgZ2ZuOiAwMDAwNDAyZCAgbWZuOiAwMDAwNDAyZA0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMTo1Nl0gICBnZm46IDAwMDA0MDJlICBtZm46IDAw
MDA0MDJlDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMxOjU2XSAgIGdmbjogMDAwMDQwMmYg
IG1mbjogMDAwMDQwMmYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzE6NTZdICAgZ2ZuOiAw
MDAwNDAzMCAgbWZuOiAwMDAwNDAzMA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMTo1Nl0g
ICBnZm46IDAwMDA0MDMxICBtZm46IDAwMDA0MDMxDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMxOjU2XSAgIGdmbjogMDAwMDQwMzIgIG1mbjogMDAwMDQwMzINCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzE6NTZdICAgZ2ZuOiAwMDAwNDAzMyAgbWZuOiAwMDAwNDAzMw0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMTo1Nl0gICBnZm46IDAwMDA0MDM0ICBtZm46IDAwMDA0MDM0
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMxOjU2XSAgIGdmbjogMDAwMDQwMzUgIG1mbjog
MDAwMDQwMzUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzE6NTZdICAgZ2ZuOiAwMDAwNDAz
NiAgbWZuOiAwMDAwNDAzNg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMTo1Nl0gICBnZm46
IDAwMDA0MDM3ICBtZm46IDAwMDA0MDM3DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMxOjU2
XSAgIGdmbjogMDAwMDQwMzggIG1mbjogMDAwMDQwMzgNCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzE6NTZdICAgZ2ZuOiAwMDAwNDAzOSAgbWZuOiAwMDAwNDAzOQ0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMTo1Nl0gICBnZm46IDAwMDA0MDNhICBtZm46IDAwMDA0MDNhDQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMxOjU2XSAgIGdmbjogMDAwMDQwM2IgIG1mbjogMDAwMDQw
M2INCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzE6NTZdICAgZ2ZuOiAwMDAwNDAzYyAgbWZu
OiAwMDAwNDAzYw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMTo1Nl0gICBnZm46IDAwMDA0
MDNkICBtZm46IDAwMDA0MDNkDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMxOjU2XSAgIGdm
bjogMDAwMDQwM2UgIG1mbjogMDAwMDQwM2UNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzE6
NTZdICAgZ2ZuOiAwMDAwNDAzZiAgbWZuOiAwMDAwNDAzZg0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMTo1Nl0gICBnZm46IDAwMDA0MDQwICBtZm46IDAwMDA0MDQwDQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMxOjU2XSAgIGdmbjogMDAwMDQwNDEgIG1mbjogMDAwMDQwNDENCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzE6NTZdICAgZ2ZuOiAwMDAwNDA0MiAgbWZuOiAwMDAw
NDA0Mg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMTo1Nl0gICBnZm46IDAwMDA0MDQzICBt
Zm46IDAwMDA0MDQzDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMxOjU2XSAgIGdmbjogMDAw
MDQwNDQgIG1mbjogMDAwMDQwNDQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzE6NTZdICAg
Z2ZuOiAwMDAwNDA0NSAgbWZuOiAwMDAwNDA0NQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
MTo1Nl0gICBnZm46IDAwMDA0MDQ2ICBtZm46IDAwMDA0MDQ2DQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMxOjU2XSAgIGdmbjogMDAwMDQwNDcgIG1mbjogMDAwMDQwNDcNCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzE6NTZdICAgZ2ZuOiAwMDAwNDA0OCAgbWZuOiAwMDAwNDA0OA0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMTo1Nl0gICBnZm46IDAwMDA0MDQ5ICBtZm46IDAw
MDA0MDQ5DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMxOjU2XSAgIGdmbjogMDAwMDQwNGEg
IG1mbjogMDAwMDQwNGENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzE6NTZdICAgZ2ZuOiAw
MDAwNDA0YiAgbWZuOiAwMDAwNDA0Yg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMTo1Nl0g
ICBnZm46IDAwMDA0MDRjICBtZm46IDAwMDA0MDRjDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMxOjU2XSAgIGdmbjogMDAwMDQwNGQgIG1mbjogMDAwMDQwNGQNCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzE6NTZdICAgZ2ZuOiAwMDAwNDA0ZSAgbWZuOiAwMDAwNDA0ZQ0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMTo1Nl0gICBnZm46IDAwMDA0MDRmICBtZm46IDAwMDA0MDRm
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMxOjU2XSAgIGdmbjogMDAwMDQwNTAgIG1mbjog
MDAwMDQwNTANCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzE6NTZdICAgZ2ZuOiAwMDAwNDA1
MSAgbWZuOiAwMDAwNDA1MQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMTo1Nl0gICBnZm46
IDAwMDA0MDUyICBtZm46IDAwMDA0MDUyDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMxOjU2
XSAgIGdmbjogMDAwMDQwNTMgIG1mbjogMDAwMDQwNTMNCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzE6NTZdICAgZ2ZuOiAwMDAwNDA1NCAgbWZuOiAwMDAwNDA1NA0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMTo1Nl0gICBnZm46IDAwMDA0MDU1ICBtZm46IDAwMDA0MDU1DQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMxOjU2XSAgIGdmbjogMDAwMDQwNTYgIG1mbjogMDAwMDQw
NTYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzE6NTZdICAgZ2ZuOiAwMDAwNDA1NyAgbWZu
OiAwMDAwNDA1Nw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMTo1Nl0gICBnZm46IDAwMDA0
MDU4ICBtZm46IDAwMDA0MDU4DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMxOjU2XSAgIGdm
bjogMDAwMDQwNTkgIG1mbjogMDAwMDQwNTkNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzE6
NTZdICAgZ2ZuOiAwMDAwNDA1YSAgbWZuOiAwMDAwNDA1YQ0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMTo1Nl0gICBnZm46IDAwMDA0MDViICBtZm46IDAwMDA0MDViDQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMxOjU2XSAgIGdmbjogMDAwMDQwNWMgIG1mbjogMDAwMDQwNWMNCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzE6NTZdICAgZ2ZuOiAwMDAwNDA1ZCAgbWZuOiAwMDAw
NDA1ZA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMTo1Nl0gICBnZm46IDAwMDA0MDVlICBt
Zm46IDAwMDA0MDVlDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMxOjU2XSAgIGdmbjogMDAw
MDQwNWYgIG1mbjogMDAwMDQwNWYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzE6NTZdICAg
Z2ZuOiAwMDAwNDA2MCAgbWZuOiAwMDAwNDA2MA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
MTo1Nl0gICBnZm46IDAwMDA0MDYxICBtZm46IDAwMDA0MDYxDQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMxOjU2XSAgIGdmbjogMDAwMDQwNjIgIG1mbjogMDAwMDQwNjINCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzE6NTZdICAgZ2ZuOiAwMDAwNDA2MyAgbWZuOiAwMDAwNDA2Mw0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMTo1Nl0gICBnZm46IDAwMDA0MDY0ICBtZm46IDAw
MDA0MDY0DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMxOjU2XSAgIGdmbjogMDAwMDQwNjUg
IG1mbjogMDAwMDQwNjUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzE6NTZdICAgZ2ZuOiAw
MDAwNDA2NiAgbWZuOiAwMDAwNDA2Ng0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMTo1Nl0g
ICBnZm46IDAwMDA0MDY3ICBtZm46IDAwMDA0MDY3DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMxOjU2XSAgIGdmbjogMDAwMDQwNjggIG1mbjogMDAwMDQwNjgNCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzE6NTZdICAgZ2ZuOiAwMDAwNDA2OSAgbWZuOiAwMDAwNDA2OQ0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMTo1Nl0gICBnZm46IDAwMDA0MDZhICBtZm46IDAwMDA0MDZh
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMxOjU2XSAgIGdmbjogMDAwMDQwNmIgIG1mbjog
MDAwMDQwNmINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzE6NTZdICAgZ2ZuOiAwMDAwNDA2
YyAgbWZuOiAwMDAwNDA2Yw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMTo1Nl0gICBnZm46
IDAwMDA0MDZkICBtZm46IDAwMDA0MDZkDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMxOjU2
XSAgIGdmbjogMDAwMDQwNmUgIG1mbjogMDAwMDQwNmUNCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzE6NTZdICAgZ2ZuOiAwMDAwNDA2ZiAgbWZuOiAwMDAwNDA2Zg0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMTo1Nl0gICBnZm46IDAwMDA0MDcwICBtZm46IDAwMDA0MDcwDQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMxOjU2XSAgIGdmbjogMDAwMDQwNzEgIG1mbjogMDAwMDQw
NzENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzE6NTZdICAgZ2ZuOiAwMDAwNDA3MiAgbWZu
OiAwMDAwNDA3Mg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMTo1Nl0gICBnZm46IDAwMDA0
MDczICBtZm46IDAwMDA0MDczDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMxOjU2XSAgIGdm
bjogMDAwMDQwNzQgIG1mbjogMDAwMDQwNzQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzE6
NTZdICAgZ2ZuOiAwMDAwNDA3NSAgbWZuOiAwMDAwNDA3NQ0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMTo1Nl0gICBnZm46IDAwMDA0MDc2ICBtZm46IDAwMDA0MDc2DQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMxOjU2XSAgIGdmbjogMDAwMDQwNzcgIG1mbjogMDAwMDQwNzcNCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzE6NTZdICAgZ2ZuOiAwMDAwNDA3OCAgbWZuOiAwMDAw
NDA3OA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMTo1Nl0gICBnZm46IDAwMDA0MDc5ICBt
Zm46IDAwMDA0MDc5DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMxOjU2XSAgIGdmbjogMDAw
MDQwN2EgIG1mbjogMDAwMDQwN2ENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzE6NTZdICAg
Z2ZuOiAwMDAwNDA3YiAgbWZuOiAwMDAwNDA3Yg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
MTo1Nl0gICBnZm46IDAwMDA0MDdjICBtZm46IDAwMDA0MDdjDQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMxOjU2XSAgIGdmbjogMDAwMDQwN2QgIG1mbjogMDAwMDQwN2QNCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzE6NTZdICAgZ2ZuOiAwMDAwNDA3ZSAgbWZuOiAwMDAwNDA3ZQ0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMTo1Nl0gICBnZm46IDAwMDA0MDdmICBtZm46IDAw
MDA0MDdmDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMxOjU2XSAgIGdmbjogMDAwMDQwODAg
IG1mbjogMDAwMDQwODANCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzE6NTZdICAgZ2ZuOiAw
MDAwNDA4MSAgbWZuOiAwMDAwNDA4MQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMTo1Nl0g
ICBnZm46IDAwMDA0MDgyICBtZm46IDAwMDA0MDgyDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMxOjU2XSAgIGdmbjogMDAwMDQwODMgIG1mbjogMDAwMDQwODMNCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzE6NTZdICAgZ2ZuOiAwMDAwNDA4NCAgbWZuOiAwMDAwNDA4NA0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMTo1Nl0gICBnZm46IDAwMDA0MDg1ICBtZm46IDAwMDA0MDg1
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMxOjU2XSAgIGdmbjogMDAwMDQwODYgIG1mbjog
MDAwMDQwODYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzE6NTZdICAgZ2ZuOiAwMDAwNDA4
NyAgbWZuOiAwMDAwNDA4Nw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMTo1Nl0gICBnZm46
IDAwMDA0MDg4ICBtZm46IDAwMDA0MDg4DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMxOjU2
XSAgIGdmbjogMDAwMDQwODkgIG1mbjogMDAwMDQwODkNCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzE6NTZdICAgZ2ZuOiAwMDAwNDA4YSAgbWZuOiAwMDAwNDA4YQ0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMTo1Nl0gICBnZm46IDAwMDA0MDhiICBtZm46IDAwMDA0MDhiDQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMxOjU2XSAgIGdmbjogMDAwMDQwOGMgIG1mbjogMDAwMDQw
OGMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzE6NTZdICAgZ2ZuOiAwMDAwNDA4ZCAgbWZu
OiAwMDAwNDA4ZA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMTo1Nl0gICBnZm46IDAwMDA0
MDhlICBtZm46IDAwMDA0MDhlDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMxOjU2XSAgIGdm
bjogMDAwMDQwOGYgIG1mbjogMDAwMDQwOGYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzE6
NTZdICAgZ2ZuOiAwMDAwNDA5MCAgbWZuOiAwMDAwNDA5MA0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMTo1Nl0gICBnZm46IDAwMDA0MDkxICBtZm46IDAwMDA0MDkxDQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMxOjU2XSAgIGdmbjogMDAwMDQwOTIgIG1mbjogMDAwMDQwOTINCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzE6NTZdICAgZ2ZuOiAwMDAwNDA5MyAgbWZuOiAwMDAw
NDA5Mw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMTo1Nl0gICBnZm46IDAwMDA0MDk0ICBt
Zm46IDAwMDA0MDk0DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMxOjU2XSAgIGdmbjogMDAw
MDQwOTUgIG1mbjogMDAwMDQwOTUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzE6NTZdICAg
Z2ZuOiAwMDAwNDA5NiAgbWZuOiAwMDAwNDA5Ng0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
MTo1Nl0gICBnZm46IDAwMDA0MDk3ICBtZm46IDAwMDA0MDk3DQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMxOjU2XSAgIGdmbjogMDAwMDQwOTggIG1mbjogMDAwMDQwOTgNCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzE6NTZdICAgZ2ZuOiAwMDAwNDA5OSAgbWZuOiAwMDAwNDA5OQ0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMTo1Nl0gICBnZm46IDAwMDA0MDlhICBtZm46IDAw
MDA0MDlhDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMxOjU2XSAgIGdmbjogMDAwMDQwOWIg
IG1mbjogMDAwMDQwOWINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzE6NTZdICAgZ2ZuOiAw
MDAwNDA5YyAgbWZuOiAwMDAwNDA5Yw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMTo1Nl0g
ICBnZm46IDAwMDA0MDlkICBtZm46IDAwMDA0MDlkDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMxOjU2XSAgIGdmbjogMDAwMDQwOWUgIG1mbjogMDAwMDQwOWUNCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzE6NTZdICAgZ2ZuOiAwMDAwNDA5ZiAgbWZuOiAwMDAwNDA5Zg0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMTo1Nl0gICBnZm46IDAwMDA0MGEwICBtZm46IDAwMDA0MGEw
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMxOjU2XSAgIGdmbjogMDAwMDQwYTEgIG1mbjog
MDAwMDQwYTENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzE6NTZdICAgZ2ZuOiAwMDAwNDBh
MiAgbWZuOiAwMDAwNDBhMg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMTo1Nl0gICBnZm46
IDAwMDA0MGEzICBtZm46IDAwMDA0MGEzDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMxOjU2
XSAgIGdmbjogMDAwMDQwYTQgIG1mbjogMDAwMDQwYTQNCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzE6NTZdICAgZ2ZuOiAwMDAwNDBhNSAgbWZuOiAwMDAwNDBhNQ0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMTo1Nl0gICBnZm46IDAwMDA0MGE2ICBtZm46IDAwMDA0MGE2DQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMxOjU2XSAgIGdmbjogMDAwMDQwYTcgIG1mbjogMDAwMDQw
YTcNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzE6NTZdICAgZ2ZuOiAwMDAwNDBhOCAgbWZu
OiAwMDAwNDBhOA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMTo1Nl0gICBnZm46IDAwMDA0
MGE5ICBtZm46IDAwMDA0MGE5DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMxOjU2XSAgIGdm
bjogMDAwMDQwYWEgIG1mbjogMDAwMDQwYWENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzE6
NTZdICAgZ2ZuOiAwMDAwNDBhYiAgbWZuOiAwMDAwNDBhYg0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMTo1Nl0gICBnZm46IDAwMDA0MGFjICBtZm46IDAwMDA0MGFjDQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMxOjU2XSAgIGdmbjogMDAwMDQwYWQgIG1mbjogMDAwMDQwYWQNCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzE6NTZdICAgZ2ZuOiAwMDAwNDBhZSAgbWZuOiAwMDAw
NDBhZQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMTo1Nl0gICBnZm46IDAwMDA0MGFmICBt
Zm46IDAwMDA0MGFmDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMxOjU2XSAgIGdmbjogMDAw
MDQwYjAgIG1mbjogMDAwMDQwYjANCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzE6NTZdICAg
Z2ZuOiAwMDAwNDBiMSAgbWZuOiAwMDAwNDBiMQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
MTo1Nl0gICBnZm46IDAwMDA0MGIyICBtZm46IDAwMDA0MGIyDQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMxOjU2XSAgIGdmbjogMDAwMDQwYjMgIG1mbjogMDAwMDQwYjMNCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzE6NTZdICAgZ2ZuOiAwMDAwNDBiNCAgbWZuOiAwMDAwNDBiNA0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMTo1Nl0gICBnZm46IDAwMDA0MGI1ICBtZm46IDAw
MDA0MGI1DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMxOjU2XSAgIGdmbjogMDAwMDQwYjYg
IG1mbjogMDAwMDQwYjYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzE6NTZdICAgZ2ZuOiAw
MDAwNDBiNyAgbWZuOiAwMDAwNDBiNw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMTo1Nl0g
ICBnZm46IDAwMDA0MGI4ICBtZm46IDAwMDA0MGI4DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMxOjU2XSAgIGdmbjogMDAwMDQwYjkgIG1mbjogMDAwMDQwYjkNCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzE6NTZdICAgZ2ZuOiAwMDAwNDBiYSAgbWZuOiAwMDAwNDBiYQ0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMTo1Nl0gICBnZm46IDAwMDA0MGJiICBtZm46IDAwMDA0MGJi
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMxOjU2XSAgIGdmbjogMDAwMDQwYmMgIG1mbjog
MDAwMDQwYmMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzE6NTZdICAgZ2ZuOiAwMDAwNDBi
ZCAgbWZuOiAwMDAwNDBiZA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMTo1Nl0gICBnZm46
IDAwMDA0MGJlICBtZm46IDAwMDA0MGJlDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMxOjU2
XSAgIGdmbjogMDAwMDQwYmYgIG1mbjogMDAwMDQwYmYNCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzE6NTZdICAgZ2ZuOiAwMDAwNDBjMCAgbWZuOiAwMDAwNDBjMA0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMTo1Nl0gICBnZm46IDAwMDA0MGMxICBtZm46IDAwMDA0MGMxDQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMxOjU2XSAgIGdmbjogMDAwMDQwYzIgIG1mbjogMDAwMDQw
YzINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzE6NTZdICAgZ2ZuOiAwMDAwNDBjMyAgbWZu
OiAwMDAwNDBjMw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMTo1Nl0gICBnZm46IDAwMDA0
MGM0ICBtZm46IDAwMDA0MGM0DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMxOjU2XSAgIGdm
bjogMDAwMDQwYzUgIG1mbjogMDAwMDQwYzUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzE6
NTZdICAgZ2ZuOiAwMDAwNDBjNiAgbWZuOiAwMDAwNDBjNg0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMTo1Nl0gICBnZm46IDAwMDA0MGM3ICBtZm46IDAwMDA0MGM3DQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMxOjU2XSAgIGdmbjogMDAwMDQwYzggIG1mbjogMDAwMDQwYzgNCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzE6NTZdICAgZ2ZuOiAwMDAwNDBjOSAgbWZuOiAwMDAw
NDBjOQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMTo1Nl0gICBnZm46IDAwMDA0MGNhICBt
Zm46IDAwMDA0MGNhDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMxOjU2XSAgIGdmbjogMDAw
MDQwY2IgIG1mbjogMDAwMDQwY2INCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzE6NTZdICAg
Z2ZuOiAwMDAwNDBjYyAgbWZuOiAwMDAwNDBjYw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
MTo1Nl0gICBnZm46IDAwMDA0MGNkICBtZm46IDAwMDA0MGNkDQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMxOjU2XSAgIGdmbjogMDAwMDQwY2UgIG1mbjogMDAwMDQwY2UNCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzE6NTZdICAgZ2ZuOiAwMDAwNDBjZiAgbWZuOiAwMDAwNDBjZg0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMTo1Nl0gICBnZm46IDAwMDA0MGQwICBtZm46IDAw
MDA0MGQwDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMxOjU2XSAgIGdmbjogMDAwMDQwZDEg
IG1mbjogMDAwMDQwZDENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzE6NTZdICAgZ2ZuOiAw
MDAwNDBkMiAgbWZuOiAwMDAwNDBkMg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMTo1Nl0g
ICBnZm46IDAwMDA0MGQzICBtZm46IDAwMDA0MGQzDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMxOjU2XSAgIGdmbjogMDAwMDQwZDQgIG1mbjogMDAwMDQwZDQNCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzE6NTZdICAgZ2ZuOiAwMDAwNDBkNSAgbWZuOiAwMDAwNDBkNQ0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMTo1Nl0gICBnZm46IDAwMDA0MGQ2ICBtZm46IDAwMDA0MGQ2
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMxOjU2XSAgIGdmbjogMDAwMDQwZDcgIG1mbjog
MDAwMDQwZDcNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzE6NTZdICAgZ2ZuOiAwMDAwNDBk
OCAgbWZuOiAwMDAwNDBkOA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMTo1Nl0gICBnZm46
IDAwMDA0MGQ5ICBtZm46IDAwMDA0MGQ5DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMxOjU2
XSAgIGdmbjogMDAwMDQwZGEgIG1mbjogMDAwMDQwZGENCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzE6NTZdICAgZ2ZuOiAwMDAwNDBkYiAgbWZuOiAwMDAwNDBkYg0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMTo1Nl0gICBnZm46IDAwMDA0MGRjICBtZm46IDAwMDA0MGRjDQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMxOjU2XSAgIGdmbjogMDAwMDQwZGQgIG1mbjogMDAwMDQw
ZGQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzE6NTZdICAgZ2ZuOiAwMDAwNDBkZSAgbWZu
OiAwMDAwNDBkZQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMTo1Nl0gICBnZm46IDAwMDA0
MGRmICBtZm46IDAwMDA0MGRmDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMxOjU2XSAgIGdm
bjogMDAwMDQwZTAgIG1mbjogMDAwMDQwZTANCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzE6
NTZdICAgZ2ZuOiAwMDAwNDBlMSAgbWZuOiAwMDAwNDBlMQ0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMTo1Nl0gICBnZm46IDAwMDA0MGUyICBtZm46IDAwMDA0MGUyDQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMxOjU2XSAgIGdmbjogMDAwMDQwZTMgIG1mbjogMDAwMDQwZTMNCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzE6NTZdICAgZ2ZuOiAwMDAwNDBlNCAgbWZuOiAwMDAw
NDBlNA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMTo1Nl0gICBnZm46IDAwMDA0MGU1ICBt
Zm46IDAwMDA0MGU1DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMxOjU2XSAgIGdmbjogMDAw
MDQwZTYgIG1mbjogMDAwMDQwZTYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzE6NTZdICAg
Z2ZuOiAwMDAwNDBlNyAgbWZuOiAwMDAwNDBlNw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
MTo1Nl0gICBnZm46IDAwMDA0MGU4ICBtZm46IDAwMDA0MGU4DQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMxOjU2XSAgIGdmbjogMDAwMDQwZTkgIG1mbjogMDAwMDQwZTkNCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzE6NTZdICAgZ2ZuOiAwMDAwNDBlYSAgbWZuOiAwMDAwNDBlYQ0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMTo1Nl0gICBnZm46IDAwMDA0MGViICBtZm46IDAw
MDA0MGViDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMxOjU2XSAgIGdmbjogMDAwMDQwZWMg
IG1mbjogMDAwMDQwZWMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzE6NTZdICAgZ2ZuOiAw
MDAwNDBlZCAgbWZuOiAwMDAwNDBlZA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMTo1Nl0g
ICBnZm46IDAwMDA0MGVlICBtZm46IDAwMDA0MGVlDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMxOjU2XSAgIGdmbjogMDAwMDQwZWYgIG1mbjogMDAwMDQwZWYNCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzE6NTZdICAgZ2ZuOiAwMDAwNDBmMCAgbWZuOiAwMDAwNDBmMA0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMTo1Nl0gICBnZm46IDAwMDA0MGYxICBtZm46IDAwMDA0MGYx
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMxOjU2XSAgIGdmbjogMDAwMDQwZjIgIG1mbjog
MDAwMDQwZjINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzE6NTZdICAgZ2ZuOiAwMDAwNDBm
MyAgbWZuOiAwMDAwNDBmMw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMTo1Nl0gICBnZm46
IDAwMDA0MGY0ICBtZm46IDAwMDA0MGY0DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMxOjU2
XSAgIGdmbjogMDAwMDQwZjUgIG1mbjogMDAwMDQwZjUNCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzE6NTZdICAgZ2ZuOiAwMDAwNDBmNiAgbWZuOiAwMDAwNDBmNg0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMTo1Nl0gICBnZm46IDAwMDA0MGY3ICBtZm46IDAwMDA0MGY3DQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMxOjU2XSAgIGdmbjogMDAwMDQwZjggIG1mbjogMDAwMDQw
ZjgNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzE6NTZdICAgZ2ZuOiAwMDAwNDBmOSAgbWZu
OiAwMDAwNDBmOQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMTo1N10gICBnZm46IDAwMDA0
MGZhICBtZm46IDAwMDA0MGZhDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMxOjU3XSAgIGdm
bjogMDAwMDQwZmIgIG1mbjogMDAwMDQwZmINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzE6
NTddICAgZ2ZuOiAwMDAwNDBmYyAgbWZuOiAwMDAwNDBmYw0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMTo1N10gICBnZm46IDAwMDA0MGZkICBtZm46IDAwMDA0MGZkDQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMxOjU3XSAgIGdmbjogMDAwMDQwZmUgIG1mbjogMDAwMDQwZmUNCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzE6NTddICAgZ2ZuOiAwMDAwNDBmZiAgbWZuOiAwMDAw
NDBmZg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMTo1N10gICBnZm46IDAwMDA0MTAwICBt
Zm46IDAwMDA0MTAwDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMxOjU3XSAgIGdmbjogMDAw
MDQxMDEgIG1mbjogMDAwMDQxMDENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzE6NTddICAg
Z2ZuOiAwMDAwNDEwMiAgbWZuOiAwMDAwNDEwMg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
MTo1N10gICBnZm46IDAwMDA0MTAzICBtZm46IDAwMDA0MTAzDQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMxOjU3XSAgIGdmbjogMDAwMDQxMDQgIG1mbjogMDAwMDQxMDQNCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzE6NTddICAgZ2ZuOiAwMDAwNDEwNSAgbWZuOiAwMDAwNDEwNQ0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMTo1N10gICBnZm46IDAwMDA0MTA2ICBtZm46IDAw
MDA0MTA2DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMxOjU3XSAgIGdmbjogMDAwMDQxMDcg
IG1mbjogMDAwMDQxMDcNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzE6NTddICAgZ2ZuOiAw
MDAwNDEwOCAgbWZuOiAwMDAwNDEwOA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMTo1N10g
ICBnZm46IDAwMDA0MTA5ICBtZm46IDAwMDA0MTA5DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMxOjU3XSAgIGdmbjogMDAwMDQxMGEgIG1mbjogMDAwMDQxMGENCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzE6NTddICAgZ2ZuOiAwMDAwNDEwYiAgbWZuOiAwMDAwNDEwYg0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMTo1N10gICBnZm46IDAwMDA0MTBjICBtZm46IDAwMDA0MTBj
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMxOjU3XSAgIGdmbjogMDAwMDQxMGQgIG1mbjog
MDAwMDQxMGQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzE6NTddICAgZ2ZuOiAwMDAwNDEw
ZSAgbWZuOiAwMDAwNDEwZQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMTo1N10gICBnZm46
IDAwMDA0MTBmICBtZm46IDAwMDA0MTBmDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMxOjU3
XSAgIGdmbjogMDAwMDQxMTAgIG1mbjogMDAwMDQxMTANCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzE6NTddICAgZ2ZuOiAwMDAwNDExMSAgbWZuOiAwMDAwNDExMQ0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMTo1N10gICBnZm46IDAwMDA0MTEyICBtZm46IDAwMDA0MTEyDQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMxOjU3XSAgIGdmbjogMDAwMDQxMTMgIG1mbjogMDAwMDQx
MTMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzE6NTddICAgZ2ZuOiAwMDAwNDExNCAgbWZu
OiAwMDAwNDExNA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMTo1N10gICBnZm46IDAwMDA0
MTE1ICBtZm46IDAwMDA0MTE1DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMxOjU3XSAgIGdm
bjogMDAwMDQxMTYgIG1mbjogMDAwMDQxMTYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzE6
NTddICAgZ2ZuOiAwMDAwNDExNyAgbWZuOiAwMDAwNDExNw0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMTo1N10gICBnZm46IDAwMDA0MTE4ICBtZm46IDAwMDA0MTE4DQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMxOjU3XSAgIGdmbjogMDAwMDQxMTkgIG1mbjogMDAwMDQxMTkNCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzE6NTddICAgZ2ZuOiAwMDAwNDExYSAgbWZuOiAwMDAw
NDExYQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMTo1N10gICBnZm46IDAwMDA0MTFiICBt
Zm46IDAwMDA0MTFiDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMxOjU3XSAgIGdmbjogMDAw
MDQxMWMgIG1mbjogMDAwMDQxMWMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzE6NTddICAg
Z2ZuOiAwMDAwNDExZCAgbWZuOiAwMDAwNDExZA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
MTo1N10gICBnZm46IDAwMDA0MTFlICBtZm46IDAwMDA0MTFlDQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMxOjU3XSAgIGdmbjogMDAwMDQxMWYgIG1mbjogMDAwMDQxMWYNCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzE6NTddICAgZ2ZuOiAwMDAwNDEyMCAgbWZuOiAwMDAwNDEyMA0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMTo1N10gICBnZm46IDAwMDA0MTIxICBtZm46IDAw
MDA0MTIxDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMxOjU3XSAgIGdmbjogMDAwMDQxMjIg
IG1mbjogMDAwMDQxMjINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzE6NTddICAgZ2ZuOiAw
MDAwNDEyMyAgbWZuOiAwMDAwNDEyMw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMTo1N10g
ICBnZm46IDAwMDA0MTI0ICBtZm46IDAwMDA0MTI0DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMxOjU3XSAgIGdmbjogMDAwMDQxMjUgIG1mbjogMDAwMDQxMjUNCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzE6NTddICAgZ2ZuOiAwMDAwNDEyNiAgbWZuOiAwMDAwNDEyNg0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMTo1N10gICBnZm46IDAwMDA0MTI3ICBtZm46IDAwMDA0MTI3
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMxOjU3XSAgIGdmbjogMDAwMDQxMjggIG1mbjog
MDAwMDQxMjgNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzE6NTddICAgZ2ZuOiAwMDAwNDEy
OSAgbWZuOiAwMDAwNDEyOQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMTo1N10gICBnZm46
IDAwMDA0MTJhICBtZm46IDAwMDA0MTJhDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMxOjU3
XSAgIGdmbjogMDAwMDQxMmIgIG1mbjogMDAwMDQxMmINCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzE6NTddICAgZ2ZuOiAwMDAwNDEyYyAgbWZuOiAwMDAwNDEyYw0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMTo1N10gICBnZm46IDAwMDA0MTJkICBtZm46IDAwMDA0MTJkDQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMxOjU3XSAgIGdmbjogMDAwMDQxMmUgIG1mbjogMDAwMDQx
MmUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzE6NTddICAgZ2ZuOiAwMDAwNDEyZiAgbWZu
OiAwMDAwNDEyZg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMTo1N10gICBnZm46IDAwMDA0
MTMwICBtZm46IDAwMDA0MTMwDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMxOjU3XSAgIGdm
bjogMDAwMDQxMzEgIG1mbjogMDAwMDQxMzENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzE6
NTddICAgZ2ZuOiAwMDAwNDEzMiAgbWZuOiAwMDAwNDEzMg0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMTo1N10gICBnZm46IDAwMDA0MTMzICBtZm46IDAwMDA0MTMzDQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMxOjU3XSAgIGdmbjogMDAwMDQxMzQgIG1mbjogMDAwMDQxMzQNCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzE6NTddICAgZ2ZuOiAwMDAwNDEzNSAgbWZuOiAwMDAw
NDEzNQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMTo1N10gICBnZm46IDAwMDA0MTM2ICBt
Zm46IDAwMDA0MTM2DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMxOjU3XSAgIGdmbjogMDAw
MDQxMzcgIG1mbjogMDAwMDQxMzcNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzE6NTddICAg
Z2ZuOiAwMDAwNDEzOCAgbWZuOiAwMDAwNDEzOA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
MTo1N10gICBnZm46IDAwMDA0MTM5ICBtZm46IDAwMDA0MTM5DQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMxOjU4XSAgIGdmbjogMDAwMDQxM2EgIG1mbjogMDAwMDQxM2ENCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzE6NThdICAgZ2ZuOiAwMDAwNDEzYiAgbWZuOiAwMDAwNDEzYg0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMTo1OF0gICBnZm46IDAwMDA0MTNjICBtZm46IDAw
MDA0MTNjDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMxOjU4XSAgIGdmbjogMDAwMDQxM2Qg
IG1mbjogMDAwMDQxM2QNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzE6NThdICAgZ2ZuOiAw
MDAwNDEzZSAgbWZuOiAwMDAwNDEzZQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMTo1OF0g
ICBnZm46IDAwMDA0MTNmICBtZm46IDAwMDA0MTNmDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMxOjU4XSAgIGdmbjogMDAwMDQxNDAgIG1mbjogMDAwMDQxNDANCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzE6NThdICAgZ2ZuOiAwMDAwNDE0MSAgbWZuOiAwMDAwNDE0MQ0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMTo1OF0gICBnZm46IDAwMDA0MTQyICBtZm46IDAwMDA0MTQy
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMxOjU4XSAgIGdmbjogMDAwMDQxNDMgIG1mbjog
MDAwMDQxNDMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzE6NThdICAgZ2ZuOiAwMDAwNDE0
NCAgbWZuOiAwMDAwNDE0NA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMTo1OF0gICBnZm46
IDAwMDA0MTQ1ICBtZm46IDAwMDA0MTQ1DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMxOjU4
XSAgIGdmbjogMDAwMDQxNDYgIG1mbjogMDAwMDQxNDYNCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzE6NThdICAgZ2ZuOiAwMDAwNDE0NyAgbWZuOiAwMDAwNDE0Nw0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMTo1OF0gICBnZm46IDAwMDA0MTQ4ICBtZm46IDAwMDA0MTQ4DQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMxOjU4XSAgIGdmbjogMDAwMDQxNDkgIG1mbjogMDAwMDQx
NDkNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzE6NThdICAgZ2ZuOiAwMDAwNDE0YSAgbWZu
OiAwMDAwNDE0YQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMTo1OF0gICBnZm46IDAwMDA0
MTRiICBtZm46IDAwMDA0MTRiDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMxOjU4XSAgIGdm
bjogMDAwMDQxNGMgIG1mbjogMDAwMDQxNGMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzE6
NThdICAgZ2ZuOiAwMDAwNDE0ZCAgbWZuOiAwMDAwNDE0ZA0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMTo1OF0gICBnZm46IDAwMDA0MTRlICBtZm46IDAwMDA0MTRlDQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMxOjU4XSAgIGdmbjogMDAwMDQxNGYgIG1mbjogMDAwMDQxNGYNCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzE6NThdICAgZ2ZuOiAwMDAwNDE1MCAgbWZuOiAwMDAw
NDE1MA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMTo1OF0gICBnZm46IDAwMDA0MTUxICBt
Zm46IDAwMDA0MTUxDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMxOjU4XSAgIGdmbjogMDAw
MDQxNTIgIG1mbjogMDAwMDQxNTINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzE6NThdICAg
Z2ZuOiAwMDAwNDE1MyAgbWZuOiAwMDAwNDE1Mw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
MTo1OF0gICBnZm46IDAwMDA0MTU0ICBtZm46IDAwMDA0MTU0DQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMxOjU4XSAgIGdmbjogMDAwMDQxNTUgIG1mbjogMDAwMDQxNTUNCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzE6NThdICAgZ2ZuOiAwMDAwNDE1NiAgbWZuOiAwMDAwNDE1Ng0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMTo1OF0gICBnZm46IDAwMDA0MTU3ICBtZm46IDAw
MDA0MTU3DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMxOjU4XSAgIGdmbjogMDAwMDQxNTgg
IG1mbjogMDAwMDQxNTgNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzE6NThdICAgZ2ZuOiAw
MDAwNDE1OSAgbWZuOiAwMDAwNDE1OQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMTo1OF0g
ICBnZm46IDAwMDA0MTVhICBtZm46IDAwMDA0MTVhDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMxOjU4XSAgIGdmbjogMDAwMDQxNWIgIG1mbjogMDAwMDQxNWINCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzE6NThdICAgZ2ZuOiAwMDAwNDE1YyAgbWZuOiAwMDAwNDE1Yw0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMTo1OF0gICBnZm46IDAwMDA0MTVkICBtZm46IDAwMDA0MTVk
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMxOjU4XSAgIGdmbjogMDAwMDQxNWUgIG1mbjog
MDAwMDQxNWUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzE6NThdICAgZ2ZuOiAwMDAwNDE1
ZiAgbWZuOiAwMDAwNDE1Zg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMTo1OF0gICBnZm46
IDAwMDA0MTYwICBtZm46IDAwMDA0MTYwDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMxOjU4
XSAgIGdmbjogMDAwMDQxNjEgIG1mbjogMDAwMDQxNjENCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzE6NThdICAgZ2ZuOiAwMDAwNDE2MiAgbWZuOiAwMDAwNDE2Mg0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMTo1OF0gICBnZm46IDAwMDA0MTYzICBtZm46IDAwMDA0MTYzDQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMxOjU4XSAgIGdmbjogMDAwMDQxNjQgIG1mbjogMDAwMDQx
NjQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzE6NThdICAgZ2ZuOiAwMDAwNDE2NSAgbWZu
OiAwMDAwNDE2NQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMTo1OF0gICBnZm46IDAwMDA0
MTY2ICBtZm46IDAwMDA0MTY2DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMxOjU4XSAgIGdm
bjogMDAwMDQxNjcgIG1mbjogMDAwMDQxNjcNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzE6
NThdICAgZ2ZuOiAwMDAwNDE2OCAgbWZuOiAwMDAwNDE2OA0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMTo1OF0gICBnZm46IDAwMDA0MTY5ICBtZm46IDAwMDA0MTY5DQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMxOjU4XSAgIGdmbjogMDAwMDQxNmEgIG1mbjogMDAwMDQxNmENCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzE6NThdICAgZ2ZuOiAwMDAwNDE2YiAgbWZuOiAwMDAw
NDE2Yg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMTo1OF0gICBnZm46IDAwMDA0MTZjICBt
Zm46IDAwMDA0MTZjDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMxOjU4XSAgIGdmbjogMDAw
MDQxNmQgIG1mbjogMDAwMDQxNmQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzE6NThdICAg
Z2ZuOiAwMDAwNDE2ZSAgbWZuOiAwMDAwNDE2ZQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
MTo1OF0gICBnZm46IDAwMDA0MTZmICBtZm46IDAwMDA0MTZmDQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMxOjU4XSAgIGdmbjogMDAwMDQxNzAgIG1mbjogMDAwMDQxNzANCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzE6NThdICAgZ2ZuOiAwMDAwNDE3MSAgbWZuOiAwMDAwNDE3MQ0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMTo1OF0gICBnZm46IDAwMDA0MTcyICBtZm46IDAw
MDA0MTcyDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMxOjU4XSAgIGdmbjogMDAwMDQxNzMg
IG1mbjogMDAwMDQxNzMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzE6NThdICAgZ2ZuOiAw
MDAwNDE3NCAgbWZuOiAwMDAwNDE3NA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMTo1OF0g
ICBnZm46IDAwMDA0MTc1ICBtZm46IDAwMDA0MTc1DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMxOjU4XSAgIGdmbjogMDAwMDQxNzYgIG1mbjogMDAwMDQxNzYNCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzE6NThdICAgZ2ZuOiAwMDAwNDE3NyAgbWZuOiAwMDAwNDE3Nw0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMTo1OF0gICBnZm46IDAwMDA0MTc4ICBtZm46IDAwMDA0MTc4
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMxOjU4XSAgIGdmbjogMDAwMDQxNzkgIG1mbjog
MDAwMDQxNzkNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzE6NTldICAgZ2ZuOiAwMDAwNDE3
YSAgbWZuOiAwMDAwNDE3YQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMTo1OV0gICBnZm46
IDAwMDA0MTdiICBtZm46IDAwMDA0MTdiDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMxOjU5
XSAgIGdmbjogMDAwMDQxN2MgIG1mbjogMDAwMDQxN2MNCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzE6NTldICAgZ2ZuOiAwMDAwNDE3ZCAgbWZuOiAwMDAwNDE3ZA0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMTo1OV0gICBnZm46IDAwMDA0MTdlICBtZm46IDAwMDA0MTdlDQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMxOjU5XSAgIGdmbjogMDAwMDQxN2YgIG1mbjogMDAwMDQx
N2YNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzE6NTldICAgZ2ZuOiAwMDAwNDE4MCAgbWZu
OiAwMDAwNDE4MA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMTo1OV0gICBnZm46IDAwMDA0
MTgxICBtZm46IDAwMDA0MTgxDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMxOjU5XSAgIGdm
bjogMDAwMDQxODIgIG1mbjogMDAwMDQxODINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzE6
NTldICAgZ2ZuOiAwMDAwNDE4MyAgbWZuOiAwMDAwNDE4Mw0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMTo1OV0gICBnZm46IDAwMDA0MTg0ICBtZm46IDAwMDA0MTg0DQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMxOjU5XSAgIGdmbjogMDAwMDQxODUgIG1mbjogMDAwMDQxODUNCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzE6NTldICAgZ2ZuOiAwMDAwNDE4NiAgbWZuOiAwMDAw
NDE4Ng0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMTo1OV0gICBnZm46IDAwMDA0MTg3ICBt
Zm46IDAwMDA0MTg3DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMxOjU5XSAgIGdmbjogMDAw
MDQxODggIG1mbjogMDAwMDQxODgNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzE6NTldICAg
Z2ZuOiAwMDAwNDE4OSAgbWZuOiAwMDAwNDE4OQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
MTo1OV0gICBnZm46IDAwMDA0MThhICBtZm46IDAwMDA0MThhDQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMxOjU5XSAgIGdmbjogMDAwMDQxOGIgIG1mbjogMDAwMDQxOGINCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzE6NTldICAgZ2ZuOiAwMDAwNDE4YyAgbWZuOiAwMDAwNDE4Yw0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMTo1OV0gICBnZm46IDAwMDA0MThkICBtZm46IDAw
MDA0MThkDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMxOjU5XSAgIGdmbjogMDAwMDQxOGUg
IG1mbjogMDAwMDQxOGUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzE6NTldICAgZ2ZuOiAw
MDAwNDE4ZiAgbWZuOiAwMDAwNDE4Zg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMTo1OV0g
ICBnZm46IDAwMDA0MTkwICBtZm46IDAwMDA0MTkwDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMxOjU5XSAgIGdmbjogMDAwMDQxOTEgIG1mbjogMDAwMDQxOTENCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzE6NTldICAgZ2ZuOiAwMDAwNDE5MiAgbWZuOiAwMDAwNDE5Mg0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMTo1OV0gICBnZm46IDAwMDA0MTkzICBtZm46IDAwMDA0MTkz
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMxOjU5XSAgIGdmbjogMDAwMDQxOTQgIG1mbjog
MDAwMDQxOTQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzE6NTldICAgZ2ZuOiAwMDAwNDE5
NSAgbWZuOiAwMDAwNDE5NQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMTo1OV0gICBnZm46
IDAwMDA0MTk2ICBtZm46IDAwMDA0MTk2DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMxOjU5
XSAgIGdmbjogMDAwMDQxOTcgIG1mbjogMDAwMDQxOTcNCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzE6NTldICAgZ2ZuOiAwMDAwNDE5OCAgbWZuOiAwMDAwNDE5OA0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMTo1OV0gICBnZm46IDAwMDA0MTk5ICBtZm46IDAwMDA0MTk5DQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMxOjU5XSAgIGdmbjogMDAwMDQxOWEgIG1mbjogMDAwMDQx
OWENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzE6NTldICAgZ2ZuOiAwMDAwNDE5YiAgbWZu
OiAwMDAwNDE5Yg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMTo1OV0gICBnZm46IDAwMDA0
MTljICBtZm46IDAwMDA0MTljDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMxOjU5XSAgIGdm
bjogMDAwMDQxOWQgIG1mbjogMDAwMDQxOWQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzE6
NTldICAgZ2ZuOiAwMDAwNDE5ZSAgbWZuOiAwMDAwNDE5ZQ0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMTo1OV0gICBnZm46IDAwMDA0MTlmICBtZm46IDAwMDA0MTlmDQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMxOjU5XSAgIGdmbjogMDAwMDQxYTAgIG1mbjogMDAwMDQxYTANCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzE6NTldICAgZ2ZuOiAwMDAwNDFhMSAgbWZuOiAwMDAw
NDFhMQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMTo1OV0gICBnZm46IDAwMDA0MWEyICBt
Zm46IDAwMDA0MWEyDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMxOjU5XSAgIGdmbjogMDAw
MDQxYTMgIG1mbjogMDAwMDQxYTMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzE6NTldICAg
Z2ZuOiAwMDAwNDFhNCAgbWZuOiAwMDAwNDFhNA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
MTo1OV0gICBnZm46IDAwMDA0MWE1ICBtZm46IDAwMDA0MWE1DQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMxOjU5XSAgIGdmbjogMDAwMDQxYTYgIG1mbjogMDAwMDQxYTYNCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzE6NTldICAgZ2ZuOiAwMDAwNDFhNyAgbWZuOiAwMDAwNDFhNw0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMTo1OV0gICBnZm46IDAwMDA0MWE4ICBtZm46IDAw
MDA0MWE4DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMxOjU5XSAgIGdmbjogMDAwMDQxYTkg
IG1mbjogMDAwMDQxYTkNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzE6NTldICAgZ2ZuOiAw
MDAwNDFhYSAgbWZuOiAwMDAwNDFhYQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMTo1OV0g
ICBnZm46IDAwMDA0MWFiICBtZm46IDAwMDA0MWFiDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMxOjU5XSAgIGdmbjogMDAwMDQxYWMgIG1mbjogMDAwMDQxYWMNCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzE6NTldICAgZ2ZuOiAwMDAwNDFhZCAgbWZuOiAwMDAwNDFhZA0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMTo1OV0gICBnZm46IDAwMDA0MWFlICBtZm46IDAwMDA0MWFl
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMxOjU5XSAgIGdmbjogMDAwMDQxYWYgIG1mbjog
MDAwMDQxYWYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzE6NTldICAgZ2ZuOiAwMDAwNDFi
MCAgbWZuOiAwMDAwNDFiMA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMTo1OV0gICBnZm46
IDAwMDA0MWIxICBtZm46IDAwMDA0MWIxDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMxOjU5
XSAgIGdmbjogMDAwMDQxYjIgIG1mbjogMDAwMDQxYjINCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzE6NTldICAgZ2ZuOiAwMDAwNDFiMyAgbWZuOiAwMDAwNDFiMw0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMTo1OV0gICBnZm46IDAwMDA0MWI0ICBtZm46IDAwMDA0MWI0DQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMxOjU5XSAgIGdmbjogMDAwMDQxYjUgIG1mbjogMDAwMDQx
YjUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzE6NTldICAgZ2ZuOiAwMDAwNDFiNiAgbWZu
OiAwMDAwNDFiNg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMTo1OV0gICBnZm46IDAwMDA0
MWI3ICBtZm46IDAwMDA0MWI3DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMxOjU5XSAgIGdm
bjogMDAwMDQxYjggIG1mbjogMDAwMDQxYjgNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzE6
NTldICAgZ2ZuOiAwMDAwNDFiOSAgbWZuOiAwMDAwNDFiOQ0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMjowMF0gICBnZm46IDAwMDA0MWJhICBtZm46IDAwMDA0MWJhDQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMyOjAwXSAgIGdmbjogMDAwMDQxYmIgIG1mbjogMDAwMDQxYmINCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MDBdICAgZ2ZuOiAwMDAwNDFiYyAgbWZuOiAwMDAw
NDFiYw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjowMF0gICBnZm46IDAwMDA0MWJkICBt
Zm46IDAwMDA0MWJkDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjAwXSAgIGdmbjogMDAw
MDQxYmUgIG1mbjogMDAwMDQxYmUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MDBdICAg
Z2ZuOiAwMDAwNDFiZiAgbWZuOiAwMDAwNDFiZg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
MjowMF0gICBnZm46IDAwMDA0MWMwICBtZm46IDAwMDA0MWMwDQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMyOjAwXSAgIGdmbjogMDAwMDQxYzEgIG1mbjogMDAwMDQxYzENCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzI6MDBdICAgZ2ZuOiAwMDAwNDFjMiAgbWZuOiAwMDAwNDFjMg0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjowMF0gICBnZm46IDAwMDA0MWMzICBtZm46IDAw
MDA0MWMzDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjAwXSAgIGdmbjogMDAwMDQxYzQg
IG1mbjogMDAwMDQxYzQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MDBdICAgZ2ZuOiAw
MDAwNDFjNSAgbWZuOiAwMDAwNDFjNQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjowMF0g
ICBnZm46IDAwMDA0MWM2ICBtZm46IDAwMDA0MWM2DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMyOjAwXSAgIGdmbjogMDAwMDQxYzcgIG1mbjogMDAwMDQxYzcNCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzI6MDBdICAgZ2ZuOiAwMDAwNDFjOCAgbWZuOiAwMDAwNDFjOA0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMjowMF0gICBnZm46IDAwMDA0MWM5ICBtZm46IDAwMDA0MWM5
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjAwXSAgIGdmbjogMDAwMDQxY2EgIG1mbjog
MDAwMDQxY2ENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MDBdICAgZ2ZuOiAwMDAwNDFj
YiAgbWZuOiAwMDAwNDFjYg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjowMF0gICBnZm46
IDAwMDA0MWNjICBtZm46IDAwMDA0MWNjDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjAw
XSAgIGdmbjogMDAwMDQxY2QgIG1mbjogMDAwMDQxY2QNCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzI6MDBdICAgZ2ZuOiAwMDAwNDFjZSAgbWZuOiAwMDAwNDFjZQ0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMjowMF0gICBnZm46IDAwMDA0MWNmICBtZm46IDAwMDA0MWNmDQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMyOjAwXSAgIGdmbjogMDAwMDQxZDAgIG1mbjogMDAwMDQx
ZDANCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MDBdICAgZ2ZuOiAwMDAwNDFkMSAgbWZu
OiAwMDAwNDFkMQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjowMF0gICBnZm46IDAwMDA0
MWQyICBtZm46IDAwMDA0MWQyDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjAwXSAgIGdm
bjogMDAwMDQxZDMgIG1mbjogMDAwMDQxZDMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6
MDBdICAgZ2ZuOiAwMDAwNDFkNCAgbWZuOiAwMDAwNDFkNA0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMjowMF0gICBnZm46IDAwMDA0MWQ1ICBtZm46IDAwMDA0MWQ1DQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMyOjAwXSAgIGdmbjogMDAwMDQxZDYgIG1mbjogMDAwMDQxZDYNCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MDBdICAgZ2ZuOiAwMDAwNDFkNyAgbWZuOiAwMDAw
NDFkNw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjowMF0gICBnZm46IDAwMDA0MWQ4ICBt
Zm46IDAwMDA0MWQ4DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjAwXSAgIGdmbjogMDAw
MDQxZDkgIG1mbjogMDAwMDQxZDkNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MDBdICAg
Z2ZuOiAwMDAwNDFkYSAgbWZuOiAwMDAwNDFkYQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
MjowMF0gICBnZm46IDAwMDA0MWRiICBtZm46IDAwMDA0MWRiDQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMyOjAwXSAgIGdmbjogMDAwMDQxZGMgIG1mbjogMDAwMDQxZGMNCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzI6MDBdICAgZ2ZuOiAwMDAwNDFkZCAgbWZuOiAwMDAwNDFkZA0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjowMF0gICBnZm46IDAwMDA0MWRlICBtZm46IDAw
MDA0MWRlDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjAwXSAgIGdmbjogMDAwMDQxZGYg
IG1mbjogMDAwMDQxZGYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MDBdICAgZ2ZuOiAw
MDAwNDFlMCAgbWZuOiAwMDAwNDFlMA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjowMF0g
ICBnZm46IDAwMDA0MWUxICBtZm46IDAwMDA0MWUxDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMyOjAwXSAgIGdmbjogMDAwMDQxZTIgIG1mbjogMDAwMDQxZTINCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzI6MDBdICAgZ2ZuOiAwMDAwNDFlMyAgbWZuOiAwMDAwNDFlMw0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMjowMF0gICBnZm46IDAwMDA0MWU0ICBtZm46IDAwMDA0MWU0
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjAwXSAgIGdmbjogMDAwMDQxZTUgIG1mbjog
MDAwMDQxZTUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MDBdICAgZ2ZuOiAwMDAwNDFl
NiAgbWZuOiAwMDAwNDFlNg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjowMF0gICBnZm46
IDAwMDA0MWU3ICBtZm46IDAwMDA0MWU3DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjAw
XSAgIGdmbjogMDAwMDQxZTggIG1mbjogMDAwMDQxZTgNCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzI6MDBdICAgZ2ZuOiAwMDAwNDFlOSAgbWZuOiAwMDAwNDFlOQ0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMjowMF0gICBnZm46IDAwMDA0MWVhICBtZm46IDAwMDA0MWVhDQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMyOjAwXSAgIGdmbjogMDAwMDQxZWIgIG1mbjogMDAwMDQx
ZWINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MDBdICAgZ2ZuOiAwMDAwNDFlYyAgbWZu
OiAwMDAwNDFlYw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjowMF0gICBnZm46IDAwMDA0
MWVkICBtZm46IDAwMDA0MWVkDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjAwXSAgIGdm
bjogMDAwMDQxZWUgIG1mbjogMDAwMDQxZWUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6
MDBdICAgZ2ZuOiAwMDAwNDFlZiAgbWZuOiAwMDAwNDFlZg0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMjowMF0gICBnZm46IDAwMDA0MWYwICBtZm46IDAwMDA0MWYwDQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMyOjAwXSAgIGdmbjogMDAwMDQxZjEgIG1mbjogMDAwMDQxZjENCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MDBdICAgZ2ZuOiAwMDAwNDFmMiAgbWZuOiAwMDAw
NDFmMg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjowMF0gICBnZm46IDAwMDA0MWYzICBt
Zm46IDAwMDA0MWYzDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjAwXSAgIGdmbjogMDAw
MDQxZjQgIG1mbjogMDAwMDQxZjQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MDBdICAg
Z2ZuOiAwMDAwNDFmNSAgbWZuOiAwMDAwNDFmNQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
MjowMF0gICBnZm46IDAwMDA0MWY2ICBtZm46IDAwMDA0MWY2DQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMyOjAwXSAgIGdmbjogMDAwMDQxZjcgIG1mbjogMDAwMDQxZjcNCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzI6MDBdICAgZ2ZuOiAwMDAwNDFmOCAgbWZuOiAwMDAwNDFmOA0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjowMF0gICBnZm46IDAwMDA0MWY5ICBtZm46IDAw
MDA0MWY5DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjAxXSAgIGdmbjogMDAwMDQxZmEg
IG1mbjogMDAwMDQxZmENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MDFdICAgZ2ZuOiAw
MDAwNDFmYiAgbWZuOiAwMDAwNDFmYg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjowMV0g
ICBnZm46IDAwMDA0MWZjICBtZm46IDAwMDA0MWZjDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMyOjAxXSAgIGdmbjogMDAwMDQxZmQgIG1mbjogMDAwMDQxZmQNCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzI6MDFdICAgZ2ZuOiAwMDAwNDFmZSAgbWZuOiAwMDAwNDFmZQ0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMjowMV0gICBnZm46IDAwMDA0MWZmICBtZm46IDAwMDA0MWZm
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjAxXSAgIGdmbjogMDAwMDQyMDAgIG1mbjog
MDAwMDQyMDANCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MDFdICAgZ2ZuOiAwMDAwNDIw
MSAgbWZuOiAwMDAwNDIwMQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjowMV0gICBnZm46
IDAwMDA0MjAyICBtZm46IDAwMDA0MjAyDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjAx
XSAgIGdmbjogMDAwMDQyMDMgIG1mbjogMDAwMDQyMDMNCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzI6MDFdICAgZ2ZuOiAwMDAwNDIwNCAgbWZuOiAwMDAwNDIwNA0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMjowMV0gICBnZm46IDAwMDA0MjA1ICBtZm46IDAwMDA0MjA1DQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMyOjAxXSAgIGdmbjogMDAwMDQyMDYgIG1mbjogMDAwMDQy
MDYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MDFdICAgZ2ZuOiAwMDAwNDIwNyAgbWZu
OiAwMDAwNDIwNw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjowMV0gICBnZm46IDAwMDA0
MjA4ICBtZm46IDAwMDA0MjA4DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjAxXSAgIGdm
bjogMDAwMDQyMDkgIG1mbjogMDAwMDQyMDkNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6
MDFdICAgZ2ZuOiAwMDAwNDIwYSAgbWZuOiAwMDAwNDIwYQ0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMjowMV0gICBnZm46IDAwMDA0MjBiICBtZm46IDAwMDA0MjBiDQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMyOjAxXSAgIGdmbjogMDAwMDQyMGMgIG1mbjogMDAwMDQyMGMNCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MDFdICAgZ2ZuOiAwMDAwNDIwZCAgbWZuOiAwMDAw
NDIwZA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjowMV0gICBnZm46IDAwMDA0MjBlICBt
Zm46IDAwMDA0MjBlDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjAxXSAgIGdmbjogMDAw
MDQyMGYgIG1mbjogMDAwMDQyMGYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MDFdICAg
Z2ZuOiAwMDAwNDIxMCAgbWZuOiAwMDAwNDIxMA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
MjowMV0gICBnZm46IDAwMDA0MjExICBtZm46IDAwMDA0MjExDQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMyOjAxXSAgIGdmbjogMDAwMDQyMTIgIG1mbjogMDAwMDQyMTINCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzI6MDFdICAgZ2ZuOiAwMDAwNDIxMyAgbWZuOiAwMDAwNDIxMw0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjowMV0gICBnZm46IDAwMDA0MjE0ICBtZm46IDAw
MDA0MjE0DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjAxXSAgIGdmbjogMDAwMDQyMTUg
IG1mbjogMDAwMDQyMTUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MDFdICAgZ2ZuOiAw
MDAwNDIxNiAgbWZuOiAwMDAwNDIxNg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjowMV0g
ICBnZm46IDAwMDA0MjE3ICBtZm46IDAwMDA0MjE3DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMyOjAxXSAgIGdmbjogMDAwMDQyMTggIG1mbjogMDAwMDQyMTgNCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzI6MDFdICAgZ2ZuOiAwMDAwNDIxOSAgbWZuOiAwMDAwNDIxOQ0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMjowMV0gICBnZm46IDAwMDA0MjFhICBtZm46IDAwMDA0MjFh
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjAxXSAgIGdmbjogMDAwMDQyMWIgIG1mbjog
MDAwMDQyMWINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MDFdICAgZ2ZuOiAwMDAwNDIx
YyAgbWZuOiAwMDAwNDIxYw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjowMV0gICBnZm46
IDAwMDA0MjFkICBtZm46IDAwMDA0MjFkDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjAx
XSAgIGdmbjogMDAwMDQyMWUgIG1mbjogMDAwMDQyMWUNCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzI6MDFdICAgZ2ZuOiAwMDAwNDIxZiAgbWZuOiAwMDAwNDIxZg0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMjowMV0gICBnZm46IDAwMDA0MjIwICBtZm46IDAwMDA0MjIwDQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMyOjAxXSAgIGdmbjogMDAwMDQyMjEgIG1mbjogMDAwMDQy
MjENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MDFdICAgZ2ZuOiAwMDAwNDIyMiAgbWZu
OiAwMDAwNDIyMg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjowMV0gICBnZm46IDAwMDA0
MjIzICBtZm46IDAwMDA0MjIzDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjAxXSAgIGdm
bjogMDAwMDQyMjQgIG1mbjogMDAwMDQyMjQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6
MDFdICAgZ2ZuOiAwMDAwNDIyNSAgbWZuOiAwMDAwNDIyNQ0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMjowMV0gICBnZm46IDAwMDA0MjI2ICBtZm46IDAwMDA0MjI2DQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMyOjAxXSAgIGdmbjogMDAwMDQyMjcgIG1mbjogMDAwMDQyMjcNCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MDFdICAgZ2ZuOiAwMDAwNDIyOCAgbWZuOiAwMDAw
NDIyOA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjowMV0gICBnZm46IDAwMDA0MjI5ICBt
Zm46IDAwMDA0MjI5DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjAxXSAgIGdmbjogMDAw
MDQyMmEgIG1mbjogMDAwMDQyMmENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MDFdICAg
Z2ZuOiAwMDAwNDIyYiAgbWZuOiAwMDAwNDIyYg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
MjowMV0gICBnZm46IDAwMDA0MjJjICBtZm46IDAwMDA0MjJjDQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMyOjAxXSAgIGdmbjogMDAwMDQyMmQgIG1mbjogMDAwMDQyMmQNCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzI6MDFdICAgZ2ZuOiAwMDAwNDIyZSAgbWZuOiAwMDAwNDIyZQ0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjowMV0gICBnZm46IDAwMDA0MjJmICBtZm46IDAw
MDA0MjJmDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjAxXSAgIGdmbjogMDAwMDQyMzAg
IG1mbjogMDAwMDQyMzANCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MDFdICAgZ2ZuOiAw
MDAwNDIzMSAgbWZuOiAwMDAwNDIzMQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjowMV0g
ICBnZm46IDAwMDA0MjMyICBtZm46IDAwMDA0MjMyDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMyOjAxXSAgIGdmbjogMDAwMDQyMzMgIG1mbjogMDAwMDQyMzMNCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzI6MDFdICAgZ2ZuOiAwMDAwNDIzNCAgbWZuOiAwMDAwNDIzNA0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMjowMV0gICBnZm46IDAwMDA0MjM1ICBtZm46IDAwMDA0MjM1
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjAxXSAgIGdmbjogMDAwMDQyMzYgIG1mbjog
MDAwMDQyMzYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MDFdICAgZ2ZuOiAwMDAwNDIz
NyAgbWZuOiAwMDAwNDIzNw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjowMV0gICBnZm46
IDAwMDA0MjM4ICBtZm46IDAwMDA0MjM4DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjAx
XSAgIGdmbjogMDAwMDQyMzkgIG1mbjogMDAwMDQyMzkNCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzI6MDJdICAgZ2ZuOiAwMDAwNDIzYSAgbWZuOiAwMDAwNDIzYQ0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMjowMl0gICBnZm46IDAwMDA0MjNiICBtZm46IDAwMDA0MjNiDQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMyOjAyXSAgIGdmbjogMDAwMDQyM2MgIG1mbjogMDAwMDQy
M2MNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MDJdICAgZ2ZuOiAwMDAwNDIzZCAgbWZu
OiAwMDAwNDIzZA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjowMl0gICBnZm46IDAwMDA0
MjNlICBtZm46IDAwMDA0MjNlDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjAyXSAgIGdm
bjogMDAwMDQyM2YgIG1mbjogMDAwMDQyM2YNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6
MDJdICAgZ2ZuOiAwMDAwNDI0MCAgbWZuOiAwMDAwNDI0MA0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMjowMl0gICBnZm46IDAwMDA0MjQxICBtZm46IDAwMDA0MjQxDQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMyOjAyXSAgIGdmbjogMDAwMDQyNDIgIG1mbjogMDAwMDQyNDINCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MDJdICAgZ2ZuOiAwMDAwNDI0MyAgbWZuOiAwMDAw
NDI0Mw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjowMl0gICBnZm46IDAwMDA0MjQ0ICBt
Zm46IDAwMDA0MjQ0DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjAyXSAgIGdmbjogMDAw
MDQyNDUgIG1mbjogMDAwMDQyNDUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MDJdICAg
Z2ZuOiAwMDAwNDI0NiAgbWZuOiAwMDAwNDI0Ng0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
MjowMl0gICBnZm46IDAwMDA0MjQ3ICBtZm46IDAwMDA0MjQ3DQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMyOjAyXSAgIGdmbjogMDAwMDQyNDggIG1mbjogMDAwMDQyNDgNCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzI6MDJdICAgZ2ZuOiAwMDAwNDI0OSAgbWZuOiAwMDAwNDI0OQ0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjowMl0gICBnZm46IDAwMDA0MjRhICBtZm46IDAw
MDA0MjRhDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjAyXSAgIGdmbjogMDAwMDQyNGIg
IG1mbjogMDAwMDQyNGINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MDJdICAgZ2ZuOiAw
MDAwNDI0YyAgbWZuOiAwMDAwNDI0Yw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjowMl0g
ICBnZm46IDAwMDA0MjRkICBtZm46IDAwMDA0MjRkDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMyOjAyXSAgIGdmbjogMDAwMDQyNGUgIG1mbjogMDAwMDQyNGUNCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzI6MDJdICAgZ2ZuOiAwMDAwNDI0ZiAgbWZuOiAwMDAwNDI0Zg0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMjowMl0gICBnZm46IDAwMDA0MjUwICBtZm46IDAwMDA0MjUw
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjAyXSAgIGdmbjogMDAwMDQyNTEgIG1mbjog
MDAwMDQyNTENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MDJdICAgZ2ZuOiAwMDAwNDI1
MiAgbWZuOiAwMDAwNDI1Mg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjowMl0gICBnZm46
IDAwMDA0MjUzICBtZm46IDAwMDA0MjUzDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjAy
XSAgIGdmbjogMDAwMDQyNTQgIG1mbjogMDAwMDQyNTQNCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzI6MDJdICAgZ2ZuOiAwMDAwNDI1NSAgbWZuOiAwMDAwNDI1NQ0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMjowMl0gICBnZm46IDAwMDA0MjU2ICBtZm46IDAwMDA0MjU2DQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMyOjAyXSAgIGdmbjogMDAwMDQyNTcgIG1mbjogMDAwMDQy
NTcNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MDJdICAgZ2ZuOiAwMDAwNDI1OCAgbWZu
OiAwMDAwNDI1OA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjowMl0gICBnZm46IDAwMDA0
MjU5ICBtZm46IDAwMDA0MjU5DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjAyXSAgIGdm
bjogMDAwMDQyNWEgIG1mbjogMDAwMDQyNWENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6
MDJdICAgZ2ZuOiAwMDAwNDI1YiAgbWZuOiAwMDAwNDI1Yg0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMjowMl0gICBnZm46IDAwMDA0MjVjICBtZm46IDAwMDA0MjVjDQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMyOjAyXSAgIGdmbjogMDAwMDQyNWQgIG1mbjogMDAwMDQyNWQNCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MDJdICAgZ2ZuOiAwMDAwNDI1ZSAgbWZuOiAwMDAw
NDI1ZQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjowMl0gICBnZm46IDAwMDA0MjVmICBt
Zm46IDAwMDA0MjVmDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjAyXSAgIGdmbjogMDAw
MDQyNjAgIG1mbjogMDAwMDQyNjANCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MDJdICAg
Z2ZuOiAwMDAwNDI2MSAgbWZuOiAwMDAwNDI2MQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
MjowMl0gICBnZm46IDAwMDA0MjYyICBtZm46IDAwMDA0MjYyDQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMyOjAyXSAgIGdmbjogMDAwMDQyNjMgIG1mbjogMDAwMDQyNjMNCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzI6MDJdICAgZ2ZuOiAwMDAwNDI2NCAgbWZuOiAwMDAwNDI2NA0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjowMl0gICBnZm46IDAwMDA0MjY1ICBtZm46IDAw
MDA0MjY1DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjAyXSAgIGdmbjogMDAwMDQyNjYg
IG1mbjogMDAwMDQyNjYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MDJdICAgZ2ZuOiAw
MDAwNDI2NyAgbWZuOiAwMDAwNDI2Nw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjowMl0g
ICBnZm46IDAwMDA0MjY4ICBtZm46IDAwMDA0MjY4DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMyOjAyXSAgIGdmbjogMDAwMDQyNjkgIG1mbjogMDAwMDQyNjkNCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzI6MDJdICAgZ2ZuOiAwMDAwNDI2YSAgbWZuOiAwMDAwNDI2YQ0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMjowMl0gICBnZm46IDAwMDA0MjZiICBtZm46IDAwMDA0MjZi
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjAyXSAgIGdmbjogMDAwMDQyNmMgIG1mbjog
MDAwMDQyNmMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MDJdICAgZ2ZuOiAwMDAwNDI2
ZCAgbWZuOiAwMDAwNDI2ZA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjowMl0gICBnZm46
IDAwMDA0MjZlICBtZm46IDAwMDA0MjZlDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjAy
XSAgIGdmbjogMDAwMDQyNmYgIG1mbjogMDAwMDQyNmYNCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzI6MDJdICAgZ2ZuOiAwMDAwNDI3MCAgbWZuOiAwMDAwNDI3MA0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMjowMl0gICBnZm46IDAwMDA0MjcxICBtZm46IDAwMDA0MjcxDQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMyOjAyXSAgIGdmbjogMDAwMDQyNzIgIG1mbjogMDAwMDQy
NzINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MDJdICAgZ2ZuOiAwMDAwNDI3MyAgbWZu
OiAwMDAwNDI3Mw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjowMl0gICBnZm46IDAwMDA0
Mjc0ICBtZm46IDAwMDA0Mjc0DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjAyXSAgIGdm
bjogMDAwMDQyNzUgIG1mbjogMDAwMDQyNzUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6
MDJdICAgZ2ZuOiAwMDAwNDI3NiAgbWZuOiAwMDAwNDI3Ng0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMjowMl0gICBnZm46IDAwMDA0Mjc3ICBtZm46IDAwMDA0Mjc3DQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMyOjAyXSAgIGdmbjogMDAwMDQyNzggIG1mbjogMDAwMDQyNzgNCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MDJdICAgZ2ZuOiAwMDAwNDI3OSAgbWZuOiAwMDAw
NDI3OQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjowM10gICBnZm46IDAwMDA0MjdhICBt
Zm46IDAwMDA0MjdhDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjAzXSAgIGdmbjogMDAw
MDQyN2IgIG1mbjogMDAwMDQyN2INCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MDNdICAg
Z2ZuOiAwMDAwNDI3YyAgbWZuOiAwMDAwNDI3Yw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
MjowM10gICBnZm46IDAwMDA0MjdkICBtZm46IDAwMDA0MjdkDQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMyOjAzXSAgIGdmbjogMDAwMDQyN2UgIG1mbjogMDAwMDQyN2UNCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzI6MDNdICAgZ2ZuOiAwMDAwNDI3ZiAgbWZuOiAwMDAwNDI3Zg0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjowM10gICBnZm46IDAwMDA0MjgwICBtZm46IDAw
MDA0MjgwDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjAzXSAgIGdmbjogMDAwMDQyODEg
IG1mbjogMDAwMDQyODENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MDNdICAgZ2ZuOiAw
MDAwNDI4MiAgbWZuOiAwMDAwNDI4Mg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjowM10g
ICBnZm46IDAwMDA0MjgzICBtZm46IDAwMDA0MjgzDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMyOjAzXSAgIGdmbjogMDAwMDQyODQgIG1mbjogMDAwMDQyODQNCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzI6MDNdICAgZ2ZuOiAwMDAwNDI4NSAgbWZuOiAwMDAwNDI4NQ0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMjowM10gICBnZm46IDAwMDA0Mjg2ICBtZm46IDAwMDA0Mjg2
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjAzXSAgIGdmbjogMDAwMDQyODcgIG1mbjog
MDAwMDQyODcNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MDNdICAgZ2ZuOiAwMDAwNDI4
OCAgbWZuOiAwMDAwNDI4OA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjowM10gICBnZm46
IDAwMDA0Mjg5ICBtZm46IDAwMDA0Mjg5DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjAz
XSAgIGdmbjogMDAwMDQyOGEgIG1mbjogMDAwMDQyOGENCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzI6MDNdICAgZ2ZuOiAwMDAwNDI4YiAgbWZuOiAwMDAwNDI4Yg0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMjowM10gICBnZm46IDAwMDA0MjhjICBtZm46IDAwMDA0MjhjDQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMyOjAzXSAgIGdmbjogMDAwMDQyOGQgIG1mbjogMDAwMDQy
OGQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MDNdICAgZ2ZuOiAwMDAwNDI4ZSAgbWZu
OiAwMDAwNDI4ZQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjowM10gICBnZm46IDAwMDA0
MjhmICBtZm46IDAwMDA0MjhmDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjAzXSAgIGdm
bjogMDAwMDQyOTAgIG1mbjogMDAwMDQyOTANCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6
MDNdICAgZ2ZuOiAwMDAwNDI5MSAgbWZuOiAwMDAwNDI5MQ0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMjowM10gICBnZm46IDAwMDA0MjkyICBtZm46IDAwMDA0MjkyDQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMyOjAzXSAgIGdmbjogMDAwMDQyOTMgIG1mbjogMDAwMDQyOTMNCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MDNdICAgZ2ZuOiAwMDAwNDI5NCAgbWZuOiAwMDAw
NDI5NA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjowM10gICBnZm46IDAwMDA0Mjk1ICBt
Zm46IDAwMDA0Mjk1DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjAzXSAgIGdmbjogMDAw
MDQyOTYgIG1mbjogMDAwMDQyOTYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MDNdICAg
Z2ZuOiAwMDAwNDI5NyAgbWZuOiAwMDAwNDI5Nw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
MjowM10gICBnZm46IDAwMDA0Mjk4ICBtZm46IDAwMDA0Mjk4DQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMyOjAzXSAgIGdmbjogMDAwMDQyOTkgIG1mbjogMDAwMDQyOTkNCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzI6MDNdICAgZ2ZuOiAwMDAwNDI5YSAgbWZuOiAwMDAwNDI5YQ0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjowM10gICBnZm46IDAwMDA0MjliICBtZm46IDAw
MDA0MjliDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjAzXSAgIGdmbjogMDAwMDQyOWMg
IG1mbjogMDAwMDQyOWMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MDNdICAgZ2ZuOiAw
MDAwNDI5ZCAgbWZuOiAwMDAwNDI5ZA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjowM10g
ICBnZm46IDAwMDA0MjllICBtZm46IDAwMDA0MjllDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMyOjAzXSAgIGdmbjogMDAwMDQyOWYgIG1mbjogMDAwMDQyOWYNCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzI6MDNdICAgZ2ZuOiAwMDAwNDJhMCAgbWZuOiAwMDAwNDJhMA0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMjowM10gICBnZm46IDAwMDA0MmExICBtZm46IDAwMDA0MmEx
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjAzXSAgIGdmbjogMDAwMDQyYTIgIG1mbjog
MDAwMDQyYTINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MDNdICAgZ2ZuOiAwMDAwNDJh
MyAgbWZuOiAwMDAwNDJhMw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjowM10gICBnZm46
IDAwMDA0MmE0ICBtZm46IDAwMDA0MmE0DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjAz
XSAgIGdmbjogMDAwMDQyYTUgIG1mbjogMDAwMDQyYTUNCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzI6MDNdICAgZ2ZuOiAwMDAwNDJhNiAgbWZuOiAwMDAwNDJhNg0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMjowM10gICBnZm46IDAwMDA0MmE3ICBtZm46IDAwMDA0MmE3DQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMyOjAzXSAgIGdmbjogMDAwMDQyYTggIG1mbjogMDAwMDQy
YTgNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MDNdICAgZ2ZuOiAwMDAwNDJhOSAgbWZu
OiAwMDAwNDJhOQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjowM10gICBnZm46IDAwMDA0
MmFhICBtZm46IDAwMDA0MmFhDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjAzXSAgIGdm
bjogMDAwMDQyYWIgIG1mbjogMDAwMDQyYWINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6
MDNdICAgZ2ZuOiAwMDAwNDJhYyAgbWZuOiAwMDAwNDJhYw0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMjowM10gICBnZm46IDAwMDA0MmFkICBtZm46IDAwMDA0MmFkDQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMyOjAzXSAgIGdmbjogMDAwMDQyYWUgIG1mbjogMDAwMDQyYWUNCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MDNdICAgZ2ZuOiAwMDAwNDJhZiAgbWZuOiAwMDAw
NDJhZg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjowM10gICBnZm46IDAwMDA0MmIwICBt
Zm46IDAwMDA0MmIwDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjAzXSAgIGdmbjogMDAw
MDQyYjEgIG1mbjogMDAwMDQyYjENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MDNdICAg
Z2ZuOiAwMDAwNDJiMiAgbWZuOiAwMDAwNDJiMg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
MjowM10gICBnZm46IDAwMDA0MmIzICBtZm46IDAwMDA0MmIzDQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMyOjAzXSAgIGdmbjogMDAwMDQyYjQgIG1mbjogMDAwMDQyYjQNCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzI6MDNdICAgZ2ZuOiAwMDAwNDJiNSAgbWZuOiAwMDAwNDJiNQ0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjowM10gICBnZm46IDAwMDA0MmI2ICBtZm46IDAw
MDA0MmI2DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjAzXSAgIGdmbjogMDAwMDQyYjcg
IG1mbjogMDAwMDQyYjcNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MDNdICAgZ2ZuOiAw
MDAwNDJiOCAgbWZuOiAwMDAwNDJiOA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjowM10g
ICBnZm46IDAwMDA0MmI5ICBtZm46IDAwMDA0MmI5DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMyOjA0XSAgIGdmbjogMDAwMDQyYmEgIG1mbjogMDAwMDQyYmENCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzI6MDRdICAgZ2ZuOiAwMDAwNDJiYiAgbWZuOiAwMDAwNDJiYg0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMjowNF0gICBnZm46IDAwMDA0MmJjICBtZm46IDAwMDA0MmJj
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjA0XSAgIGdmbjogMDAwMDQyYmQgIG1mbjog
MDAwMDQyYmQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MDRdICAgZ2ZuOiAwMDAwNDJi
ZSAgbWZuOiAwMDAwNDJiZQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjowNF0gICBnZm46
IDAwMDA0MmJmICBtZm46IDAwMDA0MmJmDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjA0
XSAgIGdmbjogMDAwMDQyYzAgIG1mbjogMDAwMDQyYzANCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzI6MDRdICAgZ2ZuOiAwMDAwNDJjMSAgbWZuOiAwMDAwNDJjMQ0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMjowNF0gICBnZm46IDAwMDA0MmMyICBtZm46IDAwMDA0MmMyDQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMyOjA0XSAgIGdmbjogMDAwMDQyYzMgIG1mbjogMDAwMDQy
YzMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MDRdICAgZ2ZuOiAwMDAwNDJjNCAgbWZu
OiAwMDAwNDJjNA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjowNF0gICBnZm46IDAwMDA0
MmM1ICBtZm46IDAwMDA0MmM1DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjA0XSAgIGdm
bjogMDAwMDQyYzYgIG1mbjogMDAwMDQyYzYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6
MDRdICAgZ2ZuOiAwMDAwNDJjNyAgbWZuOiAwMDAwNDJjNw0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMjowNF0gICBnZm46IDAwMDA0MmM4ICBtZm46IDAwMDA0MmM4DQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMyOjA0XSAgIGdmbjogMDAwMDQyYzkgIG1mbjogMDAwMDQyYzkNCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MDRdICAgZ2ZuOiAwMDAwNDJjYSAgbWZuOiAwMDAw
NDJjYQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjowNF0gICBnZm46IDAwMDA0MmNiICBt
Zm46IDAwMDA0MmNiDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjA0XSAgIGdmbjogMDAw
MDQyY2MgIG1mbjogMDAwMDQyY2MNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MDRdICAg
Z2ZuOiAwMDAwNDJjZCAgbWZuOiAwMDAwNDJjZA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
MjowNF0gICBnZm46IDAwMDA0MmNlICBtZm46IDAwMDA0MmNlDQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMyOjA0XSAgIGdmbjogMDAwMDQyY2YgIG1mbjogMDAwMDQyY2YNCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzI6MDRdICAgZ2ZuOiAwMDAwNDJkMCAgbWZuOiAwMDAwNDJkMA0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjowNF0gICBnZm46IDAwMDA0MmQxICBtZm46IDAw
MDA0MmQxDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjA0XSAgIGdmbjogMDAwMDQyZDIg
IG1mbjogMDAwMDQyZDINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MDRdICAgZ2ZuOiAw
MDAwNDJkMyAgbWZuOiAwMDAwNDJkMw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjowNF0g
ICBnZm46IDAwMDA0MmQ0ICBtZm46IDAwMDA0MmQ0DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMyOjA0XSAgIGdmbjogMDAwMDQyZDUgIG1mbjogMDAwMDQyZDUNCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzI6MDRdICAgZ2ZuOiAwMDAwNDJkNiAgbWZuOiAwMDAwNDJkNg0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMjowNF0gICBnZm46IDAwMDA0MmQ3ICBtZm46IDAwMDA0MmQ3
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjA0XSAgIGdmbjogMDAwMDQyZDggIG1mbjog
MDAwMDQyZDgNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MDRdICAgZ2ZuOiAwMDAwNDJk
OSAgbWZuOiAwMDAwNDJkOQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjowNF0gICBnZm46
IDAwMDA0MmRhICBtZm46IDAwMDA0MmRhDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjA0
XSAgIGdmbjogMDAwMDQyZGIgIG1mbjogMDAwMDQyZGINCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzI6MDRdICAgZ2ZuOiAwMDAwNDJkYyAgbWZuOiAwMDAwNDJkYw0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMjowNF0gICBnZm46IDAwMDA0MmRkICBtZm46IDAwMDA0MmRkDQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMyOjA0XSAgIGdmbjogMDAwMDQyZGUgIG1mbjogMDAwMDQy
ZGUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MDRdICAgZ2ZuOiAwMDAwNDJkZiAgbWZu
OiAwMDAwNDJkZg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjowNF0gICBnZm46IDAwMDA0
MmUwICBtZm46IDAwMDA0MmUwDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjA0XSAgIGdm
bjogMDAwMDQyZTEgIG1mbjogMDAwMDQyZTENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6
MDRdICAgZ2ZuOiAwMDAwNDJlMiAgbWZuOiAwMDAwNDJlMg0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMjowNF0gICBnZm46IDAwMDA0MmUzICBtZm46IDAwMDA0MmUzDQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMyOjA0XSAgIGdmbjogMDAwMDQyZTQgIG1mbjogMDAwMDQyZTQNCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MDRdICAgZ2ZuOiAwMDAwNDJlNSAgbWZuOiAwMDAw
NDJlNQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjowNF0gICBnZm46IDAwMDA0MmU2ICBt
Zm46IDAwMDA0MmU2DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjA0XSAgIGdmbjogMDAw
MDQyZTcgIG1mbjogMDAwMDQyZTcNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MDRdICAg
Z2ZuOiAwMDAwNDJlOCAgbWZuOiAwMDAwNDJlOA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
MjowNF0gICBnZm46IDAwMDA0MmU5ICBtZm46IDAwMDA0MmU5DQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMyOjA0XSAgIGdmbjogMDAwMDQyZWEgIG1mbjogMDAwMDQyZWENCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzI6MDRdICAgZ2ZuOiAwMDAwNDJlYiAgbWZuOiAwMDAwNDJlYg0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjowNF0gICBnZm46IDAwMDA0MmVjICBtZm46IDAw
MDA0MmVjDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjA0XSAgIGdmbjogMDAwMDQyZWQg
IG1mbjogMDAwMDQyZWQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MDRdICAgZ2ZuOiAw
MDAwNDJlZSAgbWZuOiAwMDAwNDJlZQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjowNF0g
ICBnZm46IDAwMDA0MmVmICBtZm46IDAwMDA0MmVmDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMyOjA0XSAgIGdmbjogMDAwMDQyZjAgIG1mbjogMDAwMDQyZjANCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzI6MDRdICAgZ2ZuOiAwMDAwNDJmMSAgbWZuOiAwMDAwNDJmMQ0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMjowNF0gICBnZm46IDAwMDA0MmYyICBtZm46IDAwMDA0MmYy
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjA0XSAgIGdmbjogMDAwMDQyZjMgIG1mbjog
MDAwMDQyZjMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MDRdICAgZ2ZuOiAwMDAwNDJm
NCAgbWZuOiAwMDAwNDJmNA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjowNF0gICBnZm46
IDAwMDA0MmY1ICBtZm46IDAwMDA0MmY1DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjA0
XSAgIGdmbjogMDAwMDQyZjYgIG1mbjogMDAwMDQyZjYNCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzI6MDRdICAgZ2ZuOiAwMDAwNDJmNyAgbWZuOiAwMDAwNDJmNw0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMjowNF0gICBnZm46IDAwMDA0MmY4ICBtZm46IDAwMDA0MmY4DQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMyOjA0XSAgIGdmbjogMDAwMDQyZjkgIG1mbjogMDAwMDQy
ZjkNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MDRdICAgZ2ZuOiAwMDAwNDJmYSAgbWZu
OiAwMDAwNDJmYQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjowNV0gICBnZm46IDAwMDA0
MmZiICBtZm46IDAwMDA0MmZiDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjA1XSAgIGdm
bjogMDAwMDQyZmMgIG1mbjogMDAwMDQyZmMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6
MDVdICAgZ2ZuOiAwMDAwNDJmZCAgbWZuOiAwMDAwNDJmZA0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMjowNV0gICBnZm46IDAwMDA0MmZlICBtZm46IDAwMDA0MmZlDQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMyOjA1XSAgIGdmbjogMDAwMDQyZmYgIG1mbjogMDAwMDQyZmYNCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MDVdICAgZ2ZuOiAwMDAwNDMwMCAgbWZuOiAwMDAw
NDMwMA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjowNV0gICBnZm46IDAwMDA0MzAxICBt
Zm46IDAwMDA0MzAxDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjA1XSAgIGdmbjogMDAw
MDQzMDIgIG1mbjogMDAwMDQzMDINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MDVdICAg
Z2ZuOiAwMDAwNDMwMyAgbWZuOiAwMDAwNDMwMw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
MjowNV0gICBnZm46IDAwMDA0MzA0ICBtZm46IDAwMDA0MzA0DQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMyOjA1XSAgIGdmbjogMDAwMDQzMDUgIG1mbjogMDAwMDQzMDUNCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzI6MDVdICAgZ2ZuOiAwMDAwNDMwNiAgbWZuOiAwMDAwNDMwNg0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjowNV0gICBnZm46IDAwMDA0MzA3ICBtZm46IDAw
MDA0MzA3DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjA1XSAgIGdmbjogMDAwMDQzMDgg
IG1mbjogMDAwMDQzMDgNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MDVdICAgZ2ZuOiAw
MDAwNDMwOSAgbWZuOiAwMDAwNDMwOQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjowNV0g
ICBnZm46IDAwMDA0MzBhICBtZm46IDAwMDA0MzBhDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMyOjA1XSAgIGdmbjogMDAwMDQzMGIgIG1mbjogMDAwMDQzMGINCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzI6MDVdICAgZ2ZuOiAwMDAwNDMwYyAgbWZuOiAwMDAwNDMwYw0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMjowNV0gICBnZm46IDAwMDA0MzBkICBtZm46IDAwMDA0MzBk
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjA1XSAgIGdmbjogMDAwMDQzMGUgIG1mbjog
MDAwMDQzMGUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MDVdICAgZ2ZuOiAwMDAwNDMw
ZiAgbWZuOiAwMDAwNDMwZg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjowNV0gICBnZm46
IDAwMDA0MzEwICBtZm46IDAwMDA0MzEwDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjA1
XSAgIGdmbjogMDAwMDQzMTEgIG1mbjogMDAwMDQzMTENCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzI6MDVdICAgZ2ZuOiAwMDAwNDMxMiAgbWZuOiAwMDAwNDMxMg0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMjowNV0gICBnZm46IDAwMDA0MzEzICBtZm46IDAwMDA0MzEzDQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMyOjA1XSAgIGdmbjogMDAwMDQzMTQgIG1mbjogMDAwMDQz
MTQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MDVdICAgZ2ZuOiAwMDAwNDMxNSAgbWZu
OiAwMDAwNDMxNQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjowNV0gICBnZm46IDAwMDA0
MzE2ICBtZm46IDAwMDA0MzE2DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjA1XSAgIGdm
bjogMDAwMDQzMTcgIG1mbjogMDAwMDQzMTcNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6
MDVdICAgZ2ZuOiAwMDAwNDMxOCAgbWZuOiAwMDAwNDMxOA0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMjowNV0gICBnZm46IDAwMDA0MzE5ICBtZm46IDAwMDA0MzE5DQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMyOjA1XSAgIGdmbjogMDAwMDQzMWEgIG1mbjogMDAwMDQzMWENCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MDVdICAgZ2ZuOiAwMDAwNDMxYiAgbWZuOiAwMDAw
NDMxYg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjowNV0gICBnZm46IDAwMDA0MzFjICBt
Zm46IDAwMDA0MzFjDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjA1XSAgIGdmbjogMDAw
MDQzMWQgIG1mbjogMDAwMDQzMWQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MDVdICAg
Z2ZuOiAwMDAwNDMxZSAgbWZuOiAwMDAwNDMxZQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
MjowNV0gICBnZm46IDAwMDA0MzFmICBtZm46IDAwMDA0MzFmDQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMyOjA1XSAgIGdmbjogMDAwMDQzMjAgIG1mbjogMDAwMDQzMjANCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzI6MDVdICAgZ2ZuOiAwMDAwNDMyMSAgbWZuOiAwMDAwNDMyMQ0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjowNV0gICBnZm46IDAwMDA0MzIyICBtZm46IDAw
MDA0MzIyDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjA1XSAgIGdmbjogMDAwMDQzMjMg
IG1mbjogMDAwMDQzMjMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MDVdICAgZ2ZuOiAw
MDAwNDMyNCAgbWZuOiAwMDAwNDMyNA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjowNV0g
ICBnZm46IDAwMDA0MzI1ICBtZm46IDAwMDA0MzI1DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMyOjA1XSAgIGdmbjogMDAwMDQzMjYgIG1mbjogMDAwMDQzMjYNCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzI6MDVdICAgZ2ZuOiAwMDAwNDMyNyAgbWZuOiAwMDAwNDMyNw0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMjowNV0gICBnZm46IDAwMDA0MzI4ICBtZm46IDAwMDA0MzI4
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjA1XSAgIGdmbjogMDAwMDQzMjkgIG1mbjog
MDAwMDQzMjkNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MDVdICAgZ2ZuOiAwMDAwNDMy
YSAgbWZuOiAwMDAwNDMyYQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjowNV0gICBnZm46
IDAwMDA0MzJiICBtZm46IDAwMDA0MzJiDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjA1
XSAgIGdmbjogMDAwMDQzMmMgIG1mbjogMDAwMDQzMmMNCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzI6MDVdICAgZ2ZuOiAwMDAwNDMyZCAgbWZuOiAwMDAwNDMyZA0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMjowNV0gICBnZm46IDAwMDA0MzJlICBtZm46IDAwMDA0MzJlDQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMyOjA1XSAgIGdmbjogMDAwMDQzMmYgIG1mbjogMDAwMDQz
MmYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MDVdICAgZ2ZuOiAwMDAwNDMzMCAgbWZu
OiAwMDAwNDMzMA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjowNV0gICBnZm46IDAwMDA0
MzMxICBtZm46IDAwMDA0MzMxDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjA1XSAgIGdm
bjogMDAwMDQzMzIgIG1mbjogMDAwMDQzMzINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6
MDVdICAgZ2ZuOiAwMDAwNDMzMyAgbWZuOiAwMDAwNDMzMw0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMjowNV0gICBnZm46IDAwMDA0MzM0ICBtZm46IDAwMDA0MzM0DQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMyOjA1XSAgIGdmbjogMDAwMDQzMzUgIG1mbjogMDAwMDQzMzUNCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MDVdICAgZ2ZuOiAwMDAwNDMzNiAgbWZuOiAwMDAw
NDMzNg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjowNV0gICBnZm46IDAwMDA0MzM3ICBt
Zm46IDAwMDA0MzM3DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjA1XSAgIGdmbjogMDAw
MDQzMzggIG1mbjogMDAwMDQzMzgNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MDVdICAg
Z2ZuOiAwMDAwNDMzOSAgbWZuOiAwMDAwNDMzOQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
MjowNV0gICBnZm46IDAwMDA0MzNhICBtZm46IDAwMDA0MzNhDQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMyOjA2XSAgIGdmbjogMDAwMDQzM2IgIG1mbjogMDAwMDQzM2INCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzI6MDZdICAgZ2ZuOiAwMDAwNDMzYyAgbWZuOiAwMDAwNDMzYw0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjowNl0gICBnZm46IDAwMDA0MzNkICBtZm46IDAw
MDA0MzNkDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjA2XSAgIGdmbjogMDAwMDQzM2Ug
IG1mbjogMDAwMDQzM2UNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MDZdICAgZ2ZuOiAw
MDAwNDMzZiAgbWZuOiAwMDAwNDMzZg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjowNl0g
ICBnZm46IDAwMDA0MzQwICBtZm46IDAwMDA0MzQwDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMyOjA2XSAgIGdmbjogMDAwMDQzNDEgIG1mbjogMDAwMDQzNDENCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzI6MDZdICAgZ2ZuOiAwMDAwNDM0MiAgbWZuOiAwMDAwNDM0Mg0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMjowNl0gICBnZm46IDAwMDA0MzQzICBtZm46IDAwMDA0MzQz
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjA2XSAgIGdmbjogMDAwMDQzNDQgIG1mbjog
MDAwMDQzNDQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MDZdICAgZ2ZuOiAwMDAwNDM0
NSAgbWZuOiAwMDAwNDM0NQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjowNl0gICBnZm46
IDAwMDA0MzQ2ICBtZm46IDAwMDA0MzQ2DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjA2
XSAgIGdmbjogMDAwMDQzNDcgIG1mbjogMDAwMDQzNDcNCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzI6MDZdICAgZ2ZuOiAwMDAwNDM0OCAgbWZuOiAwMDAwNDM0OA0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMjowNl0gICBnZm46IDAwMDA0MzQ5ICBtZm46IDAwMDA0MzQ5DQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMyOjA2XSAgIGdmbjogMDAwMDQzNGEgIG1mbjogMDAwMDQz
NGENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MDZdICAgZ2ZuOiAwMDAwNDM0YiAgbWZu
OiAwMDAwNDM0Yg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjowNl0gICBnZm46IDAwMDA0
MzRjICBtZm46IDAwMDA0MzRjDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjA2XSAgIGdm
bjogMDAwMDQzNGQgIG1mbjogMDAwMDQzNGQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6
MDZdICAgZ2ZuOiAwMDAwNDM0ZSAgbWZuOiAwMDAwNDM0ZQ0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMjowNl0gICBnZm46IDAwMDA0MzRmICBtZm46IDAwMDA0MzRmDQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMyOjA2XSAgIGdmbjogMDAwMDQzNTAgIG1mbjogMDAwMDQzNTANCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MDZdICAgZ2ZuOiAwMDAwNDM1MSAgbWZuOiAwMDAw
NDM1MQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjowNl0gICBnZm46IDAwMDA0MzUyICBt
Zm46IDAwMDA0MzUyDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjA2XSAgIGdmbjogMDAw
MDQzNTMgIG1mbjogMDAwMDQzNTMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MDZdICAg
Z2ZuOiAwMDAwNDM1NCAgbWZuOiAwMDAwNDM1NA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
MjowNl0gICBnZm46IDAwMDA0MzU1ICBtZm46IDAwMDA0MzU1DQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMyOjA2XSAgIGdmbjogMDAwMDQzNTYgIG1mbjogMDAwMDQzNTYNCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzI6MDZdICAgZ2ZuOiAwMDAwNDM1NyAgbWZuOiAwMDAwNDM1Nw0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjowNl0gICBnZm46IDAwMDA0MzU4ICBtZm46IDAw
MDA0MzU4DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjA2XSAgIGdmbjogMDAwMDQzNTkg
IG1mbjogMDAwMDQzNTkNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MDZdICAgZ2ZuOiAw
MDAwNDM1YSAgbWZuOiAwMDAwNDM1YQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjowNl0g
ICBnZm46IDAwMDA0MzViICBtZm46IDAwMDA0MzViDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMyOjA2XSAgIGdmbjogMDAwMDQzNWMgIG1mbjogMDAwMDQzNWMNCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzI6MDZdICAgZ2ZuOiAwMDAwNDM1ZCAgbWZuOiAwMDAwNDM1ZA0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMjowNl0gICBnZm46IDAwMDA0MzVlICBtZm46IDAwMDA0MzVl
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjA2XSAgIGdmbjogMDAwMDQzNWYgIG1mbjog
MDAwMDQzNWYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MDZdICAgZ2ZuOiAwMDAwNDM2
MCAgbWZuOiAwMDAwNDM2MA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjowNl0gICBnZm46
IDAwMDA0MzYxICBtZm46IDAwMDA0MzYxDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjA2
XSAgIGdmbjogMDAwMDQzNjIgIG1mbjogMDAwMDQzNjINCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzI6MDZdICAgZ2ZuOiAwMDAwNDM2MyAgbWZuOiAwMDAwNDM2Mw0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMjowNl0gICBnZm46IDAwMDA0MzY0ICBtZm46IDAwMDA0MzY0DQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMyOjA2XSAgIGdmbjogMDAwMDQzNjUgIG1mbjogMDAwMDQz
NjUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MDZdICAgZ2ZuOiAwMDAwNDM2NiAgbWZu
OiAwMDAwNDM2Ng0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjowNl0gICBnZm46IDAwMDA0
MzY3ICBtZm46IDAwMDA0MzY3DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjA2XSAgIGdm
bjogMDAwMDQzNjggIG1mbjogMDAwMDQzNjgNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6
MDZdICAgZ2ZuOiAwMDAwNDM2OSAgbWZuOiAwMDAwNDM2OQ0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMjowNl0gICBnZm46IDAwMDA0MzZhICBtZm46IDAwMDA0MzZhDQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMyOjA2XSAgIGdmbjogMDAwMDQzNmIgIG1mbjogMDAwMDQzNmINCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MDZdICAgZ2ZuOiAwMDAwNDM2YyAgbWZuOiAwMDAw
NDM2Yw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjowNl0gICBnZm46IDAwMDA0MzZkICBt
Zm46IDAwMDA0MzZkDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjA2XSAgIGdmbjogMDAw
MDQzNmUgIG1mbjogMDAwMDQzNmUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MDZdICAg
Z2ZuOiAwMDAwNDM2ZiAgbWZuOiAwMDAwNDM2Zg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
MjowNl0gICBnZm46IDAwMDA0MzcwICBtZm46IDAwMDA0MzcwDQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMyOjA2XSAgIGdmbjogMDAwMDQzNzEgIG1mbjogMDAwMDQzNzENCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzI6MDZdICAgZ2ZuOiAwMDAwNDM3MiAgbWZuOiAwMDAwNDM3Mg0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjowNl0gICBnZm46IDAwMDA0MzczICBtZm46IDAw
MDA0MzczDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjA2XSAgIGdmbjogMDAwMDQzNzQg
IG1mbjogMDAwMDQzNzQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MDZdICAgZ2ZuOiAw
MDAwNDM3NSAgbWZuOiAwMDAwNDM3NQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjowNl0g
ICBnZm46IDAwMDA0Mzc2ICBtZm46IDAwMDA0Mzc2DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMyOjA2XSAgIGdmbjogMDAwMDQzNzcgIG1mbjogMDAwMDQzNzcNCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzI6MDZdICAgZ2ZuOiAwMDAwNDM3OCAgbWZuOiAwMDAwNDM3OA0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMjowNl0gICBnZm46IDAwMDA0Mzc5ICBtZm46IDAwMDA0Mzc5
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjA2XSAgIGdmbjogMDAwMDQzN2EgIG1mbjog
MDAwMDQzN2ENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MDddICAgZ2ZuOiAwMDAwNDM3
YiAgbWZuOiAwMDAwNDM3Yg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjowN10gICBnZm46
IDAwMDA0MzdjICBtZm46IDAwMDA0MzdjDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjA3
XSAgIGdmbjogMDAwMDQzN2QgIG1mbjogMDAwMDQzN2QNCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzI6MDddICAgZ2ZuOiAwMDAwNDM3ZSAgbWZuOiAwMDAwNDM3ZQ0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMjowN10gICBnZm46IDAwMDA0MzdmICBtZm46IDAwMDA0MzdmDQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMyOjA3XSAgIGdmbjogMDAwMDQzODAgIG1mbjogMDAwMDQz
ODANCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MDddICAgZ2ZuOiAwMDAwNDM4MSAgbWZu
OiAwMDAwNDM4MQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjowN10gICBnZm46IDAwMDA0
MzgyICBtZm46IDAwMDA0MzgyDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjA3XSAgIGdm
bjogMDAwMDQzODMgIG1mbjogMDAwMDQzODMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6
MDddICAgZ2ZuOiAwMDAwNDM4NCAgbWZuOiAwMDAwNDM4NA0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMjowN10gICBnZm46IDAwMDA0Mzg1ICBtZm46IDAwMDA0Mzg1DQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMyOjA3XSAgIGdmbjogMDAwMDQzODYgIG1mbjogMDAwMDQzODYNCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MDddICAgZ2ZuOiAwMDAwNDM4NyAgbWZuOiAwMDAw
NDM4Nw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjowN10gICBnZm46IDAwMDA0Mzg4ICBt
Zm46IDAwMDA0Mzg4DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjA3XSAgIGdmbjogMDAw
MDQzODkgIG1mbjogMDAwMDQzODkNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MDddICAg
Z2ZuOiAwMDAwNDM4YSAgbWZuOiAwMDAwNDM4YQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
MjowN10gICBnZm46IDAwMDA0MzhiICBtZm46IDAwMDA0MzhiDQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMyOjA3XSAgIGdmbjogMDAwMDQzOGMgIG1mbjogMDAwMDQzOGMNCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzI6MDddICAgZ2ZuOiAwMDAwNDM4ZCAgbWZuOiAwMDAwNDM4ZA0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjowN10gICBnZm46IDAwMDA0MzhlICBtZm46IDAw
MDA0MzhlDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjA3XSAgIGdmbjogMDAwMDQzOGYg
IG1mbjogMDAwMDQzOGYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MDddICAgZ2ZuOiAw
MDAwNDM5MCAgbWZuOiAwMDAwNDM5MA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjowN10g
ICBnZm46IDAwMDA0MzkxICBtZm46IDAwMDA0MzkxDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMyOjA3XSAgIGdmbjogMDAwMDQzOTIgIG1mbjogMDAwMDQzOTINCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzI6MDddICAgZ2ZuOiAwMDAwNDM5MyAgbWZuOiAwMDAwNDM5Mw0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMjowN10gICBnZm46IDAwMDA0Mzk0ICBtZm46IDAwMDA0Mzk0
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjA3XSAgIGdmbjogMDAwMDQzOTUgIG1mbjog
MDAwMDQzOTUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MDddICAgZ2ZuOiAwMDAwNDM5
NiAgbWZuOiAwMDAwNDM5Ng0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjowN10gICBnZm46
IDAwMDA0Mzk3ICBtZm46IDAwMDA0Mzk3DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjA3
XSAgIGdmbjogMDAwMDQzOTggIG1mbjogMDAwMDQzOTgNCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzI6MDddICAgZ2ZuOiAwMDAwNDM5OSAgbWZuOiAwMDAwNDM5OQ0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMjowN10gICBnZm46IDAwMDA0MzlhICBtZm46IDAwMDA0MzlhDQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMyOjA3XSAgIGdmbjogMDAwMDQzOWIgIG1mbjogMDAwMDQz
OWINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MDddICAgZ2ZuOiAwMDAwNDM5YyAgbWZu
OiAwMDAwNDM5Yw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjowN10gICBnZm46IDAwMDA0
MzlkICBtZm46IDAwMDA0MzlkDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjA3XSAgIGdm
bjogMDAwMDQzOWUgIG1mbjogMDAwMDQzOWUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6
MDddICAgZ2ZuOiAwMDAwNDM5ZiAgbWZuOiAwMDAwNDM5Zg0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMjowN10gICBnZm46IDAwMDA0M2EwICBtZm46IDAwMDA0M2EwDQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMyOjA3XSAgIGdmbjogMDAwMDQzYTEgIG1mbjogMDAwMDQzYTENCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MDddICAgZ2ZuOiAwMDAwNDNhMiAgbWZuOiAwMDAw
NDNhMg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjowN10gICBnZm46IDAwMDA0M2EzICBt
Zm46IDAwMDA0M2EzDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjA3XSAgIGdmbjogMDAw
MDQzYTQgIG1mbjogMDAwMDQzYTQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MDddICAg
Z2ZuOiAwMDAwNDNhNSAgbWZuOiAwMDAwNDNhNQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
MjowN10gICBnZm46IDAwMDA0M2E2ICBtZm46IDAwMDA0M2E2DQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMyOjA3XSAgIGdmbjogMDAwMDQzYTcgIG1mbjogMDAwMDQzYTcNCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzI6MDddICAgZ2ZuOiAwMDAwNDNhOCAgbWZuOiAwMDAwNDNhOA0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjowN10gICBnZm46IDAwMDA0M2E5ICBtZm46IDAw
MDA0M2E5DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjA3XSAgIGdmbjogMDAwMDQzYWEg
IG1mbjogMDAwMDQzYWENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MDddICAgZ2ZuOiAw
MDAwNDNhYiAgbWZuOiAwMDAwNDNhYg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjowN10g
ICBnZm46IDAwMDA0M2FjICBtZm46IDAwMDA0M2FjDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMyOjA3XSAgIGdmbjogMDAwMDQzYWQgIG1mbjogMDAwMDQzYWQNCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzI6MDddICAgZ2ZuOiAwMDAwNDNhZSAgbWZuOiAwMDAwNDNhZQ0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMjowN10gICBnZm46IDAwMDA0M2FmICBtZm46IDAwMDA0M2Fm
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjA3XSAgIGdmbjogMDAwMDQzYjAgIG1mbjog
MDAwMDQzYjANCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MDddICAgZ2ZuOiAwMDAwNDNi
MSAgbWZuOiAwMDAwNDNiMQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjowN10gICBnZm46
IDAwMDA0M2IyICBtZm46IDAwMDA0M2IyDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjA3
XSAgIGdmbjogMDAwMDQzYjMgIG1mbjogMDAwMDQzYjMNCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzI6MDddICAgZ2ZuOiAwMDAwNDNiNCAgbWZuOiAwMDAwNDNiNA0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMjowN10gICBnZm46IDAwMDA0M2I1ICBtZm46IDAwMDA0M2I1DQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMyOjA3XSAgIGdmbjogMDAwMDQzYjYgIG1mbjogMDAwMDQz
YjYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MDddICAgZ2ZuOiAwMDAwNDNiNyAgbWZu
OiAwMDAwNDNiNw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjowN10gICBnZm46IDAwMDA0
M2I4ICBtZm46IDAwMDA0M2I4DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjA3XSAgIGdm
bjogMDAwMDQzYjkgIG1mbjogMDAwMDQzYjkNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6
MDddICAgZ2ZuOiAwMDAwNDNiYSAgbWZuOiAwMDAwNDNiYQ0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMjowOF0gICBnZm46IDAwMDA0M2JiICBtZm46IDAwMDA0M2JiDQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMyOjA4XSAgIGdmbjogMDAwMDQzYmMgIG1mbjogMDAwMDQzYmMNCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MDhdICAgZ2ZuOiAwMDAwNDNiZCAgbWZuOiAwMDAw
NDNiZA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjowOF0gICBnZm46IDAwMDA0M2JlICBt
Zm46IDAwMDA0M2JlDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjA4XSAgIGdmbjogMDAw
MDQzYmYgIG1mbjogMDAwMDQzYmYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MDhdICAg
Z2ZuOiAwMDAwNDNjMCAgbWZuOiAwMDAwNDNjMA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
MjowOF0gICBnZm46IDAwMDA0M2MxICBtZm46IDAwMDA0M2MxDQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMyOjA4XSAgIGdmbjogMDAwMDQzYzIgIG1mbjogMDAwMDQzYzINCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzI6MDhdICAgZ2ZuOiAwMDAwNDNjMyAgbWZuOiAwMDAwNDNjMw0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjowOF0gICBnZm46IDAwMDA0M2M0ICBtZm46IDAw
MDA0M2M0DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjA4XSAgIGdmbjogMDAwMDQzYzUg
IG1mbjogMDAwMDQzYzUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MDhdICAgZ2ZuOiAw
MDAwNDNjNiAgbWZuOiAwMDAwNDNjNg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjowOF0g
ICBnZm46IDAwMDA0M2M3ICBtZm46IDAwMDA0M2M3DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMyOjA4XSAgIGdmbjogMDAwMDQzYzggIG1mbjogMDAwMDQzYzgNCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzI6MDhdICAgZ2ZuOiAwMDAwNDNjOSAgbWZuOiAwMDAwNDNjOQ0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMjowOF0gICBnZm46IDAwMDA0M2NhICBtZm46IDAwMDA0M2Nh
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjA4XSAgIGdmbjogMDAwMDQzY2IgIG1mbjog
MDAwMDQzY2INCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MDhdICAgZ2ZuOiAwMDAwNDNj
YyAgbWZuOiAwMDAwNDNjYw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjowOF0gICBnZm46
IDAwMDA0M2NkICBtZm46IDAwMDA0M2NkDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjA4
XSAgIGdmbjogMDAwMDQzY2UgIG1mbjogMDAwMDQzY2UNCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzI6MDhdICAgZ2ZuOiAwMDAwNDNjZiAgbWZuOiAwMDAwNDNjZg0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMjowOF0gICBnZm46IDAwMDA0M2QwICBtZm46IDAwMDA0M2QwDQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMyOjA4XSAgIGdmbjogMDAwMDQzZDEgIG1mbjogMDAwMDQz
ZDENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MDhdICAgZ2ZuOiAwMDAwNDNkMiAgbWZu
OiAwMDAwNDNkMg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjowOF0gICBnZm46IDAwMDA0
M2QzICBtZm46IDAwMDA0M2QzDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjA4XSAgIGdm
bjogMDAwMDQzZDQgIG1mbjogMDAwMDQzZDQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6
MDhdICAgZ2ZuOiAwMDAwNDNkNSAgbWZuOiAwMDAwNDNkNQ0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMjowOF0gICBnZm46IDAwMDA0M2Q2ICBtZm46IDAwMDA0M2Q2DQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMyOjA4XSAgIGdmbjogMDAwMDQzZDcgIG1mbjogMDAwMDQzZDcNCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MDhdICAgZ2ZuOiAwMDAwNDNkOCAgbWZuOiAwMDAw
NDNkOA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjowOF0gICBnZm46IDAwMDA0M2Q5ICBt
Zm46IDAwMDA0M2Q5DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjA4XSAgIGdmbjogMDAw
MDQzZGEgIG1mbjogMDAwMDQzZGENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MDhdICAg
Z2ZuOiAwMDAwNDNkYiAgbWZuOiAwMDAwNDNkYg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
MjowOF0gICBnZm46IDAwMDA0M2RjICBtZm46IDAwMDA0M2RjDQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMyOjA4XSAgIGdmbjogMDAwMDQzZGQgIG1mbjogMDAwMDQzZGQNCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzI6MDhdICAgZ2ZuOiAwMDAwNDNkZSAgbWZuOiAwMDAwNDNkZQ0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjowOF0gICBnZm46IDAwMDA0M2RmICBtZm46IDAw
MDA0M2RmDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjA4XSAgIGdmbjogMDAwMDQzZTAg
IG1mbjogMDAwMDQzZTANCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MDhdICAgZ2ZuOiAw
MDAwNDNlMSAgbWZuOiAwMDAwNDNlMQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjowOF0g
ICBnZm46IDAwMDA0M2UyICBtZm46IDAwMDA0M2UyDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMyOjA4XSAgIGdmbjogMDAwMDQzZTMgIG1mbjogMDAwMDQzZTMNCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzI6MDhdICAgZ2ZuOiAwMDAwNDNlNCAgbWZuOiAwMDAwNDNlNA0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMjowOF0gICBnZm46IDAwMDA0M2U1ICBtZm46IDAwMDA0M2U1
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjA4XSAgIGdmbjogMDAwMDQzZTYgIG1mbjog
MDAwMDQzZTYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MDhdICAgZ2ZuOiAwMDAwNDNl
NyAgbWZuOiAwMDAwNDNlNw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjowOF0gICBnZm46
IDAwMDA0M2U4ICBtZm46IDAwMDA0M2U4DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjA4
XSAgIGdmbjogMDAwMDQzZTkgIG1mbjogMDAwMDQzZTkNCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzI6MDhdICAgZ2ZuOiAwMDAwNDNlYSAgbWZuOiAwMDAwNDNlYQ0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMjowOF0gICBnZm46IDAwMDA0M2ViICBtZm46IDAwMDA0M2ViDQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMyOjA4XSAgIGdmbjogMDAwMDQzZWMgIG1mbjogMDAwMDQz
ZWMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MDhdICAgZ2ZuOiAwMDAwNDNlZCAgbWZu
OiAwMDAwNDNlZA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjowOF0gICBnZm46IDAwMDA0
M2VlICBtZm46IDAwMDA0M2VlDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjA4XSAgIGdm
bjogMDAwMDQzZWYgIG1mbjogMDAwMDQzZWYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6
MDhdICAgZ2ZuOiAwMDAwNDNmMCAgbWZuOiAwMDAwNDNmMA0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMjowOF0gICBnZm46IDAwMDA0M2YxICBtZm46IDAwMDA0M2YxDQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMyOjA4XSAgIGdmbjogMDAwMDQzZjIgIG1mbjogMDAwMDQzZjINCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MDhdICAgZ2ZuOiAwMDAwNDNmMyAgbWZuOiAwMDAw
NDNmMw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjowOF0gICBnZm46IDAwMDA0M2Y0ICBt
Zm46IDAwMDA0M2Y0DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjA4XSAgIGdmbjogMDAw
MDQzZjUgIG1mbjogMDAwMDQzZjUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MDhdICAg
Z2ZuOiAwMDAwNDNmNiAgbWZuOiAwMDAwNDNmNg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
MjowOF0gICBnZm46IDAwMDA0M2Y3ICBtZm46IDAwMDA0M2Y3DQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMyOjA4XSAgIGdmbjogMDAwMDQzZjggIG1mbjogMDAwMDQzZjgNCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzI6MDhdICAgZ2ZuOiAwMDAwNDNmOSAgbWZuOiAwMDAwNDNmOQ0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjowOF0gICBnZm46IDAwMDA0M2ZhICBtZm46IDAw
MDA0M2ZhDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjA5XSAgIGdmbjogMDAwMDQzZmIg
IG1mbjogMDAwMDQzZmINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MDldICAgZ2ZuOiAw
MDAwNDNmYyAgbWZuOiAwMDAwNDNmYw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjowOV0g
ICBnZm46IDAwMDA0M2ZkICBtZm46IDAwMDA0M2ZkDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMyOjA5XSAgIGdmbjogMDAwMDQzZmUgIG1mbjogMDAwMDQzZmUNCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzI6MDldICAgZ2ZuOiAwMDAwNDNmZiAgbWZuOiAwMDAwNDNmZg0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMjowOV0gICBnZm46IDAwMDA0NDAwICBtZm46IDAwMDA0NDAw
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjA5XSAgIGdmbjogMDAwMDQ0MDEgIG1mbjog
MDAwMDQ0MDENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MDldICAgZ2ZuOiAwMDAwNDQw
MiAgbWZuOiAwMDAwNDQwMg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjowOV0gICBnZm46
IDAwMDA0NDAzICBtZm46IDAwMDA0NDAzDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjA5
XSAgIGdmbjogMDAwMDQ0MDQgIG1mbjogMDAwMDQ0MDQNCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzI6MDldICAgZ2ZuOiAwMDAwNDQwNSAgbWZuOiAwMDAwNDQwNQ0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMjowOV0gICBnZm46IDAwMDA0NDA2ICBtZm46IDAwMDA0NDA2DQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMyOjA5XSAgIGdmbjogMDAwMDQ0MDcgIG1mbjogMDAwMDQ0
MDcNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MDldICAgZ2ZuOiAwMDAwNDQwOCAgbWZu
OiAwMDAwNDQwOA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjowOV0gICBnZm46IDAwMDA0
NDA5ICBtZm46IDAwMDA0NDA5DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjA5XSAgIGdm
bjogMDAwMDQ0MGEgIG1mbjogMDAwMDQ0MGENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6
MDldICAgZ2ZuOiAwMDAwNDQwYiAgbWZuOiAwMDAwNDQwYg0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMjowOV0gICBnZm46IDAwMDA0NDBjICBtZm46IDAwMDA0NDBjDQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMyOjA5XSAgIGdmbjogMDAwMDQ0MGQgIG1mbjogMDAwMDQ0MGQNCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MDldICAgZ2ZuOiAwMDAwNDQwZSAgbWZuOiAwMDAw
NDQwZQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjowOV0gICBnZm46IDAwMDA0NDBmICBt
Zm46IDAwMDA0NDBmDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjA5XSAgIGdmbjogMDAw
MDQ0MTAgIG1mbjogMDAwMDQ0MTANCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MDldICAg
Z2ZuOiAwMDAwNDQxMSAgbWZuOiAwMDAwNDQxMQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
MjowOV0gICBnZm46IDAwMDA0NDEyICBtZm46IDAwMDA0NDEyDQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMyOjA5XSAgIGdmbjogMDAwMDQ0MTMgIG1mbjogMDAwMDQ0MTMNCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzI6MDldICAgZ2ZuOiAwMDAwNDQxNCAgbWZuOiAwMDAwNDQxNA0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjowOV0gICBnZm46IDAwMDA0NDE1ICBtZm46IDAw
MDA0NDE1DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjA5XSAgIGdmbjogMDAwMDQ0MTYg
IG1mbjogMDAwMDQ0MTYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MDldICAgZ2ZuOiAw
MDAwNDQxNyAgbWZuOiAwMDAwNDQxNw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjowOV0g
ICBnZm46IDAwMDA0NDE4ICBtZm46IDAwMDA0NDE4DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMyOjA5XSAgIGdmbjogMDAwMDQ0MTkgIG1mbjogMDAwMDQ0MTkNCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzI6MDldICAgZ2ZuOiAwMDAwNDQxYSAgbWZuOiAwMDAwNDQxYQ0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMjowOV0gICBnZm46IDAwMDA0NDFiICBtZm46IDAwMDA0NDFi
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjA5XSAgIGdmbjogMDAwMDQ0MWMgIG1mbjog
MDAwMDQ0MWMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MDldICAgZ2ZuOiAwMDAwNDQx
ZCAgbWZuOiAwMDAwNDQxZA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjowOV0gICBnZm46
IDAwMDA0NDFlICBtZm46IDAwMDA0NDFlDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjA5
XSAgIGdmbjogMDAwMDQ0MWYgIG1mbjogMDAwMDQ0MWYNCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzI6MDldICAgZ2ZuOiAwMDAwNDQyMCAgbWZuOiAwMDAwNDQyMA0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMjowOV0gICBnZm46IDAwMDA0NDIxICBtZm46IDAwMDA0NDIxDQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMyOjA5XSAgIGdmbjogMDAwMDQ0MjIgIG1mbjogMDAwMDQ0
MjINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MDldICAgZ2ZuOiAwMDAwNDQyMyAgbWZu
OiAwMDAwNDQyMw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjowOV0gICBnZm46IDAwMDA0
NDI0ICBtZm46IDAwMDA0NDI0DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjA5XSAgIGdm
bjogMDAwMDQ0MjUgIG1mbjogMDAwMDQ0MjUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6
MDldICAgZ2ZuOiAwMDAwNDQyNiAgbWZuOiAwMDAwNDQyNg0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMjowOV0gICBnZm46IDAwMDA0NDI3ICBtZm46IDAwMDA0NDI3DQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMyOjA5XSAgIGdmbjogMDAwMDQ0MjggIG1mbjogMDAwMDQ0MjgNCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MDldICAgZ2ZuOiAwMDAwNDQyOSAgbWZuOiAwMDAw
NDQyOQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjowOV0gICBnZm46IDAwMDA0NDJhICBt
Zm46IDAwMDA0NDJhDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjA5XSAgIGdmbjogMDAw
MDQ0MmIgIG1mbjogMDAwMDQ0MmINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MDldICAg
Z2ZuOiAwMDAwNDQyYyAgbWZuOiAwMDAwNDQyYw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
MjowOV0gICBnZm46IDAwMDA0NDJkICBtZm46IDAwMDA0NDJkDQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMyOjA5XSAgIGdmbjogMDAwMDQ0MmUgIG1mbjogMDAwMDQ0MmUNCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzI6MDldICAgZ2ZuOiAwMDAwNDQyZiAgbWZuOiAwMDAwNDQyZg0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjowOV0gICBnZm46IDAwMDA0NDMwICBtZm46IDAw
MDA0NDMwDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjA5XSAgIGdmbjogMDAwMDQ0MzEg
IG1mbjogMDAwMDQ0MzENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MDldICAgZ2ZuOiAw
MDAwNDQzMiAgbWZuOiAwMDAwNDQzMg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjowOV0g
ICBnZm46IDAwMDA0NDMzICBtZm46IDAwMDA0NDMzDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMyOjA5XSAgIGdmbjogMDAwMDQ0MzQgIG1mbjogMDAwMDQ0MzQNCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzI6MDldICAgZ2ZuOiAwMDAwNDQzNSAgbWZuOiAwMDAwNDQzNQ0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMjowOV0gICBnZm46IDAwMDA0NDM2ICBtZm46IDAwMDA0NDM2
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjA5XSAgIGdmbjogMDAwMDQ0MzcgIG1mbjog
MDAwMDQ0MzcNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MDldICAgZ2ZuOiAwMDAwNDQz
OCAgbWZuOiAwMDAwNDQzOA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjowOV0gICBnZm46
IDAwMDA0NDM5ICBtZm46IDAwMDA0NDM5DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjA5
XSAgIGdmbjogMDAwMDQ0M2EgIG1mbjogMDAwMDQ0M2ENCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzI6MTBdICAgZ2ZuOiAwMDAwNDQzYiAgbWZuOiAwMDAwNDQzYg0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMjoxMF0gICBnZm46IDAwMDA0NDNjICBtZm46IDAwMDA0NDNjDQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMyOjEwXSAgIGdmbjogMDAwMDQ0M2QgIG1mbjogMDAwMDQ0
M2QNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MTBdICAgZ2ZuOiAwMDAwNDQzZSAgbWZu
OiAwMDAwNDQzZQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoxMF0gICBnZm46IDAwMDA0
NDNmICBtZm46IDAwMDA0NDNmDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjEwXSAgIGdm
bjogMDAwMDQ0NDAgIG1mbjogMDAwMDQ0NDANCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6
MTBdICAgZ2ZuOiAwMDAwNDQ0MSAgbWZuOiAwMDAwNDQ0MQ0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMjoxMF0gICBnZm46IDAwMDA0NDQyICBtZm46IDAwMDA0NDQyDQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMyOjEwXSAgIGdmbjogMDAwMDQ0NDMgIG1mbjogMDAwMDQ0NDMNCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MTBdICAgZ2ZuOiAwMDAwNDQ0NCAgbWZuOiAwMDAw
NDQ0NA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoxMF0gICBnZm46IDAwMDA0NDQ1ICBt
Zm46IDAwMDA0NDQ1DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjEwXSAgIGdmbjogMDAw
MDQ0NDYgIG1mbjogMDAwMDQ0NDYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MTBdICAg
Z2ZuOiAwMDAwNDQ0NyAgbWZuOiAwMDAwNDQ0Nw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
MjoxMF0gICBnZm46IDAwMDA0NDQ4ICBtZm46IDAwMDA0NDQ4DQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMyOjEwXSAgIGdmbjogMDAwMDQ0NDkgIG1mbjogMDAwMDQ0NDkNCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzI6MTBdICAgZ2ZuOiAwMDAwNDQ0YSAgbWZuOiAwMDAwNDQ0YQ0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoxMF0gICBnZm46IDAwMDA0NDRiICBtZm46IDAw
MDA0NDRiDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjEwXSAgIGdmbjogMDAwMDQ0NGMg
IG1mbjogMDAwMDQ0NGMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MTBdICAgZ2ZuOiAw
MDAwNDQ0ZCAgbWZuOiAwMDAwNDQ0ZA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoxMF0g
ICBnZm46IDAwMDA0NDRlICBtZm46IDAwMDA0NDRlDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMyOjEwXSAgIGdmbjogMDAwMDQ0NGYgIG1mbjogMDAwMDQ0NGYNCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzI6MTBdICAgZ2ZuOiAwMDAwNDQ1MCAgbWZuOiAwMDAwNDQ1MA0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMjoxMF0gICBnZm46IDAwMDA0NDUxICBtZm46IDAwMDA0NDUx
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjEwXSAgIGdmbjogMDAwMDQ0NTIgIG1mbjog
MDAwMDQ0NTINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MTBdICAgZ2ZuOiAwMDAwNDQ1
MyAgbWZuOiAwMDAwNDQ1Mw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoxMF0gICBnZm46
IDAwMDA0NDU0ICBtZm46IDAwMDA0NDU0DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjEw
XSAgIGdmbjogMDAwMDQ0NTUgIG1mbjogMDAwMDQ0NTUNCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzI6MTBdICAgZ2ZuOiAwMDAwNDQ1NiAgbWZuOiAwMDAwNDQ1Ng0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMjoxMF0gICBnZm46IDAwMDA0NDU3ICBtZm46IDAwMDA0NDU3DQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMyOjEwXSAgIGdmbjogMDAwMDQ0NTggIG1mbjogMDAwMDQ0
NTgNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MTBdICAgZ2ZuOiAwMDAwNDQ1OSAgbWZu
OiAwMDAwNDQ1OQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoxMF0gICBnZm46IDAwMDA0
NDVhICBtZm46IDAwMDA0NDVhDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjEwXSAgIGdm
bjogMDAwMDQ0NWIgIG1mbjogMDAwMDQ0NWINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6
MTBdICAgZ2ZuOiAwMDAwNDQ1YyAgbWZuOiAwMDAwNDQ1Yw0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMjoxMF0gICBnZm46IDAwMDA0NDVkICBtZm46IDAwMDA0NDVkDQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMyOjEwXSAgIGdmbjogMDAwMDQ0NWUgIG1mbjogMDAwMDQ0NWUNCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MTBdICAgZ2ZuOiAwMDAwNDQ1ZiAgbWZuOiAwMDAw
NDQ1Zg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoxMF0gICBnZm46IDAwMDA0NDYwICBt
Zm46IDAwMDA0NDYwDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjEwXSAgIGdmbjogMDAw
MDQ0NjEgIG1mbjogMDAwMDQ0NjENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MTBdICAg
Z2ZuOiAwMDAwNDQ2MiAgbWZuOiAwMDAwNDQ2Mg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
MjoxMF0gICBnZm46IDAwMDA0NDYzICBtZm46IDAwMDA0NDYzDQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMyOjEwXSAgIGdmbjogMDAwMDQ0NjQgIG1mbjogMDAwMDQ0NjQNCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzI6MTBdICAgZ2ZuOiAwMDAwNDQ2NSAgbWZuOiAwMDAwNDQ2NQ0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoxMF0gICBnZm46IDAwMDA0NDY2ICBtZm46IDAw
MDA0NDY2DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjEwXSAgIGdmbjogMDAwMDQ0Njcg
IG1mbjogMDAwMDQ0NjcNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MTBdICAgZ2ZuOiAw
MDAwNDQ2OCAgbWZuOiAwMDAwNDQ2OA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoxMF0g
ICBnZm46IDAwMDA0NDY5ICBtZm46IDAwMDA0NDY5DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMyOjEwXSAgIGdmbjogMDAwMDQ0NmEgIG1mbjogMDAwMDQ0NmENCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzI6MTBdICAgZ2ZuOiAwMDAwNDQ2YiAgbWZuOiAwMDAwNDQ2Yg0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMjoxMF0gICBnZm46IDAwMDA0NDZjICBtZm46IDAwMDA0NDZj
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjEwXSAgIGdmbjogMDAwMDQ0NmQgIG1mbjog
MDAwMDQ0NmQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MTBdICAgZ2ZuOiAwMDAwNDQ2
ZSAgbWZuOiAwMDAwNDQ2ZQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoxMF0gICBnZm46
IDAwMDA0NDZmICBtZm46IDAwMDA0NDZmDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjEw
XSAgIGdmbjogMDAwMDQ0NzAgIG1mbjogMDAwMDQ0NzANCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzI6MTBdICAgZ2ZuOiAwMDAwNDQ3MSAgbWZuOiAwMDAwNDQ3MQ0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMjoxMF0gICBnZm46IDAwMDA0NDcyICBtZm46IDAwMDA0NDcyDQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMyOjEwXSAgIGdmbjogMDAwMDQ0NzMgIG1mbjogMDAwMDQ0
NzMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MTBdICAgZ2ZuOiAwMDAwNDQ3NCAgbWZu
OiAwMDAwNDQ3NA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoxMF0gICBnZm46IDAwMDA0
NDc1ICBtZm46IDAwMDA0NDc1DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjEwXSAgIGdm
bjogMDAwMDQ0NzYgIG1mbjogMDAwMDQ0NzYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6
MTBdICAgZ2ZuOiAwMDAwNDQ3NyAgbWZuOiAwMDAwNDQ3Nw0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMjoxMF0gICBnZm46IDAwMDA0NDc4ICBtZm46IDAwMDA0NDc4DQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMyOjEwXSAgIGdmbjogMDAwMDQ0NzkgIG1mbjogMDAwMDQ0NzkNCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MTBdICAgZ2ZuOiAwMDAwNDQ3YSAgbWZuOiAwMDAw
NDQ3YQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoxMV0gICBnZm46IDAwMDA0NDdiICBt
Zm46IDAwMDA0NDdiDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjExXSAgIGdmbjogMDAw
MDQ0N2MgIG1mbjogMDAwMDQ0N2MNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MTFdICAg
Z2ZuOiAwMDAwNDQ3ZCAgbWZuOiAwMDAwNDQ3ZA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
MjoxMV0gICBnZm46IDAwMDA0NDdlICBtZm46IDAwMDA0NDdlDQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMyOjExXSAgIGdmbjogMDAwMDQ0N2YgIG1mbjogMDAwMDQ0N2YNCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzI6MTFdICAgZ2ZuOiAwMDAwNDQ4MCAgbWZuOiAwMDAwNDQ4MA0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoxMV0gICBnZm46IDAwMDA0NDgxICBtZm46IDAw
MDA0NDgxDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjExXSAgIGdmbjogMDAwMDQ0ODIg
IG1mbjogMDAwMDQ0ODINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MTFdICAgZ2ZuOiAw
MDAwNDQ4MyAgbWZuOiAwMDAwNDQ4Mw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoxMV0g
ICBnZm46IDAwMDA0NDg0ICBtZm46IDAwMDA0NDg0DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMyOjExXSAgIGdmbjogMDAwMDQ0ODUgIG1mbjogMDAwMDQ0ODUNCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzI6MTFdICAgZ2ZuOiAwMDAwNDQ4NiAgbWZuOiAwMDAwNDQ4Ng0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMjoxMV0gICBnZm46IDAwMDA0NDg3ICBtZm46IDAwMDA0NDg3
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjExXSAgIGdmbjogMDAwMDQ0ODggIG1mbjog
MDAwMDQ0ODgNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MTFdICAgZ2ZuOiAwMDAwNDQ4
OSAgbWZuOiAwMDAwNDQ4OQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoxMV0gICBnZm46
IDAwMDA0NDhhICBtZm46IDAwMDA0NDhhDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjEx
XSAgIGdmbjogMDAwMDQ0OGIgIG1mbjogMDAwMDQ0OGINCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzI6MTFdICAgZ2ZuOiAwMDAwNDQ4YyAgbWZuOiAwMDAwNDQ4Yw0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMjoxMV0gICBnZm46IDAwMDA0NDhkICBtZm46IDAwMDA0NDhkDQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMyOjExXSAgIGdmbjogMDAwMDQ0OGUgIG1mbjogMDAwMDQ0
OGUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MTFdICAgZ2ZuOiAwMDAwNDQ4ZiAgbWZu
OiAwMDAwNDQ4Zg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoxMV0gICBnZm46IDAwMDA0
NDkwICBtZm46IDAwMDA0NDkwDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjExXSAgIGdm
bjogMDAwMDQ0OTEgIG1mbjogMDAwMDQ0OTENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6
MTFdICAgZ2ZuOiAwMDAwNDQ5MiAgbWZuOiAwMDAwNDQ5Mg0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMjoxMV0gICBnZm46IDAwMDA0NDkzICBtZm46IDAwMDA0NDkzDQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMyOjExXSAgIGdmbjogMDAwMDQ0OTQgIG1mbjogMDAwMDQ0OTQNCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MTFdICAgZ2ZuOiAwMDAwNDQ5NSAgbWZuOiAwMDAw
NDQ5NQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoxMV0gICBnZm46IDAwMDA0NDk2ICBt
Zm46IDAwMDA0NDk2DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjExXSAgIGdmbjogMDAw
MDQ0OTcgIG1mbjogMDAwMDQ0OTcNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MTFdICAg
Z2ZuOiAwMDAwNDQ5OCAgbWZuOiAwMDAwNDQ5OA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
MjoxMV0gICBnZm46IDAwMDA0NDk5ICBtZm46IDAwMDA0NDk5DQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMyOjExXSAgIGdmbjogMDAwMDQ0OWEgIG1mbjogMDAwMDQ0OWENCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzI6MTFdICAgZ2ZuOiAwMDAwNDQ5YiAgbWZuOiAwMDAwNDQ5Yg0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoxMV0gICBnZm46IDAwMDA0NDljICBtZm46IDAw
MDA0NDljDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjExXSAgIGdmbjogMDAwMDQ0OWQg
IG1mbjogMDAwMDQ0OWQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MTFdICAgZ2ZuOiAw
MDAwNDQ5ZSAgbWZuOiAwMDAwNDQ5ZQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoxMV0g
ICBnZm46IDAwMDA0NDlmICBtZm46IDAwMDA0NDlmDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMyOjExXSAgIGdmbjogMDAwMDQ0YTAgIG1mbjogMDAwMDQ0YTANCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzI6MTFdICAgZ2ZuOiAwMDAwNDRhMSAgbWZuOiAwMDAwNDRhMQ0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMjoxMV0gICBnZm46IDAwMDA0NGEyICBtZm46IDAwMDA0NGEy
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjExXSAgIGdmbjogMDAwMDQ0YTMgIG1mbjog
MDAwMDQ0YTMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MTFdICAgZ2ZuOiAwMDAwNDRh
NCAgbWZuOiAwMDAwNDRhNA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoxMV0gICBnZm46
IDAwMDA0NGE1ICBtZm46IDAwMDA0NGE1DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjEx
XSAgIGdmbjogMDAwMDQ0YTYgIG1mbjogMDAwMDQ0YTYNCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzI6MTFdICAgZ2ZuOiAwMDAwNDRhNyAgbWZuOiAwMDAwNDRhNw0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMjoxMV0gICBnZm46IDAwMDA0NGE4ICBtZm46IDAwMDA0NGE4DQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMyOjExXSAgIGdmbjogMDAwMDQ0YTkgIG1mbjogMDAwMDQ0
YTkNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MTFdICAgZ2ZuOiAwMDAwNDRhYSAgbWZu
OiAwMDAwNDRhYQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoxMV0gICBnZm46IDAwMDA0
NGFiICBtZm46IDAwMDA0NGFiDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjExXSAgIGdm
bjogMDAwMDQ0YWMgIG1mbjogMDAwMDQ0YWMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6
MTFdICAgZ2ZuOiAwMDAwNDRhZCAgbWZuOiAwMDAwNDRhZA0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMjoxMV0gICBnZm46IDAwMDA0NGFlICBtZm46IDAwMDA0NGFlDQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMyOjExXSAgIGdmbjogMDAwMDQ0YWYgIG1mbjogMDAwMDQ0YWYNCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MTFdICAgZ2ZuOiAwMDAwNDRiMCAgbWZuOiAwMDAw
NDRiMA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoxMV0gICBnZm46IDAwMDA0NGIxICBt
Zm46IDAwMDA0NGIxDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjExXSAgIGdmbjogMDAw
MDQ0YjIgIG1mbjogMDAwMDQ0YjINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MTFdICAg
Z2ZuOiAwMDAwNDRiMyAgbWZuOiAwMDAwNDRiMw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
MjoxMV0gICBnZm46IDAwMDA0NGI0ICBtZm46IDAwMDA0NGI0DQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMyOjExXSAgIGdmbjogMDAwMDQ0YjUgIG1mbjogMDAwMDQ0YjUNCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzI6MTFdICAgZ2ZuOiAwMDAwNDRiNiAgbWZuOiAwMDAwNDRiNg0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoxMV0gICBnZm46IDAwMDA0NGI3ICBtZm46IDAw
MDA0NGI3DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjExXSAgIGdmbjogMDAwMDQ0Yjgg
IG1mbjogMDAwMDQ0YjgNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MTFdICAgZ2ZuOiAw
MDAwNDRiOSAgbWZuOiAwMDAwNDRiOQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoxMV0g
ICBnZm46IDAwMDA0NGJhICBtZm46IDAwMDA0NGJhDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMyOjEyXSAgIGdmbjogMDAwMDQ0YmIgIG1mbjogMDAwMDQ0YmINCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzI6MTJdICAgZ2ZuOiAwMDAwNDRiYyAgbWZuOiAwMDAwNDRiYw0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMjoxMl0gICBnZm46IDAwMDA0NGJkICBtZm46IDAwMDA0NGJk
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjEyXSAgIGdmbjogMDAwMDQ0YmUgIG1mbjog
MDAwMDQ0YmUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MTJdICAgZ2ZuOiAwMDAwNDRi
ZiAgbWZuOiAwMDAwNDRiZg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoxMl0gICBnZm46
IDAwMDA0NGMwICBtZm46IDAwMDA0NGMwDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjEy
XSAgIGdmbjogMDAwMDQ0YzEgIG1mbjogMDAwMDQ0YzENCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzI6MTJdICAgZ2ZuOiAwMDAwNDRjMiAgbWZuOiAwMDAwNDRjMg0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMjoxMl0gICBnZm46IDAwMDA0NGMzICBtZm46IDAwMDA0NGMzDQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMyOjEyXSAgIGdmbjogMDAwMDQ0YzQgIG1mbjogMDAwMDQ0
YzQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MTJdICAgZ2ZuOiAwMDAwNDRjNSAgbWZu
OiAwMDAwNDRjNQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoxMl0gICBnZm46IDAwMDA0
NGM2ICBtZm46IDAwMDA0NGM2DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjEyXSAgIGdm
bjogMDAwMDQ0YzcgIG1mbjogMDAwMDQ0YzcNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6
MTJdICAgZ2ZuOiAwMDAwNDRjOCAgbWZuOiAwMDAwNDRjOA0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMjoxMl0gICBnZm46IDAwMDA0NGM5ICBtZm46IDAwMDA0NGM5DQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMyOjEyXSAgIGdmbjogMDAwMDQ0Y2EgIG1mbjogMDAwMDQ0Y2ENCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MTJdICAgZ2ZuOiAwMDAwNDRjYiAgbWZuOiAwMDAw
NDRjYg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoxMl0gICBnZm46IDAwMDA0NGNjICBt
Zm46IDAwMDA0NGNjDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjEyXSAgIGdmbjogMDAw
MDQ0Y2QgIG1mbjogMDAwMDQ0Y2QNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MTJdICAg
Z2ZuOiAwMDAwNDRjZSAgbWZuOiAwMDAwNDRjZQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
MjoxMl0gICBnZm46IDAwMDA0NGNmICBtZm46IDAwMDA0NGNmDQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMyOjEyXSAgIGdmbjogMDAwMDQ0ZDAgIG1mbjogMDAwMDQ0ZDANCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzI6MTJdICAgZ2ZuOiAwMDAwNDRkMSAgbWZuOiAwMDAwNDRkMQ0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoxMl0gICBnZm46IDAwMDA0NGQyICBtZm46IDAw
MDA0NGQyDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjEyXSAgIGdmbjogMDAwMDQ0ZDMg
IG1mbjogMDAwMDQ0ZDMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MTJdICAgZ2ZuOiAw
MDAwNDRkNCAgbWZuOiAwMDAwNDRkNA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoxMl0g
ICBnZm46IDAwMDA0NGQ1ICBtZm46IDAwMDA0NGQ1DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMyOjEyXSAgIGdmbjogMDAwMDQ0ZDYgIG1mbjogMDAwMDQ0ZDYNCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzI6MTJdICAgZ2ZuOiAwMDAwNDRkNyAgbWZuOiAwMDAwNDRkNw0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMjoxMl0gICBnZm46IDAwMDA0NGQ4ICBtZm46IDAwMDA0NGQ4
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjEyXSAgIGdmbjogMDAwMDQ0ZDkgIG1mbjog
MDAwMDQ0ZDkNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MTJdICAgZ2ZuOiAwMDAwNDRk
YSAgbWZuOiAwMDAwNDRkYQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoxMl0gICBnZm46
IDAwMDA0NGRiICBtZm46IDAwMDA0NGRiDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjEy
XSAgIGdmbjogMDAwMDQ0ZGMgIG1mbjogMDAwMDQ0ZGMNCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzI6MTJdICAgZ2ZuOiAwMDAwNDRkZCAgbWZuOiAwMDAwNDRkZA0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMjoxMl0gICBnZm46IDAwMDA0NGRlICBtZm46IDAwMDA0NGRlDQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMyOjEyXSAgIGdmbjogMDAwMDQ0ZGYgIG1mbjogMDAwMDQ0
ZGYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MTJdICAgZ2ZuOiAwMDAwNDRlMCAgbWZu
OiAwMDAwNDRlMA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoxMl0gICBnZm46IDAwMDA0
NGUxICBtZm46IDAwMDA0NGUxDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjEyXSAgIGdm
bjogMDAwMDQ0ZTIgIG1mbjogMDAwMDQ0ZTINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6
MTJdICAgZ2ZuOiAwMDAwNDRlMyAgbWZuOiAwMDAwNDRlMw0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMjoxMl0gICBnZm46IDAwMDA0NGU0ICBtZm46IDAwMDA0NGU0DQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMyOjEyXSAgIGdmbjogMDAwMDQ0ZTUgIG1mbjogMDAwMDQ0ZTUNCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MTJdICAgZ2ZuOiAwMDAwNDRlNiAgbWZuOiAwMDAw
NDRlNg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoxMl0gICBnZm46IDAwMDA0NGU3ICBt
Zm46IDAwMDA0NGU3DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjEyXSAgIGdmbjogMDAw
MDQ0ZTggIG1mbjogMDAwMDQ0ZTgNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MTJdICAg
Z2ZuOiAwMDAwNDRlOSAgbWZuOiAwMDAwNDRlOQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
MjoxMl0gICBnZm46IDAwMDA0NGVhICBtZm46IDAwMDA0NGVhDQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMyOjEyXSAgIGdmbjogMDAwMDQ0ZWIgIG1mbjogMDAwMDQ0ZWINCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzI6MTJdICAgZ2ZuOiAwMDAwNDRlYyAgbWZuOiAwMDAwNDRlYw0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoxMl0gICBnZm46IDAwMDA0NGVkICBtZm46IDAw
MDA0NGVkDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjEyXSAgIGdmbjogMDAwMDQ0ZWUg
IG1mbjogMDAwMDQ0ZWUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MTJdICAgZ2ZuOiAw
MDAwNDRlZiAgbWZuOiAwMDAwNDRlZg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoxMl0g
ICBnZm46IDAwMDA0NGYwICBtZm46IDAwMDA0NGYwDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMyOjEyXSAgIGdmbjogMDAwMDQ0ZjEgIG1mbjogMDAwMDQ0ZjENCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzI6MTJdICAgZ2ZuOiAwMDAwNDRmMiAgbWZuOiAwMDAwNDRmMg0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMjoxMl0gICBnZm46IDAwMDA0NGYzICBtZm46IDAwMDA0NGYz
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjEyXSAgIGdmbjogMDAwMDQ0ZjQgIG1mbjog
MDAwMDQ0ZjQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MTJdICAgZ2ZuOiAwMDAwNDRm
NSAgbWZuOiAwMDAwNDRmNQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoxMl0gICBnZm46
IDAwMDA0NGY2ICBtZm46IDAwMDA0NGY2DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjEy
XSAgIGdmbjogMDAwMDQ0ZjcgIG1mbjogMDAwMDQ0ZjcNCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzI6MTJdICAgZ2ZuOiAwMDAwNDRmOCAgbWZuOiAwMDAwNDRmOA0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMjoxMl0gICBnZm46IDAwMDA0NGY5ICBtZm46IDAwMDA0NGY5DQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMyOjEyXSAgIGdmbjogMDAwMDQ0ZmEgIG1mbjogMDAwMDQ0
ZmENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MTJdICAgZ2ZuOiAwMDAwNDRmYiAgbWZu
OiAwMDAwNDRmYg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoxM10gICBnZm46IDAwMDA0
NGZjICBtZm46IDAwMDA0NGZjDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjEzXSAgIGdm
bjogMDAwMDQ0ZmQgIG1mbjogMDAwMDQ0ZmQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6
MTNdICAgZ2ZuOiAwMDAwNDRmZSAgbWZuOiAwMDAwNDRmZQ0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMjoxM10gICBnZm46IDAwMDA0NGZmICBtZm46IDAwMDA0NGZmDQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMyOjEzXSAgIGdmbjogMDAwMDQ1MDAgIG1mbjogMDAwMDQ1MDANCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MTNdICAgZ2ZuOiAwMDAwNDUwMSAgbWZuOiAwMDAw
NDUwMQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoxM10gICBnZm46IDAwMDA0NTAyICBt
Zm46IDAwMDA0NTAyDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjEzXSAgIGdmbjogMDAw
MDQ1MDMgIG1mbjogMDAwMDQ1MDMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MTNdICAg
Z2ZuOiAwMDAwNDUwNCAgbWZuOiAwMDAwNDUwNA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
MjoxM10gICBnZm46IDAwMDA0NTA1ICBtZm46IDAwMDA0NTA1DQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMyOjEzXSAgIGdmbjogMDAwMDQ1MDYgIG1mbjogMDAwMDQ1MDYNCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzI6MTNdICAgZ2ZuOiAwMDAwNDUwNyAgbWZuOiAwMDAwNDUwNw0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoxM10gICBnZm46IDAwMDA0NTA4ICBtZm46IDAw
MDA0NTA4DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjEzXSAgIGdmbjogMDAwMDQ1MDkg
IG1mbjogMDAwMDQ1MDkNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MTNdICAgZ2ZuOiAw
MDAwNDUwYSAgbWZuOiAwMDAwNDUwYQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoxM10g
ICBnZm46IDAwMDA0NTBiICBtZm46IDAwMDA0NTBiDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMyOjEzXSAgIGdmbjogMDAwMDQ1MGMgIG1mbjogMDAwMDQ1MGMNCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzI6MTNdICAgZ2ZuOiAwMDAwNDUwZCAgbWZuOiAwMDAwNDUwZA0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMjoxM10gICBnZm46IDAwMDA0NTBlICBtZm46IDAwMDA0NTBl
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjEzXSAgIGdmbjogMDAwMDQ1MGYgIG1mbjog
MDAwMDQ1MGYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MTNdICAgZ2ZuOiAwMDAwNDUx
MCAgbWZuOiAwMDAwNDUxMA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoxM10gICBnZm46
IDAwMDA0NTExICBtZm46IDAwMDA0NTExDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjEz
XSAgIGdmbjogMDAwMDQ1MTIgIG1mbjogMDAwMDQ1MTINCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzI6MTNdICAgZ2ZuOiAwMDAwNDUxMyAgbWZuOiAwMDAwNDUxMw0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMjoxM10gICBnZm46IDAwMDA0NTE0ICBtZm46IDAwMDA0NTE0DQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMyOjEzXSAgIGdmbjogMDAwMDQ1MTUgIG1mbjogMDAwMDQ1
MTUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MTNdICAgZ2ZuOiAwMDAwNDUxNiAgbWZu
OiAwMDAwNDUxNg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoxM10gICBnZm46IDAwMDA0
NTE3ICBtZm46IDAwMDA0NTE3DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjEzXSAgIGdm
bjogMDAwMDQ1MTggIG1mbjogMDAwMDQ1MTgNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6
MTNdICAgZ2ZuOiAwMDAwNDUxOSAgbWZuOiAwMDAwNDUxOQ0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMjoxM10gICBnZm46IDAwMDA0NTFhICBtZm46IDAwMDA0NTFhDQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMyOjEzXSAgIGdmbjogMDAwMDQ1MWIgIG1mbjogMDAwMDQ1MWINCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MTNdICAgZ2ZuOiAwMDAwNDUxYyAgbWZuOiAwMDAw
NDUxYw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoxM10gICBnZm46IDAwMDA0NTFkICBt
Zm46IDAwMDA0NTFkDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjEzXSAgIGdmbjogMDAw
MDQ1MWUgIG1mbjogMDAwMDQ1MWUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MTNdICAg
Z2ZuOiAwMDAwNDUxZiAgbWZuOiAwMDAwNDUxZg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
MjoxM10gICBnZm46IDAwMDA0NTIwICBtZm46IDAwMDA0NTIwDQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMyOjEzXSAgIGdmbjogMDAwMDQ1MjEgIG1mbjogMDAwMDQ1MjENCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzI6MTNdICAgZ2ZuOiAwMDAwNDUyMiAgbWZuOiAwMDAwNDUyMg0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoxM10gICBnZm46IDAwMDA0NTIzICBtZm46IDAw
MDA0NTIzDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjEzXSAgIGdmbjogMDAwMDQ1MjQg
IG1mbjogMDAwMDQ1MjQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MTNdICAgZ2ZuOiAw
MDAwNDUyNSAgbWZuOiAwMDAwNDUyNQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoxM10g
ICBnZm46IDAwMDA0NTI2ICBtZm46IDAwMDA0NTI2DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMyOjEzXSAgIGdmbjogMDAwMDQ1MjcgIG1mbjogMDAwMDQ1MjcNCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzI6MTNdICAgZ2ZuOiAwMDAwNDUyOCAgbWZuOiAwMDAwNDUyOA0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMjoxM10gICBnZm46IDAwMDA0NTI5ICBtZm46IDAwMDA0NTI5
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjEzXSAgIGdmbjogMDAwMDQ1MmEgIG1mbjog
MDAwMDQ1MmENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MTNdICAgZ2ZuOiAwMDAwNDUy
YiAgbWZuOiAwMDAwNDUyYg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoxM10gICBnZm46
IDAwMDA0NTJjICBtZm46IDAwMDA0NTJjDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjEz
XSAgIGdmbjogMDAwMDQ1MmQgIG1mbjogMDAwMDQ1MmQNCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzI6MTNdICAgZ2ZuOiAwMDAwNDUyZSAgbWZuOiAwMDAwNDUyZQ0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMjoxM10gICBnZm46IDAwMDA0NTJmICBtZm46IDAwMDA0NTJmDQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMyOjEzXSAgIGdmbjogMDAwMDQ1MzAgIG1mbjogMDAwMDQ1
MzANCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MTNdICAgZ2ZuOiAwMDAwNDUzMSAgbWZu
OiAwMDAwNDUzMQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoxM10gICBnZm46IDAwMDA0
NTMyICBtZm46IDAwMDA0NTMyDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjEzXSAgIGdm
bjogMDAwMDQ1MzMgIG1mbjogMDAwMDQ1MzMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6
MTNdICAgZ2ZuOiAwMDAwNDUzNCAgbWZuOiAwMDAwNDUzNA0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMjoxM10gICBnZm46IDAwMDA0NTM1ICBtZm46IDAwMDA0NTM1DQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMyOjEzXSAgIGdmbjogMDAwMDQ1MzYgIG1mbjogMDAwMDQ1MzYNCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MTNdICAgZ2ZuOiAwMDAwNDUzNyAgbWZuOiAwMDAw
NDUzNw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoxM10gICBnZm46IDAwMDA0NTM4ICBt
Zm46IDAwMDA0NTM4DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjEzXSAgIGdmbjogMDAw
MDQ1MzkgIG1mbjogMDAwMDQ1MzkNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MTNdICAg
Z2ZuOiAwMDAwNDUzYSAgbWZuOiAwMDAwNDUzYQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
MjoxM10gICBnZm46IDAwMDA0NTNiICBtZm46IDAwMDA0NTNiDQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMyOjE0XSAgIGdmbjogMDAwMDQ1M2MgIG1mbjogMDAwMDQ1M2MNCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzI6MTRdICAgZ2ZuOiAwMDAwNDUzZCAgbWZuOiAwMDAwNDUzZA0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoxNF0gICBnZm46IDAwMDA0NTNlICBtZm46IDAw
MDA0NTNlDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjE0XSAgIGdmbjogMDAwMDQ1M2Yg
IG1mbjogMDAwMDQ1M2YNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MTRdICAgZ2ZuOiAw
MDAwNDU0MCAgbWZuOiAwMDAwNDU0MA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoxNF0g
ICBnZm46IDAwMDA0NTQxICBtZm46IDAwMDA0NTQxDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMyOjE0XSAgIGdmbjogMDAwMDQ1NDIgIG1mbjogMDAwMDQ1NDINCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzI6MTRdICAgZ2ZuOiAwMDAwNDU0MyAgbWZuOiAwMDAwNDU0Mw0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMjoxNF0gICBnZm46IDAwMDA0NTQ0ICBtZm46IDAwMDA0NTQ0
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjE0XSAgIGdmbjogMDAwMDQ1NDUgIG1mbjog
MDAwMDQ1NDUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MTRdICAgZ2ZuOiAwMDAwNDU0
NiAgbWZuOiAwMDAwNDU0Ng0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoxNF0gICBnZm46
IDAwMDA0NTQ3ICBtZm46IDAwMDA0NTQ3DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjE0
XSAgIGdmbjogMDAwMDQ1NDggIG1mbjogMDAwMDQ1NDgNCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzI6MTRdICAgZ2ZuOiAwMDAwNDU0OSAgbWZuOiAwMDAwNDU0OQ0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMjoxNF0gICBnZm46IDAwMDA0NTRhICBtZm46IDAwMDA0NTRhDQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMyOjE0XSAgIGdmbjogMDAwMDQ1NGIgIG1mbjogMDAwMDQ1
NGINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MTRdICAgZ2ZuOiAwMDAwNDU0YyAgbWZu
OiAwMDAwNDU0Yw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoxNF0gICBnZm46IDAwMDA0
NTRkICBtZm46IDAwMDA0NTRkDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjE0XSAgIGdm
bjogMDAwMDQ1NGUgIG1mbjogMDAwMDQ1NGUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6
MTRdICAgZ2ZuOiAwMDAwNDU0ZiAgbWZuOiAwMDAwNDU0Zg0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMjoxNF0gICBnZm46IDAwMDA0NTUwICBtZm46IDAwMDA0NTUwDQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMyOjE0XSAgIGdmbjogMDAwMDQ1NTEgIG1mbjogMDAwMDQ1NTENCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MTRdICAgZ2ZuOiAwMDAwNDU1MiAgbWZuOiAwMDAw
NDU1Mg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoxNF0gICBnZm46IDAwMDA0NTUzICBt
Zm46IDAwMDA0NTUzDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjE0XSAgIGdmbjogMDAw
MDQ1NTQgIG1mbjogMDAwMDQ1NTQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MTRdICAg
Z2ZuOiAwMDAwNDU1NSAgbWZuOiAwMDAwNDU1NQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
MjoxNF0gICBnZm46IDAwMDA0NTU2ICBtZm46IDAwMDA0NTU2DQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMyOjE0XSAgIGdmbjogMDAwMDQ1NTcgIG1mbjogMDAwMDQ1NTcNCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzI6MTRdICAgZ2ZuOiAwMDAwNDU1OCAgbWZuOiAwMDAwNDU1OA0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoxNF0gICBnZm46IDAwMDA0NTU5ICBtZm46IDAw
MDA0NTU5DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjE0XSAgIGdmbjogMDAwMDQ1NWEg
IG1mbjogMDAwMDQ1NWENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MTRdICAgZ2ZuOiAw
MDAwNDU1YiAgbWZuOiAwMDAwNDU1Yg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoxNF0g
ICBnZm46IDAwMDA0NTVjICBtZm46IDAwMDA0NTVjDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMyOjE0XSAgIGdmbjogMDAwMDQ1NWQgIG1mbjogMDAwMDQ1NWQNCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzI6MTRdICAgZ2ZuOiAwMDAwNDU1ZSAgbWZuOiAwMDAwNDU1ZQ0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMjoxNF0gICBnZm46IDAwMDA0NTVmICBtZm46IDAwMDA0NTVm
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjE0XSAgIGdmbjogMDAwMDQ1NjAgIG1mbjog
MDAwMDQ1NjANCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MTRdICAgZ2ZuOiAwMDAwNDU2
MSAgbWZuOiAwMDAwNDU2MQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoxNF0gICBnZm46
IDAwMDA0NTYyICBtZm46IDAwMDA0NTYyDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjE0
XSAgIGdmbjogMDAwMDQ1NjMgIG1mbjogMDAwMDQ1NjMNCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzI6MTRdICAgZ2ZuOiAwMDAwNDU2NCAgbWZuOiAwMDAwNDU2NA0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMjoxNF0gICBnZm46IDAwMDA0NTY1ICBtZm46IDAwMDA0NTY1DQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMyOjE0XSAgIGdmbjogMDAwMDQ1NjYgIG1mbjogMDAwMDQ1
NjYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MTRdICAgZ2ZuOiAwMDAwNDU2NyAgbWZu
OiAwMDAwNDU2Nw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoxNF0gICBnZm46IDAwMDA0
NTY4ICBtZm46IDAwMDA0NTY4DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjE0XSAgIGdm
bjogMDAwMDQ1NjkgIG1mbjogMDAwMDQ1NjkNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6
MTRdICAgZ2ZuOiAwMDAwNDU2YSAgbWZuOiAwMDAwNDU2YQ0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMjoxNF0gICBnZm46IDAwMDA0NTZiICBtZm46IDAwMDA0NTZiDQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMyOjE0XSAgIGdmbjogMDAwMDQ1NmMgIG1mbjogMDAwMDQ1NmMNCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MTRdICAgZ2ZuOiAwMDAwNDU2ZCAgbWZuOiAwMDAw
NDU2ZA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoxNF0gICBnZm46IDAwMDA0NTZlICBt
Zm46IDAwMDA0NTZlDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjE0XSAgIGdmbjogMDAw
MDQ1NmYgIG1mbjogMDAwMDQ1NmYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MTRdICAg
Z2ZuOiAwMDAwNDU3MCAgbWZuOiAwMDAwNDU3MA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
MjoxNF0gICBnZm46IDAwMDA0NTcxICBtZm46IDAwMDA0NTcxDQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMyOjE0XSAgIGdmbjogMDAwMDQ1NzIgIG1mbjogMDAwMDQ1NzINCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzI6MTRdICAgZ2ZuOiAwMDAwNDU3MyAgbWZuOiAwMDAwNDU3Mw0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoxNF0gICBnZm46IDAwMDA0NTc0ICBtZm46IDAw
MDA0NTc0DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjE0XSAgIGdmbjogMDAwMDQ1NzUg
IG1mbjogMDAwMDQ1NzUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MTRdICAgZ2ZuOiAw
MDAwNDU3NiAgbWZuOiAwMDAwNDU3Ng0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoxNF0g
ICBnZm46IDAwMDA0NTc3ICBtZm46IDAwMDA0NTc3DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMyOjE0XSAgIGdmbjogMDAwMDQ1NzggIG1mbjogMDAwMDQ1NzgNCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzI6MTRdICAgZ2ZuOiAwMDAwNDU3OSAgbWZuOiAwMDAwNDU3OQ0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMjoxNF0gICBnZm46IDAwMDA0NTdhICBtZm46IDAwMDA0NTdh
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjE0XSAgIGdmbjogMDAwMDQ1N2IgIG1mbjog
MDAwMDQ1N2INCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MTVdICAgZ2ZuOiAwMDAwNDU3
YyAgbWZuOiAwMDAwNDU3Yw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoxNV0gICBnZm46
IDAwMDA0NTdkICBtZm46IDAwMDA0NTdkDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjE1
XSAgIGdmbjogMDAwMDQ1N2UgIG1mbjogMDAwMDQ1N2UNCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzI6MTVdICAgZ2ZuOiAwMDAwNDU3ZiAgbWZuOiAwMDAwNDU3Zg0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMjoxNV0gICBnZm46IDAwMDA0NTgwICBtZm46IDAwMDA0NTgwDQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMyOjE1XSAgIGdmbjogMDAwMDQ1ODEgIG1mbjogMDAwMDQ1
ODENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MTVdICAgZ2ZuOiAwMDAwNDU4MiAgbWZu
OiAwMDAwNDU4Mg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoxNV0gICBnZm46IDAwMDA0
NTgzICBtZm46IDAwMDA0NTgzDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjE1XSAgIGdm
bjogMDAwMDQ1ODQgIG1mbjogMDAwMDQ1ODQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6
MTVdICAgZ2ZuOiAwMDAwNDU4NSAgbWZuOiAwMDAwNDU4NQ0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMjoxNV0gICBnZm46IDAwMDA0NTg2ICBtZm46IDAwMDA0NTg2DQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMyOjE1XSAgIGdmbjogMDAwMDQ1ODcgIG1mbjogMDAwMDQ1ODcNCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MTVdICAgZ2ZuOiAwMDAwNDU4OCAgbWZuOiAwMDAw
NDU4OA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoxNV0gICBnZm46IDAwMDA0NTg5ICBt
Zm46IDAwMDA0NTg5DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjE1XSAgIGdmbjogMDAw
MDQ1OGEgIG1mbjogMDAwMDQ1OGENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MTVdICAg
Z2ZuOiAwMDAwNDU4YiAgbWZuOiAwMDAwNDU4Yg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
MjoxNV0gICBnZm46IDAwMDA0NThjICBtZm46IDAwMDA0NThjDQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMyOjE1XSAgIGdmbjogMDAwMDQ1OGQgIG1mbjogMDAwMDQ1OGQNCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzI6MTVdICAgZ2ZuOiAwMDAwNDU4ZSAgbWZuOiAwMDAwNDU4ZQ0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoxNV0gICBnZm46IDAwMDA0NThmICBtZm46IDAw
MDA0NThmDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjE1XSAgIGdmbjogMDAwMDQ1OTAg
IG1mbjogMDAwMDQ1OTANCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MTVdICAgZ2ZuOiAw
MDAwNDU5MSAgbWZuOiAwMDAwNDU5MQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoxNV0g
ICBnZm46IDAwMDA0NTkyICBtZm46IDAwMDA0NTkyDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMyOjE1XSAgIGdmbjogMDAwMDQ1OTMgIG1mbjogMDAwMDQ1OTMNCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzI6MTVdICAgZ2ZuOiAwMDAwNDU5NCAgbWZuOiAwMDAwNDU5NA0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMjoxNV0gICBnZm46IDAwMDA0NTk1ICBtZm46IDAwMDA0NTk1
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjE1XSAgIGdmbjogMDAwMDQ1OTYgIG1mbjog
MDAwMDQ1OTYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MTVdICAgZ2ZuOiAwMDAwNDU5
NyAgbWZuOiAwMDAwNDU5Nw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoxNV0gICBnZm46
IDAwMDA0NTk4ICBtZm46IDAwMDA0NTk4DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjE1
XSAgIGdmbjogMDAwMDQ1OTkgIG1mbjogMDAwMDQ1OTkNCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzI6MTVdICAgZ2ZuOiAwMDAwNDU5YSAgbWZuOiAwMDAwNDU5YQ0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMjoxNV0gICBnZm46IDAwMDA0NTliICBtZm46IDAwMDA0NTliDQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMyOjE1XSAgIGdmbjogMDAwMDQ1OWMgIG1mbjogMDAwMDQ1
OWMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MTVdICAgZ2ZuOiAwMDAwNDU5ZCAgbWZu
OiAwMDAwNDU5ZA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoxNV0gICBnZm46IDAwMDA0
NTllICBtZm46IDAwMDA0NTllDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjE1XSAgIGdm
bjogMDAwMDQ1OWYgIG1mbjogMDAwMDQ1OWYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6
MTVdICAgZ2ZuOiAwMDAwNDVhMCAgbWZuOiAwMDAwNDVhMA0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMjoxNV0gICBnZm46IDAwMDA0NWExICBtZm46IDAwMDA0NWExDQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMyOjE1XSAgIGdmbjogMDAwMDQ1YTIgIG1mbjogMDAwMDQ1YTINCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MTVdICAgZ2ZuOiAwMDAwNDVhMyAgbWZuOiAwMDAw
NDVhMw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoxNV0gICBnZm46IDAwMDA0NWE0ICBt
Zm46IDAwMDA0NWE0DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjE1XSAgIGdmbjogMDAw
MDQ1YTUgIG1mbjogMDAwMDQ1YTUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MTVdICAg
Z2ZuOiAwMDAwNDVhNiAgbWZuOiAwMDAwNDVhNg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
MjoxNV0gICBnZm46IDAwMDA0NWE3ICBtZm46IDAwMDA0NWE3DQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMyOjE1XSAgIGdmbjogMDAwMDQ1YTggIG1mbjogMDAwMDQ1YTgNCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzI6MTVdICAgZ2ZuOiAwMDAwNDVhOSAgbWZuOiAwMDAwNDVhOQ0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoxNV0gICBnZm46IDAwMDA0NWFhICBtZm46IDAw
MDA0NWFhDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjE1XSAgIGdmbjogMDAwMDQ1YWIg
IG1mbjogMDAwMDQ1YWINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MTVdICAgZ2ZuOiAw
MDAwNDVhYyAgbWZuOiAwMDAwNDVhYw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoxNV0g
ICBnZm46IDAwMDA0NWFkICBtZm46IDAwMDA0NWFkDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMyOjE1XSAgIGdmbjogMDAwMDQ1YWUgIG1mbjogMDAwMDQ1YWUNCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzI6MTVdICAgZ2ZuOiAwMDAwNDVhZiAgbWZuOiAwMDAwNDVhZg0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMjoxNV0gICBnZm46IDAwMDA0NWIwICBtZm46IDAwMDA0NWIw
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjE1XSAgIGdmbjogMDAwMDQ1YjEgIG1mbjog
MDAwMDQ1YjENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MTVdICAgZ2ZuOiAwMDAwNDVi
MiAgbWZuOiAwMDAwNDViMg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoxNV0gICBnZm46
IDAwMDA0NWIzICBtZm46IDAwMDA0NWIzDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjE1
XSAgIGdmbjogMDAwMDQ1YjQgIG1mbjogMDAwMDQ1YjQNCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzI6MTVdICAgZ2ZuOiAwMDAwNDViNSAgbWZuOiAwMDAwNDViNQ0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMjoxNV0gICBnZm46IDAwMDA0NWI2ICBtZm46IDAwMDA0NWI2DQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMyOjE1XSAgIGdmbjogMDAwMDQ1YjcgIG1mbjogMDAwMDQ1
YjcNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MTVdICAgZ2ZuOiAwMDAwNDViOCAgbWZu
OiAwMDAwNDViOA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoxNV0gICBnZm46IDAwMDA0
NWI5ICBtZm46IDAwMDA0NWI5DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjE1XSAgIGdm
bjogMDAwMDQ1YmEgIG1mbjogMDAwMDQ1YmENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6
MTVdICAgZ2ZuOiAwMDAwNDViYiAgbWZuOiAwMDAwNDViYg0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMjoxNl0gICBnZm46IDAwMDA0NWJjICBtZm46IDAwMDA0NWJjDQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMyOjE2XSAgIGdmbjogMDAwMDQ1YmQgIG1mbjogMDAwMDQ1YmQNCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MTZdICAgZ2ZuOiAwMDAwNDViZSAgbWZuOiAwMDAw
NDViZQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoxNl0gICBnZm46IDAwMDA0NWJmICBt
Zm46IDAwMDA0NWJmDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjE2XSAgIGdmbjogMDAw
MDQ1YzAgIG1mbjogMDAwMDQ1YzANCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MTZdICAg
Z2ZuOiAwMDAwNDVjMSAgbWZuOiAwMDAwNDVjMQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
MjoxNl0gICBnZm46IDAwMDA0NWMyICBtZm46IDAwMDA0NWMyDQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMyOjE2XSAgIGdmbjogMDAwMDQ1YzMgIG1mbjogMDAwMDQ1YzMNCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzI6MTZdICAgZ2ZuOiAwMDAwNDVjNCAgbWZuOiAwMDAwNDVjNA0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoxNl0gICBnZm46IDAwMDA0NWM1ICBtZm46IDAw
MDA0NWM1DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjE2XSAgIGdmbjogMDAwMDQ1YzYg
IG1mbjogMDAwMDQ1YzYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MTZdICAgZ2ZuOiAw
MDAwNDVjNyAgbWZuOiAwMDAwNDVjNw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoxNl0g
ICBnZm46IDAwMDA0NWM4ICBtZm46IDAwMDA0NWM4DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMyOjE2XSAgIGdmbjogMDAwMDQ1YzkgIG1mbjogMDAwMDQ1YzkNCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzI6MTZdICAgZ2ZuOiAwMDAwNDVjYSAgbWZuOiAwMDAwNDVjYQ0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMjoxNl0gICBnZm46IDAwMDA0NWNiICBtZm46IDAwMDA0NWNi
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjE2XSAgIGdmbjogMDAwMDQ1Y2MgIG1mbjog
MDAwMDQ1Y2MNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MTZdICAgZ2ZuOiAwMDAwNDVj
ZCAgbWZuOiAwMDAwNDVjZA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoxNl0gICBnZm46
IDAwMDA0NWNlICBtZm46IDAwMDA0NWNlDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjE2
XSAgIGdmbjogMDAwMDQ1Y2YgIG1mbjogMDAwMDQ1Y2YNCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzI6MTZdICAgZ2ZuOiAwMDAwNDVkMCAgbWZuOiAwMDAwNDVkMA0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMjoxNl0gICBnZm46IDAwMDA0NWQxICBtZm46IDAwMDA0NWQxDQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMyOjE2XSAgIGdmbjogMDAwMDQ1ZDIgIG1mbjogMDAwMDQ1
ZDINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MTZdICAgZ2ZuOiAwMDAwNDVkMyAgbWZu
OiAwMDAwNDVkMw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoxNl0gICBnZm46IDAwMDA0
NWQ0ICBtZm46IDAwMDA0NWQ0DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjE2XSAgIGdm
bjogMDAwMDQ1ZDUgIG1mbjogMDAwMDQ1ZDUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6
MTZdICAgZ2ZuOiAwMDAwNDVkNiAgbWZuOiAwMDAwNDVkNg0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMjoxNl0gICBnZm46IDAwMDA0NWQ3ICBtZm46IDAwMDA0NWQ3DQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMyOjE2XSAgIGdmbjogMDAwMDQ1ZDggIG1mbjogMDAwMDQ1ZDgNCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MTZdICAgZ2ZuOiAwMDAwNDVkOSAgbWZuOiAwMDAw
NDVkOQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoxNl0gICBnZm46IDAwMDA0NWRhICBt
Zm46IDAwMDA0NWRhDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjE2XSAgIGdmbjogMDAw
MDQ1ZGIgIG1mbjogMDAwMDQ1ZGINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MTZdICAg
Z2ZuOiAwMDAwNDVkYyAgbWZuOiAwMDAwNDVkYw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
MjoxNl0gICBnZm46IDAwMDA0NWRkICBtZm46IDAwMDA0NWRkDQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMyOjE2XSAgIGdmbjogMDAwMDQ1ZGUgIG1mbjogMDAwMDQ1ZGUNCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzI6MTZdICAgZ2ZuOiAwMDAwNDVkZiAgbWZuOiAwMDAwNDVkZg0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoxNl0gICBnZm46IDAwMDA0NWUwICBtZm46IDAw
MDA0NWUwDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjE2XSAgIGdmbjogMDAwMDQ1ZTEg
IG1mbjogMDAwMDQ1ZTENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MTZdICAgZ2ZuOiAw
MDAwNDVlMiAgbWZuOiAwMDAwNDVlMg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoxNl0g
ICBnZm46IDAwMDA0NWUzICBtZm46IDAwMDA0NWUzDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMyOjE2XSAgIGdmbjogMDAwMDQ1ZTQgIG1mbjogMDAwMDQ1ZTQNCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzI6MTZdICAgZ2ZuOiAwMDAwNDVlNSAgbWZuOiAwMDAwNDVlNQ0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMjoxNl0gICBnZm46IDAwMDA0NWU2ICBtZm46IDAwMDA0NWU2
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjE2XSAgIGdmbjogMDAwMDQ1ZTcgIG1mbjog
MDAwMDQ1ZTcNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MTZdICAgZ2ZuOiAwMDAwNDVl
OCAgbWZuOiAwMDAwNDVlOA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoxNl0gICBnZm46
IDAwMDA0NWU5ICBtZm46IDAwMDA0NWU5DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjE2
XSAgIGdmbjogMDAwMDQ1ZWEgIG1mbjogMDAwMDQ1ZWENCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzI6MTZdICAgZ2ZuOiAwMDAwNDVlYiAgbWZuOiAwMDAwNDVlYg0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMjoxNl0gICBnZm46IDAwMDA0NWVjICBtZm46IDAwMDA0NWVjDQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMyOjE2XSAgIGdmbjogMDAwMDQ1ZWQgIG1mbjogMDAwMDQ1
ZWQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MTZdICAgZ2ZuOiAwMDAwNDVlZSAgbWZu
OiAwMDAwNDVlZQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoxNl0gICBnZm46IDAwMDA0
NWVmICBtZm46IDAwMDA0NWVmDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjE2XSAgIGdm
bjogMDAwMDQ1ZjAgIG1mbjogMDAwMDQ1ZjANCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6
MTZdICAgZ2ZuOiAwMDAwNDVmMSAgbWZuOiAwMDAwNDVmMQ0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMjoxNl0gICBnZm46IDAwMDA0NWYyICBtZm46IDAwMDA0NWYyDQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMyOjE2XSAgIGdmbjogMDAwMDQ1ZjMgIG1mbjogMDAwMDQ1ZjMNCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MTZdICAgZ2ZuOiAwMDAwNDVmNCAgbWZuOiAwMDAw
NDVmNA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoxNl0gICBnZm46IDAwMDA0NWY1ICBt
Zm46IDAwMDA0NWY1DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjE2XSAgIGdmbjogMDAw
MDQ1ZjYgIG1mbjogMDAwMDQ1ZjYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MTZdICAg
Z2ZuOiAwMDAwNDVmNyAgbWZuOiAwMDAwNDVmNw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
MjoxNl0gICBnZm46IDAwMDA0NWY4ICBtZm46IDAwMDA0NWY4DQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMyOjE2XSAgIGdmbjogMDAwMDQ1ZjkgIG1mbjogMDAwMDQ1ZjkNCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzI6MTZdICAgZ2ZuOiAwMDAwNDVmYSAgbWZuOiAwMDAwNDVmYQ0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoxNl0gICBnZm46IDAwMDA0NWZiICBtZm46IDAw
MDA0NWZiDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjE3XSAgIGdmbjogMDAwMDQ1ZmMg
IG1mbjogMDAwMDQ1ZmMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MTddICAgZ2ZuOiAw
MDAwNDVmZCAgbWZuOiAwMDAwNDVmZA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoxN10g
ICBnZm46IDAwMDA0NWZlICBtZm46IDAwMDA0NWZlDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMyOjE3XSAgIGdmbjogMDAwMDQ1ZmYgIG1mbjogMDAwMDQ1ZmYNCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzI6MTddICAgZ2ZuOiAwMDAwNDYwMCAgbWZuOiAwMDAwNDYwMA0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMjoxN10gICBnZm46IDAwMDA0NjAxICBtZm46IDAwMDA0NjAx
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjE3XSAgIGdmbjogMDAwMDQ2MDIgIG1mbjog
MDAwMDQ2MDINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MTddICAgZ2ZuOiAwMDAwNDYw
MyAgbWZuOiAwMDAwNDYwMw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoxN10gICBnZm46
IDAwMDA0NjA0ICBtZm46IDAwMDA0NjA0DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjE3
XSAgIGdmbjogMDAwMDQ2MDUgIG1mbjogMDAwMDQ2MDUNCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzI6MTddICAgZ2ZuOiAwMDAwNDYwNiAgbWZuOiAwMDAwNDYwNg0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMjoxN10gICBnZm46IDAwMDA0NjA3ICBtZm46IDAwMDA0NjA3DQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMyOjE3XSAgIGdmbjogMDAwMDQ2MDggIG1mbjogMDAwMDQ2
MDgNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MTddICAgZ2ZuOiAwMDAwNDYwOSAgbWZu
OiAwMDAwNDYwOQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoxN10gICBnZm46IDAwMDA0
NjBhICBtZm46IDAwMDA0NjBhDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjE3XSAgIGdm
bjogMDAwMDQ2MGIgIG1mbjogMDAwMDQ2MGINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6
MTddICAgZ2ZuOiAwMDAwNDYwYyAgbWZuOiAwMDAwNDYwYw0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMjoxN10gICBnZm46IDAwMDA0NjBkICBtZm46IDAwMDA0NjBkDQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMyOjE3XSAgIGdmbjogMDAwMDQ2MGUgIG1mbjogMDAwMDQ2MGUNCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MTddICAgZ2ZuOiAwMDAwNDYwZiAgbWZuOiAwMDAw
NDYwZg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoxN10gICBnZm46IDAwMDA0NjEwICBt
Zm46IDAwMDA0NjEwDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjE3XSAgIGdmbjogMDAw
MDQ2MTEgIG1mbjogMDAwMDQ2MTENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MTddICAg
Z2ZuOiAwMDAwNDYxMiAgbWZuOiAwMDAwNDYxMg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
MjoxN10gICBnZm46IDAwMDA0NjEzICBtZm46IDAwMDA0NjEzDQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMyOjE3XSAgIGdmbjogMDAwMDQ2MTQgIG1mbjogMDAwMDQ2MTQNCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzI6MTddICAgZ2ZuOiAwMDAwNDYxNSAgbWZuOiAwMDAwNDYxNQ0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoxN10gICBnZm46IDAwMDA0NjE2ICBtZm46IDAw
MDA0NjE2DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjE3XSAgIGdmbjogMDAwMDQ2MTcg
IG1mbjogMDAwMDQ2MTcNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MTddICAgZ2ZuOiAw
MDAwNDYxOCAgbWZuOiAwMDAwNDYxOA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoxN10g
ICBnZm46IDAwMDA0NjE5ICBtZm46IDAwMDA0NjE5DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMyOjE3XSAgIGdmbjogMDAwMDQ2MWEgIG1mbjogMDAwMDQ2MWENCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzI6MTddICAgZ2ZuOiAwMDAwNDYxYiAgbWZuOiAwMDAwNDYxYg0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMjoxN10gICBnZm46IDAwMDA0NjFjICBtZm46IDAwMDA0NjFj
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjE3XSAgIGdmbjogMDAwMDQ2MWQgIG1mbjog
MDAwMDQ2MWQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MTddICAgZ2ZuOiAwMDAwNDYx
ZSAgbWZuOiAwMDAwNDYxZQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoxN10gICBnZm46
IDAwMDA0NjFmICBtZm46IDAwMDA0NjFmDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjE3
XSAgIGdmbjogMDAwMDQ2MjAgIG1mbjogMDAwMDQ2MjANCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzI6MTddICAgZ2ZuOiAwMDAwNDYyMSAgbWZuOiAwMDAwNDYyMQ0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMjoxN10gICBnZm46IDAwMDA0NjIyICBtZm46IDAwMDA0NjIyDQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMyOjE3XSAgIGdmbjogMDAwMDQ2MjMgIG1mbjogMDAwMDQ2
MjMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MTddICAgZ2ZuOiAwMDAwNDYyNCAgbWZu
OiAwMDAwNDYyNA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoxN10gICBnZm46IDAwMDA0
NjI1ICBtZm46IDAwMDA0NjI1DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjE3XSAgIGdm
bjogMDAwMDQ2MjYgIG1mbjogMDAwMDQ2MjYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6
MTddICAgZ2ZuOiAwMDAwNDYyNyAgbWZuOiAwMDAwNDYyNw0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMjoxN10gICBnZm46IDAwMDA0NjI4ICBtZm46IDAwMDA0NjI4DQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMyOjE3XSAgIGdmbjogMDAwMDQ2MjkgIG1mbjogMDAwMDQ2MjkNCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MTddICAgZ2ZuOiAwMDAwNDYyYSAgbWZuOiAwMDAw
NDYyYQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoxN10gICBnZm46IDAwMDA0NjJiICBt
Zm46IDAwMDA0NjJiDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjE3XSAgIGdmbjogMDAw
MDQ2MmMgIG1mbjogMDAwMDQ2MmMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MTddICAg
Z2ZuOiAwMDAwNDYyZCAgbWZuOiAwMDAwNDYyZA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
MjoxN10gICBnZm46IDAwMDA0NjJlICBtZm46IDAwMDA0NjJlDQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMyOjE3XSAgIGdmbjogMDAwMDQ2MmYgIG1mbjogMDAwMDQ2MmYNCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzI6MTddICAgZ2ZuOiAwMDAwNDYzMCAgbWZuOiAwMDAwNDYzMA0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoxN10gICBnZm46IDAwMDA0NjMxICBtZm46IDAw
MDA0NjMxDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjE3XSAgIGdmbjogMDAwMDQ2MzIg
IG1mbjogMDAwMDQ2MzINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MTddICAgZ2ZuOiAw
MDAwNDYzMyAgbWZuOiAwMDAwNDYzMw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoxN10g
ICBnZm46IDAwMDA0NjM0ICBtZm46IDAwMDA0NjM0DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMyOjE3XSAgIGdmbjogMDAwMDQ2MzUgIG1mbjogMDAwMDQ2MzUNCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzI6MTddICAgZ2ZuOiAwMDAwNDYzNiAgbWZuOiAwMDAwNDYzNg0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMjoxN10gICBnZm46IDAwMDA0NjM3ICBtZm46IDAwMDA0NjM3
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjE3XSAgIGdmbjogMDAwMDQ2MzggIG1mbjog
MDAwMDQ2MzgNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MTddICAgZ2ZuOiAwMDAwNDYz
OSAgbWZuOiAwMDAwNDYzOQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoxN10gICBnZm46
IDAwMDA0NjNhICBtZm46IDAwMDA0NjNhDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjE3
XSAgIGdmbjogMDAwMDQ2M2IgIG1mbjogMDAwMDQ2M2INCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzI6MThdICAgZ2ZuOiAwMDAwNDYzYyAgbWZuOiAwMDAwNDYzYw0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMjoxOF0gICBnZm46IDAwMDA0NjNkICBtZm46IDAwMDA0NjNkDQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMyOjE4XSAgIGdmbjogMDAwMDQ2M2UgIG1mbjogMDAwMDQ2
M2UNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MThdICAgZ2ZuOiAwMDAwNDYzZiAgbWZu
OiAwMDAwNDYzZg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoxOF0gICBnZm46IDAwMDA0
NjQwICBtZm46IDAwMDA0NjQwDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjE4XSAgIGdm
bjogMDAwMDQ2NDEgIG1mbjogMDAwMDQ2NDENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6
MThdICAgZ2ZuOiAwMDAwNDY0MiAgbWZuOiAwMDAwNDY0Mg0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMjoxOF0gICBnZm46IDAwMDA0NjQzICBtZm46IDAwMDA0NjQzDQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMyOjE4XSAgIGdmbjogMDAwMDQ2NDQgIG1mbjogMDAwMDQ2NDQNCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MThdICAgZ2ZuOiAwMDAwNDY0NSAgbWZuOiAwMDAw
NDY0NQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoxOF0gICBnZm46IDAwMDA0NjQ2ICBt
Zm46IDAwMDA0NjQ2DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjE4XSAgIGdmbjogMDAw
MDQ2NDcgIG1mbjogMDAwMDQ2NDcNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MThdICAg
Z2ZuOiAwMDAwNDY0OCAgbWZuOiAwMDAwNDY0OA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
MjoxOF0gICBnZm46IDAwMDA0NjQ5ICBtZm46IDAwMDA0NjQ5DQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMyOjE4XSAgIGdmbjogMDAwMDQ2NGEgIG1mbjogMDAwMDQ2NGENCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzI6MThdICAgZ2ZuOiAwMDAwNDY0YiAgbWZuOiAwMDAwNDY0Yg0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoxOF0gICBnZm46IDAwMDA0NjRjICBtZm46IDAw
MDA0NjRjDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjE4XSAgIGdmbjogMDAwMDQ2NGQg
IG1mbjogMDAwMDQ2NGQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MThdICAgZ2ZuOiAw
MDAwNDY0ZSAgbWZuOiAwMDAwNDY0ZQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoxOF0g
ICBnZm46IDAwMDA0NjRmICBtZm46IDAwMDA0NjRmDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMyOjE4XSAgIGdmbjogMDAwMDQ2NTAgIG1mbjogMDAwMDQ2NTANCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzI6MThdICAgZ2ZuOiAwMDAwNDY1MSAgbWZuOiAwMDAwNDY1MQ0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMjoxOF0gICBnZm46IDAwMDA0NjUyICBtZm46IDAwMDA0NjUy
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjE4XSAgIGdmbjogMDAwMDQ2NTMgIG1mbjog
MDAwMDQ2NTMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MThdICAgZ2ZuOiAwMDAwNDY1
NCAgbWZuOiAwMDAwNDY1NA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoxOF0gICBnZm46
IDAwMDA0NjU1ICBtZm46IDAwMDA0NjU1DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjE4
XSAgIGdmbjogMDAwMDQ2NTYgIG1mbjogMDAwMDQ2NTYNCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzI6MThdICAgZ2ZuOiAwMDAwNDY1NyAgbWZuOiAwMDAwNDY1Nw0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMjoxOF0gICBnZm46IDAwMDA0NjU4ICBtZm46IDAwMDA0NjU4DQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMyOjE4XSAgIGdmbjogMDAwMDQ2NTkgIG1mbjogMDAwMDQ2
NTkNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MThdICAgZ2ZuOiAwMDAwNDY1YSAgbWZu
OiAwMDAwNDY1YQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoxOF0gICBnZm46IDAwMDA0
NjViICBtZm46IDAwMDA0NjViDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjE4XSAgIGdm
bjogMDAwMDQ2NWMgIG1mbjogMDAwMDQ2NWMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6
MThdICAgZ2ZuOiAwMDAwNDY1ZCAgbWZuOiAwMDAwNDY1ZA0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMjoxOF0gICBnZm46IDAwMDA0NjVlICBtZm46IDAwMDA0NjVlDQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMyOjE4XSAgIGdmbjogMDAwMDQ2NWYgIG1mbjogMDAwMDQ2NWYNCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MThdICAgZ2ZuOiAwMDAwNDY2MCAgbWZuOiAwMDAw
NDY2MA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoxOF0gICBnZm46IDAwMDA0NjYxICBt
Zm46IDAwMDA0NjYxDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjE4XSAgIGdmbjogMDAw
MDQ2NjIgIG1mbjogMDAwMDQ2NjINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MThdICAg
Z2ZuOiAwMDAwNDY2MyAgbWZuOiAwMDAwNDY2Mw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
MjoxOF0gICBnZm46IDAwMDA0NjY0ICBtZm46IDAwMDA0NjY0DQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMyOjE4XSAgIGdmbjogMDAwMDQ2NjUgIG1mbjogMDAwMDQ2NjUNCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzI6MThdICAgZ2ZuOiAwMDAwNDY2NiAgbWZuOiAwMDAwNDY2Ng0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoxOF0gICBnZm46IDAwMDA0NjY3ICBtZm46IDAw
MDA0NjY3DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjE4XSAgIGdmbjogMDAwMDQ2Njgg
IG1mbjogMDAwMDQ2NjgNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MThdICAgZ2ZuOiAw
MDAwNDY2OSAgbWZuOiAwMDAwNDY2OQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoxOF0g
ICBnZm46IDAwMDA0NjZhICBtZm46IDAwMDA0NjZhDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMyOjE4XSAgIGdmbjogMDAwMDQ2NmIgIG1mbjogMDAwMDQ2NmINCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzI6MThdICAgZ2ZuOiAwMDAwNDY2YyAgbWZuOiAwMDAwNDY2Yw0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMjoxOF0gICBnZm46IDAwMDA0NjZkICBtZm46IDAwMDA0NjZk
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjE4XSAgIGdmbjogMDAwMDQ2NmUgIG1mbjog
MDAwMDQ2NmUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MThdICAgZ2ZuOiAwMDAwNDY2
ZiAgbWZuOiAwMDAwNDY2Zg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoxOF0gICBnZm46
IDAwMDA0NjcwICBtZm46IDAwMDA0NjcwDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjE4
XSAgIGdmbjogMDAwMDQ2NzEgIG1mbjogMDAwMDQ2NzENCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzI6MThdICAgZ2ZuOiAwMDAwNDY3MiAgbWZuOiAwMDAwNDY3Mg0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMjoxOF0gICBnZm46IDAwMDA0NjczICBtZm46IDAwMDA0NjczDQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMyOjE4XSAgIGdmbjogMDAwMDQ2NzQgIG1mbjogMDAwMDQ2
NzQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MThdICAgZ2ZuOiAwMDAwNDY3NSAgbWZu
OiAwMDAwNDY3NQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoxOF0gICBnZm46IDAwMDA0
Njc2ICBtZm46IDAwMDA0Njc2DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjE4XSAgIGdm
bjogMDAwMDQ2NzcgIG1mbjogMDAwMDQ2NzcNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6
MThdICAgZ2ZuOiAwMDAwNDY3OCAgbWZuOiAwMDAwNDY3OA0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMjoxOF0gICBnZm46IDAwMDA0Njc5ICBtZm46IDAwMDA0Njc5DQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMyOjE4XSAgIGdmbjogMDAwMDQ2N2EgIG1mbjogMDAwMDQ2N2ENCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MThdICAgZ2ZuOiAwMDAwNDY3YiAgbWZuOiAwMDAw
NDY3Yg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoxOV0gICBnZm46IDAwMDA0NjdjICBt
Zm46IDAwMDA0NjdjDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjE5XSAgIGdmbjogMDAw
MDQ2N2QgIG1mbjogMDAwMDQ2N2QNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MTldICAg
Z2ZuOiAwMDAwNDY3ZSAgbWZuOiAwMDAwNDY3ZQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
MjoxOV0gICBnZm46IDAwMDA0NjdmICBtZm46IDAwMDA0NjdmDQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMyOjE5XSAgIGdmbjogMDAwMDQ2ODAgIG1mbjogMDAwMDQ2ODANCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzI6MTldICAgZ2ZuOiAwMDAwNDY4MSAgbWZuOiAwMDAwNDY4MQ0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoxOV0gICBnZm46IDAwMDA0NjgyICBtZm46IDAw
MDA0NjgyDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjE5XSAgIGdmbjogMDAwMDQ2ODMg
IG1mbjogMDAwMDQ2ODMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MTldICAgZ2ZuOiAw
MDAwNDY4NCAgbWZuOiAwMDAwNDY4NA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoxOV0g
ICBnZm46IDAwMDA0Njg1ICBtZm46IDAwMDA0Njg1DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMyOjE5XSAgIGdmbjogMDAwMDQ2ODYgIG1mbjogMDAwMDQ2ODYNCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzI6MTldICAgZ2ZuOiAwMDAwNDY4NyAgbWZuOiAwMDAwNDY4Nw0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMjoxOV0gICBnZm46IDAwMDA0Njg4ICBtZm46IDAwMDA0Njg4
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjE5XSAgIGdmbjogMDAwMDQ2ODkgIG1mbjog
MDAwMDQ2ODkNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MTldICAgZ2ZuOiAwMDAwNDY4
YSAgbWZuOiAwMDAwNDY4YQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoxOV0gICBnZm46
IDAwMDA0NjhiICBtZm46IDAwMDA0NjhiDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjE5
XSAgIGdmbjogMDAwMDQ2OGMgIG1mbjogMDAwMDQ2OGMNCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzI6MTldICAgZ2ZuOiAwMDAwNDY4ZCAgbWZuOiAwMDAwNDY4ZA0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMjoxOV0gICBnZm46IDAwMDA0NjhlICBtZm46IDAwMDA0NjhlDQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMyOjE5XSAgIGdmbjogMDAwMDQ2OGYgIG1mbjogMDAwMDQ2
OGYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MTldICAgZ2ZuOiAwMDAwNDY5MCAgbWZu
OiAwMDAwNDY5MA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoxOV0gICBnZm46IDAwMDA0
NjkxICBtZm46IDAwMDA0NjkxDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjE5XSAgIGdm
bjogMDAwMDQ2OTIgIG1mbjogMDAwMDQ2OTINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6
MTldICAgZ2ZuOiAwMDAwNDY5MyAgbWZuOiAwMDAwNDY5Mw0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMjoxOV0gICBnZm46IDAwMDA0Njk0ICBtZm46IDAwMDA0Njk0DQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMyOjE5XSAgIGdmbjogMDAwMDQ2OTUgIG1mbjogMDAwMDQ2OTUNCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MTldICAgZ2ZuOiAwMDAwNDY5NiAgbWZuOiAwMDAw
NDY5Ng0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoxOV0gICBnZm46IDAwMDA0Njk3ICBt
Zm46IDAwMDA0Njk3DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjE5XSAgIGdmbjogMDAw
MDQ2OTggIG1mbjogMDAwMDQ2OTgNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MTldICAg
Z2ZuOiAwMDAwNDY5OSAgbWZuOiAwMDAwNDY5OQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
MjoxOV0gICBnZm46IDAwMDA0NjlhICBtZm46IDAwMDA0NjlhDQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMyOjE5XSAgIGdmbjogMDAwMDQ2OWIgIG1mbjogMDAwMDQ2OWINCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzI6MTldICAgZ2ZuOiAwMDAwNDY5YyAgbWZuOiAwMDAwNDY5Yw0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoxOV0gICBnZm46IDAwMDA0NjlkICBtZm46IDAw
MDA0NjlkDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjE5XSAgIGdmbjogMDAwMDQ2OWUg
IG1mbjogMDAwMDQ2OWUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MTldICAgZ2ZuOiAw
MDAwNDY5ZiAgbWZuOiAwMDAwNDY5Zg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoxOV0g
ICBnZm46IDAwMDA0NmEwICBtZm46IDAwMDA0NmEwDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMyOjE5XSAgIGdmbjogMDAwMDQ2YTEgIG1mbjogMDAwMDQ2YTENCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzI6MTldICAgZ2ZuOiAwMDAwNDZhMiAgbWZuOiAwMDAwNDZhMg0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMjoxOV0gICBnZm46IDAwMDA0NmEzICBtZm46IDAwMDA0NmEz
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjE5XSAgIGdmbjogMDAwMDQ2YTQgIG1mbjog
MDAwMDQ2YTQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MTldICAgZ2ZuOiAwMDAwNDZh
NSAgbWZuOiAwMDAwNDZhNQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoxOV0gICBnZm46
IDAwMDA0NmE2ICBtZm46IDAwMDA0NmE2DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjE5
XSAgIGdmbjogMDAwMDQ2YTcgIG1mbjogMDAwMDQ2YTcNCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzI6MTldICAgZ2ZuOiAwMDAwNDZhOCAgbWZuOiAwMDAwNDZhOA0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMjoxOV0gICBnZm46IDAwMDA0NmE5ICBtZm46IDAwMDA0NmE5DQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMyOjE5XSAgIGdmbjogMDAwMDQ2YWEgIG1mbjogMDAwMDQ2
YWENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MTldICAgZ2ZuOiAwMDAwNDZhYiAgbWZu
OiAwMDAwNDZhYg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoxOV0gICBnZm46IDAwMDA0
NmFjICBtZm46IDAwMDA0NmFjDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjE5XSAgIGdm
bjogMDAwMDQ2YWQgIG1mbjogMDAwMDQ2YWQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6
MTldICAgZ2ZuOiAwMDAwNDZhZSAgbWZuOiAwMDAwNDZhZQ0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMjoxOV0gICBnZm46IDAwMDA0NmFmICBtZm46IDAwMDA0NmFmDQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMyOjE5XSAgIGdmbjogMDAwMDQ2YjAgIG1mbjogMDAwMDQ2YjANCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MTldICAgZ2ZuOiAwMDAwNDZiMSAgbWZuOiAwMDAw
NDZiMQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoxOV0gICBnZm46IDAwMDA0NmIyICBt
Zm46IDAwMDA0NmIyDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjE5XSAgIGdmbjogMDAw
MDQ2YjMgIG1mbjogMDAwMDQ2YjMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MTldICAg
Z2ZuOiAwMDAwNDZiNCAgbWZuOiAwMDAwNDZiNA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
MjoxOV0gICBnZm46IDAwMDA0NmI1ICBtZm46IDAwMDA0NmI1DQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMyOjE5XSAgIGdmbjogMDAwMDQ2YjYgIG1mbjogMDAwMDQ2YjYNCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzI6MTldICAgZ2ZuOiAwMDAwNDZiNyAgbWZuOiAwMDAwNDZiNw0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoxOV0gICBnZm46IDAwMDA0NmI4ICBtZm46IDAw
MDA0NmI4DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjE5XSAgIGdmbjogMDAwMDQ2Yjkg
IG1mbjogMDAwMDQ2YjkNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MTldICAgZ2ZuOiAw
MDAwNDZiYSAgbWZuOiAwMDAwNDZiYQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoxOV0g
ICBnZm46IDAwMDA0NmJiICBtZm46IDAwMDA0NmJiDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMyOjIwXSAgIGdmbjogMDAwMDQ2YmMgIG1mbjogMDAwMDQ2YmMNCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzI6MjBdICAgZ2ZuOiAwMDAwNDZiZCAgbWZuOiAwMDAwNDZiZA0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMjoyMF0gICBnZm46IDAwMDA0NmJlICBtZm46IDAwMDA0NmJl
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjIwXSAgIGdmbjogMDAwMDQ2YmYgIG1mbjog
MDAwMDQ2YmYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MjBdICAgZ2ZuOiAwMDAwNDZj
MCAgbWZuOiAwMDAwNDZjMA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoyMF0gICBnZm46
IDAwMDA0NmMxICBtZm46IDAwMDA0NmMxDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjIw
XSAgIGdmbjogMDAwMDQ2YzIgIG1mbjogMDAwMDQ2YzINCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzI6MjBdICAgZ2ZuOiAwMDAwNDZjMyAgbWZuOiAwMDAwNDZjMw0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMjoyMF0gICBnZm46IDAwMDA0NmM0ICBtZm46IDAwMDA0NmM0DQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMyOjIwXSAgIGdmbjogMDAwMDQ2YzUgIG1mbjogMDAwMDQ2
YzUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MjBdICAgZ2ZuOiAwMDAwNDZjNiAgbWZu
OiAwMDAwNDZjNg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoyMF0gICBnZm46IDAwMDA0
NmM3ICBtZm46IDAwMDA0NmM3DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjIwXSAgIGdm
bjogMDAwMDQ2YzggIG1mbjogMDAwMDQ2YzgNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6
MjBdICAgZ2ZuOiAwMDAwNDZjOSAgbWZuOiAwMDAwNDZjOQ0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMjoyMF0gICBnZm46IDAwMDA0NmNhICBtZm46IDAwMDA0NmNhDQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMyOjIwXSAgIGdmbjogMDAwMDQ2Y2IgIG1mbjogMDAwMDQ2Y2INCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MjBdICAgZ2ZuOiAwMDAwNDZjYyAgbWZuOiAwMDAw
NDZjYw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoyMF0gICBnZm46IDAwMDA0NmNkICBt
Zm46IDAwMDA0NmNkDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjIwXSAgIGdmbjogMDAw
MDQ2Y2UgIG1mbjogMDAwMDQ2Y2UNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MjBdICAg
Z2ZuOiAwMDAwNDZjZiAgbWZuOiAwMDAwNDZjZg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
MjoyMF0gICBnZm46IDAwMDA0NmQwICBtZm46IDAwMDA0NmQwDQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMyOjIwXSAgIGdmbjogMDAwMDQ2ZDEgIG1mbjogMDAwMDQ2ZDENCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzI6MjBdICAgZ2ZuOiAwMDAwNDZkMiAgbWZuOiAwMDAwNDZkMg0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoyMF0gICBnZm46IDAwMDA0NmQzICBtZm46IDAw
MDA0NmQzDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjIwXSAgIGdmbjogMDAwMDQ2ZDQg
IG1mbjogMDAwMDQ2ZDQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MjBdICAgZ2ZuOiAw
MDAwNDZkNSAgbWZuOiAwMDAwNDZkNQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoyMF0g
ICBnZm46IDAwMDA0NmQ2ICBtZm46IDAwMDA0NmQ2DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMyOjIwXSAgIGdmbjogMDAwMDQ2ZDcgIG1mbjogMDAwMDQ2ZDcNCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzI6MjBdICAgZ2ZuOiAwMDAwNDZkOCAgbWZuOiAwMDAwNDZkOA0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMjoyMF0gICBnZm46IDAwMDA0NmQ5ICBtZm46IDAwMDA0NmQ5
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjIwXSAgIGdmbjogMDAwMDQ2ZGEgIG1mbjog
MDAwMDQ2ZGENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MjBdICAgZ2ZuOiAwMDAwNDZk
YiAgbWZuOiAwMDAwNDZkYg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoyMF0gICBnZm46
IDAwMDA0NmRjICBtZm46IDAwMDA0NmRjDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjIw
XSAgIGdmbjogMDAwMDQ2ZGQgIG1mbjogMDAwMDQ2ZGQNCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzI6MjBdICAgZ2ZuOiAwMDAwNDZkZSAgbWZuOiAwMDAwNDZkZQ0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMjoyMF0gICBnZm46IDAwMDA0NmRmICBtZm46IDAwMDA0NmRmDQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMyOjIwXSAgIGdmbjogMDAwMDQ2ZTAgIG1mbjogMDAwMDQ2
ZTANCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MjBdICAgZ2ZuOiAwMDAwNDZlMSAgbWZu
OiAwMDAwNDZlMQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoyMF0gICBnZm46IDAwMDA0
NmUyICBtZm46IDAwMDA0NmUyDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjIwXSAgIGdm
bjogMDAwMDQ2ZTMgIG1mbjogMDAwMDQ2ZTMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6
MjBdICAgZ2ZuOiAwMDAwNDZlNCAgbWZuOiAwMDAwNDZlNA0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMjoyMF0gICBnZm46IDAwMDA0NmU1ICBtZm46IDAwMDA0NmU1DQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMyOjIwXSAgIGdmbjogMDAwMDQ2ZTYgIG1mbjogMDAwMDQ2ZTYNCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MjBdICAgZ2ZuOiAwMDAwNDZlNyAgbWZuOiAwMDAw
NDZlNw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoyMF0gICBnZm46IDAwMDA0NmU4ICBt
Zm46IDAwMDA0NmU4DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjIwXSAgIGdmbjogMDAw
MDQ2ZTkgIG1mbjogMDAwMDQ2ZTkNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MjBdICAg
Z2ZuOiAwMDAwNDZlYSAgbWZuOiAwMDAwNDZlYQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
MjoyMF0gICBnZm46IDAwMDA0NmViICBtZm46IDAwMDA0NmViDQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMyOjIwXSAgIGdmbjogMDAwMDQ2ZWMgIG1mbjogMDAwMDQ2ZWMNCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzI6MjBdICAgZ2ZuOiAwMDAwNDZlZCAgbWZuOiAwMDAwNDZlZA0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoyMF0gICBnZm46IDAwMDA0NmVlICBtZm46IDAw
MDA0NmVlDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjIwXSAgIGdmbjogMDAwMDQ2ZWYg
IG1mbjogMDAwMDQ2ZWYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MjBdICAgZ2ZuOiAw
MDAwNDZmMCAgbWZuOiAwMDAwNDZmMA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoyMF0g
ICBnZm46IDAwMDA0NmYxICBtZm46IDAwMDA0NmYxDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMyOjIwXSAgIGdmbjogMDAwMDQ2ZjIgIG1mbjogMDAwMDQ2ZjINCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzI6MjBdICAgZ2ZuOiAwMDAwNDZmMyAgbWZuOiAwMDAwNDZmMw0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMjoyMF0gICBnZm46IDAwMDA0NmY0ICBtZm46IDAwMDA0NmY0
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjIwXSAgIGdmbjogMDAwMDQ2ZjUgIG1mbjog
MDAwMDQ2ZjUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MjBdICAgZ2ZuOiAwMDAwNDZm
NiAgbWZuOiAwMDAwNDZmNg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoyMF0gICBnZm46
IDAwMDA0NmY3ICBtZm46IDAwMDA0NmY3DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjIw
XSAgIGdmbjogMDAwMDQ2ZjggIG1mbjogMDAwMDQ2ZjgNCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzI6MjBdICAgZ2ZuOiAwMDAwNDZmOSAgbWZuOiAwMDAwNDZmOQ0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMjoyMF0gICBnZm46IDAwMDA0NmZhICBtZm46IDAwMDA0NmZhDQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMyOjIwXSAgIGdmbjogMDAwMDQ2ZmIgIG1mbjogMDAwMDQ2
ZmINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MjFdICAgZ2ZuOiAwMDAwNDZmYyAgbWZu
OiAwMDAwNDZmYw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoyMV0gICBnZm46IDAwMDA0
NmZkICBtZm46IDAwMDA0NmZkDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjIxXSAgIGdm
bjogMDAwMDQ2ZmUgIG1mbjogMDAwMDQ2ZmUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6
MjFdICAgZ2ZuOiAwMDAwNDZmZiAgbWZuOiAwMDAwNDZmZg0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMjoyMV0gICBnZm46IDAwMDA0NzAwICBtZm46IDAwMDA0NzAwDQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMyOjIxXSAgIGdmbjogMDAwMDQ3MDEgIG1mbjogMDAwMDQ3MDENCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MjFdICAgZ2ZuOiAwMDAwNDcwMiAgbWZuOiAwMDAw
NDcwMg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoyMV0gICBnZm46IDAwMDA0NzAzICBt
Zm46IDAwMDA0NzAzDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjIxXSAgIGdmbjogMDAw
MDQ3MDQgIG1mbjogMDAwMDQ3MDQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MjFdICAg
Z2ZuOiAwMDAwNDcwNSAgbWZuOiAwMDAwNDcwNQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
MjoyMV0gICBnZm46IDAwMDA0NzA2ICBtZm46IDAwMDA0NzA2DQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMyOjIxXSAgIGdmbjogMDAwMDQ3MDcgIG1mbjogMDAwMDQ3MDcNCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzI6MjFdICAgZ2ZuOiAwMDAwNDcwOCAgbWZuOiAwMDAwNDcwOA0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoyMV0gICBnZm46IDAwMDA0NzA5ICBtZm46IDAw
MDA0NzA5DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjIxXSAgIGdmbjogMDAwMDQ3MGEg
IG1mbjogMDAwMDQ3MGENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MjFdICAgZ2ZuOiAw
MDAwNDcwYiAgbWZuOiAwMDAwNDcwYg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoyMV0g
ICBnZm46IDAwMDA0NzBjICBtZm46IDAwMDA0NzBjDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMyOjIxXSAgIGdmbjogMDAwMDQ3MGQgIG1mbjogMDAwMDQ3MGQNCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzI6MjFdICAgZ2ZuOiAwMDAwNDcwZSAgbWZuOiAwMDAwNDcwZQ0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMjoyMV0gICBnZm46IDAwMDA0NzBmICBtZm46IDAwMDA0NzBm
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjIxXSAgIGdmbjogMDAwMDQ3MTAgIG1mbjog
MDAwMDQ3MTANCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MjFdICAgZ2ZuOiAwMDAwNDcx
MSAgbWZuOiAwMDAwNDcxMQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoyMV0gICBnZm46
IDAwMDA0NzEyICBtZm46IDAwMDA0NzEyDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjIx
XSAgIGdmbjogMDAwMDQ3MTMgIG1mbjogMDAwMDQ3MTMNCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzI6MjFdICAgZ2ZuOiAwMDAwNDcxNCAgbWZuOiAwMDAwNDcxNA0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMjoyMV0gICBnZm46IDAwMDA0NzE1ICBtZm46IDAwMDA0NzE1DQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMyOjIxXSAgIGdmbjogMDAwMDQ3MTYgIG1mbjogMDAwMDQ3
MTYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MjFdICAgZ2ZuOiAwMDAwNDcxNyAgbWZu
OiAwMDAwNDcxNw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoyMV0gICBnZm46IDAwMDA0
NzE4ICBtZm46IDAwMDA0NzE4DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjIxXSAgIGdm
bjogMDAwMDQ3MTkgIG1mbjogMDAwMDQ3MTkNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6
MjFdICAgZ2ZuOiAwMDAwNDcxYSAgbWZuOiAwMDAwNDcxYQ0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMjoyMV0gICBnZm46IDAwMDA0NzFiICBtZm46IDAwMDA0NzFiDQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMyOjIxXSAgIGdmbjogMDAwMDQ3MWMgIG1mbjogMDAwMDQ3MWMNCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MjFdICAgZ2ZuOiAwMDAwNDcxZCAgbWZuOiAwMDAw
NDcxZA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoyMV0gICBnZm46IDAwMDA0NzFlICBt
Zm46IDAwMDA0NzFlDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjIxXSAgIGdmbjogMDAw
MDQ3MWYgIG1mbjogMDAwMDQ3MWYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MjFdICAg
Z2ZuOiAwMDAwNDcyMCAgbWZuOiAwMDAwNDcyMA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
MjoyMV0gICBnZm46IDAwMDA0NzIxICBtZm46IDAwMDA0NzIxDQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMyOjIxXSAgIGdmbjogMDAwMDQ3MjIgIG1mbjogMDAwMDQ3MjINCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzI6MjFdICAgZ2ZuOiAwMDAwNDcyMyAgbWZuOiAwMDAwNDcyMw0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoyMV0gICBnZm46IDAwMDA0NzI0ICBtZm46IDAw
MDA0NzI0DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjIxXSAgIGdmbjogMDAwMDQ3MjUg
IG1mbjogMDAwMDQ3MjUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MjFdICAgZ2ZuOiAw
MDAwNDcyNiAgbWZuOiAwMDAwNDcyNg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoyMV0g
ICBnZm46IDAwMDA0NzI3ICBtZm46IDAwMDA0NzI3DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMyOjIxXSAgIGdmbjogMDAwMDQ3MjggIG1mbjogMDAwMDQ3MjgNCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzI6MjFdICAgZ2ZuOiAwMDAwNDcyOSAgbWZuOiAwMDAwNDcyOQ0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMjoyMV0gICBnZm46IDAwMDA0NzJhICBtZm46IDAwMDA0NzJh
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjIxXSAgIGdmbjogMDAwMDQ3MmIgIG1mbjog
MDAwMDQ3MmINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MjFdICAgZ2ZuOiAwMDAwNDcy
YyAgbWZuOiAwMDAwNDcyYw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoyMV0gICBnZm46
IDAwMDA0NzJkICBtZm46IDAwMDA0NzJkDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjIx
XSAgIGdmbjogMDAwMDQ3MmUgIG1mbjogMDAwMDQ3MmUNCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzI6MjFdICAgZ2ZuOiAwMDAwNDcyZiAgbWZuOiAwMDAwNDcyZg0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMjoyMV0gICBnZm46IDAwMDA0NzMwICBtZm46IDAwMDA0NzMwDQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMyOjIxXSAgIGdmbjogMDAwMDQ3MzEgIG1mbjogMDAwMDQ3
MzENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MjFdICAgZ2ZuOiAwMDAwNDczMiAgbWZu
OiAwMDAwNDczMg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoyMV0gICBnZm46IDAwMDA0
NzMzICBtZm46IDAwMDA0NzMzDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjIxXSAgIGdm
bjogMDAwMDQ3MzQgIG1mbjogMDAwMDQ3MzQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6
MjFdICAgZ2ZuOiAwMDAwNDczNSAgbWZuOiAwMDAwNDczNQ0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMjoyMV0gICBnZm46IDAwMDA0NzM2ICBtZm46IDAwMDA0NzM2DQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMyOjIxXSAgIGdmbjogMDAwMDQ3MzcgIG1mbjogMDAwMDQ3MzcNCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MjFdICAgZ2ZuOiAwMDAwNDczOCAgbWZuOiAwMDAw
NDczOA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoyMV0gICBnZm46IDAwMDA0NzM5ICBt
Zm46IDAwMDA0NzM5DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjIxXSAgIGdmbjogMDAw
MDQ3M2EgIG1mbjogMDAwMDQ3M2ENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MjFdICAg
Z2ZuOiAwMDAwNDczYiAgbWZuOiAwMDAwNDczYg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
MjoyMl0gICBnZm46IDAwMDA0NzNjICBtZm46IDAwMDA0NzNjDQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMyOjIyXSAgIGdmbjogMDAwMDQ3M2QgIG1mbjogMDAwMDQ3M2QNCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzI6MjJdICAgZ2ZuOiAwMDAwNDczZSAgbWZuOiAwMDAwNDczZQ0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoyMl0gICBnZm46IDAwMDA0NzNmICBtZm46IDAw
MDA0NzNmDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjIyXSAgIGdmbjogMDAwMDQ3NDAg
IG1mbjogMDAwMDQ3NDANCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MjJdICAgZ2ZuOiAw
MDAwNDc0MSAgbWZuOiAwMDAwNDc0MQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoyMl0g
ICBnZm46IDAwMDA0NzQyICBtZm46IDAwMDA0NzQyDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMyOjIyXSAgIGdmbjogMDAwMDQ3NDMgIG1mbjogMDAwMDQ3NDMNCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzI6MjJdICAgZ2ZuOiAwMDAwNDc0NCAgbWZuOiAwMDAwNDc0NA0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMjoyMl0gICBnZm46IDAwMDA0NzQ1ICBtZm46IDAwMDA0NzQ1
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjIyXSAgIGdmbjogMDAwMDQ3NDYgIG1mbjog
MDAwMDQ3NDYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MjJdICAgZ2ZuOiAwMDAwNDc0
NyAgbWZuOiAwMDAwNDc0Nw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoyMl0gICBnZm46
IDAwMDA0NzQ4ICBtZm46IDAwMDA0NzQ4DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjIy
XSAgIGdmbjogMDAwMDQ3NDkgIG1mbjogMDAwMDQ3NDkNCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzI6MjJdICAgZ2ZuOiAwMDAwNDc0YSAgbWZuOiAwMDAwNDc0YQ0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMjoyMl0gICBnZm46IDAwMDA0NzRiICBtZm46IDAwMDA0NzRiDQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMyOjIyXSAgIGdmbjogMDAwMDQ3NGMgIG1mbjogMDAwMDQ3
NGMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MjJdICAgZ2ZuOiAwMDAwNDc0ZCAgbWZu
OiAwMDAwNDc0ZA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoyMl0gICBnZm46IDAwMDA0
NzRlICBtZm46IDAwMDA0NzRlDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjIyXSAgIGdm
bjogMDAwMDQ3NGYgIG1mbjogMDAwMDQ3NGYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6
MjJdICAgZ2ZuOiAwMDAwNDc1MCAgbWZuOiAwMDAwNDc1MA0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMjoyMl0gICBnZm46IDAwMDA0NzUxICBtZm46IDAwMDA0NzUxDQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMyOjIyXSAgIGdmbjogMDAwMDQ3NTIgIG1mbjogMDAwMDQ3NTINCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MjJdICAgZ2ZuOiAwMDAwNDc1MyAgbWZuOiAwMDAw
NDc1Mw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoyMl0gICBnZm46IDAwMDA0NzU0ICBt
Zm46IDAwMDA0NzU0DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjIyXSAgIGdmbjogMDAw
MDQ3NTUgIG1mbjogMDAwMDQ3NTUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MjJdICAg
Z2ZuOiAwMDAwNDc1NiAgbWZuOiAwMDAwNDc1Ng0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
MjoyMl0gICBnZm46IDAwMDA0NzU3ICBtZm46IDAwMDA0NzU3DQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMyOjIyXSAgIGdmbjogMDAwMDQ3NTggIG1mbjogMDAwMDQ3NTgNCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzI6MjJdICAgZ2ZuOiAwMDAwNDc1OSAgbWZuOiAwMDAwNDc1OQ0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoyMl0gICBnZm46IDAwMDA0NzVhICBtZm46IDAw
MDA0NzVhDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjIyXSAgIGdmbjogMDAwMDQ3NWIg
IG1mbjogMDAwMDQ3NWINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MjJdICAgZ2ZuOiAw
MDAwNDc1YyAgbWZuOiAwMDAwNDc1Yw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoyMl0g
ICBnZm46IDAwMDA0NzVkICBtZm46IDAwMDA0NzVkDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMyOjIyXSAgIGdmbjogMDAwMDQ3NWUgIG1mbjogMDAwMDQ3NWUNCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzI6MjJdICAgZ2ZuOiAwMDAwNDc1ZiAgbWZuOiAwMDAwNDc1Zg0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMjoyMl0gICBnZm46IDAwMDA0NzYwICBtZm46IDAwMDA0NzYw
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjIyXSAgIGdmbjogMDAwMDQ3NjEgIG1mbjog
MDAwMDQ3NjENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MjJdICAgZ2ZuOiAwMDAwNDc2
MiAgbWZuOiAwMDAwNDc2Mg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoyMl0gICBnZm46
IDAwMDA0NzYzICBtZm46IDAwMDA0NzYzDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjIy
XSAgIGdmbjogMDAwMDQ3NjQgIG1mbjogMDAwMDQ3NjQNCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzI6MjJdICAgZ2ZuOiAwMDAwNDc2NSAgbWZuOiAwMDAwNDc2NQ0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMjoyMl0gICBnZm46IDAwMDA0NzY2ICBtZm46IDAwMDA0NzY2DQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMyOjIyXSAgIGdmbjogMDAwMDQ3NjcgIG1mbjogMDAwMDQ3
NjcNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MjJdICAgZ2ZuOiAwMDAwNDc2OCAgbWZu
OiAwMDAwNDc2OA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoyMl0gICBnZm46IDAwMDA0
NzY5ICBtZm46IDAwMDA0NzY5DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjIyXSAgIGdm
bjogMDAwMDQ3NmEgIG1mbjogMDAwMDQ3NmENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6
MjJdICAgZ2ZuOiAwMDAwNDc2YiAgbWZuOiAwMDAwNDc2Yg0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMjoyMl0gICBnZm46IDAwMDA0NzZjICBtZm46IDAwMDA0NzZjDQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMyOjIyXSAgIGdmbjogMDAwMDQ3NmQgIG1mbjogMDAwMDQ3NmQNCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MjJdICAgZ2ZuOiAwMDAwNDc2ZSAgbWZuOiAwMDAw
NDc2ZQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoyMl0gICBnZm46IDAwMDA0NzZmICBt
Zm46IDAwMDA0NzZmDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjIyXSAgIGdmbjogMDAw
MDQ3NzAgIG1mbjogMDAwMDQ3NzANCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MjJdICAg
Z2ZuOiAwMDAwNDc3MSAgbWZuOiAwMDAwNDc3MQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
MjoyMl0gICBnZm46IDAwMDA0NzcyICBtZm46IDAwMDA0NzcyDQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMyOjIyXSAgIGdmbjogMDAwMDQ3NzMgIG1mbjogMDAwMDQ3NzMNCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzI6MjJdICAgZ2ZuOiAwMDAwNDc3NCAgbWZuOiAwMDAwNDc3NA0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoyMl0gICBnZm46IDAwMDA0Nzc1ICBtZm46IDAw
MDA0Nzc1DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjIyXSAgIGdmbjogMDAwMDQ3NzYg
IG1mbjogMDAwMDQ3NzYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MjJdICAgZ2ZuOiAw
MDAwNDc3NyAgbWZuOiAwMDAwNDc3Nw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoyMl0g
ICBnZm46IDAwMDA0Nzc4ICBtZm46IDAwMDA0Nzc4DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMyOjIyXSAgIGdmbjogMDAwMDQ3NzkgIG1mbjogMDAwMDQ3NzkNCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzI6MjJdICAgZ2ZuOiAwMDAwNDc3YSAgbWZuOiAwMDAwNDc3YQ0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMjoyMl0gICBnZm46IDAwMDA0NzdiICBtZm46IDAwMDA0Nzdi
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjIyXSAgIGdmbjogMDAwMDQ3N2MgIG1mbjog
MDAwMDQ3N2MNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MjNdICAgZ2ZuOiAwMDAwNDc3
ZCAgbWZuOiAwMDAwNDc3ZA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoyM10gICBnZm46
IDAwMDA0NzdlICBtZm46IDAwMDA0NzdlDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjIz
XSAgIGdmbjogMDAwMDQ3N2YgIG1mbjogMDAwMDQ3N2YNCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzI6MjNdICAgZ2ZuOiAwMDAwNDc4MCAgbWZuOiAwMDAwNDc4MA0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMjoyM10gICBnZm46IDAwMDA0NzgxICBtZm46IDAwMDA0NzgxDQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMyOjIzXSAgIGdmbjogMDAwMDQ3ODIgIG1mbjogMDAwMDQ3
ODINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MjNdICAgZ2ZuOiAwMDAwNDc4MyAgbWZu
OiAwMDAwNDc4Mw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoyM10gICBnZm46IDAwMDA0
Nzg0ICBtZm46IDAwMDA0Nzg0DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjIzXSAgIGdm
bjogMDAwMDQ3ODUgIG1mbjogMDAwMDQ3ODUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6
MjNdICAgZ2ZuOiAwMDAwNDc4NiAgbWZuOiAwMDAwNDc4Ng0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMjoyM10gICBnZm46IDAwMDA0Nzg3ICBtZm46IDAwMDA0Nzg3DQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMyOjIzXSAgIGdmbjogMDAwMDQ3ODggIG1mbjogMDAwMDQ3ODgNCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MjNdICAgZ2ZuOiAwMDAwNDc4OSAgbWZuOiAwMDAw
NDc4OQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoyM10gICBnZm46IDAwMDA0NzhhICBt
Zm46IDAwMDA0NzhhDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjIzXSAgIGdmbjogMDAw
MDQ3OGIgIG1mbjogMDAwMDQ3OGINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MjNdICAg
Z2ZuOiAwMDAwNDc4YyAgbWZuOiAwMDAwNDc4Yw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
MjoyM10gICBnZm46IDAwMDA0NzhkICBtZm46IDAwMDA0NzhkDQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMyOjIzXSAgIGdmbjogMDAwMDQ3OGUgIG1mbjogMDAwMDQ3OGUNCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzI6MjNdICAgZ2ZuOiAwMDAwNDc4ZiAgbWZuOiAwMDAwNDc4Zg0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoyM10gICBnZm46IDAwMDA0NzkwICBtZm46IDAw
MDA0NzkwDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjIzXSAgIGdmbjogMDAwMDQ3OTEg
IG1mbjogMDAwMDQ3OTENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MjNdICAgZ2ZuOiAw
MDAwNDc5MiAgbWZuOiAwMDAwNDc5Mg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoyM10g
ICBnZm46IDAwMDA0NzkzICBtZm46IDAwMDA0NzkzDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMyOjIzXSAgIGdmbjogMDAwMDQ3OTQgIG1mbjogMDAwMDQ3OTQNCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzI6MjNdICAgZ2ZuOiAwMDAwNDc5NSAgbWZuOiAwMDAwNDc5NQ0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMjoyM10gICBnZm46IDAwMDA0Nzk2ICBtZm46IDAwMDA0Nzk2
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjIzXSAgIGdmbjogMDAwMDQ3OTcgIG1mbjog
MDAwMDQ3OTcNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MjNdICAgZ2ZuOiAwMDAwNDc5
OCAgbWZuOiAwMDAwNDc5OA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoyM10gICBnZm46
IDAwMDA0Nzk5ICBtZm46IDAwMDA0Nzk5DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjIz
XSAgIGdmbjogMDAwMDQ3OWEgIG1mbjogMDAwMDQ3OWENCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzI6MjNdICAgZ2ZuOiAwMDAwNDc5YiAgbWZuOiAwMDAwNDc5Yg0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMjoyM10gICBnZm46IDAwMDA0NzljICBtZm46IDAwMDA0NzljDQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMyOjIzXSAgIGdmbjogMDAwMDQ3OWQgIG1mbjogMDAwMDQ3
OWQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MjNdICAgZ2ZuOiAwMDAwNDc5ZSAgbWZu
OiAwMDAwNDc5ZQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoyM10gICBnZm46IDAwMDA0
NzlmICBtZm46IDAwMDA0NzlmDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjIzXSAgIGdm
bjogMDAwMDQ3YTAgIG1mbjogMDAwMDQ3YTANCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6
MjNdICAgZ2ZuOiAwMDAwNDdhMSAgbWZuOiAwMDAwNDdhMQ0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMjoyM10gICBnZm46IDAwMDA0N2EyICBtZm46IDAwMDA0N2EyDQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMyOjIzXSAgIGdmbjogMDAwMDQ3YTMgIG1mbjogMDAwMDQ3YTMNCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MjNdICAgZ2ZuOiAwMDAwNDdhNCAgbWZuOiAwMDAw
NDdhNA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoyM10gICBnZm46IDAwMDA0N2E1ICBt
Zm46IDAwMDA0N2E1DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjIzXSAgIGdmbjogMDAw
MDQ3YTYgIG1mbjogMDAwMDQ3YTYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MjNdICAg
Z2ZuOiAwMDAwNDdhNyAgbWZuOiAwMDAwNDdhNw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
MjoyM10gICBnZm46IDAwMDA0N2E4ICBtZm46IDAwMDA0N2E4DQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMyOjIzXSAgIGdmbjogMDAwMDQ3YTkgIG1mbjogMDAwMDQ3YTkNCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzI6MjNdICAgZ2ZuOiAwMDAwNDdhYSAgbWZuOiAwMDAwNDdhYQ0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoyM10gICBnZm46IDAwMDA0N2FiICBtZm46IDAw
MDA0N2FiDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjIzXSAgIGdmbjogMDAwMDQ3YWMg
IG1mbjogMDAwMDQ3YWMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MjNdICAgZ2ZuOiAw
MDAwNDdhZCAgbWZuOiAwMDAwNDdhZA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoyM10g
ICBnZm46IDAwMDA0N2FlICBtZm46IDAwMDA0N2FlDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMyOjIzXSAgIGdmbjogMDAwMDQ3YWYgIG1mbjogMDAwMDQ3YWYNCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzI6MjNdICAgZ2ZuOiAwMDAwNDdiMCAgbWZuOiAwMDAwNDdiMA0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMjoyM10gICBnZm46IDAwMDA0N2IxICBtZm46IDAwMDA0N2Ix
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjIzXSAgIGdmbjogMDAwMDQ3YjIgIG1mbjog
MDAwMDQ3YjINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MjNdICAgZ2ZuOiAwMDAwNDdi
MyAgbWZuOiAwMDAwNDdiMw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoyM10gICBnZm46
IDAwMDA0N2I0ICBtZm46IDAwMDA0N2I0DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjIz
XSAgIGdmbjogMDAwMDQ3YjUgIG1mbjogMDAwMDQ3YjUNCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzI6MjNdICAgZ2ZuOiAwMDAwNDdiNiAgbWZuOiAwMDAwNDdiNg0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMjoyM10gICBnZm46IDAwMDA0N2I3ICBtZm46IDAwMDA0N2I3DQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMyOjIzXSAgIGdmbjogMDAwMDQ3YjggIG1mbjogMDAwMDQ3
YjgNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MjNdICAgZ2ZuOiAwMDAwNDdiOSAgbWZu
OiAwMDAwNDdiOQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoyM10gICBnZm46IDAwMDA0
N2JhICBtZm46IDAwMDA0N2JhDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjIzXSAgIGdm
bjogMDAwMDQ3YmIgIG1mbjogMDAwMDQ3YmINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6
MjNdICAgZ2ZuOiAwMDAwNDdiYyAgbWZuOiAwMDAwNDdiYw0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMjoyNF0gICBnZm46IDAwMDA0N2JkICBtZm46IDAwMDA0N2JkDQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMyOjI0XSAgIGdmbjogMDAwMDQ3YmUgIG1mbjogMDAwMDQ3YmUNCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MjRdICAgZ2ZuOiAwMDAwNDdiZiAgbWZuOiAwMDAw
NDdiZg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoyNF0gICBnZm46IDAwMDA0N2MwICBt
Zm46IDAwMDA0N2MwDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjI0XSAgIGdmbjogMDAw
MDQ3YzEgIG1mbjogMDAwMDQ3YzENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MjRdICAg
Z2ZuOiAwMDAwNDdjMiAgbWZuOiAwMDAwNDdjMg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
MjoyNF0gICBnZm46IDAwMDA0N2MzICBtZm46IDAwMDA0N2MzDQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMyOjI0XSAgIGdmbjogMDAwMDQ3YzQgIG1mbjogMDAwMDQ3YzQNCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzI6MjRdICAgZ2ZuOiAwMDAwNDdjNSAgbWZuOiAwMDAwNDdjNQ0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoyNF0gICBnZm46IDAwMDA0N2M2ICBtZm46IDAw
MDA0N2M2DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjI0XSAgIGdmbjogMDAwMDQ3Yzcg
IG1mbjogMDAwMDQ3YzcNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MjRdICAgZ2ZuOiAw
MDAwNDdjOCAgbWZuOiAwMDAwNDdjOA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoyNF0g
ICBnZm46IDAwMDA0N2M5ICBtZm46IDAwMDA0N2M5DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMyOjI0XSAgIGdmbjogMDAwMDQ3Y2EgIG1mbjogMDAwMDQ3Y2ENCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzI6MjRdICAgZ2ZuOiAwMDAwNDdjYiAgbWZuOiAwMDAwNDdjYg0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMjoyNF0gICBnZm46IDAwMDA0N2NjICBtZm46IDAwMDA0N2Nj
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjI0XSAgIGdmbjogMDAwMDQ3Y2QgIG1mbjog
MDAwMDQ3Y2QNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MjRdICAgZ2ZuOiAwMDAwNDdj
ZSAgbWZuOiAwMDAwNDdjZQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoyNF0gICBnZm46
IDAwMDA0N2NmICBtZm46IDAwMDA0N2NmDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjI0
XSAgIGdmbjogMDAwMDQ3ZDAgIG1mbjogMDAwMDQ3ZDANCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzI6MjRdICAgZ2ZuOiAwMDAwNDdkMSAgbWZuOiAwMDAwNDdkMQ0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMjoyNF0gICBnZm46IDAwMDA0N2QyICBtZm46IDAwMDA0N2QyDQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMyOjI0XSAgIGdmbjogMDAwMDQ3ZDMgIG1mbjogMDAwMDQ3
ZDMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MjRdICAgZ2ZuOiAwMDAwNDdkNCAgbWZu
OiAwMDAwNDdkNA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoyNF0gICBnZm46IDAwMDA0
N2Q1ICBtZm46IDAwMDA0N2Q1DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjI0XSAgIGdm
bjogMDAwMDQ3ZDYgIG1mbjogMDAwMDQ3ZDYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6
MjRdICAgZ2ZuOiAwMDAwNDdkNyAgbWZuOiAwMDAwNDdkNw0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMjoyNF0gICBnZm46IDAwMDA0N2Q4ICBtZm46IDAwMDA0N2Q4DQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMyOjI0XSAgIGdmbjogMDAwMDQ3ZDkgIG1mbjogMDAwMDQ3ZDkNCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MjRdICAgZ2ZuOiAwMDAwNDdkYSAgbWZuOiAwMDAw
NDdkYQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoyNF0gICBnZm46IDAwMDA0N2RiICBt
Zm46IDAwMDA0N2RiDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjI0XSAgIGdmbjogMDAw
MDQ3ZGMgIG1mbjogMDAwMDQ3ZGMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MjRdICAg
Z2ZuOiAwMDAwNDdkZCAgbWZuOiAwMDAwNDdkZA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
MjoyNF0gICBnZm46IDAwMDA0N2RlICBtZm46IDAwMDA0N2RlDQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMyOjI0XSAgIGdmbjogMDAwMDQ3ZGYgIG1mbjogMDAwMDQ3ZGYNCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzI6MjRdICAgZ2ZuOiAwMDAwNDdlMCAgbWZuOiAwMDAwNDdlMA0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoyNF0gICBnZm46IDAwMDA0N2UxICBtZm46IDAw
MDA0N2UxDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjI0XSAgIGdmbjogMDAwMDQ3ZTIg
IG1mbjogMDAwMDQ3ZTINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MjRdICAgZ2ZuOiAw
MDAwNDdlMyAgbWZuOiAwMDAwNDdlMw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoyNF0g
ICBnZm46IDAwMDA0N2U0ICBtZm46IDAwMDA0N2U0DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMyOjI0XSAgIGdmbjogMDAwMDQ3ZTUgIG1mbjogMDAwMDQ3ZTUNCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzI6MjRdICAgZ2ZuOiAwMDAwNDdlNiAgbWZuOiAwMDAwNDdlNg0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMjoyNF0gICBnZm46IDAwMDA0N2U3ICBtZm46IDAwMDA0N2U3
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjI0XSAgIGdmbjogMDAwMDQ3ZTggIG1mbjog
MDAwMDQ3ZTgNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MjRdICAgZ2ZuOiAwMDAwNDdl
OSAgbWZuOiAwMDAwNDdlOQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoyNF0gICBnZm46
IDAwMDA0N2VhICBtZm46IDAwMDA0N2VhDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjI0
XSAgIGdmbjogMDAwMDQ3ZWIgIG1mbjogMDAwMDQ3ZWINCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzI6MjRdICAgZ2ZuOiAwMDAwNDdlYyAgbWZuOiAwMDAwNDdlYw0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMjoyNF0gICBnZm46IDAwMDA0N2VkICBtZm46IDAwMDA0N2VkDQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMyOjI0XSAgIGdmbjogMDAwMDQ3ZWUgIG1mbjogMDAwMDQ3
ZWUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MjRdICAgZ2ZuOiAwMDAwNDdlZiAgbWZu
OiAwMDAwNDdlZg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoyNF0gICBnZm46IDAwMDA0
N2YwICBtZm46IDAwMDA0N2YwDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjI0XSAgIGdm
bjogMDAwMDQ3ZjEgIG1mbjogMDAwMDQ3ZjENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6
MjRdICAgZ2ZuOiAwMDAwNDdmMiAgbWZuOiAwMDAwNDdmMg0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMjoyNF0gICBnZm46IDAwMDA0N2YzICBtZm46IDAwMDA0N2YzDQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMyOjI0XSAgIGdmbjogMDAwMDQ3ZjQgIG1mbjogMDAwMDQ3ZjQNCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MjRdICAgZ2ZuOiAwMDAwNDdmNSAgbWZuOiAwMDAw
NDdmNQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoyNF0gICBnZm46IDAwMDA0N2Y2ICBt
Zm46IDAwMDA0N2Y2DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjI0XSAgIGdmbjogMDAw
MDQ3ZjcgIG1mbjogMDAwMDQ3ZjcNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MjRdICAg
Z2ZuOiAwMDAwNDdmOCAgbWZuOiAwMDAwNDdmOA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
MjoyNF0gICBnZm46IDAwMDA0N2Y5ICBtZm46IDAwMDA0N2Y5DQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMyOjI0XSAgIGdmbjogMDAwMDQ3ZmEgIG1mbjogMDAwMDQ3ZmENCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzI6MjRdICAgZ2ZuOiAwMDAwNDdmYiAgbWZuOiAwMDAwNDdmYg0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoyNF0gICBnZm46IDAwMDA0N2ZjICBtZm46IDAw
MDA0N2ZjDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjI1XSAgIGdmbjogMDAwMDQ3ZmQg
IG1mbjogMDAwMDQ3ZmQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MjVdICAgZ2ZuOiAw
MDAwNDdmZSAgbWZuOiAwMDAwNDdmZQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoyNV0g
ICBnZm46IDAwMDA0N2ZmICBtZm46IDAwMDA0N2ZmDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMyOjI1XSAgIGdmbjogMDAwMDQ4MDAgIG1mbjogMDAwMDQ4MDANCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzI6MjVdICAgZ2ZuOiAwMDAwNDgwMSAgbWZuOiAwMDAwNDgwMQ0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMjoyNV0gICBnZm46IDAwMDA0ODAyICBtZm46IDAwMDA0ODAy
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjI1XSAgIGdmbjogMDAwMDQ4MDMgIG1mbjog
MDAwMDQ4MDMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MjVdICAgZ2ZuOiAwMDAwNDgw
NCAgbWZuOiAwMDAwNDgwNA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoyNV0gICBnZm46
IDAwMDA0ODA1ICBtZm46IDAwMDA0ODA1DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjI1
XSAgIGdmbjogMDAwMDQ4MDYgIG1mbjogMDAwMDQ4MDYNCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzI6MjVdICAgZ2ZuOiAwMDAwNDgwNyAgbWZuOiAwMDAwNDgwNw0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMjoyNV0gICBnZm46IDAwMDA0ODA4ICBtZm46IDAwMDA0ODA4DQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMyOjI1XSAgIGdmbjogMDAwMDQ4MDkgIG1mbjogMDAwMDQ4
MDkNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MjVdICAgZ2ZuOiAwMDAwNDgwYSAgbWZu
OiAwMDAwNDgwYQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoyNV0gICBnZm46IDAwMDA0
ODBiICBtZm46IDAwMDA0ODBiDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjI1XSAgIGdm
bjogMDAwMDQ4MGMgIG1mbjogMDAwMDQ4MGMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6
MjVdICAgZ2ZuOiAwMDAwNDgwZCAgbWZuOiAwMDAwNDgwZA0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMjoyNV0gICBnZm46IDAwMDA0ODBlICBtZm46IDAwMDA0ODBlDQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMyOjI1XSAgIGdmbjogMDAwMDQ4MGYgIG1mbjogMDAwMDQ4MGYNCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MjVdICAgZ2ZuOiAwMDAwNDgxMCAgbWZuOiAwMDAw
NDgxMA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoyNV0gICBnZm46IDAwMDA0ODExICBt
Zm46IDAwMDA0ODExDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjI1XSAgIGdmbjogMDAw
MDQ4MTIgIG1mbjogMDAwMDQ4MTINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MjVdICAg
Z2ZuOiAwMDAwNDgxMyAgbWZuOiAwMDAwNDgxMw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
MjoyNV0gICBnZm46IDAwMDA0ODE0ICBtZm46IDAwMDA0ODE0DQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMyOjI1XSAgIGdmbjogMDAwMDQ4MTUgIG1mbjogMDAwMDQ4MTUNCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzI6MjVdICAgZ2ZuOiAwMDAwNDgxNiAgbWZuOiAwMDAwNDgxNg0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoyNV0gICBnZm46IDAwMDA0ODE3ICBtZm46IDAw
MDA0ODE3DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjI1XSAgIGdmbjogMDAwMDQ4MTgg
IG1mbjogMDAwMDQ4MTgNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MjVdICAgZ2ZuOiAw
MDAwNDgxOSAgbWZuOiAwMDAwNDgxOQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoyNV0g
ICBnZm46IDAwMDA0ODFhICBtZm46IDAwMDA0ODFhDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMyOjI1XSAgIGdmbjogMDAwMDQ4MWIgIG1mbjogMDAwMDQ4MWINCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzI6MjVdICAgZ2ZuOiAwMDAwNDgxYyAgbWZuOiAwMDAwNDgxYw0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMjoyNV0gICBnZm46IDAwMDA0ODFkICBtZm46IDAwMDA0ODFk
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjI1XSAgIGdmbjogMDAwMDQ4MWUgIG1mbjog
MDAwMDQ4MWUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MjVdICAgZ2ZuOiAwMDAwNDgx
ZiAgbWZuOiAwMDAwNDgxZg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoyNV0gICBnZm46
IDAwMDA0ODIwICBtZm46IDAwMDA0ODIwDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjI1
XSAgIGdmbjogMDAwMDQ4MjEgIG1mbjogMDAwMDQ4MjENCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzI6MjVdICAgZ2ZuOiAwMDAwNDgyMiAgbWZuOiAwMDAwNDgyMg0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMjoyNV0gICBnZm46IDAwMDA0ODIzICBtZm46IDAwMDA0ODIzDQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMyOjI1XSAgIGdmbjogMDAwMDQ4MjQgIG1mbjogMDAwMDQ4
MjQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MjVdICAgZ2ZuOiAwMDAwNDgyNSAgbWZu
OiAwMDAwNDgyNQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoyNV0gICBnZm46IDAwMDA0
ODI2ICBtZm46IDAwMDA0ODI2DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjI1XSAgIGdm
bjogMDAwMDQ4MjcgIG1mbjogMDAwMDQ4MjcNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6
MjVdICAgZ2ZuOiAwMDAwNDgyOCAgbWZuOiAwMDAwNDgyOA0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMjoyNV0gICBnZm46IDAwMDA0ODI5ICBtZm46IDAwMDA0ODI5DQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMyOjI1XSAgIGdmbjogMDAwMDQ4MmEgIG1mbjogMDAwMDQ4MmENCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MjVdICAgZ2ZuOiAwMDAwNDgyYiAgbWZuOiAwMDAw
NDgyYg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoyNV0gICBnZm46IDAwMDA0ODJjICBt
Zm46IDAwMDA0ODJjDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjI1XSAgIGdmbjogMDAw
MDQ4MmQgIG1mbjogMDAwMDQ4MmQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MjVdICAg
Z2ZuOiAwMDAwNDgyZSAgbWZuOiAwMDAwNDgyZQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
MjoyNV0gICBnZm46IDAwMDA0ODJmICBtZm46IDAwMDA0ODJmDQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMyOjI1XSAgIGdmbjogMDAwMDQ4MzAgIG1mbjogMDAwMDQ4MzANCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzI6MjVdICAgZ2ZuOiAwMDAwNDgzMSAgbWZuOiAwMDAwNDgzMQ0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoyNV0gICBnZm46IDAwMDA0ODMyICBtZm46IDAw
MDA0ODMyDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjI1XSAgIGdmbjogMDAwMDQ4MzMg
IG1mbjogMDAwMDQ4MzMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MjVdICAgZ2ZuOiAw
MDAwNDgzNCAgbWZuOiAwMDAwNDgzNA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoyNV0g
ICBnZm46IDAwMDA0ODM1ICBtZm46IDAwMDA0ODM1DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMyOjI1XSAgIGdmbjogMDAwMDQ4MzYgIG1mbjogMDAwMDQ4MzYNCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzI6MjVdICAgZ2ZuOiAwMDAwNDgzNyAgbWZuOiAwMDAwNDgzNw0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMjoyNV0gICBnZm46IDAwMDA0ODM4ICBtZm46IDAwMDA0ODM4
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjI1XSAgIGdmbjogMDAwMDQ4MzkgIG1mbjog
MDAwMDQ4MzkNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MjVdICAgZ2ZuOiAwMDAwNDgz
YSAgbWZuOiAwMDAwNDgzYQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoyNV0gICBnZm46
IDAwMDA0ODNiICBtZm46IDAwMDA0ODNiDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjI1
XSAgIGdmbjogMDAwMDQ4M2MgIG1mbjogMDAwMDQ4M2MNCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzI6MjZdICAgZ2ZuOiAwMDAwNDgzZCAgbWZuOiAwMDAwNDgzZA0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMjoyNl0gICBnZm46IDAwMDA0ODNlICBtZm46IDAwMDA0ODNlDQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMyOjI2XSAgIGdmbjogMDAwMDQ4M2YgIG1mbjogMDAwMDQ4
M2YNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MjZdICAgZ2ZuOiAwMDAwNDg0MCAgbWZu
OiAwMDAwNDg0MA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoyNl0gICBnZm46IDAwMDA0
ODQxICBtZm46IDAwMDA0ODQxDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjI2XSAgIGdm
bjogMDAwMDQ4NDIgIG1mbjogMDAwMDQ4NDINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6
MjZdICAgZ2ZuOiAwMDAwNDg0MyAgbWZuOiAwMDAwNDg0Mw0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMjoyNl0gICBnZm46IDAwMDA0ODQ0ICBtZm46IDAwMDA0ODQ0DQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMyOjI2XSAgIGdmbjogMDAwMDQ4NDUgIG1mbjogMDAwMDQ4NDUNCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MjZdICAgZ2ZuOiAwMDAwNDg0NiAgbWZuOiAwMDAw
NDg0Ng0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoyNl0gICBnZm46IDAwMDA0ODQ3ICBt
Zm46IDAwMDA0ODQ3DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjI2XSAgIGdmbjogMDAw
MDQ4NDggIG1mbjogMDAwMDQ4NDgNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MjZdICAg
Z2ZuOiAwMDAwNDg0OSAgbWZuOiAwMDAwNDg0OQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
MjoyNl0gICBnZm46IDAwMDA0ODRhICBtZm46IDAwMDA0ODRhDQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMyOjI2XSAgIGdmbjogMDAwMDQ4NGIgIG1mbjogMDAwMDQ4NGINCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzI6MjZdICAgZ2ZuOiAwMDAwNDg0YyAgbWZuOiAwMDAwNDg0Yw0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoyNl0gICBnZm46IDAwMDA0ODRkICBtZm46IDAw
MDA0ODRkDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjI2XSAgIGdmbjogMDAwMDQ4NGUg
IG1mbjogMDAwMDQ4NGUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MjZdICAgZ2ZuOiAw
MDAwNDg0ZiAgbWZuOiAwMDAwNDg0Zg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoyNl0g
ICBnZm46IDAwMDA0ODUwICBtZm46IDAwMDA0ODUwDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMyOjI2XSAgIGdmbjogMDAwMDQ4NTEgIG1mbjogMDAwMDQ4NTENCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzI6MjZdICAgZ2ZuOiAwMDAwNDg1MiAgbWZuOiAwMDAwNDg1Mg0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMjoyNl0gICBnZm46IDAwMDA0ODUzICBtZm46IDAwMDA0ODUz
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjI2XSAgIGdmbjogMDAwMDQ4NTQgIG1mbjog
MDAwMDQ4NTQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MjZdICAgZ2ZuOiAwMDAwNDg1
NSAgbWZuOiAwMDAwNDg1NQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoyNl0gICBnZm46
IDAwMDA0ODU2ICBtZm46IDAwMDA0ODU2DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjI2
XSAgIGdmbjogMDAwMDQ4NTcgIG1mbjogMDAwMDQ4NTcNCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzI6MjZdICAgZ2ZuOiAwMDAwNDg1OCAgbWZuOiAwMDAwNDg1OA0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMjoyNl0gICBnZm46IDAwMDA0ODU5ICBtZm46IDAwMDA0ODU5DQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMyOjI2XSAgIGdmbjogMDAwMDQ4NWEgIG1mbjogMDAwMDQ4
NWENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MjZdICAgZ2ZuOiAwMDAwNDg1YiAgbWZu
OiAwMDAwNDg1Yg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoyNl0gICBnZm46IDAwMDA0
ODVjICBtZm46IDAwMDA0ODVjDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjI2XSAgIGdm
bjogMDAwMDQ4NWQgIG1mbjogMDAwMDQ4NWQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6
MjZdICAgZ2ZuOiAwMDAwNDg1ZSAgbWZuOiAwMDAwNDg1ZQ0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMjoyNl0gICBnZm46IDAwMDA0ODVmICBtZm46IDAwMDA0ODVmDQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMyOjI2XSAgIGdmbjogMDAwMDQ4NjAgIG1mbjogMDAwMDQ4NjANCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MjZdICAgZ2ZuOiAwMDAwNDg2MSAgbWZuOiAwMDAw
NDg2MQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoyNl0gICBnZm46IDAwMDA0ODYyICBt
Zm46IDAwMDA0ODYyDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjI2XSAgIGdmbjogMDAw
MDQ4NjMgIG1mbjogMDAwMDQ4NjMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MjZdICAg
Z2ZuOiAwMDAwNDg2NCAgbWZuOiAwMDAwNDg2NA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
MjoyNl0gICBnZm46IDAwMDA0ODY1ICBtZm46IDAwMDA0ODY1DQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMyOjI2XSAgIGdmbjogMDAwMDQ4NjYgIG1mbjogMDAwMDQ4NjYNCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzI6MjZdICAgZ2ZuOiAwMDAwNDg2NyAgbWZuOiAwMDAwNDg2Nw0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoyNl0gICBnZm46IDAwMDA0ODY4ICBtZm46IDAw
MDA0ODY4DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjI2XSAgIGdmbjogMDAwMDQ4Njkg
IG1mbjogMDAwMDQ4NjkNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MjZdICAgZ2ZuOiAw
MDAwNDg2YSAgbWZuOiAwMDAwNDg2YQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoyNl0g
ICBnZm46IDAwMDA0ODZiICBtZm46IDAwMDA0ODZiDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMyOjI2XSAgIGdmbjogMDAwMDQ4NmMgIG1mbjogMDAwMDQ4NmMNCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzI6MjZdICAgZ2ZuOiAwMDAwNDg2ZCAgbWZuOiAwMDAwNDg2ZA0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMjoyNl0gICBnZm46IDAwMDA0ODZlICBtZm46IDAwMDA0ODZl
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjI2XSAgIGdmbjogMDAwMDQ4NmYgIG1mbjog
MDAwMDQ4NmYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MjZdICAgZ2ZuOiAwMDAwNDg3
MCAgbWZuOiAwMDAwNDg3MA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoyNl0gICBnZm46
IDAwMDA0ODcxICBtZm46IDAwMDA0ODcxDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjI2
XSAgIGdmbjogMDAwMDQ4NzIgIG1mbjogMDAwMDQ4NzINCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzI6MjZdICAgZ2ZuOiAwMDAwNDg3MyAgbWZuOiAwMDAwNDg3Mw0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMjoyNl0gICBnZm46IDAwMDA0ODc0ICBtZm46IDAwMDA0ODc0DQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMyOjI2XSAgIGdmbjogMDAwMDQ4NzUgIG1mbjogMDAwMDQ4
NzUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MjZdICAgZ2ZuOiAwMDAwNDg3NiAgbWZu
OiAwMDAwNDg3Ng0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoyNl0gICBnZm46IDAwMDA0
ODc3ICBtZm46IDAwMDA0ODc3DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjI2XSAgIGdm
bjogMDAwMDQ4NzggIG1mbjogMDAwMDQ4NzgNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6
MjZdICAgZ2ZuOiAwMDAwNDg3OSAgbWZuOiAwMDAwNDg3OQ0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMjoyNl0gICBnZm46IDAwMDA0ODdhICBtZm46IDAwMDA0ODdhDQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMyOjI2XSAgIGdmbjogMDAwMDQ4N2IgIG1mbjogMDAwMDQ4N2INCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MjZdICAgZ2ZuOiAwMDAwNDg3YyAgbWZuOiAwMDAw
NDg3Yw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoyN10gICBnZm46IDAwMDA0ODdkICBt
Zm46IDAwMDA0ODdkDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjI3XSAgIGdmbjogMDAw
MDQ4N2UgIG1mbjogMDAwMDQ4N2UNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MjddICAg
Z2ZuOiAwMDAwNDg3ZiAgbWZuOiAwMDAwNDg3Zg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
MjoyN10gICBnZm46IDAwMDA0ODgwICBtZm46IDAwMDA0ODgwDQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMyOjI3XSAgIGdmbjogMDAwMDQ4ODEgIG1mbjogMDAwMDQ4ODENCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzI6MjddICAgZ2ZuOiAwMDAwNDg4MiAgbWZuOiAwMDAwNDg4Mg0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoyN10gICBnZm46IDAwMDA0ODgzICBtZm46IDAw
MDA0ODgzDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjI3XSAgIGdmbjogMDAwMDQ4ODQg
IG1mbjogMDAwMDQ4ODQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MjddICAgZ2ZuOiAw
MDAwNDg4NSAgbWZuOiAwMDAwNDg4NQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoyN10g
ICBnZm46IDAwMDA0ODg2ICBtZm46IDAwMDA0ODg2DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMyOjI3XSAgIGdmbjogMDAwMDQ4ODcgIG1mbjogMDAwMDQ4ODcNCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzI6MjddICAgZ2ZuOiAwMDAwNDg4OCAgbWZuOiAwMDAwNDg4OA0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMjoyN10gICBnZm46IDAwMDA0ODg5ICBtZm46IDAwMDA0ODg5
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjI3XSAgIGdmbjogMDAwMDQ4OGEgIG1mbjog
MDAwMDQ4OGENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MjddICAgZ2ZuOiAwMDAwNDg4
YiAgbWZuOiAwMDAwNDg4Yg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoyN10gICBnZm46
IDAwMDA0ODhjICBtZm46IDAwMDA0ODhjDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjI3
XSAgIGdmbjogMDAwMDQ4OGQgIG1mbjogMDAwMDQ4OGQNCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzI6MjddICAgZ2ZuOiAwMDAwNDg4ZSAgbWZuOiAwMDAwNDg4ZQ0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMjoyN10gICBnZm46IDAwMDA0ODhmICBtZm46IDAwMDA0ODhmDQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMyOjI3XSAgIGdmbjogMDAwMDQ4OTAgIG1mbjogMDAwMDQ4
OTANCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MjddICAgZ2ZuOiAwMDAwNDg5MSAgbWZu
OiAwMDAwNDg5MQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoyN10gICBnZm46IDAwMDA0
ODkyICBtZm46IDAwMDA0ODkyDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjI3XSAgIGdm
bjogMDAwMDQ4OTMgIG1mbjogMDAwMDQ4OTMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6
MjddICAgZ2ZuOiAwMDAwNDg5NCAgbWZuOiAwMDAwNDg5NA0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMjoyN10gICBnZm46IDAwMDA0ODk1ICBtZm46IDAwMDA0ODk1DQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMyOjI3XSAgIGdmbjogMDAwMDQ4OTYgIG1mbjogMDAwMDQ4OTYNCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MjddICAgZ2ZuOiAwMDAwNDg5NyAgbWZuOiAwMDAw
NDg5Nw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoyN10gICBnZm46IDAwMDA0ODk4ICBt
Zm46IDAwMDA0ODk4DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjI3XSAgIGdmbjogMDAw
MDQ4OTkgIG1mbjogMDAwMDQ4OTkNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MjddICAg
Z2ZuOiAwMDAwNDg5YSAgbWZuOiAwMDAwNDg5YQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
MjoyN10gICBnZm46IDAwMDA0ODliICBtZm46IDAwMDA0ODliDQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMyOjI3XSAgIGdmbjogMDAwMDQ4OWMgIG1mbjogMDAwMDQ4OWMNCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzI6MjddICAgZ2ZuOiAwMDAwNDg5ZCAgbWZuOiAwMDAwNDg5ZA0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoyN10gICBnZm46IDAwMDA0ODllICBtZm46IDAw
MDA0ODllDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjI3XSAgIGdmbjogMDAwMDQ4OWYg
IG1mbjogMDAwMDQ4OWYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MjddICAgZ2ZuOiAw
MDAwNDhhMCAgbWZuOiAwMDAwNDhhMA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoyN10g
ICBnZm46IDAwMDA0OGExICBtZm46IDAwMDA0OGExDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMyOjI3XSAgIGdmbjogMDAwMDQ4YTIgIG1mbjogMDAwMDQ4YTINCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzI6MjddICAgZ2ZuOiAwMDAwNDhhMyAgbWZuOiAwMDAwNDhhMw0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMjoyN10gICBnZm46IDAwMDA0OGE0ICBtZm46IDAwMDA0OGE0
DQoNClsgIDQxMy42MDAyMDVdIGEoWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoyN10gICBnZm46
IDAwMDA0OGE1ICBtZm46IDAwMDA0OGE1DQoNCnRhMS4wMDogZXhjZXB0aW9uIEVtYXNrIDB4
MCBTQWN0KFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MjddICAgZ2ZuOiAwMDAwNDhhNiAgbWZu
OiAwMDAwNDhhNg0KDQogMHgxIFNFcnIgMHgwIGFjKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6
MjddICAgZ2ZuOiAwMDAwNDhhNyAgbWZuOiAwMDAwNDhhNw0KDQp0aW9uIDB4NiBmcm96ZW4N
Cg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoyN10gICBnZm46IDAwMDA0OGE4ICBtZm46
IDAwMDA0OGE4DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjI3XSAgIGdmbjogMDAwMDQ4
YTkgIG1mbjogMDAwMDQ4YTkNCg0KWyAgNDEzLjY5OTU5Ml0gYShYRU4pIFsyMDEyLTA4LTMx
IDIxOjMyOjI3XSAgIGdmbjogMDAwMDQ4YWEgIG1mbjogMDAwMDQ4YWENCg0KdGExLjAwOiBm
YWlsZWQgYyhYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjI3XSAgIGdmbjogMDAwMDQ4YWIgIG1m
bjogMDAwMDQ4YWINCg0Kb21tYW5kOiBSRUFEIEZQRE1BIFFVRVVFRA0KDQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMyOjI3XSAgIGdmbjogMDAwMDQ4YWMgIG1mbjogMDAwMDQ4YWMNCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MjddICAgZ2ZuOiAwMDAwNDhhZCAgbWZuOiAwMDAw
NDhhZA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoyN10gICBnZm46IDAwMDA0OGFlICBt
Zm46IDAwMDA0OGFlDQoNClsgIDQxMy43Nzg1MDRdIGEoWEVOKSBbMjAxMi0wOC0zMSAyMToz
MjoyN10gICBnZm46IDAwMDA0OGFmICBtZm46IDAwMDA0OGFmDQoNCnRhMS4wMDogY21kIDYw
LzEoWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoyN10gICBnZm46IDAwMDA0OGIwICBtZm46IDAw
MDA0OGIwDQoNCjA6MDA6NTE6MTE6OTUvMDAoWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoyN10g
ICBnZm46IDAwMDA0OGIxICBtZm46IDAwMDA0OGIxDQoNCjowMDo4ZTowMDowMC80MCB0YWcg
MCBuY3EgODE5MiBpKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MjddICAgZ2ZuOiAwMDAwNDhi
MiAgbWZuOiAwMDAwNDhiMg0KDQpuDQoNCg0KWyAgNDEzLjc3ODUwNChYRU4pIFsyMDEyLTA4
LTMxIDIxOjMyOjI3XSAgIGdmbjogMDAwMDQ4YjMgIG1mbjogMDAwMDQ4YjMNCg0KXSAgICAg
ICAgICByZXMgNDAvMDA6ZmY6MDA6MDA6MDAoWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoyN10g
ICBnZm46IDAwMDA0OGI0ICBtZm46IDAwMDA0OGI0DQoNCi8wMDowMDowMDowMDowMC8oWEVO
KSBbMjAxMi0wOC0zMSAyMTozMjoyN10gICBnZm46IDAwMDA0OGI1ICBtZm46IDAwMDA0OGI1
DQoNCjAwIEVtYXNrIDB4NCAodGltZW91dCkNCg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
MjoyN10gICBnZm46IDAwMDA0OGI2ICBtZm46IDAwMDA0OGI2DQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMyOjI3XSAgIGdmbjogMDAwMDQ4YjcgIG1mbjogMDAwMDQ4YjcNCg0KWyAgNDEz
Ljk3ODE5OF0gYXRhMS4wMDogc3RhdHVzOiAoWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoyOF0g
ICBnZm46IDAwMDA0OGI4ICBtZm46IDAwMDA0OGI4DQoNCnsgRFJEWSB9DQoNCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzI6MjhdICAgZ2ZuOiAwMDAwNDhiOSAgbWZuOiAwMDAwNDhiOQ0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoyOF0gICBnZm46IDAwMDA0OGJhICBtZm46IDAw
MDA0OGJhDQoNClsgIDQxNC4wMzY0MDddIGEoWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoyOF0g
ICBnZm46IDAwMDA0OGJiICBtZm46IDAwMDA0OGJiDQoNCnRhMTogaGFyZCByZXNldHQoWEVO
KSBbMjAxMi0wOC0zMSAyMTozMjoyOF0gICBnZm46IDAwMDA0OGJjICBtZm46IDAwMDA0OGJj
DQoNCmluZyBsaW5rDQoNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MjhdICAgZ2ZuOiAw
MDAwNDhiZCAgbWZuOiAwMDAwNDhiZA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoyOF0g
ICBnZm46IDAwMDA0OGJlICBtZm46IDAwMDA0OGJlDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMyOjI4XSAgIGdmbjogMDAwMDQ4YmYgIG1mbjogMDAwMDQ4YmYNCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzI6MjhdICAgZ2ZuOiAwMDAwNDhjMCAgbWZuOiAwMDAwNDhjMA0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMjoyOF0gICBnZm46IDAwMDA0OGMxICBtZm46IDAwMDA0OGMx
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjI4XSAgIGdmbjogMDAwMDQ4YzIgIG1mbjog
MDAwMDQ4YzINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MjhdICAgZ2ZuOiAwMDAwNDhj
MyAgbWZuOiAwMDAwNDhjMw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoyOF0gICBnZm46
IDAwMDA0OGM0ICBtZm46IDAwMDA0OGM0DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjI4
XSAgIGdmbjogMDAwMDQ4YzUgIG1mbjogMDAwMDQ4YzUNCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzI6MjhdICAgZ2ZuOiAwMDAwNDhjNiAgbWZuOiAwMDAwNDhjNg0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMjoyOF0gICBnZm46IDAwMDA0OGM3ICBtZm46IDAwMDA0OGM3DQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMyOjI4XSAgIGdmbjogMDAwMDQ4YzggIG1mbjogMDAwMDQ4
YzgNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MjhdICAgZ2ZuOiAwMDAwNDhjOSAgbWZu
OiAwMDAwNDhjOQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoyOF0gICBnZm46IDAwMDA0
OGNhICBtZm46IDAwMDA0OGNhDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjI4XSAgIGdm
bjogMDAwMDQ4Y2IgIG1mbjogMDAwMDQ4Y2INCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6
MjhdICAgZ2ZuOiAwMDAwNDhjYyAgbWZuOiAwMDAwNDhjYw0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMjoyOF0gICBnZm46IDAwMDA0OGNkICBtZm46IDAwMDA0OGNkDQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMyOjI4XSAgIGdmbjogMDAwMDQ4Y2UgIG1mbjogMDAwMDQ4Y2UNCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MjhdICAgZ2ZuOiAwMDAwNDhjZiAgbWZuOiAwMDAw
NDhjZg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoyOF0gICBnZm46IDAwMDA0OGQwICBt
Zm46IDAwMDA0OGQwDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjI4XSAgIGdmbjogMDAw
MDQ4ZDEgIG1mbjogMDAwMDQ4ZDENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MjhdICAg
Z2ZuOiAwMDAwNDhkMiAgbWZuOiAwMDAwNDhkMg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
MjoyOF0gICBnZm46IDAwMDA0OGQzICBtZm46IDAwMDA0OGQzDQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMyOjI4XSAgIGdmbjogMDAwMDQ4ZDQgIG1mbjogMDAwMDQ4ZDQNCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzI6MjhdICAgZ2ZuOiAwMDAwNDhkNSAgbWZuOiAwMDAwNDhkNQ0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoyOF0gICBnZm46IDAwMDA0OGQ2ICBtZm46IDAw
MDA0OGQ2DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjI4XSAgIGdmbjogMDAwMDQ4ZDcg
IG1mbjogMDAwMDQ4ZDcNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MjhdICAgZ2ZuOiAw
MDAwNDhkOCAgbWZuOiAwMDAwNDhkOA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoyOF0g
ICBnZm46IDAwMDA0OGQ5ICBtZm46IDAwMDA0OGQ5DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMyOjI4XSAgIGdmbjogMDAwMDQ4ZGEgIG1mbjogMDAwMDQ4ZGENCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzI6MjhdICAgZ2ZuOiAwMDAwNDhkYiAgbWZuOiAwMDAwNDhkYg0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMjoyOF0gICBnZm46IDAwMDA0OGRjICBtZm46IDAwMDA0OGRj
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjI4XSAgIGdmbjogMDAwMDQ4ZGQgIG1mbjog
MDAwMDQ4ZGQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MjhdICAgZ2ZuOiAwMDAwNDhk
ZSAgbWZuOiAwMDAwNDhkZQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoyOF0gICBnZm46
IDAwMDA0OGRmICBtZm46IDAwMDA0OGRmDQoNClsgIDQxNC42MjMyMTRdIGF0YTE6IFNBVEEg
bGluayB1KFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MjhdICAgZ2ZuOiAwMDAwNDhlMCAgbWZu
OiAwMDAwNDhlMA0KDQpwIDMuMCBHYnBzIChTU3RhKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6
MjhdICAgZ2ZuOiAwMDAwNDhlMSAgbWZuOiAwMDAwNDhlMQ0KDQp0dXMgMTIzIFNDb250cm9s
KFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MjhdICAgZ2ZuOiAwMDAwNDhlMiAgbWZuOiAwMDAw
NDhlMg0KDQogMzAwKQ0KDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjI4XSAgIGdmbjog
MDAwMDQ4ZTMgIG1mbjogMDAwMDQ4ZTMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6Mjhd
ICAgZ2ZuOiAwMDAwNDhlNCAgbWZuOiAwMDAwNDhlNA0KDQooWEVOKSBbMjAxMi0wOC0zMSAy
MTozMjoyOF0gICBnZm46IDAwMDA0OGU1ICBtZm46IDAwMDA0OGU1DQoNCihYRU4pIFsyMDEy
LTA4LTMxIDIxOjMyOjI4XSAgIGdmbjogMDAwMDQ4ZTYgIG1mbjogMDAwMDQ4ZTYNCg0KKFhF
TikgWzIwMTItMDgtMzEgMjE6MzI6MjhdICAgZ2ZuOiAwMDAwNDhlNyAgbWZuOiAwMDAwNDhl
Nw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoyOF0gICBnZm46IDAwMDA0OGU4ICBtZm46
IDAwMDA0OGU4DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjI4XSAgIGdmbjogMDAwMDQ4
ZTkgIG1mbjogMDAwMDQ4ZTkNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MjhdICAgZ2Zu
OiAwMDAwNDhlYSAgbWZuOiAwMDAwNDhlYQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoy
OF0gICBnZm46IDAwMDA0OGViICBtZm46IDAwMDA0OGViDQoNCihYRU4pIFsyMDEyLTA4LTMx
IDIxOjMyOjI4XSAgIGdmbjogMDAwMDQ4ZWMgIG1mbjogMDAwMDQ4ZWMNCg0KKFhFTikgWzIw
MTItMDgtMzEgMjE6MzI6MjhdICAgZ2ZuOiAwMDAwNDhlZCAgbWZuOiAwMDAwNDhlZA0KDQoo
WEVOKSBbMjAxMi0wOC0zMSAyMTozMjoyOF0gICBnZm46IDAwMDA0OGVlICBtZm46IDAwMDA0
OGVlDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjI4XSAgIGdmbjogMDAwMDQ4ZWYgIG1m
bjogMDAwMDQ4ZWYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MjhdICAgZ2ZuOiAwMDAw
NDhmMCAgbWZuOiAwMDAwNDhmMA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoyOF0gICBn
Zm46IDAwMDA0OGYxICBtZm46IDAwMDA0OGYxDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMy
OjI4XSAgIGdmbjogMDAwMDQ4ZjIgIG1mbjogMDAwMDQ4ZjINCg0KKFhFTikgWzIwMTItMDgt
MzEgMjE6MzI6MjhdICAgZ2ZuOiAwMDAwNDhmMyAgbWZuOiAwMDAwNDhmMw0KDQooWEVOKSBb
MjAxMi0wOC0zMSAyMTozMjoyOF0gICBnZm46IDAwMDA0OGY0ICBtZm46IDAwMDA0OGY0DQoN
CihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjI5XSAgIGdmbjogMDAwMDQ4ZjUgIG1mbjogMDAw
MDQ4ZjUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MjldICAgZ2ZuOiAwMDAwNDhmNiAg
bWZuOiAwMDAwNDhmNg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoyOV0gICBnZm46IDAw
MDA0OGY3ICBtZm46IDAwMDA0OGY3DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjI5XSAg
IGdmbjogMDAwMDQ4ZjggIG1mbjogMDAwMDQ4ZjgNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6
MzI6MjldICAgZ2ZuOiAwMDAwNDhmOSAgbWZuOiAwMDAwNDhmOQ0KDQooWEVOKSBbMjAxMi0w
OC0zMSAyMTozMjoyOV0gICBnZm46IDAwMDA0OGZhICBtZm46IDAwMDA0OGZhDQoNCihYRU4p
IFsyMDEyLTA4LTMxIDIxOjMyOjI5XSAgIGdmbjogMDAwMDQ4ZmIgIG1mbjogMDAwMDQ4ZmIN
Cg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MjldICAgZ2ZuOiAwMDAwNDhmYyAgbWZuOiAw
MDAwNDhmYw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoyOV0gICBnZm46IDAwMDA0OGZk
ICBtZm46IDAwMDA0OGZkDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjI5XSAgIGdmbjog
MDAwMDQ4ZmUgIG1mbjogMDAwMDQ4ZmUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6Mjld
ICAgZ2ZuOiAwMDAwNDhmZiAgbWZuOiAwMDAwNDhmZg0KDQooWEVOKSBbMjAxMi0wOC0zMSAy
MTozMjoyOV0gICBnZm46IDAwMDA0OTAwICBtZm46IDAwMDA0OTAwDQoNCihYRU4pIFsyMDEy
LTA4LTMxIDIxOjMyOjI5XSAgIGdmbjogMDAwMDQ5MDEgIG1mbjogMDAwMDQ5MDENCg0KKFhF
TikgWzIwMTItMDgtMzEgMjE6MzI6MjldICAgZ2ZuOiAwMDAwNDkwMiAgbWZuOiAwMDAwNDkw
Mg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoyOV0gICBnZm46IDAwMDA0OTAzICBtZm46
IDAwMDA0OTAzDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjI5XSAgIGdmbjogMDAwMDQ5
MDQgIG1mbjogMDAwMDQ5MDQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MjldICAgZ2Zu
OiAwMDAwNDkwNSAgbWZuOiAwMDAwNDkwNQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoy
OV0gICBnZm46IDAwMDA0OTA2ICBtZm46IDAwMDA0OTA2DQoNCihYRU4pIFsyMDEyLTA4LTMx
IDIxOjMyOjI5XSAgIGdmbjogMDAwMDQ5MDcgIG1mbjogMDAwMDQ5MDcNCg0KKFhFTikgWzIw
MTItMDgtMzEgMjE6MzI6MjldICAgZ2ZuOiAwMDAwNDkwOCAgbWZuOiAwMDAwNDkwOA0KDQoo
WEVOKSBbMjAxMi0wOC0zMSAyMTozMjoyOV0gICBnZm46IDAwMDA0OTA5ICBtZm46IDAwMDA0
OTA5DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjI5XSAgIGdmbjogMDAwMDQ5MGEgIG1m
bjogMDAwMDQ5MGENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MjldICAgZ2ZuOiAwMDAw
NDkwYiAgbWZuOiAwMDAwNDkwYg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoyOV0gICBn
Zm46IDAwMDA0OTBjICBtZm46IDAwMDA0OTBjDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMy
OjI5XSAgIGdmbjogMDAwMDQ5MGQgIG1mbjogMDAwMDQ5MGQNCg0KKFhFTikgWzIwMTItMDgt
MzEgMjE6MzI6MjldICAgZ2ZuOiAwMDAwNDkwZSAgbWZuOiAwMDAwNDkwZQ0KDQooWEVOKSBb
MjAxMi0wOC0zMSAyMTozMjoyOV0gICBnZm46IDAwMDA0OTBmICBtZm46IDAwMDA0OTBmDQoN
CihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjI5XSAgIGdmbjogMDAwMDQ5MTAgIG1mbjogMDAw
MDQ5MTANCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MjldICAgZ2ZuOiAwMDAwNDkxMSAg
bWZuOiAwMDAwNDkxMQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoyOV0gICBnZm46IDAw
MDA0OTEyICBtZm46IDAwMDA0OTEyDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjI5XSAg
IGdmbjogMDAwMDQ5MTMgIG1mbjogMDAwMDQ5MTMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6
MzI6MjldICAgZ2ZuOiAwMDAwNDkxNCAgbWZuOiAwMDAwNDkxNA0KDQooWEVOKSBbMjAxMi0w
OC0zMSAyMTozMjoyOV0gICBnZm46IDAwMDA0OTE1ICBtZm46IDAwMDA0OTE1DQoNCihYRU4p
IFsyMDEyLTA4LTMxIDIxOjMyOjI5XSAgIGdmbjogMDAwMDQ5MTYgIG1mbjogMDAwMDQ5MTYN
Cg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MjldICAgZ2ZuOiAwMDAwNDkxNyAgbWZuOiAw
MDAwNDkxNw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoyOV0gICBnZm46IDAwMDA0OTE4
ICBtZm46IDAwMDA0OTE4DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjI5XSAgIGdmbjog
MDAwMDQ5MTkgIG1mbjogMDAwMDQ5MTkNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6Mjld
ICAgZ2ZuOiAwMDAwNDkxYSAgbWZuOiAwMDAwNDkxYQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAy
MTozMjoyOV0gICBnZm46IDAwMDA0OTFiICBtZm46IDAwMDA0OTFiDQoNCihYRU4pIFsyMDEy
LTA4LTMxIDIxOjMyOjI5XSAgIGdmbjogMDAwMDQ5MWMgIG1mbjogMDAwMDQ5MWMNCg0KKFhF
TikgWzIwMTItMDgtMzEgMjE6MzI6MjldICAgZ2ZuOiAwMDAwNDkxZCAgbWZuOiAwMDAwNDkx
ZA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoyOV0gICBnZm46IDAwMDA0OTFlICBtZm46
IDAwMDA0OTFlDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjI5XSAgIGdmbjogMDAwMDQ5
MWYgIG1mbjogMDAwMDQ5MWYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MjldICAgZ2Zu
OiAwMDAwNDkyMCAgbWZuOiAwMDAwNDkyMA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoy
OV0gICBnZm46IDAwMDA0OTIxICBtZm46IDAwMDA0OTIxDQoNCihYRU4pIFsyMDEyLTA4LTMx
IDIxOjMyOjI5XSAgIGdmbjogMDAwMDQ5MjIgIG1mbjogMDAwMDQ5MjINCg0KKFhFTikgWzIw
MTItMDgtMzEgMjE6MzI6MjldICAgZ2ZuOiAwMDAwNDkyMyAgbWZuOiAwMDAwNDkyMw0KDQoo
WEVOKSBbMjAxMi0wOC0zMSAyMTozMjoyOV0gICBnZm46IDAwMDA0OTI0ICBtZm46IDAwMDA0
OTI0DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjI5XSAgIGdmbjogMDAwMDQ5MjUgIG1m
bjogMDAwMDQ5MjUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MjldICAgZ2ZuOiAwMDAw
NDkyNiAgbWZuOiAwMDAwNDkyNg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoyOV0gICBn
Zm46IDAwMDA0OTI3ICBtZm46IDAwMDA0OTI3DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMy
OjI5XSAgIGdmbjogMDAwMDQ5MjggIG1mbjogMDAwMDQ5MjgNCg0KKFhFTikgWzIwMTItMDgt
MzEgMjE6MzI6MjldICAgZ2ZuOiAwMDAwNDkyOSAgbWZuOiAwMDAwNDkyOQ0KDQooWEVOKSBb
MjAxMi0wOC0zMSAyMTozMjoyOV0gICBnZm46IDAwMDA0OTJhICBtZm46IDAwMDA0OTJhDQoN
CihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjI5XSAgIGdmbjogMDAwMDQ5MmIgIG1mbjogMDAw
MDQ5MmINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MjldICAgZ2ZuOiAwMDAwNDkyYyAg
bWZuOiAwMDAwNDkyYw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoyOV0gICBnZm46IDAw
MDA0OTJkICBtZm46IDAwMDA0OTJkDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjI5XSAg
IGdmbjogMDAwMDQ5MmUgIG1mbjogMDAwMDQ5MmUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6
MzI6MjldICAgZ2ZuOiAwMDAwNDkyZiAgbWZuOiAwMDAwNDkyZg0KDQooWEVOKSBbMjAxMi0w
OC0zMSAyMTozMjoyOV0gICBnZm46IDAwMDA0OTMwICBtZm46IDAwMDA0OTMwDQoNCihYRU4p
IFsyMDEyLTA4LTMxIDIxOjMyOjI5XSAgIGdmbjogMDAwMDQ5MzEgIG1mbjogMDAwMDQ5MzEN
Cg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MjldICAgZ2ZuOiAwMDAwNDkzMiAgbWZuOiAw
MDAwNDkzMg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoyOV0gICBnZm46IDAwMDA0OTMz
ICBtZm46IDAwMDA0OTMzDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjI5XSAgIGdmbjog
MDAwMDQ5MzQgIG1mbjogMDAwMDQ5MzQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6Mjld
ICAgZ2ZuOiAwMDAwNDkzNSAgbWZuOiAwMDAwNDkzNQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAy
MTozMjozMF0gICBnZm46IDAwMDA0OTM2ICBtZm46IDAwMDA0OTM2DQoNCihYRU4pIFsyMDEy
LTA4LTMxIDIxOjMyOjMwXSAgIGdmbjogMDAwMDQ5MzcgIG1mbjogMDAwMDQ5MzcNCg0KKFhF
TikgWzIwMTItMDgtMzEgMjE6MzI6MzBdICAgZ2ZuOiAwMDAwNDkzOCAgbWZuOiAwMDAwNDkz
OA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjozMF0gICBnZm46IDAwMDA0OTM5ICBtZm46
IDAwMDA0OTM5DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjMwXSAgIGdmbjogMDAwMDQ5
M2EgIG1mbjogMDAwMDQ5M2ENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MzBdICAgZ2Zu
OiAwMDAwNDkzYiAgbWZuOiAwMDAwNDkzYg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoz
MF0gICBnZm46IDAwMDA0OTNjICBtZm46IDAwMDA0OTNjDQoNCihYRU4pIFsyMDEyLTA4LTMx
IDIxOjMyOjMwXSAgIGdmbjogMDAwMDQ5M2QgIG1mbjogMDAwMDQ5M2QNCg0KKFhFTikgWzIw
MTItMDgtMzEgMjE6MzI6MzBdICAgZ2ZuOiAwMDAwNDkzZSAgbWZuOiAwMDAwNDkzZQ0KDQoo
WEVOKSBbMjAxMi0wOC0zMSAyMTozMjozMF0gICBnZm46IDAwMDA0OTNmICBtZm46IDAwMDA0
OTNmDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjMwXSAgIGdmbjogMDAwMDQ5NDAgIG1m
bjogMDAwMDQ5NDANCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MzBdICAgZ2ZuOiAwMDAw
NDk0MSAgbWZuOiAwMDAwNDk0MQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjozMF0gICBn
Zm46IDAwMDA0OTQyICBtZm46IDAwMDA0OTQyDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMy
OjMwXSAgIGdmbjogMDAwMDQ5NDMgIG1mbjogMDAwMDQ5NDMNCg0KKFhFTikgWzIwMTItMDgt
MzEgMjE6MzI6MzBdICAgZ2ZuOiAwMDAwNDk0NCAgbWZuOiAwMDAwNDk0NA0KDQooWEVOKSBb
MjAxMi0wOC0zMSAyMTozMjozMF0gICBnZm46IDAwMDA0OTQ1ICBtZm46IDAwMDA0OTQ1DQoN
CihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjMwXSAgIGdmbjogMDAwMDQ5NDYgIG1mbjogMDAw
MDQ5NDYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MzBdICAgZ2ZuOiAwMDAwNDk0NyAg
bWZuOiAwMDAwNDk0Nw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjozMF0gICBnZm46IDAw
MDA0OTQ4ICBtZm46IDAwMDA0OTQ4DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjMwXSAg
IGdmbjogMDAwMDQ5NDkgIG1mbjogMDAwMDQ5NDkNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6
MzI6MzBdICAgZ2ZuOiAwMDAwNDk0YSAgbWZuOiAwMDAwNDk0YQ0KDQooWEVOKSBbMjAxMi0w
OC0zMSAyMTozMjozMF0gICBnZm46IDAwMDA0OTRiICBtZm46IDAwMDA0OTRiDQoNCihYRU4p
IFsyMDEyLTA4LTMxIDIxOjMyOjMwXSAgIGdmbjogMDAwMDQ5NGMgIG1mbjogMDAwMDQ5NGMN
Cg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MzBdICAgZ2ZuOiAwMDAwNDk0ZCAgbWZuOiAw
MDAwNDk0ZA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjozMF0gICBnZm46IDAwMDA0OTRl
ICBtZm46IDAwMDA0OTRlDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjMwXSAgIGdmbjog
MDAwMDQ5NGYgIG1mbjogMDAwMDQ5NGYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MzBd
ICAgZ2ZuOiAwMDAwNDk1MCAgbWZuOiAwMDAwNDk1MA0KDQooWEVOKSBbMjAxMi0wOC0zMSAy
MTozMjozMF0gICBnZm46IDAwMDA0OTUxICBtZm46IDAwMDA0OTUxDQoNCihYRU4pIFsyMDEy
LTA4LTMxIDIxOjMyOjMwXSAgIGdmbjogMDAwMDQ5NTIgIG1mbjogMDAwMDQ5NTINCg0KKFhF
TikgWzIwMTItMDgtMzEgMjE6MzI6MzBdICAgZ2ZuOiAwMDAwNDk1MyAgbWZuOiAwMDAwNDk1
Mw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjozMF0gICBnZm46IDAwMDA0OTU0ICBtZm46
IDAwMDA0OTU0DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjMwXSAgIGdmbjogMDAwMDQ5
NTUgIG1mbjogMDAwMDQ5NTUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MzBdICAgZ2Zu
OiAwMDAwNDk1NiAgbWZuOiAwMDAwNDk1Ng0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoz
MF0gICBnZm46IDAwMDA0OTU3ICBtZm46IDAwMDA0OTU3DQoNCihYRU4pIFsyMDEyLTA4LTMx
IDIxOjMyOjMwXSAgIGdmbjogMDAwMDQ5NTggIG1mbjogMDAwMDQ5NTgNCg0KKFhFTikgWzIw
MTItMDgtMzEgMjE6MzI6MzBdICAgZ2ZuOiAwMDAwNDk1OSAgbWZuOiAwMDAwNDk1OQ0KDQoo
WEVOKSBbMjAxMi0wOC0zMSAyMTozMjozMF0gICBnZm46IDAwMDA0OTVhICBtZm46IDAwMDA0
OTVhDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjMwXSAgIGdmbjogMDAwMDQ5NWIgIG1m
bjogMDAwMDQ5NWINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MzBdICAgZ2ZuOiAwMDAw
NDk1YyAgbWZuOiAwMDAwNDk1Yw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjozMF0gICBn
Zm46IDAwMDA0OTVkICBtZm46IDAwMDA0OTVkDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMy
OjMwXSAgIGdmbjogMDAwMDQ5NWUgIG1mbjogMDAwMDQ5NWUNCg0KKFhFTikgWzIwMTItMDgt
MzEgMjE6MzI6MzBdICAgZ2ZuOiAwMDAwNDk1ZiAgbWZuOiAwMDAwNDk1Zg0KDQooWEVOKSBb
MjAxMi0wOC0zMSAyMTozMjozMF0gICBnZm46IDAwMDA0OTYwICBtZm46IDAwMDA0OTYwDQoN
CihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjMwXSAgIGdmbjogMDAwMDQ5NjEgIG1mbjogMDAw
MDQ5NjENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MzBdICAgZ2ZuOiAwMDAwNDk2MiAg
bWZuOiAwMDAwNDk2Mg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjozMF0gICBnZm46IDAw
MDA0OTYzICBtZm46IDAwMDA0OTYzDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjMwXSAg
IGdmbjogMDAwMDQ5NjQgIG1mbjogMDAwMDQ5NjQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6
MzI6MzBdICAgZ2ZuOiAwMDAwNDk2NSAgbWZuOiAwMDAwNDk2NQ0KDQooWEVOKSBbMjAxMi0w
OC0zMSAyMTozMjozMF0gICBnZm46IDAwMDA0OTY2ICBtZm46IDAwMDA0OTY2DQoNCihYRU4p
IFsyMDEyLTA4LTMxIDIxOjMyOjMwXSAgIGdmbjogMDAwMDQ5NjcgIG1mbjogMDAwMDQ5NjcN
Cg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MzBdICAgZ2ZuOiAwMDAwNDk2OCAgbWZuOiAw
MDAwNDk2OA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjozMF0gICBnZm46IDAwMDA0OTY5
ICBtZm46IDAwMDA0OTY5DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjMwXSAgIGdmbjog
MDAwMDQ5NmEgIG1mbjogMDAwMDQ5NmENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MzBd
ICAgZ2ZuOiAwMDAwNDk2YiAgbWZuOiAwMDAwNDk2Yg0KDQooWEVOKSBbMjAxMi0wOC0zMSAy
MTozMjozMF0gICBnZm46IDAwMDA0OTZjICBtZm46IDAwMDA0OTZjDQoNCihYRU4pIFsyMDEy
LTA4LTMxIDIxOjMyOjMwXSAgIGdmbjogMDAwMDQ5NmQgIG1mbjogMDAwMDQ5NmQNCg0KKFhF
TikgWzIwMTItMDgtMzEgMjE6MzI6MzBdICAgZ2ZuOiAwMDAwNDk2ZSAgbWZuOiAwMDAwNDk2
ZQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjozMF0gICBnZm46IDAwMDA0OTZmICBtZm46
IDAwMDA0OTZmDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjMwXSAgIGdmbjogMDAwMDQ5
NzAgIG1mbjogMDAwMDQ5NzANCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MzBdICAgZ2Zu
OiAwMDAwNDk3MSAgbWZuOiAwMDAwNDk3MQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoz
MF0gICBnZm46IDAwMDA0OTcyICBtZm46IDAwMDA0OTcyDQoNCihYRU4pIFsyMDEyLTA4LTMx
IDIxOjMyOjMwXSAgIGdmbjogMDAwMDQ5NzMgIG1mbjogMDAwMDQ5NzMNCg0KKFhFTikgWzIw
MTItMDgtMzEgMjE6MzI6MzBdICAgZ2ZuOiAwMDAwNDk3NCAgbWZuOiAwMDAwNDk3NA0KDQoo
WEVOKSBbMjAxMi0wOC0zMSAyMTozMjozMF0gICBnZm46IDAwMDA0OTc1ICBtZm46IDAwMDA0
OTc1DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjMxXSAgIGdmbjogMDAwMDQ5NzYgIG1m
bjogMDAwMDQ5NzYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MzFdICAgZ2ZuOiAwMDAw
NDk3NyAgbWZuOiAwMDAwNDk3Nw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjozMV0gICBn
Zm46IDAwMDA0OTc4ICBtZm46IDAwMDA0OTc4DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMy
OjMxXSAgIGdmbjogMDAwMDQ5NzkgIG1mbjogMDAwMDQ5NzkNCg0KKFhFTikgWzIwMTItMDgt
MzEgMjE6MzI6MzFdICAgZ2ZuOiAwMDAwNDk3YSAgbWZuOiAwMDAwNDk3YQ0KDQooWEVOKSBb
MjAxMi0wOC0zMSAyMTozMjozMV0gICBnZm46IDAwMDA0OTdiICBtZm46IDAwMDA0OTdiDQoN
CihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjMxXSAgIGdmbjogMDAwMDQ5N2MgIG1mbjogMDAw
MDQ5N2MNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MzFdICAgZ2ZuOiAwMDAwNDk3ZCAg
bWZuOiAwMDAwNDk3ZA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjozMV0gICBnZm46IDAw
MDA0OTdlICBtZm46IDAwMDA0OTdlDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjMxXSAg
IGdmbjogMDAwMDQ5N2YgIG1mbjogMDAwMDQ5N2YNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6
MzI6MzFdICAgZ2ZuOiAwMDAwNDk4MCAgbWZuOiAwMDAwNDk4MA0KDQooWEVOKSBbMjAxMi0w
OC0zMSAyMTozMjozMV0gICBnZm46IDAwMDA0OTgxICBtZm46IDAwMDA0OTgxDQoNCihYRU4p
IFsyMDEyLTA4LTMxIDIxOjMyOjMxXSAgIGdmbjogMDAwMDQ5ODIgIG1mbjogMDAwMDQ5ODIN
Cg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MzFdICAgZ2ZuOiAwMDAwNDk4MyAgbWZuOiAw
MDAwNDk4Mw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjozMV0gICBnZm46IDAwMDA0OTg0
ICBtZm46IDAwMDA0OTg0DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjMxXSAgIGdmbjog
MDAwMDQ5ODUgIG1mbjogMDAwMDQ5ODUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MzFd
ICAgZ2ZuOiAwMDAwNDk4NiAgbWZuOiAwMDAwNDk4Ng0KDQooWEVOKSBbMjAxMi0wOC0zMSAy
MTozMjozMV0gICBnZm46IDAwMDA0OTg3ICBtZm46IDAwMDA0OTg3DQoNCihYRU4pIFsyMDEy
LTA4LTMxIDIxOjMyOjMxXSAgIGdmbjogMDAwMDQ5ODggIG1mbjogMDAwMDQ5ODgNCg0KKFhF
TikgWzIwMTItMDgtMzEgMjE6MzI6MzFdICAgZ2ZuOiAwMDAwNDk4OSAgbWZuOiAwMDAwNDk4
OQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjozMV0gICBnZm46IDAwMDA0OThhICBtZm46
IDAwMDA0OThhDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjMxXSAgIGdmbjogMDAwMDQ5
OGIgIG1mbjogMDAwMDQ5OGINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MzFdICAgZ2Zu
OiAwMDAwNDk4YyAgbWZuOiAwMDAwNDk4Yw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoz
MV0gICBnZm46IDAwMDA0OThkICBtZm46IDAwMDA0OThkDQoNCihYRU4pIFsyMDEyLTA4LTMx
IDIxOjMyOjMxXSAgIGdmbjogMDAwMDQ5OGUgIG1mbjogMDAwMDQ5OGUNCg0KKFhFTikgWzIw
MTItMDgtMzEgMjE6MzI6MzFdICAgZ2ZuOiAwMDAwNDk4ZiAgbWZuOiAwMDAwNDk4Zg0KDQoo
WEVOKSBbMjAxMi0wOC0zMSAyMTozMjozMV0gICBnZm46IDAwMDA0OTkwICBtZm46IDAwMDA0
OTkwDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjMxXSAgIGdmbjogMDAwMDQ5OTEgIG1m
bjogMDAwMDQ5OTENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MzFdICAgZ2ZuOiAwMDAw
NDk5MiAgbWZuOiAwMDAwNDk5Mg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjozMV0gICBn
Zm46IDAwMDA0OTkzICBtZm46IDAwMDA0OTkzDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMy
OjMxXSAgIGdmbjogMDAwMDQ5OTQgIG1mbjogMDAwMDQ5OTQNCg0KKFhFTikgWzIwMTItMDgt
MzEgMjE6MzI6MzFdICAgZ2ZuOiAwMDAwNDk5NSAgbWZuOiAwMDAwNDk5NQ0KDQooWEVOKSBb
MjAxMi0wOC0zMSAyMTozMjozMV0gICBnZm46IDAwMDA0OTk2ICBtZm46IDAwMDA0OTk2DQoN
CihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjMxXSAgIGdmbjogMDAwMDQ5OTcgIG1mbjogMDAw
MDQ5OTcNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MzFdICAgZ2ZuOiAwMDAwNDk5OCAg
bWZuOiAwMDAwNDk5OA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjozMV0gICBnZm46IDAw
MDA0OTk5ICBtZm46IDAwMDA0OTk5DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjMxXSAg
IGdmbjogMDAwMDQ5OWEgIG1mbjogMDAwMDQ5OWENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6
MzI6MzFdICAgZ2ZuOiAwMDAwNDk5YiAgbWZuOiAwMDAwNDk5Yg0KDQooWEVOKSBbMjAxMi0w
OC0zMSAyMTozMjozMV0gICBnZm46IDAwMDA0OTljICBtZm46IDAwMDA0OTljDQoNCihYRU4p
IFsyMDEyLTA4LTMxIDIxOjMyOjMxXSAgIGdmbjogMDAwMDQ5OWQgIG1mbjogMDAwMDQ5OWQN
Cg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MzFdICAgZ2ZuOiAwMDAwNDk5ZSAgbWZuOiAw
MDAwNDk5ZQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjozMV0gICBnZm46IDAwMDA0OTlm
ICBtZm46IDAwMDA0OTlmDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjMxXSAgIGdmbjog
MDAwMDQ5YTAgIG1mbjogMDAwMDQ5YTANCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MzFd
ICAgZ2ZuOiAwMDAwNDlhMSAgbWZuOiAwMDAwNDlhMQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAy
MTozMjozMV0gICBnZm46IDAwMDA0OWEyICBtZm46IDAwMDA0OWEyDQoNCihYRU4pIFsyMDEy
LTA4LTMxIDIxOjMyOjMxXSAgIGdmbjogMDAwMDQ5YTMgIG1mbjogMDAwMDQ5YTMNCg0KKFhF
TikgWzIwMTItMDgtMzEgMjE6MzI6MzFdICAgZ2ZuOiAwMDAwNDlhNCAgbWZuOiAwMDAwNDlh
NA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjozMV0gICBnZm46IDAwMDA0OWE1ICBtZm46
IDAwMDA0OWE1DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjMxXSAgIGdmbjogMDAwMDQ5
YTYgIG1mbjogMDAwMDQ5YTYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MzFdICAgZ2Zu
OiAwMDAwNDlhNyAgbWZuOiAwMDAwNDlhNw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoz
MV0gICBnZm46IDAwMDA0OWE4ICBtZm46IDAwMDA0OWE4DQoNCihYRU4pIFsyMDEyLTA4LTMx
IDIxOjMyOjMxXSAgIGdmbjogMDAwMDQ5YTkgIG1mbjogMDAwMDQ5YTkNCg0KKFhFTikgWzIw
MTItMDgtMzEgMjE6MzI6MzFdICAgZ2ZuOiAwMDAwNDlhYSAgbWZuOiAwMDAwNDlhYQ0KDQoo
WEVOKSBbMjAxMi0wOC0zMSAyMTozMjozMV0gICBnZm46IDAwMDA0OWFiICBtZm46IDAwMDA0
OWFiDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjMxXSAgIGdmbjogMDAwMDQ5YWMgIG1m
bjogMDAwMDQ5YWMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MzFdICAgZ2ZuOiAwMDAw
NDlhZCAgbWZuOiAwMDAwNDlhZA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjozMV0gICBn
Zm46IDAwMDA0OWFlICBtZm46IDAwMDA0OWFlDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMy
OjMxXSAgIGdmbjogMDAwMDQ5YWYgIG1mbjogMDAwMDQ5YWYNCg0KKFhFTikgWzIwMTItMDgt
MzEgMjE6MzI6MzFdICAgZ2ZuOiAwMDAwNDliMCAgbWZuOiAwMDAwNDliMA0KDQooWEVOKSBb
MjAxMi0wOC0zMSAyMTozMjozMV0gICBnZm46IDAwMDA0OWIxICBtZm46IDAwMDA0OWIxDQoN
CihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjMxXSAgIGdmbjogMDAwMDQ5YjIgIG1mbjogMDAw
MDQ5YjINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MzFdICAgZ2ZuOiAwMDAwNDliMyAg
bWZuOiAwMDAwNDliMw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjozMV0gICBnZm46IDAw
MDA0OWI0ICBtZm46IDAwMDA0OWI0DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjMxXSAg
IGdmbjogMDAwMDQ5YjUgIG1mbjogMDAwMDQ5YjUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6
MzI6MzJdICAgZ2ZuOiAwMDAwNDliNiAgbWZuOiAwMDAwNDliNg0KDQooWEVOKSBbMjAxMi0w
OC0zMSAyMTozMjozMl0gICBnZm46IDAwMDA0OWI3ICBtZm46IDAwMDA0OWI3DQoNCihYRU4p
IFsyMDEyLTA4LTMxIDIxOjMyOjMyXSAgIGdmbjogMDAwMDQ5YjggIG1mbjogMDAwMDQ5YjgN
Cg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MzJdICAgZ2ZuOiAwMDAwNDliOSAgbWZuOiAw
MDAwNDliOQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjozMl0gICBnZm46IDAwMDA0OWJh
ICBtZm46IDAwMDA0OWJhDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjMyXSAgIGdmbjog
MDAwMDQ5YmIgIG1mbjogMDAwMDQ5YmINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MzJd
ICAgZ2ZuOiAwMDAwNDliYyAgbWZuOiAwMDAwNDliYw0KDQooWEVOKSBbMjAxMi0wOC0zMSAy
MTozMjozMl0gICBnZm46IDAwMDA0OWJkICBtZm46IDAwMDA0OWJkDQoNCihYRU4pIFsyMDEy
LTA4LTMxIDIxOjMyOjMyXSAgIGdmbjogMDAwMDQ5YmUgIG1mbjogMDAwMDQ5YmUNCg0KKFhF
TikgWzIwMTItMDgtMzEgMjE6MzI6MzJdICAgZ2ZuOiAwMDAwNDliZiAgbWZuOiAwMDAwNDli
Zg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjozMl0gICBnZm46IDAwMDA0OWMwICBtZm46
IDAwMDA0OWMwDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjMyXSAgIGdmbjogMDAwMDQ5
YzEgIG1mbjogMDAwMDQ5YzENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MzJdICAgZ2Zu
OiAwMDAwNDljMiAgbWZuOiAwMDAwNDljMg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoz
Ml0gICBnZm46IDAwMDA0OWMzICBtZm46IDAwMDA0OWMzDQoNCihYRU4pIFsyMDEyLTA4LTMx
IDIxOjMyOjMyXSAgIGdmbjogMDAwMDQ5YzQgIG1mbjogMDAwMDQ5YzQNCg0KKFhFTikgWzIw
MTItMDgtMzEgMjE6MzI6MzJdICAgZ2ZuOiAwMDAwNDljNSAgbWZuOiAwMDAwNDljNQ0KDQoo
WEVOKSBbMjAxMi0wOC0zMSAyMTozMjozMl0gICBnZm46IDAwMDA0OWM2ICBtZm46IDAwMDA0
OWM2DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjMyXSAgIGdmbjogMDAwMDQ5YzcgIG1m
bjogMDAwMDQ5YzcNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MzJdICAgZ2ZuOiAwMDAw
NDljOCAgbWZuOiAwMDAwNDljOA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjozMl0gICBn
Zm46IDAwMDA0OWM5ICBtZm46IDAwMDA0OWM5DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMy
OjMyXSAgIGdmbjogMDAwMDQ5Y2EgIG1mbjogMDAwMDQ5Y2ENCg0KKFhFTikgWzIwMTItMDgt
MzEgMjE6MzI6MzJdICAgZ2ZuOiAwMDAwNDljYiAgbWZuOiAwMDAwNDljYg0KDQooWEVOKSBb
MjAxMi0wOC0zMSAyMTozMjozMl0gICBnZm46IDAwMDA0OWNjICBtZm46IDAwMDA0OWNjDQoN
CihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjMyXSAgIGdmbjogMDAwMDQ5Y2QgIG1mbjogMDAw
MDQ5Y2QNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MzJdICAgZ2ZuOiAwMDAwNDljZSAg
bWZuOiAwMDAwNDljZQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjozMl0gICBnZm46IDAw
MDA0OWNmICBtZm46IDAwMDA0OWNmDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjMyXSAg
IGdmbjogMDAwMDQ5ZDAgIG1mbjogMDAwMDQ5ZDANCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6
MzI6MzJdICAgZ2ZuOiAwMDAwNDlkMSAgbWZuOiAwMDAwNDlkMQ0KDQooWEVOKSBbMjAxMi0w
OC0zMSAyMTozMjozMl0gICBnZm46IDAwMDA0OWQyICBtZm46IDAwMDA0OWQyDQoNCihYRU4p
IFsyMDEyLTA4LTMxIDIxOjMyOjMyXSAgIGdmbjogMDAwMDQ5ZDMgIG1mbjogMDAwMDQ5ZDMN
Cg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MzJdICAgZ2ZuOiAwMDAwNDlkNCAgbWZuOiAw
MDAwNDlkNA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjozMl0gICBnZm46IDAwMDA0OWQ1
ICBtZm46IDAwMDA0OWQ1DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjMyXSAgIGdmbjog
MDAwMDQ5ZDYgIG1mbjogMDAwMDQ5ZDYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MzJd
ICAgZ2ZuOiAwMDAwNDlkNyAgbWZuOiAwMDAwNDlkNw0KDQooWEVOKSBbMjAxMi0wOC0zMSAy
MTozMjozMl0gICBnZm46IDAwMDA0OWQ4ICBtZm46IDAwMDA0OWQ4DQoNCihYRU4pIFsyMDEy
LTA4LTMxIDIxOjMyOjMyXSAgIGdmbjogMDAwMDQ5ZDkgIG1mbjogMDAwMDQ5ZDkNCg0KKFhF
TikgWzIwMTItMDgtMzEgMjE6MzI6MzJdICAgZ2ZuOiAwMDAwNDlkYSAgbWZuOiAwMDAwNDlk
YQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjozMl0gICBnZm46IDAwMDA0OWRiICBtZm46
IDAwMDA0OWRiDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjMyXSAgIGdmbjogMDAwMDQ5
ZGMgIG1mbjogMDAwMDQ5ZGMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MzJdICAgZ2Zu
OiAwMDAwNDlkZCAgbWZuOiAwMDAwNDlkZA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoz
Ml0gICBnZm46IDAwMDA0OWRlICBtZm46IDAwMDA0OWRlDQoNCihYRU4pIFsyMDEyLTA4LTMx
IDIxOjMyOjMyXSAgIGdmbjogMDAwMDQ5ZGYgIG1mbjogMDAwMDQ5ZGYNCg0KKFhFTikgWzIw
MTItMDgtMzEgMjE6MzI6MzJdICAgZ2ZuOiAwMDAwNDllMCAgbWZuOiAwMDAwNDllMA0KDQoo
WEVOKSBbMjAxMi0wOC0zMSAyMTozMjozMl0gICBnZm46IDAwMDA0OWUxICBtZm46IDAwMDA0
OWUxDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjMyXSAgIGdmbjogMDAwMDQ5ZTIgIG1m
bjogMDAwMDQ5ZTINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MzJdICAgZ2ZuOiAwMDAw
NDllMyAgbWZuOiAwMDAwNDllMw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjozMl0gICBn
Zm46IDAwMDA0OWU0ICBtZm46IDAwMDA0OWU0DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMy
OjMyXSAgIGdmbjogMDAwMDQ5ZTUgIG1mbjogMDAwMDQ5ZTUNCg0KKFhFTikgWzIwMTItMDgt
MzEgMjE6MzI6MzJdICAgZ2ZuOiAwMDAwNDllNiAgbWZuOiAwMDAwNDllNg0KDQooWEVOKSBb
MjAxMi0wOC0zMSAyMTozMjozMl0gICBnZm46IDAwMDA0OWU3ICBtZm46IDAwMDA0OWU3DQoN
CihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjMyXSAgIGdmbjogMDAwMDQ5ZTggIG1mbjogMDAw
MDQ5ZTgNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MzJdICAgZ2ZuOiAwMDAwNDllOSAg
bWZuOiAwMDAwNDllOQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjozMl0gICBnZm46IDAw
MDA0OWVhICBtZm46IDAwMDA0OWVhDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjMyXSAg
IGdmbjogMDAwMDQ5ZWIgIG1mbjogMDAwMDQ5ZWINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6
MzI6MzJdICAgZ2ZuOiAwMDAwNDllYyAgbWZuOiAwMDAwNDllYw0KDQooWEVOKSBbMjAxMi0w
OC0zMSAyMTozMjozMl0gICBnZm46IDAwMDA0OWVkICBtZm46IDAwMDA0OWVkDQoNCihYRU4p
IFsyMDEyLTA4LTMxIDIxOjMyOjMyXSAgIGdmbjogMDAwMDQ5ZWUgIG1mbjogMDAwMDQ5ZWUN
Cg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MzJdICAgZ2ZuOiAwMDAwNDllZiAgbWZuOiAw
MDAwNDllZg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjozMl0gICBnZm46IDAwMDA0OWYw
ICBtZm46IDAwMDA0OWYwDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjMyXSAgIGdmbjog
MDAwMDQ5ZjEgIG1mbjogMDAwMDQ5ZjENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MzJd
ICAgZ2ZuOiAwMDAwNDlmMiAgbWZuOiAwMDAwNDlmMg0KDQooWEVOKSBbMjAxMi0wOC0zMSAy
MTozMjozMl0gICBnZm46IDAwMDA0OWYzICBtZm46IDAwMDA0OWYzDQoNCihYRU4pIFsyMDEy
LTA4LTMxIDIxOjMyOjMyXSAgIGdmbjogMDAwMDQ5ZjQgIG1mbjogMDAwMDQ5ZjQNCg0KKFhF
TikgWzIwMTItMDgtMzEgMjE6MzI6MzJdICAgZ2ZuOiAwMDAwNDlmNSAgbWZuOiAwMDAwNDlm
NQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjozM10gICBnZm46IDAwMDA0OWY2ICBtZm46
IDAwMDA0OWY2DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjMzXSAgIGdmbjogMDAwMDQ5
ZjcgIG1mbjogMDAwMDQ5ZjcNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MzNdICAgZ2Zu
OiAwMDAwNDlmOCAgbWZuOiAwMDAwNDlmOA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoz
M10gICBnZm46IDAwMDA0OWY5ICBtZm46IDAwMDA0OWY5DQoNCihYRU4pIFsyMDEyLTA4LTMx
IDIxOjMyOjMzXSAgIGdmbjogMDAwMDQ5ZmEgIG1mbjogMDAwMDQ5ZmENCg0KKFhFTikgWzIw
MTItMDgtMzEgMjE6MzI6MzNdICAgZ2ZuOiAwMDAwNDlmYiAgbWZuOiAwMDAwNDlmYg0KDQoo
WEVOKSBbMjAxMi0wOC0zMSAyMTozMjozM10gICBnZm46IDAwMDA0OWZjICBtZm46IDAwMDA0
OWZjDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjMzXSAgIGdmbjogMDAwMDQ5ZmQgIG1m
bjogMDAwMDQ5ZmQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MzNdICAgZ2ZuOiAwMDAw
NDlmZSAgbWZuOiAwMDAwNDlmZQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjozM10gICBn
Zm46IDAwMDA0OWZmICBtZm46IDAwMDA0OWZmDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMy
OjMzXSAgIGdmbjogMDAwMDRhMDAgIG1mbjogMDAwMDRhMDANCg0KKFhFTikgWzIwMTItMDgt
MzEgMjE6MzI6MzNdICAgZ2ZuOiAwMDAwNGEwMSAgbWZuOiAwMDAwNGEwMQ0KDQooWEVOKSBb
MjAxMi0wOC0zMSAyMTozMjozM10gICBnZm46IDAwMDA0YTAyICBtZm46IDAwMDA0YTAyDQoN
CihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjMzXSAgIGdmbjogMDAwMDRhMDMgIG1mbjogMDAw
MDRhMDMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MzNdICAgZ2ZuOiAwMDAwNGEwNCAg
bWZuOiAwMDAwNGEwNA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjozM10gICBnZm46IDAw
MDA0YTA1ICBtZm46IDAwMDA0YTA1DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjMzXSAg
IGdmbjogMDAwMDRhMDYgIG1mbjogMDAwMDRhMDYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6
MzI6MzNdICAgZ2ZuOiAwMDAwNGEwNyAgbWZuOiAwMDAwNGEwNw0KDQooWEVOKSBbMjAxMi0w
OC0zMSAyMTozMjozM10gICBnZm46IDAwMDA0YTA4ICBtZm46IDAwMDA0YTA4DQoNCihYRU4p
IFsyMDEyLTA4LTMxIDIxOjMyOjMzXSAgIGdmbjogMDAwMDRhMDkgIG1mbjogMDAwMDRhMDkN
Cg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MzNdICAgZ2ZuOiAwMDAwNGEwYSAgbWZuOiAw
MDAwNGEwYQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjozM10gICBnZm46IDAwMDA0YTBi
ICBtZm46IDAwMDA0YTBiDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjMzXSAgIGdmbjog
MDAwMDRhMGMgIG1mbjogMDAwMDRhMGMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MzNd
ICAgZ2ZuOiAwMDAwNGEwZCAgbWZuOiAwMDAwNGEwZA0KDQooWEVOKSBbMjAxMi0wOC0zMSAy
MTozMjozM10gICBnZm46IDAwMDA0YTBlICBtZm46IDAwMDA0YTBlDQoNCihYRU4pIFsyMDEy
LTA4LTMxIDIxOjMyOjMzXSAgIGdmbjogMDAwMDRhMGYgIG1mbjogMDAwMDRhMGYNCg0KKFhF
TikgWzIwMTItMDgtMzEgMjE6MzI6MzNdICAgZ2ZuOiAwMDAwNGExMCAgbWZuOiAwMDAwNGEx
MA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjozM10gICBnZm46IDAwMDA0YTExICBtZm46
IDAwMDA0YTExDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjMzXSAgIGdmbjogMDAwMDRh
MTIgIG1mbjogMDAwMDRhMTINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MzNdICAgZ2Zu
OiAwMDAwNGExMyAgbWZuOiAwMDAwNGExMw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoz
M10gICBnZm46IDAwMDA0YTE0ICBtZm46IDAwMDA0YTE0DQoNCihYRU4pIFsyMDEyLTA4LTMx
IDIxOjMyOjMzXSAgIGdmbjogMDAwMDRhMTUgIG1mbjogMDAwMDRhMTUNCg0KKFhFTikgWzIw
MTItMDgtMzEgMjE6MzI6MzNdICAgZ2ZuOiAwMDAwNGExNiAgbWZuOiAwMDAwNGExNg0KDQoo
WEVOKSBbMjAxMi0wOC0zMSAyMTozMjozM10gICBnZm46IDAwMDA0YTE3ICBtZm46IDAwMDA0
YTE3DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjMzXSAgIGdmbjogMDAwMDRhMTggIG1m
bjogMDAwMDRhMTgNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MzNdICAgZ2ZuOiAwMDAw
NGExOSAgbWZuOiAwMDAwNGExOQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjozM10gICBn
Zm46IDAwMDA0YTFhICBtZm46IDAwMDA0YTFhDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMy
OjMzXSAgIGdmbjogMDAwMDRhMWIgIG1mbjogMDAwMDRhMWINCg0KKFhFTikgWzIwMTItMDgt
MzEgMjE6MzI6MzNdICAgZ2ZuOiAwMDAwNGExYyAgbWZuOiAwMDAwNGExYw0KDQooWEVOKSBb
MjAxMi0wOC0zMSAyMTozMjozM10gICBnZm46IDAwMDA0YTFkICBtZm46IDAwMDA0YTFkDQoN
CihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjMzXSAgIGdmbjogMDAwMDRhMWUgIG1mbjogMDAw
MDRhMWUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MzNdICAgZ2ZuOiAwMDAwNGExZiAg
bWZuOiAwMDAwNGExZg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjozM10gICBnZm46IDAw
MDA0YTIwICBtZm46IDAwMDA0YTIwDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjMzXSAg
IGdmbjogMDAwMDRhMjEgIG1mbjogMDAwMDRhMjENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6
MzI6MzNdICAgZ2ZuOiAwMDAwNGEyMiAgbWZuOiAwMDAwNGEyMg0KDQooWEVOKSBbMjAxMi0w
OC0zMSAyMTozMjozM10gICBnZm46IDAwMDA0YTIzICBtZm46IDAwMDA0YTIzDQoNCihYRU4p
IFsyMDEyLTA4LTMxIDIxOjMyOjMzXSAgIGdmbjogMDAwMDRhMjQgIG1mbjogMDAwMDRhMjQN
Cg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MzNdICAgZ2ZuOiAwMDAwNGEyNSAgbWZuOiAw
MDAwNGEyNQ0KDQpbICA0MTkuNzI3NTc1XSBhdGExLjAwOiBxYyB0aW1lbyhYRU4pIFsyMDEy
LTA4LTMxIDIxOjMyOjMzXSAgIGdmbjogMDAwMDRhMjYgIG1mbjogMDAwMDRhMjYNCg0KdXQg
KGNtZCAweGVjKQ0KDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjMzXSAgIGdmbjogMDAw
MDRhMjcgIG1mbjogMDAwMDRhMjcNCg0KWyAgNDE5Ljc4NTU2OV0gYXRhMS4wMDogZmFpbGVk
IHQoWEVOKSBbMjAxMi0wOC0zMSAyMTozMjozM10gICBnZm46IDAwMDA0YTI4ICBtZm46IDAw
MDA0YTI4DQoNCm8gSURFTlRJRlkgKEkvTyAoWEVOKSBbMjAxMi0wOC0zMSAyMTozMjozM10g
ICBnZm46IDAwMDA0YTI5ICBtZm46IDAwMDA0YTI5DQoNCmVycm9yLCBlcnJfbWFzaz0weDQp
DQoNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MzNdICAgZ2ZuOiAwMDAwNGEyYSAgbWZu
OiAwMDAwNGEyYQ0KDQpbICA0MTkuODUxOTg1XSBhKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6
MzNdICAgZ2ZuOiAwMDAwNGEyYiAgbWZuOiAwMDAwNGEyYg0KDQp0YTEuMDA6IHJldmFsaWRh
KFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MzNdICAgZ2ZuOiAwMDAwNGEyYyAgbWZuOiAwMDAw
NGEyYw0KDQp0aW9uIGZhaWxlZCAoZXJyKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MzNdICAg
Z2ZuOiAwMDAwNGEyZCAgbWZuOiAwMDAwNGEyZA0KDQpubz0tNSkNCg0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMjozM10gICBnZm46IDAwMDA0YTJlICBtZm46IDAwMDA0YTJlDQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMyOjMzXSAgIGdmbjogMDAwMDRhMmYgIG1mbjogMDAwMDRh
MmYNCg0KWyAgNDE5LjkzMTA1MV0gYXRhMTogaGFyZCByZXNldHQoWEVOKSBbMjAxMi0wOC0z
MSAyMTozMjozM10gICBnZm46IDAwMDA0YTMwICBtZm46IDAwMDA0YTMwDQoNCmluZyBsaW5r
DQoNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MzNdICAgZ2ZuOiAwMDAwNGEzMSAgbWZu
OiAwMDAwNGEzMQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjozNF0gICBnZm46IDAwMDA0
YTMyICBtZm46IDAwMDA0YTMyDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjM0XSAgIGdm
bjogMDAwMDRhMzMgIG1mbjogMDAwMDRhMzMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6
MzRdICAgZ2ZuOiAwMDAwNGEzNCAgbWZuOiAwMDAwNGEzNA0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMjozNF0gICBnZm46IDAwMDA0YTM1ICBtZm46IDAwMDA0YTM1DQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMyOjM0XSAgIGdmbjogMDAwMDRhMzYgIG1mbjogMDAwMDRhMzYNCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MzRdICAgZ2ZuOiAwMDAwNGEzNyAgbWZuOiAwMDAw
NGEzNw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjozNF0gICBnZm46IDAwMDA0YTM4ICBt
Zm46IDAwMDA0YTM4DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjM0XSAgIGdmbjogMDAw
MDRhMzkgIG1mbjogMDAwMDRhMzkNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MzRdICAg
Z2ZuOiAwMDAwNGEzYSAgbWZuOiAwMDAwNGEzYQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
MjozNF0gICBnZm46IDAwMDA0YTNiICBtZm46IDAwMDA0YTNiDQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMyOjM0XSAgIGdmbjogMDAwMDRhM2MgIG1mbjogMDAwMDRhM2MNCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzI6MzRdICAgZ2ZuOiAwMDAwNGEzZCAgbWZuOiAwMDAwNGEzZA0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjozNF0gICBnZm46IDAwMDA0YTNlICBtZm46IDAw
MDA0YTNlDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjM0XSAgIGdmbjogMDAwMDRhM2Yg
IG1mbjogMDAwMDRhM2YNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MzRdICAgZ2ZuOiAw
MDAwNGE0MCAgbWZuOiAwMDAwNGE0MA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjozNF0g
ICBnZm46IDAwMDA0YTQxICBtZm46IDAwMDA0YTQxDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMyOjM0XSAgIGdmbjogMDAwMDRhNDIgIG1mbjogMDAwMDRhNDINCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzI6MzRdICAgZ2ZuOiAwMDAwNGE0MyAgbWZuOiAwMDAwNGE0Mw0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMjozNF0gICBnZm46IDAwMDA0YTQ0ICBtZm46IDAwMDA0YTQ0
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjM0XSAgIGdmbjogMDAwMDRhNDUgIG1mbjog
MDAwMDRhNDUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MzRdICAgZ2ZuOiAwMDAwNGE0
NiAgbWZuOiAwMDAwNGE0Ng0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjozNF0gICBnZm46
IDAwMDA0YTQ3ICBtZm46IDAwMDA0YTQ3DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjM0
XSAgIGdmbjogMDAwMDRhNDggIG1mbjogMDAwMDRhNDgNCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzI6MzRdICAgZ2ZuOiAwMDAwNGE0OSAgbWZuOiAwMDAwNGE0OQ0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMjozNF0gICBnZm46IDAwMDA0YTRhICBtZm46IDAwMDA0YTRhDQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMyOjM0XSAgIGdmbjogMDAwMDRhNGIgIG1mbjogMDAwMDRh
NGINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MzRdICAgZ2ZuOiAwMDAwNGE0YyAgbWZu
OiAwMDAwNGE0Yw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjozNF0gICBnZm46IDAwMDA0
YTRkICBtZm46IDAwMDA0YTRkDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjM0XSAgIGdm
bjogMDAwMDRhNGUgIG1mbjogMDAwMDRhNGUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6
MzRdICAgZ2ZuOiAwMDAwNGE0ZiAgbWZuOiAwMDAwNGE0Zg0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMjozNF0gICBnZm46IDAwMDA0YTUwICBtZm46IDAwMDA0YTUwDQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMyOjM0XSAgIGdmbjogMDAwMDRhNTEgIG1mbjogMDAwMDRhNTENCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MzRdICAgZ2ZuOiAwMDAwNGE1MiAgbWZuOiAwMDAw
NGE1Mg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjozNF0gICBnZm46IDAwMDA0YTUzICBt
Zm46IDAwMDA0YTUzDQoNClsgIDQyMC41MDA5ODFdIGF0YTE6IFNBVEEgbGluayB1KFhFTikg
WzIwMTItMDgtMzEgMjE6MzI6MzRdICAgZ2ZuOiAwMDAwNGE1NCAgbWZuOiAwMDAwNGE1NA0K
DQpwIDMuMCBHYnBzIChTU3RhKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MzRdICAgZ2ZuOiAw
MDAwNGE1NSAgbWZuOiAwMDAwNGE1NQ0KDQp0dXMgMTIzIFNDb250cm9sIDMwMCkNCg0KDQoo
WEVOKSBbMjAxMi0wOC0zMSAyMTozMjozNF0gICBnZm46IDAwMDA0YTU2ICBtZm46IDAwMDA0
YTU2DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjM0XSAgIGdmbjogMDAwMDRhNTcgIG1m
bjogMDAwMDRhNTcNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MzRdICAgZ2ZuOiAwMDAw
NGE1OCAgbWZuOiAwMDAwNGE1OA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjozNF0gICBn
Zm46IDAwMDA0YTU5ICBtZm46IDAwMDA0YTU5DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMy
OjM0XSAgIGdmbjogMDAwMDRhNWEgIG1mbjogMDAwMDRhNWENCg0KKFhFTikgWzIwMTItMDgt
MzEgMjE6MzI6MzRdICAgZ2ZuOiAwMDAwNGE1YiAgbWZuOiAwMDAwNGE1Yg0KDQooWEVOKSBb
MjAxMi0wOC0zMSAyMTozMjozNF0gICBnZm46IDAwMDA0YTVjICBtZm46IDAwMDA0YTVjDQoN
CihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjM0XSAgIGdmbjogMDAwMDRhNWQgIG1mbjogMDAw
MDRhNWQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MzRdICAgZ2ZuOiAwMDAwNGE1ZSAg
bWZuOiAwMDAwNGE1ZQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjozNF0gICBnZm46IDAw
MDA0YTVmICBtZm46IDAwMDA0YTVmDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjM0XSAg
IGdmbjogMDAwMDRhNjAgIG1mbjogMDAwMDRhNjANCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6
MzI6MzRdICAgZ2ZuOiAwMDAwNGE2MSAgbWZuOiAwMDAwNGE2MQ0KDQooWEVOKSBbMjAxMi0w
OC0zMSAyMTozMjozNF0gICBnZm46IDAwMDA0YTYyICBtZm46IDAwMDA0YTYyDQoNCihYRU4p
IFsyMDEyLTA4LTMxIDIxOjMyOjM0XSAgIGdmbjogMDAwMDRhNjMgIG1mbjogMDAwMDRhNjMN
Cg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MzRdICAgZ2ZuOiAwMDAwNGE2NCAgbWZuOiAw
MDAwNGE2NA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjozNF0gICBnZm46IDAwMDA0YTY1
ICBtZm46IDAwMDA0YTY1DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjM0XSAgIGdmbjog
MDAwMDRhNjYgIG1mbjogMDAwMDRhNjYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MzRd
ICAgZ2ZuOiAwMDAwNGE2NyAgbWZuOiAwMDAwNGE2Nw0KDQooWEVOKSBbMjAxMi0wOC0zMSAy
MTozMjozNF0gICBnZm46IDAwMDA0YTY4ICBtZm46IDAwMDA0YTY4DQoNCihYRU4pIFsyMDEy
LTA4LTMxIDIxOjMyOjM0XSAgIGdmbjogMDAwMDRhNjkgIG1mbjogMDAwMDRhNjkNCg0KKFhF
TikgWzIwMTItMDgtMzEgMjE6MzI6MzRdICAgZ2ZuOiAwMDAwNGE2YSAgbWZuOiAwMDAwNGE2
YQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjozNF0gICBnZm46IDAwMDA0YTZiICBtZm46
IDAwMDA0YTZiDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjM0XSAgIGdmbjogMDAwMDRh
NmMgIG1mbjogMDAwMDRhNmMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MzRdICAgZ2Zu
OiAwMDAwNGE2ZCAgbWZuOiAwMDAwNGE2ZA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoz
NF0gICBnZm46IDAwMDA0YTZlICBtZm46IDAwMDA0YTZlDQoNCihYRU4pIFsyMDEyLTA4LTMx
IDIxOjMyOjM0XSAgIGdmbjogMDAwMDRhNmYgIG1mbjogMDAwMDRhNmYNCg0KKFhFTikgWzIw
MTItMDgtMzEgMjE6MzI6MzRdICAgZ2ZuOiAwMDAwNGE3MCAgbWZuOiAwMDAwNGE3MA0KDQoo
WEVOKSBbMjAxMi0wOC0zMSAyMTozMjozNV0gICBnZm46IDAwMDA0YTcxICBtZm46IDAwMDA0
YTcxDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjM1XSAgIGdmbjogMDAwMDRhNzIgIG1m
bjogMDAwMDRhNzINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MzVdICAgZ2ZuOiAwMDAw
NGE3MyAgbWZuOiAwMDAwNGE3Mw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjozNV0gICBn
Zm46IDAwMDA0YTc0ICBtZm46IDAwMDA0YTc0DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMy
OjM1XSAgIGdmbjogMDAwMDRhNzUgIG1mbjogMDAwMDRhNzUNCg0KKFhFTikgWzIwMTItMDgt
MzEgMjE6MzI6MzVdICAgZ2ZuOiAwMDAwNGE3NiAgbWZuOiAwMDAwNGE3Ng0KDQooWEVOKSBb
MjAxMi0wOC0zMSAyMTozMjozNV0gICBnZm46IDAwMDA0YTc3ICBtZm46IDAwMDA0YTc3DQoN
CihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjM1XSAgIGdmbjogMDAwMDRhNzggIG1mbjogMDAw
MDRhNzgNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MzVdICAgZ2ZuOiAwMDAwNGE3OSAg
bWZuOiAwMDAwNGE3OQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjozNV0gICBnZm46IDAw
MDA0YTdhICBtZm46IDAwMDA0YTdhDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjM1XSAg
IGdmbjogMDAwMDRhN2IgIG1mbjogMDAwMDRhN2INCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6
MzI6MzVdICAgZ2ZuOiAwMDAwNGE3YyAgbWZuOiAwMDAwNGE3Yw0KDQooWEVOKSBbMjAxMi0w
OC0zMSAyMTozMjozNV0gICBnZm46IDAwMDA0YTdkICBtZm46IDAwMDA0YTdkDQoNCihYRU4p
IFsyMDEyLTA4LTMxIDIxOjMyOjM1XSAgIGdmbjogMDAwMDRhN2UgIG1mbjogMDAwMDRhN2UN
Cg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MzVdICAgZ2ZuOiAwMDAwNGE3ZiAgbWZuOiAw
MDAwNGE3Zg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjozNV0gICBnZm46IDAwMDA0YTgw
ICBtZm46IDAwMDA0YTgwDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjM1XSAgIGdmbjog
MDAwMDRhODEgIG1mbjogMDAwMDRhODENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MzVd
ICAgZ2ZuOiAwMDAwNGE4MiAgbWZuOiAwMDAwNGE4Mg0KDQooWEVOKSBbMjAxMi0wOC0zMSAy
MTozMjozNV0gICBnZm46IDAwMDA0YTgzICBtZm46IDAwMDA0YTgzDQoNCihYRU4pIFsyMDEy
LTA4LTMxIDIxOjMyOjM1XSAgIGdmbjogMDAwMDRhODQgIG1mbjogMDAwMDRhODQNCg0KKFhF
TikgWzIwMTItMDgtMzEgMjE6MzI6MzVdICAgZ2ZuOiAwMDAwNGE4NSAgbWZuOiAwMDAwNGE4
NQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjozNV0gICBnZm46IDAwMDA0YTg2ICBtZm46
IDAwMDA0YTg2DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjM1XSAgIGdmbjogMDAwMDRh
ODcgIG1mbjogMDAwMDRhODcNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MzVdICAgZ2Zu
OiAwMDAwNGE4OCAgbWZuOiAwMDAwNGE4OA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoz
NV0gICBnZm46IDAwMDA0YTg5ICBtZm46IDAwMDA0YTg5DQoNCihYRU4pIFsyMDEyLTA4LTMx
IDIxOjMyOjM1XSAgIGdmbjogMDAwMDRhOGEgIG1mbjogMDAwMDRhOGENCg0KKFhFTikgWzIw
MTItMDgtMzEgMjE6MzI6MzVdICAgZ2ZuOiAwMDAwNGE4YiAgbWZuOiAwMDAwNGE4Yg0KDQoo
WEVOKSBbMjAxMi0wOC0zMSAyMTozMjozNV0gICBnZm46IDAwMDA0YThjICBtZm46IDAwMDA0
YThjDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjM1XSAgIGdmbjogMDAwMDRhOGQgIG1m
bjogMDAwMDRhOGQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MzVdICAgZ2ZuOiAwMDAw
NGE4ZSAgbWZuOiAwMDAwNGE4ZQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjozNV0gICBn
Zm46IDAwMDA0YThmICBtZm46IDAwMDA0YThmDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMy
OjM1XSAgIGdmbjogMDAwMDRhOTAgIG1mbjogMDAwMDRhOTANCg0KKFhFTikgWzIwMTItMDgt
MzEgMjE6MzI6MzVdICAgZ2ZuOiAwMDAwNGE5MSAgbWZuOiAwMDAwNGE5MQ0KDQooWEVOKSBb
MjAxMi0wOC0zMSAyMTozMjozNV0gICBnZm46IDAwMDA0YTkyICBtZm46IDAwMDA0YTkyDQoN
CihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjM1XSAgIGdmbjogMDAwMDRhOTMgIG1mbjogMDAw
MDRhOTMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MzVdICAgZ2ZuOiAwMDAwNGE5NCAg
bWZuOiAwMDAwNGE5NA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjozNV0gICBnZm46IDAw
MDA0YTk1ICBtZm46IDAwMDA0YTk1DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjM1XSAg
IGdmbjogMDAwMDRhOTYgIG1mbjogMDAwMDRhOTYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6
MzI6MzVdICAgZ2ZuOiAwMDAwNGE5NyAgbWZuOiAwMDAwNGE5Nw0KDQooWEVOKSBbMjAxMi0w
OC0zMSAyMTozMjozNV0gICBnZm46IDAwMDA0YTk4ICBtZm46IDAwMDA0YTk4DQoNCihYRU4p
IFsyMDEyLTA4LTMxIDIxOjMyOjM1XSAgIGdmbjogMDAwMDRhOTkgIG1mbjogMDAwMDRhOTkN
Cg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MzVdICAgZ2ZuOiAwMDAwNGE5YSAgbWZuOiAw
MDAwNGE5YQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjozNV0gICBnZm46IDAwMDA0YTli
ICBtZm46IDAwMDA0YTliDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjM1XSAgIGdmbjog
MDAwMDRhOWMgIG1mbjogMDAwMDRhOWMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MzVd
ICAgZ2ZuOiAwMDAwNGE5ZCAgbWZuOiAwMDAwNGE5ZA0KDQooWEVOKSBbMjAxMi0wOC0zMSAy
MTozMjozNV0gICBnZm46IDAwMDA0YTllICBtZm46IDAwMDA0YTllDQoNCihYRU4pIFsyMDEy
LTA4LTMxIDIxOjMyOjM1XSAgIGdmbjogMDAwMDRhOWYgIG1mbjogMDAwMDRhOWYNCg0KKFhF
TikgWzIwMTItMDgtMzEgMjE6MzI6MzVdICAgZ2ZuOiAwMDAwNGFhMCAgbWZuOiAwMDAwNGFh
MA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjozNV0gICBnZm46IDAwMDA0YWExICBtZm46
IDAwMDA0YWExDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjM1XSAgIGdmbjogMDAwMDRh
YTIgIG1mbjogMDAwMDRhYTINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MzVdICAgZ2Zu
OiAwMDAwNGFhMyAgbWZuOiAwMDAwNGFhMw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoz
NV0gICBnZm46IDAwMDA0YWE0ICBtZm46IDAwMDA0YWE0DQoNCihYRU4pIFsyMDEyLTA4LTMx
IDIxOjMyOjM1XSAgIGdmbjogMDAwMDRhYTUgIG1mbjogMDAwMDRhYTUNCg0KKFhFTikgWzIw
MTItMDgtMzEgMjE6MzI6MzVdICAgZ2ZuOiAwMDAwNGFhNiAgbWZuOiAwMDAwNGFhNg0KDQoo
WEVOKSBbMjAxMi0wOC0zMSAyMTozMjozNV0gICBnZm46IDAwMDA0YWE3ICBtZm46IDAwMDA0
YWE3DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjM1XSAgIGdmbjogMDAwMDRhYTggIG1m
bjogMDAwMDRhYTgNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MzVdICAgZ2ZuOiAwMDAw
NGFhOSAgbWZuOiAwMDAwNGFhOQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjozNV0gICBn
Zm46IDAwMDA0YWFhICBtZm46IDAwMDA0YWFhDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMy
OjM1XSAgIGdmbjogMDAwMDRhYWIgIG1mbjogMDAwMDRhYWINCg0KKFhFTikgWzIwMTItMDgt
MzEgMjE6MzI6MzVdICAgZ2ZuOiAwMDAwNGFhYyAgbWZuOiAwMDAwNGFhYw0KDQooWEVOKSBb
MjAxMi0wOC0zMSAyMTozMjozNV0gICBnZm46IDAwMDA0YWFkICBtZm46IDAwMDA0YWFkDQoN
CihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjM1XSAgIGdmbjogMDAwMDRhYWUgIG1mbjogMDAw
MDRhYWUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MzVdICAgZ2ZuOiAwMDAwNGFhZiAg
bWZuOiAwMDAwNGFhZg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjozNV0gICBnZm46IDAw
MDA0YWIwICBtZm46IDAwMDA0YWIwDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjM2XSAg
IGdmbjogMDAwMDRhYjEgIG1mbjogMDAwMDRhYjENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6
MzI6MzZdICAgZ2ZuOiAwMDAwNGFiMiAgbWZuOiAwMDAwNGFiMg0KDQooWEVOKSBbMjAxMi0w
OC0zMSAyMTozMjozNl0gICBnZm46IDAwMDA0YWIzICBtZm46IDAwMDA0YWIzDQoNCihYRU4p
IFsyMDEyLTA4LTMxIDIxOjMyOjM2XSAgIGdmbjogMDAwMDRhYjQgIG1mbjogMDAwMDRhYjQN
Cg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MzZdICAgZ2ZuOiAwMDAwNGFiNSAgbWZuOiAw
MDAwNGFiNQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjozNl0gICBnZm46IDAwMDA0YWI2
ICBtZm46IDAwMDA0YWI2DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjM2XSAgIGdmbjog
MDAwMDRhYjcgIG1mbjogMDAwMDRhYjcNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MzZd
ICAgZ2ZuOiAwMDAwNGFiOCAgbWZuOiAwMDAwNGFiOA0KDQooWEVOKSBbMjAxMi0wOC0zMSAy
MTozMjozNl0gICBnZm46IDAwMDA0YWI5ICBtZm46IDAwMDA0YWI5DQoNCihYRU4pIFsyMDEy
LTA4LTMxIDIxOjMyOjM2XSAgIGdmbjogMDAwMDRhYmEgIG1mbjogMDAwMDRhYmENCg0KKFhF
TikgWzIwMTItMDgtMzEgMjE6MzI6MzZdICAgZ2ZuOiAwMDAwNGFiYiAgbWZuOiAwMDAwNGFi
Yg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjozNl0gICBnZm46IDAwMDA0YWJjICBtZm46
IDAwMDA0YWJjDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjM2XSAgIGdmbjogMDAwMDRh
YmQgIG1mbjogMDAwMDRhYmQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MzZdICAgZ2Zu
OiAwMDAwNGFiZSAgbWZuOiAwMDAwNGFiZQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoz
Nl0gICBnZm46IDAwMDA0YWJmICBtZm46IDAwMDA0YWJmDQoNCihYRU4pIFsyMDEyLTA4LTMx
IDIxOjMyOjM2XSAgIGdmbjogMDAwMDRhYzAgIG1mbjogMDAwMDRhYzANCg0KKFhFTikgWzIw
MTItMDgtMzEgMjE6MzI6MzZdICAgZ2ZuOiAwMDAwNGFjMSAgbWZuOiAwMDAwNGFjMQ0KDQoo
WEVOKSBbMjAxMi0wOC0zMSAyMTozMjozNl0gICBnZm46IDAwMDA0YWMyICBtZm46IDAwMDA0
YWMyDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjM2XSAgIGdmbjogMDAwMDRhYzMgIG1m
bjogMDAwMDRhYzMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MzZdICAgZ2ZuOiAwMDAw
NGFjNCAgbWZuOiAwMDAwNGFjNA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjozNl0gICBn
Zm46IDAwMDA0YWM1ICBtZm46IDAwMDA0YWM1DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMy
OjM2XSAgIGdmbjogMDAwMDRhYzYgIG1mbjogMDAwMDRhYzYNCg0KKFhFTikgWzIwMTItMDgt
MzEgMjE6MzI6MzZdICAgZ2ZuOiAwMDAwNGFjNyAgbWZuOiAwMDAwNGFjNw0KDQooWEVOKSBb
MjAxMi0wOC0zMSAyMTozMjozNl0gICBnZm46IDAwMDA0YWM4ICBtZm46IDAwMDA0YWM4DQoN
CihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjM2XSAgIGdmbjogMDAwMDRhYzkgIG1mbjogMDAw
MDRhYzkNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MzZdICAgZ2ZuOiAwMDAwNGFjYSAg
bWZuOiAwMDAwNGFjYQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjozNl0gICBnZm46IDAw
MDA0YWNiICBtZm46IDAwMDA0YWNiDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjM2XSAg
IGdmbjogMDAwMDRhY2MgIG1mbjogMDAwMDRhY2MNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6
MzI6MzZdICAgZ2ZuOiAwMDAwNGFjZCAgbWZuOiAwMDAwNGFjZA0KDQooWEVOKSBbMjAxMi0w
OC0zMSAyMTozMjozNl0gICBnZm46IDAwMDA0YWNlICBtZm46IDAwMDA0YWNlDQoNCihYRU4p
IFsyMDEyLTA4LTMxIDIxOjMyOjM2XSAgIGdmbjogMDAwMDRhY2YgIG1mbjogMDAwMDRhY2YN
Cg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MzZdICAgZ2ZuOiAwMDAwNGFkMCAgbWZuOiAw
MDAwNGFkMA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjozNl0gICBnZm46IDAwMDA0YWQx
ICBtZm46IDAwMDA0YWQxDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjM2XSAgIGdmbjog
MDAwMDRhZDIgIG1mbjogMDAwMDRhZDINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MzZd
ICAgZ2ZuOiAwMDAwNGFkMyAgbWZuOiAwMDAwNGFkMw0KDQooWEVOKSBbMjAxMi0wOC0zMSAy
MTozMjozNl0gICBnZm46IDAwMDA0YWQ0ICBtZm46IDAwMDA0YWQ0DQoNCihYRU4pIFsyMDEy
LTA4LTMxIDIxOjMyOjM2XSAgIGdmbjogMDAwMDRhZDUgIG1mbjogMDAwMDRhZDUNCg0KKFhF
TikgWzIwMTItMDgtMzEgMjE6MzI6MzZdICAgZ2ZuOiAwMDAwNGFkNiAgbWZuOiAwMDAwNGFk
Ng0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjozNl0gICBnZm46IDAwMDA0YWQ3ICBtZm46
IDAwMDA0YWQ3DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjM2XSAgIGdmbjogMDAwMDRh
ZDggIG1mbjogMDAwMDRhZDgNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MzZdICAgZ2Zu
OiAwMDAwNGFkOSAgbWZuOiAwMDAwNGFkOQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoz
Nl0gICBnZm46IDAwMDA0YWRhICBtZm46IDAwMDA0YWRhDQoNCihYRU4pIFsyMDEyLTA4LTMx
IDIxOjMyOjM2XSAgIGdmbjogMDAwMDRhZGIgIG1mbjogMDAwMDRhZGINCg0KKFhFTikgWzIw
MTItMDgtMzEgMjE6MzI6MzZdICAgZ2ZuOiAwMDAwNGFkYyAgbWZuOiAwMDAwNGFkYw0KDQoo
WEVOKSBbMjAxMi0wOC0zMSAyMTozMjozNl0gICBnZm46IDAwMDA0YWRkICBtZm46IDAwMDA0
YWRkDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjM2XSAgIGdmbjogMDAwMDRhZGUgIG1m
bjogMDAwMDRhZGUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MzZdICAgZ2ZuOiAwMDAw
NGFkZiAgbWZuOiAwMDAwNGFkZg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjozNl0gICBn
Zm46IDAwMDA0YWUwICBtZm46IDAwMDA0YWUwDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMy
OjM2XSAgIGdmbjogMDAwMDRhZTEgIG1mbjogMDAwMDRhZTENCg0KKFhFTikgWzIwMTItMDgt
MzEgMjE6MzI6MzZdICAgZ2ZuOiAwMDAwNGFlMiAgbWZuOiAwMDAwNGFlMg0KDQooWEVOKSBb
MjAxMi0wOC0zMSAyMTozMjozNl0gICBnZm46IDAwMDA0YWUzICBtZm46IDAwMDA0YWUzDQoN
CihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjM2XSAgIGdmbjogMDAwMDRhZTQgIG1mbjogMDAw
MDRhZTQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MzZdICAgZ2ZuOiAwMDAwNGFlNSAg
bWZuOiAwMDAwNGFlNQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjozNl0gICBnZm46IDAw
MDA0YWU2ICBtZm46IDAwMDA0YWU2DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjM2XSAg
IGdmbjogMDAwMDRhZTcgIG1mbjogMDAwMDRhZTcNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6
MzI6MzZdICAgZ2ZuOiAwMDAwNGFlOCAgbWZuOiAwMDAwNGFlOA0KDQooWEVOKSBbMjAxMi0w
OC0zMSAyMTozMjozNl0gICBnZm46IDAwMDA0YWU5ICBtZm46IDAwMDA0YWU5DQoNCihYRU4p
IFsyMDEyLTA4LTMxIDIxOjMyOjM2XSAgIGdmbjogMDAwMDRhZWEgIG1mbjogMDAwMDRhZWEN
Cg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MzZdICAgZ2ZuOiAwMDAwNGFlYiAgbWZuOiAw
MDAwNGFlYg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjozNl0gICBnZm46IDAwMDA0YWVj
ICBtZm46IDAwMDA0YWVjDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjM2XSAgIGdmbjog
MDAwMDRhZWQgIG1mbjogMDAwMDRhZWQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MzZd
ICAgZ2ZuOiAwMDAwNGFlZSAgbWZuOiAwMDAwNGFlZQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAy
MTozMjozNl0gICBnZm46IDAwMDA0YWVmICBtZm46IDAwMDA0YWVmDQoNCihYRU4pIFsyMDEy
LTA4LTMxIDIxOjMyOjM2XSAgIGdmbjogMDAwMDRhZjAgIG1mbjogMDAwMDRhZjANCg0KKFhF
TikgWzIwMTItMDgtMzEgMjE6MzI6MzddICAgZ2ZuOiAwMDAwNGFmMSAgbWZuOiAwMDAwNGFm
MQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjozN10gICBnZm46IDAwMDA0YWYyICBtZm46
IDAwMDA0YWYyDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjM3XSAgIGdmbjogMDAwMDRh
ZjMgIG1mbjogMDAwMDRhZjMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MzddICAgZ2Zu
OiAwMDAwNGFmNCAgbWZuOiAwMDAwNGFmNA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoz
N10gICBnZm46IDAwMDA0YWY1ICBtZm46IDAwMDA0YWY1DQoNCihYRU4pIFsyMDEyLTA4LTMx
IDIxOjMyOjM3XSAgIGdmbjogMDAwMDRhZjYgIG1mbjogMDAwMDRhZjYNCg0KKFhFTikgWzIw
MTItMDgtMzEgMjE6MzI6MzddICAgZ2ZuOiAwMDAwNGFmNyAgbWZuOiAwMDAwNGFmNw0KDQoo
WEVOKSBbMjAxMi0wOC0zMSAyMTozMjozN10gICBnZm46IDAwMDA0YWY4ICBtZm46IDAwMDA0
YWY4DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjM3XSAgIGdmbjogMDAwMDRhZjkgIG1m
bjogMDAwMDRhZjkNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MzddICAgZ2ZuOiAwMDAw
NGFmYSAgbWZuOiAwMDAwNGFmYQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjozN10gICBn
Zm46IDAwMDA0YWZiICBtZm46IDAwMDA0YWZiDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMy
OjM3XSAgIGdmbjogMDAwMDRhZmMgIG1mbjogMDAwMDRhZmMNCg0KKFhFTikgWzIwMTItMDgt
MzEgMjE6MzI6MzddICAgZ2ZuOiAwMDAwNGFmZCAgbWZuOiAwMDAwNGFmZA0KDQooWEVOKSBb
MjAxMi0wOC0zMSAyMTozMjozN10gICBnZm46IDAwMDA0YWZlICBtZm46IDAwMDA0YWZlDQoN
CihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjM3XSAgIGdmbjogMDAwMDRhZmYgIG1mbjogMDAw
MDRhZmYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MzddICAgZ2ZuOiAwMDAwNGIwMCAg
bWZuOiAwMDAwNGIwMA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjozN10gICBnZm46IDAw
MDA0YjAxICBtZm46IDAwMDA0YjAxDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjM3XSAg
IGdmbjogMDAwMDRiMDIgIG1mbjogMDAwMDRiMDINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6
MzI6MzddICAgZ2ZuOiAwMDAwNGIwMyAgbWZuOiAwMDAwNGIwMw0KDQooWEVOKSBbMjAxMi0w
OC0zMSAyMTozMjozN10gICBnZm46IDAwMDA0YjA0ICBtZm46IDAwMDA0YjA0DQoNCihYRU4p
IFsyMDEyLTA4LTMxIDIxOjMyOjM3XSAgIGdmbjogMDAwMDRiMDUgIG1mbjogMDAwMDRiMDUN
Cg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MzddICAgZ2ZuOiAwMDAwNGIwNiAgbWZuOiAw
MDAwNGIwNg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjozN10gICBnZm46IDAwMDA0YjA3
ICBtZm46IDAwMDA0YjA3DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjM3XSAgIGdmbjog
MDAwMDRiMDggIG1mbjogMDAwMDRiMDgNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6Mzdd
ICAgZ2ZuOiAwMDAwNGIwOSAgbWZuOiAwMDAwNGIwOQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAy
MTozMjozN10gICBnZm46IDAwMDA0YjBhICBtZm46IDAwMDA0YjBhDQoNCihYRU4pIFsyMDEy
LTA4LTMxIDIxOjMyOjM3XSAgIGdmbjogMDAwMDRiMGIgIG1mbjogMDAwMDRiMGINCg0KKFhF
TikgWzIwMTItMDgtMzEgMjE6MzI6MzddICAgZ2ZuOiAwMDAwNGIwYyAgbWZuOiAwMDAwNGIw
Yw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjozN10gICBnZm46IDAwMDA0YjBkICBtZm46
IDAwMDA0YjBkDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjM3XSAgIGdmbjogMDAwMDRi
MGUgIG1mbjogMDAwMDRiMGUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MzddICAgZ2Zu
OiAwMDAwNGIwZiAgbWZuOiAwMDAwNGIwZg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoz
N10gICBnZm46IDAwMDA0YjEwICBtZm46IDAwMDA0YjEwDQoNCihYRU4pIFsyMDEyLTA4LTMx
IDIxOjMyOjM3XSAgIGdmbjogMDAwMDRiMTEgIG1mbjogMDAwMDRiMTENCg0KKFhFTikgWzIw
MTItMDgtMzEgMjE6MzI6MzddICAgZ2ZuOiAwMDAwNGIxMiAgbWZuOiAwMDAwNGIxMg0KDQoo
WEVOKSBbMjAxMi0wOC0zMSAyMTozMjozN10gICBnZm46IDAwMDA0YjEzICBtZm46IDAwMDA0
YjEzDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjM3XSAgIGdmbjogMDAwMDRiMTQgIG1m
bjogMDAwMDRiMTQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MzddICAgZ2ZuOiAwMDAw
NGIxNSAgbWZuOiAwMDAwNGIxNQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjozN10gICBn
Zm46IDAwMDA0YjE2ICBtZm46IDAwMDA0YjE2DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMy
OjM3XSAgIGdmbjogMDAwMDRiMTcgIG1mbjogMDAwMDRiMTcNCg0KKFhFTikgWzIwMTItMDgt
MzEgMjE6MzI6MzddICAgZ2ZuOiAwMDAwNGIxOCAgbWZuOiAwMDAwNGIxOA0KDQooWEVOKSBb
MjAxMi0wOC0zMSAyMTozMjozN10gICBnZm46IDAwMDA0YjE5ICBtZm46IDAwMDA0YjE5DQoN
CihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjM3XSAgIGdmbjogMDAwMDRiMWEgIG1mbjogMDAw
MDRiMWENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MzddICAgZ2ZuOiAwMDAwNGIxYiAg
bWZuOiAwMDAwNGIxYg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjozN10gICBnZm46IDAw
MDA0YjFjICBtZm46IDAwMDA0YjFjDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjM3XSAg
IGdmbjogMDAwMDRiMWQgIG1mbjogMDAwMDRiMWQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6
MzI6MzddICAgZ2ZuOiAwMDAwNGIxZSAgbWZuOiAwMDAwNGIxZQ0KDQooWEVOKSBbMjAxMi0w
OC0zMSAyMTozMjozN10gICBnZm46IDAwMDA0YjFmICBtZm46IDAwMDA0YjFmDQoNCihYRU4p
IFsyMDEyLTA4LTMxIDIxOjMyOjM3XSAgIGdmbjogMDAwMDRiMjAgIG1mbjogMDAwMDRiMjAN
Cg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MzddICAgZ2ZuOiAwMDAwNGIyMSAgbWZuOiAw
MDAwNGIyMQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjozN10gICBnZm46IDAwMDA0YjIy
ICBtZm46IDAwMDA0YjIyDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjM3XSAgIGdmbjog
MDAwMDRiMjMgIG1mbjogMDAwMDRiMjMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6Mzdd
ICAgZ2ZuOiAwMDAwNGIyNCAgbWZuOiAwMDAwNGIyNA0KDQooWEVOKSBbMjAxMi0wOC0zMSAy
MTozMjozN10gICBnZm46IDAwMDA0YjI1ICBtZm46IDAwMDA0YjI1DQoNCihYRU4pIFsyMDEy
LTA4LTMxIDIxOjMyOjM3XSAgIGdmbjogMDAwMDRiMjYgIG1mbjogMDAwMDRiMjYNCg0KKFhF
TikgWzIwMTItMDgtMzEgMjE6MzI6MzddICAgZ2ZuOiAwMDAwNGIyNyAgbWZuOiAwMDAwNGIy
Nw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjozN10gICBnZm46IDAwMDA0YjI4ICBtZm46
IDAwMDA0YjI4DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjM3XSAgIGdmbjogMDAwMDRi
MjkgIG1mbjogMDAwMDRiMjkNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MzddICAgZ2Zu
OiAwMDAwNGIyYSAgbWZuOiAwMDAwNGIyYQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoz
N10gICBnZm46IDAwMDA0YjJiICBtZm46IDAwMDA0YjJiDQoNCihYRU4pIFsyMDEyLTA4LTMx
IDIxOjMyOjM3XSAgIGdmbjogMDAwMDRiMmMgIG1mbjogMDAwMDRiMmMNCg0KKFhFTikgWzIw
MTItMDgtMzEgMjE6MzI6MzddICAgZ2ZuOiAwMDAwNGIyZCAgbWZuOiAwMDAwNGIyZA0KDQoo
WEVOKSBbMjAxMi0wOC0zMSAyMTozMjozN10gICBnZm46IDAwMDA0YjJlICBtZm46IDAwMDA0
YjJlDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjM3XSAgIGdmbjogMDAwMDRiMmYgIG1m
bjogMDAwMDRiMmYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MzddICAgZ2ZuOiAwMDAw
NGIzMCAgbWZuOiAwMDAwNGIzMA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjozN10gICBn
Zm46IDAwMDA0YjMxICBtZm46IDAwMDA0YjMxDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMy
OjM4XSAgIGdmbjogMDAwMDRiMzIgIG1mbjogMDAwMDRiMzINCg0KKFhFTikgWzIwMTItMDgt
MzEgMjE6MzI6MzhdICAgZ2ZuOiAwMDAwNGIzMyAgbWZuOiAwMDAwNGIzMw0KDQooWEVOKSBb
MjAxMi0wOC0zMSAyMTozMjozOF0gICBnZm46IDAwMDA0YjM0ICBtZm46IDAwMDA0YjM0DQoN
CihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjM4XSAgIGdmbjogMDAwMDRiMzUgIG1mbjogMDAw
MDRiMzUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MzhdICAgZ2ZuOiAwMDAwNGIzNiAg
bWZuOiAwMDAwNGIzNg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjozOF0gICBnZm46IDAw
MDA0YjM3ICBtZm46IDAwMDA0YjM3DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjM4XSAg
IGdmbjogMDAwMDRiMzggIG1mbjogMDAwMDRiMzgNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6
MzI6MzhdICAgZ2ZuOiAwMDAwNGIzOSAgbWZuOiAwMDAwNGIzOQ0KDQooWEVOKSBbMjAxMi0w
OC0zMSAyMTozMjozOF0gICBnZm46IDAwMDA0YjNhICBtZm46IDAwMDA0YjNhDQoNCihYRU4p
IFsyMDEyLTA4LTMxIDIxOjMyOjM4XSAgIGdmbjogMDAwMDRiM2IgIG1mbjogMDAwMDRiM2IN
Cg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MzhdICAgZ2ZuOiAwMDAwNGIzYyAgbWZuOiAw
MDAwNGIzYw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjozOF0gICBnZm46IDAwMDA0YjNk
ICBtZm46IDAwMDA0YjNkDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjM4XSAgIGdmbjog
MDAwMDRiM2UgIG1mbjogMDAwMDRiM2UNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6Mzhd
ICAgZ2ZuOiAwMDAwNGIzZiAgbWZuOiAwMDAwNGIzZg0KDQooWEVOKSBbMjAxMi0wOC0zMSAy
MTozMjozOF0gICBnZm46IDAwMDA0YjQwICBtZm46IDAwMDA0YjQwDQoNCihYRU4pIFsyMDEy
LTA4LTMxIDIxOjMyOjM4XSAgIGdmbjogMDAwMDRiNDEgIG1mbjogMDAwMDRiNDENCg0KKFhF
TikgWzIwMTItMDgtMzEgMjE6MzI6MzhdICAgZ2ZuOiAwMDAwNGI0MiAgbWZuOiAwMDAwNGI0
Mg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjozOF0gICBnZm46IDAwMDA0YjQzICBtZm46
IDAwMDA0YjQzDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjM4XSAgIGdmbjogMDAwMDRi
NDQgIG1mbjogMDAwMDRiNDQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MzhdICAgZ2Zu
OiAwMDAwNGI0NSAgbWZuOiAwMDAwNGI0NQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoz
OF0gICBnZm46IDAwMDA0YjQ2ICBtZm46IDAwMDA0YjQ2DQoNCihYRU4pIFsyMDEyLTA4LTMx
IDIxOjMyOjM4XSAgIGdmbjogMDAwMDRiNDcgIG1mbjogMDAwMDRiNDcNCg0KKFhFTikgWzIw
MTItMDgtMzEgMjE6MzI6MzhdICAgZ2ZuOiAwMDAwNGI0OCAgbWZuOiAwMDAwNGI0OA0KDQoo
WEVOKSBbMjAxMi0wOC0zMSAyMTozMjozOF0gICBnZm46IDAwMDA0YjQ5ICBtZm46IDAwMDA0
YjQ5DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjM4XSAgIGdmbjogMDAwMDRiNGEgIG1m
bjogMDAwMDRiNGENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MzhdICAgZ2ZuOiAwMDAw
NGI0YiAgbWZuOiAwMDAwNGI0Yg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjozOF0gICBn
Zm46IDAwMDA0YjRjICBtZm46IDAwMDA0YjRjDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMy
OjM4XSAgIGdmbjogMDAwMDRiNGQgIG1mbjogMDAwMDRiNGQNCg0KKFhFTikgWzIwMTItMDgt
MzEgMjE6MzI6MzhdICAgZ2ZuOiAwMDAwNGI0ZSAgbWZuOiAwMDAwNGI0ZQ0KDQooWEVOKSBb
MjAxMi0wOC0zMSAyMTozMjozOF0gICBnZm46IDAwMDA0YjRmICBtZm46IDAwMDA0YjRmDQoN
CihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjM4XSAgIGdmbjogMDAwMDRiNTAgIG1mbjogMDAw
MDRiNTANCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MzhdICAgZ2ZuOiAwMDAwNGI1MSAg
bWZuOiAwMDAwNGI1MQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjozOF0gICBnZm46IDAw
MDA0YjUyICBtZm46IDAwMDA0YjUyDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjM4XSAg
IGdmbjogMDAwMDRiNTMgIG1mbjogMDAwMDRiNTMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6
MzI6MzhdICAgZ2ZuOiAwMDAwNGI1NCAgbWZuOiAwMDAwNGI1NA0KDQooWEVOKSBbMjAxMi0w
OC0zMSAyMTozMjozOF0gICBnZm46IDAwMDA0YjU1ICBtZm46IDAwMDA0YjU1DQoNCihYRU4p
IFsyMDEyLTA4LTMxIDIxOjMyOjM4XSAgIGdmbjogMDAwMDRiNTYgIG1mbjogMDAwMDRiNTYN
Cg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MzhdICAgZ2ZuOiAwMDAwNGI1NyAgbWZuOiAw
MDAwNGI1Nw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjozOF0gICBnZm46IDAwMDA0YjU4
ICBtZm46IDAwMDA0YjU4DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjM4XSAgIGdmbjog
MDAwMDRiNTkgIG1mbjogMDAwMDRiNTkNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6Mzhd
ICAgZ2ZuOiAwMDAwNGI1YSAgbWZuOiAwMDAwNGI1YQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAy
MTozMjozOF0gICBnZm46IDAwMDA0YjViICBtZm46IDAwMDA0YjViDQoNCihYRU4pIFsyMDEy
LTA4LTMxIDIxOjMyOjM4XSAgIGdmbjogMDAwMDRiNWMgIG1mbjogMDAwMDRiNWMNCg0KKFhF
TikgWzIwMTItMDgtMzEgMjE6MzI6MzhdICAgZ2ZuOiAwMDAwNGI1ZCAgbWZuOiAwMDAwNGI1
ZA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjozOF0gICBnZm46IDAwMDA0YjVlICBtZm46
IDAwMDA0YjVlDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjM4XSAgIGdmbjogMDAwMDRi
NWYgIG1mbjogMDAwMDRiNWYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MzhdICAgZ2Zu
OiAwMDAwNGI2MCAgbWZuOiAwMDAwNGI2MA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoz
OF0gICBnZm46IDAwMDA0YjYxICBtZm46IDAwMDA0YjYxDQoNCihYRU4pIFsyMDEyLTA4LTMx
IDIxOjMyOjM4XSAgIGdmbjogMDAwMDRiNjIgIG1mbjogMDAwMDRiNjINCg0KKFhFTikgWzIw
MTItMDgtMzEgMjE6MzI6MzhdICAgZ2ZuOiAwMDAwNGI2MyAgbWZuOiAwMDAwNGI2Mw0KDQoo
WEVOKSBbMjAxMi0wOC0zMSAyMTozMjozOF0gICBnZm46IDAwMDA0YjY0ICBtZm46IDAwMDA0
YjY0DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjM4XSAgIGdmbjogMDAwMDRiNjUgIG1m
bjogMDAwMDRiNjUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MzhdICAgZ2ZuOiAwMDAw
NGI2NiAgbWZuOiAwMDAwNGI2Ng0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjozOF0gICBn
Zm46IDAwMDA0YjY3ICBtZm46IDAwMDA0YjY3DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMy
OjM4XSAgIGdmbjogMDAwMDRiNjggIG1mbjogMDAwMDRiNjgNCg0KKFhFTikgWzIwMTItMDgt
MzEgMjE6MzI6MzhdICAgZ2ZuOiAwMDAwNGI2OSAgbWZuOiAwMDAwNGI2OQ0KDQooWEVOKSBb
MjAxMi0wOC0zMSAyMTozMjozOF0gICBnZm46IDAwMDA0YjZhICBtZm46IDAwMDA0YjZhDQoN
CihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjM4XSAgIGdmbjogMDAwMDRiNmIgIG1mbjogMDAw
MDRiNmINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MzhdICAgZ2ZuOiAwMDAwNGI2YyAg
bWZuOiAwMDAwNGI2Yw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjozOF0gICBnZm46IDAw
MDA0YjZkICBtZm46IDAwMDA0YjZkDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjM4XSAg
IGdmbjogMDAwMDRiNmUgIG1mbjogMDAwMDRiNmUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6
MzI6MzhdICAgZ2ZuOiAwMDAwNGI2ZiAgbWZuOiAwMDAwNGI2Zg0KDQooWEVOKSBbMjAxMi0w
OC0zMSAyMTozMjozOF0gICBnZm46IDAwMDA0YjcwICBtZm46IDAwMDA0YjcwDQoNCihYRU4p
IFsyMDEyLTA4LTMxIDIxOjMyOjM4XSAgIGdmbjogMDAwMDRiNzEgIG1mbjogMDAwMDRiNzEN
Cg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MzldICAgZ2ZuOiAwMDAwNGI3MiAgbWZuOiAw
MDAwNGI3Mg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjozOV0gICBnZm46IDAwMDA0Yjcz
ICBtZm46IDAwMDA0YjczDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjM5XSAgIGdmbjog
MDAwMDRiNzQgIG1mbjogMDAwMDRiNzQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6Mzld
ICAgZ2ZuOiAwMDAwNGI3NSAgbWZuOiAwMDAwNGI3NQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAy
MTozMjozOV0gICBnZm46IDAwMDA0Yjc2ICBtZm46IDAwMDA0Yjc2DQoNCihYRU4pIFsyMDEy
LTA4LTMxIDIxOjMyOjM5XSAgIGdmbjogMDAwMDRiNzcgIG1mbjogMDAwMDRiNzcNCg0KKFhF
TikgWzIwMTItMDgtMzEgMjE6MzI6MzldICAgZ2ZuOiAwMDAwNGI3OCAgbWZuOiAwMDAwNGI3
OA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjozOV0gICBnZm46IDAwMDA0Yjc5ICBtZm46
IDAwMDA0Yjc5DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjM5XSAgIGdmbjogMDAwMDRi
N2EgIG1mbjogMDAwMDRiN2ENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MzldICAgZ2Zu
OiAwMDAwNGI3YiAgbWZuOiAwMDAwNGI3Yg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoz
OV0gICBnZm46IDAwMDA0YjdjICBtZm46IDAwMDA0YjdjDQoNCihYRU4pIFsyMDEyLTA4LTMx
IDIxOjMyOjM5XSAgIGdmbjogMDAwMDRiN2QgIG1mbjogMDAwMDRiN2QNCg0KKFhFTikgWzIw
MTItMDgtMzEgMjE6MzI6MzldICAgZ2ZuOiAwMDAwNGI3ZSAgbWZuOiAwMDAwNGI3ZQ0KDQoo
WEVOKSBbMjAxMi0wOC0zMSAyMTozMjozOV0gICBnZm46IDAwMDA0YjdmICBtZm46IDAwMDA0
YjdmDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjM5XSAgIGdmbjogMDAwMDRiODAgIG1m
bjogMDAwMDRiODANCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MzldICAgZ2ZuOiAwMDAw
NGI4MSAgbWZuOiAwMDAwNGI4MQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjozOV0gICBn
Zm46IDAwMDA0YjgyICBtZm46IDAwMDA0YjgyDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMy
OjM5XSAgIGdmbjogMDAwMDRiODMgIG1mbjogMDAwMDRiODMNCg0KKFhFTikgWzIwMTItMDgt
MzEgMjE6MzI6MzldICAgZ2ZuOiAwMDAwNGI4NCAgbWZuOiAwMDAwNGI4NA0KDQooWEVOKSBb
MjAxMi0wOC0zMSAyMTozMjozOV0gICBnZm46IDAwMDA0Yjg1ICBtZm46IDAwMDA0Yjg1DQoN
CihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjM5XSAgIGdmbjogMDAwMDRiODYgIG1mbjogMDAw
MDRiODYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MzldICAgZ2ZuOiAwMDAwNGI4NyAg
bWZuOiAwMDAwNGI4Nw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjozOV0gICBnZm46IDAw
MDA0Yjg4ICBtZm46IDAwMDA0Yjg4DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjM5XSAg
IGdmbjogMDAwMDRiODkgIG1mbjogMDAwMDRiODkNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6
MzI6MzldICAgZ2ZuOiAwMDAwNGI4YSAgbWZuOiAwMDAwNGI4YQ0KDQooWEVOKSBbMjAxMi0w
OC0zMSAyMTozMjozOV0gICBnZm46IDAwMDA0YjhiICBtZm46IDAwMDA0YjhiDQoNCihYRU4p
IFsyMDEyLTA4LTMxIDIxOjMyOjM5XSAgIGdmbjogMDAwMDRiOGMgIG1mbjogMDAwMDRiOGMN
Cg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MzldICAgZ2ZuOiAwMDAwNGI4ZCAgbWZuOiAw
MDAwNGI4ZA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjozOV0gICBnZm46IDAwMDA0Yjhl
ICBtZm46IDAwMDA0YjhlDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjM5XSAgIGdmbjog
MDAwMDRiOGYgIG1mbjogMDAwMDRiOGYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6Mzld
ICAgZ2ZuOiAwMDAwNGI5MCAgbWZuOiAwMDAwNGI5MA0KDQooWEVOKSBbMjAxMi0wOC0zMSAy
MTozMjozOV0gICBnZm46IDAwMDA0YjkxICBtZm46IDAwMDA0YjkxDQoNCihYRU4pIFsyMDEy
LTA4LTMxIDIxOjMyOjM5XSAgIGdmbjogMDAwMDRiOTIgIG1mbjogMDAwMDRiOTINCg0KKFhF
TikgWzIwMTItMDgtMzEgMjE6MzI6MzldICAgZ2ZuOiAwMDAwNGI5MyAgbWZuOiAwMDAwNGI5
Mw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjozOV0gICBnZm46IDAwMDA0Yjk0ICBtZm46
IDAwMDA0Yjk0DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjM5XSAgIGdmbjogMDAwMDRi
OTUgIG1mbjogMDAwMDRiOTUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MzldICAgZ2Zu
OiAwMDAwNGI5NiAgbWZuOiAwMDAwNGI5Ng0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoz
OV0gICBnZm46IDAwMDA0Yjk3ICBtZm46IDAwMDA0Yjk3DQoNCihYRU4pIFsyMDEyLTA4LTMx
IDIxOjMyOjM5XSAgIGdmbjogMDAwMDRiOTggIG1mbjogMDAwMDRiOTgNCg0KKFhFTikgWzIw
MTItMDgtMzEgMjE6MzI6MzldICAgZ2ZuOiAwMDAwNGI5OSAgbWZuOiAwMDAwNGI5OQ0KDQoo
WEVOKSBbMjAxMi0wOC0zMSAyMTozMjozOV0gICBnZm46IDAwMDA0YjlhICBtZm46IDAwMDA0
YjlhDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjM5XSAgIGdmbjogMDAwMDRiOWIgIG1m
bjogMDAwMDRiOWINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MzldICAgZ2ZuOiAwMDAw
NGI5YyAgbWZuOiAwMDAwNGI5Yw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjozOV0gICBn
Zm46IDAwMDA0YjlkICBtZm46IDAwMDA0YjlkDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMy
OjM5XSAgIGdmbjogMDAwMDRiOWUgIG1mbjogMDAwMDRiOWUNCg0KKFhFTikgWzIwMTItMDgt
MzEgMjE6MzI6MzldICAgZ2ZuOiAwMDAwNGI5ZiAgbWZuOiAwMDAwNGI5Zg0KDQooWEVOKSBb
MjAxMi0wOC0zMSAyMTozMjozOV0gICBnZm46IDAwMDA0YmEwICBtZm46IDAwMDA0YmEwDQoN
CihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjM5XSAgIGdmbjogMDAwMDRiYTEgIG1mbjogMDAw
MDRiYTENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MzldICAgZ2ZuOiAwMDAwNGJhMiAg
bWZuOiAwMDAwNGJhMg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjozOV0gICBnZm46IDAw
MDA0YmEzICBtZm46IDAwMDA0YmEzDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjM5XSAg
IGdmbjogMDAwMDRiYTQgIG1mbjogMDAwMDRiYTQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6
MzI6MzldICAgZ2ZuOiAwMDAwNGJhNSAgbWZuOiAwMDAwNGJhNQ0KDQooWEVOKSBbMjAxMi0w
OC0zMSAyMTozMjozOV0gICBnZm46IDAwMDA0YmE2ICBtZm46IDAwMDA0YmE2DQoNCihYRU4p
IFsyMDEyLTA4LTMxIDIxOjMyOjM5XSAgIGdmbjogMDAwMDRiYTcgIG1mbjogMDAwMDRiYTcN
Cg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MzldICAgZ2ZuOiAwMDAwNGJhOCAgbWZuOiAw
MDAwNGJhOA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjozOV0gICBnZm46IDAwMDA0YmE5
ICBtZm46IDAwMDA0YmE5DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjM5XSAgIGdmbjog
MDAwMDRiYWEgIG1mbjogMDAwMDRiYWENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6Mzld
ICAgZ2ZuOiAwMDAwNGJhYiAgbWZuOiAwMDAwNGJhYg0KDQooWEVOKSBbMjAxMi0wOC0zMSAy
MTozMjozOV0gICBnZm46IDAwMDA0YmFjICBtZm46IDAwMDA0YmFjDQoNCihYRU4pIFsyMDEy
LTA4LTMxIDIxOjMyOjM5XSAgIGdmbjogMDAwMDRiYWQgIG1mbjogMDAwMDRiYWQNCg0KKFhF
TikgWzIwMTItMDgtMzEgMjE6MzI6MzldICAgZ2ZuOiAwMDAwNGJhZSAgbWZuOiAwMDAwNGJh
ZQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjozOV0gICBnZm46IDAwMDA0YmFmICBtZm46
IDAwMDA0YmFmDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjM5XSAgIGdmbjogMDAwMDRi
YjAgIG1mbjogMDAwMDRiYjANCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MzldICAgZ2Zu
OiAwMDAwNGJiMSAgbWZuOiAwMDAwNGJiMQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo0
MF0gICBnZm46IDAwMDA0YmIyICBtZm46IDAwMDA0YmIyDQoNCihYRU4pIFsyMDEyLTA4LTMx
IDIxOjMyOjQwXSAgIGdmbjogMDAwMDRiYjMgIG1mbjogMDAwMDRiYjMNCg0KKFhFTikgWzIw
MTItMDgtMzEgMjE6MzI6NDBdICAgZ2ZuOiAwMDAwNGJiNCAgbWZuOiAwMDAwNGJiNA0KDQoo
WEVOKSBbMjAxMi0wOC0zMSAyMTozMjo0MF0gICBnZm46IDAwMDA0YmI1ICBtZm46IDAwMDA0
YmI1DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjQwXSAgIGdmbjogMDAwMDRiYjYgIG1m
bjogMDAwMDRiYjYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NDBdICAgZ2ZuOiAwMDAw
NGJiNyAgbWZuOiAwMDAwNGJiNw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo0MF0gICBn
Zm46IDAwMDA0YmI4ICBtZm46IDAwMDA0YmI4DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMy
OjQwXSAgIGdmbjogMDAwMDRiYjkgIG1mbjogMDAwMDRiYjkNCg0KKFhFTikgWzIwMTItMDgt
MzEgMjE6MzI6NDBdICAgZ2ZuOiAwMDAwNGJiYSAgbWZuOiAwMDAwNGJiYQ0KDQooWEVOKSBb
MjAxMi0wOC0zMSAyMTozMjo0MF0gICBnZm46IDAwMDA0YmJiICBtZm46IDAwMDA0YmJiDQoN
CihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjQwXSAgIGdmbjogMDAwMDRiYmMgIG1mbjogMDAw
MDRiYmMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NDBdICAgZ2ZuOiAwMDAwNGJiZCAg
bWZuOiAwMDAwNGJiZA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo0MF0gICBnZm46IDAw
MDA0YmJlICBtZm46IDAwMDA0YmJlDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjQwXSAg
IGdmbjogMDAwMDRiYmYgIG1mbjogMDAwMDRiYmYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6
MzI6NDBdICAgZ2ZuOiAwMDAwNGJjMCAgbWZuOiAwMDAwNGJjMA0KDQooWEVOKSBbMjAxMi0w
OC0zMSAyMTozMjo0MF0gICBnZm46IDAwMDA0YmMxICBtZm46IDAwMDA0YmMxDQoNCihYRU4p
IFsyMDEyLTA4LTMxIDIxOjMyOjQwXSAgIGdmbjogMDAwMDRiYzIgIG1mbjogMDAwMDRiYzIN
Cg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NDBdICAgZ2ZuOiAwMDAwNGJjMyAgbWZuOiAw
MDAwNGJjMw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo0MF0gICBnZm46IDAwMDA0YmM0
ICBtZm46IDAwMDA0YmM0DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjQwXSAgIGdmbjog
MDAwMDRiYzUgIG1mbjogMDAwMDRiYzUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NDBd
ICAgZ2ZuOiAwMDAwNGJjNiAgbWZuOiAwMDAwNGJjNg0KDQooWEVOKSBbMjAxMi0wOC0zMSAy
MTozMjo0MF0gICBnZm46IDAwMDA0YmM3ICBtZm46IDAwMDA0YmM3DQoNCihYRU4pIFsyMDEy
LTA4LTMxIDIxOjMyOjQwXSAgIGdmbjogMDAwMDRiYzggIG1mbjogMDAwMDRiYzgNCg0KKFhF
TikgWzIwMTItMDgtMzEgMjE6MzI6NDBdICAgZ2ZuOiAwMDAwNGJjOSAgbWZuOiAwMDAwNGJj
OQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo0MF0gICBnZm46IDAwMDA0YmNhICBtZm46
IDAwMDA0YmNhDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjQwXSAgIGdmbjogMDAwMDRi
Y2IgIG1mbjogMDAwMDRiY2INCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NDBdICAgZ2Zu
OiAwMDAwNGJjYyAgbWZuOiAwMDAwNGJjYw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo0
MF0gICBnZm46IDAwMDA0YmNkICBtZm46IDAwMDA0YmNkDQoNCihYRU4pIFsyMDEyLTA4LTMx
IDIxOjMyOjQwXSAgIGdmbjogMDAwMDRiY2UgIG1mbjogMDAwMDRiY2UNCg0KKFhFTikgWzIw
MTItMDgtMzEgMjE6MzI6NDBdICAgZ2ZuOiAwMDAwNGJjZiAgbWZuOiAwMDAwNGJjZg0KDQoo
WEVOKSBbMjAxMi0wOC0zMSAyMTozMjo0MF0gICBnZm46IDAwMDA0YmQwICBtZm46IDAwMDA0
YmQwDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjQwXSAgIGdmbjogMDAwMDRiZDEgIG1m
bjogMDAwMDRiZDENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NDBdICAgZ2ZuOiAwMDAw
NGJkMiAgbWZuOiAwMDAwNGJkMg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo0MF0gICBn
Zm46IDAwMDA0YmQzICBtZm46IDAwMDA0YmQzDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMy
OjQwXSAgIGdmbjogMDAwMDRiZDQgIG1mbjogMDAwMDRiZDQNCg0KKFhFTikgWzIwMTItMDgt
MzEgMjE6MzI6NDBdICAgZ2ZuOiAwMDAwNGJkNSAgbWZuOiAwMDAwNGJkNQ0KDQooWEVOKSBb
MjAxMi0wOC0zMSAyMTozMjo0MF0gICBnZm46IDAwMDA0YmQ2ICBtZm46IDAwMDA0YmQ2DQoN
CihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjQwXSAgIGdmbjogMDAwMDRiZDcgIG1mbjogMDAw
MDRiZDcNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NDBdICAgZ2ZuOiAwMDAwNGJkOCAg
bWZuOiAwMDAwNGJkOA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo0MF0gICBnZm46IDAw
MDA0YmQ5ICBtZm46IDAwMDA0YmQ5DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjQwXSAg
IGdmbjogMDAwMDRiZGEgIG1mbjogMDAwMDRiZGENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6
MzI6NDBdICAgZ2ZuOiAwMDAwNGJkYiAgbWZuOiAwMDAwNGJkYg0KDQooWEVOKSBbMjAxMi0w
OC0zMSAyMTozMjo0MF0gICBnZm46IDAwMDA0YmRjICBtZm46IDAwMDA0YmRjDQoNCihYRU4p
IFsyMDEyLTA4LTMxIDIxOjMyOjQwXSAgIGdmbjogMDAwMDRiZGQgIG1mbjogMDAwMDRiZGQN
Cg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NDBdICAgZ2ZuOiAwMDAwNGJkZSAgbWZuOiAw
MDAwNGJkZQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo0MF0gICBnZm46IDAwMDA0YmRm
ICBtZm46IDAwMDA0YmRmDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjQwXSAgIGdmbjog
MDAwMDRiZTAgIG1mbjogMDAwMDRiZTANCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NDBd
ICAgZ2ZuOiAwMDAwNGJlMSAgbWZuOiAwMDAwNGJlMQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAy
MTozMjo0MF0gICBnZm46IDAwMDA0YmUyICBtZm46IDAwMDA0YmUyDQoNCihYRU4pIFsyMDEy
LTA4LTMxIDIxOjMyOjQwXSAgIGdmbjogMDAwMDRiZTMgIG1mbjogMDAwMDRiZTMNCg0KKFhF
TikgWzIwMTItMDgtMzEgMjE6MzI6NDBdICAgZ2ZuOiAwMDAwNGJlNCAgbWZuOiAwMDAwNGJl
NA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo0MF0gICBnZm46IDAwMDA0YmU1ICBtZm46
IDAwMDA0YmU1DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjQwXSAgIGdmbjogMDAwMDRi
ZTYgIG1mbjogMDAwMDRiZTYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NDBdICAgZ2Zu
OiAwMDAwNGJlNyAgbWZuOiAwMDAwNGJlNw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo0
MF0gICBnZm46IDAwMDA0YmU4ICBtZm46IDAwMDA0YmU4DQoNCihYRU4pIFsyMDEyLTA4LTMx
IDIxOjMyOjQwXSAgIGdmbjogMDAwMDRiZTkgIG1mbjogMDAwMDRiZTkNCg0KKFhFTikgWzIw
MTItMDgtMzEgMjE6MzI6NDBdICAgZ2ZuOiAwMDAwNGJlYSAgbWZuOiAwMDAwNGJlYQ0KDQoo
WEVOKSBbMjAxMi0wOC0zMSAyMTozMjo0MF0gICBnZm46IDAwMDA0YmViICBtZm46IDAwMDA0
YmViDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjQwXSAgIGdmbjogMDAwMDRiZWMgIG1m
bjogMDAwMDRiZWMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NDBdICAgZ2ZuOiAwMDAw
NGJlZCAgbWZuOiAwMDAwNGJlZA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo0MF0gICBn
Zm46IDAwMDA0YmVlICBtZm46IDAwMDA0YmVlDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMy
OjQwXSAgIGdmbjogMDAwMDRiZWYgIG1mbjogMDAwMDRiZWYNCg0KKFhFTikgWzIwMTItMDgt
MzEgMjE6MzI6NDBdICAgZ2ZuOiAwMDAwNGJmMCAgbWZuOiAwMDAwNGJmMA0KDQooWEVOKSBb
MjAxMi0wOC0zMSAyMTozMjo0MF0gICBnZm46IDAwMDA0YmYxICBtZm46IDAwMDA0YmYxDQoN
CihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjQxXSAgIGdmbjogMDAwMDRiZjIgIG1mbjogMDAw
MDRiZjINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NDFdICAgZ2ZuOiAwMDAwNGJmMyAg
bWZuOiAwMDAwNGJmMw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo0MV0gICBnZm46IDAw
MDA0YmY0ICBtZm46IDAwMDA0YmY0DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjQxXSAg
IGdmbjogMDAwMDRiZjUgIG1mbjogMDAwMDRiZjUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6
MzI6NDFdICAgZ2ZuOiAwMDAwNGJmNiAgbWZuOiAwMDAwNGJmNg0KDQooWEVOKSBbMjAxMi0w
OC0zMSAyMTozMjo0MV0gICBnZm46IDAwMDA0YmY3ICBtZm46IDAwMDA0YmY3DQoNCihYRU4p
IFsyMDEyLTA4LTMxIDIxOjMyOjQxXSAgIGdmbjogMDAwMDRiZjggIG1mbjogMDAwMDRiZjgN
Cg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NDFdICAgZ2ZuOiAwMDAwNGJmOSAgbWZuOiAw
MDAwNGJmOQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo0MV0gICBnZm46IDAwMDA0YmZh
ICBtZm46IDAwMDA0YmZhDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjQxXSAgIGdmbjog
MDAwMDRiZmIgIG1mbjogMDAwMDRiZmINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NDFd
ICAgZ2ZuOiAwMDAwNGJmYyAgbWZuOiAwMDAwNGJmYw0KDQooWEVOKSBbMjAxMi0wOC0zMSAy
MTozMjo0MV0gICBnZm46IDAwMDA0YmZkICBtZm46IDAwMDA0YmZkDQoNCihYRU4pIFsyMDEy
LTA4LTMxIDIxOjMyOjQxXSAgIGdmbjogMDAwMDRiZmUgIG1mbjogMDAwMDRiZmUNCg0KKFhF
TikgWzIwMTItMDgtMzEgMjE6MzI6NDFdICAgZ2ZuOiAwMDAwNGJmZiAgbWZuOiAwMDAwNGJm
Zg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo0MV0gICBnZm46IDAwMDA0YzAwICBtZm46
IDAwMDA0YzAwDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjQxXSAgIGdmbjogMDAwMDRj
MDEgIG1mbjogMDAwMDRjMDENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NDFdICAgZ2Zu
OiAwMDAwNGMwMiAgbWZuOiAwMDAwNGMwMg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo0
MV0gICBnZm46IDAwMDA0YzAzICBtZm46IDAwMDA0YzAzDQoNCihYRU4pIFsyMDEyLTA4LTMx
IDIxOjMyOjQxXSAgIGdmbjogMDAwMDRjMDQgIG1mbjogMDAwMDRjMDQNCg0KKFhFTikgWzIw
MTItMDgtMzEgMjE6MzI6NDFdICAgZ2ZuOiAwMDAwNGMwNSAgbWZuOiAwMDAwNGMwNQ0KDQoo
WEVOKSBbMjAxMi0wOC0zMSAyMTozMjo0MV0gICBnZm46IDAwMDA0YzA2ICBtZm46IDAwMDA0
YzA2DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjQxXSAgIGdmbjogMDAwMDRjMDcgIG1m
bjogMDAwMDRjMDcNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NDFdICAgZ2ZuOiAwMDAw
NGMwOCAgbWZuOiAwMDAwNGMwOA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo0MV0gICBn
Zm46IDAwMDA0YzA5ICBtZm46IDAwMDA0YzA5DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMy
OjQxXSAgIGdmbjogMDAwMDRjMGEgIG1mbjogMDAwMDRjMGENCg0KKFhFTikgWzIwMTItMDgt
MzEgMjE6MzI6NDFdICAgZ2ZuOiAwMDAwNGMwYiAgbWZuOiAwMDAwNGMwYg0KDQooWEVOKSBb
MjAxMi0wOC0zMSAyMTozMjo0MV0gICBnZm46IDAwMDA0YzBjICBtZm46IDAwMDA0YzBjDQoN
CihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjQxXSAgIGdmbjogMDAwMDRjMGQgIG1mbjogMDAw
MDRjMGQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NDFdICAgZ2ZuOiAwMDAwNGMwZSAg
bWZuOiAwMDAwNGMwZQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo0MV0gICBnZm46IDAw
MDA0YzBmICBtZm46IDAwMDA0YzBmDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjQxXSAg
IGdmbjogMDAwMDRjMTAgIG1mbjogMDAwMDRjMTANCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6
MzI6NDFdICAgZ2ZuOiAwMDAwNGMxMSAgbWZuOiAwMDAwNGMxMQ0KDQooWEVOKSBbMjAxMi0w
OC0zMSAyMTozMjo0MV0gICBnZm46IDAwMDA0YzEyICBtZm46IDAwMDA0YzEyDQoNCihYRU4p
IFsyMDEyLTA4LTMxIDIxOjMyOjQxXSAgIGdmbjogMDAwMDRjMTMgIG1mbjogMDAwMDRjMTMN
Cg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NDFdICAgZ2ZuOiAwMDAwNGMxNCAgbWZuOiAw
MDAwNGMxNA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo0MV0gICBnZm46IDAwMDA0YzE1
ICBtZm46IDAwMDA0YzE1DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjQxXSAgIGdmbjog
MDAwMDRjMTYgIG1mbjogMDAwMDRjMTYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NDFd
ICAgZ2ZuOiAwMDAwNGMxNyAgbWZuOiAwMDAwNGMxNw0KDQooWEVOKSBbMjAxMi0wOC0zMSAy
MTozMjo0MV0gICBnZm46IDAwMDA0YzE4ICBtZm46IDAwMDA0YzE4DQoNCihYRU4pIFsyMDEy
LTA4LTMxIDIxOjMyOjQxXSAgIGdmbjogMDAwMDRjMTkgIG1mbjogMDAwMDRjMTkNCg0KKFhF
TikgWzIwMTItMDgtMzEgMjE6MzI6NDFdICAgZ2ZuOiAwMDAwNGMxYSAgbWZuOiAwMDAwNGMx
YQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo0MV0gICBnZm46IDAwMDA0YzFiICBtZm46
IDAwMDA0YzFiDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjQxXSAgIGdmbjogMDAwMDRj
MWMgIG1mbjogMDAwMDRjMWMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NDFdICAgZ2Zu
OiAwMDAwNGMxZCAgbWZuOiAwMDAwNGMxZA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo0
MV0gICBnZm46IDAwMDA0YzFlICBtZm46IDAwMDA0YzFlDQoNCihYRU4pIFsyMDEyLTA4LTMx
IDIxOjMyOjQxXSAgIGdmbjogMDAwMDRjMWYgIG1mbjogMDAwMDRjMWYNCg0KKFhFTikgWzIw
MTItMDgtMzEgMjE6MzI6NDFdICAgZ2ZuOiAwMDAwNGMyMCAgbWZuOiAwMDAwNGMyMA0KDQoo
WEVOKSBbMjAxMi0wOC0zMSAyMTozMjo0MV0gICBnZm46IDAwMDA0YzIxICBtZm46IDAwMDA0
YzIxDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjQxXSAgIGdmbjogMDAwMDRjMjIgIG1m
bjogMDAwMDRjMjINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NDFdICAgZ2ZuOiAwMDAw
NGMyMyAgbWZuOiAwMDAwNGMyMw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo0MV0gICBn
Zm46IDAwMDA0YzI0ICBtZm46IDAwMDA0YzI0DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMy
OjQxXSAgIGdmbjogMDAwMDRjMjUgIG1mbjogMDAwMDRjMjUNCg0KKFhFTikgWzIwMTItMDgt
MzEgMjE6MzI6NDFdICAgZ2ZuOiAwMDAwNGMyNiAgbWZuOiAwMDAwNGMyNg0KDQooWEVOKSBb
MjAxMi0wOC0zMSAyMTozMjo0MV0gICBnZm46IDAwMDA0YzI3ICBtZm46IDAwMDA0YzI3DQoN
CihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjQxXSAgIGdmbjogMDAwMDRjMjggIG1mbjogMDAw
MDRjMjgNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NDFdICAgZ2ZuOiAwMDAwNGMyOSAg
bWZuOiAwMDAwNGMyOQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo0MV0gICBnZm46IDAw
MDA0YzJhICBtZm46IDAwMDA0YzJhDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjQxXSAg
IGdmbjogMDAwMDRjMmIgIG1mbjogMDAwMDRjMmINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6
MzI6NDFdICAgZ2ZuOiAwMDAwNGMyYyAgbWZuOiAwMDAwNGMyYw0KDQooWEVOKSBbMjAxMi0w
OC0zMSAyMTozMjo0MV0gICBnZm46IDAwMDA0YzJkICBtZm46IDAwMDA0YzJkDQoNCihYRU4p
IFsyMDEyLTA4LTMxIDIxOjMyOjQxXSAgIGdmbjogMDAwMDRjMmUgIG1mbjogMDAwMDRjMmUN
Cg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NDFdICAgZ2ZuOiAwMDAwNGMyZiAgbWZuOiAw
MDAwNGMyZg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo0MV0gICBnZm46IDAwMDA0YzMw
ICBtZm46IDAwMDA0YzMwDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjQxXSAgIGdmbjog
MDAwMDRjMzEgIG1mbjogMDAwMDRjMzENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NDJd
ICAgZ2ZuOiAwMDAwNGMzMiAgbWZuOiAwMDAwNGMzMg0KDQooWEVOKSBbMjAxMi0wOC0zMSAy
MTozMjo0Ml0gICBnZm46IDAwMDA0YzMzICBtZm46IDAwMDA0YzMzDQoNCihYRU4pIFsyMDEy
LTA4LTMxIDIxOjMyOjQyXSAgIGdmbjogMDAwMDRjMzQgIG1mbjogMDAwMDRjMzQNCg0KKFhF
TikgWzIwMTItMDgtMzEgMjE6MzI6NDJdICAgZ2ZuOiAwMDAwNGMzNSAgbWZuOiAwMDAwNGMz
NQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo0Ml0gICBnZm46IDAwMDA0YzM2ICBtZm46
IDAwMDA0YzM2DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjQyXSAgIGdmbjogMDAwMDRj
MzcgIG1mbjogMDAwMDRjMzcNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NDJdICAgZ2Zu
OiAwMDAwNGMzOCAgbWZuOiAwMDAwNGMzOA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo0
Ml0gICBnZm46IDAwMDA0YzM5ICBtZm46IDAwMDA0YzM5DQoNCihYRU4pIFsyMDEyLTA4LTMx
IDIxOjMyOjQyXSAgIGdmbjogMDAwMDRjM2EgIG1mbjogMDAwMDRjM2ENCg0KKFhFTikgWzIw
MTItMDgtMzEgMjE6MzI6NDJdICAgZ2ZuOiAwMDAwNGMzYiAgbWZuOiAwMDAwNGMzYg0KDQoo
WEVOKSBbMjAxMi0wOC0zMSAyMTozMjo0Ml0gICBnZm46IDAwMDA0YzNjICBtZm46IDAwMDA0
YzNjDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjQyXSAgIGdmbjogMDAwMDRjM2QgIG1m
bjogMDAwMDRjM2QNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NDJdICAgZ2ZuOiAwMDAw
NGMzZSAgbWZuOiAwMDAwNGMzZQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo0Ml0gICBn
Zm46IDAwMDA0YzNmICBtZm46IDAwMDA0YzNmDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMy
OjQyXSAgIGdmbjogMDAwMDRjNDAgIG1mbjogMDAwMDRjNDANCg0KKFhFTikgWzIwMTItMDgt
MzEgMjE6MzI6NDJdICAgZ2ZuOiAwMDAwNGM0MSAgbWZuOiAwMDAwNGM0MQ0KDQooWEVOKSBb
MjAxMi0wOC0zMSAyMTozMjo0Ml0gICBnZm46IDAwMDA0YzQyICBtZm46IDAwMDA0YzQyDQoN
CihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjQyXSAgIGdmbjogMDAwMDRjNDMgIG1mbjogMDAw
MDRjNDMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NDJdICAgZ2ZuOiAwMDAwNGM0NCAg
bWZuOiAwMDAwNGM0NA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo0Ml0gICBnZm46IDAw
MDA0YzQ1ICBtZm46IDAwMDA0YzQ1DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjQyXSAg
IGdmbjogMDAwMDRjNDYgIG1mbjogMDAwMDRjNDYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6
MzI6NDJdICAgZ2ZuOiAwMDAwNGM0NyAgbWZuOiAwMDAwNGM0Nw0KDQooWEVOKSBbMjAxMi0w
OC0zMSAyMTozMjo0Ml0gICBnZm46IDAwMDA0YzQ4ICBtZm46IDAwMDA0YzQ4DQoNCihYRU4p
IFsyMDEyLTA4LTMxIDIxOjMyOjQyXSAgIGdmbjogMDAwMDRjNDkgIG1mbjogMDAwMDRjNDkN
Cg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NDJdICAgZ2ZuOiAwMDAwNGM0YSAgbWZuOiAw
MDAwNGM0YQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo0Ml0gICBnZm46IDAwMDA0YzRi
ICBtZm46IDAwMDA0YzRiDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjQyXSAgIGdmbjog
MDAwMDRjNGMgIG1mbjogMDAwMDRjNGMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NDJd
ICAgZ2ZuOiAwMDAwNGM0ZCAgbWZuOiAwMDAwNGM0ZA0KDQooWEVOKSBbMjAxMi0wOC0zMSAy
MTozMjo0Ml0gICBnZm46IDAwMDA0YzRlICBtZm46IDAwMDA0YzRlDQoNCihYRU4pIFsyMDEy
LTA4LTMxIDIxOjMyOjQyXSAgIGdmbjogMDAwMDRjNGYgIG1mbjogMDAwMDRjNGYNCg0KKFhF
TikgWzIwMTItMDgtMzEgMjE6MzI6NDJdICAgZ2ZuOiAwMDAwNGM1MCAgbWZuOiAwMDAwNGM1
MA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo0Ml0gICBnZm46IDAwMDA0YzUxICBtZm46
IDAwMDA0YzUxDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjQyXSAgIGdmbjogMDAwMDRj
NTIgIG1mbjogMDAwMDRjNTINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NDJdICAgZ2Zu
OiAwMDAwNGM1MyAgbWZuOiAwMDAwNGM1Mw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo0
Ml0gICBnZm46IDAwMDA0YzU0ICBtZm46IDAwMDA0YzU0DQoNCihYRU4pIFsyMDEyLTA4LTMx
IDIxOjMyOjQyXSAgIGdmbjogMDAwMDRjNTUgIG1mbjogMDAwMDRjNTUNCg0KKFhFTikgWzIw
MTItMDgtMzEgMjE6MzI6NDJdICAgZ2ZuOiAwMDAwNGM1NiAgbWZuOiAwMDAwNGM1Ng0KDQoo
WEVOKSBbMjAxMi0wOC0zMSAyMTozMjo0Ml0gICBnZm46IDAwMDA0YzU3ICBtZm46IDAwMDA0
YzU3DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjQyXSAgIGdmbjogMDAwMDRjNTggIG1m
bjogMDAwMDRjNTgNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NDJdICAgZ2ZuOiAwMDAw
NGM1OSAgbWZuOiAwMDAwNGM1OQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo0Ml0gICBn
Zm46IDAwMDA0YzVhICBtZm46IDAwMDA0YzVhDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMy
OjQyXSAgIGdmbjogMDAwMDRjNWIgIG1mbjogMDAwMDRjNWINCg0KKFhFTikgWzIwMTItMDgt
MzEgMjE6MzI6NDJdICAgZ2ZuOiAwMDAwNGM1YyAgbWZuOiAwMDAwNGM1Yw0KDQooWEVOKSBb
MjAxMi0wOC0zMSAyMTozMjo0Ml0gICBnZm46IDAwMDA0YzVkICBtZm46IDAwMDA0YzVkDQoN
CihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjQyXSAgIGdmbjogMDAwMDRjNWUgIG1mbjogMDAw
MDRjNWUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NDJdICAgZ2ZuOiAwMDAwNGM1ZiAg
bWZuOiAwMDAwNGM1Zg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo0Ml0gICBnZm46IDAw
MDA0YzYwICBtZm46IDAwMDA0YzYwDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjQyXSAg
IGdmbjogMDAwMDRjNjEgIG1mbjogMDAwMDRjNjENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6
MzI6NDJdICAgZ2ZuOiAwMDAwNGM2MiAgbWZuOiAwMDAwNGM2Mg0KDQooWEVOKSBbMjAxMi0w
OC0zMSAyMTozMjo0Ml0gICBnZm46IDAwMDA0YzYzICBtZm46IDAwMDA0YzYzDQoNCihYRU4p
IFsyMDEyLTA4LTMxIDIxOjMyOjQyXSAgIGdmbjogMDAwMDRjNjQgIG1mbjogMDAwMDRjNjQN
Cg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NDJdICAgZ2ZuOiAwMDAwNGM2NSAgbWZuOiAw
MDAwNGM2NQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo0Ml0gICBnZm46IDAwMDA0YzY2
ICBtZm46IDAwMDA0YzY2DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjQyXSAgIGdmbjog
MDAwMDRjNjcgIG1mbjogMDAwMDRjNjcNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NDJd
ICAgZ2ZuOiAwMDAwNGM2OCAgbWZuOiAwMDAwNGM2OA0KDQooWEVOKSBbMjAxMi0wOC0zMSAy
MTozMjo0Ml0gICBnZm46IDAwMDA0YzY5ICBtZm46IDAwMDA0YzY5DQoNCihYRU4pIFsyMDEy
LTA4LTMxIDIxOjMyOjQyXSAgIGdmbjogMDAwMDRjNmEgIG1mbjogMDAwMDRjNmENCg0KKFhF
TikgWzIwMTItMDgtMzEgMjE6MzI6NDJdICAgZ2ZuOiAwMDAwNGM2YiAgbWZuOiAwMDAwNGM2
Yg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo0Ml0gICBnZm46IDAwMDA0YzZjICBtZm46
IDAwMDA0YzZjDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjQyXSAgIGdmbjogMDAwMDRj
NmQgIG1mbjogMDAwMDRjNmQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NDJdICAgZ2Zu
OiAwMDAwNGM2ZSAgbWZuOiAwMDAwNGM2ZQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo0
Ml0gICBnZm46IDAwMDA0YzZmICBtZm46IDAwMDA0YzZmDQoNCihYRU4pIFsyMDEyLTA4LTMx
IDIxOjMyOjQyXSAgIGdmbjogMDAwMDRjNzAgIG1mbjogMDAwMDRjNzANCg0KKFhFTikgWzIw
MTItMDgtMzEgMjE6MzI6NDJdICAgZ2ZuOiAwMDAwNGM3MSAgbWZuOiAwMDAwNGM3MQ0KDQoo
WEVOKSBbMjAxMi0wOC0zMSAyMTozMjo0M10gICBnZm46IDAwMDA0YzcyICBtZm46IDAwMDA0
YzcyDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjQzXSAgIGdmbjogMDAwMDRjNzMgIG1m
bjogMDAwMDRjNzMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NDNdICAgZ2ZuOiAwMDAw
NGM3NCAgbWZuOiAwMDAwNGM3NA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo0M10gICBn
Zm46IDAwMDA0Yzc1ICBtZm46IDAwMDA0Yzc1DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMy
OjQzXSAgIGdmbjogMDAwMDRjNzYgIG1mbjogMDAwMDRjNzYNCg0KKFhFTikgWzIwMTItMDgt
MzEgMjE6MzI6NDNdICAgZ2ZuOiAwMDAwNGM3NyAgbWZuOiAwMDAwNGM3Nw0KDQooWEVOKSBb
MjAxMi0wOC0zMSAyMTozMjo0M10gICBnZm46IDAwMDA0Yzc4ICBtZm46IDAwMDA0Yzc4DQoN
CihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjQzXSAgIGdmbjogMDAwMDRjNzkgIG1mbjogMDAw
MDRjNzkNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NDNdICAgZ2ZuOiAwMDAwNGM3YSAg
bWZuOiAwMDAwNGM3YQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo0M10gICBnZm46IDAw
MDA0YzdiICBtZm46IDAwMDA0YzdiDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjQzXSAg
IGdmbjogMDAwMDRjN2MgIG1mbjogMDAwMDRjN2MNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6
MzI6NDNdICAgZ2ZuOiAwMDAwNGM3ZCAgbWZuOiAwMDAwNGM3ZA0KDQooWEVOKSBbMjAxMi0w
OC0zMSAyMTozMjo0M10gICBnZm46IDAwMDA0YzdlICBtZm46IDAwMDA0YzdlDQoNCihYRU4p
IFsyMDEyLTA4LTMxIDIxOjMyOjQzXSAgIGdmbjogMDAwMDRjN2YgIG1mbjogMDAwMDRjN2YN
Cg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NDNdICAgZ2ZuOiAwMDAwNGM4MCAgbWZuOiAw
MDAwNGM4MA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo0M10gICBnZm46IDAwMDA0Yzgx
ICBtZm46IDAwMDA0YzgxDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjQzXSAgIGdmbjog
MDAwMDRjODIgIG1mbjogMDAwMDRjODINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NDNd
ICAgZ2ZuOiAwMDAwNGM4MyAgbWZuOiAwMDAwNGM4Mw0KDQooWEVOKSBbMjAxMi0wOC0zMSAy
MTozMjo0M10gICBnZm46IDAwMDA0Yzg0ICBtZm46IDAwMDA0Yzg0DQoNCihYRU4pIFsyMDEy
LTA4LTMxIDIxOjMyOjQzXSAgIGdmbjogMDAwMDRjODUgIG1mbjogMDAwMDRjODUNCg0KKFhF
TikgWzIwMTItMDgtMzEgMjE6MzI6NDNdICAgZ2ZuOiAwMDAwNGM4NiAgbWZuOiAwMDAwNGM4
Ng0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo0M10gICBnZm46IDAwMDA0Yzg3ICBtZm46
IDAwMDA0Yzg3DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjQzXSAgIGdmbjogMDAwMDRj
ODggIG1mbjogMDAwMDRjODgNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NDNdICAgZ2Zu
OiAwMDAwNGM4OSAgbWZuOiAwMDAwNGM4OQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo0
M10gICBnZm46IDAwMDA0YzhhICBtZm46IDAwMDA0YzhhDQoNCihYRU4pIFsyMDEyLTA4LTMx
IDIxOjMyOjQzXSAgIGdmbjogMDAwMDRjOGIgIG1mbjogMDAwMDRjOGINCg0KKFhFTikgWzIw
MTItMDgtMzEgMjE6MzI6NDNdICAgZ2ZuOiAwMDAwNGM4YyAgbWZuOiAwMDAwNGM4Yw0KDQoo
WEVOKSBbMjAxMi0wOC0zMSAyMTozMjo0M10gICBnZm46IDAwMDA0YzhkICBtZm46IDAwMDA0
YzhkDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjQzXSAgIGdmbjogMDAwMDRjOGUgIG1m
bjogMDAwMDRjOGUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NDNdICAgZ2ZuOiAwMDAw
NGM4ZiAgbWZuOiAwMDAwNGM4Zg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo0M10gICBn
Zm46IDAwMDA0YzkwICBtZm46IDAwMDA0YzkwDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMy
OjQzXSAgIGdmbjogMDAwMDRjOTEgIG1mbjogMDAwMDRjOTENCg0KKFhFTikgWzIwMTItMDgt
MzEgMjE6MzI6NDNdICAgZ2ZuOiAwMDAwNGM5MiAgbWZuOiAwMDAwNGM5Mg0KDQooWEVOKSBb
MjAxMi0wOC0zMSAyMTozMjo0M10gICBnZm46IDAwMDA0YzkzICBtZm46IDAwMDA0YzkzDQoN
CihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjQzXSAgIGdmbjogMDAwMDRjOTQgIG1mbjogMDAw
MDRjOTQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NDNdICAgZ2ZuOiAwMDAwNGM5NSAg
bWZuOiAwMDAwNGM5NQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo0M10gICBnZm46IDAw
MDA0Yzk2ICBtZm46IDAwMDA0Yzk2DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjQzXSAg
IGdmbjogMDAwMDRjOTcgIG1mbjogMDAwMDRjOTcNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6
MzI6NDNdICAgZ2ZuOiAwMDAwNGM5OCAgbWZuOiAwMDAwNGM5OA0KDQooWEVOKSBbMjAxMi0w
OC0zMSAyMTozMjo0M10gICBnZm46IDAwMDA0Yzk5ICBtZm46IDAwMDA0Yzk5DQoNCihYRU4p
IFsyMDEyLTA4LTMxIDIxOjMyOjQzXSAgIGdmbjogMDAwMDRjOWEgIG1mbjogMDAwMDRjOWEN
Cg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NDNdICAgZ2ZuOiAwMDAwNGM5YiAgbWZuOiAw
MDAwNGM5Yg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo0M10gICBnZm46IDAwMDA0Yzlj
ICBtZm46IDAwMDA0YzljDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjQzXSAgIGdmbjog
MDAwMDRjOWQgIG1mbjogMDAwMDRjOWQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NDNd
ICAgZ2ZuOiAwMDAwNGM5ZSAgbWZuOiAwMDAwNGM5ZQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAy
MTozMjo0M10gICBnZm46IDAwMDA0YzlmICBtZm46IDAwMDA0YzlmDQoNCihYRU4pIFsyMDEy
LTA4LTMxIDIxOjMyOjQzXSAgIGdmbjogMDAwMDRjYTAgIG1mbjogMDAwMDRjYTANCg0KKFhF
TikgWzIwMTItMDgtMzEgMjE6MzI6NDNdICAgZ2ZuOiAwMDAwNGNhMSAgbWZuOiAwMDAwNGNh
MQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo0M10gICBnZm46IDAwMDA0Y2EyICBtZm46
IDAwMDA0Y2EyDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjQzXSAgIGdmbjogMDAwMDRj
YTMgIG1mbjogMDAwMDRjYTMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NDNdICAgZ2Zu
OiAwMDAwNGNhNCAgbWZuOiAwMDAwNGNhNA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo0
M10gICBnZm46IDAwMDA0Y2E1ICBtZm46IDAwMDA0Y2E1DQoNCihYRU4pIFsyMDEyLTA4LTMx
IDIxOjMyOjQzXSAgIGdmbjogMDAwMDRjYTYgIG1mbjogMDAwMDRjYTYNCg0KKFhFTikgWzIw
MTItMDgtMzEgMjE6MzI6NDNdICAgZ2ZuOiAwMDAwNGNhNyAgbWZuOiAwMDAwNGNhNw0KDQoo
WEVOKSBbMjAxMi0wOC0zMSAyMTozMjo0M10gICBnZm46IDAwMDA0Y2E4ICBtZm46IDAwMDA0
Y2E4DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjQzXSAgIGdmbjogMDAwMDRjYTkgIG1m
bjogMDAwMDRjYTkNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NDNdICAgZ2ZuOiAwMDAw
NGNhYSAgbWZuOiAwMDAwNGNhYQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo0M10gICBn
Zm46IDAwMDA0Y2FiICBtZm46IDAwMDA0Y2FiDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMy
OjQzXSAgIGdmbjogMDAwMDRjYWMgIG1mbjogMDAwMDRjYWMNCg0KKFhFTikgWzIwMTItMDgt
MzEgMjE6MzI6NDNdICAgZ2ZuOiAwMDAwNGNhZCAgbWZuOiAwMDAwNGNhZA0KDQooWEVOKSBb
MjAxMi0wOC0zMSAyMTozMjo0M10gICBnZm46IDAwMDA0Y2FlICBtZm46IDAwMDA0Y2FlDQoN
CihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjQzXSAgIGdmbjogMDAwMDRjYWYgIG1mbjogMDAw
MDRjYWYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NDNdICAgZ2ZuOiAwMDAwNGNiMCAg
bWZuOiAwMDAwNGNiMA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo0M10gICBnZm46IDAw
MDA0Y2IxICBtZm46IDAwMDA0Y2IxDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjQ0XSAg
IGdmbjogMDAwMDRjYjIgIG1mbjogMDAwMDRjYjINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6
MzI6NDRdICAgZ2ZuOiAwMDAwNGNiMyAgbWZuOiAwMDAwNGNiMw0KDQooWEVOKSBbMjAxMi0w
OC0zMSAyMTozMjo0NF0gICBnZm46IDAwMDA0Y2I0ICBtZm46IDAwMDA0Y2I0DQoNCihYRU4p
IFsyMDEyLTA4LTMxIDIxOjMyOjQ0XSAgIGdmbjogMDAwMDRjYjUgIG1mbjogMDAwMDRjYjUN
Cg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NDRdICAgZ2ZuOiAwMDAwNGNiNiAgbWZuOiAw
MDAwNGNiNg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo0NF0gICBnZm46IDAwMDA0Y2I3
ICBtZm46IDAwMDA0Y2I3DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjQ0XSAgIGdmbjog
MDAwMDRjYjggIG1mbjogMDAwMDRjYjgNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NDRd
ICAgZ2ZuOiAwMDAwNGNiOSAgbWZuOiAwMDAwNGNiOQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAy
MTozMjo0NF0gICBnZm46IDAwMDA0Y2JhICBtZm46IDAwMDA0Y2JhDQoNCihYRU4pIFsyMDEy
LTA4LTMxIDIxOjMyOjQ0XSAgIGdmbjogMDAwMDRjYmIgIG1mbjogMDAwMDRjYmINCg0KKFhF
TikgWzIwMTItMDgtMzEgMjE6MzI6NDRdICAgZ2ZuOiAwMDAwNGNiYyAgbWZuOiAwMDAwNGNi
Yw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo0NF0gICBnZm46IDAwMDA0Y2JkICBtZm46
IDAwMDA0Y2JkDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjQ0XSAgIGdmbjogMDAwMDRj
YmUgIG1mbjogMDAwMDRjYmUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NDRdICAgZ2Zu
OiAwMDAwNGNiZiAgbWZuOiAwMDAwNGNiZg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo0
NF0gICBnZm46IDAwMDA0Y2MwICBtZm46IDAwMDA0Y2MwDQoNCihYRU4pIFsyMDEyLTA4LTMx
IDIxOjMyOjQ0XSAgIGdmbjogMDAwMDRjYzEgIG1mbjogMDAwMDRjYzENCg0KKFhFTikgWzIw
MTItMDgtMzEgMjE6MzI6NDRdICAgZ2ZuOiAwMDAwNGNjMiAgbWZuOiAwMDAwNGNjMg0KDQoo
WEVOKSBbMjAxMi0wOC0zMSAyMTozMjo0NF0gICBnZm46IDAwMDA0Y2MzICBtZm46IDAwMDA0
Y2MzDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjQ0XSAgIGdmbjogMDAwMDRjYzQgIG1m
bjogMDAwMDRjYzQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NDRdICAgZ2ZuOiAwMDAw
NGNjNSAgbWZuOiAwMDAwNGNjNQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo0NF0gICBn
Zm46IDAwMDA0Y2M2ICBtZm46IDAwMDA0Y2M2DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMy
OjQ0XSAgIGdmbjogMDAwMDRjYzcgIG1mbjogMDAwMDRjYzcNCg0KKFhFTikgWzIwMTItMDgt
MzEgMjE6MzI6NDRdICAgZ2ZuOiAwMDAwNGNjOCAgbWZuOiAwMDAwNGNjOA0KDQooWEVOKSBb
MjAxMi0wOC0zMSAyMTozMjo0NF0gICBnZm46IDAwMDA0Y2M5ICBtZm46IDAwMDA0Y2M5DQoN
CihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjQ0XSAgIGdmbjogMDAwMDRjY2EgIG1mbjogMDAw
MDRjY2ENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NDRdICAgZ2ZuOiAwMDAwNGNjYiAg
bWZuOiAwMDAwNGNjYg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo0NF0gICBnZm46IDAw
MDA0Y2NjICBtZm46IDAwMDA0Y2NjDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjQ0XSAg
IGdmbjogMDAwMDRjY2QgIG1mbjogMDAwMDRjY2QNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6
MzI6NDRdICAgZ2ZuOiAwMDAwNGNjZSAgbWZuOiAwMDAwNGNjZQ0KDQooWEVOKSBbMjAxMi0w
OC0zMSAyMTozMjo0NF0gICBnZm46IDAwMDA0Y2NmICBtZm46IDAwMDA0Y2NmDQoNCihYRU4p
IFsyMDEyLTA4LTMxIDIxOjMyOjQ0XSAgIGdmbjogMDAwMDRjZDAgIG1mbjogMDAwMDRjZDAN
Cg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NDRdICAgZ2ZuOiAwMDAwNGNkMSAgbWZuOiAw
MDAwNGNkMQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo0NF0gICBnZm46IDAwMDA0Y2Qy
ICBtZm46IDAwMDA0Y2QyDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjQ0XSAgIGdmbjog
MDAwMDRjZDMgIG1mbjogMDAwMDRjZDMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NDRd
ICAgZ2ZuOiAwMDAwNGNkNCAgbWZuOiAwMDAwNGNkNA0KDQooWEVOKSBbMjAxMi0wOC0zMSAy
MTozMjo0NF0gICBnZm46IDAwMDA0Y2Q1ICBtZm46IDAwMDA0Y2Q1DQoNCihYRU4pIFsyMDEy
LTA4LTMxIDIxOjMyOjQ0XSAgIGdmbjogMDAwMDRjZDYgIG1mbjogMDAwMDRjZDYNCg0KKFhF
TikgWzIwMTItMDgtMzEgMjE6MzI6NDRdICAgZ2ZuOiAwMDAwNGNkNyAgbWZuOiAwMDAwNGNk
Nw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo0NF0gICBnZm46IDAwMDA0Y2Q4ICBtZm46
IDAwMDA0Y2Q4DQoNClsgIDQzMC41ODQ4NzFdIGEoWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo0
NF0gICBnZm46IDAwMDA0Y2Q5ICBtZm46IDAwMDA0Y2Q5DQoNCnRhMS4wMDogcWMgdGltZW91
dCAoY21kIDB4ZWMpDQoNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NDRdICAgZ2ZuOiAw
MDAwNGNkYSAgbWZuOiAwMDAwNGNkYQ0KDQpbICA0MzAuNjQyNzEyXSBhKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzI6NDRdICAgZ2ZuOiAwMDAwNGNkYiAgbWZuOiAwMDAwNGNkYg0KDQp0YTEu
MDA6IGZhaWxlZCB0KFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NDRdICAgZ2ZuOiAwMDAwNGNk
YyAgbWZuOiAwMDAwNGNkYw0KDQpvIElERU5USUZZIChJL08gKFhFTikgWzIwMTItMDgtMzEg
MjE6MzI6NDRdICAgZ2ZuOiAwMDAwNGNkZCAgbWZuOiAwMDAwNGNkZA0KDQplcnJvciwgZXJy
X21hc2s9KFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NDRdICAgZ2ZuOiAwMDAwNGNkZSAgbWZu
OiAwMDAwNGNkZQ0KDQoweDQpDQoNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NDRdICAg
Z2ZuOiAwMDAwNGNkZiAgbWZuOiAwMDAwNGNkZg0KDQpbICA0MzAuNzM4MzA4XSBhKFhFTikg
WzIwMTItMDgtMzEgMjE6MzI6NDRdICAgZ2ZuOiAwMDAwNGNlMCAgbWZuOiAwMDAwNGNlMA0K
DQp0YTEuMDA6IHJldmFsaWRhKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NDRdICAgZ2ZuOiAw
MDAwNGNlMSAgbWZuOiAwMDAwNGNlMQ0KDQp0aW9uIGZhaWxlZCAoZXJybm89LTUpDQoNCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NDRdICAgZ2ZuOiAwMDAwNGNlMiAgbWZuOiAwMDAw
NGNlMg0KDQpbICA0MzAuODAwNjc4XSBhKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NDRdICAg
Z2ZuOiAwMDAwNGNlMyAgbWZuOiAwMDAwNGNlMw0KDQp0YTE6IGxpbWl0aW5nIFNBKFhFTikg
WzIwMTItMDgtMzEgMjE6MzI6NDRdICAgZ2ZuOiAwMDAwNGNlNCAgbWZuOiAwMDAwNGNlNA0K
DQpUQSBsaW5rIHNwZWVkIHRvKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NDRdICAgZ2ZuOiAw
MDAwNGNlNSAgbWZuOiAwMDAwNGNlNQ0KDQogMS41IEdicHMNCg0KDQooWEVOKSBbMjAxMi0w
OC0zMSAyMTozMjo0NF0gICBnZm46IDAwMDA0Y2U2ICBtZm46IDAwMDA0Y2U2DQoNCihYRU4p
IFsyMDEyLTA4LTMxIDIxOjMyOjQ0XSAgIGdmbjogMDAwMDRjZTcgIG1mbjogMDAwMDRjZTcN
Cg0KWyAgNDMwLjg3OTcyMV0gYShYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjQ0XSAgIGdmbjog
MDAwMDRjZTggIG1mbjogMDAwMDRjZTgNCg0KdGExOiBoYXJkIHJlc2V0dChYRU4pIFsyMDEy
LTA4LTMxIDIxOjMyOjQ0XSAgIGdmbjogMDAwMDRjZTkgIG1mbjogMDAwMDRjZTkNCg0KaW5n
IGxpbmsNCg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo0NF0gICBnZm46IDAwMDA0Y2Vh
ICBtZm46IDAwMDA0Y2VhDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjQ0XSAgIGdmbjog
MDAwMDRjZWIgIG1mbjogMDAwMDRjZWINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NDRd
ICAgZ2ZuOiAwMDAwNGNlYyAgbWZuOiAwMDAwNGNlYw0KDQooWEVOKSBbMjAxMi0wOC0zMSAy
MTozMjo0NV0gICBnZm46IDAwMDA0Y2VkICBtZm46IDAwMDA0Y2VkDQoNCihYRU4pIFsyMDEy
LTA4LTMxIDIxOjMyOjQ1XSAgIGdmbjogMDAwMDRjZWUgIG1mbjogMDAwMDRjZWUNCg0KKFhF
TikgWzIwMTItMDgtMzEgMjE6MzI6NDVdICAgZ2ZuOiAwMDAwNGNlZiAgbWZuOiAwMDAwNGNl
Zg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo0NV0gICBnZm46IDAwMDA0Y2YwICBtZm46
IDAwMDA0Y2YwDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjQ1XSAgIGdmbjogMDAwMDRj
ZjEgIG1mbjogMDAwMDRjZjENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NDVdICAgZ2Zu
OiAwMDAwNGNmMiAgbWZuOiAwMDAwNGNmMg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo0
NV0gICBnZm46IDAwMDA0Y2YzICBtZm46IDAwMDA0Y2YzDQoNCihYRU4pIFsyMDEyLTA4LTMx
IDIxOjMyOjQ1XSAgIGdmbjogMDAwMDRjZjQgIG1mbjogMDAwMDRjZjQNCg0KKFhFTikgWzIw
MTItMDgtMzEgMjE6MzI6NDVdICAgZ2ZuOiAwMDAwNGNmNSAgbWZuOiAwMDAwNGNmNQ0KDQoo
WEVOKSBbMjAxMi0wOC0zMSAyMTozMjo0NV0gICBnZm46IDAwMDA0Y2Y2ICBtZm46IDAwMDA0
Y2Y2DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjQ1XSAgIGdmbjogMDAwMDRjZjcgIG1m
bjogMDAwMDRjZjcNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NDVdICAgZ2ZuOiAwMDAw
NGNmOCAgbWZuOiAwMDAwNGNmOA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo0NV0gICBn
Zm46IDAwMDA0Y2Y5ICBtZm46IDAwMDA0Y2Y5DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMy
OjQ1XSAgIGdmbjogMDAwMDRjZmEgIG1mbjogMDAwMDRjZmENCg0KKFhFTikgWzIwMTItMDgt
MzEgMjE6MzI6NDVdICAgZ2ZuOiAwMDAwNGNmYiAgbWZuOiAwMDAwNGNmYg0KDQooWEVOKSBb
MjAxMi0wOC0zMSAyMTozMjo0NV0gICBnZm46IDAwMDA0Y2ZjICBtZm46IDAwMDA0Y2ZjDQoN
CihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjQ1XSAgIGdmbjogMDAwMDRjZmQgIG1mbjogMDAw
MDRjZmQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NDVdICAgZ2ZuOiAwMDAwNGNmZSAg
bWZuOiAwMDAwNGNmZQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo0NV0gICBnZm46IDAw
MDA0Y2ZmICBtZm46IDAwMDA0Y2ZmDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjQ1XSAg
IGdmbjogMDAwMDRkMDAgIG1mbjogMDAwMDRkMDANCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6
MzI6NDVdICAgZ2ZuOiAwMDAwNGQwMSAgbWZuOiAwMDAwNGQwMQ0KDQooWEVOKSBbMjAxMi0w
OC0zMSAyMTozMjo0NV0gICBnZm46IDAwMDA0ZDAyICBtZm46IDAwMDA0ZDAyDQoNCihYRU4p
IFsyMDEyLTA4LTMxIDIxOjMyOjQ1XSAgIGdmbjogMDAwMDRkMDMgIG1mbjogMDAwMDRkMDMN
Cg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NDVdICAgZ2ZuOiAwMDAwNGQwNCAgbWZuOiAw
MDAwNGQwNA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo0NV0gICBnZm46IDAwMDA0ZDA1
ICBtZm46IDAwMDA0ZDA1DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjQ1XSAgIGdmbjog
MDAwMDRkMDYgIG1mbjogMDAwMDRkMDYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NDVd
ICAgZ2ZuOiAwMDAwNGQwNyAgbWZuOiAwMDAwNGQwNw0KDQooWEVOKSBbMjAxMi0wOC0zMSAy
MTozMjo0NV0gICBnZm46IDAwMDA0ZDA4ICBtZm46IDAwMDA0ZDA4DQoNCihYRU4pIFsyMDEy
LTA4LTMxIDIxOjMyOjQ1XSAgIGdmbjogMDAwMDRkMDkgIG1mbjogMDAwMDRkMDkNCg0KKFhF
TikgWzIwMTItMDgtMzEgMjE6MzI6NDVdICAgZ2ZuOiAwMDAwNGQwYSAgbWZuOiAwMDAwNGQw
YQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo0NV0gICBnZm46IDAwMDA0ZDBiICBtZm46
IDAwMDA0ZDBiDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjQ1XSAgIGdmbjogMDAwMDRk
MGMgIG1mbjogMDAwMDRkMGMNCg0KWyAgNDMxLjQ2NjQxM10gYShYRU4pIFsyMDEyLTA4LTMx
IDIxOjMyOjQ1XSAgIGdmbjogMDAwMDRkMGQgIG1mbjogMDAwMDRkMGQNCg0KdGExOiBTQVRB
IGxpbmsgdShYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjQ1XSAgIGdmbjogMDAwMDRkMGUgIG1m
bjogMDAwMDRkMGUNCg0KcCAxLjUgR2JwcyAoU1N0YShYRU4pIFsyMDEyLTA4LTMxIDIxOjMy
OjQ1XSAgIGdmbjogMDAwMDRkMGYgIG1mbjogMDAwMDRkMGYNCg0KdHVzIDExMyBTQ29udHJv
bCAzMTApDQoNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NDVdICAgZ2ZuOiAwMDAwNGQx
MCAgbWZuOiAwMDAwNGQxMA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo0NV0gICBnZm46
IDAwMDA0ZDExICBtZm46IDAwMDA0ZDExDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjQ1
XSAgIGdmbjogMDAwMDRkMTIgIG1mbjogMDAwMDRkMTINCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzI6NDVdICAgZ2ZuOiAwMDAwNGQxMyAgbWZuOiAwMDAwNGQxMw0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMjo0NV0gICBnZm46IDAwMDA0ZDE0ICBtZm46IDAwMDA0ZDE0DQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMyOjQ1XSAgIGdmbjogMDAwMDRkMTUgIG1mbjogMDAwMDRk
MTUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NDVdICAgZ2ZuOiAwMDAwNGQxNiAgbWZu
OiAwMDAwNGQxNg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo0NV0gICBnZm46IDAwMDA0
ZDE3ICBtZm46IDAwMDA0ZDE3DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjQ1XSAgIGdm
bjogMDAwMDRkMTggIG1mbjogMDAwMDRkMTgNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6
NDVdICAgZ2ZuOiAwMDAwNGQxOSAgbWZuOiAwMDAwNGQxOQ0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMjo0NV0gICBnZm46IDAwMDA0ZDFhICBtZm46IDAwMDA0ZDFhDQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMyOjQ1XSAgIGdmbjogMDAwMDRkMWIgIG1mbjogMDAwMDRkMWINCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NDVdICAgZ2ZuOiAwMDAwNGQxYyAgbWZuOiAwMDAw
NGQxYw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo0NV0gICBnZm46IDAwMDA0ZDFkICBt
Zm46IDAwMDA0ZDFkDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjQ1XSAgIGdmbjogMDAw
MDRkMWUgIG1mbjogMDAwMDRkMWUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NDVdICAg
Z2ZuOiAwMDAwNGQxZiAgbWZuOiAwMDAwNGQxZg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
Mjo0NV0gICBnZm46IDAwMDA0ZDIwICBtZm46IDAwMDA0ZDIwDQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMyOjQ1XSAgIGdmbjogMDAwMDRkMjEgIG1mbjogMDAwMDRkMjENCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzI6NDVdICAgZ2ZuOiAwMDAwNGQyMiAgbWZuOiAwMDAwNGQyMg0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo0NV0gICBnZm46IDAwMDA0ZDIzICBtZm46IDAw
MDA0ZDIzDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjQ1XSAgIGdmbjogMDAwMDRkMjQg
IG1mbjogMDAwMDRkMjQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NDVdICAgZ2ZuOiAw
MDAwNGQyNSAgbWZuOiAwMDAwNGQyNQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo0NV0g
ICBnZm46IDAwMDA0ZDI2ICBtZm46IDAwMDA0ZDI2DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMyOjQ1XSAgIGdmbjogMDAwMDRkMjcgIG1mbjogMDAwMDRkMjcNCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzI6NDVdICAgZ2ZuOiAwMDAwNGQyOCAgbWZuOiAwMDAwNGQyOA0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMjo0NV0gICBnZm46IDAwMDA0ZDI5ICBtZm46IDAwMDA0ZDI5
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjQ1XSAgIGdmbjogMDAwMDRkMmEgIG1mbjog
MDAwMDRkMmENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NDVdICAgZ2ZuOiAwMDAwNGQy
YiAgbWZuOiAwMDAwNGQyYg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo0Nl0gICBnZm46
IDAwMDA0ZDJjICBtZm46IDAwMDA0ZDJjDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjQ2
XSAgIGdmbjogMDAwMDRkMmQgIG1mbjogMDAwMDRkMmQNCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzI6NDZdICAgZ2ZuOiAwMDAwNGQyZSAgbWZuOiAwMDAwNGQyZQ0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMjo0Nl0gICBnZm46IDAwMDA0ZDJmICBtZm46IDAwMDA0ZDJmDQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMyOjQ2XSAgIGdmbjogMDAwMDRkMzAgIG1mbjogMDAwMDRk
MzANCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NDZdICAgZ2ZuOiAwMDAwNGQzMSAgbWZu
OiAwMDAwNGQzMQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo0Nl0gICBnZm46IDAwMDA0
ZDMyICBtZm46IDAwMDA0ZDMyDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjQ2XSAgIGdm
bjogMDAwMDRkMzMgIG1mbjogMDAwMDRkMzMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6
NDZdICAgZ2ZuOiAwMDAwNGQzNCAgbWZuOiAwMDAwNGQzNA0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMjo0Nl0gICBnZm46IDAwMDA0ZDM1ICBtZm46IDAwMDA0ZDM1DQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMyOjQ2XSAgIGdmbjogMDAwMDRkMzYgIG1mbjogMDAwMDRkMzYNCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NDZdICAgZ2ZuOiAwMDAwNGQzNyAgbWZuOiAwMDAw
NGQzNw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo0Nl0gICBnZm46IDAwMDA0ZDM4ICBt
Zm46IDAwMDA0ZDM4DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjQ2XSAgIGdmbjogMDAw
MDRkMzkgIG1mbjogMDAwMDRkMzkNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NDZdICAg
Z2ZuOiAwMDAwNGQzYSAgbWZuOiAwMDAwNGQzYQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
Mjo0Nl0gICBnZm46IDAwMDA0ZDNiICBtZm46IDAwMDA0ZDNiDQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMyOjQ2XSAgIGdmbjogMDAwMDRkM2MgIG1mbjogMDAwMDRkM2MNCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzI6NDZdICAgZ2ZuOiAwMDAwNGQzZCAgbWZuOiAwMDAwNGQzZA0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo0Nl0gICBnZm46IDAwMDA0ZDNlICBtZm46IDAw
MDA0ZDNlDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjQ2XSAgIGdmbjogMDAwMDRkM2Yg
IG1mbjogMDAwMDRkM2YNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NDZdICAgZ2ZuOiAw
MDAwNGQ0MCAgbWZuOiAwMDAwNGQ0MA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo0Nl0g
ICBnZm46IDAwMDA0ZDQxICBtZm46IDAwMDA0ZDQxDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMyOjQ2XSAgIGdmbjogMDAwMDRkNDIgIG1mbjogMDAwMDRkNDINCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzI6NDZdICAgZ2ZuOiAwMDAwNGQ0MyAgbWZuOiAwMDAwNGQ0Mw0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMjo0Nl0gICBnZm46IDAwMDA0ZDQ0ICBtZm46IDAwMDA0ZDQ0
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjQ2XSAgIGdmbjogMDAwMDRkNDUgIG1mbjog
MDAwMDRkNDUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NDZdICAgZ2ZuOiAwMDAwNGQ0
NiAgbWZuOiAwMDAwNGQ0Ng0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo0Nl0gICBnZm46
IDAwMDA0ZDQ3ICBtZm46IDAwMDA0ZDQ3DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjQ2
XSAgIGdmbjogMDAwMDRkNDggIG1mbjogMDAwMDRkNDgNCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzI6NDZdICAgZ2ZuOiAwMDAwNGQ0OSAgbWZuOiAwMDAwNGQ0OQ0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMjo0Nl0gICBnZm46IDAwMDA0ZDRhICBtZm46IDAwMDA0ZDRhDQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMyOjQ2XSAgIGdmbjogMDAwMDRkNGIgIG1mbjogMDAwMDRk
NGINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NDZdICAgZ2ZuOiAwMDAwNGQ0YyAgbWZu
OiAwMDAwNGQ0Yw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo0Nl0gICBnZm46IDAwMDA0
ZDRkICBtZm46IDAwMDA0ZDRkDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjQ2XSAgIGdm
bjogMDAwMDRkNGUgIG1mbjogMDAwMDRkNGUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6
NDZdICAgZ2ZuOiAwMDAwNGQ0ZiAgbWZuOiAwMDAwNGQ0Zg0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMjo0Nl0gICBnZm46IDAwMDA0ZDUwICBtZm46IDAwMDA0ZDUwDQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMyOjQ2XSAgIGdmbjogMDAwMDRkNTEgIG1mbjogMDAwMDRkNTENCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NDZdICAgZ2ZuOiAwMDAwNGQ1MiAgbWZuOiAwMDAw
NGQ1Mg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo0Nl0gICBnZm46IDAwMDA0ZDUzICBt
Zm46IDAwMDA0ZDUzDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjQ2XSAgIGdmbjogMDAw
MDRkNTQgIG1mbjogMDAwMDRkNTQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NDZdICAg
Z2ZuOiAwMDAwNGQ1NSAgbWZuOiAwMDAwNGQ1NQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
Mjo0Nl0gICBnZm46IDAwMDA0ZDU2ICBtZm46IDAwMDA0ZDU2DQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMyOjQ2XSAgIGdmbjogMDAwMDRkNTcgIG1mbjogMDAwMDRkNTcNCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzI6NDZdICAgZ2ZuOiAwMDAwNGQ1OCAgbWZuOiAwMDAwNGQ1OA0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo0Nl0gICBnZm46IDAwMDA0ZDU5ICBtZm46IDAw
MDA0ZDU5DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjQ2XSAgIGdmbjogMDAwMDRkNWEg
IG1mbjogMDAwMDRkNWENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NDZdICAgZ2ZuOiAw
MDAwNGQ1YiAgbWZuOiAwMDAwNGQ1Yg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo0Nl0g
ICBnZm46IDAwMDA0ZDVjICBtZm46IDAwMDA0ZDVjDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMyOjQ2XSAgIGdmbjogMDAwMDRkNWQgIG1mbjogMDAwMDRkNWQNCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzI6NDZdICAgZ2ZuOiAwMDAwNGQ1ZSAgbWZuOiAwMDAwNGQ1ZQ0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMjo0Nl0gICBnZm46IDAwMDA0ZDVmICBtZm46IDAwMDA0ZDVm
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjQ2XSAgIGdmbjogMDAwMDRkNjAgIG1mbjog
MDAwMDRkNjANCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NDZdICAgZ2ZuOiAwMDAwNGQ2
MSAgbWZuOiAwMDAwNGQ2MQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo0Nl0gICBnZm46
IDAwMDA0ZDYyICBtZm46IDAwMDA0ZDYyDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjQ2
XSAgIGdmbjogMDAwMDRkNjMgIG1mbjogMDAwMDRkNjMNCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzI6NDZdICAgZ2ZuOiAwMDAwNGQ2NCAgbWZuOiAwMDAwNGQ2NA0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMjo0Nl0gICBnZm46IDAwMDA0ZDY1ICBtZm46IDAwMDA0ZDY1DQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMyOjQ2XSAgIGdmbjogMDAwMDRkNjYgIG1mbjogMDAwMDRk
NjYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NDZdICAgZ2ZuOiAwMDAwNGQ2NyAgbWZu
OiAwMDAwNGQ2Nw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo0Nl0gICBnZm46IDAwMDA0
ZDY4ICBtZm46IDAwMDA0ZDY4DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjQ2XSAgIGdm
bjogMDAwMDRkNjkgIG1mbjogMDAwMDRkNjkNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6
NDZdICAgZ2ZuOiAwMDAwNGQ2YSAgbWZuOiAwMDAwNGQ2YQ0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMjo0Nl0gICBnZm46IDAwMDA0ZDZiICBtZm46IDAwMDA0ZDZiDQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMyOjQ3XSAgIGdmbjogMDAwMDRkNmMgIG1mbjogMDAwMDRkNmMNCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NDddICAgZ2ZuOiAwMDAwNGQ2ZCAgbWZuOiAwMDAw
NGQ2ZA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo0N10gICBnZm46IDAwMDA0ZDZlICBt
Zm46IDAwMDA0ZDZlDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjQ3XSAgIGdmbjogMDAw
MDRkNmYgIG1mbjogMDAwMDRkNmYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NDddICAg
Z2ZuOiAwMDAwNGQ3MCAgbWZuOiAwMDAwNGQ3MA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
Mjo0N10gICBnZm46IDAwMDA0ZDcxICBtZm46IDAwMDA0ZDcxDQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMyOjQ3XSAgIGdmbjogMDAwMDRkNzIgIG1mbjogMDAwMDRkNzINCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzI6NDddICAgZ2ZuOiAwMDAwNGQ3MyAgbWZuOiAwMDAwNGQ3Mw0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo0N10gICBnZm46IDAwMDA0ZDc0ICBtZm46IDAw
MDA0ZDc0DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjQ3XSAgIGdmbjogMDAwMDRkNzUg
IG1mbjogMDAwMDRkNzUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NDddICAgZ2ZuOiAw
MDAwNGQ3NiAgbWZuOiAwMDAwNGQ3Ng0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo0N10g
ICBnZm46IDAwMDA0ZDc3ICBtZm46IDAwMDA0ZDc3DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMyOjQ3XSAgIGdmbjogMDAwMDRkNzggIG1mbjogMDAwMDRkNzgNCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzI6NDddICAgZ2ZuOiAwMDAwNGQ3OSAgbWZuOiAwMDAwNGQ3OQ0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMjo0N10gICBnZm46IDAwMDA0ZDdhICBtZm46IDAwMDA0ZDdh
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjQ3XSAgIGdmbjogMDAwMDRkN2IgIG1mbjog
MDAwMDRkN2INCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NDddICAgZ2ZuOiAwMDAwNGQ3
YyAgbWZuOiAwMDAwNGQ3Yw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo0N10gICBnZm46
IDAwMDA0ZDdkICBtZm46IDAwMDA0ZDdkDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjQ3
XSAgIGdmbjogMDAwMDRkN2UgIG1mbjogMDAwMDRkN2UNCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzI6NDddICAgZ2ZuOiAwMDAwNGQ3ZiAgbWZuOiAwMDAwNGQ3Zg0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMjo0N10gICBnZm46IDAwMDA0ZDgwICBtZm46IDAwMDA0ZDgwDQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMyOjQ3XSAgIGdmbjogMDAwMDRkODEgIG1mbjogMDAwMDRk
ODENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NDddICAgZ2ZuOiAwMDAwNGQ4MiAgbWZu
OiAwMDAwNGQ4Mg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo0N10gICBnZm46IDAwMDA0
ZDgzICBtZm46IDAwMDA0ZDgzDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjQ3XSAgIGdm
bjogMDAwMDRkODQgIG1mbjogMDAwMDRkODQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6
NDddICAgZ2ZuOiAwMDAwNGQ4NSAgbWZuOiAwMDAwNGQ4NQ0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMjo0N10gICBnZm46IDAwMDA0ZDg2ICBtZm46IDAwMDA0ZDg2DQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMyOjQ3XSAgIGdmbjogMDAwMDRkODcgIG1mbjogMDAwMDRkODcNCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NDddICAgZ2ZuOiAwMDAwNGQ4OCAgbWZuOiAwMDAw
NGQ4OA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo0N10gICBnZm46IDAwMDA0ZDg5ICBt
Zm46IDAwMDA0ZDg5DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjQ3XSAgIGdmbjogMDAw
MDRkOGEgIG1mbjogMDAwMDRkOGENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NDddICAg
Z2ZuOiAwMDAwNGQ4YiAgbWZuOiAwMDAwNGQ4Yg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
Mjo0N10gICBnZm46IDAwMDA0ZDhjICBtZm46IDAwMDA0ZDhjDQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMyOjQ3XSAgIGdmbjogMDAwMDRkOGQgIG1mbjogMDAwMDRkOGQNCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzI6NDddICAgZ2ZuOiAwMDAwNGQ4ZSAgbWZuOiAwMDAwNGQ4ZQ0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo0N10gICBnZm46IDAwMDA0ZDhmICBtZm46IDAw
MDA0ZDhmDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjQ3XSAgIGdmbjogMDAwMDRkOTAg
IG1mbjogMDAwMDRkOTANCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NDddICAgZ2ZuOiAw
MDAwNGQ5MSAgbWZuOiAwMDAwNGQ5MQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo0N10g
ICBnZm46IDAwMDA0ZDkyICBtZm46IDAwMDA0ZDkyDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMyOjQ3XSAgIGdmbjogMDAwMDRkOTMgIG1mbjogMDAwMDRkOTMNCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzI6NDddICAgZ2ZuOiAwMDAwNGQ5NCAgbWZuOiAwMDAwNGQ5NA0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMjo0N10gICBnZm46IDAwMDA0ZDk1ICBtZm46IDAwMDA0ZDk1
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjQ3XSAgIGdmbjogMDAwMDRkOTYgIG1mbjog
MDAwMDRkOTYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NDddICAgZ2ZuOiAwMDAwNGQ5
NyAgbWZuOiAwMDAwNGQ5Nw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo0N10gICBnZm46
IDAwMDA0ZDk4ICBtZm46IDAwMDA0ZDk4DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjQ3
XSAgIGdmbjogMDAwMDRkOTkgIG1mbjogMDAwMDRkOTkNCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzI6NDddICAgZ2ZuOiAwMDAwNGQ5YSAgbWZuOiAwMDAwNGQ5YQ0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMjo0N10gICBnZm46IDAwMDA0ZDliICBtZm46IDAwMDA0ZDliDQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMyOjQ3XSAgIGdmbjogMDAwMDRkOWMgIG1mbjogMDAwMDRk
OWMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NDddICAgZ2ZuOiAwMDAwNGQ5ZCAgbWZu
OiAwMDAwNGQ5ZA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo0N10gICBnZm46IDAwMDA0
ZDllICBtZm46IDAwMDA0ZDllDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjQ3XSAgIGdm
bjogMDAwMDRkOWYgIG1mbjogMDAwMDRkOWYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6
NDddICAgZ2ZuOiAwMDAwNGRhMCAgbWZuOiAwMDAwNGRhMA0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMjo0N10gICBnZm46IDAwMDA0ZGExICBtZm46IDAwMDA0ZGExDQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMyOjQ3XSAgIGdmbjogMDAwMDRkYTIgIG1mbjogMDAwMDRkYTINCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NDddICAgZ2ZuOiAwMDAwNGRhMyAgbWZuOiAwMDAw
NGRhMw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo0N10gICBnZm46IDAwMDA0ZGE0ICBt
Zm46IDAwMDA0ZGE0DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjQ3XSAgIGdmbjogMDAw
MDRkYTUgIG1mbjogMDAwMDRkYTUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NDddICAg
Z2ZuOiAwMDAwNGRhNiAgbWZuOiAwMDAwNGRhNg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
Mjo0N10gICBnZm46IDAwMDA0ZGE3ICBtZm46IDAwMDA0ZGE3DQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMyOjQ3XSAgIGdmbjogMDAwMDRkYTggIG1mbjogMDAwMDRkYTgNCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzI6NDddICAgZ2ZuOiAwMDAwNGRhOSAgbWZuOiAwMDAwNGRhOQ0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo0N10gICBnZm46IDAwMDA0ZGFhICBtZm46IDAw
MDA0ZGFhDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjQ3XSAgIGdmbjogMDAwMDRkYWIg
IG1mbjogMDAwMDRkYWINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NDddICAgZ2ZuOiAw
MDAwNGRhYyAgbWZuOiAwMDAwNGRhYw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo0OF0g
ICBnZm46IDAwMDA0ZGFkICBtZm46IDAwMDA0ZGFkDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMyOjQ4XSAgIGdmbjogMDAwMDRkYWUgIG1mbjogMDAwMDRkYWUNCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzI6NDhdICAgZ2ZuOiAwMDAwNGRhZiAgbWZuOiAwMDAwNGRhZg0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMjo0OF0gICBnZm46IDAwMDA0ZGIwICBtZm46IDAwMDA0ZGIw
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjQ4XSAgIGdmbjogMDAwMDRkYjEgIG1mbjog
MDAwMDRkYjENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NDhdICAgZ2ZuOiAwMDAwNGRi
MiAgbWZuOiAwMDAwNGRiMg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo0OF0gICBnZm46
IDAwMDA0ZGIzICBtZm46IDAwMDA0ZGIzDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjQ4
XSAgIGdmbjogMDAwMDRkYjQgIG1mbjogMDAwMDRkYjQNCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzI6NDhdICAgZ2ZuOiAwMDAwNGRiNSAgbWZuOiAwMDAwNGRiNQ0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMjo0OF0gICBnZm46IDAwMDA0ZGI2ICBtZm46IDAwMDA0ZGI2DQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMyOjQ4XSAgIGdmbjogMDAwMDRkYjcgIG1mbjogMDAwMDRk
YjcNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NDhdICAgZ2ZuOiAwMDAwNGRiOCAgbWZu
OiAwMDAwNGRiOA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo0OF0gICBnZm46IDAwMDA0
ZGI5ICBtZm46IDAwMDA0ZGI5DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjQ4XSAgIGdm
bjogMDAwMDRkYmEgIG1mbjogMDAwMDRkYmENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6
NDhdICAgZ2ZuOiAwMDAwNGRiYiAgbWZuOiAwMDAwNGRiYg0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMjo0OF0gICBnZm46IDAwMDA0ZGJjICBtZm46IDAwMDA0ZGJjDQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMyOjQ4XSAgIGdmbjogMDAwMDRkYmQgIG1mbjogMDAwMDRkYmQNCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NDhdICAgZ2ZuOiAwMDAwNGRiZSAgbWZuOiAwMDAw
NGRiZQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo0OF0gICBnZm46IDAwMDA0ZGJmICBt
Zm46IDAwMDA0ZGJmDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjQ4XSAgIGdmbjogMDAw
MDRkYzAgIG1mbjogMDAwMDRkYzANCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NDhdICAg
Z2ZuOiAwMDAwNGRjMSAgbWZuOiAwMDAwNGRjMQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
Mjo0OF0gICBnZm46IDAwMDA0ZGMyICBtZm46IDAwMDA0ZGMyDQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMyOjQ4XSAgIGdmbjogMDAwMDRkYzMgIG1mbjogMDAwMDRkYzMNCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzI6NDhdICAgZ2ZuOiAwMDAwNGRjNCAgbWZuOiAwMDAwNGRjNA0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo0OF0gICBnZm46IDAwMDA0ZGM1ICBtZm46IDAw
MDA0ZGM1DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjQ4XSAgIGdmbjogMDAwMDRkYzYg
IG1mbjogMDAwMDRkYzYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NDhdICAgZ2ZuOiAw
MDAwNGRjNyAgbWZuOiAwMDAwNGRjNw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo0OF0g
ICBnZm46IDAwMDA0ZGM4ICBtZm46IDAwMDA0ZGM4DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMyOjQ4XSAgIGdmbjogMDAwMDRkYzkgIG1mbjogMDAwMDRkYzkNCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzI6NDhdICAgZ2ZuOiAwMDAwNGRjYSAgbWZuOiAwMDAwNGRjYQ0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMjo0OF0gICBnZm46IDAwMDA0ZGNiICBtZm46IDAwMDA0ZGNi
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjQ4XSAgIGdmbjogMDAwMDRkY2MgIG1mbjog
MDAwMDRkY2MNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NDhdICAgZ2ZuOiAwMDAwNGRj
ZCAgbWZuOiAwMDAwNGRjZA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo0OF0gICBnZm46
IDAwMDA0ZGNlICBtZm46IDAwMDA0ZGNlDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjQ4
XSAgIGdmbjogMDAwMDRkY2YgIG1mbjogMDAwMDRkY2YNCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzI6NDhdICAgZ2ZuOiAwMDAwNGRkMCAgbWZuOiAwMDAwNGRkMA0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMjo0OF0gICBnZm46IDAwMDA0ZGQxICBtZm46IDAwMDA0ZGQxDQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMyOjQ4XSAgIGdmbjogMDAwMDRkZDIgIG1mbjogMDAwMDRk
ZDINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NDhdICAgZ2ZuOiAwMDAwNGRkMyAgbWZu
OiAwMDAwNGRkMw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo0OF0gICBnZm46IDAwMDA0
ZGQ0ICBtZm46IDAwMDA0ZGQ0DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjQ4XSAgIGdm
bjogMDAwMDRkZDUgIG1mbjogMDAwMDRkZDUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6
NDhdICAgZ2ZuOiAwMDAwNGRkNiAgbWZuOiAwMDAwNGRkNg0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMjo0OF0gICBnZm46IDAwMDA0ZGQ3ICBtZm46IDAwMDA0ZGQ3DQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMyOjQ4XSAgIGdmbjogMDAwMDRkZDggIG1mbjogMDAwMDRkZDgNCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NDhdICAgZ2ZuOiAwMDAwNGRkOSAgbWZuOiAwMDAw
NGRkOQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo0OF0gICBnZm46IDAwMDA0ZGRhICBt
Zm46IDAwMDA0ZGRhDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjQ4XSAgIGdmbjogMDAw
MDRkZGIgIG1mbjogMDAwMDRkZGINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NDhdICAg
Z2ZuOiAwMDAwNGRkYyAgbWZuOiAwMDAwNGRkYw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
Mjo0OF0gICBnZm46IDAwMDA0ZGRkICBtZm46IDAwMDA0ZGRkDQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMyOjQ4XSAgIGdmbjogMDAwMDRkZGUgIG1mbjogMDAwMDRkZGUNCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzI6NDhdICAgZ2ZuOiAwMDAwNGRkZiAgbWZuOiAwMDAwNGRkZg0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo0OF0gICBnZm46IDAwMDA0ZGUwICBtZm46IDAw
MDA0ZGUwDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjQ4XSAgIGdmbjogMDAwMDRkZTEg
IG1mbjogMDAwMDRkZTENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NDhdICAgZ2ZuOiAw
MDAwNGRlMiAgbWZuOiAwMDAwNGRlMg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo0OF0g
ICBnZm46IDAwMDA0ZGUzICBtZm46IDAwMDA0ZGUzDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMyOjQ4XSAgIGdmbjogMDAwMDRkZTQgIG1mbjogMDAwMDRkZTQNCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzI6NDhdICAgZ2ZuOiAwMDAwNGRlNSAgbWZuOiAwMDAwNGRlNQ0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMjo0OF0gICBnZm46IDAwMDA0ZGU2ICBtZm46IDAwMDA0ZGU2
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjQ4XSAgIGdmbjogMDAwMDRkZTcgIG1mbjog
MDAwMDRkZTcNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NDhdICAgZ2ZuOiAwMDAwNGRl
OCAgbWZuOiAwMDAwNGRlOA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo0OF0gICBnZm46
IDAwMDA0ZGU5ICBtZm46IDAwMDA0ZGU5DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjQ4
XSAgIGdmbjogMDAwMDRkZWEgIG1mbjogMDAwMDRkZWENCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzI6NDhdICAgZ2ZuOiAwMDAwNGRlYiAgbWZuOiAwMDAwNGRlYg0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMjo0OF0gICBnZm46IDAwMDA0ZGVjICBtZm46IDAwMDA0ZGVjDQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMyOjQ5XSAgIGdmbjogMDAwMDRkZWQgIG1mbjogMDAwMDRk
ZWQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NDldICAgZ2ZuOiAwMDAwNGRlZSAgbWZu
OiAwMDAwNGRlZQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo0OV0gICBnZm46IDAwMDA0
ZGVmICBtZm46IDAwMDA0ZGVmDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjQ5XSAgIGdm
bjogMDAwMDRkZjAgIG1mbjogMDAwMDRkZjANCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6
NDldICAgZ2ZuOiAwMDAwNGRmMSAgbWZuOiAwMDAwNGRmMQ0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMjo0OV0gICBnZm46IDAwMDA0ZGYyICBtZm46IDAwMDA0ZGYyDQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMyOjQ5XSAgIGdmbjogMDAwMDRkZjMgIG1mbjogMDAwMDRkZjMNCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NDldICAgZ2ZuOiAwMDAwNGRmNCAgbWZuOiAwMDAw
NGRmNA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo0OV0gICBnZm46IDAwMDA0ZGY1ICBt
Zm46IDAwMDA0ZGY1DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjQ5XSAgIGdmbjogMDAw
MDRkZjYgIG1mbjogMDAwMDRkZjYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NDldICAg
Z2ZuOiAwMDAwNGRmNyAgbWZuOiAwMDAwNGRmNw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
Mjo0OV0gICBnZm46IDAwMDA0ZGY4ICBtZm46IDAwMDA0ZGY4DQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMyOjQ5XSAgIGdmbjogMDAwMDRkZjkgIG1mbjogMDAwMDRkZjkNCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzI6NDldICAgZ2ZuOiAwMDAwNGRmYSAgbWZuOiAwMDAwNGRmYQ0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo0OV0gICBnZm46IDAwMDA0ZGZiICBtZm46IDAw
MDA0ZGZiDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjQ5XSAgIGdmbjogMDAwMDRkZmMg
IG1mbjogMDAwMDRkZmMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NDldICAgZ2ZuOiAw
MDAwNGRmZCAgbWZuOiAwMDAwNGRmZA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo0OV0g
ICBnZm46IDAwMDA0ZGZlICBtZm46IDAwMDA0ZGZlDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMyOjQ5XSAgIGdmbjogMDAwMDRkZmYgIG1mbjogMDAwMDRkZmYNCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzI6NDldICAgZ2ZuOiAwMDAwNGUwMCAgbWZuOiAwMDAwNGUwMA0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMjo0OV0gICBnZm46IDAwMDA0ZTAxICBtZm46IDAwMDA0ZTAx
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjQ5XSAgIGdmbjogMDAwMDRlMDIgIG1mbjog
MDAwMDRlMDINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NDldICAgZ2ZuOiAwMDAwNGUw
MyAgbWZuOiAwMDAwNGUwMw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo0OV0gICBnZm46
IDAwMDA0ZTA0ICBtZm46IDAwMDA0ZTA0DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjQ5
XSAgIGdmbjogMDAwMDRlMDUgIG1mbjogMDAwMDRlMDUNCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzI6NDldICAgZ2ZuOiAwMDAwNGUwNiAgbWZuOiAwMDAwNGUwNg0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMjo0OV0gICBnZm46IDAwMDA0ZTA3ICBtZm46IDAwMDA0ZTA3DQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMyOjQ5XSAgIGdmbjogMDAwMDRlMDggIG1mbjogMDAwMDRl
MDgNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NDldICAgZ2ZuOiAwMDAwNGUwOSAgbWZu
OiAwMDAwNGUwOQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo0OV0gICBnZm46IDAwMDA0
ZTBhICBtZm46IDAwMDA0ZTBhDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjQ5XSAgIGdm
bjogMDAwMDRlMGIgIG1mbjogMDAwMDRlMGINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6
NDldICAgZ2ZuOiAwMDAwNGUwYyAgbWZuOiAwMDAwNGUwYw0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMjo0OV0gICBnZm46IDAwMDA0ZTBkICBtZm46IDAwMDA0ZTBkDQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMyOjQ5XSAgIGdmbjogMDAwMDRlMGUgIG1mbjogMDAwMDRlMGUNCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NDldICAgZ2ZuOiAwMDAwNGUwZiAgbWZuOiAwMDAw
NGUwZg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo0OV0gICBnZm46IDAwMDA0ZTEwICBt
Zm46IDAwMDA0ZTEwDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjQ5XSAgIGdmbjogMDAw
MDRlMTEgIG1mbjogMDAwMDRlMTENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NDldICAg
Z2ZuOiAwMDAwNGUxMiAgbWZuOiAwMDAwNGUxMg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
Mjo0OV0gICBnZm46IDAwMDA0ZTEzICBtZm46IDAwMDA0ZTEzDQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMyOjQ5XSAgIGdmbjogMDAwMDRlMTQgIG1mbjogMDAwMDRlMTQNCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzI6NDldICAgZ2ZuOiAwMDAwNGUxNSAgbWZuOiAwMDAwNGUxNQ0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo0OV0gICBnZm46IDAwMDA0ZTE2ICBtZm46IDAw
MDA0ZTE2DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjQ5XSAgIGdmbjogMDAwMDRlMTcg
IG1mbjogMDAwMDRlMTcNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NDldICAgZ2ZuOiAw
MDAwNGUxOCAgbWZuOiAwMDAwNGUxOA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo0OV0g
ICBnZm46IDAwMDA0ZTE5ICBtZm46IDAwMDA0ZTE5DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMyOjQ5XSAgIGdmbjogMDAwMDRlMWEgIG1mbjogMDAwMDRlMWENCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzI6NDldICAgZ2ZuOiAwMDAwNGUxYiAgbWZuOiAwMDAwNGUxYg0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMjo0OV0gICBnZm46IDAwMDA0ZTFjICBtZm46IDAwMDA0ZTFj
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjQ5XSAgIGdmbjogMDAwMDRlMWQgIG1mbjog
MDAwMDRlMWQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NDldICAgZ2ZuOiAwMDAwNGUx
ZSAgbWZuOiAwMDAwNGUxZQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo0OV0gICBnZm46
IDAwMDA0ZTFmICBtZm46IDAwMDA0ZTFmDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjQ5
XSAgIGdmbjogMDAwMDRlMjAgIG1mbjogMDAwMDRlMjANCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzI6NDldICAgZ2ZuOiAwMDAwNGUyMSAgbWZuOiAwMDAwNGUyMQ0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMjo0OV0gICBnZm46IDAwMDA0ZTIyICBtZm46IDAwMDA0ZTIyDQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMyOjQ5XSAgIGdmbjogMDAwMDRlMjMgIG1mbjogMDAwMDRl
MjMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NDldICAgZ2ZuOiAwMDAwNGUyNCAgbWZu
OiAwMDAwNGUyNA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo0OV0gICBnZm46IDAwMDA0
ZTI1ICBtZm46IDAwMDA0ZTI1DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjQ5XSAgIGdm
bjogMDAwMDRlMjYgIG1mbjogMDAwMDRlMjYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6
NDldICAgZ2ZuOiAwMDAwNGUyNyAgbWZuOiAwMDAwNGUyNw0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMjo0OV0gICBnZm46IDAwMDA0ZTI4ICBtZm46IDAwMDA0ZTI4DQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMyOjQ5XSAgIGdmbjogMDAwMDRlMjkgIG1mbjogMDAwMDRlMjkNCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NDldICAgZ2ZuOiAwMDAwNGUyYSAgbWZuOiAwMDAw
NGUyYQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo0OV0gICBnZm46IDAwMDA0ZTJiICBt
Zm46IDAwMDA0ZTJiDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjQ5XSAgIGdmbjogMDAw
MDRlMmMgIG1mbjogMDAwMDRlMmMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NTBdICAg
Z2ZuOiAwMDAwNGUyZCAgbWZuOiAwMDAwNGUyZA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
Mjo1MF0gICBnZm46IDAwMDA0ZTJlICBtZm46IDAwMDA0ZTJlDQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMyOjUwXSAgIGdmbjogMDAwMDRlMmYgIG1mbjogMDAwMDRlMmYNCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzI6NTBdICAgZ2ZuOiAwMDAwNGUzMCAgbWZuOiAwMDAwNGUzMA0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo1MF0gICBnZm46IDAwMDA0ZTMxICBtZm46IDAw
MDA0ZTMxDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjUwXSAgIGdmbjogMDAwMDRlMzIg
IG1mbjogMDAwMDRlMzINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NTBdICAgZ2ZuOiAw
MDAwNGUzMyAgbWZuOiAwMDAwNGUzMw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo1MF0g
ICBnZm46IDAwMDA0ZTM0ICBtZm46IDAwMDA0ZTM0DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMyOjUwXSAgIGdmbjogMDAwMDRlMzUgIG1mbjogMDAwMDRlMzUNCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzI6NTBdICAgZ2ZuOiAwMDAwNGUzNiAgbWZuOiAwMDAwNGUzNg0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMjo1MF0gICBnZm46IDAwMDA0ZTM3ICBtZm46IDAwMDA0ZTM3
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjUwXSAgIGdmbjogMDAwMDRlMzggIG1mbjog
MDAwMDRlMzgNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NTBdICAgZ2ZuOiAwMDAwNGUz
OSAgbWZuOiAwMDAwNGUzOQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo1MF0gICBnZm46
IDAwMDA0ZTNhICBtZm46IDAwMDA0ZTNhDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjUw
XSAgIGdmbjogMDAwMDRlM2IgIG1mbjogMDAwMDRlM2INCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzI6NTBdICAgZ2ZuOiAwMDAwNGUzYyAgbWZuOiAwMDAwNGUzYw0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMjo1MF0gICBnZm46IDAwMDA0ZTNkICBtZm46IDAwMDA0ZTNkDQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMyOjUwXSAgIGdmbjogMDAwMDRlM2UgIG1mbjogMDAwMDRl
M2UNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NTBdICAgZ2ZuOiAwMDAwNGUzZiAgbWZu
OiAwMDAwNGUzZg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo1MF0gICBnZm46IDAwMDA0
ZTQwICBtZm46IDAwMDA0ZTQwDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjUwXSAgIGdm
bjogMDAwMDRlNDEgIG1mbjogMDAwMDRlNDENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6
NTBdICAgZ2ZuOiAwMDAwNGU0MiAgbWZuOiAwMDAwNGU0Mg0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMjo1MF0gICBnZm46IDAwMDA0ZTQzICBtZm46IDAwMDA0ZTQzDQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMyOjUwXSAgIGdmbjogMDAwMDRlNDQgIG1mbjogMDAwMDRlNDQNCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NTBdICAgZ2ZuOiAwMDAwNGU0NSAgbWZuOiAwMDAw
NGU0NQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo1MF0gICBnZm46IDAwMDA0ZTQ2ICBt
Zm46IDAwMDA0ZTQ2DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjUwXSAgIGdmbjogMDAw
MDRlNDcgIG1mbjogMDAwMDRlNDcNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NTBdICAg
Z2ZuOiAwMDAwNGU0OCAgbWZuOiAwMDAwNGU0OA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
Mjo1MF0gICBnZm46IDAwMDA0ZTQ5ICBtZm46IDAwMDA0ZTQ5DQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMyOjUwXSAgIGdmbjogMDAwMDRlNGEgIG1mbjogMDAwMDRlNGENCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzI6NTBdICAgZ2ZuOiAwMDAwNGU0YiAgbWZuOiAwMDAwNGU0Yg0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo1MF0gICBnZm46IDAwMDA0ZTRjICBtZm46IDAw
MDA0ZTRjDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjUwXSAgIGdmbjogMDAwMDRlNGQg
IG1mbjogMDAwMDRlNGQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NTBdICAgZ2ZuOiAw
MDAwNGU0ZSAgbWZuOiAwMDAwNGU0ZQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo1MF0g
ICBnZm46IDAwMDA0ZTRmICBtZm46IDAwMDA0ZTRmDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMyOjUwXSAgIGdmbjogMDAwMDRlNTAgIG1mbjogMDAwMDRlNTANCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzI6NTBdICAgZ2ZuOiAwMDAwNGU1MSAgbWZuOiAwMDAwNGU1MQ0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMjo1MF0gICBnZm46IDAwMDA0ZTUyICBtZm46IDAwMDA0ZTUy
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjUwXSAgIGdmbjogMDAwMDRlNTMgIG1mbjog
MDAwMDRlNTMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NTBdICAgZ2ZuOiAwMDAwNGU1
NCAgbWZuOiAwMDAwNGU1NA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo1MF0gICBnZm46
IDAwMDA0ZTU1ICBtZm46IDAwMDA0ZTU1DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjUw
XSAgIGdmbjogMDAwMDRlNTYgIG1mbjogMDAwMDRlNTYNCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzI6NTBdICAgZ2ZuOiAwMDAwNGU1NyAgbWZuOiAwMDAwNGU1Nw0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMjo1MF0gICBnZm46IDAwMDA0ZTU4ICBtZm46IDAwMDA0ZTU4DQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMyOjUwXSAgIGdmbjogMDAwMDRlNTkgIG1mbjogMDAwMDRl
NTkNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NTBdICAgZ2ZuOiAwMDAwNGU1YSAgbWZu
OiAwMDAwNGU1YQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo1MF0gICBnZm46IDAwMDA0
ZTViICBtZm46IDAwMDA0ZTViDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjUwXSAgIGdm
bjogMDAwMDRlNWMgIG1mbjogMDAwMDRlNWMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6
NTBdICAgZ2ZuOiAwMDAwNGU1ZCAgbWZuOiAwMDAwNGU1ZA0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMjo1MF0gICBnZm46IDAwMDA0ZTVlICBtZm46IDAwMDA0ZTVlDQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMyOjUwXSAgIGdmbjogMDAwMDRlNWYgIG1mbjogMDAwMDRlNWYNCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NTBdICAgZ2ZuOiAwMDAwNGU2MCAgbWZuOiAwMDAw
NGU2MA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo1MF0gICBnZm46IDAwMDA0ZTYxICBt
Zm46IDAwMDA0ZTYxDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjUwXSAgIGdmbjogMDAw
MDRlNjIgIG1mbjogMDAwMDRlNjINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NTBdICAg
Z2ZuOiAwMDAwNGU2MyAgbWZuOiAwMDAwNGU2Mw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
Mjo1MF0gICBnZm46IDAwMDA0ZTY0ICBtZm46IDAwMDA0ZTY0DQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMyOjUwXSAgIGdmbjogMDAwMDRlNjUgIG1mbjogMDAwMDRlNjUNCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzI6NTBdICAgZ2ZuOiAwMDAwNGU2NiAgbWZuOiAwMDAwNGU2Ng0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo1MF0gICBnZm46IDAwMDA0ZTY3ICBtZm46IDAw
MDA0ZTY3DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjUwXSAgIGdmbjogMDAwMDRlNjgg
IG1mbjogMDAwMDRlNjgNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NTBdICAgZ2ZuOiAw
MDAwNGU2OSAgbWZuOiAwMDAwNGU2OQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo1MF0g
ICBnZm46IDAwMDA0ZTZhICBtZm46IDAwMDA0ZTZhDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMyOjUwXSAgIGdmbjogMDAwMDRlNmIgIG1mbjogMDAwMDRlNmINCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzI6NTBdICAgZ2ZuOiAwMDAwNGU2YyAgbWZuOiAwMDAwNGU2Yw0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMjo1MV0gICBnZm46IDAwMDA0ZTZkICBtZm46IDAwMDA0ZTZk
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjUxXSAgIGdmbjogMDAwMDRlNmUgIG1mbjog
MDAwMDRlNmUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NTFdICAgZ2ZuOiAwMDAwNGU2
ZiAgbWZuOiAwMDAwNGU2Zg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo1MV0gICBnZm46
IDAwMDA0ZTcwICBtZm46IDAwMDA0ZTcwDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjUx
XSAgIGdmbjogMDAwMDRlNzEgIG1mbjogMDAwMDRlNzENCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzI6NTFdICAgZ2ZuOiAwMDAwNGU3MiAgbWZuOiAwMDAwNGU3Mg0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMjo1MV0gICBnZm46IDAwMDA0ZTczICBtZm46IDAwMDA0ZTczDQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMyOjUxXSAgIGdmbjogMDAwMDRlNzQgIG1mbjogMDAwMDRl
NzQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NTFdICAgZ2ZuOiAwMDAwNGU3NSAgbWZu
OiAwMDAwNGU3NQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo1MV0gICBnZm46IDAwMDA0
ZTc2ICBtZm46IDAwMDA0ZTc2DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjUxXSAgIGdm
bjogMDAwMDRlNzcgIG1mbjogMDAwMDRlNzcNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6
NTFdICAgZ2ZuOiAwMDAwNGU3OCAgbWZuOiAwMDAwNGU3OA0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMjo1MV0gICBnZm46IDAwMDA0ZTc5ICBtZm46IDAwMDA0ZTc5DQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMyOjUxXSAgIGdmbjogMDAwMDRlN2EgIG1mbjogMDAwMDRlN2ENCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NTFdICAgZ2ZuOiAwMDAwNGU3YiAgbWZuOiAwMDAw
NGU3Yg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo1MV0gICBnZm46IDAwMDA0ZTdjICBt
Zm46IDAwMDA0ZTdjDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjUxXSAgIGdmbjogMDAw
MDRlN2QgIG1mbjogMDAwMDRlN2QNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NTFdICAg
Z2ZuOiAwMDAwNGU3ZSAgbWZuOiAwMDAwNGU3ZQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
Mjo1MV0gICBnZm46IDAwMDA0ZTdmICBtZm46IDAwMDA0ZTdmDQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMyOjUxXSAgIGdmbjogMDAwMDRlODAgIG1mbjogMDAwMDRlODANCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzI6NTFdICAgZ2ZuOiAwMDAwNGU4MSAgbWZuOiAwMDAwNGU4MQ0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo1MV0gICBnZm46IDAwMDA0ZTgyICBtZm46IDAw
MDA0ZTgyDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjUxXSAgIGdmbjogMDAwMDRlODMg
IG1mbjogMDAwMDRlODMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NTFdICAgZ2ZuOiAw
MDAwNGU4NCAgbWZuOiAwMDAwNGU4NA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo1MV0g
ICBnZm46IDAwMDA0ZTg1ICBtZm46IDAwMDA0ZTg1DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMyOjUxXSAgIGdmbjogMDAwMDRlODYgIG1mbjogMDAwMDRlODYNCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzI6NTFdICAgZ2ZuOiAwMDAwNGU4NyAgbWZuOiAwMDAwNGU4Nw0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMjo1MV0gICBnZm46IDAwMDA0ZTg4ICBtZm46IDAwMDA0ZTg4
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjUxXSAgIGdmbjogMDAwMDRlODkgIG1mbjog
MDAwMDRlODkNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NTFdICAgZ2ZuOiAwMDAwNGU4
YSAgbWZuOiAwMDAwNGU4YQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo1MV0gICBnZm46
IDAwMDA0ZThiICBtZm46IDAwMDA0ZThiDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjUx
XSAgIGdmbjogMDAwMDRlOGMgIG1mbjogMDAwMDRlOGMNCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzI6NTFdICAgZ2ZuOiAwMDAwNGU4ZCAgbWZuOiAwMDAwNGU4ZA0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMjo1MV0gICBnZm46IDAwMDA0ZThlICBtZm46IDAwMDA0ZThlDQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMyOjUxXSAgIGdmbjogMDAwMDRlOGYgIG1mbjogMDAwMDRl
OGYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NTFdICAgZ2ZuOiAwMDAwNGU5MCAgbWZu
OiAwMDAwNGU5MA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo1MV0gICBnZm46IDAwMDA0
ZTkxICBtZm46IDAwMDA0ZTkxDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjUxXSAgIGdm
bjogMDAwMDRlOTIgIG1mbjogMDAwMDRlOTINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6
NTFdICAgZ2ZuOiAwMDAwNGU5MyAgbWZuOiAwMDAwNGU5Mw0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMjo1MV0gICBnZm46IDAwMDA0ZTk0ICBtZm46IDAwMDA0ZTk0DQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMyOjUxXSAgIGdmbjogMDAwMDRlOTUgIG1mbjogMDAwMDRlOTUNCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NTFdICAgZ2ZuOiAwMDAwNGU5NiAgbWZuOiAwMDAw
NGU5Ng0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo1MV0gICBnZm46IDAwMDA0ZTk3ICBt
Zm46IDAwMDA0ZTk3DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjUxXSAgIGdmbjogMDAw
MDRlOTggIG1mbjogMDAwMDRlOTgNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NTFdICAg
Z2ZuOiAwMDAwNGU5OSAgbWZuOiAwMDAwNGU5OQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
Mjo1MV0gICBnZm46IDAwMDA0ZTlhICBtZm46IDAwMDA0ZTlhDQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMyOjUxXSAgIGdmbjogMDAwMDRlOWIgIG1mbjogMDAwMDRlOWINCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzI6NTFdICAgZ2ZuOiAwMDAwNGU5YyAgbWZuOiAwMDAwNGU5Yw0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo1MV0gICBnZm46IDAwMDA0ZTlkICBtZm46IDAw
MDA0ZTlkDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjUxXSAgIGdmbjogMDAwMDRlOWUg
IG1mbjogMDAwMDRlOWUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NTFdICAgZ2ZuOiAw
MDAwNGU5ZiAgbWZuOiAwMDAwNGU5Zg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo1MV0g
ICBnZm46IDAwMDA0ZWEwICBtZm46IDAwMDA0ZWEwDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMyOjUxXSAgIGdmbjogMDAwMDRlYTEgIG1mbjogMDAwMDRlYTENCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzI6NTFdICAgZ2ZuOiAwMDAwNGVhMiAgbWZuOiAwMDAwNGVhMg0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMjo1MV0gICBnZm46IDAwMDA0ZWEzICBtZm46IDAwMDA0ZWEz
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjUxXSAgIGdmbjogMDAwMDRlYTQgIG1mbjog
MDAwMDRlYTQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NTFdICAgZ2ZuOiAwMDAwNGVh
NSAgbWZuOiAwMDAwNGVhNQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo1MV0gICBnZm46
IDAwMDA0ZWE2ICBtZm46IDAwMDA0ZWE2DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjUx
XSAgIGdmbjogMDAwMDRlYTcgIG1mbjogMDAwMDRlYTcNCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzI6NTFdICAgZ2ZuOiAwMDAwNGVhOCAgbWZuOiAwMDAwNGVhOA0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMjo1MV0gICBnZm46IDAwMDA0ZWE5ICBtZm46IDAwMDA0ZWE5DQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMyOjUxXSAgIGdmbjogMDAwMDRlYWEgIG1mbjogMDAwMDRl
YWENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NTFdICAgZ2ZuOiAwMDAwNGVhYiAgbWZu
OiAwMDAwNGVhYg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo1MV0gICBnZm46IDAwMDA0
ZWFjICBtZm46IDAwMDA0ZWFjDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjUyXSAgIGdm
bjogMDAwMDRlYWQgIG1mbjogMDAwMDRlYWQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6
NTJdICAgZ2ZuOiAwMDAwNGVhZSAgbWZuOiAwMDAwNGVhZQ0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMjo1Ml0gICBnZm46IDAwMDA0ZWFmICBtZm46IDAwMDA0ZWFmDQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMyOjUyXSAgIGdmbjogMDAwMDRlYjAgIG1mbjogMDAwMDRlYjANCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NTJdICAgZ2ZuOiAwMDAwNGViMSAgbWZuOiAwMDAw
NGViMQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo1Ml0gICBnZm46IDAwMDA0ZWIyICBt
Zm46IDAwMDA0ZWIyDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjUyXSAgIGdmbjogMDAw
MDRlYjMgIG1mbjogMDAwMDRlYjMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NTJdICAg
Z2ZuOiAwMDAwNGViNCAgbWZuOiAwMDAwNGViNA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
Mjo1Ml0gICBnZm46IDAwMDA0ZWI1ICBtZm46IDAwMDA0ZWI1DQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMyOjUyXSAgIGdmbjogMDAwMDRlYjYgIG1mbjogMDAwMDRlYjYNCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzI6NTJdICAgZ2ZuOiAwMDAwNGViNyAgbWZuOiAwMDAwNGViNw0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo1Ml0gICBnZm46IDAwMDA0ZWI4ICBtZm46IDAw
MDA0ZWI4DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjUyXSAgIGdmbjogMDAwMDRlYjkg
IG1mbjogMDAwMDRlYjkNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NTJdICAgZ2ZuOiAw
MDAwNGViYSAgbWZuOiAwMDAwNGViYQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo1Ml0g
ICBnZm46IDAwMDA0ZWJiICBtZm46IDAwMDA0ZWJiDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMyOjUyXSAgIGdmbjogMDAwMDRlYmMgIG1mbjogMDAwMDRlYmMNCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzI6NTJdICAgZ2ZuOiAwMDAwNGViZCAgbWZuOiAwMDAwNGViZA0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMjo1Ml0gICBnZm46IDAwMDA0ZWJlICBtZm46IDAwMDA0ZWJl
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjUyXSAgIGdmbjogMDAwMDRlYmYgIG1mbjog
MDAwMDRlYmYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NTJdICAgZ2ZuOiAwMDAwNGVj
MCAgbWZuOiAwMDAwNGVjMA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo1Ml0gICBnZm46
IDAwMDA0ZWMxICBtZm46IDAwMDA0ZWMxDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjUy
XSAgIGdmbjogMDAwMDRlYzIgIG1mbjogMDAwMDRlYzINCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzI6NTJdICAgZ2ZuOiAwMDAwNGVjMyAgbWZuOiAwMDAwNGVjMw0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMjo1Ml0gICBnZm46IDAwMDA0ZWM0ICBtZm46IDAwMDA0ZWM0DQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMyOjUyXSAgIGdmbjogMDAwMDRlYzUgIG1mbjogMDAwMDRl
YzUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NTJdICAgZ2ZuOiAwMDAwNGVjNiAgbWZu
OiAwMDAwNGVjNg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo1Ml0gICBnZm46IDAwMDA0
ZWM3ICBtZm46IDAwMDA0ZWM3DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjUyXSAgIGdm
bjogMDAwMDRlYzggIG1mbjogMDAwMDRlYzgNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6
NTJdICAgZ2ZuOiAwMDAwNGVjOSAgbWZuOiAwMDAwNGVjOQ0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMjo1Ml0gICBnZm46IDAwMDA0ZWNhICBtZm46IDAwMDA0ZWNhDQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMyOjUyXSAgIGdmbjogMDAwMDRlY2IgIG1mbjogMDAwMDRlY2INCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NTJdICAgZ2ZuOiAwMDAwNGVjYyAgbWZuOiAwMDAw
NGVjYw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo1Ml0gICBnZm46IDAwMDA0ZWNkICBt
Zm46IDAwMDA0ZWNkDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjUyXSAgIGdmbjogMDAw
MDRlY2UgIG1mbjogMDAwMDRlY2UNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NTJdICAg
Z2ZuOiAwMDAwNGVjZiAgbWZuOiAwMDAwNGVjZg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
Mjo1Ml0gICBnZm46IDAwMDA0ZWQwICBtZm46IDAwMDA0ZWQwDQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMyOjUyXSAgIGdmbjogMDAwMDRlZDEgIG1mbjogMDAwMDRlZDENCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzI6NTJdICAgZ2ZuOiAwMDAwNGVkMiAgbWZuOiAwMDAwNGVkMg0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo1Ml0gICBnZm46IDAwMDA0ZWQzICBtZm46IDAw
MDA0ZWQzDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjUyXSAgIGdmbjogMDAwMDRlZDQg
IG1mbjogMDAwMDRlZDQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NTJdICAgZ2ZuOiAw
MDAwNGVkNSAgbWZuOiAwMDAwNGVkNQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo1Ml0g
ICBnZm46IDAwMDA0ZWQ2ICBtZm46IDAwMDA0ZWQ2DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMyOjUyXSAgIGdmbjogMDAwMDRlZDcgIG1mbjogMDAwMDRlZDcNCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzI6NTJdICAgZ2ZuOiAwMDAwNGVkOCAgbWZuOiAwMDAwNGVkOA0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMjo1Ml0gICBnZm46IDAwMDA0ZWQ5ICBtZm46IDAwMDA0ZWQ5
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjUyXSAgIGdmbjogMDAwMDRlZGEgIG1mbjog
MDAwMDRlZGENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NTJdICAgZ2ZuOiAwMDAwNGVk
YiAgbWZuOiAwMDAwNGVkYg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo1Ml0gICBnZm46
IDAwMDA0ZWRjICBtZm46IDAwMDA0ZWRjDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjUy
XSAgIGdmbjogMDAwMDRlZGQgIG1mbjogMDAwMDRlZGQNCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzI6NTJdICAgZ2ZuOiAwMDAwNGVkZSAgbWZuOiAwMDAwNGVkZQ0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMjo1Ml0gICBnZm46IDAwMDA0ZWRmICBtZm46IDAwMDA0ZWRmDQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMyOjUyXSAgIGdmbjogMDAwMDRlZTAgIG1mbjogMDAwMDRl
ZTANCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NTJdICAgZ2ZuOiAwMDAwNGVlMSAgbWZu
OiAwMDAwNGVlMQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo1Ml0gICBnZm46IDAwMDA0
ZWUyICBtZm46IDAwMDA0ZWUyDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjUyXSAgIGdm
bjogMDAwMDRlZTMgIG1mbjogMDAwMDRlZTMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6
NTJdICAgZ2ZuOiAwMDAwNGVlNCAgbWZuOiAwMDAwNGVlNA0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMjo1Ml0gICBnZm46IDAwMDA0ZWU1ICBtZm46IDAwMDA0ZWU1DQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMyOjUyXSAgIGdmbjogMDAwMDRlZTYgIG1mbjogMDAwMDRlZTYNCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NTJdICAgZ2ZuOiAwMDAwNGVlNyAgbWZuOiAwMDAw
NGVlNw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo1Ml0gICBnZm46IDAwMDA0ZWU4ICBt
Zm46IDAwMDA0ZWU4DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjUyXSAgIGdmbjogMDAw
MDRlZTkgIG1mbjogMDAwMDRlZTkNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NTJdICAg
Z2ZuOiAwMDAwNGVlYSAgbWZuOiAwMDAwNGVlYQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
Mjo1Ml0gICBnZm46IDAwMDA0ZWViICBtZm46IDAwMDA0ZWViDQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMyOjUyXSAgIGdmbjogMDAwMDRlZWMgIG1mbjogMDAwMDRlZWMNCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzI6NTNdICAgZ2ZuOiAwMDAwNGVlZCAgbWZuOiAwMDAwNGVlZA0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo1M10gICBnZm46IDAwMDA0ZWVlICBtZm46IDAw
MDA0ZWVlDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjUzXSAgIGdmbjogMDAwMDRlZWYg
IG1mbjogMDAwMDRlZWYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NTNdICAgZ2ZuOiAw
MDAwNGVmMCAgbWZuOiAwMDAwNGVmMA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo1M10g
ICBnZm46IDAwMDA0ZWYxICBtZm46IDAwMDA0ZWYxDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMyOjUzXSAgIGdmbjogMDAwMDRlZjIgIG1mbjogMDAwMDRlZjINCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzI6NTNdICAgZ2ZuOiAwMDAwNGVmMyAgbWZuOiAwMDAwNGVmMw0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMjo1M10gICBnZm46IDAwMDA0ZWY0ICBtZm46IDAwMDA0ZWY0
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjUzXSAgIGdmbjogMDAwMDRlZjUgIG1mbjog
MDAwMDRlZjUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NTNdICAgZ2ZuOiAwMDAwNGVm
NiAgbWZuOiAwMDAwNGVmNg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo1M10gICBnZm46
IDAwMDA0ZWY3ICBtZm46IDAwMDA0ZWY3DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjUz
XSAgIGdmbjogMDAwMDRlZjggIG1mbjogMDAwMDRlZjgNCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzI6NTNdICAgZ2ZuOiAwMDAwNGVmOSAgbWZuOiAwMDAwNGVmOQ0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMjo1M10gICBnZm46IDAwMDA0ZWZhICBtZm46IDAwMDA0ZWZhDQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMyOjUzXSAgIGdmbjogMDAwMDRlZmIgIG1mbjogMDAwMDRl
ZmINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NTNdICAgZ2ZuOiAwMDAwNGVmYyAgbWZu
OiAwMDAwNGVmYw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo1M10gICBnZm46IDAwMDA0
ZWZkICBtZm46IDAwMDA0ZWZkDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjUzXSAgIGdm
bjogMDAwMDRlZmUgIG1mbjogMDAwMDRlZmUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6
NTNdICAgZ2ZuOiAwMDAwNGVmZiAgbWZuOiAwMDAwNGVmZg0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMjo1M10gICBnZm46IDAwMDA0ZjAwICBtZm46IDAwMDA0ZjAwDQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMyOjUzXSAgIGdmbjogMDAwMDRmMDEgIG1mbjogMDAwMDRmMDENCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NTNdICAgZ2ZuOiAwMDAwNGYwMiAgbWZuOiAwMDAw
NGYwMg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo1M10gICBnZm46IDAwMDA0ZjAzICBt
Zm46IDAwMDA0ZjAzDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjUzXSAgIGdmbjogMDAw
MDRmMDQgIG1mbjogMDAwMDRmMDQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NTNdICAg
Z2ZuOiAwMDAwNGYwNSAgbWZuOiAwMDAwNGYwNQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
Mjo1M10gICBnZm46IDAwMDA0ZjA2ICBtZm46IDAwMDA0ZjA2DQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMyOjUzXSAgIGdmbjogMDAwMDRmMDcgIG1mbjogMDAwMDRmMDcNCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzI6NTNdICAgZ2ZuOiAwMDAwNGYwOCAgbWZuOiAwMDAwNGYwOA0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo1M10gICBnZm46IDAwMDA0ZjA5ICBtZm46IDAw
MDA0ZjA5DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjUzXSAgIGdmbjogMDAwMDRmMGEg
IG1mbjogMDAwMDRmMGENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NTNdICAgZ2ZuOiAw
MDAwNGYwYiAgbWZuOiAwMDAwNGYwYg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo1M10g
ICBnZm46IDAwMDA0ZjBjICBtZm46IDAwMDA0ZjBjDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMyOjUzXSAgIGdmbjogMDAwMDRmMGQgIG1mbjogMDAwMDRmMGQNCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzI6NTNdICAgZ2ZuOiAwMDAwNGYwZSAgbWZuOiAwMDAwNGYwZQ0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMjo1M10gICBnZm46IDAwMDA0ZjBmICBtZm46IDAwMDA0ZjBm
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjUzXSAgIGdmbjogMDAwMDRmMTAgIG1mbjog
MDAwMDRmMTANCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NTNdICAgZ2ZuOiAwMDAwNGYx
MSAgbWZuOiAwMDAwNGYxMQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo1M10gICBnZm46
IDAwMDA0ZjEyICBtZm46IDAwMDA0ZjEyDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjUz
XSAgIGdmbjogMDAwMDRmMTMgIG1mbjogMDAwMDRmMTMNCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzI6NTNdICAgZ2ZuOiAwMDAwNGYxNCAgbWZuOiAwMDAwNGYxNA0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMjo1M10gICBnZm46IDAwMDA0ZjE1ICBtZm46IDAwMDA0ZjE1DQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMyOjUzXSAgIGdmbjogMDAwMDRmMTYgIG1mbjogMDAwMDRm
MTYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NTNdICAgZ2ZuOiAwMDAwNGYxNyAgbWZu
OiAwMDAwNGYxNw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo1M10gICBnZm46IDAwMDA0
ZjE4ICBtZm46IDAwMDA0ZjE4DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjUzXSAgIGdm
bjogMDAwMDRmMTkgIG1mbjogMDAwMDRmMTkNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6
NTNdICAgZ2ZuOiAwMDAwNGYxYSAgbWZuOiAwMDAwNGYxYQ0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMjo1M10gICBnZm46IDAwMDA0ZjFiICBtZm46IDAwMDA0ZjFiDQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMyOjUzXSAgIGdmbjogMDAwMDRmMWMgIG1mbjogMDAwMDRmMWMNCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NTNdICAgZ2ZuOiAwMDAwNGYxZCAgbWZuOiAwMDAw
NGYxZA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo1M10gICBnZm46IDAwMDA0ZjFlICBt
Zm46IDAwMDA0ZjFlDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjUzXSAgIGdmbjogMDAw
MDRmMWYgIG1mbjogMDAwMDRmMWYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NTNdICAg
Z2ZuOiAwMDAwNGYyMCAgbWZuOiAwMDAwNGYyMA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
Mjo1M10gICBnZm46IDAwMDA0ZjIxICBtZm46IDAwMDA0ZjIxDQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMyOjUzXSAgIGdmbjogMDAwMDRmMjIgIG1mbjogMDAwMDRmMjINCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzI6NTNdICAgZ2ZuOiAwMDAwNGYyMyAgbWZuOiAwMDAwNGYyMw0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo1M10gICBnZm46IDAwMDA0ZjI0ICBtZm46IDAw
MDA0ZjI0DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjUzXSAgIGdmbjogMDAwMDRmMjUg
IG1mbjogMDAwMDRmMjUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NTNdICAgZ2ZuOiAw
MDAwNGYyNiAgbWZuOiAwMDAwNGYyNg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo1M10g
ICBnZm46IDAwMDA0ZjI3ICBtZm46IDAwMDA0ZjI3DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMyOjUzXSAgIGdmbjogMDAwMDRmMjggIG1mbjogMDAwMDRmMjgNCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzI6NTNdICAgZ2ZuOiAwMDAwNGYyOSAgbWZuOiAwMDAwNGYyOQ0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMjo1M10gICBnZm46IDAwMDA0ZjJhICBtZm46IDAwMDA0ZjJh
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjUzXSAgIGdmbjogMDAwMDRmMmIgIG1mbjog
MDAwMDRmMmINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NTNdICAgZ2ZuOiAwMDAwNGYy
YyAgbWZuOiAwMDAwNGYyYw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo1NF0gICBnZm46
IDAwMDA0ZjJkICBtZm46IDAwMDA0ZjJkDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjU0
XSAgIGdmbjogMDAwMDRmMmUgIG1mbjogMDAwMDRmMmUNCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzI6NTRdICAgZ2ZuOiAwMDAwNGYyZiAgbWZuOiAwMDAwNGYyZg0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMjo1NF0gICBnZm46IDAwMDA0ZjMwICBtZm46IDAwMDA0ZjMwDQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMyOjU0XSAgIGdmbjogMDAwMDRmMzEgIG1mbjogMDAwMDRm
MzENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NTRdICAgZ2ZuOiAwMDAwNGYzMiAgbWZu
OiAwMDAwNGYzMg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo1NF0gICBnZm46IDAwMDA0
ZjMzICBtZm46IDAwMDA0ZjMzDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjU0XSAgIGdm
bjogMDAwMDRmMzQgIG1mbjogMDAwMDRmMzQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6
NTRdICAgZ2ZuOiAwMDAwNGYzNSAgbWZuOiAwMDAwNGYzNQ0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMjo1NF0gICBnZm46IDAwMDA0ZjM2ICBtZm46IDAwMDA0ZjM2DQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMyOjU0XSAgIGdmbjogMDAwMDRmMzcgIG1mbjogMDAwMDRmMzcNCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NTRdICAgZ2ZuOiAwMDAwNGYzOCAgbWZuOiAwMDAw
NGYzOA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo1NF0gICBnZm46IDAwMDA0ZjM5ICBt
Zm46IDAwMDA0ZjM5DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjU0XSAgIGdmbjogMDAw
MDRmM2EgIG1mbjogMDAwMDRmM2ENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NTRdICAg
Z2ZuOiAwMDAwNGYzYiAgbWZuOiAwMDAwNGYzYg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
Mjo1NF0gICBnZm46IDAwMDA0ZjNjICBtZm46IDAwMDA0ZjNjDQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMyOjU0XSAgIGdmbjogMDAwMDRmM2QgIG1mbjogMDAwMDRmM2QNCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzI6NTRdICAgZ2ZuOiAwMDAwNGYzZSAgbWZuOiAwMDAwNGYzZQ0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo1NF0gICBnZm46IDAwMDA0ZjNmICBtZm46IDAw
MDA0ZjNmDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjU0XSAgIGdmbjogMDAwMDRmNDAg
IG1mbjogMDAwMDRmNDANCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NTRdICAgZ2ZuOiAw
MDAwNGY0MSAgbWZuOiAwMDAwNGY0MQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo1NF0g
ICBnZm46IDAwMDA0ZjQyICBtZm46IDAwMDA0ZjQyDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMyOjU0XSAgIGdmbjogMDAwMDRmNDMgIG1mbjogMDAwMDRmNDMNCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzI6NTRdICAgZ2ZuOiAwMDAwNGY0NCAgbWZuOiAwMDAwNGY0NA0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMjo1NF0gICBnZm46IDAwMDA0ZjQ1ICBtZm46IDAwMDA0ZjQ1
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjU0XSAgIGdmbjogMDAwMDRmNDYgIG1mbjog
MDAwMDRmNDYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NTRdICAgZ2ZuOiAwMDAwNGY0
NyAgbWZuOiAwMDAwNGY0Nw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo1NF0gICBnZm46
IDAwMDA0ZjQ4ICBtZm46IDAwMDA0ZjQ4DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjU0
XSAgIGdmbjogMDAwMDRmNDkgIG1mbjogMDAwMDRmNDkNCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzI6NTRdICAgZ2ZuOiAwMDAwNGY0YSAgbWZuOiAwMDAwNGY0YQ0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMjo1NF0gICBnZm46IDAwMDA0ZjRiICBtZm46IDAwMDA0ZjRiDQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMyOjU0XSAgIGdmbjogMDAwMDRmNGMgIG1mbjogMDAwMDRm
NGMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NTRdICAgZ2ZuOiAwMDAwNGY0ZCAgbWZu
OiAwMDAwNGY0ZA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo1NF0gICBnZm46IDAwMDA0
ZjRlICBtZm46IDAwMDA0ZjRlDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjU0XSAgIGdm
bjogMDAwMDRmNGYgIG1mbjogMDAwMDRmNGYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6
NTRdICAgZ2ZuOiAwMDAwNGY1MCAgbWZuOiAwMDAwNGY1MA0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMjo1NF0gICBnZm46IDAwMDA0ZjUxICBtZm46IDAwMDA0ZjUxDQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMyOjU0XSAgIGdmbjogMDAwMDRmNTIgIG1mbjogMDAwMDRmNTINCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NTRdICAgZ2ZuOiAwMDAwNGY1MyAgbWZuOiAwMDAw
NGY1Mw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo1NF0gICBnZm46IDAwMDA0ZjU0ICBt
Zm46IDAwMDA0ZjU0DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjU0XSAgIGdmbjogMDAw
MDRmNTUgIG1mbjogMDAwMDRmNTUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NTRdICAg
Z2ZuOiAwMDAwNGY1NiAgbWZuOiAwMDAwNGY1Ng0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
Mjo1NF0gICBnZm46IDAwMDA0ZjU3ICBtZm46IDAwMDA0ZjU3DQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMyOjU0XSAgIGdmbjogMDAwMDRmNTggIG1mbjogMDAwMDRmNTgNCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzI6NTRdICAgZ2ZuOiAwMDAwNGY1OSAgbWZuOiAwMDAwNGY1OQ0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo1NF0gICBnZm46IDAwMDA0ZjVhICBtZm46IDAw
MDA0ZjVhDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjU0XSAgIGdmbjogMDAwMDRmNWIg
IG1mbjogMDAwMDRmNWINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NTRdICAgZ2ZuOiAw
MDAwNGY1YyAgbWZuOiAwMDAwNGY1Yw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo1NF0g
ICBnZm46IDAwMDA0ZjVkICBtZm46IDAwMDA0ZjVkDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMyOjU0XSAgIGdmbjogMDAwMDRmNWUgIG1mbjogMDAwMDRmNWUNCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzI6NTRdICAgZ2ZuOiAwMDAwNGY1ZiAgbWZuOiAwMDAwNGY1Zg0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMjo1NF0gICBnZm46IDAwMDA0ZjYwICBtZm46IDAwMDA0ZjYw
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjU0XSAgIGdmbjogMDAwMDRmNjEgIG1mbjog
MDAwMDRmNjENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NTRdICAgZ2ZuOiAwMDAwNGY2
MiAgbWZuOiAwMDAwNGY2Mg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo1NF0gICBnZm46
IDAwMDA0ZjYzICBtZm46IDAwMDA0ZjYzDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjU0
XSAgIGdmbjogMDAwMDRmNjQgIG1mbjogMDAwMDRmNjQNCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzI6NTRdICAgZ2ZuOiAwMDAwNGY2NSAgbWZuOiAwMDAwNGY2NQ0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMjo1NF0gICBnZm46IDAwMDA0ZjY2ICBtZm46IDAwMDA0ZjY2DQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMyOjU0XSAgIGdmbjogMDAwMDRmNjcgIG1mbjogMDAwMDRm
NjcNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NTRdICAgZ2ZuOiAwMDAwNGY2OCAgbWZu
OiAwMDAwNGY2OA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo1NF0gICBnZm46IDAwMDA0
ZjY5ICBtZm46IDAwMDA0ZjY5DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjU0XSAgIGdm
bjogMDAwMDRmNmEgIG1mbjogMDAwMDRmNmENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6
NTRdICAgZ2ZuOiAwMDAwNGY2YiAgbWZuOiAwMDAwNGY2Yg0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMjo1NF0gICBnZm46IDAwMDA0ZjZjICBtZm46IDAwMDA0ZjZjDQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMyOjU1XSAgIGdmbjogMDAwMDRmNmQgIG1mbjogMDAwMDRmNmQNCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NTVdICAgZ2ZuOiAwMDAwNGY2ZSAgbWZuOiAwMDAw
NGY2ZQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo1NV0gICBnZm46IDAwMDA0ZjZmICBt
Zm46IDAwMDA0ZjZmDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjU1XSAgIGdmbjogMDAw
MDRmNzAgIG1mbjogMDAwMDRmNzANCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NTVdICAg
Z2ZuOiAwMDAwNGY3MSAgbWZuOiAwMDAwNGY3MQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
Mjo1NV0gICBnZm46IDAwMDA0ZjcyICBtZm46IDAwMDA0ZjcyDQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMyOjU1XSAgIGdmbjogMDAwMDRmNzMgIG1mbjogMDAwMDRmNzMNCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzI6NTVdICAgZ2ZuOiAwMDAwNGY3NCAgbWZuOiAwMDAwNGY3NA0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo1NV0gICBnZm46IDAwMDA0Zjc1ICBtZm46IDAw
MDA0Zjc1DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjU1XSAgIGdmbjogMDAwMDRmNzYg
IG1mbjogMDAwMDRmNzYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NTVdICAgZ2ZuOiAw
MDAwNGY3NyAgbWZuOiAwMDAwNGY3Nw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo1NV0g
ICBnZm46IDAwMDA0Zjc4ICBtZm46IDAwMDA0Zjc4DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMyOjU1XSAgIGdmbjogMDAwMDRmNzkgIG1mbjogMDAwMDRmNzkNCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzI6NTVdICAgZ2ZuOiAwMDAwNGY3YSAgbWZuOiAwMDAwNGY3YQ0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMjo1NV0gICBnZm46IDAwMDA0ZjdiICBtZm46IDAwMDA0Zjdi
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjU1XSAgIGdmbjogMDAwMDRmN2MgIG1mbjog
MDAwMDRmN2MNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NTVdICAgZ2ZuOiAwMDAwNGY3
ZCAgbWZuOiAwMDAwNGY3ZA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo1NV0gICBnZm46
IDAwMDA0ZjdlICBtZm46IDAwMDA0ZjdlDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjU1
XSAgIGdmbjogMDAwMDRmN2YgIG1mbjogMDAwMDRmN2YNCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzI6NTVdICAgZ2ZuOiAwMDAwNGY4MCAgbWZuOiAwMDAwNGY4MA0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMjo1NV0gICBnZm46IDAwMDA0ZjgxICBtZm46IDAwMDA0ZjgxDQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMyOjU1XSAgIGdmbjogMDAwMDRmODIgIG1mbjogMDAwMDRm
ODINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NTVdICAgZ2ZuOiAwMDAwNGY4MyAgbWZu
OiAwMDAwNGY4Mw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo1NV0gICBnZm46IDAwMDA0
Zjg0ICBtZm46IDAwMDA0Zjg0DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjU1XSAgIGdm
bjogMDAwMDRmODUgIG1mbjogMDAwMDRmODUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6
NTVdICAgZ2ZuOiAwMDAwNGY4NiAgbWZuOiAwMDAwNGY4Ng0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMjo1NV0gICBnZm46IDAwMDA0Zjg3ICBtZm46IDAwMDA0Zjg3DQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMyOjU1XSAgIGdmbjogMDAwMDRmODggIG1mbjogMDAwMDRmODgNCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NTVdICAgZ2ZuOiAwMDAwNGY4OSAgbWZuOiAwMDAw
NGY4OQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo1NV0gICBnZm46IDAwMDA0ZjhhICBt
Zm46IDAwMDA0ZjhhDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjU1XSAgIGdmbjogMDAw
MDRmOGIgIG1mbjogMDAwMDRmOGINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NTVdICAg
Z2ZuOiAwMDAwNGY4YyAgbWZuOiAwMDAwNGY4Yw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
Mjo1NV0gICBnZm46IDAwMDA0ZjhkICBtZm46IDAwMDA0ZjhkDQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMyOjU1XSAgIGdmbjogMDAwMDRmOGUgIG1mbjogMDAwMDRmOGUNCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzI6NTVdICAgZ2ZuOiAwMDAwNGY4ZiAgbWZuOiAwMDAwNGY4Zg0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo1NV0gICBnZm46IDAwMDA0ZjkwICBtZm46IDAw
MDA0ZjkwDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjU1XSAgIGdmbjogMDAwMDRmOTEg
IG1mbjogMDAwMDRmOTENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NTVdICAgZ2ZuOiAw
MDAwNGY5MiAgbWZuOiAwMDAwNGY5Mg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo1NV0g
ICBnZm46IDAwMDA0ZjkzICBtZm46IDAwMDA0ZjkzDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMyOjU1XSAgIGdmbjogMDAwMDRmOTQgIG1mbjogMDAwMDRmOTQNCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzI6NTVdICAgZ2ZuOiAwMDAwNGY5NSAgbWZuOiAwMDAwNGY5NQ0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMjo1NV0gICBnZm46IDAwMDA0Zjk2ICBtZm46IDAwMDA0Zjk2
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjU1XSAgIGdmbjogMDAwMDRmOTcgIG1mbjog
MDAwMDRmOTcNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NTVdICAgZ2ZuOiAwMDAwNGY5
OCAgbWZuOiAwMDAwNGY5OA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo1NV0gICBnZm46
IDAwMDA0Zjk5ICBtZm46IDAwMDA0Zjk5DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjU1
XSAgIGdmbjogMDAwMDRmOWEgIG1mbjogMDAwMDRmOWENCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzI6NTVdICAgZ2ZuOiAwMDAwNGY5YiAgbWZuOiAwMDAwNGY5Yg0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMjo1NV0gICBnZm46IDAwMDA0ZjljICBtZm46IDAwMDA0ZjljDQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMyOjU1XSAgIGdmbjogMDAwMDRmOWQgIG1mbjogMDAwMDRm
OWQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NTVdICAgZ2ZuOiAwMDAwNGY5ZSAgbWZu
OiAwMDAwNGY5ZQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo1NV0gICBnZm46IDAwMDA0
ZjlmICBtZm46IDAwMDA0ZjlmDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjU1XSAgIGdm
bjogMDAwMDRmYTAgIG1mbjogMDAwMDRmYTANCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6
NTVdICAgZ2ZuOiAwMDAwNGZhMSAgbWZuOiAwMDAwNGZhMQ0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMjo1NV0gICBnZm46IDAwMDA0ZmEyICBtZm46IDAwMDA0ZmEyDQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMyOjU1XSAgIGdmbjogMDAwMDRmYTMgIG1mbjogMDAwMDRmYTMNCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NTVdICAgZ2ZuOiAwMDAwNGZhNCAgbWZuOiAwMDAw
NGZhNA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo1NV0gICBnZm46IDAwMDA0ZmE1ICBt
Zm46IDAwMDA0ZmE1DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjU1XSAgIGdmbjogMDAw
MDRmYTYgIG1mbjogMDAwMDRmYTYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NTVdICAg
Z2ZuOiAwMDAwNGZhNyAgbWZuOiAwMDAwNGZhNw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
Mjo1NV0gICBnZm46IDAwMDA0ZmE4ICBtZm46IDAwMDA0ZmE4DQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMyOjU1XSAgIGdmbjogMDAwMDRmYTkgIG1mbjogMDAwMDRmYTkNCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzI6NTVdICAgZ2ZuOiAwMDAwNGZhYSAgbWZuOiAwMDAwNGZhYQ0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo1NV0gICBnZm46IDAwMDA0ZmFiICBtZm46IDAw
MDA0ZmFiDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjU1XSAgIGdmbjogMDAwMDRmYWMg
IG1mbjogMDAwMDRmYWMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NTVdICAgZ2ZuOiAw
MDAwNGZhZCAgbWZuOiAwMDAwNGZhZA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo1Nl0g
ICBnZm46IDAwMDA0ZmFlICBtZm46IDAwMDA0ZmFlDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMyOjU2XSAgIGdmbjogMDAwMDRmYWYgIG1mbjogMDAwMDRmYWYNCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzI6NTZdICAgZ2ZuOiAwMDAwNGZiMCAgbWZuOiAwMDAwNGZiMA0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMjo1Nl0gICBnZm46IDAwMDA0ZmIxICBtZm46IDAwMDA0ZmIx
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjU2XSAgIGdmbjogMDAwMDRmYjIgIG1mbjog
MDAwMDRmYjINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NTZdICAgZ2ZuOiAwMDAwNGZi
MyAgbWZuOiAwMDAwNGZiMw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo1Nl0gICBnZm46
IDAwMDA0ZmI0ICBtZm46IDAwMDA0ZmI0DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjU2
XSAgIGdmbjogMDAwMDRmYjUgIG1mbjogMDAwMDRmYjUNCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzI6NTZdICAgZ2ZuOiAwMDAwNGZiNiAgbWZuOiAwMDAwNGZiNg0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMjo1Nl0gICBnZm46IDAwMDA0ZmI3ICBtZm46IDAwMDA0ZmI3DQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMyOjU2XSAgIGdmbjogMDAwMDRmYjggIG1mbjogMDAwMDRm
YjgNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NTZdICAgZ2ZuOiAwMDAwNGZiOSAgbWZu
OiAwMDAwNGZiOQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo1Nl0gICBnZm46IDAwMDA0
ZmJhICBtZm46IDAwMDA0ZmJhDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjU2XSAgIGdm
bjogMDAwMDRmYmIgIG1mbjogMDAwMDRmYmINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6
NTZdICAgZ2ZuOiAwMDAwNGZiYyAgbWZuOiAwMDAwNGZiYw0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMjo1Nl0gICBnZm46IDAwMDA0ZmJkICBtZm46IDAwMDA0ZmJkDQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMyOjU2XSAgIGdmbjogMDAwMDRmYmUgIG1mbjogMDAwMDRmYmUNCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NTZdICAgZ2ZuOiAwMDAwNGZiZiAgbWZuOiAwMDAw
NGZiZg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo1Nl0gICBnZm46IDAwMDA0ZmMwICBt
Zm46IDAwMDA0ZmMwDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjU2XSAgIGdmbjogMDAw
MDRmYzEgIG1mbjogMDAwMDRmYzENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NTZdICAg
Z2ZuOiAwMDAwNGZjMiAgbWZuOiAwMDAwNGZjMg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
Mjo1Nl0gICBnZm46IDAwMDA0ZmMzICBtZm46IDAwMDA0ZmMzDQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMyOjU2XSAgIGdmbjogMDAwMDRmYzQgIG1mbjogMDAwMDRmYzQNCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzI6NTZdICAgZ2ZuOiAwMDAwNGZjNSAgbWZuOiAwMDAwNGZjNQ0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo1Nl0gICBnZm46IDAwMDA0ZmM2ICBtZm46IDAw
MDA0ZmM2DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjU2XSAgIGdmbjogMDAwMDRmYzcg
IG1mbjogMDAwMDRmYzcNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NTZdICAgZ2ZuOiAw
MDAwNGZjOCAgbWZuOiAwMDAwNGZjOA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo1Nl0g
ICBnZm46IDAwMDA0ZmM5ICBtZm46IDAwMDA0ZmM5DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMyOjU2XSAgIGdmbjogMDAwMDRmY2EgIG1mbjogMDAwMDRmY2ENCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzI6NTZdICAgZ2ZuOiAwMDAwNGZjYiAgbWZuOiAwMDAwNGZjYg0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMjo1Nl0gICBnZm46IDAwMDA0ZmNjICBtZm46IDAwMDA0ZmNj
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjU2XSAgIGdmbjogMDAwMDRmY2QgIG1mbjog
MDAwMDRmY2QNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NTZdICAgZ2ZuOiAwMDAwNGZj
ZSAgbWZuOiAwMDAwNGZjZQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo1Nl0gICBnZm46
IDAwMDA0ZmNmICBtZm46IDAwMDA0ZmNmDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjU2
XSAgIGdmbjogMDAwMDRmZDAgIG1mbjogMDAwMDRmZDANCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzI6NTZdICAgZ2ZuOiAwMDAwNGZkMSAgbWZuOiAwMDAwNGZkMQ0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMjo1Nl0gICBnZm46IDAwMDA0ZmQyICBtZm46IDAwMDA0ZmQyDQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMyOjU2XSAgIGdmbjogMDAwMDRmZDMgIG1mbjogMDAwMDRm
ZDMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NTZdICAgZ2ZuOiAwMDAwNGZkNCAgbWZu
OiAwMDAwNGZkNA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo1Nl0gICBnZm46IDAwMDA0
ZmQ1ICBtZm46IDAwMDA0ZmQ1DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjU2XSAgIGdm
bjogMDAwMDRmZDYgIG1mbjogMDAwMDRmZDYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6
NTZdICAgZ2ZuOiAwMDAwNGZkNyAgbWZuOiAwMDAwNGZkNw0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMjo1Nl0gICBnZm46IDAwMDA0ZmQ4ICBtZm46IDAwMDA0ZmQ4DQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMyOjU2XSAgIGdmbjogMDAwMDRmZDkgIG1mbjogMDAwMDRmZDkNCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NTZdICAgZ2ZuOiAwMDAwNGZkYSAgbWZuOiAwMDAw
NGZkYQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo1Nl0gICBnZm46IDAwMDA0ZmRiICBt
Zm46IDAwMDA0ZmRiDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjU2XSAgIGdmbjogMDAw
MDRmZGMgIG1mbjogMDAwMDRmZGMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NTZdICAg
Z2ZuOiAwMDAwNGZkZCAgbWZuOiAwMDAwNGZkZA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
Mjo1Nl0gICBnZm46IDAwMDA0ZmRlICBtZm46IDAwMDA0ZmRlDQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMyOjU2XSAgIGdmbjogMDAwMDRmZGYgIG1mbjogMDAwMDRmZGYNCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzI6NTZdICAgZ2ZuOiAwMDAwNGZlMCAgbWZuOiAwMDAwNGZlMA0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo1Nl0gICBnZm46IDAwMDA0ZmUxICBtZm46IDAw
MDA0ZmUxDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjU2XSAgIGdmbjogMDAwMDRmZTIg
IG1mbjogMDAwMDRmZTINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NTZdICAgZ2ZuOiAw
MDAwNGZlMyAgbWZuOiAwMDAwNGZlMw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo1Nl0g
ICBnZm46IDAwMDA0ZmU0ICBtZm46IDAwMDA0ZmU0DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMyOjU2XSAgIGdmbjogMDAwMDRmZTUgIG1mbjogMDAwMDRmZTUNCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzI6NTZdICAgZ2ZuOiAwMDAwNGZlNiAgbWZuOiAwMDAwNGZlNg0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMjo1Nl0gICBnZm46IDAwMDA0ZmU3ICBtZm46IDAwMDA0ZmU3
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjU2XSAgIGdmbjogMDAwMDRmZTggIG1mbjog
MDAwMDRmZTgNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NTZdICAgZ2ZuOiAwMDAwNGZl
OSAgbWZuOiAwMDAwNGZlOQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo1Nl0gICBnZm46
IDAwMDA0ZmVhICBtZm46IDAwMDA0ZmVhDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjU2
XSAgIGdmbjogMDAwMDRmZWIgIG1mbjogMDAwMDRmZWINCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzI6NTZdICAgZ2ZuOiAwMDAwNGZlYyAgbWZuOiAwMDAwNGZlYw0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMjo1Nl0gICBnZm46IDAwMDA0ZmVkICBtZm46IDAwMDA0ZmVkDQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMyOjU3XSAgIGdmbjogMDAwMDRmZWUgIG1mbjogMDAwMDRm
ZWUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NTddICAgZ2ZuOiAwMDAwNGZlZiAgbWZu
OiAwMDAwNGZlZg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo1N10gICBnZm46IDAwMDA0
ZmYwICBtZm46IDAwMDA0ZmYwDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjU3XSAgIGdm
bjogMDAwMDRmZjEgIG1mbjogMDAwMDRmZjENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6
NTddICAgZ2ZuOiAwMDAwNGZmMiAgbWZuOiAwMDAwNGZmMg0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMjo1N10gICBnZm46IDAwMDA0ZmYzICBtZm46IDAwMDA0ZmYzDQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMyOjU3XSAgIGdmbjogMDAwMDRmZjQgIG1mbjogMDAwMDRmZjQNCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NTddICAgZ2ZuOiAwMDAwNGZmNSAgbWZuOiAwMDAw
NGZmNQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo1N10gICBnZm46IDAwMDA0ZmY2ICBt
Zm46IDAwMDA0ZmY2DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjU3XSAgIGdmbjogMDAw
MDRmZjcgIG1mbjogMDAwMDRmZjcNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NTddICAg
Z2ZuOiAwMDAwNGZmOCAgbWZuOiAwMDAwNGZmOA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
Mjo1N10gICBnZm46IDAwMDA0ZmY5ICBtZm46IDAwMDA0ZmY5DQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMyOjU3XSAgIGdmbjogMDAwMDRmZmEgIG1mbjogMDAwMDRmZmENCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzI6NTddICAgZ2ZuOiAwMDAwNGZmYiAgbWZuOiAwMDAwNGZmYg0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo1N10gICBnZm46IDAwMDA0ZmZjICBtZm46IDAw
MDA0ZmZjDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjU3XSAgIGdmbjogMDAwMDRmZmQg
IG1mbjogMDAwMDRmZmQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NTddICAgZ2ZuOiAw
MDAwNGZmZSAgbWZuOiAwMDAwNGZmZQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo1N10g
ICBnZm46IDAwMDA0ZmZmICBtZm46IDAwMDA0ZmZmDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMyOjU3XSAgIGdmbjogMDAwMDUwMDAgIG1mbjogMDAwMDUwMDANCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzI6NTddICAgZ2ZuOiAwMDAwNTAwMSAgbWZuOiAwMDAwNTAwMQ0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMjo1N10gICBnZm46IDAwMDA1MDAyICBtZm46IDAwMDA1MDAy
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjU3XSAgIGdmbjogMDAwMDUwMDMgIG1mbjog
MDAwMDUwMDMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NTddICAgZ2ZuOiAwMDAwNTAw
NCAgbWZuOiAwMDAwNTAwNA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo1N10gICBnZm46
IDAwMDA1MDA1ICBtZm46IDAwMDA1MDA1DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjU3
XSAgIGdmbjogMDAwMDUwMDYgIG1mbjogMDAwMDUwMDYNCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzI6NTddICAgZ2ZuOiAwMDAwNTAwNyAgbWZuOiAwMDAwNTAwNw0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMjo1N10gICBnZm46IDAwMDA1MDA4ICBtZm46IDAwMDA1MDA4DQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMyOjU3XSAgIGdmbjogMDAwMDUwMDkgIG1mbjogMDAwMDUw
MDkNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NTddICAgZ2ZuOiAwMDAwNTAwYSAgbWZu
OiAwMDAwNTAwYQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo1N10gICBnZm46IDAwMDA1
MDBiICBtZm46IDAwMDA1MDBiDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjU3XSAgIGdm
bjogMDAwMDUwMGMgIG1mbjogMDAwMDUwMGMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6
NTddICAgZ2ZuOiAwMDAwNTAwZCAgbWZuOiAwMDAwNTAwZA0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMjo1N10gICBnZm46IDAwMDA1MDBlICBtZm46IDAwMDA1MDBlDQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMyOjU3XSAgIGdmbjogMDAwMDUwMGYgIG1mbjogMDAwMDUwMGYNCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NTddICAgZ2ZuOiAwMDAwNTAxMCAgbWZuOiAwMDAw
NTAxMA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo1N10gICBnZm46IDAwMDA1MDExICBt
Zm46IDAwMDA1MDExDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjU3XSAgIGdmbjogMDAw
MDUwMTIgIG1mbjogMDAwMDUwMTINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NTddICAg
Z2ZuOiAwMDAwNTAxMyAgbWZuOiAwMDAwNTAxMw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
Mjo1N10gICBnZm46IDAwMDA1MDE0ICBtZm46IDAwMDA1MDE0DQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMyOjU3XSAgIGdmbjogMDAwMDUwMTUgIG1mbjogMDAwMDUwMTUNCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzI6NTddICAgZ2ZuOiAwMDAwNTAxNiAgbWZuOiAwMDAwNTAxNg0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo1N10gICBnZm46IDAwMDA1MDE3ICBtZm46IDAw
MDA1MDE3DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjU3XSAgIGdmbjogMDAwMDUwMTgg
IG1mbjogMDAwMDUwMTgNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NTddICAgZ2ZuOiAw
MDAwNTAxOSAgbWZuOiAwMDAwNTAxOQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo1N10g
ICBnZm46IDAwMDA1MDFhICBtZm46IDAwMDA1MDFhDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMyOjU3XSAgIGdmbjogMDAwMDUwMWIgIG1mbjogMDAwMDUwMWINCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzI6NTddICAgZ2ZuOiAwMDAwNTAxYyAgbWZuOiAwMDAwNTAxYw0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMjo1N10gICBnZm46IDAwMDA1MDFkICBtZm46IDAwMDA1MDFk
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjU3XSAgIGdmbjogMDAwMDUwMWUgIG1mbjog
MDAwMDUwMWUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NTddICAgZ2ZuOiAwMDAwNTAx
ZiAgbWZuOiAwMDAwNTAxZg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo1N10gICBnZm46
IDAwMDA1MDIwICBtZm46IDAwMDA1MDIwDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjU3
XSAgIGdmbjogMDAwMDUwMjEgIG1mbjogMDAwMDUwMjENCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzI6NTddICAgZ2ZuOiAwMDAwNTAyMiAgbWZuOiAwMDAwNTAyMg0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMjo1N10gICBnZm46IDAwMDA1MDIzICBtZm46IDAwMDA1MDIzDQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMyOjU3XSAgIGdmbjogMDAwMDUwMjQgIG1mbjogMDAwMDUw
MjQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NTddICAgZ2ZuOiAwMDAwNTAyNSAgbWZu
OiAwMDAwNTAyNQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo1N10gICBnZm46IDAwMDA1
MDI2ICBtZm46IDAwMDA1MDI2DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjU3XSAgIGdm
bjogMDAwMDUwMjcgIG1mbjogMDAwMDUwMjcNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6
NTddICAgZ2ZuOiAwMDAwNTAyOCAgbWZuOiAwMDAwNTAyOA0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMjo1N10gICBnZm46IDAwMDA1MDI5ICBtZm46IDAwMDA1MDI5DQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMyOjU3XSAgIGdmbjogMDAwMDUwMmEgIG1mbjogMDAwMDUwMmENCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NTddICAgZ2ZuOiAwMDAwNTAyYiAgbWZuOiAwMDAw
NTAyYg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo1N10gICBnZm46IDAwMDA1MDJjICBt
Zm46IDAwMDA1MDJjDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjU3XSAgIGdmbjogMDAw
MDUwMmQgIG1mbjogMDAwMDUwMmQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NThdICAg
Z2ZuOiAwMDAwNTAyZSAgbWZuOiAwMDAwNTAyZQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
Mjo1OF0gICBnZm46IDAwMDA1MDJmICBtZm46IDAwMDA1MDJmDQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMyOjU4XSAgIGdmbjogMDAwMDUwMzAgIG1mbjogMDAwMDUwMzANCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzI6NThdICAgZ2ZuOiAwMDAwNTAzMSAgbWZuOiAwMDAwNTAzMQ0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo1OF0gICBnZm46IDAwMDA1MDMyICBtZm46IDAw
MDA1MDMyDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjU4XSAgIGdmbjogMDAwMDUwMzMg
IG1mbjogMDAwMDUwMzMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NThdICAgZ2ZuOiAw
MDAwNTAzNCAgbWZuOiAwMDAwNTAzNA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo1OF0g
ICBnZm46IDAwMDA1MDM1ICBtZm46IDAwMDA1MDM1DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMyOjU4XSAgIGdmbjogMDAwMDUwMzYgIG1mbjogMDAwMDUwMzYNCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzI6NThdICAgZ2ZuOiAwMDAwNTAzNyAgbWZuOiAwMDAwNTAzNw0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMjo1OF0gICBnZm46IDAwMDA1MDM4ICBtZm46IDAwMDA1MDM4
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjU4XSAgIGdmbjogMDAwMDUwMzkgIG1mbjog
MDAwMDUwMzkNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NThdICAgZ2ZuOiAwMDAwNTAz
YSAgbWZuOiAwMDAwNTAzYQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo1OF0gICBnZm46
IDAwMDA1MDNiICBtZm46IDAwMDA1MDNiDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjU4
XSAgIGdmbjogMDAwMDUwM2MgIG1mbjogMDAwMDUwM2MNCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzI6NThdICAgZ2ZuOiAwMDAwNTAzZCAgbWZuOiAwMDAwNTAzZA0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMjo1OF0gICBnZm46IDAwMDA1MDNlICBtZm46IDAwMDA1MDNlDQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMyOjU4XSAgIGdmbjogMDAwMDUwM2YgIG1mbjogMDAwMDUw
M2YNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NThdICAgZ2ZuOiAwMDAwNTA0MCAgbWZu
OiAwMDAwNTA0MA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo1OF0gICBnZm46IDAwMDA1
MDQxICBtZm46IDAwMDA1MDQxDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjU4XSAgIGdm
bjogMDAwMDUwNDIgIG1mbjogMDAwMDUwNDINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6
NThdICAgZ2ZuOiAwMDAwNTA0MyAgbWZuOiAwMDAwNTA0Mw0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMjo1OF0gICBnZm46IDAwMDA1MDQ0ICBtZm46IDAwMDA1MDQ0DQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMyOjU4XSAgIGdmbjogMDAwMDUwNDUgIG1mbjogMDAwMDUwNDUNCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NThdICAgZ2ZuOiAwMDAwNTA0NiAgbWZuOiAwMDAw
NTA0Ng0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo1OF0gICBnZm46IDAwMDA1MDQ3ICBt
Zm46IDAwMDA1MDQ3DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjU4XSAgIGdmbjogMDAw
MDUwNDggIG1mbjogMDAwMDUwNDgNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NThdICAg
Z2ZuOiAwMDAwNTA0OSAgbWZuOiAwMDAwNTA0OQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
Mjo1OF0gICBnZm46IDAwMDA1MDRhICBtZm46IDAwMDA1MDRhDQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMyOjU4XSAgIGdmbjogMDAwMDUwNGIgIG1mbjogMDAwMDUwNGINCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzI6NThdICAgZ2ZuOiAwMDAwNTA0YyAgbWZuOiAwMDAwNTA0Yw0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo1OF0gICBnZm46IDAwMDA1MDRkICBtZm46IDAw
MDA1MDRkDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjU4XSAgIGdmbjogMDAwMDUwNGUg
IG1mbjogMDAwMDUwNGUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NThdICAgZ2ZuOiAw
MDAwNTA0ZiAgbWZuOiAwMDAwNTA0Zg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo1OF0g
ICBnZm46IDAwMDA1MDUwICBtZm46IDAwMDA1MDUwDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMyOjU4XSAgIGdmbjogMDAwMDUwNTEgIG1mbjogMDAwMDUwNTENCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzI6NThdICAgZ2ZuOiAwMDAwNTA1MiAgbWZuOiAwMDAwNTA1Mg0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMjo1OF0gICBnZm46IDAwMDA1MDUzICBtZm46IDAwMDA1MDUz
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjU4XSAgIGdmbjogMDAwMDUwNTQgIG1mbjog
MDAwMDUwNTQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NThdICAgZ2ZuOiAwMDAwNTA1
NSAgbWZuOiAwMDAwNTA1NQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo1OF0gICBnZm46
IDAwMDA1MDU2ICBtZm46IDAwMDA1MDU2DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjU4
XSAgIGdmbjogMDAwMDUwNTcgIG1mbjogMDAwMDUwNTcNCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzI6NThdICAgZ2ZuOiAwMDAwNTA1OCAgbWZuOiAwMDAwNTA1OA0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMjo1OF0gICBnZm46IDAwMDA1MDU5ICBtZm46IDAwMDA1MDU5DQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMyOjU4XSAgIGdmbjogMDAwMDUwNWEgIG1mbjogMDAwMDUw
NWENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NThdICAgZ2ZuOiAwMDAwNTA1YiAgbWZu
OiAwMDAwNTA1Yg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo1OF0gICBnZm46IDAwMDA1
MDVjICBtZm46IDAwMDA1MDVjDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjU4XSAgIGdm
bjogMDAwMDUwNWQgIG1mbjogMDAwMDUwNWQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6
NThdICAgZ2ZuOiAwMDAwNTA1ZSAgbWZuOiAwMDAwNTA1ZQ0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMjo1OF0gICBnZm46IDAwMDA1MDVmICBtZm46IDAwMDA1MDVmDQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMyOjU4XSAgIGdmbjogMDAwMDUwNjAgIG1mbjogMDAwMDUwNjANCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NThdICAgZ2ZuOiAwMDAwNTA2MSAgbWZuOiAwMDAw
NTA2MQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo1OF0gICBnZm46IDAwMDA1MDYyICBt
Zm46IDAwMDA1MDYyDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjU4XSAgIGdmbjogMDAw
MDUwNjMgIG1mbjogMDAwMDUwNjMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NThdICAg
Z2ZuOiAwMDAwNTA2NCAgbWZuOiAwMDAwNTA2NA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
Mjo1OF0gICBnZm46IDAwMDA1MDY1ICBtZm46IDAwMDA1MDY1DQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMyOjU4XSAgIGdmbjogMDAwMDUwNjYgIG1mbjogMDAwMDUwNjYNCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzI6NThdICAgZ2ZuOiAwMDAwNTA2NyAgbWZuOiAwMDAwNTA2Nw0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo1OF0gICBnZm46IDAwMDA1MDY4ICBtZm46IDAw
MDA1MDY4DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjU4XSAgIGdmbjogMDAwMDUwNjkg
IG1mbjogMDAwMDUwNjkNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NThdICAgZ2ZuOiAw
MDAwNTA2YSAgbWZuOiAwMDAwNTA2YQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo1OF0g
ICBnZm46IDAwMDA1MDZiICBtZm46IDAwMDA1MDZiDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMyOjU4XSAgIGdmbjogMDAwMDUwNmMgIG1mbjogMDAwMDUwNmMNCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzI6NThdICAgZ2ZuOiAwMDAwNTA2ZCAgbWZuOiAwMDAwNTA2ZA0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMjo1OV0gICBnZm46IDAwMDA1MDZlICBtZm46IDAwMDA1MDZl
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjU5XSAgIGdmbjogMDAwMDUwNmYgIG1mbjog
MDAwMDUwNmYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NTldICAgZ2ZuOiAwMDAwNTA3
MCAgbWZuOiAwMDAwNTA3MA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo1OV0gICBnZm46
IDAwMDA1MDcxICBtZm46IDAwMDA1MDcxDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjU5
XSAgIGdmbjogMDAwMDUwNzIgIG1mbjogMDAwMDUwNzINCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzI6NTldICAgZ2ZuOiAwMDAwNTA3MyAgbWZuOiAwMDAwNTA3Mw0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMjo1OV0gICBnZm46IDAwMDA1MDc0ICBtZm46IDAwMDA1MDc0DQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMyOjU5XSAgIGdmbjogMDAwMDUwNzUgIG1mbjogMDAwMDUw
NzUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NTldICAgZ2ZuOiAwMDAwNTA3NiAgbWZu
OiAwMDAwNTA3Ng0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo1OV0gICBnZm46IDAwMDA1
MDc3ICBtZm46IDAwMDA1MDc3DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjU5XSAgIGdm
bjogMDAwMDUwNzggIG1mbjogMDAwMDUwNzgNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6
NTldICAgZ2ZuOiAwMDAwNTA3OSAgbWZuOiAwMDAwNTA3OQ0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMjo1OV0gICBnZm46IDAwMDA1MDdhICBtZm46IDAwMDA1MDdhDQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMyOjU5XSAgIGdmbjogMDAwMDUwN2IgIG1mbjogMDAwMDUwN2INCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NTldICAgZ2ZuOiAwMDAwNTA3YyAgbWZuOiAwMDAw
NTA3Yw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo1OV0gICBnZm46IDAwMDA1MDdkICBt
Zm46IDAwMDA1MDdkDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjU5XSAgIGdmbjogMDAw
MDUwN2UgIG1mbjogMDAwMDUwN2UNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NTldICAg
Z2ZuOiAwMDAwNTA3ZiAgbWZuOiAwMDAwNTA3Zg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
Mjo1OV0gICBnZm46IDAwMDA1MDgwICBtZm46IDAwMDA1MDgwDQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMyOjU5XSAgIGdmbjogMDAwMDUwODEgIG1mbjogMDAwMDUwODENCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzI6NTldICAgZ2ZuOiAwMDAwNTA4MiAgbWZuOiAwMDAwNTA4Mg0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo1OV0gICBnZm46IDAwMDA1MDgzICBtZm46IDAw
MDA1MDgzDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjU5XSAgIGdmbjogMDAwMDUwODQg
IG1mbjogMDAwMDUwODQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NTldICAgZ2ZuOiAw
MDAwNTA4NSAgbWZuOiAwMDAwNTA4NQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo1OV0g
ICBnZm46IDAwMDA1MDg2ICBtZm46IDAwMDA1MDg2DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMyOjU5XSAgIGdmbjogMDAwMDUwODcgIG1mbjogMDAwMDUwODcNCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzI6NTldICAgZ2ZuOiAwMDAwNTA4OCAgbWZuOiAwMDAwNTA4OA0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMjo1OV0gICBnZm46IDAwMDA1MDg5ICBtZm46IDAwMDA1MDg5
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjU5XSAgIGdmbjogMDAwMDUwOGEgIG1mbjog
MDAwMDUwOGENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NTldICAgZ2ZuOiAwMDAwNTA4
YiAgbWZuOiAwMDAwNTA4Yg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo1OV0gICBnZm46
IDAwMDA1MDhjICBtZm46IDAwMDA1MDhjDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjU5
XSAgIGdmbjogMDAwMDUwOGQgIG1mbjogMDAwMDUwOGQNCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzI6NTldICAgZ2ZuOiAwMDAwNTA4ZSAgbWZuOiAwMDAwNTA4ZQ0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMjo1OV0gICBnZm46IDAwMDA1MDhmICBtZm46IDAwMDA1MDhmDQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMyOjU5XSAgIGdmbjogMDAwMDUwOTAgIG1mbjogMDAwMDUw
OTANCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NTldICAgZ2ZuOiAwMDAwNTA5MSAgbWZu
OiAwMDAwNTA5MQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo1OV0gICBnZm46IDAwMDA1
MDkyICBtZm46IDAwMDA1MDkyDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjU5XSAgIGdm
bjogMDAwMDUwOTMgIG1mbjogMDAwMDUwOTMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6
NTldICAgZ2ZuOiAwMDAwNTA5NCAgbWZuOiAwMDAwNTA5NA0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMjo1OV0gICBnZm46IDAwMDA1MDk1ICBtZm46IDAwMDA1MDk1DQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMyOjU5XSAgIGdmbjogMDAwMDUwOTYgIG1mbjogMDAwMDUwOTYNCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NTldICAgZ2ZuOiAwMDAwNTA5NyAgbWZuOiAwMDAw
NTA5Nw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo1OV0gICBnZm46IDAwMDA1MDk4ICBt
Zm46IDAwMDA1MDk4DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjU5XSAgIGdmbjogMDAw
MDUwOTkgIG1mbjogMDAwMDUwOTkNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NTldICAg
Z2ZuOiAwMDAwNTA5YSAgbWZuOiAwMDAwNTA5YQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
Mjo1OV0gICBnZm46IDAwMDA1MDliICBtZm46IDAwMDA1MDliDQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMyOjU5XSAgIGdmbjogMDAwMDUwOWMgIG1mbjogMDAwMDUwOWMNCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzI6NTldICAgZ2ZuOiAwMDAwNTA5ZCAgbWZuOiAwMDAwNTA5ZA0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo1OV0gICBnZm46IDAwMDA1MDllICBtZm46IDAw
MDA1MDllDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjU5XSAgIGdmbjogMDAwMDUwOWYg
IG1mbjogMDAwMDUwOWYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NTldICAgZ2ZuOiAw
MDAwNTBhMCAgbWZuOiAwMDAwNTBhMA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo1OV0g
ICBnZm46IDAwMDA1MGExICBtZm46IDAwMDA1MGExDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMyOjU5XSAgIGdmbjogMDAwMDUwYTIgIG1mbjogMDAwMDUwYTINCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzI6NTldICAgZ2ZuOiAwMDAwNTBhMyAgbWZuOiAwMDAwNTBhMw0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMjo1OV0gICBnZm46IDAwMDA1MGE0ICBtZm46IDAwMDA1MGE0
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjU5XSAgIGdmbjogMDAwMDUwYTUgIG1mbjog
MDAwMDUwYTUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NTldICAgZ2ZuOiAwMDAwNTBh
NiAgbWZuOiAwMDAwNTBhNg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo1OV0gICBnZm46
IDAwMDA1MGE3ICBtZm46IDAwMDA1MGE3DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjU5
XSAgIGdmbjogMDAwMDUwYTggIG1mbjogMDAwMDUwYTgNCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzI6NTldICAgZ2ZuOiAwMDAwNTBhOSAgbWZuOiAwMDAwNTBhOQ0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMjo1OV0gICBnZm46IDAwMDA1MGFhICBtZm46IDAwMDA1MGFhDQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMyOjU5XSAgIGdmbjogMDAwMDUwYWIgIG1mbjogMDAwMDUw
YWINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NTldICAgZ2ZuOiAwMDAwNTBhYyAgbWZu
OiAwMDAwNTBhYw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo1OV0gICBnZm46IDAwMDA1
MGFkICBtZm46IDAwMDA1MGFkDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjAwXSAgIGdm
bjogMDAwMDUwYWUgIG1mbjogMDAwMDUwYWUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6
MDBdICAgZ2ZuOiAwMDAwNTBhZiAgbWZuOiAwMDAwNTBhZg0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMzowMF0gICBnZm46IDAwMDA1MGIwICBtZm46IDAwMDA1MGIwDQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMzOjAwXSAgIGdmbjogMDAwMDUwYjEgIG1mbjogMDAwMDUwYjENCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MDBdICAgZ2ZuOiAwMDAwNTBiMiAgbWZuOiAwMDAw
NTBiMg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzowMF0gICBnZm46IDAwMDA1MGIzICBt
Zm46IDAwMDA1MGIzDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjAwXSAgIGdmbjogMDAw
MDUwYjQgIG1mbjogMDAwMDUwYjQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MDBdICAg
Z2ZuOiAwMDAwNTBiNSAgbWZuOiAwMDAwNTBiNQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
MzowMF0gICBnZm46IDAwMDA1MGI2ICBtZm46IDAwMDA1MGI2DQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMzOjAwXSAgIGdmbjogMDAwMDUwYjcgIG1mbjogMDAwMDUwYjcNCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzM6MDBdICAgZ2ZuOiAwMDAwNTBiOCAgbWZuOiAwMDAwNTBiOA0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzowMF0gICBnZm46IDAwMDA1MGI5ICBtZm46IDAw
MDA1MGI5DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjAwXSAgIGdmbjogMDAwMDUwYmEg
IG1mbjogMDAwMDUwYmENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MDBdICAgZ2ZuOiAw
MDAwNTBiYiAgbWZuOiAwMDAwNTBiYg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzowMF0g
ICBnZm46IDAwMDA1MGJjICBtZm46IDAwMDA1MGJjDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMzOjAwXSAgIGdmbjogMDAwMDUwYmQgIG1mbjogMDAwMDUwYmQNCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzM6MDBdICAgZ2ZuOiAwMDAwNTBiZSAgbWZuOiAwMDAwNTBiZQ0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMzowMF0gICBnZm46IDAwMDA1MGJmICBtZm46IDAwMDA1MGJm
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjAwXSAgIGdmbjogMDAwMDUwYzAgIG1mbjog
MDAwMDUwYzANCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MDBdICAgZ2ZuOiAwMDAwNTBj
MSAgbWZuOiAwMDAwNTBjMQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzowMF0gICBnZm46
IDAwMDA1MGMyICBtZm46IDAwMDA1MGMyDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjAw
XSAgIGdmbjogMDAwMDUwYzMgIG1mbjogMDAwMDUwYzMNCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzM6MDBdICAgZ2ZuOiAwMDAwNTBjNCAgbWZuOiAwMDAwNTBjNA0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMzowMF0gICBnZm46IDAwMDA1MGM1ICBtZm46IDAwMDA1MGM1DQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMzOjAwXSAgIGdmbjogMDAwMDUwYzYgIG1mbjogMDAwMDUw
YzYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MDBdICAgZ2ZuOiAwMDAwNTBjNyAgbWZu
OiAwMDAwNTBjNw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzowMF0gICBnZm46IDAwMDA1
MGM4ICBtZm46IDAwMDA1MGM4DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjAwXSAgIGdm
bjogMDAwMDUwYzkgIG1mbjogMDAwMDUwYzkNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6
MDBdICAgZ2ZuOiAwMDAwNTBjYSAgbWZuOiAwMDAwNTBjYQ0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMzowMF0gICBnZm46IDAwMDA1MGNiICBtZm46IDAwMDA1MGNiDQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMzOjAwXSAgIGdmbjogMDAwMDUwY2MgIG1mbjogMDAwMDUwY2MNCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MDBdICAgZ2ZuOiAwMDAwNTBjZCAgbWZuOiAwMDAw
NTBjZA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzowMF0gICBnZm46IDAwMDA1MGNlICBt
Zm46IDAwMDA1MGNlDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjAwXSAgIGdmbjogMDAw
MDUwY2YgIG1mbjogMDAwMDUwY2YNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MDBdICAg
Z2ZuOiAwMDAwNTBkMCAgbWZuOiAwMDAwNTBkMA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
MzowMF0gICBnZm46IDAwMDA1MGQxICBtZm46IDAwMDA1MGQxDQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMzOjAwXSAgIGdmbjogMDAwMDUwZDIgIG1mbjogMDAwMDUwZDINCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzM6MDBdICAgZ2ZuOiAwMDAwNTBkMyAgbWZuOiAwMDAwNTBkMw0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzowMF0gICBnZm46IDAwMDA1MGQ0ICBtZm46IDAw
MDA1MGQ0DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjAwXSAgIGdmbjogMDAwMDUwZDUg
IG1mbjogMDAwMDUwZDUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MDBdICAgZ2ZuOiAw
MDAwNTBkNiAgbWZuOiAwMDAwNTBkNg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzowMF0g
ICBnZm46IDAwMDA1MGQ3ICBtZm46IDAwMDA1MGQ3DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMzOjAwXSAgIGdmbjogMDAwMDUwZDggIG1mbjogMDAwMDUwZDgNCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzM6MDBdICAgZ2ZuOiAwMDAwNTBkOSAgbWZuOiAwMDAwNTBkOQ0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMzowMF0gICBnZm46IDAwMDA1MGRhICBtZm46IDAwMDA1MGRh
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjAwXSAgIGdmbjogMDAwMDUwZGIgIG1mbjog
MDAwMDUwZGINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MDBdICAgZ2ZuOiAwMDAwNTBk
YyAgbWZuOiAwMDAwNTBkYw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzowMF0gICBnZm46
IDAwMDA1MGRkICBtZm46IDAwMDA1MGRkDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjAw
XSAgIGdmbjogMDAwMDUwZGUgIG1mbjogMDAwMDUwZGUNCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzM6MDBdICAgZ2ZuOiAwMDAwNTBkZiAgbWZuOiAwMDAwNTBkZg0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMzowMF0gICBnZm46IDAwMDA1MGUwICBtZm46IDAwMDA1MGUwDQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMzOjAwXSAgIGdmbjogMDAwMDUwZTEgIG1mbjogMDAwMDUw
ZTENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MDBdICAgZ2ZuOiAwMDAwNTBlMiAgbWZu
OiAwMDAwNTBlMg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzowMF0gICBnZm46IDAwMDA1
MGUzICBtZm46IDAwMDA1MGUzDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjAwXSAgIGdm
bjogMDAwMDUwZTQgIG1mbjogMDAwMDUwZTQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6
MDBdICAgZ2ZuOiAwMDAwNTBlNSAgbWZuOiAwMDAwNTBlNQ0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMzowMF0gICBnZm46IDAwMDA1MGU2ICBtZm46IDAwMDA1MGU2DQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMzOjAwXSAgIGdmbjogMDAwMDUwZTcgIG1mbjogMDAwMDUwZTcNCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MDBdICAgZ2ZuOiAwMDAwNTBlOCAgbWZuOiAwMDAw
NTBlOA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzowMF0gICBnZm46IDAwMDA1MGU5ICBt
Zm46IDAwMDA1MGU5DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjAwXSAgIGdmbjogMDAw
MDUwZWEgIG1mbjogMDAwMDUwZWENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MDBdICAg
Z2ZuOiAwMDAwNTBlYiAgbWZuOiAwMDAwNTBlYg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
MzowMF0gICBnZm46IDAwMDA1MGVjICBtZm46IDAwMDA1MGVjDQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMzOjAwXSAgIGdmbjogMDAwMDUwZWQgIG1mbjogMDAwMDUwZWQNCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzM6MDFdICAgZ2ZuOiAwMDAwNTBlZSAgbWZuOiAwMDAwNTBlZQ0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzowMV0gICBnZm46IDAwMDA1MGVmICBtZm46IDAw
MDA1MGVmDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjAxXSAgIGdmbjogMDAwMDUwZjAg
IG1mbjogMDAwMDUwZjANCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MDFdICAgZ2ZuOiAw
MDAwNTBmMSAgbWZuOiAwMDAwNTBmMQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzowMV0g
ICBnZm46IDAwMDA1MGYyICBtZm46IDAwMDA1MGYyDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMzOjAxXSAgIGdmbjogMDAwMDUwZjMgIG1mbjogMDAwMDUwZjMNCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzM6MDFdICAgZ2ZuOiAwMDAwNTBmNCAgbWZuOiAwMDAwNTBmNA0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMzowMV0gICBnZm46IDAwMDA1MGY1ICBtZm46IDAwMDA1MGY1
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjAxXSAgIGdmbjogMDAwMDUwZjYgIG1mbjog
MDAwMDUwZjYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MDFdICAgZ2ZuOiAwMDAwNTBm
NyAgbWZuOiAwMDAwNTBmNw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzowMV0gICBnZm46
IDAwMDA1MGY4ICBtZm46IDAwMDA1MGY4DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjAx
XSAgIGdmbjogMDAwMDUwZjkgIG1mbjogMDAwMDUwZjkNCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzM6MDFdICAgZ2ZuOiAwMDAwNTBmYSAgbWZuOiAwMDAwNTBmYQ0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMzowMV0gICBnZm46IDAwMDA1MGZiICBtZm46IDAwMDA1MGZiDQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMzOjAxXSAgIGdmbjogMDAwMDUwZmMgIG1mbjogMDAwMDUw
ZmMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MDFdICAgZ2ZuOiAwMDAwNTBmZCAgbWZu
OiAwMDAwNTBmZA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzowMV0gICBnZm46IDAwMDA1
MGZlICBtZm46IDAwMDA1MGZlDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjAxXSAgIGdm
bjogMDAwMDUwZmYgIG1mbjogMDAwMDUwZmYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6
MDFdICAgZ2ZuOiAwMDAwNTEwMCAgbWZuOiAwMDAwNTEwMA0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMzowMV0gICBnZm46IDAwMDA1MTAxICBtZm46IDAwMDA1MTAxDQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMzOjAxXSAgIGdmbjogMDAwMDUxMDIgIG1mbjogMDAwMDUxMDINCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MDFdICAgZ2ZuOiAwMDAwNTEwMyAgbWZuOiAwMDAw
NTEwMw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzowMV0gICBnZm46IDAwMDA1MTA0ICBt
Zm46IDAwMDA1MTA0DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjAxXSAgIGdmbjogMDAw
MDUxMDUgIG1mbjogMDAwMDUxMDUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MDFdICAg
Z2ZuOiAwMDAwNTEwNiAgbWZuOiAwMDAwNTEwNg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
MzowMV0gICBnZm46IDAwMDA1MTA3ICBtZm46IDAwMDA1MTA3DQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMzOjAxXSAgIGdmbjogMDAwMDUxMDggIG1mbjogMDAwMDUxMDgNCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzM6MDFdICAgZ2ZuOiAwMDAwNTEwOSAgbWZuOiAwMDAwNTEwOQ0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzowMV0gICBnZm46IDAwMDA1MTBhICBtZm46IDAw
MDA1MTBhDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjAxXSAgIGdmbjogMDAwMDUxMGIg
IG1mbjogMDAwMDUxMGINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MDFdICAgZ2ZuOiAw
MDAwNTEwYyAgbWZuOiAwMDAwNTEwYw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzowMV0g
ICBnZm46IDAwMDA1MTBkICBtZm46IDAwMDA1MTBkDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMzOjAxXSAgIGdmbjogMDAwMDUxMGUgIG1mbjogMDAwMDUxMGUNCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzM6MDFdICAgZ2ZuOiAwMDAwNTEwZiAgbWZuOiAwMDAwNTEwZg0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMzowMV0gICBnZm46IDAwMDA1MTEwICBtZm46IDAwMDA1MTEw
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjAxXSAgIGdmbjogMDAwMDUxMTEgIG1mbjog
MDAwMDUxMTENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MDFdICAgZ2ZuOiAwMDAwNTEx
MiAgbWZuOiAwMDAwNTExMg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzowMV0gICBnZm46
IDAwMDA1MTEzICBtZm46IDAwMDA1MTEzDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjAx
XSAgIGdmbjogMDAwMDUxMTQgIG1mbjogMDAwMDUxMTQNCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzM6MDFdICAgZ2ZuOiAwMDAwNTExNSAgbWZuOiAwMDAwNTExNQ0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMzowMV0gICBnZm46IDAwMDA1MTE2ICBtZm46IDAwMDA1MTE2DQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMzOjAxXSAgIGdmbjogMDAwMDUxMTcgIG1mbjogMDAwMDUx
MTcNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MDFdICAgZ2ZuOiAwMDAwNTExOCAgbWZu
OiAwMDAwNTExOA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzowMV0gICBnZm46IDAwMDA1
MTE5ICBtZm46IDAwMDA1MTE5DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjAxXSAgIGdm
bjogMDAwMDUxMWEgIG1mbjogMDAwMDUxMWENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6
MDFdICAgZ2ZuOiAwMDAwNTExYiAgbWZuOiAwMDAwNTExYg0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMzowMV0gICBnZm46IDAwMDA1MTFjICBtZm46IDAwMDA1MTFjDQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMzOjAxXSAgIGdmbjogMDAwMDUxMWQgIG1mbjogMDAwMDUxMWQNCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MDFdICAgZ2ZuOiAwMDAwNTExZSAgbWZuOiAwMDAw
NTExZQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzowMV0gICBnZm46IDAwMDA1MTFmICBt
Zm46IDAwMDA1MTFmDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjAxXSAgIGdmbjogMDAw
MDUxMjAgIG1mbjogMDAwMDUxMjANCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MDFdICAg
Z2ZuOiAwMDAwNTEyMSAgbWZuOiAwMDAwNTEyMQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
MzowMV0gICBnZm46IDAwMDA1MTIyICBtZm46IDAwMDA1MTIyDQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMzOjAxXSAgIGdmbjogMDAwMDUxMjMgIG1mbjogMDAwMDUxMjMNCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzM6MDFdICAgZ2ZuOiAwMDAwNTEyNCAgbWZuOiAwMDAwNTEyNA0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzowMV0gICBnZm46IDAwMDA1MTI1ICBtZm46IDAw
MDA1MTI1DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjAxXSAgIGdmbjogMDAwMDUxMjYg
IG1mbjogMDAwMDUxMjYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MDFdICAgZ2ZuOiAw
MDAwNTEyNyAgbWZuOiAwMDAwNTEyNw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzowMV0g
ICBnZm46IDAwMDA1MTI4ICBtZm46IDAwMDA1MTI4DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMzOjAxXSAgIGdmbjogMDAwMDUxMjkgIG1mbjogMDAwMDUxMjkNCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzM6MDFdICAgZ2ZuOiAwMDAwNTEyYSAgbWZuOiAwMDAwNTEyYQ0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMzowMV0gICBnZm46IDAwMDA1MTJiICBtZm46IDAwMDA1MTJi
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjAxXSAgIGdmbjogMDAwMDUxMmMgIG1mbjog
MDAwMDUxMmMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MDFdICAgZ2ZuOiAwMDAwNTEy
ZCAgbWZuOiAwMDAwNTEyZA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzowMl0gICBnZm46
IDAwMDA1MTJlICBtZm46IDAwMDA1MTJlDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjAy
XSAgIGdmbjogMDAwMDUxMmYgIG1mbjogMDAwMDUxMmYNCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzM6MDJdICAgZ2ZuOiAwMDAwNTEzMCAgbWZuOiAwMDAwNTEzMA0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMzowMl0gICBnZm46IDAwMDA1MTMxICBtZm46IDAwMDA1MTMxDQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMzOjAyXSAgIGdmbjogMDAwMDUxMzIgIG1mbjogMDAwMDUx
MzINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MDJdICAgZ2ZuOiAwMDAwNTEzMyAgbWZu
OiAwMDAwNTEzMw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzowMl0gICBnZm46IDAwMDA1
MTM0ICBtZm46IDAwMDA1MTM0DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjAyXSAgIGdm
bjogMDAwMDUxMzUgIG1mbjogMDAwMDUxMzUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6
MDJdICAgZ2ZuOiAwMDAwNTEzNiAgbWZuOiAwMDAwNTEzNg0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMzowMl0gICBnZm46IDAwMDA1MTM3ICBtZm46IDAwMDA1MTM3DQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMzOjAyXSAgIGdmbjogMDAwMDUxMzggIG1mbjogMDAwMDUxMzgNCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MDJdICAgZ2ZuOiAwMDAwNTEzOSAgbWZuOiAwMDAw
NTEzOQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzowMl0gICBnZm46IDAwMDA1MTNhICBt
Zm46IDAwMDA1MTNhDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjAyXSAgIGdmbjogMDAw
MDUxM2IgIG1mbjogMDAwMDUxM2INCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MDJdICAg
Z2ZuOiAwMDAwNTEzYyAgbWZuOiAwMDAwNTEzYw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
MzowMl0gICBnZm46IDAwMDA1MTNkICBtZm46IDAwMDA1MTNkDQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMzOjAyXSAgIGdmbjogMDAwMDUxM2UgIG1mbjogMDAwMDUxM2UNCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzM6MDJdICAgZ2ZuOiAwMDAwNTEzZiAgbWZuOiAwMDAwNTEzZg0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzowMl0gICBnZm46IDAwMDA1MTQwICBtZm46IDAw
MDA1MTQwDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjAyXSAgIGdmbjogMDAwMDUxNDEg
IG1mbjogMDAwMDUxNDENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MDJdICAgZ2ZuOiAw
MDAwNTE0MiAgbWZuOiAwMDAwNTE0Mg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzowMl0g
ICBnZm46IDAwMDA1MTQzICBtZm46IDAwMDA1MTQzDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMzOjAyXSAgIGdmbjogMDAwMDUxNDQgIG1mbjogMDAwMDUxNDQNCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzM6MDJdICAgZ2ZuOiAwMDAwNTE0NSAgbWZuOiAwMDAwNTE0NQ0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMzowMl0gICBnZm46IDAwMDA1MTQ2ICBtZm46IDAwMDA1MTQ2
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjAyXSAgIGdmbjogMDAwMDUxNDcgIG1mbjog
MDAwMDUxNDcNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MDJdICAgZ2ZuOiAwMDAwNTE0
OCAgbWZuOiAwMDAwNTE0OA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzowMl0gICBnZm46
IDAwMDA1MTQ5ICBtZm46IDAwMDA1MTQ5DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjAy
XSAgIGdmbjogMDAwMDUxNGEgIG1mbjogMDAwMDUxNGENCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzM6MDJdICAgZ2ZuOiAwMDAwNTE0YiAgbWZuOiAwMDAwNTE0Yg0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMzowMl0gICBnZm46IDAwMDA1MTRjICBtZm46IDAwMDA1MTRjDQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMzOjAyXSAgIGdmbjogMDAwMDUxNGQgIG1mbjogMDAwMDUx
NGQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MDJdICAgZ2ZuOiAwMDAwNTE0ZSAgbWZu
OiAwMDAwNTE0ZQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzowMl0gICBnZm46IDAwMDA1
MTRmICBtZm46IDAwMDA1MTRmDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjAyXSAgIGdm
bjogMDAwMDUxNTAgIG1mbjogMDAwMDUxNTANCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6
MDJdICAgZ2ZuOiAwMDAwNTE1MSAgbWZuOiAwMDAwNTE1MQ0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMzowMl0gICBnZm46IDAwMDA1MTUyICBtZm46IDAwMDA1MTUyDQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMzOjAyXSAgIGdmbjogMDAwMDUxNTMgIG1mbjogMDAwMDUxNTMNCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MDJdICAgZ2ZuOiAwMDAwNTE1NCAgbWZuOiAwMDAw
NTE1NA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzowMl0gICBnZm46IDAwMDA1MTU1ICBt
Zm46IDAwMDA1MTU1DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjAyXSAgIGdmbjogMDAw
MDUxNTYgIG1mbjogMDAwMDUxNTYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MDJdICAg
Z2ZuOiAwMDAwNTE1NyAgbWZuOiAwMDAwNTE1Nw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
MzowMl0gICBnZm46IDAwMDA1MTU4ICBtZm46IDAwMDA1MTU4DQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMzOjAyXSAgIGdmbjogMDAwMDUxNTkgIG1mbjogMDAwMDUxNTkNCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzM6MDJdICAgZ2ZuOiAwMDAwNTE1YSAgbWZuOiAwMDAwNTE1YQ0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzowMl0gICBnZm46IDAwMDA1MTViICBtZm46IDAw
MDA1MTViDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjAyXSAgIGdmbjogMDAwMDUxNWMg
IG1mbjogMDAwMDUxNWMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MDJdICAgZ2ZuOiAw
MDAwNTE1ZCAgbWZuOiAwMDAwNTE1ZA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzowMl0g
ICBnZm46IDAwMDA1MTVlICBtZm46IDAwMDA1MTVlDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMzOjAyXSAgIGdmbjogMDAwMDUxNWYgIG1mbjogMDAwMDUxNWYNCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzM6MDJdICAgZ2ZuOiAwMDAwNTE2MCAgbWZuOiAwMDAwNTE2MA0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMzowMl0gICBnZm46IDAwMDA1MTYxICBtZm46IDAwMDA1MTYx
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjAyXSAgIGdmbjogMDAwMDUxNjIgIG1mbjog
MDAwMDUxNjINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MDJdICAgZ2ZuOiAwMDAwNTE2
MyAgbWZuOiAwMDAwNTE2Mw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzowMl0gICBnZm46
IDAwMDA1MTY0ICBtZm46IDAwMDA1MTY0DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjAy
XSAgIGdmbjogMDAwMDUxNjUgIG1mbjogMDAwMDUxNjUNCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzM6MDJdICAgZ2ZuOiAwMDAwNTE2NiAgbWZuOiAwMDAwNTE2Ng0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMzowMl0gICBnZm46IDAwMDA1MTY3ICBtZm46IDAwMDA1MTY3DQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMzOjAyXSAgIGdmbjogMDAwMDUxNjggIG1mbjogMDAwMDUx
NjgNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MDJdICAgZ2ZuOiAwMDAwNTE2OSAgbWZu
OiAwMDAwNTE2OQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzowMl0gICBnZm46IDAwMDA1
MTZhICBtZm46IDAwMDA1MTZhDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjAyXSAgIGdm
bjogMDAwMDUxNmIgIG1mbjogMDAwMDUxNmINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6
MDJdICAgZ2ZuOiAwMDAwNTE2YyAgbWZuOiAwMDAwNTE2Yw0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMzowMl0gICBnZm46IDAwMDA1MTZkICBtZm46IDAwMDA1MTZkDQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMzOjAzXSAgIGdmbjogMDAwMDUxNmUgIG1mbjogMDAwMDUxNmUNCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MDNdICAgZ2ZuOiAwMDAwNTE2ZiAgbWZuOiAwMDAw
NTE2Zg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzowM10gICBnZm46IDAwMDA1MTcwICBt
Zm46IDAwMDA1MTcwDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjAzXSAgIGdmbjogMDAw
MDUxNzEgIG1mbjogMDAwMDUxNzENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MDNdICAg
Z2ZuOiAwMDAwNTE3MiAgbWZuOiAwMDAwNTE3Mg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
MzowM10gICBnZm46IDAwMDA1MTczICBtZm46IDAwMDA1MTczDQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMzOjAzXSAgIGdmbjogMDAwMDUxNzQgIG1mbjogMDAwMDUxNzQNCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzM6MDNdICAgZ2ZuOiAwMDAwNTE3NSAgbWZuOiAwMDAwNTE3NQ0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzowM10gICBnZm46IDAwMDA1MTc2ICBtZm46IDAw
MDA1MTc2DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjAzXSAgIGdmbjogMDAwMDUxNzcg
IG1mbjogMDAwMDUxNzcNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MDNdICAgZ2ZuOiAw
MDAwNTE3OCAgbWZuOiAwMDAwNTE3OA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzowM10g
ICBnZm46IDAwMDA1MTc5ICBtZm46IDAwMDA1MTc5DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMzOjAzXSAgIGdmbjogMDAwMDUxN2EgIG1mbjogMDAwMDUxN2ENCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzM6MDNdICAgZ2ZuOiAwMDAwNTE3YiAgbWZuOiAwMDAwNTE3Yg0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMzowM10gICBnZm46IDAwMDA1MTdjICBtZm46IDAwMDA1MTdj
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjAzXSAgIGdmbjogMDAwMDUxN2QgIG1mbjog
MDAwMDUxN2QNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MDNdICAgZ2ZuOiAwMDAwNTE3
ZSAgbWZuOiAwMDAwNTE3ZQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzowM10gICBnZm46
IDAwMDA1MTdmICBtZm46IDAwMDA1MTdmDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjAz
XSAgIGdmbjogMDAwMDUxODAgIG1mbjogMDAwMDUxODANCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzM6MDNdICAgZ2ZuOiAwMDAwNTE4MSAgbWZuOiAwMDAwNTE4MQ0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMzowM10gICBnZm46IDAwMDA1MTgyICBtZm46IDAwMDA1MTgyDQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMzOjAzXSAgIGdmbjogMDAwMDUxODMgIG1mbjogMDAwMDUx
ODMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MDNdICAgZ2ZuOiAwMDAwNTE4NCAgbWZu
OiAwMDAwNTE4NA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzowM10gICBnZm46IDAwMDA1
MTg1ICBtZm46IDAwMDA1MTg1DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjAzXSAgIGdm
bjogMDAwMDUxODYgIG1mbjogMDAwMDUxODYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6
MDNdICAgZ2ZuOiAwMDAwNTE4NyAgbWZuOiAwMDAwNTE4Nw0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMzowM10gICBnZm46IDAwMDA1MTg4ICBtZm46IDAwMDA1MTg4DQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMzOjAzXSAgIGdmbjogMDAwMDUxODkgIG1mbjogMDAwMDUxODkNCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MDNdICAgZ2ZuOiAwMDAwNTE4YSAgbWZuOiAwMDAw
NTE4YQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzowM10gICBnZm46IDAwMDA1MThiICBt
Zm46IDAwMDA1MThiDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjAzXSAgIGdmbjogMDAw
MDUxOGMgIG1mbjogMDAwMDUxOGMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MDNdICAg
Z2ZuOiAwMDAwNTE4ZCAgbWZuOiAwMDAwNTE4ZA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
MzowM10gICBnZm46IDAwMDA1MThlICBtZm46IDAwMDA1MThlDQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMzOjAzXSAgIGdmbjogMDAwMDUxOGYgIG1mbjogMDAwMDUxOGYNCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzM6MDNdICAgZ2ZuOiAwMDAwNTE5MCAgbWZuOiAwMDAwNTE5MA0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzowM10gICBnZm46IDAwMDA1MTkxICBtZm46IDAw
MDA1MTkxDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjAzXSAgIGdmbjogMDAwMDUxOTIg
IG1mbjogMDAwMDUxOTINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MDNdICAgZ2ZuOiAw
MDAwNTE5MyAgbWZuOiAwMDAwNTE5Mw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzowM10g
ICBnZm46IDAwMDA1MTk0ICBtZm46IDAwMDA1MTk0DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMzOjAzXSAgIGdmbjogMDAwMDUxOTUgIG1mbjogMDAwMDUxOTUNCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzM6MDNdICAgZ2ZuOiAwMDAwNTE5NiAgbWZuOiAwMDAwNTE5Ng0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMzowM10gICBnZm46IDAwMDA1MTk3ICBtZm46IDAwMDA1MTk3
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjAzXSAgIGdmbjogMDAwMDUxOTggIG1mbjog
MDAwMDUxOTgNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MDNdICAgZ2ZuOiAwMDAwNTE5
OSAgbWZuOiAwMDAwNTE5OQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzowM10gICBnZm46
IDAwMDA1MTlhICBtZm46IDAwMDA1MTlhDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjAz
XSAgIGdmbjogMDAwMDUxOWIgIG1mbjogMDAwMDUxOWINCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzM6MDNdICAgZ2ZuOiAwMDAwNTE5YyAgbWZuOiAwMDAwNTE5Yw0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMzowM10gICBnZm46IDAwMDA1MTlkICBtZm46IDAwMDA1MTlkDQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMzOjAzXSAgIGdmbjogMDAwMDUxOWUgIG1mbjogMDAwMDUx
OWUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MDNdICAgZ2ZuOiAwMDAwNTE5ZiAgbWZu
OiAwMDAwNTE5Zg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzowM10gICBnZm46IDAwMDA1
MWEwICBtZm46IDAwMDA1MWEwDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjAzXSAgIGdm
bjogMDAwMDUxYTEgIG1mbjogMDAwMDUxYTENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6
MDNdICAgZ2ZuOiAwMDAwNTFhMiAgbWZuOiAwMDAwNTFhMg0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMzowM10gICBnZm46IDAwMDA1MWEzICBtZm46IDAwMDA1MWEzDQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMzOjAzXSAgIGdmbjogMDAwMDUxYTQgIG1mbjogMDAwMDUxYTQNCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MDNdICAgZ2ZuOiAwMDAwNTFhNSAgbWZuOiAwMDAw
NTFhNQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzowM10gICBnZm46IDAwMDA1MWE2ICBt
Zm46IDAwMDA1MWE2DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjAzXSAgIGdmbjogMDAw
MDUxYTcgIG1mbjogMDAwMDUxYTcNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MDNdICAg
Z2ZuOiAwMDAwNTFhOCAgbWZuOiAwMDAwNTFhOA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
MzowM10gICBnZm46IDAwMDA1MWE5ICBtZm46IDAwMDA1MWE5DQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMzOjAzXSAgIGdmbjogMDAwMDUxYWEgIG1mbjogMDAwMDUxYWENCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzM6MDNdICAgZ2ZuOiAwMDAwNTFhYiAgbWZuOiAwMDAwNTFhYg0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzowM10gICBnZm46IDAwMDA1MWFjICBtZm46IDAw
MDA1MWFjDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjAzXSAgIGdmbjogMDAwMDUxYWQg
IG1mbjogMDAwMDUxYWQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MDRdICAgZ2ZuOiAw
MDAwNTFhZSAgbWZuOiAwMDAwNTFhZQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzowNF0g
ICBnZm46IDAwMDA1MWFmICBtZm46IDAwMDA1MWFmDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMzOjA0XSAgIGdmbjogMDAwMDUxYjAgIG1mbjogMDAwMDUxYjANCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzM6MDRdICAgZ2ZuOiAwMDAwNTFiMSAgbWZuOiAwMDAwNTFiMQ0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMzowNF0gICBnZm46IDAwMDA1MWIyICBtZm46IDAwMDA1MWIy
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjA0XSAgIGdmbjogMDAwMDUxYjMgIG1mbjog
MDAwMDUxYjMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MDRdICAgZ2ZuOiAwMDAwNTFi
NCAgbWZuOiAwMDAwNTFiNA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzowNF0gICBnZm46
IDAwMDA1MWI1ICBtZm46IDAwMDA1MWI1DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjA0
XSAgIGdmbjogMDAwMDUxYjYgIG1mbjogMDAwMDUxYjYNCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzM6MDRdICAgZ2ZuOiAwMDAwNTFiNyAgbWZuOiAwMDAwNTFiNw0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMzowNF0gICBnZm46IDAwMDA1MWI4ICBtZm46IDAwMDA1MWI4DQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMzOjA0XSAgIGdmbjogMDAwMDUxYjkgIG1mbjogMDAwMDUx
YjkNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MDRdICAgZ2ZuOiAwMDAwNTFiYSAgbWZu
OiAwMDAwNTFiYQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzowNF0gICBnZm46IDAwMDA1
MWJiICBtZm46IDAwMDA1MWJiDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjA0XSAgIGdm
bjogMDAwMDUxYmMgIG1mbjogMDAwMDUxYmMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6
MDRdICAgZ2ZuOiAwMDAwNTFiZCAgbWZuOiAwMDAwNTFiZA0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMzowNF0gICBnZm46IDAwMDA1MWJlICBtZm46IDAwMDA1MWJlDQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMzOjA0XSAgIGdmbjogMDAwMDUxYmYgIG1mbjogMDAwMDUxYmYNCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MDRdICAgZ2ZuOiAwMDAwNTFjMCAgbWZuOiAwMDAw
NTFjMA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzowNF0gICBnZm46IDAwMDA1MWMxICBt
Zm46IDAwMDA1MWMxDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjA0XSAgIGdmbjogMDAw
MDUxYzIgIG1mbjogMDAwMDUxYzINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MDRdICAg
Z2ZuOiAwMDAwNTFjMyAgbWZuOiAwMDAwNTFjMw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
MzowNF0gICBnZm46IDAwMDA1MWM0ICBtZm46IDAwMDA1MWM0DQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMzOjA0XSAgIGdmbjogMDAwMDUxYzUgIG1mbjogMDAwMDUxYzUNCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzM6MDRdICAgZ2ZuOiAwMDAwNTFjNiAgbWZuOiAwMDAwNTFjNg0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzowNF0gICBnZm46IDAwMDA1MWM3ICBtZm46IDAw
MDA1MWM3DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjA0XSAgIGdmbjogMDAwMDUxYzgg
IG1mbjogMDAwMDUxYzgNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MDRdICAgZ2ZuOiAw
MDAwNTFjOSAgbWZuOiAwMDAwNTFjOQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzowNF0g
ICBnZm46IDAwMDA1MWNhICBtZm46IDAwMDA1MWNhDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMzOjA0XSAgIGdmbjogMDAwMDUxY2IgIG1mbjogMDAwMDUxY2INCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzM6MDRdICAgZ2ZuOiAwMDAwNTFjYyAgbWZuOiAwMDAwNTFjYw0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMzowNF0gICBnZm46IDAwMDA1MWNkICBtZm46IDAwMDA1MWNk
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjA0XSAgIGdmbjogMDAwMDUxY2UgIG1mbjog
MDAwMDUxY2UNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MDRdICAgZ2ZuOiAwMDAwNTFj
ZiAgbWZuOiAwMDAwNTFjZg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzowNF0gICBnZm46
IDAwMDA1MWQwICBtZm46IDAwMDA1MWQwDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjA0
XSAgIGdmbjogMDAwMDUxZDEgIG1mbjogMDAwMDUxZDENCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzM6MDRdICAgZ2ZuOiAwMDAwNTFkMiAgbWZuOiAwMDAwNTFkMg0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMzowNF0gICBnZm46IDAwMDA1MWQzICBtZm46IDAwMDA1MWQzDQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMzOjA0XSAgIGdmbjogMDAwMDUxZDQgIG1mbjogMDAwMDUx
ZDQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MDRdICAgZ2ZuOiAwMDAwNTFkNSAgbWZu
OiAwMDAwNTFkNQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzowNF0gICBnZm46IDAwMDA1
MWQ2ICBtZm46IDAwMDA1MWQ2DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjA0XSAgIGdm
bjogMDAwMDUxZDcgIG1mbjogMDAwMDUxZDcNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6
MDRdICAgZ2ZuOiAwMDAwNTFkOCAgbWZuOiAwMDAwNTFkOA0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMzowNF0gICBnZm46IDAwMDA1MWQ5ICBtZm46IDAwMDA1MWQ5DQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMzOjA0XSAgIGdmbjogMDAwMDUxZGEgIG1mbjogMDAwMDUxZGENCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MDRdICAgZ2ZuOiAwMDAwNTFkYiAgbWZuOiAwMDAw
NTFkYg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzowNF0gICBnZm46IDAwMDA1MWRjICBt
Zm46IDAwMDA1MWRjDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjA0XSAgIGdmbjogMDAw
MDUxZGQgIG1mbjogMDAwMDUxZGQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MDRdICAg
Z2ZuOiAwMDAwNTFkZSAgbWZuOiAwMDAwNTFkZQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
MzowNF0gICBnZm46IDAwMDA1MWRmICBtZm46IDAwMDA1MWRmDQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMzOjA0XSAgIGdmbjogMDAwMDUxZTAgIG1mbjogMDAwMDUxZTANCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzM6MDRdICAgZ2ZuOiAwMDAwNTFlMSAgbWZuOiAwMDAwNTFlMQ0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzowNF0gICBnZm46IDAwMDA1MWUyICBtZm46IDAw
MDA1MWUyDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjA0XSAgIGdmbjogMDAwMDUxZTMg
IG1mbjogMDAwMDUxZTMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MDRdICAgZ2ZuOiAw
MDAwNTFlNCAgbWZuOiAwMDAwNTFlNA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzowNF0g
ICBnZm46IDAwMDA1MWU1ICBtZm46IDAwMDA1MWU1DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMzOjA0XSAgIGdmbjogMDAwMDUxZTYgIG1mbjogMDAwMDUxZTYNCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzM6MDRdICAgZ2ZuOiAwMDAwNTFlNyAgbWZuOiAwMDAwNTFlNw0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMzowNF0gICBnZm46IDAwMDA1MWU4ICBtZm46IDAwMDA1MWU4
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjA0XSAgIGdmbjogMDAwMDUxZTkgIG1mbjog
MDAwMDUxZTkNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MDRdICAgZ2ZuOiAwMDAwNTFl
YSAgbWZuOiAwMDAwNTFlYQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzowNF0gICBnZm46
IDAwMDA1MWViICBtZm46IDAwMDA1MWViDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjA0
XSAgIGdmbjogMDAwMDUxZWMgIG1mbjogMDAwMDUxZWMNCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzM6MDRdICAgZ2ZuOiAwMDAwNTFlZCAgbWZuOiAwMDAwNTFlZA0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMzowNV0gICBnZm46IDAwMDA1MWVlICBtZm46IDAwMDA1MWVlDQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMzOjA1XSAgIGdmbjogMDAwMDUxZWYgIG1mbjogMDAwMDUx
ZWYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MDVdICAgZ2ZuOiAwMDAwNTFmMCAgbWZu
OiAwMDAwNTFmMA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzowNV0gICBnZm46IDAwMDA1
MWYxICBtZm46IDAwMDA1MWYxDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjA1XSAgIGdm
bjogMDAwMDUxZjIgIG1mbjogMDAwMDUxZjINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6
MDVdICAgZ2ZuOiAwMDAwNTFmMyAgbWZuOiAwMDAwNTFmMw0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMzowNV0gICBnZm46IDAwMDA1MWY0ICBtZm46IDAwMDA1MWY0DQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMzOjA1XSAgIGdmbjogMDAwMDUxZjUgIG1mbjogMDAwMDUxZjUNCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MDVdICAgZ2ZuOiAwMDAwNTFmNiAgbWZuOiAwMDAw
NTFmNg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzowNV0gICBnZm46IDAwMDA1MWY3ICBt
Zm46IDAwMDA1MWY3DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjA1XSAgIGdmbjogMDAw
MDUxZjggIG1mbjogMDAwMDUxZjgNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MDVdICAg
Z2ZuOiAwMDAwNTFmOSAgbWZuOiAwMDAwNTFmOQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
MzowNV0gICBnZm46IDAwMDA1MWZhICBtZm46IDAwMDA1MWZhDQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMzOjA1XSAgIGdmbjogMDAwMDUxZmIgIG1mbjogMDAwMDUxZmINCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzM6MDVdICAgZ2ZuOiAwMDAwNTFmYyAgbWZuOiAwMDAwNTFmYw0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzowNV0gICBnZm46IDAwMDA1MWZkICBtZm46IDAw
MDA1MWZkDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjA1XSAgIGdmbjogMDAwMDUxZmUg
IG1mbjogMDAwMDUxZmUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MDVdICAgZ2ZuOiAw
MDAwNTFmZiAgbWZuOiAwMDAwNTFmZg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzowNV0g
ICBnZm46IDAwMDA1MjAwICBtZm46IDAwMDA1MjAwDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMzOjA1XSAgIGdmbjogMDAwMDUyMDEgIG1mbjogMDAwMDUyMDENCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzM6MDVdICAgZ2ZuOiAwMDAwNTIwMiAgbWZuOiAwMDAwNTIwMg0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMzowNV0gICBnZm46IDAwMDA1MjAzICBtZm46IDAwMDA1MjAz
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjA1XSAgIGdmbjogMDAwMDUyMDQgIG1mbjog
MDAwMDUyMDQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MDVdICAgZ2ZuOiAwMDAwNTIw
NSAgbWZuOiAwMDAwNTIwNQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzowNV0gICBnZm46
IDAwMDA1MjA2ICBtZm46IDAwMDA1MjA2DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjA1
XSAgIGdmbjogMDAwMDUyMDcgIG1mbjogMDAwMDUyMDcNCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzM6MDVdICAgZ2ZuOiAwMDAwNTIwOCAgbWZuOiAwMDAwNTIwOA0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMzowNV0gICBnZm46IDAwMDA1MjA5ICBtZm46IDAwMDA1MjA5DQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMzOjA1XSAgIGdmbjogMDAwMDUyMGEgIG1mbjogMDAwMDUy
MGENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MDVdICAgZ2ZuOiAwMDAwNTIwYiAgbWZu
OiAwMDAwNTIwYg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzowNV0gICBnZm46IDAwMDA1
MjBjICBtZm46IDAwMDA1MjBjDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjA1XSAgIGdm
bjogMDAwMDUyMGQgIG1mbjogMDAwMDUyMGQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6
MDVdICAgZ2ZuOiAwMDAwNTIwZSAgbWZuOiAwMDAwNTIwZQ0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMzowNV0gICBnZm46IDAwMDA1MjBmICBtZm46IDAwMDA1MjBmDQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMzOjA1XSAgIGdmbjogMDAwMDUyMTAgIG1mbjogMDAwMDUyMTANCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MDVdICAgZ2ZuOiAwMDAwNTIxMSAgbWZuOiAwMDAw
NTIxMQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzowNV0gICBnZm46IDAwMDA1MjEyICBt
Zm46IDAwMDA1MjEyDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjA1XSAgIGdmbjogMDAw
MDUyMTMgIG1mbjogMDAwMDUyMTMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MDVdICAg
Z2ZuOiAwMDAwNTIxNCAgbWZuOiAwMDAwNTIxNA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
MzowNV0gICBnZm46IDAwMDA1MjE1ICBtZm46IDAwMDA1MjE1DQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMzOjA1XSAgIGdmbjogMDAwMDUyMTYgIG1mbjogMDAwMDUyMTYNCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzM6MDVdICAgZ2ZuOiAwMDAwNTIxNyAgbWZuOiAwMDAwNTIxNw0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzowNV0gICBnZm46IDAwMDA1MjE4ICBtZm46IDAw
MDA1MjE4DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjA1XSAgIGdmbjogMDAwMDUyMTkg
IG1mbjogMDAwMDUyMTkNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MDVdICAgZ2ZuOiAw
MDAwNTIxYSAgbWZuOiAwMDAwNTIxYQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzowNV0g
ICBnZm46IDAwMDA1MjFiICBtZm46IDAwMDA1MjFiDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMzOjA1XSAgIGdmbjogMDAwMDUyMWMgIG1mbjogMDAwMDUyMWMNCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzM6MDVdICAgZ2ZuOiAwMDAwNTIxZCAgbWZuOiAwMDAwNTIxZA0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMzowNV0gICBnZm46IDAwMDA1MjFlICBtZm46IDAwMDA1MjFl
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjA1XSAgIGdmbjogMDAwMDUyMWYgIG1mbjog
MDAwMDUyMWYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MDVdICAgZ2ZuOiAwMDAwNTIy
MCAgbWZuOiAwMDAwNTIyMA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzowNV0gICBnZm46
IDAwMDA1MjIxICBtZm46IDAwMDA1MjIxDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjA1
XSAgIGdmbjogMDAwMDUyMjIgIG1mbjogMDAwMDUyMjINCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzM6MDVdICAgZ2ZuOiAwMDAwNTIyMyAgbWZuOiAwMDAwNTIyMw0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMzowNV0gICBnZm46IDAwMDA1MjI0ICBtZm46IDAwMDA1MjI0DQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMzOjA1XSAgIGdmbjogMDAwMDUyMjUgIG1mbjogMDAwMDUy
MjUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MDVdICAgZ2ZuOiAwMDAwNTIyNiAgbWZu
OiAwMDAwNTIyNg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzowNV0gICBnZm46IDAwMDA1
MjI3ICBtZm46IDAwMDA1MjI3DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjA1XSAgIGdm
bjogMDAwMDUyMjggIG1mbjogMDAwMDUyMjgNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6
MDVdICAgZ2ZuOiAwMDAwNTIyOSAgbWZuOiAwMDAwNTIyOQ0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMzowNV0gICBnZm46IDAwMDA1MjJhICBtZm46IDAwMDA1MjJhDQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMzOjA1XSAgIGdmbjogMDAwMDUyMmIgIG1mbjogMDAwMDUyMmINCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MDVdICAgZ2ZuOiAwMDAwNTIyYyAgbWZuOiAwMDAw
NTIyYw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzowNV0gICBnZm46IDAwMDA1MjJkICBt
Zm46IDAwMDA1MjJkDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjA1XSAgIGdmbjogMDAw
MDUyMmUgIG1mbjogMDAwMDUyMmUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MDZdICAg
Z2ZuOiAwMDAwNTIyZiAgbWZuOiAwMDAwNTIyZg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
MzowNl0gICBnZm46IDAwMDA1MjMwICBtZm46IDAwMDA1MjMwDQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMzOjA2XSAgIGdmbjogMDAwMDUyMzEgIG1mbjogMDAwMDUyMzENCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzM6MDZdICAgZ2ZuOiAwMDAwNTIzMiAgbWZuOiAwMDAwNTIzMg0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzowNl0gICBnZm46IDAwMDA1MjMzICBtZm46IDAw
MDA1MjMzDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjA2XSAgIGdmbjogMDAwMDUyMzQg
IG1mbjogMDAwMDUyMzQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MDZdICAgZ2ZuOiAw
MDAwNTIzNSAgbWZuOiAwMDAwNTIzNQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzowNl0g
ICBnZm46IDAwMDA1MjM2ICBtZm46IDAwMDA1MjM2DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMzOjA2XSAgIGdmbjogMDAwMDUyMzcgIG1mbjogMDAwMDUyMzcNCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzM6MDZdICAgZ2ZuOiAwMDAwNTIzOCAgbWZuOiAwMDAwNTIzOA0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMzowNl0gICBnZm46IDAwMDA1MjM5ICBtZm46IDAwMDA1MjM5
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjA2XSAgIGdmbjogMDAwMDUyM2EgIG1mbjog
MDAwMDUyM2ENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MDZdICAgZ2ZuOiAwMDAwNTIz
YiAgbWZuOiAwMDAwNTIzYg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzowNl0gICBnZm46
IDAwMDA1MjNjICBtZm46IDAwMDA1MjNjDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjA2
XSAgIGdmbjogMDAwMDUyM2QgIG1mbjogMDAwMDUyM2QNCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzM6MDZdICAgZ2ZuOiAwMDAwNTIzZSAgbWZuOiAwMDAwNTIzZQ0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMzowNl0gICBnZm46IDAwMDA1MjNmICBtZm46IDAwMDA1MjNmDQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMzOjA2XSAgIGdmbjogMDAwMDUyNDAgIG1mbjogMDAwMDUy
NDANCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MDZdICAgZ2ZuOiAwMDAwNTI0MSAgbWZu
OiAwMDAwNTI0MQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzowNl0gICBnZm46IDAwMDA1
MjQyICBtZm46IDAwMDA1MjQyDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjA2XSAgIGdm
bjogMDAwMDUyNDMgIG1mbjogMDAwMDUyNDMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6
MDZdICAgZ2ZuOiAwMDAwNTI0NCAgbWZuOiAwMDAwNTI0NA0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMzowNl0gICBnZm46IDAwMDA1MjQ1ICBtZm46IDAwMDA1MjQ1DQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMzOjA2XSAgIGdmbjogMDAwMDUyNDYgIG1mbjogMDAwMDUyNDYNCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MDZdICAgZ2ZuOiAwMDAwNTI0NyAgbWZuOiAwMDAw
NTI0Nw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzowNl0gICBnZm46IDAwMDA1MjQ4ICBt
Zm46IDAwMDA1MjQ4DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjA2XSAgIGdmbjogMDAw
MDUyNDkgIG1mbjogMDAwMDUyNDkNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MDZdICAg
Z2ZuOiAwMDAwNTI0YSAgbWZuOiAwMDAwNTI0YQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
MzowNl0gICBnZm46IDAwMDA1MjRiICBtZm46IDAwMDA1MjRiDQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMzOjA2XSAgIGdmbjogMDAwMDUyNGMgIG1mbjogMDAwMDUyNGMNCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzM6MDZdICAgZ2ZuOiAwMDAwNTI0ZCAgbWZuOiAwMDAwNTI0ZA0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzowNl0gICBnZm46IDAwMDA1MjRlICBtZm46IDAw
MDA1MjRlDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjA2XSAgIGdmbjogMDAwMDUyNGYg
IG1mbjogMDAwMDUyNGYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MDZdICAgZ2ZuOiAw
MDAwNTI1MCAgbWZuOiAwMDAwNTI1MA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzowNl0g
ICBnZm46IDAwMDA1MjUxICBtZm46IDAwMDA1MjUxDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMzOjA2XSAgIGdmbjogMDAwMDUyNTIgIG1mbjogMDAwMDUyNTINCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzM6MDZdICAgZ2ZuOiAwMDAwNTI1MyAgbWZuOiAwMDAwNTI1Mw0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMzowNl0gICBnZm46IDAwMDA1MjU0ICBtZm46IDAwMDA1MjU0
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjA2XSAgIGdmbjogMDAwMDUyNTUgIG1mbjog
MDAwMDUyNTUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MDZdICAgZ2ZuOiAwMDAwNTI1
NiAgbWZuOiAwMDAwNTI1Ng0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzowNl0gICBnZm46
IDAwMDA1MjU3ICBtZm46IDAwMDA1MjU3DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjA2
XSAgIGdmbjogMDAwMDUyNTggIG1mbjogMDAwMDUyNTgNCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzM6MDZdICAgZ2ZuOiAwMDAwNTI1OSAgbWZuOiAwMDAwNTI1OQ0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMzowNl0gICBnZm46IDAwMDA1MjVhICBtZm46IDAwMDA1MjVhDQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMzOjA2XSAgIGdmbjogMDAwMDUyNWIgIG1mbjogMDAwMDUy
NWINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MDZdICAgZ2ZuOiAwMDAwNTI1YyAgbWZu
OiAwMDAwNTI1Yw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzowNl0gICBnZm46IDAwMDA1
MjVkICBtZm46IDAwMDA1MjVkDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjA2XSAgIGdm
bjogMDAwMDUyNWUgIG1mbjogMDAwMDUyNWUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6
MDZdICAgZ2ZuOiAwMDAwNTI1ZiAgbWZuOiAwMDAwNTI1Zg0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMzowNl0gICBnZm46IDAwMDA1MjYwICBtZm46IDAwMDA1MjYwDQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMzOjA2XSAgIGdmbjogMDAwMDUyNjEgIG1mbjogMDAwMDUyNjENCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MDZdICAgZ2ZuOiAwMDAwNTI2MiAgbWZuOiAwMDAw
NTI2Mg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzowNl0gICBnZm46IDAwMDA1MjYzICBt
Zm46IDAwMDA1MjYzDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjA2XSAgIGdmbjogMDAw
MDUyNjQgIG1mbjogMDAwMDUyNjQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MDZdICAg
Z2ZuOiAwMDAwNTI2NSAgbWZuOiAwMDAwNTI2NQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
MzowNl0gICBnZm46IDAwMDA1MjY2ICBtZm46IDAwMDA1MjY2DQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMzOjA2XSAgIGdmbjogMDAwMDUyNjcgIG1mbjogMDAwMDUyNjcNCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzM6MDZdICAgZ2ZuOiAwMDAwNTI2OCAgbWZuOiAwMDAwNTI2OA0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzowNl0gICBnZm46IDAwMDA1MjY5ICBtZm46IDAw
MDA1MjY5DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjA2XSAgIGdmbjogMDAwMDUyNmEg
IG1mbjogMDAwMDUyNmENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MDZdICAgZ2ZuOiAw
MDAwNTI2YiAgbWZuOiAwMDAwNTI2Yg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzowNl0g
ICBnZm46IDAwMDA1MjZjICBtZm46IDAwMDA1MjZjDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMzOjA2XSAgIGdmbjogMDAwMDUyNmQgIG1mbjogMDAwMDUyNmQNCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzM6MDZdICAgZ2ZuOiAwMDAwNTI2ZSAgbWZuOiAwMDAwNTI2ZQ0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMzowN10gICBnZm46IDAwMDA1MjZmICBtZm46IDAwMDA1MjZm
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjA3XSAgIGdmbjogMDAwMDUyNzAgIG1mbjog
MDAwMDUyNzANCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MDddICAgZ2ZuOiAwMDAwNTI3
MSAgbWZuOiAwMDAwNTI3MQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzowN10gICBnZm46
IDAwMDA1MjcyICBtZm46IDAwMDA1MjcyDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjA3
XSAgIGdmbjogMDAwMDUyNzMgIG1mbjogMDAwMDUyNzMNCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzM6MDddICAgZ2ZuOiAwMDAwNTI3NCAgbWZuOiAwMDAwNTI3NA0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMzowN10gICBnZm46IDAwMDA1Mjc1ICBtZm46IDAwMDA1Mjc1DQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMzOjA3XSAgIGdmbjogMDAwMDUyNzYgIG1mbjogMDAwMDUy
NzYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MDddICAgZ2ZuOiAwMDAwNTI3NyAgbWZu
OiAwMDAwNTI3Nw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzowN10gICBnZm46IDAwMDA1
Mjc4ICBtZm46IDAwMDA1Mjc4DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjA3XSAgIGdm
bjogMDAwMDUyNzkgIG1mbjogMDAwMDUyNzkNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6
MDddICAgZ2ZuOiAwMDAwNTI3YSAgbWZuOiAwMDAwNTI3YQ0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMzowN10gICBnZm46IDAwMDA1MjdiICBtZm46IDAwMDA1MjdiDQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMzOjA3XSAgIGdmbjogMDAwMDUyN2MgIG1mbjogMDAwMDUyN2MNCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MDddICAgZ2ZuOiAwMDAwNTI3ZCAgbWZuOiAwMDAw
NTI3ZA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzowN10gICBnZm46IDAwMDA1MjdlICBt
Zm46IDAwMDA1MjdlDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjA3XSAgIGdmbjogMDAw
MDUyN2YgIG1mbjogMDAwMDUyN2YNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MDddICAg
Z2ZuOiAwMDAwNTI4MCAgbWZuOiAwMDAwNTI4MA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
MzowN10gICBnZm46IDAwMDA1MjgxICBtZm46IDAwMDA1MjgxDQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMzOjA3XSAgIGdmbjogMDAwMDUyODIgIG1mbjogMDAwMDUyODINCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzM6MDddICAgZ2ZuOiAwMDAwNTI4MyAgbWZuOiAwMDAwNTI4Mw0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzowN10gICBnZm46IDAwMDA1Mjg0ICBtZm46IDAw
MDA1Mjg0DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjA3XSAgIGdmbjogMDAwMDUyODUg
IG1mbjogMDAwMDUyODUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MDddICAgZ2ZuOiAw
MDAwNTI4NiAgbWZuOiAwMDAwNTI4Ng0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzowN10g
ICBnZm46IDAwMDA1Mjg3ICBtZm46IDAwMDA1Mjg3DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMzOjA3XSAgIGdmbjogMDAwMDUyODggIG1mbjogMDAwMDUyODgNCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzM6MDddICAgZ2ZuOiAwMDAwNTI4OSAgbWZuOiAwMDAwNTI4OQ0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMzowN10gICBnZm46IDAwMDA1MjhhICBtZm46IDAwMDA1Mjhh
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjA3XSAgIGdmbjogMDAwMDUyOGIgIG1mbjog
MDAwMDUyOGINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MDddICAgZ2ZuOiAwMDAwNTI4
YyAgbWZuOiAwMDAwNTI4Yw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzowN10gICBnZm46
IDAwMDA1MjhkICBtZm46IDAwMDA1MjhkDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjA3
XSAgIGdmbjogMDAwMDUyOGUgIG1mbjogMDAwMDUyOGUNCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzM6MDddICAgZ2ZuOiAwMDAwNTI4ZiAgbWZuOiAwMDAwNTI4Zg0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMzowN10gICBnZm46IDAwMDA1MjkwICBtZm46IDAwMDA1MjkwDQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMzOjA3XSAgIGdmbjogMDAwMDUyOTEgIG1mbjogMDAwMDUy
OTENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MDddICAgZ2ZuOiAwMDAwNTI5MiAgbWZu
OiAwMDAwNTI5Mg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzowN10gICBnZm46IDAwMDA1
MjkzICBtZm46IDAwMDA1MjkzDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjA3XSAgIGdm
bjogMDAwMDUyOTQgIG1mbjogMDAwMDUyOTQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6
MDddICAgZ2ZuOiAwMDAwNTI5NSAgbWZuOiAwMDAwNTI5NQ0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMzowN10gICBnZm46IDAwMDA1Mjk2ICBtZm46IDAwMDA1Mjk2DQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMzOjA3XSAgIGdmbjogMDAwMDUyOTcgIG1mbjogMDAwMDUyOTcNCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MDddICAgZ2ZuOiAwMDAwNTI5OCAgbWZuOiAwMDAw
NTI5OA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzowN10gICBnZm46IDAwMDA1Mjk5ICBt
Zm46IDAwMDA1Mjk5DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjA3XSAgIGdmbjogMDAw
MDUyOWEgIG1mbjogMDAwMDUyOWENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MDddICAg
Z2ZuOiAwMDAwNTI5YiAgbWZuOiAwMDAwNTI5Yg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
MzowN10gICBnZm46IDAwMDA1MjljICBtZm46IDAwMDA1MjljDQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMzOjA3XSAgIGdmbjogMDAwMDUyOWQgIG1mbjogMDAwMDUyOWQNCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzM6MDddICAgZ2ZuOiAwMDAwNTI5ZSAgbWZuOiAwMDAwNTI5ZQ0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzowN10gICBnZm46IDAwMDA1MjlmICBtZm46IDAw
MDA1MjlmDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjA3XSAgIGdmbjogMDAwMDUyYTAg
IG1mbjogMDAwMDUyYTANCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MDddICAgZ2ZuOiAw
MDAwNTJhMSAgbWZuOiAwMDAwNTJhMQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzowN10g
ICBnZm46IDAwMDA1MmEyICBtZm46IDAwMDA1MmEyDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMzOjA3XSAgIGdmbjogMDAwMDUyYTMgIG1mbjogMDAwMDUyYTMNCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzM6MDddICAgZ2ZuOiAwMDAwNTJhNCAgbWZuOiAwMDAwNTJhNA0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMzowN10gICBnZm46IDAwMDA1MmE1ICBtZm46IDAwMDA1MmE1
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjA3XSAgIGdmbjogMDAwMDUyYTYgIG1mbjog
MDAwMDUyYTYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MDddICAgZ2ZuOiAwMDAwNTJh
NyAgbWZuOiAwMDAwNTJhNw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzowN10gICBnZm46
IDAwMDA1MmE4ICBtZm46IDAwMDA1MmE4DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjA3
XSAgIGdmbjogMDAwMDUyYTkgIG1mbjogMDAwMDUyYTkNCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzM6MDddICAgZ2ZuOiAwMDAwNTJhYSAgbWZuOiAwMDAwNTJhYQ0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMzowN10gICBnZm46IDAwMDA1MmFiICBtZm46IDAwMDA1MmFiDQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMzOjA3XSAgIGdmbjogMDAwMDUyYWMgIG1mbjogMDAwMDUy
YWMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MDddICAgZ2ZuOiAwMDAwNTJhZCAgbWZu
OiAwMDAwNTJhZA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzowN10gICBnZm46IDAwMDA1
MmFlICBtZm46IDAwMDA1MmFlDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjA4XSAgIGdm
bjogMDAwMDUyYWYgIG1mbjogMDAwMDUyYWYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6
MDhdICAgZ2ZuOiAwMDAwNTJiMCAgbWZuOiAwMDAwNTJiMA0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMzowOF0gICBnZm46IDAwMDA1MmIxICBtZm46IDAwMDA1MmIxDQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMzOjA4XSAgIGdmbjogMDAwMDUyYjIgIG1mbjogMDAwMDUyYjINCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MDhdICAgZ2ZuOiAwMDAwNTJiMyAgbWZuOiAwMDAw
NTJiMw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzowOF0gICBnZm46IDAwMDA1MmI0ICBt
Zm46IDAwMDA1MmI0DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjA4XSAgIGdmbjogMDAw
MDUyYjUgIG1mbjogMDAwMDUyYjUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MDhdICAg
Z2ZuOiAwMDAwNTJiNiAgbWZuOiAwMDAwNTJiNg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
MzowOF0gICBnZm46IDAwMDA1MmI3ICBtZm46IDAwMDA1MmI3DQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMzOjA4XSAgIGdmbjogMDAwMDUyYjggIG1mbjogMDAwMDUyYjgNCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzM6MDhdICAgZ2ZuOiAwMDAwNTJiOSAgbWZuOiAwMDAwNTJiOQ0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzowOF0gICBnZm46IDAwMDA1MmJhICBtZm46IDAw
MDA1MmJhDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjA4XSAgIGdmbjogMDAwMDUyYmIg
IG1mbjogMDAwMDUyYmINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MDhdICAgZ2ZuOiAw
MDAwNTJiYyAgbWZuOiAwMDAwNTJiYw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzowOF0g
ICBnZm46IDAwMDA1MmJkICBtZm46IDAwMDA1MmJkDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMzOjA4XSAgIGdmbjogMDAwMDUyYmUgIG1mbjogMDAwMDUyYmUNCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzM6MDhdICAgZ2ZuOiAwMDAwNTJiZiAgbWZuOiAwMDAwNTJiZg0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMzowOF0gICBnZm46IDAwMDA1MmMwICBtZm46IDAwMDA1MmMw
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjA4XSAgIGdmbjogMDAwMDUyYzEgIG1mbjog
MDAwMDUyYzENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MDhdICAgZ2ZuOiAwMDAwNTJj
MiAgbWZuOiAwMDAwNTJjMg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzowOF0gICBnZm46
IDAwMDA1MmMzICBtZm46IDAwMDA1MmMzDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjA4
XSAgIGdmbjogMDAwMDUyYzQgIG1mbjogMDAwMDUyYzQNCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzM6MDhdICAgZ2ZuOiAwMDAwNTJjNSAgbWZuOiAwMDAwNTJjNQ0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMzowOF0gICBnZm46IDAwMDA1MmM2ICBtZm46IDAwMDA1MmM2DQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMzOjA4XSAgIGdmbjogMDAwMDUyYzcgIG1mbjogMDAwMDUy
YzcNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MDhdICAgZ2ZuOiAwMDAwNTJjOCAgbWZu
OiAwMDAwNTJjOA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzowOF0gICBnZm46IDAwMDA1
MmM5ICBtZm46IDAwMDA1MmM5DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjA4XSAgIGdm
bjogMDAwMDUyY2EgIG1mbjogMDAwMDUyY2ENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6
MDhdICAgZ2ZuOiAwMDAwNTJjYiAgbWZuOiAwMDAwNTJjYg0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMzowOF0gICBnZm46IDAwMDA1MmNjICBtZm46IDAwMDA1MmNjDQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMzOjA4XSAgIGdmbjogMDAwMDUyY2QgIG1mbjogMDAwMDUyY2QNCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MDhdICAgZ2ZuOiAwMDAwNTJjZSAgbWZuOiAwMDAw
NTJjZQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzowOF0gICBnZm46IDAwMDA1MmNmICBt
Zm46IDAwMDA1MmNmDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjA4XSAgIGdmbjogMDAw
MDUyZDAgIG1mbjogMDAwMDUyZDANCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MDhdICAg
Z2ZuOiAwMDAwNTJkMSAgbWZuOiAwMDAwNTJkMQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
MzowOF0gICBnZm46IDAwMDA1MmQyICBtZm46IDAwMDA1MmQyDQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMzOjA4XSAgIGdmbjogMDAwMDUyZDMgIG1mbjogMDAwMDUyZDMNCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzM6MDhdICAgZ2ZuOiAwMDAwNTJkNCAgbWZuOiAwMDAwNTJkNA0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzowOF0gICBnZm46IDAwMDA1MmQ1ICBtZm46IDAw
MDA1MmQ1DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjA4XSAgIGdmbjogMDAwMDUyZDYg
IG1mbjogMDAwMDUyZDYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MDhdICAgZ2ZuOiAw
MDAwNTJkNyAgbWZuOiAwMDAwNTJkNw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzowOF0g
ICBnZm46IDAwMDA1MmQ4ICBtZm46IDAwMDA1MmQ4DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMzOjA4XSAgIGdmbjogMDAwMDUyZDkgIG1mbjogMDAwMDUyZDkNCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzM6MDhdICAgZ2ZuOiAwMDAwNTJkYSAgbWZuOiAwMDAwNTJkYQ0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMzowOF0gICBnZm46IDAwMDA1MmRiICBtZm46IDAwMDA1MmRi
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjA4XSAgIGdmbjogMDAwMDUyZGMgIG1mbjog
MDAwMDUyZGMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MDhdICAgZ2ZuOiAwMDAwNTJk
ZCAgbWZuOiAwMDAwNTJkZA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzowOF0gICBnZm46
IDAwMDA1MmRlICBtZm46IDAwMDA1MmRlDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjA4
XSAgIGdmbjogMDAwMDUyZGYgIG1mbjogMDAwMDUyZGYNCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzM6MDhdICAgZ2ZuOiAwMDAwNTJlMCAgbWZuOiAwMDAwNTJlMA0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMzowOF0gICBnZm46IDAwMDA1MmUxICBtZm46IDAwMDA1MmUxDQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMzOjA4XSAgIGdmbjogMDAwMDUyZTIgIG1mbjogMDAwMDUy
ZTINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MDhdICAgZ2ZuOiAwMDAwNTJlMyAgbWZu
OiAwMDAwNTJlMw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzowOF0gICBnZm46IDAwMDA1
MmU0ICBtZm46IDAwMDA1MmU0DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjA4XSAgIGdm
bjogMDAwMDUyZTUgIG1mbjogMDAwMDUyZTUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6
MDhdICAgZ2ZuOiAwMDAwNTJlNiAgbWZuOiAwMDAwNTJlNg0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMzowOF0gICBnZm46IDAwMDA1MmU3ICBtZm46IDAwMDA1MmU3DQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMzOjA4XSAgIGdmbjogMDAwMDUyZTggIG1mbjogMDAwMDUyZTgNCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MDhdICAgZ2ZuOiAwMDAwNTJlOSAgbWZuOiAwMDAw
NTJlOQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzowOF0gICBnZm46IDAwMDA1MmVhICBt
Zm46IDAwMDA1MmVhDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjA4XSAgIGdmbjogMDAw
MDUyZWIgIG1mbjogMDAwMDUyZWINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MDhdICAg
Z2ZuOiAwMDAwNTJlYyAgbWZuOiAwMDAwNTJlYw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
MzowOF0gICBnZm46IDAwMDA1MmVkICBtZm46IDAwMDA1MmVkDQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMzOjA4XSAgIGdmbjogMDAwMDUyZWUgIG1mbjogMDAwMDUyZWUNCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzM6MDldICAgZ2ZuOiAwMDAwNTJlZiAgbWZuOiAwMDAwNTJlZg0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzowOV0gICBnZm46IDAwMDA1MmYwICBtZm46IDAw
MDA1MmYwDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjA5XSAgIGdmbjogMDAwMDUyZjEg
IG1mbjogMDAwMDUyZjENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MDldICAgZ2ZuOiAw
MDAwNTJmMiAgbWZuOiAwMDAwNTJmMg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzowOV0g
ICBnZm46IDAwMDA1MmYzICBtZm46IDAwMDA1MmYzDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMzOjA5XSAgIGdmbjogMDAwMDUyZjQgIG1mbjogMDAwMDUyZjQNCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzM6MDldICAgZ2ZuOiAwMDAwNTJmNSAgbWZuOiAwMDAwNTJmNQ0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMzowOV0gICBnZm46IDAwMDA1MmY2ICBtZm46IDAwMDA1MmY2
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjA5XSAgIGdmbjogMDAwMDUyZjcgIG1mbjog
MDAwMDUyZjcNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MDldICAgZ2ZuOiAwMDAwNTJm
OCAgbWZuOiAwMDAwNTJmOA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzowOV0gICBnZm46
IDAwMDA1MmY5ICBtZm46IDAwMDA1MmY5DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjA5
XSAgIGdmbjogMDAwMDUyZmEgIG1mbjogMDAwMDUyZmENCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzM6MDldICAgZ2ZuOiAwMDAwNTJmYiAgbWZuOiAwMDAwNTJmYg0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMzowOV0gICBnZm46IDAwMDA1MmZjICBtZm46IDAwMDA1MmZjDQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMzOjA5XSAgIGdmbjogMDAwMDUyZmQgIG1mbjogMDAwMDUy
ZmQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MDldICAgZ2ZuOiAwMDAwNTJmZSAgbWZu
OiAwMDAwNTJmZQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzowOV0gICBnZm46IDAwMDA1
MmZmICBtZm46IDAwMDA1MmZmDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjA5XSAgIGdm
bjogMDAwMDUzMDAgIG1mbjogMDAwMDUzMDANCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6
MDldICAgZ2ZuOiAwMDAwNTMwMSAgbWZuOiAwMDAwNTMwMQ0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMzowOV0gICBnZm46IDAwMDA1MzAyICBtZm46IDAwMDA1MzAyDQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMzOjA5XSAgIGdmbjogMDAwMDUzMDMgIG1mbjogMDAwMDUzMDMNCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MDldICAgZ2ZuOiAwMDAwNTMwNCAgbWZuOiAwMDAw
NTMwNA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzowOV0gICBnZm46IDAwMDA1MzA1ICBt
Zm46IDAwMDA1MzA1DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjA5XSAgIGdmbjogMDAw
MDUzMDYgIG1mbjogMDAwMDUzMDYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MDldICAg
Z2ZuOiAwMDAwNTMwNyAgbWZuOiAwMDAwNTMwNw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
MzowOV0gICBnZm46IDAwMDA1MzA4ICBtZm46IDAwMDA1MzA4DQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMzOjA5XSAgIGdmbjogMDAwMDUzMDkgIG1mbjogMDAwMDUzMDkNCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzM6MDldICAgZ2ZuOiAwMDAwNTMwYSAgbWZuOiAwMDAwNTMwYQ0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzowOV0gICBnZm46IDAwMDA1MzBiICBtZm46IDAw
MDA1MzBiDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjA5XSAgIGdmbjogMDAwMDUzMGMg
IG1mbjogMDAwMDUzMGMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MDldICAgZ2ZuOiAw
MDAwNTMwZCAgbWZuOiAwMDAwNTMwZA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzowOV0g
ICBnZm46IDAwMDA1MzBlICBtZm46IDAwMDA1MzBlDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMzOjA5XSAgIGdmbjogMDAwMDUzMGYgIG1mbjogMDAwMDUzMGYNCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzM6MDldICAgZ2ZuOiAwMDAwNTMxMCAgbWZuOiAwMDAwNTMxMA0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMzowOV0gICBnZm46IDAwMDA1MzExICBtZm46IDAwMDA1MzEx
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjA5XSAgIGdmbjogMDAwMDUzMTIgIG1mbjog
MDAwMDUzMTINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MDldICAgZ2ZuOiAwMDAwNTMx
MyAgbWZuOiAwMDAwNTMxMw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzowOV0gICBnZm46
IDAwMDA1MzE0ICBtZm46IDAwMDA1MzE0DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjA5
XSAgIGdmbjogMDAwMDUzMTUgIG1mbjogMDAwMDUzMTUNCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzM6MDldICAgZ2ZuOiAwMDAwNTMxNiAgbWZuOiAwMDAwNTMxNg0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMzowOV0gICBnZm46IDAwMDA1MzE3ICBtZm46IDAwMDA1MzE3DQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMzOjA5XSAgIGdmbjogMDAwMDUzMTggIG1mbjogMDAwMDUz
MTgNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MDldICAgZ2ZuOiAwMDAwNTMxOSAgbWZu
OiAwMDAwNTMxOQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzowOV0gICBnZm46IDAwMDA1
MzFhICBtZm46IDAwMDA1MzFhDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjA5XSAgIGdm
bjogMDAwMDUzMWIgIG1mbjogMDAwMDUzMWINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6
MDldICAgZ2ZuOiAwMDAwNTMxYyAgbWZuOiAwMDAwNTMxYw0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMzowOV0gICBnZm46IDAwMDA1MzFkICBtZm46IDAwMDA1MzFkDQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMzOjA5XSAgIGdmbjogMDAwMDUzMWUgIG1mbjogMDAwMDUzMWUNCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MDldICAgZ2ZuOiAwMDAwNTMxZiAgbWZuOiAwMDAw
NTMxZg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzowOV0gICBnZm46IDAwMDA1MzIwICBt
Zm46IDAwMDA1MzIwDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjA5XSAgIGdmbjogMDAw
MDUzMjEgIG1mbjogMDAwMDUzMjENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MDldICAg
Z2ZuOiAwMDAwNTMyMiAgbWZuOiAwMDAwNTMyMg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
MzowOV0gICBnZm46IDAwMDA1MzIzICBtZm46IDAwMDA1MzIzDQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMzOjA5XSAgIGdmbjogMDAwMDUzMjQgIG1mbjogMDAwMDUzMjQNCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzM6MDldICAgZ2ZuOiAwMDAwNTMyNSAgbWZuOiAwMDAwNTMyNQ0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzowOV0gICBnZm46IDAwMDA1MzI2ICBtZm46IDAw
MDA1MzI2DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjA5XSAgIGdmbjogMDAwMDUzMjcg
IG1mbjogMDAwMDUzMjcNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MDldICAgZ2ZuOiAw
MDAwNTMyOCAgbWZuOiAwMDAwNTMyOA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzowOV0g
ICBnZm46IDAwMDA1MzI5ICBtZm46IDAwMDA1MzI5DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMzOjA5XSAgIGdmbjogMDAwMDUzMmEgIG1mbjogMDAwMDUzMmENCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzM6MDldICAgZ2ZuOiAwMDAwNTMyYiAgbWZuOiAwMDAwNTMyYg0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMzowOV0gICBnZm46IDAwMDA1MzJjICBtZm46IDAwMDA1MzJj
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjA5XSAgIGdmbjogMDAwMDUzMmQgIG1mbjog
MDAwMDUzMmQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MDldICAgZ2ZuOiAwMDAwNTMy
ZSAgbWZuOiAwMDAwNTMyZQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoxMF0gICBnZm46
IDAwMDA1MzJmICBtZm46IDAwMDA1MzJmDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjEw
XSAgIGdmbjogMDAwMDUzMzAgIG1mbjogMDAwMDUzMzANCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzM6MTBdICAgZ2ZuOiAwMDAwNTMzMSAgbWZuOiAwMDAwNTMzMQ0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMzoxMF0gICBnZm46IDAwMDA1MzMyICBtZm46IDAwMDA1MzMyDQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMzOjEwXSAgIGdmbjogMDAwMDUzMzMgIG1mbjogMDAwMDUz
MzMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MTBdICAgZ2ZuOiAwMDAwNTMzNCAgbWZu
OiAwMDAwNTMzNA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoxMF0gICBnZm46IDAwMDA1
MzM1ICBtZm46IDAwMDA1MzM1DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjEwXSAgIGdm
bjogMDAwMDUzMzYgIG1mbjogMDAwMDUzMzYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6
MTBdICAgZ2ZuOiAwMDAwNTMzNyAgbWZuOiAwMDAwNTMzNw0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMzoxMF0gICBnZm46IDAwMDA1MzM4ICBtZm46IDAwMDA1MzM4DQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMzOjEwXSAgIGdmbjogMDAwMDUzMzkgIG1mbjogMDAwMDUzMzkNCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MTBdICAgZ2ZuOiAwMDAwNTMzYSAgbWZuOiAwMDAw
NTMzYQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoxMF0gICBnZm46IDAwMDA1MzNiICBt
Zm46IDAwMDA1MzNiDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjEwXSAgIGdmbjogMDAw
MDUzM2MgIG1mbjogMDAwMDUzM2MNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MTBdICAg
Z2ZuOiAwMDAwNTMzZCAgbWZuOiAwMDAwNTMzZA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
MzoxMF0gICBnZm46IDAwMDA1MzNlICBtZm46IDAwMDA1MzNlDQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMzOjEwXSAgIGdmbjogMDAwMDUzM2YgIG1mbjogMDAwMDUzM2YNCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzM6MTBdICAgZ2ZuOiAwMDAwNTM0MCAgbWZuOiAwMDAwNTM0MA0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoxMF0gICBnZm46IDAwMDA1MzQxICBtZm46IDAw
MDA1MzQxDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjEwXSAgIGdmbjogMDAwMDUzNDIg
IG1mbjogMDAwMDUzNDINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MTBdICAgZ2ZuOiAw
MDAwNTM0MyAgbWZuOiAwMDAwNTM0Mw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoxMF0g
ICBnZm46IDAwMDA1MzQ0ICBtZm46IDAwMDA1MzQ0DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMzOjEwXSAgIGdmbjogMDAwMDUzNDUgIG1mbjogMDAwMDUzNDUNCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzM6MTBdICAgZ2ZuOiAwMDAwNTM0NiAgbWZuOiAwMDAwNTM0Ng0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMzoxMF0gICBnZm46IDAwMDA1MzQ3ICBtZm46IDAwMDA1MzQ3
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjEwXSAgIGdmbjogMDAwMDUzNDggIG1mbjog
MDAwMDUzNDgNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MTBdICAgZ2ZuOiAwMDAwNTM0
OSAgbWZuOiAwMDAwNTM0OQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoxMF0gICBnZm46
IDAwMDA1MzRhICBtZm46IDAwMDA1MzRhDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjEw
XSAgIGdmbjogMDAwMDUzNGIgIG1mbjogMDAwMDUzNGINCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzM6MTBdICAgZ2ZuOiAwMDAwNTM0YyAgbWZuOiAwMDAwNTM0Yw0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMzoxMF0gICBnZm46IDAwMDA1MzRkICBtZm46IDAwMDA1MzRkDQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMzOjEwXSAgIGdmbjogMDAwMDUzNGUgIG1mbjogMDAwMDUz
NGUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MTBdICAgZ2ZuOiAwMDAwNTM0ZiAgbWZu
OiAwMDAwNTM0Zg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoxMF0gICBnZm46IDAwMDA1
MzUwICBtZm46IDAwMDA1MzUwDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjEwXSAgIGdm
bjogMDAwMDUzNTEgIG1mbjogMDAwMDUzNTENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6
MTBdICAgZ2ZuOiAwMDAwNTM1MiAgbWZuOiAwMDAwNTM1Mg0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMzoxMF0gICBnZm46IDAwMDA1MzUzICBtZm46IDAwMDA1MzUzDQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMzOjEwXSAgIGdmbjogMDAwMDUzNTQgIG1mbjogMDAwMDUzNTQNCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MTBdICAgZ2ZuOiAwMDAwNTM1NSAgbWZuOiAwMDAw
NTM1NQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoxMF0gICBnZm46IDAwMDA1MzU2ICBt
Zm46IDAwMDA1MzU2DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjEwXSAgIGdmbjogMDAw
MDUzNTcgIG1mbjogMDAwMDUzNTcNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MTBdICAg
Z2ZuOiAwMDAwNTM1OCAgbWZuOiAwMDAwNTM1OA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
MzoxMF0gICBnZm46IDAwMDA1MzU5ICBtZm46IDAwMDA1MzU5DQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMzOjEwXSAgIGdmbjogMDAwMDUzNWEgIG1mbjogMDAwMDUzNWENCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzM6MTBdICAgZ2ZuOiAwMDAwNTM1YiAgbWZuOiAwMDAwNTM1Yg0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoxMF0gICBnZm46IDAwMDA1MzVjICBtZm46IDAw
MDA1MzVjDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjEwXSAgIGdmbjogMDAwMDUzNWQg
IG1mbjogMDAwMDUzNWQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MTBdICAgZ2ZuOiAw
MDAwNTM1ZSAgbWZuOiAwMDAwNTM1ZQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoxMF0g
ICBnZm46IDAwMDA1MzVmICBtZm46IDAwMDA1MzVmDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMzOjEwXSAgIGdmbjogMDAwMDUzNjAgIG1mbjogMDAwMDUzNjANCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzM6MTBdICAgZ2ZuOiAwMDAwNTM2MSAgbWZuOiAwMDAwNTM2MQ0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMzoxMF0gICBnZm46IDAwMDA1MzYyICBtZm46IDAwMDA1MzYy
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjEwXSAgIGdmbjogMDAwMDUzNjMgIG1mbjog
MDAwMDUzNjMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MTBdICAgZ2ZuOiAwMDAwNTM2
NCAgbWZuOiAwMDAwNTM2NA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoxMF0gICBnZm46
IDAwMDA1MzY1ICBtZm46IDAwMDA1MzY1DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjEw
XSAgIGdmbjogMDAwMDUzNjYgIG1mbjogMDAwMDUzNjYNCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzM6MTBdICAgZ2ZuOiAwMDAwNTM2NyAgbWZuOiAwMDAwNTM2Nw0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMzoxMF0gICBnZm46IDAwMDA1MzY4ICBtZm46IDAwMDA1MzY4DQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMzOjEwXSAgIGdmbjogMDAwMDUzNjkgIG1mbjogMDAwMDUz
NjkNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MTBdICAgZ2ZuOiAwMDAwNTM2YSAgbWZu
OiAwMDAwNTM2YQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoxMF0gICBnZm46IDAwMDA1
MzZiICBtZm46IDAwMDA1MzZiDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjEwXSAgIGdm
bjogMDAwMDUzNmMgIG1mbjogMDAwMDUzNmMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6
MTBdICAgZ2ZuOiAwMDAwNTM2ZCAgbWZuOiAwMDAwNTM2ZA0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMzoxMF0gICBnZm46IDAwMDA1MzZlICBtZm46IDAwMDA1MzZlDQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMzOjExXSAgIGdmbjogMDAwMDUzNmYgIG1mbjogMDAwMDUzNmYNCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MTFdICAgZ2ZuOiAwMDAwNTM3MCAgbWZuOiAwMDAw
NTM3MA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoxMV0gICBnZm46IDAwMDA1MzcxICBt
Zm46IDAwMDA1MzcxDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjExXSAgIGdmbjogMDAw
MDUzNzIgIG1mbjogMDAwMDUzNzINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MTFdICAg
Z2ZuOiAwMDAwNTM3MyAgbWZuOiAwMDAwNTM3Mw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
MzoxMV0gICBnZm46IDAwMDA1Mzc0ICBtZm46IDAwMDA1Mzc0DQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMzOjExXSAgIGdmbjogMDAwMDUzNzUgIG1mbjogMDAwMDUzNzUNCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzM6MTFdICAgZ2ZuOiAwMDAwNTM3NiAgbWZuOiAwMDAwNTM3Ng0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoxMV0gICBnZm46IDAwMDA1Mzc3ICBtZm46IDAw
MDA1Mzc3DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjExXSAgIGdmbjogMDAwMDUzNzgg
IG1mbjogMDAwMDUzNzgNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MTFdICAgZ2ZuOiAw
MDAwNTM3OSAgbWZuOiAwMDAwNTM3OQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoxMV0g
ICBnZm46IDAwMDA1MzdhICBtZm46IDAwMDA1MzdhDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMzOjExXSAgIGdmbjogMDAwMDUzN2IgIG1mbjogMDAwMDUzN2INCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzM6MTFdICAgZ2ZuOiAwMDAwNTM3YyAgbWZuOiAwMDAwNTM3Yw0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMzoxMV0gICBnZm46IDAwMDA1MzdkICBtZm46IDAwMDA1Mzdk
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjExXSAgIGdmbjogMDAwMDUzN2UgIG1mbjog
MDAwMDUzN2UNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MTFdICAgZ2ZuOiAwMDAwNTM3
ZiAgbWZuOiAwMDAwNTM3Zg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoxMV0gICBnZm46
IDAwMDA1MzgwICBtZm46IDAwMDA1MzgwDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjEx
XSAgIGdmbjogMDAwMDUzODEgIG1mbjogMDAwMDUzODENCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzM6MTFdICAgZ2ZuOiAwMDAwNTM4MiAgbWZuOiAwMDAwNTM4Mg0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMzoxMV0gICBnZm46IDAwMDA1MzgzICBtZm46IDAwMDA1MzgzDQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMzOjExXSAgIGdmbjogMDAwMDUzODQgIG1mbjogMDAwMDUz
ODQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MTFdICAgZ2ZuOiAwMDAwNTM4NSAgbWZu
OiAwMDAwNTM4NQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoxMV0gICBnZm46IDAwMDA1
Mzg2ICBtZm46IDAwMDA1Mzg2DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjExXSAgIGdm
bjogMDAwMDUzODcgIG1mbjogMDAwMDUzODcNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6
MTFdICAgZ2ZuOiAwMDAwNTM4OCAgbWZuOiAwMDAwNTM4OA0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMzoxMV0gICBnZm46IDAwMDA1Mzg5ICBtZm46IDAwMDA1Mzg5DQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMzOjExXSAgIGdmbjogMDAwMDUzOGEgIG1mbjogMDAwMDUzOGENCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MTFdICAgZ2ZuOiAwMDAwNTM4YiAgbWZuOiAwMDAw
NTM4Yg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoxMV0gICBnZm46IDAwMDA1MzhjICBt
Zm46IDAwMDA1MzhjDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjExXSAgIGdmbjogMDAw
MDUzOGQgIG1mbjogMDAwMDUzOGQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MTFdICAg
Z2ZuOiAwMDAwNTM4ZSAgbWZuOiAwMDAwNTM4ZQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
MzoxMV0gICBnZm46IDAwMDA1MzhmICBtZm46IDAwMDA1MzhmDQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMzOjExXSAgIGdmbjogMDAwMDUzOTAgIG1mbjogMDAwMDUzOTANCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzM6MTFdICAgZ2ZuOiAwMDAwNTM5MSAgbWZuOiAwMDAwNTM5MQ0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoxMV0gICBnZm46IDAwMDA1MzkyICBtZm46IDAw
MDA1MzkyDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjExXSAgIGdmbjogMDAwMDUzOTMg
IG1mbjogMDAwMDUzOTMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MTFdICAgZ2ZuOiAw
MDAwNTM5NCAgbWZuOiAwMDAwNTM5NA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoxMV0g
ICBnZm46IDAwMDA1Mzk1ICBtZm46IDAwMDA1Mzk1DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMzOjExXSAgIGdmbjogMDAwMDUzOTYgIG1mbjogMDAwMDUzOTYNCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzM6MTFdICAgZ2ZuOiAwMDAwNTM5NyAgbWZuOiAwMDAwNTM5Nw0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMzoxMV0gICBnZm46IDAwMDA1Mzk4ICBtZm46IDAwMDA1Mzk4
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjExXSAgIGdmbjogMDAwMDUzOTkgIG1mbjog
MDAwMDUzOTkNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MTFdICAgZ2ZuOiAwMDAwNTM5
YSAgbWZuOiAwMDAwNTM5YQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoxMV0gICBnZm46
IDAwMDA1MzliICBtZm46IDAwMDA1MzliDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjEx
XSAgIGdmbjogMDAwMDUzOWMgIG1mbjogMDAwMDUzOWMNCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzM6MTFdICAgZ2ZuOiAwMDAwNTM5ZCAgbWZuOiAwMDAwNTM5ZA0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMzoxMV0gICBnZm46IDAwMDA1MzllICBtZm46IDAwMDA1MzllDQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMzOjExXSAgIGdmbjogMDAwMDUzOWYgIG1mbjogMDAwMDUz
OWYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MTFdICAgZ2ZuOiAwMDAwNTNhMCAgbWZu
OiAwMDAwNTNhMA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoxMV0gICBnZm46IDAwMDA1
M2ExICBtZm46IDAwMDA1M2ExDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjExXSAgIGdm
bjogMDAwMDUzYTIgIG1mbjogMDAwMDUzYTINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6
MTFdICAgZ2ZuOiAwMDAwNTNhMyAgbWZuOiAwMDAwNTNhMw0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMzoxMV0gICBnZm46IDAwMDA1M2E0ICBtZm46IDAwMDA1M2E0DQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMzOjExXSAgIGdmbjogMDAwMDUzYTUgIG1mbjogMDAwMDUzYTUNCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MTFdICAgZ2ZuOiAwMDAwNTNhNiAgbWZuOiAwMDAw
NTNhNg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoxMV0gICBnZm46IDAwMDA1M2E3ICBt
Zm46IDAwMDA1M2E3DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjExXSAgIGdmbjogMDAw
MDUzYTggIG1mbjogMDAwMDUzYTgNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MTFdICAg
Z2ZuOiAwMDAwNTNhOSAgbWZuOiAwMDAwNTNhOQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
MzoxMV0gICBnZm46IDAwMDA1M2FhICBtZm46IDAwMDA1M2FhDQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMzOjExXSAgIGdmbjogMDAwMDUzYWIgIG1mbjogMDAwMDUzYWINCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzM6MTFdICAgZ2ZuOiAwMDAwNTNhYyAgbWZuOiAwMDAwNTNhYw0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoxMV0gICBnZm46IDAwMDA1M2FkICBtZm46IDAw
MDA1M2FkDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjExXSAgIGdmbjogMDAwMDUzYWUg
IG1mbjogMDAwMDUzYWUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MTJdICAgZ2ZuOiAw
MDAwNTNhZiAgbWZuOiAwMDAwNTNhZg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoxMl0g
ICBnZm46IDAwMDA1M2IwICBtZm46IDAwMDA1M2IwDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMzOjEyXSAgIGdmbjogMDAwMDUzYjEgIG1mbjogMDAwMDUzYjENCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzM6MTJdICAgZ2ZuOiAwMDAwNTNiMiAgbWZuOiAwMDAwNTNiMg0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMzoxMl0gICBnZm46IDAwMDA1M2IzICBtZm46IDAwMDA1M2Iz
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjEyXSAgIGdmbjogMDAwMDUzYjQgIG1mbjog
MDAwMDUzYjQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MTJdICAgZ2ZuOiAwMDAwNTNi
NSAgbWZuOiAwMDAwNTNiNQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoxMl0gICBnZm46
IDAwMDA1M2I2ICBtZm46IDAwMDA1M2I2DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjEy
XSAgIGdmbjogMDAwMDUzYjcgIG1mbjogMDAwMDUzYjcNCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzM6MTJdICAgZ2ZuOiAwMDAwNTNiOCAgbWZuOiAwMDAwNTNiOA0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMzoxMl0gICBnZm46IDAwMDA1M2I5ICBtZm46IDAwMDA1M2I5DQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMzOjEyXSAgIGdmbjogMDAwMDUzYmEgIG1mbjogMDAwMDUz
YmENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MTJdICAgZ2ZuOiAwMDAwNTNiYiAgbWZu
OiAwMDAwNTNiYg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoxMl0gICBnZm46IDAwMDA1
M2JjICBtZm46IDAwMDA1M2JjDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjEyXSAgIGdm
bjogMDAwMDUzYmQgIG1mbjogMDAwMDUzYmQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6
MTJdICAgZ2ZuOiAwMDAwNTNiZSAgbWZuOiAwMDAwNTNiZQ0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMzoxMl0gICBnZm46IDAwMDA1M2JmICBtZm46IDAwMDA1M2JmDQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMzOjEyXSAgIGdmbjogMDAwMDUzYzAgIG1mbjogMDAwMDUzYzANCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MTJdICAgZ2ZuOiAwMDAwNTNjMSAgbWZuOiAwMDAw
NTNjMQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoxMl0gICBnZm46IDAwMDA1M2MyICBt
Zm46IDAwMDA1M2MyDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjEyXSAgIGdmbjogMDAw
MDUzYzMgIG1mbjogMDAwMDUzYzMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MTJdICAg
Z2ZuOiAwMDAwNTNjNCAgbWZuOiAwMDAwNTNjNA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
MzoxMl0gICBnZm46IDAwMDA1M2M1ICBtZm46IDAwMDA1M2M1DQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMzOjEyXSAgIGdmbjogMDAwMDUzYzYgIG1mbjogMDAwMDUzYzYNCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzM6MTJdICAgZ2ZuOiAwMDAwNTNjNyAgbWZuOiAwMDAwNTNjNw0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoxMl0gICBnZm46IDAwMDA1M2M4ICBtZm46IDAw
MDA1M2M4DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjEyXSAgIGdmbjogMDAwMDUzYzkg
IG1mbjogMDAwMDUzYzkNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MTJdICAgZ2ZuOiAw
MDAwNTNjYSAgbWZuOiAwMDAwNTNjYQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoxMl0g
ICBnZm46IDAwMDA1M2NiICBtZm46IDAwMDA1M2NiDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMzOjEyXSAgIGdmbjogMDAwMDUzY2MgIG1mbjogMDAwMDUzY2MNCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzM6MTJdICAgZ2ZuOiAwMDAwNTNjZCAgbWZuOiAwMDAwNTNjZA0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMzoxMl0gICBnZm46IDAwMDA1M2NlICBtZm46IDAwMDA1M2Nl
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjEyXSAgIGdmbjogMDAwMDUzY2YgIG1mbjog
MDAwMDUzY2YNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MTJdICAgZ2ZuOiAwMDAwNTNk
MCAgbWZuOiAwMDAwNTNkMA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoxMl0gICBnZm46
IDAwMDA1M2QxICBtZm46IDAwMDA1M2QxDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjEy
XSAgIGdmbjogMDAwMDUzZDIgIG1mbjogMDAwMDUzZDINCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzM6MTJdICAgZ2ZuOiAwMDAwNTNkMyAgbWZuOiAwMDAwNTNkMw0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMzoxMl0gICBnZm46IDAwMDA1M2Q0ICBtZm46IDAwMDA1M2Q0DQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMzOjEyXSAgIGdmbjogMDAwMDUzZDUgIG1mbjogMDAwMDUz
ZDUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MTJdICAgZ2ZuOiAwMDAwNTNkNiAgbWZu
OiAwMDAwNTNkNg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoxMl0gICBnZm46IDAwMDA1
M2Q3ICBtZm46IDAwMDA1M2Q3DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjEyXSAgIGdm
bjogMDAwMDUzZDggIG1mbjogMDAwMDUzZDgNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6
MTJdICAgZ2ZuOiAwMDAwNTNkOSAgbWZuOiAwMDAwNTNkOQ0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMzoxMl0gICBnZm46IDAwMDA1M2RhICBtZm46IDAwMDA1M2RhDQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMzOjEyXSAgIGdmbjogMDAwMDUzZGIgIG1mbjogMDAwMDUzZGINCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MTJdICAgZ2ZuOiAwMDAwNTNkYyAgbWZuOiAwMDAw
NTNkYw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoxMl0gICBnZm46IDAwMDA1M2RkICBt
Zm46IDAwMDA1M2RkDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjEyXSAgIGdmbjogMDAw
MDUzZGUgIG1mbjogMDAwMDUzZGUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MTJdICAg
Z2ZuOiAwMDAwNTNkZiAgbWZuOiAwMDAwNTNkZg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
MzoxMl0gICBnZm46IDAwMDA1M2UwICBtZm46IDAwMDA1M2UwDQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMzOjEyXSAgIGdmbjogMDAwMDUzZTEgIG1mbjogMDAwMDUzZTENCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzM6MTJdICAgZ2ZuOiAwMDAwNTNlMiAgbWZuOiAwMDAwNTNlMg0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoxMl0gICBnZm46IDAwMDA1M2UzICBtZm46IDAw
MDA1M2UzDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjEyXSAgIGdmbjogMDAwMDUzZTQg
IG1mbjogMDAwMDUzZTQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MTJdICAgZ2ZuOiAw
MDAwNTNlNSAgbWZuOiAwMDAwNTNlNQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoxMl0g
ICBnZm46IDAwMDA1M2U2ICBtZm46IDAwMDA1M2U2DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMzOjEyXSAgIGdmbjogMDAwMDUzZTcgIG1mbjogMDAwMDUzZTcNCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzM6MTJdICAgZ2ZuOiAwMDAwNTNlOCAgbWZuOiAwMDAwNTNlOA0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMzoxMl0gICBnZm46IDAwMDA1M2U5ICBtZm46IDAwMDA1M2U5
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjEyXSAgIGdmbjogMDAwMDUzZWEgIG1mbjog
MDAwMDUzZWENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MTJdICAgZ2ZuOiAwMDAwNTNl
YiAgbWZuOiAwMDAwNTNlYg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoxMl0gICBnZm46
IDAwMDA1M2VjICBtZm46IDAwMDA1M2VjDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjEy
XSAgIGdmbjogMDAwMDUzZWQgIG1mbjogMDAwMDUzZWQNCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzM6MTJdICAgZ2ZuOiAwMDAwNTNlZSAgbWZuOiAwMDAwNTNlZQ0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMzoxM10gICBnZm46IDAwMDA1M2VmICBtZm46IDAwMDA1M2VmDQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMzOjEzXSAgIGdmbjogMDAwMDUzZjAgIG1mbjogMDAwMDUz
ZjANCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MTNdICAgZ2ZuOiAwMDAwNTNmMSAgbWZu
OiAwMDAwNTNmMQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoxM10gICBnZm46IDAwMDA1
M2YyICBtZm46IDAwMDA1M2YyDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjEzXSAgIGdm
bjogMDAwMDUzZjMgIG1mbjogMDAwMDUzZjMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6
MTNdICAgZ2ZuOiAwMDAwNTNmNCAgbWZuOiAwMDAwNTNmNA0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMzoxM10gICBnZm46IDAwMDA1M2Y1ICBtZm46IDAwMDA1M2Y1DQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMzOjEzXSAgIGdmbjogMDAwMDUzZjYgIG1mbjogMDAwMDUzZjYNCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MTNdICAgZ2ZuOiAwMDAwNTNmNyAgbWZuOiAwMDAw
NTNmNw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoxM10gICBnZm46IDAwMDA1M2Y4ICBt
Zm46IDAwMDA1M2Y4DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjEzXSAgIGdmbjogMDAw
MDUzZjkgIG1mbjogMDAwMDUzZjkNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MTNdICAg
Z2ZuOiAwMDAwNTNmYSAgbWZuOiAwMDAwNTNmYQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
MzoxM10gICBnZm46IDAwMDA1M2ZiICBtZm46IDAwMDA1M2ZiDQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMzOjEzXSAgIGdmbjogMDAwMDUzZmMgIG1mbjogMDAwMDUzZmMNCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzM6MTNdICAgZ2ZuOiAwMDAwNTNmZCAgbWZuOiAwMDAwNTNmZA0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoxM10gICBnZm46IDAwMDA1M2ZlICBtZm46IDAw
MDA1M2ZlDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjEzXSAgIGdmbjogMDAwMDUzZmYg
IG1mbjogMDAwMDUzZmYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MTNdICAgZ2ZuOiAw
MDAwNTQwMCAgbWZuOiAwMDAwNTQwMA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoxM10g
ICBnZm46IDAwMDA1NDAxICBtZm46IDAwMDA1NDAxDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMzOjEzXSAgIGdmbjogMDAwMDU0MDIgIG1mbjogMDAwMDU0MDINCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzM6MTNdICAgZ2ZuOiAwMDAwNTQwMyAgbWZuOiAwMDAwNTQwMw0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMzoxM10gICBnZm46IDAwMDA1NDA0ICBtZm46IDAwMDA1NDA0
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjEzXSAgIGdmbjogMDAwMDU0MDUgIG1mbjog
MDAwMDU0MDUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MTNdICAgZ2ZuOiAwMDAwNTQw
NiAgbWZuOiAwMDAwNTQwNg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoxM10gICBnZm46
IDAwMDA1NDA3ICBtZm46IDAwMDA1NDA3DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjEz
XSAgIGdmbjogMDAwMDU0MDggIG1mbjogMDAwMDU0MDgNCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzM6MTNdICAgZ2ZuOiAwMDAwNTQwOSAgbWZuOiAwMDAwNTQwOQ0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMzoxM10gICBnZm46IDAwMDA1NDBhICBtZm46IDAwMDA1NDBhDQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMzOjEzXSAgIGdmbjogMDAwMDU0MGIgIG1mbjogMDAwMDU0
MGINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MTNdICAgZ2ZuOiAwMDAwNTQwYyAgbWZu
OiAwMDAwNTQwYw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoxM10gICBnZm46IDAwMDA1
NDBkICBtZm46IDAwMDA1NDBkDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjEzXSAgIGdm
bjogMDAwMDU0MGUgIG1mbjogMDAwMDU0MGUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6
MTNdICAgZ2ZuOiAwMDAwNTQwZiAgbWZuOiAwMDAwNTQwZg0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMzoxM10gICBnZm46IDAwMDA1NDEwICBtZm46IDAwMDA1NDEwDQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMzOjEzXSAgIGdmbjogMDAwMDU0MTEgIG1mbjogMDAwMDU0MTENCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MTNdICAgZ2ZuOiAwMDAwNTQxMiAgbWZuOiAwMDAw
NTQxMg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoxM10gICBnZm46IDAwMDA1NDEzICBt
Zm46IDAwMDA1NDEzDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjEzXSAgIGdmbjogMDAw
MDU0MTQgIG1mbjogMDAwMDU0MTQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MTNdICAg
Z2ZuOiAwMDAwNTQxNSAgbWZuOiAwMDAwNTQxNQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
MzoxM10gICBnZm46IDAwMDA1NDE2ICBtZm46IDAwMDA1NDE2DQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMzOjEzXSAgIGdmbjogMDAwMDU0MTcgIG1mbjogMDAwMDU0MTcNCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzM6MTNdICAgZ2ZuOiAwMDAwNTQxOCAgbWZuOiAwMDAwNTQxOA0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoxM10gICBnZm46IDAwMDA1NDE5ICBtZm46IDAw
MDA1NDE5DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjEzXSAgIGdmbjogMDAwMDU0MWEg
IG1mbjogMDAwMDU0MWENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MTNdICAgZ2ZuOiAw
MDAwNTQxYiAgbWZuOiAwMDAwNTQxYg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoxM10g
ICBnZm46IDAwMDA1NDFjICBtZm46IDAwMDA1NDFjDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMzOjEzXSAgIGdmbjogMDAwMDU0MWQgIG1mbjogMDAwMDU0MWQNCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzM6MTNdICAgZ2ZuOiAwMDAwNTQxZSAgbWZuOiAwMDAwNTQxZQ0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMzoxM10gICBnZm46IDAwMDA1NDFmICBtZm46IDAwMDA1NDFm
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjEzXSAgIGdmbjogMDAwMDU0MjAgIG1mbjog
MDAwMDU0MjANCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MTNdICAgZ2ZuOiAwMDAwNTQy
MSAgbWZuOiAwMDAwNTQyMQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoxM10gICBnZm46
IDAwMDA1NDIyICBtZm46IDAwMDA1NDIyDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjEz
XSAgIGdmbjogMDAwMDU0MjMgIG1mbjogMDAwMDU0MjMNCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzM6MTNdICAgZ2ZuOiAwMDAwNTQyNCAgbWZuOiAwMDAwNTQyNA0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMzoxM10gICBnZm46IDAwMDA1NDI1ICBtZm46IDAwMDA1NDI1DQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMzOjEzXSAgIGdmbjogMDAwMDU0MjYgIG1mbjogMDAwMDU0
MjYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MTNdICAgZ2ZuOiAwMDAwNTQyNyAgbWZu
OiAwMDAwNTQyNw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoxM10gICBnZm46IDAwMDA1
NDI4ICBtZm46IDAwMDA1NDI4DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjEzXSAgIGdm
bjogMDAwMDU0MjkgIG1mbjogMDAwMDU0MjkNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6
MTNdICAgZ2ZuOiAwMDAwNTQyYSAgbWZuOiAwMDAwNTQyYQ0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMzoxM10gICBnZm46IDAwMDA1NDJiICBtZm46IDAwMDA1NDJiDQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMzOjEzXSAgIGdmbjogMDAwMDU0MmMgIG1mbjogMDAwMDU0MmMNCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MTNdICAgZ2ZuOiAwMDAwNTQyZCAgbWZuOiAwMDAw
NTQyZA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoxM10gICBnZm46IDAwMDA1NDJlICBt
Zm46IDAwMDA1NDJlDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjE0XSAgIGdmbjogMDAw
MDU0MmYgIG1mbjogMDAwMDU0MmYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MTRdICAg
Z2ZuOiAwMDAwNTQzMCAgbWZuOiAwMDAwNTQzMA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
MzoxNF0gICBnZm46IDAwMDA1NDMxICBtZm46IDAwMDA1NDMxDQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMzOjE0XSAgIGdmbjogMDAwMDU0MzIgIG1mbjogMDAwMDU0MzINCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzM6MTRdICAgZ2ZuOiAwMDAwNTQzMyAgbWZuOiAwMDAwNTQzMw0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoxNF0gICBnZm46IDAwMDA1NDM0ICBtZm46IDAw
MDA1NDM0DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjE0XSAgIGdmbjogMDAwMDU0MzUg
IG1mbjogMDAwMDU0MzUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MTRdICAgZ2ZuOiAw
MDAwNTQzNiAgbWZuOiAwMDAwNTQzNg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoxNF0g
ICBnZm46IDAwMDA1NDM3ICBtZm46IDAwMDA1NDM3DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMzOjE0XSAgIGdmbjogMDAwMDU0MzggIG1mbjogMDAwMDU0MzgNCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzM6MTRdICAgZ2ZuOiAwMDAwNTQzOSAgbWZuOiAwMDAwNTQzOQ0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMzoxNF0gICBnZm46IDAwMDA1NDNhICBtZm46IDAwMDA1NDNh
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjE0XSAgIGdmbjogMDAwMDU0M2IgIG1mbjog
MDAwMDU0M2INCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MTRdICAgZ2ZuOiAwMDAwNTQz
YyAgbWZuOiAwMDAwNTQzYw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoxNF0gICBnZm46
IDAwMDA1NDNkICBtZm46IDAwMDA1NDNkDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjE0
XSAgIGdmbjogMDAwMDU0M2UgIG1mbjogMDAwMDU0M2UNCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzM6MTRdICAgZ2ZuOiAwMDAwNTQzZiAgbWZuOiAwMDAwNTQzZg0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMzoxNF0gICBnZm46IDAwMDA1NDQwICBtZm46IDAwMDA1NDQwDQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMzOjE0XSAgIGdmbjogMDAwMDU0NDEgIG1mbjogMDAwMDU0
NDENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MTRdICAgZ2ZuOiAwMDAwNTQ0MiAgbWZu
OiAwMDAwNTQ0Mg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoxNF0gICBnZm46IDAwMDA1
NDQzICBtZm46IDAwMDA1NDQzDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjE0XSAgIGdm
bjogMDAwMDU0NDQgIG1mbjogMDAwMDU0NDQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6
MTRdICAgZ2ZuOiAwMDAwNTQ0NSAgbWZuOiAwMDAwNTQ0NQ0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMzoxNF0gICBnZm46IDAwMDA1NDQ2ICBtZm46IDAwMDA1NDQ2DQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMzOjE0XSAgIGdmbjogMDAwMDU0NDcgIG1mbjogMDAwMDU0NDcNCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MTRdICAgZ2ZuOiAwMDAwNTQ0OCAgbWZuOiAwMDAw
NTQ0OA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoxNF0gICBnZm46IDAwMDA1NDQ5ICBt
Zm46IDAwMDA1NDQ5DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjE0XSAgIGdmbjogMDAw
MDU0NGEgIG1mbjogMDAwMDU0NGENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MTRdICAg
Z2ZuOiAwMDAwNTQ0YiAgbWZuOiAwMDAwNTQ0Yg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
MzoxNF0gICBnZm46IDAwMDA1NDRjICBtZm46IDAwMDA1NDRjDQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMzOjE0XSAgIGdmbjogMDAwMDU0NGQgIG1mbjogMDAwMDU0NGQNCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzM6MTRdICAgZ2ZuOiAwMDAwNTQ0ZSAgbWZuOiAwMDAwNTQ0ZQ0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoxNF0gICBnZm46IDAwMDA1NDRmICBtZm46IDAw
MDA1NDRmDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjE0XSAgIGdmbjogMDAwMDU0NTAg
IG1mbjogMDAwMDU0NTANCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MTRdICAgZ2ZuOiAw
MDAwNTQ1MSAgbWZuOiAwMDAwNTQ1MQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoxNF0g
ICBnZm46IDAwMDA1NDUyICBtZm46IDAwMDA1NDUyDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMzOjE0XSAgIGdmbjogMDAwMDU0NTMgIG1mbjogMDAwMDU0NTMNCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzM6MTRdICAgZ2ZuOiAwMDAwNTQ1NCAgbWZuOiAwMDAwNTQ1NA0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMzoxNF0gICBnZm46IDAwMDA1NDU1ICBtZm46IDAwMDA1NDU1
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjE0XSAgIGdmbjogMDAwMDU0NTYgIG1mbjog
MDAwMDU0NTYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MTRdICAgZ2ZuOiAwMDAwNTQ1
NyAgbWZuOiAwMDAwNTQ1Nw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoxNF0gICBnZm46
IDAwMDA1NDU4ICBtZm46IDAwMDA1NDU4DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjE0
XSAgIGdmbjogMDAwMDU0NTkgIG1mbjogMDAwMDU0NTkNCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzM6MTRdICAgZ2ZuOiAwMDAwNTQ1YSAgbWZuOiAwMDAwNTQ1YQ0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMzoxNF0gICBnZm46IDAwMDA1NDViICBtZm46IDAwMDA1NDViDQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMzOjE0XSAgIGdmbjogMDAwMDU0NWMgIG1mbjogMDAwMDU0
NWMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MTRdICAgZ2ZuOiAwMDAwNTQ1ZCAgbWZu
OiAwMDAwNTQ1ZA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoxNF0gICBnZm46IDAwMDA1
NDVlICBtZm46IDAwMDA1NDVlDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjE0XSAgIGdm
bjogMDAwMDU0NWYgIG1mbjogMDAwMDU0NWYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6
MTRdICAgZ2ZuOiAwMDAwNTQ2MCAgbWZuOiAwMDAwNTQ2MA0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMzoxNF0gICBnZm46IDAwMDA1NDYxICBtZm46IDAwMDA1NDYxDQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMzOjE0XSAgIGdmbjogMDAwMDU0NjIgIG1mbjogMDAwMDU0NjINCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MTRdICAgZ2ZuOiAwMDAwNTQ2MyAgbWZuOiAwMDAw
NTQ2Mw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoxNF0gICBnZm46IDAwMDA1NDY0ICBt
Zm46IDAwMDA1NDY0DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjE0XSAgIGdmbjogMDAw
MDU0NjUgIG1mbjogMDAwMDU0NjUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MTRdICAg
Z2ZuOiAwMDAwNTQ2NiAgbWZuOiAwMDAwNTQ2Ng0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
MzoxNF0gICBnZm46IDAwMDA1NDY3ICBtZm46IDAwMDA1NDY3DQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMzOjE0XSAgIGdmbjogMDAwMDU0NjggIG1mbjogMDAwMDU0NjgNCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzM6MTRdICAgZ2ZuOiAwMDAwNTQ2OSAgbWZuOiAwMDAwNTQ2OQ0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoxNF0gICBnZm46IDAwMDA1NDZhICBtZm46IDAw
MDA1NDZhDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjE0XSAgIGdmbjogMDAwMDU0NmIg
IG1mbjogMDAwMDU0NmINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MTRdICAgZ2ZuOiAw
MDAwNTQ2YyAgbWZuOiAwMDAwNTQ2Yw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoxNF0g
ICBnZm46IDAwMDA1NDZkICBtZm46IDAwMDA1NDZkDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMzOjE0XSAgIGdmbjogMDAwMDU0NmUgIG1mbjogMDAwMDU0NmUNCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzM6MTVdICAgZ2ZuOiAwMDAwNTQ2ZiAgbWZuOiAwMDAwNTQ2Zg0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMzoxNV0gICBnZm46IDAwMDA1NDcwICBtZm46IDAwMDA1NDcw
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjE1XSAgIGdmbjogMDAwMDU0NzEgIG1mbjog
MDAwMDU0NzENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MTVdICAgZ2ZuOiAwMDAwNTQ3
MiAgbWZuOiAwMDAwNTQ3Mg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoxNV0gICBnZm46
IDAwMDA1NDczICBtZm46IDAwMDA1NDczDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjE1
XSAgIGdmbjogMDAwMDU0NzQgIG1mbjogMDAwMDU0NzQNCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzM6MTVdICAgZ2ZuOiAwMDAwNTQ3NSAgbWZuOiAwMDAwNTQ3NQ0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMzoxNV0gICBnZm46IDAwMDA1NDc2ICBtZm46IDAwMDA1NDc2DQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMzOjE1XSAgIGdmbjogMDAwMDU0NzcgIG1mbjogMDAwMDU0
NzcNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MTVdICAgZ2ZuOiAwMDAwNTQ3OCAgbWZu
OiAwMDAwNTQ3OA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoxNV0gICBnZm46IDAwMDA1
NDc5ICBtZm46IDAwMDA1NDc5DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjE1XSAgIGdm
bjogMDAwMDU0N2EgIG1mbjogMDAwMDU0N2ENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6
MTVdICAgZ2ZuOiAwMDAwNTQ3YiAgbWZuOiAwMDAwNTQ3Yg0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMzoxNV0gICBnZm46IDAwMDA1NDdjICBtZm46IDAwMDA1NDdjDQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMzOjE1XSAgIGdmbjogMDAwMDU0N2QgIG1mbjogMDAwMDU0N2QNCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MTVdICAgZ2ZuOiAwMDAwNTQ3ZSAgbWZuOiAwMDAw
NTQ3ZQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoxNV0gICBnZm46IDAwMDA1NDdmICBt
Zm46IDAwMDA1NDdmDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjE1XSAgIGdmbjogMDAw
MDU0ODAgIG1mbjogMDAwMDU0ODANCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MTVdICAg
Z2ZuOiAwMDAwNTQ4MSAgbWZuOiAwMDAwNTQ4MQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
MzoxNV0gICBnZm46IDAwMDA1NDgyICBtZm46IDAwMDA1NDgyDQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMzOjE1XSAgIGdmbjogMDAwMDU0ODMgIG1mbjogMDAwMDU0ODMNCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzM6MTVdICAgZ2ZuOiAwMDAwNTQ4NCAgbWZuOiAwMDAwNTQ4NA0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoxNV0gICBnZm46IDAwMDA1NDg1ICBtZm46IDAw
MDA1NDg1DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjE1XSAgIGdmbjogMDAwMDU0ODYg
IG1mbjogMDAwMDU0ODYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MTVdICAgZ2ZuOiAw
MDAwNTQ4NyAgbWZuOiAwMDAwNTQ4Nw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoxNV0g
ICBnZm46IDAwMDA1NDg4ICBtZm46IDAwMDA1NDg4DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMzOjE1XSAgIGdmbjogMDAwMDU0ODkgIG1mbjogMDAwMDU0ODkNCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzM6MTVdICAgZ2ZuOiAwMDAwNTQ4YSAgbWZuOiAwMDAwNTQ4YQ0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMzoxNV0gICBnZm46IDAwMDA1NDhiICBtZm46IDAwMDA1NDhi
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjE1XSAgIGdmbjogMDAwMDU0OGMgIG1mbjog
MDAwMDU0OGMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MTVdICAgZ2ZuOiAwMDAwNTQ4
ZCAgbWZuOiAwMDAwNTQ4ZA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoxNV0gICBnZm46
IDAwMDA1NDhlICBtZm46IDAwMDA1NDhlDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjE1
XSAgIGdmbjogMDAwMDU0OGYgIG1mbjogMDAwMDU0OGYNCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzM6MTVdICAgZ2ZuOiAwMDAwNTQ5MCAgbWZuOiAwMDAwNTQ5MA0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMzoxNV0gICBnZm46IDAwMDA1NDkxICBtZm46IDAwMDA1NDkxDQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMzOjE1XSAgIGdmbjogMDAwMDU0OTIgIG1mbjogMDAwMDU0
OTINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MTVdICAgZ2ZuOiAwMDAwNTQ5MyAgbWZu
OiAwMDAwNTQ5Mw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoxNV0gICBnZm46IDAwMDA1
NDk0ICBtZm46IDAwMDA1NDk0DQoNClsgIDQ2MS41NTkwMzBdIGEoWEVOKSBbMjAxMi0wOC0z
MSAyMTozMzoxNV0gICBnZm46IDAwMDA1NDk1ICBtZm46IDAwMDA1NDk1DQoNCnRhMS4wMDog
cWMgdGltZW8oWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoxNV0gICBnZm46IDAwMDA1NDk2ICBt
Zm46IDAwMDA1NDk2DQoNCnV0IChjbWQgMHhlYykNCg0KDQooWEVOKSBbMjAxMi0wOC0zMSAy
MTozMzoxNV0gICBnZm46IDAwMDA1NDk3ICBtZm46IDAwMDA1NDk3DQoNClsgIDQ2MS42MzM3
MzJdIGEoWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoxNV0gICBnZm46IDAwMDA1NDk4ICBtZm46
IDAwMDA1NDk4DQoNCnRhMS4wMDogZmFpbGVkIHQoWEVOKSBbMjAxMi0wOC0zMSAyMTozMzox
NV0gICBnZm46IDAwMDA1NDk5ICBtZm46IDAwMDA1NDk5DQoNCm8gSURFTlRJRlkgKEkvTyBl
cnJvciwgZXJyX21hc2s9KFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MTVdICAgZ2ZuOiAwMDAw
NTQ5YSAgbWZuOiAwMDAwNTQ5YQ0KDQoweDQpDQoNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6
MzM6MTVdICAgZ2ZuOiAwMDAwNTQ5YiAgbWZuOiAwMDAwNTQ5Yg0KDQpbICA0NjEuNzE2ODk1
XSBhdGExLjAwOiByZXZhbGlkYShYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjE1XSAgIGdmbjog
MDAwMDU0OWMgIG1mbjogMDAwMDU0OWMNCg0KdGlvbiBmYWlsZWQgKGVycihYRU4pIFsyMDEy
LTA4LTMxIDIxOjMzOjE1XSAgIGdmbjogMDAwMDU0OWQgIG1mbjogMDAwMDU0OWQNCg0Kbm89
LTUpDQoNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MTVdICAgZ2ZuOiAwMDAwNTQ5ZSAg
bWZuOiAwMDAwNTQ5ZQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoxNV0gICBnZm46IDAw
MDA1NDlmICBtZm46IDAwMDA1NDlmDQoNClsgIDQ2MS43NzkzNDRdIGEoWEVOKSBbMjAxMi0w
OC0zMSAyMTozMzoxNV0gICBnZm46IDAwMDA1NGEwICBtZm46IDAwMDA1NGEwDQoNCnRhMS4w
MDogZGlzYWJsZWQoWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoxNV0gICBnZm46IDAwMDA1NGEx
ICBtZm46IDAwMDA1NGExDQoNCg0KDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjE1XSAg
IGdmbjogMDAwMDU0YTIgIG1mbjogMDAwMDU0YTINCg0KWyAgNDYxLjg1MDA3OF0gYShYRU4p
IFsyMDEyLTA4LTMxIDIxOjMzOjE1XSAgIGdmbjogMDAwMDU0YTMgIG1mbjogMDAwMDU0YTMN
Cg0KdGExLjAwOiBkZXZpY2UgcihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjE1XSAgIGdmbjog
MDAwMDU0YTQgIG1mbjogMDAwMDU0YTQNCg0KZXBvcnRlZCBpbnZhbGlkIChYRU4pIFsyMDEy
LTA4LTMxIDIxOjMzOjE1XSAgIGdmbjogMDAwMDU0YTUgIG1mbjogMDAwMDU0YTUNCg0KQ0hT
IHNlY3RvciAwDQoNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MTVdICAgZ2ZuOiAwMDAw
NTRhNiAgbWZuOiAwMDAwNTRhNg0KDQpbICA0NjEuOTI5MTUwXSBhKFhFTikgWzIwMTItMDgt
MzEgMjE6MzM6MTVdICAgZ2ZuOiAwMDAwNTRhNyAgbWZuOiAwMDAwNTRhNw0KDQp0YTE6IGhh
cmQgcmVzZXR0aW5nIGxpbmsNCg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoxNV0gICBn
Zm46IDAwMDA1NGE4ICBtZm46IDAwMDA1NGE4DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMz
OjE1XSAgIGdmbjogMDAwMDU0YTkgIG1mbjogMDAwMDU0YTkNCg0KKFhFTikgWzIwMTItMDgt
MzEgMjE6MzM6MTZdICAgZ2ZuOiAwMDAwNTRhYSAgbWZuOiAwMDAwNTRhYQ0KDQooWEVOKSBb
MjAxMi0wOC0zMSAyMTozMzoxNl0gICBnZm46IDAwMDA1NGFiICBtZm46IDAwMDA1NGFiDQoN
CihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjE2XSAgIGdmbjogMDAwMDU0YWMgIG1mbjogMDAw
MDU0YWMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MTZdICAgZ2ZuOiAwMDAwNTRhZCAg
bWZuOiAwMDAwNTRhZA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoxNl0gICBnZm46IDAw
MDA1NGFlICBtZm46IDAwMDA1NGFlDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjE2XSAg
IGdmbjogMDAwMDU0YWYgIG1mbjogMDAwMDU0YWYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6
MzM6MTZdICAgZ2ZuOiAwMDAwNTRiMCAgbWZuOiAwMDAwNTRiMA0KDQooWEVOKSBbMjAxMi0w
OC0zMSAyMTozMzoxNl0gICBnZm46IDAwMDA1NGIxICBtZm46IDAwMDA1NGIxDQoNCihYRU4p
IFsyMDEyLTA4LTMxIDIxOjMzOjE2XSAgIGdmbjogMDAwMDU0YjIgIG1mbjogMDAwMDU0YjIN
Cg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MTZdICAgZ2ZuOiAwMDAwNTRiMyAgbWZuOiAw
MDAwNTRiMw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoxNl0gICBnZm46IDAwMDA1NGI0
ICBtZm46IDAwMDA1NGI0DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjE2XSAgIGdmbjog
MDAwMDU0YjUgIG1mbjogMDAwMDU0YjUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MTZd
ICAgZ2ZuOiAwMDAwNTRiNiAgbWZuOiAwMDAwNTRiNg0KDQooWEVOKSBbMjAxMi0wOC0zMSAy
MTozMzoxNl0gICBnZm46IDAwMDA1NGI3ICBtZm46IDAwMDA1NGI3DQoNCihYRU4pIFsyMDEy
LTA4LTMxIDIxOjMzOjE2XSAgIGdmbjogMDAwMDU0YjggIG1mbjogMDAwMDU0YjgNCg0KKFhF
TikgWzIwMTItMDgtMzEgMjE6MzM6MTZdICAgZ2ZuOiAwMDAwNTRiOSAgbWZuOiAwMDAwNTRi
OQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoxNl0gICBnZm46IDAwMDA1NGJhICBtZm46
IDAwMDA1NGJhDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjE2XSAgIGdmbjogMDAwMDU0
YmIgIG1mbjogMDAwMDU0YmINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MTZdICAgZ2Zu
OiAwMDAwNTRiYyAgbWZuOiAwMDAwNTRiYw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzox
Nl0gICBnZm46IDAwMDA1NGJkICBtZm46IDAwMDA1NGJkDQoNCihYRU4pIFsyMDEyLTA4LTMx
IDIxOjMzOjE2XSAgIGdmbjogMDAwMDU0YmUgIG1mbjogMDAwMDU0YmUNCg0KKFhFTikgWzIw
MTItMDgtMzEgMjE6MzM6MTZdICAgZ2ZuOiAwMDAwNTRiZiAgbWZuOiAwMDAwNTRiZg0KDQoo
WEVOKSBbMjAxMi0wOC0zMSAyMTozMzoxNl0gICBnZm46IDAwMDA1NGMwICBtZm46IDAwMDA1
NGMwDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjE2XSAgIGdmbjogMDAwMDU0YzEgIG1m
bjogMDAwMDU0YzENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MTZdICAgZ2ZuOiAwMDAw
NTRjMiAgbWZuOiAwMDAwNTRjMg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoxNl0gICBn
Zm46IDAwMDA1NGMzICBtZm46IDAwMDA1NGMzDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMz
OjE2XSAgIGdmbjogMDAwMDU0YzQgIG1mbjogMDAwMDU0YzQNCg0KKFhFTikgWzIwMTItMDgt
MzEgMjE6MzM6MTZdICAgZ2ZuOiAwMDAwNTRjNSAgbWZuOiAwMDAwNTRjNQ0KDQooWEVOKSBb
MjAxMi0wOC0zMSAyMTozMzoxNl0gICBnZm46IDAwMDA1NGM2ICBtZm46IDAwMDA1NGM2DQoN
CihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjE2XSAgIGdmbjogMDAwMDU0YzcgIG1mbjogMDAw
MDU0YzcNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MTZdICAgZ2ZuOiAwMDAwNTRjOCAg
bWZuOiAwMDAwNTRjOA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoxNl0gICBnZm46IDAw
MDA1NGM5ICBtZm46IDAwMDA1NGM5DQoNClsgIDQ2Mi40ODY4MDVdIGEoWEVOKSBbMjAxMi0w
OC0zMSAyMTozMzoxNl0gICBnZm46IDAwMDA1NGNhICBtZm46IDAwMDA1NGNhDQoNCnRhMTog
U0FUQSBsaW5rIHUoWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoxNl0gICBnZm46IDAwMDA1NGNi
ICBtZm46IDAwMDA1NGNiDQoNCnAgMS41IEdicHMgKFNTdGEoWEVOKSBbMjAxMi0wOC0zMSAy
MTozMzoxNl0gICBnZm46IDAwMDA1NGNjICBtZm46IDAwMDA1NGNjDQoNCnR1cyAxMTMgU0Nv
bnRyb2woWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoxNl0gICBnZm46IDAwMDA1NGNkICBtZm46
IDAwMDA1NGNkDQoNCiAzMTApDQoNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MTZdICAg
Z2ZuOiAwMDAwNTRjZSAgbWZuOiAwMDAwNTRjZQ0KDQpbICA0NjIuNTgyMjMwXSBzKFhFTikg
WzIwMTItMDgtMzEgMjE6MzM6MTZdICAgZ2ZuOiAwMDAwNTRjZiAgbWZuOiAwMDAwNTRjZg0K
DQpkIDA6MDowOjA6IFtzZGFdKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MTZdICAgZ2ZuOiAw
MDAwNTRkMCAgbWZuOiAwMDAwNTRkMA0KDQogIA0KDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMzOjE2XSAgIGdmbjogMDAwMDU0ZDEgIG1mbjogMDAwMDU0ZDENCg0KWyAgNDYyLjY0MDM5
Ml0gUmVzdWx0OiBob3N0Ynl0ZT0oWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoxNl0gICBnZm46
IDAwMDA1NGQyICBtZm46IDAwMDA1NGQyDQoNCkRJRF9PSyBkcml2ZXJieXQoWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMzoxNl0gICBnZm46IDAwMDA1NGQzICBtZm46IDAwMDA1NGQzDQoNCmU9
RFJJVkVSX1NFTlNFDQoNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MTZdICAgZ2ZuOiAw
MDAwNTRkNCAgbWZuOiAwMDAwNTRkNA0KDQpbICA0NjIuNzAyODQ1XSBzKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzM6MTZdICAgZ2ZuOiAwMDAwNTRkNSAgbWZuOiAwMDAwNTRkNQ0KDQpkIDA6
MDowOjA6IFtzZGFdKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MTZdICAgZ2ZuOiAwMDAwNTRk
NiAgbWZuOiAwMDAwNTRkNg0KDQogIA0KDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjE2
XSAgIGdmbjogMDAwMDU0ZDcgIG1mbjogMDAwMDU0ZDcNCg0KWyAgNDYyLjc1NjkyOF0gUyhY
RU4pIFsyMDEyLTA4LTMxIDIxOjMzOjE2XSAgIGdmbjogMDAwMDU0ZDggIG1mbjogMDAwMDU0
ZDgNCg0KZW5zZSBLZXkgOiBBYm9ydChYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjE2XSAgIGdm
bjogMDAwMDU0ZDkgIG1mbjogMDAwMDU0ZDkNCg0KZWQgQ29tbWFuZCAoWEVOKSBbMjAxMi0w
OC0zMSAyMTozMzoxNl0gICBnZm46IDAwMDA1NGRhICBtZm46IDAwMDA1NGRhDQoNCltjdXJy
ZW50XSAoWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoxNl0gICBnZm46IDAwMDA1NGRiICBtZm46
IDAwMDA1NGRiDQoNCltkZXNjcmlwdG9yXShYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjE2XSAg
IGdmbjogMDAwMDU0ZGMgIG1mbjogMDAwMDU0ZGMNCg0KDQoNCg0KKFhFTikgWzIwMTItMDgt
MzEgMjE6MzM6MTZdICAgZ2ZuOiAwMDAwNTRkZCAgbWZuOiAwMDAwNTRkZA0KDQpbICA0NjIu
ODY5MTk4XSBEKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MTZdICAgZ2ZuOiAwMDAwNTRkZSAg
bWZuOiAwMDAwNTRkZQ0KDQplc2NyaXB0b3Igc2Vuc2UgKFhFTikgWzIwMTItMDgtMzEgMjE6
MzM6MTZdICAgZ2ZuOiAwMDAwNTRkZiAgbWZuOiAwMDAwNTRkZg0KDQpkYXRhIHdpdGggc2Vu
c2UgZGVzY3JpcHRvcnMgKGluIChYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjE2XSAgIGdmbjog
MDAwMDU0ZTAgIG1mbjogMDAwMDU0ZTANCg0KaGV4KTooWEVOKSBbMjAxMi0wOC0zMSAyMToz
MzoxNl0gICBnZm46IDAwMDA1NGUxICBtZm46IDAwMDA1NGUxDQoNCg0KDQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMzOjE2XSAgIGdmbjogMDAwMDU0ZTIgIG1mbjogMDAwMDU0ZTINCg0K
WyAgNDYyLjk2NDg1NF0gIChYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjE2XSAgIGdmbjogMDAw
MDU0ZTMgIG1mbjogMDAwMDU0ZTMNCg0KICAgICAgIChYRU4pIFsyMDEyLTA4LTMxIDIxOjMz
OjE3XSAgIGdmbjogMDAwMDU0ZTQgIG1mbjogMDAwMDU0ZTQNCg0KNzIgKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzM6MTddICAgZ2ZuOiAwMDAwNTRlNSAgbWZuOiAwMDAwNTRlNQ0KDQowYiAw
MCAwMCAoWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoxN10gICBnZm46IDAwMDA1NGU2ICBtZm46
IDAwMDA1NGU2DQoNCjAwIChYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjE3XSAgIGdmbjogMDAw
MDU0ZTcgIG1mbjogMDAwMDU0ZTcNCg0KMDAgKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MTdd
ICAgZ2ZuOiAwMDAwNTRlOCAgbWZuOiAwMDAwNTRlOA0KDQowMCAoWEVOKSBbMjAxMi0wOC0z
MSAyMTozMzoxN10gICBnZm46IDAwMDA1NGU5ICBtZm46IDAwMDA1NGU5DQoNCjBjIChYRU4p
IFsyMDEyLTA4LTMxIDIxOjMzOjE3XSAgIGdmbjogMDAwMDU0ZWEgIG1mbjogMDAwMDU0ZWEN
Cg0KMDAgKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MTddICAgZ2ZuOiAwMDAwNTRlYiAgbWZu
OiAwMDAwNTRlYg0KDQowYSAoWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoxN10gICBnZm46IDAw
MDA1NGVjICBtZm46IDAwMDA1NGVjDQoNCjgwIChYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjE3
XSAgIGdmbjogMDAwMDU0ZWQgIG1mbjogMDAwMDU0ZWQNCg0KMDAgMDAgMDAgKFhFTikgWzIw
MTItMDgtMzEgMjE6MzM6MTddICAgZ2ZuOiAwMDAwNTRlZSAgbWZuOiAwMDAwNTRlZQ0KDQow
MCAoWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoxN10gICBnZm46IDAwMDA1NGVmICBtZm46IDAw
MDA1NGVmDQoNCjAwIChYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjE3XSAgIGdmbjogMDAwMDU0
ZjAgIG1mbjogMDAwMDU0ZjANCg0KDQoNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MTdd
ICAgZ2ZuOiAwMDAwNTRmMSAgbWZuOiAwMDAwNTRmMQ0KDQpbICA0NjMuMjE4NTk3XSAgKFhF
TikgWzIwMTItMDgtMzEgMjE6MzM6MTddICAgZ2ZuOiAwMDAwNTRmMiAgbWZuOiAwMDAwNTRm
Mg0KDQogICAgICAgKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MTddICAgZ2ZuOiAwMDAwNTRm
MyAgbWZuOiAwMDAwNTRmMw0KDQowMCAwMCAwMCAoWEVOKSBbMjAxMi0wOC0zMSAyMTozMzox
N10gICBnZm46IDAwMDA1NGY0ICBtZm46IDAwMDA1NGY0DQoNCjAwIChYRU4pIFsyMDEyLTA4
LTMxIDIxOjMzOjE3XSAgIGdmbjogMDAwMDU0ZjUgIG1mbjogMDAwMDU0ZjUNCg0KDQoNCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MTddICAgZ2ZuOiAwMDAwNTRmNiAgbWZuOiAwMDAw
NTRmNg0KDQpbICA0NjMuMzA1OTg3XSBzKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MTddICAg
Z2ZuOiAwMDAwNTRmNyAgbWZuOiAwMDAwNTRmNw0KDQpkIDA6MDowOjA6IFtzZGFdKFhFTikg
WzIwMTItMDgtMzEgMjE6MzM6MTddICAgZ2ZuOiAwMDAwNTRmOCAgbWZuOiAwMDAwNTRmOA0K
DQogIA0KDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjE3XSAgIGdmbjogMDAwMDU0Zjkg
IG1mbjogMDAwMDU0ZjkNCg0KWyAgNDYzLjM2NDIyMl0gQShYRU4pIFsyMDEyLTA4LTMxIDIx
OjMzOjE3XSAgIGdmbjogMDAwMDU0ZmEgIG1mbjogMDAwMDU0ZmENCg0KZGQuIFNlbnNlOiBO
byBhZChYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjE3XSAgIGdmbjogMDAwMDU0ZmIgIG1mbjog
MDAwMDU0ZmINCg0KZGl0aW9uYWwgc2Vuc2UgaShYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjE3
XSAgIGdmbjogMDAwMDU0ZmMgIG1mbjogMDAwMDU0ZmMNCg0KbmZvcm1hdGlvbihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMzOjE3XSAgIGdmbjogMDAwMDU0ZmQgIG1mbjogMDAwMDU0ZmQNCg0K
DQoNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MTddICAgZ2ZuOiAwMDAwNTRmZSAgbWZu
OiAwMDAwNTRmZQ0KDQpbICA0NjMuNDU5ODY2XSBzKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6
MTddICAgZ2ZuOiAwMDAwNTRmZiAgbWZuOiAwMDAwNTRmZg0KDQpkIDA6MDowOjA6IFtzZGFd
KFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MTddICAgZ2ZuOiAwMDAwNTUwMCAgbWZuOiAwMDAw
NTUwMA0KDQogQ0RCOiANCg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoxN10gICBnZm46
IDAwMDA1NTAxICBtZm46IDAwMDA1NTAxDQoNClsgIDQ2My41MTM5NzZdIFIoWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMzoxN10gICBnZm46IDAwMDA1NTAyICBtZm46IDAwMDA1NTAyDQoNCmVh
ZCgxMCkoWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoxN10gICBnZm46IDAwMDA1NTAzICBtZm46
IDAwMDA1NTAzDQoNCjooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoxN10gICBnZm46IDAwMDA1
NTA0ICBtZm46IDAwMDA1NTA0DQoNCiAyOChYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjE3XSAg
IGdmbjogMDAwMDU1MDUgIG1mbjogMDAwMDU1MDUNCg0KIDAwKFhFTikgWzIwMTItMDgtMzEg
MjE6MzM6MTddICAgZ2ZuOiAwMDAwNTUwNiAgbWZuOiAwMDAwNTUwNg0KDQogOGUoWEVOKSBb
MjAxMi0wOC0zMSAyMTozMzoxN10gICBnZm46IDAwMDA1NTA3ICBtZm46IDAwMDA1NTA3DQoN
CiA5NShYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjE3XSAgIGdmbjogMDAwMDU1MDggIG1mbjog
MDAwMDU1MDgNCg0KIDExKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MTddICAgZ2ZuOiAwMDAw
NTUwOSAgbWZuOiAwMDAwNTUwOQ0KDQogNTEoWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoxN10g
ICBnZm46IDAwMDA1NTBhICBtZm46IDAwMDA1NTBhDQoNCiAwMChYRU4pIFsyMDEyLTA4LTMx
IDIxOjMzOjE3XSAgIGdmbjogMDAwMDU1MGIgIG1mbjogMDAwMDU1MGINCg0KIDAwKFhFTikg
WzIwMTItMDgtMzEgMjE6MzM6MTddICAgZ2ZuOiAwMDAwNTUwYyAgbWZuOiAwMDAwNTUwYw0K
DQogMTAoWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoxN10gICBnZm46IDAwMDA1NTBkICBtZm46
IDAwMDA1NTBkDQoNCiAwMChYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjE3XSAgIGdmbjogMDAw
MDU1MGUgIG1mbjogMDAwMDU1MGUNCg0KDQoNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6
MTddICAgZ2ZuOiAwMDAwNTUwZiAgbWZuOiAwMDAwNTUwZg0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMzoxN10gICBnZm46IDAwMDA1NTEwICBtZm46IDAwMDA1NTEwDQoNClsgIDQ2My43
NjM2NjJdIGUoWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoxN10gICBnZm46IDAwMDA1NTExICBt
Zm46IDAwMDA1NTExDQoNCm5kX3JlcXVlc3Q6IEkvTyAoWEVOKSBbMjAxMi0wOC0zMSAyMToz
MzoxN10gICBnZm46IDAwMDA1NTEyICBtZm46IDAwMDA1NTEyDQoNCmVycm9yLCBkZXYgc2Rh
LCAoWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoxN10gICBnZm46IDAwMDA1NTEzICBtZm46IDAw
MDA1NTEzDQoNCnNlY3RvciAyMzkyMTMzOTYoWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoxN10g
ICBnZm46IDAwMDA1NTE0ICBtZm46IDAwMDA1NTE0DQoNCjkNCg0KDQooWEVOKSBbMjAxMi0w
OC0zMSAyMTozMzoxN10gICBnZm46IDAwMDA1NTE1ICBtZm46IDAwMDA1NTE1DQoNClsgIDQ2
My44NTk0MTBdIGEoWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoxN10gICBnZm46IDAwMDA1NTE2
ICBtZm46IDAwMDA1NTE2DQoNCnRhMTogRUggY29tcGxldGUoWEVOKSBbMjAxMi0wOC0zMSAy
MTozMzoxN10gICBnZm46IDAwMDA1NTE3ICBtZm46IDAwMDA1NTE3DQoNCg0KDQoNCihYRU4p
IFsyMDEyLTA4LTMxIDIxOjMzOjE3XSAgIGdmbjogMDAwMDU1MTggIG1mbjogMDAwMDU1MTgN
Cg0KWyAgNDYzLjkxNzU5MV0gcyhYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjE3XSAgIGdmbjog
MDAwMDU1MTkgIG1mbjogMDAwMDU1MTkNCg0KZCAwOjA6MDowOiBbc2RhXShYRU4pIFsyMDEy
LTA4LTMxIDIxOjMzOjE3XSAgIGdmbjogMDAwMDU1MWEgIG1mbjogMDAwMDU1MWENCg0KIFVu
aGFuZGxlZCBlcnJvcihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjE3XSAgIGdmbjogMDAwMDU1
MWIgIG1mbjogMDAwMDU1MWINCg0KIGNvZGUNCg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
MzoxN10gICBnZm46IDAwMDA1NTFjICBtZm46IDAwMDA1NTFjDQoNClsgIDQ2My45MjE4MDBd
IHMoWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoxOF0gICBnZm46IDAwMDA1NTFkICBtZm46IDAw
MDA1NTFkDQoNCmQgMDowOjA6MDogW3NkYV0oWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoxOF0g
ICBnZm46IDAwMDA1NTFlICBtZm46IDAwMDA1NTFlDQoNCiBVbmhhbmRsZWQgZXJyb3IoWEVO
KSBbMjAxMi0wOC0zMSAyMTozMzoxOF0gICBnZm46IDAwMDA1NTFmICBtZm46IDAwMDA1NTFm
DQoNCiBjb2RlDQoNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MThdICAgZ2ZuOiAwMDAw
NTUyMCAgbWZuOiAwMDAwNTUyMA0KDQpbICA0NjMuOTIxODAyXSBzKFhFTikgWzIwMTItMDgt
MzEgMjE6MzM6MThdICAgZ2ZuOiAwMDAwNTUyMSAgbWZuOiAwMDAwNTUyMQ0KDQpkIDA6MDow
OjA6IFtzZGFdKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MThdICAgZ2ZuOiAwMDAwNTUyMiAg
bWZuOiAwMDAwNTUyMg0KDQogIA0KDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjE4XSAg
IGdmbjogMDAwMDU1MjMgIG1mbjogMDAwMDU1MjMNCg0KWyAgNDYzLjkyMTgwM10gUmVzdWx0
OiBob3N0Ynl0ZT0oWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoxOF0gICBnZm46IDAwMDA1NTI0
ICBtZm46IDAwMDA1NTI0DQoNCkRJRF9CQURfVEFSR0VUIGQoWEVOKSBbMjAxMi0wOC0zMSAy
MTozMzoxOF0gICBnZm46IDAwMDA1NTI1ICBtZm46IDAwMDA1NTI1DQoNCnJpdmVyYnl0ZT1E
UklWRVJfT0sNCg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoxOF0gICBnZm46IDAwMDA1
NTI2ICBtZm46IDAwMDA1NTI2DQoNClsgIDQ2My45MjE4MDRdIHMoWEVOKSBbMjAxMi0wOC0z
MSAyMTozMzoxOF0gICBnZm46IDAwMDA1NTI3ICBtZm46IDAwMDA1NTI3DQoNCmQgMDowOjA6
MDogW3NkYV0gQ0RCOiANCg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoxOF0gICBnZm46
IDAwMDA1NTI4ICBtZm46IDAwMDA1NTI4DQoNClsgIDQ2My45MjE4MDldIFcoWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMzoxOF0gICBnZm46IDAwMDA1NTI5ICBtZm46IDAwMDA1NTI5DQoNCnJp
dGUoMTApOiAyYSAwMCAwMSAyYSBhZCBjMSAwMCAwKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6
MThdICAgZ2ZuOiAwMDAwNTUyYSAgbWZuOiAwMDAwNTUyYQ0KDQowIDEwIDAwDQoNCg0KKFhF
TikgWzIwMTItMDgtMzEgMjE6MzM6MThdICAgZ2ZuOiAwMDAwNTUyYiAgbWZuOiAwMDAwNTUy
Yg0KDQpbICA0NjMuOTIxODEwXSBlbmRfcmVxdWVzdDogSS9PIChYRU4pIFsyMDEyLTA4LTMx
IDIxOjMzOjE4XSAgIGdmbjogMDAwMDU1MmMgIG1mbjogMDAwMDU1MmMNCg0KZXJyb3IsIGRl
diBzZGEsIChYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjE4XSAgIGdmbjogMDAwMDU1MmQgIG1m
bjogMDAwMDU1MmQNCg0Kc2VjdG9yIDE5NTc0MjA5DQoNCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzM6MThdICAgZ2ZuOiAwMDAwNTUyZSAgbWZuOiAwMDAwNTUyZQ0KDQpbICA0NjMuOTIx
ODUzXSBzKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MThdICAgZ2ZuOiAwMDAwNTUyZiAgbWZu
OiAwMDAwNTUyZg0KDQpkIDA6MDowOjA6IFtzZGFdIFVuaGFuZGxlZCBlcnJvcihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMzOjE4XSAgIGdmbjogMDAwMDU1MzAgIG1mbjogMDAwMDU1MzANCg0K
IGNvZGUNCg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoxOF0gICBnZm46IDAwMDA1NTMx
ICBtZm46IDAwMDA1NTMxDQoNClsgIDQ2My45MjE4NTRdIHNkIDA6MDowOjA6IFtzZGFdKFhF
TikgWzIwMTItMDgtMzEgMjE6MzM6MThdICAgZ2ZuOiAwMDAwNTUzMiAgbWZuOiAwMDAwNTUz
Mg0KDQogIA0KDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjE4XSAgIGdmbjogMDAwMDU1
MzMgIG1mbjogMDAwMDU1MzMNCg0KWyAgNDYzLjkyMTg1NF0gUmVzdWx0OiBob3N0Ynl0ZT0o
WEVOKSBbMjAxMi0wOC0zMSAyMTozMzoxOF0gICBnZm46IDAwMDA1NTM0ICBtZm46IDAwMDA1
NTM0DQoNCkRJRF9CQURfVEFSR0VUIGQoWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoxOF0gICBn
Zm46IDAwMDA1NTM1ICBtZm46IDAwMDA1NTM1DQoNCnJpdmVyYnl0ZT1EUklWRVJfT0sNCg0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoxOF0gICBnZm46IDAwMDA1NTM2ICBtZm46IDAw
MDA1NTM2DQoNClsgIDQ2My45MjE4NTVdIHMoWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoxOF0g
ICBnZm46IDAwMDA1NTM3ICBtZm46IDAwMDA1NTM3DQoNCmQgMDowOjA6MDogW3NkYV0gQ0RC
OiANCg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoxOF0gICBnZm46IDAwMDA1NTM4ICBt
Zm46IDAwMDA1NTM4DQoNClsgIDQ2My45MjE4NThdIFcoWEVOKSBbMjAxMi0wOC0zMSAyMToz
MzoxOF0gICBnZm46IDAwMDA1NTM5ICBtZm46IDAwMDA1NTM5DQoNCnJpdGUoMTApOiAyYSAw
MCAwMiAzZSA1NSAwMSAwMCAwMCAwOCAwMA0KDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMz
OjE4XSAgIGdmbjogMDAwMDU1M2EgIG1mbjogMDAwMDU1M2ENCg0KWyAgNDYzLjkyMTg1OV0g
ZShYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjE4XSAgIGdmbjogMDAwMDU1M2IgIG1mbjogMDAw
MDU1M2INCg0KbmRfcmVxdWVzdDogSS9PIChYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjE4XSAg
IGdmbjogMDAwMDU1M2MgIG1mbjogMDAwMDU1M2MNCg0KZXJyb3IsIGRldiBzZGEsIChYRU4p
IFsyMDEyLTA4LTMxIDIxOjMzOjE4XSAgIGdmbjogMDAwMDU1M2QgIG1mbjogMDAwMDU1M2QN
Cg0Kc2VjdG9yIDM3NjM5NDI1DQoNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MThdICAg
Z2ZuOiAwMDAwNTUzZSAgbWZuOiAwMDAwNTUzZQ0KDQpbICA0NjMuOTIxODY0XSBCKFhFTikg
WzIwMTItMDgtMzEgMjE6MzM6MThdICAgZ2ZuOiAwMDAwNTUzZiAgbWZuOiAwMDAwNTUzZg0K
DQp1ZmZlciBJL08gZXJyb3Igb24gZGV2aWNlIGRtLTAsIChYRU4pIFsyMDEyLTA4LTMxIDIx
OjMzOjE4XSAgIGdmbjogMDAwMDU1NDAgIG1mbjogMDAwMDU1NDANCg0KbG9naWNhbCBibG9j
ayAyMihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjE4XSAgIGdmbjogMDAwMDU1NDEgIG1mbjog
MDAwMDU1NDENCg0KNjA5OTINCg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoxOF0gICBn
Zm46IDAwMDA1NTQyICBtZm46IDAwMDA1NTQyDQoNClsgIDQ2My45MjE4NjRdIGwoWEVOKSBb
MjAxMi0wOC0zMSAyMTozMzoxOF0gICBnZm46IDAwMDA1NTQzICBtZm46IDAwMDA1NTQzDQoN
Cm9zdCBwYWdlIHdyaXRlIGQoWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoxOF0gICBnZm46IDAw
MDA1NTQ0ICBtZm46IDAwMDA1NTQ0DQoNCnVlIHRvIEkvTyBlcnJvciAoWEVOKSBbMjAxMi0w
OC0zMSAyMTozMzoxOF0gICBnZm46IDAwMDA1NTQ1ICBtZm46IDAwMDA1NTQ1DQoNCm9uIGRt
LTANCg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoxOF0gICBnZm46IDAwMDA1NTQ2ICBt
Zm46IDAwMDA1NTQ2DQoNClsgIDQ2My45MjE4NzhdIHMoWEVOKSBbMjAxMi0wOC0zMSAyMToz
MzoxOF0gICBnZm46IDAwMDA1NTQ3ICBtZm46IDAwMDA1NTQ3DQoNCmQgMDowOjA6MDogW3Nk
YV0oWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoxOF0gICBnZm46IDAwMDA1NTQ4ICBtZm46IDAw
MDA1NTQ4DQoNCiBVbmhhbmRsZWQgZXJyb3IoWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoxOF0g
ICBnZm46IDAwMDA1NTQ5ICBtZm46IDAwMDA1NTQ5DQoNCiBjb2RlDQoNCg0KKFhFTikgWzIw
MTItMDgtMzEgMjE6MzM6MThdICAgZ2ZuOiAwMDAwNTU0YSAgbWZuOiAwMDAwNTU0YQ0KDQpb
ICA0NjMuOTIxODc5XSBzKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MThdICAgZ2ZuOiAwMDAw
NTU0YiAgbWZuOiAwMDAwNTU0Yg0KDQpkIDA6MDowOjA6IFtzZGFdKFhFTikgWzIwMTItMDgt
MzEgMjE6MzM6MThdICAgZ2ZuOiAwMDAwNTU0YyAgbWZuOiAwMDAwNTU0Yw0KDQogIA0KDQoN
CihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjE4XSAgIGdmbjogMDAwMDU1NGQgIG1mbjogMDAw
MDU1NGQNCg0KWyAgNDYzLjkyMTg4MF0gUmVzdWx0OiBob3N0Ynl0ZT0oWEVOKSBbMjAxMi0w
OC0zMSAyMTozMzoxOV0gICBnZm46IDAwMDA1NTRlICBtZm46IDAwMDA1NTRlDQoNCkRJRF9C
QURfVEFSR0VUIGQoWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoxOV0gICBnZm46IDAwMDA1NTRm
ICBtZm46IDAwMDA1NTRmDQoNCnJpdmVyYnl0ZT1EUklWRVJfT0sNCg0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMzoxOV0gICBnZm46IDAwMDA1NTUwICBtZm46IDAwMDA1NTUwDQoNClsg
IDQ2My45MjE4ODFdIHMoWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoxOV0gICBnZm46IDAwMDA1
NTUxICBtZm46IDAwMDA1NTUxDQoNCmQgMDowOjA6MDogW3NkYV0gQ0RCOiANCg0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMzoxOV0gICBnZm46IDAwMDA1NTUyICBtZm46IDAwMDA1NTUy
DQoNClsgIDQ2My45MjE4ODRdIFcoWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoxOV0gICBnZm46
IDAwMDA1NTUzICBtZm46IDAwMDA1NTUzDQoNCnJpdGUoMTApOiAyYSAwMCAwNSAyZSA1NSA4
MSAwMCAwKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MTldICAgZ2ZuOiAwMDAwNTU1NCAgbWZu
OiAwMDAwNTU1NA0KDQowIDA4IDAwDQoNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MTld
ICAgZ2ZuOiAwMDAwNTU1NSAgbWZuOiAwMDAwNTU1NQ0KDQpbICA0NjMuOTIxODg0XSBlbmRf
cmVxdWVzdDogSS9PIChYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjE5XSAgIGdmbjogMDAwMDU1
NTYgIG1mbjogMDAwMDU1NTYNCg0KZXJyb3IsIGRldiBzZGEsIChYRU4pIFsyMDEyLTA4LTMx
IDIxOjMzOjE5XSAgIGdmbjogMDAwMDU1NTcgIG1mbjogMDAwMDU1NTcNCg0Kc2VjdG9yIDg2
OTIyNjI1DQoNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MTldICAgZ2ZuOiAwMDAwNTU1
OCAgbWZuOiAwMDAwNTU1OA0KDQpbICA0NjMuOTIxODg3XSBCKFhFTikgWzIwMTItMDgtMzEg
MjE6MzM6MTldICAgZ2ZuOiAwMDAwNTU1OSAgbWZuOiAwMDAwNTU1OQ0KDQp1ZmZlciBJL08g
ZXJyb3Igb24gZGV2aWNlIGRtLTAsIChYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjE5XSAgIGdm
bjogMDAwMDU1NWEgIG1mbjogMDAwMDU1NWENCg0KbG9naWNhbCBibG9jayA4NChYRU4pIFsy
MDEyLTA4LTMxIDIxOjMzOjE5XSAgIGdmbjogMDAwMDU1NWIgIG1mbjogMDAwMDU1NWINCg0K
MjEzOTINCg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoxOV0gICBnZm46IDAwMDA1NTVj
ICBtZm46IDAwMDA1NTVjDQoNClsgIDQ2My45MjE4ODddIGwoWEVOKSBbMjAxMi0wOC0zMSAy
MTozMzoxOV0gICBnZm46IDAwMDA1NTVkICBtZm46IDAwMDA1NTVkDQoNCm9zdCBwYWdlIHdy
aXRlIGQoWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoxOV0gICBnZm46IDAwMDA1NTVlICBtZm46
IDAwMDA1NTVlDQoNCnVlIHRvIEkvTyBlcnJvciAoWEVOKSBbMjAxMi0wOC0zMSAyMTozMzox
OV0gICBnZm46IDAwMDA1NTVmICBtZm46IDAwMDA1NTVmDQoNCm9uIGRtLTANCg0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMzoxOV0gICBnZm46IDAwMDA1NTYwICBtZm46IDAwMDA1NTYw
DQoNClsgIDQ2My45MjE4OTZdIHMoWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoxOV0gICBnZm46
IDAwMDA1NTYxICBtZm46IDAwMDA1NTYxDQoNCmQgMDowOjA6MDogW3NkYV0gVW5oYW5kbGVk
IGVycm9yKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MTldICAgZ2ZuOiAwMDAwNTU2MiAgbWZu
OiAwMDAwNTU2Mg0KDQogY29kZQ0KDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjE5XSAg
IGdmbjogMDAwMDU1NjMgIG1mbjogMDAwMDU1NjMNCg0KWyAgNDYzLjkyMTg5N10gcyhYRU4p
IFsyMDEyLTA4LTMxIDIxOjMzOjE5XSAgIGdmbjogMDAwMDU1NjQgIG1mbjogMDAwMDU1NjQN
Cg0KZCAwOjA6MDowOiBbc2RhXShYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjE5XSAgIGdmbjog
MDAwMDU1NjUgIG1mbjogMDAwMDU1NjUNCg0KICANCg0KDQooWEVOKSBbMjAxMi0wOC0zMSAy
MTozMzoxOV0gICBnZm46IDAwMDA1NTY2ICBtZm46IDAwMDA1NTY2DQoNClsgIDQ2My45MjE4
OTddIFIoWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoxOV0gICBnZm46IDAwMDA1NTY3ICBtZm46
IDAwMDA1NTY3DQoNCmVzdWx0OiBob3N0Ynl0ZT1ESURfQkFEX1RBUkdFVCBkKFhFTikgWzIw
MTItMDgtMzEgMjE6MzM6MTldICAgZ2ZuOiAwMDAwNTU2OCAgbWZuOiAwMDAwNTU2OA0KDQpy
aXZlcmJ5dGU9RFJJVkVSKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MTldICAgZ2ZuOiAwMDAw
NTU2OSAgbWZuOiAwMDAwNTU2OQ0KDQpfT0sNCg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
MzoxOV0gICBnZm46IDAwMDA1NTZhICBtZm46IDAwMDA1NTZhDQoNClsgIDQ2My45MjE4OThd
IHMoWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoxOV0gICBnZm46IDAwMDA1NTZiICBtZm46IDAw
MDA1NTZiDQoNCmQgMDowOjA6MDogW3NkYV0oWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoxOV0g
ICBnZm46IDAwMDA1NTZjICBtZm46IDAwMDA1NTZjDQoNCiBDREI6IA0KDQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMzOjE5XSAgIGdmbjogMDAwMDU1NmQgIG1mbjogMDAwMDU1NmQNCg0K
WyAgNDYzLjkyMTkwMV0gVyhYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjE5XSAgIGdmbjogMDAw
MDU1NmUgIG1mbjogMDAwMDU1NmUNCg0Kcml0ZSgxMCk6IDJhIDAwIChYRU4pIFsyMDEyLTA4
LTMxIDIxOjMzOjE5XSAgIGdmbjogMDAwMDU1NmYgIG1mbjogMDAwMDU1NmYNCg0KMDUgMmUg
NTcgNDEgMDAgMDAgMDggMDANCg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoxOV0gICBn
Zm46IDAwMDA1NTcwICBtZm46IDAwMDA1NTcwDQoNClsgIDQ2My45MjE5MDJdIGUoWEVOKSBb
MjAxMi0wOC0zMSAyMTozMzoxOV0gICBnZm46IDAwMDA1NTcxICBtZm46IDAwMDA1NTcxDQoN
Cm5kX3JlcXVlc3Q6IEkvTyBlcnJvciwgZGV2IHNkYSwgKFhFTikgWzIwMTItMDgtMzEgMjE6
MzM6MTldICAgZ2ZuOiAwMDAwNTU3MiAgbWZuOiAwMDAwNTU3Mg0KDQpzZWN0b3IgODY5MjMw
NzMNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjE5XSAgIGdmbjogMDAwMDU1NzMgIG1mbjog
MDAwMDU1NzMNCg0KDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjE5XSAgIGdmbjogMDAw
MDU1NzQgIG1mbjogMDAwMDU1NzQNCg0KWyAgNDYzLjkyMTkwNF0gQihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMzOjE5XSAgIGdmbjogMDAwMDU1NzUgIG1mbjogMDAwMDU1NzUNCg0KdWZmZXIg
SS9PIGVycm9yIChYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjE5XSAgIGdmbjogMDAwMDU1NzYg
IG1mbjogMDAwMDU1NzYNCg0Kb24gZGV2aWNlIGRtLTAsIChYRU4pIFsyMDEyLTA4LTMxIDIx
OjMzOjE5XSAgIGdmbjogMDAwMDU1NzcgIG1mbjogMDAwMDU1NzcNCg0KbG9naWNhbCBibG9j
ayA4NDIxNDQ4DQoNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MTldICAgZ2ZuOiAwMDAw
NTU3OCAgbWZuOiAwMDAwNTU3OA0KDQpbICA0NjMuOTIxOTA1XSBsKFhFTikgWzIwMTItMDgt
MzEgMjE6MzM6MTldICAgZ2ZuOiAwMDAwNTU3OSAgbWZuOiAwMDAwNTU3OQ0KDQpvc3QgcGFn
ZSB3cml0ZSBkdWUgdG8gSS9PIGVycm9yIChYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjE5XSAg
IGdmbjogMDAwMDU1N2EgIG1mbjogMDAwMDU1N2ENCg0Kb24gZG0tMA0KDQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMzOjE5XSAgIGdmbjogMDAwMDU1N2IgIG1mbjogMDAwMDU1N2INCg0K
WyAgNDYzLjkyMTkxNF0gc2QgMDowOjA6MDogW3NkYV0oWEVOKSBbMjAxMi0wOC0zMSAyMToz
MzoxOV0gICBnZm46IDAwMDA1NTdjICBtZm46IDAwMDA1NTdjDQoNCiBVbmhhbmRsZWQgZXJy
b3IoWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoxOV0gICBnZm46IDAwMDA1NTdkICBtZm46IDAw
MDA1NTdkDQoNCiBjb2RlDQoNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MTldICAgZ2Zu
OiAwMDAwNTU3ZSAgbWZuOiAwMDAwNTU3ZQ0KDQpbICA0NjMuOTIxOTE1XSBzKFhFTikgWzIw
MTItMDgtMzEgMjE6MzM6MjBdICAgZ2ZuOiAwMDAwNTU3ZiAgbWZuOiAwMDAwNTU3Zg0KDQpk
IDA6MDowOjA6IFtzZGFdICANCg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoyMF0gICBn
Zm46IDAwMDA1NTgwICBtZm46IDAwMDA1NTgwDQoNClsgIDQ2My45MjE5MTVdIFIoWEVOKSBb
MjAxMi0wOC0zMSAyMTozMzoyMF0gICBnZm46IDAwMDA1NTgxICBtZm46IDAwMDA1NTgxDQoN
CmVzdWx0OiBob3N0Ynl0ZT1ESURfQkFEX1RBUkdFVCBkKFhFTikgWzIwMTItMDgtMzEgMjE6
MzM6MjBdICAgZ2ZuOiAwMDAwNTU4MiAgbWZuOiAwMDAwNTU4Mg0KDQpyaXZlcmJ5dGU9RFJJ
VkVSKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MjBdICAgZ2ZuOiAwMDAwNTU4MyAgbWZuOiAw
MDAwNTU4Mw0KDQpfT0sNCg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoyMF0gICBnZm46
IDAwMDA1NTg0ICBtZm46IDAwMDA1NTg0DQoNClsgIDQ2My45MjE5MTZdIHMoWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMzoyMF0gICBnZm46IDAwMDA1NTg1ICBtZm46IDAwMDA1NTg1DQoNCmQg
MDowOjA6MDogW3NkYV0oWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoyMF0gICBnZm46IDAwMDA1
NTg2ICBtZm46IDAwMDA1NTg2DQoNCiBDREI6IA0KDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMzOjIwXSAgIGdmbjogMDAwMDU1ODcgIG1mbjogMDAwMDU1ODcNCg0KWyAgNDYzLjkyMTkx
OV0gV3JpdGUoMTApOiAyYSAwMCAoWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoyMF0gICBnZm46
IDAwMDA1NTg4ICBtZm46IDAwMDA1NTg4DQoNCjA1IDM2IDU1IDE5IDAwIDAoWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMzoyMF0gICBnZm46IDAwMDA1NTg5ICBtZm46IDAwMDA1NTg5DQoNCjAg
MDggMDANCg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoyMF0gICBnZm46IDAwMDA1NThh
ICBtZm46IDAwMDA1NThhDQoNClsgIDQ2My45MjE5MjBdIGUoWEVOKSBbMjAxMi0wOC0zMSAy
MTozMzoyMF0gICBnZm46IDAwMDA1NThiICBtZm46IDAwMDA1NThiDQoNCm5kX3JlcXVlc3Q6
IEkvTyBlcnJvciwgZGV2IHNkYSwgKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MjBdICAgZ2Zu
OiAwMDAwNTU4YyAgbWZuOiAwMDAwNTU4Yw0KDQpzZWN0b3IgODc0NDY4MDkNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMzOjIwXSAgIGdmbjogMDAwMDU1OGQgIG1mbjogMDAwMDU1OGQNCg0K
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjIwXSAgIGdmbjogMDAwMDU1OGUgIG1mbjog
MDAwMDU1OGUNCg0KWyAgNDYzLjkyMTkyMl0gQihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjIw
XSAgIGdmbjogMDAwMDU1OGYgIG1mbjogMDAwMDU1OGYNCg0KdWZmZXIgSS9PIGVycm9yIChY
RU4pIFsyMDEyLTA4LTMxIDIxOjMzOjIwXSAgIGdmbjogMDAwMDU1OTAgIG1mbjogMDAwMDU1
OTANCg0Kb24gZGV2aWNlIGRtLTAsIChYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjIwXSAgIGdm
bjogMDAwMDU1OTEgIG1mbjogMDAwMDU1OTENCg0KbG9naWNhbCBibG9jayA4NDg2OTE1DQoN
Cg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MjBdICAgZ2ZuOiAwMDAwNTU5MiAgbWZuOiAw
MDAwNTU5Mg0KDQpbICA0NjMuOTIxOTIzXSBsKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MjBd
ICAgZ2ZuOiAwMDAwNTU5MyAgbWZuOiAwMDAwNTU5Mw0KDQpvc3QgcGFnZSB3cml0ZSBkdWUg
dG8gSS9PIGVycm9yIChYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjIwXSAgIGdmbjogMDAwMDU1
OTQgIG1mbjogMDAwMDU1OTQNCg0Kb24gZG0tMA0KDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMzOjIwXSAgIGdmbjogMDAwMDU1OTUgIG1mbjogMDAwMDU1OTUNCg0KWyAgNDYzLjkyMTkz
MF0gcyhYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjIwXSAgIGdmbjogMDAwMDU1OTYgIG1mbjog
MDAwMDU1OTYNCg0KZCAwOjA6MDowOiBbc2RhXShYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjIw
XSAgIGdmbjogMDAwMDU1OTcgIG1mbjogMDAwMDU1OTcNCg0KIFVuaGFuZGxlZCBlcnJvciBj
b2RlDQoNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MjBdICAgZ2ZuOiAwMDAwNTU5OCAg
bWZuOiAwMDAwNTU5OA0KDQpbICA0NjMuOTIxOTMxXSBzKFhFTikgWzIwMTItMDgtMzEgMjE6
MzM6MjBdICAgZ2ZuOiAwMDAwNTU5OSAgbWZuOiAwMDAwNTU5OQ0KDQpkIDA6MDowOjA6IFtz
ZGFdICANCg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoyMF0gICBnZm46IDAwMDA1NTlh
ICBtZm46IDAwMDA1NTlhDQoNClsgIDQ2My45MjE5MzJdIFIoWEVOKSBbMjAxMi0wOC0zMSAy
MTozMzoyMF0gICBnZm46IDAwMDA1NTliICBtZm46IDAwMDA1NTliDQoNCmVzdWx0OiBob3N0
Ynl0ZT1ESURfQkFEX1RBUkdFVCBkKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MjBdICAgZ2Zu
OiAwMDAwNTU5YyAgbWZuOiAwMDAwNTU5Yw0KDQpyaXZlcmJ5dGU9RFJJVkVSKFhFTikgWzIw
MTItMDgtMzEgMjE6MzM6MjBdICAgZ2ZuOiAwMDAwNTU5ZCAgbWZuOiAwMDAwNTU5ZA0KDQpf
T0sNCg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoyMF0gICBnZm46IDAwMDA1NTllICBt
Zm46IDAwMDA1NTllDQoNClsgIDQ2My45MjE5MzNdIHMoWEVOKSBbMjAxMi0wOC0zMSAyMToz
MzoyMF0gICBnZm46IDAwMDA1NTlmICBtZm46IDAwMDA1NTlmDQoNCmQgMDowOjA6MDogW3Nk
YV0oWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoyMF0gICBnZm46IDAwMDA1NWEwICBtZm46IDAw
MDA1NWEwDQoNCiBDREI6IA0KDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjIwXSAgIGdm
bjogMDAwMDU1YTEgIG1mbjogMDAwMDU1YTENCg0KWyAgNDYzLjkyMTkzNl0gV3JpdGUoMTAp
OiAyYSAwMCAoWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoyMF0gICBnZm46IDAwMDA1NWEyICBt
Zm46IDAwMDA1NWEyDQoNCjA1IGI2IDU3IDYxIDAwIDAoWEVOKSBbMjAxMi0wOC0zMSAyMToz
MzoyMF0gICBnZm46IDAwMDA1NWEzICBtZm46IDAwMDA1NWEzDQoNCjAgMDggMDANCg0KDQoo
WEVOKSBbMjAxMi0wOC0zMSAyMTozMzoyMF0gICBnZm46IDAwMDA1NWE0ICBtZm46IDAwMDA1
NWE0DQoNClsgIDQ2My45MjE5MzddIGUoWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoyMF0gICBn
Zm46IDAwMDA1NWE1ICBtZm46IDAwMDA1NWE1DQoNCm5kX3JlcXVlc3Q6IEkvTyAoWEVOKSBb
MjAxMi0wOC0zMSAyMTozMzoyMF0gICBnZm46IDAwMDA1NWE2ICBtZm46IDAwMDA1NWE2DQoN
CmVycm9yLCBkZXYgc2RhLCAoWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoyMF0gICBnZm46IDAw
MDA1NWE3ICBtZm46IDAwMDA1NWE3DQoNCnNlY3RvciA5NTgzNjAwMQ0KDQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMzOjIwXSAgIGdmbjogMDAwMDU1YTggIG1mbjogMDAwMDU1YTgNCg0K
WyAgNDYzLjkyMTkzOV0gQihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjIwXSAgIGdmbjogMDAw
MDU1YTkgIG1mbjogMDAwMDU1YTkNCg0KdWZmZXIgSS9PIGVycm9yIG9uIGRldmljZSBkbS0w
LCAoWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoyMF0gICBnZm46IDAwMDA1NWFhICBtZm46IDAw
MDA1NWFhDQoNCmxvZ2ljYWwgYmxvY2sgOTUoWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoyMF0g
ICBnZm46IDAwMDA1NWFiICBtZm46IDAwMDA1NWFiDQoNCjM1NTY0DQoNCg0KKFhFTikgWzIw
MTItMDgtMzEgMjE6MzM6MjBdICAgZ2ZuOiAwMDAwNTVhYyAgbWZuOiAwMDAwNTVhYw0KDQpb
ICA0NjMuOTIxOTM5XSBsKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MjBdICAgZ2ZuOiAwMDAw
NTVhZCAgbWZuOiAwMDAwNTVhZA0KDQpvc3QgcGFnZSB3cml0ZSBkKFhFTikgWzIwMTItMDgt
MzEgMjE6MzM6MjBdICAgZ2ZuOiAwMDAwNTVhZSAgbWZuOiAwMDAwNTVhZQ0KDQp1ZSB0byBJ
L08gZXJyb3IgKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MjBdICAgZ2ZuOiAwMDAwNTVhZiAg
bWZuOiAwMDAwNTVhZg0KDQpvbiBkbS0wDQoNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6
MjBdICAgZ2ZuOiAwMDAwNTViMCAgbWZuOiAwMDAwNTViMA0KDQpbICA0NjMuOTIxOTQ4XSBz
KFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MjFdICAgZ2ZuOiAwMDAwNTViMSAgbWZuOiAwMDAw
NTViMQ0KDQpkIDA6MDowOjA6IFtzZGFdIFVuaGFuZGxlZCBlcnJvcihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMzOjIxXSAgIGdmbjogMDAwMDU1YjIgIG1mbjogMDAwMDU1YjINCg0KIGNvZGUN
Cg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoyMV0gICBnZm46IDAwMDA1NWIzICBtZm46
IDAwMDA1NWIzDQoNClsgIDQ2My45MjE5NDldIHNkIDA6MDowOjA6IFtzZGFdKFhFTikgWzIw
MTItMDgtMzEgMjE6MzM6MjFdICAgZ2ZuOiAwMDAwNTViNCAgbWZuOiAwMDAwNTViNA0KDQog
IA0KDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjIxXSAgIGdmbjogMDAwMDU1YjUgIG1m
bjogMDAwMDU1YjUNCg0KWyAgNDYzLjkyMTk1MF0gUihYRU4pIFsyMDEyLTA4LTMxIDIxOjMz
OjIxXSAgIGdmbjogMDAwMDU1YjYgIG1mbjogMDAwMDU1YjYNCg0KZXN1bHQ6IGhvc3RieXRl
PShYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjIxXSAgIGdmbjogMDAwMDU1YjcgIG1mbjogMDAw
MDU1YjcNCg0KRElEX0JBRF9UQVJHRVQgZHJpdmVyYnl0ZT1EUklWRVIoWEVOKSBbMjAxMi0w
OC0zMSAyMTozMzoyMV0gICBnZm46IDAwMDA1NWI4ICBtZm46IDAwMDA1NWI4DQoNCl9PSw0K
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjIxXSAgIGdmbjogMDAwMDU1YjkgIG1mbjog
MDAwMDU1YjkNCg0KWyAgNDYzLjkyMTk1MV0gc2QgMDowOjA6MDogW3NkYV0oWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMzoyMV0gICBnZm46IDAwMDA1NWJhICBtZm46IDAwMDA1NWJhDQoNCiBD
REI6IA0KDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjIxXSAgIGdmbjogMDAwMDU1YmIg
IG1mbjogMDAwMDU1YmINCg0KWyAgNDYzLjkyMTk1NF0gV3JpdGUoMTApOiAyYSAwMCAoWEVO
KSBbMjAxMi0wOC0zMSAyMTozMzoyMV0gICBnZm46IDAwMDA1NWJjICBtZm46IDAwMDA1NWJj
DQoNCjA2IDllIDU1IDAxIDAwIDAoWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoyMV0gICBnZm46
IDAwMDA1NWJkICBtZm46IDAwMDA1NWJkDQoNCjAgMTggMDANCg0KDQooWEVOKSBbMjAxMi0w
OC0zMSAyMTozMzoyMV0gICBnZm46IDAwMDA1NWJlICBtZm46IDAwMDA1NWJlDQoNClsgIDQ2
My45MjE5NTVdIGUoWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoyMV0gICBnZm46IDAwMDA1NWJm
ICBtZm46IDAwMDA1NWJmDQoNCm5kX3JlcXVlc3Q6IEkvTyAoWEVOKSBbMjAxMi0wOC0zMSAy
MTozMzoyMV0gICBnZm46IDAwMDA1NWMwICBtZm46IDAwMDA1NWMwDQoNCmVycm9yLCBkZXYg
c2RhLCAoWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoyMV0gICBnZm46IDAwMDA1NWMxICBtZm46
IDAwMDA1NWMxDQoNCnNlY3RvciAxMTEwMzk3NDUoWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoy
MV0gICBnZm46IDAwMDA1NWMyICBtZm46IDAwMDA1NWMyDQoNCg0KDQoNCihYRU4pIFsyMDEy
LTA4LTMxIDIxOjMzOjIxXSAgIGdmbjogMDAwMDU1YzMgIG1mbjogMDAwMDU1YzMNCg0KWyAg
NDYzLjkyMTk1N10gQnVmZmVyIEkvTyBlcnJvciAoWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoy
MV0gICBnZm46IDAwMDA1NWM0ICBtZm46IDAwMDA1NWM0DQoNCm9uIGRldmljZSBkbS0wLCAo
WEVOKSBbMjAxMi0wOC0zMSAyMTozMzoyMV0gICBnZm46IDAwMDA1NWM1ICBtZm46IDAwMDA1
NWM1DQoNCmxvZ2ljYWwgYmxvY2sgMTE0MzYwMzINCg0KDQooWEVOKSBbMjAxMi0wOC0zMSAy
MTozMzoyMV0gICBnZm46IDAwMDA1NWM2ICBtZm46IDAwMDA1NWM2DQoNClsgIDQ2My45MjE5
NTddIGwoWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoyMV0gICBnZm46IDAwMDA1NWM3ICBtZm46
IDAwMDA1NWM3DQoNCm9zdCBwYWdlIHdyaXRlIGQoWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoy
MV0gICBnZm46IDAwMDA1NWM4ICBtZm46IDAwMDA1NWM4DQoNCnVlIHRvIEkvTyBlcnJvciAo
WEVOKSBbMjAxMi0wOC0zMSAyMTozMzoyMV0gICBnZm46IDAwMDA1NWM5ICBtZm46IDAwMDA1
NWM5DQoNCm9uIGRtLTANCg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoyMV0gICBnZm46
IDAwMDA1NWNhICBtZm46IDAwMDA1NWNhDQoNClsgIDQ2My45MjE5NjBdIEIoWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMzoyMV0gICBnZm46IDAwMDA1NWNiICBtZm46IDAwMDA1NWNiDQoNCnVm
ZmVyIEkvTyBlcnJvciBvbiBkZXZpY2UgZG0tMCwgKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6
MjFdICAgZ2ZuOiAwMDAwNTVjYyAgbWZuOiAwMDAwNTVjYw0KDQpsb2dpY2FsIGJsb2NrIDEx
KFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MjFdICAgZ2ZuOiAwMDAwNTVjZCAgbWZuOiAwMDAw
NTVjZA0KDQo0MzYwMzMNCg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoyMV0gICBnZm46
IDAwMDA1NWNlICBtZm46IDAwMDA1NWNlDQoNClsgIDQ2My45MjE5NjFdIGwoWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMzoyMV0gICBnZm46IDAwMDA1NWNmICBtZm46IDAwMDA1NWNmDQoNCm9z
dCBwYWdlIHdyaXRlIGQoWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoyMV0gICBnZm46IDAwMDA1
NWQwICBtZm46IDAwMDA1NWQwDQoNCnVlIHRvIEkvTyBlcnJvciAoWEVOKSBbMjAxMi0wOC0z
MSAyMTozMzoyMV0gICBnZm46IDAwMDA1NWQxICBtZm46IDAwMDA1NWQxDQoNCm9uIGRtLTAN
Cg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoyMV0gICBnZm46IDAwMDA1NWQyICBtZm46
IDAwMDA1NWQyDQoNClsgIDQ2My45MjE5NjNdIEIoWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoy
MV0gICBnZm46IDAwMDA1NWQzICBtZm46IDAwMDA1NWQzDQoNCnVmZmVyIEkvTyBlcnJvciAo
WEVOKSBbMjAxMi0wOC0zMSAyMTozMzoyMV0gICBnZm46IDAwMDA1NWQ0ICBtZm46IDAwMDA1
NWQ0DQoNCm9uIGRldmljZSBkbS0wLCAoWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoyMV0gICBn
Zm46IDAwMDA1NWQ1ICBtZm46IDAwMDA1NWQ1DQoNCmxvZ2ljYWwgYmxvY2sgMTE0MzYwMzQN
Cg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoyMV0gICBnZm46IDAwMDA1NWQ2ICBtZm46
IDAwMDA1NWQ2DQoNClsgIDQ2My45MjE5NjNdIGwoWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoy
MV0gICBnZm46IDAwMDA1NWQ3ICBtZm46IDAwMDA1NWQ3DQoNCm9zdCBwYWdlIHdyaXRlIGR1
ZSB0byBJL08gZXJyb3IgKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MjFdICAgZ2ZuOiAwMDAw
NTVkOCAgbWZuOiAwMDAwNTVkOA0KDQpvbiBkbS0wDQoNCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzM6MjFdICAgZ2ZuOiAwMDAwNTVkOSAgbWZuOiAwMDAwNTVkOQ0KDQpbICA0NjMuOTIx
OTcwXSBzZCAwOjA6MDowOiBbc2RhXShYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjIxXSAgIGdm
bjogMDAwMDU1ZGEgIG1mbjogMDAwMDU1ZGENCg0KIFVuaGFuZGxlZCBlcnJvcihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMzOjIxXSAgIGdmbjogMDAwMDU1ZGIgIG1mbjogMDAwMDU1ZGINCg0K
IGNvZGUNCg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoyMV0gICBnZm46IDAwMDA1NWRj
ICBtZm46IDAwMDA1NWRjDQoNClsgIDQ2My45MjE5NzFdIHMoWEVOKSBbMjAxMi0wOC0zMSAy
MTozMzoyMV0gICBnZm46IDAwMDA1NWRkICBtZm46IDAwMDA1NWRkDQoNCmQgMDowOjA6MDog
W3NkYV0oWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoyMV0gICBnZm46IDAwMDA1NWRlICBtZm46
IDAwMDA1NWRlDQoNCiAgDQoNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MjFdICAgZ2Zu
OiAwMDAwNTVkZiAgbWZuOiAwMDAwNTVkZg0KDQpbICA0NjMuOTIxOTcxXSBSZXN1bHQ6IGhv
c3RieXRlPShYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjIxXSAgIGdmbjogMDAwMDU1ZTAgIG1m
bjogMDAwMDU1ZTANCg0KRElEX0JBRF9UQVJHRVQgZChYRU4pIFsyMDEyLTA4LTMxIDIxOjMz
OjIxXSAgIGdmbjogMDAwMDU1ZTEgIG1mbjogMDAwMDU1ZTENCg0Kcml2ZXJieXRlPURSSVZF
UihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjIxXSAgIGdmbjogMDAwMDU1ZTIgIG1mbjogMDAw
MDU1ZTINCg0KX09LDQoNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MjJdICAgZ2ZuOiAw
MDAwNTVlMyAgbWZuOiAwMDAwNTVlMw0KDQpbICA0NjMuOTIxOTcyXSBzZCAwOjA6MDowOiBb
c2RhXShYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjIyXSAgIGdmbjogMDAwMDU1ZTQgIG1mbjog
MDAwMDU1ZTQNCg0KIENEQjogDQoNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MjJdICAg
Z2ZuOiAwMDAwNTVlNSAgbWZuOiAwMDAwNTVlNQ0KDQpbICA0NjMuOTIxOTc1XSBXKFhFTikg
WzIwMTItMDgtMzEgMjE6MzM6MjJdICAgZ2ZuOiAwMDAwNTVlNiAgbWZuOiAwMDAwNTVlNg0K
DQpyaXRlKDEwKTogMmEgMDAgKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MjJdICAgZ2ZuOiAw
MDAwNTVlNyAgbWZuOiAwMDAwNTVlNw0KDQowNiA5ZSA1YSBiMSAwMCAwKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzM6MjJdICAgZ2ZuOiAwMDAwNTVlOCAgbWZuOiAwMDAwNTVlOA0KDQowIDA4
IDAwDQoNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MjJdICAgZ2ZuOiAwMDAwNTVlOSAg
bWZuOiAwMDAwNTVlOQ0KDQpbICA0NjMuOTIxOTc2XSBlKFhFTikgWzIwMTItMDgtMzEgMjE6
MzM6MjJdICAgZ2ZuOiAwMDAwNTVlYSAgbWZuOiAwMDAwNTVlYQ0KDQpuZF9yZXF1ZXN0OiBJ
L08gKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MjJdICAgZ2ZuOiAwMDAwNTVlYiAgbWZuOiAw
MDAwNTVlYg0KDQplcnJvciwgZGV2IHNkYSwgc2VjdG9yIDExMTA0MTIwMShYRU4pIFsyMDEy
LTA4LTMxIDIxOjMzOjIyXSAgIGdmbjogMDAwMDU1ZWMgIG1mbjogMDAwMDU1ZWMNCg0KDQoN
Cg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MjJdICAgZ2ZuOiAwMDAwNTVlZCAgbWZuOiAw
MDAwNTVlZA0KDQpbICA0NjMuOTIxOTc4XSBCdWZmZXIgSS9PIGVycm9yIChYRU4pIFsyMDEy
LTA4LTMxIDIxOjMzOjIyXSAgIGdmbjogMDAwMDU1ZWUgIG1mbjogMDAwMDU1ZWUNCg0Kb24g
ZGV2aWNlIGRtLTAsIChYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjIyXSAgIGdmbjogMDAwMDU1
ZWYgIG1mbjogMDAwMDU1ZWYNCg0KbG9naWNhbCBibG9jayAxMTQzNjIxNA0KDQoNCihYRU4p
IFsyMDEyLTA4LTMxIDIxOjMzOjIyXSAgIGdmbjogMDAwMDU1ZjAgIG1mbjogMDAwMDU1ZjAN
Cg0KWyAgNDYzLjkyMTk3OF0gbChYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjIyXSAgIGdmbjog
MDAwMDU1ZjEgIG1mbjogMDAwMDU1ZjENCg0Kb3N0IHBhZ2Ugd3JpdGUgZHVlIHRvIEkvTyBl
cnJvciAoWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoyMl0gICBnZm46IDAwMDA1NWYyICBtZm46
IDAwMDA1NWYyDQoNCm9uIGRtLTANCg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoyMl0g
ICBnZm46IDAwMDA1NWYzICBtZm46IDAwMDA1NWYzDQoNClsgIDQ2My45MjE5ODZdIHNkIDA6
MDowOjA6IFtzZGFdKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MjJdICAgZ2ZuOiAwMDAwNTVm
NCAgbWZuOiAwMDAwNTVmNA0KDQogVW5oYW5kbGVkIGVycm9yKFhFTikgWzIwMTItMDgtMzEg
MjE6MzM6MjJdICAgZ2ZuOiAwMDAwNTVmNSAgbWZuOiAwMDAwNTVmNQ0KDQogY29kZQ0KDQoN
CihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjIyXSAgIGdmbjogMDAwMDU1ZjYgIG1mbjogMDAw
MDU1ZjYNCg0KWyAgNDYzLjkyMTk4N10gcyhYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjIyXSAg
IGdmbjogMDAwMDU1ZjcgIG1mbjogMDAwMDU1ZjcNCg0KZCAwOjA6MDowOiBbc2RhXSAgDQoN
Cg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MjJdICAgZ2ZuOiAwMDAwNTVmOCAgbWZuOiAw
MDAwNTVmOA0KDQpbICA0NjMuOTIxOTg4XSBSKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MjJd
ICAgZ2ZuOiAwMDAwNTVmOSAgbWZuOiAwMDAwNTVmOQ0KDQplc3VsdDogaG9zdGJ5dGU9KFhF
TikgWzIwMTItMDgtMzEgMjE6MzM6MjJdICAgZ2ZuOiAwMDAwNTVmYSAgbWZuOiAwMDAwNTVm
YQ0KDQpESURfQkFEX1RBUkdFVCBkKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MjJdICAgZ2Zu
OiAwMDAwNTVmYiAgbWZuOiAwMDAwNTVmYg0KDQpyaXZlcmJ5dGU9RFJJVkVSX09LDQoNCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MjJdICAgZ2ZuOiAwMDAwNTVmYyAgbWZuOiAwMDAw
NTVmYw0KDQpbICA0NjMuOTIxOTg4XSBzKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MjJdICAg
Z2ZuOiAwMDAwNTVmZCAgbWZuOiAwMDAwNTVmZA0KDQpkIDA6MDowOjA6IFtzZGFdIENEQjog
DQoNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MjJdICAgZ2ZuOiAwMDAwNTVmZSAgbWZu
OiAwMDAwNTVmZQ0KDQpbICA0NjMuOTIxOTkxXSBXKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6
MjJdICAgZ2ZuOiAwMDAwNTVmZiAgbWZuOiAwMDAwNTVmZg0KDQpyaXRlKDEwKTogMmEgMDAg
MDYgOWUgNjUgZTEgMDAgMChYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjIyXSAgIGdmbjogMDAw
MDU2MDAgIG1mbjogMDAwMDU2MDANCg0KMCAwOCAwMA0KDQoNCihYRU4pIFsyMDEyLTA4LTMx
IDIxOjMzOjIyXSAgIGdmbjogMDAwMDU2MDEgIG1mbjogMDAwMDU2MDENCg0KWyAgNDYzLjky
MTk5Ml0gZW5kX3JlcXVlc3Q6IEkvTyBlcnJvciwgZGV2IHNkYSwgKFhFTikgWzIwMTItMDgt
MzEgMjE6MzM6MjJdICAgZ2ZuOiAwMDAwNTYwMiAgbWZuOiAwMDAwNTYwMg0KDQpzZWN0b3Ig
MTExMDQ0MDY1KFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MjJdICAgZ2ZuOiAwMDAwNTYwMyAg
bWZuOiAwMDAwNTYwMw0KDQoNCg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoyMl0gICBn
Zm46IDAwMDA1NjA0ICBtZm46IDAwMDA1NjA0DQoNClsgIDQ2My45MjE5OTVdIEIoWEVOKSBb
MjAxMi0wOC0zMSAyMTozMzoyMl0gICBnZm46IDAwMDA1NjA1ICBtZm46IDAwMDA1NjA1DQoN
CnVmZmVyIEkvTyBlcnJvciAoWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoyMl0gICBnZm46IDAw
MDA1NjA2ICBtZm46IDAwMDA1NjA2DQoNCm9uIGRldmljZSBkbS0wLCAoWEVOKSBbMjAxMi0w
OC0zMSAyMTozMzoyMl0gICBnZm46IDAwMDA1NjA3ICBtZm46IDAwMDA1NjA3DQoNCmxvZ2lj
YWwgYmxvY2sgMTE0MzY1NzINCg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoyMl0gICBn
Zm46IDAwMDA1NjA4ICBtZm46IDAwMDA1NjA4DQoNClsgIDQ2My45MjE5OTZdIGwoWEVOKSBb
MjAxMi0wOC0zMSAyMTozMzoyMl0gICBnZm46IDAwMDA1NjA5ICBtZm46IDAwMDA1NjA5DQoN
Cm9zdCBwYWdlIHdyaXRlIGR1ZSB0byBJL08gZXJyb3IgKFhFTikgWzIwMTItMDgtMzEgMjE6
MzM6MjJdICAgZ2ZuOiAwMDAwNTYwYSAgbWZuOiAwMDAwNTYwYQ0KDQpvbiBkbS0wDQoNCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MjJdICAgZ2ZuOiAwMDAwNTYwYiAgbWZuOiAwMDAw
NTYwYg0KDQpbICA0NjMuOTIyMDIxXSBBYm9ydGluZyBqb3VybmFsIChYRU4pIFsyMDEyLTA4
LTMxIDIxOjMzOjIyXSAgIGdmbjogMDAwMDU2MGMgIG1mbjogMDAwMDU2MGMNCg0Kb24gZGV2
aWNlIGRtLTAtOChYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjIyXSAgIGdmbjogMDAwMDU2MGQg
IG1mbjogMDAwMDU2MGQNCg0KLg0KDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjIyXSAg
IGdmbjogMDAwMDU2MGUgIG1mbjogMDAwMDU2MGUNCg0KWyAgNDYzLjkyMjA4MF0gRShYRU4p
IFsyMDEyLTA4LTMxIDIxOjMzOjIyXSAgIGdmbjogMDAwMDU2MGYgIG1mbjogMDAwMDU2MGYN
Cg0KWFQ0LWZzIChkbS0wKTogZChYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjIyXSAgIGdmbjog
MDAwMDU2MTAgIG1mbjogMDAwMDU2MTANCg0KZWxheWVkIGJsb2NrIGFsbChYRU4pIFsyMDEy
LTA4LTMxIDIxOjMzOjIyXSAgIGdmbjogMDAwMDU2MTEgIG1mbjogMDAwMDU2MTENCg0Kb2Nh
dGlvbiBmYWlsZWQgZm9yIGlub2RlIDIxMDU0MTkoWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoy
Ml0gICBnZm46IDAwMDA1NjEyICBtZm46IDAwMDA1NjEyDQoNCiBhdCBsb2dpY2FsIG9mZnMo
WEVOKSBbMjAxMi0wOC0zMSAyMTozMzoyMl0gICBnZm46IDAwMDA1NjEzICBtZm46IDAwMDA1
NjEzDQoNCmV0IDM5IHdpdGggbWF4IGJsb2NrcyA1IHdpdGggZXJyKFhFTikgWzIwMTItMDgt
MzEgMjE6MzM6MjNdICAgZ2ZuOiAwMDAwNTYxNCAgbWZuOiAwMDAwNTYxNA0KDQpvciAtMzAN
Cg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoyM10gICBnZm46IDAwMDA1NjE1ICBtZm46
IDAwMDA1NjE1DQoNClsgIDQ2My45MjIwODFdIEVYVDQtZnMgKGRtLTApOiBUKFhFTikgWzIw
MTItMDgtMzEgMjE6MzM6MjNdICAgZ2ZuOiAwMDAwNTYxNiAgbWZuOiAwMDAwNTYxNg0KDQpo
aXMgc2hvdWxkIG5vdCBoKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MjNdICAgZ2ZuOiAwMDAw
NTYxNyAgbWZuOiAwMDAwNTYxNw0KDQphcHBlbiEhIERhdGEgd2lsbCBiZSBsb3N0DQoNCg0K
WyAgNDYoWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoyM10gICBnZm46IDAwMDA1NjE4ICBtZm46
IDAwMDA1NjE4DQoNCjMuOTIyMDgxXSANCg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoy
M10gICBnZm46IDAwMDA1NjE5ICBtZm46IDAwMDA1NjE5DQoNClsgIDQ2My45MjIxMzFdIEVY
VDQtZnMgZXJyb3IgKGRlKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MjNdICAgZ2ZuOiAwMDAw
NTYxYSAgbWZuOiAwMDAwNTYxYQ0KDQp2aWNlIGRtLTApIGluIGV4KFhFTikgWzIwMTItMDgt
MzEgMjE6MzM6MjNdICAgZ2ZuOiAwMDAwNTYxYiAgbWZuOiAwMDAwNTYxYg0KDQp0NF9kYV93
cml0ZXBhZ2VzOjIzOTg6IEpvdXJuYWwgaChYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjIzXSAg
IGdmbjogMDAwMDU2MWMgIG1mbjogMDAwMDU2MWMNCg0KYXMgYWJvcnRlZA0KDQoNCihYRU4p
IFsyMDEyLTA4LTMxIDIxOjMzOjIzXSAgIGdmbjogMDAwMDU2MWQgIG1mbjogMDAwMDU2MWQN
Cg0KWyAgNDYzLjkyMjIzM10gRVhUNC1mcyBlcnJvciAoZGUoWEVOKSBbMjAxMi0wOC0zMSAy
MTozMzoyM10gICBnZm46IDAwMDA1NjFlICBtZm46IDAwMDA1NjFlDQoNCnZpY2UgZG0tMCkg
aW4gZXgoWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoyM10gICBnZm46IDAwMDA1NjFmICBtZm46
IDAwMDA1NjFmDQoNCnQ0X3Jlc2VydmVfaW5vZGVfd3JpdGU6NDU0MzogSm91KFhFTikgWzIw
MTItMDgtMzEgMjE6MzM6MjNdICAgZ2ZuOiAwMDAwNTYyMCAgbWZuOiAwMDAwNTYyMA0KDQpy
bmFsIGhhcyBhYm9ydGVkKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MjNdICAgZ2ZuOiAwMDAw
NTYyMSAgbWZuOiAwMDAwNTYyMQ0KDQoNCg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoy
M10gICBnZm46IDAwMDA1NjIyICBtZm46IDAwMDA1NjIyDQoNClsgIDQ2My45MjIyNjldIHMo
WEVOKSBbMjAxMi0wOC0zMSAyMTozMzoyM10gICBnZm46IDAwMDA1NjIzICBtZm46IDAwMDA1
NjIzDQoNCmQgMDowOjA6MDogW3NkYV0gVW5oYW5kbGVkIGVycm9yKFhFTikgWzIwMTItMDgt
MzEgMjE6MzM6MjNdICAgZ2ZuOiAwMDAwNTYyNCAgbWZuOiAwMDAwNTYyNA0KDQogY29kZQ0K
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjIzXSAgIGdmbjogMDAwMDU2MjUgIG1mbjog
MDAwMDU2MjUNCg0KWyAgNDYzLjkyMjI3MF0gc2QgMDowOjA6MDogW3NkYV0oWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMzoyM10gICBnZm46IDAwMDA1NjI2ICBtZm46IDAwMDA1NjI2DQoNCiAg
DQoNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MjNdICAgZ2ZuOiAwMDAwNTYyNyAgbWZu
OiAwMDAwNTYyNw0KDQpbICA0NjMuOTIyMjcxXSBSZXN1bHQ6IGhvc3RieXRlPShYRU4pIFsy
MDEyLTA4LTMxIDIxOjMzOjIzXSAgIGdmbjogMDAwMDU2MjggIG1mbjogMDAwMDU2MjgNCg0K
RElEX0JBRF9UQVJHRVQgZChYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjIzXSAgIGdmbjogMDAw
MDU2MjkgIG1mbjogMDAwMDU2MjkNCg0Kcml2ZXJieXRlPURSSVZFUl9PSw0KDQoNCihYRU4p
IFsyMDEyLTA4LTMxIDIxOjMzOjIzXSAgIGdmbjogMDAwMDU2MmEgIG1mbjogMDAwMDU2MmEN
Cg0KWyAgNDYzLjkyMjI3Ml0gcyhYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjIzXSAgIGdmbjog
MDAwMDU2MmIgIG1mbjogMDAwMDU2MmINCg0KZCAwOjA6MDowOiBbc2RhXSBDREI6IA0KDQoN
CihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjIzXSAgIGdmbjogMDAwMDU2MmMgIG1mbjogMDAw
MDU2MmMNCg0KWyAgNDYzLjkyMjI3NV0gVyhYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjIzXSAg
IGdmbjogMDAwMDU2MmQgIG1mbjogMDAwMDU2MmQNCg0Kcml0ZSgxMCk6IDJhIDAwIDAxIDJh
IDg1IDQ5IDAwIDAoWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoyM10gICBnZm46IDAwMDA1NjJl
ICBtZm46IDAwMDA1NjJlDQoNCjAgMDggMDANCg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
MzoyM10gICBnZm46IDAwMDA1NjJmICBtZm46IDAwMDA1NjJmDQoNClsgIDQ2My45MjIyNzZd
IGVuZF9yZXF1ZXN0OiBJL08gKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MjNdICAgZ2ZuOiAw
MDAwNTYzMCAgbWZuOiAwMDAwNTYzMA0KDQplcnJvciwgZGV2IHNkYSwgKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzM6MjNdICAgZ2ZuOiAwMDAwNTYzMSAgbWZuOiAwMDAwNTYzMQ0KDQpzZWN0
b3IgMTk1NjM4NDkNCg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoyM10gICBnZm46IDAw
MDA1NjMyICBtZm46IDAwMDA1NjMyDQoNClsgIDQ2My45MjIyOTJdIEooWEVOKSBbMjAxMi0w
OC0zMSAyMTozMzoyM10gICBnZm46IDAwMDA1NjMzICBtZm46IDAwMDA1NjMzDQoNCkJEMjog
RXJyb3IgLTUgZGV0ZWN0ZWQgd2hlbiB1cGRhdGluZyBqb3VybmFsIHN1cChYRU4pIFsyMDEy
LTA4LTMxIDIxOjMzOjIzXSAgIGdmbjogMDAwMDU2MzQgIG1mbjogMDAwMDU2MzQNCg0KZXJi
bG9jayBmb3IgZG0tMChYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjIzXSAgIGdmbjogMDAwMDU2
MzUgIG1mbjogMDAwMDU2MzUNCg0KLTguDQoNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6
MjNdICAgZ2ZuOiAwMDAwNTYzNiAgbWZuOiAwMDAwNTYzNg0KDQpbICA0NjMuOTIyMzU3XSBz
KFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MjNdICAgZ2ZuOiAwMDAwNTYzNyAgbWZuOiAwMDAw
NTYzNw0KDQpkIDA6MDowOjA6IFtzZGFdKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MjNdICAg
Z2ZuOiAwMDAwNTYzOCAgbWZuOiAwMDAwNTYzOA0KDQogVW5oYW5kbGVkIGVycm9yKFhFTikg
WzIwMTItMDgtMzEgMjE6MzM6MjNdICAgZ2ZuOiAwMDAwNTYzOSAgbWZuOiAwMDAwNTYzOQ0K
DQogY29kZQ0KDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjIzXSAgIGdmbjogMDAwMDU2
M2EgIG1mbjogMDAwMDU2M2ENCg0KWyAgNDYzLjkyMjM1OF0gcyhYRU4pIFsyMDEyLTA4LTMx
IDIxOjMzOjIzXSAgIGdmbjogMDAwMDU2M2IgIG1mbjogMDAwMDU2M2INCg0KZCAwOjA6MDow
OiBbc2RhXSAgDQoNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MjNdICAgZ2ZuOiAwMDAw
NTYzYyAgbWZuOiAwMDAwNTYzYw0KDQpbICA0NjMuOTIyMzU4XSBSKFhFTikgWzIwMTItMDgt
MzEgMjE6MzM6MjNdICAgZ2ZuOiAwMDAwNTYzZCAgbWZuOiAwMDAwNTYzZA0KDQplc3VsdDog
aG9zdGJ5dGU9RElEX0JBRF9UQVJHRVQgZChYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjIzXSAg
IGdmbjogMDAwMDU2M2UgIG1mbjogMDAwMDU2M2UNCg0Kcml2ZXJieXRlPURSSVZFUihYRU4p
IFsyMDEyLTA4LTMxIDIxOjMzOjIzXSAgIGdmbjogMDAwMDU2M2YgIG1mbjogMDAwMDU2M2YN
Cg0KX09LDQoNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MjNdICAgZ2ZuOiAwMDAwNTY0
MCAgbWZuOiAwMDAwNTY0MA0KDQpbICA0NjMuOTIyMzU5XSBzKFhFTikgWzIwMTItMDgtMzEg
MjE6MzM6MjNdICAgZ2ZuOiAwMDAwNTY0MSAgbWZuOiAwMDAwNTY0MQ0KDQpkIDA6MDowOjA6
IFtzZGFdKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MjNdICAgZ2ZuOiAwMDAwNTY0MiAgbWZu
OiAwMDAwNTY0Mg0KDQogQ0RCOiANCg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoyM10g
ICBnZm46IDAwMDA1NjQzICBtZm46IDAwMDA1NjQzDQoNClsgIDQ2My45MjIzNjNdIFdyaXRl
KDEwKTogMmEgMDAgKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MjRdICAgZ2ZuOiAwMDAwNTY0
NCAgbWZuOiAwMDAwNTY0NA0KDQowMSAyYSA1NSAwMSAwMCAwKFhFTikgWzIwMTItMDgtMzEg
MjE6MzM6MjRdICAgZ2ZuOiAwMDAwNTY0NSAgbWZuOiAwMDAwNTY0NQ0KDQowIDA4IDAwDQoN
Cg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MjRdICAgZ2ZuOiAwMDAwNTY0NiAgbWZuOiAw
MDAwNTY0Ng0KDQpbICA0NjMuOTIyMzYzXSBlKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MjRd
ICAgZ2ZuOiAwMDAwNTY0NyAgbWZuOiAwMDAwNTY0Nw0KDQpuZF9yZXF1ZXN0OiBJL08gZXJy
b3IsIGRldiBzZGEsIChYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjI0XSAgIGdmbjogMDAwMDU2
NDggIG1mbjogMDAwMDU2NDgNCg0Kc2VjdG9yIDE5NTUxNDg5DQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMzoyNF0gICBnZm46IDAwMDA1NjQ5ICBtZm46IDAwMDA1NjQ5DQoNCg0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMzoyNF0gICBnZm46IDAwMDA1NjRhICBtZm46IDAwMDA1NjRh
DQoNClsgIDQ2My45MjI1MjJdIHMoWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoyNF0gICBnZm46
IDAwMDA1NjRiICBtZm46IDAwMDA1NjRiDQoNCmQgMDowOjA6MDogW3NkYV0oWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMzoyNF0gICBnZm46IDAwMDA1NjRjICBtZm46IDAwMDA1NjRjDQoNCiBV
bmhhbmRsZWQgZXJyb3IoWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoyNF0gICBnZm46IDAwMDA1
NjRkICBtZm46IDAwMDA1NjRkDQoNCiBjb2RlDQoNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6
MzM6MjRdICAgZ2ZuOiAwMDAwNTY0ZSAgbWZuOiAwMDAwNTY0ZQ0KDQpbICA0NjMuOTIyNTIz
XSBzKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MjRdICAgZ2ZuOiAwMDAwNTY0ZiAgbWZuOiAw
MDAwNTY0Zg0KDQpkIDA6MDowOjA6IFtzZGFdKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MjRd
ICAgZ2ZuOiAwMDAwNTY1MCAgbWZuOiAwMDAwNTY1MA0KDQogIA0KDQoNCihYRU4pIFsyMDEy
LTA4LTMxIDIxOjMzOjI0XSAgIGdmbjogMDAwMDU2NTEgIG1mbjogMDAwMDU2NTENCg0KWyAg
NDYzLjkyMjUyNF0gUmVzdWx0OiBob3N0Ynl0ZT0oWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoy
NF0gICBnZm46IDAwMDA1NjUyICBtZm46IDAwMDA1NjUyDQoNCkRJRF9CQURfVEFSR0VUIGQo
WEVOKSBbMjAxMi0wOC0zMSAyMTozMzoyNF0gICBnZm46IDAwMDA1NjUzICBtZm46IDAwMDA1
NjUzDQoNCnJpdmVyYnl0ZT1EUklWRVJfT0sNCg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
MzoyNF0gICBnZm46IDAwMDA1NjU0ICBtZm46IDAwMDA1NjU0DQoNClsgIDQ2My45MjI1MjVd
IHMoWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoyNF0gICBnZm46IDAwMDA1NjU1ICBtZm46IDAw
MDA1NjU1DQoNCmQgMDowOjA6MDogW3NkYV0gQ0RCOiANCg0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMzoyNF0gICBnZm46IDAwMDA1NjU2ICBtZm46IDAwMDA1NjU2DQoNClsgIDQ2My45
MjI1MjhdIFcoWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoyNF0gICBnZm46IDAwMDA1NjU3ICBt
Zm46IDAwMDA1NjU3DQoNCnJpdGUoMTApOiAyYSAwMCAwMSAyYSA1NSAwMSAwMCAwKFhFTikg
WzIwMTItMDgtMzEgMjE6MzM6MjRdICAgZ2ZuOiAwMDAwNTY1OCAgbWZuOiAwMDAwNTY1OA0K
DQowIDA4IDAwDQoNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MjRdICAgZ2ZuOiAwMDAw
NTY1OSAgbWZuOiAwMDAwNTY1OQ0KDQpbICA0NjMuOTIyNTI5XSBlbmRfcmVxdWVzdDogSS9P
IChYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjI0XSAgIGdmbjogMDAwMDU2NWEgIG1mbjogMDAw
MDU2NWENCg0KZXJyb3IsIGRldiBzZGEsIChYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjI0XSAg
IGdmbjogMDAwMDU2NWIgIG1mbjogMDAwMDU2NWINCg0Kc2VjdG9yIDE5NTUxNDg5DQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMzoyNF0gICBnZm46IDAwMDA1NjVjICBtZm46IDAwMDA1NjVj
DQoNCg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoyNF0gICBnZm46IDAwMDA1NjVkICBt
Zm46IDAwMDA1NjVkDQoNClsgIDQ2My45MjI1NDJdIEVYVDQtZnMgKGRtLTApOiBSKFhFTikg
WzIwMTItMDgtMzEgMjE6MzM6MjRdICAgZ2ZuOiAwMDAwNTY1ZSAgbWZuOiAwMDAwNTY1ZQ0K
DQplbW91bnRpbmcgZmlsZXN5KFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MjRdICAgZ2ZuOiAw
MDAwNTY1ZiAgbWZuOiAwMDAwNTY1Zg0KDQpzdGVtIHJlYWQtb25seQ0KDQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMzOjI0XSAgIGdmbjogMDAwMDU2NjAgIG1mbjogMDAwMDU2NjANCg0K
WyAgNDYzLjkyMjU0NV0gRShYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjI0XSAgIGdmbjogMDAw
MDU2NjEgIG1mbjogMDAwMDU2NjENCg0KWFQ0LWZzIChkbS0wKTogZXh0NF9kYV93cml0ZXBh
Z2UoWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoyNF0gICBnZm46IDAwMDA1NjYyICBtZm46IDAw
MDA1NjYyDQoNCnM6IGpiZDJfc3RhcnQ6IDYoWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoyNF0g
ICBnZm46IDAwMDA1NjYzICBtZm46IDAwMDA1NjYzDQoNCjE0NCBwYWdlcywgaW5vIDIoWEVO
KSBbMjAxMi0wOC0zMSAyMTozMzoyNF0gICBnZm46IDAwMDA1NjY0ICBtZm46IDAwMDA1NjY0
DQoNCjEwNTQxOTsgZXJyIC0zMA0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MjRdICAgZ2Zu
OiAwMDAwNTY2NSAgbWZuOiAwMDAwNTY2NQ0KDQoNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6
MzM6MjRdICAgZ2ZuOiAwMDAwNTY2NiAgbWZuOiAwMDAwNTY2Ng0KDQpbICA0NjMuOTI1Njkz
XSBFKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MjRdICAgZ2ZuOiAwMDAwNTY2NyAgbWZuOiAw
MDAwNTY2Nw0KDQpYVDQtZnMgZXJyb3IgKGRldmljZSBkbS0wKSBpbiBleChYRU4pIFsyMDEy
LTA4LTMxIDIxOjMzOjI0XSAgIGdmbjogMDAwMDU2NjggIG1mbjogMDAwMDU2NjgNCg0KdDRf
cmVzZXJ2ZV9pbm9kZShYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjI0XSAgIGdmbjogMDAwMDU2
NjkgIG1mbjogMDAwMDU2NjkNCg0KX3dyaXRlOjQ1NDM6IEpvdXJuYWwgaGFzIGFib3J0ZWQo
WEVOKSBbMjAxMi0wOC0zMSAyMTozMzoyNF0gICBnZm46IDAwMDA1NjZhICBtZm46IDAwMDA1
NjZhDQoNCg0KDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjI0XSAgIGdmbjogMDAwMDU2
NmIgIG1mbjogMDAwMDU2NmINCg0KWyAgNDYzLjkyNTY5OF0gRVhUNC1mcyAoZG0tMCk6IHAo
WEVOKSBbMjAxMi0wOC0zMSAyMTozMzoyNF0gICBnZm46IDAwMDA1NjZjICBtZm46IDAwMDA1
NjZjDQoNCnJldmlvdXMgSS9PIGVycm8oWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoyNF0gICBn
Zm46IDAwMDA1NjZkICBtZm46IDAwMDA1NjZkDQoNCnIgdG8gc3VwZXJibG9jayBkZXRlY3Rl
ZA0KDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjI0XSAgIGdmbjogMDAwMDU2NmUgIG1m
bjogMDAwMDU2NmUNCg0KWyAgNDYzLjkyNTczM10gcyhYRU4pIFsyMDEyLTA4LTMxIDIxOjMz
OjI0XSAgIGdmbjogMDAwMDU2NmYgIG1mbjogMDAwMDU2NmYNCg0KZCAwOjA6MDowOiBbc2Rh
XShYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjI0XSAgIGdmbjogMDAwMDU2NzAgIG1mbjogMDAw
MDU2NzANCg0KIFVuaGFuZGxlZCBlcnJvcihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjI0XSAg
IGdmbjogMDAwMDU2NzEgIG1mbjogMDAwMDU2NzENCg0KIGNvZGUNCg0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMzoyNF0gICBnZm46IDAwMDA1NjcyICBtZm46IDAwMDA1NjcyDQoNClsg
IDQ2My45MjU3MzRdIHMoWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoyNF0gICBnZm46IDAwMDA1
NjczICBtZm46IDAwMDA1NjczDQoNCmQgMDowOjA6MDogW3NkYV0oWEVOKSBbMjAxMi0wOC0z
MSAyMTozMzoyNF0gICBnZm46IDAwMDA1Njc0ICBtZm46IDAwMDA1Njc0DQoNCiAgDQoNCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MjRdICAgZ2ZuOiAwMDAwNTY3NSAgbWZuOiAwMDAw
NTY3NQ0KDQpbICA0NjMuOTI1NzM0XSBSZXN1bHQ6IGhvc3RieXRlPShYRU4pIFsyMDEyLTA4
LTMxIDIxOjMzOjI1XSAgIGdmbjogMDAwMDU2NzYgIG1mbjogMDAwMDU2NzYNCg0KRElEX0JB
RF9UQVJHRVQgZChYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjI1XSAgIGdmbjogMDAwMDU2Nzcg
IG1mbjogMDAwMDU2NzcNCg0Kcml2ZXJieXRlPURSSVZFUl9PSw0KDQoNCihYRU4pIFsyMDEy
LTA4LTMxIDIxOjMzOjI1XSAgIGdmbjogMDAwMDU2NzggIG1mbjogMDAwMDU2NzgNCg0KWyAg
NDYzLjkyNTczNV0gcyhYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjI1XSAgIGdmbjogMDAwMDU2
NzkgIG1mbjogMDAwMDU2NzkNCg0KZCAwOjA6MDowOiBbc2RhXSBDREI6IA0KDQoNCihYRU4p
IFsyMDEyLTA4LTMxIDIxOjMzOjI1XSAgIGdmbjogMDAwMDU2N2EgIG1mbjogMDAwMDU2N2EN
Cg0KWyAgNDYzLjkyNTczOV0gVyhYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjI1XSAgIGdmbjog
MDAwMDU2N2IgIG1mbjogMDAwMDU2N2INCg0Kcml0ZSgxMCk6IDJhIDAwIDAxIDJhIDU1IDAx
IDAwIDAoWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoyNV0gICBnZm46IDAwMDA1NjdjICBtZm46
IDAwMDA1NjdjDQoNCjAgMDggMDANCg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoyNV0g
ICBnZm46IDAwMDA1NjdkICBtZm46IDAwMDA1NjdkDQoNClsgIDQ2My45MjU3NDBdIGVuZF9y
ZXF1ZXN0OiBJL08gKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MjVdICAgZ2ZuOiAwMDAwNTY3
ZSAgbWZuOiAwMDAwNTY3ZQ0KDQplcnJvciwgZGV2IHNkYSwgKFhFTikgWzIwMTItMDgtMzEg
MjE6MzM6MjVdICAgZ2ZuOiAwMDAwNTY3ZiAgbWZuOiAwMDAwNTY3Zg0KDQpzZWN0b3IgMTk1
NTE0ODkNCg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoyNV0gICBnZm46IDAwMDA1Njgw
ICBtZm46IDAwMDA1NjgwDQoNClsgIDQ2My45MjU4NDhdIHMoWEVOKSBbMjAxMi0wOC0zMSAy
MTozMzoyNV0gICBnZm46IDAwMDA1NjgxICBtZm46IDAwMDA1NjgxDQoNCmQgMDowOjA6MDog
W3NkYV0gVW5oYW5kbGVkIGVycm9yKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MjVdICAgZ2Zu
OiAwMDAwNTY4MiAgbWZuOiAwMDAwNTY4Mg0KDQogY29kZQ0KDQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMzOjI1XSAgIGdmbjogMDAwMDU2ODMgIG1mbjogMDAwMDU2ODMNCg0KWyAgNDYz
LjkyNTg0OV0gc2QgMDowOjA6MDogW3NkYV0oWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoyNV0g
ICBnZm46IDAwMDA1Njg0ICBtZm46IDAwMDA1Njg0DQoNCiAgDQoNCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzM6MjVdICAgZ2ZuOiAwMDAwNTY4NSAgbWZuOiAwMDAwNTY4NQ0KDQpbICA0
NjMuOTI1ODQ5XSBSZXN1bHQ6IGhvc3RieXRlPShYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjI1
XSAgIGdmbjogMDAwMDU2ODYgIG1mbjogMDAwMDU2ODYNCg0KRElEX0JBRF9UQVJHRVQgZChY
RU4pIFsyMDEyLTA4LTMxIDIxOjMzOjI1XSAgIGdmbjogMDAwMDU2ODcgIG1mbjogMDAwMDU2
ODcNCg0Kcml2ZXJieXRlPURSSVZFUl9PSw0KDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMz
OjI1XSAgIGdmbjogMDAwMDU2ODggIG1mbjogMDAwMDU2ODgNCg0KWyAgNDYzLjkyNTg1MF0g
cyhYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjI1XSAgIGdmbjogMDAwMDU2ODkgIG1mbjogMDAw
MDU2ODkNCg0KZCAwOjA6MDowOiBbc2RhXSBDREI6IA0KDQoNCihYRU4pIFsyMDEyLTA4LTMx
IDIxOjMzOjI1XSAgIGdmbjogMDAwMDU2OGEgIG1mbjogMDAwMDU2OGENCg0KWyAgNDYzLjky
NTg1NF0gVyhYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjI1XSAgIGdmbjogMDAwMDU2OGIgIG1m
bjogMDAwMDU2OGINCg0Kcml0ZSgxMCk6IDJhIDAwIDA1IDdhIDg4IGExIDAwIDAoWEVOKSBb
MjAxMi0wOC0zMSAyMTozMzoyNV0gICBnZm46IDAwMDA1NjhjICBtZm46IDAwMDA1NjhjDQoN
CjAgMDggMDANCg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoyNV0gICBnZm46IDAwMDA1
NjhkICBtZm46IDAwMDA1NjhkDQoNClsgIDQ2My45MjU4NTVdIGVuZF9yZXF1ZXN0OiBJL08g
KFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MjVdICAgZ2ZuOiAwMDAwNTY4ZSAgbWZuOiAwMDAw
NTY4ZQ0KDQplcnJvciwgZGV2IHNkYSwgKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MjVdICAg
Z2ZuOiAwMDAwNTY4ZiAgbWZuOiAwMDAwNTY4Zg0KDQpzZWN0b3IgOTE5MTY0NDkNCg0KDQoo
WEVOKSBbMjAxMi0wOC0zMSAyMTozMzoyNV0gICBnZm46IDAwMDA1NjkwICBtZm46IDAwMDA1
NjkwDQoNClsgIDQ2My45MjU4NjZdIHMoWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoyNV0gICBn
Zm46IDAwMDA1NjkxICBtZm46IDAwMDA1NjkxDQoNCmQgMDowOjA6MDogW3NkYV0gVW5oYW5k
bGVkIGVycm9yKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MjVdICAgZ2ZuOiAwMDAwNTY5MiAg
bWZuOiAwMDAwNTY5Mg0KDQogY29kZQ0KDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjI1
XSAgIGdmbjogMDAwMDU2OTMgIG1mbjogMDAwMDU2OTMNCg0KWyAgNDYzLjkyNTg2N10gc2Qg
MDowOjA6MDogW3NkYV0oWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoyNV0gICBnZm46IDAwMDA1
Njk0ICBtZm46IDAwMDA1Njk0DQoNCiAgDQoNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6
MjVdICAgZ2ZuOiAwMDAwNTY5NSAgbWZuOiAwMDAwNTY5NQ0KDQpbICA0NjMuOTI1ODY4XSBS
ZXN1bHQ6IGhvc3RieXRlPShYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjI1XSAgIGdmbjogMDAw
MDU2OTYgIG1mbjogMDAwMDU2OTYNCg0KRElEX0JBRF9UQVJHRVQgZChYRU4pIFsyMDEyLTA4
LTMxIDIxOjMzOjI1XSAgIGdmbjogMDAwMDU2OTcgIG1mbjogMDAwMDU2OTcNCg0Kcml2ZXJi
eXRlPURSSVZFUl9PSw0KDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjI1XSAgIGdmbjog
MDAwMDU2OTggIG1mbjogMDAwMDU2OTgNCg0KWyAgNDYzLjkyNTg2OV0gcyhYRU4pIFsyMDEy
LTA4LTMxIDIxOjMzOjI1XSAgIGdmbjogMDAwMDU2OTkgIG1mbjogMDAwMDU2OTkNCg0KZCAw
OjA6MDowOiBbc2RhXSBDREI6IA0KDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjI1XSAg
IGdmbjogMDAwMDU2OWEgIG1mbjogMDAwMDU2OWENCg0KWyAgNDYzLjkyNTg3Ml0gVyhYRU4p
IFsyMDEyLTA4LTMxIDIxOjMzOjI1XSAgIGdmbjogMDAwMDU2OWIgIG1mbjogMDAwMDU2OWIN
Cg0Kcml0ZSgxMCk6IDJhIDAwIDA1IDdhIDk5IDYxIDAwIDAoWEVOKSBbMjAxMi0wOC0zMSAy
MTozMzoyNV0gICBnZm46IDAwMDA1NjljICBtZm46IDAwMDA1NjljDQoNCjAgMDggMDANCg0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoyNV0gICBnZm46IDAwMDA1NjlkICBtZm46IDAw
MDA1NjlkDQoNClsgIDQ2My45MjU4NzJdIGVuZF9yZXF1ZXN0OiBJL08gKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzM6MjVdICAgZ2ZuOiAwMDAwNTY5ZSAgbWZuOiAwMDAwNTY5ZQ0KDQplcnJv
ciwgZGV2IHNkYSwgKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MjVdICAgZ2ZuOiAwMDAwNTY5
ZiAgbWZuOiAwMDAwNTY5Zg0KDQpzZWN0b3IgOTE5MjA3MzcNCg0KDQooWEVOKSBbMjAxMi0w
OC0zMSAyMTozMzoyNV0gICBnZm46IDAwMDA1NmEwICBtZm46IDAwMDA1NmEwDQoNClsgIDQ2
My45MjU4NzldIHMoWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoyNV0gICBnZm46IDAwMDA1NmEx
ICBtZm46IDAwMDA1NmExDQoNCmQgMDowOjA6MDogW3NkYV0gVW5oYW5kbGVkIGVycm9yKFhF
TikgWzIwMTItMDgtMzEgMjE6MzM6MjVdICAgZ2ZuOiAwMDAwNTZhMiAgbWZuOiAwMDAwNTZh
Mg0KDQogY29kZQ0KDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjI1XSAgIGdmbjogMDAw
MDU2YTMgIG1mbjogMDAwMDU2YTMNCg0KWyAgNDYzLjkyNTg3OV0gc2QgMDowOjA6MDogW3Nk
YV0oWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoyNV0gICBnZm46IDAwMDA1NmE0ICBtZm46IDAw
MDA1NmE0DQoNCiAgDQoNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MjZdICAgZ2ZuOiAw
MDAwNTZhNSAgbWZuOiAwMDAwNTZhNQ0KDQpbICA0NjMuOTI1ODgwXSBSZXN1bHQ6IGhvc3Ri
eXRlPShYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjI2XSAgIGdmbjogMDAwMDU2YTYgIG1mbjog
MDAwMDU2YTYNCg0KRElEX0JBRF9UQVJHRVQgZChYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjI2
XSAgIGdmbjogMDAwMDU2YTcgIG1mbjogMDAwMDU2YTcNCg0Kcml2ZXJieXRlPURSSVZFUl9P
Sw0KDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjI2XSAgIGdmbjogMDAwMDU2YTggIG1m
bjogMDAwMDU2YTgNCg0KWyAgNDYzLjkyNTg4MV0gcyhYRU4pIFsyMDEyLTA4LTMxIDIxOjMz
OjI2XSAgIGdmbjogMDAwMDU2YTkgIG1mbjogMDAwMDU2YTkNCg0KZCAwOjA6MDowOiBbc2Rh
XSBDREI6IA0KDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjI2XSAgIGdmbjogMDAwMDU2
YWEgIG1mbjogMDAwMDU2YWENCg0KWyAgNDYzLjkyNTg4NF0gVyhYRU4pIFsyMDEyLTA4LTMx
IDIxOjMzOjI2XSAgIGdmbjogMDAwMDU2YWIgIG1mbjogMDAwMDU2YWINCg0Kcml0ZSgxMCk6
IDJhIDAwIDA1IGM2IGFmIDcxIDAwIDAoWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoyNl0gICBn
Zm46IDAwMDA1NmFjICBtZm46IDAwMDA1NmFjDQoNCjAgMDggMDANCg0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMzoyNl0gICBnZm46IDAwMDA1NmFkICBtZm46IDAwMDA1NmFkDQoNClsg
IDQ2My45MjU4ODVdIGVuZF9yZXF1ZXN0OiBJL08gKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6
MjZdICAgZ2ZuOiAwMDAwNTZhZSAgbWZuOiAwMDAwNTZhZQ0KDQplcnJvciwgZGV2IHNkYSwg
KFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MjZdICAgZ2ZuOiAwMDAwNTZhZiAgbWZuOiAwMDAw
NTZhZg0KDQpzZWN0b3IgOTY5MDcxMjENCg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoy
Nl0gICBnZm46IDAwMDA1NmIwICBtZm46IDAwMDA1NmIwDQoNClsgIDQ2My45MjU4OTFdIHMo
WEVOKSBbMjAxMi0wOC0zMSAyMTozMzoyNl0gICBnZm46IDAwMDA1NmIxICBtZm46IDAwMDA1
NmIxDQoNCmQgMDowOjA6MDogW3NkYV0gVW5oYW5kbGVkIGVycm9yKFhFTikgWzIwMTItMDgt
MzEgMjE6MzM6MjZdICAgZ2ZuOiAwMDAwNTZiMiAgbWZuOiAwMDAwNTZiMg0KDQogY29kZQ0K
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjI2XSAgIGdmbjogMDAwMDU2YjMgIG1mbjog
MDAwMDU2YjMNCg0KWyAgNDYzLjkyNTg5Ml0gc2QgMDowOjA6MDogW3NkYV0oWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMzoyNl0gICBnZm46IDAwMDA1NmI0ICBtZm46IDAwMDA1NmI0DQoNCiAg
DQoNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MjZdICAgZ2ZuOiAwMDAwNTZiNSAgbWZu
OiAwMDAwNTZiNQ0KDQpbICA0NjMuOTI1ODkyXSBSZXN1bHQ6IGhvc3RieXRlPShYRU4pIFsy
MDEyLTA4LTMxIDIxOjMzOjI2XSAgIGdmbjogMDAwMDU2YjYgIG1mbjogMDAwMDU2YjYNCg0K
RElEX0JBRF9UQVJHRVQgZChYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjI2XSAgIGdmbjogMDAw
MDU2YjcgIG1mbjogMDAwMDU2YjcNCg0Kcml2ZXJieXRlPURSSVZFUl9PSw0KDQoNCihYRU4p
IFsyMDEyLTA4LTMxIDIxOjMzOjI2XSAgIGdmbjogMDAwMDU2YjggIG1mbjogMDAwMDU2YjgN
Cg0KWyAgNDYzLjkyNTg5M10gcyhYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjI2XSAgIGdmbjog
MDAwMDU2YjkgIG1mbjogMDAwMDU2YjkNCg0KZCAwOjA6MDowOiBbc2RhXSBDREI6IA0KDQoN
CihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjI2XSAgIGdmbjogMDAwMDU2YmEgIG1mbjogMDAw
MDU2YmENCg0KWyAgNDYzLjkyNTg5Nl0gVyhYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjI2XSAg
IGdmbjogMDAwMDU2YmIgIG1mbjogMDAwMDU2YmINCg0Kcml0ZSgxMCk6IDJhIDAwIDAyIDRl
IDk1IDExIDAwIDAoWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoyNl0gICBnZm46IDAwMDA1NmJj
ICBtZm46IDAwMDA1NmJjDQoNCjAgMDggMDANCg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
MzoyNl0gICBnZm46IDAwMDA1NmJkICBtZm46IDAwMDA1NmJkDQoNClsgIDQ2My45MjU4OTdd
IGUoWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoyNl0gICBnZm46IDAwMDA1NmJlICBtZm46IDAw
MDA1NmJlDQoNCm5kX3JlcXVlc3Q6IEkvTyAoWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoyNl0g
ICBnZm46IDAwMDA1NmJmICBtZm46IDAwMDA1NmJmDQoNCmVycm9yLCBkZXYgc2RhLCAoWEVO
KSBbMjAxMi0wOC0zMSAyMTozMzoyNl0gICBnZm46IDAwMDA1NmMwICBtZm46IDAwMDA1NmMw
DQoNCnNlY3RvciAzODcwNDQwMQ0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MjZdICAgZ2Zu
OiAwMDAwNTZjMSAgbWZuOiAwMDAwNTZjMQ0KDQoNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6
MzM6MjZdICAgZ2ZuOiAwMDAwNTZjMiAgbWZuOiAwMDAwNTZjMg0KDQpbICA0NjMuOTI1OTA3
XSBKKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MjZdICAgZ2ZuOiAwMDAwNTZjMyAgbWZuOiAw
MDAwNTZjMw0KDQpCRDI6IERldGVjdGVkIElPKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MjZd
ICAgZ2ZuOiAwMDAwNTZjNCAgbWZuOiAwMDAwNTZjNA0KDQogZXJyb3JzIHdoaWxlIGZsKFhF
TikgWzIwMTItMDgtMzEgMjE6MzM6MjZdICAgZ2ZuOiAwMDAwNTZjNSAgbWZuOiAwMDAwNTZj
NQ0KDQp1c2hpbmcgZmlsZSBkYXRhIG9uIGRtLTAtOA0KDQoNCihYRU4pIFsyMDEyLTA4LTMx
IDIxOjMzOjI2XSAgIGdmbjogMDAwMDU2YzYgIG1mbjogMDAwMDU2YzYNCg0KWyAgNDcyLjY4
MjMzOV0gcyhYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjI2XSAgIGdmbjogMDAwMDU2YzcgIG1m
bjogMDAwMDU2YzcNCg0KZCAwOjA6MDowOiBbc2RhXSAgDQoNCg0KKFhFTikgWzIwMTItMDgt
MzEgMjE6MzM6MjZdICAgZ2ZuOiAwMDAwNTZjOCAgbWZuOiAwMDAwNTZjOA0KDQpbICA0NzIu
NzIzOTE5XSBSKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MjZdICAgZ2ZuOiAwMDAwNTZjOSAg
bWZuOiAwMDAwNTZjOQ0KDQplc3VsdDogaG9zdGJ5dGU9RElEX0JBRF9UQVJHRVQgZHJpdmVy
Ynl0ZT1EUklWRVIoWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoyNl0gICBnZm46IDAwMDA1NmNh
ICBtZm46IDAwMDA1NmNhDQoNCl9PSw0KDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjI2
XSAgIGdmbjogMDAwMDU2Y2IgIG1mbjogMDAwMDU2Y2INCg0KWyAgNDcyLjc4NjM2MV0gc2Qg
MDowOjA6MDogW3NkYV0oWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoyNl0gICBnZm46IDAwMDA1
NmNjICBtZm46IDAwMDA1NmNjDQoNCiBDREI6IA0KDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMzOjI2XSAgIGdmbjogMDAwMDU2Y2QgIG1mbjogMDAwMDU2Y2QNCg0KWyAgNDcyLjgyNzk2
MF0gV3JpdGUoMTApKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MjZdICAgZ2ZuOiAwMDAwNTZj
ZSAgbWZuOiAwMDAwNTZjZQ0KDQo6KFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MjZdICAgZ2Zu
OiAwMDAwNTZjZiAgbWZuOiAwMDAwNTZjZg0KDQogMmEgMDAoWEVOKSBbMjAxMi0wOC0zMSAy
MTozMzoyNl0gICBnZm46IDAwMDA1NmQwICBtZm46IDAwMDA1NmQwDQoNCiBiZihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMzOjI2XSAgIGdmbjogMDAwMDU2ZDEgIG1mbjogMDAwMDU2ZDENCg0K
IDA5KFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MjZdICAgZ2ZuOiAwMDAwNTZkMiAgbWZuOiAw
MDAwNTZkMg0KDQogMzcoWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoyNl0gICBnZm46IDAwMDA1
NmQzICBtZm46IDAwMDA1NmQzDQoNCiAxMShYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjI2XSAg
IGdmbjogMDAwMDU2ZDQgIG1mbjogMDAwMDU2ZDQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6
MzM6MjZdICAgZ2ZuOiAwMDAwNTZkNSAgbWZuOiAwMDAwNTZkNQ0KDQogMDAoWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMzoyNl0gICBnZm46IDAwMDA1NmQ2ICBtZm46IDAwMDA1NmQ2DQoNCiAw
MChYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjI2XSAgIGdmbjogMDAwMDU2ZDcgIG1mbjogMDAw
MDU2ZDcNCg0KIGIwKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MjddICAgZ2ZuOiAwMDAwNTZk
OCAgbWZuOiAwMDAwNTZkOA0KDQogMDAoWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoyN10gICBn
Zm46IDAwMDA1NmQ5ICBtZm46IDAwMDA1NmQ5DQoNCg0KDQoNCihYRU4pIFsyMDEyLTA4LTMx
IDIxOjMzOjI3XSAgIGdmbjogMDAwMDU2ZGEgIG1mbjogMDAwMDU2ZGENCg0KWyAgNDczLjA0
ODQzNF0gZShYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjI3XSAgIGdmbjogMDAwMDU2ZGIgIG1m
bjogMDAwMDU2ZGINCg0KbmRfcmVxdWVzdDogSS9PIChYRU4pIFsyMDEyLTA4LTMxIDIxOjMz
OjI3XSAgIGdmbjogMDAwMDU2ZGMgIG1mbjogMDAwMDU2ZGMNCg0KZXJyb3IsIGRldiBzZGEs
IChYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjI3XSAgIGdmbjogMDAwMDU2ZGQgIG1mbjogMDAw
MDU2ZGQNCg0Kc2VjdG9yIDMyMDUwNTIxNzcNCg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
MzoyN10gICBnZm46IDAwMDA1NmRlICBtZm46IDAwMDA1NmRlDQoNClsgIDQ3My4xMjc1NDZd
IHMoWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoyN10gICBnZm46IDAwMDA1NmRmICBtZm46IDAw
MDA1NmRmDQoNCmQgMDowOjA6MDogW3NkYV0gVW5oYW5kbGVkIGVycm9yKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzM6MjddICAgZ2ZuOiAwMDAwNTZlMCAgbWZuOiAwMDAwNTZlMA0KDQogY29k
ZQ0KDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjI3XSAgIGdmbjogMDAwMDU2ZTEgIG1m
bjogMDAwMDU2ZTENCg0KWyAgNDczLjE4OTg0MF0gc2QgMDowOjA6MDogW3NkYV0oWEVOKSBb
MjAxMi0wOC0zMSAyMTozMzoyN10gICBnZm46IDAwMDA1NmUyICBtZm46IDAwMDA1NmUyDQoN
CiAgDQoNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MjddICAgZ2ZuOiAwMDAwNTZlMyAg
bWZuOiAwMDAwNTZlMw0KDQpbICA0NzMuMjMxNDMzXSBSZXN1bHQ6IGhvc3RieXRlPShYRU4p
IFsyMDEyLTA4LTMxIDIxOjMzOjI3XSAgIGdmbjogMDAwMDU2ZTQgIG1mbjogMDAwMDU2ZTQN
Cg0KRElEX0JBRF9UQVJHRVQgZChYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjI3XSAgIGdmbjog
MDAwMDU2ZTUgIG1mbjogMDAwMDU2ZTUNCg0Kcml2ZXJieXRlPURSSVZFUl9PSw0KDQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMzOjI3XSAgIGdmbjogMDAwMDU2ZTYgIG1mbjogMDAwMDU2
ZTYNCg0KWyAgNDczLjI5Mzg1NV0gcyhYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjI3XSAgIGdm
bjogMDAwMDU2ZTcgIG1mbjogMDAwMDU2ZTcNCg0KZCAwOjA6MDowOiBbc2RhXSBDREI6IA0K
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjI3XSAgIGdmbjogMDAwMDU2ZTggIG1mbjog
MDAwMDU2ZTgNCg0KWyAgNDczLjMzNTQ0OF0gUihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjI3
XSAgIGdmbjogMDAwMDU2ZTkgIG1mbjogMDAwMDU2ZTkNCg0KZWFkKDEwKShYRU4pIFsyMDEy
LTA4LTMxIDIxOjMzOjI3XSAgIGdmbjogMDAwMDU2ZWEgIG1mbjogMDAwMDU2ZWENCg0KOihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMzOjI3XSAgIGdmbjogMDAwMDU2ZWIgIG1mbjogMDAwMDU2
ZWINCg0KIDI4IDAwKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MjddICAgZ2ZuOiAwMDAwNTZl
YyAgbWZuOiAwMDAwNTZlYw0KDQogYmUoWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoyN10gICBn
Zm46IDAwMDA1NmVkICBtZm46IDAwMDA1NmVkDQoNCiBkZihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMzOjI3XSAgIGdmbjogMDAwMDU2ZWUgIG1mbjogMDAwMDU2ZWUNCg0KIDhiKFhFTikgWzIw
MTItMDgtMzEgMjE6MzM6MjddICAgZ2ZuOiAwMDAwNTZlZiAgbWZuOiAwMDAwNTZlZg0KDQog
NjEoWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoyN10gICBnZm46IDAwMDA1NmYwICBtZm46IDAw
MDA1NmYwDQoNCiAwMChYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjI3XSAgIGdmbjogMDAwMDU2
ZjEgIG1mbjogMDAwMDU2ZjENCg0KIDAyKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MjddICAg
Z2ZuOiAwMDAwNTZmMiAgbWZuOiAwMDAwNTZmMg0KDQogMDAoWEVOKSBbMjAxMi0wOC0zMSAy
MTozMzoyN10gICBnZm46IDAwMDA1NmYzICBtZm46IDAwMDA1NmYzDQoNCiAwMChYRU4pIFsy
MDEyLTA4LTMxIDIxOjMzOjI3XSAgIGdmbjogMDAwMDU2ZjQgIG1mbjogMDAwMDU2ZjQNCg0K
DQoNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MjddICAgZ2ZuOiAwMDAwNTZmNSAgbWZu
OiAwMDAwNTZmNQ0KDQpbICA0NzMuNTU1OTAxXSBlbmRfcmVxdWVzdDogSS9PIChYRU4pIFsy
MDEyLTA4LTMxIDIxOjMzOjI3XSAgIGdmbjogMDAwMDU2ZjYgIG1mbjogMDAwMDU2ZjYNCg0K
ZXJyb3IsIGRldiBzZGEsIChYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjI3XSAgIGdmbjogMDAw
MDU2ZjcgIG1mbjogMDAwMDU2ZjcNCg0Kc2VjdG9yIDMyMDIzMjEyNDkNCg0KDQooWEVOKSBb
MjAxMi0wOC0zMSAyMTozMzoyN10gICBnZm46IDAwMDA1NmY4ICBtZm46IDAwMDA1NmY4DQoN
CihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjI3XSAgIGdmbjogMDAwMDU2ZjkgIG1mbjogMDAw
MDU2ZjkNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MjddICAgZ2ZuOiAwMDAwNTZmYSAg
bWZuOiAwMDAwNTZmYQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoyN10gICBnZm46IDAw
MDA1NmZiICBtZm46IDAwMDA1NmZiDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjI3XSAg
IGdmbjogMDAwMDU2ZmMgIG1mbjogMDAwMDU2ZmMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6
MzM6MjddICAgZ2ZuOiAwMDAwNTZmZCAgbWZuOiAwMDAwNTZmZA0KDQooWEVOKSBbMjAxMi0w
OC0zMSAyMTozMzoyN10gICBnZm46IDAwMDA1NmZlICBtZm46IDAwMDA1NmZlDQoNCihYRU4p
IFsyMDEyLTA4LTMxIDIxOjMzOjI3XSAgIGdmbjogMDAwMDU2ZmYgIG1mbjogMDAwMDU2ZmYN
Cg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MjddICAgZ2ZuOiAwMDAwNTcwMCAgbWZuOiAw
MDAwNTcwMA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoyN10gICBnZm46IDAwMDA1NzAx
ICBtZm46IDAwMDA1NzAxDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjI3XSAgIGdmbjog
MDAwMDU3MDIgIG1mbjogMDAwMDU3MDINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6Mjdd
ICAgZ2ZuOiAwMDAwNTcwMyAgbWZuOiAwMDAwNTcwMw0KDQooWEVOKSBbMjAxMi0wOC0zMSAy
MTozMzoyN10gICBnZm46IDAwMDA1NzA0ICBtZm46IDAwMDA1NzA0DQoNCihYRU4pIFsyMDEy
LTA4LTMxIDIxOjMzOjI3XSAgIGdmbjogMDAwMDU3MDUgIG1mbjogMDAwMDU3MDUNCg0KKFhF
TikgWzIwMTItMDgtMzEgMjE6MzM6MjddICAgZ2ZuOiAwMDAwNTcwNiAgbWZuOiAwMDAwNTcw
Ng0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoyN10gICBnZm46IDAwMDA1NzA3ICBtZm46
IDAwMDA1NzA3DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjI3XSAgIGdmbjogMDAwMDU3
MDggIG1mbjogMDAwMDU3MDgNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MjddICAgZ2Zu
OiAwMDAwNTcwOSAgbWZuOiAwMDAwNTcwOQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoy
N10gICBnZm46IDAwMDA1NzBhICBtZm46IDAwMDA1NzBhDQoNCihYRU4pIFsyMDEyLTA4LTMx
IDIxOjMzOjI3XSAgIGdmbjogMDAwMDU3MGIgIG1mbjogMDAwMDU3MGINCg0KKFhFTikgWzIw
MTItMDgtMzEgMjE6MzM6MjddICAgZ2ZuOiAwMDAwNTcwYyAgbWZuOiAwMDAwNTcwYw0KDQoo
WEVOKSBbMjAxMi0wOC0zMSAyMTozMzoyN10gICBnZm46IDAwMDA1NzBkICBtZm46IDAwMDA1
NzBkDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjI3XSAgIGdmbjogMDAwMDU3MGUgIG1m
bjogMDAwMDU3MGUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MjddICAgZ2ZuOiAwMDAw
NTcwZiAgbWZuOiAwMDAwNTcwZg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoyN10gICBn
Zm46IDAwMDA1NzEwICBtZm46IDAwMDA1NzEwDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMz
OjI4XSAgIGdmbjogMDAwMDU3MTEgIG1mbjogMDAwMDU3MTENCg0KKFhFTikgWzIwMTItMDgt
MzEgMjE6MzM6MjhdICAgZ2ZuOiAwMDAwNTcxMiAgbWZuOiAwMDAwNTcxMg0KDQooWEVOKSBb
MjAxMi0wOC0zMSAyMTozMzoyOF0gICBnZm46IDAwMDA1NzEzICBtZm46IDAwMDA1NzEzDQoN
CihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjI4XSAgIGdmbjogMDAwMDU3MTQgIG1mbjogMDAw
MDU3MTQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MjhdICAgZ2ZuOiAwMDAwNTcxNSAg
bWZuOiAwMDAwNTcxNQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoyOF0gICBnZm46IDAw
MDA1NzE2ICBtZm46IDAwMDA1NzE2DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjI4XSAg
IGdmbjogMDAwMDU3MTcgIG1mbjogMDAwMDU3MTcNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6
MzM6MjhdICAgZ2ZuOiAwMDAwNTcxOCAgbWZuOiAwMDAwNTcxOA0KDQooWEVOKSBbMjAxMi0w
OC0zMSAyMTozMzoyOF0gICBnZm46IDAwMDA1NzE5ICBtZm46IDAwMDA1NzE5DQoNCihYRU4p
IFsyMDEyLTA4LTMxIDIxOjMzOjI4XSAgIGdmbjogMDAwMDU3MWEgIG1mbjogMDAwMDU3MWEN
Cg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MjhdICAgZ2ZuOiAwMDAwNTcxYiAgbWZuOiAw
MDAwNTcxYg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoyOF0gICBnZm46IDAwMDA1NzFj
ICBtZm46IDAwMDA1NzFjDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjI4XSAgIGdmbjog
MDAwMDU3MWQgIG1mbjogMDAwMDU3MWQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6Mjhd
ICAgZ2ZuOiAwMDAwNTcxZSAgbWZuOiAwMDAwNTcxZQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAy
MTozMzoyOF0gICBnZm46IDAwMDA1NzFmICBtZm46IDAwMDA1NzFmDQoNCihYRU4pIFsyMDEy
LTA4LTMxIDIxOjMzOjI4XSAgIGdmbjogMDAwMDU3MjAgIG1mbjogMDAwMDU3MjANCg0KKFhF
TikgWzIwMTItMDgtMzEgMjE6MzM6MjhdICAgZ2ZuOiAwMDAwNTcyMSAgbWZuOiAwMDAwNTcy
MQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoyOF0gICBnZm46IDAwMDA1NzIyICBtZm46
IDAwMDA1NzIyDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjI4XSAgIGdmbjogMDAwMDU3
MjMgIG1mbjogMDAwMDU3MjMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MjhdICAgZ2Zu
OiAwMDAwNTcyNCAgbWZuOiAwMDAwNTcyNA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoy
OF0gICBnZm46IDAwMDA1NzI1ICBtZm46IDAwMDA1NzI1DQoNCihYRU4pIFsyMDEyLTA4LTMx
IDIxOjMzOjI4XSAgIGdmbjogMDAwMDU3MjYgIG1mbjogMDAwMDU3MjYNCg0KKFhFTikgWzIw
MTItMDgtMzEgMjE6MzM6MjhdICAgZ2ZuOiAwMDAwNTcyNyAgbWZuOiAwMDAwNTcyNw0KDQoo
WEVOKSBbMjAxMi0wOC0zMSAyMTozMzoyOF0gICBnZm46IDAwMDA1NzI4ICBtZm46IDAwMDA1
NzI4DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjI4XSAgIGdmbjogMDAwMDU3MjkgIG1m
bjogMDAwMDU3MjkNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MjhdICAgZ2ZuOiAwMDAw
NTcyYSAgbWZuOiAwMDAwNTcyYQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoyOF0gICBn
Zm46IDAwMDA1NzJiICBtZm46IDAwMDA1NzJiDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMz
OjI4XSAgIGdmbjogMDAwMDU3MmMgIG1mbjogMDAwMDU3MmMNCg0KKFhFTikgWzIwMTItMDgt
MzEgMjE6MzM6MjhdICAgZ2ZuOiAwMDAwNTcyZCAgbWZuOiAwMDAwNTcyZA0KDQooWEVOKSBb
MjAxMi0wOC0zMSAyMTozMzoyOF0gICBnZm46IDAwMDA1NzJlICBtZm46IDAwMDA1NzJlDQoN
CihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjI4XSAgIGdmbjogMDAwMDU3MmYgIG1mbjogMDAw
MDU3MmYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MjhdICAgZ2ZuOiAwMDAwNTczMCAg
bWZuOiAwMDAwNTczMA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoyOF0gICBnZm46IDAw
MDA1NzMxICBtZm46IDAwMDA1NzMxDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjI4XSAg
IGdmbjogMDAwMDU3MzIgIG1mbjogMDAwMDU3MzINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6
MzM6MjhdICAgZ2ZuOiAwMDAwNTczMyAgbWZuOiAwMDAwNTczMw0KDQooWEVOKSBbMjAxMi0w
OC0zMSAyMTozMzoyOF0gICBnZm46IDAwMDA1NzM0ICBtZm46IDAwMDA1NzM0DQoNCihYRU4p
IFsyMDEyLTA4LTMxIDIxOjMzOjI4XSAgIGdmbjogMDAwMDU3MzUgIG1mbjogMDAwMDU3MzUN
Cg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MjhdICAgZ2ZuOiAwMDAwNTczNiAgbWZuOiAw
MDAwNTczNg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoyOF0gICBnZm46IDAwMDA1NzM3
ICBtZm46IDAwMDA1NzM3DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjI4XSAgIGdmbjog
MDAwMDU3MzggIG1mbjogMDAwMDU3MzgNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6Mjhd
ICAgZ2ZuOiAwMDAwNTczOSAgbWZuOiAwMDAwNTczOQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAy
MTozMzoyOF0gICBnZm46IDAwMDA1NzNhICBtZm46IDAwMDA1NzNhDQoNCihYRU4pIFsyMDEy
LTA4LTMxIDIxOjMzOjI4XSAgIGdmbjogMDAwMDU3M2IgIG1mbjogMDAwMDU3M2INCg0KKFhF
TikgWzIwMTItMDgtMzEgMjE6MzM6MjhdICAgZ2ZuOiAwMDAwNTczYyAgbWZuOiAwMDAwNTcz
Yw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoyOF0gICBnZm46IDAwMDA1NzNkICBtZm46
IDAwMDA1NzNkDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjI4XSAgIGdmbjogMDAwMDU3
M2UgIG1mbjogMDAwMDU3M2UNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MjhdICAgZ2Zu
OiAwMDAwNTczZiAgbWZuOiAwMDAwNTczZg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoy
OF0gICBnZm46IDAwMDA1NzQwICBtZm46IDAwMDA1NzQwDQoNCihYRU4pIFsyMDEyLTA4LTMx
IDIxOjMzOjI4XSAgIGdmbjogMDAwMDU3NDEgIG1mbjogMDAwMDU3NDENCg0KKFhFTikgWzIw
MTItMDgtMzEgMjE6MzM6MjhdICAgZ2ZuOiAwMDAwNTc0MiAgbWZuOiAwMDAwNTc0Mg0KDQoo
WEVOKSBbMjAxMi0wOC0zMSAyMTozMzoyOF0gICBnZm46IDAwMDA1NzQzICBtZm46IDAwMDA1
NzQzDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjI4XSAgIGdmbjogMDAwMDU3NDQgIG1m
bjogMDAwMDU3NDQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MjhdICAgZ2ZuOiAwMDAw
NTc0NSAgbWZuOiAwMDAwNTc0NQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoyOF0gICBn
Zm46IDAwMDA1NzQ2ICBtZm46IDAwMDA1NzQ2DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMz
OjI4XSAgIGdmbjogMDAwMDU3NDcgIG1mbjogMDAwMDU3NDcNCg0KKFhFTikgWzIwMTItMDgt
MzEgMjE6MzM6MjhdICAgZ2ZuOiAwMDAwNTc0OCAgbWZuOiAwMDAwNTc0OA0KDQooWEVOKSBb
MjAxMi0wOC0zMSAyMTozMzoyOF0gICBnZm46IDAwMDA1NzQ5ICBtZm46IDAwMDA1NzQ5DQoN
CihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjI4XSAgIGdmbjogMDAwMDU3NGEgIG1mbjogMDAw
MDU3NGENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MjhdICAgZ2ZuOiAwMDAwNTc0YiAg
bWZuOiAwMDAwNTc0Yg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoyOF0gICBnZm46IDAw
MDA1NzRjICBtZm46IDAwMDA1NzRjDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjI4XSAg
IGdmbjogMDAwMDU3NGQgIG1mbjogMDAwMDU3NGQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6
MzM6MjhdICAgZ2ZuOiAwMDAwNTc0ZSAgbWZuOiAwMDAwNTc0ZQ0KDQooWEVOKSBbMjAxMi0w
OC0zMSAyMTozMzoyOF0gICBnZm46IDAwMDA1NzRmICBtZm46IDAwMDA1NzRmDQoNCihYRU4p
IFsyMDEyLTA4LTMxIDIxOjMzOjI4XSAgIGdmbjogMDAwMDU3NTAgIG1mbjogMDAwMDU3NTAN
Cg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MjldICAgZ2ZuOiAwMDAwNTc1MSAgbWZuOiAw
MDAwNTc1MQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoyOV0gICBnZm46IDAwMDA1NzUy
ICBtZm46IDAwMDA1NzUyDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjI5XSAgIGdmbjog
MDAwMDU3NTMgIG1mbjogMDAwMDU3NTMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6Mjld
ICAgZ2ZuOiAwMDAwNTc1NCAgbWZuOiAwMDAwNTc1NA0KDQooWEVOKSBbMjAxMi0wOC0zMSAy
MTozMzoyOV0gICBnZm46IDAwMDA1NzU1ICBtZm46IDAwMDA1NzU1DQoNCihYRU4pIFsyMDEy
LTA4LTMxIDIxOjMzOjI5XSAgIGdmbjogMDAwMDU3NTYgIG1mbjogMDAwMDU3NTYNCg0KKFhF
TikgWzIwMTItMDgtMzEgMjE6MzM6MjldICAgZ2ZuOiAwMDAwNTc1NyAgbWZuOiAwMDAwNTc1
Nw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoyOV0gICBnZm46IDAwMDA1NzU4ICBtZm46
IDAwMDA1NzU4DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjI5XSAgIGdmbjogMDAwMDU3
NTkgIG1mbjogMDAwMDU3NTkNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MjldICAgZ2Zu
OiAwMDAwNTc1YSAgbWZuOiAwMDAwNTc1YQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoy
OV0gICBnZm46IDAwMDA1NzViICBtZm46IDAwMDA1NzViDQoNCihYRU4pIFsyMDEyLTA4LTMx
IDIxOjMzOjI5XSAgIGdmbjogMDAwMDU3NWMgIG1mbjogMDAwMDU3NWMNCg0KKFhFTikgWzIw
MTItMDgtMzEgMjE6MzM6MjldICAgZ2ZuOiAwMDAwNTc1ZCAgbWZuOiAwMDAwNTc1ZA0KDQoo
WEVOKSBbMjAxMi0wOC0zMSAyMTozMzoyOV0gICBnZm46IDAwMDA1NzVlICBtZm46IDAwMDA1
NzVlDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjI5XSAgIGdmbjogMDAwMDU3NWYgIG1m
bjogMDAwMDU3NWYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MjldICAgZ2ZuOiAwMDAw
NTc2MCAgbWZuOiAwMDAwNTc2MA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoyOV0gICBn
Zm46IDAwMDA1NzYxICBtZm46IDAwMDA1NzYxDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMz
OjI5XSAgIGdmbjogMDAwMDU3NjIgIG1mbjogMDAwMDU3NjINCg0KKFhFTikgWzIwMTItMDgt
MzEgMjE6MzM6MjldICAgZ2ZuOiAwMDAwNTc2MyAgbWZuOiAwMDAwNTc2Mw0KDQooWEVOKSBb
MjAxMi0wOC0zMSAyMTozMzoyOV0gICBnZm46IDAwMDA1NzY0ICBtZm46IDAwMDA1NzY0DQoN
CihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjI5XSAgIGdmbjogMDAwMDU3NjUgIG1mbjogMDAw
MDU3NjUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MjldICAgZ2ZuOiAwMDAwNTc2NiAg
bWZuOiAwMDAwNTc2Ng0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoyOV0gICBnZm46IDAw
MDA1NzY3ICBtZm46IDAwMDA1NzY3DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjI5XSAg
IGdmbjogMDAwMDU3NjggIG1mbjogMDAwMDU3NjgNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6
MzM6MjldICAgZ2ZuOiAwMDAwNTc2OSAgbWZuOiAwMDAwNTc2OQ0KDQooWEVOKSBbMjAxMi0w
OC0zMSAyMTozMzoyOV0gICBnZm46IDAwMDA1NzZhICBtZm46IDAwMDA1NzZhDQoNCihYRU4p
IFsyMDEyLTA4LTMxIDIxOjMzOjI5XSAgIGdmbjogMDAwMDU3NmIgIG1mbjogMDAwMDU3NmIN
Cg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MjldICAgZ2ZuOiAwMDAwNTc2YyAgbWZuOiAw
MDAwNTc2Yw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoyOV0gICBnZm46IDAwMDA1NzZk
ICBtZm46IDAwMDA1NzZkDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjI5XSAgIGdmbjog
MDAwMDU3NmUgIG1mbjogMDAwMDU3NmUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6Mjld
ICAgZ2ZuOiAwMDAwNTc2ZiAgbWZuOiAwMDAwNTc2Zg0KDQooWEVOKSBbMjAxMi0wOC0zMSAy
MTozMzoyOV0gICBnZm46IDAwMDA1NzcwICBtZm46IDAwMDA1NzcwDQoNCihYRU4pIFsyMDEy
LTA4LTMxIDIxOjMzOjI5XSAgIGdmbjogMDAwMDU3NzEgIG1mbjogMDAwMDU3NzENCg0KKFhF
TikgWzIwMTItMDgtMzEgMjE6MzM6MjldICAgZ2ZuOiAwMDAwNTc3MiAgbWZuOiAwMDAwNTc3
Mg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoyOV0gICBnZm46IDAwMDA1NzczICBtZm46
IDAwMDA1NzczDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjI5XSAgIGdmbjogMDAwMDU3
NzQgIG1mbjogMDAwMDU3NzQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MjldICAgZ2Zu
OiAwMDAwNTc3NSAgbWZuOiAwMDAwNTc3NQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoy
OV0gICBnZm46IDAwMDA1Nzc2ICBtZm46IDAwMDA1Nzc2DQoNCihYRU4pIFsyMDEyLTA4LTMx
IDIxOjMzOjI5XSAgIGdmbjogMDAwMDU3NzcgIG1mbjogMDAwMDU3NzcNCg0KKFhFTikgWzIw
MTItMDgtMzEgMjE6MzM6MjldICAgZ2ZuOiAwMDAwNTc3OCAgbWZuOiAwMDAwNTc3OA0KDQoo
WEVOKSBbMjAxMi0wOC0zMSAyMTozMzoyOV0gICBnZm46IDAwMDA1Nzc5ICBtZm46IDAwMDA1
Nzc5DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjI5XSAgIGdmbjogMDAwMDU3N2EgIG1m
bjogMDAwMDU3N2ENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MjldICAgZ2ZuOiAwMDAw
NTc3YiAgbWZuOiAwMDAwNTc3Yg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoyOV0gICBn
Zm46IDAwMDA1NzdjICBtZm46IDAwMDA1NzdjDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMz
OjI5XSAgIGdmbjogMDAwMDU3N2QgIG1mbjogMDAwMDU3N2QNCg0KKFhFTikgWzIwMTItMDgt
MzEgMjE6MzM6MjldICAgZ2ZuOiAwMDAwNTc3ZSAgbWZuOiAwMDAwNTc3ZQ0KDQooWEVOKSBb
MjAxMi0wOC0zMSAyMTozMzoyOV0gICBnZm46IDAwMDA1NzdmICBtZm46IDAwMDA1NzdmDQoN
CihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjI5XSAgIGdmbjogMDAwMDU3ODAgIG1mbjogMDAw
MDU3ODANCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MjldICAgZ2ZuOiAwMDAwNTc4MSAg
bWZuOiAwMDAwNTc4MQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoyOV0gICBnZm46IDAw
MDA1NzgyICBtZm46IDAwMDA1NzgyDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjI5XSAg
IGdmbjogMDAwMDU3ODMgIG1mbjogMDAwMDU3ODMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6
MzM6MjldICAgZ2ZuOiAwMDAwNTc4NCAgbWZuOiAwMDAwNTc4NA0KDQooWEVOKSBbMjAxMi0w
OC0zMSAyMTozMzoyOV0gICBnZm46IDAwMDA1Nzg1ICBtZm46IDAwMDA1Nzg1DQoNCihYRU4p
IFsyMDEyLTA4LTMxIDIxOjMzOjI5XSAgIGdmbjogMDAwMDU3ODYgIG1mbjogMDAwMDU3ODYN
Cg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MjldICAgZ2ZuOiAwMDAwNTc4NyAgbWZuOiAw
MDAwNTc4Nw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoyOV0gICBnZm46IDAwMDA1Nzg4
ICBtZm46IDAwMDA1Nzg4DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjI5XSAgIGdmbjog
MDAwMDU3ODkgIG1mbjogMDAwMDU3ODkNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6Mjld
ICAgZ2ZuOiAwMDAwNTc4YSAgbWZuOiAwMDAwNTc4YQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAy
MTozMzoyOV0gICBnZm46IDAwMDA1NzhiICBtZm46IDAwMDA1NzhiDQoNCihYRU4pIFsyMDEy
LTA4LTMxIDIxOjMzOjI5XSAgIGdmbjogMDAwMDU3OGMgIG1mbjogMDAwMDU3OGMNCg0KKFhF
TikgWzIwMTItMDgtMzEgMjE6MzM6MjldICAgZ2ZuOiAwMDAwNTc4ZCAgbWZuOiAwMDAwNTc4
ZA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoyOV0gICBnZm46IDAwMDA1NzhlICBtZm46
IDAwMDA1NzhlDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjI5XSAgIGdmbjogMDAwMDU3
OGYgIG1mbjogMDAwMDU3OGYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MjldICAgZ2Zu
OiAwMDAwNTc5MCAgbWZuOiAwMDAwNTc5MA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoz
MF0gICBnZm46IDAwMDA1NzkxICBtZm46IDAwMDA1NzkxDQoNCihYRU4pIFsyMDEyLTA4LTMx
IDIxOjMzOjMwXSAgIGdmbjogMDAwMDU3OTIgIG1mbjogMDAwMDU3OTINCg0KKFhFTikgWzIw
MTItMDgtMzEgMjE6MzM6MzBdICAgZ2ZuOiAwMDAwNTc5MyAgbWZuOiAwMDAwNTc5Mw0KDQoo
WEVOKSBbMjAxMi0wOC0zMSAyMTozMzozMF0gICBnZm46IDAwMDA1Nzk0ICBtZm46IDAwMDA1
Nzk0DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjMwXSAgIGdmbjogMDAwMDU3OTUgIG1m
bjogMDAwMDU3OTUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MzBdICAgZ2ZuOiAwMDAw
NTc5NiAgbWZuOiAwMDAwNTc5Ng0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzozMF0gICBn
Zm46IDAwMDA1Nzk3ICBtZm46IDAwMDA1Nzk3DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMz
OjMwXSAgIGdmbjogMDAwMDU3OTggIG1mbjogMDAwMDU3OTgNCg0KKFhFTikgWzIwMTItMDgt
MzEgMjE6MzM6MzBdICAgZ2ZuOiAwMDAwNTc5OSAgbWZuOiAwMDAwNTc5OQ0KDQooWEVOKSBb
MjAxMi0wOC0zMSAyMTozMzozMF0gICBnZm46IDAwMDA1NzlhICBtZm46IDAwMDA1NzlhDQoN
CihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjMwXSAgIGdmbjogMDAwMDU3OWIgIG1mbjogMDAw
MDU3OWINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MzBdICAgZ2ZuOiAwMDAwNTc5YyAg
bWZuOiAwMDAwNTc5Yw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzozMF0gICBnZm46IDAw
MDA1NzlkICBtZm46IDAwMDA1NzlkDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjMwXSAg
IGdmbjogMDAwMDU3OWUgIG1mbjogMDAwMDU3OWUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6
MzM6MzBdICAgZ2ZuOiAwMDAwNTc5ZiAgbWZuOiAwMDAwNTc5Zg0KDQooWEVOKSBbMjAxMi0w
OC0zMSAyMTozMzozMF0gICBnZm46IDAwMDA1N2EwICBtZm46IDAwMDA1N2EwDQoNCihYRU4p
IFsyMDEyLTA4LTMxIDIxOjMzOjMwXSAgIGdmbjogMDAwMDU3YTEgIG1mbjogMDAwMDU3YTEN
Cg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MzBdICAgZ2ZuOiAwMDAwNTdhMiAgbWZuOiAw
MDAwNTdhMg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzozMF0gICBnZm46IDAwMDA1N2Ez
ICBtZm46IDAwMDA1N2EzDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjMwXSAgIGdmbjog
MDAwMDU3YTQgIG1mbjogMDAwMDU3YTQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MzBd
ICAgZ2ZuOiAwMDAwNTdhNSAgbWZuOiAwMDAwNTdhNQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAy
MTozMzozMF0gICBnZm46IDAwMDA1N2E2ICBtZm46IDAwMDA1N2E2DQoNCihYRU4pIFsyMDEy
LTA4LTMxIDIxOjMzOjMwXSAgIGdmbjogMDAwMDU3YTcgIG1mbjogMDAwMDU3YTcNCg0KKFhF
TikgWzIwMTItMDgtMzEgMjE6MzM6MzBdICAgZ2ZuOiAwMDAwNTdhOCAgbWZuOiAwMDAwNTdh
OA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzozMF0gICBnZm46IDAwMDA1N2E5ICBtZm46
IDAwMDA1N2E5DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjMwXSAgIGdmbjogMDAwMDU3
YWEgIG1mbjogMDAwMDU3YWENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MzBdICAgZ2Zu
OiAwMDAwNTdhYiAgbWZuOiAwMDAwNTdhYg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoz
MF0gICBnZm46IDAwMDA1N2FjICBtZm46IDAwMDA1N2FjDQoNCihYRU4pIFsyMDEyLTA4LTMx
IDIxOjMzOjMwXSAgIGdmbjogMDAwMDU3YWQgIG1mbjogMDAwMDU3YWQNCg0KKFhFTikgWzIw
MTItMDgtMzEgMjE6MzM6MzBdICAgZ2ZuOiAwMDAwNTdhZSAgbWZuOiAwMDAwNTdhZQ0KDQoo
WEVOKSBbMjAxMi0wOC0zMSAyMTozMzozMF0gICBnZm46IDAwMDA1N2FmICBtZm46IDAwMDA1
N2FmDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjMwXSAgIGdmbjogMDAwMDU3YjAgIG1m
bjogMDAwMDU3YjANCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MzBdICAgZ2ZuOiAwMDAw
NTdiMSAgbWZuOiAwMDAwNTdiMQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzozMF0gICBn
Zm46IDAwMDA1N2IyICBtZm46IDAwMDA1N2IyDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMz
OjMwXSAgIGdmbjogMDAwMDU3YjMgIG1mbjogMDAwMDU3YjMNCg0KKFhFTikgWzIwMTItMDgt
MzEgMjE6MzM6MzBdICAgZ2ZuOiAwMDAwNTdiNCAgbWZuOiAwMDAwNTdiNA0KDQooWEVOKSBb
MjAxMi0wOC0zMSAyMTozMzozMF0gICBnZm46IDAwMDA1N2I1ICBtZm46IDAwMDA1N2I1DQoN
CihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjMwXSAgIGdmbjogMDAwMDU3YjYgIG1mbjogMDAw
MDU3YjYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MzBdICAgZ2ZuOiAwMDAwNTdiNyAg
bWZuOiAwMDAwNTdiNw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzozMF0gICBnZm46IDAw
MDA1N2I4ICBtZm46IDAwMDA1N2I4DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjMwXSAg
IGdmbjogMDAwMDU3YjkgIG1mbjogMDAwMDU3YjkNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6
MzM6MzBdICAgZ2ZuOiAwMDAwNTdiYSAgbWZuOiAwMDAwNTdiYQ0KDQooWEVOKSBbMjAxMi0w
OC0zMSAyMTozMzozMF0gICBnZm46IDAwMDA1N2JiICBtZm46IDAwMDA1N2JiDQoNCihYRU4p
IFsyMDEyLTA4LTMxIDIxOjMzOjMwXSAgIGdmbjogMDAwMDU3YmMgIG1mbjogMDAwMDU3YmMN
Cg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MzBdICAgZ2ZuOiAwMDAwNTdiZCAgbWZuOiAw
MDAwNTdiZA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzozMF0gICBnZm46IDAwMDA1N2Jl
ICBtZm46IDAwMDA1N2JlDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjMwXSAgIGdmbjog
MDAwMDU3YmYgIG1mbjogMDAwMDU3YmYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MzBd
ICAgZ2ZuOiAwMDAwNTdjMCAgbWZuOiAwMDAwNTdjMA0KDQooWEVOKSBbMjAxMi0wOC0zMSAy
MTozMzozMF0gICBnZm46IDAwMDA1N2MxICBtZm46IDAwMDA1N2MxDQoNCihYRU4pIFsyMDEy
LTA4LTMxIDIxOjMzOjMwXSAgIGdmbjogMDAwMDU3YzIgIG1mbjogMDAwMDU3YzINCg0KKFhF
TikgWzIwMTItMDgtMzEgMjE6MzM6MzBdICAgZ2ZuOiAwMDAwNTdjMyAgbWZuOiAwMDAwNTdj
Mw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzozMF0gICBnZm46IDAwMDA1N2M0ICBtZm46
IDAwMDA1N2M0DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjMwXSAgIGdmbjogMDAwMDU3
YzUgIG1mbjogMDAwMDU3YzUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MzBdICAgZ2Zu
OiAwMDAwNTdjNiAgbWZuOiAwMDAwNTdjNg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoz
MF0gICBnZm46IDAwMDA1N2M3ICBtZm46IDAwMDA1N2M3DQoNCihYRU4pIFsyMDEyLTA4LTMx
IDIxOjMzOjMwXSAgIGdmbjogMDAwMDU3YzggIG1mbjogMDAwMDU3YzgNCg0KKFhFTikgWzIw
MTItMDgtMzEgMjE6MzM6MzBdICAgZ2ZuOiAwMDAwNTdjOSAgbWZuOiAwMDAwNTdjOQ0KDQoo
WEVOKSBbMjAxMi0wOC0zMSAyMTozMzozMF0gICBnZm46IDAwMDA1N2NhICBtZm46IDAwMDA1
N2NhDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjMwXSAgIGdmbjogMDAwMDU3Y2IgIG1m
bjogMDAwMDU3Y2INCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MzBdICAgZ2ZuOiAwMDAw
NTdjYyAgbWZuOiAwMDAwNTdjYw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzozMF0gICBn
Zm46IDAwMDA1N2NkICBtZm46IDAwMDA1N2NkDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMz
OjMwXSAgIGdmbjogMDAwMDU3Y2UgIG1mbjogMDAwMDU3Y2UNCg0KKFhFTikgWzIwMTItMDgt
MzEgMjE6MzM6MzBdICAgZ2ZuOiAwMDAwNTdjZiAgbWZuOiAwMDAwNTdjZg0KDQooWEVOKSBb
MjAxMi0wOC0zMSAyMTozMzozMF0gICBnZm46IDAwMDA1N2QwICBtZm46IDAwMDA1N2QwDQoN
CihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjMxXSAgIGdmbjogMDAwMDU3ZDEgIG1mbjogMDAw
MDU3ZDENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MzFdICAgZ2ZuOiAwMDAwNTdkMiAg
bWZuOiAwMDAwNTdkMg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzozMV0gICBnZm46IDAw
MDA1N2QzICBtZm46IDAwMDA1N2QzDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjMxXSAg
IGdmbjogMDAwMDU3ZDQgIG1mbjogMDAwMDU3ZDQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6
MzM6MzFdICAgZ2ZuOiAwMDAwNTdkNSAgbWZuOiAwMDAwNTdkNQ0KDQooWEVOKSBbMjAxMi0w
OC0zMSAyMTozMzozMV0gICBnZm46IDAwMDA1N2Q2ICBtZm46IDAwMDA1N2Q2DQoNCihYRU4p
IFsyMDEyLTA4LTMxIDIxOjMzOjMxXSAgIGdmbjogMDAwMDU3ZDcgIG1mbjogMDAwMDU3ZDcN
Cg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MzFdICAgZ2ZuOiAwMDAwNTdkOCAgbWZuOiAw
MDAwNTdkOA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzozMV0gICBnZm46IDAwMDA1N2Q5
ICBtZm46IDAwMDA1N2Q5DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjMxXSAgIGdmbjog
MDAwMDU3ZGEgIG1mbjogMDAwMDU3ZGENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MzFd
ICAgZ2ZuOiAwMDAwNTdkYiAgbWZuOiAwMDAwNTdkYg0KDQooWEVOKSBbMjAxMi0wOC0zMSAy
MTozMzozMV0gICBnZm46IDAwMDA1N2RjICBtZm46IDAwMDA1N2RjDQoNCihYRU4pIFsyMDEy
LTA4LTMxIDIxOjMzOjMxXSAgIGdmbjogMDAwMDU3ZGQgIG1mbjogMDAwMDU3ZGQNCg0KKFhF
TikgWzIwMTItMDgtMzEgMjE6MzM6MzFdICAgZ2ZuOiAwMDAwNTdkZSAgbWZuOiAwMDAwNTdk
ZQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzozMV0gICBnZm46IDAwMDA1N2RmICBtZm46
IDAwMDA1N2RmDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjMxXSAgIGdmbjogMDAwMDU3
ZTAgIG1mbjogMDAwMDU3ZTANCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MzFdICAgZ2Zu
OiAwMDAwNTdlMSAgbWZuOiAwMDAwNTdlMQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoz
MV0gICBnZm46IDAwMDA1N2UyICBtZm46IDAwMDA1N2UyDQoNCihYRU4pIFsyMDEyLTA4LTMx
IDIxOjMzOjMxXSAgIGdmbjogMDAwMDU3ZTMgIG1mbjogMDAwMDU3ZTMNCg0KKFhFTikgWzIw
MTItMDgtMzEgMjE6MzM6MzFdICAgZ2ZuOiAwMDAwNTdlNCAgbWZuOiAwMDAwNTdlNA0KDQoo
WEVOKSBbMjAxMi0wOC0zMSAyMTozMzozMV0gICBnZm46IDAwMDA1N2U1ICBtZm46IDAwMDA1
N2U1DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjMxXSAgIGdmbjogMDAwMDU3ZTYgIG1m
bjogMDAwMDU3ZTYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MzFdICAgZ2ZuOiAwMDAw
NTdlNyAgbWZuOiAwMDAwNTdlNw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzozMV0gICBn
Zm46IDAwMDA1N2U4ICBtZm46IDAwMDA1N2U4DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMz
OjMxXSAgIGdmbjogMDAwMDU3ZTkgIG1mbjogMDAwMDU3ZTkNCg0KKFhFTikgWzIwMTItMDgt
MzEgMjE6MzM6MzFdICAgZ2ZuOiAwMDAwNTdlYSAgbWZuOiAwMDAwNTdlYQ0KDQooWEVOKSBb
MjAxMi0wOC0zMSAyMTozMzozMV0gICBnZm46IDAwMDA1N2ViICBtZm46IDAwMDA1N2ViDQoN
CihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjMxXSAgIGdmbjogMDAwMDU3ZWMgIG1mbjogMDAw
MDU3ZWMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MzFdICAgZ2ZuOiAwMDAwNTdlZCAg
bWZuOiAwMDAwNTdlZA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzozMV0gICBnZm46IDAw
MDA1N2VlICBtZm46IDAwMDA1N2VlDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjMxXSAg
IGdmbjogMDAwMDU3ZWYgIG1mbjogMDAwMDU3ZWYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6
MzM6MzFdICAgZ2ZuOiAwMDAwNTdmMCAgbWZuOiAwMDAwNTdmMA0KDQooWEVOKSBbMjAxMi0w
OC0zMSAyMTozMzozMV0gICBnZm46IDAwMDA1N2YxICBtZm46IDAwMDA1N2YxDQoNCihYRU4p
IFsyMDEyLTA4LTMxIDIxOjMzOjMxXSAgIGdmbjogMDAwMDU3ZjIgIG1mbjogMDAwMDU3ZjIN
Cg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MzFdICAgZ2ZuOiAwMDAwNTdmMyAgbWZuOiAw
MDAwNTdmMw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzozMV0gICBnZm46IDAwMDA1N2Y0
ICBtZm46IDAwMDA1N2Y0DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjMxXSAgIGdmbjog
MDAwMDU3ZjUgIG1mbjogMDAwMDU3ZjUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MzFd
ICAgZ2ZuOiAwMDAwNTdmNiAgbWZuOiAwMDAwNTdmNg0KDQooWEVOKSBbMjAxMi0wOC0zMSAy
MTozMzozMV0gICBnZm46IDAwMDA1N2Y3ICBtZm46IDAwMDA1N2Y3DQoNCihYRU4pIFsyMDEy
LTA4LTMxIDIxOjMzOjMxXSAgIGdmbjogMDAwMDU3ZjggIG1mbjogMDAwMDU3ZjgNCg0KKFhF
TikgWzIwMTItMDgtMzEgMjE6MzM6MzFdICAgZ2ZuOiAwMDAwNTdmOSAgbWZuOiAwMDAwNTdm
OQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzozMV0gICBnZm46IDAwMDA1N2ZhICBtZm46
IDAwMDA1N2ZhDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjMxXSAgIGdmbjogMDAwMDU3
ZmIgIG1mbjogMDAwMDU3ZmINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MzFdICAgZ2Zu
OiAwMDAwNTdmYyAgbWZuOiAwMDAwNTdmYw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoz
MV0gICBnZm46IDAwMDA1N2ZkICBtZm46IDAwMDA1N2ZkDQoNCihYRU4pIFsyMDEyLTA4LTMx
IDIxOjMzOjMxXSAgIGdmbjogMDAwMDU3ZmUgIG1mbjogMDAwMDU3ZmUNCg0KKFhFTikgWzIw
MTItMDgtMzEgMjE6MzM6MzFdICAgZ2ZuOiAwMDAwNTdmZiAgbWZuOiAwMDAwNTdmZg0KDQoo
WEVOKSBbMjAxMi0wOC0zMSAyMTozMzozMV0gICBnZm46IDAwMDA1ODAwICBtZm46IDAwMDA1
ODAwDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjMxXSAgIGdmbjogMDAwMDU4MDEgIG1m
bjogMDAwMDU4MDENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MzFdICAgZ2ZuOiAwMDAw
NTgwMiAgbWZuOiAwMDAwNTgwMg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzozMV0gICBn
Zm46IDAwMDA1ODAzICBtZm46IDAwMDA1ODAzDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMz
OjMxXSAgIGdmbjogMDAwMDU4MDQgIG1mbjogMDAwMDU4MDQNCg0KKFhFTikgWzIwMTItMDgt
MzEgMjE6MzM6MzFdICAgZ2ZuOiAwMDAwNTgwNSAgbWZuOiAwMDAwNTgwNQ0KDQooWEVOKSBb
MjAxMi0wOC0zMSAyMTozMzozMV0gICBnZm46IDAwMDA1ODA2ICBtZm46IDAwMDA1ODA2DQoN
CihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjMxXSAgIGdmbjogMDAwMDU4MDcgIG1mbjogMDAw
MDU4MDcNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MzFdICAgZ2ZuOiAwMDAwNTgwOCAg
bWZuOiAwMDAwNTgwOA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzozMV0gICBnZm46IDAw
MDA1ODA5ICBtZm46IDAwMDA1ODA5DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjMxXSAg
IGdmbjogMDAwMDU4MGEgIG1mbjogMDAwMDU4MGENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6
MzM6MzFdICAgZ2ZuOiAwMDAwNTgwYiAgbWZuOiAwMDAwNTgwYg0KDQooWEVOKSBbMjAxMi0w
OC0zMSAyMTozMzozMV0gICBnZm46IDAwMDA1ODBjICBtZm46IDAwMDA1ODBjDQoNCihYRU4p
IFsyMDEyLTA4LTMxIDIxOjMzOjMxXSAgIGdmbjogMDAwMDU4MGQgIG1mbjogMDAwMDU4MGQN
Cg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MzFdICAgZ2ZuOiAwMDAwNTgwZSAgbWZuOiAw
MDAwNTgwZQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzozMV0gICBnZm46IDAwMDA1ODBm
ICBtZm46IDAwMDA1ODBmDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjMxXSAgIGdmbjog
MDAwMDU4MTAgIG1mbjogMDAwMDU4MTANCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MzJd
ICAgZ2ZuOiAwMDAwNTgxMSAgbWZuOiAwMDAwNTgxMQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAy
MTozMzozMl0gICBnZm46IDAwMDA1ODEyICBtZm46IDAwMDA1ODEyDQoNCihYRU4pIFsyMDEy
LTA4LTMxIDIxOjMzOjMyXSAgIGdmbjogMDAwMDU4MTMgIG1mbjogMDAwMDU4MTMNCg0KKFhF
TikgWzIwMTItMDgtMzEgMjE6MzM6MzJdICAgZ2ZuOiAwMDAwNTgxNCAgbWZuOiAwMDAwNTgx
NA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzozMl0gICBnZm46IDAwMDA1ODE1ICBtZm46
IDAwMDA1ODE1DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjMyXSAgIGdmbjogMDAwMDU4
MTYgIG1mbjogMDAwMDU4MTYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MzJdICAgZ2Zu
OiAwMDAwNTgxNyAgbWZuOiAwMDAwNTgxNw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoz
Ml0gICBnZm46IDAwMDA1ODE4ICBtZm46IDAwMDA1ODE4DQoNCihYRU4pIFsyMDEyLTA4LTMx
IDIxOjMzOjMyXSAgIGdmbjogMDAwMDU4MTkgIG1mbjogMDAwMDU4MTkNCg0KKFhFTikgWzIw
MTItMDgtMzEgMjE6MzM6MzJdICAgZ2ZuOiAwMDAwNTgxYSAgbWZuOiAwMDAwNTgxYQ0KDQoo
WEVOKSBbMjAxMi0wOC0zMSAyMTozMzozMl0gICBnZm46IDAwMDA1ODFiICBtZm46IDAwMDA1
ODFiDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjMyXSAgIGdmbjogMDAwMDU4MWMgIG1m
bjogMDAwMDU4MWMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MzJdICAgZ2ZuOiAwMDAw
NTgxZCAgbWZuOiAwMDAwNTgxZA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzozMl0gICBn
Zm46IDAwMDA1ODFlICBtZm46IDAwMDA1ODFlDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMz
OjMyXSAgIGdmbjogMDAwMDU4MWYgIG1mbjogMDAwMDU4MWYNCg0KKFhFTikgWzIwMTItMDgt
MzEgMjE6MzM6MzJdICAgZ2ZuOiAwMDAwNTgyMCAgbWZuOiAwMDAwNTgyMA0KDQooWEVOKSBb
MjAxMi0wOC0zMSAyMTozMzozMl0gICBnZm46IDAwMDA1ODIxICBtZm46IDAwMDA1ODIxDQoN
CihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjMyXSAgIGdmbjogMDAwMDU4MjIgIG1mbjogMDAw
MDU4MjINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MzJdICAgZ2ZuOiAwMDAwNTgyMyAg
bWZuOiAwMDAwNTgyMw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzozMl0gICBnZm46IDAw
MDA1ODI0ICBtZm46IDAwMDA1ODI0DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjMyXSAg
IGdmbjogMDAwMDU4MjUgIG1mbjogMDAwMDU4MjUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6
MzM6MzJdICAgZ2ZuOiAwMDAwNTgyNiAgbWZuOiAwMDAwNTgyNg0KDQooWEVOKSBbMjAxMi0w
OC0zMSAyMTozMzozMl0gICBnZm46IDAwMDA1ODI3ICBtZm46IDAwMDA1ODI3DQoNCihYRU4p
IFsyMDEyLTA4LTMxIDIxOjMzOjMyXSAgIGdmbjogMDAwMDU4MjggIG1mbjogMDAwMDU4MjgN
Cg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MzJdICAgZ2ZuOiAwMDAwNTgyOSAgbWZuOiAw
MDAwNTgyOQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzozMl0gICBnZm46IDAwMDA1ODJh
ICBtZm46IDAwMDA1ODJhDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjMyXSAgIGdmbjog
MDAwMDU4MmIgIG1mbjogMDAwMDU4MmINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MzJd
ICAgZ2ZuOiAwMDAwNTgyYyAgbWZuOiAwMDAwNTgyYw0KDQooWEVOKSBbMjAxMi0wOC0zMSAy
MTozMzozMl0gICBnZm46IDAwMDA1ODJkICBtZm46IDAwMDA1ODJkDQoNCihYRU4pIFsyMDEy
LTA4LTMxIDIxOjMzOjMyXSAgIGdmbjogMDAwMDU4MmUgIG1mbjogMDAwMDU4MmUNCg0KKFhF
TikgWzIwMTItMDgtMzEgMjE6MzM6MzJdICAgZ2ZuOiAwMDAwNTgyZiAgbWZuOiAwMDAwNTgy
Zg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzozMl0gICBnZm46IDAwMDA1ODMwICBtZm46
IDAwMDA1ODMwDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjMyXSAgIGdmbjogMDAwMDU4
MzEgIG1mbjogMDAwMDU4MzENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MzJdICAgZ2Zu
OiAwMDAwNTgzMiAgbWZuOiAwMDAwNTgzMg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoz
Ml0gICBnZm46IDAwMDA1ODMzICBtZm46IDAwMDA1ODMzDQoNCihYRU4pIFsyMDEyLTA4LTMx
IDIxOjMzOjMyXSAgIGdmbjogMDAwMDU4MzQgIG1mbjogMDAwMDU4MzQNCg0KKFhFTikgWzIw
MTItMDgtMzEgMjE6MzM6MzJdICAgZ2ZuOiAwMDAwNTgzNSAgbWZuOiAwMDAwNTgzNQ0KDQoo
WEVOKSBbMjAxMi0wOC0zMSAyMTozMzozMl0gICBnZm46IDAwMDA1ODM2ICBtZm46IDAwMDA1
ODM2DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjMyXSAgIGdmbjogMDAwMDU4MzcgIG1m
bjogMDAwMDU4MzcNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MzJdICAgZ2ZuOiAwMDAw
NTgzOCAgbWZuOiAwMDAwNTgzOA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzozMl0gICBn
Zm46IDAwMDA1ODM5ICBtZm46IDAwMDA1ODM5DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMz
OjMyXSAgIGdmbjogMDAwMDU4M2EgIG1mbjogMDAwMDU4M2ENCg0KKFhFTikgWzIwMTItMDgt
MzEgMjE6MzM6MzJdICAgZ2ZuOiAwMDAwNTgzYiAgbWZuOiAwMDAwNTgzYg0KDQooWEVOKSBb
MjAxMi0wOC0zMSAyMTozMzozMl0gICBnZm46IDAwMDA1ODNjICBtZm46IDAwMDA1ODNjDQoN
CihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjMyXSAgIGdmbjogMDAwMDU4M2QgIG1mbjogMDAw
MDU4M2QNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MzJdICAgZ2ZuOiAwMDAwNTgzZSAg
bWZuOiAwMDAwNTgzZQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzozMl0gICBnZm46IDAw
MDA1ODNmICBtZm46IDAwMDA1ODNmDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjMyXSAg
IGdmbjogMDAwMDU4NDAgIG1mbjogMDAwMDU4NDANCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6
MzM6MzJdICAgZ2ZuOiAwMDAwNTg0MSAgbWZuOiAwMDAwNTg0MQ0KDQooWEVOKSBbMjAxMi0w
OC0zMSAyMTozMzozMl0gICBnZm46IDAwMDA1ODQyICBtZm46IDAwMDA1ODQyDQoNCihYRU4p
IFsyMDEyLTA4LTMxIDIxOjMzOjMyXSAgIGdmbjogMDAwMDU4NDMgIG1mbjogMDAwMDU4NDMN
Cg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MzJdICAgZ2ZuOiAwMDAwNTg0NCAgbWZuOiAw
MDAwNTg0NA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzozMl0gICBnZm46IDAwMDA1ODQ1
ICBtZm46IDAwMDA1ODQ1DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjMyXSAgIGdmbjog
MDAwMDU4NDYgIG1mbjogMDAwMDU4NDYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MzJd
ICAgZ2ZuOiAwMDAwNTg0NyAgbWZuOiAwMDAwNTg0Nw0KDQooWEVOKSBbMjAxMi0wOC0zMSAy
MTozMzozMl0gICBnZm46IDAwMDA1ODQ4ICBtZm46IDAwMDA1ODQ4DQoNCihYRU4pIFsyMDEy
LTA4LTMxIDIxOjMzOjMyXSAgIGdmbjogMDAwMDU4NDkgIG1mbjogMDAwMDU4NDkNCg0KKFhF
TikgWzIwMTItMDgtMzEgMjE6MzM6MzJdICAgZ2ZuOiAwMDAwNTg0YSAgbWZuOiAwMDAwNTg0
YQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzozMl0gICBnZm46IDAwMDA1ODRiICBtZm46
IDAwMDA1ODRiDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjMyXSAgIGdmbjogMDAwMDU4
NGMgIG1mbjogMDAwMDU4NGMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MzJdICAgZ2Zu
OiAwMDAwNTg0ZCAgbWZuOiAwMDAwNTg0ZA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoz
Ml0gICBnZm46IDAwMDA1ODRlICBtZm46IDAwMDA1ODRlDQoNCihYRU4pIFsyMDEyLTA4LTMx
IDIxOjMzOjMyXSAgIGdmbjogMDAwMDU4NGYgIG1mbjogMDAwMDU4NGYNCg0KKFhFTikgWzIw
MTItMDgtMzEgMjE6MzM6MzJdICAgZ2ZuOiAwMDAwNTg1MCAgbWZuOiAwMDAwNTg1MA0KDQoo
WEVOKSBbMjAxMi0wOC0zMSAyMTozMzozM10gICBnZm46IDAwMDA1ODUxICBtZm46IDAwMDA1
ODUxDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjMzXSAgIGdmbjogMDAwMDU4NTIgIG1m
bjogMDAwMDU4NTINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MzNdICAgZ2ZuOiAwMDAw
NTg1MyAgbWZuOiAwMDAwNTg1Mw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzozM10gICBn
Zm46IDAwMDA1ODU0ICBtZm46IDAwMDA1ODU0DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMz
OjMzXSAgIGdmbjogMDAwMDU4NTUgIG1mbjogMDAwMDU4NTUNCg0KKFhFTikgWzIwMTItMDgt
MzEgMjE6MzM6MzNdICAgZ2ZuOiAwMDAwNTg1NiAgbWZuOiAwMDAwNTg1Ng0KDQooWEVOKSBb
MjAxMi0wOC0zMSAyMTozMzozM10gICBnZm46IDAwMDA1ODU3ICBtZm46IDAwMDA1ODU3DQoN
CihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjMzXSAgIGdmbjogMDAwMDU4NTggIG1mbjogMDAw
MDU4NTgNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MzNdICAgZ2ZuOiAwMDAwNTg1OSAg
bWZuOiAwMDAwNTg1OQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzozM10gICBnZm46IDAw
MDA1ODVhICBtZm46IDAwMDA1ODVhDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjMzXSAg
IGdmbjogMDAwMDU4NWIgIG1mbjogMDAwMDU4NWINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6
MzM6MzNdICAgZ2ZuOiAwMDAwNTg1YyAgbWZuOiAwMDAwNTg1Yw0KDQooWEVOKSBbMjAxMi0w
OC0zMSAyMTozMzozM10gICBnZm46IDAwMDA1ODVkICBtZm46IDAwMDA1ODVkDQoNCihYRU4p
IFsyMDEyLTA4LTMxIDIxOjMzOjMzXSAgIGdmbjogMDAwMDU4NWUgIG1mbjogMDAwMDU4NWUN
Cg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MzNdICAgZ2ZuOiAwMDAwNTg1ZiAgbWZuOiAw
MDAwNTg1Zg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzozM10gICBnZm46IDAwMDA1ODYw
ICBtZm46IDAwMDA1ODYwDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjMzXSAgIGdmbjog
MDAwMDU4NjEgIG1mbjogMDAwMDU4NjENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MzNd
ICAgZ2ZuOiAwMDAwNTg2MiAgbWZuOiAwMDAwNTg2Mg0KDQooWEVOKSBbMjAxMi0wOC0zMSAy
MTozMzozM10gICBnZm46IDAwMDA1ODYzICBtZm46IDAwMDA1ODYzDQoNCihYRU4pIFsyMDEy
LTA4LTMxIDIxOjMzOjMzXSAgIGdmbjogMDAwMDU4NjQgIG1mbjogMDAwMDU4NjQNCg0KKFhF
TikgWzIwMTItMDgtMzEgMjE6MzM6MzNdICAgZ2ZuOiAwMDAwNTg2NSAgbWZuOiAwMDAwNTg2
NQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzozM10gICBnZm46IDAwMDA1ODY2ICBtZm46
IDAwMDA1ODY2DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjMzXSAgIGdmbjogMDAwMDU4
NjcgIG1mbjogMDAwMDU4NjcNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MzNdICAgZ2Zu
OiAwMDAwNTg2OCAgbWZuOiAwMDAwNTg2OA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoz
M10gICBnZm46IDAwMDA1ODY5ICBtZm46IDAwMDA1ODY5DQoNCihYRU4pIFsyMDEyLTA4LTMx
IDIxOjMzOjMzXSAgIGdmbjogMDAwMDU4NmEgIG1mbjogMDAwMDU4NmENCg0KKFhFTikgWzIw
MTItMDgtMzEgMjE6MzM6MzNdICAgZ2ZuOiAwMDAwNTg2YiAgbWZuOiAwMDAwNTg2Yg0KDQoo
WEVOKSBbMjAxMi0wOC0zMSAyMTozMzozM10gICBnZm46IDAwMDA1ODZjICBtZm46IDAwMDA1
ODZjDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjMzXSAgIGdmbjogMDAwMDU4NmQgIG1m
bjogMDAwMDU4NmQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MzNdICAgZ2ZuOiAwMDAw
NTg2ZSAgbWZuOiAwMDAwNTg2ZQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzozM10gICBn
Zm46IDAwMDA1ODZmICBtZm46IDAwMDA1ODZmDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMz
OjMzXSAgIGdmbjogMDAwMDU4NzAgIG1mbjogMDAwMDU4NzANCg0KKFhFTikgWzIwMTItMDgt
MzEgMjE6MzM6MzNdICAgZ2ZuOiAwMDAwNTg3MSAgbWZuOiAwMDAwNTg3MQ0KDQooWEVOKSBb
MjAxMi0wOC0zMSAyMTozMzozM10gICBnZm46IDAwMDA1ODcyICBtZm46IDAwMDA1ODcyDQoN
CihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjMzXSAgIGdmbjogMDAwMDU4NzMgIG1mbjogMDAw
MDU4NzMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MzNdICAgZ2ZuOiAwMDAwNTg3NCAg
bWZuOiAwMDAwNTg3NA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzozM10gICBnZm46IDAw
MDA1ODc1ICBtZm46IDAwMDA1ODc1DQoNClsgIDQ3OS41NTkzNDddIGEoWEVOKSBbMjAxMi0w
OC0zMSAyMTozMzozM10gICBnZm46IDAwMDA1ODc2ICBtZm46IDAwMDA1ODc2DQoNCnRhMy4w
MDogZXhjZXB0aW8oWEVOKSBbMjAxMi0wOC0zMSAyMTozMzozM10gICBnZm46IDAwMDA1ODc3
ICBtZm46IDAwMDA1ODc3DQoNCm4gRW1hc2sgMHgwIFNBY3QgMHgwIFNFcnIgMHgwIGFjKFhF
TikgWzIwMTItMDgtMzEgMjE6MzM6MzNdICAgZ2ZuOiAwMDAwNTg3OCAgbWZuOiAwMDAwNTg3
OA0KDQp0aW9uIDB4NiBmcm96ZW4NCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjMzXSAgIGdm
bjogMDAwMDU4NzkgIG1mbjogMDAwMDU4NzkNCg0KDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMzOjMzXSAgIGdmbjogMDAwMDU4N2EgIG1mbjogMDAwMDU4N2ENCg0KWyAgNDc5LjY2Mzcz
OF0gYShYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjMzXSAgIGdmbjogMDAwMDU4N2IgIG1mbjog
MDAwMDU4N2INCg0KdGEzLjAwOiBmYWlsZWQgYyhYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjMz
XSAgIGdmbjogMDAwMDU4N2MgIG1mbjogMDAwMDU4N2MNCg0Kb21tYW5kOiBDSEVDSyBQTyhY
RU4pIFsyMDEyLTA4LTMxIDIxOjMzOjMzXSAgIGdmbjogMDAwMDU4N2QgIG1mbjogMDAwMDU4
N2QNCg0KV0VSIE1PREUNCg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzozM10gICBnZm46
IDAwMDA1ODdlICBtZm46IDAwMDA1ODdlDQoNClsgIDQ3OS43Mzc1NjNdIGEoWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMzozM10gICBnZm46IDAwMDA1ODdmICBtZm46IDAwMDA1ODdmDQoNCnRh
My4wMDogY21kIGU1LzAoWEVOKSBbMjAxMi0wOC0zMSAyMTozMzozM10gICBnZm46IDAwMDA1
ODgwICBtZm46IDAwMDA1ODgwDQoNCjA6MDA6MDA6MDA6MDAvMDAoWEVOKSBbMjAxMi0wOC0z
MSAyMTozMzozM10gICBnZm46IDAwMDA1ODgxICBtZm46IDAwMDA1ODgxDQoNCjowMDowMDow
MDowMC80MCB0YWcgMA0KDQoNClsgIDQ3OS43MyhYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjMz
XSAgIGdmbjogMDAwMDU4ODIgIG1mbjogMDAwMDU4ODINCg0KNzU2M10gICAgICAgICAgcihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMzOjMzXSAgIGdmbjogMDAwMDU4ODMgIG1mbjogMDAwMDU4
ODMNCg0KZXMgNDAvMDA6ZmY6MDA6MDA6MDAvMDA6MDA6MDA6MDAoWEVOKSBbMjAxMi0wOC0z
MSAyMTozMzozM10gICBnZm46IDAwMDA1ODg0ICBtZm46IDAwMDA1ODg0DQoNCjowMC80MCBF
bWFzayAweDQoWEVOKSBbMjAxMi0wOC0zMSAyMTozMzozM10gICBnZm46IDAwMDA1ODg1ICBt
Zm46IDAwMDA1ODg1DQoNCiAodGltZW91dCkNCg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
MzozM10gICBnZm46IDAwMDA1ODg2ICBtZm46IDAwMDA1ODg2DQoNClsgIDQ3OS45MDUzMzZd
IGEoWEVOKSBbMjAxMi0wOC0zMSAyMTozMzozM10gICBnZm46IDAwMDA1ODg3ICBtZm46IDAw
MDA1ODg3DQoNCnRhMy4wMDogc3RhdHVzOiAoWEVOKSBbMjAxMi0wOC0zMSAyMTozMzozM10g
ICBnZm46IDAwMDA1ODg4ICBtZm46IDAwMDA1ODg4DQoNCnsgRFJEWSB9DQoNCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzM6MzNdICAgZ2ZuOiAwMDAwNTg4OSAgbWZuOiAwMDAwNTg4OQ0K
DQpbICA0NzkuOTYyMTUzXSBhKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MzNdICAgZ2ZuOiAw
MDAwNTg4YSAgbWZuOiAwMDAwNTg4YQ0KDQp0YTM6IGhhcmQgcmVzZXR0KFhFTikgWzIwMTIt
MDgtMzEgMjE6MzM6MzRdICAgZ2ZuOiAwMDAwNTg4YiAgbWZuOiAwMDAwNTg4Yg0KDQppbmcg
bGluaw0KDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjM0XSAgIGdmbjogMDAwMDU4OGMg
IG1mbjogMDAwMDU4OGMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MzRdICAgZ2ZuOiAw
MDAwNTg4ZCAgbWZuOiAwMDAwNTg4ZA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzozNF0g
ICBnZm46IDAwMDA1ODhlICBtZm46IDAwMDA1ODhlDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMzOjM0XSAgIGdmbjogMDAwMDU4OGYgIG1mbjogMDAwMDU4OGYNCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzM6MzRdICAgZ2ZuOiAwMDAwNTg5MCAgbWZuOiAwMDAwNTg5MA0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMzozNF0gICBnZm46IDAwMDA1ODkxICBtZm46IDAwMDA1ODkx
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjM0XSAgIGdmbjogMDAwMDU4OTIgIG1mbjog
MDAwMDU4OTINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MzRdICAgZ2ZuOiAwMDAwNTg5
MyAgbWZuOiAwMDAwNTg5Mw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzozNF0gICBnZm46
IDAwMDA1ODk0ICBtZm46IDAwMDA1ODk0DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjM0
XSAgIGdmbjogMDAwMDU4OTUgIG1mbjogMDAwMDU4OTUNCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzM6MzRdICAgZ2ZuOiAwMDAwNTg5NiAgbWZuOiAwMDAwNTg5Ng0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMzozNF0gICBnZm46IDAwMDA1ODk3ICBtZm46IDAwMDA1ODk3DQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMzOjM0XSAgIGdmbjogMDAwMDU4OTggIG1mbjogMDAwMDU4
OTgNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MzRdICAgZ2ZuOiAwMDAwNTg5OSAgbWZu
OiAwMDAwNTg5OQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzozNF0gICBnZm46IDAwMDA1
ODlhICBtZm46IDAwMDA1ODlhDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjM0XSAgIGdm
bjogMDAwMDU4OWIgIG1mbjogMDAwMDU4OWINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6
MzRdICAgZ2ZuOiAwMDAwNTg5YyAgbWZuOiAwMDAwNTg5Yw0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMzozNF0gICBnZm46IDAwMDA1ODlkICBtZm46IDAwMDA1ODlkDQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMzOjM0XSAgIGdmbjogMDAwMDU4OWUgIG1mbjogMDAwMDU4OWUNCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MzRdICAgZ2ZuOiAwMDAwNTg5ZiAgbWZuOiAwMDAw
NTg5Zg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzozNF0gICBnZm46IDAwMDA1OGEwICBt
Zm46IDAwMDA1OGEwDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjM0XSAgIGdmbjogMDAw
MDU4YTEgIG1mbjogMDAwMDU4YTENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MzRdICAg
Z2ZuOiAwMDAwNThhMiAgbWZuOiAwMDAwNThhMg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
MzozNF0gICBnZm46IDAwMDA1OGEzICBtZm46IDAwMDA1OGEzDQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMzOjM0XSAgIGdmbjogMDAwMDU4YTQgIG1mbjogMDAwMDU4YTQNCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzM6MzRdICAgZ2ZuOiAwMDAwNThhNSAgbWZuOiAwMDAwNThhNQ0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzozNF0gICBnZm46IDAwMDA1OGE2ICBtZm46IDAw
MDA1OGE2DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjM0XSAgIGdmbjogMDAwMDU4YTcg
IG1mbjogMDAwMDU4YTcNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MzRdICAgZ2ZuOiAw
MDAwNThhOCAgbWZuOiAwMDAwNThhOA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzozNF0g
ICBnZm46IDAwMDA1OGE5ICBtZm46IDAwMDA1OGE5DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMzOjM0XSAgIGdmbjogMDAwMDU4YWEgIG1mbjogMDAwMDU4YWENCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzM6MzRdICAgZ2ZuOiAwMDAwNThhYiAgbWZuOiAwMDAwNThhYg0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMzozNF0gICBnZm46IDAwMDA1OGFjICBtZm46IDAwMDA1OGFj
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjM0XSAgIGdmbjogMDAwMDU4YWQgIG1mbjog
MDAwMDU4YWQNCg0KWyAgNDgwLjUzNjIzOF0gYShYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjM0
XSAgIGdmbjogMDAwMDU4YWUgIG1mbjogMDAwMDU4YWUNCg0KdGEzOiBTQVRBIGxpbmsgdShY
RU4pIFsyMDEyLTA4LTMxIDIxOjMzOjM0XSAgIGdmbjogMDAwMDU4YWYgIG1mbjogMDAwMDU4
YWYNCg0KcCA2LjAgR2JwcyAoU1N0YXR1cyAxMzMgU0NvbnRyb2woWEVOKSBbMjAxMi0wOC0z
MSAyMTozMzozNF0gICBnZm46IDAwMDA1OGIwICBtZm46IDAwMDA1OGIwDQoNCiAzMDApDQoN
Cg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MzRdICAgZ2ZuOiAwMDAwNThiMSAgbWZuOiAw
MDAwNThiMQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzozNF0gICBnZm46IDAwMDA1OGIy
ICBtZm46IDAwMDA1OGIyDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjM0XSAgIGdmbjog
MDAwMDU4YjMgIG1mbjogMDAwMDU4YjMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MzRd
ICAgZ2ZuOiAwMDAwNThiNCAgbWZuOiAwMDAwNThiNA0KDQooWEVOKSBbMjAxMi0wOC0zMSAy
MTozMzozNF0gICBnZm46IDAwMDA1OGI1ICBtZm46IDAwMDA1OGI1DQoNCihYRU4pIFsyMDEy
LTA4LTMxIDIxOjMzOjM0XSAgIGdmbjogMDAwMDU4YjYgIG1mbjogMDAwMDU4YjYNCg0KKFhF
TikgWzIwMTItMDgtMzEgMjE6MzM6MzRdICAgZ2ZuOiAwMDAwNThiNyAgbWZuOiAwMDAwNThi
Nw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzozNF0gICBnZm46IDAwMDA1OGI4ICBtZm46
IDAwMDA1OGI4DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjM0XSAgIGdmbjogMDAwMDU4
YjkgIG1mbjogMDAwMDU4YjkNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MzRdICAgZ2Zu
OiAwMDAwNThiYSAgbWZuOiAwMDAwNThiYQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoz
NF0gICBnZm46IDAwMDA1OGJiICBtZm46IDAwMDA1OGJiDQoNCihYRU4pIFsyMDEyLTA4LTMx
IDIxOjMzOjM0XSAgIGdmbjogMDAwMDU4YmMgIG1mbjogMDAwMDU4YmMNCg0KKFhFTikgWzIw
MTItMDgtMzEgMjE6MzM6MzRdICAgZ2ZuOiAwMDAwNThiZCAgbWZuOiAwMDAwNThiZA0KDQoo
WEVOKSBbMjAxMi0wOC0zMSAyMTozMzozNF0gICBnZm46IDAwMDA1OGJlICBtZm46IDAwMDA1
OGJlDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjM0XSAgIGdmbjogMDAwMDU4YmYgIG1m
bjogMDAwMDU4YmYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MzRdICAgZ2ZuOiAwMDAw
NThjMCAgbWZuOiAwMDAwNThjMA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzozNF0gICBn
Zm46IDAwMDA1OGMxICBtZm46IDAwMDA1OGMxDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMz
OjM0XSAgIGdmbjogMDAwMDU4YzIgIG1mbjogMDAwMDU4YzINCg0KKFhFTikgWzIwMTItMDgt
MzEgMjE6MzM6MzRdICAgZ2ZuOiAwMDAwNThjMyAgbWZuOiAwMDAwNThjMw0KDQooWEVOKSBb
MjAxMi0wOC0zMSAyMTozMzozNF0gICBnZm46IDAwMDA1OGM0ICBtZm46IDAwMDA1OGM0DQoN
CihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjM0XSAgIGdmbjogMDAwMDU4YzUgIG1mbjogMDAw
MDU4YzUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MzRdICAgZ2ZuOiAwMDAwNThjNiAg
bWZuOiAwMDAwNThjNg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzozNF0gICBnZm46IDAw
MDA1OGM3ICBtZm46IDAwMDA1OGM3DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjM0XSAg
IGdmbjogMDAwMDU4YzggIG1mbjogMDAwMDU4YzgNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6
MzM6MzRdICAgZ2ZuOiAwMDAwNThjOSAgbWZuOiAwMDAwNThjOQ0KDQooWEVOKSBbMjAxMi0w
OC0zMSAyMTozMzozNV0gICBnZm46IDAwMDA1OGNhICBtZm46IDAwMDA1OGNhDQoNCihYRU4p
IFsyMDEyLTA4LTMxIDIxOjMzOjM1XSAgIGdmbjogMDAwMDU4Y2IgIG1mbjogMDAwMDU4Y2IN
Cg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MzVdICAgZ2ZuOiAwMDAwNThjYyAgbWZuOiAw
MDAwNThjYw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzozNV0gICBnZm46IDAwMDA1OGNk
ICBtZm46IDAwMDA1OGNkDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjM1XSAgIGdmbjog
MDAwMDU4Y2UgIG1mbjogMDAwMDU4Y2UNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MzVd
ICAgZ2ZuOiAwMDAwNThjZiAgbWZuOiAwMDAwNThjZg0KDQooWEVOKSBbMjAxMi0wOC0zMSAy
MTozMzozNV0gICBnZm46IDAwMDA1OGQwICBtZm46IDAwMDA1OGQwDQoNCihYRU4pIFsyMDEy
LTA4LTMxIDIxOjMzOjM1XSAgIGdmbjogMDAwMDU4ZDEgIG1mbjogMDAwMDU4ZDENCg0KKFhF
TikgWzIwMTItMDgtMzEgMjE6MzM6MzVdICAgZ2ZuOiAwMDAwNThkMiAgbWZuOiAwMDAwNThk
Mg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzozNV0gICBnZm46IDAwMDA1OGQzICBtZm46
IDAwMDA1OGQzDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjM1XSAgIGdmbjogMDAwMDU4
ZDQgIG1mbjogMDAwMDU4ZDQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MzVdICAgZ2Zu
OiAwMDAwNThkNSAgbWZuOiAwMDAwNThkNQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoz
NV0gICBnZm46IDAwMDA1OGQ2ICBtZm46IDAwMDA1OGQ2DQoNCihYRU4pIFsyMDEyLTA4LTMx
IDIxOjMzOjM1XSAgIGdmbjogMDAwMDU4ZDcgIG1mbjogMDAwMDU4ZDcNCg0KKFhFTikgWzIw
MTItMDgtMzEgMjE6MzM6MzVdICAgZ2ZuOiAwMDAwNThkOCAgbWZuOiAwMDAwNThkOA0KDQoo
WEVOKSBbMjAxMi0wOC0zMSAyMTozMzozNV0gICBnZm46IDAwMDA1OGQ5ICBtZm46IDAwMDA1
OGQ5DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjM1XSAgIGdmbjogMDAwMDU4ZGEgIG1m
bjogMDAwMDU4ZGENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MzVdICAgZ2ZuOiAwMDAw
NThkYiAgbWZuOiAwMDAwNThkYg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzozNV0gICBn
Zm46IDAwMDA1OGRjICBtZm46IDAwMDA1OGRjDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMz
OjM1XSAgIGdmbjogMDAwMDU4ZGQgIG1mbjogMDAwMDU4ZGQNCg0KKFhFTikgWzIwMTItMDgt
MzEgMjE6MzM6MzVdICAgZ2ZuOiAwMDAwNThkZSAgbWZuOiAwMDAwNThkZQ0KDQooWEVOKSBb
MjAxMi0wOC0zMSAyMTozMzozNV0gICBnZm46IDAwMDA1OGRmICBtZm46IDAwMDA1OGRmDQoN
CihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjM1XSAgIGdmbjogMDAwMDU4ZTAgIG1mbjogMDAw
MDU4ZTANCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MzVdICAgZ2ZuOiAwMDAwNThlMSAg
bWZuOiAwMDAwNThlMQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzozNV0gICBnZm46IDAw
MDA1OGUyICBtZm46IDAwMDA1OGUyDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjM1XSAg
IGdmbjogMDAwMDU4ZTMgIG1mbjogMDAwMDU4ZTMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6
MzM6MzVdICAgZ2ZuOiAwMDAwNThlNCAgbWZuOiAwMDAwNThlNA0KDQooWEVOKSBbMjAxMi0w
OC0zMSAyMTozMzozNV0gICBnZm46IDAwMDA1OGU1ICBtZm46IDAwMDA1OGU1DQoNCihYRU4p
IFsyMDEyLTA4LTMxIDIxOjMzOjM1XSAgIGdmbjogMDAwMDU4ZTYgIG1mbjogMDAwMDU4ZTYN
Cg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MzVdICAgZ2ZuOiAwMDAwNThlNyAgbWZuOiAw
MDAwNThlNw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzozNV0gICBnZm46IDAwMDA1OGU4
ICBtZm46IDAwMDA1OGU4DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjM1XSAgIGdmbjog
MDAwMDU4ZTkgIG1mbjogMDAwMDU4ZTkNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MzVd
ICAgZ2ZuOiAwMDAwNThlYSAgbWZuOiAwMDAwNThlYQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAy
MTozMzozNV0gICBnZm46IDAwMDA1OGViICBtZm46IDAwMDA1OGViDQoNCihYRU4pIFsyMDEy
LTA4LTMxIDIxOjMzOjM1XSAgIGdmbjogMDAwMDU4ZWMgIG1mbjogMDAwMDU4ZWMNCg0KKFhF
TikgWzIwMTItMDgtMzEgMjE6MzM6MzVdICAgZ2ZuOiAwMDAwNThlZCAgbWZuOiAwMDAwNThl
ZA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzozNV0gICBnZm46IDAwMDA1OGVlICBtZm46
IDAwMDA1OGVlDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjM1XSAgIGdmbjogMDAwMDU4
ZWYgIG1mbjogMDAwMDU4ZWYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MzVdICAgZ2Zu
OiAwMDAwNThmMCAgbWZuOiAwMDAwNThmMA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoz
NV0gICBnZm46IDAwMDA1OGYxICBtZm46IDAwMDA1OGYxDQoNCihYRU4pIFsyMDEyLTA4LTMx
IDIxOjMzOjM1XSAgIGdmbjogMDAwMDU4ZjIgIG1mbjogMDAwMDU4ZjINCg0KKFhFTikgWzIw
MTItMDgtMzEgMjE6MzM6MzVdICAgZ2ZuOiAwMDAwNThmMyAgbWZuOiAwMDAwNThmMw0KDQoo
WEVOKSBbMjAxMi0wOC0zMSAyMTozMzozNV0gICBnZm46IDAwMDA1OGY0ICBtZm46IDAwMDA1
OGY0DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjM1XSAgIGdmbjogMDAwMDU4ZjUgIG1m
bjogMDAwMDU4ZjUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MzVdICAgZ2ZuOiAwMDAw
NThmNiAgbWZuOiAwMDAwNThmNg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzozNV0gICBn
Zm46IDAwMDA1OGY3ICBtZm46IDAwMDA1OGY3DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMz
OjM1XSAgIGdmbjogMDAwMDU4ZjggIG1mbjogMDAwMDU4ZjgNCg0KKFhFTikgWzIwMTItMDgt
MzEgMjE6MzM6MzVdICAgZ2ZuOiAwMDAwNThmOSAgbWZuOiAwMDAwNThmOQ0KDQooWEVOKSBb
MjAxMi0wOC0zMSAyMTozMzozNV0gICBnZm46IDAwMDA1OGZhICBtZm46IDAwMDA1OGZhDQoN
CihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjM1XSAgIGdmbjogMDAwMDU4ZmIgIG1mbjogMDAw
MDU4ZmINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MzVdICAgZ2ZuOiAwMDAwNThmYyAg
bWZuOiAwMDAwNThmYw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzozNV0gICBnZm46IDAw
MDA1OGZkICBtZm46IDAwMDA1OGZkDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjM1XSAg
IGdmbjogMDAwMDU4ZmUgIG1mbjogMDAwMDU4ZmUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6
MzM6MzVdICAgZ2ZuOiAwMDAwNThmZiAgbWZuOiAwMDAwNThmZg0KDQooWEVOKSBbMjAxMi0w
OC0zMSAyMTozMzozNV0gICBnZm46IDAwMDA1OTAwICBtZm46IDAwMDA1OTAwDQoNCihYRU4p
IFsyMDEyLTA4LTMxIDIxOjMzOjM1XSAgIGdmbjogMDAwMDU5MDEgIG1mbjogMDAwMDU5MDEN
Cg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MzVdICAgZ2ZuOiAwMDAwNTkwMiAgbWZuOiAw
MDAwNTkwMg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzozNV0gICBnZm46IDAwMDA1OTAz
ICBtZm46IDAwMDA1OTAzDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjM1XSAgIGdmbjog
MDAwMDU5MDQgIG1mbjogMDAwMDU5MDQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MzVd
ICAgZ2ZuOiAwMDAwNTkwNSAgbWZuOiAwMDAwNTkwNQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAy
MTozMzozNV0gICBnZm46IDAwMDA1OTA2ICBtZm46IDAwMDA1OTA2DQoNCihYRU4pIFsyMDEy
LTA4LTMxIDIxOjMzOjM1XSAgIGdmbjogMDAwMDU5MDcgIG1mbjogMDAwMDU5MDcNCg0KKFhF
TikgWzIwMTItMDgtMzEgMjE6MzM6MzVdICAgZ2ZuOiAwMDAwNTkwOCAgbWZuOiAwMDAwNTkw
OA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzozNV0gICBnZm46IDAwMDA1OTA5ICBtZm46
IDAwMDA1OTA5DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjM2XSAgIGdmbjogMDAwMDU5
MGEgIG1mbjogMDAwMDU5MGENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MzZdICAgZ2Zu
OiAwMDAwNTkwYiAgbWZuOiAwMDAwNTkwYg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoz
Nl0gICBnZm46IDAwMDA1OTBjICBtZm46IDAwMDA1OTBjDQoNCihYRU4pIFsyMDEyLTA4LTMx
IDIxOjMzOjM2XSAgIGdmbjogMDAwMDU5MGQgIG1mbjogMDAwMDU5MGQNCg0KKFhFTikgWzIw
MTItMDgtMzEgMjE6MzM6MzZdICAgZ2ZuOiAwMDAwNTkwZSAgbWZuOiAwMDAwNTkwZQ0KDQoo
WEVOKSBbMjAxMi0wOC0zMSAyMTozMzozNl0gICBnZm46IDAwMDA1OTBmICBtZm46IDAwMDA1
OTBmDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjM2XSAgIGdmbjogMDAwMDU5MTAgIG1m
bjogMDAwMDU5MTANCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MzZdICAgZ2ZuOiAwMDAw
NTkxMSAgbWZuOiAwMDAwNTkxMQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzozNl0gICBn
Zm46IDAwMDA1OTEyICBtZm46IDAwMDA1OTEyDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMz
OjM2XSAgIGdmbjogMDAwMDU5MTMgIG1mbjogMDAwMDU5MTMNCg0KKFhFTikgWzIwMTItMDgt
MzEgMjE6MzM6MzZdICAgZ2ZuOiAwMDAwNTkxNCAgbWZuOiAwMDAwNTkxNA0KDQooWEVOKSBb
MjAxMi0wOC0zMSAyMTozMzozNl0gICBnZm46IDAwMDA1OTE1ICBtZm46IDAwMDA1OTE1DQoN
CihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjM2XSAgIGdmbjogMDAwMDU5MTYgIG1mbjogMDAw
MDU5MTYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MzZdICAgZ2ZuOiAwMDAwNTkxNyAg
bWZuOiAwMDAwNTkxNw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzozNl0gICBnZm46IDAw
MDA1OTE4ICBtZm46IDAwMDA1OTE4DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjM2XSAg
IGdmbjogMDAwMDU5MTkgIG1mbjogMDAwMDU5MTkNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6
MzM6MzZdICAgZ2ZuOiAwMDAwNTkxYSAgbWZuOiAwMDAwNTkxYQ0KDQooWEVOKSBbMjAxMi0w
OC0zMSAyMTozMzozNl0gICBnZm46IDAwMDA1OTFiICBtZm46IDAwMDA1OTFiDQoNCihYRU4p
IFsyMDEyLTA4LTMxIDIxOjMzOjM2XSAgIGdmbjogMDAwMDU5MWMgIG1mbjogMDAwMDU5MWMN
Cg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MzZdICAgZ2ZuOiAwMDAwNTkxZCAgbWZuOiAw
MDAwNTkxZA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzozNl0gICBnZm46IDAwMDA1OTFl
ICBtZm46IDAwMDA1OTFlDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjM2XSAgIGdmbjog
MDAwMDU5MWYgIG1mbjogMDAwMDU5MWYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MzZd
ICAgZ2ZuOiAwMDAwNTkyMCAgbWZuOiAwMDAwNTkyMA0KDQooWEVOKSBbMjAxMi0wOC0zMSAy
MTozMzozNl0gICBnZm46IDAwMDA1OTIxICBtZm46IDAwMDA1OTIxDQoNCihYRU4pIFsyMDEy
LTA4LTMxIDIxOjMzOjM2XSAgIGdmbjogMDAwMDU5MjIgIG1mbjogMDAwMDU5MjINCg0KKFhF
TikgWzIwMTItMDgtMzEgMjE6MzM6MzZdICAgZ2ZuOiAwMDAwNTkyMyAgbWZuOiAwMDAwNTky
Mw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzozNl0gICBnZm46IDAwMDA1OTI0ICBtZm46
IDAwMDA1OTI0DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjM2XSAgIGdmbjogMDAwMDU5
MjUgIG1mbjogMDAwMDU5MjUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MzZdICAgZ2Zu
OiAwMDAwNTkyNiAgbWZuOiAwMDAwNTkyNg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoz
Nl0gICBnZm46IDAwMDA1OTI3ICBtZm46IDAwMDA1OTI3DQoNCihYRU4pIFsyMDEyLTA4LTMx
IDIxOjMzOjM2XSAgIGdmbjogMDAwMDU5MjggIG1mbjogMDAwMDU5MjgNCg0KKFhFTikgWzIw
MTItMDgtMzEgMjE6MzM6MzZdICAgZ2ZuOiAwMDAwNTkyOSAgbWZuOiAwMDAwNTkyOQ0KDQoo
WEVOKSBbMjAxMi0wOC0zMSAyMTozMzozNl0gICBnZm46IDAwMDA1OTJhICBtZm46IDAwMDA1
OTJhDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjM2XSAgIGdmbjogMDAwMDU5MmIgIG1m
bjogMDAwMDU5MmINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MzZdICAgZ2ZuOiAwMDAw
NTkyYyAgbWZuOiAwMDAwNTkyYw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzozNl0gICBn
Zm46IDAwMDA1OTJkICBtZm46IDAwMDA1OTJkDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMz
OjM2XSAgIGdmbjogMDAwMDU5MmUgIG1mbjogMDAwMDU5MmUNCg0KKFhFTikgWzIwMTItMDgt
MzEgMjE6MzM6MzZdICAgZ2ZuOiAwMDAwNTkyZiAgbWZuOiAwMDAwNTkyZg0KDQooWEVOKSBb
MjAxMi0wOC0zMSAyMTozMzozNl0gICBnZm46IDAwMDA1OTMwICBtZm46IDAwMDA1OTMwDQoN
CihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjM2XSAgIGdmbjogMDAwMDU5MzEgIG1mbjogMDAw
MDU5MzENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MzZdICAgZ2ZuOiAwMDAwNTkzMiAg
bWZuOiAwMDAwNTkzMg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzozNl0gICBnZm46IDAw
MDA1OTMzICBtZm46IDAwMDA1OTMzDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjM2XSAg
IGdmbjogMDAwMDU5MzQgIG1mbjogMDAwMDU5MzQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6
MzM6MzZdICAgZ2ZuOiAwMDAwNTkzNSAgbWZuOiAwMDAwNTkzNQ0KDQooWEVOKSBbMjAxMi0w
OC0zMSAyMTozMzozNl0gICBnZm46IDAwMDA1OTM2ICBtZm46IDAwMDA1OTM2DQoNCihYRU4p
IFsyMDEyLTA4LTMxIDIxOjMzOjM2XSAgIGdmbjogMDAwMDU5MzcgIG1mbjogMDAwMDU5MzcN
Cg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MzZdICAgZ2ZuOiAwMDAwNTkzOCAgbWZuOiAw
MDAwNTkzOA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzozNl0gICBnZm46IDAwMDA1OTM5
ICBtZm46IDAwMDA1OTM5DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjM2XSAgIGdmbjog
MDAwMDU5M2EgIG1mbjogMDAwMDU5M2ENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MzZd
ICAgZ2ZuOiAwMDAwNTkzYiAgbWZuOiAwMDAwNTkzYg0KDQooWEVOKSBbMjAxMi0wOC0zMSAy
MTozMzozNl0gICBnZm46IDAwMDA1OTNjICBtZm46IDAwMDA1OTNjDQoNCihYRU4pIFsyMDEy
LTA4LTMxIDIxOjMzOjM2XSAgIGdmbjogMDAwMDU5M2QgIG1mbjogMDAwMDU5M2QNCg0KKFhF
TikgWzIwMTItMDgtMzEgMjE6MzM6MzZdICAgZ2ZuOiAwMDAwNTkzZSAgbWZuOiAwMDAwNTkz
ZQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzozNl0gICBnZm46IDAwMDA1OTNmICBtZm46
IDAwMDA1OTNmDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjM2XSAgIGdmbjogMDAwMDU5
NDAgIG1mbjogMDAwMDU5NDANCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MzZdICAgZ2Zu
OiAwMDAwNTk0MSAgbWZuOiAwMDAwNTk0MQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoz
Nl0gICBnZm46IDAwMDA1OTQyICBtZm46IDAwMDA1OTQyDQoNCihYRU4pIFsyMDEyLTA4LTMx
IDIxOjMzOjM2XSAgIGdmbjogMDAwMDU5NDMgIG1mbjogMDAwMDU5NDMNCg0KKFhFTikgWzIw
MTItMDgtMzEgMjE6MzM6MzZdICAgZ2ZuOiAwMDAwNTk0NCAgbWZuOiAwMDAwNTk0NA0KDQoo
WEVOKSBbMjAxMi0wOC0zMSAyMTozMzozNl0gICBnZm46IDAwMDA1OTQ1ICBtZm46IDAwMDA1
OTQ1DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjM2XSAgIGdmbjogMDAwMDU5NDYgIG1m
bjogMDAwMDU5NDYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MzZdICAgZ2ZuOiAwMDAw
NTk0NyAgbWZuOiAwMDAwNTk0Nw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzozNl0gICBn
Zm46IDAwMDA1OTQ4ICBtZm46IDAwMDA1OTQ4DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMz
OjM2XSAgIGdmbjogMDAwMDU5NDkgIG1mbjogMDAwMDU5NDkNCg0KKFhFTikgWzIwMTItMDgt
MzEgMjE6MzM6MzddICAgZ2ZuOiAwMDAwNTk0YSAgbWZuOiAwMDAwNTk0YQ0KDQooWEVOKSBb
MjAxMi0wOC0zMSAyMTozMzozN10gICBnZm46IDAwMDA1OTRiICBtZm46IDAwMDA1OTRiDQoN
CihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjM3XSAgIGdmbjogMDAwMDU5NGMgIG1mbjogMDAw
MDU5NGMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MzddICAgZ2ZuOiAwMDAwNTk0ZCAg
bWZuOiAwMDAwNTk0ZA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzozN10gICBnZm46IDAw
MDA1OTRlICBtZm46IDAwMDA1OTRlDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjM3XSAg
IGdmbjogMDAwMDU5NGYgIG1mbjogMDAwMDU5NGYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6
MzM6MzddICAgZ2ZuOiAwMDAwNTk1MCAgbWZuOiAwMDAwNTk1MA0KDQooWEVOKSBbMjAxMi0w
OC0zMSAyMTozMzozN10gICBnZm46IDAwMDA1OTUxICBtZm46IDAwMDA1OTUxDQoNCihYRU4p
IFsyMDEyLTA4LTMxIDIxOjMzOjM3XSAgIGdmbjogMDAwMDU5NTIgIG1mbjogMDAwMDU5NTIN
Cg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MzddICAgZ2ZuOiAwMDAwNTk1MyAgbWZuOiAw
MDAwNTk1Mw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzozN10gICBnZm46IDAwMDA1OTU0
ICBtZm46IDAwMDA1OTU0DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjM3XSAgIGdmbjog
MDAwMDU5NTUgIG1mbjogMDAwMDU5NTUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6Mzdd
ICAgZ2ZuOiAwMDAwNTk1NiAgbWZuOiAwMDAwNTk1Ng0KDQooWEVOKSBbMjAxMi0wOC0zMSAy
MTozMzozN10gICBnZm46IDAwMDA1OTU3ICBtZm46IDAwMDA1OTU3DQoNCihYRU4pIFsyMDEy
LTA4LTMxIDIxOjMzOjM3XSAgIGdmbjogMDAwMDU5NTggIG1mbjogMDAwMDU5NTgNCg0KKFhF
TikgWzIwMTItMDgtMzEgMjE6MzM6MzddICAgZ2ZuOiAwMDAwNTk1OSAgbWZuOiAwMDAwNTk1
OQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzozN10gICBnZm46IDAwMDA1OTVhICBtZm46
IDAwMDA1OTVhDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjM3XSAgIGdmbjogMDAwMDU5
NWIgIG1mbjogMDAwMDU5NWINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MzddICAgZ2Zu
OiAwMDAwNTk1YyAgbWZuOiAwMDAwNTk1Yw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoz
N10gICBnZm46IDAwMDA1OTVkICBtZm46IDAwMDA1OTVkDQoNCihYRU4pIFsyMDEyLTA4LTMx
IDIxOjMzOjM3XSAgIGdmbjogMDAwMDU5NWUgIG1mbjogMDAwMDU5NWUNCg0KKFhFTikgWzIw
MTItMDgtMzEgMjE6MzM6MzddICAgZ2ZuOiAwMDAwNTk1ZiAgbWZuOiAwMDAwNTk1Zg0KDQoo
WEVOKSBbMjAxMi0wOC0zMSAyMTozMzozN10gICBnZm46IDAwMDA1OTYwICBtZm46IDAwMDA1
OTYwDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjM3XSAgIGdmbjogMDAwMDU5NjEgIG1m
bjogMDAwMDU5NjENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MzddICAgZ2ZuOiAwMDAw
NTk2MiAgbWZuOiAwMDAwNTk2Mg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzozN10gICBn
Zm46IDAwMDA1OTYzICBtZm46IDAwMDA1OTYzDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMz
OjM3XSAgIGdmbjogMDAwMDU5NjQgIG1mbjogMDAwMDU5NjQNCg0KKFhFTikgWzIwMTItMDgt
MzEgMjE6MzM6MzddICAgZ2ZuOiAwMDAwNTk2NSAgbWZuOiAwMDAwNTk2NQ0KDQooWEVOKSBb
MjAxMi0wOC0zMSAyMTozMzozN10gICBnZm46IDAwMDA1OTY2ICBtZm46IDAwMDA1OTY2DQoN
CihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjM3XSAgIGdmbjogMDAwMDU5NjcgIG1mbjogMDAw
MDU5NjcNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MzddICAgZ2ZuOiAwMDAwNTk2OCAg
bWZuOiAwMDAwNTk2OA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzozN10gICBnZm46IDAw
MDA1OTY5ICBtZm46IDAwMDA1OTY5DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjM3XSAg
IGdmbjogMDAwMDU5NmEgIG1mbjogMDAwMDU5NmENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6
MzM6MzddICAgZ2ZuOiAwMDAwNTk2YiAgbWZuOiAwMDAwNTk2Yg0KDQooWEVOKSBbMjAxMi0w
OC0zMSAyMTozMzozN10gICBnZm46IDAwMDA1OTZjICBtZm46IDAwMDA1OTZjDQoNCihYRU4p
IFsyMDEyLTA4LTMxIDIxOjMzOjM3XSAgIGdmbjogMDAwMDU5NmQgIG1mbjogMDAwMDU5NmQN
Cg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MzddICAgZ2ZuOiAwMDAwNTk2ZSAgbWZuOiAw
MDAwNTk2ZQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzozN10gICBnZm46IDAwMDA1OTZm
ICBtZm46IDAwMDA1OTZmDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjM3XSAgIGdmbjog
MDAwMDU5NzAgIG1mbjogMDAwMDU5NzANCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6Mzdd
ICAgZ2ZuOiAwMDAwNTk3MSAgbWZuOiAwMDAwNTk3MQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAy
MTozMzozN10gICBnZm46IDAwMDA1OTcyICBtZm46IDAwMDA1OTcyDQoNCihYRU4pIFsyMDEy
LTA4LTMxIDIxOjMzOjM3XSAgIGdmbjogMDAwMDU5NzMgIG1mbjogMDAwMDU5NzMNCg0KKFhF
TikgWzIwMTItMDgtMzEgMjE6MzM6MzddICAgZ2ZuOiAwMDAwNTk3NCAgbWZuOiAwMDAwNTk3
NA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzozN10gICBnZm46IDAwMDA1OTc1ICBtZm46
IDAwMDA1OTc1DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjM3XSAgIGdmbjogMDAwMDU5
NzYgIG1mbjogMDAwMDU5NzYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MzddICAgZ2Zu
OiAwMDAwNTk3NyAgbWZuOiAwMDAwNTk3Nw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoz
N10gICBnZm46IDAwMDA1OTc4ICBtZm46IDAwMDA1OTc4DQoNCihYRU4pIFsyMDEyLTA4LTMx
IDIxOjMzOjM3XSAgIGdmbjogMDAwMDU5NzkgIG1mbjogMDAwMDU5NzkNCg0KKFhFTikgWzIw
MTItMDgtMzEgMjE6MzM6MzddICAgZ2ZuOiAwMDAwNTk3YSAgbWZuOiAwMDAwNTk3YQ0KDQoo
WEVOKSBbMjAxMi0wOC0zMSAyMTozMzozN10gICBnZm46IDAwMDA1OTdiICBtZm46IDAwMDA1
OTdiDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjM3XSAgIGdmbjogMDAwMDU5N2MgIG1m
bjogMDAwMDU5N2MNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MzddICAgZ2ZuOiAwMDAw
NTk3ZCAgbWZuOiAwMDAwNTk3ZA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzozN10gICBn
Zm46IDAwMDA1OTdlICBtZm46IDAwMDA1OTdlDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMz
OjM3XSAgIGdmbjogMDAwMDU5N2YgIG1mbjogMDAwMDU5N2YNCg0KKFhFTikgWzIwMTItMDgt
MzEgMjE6MzM6MzddICAgZ2ZuOiAwMDAwNTk4MCAgbWZuOiAwMDAwNTk4MA0KDQooWEVOKSBb
MjAxMi0wOC0zMSAyMTozMzozN10gICBnZm46IDAwMDA1OTgxICBtZm46IDAwMDA1OTgxDQoN
CihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjM3XSAgIGdmbjogMDAwMDU5ODIgIG1mbjogMDAw
MDU5ODINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MzddICAgZ2ZuOiAwMDAwNTk4MyAg
bWZuOiAwMDAwNTk4Mw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzozN10gICBnZm46IDAw
MDA1OTg0ICBtZm46IDAwMDA1OTg0DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjM3XSAg
IGdmbjogMDAwMDU5ODUgIG1mbjogMDAwMDU5ODUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6
MzM6MzddICAgZ2ZuOiAwMDAwNTk4NiAgbWZuOiAwMDAwNTk4Ng0KDQooWEVOKSBbMjAxMi0w
OC0zMSAyMTozMzozN10gICBnZm46IDAwMDA1OTg3ICBtZm46IDAwMDA1OTg3DQoNCihYRU4p
IFsyMDEyLTA4LTMxIDIxOjMzOjM3XSAgIGdmbjogMDAwMDU5ODggIG1mbjogMDAwMDU5ODgN
Cg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MzddICAgZ2ZuOiAwMDAwNTk4OSAgbWZuOiAw
MDAwNTk4OQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzozOF0gICBnZm46IDAwMDA1OThh
ICBtZm46IDAwMDA1OThhDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjM4XSAgIGdmbjog
MDAwMDU5OGIgIG1mbjogMDAwMDU5OGINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6Mzhd
ICAgZ2ZuOiAwMDAwNTk4YyAgbWZuOiAwMDAwNTk4Yw0KDQooWEVOKSBbMjAxMi0wOC0zMSAy
MTozMzozOF0gICBnZm46IDAwMDA1OThkICBtZm46IDAwMDA1OThkDQoNCihYRU4pIFsyMDEy
LTA4LTMxIDIxOjMzOjM4XSAgIGdmbjogMDAwMDU5OGUgIG1mbjogMDAwMDU5OGUNCg0KKFhF
TikgWzIwMTItMDgtMzEgMjE6MzM6MzhdICAgZ2ZuOiAwMDAwNTk4ZiAgbWZuOiAwMDAwNTk4
Zg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzozOF0gICBnZm46IDAwMDA1OTkwICBtZm46
IDAwMDA1OTkwDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjM4XSAgIGdmbjogMDAwMDU5
OTEgIG1mbjogMDAwMDU5OTENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MzhdICAgZ2Zu
OiAwMDAwNTk5MiAgbWZuOiAwMDAwNTk5Mg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoz
OF0gICBnZm46IDAwMDA1OTkzICBtZm46IDAwMDA1OTkzDQoNCihYRU4pIFsyMDEyLTA4LTMx
IDIxOjMzOjM4XSAgIGdmbjogMDAwMDU5OTQgIG1mbjogMDAwMDU5OTQNCg0KKFhFTikgWzIw
MTItMDgtMzEgMjE6MzM6MzhdICAgZ2ZuOiAwMDAwNTk5NSAgbWZuOiAwMDAwNTk5NQ0KDQoo
WEVOKSBbMjAxMi0wOC0zMSAyMTozMzozOF0gICBnZm46IDAwMDA1OTk2ICBtZm46IDAwMDA1
OTk2DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjM4XSAgIGdmbjogMDAwMDU5OTcgIG1m
bjogMDAwMDU5OTcNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MzhdICAgZ2ZuOiAwMDAw
NTk5OCAgbWZuOiAwMDAwNTk5OA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzozOF0gICBn
Zm46IDAwMDA1OTk5ICBtZm46IDAwMDA1OTk5DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMz
OjM4XSAgIGdmbjogMDAwMDU5OWEgIG1mbjogMDAwMDU5OWENCg0KKFhFTikgWzIwMTItMDgt
MzEgMjE6MzM6MzhdICAgZ2ZuOiAwMDAwNTk5YiAgbWZuOiAwMDAwNTk5Yg0KDQooWEVOKSBb
MjAxMi0wOC0zMSAyMTozMzozOF0gICBnZm46IDAwMDA1OTljICBtZm46IDAwMDA1OTljDQoN
CihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjM4XSAgIGdmbjogMDAwMDU5OWQgIG1mbjogMDAw
MDU5OWQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MzhdICAgZ2ZuOiAwMDAwNTk5ZSAg
bWZuOiAwMDAwNTk5ZQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzozOF0gICBnZm46IDAw
MDA1OTlmICBtZm46IDAwMDA1OTlmDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjM4XSAg
IGdmbjogMDAwMDU5YTAgIG1mbjogMDAwMDU5YTANCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6
MzM6MzhdICAgZ2ZuOiAwMDAwNTlhMSAgbWZuOiAwMDAwNTlhMQ0KDQooWEVOKSBbMjAxMi0w
OC0zMSAyMTozMzozOF0gICBnZm46IDAwMDA1OWEyICBtZm46IDAwMDA1OWEyDQoNCihYRU4p
IFsyMDEyLTA4LTMxIDIxOjMzOjM4XSAgIGdmbjogMDAwMDU5YTMgIG1mbjogMDAwMDU5YTMN
Cg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MzhdICAgZ2ZuOiAwMDAwNTlhNCAgbWZuOiAw
MDAwNTlhNA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzozOF0gICBnZm46IDAwMDA1OWE1
ICBtZm46IDAwMDA1OWE1DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjM4XSAgIGdmbjog
MDAwMDU5YTYgIG1mbjogMDAwMDU5YTYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6Mzhd
ICAgZ2ZuOiAwMDAwNTlhNyAgbWZuOiAwMDAwNTlhNw0KDQooWEVOKSBbMjAxMi0wOC0zMSAy
MTozMzozOF0gICBnZm46IDAwMDA1OWE4ICBtZm46IDAwMDA1OWE4DQoNCihYRU4pIFsyMDEy
LTA4LTMxIDIxOjMzOjM4XSAgIGdmbjogMDAwMDU5YTkgIG1mbjogMDAwMDU5YTkNCg0KKFhF
TikgWzIwMTItMDgtMzEgMjE6MzM6MzhdICAgZ2ZuOiAwMDAwNTlhYSAgbWZuOiAwMDAwNTlh
YQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzozOF0gICBnZm46IDAwMDA1OWFiICBtZm46
IDAwMDA1OWFiDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjM4XSAgIGdmbjogMDAwMDU5
YWMgIG1mbjogMDAwMDU5YWMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MzhdICAgZ2Zu
OiAwMDAwNTlhZCAgbWZuOiAwMDAwNTlhZA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoz
OF0gICBnZm46IDAwMDA1OWFlICBtZm46IDAwMDA1OWFlDQoNCihYRU4pIFsyMDEyLTA4LTMx
IDIxOjMzOjM4XSAgIGdmbjogMDAwMDU5YWYgIG1mbjogMDAwMDU5YWYNCg0KKFhFTikgWzIw
MTItMDgtMzEgMjE6MzM6MzhdICAgZ2ZuOiAwMDAwNTliMCAgbWZuOiAwMDAwNTliMA0KDQoo
WEVOKSBbMjAxMi0wOC0zMSAyMTozMzozOF0gICBnZm46IDAwMDA1OWIxICBtZm46IDAwMDA1
OWIxDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjM4XSAgIGdmbjogMDAwMDU5YjIgIG1m
bjogMDAwMDU5YjINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MzhdICAgZ2ZuOiAwMDAw
NTliMyAgbWZuOiAwMDAwNTliMw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzozOF0gICBn
Zm46IDAwMDA1OWI0ICBtZm46IDAwMDA1OWI0DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMz
OjM4XSAgIGdmbjogMDAwMDU5YjUgIG1mbjogMDAwMDU5YjUNCg0KKFhFTikgWzIwMTItMDgt
MzEgMjE6MzM6MzhdICAgZ2ZuOiAwMDAwNTliNiAgbWZuOiAwMDAwNTliNg0KDQooWEVOKSBb
MjAxMi0wOC0zMSAyMTozMzozOF0gICBnZm46IDAwMDA1OWI3ICBtZm46IDAwMDA1OWI3DQoN
CihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjM4XSAgIGdmbjogMDAwMDU5YjggIG1mbjogMDAw
MDU5YjgNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MzhdICAgZ2ZuOiAwMDAwNTliOSAg
bWZuOiAwMDAwNTliOQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzozOF0gICBnZm46IDAw
MDA1OWJhICBtZm46IDAwMDA1OWJhDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjM4XSAg
IGdmbjogMDAwMDU5YmIgIG1mbjogMDAwMDU5YmINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6
MzM6MzhdICAgZ2ZuOiAwMDAwNTliYyAgbWZuOiAwMDAwNTliYw0KDQooWEVOKSBbMjAxMi0w
OC0zMSAyMTozMzozOF0gICBnZm46IDAwMDA1OWJkICBtZm46IDAwMDA1OWJkDQoNCihYRU4p
IFsyMDEyLTA4LTMxIDIxOjMzOjM4XSAgIGdmbjogMDAwMDU5YmUgIG1mbjogMDAwMDU5YmUN
Cg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MzhdICAgZ2ZuOiAwMDAwNTliZiAgbWZuOiAw
MDAwNTliZg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzozOF0gICBnZm46IDAwMDA1OWMw
ICBtZm46IDAwMDA1OWMwDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjM4XSAgIGdmbjog
MDAwMDU5YzEgIG1mbjogMDAwMDU5YzENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6Mzhd
ICAgZ2ZuOiAwMDAwNTljMiAgbWZuOiAwMDAwNTljMg0KDQooWEVOKSBbMjAxMi0wOC0zMSAy
MTozMzozOF0gICBnZm46IDAwMDA1OWMzICBtZm46IDAwMDA1OWMzDQoNCihYRU4pIFsyMDEy
LTA4LTMxIDIxOjMzOjM4XSAgIGdmbjogMDAwMDU5YzQgIG1mbjogMDAwMDU5YzQNCg0KKFhF
TikgWzIwMTItMDgtMzEgMjE6MzM6MzhdICAgZ2ZuOiAwMDAwNTljNSAgbWZuOiAwMDAwNTlj
NQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzozOF0gICBnZm46IDAwMDA1OWM2ICBtZm46
IDAwMDA1OWM2DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjM4XSAgIGdmbjogMDAwMDU5
YzcgIG1mbjogMDAwMDU5YzcNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MzhdICAgZ2Zu
OiAwMDAwNTljOCAgbWZuOiAwMDAwNTljOA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoz
OF0gICBnZm46IDAwMDA1OWM5ICBtZm46IDAwMDA1OWM5DQoNCihYRU4pIFsyMDEyLTA4LTMx
IDIxOjMzOjM4XSAgIGdmbjogMDAwMDU5Y2EgIG1mbjogMDAwMDU5Y2ENCg0KKFhFTikgWzIw
MTItMDgtMzEgMjE6MzM6MzldICAgZ2ZuOiAwMDAwNTljYiAgbWZuOiAwMDAwNTljYg0KDQoo
WEVOKSBbMjAxMi0wOC0zMSAyMTozMzozOV0gICBnZm46IDAwMDA1OWNjICBtZm46IDAwMDA1
OWNjDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjM5XSAgIGdmbjogMDAwMDU5Y2QgIG1m
bjogMDAwMDU5Y2QNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MzldICAgZ2ZuOiAwMDAw
NTljZSAgbWZuOiAwMDAwNTljZQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzozOV0gICBn
Zm46IDAwMDA1OWNmICBtZm46IDAwMDA1OWNmDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMz
OjM5XSAgIGdmbjogMDAwMDU5ZDAgIG1mbjogMDAwMDU5ZDANCg0KKFhFTikgWzIwMTItMDgt
MzEgMjE6MzM6MzldICAgZ2ZuOiAwMDAwNTlkMSAgbWZuOiAwMDAwNTlkMQ0KDQooWEVOKSBb
MjAxMi0wOC0zMSAyMTozMzozOV0gICBnZm46IDAwMDA1OWQyICBtZm46IDAwMDA1OWQyDQoN
CihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjM5XSAgIGdmbjogMDAwMDU5ZDMgIG1mbjogMDAw
MDU5ZDMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MzldICAgZ2ZuOiAwMDAwNTlkNCAg
bWZuOiAwMDAwNTlkNA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzozOV0gICBnZm46IDAw
MDA1OWQ1ICBtZm46IDAwMDA1OWQ1DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjM5XSAg
IGdmbjogMDAwMDU5ZDYgIG1mbjogMDAwMDU5ZDYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6
MzM6MzldICAgZ2ZuOiAwMDAwNTlkNyAgbWZuOiAwMDAwNTlkNw0KDQooWEVOKSBbMjAxMi0w
OC0zMSAyMTozMzozOV0gICBnZm46IDAwMDA1OWQ4ICBtZm46IDAwMDA1OWQ4DQoNCihYRU4p
IFsyMDEyLTA4LTMxIDIxOjMzOjM5XSAgIGdmbjogMDAwMDU5ZDkgIG1mbjogMDAwMDU5ZDkN
Cg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MzldICAgZ2ZuOiAwMDAwNTlkYSAgbWZuOiAw
MDAwNTlkYQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzozOV0gICBnZm46IDAwMDA1OWRi
ICBtZm46IDAwMDA1OWRiDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjM5XSAgIGdmbjog
MDAwMDU5ZGMgIG1mbjogMDAwMDU5ZGMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6Mzld
ICAgZ2ZuOiAwMDAwNTlkZCAgbWZuOiAwMDAwNTlkZA0KDQooWEVOKSBbMjAxMi0wOC0zMSAy
MTozMzozOV0gICBnZm46IDAwMDA1OWRlICBtZm46IDAwMDA1OWRlDQoNCihYRU4pIFsyMDEy
LTA4LTMxIDIxOjMzOjM5XSAgIGdmbjogMDAwMDU5ZGYgIG1mbjogMDAwMDU5ZGYNCg0KKFhF
TikgWzIwMTItMDgtMzEgMjE6MzM6MzldICAgZ2ZuOiAwMDAwNTllMCAgbWZuOiAwMDAwNTll
MA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzozOV0gICBnZm46IDAwMDA1OWUxICBtZm46
IDAwMDA1OWUxDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjM5XSAgIGdmbjogMDAwMDU5
ZTIgIG1mbjogMDAwMDU5ZTINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MzldICAgZ2Zu
OiAwMDAwNTllMyAgbWZuOiAwMDAwNTllMw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoz
OV0gICBnZm46IDAwMDA1OWU0ICBtZm46IDAwMDA1OWU0DQoNCihYRU4pIFsyMDEyLTA4LTMx
IDIxOjMzOjM5XSAgIGdmbjogMDAwMDU5ZTUgIG1mbjogMDAwMDU5ZTUNCg0KKFhFTikgWzIw
MTItMDgtMzEgMjE6MzM6MzldICAgZ2ZuOiAwMDAwNTllNiAgbWZuOiAwMDAwNTllNg0KDQoo
WEVOKSBbMjAxMi0wOC0zMSAyMTozMzozOV0gICBnZm46IDAwMDA1OWU3ICBtZm46IDAwMDA1
OWU3DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjM5XSAgIGdmbjogMDAwMDU5ZTggIG1m
bjogMDAwMDU5ZTgNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MzldICAgZ2ZuOiAwMDAw
NTllOSAgbWZuOiAwMDAwNTllOQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzozOV0gICBn
Zm46IDAwMDA1OWVhICBtZm46IDAwMDA1OWVhDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMz
OjM5XSAgIGdmbjogMDAwMDU5ZWIgIG1mbjogMDAwMDU5ZWINCg0KKFhFTikgWzIwMTItMDgt
MzEgMjE6MzM6MzldICAgZ2ZuOiAwMDAwNTllYyAgbWZuOiAwMDAwNTllYw0KDQooWEVOKSBb
MjAxMi0wOC0zMSAyMTozMzozOV0gICBnZm46IDAwMDA1OWVkICBtZm46IDAwMDA1OWVkDQoN
CihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjM5XSAgIGdmbjogMDAwMDU5ZWUgIG1mbjogMDAw
MDU5ZWUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MzldICAgZ2ZuOiAwMDAwNTllZiAg
bWZuOiAwMDAwNTllZg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzozOV0gICBnZm46IDAw
MDA1OWYwICBtZm46IDAwMDA1OWYwDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjM5XSAg
IGdmbjogMDAwMDU5ZjEgIG1mbjogMDAwMDU5ZjENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6
MzM6MzldICAgZ2ZuOiAwMDAwNTlmMiAgbWZuOiAwMDAwNTlmMg0KDQpbICA0ODUuNjIzNzkz
XSBhKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MzldICAgZ2ZuOiAwMDAwNTlmMyAgbWZuOiAw
MDAwNTlmMw0KDQp0YTMuMDA6IHFjIHRpbWVvKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6Mzld
ICAgZ2ZuOiAwMDAwNTlmNCAgbWZuOiAwMDAwNTlmNA0KDQp1dCAoY21kIDB4ZWMpDQoNCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MzldICAgZ2ZuOiAwMDAwNTlmNSAgbWZuOiAwMDAw
NTlmNQ0KDQpbICA0ODUuNjgxOTg0XSBhdGEzLjAwOiBmYWlsZWQgdChYRU4pIFsyMDEyLTA4
LTMxIDIxOjMzOjM5XSAgIGdmbjogMDAwMDU5ZjYgIG1mbjogMDAwMDU5ZjYNCg0KbyBJREVO
VElGWSAoSS9PIChYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjM5XSAgIGdmbjogMDAwMDU5Zjcg
IG1mbjogMDAwMDU5ZjcNCg0KZXJyb3IsIGVycl9tYXNrPTB4NCkNCg0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMzozOV0gICBnZm46IDAwMDA1OWY4ICBtZm46IDAwMDA1OWY4DQoNClsg
IDQ4NS43NDg1MzBdIGEoWEVOKSBbMjAxMi0wOC0zMSAyMTozMzozOV0gICBnZm46IDAwMDA1
OWY5ICBtZm46IDAwMDA1OWY5DQoNCnRhMy4wMDogcmV2YWxpZGF0aW9uIGZhaWxlZCAoZXJy
KFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MzldICAgZ2ZuOiAwMDAwNTlmYSAgbWZuOiAwMDAw
NTlmYQ0KDQpubz0tNSkNCg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzozOV0gICBnZm46
IDAwMDA1OWZiICBtZm46IDAwMDA1OWZiDQoNClsgIDQ4NS44MTA5MjBdIGF0YTM6IGhhcmQg
cmVzZXR0KFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MzldICAgZ2ZuOiAwMDAwNTlmYyAgbWZu
OiAwMDAwNTlmYw0KDQppbmcgbGluaw0KDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjM5
XSAgIGdmbjogMDAwMDU5ZmQgIG1mbjogMDAwMDU5ZmQNCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzM6MzldICAgZ2ZuOiAwMDAwNTlmZSAgbWZuOiAwMDAwNTlmZQ0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMzozOV0gICBnZm46IDAwMDA1OWZmICBtZm46IDAwMDA1OWZmDQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMzOjM5XSAgIGdmbjogMDAwMDVhMDAgIG1mbjogMDAwMDVh
MDANCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MzldICAgZ2ZuOiAwMDAwNWEwMSAgbWZu
OiAwMDAwNWEwMQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzozOV0gICBnZm46IDAwMDA1
YTAyICBtZm46IDAwMDA1YTAyDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjM5XSAgIGdm
bjogMDAwMDVhMDMgIG1mbjogMDAwMDVhMDMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6
MzldICAgZ2ZuOiAwMDAwNWEwNCAgbWZuOiAwMDAwNWEwNA0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMzozOV0gICBnZm46IDAwMDA1YTA1ICBtZm46IDAwMDA1YTA1DQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMzOjM5XSAgIGdmbjogMDAwMDVhMDYgIG1mbjogMDAwMDVhMDYNCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NDBdICAgZ2ZuOiAwMDAwNWEwNyAgbWZuOiAwMDAw
NWEwNw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo0MF0gICBnZm46IDAwMDA1YTA4ICBt
Zm46IDAwMDA1YTA4DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjQwXSAgIGdmbjogMDAw
MDVhMDkgIG1mbjogMDAwMDVhMDkNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NDBdICAg
Z2ZuOiAwMDAwNWEwYSAgbWZuOiAwMDAwNWEwYQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
Mzo0MF0gICBnZm46IDAwMDA1YTBiICBtZm46IDAwMDA1YTBiDQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMzOjQwXSAgIGdmbjogMDAwMDVhMGMgIG1mbjogMDAwMDVhMGMNCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzM6NDBdICAgZ2ZuOiAwMDAwNWEwZCAgbWZuOiAwMDAwNWEwZA0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo0MF0gICBnZm46IDAwMDA1YTBlICBtZm46IDAw
MDA1YTBlDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjQwXSAgIGdmbjogMDAwMDVhMGYg
IG1mbjogMDAwMDVhMGYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NDBdICAgZ2ZuOiAw
MDAwNWExMCAgbWZuOiAwMDAwNWExMA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo0MF0g
ICBnZm46IDAwMDA1YTExICBtZm46IDAwMDA1YTExDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMzOjQwXSAgIGdmbjogMDAwMDVhMTIgIG1mbjogMDAwMDVhMTINCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzM6NDBdICAgZ2ZuOiAwMDAwNWExMyAgbWZuOiAwMDAwNWExMw0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMzo0MF0gICBnZm46IDAwMDA1YTE0ICBtZm46IDAwMDA1YTE0
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjQwXSAgIGdmbjogMDAwMDVhMTUgIG1mbjog
MDAwMDVhMTUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NDBdICAgZ2ZuOiAwMDAwNWEx
NiAgbWZuOiAwMDAwNWExNg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo0MF0gICBnZm46
IDAwMDA1YTE3ICBtZm46IDAwMDA1YTE3DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjQw
XSAgIGdmbjogMDAwMDVhMTggIG1mbjogMDAwMDVhMTgNCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzM6NDBdICAgZ2ZuOiAwMDAwNWExOSAgbWZuOiAwMDAwNWExOQ0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMzo0MF0gICBnZm46IDAwMDA1YTFhICBtZm46IDAwMDA1YTFhDQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMzOjQwXSAgIGdmbjogMDAwMDVhMWIgIG1mbjogMDAwMDVh
MWINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NDBdICAgZ2ZuOiAwMDAwNWExYyAgbWZu
OiAwMDAwNWExYw0KDQpbICA0ODYuMzQyMDYxXSBhKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6
NDBdICAgZ2ZuOiAwMDAwNWExZCAgbWZuOiAwMDAwNWExZA0KDQp0YTM6IFNBVEEgbGluayB1
KFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NDBdICAgZ2ZuOiAwMDAwNWExZSAgbWZuOiAwMDAw
NWExZQ0KDQpwIDYuMCBHYnBzIChTU3RhKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NDBdICAg
Z2ZuOiAwMDAwNWExZiAgbWZuOiAwMDAwNWExZg0KDQp0dXMgMTMzIFNDb250cm9sIDMwMCkN
Cg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo0MF0gICBnZm46IDAwMDA1YTIwICBtZm46
IDAwMDA1YTIwDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjQwXSAgIGdmbjogMDAwMDVh
MjEgIG1mbjogMDAwMDVhMjENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NDBdICAgZ2Zu
OiAwMDAwNWEyMiAgbWZuOiAwMDAwNWEyMg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo0
MF0gICBnZm46IDAwMDA1YTIzICBtZm46IDAwMDA1YTIzDQoNCihYRU4pIFsyMDEyLTA4LTMx
IDIxOjMzOjQwXSAgIGdmbjogMDAwMDVhMjQgIG1mbjogMDAwMDVhMjQNCg0KKFhFTikgWzIw
MTItMDgtMzEgMjE6MzM6NDBdICAgZ2ZuOiAwMDAwNWEyNSAgbWZuOiAwMDAwNWEyNQ0KDQoo
WEVOKSBbMjAxMi0wOC0zMSAyMTozMzo0MF0gICBnZm46IDAwMDA1YTI2ICBtZm46IDAwMDA1
YTI2DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjQwXSAgIGdmbjogMDAwMDVhMjcgIG1m
bjogMDAwMDVhMjcNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NDBdICAgZ2ZuOiAwMDAw
NWEyOCAgbWZuOiAwMDAwNWEyOA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo0MF0gICBn
Zm46IDAwMDA1YTI5ICBtZm46IDAwMDA1YTI5DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMz
OjQwXSAgIGdmbjogMDAwMDVhMmEgIG1mbjogMDAwMDVhMmENCg0KKFhFTikgWzIwMTItMDgt
MzEgMjE6MzM6NDBdICAgZ2ZuOiAwMDAwNWEyYiAgbWZuOiAwMDAwNWEyYg0KDQooWEVOKSBb
MjAxMi0wOC0zMSAyMTozMzo0MF0gICBnZm46IDAwMDA1YTJjICBtZm46IDAwMDA1YTJjDQoN
CihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjQwXSAgIGdmbjogMDAwMDVhMmQgIG1mbjogMDAw
MDVhMmQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NDBdICAgZ2ZuOiAwMDAwNWEyZSAg
bWZuOiAwMDAwNWEyZQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo0MF0gICBnZm46IDAw
MDA1YTJmICBtZm46IDAwMDA1YTJmDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjQwXSAg
IGdmbjogMDAwMDVhMzAgIG1mbjogMDAwMDVhMzANCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6
MzM6NDBdICAgZ2ZuOiAwMDAwNWEzMSAgbWZuOiAwMDAwNWEzMQ0KDQooWEVOKSBbMjAxMi0w
OC0zMSAyMTozMzo0MF0gICBnZm46IDAwMDA1YTMyICBtZm46IDAwMDA1YTMyDQoNCihYRU4p
IFsyMDEyLTA4LTMxIDIxOjMzOjQwXSAgIGdmbjogMDAwMDVhMzMgIG1mbjogMDAwMDVhMzMN
Cg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NDBdICAgZ2ZuOiAwMDAwNWEzNCAgbWZuOiAw
MDAwNWEzNA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo0MF0gICBnZm46IDAwMDA1YTM1
ICBtZm46IDAwMDA1YTM1DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjQwXSAgIGdmbjog
MDAwMDVhMzYgIG1mbjogMDAwMDVhMzYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NDBd
ICAgZ2ZuOiAwMDAwNWEzNyAgbWZuOiAwMDAwNWEzNw0KDQooWEVOKSBbMjAxMi0wOC0zMSAy
MTozMzo0MF0gICBnZm46IDAwMDA1YTM4ICBtZm46IDAwMDA1YTM4DQoNCihYRU4pIFsyMDEy
LTA4LTMxIDIxOjMzOjQwXSAgIGdmbjogMDAwMDVhMzkgIG1mbjogMDAwMDVhMzkNCg0KKFhF
TikgWzIwMTItMDgtMzEgMjE6MzM6NDBdICAgZ2ZuOiAwMDAwNWEzYSAgbWZuOiAwMDAwNWEz
YQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo0MF0gICBnZm46IDAwMDA1YTNiICBtZm46
IDAwMDA1YTNiDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjQwXSAgIGdmbjogMDAwMDVh
M2MgIG1mbjogMDAwMDVhM2MNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NDBdICAgZ2Zu
OiAwMDAwNWEzZCAgbWZuOiAwMDAwNWEzZA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo0
MF0gICBnZm46IDAwMDA1YTNlICBtZm46IDAwMDA1YTNlDQoNCihYRU4pIFsyMDEyLTA4LTMx
IDIxOjMzOjQwXSAgIGdmbjogMDAwMDVhM2YgIG1mbjogMDAwMDVhM2YNCg0KKFhFTikgWzIw
MTItMDgtMzEgMjE6MzM6NDBdICAgZ2ZuOiAwMDAwNWE0MCAgbWZuOiAwMDAwNWE0MA0KDQoo
WEVOKSBbMjAxMi0wOC0zMSAyMTozMzo0MF0gICBnZm46IDAwMDA1YTQxICBtZm46IDAwMDA1
YTQxDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjQwXSAgIGdmbjogMDAwMDVhNDIgIG1m
bjogMDAwMDVhNDINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NDBdICAgZ2ZuOiAwMDAw
NWE0MyAgbWZuOiAwMDAwNWE0Mw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo0MF0gICBn
Zm46IDAwMDA1YTQ0ICBtZm46IDAwMDA1YTQ0DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMz
OjQwXSAgIGdmbjogMDAwMDVhNDUgIG1mbjogMDAwMDVhNDUNCg0KKFhFTikgWzIwMTItMDgt
MzEgMjE6MzM6NDFdICAgZ2ZuOiAwMDAwNWE0NiAgbWZuOiAwMDAwNWE0Ng0KDQooWEVOKSBb
MjAxMi0wOC0zMSAyMTozMzo0MV0gICBnZm46IDAwMDA1YTQ3ICBtZm46IDAwMDA1YTQ3DQoN
CihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjQxXSAgIGdmbjogMDAwMDVhNDggIG1mbjogMDAw
MDVhNDgNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NDFdICAgZ2ZuOiAwMDAwNWE0OSAg
bWZuOiAwMDAwNWE0OQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo0MV0gICBnZm46IDAw
MDA1YTRhICBtZm46IDAwMDA1YTRhDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjQxXSAg
IGdmbjogMDAwMDVhNGIgIG1mbjogMDAwMDVhNGINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6
MzM6NDFdICAgZ2ZuOiAwMDAwNWE0YyAgbWZuOiAwMDAwNWE0Yw0KDQooWEVOKSBbMjAxMi0w
OC0zMSAyMTozMzo0MV0gICBnZm46IDAwMDA1YTRkICBtZm46IDAwMDA1YTRkDQoNCihYRU4p
IFsyMDEyLTA4LTMxIDIxOjMzOjQxXSAgIGdmbjogMDAwMDVhNGUgIG1mbjogMDAwMDVhNGUN
Cg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NDFdICAgZ2ZuOiAwMDAwNWE0ZiAgbWZuOiAw
MDAwNWE0Zg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo0MV0gICBnZm46IDAwMDA1YTUw
ICBtZm46IDAwMDA1YTUwDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjQxXSAgIGdmbjog
MDAwMDVhNTEgIG1mbjogMDAwMDVhNTENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NDFd
ICAgZ2ZuOiAwMDAwNWE1MiAgbWZuOiAwMDAwNWE1Mg0KDQooWEVOKSBbMjAxMi0wOC0zMSAy
MTozMzo0MV0gICBnZm46IDAwMDA1YTUzICBtZm46IDAwMDA1YTUzDQoNCihYRU4pIFsyMDEy
LTA4LTMxIDIxOjMzOjQxXSAgIGdmbjogMDAwMDVhNTQgIG1mbjogMDAwMDVhNTQNCg0KKFhF
TikgWzIwMTItMDgtMzEgMjE6MzM6NDFdICAgZ2ZuOiAwMDAwNWE1NSAgbWZuOiAwMDAwNWE1
NQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo0MV0gICBnZm46IDAwMDA1YTU2ICBtZm46
IDAwMDA1YTU2DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjQxXSAgIGdmbjogMDAwMDVh
NTcgIG1mbjogMDAwMDVhNTcNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NDFdICAgZ2Zu
OiAwMDAwNWE1OCAgbWZuOiAwMDAwNWE1OA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo0
MV0gICBnZm46IDAwMDA1YTU5ICBtZm46IDAwMDA1YTU5DQoNCihYRU4pIFsyMDEyLTA4LTMx
IDIxOjMzOjQxXSAgIGdmbjogMDAwMDVhNWEgIG1mbjogMDAwMDVhNWENCg0KKFhFTikgWzIw
MTItMDgtMzEgMjE6MzM6NDFdICAgZ2ZuOiAwMDAwNWE1YiAgbWZuOiAwMDAwNWE1Yg0KDQoo
WEVOKSBbMjAxMi0wOC0zMSAyMTozMzo0MV0gICBnZm46IDAwMDA1YTVjICBtZm46IDAwMDA1
YTVjDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjQxXSAgIGdmbjogMDAwMDVhNWQgIG1m
bjogMDAwMDVhNWQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NDFdICAgZ2ZuOiAwMDAw
NWE1ZSAgbWZuOiAwMDAwNWE1ZQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo0MV0gICBn
Zm46IDAwMDA1YTVmICBtZm46IDAwMDA1YTVmDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMz
OjQxXSAgIGdmbjogMDAwMDVhNjAgIG1mbjogMDAwMDVhNjANCg0KKFhFTikgWzIwMTItMDgt
MzEgMjE6MzM6NDFdICAgZ2ZuOiAwMDAwNWE2MSAgbWZuOiAwMDAwNWE2MQ0KDQooWEVOKSBb
MjAxMi0wOC0zMSAyMTozMzo0MV0gICBnZm46IDAwMDA1YTYyICBtZm46IDAwMDA1YTYyDQoN
CihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjQxXSAgIGdmbjogMDAwMDVhNjMgIG1mbjogMDAw
MDVhNjMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NDFdICAgZ2ZuOiAwMDAwNWE2NCAg
bWZuOiAwMDAwNWE2NA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo0MV0gICBnZm46IDAw
MDA1YTY1ICBtZm46IDAwMDA1YTY1DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjQxXSAg
IGdmbjogMDAwMDVhNjYgIG1mbjogMDAwMDVhNjYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6
MzM6NDFdICAgZ2ZuOiAwMDAwNWE2NyAgbWZuOiAwMDAwNWE2Nw0KDQooWEVOKSBbMjAxMi0w
OC0zMSAyMTozMzo0MV0gICBnZm46IDAwMDA1YTY4ICBtZm46IDAwMDA1YTY4DQoNCihYRU4p
IFsyMDEyLTA4LTMxIDIxOjMzOjQxXSAgIGdmbjogMDAwMDVhNjkgIG1mbjogMDAwMDVhNjkN
Cg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NDFdICAgZ2ZuOiAwMDAwNWE2YSAgbWZuOiAw
MDAwNWE2YQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo0MV0gICBnZm46IDAwMDA1YTZi
ICBtZm46IDAwMDA1YTZiDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjQxXSAgIGdmbjog
MDAwMDVhNmMgIG1mbjogMDAwMDVhNmMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NDFd
ICAgZ2ZuOiAwMDAwNWE2ZCAgbWZuOiAwMDAwNWE2ZA0KDQooWEVOKSBbMjAxMi0wOC0zMSAy
MTozMzo0MV0gICBnZm46IDAwMDA1YTZlICBtZm46IDAwMDA1YTZlDQoNCihYRU4pIFsyMDEy
LTA4LTMxIDIxOjMzOjQxXSAgIGdmbjogMDAwMDVhNmYgIG1mbjogMDAwMDVhNmYNCg0KKFhF
TikgWzIwMTItMDgtMzEgMjE6MzM6NDFdICAgZ2ZuOiAwMDAwNWE3MCAgbWZuOiAwMDAwNWE3
MA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo0MV0gICBnZm46IDAwMDA1YTcxICBtZm46
IDAwMDA1YTcxDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjQxXSAgIGdmbjogMDAwMDVh
NzIgIG1mbjogMDAwMDVhNzINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NDFdICAgZ2Zu
OiAwMDAwNWE3MyAgbWZuOiAwMDAwNWE3Mw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo0
MV0gICBnZm46IDAwMDA1YTc0ICBtZm46IDAwMDA1YTc0DQoNCihYRU4pIFsyMDEyLTA4LTMx
IDIxOjMzOjQxXSAgIGdmbjogMDAwMDVhNzUgIG1mbjogMDAwMDVhNzUNCg0KKFhFTikgWzIw
MTItMDgtMzEgMjE6MzM6NDFdICAgZ2ZuOiAwMDAwNWE3NiAgbWZuOiAwMDAwNWE3Ng0KDQoo
WEVOKSBbMjAxMi0wOC0zMSAyMTozMzo0MV0gICBnZm46IDAwMDA1YTc3ICBtZm46IDAwMDA1
YTc3DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjQxXSAgIGdmbjogMDAwMDVhNzggIG1m
bjogMDAwMDVhNzgNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NDFdICAgZ2ZuOiAwMDAw
NWE3OSAgbWZuOiAwMDAwNWE3OQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo0MV0gICBn
Zm46IDAwMDA1YTdhICBtZm46IDAwMDA1YTdhDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMz
OjQxXSAgIGdmbjogMDAwMDVhN2IgIG1mbjogMDAwMDVhN2INCg0KKFhFTikgWzIwMTItMDgt
MzEgMjE6MzM6NDFdICAgZ2ZuOiAwMDAwNWE3YyAgbWZuOiAwMDAwNWE3Yw0KDQooWEVOKSBb
MjAxMi0wOC0zMSAyMTozMzo0MV0gICBnZm46IDAwMDA1YTdkICBtZm46IDAwMDA1YTdkDQoN
CihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjQxXSAgIGdmbjogMDAwMDVhN2UgIG1mbjogMDAw
MDVhN2UNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NDFdICAgZ2ZuOiAwMDAwNWE3ZiAg
bWZuOiAwMDAwNWE3Zg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo0MV0gICBnZm46IDAw
MDA1YTgwICBtZm46IDAwMDA1YTgwDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjQxXSAg
IGdmbjogMDAwMDVhODEgIG1mbjogMDAwMDVhODENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6
MzM6NDFdICAgZ2ZuOiAwMDAwNWE4MiAgbWZuOiAwMDAwNWE4Mg0KDQooWEVOKSBbMjAxMi0w
OC0zMSAyMTozMzo0MV0gICBnZm46IDAwMDA1YTgzICBtZm46IDAwMDA1YTgzDQoNCihYRU4p
IFsyMDEyLTA4LTMxIDIxOjMzOjQxXSAgIGdmbjogMDAwMDVhODQgIG1mbjogMDAwMDVhODQN
Cg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NDFdICAgZ2ZuOiAwMDAwNWE4NSAgbWZuOiAw
MDAwNWE4NQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo0Ml0gICBnZm46IDAwMDA1YTg2
ICBtZm46IDAwMDA1YTg2DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjQyXSAgIGdmbjog
MDAwMDVhODcgIG1mbjogMDAwMDVhODcNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NDJd
ICAgZ2ZuOiAwMDAwNWE4OCAgbWZuOiAwMDAwNWE4OA0KDQooWEVOKSBbMjAxMi0wOC0zMSAy
MTozMzo0Ml0gICBnZm46IDAwMDA1YTg5ICBtZm46IDAwMDA1YTg5DQoNCihYRU4pIFsyMDEy
LTA4LTMxIDIxOjMzOjQyXSAgIGdmbjogMDAwMDVhOGEgIG1mbjogMDAwMDVhOGENCg0KKFhF
TikgWzIwMTItMDgtMzEgMjE6MzM6NDJdICAgZ2ZuOiAwMDAwNWE4YiAgbWZuOiAwMDAwNWE4
Yg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo0Ml0gICBnZm46IDAwMDA1YThjICBtZm46
IDAwMDA1YThjDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjQyXSAgIGdmbjogMDAwMDVh
OGQgIG1mbjogMDAwMDVhOGQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NDJdICAgZ2Zu
OiAwMDAwNWE4ZSAgbWZuOiAwMDAwNWE4ZQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo0
Ml0gICBnZm46IDAwMDA1YThmICBtZm46IDAwMDA1YThmDQoNCihYRU4pIFsyMDEyLTA4LTMx
IDIxOjMzOjQyXSAgIGdmbjogMDAwMDVhOTAgIG1mbjogMDAwMDVhOTANCg0KKFhFTikgWzIw
MTItMDgtMzEgMjE6MzM6NDJdICAgZ2ZuOiAwMDAwNWE5MSAgbWZuOiAwMDAwNWE5MQ0KDQoo
WEVOKSBbMjAxMi0wOC0zMSAyMTozMzo0Ml0gICBnZm46IDAwMDA1YTkyICBtZm46IDAwMDA1
YTkyDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjQyXSAgIGdmbjogMDAwMDVhOTMgIG1m
bjogMDAwMDVhOTMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NDJdICAgZ2ZuOiAwMDAw
NWE5NCAgbWZuOiAwMDAwNWE5NA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo0Ml0gICBn
Zm46IDAwMDA1YTk1ICBtZm46IDAwMDA1YTk1DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMz
OjQyXSAgIGdmbjogMDAwMDVhOTYgIG1mbjogMDAwMDVhOTYNCg0KKFhFTikgWzIwMTItMDgt
MzEgMjE6MzM6NDJdICAgZ2ZuOiAwMDAwNWE5NyAgbWZuOiAwMDAwNWE5Nw0KDQooWEVOKSBb
MjAxMi0wOC0zMSAyMTozMzo0Ml0gICBnZm46IDAwMDA1YTk4ICBtZm46IDAwMDA1YTk4DQoN
CihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjQyXSAgIGdmbjogMDAwMDVhOTkgIG1mbjogMDAw
MDVhOTkNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NDJdICAgZ2ZuOiAwMDAwNWE5YSAg
bWZuOiAwMDAwNWE5YQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo0Ml0gICBnZm46IDAw
MDA1YTliICBtZm46IDAwMDA1YTliDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjQyXSAg
IGdmbjogMDAwMDVhOWMgIG1mbjogMDAwMDVhOWMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6
MzM6NDJdICAgZ2ZuOiAwMDAwNWE5ZCAgbWZuOiAwMDAwNWE5ZA0KDQooWEVOKSBbMjAxMi0w
OC0zMSAyMTozMzo0Ml0gICBnZm46IDAwMDA1YTllICBtZm46IDAwMDA1YTllDQoNCihYRU4p
IFsyMDEyLTA4LTMxIDIxOjMzOjQyXSAgIGdmbjogMDAwMDVhOWYgIG1mbjogMDAwMDVhOWYN
Cg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NDJdICAgZ2ZuOiAwMDAwNWFhMCAgbWZuOiAw
MDAwNWFhMA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo0Ml0gICBnZm46IDAwMDA1YWEx
ICBtZm46IDAwMDA1YWExDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjQyXSAgIGdmbjog
MDAwMDVhYTIgIG1mbjogMDAwMDVhYTINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NDJd
ICAgZ2ZuOiAwMDAwNWFhMyAgbWZuOiAwMDAwNWFhMw0KDQooWEVOKSBbMjAxMi0wOC0zMSAy
MTozMzo0Ml0gICBnZm46IDAwMDA1YWE0ICBtZm46IDAwMDA1YWE0DQoNCihYRU4pIFsyMDEy
LTA4LTMxIDIxOjMzOjQyXSAgIGdmbjogMDAwMDVhYTUgIG1mbjogMDAwMDVhYTUNCg0KKFhF
TikgWzIwMTItMDgtMzEgMjE6MzM6NDJdICAgZ2ZuOiAwMDAwNWFhNiAgbWZuOiAwMDAwNWFh
Ng0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo0Ml0gICBnZm46IDAwMDA1YWE3ICBtZm46
IDAwMDA1YWE3DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjQyXSAgIGdmbjogMDAwMDVh
YTggIG1mbjogMDAwMDVhYTgNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NDJdICAgZ2Zu
OiAwMDAwNWFhOSAgbWZuOiAwMDAwNWFhOQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo0
Ml0gICBnZm46IDAwMDA1YWFhICBtZm46IDAwMDA1YWFhDQoNCihYRU4pIFsyMDEyLTA4LTMx
IDIxOjMzOjQyXSAgIGdmbjogMDAwMDVhYWIgIG1mbjogMDAwMDVhYWINCg0KKFhFTikgWzIw
MTItMDgtMzEgMjE6MzM6NDJdICAgZ2ZuOiAwMDAwNWFhYyAgbWZuOiAwMDAwNWFhYw0KDQoo
WEVOKSBbMjAxMi0wOC0zMSAyMTozMzo0Ml0gICBnZm46IDAwMDA1YWFkICBtZm46IDAwMDA1
YWFkDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjQyXSAgIGdmbjogMDAwMDVhYWUgIG1m
bjogMDAwMDVhYWUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NDJdICAgZ2ZuOiAwMDAw
NWFhZiAgbWZuOiAwMDAwNWFhZg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo0Ml0gICBn
Zm46IDAwMDA1YWIwICBtZm46IDAwMDA1YWIwDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMz
OjQyXSAgIGdmbjogMDAwMDVhYjEgIG1mbjogMDAwMDVhYjENCg0KKFhFTikgWzIwMTItMDgt
MzEgMjE6MzM6NDJdICAgZ2ZuOiAwMDAwNWFiMiAgbWZuOiAwMDAwNWFiMg0KDQooWEVOKSBb
MjAxMi0wOC0zMSAyMTozMzo0Ml0gICBnZm46IDAwMDA1YWIzICBtZm46IDAwMDA1YWIzDQoN
CihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjQyXSAgIGdmbjogMDAwMDVhYjQgIG1mbjogMDAw
MDVhYjQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NDJdICAgZ2ZuOiAwMDAwNWFiNSAg
bWZuOiAwMDAwNWFiNQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo0Ml0gICBnZm46IDAw
MDA1YWI2ICBtZm46IDAwMDA1YWI2DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjQyXSAg
IGdmbjogMDAwMDVhYjcgIG1mbjogMDAwMDVhYjcNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6
MzM6NDJdICAgZ2ZuOiAwMDAwNWFiOCAgbWZuOiAwMDAwNWFiOA0KDQooWEVOKSBbMjAxMi0w
OC0zMSAyMTozMzo0Ml0gICBnZm46IDAwMDA1YWI5ICBtZm46IDAwMDA1YWI5DQoNCihYRU4p
IFsyMDEyLTA4LTMxIDIxOjMzOjQyXSAgIGdmbjogMDAwMDVhYmEgIG1mbjogMDAwMDVhYmEN
Cg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NDJdICAgZ2ZuOiAwMDAwNWFiYiAgbWZuOiAw
MDAwNWFiYg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo0Ml0gICBnZm46IDAwMDA1YWJj
ICBtZm46IDAwMDA1YWJjDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjQyXSAgIGdmbjog
MDAwMDVhYmQgIG1mbjogMDAwMDVhYmQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NDJd
ICAgZ2ZuOiAwMDAwNWFiZSAgbWZuOiAwMDAwNWFiZQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAy
MTozMzo0Ml0gICBnZm46IDAwMDA1YWJmICBtZm46IDAwMDA1YWJmDQoNCihYRU4pIFsyMDEy
LTA4LTMxIDIxOjMzOjQyXSAgIGdmbjogMDAwMDVhYzAgIG1mbjogMDAwMDVhYzANCg0KKFhF
TikgWzIwMTItMDgtMzEgMjE6MzM6NDJdICAgZ2ZuOiAwMDAwNWFjMSAgbWZuOiAwMDAwNWFj
MQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo0Ml0gICBnZm46IDAwMDA1YWMyICBtZm46
IDAwMDA1YWMyDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjQyXSAgIGdmbjogMDAwMDVh
YzMgIG1mbjogMDAwMDVhYzMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NDJdICAgZ2Zu
OiAwMDAwNWFjNCAgbWZuOiAwMDAwNWFjNA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo0
Ml0gICBnZm46IDAwMDA1YWM1ICBtZm46IDAwMDA1YWM1DQoNCihYRU4pIFsyMDEyLTA4LTMx
IDIxOjMzOjQzXSAgIGdmbjogMDAwMDVhYzYgIG1mbjogMDAwMDVhYzYNCg0KKFhFTikgWzIw
MTItMDgtMzEgMjE6MzM6NDNdICAgZ2ZuOiAwMDAwNWFjNyAgbWZuOiAwMDAwNWFjNw0KDQoo
WEVOKSBbMjAxMi0wOC0zMSAyMTozMzo0M10gICBnZm46IDAwMDA1YWM4ICBtZm46IDAwMDA1
YWM4DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjQzXSAgIGdmbjogMDAwMDVhYzkgIG1m
bjogMDAwMDVhYzkNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NDNdICAgZ2ZuOiAwMDAw
NWFjYSAgbWZuOiAwMDAwNWFjYQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo0M10gICBn
Zm46IDAwMDA1YWNiICBtZm46IDAwMDA1YWNiDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMz
OjQzXSAgIGdmbjogMDAwMDVhY2MgIG1mbjogMDAwMDVhY2MNCg0KKFhFTikgWzIwMTItMDgt
MzEgMjE6MzM6NDNdICAgZ2ZuOiAwMDAwNWFjZCAgbWZuOiAwMDAwNWFjZA0KDQooWEVOKSBb
MjAxMi0wOC0zMSAyMTozMzo0M10gICBnZm46IDAwMDA1YWNlICBtZm46IDAwMDA1YWNlDQoN
CihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjQzXSAgIGdmbjogMDAwMDVhY2YgIG1mbjogMDAw
MDVhY2YNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NDNdICAgZ2ZuOiAwMDAwNWFkMCAg
bWZuOiAwMDAwNWFkMA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo0M10gICBnZm46IDAw
MDA1YWQxICBtZm46IDAwMDA1YWQxDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjQzXSAg
IGdmbjogMDAwMDVhZDIgIG1mbjogMDAwMDVhZDINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6
MzM6NDNdICAgZ2ZuOiAwMDAwNWFkMyAgbWZuOiAwMDAwNWFkMw0KDQooWEVOKSBbMjAxMi0w
OC0zMSAyMTozMzo0M10gICBnZm46IDAwMDA1YWQ0ICBtZm46IDAwMDA1YWQ0DQoNCihYRU4p
IFsyMDEyLTA4LTMxIDIxOjMzOjQzXSAgIGdmbjogMDAwMDVhZDUgIG1mbjogMDAwMDVhZDUN
Cg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NDNdICAgZ2ZuOiAwMDAwNWFkNiAgbWZuOiAw
MDAwNWFkNg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo0M10gICBnZm46IDAwMDA1YWQ3
ICBtZm46IDAwMDA1YWQ3DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjQzXSAgIGdmbjog
MDAwMDVhZDggIG1mbjogMDAwMDVhZDgNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NDNd
ICAgZ2ZuOiAwMDAwNWFkOSAgbWZuOiAwMDAwNWFkOQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAy
MTozMzo0M10gICBnZm46IDAwMDA1YWRhICBtZm46IDAwMDA1YWRhDQoNCihYRU4pIFsyMDEy
LTA4LTMxIDIxOjMzOjQzXSAgIGdmbjogMDAwMDVhZGIgIG1mbjogMDAwMDVhZGINCg0KKFhF
TikgWzIwMTItMDgtMzEgMjE6MzM6NDNdICAgZ2ZuOiAwMDAwNWFkYyAgbWZuOiAwMDAwNWFk
Yw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo0M10gICBnZm46IDAwMDA1YWRkICBtZm46
IDAwMDA1YWRkDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjQzXSAgIGdmbjogMDAwMDVh
ZGUgIG1mbjogMDAwMDVhZGUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NDNdICAgZ2Zu
OiAwMDAwNWFkZiAgbWZuOiAwMDAwNWFkZg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo0
M10gICBnZm46IDAwMDA1YWUwICBtZm46IDAwMDA1YWUwDQoNCihYRU4pIFsyMDEyLTA4LTMx
IDIxOjMzOjQzXSAgIGdmbjogMDAwMDVhZTEgIG1mbjogMDAwMDVhZTENCg0KKFhFTikgWzIw
MTItMDgtMzEgMjE6MzM6NDNdICAgZ2ZuOiAwMDAwNWFlMiAgbWZuOiAwMDAwNWFlMg0KDQoo
WEVOKSBbMjAxMi0wOC0zMSAyMTozMzo0M10gICBnZm46IDAwMDA1YWUzICBtZm46IDAwMDA1
YWUzDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjQzXSAgIGdmbjogMDAwMDVhZTQgIG1m
bjogMDAwMDVhZTQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NDNdICAgZ2ZuOiAwMDAw
NWFlNSAgbWZuOiAwMDAwNWFlNQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo0M10gICBn
Zm46IDAwMDA1YWU2ICBtZm46IDAwMDA1YWU2DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMz
OjQzXSAgIGdmbjogMDAwMDVhZTcgIG1mbjogMDAwMDVhZTcNCg0KKFhFTikgWzIwMTItMDgt
MzEgMjE6MzM6NDNdICAgZ2ZuOiAwMDAwNWFlOCAgbWZuOiAwMDAwNWFlOA0KDQooWEVOKSBb
MjAxMi0wOC0zMSAyMTozMzo0M10gICBnZm46IDAwMDA1YWU5ICBtZm46IDAwMDA1YWU5DQoN
CihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjQzXSAgIGdmbjogMDAwMDVhZWEgIG1mbjogMDAw
MDVhZWENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NDNdICAgZ2ZuOiAwMDAwNWFlYiAg
bWZuOiAwMDAwNWFlYg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo0M10gICBnZm46IDAw
MDA1YWVjICBtZm46IDAwMDA1YWVjDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjQzXSAg
IGdmbjogMDAwMDVhZWQgIG1mbjogMDAwMDVhZWQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6
MzM6NDNdICAgZ2ZuOiAwMDAwNWFlZSAgbWZuOiAwMDAwNWFlZQ0KDQooWEVOKSBbMjAxMi0w
OC0zMSAyMTozMzo0M10gICBnZm46IDAwMDA1YWVmICBtZm46IDAwMDA1YWVmDQoNCihYRU4p
IFsyMDEyLTA4LTMxIDIxOjMzOjQzXSAgIGdmbjogMDAwMDVhZjAgIG1mbjogMDAwMDVhZjAN
Cg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NDNdICAgZ2ZuOiAwMDAwNWFmMSAgbWZuOiAw
MDAwNWFmMQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo0M10gICBnZm46IDAwMDA1YWYy
ICBtZm46IDAwMDA1YWYyDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjQzXSAgIGdmbjog
MDAwMDVhZjMgIG1mbjogMDAwMDVhZjMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NDNd
ICAgZ2ZuOiAwMDAwNWFmNCAgbWZuOiAwMDAwNWFmNA0KDQooWEVOKSBbMjAxMi0wOC0zMSAy
MTozMzo0M10gICBnZm46IDAwMDA1YWY1ICBtZm46IDAwMDA1YWY1DQoNCihYRU4pIFsyMDEy
LTA4LTMxIDIxOjMzOjQzXSAgIGdmbjogMDAwMDVhZjYgIG1mbjogMDAwMDVhZjYNCg0KKFhF
TikgWzIwMTItMDgtMzEgMjE6MzM6NDNdICAgZ2ZuOiAwMDAwNWFmNyAgbWZuOiAwMDAwNWFm
Nw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo0M10gICBnZm46IDAwMDA1YWY4ICBtZm46
IDAwMDA1YWY4DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjQzXSAgIGdmbjogMDAwMDVh
ZjkgIG1mbjogMDAwMDVhZjkNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NDNdICAgZ2Zu
OiAwMDAwNWFmYSAgbWZuOiAwMDAwNWFmYQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo0
M10gICBnZm46IDAwMDA1YWZiICBtZm46IDAwMDA1YWZiDQoNCihYRU4pIFsyMDEyLTA4LTMx
IDIxOjMzOjQzXSAgIGdmbjogMDAwMDVhZmMgIG1mbjogMDAwMDVhZmMNCg0KKFhFTikgWzIw
MTItMDgtMzEgMjE6MzM6NDNdICAgZ2ZuOiAwMDAwNWFmZCAgbWZuOiAwMDAwNWFmZA0KDQoo
WEVOKSBbMjAxMi0wOC0zMSAyMTozMzo0M10gICBnZm46IDAwMDA1YWZlICBtZm46IDAwMDA1
YWZlDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjQzXSAgIGdmbjogMDAwMDVhZmYgIG1m
bjogMDAwMDVhZmYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NDNdICAgZ2ZuOiAwMDAw
NWIwMCAgbWZuOiAwMDAwNWIwMA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo0M10gICBn
Zm46IDAwMDA1YjAxICBtZm46IDAwMDA1YjAxDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMz
OjQzXSAgIGdmbjogMDAwMDViMDIgIG1mbjogMDAwMDViMDINCg0KKFhFTikgWzIwMTItMDgt
MzEgMjE6MzM6NDNdICAgZ2ZuOiAwMDAwNWIwMyAgbWZuOiAwMDAwNWIwMw0KDQooWEVOKSBb
MjAxMi0wOC0zMSAyMTozMzo0M10gICBnZm46IDAwMDA1YjA0ICBtZm46IDAwMDA1YjA0DQoN
CihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjQzXSAgIGdmbjogMDAwMDViMDUgIG1mbjogMDAw
MDViMDUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NDRdICAgZ2ZuOiAwMDAwNWIwNiAg
bWZuOiAwMDAwNWIwNg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo0NF0gICBnZm46IDAw
MDA1YjA3ICBtZm46IDAwMDA1YjA3DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjQ0XSAg
IGdmbjogMDAwMDViMDggIG1mbjogMDAwMDViMDgNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6
MzM6NDRdICAgZ2ZuOiAwMDAwNWIwOSAgbWZuOiAwMDAwNWIwOQ0KDQooWEVOKSBbMjAxMi0w
OC0zMSAyMTozMzo0NF0gICBnZm46IDAwMDA1YjBhICBtZm46IDAwMDA1YjBhDQoNCihYRU4p
IFsyMDEyLTA4LTMxIDIxOjMzOjQ0XSAgIGdmbjogMDAwMDViMGIgIG1mbjogMDAwMDViMGIN
Cg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NDRdICAgZ2ZuOiAwMDAwNWIwYyAgbWZuOiAw
MDAwNWIwYw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo0NF0gICBnZm46IDAwMDA1YjBk
ICBtZm46IDAwMDA1YjBkDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjQ0XSAgIGdmbjog
MDAwMDViMGUgIG1mbjogMDAwMDViMGUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NDRd
ICAgZ2ZuOiAwMDAwNWIwZiAgbWZuOiAwMDAwNWIwZg0KDQooWEVOKSBbMjAxMi0wOC0zMSAy
MTozMzo0NF0gICBnZm46IDAwMDA1YjEwICBtZm46IDAwMDA1YjEwDQoNCihYRU4pIFsyMDEy
LTA4LTMxIDIxOjMzOjQ0XSAgIGdmbjogMDAwMDViMTEgIG1mbjogMDAwMDViMTENCg0KKFhF
TikgWzIwMTItMDgtMzEgMjE6MzM6NDRdICAgZ2ZuOiAwMDAwNWIxMiAgbWZuOiAwMDAwNWIx
Mg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo0NF0gICBnZm46IDAwMDA1YjEzICBtZm46
IDAwMDA1YjEzDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjQ0XSAgIGdmbjogMDAwMDVi
MTQgIG1mbjogMDAwMDViMTQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NDRdICAgZ2Zu
OiAwMDAwNWIxNSAgbWZuOiAwMDAwNWIxNQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo0
NF0gICBnZm46IDAwMDA1YjE2ICBtZm46IDAwMDA1YjE2DQoNCihYRU4pIFsyMDEyLTA4LTMx
IDIxOjMzOjQ0XSAgIGdmbjogMDAwMDViMTcgIG1mbjogMDAwMDViMTcNCg0KKFhFTikgWzIw
MTItMDgtMzEgMjE6MzM6NDRdICAgZ2ZuOiAwMDAwNWIxOCAgbWZuOiAwMDAwNWIxOA0KDQoo
WEVOKSBbMjAxMi0wOC0zMSAyMTozMzo0NF0gICBnZm46IDAwMDA1YjE5ICBtZm46IDAwMDA1
YjE5DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjQ0XSAgIGdmbjogMDAwMDViMWEgIG1m
bjogMDAwMDViMWENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NDRdICAgZ2ZuOiAwMDAw
NWIxYiAgbWZuOiAwMDAwNWIxYg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo0NF0gICBn
Zm46IDAwMDA1YjFjICBtZm46IDAwMDA1YjFjDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMz
OjQ0XSAgIGdmbjogMDAwMDViMWQgIG1mbjogMDAwMDViMWQNCg0KKFhFTikgWzIwMTItMDgt
MzEgMjE6MzM6NDRdICAgZ2ZuOiAwMDAwNWIxZSAgbWZuOiAwMDAwNWIxZQ0KDQooWEVOKSBb
MjAxMi0wOC0zMSAyMTozMzo0NF0gICBnZm46IDAwMDA1YjFmICBtZm46IDAwMDA1YjFmDQoN
CihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjQ0XSAgIGdmbjogMDAwMDViMjAgIG1mbjogMDAw
MDViMjANCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NDRdICAgZ2ZuOiAwMDAwNWIyMSAg
bWZuOiAwMDAwNWIyMQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo0NF0gICBnZm46IDAw
MDA1YjIyICBtZm46IDAwMDA1YjIyDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjQ0XSAg
IGdmbjogMDAwMDViMjMgIG1mbjogMDAwMDViMjMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6
MzM6NDRdICAgZ2ZuOiAwMDAwNWIyNCAgbWZuOiAwMDAwNWIyNA0KDQooWEVOKSBbMjAxMi0w
OC0zMSAyMTozMzo0NF0gICBnZm46IDAwMDA1YjI1ICBtZm46IDAwMDA1YjI1DQoNCihYRU4p
IFsyMDEyLTA4LTMxIDIxOjMzOjQ0XSAgIGdmbjogMDAwMDViMjYgIG1mbjogMDAwMDViMjYN
Cg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NDRdICAgZ2ZuOiAwMDAwNWIyNyAgbWZuOiAw
MDAwNWIyNw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo0NF0gICBnZm46IDAwMDA1YjI4
ICBtZm46IDAwMDA1YjI4DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjQ0XSAgIGdmbjog
MDAwMDViMjkgIG1mbjogMDAwMDViMjkNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NDRd
ICAgZ2ZuOiAwMDAwNWIyYSAgbWZuOiAwMDAwNWIyYQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAy
MTozMzo0NF0gICBnZm46IDAwMDA1YjJiICBtZm46IDAwMDA1YjJiDQoNCihYRU4pIFsyMDEy
LTA4LTMxIDIxOjMzOjQ0XSAgIGdmbjogMDAwMDViMmMgIG1mbjogMDAwMDViMmMNCg0KKFhF
TikgWzIwMTItMDgtMzEgMjE6MzM6NDRdICAgZ2ZuOiAwMDAwNWIyZCAgbWZuOiAwMDAwNWIy
ZA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo0NF0gICBnZm46IDAwMDA1YjJlICBtZm46
IDAwMDA1YjJlDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjQ0XSAgIGdmbjogMDAwMDVi
MmYgIG1mbjogMDAwMDViMmYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NDRdICAgZ2Zu
OiAwMDAwNWIzMCAgbWZuOiAwMDAwNWIzMA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo0
NF0gICBnZm46IDAwMDA1YjMxICBtZm46IDAwMDA1YjMxDQoNCihYRU4pIFsyMDEyLTA4LTMx
IDIxOjMzOjQ0XSAgIGdmbjogMDAwMDViMzIgIG1mbjogMDAwMDViMzINCg0KKFhFTikgWzIw
MTItMDgtMzEgMjE6MzM6NDRdICAgZ2ZuOiAwMDAwNWIzMyAgbWZuOiAwMDAwNWIzMw0KDQoo
WEVOKSBbMjAxMi0wOC0zMSAyMTozMzo0NF0gICBnZm46IDAwMDA1YjM0ICBtZm46IDAwMDA1
YjM0DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjQ0XSAgIGdmbjogMDAwMDViMzUgIG1m
bjogMDAwMDViMzUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NDRdICAgZ2ZuOiAwMDAw
NWIzNiAgbWZuOiAwMDAwNWIzNg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo0NF0gICBn
Zm46IDAwMDA1YjM3ICBtZm46IDAwMDA1YjM3DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMz
OjQ0XSAgIGdmbjogMDAwMDViMzggIG1mbjogMDAwMDViMzgNCg0KKFhFTikgWzIwMTItMDgt
MzEgMjE6MzM6NDRdICAgZ2ZuOiAwMDAwNWIzOSAgbWZuOiAwMDAwNWIzOQ0KDQooWEVOKSBb
MjAxMi0wOC0zMSAyMTozMzo0NF0gICBnZm46IDAwMDA1YjNhICBtZm46IDAwMDA1YjNhDQoN
CihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjQ0XSAgIGdmbjogMDAwMDViM2IgIG1mbjogMDAw
MDViM2INCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NDRdICAgZ2ZuOiAwMDAwNWIzYyAg
bWZuOiAwMDAwNWIzYw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo0NF0gICBnZm46IDAw
MDA1YjNkICBtZm46IDAwMDA1YjNkDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjQ0XSAg
IGdmbjogMDAwMDViM2UgIG1mbjogMDAwMDViM2UNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6
MzM6NDRdICAgZ2ZuOiAwMDAwNWIzZiAgbWZuOiAwMDAwNWIzZg0KDQooWEVOKSBbMjAxMi0w
OC0zMSAyMTozMzo0NF0gICBnZm46IDAwMDA1YjQwICBtZm46IDAwMDA1YjQwDQoNCihYRU4p
IFsyMDEyLTA4LTMxIDIxOjMzOjQ0XSAgIGdmbjogMDAwMDViNDEgIG1mbjogMDAwMDViNDEN
Cg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NDRdICAgZ2ZuOiAwMDAwNWI0MiAgbWZuOiAw
MDAwNWI0Mg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo0NF0gICBnZm46IDAwMDA1YjQz
ICBtZm46IDAwMDA1YjQzDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjQ0XSAgIGdmbjog
MDAwMDViNDQgIG1mbjogMDAwMDViNDQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NDRd
ICAgZ2ZuOiAwMDAwNWI0NSAgbWZuOiAwMDAwNWI0NQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAy
MTozMzo0NV0gICBnZm46IDAwMDA1YjQ2ICBtZm46IDAwMDA1YjQ2DQoNCihYRU4pIFsyMDEy
LTA4LTMxIDIxOjMzOjQ1XSAgIGdmbjogMDAwMDViNDcgIG1mbjogMDAwMDViNDcNCg0KKFhF
TikgWzIwMTItMDgtMzEgMjE6MzM6NDVdICAgZ2ZuOiAwMDAwNWI0OCAgbWZuOiAwMDAwNWI0
OA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo0NV0gICBnZm46IDAwMDA1YjQ5ICBtZm46
IDAwMDA1YjQ5DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjQ1XSAgIGdmbjogMDAwMDVi
NGEgIG1mbjogMDAwMDViNGENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NDVdICAgZ2Zu
OiAwMDAwNWI0YiAgbWZuOiAwMDAwNWI0Yg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo0
NV0gICBnZm46IDAwMDA1YjRjICBtZm46IDAwMDA1YjRjDQoNCihYRU4pIFsyMDEyLTA4LTMx
IDIxOjMzOjQ1XSAgIGdmbjogMDAwMDViNGQgIG1mbjogMDAwMDViNGQNCg0KKFhFTikgWzIw
MTItMDgtMzEgMjE6MzM6NDVdICAgZ2ZuOiAwMDAwNWI0ZSAgbWZuOiAwMDAwNWI0ZQ0KDQoo
WEVOKSBbMjAxMi0wOC0zMSAyMTozMzo0NV0gICBnZm46IDAwMDA1YjRmICBtZm46IDAwMDA1
YjRmDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjQ1XSAgIGdmbjogMDAwMDViNTAgIG1m
bjogMDAwMDViNTANCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NDVdICAgZ2ZuOiAwMDAw
NWI1MSAgbWZuOiAwMDAwNWI1MQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo0NV0gICBn
Zm46IDAwMDA1YjUyICBtZm46IDAwMDA1YjUyDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMz
OjQ1XSAgIGdmbjogMDAwMDViNTMgIG1mbjogMDAwMDViNTMNCg0KKFhFTikgWzIwMTItMDgt
MzEgMjE6MzM6NDVdICAgZ2ZuOiAwMDAwNWI1NCAgbWZuOiAwMDAwNWI1NA0KDQooWEVOKSBb
MjAxMi0wOC0zMSAyMTozMzo0NV0gICBnZm46IDAwMDA1YjU1ICBtZm46IDAwMDA1YjU1DQoN
CihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjQ1XSAgIGdmbjogMDAwMDViNTYgIG1mbjogMDAw
MDViNTYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NDVdICAgZ2ZuOiAwMDAwNWI1NyAg
bWZuOiAwMDAwNWI1Nw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo0NV0gICBnZm46IDAw
MDA1YjU4ICBtZm46IDAwMDA1YjU4DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjQ1XSAg
IGdmbjogMDAwMDViNTkgIG1mbjogMDAwMDViNTkNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6
MzM6NDVdICAgZ2ZuOiAwMDAwNWI1YSAgbWZuOiAwMDAwNWI1YQ0KDQooWEVOKSBbMjAxMi0w
OC0zMSAyMTozMzo0NV0gICBnZm46IDAwMDA1YjViICBtZm46IDAwMDA1YjViDQoNCihYRU4p
IFsyMDEyLTA4LTMxIDIxOjMzOjQ1XSAgIGdmbjogMDAwMDViNWMgIG1mbjogMDAwMDViNWMN
Cg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NDVdICAgZ2ZuOiAwMDAwNWI1ZCAgbWZuOiAw
MDAwNWI1ZA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo0NV0gICBnZm46IDAwMDA1YjVl
ICBtZm46IDAwMDA1YjVlDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjQ1XSAgIGdmbjog
MDAwMDViNWYgIG1mbjogMDAwMDViNWYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NDVd
ICAgZ2ZuOiAwMDAwNWI2MCAgbWZuOiAwMDAwNWI2MA0KDQooWEVOKSBbMjAxMi0wOC0zMSAy
MTozMzo0NV0gICBnZm46IDAwMDA1YjYxICBtZm46IDAwMDA1YjYxDQoNCihYRU4pIFsyMDEy
LTA4LTMxIDIxOjMzOjQ1XSAgIGdmbjogMDAwMDViNjIgIG1mbjogMDAwMDViNjINCg0KKFhF
TikgWzIwMTItMDgtMzEgMjE6MzM6NDVdICAgZ2ZuOiAwMDAwNWI2MyAgbWZuOiAwMDAwNWI2
Mw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo0NV0gICBnZm46IDAwMDA1YjY0ICBtZm46
IDAwMDA1YjY0DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjQ1XSAgIGdmbjogMDAwMDVi
NjUgIG1mbjogMDAwMDViNjUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NDVdICAgZ2Zu
OiAwMDAwNWI2NiAgbWZuOiAwMDAwNWI2Ng0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo0
NV0gICBnZm46IDAwMDA1YjY3ICBtZm46IDAwMDA1YjY3DQoNCihYRU4pIFsyMDEyLTA4LTMx
IDIxOjMzOjQ1XSAgIGdmbjogMDAwMDViNjggIG1mbjogMDAwMDViNjgNCg0KKFhFTikgWzIw
MTItMDgtMzEgMjE6MzM6NDVdICAgZ2ZuOiAwMDAwNWI2OSAgbWZuOiAwMDAwNWI2OQ0KDQoo
WEVOKSBbMjAxMi0wOC0zMSAyMTozMzo0NV0gICBnZm46IDAwMDA1YjZhICBtZm46IDAwMDA1
YjZhDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjQ1XSAgIGdmbjogMDAwMDViNmIgIG1m
bjogMDAwMDViNmINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NDVdICAgZ2ZuOiAwMDAw
NWI2YyAgbWZuOiAwMDAwNWI2Yw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo0NV0gICBn
Zm46IDAwMDA1YjZkICBtZm46IDAwMDA1YjZkDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMz
OjQ1XSAgIGdmbjogMDAwMDViNmUgIG1mbjogMDAwMDViNmUNCg0KKFhFTikgWzIwMTItMDgt
MzEgMjE6MzM6NDVdICAgZ2ZuOiAwMDAwNWI2ZiAgbWZuOiAwMDAwNWI2Zg0KDQooWEVOKSBb
MjAxMi0wOC0zMSAyMTozMzo0NV0gICBnZm46IDAwMDA1YjcwICBtZm46IDAwMDA1YjcwDQoN
CihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjQ1XSAgIGdmbjogMDAwMDViNzEgIG1mbjogMDAw
MDViNzENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NDVdICAgZ2ZuOiAwMDAwNWI3MiAg
bWZuOiAwMDAwNWI3Mg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo0NV0gICBnZm46IDAw
MDA1YjczICBtZm46IDAwMDA1YjczDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjQ1XSAg
IGdmbjogMDAwMDViNzQgIG1mbjogMDAwMDViNzQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6
MzM6NDVdICAgZ2ZuOiAwMDAwNWI3NSAgbWZuOiAwMDAwNWI3NQ0KDQooWEVOKSBbMjAxMi0w
OC0zMSAyMTozMzo0NV0gICBnZm46IDAwMDA1Yjc2ICBtZm46IDAwMDA1Yjc2DQoNCihYRU4p
IFsyMDEyLTA4LTMxIDIxOjMzOjQ1XSAgIGdmbjogMDAwMDViNzcgIG1mbjogMDAwMDViNzcN
Cg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NDVdICAgZ2ZuOiAwMDAwNWI3OCAgbWZuOiAw
MDAwNWI3OA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo0NV0gICBnZm46IDAwMDA1Yjc5
ICBtZm46IDAwMDA1Yjc5DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjQ1XSAgIGdmbjog
MDAwMDViN2EgIG1mbjogMDAwMDViN2ENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NDVd
ICAgZ2ZuOiAwMDAwNWI3YiAgbWZuOiAwMDAwNWI3Yg0KDQooWEVOKSBbMjAxMi0wOC0zMSAy
MTozMzo0NV0gICBnZm46IDAwMDA1YjdjICBtZm46IDAwMDA1YjdjDQoNCihYRU4pIFsyMDEy
LTA4LTMxIDIxOjMzOjQ1XSAgIGdmbjogMDAwMDViN2QgIG1mbjogMDAwMDViN2QNCg0KKFhF
TikgWzIwMTItMDgtMzEgMjE6MzM6NDVdICAgZ2ZuOiAwMDAwNWI3ZSAgbWZuOiAwMDAwNWI3
ZQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo0NV0gICBnZm46IDAwMDA1YjdmICBtZm46
IDAwMDA1YjdmDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjQ1XSAgIGdmbjogMDAwMDVi
ODAgIG1mbjogMDAwMDViODANCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NDVdICAgZ2Zu
OiAwMDAwNWI4MSAgbWZuOiAwMDAwNWI4MQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo0
NV0gICBnZm46IDAwMDA1YjgyICBtZm46IDAwMDA1YjgyDQoNCihYRU4pIFsyMDEyLTA4LTMx
IDIxOjMzOjQ1XSAgIGdmbjogMDAwMDViODMgIG1mbjogMDAwMDViODMNCg0KKFhFTikgWzIw
MTItMDgtMzEgMjE6MzM6NDVdICAgZ2ZuOiAwMDAwNWI4NCAgbWZuOiAwMDAwNWI4NA0KDQoo
WEVOKSBbMjAxMi0wOC0zMSAyMTozMzo0NV0gICBnZm46IDAwMDA1Yjg1ICBtZm46IDAwMDA1
Yjg1DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjQ2XSAgIGdmbjogMDAwMDViODYgIG1m
bjogMDAwMDViODYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NDZdICAgZ2ZuOiAwMDAw
NWI4NyAgbWZuOiAwMDAwNWI4Nw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo0Nl0gICBn
Zm46IDAwMDA1Yjg4ICBtZm46IDAwMDA1Yjg4DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMz
OjQ2XSAgIGdmbjogMDAwMDViODkgIG1mbjogMDAwMDViODkNCg0KKFhFTikgWzIwMTItMDgt
MzEgMjE6MzM6NDZdICAgZ2ZuOiAwMDAwNWI4YSAgbWZuOiAwMDAwNWI4YQ0KDQooWEVOKSBb
MjAxMi0wOC0zMSAyMTozMzo0Nl0gICBnZm46IDAwMDA1YjhiICBtZm46IDAwMDA1YjhiDQoN
CihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjQ2XSAgIGdmbjogMDAwMDViOGMgIG1mbjogMDAw
MDViOGMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NDZdICAgZ2ZuOiAwMDAwNWI4ZCAg
bWZuOiAwMDAwNWI4ZA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo0Nl0gICBnZm46IDAw
MDA1YjhlICBtZm46IDAwMDA1YjhlDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjQ2XSAg
IGdmbjogMDAwMDViOGYgIG1mbjogMDAwMDViOGYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6
MzM6NDZdICAgZ2ZuOiAwMDAwNWI5MCAgbWZuOiAwMDAwNWI5MA0KDQooWEVOKSBbMjAxMi0w
OC0zMSAyMTozMzo0Nl0gICBnZm46IDAwMDA1YjkxICBtZm46IDAwMDA1YjkxDQoNCihYRU4p
IFsyMDEyLTA4LTMxIDIxOjMzOjQ2XSAgIGdmbjogMDAwMDViOTIgIG1mbjogMDAwMDViOTIN
Cg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NDZdICAgZ2ZuOiAwMDAwNWI5MyAgbWZuOiAw
MDAwNWI5Mw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo0Nl0gICBnZm46IDAwMDA1Yjk0
ICBtZm46IDAwMDA1Yjk0DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjQ2XSAgIGdmbjog
MDAwMDViOTUgIG1mbjogMDAwMDViOTUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NDZd
ICAgZ2ZuOiAwMDAwNWI5NiAgbWZuOiAwMDAwNWI5Ng0KDQooWEVOKSBbMjAxMi0wOC0zMSAy
MTozMzo0Nl0gICBnZm46IDAwMDA1Yjk3ICBtZm46IDAwMDA1Yjk3DQoNCihYRU4pIFsyMDEy
LTA4LTMxIDIxOjMzOjQ2XSAgIGdmbjogMDAwMDViOTggIG1mbjogMDAwMDViOTgNCg0KKFhF
TikgWzIwMTItMDgtMzEgMjE6MzM6NDZdICAgZ2ZuOiAwMDAwNWI5OSAgbWZuOiAwMDAwNWI5
OQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo0Nl0gICBnZm46IDAwMDA1YjlhICBtZm46
IDAwMDA1YjlhDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjQ2XSAgIGdmbjogMDAwMDVi
OWIgIG1mbjogMDAwMDViOWINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NDZdICAgZ2Zu
OiAwMDAwNWI5YyAgbWZuOiAwMDAwNWI5Yw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo0
Nl0gICBnZm46IDAwMDA1YjlkICBtZm46IDAwMDA1YjlkDQoNCihYRU4pIFsyMDEyLTA4LTMx
IDIxOjMzOjQ2XSAgIGdmbjogMDAwMDViOWUgIG1mbjogMDAwMDViOWUNCg0KKFhFTikgWzIw
MTItMDgtMzEgMjE6MzM6NDZdICAgZ2ZuOiAwMDAwNWI5ZiAgbWZuOiAwMDAwNWI5Zg0KDQoo
WEVOKSBbMjAxMi0wOC0zMSAyMTozMzo0Nl0gICBnZm46IDAwMDA1YmEwICBtZm46IDAwMDA1
YmEwDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjQ2XSAgIGdmbjogMDAwMDViYTEgIG1m
bjogMDAwMDViYTENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NDZdICAgZ2ZuOiAwMDAw
NWJhMiAgbWZuOiAwMDAwNWJhMg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo0Nl0gICBn
Zm46IDAwMDA1YmEzICBtZm46IDAwMDA1YmEzDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMz
OjQ2XSAgIGdmbjogMDAwMDViYTQgIG1mbjogMDAwMDViYTQNCg0KKFhFTikgWzIwMTItMDgt
MzEgMjE6MzM6NDZdICAgZ2ZuOiAwMDAwNWJhNSAgbWZuOiAwMDAwNWJhNQ0KDQooWEVOKSBb
MjAxMi0wOC0zMSAyMTozMzo0Nl0gICBnZm46IDAwMDA1YmE2ICBtZm46IDAwMDA1YmE2DQoN
CihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjQ2XSAgIGdmbjogMDAwMDViYTcgIG1mbjogMDAw
MDViYTcNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NDZdICAgZ2ZuOiAwMDAwNWJhOCAg
bWZuOiAwMDAwNWJhOA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo0Nl0gICBnZm46IDAw
MDA1YmE5ICBtZm46IDAwMDA1YmE5DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjQ2XSAg
IGdmbjogMDAwMDViYWEgIG1mbjogMDAwMDViYWENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6
MzM6NDZdICAgZ2ZuOiAwMDAwNWJhYiAgbWZuOiAwMDAwNWJhYg0KDQooWEVOKSBbMjAxMi0w
OC0zMSAyMTozMzo0Nl0gICBnZm46IDAwMDA1YmFjICBtZm46IDAwMDA1YmFjDQoNCihYRU4p
IFsyMDEyLTA4LTMxIDIxOjMzOjQ2XSAgIGdmbjogMDAwMDViYWQgIG1mbjogMDAwMDViYWQN
Cg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NDZdICAgZ2ZuOiAwMDAwNWJhZSAgbWZuOiAw
MDAwNWJhZQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo0Nl0gICBnZm46IDAwMDA1YmFm
ICBtZm46IDAwMDA1YmFmDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjQ2XSAgIGdmbjog
MDAwMDViYjAgIG1mbjogMDAwMDViYjANCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NDZd
ICAgZ2ZuOiAwMDAwNWJiMSAgbWZuOiAwMDAwNWJiMQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAy
MTozMzo0Nl0gICBnZm46IDAwMDA1YmIyICBtZm46IDAwMDA1YmIyDQoNCihYRU4pIFsyMDEy
LTA4LTMxIDIxOjMzOjQ2XSAgIGdmbjogMDAwMDViYjMgIG1mbjogMDAwMDViYjMNCg0KKFhF
TikgWzIwMTItMDgtMzEgMjE6MzM6NDZdICAgZ2ZuOiAwMDAwNWJiNCAgbWZuOiAwMDAwNWJi
NA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo0Nl0gICBnZm46IDAwMDA1YmI1ICBtZm46
IDAwMDA1YmI1DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjQ2XSAgIGdmbjogMDAwMDVi
YjYgIG1mbjogMDAwMDViYjYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NDZdICAgZ2Zu
OiAwMDAwNWJiNyAgbWZuOiAwMDAwNWJiNw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo0
Nl0gICBnZm46IDAwMDA1YmI4ICBtZm46IDAwMDA1YmI4DQoNCihYRU4pIFsyMDEyLTA4LTMx
IDIxOjMzOjQ2XSAgIGdmbjogMDAwMDViYjkgIG1mbjogMDAwMDViYjkNCg0KKFhFTikgWzIw
MTItMDgtMzEgMjE6MzM6NDZdICAgZ2ZuOiAwMDAwNWJiYSAgbWZuOiAwMDAwNWJiYQ0KDQoo
WEVOKSBbMjAxMi0wOC0zMSAyMTozMzo0Nl0gICBnZm46IDAwMDA1YmJiICBtZm46IDAwMDA1
YmJiDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjQ2XSAgIGdmbjogMDAwMDViYmMgIG1m
bjogMDAwMDViYmMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NDZdICAgZ2ZuOiAwMDAw
NWJiZCAgbWZuOiAwMDAwNWJiZA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo0Nl0gICBn
Zm46IDAwMDA1YmJlICBtZm46IDAwMDA1YmJlDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMz
OjQ2XSAgIGdmbjogMDAwMDViYmYgIG1mbjogMDAwMDViYmYNCg0KKFhFTikgWzIwMTItMDgt
MzEgMjE6MzM6NDZdICAgZ2ZuOiAwMDAwNWJjMCAgbWZuOiAwMDAwNWJjMA0KDQooWEVOKSBb
MjAxMi0wOC0zMSAyMTozMzo0Nl0gICBnZm46IDAwMDA1YmMxICBtZm46IDAwMDA1YmMxDQoN
CihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjQ2XSAgIGdmbjogMDAwMDViYzIgIG1mbjogMDAw
MDViYzINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NDZdICAgZ2ZuOiAwMDAwNWJjMyAg
bWZuOiAwMDAwNWJjMw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo0Nl0gICBnZm46IDAw
MDA1YmM0ICBtZm46IDAwMDA1YmM0DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjQ2XSAg
IGdmbjogMDAwMDViYzUgIG1mbjogMDAwMDViYzUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6
MzM6NDddICAgZ2ZuOiAwMDAwNWJjNiAgbWZuOiAwMDAwNWJjNg0KDQooWEVOKSBbMjAxMi0w
OC0zMSAyMTozMzo0N10gICBnZm46IDAwMDA1YmM3ICBtZm46IDAwMDA1YmM3DQoNCihYRU4p
IFsyMDEyLTA4LTMxIDIxOjMzOjQ3XSAgIGdmbjogMDAwMDViYzggIG1mbjogMDAwMDViYzgN
Cg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NDddICAgZ2ZuOiAwMDAwNWJjOSAgbWZuOiAw
MDAwNWJjOQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo0N10gICBnZm46IDAwMDA1YmNh
ICBtZm46IDAwMDA1YmNhDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjQ3XSAgIGdmbjog
MDAwMDViY2IgIG1mbjogMDAwMDViY2INCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NDdd
ICAgZ2ZuOiAwMDAwNWJjYyAgbWZuOiAwMDAwNWJjYw0KDQooWEVOKSBbMjAxMi0wOC0zMSAy
MTozMzo0N10gICBnZm46IDAwMDA1YmNkICBtZm46IDAwMDA1YmNkDQoNCihYRU4pIFsyMDEy
LTA4LTMxIDIxOjMzOjQ3XSAgIGdmbjogMDAwMDViY2UgIG1mbjogMDAwMDViY2UNCg0KKFhF
TikgWzIwMTItMDgtMzEgMjE6MzM6NDddICAgZ2ZuOiAwMDAwNWJjZiAgbWZuOiAwMDAwNWJj
Zg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo0N10gICBnZm46IDAwMDA1YmQwICBtZm46
IDAwMDA1YmQwDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjQ3XSAgIGdmbjogMDAwMDVi
ZDEgIG1mbjogMDAwMDViZDENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NDddICAgZ2Zu
OiAwMDAwNWJkMiAgbWZuOiAwMDAwNWJkMg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo0
N10gICBnZm46IDAwMDA1YmQzICBtZm46IDAwMDA1YmQzDQoNCihYRU4pIFsyMDEyLTA4LTMx
IDIxOjMzOjQ3XSAgIGdmbjogMDAwMDViZDQgIG1mbjogMDAwMDViZDQNCg0KKFhFTikgWzIw
MTItMDgtMzEgMjE6MzM6NDddICAgZ2ZuOiAwMDAwNWJkNSAgbWZuOiAwMDAwNWJkNQ0KDQoo
WEVOKSBbMjAxMi0wOC0zMSAyMTozMzo0N10gICBnZm46IDAwMDA1YmQ2ICBtZm46IDAwMDA1
YmQ2DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjQ3XSAgIGdmbjogMDAwMDViZDcgIG1m
bjogMDAwMDViZDcNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NDddICAgZ2ZuOiAwMDAw
NWJkOCAgbWZuOiAwMDAwNWJkOA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo0N10gICBn
Zm46IDAwMDA1YmQ5ICBtZm46IDAwMDA1YmQ5DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMz
OjQ3XSAgIGdmbjogMDAwMDViZGEgIG1mbjogMDAwMDViZGENCg0KKFhFTikgWzIwMTItMDgt
MzEgMjE6MzM6NDddICAgZ2ZuOiAwMDAwNWJkYiAgbWZuOiAwMDAwNWJkYg0KDQooWEVOKSBb
MjAxMi0wOC0zMSAyMTozMzo0N10gICBnZm46IDAwMDA1YmRjICBtZm46IDAwMDA1YmRjDQoN
CihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjQ3XSAgIGdmbjogMDAwMDViZGQgIG1mbjogMDAw
MDViZGQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NDddICAgZ2ZuOiAwMDAwNWJkZSAg
bWZuOiAwMDAwNWJkZQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo0N10gICBnZm46IDAw
MDA1YmRmICBtZm46IDAwMDA1YmRmDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjQ3XSAg
IGdmbjogMDAwMDViZTAgIG1mbjogMDAwMDViZTANCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6
MzM6NDddICAgZ2ZuOiAwMDAwNWJlMSAgbWZuOiAwMDAwNWJlMQ0KDQooWEVOKSBbMjAxMi0w
OC0zMSAyMTozMzo0N10gICBnZm46IDAwMDA1YmUyICBtZm46IDAwMDA1YmUyDQoNCihYRU4p
IFsyMDEyLTA4LTMxIDIxOjMzOjQ3XSAgIGdmbjogMDAwMDViZTMgIG1mbjogMDAwMDViZTMN
Cg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NDddICAgZ2ZuOiAwMDAwNWJlNCAgbWZuOiAw
MDAwNWJlNA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo0N10gICBnZm46IDAwMDA1YmU1
ICBtZm46IDAwMDA1YmU1DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjQ3XSAgIGdmbjog
MDAwMDViZTYgIG1mbjogMDAwMDViZTYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NDdd
ICAgZ2ZuOiAwMDAwNWJlNyAgbWZuOiAwMDAwNWJlNw0KDQooWEVOKSBbMjAxMi0wOC0zMSAy
MTozMzo0N10gICBnZm46IDAwMDA1YmU4ICBtZm46IDAwMDA1YmU4DQoNCihYRU4pIFsyMDEy
LTA4LTMxIDIxOjMzOjQ3XSAgIGdmbjogMDAwMDViZTkgIG1mbjogMDAwMDViZTkNCg0KKFhF
TikgWzIwMTItMDgtMzEgMjE6MzM6NDddICAgZ2ZuOiAwMDAwNWJlYSAgbWZuOiAwMDAwNWJl
YQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo0N10gICBnZm46IDAwMDA1YmViICBtZm46
IDAwMDA1YmViDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjQ3XSAgIGdmbjogMDAwMDVi
ZWMgIG1mbjogMDAwMDViZWMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NDddICAgZ2Zu
OiAwMDAwNWJlZCAgbWZuOiAwMDAwNWJlZA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo0
N10gICBnZm46IDAwMDA1YmVlICBtZm46IDAwMDA1YmVlDQoNCihYRU4pIFsyMDEyLTA4LTMx
IDIxOjMzOjQ3XSAgIGdmbjogMDAwMDViZWYgIG1mbjogMDAwMDViZWYNCg0KKFhFTikgWzIw
MTItMDgtMzEgMjE6MzM6NDddICAgZ2ZuOiAwMDAwNWJmMCAgbWZuOiAwMDAwNWJmMA0KDQoo
WEVOKSBbMjAxMi0wOC0zMSAyMTozMzo0N10gICBnZm46IDAwMDA1YmYxICBtZm46IDAwMDA1
YmYxDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjQ3XSAgIGdmbjogMDAwMDViZjIgIG1m
bjogMDAwMDViZjINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NDddICAgZ2ZuOiAwMDAw
NWJmMyAgbWZuOiAwMDAwNWJmMw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo0N10gICBn
Zm46IDAwMDA1YmY0ICBtZm46IDAwMDA1YmY0DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMz
OjQ3XSAgIGdmbjogMDAwMDViZjUgIG1mbjogMDAwMDViZjUNCg0KKFhFTikgWzIwMTItMDgt
MzEgMjE6MzM6NDddICAgZ2ZuOiAwMDAwNWJmNiAgbWZuOiAwMDAwNWJmNg0KDQooWEVOKSBb
MjAxMi0wOC0zMSAyMTozMzo0N10gICBnZm46IDAwMDA1YmY3ICBtZm46IDAwMDA1YmY3DQoN
CihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjQ3XSAgIGdmbjogMDAwMDViZjggIG1mbjogMDAw
MDViZjgNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NDddICAgZ2ZuOiAwMDAwNWJmOSAg
bWZuOiAwMDAwNWJmOQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo0N10gICBnZm46IDAw
MDA1YmZhICBtZm46IDAwMDA1YmZhDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjQ3XSAg
IGdmbjogMDAwMDViZmIgIG1mbjogMDAwMDViZmINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6
MzM6NDddICAgZ2ZuOiAwMDAwNWJmYyAgbWZuOiAwMDAwNWJmYw0KDQooWEVOKSBbMjAxMi0w
OC0zMSAyMTozMzo0N10gICBnZm46IDAwMDA1YmZkICBtZm46IDAwMDA1YmZkDQoNCihYRU4p
IFsyMDEyLTA4LTMxIDIxOjMzOjQ3XSAgIGdmbjogMDAwMDViZmUgIG1mbjogMDAwMDViZmUN
Cg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NDddICAgZ2ZuOiAwMDAwNWJmZiAgbWZuOiAw
MDAwNWJmZg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo0N10gICBnZm46IDAwMDA1YzAw
ICBtZm46IDAwMDA1YzAwDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjQ3XSAgIGdmbjog
MDAwMDVjMDEgIG1mbjogMDAwMDVjMDENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NDdd
ICAgZ2ZuOiAwMDAwNWMwMiAgbWZuOiAwMDAwNWMwMg0KDQooWEVOKSBbMjAxMi0wOC0zMSAy
MTozMzo0N10gICBnZm46IDAwMDA1YzAzICBtZm46IDAwMDA1YzAzDQoNCihYRU4pIFsyMDEy
LTA4LTMxIDIxOjMzOjQ3XSAgIGdmbjogMDAwMDVjMDQgIG1mbjogMDAwMDVjMDQNCg0KKFhF
TikgWzIwMTItMDgtMzEgMjE6MzM6NDddICAgZ2ZuOiAwMDAwNWMwNSAgbWZuOiAwMDAwNWMw
NQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo0OF0gICBnZm46IDAwMDA1YzA2ICBtZm46
IDAwMDA1YzA2DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjQ4XSAgIGdmbjogMDAwMDVj
MDcgIG1mbjogMDAwMDVjMDcNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NDhdICAgZ2Zu
OiAwMDAwNWMwOCAgbWZuOiAwMDAwNWMwOA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo0
OF0gICBnZm46IDAwMDA1YzA5ICBtZm46IDAwMDA1YzA5DQoNCihYRU4pIFsyMDEyLTA4LTMx
IDIxOjMzOjQ4XSAgIGdmbjogMDAwMDVjMGEgIG1mbjogMDAwMDVjMGENCg0KKFhFTikgWzIw
MTItMDgtMzEgMjE6MzM6NDhdICAgZ2ZuOiAwMDAwNWMwYiAgbWZuOiAwMDAwNWMwYg0KDQoo
WEVOKSBbMjAxMi0wOC0zMSAyMTozMzo0OF0gICBnZm46IDAwMDA1YzBjICBtZm46IDAwMDA1
YzBjDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjQ4XSAgIGdmbjogMDAwMDVjMGQgIG1m
bjogMDAwMDVjMGQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NDhdICAgZ2ZuOiAwMDAw
NWMwZSAgbWZuOiAwMDAwNWMwZQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo0OF0gICBn
Zm46IDAwMDA1YzBmICBtZm46IDAwMDA1YzBmDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMz
OjQ4XSAgIGdmbjogMDAwMDVjMTAgIG1mbjogMDAwMDVjMTANCg0KKFhFTikgWzIwMTItMDgt
MzEgMjE6MzM6NDhdICAgZ2ZuOiAwMDAwNWMxMSAgbWZuOiAwMDAwNWMxMQ0KDQooWEVOKSBb
MjAxMi0wOC0zMSAyMTozMzo0OF0gICBnZm46IDAwMDA1YzEyICBtZm46IDAwMDA1YzEyDQoN
CihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjQ4XSAgIGdmbjogMDAwMDVjMTMgIG1mbjogMDAw
MDVjMTMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NDhdICAgZ2ZuOiAwMDAwNWMxNCAg
bWZuOiAwMDAwNWMxNA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo0OF0gICBnZm46IDAw
MDA1YzE1ICBtZm46IDAwMDA1YzE1DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjQ4XSAg
IGdmbjogMDAwMDVjMTYgIG1mbjogMDAwMDVjMTYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6
MzM6NDhdICAgZ2ZuOiAwMDAwNWMxNyAgbWZuOiAwMDAwNWMxNw0KDQooWEVOKSBbMjAxMi0w
OC0zMSAyMTozMzo0OF0gICBnZm46IDAwMDA1YzE4ICBtZm46IDAwMDA1YzE4DQoNCihYRU4p
IFsyMDEyLTA4LTMxIDIxOjMzOjQ4XSAgIGdmbjogMDAwMDVjMTkgIG1mbjogMDAwMDVjMTkN
Cg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NDhdICAgZ2ZuOiAwMDAwNWMxYSAgbWZuOiAw
MDAwNWMxYQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo0OF0gICBnZm46IDAwMDA1YzFi
ICBtZm46IDAwMDA1YzFiDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjQ4XSAgIGdmbjog
MDAwMDVjMWMgIG1mbjogMDAwMDVjMWMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NDhd
ICAgZ2ZuOiAwMDAwNWMxZCAgbWZuOiAwMDAwNWMxZA0KDQooWEVOKSBbMjAxMi0wOC0zMSAy
MTozMzo0OF0gICBnZm46IDAwMDA1YzFlICBtZm46IDAwMDA1YzFlDQoNCihYRU4pIFsyMDEy
LTA4LTMxIDIxOjMzOjQ4XSAgIGdmbjogMDAwMDVjMWYgIG1mbjogMDAwMDVjMWYNCg0KKFhF
TikgWzIwMTItMDgtMzEgMjE6MzM6NDhdICAgZ2ZuOiAwMDAwNWMyMCAgbWZuOiAwMDAwNWMy
MA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo0OF0gICBnZm46IDAwMDA1YzIxICBtZm46
IDAwMDA1YzIxDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjQ4XSAgIGdmbjogMDAwMDVj
MjIgIG1mbjogMDAwMDVjMjINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NDhdICAgZ2Zu
OiAwMDAwNWMyMyAgbWZuOiAwMDAwNWMyMw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo0
OF0gICBnZm46IDAwMDA1YzI0ICBtZm46IDAwMDA1YzI0DQoNCihYRU4pIFsyMDEyLTA4LTMx
IDIxOjMzOjQ4XSAgIGdmbjogMDAwMDVjMjUgIG1mbjogMDAwMDVjMjUNCg0KKFhFTikgWzIw
MTItMDgtMzEgMjE6MzM6NDhdICAgZ2ZuOiAwMDAwNWMyNiAgbWZuOiAwMDAwNWMyNg0KDQoo
WEVOKSBbMjAxMi0wOC0zMSAyMTozMzo0OF0gICBnZm46IDAwMDA1YzI3ICBtZm46IDAwMDA1
YzI3DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjQ4XSAgIGdmbjogMDAwMDVjMjggIG1m
bjogMDAwMDVjMjgNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NDhdICAgZ2ZuOiAwMDAw
NWMyOSAgbWZuOiAwMDAwNWMyOQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo0OF0gICBn
Zm46IDAwMDA1YzJhICBtZm46IDAwMDA1YzJhDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMz
OjQ4XSAgIGdmbjogMDAwMDVjMmIgIG1mbjogMDAwMDVjMmINCg0KKFhFTikgWzIwMTItMDgt
MzEgMjE6MzM6NDhdICAgZ2ZuOiAwMDAwNWMyYyAgbWZuOiAwMDAwNWMyYw0KDQooWEVOKSBb
MjAxMi0wOC0zMSAyMTozMzo0OF0gICBnZm46IDAwMDA1YzJkICBtZm46IDAwMDA1YzJkDQoN
CihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjQ4XSAgIGdmbjogMDAwMDVjMmUgIG1mbjogMDAw
MDVjMmUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NDhdICAgZ2ZuOiAwMDAwNWMyZiAg
bWZuOiAwMDAwNWMyZg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo0OF0gICBnZm46IDAw
MDA1YzMwICBtZm46IDAwMDA1YzMwDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjQ4XSAg
IGdmbjogMDAwMDVjMzEgIG1mbjogMDAwMDVjMzENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6
MzM6NDhdICAgZ2ZuOiAwMDAwNWMzMiAgbWZuOiAwMDAwNWMzMg0KDQooWEVOKSBbMjAxMi0w
OC0zMSAyMTozMzo0OF0gICBnZm46IDAwMDA1YzMzICBtZm46IDAwMDA1YzMzDQoNCihYRU4p
IFsyMDEyLTA4LTMxIDIxOjMzOjQ4XSAgIGdmbjogMDAwMDVjMzQgIG1mbjogMDAwMDVjMzQN
Cg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NDhdICAgZ2ZuOiAwMDAwNWMzNSAgbWZuOiAw
MDAwNWMzNQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo0OF0gICBnZm46IDAwMDA1YzM2
ICBtZm46IDAwMDA1YzM2DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjQ4XSAgIGdmbjog
MDAwMDVjMzcgIG1mbjogMDAwMDVjMzcNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NDhd
ICAgZ2ZuOiAwMDAwNWMzOCAgbWZuOiAwMDAwNWMzOA0KDQooWEVOKSBbMjAxMi0wOC0zMSAy
MTozMzo0OF0gICBnZm46IDAwMDA1YzM5ICBtZm46IDAwMDA1YzM5DQoNCihYRU4pIFsyMDEy
LTA4LTMxIDIxOjMzOjQ4XSAgIGdmbjogMDAwMDVjM2EgIG1mbjogMDAwMDVjM2ENCg0KKFhF
TikgWzIwMTItMDgtMzEgMjE6MzM6NDhdICAgZ2ZuOiAwMDAwNWMzYiAgbWZuOiAwMDAwNWMz
Yg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo0OF0gICBnZm46IDAwMDA1YzNjICBtZm46
IDAwMDA1YzNjDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjQ4XSAgIGdmbjogMDAwMDVj
M2QgIG1mbjogMDAwMDVjM2QNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NDhdICAgZ2Zu
OiAwMDAwNWMzZSAgbWZuOiAwMDAwNWMzZQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo0
OF0gICBnZm46IDAwMDA1YzNmICBtZm46IDAwMDA1YzNmDQoNCihYRU4pIFsyMDEyLTA4LTMx
IDIxOjMzOjQ4XSAgIGdmbjogMDAwMDVjNDAgIG1mbjogMDAwMDVjNDANCg0KKFhFTikgWzIw
MTItMDgtMzEgMjE6MzM6NDhdICAgZ2ZuOiAwMDAwNWM0MSAgbWZuOiAwMDAwNWM0MQ0KDQoo
WEVOKSBbMjAxMi0wOC0zMSAyMTozMzo0OF0gICBnZm46IDAwMDA1YzQyICBtZm46IDAwMDA1
YzQyDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjQ4XSAgIGdmbjogMDAwMDVjNDMgIG1m
bjogMDAwMDVjNDMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NDhdICAgZ2ZuOiAwMDAw
NWM0NCAgbWZuOiAwMDAwNWM0NA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo0OF0gICBn
Zm46IDAwMDA1YzQ1ICBtZm46IDAwMDA1YzQ1DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMz
OjQ5XSAgIGdmbjogMDAwMDVjNDYgIG1mbjogMDAwMDVjNDYNCg0KKFhFTikgWzIwMTItMDgt
MzEgMjE6MzM6NDldICAgZ2ZuOiAwMDAwNWM0NyAgbWZuOiAwMDAwNWM0Nw0KDQooWEVOKSBb
MjAxMi0wOC0zMSAyMTozMzo0OV0gICBnZm46IDAwMDA1YzQ4ICBtZm46IDAwMDA1YzQ4DQoN
CihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjQ5XSAgIGdmbjogMDAwMDVjNDkgIG1mbjogMDAw
MDVjNDkNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NDldICAgZ2ZuOiAwMDAwNWM0YSAg
bWZuOiAwMDAwNWM0YQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo0OV0gICBnZm46IDAw
MDA1YzRiICBtZm46IDAwMDA1YzRiDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjQ5XSAg
IGdmbjogMDAwMDVjNGMgIG1mbjogMDAwMDVjNGMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6
MzM6NDldICAgZ2ZuOiAwMDAwNWM0ZCAgbWZuOiAwMDAwNWM0ZA0KDQooWEVOKSBbMjAxMi0w
OC0zMSAyMTozMzo0OV0gICBnZm46IDAwMDA1YzRlICBtZm46IDAwMDA1YzRlDQoNCihYRU4p
IFsyMDEyLTA4LTMxIDIxOjMzOjQ5XSAgIGdmbjogMDAwMDVjNGYgIG1mbjogMDAwMDVjNGYN
Cg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NDldICAgZ2ZuOiAwMDAwNWM1MCAgbWZuOiAw
MDAwNWM1MA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo0OV0gICBnZm46IDAwMDA1YzUx
ICBtZm46IDAwMDA1YzUxDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjQ5XSAgIGdmbjog
MDAwMDVjNTIgIG1mbjogMDAwMDVjNTINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NDld
ICAgZ2ZuOiAwMDAwNWM1MyAgbWZuOiAwMDAwNWM1Mw0KDQooWEVOKSBbMjAxMi0wOC0zMSAy
MTozMzo0OV0gICBnZm46IDAwMDA1YzU0ICBtZm46IDAwMDA1YzU0DQoNCihYRU4pIFsyMDEy
LTA4LTMxIDIxOjMzOjQ5XSAgIGdmbjogMDAwMDVjNTUgIG1mbjogMDAwMDVjNTUNCg0KKFhF
TikgWzIwMTItMDgtMzEgMjE6MzM6NDldICAgZ2ZuOiAwMDAwNWM1NiAgbWZuOiAwMDAwNWM1
Ng0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo0OV0gICBnZm46IDAwMDA1YzU3ICBtZm46
IDAwMDA1YzU3DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjQ5XSAgIGdmbjogMDAwMDVj
NTggIG1mbjogMDAwMDVjNTgNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NDldICAgZ2Zu
OiAwMDAwNWM1OSAgbWZuOiAwMDAwNWM1OQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo0
OV0gICBnZm46IDAwMDA1YzVhICBtZm46IDAwMDA1YzVhDQoNCihYRU4pIFsyMDEyLTA4LTMx
IDIxOjMzOjQ5XSAgIGdmbjogMDAwMDVjNWIgIG1mbjogMDAwMDVjNWINCg0KKFhFTikgWzIw
MTItMDgtMzEgMjE6MzM6NDldICAgZ2ZuOiAwMDAwNWM1YyAgbWZuOiAwMDAwNWM1Yw0KDQoo
WEVOKSBbMjAxMi0wOC0zMSAyMTozMzo0OV0gICBnZm46IDAwMDA1YzVkICBtZm46IDAwMDA1
YzVkDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjQ5XSAgIGdmbjogMDAwMDVjNWUgIG1m
bjogMDAwMDVjNWUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NDldICAgZ2ZuOiAwMDAw
NWM1ZiAgbWZuOiAwMDAwNWM1Zg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo0OV0gICBn
Zm46IDAwMDA1YzYwICBtZm46IDAwMDA1YzYwDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMz
OjQ5XSAgIGdmbjogMDAwMDVjNjEgIG1mbjogMDAwMDVjNjENCg0KKFhFTikgWzIwMTItMDgt
MzEgMjE6MzM6NDldICAgZ2ZuOiAwMDAwNWM2MiAgbWZuOiAwMDAwNWM2Mg0KDQooWEVOKSBb
MjAxMi0wOC0zMSAyMTozMzo0OV0gICBnZm46IDAwMDA1YzYzICBtZm46IDAwMDA1YzYzDQoN
CihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjQ5XSAgIGdmbjogMDAwMDVjNjQgIG1mbjogMDAw
MDVjNjQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NDldICAgZ2ZuOiAwMDAwNWM2NSAg
bWZuOiAwMDAwNWM2NQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo0OV0gICBnZm46IDAw
MDA1YzY2ICBtZm46IDAwMDA1YzY2DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjQ5XSAg
IGdmbjogMDAwMDVjNjcgIG1mbjogMDAwMDVjNjcNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6
MzM6NDldICAgZ2ZuOiAwMDAwNWM2OCAgbWZuOiAwMDAwNWM2OA0KDQooWEVOKSBbMjAxMi0w
OC0zMSAyMTozMzo0OV0gICBnZm46IDAwMDA1YzY5ICBtZm46IDAwMDA1YzY5DQoNCihYRU4p
IFsyMDEyLTA4LTMxIDIxOjMzOjQ5XSAgIGdmbjogMDAwMDVjNmEgIG1mbjogMDAwMDVjNmEN
Cg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NDldICAgZ2ZuOiAwMDAwNWM2YiAgbWZuOiAw
MDAwNWM2Yg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo0OV0gICBnZm46IDAwMDA1YzZj
ICBtZm46IDAwMDA1YzZjDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjQ5XSAgIGdmbjog
MDAwMDVjNmQgIG1mbjogMDAwMDVjNmQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NDld
ICAgZ2ZuOiAwMDAwNWM2ZSAgbWZuOiAwMDAwNWM2ZQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAy
MTozMzo0OV0gICBnZm46IDAwMDA1YzZmICBtZm46IDAwMDA1YzZmDQoNCihYRU4pIFsyMDEy
LTA4LTMxIDIxOjMzOjQ5XSAgIGdmbjogMDAwMDVjNzAgIG1mbjogMDAwMDVjNzANCg0KKFhF
TikgWzIwMTItMDgtMzEgMjE6MzM6NDldICAgZ2ZuOiAwMDAwNWM3MSAgbWZuOiAwMDAwNWM3
MQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo0OV0gICBnZm46IDAwMDA1YzcyICBtZm46
IDAwMDA1YzcyDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjQ5XSAgIGdmbjogMDAwMDVj
NzMgIG1mbjogMDAwMDVjNzMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NDldICAgZ2Zu
OiAwMDAwNWM3NCAgbWZuOiAwMDAwNWM3NA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo0
OV0gICBnZm46IDAwMDA1Yzc1ICBtZm46IDAwMDA1Yzc1DQoNCihYRU4pIFsyMDEyLTA4LTMx
IDIxOjMzOjQ5XSAgIGdmbjogMDAwMDVjNzYgIG1mbjogMDAwMDVjNzYNCg0KKFhFTikgWzIw
MTItMDgtMzEgMjE6MzM6NDldICAgZ2ZuOiAwMDAwNWM3NyAgbWZuOiAwMDAwNWM3Nw0KDQoo
WEVOKSBbMjAxMi0wOC0zMSAyMTozMzo0OV0gICBnZm46IDAwMDA1Yzc4ICBtZm46IDAwMDA1
Yzc4DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjQ5XSAgIGdmbjogMDAwMDVjNzkgIG1m
bjogMDAwMDVjNzkNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NDldICAgZ2ZuOiAwMDAw
NWM3YSAgbWZuOiAwMDAwNWM3YQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo0OV0gICBn
Zm46IDAwMDA1YzdiICBtZm46IDAwMDA1YzdiDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMz
OjQ5XSAgIGdmbjogMDAwMDVjN2MgIG1mbjogMDAwMDVjN2MNCg0KKFhFTikgWzIwMTItMDgt
MzEgMjE6MzM6NDldICAgZ2ZuOiAwMDAwNWM3ZCAgbWZuOiAwMDAwNWM3ZA0KDQooWEVOKSBb
MjAxMi0wOC0zMSAyMTozMzo0OV0gICBnZm46IDAwMDA1YzdlICBtZm46IDAwMDA1YzdlDQoN
CihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjQ5XSAgIGdmbjogMDAwMDVjN2YgIG1mbjogMDAw
MDVjN2YNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NDldICAgZ2ZuOiAwMDAwNWM4MCAg
bWZuOiAwMDAwNWM4MA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo0OV0gICBnZm46IDAw
MDA1YzgxICBtZm46IDAwMDA1YzgxDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjQ5XSAg
IGdmbjogMDAwMDVjODIgIG1mbjogMDAwMDVjODINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6
MzM6NDldICAgZ2ZuOiAwMDAwNWM4MyAgbWZuOiAwMDAwNWM4Mw0KDQooWEVOKSBbMjAxMi0w
OC0zMSAyMTozMzo0OV0gICBnZm46IDAwMDA1Yzg0ICBtZm46IDAwMDA1Yzg0DQoNCihYRU4p
IFsyMDEyLTA4LTMxIDIxOjMzOjQ5XSAgIGdmbjogMDAwMDVjODUgIG1mbjogMDAwMDVjODUN
Cg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NDldICAgZ2ZuOiAwMDAwNWM4NiAgbWZuOiAw
MDAwNWM4Ng0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo1MF0gICBnZm46IDAwMDA1Yzg3
ICBtZm46IDAwMDA1Yzg3DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjUwXSAgIGdmbjog
MDAwMDVjODggIG1mbjogMDAwMDVjODgNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NTBd
ICAgZ2ZuOiAwMDAwNWM4OSAgbWZuOiAwMDAwNWM4OQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAy
MTozMzo1MF0gICBnZm46IDAwMDA1YzhhICBtZm46IDAwMDA1YzhhDQoNCihYRU4pIFsyMDEy
LTA4LTMxIDIxOjMzOjUwXSAgIGdmbjogMDAwMDVjOGIgIG1mbjogMDAwMDVjOGINCg0KKFhF
TikgWzIwMTItMDgtMzEgMjE6MzM6NTBdICAgZ2ZuOiAwMDAwNWM4YyAgbWZuOiAwMDAwNWM4
Yw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo1MF0gICBnZm46IDAwMDA1YzhkICBtZm46
IDAwMDA1YzhkDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjUwXSAgIGdmbjogMDAwMDVj
OGUgIG1mbjogMDAwMDVjOGUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NTBdICAgZ2Zu
OiAwMDAwNWM4ZiAgbWZuOiAwMDAwNWM4Zg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo1
MF0gICBnZm46IDAwMDA1YzkwICBtZm46IDAwMDA1YzkwDQoNCihYRU4pIFsyMDEyLTA4LTMx
IDIxOjMzOjUwXSAgIGdmbjogMDAwMDVjOTEgIG1mbjogMDAwMDVjOTENCg0KKFhFTikgWzIw
MTItMDgtMzEgMjE6MzM6NTBdICAgZ2ZuOiAwMDAwNWM5MiAgbWZuOiAwMDAwNWM5Mg0KDQoo
WEVOKSBbMjAxMi0wOC0zMSAyMTozMzo1MF0gICBnZm46IDAwMDA1YzkzICBtZm46IDAwMDA1
YzkzDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjUwXSAgIGdmbjogMDAwMDVjOTQgIG1m
bjogMDAwMDVjOTQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NTBdICAgZ2ZuOiAwMDAw
NWM5NSAgbWZuOiAwMDAwNWM5NQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo1MF0gICBn
Zm46IDAwMDA1Yzk2ICBtZm46IDAwMDA1Yzk2DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMz
OjUwXSAgIGdmbjogMDAwMDVjOTcgIG1mbjogMDAwMDVjOTcNCg0KKFhFTikgWzIwMTItMDgt
MzEgMjE6MzM6NTBdICAgZ2ZuOiAwMDAwNWM5OCAgbWZuOiAwMDAwNWM5OA0KDQooWEVOKSBb
MjAxMi0wOC0zMSAyMTozMzo1MF0gICBnZm46IDAwMDA1Yzk5ICBtZm46IDAwMDA1Yzk5DQoN
CihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjUwXSAgIGdmbjogMDAwMDVjOWEgIG1mbjogMDAw
MDVjOWENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NTBdICAgZ2ZuOiAwMDAwNWM5YiAg
bWZuOiAwMDAwNWM5Yg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo1MF0gICBnZm46IDAw
MDA1YzljICBtZm46IDAwMDA1YzljDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjUwXSAg
IGdmbjogMDAwMDVjOWQgIG1mbjogMDAwMDVjOWQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6
MzM6NTBdICAgZ2ZuOiAwMDAwNWM5ZSAgbWZuOiAwMDAwNWM5ZQ0KDQooWEVOKSBbMjAxMi0w
OC0zMSAyMTozMzo1MF0gICBnZm46IDAwMDA1YzlmICBtZm46IDAwMDA1YzlmDQoNCihYRU4p
IFsyMDEyLTA4LTMxIDIxOjMzOjUwXSAgIGdmbjogMDAwMDVjYTAgIG1mbjogMDAwMDVjYTAN
Cg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NTBdICAgZ2ZuOiAwMDAwNWNhMSAgbWZuOiAw
MDAwNWNhMQ0KDQpbICA0OTYuNDE4NjcxXSBhKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NTBd
ICAgZ2ZuOiAwMDAwNWNhMiAgbWZuOiAwMDAwNWNhMg0KDQp0YTMuMDA6IHFjIHRpbWVvKFhF
TikgWzIwMTItMDgtMzEgMjE6MzM6NTBdICAgZ2ZuOiAwMDAwNWNhMyAgbWZuOiAwMDAwNWNh
Mw0KDQp1dCAoY21kIDB4ZWMpDQoNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NTBdICAg
Z2ZuOiAwMDAwNWNhNCAgbWZuOiAwMDAwNWNhNA0KDQpbICA0OTYuNDc2OTUxXSBhKFhFTikg
WzIwMTItMDgtMzEgMjE6MzM6NTBdICAgZ2ZuOiAwMDAwNWNhNSAgbWZuOiAwMDAwNWNhNQ0K
DQp0YTMuMDA6IGZhaWxlZCB0byBJREVOVElGWSAoSS9PIChYRU4pIFsyMDEyLTA4LTMxIDIx
OjMzOjUwXSAgIGdmbjogMDAwMDVjYTYgIG1mbjogMDAwMDVjYTYNCg0KZXJyb3IsIGVycl9t
YXNrPShYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjUwXSAgIGdmbjogMDAwMDVjYTcgIG1mbjog
MDAwMDVjYTcNCg0KMHg0KQ0KDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjUwXSAgIGdm
bjogMDAwMDVjYTggIG1mbjogMDAwMDVjYTgNCg0KWyAgNDk2LjU1NTkwNF0gYShYRU4pIFsy
MDEyLTA4LTMxIDIxOjMzOjUwXSAgIGdmbjogMDAwMDVjYTkgIG1mbjogMDAwMDVjYTkNCg0K
dGEzLjAwOiByZXZhbGlkYShYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjUwXSAgIGdmbjogMDAw
MDVjYWEgIG1mbjogMDAwMDVjYWENCg0KdGlvbiBmYWlsZWQgKGVycihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMzOjUwXSAgIGdmbjogMDAwMDVjYWIgIG1mbjogMDAwMDVjYWINCg0Kbm89LTUp
DQoNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NTBdICAgZ2ZuOiAwMDAwNWNhYyAgbWZu
OiAwMDAwNWNhYw0KDQpbICA0OTYuNjM1MDE1XSBhKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6
NTBdICAgZ2ZuOiAwMDAwNWNhZCAgbWZuOiAwMDAwNWNhZA0KDQp0YTM6IGxpbWl0aW5nIFNB
VEEgbGluayBzcGVlZCB0byhYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjUwXSAgIGdmbjogMDAw
MDVjYWUgIG1mbjogMDAwMDVjYWUNCg0KIDMuMCBHYnBzDQoNCg0KKFhFTikgWzIwMTItMDgt
MzEgMjE6MzM6NTBdICAgZ2ZuOiAwMDAwNWNhZiAgbWZuOiAwMDAwNWNhZg0KDQpbICA0OTYu
Njk3MzMwXSBhdGEzOiBoYXJkIHJlc2V0dChYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjUwXSAg
IGdmbjogMDAwMDVjYjAgIG1mbjogMDAwMDVjYjANCg0KaW5nIGxpbmsNCg0KDQooWEVOKSBb
MjAxMi0wOC0zMSAyMTozMzo1MF0gICBnZm46IDAwMDA1Y2IxICBtZm46IDAwMDA1Y2IxDQoN
CihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjUwXSAgIGdmbjogMDAwMDVjYjIgIG1mbjogMDAw
MDVjYjINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NTBdICAgZ2ZuOiAwMDAwNWNiMyAg
bWZuOiAwMDAwNWNiMw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo1MF0gICBnZm46IDAw
MDA1Y2I0ICBtZm46IDAwMDA1Y2I0DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjUwXSAg
IGdmbjogMDAwMDVjYjUgIG1mbjogMDAwMDVjYjUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6
MzM6NTBdICAgZ2ZuOiAwMDAwNWNiNiAgbWZuOiAwMDAwNWNiNg0KDQooWEVOKSBbMjAxMi0w
OC0zMSAyMTozMzo1MF0gICBnZm46IDAwMDA1Y2I3ICBtZm46IDAwMDA1Y2I3DQoNCihYRU4p
IFsyMDEyLTA4LTMxIDIxOjMzOjUwXSAgIGdmbjogMDAwMDVjYjggIG1mbjogMDAwMDVjYjgN
Cg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NTBdICAgZ2ZuOiAwMDAwNWNiOSAgbWZuOiAw
MDAwNWNiOQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo1MF0gICBnZm46IDAwMDA1Y2Jh
ICBtZm46IDAwMDA1Y2JhDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjUwXSAgIGdmbjog
MDAwMDVjYmIgIG1mbjogMDAwMDVjYmINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NTBd
ICAgZ2ZuOiAwMDAwNWNiYyAgbWZuOiAwMDAwNWNiYw0KDQooWEVOKSBbMjAxMi0wOC0zMSAy
MTozMzo1MF0gICBnZm46IDAwMDA1Y2JkICBtZm46IDAwMDA1Y2JkDQoNCihYRU4pIFsyMDEy
LTA4LTMxIDIxOjMzOjUwXSAgIGdmbjogMDAwMDVjYmUgIG1mbjogMDAwMDVjYmUNCg0KKFhF
TikgWzIwMTItMDgtMzEgMjE6MzM6NTBdICAgZ2ZuOiAwMDAwNWNiZiAgbWZuOiAwMDAwNWNi
Zg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo1MF0gICBnZm46IDAwMDA1Y2MwICBtZm46
IDAwMDA1Y2MwDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjUwXSAgIGdmbjogMDAwMDVj
YzEgIG1mbjogMDAwMDVjYzENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NTFdICAgZ2Zu
OiAwMDAwNWNjMiAgbWZuOiAwMDAwNWNjMg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo1
MV0gICBnZm46IDAwMDA1Y2MzICBtZm46IDAwMDA1Y2MzDQoNCihYRU4pIFsyMDEyLTA4LTMx
IDIxOjMzOjUxXSAgIGdmbjogMDAwMDVjYzQgIG1mbjogMDAwMDVjYzQNCg0KKFhFTikgWzIw
MTItMDgtMzEgMjE6MzM6NTFdICAgZ2ZuOiAwMDAwNWNjNSAgbWZuOiAwMDAwNWNjNQ0KDQoo
WEVOKSBbMjAxMi0wOC0zMSAyMTozMzo1MV0gICBnZm46IDAwMDA1Y2M2ICBtZm46IDAwMDA1
Y2M2DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjUxXSAgIGdmbjogMDAwMDVjYzcgIG1m
bjogMDAwMDVjYzcNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NTFdICAgZ2ZuOiAwMDAw
NWNjOCAgbWZuOiAwMDAwNWNjOA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo1MV0gICBn
Zm46IDAwMDA1Y2M5ICBtZm46IDAwMDA1Y2M5DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMz
OjUxXSAgIGdmbjogMDAwMDVjY2EgIG1mbjogMDAwMDVjY2ENCg0KKFhFTikgWzIwMTItMDgt
MzEgMjE6MzM6NTFdICAgZ2ZuOiAwMDAwNWNjYiAgbWZuOiAwMDAwNWNjYg0KDQooWEVOKSBb
MjAxMi0wOC0zMSAyMTozMzo1MV0gICBnZm46IDAwMDA1Y2NjICBtZm46IDAwMDA1Y2NjDQoN
CihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjUxXSAgIGdmbjogMDAwMDVjY2QgIG1mbjogMDAw
MDVjY2QNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NTFdICAgZ2ZuOiAwMDAwNWNjZSAg
bWZuOiAwMDAwNWNjZQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo1MV0gICBnZm46IDAw
MDA1Y2NmICBtZm46IDAwMDA1Y2NmDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjUxXSAg
IGdmbjogMDAwMDVjZDAgIG1mbjogMDAwMDVjZDANCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6
MzM6NTFdICAgZ2ZuOiAwMDAwNWNkMSAgbWZuOiAwMDAwNWNkMQ0KDQpbICA0OTcuMjQyMTc3
XSBhKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NTFdICAgZ2ZuOiAwMDAwNWNkMiAgbWZuOiAw
MDAwNWNkMg0KDQp0YTM6IFNBVEEgbGluayB1KFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NTFd
ICAgZ2ZuOiAwMDAwNWNkMyAgbWZuOiAwMDAwNWNkMw0KDQpwIDMuMCBHYnBzIChTU3RhdHVz
IDEyMyBTQ29udHJvbChYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjUxXSAgIGdmbjogMDAwMDVj
ZDQgIG1mbjogMDAwMDVjZDQNCg0KIDMyMCkNCg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
Mzo1MV0gICBnZm46IDAwMDA1Y2Q1ICBtZm46IDAwMDA1Y2Q1DQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMzOjUxXSAgIGdmbjogMDAwMDVjZDYgIG1mbjogMDAwMDVjZDYNCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzM6NTFdICAgZ2ZuOiAwMDAwNWNkNyAgbWZuOiAwMDAwNWNkNw0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo1MV0gICBnZm46IDAwMDA1Y2Q4ICBtZm46IDAw
MDA1Y2Q4DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjUxXSAgIGdmbjogMDAwMDVjZDkg
IG1mbjogMDAwMDVjZDkNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NTFdICAgZ2ZuOiAw
MDAwNWNkYSAgbWZuOiAwMDAwNWNkYQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo1MV0g
ICBnZm46IDAwMDA1Y2RiICBtZm46IDAwMDA1Y2RiDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMzOjUxXSAgIGdmbjogMDAwMDVjZGMgIG1mbjogMDAwMDVjZGMNCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzM6NTFdICAgZ2ZuOiAwMDAwNWNkZCAgbWZuOiAwMDAwNWNkZA0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMzo1MV0gICBnZm46IDAwMDA1Y2RlICBtZm46IDAwMDA1Y2Rl
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjUxXSAgIGdmbjogMDAwMDVjZGYgIG1mbjog
MDAwMDVjZGYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NTFdICAgZ2ZuOiAwMDAwNWNl
MCAgbWZuOiAwMDAwNWNlMA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo1MV0gICBnZm46
IDAwMDA1Y2UxICBtZm46IDAwMDA1Y2UxDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjUx
XSAgIGdmbjogMDAwMDVjZTIgIG1mbjogMDAwMDVjZTINCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzM6NTFdICAgZ2ZuOiAwMDAwNWNlMyAgbWZuOiAwMDAwNWNlMw0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMzo1MV0gICBnZm46IDAwMDA1Y2U0ICBtZm46IDAwMDA1Y2U0DQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMzOjUxXSAgIGdmbjogMDAwMDVjZTUgIG1mbjogMDAwMDVj
ZTUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NTFdICAgZ2ZuOiAwMDAwNWNlNiAgbWZu
OiAwMDAwNWNlNg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo1MV0gICBnZm46IDAwMDA1
Y2U3ICBtZm46IDAwMDA1Y2U3DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjUxXSAgIGdm
bjogMDAwMDVjZTggIG1mbjogMDAwMDVjZTgNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6
NTFdICAgZ2ZuOiAwMDAwNWNlOSAgbWZuOiAwMDAwNWNlOQ0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMzo1MV0gICBnZm46IDAwMDA1Y2VhICBtZm46IDAwMDA1Y2VhDQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMzOjUxXSAgIGdmbjogMDAwMDVjZWIgIG1mbjogMDAwMDVjZWINCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NTFdICAgZ2ZuOiAwMDAwNWNlYyAgbWZuOiAwMDAw
NWNlYw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo1MV0gICBnZm46IDAwMDA1Y2VkICBt
Zm46IDAwMDA1Y2VkDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjUxXSAgIGdmbjogMDAw
MDVjZWUgIG1mbjogMDAwMDVjZWUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NTFdICAg
Z2ZuOiAwMDAwNWNlZiAgbWZuOiAwMDAwNWNlZg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
Mzo1MV0gICBnZm46IDAwMDA1Y2YwICBtZm46IDAwMDA1Y2YwDQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMzOjUxXSAgIGdmbjogMDAwMDVjZjEgIG1mbjogMDAwMDVjZjENCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzM6NTFdICAgZ2ZuOiAwMDAwNWNmMiAgbWZuOiAwMDAwNWNmMg0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo1MV0gICBnZm46IDAwMDA1Y2YzICBtZm46IDAw
MDA1Y2YzDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjUxXSAgIGdmbjogMDAwMDVjZjQg
IG1mbjogMDAwMDVjZjQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NTFdICAgZ2ZuOiAw
MDAwNWNmNSAgbWZuOiAwMDAwNWNmNQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo1MV0g
ICBnZm46IDAwMDA1Y2Y2ICBtZm46IDAwMDA1Y2Y2DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMzOjUxXSAgIGdmbjogMDAwMDVjZjcgIG1mbjogMDAwMDVjZjcNCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzM6NTFdICAgZ2ZuOiAwMDAwNWNmOCAgbWZuOiAwMDAwNWNmOA0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMzo1MV0gICBnZm46IDAwMDA1Y2Y5ICBtZm46IDAwMDA1Y2Y5
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjUxXSAgIGdmbjogMDAwMDVjZmEgIG1mbjog
MDAwMDVjZmENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NTFdICAgZ2ZuOiAwMDAwNWNm
YiAgbWZuOiAwMDAwNWNmYg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo1MV0gICBnZm46
IDAwMDA1Y2ZjICBtZm46IDAwMDA1Y2ZjDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjUx
XSAgIGdmbjogMDAwMDVjZmQgIG1mbjogMDAwMDVjZmQNCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzM6NTFdICAgZ2ZuOiAwMDAwNWNmZSAgbWZuOiAwMDAwNWNmZQ0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMzo1MV0gICBnZm46IDAwMDA1Y2ZmICBtZm46IDAwMDA1Y2ZmDQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMzOjUxXSAgIGdmbjogMDAwMDVkMDAgIG1mbjogMDAwMDVk
MDANCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NTJdICAgZ2ZuOiAwMDAwNWQwMSAgbWZu
OiAwMDAwNWQwMQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo1Ml0gICBnZm46IDAwMDA1
ZDAyICBtZm46IDAwMDA1ZDAyDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjUyXSAgIGdm
bjogMDAwMDVkMDMgIG1mbjogMDAwMDVkMDMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6
NTJdICAgZ2ZuOiAwMDAwNWQwNCAgbWZuOiAwMDAwNWQwNA0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMzo1Ml0gICBnZm46IDAwMDA1ZDA1ICBtZm46IDAwMDA1ZDA1DQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMzOjUyXSAgIGdmbjogMDAwMDVkMDYgIG1mbjogMDAwMDVkMDYNCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NTJdICAgZ2ZuOiAwMDAwNWQwNyAgbWZuOiAwMDAw
NWQwNw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo1Ml0gICBnZm46IDAwMDA1ZDA4ICBt
Zm46IDAwMDA1ZDA4DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjUyXSAgIGdmbjogMDAw
MDVkMDkgIG1mbjogMDAwMDVkMDkNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NTJdICAg
Z2ZuOiAwMDAwNWQwYSAgbWZuOiAwMDAwNWQwYQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
Mzo1Ml0gICBnZm46IDAwMDA1ZDBiICBtZm46IDAwMDA1ZDBiDQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMzOjUyXSAgIGdmbjogMDAwMDVkMGMgIG1mbjogMDAwMDVkMGMNCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzM6NTJdICAgZ2ZuOiAwMDAwNWQwZCAgbWZuOiAwMDAwNWQwZA0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo1Ml0gICBnZm46IDAwMDA1ZDBlICBtZm46IDAw
MDA1ZDBlDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjUyXSAgIGdmbjogMDAwMDVkMGYg
IG1mbjogMDAwMDVkMGYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NTJdICAgZ2ZuOiAw
MDAwNWQxMCAgbWZuOiAwMDAwNWQxMA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo1Ml0g
ICBnZm46IDAwMDA1ZDExICBtZm46IDAwMDA1ZDExDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMzOjUyXSAgIGdmbjogMDAwMDVkMTIgIG1mbjogMDAwMDVkMTINCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzM6NTJdICAgZ2ZuOiAwMDAwNWQxMyAgbWZuOiAwMDAwNWQxMw0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMzo1Ml0gICBnZm46IDAwMDA1ZDE0ICBtZm46IDAwMDA1ZDE0
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjUyXSAgIGdmbjogMDAwMDVkMTUgIG1mbjog
MDAwMDVkMTUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NTJdICAgZ2ZuOiAwMDAwNWQx
NiAgbWZuOiAwMDAwNWQxNg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo1Ml0gICBnZm46
IDAwMDA1ZDE3ICBtZm46IDAwMDA1ZDE3DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjUy
XSAgIGdmbjogMDAwMDVkMTggIG1mbjogMDAwMDVkMTgNCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzM6NTJdICAgZ2ZuOiAwMDAwNWQxOSAgbWZuOiAwMDAwNWQxOQ0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMzo1Ml0gICBnZm46IDAwMDA1ZDFhICBtZm46IDAwMDA1ZDFhDQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMzOjUyXSAgIGdmbjogMDAwMDVkMWIgIG1mbjogMDAwMDVk
MWINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NTJdICAgZ2ZuOiAwMDAwNWQxYyAgbWZu
OiAwMDAwNWQxYw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo1Ml0gICBnZm46IDAwMDA1
ZDFkICBtZm46IDAwMDA1ZDFkDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjUyXSAgIGdm
bjogMDAwMDVkMWUgIG1mbjogMDAwMDVkMWUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6
NTJdICAgZ2ZuOiAwMDAwNWQxZiAgbWZuOiAwMDAwNWQxZg0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMzo1Ml0gICBnZm46IDAwMDA1ZDIwICBtZm46IDAwMDA1ZDIwDQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMzOjUyXSAgIGdmbjogMDAwMDVkMjEgIG1mbjogMDAwMDVkMjENCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NTJdICAgZ2ZuOiAwMDAwNWQyMiAgbWZuOiAwMDAw
NWQyMg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo1Ml0gICBnZm46IDAwMDA1ZDIzICBt
Zm46IDAwMDA1ZDIzDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjUyXSAgIGdmbjogMDAw
MDVkMjQgIG1mbjogMDAwMDVkMjQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NTJdICAg
Z2ZuOiAwMDAwNWQyNSAgbWZuOiAwMDAwNWQyNQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
Mzo1Ml0gICBnZm46IDAwMDA1ZDI2ICBtZm46IDAwMDA1ZDI2DQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMzOjUyXSAgIGdmbjogMDAwMDVkMjcgIG1mbjogMDAwMDVkMjcNCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzM6NTJdICAgZ2ZuOiAwMDAwNWQyOCAgbWZuOiAwMDAwNWQyOA0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo1Ml0gICBnZm46IDAwMDA1ZDI5ICBtZm46IDAw
MDA1ZDI5DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjUyXSAgIGdmbjogMDAwMDVkMmEg
IG1mbjogMDAwMDVkMmENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NTJdICAgZ2ZuOiAw
MDAwNWQyYiAgbWZuOiAwMDAwNWQyYg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo1Ml0g
ICBnZm46IDAwMDA1ZDJjICBtZm46IDAwMDA1ZDJjDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMzOjUyXSAgIGdmbjogMDAwMDVkMmQgIG1mbjogMDAwMDVkMmQNCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzM6NTJdICAgZ2ZuOiAwMDAwNWQyZSAgbWZuOiAwMDAwNWQyZQ0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMzo1Ml0gICBnZm46IDAwMDA1ZDJmICBtZm46IDAwMDA1ZDJm
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjUyXSAgIGdmbjogMDAwMDVkMzAgIG1mbjog
MDAwMDVkMzANCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NTJdICAgZ2ZuOiAwMDAwNWQz
MSAgbWZuOiAwMDAwNWQzMQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo1Ml0gICBnZm46
IDAwMDA1ZDMyICBtZm46IDAwMDA1ZDMyDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjUy
XSAgIGdmbjogMDAwMDVkMzMgIG1mbjogMDAwMDVkMzMNCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzM6NTJdICAgZ2ZuOiAwMDAwNWQzNCAgbWZuOiAwMDAwNWQzNA0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMzo1Ml0gICBnZm46IDAwMDA1ZDM1ICBtZm46IDAwMDA1ZDM1DQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMzOjUyXSAgIGdmbjogMDAwMDVkMzYgIG1mbjogMDAwMDVk
MzYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NTJdICAgZ2ZuOiAwMDAwNWQzNyAgbWZu
OiAwMDAwNWQzNw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo1Ml0gICBnZm46IDAwMDA1
ZDM4ICBtZm46IDAwMDA1ZDM4DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjUyXSAgIGdm
bjogMDAwMDVkMzkgIG1mbjogMDAwMDVkMzkNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6
NTJdICAgZ2ZuOiAwMDAwNWQzYSAgbWZuOiAwMDAwNWQzYQ0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMzo1Ml0gICBnZm46IDAwMDA1ZDNiICBtZm46IDAwMDA1ZDNiDQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMzOjUyXSAgIGdmbjogMDAwMDVkM2MgIG1mbjogMDAwMDVkM2MNCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NTJdICAgZ2ZuOiAwMDAwNWQzZCAgbWZuOiAwMDAw
NWQzZA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo1Ml0gICBnZm46IDAwMDA1ZDNlICBt
Zm46IDAwMDA1ZDNlDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjUyXSAgIGdmbjogMDAw
MDVkM2YgIG1mbjogMDAwMDVkM2YNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NTJdICAg
Z2ZuOiAwMDAwNWQ0MCAgbWZuOiAwMDAwNWQ0MA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
Mzo1M10gICBnZm46IDAwMDA1ZDQxICBtZm46IDAwMDA1ZDQxDQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMzOjUzXSAgIGdmbjogMDAwMDVkNDIgIG1mbjogMDAwMDVkNDINCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzM6NTNdICAgZ2ZuOiAwMDAwNWQ0MyAgbWZuOiAwMDAwNWQ0Mw0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo1M10gICBnZm46IDAwMDA1ZDQ0ICBtZm46IDAw
MDA1ZDQ0DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjUzXSAgIGdmbjogMDAwMDVkNDUg
IG1mbjogMDAwMDVkNDUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NTNdICAgZ2ZuOiAw
MDAwNWQ0NiAgbWZuOiAwMDAwNWQ0Ng0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo1M10g
ICBnZm46IDAwMDA1ZDQ3ICBtZm46IDAwMDA1ZDQ3DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMzOjUzXSAgIGdmbjogMDAwMDVkNDggIG1mbjogMDAwMDVkNDgNCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzM6NTNdICAgZ2ZuOiAwMDAwNWQ0OSAgbWZuOiAwMDAwNWQ0OQ0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMzo1M10gICBnZm46IDAwMDA1ZDRhICBtZm46IDAwMDA1ZDRh
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjUzXSAgIGdmbjogMDAwMDVkNGIgIG1mbjog
MDAwMDVkNGINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NTNdICAgZ2ZuOiAwMDAwNWQ0
YyAgbWZuOiAwMDAwNWQ0Yw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo1M10gICBnZm46
IDAwMDA1ZDRkICBtZm46IDAwMDA1ZDRkDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjUz
XSAgIGdmbjogMDAwMDVkNGUgIG1mbjogMDAwMDVkNGUNCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzM6NTNdICAgZ2ZuOiAwMDAwNWQ0ZiAgbWZuOiAwMDAwNWQ0Zg0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMzo1M10gICBnZm46IDAwMDA1ZDUwICBtZm46IDAwMDA1ZDUwDQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMzOjUzXSAgIGdmbjogMDAwMDVkNTEgIG1mbjogMDAwMDVk
NTENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NTNdICAgZ2ZuOiAwMDAwNWQ1MiAgbWZu
OiAwMDAwNWQ1Mg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo1M10gICBnZm46IDAwMDA1
ZDUzICBtZm46IDAwMDA1ZDUzDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjUzXSAgIGdm
bjogMDAwMDVkNTQgIG1mbjogMDAwMDVkNTQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6
NTNdICAgZ2ZuOiAwMDAwNWQ1NSAgbWZuOiAwMDAwNWQ1NQ0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMzo1M10gICBnZm46IDAwMDA1ZDU2ICBtZm46IDAwMDA1ZDU2DQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMzOjUzXSAgIGdmbjogMDAwMDVkNTcgIG1mbjogMDAwMDVkNTcNCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NTNdICAgZ2ZuOiAwMDAwNWQ1OCAgbWZuOiAwMDAw
NWQ1OA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo1M10gICBnZm46IDAwMDA1ZDU5ICBt
Zm46IDAwMDA1ZDU5DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjUzXSAgIGdmbjogMDAw
MDVkNWEgIG1mbjogMDAwMDVkNWENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NTNdICAg
Z2ZuOiAwMDAwNWQ1YiAgbWZuOiAwMDAwNWQ1Yg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
Mzo1M10gICBnZm46IDAwMDA1ZDVjICBtZm46IDAwMDA1ZDVjDQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMzOjUzXSAgIGdmbjogMDAwMDVkNWQgIG1mbjogMDAwMDVkNWQNCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzM6NTNdICAgZ2ZuOiAwMDAwNWQ1ZSAgbWZuOiAwMDAwNWQ1ZQ0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo1M10gICBnZm46IDAwMDA1ZDVmICBtZm46IDAw
MDA1ZDVmDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjUzXSAgIGdmbjogMDAwMDVkNjAg
IG1mbjogMDAwMDVkNjANCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NTNdICAgZ2ZuOiAw
MDAwNWQ2MSAgbWZuOiAwMDAwNWQ2MQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo1M10g
ICBnZm46IDAwMDA1ZDYyICBtZm46IDAwMDA1ZDYyDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMzOjUzXSAgIGdmbjogMDAwMDVkNjMgIG1mbjogMDAwMDVkNjMNCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzM6NTNdICAgZ2ZuOiAwMDAwNWQ2NCAgbWZuOiAwMDAwNWQ2NA0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMzo1M10gICBnZm46IDAwMDA1ZDY1ICBtZm46IDAwMDA1ZDY1
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjUzXSAgIGdmbjogMDAwMDVkNjYgIG1mbjog
MDAwMDVkNjYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NTNdICAgZ2ZuOiAwMDAwNWQ2
NyAgbWZuOiAwMDAwNWQ2Nw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo1M10gICBnZm46
IDAwMDA1ZDY4ICBtZm46IDAwMDA1ZDY4DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjUz
XSAgIGdmbjogMDAwMDVkNjkgIG1mbjogMDAwMDVkNjkNCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzM6NTNdICAgZ2ZuOiAwMDAwNWQ2YSAgbWZuOiAwMDAwNWQ2YQ0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMzo1M10gICBnZm46IDAwMDA1ZDZiICBtZm46IDAwMDA1ZDZiDQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMzOjUzXSAgIGdmbjogMDAwMDVkNmMgIG1mbjogMDAwMDVk
NmMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NTNdICAgZ2ZuOiAwMDAwNWQ2ZCAgbWZu
OiAwMDAwNWQ2ZA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo1M10gICBnZm46IDAwMDA1
ZDZlICBtZm46IDAwMDA1ZDZlDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjUzXSAgIGdm
bjogMDAwMDVkNmYgIG1mbjogMDAwMDVkNmYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6
NTNdICAgZ2ZuOiAwMDAwNWQ3MCAgbWZuOiAwMDAwNWQ3MA0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMzo1M10gICBnZm46IDAwMDA1ZDcxICBtZm46IDAwMDA1ZDcxDQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMzOjUzXSAgIGdmbjogMDAwMDVkNzIgIG1mbjogMDAwMDVkNzINCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NTNdICAgZ2ZuOiAwMDAwNWQ3MyAgbWZuOiAwMDAw
NWQ3Mw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo1M10gICBnZm46IDAwMDA1ZDc0ICBt
Zm46IDAwMDA1ZDc0DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjUzXSAgIGdmbjogMDAw
MDVkNzUgIG1mbjogMDAwMDVkNzUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NTNdICAg
Z2ZuOiAwMDAwNWQ3NiAgbWZuOiAwMDAwNWQ3Ng0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
Mzo1M10gICBnZm46IDAwMDA1ZDc3ICBtZm46IDAwMDA1ZDc3DQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMzOjUzXSAgIGdmbjogMDAwMDVkNzggIG1mbjogMDAwMDVkNzgNCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzM6NTNdICAgZ2ZuOiAwMDAwNWQ3OSAgbWZuOiAwMDAwNWQ3OQ0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo1M10gICBnZm46IDAwMDA1ZDdhICBtZm46IDAw
MDA1ZDdhDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjUzXSAgIGdmbjogMDAwMDVkN2Ig
IG1mbjogMDAwMDVkN2INCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NTNdICAgZ2ZuOiAw
MDAwNWQ3YyAgbWZuOiAwMDAwNWQ3Yw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo1M10g
ICBnZm46IDAwMDA1ZDdkICBtZm46IDAwMDA1ZDdkDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMzOjUzXSAgIGdmbjogMDAwMDVkN2UgIG1mbjogMDAwMDVkN2UNCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzM6NTNdICAgZ2ZuOiAwMDAwNWQ3ZiAgbWZuOiAwMDAwNWQ3Zg0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMzo1M10gICBnZm46IDAwMDA1ZDgwICBtZm46IDAwMDA1ZDgw
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjU0XSAgIGdmbjogMDAwMDVkODEgIG1mbjog
MDAwMDVkODENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NTRdICAgZ2ZuOiAwMDAwNWQ4
MiAgbWZuOiAwMDAwNWQ4Mg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo1NF0gICBnZm46
IDAwMDA1ZDgzICBtZm46IDAwMDA1ZDgzDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjU0
XSAgIGdmbjogMDAwMDVkODQgIG1mbjogMDAwMDVkODQNCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzM6NTRdICAgZ2ZuOiAwMDAwNWQ4NSAgbWZuOiAwMDAwNWQ4NQ0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMzo1NF0gICBnZm46IDAwMDA1ZDg2ICBtZm46IDAwMDA1ZDg2DQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMzOjU0XSAgIGdmbjogMDAwMDVkODcgIG1mbjogMDAwMDVk
ODcNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NTRdICAgZ2ZuOiAwMDAwNWQ4OCAgbWZu
OiAwMDAwNWQ4OA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo1NF0gICBnZm46IDAwMDA1
ZDg5ICBtZm46IDAwMDA1ZDg5DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjU0XSAgIGdm
bjogMDAwMDVkOGEgIG1mbjogMDAwMDVkOGENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6
NTRdICAgZ2ZuOiAwMDAwNWQ4YiAgbWZuOiAwMDAwNWQ4Yg0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMzo1NF0gICBnZm46IDAwMDA1ZDhjICBtZm46IDAwMDA1ZDhjDQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMzOjU0XSAgIGdmbjogMDAwMDVkOGQgIG1mbjogMDAwMDVkOGQNCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NTRdICAgZ2ZuOiAwMDAwNWQ4ZSAgbWZuOiAwMDAw
NWQ4ZQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo1NF0gICBnZm46IDAwMDA1ZDhmICBt
Zm46IDAwMDA1ZDhmDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjU0XSAgIGdmbjogMDAw
MDVkOTAgIG1mbjogMDAwMDVkOTANCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NTRdICAg
Z2ZuOiAwMDAwNWQ5MSAgbWZuOiAwMDAwNWQ5MQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
Mzo1NF0gICBnZm46IDAwMDA1ZDkyICBtZm46IDAwMDA1ZDkyDQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMzOjU0XSAgIGdmbjogMDAwMDVkOTMgIG1mbjogMDAwMDVkOTMNCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzM6NTRdICAgZ2ZuOiAwMDAwNWQ5NCAgbWZuOiAwMDAwNWQ5NA0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo1NF0gICBnZm46IDAwMDA1ZDk1ICBtZm46IDAw
MDA1ZDk1DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjU0XSAgIGdmbjogMDAwMDVkOTYg
IG1mbjogMDAwMDVkOTYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NTRdICAgZ2ZuOiAw
MDAwNWQ5NyAgbWZuOiAwMDAwNWQ5Nw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo1NF0g
ICBnZm46IDAwMDA1ZDk4ICBtZm46IDAwMDA1ZDk4DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMzOjU0XSAgIGdmbjogMDAwMDVkOTkgIG1mbjogMDAwMDVkOTkNCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzM6NTRdICAgZ2ZuOiAwMDAwNWQ5YSAgbWZuOiAwMDAwNWQ5YQ0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMzo1NF0gICBnZm46IDAwMDA1ZDliICBtZm46IDAwMDA1ZDli
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjU0XSAgIGdmbjogMDAwMDVkOWMgIG1mbjog
MDAwMDVkOWMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NTRdICAgZ2ZuOiAwMDAwNWQ5
ZCAgbWZuOiAwMDAwNWQ5ZA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo1NF0gICBnZm46
IDAwMDA1ZDllICBtZm46IDAwMDA1ZDllDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjU0
XSAgIGdmbjogMDAwMDVkOWYgIG1mbjogMDAwMDVkOWYNCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzM6NTRdICAgZ2ZuOiAwMDAwNWRhMCAgbWZuOiAwMDAwNWRhMA0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMzo1NF0gICBnZm46IDAwMDA1ZGExICBtZm46IDAwMDA1ZGExDQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMzOjU0XSAgIGdmbjogMDAwMDVkYTIgIG1mbjogMDAwMDVk
YTINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NTRdICAgZ2ZuOiAwMDAwNWRhMyAgbWZu
OiAwMDAwNWRhMw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo1NF0gICBnZm46IDAwMDA1
ZGE0ICBtZm46IDAwMDA1ZGE0DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjU0XSAgIGdm
bjogMDAwMDVkYTUgIG1mbjogMDAwMDVkYTUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6
NTRdICAgZ2ZuOiAwMDAwNWRhNiAgbWZuOiAwMDAwNWRhNg0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMzo1NF0gICBnZm46IDAwMDA1ZGE3ICBtZm46IDAwMDA1ZGE3DQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMzOjU0XSAgIGdmbjogMDAwMDVkYTggIG1mbjogMDAwMDVkYTgNCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NTRdICAgZ2ZuOiAwMDAwNWRhOSAgbWZuOiAwMDAw
NWRhOQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo1NF0gICBnZm46IDAwMDA1ZGFhICBt
Zm46IDAwMDA1ZGFhDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjU0XSAgIGdmbjogMDAw
MDVkYWIgIG1mbjogMDAwMDVkYWINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NTRdICAg
Z2ZuOiAwMDAwNWRhYyAgbWZuOiAwMDAwNWRhYw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
Mzo1NF0gICBnZm46IDAwMDA1ZGFkICBtZm46IDAwMDA1ZGFkDQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMzOjU0XSAgIGdmbjogMDAwMDVkYWUgIG1mbjogMDAwMDVkYWUNCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzM6NTRdICAgZ2ZuOiAwMDAwNWRhZiAgbWZuOiAwMDAwNWRhZg0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo1NF0gICBnZm46IDAwMDA1ZGIwICBtZm46IDAw
MDA1ZGIwDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjU0XSAgIGdmbjogMDAwMDVkYjEg
IG1mbjogMDAwMDVkYjENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NTRdICAgZ2ZuOiAw
MDAwNWRiMiAgbWZuOiAwMDAwNWRiMg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo1NF0g
ICBnZm46IDAwMDA1ZGIzICBtZm46IDAwMDA1ZGIzDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMzOjU0XSAgIGdmbjogMDAwMDVkYjQgIG1mbjogMDAwMDVkYjQNCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzM6NTRdICAgZ2ZuOiAwMDAwNWRiNSAgbWZuOiAwMDAwNWRiNQ0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMzo1NF0gICBnZm46IDAwMDA1ZGI2ICBtZm46IDAwMDA1ZGI2
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjU0XSAgIGdmbjogMDAwMDVkYjcgIG1mbjog
MDAwMDVkYjcNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NTRdICAgZ2ZuOiAwMDAwNWRi
OCAgbWZuOiAwMDAwNWRiOA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo1NF0gICBnZm46
IDAwMDA1ZGI5ICBtZm46IDAwMDA1ZGI5DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjU0
XSAgIGdmbjogMDAwMDVkYmEgIG1mbjogMDAwMDVkYmENCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzM6NTRdICAgZ2ZuOiAwMDAwNWRiYiAgbWZuOiAwMDAwNWRiYg0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMzo1NF0gICBnZm46IDAwMDA1ZGJjICBtZm46IDAwMDA1ZGJjDQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMzOjU0XSAgIGdmbjogMDAwMDVkYmQgIG1mbjogMDAwMDVk
YmQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NTRdICAgZ2ZuOiAwMDAwNWRiZSAgbWZu
OiAwMDAwNWRiZQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo1NF0gICBnZm46IDAwMDA1
ZGJmICBtZm46IDAwMDA1ZGJmDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjU0XSAgIGdm
bjogMDAwMDVkYzAgIG1mbjogMDAwMDVkYzANCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6
NTVdICAgZ2ZuOiAwMDAwNWRjMSAgbWZuOiAwMDAwNWRjMQ0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMzo1NV0gICBnZm46IDAwMDA1ZGMyICBtZm46IDAwMDA1ZGMyDQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMzOjU1XSAgIGdmbjogMDAwMDVkYzMgIG1mbjogMDAwMDVkYzMNCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NTVdICAgZ2ZuOiAwMDAwNWRjNCAgbWZuOiAwMDAw
NWRjNA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo1NV0gICBnZm46IDAwMDA1ZGM1ICBt
Zm46IDAwMDA1ZGM1DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjU1XSAgIGdmbjogMDAw
MDVkYzYgIG1mbjogMDAwMDVkYzYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NTVdICAg
Z2ZuOiAwMDAwNWRjNyAgbWZuOiAwMDAwNWRjNw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
Mzo1NV0gICBnZm46IDAwMDA1ZGM4ICBtZm46IDAwMDA1ZGM4DQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMzOjU1XSAgIGdmbjogMDAwMDVkYzkgIG1mbjogMDAwMDVkYzkNCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzM6NTVdICAgZ2ZuOiAwMDAwNWRjYSAgbWZuOiAwMDAwNWRjYQ0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo1NV0gICBnZm46IDAwMDA1ZGNiICBtZm46IDAw
MDA1ZGNiDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjU1XSAgIGdmbjogMDAwMDVkY2Mg
IG1mbjogMDAwMDVkY2MNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NTVdICAgZ2ZuOiAw
MDAwNWRjZCAgbWZuOiAwMDAwNWRjZA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo1NV0g
ICBnZm46IDAwMDA1ZGNlICBtZm46IDAwMDA1ZGNlDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMzOjU1XSAgIGdmbjogMDAwMDVkY2YgIG1mbjogMDAwMDVkY2YNCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzM6NTVdICAgZ2ZuOiAwMDAwNWRkMCAgbWZuOiAwMDAwNWRkMA0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMzo1NV0gICBnZm46IDAwMDA1ZGQxICBtZm46IDAwMDA1ZGQx
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjU1XSAgIGdmbjogMDAwMDVkZDIgIG1mbjog
MDAwMDVkZDINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NTVdICAgZ2ZuOiAwMDAwNWRk
MyAgbWZuOiAwMDAwNWRkMw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo1NV0gICBnZm46
IDAwMDA1ZGQ0ICBtZm46IDAwMDA1ZGQ0DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjU1
XSAgIGdmbjogMDAwMDVkZDUgIG1mbjogMDAwMDVkZDUNCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzM6NTVdICAgZ2ZuOiAwMDAwNWRkNiAgbWZuOiAwMDAwNWRkNg0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMzo1NV0gICBnZm46IDAwMDA1ZGQ3ICBtZm46IDAwMDA1ZGQ3DQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMzOjU1XSAgIGdmbjogMDAwMDVkZDggIG1mbjogMDAwMDVk
ZDgNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NTVdICAgZ2ZuOiAwMDAwNWRkOSAgbWZu
OiAwMDAwNWRkOQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo1NV0gICBnZm46IDAwMDA1
ZGRhICBtZm46IDAwMDA1ZGRhDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjU1XSAgIGdm
bjogMDAwMDVkZGIgIG1mbjogMDAwMDVkZGINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6
NTVdICAgZ2ZuOiAwMDAwNWRkYyAgbWZuOiAwMDAwNWRkYw0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMzo1NV0gICBnZm46IDAwMDA1ZGRkICBtZm46IDAwMDA1ZGRkDQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMzOjU1XSAgIGdmbjogMDAwMDVkZGUgIG1mbjogMDAwMDVkZGUNCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NTVdICAgZ2ZuOiAwMDAwNWRkZiAgbWZuOiAwMDAw
NWRkZg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo1NV0gICBnZm46IDAwMDA1ZGUwICBt
Zm46IDAwMDA1ZGUwDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjU1XSAgIGdmbjogMDAw
MDVkZTEgIG1mbjogMDAwMDVkZTENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NTVdICAg
Z2ZuOiAwMDAwNWRlMiAgbWZuOiAwMDAwNWRlMg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
Mzo1NV0gICBnZm46IDAwMDA1ZGUzICBtZm46IDAwMDA1ZGUzDQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMzOjU1XSAgIGdmbjogMDAwMDVkZTQgIG1mbjogMDAwMDVkZTQNCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzM6NTVdICAgZ2ZuOiAwMDAwNWRlNSAgbWZuOiAwMDAwNWRlNQ0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo1NV0gICBnZm46IDAwMDA1ZGU2ICBtZm46IDAw
MDA1ZGU2DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjU1XSAgIGdmbjogMDAwMDVkZTcg
IG1mbjogMDAwMDVkZTcNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NTVdICAgZ2ZuOiAw
MDAwNWRlOCAgbWZuOiAwMDAwNWRlOA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo1NV0g
ICBnZm46IDAwMDA1ZGU5ICBtZm46IDAwMDA1ZGU5DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMzOjU1XSAgIGdmbjogMDAwMDVkZWEgIG1mbjogMDAwMDVkZWENCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzM6NTVdICAgZ2ZuOiAwMDAwNWRlYiAgbWZuOiAwMDAwNWRlYg0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMzo1NV0gICBnZm46IDAwMDA1ZGVjICBtZm46IDAwMDA1ZGVj
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjU1XSAgIGdmbjogMDAwMDVkZWQgIG1mbjog
MDAwMDVkZWQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NTVdICAgZ2ZuOiAwMDAwNWRl
ZSAgbWZuOiAwMDAwNWRlZQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo1NV0gICBnZm46
IDAwMDA1ZGVmICBtZm46IDAwMDA1ZGVmDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjU1
XSAgIGdmbjogMDAwMDVkZjAgIG1mbjogMDAwMDVkZjANCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzM6NTVdICAgZ2ZuOiAwMDAwNWRmMSAgbWZuOiAwMDAwNWRmMQ0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMzo1NV0gICBnZm46IDAwMDA1ZGYyICBtZm46IDAwMDA1ZGYyDQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMzOjU1XSAgIGdmbjogMDAwMDVkZjMgIG1mbjogMDAwMDVk
ZjMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NTVdICAgZ2ZuOiAwMDAwNWRmNCAgbWZu
OiAwMDAwNWRmNA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo1NV0gICBnZm46IDAwMDA1
ZGY1ICBtZm46IDAwMDA1ZGY1DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjU1XSAgIGdm
bjogMDAwMDVkZjYgIG1mbjogMDAwMDVkZjYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6
NTVdICAgZ2ZuOiAwMDAwNWRmNyAgbWZuOiAwMDAwNWRmNw0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMzo1NV0gICBnZm46IDAwMDA1ZGY4ICBtZm46IDAwMDA1ZGY4DQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMzOjU1XSAgIGdmbjogMDAwMDVkZjkgIG1mbjogMDAwMDVkZjkNCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NTVdICAgZ2ZuOiAwMDAwNWRmYSAgbWZuOiAwMDAw
NWRmYQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo1NV0gICBnZm46IDAwMDA1ZGZiICBt
Zm46IDAwMDA1ZGZiDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjU1XSAgIGdmbjogMDAw
MDVkZmMgIG1mbjogMDAwMDVkZmMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NTVdICAg
Z2ZuOiAwMDAwNWRmZCAgbWZuOiAwMDAwNWRmZA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
Mzo1NV0gICBnZm46IDAwMDA1ZGZlICBtZm46IDAwMDA1ZGZlDQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMzOjU1XSAgIGdmbjogMDAwMDVkZmYgIG1mbjogMDAwMDVkZmYNCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzM6NTVdICAgZ2ZuOiAwMDAwNWUwMCAgbWZuOiAwMDAwNWUwMA0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo1Nl0gICBnZm46IDAwMDA1ZTAxICBtZm46IDAw
MDA1ZTAxDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjU2XSAgIGdmbjogMDAwMDVlMDIg
IG1mbjogMDAwMDVlMDINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NTZdICAgZ2ZuOiAw
MDAwNWUwMyAgbWZuOiAwMDAwNWUwMw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo1Nl0g
ICBnZm46IDAwMDA1ZTA0ICBtZm46IDAwMDA1ZTA0DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMzOjU2XSAgIGdmbjogMDAwMDVlMDUgIG1mbjogMDAwMDVlMDUNCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzM6NTZdICAgZ2ZuOiAwMDAwNWUwNiAgbWZuOiAwMDAwNWUwNg0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMzo1Nl0gICBnZm46IDAwMDA1ZTA3ICBtZm46IDAwMDA1ZTA3
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjU2XSAgIGdmbjogMDAwMDVlMDggIG1mbjog
MDAwMDVlMDgNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NTZdICAgZ2ZuOiAwMDAwNWUw
OSAgbWZuOiAwMDAwNWUwOQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo1Nl0gICBnZm46
IDAwMDA1ZTBhICBtZm46IDAwMDA1ZTBhDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjU2
XSAgIGdmbjogMDAwMDVlMGIgIG1mbjogMDAwMDVlMGINCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzM6NTZdICAgZ2ZuOiAwMDAwNWUwYyAgbWZuOiAwMDAwNWUwYw0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMzo1Nl0gICBnZm46IDAwMDA1ZTBkICBtZm46IDAwMDA1ZTBkDQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMzOjU2XSAgIGdmbjogMDAwMDVlMGUgIG1mbjogMDAwMDVl
MGUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NTZdICAgZ2ZuOiAwMDAwNWUwZiAgbWZu
OiAwMDAwNWUwZg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo1Nl0gICBnZm46IDAwMDA1
ZTEwICBtZm46IDAwMDA1ZTEwDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjU2XSAgIGdm
bjogMDAwMDVlMTEgIG1mbjogMDAwMDVlMTENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6
NTZdICAgZ2ZuOiAwMDAwNWUxMiAgbWZuOiAwMDAwNWUxMg0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMzo1Nl0gICBnZm46IDAwMDA1ZTEzICBtZm46IDAwMDA1ZTEzDQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMzOjU2XSAgIGdmbjogMDAwMDVlMTQgIG1mbjogMDAwMDVlMTQNCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NTZdICAgZ2ZuOiAwMDAwNWUxNSAgbWZuOiAwMDAw
NWUxNQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo1Nl0gICBnZm46IDAwMDA1ZTE2ICBt
Zm46IDAwMDA1ZTE2DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjU2XSAgIGdmbjogMDAw
MDVlMTcgIG1mbjogMDAwMDVlMTcNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NTZdICAg
Z2ZuOiAwMDAwNWUxOCAgbWZuOiAwMDAwNWUxOA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
Mzo1Nl0gICBnZm46IDAwMDA1ZTE5ICBtZm46IDAwMDA1ZTE5DQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMzOjU2XSAgIGdmbjogMDAwMDVlMWEgIG1mbjogMDAwMDVlMWENCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzM6NTZdICAgZ2ZuOiAwMDAwNWUxYiAgbWZuOiAwMDAwNWUxYg0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo1Nl0gICBnZm46IDAwMDA1ZTFjICBtZm46IDAw
MDA1ZTFjDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjU2XSAgIGdmbjogMDAwMDVlMWQg
IG1mbjogMDAwMDVlMWQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NTZdICAgZ2ZuOiAw
MDAwNWUxZSAgbWZuOiAwMDAwNWUxZQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo1Nl0g
ICBnZm46IDAwMDA1ZTFmICBtZm46IDAwMDA1ZTFmDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMzOjU2XSAgIGdmbjogMDAwMDVlMjAgIG1mbjogMDAwMDVlMjANCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzM6NTZdICAgZ2ZuOiAwMDAwNWUyMSAgbWZuOiAwMDAwNWUyMQ0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMzo1Nl0gICBnZm46IDAwMDA1ZTIyICBtZm46IDAwMDA1ZTIy
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjU2XSAgIGdmbjogMDAwMDVlMjMgIG1mbjog
MDAwMDVlMjMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NTZdICAgZ2ZuOiAwMDAwNWUy
NCAgbWZuOiAwMDAwNWUyNA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo1Nl0gICBnZm46
IDAwMDA1ZTI1ICBtZm46IDAwMDA1ZTI1DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjU2
XSAgIGdmbjogMDAwMDVlMjYgIG1mbjogMDAwMDVlMjYNCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzM6NTZdICAgZ2ZuOiAwMDAwNWUyNyAgbWZuOiAwMDAwNWUyNw0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMzo1Nl0gICBnZm46IDAwMDA1ZTI4ICBtZm46IDAwMDA1ZTI4DQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMzOjU2XSAgIGdmbjogMDAwMDVlMjkgIG1mbjogMDAwMDVl
MjkNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NTZdICAgZ2ZuOiAwMDAwNWUyYSAgbWZu
OiAwMDAwNWUyYQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo1Nl0gICBnZm46IDAwMDA1
ZTJiICBtZm46IDAwMDA1ZTJiDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjU2XSAgIGdm
bjogMDAwMDVlMmMgIG1mbjogMDAwMDVlMmMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6
NTZdICAgZ2ZuOiAwMDAwNWUyZCAgbWZuOiAwMDAwNWUyZA0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMzo1Nl0gICBnZm46IDAwMDA1ZTJlICBtZm46IDAwMDA1ZTJlDQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMzOjU2XSAgIGdmbjogMDAwMDVlMmYgIG1mbjogMDAwMDVlMmYNCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NTZdICAgZ2ZuOiAwMDAwNWUzMCAgbWZuOiAwMDAw
NWUzMA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo1Nl0gICBnZm46IDAwMDA1ZTMxICBt
Zm46IDAwMDA1ZTMxDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjU2XSAgIGdmbjogMDAw
MDVlMzIgIG1mbjogMDAwMDVlMzINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NTZdICAg
Z2ZuOiAwMDAwNWUzMyAgbWZuOiAwMDAwNWUzMw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
Mzo1Nl0gICBnZm46IDAwMDA1ZTM0ICBtZm46IDAwMDA1ZTM0DQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMzOjU2XSAgIGdmbjogMDAwMDVlMzUgIG1mbjogMDAwMDVlMzUNCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzM6NTZdICAgZ2ZuOiAwMDAwNWUzNiAgbWZuOiAwMDAwNWUzNg0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo1Nl0gICBnZm46IDAwMDA1ZTM3ICBtZm46IDAw
MDA1ZTM3DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjU2XSAgIGdmbjogMDAwMDVlMzgg
IG1mbjogMDAwMDVlMzgNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NTZdICAgZ2ZuOiAw
MDAwNWUzOSAgbWZuOiAwMDAwNWUzOQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo1Nl0g
ICBnZm46IDAwMDA1ZTNhICBtZm46IDAwMDA1ZTNhDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMzOjU2XSAgIGdmbjogMDAwMDVlM2IgIG1mbjogMDAwMDVlM2INCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzM6NTZdICAgZ2ZuOiAwMDAwNWUzYyAgbWZuOiAwMDAwNWUzYw0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMzo1Nl0gICBnZm46IDAwMDA1ZTNkICBtZm46IDAwMDA1ZTNk
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjU2XSAgIGdmbjogMDAwMDVlM2UgIG1mbjog
MDAwMDVlM2UNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NTZdICAgZ2ZuOiAwMDAwNWUz
ZiAgbWZuOiAwMDAwNWUzZg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo1Nl0gICBnZm46
IDAwMDA1ZTQwICBtZm46IDAwMDA1ZTQwDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjU2
XSAgIGdmbjogMDAwMDVlNDEgIG1mbjogMDAwMDVlNDENCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzM6NTddICAgZ2ZuOiAwMDAwNWU0MiAgbWZuOiAwMDAwNWU0Mg0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMzo1N10gICBnZm46IDAwMDA1ZTQzICBtZm46IDAwMDA1ZTQzDQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMzOjU3XSAgIGdmbjogMDAwMDVlNDQgIG1mbjogMDAwMDVl
NDQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NTddICAgZ2ZuOiAwMDAwNWU0NSAgbWZu
OiAwMDAwNWU0NQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo1N10gICBnZm46IDAwMDA1
ZTQ2ICBtZm46IDAwMDA1ZTQ2DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjU3XSAgIGdm
bjogMDAwMDVlNDcgIG1mbjogMDAwMDVlNDcNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6
NTddICAgZ2ZuOiAwMDAwNWU0OCAgbWZuOiAwMDAwNWU0OA0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMzo1N10gICBnZm46IDAwMDA1ZTQ5ICBtZm46IDAwMDA1ZTQ5DQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMzOjU3XSAgIGdmbjogMDAwMDVlNGEgIG1mbjogMDAwMDVlNGENCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NTddICAgZ2ZuOiAwMDAwNWU0YiAgbWZuOiAwMDAw
NWU0Yg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo1N10gICBnZm46IDAwMDA1ZTRjICBt
Zm46IDAwMDA1ZTRjDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjU3XSAgIGdmbjogMDAw
MDVlNGQgIG1mbjogMDAwMDVlNGQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NTddICAg
Z2ZuOiAwMDAwNWU0ZSAgbWZuOiAwMDAwNWU0ZQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
Mzo1N10gICBnZm46IDAwMDA1ZTRmICBtZm46IDAwMDA1ZTRmDQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMzOjU3XSAgIGdmbjogMDAwMDVlNTAgIG1mbjogMDAwMDVlNTANCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzM6NTddICAgZ2ZuOiAwMDAwNWU1MSAgbWZuOiAwMDAwNWU1MQ0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo1N10gICBnZm46IDAwMDA1ZTUyICBtZm46IDAw
MDA1ZTUyDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjU3XSAgIGdmbjogMDAwMDVlNTMg
IG1mbjogMDAwMDVlNTMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NTddICAgZ2ZuOiAw
MDAwNWU1NCAgbWZuOiAwMDAwNWU1NA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo1N10g
ICBnZm46IDAwMDA1ZTU1ICBtZm46IDAwMDA1ZTU1DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMzOjU3XSAgIGdmbjogMDAwMDVlNTYgIG1mbjogMDAwMDVlNTYNCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzM6NTddICAgZ2ZuOiAwMDAwNWU1NyAgbWZuOiAwMDAwNWU1Nw0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMzo1N10gICBnZm46IDAwMDA1ZTU4ICBtZm46IDAwMDA1ZTU4
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjU3XSAgIGdmbjogMDAwMDVlNTkgIG1mbjog
MDAwMDVlNTkNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NTddICAgZ2ZuOiAwMDAwNWU1
YSAgbWZuOiAwMDAwNWU1YQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo1N10gICBnZm46
IDAwMDA1ZTViICBtZm46IDAwMDA1ZTViDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjU3
XSAgIGdmbjogMDAwMDVlNWMgIG1mbjogMDAwMDVlNWMNCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzM6NTddICAgZ2ZuOiAwMDAwNWU1ZCAgbWZuOiAwMDAwNWU1ZA0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMzo1N10gICBnZm46IDAwMDA1ZTVlICBtZm46IDAwMDA1ZTVlDQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMzOjU3XSAgIGdmbjogMDAwMDVlNWYgIG1mbjogMDAwMDVl
NWYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NTddICAgZ2ZuOiAwMDAwNWU2MCAgbWZu
OiAwMDAwNWU2MA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo1N10gICBnZm46IDAwMDA1
ZTYxICBtZm46IDAwMDA1ZTYxDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjU3XSAgIGdm
bjogMDAwMDVlNjIgIG1mbjogMDAwMDVlNjINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6
NTddICAgZ2ZuOiAwMDAwNWU2MyAgbWZuOiAwMDAwNWU2Mw0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMzo1N10gICBnZm46IDAwMDA1ZTY0ICBtZm46IDAwMDA1ZTY0DQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMzOjU3XSAgIGdmbjogMDAwMDVlNjUgIG1mbjogMDAwMDVlNjUNCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NTddICAgZ2ZuOiAwMDAwNWU2NiAgbWZuOiAwMDAw
NWU2Ng0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo1N10gICBnZm46IDAwMDA1ZTY3ICBt
Zm46IDAwMDA1ZTY3DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjU3XSAgIGdmbjogMDAw
MDVlNjggIG1mbjogMDAwMDVlNjgNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NTddICAg
Z2ZuOiAwMDAwNWU2OSAgbWZuOiAwMDAwNWU2OQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
Mzo1N10gICBnZm46IDAwMDA1ZTZhICBtZm46IDAwMDA1ZTZhDQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMzOjU3XSAgIGdmbjogMDAwMDVlNmIgIG1mbjogMDAwMDVlNmINCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzM6NTddICAgZ2ZuOiAwMDAwNWU2YyAgbWZuOiAwMDAwNWU2Yw0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo1N10gICBnZm46IDAwMDA1ZTZkICBtZm46IDAw
MDA1ZTZkDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjU3XSAgIGdmbjogMDAwMDVlNmUg
IG1mbjogMDAwMDVlNmUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NTddICAgZ2ZuOiAw
MDAwNWU2ZiAgbWZuOiAwMDAwNWU2Zg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo1N10g
ICBnZm46IDAwMDA1ZTcwICBtZm46IDAwMDA1ZTcwDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMzOjU3XSAgIGdmbjogMDAwMDVlNzEgIG1mbjogMDAwMDVlNzENCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzM6NTddICAgZ2ZuOiAwMDAwNWU3MiAgbWZuOiAwMDAwNWU3Mg0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMzo1N10gICBnZm46IDAwMDA1ZTczICBtZm46IDAwMDA1ZTcz
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjU3XSAgIGdmbjogMDAwMDVlNzQgIG1mbjog
MDAwMDVlNzQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NTddICAgZ2ZuOiAwMDAwNWU3
NSAgbWZuOiAwMDAwNWU3NQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo1N10gICBnZm46
IDAwMDA1ZTc2ICBtZm46IDAwMDA1ZTc2DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjU3
XSAgIGdmbjogMDAwMDVlNzcgIG1mbjogMDAwMDVlNzcNCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzM6NTddICAgZ2ZuOiAwMDAwNWU3OCAgbWZuOiAwMDAwNWU3OA0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMzo1N10gICBnZm46IDAwMDA1ZTc5ICBtZm46IDAwMDA1ZTc5DQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMzOjU3XSAgIGdmbjogMDAwMDVlN2EgIG1mbjogMDAwMDVl
N2ENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NTddICAgZ2ZuOiAwMDAwNWU3YiAgbWZu
OiAwMDAwNWU3Yg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo1N10gICBnZm46IDAwMDA1
ZTdjICBtZm46IDAwMDA1ZTdjDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjU3XSAgIGdm
bjogMDAwMDVlN2QgIG1mbjogMDAwMDVlN2QNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6
NTddICAgZ2ZuOiAwMDAwNWU3ZSAgbWZuOiAwMDAwNWU3ZQ0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMzo1N10gICBnZm46IDAwMDA1ZTdmICBtZm46IDAwMDA1ZTdmDQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMzOjU3XSAgIGdmbjogMDAwMDVlODAgIG1mbjogMDAwMDVlODANCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NTddICAgZ2ZuOiAwMDAwNWU4MSAgbWZuOiAwMDAw
NWU4MQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo1OF0gICBnZm46IDAwMDA1ZTgyICBt
Zm46IDAwMDA1ZTgyDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjU4XSAgIGdmbjogMDAw
MDVlODMgIG1mbjogMDAwMDVlODMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NThdICAg
Z2ZuOiAwMDAwNWU4NCAgbWZuOiAwMDAwNWU4NA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
Mzo1OF0gICBnZm46IDAwMDA1ZTg1ICBtZm46IDAwMDA1ZTg1DQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMzOjU4XSAgIGdmbjogMDAwMDVlODYgIG1mbjogMDAwMDVlODYNCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzM6NThdICAgZ2ZuOiAwMDAwNWU4NyAgbWZuOiAwMDAwNWU4Nw0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo1OF0gICBnZm46IDAwMDA1ZTg4ICBtZm46IDAw
MDA1ZTg4DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjU4XSAgIGdmbjogMDAwMDVlODkg
IG1mbjogMDAwMDVlODk=
------------03F05B075321531C3
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

------------03F05B075321531C3--



From xen-devel-bounces@lists.xen.org Sat Sep 01 05:21:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 01 Sep 2012 05: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 1T7g8N-000613-7g; Sat, 01 Sep 2012 05:20:39 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <linux@eikelenboom.it>) id 1T7Zvy-0008FL-HL
	for xen-devel@lists.xen.org; Fri, 31 Aug 2012 22:43:28 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-14.tower-27.messagelabs.com!1346452977!2165777!1
X-Originating-IP: [188.40.164.121]
X-SpamReason: No, hits=3.0 required=7.0 tests=ML_RADAR_551,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13596 invoked from network); 31 Aug 2012 22:42:58 -0000
Received: from static.121.164.40.188.clients.your-server.de (HELO
	smtp.eikelenboom.it) (188.40.164.121)
	by server-14.tower-27.messagelabs.com with AES256-SHA encrypted SMTP;
	31 Aug 2012 22:42:58 -0000
Received: from 26-69-ftth.onsneteindhoven.nl ([88.159.69.26]:50972
	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 1T7ZsN-0000Fk-St; Sat, 01 Sep 2012 00:39:45 +0200
Date: Sat, 1 Sep 2012 00:42:49 +0200
From: Sander Eikelenboom <linux@eikelenboom.it>
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <723041396.20120901004249@eikelenboom.it>
To: Santosh Jodh <Santosh.Jodh@citrix.com>
In-Reply-To: <7914B38A4445B34AA16EB9F1352942F1012F0F6F4AE2@SJCPMAILBOX01.citrite.net>
References: <647712821.20120831234512@eikelenboom.it>
	<7914B38A4445B34AA16EB9F1352942F1012F0F6F4AE2@SJCPMAILBOX01.citrite.net>
MIME-Version: 1.0
Content-Type: multipart/mixed;
 boundary="----------03F05B075321531C3"
X-Mailman-Approved-At: Sat, 01 Sep 2012 05:20:38 +0000
Cc: "wei.wang2@amd.com" <wei.wang2@amd.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Using debug-key 'o:  Dump IOMMU p2m table,
	locks up machine
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

------------03F05B075321531C3
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit


Saturday, September 1, 2012, 12:24:32 AM, you wrote:

> Depending on how many VMs you have and the size of the IOMMU p2m table, it can take a while. It should not be infinite though. 

> How many VMs do you have running?

15

> Can you please send the serial output when you press 'o'?

Attached, to the end you will see the s-ata errors coming through while the dump still runs.
This is not a complete dump, only a few minutes after which i did a hard reset.

> Santosh

>> -----Original Message-----
>> From: Sander Eikelenboom [mailto:linux@eikelenboom.it]
>> Sent: Friday, August 31, 2012 2:45 PM
>> To: Santosh Jodh; wei.wang2@amd.com
>> Cc: xen-devel@lists.xen.org
>> Subject: Using debug-key 'o: Dump IOMMU p2m table, locks up machine
>> 
>> 
>> I was trying to use the 'o' debug key to make a bug report about an "AMD-Vi:
>> IO_PAGE_FAULT".
>> 
>> The result:
>> - When using "xl debug-keys o", the machine seems in a infinite loop, can
>> hardly login, eventually resulting in a kernel RCU stall and complete lockup.
>> - When using serial console: I get a infinite stream of "gfn:  mfn: " lines, mean
>> while on the normal console, S-ATA devices are starting to give errors.
>> 
>> So either option trashes the machine, other debug-keys work fine.
>> 
>> Machine has a 890-fx chipset and AMD phenom x6 proc.
>> 
>> xl dmesg with bootup and output from some other debug-keys is attached.
>> 
>> --
>> 
>> Sander




-- 
Best regards,
 Sander                            mailto:linux@eikelenboom.it
------------03F05B075321531C3
Content-Type: text/plain;
 name="output-debug-keys-o.txt"
Content-transfer-encoding: base64
Content-Disposition: attachment;
 filename="output-debug-keys-o.txt"

DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMxOjU0XSAqKiogU2VyaWFsIGlucHV0IC0+IFhl
biAodHlwZSAnQ1RSTC1hJyB0aHJlZSB0aW1lcyB0byBzd2l0Y2ggaW5wdXQgdG8gRE9NMCkN
Cg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzE6NTZdIA0KDQooWEVOKSBbMjAxMi0wOC0zMSAy
MTozMTo1Nl0gZG9tYWluMSBJT01NVSBwMm0gdGFibGU6IA0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMTo1Nl0gcDJtIHRhYmxlIGhhcyAzIGxldmVscw0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMTo1Nl0gDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMxOjU2XSBkb21haW4yIElP
TU1VIHAybSB0YWJsZTogDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMxOjU2XSBwMm0gdGFi
bGUgaGFzIDMgbGV2ZWxzDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMxOjU2XSANCg0KKFhF
TikgWzIwMTItMDgtMzEgMjE6MzE6NTZdIGRvbWFpbjMgSU9NTVUgcDJtIHRhYmxlOiANCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzE6NTZdIHAybSB0YWJsZSBoYXMgMyBsZXZlbHMNCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzE6NTZdIA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
MTo1Nl0gZG9tYWluNCBJT01NVSBwMm0gdGFibGU6IA0KDQooWEVOKSBbMjAxMi0wOC0zMSAy
MTozMTo1Nl0gcDJtIHRhYmxlIGhhcyAzIGxldmVscw0KDQooWEVOKSBbMjAxMi0wOC0zMSAy
MTozMTo1Nl0gDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMxOjU2XSBkb21haW41IElPTU1V
IHAybSB0YWJsZTogDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMxOjU2XSBwMm0gdGFibGUg
aGFzIDMgbGV2ZWxzDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMxOjU2XSANCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzE6NTZdIGRvbWFpbjYgSU9NTVUgcDJtIHRhYmxlOiANCg0KKFhF
TikgWzIwMTItMDgtMzEgMjE6MzE6NTZdIHAybSB0YWJsZSBoYXMgMyBsZXZlbHMNCg0KKFhF
TikgWzIwMTItMDgtMzEgMjE6MzE6NTZdIA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMTo1
Nl0gZG9tYWluNyBJT01NVSBwMm0gdGFibGU6IA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
MTo1Nl0gcDJtIHRhYmxlIGhhcyAzIGxldmVscw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
MTo1Nl0gDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMxOjU2XSBkb21haW44IElPTU1VIHAy
bSB0YWJsZTogDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMxOjU2XSBwMm0gdGFibGUgaGFz
IDMgbGV2ZWxzDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMxOjU2XSANCg0KKFhFTikgWzIw
MTItMDgtMzEgMjE6MzE6NTZdIGRvbWFpbjkgSU9NTVUgcDJtIHRhYmxlOiANCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzE6NTZdIHAybSB0YWJsZSBoYXMgMyBsZXZlbHMNCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzE6NTZdIA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMTo1Nl0g
ZG9tYWluMTAgSU9NTVUgcDJtIHRhYmxlOiANCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzE6
NTZdIHAybSB0YWJsZSBoYXMgMyBsZXZlbHMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzE6
NTZdIA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMTo1Nl0gZG9tYWluMTEgSU9NTVUgcDJt
IHRhYmxlOiANCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzE6NTZdIHAybSB0YWJsZSBoYXMg
MyBsZXZlbHMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzE6NTZdICAgZ2ZuOiAwMDAwNDAw
MCAgbWZuOiAwMDAwNDAwMA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMTo1Nl0gICBnZm46
IDAwMDA0MDAxICBtZm46IDAwMDA0MDAxDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMxOjU2
XSAgIGdmbjogMDAwMDQwMDIgIG1mbjogMDAwMDQwMDINCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzE6NTZdICAgZ2ZuOiAwMDAwNDAwMyAgbWZuOiAwMDAwNDAwMw0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMTo1Nl0gICBnZm46IDAwMDA0MDA0ICBtZm46IDAwMDA0MDA0DQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMxOjU2XSAgIGdmbjogMDAwMDQwMDUgIG1mbjogMDAwMDQw
MDUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzE6NTZdICAgZ2ZuOiAwMDAwNDAwNiAgbWZu
OiAwMDAwNDAwNg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMTo1Nl0gICBnZm46IDAwMDA0
MDA3ICBtZm46IDAwMDA0MDA3DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMxOjU2XSAgIGdm
bjogMDAwMDQwMDggIG1mbjogMDAwMDQwMDgNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzE6
NTZdICAgZ2ZuOiAwMDAwNDAwOSAgbWZuOiAwMDAwNDAwOQ0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMTo1Nl0gICBnZm46IDAwMDA0MDBhICBtZm46IDAwMDA0MDBhDQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMxOjU2XSAgIGdmbjogMDAwMDQwMGIgIG1mbjogMDAwMDQwMGINCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzE6NTZdICAgZ2ZuOiAwMDAwNDAwYyAgbWZuOiAwMDAw
NDAwYw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMTo1Nl0gICBnZm46IDAwMDA0MDBkICBt
Zm46IDAwMDA0MDBkDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMxOjU2XSAgIGdmbjogMDAw
MDQwMGUgIG1mbjogMDAwMDQwMGUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzE6NTZdICAg
Z2ZuOiAwMDAwNDAwZiAgbWZuOiAwMDAwNDAwZg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
MTo1Nl0gICBnZm46IDAwMDA0MDEwICBtZm46IDAwMDA0MDEwDQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMxOjU2XSAgIGdmbjogMDAwMDQwMTEgIG1mbjogMDAwMDQwMTENCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzE6NTZdICAgZ2ZuOiAwMDAwNDAxMiAgbWZuOiAwMDAwNDAxMg0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMTo1Nl0gICBnZm46IDAwMDA0MDEzICBtZm46IDAw
MDA0MDEzDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMxOjU2XSAgIGdmbjogMDAwMDQwMTQg
IG1mbjogMDAwMDQwMTQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzE6NTZdICAgZ2ZuOiAw
MDAwNDAxNSAgbWZuOiAwMDAwNDAxNQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMTo1Nl0g
ICBnZm46IDAwMDA0MDE2ICBtZm46IDAwMDA0MDE2DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMxOjU2XSAgIGdmbjogMDAwMDQwMTcgIG1mbjogMDAwMDQwMTcNCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzE6NTZdICAgZ2ZuOiAwMDAwNDAxOCAgbWZuOiAwMDAwNDAxOA0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMTo1Nl0gICBnZm46IDAwMDA0MDE5ICBtZm46IDAwMDA0MDE5
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMxOjU2XSAgIGdmbjogMDAwMDQwMWEgIG1mbjog
MDAwMDQwMWENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzE6NTZdICAgZ2ZuOiAwMDAwNDAx
YiAgbWZuOiAwMDAwNDAxYg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMTo1Nl0gICBnZm46
IDAwMDA0MDFjICBtZm46IDAwMDA0MDFjDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMxOjU2
XSAgIGdmbjogMDAwMDQwMWQgIG1mbjogMDAwMDQwMWQNCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzE6NTZdICAgZ2ZuOiAwMDAwNDAxZSAgbWZuOiAwMDAwNDAxZQ0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMTo1Nl0gICBnZm46IDAwMDA0MDFmICBtZm46IDAwMDA0MDFmDQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMxOjU2XSAgIGdmbjogMDAwMDQwMjAgIG1mbjogMDAwMDQw
MjANCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzE6NTZdICAgZ2ZuOiAwMDAwNDAyMSAgbWZu
OiAwMDAwNDAyMQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMTo1Nl0gICBnZm46IDAwMDA0
MDIyICBtZm46IDAwMDA0MDIyDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMxOjU2XSAgIGdm
bjogMDAwMDQwMjMgIG1mbjogMDAwMDQwMjMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzE6
NTZdICAgZ2ZuOiAwMDAwNDAyNCAgbWZuOiAwMDAwNDAyNA0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMTo1Nl0gICBnZm46IDAwMDA0MDI1ICBtZm46IDAwMDA0MDI1DQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMxOjU2XSAgIGdmbjogMDAwMDQwMjYgIG1mbjogMDAwMDQwMjYNCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzE6NTZdICAgZ2ZuOiAwMDAwNDAyNyAgbWZuOiAwMDAw
NDAyNw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMTo1Nl0gICBnZm46IDAwMDA0MDI4ICBt
Zm46IDAwMDA0MDI4DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMxOjU2XSAgIGdmbjogMDAw
MDQwMjkgIG1mbjogMDAwMDQwMjkNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzE6NTZdICAg
Z2ZuOiAwMDAwNDAyYSAgbWZuOiAwMDAwNDAyYQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
MTo1Nl0gICBnZm46IDAwMDA0MDJiICBtZm46IDAwMDA0MDJiDQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMxOjU2XSAgIGdmbjogMDAwMDQwMmMgIG1mbjogMDAwMDQwMmMNCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzE6NTZdICAgZ2ZuOiAwMDAwNDAyZCAgbWZuOiAwMDAwNDAyZA0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMTo1Nl0gICBnZm46IDAwMDA0MDJlICBtZm46IDAw
MDA0MDJlDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMxOjU2XSAgIGdmbjogMDAwMDQwMmYg
IG1mbjogMDAwMDQwMmYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzE6NTZdICAgZ2ZuOiAw
MDAwNDAzMCAgbWZuOiAwMDAwNDAzMA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMTo1Nl0g
ICBnZm46IDAwMDA0MDMxICBtZm46IDAwMDA0MDMxDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMxOjU2XSAgIGdmbjogMDAwMDQwMzIgIG1mbjogMDAwMDQwMzINCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzE6NTZdICAgZ2ZuOiAwMDAwNDAzMyAgbWZuOiAwMDAwNDAzMw0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMTo1Nl0gICBnZm46IDAwMDA0MDM0ICBtZm46IDAwMDA0MDM0
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMxOjU2XSAgIGdmbjogMDAwMDQwMzUgIG1mbjog
MDAwMDQwMzUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzE6NTZdICAgZ2ZuOiAwMDAwNDAz
NiAgbWZuOiAwMDAwNDAzNg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMTo1Nl0gICBnZm46
IDAwMDA0MDM3ICBtZm46IDAwMDA0MDM3DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMxOjU2
XSAgIGdmbjogMDAwMDQwMzggIG1mbjogMDAwMDQwMzgNCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzE6NTZdICAgZ2ZuOiAwMDAwNDAzOSAgbWZuOiAwMDAwNDAzOQ0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMTo1Nl0gICBnZm46IDAwMDA0MDNhICBtZm46IDAwMDA0MDNhDQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMxOjU2XSAgIGdmbjogMDAwMDQwM2IgIG1mbjogMDAwMDQw
M2INCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzE6NTZdICAgZ2ZuOiAwMDAwNDAzYyAgbWZu
OiAwMDAwNDAzYw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMTo1Nl0gICBnZm46IDAwMDA0
MDNkICBtZm46IDAwMDA0MDNkDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMxOjU2XSAgIGdm
bjogMDAwMDQwM2UgIG1mbjogMDAwMDQwM2UNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzE6
NTZdICAgZ2ZuOiAwMDAwNDAzZiAgbWZuOiAwMDAwNDAzZg0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMTo1Nl0gICBnZm46IDAwMDA0MDQwICBtZm46IDAwMDA0MDQwDQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMxOjU2XSAgIGdmbjogMDAwMDQwNDEgIG1mbjogMDAwMDQwNDENCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzE6NTZdICAgZ2ZuOiAwMDAwNDA0MiAgbWZuOiAwMDAw
NDA0Mg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMTo1Nl0gICBnZm46IDAwMDA0MDQzICBt
Zm46IDAwMDA0MDQzDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMxOjU2XSAgIGdmbjogMDAw
MDQwNDQgIG1mbjogMDAwMDQwNDQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzE6NTZdICAg
Z2ZuOiAwMDAwNDA0NSAgbWZuOiAwMDAwNDA0NQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
MTo1Nl0gICBnZm46IDAwMDA0MDQ2ICBtZm46IDAwMDA0MDQ2DQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMxOjU2XSAgIGdmbjogMDAwMDQwNDcgIG1mbjogMDAwMDQwNDcNCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzE6NTZdICAgZ2ZuOiAwMDAwNDA0OCAgbWZuOiAwMDAwNDA0OA0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMTo1Nl0gICBnZm46IDAwMDA0MDQ5ICBtZm46IDAw
MDA0MDQ5DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMxOjU2XSAgIGdmbjogMDAwMDQwNGEg
IG1mbjogMDAwMDQwNGENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzE6NTZdICAgZ2ZuOiAw
MDAwNDA0YiAgbWZuOiAwMDAwNDA0Yg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMTo1Nl0g
ICBnZm46IDAwMDA0MDRjICBtZm46IDAwMDA0MDRjDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMxOjU2XSAgIGdmbjogMDAwMDQwNGQgIG1mbjogMDAwMDQwNGQNCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzE6NTZdICAgZ2ZuOiAwMDAwNDA0ZSAgbWZuOiAwMDAwNDA0ZQ0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMTo1Nl0gICBnZm46IDAwMDA0MDRmICBtZm46IDAwMDA0MDRm
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMxOjU2XSAgIGdmbjogMDAwMDQwNTAgIG1mbjog
MDAwMDQwNTANCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzE6NTZdICAgZ2ZuOiAwMDAwNDA1
MSAgbWZuOiAwMDAwNDA1MQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMTo1Nl0gICBnZm46
IDAwMDA0MDUyICBtZm46IDAwMDA0MDUyDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMxOjU2
XSAgIGdmbjogMDAwMDQwNTMgIG1mbjogMDAwMDQwNTMNCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzE6NTZdICAgZ2ZuOiAwMDAwNDA1NCAgbWZuOiAwMDAwNDA1NA0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMTo1Nl0gICBnZm46IDAwMDA0MDU1ICBtZm46IDAwMDA0MDU1DQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMxOjU2XSAgIGdmbjogMDAwMDQwNTYgIG1mbjogMDAwMDQw
NTYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzE6NTZdICAgZ2ZuOiAwMDAwNDA1NyAgbWZu
OiAwMDAwNDA1Nw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMTo1Nl0gICBnZm46IDAwMDA0
MDU4ICBtZm46IDAwMDA0MDU4DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMxOjU2XSAgIGdm
bjogMDAwMDQwNTkgIG1mbjogMDAwMDQwNTkNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzE6
NTZdICAgZ2ZuOiAwMDAwNDA1YSAgbWZuOiAwMDAwNDA1YQ0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMTo1Nl0gICBnZm46IDAwMDA0MDViICBtZm46IDAwMDA0MDViDQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMxOjU2XSAgIGdmbjogMDAwMDQwNWMgIG1mbjogMDAwMDQwNWMNCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzE6NTZdICAgZ2ZuOiAwMDAwNDA1ZCAgbWZuOiAwMDAw
NDA1ZA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMTo1Nl0gICBnZm46IDAwMDA0MDVlICBt
Zm46IDAwMDA0MDVlDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMxOjU2XSAgIGdmbjogMDAw
MDQwNWYgIG1mbjogMDAwMDQwNWYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzE6NTZdICAg
Z2ZuOiAwMDAwNDA2MCAgbWZuOiAwMDAwNDA2MA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
MTo1Nl0gICBnZm46IDAwMDA0MDYxICBtZm46IDAwMDA0MDYxDQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMxOjU2XSAgIGdmbjogMDAwMDQwNjIgIG1mbjogMDAwMDQwNjINCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzE6NTZdICAgZ2ZuOiAwMDAwNDA2MyAgbWZuOiAwMDAwNDA2Mw0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMTo1Nl0gICBnZm46IDAwMDA0MDY0ICBtZm46IDAw
MDA0MDY0DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMxOjU2XSAgIGdmbjogMDAwMDQwNjUg
IG1mbjogMDAwMDQwNjUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzE6NTZdICAgZ2ZuOiAw
MDAwNDA2NiAgbWZuOiAwMDAwNDA2Ng0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMTo1Nl0g
ICBnZm46IDAwMDA0MDY3ICBtZm46IDAwMDA0MDY3DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMxOjU2XSAgIGdmbjogMDAwMDQwNjggIG1mbjogMDAwMDQwNjgNCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzE6NTZdICAgZ2ZuOiAwMDAwNDA2OSAgbWZuOiAwMDAwNDA2OQ0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMTo1Nl0gICBnZm46IDAwMDA0MDZhICBtZm46IDAwMDA0MDZh
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMxOjU2XSAgIGdmbjogMDAwMDQwNmIgIG1mbjog
MDAwMDQwNmINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzE6NTZdICAgZ2ZuOiAwMDAwNDA2
YyAgbWZuOiAwMDAwNDA2Yw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMTo1Nl0gICBnZm46
IDAwMDA0MDZkICBtZm46IDAwMDA0MDZkDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMxOjU2
XSAgIGdmbjogMDAwMDQwNmUgIG1mbjogMDAwMDQwNmUNCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzE6NTZdICAgZ2ZuOiAwMDAwNDA2ZiAgbWZuOiAwMDAwNDA2Zg0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMTo1Nl0gICBnZm46IDAwMDA0MDcwICBtZm46IDAwMDA0MDcwDQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMxOjU2XSAgIGdmbjogMDAwMDQwNzEgIG1mbjogMDAwMDQw
NzENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzE6NTZdICAgZ2ZuOiAwMDAwNDA3MiAgbWZu
OiAwMDAwNDA3Mg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMTo1Nl0gICBnZm46IDAwMDA0
MDczICBtZm46IDAwMDA0MDczDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMxOjU2XSAgIGdm
bjogMDAwMDQwNzQgIG1mbjogMDAwMDQwNzQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzE6
NTZdICAgZ2ZuOiAwMDAwNDA3NSAgbWZuOiAwMDAwNDA3NQ0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMTo1Nl0gICBnZm46IDAwMDA0MDc2ICBtZm46IDAwMDA0MDc2DQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMxOjU2XSAgIGdmbjogMDAwMDQwNzcgIG1mbjogMDAwMDQwNzcNCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzE6NTZdICAgZ2ZuOiAwMDAwNDA3OCAgbWZuOiAwMDAw
NDA3OA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMTo1Nl0gICBnZm46IDAwMDA0MDc5ICBt
Zm46IDAwMDA0MDc5DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMxOjU2XSAgIGdmbjogMDAw
MDQwN2EgIG1mbjogMDAwMDQwN2ENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzE6NTZdICAg
Z2ZuOiAwMDAwNDA3YiAgbWZuOiAwMDAwNDA3Yg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
MTo1Nl0gICBnZm46IDAwMDA0MDdjICBtZm46IDAwMDA0MDdjDQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMxOjU2XSAgIGdmbjogMDAwMDQwN2QgIG1mbjogMDAwMDQwN2QNCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzE6NTZdICAgZ2ZuOiAwMDAwNDA3ZSAgbWZuOiAwMDAwNDA3ZQ0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMTo1Nl0gICBnZm46IDAwMDA0MDdmICBtZm46IDAw
MDA0MDdmDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMxOjU2XSAgIGdmbjogMDAwMDQwODAg
IG1mbjogMDAwMDQwODANCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzE6NTZdICAgZ2ZuOiAw
MDAwNDA4MSAgbWZuOiAwMDAwNDA4MQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMTo1Nl0g
ICBnZm46IDAwMDA0MDgyICBtZm46IDAwMDA0MDgyDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMxOjU2XSAgIGdmbjogMDAwMDQwODMgIG1mbjogMDAwMDQwODMNCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzE6NTZdICAgZ2ZuOiAwMDAwNDA4NCAgbWZuOiAwMDAwNDA4NA0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMTo1Nl0gICBnZm46IDAwMDA0MDg1ICBtZm46IDAwMDA0MDg1
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMxOjU2XSAgIGdmbjogMDAwMDQwODYgIG1mbjog
MDAwMDQwODYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzE6NTZdICAgZ2ZuOiAwMDAwNDA4
NyAgbWZuOiAwMDAwNDA4Nw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMTo1Nl0gICBnZm46
IDAwMDA0MDg4ICBtZm46IDAwMDA0MDg4DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMxOjU2
XSAgIGdmbjogMDAwMDQwODkgIG1mbjogMDAwMDQwODkNCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzE6NTZdICAgZ2ZuOiAwMDAwNDA4YSAgbWZuOiAwMDAwNDA4YQ0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMTo1Nl0gICBnZm46IDAwMDA0MDhiICBtZm46IDAwMDA0MDhiDQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMxOjU2XSAgIGdmbjogMDAwMDQwOGMgIG1mbjogMDAwMDQw
OGMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzE6NTZdICAgZ2ZuOiAwMDAwNDA4ZCAgbWZu
OiAwMDAwNDA4ZA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMTo1Nl0gICBnZm46IDAwMDA0
MDhlICBtZm46IDAwMDA0MDhlDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMxOjU2XSAgIGdm
bjogMDAwMDQwOGYgIG1mbjogMDAwMDQwOGYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzE6
NTZdICAgZ2ZuOiAwMDAwNDA5MCAgbWZuOiAwMDAwNDA5MA0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMTo1Nl0gICBnZm46IDAwMDA0MDkxICBtZm46IDAwMDA0MDkxDQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMxOjU2XSAgIGdmbjogMDAwMDQwOTIgIG1mbjogMDAwMDQwOTINCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzE6NTZdICAgZ2ZuOiAwMDAwNDA5MyAgbWZuOiAwMDAw
NDA5Mw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMTo1Nl0gICBnZm46IDAwMDA0MDk0ICBt
Zm46IDAwMDA0MDk0DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMxOjU2XSAgIGdmbjogMDAw
MDQwOTUgIG1mbjogMDAwMDQwOTUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzE6NTZdICAg
Z2ZuOiAwMDAwNDA5NiAgbWZuOiAwMDAwNDA5Ng0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
MTo1Nl0gICBnZm46IDAwMDA0MDk3ICBtZm46IDAwMDA0MDk3DQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMxOjU2XSAgIGdmbjogMDAwMDQwOTggIG1mbjogMDAwMDQwOTgNCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzE6NTZdICAgZ2ZuOiAwMDAwNDA5OSAgbWZuOiAwMDAwNDA5OQ0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMTo1Nl0gICBnZm46IDAwMDA0MDlhICBtZm46IDAw
MDA0MDlhDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMxOjU2XSAgIGdmbjogMDAwMDQwOWIg
IG1mbjogMDAwMDQwOWINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzE6NTZdICAgZ2ZuOiAw
MDAwNDA5YyAgbWZuOiAwMDAwNDA5Yw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMTo1Nl0g
ICBnZm46IDAwMDA0MDlkICBtZm46IDAwMDA0MDlkDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMxOjU2XSAgIGdmbjogMDAwMDQwOWUgIG1mbjogMDAwMDQwOWUNCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzE6NTZdICAgZ2ZuOiAwMDAwNDA5ZiAgbWZuOiAwMDAwNDA5Zg0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMTo1Nl0gICBnZm46IDAwMDA0MGEwICBtZm46IDAwMDA0MGEw
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMxOjU2XSAgIGdmbjogMDAwMDQwYTEgIG1mbjog
MDAwMDQwYTENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzE6NTZdICAgZ2ZuOiAwMDAwNDBh
MiAgbWZuOiAwMDAwNDBhMg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMTo1Nl0gICBnZm46
IDAwMDA0MGEzICBtZm46IDAwMDA0MGEzDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMxOjU2
XSAgIGdmbjogMDAwMDQwYTQgIG1mbjogMDAwMDQwYTQNCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzE6NTZdICAgZ2ZuOiAwMDAwNDBhNSAgbWZuOiAwMDAwNDBhNQ0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMTo1Nl0gICBnZm46IDAwMDA0MGE2ICBtZm46IDAwMDA0MGE2DQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMxOjU2XSAgIGdmbjogMDAwMDQwYTcgIG1mbjogMDAwMDQw
YTcNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzE6NTZdICAgZ2ZuOiAwMDAwNDBhOCAgbWZu
OiAwMDAwNDBhOA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMTo1Nl0gICBnZm46IDAwMDA0
MGE5ICBtZm46IDAwMDA0MGE5DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMxOjU2XSAgIGdm
bjogMDAwMDQwYWEgIG1mbjogMDAwMDQwYWENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzE6
NTZdICAgZ2ZuOiAwMDAwNDBhYiAgbWZuOiAwMDAwNDBhYg0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMTo1Nl0gICBnZm46IDAwMDA0MGFjICBtZm46IDAwMDA0MGFjDQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMxOjU2XSAgIGdmbjogMDAwMDQwYWQgIG1mbjogMDAwMDQwYWQNCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzE6NTZdICAgZ2ZuOiAwMDAwNDBhZSAgbWZuOiAwMDAw
NDBhZQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMTo1Nl0gICBnZm46IDAwMDA0MGFmICBt
Zm46IDAwMDA0MGFmDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMxOjU2XSAgIGdmbjogMDAw
MDQwYjAgIG1mbjogMDAwMDQwYjANCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzE6NTZdICAg
Z2ZuOiAwMDAwNDBiMSAgbWZuOiAwMDAwNDBiMQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
MTo1Nl0gICBnZm46IDAwMDA0MGIyICBtZm46IDAwMDA0MGIyDQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMxOjU2XSAgIGdmbjogMDAwMDQwYjMgIG1mbjogMDAwMDQwYjMNCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzE6NTZdICAgZ2ZuOiAwMDAwNDBiNCAgbWZuOiAwMDAwNDBiNA0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMTo1Nl0gICBnZm46IDAwMDA0MGI1ICBtZm46IDAw
MDA0MGI1DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMxOjU2XSAgIGdmbjogMDAwMDQwYjYg
IG1mbjogMDAwMDQwYjYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzE6NTZdICAgZ2ZuOiAw
MDAwNDBiNyAgbWZuOiAwMDAwNDBiNw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMTo1Nl0g
ICBnZm46IDAwMDA0MGI4ICBtZm46IDAwMDA0MGI4DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMxOjU2XSAgIGdmbjogMDAwMDQwYjkgIG1mbjogMDAwMDQwYjkNCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzE6NTZdICAgZ2ZuOiAwMDAwNDBiYSAgbWZuOiAwMDAwNDBiYQ0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMTo1Nl0gICBnZm46IDAwMDA0MGJiICBtZm46IDAwMDA0MGJi
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMxOjU2XSAgIGdmbjogMDAwMDQwYmMgIG1mbjog
MDAwMDQwYmMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzE6NTZdICAgZ2ZuOiAwMDAwNDBi
ZCAgbWZuOiAwMDAwNDBiZA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMTo1Nl0gICBnZm46
IDAwMDA0MGJlICBtZm46IDAwMDA0MGJlDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMxOjU2
XSAgIGdmbjogMDAwMDQwYmYgIG1mbjogMDAwMDQwYmYNCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzE6NTZdICAgZ2ZuOiAwMDAwNDBjMCAgbWZuOiAwMDAwNDBjMA0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMTo1Nl0gICBnZm46IDAwMDA0MGMxICBtZm46IDAwMDA0MGMxDQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMxOjU2XSAgIGdmbjogMDAwMDQwYzIgIG1mbjogMDAwMDQw
YzINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzE6NTZdICAgZ2ZuOiAwMDAwNDBjMyAgbWZu
OiAwMDAwNDBjMw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMTo1Nl0gICBnZm46IDAwMDA0
MGM0ICBtZm46IDAwMDA0MGM0DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMxOjU2XSAgIGdm
bjogMDAwMDQwYzUgIG1mbjogMDAwMDQwYzUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzE6
NTZdICAgZ2ZuOiAwMDAwNDBjNiAgbWZuOiAwMDAwNDBjNg0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMTo1Nl0gICBnZm46IDAwMDA0MGM3ICBtZm46IDAwMDA0MGM3DQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMxOjU2XSAgIGdmbjogMDAwMDQwYzggIG1mbjogMDAwMDQwYzgNCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzE6NTZdICAgZ2ZuOiAwMDAwNDBjOSAgbWZuOiAwMDAw
NDBjOQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMTo1Nl0gICBnZm46IDAwMDA0MGNhICBt
Zm46IDAwMDA0MGNhDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMxOjU2XSAgIGdmbjogMDAw
MDQwY2IgIG1mbjogMDAwMDQwY2INCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzE6NTZdICAg
Z2ZuOiAwMDAwNDBjYyAgbWZuOiAwMDAwNDBjYw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
MTo1Nl0gICBnZm46IDAwMDA0MGNkICBtZm46IDAwMDA0MGNkDQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMxOjU2XSAgIGdmbjogMDAwMDQwY2UgIG1mbjogMDAwMDQwY2UNCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzE6NTZdICAgZ2ZuOiAwMDAwNDBjZiAgbWZuOiAwMDAwNDBjZg0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMTo1Nl0gICBnZm46IDAwMDA0MGQwICBtZm46IDAw
MDA0MGQwDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMxOjU2XSAgIGdmbjogMDAwMDQwZDEg
IG1mbjogMDAwMDQwZDENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzE6NTZdICAgZ2ZuOiAw
MDAwNDBkMiAgbWZuOiAwMDAwNDBkMg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMTo1Nl0g
ICBnZm46IDAwMDA0MGQzICBtZm46IDAwMDA0MGQzDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMxOjU2XSAgIGdmbjogMDAwMDQwZDQgIG1mbjogMDAwMDQwZDQNCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzE6NTZdICAgZ2ZuOiAwMDAwNDBkNSAgbWZuOiAwMDAwNDBkNQ0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMTo1Nl0gICBnZm46IDAwMDA0MGQ2ICBtZm46IDAwMDA0MGQ2
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMxOjU2XSAgIGdmbjogMDAwMDQwZDcgIG1mbjog
MDAwMDQwZDcNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzE6NTZdICAgZ2ZuOiAwMDAwNDBk
OCAgbWZuOiAwMDAwNDBkOA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMTo1Nl0gICBnZm46
IDAwMDA0MGQ5ICBtZm46IDAwMDA0MGQ5DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMxOjU2
XSAgIGdmbjogMDAwMDQwZGEgIG1mbjogMDAwMDQwZGENCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzE6NTZdICAgZ2ZuOiAwMDAwNDBkYiAgbWZuOiAwMDAwNDBkYg0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMTo1Nl0gICBnZm46IDAwMDA0MGRjICBtZm46IDAwMDA0MGRjDQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMxOjU2XSAgIGdmbjogMDAwMDQwZGQgIG1mbjogMDAwMDQw
ZGQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzE6NTZdICAgZ2ZuOiAwMDAwNDBkZSAgbWZu
OiAwMDAwNDBkZQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMTo1Nl0gICBnZm46IDAwMDA0
MGRmICBtZm46IDAwMDA0MGRmDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMxOjU2XSAgIGdm
bjogMDAwMDQwZTAgIG1mbjogMDAwMDQwZTANCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzE6
NTZdICAgZ2ZuOiAwMDAwNDBlMSAgbWZuOiAwMDAwNDBlMQ0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMTo1Nl0gICBnZm46IDAwMDA0MGUyICBtZm46IDAwMDA0MGUyDQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMxOjU2XSAgIGdmbjogMDAwMDQwZTMgIG1mbjogMDAwMDQwZTMNCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzE6NTZdICAgZ2ZuOiAwMDAwNDBlNCAgbWZuOiAwMDAw
NDBlNA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMTo1Nl0gICBnZm46IDAwMDA0MGU1ICBt
Zm46IDAwMDA0MGU1DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMxOjU2XSAgIGdmbjogMDAw
MDQwZTYgIG1mbjogMDAwMDQwZTYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzE6NTZdICAg
Z2ZuOiAwMDAwNDBlNyAgbWZuOiAwMDAwNDBlNw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
MTo1Nl0gICBnZm46IDAwMDA0MGU4ICBtZm46IDAwMDA0MGU4DQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMxOjU2XSAgIGdmbjogMDAwMDQwZTkgIG1mbjogMDAwMDQwZTkNCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzE6NTZdICAgZ2ZuOiAwMDAwNDBlYSAgbWZuOiAwMDAwNDBlYQ0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMTo1Nl0gICBnZm46IDAwMDA0MGViICBtZm46IDAw
MDA0MGViDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMxOjU2XSAgIGdmbjogMDAwMDQwZWMg
IG1mbjogMDAwMDQwZWMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzE6NTZdICAgZ2ZuOiAw
MDAwNDBlZCAgbWZuOiAwMDAwNDBlZA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMTo1Nl0g
ICBnZm46IDAwMDA0MGVlICBtZm46IDAwMDA0MGVlDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMxOjU2XSAgIGdmbjogMDAwMDQwZWYgIG1mbjogMDAwMDQwZWYNCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzE6NTZdICAgZ2ZuOiAwMDAwNDBmMCAgbWZuOiAwMDAwNDBmMA0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMTo1Nl0gICBnZm46IDAwMDA0MGYxICBtZm46IDAwMDA0MGYx
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMxOjU2XSAgIGdmbjogMDAwMDQwZjIgIG1mbjog
MDAwMDQwZjINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzE6NTZdICAgZ2ZuOiAwMDAwNDBm
MyAgbWZuOiAwMDAwNDBmMw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMTo1Nl0gICBnZm46
IDAwMDA0MGY0ICBtZm46IDAwMDA0MGY0DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMxOjU2
XSAgIGdmbjogMDAwMDQwZjUgIG1mbjogMDAwMDQwZjUNCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzE6NTZdICAgZ2ZuOiAwMDAwNDBmNiAgbWZuOiAwMDAwNDBmNg0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMTo1Nl0gICBnZm46IDAwMDA0MGY3ICBtZm46IDAwMDA0MGY3DQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMxOjU2XSAgIGdmbjogMDAwMDQwZjggIG1mbjogMDAwMDQw
ZjgNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzE6NTZdICAgZ2ZuOiAwMDAwNDBmOSAgbWZu
OiAwMDAwNDBmOQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMTo1N10gICBnZm46IDAwMDA0
MGZhICBtZm46IDAwMDA0MGZhDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMxOjU3XSAgIGdm
bjogMDAwMDQwZmIgIG1mbjogMDAwMDQwZmINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzE6
NTddICAgZ2ZuOiAwMDAwNDBmYyAgbWZuOiAwMDAwNDBmYw0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMTo1N10gICBnZm46IDAwMDA0MGZkICBtZm46IDAwMDA0MGZkDQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMxOjU3XSAgIGdmbjogMDAwMDQwZmUgIG1mbjogMDAwMDQwZmUNCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzE6NTddICAgZ2ZuOiAwMDAwNDBmZiAgbWZuOiAwMDAw
NDBmZg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMTo1N10gICBnZm46IDAwMDA0MTAwICBt
Zm46IDAwMDA0MTAwDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMxOjU3XSAgIGdmbjogMDAw
MDQxMDEgIG1mbjogMDAwMDQxMDENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzE6NTddICAg
Z2ZuOiAwMDAwNDEwMiAgbWZuOiAwMDAwNDEwMg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
MTo1N10gICBnZm46IDAwMDA0MTAzICBtZm46IDAwMDA0MTAzDQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMxOjU3XSAgIGdmbjogMDAwMDQxMDQgIG1mbjogMDAwMDQxMDQNCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzE6NTddICAgZ2ZuOiAwMDAwNDEwNSAgbWZuOiAwMDAwNDEwNQ0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMTo1N10gICBnZm46IDAwMDA0MTA2ICBtZm46IDAw
MDA0MTA2DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMxOjU3XSAgIGdmbjogMDAwMDQxMDcg
IG1mbjogMDAwMDQxMDcNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzE6NTddICAgZ2ZuOiAw
MDAwNDEwOCAgbWZuOiAwMDAwNDEwOA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMTo1N10g
ICBnZm46IDAwMDA0MTA5ICBtZm46IDAwMDA0MTA5DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMxOjU3XSAgIGdmbjogMDAwMDQxMGEgIG1mbjogMDAwMDQxMGENCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzE6NTddICAgZ2ZuOiAwMDAwNDEwYiAgbWZuOiAwMDAwNDEwYg0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMTo1N10gICBnZm46IDAwMDA0MTBjICBtZm46IDAwMDA0MTBj
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMxOjU3XSAgIGdmbjogMDAwMDQxMGQgIG1mbjog
MDAwMDQxMGQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzE6NTddICAgZ2ZuOiAwMDAwNDEw
ZSAgbWZuOiAwMDAwNDEwZQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMTo1N10gICBnZm46
IDAwMDA0MTBmICBtZm46IDAwMDA0MTBmDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMxOjU3
XSAgIGdmbjogMDAwMDQxMTAgIG1mbjogMDAwMDQxMTANCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzE6NTddICAgZ2ZuOiAwMDAwNDExMSAgbWZuOiAwMDAwNDExMQ0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMTo1N10gICBnZm46IDAwMDA0MTEyICBtZm46IDAwMDA0MTEyDQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMxOjU3XSAgIGdmbjogMDAwMDQxMTMgIG1mbjogMDAwMDQx
MTMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzE6NTddICAgZ2ZuOiAwMDAwNDExNCAgbWZu
OiAwMDAwNDExNA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMTo1N10gICBnZm46IDAwMDA0
MTE1ICBtZm46IDAwMDA0MTE1DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMxOjU3XSAgIGdm
bjogMDAwMDQxMTYgIG1mbjogMDAwMDQxMTYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzE6
NTddICAgZ2ZuOiAwMDAwNDExNyAgbWZuOiAwMDAwNDExNw0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMTo1N10gICBnZm46IDAwMDA0MTE4ICBtZm46IDAwMDA0MTE4DQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMxOjU3XSAgIGdmbjogMDAwMDQxMTkgIG1mbjogMDAwMDQxMTkNCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzE6NTddICAgZ2ZuOiAwMDAwNDExYSAgbWZuOiAwMDAw
NDExYQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMTo1N10gICBnZm46IDAwMDA0MTFiICBt
Zm46IDAwMDA0MTFiDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMxOjU3XSAgIGdmbjogMDAw
MDQxMWMgIG1mbjogMDAwMDQxMWMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzE6NTddICAg
Z2ZuOiAwMDAwNDExZCAgbWZuOiAwMDAwNDExZA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
MTo1N10gICBnZm46IDAwMDA0MTFlICBtZm46IDAwMDA0MTFlDQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMxOjU3XSAgIGdmbjogMDAwMDQxMWYgIG1mbjogMDAwMDQxMWYNCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzE6NTddICAgZ2ZuOiAwMDAwNDEyMCAgbWZuOiAwMDAwNDEyMA0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMTo1N10gICBnZm46IDAwMDA0MTIxICBtZm46IDAw
MDA0MTIxDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMxOjU3XSAgIGdmbjogMDAwMDQxMjIg
IG1mbjogMDAwMDQxMjINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzE6NTddICAgZ2ZuOiAw
MDAwNDEyMyAgbWZuOiAwMDAwNDEyMw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMTo1N10g
ICBnZm46IDAwMDA0MTI0ICBtZm46IDAwMDA0MTI0DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMxOjU3XSAgIGdmbjogMDAwMDQxMjUgIG1mbjogMDAwMDQxMjUNCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzE6NTddICAgZ2ZuOiAwMDAwNDEyNiAgbWZuOiAwMDAwNDEyNg0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMTo1N10gICBnZm46IDAwMDA0MTI3ICBtZm46IDAwMDA0MTI3
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMxOjU3XSAgIGdmbjogMDAwMDQxMjggIG1mbjog
MDAwMDQxMjgNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzE6NTddICAgZ2ZuOiAwMDAwNDEy
OSAgbWZuOiAwMDAwNDEyOQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMTo1N10gICBnZm46
IDAwMDA0MTJhICBtZm46IDAwMDA0MTJhDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMxOjU3
XSAgIGdmbjogMDAwMDQxMmIgIG1mbjogMDAwMDQxMmINCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzE6NTddICAgZ2ZuOiAwMDAwNDEyYyAgbWZuOiAwMDAwNDEyYw0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMTo1N10gICBnZm46IDAwMDA0MTJkICBtZm46IDAwMDA0MTJkDQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMxOjU3XSAgIGdmbjogMDAwMDQxMmUgIG1mbjogMDAwMDQx
MmUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzE6NTddICAgZ2ZuOiAwMDAwNDEyZiAgbWZu
OiAwMDAwNDEyZg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMTo1N10gICBnZm46IDAwMDA0
MTMwICBtZm46IDAwMDA0MTMwDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMxOjU3XSAgIGdm
bjogMDAwMDQxMzEgIG1mbjogMDAwMDQxMzENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzE6
NTddICAgZ2ZuOiAwMDAwNDEzMiAgbWZuOiAwMDAwNDEzMg0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMTo1N10gICBnZm46IDAwMDA0MTMzICBtZm46IDAwMDA0MTMzDQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMxOjU3XSAgIGdmbjogMDAwMDQxMzQgIG1mbjogMDAwMDQxMzQNCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzE6NTddICAgZ2ZuOiAwMDAwNDEzNSAgbWZuOiAwMDAw
NDEzNQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMTo1N10gICBnZm46IDAwMDA0MTM2ICBt
Zm46IDAwMDA0MTM2DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMxOjU3XSAgIGdmbjogMDAw
MDQxMzcgIG1mbjogMDAwMDQxMzcNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzE6NTddICAg
Z2ZuOiAwMDAwNDEzOCAgbWZuOiAwMDAwNDEzOA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
MTo1N10gICBnZm46IDAwMDA0MTM5ICBtZm46IDAwMDA0MTM5DQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMxOjU4XSAgIGdmbjogMDAwMDQxM2EgIG1mbjogMDAwMDQxM2ENCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzE6NThdICAgZ2ZuOiAwMDAwNDEzYiAgbWZuOiAwMDAwNDEzYg0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMTo1OF0gICBnZm46IDAwMDA0MTNjICBtZm46IDAw
MDA0MTNjDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMxOjU4XSAgIGdmbjogMDAwMDQxM2Qg
IG1mbjogMDAwMDQxM2QNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzE6NThdICAgZ2ZuOiAw
MDAwNDEzZSAgbWZuOiAwMDAwNDEzZQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMTo1OF0g
ICBnZm46IDAwMDA0MTNmICBtZm46IDAwMDA0MTNmDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMxOjU4XSAgIGdmbjogMDAwMDQxNDAgIG1mbjogMDAwMDQxNDANCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzE6NThdICAgZ2ZuOiAwMDAwNDE0MSAgbWZuOiAwMDAwNDE0MQ0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMTo1OF0gICBnZm46IDAwMDA0MTQyICBtZm46IDAwMDA0MTQy
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMxOjU4XSAgIGdmbjogMDAwMDQxNDMgIG1mbjog
MDAwMDQxNDMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzE6NThdICAgZ2ZuOiAwMDAwNDE0
NCAgbWZuOiAwMDAwNDE0NA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMTo1OF0gICBnZm46
IDAwMDA0MTQ1ICBtZm46IDAwMDA0MTQ1DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMxOjU4
XSAgIGdmbjogMDAwMDQxNDYgIG1mbjogMDAwMDQxNDYNCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzE6NThdICAgZ2ZuOiAwMDAwNDE0NyAgbWZuOiAwMDAwNDE0Nw0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMTo1OF0gICBnZm46IDAwMDA0MTQ4ICBtZm46IDAwMDA0MTQ4DQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMxOjU4XSAgIGdmbjogMDAwMDQxNDkgIG1mbjogMDAwMDQx
NDkNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzE6NThdICAgZ2ZuOiAwMDAwNDE0YSAgbWZu
OiAwMDAwNDE0YQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMTo1OF0gICBnZm46IDAwMDA0
MTRiICBtZm46IDAwMDA0MTRiDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMxOjU4XSAgIGdm
bjogMDAwMDQxNGMgIG1mbjogMDAwMDQxNGMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzE6
NThdICAgZ2ZuOiAwMDAwNDE0ZCAgbWZuOiAwMDAwNDE0ZA0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMTo1OF0gICBnZm46IDAwMDA0MTRlICBtZm46IDAwMDA0MTRlDQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMxOjU4XSAgIGdmbjogMDAwMDQxNGYgIG1mbjogMDAwMDQxNGYNCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzE6NThdICAgZ2ZuOiAwMDAwNDE1MCAgbWZuOiAwMDAw
NDE1MA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMTo1OF0gICBnZm46IDAwMDA0MTUxICBt
Zm46IDAwMDA0MTUxDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMxOjU4XSAgIGdmbjogMDAw
MDQxNTIgIG1mbjogMDAwMDQxNTINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzE6NThdICAg
Z2ZuOiAwMDAwNDE1MyAgbWZuOiAwMDAwNDE1Mw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
MTo1OF0gICBnZm46IDAwMDA0MTU0ICBtZm46IDAwMDA0MTU0DQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMxOjU4XSAgIGdmbjogMDAwMDQxNTUgIG1mbjogMDAwMDQxNTUNCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzE6NThdICAgZ2ZuOiAwMDAwNDE1NiAgbWZuOiAwMDAwNDE1Ng0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMTo1OF0gICBnZm46IDAwMDA0MTU3ICBtZm46IDAw
MDA0MTU3DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMxOjU4XSAgIGdmbjogMDAwMDQxNTgg
IG1mbjogMDAwMDQxNTgNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzE6NThdICAgZ2ZuOiAw
MDAwNDE1OSAgbWZuOiAwMDAwNDE1OQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMTo1OF0g
ICBnZm46IDAwMDA0MTVhICBtZm46IDAwMDA0MTVhDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMxOjU4XSAgIGdmbjogMDAwMDQxNWIgIG1mbjogMDAwMDQxNWINCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzE6NThdICAgZ2ZuOiAwMDAwNDE1YyAgbWZuOiAwMDAwNDE1Yw0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMTo1OF0gICBnZm46IDAwMDA0MTVkICBtZm46IDAwMDA0MTVk
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMxOjU4XSAgIGdmbjogMDAwMDQxNWUgIG1mbjog
MDAwMDQxNWUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzE6NThdICAgZ2ZuOiAwMDAwNDE1
ZiAgbWZuOiAwMDAwNDE1Zg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMTo1OF0gICBnZm46
IDAwMDA0MTYwICBtZm46IDAwMDA0MTYwDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMxOjU4
XSAgIGdmbjogMDAwMDQxNjEgIG1mbjogMDAwMDQxNjENCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzE6NThdICAgZ2ZuOiAwMDAwNDE2MiAgbWZuOiAwMDAwNDE2Mg0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMTo1OF0gICBnZm46IDAwMDA0MTYzICBtZm46IDAwMDA0MTYzDQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMxOjU4XSAgIGdmbjogMDAwMDQxNjQgIG1mbjogMDAwMDQx
NjQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzE6NThdICAgZ2ZuOiAwMDAwNDE2NSAgbWZu
OiAwMDAwNDE2NQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMTo1OF0gICBnZm46IDAwMDA0
MTY2ICBtZm46IDAwMDA0MTY2DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMxOjU4XSAgIGdm
bjogMDAwMDQxNjcgIG1mbjogMDAwMDQxNjcNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzE6
NThdICAgZ2ZuOiAwMDAwNDE2OCAgbWZuOiAwMDAwNDE2OA0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMTo1OF0gICBnZm46IDAwMDA0MTY5ICBtZm46IDAwMDA0MTY5DQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMxOjU4XSAgIGdmbjogMDAwMDQxNmEgIG1mbjogMDAwMDQxNmENCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzE6NThdICAgZ2ZuOiAwMDAwNDE2YiAgbWZuOiAwMDAw
NDE2Yg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMTo1OF0gICBnZm46IDAwMDA0MTZjICBt
Zm46IDAwMDA0MTZjDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMxOjU4XSAgIGdmbjogMDAw
MDQxNmQgIG1mbjogMDAwMDQxNmQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzE6NThdICAg
Z2ZuOiAwMDAwNDE2ZSAgbWZuOiAwMDAwNDE2ZQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
MTo1OF0gICBnZm46IDAwMDA0MTZmICBtZm46IDAwMDA0MTZmDQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMxOjU4XSAgIGdmbjogMDAwMDQxNzAgIG1mbjogMDAwMDQxNzANCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzE6NThdICAgZ2ZuOiAwMDAwNDE3MSAgbWZuOiAwMDAwNDE3MQ0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMTo1OF0gICBnZm46IDAwMDA0MTcyICBtZm46IDAw
MDA0MTcyDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMxOjU4XSAgIGdmbjogMDAwMDQxNzMg
IG1mbjogMDAwMDQxNzMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzE6NThdICAgZ2ZuOiAw
MDAwNDE3NCAgbWZuOiAwMDAwNDE3NA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMTo1OF0g
ICBnZm46IDAwMDA0MTc1ICBtZm46IDAwMDA0MTc1DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMxOjU4XSAgIGdmbjogMDAwMDQxNzYgIG1mbjogMDAwMDQxNzYNCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzE6NThdICAgZ2ZuOiAwMDAwNDE3NyAgbWZuOiAwMDAwNDE3Nw0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMTo1OF0gICBnZm46IDAwMDA0MTc4ICBtZm46IDAwMDA0MTc4
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMxOjU4XSAgIGdmbjogMDAwMDQxNzkgIG1mbjog
MDAwMDQxNzkNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzE6NTldICAgZ2ZuOiAwMDAwNDE3
YSAgbWZuOiAwMDAwNDE3YQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMTo1OV0gICBnZm46
IDAwMDA0MTdiICBtZm46IDAwMDA0MTdiDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMxOjU5
XSAgIGdmbjogMDAwMDQxN2MgIG1mbjogMDAwMDQxN2MNCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzE6NTldICAgZ2ZuOiAwMDAwNDE3ZCAgbWZuOiAwMDAwNDE3ZA0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMTo1OV0gICBnZm46IDAwMDA0MTdlICBtZm46IDAwMDA0MTdlDQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMxOjU5XSAgIGdmbjogMDAwMDQxN2YgIG1mbjogMDAwMDQx
N2YNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzE6NTldICAgZ2ZuOiAwMDAwNDE4MCAgbWZu
OiAwMDAwNDE4MA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMTo1OV0gICBnZm46IDAwMDA0
MTgxICBtZm46IDAwMDA0MTgxDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMxOjU5XSAgIGdm
bjogMDAwMDQxODIgIG1mbjogMDAwMDQxODINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzE6
NTldICAgZ2ZuOiAwMDAwNDE4MyAgbWZuOiAwMDAwNDE4Mw0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMTo1OV0gICBnZm46IDAwMDA0MTg0ICBtZm46IDAwMDA0MTg0DQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMxOjU5XSAgIGdmbjogMDAwMDQxODUgIG1mbjogMDAwMDQxODUNCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzE6NTldICAgZ2ZuOiAwMDAwNDE4NiAgbWZuOiAwMDAw
NDE4Ng0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMTo1OV0gICBnZm46IDAwMDA0MTg3ICBt
Zm46IDAwMDA0MTg3DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMxOjU5XSAgIGdmbjogMDAw
MDQxODggIG1mbjogMDAwMDQxODgNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzE6NTldICAg
Z2ZuOiAwMDAwNDE4OSAgbWZuOiAwMDAwNDE4OQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
MTo1OV0gICBnZm46IDAwMDA0MThhICBtZm46IDAwMDA0MThhDQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMxOjU5XSAgIGdmbjogMDAwMDQxOGIgIG1mbjogMDAwMDQxOGINCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzE6NTldICAgZ2ZuOiAwMDAwNDE4YyAgbWZuOiAwMDAwNDE4Yw0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMTo1OV0gICBnZm46IDAwMDA0MThkICBtZm46IDAw
MDA0MThkDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMxOjU5XSAgIGdmbjogMDAwMDQxOGUg
IG1mbjogMDAwMDQxOGUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzE6NTldICAgZ2ZuOiAw
MDAwNDE4ZiAgbWZuOiAwMDAwNDE4Zg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMTo1OV0g
ICBnZm46IDAwMDA0MTkwICBtZm46IDAwMDA0MTkwDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMxOjU5XSAgIGdmbjogMDAwMDQxOTEgIG1mbjogMDAwMDQxOTENCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzE6NTldICAgZ2ZuOiAwMDAwNDE5MiAgbWZuOiAwMDAwNDE5Mg0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMTo1OV0gICBnZm46IDAwMDA0MTkzICBtZm46IDAwMDA0MTkz
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMxOjU5XSAgIGdmbjogMDAwMDQxOTQgIG1mbjog
MDAwMDQxOTQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzE6NTldICAgZ2ZuOiAwMDAwNDE5
NSAgbWZuOiAwMDAwNDE5NQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMTo1OV0gICBnZm46
IDAwMDA0MTk2ICBtZm46IDAwMDA0MTk2DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMxOjU5
XSAgIGdmbjogMDAwMDQxOTcgIG1mbjogMDAwMDQxOTcNCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzE6NTldICAgZ2ZuOiAwMDAwNDE5OCAgbWZuOiAwMDAwNDE5OA0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMTo1OV0gICBnZm46IDAwMDA0MTk5ICBtZm46IDAwMDA0MTk5DQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMxOjU5XSAgIGdmbjogMDAwMDQxOWEgIG1mbjogMDAwMDQx
OWENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzE6NTldICAgZ2ZuOiAwMDAwNDE5YiAgbWZu
OiAwMDAwNDE5Yg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMTo1OV0gICBnZm46IDAwMDA0
MTljICBtZm46IDAwMDA0MTljDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMxOjU5XSAgIGdm
bjogMDAwMDQxOWQgIG1mbjogMDAwMDQxOWQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzE6
NTldICAgZ2ZuOiAwMDAwNDE5ZSAgbWZuOiAwMDAwNDE5ZQ0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMTo1OV0gICBnZm46IDAwMDA0MTlmICBtZm46IDAwMDA0MTlmDQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMxOjU5XSAgIGdmbjogMDAwMDQxYTAgIG1mbjogMDAwMDQxYTANCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzE6NTldICAgZ2ZuOiAwMDAwNDFhMSAgbWZuOiAwMDAw
NDFhMQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMTo1OV0gICBnZm46IDAwMDA0MWEyICBt
Zm46IDAwMDA0MWEyDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMxOjU5XSAgIGdmbjogMDAw
MDQxYTMgIG1mbjogMDAwMDQxYTMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzE6NTldICAg
Z2ZuOiAwMDAwNDFhNCAgbWZuOiAwMDAwNDFhNA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
MTo1OV0gICBnZm46IDAwMDA0MWE1ICBtZm46IDAwMDA0MWE1DQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMxOjU5XSAgIGdmbjogMDAwMDQxYTYgIG1mbjogMDAwMDQxYTYNCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzE6NTldICAgZ2ZuOiAwMDAwNDFhNyAgbWZuOiAwMDAwNDFhNw0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMTo1OV0gICBnZm46IDAwMDA0MWE4ICBtZm46IDAw
MDA0MWE4DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMxOjU5XSAgIGdmbjogMDAwMDQxYTkg
IG1mbjogMDAwMDQxYTkNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzE6NTldICAgZ2ZuOiAw
MDAwNDFhYSAgbWZuOiAwMDAwNDFhYQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMTo1OV0g
ICBnZm46IDAwMDA0MWFiICBtZm46IDAwMDA0MWFiDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMxOjU5XSAgIGdmbjogMDAwMDQxYWMgIG1mbjogMDAwMDQxYWMNCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzE6NTldICAgZ2ZuOiAwMDAwNDFhZCAgbWZuOiAwMDAwNDFhZA0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMTo1OV0gICBnZm46IDAwMDA0MWFlICBtZm46IDAwMDA0MWFl
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMxOjU5XSAgIGdmbjogMDAwMDQxYWYgIG1mbjog
MDAwMDQxYWYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzE6NTldICAgZ2ZuOiAwMDAwNDFi
MCAgbWZuOiAwMDAwNDFiMA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMTo1OV0gICBnZm46
IDAwMDA0MWIxICBtZm46IDAwMDA0MWIxDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMxOjU5
XSAgIGdmbjogMDAwMDQxYjIgIG1mbjogMDAwMDQxYjINCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzE6NTldICAgZ2ZuOiAwMDAwNDFiMyAgbWZuOiAwMDAwNDFiMw0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMTo1OV0gICBnZm46IDAwMDA0MWI0ICBtZm46IDAwMDA0MWI0DQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMxOjU5XSAgIGdmbjogMDAwMDQxYjUgIG1mbjogMDAwMDQx
YjUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzE6NTldICAgZ2ZuOiAwMDAwNDFiNiAgbWZu
OiAwMDAwNDFiNg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMTo1OV0gICBnZm46IDAwMDA0
MWI3ICBtZm46IDAwMDA0MWI3DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMxOjU5XSAgIGdm
bjogMDAwMDQxYjggIG1mbjogMDAwMDQxYjgNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzE6
NTldICAgZ2ZuOiAwMDAwNDFiOSAgbWZuOiAwMDAwNDFiOQ0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMjowMF0gICBnZm46IDAwMDA0MWJhICBtZm46IDAwMDA0MWJhDQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMyOjAwXSAgIGdmbjogMDAwMDQxYmIgIG1mbjogMDAwMDQxYmINCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MDBdICAgZ2ZuOiAwMDAwNDFiYyAgbWZuOiAwMDAw
NDFiYw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjowMF0gICBnZm46IDAwMDA0MWJkICBt
Zm46IDAwMDA0MWJkDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjAwXSAgIGdmbjogMDAw
MDQxYmUgIG1mbjogMDAwMDQxYmUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MDBdICAg
Z2ZuOiAwMDAwNDFiZiAgbWZuOiAwMDAwNDFiZg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
MjowMF0gICBnZm46IDAwMDA0MWMwICBtZm46IDAwMDA0MWMwDQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMyOjAwXSAgIGdmbjogMDAwMDQxYzEgIG1mbjogMDAwMDQxYzENCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzI6MDBdICAgZ2ZuOiAwMDAwNDFjMiAgbWZuOiAwMDAwNDFjMg0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjowMF0gICBnZm46IDAwMDA0MWMzICBtZm46IDAw
MDA0MWMzDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjAwXSAgIGdmbjogMDAwMDQxYzQg
IG1mbjogMDAwMDQxYzQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MDBdICAgZ2ZuOiAw
MDAwNDFjNSAgbWZuOiAwMDAwNDFjNQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjowMF0g
ICBnZm46IDAwMDA0MWM2ICBtZm46IDAwMDA0MWM2DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMyOjAwXSAgIGdmbjogMDAwMDQxYzcgIG1mbjogMDAwMDQxYzcNCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzI6MDBdICAgZ2ZuOiAwMDAwNDFjOCAgbWZuOiAwMDAwNDFjOA0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMjowMF0gICBnZm46IDAwMDA0MWM5ICBtZm46IDAwMDA0MWM5
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjAwXSAgIGdmbjogMDAwMDQxY2EgIG1mbjog
MDAwMDQxY2ENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MDBdICAgZ2ZuOiAwMDAwNDFj
YiAgbWZuOiAwMDAwNDFjYg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjowMF0gICBnZm46
IDAwMDA0MWNjICBtZm46IDAwMDA0MWNjDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjAw
XSAgIGdmbjogMDAwMDQxY2QgIG1mbjogMDAwMDQxY2QNCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzI6MDBdICAgZ2ZuOiAwMDAwNDFjZSAgbWZuOiAwMDAwNDFjZQ0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMjowMF0gICBnZm46IDAwMDA0MWNmICBtZm46IDAwMDA0MWNmDQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMyOjAwXSAgIGdmbjogMDAwMDQxZDAgIG1mbjogMDAwMDQx
ZDANCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MDBdICAgZ2ZuOiAwMDAwNDFkMSAgbWZu
OiAwMDAwNDFkMQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjowMF0gICBnZm46IDAwMDA0
MWQyICBtZm46IDAwMDA0MWQyDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjAwXSAgIGdm
bjogMDAwMDQxZDMgIG1mbjogMDAwMDQxZDMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6
MDBdICAgZ2ZuOiAwMDAwNDFkNCAgbWZuOiAwMDAwNDFkNA0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMjowMF0gICBnZm46IDAwMDA0MWQ1ICBtZm46IDAwMDA0MWQ1DQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMyOjAwXSAgIGdmbjogMDAwMDQxZDYgIG1mbjogMDAwMDQxZDYNCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MDBdICAgZ2ZuOiAwMDAwNDFkNyAgbWZuOiAwMDAw
NDFkNw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjowMF0gICBnZm46IDAwMDA0MWQ4ICBt
Zm46IDAwMDA0MWQ4DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjAwXSAgIGdmbjogMDAw
MDQxZDkgIG1mbjogMDAwMDQxZDkNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MDBdICAg
Z2ZuOiAwMDAwNDFkYSAgbWZuOiAwMDAwNDFkYQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
MjowMF0gICBnZm46IDAwMDA0MWRiICBtZm46IDAwMDA0MWRiDQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMyOjAwXSAgIGdmbjogMDAwMDQxZGMgIG1mbjogMDAwMDQxZGMNCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzI6MDBdICAgZ2ZuOiAwMDAwNDFkZCAgbWZuOiAwMDAwNDFkZA0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjowMF0gICBnZm46IDAwMDA0MWRlICBtZm46IDAw
MDA0MWRlDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjAwXSAgIGdmbjogMDAwMDQxZGYg
IG1mbjogMDAwMDQxZGYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MDBdICAgZ2ZuOiAw
MDAwNDFlMCAgbWZuOiAwMDAwNDFlMA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjowMF0g
ICBnZm46IDAwMDA0MWUxICBtZm46IDAwMDA0MWUxDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMyOjAwXSAgIGdmbjogMDAwMDQxZTIgIG1mbjogMDAwMDQxZTINCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzI6MDBdICAgZ2ZuOiAwMDAwNDFlMyAgbWZuOiAwMDAwNDFlMw0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMjowMF0gICBnZm46IDAwMDA0MWU0ICBtZm46IDAwMDA0MWU0
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjAwXSAgIGdmbjogMDAwMDQxZTUgIG1mbjog
MDAwMDQxZTUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MDBdICAgZ2ZuOiAwMDAwNDFl
NiAgbWZuOiAwMDAwNDFlNg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjowMF0gICBnZm46
IDAwMDA0MWU3ICBtZm46IDAwMDA0MWU3DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjAw
XSAgIGdmbjogMDAwMDQxZTggIG1mbjogMDAwMDQxZTgNCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzI6MDBdICAgZ2ZuOiAwMDAwNDFlOSAgbWZuOiAwMDAwNDFlOQ0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMjowMF0gICBnZm46IDAwMDA0MWVhICBtZm46IDAwMDA0MWVhDQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMyOjAwXSAgIGdmbjogMDAwMDQxZWIgIG1mbjogMDAwMDQx
ZWINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MDBdICAgZ2ZuOiAwMDAwNDFlYyAgbWZu
OiAwMDAwNDFlYw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjowMF0gICBnZm46IDAwMDA0
MWVkICBtZm46IDAwMDA0MWVkDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjAwXSAgIGdm
bjogMDAwMDQxZWUgIG1mbjogMDAwMDQxZWUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6
MDBdICAgZ2ZuOiAwMDAwNDFlZiAgbWZuOiAwMDAwNDFlZg0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMjowMF0gICBnZm46IDAwMDA0MWYwICBtZm46IDAwMDA0MWYwDQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMyOjAwXSAgIGdmbjogMDAwMDQxZjEgIG1mbjogMDAwMDQxZjENCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MDBdICAgZ2ZuOiAwMDAwNDFmMiAgbWZuOiAwMDAw
NDFmMg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjowMF0gICBnZm46IDAwMDA0MWYzICBt
Zm46IDAwMDA0MWYzDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjAwXSAgIGdmbjogMDAw
MDQxZjQgIG1mbjogMDAwMDQxZjQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MDBdICAg
Z2ZuOiAwMDAwNDFmNSAgbWZuOiAwMDAwNDFmNQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
MjowMF0gICBnZm46IDAwMDA0MWY2ICBtZm46IDAwMDA0MWY2DQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMyOjAwXSAgIGdmbjogMDAwMDQxZjcgIG1mbjogMDAwMDQxZjcNCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzI6MDBdICAgZ2ZuOiAwMDAwNDFmOCAgbWZuOiAwMDAwNDFmOA0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjowMF0gICBnZm46IDAwMDA0MWY5ICBtZm46IDAw
MDA0MWY5DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjAxXSAgIGdmbjogMDAwMDQxZmEg
IG1mbjogMDAwMDQxZmENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MDFdICAgZ2ZuOiAw
MDAwNDFmYiAgbWZuOiAwMDAwNDFmYg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjowMV0g
ICBnZm46IDAwMDA0MWZjICBtZm46IDAwMDA0MWZjDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMyOjAxXSAgIGdmbjogMDAwMDQxZmQgIG1mbjogMDAwMDQxZmQNCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzI6MDFdICAgZ2ZuOiAwMDAwNDFmZSAgbWZuOiAwMDAwNDFmZQ0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMjowMV0gICBnZm46IDAwMDA0MWZmICBtZm46IDAwMDA0MWZm
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjAxXSAgIGdmbjogMDAwMDQyMDAgIG1mbjog
MDAwMDQyMDANCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MDFdICAgZ2ZuOiAwMDAwNDIw
MSAgbWZuOiAwMDAwNDIwMQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjowMV0gICBnZm46
IDAwMDA0MjAyICBtZm46IDAwMDA0MjAyDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjAx
XSAgIGdmbjogMDAwMDQyMDMgIG1mbjogMDAwMDQyMDMNCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzI6MDFdICAgZ2ZuOiAwMDAwNDIwNCAgbWZuOiAwMDAwNDIwNA0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMjowMV0gICBnZm46IDAwMDA0MjA1ICBtZm46IDAwMDA0MjA1DQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMyOjAxXSAgIGdmbjogMDAwMDQyMDYgIG1mbjogMDAwMDQy
MDYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MDFdICAgZ2ZuOiAwMDAwNDIwNyAgbWZu
OiAwMDAwNDIwNw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjowMV0gICBnZm46IDAwMDA0
MjA4ICBtZm46IDAwMDA0MjA4DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjAxXSAgIGdm
bjogMDAwMDQyMDkgIG1mbjogMDAwMDQyMDkNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6
MDFdICAgZ2ZuOiAwMDAwNDIwYSAgbWZuOiAwMDAwNDIwYQ0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMjowMV0gICBnZm46IDAwMDA0MjBiICBtZm46IDAwMDA0MjBiDQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMyOjAxXSAgIGdmbjogMDAwMDQyMGMgIG1mbjogMDAwMDQyMGMNCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MDFdICAgZ2ZuOiAwMDAwNDIwZCAgbWZuOiAwMDAw
NDIwZA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjowMV0gICBnZm46IDAwMDA0MjBlICBt
Zm46IDAwMDA0MjBlDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjAxXSAgIGdmbjogMDAw
MDQyMGYgIG1mbjogMDAwMDQyMGYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MDFdICAg
Z2ZuOiAwMDAwNDIxMCAgbWZuOiAwMDAwNDIxMA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
MjowMV0gICBnZm46IDAwMDA0MjExICBtZm46IDAwMDA0MjExDQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMyOjAxXSAgIGdmbjogMDAwMDQyMTIgIG1mbjogMDAwMDQyMTINCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzI6MDFdICAgZ2ZuOiAwMDAwNDIxMyAgbWZuOiAwMDAwNDIxMw0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjowMV0gICBnZm46IDAwMDA0MjE0ICBtZm46IDAw
MDA0MjE0DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjAxXSAgIGdmbjogMDAwMDQyMTUg
IG1mbjogMDAwMDQyMTUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MDFdICAgZ2ZuOiAw
MDAwNDIxNiAgbWZuOiAwMDAwNDIxNg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjowMV0g
ICBnZm46IDAwMDA0MjE3ICBtZm46IDAwMDA0MjE3DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMyOjAxXSAgIGdmbjogMDAwMDQyMTggIG1mbjogMDAwMDQyMTgNCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzI6MDFdICAgZ2ZuOiAwMDAwNDIxOSAgbWZuOiAwMDAwNDIxOQ0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMjowMV0gICBnZm46IDAwMDA0MjFhICBtZm46IDAwMDA0MjFh
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjAxXSAgIGdmbjogMDAwMDQyMWIgIG1mbjog
MDAwMDQyMWINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MDFdICAgZ2ZuOiAwMDAwNDIx
YyAgbWZuOiAwMDAwNDIxYw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjowMV0gICBnZm46
IDAwMDA0MjFkICBtZm46IDAwMDA0MjFkDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjAx
XSAgIGdmbjogMDAwMDQyMWUgIG1mbjogMDAwMDQyMWUNCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzI6MDFdICAgZ2ZuOiAwMDAwNDIxZiAgbWZuOiAwMDAwNDIxZg0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMjowMV0gICBnZm46IDAwMDA0MjIwICBtZm46IDAwMDA0MjIwDQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMyOjAxXSAgIGdmbjogMDAwMDQyMjEgIG1mbjogMDAwMDQy
MjENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MDFdICAgZ2ZuOiAwMDAwNDIyMiAgbWZu
OiAwMDAwNDIyMg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjowMV0gICBnZm46IDAwMDA0
MjIzICBtZm46IDAwMDA0MjIzDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjAxXSAgIGdm
bjogMDAwMDQyMjQgIG1mbjogMDAwMDQyMjQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6
MDFdICAgZ2ZuOiAwMDAwNDIyNSAgbWZuOiAwMDAwNDIyNQ0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMjowMV0gICBnZm46IDAwMDA0MjI2ICBtZm46IDAwMDA0MjI2DQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMyOjAxXSAgIGdmbjogMDAwMDQyMjcgIG1mbjogMDAwMDQyMjcNCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MDFdICAgZ2ZuOiAwMDAwNDIyOCAgbWZuOiAwMDAw
NDIyOA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjowMV0gICBnZm46IDAwMDA0MjI5ICBt
Zm46IDAwMDA0MjI5DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjAxXSAgIGdmbjogMDAw
MDQyMmEgIG1mbjogMDAwMDQyMmENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MDFdICAg
Z2ZuOiAwMDAwNDIyYiAgbWZuOiAwMDAwNDIyYg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
MjowMV0gICBnZm46IDAwMDA0MjJjICBtZm46IDAwMDA0MjJjDQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMyOjAxXSAgIGdmbjogMDAwMDQyMmQgIG1mbjogMDAwMDQyMmQNCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzI6MDFdICAgZ2ZuOiAwMDAwNDIyZSAgbWZuOiAwMDAwNDIyZQ0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjowMV0gICBnZm46IDAwMDA0MjJmICBtZm46IDAw
MDA0MjJmDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjAxXSAgIGdmbjogMDAwMDQyMzAg
IG1mbjogMDAwMDQyMzANCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MDFdICAgZ2ZuOiAw
MDAwNDIzMSAgbWZuOiAwMDAwNDIzMQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjowMV0g
ICBnZm46IDAwMDA0MjMyICBtZm46IDAwMDA0MjMyDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMyOjAxXSAgIGdmbjogMDAwMDQyMzMgIG1mbjogMDAwMDQyMzMNCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzI6MDFdICAgZ2ZuOiAwMDAwNDIzNCAgbWZuOiAwMDAwNDIzNA0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMjowMV0gICBnZm46IDAwMDA0MjM1ICBtZm46IDAwMDA0MjM1
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjAxXSAgIGdmbjogMDAwMDQyMzYgIG1mbjog
MDAwMDQyMzYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MDFdICAgZ2ZuOiAwMDAwNDIz
NyAgbWZuOiAwMDAwNDIzNw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjowMV0gICBnZm46
IDAwMDA0MjM4ICBtZm46IDAwMDA0MjM4DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjAx
XSAgIGdmbjogMDAwMDQyMzkgIG1mbjogMDAwMDQyMzkNCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzI6MDJdICAgZ2ZuOiAwMDAwNDIzYSAgbWZuOiAwMDAwNDIzYQ0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMjowMl0gICBnZm46IDAwMDA0MjNiICBtZm46IDAwMDA0MjNiDQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMyOjAyXSAgIGdmbjogMDAwMDQyM2MgIG1mbjogMDAwMDQy
M2MNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MDJdICAgZ2ZuOiAwMDAwNDIzZCAgbWZu
OiAwMDAwNDIzZA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjowMl0gICBnZm46IDAwMDA0
MjNlICBtZm46IDAwMDA0MjNlDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjAyXSAgIGdm
bjogMDAwMDQyM2YgIG1mbjogMDAwMDQyM2YNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6
MDJdICAgZ2ZuOiAwMDAwNDI0MCAgbWZuOiAwMDAwNDI0MA0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMjowMl0gICBnZm46IDAwMDA0MjQxICBtZm46IDAwMDA0MjQxDQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMyOjAyXSAgIGdmbjogMDAwMDQyNDIgIG1mbjogMDAwMDQyNDINCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MDJdICAgZ2ZuOiAwMDAwNDI0MyAgbWZuOiAwMDAw
NDI0Mw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjowMl0gICBnZm46IDAwMDA0MjQ0ICBt
Zm46IDAwMDA0MjQ0DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjAyXSAgIGdmbjogMDAw
MDQyNDUgIG1mbjogMDAwMDQyNDUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MDJdICAg
Z2ZuOiAwMDAwNDI0NiAgbWZuOiAwMDAwNDI0Ng0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
MjowMl0gICBnZm46IDAwMDA0MjQ3ICBtZm46IDAwMDA0MjQ3DQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMyOjAyXSAgIGdmbjogMDAwMDQyNDggIG1mbjogMDAwMDQyNDgNCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzI6MDJdICAgZ2ZuOiAwMDAwNDI0OSAgbWZuOiAwMDAwNDI0OQ0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjowMl0gICBnZm46IDAwMDA0MjRhICBtZm46IDAw
MDA0MjRhDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjAyXSAgIGdmbjogMDAwMDQyNGIg
IG1mbjogMDAwMDQyNGINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MDJdICAgZ2ZuOiAw
MDAwNDI0YyAgbWZuOiAwMDAwNDI0Yw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjowMl0g
ICBnZm46IDAwMDA0MjRkICBtZm46IDAwMDA0MjRkDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMyOjAyXSAgIGdmbjogMDAwMDQyNGUgIG1mbjogMDAwMDQyNGUNCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzI6MDJdICAgZ2ZuOiAwMDAwNDI0ZiAgbWZuOiAwMDAwNDI0Zg0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMjowMl0gICBnZm46IDAwMDA0MjUwICBtZm46IDAwMDA0MjUw
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjAyXSAgIGdmbjogMDAwMDQyNTEgIG1mbjog
MDAwMDQyNTENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MDJdICAgZ2ZuOiAwMDAwNDI1
MiAgbWZuOiAwMDAwNDI1Mg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjowMl0gICBnZm46
IDAwMDA0MjUzICBtZm46IDAwMDA0MjUzDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjAy
XSAgIGdmbjogMDAwMDQyNTQgIG1mbjogMDAwMDQyNTQNCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzI6MDJdICAgZ2ZuOiAwMDAwNDI1NSAgbWZuOiAwMDAwNDI1NQ0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMjowMl0gICBnZm46IDAwMDA0MjU2ICBtZm46IDAwMDA0MjU2DQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMyOjAyXSAgIGdmbjogMDAwMDQyNTcgIG1mbjogMDAwMDQy
NTcNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MDJdICAgZ2ZuOiAwMDAwNDI1OCAgbWZu
OiAwMDAwNDI1OA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjowMl0gICBnZm46IDAwMDA0
MjU5ICBtZm46IDAwMDA0MjU5DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjAyXSAgIGdm
bjogMDAwMDQyNWEgIG1mbjogMDAwMDQyNWENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6
MDJdICAgZ2ZuOiAwMDAwNDI1YiAgbWZuOiAwMDAwNDI1Yg0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMjowMl0gICBnZm46IDAwMDA0MjVjICBtZm46IDAwMDA0MjVjDQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMyOjAyXSAgIGdmbjogMDAwMDQyNWQgIG1mbjogMDAwMDQyNWQNCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MDJdICAgZ2ZuOiAwMDAwNDI1ZSAgbWZuOiAwMDAw
NDI1ZQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjowMl0gICBnZm46IDAwMDA0MjVmICBt
Zm46IDAwMDA0MjVmDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjAyXSAgIGdmbjogMDAw
MDQyNjAgIG1mbjogMDAwMDQyNjANCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MDJdICAg
Z2ZuOiAwMDAwNDI2MSAgbWZuOiAwMDAwNDI2MQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
MjowMl0gICBnZm46IDAwMDA0MjYyICBtZm46IDAwMDA0MjYyDQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMyOjAyXSAgIGdmbjogMDAwMDQyNjMgIG1mbjogMDAwMDQyNjMNCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzI6MDJdICAgZ2ZuOiAwMDAwNDI2NCAgbWZuOiAwMDAwNDI2NA0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjowMl0gICBnZm46IDAwMDA0MjY1ICBtZm46IDAw
MDA0MjY1DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjAyXSAgIGdmbjogMDAwMDQyNjYg
IG1mbjogMDAwMDQyNjYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MDJdICAgZ2ZuOiAw
MDAwNDI2NyAgbWZuOiAwMDAwNDI2Nw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjowMl0g
ICBnZm46IDAwMDA0MjY4ICBtZm46IDAwMDA0MjY4DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMyOjAyXSAgIGdmbjogMDAwMDQyNjkgIG1mbjogMDAwMDQyNjkNCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzI6MDJdICAgZ2ZuOiAwMDAwNDI2YSAgbWZuOiAwMDAwNDI2YQ0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMjowMl0gICBnZm46IDAwMDA0MjZiICBtZm46IDAwMDA0MjZi
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjAyXSAgIGdmbjogMDAwMDQyNmMgIG1mbjog
MDAwMDQyNmMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MDJdICAgZ2ZuOiAwMDAwNDI2
ZCAgbWZuOiAwMDAwNDI2ZA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjowMl0gICBnZm46
IDAwMDA0MjZlICBtZm46IDAwMDA0MjZlDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjAy
XSAgIGdmbjogMDAwMDQyNmYgIG1mbjogMDAwMDQyNmYNCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzI6MDJdICAgZ2ZuOiAwMDAwNDI3MCAgbWZuOiAwMDAwNDI3MA0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMjowMl0gICBnZm46IDAwMDA0MjcxICBtZm46IDAwMDA0MjcxDQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMyOjAyXSAgIGdmbjogMDAwMDQyNzIgIG1mbjogMDAwMDQy
NzINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MDJdICAgZ2ZuOiAwMDAwNDI3MyAgbWZu
OiAwMDAwNDI3Mw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjowMl0gICBnZm46IDAwMDA0
Mjc0ICBtZm46IDAwMDA0Mjc0DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjAyXSAgIGdm
bjogMDAwMDQyNzUgIG1mbjogMDAwMDQyNzUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6
MDJdICAgZ2ZuOiAwMDAwNDI3NiAgbWZuOiAwMDAwNDI3Ng0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMjowMl0gICBnZm46IDAwMDA0Mjc3ICBtZm46IDAwMDA0Mjc3DQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMyOjAyXSAgIGdmbjogMDAwMDQyNzggIG1mbjogMDAwMDQyNzgNCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MDJdICAgZ2ZuOiAwMDAwNDI3OSAgbWZuOiAwMDAw
NDI3OQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjowM10gICBnZm46IDAwMDA0MjdhICBt
Zm46IDAwMDA0MjdhDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjAzXSAgIGdmbjogMDAw
MDQyN2IgIG1mbjogMDAwMDQyN2INCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MDNdICAg
Z2ZuOiAwMDAwNDI3YyAgbWZuOiAwMDAwNDI3Yw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
MjowM10gICBnZm46IDAwMDA0MjdkICBtZm46IDAwMDA0MjdkDQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMyOjAzXSAgIGdmbjogMDAwMDQyN2UgIG1mbjogMDAwMDQyN2UNCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzI6MDNdICAgZ2ZuOiAwMDAwNDI3ZiAgbWZuOiAwMDAwNDI3Zg0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjowM10gICBnZm46IDAwMDA0MjgwICBtZm46IDAw
MDA0MjgwDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjAzXSAgIGdmbjogMDAwMDQyODEg
IG1mbjogMDAwMDQyODENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MDNdICAgZ2ZuOiAw
MDAwNDI4MiAgbWZuOiAwMDAwNDI4Mg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjowM10g
ICBnZm46IDAwMDA0MjgzICBtZm46IDAwMDA0MjgzDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMyOjAzXSAgIGdmbjogMDAwMDQyODQgIG1mbjogMDAwMDQyODQNCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzI6MDNdICAgZ2ZuOiAwMDAwNDI4NSAgbWZuOiAwMDAwNDI4NQ0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMjowM10gICBnZm46IDAwMDA0Mjg2ICBtZm46IDAwMDA0Mjg2
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjAzXSAgIGdmbjogMDAwMDQyODcgIG1mbjog
MDAwMDQyODcNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MDNdICAgZ2ZuOiAwMDAwNDI4
OCAgbWZuOiAwMDAwNDI4OA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjowM10gICBnZm46
IDAwMDA0Mjg5ICBtZm46IDAwMDA0Mjg5DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjAz
XSAgIGdmbjogMDAwMDQyOGEgIG1mbjogMDAwMDQyOGENCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzI6MDNdICAgZ2ZuOiAwMDAwNDI4YiAgbWZuOiAwMDAwNDI4Yg0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMjowM10gICBnZm46IDAwMDA0MjhjICBtZm46IDAwMDA0MjhjDQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMyOjAzXSAgIGdmbjogMDAwMDQyOGQgIG1mbjogMDAwMDQy
OGQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MDNdICAgZ2ZuOiAwMDAwNDI4ZSAgbWZu
OiAwMDAwNDI4ZQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjowM10gICBnZm46IDAwMDA0
MjhmICBtZm46IDAwMDA0MjhmDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjAzXSAgIGdm
bjogMDAwMDQyOTAgIG1mbjogMDAwMDQyOTANCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6
MDNdICAgZ2ZuOiAwMDAwNDI5MSAgbWZuOiAwMDAwNDI5MQ0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMjowM10gICBnZm46IDAwMDA0MjkyICBtZm46IDAwMDA0MjkyDQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMyOjAzXSAgIGdmbjogMDAwMDQyOTMgIG1mbjogMDAwMDQyOTMNCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MDNdICAgZ2ZuOiAwMDAwNDI5NCAgbWZuOiAwMDAw
NDI5NA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjowM10gICBnZm46IDAwMDA0Mjk1ICBt
Zm46IDAwMDA0Mjk1DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjAzXSAgIGdmbjogMDAw
MDQyOTYgIG1mbjogMDAwMDQyOTYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MDNdICAg
Z2ZuOiAwMDAwNDI5NyAgbWZuOiAwMDAwNDI5Nw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
MjowM10gICBnZm46IDAwMDA0Mjk4ICBtZm46IDAwMDA0Mjk4DQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMyOjAzXSAgIGdmbjogMDAwMDQyOTkgIG1mbjogMDAwMDQyOTkNCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzI6MDNdICAgZ2ZuOiAwMDAwNDI5YSAgbWZuOiAwMDAwNDI5YQ0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjowM10gICBnZm46IDAwMDA0MjliICBtZm46IDAw
MDA0MjliDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjAzXSAgIGdmbjogMDAwMDQyOWMg
IG1mbjogMDAwMDQyOWMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MDNdICAgZ2ZuOiAw
MDAwNDI5ZCAgbWZuOiAwMDAwNDI5ZA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjowM10g
ICBnZm46IDAwMDA0MjllICBtZm46IDAwMDA0MjllDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMyOjAzXSAgIGdmbjogMDAwMDQyOWYgIG1mbjogMDAwMDQyOWYNCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzI6MDNdICAgZ2ZuOiAwMDAwNDJhMCAgbWZuOiAwMDAwNDJhMA0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMjowM10gICBnZm46IDAwMDA0MmExICBtZm46IDAwMDA0MmEx
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjAzXSAgIGdmbjogMDAwMDQyYTIgIG1mbjog
MDAwMDQyYTINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MDNdICAgZ2ZuOiAwMDAwNDJh
MyAgbWZuOiAwMDAwNDJhMw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjowM10gICBnZm46
IDAwMDA0MmE0ICBtZm46IDAwMDA0MmE0DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjAz
XSAgIGdmbjogMDAwMDQyYTUgIG1mbjogMDAwMDQyYTUNCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzI6MDNdICAgZ2ZuOiAwMDAwNDJhNiAgbWZuOiAwMDAwNDJhNg0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMjowM10gICBnZm46IDAwMDA0MmE3ICBtZm46IDAwMDA0MmE3DQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMyOjAzXSAgIGdmbjogMDAwMDQyYTggIG1mbjogMDAwMDQy
YTgNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MDNdICAgZ2ZuOiAwMDAwNDJhOSAgbWZu
OiAwMDAwNDJhOQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjowM10gICBnZm46IDAwMDA0
MmFhICBtZm46IDAwMDA0MmFhDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjAzXSAgIGdm
bjogMDAwMDQyYWIgIG1mbjogMDAwMDQyYWINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6
MDNdICAgZ2ZuOiAwMDAwNDJhYyAgbWZuOiAwMDAwNDJhYw0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMjowM10gICBnZm46IDAwMDA0MmFkICBtZm46IDAwMDA0MmFkDQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMyOjAzXSAgIGdmbjogMDAwMDQyYWUgIG1mbjogMDAwMDQyYWUNCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MDNdICAgZ2ZuOiAwMDAwNDJhZiAgbWZuOiAwMDAw
NDJhZg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjowM10gICBnZm46IDAwMDA0MmIwICBt
Zm46IDAwMDA0MmIwDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjAzXSAgIGdmbjogMDAw
MDQyYjEgIG1mbjogMDAwMDQyYjENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MDNdICAg
Z2ZuOiAwMDAwNDJiMiAgbWZuOiAwMDAwNDJiMg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
MjowM10gICBnZm46IDAwMDA0MmIzICBtZm46IDAwMDA0MmIzDQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMyOjAzXSAgIGdmbjogMDAwMDQyYjQgIG1mbjogMDAwMDQyYjQNCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzI6MDNdICAgZ2ZuOiAwMDAwNDJiNSAgbWZuOiAwMDAwNDJiNQ0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjowM10gICBnZm46IDAwMDA0MmI2ICBtZm46IDAw
MDA0MmI2DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjAzXSAgIGdmbjogMDAwMDQyYjcg
IG1mbjogMDAwMDQyYjcNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MDNdICAgZ2ZuOiAw
MDAwNDJiOCAgbWZuOiAwMDAwNDJiOA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjowM10g
ICBnZm46IDAwMDA0MmI5ICBtZm46IDAwMDA0MmI5DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMyOjA0XSAgIGdmbjogMDAwMDQyYmEgIG1mbjogMDAwMDQyYmENCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzI6MDRdICAgZ2ZuOiAwMDAwNDJiYiAgbWZuOiAwMDAwNDJiYg0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMjowNF0gICBnZm46IDAwMDA0MmJjICBtZm46IDAwMDA0MmJj
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjA0XSAgIGdmbjogMDAwMDQyYmQgIG1mbjog
MDAwMDQyYmQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MDRdICAgZ2ZuOiAwMDAwNDJi
ZSAgbWZuOiAwMDAwNDJiZQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjowNF0gICBnZm46
IDAwMDA0MmJmICBtZm46IDAwMDA0MmJmDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjA0
XSAgIGdmbjogMDAwMDQyYzAgIG1mbjogMDAwMDQyYzANCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzI6MDRdICAgZ2ZuOiAwMDAwNDJjMSAgbWZuOiAwMDAwNDJjMQ0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMjowNF0gICBnZm46IDAwMDA0MmMyICBtZm46IDAwMDA0MmMyDQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMyOjA0XSAgIGdmbjogMDAwMDQyYzMgIG1mbjogMDAwMDQy
YzMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MDRdICAgZ2ZuOiAwMDAwNDJjNCAgbWZu
OiAwMDAwNDJjNA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjowNF0gICBnZm46IDAwMDA0
MmM1ICBtZm46IDAwMDA0MmM1DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjA0XSAgIGdm
bjogMDAwMDQyYzYgIG1mbjogMDAwMDQyYzYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6
MDRdICAgZ2ZuOiAwMDAwNDJjNyAgbWZuOiAwMDAwNDJjNw0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMjowNF0gICBnZm46IDAwMDA0MmM4ICBtZm46IDAwMDA0MmM4DQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMyOjA0XSAgIGdmbjogMDAwMDQyYzkgIG1mbjogMDAwMDQyYzkNCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MDRdICAgZ2ZuOiAwMDAwNDJjYSAgbWZuOiAwMDAw
NDJjYQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjowNF0gICBnZm46IDAwMDA0MmNiICBt
Zm46IDAwMDA0MmNiDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjA0XSAgIGdmbjogMDAw
MDQyY2MgIG1mbjogMDAwMDQyY2MNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MDRdICAg
Z2ZuOiAwMDAwNDJjZCAgbWZuOiAwMDAwNDJjZA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
MjowNF0gICBnZm46IDAwMDA0MmNlICBtZm46IDAwMDA0MmNlDQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMyOjA0XSAgIGdmbjogMDAwMDQyY2YgIG1mbjogMDAwMDQyY2YNCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzI6MDRdICAgZ2ZuOiAwMDAwNDJkMCAgbWZuOiAwMDAwNDJkMA0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjowNF0gICBnZm46IDAwMDA0MmQxICBtZm46IDAw
MDA0MmQxDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjA0XSAgIGdmbjogMDAwMDQyZDIg
IG1mbjogMDAwMDQyZDINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MDRdICAgZ2ZuOiAw
MDAwNDJkMyAgbWZuOiAwMDAwNDJkMw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjowNF0g
ICBnZm46IDAwMDA0MmQ0ICBtZm46IDAwMDA0MmQ0DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMyOjA0XSAgIGdmbjogMDAwMDQyZDUgIG1mbjogMDAwMDQyZDUNCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzI6MDRdICAgZ2ZuOiAwMDAwNDJkNiAgbWZuOiAwMDAwNDJkNg0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMjowNF0gICBnZm46IDAwMDA0MmQ3ICBtZm46IDAwMDA0MmQ3
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjA0XSAgIGdmbjogMDAwMDQyZDggIG1mbjog
MDAwMDQyZDgNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MDRdICAgZ2ZuOiAwMDAwNDJk
OSAgbWZuOiAwMDAwNDJkOQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjowNF0gICBnZm46
IDAwMDA0MmRhICBtZm46IDAwMDA0MmRhDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjA0
XSAgIGdmbjogMDAwMDQyZGIgIG1mbjogMDAwMDQyZGINCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzI6MDRdICAgZ2ZuOiAwMDAwNDJkYyAgbWZuOiAwMDAwNDJkYw0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMjowNF0gICBnZm46IDAwMDA0MmRkICBtZm46IDAwMDA0MmRkDQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMyOjA0XSAgIGdmbjogMDAwMDQyZGUgIG1mbjogMDAwMDQy
ZGUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MDRdICAgZ2ZuOiAwMDAwNDJkZiAgbWZu
OiAwMDAwNDJkZg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjowNF0gICBnZm46IDAwMDA0
MmUwICBtZm46IDAwMDA0MmUwDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjA0XSAgIGdm
bjogMDAwMDQyZTEgIG1mbjogMDAwMDQyZTENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6
MDRdICAgZ2ZuOiAwMDAwNDJlMiAgbWZuOiAwMDAwNDJlMg0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMjowNF0gICBnZm46IDAwMDA0MmUzICBtZm46IDAwMDA0MmUzDQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMyOjA0XSAgIGdmbjogMDAwMDQyZTQgIG1mbjogMDAwMDQyZTQNCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MDRdICAgZ2ZuOiAwMDAwNDJlNSAgbWZuOiAwMDAw
NDJlNQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjowNF0gICBnZm46IDAwMDA0MmU2ICBt
Zm46IDAwMDA0MmU2DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjA0XSAgIGdmbjogMDAw
MDQyZTcgIG1mbjogMDAwMDQyZTcNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MDRdICAg
Z2ZuOiAwMDAwNDJlOCAgbWZuOiAwMDAwNDJlOA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
MjowNF0gICBnZm46IDAwMDA0MmU5ICBtZm46IDAwMDA0MmU5DQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMyOjA0XSAgIGdmbjogMDAwMDQyZWEgIG1mbjogMDAwMDQyZWENCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzI6MDRdICAgZ2ZuOiAwMDAwNDJlYiAgbWZuOiAwMDAwNDJlYg0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjowNF0gICBnZm46IDAwMDA0MmVjICBtZm46IDAw
MDA0MmVjDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjA0XSAgIGdmbjogMDAwMDQyZWQg
IG1mbjogMDAwMDQyZWQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MDRdICAgZ2ZuOiAw
MDAwNDJlZSAgbWZuOiAwMDAwNDJlZQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjowNF0g
ICBnZm46IDAwMDA0MmVmICBtZm46IDAwMDA0MmVmDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMyOjA0XSAgIGdmbjogMDAwMDQyZjAgIG1mbjogMDAwMDQyZjANCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzI6MDRdICAgZ2ZuOiAwMDAwNDJmMSAgbWZuOiAwMDAwNDJmMQ0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMjowNF0gICBnZm46IDAwMDA0MmYyICBtZm46IDAwMDA0MmYy
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjA0XSAgIGdmbjogMDAwMDQyZjMgIG1mbjog
MDAwMDQyZjMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MDRdICAgZ2ZuOiAwMDAwNDJm
NCAgbWZuOiAwMDAwNDJmNA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjowNF0gICBnZm46
IDAwMDA0MmY1ICBtZm46IDAwMDA0MmY1DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjA0
XSAgIGdmbjogMDAwMDQyZjYgIG1mbjogMDAwMDQyZjYNCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzI6MDRdICAgZ2ZuOiAwMDAwNDJmNyAgbWZuOiAwMDAwNDJmNw0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMjowNF0gICBnZm46IDAwMDA0MmY4ICBtZm46IDAwMDA0MmY4DQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMyOjA0XSAgIGdmbjogMDAwMDQyZjkgIG1mbjogMDAwMDQy
ZjkNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MDRdICAgZ2ZuOiAwMDAwNDJmYSAgbWZu
OiAwMDAwNDJmYQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjowNV0gICBnZm46IDAwMDA0
MmZiICBtZm46IDAwMDA0MmZiDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjA1XSAgIGdm
bjogMDAwMDQyZmMgIG1mbjogMDAwMDQyZmMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6
MDVdICAgZ2ZuOiAwMDAwNDJmZCAgbWZuOiAwMDAwNDJmZA0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMjowNV0gICBnZm46IDAwMDA0MmZlICBtZm46IDAwMDA0MmZlDQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMyOjA1XSAgIGdmbjogMDAwMDQyZmYgIG1mbjogMDAwMDQyZmYNCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MDVdICAgZ2ZuOiAwMDAwNDMwMCAgbWZuOiAwMDAw
NDMwMA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjowNV0gICBnZm46IDAwMDA0MzAxICBt
Zm46IDAwMDA0MzAxDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjA1XSAgIGdmbjogMDAw
MDQzMDIgIG1mbjogMDAwMDQzMDINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MDVdICAg
Z2ZuOiAwMDAwNDMwMyAgbWZuOiAwMDAwNDMwMw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
MjowNV0gICBnZm46IDAwMDA0MzA0ICBtZm46IDAwMDA0MzA0DQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMyOjA1XSAgIGdmbjogMDAwMDQzMDUgIG1mbjogMDAwMDQzMDUNCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzI6MDVdICAgZ2ZuOiAwMDAwNDMwNiAgbWZuOiAwMDAwNDMwNg0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjowNV0gICBnZm46IDAwMDA0MzA3ICBtZm46IDAw
MDA0MzA3DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjA1XSAgIGdmbjogMDAwMDQzMDgg
IG1mbjogMDAwMDQzMDgNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MDVdICAgZ2ZuOiAw
MDAwNDMwOSAgbWZuOiAwMDAwNDMwOQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjowNV0g
ICBnZm46IDAwMDA0MzBhICBtZm46IDAwMDA0MzBhDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMyOjA1XSAgIGdmbjogMDAwMDQzMGIgIG1mbjogMDAwMDQzMGINCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzI6MDVdICAgZ2ZuOiAwMDAwNDMwYyAgbWZuOiAwMDAwNDMwYw0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMjowNV0gICBnZm46IDAwMDA0MzBkICBtZm46IDAwMDA0MzBk
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjA1XSAgIGdmbjogMDAwMDQzMGUgIG1mbjog
MDAwMDQzMGUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MDVdICAgZ2ZuOiAwMDAwNDMw
ZiAgbWZuOiAwMDAwNDMwZg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjowNV0gICBnZm46
IDAwMDA0MzEwICBtZm46IDAwMDA0MzEwDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjA1
XSAgIGdmbjogMDAwMDQzMTEgIG1mbjogMDAwMDQzMTENCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzI6MDVdICAgZ2ZuOiAwMDAwNDMxMiAgbWZuOiAwMDAwNDMxMg0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMjowNV0gICBnZm46IDAwMDA0MzEzICBtZm46IDAwMDA0MzEzDQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMyOjA1XSAgIGdmbjogMDAwMDQzMTQgIG1mbjogMDAwMDQz
MTQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MDVdICAgZ2ZuOiAwMDAwNDMxNSAgbWZu
OiAwMDAwNDMxNQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjowNV0gICBnZm46IDAwMDA0
MzE2ICBtZm46IDAwMDA0MzE2DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjA1XSAgIGdm
bjogMDAwMDQzMTcgIG1mbjogMDAwMDQzMTcNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6
MDVdICAgZ2ZuOiAwMDAwNDMxOCAgbWZuOiAwMDAwNDMxOA0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMjowNV0gICBnZm46IDAwMDA0MzE5ICBtZm46IDAwMDA0MzE5DQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMyOjA1XSAgIGdmbjogMDAwMDQzMWEgIG1mbjogMDAwMDQzMWENCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MDVdICAgZ2ZuOiAwMDAwNDMxYiAgbWZuOiAwMDAw
NDMxYg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjowNV0gICBnZm46IDAwMDA0MzFjICBt
Zm46IDAwMDA0MzFjDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjA1XSAgIGdmbjogMDAw
MDQzMWQgIG1mbjogMDAwMDQzMWQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MDVdICAg
Z2ZuOiAwMDAwNDMxZSAgbWZuOiAwMDAwNDMxZQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
MjowNV0gICBnZm46IDAwMDA0MzFmICBtZm46IDAwMDA0MzFmDQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMyOjA1XSAgIGdmbjogMDAwMDQzMjAgIG1mbjogMDAwMDQzMjANCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzI6MDVdICAgZ2ZuOiAwMDAwNDMyMSAgbWZuOiAwMDAwNDMyMQ0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjowNV0gICBnZm46IDAwMDA0MzIyICBtZm46IDAw
MDA0MzIyDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjA1XSAgIGdmbjogMDAwMDQzMjMg
IG1mbjogMDAwMDQzMjMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MDVdICAgZ2ZuOiAw
MDAwNDMyNCAgbWZuOiAwMDAwNDMyNA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjowNV0g
ICBnZm46IDAwMDA0MzI1ICBtZm46IDAwMDA0MzI1DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMyOjA1XSAgIGdmbjogMDAwMDQzMjYgIG1mbjogMDAwMDQzMjYNCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzI6MDVdICAgZ2ZuOiAwMDAwNDMyNyAgbWZuOiAwMDAwNDMyNw0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMjowNV0gICBnZm46IDAwMDA0MzI4ICBtZm46IDAwMDA0MzI4
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjA1XSAgIGdmbjogMDAwMDQzMjkgIG1mbjog
MDAwMDQzMjkNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MDVdICAgZ2ZuOiAwMDAwNDMy
YSAgbWZuOiAwMDAwNDMyYQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjowNV0gICBnZm46
IDAwMDA0MzJiICBtZm46IDAwMDA0MzJiDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjA1
XSAgIGdmbjogMDAwMDQzMmMgIG1mbjogMDAwMDQzMmMNCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzI6MDVdICAgZ2ZuOiAwMDAwNDMyZCAgbWZuOiAwMDAwNDMyZA0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMjowNV0gICBnZm46IDAwMDA0MzJlICBtZm46IDAwMDA0MzJlDQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMyOjA1XSAgIGdmbjogMDAwMDQzMmYgIG1mbjogMDAwMDQz
MmYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MDVdICAgZ2ZuOiAwMDAwNDMzMCAgbWZu
OiAwMDAwNDMzMA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjowNV0gICBnZm46IDAwMDA0
MzMxICBtZm46IDAwMDA0MzMxDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjA1XSAgIGdm
bjogMDAwMDQzMzIgIG1mbjogMDAwMDQzMzINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6
MDVdICAgZ2ZuOiAwMDAwNDMzMyAgbWZuOiAwMDAwNDMzMw0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMjowNV0gICBnZm46IDAwMDA0MzM0ICBtZm46IDAwMDA0MzM0DQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMyOjA1XSAgIGdmbjogMDAwMDQzMzUgIG1mbjogMDAwMDQzMzUNCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MDVdICAgZ2ZuOiAwMDAwNDMzNiAgbWZuOiAwMDAw
NDMzNg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjowNV0gICBnZm46IDAwMDA0MzM3ICBt
Zm46IDAwMDA0MzM3DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjA1XSAgIGdmbjogMDAw
MDQzMzggIG1mbjogMDAwMDQzMzgNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MDVdICAg
Z2ZuOiAwMDAwNDMzOSAgbWZuOiAwMDAwNDMzOQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
MjowNV0gICBnZm46IDAwMDA0MzNhICBtZm46IDAwMDA0MzNhDQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMyOjA2XSAgIGdmbjogMDAwMDQzM2IgIG1mbjogMDAwMDQzM2INCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzI6MDZdICAgZ2ZuOiAwMDAwNDMzYyAgbWZuOiAwMDAwNDMzYw0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjowNl0gICBnZm46IDAwMDA0MzNkICBtZm46IDAw
MDA0MzNkDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjA2XSAgIGdmbjogMDAwMDQzM2Ug
IG1mbjogMDAwMDQzM2UNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MDZdICAgZ2ZuOiAw
MDAwNDMzZiAgbWZuOiAwMDAwNDMzZg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjowNl0g
ICBnZm46IDAwMDA0MzQwICBtZm46IDAwMDA0MzQwDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMyOjA2XSAgIGdmbjogMDAwMDQzNDEgIG1mbjogMDAwMDQzNDENCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzI6MDZdICAgZ2ZuOiAwMDAwNDM0MiAgbWZuOiAwMDAwNDM0Mg0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMjowNl0gICBnZm46IDAwMDA0MzQzICBtZm46IDAwMDA0MzQz
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjA2XSAgIGdmbjogMDAwMDQzNDQgIG1mbjog
MDAwMDQzNDQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MDZdICAgZ2ZuOiAwMDAwNDM0
NSAgbWZuOiAwMDAwNDM0NQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjowNl0gICBnZm46
IDAwMDA0MzQ2ICBtZm46IDAwMDA0MzQ2DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjA2
XSAgIGdmbjogMDAwMDQzNDcgIG1mbjogMDAwMDQzNDcNCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzI6MDZdICAgZ2ZuOiAwMDAwNDM0OCAgbWZuOiAwMDAwNDM0OA0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMjowNl0gICBnZm46IDAwMDA0MzQ5ICBtZm46IDAwMDA0MzQ5DQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMyOjA2XSAgIGdmbjogMDAwMDQzNGEgIG1mbjogMDAwMDQz
NGENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MDZdICAgZ2ZuOiAwMDAwNDM0YiAgbWZu
OiAwMDAwNDM0Yg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjowNl0gICBnZm46IDAwMDA0
MzRjICBtZm46IDAwMDA0MzRjDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjA2XSAgIGdm
bjogMDAwMDQzNGQgIG1mbjogMDAwMDQzNGQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6
MDZdICAgZ2ZuOiAwMDAwNDM0ZSAgbWZuOiAwMDAwNDM0ZQ0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMjowNl0gICBnZm46IDAwMDA0MzRmICBtZm46IDAwMDA0MzRmDQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMyOjA2XSAgIGdmbjogMDAwMDQzNTAgIG1mbjogMDAwMDQzNTANCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MDZdICAgZ2ZuOiAwMDAwNDM1MSAgbWZuOiAwMDAw
NDM1MQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjowNl0gICBnZm46IDAwMDA0MzUyICBt
Zm46IDAwMDA0MzUyDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjA2XSAgIGdmbjogMDAw
MDQzNTMgIG1mbjogMDAwMDQzNTMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MDZdICAg
Z2ZuOiAwMDAwNDM1NCAgbWZuOiAwMDAwNDM1NA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
MjowNl0gICBnZm46IDAwMDA0MzU1ICBtZm46IDAwMDA0MzU1DQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMyOjA2XSAgIGdmbjogMDAwMDQzNTYgIG1mbjogMDAwMDQzNTYNCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzI6MDZdICAgZ2ZuOiAwMDAwNDM1NyAgbWZuOiAwMDAwNDM1Nw0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjowNl0gICBnZm46IDAwMDA0MzU4ICBtZm46IDAw
MDA0MzU4DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjA2XSAgIGdmbjogMDAwMDQzNTkg
IG1mbjogMDAwMDQzNTkNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MDZdICAgZ2ZuOiAw
MDAwNDM1YSAgbWZuOiAwMDAwNDM1YQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjowNl0g
ICBnZm46IDAwMDA0MzViICBtZm46IDAwMDA0MzViDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMyOjA2XSAgIGdmbjogMDAwMDQzNWMgIG1mbjogMDAwMDQzNWMNCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzI6MDZdICAgZ2ZuOiAwMDAwNDM1ZCAgbWZuOiAwMDAwNDM1ZA0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMjowNl0gICBnZm46IDAwMDA0MzVlICBtZm46IDAwMDA0MzVl
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjA2XSAgIGdmbjogMDAwMDQzNWYgIG1mbjog
MDAwMDQzNWYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MDZdICAgZ2ZuOiAwMDAwNDM2
MCAgbWZuOiAwMDAwNDM2MA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjowNl0gICBnZm46
IDAwMDA0MzYxICBtZm46IDAwMDA0MzYxDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjA2
XSAgIGdmbjogMDAwMDQzNjIgIG1mbjogMDAwMDQzNjINCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzI6MDZdICAgZ2ZuOiAwMDAwNDM2MyAgbWZuOiAwMDAwNDM2Mw0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMjowNl0gICBnZm46IDAwMDA0MzY0ICBtZm46IDAwMDA0MzY0DQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMyOjA2XSAgIGdmbjogMDAwMDQzNjUgIG1mbjogMDAwMDQz
NjUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MDZdICAgZ2ZuOiAwMDAwNDM2NiAgbWZu
OiAwMDAwNDM2Ng0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjowNl0gICBnZm46IDAwMDA0
MzY3ICBtZm46IDAwMDA0MzY3DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjA2XSAgIGdm
bjogMDAwMDQzNjggIG1mbjogMDAwMDQzNjgNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6
MDZdICAgZ2ZuOiAwMDAwNDM2OSAgbWZuOiAwMDAwNDM2OQ0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMjowNl0gICBnZm46IDAwMDA0MzZhICBtZm46IDAwMDA0MzZhDQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMyOjA2XSAgIGdmbjogMDAwMDQzNmIgIG1mbjogMDAwMDQzNmINCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MDZdICAgZ2ZuOiAwMDAwNDM2YyAgbWZuOiAwMDAw
NDM2Yw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjowNl0gICBnZm46IDAwMDA0MzZkICBt
Zm46IDAwMDA0MzZkDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjA2XSAgIGdmbjogMDAw
MDQzNmUgIG1mbjogMDAwMDQzNmUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MDZdICAg
Z2ZuOiAwMDAwNDM2ZiAgbWZuOiAwMDAwNDM2Zg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
MjowNl0gICBnZm46IDAwMDA0MzcwICBtZm46IDAwMDA0MzcwDQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMyOjA2XSAgIGdmbjogMDAwMDQzNzEgIG1mbjogMDAwMDQzNzENCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzI6MDZdICAgZ2ZuOiAwMDAwNDM3MiAgbWZuOiAwMDAwNDM3Mg0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjowNl0gICBnZm46IDAwMDA0MzczICBtZm46IDAw
MDA0MzczDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjA2XSAgIGdmbjogMDAwMDQzNzQg
IG1mbjogMDAwMDQzNzQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MDZdICAgZ2ZuOiAw
MDAwNDM3NSAgbWZuOiAwMDAwNDM3NQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjowNl0g
ICBnZm46IDAwMDA0Mzc2ICBtZm46IDAwMDA0Mzc2DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMyOjA2XSAgIGdmbjogMDAwMDQzNzcgIG1mbjogMDAwMDQzNzcNCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzI6MDZdICAgZ2ZuOiAwMDAwNDM3OCAgbWZuOiAwMDAwNDM3OA0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMjowNl0gICBnZm46IDAwMDA0Mzc5ICBtZm46IDAwMDA0Mzc5
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjA2XSAgIGdmbjogMDAwMDQzN2EgIG1mbjog
MDAwMDQzN2ENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MDddICAgZ2ZuOiAwMDAwNDM3
YiAgbWZuOiAwMDAwNDM3Yg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjowN10gICBnZm46
IDAwMDA0MzdjICBtZm46IDAwMDA0MzdjDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjA3
XSAgIGdmbjogMDAwMDQzN2QgIG1mbjogMDAwMDQzN2QNCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzI6MDddICAgZ2ZuOiAwMDAwNDM3ZSAgbWZuOiAwMDAwNDM3ZQ0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMjowN10gICBnZm46IDAwMDA0MzdmICBtZm46IDAwMDA0MzdmDQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMyOjA3XSAgIGdmbjogMDAwMDQzODAgIG1mbjogMDAwMDQz
ODANCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MDddICAgZ2ZuOiAwMDAwNDM4MSAgbWZu
OiAwMDAwNDM4MQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjowN10gICBnZm46IDAwMDA0
MzgyICBtZm46IDAwMDA0MzgyDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjA3XSAgIGdm
bjogMDAwMDQzODMgIG1mbjogMDAwMDQzODMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6
MDddICAgZ2ZuOiAwMDAwNDM4NCAgbWZuOiAwMDAwNDM4NA0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMjowN10gICBnZm46IDAwMDA0Mzg1ICBtZm46IDAwMDA0Mzg1DQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMyOjA3XSAgIGdmbjogMDAwMDQzODYgIG1mbjogMDAwMDQzODYNCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MDddICAgZ2ZuOiAwMDAwNDM4NyAgbWZuOiAwMDAw
NDM4Nw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjowN10gICBnZm46IDAwMDA0Mzg4ICBt
Zm46IDAwMDA0Mzg4DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjA3XSAgIGdmbjogMDAw
MDQzODkgIG1mbjogMDAwMDQzODkNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MDddICAg
Z2ZuOiAwMDAwNDM4YSAgbWZuOiAwMDAwNDM4YQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
MjowN10gICBnZm46IDAwMDA0MzhiICBtZm46IDAwMDA0MzhiDQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMyOjA3XSAgIGdmbjogMDAwMDQzOGMgIG1mbjogMDAwMDQzOGMNCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzI6MDddICAgZ2ZuOiAwMDAwNDM4ZCAgbWZuOiAwMDAwNDM4ZA0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjowN10gICBnZm46IDAwMDA0MzhlICBtZm46IDAw
MDA0MzhlDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjA3XSAgIGdmbjogMDAwMDQzOGYg
IG1mbjogMDAwMDQzOGYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MDddICAgZ2ZuOiAw
MDAwNDM5MCAgbWZuOiAwMDAwNDM5MA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjowN10g
ICBnZm46IDAwMDA0MzkxICBtZm46IDAwMDA0MzkxDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMyOjA3XSAgIGdmbjogMDAwMDQzOTIgIG1mbjogMDAwMDQzOTINCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzI6MDddICAgZ2ZuOiAwMDAwNDM5MyAgbWZuOiAwMDAwNDM5Mw0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMjowN10gICBnZm46IDAwMDA0Mzk0ICBtZm46IDAwMDA0Mzk0
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjA3XSAgIGdmbjogMDAwMDQzOTUgIG1mbjog
MDAwMDQzOTUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MDddICAgZ2ZuOiAwMDAwNDM5
NiAgbWZuOiAwMDAwNDM5Ng0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjowN10gICBnZm46
IDAwMDA0Mzk3ICBtZm46IDAwMDA0Mzk3DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjA3
XSAgIGdmbjogMDAwMDQzOTggIG1mbjogMDAwMDQzOTgNCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzI6MDddICAgZ2ZuOiAwMDAwNDM5OSAgbWZuOiAwMDAwNDM5OQ0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMjowN10gICBnZm46IDAwMDA0MzlhICBtZm46IDAwMDA0MzlhDQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMyOjA3XSAgIGdmbjogMDAwMDQzOWIgIG1mbjogMDAwMDQz
OWINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MDddICAgZ2ZuOiAwMDAwNDM5YyAgbWZu
OiAwMDAwNDM5Yw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjowN10gICBnZm46IDAwMDA0
MzlkICBtZm46IDAwMDA0MzlkDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjA3XSAgIGdm
bjogMDAwMDQzOWUgIG1mbjogMDAwMDQzOWUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6
MDddICAgZ2ZuOiAwMDAwNDM5ZiAgbWZuOiAwMDAwNDM5Zg0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMjowN10gICBnZm46IDAwMDA0M2EwICBtZm46IDAwMDA0M2EwDQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMyOjA3XSAgIGdmbjogMDAwMDQzYTEgIG1mbjogMDAwMDQzYTENCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MDddICAgZ2ZuOiAwMDAwNDNhMiAgbWZuOiAwMDAw
NDNhMg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjowN10gICBnZm46IDAwMDA0M2EzICBt
Zm46IDAwMDA0M2EzDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjA3XSAgIGdmbjogMDAw
MDQzYTQgIG1mbjogMDAwMDQzYTQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MDddICAg
Z2ZuOiAwMDAwNDNhNSAgbWZuOiAwMDAwNDNhNQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
MjowN10gICBnZm46IDAwMDA0M2E2ICBtZm46IDAwMDA0M2E2DQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMyOjA3XSAgIGdmbjogMDAwMDQzYTcgIG1mbjogMDAwMDQzYTcNCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzI6MDddICAgZ2ZuOiAwMDAwNDNhOCAgbWZuOiAwMDAwNDNhOA0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjowN10gICBnZm46IDAwMDA0M2E5ICBtZm46IDAw
MDA0M2E5DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjA3XSAgIGdmbjogMDAwMDQzYWEg
IG1mbjogMDAwMDQzYWENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MDddICAgZ2ZuOiAw
MDAwNDNhYiAgbWZuOiAwMDAwNDNhYg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjowN10g
ICBnZm46IDAwMDA0M2FjICBtZm46IDAwMDA0M2FjDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMyOjA3XSAgIGdmbjogMDAwMDQzYWQgIG1mbjogMDAwMDQzYWQNCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzI6MDddICAgZ2ZuOiAwMDAwNDNhZSAgbWZuOiAwMDAwNDNhZQ0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMjowN10gICBnZm46IDAwMDA0M2FmICBtZm46IDAwMDA0M2Fm
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjA3XSAgIGdmbjogMDAwMDQzYjAgIG1mbjog
MDAwMDQzYjANCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MDddICAgZ2ZuOiAwMDAwNDNi
MSAgbWZuOiAwMDAwNDNiMQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjowN10gICBnZm46
IDAwMDA0M2IyICBtZm46IDAwMDA0M2IyDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjA3
XSAgIGdmbjogMDAwMDQzYjMgIG1mbjogMDAwMDQzYjMNCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzI6MDddICAgZ2ZuOiAwMDAwNDNiNCAgbWZuOiAwMDAwNDNiNA0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMjowN10gICBnZm46IDAwMDA0M2I1ICBtZm46IDAwMDA0M2I1DQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMyOjA3XSAgIGdmbjogMDAwMDQzYjYgIG1mbjogMDAwMDQz
YjYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MDddICAgZ2ZuOiAwMDAwNDNiNyAgbWZu
OiAwMDAwNDNiNw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjowN10gICBnZm46IDAwMDA0
M2I4ICBtZm46IDAwMDA0M2I4DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjA3XSAgIGdm
bjogMDAwMDQzYjkgIG1mbjogMDAwMDQzYjkNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6
MDddICAgZ2ZuOiAwMDAwNDNiYSAgbWZuOiAwMDAwNDNiYQ0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMjowOF0gICBnZm46IDAwMDA0M2JiICBtZm46IDAwMDA0M2JiDQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMyOjA4XSAgIGdmbjogMDAwMDQzYmMgIG1mbjogMDAwMDQzYmMNCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MDhdICAgZ2ZuOiAwMDAwNDNiZCAgbWZuOiAwMDAw
NDNiZA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjowOF0gICBnZm46IDAwMDA0M2JlICBt
Zm46IDAwMDA0M2JlDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjA4XSAgIGdmbjogMDAw
MDQzYmYgIG1mbjogMDAwMDQzYmYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MDhdICAg
Z2ZuOiAwMDAwNDNjMCAgbWZuOiAwMDAwNDNjMA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
MjowOF0gICBnZm46IDAwMDA0M2MxICBtZm46IDAwMDA0M2MxDQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMyOjA4XSAgIGdmbjogMDAwMDQzYzIgIG1mbjogMDAwMDQzYzINCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzI6MDhdICAgZ2ZuOiAwMDAwNDNjMyAgbWZuOiAwMDAwNDNjMw0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjowOF0gICBnZm46IDAwMDA0M2M0ICBtZm46IDAw
MDA0M2M0DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjA4XSAgIGdmbjogMDAwMDQzYzUg
IG1mbjogMDAwMDQzYzUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MDhdICAgZ2ZuOiAw
MDAwNDNjNiAgbWZuOiAwMDAwNDNjNg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjowOF0g
ICBnZm46IDAwMDA0M2M3ICBtZm46IDAwMDA0M2M3DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMyOjA4XSAgIGdmbjogMDAwMDQzYzggIG1mbjogMDAwMDQzYzgNCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzI6MDhdICAgZ2ZuOiAwMDAwNDNjOSAgbWZuOiAwMDAwNDNjOQ0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMjowOF0gICBnZm46IDAwMDA0M2NhICBtZm46IDAwMDA0M2Nh
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjA4XSAgIGdmbjogMDAwMDQzY2IgIG1mbjog
MDAwMDQzY2INCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MDhdICAgZ2ZuOiAwMDAwNDNj
YyAgbWZuOiAwMDAwNDNjYw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjowOF0gICBnZm46
IDAwMDA0M2NkICBtZm46IDAwMDA0M2NkDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjA4
XSAgIGdmbjogMDAwMDQzY2UgIG1mbjogMDAwMDQzY2UNCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzI6MDhdICAgZ2ZuOiAwMDAwNDNjZiAgbWZuOiAwMDAwNDNjZg0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMjowOF0gICBnZm46IDAwMDA0M2QwICBtZm46IDAwMDA0M2QwDQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMyOjA4XSAgIGdmbjogMDAwMDQzZDEgIG1mbjogMDAwMDQz
ZDENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MDhdICAgZ2ZuOiAwMDAwNDNkMiAgbWZu
OiAwMDAwNDNkMg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjowOF0gICBnZm46IDAwMDA0
M2QzICBtZm46IDAwMDA0M2QzDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjA4XSAgIGdm
bjogMDAwMDQzZDQgIG1mbjogMDAwMDQzZDQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6
MDhdICAgZ2ZuOiAwMDAwNDNkNSAgbWZuOiAwMDAwNDNkNQ0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMjowOF0gICBnZm46IDAwMDA0M2Q2ICBtZm46IDAwMDA0M2Q2DQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMyOjA4XSAgIGdmbjogMDAwMDQzZDcgIG1mbjogMDAwMDQzZDcNCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MDhdICAgZ2ZuOiAwMDAwNDNkOCAgbWZuOiAwMDAw
NDNkOA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjowOF0gICBnZm46IDAwMDA0M2Q5ICBt
Zm46IDAwMDA0M2Q5DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjA4XSAgIGdmbjogMDAw
MDQzZGEgIG1mbjogMDAwMDQzZGENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MDhdICAg
Z2ZuOiAwMDAwNDNkYiAgbWZuOiAwMDAwNDNkYg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
MjowOF0gICBnZm46IDAwMDA0M2RjICBtZm46IDAwMDA0M2RjDQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMyOjA4XSAgIGdmbjogMDAwMDQzZGQgIG1mbjogMDAwMDQzZGQNCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzI6MDhdICAgZ2ZuOiAwMDAwNDNkZSAgbWZuOiAwMDAwNDNkZQ0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjowOF0gICBnZm46IDAwMDA0M2RmICBtZm46IDAw
MDA0M2RmDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjA4XSAgIGdmbjogMDAwMDQzZTAg
IG1mbjogMDAwMDQzZTANCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MDhdICAgZ2ZuOiAw
MDAwNDNlMSAgbWZuOiAwMDAwNDNlMQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjowOF0g
ICBnZm46IDAwMDA0M2UyICBtZm46IDAwMDA0M2UyDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMyOjA4XSAgIGdmbjogMDAwMDQzZTMgIG1mbjogMDAwMDQzZTMNCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzI6MDhdICAgZ2ZuOiAwMDAwNDNlNCAgbWZuOiAwMDAwNDNlNA0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMjowOF0gICBnZm46IDAwMDA0M2U1ICBtZm46IDAwMDA0M2U1
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjA4XSAgIGdmbjogMDAwMDQzZTYgIG1mbjog
MDAwMDQzZTYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MDhdICAgZ2ZuOiAwMDAwNDNl
NyAgbWZuOiAwMDAwNDNlNw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjowOF0gICBnZm46
IDAwMDA0M2U4ICBtZm46IDAwMDA0M2U4DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjA4
XSAgIGdmbjogMDAwMDQzZTkgIG1mbjogMDAwMDQzZTkNCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzI6MDhdICAgZ2ZuOiAwMDAwNDNlYSAgbWZuOiAwMDAwNDNlYQ0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMjowOF0gICBnZm46IDAwMDA0M2ViICBtZm46IDAwMDA0M2ViDQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMyOjA4XSAgIGdmbjogMDAwMDQzZWMgIG1mbjogMDAwMDQz
ZWMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MDhdICAgZ2ZuOiAwMDAwNDNlZCAgbWZu
OiAwMDAwNDNlZA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjowOF0gICBnZm46IDAwMDA0
M2VlICBtZm46IDAwMDA0M2VlDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjA4XSAgIGdm
bjogMDAwMDQzZWYgIG1mbjogMDAwMDQzZWYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6
MDhdICAgZ2ZuOiAwMDAwNDNmMCAgbWZuOiAwMDAwNDNmMA0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMjowOF0gICBnZm46IDAwMDA0M2YxICBtZm46IDAwMDA0M2YxDQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMyOjA4XSAgIGdmbjogMDAwMDQzZjIgIG1mbjogMDAwMDQzZjINCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MDhdICAgZ2ZuOiAwMDAwNDNmMyAgbWZuOiAwMDAw
NDNmMw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjowOF0gICBnZm46IDAwMDA0M2Y0ICBt
Zm46IDAwMDA0M2Y0DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjA4XSAgIGdmbjogMDAw
MDQzZjUgIG1mbjogMDAwMDQzZjUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MDhdICAg
Z2ZuOiAwMDAwNDNmNiAgbWZuOiAwMDAwNDNmNg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
MjowOF0gICBnZm46IDAwMDA0M2Y3ICBtZm46IDAwMDA0M2Y3DQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMyOjA4XSAgIGdmbjogMDAwMDQzZjggIG1mbjogMDAwMDQzZjgNCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzI6MDhdICAgZ2ZuOiAwMDAwNDNmOSAgbWZuOiAwMDAwNDNmOQ0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjowOF0gICBnZm46IDAwMDA0M2ZhICBtZm46IDAw
MDA0M2ZhDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjA5XSAgIGdmbjogMDAwMDQzZmIg
IG1mbjogMDAwMDQzZmINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MDldICAgZ2ZuOiAw
MDAwNDNmYyAgbWZuOiAwMDAwNDNmYw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjowOV0g
ICBnZm46IDAwMDA0M2ZkICBtZm46IDAwMDA0M2ZkDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMyOjA5XSAgIGdmbjogMDAwMDQzZmUgIG1mbjogMDAwMDQzZmUNCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzI6MDldICAgZ2ZuOiAwMDAwNDNmZiAgbWZuOiAwMDAwNDNmZg0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMjowOV0gICBnZm46IDAwMDA0NDAwICBtZm46IDAwMDA0NDAw
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjA5XSAgIGdmbjogMDAwMDQ0MDEgIG1mbjog
MDAwMDQ0MDENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MDldICAgZ2ZuOiAwMDAwNDQw
MiAgbWZuOiAwMDAwNDQwMg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjowOV0gICBnZm46
IDAwMDA0NDAzICBtZm46IDAwMDA0NDAzDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjA5
XSAgIGdmbjogMDAwMDQ0MDQgIG1mbjogMDAwMDQ0MDQNCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzI6MDldICAgZ2ZuOiAwMDAwNDQwNSAgbWZuOiAwMDAwNDQwNQ0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMjowOV0gICBnZm46IDAwMDA0NDA2ICBtZm46IDAwMDA0NDA2DQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMyOjA5XSAgIGdmbjogMDAwMDQ0MDcgIG1mbjogMDAwMDQ0
MDcNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MDldICAgZ2ZuOiAwMDAwNDQwOCAgbWZu
OiAwMDAwNDQwOA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjowOV0gICBnZm46IDAwMDA0
NDA5ICBtZm46IDAwMDA0NDA5DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjA5XSAgIGdm
bjogMDAwMDQ0MGEgIG1mbjogMDAwMDQ0MGENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6
MDldICAgZ2ZuOiAwMDAwNDQwYiAgbWZuOiAwMDAwNDQwYg0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMjowOV0gICBnZm46IDAwMDA0NDBjICBtZm46IDAwMDA0NDBjDQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMyOjA5XSAgIGdmbjogMDAwMDQ0MGQgIG1mbjogMDAwMDQ0MGQNCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MDldICAgZ2ZuOiAwMDAwNDQwZSAgbWZuOiAwMDAw
NDQwZQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjowOV0gICBnZm46IDAwMDA0NDBmICBt
Zm46IDAwMDA0NDBmDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjA5XSAgIGdmbjogMDAw
MDQ0MTAgIG1mbjogMDAwMDQ0MTANCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MDldICAg
Z2ZuOiAwMDAwNDQxMSAgbWZuOiAwMDAwNDQxMQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
MjowOV0gICBnZm46IDAwMDA0NDEyICBtZm46IDAwMDA0NDEyDQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMyOjA5XSAgIGdmbjogMDAwMDQ0MTMgIG1mbjogMDAwMDQ0MTMNCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzI6MDldICAgZ2ZuOiAwMDAwNDQxNCAgbWZuOiAwMDAwNDQxNA0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjowOV0gICBnZm46IDAwMDA0NDE1ICBtZm46IDAw
MDA0NDE1DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjA5XSAgIGdmbjogMDAwMDQ0MTYg
IG1mbjogMDAwMDQ0MTYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MDldICAgZ2ZuOiAw
MDAwNDQxNyAgbWZuOiAwMDAwNDQxNw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjowOV0g
ICBnZm46IDAwMDA0NDE4ICBtZm46IDAwMDA0NDE4DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMyOjA5XSAgIGdmbjogMDAwMDQ0MTkgIG1mbjogMDAwMDQ0MTkNCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzI6MDldICAgZ2ZuOiAwMDAwNDQxYSAgbWZuOiAwMDAwNDQxYQ0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMjowOV0gICBnZm46IDAwMDA0NDFiICBtZm46IDAwMDA0NDFi
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjA5XSAgIGdmbjogMDAwMDQ0MWMgIG1mbjog
MDAwMDQ0MWMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MDldICAgZ2ZuOiAwMDAwNDQx
ZCAgbWZuOiAwMDAwNDQxZA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjowOV0gICBnZm46
IDAwMDA0NDFlICBtZm46IDAwMDA0NDFlDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjA5
XSAgIGdmbjogMDAwMDQ0MWYgIG1mbjogMDAwMDQ0MWYNCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzI6MDldICAgZ2ZuOiAwMDAwNDQyMCAgbWZuOiAwMDAwNDQyMA0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMjowOV0gICBnZm46IDAwMDA0NDIxICBtZm46IDAwMDA0NDIxDQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMyOjA5XSAgIGdmbjogMDAwMDQ0MjIgIG1mbjogMDAwMDQ0
MjINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MDldICAgZ2ZuOiAwMDAwNDQyMyAgbWZu
OiAwMDAwNDQyMw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjowOV0gICBnZm46IDAwMDA0
NDI0ICBtZm46IDAwMDA0NDI0DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjA5XSAgIGdm
bjogMDAwMDQ0MjUgIG1mbjogMDAwMDQ0MjUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6
MDldICAgZ2ZuOiAwMDAwNDQyNiAgbWZuOiAwMDAwNDQyNg0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMjowOV0gICBnZm46IDAwMDA0NDI3ICBtZm46IDAwMDA0NDI3DQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMyOjA5XSAgIGdmbjogMDAwMDQ0MjggIG1mbjogMDAwMDQ0MjgNCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MDldICAgZ2ZuOiAwMDAwNDQyOSAgbWZuOiAwMDAw
NDQyOQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjowOV0gICBnZm46IDAwMDA0NDJhICBt
Zm46IDAwMDA0NDJhDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjA5XSAgIGdmbjogMDAw
MDQ0MmIgIG1mbjogMDAwMDQ0MmINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MDldICAg
Z2ZuOiAwMDAwNDQyYyAgbWZuOiAwMDAwNDQyYw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
MjowOV0gICBnZm46IDAwMDA0NDJkICBtZm46IDAwMDA0NDJkDQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMyOjA5XSAgIGdmbjogMDAwMDQ0MmUgIG1mbjogMDAwMDQ0MmUNCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzI6MDldICAgZ2ZuOiAwMDAwNDQyZiAgbWZuOiAwMDAwNDQyZg0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjowOV0gICBnZm46IDAwMDA0NDMwICBtZm46IDAw
MDA0NDMwDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjA5XSAgIGdmbjogMDAwMDQ0MzEg
IG1mbjogMDAwMDQ0MzENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MDldICAgZ2ZuOiAw
MDAwNDQzMiAgbWZuOiAwMDAwNDQzMg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjowOV0g
ICBnZm46IDAwMDA0NDMzICBtZm46IDAwMDA0NDMzDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMyOjA5XSAgIGdmbjogMDAwMDQ0MzQgIG1mbjogMDAwMDQ0MzQNCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzI6MDldICAgZ2ZuOiAwMDAwNDQzNSAgbWZuOiAwMDAwNDQzNQ0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMjowOV0gICBnZm46IDAwMDA0NDM2ICBtZm46IDAwMDA0NDM2
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjA5XSAgIGdmbjogMDAwMDQ0MzcgIG1mbjog
MDAwMDQ0MzcNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MDldICAgZ2ZuOiAwMDAwNDQz
OCAgbWZuOiAwMDAwNDQzOA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjowOV0gICBnZm46
IDAwMDA0NDM5ICBtZm46IDAwMDA0NDM5DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjA5
XSAgIGdmbjogMDAwMDQ0M2EgIG1mbjogMDAwMDQ0M2ENCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzI6MTBdICAgZ2ZuOiAwMDAwNDQzYiAgbWZuOiAwMDAwNDQzYg0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMjoxMF0gICBnZm46IDAwMDA0NDNjICBtZm46IDAwMDA0NDNjDQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMyOjEwXSAgIGdmbjogMDAwMDQ0M2QgIG1mbjogMDAwMDQ0
M2QNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MTBdICAgZ2ZuOiAwMDAwNDQzZSAgbWZu
OiAwMDAwNDQzZQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoxMF0gICBnZm46IDAwMDA0
NDNmICBtZm46IDAwMDA0NDNmDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjEwXSAgIGdm
bjogMDAwMDQ0NDAgIG1mbjogMDAwMDQ0NDANCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6
MTBdICAgZ2ZuOiAwMDAwNDQ0MSAgbWZuOiAwMDAwNDQ0MQ0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMjoxMF0gICBnZm46IDAwMDA0NDQyICBtZm46IDAwMDA0NDQyDQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMyOjEwXSAgIGdmbjogMDAwMDQ0NDMgIG1mbjogMDAwMDQ0NDMNCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MTBdICAgZ2ZuOiAwMDAwNDQ0NCAgbWZuOiAwMDAw
NDQ0NA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoxMF0gICBnZm46IDAwMDA0NDQ1ICBt
Zm46IDAwMDA0NDQ1DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjEwXSAgIGdmbjogMDAw
MDQ0NDYgIG1mbjogMDAwMDQ0NDYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MTBdICAg
Z2ZuOiAwMDAwNDQ0NyAgbWZuOiAwMDAwNDQ0Nw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
MjoxMF0gICBnZm46IDAwMDA0NDQ4ICBtZm46IDAwMDA0NDQ4DQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMyOjEwXSAgIGdmbjogMDAwMDQ0NDkgIG1mbjogMDAwMDQ0NDkNCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzI6MTBdICAgZ2ZuOiAwMDAwNDQ0YSAgbWZuOiAwMDAwNDQ0YQ0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoxMF0gICBnZm46IDAwMDA0NDRiICBtZm46IDAw
MDA0NDRiDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjEwXSAgIGdmbjogMDAwMDQ0NGMg
IG1mbjogMDAwMDQ0NGMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MTBdICAgZ2ZuOiAw
MDAwNDQ0ZCAgbWZuOiAwMDAwNDQ0ZA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoxMF0g
ICBnZm46IDAwMDA0NDRlICBtZm46IDAwMDA0NDRlDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMyOjEwXSAgIGdmbjogMDAwMDQ0NGYgIG1mbjogMDAwMDQ0NGYNCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzI6MTBdICAgZ2ZuOiAwMDAwNDQ1MCAgbWZuOiAwMDAwNDQ1MA0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMjoxMF0gICBnZm46IDAwMDA0NDUxICBtZm46IDAwMDA0NDUx
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjEwXSAgIGdmbjogMDAwMDQ0NTIgIG1mbjog
MDAwMDQ0NTINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MTBdICAgZ2ZuOiAwMDAwNDQ1
MyAgbWZuOiAwMDAwNDQ1Mw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoxMF0gICBnZm46
IDAwMDA0NDU0ICBtZm46IDAwMDA0NDU0DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjEw
XSAgIGdmbjogMDAwMDQ0NTUgIG1mbjogMDAwMDQ0NTUNCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzI6MTBdICAgZ2ZuOiAwMDAwNDQ1NiAgbWZuOiAwMDAwNDQ1Ng0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMjoxMF0gICBnZm46IDAwMDA0NDU3ICBtZm46IDAwMDA0NDU3DQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMyOjEwXSAgIGdmbjogMDAwMDQ0NTggIG1mbjogMDAwMDQ0
NTgNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MTBdICAgZ2ZuOiAwMDAwNDQ1OSAgbWZu
OiAwMDAwNDQ1OQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoxMF0gICBnZm46IDAwMDA0
NDVhICBtZm46IDAwMDA0NDVhDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjEwXSAgIGdm
bjogMDAwMDQ0NWIgIG1mbjogMDAwMDQ0NWINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6
MTBdICAgZ2ZuOiAwMDAwNDQ1YyAgbWZuOiAwMDAwNDQ1Yw0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMjoxMF0gICBnZm46IDAwMDA0NDVkICBtZm46IDAwMDA0NDVkDQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMyOjEwXSAgIGdmbjogMDAwMDQ0NWUgIG1mbjogMDAwMDQ0NWUNCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MTBdICAgZ2ZuOiAwMDAwNDQ1ZiAgbWZuOiAwMDAw
NDQ1Zg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoxMF0gICBnZm46IDAwMDA0NDYwICBt
Zm46IDAwMDA0NDYwDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjEwXSAgIGdmbjogMDAw
MDQ0NjEgIG1mbjogMDAwMDQ0NjENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MTBdICAg
Z2ZuOiAwMDAwNDQ2MiAgbWZuOiAwMDAwNDQ2Mg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
MjoxMF0gICBnZm46IDAwMDA0NDYzICBtZm46IDAwMDA0NDYzDQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMyOjEwXSAgIGdmbjogMDAwMDQ0NjQgIG1mbjogMDAwMDQ0NjQNCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzI6MTBdICAgZ2ZuOiAwMDAwNDQ2NSAgbWZuOiAwMDAwNDQ2NQ0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoxMF0gICBnZm46IDAwMDA0NDY2ICBtZm46IDAw
MDA0NDY2DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjEwXSAgIGdmbjogMDAwMDQ0Njcg
IG1mbjogMDAwMDQ0NjcNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MTBdICAgZ2ZuOiAw
MDAwNDQ2OCAgbWZuOiAwMDAwNDQ2OA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoxMF0g
ICBnZm46IDAwMDA0NDY5ICBtZm46IDAwMDA0NDY5DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMyOjEwXSAgIGdmbjogMDAwMDQ0NmEgIG1mbjogMDAwMDQ0NmENCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzI6MTBdICAgZ2ZuOiAwMDAwNDQ2YiAgbWZuOiAwMDAwNDQ2Yg0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMjoxMF0gICBnZm46IDAwMDA0NDZjICBtZm46IDAwMDA0NDZj
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjEwXSAgIGdmbjogMDAwMDQ0NmQgIG1mbjog
MDAwMDQ0NmQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MTBdICAgZ2ZuOiAwMDAwNDQ2
ZSAgbWZuOiAwMDAwNDQ2ZQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoxMF0gICBnZm46
IDAwMDA0NDZmICBtZm46IDAwMDA0NDZmDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjEw
XSAgIGdmbjogMDAwMDQ0NzAgIG1mbjogMDAwMDQ0NzANCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzI6MTBdICAgZ2ZuOiAwMDAwNDQ3MSAgbWZuOiAwMDAwNDQ3MQ0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMjoxMF0gICBnZm46IDAwMDA0NDcyICBtZm46IDAwMDA0NDcyDQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMyOjEwXSAgIGdmbjogMDAwMDQ0NzMgIG1mbjogMDAwMDQ0
NzMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MTBdICAgZ2ZuOiAwMDAwNDQ3NCAgbWZu
OiAwMDAwNDQ3NA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoxMF0gICBnZm46IDAwMDA0
NDc1ICBtZm46IDAwMDA0NDc1DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjEwXSAgIGdm
bjogMDAwMDQ0NzYgIG1mbjogMDAwMDQ0NzYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6
MTBdICAgZ2ZuOiAwMDAwNDQ3NyAgbWZuOiAwMDAwNDQ3Nw0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMjoxMF0gICBnZm46IDAwMDA0NDc4ICBtZm46IDAwMDA0NDc4DQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMyOjEwXSAgIGdmbjogMDAwMDQ0NzkgIG1mbjogMDAwMDQ0NzkNCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MTBdICAgZ2ZuOiAwMDAwNDQ3YSAgbWZuOiAwMDAw
NDQ3YQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoxMV0gICBnZm46IDAwMDA0NDdiICBt
Zm46IDAwMDA0NDdiDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjExXSAgIGdmbjogMDAw
MDQ0N2MgIG1mbjogMDAwMDQ0N2MNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MTFdICAg
Z2ZuOiAwMDAwNDQ3ZCAgbWZuOiAwMDAwNDQ3ZA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
MjoxMV0gICBnZm46IDAwMDA0NDdlICBtZm46IDAwMDA0NDdlDQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMyOjExXSAgIGdmbjogMDAwMDQ0N2YgIG1mbjogMDAwMDQ0N2YNCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzI6MTFdICAgZ2ZuOiAwMDAwNDQ4MCAgbWZuOiAwMDAwNDQ4MA0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoxMV0gICBnZm46IDAwMDA0NDgxICBtZm46IDAw
MDA0NDgxDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjExXSAgIGdmbjogMDAwMDQ0ODIg
IG1mbjogMDAwMDQ0ODINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MTFdICAgZ2ZuOiAw
MDAwNDQ4MyAgbWZuOiAwMDAwNDQ4Mw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoxMV0g
ICBnZm46IDAwMDA0NDg0ICBtZm46IDAwMDA0NDg0DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMyOjExXSAgIGdmbjogMDAwMDQ0ODUgIG1mbjogMDAwMDQ0ODUNCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzI6MTFdICAgZ2ZuOiAwMDAwNDQ4NiAgbWZuOiAwMDAwNDQ4Ng0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMjoxMV0gICBnZm46IDAwMDA0NDg3ICBtZm46IDAwMDA0NDg3
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjExXSAgIGdmbjogMDAwMDQ0ODggIG1mbjog
MDAwMDQ0ODgNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MTFdICAgZ2ZuOiAwMDAwNDQ4
OSAgbWZuOiAwMDAwNDQ4OQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoxMV0gICBnZm46
IDAwMDA0NDhhICBtZm46IDAwMDA0NDhhDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjEx
XSAgIGdmbjogMDAwMDQ0OGIgIG1mbjogMDAwMDQ0OGINCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzI6MTFdICAgZ2ZuOiAwMDAwNDQ4YyAgbWZuOiAwMDAwNDQ4Yw0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMjoxMV0gICBnZm46IDAwMDA0NDhkICBtZm46IDAwMDA0NDhkDQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMyOjExXSAgIGdmbjogMDAwMDQ0OGUgIG1mbjogMDAwMDQ0
OGUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MTFdICAgZ2ZuOiAwMDAwNDQ4ZiAgbWZu
OiAwMDAwNDQ4Zg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoxMV0gICBnZm46IDAwMDA0
NDkwICBtZm46IDAwMDA0NDkwDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjExXSAgIGdm
bjogMDAwMDQ0OTEgIG1mbjogMDAwMDQ0OTENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6
MTFdICAgZ2ZuOiAwMDAwNDQ5MiAgbWZuOiAwMDAwNDQ5Mg0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMjoxMV0gICBnZm46IDAwMDA0NDkzICBtZm46IDAwMDA0NDkzDQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMyOjExXSAgIGdmbjogMDAwMDQ0OTQgIG1mbjogMDAwMDQ0OTQNCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MTFdICAgZ2ZuOiAwMDAwNDQ5NSAgbWZuOiAwMDAw
NDQ5NQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoxMV0gICBnZm46IDAwMDA0NDk2ICBt
Zm46IDAwMDA0NDk2DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjExXSAgIGdmbjogMDAw
MDQ0OTcgIG1mbjogMDAwMDQ0OTcNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MTFdICAg
Z2ZuOiAwMDAwNDQ5OCAgbWZuOiAwMDAwNDQ5OA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
MjoxMV0gICBnZm46IDAwMDA0NDk5ICBtZm46IDAwMDA0NDk5DQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMyOjExXSAgIGdmbjogMDAwMDQ0OWEgIG1mbjogMDAwMDQ0OWENCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzI6MTFdICAgZ2ZuOiAwMDAwNDQ5YiAgbWZuOiAwMDAwNDQ5Yg0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoxMV0gICBnZm46IDAwMDA0NDljICBtZm46IDAw
MDA0NDljDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjExXSAgIGdmbjogMDAwMDQ0OWQg
IG1mbjogMDAwMDQ0OWQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MTFdICAgZ2ZuOiAw
MDAwNDQ5ZSAgbWZuOiAwMDAwNDQ5ZQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoxMV0g
ICBnZm46IDAwMDA0NDlmICBtZm46IDAwMDA0NDlmDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMyOjExXSAgIGdmbjogMDAwMDQ0YTAgIG1mbjogMDAwMDQ0YTANCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzI6MTFdICAgZ2ZuOiAwMDAwNDRhMSAgbWZuOiAwMDAwNDRhMQ0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMjoxMV0gICBnZm46IDAwMDA0NGEyICBtZm46IDAwMDA0NGEy
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjExXSAgIGdmbjogMDAwMDQ0YTMgIG1mbjog
MDAwMDQ0YTMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MTFdICAgZ2ZuOiAwMDAwNDRh
NCAgbWZuOiAwMDAwNDRhNA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoxMV0gICBnZm46
IDAwMDA0NGE1ICBtZm46IDAwMDA0NGE1DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjEx
XSAgIGdmbjogMDAwMDQ0YTYgIG1mbjogMDAwMDQ0YTYNCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzI6MTFdICAgZ2ZuOiAwMDAwNDRhNyAgbWZuOiAwMDAwNDRhNw0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMjoxMV0gICBnZm46IDAwMDA0NGE4ICBtZm46IDAwMDA0NGE4DQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMyOjExXSAgIGdmbjogMDAwMDQ0YTkgIG1mbjogMDAwMDQ0
YTkNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MTFdICAgZ2ZuOiAwMDAwNDRhYSAgbWZu
OiAwMDAwNDRhYQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoxMV0gICBnZm46IDAwMDA0
NGFiICBtZm46IDAwMDA0NGFiDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjExXSAgIGdm
bjogMDAwMDQ0YWMgIG1mbjogMDAwMDQ0YWMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6
MTFdICAgZ2ZuOiAwMDAwNDRhZCAgbWZuOiAwMDAwNDRhZA0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMjoxMV0gICBnZm46IDAwMDA0NGFlICBtZm46IDAwMDA0NGFlDQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMyOjExXSAgIGdmbjogMDAwMDQ0YWYgIG1mbjogMDAwMDQ0YWYNCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MTFdICAgZ2ZuOiAwMDAwNDRiMCAgbWZuOiAwMDAw
NDRiMA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoxMV0gICBnZm46IDAwMDA0NGIxICBt
Zm46IDAwMDA0NGIxDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjExXSAgIGdmbjogMDAw
MDQ0YjIgIG1mbjogMDAwMDQ0YjINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MTFdICAg
Z2ZuOiAwMDAwNDRiMyAgbWZuOiAwMDAwNDRiMw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
MjoxMV0gICBnZm46IDAwMDA0NGI0ICBtZm46IDAwMDA0NGI0DQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMyOjExXSAgIGdmbjogMDAwMDQ0YjUgIG1mbjogMDAwMDQ0YjUNCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzI6MTFdICAgZ2ZuOiAwMDAwNDRiNiAgbWZuOiAwMDAwNDRiNg0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoxMV0gICBnZm46IDAwMDA0NGI3ICBtZm46IDAw
MDA0NGI3DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjExXSAgIGdmbjogMDAwMDQ0Yjgg
IG1mbjogMDAwMDQ0YjgNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MTFdICAgZ2ZuOiAw
MDAwNDRiOSAgbWZuOiAwMDAwNDRiOQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoxMV0g
ICBnZm46IDAwMDA0NGJhICBtZm46IDAwMDA0NGJhDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMyOjEyXSAgIGdmbjogMDAwMDQ0YmIgIG1mbjogMDAwMDQ0YmINCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzI6MTJdICAgZ2ZuOiAwMDAwNDRiYyAgbWZuOiAwMDAwNDRiYw0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMjoxMl0gICBnZm46IDAwMDA0NGJkICBtZm46IDAwMDA0NGJk
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjEyXSAgIGdmbjogMDAwMDQ0YmUgIG1mbjog
MDAwMDQ0YmUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MTJdICAgZ2ZuOiAwMDAwNDRi
ZiAgbWZuOiAwMDAwNDRiZg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoxMl0gICBnZm46
IDAwMDA0NGMwICBtZm46IDAwMDA0NGMwDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjEy
XSAgIGdmbjogMDAwMDQ0YzEgIG1mbjogMDAwMDQ0YzENCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzI6MTJdICAgZ2ZuOiAwMDAwNDRjMiAgbWZuOiAwMDAwNDRjMg0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMjoxMl0gICBnZm46IDAwMDA0NGMzICBtZm46IDAwMDA0NGMzDQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMyOjEyXSAgIGdmbjogMDAwMDQ0YzQgIG1mbjogMDAwMDQ0
YzQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MTJdICAgZ2ZuOiAwMDAwNDRjNSAgbWZu
OiAwMDAwNDRjNQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoxMl0gICBnZm46IDAwMDA0
NGM2ICBtZm46IDAwMDA0NGM2DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjEyXSAgIGdm
bjogMDAwMDQ0YzcgIG1mbjogMDAwMDQ0YzcNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6
MTJdICAgZ2ZuOiAwMDAwNDRjOCAgbWZuOiAwMDAwNDRjOA0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMjoxMl0gICBnZm46IDAwMDA0NGM5ICBtZm46IDAwMDA0NGM5DQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMyOjEyXSAgIGdmbjogMDAwMDQ0Y2EgIG1mbjogMDAwMDQ0Y2ENCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MTJdICAgZ2ZuOiAwMDAwNDRjYiAgbWZuOiAwMDAw
NDRjYg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoxMl0gICBnZm46IDAwMDA0NGNjICBt
Zm46IDAwMDA0NGNjDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjEyXSAgIGdmbjogMDAw
MDQ0Y2QgIG1mbjogMDAwMDQ0Y2QNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MTJdICAg
Z2ZuOiAwMDAwNDRjZSAgbWZuOiAwMDAwNDRjZQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
MjoxMl0gICBnZm46IDAwMDA0NGNmICBtZm46IDAwMDA0NGNmDQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMyOjEyXSAgIGdmbjogMDAwMDQ0ZDAgIG1mbjogMDAwMDQ0ZDANCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzI6MTJdICAgZ2ZuOiAwMDAwNDRkMSAgbWZuOiAwMDAwNDRkMQ0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoxMl0gICBnZm46IDAwMDA0NGQyICBtZm46IDAw
MDA0NGQyDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjEyXSAgIGdmbjogMDAwMDQ0ZDMg
IG1mbjogMDAwMDQ0ZDMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MTJdICAgZ2ZuOiAw
MDAwNDRkNCAgbWZuOiAwMDAwNDRkNA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoxMl0g
ICBnZm46IDAwMDA0NGQ1ICBtZm46IDAwMDA0NGQ1DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMyOjEyXSAgIGdmbjogMDAwMDQ0ZDYgIG1mbjogMDAwMDQ0ZDYNCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzI6MTJdICAgZ2ZuOiAwMDAwNDRkNyAgbWZuOiAwMDAwNDRkNw0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMjoxMl0gICBnZm46IDAwMDA0NGQ4ICBtZm46IDAwMDA0NGQ4
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjEyXSAgIGdmbjogMDAwMDQ0ZDkgIG1mbjog
MDAwMDQ0ZDkNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MTJdICAgZ2ZuOiAwMDAwNDRk
YSAgbWZuOiAwMDAwNDRkYQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoxMl0gICBnZm46
IDAwMDA0NGRiICBtZm46IDAwMDA0NGRiDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjEy
XSAgIGdmbjogMDAwMDQ0ZGMgIG1mbjogMDAwMDQ0ZGMNCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzI6MTJdICAgZ2ZuOiAwMDAwNDRkZCAgbWZuOiAwMDAwNDRkZA0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMjoxMl0gICBnZm46IDAwMDA0NGRlICBtZm46IDAwMDA0NGRlDQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMyOjEyXSAgIGdmbjogMDAwMDQ0ZGYgIG1mbjogMDAwMDQ0
ZGYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MTJdICAgZ2ZuOiAwMDAwNDRlMCAgbWZu
OiAwMDAwNDRlMA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoxMl0gICBnZm46IDAwMDA0
NGUxICBtZm46IDAwMDA0NGUxDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjEyXSAgIGdm
bjogMDAwMDQ0ZTIgIG1mbjogMDAwMDQ0ZTINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6
MTJdICAgZ2ZuOiAwMDAwNDRlMyAgbWZuOiAwMDAwNDRlMw0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMjoxMl0gICBnZm46IDAwMDA0NGU0ICBtZm46IDAwMDA0NGU0DQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMyOjEyXSAgIGdmbjogMDAwMDQ0ZTUgIG1mbjogMDAwMDQ0ZTUNCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MTJdICAgZ2ZuOiAwMDAwNDRlNiAgbWZuOiAwMDAw
NDRlNg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoxMl0gICBnZm46IDAwMDA0NGU3ICBt
Zm46IDAwMDA0NGU3DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjEyXSAgIGdmbjogMDAw
MDQ0ZTggIG1mbjogMDAwMDQ0ZTgNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MTJdICAg
Z2ZuOiAwMDAwNDRlOSAgbWZuOiAwMDAwNDRlOQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
MjoxMl0gICBnZm46IDAwMDA0NGVhICBtZm46IDAwMDA0NGVhDQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMyOjEyXSAgIGdmbjogMDAwMDQ0ZWIgIG1mbjogMDAwMDQ0ZWINCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzI6MTJdICAgZ2ZuOiAwMDAwNDRlYyAgbWZuOiAwMDAwNDRlYw0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoxMl0gICBnZm46IDAwMDA0NGVkICBtZm46IDAw
MDA0NGVkDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjEyXSAgIGdmbjogMDAwMDQ0ZWUg
IG1mbjogMDAwMDQ0ZWUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MTJdICAgZ2ZuOiAw
MDAwNDRlZiAgbWZuOiAwMDAwNDRlZg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoxMl0g
ICBnZm46IDAwMDA0NGYwICBtZm46IDAwMDA0NGYwDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMyOjEyXSAgIGdmbjogMDAwMDQ0ZjEgIG1mbjogMDAwMDQ0ZjENCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzI6MTJdICAgZ2ZuOiAwMDAwNDRmMiAgbWZuOiAwMDAwNDRmMg0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMjoxMl0gICBnZm46IDAwMDA0NGYzICBtZm46IDAwMDA0NGYz
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjEyXSAgIGdmbjogMDAwMDQ0ZjQgIG1mbjog
MDAwMDQ0ZjQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MTJdICAgZ2ZuOiAwMDAwNDRm
NSAgbWZuOiAwMDAwNDRmNQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoxMl0gICBnZm46
IDAwMDA0NGY2ICBtZm46IDAwMDA0NGY2DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjEy
XSAgIGdmbjogMDAwMDQ0ZjcgIG1mbjogMDAwMDQ0ZjcNCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzI6MTJdICAgZ2ZuOiAwMDAwNDRmOCAgbWZuOiAwMDAwNDRmOA0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMjoxMl0gICBnZm46IDAwMDA0NGY5ICBtZm46IDAwMDA0NGY5DQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMyOjEyXSAgIGdmbjogMDAwMDQ0ZmEgIG1mbjogMDAwMDQ0
ZmENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MTJdICAgZ2ZuOiAwMDAwNDRmYiAgbWZu
OiAwMDAwNDRmYg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoxM10gICBnZm46IDAwMDA0
NGZjICBtZm46IDAwMDA0NGZjDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjEzXSAgIGdm
bjogMDAwMDQ0ZmQgIG1mbjogMDAwMDQ0ZmQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6
MTNdICAgZ2ZuOiAwMDAwNDRmZSAgbWZuOiAwMDAwNDRmZQ0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMjoxM10gICBnZm46IDAwMDA0NGZmICBtZm46IDAwMDA0NGZmDQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMyOjEzXSAgIGdmbjogMDAwMDQ1MDAgIG1mbjogMDAwMDQ1MDANCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MTNdICAgZ2ZuOiAwMDAwNDUwMSAgbWZuOiAwMDAw
NDUwMQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoxM10gICBnZm46IDAwMDA0NTAyICBt
Zm46IDAwMDA0NTAyDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjEzXSAgIGdmbjogMDAw
MDQ1MDMgIG1mbjogMDAwMDQ1MDMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MTNdICAg
Z2ZuOiAwMDAwNDUwNCAgbWZuOiAwMDAwNDUwNA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
MjoxM10gICBnZm46IDAwMDA0NTA1ICBtZm46IDAwMDA0NTA1DQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMyOjEzXSAgIGdmbjogMDAwMDQ1MDYgIG1mbjogMDAwMDQ1MDYNCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzI6MTNdICAgZ2ZuOiAwMDAwNDUwNyAgbWZuOiAwMDAwNDUwNw0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoxM10gICBnZm46IDAwMDA0NTA4ICBtZm46IDAw
MDA0NTA4DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjEzXSAgIGdmbjogMDAwMDQ1MDkg
IG1mbjogMDAwMDQ1MDkNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MTNdICAgZ2ZuOiAw
MDAwNDUwYSAgbWZuOiAwMDAwNDUwYQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoxM10g
ICBnZm46IDAwMDA0NTBiICBtZm46IDAwMDA0NTBiDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMyOjEzXSAgIGdmbjogMDAwMDQ1MGMgIG1mbjogMDAwMDQ1MGMNCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzI6MTNdICAgZ2ZuOiAwMDAwNDUwZCAgbWZuOiAwMDAwNDUwZA0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMjoxM10gICBnZm46IDAwMDA0NTBlICBtZm46IDAwMDA0NTBl
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjEzXSAgIGdmbjogMDAwMDQ1MGYgIG1mbjog
MDAwMDQ1MGYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MTNdICAgZ2ZuOiAwMDAwNDUx
MCAgbWZuOiAwMDAwNDUxMA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoxM10gICBnZm46
IDAwMDA0NTExICBtZm46IDAwMDA0NTExDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjEz
XSAgIGdmbjogMDAwMDQ1MTIgIG1mbjogMDAwMDQ1MTINCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzI6MTNdICAgZ2ZuOiAwMDAwNDUxMyAgbWZuOiAwMDAwNDUxMw0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMjoxM10gICBnZm46IDAwMDA0NTE0ICBtZm46IDAwMDA0NTE0DQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMyOjEzXSAgIGdmbjogMDAwMDQ1MTUgIG1mbjogMDAwMDQ1
MTUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MTNdICAgZ2ZuOiAwMDAwNDUxNiAgbWZu
OiAwMDAwNDUxNg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoxM10gICBnZm46IDAwMDA0
NTE3ICBtZm46IDAwMDA0NTE3DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjEzXSAgIGdm
bjogMDAwMDQ1MTggIG1mbjogMDAwMDQ1MTgNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6
MTNdICAgZ2ZuOiAwMDAwNDUxOSAgbWZuOiAwMDAwNDUxOQ0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMjoxM10gICBnZm46IDAwMDA0NTFhICBtZm46IDAwMDA0NTFhDQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMyOjEzXSAgIGdmbjogMDAwMDQ1MWIgIG1mbjogMDAwMDQ1MWINCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MTNdICAgZ2ZuOiAwMDAwNDUxYyAgbWZuOiAwMDAw
NDUxYw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoxM10gICBnZm46IDAwMDA0NTFkICBt
Zm46IDAwMDA0NTFkDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjEzXSAgIGdmbjogMDAw
MDQ1MWUgIG1mbjogMDAwMDQ1MWUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MTNdICAg
Z2ZuOiAwMDAwNDUxZiAgbWZuOiAwMDAwNDUxZg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
MjoxM10gICBnZm46IDAwMDA0NTIwICBtZm46IDAwMDA0NTIwDQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMyOjEzXSAgIGdmbjogMDAwMDQ1MjEgIG1mbjogMDAwMDQ1MjENCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzI6MTNdICAgZ2ZuOiAwMDAwNDUyMiAgbWZuOiAwMDAwNDUyMg0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoxM10gICBnZm46IDAwMDA0NTIzICBtZm46IDAw
MDA0NTIzDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjEzXSAgIGdmbjogMDAwMDQ1MjQg
IG1mbjogMDAwMDQ1MjQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MTNdICAgZ2ZuOiAw
MDAwNDUyNSAgbWZuOiAwMDAwNDUyNQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoxM10g
ICBnZm46IDAwMDA0NTI2ICBtZm46IDAwMDA0NTI2DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMyOjEzXSAgIGdmbjogMDAwMDQ1MjcgIG1mbjogMDAwMDQ1MjcNCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzI6MTNdICAgZ2ZuOiAwMDAwNDUyOCAgbWZuOiAwMDAwNDUyOA0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMjoxM10gICBnZm46IDAwMDA0NTI5ICBtZm46IDAwMDA0NTI5
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjEzXSAgIGdmbjogMDAwMDQ1MmEgIG1mbjog
MDAwMDQ1MmENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MTNdICAgZ2ZuOiAwMDAwNDUy
YiAgbWZuOiAwMDAwNDUyYg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoxM10gICBnZm46
IDAwMDA0NTJjICBtZm46IDAwMDA0NTJjDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjEz
XSAgIGdmbjogMDAwMDQ1MmQgIG1mbjogMDAwMDQ1MmQNCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzI6MTNdICAgZ2ZuOiAwMDAwNDUyZSAgbWZuOiAwMDAwNDUyZQ0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMjoxM10gICBnZm46IDAwMDA0NTJmICBtZm46IDAwMDA0NTJmDQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMyOjEzXSAgIGdmbjogMDAwMDQ1MzAgIG1mbjogMDAwMDQ1
MzANCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MTNdICAgZ2ZuOiAwMDAwNDUzMSAgbWZu
OiAwMDAwNDUzMQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoxM10gICBnZm46IDAwMDA0
NTMyICBtZm46IDAwMDA0NTMyDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjEzXSAgIGdm
bjogMDAwMDQ1MzMgIG1mbjogMDAwMDQ1MzMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6
MTNdICAgZ2ZuOiAwMDAwNDUzNCAgbWZuOiAwMDAwNDUzNA0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMjoxM10gICBnZm46IDAwMDA0NTM1ICBtZm46IDAwMDA0NTM1DQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMyOjEzXSAgIGdmbjogMDAwMDQ1MzYgIG1mbjogMDAwMDQ1MzYNCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MTNdICAgZ2ZuOiAwMDAwNDUzNyAgbWZuOiAwMDAw
NDUzNw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoxM10gICBnZm46IDAwMDA0NTM4ICBt
Zm46IDAwMDA0NTM4DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjEzXSAgIGdmbjogMDAw
MDQ1MzkgIG1mbjogMDAwMDQ1MzkNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MTNdICAg
Z2ZuOiAwMDAwNDUzYSAgbWZuOiAwMDAwNDUzYQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
MjoxM10gICBnZm46IDAwMDA0NTNiICBtZm46IDAwMDA0NTNiDQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMyOjE0XSAgIGdmbjogMDAwMDQ1M2MgIG1mbjogMDAwMDQ1M2MNCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzI6MTRdICAgZ2ZuOiAwMDAwNDUzZCAgbWZuOiAwMDAwNDUzZA0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoxNF0gICBnZm46IDAwMDA0NTNlICBtZm46IDAw
MDA0NTNlDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjE0XSAgIGdmbjogMDAwMDQ1M2Yg
IG1mbjogMDAwMDQ1M2YNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MTRdICAgZ2ZuOiAw
MDAwNDU0MCAgbWZuOiAwMDAwNDU0MA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoxNF0g
ICBnZm46IDAwMDA0NTQxICBtZm46IDAwMDA0NTQxDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMyOjE0XSAgIGdmbjogMDAwMDQ1NDIgIG1mbjogMDAwMDQ1NDINCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzI6MTRdICAgZ2ZuOiAwMDAwNDU0MyAgbWZuOiAwMDAwNDU0Mw0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMjoxNF0gICBnZm46IDAwMDA0NTQ0ICBtZm46IDAwMDA0NTQ0
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjE0XSAgIGdmbjogMDAwMDQ1NDUgIG1mbjog
MDAwMDQ1NDUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MTRdICAgZ2ZuOiAwMDAwNDU0
NiAgbWZuOiAwMDAwNDU0Ng0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoxNF0gICBnZm46
IDAwMDA0NTQ3ICBtZm46IDAwMDA0NTQ3DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjE0
XSAgIGdmbjogMDAwMDQ1NDggIG1mbjogMDAwMDQ1NDgNCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzI6MTRdICAgZ2ZuOiAwMDAwNDU0OSAgbWZuOiAwMDAwNDU0OQ0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMjoxNF0gICBnZm46IDAwMDA0NTRhICBtZm46IDAwMDA0NTRhDQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMyOjE0XSAgIGdmbjogMDAwMDQ1NGIgIG1mbjogMDAwMDQ1
NGINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MTRdICAgZ2ZuOiAwMDAwNDU0YyAgbWZu
OiAwMDAwNDU0Yw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoxNF0gICBnZm46IDAwMDA0
NTRkICBtZm46IDAwMDA0NTRkDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjE0XSAgIGdm
bjogMDAwMDQ1NGUgIG1mbjogMDAwMDQ1NGUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6
MTRdICAgZ2ZuOiAwMDAwNDU0ZiAgbWZuOiAwMDAwNDU0Zg0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMjoxNF0gICBnZm46IDAwMDA0NTUwICBtZm46IDAwMDA0NTUwDQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMyOjE0XSAgIGdmbjogMDAwMDQ1NTEgIG1mbjogMDAwMDQ1NTENCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MTRdICAgZ2ZuOiAwMDAwNDU1MiAgbWZuOiAwMDAw
NDU1Mg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoxNF0gICBnZm46IDAwMDA0NTUzICBt
Zm46IDAwMDA0NTUzDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjE0XSAgIGdmbjogMDAw
MDQ1NTQgIG1mbjogMDAwMDQ1NTQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MTRdICAg
Z2ZuOiAwMDAwNDU1NSAgbWZuOiAwMDAwNDU1NQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
MjoxNF0gICBnZm46IDAwMDA0NTU2ICBtZm46IDAwMDA0NTU2DQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMyOjE0XSAgIGdmbjogMDAwMDQ1NTcgIG1mbjogMDAwMDQ1NTcNCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzI6MTRdICAgZ2ZuOiAwMDAwNDU1OCAgbWZuOiAwMDAwNDU1OA0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoxNF0gICBnZm46IDAwMDA0NTU5ICBtZm46IDAw
MDA0NTU5DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjE0XSAgIGdmbjogMDAwMDQ1NWEg
IG1mbjogMDAwMDQ1NWENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MTRdICAgZ2ZuOiAw
MDAwNDU1YiAgbWZuOiAwMDAwNDU1Yg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoxNF0g
ICBnZm46IDAwMDA0NTVjICBtZm46IDAwMDA0NTVjDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMyOjE0XSAgIGdmbjogMDAwMDQ1NWQgIG1mbjogMDAwMDQ1NWQNCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzI6MTRdICAgZ2ZuOiAwMDAwNDU1ZSAgbWZuOiAwMDAwNDU1ZQ0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMjoxNF0gICBnZm46IDAwMDA0NTVmICBtZm46IDAwMDA0NTVm
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjE0XSAgIGdmbjogMDAwMDQ1NjAgIG1mbjog
MDAwMDQ1NjANCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MTRdICAgZ2ZuOiAwMDAwNDU2
MSAgbWZuOiAwMDAwNDU2MQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoxNF0gICBnZm46
IDAwMDA0NTYyICBtZm46IDAwMDA0NTYyDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjE0
XSAgIGdmbjogMDAwMDQ1NjMgIG1mbjogMDAwMDQ1NjMNCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzI6MTRdICAgZ2ZuOiAwMDAwNDU2NCAgbWZuOiAwMDAwNDU2NA0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMjoxNF0gICBnZm46IDAwMDA0NTY1ICBtZm46IDAwMDA0NTY1DQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMyOjE0XSAgIGdmbjogMDAwMDQ1NjYgIG1mbjogMDAwMDQ1
NjYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MTRdICAgZ2ZuOiAwMDAwNDU2NyAgbWZu
OiAwMDAwNDU2Nw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoxNF0gICBnZm46IDAwMDA0
NTY4ICBtZm46IDAwMDA0NTY4DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjE0XSAgIGdm
bjogMDAwMDQ1NjkgIG1mbjogMDAwMDQ1NjkNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6
MTRdICAgZ2ZuOiAwMDAwNDU2YSAgbWZuOiAwMDAwNDU2YQ0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMjoxNF0gICBnZm46IDAwMDA0NTZiICBtZm46IDAwMDA0NTZiDQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMyOjE0XSAgIGdmbjogMDAwMDQ1NmMgIG1mbjogMDAwMDQ1NmMNCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MTRdICAgZ2ZuOiAwMDAwNDU2ZCAgbWZuOiAwMDAw
NDU2ZA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoxNF0gICBnZm46IDAwMDA0NTZlICBt
Zm46IDAwMDA0NTZlDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjE0XSAgIGdmbjogMDAw
MDQ1NmYgIG1mbjogMDAwMDQ1NmYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MTRdICAg
Z2ZuOiAwMDAwNDU3MCAgbWZuOiAwMDAwNDU3MA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
MjoxNF0gICBnZm46IDAwMDA0NTcxICBtZm46IDAwMDA0NTcxDQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMyOjE0XSAgIGdmbjogMDAwMDQ1NzIgIG1mbjogMDAwMDQ1NzINCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzI6MTRdICAgZ2ZuOiAwMDAwNDU3MyAgbWZuOiAwMDAwNDU3Mw0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoxNF0gICBnZm46IDAwMDA0NTc0ICBtZm46IDAw
MDA0NTc0DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjE0XSAgIGdmbjogMDAwMDQ1NzUg
IG1mbjogMDAwMDQ1NzUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MTRdICAgZ2ZuOiAw
MDAwNDU3NiAgbWZuOiAwMDAwNDU3Ng0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoxNF0g
ICBnZm46IDAwMDA0NTc3ICBtZm46IDAwMDA0NTc3DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMyOjE0XSAgIGdmbjogMDAwMDQ1NzggIG1mbjogMDAwMDQ1NzgNCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzI6MTRdICAgZ2ZuOiAwMDAwNDU3OSAgbWZuOiAwMDAwNDU3OQ0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMjoxNF0gICBnZm46IDAwMDA0NTdhICBtZm46IDAwMDA0NTdh
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjE0XSAgIGdmbjogMDAwMDQ1N2IgIG1mbjog
MDAwMDQ1N2INCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MTVdICAgZ2ZuOiAwMDAwNDU3
YyAgbWZuOiAwMDAwNDU3Yw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoxNV0gICBnZm46
IDAwMDA0NTdkICBtZm46IDAwMDA0NTdkDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjE1
XSAgIGdmbjogMDAwMDQ1N2UgIG1mbjogMDAwMDQ1N2UNCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzI6MTVdICAgZ2ZuOiAwMDAwNDU3ZiAgbWZuOiAwMDAwNDU3Zg0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMjoxNV0gICBnZm46IDAwMDA0NTgwICBtZm46IDAwMDA0NTgwDQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMyOjE1XSAgIGdmbjogMDAwMDQ1ODEgIG1mbjogMDAwMDQ1
ODENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MTVdICAgZ2ZuOiAwMDAwNDU4MiAgbWZu
OiAwMDAwNDU4Mg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoxNV0gICBnZm46IDAwMDA0
NTgzICBtZm46IDAwMDA0NTgzDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjE1XSAgIGdm
bjogMDAwMDQ1ODQgIG1mbjogMDAwMDQ1ODQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6
MTVdICAgZ2ZuOiAwMDAwNDU4NSAgbWZuOiAwMDAwNDU4NQ0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMjoxNV0gICBnZm46IDAwMDA0NTg2ICBtZm46IDAwMDA0NTg2DQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMyOjE1XSAgIGdmbjogMDAwMDQ1ODcgIG1mbjogMDAwMDQ1ODcNCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MTVdICAgZ2ZuOiAwMDAwNDU4OCAgbWZuOiAwMDAw
NDU4OA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoxNV0gICBnZm46IDAwMDA0NTg5ICBt
Zm46IDAwMDA0NTg5DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjE1XSAgIGdmbjogMDAw
MDQ1OGEgIG1mbjogMDAwMDQ1OGENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MTVdICAg
Z2ZuOiAwMDAwNDU4YiAgbWZuOiAwMDAwNDU4Yg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
MjoxNV0gICBnZm46IDAwMDA0NThjICBtZm46IDAwMDA0NThjDQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMyOjE1XSAgIGdmbjogMDAwMDQ1OGQgIG1mbjogMDAwMDQ1OGQNCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzI6MTVdICAgZ2ZuOiAwMDAwNDU4ZSAgbWZuOiAwMDAwNDU4ZQ0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoxNV0gICBnZm46IDAwMDA0NThmICBtZm46IDAw
MDA0NThmDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjE1XSAgIGdmbjogMDAwMDQ1OTAg
IG1mbjogMDAwMDQ1OTANCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MTVdICAgZ2ZuOiAw
MDAwNDU5MSAgbWZuOiAwMDAwNDU5MQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoxNV0g
ICBnZm46IDAwMDA0NTkyICBtZm46IDAwMDA0NTkyDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMyOjE1XSAgIGdmbjogMDAwMDQ1OTMgIG1mbjogMDAwMDQ1OTMNCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzI6MTVdICAgZ2ZuOiAwMDAwNDU5NCAgbWZuOiAwMDAwNDU5NA0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMjoxNV0gICBnZm46IDAwMDA0NTk1ICBtZm46IDAwMDA0NTk1
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjE1XSAgIGdmbjogMDAwMDQ1OTYgIG1mbjog
MDAwMDQ1OTYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MTVdICAgZ2ZuOiAwMDAwNDU5
NyAgbWZuOiAwMDAwNDU5Nw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoxNV0gICBnZm46
IDAwMDA0NTk4ICBtZm46IDAwMDA0NTk4DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjE1
XSAgIGdmbjogMDAwMDQ1OTkgIG1mbjogMDAwMDQ1OTkNCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzI6MTVdICAgZ2ZuOiAwMDAwNDU5YSAgbWZuOiAwMDAwNDU5YQ0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMjoxNV0gICBnZm46IDAwMDA0NTliICBtZm46IDAwMDA0NTliDQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMyOjE1XSAgIGdmbjogMDAwMDQ1OWMgIG1mbjogMDAwMDQ1
OWMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MTVdICAgZ2ZuOiAwMDAwNDU5ZCAgbWZu
OiAwMDAwNDU5ZA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoxNV0gICBnZm46IDAwMDA0
NTllICBtZm46IDAwMDA0NTllDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjE1XSAgIGdm
bjogMDAwMDQ1OWYgIG1mbjogMDAwMDQ1OWYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6
MTVdICAgZ2ZuOiAwMDAwNDVhMCAgbWZuOiAwMDAwNDVhMA0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMjoxNV0gICBnZm46IDAwMDA0NWExICBtZm46IDAwMDA0NWExDQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMyOjE1XSAgIGdmbjogMDAwMDQ1YTIgIG1mbjogMDAwMDQ1YTINCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MTVdICAgZ2ZuOiAwMDAwNDVhMyAgbWZuOiAwMDAw
NDVhMw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoxNV0gICBnZm46IDAwMDA0NWE0ICBt
Zm46IDAwMDA0NWE0DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjE1XSAgIGdmbjogMDAw
MDQ1YTUgIG1mbjogMDAwMDQ1YTUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MTVdICAg
Z2ZuOiAwMDAwNDVhNiAgbWZuOiAwMDAwNDVhNg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
MjoxNV0gICBnZm46IDAwMDA0NWE3ICBtZm46IDAwMDA0NWE3DQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMyOjE1XSAgIGdmbjogMDAwMDQ1YTggIG1mbjogMDAwMDQ1YTgNCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzI6MTVdICAgZ2ZuOiAwMDAwNDVhOSAgbWZuOiAwMDAwNDVhOQ0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoxNV0gICBnZm46IDAwMDA0NWFhICBtZm46IDAw
MDA0NWFhDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjE1XSAgIGdmbjogMDAwMDQ1YWIg
IG1mbjogMDAwMDQ1YWINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MTVdICAgZ2ZuOiAw
MDAwNDVhYyAgbWZuOiAwMDAwNDVhYw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoxNV0g
ICBnZm46IDAwMDA0NWFkICBtZm46IDAwMDA0NWFkDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMyOjE1XSAgIGdmbjogMDAwMDQ1YWUgIG1mbjogMDAwMDQ1YWUNCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzI6MTVdICAgZ2ZuOiAwMDAwNDVhZiAgbWZuOiAwMDAwNDVhZg0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMjoxNV0gICBnZm46IDAwMDA0NWIwICBtZm46IDAwMDA0NWIw
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjE1XSAgIGdmbjogMDAwMDQ1YjEgIG1mbjog
MDAwMDQ1YjENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MTVdICAgZ2ZuOiAwMDAwNDVi
MiAgbWZuOiAwMDAwNDViMg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoxNV0gICBnZm46
IDAwMDA0NWIzICBtZm46IDAwMDA0NWIzDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjE1
XSAgIGdmbjogMDAwMDQ1YjQgIG1mbjogMDAwMDQ1YjQNCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzI6MTVdICAgZ2ZuOiAwMDAwNDViNSAgbWZuOiAwMDAwNDViNQ0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMjoxNV0gICBnZm46IDAwMDA0NWI2ICBtZm46IDAwMDA0NWI2DQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMyOjE1XSAgIGdmbjogMDAwMDQ1YjcgIG1mbjogMDAwMDQ1
YjcNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MTVdICAgZ2ZuOiAwMDAwNDViOCAgbWZu
OiAwMDAwNDViOA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoxNV0gICBnZm46IDAwMDA0
NWI5ICBtZm46IDAwMDA0NWI5DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjE1XSAgIGdm
bjogMDAwMDQ1YmEgIG1mbjogMDAwMDQ1YmENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6
MTVdICAgZ2ZuOiAwMDAwNDViYiAgbWZuOiAwMDAwNDViYg0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMjoxNl0gICBnZm46IDAwMDA0NWJjICBtZm46IDAwMDA0NWJjDQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMyOjE2XSAgIGdmbjogMDAwMDQ1YmQgIG1mbjogMDAwMDQ1YmQNCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MTZdICAgZ2ZuOiAwMDAwNDViZSAgbWZuOiAwMDAw
NDViZQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoxNl0gICBnZm46IDAwMDA0NWJmICBt
Zm46IDAwMDA0NWJmDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjE2XSAgIGdmbjogMDAw
MDQ1YzAgIG1mbjogMDAwMDQ1YzANCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MTZdICAg
Z2ZuOiAwMDAwNDVjMSAgbWZuOiAwMDAwNDVjMQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
MjoxNl0gICBnZm46IDAwMDA0NWMyICBtZm46IDAwMDA0NWMyDQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMyOjE2XSAgIGdmbjogMDAwMDQ1YzMgIG1mbjogMDAwMDQ1YzMNCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzI6MTZdICAgZ2ZuOiAwMDAwNDVjNCAgbWZuOiAwMDAwNDVjNA0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoxNl0gICBnZm46IDAwMDA0NWM1ICBtZm46IDAw
MDA0NWM1DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjE2XSAgIGdmbjogMDAwMDQ1YzYg
IG1mbjogMDAwMDQ1YzYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MTZdICAgZ2ZuOiAw
MDAwNDVjNyAgbWZuOiAwMDAwNDVjNw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoxNl0g
ICBnZm46IDAwMDA0NWM4ICBtZm46IDAwMDA0NWM4DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMyOjE2XSAgIGdmbjogMDAwMDQ1YzkgIG1mbjogMDAwMDQ1YzkNCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzI6MTZdICAgZ2ZuOiAwMDAwNDVjYSAgbWZuOiAwMDAwNDVjYQ0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMjoxNl0gICBnZm46IDAwMDA0NWNiICBtZm46IDAwMDA0NWNi
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjE2XSAgIGdmbjogMDAwMDQ1Y2MgIG1mbjog
MDAwMDQ1Y2MNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MTZdICAgZ2ZuOiAwMDAwNDVj
ZCAgbWZuOiAwMDAwNDVjZA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoxNl0gICBnZm46
IDAwMDA0NWNlICBtZm46IDAwMDA0NWNlDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjE2
XSAgIGdmbjogMDAwMDQ1Y2YgIG1mbjogMDAwMDQ1Y2YNCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzI6MTZdICAgZ2ZuOiAwMDAwNDVkMCAgbWZuOiAwMDAwNDVkMA0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMjoxNl0gICBnZm46IDAwMDA0NWQxICBtZm46IDAwMDA0NWQxDQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMyOjE2XSAgIGdmbjogMDAwMDQ1ZDIgIG1mbjogMDAwMDQ1
ZDINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MTZdICAgZ2ZuOiAwMDAwNDVkMyAgbWZu
OiAwMDAwNDVkMw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoxNl0gICBnZm46IDAwMDA0
NWQ0ICBtZm46IDAwMDA0NWQ0DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjE2XSAgIGdm
bjogMDAwMDQ1ZDUgIG1mbjogMDAwMDQ1ZDUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6
MTZdICAgZ2ZuOiAwMDAwNDVkNiAgbWZuOiAwMDAwNDVkNg0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMjoxNl0gICBnZm46IDAwMDA0NWQ3ICBtZm46IDAwMDA0NWQ3DQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMyOjE2XSAgIGdmbjogMDAwMDQ1ZDggIG1mbjogMDAwMDQ1ZDgNCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MTZdICAgZ2ZuOiAwMDAwNDVkOSAgbWZuOiAwMDAw
NDVkOQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoxNl0gICBnZm46IDAwMDA0NWRhICBt
Zm46IDAwMDA0NWRhDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjE2XSAgIGdmbjogMDAw
MDQ1ZGIgIG1mbjogMDAwMDQ1ZGINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MTZdICAg
Z2ZuOiAwMDAwNDVkYyAgbWZuOiAwMDAwNDVkYw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
MjoxNl0gICBnZm46IDAwMDA0NWRkICBtZm46IDAwMDA0NWRkDQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMyOjE2XSAgIGdmbjogMDAwMDQ1ZGUgIG1mbjogMDAwMDQ1ZGUNCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzI6MTZdICAgZ2ZuOiAwMDAwNDVkZiAgbWZuOiAwMDAwNDVkZg0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoxNl0gICBnZm46IDAwMDA0NWUwICBtZm46IDAw
MDA0NWUwDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjE2XSAgIGdmbjogMDAwMDQ1ZTEg
IG1mbjogMDAwMDQ1ZTENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MTZdICAgZ2ZuOiAw
MDAwNDVlMiAgbWZuOiAwMDAwNDVlMg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoxNl0g
ICBnZm46IDAwMDA0NWUzICBtZm46IDAwMDA0NWUzDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMyOjE2XSAgIGdmbjogMDAwMDQ1ZTQgIG1mbjogMDAwMDQ1ZTQNCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzI6MTZdICAgZ2ZuOiAwMDAwNDVlNSAgbWZuOiAwMDAwNDVlNQ0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMjoxNl0gICBnZm46IDAwMDA0NWU2ICBtZm46IDAwMDA0NWU2
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjE2XSAgIGdmbjogMDAwMDQ1ZTcgIG1mbjog
MDAwMDQ1ZTcNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MTZdICAgZ2ZuOiAwMDAwNDVl
OCAgbWZuOiAwMDAwNDVlOA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoxNl0gICBnZm46
IDAwMDA0NWU5ICBtZm46IDAwMDA0NWU5DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjE2
XSAgIGdmbjogMDAwMDQ1ZWEgIG1mbjogMDAwMDQ1ZWENCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzI6MTZdICAgZ2ZuOiAwMDAwNDVlYiAgbWZuOiAwMDAwNDVlYg0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMjoxNl0gICBnZm46IDAwMDA0NWVjICBtZm46IDAwMDA0NWVjDQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMyOjE2XSAgIGdmbjogMDAwMDQ1ZWQgIG1mbjogMDAwMDQ1
ZWQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MTZdICAgZ2ZuOiAwMDAwNDVlZSAgbWZu
OiAwMDAwNDVlZQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoxNl0gICBnZm46IDAwMDA0
NWVmICBtZm46IDAwMDA0NWVmDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjE2XSAgIGdm
bjogMDAwMDQ1ZjAgIG1mbjogMDAwMDQ1ZjANCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6
MTZdICAgZ2ZuOiAwMDAwNDVmMSAgbWZuOiAwMDAwNDVmMQ0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMjoxNl0gICBnZm46IDAwMDA0NWYyICBtZm46IDAwMDA0NWYyDQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMyOjE2XSAgIGdmbjogMDAwMDQ1ZjMgIG1mbjogMDAwMDQ1ZjMNCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MTZdICAgZ2ZuOiAwMDAwNDVmNCAgbWZuOiAwMDAw
NDVmNA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoxNl0gICBnZm46IDAwMDA0NWY1ICBt
Zm46IDAwMDA0NWY1DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjE2XSAgIGdmbjogMDAw
MDQ1ZjYgIG1mbjogMDAwMDQ1ZjYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MTZdICAg
Z2ZuOiAwMDAwNDVmNyAgbWZuOiAwMDAwNDVmNw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
MjoxNl0gICBnZm46IDAwMDA0NWY4ICBtZm46IDAwMDA0NWY4DQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMyOjE2XSAgIGdmbjogMDAwMDQ1ZjkgIG1mbjogMDAwMDQ1ZjkNCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzI6MTZdICAgZ2ZuOiAwMDAwNDVmYSAgbWZuOiAwMDAwNDVmYQ0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoxNl0gICBnZm46IDAwMDA0NWZiICBtZm46IDAw
MDA0NWZiDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjE3XSAgIGdmbjogMDAwMDQ1ZmMg
IG1mbjogMDAwMDQ1ZmMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MTddICAgZ2ZuOiAw
MDAwNDVmZCAgbWZuOiAwMDAwNDVmZA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoxN10g
ICBnZm46IDAwMDA0NWZlICBtZm46IDAwMDA0NWZlDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMyOjE3XSAgIGdmbjogMDAwMDQ1ZmYgIG1mbjogMDAwMDQ1ZmYNCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzI6MTddICAgZ2ZuOiAwMDAwNDYwMCAgbWZuOiAwMDAwNDYwMA0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMjoxN10gICBnZm46IDAwMDA0NjAxICBtZm46IDAwMDA0NjAx
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjE3XSAgIGdmbjogMDAwMDQ2MDIgIG1mbjog
MDAwMDQ2MDINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MTddICAgZ2ZuOiAwMDAwNDYw
MyAgbWZuOiAwMDAwNDYwMw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoxN10gICBnZm46
IDAwMDA0NjA0ICBtZm46IDAwMDA0NjA0DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjE3
XSAgIGdmbjogMDAwMDQ2MDUgIG1mbjogMDAwMDQ2MDUNCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzI6MTddICAgZ2ZuOiAwMDAwNDYwNiAgbWZuOiAwMDAwNDYwNg0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMjoxN10gICBnZm46IDAwMDA0NjA3ICBtZm46IDAwMDA0NjA3DQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMyOjE3XSAgIGdmbjogMDAwMDQ2MDggIG1mbjogMDAwMDQ2
MDgNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MTddICAgZ2ZuOiAwMDAwNDYwOSAgbWZu
OiAwMDAwNDYwOQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoxN10gICBnZm46IDAwMDA0
NjBhICBtZm46IDAwMDA0NjBhDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjE3XSAgIGdm
bjogMDAwMDQ2MGIgIG1mbjogMDAwMDQ2MGINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6
MTddICAgZ2ZuOiAwMDAwNDYwYyAgbWZuOiAwMDAwNDYwYw0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMjoxN10gICBnZm46IDAwMDA0NjBkICBtZm46IDAwMDA0NjBkDQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMyOjE3XSAgIGdmbjogMDAwMDQ2MGUgIG1mbjogMDAwMDQ2MGUNCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MTddICAgZ2ZuOiAwMDAwNDYwZiAgbWZuOiAwMDAw
NDYwZg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoxN10gICBnZm46IDAwMDA0NjEwICBt
Zm46IDAwMDA0NjEwDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjE3XSAgIGdmbjogMDAw
MDQ2MTEgIG1mbjogMDAwMDQ2MTENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MTddICAg
Z2ZuOiAwMDAwNDYxMiAgbWZuOiAwMDAwNDYxMg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
MjoxN10gICBnZm46IDAwMDA0NjEzICBtZm46IDAwMDA0NjEzDQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMyOjE3XSAgIGdmbjogMDAwMDQ2MTQgIG1mbjogMDAwMDQ2MTQNCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzI6MTddICAgZ2ZuOiAwMDAwNDYxNSAgbWZuOiAwMDAwNDYxNQ0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoxN10gICBnZm46IDAwMDA0NjE2ICBtZm46IDAw
MDA0NjE2DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjE3XSAgIGdmbjogMDAwMDQ2MTcg
IG1mbjogMDAwMDQ2MTcNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MTddICAgZ2ZuOiAw
MDAwNDYxOCAgbWZuOiAwMDAwNDYxOA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoxN10g
ICBnZm46IDAwMDA0NjE5ICBtZm46IDAwMDA0NjE5DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMyOjE3XSAgIGdmbjogMDAwMDQ2MWEgIG1mbjogMDAwMDQ2MWENCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzI6MTddICAgZ2ZuOiAwMDAwNDYxYiAgbWZuOiAwMDAwNDYxYg0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMjoxN10gICBnZm46IDAwMDA0NjFjICBtZm46IDAwMDA0NjFj
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjE3XSAgIGdmbjogMDAwMDQ2MWQgIG1mbjog
MDAwMDQ2MWQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MTddICAgZ2ZuOiAwMDAwNDYx
ZSAgbWZuOiAwMDAwNDYxZQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoxN10gICBnZm46
IDAwMDA0NjFmICBtZm46IDAwMDA0NjFmDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjE3
XSAgIGdmbjogMDAwMDQ2MjAgIG1mbjogMDAwMDQ2MjANCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzI6MTddICAgZ2ZuOiAwMDAwNDYyMSAgbWZuOiAwMDAwNDYyMQ0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMjoxN10gICBnZm46IDAwMDA0NjIyICBtZm46IDAwMDA0NjIyDQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMyOjE3XSAgIGdmbjogMDAwMDQ2MjMgIG1mbjogMDAwMDQ2
MjMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MTddICAgZ2ZuOiAwMDAwNDYyNCAgbWZu
OiAwMDAwNDYyNA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoxN10gICBnZm46IDAwMDA0
NjI1ICBtZm46IDAwMDA0NjI1DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjE3XSAgIGdm
bjogMDAwMDQ2MjYgIG1mbjogMDAwMDQ2MjYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6
MTddICAgZ2ZuOiAwMDAwNDYyNyAgbWZuOiAwMDAwNDYyNw0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMjoxN10gICBnZm46IDAwMDA0NjI4ICBtZm46IDAwMDA0NjI4DQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMyOjE3XSAgIGdmbjogMDAwMDQ2MjkgIG1mbjogMDAwMDQ2MjkNCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MTddICAgZ2ZuOiAwMDAwNDYyYSAgbWZuOiAwMDAw
NDYyYQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoxN10gICBnZm46IDAwMDA0NjJiICBt
Zm46IDAwMDA0NjJiDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjE3XSAgIGdmbjogMDAw
MDQ2MmMgIG1mbjogMDAwMDQ2MmMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MTddICAg
Z2ZuOiAwMDAwNDYyZCAgbWZuOiAwMDAwNDYyZA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
MjoxN10gICBnZm46IDAwMDA0NjJlICBtZm46IDAwMDA0NjJlDQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMyOjE3XSAgIGdmbjogMDAwMDQ2MmYgIG1mbjogMDAwMDQ2MmYNCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzI6MTddICAgZ2ZuOiAwMDAwNDYzMCAgbWZuOiAwMDAwNDYzMA0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoxN10gICBnZm46IDAwMDA0NjMxICBtZm46IDAw
MDA0NjMxDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjE3XSAgIGdmbjogMDAwMDQ2MzIg
IG1mbjogMDAwMDQ2MzINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MTddICAgZ2ZuOiAw
MDAwNDYzMyAgbWZuOiAwMDAwNDYzMw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoxN10g
ICBnZm46IDAwMDA0NjM0ICBtZm46IDAwMDA0NjM0DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMyOjE3XSAgIGdmbjogMDAwMDQ2MzUgIG1mbjogMDAwMDQ2MzUNCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzI6MTddICAgZ2ZuOiAwMDAwNDYzNiAgbWZuOiAwMDAwNDYzNg0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMjoxN10gICBnZm46IDAwMDA0NjM3ICBtZm46IDAwMDA0NjM3
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjE3XSAgIGdmbjogMDAwMDQ2MzggIG1mbjog
MDAwMDQ2MzgNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MTddICAgZ2ZuOiAwMDAwNDYz
OSAgbWZuOiAwMDAwNDYzOQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoxN10gICBnZm46
IDAwMDA0NjNhICBtZm46IDAwMDA0NjNhDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjE3
XSAgIGdmbjogMDAwMDQ2M2IgIG1mbjogMDAwMDQ2M2INCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzI6MThdICAgZ2ZuOiAwMDAwNDYzYyAgbWZuOiAwMDAwNDYzYw0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMjoxOF0gICBnZm46IDAwMDA0NjNkICBtZm46IDAwMDA0NjNkDQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMyOjE4XSAgIGdmbjogMDAwMDQ2M2UgIG1mbjogMDAwMDQ2
M2UNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MThdICAgZ2ZuOiAwMDAwNDYzZiAgbWZu
OiAwMDAwNDYzZg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoxOF0gICBnZm46IDAwMDA0
NjQwICBtZm46IDAwMDA0NjQwDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjE4XSAgIGdm
bjogMDAwMDQ2NDEgIG1mbjogMDAwMDQ2NDENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6
MThdICAgZ2ZuOiAwMDAwNDY0MiAgbWZuOiAwMDAwNDY0Mg0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMjoxOF0gICBnZm46IDAwMDA0NjQzICBtZm46IDAwMDA0NjQzDQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMyOjE4XSAgIGdmbjogMDAwMDQ2NDQgIG1mbjogMDAwMDQ2NDQNCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MThdICAgZ2ZuOiAwMDAwNDY0NSAgbWZuOiAwMDAw
NDY0NQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoxOF0gICBnZm46IDAwMDA0NjQ2ICBt
Zm46IDAwMDA0NjQ2DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjE4XSAgIGdmbjogMDAw
MDQ2NDcgIG1mbjogMDAwMDQ2NDcNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MThdICAg
Z2ZuOiAwMDAwNDY0OCAgbWZuOiAwMDAwNDY0OA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
MjoxOF0gICBnZm46IDAwMDA0NjQ5ICBtZm46IDAwMDA0NjQ5DQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMyOjE4XSAgIGdmbjogMDAwMDQ2NGEgIG1mbjogMDAwMDQ2NGENCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzI6MThdICAgZ2ZuOiAwMDAwNDY0YiAgbWZuOiAwMDAwNDY0Yg0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoxOF0gICBnZm46IDAwMDA0NjRjICBtZm46IDAw
MDA0NjRjDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjE4XSAgIGdmbjogMDAwMDQ2NGQg
IG1mbjogMDAwMDQ2NGQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MThdICAgZ2ZuOiAw
MDAwNDY0ZSAgbWZuOiAwMDAwNDY0ZQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoxOF0g
ICBnZm46IDAwMDA0NjRmICBtZm46IDAwMDA0NjRmDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMyOjE4XSAgIGdmbjogMDAwMDQ2NTAgIG1mbjogMDAwMDQ2NTANCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzI6MThdICAgZ2ZuOiAwMDAwNDY1MSAgbWZuOiAwMDAwNDY1MQ0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMjoxOF0gICBnZm46IDAwMDA0NjUyICBtZm46IDAwMDA0NjUy
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjE4XSAgIGdmbjogMDAwMDQ2NTMgIG1mbjog
MDAwMDQ2NTMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MThdICAgZ2ZuOiAwMDAwNDY1
NCAgbWZuOiAwMDAwNDY1NA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoxOF0gICBnZm46
IDAwMDA0NjU1ICBtZm46IDAwMDA0NjU1DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjE4
XSAgIGdmbjogMDAwMDQ2NTYgIG1mbjogMDAwMDQ2NTYNCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzI6MThdICAgZ2ZuOiAwMDAwNDY1NyAgbWZuOiAwMDAwNDY1Nw0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMjoxOF0gICBnZm46IDAwMDA0NjU4ICBtZm46IDAwMDA0NjU4DQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMyOjE4XSAgIGdmbjogMDAwMDQ2NTkgIG1mbjogMDAwMDQ2
NTkNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MThdICAgZ2ZuOiAwMDAwNDY1YSAgbWZu
OiAwMDAwNDY1YQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoxOF0gICBnZm46IDAwMDA0
NjViICBtZm46IDAwMDA0NjViDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjE4XSAgIGdm
bjogMDAwMDQ2NWMgIG1mbjogMDAwMDQ2NWMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6
MThdICAgZ2ZuOiAwMDAwNDY1ZCAgbWZuOiAwMDAwNDY1ZA0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMjoxOF0gICBnZm46IDAwMDA0NjVlICBtZm46IDAwMDA0NjVlDQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMyOjE4XSAgIGdmbjogMDAwMDQ2NWYgIG1mbjogMDAwMDQ2NWYNCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MThdICAgZ2ZuOiAwMDAwNDY2MCAgbWZuOiAwMDAw
NDY2MA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoxOF0gICBnZm46IDAwMDA0NjYxICBt
Zm46IDAwMDA0NjYxDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjE4XSAgIGdmbjogMDAw
MDQ2NjIgIG1mbjogMDAwMDQ2NjINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MThdICAg
Z2ZuOiAwMDAwNDY2MyAgbWZuOiAwMDAwNDY2Mw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
MjoxOF0gICBnZm46IDAwMDA0NjY0ICBtZm46IDAwMDA0NjY0DQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMyOjE4XSAgIGdmbjogMDAwMDQ2NjUgIG1mbjogMDAwMDQ2NjUNCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzI6MThdICAgZ2ZuOiAwMDAwNDY2NiAgbWZuOiAwMDAwNDY2Ng0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoxOF0gICBnZm46IDAwMDA0NjY3ICBtZm46IDAw
MDA0NjY3DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjE4XSAgIGdmbjogMDAwMDQ2Njgg
IG1mbjogMDAwMDQ2NjgNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MThdICAgZ2ZuOiAw
MDAwNDY2OSAgbWZuOiAwMDAwNDY2OQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoxOF0g
ICBnZm46IDAwMDA0NjZhICBtZm46IDAwMDA0NjZhDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMyOjE4XSAgIGdmbjogMDAwMDQ2NmIgIG1mbjogMDAwMDQ2NmINCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzI6MThdICAgZ2ZuOiAwMDAwNDY2YyAgbWZuOiAwMDAwNDY2Yw0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMjoxOF0gICBnZm46IDAwMDA0NjZkICBtZm46IDAwMDA0NjZk
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjE4XSAgIGdmbjogMDAwMDQ2NmUgIG1mbjog
MDAwMDQ2NmUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MThdICAgZ2ZuOiAwMDAwNDY2
ZiAgbWZuOiAwMDAwNDY2Zg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoxOF0gICBnZm46
IDAwMDA0NjcwICBtZm46IDAwMDA0NjcwDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjE4
XSAgIGdmbjogMDAwMDQ2NzEgIG1mbjogMDAwMDQ2NzENCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzI6MThdICAgZ2ZuOiAwMDAwNDY3MiAgbWZuOiAwMDAwNDY3Mg0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMjoxOF0gICBnZm46IDAwMDA0NjczICBtZm46IDAwMDA0NjczDQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMyOjE4XSAgIGdmbjogMDAwMDQ2NzQgIG1mbjogMDAwMDQ2
NzQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MThdICAgZ2ZuOiAwMDAwNDY3NSAgbWZu
OiAwMDAwNDY3NQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoxOF0gICBnZm46IDAwMDA0
Njc2ICBtZm46IDAwMDA0Njc2DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjE4XSAgIGdm
bjogMDAwMDQ2NzcgIG1mbjogMDAwMDQ2NzcNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6
MThdICAgZ2ZuOiAwMDAwNDY3OCAgbWZuOiAwMDAwNDY3OA0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMjoxOF0gICBnZm46IDAwMDA0Njc5ICBtZm46IDAwMDA0Njc5DQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMyOjE4XSAgIGdmbjogMDAwMDQ2N2EgIG1mbjogMDAwMDQ2N2ENCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MThdICAgZ2ZuOiAwMDAwNDY3YiAgbWZuOiAwMDAw
NDY3Yg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoxOV0gICBnZm46IDAwMDA0NjdjICBt
Zm46IDAwMDA0NjdjDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjE5XSAgIGdmbjogMDAw
MDQ2N2QgIG1mbjogMDAwMDQ2N2QNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MTldICAg
Z2ZuOiAwMDAwNDY3ZSAgbWZuOiAwMDAwNDY3ZQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
MjoxOV0gICBnZm46IDAwMDA0NjdmICBtZm46IDAwMDA0NjdmDQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMyOjE5XSAgIGdmbjogMDAwMDQ2ODAgIG1mbjogMDAwMDQ2ODANCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzI6MTldICAgZ2ZuOiAwMDAwNDY4MSAgbWZuOiAwMDAwNDY4MQ0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoxOV0gICBnZm46IDAwMDA0NjgyICBtZm46IDAw
MDA0NjgyDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjE5XSAgIGdmbjogMDAwMDQ2ODMg
IG1mbjogMDAwMDQ2ODMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MTldICAgZ2ZuOiAw
MDAwNDY4NCAgbWZuOiAwMDAwNDY4NA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoxOV0g
ICBnZm46IDAwMDA0Njg1ICBtZm46IDAwMDA0Njg1DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMyOjE5XSAgIGdmbjogMDAwMDQ2ODYgIG1mbjogMDAwMDQ2ODYNCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzI6MTldICAgZ2ZuOiAwMDAwNDY4NyAgbWZuOiAwMDAwNDY4Nw0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMjoxOV0gICBnZm46IDAwMDA0Njg4ICBtZm46IDAwMDA0Njg4
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjE5XSAgIGdmbjogMDAwMDQ2ODkgIG1mbjog
MDAwMDQ2ODkNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MTldICAgZ2ZuOiAwMDAwNDY4
YSAgbWZuOiAwMDAwNDY4YQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoxOV0gICBnZm46
IDAwMDA0NjhiICBtZm46IDAwMDA0NjhiDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjE5
XSAgIGdmbjogMDAwMDQ2OGMgIG1mbjogMDAwMDQ2OGMNCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzI6MTldICAgZ2ZuOiAwMDAwNDY4ZCAgbWZuOiAwMDAwNDY4ZA0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMjoxOV0gICBnZm46IDAwMDA0NjhlICBtZm46IDAwMDA0NjhlDQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMyOjE5XSAgIGdmbjogMDAwMDQ2OGYgIG1mbjogMDAwMDQ2
OGYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MTldICAgZ2ZuOiAwMDAwNDY5MCAgbWZu
OiAwMDAwNDY5MA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoxOV0gICBnZm46IDAwMDA0
NjkxICBtZm46IDAwMDA0NjkxDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjE5XSAgIGdm
bjogMDAwMDQ2OTIgIG1mbjogMDAwMDQ2OTINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6
MTldICAgZ2ZuOiAwMDAwNDY5MyAgbWZuOiAwMDAwNDY5Mw0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMjoxOV0gICBnZm46IDAwMDA0Njk0ICBtZm46IDAwMDA0Njk0DQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMyOjE5XSAgIGdmbjogMDAwMDQ2OTUgIG1mbjogMDAwMDQ2OTUNCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MTldICAgZ2ZuOiAwMDAwNDY5NiAgbWZuOiAwMDAw
NDY5Ng0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoxOV0gICBnZm46IDAwMDA0Njk3ICBt
Zm46IDAwMDA0Njk3DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjE5XSAgIGdmbjogMDAw
MDQ2OTggIG1mbjogMDAwMDQ2OTgNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MTldICAg
Z2ZuOiAwMDAwNDY5OSAgbWZuOiAwMDAwNDY5OQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
MjoxOV0gICBnZm46IDAwMDA0NjlhICBtZm46IDAwMDA0NjlhDQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMyOjE5XSAgIGdmbjogMDAwMDQ2OWIgIG1mbjogMDAwMDQ2OWINCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzI6MTldICAgZ2ZuOiAwMDAwNDY5YyAgbWZuOiAwMDAwNDY5Yw0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoxOV0gICBnZm46IDAwMDA0NjlkICBtZm46IDAw
MDA0NjlkDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjE5XSAgIGdmbjogMDAwMDQ2OWUg
IG1mbjogMDAwMDQ2OWUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MTldICAgZ2ZuOiAw
MDAwNDY5ZiAgbWZuOiAwMDAwNDY5Zg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoxOV0g
ICBnZm46IDAwMDA0NmEwICBtZm46IDAwMDA0NmEwDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMyOjE5XSAgIGdmbjogMDAwMDQ2YTEgIG1mbjogMDAwMDQ2YTENCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzI6MTldICAgZ2ZuOiAwMDAwNDZhMiAgbWZuOiAwMDAwNDZhMg0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMjoxOV0gICBnZm46IDAwMDA0NmEzICBtZm46IDAwMDA0NmEz
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjE5XSAgIGdmbjogMDAwMDQ2YTQgIG1mbjog
MDAwMDQ2YTQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MTldICAgZ2ZuOiAwMDAwNDZh
NSAgbWZuOiAwMDAwNDZhNQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoxOV0gICBnZm46
IDAwMDA0NmE2ICBtZm46IDAwMDA0NmE2DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjE5
XSAgIGdmbjogMDAwMDQ2YTcgIG1mbjogMDAwMDQ2YTcNCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzI6MTldICAgZ2ZuOiAwMDAwNDZhOCAgbWZuOiAwMDAwNDZhOA0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMjoxOV0gICBnZm46IDAwMDA0NmE5ICBtZm46IDAwMDA0NmE5DQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMyOjE5XSAgIGdmbjogMDAwMDQ2YWEgIG1mbjogMDAwMDQ2
YWENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MTldICAgZ2ZuOiAwMDAwNDZhYiAgbWZu
OiAwMDAwNDZhYg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoxOV0gICBnZm46IDAwMDA0
NmFjICBtZm46IDAwMDA0NmFjDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjE5XSAgIGdm
bjogMDAwMDQ2YWQgIG1mbjogMDAwMDQ2YWQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6
MTldICAgZ2ZuOiAwMDAwNDZhZSAgbWZuOiAwMDAwNDZhZQ0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMjoxOV0gICBnZm46IDAwMDA0NmFmICBtZm46IDAwMDA0NmFmDQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMyOjE5XSAgIGdmbjogMDAwMDQ2YjAgIG1mbjogMDAwMDQ2YjANCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MTldICAgZ2ZuOiAwMDAwNDZiMSAgbWZuOiAwMDAw
NDZiMQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoxOV0gICBnZm46IDAwMDA0NmIyICBt
Zm46IDAwMDA0NmIyDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjE5XSAgIGdmbjogMDAw
MDQ2YjMgIG1mbjogMDAwMDQ2YjMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MTldICAg
Z2ZuOiAwMDAwNDZiNCAgbWZuOiAwMDAwNDZiNA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
MjoxOV0gICBnZm46IDAwMDA0NmI1ICBtZm46IDAwMDA0NmI1DQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMyOjE5XSAgIGdmbjogMDAwMDQ2YjYgIG1mbjogMDAwMDQ2YjYNCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzI6MTldICAgZ2ZuOiAwMDAwNDZiNyAgbWZuOiAwMDAwNDZiNw0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoxOV0gICBnZm46IDAwMDA0NmI4ICBtZm46IDAw
MDA0NmI4DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjE5XSAgIGdmbjogMDAwMDQ2Yjkg
IG1mbjogMDAwMDQ2YjkNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MTldICAgZ2ZuOiAw
MDAwNDZiYSAgbWZuOiAwMDAwNDZiYQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoxOV0g
ICBnZm46IDAwMDA0NmJiICBtZm46IDAwMDA0NmJiDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMyOjIwXSAgIGdmbjogMDAwMDQ2YmMgIG1mbjogMDAwMDQ2YmMNCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzI6MjBdICAgZ2ZuOiAwMDAwNDZiZCAgbWZuOiAwMDAwNDZiZA0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMjoyMF0gICBnZm46IDAwMDA0NmJlICBtZm46IDAwMDA0NmJl
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjIwXSAgIGdmbjogMDAwMDQ2YmYgIG1mbjog
MDAwMDQ2YmYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MjBdICAgZ2ZuOiAwMDAwNDZj
MCAgbWZuOiAwMDAwNDZjMA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoyMF0gICBnZm46
IDAwMDA0NmMxICBtZm46IDAwMDA0NmMxDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjIw
XSAgIGdmbjogMDAwMDQ2YzIgIG1mbjogMDAwMDQ2YzINCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzI6MjBdICAgZ2ZuOiAwMDAwNDZjMyAgbWZuOiAwMDAwNDZjMw0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMjoyMF0gICBnZm46IDAwMDA0NmM0ICBtZm46IDAwMDA0NmM0DQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMyOjIwXSAgIGdmbjogMDAwMDQ2YzUgIG1mbjogMDAwMDQ2
YzUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MjBdICAgZ2ZuOiAwMDAwNDZjNiAgbWZu
OiAwMDAwNDZjNg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoyMF0gICBnZm46IDAwMDA0
NmM3ICBtZm46IDAwMDA0NmM3DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjIwXSAgIGdm
bjogMDAwMDQ2YzggIG1mbjogMDAwMDQ2YzgNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6
MjBdICAgZ2ZuOiAwMDAwNDZjOSAgbWZuOiAwMDAwNDZjOQ0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMjoyMF0gICBnZm46IDAwMDA0NmNhICBtZm46IDAwMDA0NmNhDQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMyOjIwXSAgIGdmbjogMDAwMDQ2Y2IgIG1mbjogMDAwMDQ2Y2INCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MjBdICAgZ2ZuOiAwMDAwNDZjYyAgbWZuOiAwMDAw
NDZjYw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoyMF0gICBnZm46IDAwMDA0NmNkICBt
Zm46IDAwMDA0NmNkDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjIwXSAgIGdmbjogMDAw
MDQ2Y2UgIG1mbjogMDAwMDQ2Y2UNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MjBdICAg
Z2ZuOiAwMDAwNDZjZiAgbWZuOiAwMDAwNDZjZg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
MjoyMF0gICBnZm46IDAwMDA0NmQwICBtZm46IDAwMDA0NmQwDQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMyOjIwXSAgIGdmbjogMDAwMDQ2ZDEgIG1mbjogMDAwMDQ2ZDENCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzI6MjBdICAgZ2ZuOiAwMDAwNDZkMiAgbWZuOiAwMDAwNDZkMg0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoyMF0gICBnZm46IDAwMDA0NmQzICBtZm46IDAw
MDA0NmQzDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjIwXSAgIGdmbjogMDAwMDQ2ZDQg
IG1mbjogMDAwMDQ2ZDQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MjBdICAgZ2ZuOiAw
MDAwNDZkNSAgbWZuOiAwMDAwNDZkNQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoyMF0g
ICBnZm46IDAwMDA0NmQ2ICBtZm46IDAwMDA0NmQ2DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMyOjIwXSAgIGdmbjogMDAwMDQ2ZDcgIG1mbjogMDAwMDQ2ZDcNCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzI6MjBdICAgZ2ZuOiAwMDAwNDZkOCAgbWZuOiAwMDAwNDZkOA0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMjoyMF0gICBnZm46IDAwMDA0NmQ5ICBtZm46IDAwMDA0NmQ5
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjIwXSAgIGdmbjogMDAwMDQ2ZGEgIG1mbjog
MDAwMDQ2ZGENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MjBdICAgZ2ZuOiAwMDAwNDZk
YiAgbWZuOiAwMDAwNDZkYg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoyMF0gICBnZm46
IDAwMDA0NmRjICBtZm46IDAwMDA0NmRjDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjIw
XSAgIGdmbjogMDAwMDQ2ZGQgIG1mbjogMDAwMDQ2ZGQNCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzI6MjBdICAgZ2ZuOiAwMDAwNDZkZSAgbWZuOiAwMDAwNDZkZQ0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMjoyMF0gICBnZm46IDAwMDA0NmRmICBtZm46IDAwMDA0NmRmDQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMyOjIwXSAgIGdmbjogMDAwMDQ2ZTAgIG1mbjogMDAwMDQ2
ZTANCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MjBdICAgZ2ZuOiAwMDAwNDZlMSAgbWZu
OiAwMDAwNDZlMQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoyMF0gICBnZm46IDAwMDA0
NmUyICBtZm46IDAwMDA0NmUyDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjIwXSAgIGdm
bjogMDAwMDQ2ZTMgIG1mbjogMDAwMDQ2ZTMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6
MjBdICAgZ2ZuOiAwMDAwNDZlNCAgbWZuOiAwMDAwNDZlNA0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMjoyMF0gICBnZm46IDAwMDA0NmU1ICBtZm46IDAwMDA0NmU1DQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMyOjIwXSAgIGdmbjogMDAwMDQ2ZTYgIG1mbjogMDAwMDQ2ZTYNCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MjBdICAgZ2ZuOiAwMDAwNDZlNyAgbWZuOiAwMDAw
NDZlNw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoyMF0gICBnZm46IDAwMDA0NmU4ICBt
Zm46IDAwMDA0NmU4DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjIwXSAgIGdmbjogMDAw
MDQ2ZTkgIG1mbjogMDAwMDQ2ZTkNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MjBdICAg
Z2ZuOiAwMDAwNDZlYSAgbWZuOiAwMDAwNDZlYQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
MjoyMF0gICBnZm46IDAwMDA0NmViICBtZm46IDAwMDA0NmViDQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMyOjIwXSAgIGdmbjogMDAwMDQ2ZWMgIG1mbjogMDAwMDQ2ZWMNCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzI6MjBdICAgZ2ZuOiAwMDAwNDZlZCAgbWZuOiAwMDAwNDZlZA0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoyMF0gICBnZm46IDAwMDA0NmVlICBtZm46IDAw
MDA0NmVlDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjIwXSAgIGdmbjogMDAwMDQ2ZWYg
IG1mbjogMDAwMDQ2ZWYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MjBdICAgZ2ZuOiAw
MDAwNDZmMCAgbWZuOiAwMDAwNDZmMA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoyMF0g
ICBnZm46IDAwMDA0NmYxICBtZm46IDAwMDA0NmYxDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMyOjIwXSAgIGdmbjogMDAwMDQ2ZjIgIG1mbjogMDAwMDQ2ZjINCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzI6MjBdICAgZ2ZuOiAwMDAwNDZmMyAgbWZuOiAwMDAwNDZmMw0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMjoyMF0gICBnZm46IDAwMDA0NmY0ICBtZm46IDAwMDA0NmY0
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjIwXSAgIGdmbjogMDAwMDQ2ZjUgIG1mbjog
MDAwMDQ2ZjUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MjBdICAgZ2ZuOiAwMDAwNDZm
NiAgbWZuOiAwMDAwNDZmNg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoyMF0gICBnZm46
IDAwMDA0NmY3ICBtZm46IDAwMDA0NmY3DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjIw
XSAgIGdmbjogMDAwMDQ2ZjggIG1mbjogMDAwMDQ2ZjgNCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzI6MjBdICAgZ2ZuOiAwMDAwNDZmOSAgbWZuOiAwMDAwNDZmOQ0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMjoyMF0gICBnZm46IDAwMDA0NmZhICBtZm46IDAwMDA0NmZhDQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMyOjIwXSAgIGdmbjogMDAwMDQ2ZmIgIG1mbjogMDAwMDQ2
ZmINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MjFdICAgZ2ZuOiAwMDAwNDZmYyAgbWZu
OiAwMDAwNDZmYw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoyMV0gICBnZm46IDAwMDA0
NmZkICBtZm46IDAwMDA0NmZkDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjIxXSAgIGdm
bjogMDAwMDQ2ZmUgIG1mbjogMDAwMDQ2ZmUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6
MjFdICAgZ2ZuOiAwMDAwNDZmZiAgbWZuOiAwMDAwNDZmZg0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMjoyMV0gICBnZm46IDAwMDA0NzAwICBtZm46IDAwMDA0NzAwDQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMyOjIxXSAgIGdmbjogMDAwMDQ3MDEgIG1mbjogMDAwMDQ3MDENCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MjFdICAgZ2ZuOiAwMDAwNDcwMiAgbWZuOiAwMDAw
NDcwMg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoyMV0gICBnZm46IDAwMDA0NzAzICBt
Zm46IDAwMDA0NzAzDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjIxXSAgIGdmbjogMDAw
MDQ3MDQgIG1mbjogMDAwMDQ3MDQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MjFdICAg
Z2ZuOiAwMDAwNDcwNSAgbWZuOiAwMDAwNDcwNQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
MjoyMV0gICBnZm46IDAwMDA0NzA2ICBtZm46IDAwMDA0NzA2DQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMyOjIxXSAgIGdmbjogMDAwMDQ3MDcgIG1mbjogMDAwMDQ3MDcNCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzI6MjFdICAgZ2ZuOiAwMDAwNDcwOCAgbWZuOiAwMDAwNDcwOA0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoyMV0gICBnZm46IDAwMDA0NzA5ICBtZm46IDAw
MDA0NzA5DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjIxXSAgIGdmbjogMDAwMDQ3MGEg
IG1mbjogMDAwMDQ3MGENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MjFdICAgZ2ZuOiAw
MDAwNDcwYiAgbWZuOiAwMDAwNDcwYg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoyMV0g
ICBnZm46IDAwMDA0NzBjICBtZm46IDAwMDA0NzBjDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMyOjIxXSAgIGdmbjogMDAwMDQ3MGQgIG1mbjogMDAwMDQ3MGQNCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzI6MjFdICAgZ2ZuOiAwMDAwNDcwZSAgbWZuOiAwMDAwNDcwZQ0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMjoyMV0gICBnZm46IDAwMDA0NzBmICBtZm46IDAwMDA0NzBm
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjIxXSAgIGdmbjogMDAwMDQ3MTAgIG1mbjog
MDAwMDQ3MTANCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MjFdICAgZ2ZuOiAwMDAwNDcx
MSAgbWZuOiAwMDAwNDcxMQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoyMV0gICBnZm46
IDAwMDA0NzEyICBtZm46IDAwMDA0NzEyDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjIx
XSAgIGdmbjogMDAwMDQ3MTMgIG1mbjogMDAwMDQ3MTMNCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzI6MjFdICAgZ2ZuOiAwMDAwNDcxNCAgbWZuOiAwMDAwNDcxNA0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMjoyMV0gICBnZm46IDAwMDA0NzE1ICBtZm46IDAwMDA0NzE1DQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMyOjIxXSAgIGdmbjogMDAwMDQ3MTYgIG1mbjogMDAwMDQ3
MTYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MjFdICAgZ2ZuOiAwMDAwNDcxNyAgbWZu
OiAwMDAwNDcxNw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoyMV0gICBnZm46IDAwMDA0
NzE4ICBtZm46IDAwMDA0NzE4DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjIxXSAgIGdm
bjogMDAwMDQ3MTkgIG1mbjogMDAwMDQ3MTkNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6
MjFdICAgZ2ZuOiAwMDAwNDcxYSAgbWZuOiAwMDAwNDcxYQ0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMjoyMV0gICBnZm46IDAwMDA0NzFiICBtZm46IDAwMDA0NzFiDQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMyOjIxXSAgIGdmbjogMDAwMDQ3MWMgIG1mbjogMDAwMDQ3MWMNCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MjFdICAgZ2ZuOiAwMDAwNDcxZCAgbWZuOiAwMDAw
NDcxZA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoyMV0gICBnZm46IDAwMDA0NzFlICBt
Zm46IDAwMDA0NzFlDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjIxXSAgIGdmbjogMDAw
MDQ3MWYgIG1mbjogMDAwMDQ3MWYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MjFdICAg
Z2ZuOiAwMDAwNDcyMCAgbWZuOiAwMDAwNDcyMA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
MjoyMV0gICBnZm46IDAwMDA0NzIxICBtZm46IDAwMDA0NzIxDQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMyOjIxXSAgIGdmbjogMDAwMDQ3MjIgIG1mbjogMDAwMDQ3MjINCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzI6MjFdICAgZ2ZuOiAwMDAwNDcyMyAgbWZuOiAwMDAwNDcyMw0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoyMV0gICBnZm46IDAwMDA0NzI0ICBtZm46IDAw
MDA0NzI0DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjIxXSAgIGdmbjogMDAwMDQ3MjUg
IG1mbjogMDAwMDQ3MjUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MjFdICAgZ2ZuOiAw
MDAwNDcyNiAgbWZuOiAwMDAwNDcyNg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoyMV0g
ICBnZm46IDAwMDA0NzI3ICBtZm46IDAwMDA0NzI3DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMyOjIxXSAgIGdmbjogMDAwMDQ3MjggIG1mbjogMDAwMDQ3MjgNCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzI6MjFdICAgZ2ZuOiAwMDAwNDcyOSAgbWZuOiAwMDAwNDcyOQ0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMjoyMV0gICBnZm46IDAwMDA0NzJhICBtZm46IDAwMDA0NzJh
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjIxXSAgIGdmbjogMDAwMDQ3MmIgIG1mbjog
MDAwMDQ3MmINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MjFdICAgZ2ZuOiAwMDAwNDcy
YyAgbWZuOiAwMDAwNDcyYw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoyMV0gICBnZm46
IDAwMDA0NzJkICBtZm46IDAwMDA0NzJkDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjIx
XSAgIGdmbjogMDAwMDQ3MmUgIG1mbjogMDAwMDQ3MmUNCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzI6MjFdICAgZ2ZuOiAwMDAwNDcyZiAgbWZuOiAwMDAwNDcyZg0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMjoyMV0gICBnZm46IDAwMDA0NzMwICBtZm46IDAwMDA0NzMwDQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMyOjIxXSAgIGdmbjogMDAwMDQ3MzEgIG1mbjogMDAwMDQ3
MzENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MjFdICAgZ2ZuOiAwMDAwNDczMiAgbWZu
OiAwMDAwNDczMg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoyMV0gICBnZm46IDAwMDA0
NzMzICBtZm46IDAwMDA0NzMzDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjIxXSAgIGdm
bjogMDAwMDQ3MzQgIG1mbjogMDAwMDQ3MzQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6
MjFdICAgZ2ZuOiAwMDAwNDczNSAgbWZuOiAwMDAwNDczNQ0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMjoyMV0gICBnZm46IDAwMDA0NzM2ICBtZm46IDAwMDA0NzM2DQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMyOjIxXSAgIGdmbjogMDAwMDQ3MzcgIG1mbjogMDAwMDQ3MzcNCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MjFdICAgZ2ZuOiAwMDAwNDczOCAgbWZuOiAwMDAw
NDczOA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoyMV0gICBnZm46IDAwMDA0NzM5ICBt
Zm46IDAwMDA0NzM5DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjIxXSAgIGdmbjogMDAw
MDQ3M2EgIG1mbjogMDAwMDQ3M2ENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MjFdICAg
Z2ZuOiAwMDAwNDczYiAgbWZuOiAwMDAwNDczYg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
MjoyMl0gICBnZm46IDAwMDA0NzNjICBtZm46IDAwMDA0NzNjDQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMyOjIyXSAgIGdmbjogMDAwMDQ3M2QgIG1mbjogMDAwMDQ3M2QNCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzI6MjJdICAgZ2ZuOiAwMDAwNDczZSAgbWZuOiAwMDAwNDczZQ0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoyMl0gICBnZm46IDAwMDA0NzNmICBtZm46IDAw
MDA0NzNmDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjIyXSAgIGdmbjogMDAwMDQ3NDAg
IG1mbjogMDAwMDQ3NDANCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MjJdICAgZ2ZuOiAw
MDAwNDc0MSAgbWZuOiAwMDAwNDc0MQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoyMl0g
ICBnZm46IDAwMDA0NzQyICBtZm46IDAwMDA0NzQyDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMyOjIyXSAgIGdmbjogMDAwMDQ3NDMgIG1mbjogMDAwMDQ3NDMNCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzI6MjJdICAgZ2ZuOiAwMDAwNDc0NCAgbWZuOiAwMDAwNDc0NA0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMjoyMl0gICBnZm46IDAwMDA0NzQ1ICBtZm46IDAwMDA0NzQ1
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjIyXSAgIGdmbjogMDAwMDQ3NDYgIG1mbjog
MDAwMDQ3NDYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MjJdICAgZ2ZuOiAwMDAwNDc0
NyAgbWZuOiAwMDAwNDc0Nw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoyMl0gICBnZm46
IDAwMDA0NzQ4ICBtZm46IDAwMDA0NzQ4DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjIy
XSAgIGdmbjogMDAwMDQ3NDkgIG1mbjogMDAwMDQ3NDkNCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzI6MjJdICAgZ2ZuOiAwMDAwNDc0YSAgbWZuOiAwMDAwNDc0YQ0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMjoyMl0gICBnZm46IDAwMDA0NzRiICBtZm46IDAwMDA0NzRiDQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMyOjIyXSAgIGdmbjogMDAwMDQ3NGMgIG1mbjogMDAwMDQ3
NGMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MjJdICAgZ2ZuOiAwMDAwNDc0ZCAgbWZu
OiAwMDAwNDc0ZA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoyMl0gICBnZm46IDAwMDA0
NzRlICBtZm46IDAwMDA0NzRlDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjIyXSAgIGdm
bjogMDAwMDQ3NGYgIG1mbjogMDAwMDQ3NGYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6
MjJdICAgZ2ZuOiAwMDAwNDc1MCAgbWZuOiAwMDAwNDc1MA0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMjoyMl0gICBnZm46IDAwMDA0NzUxICBtZm46IDAwMDA0NzUxDQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMyOjIyXSAgIGdmbjogMDAwMDQ3NTIgIG1mbjogMDAwMDQ3NTINCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MjJdICAgZ2ZuOiAwMDAwNDc1MyAgbWZuOiAwMDAw
NDc1Mw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoyMl0gICBnZm46IDAwMDA0NzU0ICBt
Zm46IDAwMDA0NzU0DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjIyXSAgIGdmbjogMDAw
MDQ3NTUgIG1mbjogMDAwMDQ3NTUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MjJdICAg
Z2ZuOiAwMDAwNDc1NiAgbWZuOiAwMDAwNDc1Ng0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
MjoyMl0gICBnZm46IDAwMDA0NzU3ICBtZm46IDAwMDA0NzU3DQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMyOjIyXSAgIGdmbjogMDAwMDQ3NTggIG1mbjogMDAwMDQ3NTgNCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzI6MjJdICAgZ2ZuOiAwMDAwNDc1OSAgbWZuOiAwMDAwNDc1OQ0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoyMl0gICBnZm46IDAwMDA0NzVhICBtZm46IDAw
MDA0NzVhDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjIyXSAgIGdmbjogMDAwMDQ3NWIg
IG1mbjogMDAwMDQ3NWINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MjJdICAgZ2ZuOiAw
MDAwNDc1YyAgbWZuOiAwMDAwNDc1Yw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoyMl0g
ICBnZm46IDAwMDA0NzVkICBtZm46IDAwMDA0NzVkDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMyOjIyXSAgIGdmbjogMDAwMDQ3NWUgIG1mbjogMDAwMDQ3NWUNCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzI6MjJdICAgZ2ZuOiAwMDAwNDc1ZiAgbWZuOiAwMDAwNDc1Zg0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMjoyMl0gICBnZm46IDAwMDA0NzYwICBtZm46IDAwMDA0NzYw
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjIyXSAgIGdmbjogMDAwMDQ3NjEgIG1mbjog
MDAwMDQ3NjENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MjJdICAgZ2ZuOiAwMDAwNDc2
MiAgbWZuOiAwMDAwNDc2Mg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoyMl0gICBnZm46
IDAwMDA0NzYzICBtZm46IDAwMDA0NzYzDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjIy
XSAgIGdmbjogMDAwMDQ3NjQgIG1mbjogMDAwMDQ3NjQNCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzI6MjJdICAgZ2ZuOiAwMDAwNDc2NSAgbWZuOiAwMDAwNDc2NQ0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMjoyMl0gICBnZm46IDAwMDA0NzY2ICBtZm46IDAwMDA0NzY2DQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMyOjIyXSAgIGdmbjogMDAwMDQ3NjcgIG1mbjogMDAwMDQ3
NjcNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MjJdICAgZ2ZuOiAwMDAwNDc2OCAgbWZu
OiAwMDAwNDc2OA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoyMl0gICBnZm46IDAwMDA0
NzY5ICBtZm46IDAwMDA0NzY5DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjIyXSAgIGdm
bjogMDAwMDQ3NmEgIG1mbjogMDAwMDQ3NmENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6
MjJdICAgZ2ZuOiAwMDAwNDc2YiAgbWZuOiAwMDAwNDc2Yg0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMjoyMl0gICBnZm46IDAwMDA0NzZjICBtZm46IDAwMDA0NzZjDQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMyOjIyXSAgIGdmbjogMDAwMDQ3NmQgIG1mbjogMDAwMDQ3NmQNCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MjJdICAgZ2ZuOiAwMDAwNDc2ZSAgbWZuOiAwMDAw
NDc2ZQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoyMl0gICBnZm46IDAwMDA0NzZmICBt
Zm46IDAwMDA0NzZmDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjIyXSAgIGdmbjogMDAw
MDQ3NzAgIG1mbjogMDAwMDQ3NzANCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MjJdICAg
Z2ZuOiAwMDAwNDc3MSAgbWZuOiAwMDAwNDc3MQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
MjoyMl0gICBnZm46IDAwMDA0NzcyICBtZm46IDAwMDA0NzcyDQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMyOjIyXSAgIGdmbjogMDAwMDQ3NzMgIG1mbjogMDAwMDQ3NzMNCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzI6MjJdICAgZ2ZuOiAwMDAwNDc3NCAgbWZuOiAwMDAwNDc3NA0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoyMl0gICBnZm46IDAwMDA0Nzc1ICBtZm46IDAw
MDA0Nzc1DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjIyXSAgIGdmbjogMDAwMDQ3NzYg
IG1mbjogMDAwMDQ3NzYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MjJdICAgZ2ZuOiAw
MDAwNDc3NyAgbWZuOiAwMDAwNDc3Nw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoyMl0g
ICBnZm46IDAwMDA0Nzc4ICBtZm46IDAwMDA0Nzc4DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMyOjIyXSAgIGdmbjogMDAwMDQ3NzkgIG1mbjogMDAwMDQ3NzkNCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzI6MjJdICAgZ2ZuOiAwMDAwNDc3YSAgbWZuOiAwMDAwNDc3YQ0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMjoyMl0gICBnZm46IDAwMDA0NzdiICBtZm46IDAwMDA0Nzdi
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjIyXSAgIGdmbjogMDAwMDQ3N2MgIG1mbjog
MDAwMDQ3N2MNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MjNdICAgZ2ZuOiAwMDAwNDc3
ZCAgbWZuOiAwMDAwNDc3ZA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoyM10gICBnZm46
IDAwMDA0NzdlICBtZm46IDAwMDA0NzdlDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjIz
XSAgIGdmbjogMDAwMDQ3N2YgIG1mbjogMDAwMDQ3N2YNCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzI6MjNdICAgZ2ZuOiAwMDAwNDc4MCAgbWZuOiAwMDAwNDc4MA0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMjoyM10gICBnZm46IDAwMDA0NzgxICBtZm46IDAwMDA0NzgxDQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMyOjIzXSAgIGdmbjogMDAwMDQ3ODIgIG1mbjogMDAwMDQ3
ODINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MjNdICAgZ2ZuOiAwMDAwNDc4MyAgbWZu
OiAwMDAwNDc4Mw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoyM10gICBnZm46IDAwMDA0
Nzg0ICBtZm46IDAwMDA0Nzg0DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjIzXSAgIGdm
bjogMDAwMDQ3ODUgIG1mbjogMDAwMDQ3ODUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6
MjNdICAgZ2ZuOiAwMDAwNDc4NiAgbWZuOiAwMDAwNDc4Ng0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMjoyM10gICBnZm46IDAwMDA0Nzg3ICBtZm46IDAwMDA0Nzg3DQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMyOjIzXSAgIGdmbjogMDAwMDQ3ODggIG1mbjogMDAwMDQ3ODgNCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MjNdICAgZ2ZuOiAwMDAwNDc4OSAgbWZuOiAwMDAw
NDc4OQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoyM10gICBnZm46IDAwMDA0NzhhICBt
Zm46IDAwMDA0NzhhDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjIzXSAgIGdmbjogMDAw
MDQ3OGIgIG1mbjogMDAwMDQ3OGINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MjNdICAg
Z2ZuOiAwMDAwNDc4YyAgbWZuOiAwMDAwNDc4Yw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
MjoyM10gICBnZm46IDAwMDA0NzhkICBtZm46IDAwMDA0NzhkDQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMyOjIzXSAgIGdmbjogMDAwMDQ3OGUgIG1mbjogMDAwMDQ3OGUNCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzI6MjNdICAgZ2ZuOiAwMDAwNDc4ZiAgbWZuOiAwMDAwNDc4Zg0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoyM10gICBnZm46IDAwMDA0NzkwICBtZm46IDAw
MDA0NzkwDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjIzXSAgIGdmbjogMDAwMDQ3OTEg
IG1mbjogMDAwMDQ3OTENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MjNdICAgZ2ZuOiAw
MDAwNDc5MiAgbWZuOiAwMDAwNDc5Mg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoyM10g
ICBnZm46IDAwMDA0NzkzICBtZm46IDAwMDA0NzkzDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMyOjIzXSAgIGdmbjogMDAwMDQ3OTQgIG1mbjogMDAwMDQ3OTQNCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzI6MjNdICAgZ2ZuOiAwMDAwNDc5NSAgbWZuOiAwMDAwNDc5NQ0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMjoyM10gICBnZm46IDAwMDA0Nzk2ICBtZm46IDAwMDA0Nzk2
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjIzXSAgIGdmbjogMDAwMDQ3OTcgIG1mbjog
MDAwMDQ3OTcNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MjNdICAgZ2ZuOiAwMDAwNDc5
OCAgbWZuOiAwMDAwNDc5OA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoyM10gICBnZm46
IDAwMDA0Nzk5ICBtZm46IDAwMDA0Nzk5DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjIz
XSAgIGdmbjogMDAwMDQ3OWEgIG1mbjogMDAwMDQ3OWENCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzI6MjNdICAgZ2ZuOiAwMDAwNDc5YiAgbWZuOiAwMDAwNDc5Yg0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMjoyM10gICBnZm46IDAwMDA0NzljICBtZm46IDAwMDA0NzljDQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMyOjIzXSAgIGdmbjogMDAwMDQ3OWQgIG1mbjogMDAwMDQ3
OWQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MjNdICAgZ2ZuOiAwMDAwNDc5ZSAgbWZu
OiAwMDAwNDc5ZQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoyM10gICBnZm46IDAwMDA0
NzlmICBtZm46IDAwMDA0NzlmDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjIzXSAgIGdm
bjogMDAwMDQ3YTAgIG1mbjogMDAwMDQ3YTANCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6
MjNdICAgZ2ZuOiAwMDAwNDdhMSAgbWZuOiAwMDAwNDdhMQ0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMjoyM10gICBnZm46IDAwMDA0N2EyICBtZm46IDAwMDA0N2EyDQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMyOjIzXSAgIGdmbjogMDAwMDQ3YTMgIG1mbjogMDAwMDQ3YTMNCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MjNdICAgZ2ZuOiAwMDAwNDdhNCAgbWZuOiAwMDAw
NDdhNA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoyM10gICBnZm46IDAwMDA0N2E1ICBt
Zm46IDAwMDA0N2E1DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjIzXSAgIGdmbjogMDAw
MDQ3YTYgIG1mbjogMDAwMDQ3YTYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MjNdICAg
Z2ZuOiAwMDAwNDdhNyAgbWZuOiAwMDAwNDdhNw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
MjoyM10gICBnZm46IDAwMDA0N2E4ICBtZm46IDAwMDA0N2E4DQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMyOjIzXSAgIGdmbjogMDAwMDQ3YTkgIG1mbjogMDAwMDQ3YTkNCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzI6MjNdICAgZ2ZuOiAwMDAwNDdhYSAgbWZuOiAwMDAwNDdhYQ0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoyM10gICBnZm46IDAwMDA0N2FiICBtZm46IDAw
MDA0N2FiDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjIzXSAgIGdmbjogMDAwMDQ3YWMg
IG1mbjogMDAwMDQ3YWMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MjNdICAgZ2ZuOiAw
MDAwNDdhZCAgbWZuOiAwMDAwNDdhZA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoyM10g
ICBnZm46IDAwMDA0N2FlICBtZm46IDAwMDA0N2FlDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMyOjIzXSAgIGdmbjogMDAwMDQ3YWYgIG1mbjogMDAwMDQ3YWYNCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzI6MjNdICAgZ2ZuOiAwMDAwNDdiMCAgbWZuOiAwMDAwNDdiMA0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMjoyM10gICBnZm46IDAwMDA0N2IxICBtZm46IDAwMDA0N2Ix
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjIzXSAgIGdmbjogMDAwMDQ3YjIgIG1mbjog
MDAwMDQ3YjINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MjNdICAgZ2ZuOiAwMDAwNDdi
MyAgbWZuOiAwMDAwNDdiMw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoyM10gICBnZm46
IDAwMDA0N2I0ICBtZm46IDAwMDA0N2I0DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjIz
XSAgIGdmbjogMDAwMDQ3YjUgIG1mbjogMDAwMDQ3YjUNCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzI6MjNdICAgZ2ZuOiAwMDAwNDdiNiAgbWZuOiAwMDAwNDdiNg0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMjoyM10gICBnZm46IDAwMDA0N2I3ICBtZm46IDAwMDA0N2I3DQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMyOjIzXSAgIGdmbjogMDAwMDQ3YjggIG1mbjogMDAwMDQ3
YjgNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MjNdICAgZ2ZuOiAwMDAwNDdiOSAgbWZu
OiAwMDAwNDdiOQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoyM10gICBnZm46IDAwMDA0
N2JhICBtZm46IDAwMDA0N2JhDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjIzXSAgIGdm
bjogMDAwMDQ3YmIgIG1mbjogMDAwMDQ3YmINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6
MjNdICAgZ2ZuOiAwMDAwNDdiYyAgbWZuOiAwMDAwNDdiYw0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMjoyNF0gICBnZm46IDAwMDA0N2JkICBtZm46IDAwMDA0N2JkDQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMyOjI0XSAgIGdmbjogMDAwMDQ3YmUgIG1mbjogMDAwMDQ3YmUNCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MjRdICAgZ2ZuOiAwMDAwNDdiZiAgbWZuOiAwMDAw
NDdiZg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoyNF0gICBnZm46IDAwMDA0N2MwICBt
Zm46IDAwMDA0N2MwDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjI0XSAgIGdmbjogMDAw
MDQ3YzEgIG1mbjogMDAwMDQ3YzENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MjRdICAg
Z2ZuOiAwMDAwNDdjMiAgbWZuOiAwMDAwNDdjMg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
MjoyNF0gICBnZm46IDAwMDA0N2MzICBtZm46IDAwMDA0N2MzDQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMyOjI0XSAgIGdmbjogMDAwMDQ3YzQgIG1mbjogMDAwMDQ3YzQNCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzI6MjRdICAgZ2ZuOiAwMDAwNDdjNSAgbWZuOiAwMDAwNDdjNQ0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoyNF0gICBnZm46IDAwMDA0N2M2ICBtZm46IDAw
MDA0N2M2DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjI0XSAgIGdmbjogMDAwMDQ3Yzcg
IG1mbjogMDAwMDQ3YzcNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MjRdICAgZ2ZuOiAw
MDAwNDdjOCAgbWZuOiAwMDAwNDdjOA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoyNF0g
ICBnZm46IDAwMDA0N2M5ICBtZm46IDAwMDA0N2M5DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMyOjI0XSAgIGdmbjogMDAwMDQ3Y2EgIG1mbjogMDAwMDQ3Y2ENCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzI6MjRdICAgZ2ZuOiAwMDAwNDdjYiAgbWZuOiAwMDAwNDdjYg0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMjoyNF0gICBnZm46IDAwMDA0N2NjICBtZm46IDAwMDA0N2Nj
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjI0XSAgIGdmbjogMDAwMDQ3Y2QgIG1mbjog
MDAwMDQ3Y2QNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MjRdICAgZ2ZuOiAwMDAwNDdj
ZSAgbWZuOiAwMDAwNDdjZQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoyNF0gICBnZm46
IDAwMDA0N2NmICBtZm46IDAwMDA0N2NmDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjI0
XSAgIGdmbjogMDAwMDQ3ZDAgIG1mbjogMDAwMDQ3ZDANCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzI6MjRdICAgZ2ZuOiAwMDAwNDdkMSAgbWZuOiAwMDAwNDdkMQ0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMjoyNF0gICBnZm46IDAwMDA0N2QyICBtZm46IDAwMDA0N2QyDQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMyOjI0XSAgIGdmbjogMDAwMDQ3ZDMgIG1mbjogMDAwMDQ3
ZDMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MjRdICAgZ2ZuOiAwMDAwNDdkNCAgbWZu
OiAwMDAwNDdkNA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoyNF0gICBnZm46IDAwMDA0
N2Q1ICBtZm46IDAwMDA0N2Q1DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjI0XSAgIGdm
bjogMDAwMDQ3ZDYgIG1mbjogMDAwMDQ3ZDYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6
MjRdICAgZ2ZuOiAwMDAwNDdkNyAgbWZuOiAwMDAwNDdkNw0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMjoyNF0gICBnZm46IDAwMDA0N2Q4ICBtZm46IDAwMDA0N2Q4DQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMyOjI0XSAgIGdmbjogMDAwMDQ3ZDkgIG1mbjogMDAwMDQ3ZDkNCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MjRdICAgZ2ZuOiAwMDAwNDdkYSAgbWZuOiAwMDAw
NDdkYQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoyNF0gICBnZm46IDAwMDA0N2RiICBt
Zm46IDAwMDA0N2RiDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjI0XSAgIGdmbjogMDAw
MDQ3ZGMgIG1mbjogMDAwMDQ3ZGMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MjRdICAg
Z2ZuOiAwMDAwNDdkZCAgbWZuOiAwMDAwNDdkZA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
MjoyNF0gICBnZm46IDAwMDA0N2RlICBtZm46IDAwMDA0N2RlDQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMyOjI0XSAgIGdmbjogMDAwMDQ3ZGYgIG1mbjogMDAwMDQ3ZGYNCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzI6MjRdICAgZ2ZuOiAwMDAwNDdlMCAgbWZuOiAwMDAwNDdlMA0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoyNF0gICBnZm46IDAwMDA0N2UxICBtZm46IDAw
MDA0N2UxDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjI0XSAgIGdmbjogMDAwMDQ3ZTIg
IG1mbjogMDAwMDQ3ZTINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MjRdICAgZ2ZuOiAw
MDAwNDdlMyAgbWZuOiAwMDAwNDdlMw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoyNF0g
ICBnZm46IDAwMDA0N2U0ICBtZm46IDAwMDA0N2U0DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMyOjI0XSAgIGdmbjogMDAwMDQ3ZTUgIG1mbjogMDAwMDQ3ZTUNCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzI6MjRdICAgZ2ZuOiAwMDAwNDdlNiAgbWZuOiAwMDAwNDdlNg0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMjoyNF0gICBnZm46IDAwMDA0N2U3ICBtZm46IDAwMDA0N2U3
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjI0XSAgIGdmbjogMDAwMDQ3ZTggIG1mbjog
MDAwMDQ3ZTgNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MjRdICAgZ2ZuOiAwMDAwNDdl
OSAgbWZuOiAwMDAwNDdlOQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoyNF0gICBnZm46
IDAwMDA0N2VhICBtZm46IDAwMDA0N2VhDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjI0
XSAgIGdmbjogMDAwMDQ3ZWIgIG1mbjogMDAwMDQ3ZWINCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzI6MjRdICAgZ2ZuOiAwMDAwNDdlYyAgbWZuOiAwMDAwNDdlYw0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMjoyNF0gICBnZm46IDAwMDA0N2VkICBtZm46IDAwMDA0N2VkDQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMyOjI0XSAgIGdmbjogMDAwMDQ3ZWUgIG1mbjogMDAwMDQ3
ZWUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MjRdICAgZ2ZuOiAwMDAwNDdlZiAgbWZu
OiAwMDAwNDdlZg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoyNF0gICBnZm46IDAwMDA0
N2YwICBtZm46IDAwMDA0N2YwDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjI0XSAgIGdm
bjogMDAwMDQ3ZjEgIG1mbjogMDAwMDQ3ZjENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6
MjRdICAgZ2ZuOiAwMDAwNDdmMiAgbWZuOiAwMDAwNDdmMg0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMjoyNF0gICBnZm46IDAwMDA0N2YzICBtZm46IDAwMDA0N2YzDQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMyOjI0XSAgIGdmbjogMDAwMDQ3ZjQgIG1mbjogMDAwMDQ3ZjQNCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MjRdICAgZ2ZuOiAwMDAwNDdmNSAgbWZuOiAwMDAw
NDdmNQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoyNF0gICBnZm46IDAwMDA0N2Y2ICBt
Zm46IDAwMDA0N2Y2DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjI0XSAgIGdmbjogMDAw
MDQ3ZjcgIG1mbjogMDAwMDQ3ZjcNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MjRdICAg
Z2ZuOiAwMDAwNDdmOCAgbWZuOiAwMDAwNDdmOA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
MjoyNF0gICBnZm46IDAwMDA0N2Y5ICBtZm46IDAwMDA0N2Y5DQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMyOjI0XSAgIGdmbjogMDAwMDQ3ZmEgIG1mbjogMDAwMDQ3ZmENCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzI6MjRdICAgZ2ZuOiAwMDAwNDdmYiAgbWZuOiAwMDAwNDdmYg0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoyNF0gICBnZm46IDAwMDA0N2ZjICBtZm46IDAw
MDA0N2ZjDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjI1XSAgIGdmbjogMDAwMDQ3ZmQg
IG1mbjogMDAwMDQ3ZmQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MjVdICAgZ2ZuOiAw
MDAwNDdmZSAgbWZuOiAwMDAwNDdmZQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoyNV0g
ICBnZm46IDAwMDA0N2ZmICBtZm46IDAwMDA0N2ZmDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMyOjI1XSAgIGdmbjogMDAwMDQ4MDAgIG1mbjogMDAwMDQ4MDANCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzI6MjVdICAgZ2ZuOiAwMDAwNDgwMSAgbWZuOiAwMDAwNDgwMQ0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMjoyNV0gICBnZm46IDAwMDA0ODAyICBtZm46IDAwMDA0ODAy
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjI1XSAgIGdmbjogMDAwMDQ4MDMgIG1mbjog
MDAwMDQ4MDMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MjVdICAgZ2ZuOiAwMDAwNDgw
NCAgbWZuOiAwMDAwNDgwNA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoyNV0gICBnZm46
IDAwMDA0ODA1ICBtZm46IDAwMDA0ODA1DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjI1
XSAgIGdmbjogMDAwMDQ4MDYgIG1mbjogMDAwMDQ4MDYNCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzI6MjVdICAgZ2ZuOiAwMDAwNDgwNyAgbWZuOiAwMDAwNDgwNw0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMjoyNV0gICBnZm46IDAwMDA0ODA4ICBtZm46IDAwMDA0ODA4DQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMyOjI1XSAgIGdmbjogMDAwMDQ4MDkgIG1mbjogMDAwMDQ4
MDkNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MjVdICAgZ2ZuOiAwMDAwNDgwYSAgbWZu
OiAwMDAwNDgwYQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoyNV0gICBnZm46IDAwMDA0
ODBiICBtZm46IDAwMDA0ODBiDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjI1XSAgIGdm
bjogMDAwMDQ4MGMgIG1mbjogMDAwMDQ4MGMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6
MjVdICAgZ2ZuOiAwMDAwNDgwZCAgbWZuOiAwMDAwNDgwZA0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMjoyNV0gICBnZm46IDAwMDA0ODBlICBtZm46IDAwMDA0ODBlDQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMyOjI1XSAgIGdmbjogMDAwMDQ4MGYgIG1mbjogMDAwMDQ4MGYNCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MjVdICAgZ2ZuOiAwMDAwNDgxMCAgbWZuOiAwMDAw
NDgxMA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoyNV0gICBnZm46IDAwMDA0ODExICBt
Zm46IDAwMDA0ODExDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjI1XSAgIGdmbjogMDAw
MDQ4MTIgIG1mbjogMDAwMDQ4MTINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MjVdICAg
Z2ZuOiAwMDAwNDgxMyAgbWZuOiAwMDAwNDgxMw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
MjoyNV0gICBnZm46IDAwMDA0ODE0ICBtZm46IDAwMDA0ODE0DQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMyOjI1XSAgIGdmbjogMDAwMDQ4MTUgIG1mbjogMDAwMDQ4MTUNCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzI6MjVdICAgZ2ZuOiAwMDAwNDgxNiAgbWZuOiAwMDAwNDgxNg0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoyNV0gICBnZm46IDAwMDA0ODE3ICBtZm46IDAw
MDA0ODE3DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjI1XSAgIGdmbjogMDAwMDQ4MTgg
IG1mbjogMDAwMDQ4MTgNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MjVdICAgZ2ZuOiAw
MDAwNDgxOSAgbWZuOiAwMDAwNDgxOQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoyNV0g
ICBnZm46IDAwMDA0ODFhICBtZm46IDAwMDA0ODFhDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMyOjI1XSAgIGdmbjogMDAwMDQ4MWIgIG1mbjogMDAwMDQ4MWINCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzI6MjVdICAgZ2ZuOiAwMDAwNDgxYyAgbWZuOiAwMDAwNDgxYw0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMjoyNV0gICBnZm46IDAwMDA0ODFkICBtZm46IDAwMDA0ODFk
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjI1XSAgIGdmbjogMDAwMDQ4MWUgIG1mbjog
MDAwMDQ4MWUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MjVdICAgZ2ZuOiAwMDAwNDgx
ZiAgbWZuOiAwMDAwNDgxZg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoyNV0gICBnZm46
IDAwMDA0ODIwICBtZm46IDAwMDA0ODIwDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjI1
XSAgIGdmbjogMDAwMDQ4MjEgIG1mbjogMDAwMDQ4MjENCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzI6MjVdICAgZ2ZuOiAwMDAwNDgyMiAgbWZuOiAwMDAwNDgyMg0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMjoyNV0gICBnZm46IDAwMDA0ODIzICBtZm46IDAwMDA0ODIzDQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMyOjI1XSAgIGdmbjogMDAwMDQ4MjQgIG1mbjogMDAwMDQ4
MjQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MjVdICAgZ2ZuOiAwMDAwNDgyNSAgbWZu
OiAwMDAwNDgyNQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoyNV0gICBnZm46IDAwMDA0
ODI2ICBtZm46IDAwMDA0ODI2DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjI1XSAgIGdm
bjogMDAwMDQ4MjcgIG1mbjogMDAwMDQ4MjcNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6
MjVdICAgZ2ZuOiAwMDAwNDgyOCAgbWZuOiAwMDAwNDgyOA0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMjoyNV0gICBnZm46IDAwMDA0ODI5ICBtZm46IDAwMDA0ODI5DQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMyOjI1XSAgIGdmbjogMDAwMDQ4MmEgIG1mbjogMDAwMDQ4MmENCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MjVdICAgZ2ZuOiAwMDAwNDgyYiAgbWZuOiAwMDAw
NDgyYg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoyNV0gICBnZm46IDAwMDA0ODJjICBt
Zm46IDAwMDA0ODJjDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjI1XSAgIGdmbjogMDAw
MDQ4MmQgIG1mbjogMDAwMDQ4MmQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MjVdICAg
Z2ZuOiAwMDAwNDgyZSAgbWZuOiAwMDAwNDgyZQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
MjoyNV0gICBnZm46IDAwMDA0ODJmICBtZm46IDAwMDA0ODJmDQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMyOjI1XSAgIGdmbjogMDAwMDQ4MzAgIG1mbjogMDAwMDQ4MzANCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzI6MjVdICAgZ2ZuOiAwMDAwNDgzMSAgbWZuOiAwMDAwNDgzMQ0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoyNV0gICBnZm46IDAwMDA0ODMyICBtZm46IDAw
MDA0ODMyDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjI1XSAgIGdmbjogMDAwMDQ4MzMg
IG1mbjogMDAwMDQ4MzMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MjVdICAgZ2ZuOiAw
MDAwNDgzNCAgbWZuOiAwMDAwNDgzNA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoyNV0g
ICBnZm46IDAwMDA0ODM1ICBtZm46IDAwMDA0ODM1DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMyOjI1XSAgIGdmbjogMDAwMDQ4MzYgIG1mbjogMDAwMDQ4MzYNCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzI6MjVdICAgZ2ZuOiAwMDAwNDgzNyAgbWZuOiAwMDAwNDgzNw0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMjoyNV0gICBnZm46IDAwMDA0ODM4ICBtZm46IDAwMDA0ODM4
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjI1XSAgIGdmbjogMDAwMDQ4MzkgIG1mbjog
MDAwMDQ4MzkNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MjVdICAgZ2ZuOiAwMDAwNDgz
YSAgbWZuOiAwMDAwNDgzYQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoyNV0gICBnZm46
IDAwMDA0ODNiICBtZm46IDAwMDA0ODNiDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjI1
XSAgIGdmbjogMDAwMDQ4M2MgIG1mbjogMDAwMDQ4M2MNCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzI6MjZdICAgZ2ZuOiAwMDAwNDgzZCAgbWZuOiAwMDAwNDgzZA0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMjoyNl0gICBnZm46IDAwMDA0ODNlICBtZm46IDAwMDA0ODNlDQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMyOjI2XSAgIGdmbjogMDAwMDQ4M2YgIG1mbjogMDAwMDQ4
M2YNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MjZdICAgZ2ZuOiAwMDAwNDg0MCAgbWZu
OiAwMDAwNDg0MA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoyNl0gICBnZm46IDAwMDA0
ODQxICBtZm46IDAwMDA0ODQxDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjI2XSAgIGdm
bjogMDAwMDQ4NDIgIG1mbjogMDAwMDQ4NDINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6
MjZdICAgZ2ZuOiAwMDAwNDg0MyAgbWZuOiAwMDAwNDg0Mw0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMjoyNl0gICBnZm46IDAwMDA0ODQ0ICBtZm46IDAwMDA0ODQ0DQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMyOjI2XSAgIGdmbjogMDAwMDQ4NDUgIG1mbjogMDAwMDQ4NDUNCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MjZdICAgZ2ZuOiAwMDAwNDg0NiAgbWZuOiAwMDAw
NDg0Ng0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoyNl0gICBnZm46IDAwMDA0ODQ3ICBt
Zm46IDAwMDA0ODQ3DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjI2XSAgIGdmbjogMDAw
MDQ4NDggIG1mbjogMDAwMDQ4NDgNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MjZdICAg
Z2ZuOiAwMDAwNDg0OSAgbWZuOiAwMDAwNDg0OQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
MjoyNl0gICBnZm46IDAwMDA0ODRhICBtZm46IDAwMDA0ODRhDQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMyOjI2XSAgIGdmbjogMDAwMDQ4NGIgIG1mbjogMDAwMDQ4NGINCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzI6MjZdICAgZ2ZuOiAwMDAwNDg0YyAgbWZuOiAwMDAwNDg0Yw0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoyNl0gICBnZm46IDAwMDA0ODRkICBtZm46IDAw
MDA0ODRkDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjI2XSAgIGdmbjogMDAwMDQ4NGUg
IG1mbjogMDAwMDQ4NGUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MjZdICAgZ2ZuOiAw
MDAwNDg0ZiAgbWZuOiAwMDAwNDg0Zg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoyNl0g
ICBnZm46IDAwMDA0ODUwICBtZm46IDAwMDA0ODUwDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMyOjI2XSAgIGdmbjogMDAwMDQ4NTEgIG1mbjogMDAwMDQ4NTENCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzI6MjZdICAgZ2ZuOiAwMDAwNDg1MiAgbWZuOiAwMDAwNDg1Mg0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMjoyNl0gICBnZm46IDAwMDA0ODUzICBtZm46IDAwMDA0ODUz
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjI2XSAgIGdmbjogMDAwMDQ4NTQgIG1mbjog
MDAwMDQ4NTQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MjZdICAgZ2ZuOiAwMDAwNDg1
NSAgbWZuOiAwMDAwNDg1NQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoyNl0gICBnZm46
IDAwMDA0ODU2ICBtZm46IDAwMDA0ODU2DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjI2
XSAgIGdmbjogMDAwMDQ4NTcgIG1mbjogMDAwMDQ4NTcNCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzI6MjZdICAgZ2ZuOiAwMDAwNDg1OCAgbWZuOiAwMDAwNDg1OA0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMjoyNl0gICBnZm46IDAwMDA0ODU5ICBtZm46IDAwMDA0ODU5DQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMyOjI2XSAgIGdmbjogMDAwMDQ4NWEgIG1mbjogMDAwMDQ4
NWENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MjZdICAgZ2ZuOiAwMDAwNDg1YiAgbWZu
OiAwMDAwNDg1Yg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoyNl0gICBnZm46IDAwMDA0
ODVjICBtZm46IDAwMDA0ODVjDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjI2XSAgIGdm
bjogMDAwMDQ4NWQgIG1mbjogMDAwMDQ4NWQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6
MjZdICAgZ2ZuOiAwMDAwNDg1ZSAgbWZuOiAwMDAwNDg1ZQ0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMjoyNl0gICBnZm46IDAwMDA0ODVmICBtZm46IDAwMDA0ODVmDQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMyOjI2XSAgIGdmbjogMDAwMDQ4NjAgIG1mbjogMDAwMDQ4NjANCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MjZdICAgZ2ZuOiAwMDAwNDg2MSAgbWZuOiAwMDAw
NDg2MQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoyNl0gICBnZm46IDAwMDA0ODYyICBt
Zm46IDAwMDA0ODYyDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjI2XSAgIGdmbjogMDAw
MDQ4NjMgIG1mbjogMDAwMDQ4NjMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MjZdICAg
Z2ZuOiAwMDAwNDg2NCAgbWZuOiAwMDAwNDg2NA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
MjoyNl0gICBnZm46IDAwMDA0ODY1ICBtZm46IDAwMDA0ODY1DQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMyOjI2XSAgIGdmbjogMDAwMDQ4NjYgIG1mbjogMDAwMDQ4NjYNCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzI6MjZdICAgZ2ZuOiAwMDAwNDg2NyAgbWZuOiAwMDAwNDg2Nw0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoyNl0gICBnZm46IDAwMDA0ODY4ICBtZm46IDAw
MDA0ODY4DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjI2XSAgIGdmbjogMDAwMDQ4Njkg
IG1mbjogMDAwMDQ4NjkNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MjZdICAgZ2ZuOiAw
MDAwNDg2YSAgbWZuOiAwMDAwNDg2YQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoyNl0g
ICBnZm46IDAwMDA0ODZiICBtZm46IDAwMDA0ODZiDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMyOjI2XSAgIGdmbjogMDAwMDQ4NmMgIG1mbjogMDAwMDQ4NmMNCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzI6MjZdICAgZ2ZuOiAwMDAwNDg2ZCAgbWZuOiAwMDAwNDg2ZA0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMjoyNl0gICBnZm46IDAwMDA0ODZlICBtZm46IDAwMDA0ODZl
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjI2XSAgIGdmbjogMDAwMDQ4NmYgIG1mbjog
MDAwMDQ4NmYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MjZdICAgZ2ZuOiAwMDAwNDg3
MCAgbWZuOiAwMDAwNDg3MA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoyNl0gICBnZm46
IDAwMDA0ODcxICBtZm46IDAwMDA0ODcxDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjI2
XSAgIGdmbjogMDAwMDQ4NzIgIG1mbjogMDAwMDQ4NzINCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzI6MjZdICAgZ2ZuOiAwMDAwNDg3MyAgbWZuOiAwMDAwNDg3Mw0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMjoyNl0gICBnZm46IDAwMDA0ODc0ICBtZm46IDAwMDA0ODc0DQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMyOjI2XSAgIGdmbjogMDAwMDQ4NzUgIG1mbjogMDAwMDQ4
NzUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MjZdICAgZ2ZuOiAwMDAwNDg3NiAgbWZu
OiAwMDAwNDg3Ng0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoyNl0gICBnZm46IDAwMDA0
ODc3ICBtZm46IDAwMDA0ODc3DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjI2XSAgIGdm
bjogMDAwMDQ4NzggIG1mbjogMDAwMDQ4NzgNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6
MjZdICAgZ2ZuOiAwMDAwNDg3OSAgbWZuOiAwMDAwNDg3OQ0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMjoyNl0gICBnZm46IDAwMDA0ODdhICBtZm46IDAwMDA0ODdhDQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMyOjI2XSAgIGdmbjogMDAwMDQ4N2IgIG1mbjogMDAwMDQ4N2INCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MjZdICAgZ2ZuOiAwMDAwNDg3YyAgbWZuOiAwMDAw
NDg3Yw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoyN10gICBnZm46IDAwMDA0ODdkICBt
Zm46IDAwMDA0ODdkDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjI3XSAgIGdmbjogMDAw
MDQ4N2UgIG1mbjogMDAwMDQ4N2UNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MjddICAg
Z2ZuOiAwMDAwNDg3ZiAgbWZuOiAwMDAwNDg3Zg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
MjoyN10gICBnZm46IDAwMDA0ODgwICBtZm46IDAwMDA0ODgwDQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMyOjI3XSAgIGdmbjogMDAwMDQ4ODEgIG1mbjogMDAwMDQ4ODENCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzI6MjddICAgZ2ZuOiAwMDAwNDg4MiAgbWZuOiAwMDAwNDg4Mg0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoyN10gICBnZm46IDAwMDA0ODgzICBtZm46IDAw
MDA0ODgzDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjI3XSAgIGdmbjogMDAwMDQ4ODQg
IG1mbjogMDAwMDQ4ODQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MjddICAgZ2ZuOiAw
MDAwNDg4NSAgbWZuOiAwMDAwNDg4NQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoyN10g
ICBnZm46IDAwMDA0ODg2ICBtZm46IDAwMDA0ODg2DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMyOjI3XSAgIGdmbjogMDAwMDQ4ODcgIG1mbjogMDAwMDQ4ODcNCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzI6MjddICAgZ2ZuOiAwMDAwNDg4OCAgbWZuOiAwMDAwNDg4OA0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMjoyN10gICBnZm46IDAwMDA0ODg5ICBtZm46IDAwMDA0ODg5
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjI3XSAgIGdmbjogMDAwMDQ4OGEgIG1mbjog
MDAwMDQ4OGENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MjddICAgZ2ZuOiAwMDAwNDg4
YiAgbWZuOiAwMDAwNDg4Yg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoyN10gICBnZm46
IDAwMDA0ODhjICBtZm46IDAwMDA0ODhjDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjI3
XSAgIGdmbjogMDAwMDQ4OGQgIG1mbjogMDAwMDQ4OGQNCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzI6MjddICAgZ2ZuOiAwMDAwNDg4ZSAgbWZuOiAwMDAwNDg4ZQ0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMjoyN10gICBnZm46IDAwMDA0ODhmICBtZm46IDAwMDA0ODhmDQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMyOjI3XSAgIGdmbjogMDAwMDQ4OTAgIG1mbjogMDAwMDQ4
OTANCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MjddICAgZ2ZuOiAwMDAwNDg5MSAgbWZu
OiAwMDAwNDg5MQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoyN10gICBnZm46IDAwMDA0
ODkyICBtZm46IDAwMDA0ODkyDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjI3XSAgIGdm
bjogMDAwMDQ4OTMgIG1mbjogMDAwMDQ4OTMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6
MjddICAgZ2ZuOiAwMDAwNDg5NCAgbWZuOiAwMDAwNDg5NA0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMjoyN10gICBnZm46IDAwMDA0ODk1ICBtZm46IDAwMDA0ODk1DQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMyOjI3XSAgIGdmbjogMDAwMDQ4OTYgIG1mbjogMDAwMDQ4OTYNCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MjddICAgZ2ZuOiAwMDAwNDg5NyAgbWZuOiAwMDAw
NDg5Nw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoyN10gICBnZm46IDAwMDA0ODk4ICBt
Zm46IDAwMDA0ODk4DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjI3XSAgIGdmbjogMDAw
MDQ4OTkgIG1mbjogMDAwMDQ4OTkNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MjddICAg
Z2ZuOiAwMDAwNDg5YSAgbWZuOiAwMDAwNDg5YQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
MjoyN10gICBnZm46IDAwMDA0ODliICBtZm46IDAwMDA0ODliDQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMyOjI3XSAgIGdmbjogMDAwMDQ4OWMgIG1mbjogMDAwMDQ4OWMNCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzI6MjddICAgZ2ZuOiAwMDAwNDg5ZCAgbWZuOiAwMDAwNDg5ZA0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoyN10gICBnZm46IDAwMDA0ODllICBtZm46IDAw
MDA0ODllDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjI3XSAgIGdmbjogMDAwMDQ4OWYg
IG1mbjogMDAwMDQ4OWYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MjddICAgZ2ZuOiAw
MDAwNDhhMCAgbWZuOiAwMDAwNDhhMA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoyN10g
ICBnZm46IDAwMDA0OGExICBtZm46IDAwMDA0OGExDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMyOjI3XSAgIGdmbjogMDAwMDQ4YTIgIG1mbjogMDAwMDQ4YTINCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzI6MjddICAgZ2ZuOiAwMDAwNDhhMyAgbWZuOiAwMDAwNDhhMw0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMjoyN10gICBnZm46IDAwMDA0OGE0ICBtZm46IDAwMDA0OGE0
DQoNClsgIDQxMy42MDAyMDVdIGEoWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoyN10gICBnZm46
IDAwMDA0OGE1ICBtZm46IDAwMDA0OGE1DQoNCnRhMS4wMDogZXhjZXB0aW9uIEVtYXNrIDB4
MCBTQWN0KFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MjddICAgZ2ZuOiAwMDAwNDhhNiAgbWZu
OiAwMDAwNDhhNg0KDQogMHgxIFNFcnIgMHgwIGFjKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6
MjddICAgZ2ZuOiAwMDAwNDhhNyAgbWZuOiAwMDAwNDhhNw0KDQp0aW9uIDB4NiBmcm96ZW4N
Cg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoyN10gICBnZm46IDAwMDA0OGE4ICBtZm46
IDAwMDA0OGE4DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjI3XSAgIGdmbjogMDAwMDQ4
YTkgIG1mbjogMDAwMDQ4YTkNCg0KWyAgNDEzLjY5OTU5Ml0gYShYRU4pIFsyMDEyLTA4LTMx
IDIxOjMyOjI3XSAgIGdmbjogMDAwMDQ4YWEgIG1mbjogMDAwMDQ4YWENCg0KdGExLjAwOiBm
YWlsZWQgYyhYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjI3XSAgIGdmbjogMDAwMDQ4YWIgIG1m
bjogMDAwMDQ4YWINCg0Kb21tYW5kOiBSRUFEIEZQRE1BIFFVRVVFRA0KDQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMyOjI3XSAgIGdmbjogMDAwMDQ4YWMgIG1mbjogMDAwMDQ4YWMNCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MjddICAgZ2ZuOiAwMDAwNDhhZCAgbWZuOiAwMDAw
NDhhZA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoyN10gICBnZm46IDAwMDA0OGFlICBt
Zm46IDAwMDA0OGFlDQoNClsgIDQxMy43Nzg1MDRdIGEoWEVOKSBbMjAxMi0wOC0zMSAyMToz
MjoyN10gICBnZm46IDAwMDA0OGFmICBtZm46IDAwMDA0OGFmDQoNCnRhMS4wMDogY21kIDYw
LzEoWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoyN10gICBnZm46IDAwMDA0OGIwICBtZm46IDAw
MDA0OGIwDQoNCjA6MDA6NTE6MTE6OTUvMDAoWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoyN10g
ICBnZm46IDAwMDA0OGIxICBtZm46IDAwMDA0OGIxDQoNCjowMDo4ZTowMDowMC80MCB0YWcg
MCBuY3EgODE5MiBpKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MjddICAgZ2ZuOiAwMDAwNDhi
MiAgbWZuOiAwMDAwNDhiMg0KDQpuDQoNCg0KWyAgNDEzLjc3ODUwNChYRU4pIFsyMDEyLTA4
LTMxIDIxOjMyOjI3XSAgIGdmbjogMDAwMDQ4YjMgIG1mbjogMDAwMDQ4YjMNCg0KXSAgICAg
ICAgICByZXMgNDAvMDA6ZmY6MDA6MDA6MDAoWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoyN10g
ICBnZm46IDAwMDA0OGI0ICBtZm46IDAwMDA0OGI0DQoNCi8wMDowMDowMDowMDowMC8oWEVO
KSBbMjAxMi0wOC0zMSAyMTozMjoyN10gICBnZm46IDAwMDA0OGI1ICBtZm46IDAwMDA0OGI1
DQoNCjAwIEVtYXNrIDB4NCAodGltZW91dCkNCg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
MjoyN10gICBnZm46IDAwMDA0OGI2ICBtZm46IDAwMDA0OGI2DQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMyOjI3XSAgIGdmbjogMDAwMDQ4YjcgIG1mbjogMDAwMDQ4YjcNCg0KWyAgNDEz
Ljk3ODE5OF0gYXRhMS4wMDogc3RhdHVzOiAoWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoyOF0g
ICBnZm46IDAwMDA0OGI4ICBtZm46IDAwMDA0OGI4DQoNCnsgRFJEWSB9DQoNCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzI6MjhdICAgZ2ZuOiAwMDAwNDhiOSAgbWZuOiAwMDAwNDhiOQ0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoyOF0gICBnZm46IDAwMDA0OGJhICBtZm46IDAw
MDA0OGJhDQoNClsgIDQxNC4wMzY0MDddIGEoWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoyOF0g
ICBnZm46IDAwMDA0OGJiICBtZm46IDAwMDA0OGJiDQoNCnRhMTogaGFyZCByZXNldHQoWEVO
KSBbMjAxMi0wOC0zMSAyMTozMjoyOF0gICBnZm46IDAwMDA0OGJjICBtZm46IDAwMDA0OGJj
DQoNCmluZyBsaW5rDQoNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MjhdICAgZ2ZuOiAw
MDAwNDhiZCAgbWZuOiAwMDAwNDhiZA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoyOF0g
ICBnZm46IDAwMDA0OGJlICBtZm46IDAwMDA0OGJlDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMyOjI4XSAgIGdmbjogMDAwMDQ4YmYgIG1mbjogMDAwMDQ4YmYNCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzI6MjhdICAgZ2ZuOiAwMDAwNDhjMCAgbWZuOiAwMDAwNDhjMA0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMjoyOF0gICBnZm46IDAwMDA0OGMxICBtZm46IDAwMDA0OGMx
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjI4XSAgIGdmbjogMDAwMDQ4YzIgIG1mbjog
MDAwMDQ4YzINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MjhdICAgZ2ZuOiAwMDAwNDhj
MyAgbWZuOiAwMDAwNDhjMw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoyOF0gICBnZm46
IDAwMDA0OGM0ICBtZm46IDAwMDA0OGM0DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjI4
XSAgIGdmbjogMDAwMDQ4YzUgIG1mbjogMDAwMDQ4YzUNCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzI6MjhdICAgZ2ZuOiAwMDAwNDhjNiAgbWZuOiAwMDAwNDhjNg0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMjoyOF0gICBnZm46IDAwMDA0OGM3ICBtZm46IDAwMDA0OGM3DQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMyOjI4XSAgIGdmbjogMDAwMDQ4YzggIG1mbjogMDAwMDQ4
YzgNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MjhdICAgZ2ZuOiAwMDAwNDhjOSAgbWZu
OiAwMDAwNDhjOQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoyOF0gICBnZm46IDAwMDA0
OGNhICBtZm46IDAwMDA0OGNhDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjI4XSAgIGdm
bjogMDAwMDQ4Y2IgIG1mbjogMDAwMDQ4Y2INCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6
MjhdICAgZ2ZuOiAwMDAwNDhjYyAgbWZuOiAwMDAwNDhjYw0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMjoyOF0gICBnZm46IDAwMDA0OGNkICBtZm46IDAwMDA0OGNkDQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMyOjI4XSAgIGdmbjogMDAwMDQ4Y2UgIG1mbjogMDAwMDQ4Y2UNCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MjhdICAgZ2ZuOiAwMDAwNDhjZiAgbWZuOiAwMDAw
NDhjZg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoyOF0gICBnZm46IDAwMDA0OGQwICBt
Zm46IDAwMDA0OGQwDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjI4XSAgIGdmbjogMDAw
MDQ4ZDEgIG1mbjogMDAwMDQ4ZDENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MjhdICAg
Z2ZuOiAwMDAwNDhkMiAgbWZuOiAwMDAwNDhkMg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
MjoyOF0gICBnZm46IDAwMDA0OGQzICBtZm46IDAwMDA0OGQzDQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMyOjI4XSAgIGdmbjogMDAwMDQ4ZDQgIG1mbjogMDAwMDQ4ZDQNCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzI6MjhdICAgZ2ZuOiAwMDAwNDhkNSAgbWZuOiAwMDAwNDhkNQ0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoyOF0gICBnZm46IDAwMDA0OGQ2ICBtZm46IDAw
MDA0OGQ2DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjI4XSAgIGdmbjogMDAwMDQ4ZDcg
IG1mbjogMDAwMDQ4ZDcNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MjhdICAgZ2ZuOiAw
MDAwNDhkOCAgbWZuOiAwMDAwNDhkOA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoyOF0g
ICBnZm46IDAwMDA0OGQ5ICBtZm46IDAwMDA0OGQ5DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMyOjI4XSAgIGdmbjogMDAwMDQ4ZGEgIG1mbjogMDAwMDQ4ZGENCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzI6MjhdICAgZ2ZuOiAwMDAwNDhkYiAgbWZuOiAwMDAwNDhkYg0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMjoyOF0gICBnZm46IDAwMDA0OGRjICBtZm46IDAwMDA0OGRj
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjI4XSAgIGdmbjogMDAwMDQ4ZGQgIG1mbjog
MDAwMDQ4ZGQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MjhdICAgZ2ZuOiAwMDAwNDhk
ZSAgbWZuOiAwMDAwNDhkZQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoyOF0gICBnZm46
IDAwMDA0OGRmICBtZm46IDAwMDA0OGRmDQoNClsgIDQxNC42MjMyMTRdIGF0YTE6IFNBVEEg
bGluayB1KFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MjhdICAgZ2ZuOiAwMDAwNDhlMCAgbWZu
OiAwMDAwNDhlMA0KDQpwIDMuMCBHYnBzIChTU3RhKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6
MjhdICAgZ2ZuOiAwMDAwNDhlMSAgbWZuOiAwMDAwNDhlMQ0KDQp0dXMgMTIzIFNDb250cm9s
KFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MjhdICAgZ2ZuOiAwMDAwNDhlMiAgbWZuOiAwMDAw
NDhlMg0KDQogMzAwKQ0KDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjI4XSAgIGdmbjog
MDAwMDQ4ZTMgIG1mbjogMDAwMDQ4ZTMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6Mjhd
ICAgZ2ZuOiAwMDAwNDhlNCAgbWZuOiAwMDAwNDhlNA0KDQooWEVOKSBbMjAxMi0wOC0zMSAy
MTozMjoyOF0gICBnZm46IDAwMDA0OGU1ICBtZm46IDAwMDA0OGU1DQoNCihYRU4pIFsyMDEy
LTA4LTMxIDIxOjMyOjI4XSAgIGdmbjogMDAwMDQ4ZTYgIG1mbjogMDAwMDQ4ZTYNCg0KKFhF
TikgWzIwMTItMDgtMzEgMjE6MzI6MjhdICAgZ2ZuOiAwMDAwNDhlNyAgbWZuOiAwMDAwNDhl
Nw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoyOF0gICBnZm46IDAwMDA0OGU4ICBtZm46
IDAwMDA0OGU4DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjI4XSAgIGdmbjogMDAwMDQ4
ZTkgIG1mbjogMDAwMDQ4ZTkNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MjhdICAgZ2Zu
OiAwMDAwNDhlYSAgbWZuOiAwMDAwNDhlYQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoy
OF0gICBnZm46IDAwMDA0OGViICBtZm46IDAwMDA0OGViDQoNCihYRU4pIFsyMDEyLTA4LTMx
IDIxOjMyOjI4XSAgIGdmbjogMDAwMDQ4ZWMgIG1mbjogMDAwMDQ4ZWMNCg0KKFhFTikgWzIw
MTItMDgtMzEgMjE6MzI6MjhdICAgZ2ZuOiAwMDAwNDhlZCAgbWZuOiAwMDAwNDhlZA0KDQoo
WEVOKSBbMjAxMi0wOC0zMSAyMTozMjoyOF0gICBnZm46IDAwMDA0OGVlICBtZm46IDAwMDA0
OGVlDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjI4XSAgIGdmbjogMDAwMDQ4ZWYgIG1m
bjogMDAwMDQ4ZWYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MjhdICAgZ2ZuOiAwMDAw
NDhmMCAgbWZuOiAwMDAwNDhmMA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoyOF0gICBn
Zm46IDAwMDA0OGYxICBtZm46IDAwMDA0OGYxDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMy
OjI4XSAgIGdmbjogMDAwMDQ4ZjIgIG1mbjogMDAwMDQ4ZjINCg0KKFhFTikgWzIwMTItMDgt
MzEgMjE6MzI6MjhdICAgZ2ZuOiAwMDAwNDhmMyAgbWZuOiAwMDAwNDhmMw0KDQooWEVOKSBb
MjAxMi0wOC0zMSAyMTozMjoyOF0gICBnZm46IDAwMDA0OGY0ICBtZm46IDAwMDA0OGY0DQoN
CihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjI5XSAgIGdmbjogMDAwMDQ4ZjUgIG1mbjogMDAw
MDQ4ZjUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MjldICAgZ2ZuOiAwMDAwNDhmNiAg
bWZuOiAwMDAwNDhmNg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoyOV0gICBnZm46IDAw
MDA0OGY3ICBtZm46IDAwMDA0OGY3DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjI5XSAg
IGdmbjogMDAwMDQ4ZjggIG1mbjogMDAwMDQ4ZjgNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6
MzI6MjldICAgZ2ZuOiAwMDAwNDhmOSAgbWZuOiAwMDAwNDhmOQ0KDQooWEVOKSBbMjAxMi0w
OC0zMSAyMTozMjoyOV0gICBnZm46IDAwMDA0OGZhICBtZm46IDAwMDA0OGZhDQoNCihYRU4p
IFsyMDEyLTA4LTMxIDIxOjMyOjI5XSAgIGdmbjogMDAwMDQ4ZmIgIG1mbjogMDAwMDQ4ZmIN
Cg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MjldICAgZ2ZuOiAwMDAwNDhmYyAgbWZuOiAw
MDAwNDhmYw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoyOV0gICBnZm46IDAwMDA0OGZk
ICBtZm46IDAwMDA0OGZkDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjI5XSAgIGdmbjog
MDAwMDQ4ZmUgIG1mbjogMDAwMDQ4ZmUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6Mjld
ICAgZ2ZuOiAwMDAwNDhmZiAgbWZuOiAwMDAwNDhmZg0KDQooWEVOKSBbMjAxMi0wOC0zMSAy
MTozMjoyOV0gICBnZm46IDAwMDA0OTAwICBtZm46IDAwMDA0OTAwDQoNCihYRU4pIFsyMDEy
LTA4LTMxIDIxOjMyOjI5XSAgIGdmbjogMDAwMDQ5MDEgIG1mbjogMDAwMDQ5MDENCg0KKFhF
TikgWzIwMTItMDgtMzEgMjE6MzI6MjldICAgZ2ZuOiAwMDAwNDkwMiAgbWZuOiAwMDAwNDkw
Mg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoyOV0gICBnZm46IDAwMDA0OTAzICBtZm46
IDAwMDA0OTAzDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjI5XSAgIGdmbjogMDAwMDQ5
MDQgIG1mbjogMDAwMDQ5MDQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MjldICAgZ2Zu
OiAwMDAwNDkwNSAgbWZuOiAwMDAwNDkwNQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoy
OV0gICBnZm46IDAwMDA0OTA2ICBtZm46IDAwMDA0OTA2DQoNCihYRU4pIFsyMDEyLTA4LTMx
IDIxOjMyOjI5XSAgIGdmbjogMDAwMDQ5MDcgIG1mbjogMDAwMDQ5MDcNCg0KKFhFTikgWzIw
MTItMDgtMzEgMjE6MzI6MjldICAgZ2ZuOiAwMDAwNDkwOCAgbWZuOiAwMDAwNDkwOA0KDQoo
WEVOKSBbMjAxMi0wOC0zMSAyMTozMjoyOV0gICBnZm46IDAwMDA0OTA5ICBtZm46IDAwMDA0
OTA5DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjI5XSAgIGdmbjogMDAwMDQ5MGEgIG1m
bjogMDAwMDQ5MGENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MjldICAgZ2ZuOiAwMDAw
NDkwYiAgbWZuOiAwMDAwNDkwYg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoyOV0gICBn
Zm46IDAwMDA0OTBjICBtZm46IDAwMDA0OTBjDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMy
OjI5XSAgIGdmbjogMDAwMDQ5MGQgIG1mbjogMDAwMDQ5MGQNCg0KKFhFTikgWzIwMTItMDgt
MzEgMjE6MzI6MjldICAgZ2ZuOiAwMDAwNDkwZSAgbWZuOiAwMDAwNDkwZQ0KDQooWEVOKSBb
MjAxMi0wOC0zMSAyMTozMjoyOV0gICBnZm46IDAwMDA0OTBmICBtZm46IDAwMDA0OTBmDQoN
CihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjI5XSAgIGdmbjogMDAwMDQ5MTAgIG1mbjogMDAw
MDQ5MTANCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MjldICAgZ2ZuOiAwMDAwNDkxMSAg
bWZuOiAwMDAwNDkxMQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoyOV0gICBnZm46IDAw
MDA0OTEyICBtZm46IDAwMDA0OTEyDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjI5XSAg
IGdmbjogMDAwMDQ5MTMgIG1mbjogMDAwMDQ5MTMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6
MzI6MjldICAgZ2ZuOiAwMDAwNDkxNCAgbWZuOiAwMDAwNDkxNA0KDQooWEVOKSBbMjAxMi0w
OC0zMSAyMTozMjoyOV0gICBnZm46IDAwMDA0OTE1ICBtZm46IDAwMDA0OTE1DQoNCihYRU4p
IFsyMDEyLTA4LTMxIDIxOjMyOjI5XSAgIGdmbjogMDAwMDQ5MTYgIG1mbjogMDAwMDQ5MTYN
Cg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MjldICAgZ2ZuOiAwMDAwNDkxNyAgbWZuOiAw
MDAwNDkxNw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoyOV0gICBnZm46IDAwMDA0OTE4
ICBtZm46IDAwMDA0OTE4DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjI5XSAgIGdmbjog
MDAwMDQ5MTkgIG1mbjogMDAwMDQ5MTkNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6Mjld
ICAgZ2ZuOiAwMDAwNDkxYSAgbWZuOiAwMDAwNDkxYQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAy
MTozMjoyOV0gICBnZm46IDAwMDA0OTFiICBtZm46IDAwMDA0OTFiDQoNCihYRU4pIFsyMDEy
LTA4LTMxIDIxOjMyOjI5XSAgIGdmbjogMDAwMDQ5MWMgIG1mbjogMDAwMDQ5MWMNCg0KKFhF
TikgWzIwMTItMDgtMzEgMjE6MzI6MjldICAgZ2ZuOiAwMDAwNDkxZCAgbWZuOiAwMDAwNDkx
ZA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoyOV0gICBnZm46IDAwMDA0OTFlICBtZm46
IDAwMDA0OTFlDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjI5XSAgIGdmbjogMDAwMDQ5
MWYgIG1mbjogMDAwMDQ5MWYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MjldICAgZ2Zu
OiAwMDAwNDkyMCAgbWZuOiAwMDAwNDkyMA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoy
OV0gICBnZm46IDAwMDA0OTIxICBtZm46IDAwMDA0OTIxDQoNCihYRU4pIFsyMDEyLTA4LTMx
IDIxOjMyOjI5XSAgIGdmbjogMDAwMDQ5MjIgIG1mbjogMDAwMDQ5MjINCg0KKFhFTikgWzIw
MTItMDgtMzEgMjE6MzI6MjldICAgZ2ZuOiAwMDAwNDkyMyAgbWZuOiAwMDAwNDkyMw0KDQoo
WEVOKSBbMjAxMi0wOC0zMSAyMTozMjoyOV0gICBnZm46IDAwMDA0OTI0ICBtZm46IDAwMDA0
OTI0DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjI5XSAgIGdmbjogMDAwMDQ5MjUgIG1m
bjogMDAwMDQ5MjUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MjldICAgZ2ZuOiAwMDAw
NDkyNiAgbWZuOiAwMDAwNDkyNg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoyOV0gICBn
Zm46IDAwMDA0OTI3ICBtZm46IDAwMDA0OTI3DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMy
OjI5XSAgIGdmbjogMDAwMDQ5MjggIG1mbjogMDAwMDQ5MjgNCg0KKFhFTikgWzIwMTItMDgt
MzEgMjE6MzI6MjldICAgZ2ZuOiAwMDAwNDkyOSAgbWZuOiAwMDAwNDkyOQ0KDQooWEVOKSBb
MjAxMi0wOC0zMSAyMTozMjoyOV0gICBnZm46IDAwMDA0OTJhICBtZm46IDAwMDA0OTJhDQoN
CihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjI5XSAgIGdmbjogMDAwMDQ5MmIgIG1mbjogMDAw
MDQ5MmINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MjldICAgZ2ZuOiAwMDAwNDkyYyAg
bWZuOiAwMDAwNDkyYw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoyOV0gICBnZm46IDAw
MDA0OTJkICBtZm46IDAwMDA0OTJkDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjI5XSAg
IGdmbjogMDAwMDQ5MmUgIG1mbjogMDAwMDQ5MmUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6
MzI6MjldICAgZ2ZuOiAwMDAwNDkyZiAgbWZuOiAwMDAwNDkyZg0KDQooWEVOKSBbMjAxMi0w
OC0zMSAyMTozMjoyOV0gICBnZm46IDAwMDA0OTMwICBtZm46IDAwMDA0OTMwDQoNCihYRU4p
IFsyMDEyLTA4LTMxIDIxOjMyOjI5XSAgIGdmbjogMDAwMDQ5MzEgIG1mbjogMDAwMDQ5MzEN
Cg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MjldICAgZ2ZuOiAwMDAwNDkzMiAgbWZuOiAw
MDAwNDkzMg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoyOV0gICBnZm46IDAwMDA0OTMz
ICBtZm46IDAwMDA0OTMzDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjI5XSAgIGdmbjog
MDAwMDQ5MzQgIG1mbjogMDAwMDQ5MzQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6Mjld
ICAgZ2ZuOiAwMDAwNDkzNSAgbWZuOiAwMDAwNDkzNQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAy
MTozMjozMF0gICBnZm46IDAwMDA0OTM2ICBtZm46IDAwMDA0OTM2DQoNCihYRU4pIFsyMDEy
LTA4LTMxIDIxOjMyOjMwXSAgIGdmbjogMDAwMDQ5MzcgIG1mbjogMDAwMDQ5MzcNCg0KKFhF
TikgWzIwMTItMDgtMzEgMjE6MzI6MzBdICAgZ2ZuOiAwMDAwNDkzOCAgbWZuOiAwMDAwNDkz
OA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjozMF0gICBnZm46IDAwMDA0OTM5ICBtZm46
IDAwMDA0OTM5DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjMwXSAgIGdmbjogMDAwMDQ5
M2EgIG1mbjogMDAwMDQ5M2ENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MzBdICAgZ2Zu
OiAwMDAwNDkzYiAgbWZuOiAwMDAwNDkzYg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoz
MF0gICBnZm46IDAwMDA0OTNjICBtZm46IDAwMDA0OTNjDQoNCihYRU4pIFsyMDEyLTA4LTMx
IDIxOjMyOjMwXSAgIGdmbjogMDAwMDQ5M2QgIG1mbjogMDAwMDQ5M2QNCg0KKFhFTikgWzIw
MTItMDgtMzEgMjE6MzI6MzBdICAgZ2ZuOiAwMDAwNDkzZSAgbWZuOiAwMDAwNDkzZQ0KDQoo
WEVOKSBbMjAxMi0wOC0zMSAyMTozMjozMF0gICBnZm46IDAwMDA0OTNmICBtZm46IDAwMDA0
OTNmDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjMwXSAgIGdmbjogMDAwMDQ5NDAgIG1m
bjogMDAwMDQ5NDANCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MzBdICAgZ2ZuOiAwMDAw
NDk0MSAgbWZuOiAwMDAwNDk0MQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjozMF0gICBn
Zm46IDAwMDA0OTQyICBtZm46IDAwMDA0OTQyDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMy
OjMwXSAgIGdmbjogMDAwMDQ5NDMgIG1mbjogMDAwMDQ5NDMNCg0KKFhFTikgWzIwMTItMDgt
MzEgMjE6MzI6MzBdICAgZ2ZuOiAwMDAwNDk0NCAgbWZuOiAwMDAwNDk0NA0KDQooWEVOKSBb
MjAxMi0wOC0zMSAyMTozMjozMF0gICBnZm46IDAwMDA0OTQ1ICBtZm46IDAwMDA0OTQ1DQoN
CihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjMwXSAgIGdmbjogMDAwMDQ5NDYgIG1mbjogMDAw
MDQ5NDYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MzBdICAgZ2ZuOiAwMDAwNDk0NyAg
bWZuOiAwMDAwNDk0Nw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjozMF0gICBnZm46IDAw
MDA0OTQ4ICBtZm46IDAwMDA0OTQ4DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjMwXSAg
IGdmbjogMDAwMDQ5NDkgIG1mbjogMDAwMDQ5NDkNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6
MzI6MzBdICAgZ2ZuOiAwMDAwNDk0YSAgbWZuOiAwMDAwNDk0YQ0KDQooWEVOKSBbMjAxMi0w
OC0zMSAyMTozMjozMF0gICBnZm46IDAwMDA0OTRiICBtZm46IDAwMDA0OTRiDQoNCihYRU4p
IFsyMDEyLTA4LTMxIDIxOjMyOjMwXSAgIGdmbjogMDAwMDQ5NGMgIG1mbjogMDAwMDQ5NGMN
Cg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MzBdICAgZ2ZuOiAwMDAwNDk0ZCAgbWZuOiAw
MDAwNDk0ZA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjozMF0gICBnZm46IDAwMDA0OTRl
ICBtZm46IDAwMDA0OTRlDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjMwXSAgIGdmbjog
MDAwMDQ5NGYgIG1mbjogMDAwMDQ5NGYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MzBd
ICAgZ2ZuOiAwMDAwNDk1MCAgbWZuOiAwMDAwNDk1MA0KDQooWEVOKSBbMjAxMi0wOC0zMSAy
MTozMjozMF0gICBnZm46IDAwMDA0OTUxICBtZm46IDAwMDA0OTUxDQoNCihYRU4pIFsyMDEy
LTA4LTMxIDIxOjMyOjMwXSAgIGdmbjogMDAwMDQ5NTIgIG1mbjogMDAwMDQ5NTINCg0KKFhF
TikgWzIwMTItMDgtMzEgMjE6MzI6MzBdICAgZ2ZuOiAwMDAwNDk1MyAgbWZuOiAwMDAwNDk1
Mw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjozMF0gICBnZm46IDAwMDA0OTU0ICBtZm46
IDAwMDA0OTU0DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjMwXSAgIGdmbjogMDAwMDQ5
NTUgIG1mbjogMDAwMDQ5NTUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MzBdICAgZ2Zu
OiAwMDAwNDk1NiAgbWZuOiAwMDAwNDk1Ng0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoz
MF0gICBnZm46IDAwMDA0OTU3ICBtZm46IDAwMDA0OTU3DQoNCihYRU4pIFsyMDEyLTA4LTMx
IDIxOjMyOjMwXSAgIGdmbjogMDAwMDQ5NTggIG1mbjogMDAwMDQ5NTgNCg0KKFhFTikgWzIw
MTItMDgtMzEgMjE6MzI6MzBdICAgZ2ZuOiAwMDAwNDk1OSAgbWZuOiAwMDAwNDk1OQ0KDQoo
WEVOKSBbMjAxMi0wOC0zMSAyMTozMjozMF0gICBnZm46IDAwMDA0OTVhICBtZm46IDAwMDA0
OTVhDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjMwXSAgIGdmbjogMDAwMDQ5NWIgIG1m
bjogMDAwMDQ5NWINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MzBdICAgZ2ZuOiAwMDAw
NDk1YyAgbWZuOiAwMDAwNDk1Yw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjozMF0gICBn
Zm46IDAwMDA0OTVkICBtZm46IDAwMDA0OTVkDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMy
OjMwXSAgIGdmbjogMDAwMDQ5NWUgIG1mbjogMDAwMDQ5NWUNCg0KKFhFTikgWzIwMTItMDgt
MzEgMjE6MzI6MzBdICAgZ2ZuOiAwMDAwNDk1ZiAgbWZuOiAwMDAwNDk1Zg0KDQooWEVOKSBb
MjAxMi0wOC0zMSAyMTozMjozMF0gICBnZm46IDAwMDA0OTYwICBtZm46IDAwMDA0OTYwDQoN
CihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjMwXSAgIGdmbjogMDAwMDQ5NjEgIG1mbjogMDAw
MDQ5NjENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MzBdICAgZ2ZuOiAwMDAwNDk2MiAg
bWZuOiAwMDAwNDk2Mg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjozMF0gICBnZm46IDAw
MDA0OTYzICBtZm46IDAwMDA0OTYzDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjMwXSAg
IGdmbjogMDAwMDQ5NjQgIG1mbjogMDAwMDQ5NjQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6
MzI6MzBdICAgZ2ZuOiAwMDAwNDk2NSAgbWZuOiAwMDAwNDk2NQ0KDQooWEVOKSBbMjAxMi0w
OC0zMSAyMTozMjozMF0gICBnZm46IDAwMDA0OTY2ICBtZm46IDAwMDA0OTY2DQoNCihYRU4p
IFsyMDEyLTA4LTMxIDIxOjMyOjMwXSAgIGdmbjogMDAwMDQ5NjcgIG1mbjogMDAwMDQ5NjcN
Cg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MzBdICAgZ2ZuOiAwMDAwNDk2OCAgbWZuOiAw
MDAwNDk2OA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjozMF0gICBnZm46IDAwMDA0OTY5
ICBtZm46IDAwMDA0OTY5DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjMwXSAgIGdmbjog
MDAwMDQ5NmEgIG1mbjogMDAwMDQ5NmENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MzBd
ICAgZ2ZuOiAwMDAwNDk2YiAgbWZuOiAwMDAwNDk2Yg0KDQooWEVOKSBbMjAxMi0wOC0zMSAy
MTozMjozMF0gICBnZm46IDAwMDA0OTZjICBtZm46IDAwMDA0OTZjDQoNCihYRU4pIFsyMDEy
LTA4LTMxIDIxOjMyOjMwXSAgIGdmbjogMDAwMDQ5NmQgIG1mbjogMDAwMDQ5NmQNCg0KKFhF
TikgWzIwMTItMDgtMzEgMjE6MzI6MzBdICAgZ2ZuOiAwMDAwNDk2ZSAgbWZuOiAwMDAwNDk2
ZQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjozMF0gICBnZm46IDAwMDA0OTZmICBtZm46
IDAwMDA0OTZmDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjMwXSAgIGdmbjogMDAwMDQ5
NzAgIG1mbjogMDAwMDQ5NzANCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MzBdICAgZ2Zu
OiAwMDAwNDk3MSAgbWZuOiAwMDAwNDk3MQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoz
MF0gICBnZm46IDAwMDA0OTcyICBtZm46IDAwMDA0OTcyDQoNCihYRU4pIFsyMDEyLTA4LTMx
IDIxOjMyOjMwXSAgIGdmbjogMDAwMDQ5NzMgIG1mbjogMDAwMDQ5NzMNCg0KKFhFTikgWzIw
MTItMDgtMzEgMjE6MzI6MzBdICAgZ2ZuOiAwMDAwNDk3NCAgbWZuOiAwMDAwNDk3NA0KDQoo
WEVOKSBbMjAxMi0wOC0zMSAyMTozMjozMF0gICBnZm46IDAwMDA0OTc1ICBtZm46IDAwMDA0
OTc1DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjMxXSAgIGdmbjogMDAwMDQ5NzYgIG1m
bjogMDAwMDQ5NzYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MzFdICAgZ2ZuOiAwMDAw
NDk3NyAgbWZuOiAwMDAwNDk3Nw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjozMV0gICBn
Zm46IDAwMDA0OTc4ICBtZm46IDAwMDA0OTc4DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMy
OjMxXSAgIGdmbjogMDAwMDQ5NzkgIG1mbjogMDAwMDQ5NzkNCg0KKFhFTikgWzIwMTItMDgt
MzEgMjE6MzI6MzFdICAgZ2ZuOiAwMDAwNDk3YSAgbWZuOiAwMDAwNDk3YQ0KDQooWEVOKSBb
MjAxMi0wOC0zMSAyMTozMjozMV0gICBnZm46IDAwMDA0OTdiICBtZm46IDAwMDA0OTdiDQoN
CihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjMxXSAgIGdmbjogMDAwMDQ5N2MgIG1mbjogMDAw
MDQ5N2MNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MzFdICAgZ2ZuOiAwMDAwNDk3ZCAg
bWZuOiAwMDAwNDk3ZA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjozMV0gICBnZm46IDAw
MDA0OTdlICBtZm46IDAwMDA0OTdlDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjMxXSAg
IGdmbjogMDAwMDQ5N2YgIG1mbjogMDAwMDQ5N2YNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6
MzI6MzFdICAgZ2ZuOiAwMDAwNDk4MCAgbWZuOiAwMDAwNDk4MA0KDQooWEVOKSBbMjAxMi0w
OC0zMSAyMTozMjozMV0gICBnZm46IDAwMDA0OTgxICBtZm46IDAwMDA0OTgxDQoNCihYRU4p
IFsyMDEyLTA4LTMxIDIxOjMyOjMxXSAgIGdmbjogMDAwMDQ5ODIgIG1mbjogMDAwMDQ5ODIN
Cg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MzFdICAgZ2ZuOiAwMDAwNDk4MyAgbWZuOiAw
MDAwNDk4Mw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjozMV0gICBnZm46IDAwMDA0OTg0
ICBtZm46IDAwMDA0OTg0DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjMxXSAgIGdmbjog
MDAwMDQ5ODUgIG1mbjogMDAwMDQ5ODUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MzFd
ICAgZ2ZuOiAwMDAwNDk4NiAgbWZuOiAwMDAwNDk4Ng0KDQooWEVOKSBbMjAxMi0wOC0zMSAy
MTozMjozMV0gICBnZm46IDAwMDA0OTg3ICBtZm46IDAwMDA0OTg3DQoNCihYRU4pIFsyMDEy
LTA4LTMxIDIxOjMyOjMxXSAgIGdmbjogMDAwMDQ5ODggIG1mbjogMDAwMDQ5ODgNCg0KKFhF
TikgWzIwMTItMDgtMzEgMjE6MzI6MzFdICAgZ2ZuOiAwMDAwNDk4OSAgbWZuOiAwMDAwNDk4
OQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjozMV0gICBnZm46IDAwMDA0OThhICBtZm46
IDAwMDA0OThhDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjMxXSAgIGdmbjogMDAwMDQ5
OGIgIG1mbjogMDAwMDQ5OGINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MzFdICAgZ2Zu
OiAwMDAwNDk4YyAgbWZuOiAwMDAwNDk4Yw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoz
MV0gICBnZm46IDAwMDA0OThkICBtZm46IDAwMDA0OThkDQoNCihYRU4pIFsyMDEyLTA4LTMx
IDIxOjMyOjMxXSAgIGdmbjogMDAwMDQ5OGUgIG1mbjogMDAwMDQ5OGUNCg0KKFhFTikgWzIw
MTItMDgtMzEgMjE6MzI6MzFdICAgZ2ZuOiAwMDAwNDk4ZiAgbWZuOiAwMDAwNDk4Zg0KDQoo
WEVOKSBbMjAxMi0wOC0zMSAyMTozMjozMV0gICBnZm46IDAwMDA0OTkwICBtZm46IDAwMDA0
OTkwDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjMxXSAgIGdmbjogMDAwMDQ5OTEgIG1m
bjogMDAwMDQ5OTENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MzFdICAgZ2ZuOiAwMDAw
NDk5MiAgbWZuOiAwMDAwNDk5Mg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjozMV0gICBn
Zm46IDAwMDA0OTkzICBtZm46IDAwMDA0OTkzDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMy
OjMxXSAgIGdmbjogMDAwMDQ5OTQgIG1mbjogMDAwMDQ5OTQNCg0KKFhFTikgWzIwMTItMDgt
MzEgMjE6MzI6MzFdICAgZ2ZuOiAwMDAwNDk5NSAgbWZuOiAwMDAwNDk5NQ0KDQooWEVOKSBb
MjAxMi0wOC0zMSAyMTozMjozMV0gICBnZm46IDAwMDA0OTk2ICBtZm46IDAwMDA0OTk2DQoN
CihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjMxXSAgIGdmbjogMDAwMDQ5OTcgIG1mbjogMDAw
MDQ5OTcNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MzFdICAgZ2ZuOiAwMDAwNDk5OCAg
bWZuOiAwMDAwNDk5OA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjozMV0gICBnZm46IDAw
MDA0OTk5ICBtZm46IDAwMDA0OTk5DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjMxXSAg
IGdmbjogMDAwMDQ5OWEgIG1mbjogMDAwMDQ5OWENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6
MzI6MzFdICAgZ2ZuOiAwMDAwNDk5YiAgbWZuOiAwMDAwNDk5Yg0KDQooWEVOKSBbMjAxMi0w
OC0zMSAyMTozMjozMV0gICBnZm46IDAwMDA0OTljICBtZm46IDAwMDA0OTljDQoNCihYRU4p
IFsyMDEyLTA4LTMxIDIxOjMyOjMxXSAgIGdmbjogMDAwMDQ5OWQgIG1mbjogMDAwMDQ5OWQN
Cg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MzFdICAgZ2ZuOiAwMDAwNDk5ZSAgbWZuOiAw
MDAwNDk5ZQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjozMV0gICBnZm46IDAwMDA0OTlm
ICBtZm46IDAwMDA0OTlmDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjMxXSAgIGdmbjog
MDAwMDQ5YTAgIG1mbjogMDAwMDQ5YTANCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MzFd
ICAgZ2ZuOiAwMDAwNDlhMSAgbWZuOiAwMDAwNDlhMQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAy
MTozMjozMV0gICBnZm46IDAwMDA0OWEyICBtZm46IDAwMDA0OWEyDQoNCihYRU4pIFsyMDEy
LTA4LTMxIDIxOjMyOjMxXSAgIGdmbjogMDAwMDQ5YTMgIG1mbjogMDAwMDQ5YTMNCg0KKFhF
TikgWzIwMTItMDgtMzEgMjE6MzI6MzFdICAgZ2ZuOiAwMDAwNDlhNCAgbWZuOiAwMDAwNDlh
NA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjozMV0gICBnZm46IDAwMDA0OWE1ICBtZm46
IDAwMDA0OWE1DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjMxXSAgIGdmbjogMDAwMDQ5
YTYgIG1mbjogMDAwMDQ5YTYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MzFdICAgZ2Zu
OiAwMDAwNDlhNyAgbWZuOiAwMDAwNDlhNw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoz
MV0gICBnZm46IDAwMDA0OWE4ICBtZm46IDAwMDA0OWE4DQoNCihYRU4pIFsyMDEyLTA4LTMx
IDIxOjMyOjMxXSAgIGdmbjogMDAwMDQ5YTkgIG1mbjogMDAwMDQ5YTkNCg0KKFhFTikgWzIw
MTItMDgtMzEgMjE6MzI6MzFdICAgZ2ZuOiAwMDAwNDlhYSAgbWZuOiAwMDAwNDlhYQ0KDQoo
WEVOKSBbMjAxMi0wOC0zMSAyMTozMjozMV0gICBnZm46IDAwMDA0OWFiICBtZm46IDAwMDA0
OWFiDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjMxXSAgIGdmbjogMDAwMDQ5YWMgIG1m
bjogMDAwMDQ5YWMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MzFdICAgZ2ZuOiAwMDAw
NDlhZCAgbWZuOiAwMDAwNDlhZA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjozMV0gICBn
Zm46IDAwMDA0OWFlICBtZm46IDAwMDA0OWFlDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMy
OjMxXSAgIGdmbjogMDAwMDQ5YWYgIG1mbjogMDAwMDQ5YWYNCg0KKFhFTikgWzIwMTItMDgt
MzEgMjE6MzI6MzFdICAgZ2ZuOiAwMDAwNDliMCAgbWZuOiAwMDAwNDliMA0KDQooWEVOKSBb
MjAxMi0wOC0zMSAyMTozMjozMV0gICBnZm46IDAwMDA0OWIxICBtZm46IDAwMDA0OWIxDQoN
CihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjMxXSAgIGdmbjogMDAwMDQ5YjIgIG1mbjogMDAw
MDQ5YjINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MzFdICAgZ2ZuOiAwMDAwNDliMyAg
bWZuOiAwMDAwNDliMw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjozMV0gICBnZm46IDAw
MDA0OWI0ICBtZm46IDAwMDA0OWI0DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjMxXSAg
IGdmbjogMDAwMDQ5YjUgIG1mbjogMDAwMDQ5YjUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6
MzI6MzJdICAgZ2ZuOiAwMDAwNDliNiAgbWZuOiAwMDAwNDliNg0KDQooWEVOKSBbMjAxMi0w
OC0zMSAyMTozMjozMl0gICBnZm46IDAwMDA0OWI3ICBtZm46IDAwMDA0OWI3DQoNCihYRU4p
IFsyMDEyLTA4LTMxIDIxOjMyOjMyXSAgIGdmbjogMDAwMDQ5YjggIG1mbjogMDAwMDQ5YjgN
Cg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MzJdICAgZ2ZuOiAwMDAwNDliOSAgbWZuOiAw
MDAwNDliOQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjozMl0gICBnZm46IDAwMDA0OWJh
ICBtZm46IDAwMDA0OWJhDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjMyXSAgIGdmbjog
MDAwMDQ5YmIgIG1mbjogMDAwMDQ5YmINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MzJd
ICAgZ2ZuOiAwMDAwNDliYyAgbWZuOiAwMDAwNDliYw0KDQooWEVOKSBbMjAxMi0wOC0zMSAy
MTozMjozMl0gICBnZm46IDAwMDA0OWJkICBtZm46IDAwMDA0OWJkDQoNCihYRU4pIFsyMDEy
LTA4LTMxIDIxOjMyOjMyXSAgIGdmbjogMDAwMDQ5YmUgIG1mbjogMDAwMDQ5YmUNCg0KKFhF
TikgWzIwMTItMDgtMzEgMjE6MzI6MzJdICAgZ2ZuOiAwMDAwNDliZiAgbWZuOiAwMDAwNDli
Zg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjozMl0gICBnZm46IDAwMDA0OWMwICBtZm46
IDAwMDA0OWMwDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjMyXSAgIGdmbjogMDAwMDQ5
YzEgIG1mbjogMDAwMDQ5YzENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MzJdICAgZ2Zu
OiAwMDAwNDljMiAgbWZuOiAwMDAwNDljMg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoz
Ml0gICBnZm46IDAwMDA0OWMzICBtZm46IDAwMDA0OWMzDQoNCihYRU4pIFsyMDEyLTA4LTMx
IDIxOjMyOjMyXSAgIGdmbjogMDAwMDQ5YzQgIG1mbjogMDAwMDQ5YzQNCg0KKFhFTikgWzIw
MTItMDgtMzEgMjE6MzI6MzJdICAgZ2ZuOiAwMDAwNDljNSAgbWZuOiAwMDAwNDljNQ0KDQoo
WEVOKSBbMjAxMi0wOC0zMSAyMTozMjozMl0gICBnZm46IDAwMDA0OWM2ICBtZm46IDAwMDA0
OWM2DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjMyXSAgIGdmbjogMDAwMDQ5YzcgIG1m
bjogMDAwMDQ5YzcNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MzJdICAgZ2ZuOiAwMDAw
NDljOCAgbWZuOiAwMDAwNDljOA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjozMl0gICBn
Zm46IDAwMDA0OWM5ICBtZm46IDAwMDA0OWM5DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMy
OjMyXSAgIGdmbjogMDAwMDQ5Y2EgIG1mbjogMDAwMDQ5Y2ENCg0KKFhFTikgWzIwMTItMDgt
MzEgMjE6MzI6MzJdICAgZ2ZuOiAwMDAwNDljYiAgbWZuOiAwMDAwNDljYg0KDQooWEVOKSBb
MjAxMi0wOC0zMSAyMTozMjozMl0gICBnZm46IDAwMDA0OWNjICBtZm46IDAwMDA0OWNjDQoN
CihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjMyXSAgIGdmbjogMDAwMDQ5Y2QgIG1mbjogMDAw
MDQ5Y2QNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MzJdICAgZ2ZuOiAwMDAwNDljZSAg
bWZuOiAwMDAwNDljZQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjozMl0gICBnZm46IDAw
MDA0OWNmICBtZm46IDAwMDA0OWNmDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjMyXSAg
IGdmbjogMDAwMDQ5ZDAgIG1mbjogMDAwMDQ5ZDANCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6
MzI6MzJdICAgZ2ZuOiAwMDAwNDlkMSAgbWZuOiAwMDAwNDlkMQ0KDQooWEVOKSBbMjAxMi0w
OC0zMSAyMTozMjozMl0gICBnZm46IDAwMDA0OWQyICBtZm46IDAwMDA0OWQyDQoNCihYRU4p
IFsyMDEyLTA4LTMxIDIxOjMyOjMyXSAgIGdmbjogMDAwMDQ5ZDMgIG1mbjogMDAwMDQ5ZDMN
Cg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MzJdICAgZ2ZuOiAwMDAwNDlkNCAgbWZuOiAw
MDAwNDlkNA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjozMl0gICBnZm46IDAwMDA0OWQ1
ICBtZm46IDAwMDA0OWQ1DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjMyXSAgIGdmbjog
MDAwMDQ5ZDYgIG1mbjogMDAwMDQ5ZDYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MzJd
ICAgZ2ZuOiAwMDAwNDlkNyAgbWZuOiAwMDAwNDlkNw0KDQooWEVOKSBbMjAxMi0wOC0zMSAy
MTozMjozMl0gICBnZm46IDAwMDA0OWQ4ICBtZm46IDAwMDA0OWQ4DQoNCihYRU4pIFsyMDEy
LTA4LTMxIDIxOjMyOjMyXSAgIGdmbjogMDAwMDQ5ZDkgIG1mbjogMDAwMDQ5ZDkNCg0KKFhF
TikgWzIwMTItMDgtMzEgMjE6MzI6MzJdICAgZ2ZuOiAwMDAwNDlkYSAgbWZuOiAwMDAwNDlk
YQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjozMl0gICBnZm46IDAwMDA0OWRiICBtZm46
IDAwMDA0OWRiDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjMyXSAgIGdmbjogMDAwMDQ5
ZGMgIG1mbjogMDAwMDQ5ZGMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MzJdICAgZ2Zu
OiAwMDAwNDlkZCAgbWZuOiAwMDAwNDlkZA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoz
Ml0gICBnZm46IDAwMDA0OWRlICBtZm46IDAwMDA0OWRlDQoNCihYRU4pIFsyMDEyLTA4LTMx
IDIxOjMyOjMyXSAgIGdmbjogMDAwMDQ5ZGYgIG1mbjogMDAwMDQ5ZGYNCg0KKFhFTikgWzIw
MTItMDgtMzEgMjE6MzI6MzJdICAgZ2ZuOiAwMDAwNDllMCAgbWZuOiAwMDAwNDllMA0KDQoo
WEVOKSBbMjAxMi0wOC0zMSAyMTozMjozMl0gICBnZm46IDAwMDA0OWUxICBtZm46IDAwMDA0
OWUxDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjMyXSAgIGdmbjogMDAwMDQ5ZTIgIG1m
bjogMDAwMDQ5ZTINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MzJdICAgZ2ZuOiAwMDAw
NDllMyAgbWZuOiAwMDAwNDllMw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjozMl0gICBn
Zm46IDAwMDA0OWU0ICBtZm46IDAwMDA0OWU0DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMy
OjMyXSAgIGdmbjogMDAwMDQ5ZTUgIG1mbjogMDAwMDQ5ZTUNCg0KKFhFTikgWzIwMTItMDgt
MzEgMjE6MzI6MzJdICAgZ2ZuOiAwMDAwNDllNiAgbWZuOiAwMDAwNDllNg0KDQooWEVOKSBb
MjAxMi0wOC0zMSAyMTozMjozMl0gICBnZm46IDAwMDA0OWU3ICBtZm46IDAwMDA0OWU3DQoN
CihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjMyXSAgIGdmbjogMDAwMDQ5ZTggIG1mbjogMDAw
MDQ5ZTgNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MzJdICAgZ2ZuOiAwMDAwNDllOSAg
bWZuOiAwMDAwNDllOQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjozMl0gICBnZm46IDAw
MDA0OWVhICBtZm46IDAwMDA0OWVhDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjMyXSAg
IGdmbjogMDAwMDQ5ZWIgIG1mbjogMDAwMDQ5ZWINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6
MzI6MzJdICAgZ2ZuOiAwMDAwNDllYyAgbWZuOiAwMDAwNDllYw0KDQooWEVOKSBbMjAxMi0w
OC0zMSAyMTozMjozMl0gICBnZm46IDAwMDA0OWVkICBtZm46IDAwMDA0OWVkDQoNCihYRU4p
IFsyMDEyLTA4LTMxIDIxOjMyOjMyXSAgIGdmbjogMDAwMDQ5ZWUgIG1mbjogMDAwMDQ5ZWUN
Cg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MzJdICAgZ2ZuOiAwMDAwNDllZiAgbWZuOiAw
MDAwNDllZg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjozMl0gICBnZm46IDAwMDA0OWYw
ICBtZm46IDAwMDA0OWYwDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjMyXSAgIGdmbjog
MDAwMDQ5ZjEgIG1mbjogMDAwMDQ5ZjENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MzJd
ICAgZ2ZuOiAwMDAwNDlmMiAgbWZuOiAwMDAwNDlmMg0KDQooWEVOKSBbMjAxMi0wOC0zMSAy
MTozMjozMl0gICBnZm46IDAwMDA0OWYzICBtZm46IDAwMDA0OWYzDQoNCihYRU4pIFsyMDEy
LTA4LTMxIDIxOjMyOjMyXSAgIGdmbjogMDAwMDQ5ZjQgIG1mbjogMDAwMDQ5ZjQNCg0KKFhF
TikgWzIwMTItMDgtMzEgMjE6MzI6MzJdICAgZ2ZuOiAwMDAwNDlmNSAgbWZuOiAwMDAwNDlm
NQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjozM10gICBnZm46IDAwMDA0OWY2ICBtZm46
IDAwMDA0OWY2DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjMzXSAgIGdmbjogMDAwMDQ5
ZjcgIG1mbjogMDAwMDQ5ZjcNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MzNdICAgZ2Zu
OiAwMDAwNDlmOCAgbWZuOiAwMDAwNDlmOA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoz
M10gICBnZm46IDAwMDA0OWY5ICBtZm46IDAwMDA0OWY5DQoNCihYRU4pIFsyMDEyLTA4LTMx
IDIxOjMyOjMzXSAgIGdmbjogMDAwMDQ5ZmEgIG1mbjogMDAwMDQ5ZmENCg0KKFhFTikgWzIw
MTItMDgtMzEgMjE6MzI6MzNdICAgZ2ZuOiAwMDAwNDlmYiAgbWZuOiAwMDAwNDlmYg0KDQoo
WEVOKSBbMjAxMi0wOC0zMSAyMTozMjozM10gICBnZm46IDAwMDA0OWZjICBtZm46IDAwMDA0
OWZjDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjMzXSAgIGdmbjogMDAwMDQ5ZmQgIG1m
bjogMDAwMDQ5ZmQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MzNdICAgZ2ZuOiAwMDAw
NDlmZSAgbWZuOiAwMDAwNDlmZQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjozM10gICBn
Zm46IDAwMDA0OWZmICBtZm46IDAwMDA0OWZmDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMy
OjMzXSAgIGdmbjogMDAwMDRhMDAgIG1mbjogMDAwMDRhMDANCg0KKFhFTikgWzIwMTItMDgt
MzEgMjE6MzI6MzNdICAgZ2ZuOiAwMDAwNGEwMSAgbWZuOiAwMDAwNGEwMQ0KDQooWEVOKSBb
MjAxMi0wOC0zMSAyMTozMjozM10gICBnZm46IDAwMDA0YTAyICBtZm46IDAwMDA0YTAyDQoN
CihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjMzXSAgIGdmbjogMDAwMDRhMDMgIG1mbjogMDAw
MDRhMDMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MzNdICAgZ2ZuOiAwMDAwNGEwNCAg
bWZuOiAwMDAwNGEwNA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjozM10gICBnZm46IDAw
MDA0YTA1ICBtZm46IDAwMDA0YTA1DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjMzXSAg
IGdmbjogMDAwMDRhMDYgIG1mbjogMDAwMDRhMDYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6
MzI6MzNdICAgZ2ZuOiAwMDAwNGEwNyAgbWZuOiAwMDAwNGEwNw0KDQooWEVOKSBbMjAxMi0w
OC0zMSAyMTozMjozM10gICBnZm46IDAwMDA0YTA4ICBtZm46IDAwMDA0YTA4DQoNCihYRU4p
IFsyMDEyLTA4LTMxIDIxOjMyOjMzXSAgIGdmbjogMDAwMDRhMDkgIG1mbjogMDAwMDRhMDkN
Cg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MzNdICAgZ2ZuOiAwMDAwNGEwYSAgbWZuOiAw
MDAwNGEwYQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjozM10gICBnZm46IDAwMDA0YTBi
ICBtZm46IDAwMDA0YTBiDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjMzXSAgIGdmbjog
MDAwMDRhMGMgIG1mbjogMDAwMDRhMGMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MzNd
ICAgZ2ZuOiAwMDAwNGEwZCAgbWZuOiAwMDAwNGEwZA0KDQooWEVOKSBbMjAxMi0wOC0zMSAy
MTozMjozM10gICBnZm46IDAwMDA0YTBlICBtZm46IDAwMDA0YTBlDQoNCihYRU4pIFsyMDEy
LTA4LTMxIDIxOjMyOjMzXSAgIGdmbjogMDAwMDRhMGYgIG1mbjogMDAwMDRhMGYNCg0KKFhF
TikgWzIwMTItMDgtMzEgMjE6MzI6MzNdICAgZ2ZuOiAwMDAwNGExMCAgbWZuOiAwMDAwNGEx
MA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjozM10gICBnZm46IDAwMDA0YTExICBtZm46
IDAwMDA0YTExDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjMzXSAgIGdmbjogMDAwMDRh
MTIgIG1mbjogMDAwMDRhMTINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MzNdICAgZ2Zu
OiAwMDAwNGExMyAgbWZuOiAwMDAwNGExMw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoz
M10gICBnZm46IDAwMDA0YTE0ICBtZm46IDAwMDA0YTE0DQoNCihYRU4pIFsyMDEyLTA4LTMx
IDIxOjMyOjMzXSAgIGdmbjogMDAwMDRhMTUgIG1mbjogMDAwMDRhMTUNCg0KKFhFTikgWzIw
MTItMDgtMzEgMjE6MzI6MzNdICAgZ2ZuOiAwMDAwNGExNiAgbWZuOiAwMDAwNGExNg0KDQoo
WEVOKSBbMjAxMi0wOC0zMSAyMTozMjozM10gICBnZm46IDAwMDA0YTE3ICBtZm46IDAwMDA0
YTE3DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjMzXSAgIGdmbjogMDAwMDRhMTggIG1m
bjogMDAwMDRhMTgNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MzNdICAgZ2ZuOiAwMDAw
NGExOSAgbWZuOiAwMDAwNGExOQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjozM10gICBn
Zm46IDAwMDA0YTFhICBtZm46IDAwMDA0YTFhDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMy
OjMzXSAgIGdmbjogMDAwMDRhMWIgIG1mbjogMDAwMDRhMWINCg0KKFhFTikgWzIwMTItMDgt
MzEgMjE6MzI6MzNdICAgZ2ZuOiAwMDAwNGExYyAgbWZuOiAwMDAwNGExYw0KDQooWEVOKSBb
MjAxMi0wOC0zMSAyMTozMjozM10gICBnZm46IDAwMDA0YTFkICBtZm46IDAwMDA0YTFkDQoN
CihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjMzXSAgIGdmbjogMDAwMDRhMWUgIG1mbjogMDAw
MDRhMWUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MzNdICAgZ2ZuOiAwMDAwNGExZiAg
bWZuOiAwMDAwNGExZg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjozM10gICBnZm46IDAw
MDA0YTIwICBtZm46IDAwMDA0YTIwDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjMzXSAg
IGdmbjogMDAwMDRhMjEgIG1mbjogMDAwMDRhMjENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6
MzI6MzNdICAgZ2ZuOiAwMDAwNGEyMiAgbWZuOiAwMDAwNGEyMg0KDQooWEVOKSBbMjAxMi0w
OC0zMSAyMTozMjozM10gICBnZm46IDAwMDA0YTIzICBtZm46IDAwMDA0YTIzDQoNCihYRU4p
IFsyMDEyLTA4LTMxIDIxOjMyOjMzXSAgIGdmbjogMDAwMDRhMjQgIG1mbjogMDAwMDRhMjQN
Cg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MzNdICAgZ2ZuOiAwMDAwNGEyNSAgbWZuOiAw
MDAwNGEyNQ0KDQpbICA0MTkuNzI3NTc1XSBhdGExLjAwOiBxYyB0aW1lbyhYRU4pIFsyMDEy
LTA4LTMxIDIxOjMyOjMzXSAgIGdmbjogMDAwMDRhMjYgIG1mbjogMDAwMDRhMjYNCg0KdXQg
KGNtZCAweGVjKQ0KDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjMzXSAgIGdmbjogMDAw
MDRhMjcgIG1mbjogMDAwMDRhMjcNCg0KWyAgNDE5Ljc4NTU2OV0gYXRhMS4wMDogZmFpbGVk
IHQoWEVOKSBbMjAxMi0wOC0zMSAyMTozMjozM10gICBnZm46IDAwMDA0YTI4ICBtZm46IDAw
MDA0YTI4DQoNCm8gSURFTlRJRlkgKEkvTyAoWEVOKSBbMjAxMi0wOC0zMSAyMTozMjozM10g
ICBnZm46IDAwMDA0YTI5ICBtZm46IDAwMDA0YTI5DQoNCmVycm9yLCBlcnJfbWFzaz0weDQp
DQoNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MzNdICAgZ2ZuOiAwMDAwNGEyYSAgbWZu
OiAwMDAwNGEyYQ0KDQpbICA0MTkuODUxOTg1XSBhKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6
MzNdICAgZ2ZuOiAwMDAwNGEyYiAgbWZuOiAwMDAwNGEyYg0KDQp0YTEuMDA6IHJldmFsaWRh
KFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MzNdICAgZ2ZuOiAwMDAwNGEyYyAgbWZuOiAwMDAw
NGEyYw0KDQp0aW9uIGZhaWxlZCAoZXJyKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MzNdICAg
Z2ZuOiAwMDAwNGEyZCAgbWZuOiAwMDAwNGEyZA0KDQpubz0tNSkNCg0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMjozM10gICBnZm46IDAwMDA0YTJlICBtZm46IDAwMDA0YTJlDQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMyOjMzXSAgIGdmbjogMDAwMDRhMmYgIG1mbjogMDAwMDRh
MmYNCg0KWyAgNDE5LjkzMTA1MV0gYXRhMTogaGFyZCByZXNldHQoWEVOKSBbMjAxMi0wOC0z
MSAyMTozMjozM10gICBnZm46IDAwMDA0YTMwICBtZm46IDAwMDA0YTMwDQoNCmluZyBsaW5r
DQoNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MzNdICAgZ2ZuOiAwMDAwNGEzMSAgbWZu
OiAwMDAwNGEzMQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjozNF0gICBnZm46IDAwMDA0
YTMyICBtZm46IDAwMDA0YTMyDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjM0XSAgIGdm
bjogMDAwMDRhMzMgIG1mbjogMDAwMDRhMzMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6
MzRdICAgZ2ZuOiAwMDAwNGEzNCAgbWZuOiAwMDAwNGEzNA0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMjozNF0gICBnZm46IDAwMDA0YTM1ICBtZm46IDAwMDA0YTM1DQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMyOjM0XSAgIGdmbjogMDAwMDRhMzYgIG1mbjogMDAwMDRhMzYNCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MzRdICAgZ2ZuOiAwMDAwNGEzNyAgbWZuOiAwMDAw
NGEzNw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjozNF0gICBnZm46IDAwMDA0YTM4ICBt
Zm46IDAwMDA0YTM4DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjM0XSAgIGdmbjogMDAw
MDRhMzkgIG1mbjogMDAwMDRhMzkNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MzRdICAg
Z2ZuOiAwMDAwNGEzYSAgbWZuOiAwMDAwNGEzYQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
MjozNF0gICBnZm46IDAwMDA0YTNiICBtZm46IDAwMDA0YTNiDQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMyOjM0XSAgIGdmbjogMDAwMDRhM2MgIG1mbjogMDAwMDRhM2MNCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzI6MzRdICAgZ2ZuOiAwMDAwNGEzZCAgbWZuOiAwMDAwNGEzZA0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjozNF0gICBnZm46IDAwMDA0YTNlICBtZm46IDAw
MDA0YTNlDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjM0XSAgIGdmbjogMDAwMDRhM2Yg
IG1mbjogMDAwMDRhM2YNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MzRdICAgZ2ZuOiAw
MDAwNGE0MCAgbWZuOiAwMDAwNGE0MA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjozNF0g
ICBnZm46IDAwMDA0YTQxICBtZm46IDAwMDA0YTQxDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMyOjM0XSAgIGdmbjogMDAwMDRhNDIgIG1mbjogMDAwMDRhNDINCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzI6MzRdICAgZ2ZuOiAwMDAwNGE0MyAgbWZuOiAwMDAwNGE0Mw0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMjozNF0gICBnZm46IDAwMDA0YTQ0ICBtZm46IDAwMDA0YTQ0
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjM0XSAgIGdmbjogMDAwMDRhNDUgIG1mbjog
MDAwMDRhNDUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MzRdICAgZ2ZuOiAwMDAwNGE0
NiAgbWZuOiAwMDAwNGE0Ng0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjozNF0gICBnZm46
IDAwMDA0YTQ3ICBtZm46IDAwMDA0YTQ3DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjM0
XSAgIGdmbjogMDAwMDRhNDggIG1mbjogMDAwMDRhNDgNCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzI6MzRdICAgZ2ZuOiAwMDAwNGE0OSAgbWZuOiAwMDAwNGE0OQ0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMjozNF0gICBnZm46IDAwMDA0YTRhICBtZm46IDAwMDA0YTRhDQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMyOjM0XSAgIGdmbjogMDAwMDRhNGIgIG1mbjogMDAwMDRh
NGINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MzRdICAgZ2ZuOiAwMDAwNGE0YyAgbWZu
OiAwMDAwNGE0Yw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjozNF0gICBnZm46IDAwMDA0
YTRkICBtZm46IDAwMDA0YTRkDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjM0XSAgIGdm
bjogMDAwMDRhNGUgIG1mbjogMDAwMDRhNGUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6
MzRdICAgZ2ZuOiAwMDAwNGE0ZiAgbWZuOiAwMDAwNGE0Zg0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMjozNF0gICBnZm46IDAwMDA0YTUwICBtZm46IDAwMDA0YTUwDQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMyOjM0XSAgIGdmbjogMDAwMDRhNTEgIG1mbjogMDAwMDRhNTENCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MzRdICAgZ2ZuOiAwMDAwNGE1MiAgbWZuOiAwMDAw
NGE1Mg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjozNF0gICBnZm46IDAwMDA0YTUzICBt
Zm46IDAwMDA0YTUzDQoNClsgIDQyMC41MDA5ODFdIGF0YTE6IFNBVEEgbGluayB1KFhFTikg
WzIwMTItMDgtMzEgMjE6MzI6MzRdICAgZ2ZuOiAwMDAwNGE1NCAgbWZuOiAwMDAwNGE1NA0K
DQpwIDMuMCBHYnBzIChTU3RhKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MzRdICAgZ2ZuOiAw
MDAwNGE1NSAgbWZuOiAwMDAwNGE1NQ0KDQp0dXMgMTIzIFNDb250cm9sIDMwMCkNCg0KDQoo
WEVOKSBbMjAxMi0wOC0zMSAyMTozMjozNF0gICBnZm46IDAwMDA0YTU2ICBtZm46IDAwMDA0
YTU2DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjM0XSAgIGdmbjogMDAwMDRhNTcgIG1m
bjogMDAwMDRhNTcNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MzRdICAgZ2ZuOiAwMDAw
NGE1OCAgbWZuOiAwMDAwNGE1OA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjozNF0gICBn
Zm46IDAwMDA0YTU5ICBtZm46IDAwMDA0YTU5DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMy
OjM0XSAgIGdmbjogMDAwMDRhNWEgIG1mbjogMDAwMDRhNWENCg0KKFhFTikgWzIwMTItMDgt
MzEgMjE6MzI6MzRdICAgZ2ZuOiAwMDAwNGE1YiAgbWZuOiAwMDAwNGE1Yg0KDQooWEVOKSBb
MjAxMi0wOC0zMSAyMTozMjozNF0gICBnZm46IDAwMDA0YTVjICBtZm46IDAwMDA0YTVjDQoN
CihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjM0XSAgIGdmbjogMDAwMDRhNWQgIG1mbjogMDAw
MDRhNWQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MzRdICAgZ2ZuOiAwMDAwNGE1ZSAg
bWZuOiAwMDAwNGE1ZQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjozNF0gICBnZm46IDAw
MDA0YTVmICBtZm46IDAwMDA0YTVmDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjM0XSAg
IGdmbjogMDAwMDRhNjAgIG1mbjogMDAwMDRhNjANCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6
MzI6MzRdICAgZ2ZuOiAwMDAwNGE2MSAgbWZuOiAwMDAwNGE2MQ0KDQooWEVOKSBbMjAxMi0w
OC0zMSAyMTozMjozNF0gICBnZm46IDAwMDA0YTYyICBtZm46IDAwMDA0YTYyDQoNCihYRU4p
IFsyMDEyLTA4LTMxIDIxOjMyOjM0XSAgIGdmbjogMDAwMDRhNjMgIG1mbjogMDAwMDRhNjMN
Cg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MzRdICAgZ2ZuOiAwMDAwNGE2NCAgbWZuOiAw
MDAwNGE2NA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjozNF0gICBnZm46IDAwMDA0YTY1
ICBtZm46IDAwMDA0YTY1DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjM0XSAgIGdmbjog
MDAwMDRhNjYgIG1mbjogMDAwMDRhNjYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MzRd
ICAgZ2ZuOiAwMDAwNGE2NyAgbWZuOiAwMDAwNGE2Nw0KDQooWEVOKSBbMjAxMi0wOC0zMSAy
MTozMjozNF0gICBnZm46IDAwMDA0YTY4ICBtZm46IDAwMDA0YTY4DQoNCihYRU4pIFsyMDEy
LTA4LTMxIDIxOjMyOjM0XSAgIGdmbjogMDAwMDRhNjkgIG1mbjogMDAwMDRhNjkNCg0KKFhF
TikgWzIwMTItMDgtMzEgMjE6MzI6MzRdICAgZ2ZuOiAwMDAwNGE2YSAgbWZuOiAwMDAwNGE2
YQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjozNF0gICBnZm46IDAwMDA0YTZiICBtZm46
IDAwMDA0YTZiDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjM0XSAgIGdmbjogMDAwMDRh
NmMgIG1mbjogMDAwMDRhNmMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MzRdICAgZ2Zu
OiAwMDAwNGE2ZCAgbWZuOiAwMDAwNGE2ZA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoz
NF0gICBnZm46IDAwMDA0YTZlICBtZm46IDAwMDA0YTZlDQoNCihYRU4pIFsyMDEyLTA4LTMx
IDIxOjMyOjM0XSAgIGdmbjogMDAwMDRhNmYgIG1mbjogMDAwMDRhNmYNCg0KKFhFTikgWzIw
MTItMDgtMzEgMjE6MzI6MzRdICAgZ2ZuOiAwMDAwNGE3MCAgbWZuOiAwMDAwNGE3MA0KDQoo
WEVOKSBbMjAxMi0wOC0zMSAyMTozMjozNV0gICBnZm46IDAwMDA0YTcxICBtZm46IDAwMDA0
YTcxDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjM1XSAgIGdmbjogMDAwMDRhNzIgIG1m
bjogMDAwMDRhNzINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MzVdICAgZ2ZuOiAwMDAw
NGE3MyAgbWZuOiAwMDAwNGE3Mw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjozNV0gICBn
Zm46IDAwMDA0YTc0ICBtZm46IDAwMDA0YTc0DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMy
OjM1XSAgIGdmbjogMDAwMDRhNzUgIG1mbjogMDAwMDRhNzUNCg0KKFhFTikgWzIwMTItMDgt
MzEgMjE6MzI6MzVdICAgZ2ZuOiAwMDAwNGE3NiAgbWZuOiAwMDAwNGE3Ng0KDQooWEVOKSBb
MjAxMi0wOC0zMSAyMTozMjozNV0gICBnZm46IDAwMDA0YTc3ICBtZm46IDAwMDA0YTc3DQoN
CihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjM1XSAgIGdmbjogMDAwMDRhNzggIG1mbjogMDAw
MDRhNzgNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MzVdICAgZ2ZuOiAwMDAwNGE3OSAg
bWZuOiAwMDAwNGE3OQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjozNV0gICBnZm46IDAw
MDA0YTdhICBtZm46IDAwMDA0YTdhDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjM1XSAg
IGdmbjogMDAwMDRhN2IgIG1mbjogMDAwMDRhN2INCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6
MzI6MzVdICAgZ2ZuOiAwMDAwNGE3YyAgbWZuOiAwMDAwNGE3Yw0KDQooWEVOKSBbMjAxMi0w
OC0zMSAyMTozMjozNV0gICBnZm46IDAwMDA0YTdkICBtZm46IDAwMDA0YTdkDQoNCihYRU4p
IFsyMDEyLTA4LTMxIDIxOjMyOjM1XSAgIGdmbjogMDAwMDRhN2UgIG1mbjogMDAwMDRhN2UN
Cg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MzVdICAgZ2ZuOiAwMDAwNGE3ZiAgbWZuOiAw
MDAwNGE3Zg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjozNV0gICBnZm46IDAwMDA0YTgw
ICBtZm46IDAwMDA0YTgwDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjM1XSAgIGdmbjog
MDAwMDRhODEgIG1mbjogMDAwMDRhODENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MzVd
ICAgZ2ZuOiAwMDAwNGE4MiAgbWZuOiAwMDAwNGE4Mg0KDQooWEVOKSBbMjAxMi0wOC0zMSAy
MTozMjozNV0gICBnZm46IDAwMDA0YTgzICBtZm46IDAwMDA0YTgzDQoNCihYRU4pIFsyMDEy
LTA4LTMxIDIxOjMyOjM1XSAgIGdmbjogMDAwMDRhODQgIG1mbjogMDAwMDRhODQNCg0KKFhF
TikgWzIwMTItMDgtMzEgMjE6MzI6MzVdICAgZ2ZuOiAwMDAwNGE4NSAgbWZuOiAwMDAwNGE4
NQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjozNV0gICBnZm46IDAwMDA0YTg2ICBtZm46
IDAwMDA0YTg2DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjM1XSAgIGdmbjogMDAwMDRh
ODcgIG1mbjogMDAwMDRhODcNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MzVdICAgZ2Zu
OiAwMDAwNGE4OCAgbWZuOiAwMDAwNGE4OA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoz
NV0gICBnZm46IDAwMDA0YTg5ICBtZm46IDAwMDA0YTg5DQoNCihYRU4pIFsyMDEyLTA4LTMx
IDIxOjMyOjM1XSAgIGdmbjogMDAwMDRhOGEgIG1mbjogMDAwMDRhOGENCg0KKFhFTikgWzIw
MTItMDgtMzEgMjE6MzI6MzVdICAgZ2ZuOiAwMDAwNGE4YiAgbWZuOiAwMDAwNGE4Yg0KDQoo
WEVOKSBbMjAxMi0wOC0zMSAyMTozMjozNV0gICBnZm46IDAwMDA0YThjICBtZm46IDAwMDA0
YThjDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjM1XSAgIGdmbjogMDAwMDRhOGQgIG1m
bjogMDAwMDRhOGQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MzVdICAgZ2ZuOiAwMDAw
NGE4ZSAgbWZuOiAwMDAwNGE4ZQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjozNV0gICBn
Zm46IDAwMDA0YThmICBtZm46IDAwMDA0YThmDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMy
OjM1XSAgIGdmbjogMDAwMDRhOTAgIG1mbjogMDAwMDRhOTANCg0KKFhFTikgWzIwMTItMDgt
MzEgMjE6MzI6MzVdICAgZ2ZuOiAwMDAwNGE5MSAgbWZuOiAwMDAwNGE5MQ0KDQooWEVOKSBb
MjAxMi0wOC0zMSAyMTozMjozNV0gICBnZm46IDAwMDA0YTkyICBtZm46IDAwMDA0YTkyDQoN
CihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjM1XSAgIGdmbjogMDAwMDRhOTMgIG1mbjogMDAw
MDRhOTMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MzVdICAgZ2ZuOiAwMDAwNGE5NCAg
bWZuOiAwMDAwNGE5NA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjozNV0gICBnZm46IDAw
MDA0YTk1ICBtZm46IDAwMDA0YTk1DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjM1XSAg
IGdmbjogMDAwMDRhOTYgIG1mbjogMDAwMDRhOTYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6
MzI6MzVdICAgZ2ZuOiAwMDAwNGE5NyAgbWZuOiAwMDAwNGE5Nw0KDQooWEVOKSBbMjAxMi0w
OC0zMSAyMTozMjozNV0gICBnZm46IDAwMDA0YTk4ICBtZm46IDAwMDA0YTk4DQoNCihYRU4p
IFsyMDEyLTA4LTMxIDIxOjMyOjM1XSAgIGdmbjogMDAwMDRhOTkgIG1mbjogMDAwMDRhOTkN
Cg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MzVdICAgZ2ZuOiAwMDAwNGE5YSAgbWZuOiAw
MDAwNGE5YQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjozNV0gICBnZm46IDAwMDA0YTli
ICBtZm46IDAwMDA0YTliDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjM1XSAgIGdmbjog
MDAwMDRhOWMgIG1mbjogMDAwMDRhOWMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MzVd
ICAgZ2ZuOiAwMDAwNGE5ZCAgbWZuOiAwMDAwNGE5ZA0KDQooWEVOKSBbMjAxMi0wOC0zMSAy
MTozMjozNV0gICBnZm46IDAwMDA0YTllICBtZm46IDAwMDA0YTllDQoNCihYRU4pIFsyMDEy
LTA4LTMxIDIxOjMyOjM1XSAgIGdmbjogMDAwMDRhOWYgIG1mbjogMDAwMDRhOWYNCg0KKFhF
TikgWzIwMTItMDgtMzEgMjE6MzI6MzVdICAgZ2ZuOiAwMDAwNGFhMCAgbWZuOiAwMDAwNGFh
MA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjozNV0gICBnZm46IDAwMDA0YWExICBtZm46
IDAwMDA0YWExDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjM1XSAgIGdmbjogMDAwMDRh
YTIgIG1mbjogMDAwMDRhYTINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MzVdICAgZ2Zu
OiAwMDAwNGFhMyAgbWZuOiAwMDAwNGFhMw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoz
NV0gICBnZm46IDAwMDA0YWE0ICBtZm46IDAwMDA0YWE0DQoNCihYRU4pIFsyMDEyLTA4LTMx
IDIxOjMyOjM1XSAgIGdmbjogMDAwMDRhYTUgIG1mbjogMDAwMDRhYTUNCg0KKFhFTikgWzIw
MTItMDgtMzEgMjE6MzI6MzVdICAgZ2ZuOiAwMDAwNGFhNiAgbWZuOiAwMDAwNGFhNg0KDQoo
WEVOKSBbMjAxMi0wOC0zMSAyMTozMjozNV0gICBnZm46IDAwMDA0YWE3ICBtZm46IDAwMDA0
YWE3DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjM1XSAgIGdmbjogMDAwMDRhYTggIG1m
bjogMDAwMDRhYTgNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MzVdICAgZ2ZuOiAwMDAw
NGFhOSAgbWZuOiAwMDAwNGFhOQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjozNV0gICBn
Zm46IDAwMDA0YWFhICBtZm46IDAwMDA0YWFhDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMy
OjM1XSAgIGdmbjogMDAwMDRhYWIgIG1mbjogMDAwMDRhYWINCg0KKFhFTikgWzIwMTItMDgt
MzEgMjE6MzI6MzVdICAgZ2ZuOiAwMDAwNGFhYyAgbWZuOiAwMDAwNGFhYw0KDQooWEVOKSBb
MjAxMi0wOC0zMSAyMTozMjozNV0gICBnZm46IDAwMDA0YWFkICBtZm46IDAwMDA0YWFkDQoN
CihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjM1XSAgIGdmbjogMDAwMDRhYWUgIG1mbjogMDAw
MDRhYWUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MzVdICAgZ2ZuOiAwMDAwNGFhZiAg
bWZuOiAwMDAwNGFhZg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjozNV0gICBnZm46IDAw
MDA0YWIwICBtZm46IDAwMDA0YWIwDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjM2XSAg
IGdmbjogMDAwMDRhYjEgIG1mbjogMDAwMDRhYjENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6
MzI6MzZdICAgZ2ZuOiAwMDAwNGFiMiAgbWZuOiAwMDAwNGFiMg0KDQooWEVOKSBbMjAxMi0w
OC0zMSAyMTozMjozNl0gICBnZm46IDAwMDA0YWIzICBtZm46IDAwMDA0YWIzDQoNCihYRU4p
IFsyMDEyLTA4LTMxIDIxOjMyOjM2XSAgIGdmbjogMDAwMDRhYjQgIG1mbjogMDAwMDRhYjQN
Cg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MzZdICAgZ2ZuOiAwMDAwNGFiNSAgbWZuOiAw
MDAwNGFiNQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjozNl0gICBnZm46IDAwMDA0YWI2
ICBtZm46IDAwMDA0YWI2DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjM2XSAgIGdmbjog
MDAwMDRhYjcgIG1mbjogMDAwMDRhYjcNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MzZd
ICAgZ2ZuOiAwMDAwNGFiOCAgbWZuOiAwMDAwNGFiOA0KDQooWEVOKSBbMjAxMi0wOC0zMSAy
MTozMjozNl0gICBnZm46IDAwMDA0YWI5ICBtZm46IDAwMDA0YWI5DQoNCihYRU4pIFsyMDEy
LTA4LTMxIDIxOjMyOjM2XSAgIGdmbjogMDAwMDRhYmEgIG1mbjogMDAwMDRhYmENCg0KKFhF
TikgWzIwMTItMDgtMzEgMjE6MzI6MzZdICAgZ2ZuOiAwMDAwNGFiYiAgbWZuOiAwMDAwNGFi
Yg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjozNl0gICBnZm46IDAwMDA0YWJjICBtZm46
IDAwMDA0YWJjDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjM2XSAgIGdmbjogMDAwMDRh
YmQgIG1mbjogMDAwMDRhYmQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MzZdICAgZ2Zu
OiAwMDAwNGFiZSAgbWZuOiAwMDAwNGFiZQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoz
Nl0gICBnZm46IDAwMDA0YWJmICBtZm46IDAwMDA0YWJmDQoNCihYRU4pIFsyMDEyLTA4LTMx
IDIxOjMyOjM2XSAgIGdmbjogMDAwMDRhYzAgIG1mbjogMDAwMDRhYzANCg0KKFhFTikgWzIw
MTItMDgtMzEgMjE6MzI6MzZdICAgZ2ZuOiAwMDAwNGFjMSAgbWZuOiAwMDAwNGFjMQ0KDQoo
WEVOKSBbMjAxMi0wOC0zMSAyMTozMjozNl0gICBnZm46IDAwMDA0YWMyICBtZm46IDAwMDA0
YWMyDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjM2XSAgIGdmbjogMDAwMDRhYzMgIG1m
bjogMDAwMDRhYzMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MzZdICAgZ2ZuOiAwMDAw
NGFjNCAgbWZuOiAwMDAwNGFjNA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjozNl0gICBn
Zm46IDAwMDA0YWM1ICBtZm46IDAwMDA0YWM1DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMy
OjM2XSAgIGdmbjogMDAwMDRhYzYgIG1mbjogMDAwMDRhYzYNCg0KKFhFTikgWzIwMTItMDgt
MzEgMjE6MzI6MzZdICAgZ2ZuOiAwMDAwNGFjNyAgbWZuOiAwMDAwNGFjNw0KDQooWEVOKSBb
MjAxMi0wOC0zMSAyMTozMjozNl0gICBnZm46IDAwMDA0YWM4ICBtZm46IDAwMDA0YWM4DQoN
CihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjM2XSAgIGdmbjogMDAwMDRhYzkgIG1mbjogMDAw
MDRhYzkNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MzZdICAgZ2ZuOiAwMDAwNGFjYSAg
bWZuOiAwMDAwNGFjYQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjozNl0gICBnZm46IDAw
MDA0YWNiICBtZm46IDAwMDA0YWNiDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjM2XSAg
IGdmbjogMDAwMDRhY2MgIG1mbjogMDAwMDRhY2MNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6
MzI6MzZdICAgZ2ZuOiAwMDAwNGFjZCAgbWZuOiAwMDAwNGFjZA0KDQooWEVOKSBbMjAxMi0w
OC0zMSAyMTozMjozNl0gICBnZm46IDAwMDA0YWNlICBtZm46IDAwMDA0YWNlDQoNCihYRU4p
IFsyMDEyLTA4LTMxIDIxOjMyOjM2XSAgIGdmbjogMDAwMDRhY2YgIG1mbjogMDAwMDRhY2YN
Cg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MzZdICAgZ2ZuOiAwMDAwNGFkMCAgbWZuOiAw
MDAwNGFkMA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjozNl0gICBnZm46IDAwMDA0YWQx
ICBtZm46IDAwMDA0YWQxDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjM2XSAgIGdmbjog
MDAwMDRhZDIgIG1mbjogMDAwMDRhZDINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MzZd
ICAgZ2ZuOiAwMDAwNGFkMyAgbWZuOiAwMDAwNGFkMw0KDQooWEVOKSBbMjAxMi0wOC0zMSAy
MTozMjozNl0gICBnZm46IDAwMDA0YWQ0ICBtZm46IDAwMDA0YWQ0DQoNCihYRU4pIFsyMDEy
LTA4LTMxIDIxOjMyOjM2XSAgIGdmbjogMDAwMDRhZDUgIG1mbjogMDAwMDRhZDUNCg0KKFhF
TikgWzIwMTItMDgtMzEgMjE6MzI6MzZdICAgZ2ZuOiAwMDAwNGFkNiAgbWZuOiAwMDAwNGFk
Ng0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjozNl0gICBnZm46IDAwMDA0YWQ3ICBtZm46
IDAwMDA0YWQ3DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjM2XSAgIGdmbjogMDAwMDRh
ZDggIG1mbjogMDAwMDRhZDgNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MzZdICAgZ2Zu
OiAwMDAwNGFkOSAgbWZuOiAwMDAwNGFkOQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoz
Nl0gICBnZm46IDAwMDA0YWRhICBtZm46IDAwMDA0YWRhDQoNCihYRU4pIFsyMDEyLTA4LTMx
IDIxOjMyOjM2XSAgIGdmbjogMDAwMDRhZGIgIG1mbjogMDAwMDRhZGINCg0KKFhFTikgWzIw
MTItMDgtMzEgMjE6MzI6MzZdICAgZ2ZuOiAwMDAwNGFkYyAgbWZuOiAwMDAwNGFkYw0KDQoo
WEVOKSBbMjAxMi0wOC0zMSAyMTozMjozNl0gICBnZm46IDAwMDA0YWRkICBtZm46IDAwMDA0
YWRkDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjM2XSAgIGdmbjogMDAwMDRhZGUgIG1m
bjogMDAwMDRhZGUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MzZdICAgZ2ZuOiAwMDAw
NGFkZiAgbWZuOiAwMDAwNGFkZg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjozNl0gICBn
Zm46IDAwMDA0YWUwICBtZm46IDAwMDA0YWUwDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMy
OjM2XSAgIGdmbjogMDAwMDRhZTEgIG1mbjogMDAwMDRhZTENCg0KKFhFTikgWzIwMTItMDgt
MzEgMjE6MzI6MzZdICAgZ2ZuOiAwMDAwNGFlMiAgbWZuOiAwMDAwNGFlMg0KDQooWEVOKSBb
MjAxMi0wOC0zMSAyMTozMjozNl0gICBnZm46IDAwMDA0YWUzICBtZm46IDAwMDA0YWUzDQoN
CihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjM2XSAgIGdmbjogMDAwMDRhZTQgIG1mbjogMDAw
MDRhZTQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MzZdICAgZ2ZuOiAwMDAwNGFlNSAg
bWZuOiAwMDAwNGFlNQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjozNl0gICBnZm46IDAw
MDA0YWU2ICBtZm46IDAwMDA0YWU2DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjM2XSAg
IGdmbjogMDAwMDRhZTcgIG1mbjogMDAwMDRhZTcNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6
MzI6MzZdICAgZ2ZuOiAwMDAwNGFlOCAgbWZuOiAwMDAwNGFlOA0KDQooWEVOKSBbMjAxMi0w
OC0zMSAyMTozMjozNl0gICBnZm46IDAwMDA0YWU5ICBtZm46IDAwMDA0YWU5DQoNCihYRU4p
IFsyMDEyLTA4LTMxIDIxOjMyOjM2XSAgIGdmbjogMDAwMDRhZWEgIG1mbjogMDAwMDRhZWEN
Cg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MzZdICAgZ2ZuOiAwMDAwNGFlYiAgbWZuOiAw
MDAwNGFlYg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjozNl0gICBnZm46IDAwMDA0YWVj
ICBtZm46IDAwMDA0YWVjDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjM2XSAgIGdmbjog
MDAwMDRhZWQgIG1mbjogMDAwMDRhZWQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MzZd
ICAgZ2ZuOiAwMDAwNGFlZSAgbWZuOiAwMDAwNGFlZQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAy
MTozMjozNl0gICBnZm46IDAwMDA0YWVmICBtZm46IDAwMDA0YWVmDQoNCihYRU4pIFsyMDEy
LTA4LTMxIDIxOjMyOjM2XSAgIGdmbjogMDAwMDRhZjAgIG1mbjogMDAwMDRhZjANCg0KKFhF
TikgWzIwMTItMDgtMzEgMjE6MzI6MzddICAgZ2ZuOiAwMDAwNGFmMSAgbWZuOiAwMDAwNGFm
MQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjozN10gICBnZm46IDAwMDA0YWYyICBtZm46
IDAwMDA0YWYyDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjM3XSAgIGdmbjogMDAwMDRh
ZjMgIG1mbjogMDAwMDRhZjMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MzddICAgZ2Zu
OiAwMDAwNGFmNCAgbWZuOiAwMDAwNGFmNA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoz
N10gICBnZm46IDAwMDA0YWY1ICBtZm46IDAwMDA0YWY1DQoNCihYRU4pIFsyMDEyLTA4LTMx
IDIxOjMyOjM3XSAgIGdmbjogMDAwMDRhZjYgIG1mbjogMDAwMDRhZjYNCg0KKFhFTikgWzIw
MTItMDgtMzEgMjE6MzI6MzddICAgZ2ZuOiAwMDAwNGFmNyAgbWZuOiAwMDAwNGFmNw0KDQoo
WEVOKSBbMjAxMi0wOC0zMSAyMTozMjozN10gICBnZm46IDAwMDA0YWY4ICBtZm46IDAwMDA0
YWY4DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjM3XSAgIGdmbjogMDAwMDRhZjkgIG1m
bjogMDAwMDRhZjkNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MzddICAgZ2ZuOiAwMDAw
NGFmYSAgbWZuOiAwMDAwNGFmYQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjozN10gICBn
Zm46IDAwMDA0YWZiICBtZm46IDAwMDA0YWZiDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMy
OjM3XSAgIGdmbjogMDAwMDRhZmMgIG1mbjogMDAwMDRhZmMNCg0KKFhFTikgWzIwMTItMDgt
MzEgMjE6MzI6MzddICAgZ2ZuOiAwMDAwNGFmZCAgbWZuOiAwMDAwNGFmZA0KDQooWEVOKSBb
MjAxMi0wOC0zMSAyMTozMjozN10gICBnZm46IDAwMDA0YWZlICBtZm46IDAwMDA0YWZlDQoN
CihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjM3XSAgIGdmbjogMDAwMDRhZmYgIG1mbjogMDAw
MDRhZmYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MzddICAgZ2ZuOiAwMDAwNGIwMCAg
bWZuOiAwMDAwNGIwMA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjozN10gICBnZm46IDAw
MDA0YjAxICBtZm46IDAwMDA0YjAxDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjM3XSAg
IGdmbjogMDAwMDRiMDIgIG1mbjogMDAwMDRiMDINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6
MzI6MzddICAgZ2ZuOiAwMDAwNGIwMyAgbWZuOiAwMDAwNGIwMw0KDQooWEVOKSBbMjAxMi0w
OC0zMSAyMTozMjozN10gICBnZm46IDAwMDA0YjA0ICBtZm46IDAwMDA0YjA0DQoNCihYRU4p
IFsyMDEyLTA4LTMxIDIxOjMyOjM3XSAgIGdmbjogMDAwMDRiMDUgIG1mbjogMDAwMDRiMDUN
Cg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MzddICAgZ2ZuOiAwMDAwNGIwNiAgbWZuOiAw
MDAwNGIwNg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjozN10gICBnZm46IDAwMDA0YjA3
ICBtZm46IDAwMDA0YjA3DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjM3XSAgIGdmbjog
MDAwMDRiMDggIG1mbjogMDAwMDRiMDgNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6Mzdd
ICAgZ2ZuOiAwMDAwNGIwOSAgbWZuOiAwMDAwNGIwOQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAy
MTozMjozN10gICBnZm46IDAwMDA0YjBhICBtZm46IDAwMDA0YjBhDQoNCihYRU4pIFsyMDEy
LTA4LTMxIDIxOjMyOjM3XSAgIGdmbjogMDAwMDRiMGIgIG1mbjogMDAwMDRiMGINCg0KKFhF
TikgWzIwMTItMDgtMzEgMjE6MzI6MzddICAgZ2ZuOiAwMDAwNGIwYyAgbWZuOiAwMDAwNGIw
Yw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjozN10gICBnZm46IDAwMDA0YjBkICBtZm46
IDAwMDA0YjBkDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjM3XSAgIGdmbjogMDAwMDRi
MGUgIG1mbjogMDAwMDRiMGUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MzddICAgZ2Zu
OiAwMDAwNGIwZiAgbWZuOiAwMDAwNGIwZg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoz
N10gICBnZm46IDAwMDA0YjEwICBtZm46IDAwMDA0YjEwDQoNCihYRU4pIFsyMDEyLTA4LTMx
IDIxOjMyOjM3XSAgIGdmbjogMDAwMDRiMTEgIG1mbjogMDAwMDRiMTENCg0KKFhFTikgWzIw
MTItMDgtMzEgMjE6MzI6MzddICAgZ2ZuOiAwMDAwNGIxMiAgbWZuOiAwMDAwNGIxMg0KDQoo
WEVOKSBbMjAxMi0wOC0zMSAyMTozMjozN10gICBnZm46IDAwMDA0YjEzICBtZm46IDAwMDA0
YjEzDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjM3XSAgIGdmbjogMDAwMDRiMTQgIG1m
bjogMDAwMDRiMTQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MzddICAgZ2ZuOiAwMDAw
NGIxNSAgbWZuOiAwMDAwNGIxNQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjozN10gICBn
Zm46IDAwMDA0YjE2ICBtZm46IDAwMDA0YjE2DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMy
OjM3XSAgIGdmbjogMDAwMDRiMTcgIG1mbjogMDAwMDRiMTcNCg0KKFhFTikgWzIwMTItMDgt
MzEgMjE6MzI6MzddICAgZ2ZuOiAwMDAwNGIxOCAgbWZuOiAwMDAwNGIxOA0KDQooWEVOKSBb
MjAxMi0wOC0zMSAyMTozMjozN10gICBnZm46IDAwMDA0YjE5ICBtZm46IDAwMDA0YjE5DQoN
CihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjM3XSAgIGdmbjogMDAwMDRiMWEgIG1mbjogMDAw
MDRiMWENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MzddICAgZ2ZuOiAwMDAwNGIxYiAg
bWZuOiAwMDAwNGIxYg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjozN10gICBnZm46IDAw
MDA0YjFjICBtZm46IDAwMDA0YjFjDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjM3XSAg
IGdmbjogMDAwMDRiMWQgIG1mbjogMDAwMDRiMWQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6
MzI6MzddICAgZ2ZuOiAwMDAwNGIxZSAgbWZuOiAwMDAwNGIxZQ0KDQooWEVOKSBbMjAxMi0w
OC0zMSAyMTozMjozN10gICBnZm46IDAwMDA0YjFmICBtZm46IDAwMDA0YjFmDQoNCihYRU4p
IFsyMDEyLTA4LTMxIDIxOjMyOjM3XSAgIGdmbjogMDAwMDRiMjAgIG1mbjogMDAwMDRiMjAN
Cg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MzddICAgZ2ZuOiAwMDAwNGIyMSAgbWZuOiAw
MDAwNGIyMQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjozN10gICBnZm46IDAwMDA0YjIy
ICBtZm46IDAwMDA0YjIyDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjM3XSAgIGdmbjog
MDAwMDRiMjMgIG1mbjogMDAwMDRiMjMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6Mzdd
ICAgZ2ZuOiAwMDAwNGIyNCAgbWZuOiAwMDAwNGIyNA0KDQooWEVOKSBbMjAxMi0wOC0zMSAy
MTozMjozN10gICBnZm46IDAwMDA0YjI1ICBtZm46IDAwMDA0YjI1DQoNCihYRU4pIFsyMDEy
LTA4LTMxIDIxOjMyOjM3XSAgIGdmbjogMDAwMDRiMjYgIG1mbjogMDAwMDRiMjYNCg0KKFhF
TikgWzIwMTItMDgtMzEgMjE6MzI6MzddICAgZ2ZuOiAwMDAwNGIyNyAgbWZuOiAwMDAwNGIy
Nw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjozN10gICBnZm46IDAwMDA0YjI4ICBtZm46
IDAwMDA0YjI4DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjM3XSAgIGdmbjogMDAwMDRi
MjkgIG1mbjogMDAwMDRiMjkNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MzddICAgZ2Zu
OiAwMDAwNGIyYSAgbWZuOiAwMDAwNGIyYQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoz
N10gICBnZm46IDAwMDA0YjJiICBtZm46IDAwMDA0YjJiDQoNCihYRU4pIFsyMDEyLTA4LTMx
IDIxOjMyOjM3XSAgIGdmbjogMDAwMDRiMmMgIG1mbjogMDAwMDRiMmMNCg0KKFhFTikgWzIw
MTItMDgtMzEgMjE6MzI6MzddICAgZ2ZuOiAwMDAwNGIyZCAgbWZuOiAwMDAwNGIyZA0KDQoo
WEVOKSBbMjAxMi0wOC0zMSAyMTozMjozN10gICBnZm46IDAwMDA0YjJlICBtZm46IDAwMDA0
YjJlDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjM3XSAgIGdmbjogMDAwMDRiMmYgIG1m
bjogMDAwMDRiMmYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MzddICAgZ2ZuOiAwMDAw
NGIzMCAgbWZuOiAwMDAwNGIzMA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjozN10gICBn
Zm46IDAwMDA0YjMxICBtZm46IDAwMDA0YjMxDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMy
OjM4XSAgIGdmbjogMDAwMDRiMzIgIG1mbjogMDAwMDRiMzINCg0KKFhFTikgWzIwMTItMDgt
MzEgMjE6MzI6MzhdICAgZ2ZuOiAwMDAwNGIzMyAgbWZuOiAwMDAwNGIzMw0KDQooWEVOKSBb
MjAxMi0wOC0zMSAyMTozMjozOF0gICBnZm46IDAwMDA0YjM0ICBtZm46IDAwMDA0YjM0DQoN
CihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjM4XSAgIGdmbjogMDAwMDRiMzUgIG1mbjogMDAw
MDRiMzUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MzhdICAgZ2ZuOiAwMDAwNGIzNiAg
bWZuOiAwMDAwNGIzNg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjozOF0gICBnZm46IDAw
MDA0YjM3ICBtZm46IDAwMDA0YjM3DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjM4XSAg
IGdmbjogMDAwMDRiMzggIG1mbjogMDAwMDRiMzgNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6
MzI6MzhdICAgZ2ZuOiAwMDAwNGIzOSAgbWZuOiAwMDAwNGIzOQ0KDQooWEVOKSBbMjAxMi0w
OC0zMSAyMTozMjozOF0gICBnZm46IDAwMDA0YjNhICBtZm46IDAwMDA0YjNhDQoNCihYRU4p
IFsyMDEyLTA4LTMxIDIxOjMyOjM4XSAgIGdmbjogMDAwMDRiM2IgIG1mbjogMDAwMDRiM2IN
Cg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MzhdICAgZ2ZuOiAwMDAwNGIzYyAgbWZuOiAw
MDAwNGIzYw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjozOF0gICBnZm46IDAwMDA0YjNk
ICBtZm46IDAwMDA0YjNkDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjM4XSAgIGdmbjog
MDAwMDRiM2UgIG1mbjogMDAwMDRiM2UNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6Mzhd
ICAgZ2ZuOiAwMDAwNGIzZiAgbWZuOiAwMDAwNGIzZg0KDQooWEVOKSBbMjAxMi0wOC0zMSAy
MTozMjozOF0gICBnZm46IDAwMDA0YjQwICBtZm46IDAwMDA0YjQwDQoNCihYRU4pIFsyMDEy
LTA4LTMxIDIxOjMyOjM4XSAgIGdmbjogMDAwMDRiNDEgIG1mbjogMDAwMDRiNDENCg0KKFhF
TikgWzIwMTItMDgtMzEgMjE6MzI6MzhdICAgZ2ZuOiAwMDAwNGI0MiAgbWZuOiAwMDAwNGI0
Mg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjozOF0gICBnZm46IDAwMDA0YjQzICBtZm46
IDAwMDA0YjQzDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjM4XSAgIGdmbjogMDAwMDRi
NDQgIG1mbjogMDAwMDRiNDQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MzhdICAgZ2Zu
OiAwMDAwNGI0NSAgbWZuOiAwMDAwNGI0NQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoz
OF0gICBnZm46IDAwMDA0YjQ2ICBtZm46IDAwMDA0YjQ2DQoNCihYRU4pIFsyMDEyLTA4LTMx
IDIxOjMyOjM4XSAgIGdmbjogMDAwMDRiNDcgIG1mbjogMDAwMDRiNDcNCg0KKFhFTikgWzIw
MTItMDgtMzEgMjE6MzI6MzhdICAgZ2ZuOiAwMDAwNGI0OCAgbWZuOiAwMDAwNGI0OA0KDQoo
WEVOKSBbMjAxMi0wOC0zMSAyMTozMjozOF0gICBnZm46IDAwMDA0YjQ5ICBtZm46IDAwMDA0
YjQ5DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjM4XSAgIGdmbjogMDAwMDRiNGEgIG1m
bjogMDAwMDRiNGENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MzhdICAgZ2ZuOiAwMDAw
NGI0YiAgbWZuOiAwMDAwNGI0Yg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjozOF0gICBn
Zm46IDAwMDA0YjRjICBtZm46IDAwMDA0YjRjDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMy
OjM4XSAgIGdmbjogMDAwMDRiNGQgIG1mbjogMDAwMDRiNGQNCg0KKFhFTikgWzIwMTItMDgt
MzEgMjE6MzI6MzhdICAgZ2ZuOiAwMDAwNGI0ZSAgbWZuOiAwMDAwNGI0ZQ0KDQooWEVOKSBb
MjAxMi0wOC0zMSAyMTozMjozOF0gICBnZm46IDAwMDA0YjRmICBtZm46IDAwMDA0YjRmDQoN
CihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjM4XSAgIGdmbjogMDAwMDRiNTAgIG1mbjogMDAw
MDRiNTANCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MzhdICAgZ2ZuOiAwMDAwNGI1MSAg
bWZuOiAwMDAwNGI1MQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjozOF0gICBnZm46IDAw
MDA0YjUyICBtZm46IDAwMDA0YjUyDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjM4XSAg
IGdmbjogMDAwMDRiNTMgIG1mbjogMDAwMDRiNTMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6
MzI6MzhdICAgZ2ZuOiAwMDAwNGI1NCAgbWZuOiAwMDAwNGI1NA0KDQooWEVOKSBbMjAxMi0w
OC0zMSAyMTozMjozOF0gICBnZm46IDAwMDA0YjU1ICBtZm46IDAwMDA0YjU1DQoNCihYRU4p
IFsyMDEyLTA4LTMxIDIxOjMyOjM4XSAgIGdmbjogMDAwMDRiNTYgIG1mbjogMDAwMDRiNTYN
Cg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MzhdICAgZ2ZuOiAwMDAwNGI1NyAgbWZuOiAw
MDAwNGI1Nw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjozOF0gICBnZm46IDAwMDA0YjU4
ICBtZm46IDAwMDA0YjU4DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjM4XSAgIGdmbjog
MDAwMDRiNTkgIG1mbjogMDAwMDRiNTkNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6Mzhd
ICAgZ2ZuOiAwMDAwNGI1YSAgbWZuOiAwMDAwNGI1YQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAy
MTozMjozOF0gICBnZm46IDAwMDA0YjViICBtZm46IDAwMDA0YjViDQoNCihYRU4pIFsyMDEy
LTA4LTMxIDIxOjMyOjM4XSAgIGdmbjogMDAwMDRiNWMgIG1mbjogMDAwMDRiNWMNCg0KKFhF
TikgWzIwMTItMDgtMzEgMjE6MzI6MzhdICAgZ2ZuOiAwMDAwNGI1ZCAgbWZuOiAwMDAwNGI1
ZA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjozOF0gICBnZm46IDAwMDA0YjVlICBtZm46
IDAwMDA0YjVlDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjM4XSAgIGdmbjogMDAwMDRi
NWYgIG1mbjogMDAwMDRiNWYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MzhdICAgZ2Zu
OiAwMDAwNGI2MCAgbWZuOiAwMDAwNGI2MA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoz
OF0gICBnZm46IDAwMDA0YjYxICBtZm46IDAwMDA0YjYxDQoNCihYRU4pIFsyMDEyLTA4LTMx
IDIxOjMyOjM4XSAgIGdmbjogMDAwMDRiNjIgIG1mbjogMDAwMDRiNjINCg0KKFhFTikgWzIw
MTItMDgtMzEgMjE6MzI6MzhdICAgZ2ZuOiAwMDAwNGI2MyAgbWZuOiAwMDAwNGI2Mw0KDQoo
WEVOKSBbMjAxMi0wOC0zMSAyMTozMjozOF0gICBnZm46IDAwMDA0YjY0ICBtZm46IDAwMDA0
YjY0DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjM4XSAgIGdmbjogMDAwMDRiNjUgIG1m
bjogMDAwMDRiNjUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MzhdICAgZ2ZuOiAwMDAw
NGI2NiAgbWZuOiAwMDAwNGI2Ng0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjozOF0gICBn
Zm46IDAwMDA0YjY3ICBtZm46IDAwMDA0YjY3DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMy
OjM4XSAgIGdmbjogMDAwMDRiNjggIG1mbjogMDAwMDRiNjgNCg0KKFhFTikgWzIwMTItMDgt
MzEgMjE6MzI6MzhdICAgZ2ZuOiAwMDAwNGI2OSAgbWZuOiAwMDAwNGI2OQ0KDQooWEVOKSBb
MjAxMi0wOC0zMSAyMTozMjozOF0gICBnZm46IDAwMDA0YjZhICBtZm46IDAwMDA0YjZhDQoN
CihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjM4XSAgIGdmbjogMDAwMDRiNmIgIG1mbjogMDAw
MDRiNmINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MzhdICAgZ2ZuOiAwMDAwNGI2YyAg
bWZuOiAwMDAwNGI2Yw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjozOF0gICBnZm46IDAw
MDA0YjZkICBtZm46IDAwMDA0YjZkDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjM4XSAg
IGdmbjogMDAwMDRiNmUgIG1mbjogMDAwMDRiNmUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6
MzI6MzhdICAgZ2ZuOiAwMDAwNGI2ZiAgbWZuOiAwMDAwNGI2Zg0KDQooWEVOKSBbMjAxMi0w
OC0zMSAyMTozMjozOF0gICBnZm46IDAwMDA0YjcwICBtZm46IDAwMDA0YjcwDQoNCihYRU4p
IFsyMDEyLTA4LTMxIDIxOjMyOjM4XSAgIGdmbjogMDAwMDRiNzEgIG1mbjogMDAwMDRiNzEN
Cg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MzldICAgZ2ZuOiAwMDAwNGI3MiAgbWZuOiAw
MDAwNGI3Mg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjozOV0gICBnZm46IDAwMDA0Yjcz
ICBtZm46IDAwMDA0YjczDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjM5XSAgIGdmbjog
MDAwMDRiNzQgIG1mbjogMDAwMDRiNzQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6Mzld
ICAgZ2ZuOiAwMDAwNGI3NSAgbWZuOiAwMDAwNGI3NQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAy
MTozMjozOV0gICBnZm46IDAwMDA0Yjc2ICBtZm46IDAwMDA0Yjc2DQoNCihYRU4pIFsyMDEy
LTA4LTMxIDIxOjMyOjM5XSAgIGdmbjogMDAwMDRiNzcgIG1mbjogMDAwMDRiNzcNCg0KKFhF
TikgWzIwMTItMDgtMzEgMjE6MzI6MzldICAgZ2ZuOiAwMDAwNGI3OCAgbWZuOiAwMDAwNGI3
OA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjozOV0gICBnZm46IDAwMDA0Yjc5ICBtZm46
IDAwMDA0Yjc5DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjM5XSAgIGdmbjogMDAwMDRi
N2EgIG1mbjogMDAwMDRiN2ENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MzldICAgZ2Zu
OiAwMDAwNGI3YiAgbWZuOiAwMDAwNGI3Yg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoz
OV0gICBnZm46IDAwMDA0YjdjICBtZm46IDAwMDA0YjdjDQoNCihYRU4pIFsyMDEyLTA4LTMx
IDIxOjMyOjM5XSAgIGdmbjogMDAwMDRiN2QgIG1mbjogMDAwMDRiN2QNCg0KKFhFTikgWzIw
MTItMDgtMzEgMjE6MzI6MzldICAgZ2ZuOiAwMDAwNGI3ZSAgbWZuOiAwMDAwNGI3ZQ0KDQoo
WEVOKSBbMjAxMi0wOC0zMSAyMTozMjozOV0gICBnZm46IDAwMDA0YjdmICBtZm46IDAwMDA0
YjdmDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjM5XSAgIGdmbjogMDAwMDRiODAgIG1m
bjogMDAwMDRiODANCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MzldICAgZ2ZuOiAwMDAw
NGI4MSAgbWZuOiAwMDAwNGI4MQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjozOV0gICBn
Zm46IDAwMDA0YjgyICBtZm46IDAwMDA0YjgyDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMy
OjM5XSAgIGdmbjogMDAwMDRiODMgIG1mbjogMDAwMDRiODMNCg0KKFhFTikgWzIwMTItMDgt
MzEgMjE6MzI6MzldICAgZ2ZuOiAwMDAwNGI4NCAgbWZuOiAwMDAwNGI4NA0KDQooWEVOKSBb
MjAxMi0wOC0zMSAyMTozMjozOV0gICBnZm46IDAwMDA0Yjg1ICBtZm46IDAwMDA0Yjg1DQoN
CihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjM5XSAgIGdmbjogMDAwMDRiODYgIG1mbjogMDAw
MDRiODYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MzldICAgZ2ZuOiAwMDAwNGI4NyAg
bWZuOiAwMDAwNGI4Nw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjozOV0gICBnZm46IDAw
MDA0Yjg4ICBtZm46IDAwMDA0Yjg4DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjM5XSAg
IGdmbjogMDAwMDRiODkgIG1mbjogMDAwMDRiODkNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6
MzI6MzldICAgZ2ZuOiAwMDAwNGI4YSAgbWZuOiAwMDAwNGI4YQ0KDQooWEVOKSBbMjAxMi0w
OC0zMSAyMTozMjozOV0gICBnZm46IDAwMDA0YjhiICBtZm46IDAwMDA0YjhiDQoNCihYRU4p
IFsyMDEyLTA4LTMxIDIxOjMyOjM5XSAgIGdmbjogMDAwMDRiOGMgIG1mbjogMDAwMDRiOGMN
Cg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MzldICAgZ2ZuOiAwMDAwNGI4ZCAgbWZuOiAw
MDAwNGI4ZA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjozOV0gICBnZm46IDAwMDA0Yjhl
ICBtZm46IDAwMDA0YjhlDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjM5XSAgIGdmbjog
MDAwMDRiOGYgIG1mbjogMDAwMDRiOGYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6Mzld
ICAgZ2ZuOiAwMDAwNGI5MCAgbWZuOiAwMDAwNGI5MA0KDQooWEVOKSBbMjAxMi0wOC0zMSAy
MTozMjozOV0gICBnZm46IDAwMDA0YjkxICBtZm46IDAwMDA0YjkxDQoNCihYRU4pIFsyMDEy
LTA4LTMxIDIxOjMyOjM5XSAgIGdmbjogMDAwMDRiOTIgIG1mbjogMDAwMDRiOTINCg0KKFhF
TikgWzIwMTItMDgtMzEgMjE6MzI6MzldICAgZ2ZuOiAwMDAwNGI5MyAgbWZuOiAwMDAwNGI5
Mw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjozOV0gICBnZm46IDAwMDA0Yjk0ICBtZm46
IDAwMDA0Yjk0DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjM5XSAgIGdmbjogMDAwMDRi
OTUgIG1mbjogMDAwMDRiOTUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MzldICAgZ2Zu
OiAwMDAwNGI5NiAgbWZuOiAwMDAwNGI5Ng0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjoz
OV0gICBnZm46IDAwMDA0Yjk3ICBtZm46IDAwMDA0Yjk3DQoNCihYRU4pIFsyMDEyLTA4LTMx
IDIxOjMyOjM5XSAgIGdmbjogMDAwMDRiOTggIG1mbjogMDAwMDRiOTgNCg0KKFhFTikgWzIw
MTItMDgtMzEgMjE6MzI6MzldICAgZ2ZuOiAwMDAwNGI5OSAgbWZuOiAwMDAwNGI5OQ0KDQoo
WEVOKSBbMjAxMi0wOC0zMSAyMTozMjozOV0gICBnZm46IDAwMDA0YjlhICBtZm46IDAwMDA0
YjlhDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjM5XSAgIGdmbjogMDAwMDRiOWIgIG1m
bjogMDAwMDRiOWINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MzldICAgZ2ZuOiAwMDAw
NGI5YyAgbWZuOiAwMDAwNGI5Yw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjozOV0gICBn
Zm46IDAwMDA0YjlkICBtZm46IDAwMDA0YjlkDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMy
OjM5XSAgIGdmbjogMDAwMDRiOWUgIG1mbjogMDAwMDRiOWUNCg0KKFhFTikgWzIwMTItMDgt
MzEgMjE6MzI6MzldICAgZ2ZuOiAwMDAwNGI5ZiAgbWZuOiAwMDAwNGI5Zg0KDQooWEVOKSBb
MjAxMi0wOC0zMSAyMTozMjozOV0gICBnZm46IDAwMDA0YmEwICBtZm46IDAwMDA0YmEwDQoN
CihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjM5XSAgIGdmbjogMDAwMDRiYTEgIG1mbjogMDAw
MDRiYTENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MzldICAgZ2ZuOiAwMDAwNGJhMiAg
bWZuOiAwMDAwNGJhMg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjozOV0gICBnZm46IDAw
MDA0YmEzICBtZm46IDAwMDA0YmEzDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjM5XSAg
IGdmbjogMDAwMDRiYTQgIG1mbjogMDAwMDRiYTQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6
MzI6MzldICAgZ2ZuOiAwMDAwNGJhNSAgbWZuOiAwMDAwNGJhNQ0KDQooWEVOKSBbMjAxMi0w
OC0zMSAyMTozMjozOV0gICBnZm46IDAwMDA0YmE2ICBtZm46IDAwMDA0YmE2DQoNCihYRU4p
IFsyMDEyLTA4LTMxIDIxOjMyOjM5XSAgIGdmbjogMDAwMDRiYTcgIG1mbjogMDAwMDRiYTcN
Cg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MzldICAgZ2ZuOiAwMDAwNGJhOCAgbWZuOiAw
MDAwNGJhOA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjozOV0gICBnZm46IDAwMDA0YmE5
ICBtZm46IDAwMDA0YmE5DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjM5XSAgIGdmbjog
MDAwMDRiYWEgIG1mbjogMDAwMDRiYWENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6Mzld
ICAgZ2ZuOiAwMDAwNGJhYiAgbWZuOiAwMDAwNGJhYg0KDQooWEVOKSBbMjAxMi0wOC0zMSAy
MTozMjozOV0gICBnZm46IDAwMDA0YmFjICBtZm46IDAwMDA0YmFjDQoNCihYRU4pIFsyMDEy
LTA4LTMxIDIxOjMyOjM5XSAgIGdmbjogMDAwMDRiYWQgIG1mbjogMDAwMDRiYWQNCg0KKFhF
TikgWzIwMTItMDgtMzEgMjE6MzI6MzldICAgZ2ZuOiAwMDAwNGJhZSAgbWZuOiAwMDAwNGJh
ZQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjozOV0gICBnZm46IDAwMDA0YmFmICBtZm46
IDAwMDA0YmFmDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjM5XSAgIGdmbjogMDAwMDRi
YjAgIG1mbjogMDAwMDRiYjANCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6MzldICAgZ2Zu
OiAwMDAwNGJiMSAgbWZuOiAwMDAwNGJiMQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo0
MF0gICBnZm46IDAwMDA0YmIyICBtZm46IDAwMDA0YmIyDQoNCihYRU4pIFsyMDEyLTA4LTMx
IDIxOjMyOjQwXSAgIGdmbjogMDAwMDRiYjMgIG1mbjogMDAwMDRiYjMNCg0KKFhFTikgWzIw
MTItMDgtMzEgMjE6MzI6NDBdICAgZ2ZuOiAwMDAwNGJiNCAgbWZuOiAwMDAwNGJiNA0KDQoo
WEVOKSBbMjAxMi0wOC0zMSAyMTozMjo0MF0gICBnZm46IDAwMDA0YmI1ICBtZm46IDAwMDA0
YmI1DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjQwXSAgIGdmbjogMDAwMDRiYjYgIG1m
bjogMDAwMDRiYjYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NDBdICAgZ2ZuOiAwMDAw
NGJiNyAgbWZuOiAwMDAwNGJiNw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo0MF0gICBn
Zm46IDAwMDA0YmI4ICBtZm46IDAwMDA0YmI4DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMy
OjQwXSAgIGdmbjogMDAwMDRiYjkgIG1mbjogMDAwMDRiYjkNCg0KKFhFTikgWzIwMTItMDgt
MzEgMjE6MzI6NDBdICAgZ2ZuOiAwMDAwNGJiYSAgbWZuOiAwMDAwNGJiYQ0KDQooWEVOKSBb
MjAxMi0wOC0zMSAyMTozMjo0MF0gICBnZm46IDAwMDA0YmJiICBtZm46IDAwMDA0YmJiDQoN
CihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjQwXSAgIGdmbjogMDAwMDRiYmMgIG1mbjogMDAw
MDRiYmMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NDBdICAgZ2ZuOiAwMDAwNGJiZCAg
bWZuOiAwMDAwNGJiZA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo0MF0gICBnZm46IDAw
MDA0YmJlICBtZm46IDAwMDA0YmJlDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjQwXSAg
IGdmbjogMDAwMDRiYmYgIG1mbjogMDAwMDRiYmYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6
MzI6NDBdICAgZ2ZuOiAwMDAwNGJjMCAgbWZuOiAwMDAwNGJjMA0KDQooWEVOKSBbMjAxMi0w
OC0zMSAyMTozMjo0MF0gICBnZm46IDAwMDA0YmMxICBtZm46IDAwMDA0YmMxDQoNCihYRU4p
IFsyMDEyLTA4LTMxIDIxOjMyOjQwXSAgIGdmbjogMDAwMDRiYzIgIG1mbjogMDAwMDRiYzIN
Cg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NDBdICAgZ2ZuOiAwMDAwNGJjMyAgbWZuOiAw
MDAwNGJjMw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo0MF0gICBnZm46IDAwMDA0YmM0
ICBtZm46IDAwMDA0YmM0DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjQwXSAgIGdmbjog
MDAwMDRiYzUgIG1mbjogMDAwMDRiYzUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NDBd
ICAgZ2ZuOiAwMDAwNGJjNiAgbWZuOiAwMDAwNGJjNg0KDQooWEVOKSBbMjAxMi0wOC0zMSAy
MTozMjo0MF0gICBnZm46IDAwMDA0YmM3ICBtZm46IDAwMDA0YmM3DQoNCihYRU4pIFsyMDEy
LTA4LTMxIDIxOjMyOjQwXSAgIGdmbjogMDAwMDRiYzggIG1mbjogMDAwMDRiYzgNCg0KKFhF
TikgWzIwMTItMDgtMzEgMjE6MzI6NDBdICAgZ2ZuOiAwMDAwNGJjOSAgbWZuOiAwMDAwNGJj
OQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo0MF0gICBnZm46IDAwMDA0YmNhICBtZm46
IDAwMDA0YmNhDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjQwXSAgIGdmbjogMDAwMDRi
Y2IgIG1mbjogMDAwMDRiY2INCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NDBdICAgZ2Zu
OiAwMDAwNGJjYyAgbWZuOiAwMDAwNGJjYw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo0
MF0gICBnZm46IDAwMDA0YmNkICBtZm46IDAwMDA0YmNkDQoNCihYRU4pIFsyMDEyLTA4LTMx
IDIxOjMyOjQwXSAgIGdmbjogMDAwMDRiY2UgIG1mbjogMDAwMDRiY2UNCg0KKFhFTikgWzIw
MTItMDgtMzEgMjE6MzI6NDBdICAgZ2ZuOiAwMDAwNGJjZiAgbWZuOiAwMDAwNGJjZg0KDQoo
WEVOKSBbMjAxMi0wOC0zMSAyMTozMjo0MF0gICBnZm46IDAwMDA0YmQwICBtZm46IDAwMDA0
YmQwDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjQwXSAgIGdmbjogMDAwMDRiZDEgIG1m
bjogMDAwMDRiZDENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NDBdICAgZ2ZuOiAwMDAw
NGJkMiAgbWZuOiAwMDAwNGJkMg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo0MF0gICBn
Zm46IDAwMDA0YmQzICBtZm46IDAwMDA0YmQzDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMy
OjQwXSAgIGdmbjogMDAwMDRiZDQgIG1mbjogMDAwMDRiZDQNCg0KKFhFTikgWzIwMTItMDgt
MzEgMjE6MzI6NDBdICAgZ2ZuOiAwMDAwNGJkNSAgbWZuOiAwMDAwNGJkNQ0KDQooWEVOKSBb
MjAxMi0wOC0zMSAyMTozMjo0MF0gICBnZm46IDAwMDA0YmQ2ICBtZm46IDAwMDA0YmQ2DQoN
CihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjQwXSAgIGdmbjogMDAwMDRiZDcgIG1mbjogMDAw
MDRiZDcNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NDBdICAgZ2ZuOiAwMDAwNGJkOCAg
bWZuOiAwMDAwNGJkOA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo0MF0gICBnZm46IDAw
MDA0YmQ5ICBtZm46IDAwMDA0YmQ5DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjQwXSAg
IGdmbjogMDAwMDRiZGEgIG1mbjogMDAwMDRiZGENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6
MzI6NDBdICAgZ2ZuOiAwMDAwNGJkYiAgbWZuOiAwMDAwNGJkYg0KDQooWEVOKSBbMjAxMi0w
OC0zMSAyMTozMjo0MF0gICBnZm46IDAwMDA0YmRjICBtZm46IDAwMDA0YmRjDQoNCihYRU4p
IFsyMDEyLTA4LTMxIDIxOjMyOjQwXSAgIGdmbjogMDAwMDRiZGQgIG1mbjogMDAwMDRiZGQN
Cg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NDBdICAgZ2ZuOiAwMDAwNGJkZSAgbWZuOiAw
MDAwNGJkZQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo0MF0gICBnZm46IDAwMDA0YmRm
ICBtZm46IDAwMDA0YmRmDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjQwXSAgIGdmbjog
MDAwMDRiZTAgIG1mbjogMDAwMDRiZTANCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NDBd
ICAgZ2ZuOiAwMDAwNGJlMSAgbWZuOiAwMDAwNGJlMQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAy
MTozMjo0MF0gICBnZm46IDAwMDA0YmUyICBtZm46IDAwMDA0YmUyDQoNCihYRU4pIFsyMDEy
LTA4LTMxIDIxOjMyOjQwXSAgIGdmbjogMDAwMDRiZTMgIG1mbjogMDAwMDRiZTMNCg0KKFhF
TikgWzIwMTItMDgtMzEgMjE6MzI6NDBdICAgZ2ZuOiAwMDAwNGJlNCAgbWZuOiAwMDAwNGJl
NA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo0MF0gICBnZm46IDAwMDA0YmU1ICBtZm46
IDAwMDA0YmU1DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjQwXSAgIGdmbjogMDAwMDRi
ZTYgIG1mbjogMDAwMDRiZTYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NDBdICAgZ2Zu
OiAwMDAwNGJlNyAgbWZuOiAwMDAwNGJlNw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo0
MF0gICBnZm46IDAwMDA0YmU4ICBtZm46IDAwMDA0YmU4DQoNCihYRU4pIFsyMDEyLTA4LTMx
IDIxOjMyOjQwXSAgIGdmbjogMDAwMDRiZTkgIG1mbjogMDAwMDRiZTkNCg0KKFhFTikgWzIw
MTItMDgtMzEgMjE6MzI6NDBdICAgZ2ZuOiAwMDAwNGJlYSAgbWZuOiAwMDAwNGJlYQ0KDQoo
WEVOKSBbMjAxMi0wOC0zMSAyMTozMjo0MF0gICBnZm46IDAwMDA0YmViICBtZm46IDAwMDA0
YmViDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjQwXSAgIGdmbjogMDAwMDRiZWMgIG1m
bjogMDAwMDRiZWMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NDBdICAgZ2ZuOiAwMDAw
NGJlZCAgbWZuOiAwMDAwNGJlZA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo0MF0gICBn
Zm46IDAwMDA0YmVlICBtZm46IDAwMDA0YmVlDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMy
OjQwXSAgIGdmbjogMDAwMDRiZWYgIG1mbjogMDAwMDRiZWYNCg0KKFhFTikgWzIwMTItMDgt
MzEgMjE6MzI6NDBdICAgZ2ZuOiAwMDAwNGJmMCAgbWZuOiAwMDAwNGJmMA0KDQooWEVOKSBb
MjAxMi0wOC0zMSAyMTozMjo0MF0gICBnZm46IDAwMDA0YmYxICBtZm46IDAwMDA0YmYxDQoN
CihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjQxXSAgIGdmbjogMDAwMDRiZjIgIG1mbjogMDAw
MDRiZjINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NDFdICAgZ2ZuOiAwMDAwNGJmMyAg
bWZuOiAwMDAwNGJmMw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo0MV0gICBnZm46IDAw
MDA0YmY0ICBtZm46IDAwMDA0YmY0DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjQxXSAg
IGdmbjogMDAwMDRiZjUgIG1mbjogMDAwMDRiZjUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6
MzI6NDFdICAgZ2ZuOiAwMDAwNGJmNiAgbWZuOiAwMDAwNGJmNg0KDQooWEVOKSBbMjAxMi0w
OC0zMSAyMTozMjo0MV0gICBnZm46IDAwMDA0YmY3ICBtZm46IDAwMDA0YmY3DQoNCihYRU4p
IFsyMDEyLTA4LTMxIDIxOjMyOjQxXSAgIGdmbjogMDAwMDRiZjggIG1mbjogMDAwMDRiZjgN
Cg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NDFdICAgZ2ZuOiAwMDAwNGJmOSAgbWZuOiAw
MDAwNGJmOQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo0MV0gICBnZm46IDAwMDA0YmZh
ICBtZm46IDAwMDA0YmZhDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjQxXSAgIGdmbjog
MDAwMDRiZmIgIG1mbjogMDAwMDRiZmINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NDFd
ICAgZ2ZuOiAwMDAwNGJmYyAgbWZuOiAwMDAwNGJmYw0KDQooWEVOKSBbMjAxMi0wOC0zMSAy
MTozMjo0MV0gICBnZm46IDAwMDA0YmZkICBtZm46IDAwMDA0YmZkDQoNCihYRU4pIFsyMDEy
LTA4LTMxIDIxOjMyOjQxXSAgIGdmbjogMDAwMDRiZmUgIG1mbjogMDAwMDRiZmUNCg0KKFhF
TikgWzIwMTItMDgtMzEgMjE6MzI6NDFdICAgZ2ZuOiAwMDAwNGJmZiAgbWZuOiAwMDAwNGJm
Zg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo0MV0gICBnZm46IDAwMDA0YzAwICBtZm46
IDAwMDA0YzAwDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjQxXSAgIGdmbjogMDAwMDRj
MDEgIG1mbjogMDAwMDRjMDENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NDFdICAgZ2Zu
OiAwMDAwNGMwMiAgbWZuOiAwMDAwNGMwMg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo0
MV0gICBnZm46IDAwMDA0YzAzICBtZm46IDAwMDA0YzAzDQoNCihYRU4pIFsyMDEyLTA4LTMx
IDIxOjMyOjQxXSAgIGdmbjogMDAwMDRjMDQgIG1mbjogMDAwMDRjMDQNCg0KKFhFTikgWzIw
MTItMDgtMzEgMjE6MzI6NDFdICAgZ2ZuOiAwMDAwNGMwNSAgbWZuOiAwMDAwNGMwNQ0KDQoo
WEVOKSBbMjAxMi0wOC0zMSAyMTozMjo0MV0gICBnZm46IDAwMDA0YzA2ICBtZm46IDAwMDA0
YzA2DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjQxXSAgIGdmbjogMDAwMDRjMDcgIG1m
bjogMDAwMDRjMDcNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NDFdICAgZ2ZuOiAwMDAw
NGMwOCAgbWZuOiAwMDAwNGMwOA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo0MV0gICBn
Zm46IDAwMDA0YzA5ICBtZm46IDAwMDA0YzA5DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMy
OjQxXSAgIGdmbjogMDAwMDRjMGEgIG1mbjogMDAwMDRjMGENCg0KKFhFTikgWzIwMTItMDgt
MzEgMjE6MzI6NDFdICAgZ2ZuOiAwMDAwNGMwYiAgbWZuOiAwMDAwNGMwYg0KDQooWEVOKSBb
MjAxMi0wOC0zMSAyMTozMjo0MV0gICBnZm46IDAwMDA0YzBjICBtZm46IDAwMDA0YzBjDQoN
CihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjQxXSAgIGdmbjogMDAwMDRjMGQgIG1mbjogMDAw
MDRjMGQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NDFdICAgZ2ZuOiAwMDAwNGMwZSAg
bWZuOiAwMDAwNGMwZQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo0MV0gICBnZm46IDAw
MDA0YzBmICBtZm46IDAwMDA0YzBmDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjQxXSAg
IGdmbjogMDAwMDRjMTAgIG1mbjogMDAwMDRjMTANCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6
MzI6NDFdICAgZ2ZuOiAwMDAwNGMxMSAgbWZuOiAwMDAwNGMxMQ0KDQooWEVOKSBbMjAxMi0w
OC0zMSAyMTozMjo0MV0gICBnZm46IDAwMDA0YzEyICBtZm46IDAwMDA0YzEyDQoNCihYRU4p
IFsyMDEyLTA4LTMxIDIxOjMyOjQxXSAgIGdmbjogMDAwMDRjMTMgIG1mbjogMDAwMDRjMTMN
Cg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NDFdICAgZ2ZuOiAwMDAwNGMxNCAgbWZuOiAw
MDAwNGMxNA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo0MV0gICBnZm46IDAwMDA0YzE1
ICBtZm46IDAwMDA0YzE1DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjQxXSAgIGdmbjog
MDAwMDRjMTYgIG1mbjogMDAwMDRjMTYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NDFd
ICAgZ2ZuOiAwMDAwNGMxNyAgbWZuOiAwMDAwNGMxNw0KDQooWEVOKSBbMjAxMi0wOC0zMSAy
MTozMjo0MV0gICBnZm46IDAwMDA0YzE4ICBtZm46IDAwMDA0YzE4DQoNCihYRU4pIFsyMDEy
LTA4LTMxIDIxOjMyOjQxXSAgIGdmbjogMDAwMDRjMTkgIG1mbjogMDAwMDRjMTkNCg0KKFhF
TikgWzIwMTItMDgtMzEgMjE6MzI6NDFdICAgZ2ZuOiAwMDAwNGMxYSAgbWZuOiAwMDAwNGMx
YQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo0MV0gICBnZm46IDAwMDA0YzFiICBtZm46
IDAwMDA0YzFiDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjQxXSAgIGdmbjogMDAwMDRj
MWMgIG1mbjogMDAwMDRjMWMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NDFdICAgZ2Zu
OiAwMDAwNGMxZCAgbWZuOiAwMDAwNGMxZA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo0
MV0gICBnZm46IDAwMDA0YzFlICBtZm46IDAwMDA0YzFlDQoNCihYRU4pIFsyMDEyLTA4LTMx
IDIxOjMyOjQxXSAgIGdmbjogMDAwMDRjMWYgIG1mbjogMDAwMDRjMWYNCg0KKFhFTikgWzIw
MTItMDgtMzEgMjE6MzI6NDFdICAgZ2ZuOiAwMDAwNGMyMCAgbWZuOiAwMDAwNGMyMA0KDQoo
WEVOKSBbMjAxMi0wOC0zMSAyMTozMjo0MV0gICBnZm46IDAwMDA0YzIxICBtZm46IDAwMDA0
YzIxDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjQxXSAgIGdmbjogMDAwMDRjMjIgIG1m
bjogMDAwMDRjMjINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NDFdICAgZ2ZuOiAwMDAw
NGMyMyAgbWZuOiAwMDAwNGMyMw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo0MV0gICBn
Zm46IDAwMDA0YzI0ICBtZm46IDAwMDA0YzI0DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMy
OjQxXSAgIGdmbjogMDAwMDRjMjUgIG1mbjogMDAwMDRjMjUNCg0KKFhFTikgWzIwMTItMDgt
MzEgMjE6MzI6NDFdICAgZ2ZuOiAwMDAwNGMyNiAgbWZuOiAwMDAwNGMyNg0KDQooWEVOKSBb
MjAxMi0wOC0zMSAyMTozMjo0MV0gICBnZm46IDAwMDA0YzI3ICBtZm46IDAwMDA0YzI3DQoN
CihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjQxXSAgIGdmbjogMDAwMDRjMjggIG1mbjogMDAw
MDRjMjgNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NDFdICAgZ2ZuOiAwMDAwNGMyOSAg
bWZuOiAwMDAwNGMyOQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo0MV0gICBnZm46IDAw
MDA0YzJhICBtZm46IDAwMDA0YzJhDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjQxXSAg
IGdmbjogMDAwMDRjMmIgIG1mbjogMDAwMDRjMmINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6
MzI6NDFdICAgZ2ZuOiAwMDAwNGMyYyAgbWZuOiAwMDAwNGMyYw0KDQooWEVOKSBbMjAxMi0w
OC0zMSAyMTozMjo0MV0gICBnZm46IDAwMDA0YzJkICBtZm46IDAwMDA0YzJkDQoNCihYRU4p
IFsyMDEyLTA4LTMxIDIxOjMyOjQxXSAgIGdmbjogMDAwMDRjMmUgIG1mbjogMDAwMDRjMmUN
Cg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NDFdICAgZ2ZuOiAwMDAwNGMyZiAgbWZuOiAw
MDAwNGMyZg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo0MV0gICBnZm46IDAwMDA0YzMw
ICBtZm46IDAwMDA0YzMwDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjQxXSAgIGdmbjog
MDAwMDRjMzEgIG1mbjogMDAwMDRjMzENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NDJd
ICAgZ2ZuOiAwMDAwNGMzMiAgbWZuOiAwMDAwNGMzMg0KDQooWEVOKSBbMjAxMi0wOC0zMSAy
MTozMjo0Ml0gICBnZm46IDAwMDA0YzMzICBtZm46IDAwMDA0YzMzDQoNCihYRU4pIFsyMDEy
LTA4LTMxIDIxOjMyOjQyXSAgIGdmbjogMDAwMDRjMzQgIG1mbjogMDAwMDRjMzQNCg0KKFhF
TikgWzIwMTItMDgtMzEgMjE6MzI6NDJdICAgZ2ZuOiAwMDAwNGMzNSAgbWZuOiAwMDAwNGMz
NQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo0Ml0gICBnZm46IDAwMDA0YzM2ICBtZm46
IDAwMDA0YzM2DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjQyXSAgIGdmbjogMDAwMDRj
MzcgIG1mbjogMDAwMDRjMzcNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NDJdICAgZ2Zu
OiAwMDAwNGMzOCAgbWZuOiAwMDAwNGMzOA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo0
Ml0gICBnZm46IDAwMDA0YzM5ICBtZm46IDAwMDA0YzM5DQoNCihYRU4pIFsyMDEyLTA4LTMx
IDIxOjMyOjQyXSAgIGdmbjogMDAwMDRjM2EgIG1mbjogMDAwMDRjM2ENCg0KKFhFTikgWzIw
MTItMDgtMzEgMjE6MzI6NDJdICAgZ2ZuOiAwMDAwNGMzYiAgbWZuOiAwMDAwNGMzYg0KDQoo
WEVOKSBbMjAxMi0wOC0zMSAyMTozMjo0Ml0gICBnZm46IDAwMDA0YzNjICBtZm46IDAwMDA0
YzNjDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjQyXSAgIGdmbjogMDAwMDRjM2QgIG1m
bjogMDAwMDRjM2QNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NDJdICAgZ2ZuOiAwMDAw
NGMzZSAgbWZuOiAwMDAwNGMzZQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo0Ml0gICBn
Zm46IDAwMDA0YzNmICBtZm46IDAwMDA0YzNmDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMy
OjQyXSAgIGdmbjogMDAwMDRjNDAgIG1mbjogMDAwMDRjNDANCg0KKFhFTikgWzIwMTItMDgt
MzEgMjE6MzI6NDJdICAgZ2ZuOiAwMDAwNGM0MSAgbWZuOiAwMDAwNGM0MQ0KDQooWEVOKSBb
MjAxMi0wOC0zMSAyMTozMjo0Ml0gICBnZm46IDAwMDA0YzQyICBtZm46IDAwMDA0YzQyDQoN
CihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjQyXSAgIGdmbjogMDAwMDRjNDMgIG1mbjogMDAw
MDRjNDMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NDJdICAgZ2ZuOiAwMDAwNGM0NCAg
bWZuOiAwMDAwNGM0NA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo0Ml0gICBnZm46IDAw
MDA0YzQ1ICBtZm46IDAwMDA0YzQ1DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjQyXSAg
IGdmbjogMDAwMDRjNDYgIG1mbjogMDAwMDRjNDYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6
MzI6NDJdICAgZ2ZuOiAwMDAwNGM0NyAgbWZuOiAwMDAwNGM0Nw0KDQooWEVOKSBbMjAxMi0w
OC0zMSAyMTozMjo0Ml0gICBnZm46IDAwMDA0YzQ4ICBtZm46IDAwMDA0YzQ4DQoNCihYRU4p
IFsyMDEyLTA4LTMxIDIxOjMyOjQyXSAgIGdmbjogMDAwMDRjNDkgIG1mbjogMDAwMDRjNDkN
Cg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NDJdICAgZ2ZuOiAwMDAwNGM0YSAgbWZuOiAw
MDAwNGM0YQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo0Ml0gICBnZm46IDAwMDA0YzRi
ICBtZm46IDAwMDA0YzRiDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjQyXSAgIGdmbjog
MDAwMDRjNGMgIG1mbjogMDAwMDRjNGMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NDJd
ICAgZ2ZuOiAwMDAwNGM0ZCAgbWZuOiAwMDAwNGM0ZA0KDQooWEVOKSBbMjAxMi0wOC0zMSAy
MTozMjo0Ml0gICBnZm46IDAwMDA0YzRlICBtZm46IDAwMDA0YzRlDQoNCihYRU4pIFsyMDEy
LTA4LTMxIDIxOjMyOjQyXSAgIGdmbjogMDAwMDRjNGYgIG1mbjogMDAwMDRjNGYNCg0KKFhF
TikgWzIwMTItMDgtMzEgMjE6MzI6NDJdICAgZ2ZuOiAwMDAwNGM1MCAgbWZuOiAwMDAwNGM1
MA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo0Ml0gICBnZm46IDAwMDA0YzUxICBtZm46
IDAwMDA0YzUxDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjQyXSAgIGdmbjogMDAwMDRj
NTIgIG1mbjogMDAwMDRjNTINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NDJdICAgZ2Zu
OiAwMDAwNGM1MyAgbWZuOiAwMDAwNGM1Mw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo0
Ml0gICBnZm46IDAwMDA0YzU0ICBtZm46IDAwMDA0YzU0DQoNCihYRU4pIFsyMDEyLTA4LTMx
IDIxOjMyOjQyXSAgIGdmbjogMDAwMDRjNTUgIG1mbjogMDAwMDRjNTUNCg0KKFhFTikgWzIw
MTItMDgtMzEgMjE6MzI6NDJdICAgZ2ZuOiAwMDAwNGM1NiAgbWZuOiAwMDAwNGM1Ng0KDQoo
WEVOKSBbMjAxMi0wOC0zMSAyMTozMjo0Ml0gICBnZm46IDAwMDA0YzU3ICBtZm46IDAwMDA0
YzU3DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjQyXSAgIGdmbjogMDAwMDRjNTggIG1m
bjogMDAwMDRjNTgNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NDJdICAgZ2ZuOiAwMDAw
NGM1OSAgbWZuOiAwMDAwNGM1OQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo0Ml0gICBn
Zm46IDAwMDA0YzVhICBtZm46IDAwMDA0YzVhDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMy
OjQyXSAgIGdmbjogMDAwMDRjNWIgIG1mbjogMDAwMDRjNWINCg0KKFhFTikgWzIwMTItMDgt
MzEgMjE6MzI6NDJdICAgZ2ZuOiAwMDAwNGM1YyAgbWZuOiAwMDAwNGM1Yw0KDQooWEVOKSBb
MjAxMi0wOC0zMSAyMTozMjo0Ml0gICBnZm46IDAwMDA0YzVkICBtZm46IDAwMDA0YzVkDQoN
CihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjQyXSAgIGdmbjogMDAwMDRjNWUgIG1mbjogMDAw
MDRjNWUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NDJdICAgZ2ZuOiAwMDAwNGM1ZiAg
bWZuOiAwMDAwNGM1Zg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo0Ml0gICBnZm46IDAw
MDA0YzYwICBtZm46IDAwMDA0YzYwDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjQyXSAg
IGdmbjogMDAwMDRjNjEgIG1mbjogMDAwMDRjNjENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6
MzI6NDJdICAgZ2ZuOiAwMDAwNGM2MiAgbWZuOiAwMDAwNGM2Mg0KDQooWEVOKSBbMjAxMi0w
OC0zMSAyMTozMjo0Ml0gICBnZm46IDAwMDA0YzYzICBtZm46IDAwMDA0YzYzDQoNCihYRU4p
IFsyMDEyLTA4LTMxIDIxOjMyOjQyXSAgIGdmbjogMDAwMDRjNjQgIG1mbjogMDAwMDRjNjQN
Cg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NDJdICAgZ2ZuOiAwMDAwNGM2NSAgbWZuOiAw
MDAwNGM2NQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo0Ml0gICBnZm46IDAwMDA0YzY2
ICBtZm46IDAwMDA0YzY2DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjQyXSAgIGdmbjog
MDAwMDRjNjcgIG1mbjogMDAwMDRjNjcNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NDJd
ICAgZ2ZuOiAwMDAwNGM2OCAgbWZuOiAwMDAwNGM2OA0KDQooWEVOKSBbMjAxMi0wOC0zMSAy
MTozMjo0Ml0gICBnZm46IDAwMDA0YzY5ICBtZm46IDAwMDA0YzY5DQoNCihYRU4pIFsyMDEy
LTA4LTMxIDIxOjMyOjQyXSAgIGdmbjogMDAwMDRjNmEgIG1mbjogMDAwMDRjNmENCg0KKFhF
TikgWzIwMTItMDgtMzEgMjE6MzI6NDJdICAgZ2ZuOiAwMDAwNGM2YiAgbWZuOiAwMDAwNGM2
Yg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo0Ml0gICBnZm46IDAwMDA0YzZjICBtZm46
IDAwMDA0YzZjDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjQyXSAgIGdmbjogMDAwMDRj
NmQgIG1mbjogMDAwMDRjNmQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NDJdICAgZ2Zu
OiAwMDAwNGM2ZSAgbWZuOiAwMDAwNGM2ZQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo0
Ml0gICBnZm46IDAwMDA0YzZmICBtZm46IDAwMDA0YzZmDQoNCihYRU4pIFsyMDEyLTA4LTMx
IDIxOjMyOjQyXSAgIGdmbjogMDAwMDRjNzAgIG1mbjogMDAwMDRjNzANCg0KKFhFTikgWzIw
MTItMDgtMzEgMjE6MzI6NDJdICAgZ2ZuOiAwMDAwNGM3MSAgbWZuOiAwMDAwNGM3MQ0KDQoo
WEVOKSBbMjAxMi0wOC0zMSAyMTozMjo0M10gICBnZm46IDAwMDA0YzcyICBtZm46IDAwMDA0
YzcyDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjQzXSAgIGdmbjogMDAwMDRjNzMgIG1m
bjogMDAwMDRjNzMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NDNdICAgZ2ZuOiAwMDAw
NGM3NCAgbWZuOiAwMDAwNGM3NA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo0M10gICBn
Zm46IDAwMDA0Yzc1ICBtZm46IDAwMDA0Yzc1DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMy
OjQzXSAgIGdmbjogMDAwMDRjNzYgIG1mbjogMDAwMDRjNzYNCg0KKFhFTikgWzIwMTItMDgt
MzEgMjE6MzI6NDNdICAgZ2ZuOiAwMDAwNGM3NyAgbWZuOiAwMDAwNGM3Nw0KDQooWEVOKSBb
MjAxMi0wOC0zMSAyMTozMjo0M10gICBnZm46IDAwMDA0Yzc4ICBtZm46IDAwMDA0Yzc4DQoN
CihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjQzXSAgIGdmbjogMDAwMDRjNzkgIG1mbjogMDAw
MDRjNzkNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NDNdICAgZ2ZuOiAwMDAwNGM3YSAg
bWZuOiAwMDAwNGM3YQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo0M10gICBnZm46IDAw
MDA0YzdiICBtZm46IDAwMDA0YzdiDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjQzXSAg
IGdmbjogMDAwMDRjN2MgIG1mbjogMDAwMDRjN2MNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6
MzI6NDNdICAgZ2ZuOiAwMDAwNGM3ZCAgbWZuOiAwMDAwNGM3ZA0KDQooWEVOKSBbMjAxMi0w
OC0zMSAyMTozMjo0M10gICBnZm46IDAwMDA0YzdlICBtZm46IDAwMDA0YzdlDQoNCihYRU4p
IFsyMDEyLTA4LTMxIDIxOjMyOjQzXSAgIGdmbjogMDAwMDRjN2YgIG1mbjogMDAwMDRjN2YN
Cg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NDNdICAgZ2ZuOiAwMDAwNGM4MCAgbWZuOiAw
MDAwNGM4MA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo0M10gICBnZm46IDAwMDA0Yzgx
ICBtZm46IDAwMDA0YzgxDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjQzXSAgIGdmbjog
MDAwMDRjODIgIG1mbjogMDAwMDRjODINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NDNd
ICAgZ2ZuOiAwMDAwNGM4MyAgbWZuOiAwMDAwNGM4Mw0KDQooWEVOKSBbMjAxMi0wOC0zMSAy
MTozMjo0M10gICBnZm46IDAwMDA0Yzg0ICBtZm46IDAwMDA0Yzg0DQoNCihYRU4pIFsyMDEy
LTA4LTMxIDIxOjMyOjQzXSAgIGdmbjogMDAwMDRjODUgIG1mbjogMDAwMDRjODUNCg0KKFhF
TikgWzIwMTItMDgtMzEgMjE6MzI6NDNdICAgZ2ZuOiAwMDAwNGM4NiAgbWZuOiAwMDAwNGM4
Ng0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo0M10gICBnZm46IDAwMDA0Yzg3ICBtZm46
IDAwMDA0Yzg3DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjQzXSAgIGdmbjogMDAwMDRj
ODggIG1mbjogMDAwMDRjODgNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NDNdICAgZ2Zu
OiAwMDAwNGM4OSAgbWZuOiAwMDAwNGM4OQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo0
M10gICBnZm46IDAwMDA0YzhhICBtZm46IDAwMDA0YzhhDQoNCihYRU4pIFsyMDEyLTA4LTMx
IDIxOjMyOjQzXSAgIGdmbjogMDAwMDRjOGIgIG1mbjogMDAwMDRjOGINCg0KKFhFTikgWzIw
MTItMDgtMzEgMjE6MzI6NDNdICAgZ2ZuOiAwMDAwNGM4YyAgbWZuOiAwMDAwNGM4Yw0KDQoo
WEVOKSBbMjAxMi0wOC0zMSAyMTozMjo0M10gICBnZm46IDAwMDA0YzhkICBtZm46IDAwMDA0
YzhkDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjQzXSAgIGdmbjogMDAwMDRjOGUgIG1m
bjogMDAwMDRjOGUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NDNdICAgZ2ZuOiAwMDAw
NGM4ZiAgbWZuOiAwMDAwNGM4Zg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo0M10gICBn
Zm46IDAwMDA0YzkwICBtZm46IDAwMDA0YzkwDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMy
OjQzXSAgIGdmbjogMDAwMDRjOTEgIG1mbjogMDAwMDRjOTENCg0KKFhFTikgWzIwMTItMDgt
MzEgMjE6MzI6NDNdICAgZ2ZuOiAwMDAwNGM5MiAgbWZuOiAwMDAwNGM5Mg0KDQooWEVOKSBb
MjAxMi0wOC0zMSAyMTozMjo0M10gICBnZm46IDAwMDA0YzkzICBtZm46IDAwMDA0YzkzDQoN
CihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjQzXSAgIGdmbjogMDAwMDRjOTQgIG1mbjogMDAw
MDRjOTQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NDNdICAgZ2ZuOiAwMDAwNGM5NSAg
bWZuOiAwMDAwNGM5NQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo0M10gICBnZm46IDAw
MDA0Yzk2ICBtZm46IDAwMDA0Yzk2DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjQzXSAg
IGdmbjogMDAwMDRjOTcgIG1mbjogMDAwMDRjOTcNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6
MzI6NDNdICAgZ2ZuOiAwMDAwNGM5OCAgbWZuOiAwMDAwNGM5OA0KDQooWEVOKSBbMjAxMi0w
OC0zMSAyMTozMjo0M10gICBnZm46IDAwMDA0Yzk5ICBtZm46IDAwMDA0Yzk5DQoNCihYRU4p
IFsyMDEyLTA4LTMxIDIxOjMyOjQzXSAgIGdmbjogMDAwMDRjOWEgIG1mbjogMDAwMDRjOWEN
Cg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NDNdICAgZ2ZuOiAwMDAwNGM5YiAgbWZuOiAw
MDAwNGM5Yg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo0M10gICBnZm46IDAwMDA0Yzlj
ICBtZm46IDAwMDA0YzljDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjQzXSAgIGdmbjog
MDAwMDRjOWQgIG1mbjogMDAwMDRjOWQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NDNd
ICAgZ2ZuOiAwMDAwNGM5ZSAgbWZuOiAwMDAwNGM5ZQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAy
MTozMjo0M10gICBnZm46IDAwMDA0YzlmICBtZm46IDAwMDA0YzlmDQoNCihYRU4pIFsyMDEy
LTA4LTMxIDIxOjMyOjQzXSAgIGdmbjogMDAwMDRjYTAgIG1mbjogMDAwMDRjYTANCg0KKFhF
TikgWzIwMTItMDgtMzEgMjE6MzI6NDNdICAgZ2ZuOiAwMDAwNGNhMSAgbWZuOiAwMDAwNGNh
MQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo0M10gICBnZm46IDAwMDA0Y2EyICBtZm46
IDAwMDA0Y2EyDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjQzXSAgIGdmbjogMDAwMDRj
YTMgIG1mbjogMDAwMDRjYTMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NDNdICAgZ2Zu
OiAwMDAwNGNhNCAgbWZuOiAwMDAwNGNhNA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo0
M10gICBnZm46IDAwMDA0Y2E1ICBtZm46IDAwMDA0Y2E1DQoNCihYRU4pIFsyMDEyLTA4LTMx
IDIxOjMyOjQzXSAgIGdmbjogMDAwMDRjYTYgIG1mbjogMDAwMDRjYTYNCg0KKFhFTikgWzIw
MTItMDgtMzEgMjE6MzI6NDNdICAgZ2ZuOiAwMDAwNGNhNyAgbWZuOiAwMDAwNGNhNw0KDQoo
WEVOKSBbMjAxMi0wOC0zMSAyMTozMjo0M10gICBnZm46IDAwMDA0Y2E4ICBtZm46IDAwMDA0
Y2E4DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjQzXSAgIGdmbjogMDAwMDRjYTkgIG1m
bjogMDAwMDRjYTkNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NDNdICAgZ2ZuOiAwMDAw
NGNhYSAgbWZuOiAwMDAwNGNhYQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo0M10gICBn
Zm46IDAwMDA0Y2FiICBtZm46IDAwMDA0Y2FiDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMy
OjQzXSAgIGdmbjogMDAwMDRjYWMgIG1mbjogMDAwMDRjYWMNCg0KKFhFTikgWzIwMTItMDgt
MzEgMjE6MzI6NDNdICAgZ2ZuOiAwMDAwNGNhZCAgbWZuOiAwMDAwNGNhZA0KDQooWEVOKSBb
MjAxMi0wOC0zMSAyMTozMjo0M10gICBnZm46IDAwMDA0Y2FlICBtZm46IDAwMDA0Y2FlDQoN
CihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjQzXSAgIGdmbjogMDAwMDRjYWYgIG1mbjogMDAw
MDRjYWYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NDNdICAgZ2ZuOiAwMDAwNGNiMCAg
bWZuOiAwMDAwNGNiMA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo0M10gICBnZm46IDAw
MDA0Y2IxICBtZm46IDAwMDA0Y2IxDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjQ0XSAg
IGdmbjogMDAwMDRjYjIgIG1mbjogMDAwMDRjYjINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6
MzI6NDRdICAgZ2ZuOiAwMDAwNGNiMyAgbWZuOiAwMDAwNGNiMw0KDQooWEVOKSBbMjAxMi0w
OC0zMSAyMTozMjo0NF0gICBnZm46IDAwMDA0Y2I0ICBtZm46IDAwMDA0Y2I0DQoNCihYRU4p
IFsyMDEyLTA4LTMxIDIxOjMyOjQ0XSAgIGdmbjogMDAwMDRjYjUgIG1mbjogMDAwMDRjYjUN
Cg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NDRdICAgZ2ZuOiAwMDAwNGNiNiAgbWZuOiAw
MDAwNGNiNg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo0NF0gICBnZm46IDAwMDA0Y2I3
ICBtZm46IDAwMDA0Y2I3DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjQ0XSAgIGdmbjog
MDAwMDRjYjggIG1mbjogMDAwMDRjYjgNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NDRd
ICAgZ2ZuOiAwMDAwNGNiOSAgbWZuOiAwMDAwNGNiOQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAy
MTozMjo0NF0gICBnZm46IDAwMDA0Y2JhICBtZm46IDAwMDA0Y2JhDQoNCihYRU4pIFsyMDEy
LTA4LTMxIDIxOjMyOjQ0XSAgIGdmbjogMDAwMDRjYmIgIG1mbjogMDAwMDRjYmINCg0KKFhF
TikgWzIwMTItMDgtMzEgMjE6MzI6NDRdICAgZ2ZuOiAwMDAwNGNiYyAgbWZuOiAwMDAwNGNi
Yw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo0NF0gICBnZm46IDAwMDA0Y2JkICBtZm46
IDAwMDA0Y2JkDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjQ0XSAgIGdmbjogMDAwMDRj
YmUgIG1mbjogMDAwMDRjYmUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NDRdICAgZ2Zu
OiAwMDAwNGNiZiAgbWZuOiAwMDAwNGNiZg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo0
NF0gICBnZm46IDAwMDA0Y2MwICBtZm46IDAwMDA0Y2MwDQoNCihYRU4pIFsyMDEyLTA4LTMx
IDIxOjMyOjQ0XSAgIGdmbjogMDAwMDRjYzEgIG1mbjogMDAwMDRjYzENCg0KKFhFTikgWzIw
MTItMDgtMzEgMjE6MzI6NDRdICAgZ2ZuOiAwMDAwNGNjMiAgbWZuOiAwMDAwNGNjMg0KDQoo
WEVOKSBbMjAxMi0wOC0zMSAyMTozMjo0NF0gICBnZm46IDAwMDA0Y2MzICBtZm46IDAwMDA0
Y2MzDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjQ0XSAgIGdmbjogMDAwMDRjYzQgIG1m
bjogMDAwMDRjYzQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NDRdICAgZ2ZuOiAwMDAw
NGNjNSAgbWZuOiAwMDAwNGNjNQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo0NF0gICBn
Zm46IDAwMDA0Y2M2ICBtZm46IDAwMDA0Y2M2DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMy
OjQ0XSAgIGdmbjogMDAwMDRjYzcgIG1mbjogMDAwMDRjYzcNCg0KKFhFTikgWzIwMTItMDgt
MzEgMjE6MzI6NDRdICAgZ2ZuOiAwMDAwNGNjOCAgbWZuOiAwMDAwNGNjOA0KDQooWEVOKSBb
MjAxMi0wOC0zMSAyMTozMjo0NF0gICBnZm46IDAwMDA0Y2M5ICBtZm46IDAwMDA0Y2M5DQoN
CihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjQ0XSAgIGdmbjogMDAwMDRjY2EgIG1mbjogMDAw
MDRjY2ENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NDRdICAgZ2ZuOiAwMDAwNGNjYiAg
bWZuOiAwMDAwNGNjYg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo0NF0gICBnZm46IDAw
MDA0Y2NjICBtZm46IDAwMDA0Y2NjDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjQ0XSAg
IGdmbjogMDAwMDRjY2QgIG1mbjogMDAwMDRjY2QNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6
MzI6NDRdICAgZ2ZuOiAwMDAwNGNjZSAgbWZuOiAwMDAwNGNjZQ0KDQooWEVOKSBbMjAxMi0w
OC0zMSAyMTozMjo0NF0gICBnZm46IDAwMDA0Y2NmICBtZm46IDAwMDA0Y2NmDQoNCihYRU4p
IFsyMDEyLTA4LTMxIDIxOjMyOjQ0XSAgIGdmbjogMDAwMDRjZDAgIG1mbjogMDAwMDRjZDAN
Cg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NDRdICAgZ2ZuOiAwMDAwNGNkMSAgbWZuOiAw
MDAwNGNkMQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo0NF0gICBnZm46IDAwMDA0Y2Qy
ICBtZm46IDAwMDA0Y2QyDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjQ0XSAgIGdmbjog
MDAwMDRjZDMgIG1mbjogMDAwMDRjZDMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NDRd
ICAgZ2ZuOiAwMDAwNGNkNCAgbWZuOiAwMDAwNGNkNA0KDQooWEVOKSBbMjAxMi0wOC0zMSAy
MTozMjo0NF0gICBnZm46IDAwMDA0Y2Q1ICBtZm46IDAwMDA0Y2Q1DQoNCihYRU4pIFsyMDEy
LTA4LTMxIDIxOjMyOjQ0XSAgIGdmbjogMDAwMDRjZDYgIG1mbjogMDAwMDRjZDYNCg0KKFhF
TikgWzIwMTItMDgtMzEgMjE6MzI6NDRdICAgZ2ZuOiAwMDAwNGNkNyAgbWZuOiAwMDAwNGNk
Nw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo0NF0gICBnZm46IDAwMDA0Y2Q4ICBtZm46
IDAwMDA0Y2Q4DQoNClsgIDQzMC41ODQ4NzFdIGEoWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo0
NF0gICBnZm46IDAwMDA0Y2Q5ICBtZm46IDAwMDA0Y2Q5DQoNCnRhMS4wMDogcWMgdGltZW91
dCAoY21kIDB4ZWMpDQoNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NDRdICAgZ2ZuOiAw
MDAwNGNkYSAgbWZuOiAwMDAwNGNkYQ0KDQpbICA0MzAuNjQyNzEyXSBhKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzI6NDRdICAgZ2ZuOiAwMDAwNGNkYiAgbWZuOiAwMDAwNGNkYg0KDQp0YTEu
MDA6IGZhaWxlZCB0KFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NDRdICAgZ2ZuOiAwMDAwNGNk
YyAgbWZuOiAwMDAwNGNkYw0KDQpvIElERU5USUZZIChJL08gKFhFTikgWzIwMTItMDgtMzEg
MjE6MzI6NDRdICAgZ2ZuOiAwMDAwNGNkZCAgbWZuOiAwMDAwNGNkZA0KDQplcnJvciwgZXJy
X21hc2s9KFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NDRdICAgZ2ZuOiAwMDAwNGNkZSAgbWZu
OiAwMDAwNGNkZQ0KDQoweDQpDQoNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NDRdICAg
Z2ZuOiAwMDAwNGNkZiAgbWZuOiAwMDAwNGNkZg0KDQpbICA0MzAuNzM4MzA4XSBhKFhFTikg
WzIwMTItMDgtMzEgMjE6MzI6NDRdICAgZ2ZuOiAwMDAwNGNlMCAgbWZuOiAwMDAwNGNlMA0K
DQp0YTEuMDA6IHJldmFsaWRhKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NDRdICAgZ2ZuOiAw
MDAwNGNlMSAgbWZuOiAwMDAwNGNlMQ0KDQp0aW9uIGZhaWxlZCAoZXJybm89LTUpDQoNCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NDRdICAgZ2ZuOiAwMDAwNGNlMiAgbWZuOiAwMDAw
NGNlMg0KDQpbICA0MzAuODAwNjc4XSBhKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NDRdICAg
Z2ZuOiAwMDAwNGNlMyAgbWZuOiAwMDAwNGNlMw0KDQp0YTE6IGxpbWl0aW5nIFNBKFhFTikg
WzIwMTItMDgtMzEgMjE6MzI6NDRdICAgZ2ZuOiAwMDAwNGNlNCAgbWZuOiAwMDAwNGNlNA0K
DQpUQSBsaW5rIHNwZWVkIHRvKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NDRdICAgZ2ZuOiAw
MDAwNGNlNSAgbWZuOiAwMDAwNGNlNQ0KDQogMS41IEdicHMNCg0KDQooWEVOKSBbMjAxMi0w
OC0zMSAyMTozMjo0NF0gICBnZm46IDAwMDA0Y2U2ICBtZm46IDAwMDA0Y2U2DQoNCihYRU4p
IFsyMDEyLTA4LTMxIDIxOjMyOjQ0XSAgIGdmbjogMDAwMDRjZTcgIG1mbjogMDAwMDRjZTcN
Cg0KWyAgNDMwLjg3OTcyMV0gYShYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjQ0XSAgIGdmbjog
MDAwMDRjZTggIG1mbjogMDAwMDRjZTgNCg0KdGExOiBoYXJkIHJlc2V0dChYRU4pIFsyMDEy
LTA4LTMxIDIxOjMyOjQ0XSAgIGdmbjogMDAwMDRjZTkgIG1mbjogMDAwMDRjZTkNCg0KaW5n
IGxpbmsNCg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo0NF0gICBnZm46IDAwMDA0Y2Vh
ICBtZm46IDAwMDA0Y2VhDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjQ0XSAgIGdmbjog
MDAwMDRjZWIgIG1mbjogMDAwMDRjZWINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NDRd
ICAgZ2ZuOiAwMDAwNGNlYyAgbWZuOiAwMDAwNGNlYw0KDQooWEVOKSBbMjAxMi0wOC0zMSAy
MTozMjo0NV0gICBnZm46IDAwMDA0Y2VkICBtZm46IDAwMDA0Y2VkDQoNCihYRU4pIFsyMDEy
LTA4LTMxIDIxOjMyOjQ1XSAgIGdmbjogMDAwMDRjZWUgIG1mbjogMDAwMDRjZWUNCg0KKFhF
TikgWzIwMTItMDgtMzEgMjE6MzI6NDVdICAgZ2ZuOiAwMDAwNGNlZiAgbWZuOiAwMDAwNGNl
Zg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo0NV0gICBnZm46IDAwMDA0Y2YwICBtZm46
IDAwMDA0Y2YwDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjQ1XSAgIGdmbjogMDAwMDRj
ZjEgIG1mbjogMDAwMDRjZjENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NDVdICAgZ2Zu
OiAwMDAwNGNmMiAgbWZuOiAwMDAwNGNmMg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo0
NV0gICBnZm46IDAwMDA0Y2YzICBtZm46IDAwMDA0Y2YzDQoNCihYRU4pIFsyMDEyLTA4LTMx
IDIxOjMyOjQ1XSAgIGdmbjogMDAwMDRjZjQgIG1mbjogMDAwMDRjZjQNCg0KKFhFTikgWzIw
MTItMDgtMzEgMjE6MzI6NDVdICAgZ2ZuOiAwMDAwNGNmNSAgbWZuOiAwMDAwNGNmNQ0KDQoo
WEVOKSBbMjAxMi0wOC0zMSAyMTozMjo0NV0gICBnZm46IDAwMDA0Y2Y2ICBtZm46IDAwMDA0
Y2Y2DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjQ1XSAgIGdmbjogMDAwMDRjZjcgIG1m
bjogMDAwMDRjZjcNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NDVdICAgZ2ZuOiAwMDAw
NGNmOCAgbWZuOiAwMDAwNGNmOA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo0NV0gICBn
Zm46IDAwMDA0Y2Y5ICBtZm46IDAwMDA0Y2Y5DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMy
OjQ1XSAgIGdmbjogMDAwMDRjZmEgIG1mbjogMDAwMDRjZmENCg0KKFhFTikgWzIwMTItMDgt
MzEgMjE6MzI6NDVdICAgZ2ZuOiAwMDAwNGNmYiAgbWZuOiAwMDAwNGNmYg0KDQooWEVOKSBb
MjAxMi0wOC0zMSAyMTozMjo0NV0gICBnZm46IDAwMDA0Y2ZjICBtZm46IDAwMDA0Y2ZjDQoN
CihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjQ1XSAgIGdmbjogMDAwMDRjZmQgIG1mbjogMDAw
MDRjZmQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NDVdICAgZ2ZuOiAwMDAwNGNmZSAg
bWZuOiAwMDAwNGNmZQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo0NV0gICBnZm46IDAw
MDA0Y2ZmICBtZm46IDAwMDA0Y2ZmDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjQ1XSAg
IGdmbjogMDAwMDRkMDAgIG1mbjogMDAwMDRkMDANCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6
MzI6NDVdICAgZ2ZuOiAwMDAwNGQwMSAgbWZuOiAwMDAwNGQwMQ0KDQooWEVOKSBbMjAxMi0w
OC0zMSAyMTozMjo0NV0gICBnZm46IDAwMDA0ZDAyICBtZm46IDAwMDA0ZDAyDQoNCihYRU4p
IFsyMDEyLTA4LTMxIDIxOjMyOjQ1XSAgIGdmbjogMDAwMDRkMDMgIG1mbjogMDAwMDRkMDMN
Cg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NDVdICAgZ2ZuOiAwMDAwNGQwNCAgbWZuOiAw
MDAwNGQwNA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo0NV0gICBnZm46IDAwMDA0ZDA1
ICBtZm46IDAwMDA0ZDA1DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjQ1XSAgIGdmbjog
MDAwMDRkMDYgIG1mbjogMDAwMDRkMDYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NDVd
ICAgZ2ZuOiAwMDAwNGQwNyAgbWZuOiAwMDAwNGQwNw0KDQooWEVOKSBbMjAxMi0wOC0zMSAy
MTozMjo0NV0gICBnZm46IDAwMDA0ZDA4ICBtZm46IDAwMDA0ZDA4DQoNCihYRU4pIFsyMDEy
LTA4LTMxIDIxOjMyOjQ1XSAgIGdmbjogMDAwMDRkMDkgIG1mbjogMDAwMDRkMDkNCg0KKFhF
TikgWzIwMTItMDgtMzEgMjE6MzI6NDVdICAgZ2ZuOiAwMDAwNGQwYSAgbWZuOiAwMDAwNGQw
YQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo0NV0gICBnZm46IDAwMDA0ZDBiICBtZm46
IDAwMDA0ZDBiDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjQ1XSAgIGdmbjogMDAwMDRk
MGMgIG1mbjogMDAwMDRkMGMNCg0KWyAgNDMxLjQ2NjQxM10gYShYRU4pIFsyMDEyLTA4LTMx
IDIxOjMyOjQ1XSAgIGdmbjogMDAwMDRkMGQgIG1mbjogMDAwMDRkMGQNCg0KdGExOiBTQVRB
IGxpbmsgdShYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjQ1XSAgIGdmbjogMDAwMDRkMGUgIG1m
bjogMDAwMDRkMGUNCg0KcCAxLjUgR2JwcyAoU1N0YShYRU4pIFsyMDEyLTA4LTMxIDIxOjMy
OjQ1XSAgIGdmbjogMDAwMDRkMGYgIG1mbjogMDAwMDRkMGYNCg0KdHVzIDExMyBTQ29udHJv
bCAzMTApDQoNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NDVdICAgZ2ZuOiAwMDAwNGQx
MCAgbWZuOiAwMDAwNGQxMA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo0NV0gICBnZm46
IDAwMDA0ZDExICBtZm46IDAwMDA0ZDExDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjQ1
XSAgIGdmbjogMDAwMDRkMTIgIG1mbjogMDAwMDRkMTINCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzI6NDVdICAgZ2ZuOiAwMDAwNGQxMyAgbWZuOiAwMDAwNGQxMw0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMjo0NV0gICBnZm46IDAwMDA0ZDE0ICBtZm46IDAwMDA0ZDE0DQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMyOjQ1XSAgIGdmbjogMDAwMDRkMTUgIG1mbjogMDAwMDRk
MTUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NDVdICAgZ2ZuOiAwMDAwNGQxNiAgbWZu
OiAwMDAwNGQxNg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo0NV0gICBnZm46IDAwMDA0
ZDE3ICBtZm46IDAwMDA0ZDE3DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjQ1XSAgIGdm
bjogMDAwMDRkMTggIG1mbjogMDAwMDRkMTgNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6
NDVdICAgZ2ZuOiAwMDAwNGQxOSAgbWZuOiAwMDAwNGQxOQ0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMjo0NV0gICBnZm46IDAwMDA0ZDFhICBtZm46IDAwMDA0ZDFhDQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMyOjQ1XSAgIGdmbjogMDAwMDRkMWIgIG1mbjogMDAwMDRkMWINCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NDVdICAgZ2ZuOiAwMDAwNGQxYyAgbWZuOiAwMDAw
NGQxYw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo0NV0gICBnZm46IDAwMDA0ZDFkICBt
Zm46IDAwMDA0ZDFkDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjQ1XSAgIGdmbjogMDAw
MDRkMWUgIG1mbjogMDAwMDRkMWUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NDVdICAg
Z2ZuOiAwMDAwNGQxZiAgbWZuOiAwMDAwNGQxZg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
Mjo0NV0gICBnZm46IDAwMDA0ZDIwICBtZm46IDAwMDA0ZDIwDQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMyOjQ1XSAgIGdmbjogMDAwMDRkMjEgIG1mbjogMDAwMDRkMjENCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzI6NDVdICAgZ2ZuOiAwMDAwNGQyMiAgbWZuOiAwMDAwNGQyMg0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo0NV0gICBnZm46IDAwMDA0ZDIzICBtZm46IDAw
MDA0ZDIzDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjQ1XSAgIGdmbjogMDAwMDRkMjQg
IG1mbjogMDAwMDRkMjQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NDVdICAgZ2ZuOiAw
MDAwNGQyNSAgbWZuOiAwMDAwNGQyNQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo0NV0g
ICBnZm46IDAwMDA0ZDI2ICBtZm46IDAwMDA0ZDI2DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMyOjQ1XSAgIGdmbjogMDAwMDRkMjcgIG1mbjogMDAwMDRkMjcNCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzI6NDVdICAgZ2ZuOiAwMDAwNGQyOCAgbWZuOiAwMDAwNGQyOA0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMjo0NV0gICBnZm46IDAwMDA0ZDI5ICBtZm46IDAwMDA0ZDI5
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjQ1XSAgIGdmbjogMDAwMDRkMmEgIG1mbjog
MDAwMDRkMmENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NDVdICAgZ2ZuOiAwMDAwNGQy
YiAgbWZuOiAwMDAwNGQyYg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo0Nl0gICBnZm46
IDAwMDA0ZDJjICBtZm46IDAwMDA0ZDJjDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjQ2
XSAgIGdmbjogMDAwMDRkMmQgIG1mbjogMDAwMDRkMmQNCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzI6NDZdICAgZ2ZuOiAwMDAwNGQyZSAgbWZuOiAwMDAwNGQyZQ0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMjo0Nl0gICBnZm46IDAwMDA0ZDJmICBtZm46IDAwMDA0ZDJmDQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMyOjQ2XSAgIGdmbjogMDAwMDRkMzAgIG1mbjogMDAwMDRk
MzANCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NDZdICAgZ2ZuOiAwMDAwNGQzMSAgbWZu
OiAwMDAwNGQzMQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo0Nl0gICBnZm46IDAwMDA0
ZDMyICBtZm46IDAwMDA0ZDMyDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjQ2XSAgIGdm
bjogMDAwMDRkMzMgIG1mbjogMDAwMDRkMzMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6
NDZdICAgZ2ZuOiAwMDAwNGQzNCAgbWZuOiAwMDAwNGQzNA0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMjo0Nl0gICBnZm46IDAwMDA0ZDM1ICBtZm46IDAwMDA0ZDM1DQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMyOjQ2XSAgIGdmbjogMDAwMDRkMzYgIG1mbjogMDAwMDRkMzYNCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NDZdICAgZ2ZuOiAwMDAwNGQzNyAgbWZuOiAwMDAw
NGQzNw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo0Nl0gICBnZm46IDAwMDA0ZDM4ICBt
Zm46IDAwMDA0ZDM4DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjQ2XSAgIGdmbjogMDAw
MDRkMzkgIG1mbjogMDAwMDRkMzkNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NDZdICAg
Z2ZuOiAwMDAwNGQzYSAgbWZuOiAwMDAwNGQzYQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
Mjo0Nl0gICBnZm46IDAwMDA0ZDNiICBtZm46IDAwMDA0ZDNiDQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMyOjQ2XSAgIGdmbjogMDAwMDRkM2MgIG1mbjogMDAwMDRkM2MNCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzI6NDZdICAgZ2ZuOiAwMDAwNGQzZCAgbWZuOiAwMDAwNGQzZA0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo0Nl0gICBnZm46IDAwMDA0ZDNlICBtZm46IDAw
MDA0ZDNlDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjQ2XSAgIGdmbjogMDAwMDRkM2Yg
IG1mbjogMDAwMDRkM2YNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NDZdICAgZ2ZuOiAw
MDAwNGQ0MCAgbWZuOiAwMDAwNGQ0MA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo0Nl0g
ICBnZm46IDAwMDA0ZDQxICBtZm46IDAwMDA0ZDQxDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMyOjQ2XSAgIGdmbjogMDAwMDRkNDIgIG1mbjogMDAwMDRkNDINCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzI6NDZdICAgZ2ZuOiAwMDAwNGQ0MyAgbWZuOiAwMDAwNGQ0Mw0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMjo0Nl0gICBnZm46IDAwMDA0ZDQ0ICBtZm46IDAwMDA0ZDQ0
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjQ2XSAgIGdmbjogMDAwMDRkNDUgIG1mbjog
MDAwMDRkNDUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NDZdICAgZ2ZuOiAwMDAwNGQ0
NiAgbWZuOiAwMDAwNGQ0Ng0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo0Nl0gICBnZm46
IDAwMDA0ZDQ3ICBtZm46IDAwMDA0ZDQ3DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjQ2
XSAgIGdmbjogMDAwMDRkNDggIG1mbjogMDAwMDRkNDgNCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzI6NDZdICAgZ2ZuOiAwMDAwNGQ0OSAgbWZuOiAwMDAwNGQ0OQ0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMjo0Nl0gICBnZm46IDAwMDA0ZDRhICBtZm46IDAwMDA0ZDRhDQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMyOjQ2XSAgIGdmbjogMDAwMDRkNGIgIG1mbjogMDAwMDRk
NGINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NDZdICAgZ2ZuOiAwMDAwNGQ0YyAgbWZu
OiAwMDAwNGQ0Yw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo0Nl0gICBnZm46IDAwMDA0
ZDRkICBtZm46IDAwMDA0ZDRkDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjQ2XSAgIGdm
bjogMDAwMDRkNGUgIG1mbjogMDAwMDRkNGUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6
NDZdICAgZ2ZuOiAwMDAwNGQ0ZiAgbWZuOiAwMDAwNGQ0Zg0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMjo0Nl0gICBnZm46IDAwMDA0ZDUwICBtZm46IDAwMDA0ZDUwDQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMyOjQ2XSAgIGdmbjogMDAwMDRkNTEgIG1mbjogMDAwMDRkNTENCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NDZdICAgZ2ZuOiAwMDAwNGQ1MiAgbWZuOiAwMDAw
NGQ1Mg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo0Nl0gICBnZm46IDAwMDA0ZDUzICBt
Zm46IDAwMDA0ZDUzDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjQ2XSAgIGdmbjogMDAw
MDRkNTQgIG1mbjogMDAwMDRkNTQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NDZdICAg
Z2ZuOiAwMDAwNGQ1NSAgbWZuOiAwMDAwNGQ1NQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
Mjo0Nl0gICBnZm46IDAwMDA0ZDU2ICBtZm46IDAwMDA0ZDU2DQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMyOjQ2XSAgIGdmbjogMDAwMDRkNTcgIG1mbjogMDAwMDRkNTcNCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzI6NDZdICAgZ2ZuOiAwMDAwNGQ1OCAgbWZuOiAwMDAwNGQ1OA0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo0Nl0gICBnZm46IDAwMDA0ZDU5ICBtZm46IDAw
MDA0ZDU5DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjQ2XSAgIGdmbjogMDAwMDRkNWEg
IG1mbjogMDAwMDRkNWENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NDZdICAgZ2ZuOiAw
MDAwNGQ1YiAgbWZuOiAwMDAwNGQ1Yg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo0Nl0g
ICBnZm46IDAwMDA0ZDVjICBtZm46IDAwMDA0ZDVjDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMyOjQ2XSAgIGdmbjogMDAwMDRkNWQgIG1mbjogMDAwMDRkNWQNCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzI6NDZdICAgZ2ZuOiAwMDAwNGQ1ZSAgbWZuOiAwMDAwNGQ1ZQ0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMjo0Nl0gICBnZm46IDAwMDA0ZDVmICBtZm46IDAwMDA0ZDVm
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjQ2XSAgIGdmbjogMDAwMDRkNjAgIG1mbjog
MDAwMDRkNjANCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NDZdICAgZ2ZuOiAwMDAwNGQ2
MSAgbWZuOiAwMDAwNGQ2MQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo0Nl0gICBnZm46
IDAwMDA0ZDYyICBtZm46IDAwMDA0ZDYyDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjQ2
XSAgIGdmbjogMDAwMDRkNjMgIG1mbjogMDAwMDRkNjMNCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzI6NDZdICAgZ2ZuOiAwMDAwNGQ2NCAgbWZuOiAwMDAwNGQ2NA0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMjo0Nl0gICBnZm46IDAwMDA0ZDY1ICBtZm46IDAwMDA0ZDY1DQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMyOjQ2XSAgIGdmbjogMDAwMDRkNjYgIG1mbjogMDAwMDRk
NjYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NDZdICAgZ2ZuOiAwMDAwNGQ2NyAgbWZu
OiAwMDAwNGQ2Nw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo0Nl0gICBnZm46IDAwMDA0
ZDY4ICBtZm46IDAwMDA0ZDY4DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjQ2XSAgIGdm
bjogMDAwMDRkNjkgIG1mbjogMDAwMDRkNjkNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6
NDZdICAgZ2ZuOiAwMDAwNGQ2YSAgbWZuOiAwMDAwNGQ2YQ0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMjo0Nl0gICBnZm46IDAwMDA0ZDZiICBtZm46IDAwMDA0ZDZiDQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMyOjQ3XSAgIGdmbjogMDAwMDRkNmMgIG1mbjogMDAwMDRkNmMNCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NDddICAgZ2ZuOiAwMDAwNGQ2ZCAgbWZuOiAwMDAw
NGQ2ZA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo0N10gICBnZm46IDAwMDA0ZDZlICBt
Zm46IDAwMDA0ZDZlDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjQ3XSAgIGdmbjogMDAw
MDRkNmYgIG1mbjogMDAwMDRkNmYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NDddICAg
Z2ZuOiAwMDAwNGQ3MCAgbWZuOiAwMDAwNGQ3MA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
Mjo0N10gICBnZm46IDAwMDA0ZDcxICBtZm46IDAwMDA0ZDcxDQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMyOjQ3XSAgIGdmbjogMDAwMDRkNzIgIG1mbjogMDAwMDRkNzINCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzI6NDddICAgZ2ZuOiAwMDAwNGQ3MyAgbWZuOiAwMDAwNGQ3Mw0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo0N10gICBnZm46IDAwMDA0ZDc0ICBtZm46IDAw
MDA0ZDc0DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjQ3XSAgIGdmbjogMDAwMDRkNzUg
IG1mbjogMDAwMDRkNzUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NDddICAgZ2ZuOiAw
MDAwNGQ3NiAgbWZuOiAwMDAwNGQ3Ng0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo0N10g
ICBnZm46IDAwMDA0ZDc3ICBtZm46IDAwMDA0ZDc3DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMyOjQ3XSAgIGdmbjogMDAwMDRkNzggIG1mbjogMDAwMDRkNzgNCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzI6NDddICAgZ2ZuOiAwMDAwNGQ3OSAgbWZuOiAwMDAwNGQ3OQ0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMjo0N10gICBnZm46IDAwMDA0ZDdhICBtZm46IDAwMDA0ZDdh
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjQ3XSAgIGdmbjogMDAwMDRkN2IgIG1mbjog
MDAwMDRkN2INCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NDddICAgZ2ZuOiAwMDAwNGQ3
YyAgbWZuOiAwMDAwNGQ3Yw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo0N10gICBnZm46
IDAwMDA0ZDdkICBtZm46IDAwMDA0ZDdkDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjQ3
XSAgIGdmbjogMDAwMDRkN2UgIG1mbjogMDAwMDRkN2UNCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzI6NDddICAgZ2ZuOiAwMDAwNGQ3ZiAgbWZuOiAwMDAwNGQ3Zg0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMjo0N10gICBnZm46IDAwMDA0ZDgwICBtZm46IDAwMDA0ZDgwDQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMyOjQ3XSAgIGdmbjogMDAwMDRkODEgIG1mbjogMDAwMDRk
ODENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NDddICAgZ2ZuOiAwMDAwNGQ4MiAgbWZu
OiAwMDAwNGQ4Mg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo0N10gICBnZm46IDAwMDA0
ZDgzICBtZm46IDAwMDA0ZDgzDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjQ3XSAgIGdm
bjogMDAwMDRkODQgIG1mbjogMDAwMDRkODQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6
NDddICAgZ2ZuOiAwMDAwNGQ4NSAgbWZuOiAwMDAwNGQ4NQ0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMjo0N10gICBnZm46IDAwMDA0ZDg2ICBtZm46IDAwMDA0ZDg2DQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMyOjQ3XSAgIGdmbjogMDAwMDRkODcgIG1mbjogMDAwMDRkODcNCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NDddICAgZ2ZuOiAwMDAwNGQ4OCAgbWZuOiAwMDAw
NGQ4OA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo0N10gICBnZm46IDAwMDA0ZDg5ICBt
Zm46IDAwMDA0ZDg5DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjQ3XSAgIGdmbjogMDAw
MDRkOGEgIG1mbjogMDAwMDRkOGENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NDddICAg
Z2ZuOiAwMDAwNGQ4YiAgbWZuOiAwMDAwNGQ4Yg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
Mjo0N10gICBnZm46IDAwMDA0ZDhjICBtZm46IDAwMDA0ZDhjDQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMyOjQ3XSAgIGdmbjogMDAwMDRkOGQgIG1mbjogMDAwMDRkOGQNCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzI6NDddICAgZ2ZuOiAwMDAwNGQ4ZSAgbWZuOiAwMDAwNGQ4ZQ0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo0N10gICBnZm46IDAwMDA0ZDhmICBtZm46IDAw
MDA0ZDhmDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjQ3XSAgIGdmbjogMDAwMDRkOTAg
IG1mbjogMDAwMDRkOTANCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NDddICAgZ2ZuOiAw
MDAwNGQ5MSAgbWZuOiAwMDAwNGQ5MQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo0N10g
ICBnZm46IDAwMDA0ZDkyICBtZm46IDAwMDA0ZDkyDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMyOjQ3XSAgIGdmbjogMDAwMDRkOTMgIG1mbjogMDAwMDRkOTMNCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzI6NDddICAgZ2ZuOiAwMDAwNGQ5NCAgbWZuOiAwMDAwNGQ5NA0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMjo0N10gICBnZm46IDAwMDA0ZDk1ICBtZm46IDAwMDA0ZDk1
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjQ3XSAgIGdmbjogMDAwMDRkOTYgIG1mbjog
MDAwMDRkOTYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NDddICAgZ2ZuOiAwMDAwNGQ5
NyAgbWZuOiAwMDAwNGQ5Nw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo0N10gICBnZm46
IDAwMDA0ZDk4ICBtZm46IDAwMDA0ZDk4DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjQ3
XSAgIGdmbjogMDAwMDRkOTkgIG1mbjogMDAwMDRkOTkNCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzI6NDddICAgZ2ZuOiAwMDAwNGQ5YSAgbWZuOiAwMDAwNGQ5YQ0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMjo0N10gICBnZm46IDAwMDA0ZDliICBtZm46IDAwMDA0ZDliDQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMyOjQ3XSAgIGdmbjogMDAwMDRkOWMgIG1mbjogMDAwMDRk
OWMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NDddICAgZ2ZuOiAwMDAwNGQ5ZCAgbWZu
OiAwMDAwNGQ5ZA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo0N10gICBnZm46IDAwMDA0
ZDllICBtZm46IDAwMDA0ZDllDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjQ3XSAgIGdm
bjogMDAwMDRkOWYgIG1mbjogMDAwMDRkOWYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6
NDddICAgZ2ZuOiAwMDAwNGRhMCAgbWZuOiAwMDAwNGRhMA0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMjo0N10gICBnZm46IDAwMDA0ZGExICBtZm46IDAwMDA0ZGExDQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMyOjQ3XSAgIGdmbjogMDAwMDRkYTIgIG1mbjogMDAwMDRkYTINCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NDddICAgZ2ZuOiAwMDAwNGRhMyAgbWZuOiAwMDAw
NGRhMw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo0N10gICBnZm46IDAwMDA0ZGE0ICBt
Zm46IDAwMDA0ZGE0DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjQ3XSAgIGdmbjogMDAw
MDRkYTUgIG1mbjogMDAwMDRkYTUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NDddICAg
Z2ZuOiAwMDAwNGRhNiAgbWZuOiAwMDAwNGRhNg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
Mjo0N10gICBnZm46IDAwMDA0ZGE3ICBtZm46IDAwMDA0ZGE3DQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMyOjQ3XSAgIGdmbjogMDAwMDRkYTggIG1mbjogMDAwMDRkYTgNCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzI6NDddICAgZ2ZuOiAwMDAwNGRhOSAgbWZuOiAwMDAwNGRhOQ0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo0N10gICBnZm46IDAwMDA0ZGFhICBtZm46IDAw
MDA0ZGFhDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjQ3XSAgIGdmbjogMDAwMDRkYWIg
IG1mbjogMDAwMDRkYWINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NDddICAgZ2ZuOiAw
MDAwNGRhYyAgbWZuOiAwMDAwNGRhYw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo0OF0g
ICBnZm46IDAwMDA0ZGFkICBtZm46IDAwMDA0ZGFkDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMyOjQ4XSAgIGdmbjogMDAwMDRkYWUgIG1mbjogMDAwMDRkYWUNCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzI6NDhdICAgZ2ZuOiAwMDAwNGRhZiAgbWZuOiAwMDAwNGRhZg0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMjo0OF0gICBnZm46IDAwMDA0ZGIwICBtZm46IDAwMDA0ZGIw
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjQ4XSAgIGdmbjogMDAwMDRkYjEgIG1mbjog
MDAwMDRkYjENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NDhdICAgZ2ZuOiAwMDAwNGRi
MiAgbWZuOiAwMDAwNGRiMg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo0OF0gICBnZm46
IDAwMDA0ZGIzICBtZm46IDAwMDA0ZGIzDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjQ4
XSAgIGdmbjogMDAwMDRkYjQgIG1mbjogMDAwMDRkYjQNCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzI6NDhdICAgZ2ZuOiAwMDAwNGRiNSAgbWZuOiAwMDAwNGRiNQ0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMjo0OF0gICBnZm46IDAwMDA0ZGI2ICBtZm46IDAwMDA0ZGI2DQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMyOjQ4XSAgIGdmbjogMDAwMDRkYjcgIG1mbjogMDAwMDRk
YjcNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NDhdICAgZ2ZuOiAwMDAwNGRiOCAgbWZu
OiAwMDAwNGRiOA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo0OF0gICBnZm46IDAwMDA0
ZGI5ICBtZm46IDAwMDA0ZGI5DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjQ4XSAgIGdm
bjogMDAwMDRkYmEgIG1mbjogMDAwMDRkYmENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6
NDhdICAgZ2ZuOiAwMDAwNGRiYiAgbWZuOiAwMDAwNGRiYg0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMjo0OF0gICBnZm46IDAwMDA0ZGJjICBtZm46IDAwMDA0ZGJjDQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMyOjQ4XSAgIGdmbjogMDAwMDRkYmQgIG1mbjogMDAwMDRkYmQNCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NDhdICAgZ2ZuOiAwMDAwNGRiZSAgbWZuOiAwMDAw
NGRiZQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo0OF0gICBnZm46IDAwMDA0ZGJmICBt
Zm46IDAwMDA0ZGJmDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjQ4XSAgIGdmbjogMDAw
MDRkYzAgIG1mbjogMDAwMDRkYzANCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NDhdICAg
Z2ZuOiAwMDAwNGRjMSAgbWZuOiAwMDAwNGRjMQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
Mjo0OF0gICBnZm46IDAwMDA0ZGMyICBtZm46IDAwMDA0ZGMyDQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMyOjQ4XSAgIGdmbjogMDAwMDRkYzMgIG1mbjogMDAwMDRkYzMNCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzI6NDhdICAgZ2ZuOiAwMDAwNGRjNCAgbWZuOiAwMDAwNGRjNA0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo0OF0gICBnZm46IDAwMDA0ZGM1ICBtZm46IDAw
MDA0ZGM1DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjQ4XSAgIGdmbjogMDAwMDRkYzYg
IG1mbjogMDAwMDRkYzYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NDhdICAgZ2ZuOiAw
MDAwNGRjNyAgbWZuOiAwMDAwNGRjNw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo0OF0g
ICBnZm46IDAwMDA0ZGM4ICBtZm46IDAwMDA0ZGM4DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMyOjQ4XSAgIGdmbjogMDAwMDRkYzkgIG1mbjogMDAwMDRkYzkNCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzI6NDhdICAgZ2ZuOiAwMDAwNGRjYSAgbWZuOiAwMDAwNGRjYQ0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMjo0OF0gICBnZm46IDAwMDA0ZGNiICBtZm46IDAwMDA0ZGNi
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjQ4XSAgIGdmbjogMDAwMDRkY2MgIG1mbjog
MDAwMDRkY2MNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NDhdICAgZ2ZuOiAwMDAwNGRj
ZCAgbWZuOiAwMDAwNGRjZA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo0OF0gICBnZm46
IDAwMDA0ZGNlICBtZm46IDAwMDA0ZGNlDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjQ4
XSAgIGdmbjogMDAwMDRkY2YgIG1mbjogMDAwMDRkY2YNCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzI6NDhdICAgZ2ZuOiAwMDAwNGRkMCAgbWZuOiAwMDAwNGRkMA0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMjo0OF0gICBnZm46IDAwMDA0ZGQxICBtZm46IDAwMDA0ZGQxDQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMyOjQ4XSAgIGdmbjogMDAwMDRkZDIgIG1mbjogMDAwMDRk
ZDINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NDhdICAgZ2ZuOiAwMDAwNGRkMyAgbWZu
OiAwMDAwNGRkMw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo0OF0gICBnZm46IDAwMDA0
ZGQ0ICBtZm46IDAwMDA0ZGQ0DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjQ4XSAgIGdm
bjogMDAwMDRkZDUgIG1mbjogMDAwMDRkZDUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6
NDhdICAgZ2ZuOiAwMDAwNGRkNiAgbWZuOiAwMDAwNGRkNg0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMjo0OF0gICBnZm46IDAwMDA0ZGQ3ICBtZm46IDAwMDA0ZGQ3DQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMyOjQ4XSAgIGdmbjogMDAwMDRkZDggIG1mbjogMDAwMDRkZDgNCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NDhdICAgZ2ZuOiAwMDAwNGRkOSAgbWZuOiAwMDAw
NGRkOQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo0OF0gICBnZm46IDAwMDA0ZGRhICBt
Zm46IDAwMDA0ZGRhDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjQ4XSAgIGdmbjogMDAw
MDRkZGIgIG1mbjogMDAwMDRkZGINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NDhdICAg
Z2ZuOiAwMDAwNGRkYyAgbWZuOiAwMDAwNGRkYw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
Mjo0OF0gICBnZm46IDAwMDA0ZGRkICBtZm46IDAwMDA0ZGRkDQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMyOjQ4XSAgIGdmbjogMDAwMDRkZGUgIG1mbjogMDAwMDRkZGUNCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzI6NDhdICAgZ2ZuOiAwMDAwNGRkZiAgbWZuOiAwMDAwNGRkZg0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo0OF0gICBnZm46IDAwMDA0ZGUwICBtZm46IDAw
MDA0ZGUwDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjQ4XSAgIGdmbjogMDAwMDRkZTEg
IG1mbjogMDAwMDRkZTENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NDhdICAgZ2ZuOiAw
MDAwNGRlMiAgbWZuOiAwMDAwNGRlMg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo0OF0g
ICBnZm46IDAwMDA0ZGUzICBtZm46IDAwMDA0ZGUzDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMyOjQ4XSAgIGdmbjogMDAwMDRkZTQgIG1mbjogMDAwMDRkZTQNCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzI6NDhdICAgZ2ZuOiAwMDAwNGRlNSAgbWZuOiAwMDAwNGRlNQ0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMjo0OF0gICBnZm46IDAwMDA0ZGU2ICBtZm46IDAwMDA0ZGU2
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjQ4XSAgIGdmbjogMDAwMDRkZTcgIG1mbjog
MDAwMDRkZTcNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NDhdICAgZ2ZuOiAwMDAwNGRl
OCAgbWZuOiAwMDAwNGRlOA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo0OF0gICBnZm46
IDAwMDA0ZGU5ICBtZm46IDAwMDA0ZGU5DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjQ4
XSAgIGdmbjogMDAwMDRkZWEgIG1mbjogMDAwMDRkZWENCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzI6NDhdICAgZ2ZuOiAwMDAwNGRlYiAgbWZuOiAwMDAwNGRlYg0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMjo0OF0gICBnZm46IDAwMDA0ZGVjICBtZm46IDAwMDA0ZGVjDQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMyOjQ5XSAgIGdmbjogMDAwMDRkZWQgIG1mbjogMDAwMDRk
ZWQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NDldICAgZ2ZuOiAwMDAwNGRlZSAgbWZu
OiAwMDAwNGRlZQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo0OV0gICBnZm46IDAwMDA0
ZGVmICBtZm46IDAwMDA0ZGVmDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjQ5XSAgIGdm
bjogMDAwMDRkZjAgIG1mbjogMDAwMDRkZjANCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6
NDldICAgZ2ZuOiAwMDAwNGRmMSAgbWZuOiAwMDAwNGRmMQ0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMjo0OV0gICBnZm46IDAwMDA0ZGYyICBtZm46IDAwMDA0ZGYyDQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMyOjQ5XSAgIGdmbjogMDAwMDRkZjMgIG1mbjogMDAwMDRkZjMNCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NDldICAgZ2ZuOiAwMDAwNGRmNCAgbWZuOiAwMDAw
NGRmNA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo0OV0gICBnZm46IDAwMDA0ZGY1ICBt
Zm46IDAwMDA0ZGY1DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjQ5XSAgIGdmbjogMDAw
MDRkZjYgIG1mbjogMDAwMDRkZjYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NDldICAg
Z2ZuOiAwMDAwNGRmNyAgbWZuOiAwMDAwNGRmNw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
Mjo0OV0gICBnZm46IDAwMDA0ZGY4ICBtZm46IDAwMDA0ZGY4DQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMyOjQ5XSAgIGdmbjogMDAwMDRkZjkgIG1mbjogMDAwMDRkZjkNCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzI6NDldICAgZ2ZuOiAwMDAwNGRmYSAgbWZuOiAwMDAwNGRmYQ0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo0OV0gICBnZm46IDAwMDA0ZGZiICBtZm46IDAw
MDA0ZGZiDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjQ5XSAgIGdmbjogMDAwMDRkZmMg
IG1mbjogMDAwMDRkZmMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NDldICAgZ2ZuOiAw
MDAwNGRmZCAgbWZuOiAwMDAwNGRmZA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo0OV0g
ICBnZm46IDAwMDA0ZGZlICBtZm46IDAwMDA0ZGZlDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMyOjQ5XSAgIGdmbjogMDAwMDRkZmYgIG1mbjogMDAwMDRkZmYNCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzI6NDldICAgZ2ZuOiAwMDAwNGUwMCAgbWZuOiAwMDAwNGUwMA0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMjo0OV0gICBnZm46IDAwMDA0ZTAxICBtZm46IDAwMDA0ZTAx
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjQ5XSAgIGdmbjogMDAwMDRlMDIgIG1mbjog
MDAwMDRlMDINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NDldICAgZ2ZuOiAwMDAwNGUw
MyAgbWZuOiAwMDAwNGUwMw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo0OV0gICBnZm46
IDAwMDA0ZTA0ICBtZm46IDAwMDA0ZTA0DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjQ5
XSAgIGdmbjogMDAwMDRlMDUgIG1mbjogMDAwMDRlMDUNCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzI6NDldICAgZ2ZuOiAwMDAwNGUwNiAgbWZuOiAwMDAwNGUwNg0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMjo0OV0gICBnZm46IDAwMDA0ZTA3ICBtZm46IDAwMDA0ZTA3DQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMyOjQ5XSAgIGdmbjogMDAwMDRlMDggIG1mbjogMDAwMDRl
MDgNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NDldICAgZ2ZuOiAwMDAwNGUwOSAgbWZu
OiAwMDAwNGUwOQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo0OV0gICBnZm46IDAwMDA0
ZTBhICBtZm46IDAwMDA0ZTBhDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjQ5XSAgIGdm
bjogMDAwMDRlMGIgIG1mbjogMDAwMDRlMGINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6
NDldICAgZ2ZuOiAwMDAwNGUwYyAgbWZuOiAwMDAwNGUwYw0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMjo0OV0gICBnZm46IDAwMDA0ZTBkICBtZm46IDAwMDA0ZTBkDQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMyOjQ5XSAgIGdmbjogMDAwMDRlMGUgIG1mbjogMDAwMDRlMGUNCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NDldICAgZ2ZuOiAwMDAwNGUwZiAgbWZuOiAwMDAw
NGUwZg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo0OV0gICBnZm46IDAwMDA0ZTEwICBt
Zm46IDAwMDA0ZTEwDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjQ5XSAgIGdmbjogMDAw
MDRlMTEgIG1mbjogMDAwMDRlMTENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NDldICAg
Z2ZuOiAwMDAwNGUxMiAgbWZuOiAwMDAwNGUxMg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
Mjo0OV0gICBnZm46IDAwMDA0ZTEzICBtZm46IDAwMDA0ZTEzDQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMyOjQ5XSAgIGdmbjogMDAwMDRlMTQgIG1mbjogMDAwMDRlMTQNCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzI6NDldICAgZ2ZuOiAwMDAwNGUxNSAgbWZuOiAwMDAwNGUxNQ0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo0OV0gICBnZm46IDAwMDA0ZTE2ICBtZm46IDAw
MDA0ZTE2DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjQ5XSAgIGdmbjogMDAwMDRlMTcg
IG1mbjogMDAwMDRlMTcNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NDldICAgZ2ZuOiAw
MDAwNGUxOCAgbWZuOiAwMDAwNGUxOA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo0OV0g
ICBnZm46IDAwMDA0ZTE5ICBtZm46IDAwMDA0ZTE5DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMyOjQ5XSAgIGdmbjogMDAwMDRlMWEgIG1mbjogMDAwMDRlMWENCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzI6NDldICAgZ2ZuOiAwMDAwNGUxYiAgbWZuOiAwMDAwNGUxYg0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMjo0OV0gICBnZm46IDAwMDA0ZTFjICBtZm46IDAwMDA0ZTFj
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjQ5XSAgIGdmbjogMDAwMDRlMWQgIG1mbjog
MDAwMDRlMWQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NDldICAgZ2ZuOiAwMDAwNGUx
ZSAgbWZuOiAwMDAwNGUxZQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo0OV0gICBnZm46
IDAwMDA0ZTFmICBtZm46IDAwMDA0ZTFmDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjQ5
XSAgIGdmbjogMDAwMDRlMjAgIG1mbjogMDAwMDRlMjANCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzI6NDldICAgZ2ZuOiAwMDAwNGUyMSAgbWZuOiAwMDAwNGUyMQ0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMjo0OV0gICBnZm46IDAwMDA0ZTIyICBtZm46IDAwMDA0ZTIyDQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMyOjQ5XSAgIGdmbjogMDAwMDRlMjMgIG1mbjogMDAwMDRl
MjMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NDldICAgZ2ZuOiAwMDAwNGUyNCAgbWZu
OiAwMDAwNGUyNA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo0OV0gICBnZm46IDAwMDA0
ZTI1ICBtZm46IDAwMDA0ZTI1DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjQ5XSAgIGdm
bjogMDAwMDRlMjYgIG1mbjogMDAwMDRlMjYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6
NDldICAgZ2ZuOiAwMDAwNGUyNyAgbWZuOiAwMDAwNGUyNw0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMjo0OV0gICBnZm46IDAwMDA0ZTI4ICBtZm46IDAwMDA0ZTI4DQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMyOjQ5XSAgIGdmbjogMDAwMDRlMjkgIG1mbjogMDAwMDRlMjkNCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NDldICAgZ2ZuOiAwMDAwNGUyYSAgbWZuOiAwMDAw
NGUyYQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo0OV0gICBnZm46IDAwMDA0ZTJiICBt
Zm46IDAwMDA0ZTJiDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjQ5XSAgIGdmbjogMDAw
MDRlMmMgIG1mbjogMDAwMDRlMmMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NTBdICAg
Z2ZuOiAwMDAwNGUyZCAgbWZuOiAwMDAwNGUyZA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
Mjo1MF0gICBnZm46IDAwMDA0ZTJlICBtZm46IDAwMDA0ZTJlDQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMyOjUwXSAgIGdmbjogMDAwMDRlMmYgIG1mbjogMDAwMDRlMmYNCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzI6NTBdICAgZ2ZuOiAwMDAwNGUzMCAgbWZuOiAwMDAwNGUzMA0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo1MF0gICBnZm46IDAwMDA0ZTMxICBtZm46IDAw
MDA0ZTMxDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjUwXSAgIGdmbjogMDAwMDRlMzIg
IG1mbjogMDAwMDRlMzINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NTBdICAgZ2ZuOiAw
MDAwNGUzMyAgbWZuOiAwMDAwNGUzMw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo1MF0g
ICBnZm46IDAwMDA0ZTM0ICBtZm46IDAwMDA0ZTM0DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMyOjUwXSAgIGdmbjogMDAwMDRlMzUgIG1mbjogMDAwMDRlMzUNCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzI6NTBdICAgZ2ZuOiAwMDAwNGUzNiAgbWZuOiAwMDAwNGUzNg0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMjo1MF0gICBnZm46IDAwMDA0ZTM3ICBtZm46IDAwMDA0ZTM3
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjUwXSAgIGdmbjogMDAwMDRlMzggIG1mbjog
MDAwMDRlMzgNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NTBdICAgZ2ZuOiAwMDAwNGUz
OSAgbWZuOiAwMDAwNGUzOQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo1MF0gICBnZm46
IDAwMDA0ZTNhICBtZm46IDAwMDA0ZTNhDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjUw
XSAgIGdmbjogMDAwMDRlM2IgIG1mbjogMDAwMDRlM2INCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzI6NTBdICAgZ2ZuOiAwMDAwNGUzYyAgbWZuOiAwMDAwNGUzYw0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMjo1MF0gICBnZm46IDAwMDA0ZTNkICBtZm46IDAwMDA0ZTNkDQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMyOjUwXSAgIGdmbjogMDAwMDRlM2UgIG1mbjogMDAwMDRl
M2UNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NTBdICAgZ2ZuOiAwMDAwNGUzZiAgbWZu
OiAwMDAwNGUzZg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo1MF0gICBnZm46IDAwMDA0
ZTQwICBtZm46IDAwMDA0ZTQwDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjUwXSAgIGdm
bjogMDAwMDRlNDEgIG1mbjogMDAwMDRlNDENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6
NTBdICAgZ2ZuOiAwMDAwNGU0MiAgbWZuOiAwMDAwNGU0Mg0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMjo1MF0gICBnZm46IDAwMDA0ZTQzICBtZm46IDAwMDA0ZTQzDQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMyOjUwXSAgIGdmbjogMDAwMDRlNDQgIG1mbjogMDAwMDRlNDQNCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NTBdICAgZ2ZuOiAwMDAwNGU0NSAgbWZuOiAwMDAw
NGU0NQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo1MF0gICBnZm46IDAwMDA0ZTQ2ICBt
Zm46IDAwMDA0ZTQ2DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjUwXSAgIGdmbjogMDAw
MDRlNDcgIG1mbjogMDAwMDRlNDcNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NTBdICAg
Z2ZuOiAwMDAwNGU0OCAgbWZuOiAwMDAwNGU0OA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
Mjo1MF0gICBnZm46IDAwMDA0ZTQ5ICBtZm46IDAwMDA0ZTQ5DQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMyOjUwXSAgIGdmbjogMDAwMDRlNGEgIG1mbjogMDAwMDRlNGENCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzI6NTBdICAgZ2ZuOiAwMDAwNGU0YiAgbWZuOiAwMDAwNGU0Yg0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo1MF0gICBnZm46IDAwMDA0ZTRjICBtZm46IDAw
MDA0ZTRjDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjUwXSAgIGdmbjogMDAwMDRlNGQg
IG1mbjogMDAwMDRlNGQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NTBdICAgZ2ZuOiAw
MDAwNGU0ZSAgbWZuOiAwMDAwNGU0ZQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo1MF0g
ICBnZm46IDAwMDA0ZTRmICBtZm46IDAwMDA0ZTRmDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMyOjUwXSAgIGdmbjogMDAwMDRlNTAgIG1mbjogMDAwMDRlNTANCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzI6NTBdICAgZ2ZuOiAwMDAwNGU1MSAgbWZuOiAwMDAwNGU1MQ0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMjo1MF0gICBnZm46IDAwMDA0ZTUyICBtZm46IDAwMDA0ZTUy
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjUwXSAgIGdmbjogMDAwMDRlNTMgIG1mbjog
MDAwMDRlNTMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NTBdICAgZ2ZuOiAwMDAwNGU1
NCAgbWZuOiAwMDAwNGU1NA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo1MF0gICBnZm46
IDAwMDA0ZTU1ICBtZm46IDAwMDA0ZTU1DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjUw
XSAgIGdmbjogMDAwMDRlNTYgIG1mbjogMDAwMDRlNTYNCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzI6NTBdICAgZ2ZuOiAwMDAwNGU1NyAgbWZuOiAwMDAwNGU1Nw0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMjo1MF0gICBnZm46IDAwMDA0ZTU4ICBtZm46IDAwMDA0ZTU4DQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMyOjUwXSAgIGdmbjogMDAwMDRlNTkgIG1mbjogMDAwMDRl
NTkNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NTBdICAgZ2ZuOiAwMDAwNGU1YSAgbWZu
OiAwMDAwNGU1YQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo1MF0gICBnZm46IDAwMDA0
ZTViICBtZm46IDAwMDA0ZTViDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjUwXSAgIGdm
bjogMDAwMDRlNWMgIG1mbjogMDAwMDRlNWMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6
NTBdICAgZ2ZuOiAwMDAwNGU1ZCAgbWZuOiAwMDAwNGU1ZA0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMjo1MF0gICBnZm46IDAwMDA0ZTVlICBtZm46IDAwMDA0ZTVlDQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMyOjUwXSAgIGdmbjogMDAwMDRlNWYgIG1mbjogMDAwMDRlNWYNCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NTBdICAgZ2ZuOiAwMDAwNGU2MCAgbWZuOiAwMDAw
NGU2MA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo1MF0gICBnZm46IDAwMDA0ZTYxICBt
Zm46IDAwMDA0ZTYxDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjUwXSAgIGdmbjogMDAw
MDRlNjIgIG1mbjogMDAwMDRlNjINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NTBdICAg
Z2ZuOiAwMDAwNGU2MyAgbWZuOiAwMDAwNGU2Mw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
Mjo1MF0gICBnZm46IDAwMDA0ZTY0ICBtZm46IDAwMDA0ZTY0DQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMyOjUwXSAgIGdmbjogMDAwMDRlNjUgIG1mbjogMDAwMDRlNjUNCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzI6NTBdICAgZ2ZuOiAwMDAwNGU2NiAgbWZuOiAwMDAwNGU2Ng0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo1MF0gICBnZm46IDAwMDA0ZTY3ICBtZm46IDAw
MDA0ZTY3DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjUwXSAgIGdmbjogMDAwMDRlNjgg
IG1mbjogMDAwMDRlNjgNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NTBdICAgZ2ZuOiAw
MDAwNGU2OSAgbWZuOiAwMDAwNGU2OQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo1MF0g
ICBnZm46IDAwMDA0ZTZhICBtZm46IDAwMDA0ZTZhDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMyOjUwXSAgIGdmbjogMDAwMDRlNmIgIG1mbjogMDAwMDRlNmINCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzI6NTBdICAgZ2ZuOiAwMDAwNGU2YyAgbWZuOiAwMDAwNGU2Yw0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMjo1MV0gICBnZm46IDAwMDA0ZTZkICBtZm46IDAwMDA0ZTZk
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjUxXSAgIGdmbjogMDAwMDRlNmUgIG1mbjog
MDAwMDRlNmUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NTFdICAgZ2ZuOiAwMDAwNGU2
ZiAgbWZuOiAwMDAwNGU2Zg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo1MV0gICBnZm46
IDAwMDA0ZTcwICBtZm46IDAwMDA0ZTcwDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjUx
XSAgIGdmbjogMDAwMDRlNzEgIG1mbjogMDAwMDRlNzENCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzI6NTFdICAgZ2ZuOiAwMDAwNGU3MiAgbWZuOiAwMDAwNGU3Mg0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMjo1MV0gICBnZm46IDAwMDA0ZTczICBtZm46IDAwMDA0ZTczDQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMyOjUxXSAgIGdmbjogMDAwMDRlNzQgIG1mbjogMDAwMDRl
NzQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NTFdICAgZ2ZuOiAwMDAwNGU3NSAgbWZu
OiAwMDAwNGU3NQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo1MV0gICBnZm46IDAwMDA0
ZTc2ICBtZm46IDAwMDA0ZTc2DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjUxXSAgIGdm
bjogMDAwMDRlNzcgIG1mbjogMDAwMDRlNzcNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6
NTFdICAgZ2ZuOiAwMDAwNGU3OCAgbWZuOiAwMDAwNGU3OA0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMjo1MV0gICBnZm46IDAwMDA0ZTc5ICBtZm46IDAwMDA0ZTc5DQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMyOjUxXSAgIGdmbjogMDAwMDRlN2EgIG1mbjogMDAwMDRlN2ENCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NTFdICAgZ2ZuOiAwMDAwNGU3YiAgbWZuOiAwMDAw
NGU3Yg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo1MV0gICBnZm46IDAwMDA0ZTdjICBt
Zm46IDAwMDA0ZTdjDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjUxXSAgIGdmbjogMDAw
MDRlN2QgIG1mbjogMDAwMDRlN2QNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NTFdICAg
Z2ZuOiAwMDAwNGU3ZSAgbWZuOiAwMDAwNGU3ZQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
Mjo1MV0gICBnZm46IDAwMDA0ZTdmICBtZm46IDAwMDA0ZTdmDQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMyOjUxXSAgIGdmbjogMDAwMDRlODAgIG1mbjogMDAwMDRlODANCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzI6NTFdICAgZ2ZuOiAwMDAwNGU4MSAgbWZuOiAwMDAwNGU4MQ0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo1MV0gICBnZm46IDAwMDA0ZTgyICBtZm46IDAw
MDA0ZTgyDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjUxXSAgIGdmbjogMDAwMDRlODMg
IG1mbjogMDAwMDRlODMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NTFdICAgZ2ZuOiAw
MDAwNGU4NCAgbWZuOiAwMDAwNGU4NA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo1MV0g
ICBnZm46IDAwMDA0ZTg1ICBtZm46IDAwMDA0ZTg1DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMyOjUxXSAgIGdmbjogMDAwMDRlODYgIG1mbjogMDAwMDRlODYNCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzI6NTFdICAgZ2ZuOiAwMDAwNGU4NyAgbWZuOiAwMDAwNGU4Nw0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMjo1MV0gICBnZm46IDAwMDA0ZTg4ICBtZm46IDAwMDA0ZTg4
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjUxXSAgIGdmbjogMDAwMDRlODkgIG1mbjog
MDAwMDRlODkNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NTFdICAgZ2ZuOiAwMDAwNGU4
YSAgbWZuOiAwMDAwNGU4YQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo1MV0gICBnZm46
IDAwMDA0ZThiICBtZm46IDAwMDA0ZThiDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjUx
XSAgIGdmbjogMDAwMDRlOGMgIG1mbjogMDAwMDRlOGMNCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzI6NTFdICAgZ2ZuOiAwMDAwNGU4ZCAgbWZuOiAwMDAwNGU4ZA0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMjo1MV0gICBnZm46IDAwMDA0ZThlICBtZm46IDAwMDA0ZThlDQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMyOjUxXSAgIGdmbjogMDAwMDRlOGYgIG1mbjogMDAwMDRl
OGYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NTFdICAgZ2ZuOiAwMDAwNGU5MCAgbWZu
OiAwMDAwNGU5MA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo1MV0gICBnZm46IDAwMDA0
ZTkxICBtZm46IDAwMDA0ZTkxDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjUxXSAgIGdm
bjogMDAwMDRlOTIgIG1mbjogMDAwMDRlOTINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6
NTFdICAgZ2ZuOiAwMDAwNGU5MyAgbWZuOiAwMDAwNGU5Mw0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMjo1MV0gICBnZm46IDAwMDA0ZTk0ICBtZm46IDAwMDA0ZTk0DQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMyOjUxXSAgIGdmbjogMDAwMDRlOTUgIG1mbjogMDAwMDRlOTUNCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NTFdICAgZ2ZuOiAwMDAwNGU5NiAgbWZuOiAwMDAw
NGU5Ng0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo1MV0gICBnZm46IDAwMDA0ZTk3ICBt
Zm46IDAwMDA0ZTk3DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjUxXSAgIGdmbjogMDAw
MDRlOTggIG1mbjogMDAwMDRlOTgNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NTFdICAg
Z2ZuOiAwMDAwNGU5OSAgbWZuOiAwMDAwNGU5OQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
Mjo1MV0gICBnZm46IDAwMDA0ZTlhICBtZm46IDAwMDA0ZTlhDQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMyOjUxXSAgIGdmbjogMDAwMDRlOWIgIG1mbjogMDAwMDRlOWINCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzI6NTFdICAgZ2ZuOiAwMDAwNGU5YyAgbWZuOiAwMDAwNGU5Yw0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo1MV0gICBnZm46IDAwMDA0ZTlkICBtZm46IDAw
MDA0ZTlkDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjUxXSAgIGdmbjogMDAwMDRlOWUg
IG1mbjogMDAwMDRlOWUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NTFdICAgZ2ZuOiAw
MDAwNGU5ZiAgbWZuOiAwMDAwNGU5Zg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo1MV0g
ICBnZm46IDAwMDA0ZWEwICBtZm46IDAwMDA0ZWEwDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMyOjUxXSAgIGdmbjogMDAwMDRlYTEgIG1mbjogMDAwMDRlYTENCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzI6NTFdICAgZ2ZuOiAwMDAwNGVhMiAgbWZuOiAwMDAwNGVhMg0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMjo1MV0gICBnZm46IDAwMDA0ZWEzICBtZm46IDAwMDA0ZWEz
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjUxXSAgIGdmbjogMDAwMDRlYTQgIG1mbjog
MDAwMDRlYTQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NTFdICAgZ2ZuOiAwMDAwNGVh
NSAgbWZuOiAwMDAwNGVhNQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo1MV0gICBnZm46
IDAwMDA0ZWE2ICBtZm46IDAwMDA0ZWE2DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjUx
XSAgIGdmbjogMDAwMDRlYTcgIG1mbjogMDAwMDRlYTcNCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzI6NTFdICAgZ2ZuOiAwMDAwNGVhOCAgbWZuOiAwMDAwNGVhOA0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMjo1MV0gICBnZm46IDAwMDA0ZWE5ICBtZm46IDAwMDA0ZWE5DQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMyOjUxXSAgIGdmbjogMDAwMDRlYWEgIG1mbjogMDAwMDRl
YWENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NTFdICAgZ2ZuOiAwMDAwNGVhYiAgbWZu
OiAwMDAwNGVhYg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo1MV0gICBnZm46IDAwMDA0
ZWFjICBtZm46IDAwMDA0ZWFjDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjUyXSAgIGdm
bjogMDAwMDRlYWQgIG1mbjogMDAwMDRlYWQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6
NTJdICAgZ2ZuOiAwMDAwNGVhZSAgbWZuOiAwMDAwNGVhZQ0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMjo1Ml0gICBnZm46IDAwMDA0ZWFmICBtZm46IDAwMDA0ZWFmDQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMyOjUyXSAgIGdmbjogMDAwMDRlYjAgIG1mbjogMDAwMDRlYjANCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NTJdICAgZ2ZuOiAwMDAwNGViMSAgbWZuOiAwMDAw
NGViMQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo1Ml0gICBnZm46IDAwMDA0ZWIyICBt
Zm46IDAwMDA0ZWIyDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjUyXSAgIGdmbjogMDAw
MDRlYjMgIG1mbjogMDAwMDRlYjMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NTJdICAg
Z2ZuOiAwMDAwNGViNCAgbWZuOiAwMDAwNGViNA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
Mjo1Ml0gICBnZm46IDAwMDA0ZWI1ICBtZm46IDAwMDA0ZWI1DQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMyOjUyXSAgIGdmbjogMDAwMDRlYjYgIG1mbjogMDAwMDRlYjYNCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzI6NTJdICAgZ2ZuOiAwMDAwNGViNyAgbWZuOiAwMDAwNGViNw0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo1Ml0gICBnZm46IDAwMDA0ZWI4ICBtZm46IDAw
MDA0ZWI4DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjUyXSAgIGdmbjogMDAwMDRlYjkg
IG1mbjogMDAwMDRlYjkNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NTJdICAgZ2ZuOiAw
MDAwNGViYSAgbWZuOiAwMDAwNGViYQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo1Ml0g
ICBnZm46IDAwMDA0ZWJiICBtZm46IDAwMDA0ZWJiDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMyOjUyXSAgIGdmbjogMDAwMDRlYmMgIG1mbjogMDAwMDRlYmMNCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzI6NTJdICAgZ2ZuOiAwMDAwNGViZCAgbWZuOiAwMDAwNGViZA0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMjo1Ml0gICBnZm46IDAwMDA0ZWJlICBtZm46IDAwMDA0ZWJl
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjUyXSAgIGdmbjogMDAwMDRlYmYgIG1mbjog
MDAwMDRlYmYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NTJdICAgZ2ZuOiAwMDAwNGVj
MCAgbWZuOiAwMDAwNGVjMA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo1Ml0gICBnZm46
IDAwMDA0ZWMxICBtZm46IDAwMDA0ZWMxDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjUy
XSAgIGdmbjogMDAwMDRlYzIgIG1mbjogMDAwMDRlYzINCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzI6NTJdICAgZ2ZuOiAwMDAwNGVjMyAgbWZuOiAwMDAwNGVjMw0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMjo1Ml0gICBnZm46IDAwMDA0ZWM0ICBtZm46IDAwMDA0ZWM0DQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMyOjUyXSAgIGdmbjogMDAwMDRlYzUgIG1mbjogMDAwMDRl
YzUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NTJdICAgZ2ZuOiAwMDAwNGVjNiAgbWZu
OiAwMDAwNGVjNg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo1Ml0gICBnZm46IDAwMDA0
ZWM3ICBtZm46IDAwMDA0ZWM3DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjUyXSAgIGdm
bjogMDAwMDRlYzggIG1mbjogMDAwMDRlYzgNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6
NTJdICAgZ2ZuOiAwMDAwNGVjOSAgbWZuOiAwMDAwNGVjOQ0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMjo1Ml0gICBnZm46IDAwMDA0ZWNhICBtZm46IDAwMDA0ZWNhDQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMyOjUyXSAgIGdmbjogMDAwMDRlY2IgIG1mbjogMDAwMDRlY2INCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NTJdICAgZ2ZuOiAwMDAwNGVjYyAgbWZuOiAwMDAw
NGVjYw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo1Ml0gICBnZm46IDAwMDA0ZWNkICBt
Zm46IDAwMDA0ZWNkDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjUyXSAgIGdmbjogMDAw
MDRlY2UgIG1mbjogMDAwMDRlY2UNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NTJdICAg
Z2ZuOiAwMDAwNGVjZiAgbWZuOiAwMDAwNGVjZg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
Mjo1Ml0gICBnZm46IDAwMDA0ZWQwICBtZm46IDAwMDA0ZWQwDQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMyOjUyXSAgIGdmbjogMDAwMDRlZDEgIG1mbjogMDAwMDRlZDENCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzI6NTJdICAgZ2ZuOiAwMDAwNGVkMiAgbWZuOiAwMDAwNGVkMg0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo1Ml0gICBnZm46IDAwMDA0ZWQzICBtZm46IDAw
MDA0ZWQzDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjUyXSAgIGdmbjogMDAwMDRlZDQg
IG1mbjogMDAwMDRlZDQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NTJdICAgZ2ZuOiAw
MDAwNGVkNSAgbWZuOiAwMDAwNGVkNQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo1Ml0g
ICBnZm46IDAwMDA0ZWQ2ICBtZm46IDAwMDA0ZWQ2DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMyOjUyXSAgIGdmbjogMDAwMDRlZDcgIG1mbjogMDAwMDRlZDcNCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzI6NTJdICAgZ2ZuOiAwMDAwNGVkOCAgbWZuOiAwMDAwNGVkOA0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMjo1Ml0gICBnZm46IDAwMDA0ZWQ5ICBtZm46IDAwMDA0ZWQ5
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjUyXSAgIGdmbjogMDAwMDRlZGEgIG1mbjog
MDAwMDRlZGENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NTJdICAgZ2ZuOiAwMDAwNGVk
YiAgbWZuOiAwMDAwNGVkYg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo1Ml0gICBnZm46
IDAwMDA0ZWRjICBtZm46IDAwMDA0ZWRjDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjUy
XSAgIGdmbjogMDAwMDRlZGQgIG1mbjogMDAwMDRlZGQNCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzI6NTJdICAgZ2ZuOiAwMDAwNGVkZSAgbWZuOiAwMDAwNGVkZQ0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMjo1Ml0gICBnZm46IDAwMDA0ZWRmICBtZm46IDAwMDA0ZWRmDQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMyOjUyXSAgIGdmbjogMDAwMDRlZTAgIG1mbjogMDAwMDRl
ZTANCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NTJdICAgZ2ZuOiAwMDAwNGVlMSAgbWZu
OiAwMDAwNGVlMQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo1Ml0gICBnZm46IDAwMDA0
ZWUyICBtZm46IDAwMDA0ZWUyDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjUyXSAgIGdm
bjogMDAwMDRlZTMgIG1mbjogMDAwMDRlZTMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6
NTJdICAgZ2ZuOiAwMDAwNGVlNCAgbWZuOiAwMDAwNGVlNA0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMjo1Ml0gICBnZm46IDAwMDA0ZWU1ICBtZm46IDAwMDA0ZWU1DQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMyOjUyXSAgIGdmbjogMDAwMDRlZTYgIG1mbjogMDAwMDRlZTYNCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NTJdICAgZ2ZuOiAwMDAwNGVlNyAgbWZuOiAwMDAw
NGVlNw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo1Ml0gICBnZm46IDAwMDA0ZWU4ICBt
Zm46IDAwMDA0ZWU4DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjUyXSAgIGdmbjogMDAw
MDRlZTkgIG1mbjogMDAwMDRlZTkNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NTJdICAg
Z2ZuOiAwMDAwNGVlYSAgbWZuOiAwMDAwNGVlYQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
Mjo1Ml0gICBnZm46IDAwMDA0ZWViICBtZm46IDAwMDA0ZWViDQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMyOjUyXSAgIGdmbjogMDAwMDRlZWMgIG1mbjogMDAwMDRlZWMNCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzI6NTNdICAgZ2ZuOiAwMDAwNGVlZCAgbWZuOiAwMDAwNGVlZA0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo1M10gICBnZm46IDAwMDA0ZWVlICBtZm46IDAw
MDA0ZWVlDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjUzXSAgIGdmbjogMDAwMDRlZWYg
IG1mbjogMDAwMDRlZWYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NTNdICAgZ2ZuOiAw
MDAwNGVmMCAgbWZuOiAwMDAwNGVmMA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo1M10g
ICBnZm46IDAwMDA0ZWYxICBtZm46IDAwMDA0ZWYxDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMyOjUzXSAgIGdmbjogMDAwMDRlZjIgIG1mbjogMDAwMDRlZjINCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzI6NTNdICAgZ2ZuOiAwMDAwNGVmMyAgbWZuOiAwMDAwNGVmMw0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMjo1M10gICBnZm46IDAwMDA0ZWY0ICBtZm46IDAwMDA0ZWY0
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjUzXSAgIGdmbjogMDAwMDRlZjUgIG1mbjog
MDAwMDRlZjUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NTNdICAgZ2ZuOiAwMDAwNGVm
NiAgbWZuOiAwMDAwNGVmNg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo1M10gICBnZm46
IDAwMDA0ZWY3ICBtZm46IDAwMDA0ZWY3DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjUz
XSAgIGdmbjogMDAwMDRlZjggIG1mbjogMDAwMDRlZjgNCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzI6NTNdICAgZ2ZuOiAwMDAwNGVmOSAgbWZuOiAwMDAwNGVmOQ0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMjo1M10gICBnZm46IDAwMDA0ZWZhICBtZm46IDAwMDA0ZWZhDQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMyOjUzXSAgIGdmbjogMDAwMDRlZmIgIG1mbjogMDAwMDRl
ZmINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NTNdICAgZ2ZuOiAwMDAwNGVmYyAgbWZu
OiAwMDAwNGVmYw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo1M10gICBnZm46IDAwMDA0
ZWZkICBtZm46IDAwMDA0ZWZkDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjUzXSAgIGdm
bjogMDAwMDRlZmUgIG1mbjogMDAwMDRlZmUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6
NTNdICAgZ2ZuOiAwMDAwNGVmZiAgbWZuOiAwMDAwNGVmZg0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMjo1M10gICBnZm46IDAwMDA0ZjAwICBtZm46IDAwMDA0ZjAwDQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMyOjUzXSAgIGdmbjogMDAwMDRmMDEgIG1mbjogMDAwMDRmMDENCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NTNdICAgZ2ZuOiAwMDAwNGYwMiAgbWZuOiAwMDAw
NGYwMg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo1M10gICBnZm46IDAwMDA0ZjAzICBt
Zm46IDAwMDA0ZjAzDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjUzXSAgIGdmbjogMDAw
MDRmMDQgIG1mbjogMDAwMDRmMDQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NTNdICAg
Z2ZuOiAwMDAwNGYwNSAgbWZuOiAwMDAwNGYwNQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
Mjo1M10gICBnZm46IDAwMDA0ZjA2ICBtZm46IDAwMDA0ZjA2DQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMyOjUzXSAgIGdmbjogMDAwMDRmMDcgIG1mbjogMDAwMDRmMDcNCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzI6NTNdICAgZ2ZuOiAwMDAwNGYwOCAgbWZuOiAwMDAwNGYwOA0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo1M10gICBnZm46IDAwMDA0ZjA5ICBtZm46IDAw
MDA0ZjA5DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjUzXSAgIGdmbjogMDAwMDRmMGEg
IG1mbjogMDAwMDRmMGENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NTNdICAgZ2ZuOiAw
MDAwNGYwYiAgbWZuOiAwMDAwNGYwYg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo1M10g
ICBnZm46IDAwMDA0ZjBjICBtZm46IDAwMDA0ZjBjDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMyOjUzXSAgIGdmbjogMDAwMDRmMGQgIG1mbjogMDAwMDRmMGQNCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzI6NTNdICAgZ2ZuOiAwMDAwNGYwZSAgbWZuOiAwMDAwNGYwZQ0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMjo1M10gICBnZm46IDAwMDA0ZjBmICBtZm46IDAwMDA0ZjBm
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjUzXSAgIGdmbjogMDAwMDRmMTAgIG1mbjog
MDAwMDRmMTANCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NTNdICAgZ2ZuOiAwMDAwNGYx
MSAgbWZuOiAwMDAwNGYxMQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo1M10gICBnZm46
IDAwMDA0ZjEyICBtZm46IDAwMDA0ZjEyDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjUz
XSAgIGdmbjogMDAwMDRmMTMgIG1mbjogMDAwMDRmMTMNCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzI6NTNdICAgZ2ZuOiAwMDAwNGYxNCAgbWZuOiAwMDAwNGYxNA0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMjo1M10gICBnZm46IDAwMDA0ZjE1ICBtZm46IDAwMDA0ZjE1DQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMyOjUzXSAgIGdmbjogMDAwMDRmMTYgIG1mbjogMDAwMDRm
MTYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NTNdICAgZ2ZuOiAwMDAwNGYxNyAgbWZu
OiAwMDAwNGYxNw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo1M10gICBnZm46IDAwMDA0
ZjE4ICBtZm46IDAwMDA0ZjE4DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjUzXSAgIGdm
bjogMDAwMDRmMTkgIG1mbjogMDAwMDRmMTkNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6
NTNdICAgZ2ZuOiAwMDAwNGYxYSAgbWZuOiAwMDAwNGYxYQ0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMjo1M10gICBnZm46IDAwMDA0ZjFiICBtZm46IDAwMDA0ZjFiDQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMyOjUzXSAgIGdmbjogMDAwMDRmMWMgIG1mbjogMDAwMDRmMWMNCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NTNdICAgZ2ZuOiAwMDAwNGYxZCAgbWZuOiAwMDAw
NGYxZA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo1M10gICBnZm46IDAwMDA0ZjFlICBt
Zm46IDAwMDA0ZjFlDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjUzXSAgIGdmbjogMDAw
MDRmMWYgIG1mbjogMDAwMDRmMWYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NTNdICAg
Z2ZuOiAwMDAwNGYyMCAgbWZuOiAwMDAwNGYyMA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
Mjo1M10gICBnZm46IDAwMDA0ZjIxICBtZm46IDAwMDA0ZjIxDQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMyOjUzXSAgIGdmbjogMDAwMDRmMjIgIG1mbjogMDAwMDRmMjINCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzI6NTNdICAgZ2ZuOiAwMDAwNGYyMyAgbWZuOiAwMDAwNGYyMw0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo1M10gICBnZm46IDAwMDA0ZjI0ICBtZm46IDAw
MDA0ZjI0DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjUzXSAgIGdmbjogMDAwMDRmMjUg
IG1mbjogMDAwMDRmMjUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NTNdICAgZ2ZuOiAw
MDAwNGYyNiAgbWZuOiAwMDAwNGYyNg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo1M10g
ICBnZm46IDAwMDA0ZjI3ICBtZm46IDAwMDA0ZjI3DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMyOjUzXSAgIGdmbjogMDAwMDRmMjggIG1mbjogMDAwMDRmMjgNCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzI6NTNdICAgZ2ZuOiAwMDAwNGYyOSAgbWZuOiAwMDAwNGYyOQ0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMjo1M10gICBnZm46IDAwMDA0ZjJhICBtZm46IDAwMDA0ZjJh
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjUzXSAgIGdmbjogMDAwMDRmMmIgIG1mbjog
MDAwMDRmMmINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NTNdICAgZ2ZuOiAwMDAwNGYy
YyAgbWZuOiAwMDAwNGYyYw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo1NF0gICBnZm46
IDAwMDA0ZjJkICBtZm46IDAwMDA0ZjJkDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjU0
XSAgIGdmbjogMDAwMDRmMmUgIG1mbjogMDAwMDRmMmUNCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzI6NTRdICAgZ2ZuOiAwMDAwNGYyZiAgbWZuOiAwMDAwNGYyZg0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMjo1NF0gICBnZm46IDAwMDA0ZjMwICBtZm46IDAwMDA0ZjMwDQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMyOjU0XSAgIGdmbjogMDAwMDRmMzEgIG1mbjogMDAwMDRm
MzENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NTRdICAgZ2ZuOiAwMDAwNGYzMiAgbWZu
OiAwMDAwNGYzMg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo1NF0gICBnZm46IDAwMDA0
ZjMzICBtZm46IDAwMDA0ZjMzDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjU0XSAgIGdm
bjogMDAwMDRmMzQgIG1mbjogMDAwMDRmMzQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6
NTRdICAgZ2ZuOiAwMDAwNGYzNSAgbWZuOiAwMDAwNGYzNQ0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMjo1NF0gICBnZm46IDAwMDA0ZjM2ICBtZm46IDAwMDA0ZjM2DQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMyOjU0XSAgIGdmbjogMDAwMDRmMzcgIG1mbjogMDAwMDRmMzcNCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NTRdICAgZ2ZuOiAwMDAwNGYzOCAgbWZuOiAwMDAw
NGYzOA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo1NF0gICBnZm46IDAwMDA0ZjM5ICBt
Zm46IDAwMDA0ZjM5DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjU0XSAgIGdmbjogMDAw
MDRmM2EgIG1mbjogMDAwMDRmM2ENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NTRdICAg
Z2ZuOiAwMDAwNGYzYiAgbWZuOiAwMDAwNGYzYg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
Mjo1NF0gICBnZm46IDAwMDA0ZjNjICBtZm46IDAwMDA0ZjNjDQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMyOjU0XSAgIGdmbjogMDAwMDRmM2QgIG1mbjogMDAwMDRmM2QNCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzI6NTRdICAgZ2ZuOiAwMDAwNGYzZSAgbWZuOiAwMDAwNGYzZQ0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo1NF0gICBnZm46IDAwMDA0ZjNmICBtZm46IDAw
MDA0ZjNmDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjU0XSAgIGdmbjogMDAwMDRmNDAg
IG1mbjogMDAwMDRmNDANCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NTRdICAgZ2ZuOiAw
MDAwNGY0MSAgbWZuOiAwMDAwNGY0MQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo1NF0g
ICBnZm46IDAwMDA0ZjQyICBtZm46IDAwMDA0ZjQyDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMyOjU0XSAgIGdmbjogMDAwMDRmNDMgIG1mbjogMDAwMDRmNDMNCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzI6NTRdICAgZ2ZuOiAwMDAwNGY0NCAgbWZuOiAwMDAwNGY0NA0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMjo1NF0gICBnZm46IDAwMDA0ZjQ1ICBtZm46IDAwMDA0ZjQ1
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjU0XSAgIGdmbjogMDAwMDRmNDYgIG1mbjog
MDAwMDRmNDYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NTRdICAgZ2ZuOiAwMDAwNGY0
NyAgbWZuOiAwMDAwNGY0Nw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo1NF0gICBnZm46
IDAwMDA0ZjQ4ICBtZm46IDAwMDA0ZjQ4DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjU0
XSAgIGdmbjogMDAwMDRmNDkgIG1mbjogMDAwMDRmNDkNCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzI6NTRdICAgZ2ZuOiAwMDAwNGY0YSAgbWZuOiAwMDAwNGY0YQ0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMjo1NF0gICBnZm46IDAwMDA0ZjRiICBtZm46IDAwMDA0ZjRiDQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMyOjU0XSAgIGdmbjogMDAwMDRmNGMgIG1mbjogMDAwMDRm
NGMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NTRdICAgZ2ZuOiAwMDAwNGY0ZCAgbWZu
OiAwMDAwNGY0ZA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo1NF0gICBnZm46IDAwMDA0
ZjRlICBtZm46IDAwMDA0ZjRlDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjU0XSAgIGdm
bjogMDAwMDRmNGYgIG1mbjogMDAwMDRmNGYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6
NTRdICAgZ2ZuOiAwMDAwNGY1MCAgbWZuOiAwMDAwNGY1MA0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMjo1NF0gICBnZm46IDAwMDA0ZjUxICBtZm46IDAwMDA0ZjUxDQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMyOjU0XSAgIGdmbjogMDAwMDRmNTIgIG1mbjogMDAwMDRmNTINCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NTRdICAgZ2ZuOiAwMDAwNGY1MyAgbWZuOiAwMDAw
NGY1Mw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo1NF0gICBnZm46IDAwMDA0ZjU0ICBt
Zm46IDAwMDA0ZjU0DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjU0XSAgIGdmbjogMDAw
MDRmNTUgIG1mbjogMDAwMDRmNTUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NTRdICAg
Z2ZuOiAwMDAwNGY1NiAgbWZuOiAwMDAwNGY1Ng0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
Mjo1NF0gICBnZm46IDAwMDA0ZjU3ICBtZm46IDAwMDA0ZjU3DQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMyOjU0XSAgIGdmbjogMDAwMDRmNTggIG1mbjogMDAwMDRmNTgNCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzI6NTRdICAgZ2ZuOiAwMDAwNGY1OSAgbWZuOiAwMDAwNGY1OQ0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo1NF0gICBnZm46IDAwMDA0ZjVhICBtZm46IDAw
MDA0ZjVhDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjU0XSAgIGdmbjogMDAwMDRmNWIg
IG1mbjogMDAwMDRmNWINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NTRdICAgZ2ZuOiAw
MDAwNGY1YyAgbWZuOiAwMDAwNGY1Yw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo1NF0g
ICBnZm46IDAwMDA0ZjVkICBtZm46IDAwMDA0ZjVkDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMyOjU0XSAgIGdmbjogMDAwMDRmNWUgIG1mbjogMDAwMDRmNWUNCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzI6NTRdICAgZ2ZuOiAwMDAwNGY1ZiAgbWZuOiAwMDAwNGY1Zg0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMjo1NF0gICBnZm46IDAwMDA0ZjYwICBtZm46IDAwMDA0ZjYw
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjU0XSAgIGdmbjogMDAwMDRmNjEgIG1mbjog
MDAwMDRmNjENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NTRdICAgZ2ZuOiAwMDAwNGY2
MiAgbWZuOiAwMDAwNGY2Mg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo1NF0gICBnZm46
IDAwMDA0ZjYzICBtZm46IDAwMDA0ZjYzDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjU0
XSAgIGdmbjogMDAwMDRmNjQgIG1mbjogMDAwMDRmNjQNCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzI6NTRdICAgZ2ZuOiAwMDAwNGY2NSAgbWZuOiAwMDAwNGY2NQ0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMjo1NF0gICBnZm46IDAwMDA0ZjY2ICBtZm46IDAwMDA0ZjY2DQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMyOjU0XSAgIGdmbjogMDAwMDRmNjcgIG1mbjogMDAwMDRm
NjcNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NTRdICAgZ2ZuOiAwMDAwNGY2OCAgbWZu
OiAwMDAwNGY2OA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo1NF0gICBnZm46IDAwMDA0
ZjY5ICBtZm46IDAwMDA0ZjY5DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjU0XSAgIGdm
bjogMDAwMDRmNmEgIG1mbjogMDAwMDRmNmENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6
NTRdICAgZ2ZuOiAwMDAwNGY2YiAgbWZuOiAwMDAwNGY2Yg0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMjo1NF0gICBnZm46IDAwMDA0ZjZjICBtZm46IDAwMDA0ZjZjDQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMyOjU1XSAgIGdmbjogMDAwMDRmNmQgIG1mbjogMDAwMDRmNmQNCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NTVdICAgZ2ZuOiAwMDAwNGY2ZSAgbWZuOiAwMDAw
NGY2ZQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo1NV0gICBnZm46IDAwMDA0ZjZmICBt
Zm46IDAwMDA0ZjZmDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjU1XSAgIGdmbjogMDAw
MDRmNzAgIG1mbjogMDAwMDRmNzANCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NTVdICAg
Z2ZuOiAwMDAwNGY3MSAgbWZuOiAwMDAwNGY3MQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
Mjo1NV0gICBnZm46IDAwMDA0ZjcyICBtZm46IDAwMDA0ZjcyDQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMyOjU1XSAgIGdmbjogMDAwMDRmNzMgIG1mbjogMDAwMDRmNzMNCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzI6NTVdICAgZ2ZuOiAwMDAwNGY3NCAgbWZuOiAwMDAwNGY3NA0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo1NV0gICBnZm46IDAwMDA0Zjc1ICBtZm46IDAw
MDA0Zjc1DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjU1XSAgIGdmbjogMDAwMDRmNzYg
IG1mbjogMDAwMDRmNzYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NTVdICAgZ2ZuOiAw
MDAwNGY3NyAgbWZuOiAwMDAwNGY3Nw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo1NV0g
ICBnZm46IDAwMDA0Zjc4ICBtZm46IDAwMDA0Zjc4DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMyOjU1XSAgIGdmbjogMDAwMDRmNzkgIG1mbjogMDAwMDRmNzkNCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzI6NTVdICAgZ2ZuOiAwMDAwNGY3YSAgbWZuOiAwMDAwNGY3YQ0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMjo1NV0gICBnZm46IDAwMDA0ZjdiICBtZm46IDAwMDA0Zjdi
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjU1XSAgIGdmbjogMDAwMDRmN2MgIG1mbjog
MDAwMDRmN2MNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NTVdICAgZ2ZuOiAwMDAwNGY3
ZCAgbWZuOiAwMDAwNGY3ZA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo1NV0gICBnZm46
IDAwMDA0ZjdlICBtZm46IDAwMDA0ZjdlDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjU1
XSAgIGdmbjogMDAwMDRmN2YgIG1mbjogMDAwMDRmN2YNCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzI6NTVdICAgZ2ZuOiAwMDAwNGY4MCAgbWZuOiAwMDAwNGY4MA0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMjo1NV0gICBnZm46IDAwMDA0ZjgxICBtZm46IDAwMDA0ZjgxDQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMyOjU1XSAgIGdmbjogMDAwMDRmODIgIG1mbjogMDAwMDRm
ODINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NTVdICAgZ2ZuOiAwMDAwNGY4MyAgbWZu
OiAwMDAwNGY4Mw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo1NV0gICBnZm46IDAwMDA0
Zjg0ICBtZm46IDAwMDA0Zjg0DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjU1XSAgIGdm
bjogMDAwMDRmODUgIG1mbjogMDAwMDRmODUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6
NTVdICAgZ2ZuOiAwMDAwNGY4NiAgbWZuOiAwMDAwNGY4Ng0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMjo1NV0gICBnZm46IDAwMDA0Zjg3ICBtZm46IDAwMDA0Zjg3DQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMyOjU1XSAgIGdmbjogMDAwMDRmODggIG1mbjogMDAwMDRmODgNCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NTVdICAgZ2ZuOiAwMDAwNGY4OSAgbWZuOiAwMDAw
NGY4OQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo1NV0gICBnZm46IDAwMDA0ZjhhICBt
Zm46IDAwMDA0ZjhhDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjU1XSAgIGdmbjogMDAw
MDRmOGIgIG1mbjogMDAwMDRmOGINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NTVdICAg
Z2ZuOiAwMDAwNGY4YyAgbWZuOiAwMDAwNGY4Yw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
Mjo1NV0gICBnZm46IDAwMDA0ZjhkICBtZm46IDAwMDA0ZjhkDQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMyOjU1XSAgIGdmbjogMDAwMDRmOGUgIG1mbjogMDAwMDRmOGUNCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzI6NTVdICAgZ2ZuOiAwMDAwNGY4ZiAgbWZuOiAwMDAwNGY4Zg0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo1NV0gICBnZm46IDAwMDA0ZjkwICBtZm46IDAw
MDA0ZjkwDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjU1XSAgIGdmbjogMDAwMDRmOTEg
IG1mbjogMDAwMDRmOTENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NTVdICAgZ2ZuOiAw
MDAwNGY5MiAgbWZuOiAwMDAwNGY5Mg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo1NV0g
ICBnZm46IDAwMDA0ZjkzICBtZm46IDAwMDA0ZjkzDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMyOjU1XSAgIGdmbjogMDAwMDRmOTQgIG1mbjogMDAwMDRmOTQNCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzI6NTVdICAgZ2ZuOiAwMDAwNGY5NSAgbWZuOiAwMDAwNGY5NQ0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMjo1NV0gICBnZm46IDAwMDA0Zjk2ICBtZm46IDAwMDA0Zjk2
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjU1XSAgIGdmbjogMDAwMDRmOTcgIG1mbjog
MDAwMDRmOTcNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NTVdICAgZ2ZuOiAwMDAwNGY5
OCAgbWZuOiAwMDAwNGY5OA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo1NV0gICBnZm46
IDAwMDA0Zjk5ICBtZm46IDAwMDA0Zjk5DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjU1
XSAgIGdmbjogMDAwMDRmOWEgIG1mbjogMDAwMDRmOWENCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzI6NTVdICAgZ2ZuOiAwMDAwNGY5YiAgbWZuOiAwMDAwNGY5Yg0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMjo1NV0gICBnZm46IDAwMDA0ZjljICBtZm46IDAwMDA0ZjljDQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMyOjU1XSAgIGdmbjogMDAwMDRmOWQgIG1mbjogMDAwMDRm
OWQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NTVdICAgZ2ZuOiAwMDAwNGY5ZSAgbWZu
OiAwMDAwNGY5ZQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo1NV0gICBnZm46IDAwMDA0
ZjlmICBtZm46IDAwMDA0ZjlmDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjU1XSAgIGdm
bjogMDAwMDRmYTAgIG1mbjogMDAwMDRmYTANCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6
NTVdICAgZ2ZuOiAwMDAwNGZhMSAgbWZuOiAwMDAwNGZhMQ0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMjo1NV0gICBnZm46IDAwMDA0ZmEyICBtZm46IDAwMDA0ZmEyDQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMyOjU1XSAgIGdmbjogMDAwMDRmYTMgIG1mbjogMDAwMDRmYTMNCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NTVdICAgZ2ZuOiAwMDAwNGZhNCAgbWZuOiAwMDAw
NGZhNA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo1NV0gICBnZm46IDAwMDA0ZmE1ICBt
Zm46IDAwMDA0ZmE1DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjU1XSAgIGdmbjogMDAw
MDRmYTYgIG1mbjogMDAwMDRmYTYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NTVdICAg
Z2ZuOiAwMDAwNGZhNyAgbWZuOiAwMDAwNGZhNw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
Mjo1NV0gICBnZm46IDAwMDA0ZmE4ICBtZm46IDAwMDA0ZmE4DQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMyOjU1XSAgIGdmbjogMDAwMDRmYTkgIG1mbjogMDAwMDRmYTkNCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzI6NTVdICAgZ2ZuOiAwMDAwNGZhYSAgbWZuOiAwMDAwNGZhYQ0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo1NV0gICBnZm46IDAwMDA0ZmFiICBtZm46IDAw
MDA0ZmFiDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjU1XSAgIGdmbjogMDAwMDRmYWMg
IG1mbjogMDAwMDRmYWMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NTVdICAgZ2ZuOiAw
MDAwNGZhZCAgbWZuOiAwMDAwNGZhZA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo1Nl0g
ICBnZm46IDAwMDA0ZmFlICBtZm46IDAwMDA0ZmFlDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMyOjU2XSAgIGdmbjogMDAwMDRmYWYgIG1mbjogMDAwMDRmYWYNCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzI6NTZdICAgZ2ZuOiAwMDAwNGZiMCAgbWZuOiAwMDAwNGZiMA0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMjo1Nl0gICBnZm46IDAwMDA0ZmIxICBtZm46IDAwMDA0ZmIx
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjU2XSAgIGdmbjogMDAwMDRmYjIgIG1mbjog
MDAwMDRmYjINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NTZdICAgZ2ZuOiAwMDAwNGZi
MyAgbWZuOiAwMDAwNGZiMw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo1Nl0gICBnZm46
IDAwMDA0ZmI0ICBtZm46IDAwMDA0ZmI0DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjU2
XSAgIGdmbjogMDAwMDRmYjUgIG1mbjogMDAwMDRmYjUNCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzI6NTZdICAgZ2ZuOiAwMDAwNGZiNiAgbWZuOiAwMDAwNGZiNg0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMjo1Nl0gICBnZm46IDAwMDA0ZmI3ICBtZm46IDAwMDA0ZmI3DQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMyOjU2XSAgIGdmbjogMDAwMDRmYjggIG1mbjogMDAwMDRm
YjgNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NTZdICAgZ2ZuOiAwMDAwNGZiOSAgbWZu
OiAwMDAwNGZiOQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo1Nl0gICBnZm46IDAwMDA0
ZmJhICBtZm46IDAwMDA0ZmJhDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjU2XSAgIGdm
bjogMDAwMDRmYmIgIG1mbjogMDAwMDRmYmINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6
NTZdICAgZ2ZuOiAwMDAwNGZiYyAgbWZuOiAwMDAwNGZiYw0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMjo1Nl0gICBnZm46IDAwMDA0ZmJkICBtZm46IDAwMDA0ZmJkDQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMyOjU2XSAgIGdmbjogMDAwMDRmYmUgIG1mbjogMDAwMDRmYmUNCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NTZdICAgZ2ZuOiAwMDAwNGZiZiAgbWZuOiAwMDAw
NGZiZg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo1Nl0gICBnZm46IDAwMDA0ZmMwICBt
Zm46IDAwMDA0ZmMwDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjU2XSAgIGdmbjogMDAw
MDRmYzEgIG1mbjogMDAwMDRmYzENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NTZdICAg
Z2ZuOiAwMDAwNGZjMiAgbWZuOiAwMDAwNGZjMg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
Mjo1Nl0gICBnZm46IDAwMDA0ZmMzICBtZm46IDAwMDA0ZmMzDQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMyOjU2XSAgIGdmbjogMDAwMDRmYzQgIG1mbjogMDAwMDRmYzQNCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzI6NTZdICAgZ2ZuOiAwMDAwNGZjNSAgbWZuOiAwMDAwNGZjNQ0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo1Nl0gICBnZm46IDAwMDA0ZmM2ICBtZm46IDAw
MDA0ZmM2DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjU2XSAgIGdmbjogMDAwMDRmYzcg
IG1mbjogMDAwMDRmYzcNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NTZdICAgZ2ZuOiAw
MDAwNGZjOCAgbWZuOiAwMDAwNGZjOA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo1Nl0g
ICBnZm46IDAwMDA0ZmM5ICBtZm46IDAwMDA0ZmM5DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMyOjU2XSAgIGdmbjogMDAwMDRmY2EgIG1mbjogMDAwMDRmY2ENCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzI6NTZdICAgZ2ZuOiAwMDAwNGZjYiAgbWZuOiAwMDAwNGZjYg0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMjo1Nl0gICBnZm46IDAwMDA0ZmNjICBtZm46IDAwMDA0ZmNj
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjU2XSAgIGdmbjogMDAwMDRmY2QgIG1mbjog
MDAwMDRmY2QNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NTZdICAgZ2ZuOiAwMDAwNGZj
ZSAgbWZuOiAwMDAwNGZjZQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo1Nl0gICBnZm46
IDAwMDA0ZmNmICBtZm46IDAwMDA0ZmNmDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjU2
XSAgIGdmbjogMDAwMDRmZDAgIG1mbjogMDAwMDRmZDANCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzI6NTZdICAgZ2ZuOiAwMDAwNGZkMSAgbWZuOiAwMDAwNGZkMQ0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMjo1Nl0gICBnZm46IDAwMDA0ZmQyICBtZm46IDAwMDA0ZmQyDQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMyOjU2XSAgIGdmbjogMDAwMDRmZDMgIG1mbjogMDAwMDRm
ZDMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NTZdICAgZ2ZuOiAwMDAwNGZkNCAgbWZu
OiAwMDAwNGZkNA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo1Nl0gICBnZm46IDAwMDA0
ZmQ1ICBtZm46IDAwMDA0ZmQ1DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjU2XSAgIGdm
bjogMDAwMDRmZDYgIG1mbjogMDAwMDRmZDYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6
NTZdICAgZ2ZuOiAwMDAwNGZkNyAgbWZuOiAwMDAwNGZkNw0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMjo1Nl0gICBnZm46IDAwMDA0ZmQ4ICBtZm46IDAwMDA0ZmQ4DQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMyOjU2XSAgIGdmbjogMDAwMDRmZDkgIG1mbjogMDAwMDRmZDkNCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NTZdICAgZ2ZuOiAwMDAwNGZkYSAgbWZuOiAwMDAw
NGZkYQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo1Nl0gICBnZm46IDAwMDA0ZmRiICBt
Zm46IDAwMDA0ZmRiDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjU2XSAgIGdmbjogMDAw
MDRmZGMgIG1mbjogMDAwMDRmZGMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NTZdICAg
Z2ZuOiAwMDAwNGZkZCAgbWZuOiAwMDAwNGZkZA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
Mjo1Nl0gICBnZm46IDAwMDA0ZmRlICBtZm46IDAwMDA0ZmRlDQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMyOjU2XSAgIGdmbjogMDAwMDRmZGYgIG1mbjogMDAwMDRmZGYNCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzI6NTZdICAgZ2ZuOiAwMDAwNGZlMCAgbWZuOiAwMDAwNGZlMA0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo1Nl0gICBnZm46IDAwMDA0ZmUxICBtZm46IDAw
MDA0ZmUxDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjU2XSAgIGdmbjogMDAwMDRmZTIg
IG1mbjogMDAwMDRmZTINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NTZdICAgZ2ZuOiAw
MDAwNGZlMyAgbWZuOiAwMDAwNGZlMw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo1Nl0g
ICBnZm46IDAwMDA0ZmU0ICBtZm46IDAwMDA0ZmU0DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMyOjU2XSAgIGdmbjogMDAwMDRmZTUgIG1mbjogMDAwMDRmZTUNCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzI6NTZdICAgZ2ZuOiAwMDAwNGZlNiAgbWZuOiAwMDAwNGZlNg0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMjo1Nl0gICBnZm46IDAwMDA0ZmU3ICBtZm46IDAwMDA0ZmU3
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjU2XSAgIGdmbjogMDAwMDRmZTggIG1mbjog
MDAwMDRmZTgNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NTZdICAgZ2ZuOiAwMDAwNGZl
OSAgbWZuOiAwMDAwNGZlOQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo1Nl0gICBnZm46
IDAwMDA0ZmVhICBtZm46IDAwMDA0ZmVhDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjU2
XSAgIGdmbjogMDAwMDRmZWIgIG1mbjogMDAwMDRmZWINCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzI6NTZdICAgZ2ZuOiAwMDAwNGZlYyAgbWZuOiAwMDAwNGZlYw0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMjo1Nl0gICBnZm46IDAwMDA0ZmVkICBtZm46IDAwMDA0ZmVkDQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMyOjU3XSAgIGdmbjogMDAwMDRmZWUgIG1mbjogMDAwMDRm
ZWUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NTddICAgZ2ZuOiAwMDAwNGZlZiAgbWZu
OiAwMDAwNGZlZg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo1N10gICBnZm46IDAwMDA0
ZmYwICBtZm46IDAwMDA0ZmYwDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjU3XSAgIGdm
bjogMDAwMDRmZjEgIG1mbjogMDAwMDRmZjENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6
NTddICAgZ2ZuOiAwMDAwNGZmMiAgbWZuOiAwMDAwNGZmMg0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMjo1N10gICBnZm46IDAwMDA0ZmYzICBtZm46IDAwMDA0ZmYzDQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMyOjU3XSAgIGdmbjogMDAwMDRmZjQgIG1mbjogMDAwMDRmZjQNCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NTddICAgZ2ZuOiAwMDAwNGZmNSAgbWZuOiAwMDAw
NGZmNQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo1N10gICBnZm46IDAwMDA0ZmY2ICBt
Zm46IDAwMDA0ZmY2DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjU3XSAgIGdmbjogMDAw
MDRmZjcgIG1mbjogMDAwMDRmZjcNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NTddICAg
Z2ZuOiAwMDAwNGZmOCAgbWZuOiAwMDAwNGZmOA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
Mjo1N10gICBnZm46IDAwMDA0ZmY5ICBtZm46IDAwMDA0ZmY5DQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMyOjU3XSAgIGdmbjogMDAwMDRmZmEgIG1mbjogMDAwMDRmZmENCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzI6NTddICAgZ2ZuOiAwMDAwNGZmYiAgbWZuOiAwMDAwNGZmYg0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo1N10gICBnZm46IDAwMDA0ZmZjICBtZm46IDAw
MDA0ZmZjDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjU3XSAgIGdmbjogMDAwMDRmZmQg
IG1mbjogMDAwMDRmZmQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NTddICAgZ2ZuOiAw
MDAwNGZmZSAgbWZuOiAwMDAwNGZmZQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo1N10g
ICBnZm46IDAwMDA0ZmZmICBtZm46IDAwMDA0ZmZmDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMyOjU3XSAgIGdmbjogMDAwMDUwMDAgIG1mbjogMDAwMDUwMDANCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzI6NTddICAgZ2ZuOiAwMDAwNTAwMSAgbWZuOiAwMDAwNTAwMQ0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMjo1N10gICBnZm46IDAwMDA1MDAyICBtZm46IDAwMDA1MDAy
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjU3XSAgIGdmbjogMDAwMDUwMDMgIG1mbjog
MDAwMDUwMDMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NTddICAgZ2ZuOiAwMDAwNTAw
NCAgbWZuOiAwMDAwNTAwNA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo1N10gICBnZm46
IDAwMDA1MDA1ICBtZm46IDAwMDA1MDA1DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjU3
XSAgIGdmbjogMDAwMDUwMDYgIG1mbjogMDAwMDUwMDYNCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzI6NTddICAgZ2ZuOiAwMDAwNTAwNyAgbWZuOiAwMDAwNTAwNw0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMjo1N10gICBnZm46IDAwMDA1MDA4ICBtZm46IDAwMDA1MDA4DQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMyOjU3XSAgIGdmbjogMDAwMDUwMDkgIG1mbjogMDAwMDUw
MDkNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NTddICAgZ2ZuOiAwMDAwNTAwYSAgbWZu
OiAwMDAwNTAwYQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo1N10gICBnZm46IDAwMDA1
MDBiICBtZm46IDAwMDA1MDBiDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjU3XSAgIGdm
bjogMDAwMDUwMGMgIG1mbjogMDAwMDUwMGMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6
NTddICAgZ2ZuOiAwMDAwNTAwZCAgbWZuOiAwMDAwNTAwZA0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMjo1N10gICBnZm46IDAwMDA1MDBlICBtZm46IDAwMDA1MDBlDQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMyOjU3XSAgIGdmbjogMDAwMDUwMGYgIG1mbjogMDAwMDUwMGYNCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NTddICAgZ2ZuOiAwMDAwNTAxMCAgbWZuOiAwMDAw
NTAxMA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo1N10gICBnZm46IDAwMDA1MDExICBt
Zm46IDAwMDA1MDExDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjU3XSAgIGdmbjogMDAw
MDUwMTIgIG1mbjogMDAwMDUwMTINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NTddICAg
Z2ZuOiAwMDAwNTAxMyAgbWZuOiAwMDAwNTAxMw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
Mjo1N10gICBnZm46IDAwMDA1MDE0ICBtZm46IDAwMDA1MDE0DQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMyOjU3XSAgIGdmbjogMDAwMDUwMTUgIG1mbjogMDAwMDUwMTUNCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzI6NTddICAgZ2ZuOiAwMDAwNTAxNiAgbWZuOiAwMDAwNTAxNg0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo1N10gICBnZm46IDAwMDA1MDE3ICBtZm46IDAw
MDA1MDE3DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjU3XSAgIGdmbjogMDAwMDUwMTgg
IG1mbjogMDAwMDUwMTgNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NTddICAgZ2ZuOiAw
MDAwNTAxOSAgbWZuOiAwMDAwNTAxOQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo1N10g
ICBnZm46IDAwMDA1MDFhICBtZm46IDAwMDA1MDFhDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMyOjU3XSAgIGdmbjogMDAwMDUwMWIgIG1mbjogMDAwMDUwMWINCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzI6NTddICAgZ2ZuOiAwMDAwNTAxYyAgbWZuOiAwMDAwNTAxYw0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMjo1N10gICBnZm46IDAwMDA1MDFkICBtZm46IDAwMDA1MDFk
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjU3XSAgIGdmbjogMDAwMDUwMWUgIG1mbjog
MDAwMDUwMWUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NTddICAgZ2ZuOiAwMDAwNTAx
ZiAgbWZuOiAwMDAwNTAxZg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo1N10gICBnZm46
IDAwMDA1MDIwICBtZm46IDAwMDA1MDIwDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjU3
XSAgIGdmbjogMDAwMDUwMjEgIG1mbjogMDAwMDUwMjENCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzI6NTddICAgZ2ZuOiAwMDAwNTAyMiAgbWZuOiAwMDAwNTAyMg0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMjo1N10gICBnZm46IDAwMDA1MDIzICBtZm46IDAwMDA1MDIzDQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMyOjU3XSAgIGdmbjogMDAwMDUwMjQgIG1mbjogMDAwMDUw
MjQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NTddICAgZ2ZuOiAwMDAwNTAyNSAgbWZu
OiAwMDAwNTAyNQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo1N10gICBnZm46IDAwMDA1
MDI2ICBtZm46IDAwMDA1MDI2DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjU3XSAgIGdm
bjogMDAwMDUwMjcgIG1mbjogMDAwMDUwMjcNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6
NTddICAgZ2ZuOiAwMDAwNTAyOCAgbWZuOiAwMDAwNTAyOA0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMjo1N10gICBnZm46IDAwMDA1MDI5ICBtZm46IDAwMDA1MDI5DQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMyOjU3XSAgIGdmbjogMDAwMDUwMmEgIG1mbjogMDAwMDUwMmENCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NTddICAgZ2ZuOiAwMDAwNTAyYiAgbWZuOiAwMDAw
NTAyYg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo1N10gICBnZm46IDAwMDA1MDJjICBt
Zm46IDAwMDA1MDJjDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjU3XSAgIGdmbjogMDAw
MDUwMmQgIG1mbjogMDAwMDUwMmQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NThdICAg
Z2ZuOiAwMDAwNTAyZSAgbWZuOiAwMDAwNTAyZQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
Mjo1OF0gICBnZm46IDAwMDA1MDJmICBtZm46IDAwMDA1MDJmDQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMyOjU4XSAgIGdmbjogMDAwMDUwMzAgIG1mbjogMDAwMDUwMzANCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzI6NThdICAgZ2ZuOiAwMDAwNTAzMSAgbWZuOiAwMDAwNTAzMQ0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo1OF0gICBnZm46IDAwMDA1MDMyICBtZm46IDAw
MDA1MDMyDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjU4XSAgIGdmbjogMDAwMDUwMzMg
IG1mbjogMDAwMDUwMzMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NThdICAgZ2ZuOiAw
MDAwNTAzNCAgbWZuOiAwMDAwNTAzNA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo1OF0g
ICBnZm46IDAwMDA1MDM1ICBtZm46IDAwMDA1MDM1DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMyOjU4XSAgIGdmbjogMDAwMDUwMzYgIG1mbjogMDAwMDUwMzYNCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzI6NThdICAgZ2ZuOiAwMDAwNTAzNyAgbWZuOiAwMDAwNTAzNw0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMjo1OF0gICBnZm46IDAwMDA1MDM4ICBtZm46IDAwMDA1MDM4
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjU4XSAgIGdmbjogMDAwMDUwMzkgIG1mbjog
MDAwMDUwMzkNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NThdICAgZ2ZuOiAwMDAwNTAz
YSAgbWZuOiAwMDAwNTAzYQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo1OF0gICBnZm46
IDAwMDA1MDNiICBtZm46IDAwMDA1MDNiDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjU4
XSAgIGdmbjogMDAwMDUwM2MgIG1mbjogMDAwMDUwM2MNCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzI6NThdICAgZ2ZuOiAwMDAwNTAzZCAgbWZuOiAwMDAwNTAzZA0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMjo1OF0gICBnZm46IDAwMDA1MDNlICBtZm46IDAwMDA1MDNlDQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMyOjU4XSAgIGdmbjogMDAwMDUwM2YgIG1mbjogMDAwMDUw
M2YNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NThdICAgZ2ZuOiAwMDAwNTA0MCAgbWZu
OiAwMDAwNTA0MA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo1OF0gICBnZm46IDAwMDA1
MDQxICBtZm46IDAwMDA1MDQxDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjU4XSAgIGdm
bjogMDAwMDUwNDIgIG1mbjogMDAwMDUwNDINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6
NThdICAgZ2ZuOiAwMDAwNTA0MyAgbWZuOiAwMDAwNTA0Mw0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMjo1OF0gICBnZm46IDAwMDA1MDQ0ICBtZm46IDAwMDA1MDQ0DQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMyOjU4XSAgIGdmbjogMDAwMDUwNDUgIG1mbjogMDAwMDUwNDUNCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NThdICAgZ2ZuOiAwMDAwNTA0NiAgbWZuOiAwMDAw
NTA0Ng0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo1OF0gICBnZm46IDAwMDA1MDQ3ICBt
Zm46IDAwMDA1MDQ3DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjU4XSAgIGdmbjogMDAw
MDUwNDggIG1mbjogMDAwMDUwNDgNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NThdICAg
Z2ZuOiAwMDAwNTA0OSAgbWZuOiAwMDAwNTA0OQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
Mjo1OF0gICBnZm46IDAwMDA1MDRhICBtZm46IDAwMDA1MDRhDQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMyOjU4XSAgIGdmbjogMDAwMDUwNGIgIG1mbjogMDAwMDUwNGINCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzI6NThdICAgZ2ZuOiAwMDAwNTA0YyAgbWZuOiAwMDAwNTA0Yw0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo1OF0gICBnZm46IDAwMDA1MDRkICBtZm46IDAw
MDA1MDRkDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjU4XSAgIGdmbjogMDAwMDUwNGUg
IG1mbjogMDAwMDUwNGUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NThdICAgZ2ZuOiAw
MDAwNTA0ZiAgbWZuOiAwMDAwNTA0Zg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo1OF0g
ICBnZm46IDAwMDA1MDUwICBtZm46IDAwMDA1MDUwDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMyOjU4XSAgIGdmbjogMDAwMDUwNTEgIG1mbjogMDAwMDUwNTENCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzI6NThdICAgZ2ZuOiAwMDAwNTA1MiAgbWZuOiAwMDAwNTA1Mg0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMjo1OF0gICBnZm46IDAwMDA1MDUzICBtZm46IDAwMDA1MDUz
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjU4XSAgIGdmbjogMDAwMDUwNTQgIG1mbjog
MDAwMDUwNTQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NThdICAgZ2ZuOiAwMDAwNTA1
NSAgbWZuOiAwMDAwNTA1NQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo1OF0gICBnZm46
IDAwMDA1MDU2ICBtZm46IDAwMDA1MDU2DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjU4
XSAgIGdmbjogMDAwMDUwNTcgIG1mbjogMDAwMDUwNTcNCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzI6NThdICAgZ2ZuOiAwMDAwNTA1OCAgbWZuOiAwMDAwNTA1OA0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMjo1OF0gICBnZm46IDAwMDA1MDU5ICBtZm46IDAwMDA1MDU5DQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMyOjU4XSAgIGdmbjogMDAwMDUwNWEgIG1mbjogMDAwMDUw
NWENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NThdICAgZ2ZuOiAwMDAwNTA1YiAgbWZu
OiAwMDAwNTA1Yg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo1OF0gICBnZm46IDAwMDA1
MDVjICBtZm46IDAwMDA1MDVjDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjU4XSAgIGdm
bjogMDAwMDUwNWQgIG1mbjogMDAwMDUwNWQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6
NThdICAgZ2ZuOiAwMDAwNTA1ZSAgbWZuOiAwMDAwNTA1ZQ0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMjo1OF0gICBnZm46IDAwMDA1MDVmICBtZm46IDAwMDA1MDVmDQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMyOjU4XSAgIGdmbjogMDAwMDUwNjAgIG1mbjogMDAwMDUwNjANCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NThdICAgZ2ZuOiAwMDAwNTA2MSAgbWZuOiAwMDAw
NTA2MQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo1OF0gICBnZm46IDAwMDA1MDYyICBt
Zm46IDAwMDA1MDYyDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjU4XSAgIGdmbjogMDAw
MDUwNjMgIG1mbjogMDAwMDUwNjMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NThdICAg
Z2ZuOiAwMDAwNTA2NCAgbWZuOiAwMDAwNTA2NA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
Mjo1OF0gICBnZm46IDAwMDA1MDY1ICBtZm46IDAwMDA1MDY1DQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMyOjU4XSAgIGdmbjogMDAwMDUwNjYgIG1mbjogMDAwMDUwNjYNCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzI6NThdICAgZ2ZuOiAwMDAwNTA2NyAgbWZuOiAwMDAwNTA2Nw0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo1OF0gICBnZm46IDAwMDA1MDY4ICBtZm46IDAw
MDA1MDY4DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjU4XSAgIGdmbjogMDAwMDUwNjkg
IG1mbjogMDAwMDUwNjkNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NThdICAgZ2ZuOiAw
MDAwNTA2YSAgbWZuOiAwMDAwNTA2YQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo1OF0g
ICBnZm46IDAwMDA1MDZiICBtZm46IDAwMDA1MDZiDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMyOjU4XSAgIGdmbjogMDAwMDUwNmMgIG1mbjogMDAwMDUwNmMNCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzI6NThdICAgZ2ZuOiAwMDAwNTA2ZCAgbWZuOiAwMDAwNTA2ZA0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMjo1OV0gICBnZm46IDAwMDA1MDZlICBtZm46IDAwMDA1MDZl
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjU5XSAgIGdmbjogMDAwMDUwNmYgIG1mbjog
MDAwMDUwNmYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NTldICAgZ2ZuOiAwMDAwNTA3
MCAgbWZuOiAwMDAwNTA3MA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo1OV0gICBnZm46
IDAwMDA1MDcxICBtZm46IDAwMDA1MDcxDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjU5
XSAgIGdmbjogMDAwMDUwNzIgIG1mbjogMDAwMDUwNzINCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzI6NTldICAgZ2ZuOiAwMDAwNTA3MyAgbWZuOiAwMDAwNTA3Mw0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMjo1OV0gICBnZm46IDAwMDA1MDc0ICBtZm46IDAwMDA1MDc0DQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMyOjU5XSAgIGdmbjogMDAwMDUwNzUgIG1mbjogMDAwMDUw
NzUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NTldICAgZ2ZuOiAwMDAwNTA3NiAgbWZu
OiAwMDAwNTA3Ng0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo1OV0gICBnZm46IDAwMDA1
MDc3ICBtZm46IDAwMDA1MDc3DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjU5XSAgIGdm
bjogMDAwMDUwNzggIG1mbjogMDAwMDUwNzgNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6
NTldICAgZ2ZuOiAwMDAwNTA3OSAgbWZuOiAwMDAwNTA3OQ0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMjo1OV0gICBnZm46IDAwMDA1MDdhICBtZm46IDAwMDA1MDdhDQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMyOjU5XSAgIGdmbjogMDAwMDUwN2IgIG1mbjogMDAwMDUwN2INCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NTldICAgZ2ZuOiAwMDAwNTA3YyAgbWZuOiAwMDAw
NTA3Yw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo1OV0gICBnZm46IDAwMDA1MDdkICBt
Zm46IDAwMDA1MDdkDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjU5XSAgIGdmbjogMDAw
MDUwN2UgIG1mbjogMDAwMDUwN2UNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NTldICAg
Z2ZuOiAwMDAwNTA3ZiAgbWZuOiAwMDAwNTA3Zg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
Mjo1OV0gICBnZm46IDAwMDA1MDgwICBtZm46IDAwMDA1MDgwDQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMyOjU5XSAgIGdmbjogMDAwMDUwODEgIG1mbjogMDAwMDUwODENCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzI6NTldICAgZ2ZuOiAwMDAwNTA4MiAgbWZuOiAwMDAwNTA4Mg0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo1OV0gICBnZm46IDAwMDA1MDgzICBtZm46IDAw
MDA1MDgzDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjU5XSAgIGdmbjogMDAwMDUwODQg
IG1mbjogMDAwMDUwODQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NTldICAgZ2ZuOiAw
MDAwNTA4NSAgbWZuOiAwMDAwNTA4NQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo1OV0g
ICBnZm46IDAwMDA1MDg2ICBtZm46IDAwMDA1MDg2DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMyOjU5XSAgIGdmbjogMDAwMDUwODcgIG1mbjogMDAwMDUwODcNCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzI6NTldICAgZ2ZuOiAwMDAwNTA4OCAgbWZuOiAwMDAwNTA4OA0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMjo1OV0gICBnZm46IDAwMDA1MDg5ICBtZm46IDAwMDA1MDg5
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjU5XSAgIGdmbjogMDAwMDUwOGEgIG1mbjog
MDAwMDUwOGENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NTldICAgZ2ZuOiAwMDAwNTA4
YiAgbWZuOiAwMDAwNTA4Yg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo1OV0gICBnZm46
IDAwMDA1MDhjICBtZm46IDAwMDA1MDhjDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjU5
XSAgIGdmbjogMDAwMDUwOGQgIG1mbjogMDAwMDUwOGQNCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzI6NTldICAgZ2ZuOiAwMDAwNTA4ZSAgbWZuOiAwMDAwNTA4ZQ0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMjo1OV0gICBnZm46IDAwMDA1MDhmICBtZm46IDAwMDA1MDhmDQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMyOjU5XSAgIGdmbjogMDAwMDUwOTAgIG1mbjogMDAwMDUw
OTANCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NTldICAgZ2ZuOiAwMDAwNTA5MSAgbWZu
OiAwMDAwNTA5MQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo1OV0gICBnZm46IDAwMDA1
MDkyICBtZm46IDAwMDA1MDkyDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjU5XSAgIGdm
bjogMDAwMDUwOTMgIG1mbjogMDAwMDUwOTMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6
NTldICAgZ2ZuOiAwMDAwNTA5NCAgbWZuOiAwMDAwNTA5NA0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMjo1OV0gICBnZm46IDAwMDA1MDk1ICBtZm46IDAwMDA1MDk1DQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMyOjU5XSAgIGdmbjogMDAwMDUwOTYgIG1mbjogMDAwMDUwOTYNCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NTldICAgZ2ZuOiAwMDAwNTA5NyAgbWZuOiAwMDAw
NTA5Nw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo1OV0gICBnZm46IDAwMDA1MDk4ICBt
Zm46IDAwMDA1MDk4DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjU5XSAgIGdmbjogMDAw
MDUwOTkgIG1mbjogMDAwMDUwOTkNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NTldICAg
Z2ZuOiAwMDAwNTA5YSAgbWZuOiAwMDAwNTA5YQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
Mjo1OV0gICBnZm46IDAwMDA1MDliICBtZm46IDAwMDA1MDliDQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMyOjU5XSAgIGdmbjogMDAwMDUwOWMgIG1mbjogMDAwMDUwOWMNCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzI6NTldICAgZ2ZuOiAwMDAwNTA5ZCAgbWZuOiAwMDAwNTA5ZA0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo1OV0gICBnZm46IDAwMDA1MDllICBtZm46IDAw
MDA1MDllDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjU5XSAgIGdmbjogMDAwMDUwOWYg
IG1mbjogMDAwMDUwOWYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NTldICAgZ2ZuOiAw
MDAwNTBhMCAgbWZuOiAwMDAwNTBhMA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo1OV0g
ICBnZm46IDAwMDA1MGExICBtZm46IDAwMDA1MGExDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMyOjU5XSAgIGdmbjogMDAwMDUwYTIgIG1mbjogMDAwMDUwYTINCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzI6NTldICAgZ2ZuOiAwMDAwNTBhMyAgbWZuOiAwMDAwNTBhMw0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMjo1OV0gICBnZm46IDAwMDA1MGE0ICBtZm46IDAwMDA1MGE0
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjU5XSAgIGdmbjogMDAwMDUwYTUgIG1mbjog
MDAwMDUwYTUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NTldICAgZ2ZuOiAwMDAwNTBh
NiAgbWZuOiAwMDAwNTBhNg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo1OV0gICBnZm46
IDAwMDA1MGE3ICBtZm46IDAwMDA1MGE3DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMyOjU5
XSAgIGdmbjogMDAwMDUwYTggIG1mbjogMDAwMDUwYTgNCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzI6NTldICAgZ2ZuOiAwMDAwNTBhOSAgbWZuOiAwMDAwNTBhOQ0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMjo1OV0gICBnZm46IDAwMDA1MGFhICBtZm46IDAwMDA1MGFhDQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMyOjU5XSAgIGdmbjogMDAwMDUwYWIgIG1mbjogMDAwMDUw
YWINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzI6NTldICAgZ2ZuOiAwMDAwNTBhYyAgbWZu
OiAwMDAwNTBhYw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMjo1OV0gICBnZm46IDAwMDA1
MGFkICBtZm46IDAwMDA1MGFkDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjAwXSAgIGdm
bjogMDAwMDUwYWUgIG1mbjogMDAwMDUwYWUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6
MDBdICAgZ2ZuOiAwMDAwNTBhZiAgbWZuOiAwMDAwNTBhZg0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMzowMF0gICBnZm46IDAwMDA1MGIwICBtZm46IDAwMDA1MGIwDQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMzOjAwXSAgIGdmbjogMDAwMDUwYjEgIG1mbjogMDAwMDUwYjENCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MDBdICAgZ2ZuOiAwMDAwNTBiMiAgbWZuOiAwMDAw
NTBiMg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzowMF0gICBnZm46IDAwMDA1MGIzICBt
Zm46IDAwMDA1MGIzDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjAwXSAgIGdmbjogMDAw
MDUwYjQgIG1mbjogMDAwMDUwYjQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MDBdICAg
Z2ZuOiAwMDAwNTBiNSAgbWZuOiAwMDAwNTBiNQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
MzowMF0gICBnZm46IDAwMDA1MGI2ICBtZm46IDAwMDA1MGI2DQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMzOjAwXSAgIGdmbjogMDAwMDUwYjcgIG1mbjogMDAwMDUwYjcNCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzM6MDBdICAgZ2ZuOiAwMDAwNTBiOCAgbWZuOiAwMDAwNTBiOA0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzowMF0gICBnZm46IDAwMDA1MGI5ICBtZm46IDAw
MDA1MGI5DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjAwXSAgIGdmbjogMDAwMDUwYmEg
IG1mbjogMDAwMDUwYmENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MDBdICAgZ2ZuOiAw
MDAwNTBiYiAgbWZuOiAwMDAwNTBiYg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzowMF0g
ICBnZm46IDAwMDA1MGJjICBtZm46IDAwMDA1MGJjDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMzOjAwXSAgIGdmbjogMDAwMDUwYmQgIG1mbjogMDAwMDUwYmQNCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzM6MDBdICAgZ2ZuOiAwMDAwNTBiZSAgbWZuOiAwMDAwNTBiZQ0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMzowMF0gICBnZm46IDAwMDA1MGJmICBtZm46IDAwMDA1MGJm
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjAwXSAgIGdmbjogMDAwMDUwYzAgIG1mbjog
MDAwMDUwYzANCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MDBdICAgZ2ZuOiAwMDAwNTBj
MSAgbWZuOiAwMDAwNTBjMQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzowMF0gICBnZm46
IDAwMDA1MGMyICBtZm46IDAwMDA1MGMyDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjAw
XSAgIGdmbjogMDAwMDUwYzMgIG1mbjogMDAwMDUwYzMNCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzM6MDBdICAgZ2ZuOiAwMDAwNTBjNCAgbWZuOiAwMDAwNTBjNA0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMzowMF0gICBnZm46IDAwMDA1MGM1ICBtZm46IDAwMDA1MGM1DQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMzOjAwXSAgIGdmbjogMDAwMDUwYzYgIG1mbjogMDAwMDUw
YzYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MDBdICAgZ2ZuOiAwMDAwNTBjNyAgbWZu
OiAwMDAwNTBjNw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzowMF0gICBnZm46IDAwMDA1
MGM4ICBtZm46IDAwMDA1MGM4DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjAwXSAgIGdm
bjogMDAwMDUwYzkgIG1mbjogMDAwMDUwYzkNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6
MDBdICAgZ2ZuOiAwMDAwNTBjYSAgbWZuOiAwMDAwNTBjYQ0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMzowMF0gICBnZm46IDAwMDA1MGNiICBtZm46IDAwMDA1MGNiDQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMzOjAwXSAgIGdmbjogMDAwMDUwY2MgIG1mbjogMDAwMDUwY2MNCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MDBdICAgZ2ZuOiAwMDAwNTBjZCAgbWZuOiAwMDAw
NTBjZA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzowMF0gICBnZm46IDAwMDA1MGNlICBt
Zm46IDAwMDA1MGNlDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjAwXSAgIGdmbjogMDAw
MDUwY2YgIG1mbjogMDAwMDUwY2YNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MDBdICAg
Z2ZuOiAwMDAwNTBkMCAgbWZuOiAwMDAwNTBkMA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
MzowMF0gICBnZm46IDAwMDA1MGQxICBtZm46IDAwMDA1MGQxDQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMzOjAwXSAgIGdmbjogMDAwMDUwZDIgIG1mbjogMDAwMDUwZDINCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzM6MDBdICAgZ2ZuOiAwMDAwNTBkMyAgbWZuOiAwMDAwNTBkMw0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzowMF0gICBnZm46IDAwMDA1MGQ0ICBtZm46IDAw
MDA1MGQ0DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjAwXSAgIGdmbjogMDAwMDUwZDUg
IG1mbjogMDAwMDUwZDUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MDBdICAgZ2ZuOiAw
MDAwNTBkNiAgbWZuOiAwMDAwNTBkNg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzowMF0g
ICBnZm46IDAwMDA1MGQ3ICBtZm46IDAwMDA1MGQ3DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMzOjAwXSAgIGdmbjogMDAwMDUwZDggIG1mbjogMDAwMDUwZDgNCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzM6MDBdICAgZ2ZuOiAwMDAwNTBkOSAgbWZuOiAwMDAwNTBkOQ0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMzowMF0gICBnZm46IDAwMDA1MGRhICBtZm46IDAwMDA1MGRh
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjAwXSAgIGdmbjogMDAwMDUwZGIgIG1mbjog
MDAwMDUwZGINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MDBdICAgZ2ZuOiAwMDAwNTBk
YyAgbWZuOiAwMDAwNTBkYw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzowMF0gICBnZm46
IDAwMDA1MGRkICBtZm46IDAwMDA1MGRkDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjAw
XSAgIGdmbjogMDAwMDUwZGUgIG1mbjogMDAwMDUwZGUNCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzM6MDBdICAgZ2ZuOiAwMDAwNTBkZiAgbWZuOiAwMDAwNTBkZg0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMzowMF0gICBnZm46IDAwMDA1MGUwICBtZm46IDAwMDA1MGUwDQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMzOjAwXSAgIGdmbjogMDAwMDUwZTEgIG1mbjogMDAwMDUw
ZTENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MDBdICAgZ2ZuOiAwMDAwNTBlMiAgbWZu
OiAwMDAwNTBlMg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzowMF0gICBnZm46IDAwMDA1
MGUzICBtZm46IDAwMDA1MGUzDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjAwXSAgIGdm
bjogMDAwMDUwZTQgIG1mbjogMDAwMDUwZTQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6
MDBdICAgZ2ZuOiAwMDAwNTBlNSAgbWZuOiAwMDAwNTBlNQ0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMzowMF0gICBnZm46IDAwMDA1MGU2ICBtZm46IDAwMDA1MGU2DQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMzOjAwXSAgIGdmbjogMDAwMDUwZTcgIG1mbjogMDAwMDUwZTcNCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MDBdICAgZ2ZuOiAwMDAwNTBlOCAgbWZuOiAwMDAw
NTBlOA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzowMF0gICBnZm46IDAwMDA1MGU5ICBt
Zm46IDAwMDA1MGU5DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjAwXSAgIGdmbjogMDAw
MDUwZWEgIG1mbjogMDAwMDUwZWENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MDBdICAg
Z2ZuOiAwMDAwNTBlYiAgbWZuOiAwMDAwNTBlYg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
MzowMF0gICBnZm46IDAwMDA1MGVjICBtZm46IDAwMDA1MGVjDQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMzOjAwXSAgIGdmbjogMDAwMDUwZWQgIG1mbjogMDAwMDUwZWQNCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzM6MDFdICAgZ2ZuOiAwMDAwNTBlZSAgbWZuOiAwMDAwNTBlZQ0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzowMV0gICBnZm46IDAwMDA1MGVmICBtZm46IDAw
MDA1MGVmDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjAxXSAgIGdmbjogMDAwMDUwZjAg
IG1mbjogMDAwMDUwZjANCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MDFdICAgZ2ZuOiAw
MDAwNTBmMSAgbWZuOiAwMDAwNTBmMQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzowMV0g
ICBnZm46IDAwMDA1MGYyICBtZm46IDAwMDA1MGYyDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMzOjAxXSAgIGdmbjogMDAwMDUwZjMgIG1mbjogMDAwMDUwZjMNCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzM6MDFdICAgZ2ZuOiAwMDAwNTBmNCAgbWZuOiAwMDAwNTBmNA0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMzowMV0gICBnZm46IDAwMDA1MGY1ICBtZm46IDAwMDA1MGY1
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjAxXSAgIGdmbjogMDAwMDUwZjYgIG1mbjog
MDAwMDUwZjYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MDFdICAgZ2ZuOiAwMDAwNTBm
NyAgbWZuOiAwMDAwNTBmNw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzowMV0gICBnZm46
IDAwMDA1MGY4ICBtZm46IDAwMDA1MGY4DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjAx
XSAgIGdmbjogMDAwMDUwZjkgIG1mbjogMDAwMDUwZjkNCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzM6MDFdICAgZ2ZuOiAwMDAwNTBmYSAgbWZuOiAwMDAwNTBmYQ0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMzowMV0gICBnZm46IDAwMDA1MGZiICBtZm46IDAwMDA1MGZiDQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMzOjAxXSAgIGdmbjogMDAwMDUwZmMgIG1mbjogMDAwMDUw
ZmMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MDFdICAgZ2ZuOiAwMDAwNTBmZCAgbWZu
OiAwMDAwNTBmZA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzowMV0gICBnZm46IDAwMDA1
MGZlICBtZm46IDAwMDA1MGZlDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjAxXSAgIGdm
bjogMDAwMDUwZmYgIG1mbjogMDAwMDUwZmYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6
MDFdICAgZ2ZuOiAwMDAwNTEwMCAgbWZuOiAwMDAwNTEwMA0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMzowMV0gICBnZm46IDAwMDA1MTAxICBtZm46IDAwMDA1MTAxDQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMzOjAxXSAgIGdmbjogMDAwMDUxMDIgIG1mbjogMDAwMDUxMDINCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MDFdICAgZ2ZuOiAwMDAwNTEwMyAgbWZuOiAwMDAw
NTEwMw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzowMV0gICBnZm46IDAwMDA1MTA0ICBt
Zm46IDAwMDA1MTA0DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjAxXSAgIGdmbjogMDAw
MDUxMDUgIG1mbjogMDAwMDUxMDUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MDFdICAg
Z2ZuOiAwMDAwNTEwNiAgbWZuOiAwMDAwNTEwNg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
MzowMV0gICBnZm46IDAwMDA1MTA3ICBtZm46IDAwMDA1MTA3DQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMzOjAxXSAgIGdmbjogMDAwMDUxMDggIG1mbjogMDAwMDUxMDgNCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzM6MDFdICAgZ2ZuOiAwMDAwNTEwOSAgbWZuOiAwMDAwNTEwOQ0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzowMV0gICBnZm46IDAwMDA1MTBhICBtZm46IDAw
MDA1MTBhDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjAxXSAgIGdmbjogMDAwMDUxMGIg
IG1mbjogMDAwMDUxMGINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MDFdICAgZ2ZuOiAw
MDAwNTEwYyAgbWZuOiAwMDAwNTEwYw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzowMV0g
ICBnZm46IDAwMDA1MTBkICBtZm46IDAwMDA1MTBkDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMzOjAxXSAgIGdmbjogMDAwMDUxMGUgIG1mbjogMDAwMDUxMGUNCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzM6MDFdICAgZ2ZuOiAwMDAwNTEwZiAgbWZuOiAwMDAwNTEwZg0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMzowMV0gICBnZm46IDAwMDA1MTEwICBtZm46IDAwMDA1MTEw
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjAxXSAgIGdmbjogMDAwMDUxMTEgIG1mbjog
MDAwMDUxMTENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MDFdICAgZ2ZuOiAwMDAwNTEx
MiAgbWZuOiAwMDAwNTExMg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzowMV0gICBnZm46
IDAwMDA1MTEzICBtZm46IDAwMDA1MTEzDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjAx
XSAgIGdmbjogMDAwMDUxMTQgIG1mbjogMDAwMDUxMTQNCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzM6MDFdICAgZ2ZuOiAwMDAwNTExNSAgbWZuOiAwMDAwNTExNQ0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMzowMV0gICBnZm46IDAwMDA1MTE2ICBtZm46IDAwMDA1MTE2DQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMzOjAxXSAgIGdmbjogMDAwMDUxMTcgIG1mbjogMDAwMDUx
MTcNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MDFdICAgZ2ZuOiAwMDAwNTExOCAgbWZu
OiAwMDAwNTExOA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzowMV0gICBnZm46IDAwMDA1
MTE5ICBtZm46IDAwMDA1MTE5DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjAxXSAgIGdm
bjogMDAwMDUxMWEgIG1mbjogMDAwMDUxMWENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6
MDFdICAgZ2ZuOiAwMDAwNTExYiAgbWZuOiAwMDAwNTExYg0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMzowMV0gICBnZm46IDAwMDA1MTFjICBtZm46IDAwMDA1MTFjDQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMzOjAxXSAgIGdmbjogMDAwMDUxMWQgIG1mbjogMDAwMDUxMWQNCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MDFdICAgZ2ZuOiAwMDAwNTExZSAgbWZuOiAwMDAw
NTExZQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzowMV0gICBnZm46IDAwMDA1MTFmICBt
Zm46IDAwMDA1MTFmDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjAxXSAgIGdmbjogMDAw
MDUxMjAgIG1mbjogMDAwMDUxMjANCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MDFdICAg
Z2ZuOiAwMDAwNTEyMSAgbWZuOiAwMDAwNTEyMQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
MzowMV0gICBnZm46IDAwMDA1MTIyICBtZm46IDAwMDA1MTIyDQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMzOjAxXSAgIGdmbjogMDAwMDUxMjMgIG1mbjogMDAwMDUxMjMNCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzM6MDFdICAgZ2ZuOiAwMDAwNTEyNCAgbWZuOiAwMDAwNTEyNA0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzowMV0gICBnZm46IDAwMDA1MTI1ICBtZm46IDAw
MDA1MTI1DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjAxXSAgIGdmbjogMDAwMDUxMjYg
IG1mbjogMDAwMDUxMjYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MDFdICAgZ2ZuOiAw
MDAwNTEyNyAgbWZuOiAwMDAwNTEyNw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzowMV0g
ICBnZm46IDAwMDA1MTI4ICBtZm46IDAwMDA1MTI4DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMzOjAxXSAgIGdmbjogMDAwMDUxMjkgIG1mbjogMDAwMDUxMjkNCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzM6MDFdICAgZ2ZuOiAwMDAwNTEyYSAgbWZuOiAwMDAwNTEyYQ0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMzowMV0gICBnZm46IDAwMDA1MTJiICBtZm46IDAwMDA1MTJi
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjAxXSAgIGdmbjogMDAwMDUxMmMgIG1mbjog
MDAwMDUxMmMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MDFdICAgZ2ZuOiAwMDAwNTEy
ZCAgbWZuOiAwMDAwNTEyZA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzowMl0gICBnZm46
IDAwMDA1MTJlICBtZm46IDAwMDA1MTJlDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjAy
XSAgIGdmbjogMDAwMDUxMmYgIG1mbjogMDAwMDUxMmYNCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzM6MDJdICAgZ2ZuOiAwMDAwNTEzMCAgbWZuOiAwMDAwNTEzMA0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMzowMl0gICBnZm46IDAwMDA1MTMxICBtZm46IDAwMDA1MTMxDQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMzOjAyXSAgIGdmbjogMDAwMDUxMzIgIG1mbjogMDAwMDUx
MzINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MDJdICAgZ2ZuOiAwMDAwNTEzMyAgbWZu
OiAwMDAwNTEzMw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzowMl0gICBnZm46IDAwMDA1
MTM0ICBtZm46IDAwMDA1MTM0DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjAyXSAgIGdm
bjogMDAwMDUxMzUgIG1mbjogMDAwMDUxMzUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6
MDJdICAgZ2ZuOiAwMDAwNTEzNiAgbWZuOiAwMDAwNTEzNg0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMzowMl0gICBnZm46IDAwMDA1MTM3ICBtZm46IDAwMDA1MTM3DQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMzOjAyXSAgIGdmbjogMDAwMDUxMzggIG1mbjogMDAwMDUxMzgNCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MDJdICAgZ2ZuOiAwMDAwNTEzOSAgbWZuOiAwMDAw
NTEzOQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzowMl0gICBnZm46IDAwMDA1MTNhICBt
Zm46IDAwMDA1MTNhDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjAyXSAgIGdmbjogMDAw
MDUxM2IgIG1mbjogMDAwMDUxM2INCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MDJdICAg
Z2ZuOiAwMDAwNTEzYyAgbWZuOiAwMDAwNTEzYw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
MzowMl0gICBnZm46IDAwMDA1MTNkICBtZm46IDAwMDA1MTNkDQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMzOjAyXSAgIGdmbjogMDAwMDUxM2UgIG1mbjogMDAwMDUxM2UNCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzM6MDJdICAgZ2ZuOiAwMDAwNTEzZiAgbWZuOiAwMDAwNTEzZg0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzowMl0gICBnZm46IDAwMDA1MTQwICBtZm46IDAw
MDA1MTQwDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjAyXSAgIGdmbjogMDAwMDUxNDEg
IG1mbjogMDAwMDUxNDENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MDJdICAgZ2ZuOiAw
MDAwNTE0MiAgbWZuOiAwMDAwNTE0Mg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzowMl0g
ICBnZm46IDAwMDA1MTQzICBtZm46IDAwMDA1MTQzDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMzOjAyXSAgIGdmbjogMDAwMDUxNDQgIG1mbjogMDAwMDUxNDQNCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzM6MDJdICAgZ2ZuOiAwMDAwNTE0NSAgbWZuOiAwMDAwNTE0NQ0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMzowMl0gICBnZm46IDAwMDA1MTQ2ICBtZm46IDAwMDA1MTQ2
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjAyXSAgIGdmbjogMDAwMDUxNDcgIG1mbjog
MDAwMDUxNDcNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MDJdICAgZ2ZuOiAwMDAwNTE0
OCAgbWZuOiAwMDAwNTE0OA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzowMl0gICBnZm46
IDAwMDA1MTQ5ICBtZm46IDAwMDA1MTQ5DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjAy
XSAgIGdmbjogMDAwMDUxNGEgIG1mbjogMDAwMDUxNGENCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzM6MDJdICAgZ2ZuOiAwMDAwNTE0YiAgbWZuOiAwMDAwNTE0Yg0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMzowMl0gICBnZm46IDAwMDA1MTRjICBtZm46IDAwMDA1MTRjDQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMzOjAyXSAgIGdmbjogMDAwMDUxNGQgIG1mbjogMDAwMDUx
NGQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MDJdICAgZ2ZuOiAwMDAwNTE0ZSAgbWZu
OiAwMDAwNTE0ZQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzowMl0gICBnZm46IDAwMDA1
MTRmICBtZm46IDAwMDA1MTRmDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjAyXSAgIGdm
bjogMDAwMDUxNTAgIG1mbjogMDAwMDUxNTANCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6
MDJdICAgZ2ZuOiAwMDAwNTE1MSAgbWZuOiAwMDAwNTE1MQ0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMzowMl0gICBnZm46IDAwMDA1MTUyICBtZm46IDAwMDA1MTUyDQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMzOjAyXSAgIGdmbjogMDAwMDUxNTMgIG1mbjogMDAwMDUxNTMNCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MDJdICAgZ2ZuOiAwMDAwNTE1NCAgbWZuOiAwMDAw
NTE1NA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzowMl0gICBnZm46IDAwMDA1MTU1ICBt
Zm46IDAwMDA1MTU1DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjAyXSAgIGdmbjogMDAw
MDUxNTYgIG1mbjogMDAwMDUxNTYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MDJdICAg
Z2ZuOiAwMDAwNTE1NyAgbWZuOiAwMDAwNTE1Nw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
MzowMl0gICBnZm46IDAwMDA1MTU4ICBtZm46IDAwMDA1MTU4DQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMzOjAyXSAgIGdmbjogMDAwMDUxNTkgIG1mbjogMDAwMDUxNTkNCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzM6MDJdICAgZ2ZuOiAwMDAwNTE1YSAgbWZuOiAwMDAwNTE1YQ0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzowMl0gICBnZm46IDAwMDA1MTViICBtZm46IDAw
MDA1MTViDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjAyXSAgIGdmbjogMDAwMDUxNWMg
IG1mbjogMDAwMDUxNWMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MDJdICAgZ2ZuOiAw
MDAwNTE1ZCAgbWZuOiAwMDAwNTE1ZA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzowMl0g
ICBnZm46IDAwMDA1MTVlICBtZm46IDAwMDA1MTVlDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMzOjAyXSAgIGdmbjogMDAwMDUxNWYgIG1mbjogMDAwMDUxNWYNCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzM6MDJdICAgZ2ZuOiAwMDAwNTE2MCAgbWZuOiAwMDAwNTE2MA0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMzowMl0gICBnZm46IDAwMDA1MTYxICBtZm46IDAwMDA1MTYx
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjAyXSAgIGdmbjogMDAwMDUxNjIgIG1mbjog
MDAwMDUxNjINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MDJdICAgZ2ZuOiAwMDAwNTE2
MyAgbWZuOiAwMDAwNTE2Mw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzowMl0gICBnZm46
IDAwMDA1MTY0ICBtZm46IDAwMDA1MTY0DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjAy
XSAgIGdmbjogMDAwMDUxNjUgIG1mbjogMDAwMDUxNjUNCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzM6MDJdICAgZ2ZuOiAwMDAwNTE2NiAgbWZuOiAwMDAwNTE2Ng0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMzowMl0gICBnZm46IDAwMDA1MTY3ICBtZm46IDAwMDA1MTY3DQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMzOjAyXSAgIGdmbjogMDAwMDUxNjggIG1mbjogMDAwMDUx
NjgNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MDJdICAgZ2ZuOiAwMDAwNTE2OSAgbWZu
OiAwMDAwNTE2OQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzowMl0gICBnZm46IDAwMDA1
MTZhICBtZm46IDAwMDA1MTZhDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjAyXSAgIGdm
bjogMDAwMDUxNmIgIG1mbjogMDAwMDUxNmINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6
MDJdICAgZ2ZuOiAwMDAwNTE2YyAgbWZuOiAwMDAwNTE2Yw0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMzowMl0gICBnZm46IDAwMDA1MTZkICBtZm46IDAwMDA1MTZkDQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMzOjAzXSAgIGdmbjogMDAwMDUxNmUgIG1mbjogMDAwMDUxNmUNCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MDNdICAgZ2ZuOiAwMDAwNTE2ZiAgbWZuOiAwMDAw
NTE2Zg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzowM10gICBnZm46IDAwMDA1MTcwICBt
Zm46IDAwMDA1MTcwDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjAzXSAgIGdmbjogMDAw
MDUxNzEgIG1mbjogMDAwMDUxNzENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MDNdICAg
Z2ZuOiAwMDAwNTE3MiAgbWZuOiAwMDAwNTE3Mg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
MzowM10gICBnZm46IDAwMDA1MTczICBtZm46IDAwMDA1MTczDQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMzOjAzXSAgIGdmbjogMDAwMDUxNzQgIG1mbjogMDAwMDUxNzQNCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzM6MDNdICAgZ2ZuOiAwMDAwNTE3NSAgbWZuOiAwMDAwNTE3NQ0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzowM10gICBnZm46IDAwMDA1MTc2ICBtZm46IDAw
MDA1MTc2DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjAzXSAgIGdmbjogMDAwMDUxNzcg
IG1mbjogMDAwMDUxNzcNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MDNdICAgZ2ZuOiAw
MDAwNTE3OCAgbWZuOiAwMDAwNTE3OA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzowM10g
ICBnZm46IDAwMDA1MTc5ICBtZm46IDAwMDA1MTc5DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMzOjAzXSAgIGdmbjogMDAwMDUxN2EgIG1mbjogMDAwMDUxN2ENCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzM6MDNdICAgZ2ZuOiAwMDAwNTE3YiAgbWZuOiAwMDAwNTE3Yg0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMzowM10gICBnZm46IDAwMDA1MTdjICBtZm46IDAwMDA1MTdj
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjAzXSAgIGdmbjogMDAwMDUxN2QgIG1mbjog
MDAwMDUxN2QNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MDNdICAgZ2ZuOiAwMDAwNTE3
ZSAgbWZuOiAwMDAwNTE3ZQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzowM10gICBnZm46
IDAwMDA1MTdmICBtZm46IDAwMDA1MTdmDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjAz
XSAgIGdmbjogMDAwMDUxODAgIG1mbjogMDAwMDUxODANCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzM6MDNdICAgZ2ZuOiAwMDAwNTE4MSAgbWZuOiAwMDAwNTE4MQ0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMzowM10gICBnZm46IDAwMDA1MTgyICBtZm46IDAwMDA1MTgyDQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMzOjAzXSAgIGdmbjogMDAwMDUxODMgIG1mbjogMDAwMDUx
ODMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MDNdICAgZ2ZuOiAwMDAwNTE4NCAgbWZu
OiAwMDAwNTE4NA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzowM10gICBnZm46IDAwMDA1
MTg1ICBtZm46IDAwMDA1MTg1DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjAzXSAgIGdm
bjogMDAwMDUxODYgIG1mbjogMDAwMDUxODYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6
MDNdICAgZ2ZuOiAwMDAwNTE4NyAgbWZuOiAwMDAwNTE4Nw0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMzowM10gICBnZm46IDAwMDA1MTg4ICBtZm46IDAwMDA1MTg4DQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMzOjAzXSAgIGdmbjogMDAwMDUxODkgIG1mbjogMDAwMDUxODkNCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MDNdICAgZ2ZuOiAwMDAwNTE4YSAgbWZuOiAwMDAw
NTE4YQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzowM10gICBnZm46IDAwMDA1MThiICBt
Zm46IDAwMDA1MThiDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjAzXSAgIGdmbjogMDAw
MDUxOGMgIG1mbjogMDAwMDUxOGMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MDNdICAg
Z2ZuOiAwMDAwNTE4ZCAgbWZuOiAwMDAwNTE4ZA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
MzowM10gICBnZm46IDAwMDA1MThlICBtZm46IDAwMDA1MThlDQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMzOjAzXSAgIGdmbjogMDAwMDUxOGYgIG1mbjogMDAwMDUxOGYNCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzM6MDNdICAgZ2ZuOiAwMDAwNTE5MCAgbWZuOiAwMDAwNTE5MA0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzowM10gICBnZm46IDAwMDA1MTkxICBtZm46IDAw
MDA1MTkxDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjAzXSAgIGdmbjogMDAwMDUxOTIg
IG1mbjogMDAwMDUxOTINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MDNdICAgZ2ZuOiAw
MDAwNTE5MyAgbWZuOiAwMDAwNTE5Mw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzowM10g
ICBnZm46IDAwMDA1MTk0ICBtZm46IDAwMDA1MTk0DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMzOjAzXSAgIGdmbjogMDAwMDUxOTUgIG1mbjogMDAwMDUxOTUNCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzM6MDNdICAgZ2ZuOiAwMDAwNTE5NiAgbWZuOiAwMDAwNTE5Ng0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMzowM10gICBnZm46IDAwMDA1MTk3ICBtZm46IDAwMDA1MTk3
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjAzXSAgIGdmbjogMDAwMDUxOTggIG1mbjog
MDAwMDUxOTgNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MDNdICAgZ2ZuOiAwMDAwNTE5
OSAgbWZuOiAwMDAwNTE5OQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzowM10gICBnZm46
IDAwMDA1MTlhICBtZm46IDAwMDA1MTlhDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjAz
XSAgIGdmbjogMDAwMDUxOWIgIG1mbjogMDAwMDUxOWINCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzM6MDNdICAgZ2ZuOiAwMDAwNTE5YyAgbWZuOiAwMDAwNTE5Yw0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMzowM10gICBnZm46IDAwMDA1MTlkICBtZm46IDAwMDA1MTlkDQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMzOjAzXSAgIGdmbjogMDAwMDUxOWUgIG1mbjogMDAwMDUx
OWUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MDNdICAgZ2ZuOiAwMDAwNTE5ZiAgbWZu
OiAwMDAwNTE5Zg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzowM10gICBnZm46IDAwMDA1
MWEwICBtZm46IDAwMDA1MWEwDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjAzXSAgIGdm
bjogMDAwMDUxYTEgIG1mbjogMDAwMDUxYTENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6
MDNdICAgZ2ZuOiAwMDAwNTFhMiAgbWZuOiAwMDAwNTFhMg0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMzowM10gICBnZm46IDAwMDA1MWEzICBtZm46IDAwMDA1MWEzDQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMzOjAzXSAgIGdmbjogMDAwMDUxYTQgIG1mbjogMDAwMDUxYTQNCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MDNdICAgZ2ZuOiAwMDAwNTFhNSAgbWZuOiAwMDAw
NTFhNQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzowM10gICBnZm46IDAwMDA1MWE2ICBt
Zm46IDAwMDA1MWE2DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjAzXSAgIGdmbjogMDAw
MDUxYTcgIG1mbjogMDAwMDUxYTcNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MDNdICAg
Z2ZuOiAwMDAwNTFhOCAgbWZuOiAwMDAwNTFhOA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
MzowM10gICBnZm46IDAwMDA1MWE5ICBtZm46IDAwMDA1MWE5DQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMzOjAzXSAgIGdmbjogMDAwMDUxYWEgIG1mbjogMDAwMDUxYWENCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzM6MDNdICAgZ2ZuOiAwMDAwNTFhYiAgbWZuOiAwMDAwNTFhYg0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzowM10gICBnZm46IDAwMDA1MWFjICBtZm46IDAw
MDA1MWFjDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjAzXSAgIGdmbjogMDAwMDUxYWQg
IG1mbjogMDAwMDUxYWQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MDRdICAgZ2ZuOiAw
MDAwNTFhZSAgbWZuOiAwMDAwNTFhZQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzowNF0g
ICBnZm46IDAwMDA1MWFmICBtZm46IDAwMDA1MWFmDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMzOjA0XSAgIGdmbjogMDAwMDUxYjAgIG1mbjogMDAwMDUxYjANCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzM6MDRdICAgZ2ZuOiAwMDAwNTFiMSAgbWZuOiAwMDAwNTFiMQ0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMzowNF0gICBnZm46IDAwMDA1MWIyICBtZm46IDAwMDA1MWIy
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjA0XSAgIGdmbjogMDAwMDUxYjMgIG1mbjog
MDAwMDUxYjMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MDRdICAgZ2ZuOiAwMDAwNTFi
NCAgbWZuOiAwMDAwNTFiNA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzowNF0gICBnZm46
IDAwMDA1MWI1ICBtZm46IDAwMDA1MWI1DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjA0
XSAgIGdmbjogMDAwMDUxYjYgIG1mbjogMDAwMDUxYjYNCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzM6MDRdICAgZ2ZuOiAwMDAwNTFiNyAgbWZuOiAwMDAwNTFiNw0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMzowNF0gICBnZm46IDAwMDA1MWI4ICBtZm46IDAwMDA1MWI4DQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMzOjA0XSAgIGdmbjogMDAwMDUxYjkgIG1mbjogMDAwMDUx
YjkNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MDRdICAgZ2ZuOiAwMDAwNTFiYSAgbWZu
OiAwMDAwNTFiYQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzowNF0gICBnZm46IDAwMDA1
MWJiICBtZm46IDAwMDA1MWJiDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjA0XSAgIGdm
bjogMDAwMDUxYmMgIG1mbjogMDAwMDUxYmMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6
MDRdICAgZ2ZuOiAwMDAwNTFiZCAgbWZuOiAwMDAwNTFiZA0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMzowNF0gICBnZm46IDAwMDA1MWJlICBtZm46IDAwMDA1MWJlDQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMzOjA0XSAgIGdmbjogMDAwMDUxYmYgIG1mbjogMDAwMDUxYmYNCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MDRdICAgZ2ZuOiAwMDAwNTFjMCAgbWZuOiAwMDAw
NTFjMA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzowNF0gICBnZm46IDAwMDA1MWMxICBt
Zm46IDAwMDA1MWMxDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjA0XSAgIGdmbjogMDAw
MDUxYzIgIG1mbjogMDAwMDUxYzINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MDRdICAg
Z2ZuOiAwMDAwNTFjMyAgbWZuOiAwMDAwNTFjMw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
MzowNF0gICBnZm46IDAwMDA1MWM0ICBtZm46IDAwMDA1MWM0DQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMzOjA0XSAgIGdmbjogMDAwMDUxYzUgIG1mbjogMDAwMDUxYzUNCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzM6MDRdICAgZ2ZuOiAwMDAwNTFjNiAgbWZuOiAwMDAwNTFjNg0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzowNF0gICBnZm46IDAwMDA1MWM3ICBtZm46IDAw
MDA1MWM3DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjA0XSAgIGdmbjogMDAwMDUxYzgg
IG1mbjogMDAwMDUxYzgNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MDRdICAgZ2ZuOiAw
MDAwNTFjOSAgbWZuOiAwMDAwNTFjOQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzowNF0g
ICBnZm46IDAwMDA1MWNhICBtZm46IDAwMDA1MWNhDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMzOjA0XSAgIGdmbjogMDAwMDUxY2IgIG1mbjogMDAwMDUxY2INCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzM6MDRdICAgZ2ZuOiAwMDAwNTFjYyAgbWZuOiAwMDAwNTFjYw0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMzowNF0gICBnZm46IDAwMDA1MWNkICBtZm46IDAwMDA1MWNk
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjA0XSAgIGdmbjogMDAwMDUxY2UgIG1mbjog
MDAwMDUxY2UNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MDRdICAgZ2ZuOiAwMDAwNTFj
ZiAgbWZuOiAwMDAwNTFjZg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzowNF0gICBnZm46
IDAwMDA1MWQwICBtZm46IDAwMDA1MWQwDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjA0
XSAgIGdmbjogMDAwMDUxZDEgIG1mbjogMDAwMDUxZDENCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzM6MDRdICAgZ2ZuOiAwMDAwNTFkMiAgbWZuOiAwMDAwNTFkMg0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMzowNF0gICBnZm46IDAwMDA1MWQzICBtZm46IDAwMDA1MWQzDQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMzOjA0XSAgIGdmbjogMDAwMDUxZDQgIG1mbjogMDAwMDUx
ZDQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MDRdICAgZ2ZuOiAwMDAwNTFkNSAgbWZu
OiAwMDAwNTFkNQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzowNF0gICBnZm46IDAwMDA1
MWQ2ICBtZm46IDAwMDA1MWQ2DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjA0XSAgIGdm
bjogMDAwMDUxZDcgIG1mbjogMDAwMDUxZDcNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6
MDRdICAgZ2ZuOiAwMDAwNTFkOCAgbWZuOiAwMDAwNTFkOA0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMzowNF0gICBnZm46IDAwMDA1MWQ5ICBtZm46IDAwMDA1MWQ5DQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMzOjA0XSAgIGdmbjogMDAwMDUxZGEgIG1mbjogMDAwMDUxZGENCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MDRdICAgZ2ZuOiAwMDAwNTFkYiAgbWZuOiAwMDAw
NTFkYg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzowNF0gICBnZm46IDAwMDA1MWRjICBt
Zm46IDAwMDA1MWRjDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjA0XSAgIGdmbjogMDAw
MDUxZGQgIG1mbjogMDAwMDUxZGQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MDRdICAg
Z2ZuOiAwMDAwNTFkZSAgbWZuOiAwMDAwNTFkZQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
MzowNF0gICBnZm46IDAwMDA1MWRmICBtZm46IDAwMDA1MWRmDQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMzOjA0XSAgIGdmbjogMDAwMDUxZTAgIG1mbjogMDAwMDUxZTANCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzM6MDRdICAgZ2ZuOiAwMDAwNTFlMSAgbWZuOiAwMDAwNTFlMQ0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzowNF0gICBnZm46IDAwMDA1MWUyICBtZm46IDAw
MDA1MWUyDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjA0XSAgIGdmbjogMDAwMDUxZTMg
IG1mbjogMDAwMDUxZTMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MDRdICAgZ2ZuOiAw
MDAwNTFlNCAgbWZuOiAwMDAwNTFlNA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzowNF0g
ICBnZm46IDAwMDA1MWU1ICBtZm46IDAwMDA1MWU1DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMzOjA0XSAgIGdmbjogMDAwMDUxZTYgIG1mbjogMDAwMDUxZTYNCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzM6MDRdICAgZ2ZuOiAwMDAwNTFlNyAgbWZuOiAwMDAwNTFlNw0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMzowNF0gICBnZm46IDAwMDA1MWU4ICBtZm46IDAwMDA1MWU4
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjA0XSAgIGdmbjogMDAwMDUxZTkgIG1mbjog
MDAwMDUxZTkNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MDRdICAgZ2ZuOiAwMDAwNTFl
YSAgbWZuOiAwMDAwNTFlYQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzowNF0gICBnZm46
IDAwMDA1MWViICBtZm46IDAwMDA1MWViDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjA0
XSAgIGdmbjogMDAwMDUxZWMgIG1mbjogMDAwMDUxZWMNCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzM6MDRdICAgZ2ZuOiAwMDAwNTFlZCAgbWZuOiAwMDAwNTFlZA0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMzowNV0gICBnZm46IDAwMDA1MWVlICBtZm46IDAwMDA1MWVlDQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMzOjA1XSAgIGdmbjogMDAwMDUxZWYgIG1mbjogMDAwMDUx
ZWYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MDVdICAgZ2ZuOiAwMDAwNTFmMCAgbWZu
OiAwMDAwNTFmMA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzowNV0gICBnZm46IDAwMDA1
MWYxICBtZm46IDAwMDA1MWYxDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjA1XSAgIGdm
bjogMDAwMDUxZjIgIG1mbjogMDAwMDUxZjINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6
MDVdICAgZ2ZuOiAwMDAwNTFmMyAgbWZuOiAwMDAwNTFmMw0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMzowNV0gICBnZm46IDAwMDA1MWY0ICBtZm46IDAwMDA1MWY0DQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMzOjA1XSAgIGdmbjogMDAwMDUxZjUgIG1mbjogMDAwMDUxZjUNCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MDVdICAgZ2ZuOiAwMDAwNTFmNiAgbWZuOiAwMDAw
NTFmNg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzowNV0gICBnZm46IDAwMDA1MWY3ICBt
Zm46IDAwMDA1MWY3DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjA1XSAgIGdmbjogMDAw
MDUxZjggIG1mbjogMDAwMDUxZjgNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MDVdICAg
Z2ZuOiAwMDAwNTFmOSAgbWZuOiAwMDAwNTFmOQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
MzowNV0gICBnZm46IDAwMDA1MWZhICBtZm46IDAwMDA1MWZhDQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMzOjA1XSAgIGdmbjogMDAwMDUxZmIgIG1mbjogMDAwMDUxZmINCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzM6MDVdICAgZ2ZuOiAwMDAwNTFmYyAgbWZuOiAwMDAwNTFmYw0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzowNV0gICBnZm46IDAwMDA1MWZkICBtZm46IDAw
MDA1MWZkDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjA1XSAgIGdmbjogMDAwMDUxZmUg
IG1mbjogMDAwMDUxZmUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MDVdICAgZ2ZuOiAw
MDAwNTFmZiAgbWZuOiAwMDAwNTFmZg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzowNV0g
ICBnZm46IDAwMDA1MjAwICBtZm46IDAwMDA1MjAwDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMzOjA1XSAgIGdmbjogMDAwMDUyMDEgIG1mbjogMDAwMDUyMDENCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzM6MDVdICAgZ2ZuOiAwMDAwNTIwMiAgbWZuOiAwMDAwNTIwMg0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMzowNV0gICBnZm46IDAwMDA1MjAzICBtZm46IDAwMDA1MjAz
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjA1XSAgIGdmbjogMDAwMDUyMDQgIG1mbjog
MDAwMDUyMDQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MDVdICAgZ2ZuOiAwMDAwNTIw
NSAgbWZuOiAwMDAwNTIwNQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzowNV0gICBnZm46
IDAwMDA1MjA2ICBtZm46IDAwMDA1MjA2DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjA1
XSAgIGdmbjogMDAwMDUyMDcgIG1mbjogMDAwMDUyMDcNCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzM6MDVdICAgZ2ZuOiAwMDAwNTIwOCAgbWZuOiAwMDAwNTIwOA0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMzowNV0gICBnZm46IDAwMDA1MjA5ICBtZm46IDAwMDA1MjA5DQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMzOjA1XSAgIGdmbjogMDAwMDUyMGEgIG1mbjogMDAwMDUy
MGENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MDVdICAgZ2ZuOiAwMDAwNTIwYiAgbWZu
OiAwMDAwNTIwYg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzowNV0gICBnZm46IDAwMDA1
MjBjICBtZm46IDAwMDA1MjBjDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjA1XSAgIGdm
bjogMDAwMDUyMGQgIG1mbjogMDAwMDUyMGQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6
MDVdICAgZ2ZuOiAwMDAwNTIwZSAgbWZuOiAwMDAwNTIwZQ0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMzowNV0gICBnZm46IDAwMDA1MjBmICBtZm46IDAwMDA1MjBmDQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMzOjA1XSAgIGdmbjogMDAwMDUyMTAgIG1mbjogMDAwMDUyMTANCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MDVdICAgZ2ZuOiAwMDAwNTIxMSAgbWZuOiAwMDAw
NTIxMQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzowNV0gICBnZm46IDAwMDA1MjEyICBt
Zm46IDAwMDA1MjEyDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjA1XSAgIGdmbjogMDAw
MDUyMTMgIG1mbjogMDAwMDUyMTMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MDVdICAg
Z2ZuOiAwMDAwNTIxNCAgbWZuOiAwMDAwNTIxNA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
MzowNV0gICBnZm46IDAwMDA1MjE1ICBtZm46IDAwMDA1MjE1DQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMzOjA1XSAgIGdmbjogMDAwMDUyMTYgIG1mbjogMDAwMDUyMTYNCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzM6MDVdICAgZ2ZuOiAwMDAwNTIxNyAgbWZuOiAwMDAwNTIxNw0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzowNV0gICBnZm46IDAwMDA1MjE4ICBtZm46IDAw
MDA1MjE4DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjA1XSAgIGdmbjogMDAwMDUyMTkg
IG1mbjogMDAwMDUyMTkNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MDVdICAgZ2ZuOiAw
MDAwNTIxYSAgbWZuOiAwMDAwNTIxYQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzowNV0g
ICBnZm46IDAwMDA1MjFiICBtZm46IDAwMDA1MjFiDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMzOjA1XSAgIGdmbjogMDAwMDUyMWMgIG1mbjogMDAwMDUyMWMNCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzM6MDVdICAgZ2ZuOiAwMDAwNTIxZCAgbWZuOiAwMDAwNTIxZA0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMzowNV0gICBnZm46IDAwMDA1MjFlICBtZm46IDAwMDA1MjFl
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjA1XSAgIGdmbjogMDAwMDUyMWYgIG1mbjog
MDAwMDUyMWYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MDVdICAgZ2ZuOiAwMDAwNTIy
MCAgbWZuOiAwMDAwNTIyMA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzowNV0gICBnZm46
IDAwMDA1MjIxICBtZm46IDAwMDA1MjIxDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjA1
XSAgIGdmbjogMDAwMDUyMjIgIG1mbjogMDAwMDUyMjINCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzM6MDVdICAgZ2ZuOiAwMDAwNTIyMyAgbWZuOiAwMDAwNTIyMw0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMzowNV0gICBnZm46IDAwMDA1MjI0ICBtZm46IDAwMDA1MjI0DQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMzOjA1XSAgIGdmbjogMDAwMDUyMjUgIG1mbjogMDAwMDUy
MjUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MDVdICAgZ2ZuOiAwMDAwNTIyNiAgbWZu
OiAwMDAwNTIyNg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzowNV0gICBnZm46IDAwMDA1
MjI3ICBtZm46IDAwMDA1MjI3DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjA1XSAgIGdm
bjogMDAwMDUyMjggIG1mbjogMDAwMDUyMjgNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6
MDVdICAgZ2ZuOiAwMDAwNTIyOSAgbWZuOiAwMDAwNTIyOQ0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMzowNV0gICBnZm46IDAwMDA1MjJhICBtZm46IDAwMDA1MjJhDQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMzOjA1XSAgIGdmbjogMDAwMDUyMmIgIG1mbjogMDAwMDUyMmINCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MDVdICAgZ2ZuOiAwMDAwNTIyYyAgbWZuOiAwMDAw
NTIyYw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzowNV0gICBnZm46IDAwMDA1MjJkICBt
Zm46IDAwMDA1MjJkDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjA1XSAgIGdmbjogMDAw
MDUyMmUgIG1mbjogMDAwMDUyMmUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MDZdICAg
Z2ZuOiAwMDAwNTIyZiAgbWZuOiAwMDAwNTIyZg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
MzowNl0gICBnZm46IDAwMDA1MjMwICBtZm46IDAwMDA1MjMwDQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMzOjA2XSAgIGdmbjogMDAwMDUyMzEgIG1mbjogMDAwMDUyMzENCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzM6MDZdICAgZ2ZuOiAwMDAwNTIzMiAgbWZuOiAwMDAwNTIzMg0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzowNl0gICBnZm46IDAwMDA1MjMzICBtZm46IDAw
MDA1MjMzDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjA2XSAgIGdmbjogMDAwMDUyMzQg
IG1mbjogMDAwMDUyMzQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MDZdICAgZ2ZuOiAw
MDAwNTIzNSAgbWZuOiAwMDAwNTIzNQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzowNl0g
ICBnZm46IDAwMDA1MjM2ICBtZm46IDAwMDA1MjM2DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMzOjA2XSAgIGdmbjogMDAwMDUyMzcgIG1mbjogMDAwMDUyMzcNCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzM6MDZdICAgZ2ZuOiAwMDAwNTIzOCAgbWZuOiAwMDAwNTIzOA0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMzowNl0gICBnZm46IDAwMDA1MjM5ICBtZm46IDAwMDA1MjM5
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjA2XSAgIGdmbjogMDAwMDUyM2EgIG1mbjog
MDAwMDUyM2ENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MDZdICAgZ2ZuOiAwMDAwNTIz
YiAgbWZuOiAwMDAwNTIzYg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzowNl0gICBnZm46
IDAwMDA1MjNjICBtZm46IDAwMDA1MjNjDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjA2
XSAgIGdmbjogMDAwMDUyM2QgIG1mbjogMDAwMDUyM2QNCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzM6MDZdICAgZ2ZuOiAwMDAwNTIzZSAgbWZuOiAwMDAwNTIzZQ0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMzowNl0gICBnZm46IDAwMDA1MjNmICBtZm46IDAwMDA1MjNmDQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMzOjA2XSAgIGdmbjogMDAwMDUyNDAgIG1mbjogMDAwMDUy
NDANCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MDZdICAgZ2ZuOiAwMDAwNTI0MSAgbWZu
OiAwMDAwNTI0MQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzowNl0gICBnZm46IDAwMDA1
MjQyICBtZm46IDAwMDA1MjQyDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjA2XSAgIGdm
bjogMDAwMDUyNDMgIG1mbjogMDAwMDUyNDMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6
MDZdICAgZ2ZuOiAwMDAwNTI0NCAgbWZuOiAwMDAwNTI0NA0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMzowNl0gICBnZm46IDAwMDA1MjQ1ICBtZm46IDAwMDA1MjQ1DQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMzOjA2XSAgIGdmbjogMDAwMDUyNDYgIG1mbjogMDAwMDUyNDYNCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MDZdICAgZ2ZuOiAwMDAwNTI0NyAgbWZuOiAwMDAw
NTI0Nw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzowNl0gICBnZm46IDAwMDA1MjQ4ICBt
Zm46IDAwMDA1MjQ4DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjA2XSAgIGdmbjogMDAw
MDUyNDkgIG1mbjogMDAwMDUyNDkNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MDZdICAg
Z2ZuOiAwMDAwNTI0YSAgbWZuOiAwMDAwNTI0YQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
MzowNl0gICBnZm46IDAwMDA1MjRiICBtZm46IDAwMDA1MjRiDQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMzOjA2XSAgIGdmbjogMDAwMDUyNGMgIG1mbjogMDAwMDUyNGMNCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzM6MDZdICAgZ2ZuOiAwMDAwNTI0ZCAgbWZuOiAwMDAwNTI0ZA0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzowNl0gICBnZm46IDAwMDA1MjRlICBtZm46IDAw
MDA1MjRlDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjA2XSAgIGdmbjogMDAwMDUyNGYg
IG1mbjogMDAwMDUyNGYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MDZdICAgZ2ZuOiAw
MDAwNTI1MCAgbWZuOiAwMDAwNTI1MA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzowNl0g
ICBnZm46IDAwMDA1MjUxICBtZm46IDAwMDA1MjUxDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMzOjA2XSAgIGdmbjogMDAwMDUyNTIgIG1mbjogMDAwMDUyNTINCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzM6MDZdICAgZ2ZuOiAwMDAwNTI1MyAgbWZuOiAwMDAwNTI1Mw0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMzowNl0gICBnZm46IDAwMDA1MjU0ICBtZm46IDAwMDA1MjU0
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjA2XSAgIGdmbjogMDAwMDUyNTUgIG1mbjog
MDAwMDUyNTUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MDZdICAgZ2ZuOiAwMDAwNTI1
NiAgbWZuOiAwMDAwNTI1Ng0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzowNl0gICBnZm46
IDAwMDA1MjU3ICBtZm46IDAwMDA1MjU3DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjA2
XSAgIGdmbjogMDAwMDUyNTggIG1mbjogMDAwMDUyNTgNCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzM6MDZdICAgZ2ZuOiAwMDAwNTI1OSAgbWZuOiAwMDAwNTI1OQ0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMzowNl0gICBnZm46IDAwMDA1MjVhICBtZm46IDAwMDA1MjVhDQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMzOjA2XSAgIGdmbjogMDAwMDUyNWIgIG1mbjogMDAwMDUy
NWINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MDZdICAgZ2ZuOiAwMDAwNTI1YyAgbWZu
OiAwMDAwNTI1Yw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzowNl0gICBnZm46IDAwMDA1
MjVkICBtZm46IDAwMDA1MjVkDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjA2XSAgIGdm
bjogMDAwMDUyNWUgIG1mbjogMDAwMDUyNWUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6
MDZdICAgZ2ZuOiAwMDAwNTI1ZiAgbWZuOiAwMDAwNTI1Zg0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMzowNl0gICBnZm46IDAwMDA1MjYwICBtZm46IDAwMDA1MjYwDQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMzOjA2XSAgIGdmbjogMDAwMDUyNjEgIG1mbjogMDAwMDUyNjENCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MDZdICAgZ2ZuOiAwMDAwNTI2MiAgbWZuOiAwMDAw
NTI2Mg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzowNl0gICBnZm46IDAwMDA1MjYzICBt
Zm46IDAwMDA1MjYzDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjA2XSAgIGdmbjogMDAw
MDUyNjQgIG1mbjogMDAwMDUyNjQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MDZdICAg
Z2ZuOiAwMDAwNTI2NSAgbWZuOiAwMDAwNTI2NQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
MzowNl0gICBnZm46IDAwMDA1MjY2ICBtZm46IDAwMDA1MjY2DQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMzOjA2XSAgIGdmbjogMDAwMDUyNjcgIG1mbjogMDAwMDUyNjcNCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzM6MDZdICAgZ2ZuOiAwMDAwNTI2OCAgbWZuOiAwMDAwNTI2OA0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzowNl0gICBnZm46IDAwMDA1MjY5ICBtZm46IDAw
MDA1MjY5DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjA2XSAgIGdmbjogMDAwMDUyNmEg
IG1mbjogMDAwMDUyNmENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MDZdICAgZ2ZuOiAw
MDAwNTI2YiAgbWZuOiAwMDAwNTI2Yg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzowNl0g
ICBnZm46IDAwMDA1MjZjICBtZm46IDAwMDA1MjZjDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMzOjA2XSAgIGdmbjogMDAwMDUyNmQgIG1mbjogMDAwMDUyNmQNCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzM6MDZdICAgZ2ZuOiAwMDAwNTI2ZSAgbWZuOiAwMDAwNTI2ZQ0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMzowN10gICBnZm46IDAwMDA1MjZmICBtZm46IDAwMDA1MjZm
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjA3XSAgIGdmbjogMDAwMDUyNzAgIG1mbjog
MDAwMDUyNzANCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MDddICAgZ2ZuOiAwMDAwNTI3
MSAgbWZuOiAwMDAwNTI3MQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzowN10gICBnZm46
IDAwMDA1MjcyICBtZm46IDAwMDA1MjcyDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjA3
XSAgIGdmbjogMDAwMDUyNzMgIG1mbjogMDAwMDUyNzMNCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzM6MDddICAgZ2ZuOiAwMDAwNTI3NCAgbWZuOiAwMDAwNTI3NA0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMzowN10gICBnZm46IDAwMDA1Mjc1ICBtZm46IDAwMDA1Mjc1DQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMzOjA3XSAgIGdmbjogMDAwMDUyNzYgIG1mbjogMDAwMDUy
NzYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MDddICAgZ2ZuOiAwMDAwNTI3NyAgbWZu
OiAwMDAwNTI3Nw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzowN10gICBnZm46IDAwMDA1
Mjc4ICBtZm46IDAwMDA1Mjc4DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjA3XSAgIGdm
bjogMDAwMDUyNzkgIG1mbjogMDAwMDUyNzkNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6
MDddICAgZ2ZuOiAwMDAwNTI3YSAgbWZuOiAwMDAwNTI3YQ0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMzowN10gICBnZm46IDAwMDA1MjdiICBtZm46IDAwMDA1MjdiDQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMzOjA3XSAgIGdmbjogMDAwMDUyN2MgIG1mbjogMDAwMDUyN2MNCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MDddICAgZ2ZuOiAwMDAwNTI3ZCAgbWZuOiAwMDAw
NTI3ZA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzowN10gICBnZm46IDAwMDA1MjdlICBt
Zm46IDAwMDA1MjdlDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjA3XSAgIGdmbjogMDAw
MDUyN2YgIG1mbjogMDAwMDUyN2YNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MDddICAg
Z2ZuOiAwMDAwNTI4MCAgbWZuOiAwMDAwNTI4MA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
MzowN10gICBnZm46IDAwMDA1MjgxICBtZm46IDAwMDA1MjgxDQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMzOjA3XSAgIGdmbjogMDAwMDUyODIgIG1mbjogMDAwMDUyODINCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzM6MDddICAgZ2ZuOiAwMDAwNTI4MyAgbWZuOiAwMDAwNTI4Mw0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzowN10gICBnZm46IDAwMDA1Mjg0ICBtZm46IDAw
MDA1Mjg0DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjA3XSAgIGdmbjogMDAwMDUyODUg
IG1mbjogMDAwMDUyODUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MDddICAgZ2ZuOiAw
MDAwNTI4NiAgbWZuOiAwMDAwNTI4Ng0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzowN10g
ICBnZm46IDAwMDA1Mjg3ICBtZm46IDAwMDA1Mjg3DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMzOjA3XSAgIGdmbjogMDAwMDUyODggIG1mbjogMDAwMDUyODgNCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzM6MDddICAgZ2ZuOiAwMDAwNTI4OSAgbWZuOiAwMDAwNTI4OQ0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMzowN10gICBnZm46IDAwMDA1MjhhICBtZm46IDAwMDA1Mjhh
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjA3XSAgIGdmbjogMDAwMDUyOGIgIG1mbjog
MDAwMDUyOGINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MDddICAgZ2ZuOiAwMDAwNTI4
YyAgbWZuOiAwMDAwNTI4Yw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzowN10gICBnZm46
IDAwMDA1MjhkICBtZm46IDAwMDA1MjhkDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjA3
XSAgIGdmbjogMDAwMDUyOGUgIG1mbjogMDAwMDUyOGUNCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzM6MDddICAgZ2ZuOiAwMDAwNTI4ZiAgbWZuOiAwMDAwNTI4Zg0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMzowN10gICBnZm46IDAwMDA1MjkwICBtZm46IDAwMDA1MjkwDQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMzOjA3XSAgIGdmbjogMDAwMDUyOTEgIG1mbjogMDAwMDUy
OTENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MDddICAgZ2ZuOiAwMDAwNTI5MiAgbWZu
OiAwMDAwNTI5Mg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzowN10gICBnZm46IDAwMDA1
MjkzICBtZm46IDAwMDA1MjkzDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjA3XSAgIGdm
bjogMDAwMDUyOTQgIG1mbjogMDAwMDUyOTQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6
MDddICAgZ2ZuOiAwMDAwNTI5NSAgbWZuOiAwMDAwNTI5NQ0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMzowN10gICBnZm46IDAwMDA1Mjk2ICBtZm46IDAwMDA1Mjk2DQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMzOjA3XSAgIGdmbjogMDAwMDUyOTcgIG1mbjogMDAwMDUyOTcNCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MDddICAgZ2ZuOiAwMDAwNTI5OCAgbWZuOiAwMDAw
NTI5OA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzowN10gICBnZm46IDAwMDA1Mjk5ICBt
Zm46IDAwMDA1Mjk5DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjA3XSAgIGdmbjogMDAw
MDUyOWEgIG1mbjogMDAwMDUyOWENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MDddICAg
Z2ZuOiAwMDAwNTI5YiAgbWZuOiAwMDAwNTI5Yg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
MzowN10gICBnZm46IDAwMDA1MjljICBtZm46IDAwMDA1MjljDQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMzOjA3XSAgIGdmbjogMDAwMDUyOWQgIG1mbjogMDAwMDUyOWQNCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzM6MDddICAgZ2ZuOiAwMDAwNTI5ZSAgbWZuOiAwMDAwNTI5ZQ0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzowN10gICBnZm46IDAwMDA1MjlmICBtZm46IDAw
MDA1MjlmDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjA3XSAgIGdmbjogMDAwMDUyYTAg
IG1mbjogMDAwMDUyYTANCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MDddICAgZ2ZuOiAw
MDAwNTJhMSAgbWZuOiAwMDAwNTJhMQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzowN10g
ICBnZm46IDAwMDA1MmEyICBtZm46IDAwMDA1MmEyDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMzOjA3XSAgIGdmbjogMDAwMDUyYTMgIG1mbjogMDAwMDUyYTMNCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzM6MDddICAgZ2ZuOiAwMDAwNTJhNCAgbWZuOiAwMDAwNTJhNA0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMzowN10gICBnZm46IDAwMDA1MmE1ICBtZm46IDAwMDA1MmE1
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjA3XSAgIGdmbjogMDAwMDUyYTYgIG1mbjog
MDAwMDUyYTYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MDddICAgZ2ZuOiAwMDAwNTJh
NyAgbWZuOiAwMDAwNTJhNw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzowN10gICBnZm46
IDAwMDA1MmE4ICBtZm46IDAwMDA1MmE4DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjA3
XSAgIGdmbjogMDAwMDUyYTkgIG1mbjogMDAwMDUyYTkNCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzM6MDddICAgZ2ZuOiAwMDAwNTJhYSAgbWZuOiAwMDAwNTJhYQ0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMzowN10gICBnZm46IDAwMDA1MmFiICBtZm46IDAwMDA1MmFiDQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMzOjA3XSAgIGdmbjogMDAwMDUyYWMgIG1mbjogMDAwMDUy
YWMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MDddICAgZ2ZuOiAwMDAwNTJhZCAgbWZu
OiAwMDAwNTJhZA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzowN10gICBnZm46IDAwMDA1
MmFlICBtZm46IDAwMDA1MmFlDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjA4XSAgIGdm
bjogMDAwMDUyYWYgIG1mbjogMDAwMDUyYWYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6
MDhdICAgZ2ZuOiAwMDAwNTJiMCAgbWZuOiAwMDAwNTJiMA0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMzowOF0gICBnZm46IDAwMDA1MmIxICBtZm46IDAwMDA1MmIxDQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMzOjA4XSAgIGdmbjogMDAwMDUyYjIgIG1mbjogMDAwMDUyYjINCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MDhdICAgZ2ZuOiAwMDAwNTJiMyAgbWZuOiAwMDAw
NTJiMw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzowOF0gICBnZm46IDAwMDA1MmI0ICBt
Zm46IDAwMDA1MmI0DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjA4XSAgIGdmbjogMDAw
MDUyYjUgIG1mbjogMDAwMDUyYjUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MDhdICAg
Z2ZuOiAwMDAwNTJiNiAgbWZuOiAwMDAwNTJiNg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
MzowOF0gICBnZm46IDAwMDA1MmI3ICBtZm46IDAwMDA1MmI3DQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMzOjA4XSAgIGdmbjogMDAwMDUyYjggIG1mbjogMDAwMDUyYjgNCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzM6MDhdICAgZ2ZuOiAwMDAwNTJiOSAgbWZuOiAwMDAwNTJiOQ0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzowOF0gICBnZm46IDAwMDA1MmJhICBtZm46IDAw
MDA1MmJhDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjA4XSAgIGdmbjogMDAwMDUyYmIg
IG1mbjogMDAwMDUyYmINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MDhdICAgZ2ZuOiAw
MDAwNTJiYyAgbWZuOiAwMDAwNTJiYw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzowOF0g
ICBnZm46IDAwMDA1MmJkICBtZm46IDAwMDA1MmJkDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMzOjA4XSAgIGdmbjogMDAwMDUyYmUgIG1mbjogMDAwMDUyYmUNCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzM6MDhdICAgZ2ZuOiAwMDAwNTJiZiAgbWZuOiAwMDAwNTJiZg0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMzowOF0gICBnZm46IDAwMDA1MmMwICBtZm46IDAwMDA1MmMw
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjA4XSAgIGdmbjogMDAwMDUyYzEgIG1mbjog
MDAwMDUyYzENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MDhdICAgZ2ZuOiAwMDAwNTJj
MiAgbWZuOiAwMDAwNTJjMg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzowOF0gICBnZm46
IDAwMDA1MmMzICBtZm46IDAwMDA1MmMzDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjA4
XSAgIGdmbjogMDAwMDUyYzQgIG1mbjogMDAwMDUyYzQNCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzM6MDhdICAgZ2ZuOiAwMDAwNTJjNSAgbWZuOiAwMDAwNTJjNQ0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMzowOF0gICBnZm46IDAwMDA1MmM2ICBtZm46IDAwMDA1MmM2DQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMzOjA4XSAgIGdmbjogMDAwMDUyYzcgIG1mbjogMDAwMDUy
YzcNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MDhdICAgZ2ZuOiAwMDAwNTJjOCAgbWZu
OiAwMDAwNTJjOA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzowOF0gICBnZm46IDAwMDA1
MmM5ICBtZm46IDAwMDA1MmM5DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjA4XSAgIGdm
bjogMDAwMDUyY2EgIG1mbjogMDAwMDUyY2ENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6
MDhdICAgZ2ZuOiAwMDAwNTJjYiAgbWZuOiAwMDAwNTJjYg0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMzowOF0gICBnZm46IDAwMDA1MmNjICBtZm46IDAwMDA1MmNjDQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMzOjA4XSAgIGdmbjogMDAwMDUyY2QgIG1mbjogMDAwMDUyY2QNCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MDhdICAgZ2ZuOiAwMDAwNTJjZSAgbWZuOiAwMDAw
NTJjZQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzowOF0gICBnZm46IDAwMDA1MmNmICBt
Zm46IDAwMDA1MmNmDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjA4XSAgIGdmbjogMDAw
MDUyZDAgIG1mbjogMDAwMDUyZDANCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MDhdICAg
Z2ZuOiAwMDAwNTJkMSAgbWZuOiAwMDAwNTJkMQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
MzowOF0gICBnZm46IDAwMDA1MmQyICBtZm46IDAwMDA1MmQyDQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMzOjA4XSAgIGdmbjogMDAwMDUyZDMgIG1mbjogMDAwMDUyZDMNCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzM6MDhdICAgZ2ZuOiAwMDAwNTJkNCAgbWZuOiAwMDAwNTJkNA0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzowOF0gICBnZm46IDAwMDA1MmQ1ICBtZm46IDAw
MDA1MmQ1DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjA4XSAgIGdmbjogMDAwMDUyZDYg
IG1mbjogMDAwMDUyZDYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MDhdICAgZ2ZuOiAw
MDAwNTJkNyAgbWZuOiAwMDAwNTJkNw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzowOF0g
ICBnZm46IDAwMDA1MmQ4ICBtZm46IDAwMDA1MmQ4DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMzOjA4XSAgIGdmbjogMDAwMDUyZDkgIG1mbjogMDAwMDUyZDkNCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzM6MDhdICAgZ2ZuOiAwMDAwNTJkYSAgbWZuOiAwMDAwNTJkYQ0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMzowOF0gICBnZm46IDAwMDA1MmRiICBtZm46IDAwMDA1MmRi
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjA4XSAgIGdmbjogMDAwMDUyZGMgIG1mbjog
MDAwMDUyZGMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MDhdICAgZ2ZuOiAwMDAwNTJk
ZCAgbWZuOiAwMDAwNTJkZA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzowOF0gICBnZm46
IDAwMDA1MmRlICBtZm46IDAwMDA1MmRlDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjA4
XSAgIGdmbjogMDAwMDUyZGYgIG1mbjogMDAwMDUyZGYNCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzM6MDhdICAgZ2ZuOiAwMDAwNTJlMCAgbWZuOiAwMDAwNTJlMA0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMzowOF0gICBnZm46IDAwMDA1MmUxICBtZm46IDAwMDA1MmUxDQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMzOjA4XSAgIGdmbjogMDAwMDUyZTIgIG1mbjogMDAwMDUy
ZTINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MDhdICAgZ2ZuOiAwMDAwNTJlMyAgbWZu
OiAwMDAwNTJlMw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzowOF0gICBnZm46IDAwMDA1
MmU0ICBtZm46IDAwMDA1MmU0DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjA4XSAgIGdm
bjogMDAwMDUyZTUgIG1mbjogMDAwMDUyZTUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6
MDhdICAgZ2ZuOiAwMDAwNTJlNiAgbWZuOiAwMDAwNTJlNg0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMzowOF0gICBnZm46IDAwMDA1MmU3ICBtZm46IDAwMDA1MmU3DQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMzOjA4XSAgIGdmbjogMDAwMDUyZTggIG1mbjogMDAwMDUyZTgNCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MDhdICAgZ2ZuOiAwMDAwNTJlOSAgbWZuOiAwMDAw
NTJlOQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzowOF0gICBnZm46IDAwMDA1MmVhICBt
Zm46IDAwMDA1MmVhDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjA4XSAgIGdmbjogMDAw
MDUyZWIgIG1mbjogMDAwMDUyZWINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MDhdICAg
Z2ZuOiAwMDAwNTJlYyAgbWZuOiAwMDAwNTJlYw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
MzowOF0gICBnZm46IDAwMDA1MmVkICBtZm46IDAwMDA1MmVkDQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMzOjA4XSAgIGdmbjogMDAwMDUyZWUgIG1mbjogMDAwMDUyZWUNCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzM6MDldICAgZ2ZuOiAwMDAwNTJlZiAgbWZuOiAwMDAwNTJlZg0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzowOV0gICBnZm46IDAwMDA1MmYwICBtZm46IDAw
MDA1MmYwDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjA5XSAgIGdmbjogMDAwMDUyZjEg
IG1mbjogMDAwMDUyZjENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MDldICAgZ2ZuOiAw
MDAwNTJmMiAgbWZuOiAwMDAwNTJmMg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzowOV0g
ICBnZm46IDAwMDA1MmYzICBtZm46IDAwMDA1MmYzDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMzOjA5XSAgIGdmbjogMDAwMDUyZjQgIG1mbjogMDAwMDUyZjQNCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzM6MDldICAgZ2ZuOiAwMDAwNTJmNSAgbWZuOiAwMDAwNTJmNQ0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMzowOV0gICBnZm46IDAwMDA1MmY2ICBtZm46IDAwMDA1MmY2
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjA5XSAgIGdmbjogMDAwMDUyZjcgIG1mbjog
MDAwMDUyZjcNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MDldICAgZ2ZuOiAwMDAwNTJm
OCAgbWZuOiAwMDAwNTJmOA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzowOV0gICBnZm46
IDAwMDA1MmY5ICBtZm46IDAwMDA1MmY5DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjA5
XSAgIGdmbjogMDAwMDUyZmEgIG1mbjogMDAwMDUyZmENCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzM6MDldICAgZ2ZuOiAwMDAwNTJmYiAgbWZuOiAwMDAwNTJmYg0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMzowOV0gICBnZm46IDAwMDA1MmZjICBtZm46IDAwMDA1MmZjDQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMzOjA5XSAgIGdmbjogMDAwMDUyZmQgIG1mbjogMDAwMDUy
ZmQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MDldICAgZ2ZuOiAwMDAwNTJmZSAgbWZu
OiAwMDAwNTJmZQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzowOV0gICBnZm46IDAwMDA1
MmZmICBtZm46IDAwMDA1MmZmDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjA5XSAgIGdm
bjogMDAwMDUzMDAgIG1mbjogMDAwMDUzMDANCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6
MDldICAgZ2ZuOiAwMDAwNTMwMSAgbWZuOiAwMDAwNTMwMQ0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMzowOV0gICBnZm46IDAwMDA1MzAyICBtZm46IDAwMDA1MzAyDQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMzOjA5XSAgIGdmbjogMDAwMDUzMDMgIG1mbjogMDAwMDUzMDMNCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MDldICAgZ2ZuOiAwMDAwNTMwNCAgbWZuOiAwMDAw
NTMwNA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzowOV0gICBnZm46IDAwMDA1MzA1ICBt
Zm46IDAwMDA1MzA1DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjA5XSAgIGdmbjogMDAw
MDUzMDYgIG1mbjogMDAwMDUzMDYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MDldICAg
Z2ZuOiAwMDAwNTMwNyAgbWZuOiAwMDAwNTMwNw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
MzowOV0gICBnZm46IDAwMDA1MzA4ICBtZm46IDAwMDA1MzA4DQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMzOjA5XSAgIGdmbjogMDAwMDUzMDkgIG1mbjogMDAwMDUzMDkNCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzM6MDldICAgZ2ZuOiAwMDAwNTMwYSAgbWZuOiAwMDAwNTMwYQ0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzowOV0gICBnZm46IDAwMDA1MzBiICBtZm46IDAw
MDA1MzBiDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjA5XSAgIGdmbjogMDAwMDUzMGMg
IG1mbjogMDAwMDUzMGMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MDldICAgZ2ZuOiAw
MDAwNTMwZCAgbWZuOiAwMDAwNTMwZA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzowOV0g
ICBnZm46IDAwMDA1MzBlICBtZm46IDAwMDA1MzBlDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMzOjA5XSAgIGdmbjogMDAwMDUzMGYgIG1mbjogMDAwMDUzMGYNCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzM6MDldICAgZ2ZuOiAwMDAwNTMxMCAgbWZuOiAwMDAwNTMxMA0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMzowOV0gICBnZm46IDAwMDA1MzExICBtZm46IDAwMDA1MzEx
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjA5XSAgIGdmbjogMDAwMDUzMTIgIG1mbjog
MDAwMDUzMTINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MDldICAgZ2ZuOiAwMDAwNTMx
MyAgbWZuOiAwMDAwNTMxMw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzowOV0gICBnZm46
IDAwMDA1MzE0ICBtZm46IDAwMDA1MzE0DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjA5
XSAgIGdmbjogMDAwMDUzMTUgIG1mbjogMDAwMDUzMTUNCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzM6MDldICAgZ2ZuOiAwMDAwNTMxNiAgbWZuOiAwMDAwNTMxNg0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMzowOV0gICBnZm46IDAwMDA1MzE3ICBtZm46IDAwMDA1MzE3DQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMzOjA5XSAgIGdmbjogMDAwMDUzMTggIG1mbjogMDAwMDUz
MTgNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MDldICAgZ2ZuOiAwMDAwNTMxOSAgbWZu
OiAwMDAwNTMxOQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzowOV0gICBnZm46IDAwMDA1
MzFhICBtZm46IDAwMDA1MzFhDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjA5XSAgIGdm
bjogMDAwMDUzMWIgIG1mbjogMDAwMDUzMWINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6
MDldICAgZ2ZuOiAwMDAwNTMxYyAgbWZuOiAwMDAwNTMxYw0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMzowOV0gICBnZm46IDAwMDA1MzFkICBtZm46IDAwMDA1MzFkDQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMzOjA5XSAgIGdmbjogMDAwMDUzMWUgIG1mbjogMDAwMDUzMWUNCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MDldICAgZ2ZuOiAwMDAwNTMxZiAgbWZuOiAwMDAw
NTMxZg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzowOV0gICBnZm46IDAwMDA1MzIwICBt
Zm46IDAwMDA1MzIwDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjA5XSAgIGdmbjogMDAw
MDUzMjEgIG1mbjogMDAwMDUzMjENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MDldICAg
Z2ZuOiAwMDAwNTMyMiAgbWZuOiAwMDAwNTMyMg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
MzowOV0gICBnZm46IDAwMDA1MzIzICBtZm46IDAwMDA1MzIzDQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMzOjA5XSAgIGdmbjogMDAwMDUzMjQgIG1mbjogMDAwMDUzMjQNCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzM6MDldICAgZ2ZuOiAwMDAwNTMyNSAgbWZuOiAwMDAwNTMyNQ0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzowOV0gICBnZm46IDAwMDA1MzI2ICBtZm46IDAw
MDA1MzI2DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjA5XSAgIGdmbjogMDAwMDUzMjcg
IG1mbjogMDAwMDUzMjcNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MDldICAgZ2ZuOiAw
MDAwNTMyOCAgbWZuOiAwMDAwNTMyOA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzowOV0g
ICBnZm46IDAwMDA1MzI5ICBtZm46IDAwMDA1MzI5DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMzOjA5XSAgIGdmbjogMDAwMDUzMmEgIG1mbjogMDAwMDUzMmENCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzM6MDldICAgZ2ZuOiAwMDAwNTMyYiAgbWZuOiAwMDAwNTMyYg0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMzowOV0gICBnZm46IDAwMDA1MzJjICBtZm46IDAwMDA1MzJj
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjA5XSAgIGdmbjogMDAwMDUzMmQgIG1mbjog
MDAwMDUzMmQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MDldICAgZ2ZuOiAwMDAwNTMy
ZSAgbWZuOiAwMDAwNTMyZQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoxMF0gICBnZm46
IDAwMDA1MzJmICBtZm46IDAwMDA1MzJmDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjEw
XSAgIGdmbjogMDAwMDUzMzAgIG1mbjogMDAwMDUzMzANCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzM6MTBdICAgZ2ZuOiAwMDAwNTMzMSAgbWZuOiAwMDAwNTMzMQ0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMzoxMF0gICBnZm46IDAwMDA1MzMyICBtZm46IDAwMDA1MzMyDQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMzOjEwXSAgIGdmbjogMDAwMDUzMzMgIG1mbjogMDAwMDUz
MzMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MTBdICAgZ2ZuOiAwMDAwNTMzNCAgbWZu
OiAwMDAwNTMzNA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoxMF0gICBnZm46IDAwMDA1
MzM1ICBtZm46IDAwMDA1MzM1DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjEwXSAgIGdm
bjogMDAwMDUzMzYgIG1mbjogMDAwMDUzMzYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6
MTBdICAgZ2ZuOiAwMDAwNTMzNyAgbWZuOiAwMDAwNTMzNw0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMzoxMF0gICBnZm46IDAwMDA1MzM4ICBtZm46IDAwMDA1MzM4DQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMzOjEwXSAgIGdmbjogMDAwMDUzMzkgIG1mbjogMDAwMDUzMzkNCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MTBdICAgZ2ZuOiAwMDAwNTMzYSAgbWZuOiAwMDAw
NTMzYQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoxMF0gICBnZm46IDAwMDA1MzNiICBt
Zm46IDAwMDA1MzNiDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjEwXSAgIGdmbjogMDAw
MDUzM2MgIG1mbjogMDAwMDUzM2MNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MTBdICAg
Z2ZuOiAwMDAwNTMzZCAgbWZuOiAwMDAwNTMzZA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
MzoxMF0gICBnZm46IDAwMDA1MzNlICBtZm46IDAwMDA1MzNlDQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMzOjEwXSAgIGdmbjogMDAwMDUzM2YgIG1mbjogMDAwMDUzM2YNCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzM6MTBdICAgZ2ZuOiAwMDAwNTM0MCAgbWZuOiAwMDAwNTM0MA0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoxMF0gICBnZm46IDAwMDA1MzQxICBtZm46IDAw
MDA1MzQxDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjEwXSAgIGdmbjogMDAwMDUzNDIg
IG1mbjogMDAwMDUzNDINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MTBdICAgZ2ZuOiAw
MDAwNTM0MyAgbWZuOiAwMDAwNTM0Mw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoxMF0g
ICBnZm46IDAwMDA1MzQ0ICBtZm46IDAwMDA1MzQ0DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMzOjEwXSAgIGdmbjogMDAwMDUzNDUgIG1mbjogMDAwMDUzNDUNCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzM6MTBdICAgZ2ZuOiAwMDAwNTM0NiAgbWZuOiAwMDAwNTM0Ng0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMzoxMF0gICBnZm46IDAwMDA1MzQ3ICBtZm46IDAwMDA1MzQ3
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjEwXSAgIGdmbjogMDAwMDUzNDggIG1mbjog
MDAwMDUzNDgNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MTBdICAgZ2ZuOiAwMDAwNTM0
OSAgbWZuOiAwMDAwNTM0OQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoxMF0gICBnZm46
IDAwMDA1MzRhICBtZm46IDAwMDA1MzRhDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjEw
XSAgIGdmbjogMDAwMDUzNGIgIG1mbjogMDAwMDUzNGINCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzM6MTBdICAgZ2ZuOiAwMDAwNTM0YyAgbWZuOiAwMDAwNTM0Yw0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMzoxMF0gICBnZm46IDAwMDA1MzRkICBtZm46IDAwMDA1MzRkDQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMzOjEwXSAgIGdmbjogMDAwMDUzNGUgIG1mbjogMDAwMDUz
NGUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MTBdICAgZ2ZuOiAwMDAwNTM0ZiAgbWZu
OiAwMDAwNTM0Zg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoxMF0gICBnZm46IDAwMDA1
MzUwICBtZm46IDAwMDA1MzUwDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjEwXSAgIGdm
bjogMDAwMDUzNTEgIG1mbjogMDAwMDUzNTENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6
MTBdICAgZ2ZuOiAwMDAwNTM1MiAgbWZuOiAwMDAwNTM1Mg0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMzoxMF0gICBnZm46IDAwMDA1MzUzICBtZm46IDAwMDA1MzUzDQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMzOjEwXSAgIGdmbjogMDAwMDUzNTQgIG1mbjogMDAwMDUzNTQNCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MTBdICAgZ2ZuOiAwMDAwNTM1NSAgbWZuOiAwMDAw
NTM1NQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoxMF0gICBnZm46IDAwMDA1MzU2ICBt
Zm46IDAwMDA1MzU2DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjEwXSAgIGdmbjogMDAw
MDUzNTcgIG1mbjogMDAwMDUzNTcNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MTBdICAg
Z2ZuOiAwMDAwNTM1OCAgbWZuOiAwMDAwNTM1OA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
MzoxMF0gICBnZm46IDAwMDA1MzU5ICBtZm46IDAwMDA1MzU5DQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMzOjEwXSAgIGdmbjogMDAwMDUzNWEgIG1mbjogMDAwMDUzNWENCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzM6MTBdICAgZ2ZuOiAwMDAwNTM1YiAgbWZuOiAwMDAwNTM1Yg0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoxMF0gICBnZm46IDAwMDA1MzVjICBtZm46IDAw
MDA1MzVjDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjEwXSAgIGdmbjogMDAwMDUzNWQg
IG1mbjogMDAwMDUzNWQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MTBdICAgZ2ZuOiAw
MDAwNTM1ZSAgbWZuOiAwMDAwNTM1ZQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoxMF0g
ICBnZm46IDAwMDA1MzVmICBtZm46IDAwMDA1MzVmDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMzOjEwXSAgIGdmbjogMDAwMDUzNjAgIG1mbjogMDAwMDUzNjANCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzM6MTBdICAgZ2ZuOiAwMDAwNTM2MSAgbWZuOiAwMDAwNTM2MQ0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMzoxMF0gICBnZm46IDAwMDA1MzYyICBtZm46IDAwMDA1MzYy
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjEwXSAgIGdmbjogMDAwMDUzNjMgIG1mbjog
MDAwMDUzNjMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MTBdICAgZ2ZuOiAwMDAwNTM2
NCAgbWZuOiAwMDAwNTM2NA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoxMF0gICBnZm46
IDAwMDA1MzY1ICBtZm46IDAwMDA1MzY1DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjEw
XSAgIGdmbjogMDAwMDUzNjYgIG1mbjogMDAwMDUzNjYNCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzM6MTBdICAgZ2ZuOiAwMDAwNTM2NyAgbWZuOiAwMDAwNTM2Nw0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMzoxMF0gICBnZm46IDAwMDA1MzY4ICBtZm46IDAwMDA1MzY4DQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMzOjEwXSAgIGdmbjogMDAwMDUzNjkgIG1mbjogMDAwMDUz
NjkNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MTBdICAgZ2ZuOiAwMDAwNTM2YSAgbWZu
OiAwMDAwNTM2YQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoxMF0gICBnZm46IDAwMDA1
MzZiICBtZm46IDAwMDA1MzZiDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjEwXSAgIGdm
bjogMDAwMDUzNmMgIG1mbjogMDAwMDUzNmMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6
MTBdICAgZ2ZuOiAwMDAwNTM2ZCAgbWZuOiAwMDAwNTM2ZA0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMzoxMF0gICBnZm46IDAwMDA1MzZlICBtZm46IDAwMDA1MzZlDQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMzOjExXSAgIGdmbjogMDAwMDUzNmYgIG1mbjogMDAwMDUzNmYNCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MTFdICAgZ2ZuOiAwMDAwNTM3MCAgbWZuOiAwMDAw
NTM3MA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoxMV0gICBnZm46IDAwMDA1MzcxICBt
Zm46IDAwMDA1MzcxDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjExXSAgIGdmbjogMDAw
MDUzNzIgIG1mbjogMDAwMDUzNzINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MTFdICAg
Z2ZuOiAwMDAwNTM3MyAgbWZuOiAwMDAwNTM3Mw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
MzoxMV0gICBnZm46IDAwMDA1Mzc0ICBtZm46IDAwMDA1Mzc0DQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMzOjExXSAgIGdmbjogMDAwMDUzNzUgIG1mbjogMDAwMDUzNzUNCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzM6MTFdICAgZ2ZuOiAwMDAwNTM3NiAgbWZuOiAwMDAwNTM3Ng0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoxMV0gICBnZm46IDAwMDA1Mzc3ICBtZm46IDAw
MDA1Mzc3DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjExXSAgIGdmbjogMDAwMDUzNzgg
IG1mbjogMDAwMDUzNzgNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MTFdICAgZ2ZuOiAw
MDAwNTM3OSAgbWZuOiAwMDAwNTM3OQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoxMV0g
ICBnZm46IDAwMDA1MzdhICBtZm46IDAwMDA1MzdhDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMzOjExXSAgIGdmbjogMDAwMDUzN2IgIG1mbjogMDAwMDUzN2INCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzM6MTFdICAgZ2ZuOiAwMDAwNTM3YyAgbWZuOiAwMDAwNTM3Yw0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMzoxMV0gICBnZm46IDAwMDA1MzdkICBtZm46IDAwMDA1Mzdk
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjExXSAgIGdmbjogMDAwMDUzN2UgIG1mbjog
MDAwMDUzN2UNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MTFdICAgZ2ZuOiAwMDAwNTM3
ZiAgbWZuOiAwMDAwNTM3Zg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoxMV0gICBnZm46
IDAwMDA1MzgwICBtZm46IDAwMDA1MzgwDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjEx
XSAgIGdmbjogMDAwMDUzODEgIG1mbjogMDAwMDUzODENCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzM6MTFdICAgZ2ZuOiAwMDAwNTM4MiAgbWZuOiAwMDAwNTM4Mg0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMzoxMV0gICBnZm46IDAwMDA1MzgzICBtZm46IDAwMDA1MzgzDQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMzOjExXSAgIGdmbjogMDAwMDUzODQgIG1mbjogMDAwMDUz
ODQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MTFdICAgZ2ZuOiAwMDAwNTM4NSAgbWZu
OiAwMDAwNTM4NQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoxMV0gICBnZm46IDAwMDA1
Mzg2ICBtZm46IDAwMDA1Mzg2DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjExXSAgIGdm
bjogMDAwMDUzODcgIG1mbjogMDAwMDUzODcNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6
MTFdICAgZ2ZuOiAwMDAwNTM4OCAgbWZuOiAwMDAwNTM4OA0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMzoxMV0gICBnZm46IDAwMDA1Mzg5ICBtZm46IDAwMDA1Mzg5DQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMzOjExXSAgIGdmbjogMDAwMDUzOGEgIG1mbjogMDAwMDUzOGENCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MTFdICAgZ2ZuOiAwMDAwNTM4YiAgbWZuOiAwMDAw
NTM4Yg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoxMV0gICBnZm46IDAwMDA1MzhjICBt
Zm46IDAwMDA1MzhjDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjExXSAgIGdmbjogMDAw
MDUzOGQgIG1mbjogMDAwMDUzOGQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MTFdICAg
Z2ZuOiAwMDAwNTM4ZSAgbWZuOiAwMDAwNTM4ZQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
MzoxMV0gICBnZm46IDAwMDA1MzhmICBtZm46IDAwMDA1MzhmDQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMzOjExXSAgIGdmbjogMDAwMDUzOTAgIG1mbjogMDAwMDUzOTANCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzM6MTFdICAgZ2ZuOiAwMDAwNTM5MSAgbWZuOiAwMDAwNTM5MQ0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoxMV0gICBnZm46IDAwMDA1MzkyICBtZm46IDAw
MDA1MzkyDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjExXSAgIGdmbjogMDAwMDUzOTMg
IG1mbjogMDAwMDUzOTMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MTFdICAgZ2ZuOiAw
MDAwNTM5NCAgbWZuOiAwMDAwNTM5NA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoxMV0g
ICBnZm46IDAwMDA1Mzk1ICBtZm46IDAwMDA1Mzk1DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMzOjExXSAgIGdmbjogMDAwMDUzOTYgIG1mbjogMDAwMDUzOTYNCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzM6MTFdICAgZ2ZuOiAwMDAwNTM5NyAgbWZuOiAwMDAwNTM5Nw0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMzoxMV0gICBnZm46IDAwMDA1Mzk4ICBtZm46IDAwMDA1Mzk4
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjExXSAgIGdmbjogMDAwMDUzOTkgIG1mbjog
MDAwMDUzOTkNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MTFdICAgZ2ZuOiAwMDAwNTM5
YSAgbWZuOiAwMDAwNTM5YQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoxMV0gICBnZm46
IDAwMDA1MzliICBtZm46IDAwMDA1MzliDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjEx
XSAgIGdmbjogMDAwMDUzOWMgIG1mbjogMDAwMDUzOWMNCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzM6MTFdICAgZ2ZuOiAwMDAwNTM5ZCAgbWZuOiAwMDAwNTM5ZA0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMzoxMV0gICBnZm46IDAwMDA1MzllICBtZm46IDAwMDA1MzllDQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMzOjExXSAgIGdmbjogMDAwMDUzOWYgIG1mbjogMDAwMDUz
OWYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MTFdICAgZ2ZuOiAwMDAwNTNhMCAgbWZu
OiAwMDAwNTNhMA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoxMV0gICBnZm46IDAwMDA1
M2ExICBtZm46IDAwMDA1M2ExDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjExXSAgIGdm
bjogMDAwMDUzYTIgIG1mbjogMDAwMDUzYTINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6
MTFdICAgZ2ZuOiAwMDAwNTNhMyAgbWZuOiAwMDAwNTNhMw0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMzoxMV0gICBnZm46IDAwMDA1M2E0ICBtZm46IDAwMDA1M2E0DQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMzOjExXSAgIGdmbjogMDAwMDUzYTUgIG1mbjogMDAwMDUzYTUNCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MTFdICAgZ2ZuOiAwMDAwNTNhNiAgbWZuOiAwMDAw
NTNhNg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoxMV0gICBnZm46IDAwMDA1M2E3ICBt
Zm46IDAwMDA1M2E3DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjExXSAgIGdmbjogMDAw
MDUzYTggIG1mbjogMDAwMDUzYTgNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MTFdICAg
Z2ZuOiAwMDAwNTNhOSAgbWZuOiAwMDAwNTNhOQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
MzoxMV0gICBnZm46IDAwMDA1M2FhICBtZm46IDAwMDA1M2FhDQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMzOjExXSAgIGdmbjogMDAwMDUzYWIgIG1mbjogMDAwMDUzYWINCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzM6MTFdICAgZ2ZuOiAwMDAwNTNhYyAgbWZuOiAwMDAwNTNhYw0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoxMV0gICBnZm46IDAwMDA1M2FkICBtZm46IDAw
MDA1M2FkDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjExXSAgIGdmbjogMDAwMDUzYWUg
IG1mbjogMDAwMDUzYWUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MTJdICAgZ2ZuOiAw
MDAwNTNhZiAgbWZuOiAwMDAwNTNhZg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoxMl0g
ICBnZm46IDAwMDA1M2IwICBtZm46IDAwMDA1M2IwDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMzOjEyXSAgIGdmbjogMDAwMDUzYjEgIG1mbjogMDAwMDUzYjENCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzM6MTJdICAgZ2ZuOiAwMDAwNTNiMiAgbWZuOiAwMDAwNTNiMg0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMzoxMl0gICBnZm46IDAwMDA1M2IzICBtZm46IDAwMDA1M2Iz
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjEyXSAgIGdmbjogMDAwMDUzYjQgIG1mbjog
MDAwMDUzYjQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MTJdICAgZ2ZuOiAwMDAwNTNi
NSAgbWZuOiAwMDAwNTNiNQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoxMl0gICBnZm46
IDAwMDA1M2I2ICBtZm46IDAwMDA1M2I2DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjEy
XSAgIGdmbjogMDAwMDUzYjcgIG1mbjogMDAwMDUzYjcNCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzM6MTJdICAgZ2ZuOiAwMDAwNTNiOCAgbWZuOiAwMDAwNTNiOA0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMzoxMl0gICBnZm46IDAwMDA1M2I5ICBtZm46IDAwMDA1M2I5DQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMzOjEyXSAgIGdmbjogMDAwMDUzYmEgIG1mbjogMDAwMDUz
YmENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MTJdICAgZ2ZuOiAwMDAwNTNiYiAgbWZu
OiAwMDAwNTNiYg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoxMl0gICBnZm46IDAwMDA1
M2JjICBtZm46IDAwMDA1M2JjDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjEyXSAgIGdm
bjogMDAwMDUzYmQgIG1mbjogMDAwMDUzYmQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6
MTJdICAgZ2ZuOiAwMDAwNTNiZSAgbWZuOiAwMDAwNTNiZQ0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMzoxMl0gICBnZm46IDAwMDA1M2JmICBtZm46IDAwMDA1M2JmDQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMzOjEyXSAgIGdmbjogMDAwMDUzYzAgIG1mbjogMDAwMDUzYzANCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MTJdICAgZ2ZuOiAwMDAwNTNjMSAgbWZuOiAwMDAw
NTNjMQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoxMl0gICBnZm46IDAwMDA1M2MyICBt
Zm46IDAwMDA1M2MyDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjEyXSAgIGdmbjogMDAw
MDUzYzMgIG1mbjogMDAwMDUzYzMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MTJdICAg
Z2ZuOiAwMDAwNTNjNCAgbWZuOiAwMDAwNTNjNA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
MzoxMl0gICBnZm46IDAwMDA1M2M1ICBtZm46IDAwMDA1M2M1DQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMzOjEyXSAgIGdmbjogMDAwMDUzYzYgIG1mbjogMDAwMDUzYzYNCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzM6MTJdICAgZ2ZuOiAwMDAwNTNjNyAgbWZuOiAwMDAwNTNjNw0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoxMl0gICBnZm46IDAwMDA1M2M4ICBtZm46IDAw
MDA1M2M4DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjEyXSAgIGdmbjogMDAwMDUzYzkg
IG1mbjogMDAwMDUzYzkNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MTJdICAgZ2ZuOiAw
MDAwNTNjYSAgbWZuOiAwMDAwNTNjYQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoxMl0g
ICBnZm46IDAwMDA1M2NiICBtZm46IDAwMDA1M2NiDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMzOjEyXSAgIGdmbjogMDAwMDUzY2MgIG1mbjogMDAwMDUzY2MNCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzM6MTJdICAgZ2ZuOiAwMDAwNTNjZCAgbWZuOiAwMDAwNTNjZA0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMzoxMl0gICBnZm46IDAwMDA1M2NlICBtZm46IDAwMDA1M2Nl
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjEyXSAgIGdmbjogMDAwMDUzY2YgIG1mbjog
MDAwMDUzY2YNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MTJdICAgZ2ZuOiAwMDAwNTNk
MCAgbWZuOiAwMDAwNTNkMA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoxMl0gICBnZm46
IDAwMDA1M2QxICBtZm46IDAwMDA1M2QxDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjEy
XSAgIGdmbjogMDAwMDUzZDIgIG1mbjogMDAwMDUzZDINCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzM6MTJdICAgZ2ZuOiAwMDAwNTNkMyAgbWZuOiAwMDAwNTNkMw0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMzoxMl0gICBnZm46IDAwMDA1M2Q0ICBtZm46IDAwMDA1M2Q0DQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMzOjEyXSAgIGdmbjogMDAwMDUzZDUgIG1mbjogMDAwMDUz
ZDUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MTJdICAgZ2ZuOiAwMDAwNTNkNiAgbWZu
OiAwMDAwNTNkNg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoxMl0gICBnZm46IDAwMDA1
M2Q3ICBtZm46IDAwMDA1M2Q3DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjEyXSAgIGdm
bjogMDAwMDUzZDggIG1mbjogMDAwMDUzZDgNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6
MTJdICAgZ2ZuOiAwMDAwNTNkOSAgbWZuOiAwMDAwNTNkOQ0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMzoxMl0gICBnZm46IDAwMDA1M2RhICBtZm46IDAwMDA1M2RhDQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMzOjEyXSAgIGdmbjogMDAwMDUzZGIgIG1mbjogMDAwMDUzZGINCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MTJdICAgZ2ZuOiAwMDAwNTNkYyAgbWZuOiAwMDAw
NTNkYw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoxMl0gICBnZm46IDAwMDA1M2RkICBt
Zm46IDAwMDA1M2RkDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjEyXSAgIGdmbjogMDAw
MDUzZGUgIG1mbjogMDAwMDUzZGUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MTJdICAg
Z2ZuOiAwMDAwNTNkZiAgbWZuOiAwMDAwNTNkZg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
MzoxMl0gICBnZm46IDAwMDA1M2UwICBtZm46IDAwMDA1M2UwDQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMzOjEyXSAgIGdmbjogMDAwMDUzZTEgIG1mbjogMDAwMDUzZTENCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzM6MTJdICAgZ2ZuOiAwMDAwNTNlMiAgbWZuOiAwMDAwNTNlMg0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoxMl0gICBnZm46IDAwMDA1M2UzICBtZm46IDAw
MDA1M2UzDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjEyXSAgIGdmbjogMDAwMDUzZTQg
IG1mbjogMDAwMDUzZTQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MTJdICAgZ2ZuOiAw
MDAwNTNlNSAgbWZuOiAwMDAwNTNlNQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoxMl0g
ICBnZm46IDAwMDA1M2U2ICBtZm46IDAwMDA1M2U2DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMzOjEyXSAgIGdmbjogMDAwMDUzZTcgIG1mbjogMDAwMDUzZTcNCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzM6MTJdICAgZ2ZuOiAwMDAwNTNlOCAgbWZuOiAwMDAwNTNlOA0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMzoxMl0gICBnZm46IDAwMDA1M2U5ICBtZm46IDAwMDA1M2U5
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjEyXSAgIGdmbjogMDAwMDUzZWEgIG1mbjog
MDAwMDUzZWENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MTJdICAgZ2ZuOiAwMDAwNTNl
YiAgbWZuOiAwMDAwNTNlYg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoxMl0gICBnZm46
IDAwMDA1M2VjICBtZm46IDAwMDA1M2VjDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjEy
XSAgIGdmbjogMDAwMDUzZWQgIG1mbjogMDAwMDUzZWQNCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzM6MTJdICAgZ2ZuOiAwMDAwNTNlZSAgbWZuOiAwMDAwNTNlZQ0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMzoxM10gICBnZm46IDAwMDA1M2VmICBtZm46IDAwMDA1M2VmDQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMzOjEzXSAgIGdmbjogMDAwMDUzZjAgIG1mbjogMDAwMDUz
ZjANCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MTNdICAgZ2ZuOiAwMDAwNTNmMSAgbWZu
OiAwMDAwNTNmMQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoxM10gICBnZm46IDAwMDA1
M2YyICBtZm46IDAwMDA1M2YyDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjEzXSAgIGdm
bjogMDAwMDUzZjMgIG1mbjogMDAwMDUzZjMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6
MTNdICAgZ2ZuOiAwMDAwNTNmNCAgbWZuOiAwMDAwNTNmNA0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMzoxM10gICBnZm46IDAwMDA1M2Y1ICBtZm46IDAwMDA1M2Y1DQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMzOjEzXSAgIGdmbjogMDAwMDUzZjYgIG1mbjogMDAwMDUzZjYNCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MTNdICAgZ2ZuOiAwMDAwNTNmNyAgbWZuOiAwMDAw
NTNmNw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoxM10gICBnZm46IDAwMDA1M2Y4ICBt
Zm46IDAwMDA1M2Y4DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjEzXSAgIGdmbjogMDAw
MDUzZjkgIG1mbjogMDAwMDUzZjkNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MTNdICAg
Z2ZuOiAwMDAwNTNmYSAgbWZuOiAwMDAwNTNmYQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
MzoxM10gICBnZm46IDAwMDA1M2ZiICBtZm46IDAwMDA1M2ZiDQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMzOjEzXSAgIGdmbjogMDAwMDUzZmMgIG1mbjogMDAwMDUzZmMNCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzM6MTNdICAgZ2ZuOiAwMDAwNTNmZCAgbWZuOiAwMDAwNTNmZA0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoxM10gICBnZm46IDAwMDA1M2ZlICBtZm46IDAw
MDA1M2ZlDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjEzXSAgIGdmbjogMDAwMDUzZmYg
IG1mbjogMDAwMDUzZmYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MTNdICAgZ2ZuOiAw
MDAwNTQwMCAgbWZuOiAwMDAwNTQwMA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoxM10g
ICBnZm46IDAwMDA1NDAxICBtZm46IDAwMDA1NDAxDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMzOjEzXSAgIGdmbjogMDAwMDU0MDIgIG1mbjogMDAwMDU0MDINCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzM6MTNdICAgZ2ZuOiAwMDAwNTQwMyAgbWZuOiAwMDAwNTQwMw0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMzoxM10gICBnZm46IDAwMDA1NDA0ICBtZm46IDAwMDA1NDA0
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjEzXSAgIGdmbjogMDAwMDU0MDUgIG1mbjog
MDAwMDU0MDUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MTNdICAgZ2ZuOiAwMDAwNTQw
NiAgbWZuOiAwMDAwNTQwNg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoxM10gICBnZm46
IDAwMDA1NDA3ICBtZm46IDAwMDA1NDA3DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjEz
XSAgIGdmbjogMDAwMDU0MDggIG1mbjogMDAwMDU0MDgNCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzM6MTNdICAgZ2ZuOiAwMDAwNTQwOSAgbWZuOiAwMDAwNTQwOQ0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMzoxM10gICBnZm46IDAwMDA1NDBhICBtZm46IDAwMDA1NDBhDQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMzOjEzXSAgIGdmbjogMDAwMDU0MGIgIG1mbjogMDAwMDU0
MGINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MTNdICAgZ2ZuOiAwMDAwNTQwYyAgbWZu
OiAwMDAwNTQwYw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoxM10gICBnZm46IDAwMDA1
NDBkICBtZm46IDAwMDA1NDBkDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjEzXSAgIGdm
bjogMDAwMDU0MGUgIG1mbjogMDAwMDU0MGUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6
MTNdICAgZ2ZuOiAwMDAwNTQwZiAgbWZuOiAwMDAwNTQwZg0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMzoxM10gICBnZm46IDAwMDA1NDEwICBtZm46IDAwMDA1NDEwDQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMzOjEzXSAgIGdmbjogMDAwMDU0MTEgIG1mbjogMDAwMDU0MTENCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MTNdICAgZ2ZuOiAwMDAwNTQxMiAgbWZuOiAwMDAw
NTQxMg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoxM10gICBnZm46IDAwMDA1NDEzICBt
Zm46IDAwMDA1NDEzDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjEzXSAgIGdmbjogMDAw
MDU0MTQgIG1mbjogMDAwMDU0MTQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MTNdICAg
Z2ZuOiAwMDAwNTQxNSAgbWZuOiAwMDAwNTQxNQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
MzoxM10gICBnZm46IDAwMDA1NDE2ICBtZm46IDAwMDA1NDE2DQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMzOjEzXSAgIGdmbjogMDAwMDU0MTcgIG1mbjogMDAwMDU0MTcNCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzM6MTNdICAgZ2ZuOiAwMDAwNTQxOCAgbWZuOiAwMDAwNTQxOA0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoxM10gICBnZm46IDAwMDA1NDE5ICBtZm46IDAw
MDA1NDE5DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjEzXSAgIGdmbjogMDAwMDU0MWEg
IG1mbjogMDAwMDU0MWENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MTNdICAgZ2ZuOiAw
MDAwNTQxYiAgbWZuOiAwMDAwNTQxYg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoxM10g
ICBnZm46IDAwMDA1NDFjICBtZm46IDAwMDA1NDFjDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMzOjEzXSAgIGdmbjogMDAwMDU0MWQgIG1mbjogMDAwMDU0MWQNCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzM6MTNdICAgZ2ZuOiAwMDAwNTQxZSAgbWZuOiAwMDAwNTQxZQ0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMzoxM10gICBnZm46IDAwMDA1NDFmICBtZm46IDAwMDA1NDFm
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjEzXSAgIGdmbjogMDAwMDU0MjAgIG1mbjog
MDAwMDU0MjANCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MTNdICAgZ2ZuOiAwMDAwNTQy
MSAgbWZuOiAwMDAwNTQyMQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoxM10gICBnZm46
IDAwMDA1NDIyICBtZm46IDAwMDA1NDIyDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjEz
XSAgIGdmbjogMDAwMDU0MjMgIG1mbjogMDAwMDU0MjMNCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzM6MTNdICAgZ2ZuOiAwMDAwNTQyNCAgbWZuOiAwMDAwNTQyNA0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMzoxM10gICBnZm46IDAwMDA1NDI1ICBtZm46IDAwMDA1NDI1DQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMzOjEzXSAgIGdmbjogMDAwMDU0MjYgIG1mbjogMDAwMDU0
MjYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MTNdICAgZ2ZuOiAwMDAwNTQyNyAgbWZu
OiAwMDAwNTQyNw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoxM10gICBnZm46IDAwMDA1
NDI4ICBtZm46IDAwMDA1NDI4DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjEzXSAgIGdm
bjogMDAwMDU0MjkgIG1mbjogMDAwMDU0MjkNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6
MTNdICAgZ2ZuOiAwMDAwNTQyYSAgbWZuOiAwMDAwNTQyYQ0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMzoxM10gICBnZm46IDAwMDA1NDJiICBtZm46IDAwMDA1NDJiDQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMzOjEzXSAgIGdmbjogMDAwMDU0MmMgIG1mbjogMDAwMDU0MmMNCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MTNdICAgZ2ZuOiAwMDAwNTQyZCAgbWZuOiAwMDAw
NTQyZA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoxM10gICBnZm46IDAwMDA1NDJlICBt
Zm46IDAwMDA1NDJlDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjE0XSAgIGdmbjogMDAw
MDU0MmYgIG1mbjogMDAwMDU0MmYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MTRdICAg
Z2ZuOiAwMDAwNTQzMCAgbWZuOiAwMDAwNTQzMA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
MzoxNF0gICBnZm46IDAwMDA1NDMxICBtZm46IDAwMDA1NDMxDQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMzOjE0XSAgIGdmbjogMDAwMDU0MzIgIG1mbjogMDAwMDU0MzINCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzM6MTRdICAgZ2ZuOiAwMDAwNTQzMyAgbWZuOiAwMDAwNTQzMw0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoxNF0gICBnZm46IDAwMDA1NDM0ICBtZm46IDAw
MDA1NDM0DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjE0XSAgIGdmbjogMDAwMDU0MzUg
IG1mbjogMDAwMDU0MzUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MTRdICAgZ2ZuOiAw
MDAwNTQzNiAgbWZuOiAwMDAwNTQzNg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoxNF0g
ICBnZm46IDAwMDA1NDM3ICBtZm46IDAwMDA1NDM3DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMzOjE0XSAgIGdmbjogMDAwMDU0MzggIG1mbjogMDAwMDU0MzgNCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzM6MTRdICAgZ2ZuOiAwMDAwNTQzOSAgbWZuOiAwMDAwNTQzOQ0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMzoxNF0gICBnZm46IDAwMDA1NDNhICBtZm46IDAwMDA1NDNh
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjE0XSAgIGdmbjogMDAwMDU0M2IgIG1mbjog
MDAwMDU0M2INCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MTRdICAgZ2ZuOiAwMDAwNTQz
YyAgbWZuOiAwMDAwNTQzYw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoxNF0gICBnZm46
IDAwMDA1NDNkICBtZm46IDAwMDA1NDNkDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjE0
XSAgIGdmbjogMDAwMDU0M2UgIG1mbjogMDAwMDU0M2UNCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzM6MTRdICAgZ2ZuOiAwMDAwNTQzZiAgbWZuOiAwMDAwNTQzZg0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMzoxNF0gICBnZm46IDAwMDA1NDQwICBtZm46IDAwMDA1NDQwDQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMzOjE0XSAgIGdmbjogMDAwMDU0NDEgIG1mbjogMDAwMDU0
NDENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MTRdICAgZ2ZuOiAwMDAwNTQ0MiAgbWZu
OiAwMDAwNTQ0Mg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoxNF0gICBnZm46IDAwMDA1
NDQzICBtZm46IDAwMDA1NDQzDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjE0XSAgIGdm
bjogMDAwMDU0NDQgIG1mbjogMDAwMDU0NDQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6
MTRdICAgZ2ZuOiAwMDAwNTQ0NSAgbWZuOiAwMDAwNTQ0NQ0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMzoxNF0gICBnZm46IDAwMDA1NDQ2ICBtZm46IDAwMDA1NDQ2DQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMzOjE0XSAgIGdmbjogMDAwMDU0NDcgIG1mbjogMDAwMDU0NDcNCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MTRdICAgZ2ZuOiAwMDAwNTQ0OCAgbWZuOiAwMDAw
NTQ0OA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoxNF0gICBnZm46IDAwMDA1NDQ5ICBt
Zm46IDAwMDA1NDQ5DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjE0XSAgIGdmbjogMDAw
MDU0NGEgIG1mbjogMDAwMDU0NGENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MTRdICAg
Z2ZuOiAwMDAwNTQ0YiAgbWZuOiAwMDAwNTQ0Yg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
MzoxNF0gICBnZm46IDAwMDA1NDRjICBtZm46IDAwMDA1NDRjDQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMzOjE0XSAgIGdmbjogMDAwMDU0NGQgIG1mbjogMDAwMDU0NGQNCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzM6MTRdICAgZ2ZuOiAwMDAwNTQ0ZSAgbWZuOiAwMDAwNTQ0ZQ0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoxNF0gICBnZm46IDAwMDA1NDRmICBtZm46IDAw
MDA1NDRmDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjE0XSAgIGdmbjogMDAwMDU0NTAg
IG1mbjogMDAwMDU0NTANCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MTRdICAgZ2ZuOiAw
MDAwNTQ1MSAgbWZuOiAwMDAwNTQ1MQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoxNF0g
ICBnZm46IDAwMDA1NDUyICBtZm46IDAwMDA1NDUyDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMzOjE0XSAgIGdmbjogMDAwMDU0NTMgIG1mbjogMDAwMDU0NTMNCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzM6MTRdICAgZ2ZuOiAwMDAwNTQ1NCAgbWZuOiAwMDAwNTQ1NA0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMzoxNF0gICBnZm46IDAwMDA1NDU1ICBtZm46IDAwMDA1NDU1
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjE0XSAgIGdmbjogMDAwMDU0NTYgIG1mbjog
MDAwMDU0NTYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MTRdICAgZ2ZuOiAwMDAwNTQ1
NyAgbWZuOiAwMDAwNTQ1Nw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoxNF0gICBnZm46
IDAwMDA1NDU4ICBtZm46IDAwMDA1NDU4DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjE0
XSAgIGdmbjogMDAwMDU0NTkgIG1mbjogMDAwMDU0NTkNCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzM6MTRdICAgZ2ZuOiAwMDAwNTQ1YSAgbWZuOiAwMDAwNTQ1YQ0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMzoxNF0gICBnZm46IDAwMDA1NDViICBtZm46IDAwMDA1NDViDQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMzOjE0XSAgIGdmbjogMDAwMDU0NWMgIG1mbjogMDAwMDU0
NWMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MTRdICAgZ2ZuOiAwMDAwNTQ1ZCAgbWZu
OiAwMDAwNTQ1ZA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoxNF0gICBnZm46IDAwMDA1
NDVlICBtZm46IDAwMDA1NDVlDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjE0XSAgIGdm
bjogMDAwMDU0NWYgIG1mbjogMDAwMDU0NWYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6
MTRdICAgZ2ZuOiAwMDAwNTQ2MCAgbWZuOiAwMDAwNTQ2MA0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMzoxNF0gICBnZm46IDAwMDA1NDYxICBtZm46IDAwMDA1NDYxDQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMzOjE0XSAgIGdmbjogMDAwMDU0NjIgIG1mbjogMDAwMDU0NjINCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MTRdICAgZ2ZuOiAwMDAwNTQ2MyAgbWZuOiAwMDAw
NTQ2Mw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoxNF0gICBnZm46IDAwMDA1NDY0ICBt
Zm46IDAwMDA1NDY0DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjE0XSAgIGdmbjogMDAw
MDU0NjUgIG1mbjogMDAwMDU0NjUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MTRdICAg
Z2ZuOiAwMDAwNTQ2NiAgbWZuOiAwMDAwNTQ2Ng0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
MzoxNF0gICBnZm46IDAwMDA1NDY3ICBtZm46IDAwMDA1NDY3DQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMzOjE0XSAgIGdmbjogMDAwMDU0NjggIG1mbjogMDAwMDU0NjgNCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzM6MTRdICAgZ2ZuOiAwMDAwNTQ2OSAgbWZuOiAwMDAwNTQ2OQ0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoxNF0gICBnZm46IDAwMDA1NDZhICBtZm46IDAw
MDA1NDZhDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjE0XSAgIGdmbjogMDAwMDU0NmIg
IG1mbjogMDAwMDU0NmINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MTRdICAgZ2ZuOiAw
MDAwNTQ2YyAgbWZuOiAwMDAwNTQ2Yw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoxNF0g
ICBnZm46IDAwMDA1NDZkICBtZm46IDAwMDA1NDZkDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMzOjE0XSAgIGdmbjogMDAwMDU0NmUgIG1mbjogMDAwMDU0NmUNCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzM6MTVdICAgZ2ZuOiAwMDAwNTQ2ZiAgbWZuOiAwMDAwNTQ2Zg0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMzoxNV0gICBnZm46IDAwMDA1NDcwICBtZm46IDAwMDA1NDcw
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjE1XSAgIGdmbjogMDAwMDU0NzEgIG1mbjog
MDAwMDU0NzENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MTVdICAgZ2ZuOiAwMDAwNTQ3
MiAgbWZuOiAwMDAwNTQ3Mg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoxNV0gICBnZm46
IDAwMDA1NDczICBtZm46IDAwMDA1NDczDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjE1
XSAgIGdmbjogMDAwMDU0NzQgIG1mbjogMDAwMDU0NzQNCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzM6MTVdICAgZ2ZuOiAwMDAwNTQ3NSAgbWZuOiAwMDAwNTQ3NQ0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMzoxNV0gICBnZm46IDAwMDA1NDc2ICBtZm46IDAwMDA1NDc2DQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMzOjE1XSAgIGdmbjogMDAwMDU0NzcgIG1mbjogMDAwMDU0
NzcNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MTVdICAgZ2ZuOiAwMDAwNTQ3OCAgbWZu
OiAwMDAwNTQ3OA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoxNV0gICBnZm46IDAwMDA1
NDc5ICBtZm46IDAwMDA1NDc5DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjE1XSAgIGdm
bjogMDAwMDU0N2EgIG1mbjogMDAwMDU0N2ENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6
MTVdICAgZ2ZuOiAwMDAwNTQ3YiAgbWZuOiAwMDAwNTQ3Yg0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMzoxNV0gICBnZm46IDAwMDA1NDdjICBtZm46IDAwMDA1NDdjDQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMzOjE1XSAgIGdmbjogMDAwMDU0N2QgIG1mbjogMDAwMDU0N2QNCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MTVdICAgZ2ZuOiAwMDAwNTQ3ZSAgbWZuOiAwMDAw
NTQ3ZQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoxNV0gICBnZm46IDAwMDA1NDdmICBt
Zm46IDAwMDA1NDdmDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjE1XSAgIGdmbjogMDAw
MDU0ODAgIG1mbjogMDAwMDU0ODANCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MTVdICAg
Z2ZuOiAwMDAwNTQ4MSAgbWZuOiAwMDAwNTQ4MQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
MzoxNV0gICBnZm46IDAwMDA1NDgyICBtZm46IDAwMDA1NDgyDQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMzOjE1XSAgIGdmbjogMDAwMDU0ODMgIG1mbjogMDAwMDU0ODMNCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzM6MTVdICAgZ2ZuOiAwMDAwNTQ4NCAgbWZuOiAwMDAwNTQ4NA0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoxNV0gICBnZm46IDAwMDA1NDg1ICBtZm46IDAw
MDA1NDg1DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjE1XSAgIGdmbjogMDAwMDU0ODYg
IG1mbjogMDAwMDU0ODYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MTVdICAgZ2ZuOiAw
MDAwNTQ4NyAgbWZuOiAwMDAwNTQ4Nw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoxNV0g
ICBnZm46IDAwMDA1NDg4ICBtZm46IDAwMDA1NDg4DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMzOjE1XSAgIGdmbjogMDAwMDU0ODkgIG1mbjogMDAwMDU0ODkNCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzM6MTVdICAgZ2ZuOiAwMDAwNTQ4YSAgbWZuOiAwMDAwNTQ4YQ0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMzoxNV0gICBnZm46IDAwMDA1NDhiICBtZm46IDAwMDA1NDhi
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjE1XSAgIGdmbjogMDAwMDU0OGMgIG1mbjog
MDAwMDU0OGMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MTVdICAgZ2ZuOiAwMDAwNTQ4
ZCAgbWZuOiAwMDAwNTQ4ZA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoxNV0gICBnZm46
IDAwMDA1NDhlICBtZm46IDAwMDA1NDhlDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjE1
XSAgIGdmbjogMDAwMDU0OGYgIG1mbjogMDAwMDU0OGYNCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzM6MTVdICAgZ2ZuOiAwMDAwNTQ5MCAgbWZuOiAwMDAwNTQ5MA0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMzoxNV0gICBnZm46IDAwMDA1NDkxICBtZm46IDAwMDA1NDkxDQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMzOjE1XSAgIGdmbjogMDAwMDU0OTIgIG1mbjogMDAwMDU0
OTINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MTVdICAgZ2ZuOiAwMDAwNTQ5MyAgbWZu
OiAwMDAwNTQ5Mw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoxNV0gICBnZm46IDAwMDA1
NDk0ICBtZm46IDAwMDA1NDk0DQoNClsgIDQ2MS41NTkwMzBdIGEoWEVOKSBbMjAxMi0wOC0z
MSAyMTozMzoxNV0gICBnZm46IDAwMDA1NDk1ICBtZm46IDAwMDA1NDk1DQoNCnRhMS4wMDog
cWMgdGltZW8oWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoxNV0gICBnZm46IDAwMDA1NDk2ICBt
Zm46IDAwMDA1NDk2DQoNCnV0IChjbWQgMHhlYykNCg0KDQooWEVOKSBbMjAxMi0wOC0zMSAy
MTozMzoxNV0gICBnZm46IDAwMDA1NDk3ICBtZm46IDAwMDA1NDk3DQoNClsgIDQ2MS42MzM3
MzJdIGEoWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoxNV0gICBnZm46IDAwMDA1NDk4ICBtZm46
IDAwMDA1NDk4DQoNCnRhMS4wMDogZmFpbGVkIHQoWEVOKSBbMjAxMi0wOC0zMSAyMTozMzox
NV0gICBnZm46IDAwMDA1NDk5ICBtZm46IDAwMDA1NDk5DQoNCm8gSURFTlRJRlkgKEkvTyBl
cnJvciwgZXJyX21hc2s9KFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MTVdICAgZ2ZuOiAwMDAw
NTQ5YSAgbWZuOiAwMDAwNTQ5YQ0KDQoweDQpDQoNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6
MzM6MTVdICAgZ2ZuOiAwMDAwNTQ5YiAgbWZuOiAwMDAwNTQ5Yg0KDQpbICA0NjEuNzE2ODk1
XSBhdGExLjAwOiByZXZhbGlkYShYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjE1XSAgIGdmbjog
MDAwMDU0OWMgIG1mbjogMDAwMDU0OWMNCg0KdGlvbiBmYWlsZWQgKGVycihYRU4pIFsyMDEy
LTA4LTMxIDIxOjMzOjE1XSAgIGdmbjogMDAwMDU0OWQgIG1mbjogMDAwMDU0OWQNCg0Kbm89
LTUpDQoNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MTVdICAgZ2ZuOiAwMDAwNTQ5ZSAg
bWZuOiAwMDAwNTQ5ZQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoxNV0gICBnZm46IDAw
MDA1NDlmICBtZm46IDAwMDA1NDlmDQoNClsgIDQ2MS43NzkzNDRdIGEoWEVOKSBbMjAxMi0w
OC0zMSAyMTozMzoxNV0gICBnZm46IDAwMDA1NGEwICBtZm46IDAwMDA1NGEwDQoNCnRhMS4w
MDogZGlzYWJsZWQoWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoxNV0gICBnZm46IDAwMDA1NGEx
ICBtZm46IDAwMDA1NGExDQoNCg0KDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjE1XSAg
IGdmbjogMDAwMDU0YTIgIG1mbjogMDAwMDU0YTINCg0KWyAgNDYxLjg1MDA3OF0gYShYRU4p
IFsyMDEyLTA4LTMxIDIxOjMzOjE1XSAgIGdmbjogMDAwMDU0YTMgIG1mbjogMDAwMDU0YTMN
Cg0KdGExLjAwOiBkZXZpY2UgcihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjE1XSAgIGdmbjog
MDAwMDU0YTQgIG1mbjogMDAwMDU0YTQNCg0KZXBvcnRlZCBpbnZhbGlkIChYRU4pIFsyMDEy
LTA4LTMxIDIxOjMzOjE1XSAgIGdmbjogMDAwMDU0YTUgIG1mbjogMDAwMDU0YTUNCg0KQ0hT
IHNlY3RvciAwDQoNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MTVdICAgZ2ZuOiAwMDAw
NTRhNiAgbWZuOiAwMDAwNTRhNg0KDQpbICA0NjEuOTI5MTUwXSBhKFhFTikgWzIwMTItMDgt
MzEgMjE6MzM6MTVdICAgZ2ZuOiAwMDAwNTRhNyAgbWZuOiAwMDAwNTRhNw0KDQp0YTE6IGhh
cmQgcmVzZXR0aW5nIGxpbmsNCg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoxNV0gICBn
Zm46IDAwMDA1NGE4ICBtZm46IDAwMDA1NGE4DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMz
OjE1XSAgIGdmbjogMDAwMDU0YTkgIG1mbjogMDAwMDU0YTkNCg0KKFhFTikgWzIwMTItMDgt
MzEgMjE6MzM6MTZdICAgZ2ZuOiAwMDAwNTRhYSAgbWZuOiAwMDAwNTRhYQ0KDQooWEVOKSBb
MjAxMi0wOC0zMSAyMTozMzoxNl0gICBnZm46IDAwMDA1NGFiICBtZm46IDAwMDA1NGFiDQoN
CihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjE2XSAgIGdmbjogMDAwMDU0YWMgIG1mbjogMDAw
MDU0YWMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MTZdICAgZ2ZuOiAwMDAwNTRhZCAg
bWZuOiAwMDAwNTRhZA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoxNl0gICBnZm46IDAw
MDA1NGFlICBtZm46IDAwMDA1NGFlDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjE2XSAg
IGdmbjogMDAwMDU0YWYgIG1mbjogMDAwMDU0YWYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6
MzM6MTZdICAgZ2ZuOiAwMDAwNTRiMCAgbWZuOiAwMDAwNTRiMA0KDQooWEVOKSBbMjAxMi0w
OC0zMSAyMTozMzoxNl0gICBnZm46IDAwMDA1NGIxICBtZm46IDAwMDA1NGIxDQoNCihYRU4p
IFsyMDEyLTA4LTMxIDIxOjMzOjE2XSAgIGdmbjogMDAwMDU0YjIgIG1mbjogMDAwMDU0YjIN
Cg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MTZdICAgZ2ZuOiAwMDAwNTRiMyAgbWZuOiAw
MDAwNTRiMw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoxNl0gICBnZm46IDAwMDA1NGI0
ICBtZm46IDAwMDA1NGI0DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjE2XSAgIGdmbjog
MDAwMDU0YjUgIG1mbjogMDAwMDU0YjUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MTZd
ICAgZ2ZuOiAwMDAwNTRiNiAgbWZuOiAwMDAwNTRiNg0KDQooWEVOKSBbMjAxMi0wOC0zMSAy
MTozMzoxNl0gICBnZm46IDAwMDA1NGI3ICBtZm46IDAwMDA1NGI3DQoNCihYRU4pIFsyMDEy
LTA4LTMxIDIxOjMzOjE2XSAgIGdmbjogMDAwMDU0YjggIG1mbjogMDAwMDU0YjgNCg0KKFhF
TikgWzIwMTItMDgtMzEgMjE6MzM6MTZdICAgZ2ZuOiAwMDAwNTRiOSAgbWZuOiAwMDAwNTRi
OQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoxNl0gICBnZm46IDAwMDA1NGJhICBtZm46
IDAwMDA1NGJhDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjE2XSAgIGdmbjogMDAwMDU0
YmIgIG1mbjogMDAwMDU0YmINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MTZdICAgZ2Zu
OiAwMDAwNTRiYyAgbWZuOiAwMDAwNTRiYw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzox
Nl0gICBnZm46IDAwMDA1NGJkICBtZm46IDAwMDA1NGJkDQoNCihYRU4pIFsyMDEyLTA4LTMx
IDIxOjMzOjE2XSAgIGdmbjogMDAwMDU0YmUgIG1mbjogMDAwMDU0YmUNCg0KKFhFTikgWzIw
MTItMDgtMzEgMjE6MzM6MTZdICAgZ2ZuOiAwMDAwNTRiZiAgbWZuOiAwMDAwNTRiZg0KDQoo
WEVOKSBbMjAxMi0wOC0zMSAyMTozMzoxNl0gICBnZm46IDAwMDA1NGMwICBtZm46IDAwMDA1
NGMwDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjE2XSAgIGdmbjogMDAwMDU0YzEgIG1m
bjogMDAwMDU0YzENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MTZdICAgZ2ZuOiAwMDAw
NTRjMiAgbWZuOiAwMDAwNTRjMg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoxNl0gICBn
Zm46IDAwMDA1NGMzICBtZm46IDAwMDA1NGMzDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMz
OjE2XSAgIGdmbjogMDAwMDU0YzQgIG1mbjogMDAwMDU0YzQNCg0KKFhFTikgWzIwMTItMDgt
MzEgMjE6MzM6MTZdICAgZ2ZuOiAwMDAwNTRjNSAgbWZuOiAwMDAwNTRjNQ0KDQooWEVOKSBb
MjAxMi0wOC0zMSAyMTozMzoxNl0gICBnZm46IDAwMDA1NGM2ICBtZm46IDAwMDA1NGM2DQoN
CihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjE2XSAgIGdmbjogMDAwMDU0YzcgIG1mbjogMDAw
MDU0YzcNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MTZdICAgZ2ZuOiAwMDAwNTRjOCAg
bWZuOiAwMDAwNTRjOA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoxNl0gICBnZm46IDAw
MDA1NGM5ICBtZm46IDAwMDA1NGM5DQoNClsgIDQ2Mi40ODY4MDVdIGEoWEVOKSBbMjAxMi0w
OC0zMSAyMTozMzoxNl0gICBnZm46IDAwMDA1NGNhICBtZm46IDAwMDA1NGNhDQoNCnRhMTog
U0FUQSBsaW5rIHUoWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoxNl0gICBnZm46IDAwMDA1NGNi
ICBtZm46IDAwMDA1NGNiDQoNCnAgMS41IEdicHMgKFNTdGEoWEVOKSBbMjAxMi0wOC0zMSAy
MTozMzoxNl0gICBnZm46IDAwMDA1NGNjICBtZm46IDAwMDA1NGNjDQoNCnR1cyAxMTMgU0Nv
bnRyb2woWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoxNl0gICBnZm46IDAwMDA1NGNkICBtZm46
IDAwMDA1NGNkDQoNCiAzMTApDQoNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MTZdICAg
Z2ZuOiAwMDAwNTRjZSAgbWZuOiAwMDAwNTRjZQ0KDQpbICA0NjIuNTgyMjMwXSBzKFhFTikg
WzIwMTItMDgtMzEgMjE6MzM6MTZdICAgZ2ZuOiAwMDAwNTRjZiAgbWZuOiAwMDAwNTRjZg0K
DQpkIDA6MDowOjA6IFtzZGFdKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MTZdICAgZ2ZuOiAw
MDAwNTRkMCAgbWZuOiAwMDAwNTRkMA0KDQogIA0KDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMzOjE2XSAgIGdmbjogMDAwMDU0ZDEgIG1mbjogMDAwMDU0ZDENCg0KWyAgNDYyLjY0MDM5
Ml0gUmVzdWx0OiBob3N0Ynl0ZT0oWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoxNl0gICBnZm46
IDAwMDA1NGQyICBtZm46IDAwMDA1NGQyDQoNCkRJRF9PSyBkcml2ZXJieXQoWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMzoxNl0gICBnZm46IDAwMDA1NGQzICBtZm46IDAwMDA1NGQzDQoNCmU9
RFJJVkVSX1NFTlNFDQoNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MTZdICAgZ2ZuOiAw
MDAwNTRkNCAgbWZuOiAwMDAwNTRkNA0KDQpbICA0NjIuNzAyODQ1XSBzKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzM6MTZdICAgZ2ZuOiAwMDAwNTRkNSAgbWZuOiAwMDAwNTRkNQ0KDQpkIDA6
MDowOjA6IFtzZGFdKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MTZdICAgZ2ZuOiAwMDAwNTRk
NiAgbWZuOiAwMDAwNTRkNg0KDQogIA0KDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjE2
XSAgIGdmbjogMDAwMDU0ZDcgIG1mbjogMDAwMDU0ZDcNCg0KWyAgNDYyLjc1NjkyOF0gUyhY
RU4pIFsyMDEyLTA4LTMxIDIxOjMzOjE2XSAgIGdmbjogMDAwMDU0ZDggIG1mbjogMDAwMDU0
ZDgNCg0KZW5zZSBLZXkgOiBBYm9ydChYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjE2XSAgIGdm
bjogMDAwMDU0ZDkgIG1mbjogMDAwMDU0ZDkNCg0KZWQgQ29tbWFuZCAoWEVOKSBbMjAxMi0w
OC0zMSAyMTozMzoxNl0gICBnZm46IDAwMDA1NGRhICBtZm46IDAwMDA1NGRhDQoNCltjdXJy
ZW50XSAoWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoxNl0gICBnZm46IDAwMDA1NGRiICBtZm46
IDAwMDA1NGRiDQoNCltkZXNjcmlwdG9yXShYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjE2XSAg
IGdmbjogMDAwMDU0ZGMgIG1mbjogMDAwMDU0ZGMNCg0KDQoNCg0KKFhFTikgWzIwMTItMDgt
MzEgMjE6MzM6MTZdICAgZ2ZuOiAwMDAwNTRkZCAgbWZuOiAwMDAwNTRkZA0KDQpbICA0NjIu
ODY5MTk4XSBEKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MTZdICAgZ2ZuOiAwMDAwNTRkZSAg
bWZuOiAwMDAwNTRkZQ0KDQplc2NyaXB0b3Igc2Vuc2UgKFhFTikgWzIwMTItMDgtMzEgMjE6
MzM6MTZdICAgZ2ZuOiAwMDAwNTRkZiAgbWZuOiAwMDAwNTRkZg0KDQpkYXRhIHdpdGggc2Vu
c2UgZGVzY3JpcHRvcnMgKGluIChYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjE2XSAgIGdmbjog
MDAwMDU0ZTAgIG1mbjogMDAwMDU0ZTANCg0KaGV4KTooWEVOKSBbMjAxMi0wOC0zMSAyMToz
MzoxNl0gICBnZm46IDAwMDA1NGUxICBtZm46IDAwMDA1NGUxDQoNCg0KDQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMzOjE2XSAgIGdmbjogMDAwMDU0ZTIgIG1mbjogMDAwMDU0ZTINCg0K
WyAgNDYyLjk2NDg1NF0gIChYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjE2XSAgIGdmbjogMDAw
MDU0ZTMgIG1mbjogMDAwMDU0ZTMNCg0KICAgICAgIChYRU4pIFsyMDEyLTA4LTMxIDIxOjMz
OjE3XSAgIGdmbjogMDAwMDU0ZTQgIG1mbjogMDAwMDU0ZTQNCg0KNzIgKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzM6MTddICAgZ2ZuOiAwMDAwNTRlNSAgbWZuOiAwMDAwNTRlNQ0KDQowYiAw
MCAwMCAoWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoxN10gICBnZm46IDAwMDA1NGU2ICBtZm46
IDAwMDA1NGU2DQoNCjAwIChYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjE3XSAgIGdmbjogMDAw
MDU0ZTcgIG1mbjogMDAwMDU0ZTcNCg0KMDAgKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MTdd
ICAgZ2ZuOiAwMDAwNTRlOCAgbWZuOiAwMDAwNTRlOA0KDQowMCAoWEVOKSBbMjAxMi0wOC0z
MSAyMTozMzoxN10gICBnZm46IDAwMDA1NGU5ICBtZm46IDAwMDA1NGU5DQoNCjBjIChYRU4p
IFsyMDEyLTA4LTMxIDIxOjMzOjE3XSAgIGdmbjogMDAwMDU0ZWEgIG1mbjogMDAwMDU0ZWEN
Cg0KMDAgKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MTddICAgZ2ZuOiAwMDAwNTRlYiAgbWZu
OiAwMDAwNTRlYg0KDQowYSAoWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoxN10gICBnZm46IDAw
MDA1NGVjICBtZm46IDAwMDA1NGVjDQoNCjgwIChYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjE3
XSAgIGdmbjogMDAwMDU0ZWQgIG1mbjogMDAwMDU0ZWQNCg0KMDAgMDAgMDAgKFhFTikgWzIw
MTItMDgtMzEgMjE6MzM6MTddICAgZ2ZuOiAwMDAwNTRlZSAgbWZuOiAwMDAwNTRlZQ0KDQow
MCAoWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoxN10gICBnZm46IDAwMDA1NGVmICBtZm46IDAw
MDA1NGVmDQoNCjAwIChYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjE3XSAgIGdmbjogMDAwMDU0
ZjAgIG1mbjogMDAwMDU0ZjANCg0KDQoNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MTdd
ICAgZ2ZuOiAwMDAwNTRmMSAgbWZuOiAwMDAwNTRmMQ0KDQpbICA0NjMuMjE4NTk3XSAgKFhF
TikgWzIwMTItMDgtMzEgMjE6MzM6MTddICAgZ2ZuOiAwMDAwNTRmMiAgbWZuOiAwMDAwNTRm
Mg0KDQogICAgICAgKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MTddICAgZ2ZuOiAwMDAwNTRm
MyAgbWZuOiAwMDAwNTRmMw0KDQowMCAwMCAwMCAoWEVOKSBbMjAxMi0wOC0zMSAyMTozMzox
N10gICBnZm46IDAwMDA1NGY0ICBtZm46IDAwMDA1NGY0DQoNCjAwIChYRU4pIFsyMDEyLTA4
LTMxIDIxOjMzOjE3XSAgIGdmbjogMDAwMDU0ZjUgIG1mbjogMDAwMDU0ZjUNCg0KDQoNCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MTddICAgZ2ZuOiAwMDAwNTRmNiAgbWZuOiAwMDAw
NTRmNg0KDQpbICA0NjMuMzA1OTg3XSBzKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MTddICAg
Z2ZuOiAwMDAwNTRmNyAgbWZuOiAwMDAwNTRmNw0KDQpkIDA6MDowOjA6IFtzZGFdKFhFTikg
WzIwMTItMDgtMzEgMjE6MzM6MTddICAgZ2ZuOiAwMDAwNTRmOCAgbWZuOiAwMDAwNTRmOA0K
DQogIA0KDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjE3XSAgIGdmbjogMDAwMDU0Zjkg
IG1mbjogMDAwMDU0ZjkNCg0KWyAgNDYzLjM2NDIyMl0gQShYRU4pIFsyMDEyLTA4LTMxIDIx
OjMzOjE3XSAgIGdmbjogMDAwMDU0ZmEgIG1mbjogMDAwMDU0ZmENCg0KZGQuIFNlbnNlOiBO
byBhZChYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjE3XSAgIGdmbjogMDAwMDU0ZmIgIG1mbjog
MDAwMDU0ZmINCg0KZGl0aW9uYWwgc2Vuc2UgaShYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjE3
XSAgIGdmbjogMDAwMDU0ZmMgIG1mbjogMDAwMDU0ZmMNCg0KbmZvcm1hdGlvbihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMzOjE3XSAgIGdmbjogMDAwMDU0ZmQgIG1mbjogMDAwMDU0ZmQNCg0K
DQoNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MTddICAgZ2ZuOiAwMDAwNTRmZSAgbWZu
OiAwMDAwNTRmZQ0KDQpbICA0NjMuNDU5ODY2XSBzKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6
MTddICAgZ2ZuOiAwMDAwNTRmZiAgbWZuOiAwMDAwNTRmZg0KDQpkIDA6MDowOjA6IFtzZGFd
KFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MTddICAgZ2ZuOiAwMDAwNTUwMCAgbWZuOiAwMDAw
NTUwMA0KDQogQ0RCOiANCg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoxN10gICBnZm46
IDAwMDA1NTAxICBtZm46IDAwMDA1NTAxDQoNClsgIDQ2My41MTM5NzZdIFIoWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMzoxN10gICBnZm46IDAwMDA1NTAyICBtZm46IDAwMDA1NTAyDQoNCmVh
ZCgxMCkoWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoxN10gICBnZm46IDAwMDA1NTAzICBtZm46
IDAwMDA1NTAzDQoNCjooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoxN10gICBnZm46IDAwMDA1
NTA0ICBtZm46IDAwMDA1NTA0DQoNCiAyOChYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjE3XSAg
IGdmbjogMDAwMDU1MDUgIG1mbjogMDAwMDU1MDUNCg0KIDAwKFhFTikgWzIwMTItMDgtMzEg
MjE6MzM6MTddICAgZ2ZuOiAwMDAwNTUwNiAgbWZuOiAwMDAwNTUwNg0KDQogOGUoWEVOKSBb
MjAxMi0wOC0zMSAyMTozMzoxN10gICBnZm46IDAwMDA1NTA3ICBtZm46IDAwMDA1NTA3DQoN
CiA5NShYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjE3XSAgIGdmbjogMDAwMDU1MDggIG1mbjog
MDAwMDU1MDgNCg0KIDExKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MTddICAgZ2ZuOiAwMDAw
NTUwOSAgbWZuOiAwMDAwNTUwOQ0KDQogNTEoWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoxN10g
ICBnZm46IDAwMDA1NTBhICBtZm46IDAwMDA1NTBhDQoNCiAwMChYRU4pIFsyMDEyLTA4LTMx
IDIxOjMzOjE3XSAgIGdmbjogMDAwMDU1MGIgIG1mbjogMDAwMDU1MGINCg0KIDAwKFhFTikg
WzIwMTItMDgtMzEgMjE6MzM6MTddICAgZ2ZuOiAwMDAwNTUwYyAgbWZuOiAwMDAwNTUwYw0K
DQogMTAoWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoxN10gICBnZm46IDAwMDA1NTBkICBtZm46
IDAwMDA1NTBkDQoNCiAwMChYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjE3XSAgIGdmbjogMDAw
MDU1MGUgIG1mbjogMDAwMDU1MGUNCg0KDQoNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6
MTddICAgZ2ZuOiAwMDAwNTUwZiAgbWZuOiAwMDAwNTUwZg0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMzoxN10gICBnZm46IDAwMDA1NTEwICBtZm46IDAwMDA1NTEwDQoNClsgIDQ2My43
NjM2NjJdIGUoWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoxN10gICBnZm46IDAwMDA1NTExICBt
Zm46IDAwMDA1NTExDQoNCm5kX3JlcXVlc3Q6IEkvTyAoWEVOKSBbMjAxMi0wOC0zMSAyMToz
MzoxN10gICBnZm46IDAwMDA1NTEyICBtZm46IDAwMDA1NTEyDQoNCmVycm9yLCBkZXYgc2Rh
LCAoWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoxN10gICBnZm46IDAwMDA1NTEzICBtZm46IDAw
MDA1NTEzDQoNCnNlY3RvciAyMzkyMTMzOTYoWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoxN10g
ICBnZm46IDAwMDA1NTE0ICBtZm46IDAwMDA1NTE0DQoNCjkNCg0KDQooWEVOKSBbMjAxMi0w
OC0zMSAyMTozMzoxN10gICBnZm46IDAwMDA1NTE1ICBtZm46IDAwMDA1NTE1DQoNClsgIDQ2
My44NTk0MTBdIGEoWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoxN10gICBnZm46IDAwMDA1NTE2
ICBtZm46IDAwMDA1NTE2DQoNCnRhMTogRUggY29tcGxldGUoWEVOKSBbMjAxMi0wOC0zMSAy
MTozMzoxN10gICBnZm46IDAwMDA1NTE3ICBtZm46IDAwMDA1NTE3DQoNCg0KDQoNCihYRU4p
IFsyMDEyLTA4LTMxIDIxOjMzOjE3XSAgIGdmbjogMDAwMDU1MTggIG1mbjogMDAwMDU1MTgN
Cg0KWyAgNDYzLjkxNzU5MV0gcyhYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjE3XSAgIGdmbjog
MDAwMDU1MTkgIG1mbjogMDAwMDU1MTkNCg0KZCAwOjA6MDowOiBbc2RhXShYRU4pIFsyMDEy
LTA4LTMxIDIxOjMzOjE3XSAgIGdmbjogMDAwMDU1MWEgIG1mbjogMDAwMDU1MWENCg0KIFVu
aGFuZGxlZCBlcnJvcihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjE3XSAgIGdmbjogMDAwMDU1
MWIgIG1mbjogMDAwMDU1MWINCg0KIGNvZGUNCg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
MzoxN10gICBnZm46IDAwMDA1NTFjICBtZm46IDAwMDA1NTFjDQoNClsgIDQ2My45MjE4MDBd
IHMoWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoxOF0gICBnZm46IDAwMDA1NTFkICBtZm46IDAw
MDA1NTFkDQoNCmQgMDowOjA6MDogW3NkYV0oWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoxOF0g
ICBnZm46IDAwMDA1NTFlICBtZm46IDAwMDA1NTFlDQoNCiBVbmhhbmRsZWQgZXJyb3IoWEVO
KSBbMjAxMi0wOC0zMSAyMTozMzoxOF0gICBnZm46IDAwMDA1NTFmICBtZm46IDAwMDA1NTFm
DQoNCiBjb2RlDQoNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MThdICAgZ2ZuOiAwMDAw
NTUyMCAgbWZuOiAwMDAwNTUyMA0KDQpbICA0NjMuOTIxODAyXSBzKFhFTikgWzIwMTItMDgt
MzEgMjE6MzM6MThdICAgZ2ZuOiAwMDAwNTUyMSAgbWZuOiAwMDAwNTUyMQ0KDQpkIDA6MDow
OjA6IFtzZGFdKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MThdICAgZ2ZuOiAwMDAwNTUyMiAg
bWZuOiAwMDAwNTUyMg0KDQogIA0KDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjE4XSAg
IGdmbjogMDAwMDU1MjMgIG1mbjogMDAwMDU1MjMNCg0KWyAgNDYzLjkyMTgwM10gUmVzdWx0
OiBob3N0Ynl0ZT0oWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoxOF0gICBnZm46IDAwMDA1NTI0
ICBtZm46IDAwMDA1NTI0DQoNCkRJRF9CQURfVEFSR0VUIGQoWEVOKSBbMjAxMi0wOC0zMSAy
MTozMzoxOF0gICBnZm46IDAwMDA1NTI1ICBtZm46IDAwMDA1NTI1DQoNCnJpdmVyYnl0ZT1E
UklWRVJfT0sNCg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoxOF0gICBnZm46IDAwMDA1
NTI2ICBtZm46IDAwMDA1NTI2DQoNClsgIDQ2My45MjE4MDRdIHMoWEVOKSBbMjAxMi0wOC0z
MSAyMTozMzoxOF0gICBnZm46IDAwMDA1NTI3ICBtZm46IDAwMDA1NTI3DQoNCmQgMDowOjA6
MDogW3NkYV0gQ0RCOiANCg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoxOF0gICBnZm46
IDAwMDA1NTI4ICBtZm46IDAwMDA1NTI4DQoNClsgIDQ2My45MjE4MDldIFcoWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMzoxOF0gICBnZm46IDAwMDA1NTI5ICBtZm46IDAwMDA1NTI5DQoNCnJp
dGUoMTApOiAyYSAwMCAwMSAyYSBhZCBjMSAwMCAwKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6
MThdICAgZ2ZuOiAwMDAwNTUyYSAgbWZuOiAwMDAwNTUyYQ0KDQowIDEwIDAwDQoNCg0KKFhF
TikgWzIwMTItMDgtMzEgMjE6MzM6MThdICAgZ2ZuOiAwMDAwNTUyYiAgbWZuOiAwMDAwNTUy
Yg0KDQpbICA0NjMuOTIxODEwXSBlbmRfcmVxdWVzdDogSS9PIChYRU4pIFsyMDEyLTA4LTMx
IDIxOjMzOjE4XSAgIGdmbjogMDAwMDU1MmMgIG1mbjogMDAwMDU1MmMNCg0KZXJyb3IsIGRl
diBzZGEsIChYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjE4XSAgIGdmbjogMDAwMDU1MmQgIG1m
bjogMDAwMDU1MmQNCg0Kc2VjdG9yIDE5NTc0MjA5DQoNCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzM6MThdICAgZ2ZuOiAwMDAwNTUyZSAgbWZuOiAwMDAwNTUyZQ0KDQpbICA0NjMuOTIx
ODUzXSBzKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MThdICAgZ2ZuOiAwMDAwNTUyZiAgbWZu
OiAwMDAwNTUyZg0KDQpkIDA6MDowOjA6IFtzZGFdIFVuaGFuZGxlZCBlcnJvcihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMzOjE4XSAgIGdmbjogMDAwMDU1MzAgIG1mbjogMDAwMDU1MzANCg0K
IGNvZGUNCg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoxOF0gICBnZm46IDAwMDA1NTMx
ICBtZm46IDAwMDA1NTMxDQoNClsgIDQ2My45MjE4NTRdIHNkIDA6MDowOjA6IFtzZGFdKFhF
TikgWzIwMTItMDgtMzEgMjE6MzM6MThdICAgZ2ZuOiAwMDAwNTUzMiAgbWZuOiAwMDAwNTUz
Mg0KDQogIA0KDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjE4XSAgIGdmbjogMDAwMDU1
MzMgIG1mbjogMDAwMDU1MzMNCg0KWyAgNDYzLjkyMTg1NF0gUmVzdWx0OiBob3N0Ynl0ZT0o
WEVOKSBbMjAxMi0wOC0zMSAyMTozMzoxOF0gICBnZm46IDAwMDA1NTM0ICBtZm46IDAwMDA1
NTM0DQoNCkRJRF9CQURfVEFSR0VUIGQoWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoxOF0gICBn
Zm46IDAwMDA1NTM1ICBtZm46IDAwMDA1NTM1DQoNCnJpdmVyYnl0ZT1EUklWRVJfT0sNCg0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoxOF0gICBnZm46IDAwMDA1NTM2ICBtZm46IDAw
MDA1NTM2DQoNClsgIDQ2My45MjE4NTVdIHMoWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoxOF0g
ICBnZm46IDAwMDA1NTM3ICBtZm46IDAwMDA1NTM3DQoNCmQgMDowOjA6MDogW3NkYV0gQ0RC
OiANCg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoxOF0gICBnZm46IDAwMDA1NTM4ICBt
Zm46IDAwMDA1NTM4DQoNClsgIDQ2My45MjE4NThdIFcoWEVOKSBbMjAxMi0wOC0zMSAyMToz
MzoxOF0gICBnZm46IDAwMDA1NTM5ICBtZm46IDAwMDA1NTM5DQoNCnJpdGUoMTApOiAyYSAw
MCAwMiAzZSA1NSAwMSAwMCAwMCAwOCAwMA0KDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMz
OjE4XSAgIGdmbjogMDAwMDU1M2EgIG1mbjogMDAwMDU1M2ENCg0KWyAgNDYzLjkyMTg1OV0g
ZShYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjE4XSAgIGdmbjogMDAwMDU1M2IgIG1mbjogMDAw
MDU1M2INCg0KbmRfcmVxdWVzdDogSS9PIChYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjE4XSAg
IGdmbjogMDAwMDU1M2MgIG1mbjogMDAwMDU1M2MNCg0KZXJyb3IsIGRldiBzZGEsIChYRU4p
IFsyMDEyLTA4LTMxIDIxOjMzOjE4XSAgIGdmbjogMDAwMDU1M2QgIG1mbjogMDAwMDU1M2QN
Cg0Kc2VjdG9yIDM3NjM5NDI1DQoNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MThdICAg
Z2ZuOiAwMDAwNTUzZSAgbWZuOiAwMDAwNTUzZQ0KDQpbICA0NjMuOTIxODY0XSBCKFhFTikg
WzIwMTItMDgtMzEgMjE6MzM6MThdICAgZ2ZuOiAwMDAwNTUzZiAgbWZuOiAwMDAwNTUzZg0K
DQp1ZmZlciBJL08gZXJyb3Igb24gZGV2aWNlIGRtLTAsIChYRU4pIFsyMDEyLTA4LTMxIDIx
OjMzOjE4XSAgIGdmbjogMDAwMDU1NDAgIG1mbjogMDAwMDU1NDANCg0KbG9naWNhbCBibG9j
ayAyMihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjE4XSAgIGdmbjogMDAwMDU1NDEgIG1mbjog
MDAwMDU1NDENCg0KNjA5OTINCg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoxOF0gICBn
Zm46IDAwMDA1NTQyICBtZm46IDAwMDA1NTQyDQoNClsgIDQ2My45MjE4NjRdIGwoWEVOKSBb
MjAxMi0wOC0zMSAyMTozMzoxOF0gICBnZm46IDAwMDA1NTQzICBtZm46IDAwMDA1NTQzDQoN
Cm9zdCBwYWdlIHdyaXRlIGQoWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoxOF0gICBnZm46IDAw
MDA1NTQ0ICBtZm46IDAwMDA1NTQ0DQoNCnVlIHRvIEkvTyBlcnJvciAoWEVOKSBbMjAxMi0w
OC0zMSAyMTozMzoxOF0gICBnZm46IDAwMDA1NTQ1ICBtZm46IDAwMDA1NTQ1DQoNCm9uIGRt
LTANCg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoxOF0gICBnZm46IDAwMDA1NTQ2ICBt
Zm46IDAwMDA1NTQ2DQoNClsgIDQ2My45MjE4NzhdIHMoWEVOKSBbMjAxMi0wOC0zMSAyMToz
MzoxOF0gICBnZm46IDAwMDA1NTQ3ICBtZm46IDAwMDA1NTQ3DQoNCmQgMDowOjA6MDogW3Nk
YV0oWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoxOF0gICBnZm46IDAwMDA1NTQ4ICBtZm46IDAw
MDA1NTQ4DQoNCiBVbmhhbmRsZWQgZXJyb3IoWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoxOF0g
ICBnZm46IDAwMDA1NTQ5ICBtZm46IDAwMDA1NTQ5DQoNCiBjb2RlDQoNCg0KKFhFTikgWzIw
MTItMDgtMzEgMjE6MzM6MThdICAgZ2ZuOiAwMDAwNTU0YSAgbWZuOiAwMDAwNTU0YQ0KDQpb
ICA0NjMuOTIxODc5XSBzKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MThdICAgZ2ZuOiAwMDAw
NTU0YiAgbWZuOiAwMDAwNTU0Yg0KDQpkIDA6MDowOjA6IFtzZGFdKFhFTikgWzIwMTItMDgt
MzEgMjE6MzM6MThdICAgZ2ZuOiAwMDAwNTU0YyAgbWZuOiAwMDAwNTU0Yw0KDQogIA0KDQoN
CihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjE4XSAgIGdmbjogMDAwMDU1NGQgIG1mbjogMDAw
MDU1NGQNCg0KWyAgNDYzLjkyMTg4MF0gUmVzdWx0OiBob3N0Ynl0ZT0oWEVOKSBbMjAxMi0w
OC0zMSAyMTozMzoxOV0gICBnZm46IDAwMDA1NTRlICBtZm46IDAwMDA1NTRlDQoNCkRJRF9C
QURfVEFSR0VUIGQoWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoxOV0gICBnZm46IDAwMDA1NTRm
ICBtZm46IDAwMDA1NTRmDQoNCnJpdmVyYnl0ZT1EUklWRVJfT0sNCg0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMzoxOV0gICBnZm46IDAwMDA1NTUwICBtZm46IDAwMDA1NTUwDQoNClsg
IDQ2My45MjE4ODFdIHMoWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoxOV0gICBnZm46IDAwMDA1
NTUxICBtZm46IDAwMDA1NTUxDQoNCmQgMDowOjA6MDogW3NkYV0gQ0RCOiANCg0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMzoxOV0gICBnZm46IDAwMDA1NTUyICBtZm46IDAwMDA1NTUy
DQoNClsgIDQ2My45MjE4ODRdIFcoWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoxOV0gICBnZm46
IDAwMDA1NTUzICBtZm46IDAwMDA1NTUzDQoNCnJpdGUoMTApOiAyYSAwMCAwNSAyZSA1NSA4
MSAwMCAwKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MTldICAgZ2ZuOiAwMDAwNTU1NCAgbWZu
OiAwMDAwNTU1NA0KDQowIDA4IDAwDQoNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MTld
ICAgZ2ZuOiAwMDAwNTU1NSAgbWZuOiAwMDAwNTU1NQ0KDQpbICA0NjMuOTIxODg0XSBlbmRf
cmVxdWVzdDogSS9PIChYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjE5XSAgIGdmbjogMDAwMDU1
NTYgIG1mbjogMDAwMDU1NTYNCg0KZXJyb3IsIGRldiBzZGEsIChYRU4pIFsyMDEyLTA4LTMx
IDIxOjMzOjE5XSAgIGdmbjogMDAwMDU1NTcgIG1mbjogMDAwMDU1NTcNCg0Kc2VjdG9yIDg2
OTIyNjI1DQoNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MTldICAgZ2ZuOiAwMDAwNTU1
OCAgbWZuOiAwMDAwNTU1OA0KDQpbICA0NjMuOTIxODg3XSBCKFhFTikgWzIwMTItMDgtMzEg
MjE6MzM6MTldICAgZ2ZuOiAwMDAwNTU1OSAgbWZuOiAwMDAwNTU1OQ0KDQp1ZmZlciBJL08g
ZXJyb3Igb24gZGV2aWNlIGRtLTAsIChYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjE5XSAgIGdm
bjogMDAwMDU1NWEgIG1mbjogMDAwMDU1NWENCg0KbG9naWNhbCBibG9jayA4NChYRU4pIFsy
MDEyLTA4LTMxIDIxOjMzOjE5XSAgIGdmbjogMDAwMDU1NWIgIG1mbjogMDAwMDU1NWINCg0K
MjEzOTINCg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoxOV0gICBnZm46IDAwMDA1NTVj
ICBtZm46IDAwMDA1NTVjDQoNClsgIDQ2My45MjE4ODddIGwoWEVOKSBbMjAxMi0wOC0zMSAy
MTozMzoxOV0gICBnZm46IDAwMDA1NTVkICBtZm46IDAwMDA1NTVkDQoNCm9zdCBwYWdlIHdy
aXRlIGQoWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoxOV0gICBnZm46IDAwMDA1NTVlICBtZm46
IDAwMDA1NTVlDQoNCnVlIHRvIEkvTyBlcnJvciAoWEVOKSBbMjAxMi0wOC0zMSAyMTozMzox
OV0gICBnZm46IDAwMDA1NTVmICBtZm46IDAwMDA1NTVmDQoNCm9uIGRtLTANCg0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMzoxOV0gICBnZm46IDAwMDA1NTYwICBtZm46IDAwMDA1NTYw
DQoNClsgIDQ2My45MjE4OTZdIHMoWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoxOV0gICBnZm46
IDAwMDA1NTYxICBtZm46IDAwMDA1NTYxDQoNCmQgMDowOjA6MDogW3NkYV0gVW5oYW5kbGVk
IGVycm9yKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MTldICAgZ2ZuOiAwMDAwNTU2MiAgbWZu
OiAwMDAwNTU2Mg0KDQogY29kZQ0KDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjE5XSAg
IGdmbjogMDAwMDU1NjMgIG1mbjogMDAwMDU1NjMNCg0KWyAgNDYzLjkyMTg5N10gcyhYRU4p
IFsyMDEyLTA4LTMxIDIxOjMzOjE5XSAgIGdmbjogMDAwMDU1NjQgIG1mbjogMDAwMDU1NjQN
Cg0KZCAwOjA6MDowOiBbc2RhXShYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjE5XSAgIGdmbjog
MDAwMDU1NjUgIG1mbjogMDAwMDU1NjUNCg0KICANCg0KDQooWEVOKSBbMjAxMi0wOC0zMSAy
MTozMzoxOV0gICBnZm46IDAwMDA1NTY2ICBtZm46IDAwMDA1NTY2DQoNClsgIDQ2My45MjE4
OTddIFIoWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoxOV0gICBnZm46IDAwMDA1NTY3ICBtZm46
IDAwMDA1NTY3DQoNCmVzdWx0OiBob3N0Ynl0ZT1ESURfQkFEX1RBUkdFVCBkKFhFTikgWzIw
MTItMDgtMzEgMjE6MzM6MTldICAgZ2ZuOiAwMDAwNTU2OCAgbWZuOiAwMDAwNTU2OA0KDQpy
aXZlcmJ5dGU9RFJJVkVSKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MTldICAgZ2ZuOiAwMDAw
NTU2OSAgbWZuOiAwMDAwNTU2OQ0KDQpfT0sNCg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
MzoxOV0gICBnZm46IDAwMDA1NTZhICBtZm46IDAwMDA1NTZhDQoNClsgIDQ2My45MjE4OThd
IHMoWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoxOV0gICBnZm46IDAwMDA1NTZiICBtZm46IDAw
MDA1NTZiDQoNCmQgMDowOjA6MDogW3NkYV0oWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoxOV0g
ICBnZm46IDAwMDA1NTZjICBtZm46IDAwMDA1NTZjDQoNCiBDREI6IA0KDQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMzOjE5XSAgIGdmbjogMDAwMDU1NmQgIG1mbjogMDAwMDU1NmQNCg0K
WyAgNDYzLjkyMTkwMV0gVyhYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjE5XSAgIGdmbjogMDAw
MDU1NmUgIG1mbjogMDAwMDU1NmUNCg0Kcml0ZSgxMCk6IDJhIDAwIChYRU4pIFsyMDEyLTA4
LTMxIDIxOjMzOjE5XSAgIGdmbjogMDAwMDU1NmYgIG1mbjogMDAwMDU1NmYNCg0KMDUgMmUg
NTcgNDEgMDAgMDAgMDggMDANCg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoxOV0gICBn
Zm46IDAwMDA1NTcwICBtZm46IDAwMDA1NTcwDQoNClsgIDQ2My45MjE5MDJdIGUoWEVOKSBb
MjAxMi0wOC0zMSAyMTozMzoxOV0gICBnZm46IDAwMDA1NTcxICBtZm46IDAwMDA1NTcxDQoN
Cm5kX3JlcXVlc3Q6IEkvTyBlcnJvciwgZGV2IHNkYSwgKFhFTikgWzIwMTItMDgtMzEgMjE6
MzM6MTldICAgZ2ZuOiAwMDAwNTU3MiAgbWZuOiAwMDAwNTU3Mg0KDQpzZWN0b3IgODY5MjMw
NzMNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjE5XSAgIGdmbjogMDAwMDU1NzMgIG1mbjog
MDAwMDU1NzMNCg0KDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjE5XSAgIGdmbjogMDAw
MDU1NzQgIG1mbjogMDAwMDU1NzQNCg0KWyAgNDYzLjkyMTkwNF0gQihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMzOjE5XSAgIGdmbjogMDAwMDU1NzUgIG1mbjogMDAwMDU1NzUNCg0KdWZmZXIg
SS9PIGVycm9yIChYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjE5XSAgIGdmbjogMDAwMDU1NzYg
IG1mbjogMDAwMDU1NzYNCg0Kb24gZGV2aWNlIGRtLTAsIChYRU4pIFsyMDEyLTA4LTMxIDIx
OjMzOjE5XSAgIGdmbjogMDAwMDU1NzcgIG1mbjogMDAwMDU1NzcNCg0KbG9naWNhbCBibG9j
ayA4NDIxNDQ4DQoNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MTldICAgZ2ZuOiAwMDAw
NTU3OCAgbWZuOiAwMDAwNTU3OA0KDQpbICA0NjMuOTIxOTA1XSBsKFhFTikgWzIwMTItMDgt
MzEgMjE6MzM6MTldICAgZ2ZuOiAwMDAwNTU3OSAgbWZuOiAwMDAwNTU3OQ0KDQpvc3QgcGFn
ZSB3cml0ZSBkdWUgdG8gSS9PIGVycm9yIChYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjE5XSAg
IGdmbjogMDAwMDU1N2EgIG1mbjogMDAwMDU1N2ENCg0Kb24gZG0tMA0KDQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMzOjE5XSAgIGdmbjogMDAwMDU1N2IgIG1mbjogMDAwMDU1N2INCg0K
WyAgNDYzLjkyMTkxNF0gc2QgMDowOjA6MDogW3NkYV0oWEVOKSBbMjAxMi0wOC0zMSAyMToz
MzoxOV0gICBnZm46IDAwMDA1NTdjICBtZm46IDAwMDA1NTdjDQoNCiBVbmhhbmRsZWQgZXJy
b3IoWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoxOV0gICBnZm46IDAwMDA1NTdkICBtZm46IDAw
MDA1NTdkDQoNCiBjb2RlDQoNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MTldICAgZ2Zu
OiAwMDAwNTU3ZSAgbWZuOiAwMDAwNTU3ZQ0KDQpbICA0NjMuOTIxOTE1XSBzKFhFTikgWzIw
MTItMDgtMzEgMjE6MzM6MjBdICAgZ2ZuOiAwMDAwNTU3ZiAgbWZuOiAwMDAwNTU3Zg0KDQpk
IDA6MDowOjA6IFtzZGFdICANCg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoyMF0gICBn
Zm46IDAwMDA1NTgwICBtZm46IDAwMDA1NTgwDQoNClsgIDQ2My45MjE5MTVdIFIoWEVOKSBb
MjAxMi0wOC0zMSAyMTozMzoyMF0gICBnZm46IDAwMDA1NTgxICBtZm46IDAwMDA1NTgxDQoN
CmVzdWx0OiBob3N0Ynl0ZT1ESURfQkFEX1RBUkdFVCBkKFhFTikgWzIwMTItMDgtMzEgMjE6
MzM6MjBdICAgZ2ZuOiAwMDAwNTU4MiAgbWZuOiAwMDAwNTU4Mg0KDQpyaXZlcmJ5dGU9RFJJ
VkVSKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MjBdICAgZ2ZuOiAwMDAwNTU4MyAgbWZuOiAw
MDAwNTU4Mw0KDQpfT0sNCg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoyMF0gICBnZm46
IDAwMDA1NTg0ICBtZm46IDAwMDA1NTg0DQoNClsgIDQ2My45MjE5MTZdIHMoWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMzoyMF0gICBnZm46IDAwMDA1NTg1ICBtZm46IDAwMDA1NTg1DQoNCmQg
MDowOjA6MDogW3NkYV0oWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoyMF0gICBnZm46IDAwMDA1
NTg2ICBtZm46IDAwMDA1NTg2DQoNCiBDREI6IA0KDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMzOjIwXSAgIGdmbjogMDAwMDU1ODcgIG1mbjogMDAwMDU1ODcNCg0KWyAgNDYzLjkyMTkx
OV0gV3JpdGUoMTApOiAyYSAwMCAoWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoyMF0gICBnZm46
IDAwMDA1NTg4ICBtZm46IDAwMDA1NTg4DQoNCjA1IDM2IDU1IDE5IDAwIDAoWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMzoyMF0gICBnZm46IDAwMDA1NTg5ICBtZm46IDAwMDA1NTg5DQoNCjAg
MDggMDANCg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoyMF0gICBnZm46IDAwMDA1NThh
ICBtZm46IDAwMDA1NThhDQoNClsgIDQ2My45MjE5MjBdIGUoWEVOKSBbMjAxMi0wOC0zMSAy
MTozMzoyMF0gICBnZm46IDAwMDA1NThiICBtZm46IDAwMDA1NThiDQoNCm5kX3JlcXVlc3Q6
IEkvTyBlcnJvciwgZGV2IHNkYSwgKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MjBdICAgZ2Zu
OiAwMDAwNTU4YyAgbWZuOiAwMDAwNTU4Yw0KDQpzZWN0b3IgODc0NDY4MDkNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMzOjIwXSAgIGdmbjogMDAwMDU1OGQgIG1mbjogMDAwMDU1OGQNCg0K
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjIwXSAgIGdmbjogMDAwMDU1OGUgIG1mbjog
MDAwMDU1OGUNCg0KWyAgNDYzLjkyMTkyMl0gQihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjIw
XSAgIGdmbjogMDAwMDU1OGYgIG1mbjogMDAwMDU1OGYNCg0KdWZmZXIgSS9PIGVycm9yIChY
RU4pIFsyMDEyLTA4LTMxIDIxOjMzOjIwXSAgIGdmbjogMDAwMDU1OTAgIG1mbjogMDAwMDU1
OTANCg0Kb24gZGV2aWNlIGRtLTAsIChYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjIwXSAgIGdm
bjogMDAwMDU1OTEgIG1mbjogMDAwMDU1OTENCg0KbG9naWNhbCBibG9jayA4NDg2OTE1DQoN
Cg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MjBdICAgZ2ZuOiAwMDAwNTU5MiAgbWZuOiAw
MDAwNTU5Mg0KDQpbICA0NjMuOTIxOTIzXSBsKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MjBd
ICAgZ2ZuOiAwMDAwNTU5MyAgbWZuOiAwMDAwNTU5Mw0KDQpvc3QgcGFnZSB3cml0ZSBkdWUg
dG8gSS9PIGVycm9yIChYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjIwXSAgIGdmbjogMDAwMDU1
OTQgIG1mbjogMDAwMDU1OTQNCg0Kb24gZG0tMA0KDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMzOjIwXSAgIGdmbjogMDAwMDU1OTUgIG1mbjogMDAwMDU1OTUNCg0KWyAgNDYzLjkyMTkz
MF0gcyhYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjIwXSAgIGdmbjogMDAwMDU1OTYgIG1mbjog
MDAwMDU1OTYNCg0KZCAwOjA6MDowOiBbc2RhXShYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjIw
XSAgIGdmbjogMDAwMDU1OTcgIG1mbjogMDAwMDU1OTcNCg0KIFVuaGFuZGxlZCBlcnJvciBj
b2RlDQoNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MjBdICAgZ2ZuOiAwMDAwNTU5OCAg
bWZuOiAwMDAwNTU5OA0KDQpbICA0NjMuOTIxOTMxXSBzKFhFTikgWzIwMTItMDgtMzEgMjE6
MzM6MjBdICAgZ2ZuOiAwMDAwNTU5OSAgbWZuOiAwMDAwNTU5OQ0KDQpkIDA6MDowOjA6IFtz
ZGFdICANCg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoyMF0gICBnZm46IDAwMDA1NTlh
ICBtZm46IDAwMDA1NTlhDQoNClsgIDQ2My45MjE5MzJdIFIoWEVOKSBbMjAxMi0wOC0zMSAy
MTozMzoyMF0gICBnZm46IDAwMDA1NTliICBtZm46IDAwMDA1NTliDQoNCmVzdWx0OiBob3N0
Ynl0ZT1ESURfQkFEX1RBUkdFVCBkKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MjBdICAgZ2Zu
OiAwMDAwNTU5YyAgbWZuOiAwMDAwNTU5Yw0KDQpyaXZlcmJ5dGU9RFJJVkVSKFhFTikgWzIw
MTItMDgtMzEgMjE6MzM6MjBdICAgZ2ZuOiAwMDAwNTU5ZCAgbWZuOiAwMDAwNTU5ZA0KDQpf
T0sNCg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoyMF0gICBnZm46IDAwMDA1NTllICBt
Zm46IDAwMDA1NTllDQoNClsgIDQ2My45MjE5MzNdIHMoWEVOKSBbMjAxMi0wOC0zMSAyMToz
MzoyMF0gICBnZm46IDAwMDA1NTlmICBtZm46IDAwMDA1NTlmDQoNCmQgMDowOjA6MDogW3Nk
YV0oWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoyMF0gICBnZm46IDAwMDA1NWEwICBtZm46IDAw
MDA1NWEwDQoNCiBDREI6IA0KDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjIwXSAgIGdm
bjogMDAwMDU1YTEgIG1mbjogMDAwMDU1YTENCg0KWyAgNDYzLjkyMTkzNl0gV3JpdGUoMTAp
OiAyYSAwMCAoWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoyMF0gICBnZm46IDAwMDA1NWEyICBt
Zm46IDAwMDA1NWEyDQoNCjA1IGI2IDU3IDYxIDAwIDAoWEVOKSBbMjAxMi0wOC0zMSAyMToz
MzoyMF0gICBnZm46IDAwMDA1NWEzICBtZm46IDAwMDA1NWEzDQoNCjAgMDggMDANCg0KDQoo
WEVOKSBbMjAxMi0wOC0zMSAyMTozMzoyMF0gICBnZm46IDAwMDA1NWE0ICBtZm46IDAwMDA1
NWE0DQoNClsgIDQ2My45MjE5MzddIGUoWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoyMF0gICBn
Zm46IDAwMDA1NWE1ICBtZm46IDAwMDA1NWE1DQoNCm5kX3JlcXVlc3Q6IEkvTyAoWEVOKSBb
MjAxMi0wOC0zMSAyMTozMzoyMF0gICBnZm46IDAwMDA1NWE2ICBtZm46IDAwMDA1NWE2DQoN
CmVycm9yLCBkZXYgc2RhLCAoWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoyMF0gICBnZm46IDAw
MDA1NWE3ICBtZm46IDAwMDA1NWE3DQoNCnNlY3RvciA5NTgzNjAwMQ0KDQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMzOjIwXSAgIGdmbjogMDAwMDU1YTggIG1mbjogMDAwMDU1YTgNCg0K
WyAgNDYzLjkyMTkzOV0gQihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjIwXSAgIGdmbjogMDAw
MDU1YTkgIG1mbjogMDAwMDU1YTkNCg0KdWZmZXIgSS9PIGVycm9yIG9uIGRldmljZSBkbS0w
LCAoWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoyMF0gICBnZm46IDAwMDA1NWFhICBtZm46IDAw
MDA1NWFhDQoNCmxvZ2ljYWwgYmxvY2sgOTUoWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoyMF0g
ICBnZm46IDAwMDA1NWFiICBtZm46IDAwMDA1NWFiDQoNCjM1NTY0DQoNCg0KKFhFTikgWzIw
MTItMDgtMzEgMjE6MzM6MjBdICAgZ2ZuOiAwMDAwNTVhYyAgbWZuOiAwMDAwNTVhYw0KDQpb
ICA0NjMuOTIxOTM5XSBsKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MjBdICAgZ2ZuOiAwMDAw
NTVhZCAgbWZuOiAwMDAwNTVhZA0KDQpvc3QgcGFnZSB3cml0ZSBkKFhFTikgWzIwMTItMDgt
MzEgMjE6MzM6MjBdICAgZ2ZuOiAwMDAwNTVhZSAgbWZuOiAwMDAwNTVhZQ0KDQp1ZSB0byBJ
L08gZXJyb3IgKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MjBdICAgZ2ZuOiAwMDAwNTVhZiAg
bWZuOiAwMDAwNTVhZg0KDQpvbiBkbS0wDQoNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6
MjBdICAgZ2ZuOiAwMDAwNTViMCAgbWZuOiAwMDAwNTViMA0KDQpbICA0NjMuOTIxOTQ4XSBz
KFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MjFdICAgZ2ZuOiAwMDAwNTViMSAgbWZuOiAwMDAw
NTViMQ0KDQpkIDA6MDowOjA6IFtzZGFdIFVuaGFuZGxlZCBlcnJvcihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMzOjIxXSAgIGdmbjogMDAwMDU1YjIgIG1mbjogMDAwMDU1YjINCg0KIGNvZGUN
Cg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoyMV0gICBnZm46IDAwMDA1NWIzICBtZm46
IDAwMDA1NWIzDQoNClsgIDQ2My45MjE5NDldIHNkIDA6MDowOjA6IFtzZGFdKFhFTikgWzIw
MTItMDgtMzEgMjE6MzM6MjFdICAgZ2ZuOiAwMDAwNTViNCAgbWZuOiAwMDAwNTViNA0KDQog
IA0KDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjIxXSAgIGdmbjogMDAwMDU1YjUgIG1m
bjogMDAwMDU1YjUNCg0KWyAgNDYzLjkyMTk1MF0gUihYRU4pIFsyMDEyLTA4LTMxIDIxOjMz
OjIxXSAgIGdmbjogMDAwMDU1YjYgIG1mbjogMDAwMDU1YjYNCg0KZXN1bHQ6IGhvc3RieXRl
PShYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjIxXSAgIGdmbjogMDAwMDU1YjcgIG1mbjogMDAw
MDU1YjcNCg0KRElEX0JBRF9UQVJHRVQgZHJpdmVyYnl0ZT1EUklWRVIoWEVOKSBbMjAxMi0w
OC0zMSAyMTozMzoyMV0gICBnZm46IDAwMDA1NWI4ICBtZm46IDAwMDA1NWI4DQoNCl9PSw0K
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjIxXSAgIGdmbjogMDAwMDU1YjkgIG1mbjog
MDAwMDU1YjkNCg0KWyAgNDYzLjkyMTk1MV0gc2QgMDowOjA6MDogW3NkYV0oWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMzoyMV0gICBnZm46IDAwMDA1NWJhICBtZm46IDAwMDA1NWJhDQoNCiBD
REI6IA0KDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjIxXSAgIGdmbjogMDAwMDU1YmIg
IG1mbjogMDAwMDU1YmINCg0KWyAgNDYzLjkyMTk1NF0gV3JpdGUoMTApOiAyYSAwMCAoWEVO
KSBbMjAxMi0wOC0zMSAyMTozMzoyMV0gICBnZm46IDAwMDA1NWJjICBtZm46IDAwMDA1NWJj
DQoNCjA2IDllIDU1IDAxIDAwIDAoWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoyMV0gICBnZm46
IDAwMDA1NWJkICBtZm46IDAwMDA1NWJkDQoNCjAgMTggMDANCg0KDQooWEVOKSBbMjAxMi0w
OC0zMSAyMTozMzoyMV0gICBnZm46IDAwMDA1NWJlICBtZm46IDAwMDA1NWJlDQoNClsgIDQ2
My45MjE5NTVdIGUoWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoyMV0gICBnZm46IDAwMDA1NWJm
ICBtZm46IDAwMDA1NWJmDQoNCm5kX3JlcXVlc3Q6IEkvTyAoWEVOKSBbMjAxMi0wOC0zMSAy
MTozMzoyMV0gICBnZm46IDAwMDA1NWMwICBtZm46IDAwMDA1NWMwDQoNCmVycm9yLCBkZXYg
c2RhLCAoWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoyMV0gICBnZm46IDAwMDA1NWMxICBtZm46
IDAwMDA1NWMxDQoNCnNlY3RvciAxMTEwMzk3NDUoWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoy
MV0gICBnZm46IDAwMDA1NWMyICBtZm46IDAwMDA1NWMyDQoNCg0KDQoNCihYRU4pIFsyMDEy
LTA4LTMxIDIxOjMzOjIxXSAgIGdmbjogMDAwMDU1YzMgIG1mbjogMDAwMDU1YzMNCg0KWyAg
NDYzLjkyMTk1N10gQnVmZmVyIEkvTyBlcnJvciAoWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoy
MV0gICBnZm46IDAwMDA1NWM0ICBtZm46IDAwMDA1NWM0DQoNCm9uIGRldmljZSBkbS0wLCAo
WEVOKSBbMjAxMi0wOC0zMSAyMTozMzoyMV0gICBnZm46IDAwMDA1NWM1ICBtZm46IDAwMDA1
NWM1DQoNCmxvZ2ljYWwgYmxvY2sgMTE0MzYwMzINCg0KDQooWEVOKSBbMjAxMi0wOC0zMSAy
MTozMzoyMV0gICBnZm46IDAwMDA1NWM2ICBtZm46IDAwMDA1NWM2DQoNClsgIDQ2My45MjE5
NTddIGwoWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoyMV0gICBnZm46IDAwMDA1NWM3ICBtZm46
IDAwMDA1NWM3DQoNCm9zdCBwYWdlIHdyaXRlIGQoWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoy
MV0gICBnZm46IDAwMDA1NWM4ICBtZm46IDAwMDA1NWM4DQoNCnVlIHRvIEkvTyBlcnJvciAo
WEVOKSBbMjAxMi0wOC0zMSAyMTozMzoyMV0gICBnZm46IDAwMDA1NWM5ICBtZm46IDAwMDA1
NWM5DQoNCm9uIGRtLTANCg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoyMV0gICBnZm46
IDAwMDA1NWNhICBtZm46IDAwMDA1NWNhDQoNClsgIDQ2My45MjE5NjBdIEIoWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMzoyMV0gICBnZm46IDAwMDA1NWNiICBtZm46IDAwMDA1NWNiDQoNCnVm
ZmVyIEkvTyBlcnJvciBvbiBkZXZpY2UgZG0tMCwgKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6
MjFdICAgZ2ZuOiAwMDAwNTVjYyAgbWZuOiAwMDAwNTVjYw0KDQpsb2dpY2FsIGJsb2NrIDEx
KFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MjFdICAgZ2ZuOiAwMDAwNTVjZCAgbWZuOiAwMDAw
NTVjZA0KDQo0MzYwMzMNCg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoyMV0gICBnZm46
IDAwMDA1NWNlICBtZm46IDAwMDA1NWNlDQoNClsgIDQ2My45MjE5NjFdIGwoWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMzoyMV0gICBnZm46IDAwMDA1NWNmICBtZm46IDAwMDA1NWNmDQoNCm9z
dCBwYWdlIHdyaXRlIGQoWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoyMV0gICBnZm46IDAwMDA1
NWQwICBtZm46IDAwMDA1NWQwDQoNCnVlIHRvIEkvTyBlcnJvciAoWEVOKSBbMjAxMi0wOC0z
MSAyMTozMzoyMV0gICBnZm46IDAwMDA1NWQxICBtZm46IDAwMDA1NWQxDQoNCm9uIGRtLTAN
Cg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoyMV0gICBnZm46IDAwMDA1NWQyICBtZm46
IDAwMDA1NWQyDQoNClsgIDQ2My45MjE5NjNdIEIoWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoy
MV0gICBnZm46IDAwMDA1NWQzICBtZm46IDAwMDA1NWQzDQoNCnVmZmVyIEkvTyBlcnJvciAo
WEVOKSBbMjAxMi0wOC0zMSAyMTozMzoyMV0gICBnZm46IDAwMDA1NWQ0ICBtZm46IDAwMDA1
NWQ0DQoNCm9uIGRldmljZSBkbS0wLCAoWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoyMV0gICBn
Zm46IDAwMDA1NWQ1ICBtZm46IDAwMDA1NWQ1DQoNCmxvZ2ljYWwgYmxvY2sgMTE0MzYwMzQN
Cg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoyMV0gICBnZm46IDAwMDA1NWQ2ICBtZm46
IDAwMDA1NWQ2DQoNClsgIDQ2My45MjE5NjNdIGwoWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoy
MV0gICBnZm46IDAwMDA1NWQ3ICBtZm46IDAwMDA1NWQ3DQoNCm9zdCBwYWdlIHdyaXRlIGR1
ZSB0byBJL08gZXJyb3IgKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MjFdICAgZ2ZuOiAwMDAw
NTVkOCAgbWZuOiAwMDAwNTVkOA0KDQpvbiBkbS0wDQoNCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzM6MjFdICAgZ2ZuOiAwMDAwNTVkOSAgbWZuOiAwMDAwNTVkOQ0KDQpbICA0NjMuOTIx
OTcwXSBzZCAwOjA6MDowOiBbc2RhXShYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjIxXSAgIGdm
bjogMDAwMDU1ZGEgIG1mbjogMDAwMDU1ZGENCg0KIFVuaGFuZGxlZCBlcnJvcihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMzOjIxXSAgIGdmbjogMDAwMDU1ZGIgIG1mbjogMDAwMDU1ZGINCg0K
IGNvZGUNCg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoyMV0gICBnZm46IDAwMDA1NWRj
ICBtZm46IDAwMDA1NWRjDQoNClsgIDQ2My45MjE5NzFdIHMoWEVOKSBbMjAxMi0wOC0zMSAy
MTozMzoyMV0gICBnZm46IDAwMDA1NWRkICBtZm46IDAwMDA1NWRkDQoNCmQgMDowOjA6MDog
W3NkYV0oWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoyMV0gICBnZm46IDAwMDA1NWRlICBtZm46
IDAwMDA1NWRlDQoNCiAgDQoNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MjFdICAgZ2Zu
OiAwMDAwNTVkZiAgbWZuOiAwMDAwNTVkZg0KDQpbICA0NjMuOTIxOTcxXSBSZXN1bHQ6IGhv
c3RieXRlPShYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjIxXSAgIGdmbjogMDAwMDU1ZTAgIG1m
bjogMDAwMDU1ZTANCg0KRElEX0JBRF9UQVJHRVQgZChYRU4pIFsyMDEyLTA4LTMxIDIxOjMz
OjIxXSAgIGdmbjogMDAwMDU1ZTEgIG1mbjogMDAwMDU1ZTENCg0Kcml2ZXJieXRlPURSSVZF
UihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjIxXSAgIGdmbjogMDAwMDU1ZTIgIG1mbjogMDAw
MDU1ZTINCg0KX09LDQoNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MjJdICAgZ2ZuOiAw
MDAwNTVlMyAgbWZuOiAwMDAwNTVlMw0KDQpbICA0NjMuOTIxOTcyXSBzZCAwOjA6MDowOiBb
c2RhXShYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjIyXSAgIGdmbjogMDAwMDU1ZTQgIG1mbjog
MDAwMDU1ZTQNCg0KIENEQjogDQoNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MjJdICAg
Z2ZuOiAwMDAwNTVlNSAgbWZuOiAwMDAwNTVlNQ0KDQpbICA0NjMuOTIxOTc1XSBXKFhFTikg
WzIwMTItMDgtMzEgMjE6MzM6MjJdICAgZ2ZuOiAwMDAwNTVlNiAgbWZuOiAwMDAwNTVlNg0K
DQpyaXRlKDEwKTogMmEgMDAgKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MjJdICAgZ2ZuOiAw
MDAwNTVlNyAgbWZuOiAwMDAwNTVlNw0KDQowNiA5ZSA1YSBiMSAwMCAwKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzM6MjJdICAgZ2ZuOiAwMDAwNTVlOCAgbWZuOiAwMDAwNTVlOA0KDQowIDA4
IDAwDQoNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MjJdICAgZ2ZuOiAwMDAwNTVlOSAg
bWZuOiAwMDAwNTVlOQ0KDQpbICA0NjMuOTIxOTc2XSBlKFhFTikgWzIwMTItMDgtMzEgMjE6
MzM6MjJdICAgZ2ZuOiAwMDAwNTVlYSAgbWZuOiAwMDAwNTVlYQ0KDQpuZF9yZXF1ZXN0OiBJ
L08gKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MjJdICAgZ2ZuOiAwMDAwNTVlYiAgbWZuOiAw
MDAwNTVlYg0KDQplcnJvciwgZGV2IHNkYSwgc2VjdG9yIDExMTA0MTIwMShYRU4pIFsyMDEy
LTA4LTMxIDIxOjMzOjIyXSAgIGdmbjogMDAwMDU1ZWMgIG1mbjogMDAwMDU1ZWMNCg0KDQoN
Cg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MjJdICAgZ2ZuOiAwMDAwNTVlZCAgbWZuOiAw
MDAwNTVlZA0KDQpbICA0NjMuOTIxOTc4XSBCdWZmZXIgSS9PIGVycm9yIChYRU4pIFsyMDEy
LTA4LTMxIDIxOjMzOjIyXSAgIGdmbjogMDAwMDU1ZWUgIG1mbjogMDAwMDU1ZWUNCg0Kb24g
ZGV2aWNlIGRtLTAsIChYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjIyXSAgIGdmbjogMDAwMDU1
ZWYgIG1mbjogMDAwMDU1ZWYNCg0KbG9naWNhbCBibG9jayAxMTQzNjIxNA0KDQoNCihYRU4p
IFsyMDEyLTA4LTMxIDIxOjMzOjIyXSAgIGdmbjogMDAwMDU1ZjAgIG1mbjogMDAwMDU1ZjAN
Cg0KWyAgNDYzLjkyMTk3OF0gbChYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjIyXSAgIGdmbjog
MDAwMDU1ZjEgIG1mbjogMDAwMDU1ZjENCg0Kb3N0IHBhZ2Ugd3JpdGUgZHVlIHRvIEkvTyBl
cnJvciAoWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoyMl0gICBnZm46IDAwMDA1NWYyICBtZm46
IDAwMDA1NWYyDQoNCm9uIGRtLTANCg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoyMl0g
ICBnZm46IDAwMDA1NWYzICBtZm46IDAwMDA1NWYzDQoNClsgIDQ2My45MjE5ODZdIHNkIDA6
MDowOjA6IFtzZGFdKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MjJdICAgZ2ZuOiAwMDAwNTVm
NCAgbWZuOiAwMDAwNTVmNA0KDQogVW5oYW5kbGVkIGVycm9yKFhFTikgWzIwMTItMDgtMzEg
MjE6MzM6MjJdICAgZ2ZuOiAwMDAwNTVmNSAgbWZuOiAwMDAwNTVmNQ0KDQogY29kZQ0KDQoN
CihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjIyXSAgIGdmbjogMDAwMDU1ZjYgIG1mbjogMDAw
MDU1ZjYNCg0KWyAgNDYzLjkyMTk4N10gcyhYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjIyXSAg
IGdmbjogMDAwMDU1ZjcgIG1mbjogMDAwMDU1ZjcNCg0KZCAwOjA6MDowOiBbc2RhXSAgDQoN
Cg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MjJdICAgZ2ZuOiAwMDAwNTVmOCAgbWZuOiAw
MDAwNTVmOA0KDQpbICA0NjMuOTIxOTg4XSBSKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MjJd
ICAgZ2ZuOiAwMDAwNTVmOSAgbWZuOiAwMDAwNTVmOQ0KDQplc3VsdDogaG9zdGJ5dGU9KFhF
TikgWzIwMTItMDgtMzEgMjE6MzM6MjJdICAgZ2ZuOiAwMDAwNTVmYSAgbWZuOiAwMDAwNTVm
YQ0KDQpESURfQkFEX1RBUkdFVCBkKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MjJdICAgZ2Zu
OiAwMDAwNTVmYiAgbWZuOiAwMDAwNTVmYg0KDQpyaXZlcmJ5dGU9RFJJVkVSX09LDQoNCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MjJdICAgZ2ZuOiAwMDAwNTVmYyAgbWZuOiAwMDAw
NTVmYw0KDQpbICA0NjMuOTIxOTg4XSBzKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MjJdICAg
Z2ZuOiAwMDAwNTVmZCAgbWZuOiAwMDAwNTVmZA0KDQpkIDA6MDowOjA6IFtzZGFdIENEQjog
DQoNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MjJdICAgZ2ZuOiAwMDAwNTVmZSAgbWZu
OiAwMDAwNTVmZQ0KDQpbICA0NjMuOTIxOTkxXSBXKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6
MjJdICAgZ2ZuOiAwMDAwNTVmZiAgbWZuOiAwMDAwNTVmZg0KDQpyaXRlKDEwKTogMmEgMDAg
MDYgOWUgNjUgZTEgMDAgMChYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjIyXSAgIGdmbjogMDAw
MDU2MDAgIG1mbjogMDAwMDU2MDANCg0KMCAwOCAwMA0KDQoNCihYRU4pIFsyMDEyLTA4LTMx
IDIxOjMzOjIyXSAgIGdmbjogMDAwMDU2MDEgIG1mbjogMDAwMDU2MDENCg0KWyAgNDYzLjky
MTk5Ml0gZW5kX3JlcXVlc3Q6IEkvTyBlcnJvciwgZGV2IHNkYSwgKFhFTikgWzIwMTItMDgt
MzEgMjE6MzM6MjJdICAgZ2ZuOiAwMDAwNTYwMiAgbWZuOiAwMDAwNTYwMg0KDQpzZWN0b3Ig
MTExMDQ0MDY1KFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MjJdICAgZ2ZuOiAwMDAwNTYwMyAg
bWZuOiAwMDAwNTYwMw0KDQoNCg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoyMl0gICBn
Zm46IDAwMDA1NjA0ICBtZm46IDAwMDA1NjA0DQoNClsgIDQ2My45MjE5OTVdIEIoWEVOKSBb
MjAxMi0wOC0zMSAyMTozMzoyMl0gICBnZm46IDAwMDA1NjA1ICBtZm46IDAwMDA1NjA1DQoN
CnVmZmVyIEkvTyBlcnJvciAoWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoyMl0gICBnZm46IDAw
MDA1NjA2ICBtZm46IDAwMDA1NjA2DQoNCm9uIGRldmljZSBkbS0wLCAoWEVOKSBbMjAxMi0w
OC0zMSAyMTozMzoyMl0gICBnZm46IDAwMDA1NjA3ICBtZm46IDAwMDA1NjA3DQoNCmxvZ2lj
YWwgYmxvY2sgMTE0MzY1NzINCg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoyMl0gICBn
Zm46IDAwMDA1NjA4ICBtZm46IDAwMDA1NjA4DQoNClsgIDQ2My45MjE5OTZdIGwoWEVOKSBb
MjAxMi0wOC0zMSAyMTozMzoyMl0gICBnZm46IDAwMDA1NjA5ICBtZm46IDAwMDA1NjA5DQoN
Cm9zdCBwYWdlIHdyaXRlIGR1ZSB0byBJL08gZXJyb3IgKFhFTikgWzIwMTItMDgtMzEgMjE6
MzM6MjJdICAgZ2ZuOiAwMDAwNTYwYSAgbWZuOiAwMDAwNTYwYQ0KDQpvbiBkbS0wDQoNCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MjJdICAgZ2ZuOiAwMDAwNTYwYiAgbWZuOiAwMDAw
NTYwYg0KDQpbICA0NjMuOTIyMDIxXSBBYm9ydGluZyBqb3VybmFsIChYRU4pIFsyMDEyLTA4
LTMxIDIxOjMzOjIyXSAgIGdmbjogMDAwMDU2MGMgIG1mbjogMDAwMDU2MGMNCg0Kb24gZGV2
aWNlIGRtLTAtOChYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjIyXSAgIGdmbjogMDAwMDU2MGQg
IG1mbjogMDAwMDU2MGQNCg0KLg0KDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjIyXSAg
IGdmbjogMDAwMDU2MGUgIG1mbjogMDAwMDU2MGUNCg0KWyAgNDYzLjkyMjA4MF0gRShYRU4p
IFsyMDEyLTA4LTMxIDIxOjMzOjIyXSAgIGdmbjogMDAwMDU2MGYgIG1mbjogMDAwMDU2MGYN
Cg0KWFQ0LWZzIChkbS0wKTogZChYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjIyXSAgIGdmbjog
MDAwMDU2MTAgIG1mbjogMDAwMDU2MTANCg0KZWxheWVkIGJsb2NrIGFsbChYRU4pIFsyMDEy
LTA4LTMxIDIxOjMzOjIyXSAgIGdmbjogMDAwMDU2MTEgIG1mbjogMDAwMDU2MTENCg0Kb2Nh
dGlvbiBmYWlsZWQgZm9yIGlub2RlIDIxMDU0MTkoWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoy
Ml0gICBnZm46IDAwMDA1NjEyICBtZm46IDAwMDA1NjEyDQoNCiBhdCBsb2dpY2FsIG9mZnMo
WEVOKSBbMjAxMi0wOC0zMSAyMTozMzoyMl0gICBnZm46IDAwMDA1NjEzICBtZm46IDAwMDA1
NjEzDQoNCmV0IDM5IHdpdGggbWF4IGJsb2NrcyA1IHdpdGggZXJyKFhFTikgWzIwMTItMDgt
MzEgMjE6MzM6MjNdICAgZ2ZuOiAwMDAwNTYxNCAgbWZuOiAwMDAwNTYxNA0KDQpvciAtMzAN
Cg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoyM10gICBnZm46IDAwMDA1NjE1ICBtZm46
IDAwMDA1NjE1DQoNClsgIDQ2My45MjIwODFdIEVYVDQtZnMgKGRtLTApOiBUKFhFTikgWzIw
MTItMDgtMzEgMjE6MzM6MjNdICAgZ2ZuOiAwMDAwNTYxNiAgbWZuOiAwMDAwNTYxNg0KDQpo
aXMgc2hvdWxkIG5vdCBoKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MjNdICAgZ2ZuOiAwMDAw
NTYxNyAgbWZuOiAwMDAwNTYxNw0KDQphcHBlbiEhIERhdGEgd2lsbCBiZSBsb3N0DQoNCg0K
WyAgNDYoWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoyM10gICBnZm46IDAwMDA1NjE4ICBtZm46
IDAwMDA1NjE4DQoNCjMuOTIyMDgxXSANCg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoy
M10gICBnZm46IDAwMDA1NjE5ICBtZm46IDAwMDA1NjE5DQoNClsgIDQ2My45MjIxMzFdIEVY
VDQtZnMgZXJyb3IgKGRlKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MjNdICAgZ2ZuOiAwMDAw
NTYxYSAgbWZuOiAwMDAwNTYxYQ0KDQp2aWNlIGRtLTApIGluIGV4KFhFTikgWzIwMTItMDgt
MzEgMjE6MzM6MjNdICAgZ2ZuOiAwMDAwNTYxYiAgbWZuOiAwMDAwNTYxYg0KDQp0NF9kYV93
cml0ZXBhZ2VzOjIzOTg6IEpvdXJuYWwgaChYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjIzXSAg
IGdmbjogMDAwMDU2MWMgIG1mbjogMDAwMDU2MWMNCg0KYXMgYWJvcnRlZA0KDQoNCihYRU4p
IFsyMDEyLTA4LTMxIDIxOjMzOjIzXSAgIGdmbjogMDAwMDU2MWQgIG1mbjogMDAwMDU2MWQN
Cg0KWyAgNDYzLjkyMjIzM10gRVhUNC1mcyBlcnJvciAoZGUoWEVOKSBbMjAxMi0wOC0zMSAy
MTozMzoyM10gICBnZm46IDAwMDA1NjFlICBtZm46IDAwMDA1NjFlDQoNCnZpY2UgZG0tMCkg
aW4gZXgoWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoyM10gICBnZm46IDAwMDA1NjFmICBtZm46
IDAwMDA1NjFmDQoNCnQ0X3Jlc2VydmVfaW5vZGVfd3JpdGU6NDU0MzogSm91KFhFTikgWzIw
MTItMDgtMzEgMjE6MzM6MjNdICAgZ2ZuOiAwMDAwNTYyMCAgbWZuOiAwMDAwNTYyMA0KDQpy
bmFsIGhhcyBhYm9ydGVkKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MjNdICAgZ2ZuOiAwMDAw
NTYyMSAgbWZuOiAwMDAwNTYyMQ0KDQoNCg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoy
M10gICBnZm46IDAwMDA1NjIyICBtZm46IDAwMDA1NjIyDQoNClsgIDQ2My45MjIyNjldIHMo
WEVOKSBbMjAxMi0wOC0zMSAyMTozMzoyM10gICBnZm46IDAwMDA1NjIzICBtZm46IDAwMDA1
NjIzDQoNCmQgMDowOjA6MDogW3NkYV0gVW5oYW5kbGVkIGVycm9yKFhFTikgWzIwMTItMDgt
MzEgMjE6MzM6MjNdICAgZ2ZuOiAwMDAwNTYyNCAgbWZuOiAwMDAwNTYyNA0KDQogY29kZQ0K
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjIzXSAgIGdmbjogMDAwMDU2MjUgIG1mbjog
MDAwMDU2MjUNCg0KWyAgNDYzLjkyMjI3MF0gc2QgMDowOjA6MDogW3NkYV0oWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMzoyM10gICBnZm46IDAwMDA1NjI2ICBtZm46IDAwMDA1NjI2DQoNCiAg
DQoNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MjNdICAgZ2ZuOiAwMDAwNTYyNyAgbWZu
OiAwMDAwNTYyNw0KDQpbICA0NjMuOTIyMjcxXSBSZXN1bHQ6IGhvc3RieXRlPShYRU4pIFsy
MDEyLTA4LTMxIDIxOjMzOjIzXSAgIGdmbjogMDAwMDU2MjggIG1mbjogMDAwMDU2MjgNCg0K
RElEX0JBRF9UQVJHRVQgZChYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjIzXSAgIGdmbjogMDAw
MDU2MjkgIG1mbjogMDAwMDU2MjkNCg0Kcml2ZXJieXRlPURSSVZFUl9PSw0KDQoNCihYRU4p
IFsyMDEyLTA4LTMxIDIxOjMzOjIzXSAgIGdmbjogMDAwMDU2MmEgIG1mbjogMDAwMDU2MmEN
Cg0KWyAgNDYzLjkyMjI3Ml0gcyhYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjIzXSAgIGdmbjog
MDAwMDU2MmIgIG1mbjogMDAwMDU2MmINCg0KZCAwOjA6MDowOiBbc2RhXSBDREI6IA0KDQoN
CihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjIzXSAgIGdmbjogMDAwMDU2MmMgIG1mbjogMDAw
MDU2MmMNCg0KWyAgNDYzLjkyMjI3NV0gVyhYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjIzXSAg
IGdmbjogMDAwMDU2MmQgIG1mbjogMDAwMDU2MmQNCg0Kcml0ZSgxMCk6IDJhIDAwIDAxIDJh
IDg1IDQ5IDAwIDAoWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoyM10gICBnZm46IDAwMDA1NjJl
ICBtZm46IDAwMDA1NjJlDQoNCjAgMDggMDANCg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
MzoyM10gICBnZm46IDAwMDA1NjJmICBtZm46IDAwMDA1NjJmDQoNClsgIDQ2My45MjIyNzZd
IGVuZF9yZXF1ZXN0OiBJL08gKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MjNdICAgZ2ZuOiAw
MDAwNTYzMCAgbWZuOiAwMDAwNTYzMA0KDQplcnJvciwgZGV2IHNkYSwgKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzM6MjNdICAgZ2ZuOiAwMDAwNTYzMSAgbWZuOiAwMDAwNTYzMQ0KDQpzZWN0
b3IgMTk1NjM4NDkNCg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoyM10gICBnZm46IDAw
MDA1NjMyICBtZm46IDAwMDA1NjMyDQoNClsgIDQ2My45MjIyOTJdIEooWEVOKSBbMjAxMi0w
OC0zMSAyMTozMzoyM10gICBnZm46IDAwMDA1NjMzICBtZm46IDAwMDA1NjMzDQoNCkJEMjog
RXJyb3IgLTUgZGV0ZWN0ZWQgd2hlbiB1cGRhdGluZyBqb3VybmFsIHN1cChYRU4pIFsyMDEy
LTA4LTMxIDIxOjMzOjIzXSAgIGdmbjogMDAwMDU2MzQgIG1mbjogMDAwMDU2MzQNCg0KZXJi
bG9jayBmb3IgZG0tMChYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjIzXSAgIGdmbjogMDAwMDU2
MzUgIG1mbjogMDAwMDU2MzUNCg0KLTguDQoNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6
MjNdICAgZ2ZuOiAwMDAwNTYzNiAgbWZuOiAwMDAwNTYzNg0KDQpbICA0NjMuOTIyMzU3XSBz
KFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MjNdICAgZ2ZuOiAwMDAwNTYzNyAgbWZuOiAwMDAw
NTYzNw0KDQpkIDA6MDowOjA6IFtzZGFdKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MjNdICAg
Z2ZuOiAwMDAwNTYzOCAgbWZuOiAwMDAwNTYzOA0KDQogVW5oYW5kbGVkIGVycm9yKFhFTikg
WzIwMTItMDgtMzEgMjE6MzM6MjNdICAgZ2ZuOiAwMDAwNTYzOSAgbWZuOiAwMDAwNTYzOQ0K
DQogY29kZQ0KDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjIzXSAgIGdmbjogMDAwMDU2
M2EgIG1mbjogMDAwMDU2M2ENCg0KWyAgNDYzLjkyMjM1OF0gcyhYRU4pIFsyMDEyLTA4LTMx
IDIxOjMzOjIzXSAgIGdmbjogMDAwMDU2M2IgIG1mbjogMDAwMDU2M2INCg0KZCAwOjA6MDow
OiBbc2RhXSAgDQoNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MjNdICAgZ2ZuOiAwMDAw
NTYzYyAgbWZuOiAwMDAwNTYzYw0KDQpbICA0NjMuOTIyMzU4XSBSKFhFTikgWzIwMTItMDgt
MzEgMjE6MzM6MjNdICAgZ2ZuOiAwMDAwNTYzZCAgbWZuOiAwMDAwNTYzZA0KDQplc3VsdDog
aG9zdGJ5dGU9RElEX0JBRF9UQVJHRVQgZChYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjIzXSAg
IGdmbjogMDAwMDU2M2UgIG1mbjogMDAwMDU2M2UNCg0Kcml2ZXJieXRlPURSSVZFUihYRU4p
IFsyMDEyLTA4LTMxIDIxOjMzOjIzXSAgIGdmbjogMDAwMDU2M2YgIG1mbjogMDAwMDU2M2YN
Cg0KX09LDQoNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MjNdICAgZ2ZuOiAwMDAwNTY0
MCAgbWZuOiAwMDAwNTY0MA0KDQpbICA0NjMuOTIyMzU5XSBzKFhFTikgWzIwMTItMDgtMzEg
MjE6MzM6MjNdICAgZ2ZuOiAwMDAwNTY0MSAgbWZuOiAwMDAwNTY0MQ0KDQpkIDA6MDowOjA6
IFtzZGFdKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MjNdICAgZ2ZuOiAwMDAwNTY0MiAgbWZu
OiAwMDAwNTY0Mg0KDQogQ0RCOiANCg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoyM10g
ICBnZm46IDAwMDA1NjQzICBtZm46IDAwMDA1NjQzDQoNClsgIDQ2My45MjIzNjNdIFdyaXRl
KDEwKTogMmEgMDAgKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MjRdICAgZ2ZuOiAwMDAwNTY0
NCAgbWZuOiAwMDAwNTY0NA0KDQowMSAyYSA1NSAwMSAwMCAwKFhFTikgWzIwMTItMDgtMzEg
MjE6MzM6MjRdICAgZ2ZuOiAwMDAwNTY0NSAgbWZuOiAwMDAwNTY0NQ0KDQowIDA4IDAwDQoN
Cg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MjRdICAgZ2ZuOiAwMDAwNTY0NiAgbWZuOiAw
MDAwNTY0Ng0KDQpbICA0NjMuOTIyMzYzXSBlKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MjRd
ICAgZ2ZuOiAwMDAwNTY0NyAgbWZuOiAwMDAwNTY0Nw0KDQpuZF9yZXF1ZXN0OiBJL08gZXJy
b3IsIGRldiBzZGEsIChYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjI0XSAgIGdmbjogMDAwMDU2
NDggIG1mbjogMDAwMDU2NDgNCg0Kc2VjdG9yIDE5NTUxNDg5DQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMzoyNF0gICBnZm46IDAwMDA1NjQ5ICBtZm46IDAwMDA1NjQ5DQoNCg0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMzoyNF0gICBnZm46IDAwMDA1NjRhICBtZm46IDAwMDA1NjRh
DQoNClsgIDQ2My45MjI1MjJdIHMoWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoyNF0gICBnZm46
IDAwMDA1NjRiICBtZm46IDAwMDA1NjRiDQoNCmQgMDowOjA6MDogW3NkYV0oWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMzoyNF0gICBnZm46IDAwMDA1NjRjICBtZm46IDAwMDA1NjRjDQoNCiBV
bmhhbmRsZWQgZXJyb3IoWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoyNF0gICBnZm46IDAwMDA1
NjRkICBtZm46IDAwMDA1NjRkDQoNCiBjb2RlDQoNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6
MzM6MjRdICAgZ2ZuOiAwMDAwNTY0ZSAgbWZuOiAwMDAwNTY0ZQ0KDQpbICA0NjMuOTIyNTIz
XSBzKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MjRdICAgZ2ZuOiAwMDAwNTY0ZiAgbWZuOiAw
MDAwNTY0Zg0KDQpkIDA6MDowOjA6IFtzZGFdKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MjRd
ICAgZ2ZuOiAwMDAwNTY1MCAgbWZuOiAwMDAwNTY1MA0KDQogIA0KDQoNCihYRU4pIFsyMDEy
LTA4LTMxIDIxOjMzOjI0XSAgIGdmbjogMDAwMDU2NTEgIG1mbjogMDAwMDU2NTENCg0KWyAg
NDYzLjkyMjUyNF0gUmVzdWx0OiBob3N0Ynl0ZT0oWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoy
NF0gICBnZm46IDAwMDA1NjUyICBtZm46IDAwMDA1NjUyDQoNCkRJRF9CQURfVEFSR0VUIGQo
WEVOKSBbMjAxMi0wOC0zMSAyMTozMzoyNF0gICBnZm46IDAwMDA1NjUzICBtZm46IDAwMDA1
NjUzDQoNCnJpdmVyYnl0ZT1EUklWRVJfT0sNCg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
MzoyNF0gICBnZm46IDAwMDA1NjU0ICBtZm46IDAwMDA1NjU0DQoNClsgIDQ2My45MjI1MjVd
IHMoWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoyNF0gICBnZm46IDAwMDA1NjU1ICBtZm46IDAw
MDA1NjU1DQoNCmQgMDowOjA6MDogW3NkYV0gQ0RCOiANCg0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMzoyNF0gICBnZm46IDAwMDA1NjU2ICBtZm46IDAwMDA1NjU2DQoNClsgIDQ2My45
MjI1MjhdIFcoWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoyNF0gICBnZm46IDAwMDA1NjU3ICBt
Zm46IDAwMDA1NjU3DQoNCnJpdGUoMTApOiAyYSAwMCAwMSAyYSA1NSAwMSAwMCAwKFhFTikg
WzIwMTItMDgtMzEgMjE6MzM6MjRdICAgZ2ZuOiAwMDAwNTY1OCAgbWZuOiAwMDAwNTY1OA0K
DQowIDA4IDAwDQoNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MjRdICAgZ2ZuOiAwMDAw
NTY1OSAgbWZuOiAwMDAwNTY1OQ0KDQpbICA0NjMuOTIyNTI5XSBlbmRfcmVxdWVzdDogSS9P
IChYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjI0XSAgIGdmbjogMDAwMDU2NWEgIG1mbjogMDAw
MDU2NWENCg0KZXJyb3IsIGRldiBzZGEsIChYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjI0XSAg
IGdmbjogMDAwMDU2NWIgIG1mbjogMDAwMDU2NWINCg0Kc2VjdG9yIDE5NTUxNDg5DQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMzoyNF0gICBnZm46IDAwMDA1NjVjICBtZm46IDAwMDA1NjVj
DQoNCg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoyNF0gICBnZm46IDAwMDA1NjVkICBt
Zm46IDAwMDA1NjVkDQoNClsgIDQ2My45MjI1NDJdIEVYVDQtZnMgKGRtLTApOiBSKFhFTikg
WzIwMTItMDgtMzEgMjE6MzM6MjRdICAgZ2ZuOiAwMDAwNTY1ZSAgbWZuOiAwMDAwNTY1ZQ0K
DQplbW91bnRpbmcgZmlsZXN5KFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MjRdICAgZ2ZuOiAw
MDAwNTY1ZiAgbWZuOiAwMDAwNTY1Zg0KDQpzdGVtIHJlYWQtb25seQ0KDQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMzOjI0XSAgIGdmbjogMDAwMDU2NjAgIG1mbjogMDAwMDU2NjANCg0K
WyAgNDYzLjkyMjU0NV0gRShYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjI0XSAgIGdmbjogMDAw
MDU2NjEgIG1mbjogMDAwMDU2NjENCg0KWFQ0LWZzIChkbS0wKTogZXh0NF9kYV93cml0ZXBh
Z2UoWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoyNF0gICBnZm46IDAwMDA1NjYyICBtZm46IDAw
MDA1NjYyDQoNCnM6IGpiZDJfc3RhcnQ6IDYoWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoyNF0g
ICBnZm46IDAwMDA1NjYzICBtZm46IDAwMDA1NjYzDQoNCjE0NCBwYWdlcywgaW5vIDIoWEVO
KSBbMjAxMi0wOC0zMSAyMTozMzoyNF0gICBnZm46IDAwMDA1NjY0ICBtZm46IDAwMDA1NjY0
DQoNCjEwNTQxOTsgZXJyIC0zMA0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MjRdICAgZ2Zu
OiAwMDAwNTY2NSAgbWZuOiAwMDAwNTY2NQ0KDQoNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6
MzM6MjRdICAgZ2ZuOiAwMDAwNTY2NiAgbWZuOiAwMDAwNTY2Ng0KDQpbICA0NjMuOTI1Njkz
XSBFKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MjRdICAgZ2ZuOiAwMDAwNTY2NyAgbWZuOiAw
MDAwNTY2Nw0KDQpYVDQtZnMgZXJyb3IgKGRldmljZSBkbS0wKSBpbiBleChYRU4pIFsyMDEy
LTA4LTMxIDIxOjMzOjI0XSAgIGdmbjogMDAwMDU2NjggIG1mbjogMDAwMDU2NjgNCg0KdDRf
cmVzZXJ2ZV9pbm9kZShYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjI0XSAgIGdmbjogMDAwMDU2
NjkgIG1mbjogMDAwMDU2NjkNCg0KX3dyaXRlOjQ1NDM6IEpvdXJuYWwgaGFzIGFib3J0ZWQo
WEVOKSBbMjAxMi0wOC0zMSAyMTozMzoyNF0gICBnZm46IDAwMDA1NjZhICBtZm46IDAwMDA1
NjZhDQoNCg0KDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjI0XSAgIGdmbjogMDAwMDU2
NmIgIG1mbjogMDAwMDU2NmINCg0KWyAgNDYzLjkyNTY5OF0gRVhUNC1mcyAoZG0tMCk6IHAo
WEVOKSBbMjAxMi0wOC0zMSAyMTozMzoyNF0gICBnZm46IDAwMDA1NjZjICBtZm46IDAwMDA1
NjZjDQoNCnJldmlvdXMgSS9PIGVycm8oWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoyNF0gICBn
Zm46IDAwMDA1NjZkICBtZm46IDAwMDA1NjZkDQoNCnIgdG8gc3VwZXJibG9jayBkZXRlY3Rl
ZA0KDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjI0XSAgIGdmbjogMDAwMDU2NmUgIG1m
bjogMDAwMDU2NmUNCg0KWyAgNDYzLjkyNTczM10gcyhYRU4pIFsyMDEyLTA4LTMxIDIxOjMz
OjI0XSAgIGdmbjogMDAwMDU2NmYgIG1mbjogMDAwMDU2NmYNCg0KZCAwOjA6MDowOiBbc2Rh
XShYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjI0XSAgIGdmbjogMDAwMDU2NzAgIG1mbjogMDAw
MDU2NzANCg0KIFVuaGFuZGxlZCBlcnJvcihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjI0XSAg
IGdmbjogMDAwMDU2NzEgIG1mbjogMDAwMDU2NzENCg0KIGNvZGUNCg0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMzoyNF0gICBnZm46IDAwMDA1NjcyICBtZm46IDAwMDA1NjcyDQoNClsg
IDQ2My45MjU3MzRdIHMoWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoyNF0gICBnZm46IDAwMDA1
NjczICBtZm46IDAwMDA1NjczDQoNCmQgMDowOjA6MDogW3NkYV0oWEVOKSBbMjAxMi0wOC0z
MSAyMTozMzoyNF0gICBnZm46IDAwMDA1Njc0ICBtZm46IDAwMDA1Njc0DQoNCiAgDQoNCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MjRdICAgZ2ZuOiAwMDAwNTY3NSAgbWZuOiAwMDAw
NTY3NQ0KDQpbICA0NjMuOTI1NzM0XSBSZXN1bHQ6IGhvc3RieXRlPShYRU4pIFsyMDEyLTA4
LTMxIDIxOjMzOjI1XSAgIGdmbjogMDAwMDU2NzYgIG1mbjogMDAwMDU2NzYNCg0KRElEX0JB
RF9UQVJHRVQgZChYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjI1XSAgIGdmbjogMDAwMDU2Nzcg
IG1mbjogMDAwMDU2NzcNCg0Kcml2ZXJieXRlPURSSVZFUl9PSw0KDQoNCihYRU4pIFsyMDEy
LTA4LTMxIDIxOjMzOjI1XSAgIGdmbjogMDAwMDU2NzggIG1mbjogMDAwMDU2NzgNCg0KWyAg
NDYzLjkyNTczNV0gcyhYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjI1XSAgIGdmbjogMDAwMDU2
NzkgIG1mbjogMDAwMDU2NzkNCg0KZCAwOjA6MDowOiBbc2RhXSBDREI6IA0KDQoNCihYRU4p
IFsyMDEyLTA4LTMxIDIxOjMzOjI1XSAgIGdmbjogMDAwMDU2N2EgIG1mbjogMDAwMDU2N2EN
Cg0KWyAgNDYzLjkyNTczOV0gVyhYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjI1XSAgIGdmbjog
MDAwMDU2N2IgIG1mbjogMDAwMDU2N2INCg0Kcml0ZSgxMCk6IDJhIDAwIDAxIDJhIDU1IDAx
IDAwIDAoWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoyNV0gICBnZm46IDAwMDA1NjdjICBtZm46
IDAwMDA1NjdjDQoNCjAgMDggMDANCg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoyNV0g
ICBnZm46IDAwMDA1NjdkICBtZm46IDAwMDA1NjdkDQoNClsgIDQ2My45MjU3NDBdIGVuZF9y
ZXF1ZXN0OiBJL08gKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MjVdICAgZ2ZuOiAwMDAwNTY3
ZSAgbWZuOiAwMDAwNTY3ZQ0KDQplcnJvciwgZGV2IHNkYSwgKFhFTikgWzIwMTItMDgtMzEg
MjE6MzM6MjVdICAgZ2ZuOiAwMDAwNTY3ZiAgbWZuOiAwMDAwNTY3Zg0KDQpzZWN0b3IgMTk1
NTE0ODkNCg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoyNV0gICBnZm46IDAwMDA1Njgw
ICBtZm46IDAwMDA1NjgwDQoNClsgIDQ2My45MjU4NDhdIHMoWEVOKSBbMjAxMi0wOC0zMSAy
MTozMzoyNV0gICBnZm46IDAwMDA1NjgxICBtZm46IDAwMDA1NjgxDQoNCmQgMDowOjA6MDog
W3NkYV0gVW5oYW5kbGVkIGVycm9yKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MjVdICAgZ2Zu
OiAwMDAwNTY4MiAgbWZuOiAwMDAwNTY4Mg0KDQogY29kZQ0KDQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMzOjI1XSAgIGdmbjogMDAwMDU2ODMgIG1mbjogMDAwMDU2ODMNCg0KWyAgNDYz
LjkyNTg0OV0gc2QgMDowOjA6MDogW3NkYV0oWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoyNV0g
ICBnZm46IDAwMDA1Njg0ICBtZm46IDAwMDA1Njg0DQoNCiAgDQoNCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzM6MjVdICAgZ2ZuOiAwMDAwNTY4NSAgbWZuOiAwMDAwNTY4NQ0KDQpbICA0
NjMuOTI1ODQ5XSBSZXN1bHQ6IGhvc3RieXRlPShYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjI1
XSAgIGdmbjogMDAwMDU2ODYgIG1mbjogMDAwMDU2ODYNCg0KRElEX0JBRF9UQVJHRVQgZChY
RU4pIFsyMDEyLTA4LTMxIDIxOjMzOjI1XSAgIGdmbjogMDAwMDU2ODcgIG1mbjogMDAwMDU2
ODcNCg0Kcml2ZXJieXRlPURSSVZFUl9PSw0KDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMz
OjI1XSAgIGdmbjogMDAwMDU2ODggIG1mbjogMDAwMDU2ODgNCg0KWyAgNDYzLjkyNTg1MF0g
cyhYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjI1XSAgIGdmbjogMDAwMDU2ODkgIG1mbjogMDAw
MDU2ODkNCg0KZCAwOjA6MDowOiBbc2RhXSBDREI6IA0KDQoNCihYRU4pIFsyMDEyLTA4LTMx
IDIxOjMzOjI1XSAgIGdmbjogMDAwMDU2OGEgIG1mbjogMDAwMDU2OGENCg0KWyAgNDYzLjky
NTg1NF0gVyhYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjI1XSAgIGdmbjogMDAwMDU2OGIgIG1m
bjogMDAwMDU2OGINCg0Kcml0ZSgxMCk6IDJhIDAwIDA1IDdhIDg4IGExIDAwIDAoWEVOKSBb
MjAxMi0wOC0zMSAyMTozMzoyNV0gICBnZm46IDAwMDA1NjhjICBtZm46IDAwMDA1NjhjDQoN
CjAgMDggMDANCg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoyNV0gICBnZm46IDAwMDA1
NjhkICBtZm46IDAwMDA1NjhkDQoNClsgIDQ2My45MjU4NTVdIGVuZF9yZXF1ZXN0OiBJL08g
KFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MjVdICAgZ2ZuOiAwMDAwNTY4ZSAgbWZuOiAwMDAw
NTY4ZQ0KDQplcnJvciwgZGV2IHNkYSwgKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MjVdICAg
Z2ZuOiAwMDAwNTY4ZiAgbWZuOiAwMDAwNTY4Zg0KDQpzZWN0b3IgOTE5MTY0NDkNCg0KDQoo
WEVOKSBbMjAxMi0wOC0zMSAyMTozMzoyNV0gICBnZm46IDAwMDA1NjkwICBtZm46IDAwMDA1
NjkwDQoNClsgIDQ2My45MjU4NjZdIHMoWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoyNV0gICBn
Zm46IDAwMDA1NjkxICBtZm46IDAwMDA1NjkxDQoNCmQgMDowOjA6MDogW3NkYV0gVW5oYW5k
bGVkIGVycm9yKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MjVdICAgZ2ZuOiAwMDAwNTY5MiAg
bWZuOiAwMDAwNTY5Mg0KDQogY29kZQ0KDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjI1
XSAgIGdmbjogMDAwMDU2OTMgIG1mbjogMDAwMDU2OTMNCg0KWyAgNDYzLjkyNTg2N10gc2Qg
MDowOjA6MDogW3NkYV0oWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoyNV0gICBnZm46IDAwMDA1
Njk0ICBtZm46IDAwMDA1Njk0DQoNCiAgDQoNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6
MjVdICAgZ2ZuOiAwMDAwNTY5NSAgbWZuOiAwMDAwNTY5NQ0KDQpbICA0NjMuOTI1ODY4XSBS
ZXN1bHQ6IGhvc3RieXRlPShYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjI1XSAgIGdmbjogMDAw
MDU2OTYgIG1mbjogMDAwMDU2OTYNCg0KRElEX0JBRF9UQVJHRVQgZChYRU4pIFsyMDEyLTA4
LTMxIDIxOjMzOjI1XSAgIGdmbjogMDAwMDU2OTcgIG1mbjogMDAwMDU2OTcNCg0Kcml2ZXJi
eXRlPURSSVZFUl9PSw0KDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjI1XSAgIGdmbjog
MDAwMDU2OTggIG1mbjogMDAwMDU2OTgNCg0KWyAgNDYzLjkyNTg2OV0gcyhYRU4pIFsyMDEy
LTA4LTMxIDIxOjMzOjI1XSAgIGdmbjogMDAwMDU2OTkgIG1mbjogMDAwMDU2OTkNCg0KZCAw
OjA6MDowOiBbc2RhXSBDREI6IA0KDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjI1XSAg
IGdmbjogMDAwMDU2OWEgIG1mbjogMDAwMDU2OWENCg0KWyAgNDYzLjkyNTg3Ml0gVyhYRU4p
IFsyMDEyLTA4LTMxIDIxOjMzOjI1XSAgIGdmbjogMDAwMDU2OWIgIG1mbjogMDAwMDU2OWIN
Cg0Kcml0ZSgxMCk6IDJhIDAwIDA1IDdhIDk5IDYxIDAwIDAoWEVOKSBbMjAxMi0wOC0zMSAy
MTozMzoyNV0gICBnZm46IDAwMDA1NjljICBtZm46IDAwMDA1NjljDQoNCjAgMDggMDANCg0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoyNV0gICBnZm46IDAwMDA1NjlkICBtZm46IDAw
MDA1NjlkDQoNClsgIDQ2My45MjU4NzJdIGVuZF9yZXF1ZXN0OiBJL08gKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzM6MjVdICAgZ2ZuOiAwMDAwNTY5ZSAgbWZuOiAwMDAwNTY5ZQ0KDQplcnJv
ciwgZGV2IHNkYSwgKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MjVdICAgZ2ZuOiAwMDAwNTY5
ZiAgbWZuOiAwMDAwNTY5Zg0KDQpzZWN0b3IgOTE5MjA3MzcNCg0KDQooWEVOKSBbMjAxMi0w
OC0zMSAyMTozMzoyNV0gICBnZm46IDAwMDA1NmEwICBtZm46IDAwMDA1NmEwDQoNClsgIDQ2
My45MjU4NzldIHMoWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoyNV0gICBnZm46IDAwMDA1NmEx
ICBtZm46IDAwMDA1NmExDQoNCmQgMDowOjA6MDogW3NkYV0gVW5oYW5kbGVkIGVycm9yKFhF
TikgWzIwMTItMDgtMzEgMjE6MzM6MjVdICAgZ2ZuOiAwMDAwNTZhMiAgbWZuOiAwMDAwNTZh
Mg0KDQogY29kZQ0KDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjI1XSAgIGdmbjogMDAw
MDU2YTMgIG1mbjogMDAwMDU2YTMNCg0KWyAgNDYzLjkyNTg3OV0gc2QgMDowOjA6MDogW3Nk
YV0oWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoyNV0gICBnZm46IDAwMDA1NmE0ICBtZm46IDAw
MDA1NmE0DQoNCiAgDQoNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MjZdICAgZ2ZuOiAw
MDAwNTZhNSAgbWZuOiAwMDAwNTZhNQ0KDQpbICA0NjMuOTI1ODgwXSBSZXN1bHQ6IGhvc3Ri
eXRlPShYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjI2XSAgIGdmbjogMDAwMDU2YTYgIG1mbjog
MDAwMDU2YTYNCg0KRElEX0JBRF9UQVJHRVQgZChYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjI2
XSAgIGdmbjogMDAwMDU2YTcgIG1mbjogMDAwMDU2YTcNCg0Kcml2ZXJieXRlPURSSVZFUl9P
Sw0KDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjI2XSAgIGdmbjogMDAwMDU2YTggIG1m
bjogMDAwMDU2YTgNCg0KWyAgNDYzLjkyNTg4MV0gcyhYRU4pIFsyMDEyLTA4LTMxIDIxOjMz
OjI2XSAgIGdmbjogMDAwMDU2YTkgIG1mbjogMDAwMDU2YTkNCg0KZCAwOjA6MDowOiBbc2Rh
XSBDREI6IA0KDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjI2XSAgIGdmbjogMDAwMDU2
YWEgIG1mbjogMDAwMDU2YWENCg0KWyAgNDYzLjkyNTg4NF0gVyhYRU4pIFsyMDEyLTA4LTMx
IDIxOjMzOjI2XSAgIGdmbjogMDAwMDU2YWIgIG1mbjogMDAwMDU2YWINCg0Kcml0ZSgxMCk6
IDJhIDAwIDA1IGM2IGFmIDcxIDAwIDAoWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoyNl0gICBn
Zm46IDAwMDA1NmFjICBtZm46IDAwMDA1NmFjDQoNCjAgMDggMDANCg0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMzoyNl0gICBnZm46IDAwMDA1NmFkICBtZm46IDAwMDA1NmFkDQoNClsg
IDQ2My45MjU4ODVdIGVuZF9yZXF1ZXN0OiBJL08gKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6
MjZdICAgZ2ZuOiAwMDAwNTZhZSAgbWZuOiAwMDAwNTZhZQ0KDQplcnJvciwgZGV2IHNkYSwg
KFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MjZdICAgZ2ZuOiAwMDAwNTZhZiAgbWZuOiAwMDAw
NTZhZg0KDQpzZWN0b3IgOTY5MDcxMjENCg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoy
Nl0gICBnZm46IDAwMDA1NmIwICBtZm46IDAwMDA1NmIwDQoNClsgIDQ2My45MjU4OTFdIHMo
WEVOKSBbMjAxMi0wOC0zMSAyMTozMzoyNl0gICBnZm46IDAwMDA1NmIxICBtZm46IDAwMDA1
NmIxDQoNCmQgMDowOjA6MDogW3NkYV0gVW5oYW5kbGVkIGVycm9yKFhFTikgWzIwMTItMDgt
MzEgMjE6MzM6MjZdICAgZ2ZuOiAwMDAwNTZiMiAgbWZuOiAwMDAwNTZiMg0KDQogY29kZQ0K
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjI2XSAgIGdmbjogMDAwMDU2YjMgIG1mbjog
MDAwMDU2YjMNCg0KWyAgNDYzLjkyNTg5Ml0gc2QgMDowOjA6MDogW3NkYV0oWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMzoyNl0gICBnZm46IDAwMDA1NmI0ICBtZm46IDAwMDA1NmI0DQoNCiAg
DQoNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MjZdICAgZ2ZuOiAwMDAwNTZiNSAgbWZu
OiAwMDAwNTZiNQ0KDQpbICA0NjMuOTI1ODkyXSBSZXN1bHQ6IGhvc3RieXRlPShYRU4pIFsy
MDEyLTA4LTMxIDIxOjMzOjI2XSAgIGdmbjogMDAwMDU2YjYgIG1mbjogMDAwMDU2YjYNCg0K
RElEX0JBRF9UQVJHRVQgZChYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjI2XSAgIGdmbjogMDAw
MDU2YjcgIG1mbjogMDAwMDU2YjcNCg0Kcml2ZXJieXRlPURSSVZFUl9PSw0KDQoNCihYRU4p
IFsyMDEyLTA4LTMxIDIxOjMzOjI2XSAgIGdmbjogMDAwMDU2YjggIG1mbjogMDAwMDU2YjgN
Cg0KWyAgNDYzLjkyNTg5M10gcyhYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjI2XSAgIGdmbjog
MDAwMDU2YjkgIG1mbjogMDAwMDU2YjkNCg0KZCAwOjA6MDowOiBbc2RhXSBDREI6IA0KDQoN
CihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjI2XSAgIGdmbjogMDAwMDU2YmEgIG1mbjogMDAw
MDU2YmENCg0KWyAgNDYzLjkyNTg5Nl0gVyhYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjI2XSAg
IGdmbjogMDAwMDU2YmIgIG1mbjogMDAwMDU2YmINCg0Kcml0ZSgxMCk6IDJhIDAwIDAyIDRl
IDk1IDExIDAwIDAoWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoyNl0gICBnZm46IDAwMDA1NmJj
ICBtZm46IDAwMDA1NmJjDQoNCjAgMDggMDANCg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
MzoyNl0gICBnZm46IDAwMDA1NmJkICBtZm46IDAwMDA1NmJkDQoNClsgIDQ2My45MjU4OTdd
IGUoWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoyNl0gICBnZm46IDAwMDA1NmJlICBtZm46IDAw
MDA1NmJlDQoNCm5kX3JlcXVlc3Q6IEkvTyAoWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoyNl0g
ICBnZm46IDAwMDA1NmJmICBtZm46IDAwMDA1NmJmDQoNCmVycm9yLCBkZXYgc2RhLCAoWEVO
KSBbMjAxMi0wOC0zMSAyMTozMzoyNl0gICBnZm46IDAwMDA1NmMwICBtZm46IDAwMDA1NmMw
DQoNCnNlY3RvciAzODcwNDQwMQ0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MjZdICAgZ2Zu
OiAwMDAwNTZjMSAgbWZuOiAwMDAwNTZjMQ0KDQoNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6
MzM6MjZdICAgZ2ZuOiAwMDAwNTZjMiAgbWZuOiAwMDAwNTZjMg0KDQpbICA0NjMuOTI1OTA3
XSBKKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MjZdICAgZ2ZuOiAwMDAwNTZjMyAgbWZuOiAw
MDAwNTZjMw0KDQpCRDI6IERldGVjdGVkIElPKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MjZd
ICAgZ2ZuOiAwMDAwNTZjNCAgbWZuOiAwMDAwNTZjNA0KDQogZXJyb3JzIHdoaWxlIGZsKFhF
TikgWzIwMTItMDgtMzEgMjE6MzM6MjZdICAgZ2ZuOiAwMDAwNTZjNSAgbWZuOiAwMDAwNTZj
NQ0KDQp1c2hpbmcgZmlsZSBkYXRhIG9uIGRtLTAtOA0KDQoNCihYRU4pIFsyMDEyLTA4LTMx
IDIxOjMzOjI2XSAgIGdmbjogMDAwMDU2YzYgIG1mbjogMDAwMDU2YzYNCg0KWyAgNDcyLjY4
MjMzOV0gcyhYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjI2XSAgIGdmbjogMDAwMDU2YzcgIG1m
bjogMDAwMDU2YzcNCg0KZCAwOjA6MDowOiBbc2RhXSAgDQoNCg0KKFhFTikgWzIwMTItMDgt
MzEgMjE6MzM6MjZdICAgZ2ZuOiAwMDAwNTZjOCAgbWZuOiAwMDAwNTZjOA0KDQpbICA0NzIu
NzIzOTE5XSBSKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MjZdICAgZ2ZuOiAwMDAwNTZjOSAg
bWZuOiAwMDAwNTZjOQ0KDQplc3VsdDogaG9zdGJ5dGU9RElEX0JBRF9UQVJHRVQgZHJpdmVy
Ynl0ZT1EUklWRVIoWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoyNl0gICBnZm46IDAwMDA1NmNh
ICBtZm46IDAwMDA1NmNhDQoNCl9PSw0KDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjI2
XSAgIGdmbjogMDAwMDU2Y2IgIG1mbjogMDAwMDU2Y2INCg0KWyAgNDcyLjc4NjM2MV0gc2Qg
MDowOjA6MDogW3NkYV0oWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoyNl0gICBnZm46IDAwMDA1
NmNjICBtZm46IDAwMDA1NmNjDQoNCiBDREI6IA0KDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMzOjI2XSAgIGdmbjogMDAwMDU2Y2QgIG1mbjogMDAwMDU2Y2QNCg0KWyAgNDcyLjgyNzk2
MF0gV3JpdGUoMTApKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MjZdICAgZ2ZuOiAwMDAwNTZj
ZSAgbWZuOiAwMDAwNTZjZQ0KDQo6KFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MjZdICAgZ2Zu
OiAwMDAwNTZjZiAgbWZuOiAwMDAwNTZjZg0KDQogMmEgMDAoWEVOKSBbMjAxMi0wOC0zMSAy
MTozMzoyNl0gICBnZm46IDAwMDA1NmQwICBtZm46IDAwMDA1NmQwDQoNCiBiZihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMzOjI2XSAgIGdmbjogMDAwMDU2ZDEgIG1mbjogMDAwMDU2ZDENCg0K
IDA5KFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MjZdICAgZ2ZuOiAwMDAwNTZkMiAgbWZuOiAw
MDAwNTZkMg0KDQogMzcoWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoyNl0gICBnZm46IDAwMDA1
NmQzICBtZm46IDAwMDA1NmQzDQoNCiAxMShYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjI2XSAg
IGdmbjogMDAwMDU2ZDQgIG1mbjogMDAwMDU2ZDQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6
MzM6MjZdICAgZ2ZuOiAwMDAwNTZkNSAgbWZuOiAwMDAwNTZkNQ0KDQogMDAoWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMzoyNl0gICBnZm46IDAwMDA1NmQ2ICBtZm46IDAwMDA1NmQ2DQoNCiAw
MChYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjI2XSAgIGdmbjogMDAwMDU2ZDcgIG1mbjogMDAw
MDU2ZDcNCg0KIGIwKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MjddICAgZ2ZuOiAwMDAwNTZk
OCAgbWZuOiAwMDAwNTZkOA0KDQogMDAoWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoyN10gICBn
Zm46IDAwMDA1NmQ5ICBtZm46IDAwMDA1NmQ5DQoNCg0KDQoNCihYRU4pIFsyMDEyLTA4LTMx
IDIxOjMzOjI3XSAgIGdmbjogMDAwMDU2ZGEgIG1mbjogMDAwMDU2ZGENCg0KWyAgNDczLjA0
ODQzNF0gZShYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjI3XSAgIGdmbjogMDAwMDU2ZGIgIG1m
bjogMDAwMDU2ZGINCg0KbmRfcmVxdWVzdDogSS9PIChYRU4pIFsyMDEyLTA4LTMxIDIxOjMz
OjI3XSAgIGdmbjogMDAwMDU2ZGMgIG1mbjogMDAwMDU2ZGMNCg0KZXJyb3IsIGRldiBzZGEs
IChYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjI3XSAgIGdmbjogMDAwMDU2ZGQgIG1mbjogMDAw
MDU2ZGQNCg0Kc2VjdG9yIDMyMDUwNTIxNzcNCg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
MzoyN10gICBnZm46IDAwMDA1NmRlICBtZm46IDAwMDA1NmRlDQoNClsgIDQ3My4xMjc1NDZd
IHMoWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoyN10gICBnZm46IDAwMDA1NmRmICBtZm46IDAw
MDA1NmRmDQoNCmQgMDowOjA6MDogW3NkYV0gVW5oYW5kbGVkIGVycm9yKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzM6MjddICAgZ2ZuOiAwMDAwNTZlMCAgbWZuOiAwMDAwNTZlMA0KDQogY29k
ZQ0KDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjI3XSAgIGdmbjogMDAwMDU2ZTEgIG1m
bjogMDAwMDU2ZTENCg0KWyAgNDczLjE4OTg0MF0gc2QgMDowOjA6MDogW3NkYV0oWEVOKSBb
MjAxMi0wOC0zMSAyMTozMzoyN10gICBnZm46IDAwMDA1NmUyICBtZm46IDAwMDA1NmUyDQoN
CiAgDQoNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MjddICAgZ2ZuOiAwMDAwNTZlMyAg
bWZuOiAwMDAwNTZlMw0KDQpbICA0NzMuMjMxNDMzXSBSZXN1bHQ6IGhvc3RieXRlPShYRU4p
IFsyMDEyLTA4LTMxIDIxOjMzOjI3XSAgIGdmbjogMDAwMDU2ZTQgIG1mbjogMDAwMDU2ZTQN
Cg0KRElEX0JBRF9UQVJHRVQgZChYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjI3XSAgIGdmbjog
MDAwMDU2ZTUgIG1mbjogMDAwMDU2ZTUNCg0Kcml2ZXJieXRlPURSSVZFUl9PSw0KDQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMzOjI3XSAgIGdmbjogMDAwMDU2ZTYgIG1mbjogMDAwMDU2
ZTYNCg0KWyAgNDczLjI5Mzg1NV0gcyhYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjI3XSAgIGdm
bjogMDAwMDU2ZTcgIG1mbjogMDAwMDU2ZTcNCg0KZCAwOjA6MDowOiBbc2RhXSBDREI6IA0K
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjI3XSAgIGdmbjogMDAwMDU2ZTggIG1mbjog
MDAwMDU2ZTgNCg0KWyAgNDczLjMzNTQ0OF0gUihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjI3
XSAgIGdmbjogMDAwMDU2ZTkgIG1mbjogMDAwMDU2ZTkNCg0KZWFkKDEwKShYRU4pIFsyMDEy
LTA4LTMxIDIxOjMzOjI3XSAgIGdmbjogMDAwMDU2ZWEgIG1mbjogMDAwMDU2ZWENCg0KOihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMzOjI3XSAgIGdmbjogMDAwMDU2ZWIgIG1mbjogMDAwMDU2
ZWINCg0KIDI4IDAwKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MjddICAgZ2ZuOiAwMDAwNTZl
YyAgbWZuOiAwMDAwNTZlYw0KDQogYmUoWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoyN10gICBn
Zm46IDAwMDA1NmVkICBtZm46IDAwMDA1NmVkDQoNCiBkZihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMzOjI3XSAgIGdmbjogMDAwMDU2ZWUgIG1mbjogMDAwMDU2ZWUNCg0KIDhiKFhFTikgWzIw
MTItMDgtMzEgMjE6MzM6MjddICAgZ2ZuOiAwMDAwNTZlZiAgbWZuOiAwMDAwNTZlZg0KDQog
NjEoWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoyN10gICBnZm46IDAwMDA1NmYwICBtZm46IDAw
MDA1NmYwDQoNCiAwMChYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjI3XSAgIGdmbjogMDAwMDU2
ZjEgIG1mbjogMDAwMDU2ZjENCg0KIDAyKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MjddICAg
Z2ZuOiAwMDAwNTZmMiAgbWZuOiAwMDAwNTZmMg0KDQogMDAoWEVOKSBbMjAxMi0wOC0zMSAy
MTozMzoyN10gICBnZm46IDAwMDA1NmYzICBtZm46IDAwMDA1NmYzDQoNCiAwMChYRU4pIFsy
MDEyLTA4LTMxIDIxOjMzOjI3XSAgIGdmbjogMDAwMDU2ZjQgIG1mbjogMDAwMDU2ZjQNCg0K
DQoNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MjddICAgZ2ZuOiAwMDAwNTZmNSAgbWZu
OiAwMDAwNTZmNQ0KDQpbICA0NzMuNTU1OTAxXSBlbmRfcmVxdWVzdDogSS9PIChYRU4pIFsy
MDEyLTA4LTMxIDIxOjMzOjI3XSAgIGdmbjogMDAwMDU2ZjYgIG1mbjogMDAwMDU2ZjYNCg0K
ZXJyb3IsIGRldiBzZGEsIChYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjI3XSAgIGdmbjogMDAw
MDU2ZjcgIG1mbjogMDAwMDU2ZjcNCg0Kc2VjdG9yIDMyMDIzMjEyNDkNCg0KDQooWEVOKSBb
MjAxMi0wOC0zMSAyMTozMzoyN10gICBnZm46IDAwMDA1NmY4ICBtZm46IDAwMDA1NmY4DQoN
CihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjI3XSAgIGdmbjogMDAwMDU2ZjkgIG1mbjogMDAw
MDU2ZjkNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MjddICAgZ2ZuOiAwMDAwNTZmYSAg
bWZuOiAwMDAwNTZmYQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoyN10gICBnZm46IDAw
MDA1NmZiICBtZm46IDAwMDA1NmZiDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjI3XSAg
IGdmbjogMDAwMDU2ZmMgIG1mbjogMDAwMDU2ZmMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6
MzM6MjddICAgZ2ZuOiAwMDAwNTZmZCAgbWZuOiAwMDAwNTZmZA0KDQooWEVOKSBbMjAxMi0w
OC0zMSAyMTozMzoyN10gICBnZm46IDAwMDA1NmZlICBtZm46IDAwMDA1NmZlDQoNCihYRU4p
IFsyMDEyLTA4LTMxIDIxOjMzOjI3XSAgIGdmbjogMDAwMDU2ZmYgIG1mbjogMDAwMDU2ZmYN
Cg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MjddICAgZ2ZuOiAwMDAwNTcwMCAgbWZuOiAw
MDAwNTcwMA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoyN10gICBnZm46IDAwMDA1NzAx
ICBtZm46IDAwMDA1NzAxDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjI3XSAgIGdmbjog
MDAwMDU3MDIgIG1mbjogMDAwMDU3MDINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6Mjdd
ICAgZ2ZuOiAwMDAwNTcwMyAgbWZuOiAwMDAwNTcwMw0KDQooWEVOKSBbMjAxMi0wOC0zMSAy
MTozMzoyN10gICBnZm46IDAwMDA1NzA0ICBtZm46IDAwMDA1NzA0DQoNCihYRU4pIFsyMDEy
LTA4LTMxIDIxOjMzOjI3XSAgIGdmbjogMDAwMDU3MDUgIG1mbjogMDAwMDU3MDUNCg0KKFhF
TikgWzIwMTItMDgtMzEgMjE6MzM6MjddICAgZ2ZuOiAwMDAwNTcwNiAgbWZuOiAwMDAwNTcw
Ng0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoyN10gICBnZm46IDAwMDA1NzA3ICBtZm46
IDAwMDA1NzA3DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjI3XSAgIGdmbjogMDAwMDU3
MDggIG1mbjogMDAwMDU3MDgNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MjddICAgZ2Zu
OiAwMDAwNTcwOSAgbWZuOiAwMDAwNTcwOQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoy
N10gICBnZm46IDAwMDA1NzBhICBtZm46IDAwMDA1NzBhDQoNCihYRU4pIFsyMDEyLTA4LTMx
IDIxOjMzOjI3XSAgIGdmbjogMDAwMDU3MGIgIG1mbjogMDAwMDU3MGINCg0KKFhFTikgWzIw
MTItMDgtMzEgMjE6MzM6MjddICAgZ2ZuOiAwMDAwNTcwYyAgbWZuOiAwMDAwNTcwYw0KDQoo
WEVOKSBbMjAxMi0wOC0zMSAyMTozMzoyN10gICBnZm46IDAwMDA1NzBkICBtZm46IDAwMDA1
NzBkDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjI3XSAgIGdmbjogMDAwMDU3MGUgIG1m
bjogMDAwMDU3MGUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MjddICAgZ2ZuOiAwMDAw
NTcwZiAgbWZuOiAwMDAwNTcwZg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoyN10gICBn
Zm46IDAwMDA1NzEwICBtZm46IDAwMDA1NzEwDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMz
OjI4XSAgIGdmbjogMDAwMDU3MTEgIG1mbjogMDAwMDU3MTENCg0KKFhFTikgWzIwMTItMDgt
MzEgMjE6MzM6MjhdICAgZ2ZuOiAwMDAwNTcxMiAgbWZuOiAwMDAwNTcxMg0KDQooWEVOKSBb
MjAxMi0wOC0zMSAyMTozMzoyOF0gICBnZm46IDAwMDA1NzEzICBtZm46IDAwMDA1NzEzDQoN
CihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjI4XSAgIGdmbjogMDAwMDU3MTQgIG1mbjogMDAw
MDU3MTQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MjhdICAgZ2ZuOiAwMDAwNTcxNSAg
bWZuOiAwMDAwNTcxNQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoyOF0gICBnZm46IDAw
MDA1NzE2ICBtZm46IDAwMDA1NzE2DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjI4XSAg
IGdmbjogMDAwMDU3MTcgIG1mbjogMDAwMDU3MTcNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6
MzM6MjhdICAgZ2ZuOiAwMDAwNTcxOCAgbWZuOiAwMDAwNTcxOA0KDQooWEVOKSBbMjAxMi0w
OC0zMSAyMTozMzoyOF0gICBnZm46IDAwMDA1NzE5ICBtZm46IDAwMDA1NzE5DQoNCihYRU4p
IFsyMDEyLTA4LTMxIDIxOjMzOjI4XSAgIGdmbjogMDAwMDU3MWEgIG1mbjogMDAwMDU3MWEN
Cg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MjhdICAgZ2ZuOiAwMDAwNTcxYiAgbWZuOiAw
MDAwNTcxYg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoyOF0gICBnZm46IDAwMDA1NzFj
ICBtZm46IDAwMDA1NzFjDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjI4XSAgIGdmbjog
MDAwMDU3MWQgIG1mbjogMDAwMDU3MWQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6Mjhd
ICAgZ2ZuOiAwMDAwNTcxZSAgbWZuOiAwMDAwNTcxZQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAy
MTozMzoyOF0gICBnZm46IDAwMDA1NzFmICBtZm46IDAwMDA1NzFmDQoNCihYRU4pIFsyMDEy
LTA4LTMxIDIxOjMzOjI4XSAgIGdmbjogMDAwMDU3MjAgIG1mbjogMDAwMDU3MjANCg0KKFhF
TikgWzIwMTItMDgtMzEgMjE6MzM6MjhdICAgZ2ZuOiAwMDAwNTcyMSAgbWZuOiAwMDAwNTcy
MQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoyOF0gICBnZm46IDAwMDA1NzIyICBtZm46
IDAwMDA1NzIyDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjI4XSAgIGdmbjogMDAwMDU3
MjMgIG1mbjogMDAwMDU3MjMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MjhdICAgZ2Zu
OiAwMDAwNTcyNCAgbWZuOiAwMDAwNTcyNA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoy
OF0gICBnZm46IDAwMDA1NzI1ICBtZm46IDAwMDA1NzI1DQoNCihYRU4pIFsyMDEyLTA4LTMx
IDIxOjMzOjI4XSAgIGdmbjogMDAwMDU3MjYgIG1mbjogMDAwMDU3MjYNCg0KKFhFTikgWzIw
MTItMDgtMzEgMjE6MzM6MjhdICAgZ2ZuOiAwMDAwNTcyNyAgbWZuOiAwMDAwNTcyNw0KDQoo
WEVOKSBbMjAxMi0wOC0zMSAyMTozMzoyOF0gICBnZm46IDAwMDA1NzI4ICBtZm46IDAwMDA1
NzI4DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjI4XSAgIGdmbjogMDAwMDU3MjkgIG1m
bjogMDAwMDU3MjkNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MjhdICAgZ2ZuOiAwMDAw
NTcyYSAgbWZuOiAwMDAwNTcyYQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoyOF0gICBn
Zm46IDAwMDA1NzJiICBtZm46IDAwMDA1NzJiDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMz
OjI4XSAgIGdmbjogMDAwMDU3MmMgIG1mbjogMDAwMDU3MmMNCg0KKFhFTikgWzIwMTItMDgt
MzEgMjE6MzM6MjhdICAgZ2ZuOiAwMDAwNTcyZCAgbWZuOiAwMDAwNTcyZA0KDQooWEVOKSBb
MjAxMi0wOC0zMSAyMTozMzoyOF0gICBnZm46IDAwMDA1NzJlICBtZm46IDAwMDA1NzJlDQoN
CihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjI4XSAgIGdmbjogMDAwMDU3MmYgIG1mbjogMDAw
MDU3MmYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MjhdICAgZ2ZuOiAwMDAwNTczMCAg
bWZuOiAwMDAwNTczMA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoyOF0gICBnZm46IDAw
MDA1NzMxICBtZm46IDAwMDA1NzMxDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjI4XSAg
IGdmbjogMDAwMDU3MzIgIG1mbjogMDAwMDU3MzINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6
MzM6MjhdICAgZ2ZuOiAwMDAwNTczMyAgbWZuOiAwMDAwNTczMw0KDQooWEVOKSBbMjAxMi0w
OC0zMSAyMTozMzoyOF0gICBnZm46IDAwMDA1NzM0ICBtZm46IDAwMDA1NzM0DQoNCihYRU4p
IFsyMDEyLTA4LTMxIDIxOjMzOjI4XSAgIGdmbjogMDAwMDU3MzUgIG1mbjogMDAwMDU3MzUN
Cg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MjhdICAgZ2ZuOiAwMDAwNTczNiAgbWZuOiAw
MDAwNTczNg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoyOF0gICBnZm46IDAwMDA1NzM3
ICBtZm46IDAwMDA1NzM3DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjI4XSAgIGdmbjog
MDAwMDU3MzggIG1mbjogMDAwMDU3MzgNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6Mjhd
ICAgZ2ZuOiAwMDAwNTczOSAgbWZuOiAwMDAwNTczOQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAy
MTozMzoyOF0gICBnZm46IDAwMDA1NzNhICBtZm46IDAwMDA1NzNhDQoNCihYRU4pIFsyMDEy
LTA4LTMxIDIxOjMzOjI4XSAgIGdmbjogMDAwMDU3M2IgIG1mbjogMDAwMDU3M2INCg0KKFhF
TikgWzIwMTItMDgtMzEgMjE6MzM6MjhdICAgZ2ZuOiAwMDAwNTczYyAgbWZuOiAwMDAwNTcz
Yw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoyOF0gICBnZm46IDAwMDA1NzNkICBtZm46
IDAwMDA1NzNkDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjI4XSAgIGdmbjogMDAwMDU3
M2UgIG1mbjogMDAwMDU3M2UNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MjhdICAgZ2Zu
OiAwMDAwNTczZiAgbWZuOiAwMDAwNTczZg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoy
OF0gICBnZm46IDAwMDA1NzQwICBtZm46IDAwMDA1NzQwDQoNCihYRU4pIFsyMDEyLTA4LTMx
IDIxOjMzOjI4XSAgIGdmbjogMDAwMDU3NDEgIG1mbjogMDAwMDU3NDENCg0KKFhFTikgWzIw
MTItMDgtMzEgMjE6MzM6MjhdICAgZ2ZuOiAwMDAwNTc0MiAgbWZuOiAwMDAwNTc0Mg0KDQoo
WEVOKSBbMjAxMi0wOC0zMSAyMTozMzoyOF0gICBnZm46IDAwMDA1NzQzICBtZm46IDAwMDA1
NzQzDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjI4XSAgIGdmbjogMDAwMDU3NDQgIG1m
bjogMDAwMDU3NDQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MjhdICAgZ2ZuOiAwMDAw
NTc0NSAgbWZuOiAwMDAwNTc0NQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoyOF0gICBn
Zm46IDAwMDA1NzQ2ICBtZm46IDAwMDA1NzQ2DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMz
OjI4XSAgIGdmbjogMDAwMDU3NDcgIG1mbjogMDAwMDU3NDcNCg0KKFhFTikgWzIwMTItMDgt
MzEgMjE6MzM6MjhdICAgZ2ZuOiAwMDAwNTc0OCAgbWZuOiAwMDAwNTc0OA0KDQooWEVOKSBb
MjAxMi0wOC0zMSAyMTozMzoyOF0gICBnZm46IDAwMDA1NzQ5ICBtZm46IDAwMDA1NzQ5DQoN
CihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjI4XSAgIGdmbjogMDAwMDU3NGEgIG1mbjogMDAw
MDU3NGENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MjhdICAgZ2ZuOiAwMDAwNTc0YiAg
bWZuOiAwMDAwNTc0Yg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoyOF0gICBnZm46IDAw
MDA1NzRjICBtZm46IDAwMDA1NzRjDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjI4XSAg
IGdmbjogMDAwMDU3NGQgIG1mbjogMDAwMDU3NGQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6
MzM6MjhdICAgZ2ZuOiAwMDAwNTc0ZSAgbWZuOiAwMDAwNTc0ZQ0KDQooWEVOKSBbMjAxMi0w
OC0zMSAyMTozMzoyOF0gICBnZm46IDAwMDA1NzRmICBtZm46IDAwMDA1NzRmDQoNCihYRU4p
IFsyMDEyLTA4LTMxIDIxOjMzOjI4XSAgIGdmbjogMDAwMDU3NTAgIG1mbjogMDAwMDU3NTAN
Cg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MjldICAgZ2ZuOiAwMDAwNTc1MSAgbWZuOiAw
MDAwNTc1MQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoyOV0gICBnZm46IDAwMDA1NzUy
ICBtZm46IDAwMDA1NzUyDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjI5XSAgIGdmbjog
MDAwMDU3NTMgIG1mbjogMDAwMDU3NTMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6Mjld
ICAgZ2ZuOiAwMDAwNTc1NCAgbWZuOiAwMDAwNTc1NA0KDQooWEVOKSBbMjAxMi0wOC0zMSAy
MTozMzoyOV0gICBnZm46IDAwMDA1NzU1ICBtZm46IDAwMDA1NzU1DQoNCihYRU4pIFsyMDEy
LTA4LTMxIDIxOjMzOjI5XSAgIGdmbjogMDAwMDU3NTYgIG1mbjogMDAwMDU3NTYNCg0KKFhF
TikgWzIwMTItMDgtMzEgMjE6MzM6MjldICAgZ2ZuOiAwMDAwNTc1NyAgbWZuOiAwMDAwNTc1
Nw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoyOV0gICBnZm46IDAwMDA1NzU4ICBtZm46
IDAwMDA1NzU4DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjI5XSAgIGdmbjogMDAwMDU3
NTkgIG1mbjogMDAwMDU3NTkNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MjldICAgZ2Zu
OiAwMDAwNTc1YSAgbWZuOiAwMDAwNTc1YQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoy
OV0gICBnZm46IDAwMDA1NzViICBtZm46IDAwMDA1NzViDQoNCihYRU4pIFsyMDEyLTA4LTMx
IDIxOjMzOjI5XSAgIGdmbjogMDAwMDU3NWMgIG1mbjogMDAwMDU3NWMNCg0KKFhFTikgWzIw
MTItMDgtMzEgMjE6MzM6MjldICAgZ2ZuOiAwMDAwNTc1ZCAgbWZuOiAwMDAwNTc1ZA0KDQoo
WEVOKSBbMjAxMi0wOC0zMSAyMTozMzoyOV0gICBnZm46IDAwMDA1NzVlICBtZm46IDAwMDA1
NzVlDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjI5XSAgIGdmbjogMDAwMDU3NWYgIG1m
bjogMDAwMDU3NWYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MjldICAgZ2ZuOiAwMDAw
NTc2MCAgbWZuOiAwMDAwNTc2MA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoyOV0gICBn
Zm46IDAwMDA1NzYxICBtZm46IDAwMDA1NzYxDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMz
OjI5XSAgIGdmbjogMDAwMDU3NjIgIG1mbjogMDAwMDU3NjINCg0KKFhFTikgWzIwMTItMDgt
MzEgMjE6MzM6MjldICAgZ2ZuOiAwMDAwNTc2MyAgbWZuOiAwMDAwNTc2Mw0KDQooWEVOKSBb
MjAxMi0wOC0zMSAyMTozMzoyOV0gICBnZm46IDAwMDA1NzY0ICBtZm46IDAwMDA1NzY0DQoN
CihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjI5XSAgIGdmbjogMDAwMDU3NjUgIG1mbjogMDAw
MDU3NjUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MjldICAgZ2ZuOiAwMDAwNTc2NiAg
bWZuOiAwMDAwNTc2Ng0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoyOV0gICBnZm46IDAw
MDA1NzY3ICBtZm46IDAwMDA1NzY3DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjI5XSAg
IGdmbjogMDAwMDU3NjggIG1mbjogMDAwMDU3NjgNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6
MzM6MjldICAgZ2ZuOiAwMDAwNTc2OSAgbWZuOiAwMDAwNTc2OQ0KDQooWEVOKSBbMjAxMi0w
OC0zMSAyMTozMzoyOV0gICBnZm46IDAwMDA1NzZhICBtZm46IDAwMDA1NzZhDQoNCihYRU4p
IFsyMDEyLTA4LTMxIDIxOjMzOjI5XSAgIGdmbjogMDAwMDU3NmIgIG1mbjogMDAwMDU3NmIN
Cg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MjldICAgZ2ZuOiAwMDAwNTc2YyAgbWZuOiAw
MDAwNTc2Yw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoyOV0gICBnZm46IDAwMDA1NzZk
ICBtZm46IDAwMDA1NzZkDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjI5XSAgIGdmbjog
MDAwMDU3NmUgIG1mbjogMDAwMDU3NmUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6Mjld
ICAgZ2ZuOiAwMDAwNTc2ZiAgbWZuOiAwMDAwNTc2Zg0KDQooWEVOKSBbMjAxMi0wOC0zMSAy
MTozMzoyOV0gICBnZm46IDAwMDA1NzcwICBtZm46IDAwMDA1NzcwDQoNCihYRU4pIFsyMDEy
LTA4LTMxIDIxOjMzOjI5XSAgIGdmbjogMDAwMDU3NzEgIG1mbjogMDAwMDU3NzENCg0KKFhF
TikgWzIwMTItMDgtMzEgMjE6MzM6MjldICAgZ2ZuOiAwMDAwNTc3MiAgbWZuOiAwMDAwNTc3
Mg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoyOV0gICBnZm46IDAwMDA1NzczICBtZm46
IDAwMDA1NzczDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjI5XSAgIGdmbjogMDAwMDU3
NzQgIG1mbjogMDAwMDU3NzQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MjldICAgZ2Zu
OiAwMDAwNTc3NSAgbWZuOiAwMDAwNTc3NQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoy
OV0gICBnZm46IDAwMDA1Nzc2ICBtZm46IDAwMDA1Nzc2DQoNCihYRU4pIFsyMDEyLTA4LTMx
IDIxOjMzOjI5XSAgIGdmbjogMDAwMDU3NzcgIG1mbjogMDAwMDU3NzcNCg0KKFhFTikgWzIw
MTItMDgtMzEgMjE6MzM6MjldICAgZ2ZuOiAwMDAwNTc3OCAgbWZuOiAwMDAwNTc3OA0KDQoo
WEVOKSBbMjAxMi0wOC0zMSAyMTozMzoyOV0gICBnZm46IDAwMDA1Nzc5ICBtZm46IDAwMDA1
Nzc5DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjI5XSAgIGdmbjogMDAwMDU3N2EgIG1m
bjogMDAwMDU3N2ENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MjldICAgZ2ZuOiAwMDAw
NTc3YiAgbWZuOiAwMDAwNTc3Yg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoyOV0gICBn
Zm46IDAwMDA1NzdjICBtZm46IDAwMDA1NzdjDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMz
OjI5XSAgIGdmbjogMDAwMDU3N2QgIG1mbjogMDAwMDU3N2QNCg0KKFhFTikgWzIwMTItMDgt
MzEgMjE6MzM6MjldICAgZ2ZuOiAwMDAwNTc3ZSAgbWZuOiAwMDAwNTc3ZQ0KDQooWEVOKSBb
MjAxMi0wOC0zMSAyMTozMzoyOV0gICBnZm46IDAwMDA1NzdmICBtZm46IDAwMDA1NzdmDQoN
CihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjI5XSAgIGdmbjogMDAwMDU3ODAgIG1mbjogMDAw
MDU3ODANCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MjldICAgZ2ZuOiAwMDAwNTc4MSAg
bWZuOiAwMDAwNTc4MQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoyOV0gICBnZm46IDAw
MDA1NzgyICBtZm46IDAwMDA1NzgyDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjI5XSAg
IGdmbjogMDAwMDU3ODMgIG1mbjogMDAwMDU3ODMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6
MzM6MjldICAgZ2ZuOiAwMDAwNTc4NCAgbWZuOiAwMDAwNTc4NA0KDQooWEVOKSBbMjAxMi0w
OC0zMSAyMTozMzoyOV0gICBnZm46IDAwMDA1Nzg1ICBtZm46IDAwMDA1Nzg1DQoNCihYRU4p
IFsyMDEyLTA4LTMxIDIxOjMzOjI5XSAgIGdmbjogMDAwMDU3ODYgIG1mbjogMDAwMDU3ODYN
Cg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MjldICAgZ2ZuOiAwMDAwNTc4NyAgbWZuOiAw
MDAwNTc4Nw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoyOV0gICBnZm46IDAwMDA1Nzg4
ICBtZm46IDAwMDA1Nzg4DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjI5XSAgIGdmbjog
MDAwMDU3ODkgIG1mbjogMDAwMDU3ODkNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6Mjld
ICAgZ2ZuOiAwMDAwNTc4YSAgbWZuOiAwMDAwNTc4YQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAy
MTozMzoyOV0gICBnZm46IDAwMDA1NzhiICBtZm46IDAwMDA1NzhiDQoNCihYRU4pIFsyMDEy
LTA4LTMxIDIxOjMzOjI5XSAgIGdmbjogMDAwMDU3OGMgIG1mbjogMDAwMDU3OGMNCg0KKFhF
TikgWzIwMTItMDgtMzEgMjE6MzM6MjldICAgZ2ZuOiAwMDAwNTc4ZCAgbWZuOiAwMDAwNTc4
ZA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoyOV0gICBnZm46IDAwMDA1NzhlICBtZm46
IDAwMDA1NzhlDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjI5XSAgIGdmbjogMDAwMDU3
OGYgIG1mbjogMDAwMDU3OGYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MjldICAgZ2Zu
OiAwMDAwNTc5MCAgbWZuOiAwMDAwNTc5MA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoz
MF0gICBnZm46IDAwMDA1NzkxICBtZm46IDAwMDA1NzkxDQoNCihYRU4pIFsyMDEyLTA4LTMx
IDIxOjMzOjMwXSAgIGdmbjogMDAwMDU3OTIgIG1mbjogMDAwMDU3OTINCg0KKFhFTikgWzIw
MTItMDgtMzEgMjE6MzM6MzBdICAgZ2ZuOiAwMDAwNTc5MyAgbWZuOiAwMDAwNTc5Mw0KDQoo
WEVOKSBbMjAxMi0wOC0zMSAyMTozMzozMF0gICBnZm46IDAwMDA1Nzk0ICBtZm46IDAwMDA1
Nzk0DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjMwXSAgIGdmbjogMDAwMDU3OTUgIG1m
bjogMDAwMDU3OTUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MzBdICAgZ2ZuOiAwMDAw
NTc5NiAgbWZuOiAwMDAwNTc5Ng0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzozMF0gICBn
Zm46IDAwMDA1Nzk3ICBtZm46IDAwMDA1Nzk3DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMz
OjMwXSAgIGdmbjogMDAwMDU3OTggIG1mbjogMDAwMDU3OTgNCg0KKFhFTikgWzIwMTItMDgt
MzEgMjE6MzM6MzBdICAgZ2ZuOiAwMDAwNTc5OSAgbWZuOiAwMDAwNTc5OQ0KDQooWEVOKSBb
MjAxMi0wOC0zMSAyMTozMzozMF0gICBnZm46IDAwMDA1NzlhICBtZm46IDAwMDA1NzlhDQoN
CihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjMwXSAgIGdmbjogMDAwMDU3OWIgIG1mbjogMDAw
MDU3OWINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MzBdICAgZ2ZuOiAwMDAwNTc5YyAg
bWZuOiAwMDAwNTc5Yw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzozMF0gICBnZm46IDAw
MDA1NzlkICBtZm46IDAwMDA1NzlkDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjMwXSAg
IGdmbjogMDAwMDU3OWUgIG1mbjogMDAwMDU3OWUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6
MzM6MzBdICAgZ2ZuOiAwMDAwNTc5ZiAgbWZuOiAwMDAwNTc5Zg0KDQooWEVOKSBbMjAxMi0w
OC0zMSAyMTozMzozMF0gICBnZm46IDAwMDA1N2EwICBtZm46IDAwMDA1N2EwDQoNCihYRU4p
IFsyMDEyLTA4LTMxIDIxOjMzOjMwXSAgIGdmbjogMDAwMDU3YTEgIG1mbjogMDAwMDU3YTEN
Cg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MzBdICAgZ2ZuOiAwMDAwNTdhMiAgbWZuOiAw
MDAwNTdhMg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzozMF0gICBnZm46IDAwMDA1N2Ez
ICBtZm46IDAwMDA1N2EzDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjMwXSAgIGdmbjog
MDAwMDU3YTQgIG1mbjogMDAwMDU3YTQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MzBd
ICAgZ2ZuOiAwMDAwNTdhNSAgbWZuOiAwMDAwNTdhNQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAy
MTozMzozMF0gICBnZm46IDAwMDA1N2E2ICBtZm46IDAwMDA1N2E2DQoNCihYRU4pIFsyMDEy
LTA4LTMxIDIxOjMzOjMwXSAgIGdmbjogMDAwMDU3YTcgIG1mbjogMDAwMDU3YTcNCg0KKFhF
TikgWzIwMTItMDgtMzEgMjE6MzM6MzBdICAgZ2ZuOiAwMDAwNTdhOCAgbWZuOiAwMDAwNTdh
OA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzozMF0gICBnZm46IDAwMDA1N2E5ICBtZm46
IDAwMDA1N2E5DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjMwXSAgIGdmbjogMDAwMDU3
YWEgIG1mbjogMDAwMDU3YWENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MzBdICAgZ2Zu
OiAwMDAwNTdhYiAgbWZuOiAwMDAwNTdhYg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoz
MF0gICBnZm46IDAwMDA1N2FjICBtZm46IDAwMDA1N2FjDQoNCihYRU4pIFsyMDEyLTA4LTMx
IDIxOjMzOjMwXSAgIGdmbjogMDAwMDU3YWQgIG1mbjogMDAwMDU3YWQNCg0KKFhFTikgWzIw
MTItMDgtMzEgMjE6MzM6MzBdICAgZ2ZuOiAwMDAwNTdhZSAgbWZuOiAwMDAwNTdhZQ0KDQoo
WEVOKSBbMjAxMi0wOC0zMSAyMTozMzozMF0gICBnZm46IDAwMDA1N2FmICBtZm46IDAwMDA1
N2FmDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjMwXSAgIGdmbjogMDAwMDU3YjAgIG1m
bjogMDAwMDU3YjANCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MzBdICAgZ2ZuOiAwMDAw
NTdiMSAgbWZuOiAwMDAwNTdiMQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzozMF0gICBn
Zm46IDAwMDA1N2IyICBtZm46IDAwMDA1N2IyDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMz
OjMwXSAgIGdmbjogMDAwMDU3YjMgIG1mbjogMDAwMDU3YjMNCg0KKFhFTikgWzIwMTItMDgt
MzEgMjE6MzM6MzBdICAgZ2ZuOiAwMDAwNTdiNCAgbWZuOiAwMDAwNTdiNA0KDQooWEVOKSBb
MjAxMi0wOC0zMSAyMTozMzozMF0gICBnZm46IDAwMDA1N2I1ICBtZm46IDAwMDA1N2I1DQoN
CihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjMwXSAgIGdmbjogMDAwMDU3YjYgIG1mbjogMDAw
MDU3YjYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MzBdICAgZ2ZuOiAwMDAwNTdiNyAg
bWZuOiAwMDAwNTdiNw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzozMF0gICBnZm46IDAw
MDA1N2I4ICBtZm46IDAwMDA1N2I4DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjMwXSAg
IGdmbjogMDAwMDU3YjkgIG1mbjogMDAwMDU3YjkNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6
MzM6MzBdICAgZ2ZuOiAwMDAwNTdiYSAgbWZuOiAwMDAwNTdiYQ0KDQooWEVOKSBbMjAxMi0w
OC0zMSAyMTozMzozMF0gICBnZm46IDAwMDA1N2JiICBtZm46IDAwMDA1N2JiDQoNCihYRU4p
IFsyMDEyLTA4LTMxIDIxOjMzOjMwXSAgIGdmbjogMDAwMDU3YmMgIG1mbjogMDAwMDU3YmMN
Cg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MzBdICAgZ2ZuOiAwMDAwNTdiZCAgbWZuOiAw
MDAwNTdiZA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzozMF0gICBnZm46IDAwMDA1N2Jl
ICBtZm46IDAwMDA1N2JlDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjMwXSAgIGdmbjog
MDAwMDU3YmYgIG1mbjogMDAwMDU3YmYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MzBd
ICAgZ2ZuOiAwMDAwNTdjMCAgbWZuOiAwMDAwNTdjMA0KDQooWEVOKSBbMjAxMi0wOC0zMSAy
MTozMzozMF0gICBnZm46IDAwMDA1N2MxICBtZm46IDAwMDA1N2MxDQoNCihYRU4pIFsyMDEy
LTA4LTMxIDIxOjMzOjMwXSAgIGdmbjogMDAwMDU3YzIgIG1mbjogMDAwMDU3YzINCg0KKFhF
TikgWzIwMTItMDgtMzEgMjE6MzM6MzBdICAgZ2ZuOiAwMDAwNTdjMyAgbWZuOiAwMDAwNTdj
Mw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzozMF0gICBnZm46IDAwMDA1N2M0ICBtZm46
IDAwMDA1N2M0DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjMwXSAgIGdmbjogMDAwMDU3
YzUgIG1mbjogMDAwMDU3YzUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MzBdICAgZ2Zu
OiAwMDAwNTdjNiAgbWZuOiAwMDAwNTdjNg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoz
MF0gICBnZm46IDAwMDA1N2M3ICBtZm46IDAwMDA1N2M3DQoNCihYRU4pIFsyMDEyLTA4LTMx
IDIxOjMzOjMwXSAgIGdmbjogMDAwMDU3YzggIG1mbjogMDAwMDU3YzgNCg0KKFhFTikgWzIw
MTItMDgtMzEgMjE6MzM6MzBdICAgZ2ZuOiAwMDAwNTdjOSAgbWZuOiAwMDAwNTdjOQ0KDQoo
WEVOKSBbMjAxMi0wOC0zMSAyMTozMzozMF0gICBnZm46IDAwMDA1N2NhICBtZm46IDAwMDA1
N2NhDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjMwXSAgIGdmbjogMDAwMDU3Y2IgIG1m
bjogMDAwMDU3Y2INCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MzBdICAgZ2ZuOiAwMDAw
NTdjYyAgbWZuOiAwMDAwNTdjYw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzozMF0gICBn
Zm46IDAwMDA1N2NkICBtZm46IDAwMDA1N2NkDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMz
OjMwXSAgIGdmbjogMDAwMDU3Y2UgIG1mbjogMDAwMDU3Y2UNCg0KKFhFTikgWzIwMTItMDgt
MzEgMjE6MzM6MzBdICAgZ2ZuOiAwMDAwNTdjZiAgbWZuOiAwMDAwNTdjZg0KDQooWEVOKSBb
MjAxMi0wOC0zMSAyMTozMzozMF0gICBnZm46IDAwMDA1N2QwICBtZm46IDAwMDA1N2QwDQoN
CihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjMxXSAgIGdmbjogMDAwMDU3ZDEgIG1mbjogMDAw
MDU3ZDENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MzFdICAgZ2ZuOiAwMDAwNTdkMiAg
bWZuOiAwMDAwNTdkMg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzozMV0gICBnZm46IDAw
MDA1N2QzICBtZm46IDAwMDA1N2QzDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjMxXSAg
IGdmbjogMDAwMDU3ZDQgIG1mbjogMDAwMDU3ZDQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6
MzM6MzFdICAgZ2ZuOiAwMDAwNTdkNSAgbWZuOiAwMDAwNTdkNQ0KDQooWEVOKSBbMjAxMi0w
OC0zMSAyMTozMzozMV0gICBnZm46IDAwMDA1N2Q2ICBtZm46IDAwMDA1N2Q2DQoNCihYRU4p
IFsyMDEyLTA4LTMxIDIxOjMzOjMxXSAgIGdmbjogMDAwMDU3ZDcgIG1mbjogMDAwMDU3ZDcN
Cg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MzFdICAgZ2ZuOiAwMDAwNTdkOCAgbWZuOiAw
MDAwNTdkOA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzozMV0gICBnZm46IDAwMDA1N2Q5
ICBtZm46IDAwMDA1N2Q5DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjMxXSAgIGdmbjog
MDAwMDU3ZGEgIG1mbjogMDAwMDU3ZGENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MzFd
ICAgZ2ZuOiAwMDAwNTdkYiAgbWZuOiAwMDAwNTdkYg0KDQooWEVOKSBbMjAxMi0wOC0zMSAy
MTozMzozMV0gICBnZm46IDAwMDA1N2RjICBtZm46IDAwMDA1N2RjDQoNCihYRU4pIFsyMDEy
LTA4LTMxIDIxOjMzOjMxXSAgIGdmbjogMDAwMDU3ZGQgIG1mbjogMDAwMDU3ZGQNCg0KKFhF
TikgWzIwMTItMDgtMzEgMjE6MzM6MzFdICAgZ2ZuOiAwMDAwNTdkZSAgbWZuOiAwMDAwNTdk
ZQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzozMV0gICBnZm46IDAwMDA1N2RmICBtZm46
IDAwMDA1N2RmDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjMxXSAgIGdmbjogMDAwMDU3
ZTAgIG1mbjogMDAwMDU3ZTANCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MzFdICAgZ2Zu
OiAwMDAwNTdlMSAgbWZuOiAwMDAwNTdlMQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoz
MV0gICBnZm46IDAwMDA1N2UyICBtZm46IDAwMDA1N2UyDQoNCihYRU4pIFsyMDEyLTA4LTMx
IDIxOjMzOjMxXSAgIGdmbjogMDAwMDU3ZTMgIG1mbjogMDAwMDU3ZTMNCg0KKFhFTikgWzIw
MTItMDgtMzEgMjE6MzM6MzFdICAgZ2ZuOiAwMDAwNTdlNCAgbWZuOiAwMDAwNTdlNA0KDQoo
WEVOKSBbMjAxMi0wOC0zMSAyMTozMzozMV0gICBnZm46IDAwMDA1N2U1ICBtZm46IDAwMDA1
N2U1DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjMxXSAgIGdmbjogMDAwMDU3ZTYgIG1m
bjogMDAwMDU3ZTYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MzFdICAgZ2ZuOiAwMDAw
NTdlNyAgbWZuOiAwMDAwNTdlNw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzozMV0gICBn
Zm46IDAwMDA1N2U4ICBtZm46IDAwMDA1N2U4DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMz
OjMxXSAgIGdmbjogMDAwMDU3ZTkgIG1mbjogMDAwMDU3ZTkNCg0KKFhFTikgWzIwMTItMDgt
MzEgMjE6MzM6MzFdICAgZ2ZuOiAwMDAwNTdlYSAgbWZuOiAwMDAwNTdlYQ0KDQooWEVOKSBb
MjAxMi0wOC0zMSAyMTozMzozMV0gICBnZm46IDAwMDA1N2ViICBtZm46IDAwMDA1N2ViDQoN
CihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjMxXSAgIGdmbjogMDAwMDU3ZWMgIG1mbjogMDAw
MDU3ZWMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MzFdICAgZ2ZuOiAwMDAwNTdlZCAg
bWZuOiAwMDAwNTdlZA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzozMV0gICBnZm46IDAw
MDA1N2VlICBtZm46IDAwMDA1N2VlDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjMxXSAg
IGdmbjogMDAwMDU3ZWYgIG1mbjogMDAwMDU3ZWYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6
MzM6MzFdICAgZ2ZuOiAwMDAwNTdmMCAgbWZuOiAwMDAwNTdmMA0KDQooWEVOKSBbMjAxMi0w
OC0zMSAyMTozMzozMV0gICBnZm46IDAwMDA1N2YxICBtZm46IDAwMDA1N2YxDQoNCihYRU4p
IFsyMDEyLTA4LTMxIDIxOjMzOjMxXSAgIGdmbjogMDAwMDU3ZjIgIG1mbjogMDAwMDU3ZjIN
Cg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MzFdICAgZ2ZuOiAwMDAwNTdmMyAgbWZuOiAw
MDAwNTdmMw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzozMV0gICBnZm46IDAwMDA1N2Y0
ICBtZm46IDAwMDA1N2Y0DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjMxXSAgIGdmbjog
MDAwMDU3ZjUgIG1mbjogMDAwMDU3ZjUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MzFd
ICAgZ2ZuOiAwMDAwNTdmNiAgbWZuOiAwMDAwNTdmNg0KDQooWEVOKSBbMjAxMi0wOC0zMSAy
MTozMzozMV0gICBnZm46IDAwMDA1N2Y3ICBtZm46IDAwMDA1N2Y3DQoNCihYRU4pIFsyMDEy
LTA4LTMxIDIxOjMzOjMxXSAgIGdmbjogMDAwMDU3ZjggIG1mbjogMDAwMDU3ZjgNCg0KKFhF
TikgWzIwMTItMDgtMzEgMjE6MzM6MzFdICAgZ2ZuOiAwMDAwNTdmOSAgbWZuOiAwMDAwNTdm
OQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzozMV0gICBnZm46IDAwMDA1N2ZhICBtZm46
IDAwMDA1N2ZhDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjMxXSAgIGdmbjogMDAwMDU3
ZmIgIG1mbjogMDAwMDU3ZmINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MzFdICAgZ2Zu
OiAwMDAwNTdmYyAgbWZuOiAwMDAwNTdmYw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoz
MV0gICBnZm46IDAwMDA1N2ZkICBtZm46IDAwMDA1N2ZkDQoNCihYRU4pIFsyMDEyLTA4LTMx
IDIxOjMzOjMxXSAgIGdmbjogMDAwMDU3ZmUgIG1mbjogMDAwMDU3ZmUNCg0KKFhFTikgWzIw
MTItMDgtMzEgMjE6MzM6MzFdICAgZ2ZuOiAwMDAwNTdmZiAgbWZuOiAwMDAwNTdmZg0KDQoo
WEVOKSBbMjAxMi0wOC0zMSAyMTozMzozMV0gICBnZm46IDAwMDA1ODAwICBtZm46IDAwMDA1
ODAwDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjMxXSAgIGdmbjogMDAwMDU4MDEgIG1m
bjogMDAwMDU4MDENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MzFdICAgZ2ZuOiAwMDAw
NTgwMiAgbWZuOiAwMDAwNTgwMg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzozMV0gICBn
Zm46IDAwMDA1ODAzICBtZm46IDAwMDA1ODAzDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMz
OjMxXSAgIGdmbjogMDAwMDU4MDQgIG1mbjogMDAwMDU4MDQNCg0KKFhFTikgWzIwMTItMDgt
MzEgMjE6MzM6MzFdICAgZ2ZuOiAwMDAwNTgwNSAgbWZuOiAwMDAwNTgwNQ0KDQooWEVOKSBb
MjAxMi0wOC0zMSAyMTozMzozMV0gICBnZm46IDAwMDA1ODA2ICBtZm46IDAwMDA1ODA2DQoN
CihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjMxXSAgIGdmbjogMDAwMDU4MDcgIG1mbjogMDAw
MDU4MDcNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MzFdICAgZ2ZuOiAwMDAwNTgwOCAg
bWZuOiAwMDAwNTgwOA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzozMV0gICBnZm46IDAw
MDA1ODA5ICBtZm46IDAwMDA1ODA5DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjMxXSAg
IGdmbjogMDAwMDU4MGEgIG1mbjogMDAwMDU4MGENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6
MzM6MzFdICAgZ2ZuOiAwMDAwNTgwYiAgbWZuOiAwMDAwNTgwYg0KDQooWEVOKSBbMjAxMi0w
OC0zMSAyMTozMzozMV0gICBnZm46IDAwMDA1ODBjICBtZm46IDAwMDA1ODBjDQoNCihYRU4p
IFsyMDEyLTA4LTMxIDIxOjMzOjMxXSAgIGdmbjogMDAwMDU4MGQgIG1mbjogMDAwMDU4MGQN
Cg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MzFdICAgZ2ZuOiAwMDAwNTgwZSAgbWZuOiAw
MDAwNTgwZQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzozMV0gICBnZm46IDAwMDA1ODBm
ICBtZm46IDAwMDA1ODBmDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjMxXSAgIGdmbjog
MDAwMDU4MTAgIG1mbjogMDAwMDU4MTANCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MzJd
ICAgZ2ZuOiAwMDAwNTgxMSAgbWZuOiAwMDAwNTgxMQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAy
MTozMzozMl0gICBnZm46IDAwMDA1ODEyICBtZm46IDAwMDA1ODEyDQoNCihYRU4pIFsyMDEy
LTA4LTMxIDIxOjMzOjMyXSAgIGdmbjogMDAwMDU4MTMgIG1mbjogMDAwMDU4MTMNCg0KKFhF
TikgWzIwMTItMDgtMzEgMjE6MzM6MzJdICAgZ2ZuOiAwMDAwNTgxNCAgbWZuOiAwMDAwNTgx
NA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzozMl0gICBnZm46IDAwMDA1ODE1ICBtZm46
IDAwMDA1ODE1DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjMyXSAgIGdmbjogMDAwMDU4
MTYgIG1mbjogMDAwMDU4MTYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MzJdICAgZ2Zu
OiAwMDAwNTgxNyAgbWZuOiAwMDAwNTgxNw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoz
Ml0gICBnZm46IDAwMDA1ODE4ICBtZm46IDAwMDA1ODE4DQoNCihYRU4pIFsyMDEyLTA4LTMx
IDIxOjMzOjMyXSAgIGdmbjogMDAwMDU4MTkgIG1mbjogMDAwMDU4MTkNCg0KKFhFTikgWzIw
MTItMDgtMzEgMjE6MzM6MzJdICAgZ2ZuOiAwMDAwNTgxYSAgbWZuOiAwMDAwNTgxYQ0KDQoo
WEVOKSBbMjAxMi0wOC0zMSAyMTozMzozMl0gICBnZm46IDAwMDA1ODFiICBtZm46IDAwMDA1
ODFiDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjMyXSAgIGdmbjogMDAwMDU4MWMgIG1m
bjogMDAwMDU4MWMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MzJdICAgZ2ZuOiAwMDAw
NTgxZCAgbWZuOiAwMDAwNTgxZA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzozMl0gICBn
Zm46IDAwMDA1ODFlICBtZm46IDAwMDA1ODFlDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMz
OjMyXSAgIGdmbjogMDAwMDU4MWYgIG1mbjogMDAwMDU4MWYNCg0KKFhFTikgWzIwMTItMDgt
MzEgMjE6MzM6MzJdICAgZ2ZuOiAwMDAwNTgyMCAgbWZuOiAwMDAwNTgyMA0KDQooWEVOKSBb
MjAxMi0wOC0zMSAyMTozMzozMl0gICBnZm46IDAwMDA1ODIxICBtZm46IDAwMDA1ODIxDQoN
CihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjMyXSAgIGdmbjogMDAwMDU4MjIgIG1mbjogMDAw
MDU4MjINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MzJdICAgZ2ZuOiAwMDAwNTgyMyAg
bWZuOiAwMDAwNTgyMw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzozMl0gICBnZm46IDAw
MDA1ODI0ICBtZm46IDAwMDA1ODI0DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjMyXSAg
IGdmbjogMDAwMDU4MjUgIG1mbjogMDAwMDU4MjUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6
MzM6MzJdICAgZ2ZuOiAwMDAwNTgyNiAgbWZuOiAwMDAwNTgyNg0KDQooWEVOKSBbMjAxMi0w
OC0zMSAyMTozMzozMl0gICBnZm46IDAwMDA1ODI3ICBtZm46IDAwMDA1ODI3DQoNCihYRU4p
IFsyMDEyLTA4LTMxIDIxOjMzOjMyXSAgIGdmbjogMDAwMDU4MjggIG1mbjogMDAwMDU4MjgN
Cg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MzJdICAgZ2ZuOiAwMDAwNTgyOSAgbWZuOiAw
MDAwNTgyOQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzozMl0gICBnZm46IDAwMDA1ODJh
ICBtZm46IDAwMDA1ODJhDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjMyXSAgIGdmbjog
MDAwMDU4MmIgIG1mbjogMDAwMDU4MmINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MzJd
ICAgZ2ZuOiAwMDAwNTgyYyAgbWZuOiAwMDAwNTgyYw0KDQooWEVOKSBbMjAxMi0wOC0zMSAy
MTozMzozMl0gICBnZm46IDAwMDA1ODJkICBtZm46IDAwMDA1ODJkDQoNCihYRU4pIFsyMDEy
LTA4LTMxIDIxOjMzOjMyXSAgIGdmbjogMDAwMDU4MmUgIG1mbjogMDAwMDU4MmUNCg0KKFhF
TikgWzIwMTItMDgtMzEgMjE6MzM6MzJdICAgZ2ZuOiAwMDAwNTgyZiAgbWZuOiAwMDAwNTgy
Zg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzozMl0gICBnZm46IDAwMDA1ODMwICBtZm46
IDAwMDA1ODMwDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjMyXSAgIGdmbjogMDAwMDU4
MzEgIG1mbjogMDAwMDU4MzENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MzJdICAgZ2Zu
OiAwMDAwNTgzMiAgbWZuOiAwMDAwNTgzMg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoz
Ml0gICBnZm46IDAwMDA1ODMzICBtZm46IDAwMDA1ODMzDQoNCihYRU4pIFsyMDEyLTA4LTMx
IDIxOjMzOjMyXSAgIGdmbjogMDAwMDU4MzQgIG1mbjogMDAwMDU4MzQNCg0KKFhFTikgWzIw
MTItMDgtMzEgMjE6MzM6MzJdICAgZ2ZuOiAwMDAwNTgzNSAgbWZuOiAwMDAwNTgzNQ0KDQoo
WEVOKSBbMjAxMi0wOC0zMSAyMTozMzozMl0gICBnZm46IDAwMDA1ODM2ICBtZm46IDAwMDA1
ODM2DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjMyXSAgIGdmbjogMDAwMDU4MzcgIG1m
bjogMDAwMDU4MzcNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MzJdICAgZ2ZuOiAwMDAw
NTgzOCAgbWZuOiAwMDAwNTgzOA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzozMl0gICBn
Zm46IDAwMDA1ODM5ICBtZm46IDAwMDA1ODM5DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMz
OjMyXSAgIGdmbjogMDAwMDU4M2EgIG1mbjogMDAwMDU4M2ENCg0KKFhFTikgWzIwMTItMDgt
MzEgMjE6MzM6MzJdICAgZ2ZuOiAwMDAwNTgzYiAgbWZuOiAwMDAwNTgzYg0KDQooWEVOKSBb
MjAxMi0wOC0zMSAyMTozMzozMl0gICBnZm46IDAwMDA1ODNjICBtZm46IDAwMDA1ODNjDQoN
CihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjMyXSAgIGdmbjogMDAwMDU4M2QgIG1mbjogMDAw
MDU4M2QNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MzJdICAgZ2ZuOiAwMDAwNTgzZSAg
bWZuOiAwMDAwNTgzZQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzozMl0gICBnZm46IDAw
MDA1ODNmICBtZm46IDAwMDA1ODNmDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjMyXSAg
IGdmbjogMDAwMDU4NDAgIG1mbjogMDAwMDU4NDANCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6
MzM6MzJdICAgZ2ZuOiAwMDAwNTg0MSAgbWZuOiAwMDAwNTg0MQ0KDQooWEVOKSBbMjAxMi0w
OC0zMSAyMTozMzozMl0gICBnZm46IDAwMDA1ODQyICBtZm46IDAwMDA1ODQyDQoNCihYRU4p
IFsyMDEyLTA4LTMxIDIxOjMzOjMyXSAgIGdmbjogMDAwMDU4NDMgIG1mbjogMDAwMDU4NDMN
Cg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MzJdICAgZ2ZuOiAwMDAwNTg0NCAgbWZuOiAw
MDAwNTg0NA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzozMl0gICBnZm46IDAwMDA1ODQ1
ICBtZm46IDAwMDA1ODQ1DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjMyXSAgIGdmbjog
MDAwMDU4NDYgIG1mbjogMDAwMDU4NDYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MzJd
ICAgZ2ZuOiAwMDAwNTg0NyAgbWZuOiAwMDAwNTg0Nw0KDQooWEVOKSBbMjAxMi0wOC0zMSAy
MTozMzozMl0gICBnZm46IDAwMDA1ODQ4ICBtZm46IDAwMDA1ODQ4DQoNCihYRU4pIFsyMDEy
LTA4LTMxIDIxOjMzOjMyXSAgIGdmbjogMDAwMDU4NDkgIG1mbjogMDAwMDU4NDkNCg0KKFhF
TikgWzIwMTItMDgtMzEgMjE6MzM6MzJdICAgZ2ZuOiAwMDAwNTg0YSAgbWZuOiAwMDAwNTg0
YQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzozMl0gICBnZm46IDAwMDA1ODRiICBtZm46
IDAwMDA1ODRiDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjMyXSAgIGdmbjogMDAwMDU4
NGMgIG1mbjogMDAwMDU4NGMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MzJdICAgZ2Zu
OiAwMDAwNTg0ZCAgbWZuOiAwMDAwNTg0ZA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoz
Ml0gICBnZm46IDAwMDA1ODRlICBtZm46IDAwMDA1ODRlDQoNCihYRU4pIFsyMDEyLTA4LTMx
IDIxOjMzOjMyXSAgIGdmbjogMDAwMDU4NGYgIG1mbjogMDAwMDU4NGYNCg0KKFhFTikgWzIw
MTItMDgtMzEgMjE6MzM6MzJdICAgZ2ZuOiAwMDAwNTg1MCAgbWZuOiAwMDAwNTg1MA0KDQoo
WEVOKSBbMjAxMi0wOC0zMSAyMTozMzozM10gICBnZm46IDAwMDA1ODUxICBtZm46IDAwMDA1
ODUxDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjMzXSAgIGdmbjogMDAwMDU4NTIgIG1m
bjogMDAwMDU4NTINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MzNdICAgZ2ZuOiAwMDAw
NTg1MyAgbWZuOiAwMDAwNTg1Mw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzozM10gICBn
Zm46IDAwMDA1ODU0ICBtZm46IDAwMDA1ODU0DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMz
OjMzXSAgIGdmbjogMDAwMDU4NTUgIG1mbjogMDAwMDU4NTUNCg0KKFhFTikgWzIwMTItMDgt
MzEgMjE6MzM6MzNdICAgZ2ZuOiAwMDAwNTg1NiAgbWZuOiAwMDAwNTg1Ng0KDQooWEVOKSBb
MjAxMi0wOC0zMSAyMTozMzozM10gICBnZm46IDAwMDA1ODU3ICBtZm46IDAwMDA1ODU3DQoN
CihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjMzXSAgIGdmbjogMDAwMDU4NTggIG1mbjogMDAw
MDU4NTgNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MzNdICAgZ2ZuOiAwMDAwNTg1OSAg
bWZuOiAwMDAwNTg1OQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzozM10gICBnZm46IDAw
MDA1ODVhICBtZm46IDAwMDA1ODVhDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjMzXSAg
IGdmbjogMDAwMDU4NWIgIG1mbjogMDAwMDU4NWINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6
MzM6MzNdICAgZ2ZuOiAwMDAwNTg1YyAgbWZuOiAwMDAwNTg1Yw0KDQooWEVOKSBbMjAxMi0w
OC0zMSAyMTozMzozM10gICBnZm46IDAwMDA1ODVkICBtZm46IDAwMDA1ODVkDQoNCihYRU4p
IFsyMDEyLTA4LTMxIDIxOjMzOjMzXSAgIGdmbjogMDAwMDU4NWUgIG1mbjogMDAwMDU4NWUN
Cg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MzNdICAgZ2ZuOiAwMDAwNTg1ZiAgbWZuOiAw
MDAwNTg1Zg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzozM10gICBnZm46IDAwMDA1ODYw
ICBtZm46IDAwMDA1ODYwDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjMzXSAgIGdmbjog
MDAwMDU4NjEgIG1mbjogMDAwMDU4NjENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MzNd
ICAgZ2ZuOiAwMDAwNTg2MiAgbWZuOiAwMDAwNTg2Mg0KDQooWEVOKSBbMjAxMi0wOC0zMSAy
MTozMzozM10gICBnZm46IDAwMDA1ODYzICBtZm46IDAwMDA1ODYzDQoNCihYRU4pIFsyMDEy
LTA4LTMxIDIxOjMzOjMzXSAgIGdmbjogMDAwMDU4NjQgIG1mbjogMDAwMDU4NjQNCg0KKFhF
TikgWzIwMTItMDgtMzEgMjE6MzM6MzNdICAgZ2ZuOiAwMDAwNTg2NSAgbWZuOiAwMDAwNTg2
NQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzozM10gICBnZm46IDAwMDA1ODY2ICBtZm46
IDAwMDA1ODY2DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjMzXSAgIGdmbjogMDAwMDU4
NjcgIG1mbjogMDAwMDU4NjcNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MzNdICAgZ2Zu
OiAwMDAwNTg2OCAgbWZuOiAwMDAwNTg2OA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoz
M10gICBnZm46IDAwMDA1ODY5ICBtZm46IDAwMDA1ODY5DQoNCihYRU4pIFsyMDEyLTA4LTMx
IDIxOjMzOjMzXSAgIGdmbjogMDAwMDU4NmEgIG1mbjogMDAwMDU4NmENCg0KKFhFTikgWzIw
MTItMDgtMzEgMjE6MzM6MzNdICAgZ2ZuOiAwMDAwNTg2YiAgbWZuOiAwMDAwNTg2Yg0KDQoo
WEVOKSBbMjAxMi0wOC0zMSAyMTozMzozM10gICBnZm46IDAwMDA1ODZjICBtZm46IDAwMDA1
ODZjDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjMzXSAgIGdmbjogMDAwMDU4NmQgIG1m
bjogMDAwMDU4NmQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MzNdICAgZ2ZuOiAwMDAw
NTg2ZSAgbWZuOiAwMDAwNTg2ZQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzozM10gICBn
Zm46IDAwMDA1ODZmICBtZm46IDAwMDA1ODZmDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMz
OjMzXSAgIGdmbjogMDAwMDU4NzAgIG1mbjogMDAwMDU4NzANCg0KKFhFTikgWzIwMTItMDgt
MzEgMjE6MzM6MzNdICAgZ2ZuOiAwMDAwNTg3MSAgbWZuOiAwMDAwNTg3MQ0KDQooWEVOKSBb
MjAxMi0wOC0zMSAyMTozMzozM10gICBnZm46IDAwMDA1ODcyICBtZm46IDAwMDA1ODcyDQoN
CihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjMzXSAgIGdmbjogMDAwMDU4NzMgIG1mbjogMDAw
MDU4NzMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MzNdICAgZ2ZuOiAwMDAwNTg3NCAg
bWZuOiAwMDAwNTg3NA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzozM10gICBnZm46IDAw
MDA1ODc1ICBtZm46IDAwMDA1ODc1DQoNClsgIDQ3OS41NTkzNDddIGEoWEVOKSBbMjAxMi0w
OC0zMSAyMTozMzozM10gICBnZm46IDAwMDA1ODc2ICBtZm46IDAwMDA1ODc2DQoNCnRhMy4w
MDogZXhjZXB0aW8oWEVOKSBbMjAxMi0wOC0zMSAyMTozMzozM10gICBnZm46IDAwMDA1ODc3
ICBtZm46IDAwMDA1ODc3DQoNCm4gRW1hc2sgMHgwIFNBY3QgMHgwIFNFcnIgMHgwIGFjKFhF
TikgWzIwMTItMDgtMzEgMjE6MzM6MzNdICAgZ2ZuOiAwMDAwNTg3OCAgbWZuOiAwMDAwNTg3
OA0KDQp0aW9uIDB4NiBmcm96ZW4NCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjMzXSAgIGdm
bjogMDAwMDU4NzkgIG1mbjogMDAwMDU4NzkNCg0KDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMzOjMzXSAgIGdmbjogMDAwMDU4N2EgIG1mbjogMDAwMDU4N2ENCg0KWyAgNDc5LjY2Mzcz
OF0gYShYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjMzXSAgIGdmbjogMDAwMDU4N2IgIG1mbjog
MDAwMDU4N2INCg0KdGEzLjAwOiBmYWlsZWQgYyhYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjMz
XSAgIGdmbjogMDAwMDU4N2MgIG1mbjogMDAwMDU4N2MNCg0Kb21tYW5kOiBDSEVDSyBQTyhY
RU4pIFsyMDEyLTA4LTMxIDIxOjMzOjMzXSAgIGdmbjogMDAwMDU4N2QgIG1mbjogMDAwMDU4
N2QNCg0KV0VSIE1PREUNCg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzozM10gICBnZm46
IDAwMDA1ODdlICBtZm46IDAwMDA1ODdlDQoNClsgIDQ3OS43Mzc1NjNdIGEoWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMzozM10gICBnZm46IDAwMDA1ODdmICBtZm46IDAwMDA1ODdmDQoNCnRh
My4wMDogY21kIGU1LzAoWEVOKSBbMjAxMi0wOC0zMSAyMTozMzozM10gICBnZm46IDAwMDA1
ODgwICBtZm46IDAwMDA1ODgwDQoNCjA6MDA6MDA6MDA6MDAvMDAoWEVOKSBbMjAxMi0wOC0z
MSAyMTozMzozM10gICBnZm46IDAwMDA1ODgxICBtZm46IDAwMDA1ODgxDQoNCjowMDowMDow
MDowMC80MCB0YWcgMA0KDQoNClsgIDQ3OS43MyhYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjMz
XSAgIGdmbjogMDAwMDU4ODIgIG1mbjogMDAwMDU4ODINCg0KNzU2M10gICAgICAgICAgcihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMzOjMzXSAgIGdmbjogMDAwMDU4ODMgIG1mbjogMDAwMDU4
ODMNCg0KZXMgNDAvMDA6ZmY6MDA6MDA6MDAvMDA6MDA6MDA6MDAoWEVOKSBbMjAxMi0wOC0z
MSAyMTozMzozM10gICBnZm46IDAwMDA1ODg0ICBtZm46IDAwMDA1ODg0DQoNCjowMC80MCBF
bWFzayAweDQoWEVOKSBbMjAxMi0wOC0zMSAyMTozMzozM10gICBnZm46IDAwMDA1ODg1ICBt
Zm46IDAwMDA1ODg1DQoNCiAodGltZW91dCkNCg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
MzozM10gICBnZm46IDAwMDA1ODg2ICBtZm46IDAwMDA1ODg2DQoNClsgIDQ3OS45MDUzMzZd
IGEoWEVOKSBbMjAxMi0wOC0zMSAyMTozMzozM10gICBnZm46IDAwMDA1ODg3ICBtZm46IDAw
MDA1ODg3DQoNCnRhMy4wMDogc3RhdHVzOiAoWEVOKSBbMjAxMi0wOC0zMSAyMTozMzozM10g
ICBnZm46IDAwMDA1ODg4ICBtZm46IDAwMDA1ODg4DQoNCnsgRFJEWSB9DQoNCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzM6MzNdICAgZ2ZuOiAwMDAwNTg4OSAgbWZuOiAwMDAwNTg4OQ0K
DQpbICA0NzkuOTYyMTUzXSBhKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MzNdICAgZ2ZuOiAw
MDAwNTg4YSAgbWZuOiAwMDAwNTg4YQ0KDQp0YTM6IGhhcmQgcmVzZXR0KFhFTikgWzIwMTIt
MDgtMzEgMjE6MzM6MzRdICAgZ2ZuOiAwMDAwNTg4YiAgbWZuOiAwMDAwNTg4Yg0KDQppbmcg
bGluaw0KDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjM0XSAgIGdmbjogMDAwMDU4OGMg
IG1mbjogMDAwMDU4OGMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MzRdICAgZ2ZuOiAw
MDAwNTg4ZCAgbWZuOiAwMDAwNTg4ZA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzozNF0g
ICBnZm46IDAwMDA1ODhlICBtZm46IDAwMDA1ODhlDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMzOjM0XSAgIGdmbjogMDAwMDU4OGYgIG1mbjogMDAwMDU4OGYNCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzM6MzRdICAgZ2ZuOiAwMDAwNTg5MCAgbWZuOiAwMDAwNTg5MA0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMzozNF0gICBnZm46IDAwMDA1ODkxICBtZm46IDAwMDA1ODkx
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjM0XSAgIGdmbjogMDAwMDU4OTIgIG1mbjog
MDAwMDU4OTINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MzRdICAgZ2ZuOiAwMDAwNTg5
MyAgbWZuOiAwMDAwNTg5Mw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzozNF0gICBnZm46
IDAwMDA1ODk0ICBtZm46IDAwMDA1ODk0DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjM0
XSAgIGdmbjogMDAwMDU4OTUgIG1mbjogMDAwMDU4OTUNCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzM6MzRdICAgZ2ZuOiAwMDAwNTg5NiAgbWZuOiAwMDAwNTg5Ng0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMzozNF0gICBnZm46IDAwMDA1ODk3ICBtZm46IDAwMDA1ODk3DQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMzOjM0XSAgIGdmbjogMDAwMDU4OTggIG1mbjogMDAwMDU4
OTgNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MzRdICAgZ2ZuOiAwMDAwNTg5OSAgbWZu
OiAwMDAwNTg5OQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzozNF0gICBnZm46IDAwMDA1
ODlhICBtZm46IDAwMDA1ODlhDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjM0XSAgIGdm
bjogMDAwMDU4OWIgIG1mbjogMDAwMDU4OWINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6
MzRdICAgZ2ZuOiAwMDAwNTg5YyAgbWZuOiAwMDAwNTg5Yw0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMzozNF0gICBnZm46IDAwMDA1ODlkICBtZm46IDAwMDA1ODlkDQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMzOjM0XSAgIGdmbjogMDAwMDU4OWUgIG1mbjogMDAwMDU4OWUNCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MzRdICAgZ2ZuOiAwMDAwNTg5ZiAgbWZuOiAwMDAw
NTg5Zg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzozNF0gICBnZm46IDAwMDA1OGEwICBt
Zm46IDAwMDA1OGEwDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjM0XSAgIGdmbjogMDAw
MDU4YTEgIG1mbjogMDAwMDU4YTENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MzRdICAg
Z2ZuOiAwMDAwNThhMiAgbWZuOiAwMDAwNThhMg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
MzozNF0gICBnZm46IDAwMDA1OGEzICBtZm46IDAwMDA1OGEzDQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMzOjM0XSAgIGdmbjogMDAwMDU4YTQgIG1mbjogMDAwMDU4YTQNCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzM6MzRdICAgZ2ZuOiAwMDAwNThhNSAgbWZuOiAwMDAwNThhNQ0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzozNF0gICBnZm46IDAwMDA1OGE2ICBtZm46IDAw
MDA1OGE2DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjM0XSAgIGdmbjogMDAwMDU4YTcg
IG1mbjogMDAwMDU4YTcNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MzRdICAgZ2ZuOiAw
MDAwNThhOCAgbWZuOiAwMDAwNThhOA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzozNF0g
ICBnZm46IDAwMDA1OGE5ICBtZm46IDAwMDA1OGE5DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMzOjM0XSAgIGdmbjogMDAwMDU4YWEgIG1mbjogMDAwMDU4YWENCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzM6MzRdICAgZ2ZuOiAwMDAwNThhYiAgbWZuOiAwMDAwNThhYg0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMzozNF0gICBnZm46IDAwMDA1OGFjICBtZm46IDAwMDA1OGFj
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjM0XSAgIGdmbjogMDAwMDU4YWQgIG1mbjog
MDAwMDU4YWQNCg0KWyAgNDgwLjUzNjIzOF0gYShYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjM0
XSAgIGdmbjogMDAwMDU4YWUgIG1mbjogMDAwMDU4YWUNCg0KdGEzOiBTQVRBIGxpbmsgdShY
RU4pIFsyMDEyLTA4LTMxIDIxOjMzOjM0XSAgIGdmbjogMDAwMDU4YWYgIG1mbjogMDAwMDU4
YWYNCg0KcCA2LjAgR2JwcyAoU1N0YXR1cyAxMzMgU0NvbnRyb2woWEVOKSBbMjAxMi0wOC0z
MSAyMTozMzozNF0gICBnZm46IDAwMDA1OGIwICBtZm46IDAwMDA1OGIwDQoNCiAzMDApDQoN
Cg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MzRdICAgZ2ZuOiAwMDAwNThiMSAgbWZuOiAw
MDAwNThiMQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzozNF0gICBnZm46IDAwMDA1OGIy
ICBtZm46IDAwMDA1OGIyDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjM0XSAgIGdmbjog
MDAwMDU4YjMgIG1mbjogMDAwMDU4YjMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MzRd
ICAgZ2ZuOiAwMDAwNThiNCAgbWZuOiAwMDAwNThiNA0KDQooWEVOKSBbMjAxMi0wOC0zMSAy
MTozMzozNF0gICBnZm46IDAwMDA1OGI1ICBtZm46IDAwMDA1OGI1DQoNCihYRU4pIFsyMDEy
LTA4LTMxIDIxOjMzOjM0XSAgIGdmbjogMDAwMDU4YjYgIG1mbjogMDAwMDU4YjYNCg0KKFhF
TikgWzIwMTItMDgtMzEgMjE6MzM6MzRdICAgZ2ZuOiAwMDAwNThiNyAgbWZuOiAwMDAwNThi
Nw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzozNF0gICBnZm46IDAwMDA1OGI4ICBtZm46
IDAwMDA1OGI4DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjM0XSAgIGdmbjogMDAwMDU4
YjkgIG1mbjogMDAwMDU4YjkNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MzRdICAgZ2Zu
OiAwMDAwNThiYSAgbWZuOiAwMDAwNThiYQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoz
NF0gICBnZm46IDAwMDA1OGJiICBtZm46IDAwMDA1OGJiDQoNCihYRU4pIFsyMDEyLTA4LTMx
IDIxOjMzOjM0XSAgIGdmbjogMDAwMDU4YmMgIG1mbjogMDAwMDU4YmMNCg0KKFhFTikgWzIw
MTItMDgtMzEgMjE6MzM6MzRdICAgZ2ZuOiAwMDAwNThiZCAgbWZuOiAwMDAwNThiZA0KDQoo
WEVOKSBbMjAxMi0wOC0zMSAyMTozMzozNF0gICBnZm46IDAwMDA1OGJlICBtZm46IDAwMDA1
OGJlDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjM0XSAgIGdmbjogMDAwMDU4YmYgIG1m
bjogMDAwMDU4YmYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MzRdICAgZ2ZuOiAwMDAw
NThjMCAgbWZuOiAwMDAwNThjMA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzozNF0gICBn
Zm46IDAwMDA1OGMxICBtZm46IDAwMDA1OGMxDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMz
OjM0XSAgIGdmbjogMDAwMDU4YzIgIG1mbjogMDAwMDU4YzINCg0KKFhFTikgWzIwMTItMDgt
MzEgMjE6MzM6MzRdICAgZ2ZuOiAwMDAwNThjMyAgbWZuOiAwMDAwNThjMw0KDQooWEVOKSBb
MjAxMi0wOC0zMSAyMTozMzozNF0gICBnZm46IDAwMDA1OGM0ICBtZm46IDAwMDA1OGM0DQoN
CihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjM0XSAgIGdmbjogMDAwMDU4YzUgIG1mbjogMDAw
MDU4YzUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MzRdICAgZ2ZuOiAwMDAwNThjNiAg
bWZuOiAwMDAwNThjNg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzozNF0gICBnZm46IDAw
MDA1OGM3ICBtZm46IDAwMDA1OGM3DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjM0XSAg
IGdmbjogMDAwMDU4YzggIG1mbjogMDAwMDU4YzgNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6
MzM6MzRdICAgZ2ZuOiAwMDAwNThjOSAgbWZuOiAwMDAwNThjOQ0KDQooWEVOKSBbMjAxMi0w
OC0zMSAyMTozMzozNV0gICBnZm46IDAwMDA1OGNhICBtZm46IDAwMDA1OGNhDQoNCihYRU4p
IFsyMDEyLTA4LTMxIDIxOjMzOjM1XSAgIGdmbjogMDAwMDU4Y2IgIG1mbjogMDAwMDU4Y2IN
Cg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MzVdICAgZ2ZuOiAwMDAwNThjYyAgbWZuOiAw
MDAwNThjYw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzozNV0gICBnZm46IDAwMDA1OGNk
ICBtZm46IDAwMDA1OGNkDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjM1XSAgIGdmbjog
MDAwMDU4Y2UgIG1mbjogMDAwMDU4Y2UNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MzVd
ICAgZ2ZuOiAwMDAwNThjZiAgbWZuOiAwMDAwNThjZg0KDQooWEVOKSBbMjAxMi0wOC0zMSAy
MTozMzozNV0gICBnZm46IDAwMDA1OGQwICBtZm46IDAwMDA1OGQwDQoNCihYRU4pIFsyMDEy
LTA4LTMxIDIxOjMzOjM1XSAgIGdmbjogMDAwMDU4ZDEgIG1mbjogMDAwMDU4ZDENCg0KKFhF
TikgWzIwMTItMDgtMzEgMjE6MzM6MzVdICAgZ2ZuOiAwMDAwNThkMiAgbWZuOiAwMDAwNThk
Mg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzozNV0gICBnZm46IDAwMDA1OGQzICBtZm46
IDAwMDA1OGQzDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjM1XSAgIGdmbjogMDAwMDU4
ZDQgIG1mbjogMDAwMDU4ZDQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MzVdICAgZ2Zu
OiAwMDAwNThkNSAgbWZuOiAwMDAwNThkNQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoz
NV0gICBnZm46IDAwMDA1OGQ2ICBtZm46IDAwMDA1OGQ2DQoNCihYRU4pIFsyMDEyLTA4LTMx
IDIxOjMzOjM1XSAgIGdmbjogMDAwMDU4ZDcgIG1mbjogMDAwMDU4ZDcNCg0KKFhFTikgWzIw
MTItMDgtMzEgMjE6MzM6MzVdICAgZ2ZuOiAwMDAwNThkOCAgbWZuOiAwMDAwNThkOA0KDQoo
WEVOKSBbMjAxMi0wOC0zMSAyMTozMzozNV0gICBnZm46IDAwMDA1OGQ5ICBtZm46IDAwMDA1
OGQ5DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjM1XSAgIGdmbjogMDAwMDU4ZGEgIG1m
bjogMDAwMDU4ZGENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MzVdICAgZ2ZuOiAwMDAw
NThkYiAgbWZuOiAwMDAwNThkYg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzozNV0gICBn
Zm46IDAwMDA1OGRjICBtZm46IDAwMDA1OGRjDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMz
OjM1XSAgIGdmbjogMDAwMDU4ZGQgIG1mbjogMDAwMDU4ZGQNCg0KKFhFTikgWzIwMTItMDgt
MzEgMjE6MzM6MzVdICAgZ2ZuOiAwMDAwNThkZSAgbWZuOiAwMDAwNThkZQ0KDQooWEVOKSBb
MjAxMi0wOC0zMSAyMTozMzozNV0gICBnZm46IDAwMDA1OGRmICBtZm46IDAwMDA1OGRmDQoN
CihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjM1XSAgIGdmbjogMDAwMDU4ZTAgIG1mbjogMDAw
MDU4ZTANCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MzVdICAgZ2ZuOiAwMDAwNThlMSAg
bWZuOiAwMDAwNThlMQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzozNV0gICBnZm46IDAw
MDA1OGUyICBtZm46IDAwMDA1OGUyDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjM1XSAg
IGdmbjogMDAwMDU4ZTMgIG1mbjogMDAwMDU4ZTMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6
MzM6MzVdICAgZ2ZuOiAwMDAwNThlNCAgbWZuOiAwMDAwNThlNA0KDQooWEVOKSBbMjAxMi0w
OC0zMSAyMTozMzozNV0gICBnZm46IDAwMDA1OGU1ICBtZm46IDAwMDA1OGU1DQoNCihYRU4p
IFsyMDEyLTA4LTMxIDIxOjMzOjM1XSAgIGdmbjogMDAwMDU4ZTYgIG1mbjogMDAwMDU4ZTYN
Cg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MzVdICAgZ2ZuOiAwMDAwNThlNyAgbWZuOiAw
MDAwNThlNw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzozNV0gICBnZm46IDAwMDA1OGU4
ICBtZm46IDAwMDA1OGU4DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjM1XSAgIGdmbjog
MDAwMDU4ZTkgIG1mbjogMDAwMDU4ZTkNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MzVd
ICAgZ2ZuOiAwMDAwNThlYSAgbWZuOiAwMDAwNThlYQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAy
MTozMzozNV0gICBnZm46IDAwMDA1OGViICBtZm46IDAwMDA1OGViDQoNCihYRU4pIFsyMDEy
LTA4LTMxIDIxOjMzOjM1XSAgIGdmbjogMDAwMDU4ZWMgIG1mbjogMDAwMDU4ZWMNCg0KKFhF
TikgWzIwMTItMDgtMzEgMjE6MzM6MzVdICAgZ2ZuOiAwMDAwNThlZCAgbWZuOiAwMDAwNThl
ZA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzozNV0gICBnZm46IDAwMDA1OGVlICBtZm46
IDAwMDA1OGVlDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjM1XSAgIGdmbjogMDAwMDU4
ZWYgIG1mbjogMDAwMDU4ZWYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MzVdICAgZ2Zu
OiAwMDAwNThmMCAgbWZuOiAwMDAwNThmMA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoz
NV0gICBnZm46IDAwMDA1OGYxICBtZm46IDAwMDA1OGYxDQoNCihYRU4pIFsyMDEyLTA4LTMx
IDIxOjMzOjM1XSAgIGdmbjogMDAwMDU4ZjIgIG1mbjogMDAwMDU4ZjINCg0KKFhFTikgWzIw
MTItMDgtMzEgMjE6MzM6MzVdICAgZ2ZuOiAwMDAwNThmMyAgbWZuOiAwMDAwNThmMw0KDQoo
WEVOKSBbMjAxMi0wOC0zMSAyMTozMzozNV0gICBnZm46IDAwMDA1OGY0ICBtZm46IDAwMDA1
OGY0DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjM1XSAgIGdmbjogMDAwMDU4ZjUgIG1m
bjogMDAwMDU4ZjUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MzVdICAgZ2ZuOiAwMDAw
NThmNiAgbWZuOiAwMDAwNThmNg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzozNV0gICBn
Zm46IDAwMDA1OGY3ICBtZm46IDAwMDA1OGY3DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMz
OjM1XSAgIGdmbjogMDAwMDU4ZjggIG1mbjogMDAwMDU4ZjgNCg0KKFhFTikgWzIwMTItMDgt
MzEgMjE6MzM6MzVdICAgZ2ZuOiAwMDAwNThmOSAgbWZuOiAwMDAwNThmOQ0KDQooWEVOKSBb
MjAxMi0wOC0zMSAyMTozMzozNV0gICBnZm46IDAwMDA1OGZhICBtZm46IDAwMDA1OGZhDQoN
CihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjM1XSAgIGdmbjogMDAwMDU4ZmIgIG1mbjogMDAw
MDU4ZmINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MzVdICAgZ2ZuOiAwMDAwNThmYyAg
bWZuOiAwMDAwNThmYw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzozNV0gICBnZm46IDAw
MDA1OGZkICBtZm46IDAwMDA1OGZkDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjM1XSAg
IGdmbjogMDAwMDU4ZmUgIG1mbjogMDAwMDU4ZmUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6
MzM6MzVdICAgZ2ZuOiAwMDAwNThmZiAgbWZuOiAwMDAwNThmZg0KDQooWEVOKSBbMjAxMi0w
OC0zMSAyMTozMzozNV0gICBnZm46IDAwMDA1OTAwICBtZm46IDAwMDA1OTAwDQoNCihYRU4p
IFsyMDEyLTA4LTMxIDIxOjMzOjM1XSAgIGdmbjogMDAwMDU5MDEgIG1mbjogMDAwMDU5MDEN
Cg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MzVdICAgZ2ZuOiAwMDAwNTkwMiAgbWZuOiAw
MDAwNTkwMg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzozNV0gICBnZm46IDAwMDA1OTAz
ICBtZm46IDAwMDA1OTAzDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjM1XSAgIGdmbjog
MDAwMDU5MDQgIG1mbjogMDAwMDU5MDQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MzVd
ICAgZ2ZuOiAwMDAwNTkwNSAgbWZuOiAwMDAwNTkwNQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAy
MTozMzozNV0gICBnZm46IDAwMDA1OTA2ICBtZm46IDAwMDA1OTA2DQoNCihYRU4pIFsyMDEy
LTA4LTMxIDIxOjMzOjM1XSAgIGdmbjogMDAwMDU5MDcgIG1mbjogMDAwMDU5MDcNCg0KKFhF
TikgWzIwMTItMDgtMzEgMjE6MzM6MzVdICAgZ2ZuOiAwMDAwNTkwOCAgbWZuOiAwMDAwNTkw
OA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzozNV0gICBnZm46IDAwMDA1OTA5ICBtZm46
IDAwMDA1OTA5DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjM2XSAgIGdmbjogMDAwMDU5
MGEgIG1mbjogMDAwMDU5MGENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MzZdICAgZ2Zu
OiAwMDAwNTkwYiAgbWZuOiAwMDAwNTkwYg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoz
Nl0gICBnZm46IDAwMDA1OTBjICBtZm46IDAwMDA1OTBjDQoNCihYRU4pIFsyMDEyLTA4LTMx
IDIxOjMzOjM2XSAgIGdmbjogMDAwMDU5MGQgIG1mbjogMDAwMDU5MGQNCg0KKFhFTikgWzIw
MTItMDgtMzEgMjE6MzM6MzZdICAgZ2ZuOiAwMDAwNTkwZSAgbWZuOiAwMDAwNTkwZQ0KDQoo
WEVOKSBbMjAxMi0wOC0zMSAyMTozMzozNl0gICBnZm46IDAwMDA1OTBmICBtZm46IDAwMDA1
OTBmDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjM2XSAgIGdmbjogMDAwMDU5MTAgIG1m
bjogMDAwMDU5MTANCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MzZdICAgZ2ZuOiAwMDAw
NTkxMSAgbWZuOiAwMDAwNTkxMQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzozNl0gICBn
Zm46IDAwMDA1OTEyICBtZm46IDAwMDA1OTEyDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMz
OjM2XSAgIGdmbjogMDAwMDU5MTMgIG1mbjogMDAwMDU5MTMNCg0KKFhFTikgWzIwMTItMDgt
MzEgMjE6MzM6MzZdICAgZ2ZuOiAwMDAwNTkxNCAgbWZuOiAwMDAwNTkxNA0KDQooWEVOKSBb
MjAxMi0wOC0zMSAyMTozMzozNl0gICBnZm46IDAwMDA1OTE1ICBtZm46IDAwMDA1OTE1DQoN
CihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjM2XSAgIGdmbjogMDAwMDU5MTYgIG1mbjogMDAw
MDU5MTYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MzZdICAgZ2ZuOiAwMDAwNTkxNyAg
bWZuOiAwMDAwNTkxNw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzozNl0gICBnZm46IDAw
MDA1OTE4ICBtZm46IDAwMDA1OTE4DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjM2XSAg
IGdmbjogMDAwMDU5MTkgIG1mbjogMDAwMDU5MTkNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6
MzM6MzZdICAgZ2ZuOiAwMDAwNTkxYSAgbWZuOiAwMDAwNTkxYQ0KDQooWEVOKSBbMjAxMi0w
OC0zMSAyMTozMzozNl0gICBnZm46IDAwMDA1OTFiICBtZm46IDAwMDA1OTFiDQoNCihYRU4p
IFsyMDEyLTA4LTMxIDIxOjMzOjM2XSAgIGdmbjogMDAwMDU5MWMgIG1mbjogMDAwMDU5MWMN
Cg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MzZdICAgZ2ZuOiAwMDAwNTkxZCAgbWZuOiAw
MDAwNTkxZA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzozNl0gICBnZm46IDAwMDA1OTFl
ICBtZm46IDAwMDA1OTFlDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjM2XSAgIGdmbjog
MDAwMDU5MWYgIG1mbjogMDAwMDU5MWYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MzZd
ICAgZ2ZuOiAwMDAwNTkyMCAgbWZuOiAwMDAwNTkyMA0KDQooWEVOKSBbMjAxMi0wOC0zMSAy
MTozMzozNl0gICBnZm46IDAwMDA1OTIxICBtZm46IDAwMDA1OTIxDQoNCihYRU4pIFsyMDEy
LTA4LTMxIDIxOjMzOjM2XSAgIGdmbjogMDAwMDU5MjIgIG1mbjogMDAwMDU5MjINCg0KKFhF
TikgWzIwMTItMDgtMzEgMjE6MzM6MzZdICAgZ2ZuOiAwMDAwNTkyMyAgbWZuOiAwMDAwNTky
Mw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzozNl0gICBnZm46IDAwMDA1OTI0ICBtZm46
IDAwMDA1OTI0DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjM2XSAgIGdmbjogMDAwMDU5
MjUgIG1mbjogMDAwMDU5MjUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MzZdICAgZ2Zu
OiAwMDAwNTkyNiAgbWZuOiAwMDAwNTkyNg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoz
Nl0gICBnZm46IDAwMDA1OTI3ICBtZm46IDAwMDA1OTI3DQoNCihYRU4pIFsyMDEyLTA4LTMx
IDIxOjMzOjM2XSAgIGdmbjogMDAwMDU5MjggIG1mbjogMDAwMDU5MjgNCg0KKFhFTikgWzIw
MTItMDgtMzEgMjE6MzM6MzZdICAgZ2ZuOiAwMDAwNTkyOSAgbWZuOiAwMDAwNTkyOQ0KDQoo
WEVOKSBbMjAxMi0wOC0zMSAyMTozMzozNl0gICBnZm46IDAwMDA1OTJhICBtZm46IDAwMDA1
OTJhDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjM2XSAgIGdmbjogMDAwMDU5MmIgIG1m
bjogMDAwMDU5MmINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MzZdICAgZ2ZuOiAwMDAw
NTkyYyAgbWZuOiAwMDAwNTkyYw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzozNl0gICBn
Zm46IDAwMDA1OTJkICBtZm46IDAwMDA1OTJkDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMz
OjM2XSAgIGdmbjogMDAwMDU5MmUgIG1mbjogMDAwMDU5MmUNCg0KKFhFTikgWzIwMTItMDgt
MzEgMjE6MzM6MzZdICAgZ2ZuOiAwMDAwNTkyZiAgbWZuOiAwMDAwNTkyZg0KDQooWEVOKSBb
MjAxMi0wOC0zMSAyMTozMzozNl0gICBnZm46IDAwMDA1OTMwICBtZm46IDAwMDA1OTMwDQoN
CihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjM2XSAgIGdmbjogMDAwMDU5MzEgIG1mbjogMDAw
MDU5MzENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MzZdICAgZ2ZuOiAwMDAwNTkzMiAg
bWZuOiAwMDAwNTkzMg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzozNl0gICBnZm46IDAw
MDA1OTMzICBtZm46IDAwMDA1OTMzDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjM2XSAg
IGdmbjogMDAwMDU5MzQgIG1mbjogMDAwMDU5MzQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6
MzM6MzZdICAgZ2ZuOiAwMDAwNTkzNSAgbWZuOiAwMDAwNTkzNQ0KDQooWEVOKSBbMjAxMi0w
OC0zMSAyMTozMzozNl0gICBnZm46IDAwMDA1OTM2ICBtZm46IDAwMDA1OTM2DQoNCihYRU4p
IFsyMDEyLTA4LTMxIDIxOjMzOjM2XSAgIGdmbjogMDAwMDU5MzcgIG1mbjogMDAwMDU5MzcN
Cg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MzZdICAgZ2ZuOiAwMDAwNTkzOCAgbWZuOiAw
MDAwNTkzOA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzozNl0gICBnZm46IDAwMDA1OTM5
ICBtZm46IDAwMDA1OTM5DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjM2XSAgIGdmbjog
MDAwMDU5M2EgIG1mbjogMDAwMDU5M2ENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MzZd
ICAgZ2ZuOiAwMDAwNTkzYiAgbWZuOiAwMDAwNTkzYg0KDQooWEVOKSBbMjAxMi0wOC0zMSAy
MTozMzozNl0gICBnZm46IDAwMDA1OTNjICBtZm46IDAwMDA1OTNjDQoNCihYRU4pIFsyMDEy
LTA4LTMxIDIxOjMzOjM2XSAgIGdmbjogMDAwMDU5M2QgIG1mbjogMDAwMDU5M2QNCg0KKFhF
TikgWzIwMTItMDgtMzEgMjE6MzM6MzZdICAgZ2ZuOiAwMDAwNTkzZSAgbWZuOiAwMDAwNTkz
ZQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzozNl0gICBnZm46IDAwMDA1OTNmICBtZm46
IDAwMDA1OTNmDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjM2XSAgIGdmbjogMDAwMDU5
NDAgIG1mbjogMDAwMDU5NDANCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MzZdICAgZ2Zu
OiAwMDAwNTk0MSAgbWZuOiAwMDAwNTk0MQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoz
Nl0gICBnZm46IDAwMDA1OTQyICBtZm46IDAwMDA1OTQyDQoNCihYRU4pIFsyMDEyLTA4LTMx
IDIxOjMzOjM2XSAgIGdmbjogMDAwMDU5NDMgIG1mbjogMDAwMDU5NDMNCg0KKFhFTikgWzIw
MTItMDgtMzEgMjE6MzM6MzZdICAgZ2ZuOiAwMDAwNTk0NCAgbWZuOiAwMDAwNTk0NA0KDQoo
WEVOKSBbMjAxMi0wOC0zMSAyMTozMzozNl0gICBnZm46IDAwMDA1OTQ1ICBtZm46IDAwMDA1
OTQ1DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjM2XSAgIGdmbjogMDAwMDU5NDYgIG1m
bjogMDAwMDU5NDYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MzZdICAgZ2ZuOiAwMDAw
NTk0NyAgbWZuOiAwMDAwNTk0Nw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzozNl0gICBn
Zm46IDAwMDA1OTQ4ICBtZm46IDAwMDA1OTQ4DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMz
OjM2XSAgIGdmbjogMDAwMDU5NDkgIG1mbjogMDAwMDU5NDkNCg0KKFhFTikgWzIwMTItMDgt
MzEgMjE6MzM6MzddICAgZ2ZuOiAwMDAwNTk0YSAgbWZuOiAwMDAwNTk0YQ0KDQooWEVOKSBb
MjAxMi0wOC0zMSAyMTozMzozN10gICBnZm46IDAwMDA1OTRiICBtZm46IDAwMDA1OTRiDQoN
CihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjM3XSAgIGdmbjogMDAwMDU5NGMgIG1mbjogMDAw
MDU5NGMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MzddICAgZ2ZuOiAwMDAwNTk0ZCAg
bWZuOiAwMDAwNTk0ZA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzozN10gICBnZm46IDAw
MDA1OTRlICBtZm46IDAwMDA1OTRlDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjM3XSAg
IGdmbjogMDAwMDU5NGYgIG1mbjogMDAwMDU5NGYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6
MzM6MzddICAgZ2ZuOiAwMDAwNTk1MCAgbWZuOiAwMDAwNTk1MA0KDQooWEVOKSBbMjAxMi0w
OC0zMSAyMTozMzozN10gICBnZm46IDAwMDA1OTUxICBtZm46IDAwMDA1OTUxDQoNCihYRU4p
IFsyMDEyLTA4LTMxIDIxOjMzOjM3XSAgIGdmbjogMDAwMDU5NTIgIG1mbjogMDAwMDU5NTIN
Cg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MzddICAgZ2ZuOiAwMDAwNTk1MyAgbWZuOiAw
MDAwNTk1Mw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzozN10gICBnZm46IDAwMDA1OTU0
ICBtZm46IDAwMDA1OTU0DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjM3XSAgIGdmbjog
MDAwMDU5NTUgIG1mbjogMDAwMDU5NTUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6Mzdd
ICAgZ2ZuOiAwMDAwNTk1NiAgbWZuOiAwMDAwNTk1Ng0KDQooWEVOKSBbMjAxMi0wOC0zMSAy
MTozMzozN10gICBnZm46IDAwMDA1OTU3ICBtZm46IDAwMDA1OTU3DQoNCihYRU4pIFsyMDEy
LTA4LTMxIDIxOjMzOjM3XSAgIGdmbjogMDAwMDU5NTggIG1mbjogMDAwMDU5NTgNCg0KKFhF
TikgWzIwMTItMDgtMzEgMjE6MzM6MzddICAgZ2ZuOiAwMDAwNTk1OSAgbWZuOiAwMDAwNTk1
OQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzozN10gICBnZm46IDAwMDA1OTVhICBtZm46
IDAwMDA1OTVhDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjM3XSAgIGdmbjogMDAwMDU5
NWIgIG1mbjogMDAwMDU5NWINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MzddICAgZ2Zu
OiAwMDAwNTk1YyAgbWZuOiAwMDAwNTk1Yw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoz
N10gICBnZm46IDAwMDA1OTVkICBtZm46IDAwMDA1OTVkDQoNCihYRU4pIFsyMDEyLTA4LTMx
IDIxOjMzOjM3XSAgIGdmbjogMDAwMDU5NWUgIG1mbjogMDAwMDU5NWUNCg0KKFhFTikgWzIw
MTItMDgtMzEgMjE6MzM6MzddICAgZ2ZuOiAwMDAwNTk1ZiAgbWZuOiAwMDAwNTk1Zg0KDQoo
WEVOKSBbMjAxMi0wOC0zMSAyMTozMzozN10gICBnZm46IDAwMDA1OTYwICBtZm46IDAwMDA1
OTYwDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjM3XSAgIGdmbjogMDAwMDU5NjEgIG1m
bjogMDAwMDU5NjENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MzddICAgZ2ZuOiAwMDAw
NTk2MiAgbWZuOiAwMDAwNTk2Mg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzozN10gICBn
Zm46IDAwMDA1OTYzICBtZm46IDAwMDA1OTYzDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMz
OjM3XSAgIGdmbjogMDAwMDU5NjQgIG1mbjogMDAwMDU5NjQNCg0KKFhFTikgWzIwMTItMDgt
MzEgMjE6MzM6MzddICAgZ2ZuOiAwMDAwNTk2NSAgbWZuOiAwMDAwNTk2NQ0KDQooWEVOKSBb
MjAxMi0wOC0zMSAyMTozMzozN10gICBnZm46IDAwMDA1OTY2ICBtZm46IDAwMDA1OTY2DQoN
CihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjM3XSAgIGdmbjogMDAwMDU5NjcgIG1mbjogMDAw
MDU5NjcNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MzddICAgZ2ZuOiAwMDAwNTk2OCAg
bWZuOiAwMDAwNTk2OA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzozN10gICBnZm46IDAw
MDA1OTY5ICBtZm46IDAwMDA1OTY5DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjM3XSAg
IGdmbjogMDAwMDU5NmEgIG1mbjogMDAwMDU5NmENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6
MzM6MzddICAgZ2ZuOiAwMDAwNTk2YiAgbWZuOiAwMDAwNTk2Yg0KDQooWEVOKSBbMjAxMi0w
OC0zMSAyMTozMzozN10gICBnZm46IDAwMDA1OTZjICBtZm46IDAwMDA1OTZjDQoNCihYRU4p
IFsyMDEyLTA4LTMxIDIxOjMzOjM3XSAgIGdmbjogMDAwMDU5NmQgIG1mbjogMDAwMDU5NmQN
Cg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MzddICAgZ2ZuOiAwMDAwNTk2ZSAgbWZuOiAw
MDAwNTk2ZQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzozN10gICBnZm46IDAwMDA1OTZm
ICBtZm46IDAwMDA1OTZmDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjM3XSAgIGdmbjog
MDAwMDU5NzAgIG1mbjogMDAwMDU5NzANCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6Mzdd
ICAgZ2ZuOiAwMDAwNTk3MSAgbWZuOiAwMDAwNTk3MQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAy
MTozMzozN10gICBnZm46IDAwMDA1OTcyICBtZm46IDAwMDA1OTcyDQoNCihYRU4pIFsyMDEy
LTA4LTMxIDIxOjMzOjM3XSAgIGdmbjogMDAwMDU5NzMgIG1mbjogMDAwMDU5NzMNCg0KKFhF
TikgWzIwMTItMDgtMzEgMjE6MzM6MzddICAgZ2ZuOiAwMDAwNTk3NCAgbWZuOiAwMDAwNTk3
NA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzozN10gICBnZm46IDAwMDA1OTc1ICBtZm46
IDAwMDA1OTc1DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjM3XSAgIGdmbjogMDAwMDU5
NzYgIG1mbjogMDAwMDU5NzYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MzddICAgZ2Zu
OiAwMDAwNTk3NyAgbWZuOiAwMDAwNTk3Nw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoz
N10gICBnZm46IDAwMDA1OTc4ICBtZm46IDAwMDA1OTc4DQoNCihYRU4pIFsyMDEyLTA4LTMx
IDIxOjMzOjM3XSAgIGdmbjogMDAwMDU5NzkgIG1mbjogMDAwMDU5NzkNCg0KKFhFTikgWzIw
MTItMDgtMzEgMjE6MzM6MzddICAgZ2ZuOiAwMDAwNTk3YSAgbWZuOiAwMDAwNTk3YQ0KDQoo
WEVOKSBbMjAxMi0wOC0zMSAyMTozMzozN10gICBnZm46IDAwMDA1OTdiICBtZm46IDAwMDA1
OTdiDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjM3XSAgIGdmbjogMDAwMDU5N2MgIG1m
bjogMDAwMDU5N2MNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MzddICAgZ2ZuOiAwMDAw
NTk3ZCAgbWZuOiAwMDAwNTk3ZA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzozN10gICBn
Zm46IDAwMDA1OTdlICBtZm46IDAwMDA1OTdlDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMz
OjM3XSAgIGdmbjogMDAwMDU5N2YgIG1mbjogMDAwMDU5N2YNCg0KKFhFTikgWzIwMTItMDgt
MzEgMjE6MzM6MzddICAgZ2ZuOiAwMDAwNTk4MCAgbWZuOiAwMDAwNTk4MA0KDQooWEVOKSBb
MjAxMi0wOC0zMSAyMTozMzozN10gICBnZm46IDAwMDA1OTgxICBtZm46IDAwMDA1OTgxDQoN
CihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjM3XSAgIGdmbjogMDAwMDU5ODIgIG1mbjogMDAw
MDU5ODINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MzddICAgZ2ZuOiAwMDAwNTk4MyAg
bWZuOiAwMDAwNTk4Mw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzozN10gICBnZm46IDAw
MDA1OTg0ICBtZm46IDAwMDA1OTg0DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjM3XSAg
IGdmbjogMDAwMDU5ODUgIG1mbjogMDAwMDU5ODUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6
MzM6MzddICAgZ2ZuOiAwMDAwNTk4NiAgbWZuOiAwMDAwNTk4Ng0KDQooWEVOKSBbMjAxMi0w
OC0zMSAyMTozMzozN10gICBnZm46IDAwMDA1OTg3ICBtZm46IDAwMDA1OTg3DQoNCihYRU4p
IFsyMDEyLTA4LTMxIDIxOjMzOjM3XSAgIGdmbjogMDAwMDU5ODggIG1mbjogMDAwMDU5ODgN
Cg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MzddICAgZ2ZuOiAwMDAwNTk4OSAgbWZuOiAw
MDAwNTk4OQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzozOF0gICBnZm46IDAwMDA1OThh
ICBtZm46IDAwMDA1OThhDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjM4XSAgIGdmbjog
MDAwMDU5OGIgIG1mbjogMDAwMDU5OGINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6Mzhd
ICAgZ2ZuOiAwMDAwNTk4YyAgbWZuOiAwMDAwNTk4Yw0KDQooWEVOKSBbMjAxMi0wOC0zMSAy
MTozMzozOF0gICBnZm46IDAwMDA1OThkICBtZm46IDAwMDA1OThkDQoNCihYRU4pIFsyMDEy
LTA4LTMxIDIxOjMzOjM4XSAgIGdmbjogMDAwMDU5OGUgIG1mbjogMDAwMDU5OGUNCg0KKFhF
TikgWzIwMTItMDgtMzEgMjE6MzM6MzhdICAgZ2ZuOiAwMDAwNTk4ZiAgbWZuOiAwMDAwNTk4
Zg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzozOF0gICBnZm46IDAwMDA1OTkwICBtZm46
IDAwMDA1OTkwDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjM4XSAgIGdmbjogMDAwMDU5
OTEgIG1mbjogMDAwMDU5OTENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MzhdICAgZ2Zu
OiAwMDAwNTk5MiAgbWZuOiAwMDAwNTk5Mg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoz
OF0gICBnZm46IDAwMDA1OTkzICBtZm46IDAwMDA1OTkzDQoNCihYRU4pIFsyMDEyLTA4LTMx
IDIxOjMzOjM4XSAgIGdmbjogMDAwMDU5OTQgIG1mbjogMDAwMDU5OTQNCg0KKFhFTikgWzIw
MTItMDgtMzEgMjE6MzM6MzhdICAgZ2ZuOiAwMDAwNTk5NSAgbWZuOiAwMDAwNTk5NQ0KDQoo
WEVOKSBbMjAxMi0wOC0zMSAyMTozMzozOF0gICBnZm46IDAwMDA1OTk2ICBtZm46IDAwMDA1
OTk2DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjM4XSAgIGdmbjogMDAwMDU5OTcgIG1m
bjogMDAwMDU5OTcNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MzhdICAgZ2ZuOiAwMDAw
NTk5OCAgbWZuOiAwMDAwNTk5OA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzozOF0gICBn
Zm46IDAwMDA1OTk5ICBtZm46IDAwMDA1OTk5DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMz
OjM4XSAgIGdmbjogMDAwMDU5OWEgIG1mbjogMDAwMDU5OWENCg0KKFhFTikgWzIwMTItMDgt
MzEgMjE6MzM6MzhdICAgZ2ZuOiAwMDAwNTk5YiAgbWZuOiAwMDAwNTk5Yg0KDQooWEVOKSBb
MjAxMi0wOC0zMSAyMTozMzozOF0gICBnZm46IDAwMDA1OTljICBtZm46IDAwMDA1OTljDQoN
CihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjM4XSAgIGdmbjogMDAwMDU5OWQgIG1mbjogMDAw
MDU5OWQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MzhdICAgZ2ZuOiAwMDAwNTk5ZSAg
bWZuOiAwMDAwNTk5ZQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzozOF0gICBnZm46IDAw
MDA1OTlmICBtZm46IDAwMDA1OTlmDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjM4XSAg
IGdmbjogMDAwMDU5YTAgIG1mbjogMDAwMDU5YTANCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6
MzM6MzhdICAgZ2ZuOiAwMDAwNTlhMSAgbWZuOiAwMDAwNTlhMQ0KDQooWEVOKSBbMjAxMi0w
OC0zMSAyMTozMzozOF0gICBnZm46IDAwMDA1OWEyICBtZm46IDAwMDA1OWEyDQoNCihYRU4p
IFsyMDEyLTA4LTMxIDIxOjMzOjM4XSAgIGdmbjogMDAwMDU5YTMgIG1mbjogMDAwMDU5YTMN
Cg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MzhdICAgZ2ZuOiAwMDAwNTlhNCAgbWZuOiAw
MDAwNTlhNA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzozOF0gICBnZm46IDAwMDA1OWE1
ICBtZm46IDAwMDA1OWE1DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjM4XSAgIGdmbjog
MDAwMDU5YTYgIG1mbjogMDAwMDU5YTYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6Mzhd
ICAgZ2ZuOiAwMDAwNTlhNyAgbWZuOiAwMDAwNTlhNw0KDQooWEVOKSBbMjAxMi0wOC0zMSAy
MTozMzozOF0gICBnZm46IDAwMDA1OWE4ICBtZm46IDAwMDA1OWE4DQoNCihYRU4pIFsyMDEy
LTA4LTMxIDIxOjMzOjM4XSAgIGdmbjogMDAwMDU5YTkgIG1mbjogMDAwMDU5YTkNCg0KKFhF
TikgWzIwMTItMDgtMzEgMjE6MzM6MzhdICAgZ2ZuOiAwMDAwNTlhYSAgbWZuOiAwMDAwNTlh
YQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzozOF0gICBnZm46IDAwMDA1OWFiICBtZm46
IDAwMDA1OWFiDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjM4XSAgIGdmbjogMDAwMDU5
YWMgIG1mbjogMDAwMDU5YWMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MzhdICAgZ2Zu
OiAwMDAwNTlhZCAgbWZuOiAwMDAwNTlhZA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoz
OF0gICBnZm46IDAwMDA1OWFlICBtZm46IDAwMDA1OWFlDQoNCihYRU4pIFsyMDEyLTA4LTMx
IDIxOjMzOjM4XSAgIGdmbjogMDAwMDU5YWYgIG1mbjogMDAwMDU5YWYNCg0KKFhFTikgWzIw
MTItMDgtMzEgMjE6MzM6MzhdICAgZ2ZuOiAwMDAwNTliMCAgbWZuOiAwMDAwNTliMA0KDQoo
WEVOKSBbMjAxMi0wOC0zMSAyMTozMzozOF0gICBnZm46IDAwMDA1OWIxICBtZm46IDAwMDA1
OWIxDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjM4XSAgIGdmbjogMDAwMDU5YjIgIG1m
bjogMDAwMDU5YjINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MzhdICAgZ2ZuOiAwMDAw
NTliMyAgbWZuOiAwMDAwNTliMw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzozOF0gICBn
Zm46IDAwMDA1OWI0ICBtZm46IDAwMDA1OWI0DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMz
OjM4XSAgIGdmbjogMDAwMDU5YjUgIG1mbjogMDAwMDU5YjUNCg0KKFhFTikgWzIwMTItMDgt
MzEgMjE6MzM6MzhdICAgZ2ZuOiAwMDAwNTliNiAgbWZuOiAwMDAwNTliNg0KDQooWEVOKSBb
MjAxMi0wOC0zMSAyMTozMzozOF0gICBnZm46IDAwMDA1OWI3ICBtZm46IDAwMDA1OWI3DQoN
CihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjM4XSAgIGdmbjogMDAwMDU5YjggIG1mbjogMDAw
MDU5YjgNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MzhdICAgZ2ZuOiAwMDAwNTliOSAg
bWZuOiAwMDAwNTliOQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzozOF0gICBnZm46IDAw
MDA1OWJhICBtZm46IDAwMDA1OWJhDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjM4XSAg
IGdmbjogMDAwMDU5YmIgIG1mbjogMDAwMDU5YmINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6
MzM6MzhdICAgZ2ZuOiAwMDAwNTliYyAgbWZuOiAwMDAwNTliYw0KDQooWEVOKSBbMjAxMi0w
OC0zMSAyMTozMzozOF0gICBnZm46IDAwMDA1OWJkICBtZm46IDAwMDA1OWJkDQoNCihYRU4p
IFsyMDEyLTA4LTMxIDIxOjMzOjM4XSAgIGdmbjogMDAwMDU5YmUgIG1mbjogMDAwMDU5YmUN
Cg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MzhdICAgZ2ZuOiAwMDAwNTliZiAgbWZuOiAw
MDAwNTliZg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzozOF0gICBnZm46IDAwMDA1OWMw
ICBtZm46IDAwMDA1OWMwDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjM4XSAgIGdmbjog
MDAwMDU5YzEgIG1mbjogMDAwMDU5YzENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6Mzhd
ICAgZ2ZuOiAwMDAwNTljMiAgbWZuOiAwMDAwNTljMg0KDQooWEVOKSBbMjAxMi0wOC0zMSAy
MTozMzozOF0gICBnZm46IDAwMDA1OWMzICBtZm46IDAwMDA1OWMzDQoNCihYRU4pIFsyMDEy
LTA4LTMxIDIxOjMzOjM4XSAgIGdmbjogMDAwMDU5YzQgIG1mbjogMDAwMDU5YzQNCg0KKFhF
TikgWzIwMTItMDgtMzEgMjE6MzM6MzhdICAgZ2ZuOiAwMDAwNTljNSAgbWZuOiAwMDAwNTlj
NQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzozOF0gICBnZm46IDAwMDA1OWM2ICBtZm46
IDAwMDA1OWM2DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjM4XSAgIGdmbjogMDAwMDU5
YzcgIG1mbjogMDAwMDU5YzcNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MzhdICAgZ2Zu
OiAwMDAwNTljOCAgbWZuOiAwMDAwNTljOA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoz
OF0gICBnZm46IDAwMDA1OWM5ICBtZm46IDAwMDA1OWM5DQoNCihYRU4pIFsyMDEyLTA4LTMx
IDIxOjMzOjM4XSAgIGdmbjogMDAwMDU5Y2EgIG1mbjogMDAwMDU5Y2ENCg0KKFhFTikgWzIw
MTItMDgtMzEgMjE6MzM6MzldICAgZ2ZuOiAwMDAwNTljYiAgbWZuOiAwMDAwNTljYg0KDQoo
WEVOKSBbMjAxMi0wOC0zMSAyMTozMzozOV0gICBnZm46IDAwMDA1OWNjICBtZm46IDAwMDA1
OWNjDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjM5XSAgIGdmbjogMDAwMDU5Y2QgIG1m
bjogMDAwMDU5Y2QNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MzldICAgZ2ZuOiAwMDAw
NTljZSAgbWZuOiAwMDAwNTljZQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzozOV0gICBn
Zm46IDAwMDA1OWNmICBtZm46IDAwMDA1OWNmDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMz
OjM5XSAgIGdmbjogMDAwMDU5ZDAgIG1mbjogMDAwMDU5ZDANCg0KKFhFTikgWzIwMTItMDgt
MzEgMjE6MzM6MzldICAgZ2ZuOiAwMDAwNTlkMSAgbWZuOiAwMDAwNTlkMQ0KDQooWEVOKSBb
MjAxMi0wOC0zMSAyMTozMzozOV0gICBnZm46IDAwMDA1OWQyICBtZm46IDAwMDA1OWQyDQoN
CihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjM5XSAgIGdmbjogMDAwMDU5ZDMgIG1mbjogMDAw
MDU5ZDMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MzldICAgZ2ZuOiAwMDAwNTlkNCAg
bWZuOiAwMDAwNTlkNA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzozOV0gICBnZm46IDAw
MDA1OWQ1ICBtZm46IDAwMDA1OWQ1DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjM5XSAg
IGdmbjogMDAwMDU5ZDYgIG1mbjogMDAwMDU5ZDYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6
MzM6MzldICAgZ2ZuOiAwMDAwNTlkNyAgbWZuOiAwMDAwNTlkNw0KDQooWEVOKSBbMjAxMi0w
OC0zMSAyMTozMzozOV0gICBnZm46IDAwMDA1OWQ4ICBtZm46IDAwMDA1OWQ4DQoNCihYRU4p
IFsyMDEyLTA4LTMxIDIxOjMzOjM5XSAgIGdmbjogMDAwMDU5ZDkgIG1mbjogMDAwMDU5ZDkN
Cg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MzldICAgZ2ZuOiAwMDAwNTlkYSAgbWZuOiAw
MDAwNTlkYQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzozOV0gICBnZm46IDAwMDA1OWRi
ICBtZm46IDAwMDA1OWRiDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjM5XSAgIGdmbjog
MDAwMDU5ZGMgIG1mbjogMDAwMDU5ZGMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6Mzld
ICAgZ2ZuOiAwMDAwNTlkZCAgbWZuOiAwMDAwNTlkZA0KDQooWEVOKSBbMjAxMi0wOC0zMSAy
MTozMzozOV0gICBnZm46IDAwMDA1OWRlICBtZm46IDAwMDA1OWRlDQoNCihYRU4pIFsyMDEy
LTA4LTMxIDIxOjMzOjM5XSAgIGdmbjogMDAwMDU5ZGYgIG1mbjogMDAwMDU5ZGYNCg0KKFhF
TikgWzIwMTItMDgtMzEgMjE6MzM6MzldICAgZ2ZuOiAwMDAwNTllMCAgbWZuOiAwMDAwNTll
MA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzozOV0gICBnZm46IDAwMDA1OWUxICBtZm46
IDAwMDA1OWUxDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjM5XSAgIGdmbjogMDAwMDU5
ZTIgIG1mbjogMDAwMDU5ZTINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MzldICAgZ2Zu
OiAwMDAwNTllMyAgbWZuOiAwMDAwNTllMw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzoz
OV0gICBnZm46IDAwMDA1OWU0ICBtZm46IDAwMDA1OWU0DQoNCihYRU4pIFsyMDEyLTA4LTMx
IDIxOjMzOjM5XSAgIGdmbjogMDAwMDU5ZTUgIG1mbjogMDAwMDU5ZTUNCg0KKFhFTikgWzIw
MTItMDgtMzEgMjE6MzM6MzldICAgZ2ZuOiAwMDAwNTllNiAgbWZuOiAwMDAwNTllNg0KDQoo
WEVOKSBbMjAxMi0wOC0zMSAyMTozMzozOV0gICBnZm46IDAwMDA1OWU3ICBtZm46IDAwMDA1
OWU3DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjM5XSAgIGdmbjogMDAwMDU5ZTggIG1m
bjogMDAwMDU5ZTgNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MzldICAgZ2ZuOiAwMDAw
NTllOSAgbWZuOiAwMDAwNTllOQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzozOV0gICBn
Zm46IDAwMDA1OWVhICBtZm46IDAwMDA1OWVhDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMz
OjM5XSAgIGdmbjogMDAwMDU5ZWIgIG1mbjogMDAwMDU5ZWINCg0KKFhFTikgWzIwMTItMDgt
MzEgMjE6MzM6MzldICAgZ2ZuOiAwMDAwNTllYyAgbWZuOiAwMDAwNTllYw0KDQooWEVOKSBb
MjAxMi0wOC0zMSAyMTozMzozOV0gICBnZm46IDAwMDA1OWVkICBtZm46IDAwMDA1OWVkDQoN
CihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjM5XSAgIGdmbjogMDAwMDU5ZWUgIG1mbjogMDAw
MDU5ZWUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MzldICAgZ2ZuOiAwMDAwNTllZiAg
bWZuOiAwMDAwNTllZg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzozOV0gICBnZm46IDAw
MDA1OWYwICBtZm46IDAwMDA1OWYwDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjM5XSAg
IGdmbjogMDAwMDU5ZjEgIG1mbjogMDAwMDU5ZjENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6
MzM6MzldICAgZ2ZuOiAwMDAwNTlmMiAgbWZuOiAwMDAwNTlmMg0KDQpbICA0ODUuNjIzNzkz
XSBhKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MzldICAgZ2ZuOiAwMDAwNTlmMyAgbWZuOiAw
MDAwNTlmMw0KDQp0YTMuMDA6IHFjIHRpbWVvKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6Mzld
ICAgZ2ZuOiAwMDAwNTlmNCAgbWZuOiAwMDAwNTlmNA0KDQp1dCAoY21kIDB4ZWMpDQoNCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MzldICAgZ2ZuOiAwMDAwNTlmNSAgbWZuOiAwMDAw
NTlmNQ0KDQpbICA0ODUuNjgxOTg0XSBhdGEzLjAwOiBmYWlsZWQgdChYRU4pIFsyMDEyLTA4
LTMxIDIxOjMzOjM5XSAgIGdmbjogMDAwMDU5ZjYgIG1mbjogMDAwMDU5ZjYNCg0KbyBJREVO
VElGWSAoSS9PIChYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjM5XSAgIGdmbjogMDAwMDU5Zjcg
IG1mbjogMDAwMDU5ZjcNCg0KZXJyb3IsIGVycl9tYXNrPTB4NCkNCg0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMzozOV0gICBnZm46IDAwMDA1OWY4ICBtZm46IDAwMDA1OWY4DQoNClsg
IDQ4NS43NDg1MzBdIGEoWEVOKSBbMjAxMi0wOC0zMSAyMTozMzozOV0gICBnZm46IDAwMDA1
OWY5ICBtZm46IDAwMDA1OWY5DQoNCnRhMy4wMDogcmV2YWxpZGF0aW9uIGZhaWxlZCAoZXJy
KFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MzldICAgZ2ZuOiAwMDAwNTlmYSAgbWZuOiAwMDAw
NTlmYQ0KDQpubz0tNSkNCg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzozOV0gICBnZm46
IDAwMDA1OWZiICBtZm46IDAwMDA1OWZiDQoNClsgIDQ4NS44MTA5MjBdIGF0YTM6IGhhcmQg
cmVzZXR0KFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MzldICAgZ2ZuOiAwMDAwNTlmYyAgbWZu
OiAwMDAwNTlmYw0KDQppbmcgbGluaw0KDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjM5
XSAgIGdmbjogMDAwMDU5ZmQgIG1mbjogMDAwMDU5ZmQNCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzM6MzldICAgZ2ZuOiAwMDAwNTlmZSAgbWZuOiAwMDAwNTlmZQ0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMzozOV0gICBnZm46IDAwMDA1OWZmICBtZm46IDAwMDA1OWZmDQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMzOjM5XSAgIGdmbjogMDAwMDVhMDAgIG1mbjogMDAwMDVh
MDANCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6MzldICAgZ2ZuOiAwMDAwNWEwMSAgbWZu
OiAwMDAwNWEwMQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzozOV0gICBnZm46IDAwMDA1
YTAyICBtZm46IDAwMDA1YTAyDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjM5XSAgIGdm
bjogMDAwMDVhMDMgIG1mbjogMDAwMDVhMDMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6
MzldICAgZ2ZuOiAwMDAwNWEwNCAgbWZuOiAwMDAwNWEwNA0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMzozOV0gICBnZm46IDAwMDA1YTA1ICBtZm46IDAwMDA1YTA1DQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMzOjM5XSAgIGdmbjogMDAwMDVhMDYgIG1mbjogMDAwMDVhMDYNCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NDBdICAgZ2ZuOiAwMDAwNWEwNyAgbWZuOiAwMDAw
NWEwNw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo0MF0gICBnZm46IDAwMDA1YTA4ICBt
Zm46IDAwMDA1YTA4DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjQwXSAgIGdmbjogMDAw
MDVhMDkgIG1mbjogMDAwMDVhMDkNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NDBdICAg
Z2ZuOiAwMDAwNWEwYSAgbWZuOiAwMDAwNWEwYQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
Mzo0MF0gICBnZm46IDAwMDA1YTBiICBtZm46IDAwMDA1YTBiDQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMzOjQwXSAgIGdmbjogMDAwMDVhMGMgIG1mbjogMDAwMDVhMGMNCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzM6NDBdICAgZ2ZuOiAwMDAwNWEwZCAgbWZuOiAwMDAwNWEwZA0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo0MF0gICBnZm46IDAwMDA1YTBlICBtZm46IDAw
MDA1YTBlDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjQwXSAgIGdmbjogMDAwMDVhMGYg
IG1mbjogMDAwMDVhMGYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NDBdICAgZ2ZuOiAw
MDAwNWExMCAgbWZuOiAwMDAwNWExMA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo0MF0g
ICBnZm46IDAwMDA1YTExICBtZm46IDAwMDA1YTExDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMzOjQwXSAgIGdmbjogMDAwMDVhMTIgIG1mbjogMDAwMDVhMTINCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzM6NDBdICAgZ2ZuOiAwMDAwNWExMyAgbWZuOiAwMDAwNWExMw0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMzo0MF0gICBnZm46IDAwMDA1YTE0ICBtZm46IDAwMDA1YTE0
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjQwXSAgIGdmbjogMDAwMDVhMTUgIG1mbjog
MDAwMDVhMTUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NDBdICAgZ2ZuOiAwMDAwNWEx
NiAgbWZuOiAwMDAwNWExNg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo0MF0gICBnZm46
IDAwMDA1YTE3ICBtZm46IDAwMDA1YTE3DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjQw
XSAgIGdmbjogMDAwMDVhMTggIG1mbjogMDAwMDVhMTgNCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzM6NDBdICAgZ2ZuOiAwMDAwNWExOSAgbWZuOiAwMDAwNWExOQ0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMzo0MF0gICBnZm46IDAwMDA1YTFhICBtZm46IDAwMDA1YTFhDQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMzOjQwXSAgIGdmbjogMDAwMDVhMWIgIG1mbjogMDAwMDVh
MWINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NDBdICAgZ2ZuOiAwMDAwNWExYyAgbWZu
OiAwMDAwNWExYw0KDQpbICA0ODYuMzQyMDYxXSBhKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6
NDBdICAgZ2ZuOiAwMDAwNWExZCAgbWZuOiAwMDAwNWExZA0KDQp0YTM6IFNBVEEgbGluayB1
KFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NDBdICAgZ2ZuOiAwMDAwNWExZSAgbWZuOiAwMDAw
NWExZQ0KDQpwIDYuMCBHYnBzIChTU3RhKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NDBdICAg
Z2ZuOiAwMDAwNWExZiAgbWZuOiAwMDAwNWExZg0KDQp0dXMgMTMzIFNDb250cm9sIDMwMCkN
Cg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo0MF0gICBnZm46IDAwMDA1YTIwICBtZm46
IDAwMDA1YTIwDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjQwXSAgIGdmbjogMDAwMDVh
MjEgIG1mbjogMDAwMDVhMjENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NDBdICAgZ2Zu
OiAwMDAwNWEyMiAgbWZuOiAwMDAwNWEyMg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo0
MF0gICBnZm46IDAwMDA1YTIzICBtZm46IDAwMDA1YTIzDQoNCihYRU4pIFsyMDEyLTA4LTMx
IDIxOjMzOjQwXSAgIGdmbjogMDAwMDVhMjQgIG1mbjogMDAwMDVhMjQNCg0KKFhFTikgWzIw
MTItMDgtMzEgMjE6MzM6NDBdICAgZ2ZuOiAwMDAwNWEyNSAgbWZuOiAwMDAwNWEyNQ0KDQoo
WEVOKSBbMjAxMi0wOC0zMSAyMTozMzo0MF0gICBnZm46IDAwMDA1YTI2ICBtZm46IDAwMDA1
YTI2DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjQwXSAgIGdmbjogMDAwMDVhMjcgIG1m
bjogMDAwMDVhMjcNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NDBdICAgZ2ZuOiAwMDAw
NWEyOCAgbWZuOiAwMDAwNWEyOA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo0MF0gICBn
Zm46IDAwMDA1YTI5ICBtZm46IDAwMDA1YTI5DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMz
OjQwXSAgIGdmbjogMDAwMDVhMmEgIG1mbjogMDAwMDVhMmENCg0KKFhFTikgWzIwMTItMDgt
MzEgMjE6MzM6NDBdICAgZ2ZuOiAwMDAwNWEyYiAgbWZuOiAwMDAwNWEyYg0KDQooWEVOKSBb
MjAxMi0wOC0zMSAyMTozMzo0MF0gICBnZm46IDAwMDA1YTJjICBtZm46IDAwMDA1YTJjDQoN
CihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjQwXSAgIGdmbjogMDAwMDVhMmQgIG1mbjogMDAw
MDVhMmQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NDBdICAgZ2ZuOiAwMDAwNWEyZSAg
bWZuOiAwMDAwNWEyZQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo0MF0gICBnZm46IDAw
MDA1YTJmICBtZm46IDAwMDA1YTJmDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjQwXSAg
IGdmbjogMDAwMDVhMzAgIG1mbjogMDAwMDVhMzANCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6
MzM6NDBdICAgZ2ZuOiAwMDAwNWEzMSAgbWZuOiAwMDAwNWEzMQ0KDQooWEVOKSBbMjAxMi0w
OC0zMSAyMTozMzo0MF0gICBnZm46IDAwMDA1YTMyICBtZm46IDAwMDA1YTMyDQoNCihYRU4p
IFsyMDEyLTA4LTMxIDIxOjMzOjQwXSAgIGdmbjogMDAwMDVhMzMgIG1mbjogMDAwMDVhMzMN
Cg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NDBdICAgZ2ZuOiAwMDAwNWEzNCAgbWZuOiAw
MDAwNWEzNA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo0MF0gICBnZm46IDAwMDA1YTM1
ICBtZm46IDAwMDA1YTM1DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjQwXSAgIGdmbjog
MDAwMDVhMzYgIG1mbjogMDAwMDVhMzYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NDBd
ICAgZ2ZuOiAwMDAwNWEzNyAgbWZuOiAwMDAwNWEzNw0KDQooWEVOKSBbMjAxMi0wOC0zMSAy
MTozMzo0MF0gICBnZm46IDAwMDA1YTM4ICBtZm46IDAwMDA1YTM4DQoNCihYRU4pIFsyMDEy
LTA4LTMxIDIxOjMzOjQwXSAgIGdmbjogMDAwMDVhMzkgIG1mbjogMDAwMDVhMzkNCg0KKFhF
TikgWzIwMTItMDgtMzEgMjE6MzM6NDBdICAgZ2ZuOiAwMDAwNWEzYSAgbWZuOiAwMDAwNWEz
YQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo0MF0gICBnZm46IDAwMDA1YTNiICBtZm46
IDAwMDA1YTNiDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjQwXSAgIGdmbjogMDAwMDVh
M2MgIG1mbjogMDAwMDVhM2MNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NDBdICAgZ2Zu
OiAwMDAwNWEzZCAgbWZuOiAwMDAwNWEzZA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo0
MF0gICBnZm46IDAwMDA1YTNlICBtZm46IDAwMDA1YTNlDQoNCihYRU4pIFsyMDEyLTA4LTMx
IDIxOjMzOjQwXSAgIGdmbjogMDAwMDVhM2YgIG1mbjogMDAwMDVhM2YNCg0KKFhFTikgWzIw
MTItMDgtMzEgMjE6MzM6NDBdICAgZ2ZuOiAwMDAwNWE0MCAgbWZuOiAwMDAwNWE0MA0KDQoo
WEVOKSBbMjAxMi0wOC0zMSAyMTozMzo0MF0gICBnZm46IDAwMDA1YTQxICBtZm46IDAwMDA1
YTQxDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjQwXSAgIGdmbjogMDAwMDVhNDIgIG1m
bjogMDAwMDVhNDINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NDBdICAgZ2ZuOiAwMDAw
NWE0MyAgbWZuOiAwMDAwNWE0Mw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo0MF0gICBn
Zm46IDAwMDA1YTQ0ICBtZm46IDAwMDA1YTQ0DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMz
OjQwXSAgIGdmbjogMDAwMDVhNDUgIG1mbjogMDAwMDVhNDUNCg0KKFhFTikgWzIwMTItMDgt
MzEgMjE6MzM6NDFdICAgZ2ZuOiAwMDAwNWE0NiAgbWZuOiAwMDAwNWE0Ng0KDQooWEVOKSBb
MjAxMi0wOC0zMSAyMTozMzo0MV0gICBnZm46IDAwMDA1YTQ3ICBtZm46IDAwMDA1YTQ3DQoN
CihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjQxXSAgIGdmbjogMDAwMDVhNDggIG1mbjogMDAw
MDVhNDgNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NDFdICAgZ2ZuOiAwMDAwNWE0OSAg
bWZuOiAwMDAwNWE0OQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo0MV0gICBnZm46IDAw
MDA1YTRhICBtZm46IDAwMDA1YTRhDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjQxXSAg
IGdmbjogMDAwMDVhNGIgIG1mbjogMDAwMDVhNGINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6
MzM6NDFdICAgZ2ZuOiAwMDAwNWE0YyAgbWZuOiAwMDAwNWE0Yw0KDQooWEVOKSBbMjAxMi0w
OC0zMSAyMTozMzo0MV0gICBnZm46IDAwMDA1YTRkICBtZm46IDAwMDA1YTRkDQoNCihYRU4p
IFsyMDEyLTA4LTMxIDIxOjMzOjQxXSAgIGdmbjogMDAwMDVhNGUgIG1mbjogMDAwMDVhNGUN
Cg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NDFdICAgZ2ZuOiAwMDAwNWE0ZiAgbWZuOiAw
MDAwNWE0Zg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo0MV0gICBnZm46IDAwMDA1YTUw
ICBtZm46IDAwMDA1YTUwDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjQxXSAgIGdmbjog
MDAwMDVhNTEgIG1mbjogMDAwMDVhNTENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NDFd
ICAgZ2ZuOiAwMDAwNWE1MiAgbWZuOiAwMDAwNWE1Mg0KDQooWEVOKSBbMjAxMi0wOC0zMSAy
MTozMzo0MV0gICBnZm46IDAwMDA1YTUzICBtZm46IDAwMDA1YTUzDQoNCihYRU4pIFsyMDEy
LTA4LTMxIDIxOjMzOjQxXSAgIGdmbjogMDAwMDVhNTQgIG1mbjogMDAwMDVhNTQNCg0KKFhF
TikgWzIwMTItMDgtMzEgMjE6MzM6NDFdICAgZ2ZuOiAwMDAwNWE1NSAgbWZuOiAwMDAwNWE1
NQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo0MV0gICBnZm46IDAwMDA1YTU2ICBtZm46
IDAwMDA1YTU2DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjQxXSAgIGdmbjogMDAwMDVh
NTcgIG1mbjogMDAwMDVhNTcNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NDFdICAgZ2Zu
OiAwMDAwNWE1OCAgbWZuOiAwMDAwNWE1OA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo0
MV0gICBnZm46IDAwMDA1YTU5ICBtZm46IDAwMDA1YTU5DQoNCihYRU4pIFsyMDEyLTA4LTMx
IDIxOjMzOjQxXSAgIGdmbjogMDAwMDVhNWEgIG1mbjogMDAwMDVhNWENCg0KKFhFTikgWzIw
MTItMDgtMzEgMjE6MzM6NDFdICAgZ2ZuOiAwMDAwNWE1YiAgbWZuOiAwMDAwNWE1Yg0KDQoo
WEVOKSBbMjAxMi0wOC0zMSAyMTozMzo0MV0gICBnZm46IDAwMDA1YTVjICBtZm46IDAwMDA1
YTVjDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjQxXSAgIGdmbjogMDAwMDVhNWQgIG1m
bjogMDAwMDVhNWQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NDFdICAgZ2ZuOiAwMDAw
NWE1ZSAgbWZuOiAwMDAwNWE1ZQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo0MV0gICBn
Zm46IDAwMDA1YTVmICBtZm46IDAwMDA1YTVmDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMz
OjQxXSAgIGdmbjogMDAwMDVhNjAgIG1mbjogMDAwMDVhNjANCg0KKFhFTikgWzIwMTItMDgt
MzEgMjE6MzM6NDFdICAgZ2ZuOiAwMDAwNWE2MSAgbWZuOiAwMDAwNWE2MQ0KDQooWEVOKSBb
MjAxMi0wOC0zMSAyMTozMzo0MV0gICBnZm46IDAwMDA1YTYyICBtZm46IDAwMDA1YTYyDQoN
CihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjQxXSAgIGdmbjogMDAwMDVhNjMgIG1mbjogMDAw
MDVhNjMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NDFdICAgZ2ZuOiAwMDAwNWE2NCAg
bWZuOiAwMDAwNWE2NA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo0MV0gICBnZm46IDAw
MDA1YTY1ICBtZm46IDAwMDA1YTY1DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjQxXSAg
IGdmbjogMDAwMDVhNjYgIG1mbjogMDAwMDVhNjYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6
MzM6NDFdICAgZ2ZuOiAwMDAwNWE2NyAgbWZuOiAwMDAwNWE2Nw0KDQooWEVOKSBbMjAxMi0w
OC0zMSAyMTozMzo0MV0gICBnZm46IDAwMDA1YTY4ICBtZm46IDAwMDA1YTY4DQoNCihYRU4p
IFsyMDEyLTA4LTMxIDIxOjMzOjQxXSAgIGdmbjogMDAwMDVhNjkgIG1mbjogMDAwMDVhNjkN
Cg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NDFdICAgZ2ZuOiAwMDAwNWE2YSAgbWZuOiAw
MDAwNWE2YQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo0MV0gICBnZm46IDAwMDA1YTZi
ICBtZm46IDAwMDA1YTZiDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjQxXSAgIGdmbjog
MDAwMDVhNmMgIG1mbjogMDAwMDVhNmMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NDFd
ICAgZ2ZuOiAwMDAwNWE2ZCAgbWZuOiAwMDAwNWE2ZA0KDQooWEVOKSBbMjAxMi0wOC0zMSAy
MTozMzo0MV0gICBnZm46IDAwMDA1YTZlICBtZm46IDAwMDA1YTZlDQoNCihYRU4pIFsyMDEy
LTA4LTMxIDIxOjMzOjQxXSAgIGdmbjogMDAwMDVhNmYgIG1mbjogMDAwMDVhNmYNCg0KKFhF
TikgWzIwMTItMDgtMzEgMjE6MzM6NDFdICAgZ2ZuOiAwMDAwNWE3MCAgbWZuOiAwMDAwNWE3
MA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo0MV0gICBnZm46IDAwMDA1YTcxICBtZm46
IDAwMDA1YTcxDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjQxXSAgIGdmbjogMDAwMDVh
NzIgIG1mbjogMDAwMDVhNzINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NDFdICAgZ2Zu
OiAwMDAwNWE3MyAgbWZuOiAwMDAwNWE3Mw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo0
MV0gICBnZm46IDAwMDA1YTc0ICBtZm46IDAwMDA1YTc0DQoNCihYRU4pIFsyMDEyLTA4LTMx
IDIxOjMzOjQxXSAgIGdmbjogMDAwMDVhNzUgIG1mbjogMDAwMDVhNzUNCg0KKFhFTikgWzIw
MTItMDgtMzEgMjE6MzM6NDFdICAgZ2ZuOiAwMDAwNWE3NiAgbWZuOiAwMDAwNWE3Ng0KDQoo
WEVOKSBbMjAxMi0wOC0zMSAyMTozMzo0MV0gICBnZm46IDAwMDA1YTc3ICBtZm46IDAwMDA1
YTc3DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjQxXSAgIGdmbjogMDAwMDVhNzggIG1m
bjogMDAwMDVhNzgNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NDFdICAgZ2ZuOiAwMDAw
NWE3OSAgbWZuOiAwMDAwNWE3OQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo0MV0gICBn
Zm46IDAwMDA1YTdhICBtZm46IDAwMDA1YTdhDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMz
OjQxXSAgIGdmbjogMDAwMDVhN2IgIG1mbjogMDAwMDVhN2INCg0KKFhFTikgWzIwMTItMDgt
MzEgMjE6MzM6NDFdICAgZ2ZuOiAwMDAwNWE3YyAgbWZuOiAwMDAwNWE3Yw0KDQooWEVOKSBb
MjAxMi0wOC0zMSAyMTozMzo0MV0gICBnZm46IDAwMDA1YTdkICBtZm46IDAwMDA1YTdkDQoN
CihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjQxXSAgIGdmbjogMDAwMDVhN2UgIG1mbjogMDAw
MDVhN2UNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NDFdICAgZ2ZuOiAwMDAwNWE3ZiAg
bWZuOiAwMDAwNWE3Zg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo0MV0gICBnZm46IDAw
MDA1YTgwICBtZm46IDAwMDA1YTgwDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjQxXSAg
IGdmbjogMDAwMDVhODEgIG1mbjogMDAwMDVhODENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6
MzM6NDFdICAgZ2ZuOiAwMDAwNWE4MiAgbWZuOiAwMDAwNWE4Mg0KDQooWEVOKSBbMjAxMi0w
OC0zMSAyMTozMzo0MV0gICBnZm46IDAwMDA1YTgzICBtZm46IDAwMDA1YTgzDQoNCihYRU4p
IFsyMDEyLTA4LTMxIDIxOjMzOjQxXSAgIGdmbjogMDAwMDVhODQgIG1mbjogMDAwMDVhODQN
Cg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NDFdICAgZ2ZuOiAwMDAwNWE4NSAgbWZuOiAw
MDAwNWE4NQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo0Ml0gICBnZm46IDAwMDA1YTg2
ICBtZm46IDAwMDA1YTg2DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjQyXSAgIGdmbjog
MDAwMDVhODcgIG1mbjogMDAwMDVhODcNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NDJd
ICAgZ2ZuOiAwMDAwNWE4OCAgbWZuOiAwMDAwNWE4OA0KDQooWEVOKSBbMjAxMi0wOC0zMSAy
MTozMzo0Ml0gICBnZm46IDAwMDA1YTg5ICBtZm46IDAwMDA1YTg5DQoNCihYRU4pIFsyMDEy
LTA4LTMxIDIxOjMzOjQyXSAgIGdmbjogMDAwMDVhOGEgIG1mbjogMDAwMDVhOGENCg0KKFhF
TikgWzIwMTItMDgtMzEgMjE6MzM6NDJdICAgZ2ZuOiAwMDAwNWE4YiAgbWZuOiAwMDAwNWE4
Yg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo0Ml0gICBnZm46IDAwMDA1YThjICBtZm46
IDAwMDA1YThjDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjQyXSAgIGdmbjogMDAwMDVh
OGQgIG1mbjogMDAwMDVhOGQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NDJdICAgZ2Zu
OiAwMDAwNWE4ZSAgbWZuOiAwMDAwNWE4ZQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo0
Ml0gICBnZm46IDAwMDA1YThmICBtZm46IDAwMDA1YThmDQoNCihYRU4pIFsyMDEyLTA4LTMx
IDIxOjMzOjQyXSAgIGdmbjogMDAwMDVhOTAgIG1mbjogMDAwMDVhOTANCg0KKFhFTikgWzIw
MTItMDgtMzEgMjE6MzM6NDJdICAgZ2ZuOiAwMDAwNWE5MSAgbWZuOiAwMDAwNWE5MQ0KDQoo
WEVOKSBbMjAxMi0wOC0zMSAyMTozMzo0Ml0gICBnZm46IDAwMDA1YTkyICBtZm46IDAwMDA1
YTkyDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjQyXSAgIGdmbjogMDAwMDVhOTMgIG1m
bjogMDAwMDVhOTMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NDJdICAgZ2ZuOiAwMDAw
NWE5NCAgbWZuOiAwMDAwNWE5NA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo0Ml0gICBn
Zm46IDAwMDA1YTk1ICBtZm46IDAwMDA1YTk1DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMz
OjQyXSAgIGdmbjogMDAwMDVhOTYgIG1mbjogMDAwMDVhOTYNCg0KKFhFTikgWzIwMTItMDgt
MzEgMjE6MzM6NDJdICAgZ2ZuOiAwMDAwNWE5NyAgbWZuOiAwMDAwNWE5Nw0KDQooWEVOKSBb
MjAxMi0wOC0zMSAyMTozMzo0Ml0gICBnZm46IDAwMDA1YTk4ICBtZm46IDAwMDA1YTk4DQoN
CihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjQyXSAgIGdmbjogMDAwMDVhOTkgIG1mbjogMDAw
MDVhOTkNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NDJdICAgZ2ZuOiAwMDAwNWE5YSAg
bWZuOiAwMDAwNWE5YQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo0Ml0gICBnZm46IDAw
MDA1YTliICBtZm46IDAwMDA1YTliDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjQyXSAg
IGdmbjogMDAwMDVhOWMgIG1mbjogMDAwMDVhOWMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6
MzM6NDJdICAgZ2ZuOiAwMDAwNWE5ZCAgbWZuOiAwMDAwNWE5ZA0KDQooWEVOKSBbMjAxMi0w
OC0zMSAyMTozMzo0Ml0gICBnZm46IDAwMDA1YTllICBtZm46IDAwMDA1YTllDQoNCihYRU4p
IFsyMDEyLTA4LTMxIDIxOjMzOjQyXSAgIGdmbjogMDAwMDVhOWYgIG1mbjogMDAwMDVhOWYN
Cg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NDJdICAgZ2ZuOiAwMDAwNWFhMCAgbWZuOiAw
MDAwNWFhMA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo0Ml0gICBnZm46IDAwMDA1YWEx
ICBtZm46IDAwMDA1YWExDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjQyXSAgIGdmbjog
MDAwMDVhYTIgIG1mbjogMDAwMDVhYTINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NDJd
ICAgZ2ZuOiAwMDAwNWFhMyAgbWZuOiAwMDAwNWFhMw0KDQooWEVOKSBbMjAxMi0wOC0zMSAy
MTozMzo0Ml0gICBnZm46IDAwMDA1YWE0ICBtZm46IDAwMDA1YWE0DQoNCihYRU4pIFsyMDEy
LTA4LTMxIDIxOjMzOjQyXSAgIGdmbjogMDAwMDVhYTUgIG1mbjogMDAwMDVhYTUNCg0KKFhF
TikgWzIwMTItMDgtMzEgMjE6MzM6NDJdICAgZ2ZuOiAwMDAwNWFhNiAgbWZuOiAwMDAwNWFh
Ng0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo0Ml0gICBnZm46IDAwMDA1YWE3ICBtZm46
IDAwMDA1YWE3DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjQyXSAgIGdmbjogMDAwMDVh
YTggIG1mbjogMDAwMDVhYTgNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NDJdICAgZ2Zu
OiAwMDAwNWFhOSAgbWZuOiAwMDAwNWFhOQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo0
Ml0gICBnZm46IDAwMDA1YWFhICBtZm46IDAwMDA1YWFhDQoNCihYRU4pIFsyMDEyLTA4LTMx
IDIxOjMzOjQyXSAgIGdmbjogMDAwMDVhYWIgIG1mbjogMDAwMDVhYWINCg0KKFhFTikgWzIw
MTItMDgtMzEgMjE6MzM6NDJdICAgZ2ZuOiAwMDAwNWFhYyAgbWZuOiAwMDAwNWFhYw0KDQoo
WEVOKSBbMjAxMi0wOC0zMSAyMTozMzo0Ml0gICBnZm46IDAwMDA1YWFkICBtZm46IDAwMDA1
YWFkDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjQyXSAgIGdmbjogMDAwMDVhYWUgIG1m
bjogMDAwMDVhYWUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NDJdICAgZ2ZuOiAwMDAw
NWFhZiAgbWZuOiAwMDAwNWFhZg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo0Ml0gICBn
Zm46IDAwMDA1YWIwICBtZm46IDAwMDA1YWIwDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMz
OjQyXSAgIGdmbjogMDAwMDVhYjEgIG1mbjogMDAwMDVhYjENCg0KKFhFTikgWzIwMTItMDgt
MzEgMjE6MzM6NDJdICAgZ2ZuOiAwMDAwNWFiMiAgbWZuOiAwMDAwNWFiMg0KDQooWEVOKSBb
MjAxMi0wOC0zMSAyMTozMzo0Ml0gICBnZm46IDAwMDA1YWIzICBtZm46IDAwMDA1YWIzDQoN
CihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjQyXSAgIGdmbjogMDAwMDVhYjQgIG1mbjogMDAw
MDVhYjQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NDJdICAgZ2ZuOiAwMDAwNWFiNSAg
bWZuOiAwMDAwNWFiNQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo0Ml0gICBnZm46IDAw
MDA1YWI2ICBtZm46IDAwMDA1YWI2DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjQyXSAg
IGdmbjogMDAwMDVhYjcgIG1mbjogMDAwMDVhYjcNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6
MzM6NDJdICAgZ2ZuOiAwMDAwNWFiOCAgbWZuOiAwMDAwNWFiOA0KDQooWEVOKSBbMjAxMi0w
OC0zMSAyMTozMzo0Ml0gICBnZm46IDAwMDA1YWI5ICBtZm46IDAwMDA1YWI5DQoNCihYRU4p
IFsyMDEyLTA4LTMxIDIxOjMzOjQyXSAgIGdmbjogMDAwMDVhYmEgIG1mbjogMDAwMDVhYmEN
Cg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NDJdICAgZ2ZuOiAwMDAwNWFiYiAgbWZuOiAw
MDAwNWFiYg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo0Ml0gICBnZm46IDAwMDA1YWJj
ICBtZm46IDAwMDA1YWJjDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjQyXSAgIGdmbjog
MDAwMDVhYmQgIG1mbjogMDAwMDVhYmQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NDJd
ICAgZ2ZuOiAwMDAwNWFiZSAgbWZuOiAwMDAwNWFiZQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAy
MTozMzo0Ml0gICBnZm46IDAwMDA1YWJmICBtZm46IDAwMDA1YWJmDQoNCihYRU4pIFsyMDEy
LTA4LTMxIDIxOjMzOjQyXSAgIGdmbjogMDAwMDVhYzAgIG1mbjogMDAwMDVhYzANCg0KKFhF
TikgWzIwMTItMDgtMzEgMjE6MzM6NDJdICAgZ2ZuOiAwMDAwNWFjMSAgbWZuOiAwMDAwNWFj
MQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo0Ml0gICBnZm46IDAwMDA1YWMyICBtZm46
IDAwMDA1YWMyDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjQyXSAgIGdmbjogMDAwMDVh
YzMgIG1mbjogMDAwMDVhYzMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NDJdICAgZ2Zu
OiAwMDAwNWFjNCAgbWZuOiAwMDAwNWFjNA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo0
Ml0gICBnZm46IDAwMDA1YWM1ICBtZm46IDAwMDA1YWM1DQoNCihYRU4pIFsyMDEyLTA4LTMx
IDIxOjMzOjQzXSAgIGdmbjogMDAwMDVhYzYgIG1mbjogMDAwMDVhYzYNCg0KKFhFTikgWzIw
MTItMDgtMzEgMjE6MzM6NDNdICAgZ2ZuOiAwMDAwNWFjNyAgbWZuOiAwMDAwNWFjNw0KDQoo
WEVOKSBbMjAxMi0wOC0zMSAyMTozMzo0M10gICBnZm46IDAwMDA1YWM4ICBtZm46IDAwMDA1
YWM4DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjQzXSAgIGdmbjogMDAwMDVhYzkgIG1m
bjogMDAwMDVhYzkNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NDNdICAgZ2ZuOiAwMDAw
NWFjYSAgbWZuOiAwMDAwNWFjYQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo0M10gICBn
Zm46IDAwMDA1YWNiICBtZm46IDAwMDA1YWNiDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMz
OjQzXSAgIGdmbjogMDAwMDVhY2MgIG1mbjogMDAwMDVhY2MNCg0KKFhFTikgWzIwMTItMDgt
MzEgMjE6MzM6NDNdICAgZ2ZuOiAwMDAwNWFjZCAgbWZuOiAwMDAwNWFjZA0KDQooWEVOKSBb
MjAxMi0wOC0zMSAyMTozMzo0M10gICBnZm46IDAwMDA1YWNlICBtZm46IDAwMDA1YWNlDQoN
CihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjQzXSAgIGdmbjogMDAwMDVhY2YgIG1mbjogMDAw
MDVhY2YNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NDNdICAgZ2ZuOiAwMDAwNWFkMCAg
bWZuOiAwMDAwNWFkMA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo0M10gICBnZm46IDAw
MDA1YWQxICBtZm46IDAwMDA1YWQxDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjQzXSAg
IGdmbjogMDAwMDVhZDIgIG1mbjogMDAwMDVhZDINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6
MzM6NDNdICAgZ2ZuOiAwMDAwNWFkMyAgbWZuOiAwMDAwNWFkMw0KDQooWEVOKSBbMjAxMi0w
OC0zMSAyMTozMzo0M10gICBnZm46IDAwMDA1YWQ0ICBtZm46IDAwMDA1YWQ0DQoNCihYRU4p
IFsyMDEyLTA4LTMxIDIxOjMzOjQzXSAgIGdmbjogMDAwMDVhZDUgIG1mbjogMDAwMDVhZDUN
Cg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NDNdICAgZ2ZuOiAwMDAwNWFkNiAgbWZuOiAw
MDAwNWFkNg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo0M10gICBnZm46IDAwMDA1YWQ3
ICBtZm46IDAwMDA1YWQ3DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjQzXSAgIGdmbjog
MDAwMDVhZDggIG1mbjogMDAwMDVhZDgNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NDNd
ICAgZ2ZuOiAwMDAwNWFkOSAgbWZuOiAwMDAwNWFkOQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAy
MTozMzo0M10gICBnZm46IDAwMDA1YWRhICBtZm46IDAwMDA1YWRhDQoNCihYRU4pIFsyMDEy
LTA4LTMxIDIxOjMzOjQzXSAgIGdmbjogMDAwMDVhZGIgIG1mbjogMDAwMDVhZGINCg0KKFhF
TikgWzIwMTItMDgtMzEgMjE6MzM6NDNdICAgZ2ZuOiAwMDAwNWFkYyAgbWZuOiAwMDAwNWFk
Yw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo0M10gICBnZm46IDAwMDA1YWRkICBtZm46
IDAwMDA1YWRkDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjQzXSAgIGdmbjogMDAwMDVh
ZGUgIG1mbjogMDAwMDVhZGUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NDNdICAgZ2Zu
OiAwMDAwNWFkZiAgbWZuOiAwMDAwNWFkZg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo0
M10gICBnZm46IDAwMDA1YWUwICBtZm46IDAwMDA1YWUwDQoNCihYRU4pIFsyMDEyLTA4LTMx
IDIxOjMzOjQzXSAgIGdmbjogMDAwMDVhZTEgIG1mbjogMDAwMDVhZTENCg0KKFhFTikgWzIw
MTItMDgtMzEgMjE6MzM6NDNdICAgZ2ZuOiAwMDAwNWFlMiAgbWZuOiAwMDAwNWFlMg0KDQoo
WEVOKSBbMjAxMi0wOC0zMSAyMTozMzo0M10gICBnZm46IDAwMDA1YWUzICBtZm46IDAwMDA1
YWUzDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjQzXSAgIGdmbjogMDAwMDVhZTQgIG1m
bjogMDAwMDVhZTQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NDNdICAgZ2ZuOiAwMDAw
NWFlNSAgbWZuOiAwMDAwNWFlNQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo0M10gICBn
Zm46IDAwMDA1YWU2ICBtZm46IDAwMDA1YWU2DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMz
OjQzXSAgIGdmbjogMDAwMDVhZTcgIG1mbjogMDAwMDVhZTcNCg0KKFhFTikgWzIwMTItMDgt
MzEgMjE6MzM6NDNdICAgZ2ZuOiAwMDAwNWFlOCAgbWZuOiAwMDAwNWFlOA0KDQooWEVOKSBb
MjAxMi0wOC0zMSAyMTozMzo0M10gICBnZm46IDAwMDA1YWU5ICBtZm46IDAwMDA1YWU5DQoN
CihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjQzXSAgIGdmbjogMDAwMDVhZWEgIG1mbjogMDAw
MDVhZWENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NDNdICAgZ2ZuOiAwMDAwNWFlYiAg
bWZuOiAwMDAwNWFlYg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo0M10gICBnZm46IDAw
MDA1YWVjICBtZm46IDAwMDA1YWVjDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjQzXSAg
IGdmbjogMDAwMDVhZWQgIG1mbjogMDAwMDVhZWQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6
MzM6NDNdICAgZ2ZuOiAwMDAwNWFlZSAgbWZuOiAwMDAwNWFlZQ0KDQooWEVOKSBbMjAxMi0w
OC0zMSAyMTozMzo0M10gICBnZm46IDAwMDA1YWVmICBtZm46IDAwMDA1YWVmDQoNCihYRU4p
IFsyMDEyLTA4LTMxIDIxOjMzOjQzXSAgIGdmbjogMDAwMDVhZjAgIG1mbjogMDAwMDVhZjAN
Cg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NDNdICAgZ2ZuOiAwMDAwNWFmMSAgbWZuOiAw
MDAwNWFmMQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo0M10gICBnZm46IDAwMDA1YWYy
ICBtZm46IDAwMDA1YWYyDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjQzXSAgIGdmbjog
MDAwMDVhZjMgIG1mbjogMDAwMDVhZjMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NDNd
ICAgZ2ZuOiAwMDAwNWFmNCAgbWZuOiAwMDAwNWFmNA0KDQooWEVOKSBbMjAxMi0wOC0zMSAy
MTozMzo0M10gICBnZm46IDAwMDA1YWY1ICBtZm46IDAwMDA1YWY1DQoNCihYRU4pIFsyMDEy
LTA4LTMxIDIxOjMzOjQzXSAgIGdmbjogMDAwMDVhZjYgIG1mbjogMDAwMDVhZjYNCg0KKFhF
TikgWzIwMTItMDgtMzEgMjE6MzM6NDNdICAgZ2ZuOiAwMDAwNWFmNyAgbWZuOiAwMDAwNWFm
Nw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo0M10gICBnZm46IDAwMDA1YWY4ICBtZm46
IDAwMDA1YWY4DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjQzXSAgIGdmbjogMDAwMDVh
ZjkgIG1mbjogMDAwMDVhZjkNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NDNdICAgZ2Zu
OiAwMDAwNWFmYSAgbWZuOiAwMDAwNWFmYQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo0
M10gICBnZm46IDAwMDA1YWZiICBtZm46IDAwMDA1YWZiDQoNCihYRU4pIFsyMDEyLTA4LTMx
IDIxOjMzOjQzXSAgIGdmbjogMDAwMDVhZmMgIG1mbjogMDAwMDVhZmMNCg0KKFhFTikgWzIw
MTItMDgtMzEgMjE6MzM6NDNdICAgZ2ZuOiAwMDAwNWFmZCAgbWZuOiAwMDAwNWFmZA0KDQoo
WEVOKSBbMjAxMi0wOC0zMSAyMTozMzo0M10gICBnZm46IDAwMDA1YWZlICBtZm46IDAwMDA1
YWZlDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjQzXSAgIGdmbjogMDAwMDVhZmYgIG1m
bjogMDAwMDVhZmYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NDNdICAgZ2ZuOiAwMDAw
NWIwMCAgbWZuOiAwMDAwNWIwMA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo0M10gICBn
Zm46IDAwMDA1YjAxICBtZm46IDAwMDA1YjAxDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMz
OjQzXSAgIGdmbjogMDAwMDViMDIgIG1mbjogMDAwMDViMDINCg0KKFhFTikgWzIwMTItMDgt
MzEgMjE6MzM6NDNdICAgZ2ZuOiAwMDAwNWIwMyAgbWZuOiAwMDAwNWIwMw0KDQooWEVOKSBb
MjAxMi0wOC0zMSAyMTozMzo0M10gICBnZm46IDAwMDA1YjA0ICBtZm46IDAwMDA1YjA0DQoN
CihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjQzXSAgIGdmbjogMDAwMDViMDUgIG1mbjogMDAw
MDViMDUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NDRdICAgZ2ZuOiAwMDAwNWIwNiAg
bWZuOiAwMDAwNWIwNg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo0NF0gICBnZm46IDAw
MDA1YjA3ICBtZm46IDAwMDA1YjA3DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjQ0XSAg
IGdmbjogMDAwMDViMDggIG1mbjogMDAwMDViMDgNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6
MzM6NDRdICAgZ2ZuOiAwMDAwNWIwOSAgbWZuOiAwMDAwNWIwOQ0KDQooWEVOKSBbMjAxMi0w
OC0zMSAyMTozMzo0NF0gICBnZm46IDAwMDA1YjBhICBtZm46IDAwMDA1YjBhDQoNCihYRU4p
IFsyMDEyLTA4LTMxIDIxOjMzOjQ0XSAgIGdmbjogMDAwMDViMGIgIG1mbjogMDAwMDViMGIN
Cg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NDRdICAgZ2ZuOiAwMDAwNWIwYyAgbWZuOiAw
MDAwNWIwYw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo0NF0gICBnZm46IDAwMDA1YjBk
ICBtZm46IDAwMDA1YjBkDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjQ0XSAgIGdmbjog
MDAwMDViMGUgIG1mbjogMDAwMDViMGUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NDRd
ICAgZ2ZuOiAwMDAwNWIwZiAgbWZuOiAwMDAwNWIwZg0KDQooWEVOKSBbMjAxMi0wOC0zMSAy
MTozMzo0NF0gICBnZm46IDAwMDA1YjEwICBtZm46IDAwMDA1YjEwDQoNCihYRU4pIFsyMDEy
LTA4LTMxIDIxOjMzOjQ0XSAgIGdmbjogMDAwMDViMTEgIG1mbjogMDAwMDViMTENCg0KKFhF
TikgWzIwMTItMDgtMzEgMjE6MzM6NDRdICAgZ2ZuOiAwMDAwNWIxMiAgbWZuOiAwMDAwNWIx
Mg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo0NF0gICBnZm46IDAwMDA1YjEzICBtZm46
IDAwMDA1YjEzDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjQ0XSAgIGdmbjogMDAwMDVi
MTQgIG1mbjogMDAwMDViMTQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NDRdICAgZ2Zu
OiAwMDAwNWIxNSAgbWZuOiAwMDAwNWIxNQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo0
NF0gICBnZm46IDAwMDA1YjE2ICBtZm46IDAwMDA1YjE2DQoNCihYRU4pIFsyMDEyLTA4LTMx
IDIxOjMzOjQ0XSAgIGdmbjogMDAwMDViMTcgIG1mbjogMDAwMDViMTcNCg0KKFhFTikgWzIw
MTItMDgtMzEgMjE6MzM6NDRdICAgZ2ZuOiAwMDAwNWIxOCAgbWZuOiAwMDAwNWIxOA0KDQoo
WEVOKSBbMjAxMi0wOC0zMSAyMTozMzo0NF0gICBnZm46IDAwMDA1YjE5ICBtZm46IDAwMDA1
YjE5DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjQ0XSAgIGdmbjogMDAwMDViMWEgIG1m
bjogMDAwMDViMWENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NDRdICAgZ2ZuOiAwMDAw
NWIxYiAgbWZuOiAwMDAwNWIxYg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo0NF0gICBn
Zm46IDAwMDA1YjFjICBtZm46IDAwMDA1YjFjDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMz
OjQ0XSAgIGdmbjogMDAwMDViMWQgIG1mbjogMDAwMDViMWQNCg0KKFhFTikgWzIwMTItMDgt
MzEgMjE6MzM6NDRdICAgZ2ZuOiAwMDAwNWIxZSAgbWZuOiAwMDAwNWIxZQ0KDQooWEVOKSBb
MjAxMi0wOC0zMSAyMTozMzo0NF0gICBnZm46IDAwMDA1YjFmICBtZm46IDAwMDA1YjFmDQoN
CihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjQ0XSAgIGdmbjogMDAwMDViMjAgIG1mbjogMDAw
MDViMjANCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NDRdICAgZ2ZuOiAwMDAwNWIyMSAg
bWZuOiAwMDAwNWIyMQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo0NF0gICBnZm46IDAw
MDA1YjIyICBtZm46IDAwMDA1YjIyDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjQ0XSAg
IGdmbjogMDAwMDViMjMgIG1mbjogMDAwMDViMjMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6
MzM6NDRdICAgZ2ZuOiAwMDAwNWIyNCAgbWZuOiAwMDAwNWIyNA0KDQooWEVOKSBbMjAxMi0w
OC0zMSAyMTozMzo0NF0gICBnZm46IDAwMDA1YjI1ICBtZm46IDAwMDA1YjI1DQoNCihYRU4p
IFsyMDEyLTA4LTMxIDIxOjMzOjQ0XSAgIGdmbjogMDAwMDViMjYgIG1mbjogMDAwMDViMjYN
Cg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NDRdICAgZ2ZuOiAwMDAwNWIyNyAgbWZuOiAw
MDAwNWIyNw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo0NF0gICBnZm46IDAwMDA1YjI4
ICBtZm46IDAwMDA1YjI4DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjQ0XSAgIGdmbjog
MDAwMDViMjkgIG1mbjogMDAwMDViMjkNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NDRd
ICAgZ2ZuOiAwMDAwNWIyYSAgbWZuOiAwMDAwNWIyYQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAy
MTozMzo0NF0gICBnZm46IDAwMDA1YjJiICBtZm46IDAwMDA1YjJiDQoNCihYRU4pIFsyMDEy
LTA4LTMxIDIxOjMzOjQ0XSAgIGdmbjogMDAwMDViMmMgIG1mbjogMDAwMDViMmMNCg0KKFhF
TikgWzIwMTItMDgtMzEgMjE6MzM6NDRdICAgZ2ZuOiAwMDAwNWIyZCAgbWZuOiAwMDAwNWIy
ZA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo0NF0gICBnZm46IDAwMDA1YjJlICBtZm46
IDAwMDA1YjJlDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjQ0XSAgIGdmbjogMDAwMDVi
MmYgIG1mbjogMDAwMDViMmYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NDRdICAgZ2Zu
OiAwMDAwNWIzMCAgbWZuOiAwMDAwNWIzMA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo0
NF0gICBnZm46IDAwMDA1YjMxICBtZm46IDAwMDA1YjMxDQoNCihYRU4pIFsyMDEyLTA4LTMx
IDIxOjMzOjQ0XSAgIGdmbjogMDAwMDViMzIgIG1mbjogMDAwMDViMzINCg0KKFhFTikgWzIw
MTItMDgtMzEgMjE6MzM6NDRdICAgZ2ZuOiAwMDAwNWIzMyAgbWZuOiAwMDAwNWIzMw0KDQoo
WEVOKSBbMjAxMi0wOC0zMSAyMTozMzo0NF0gICBnZm46IDAwMDA1YjM0ICBtZm46IDAwMDA1
YjM0DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjQ0XSAgIGdmbjogMDAwMDViMzUgIG1m
bjogMDAwMDViMzUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NDRdICAgZ2ZuOiAwMDAw
NWIzNiAgbWZuOiAwMDAwNWIzNg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo0NF0gICBn
Zm46IDAwMDA1YjM3ICBtZm46IDAwMDA1YjM3DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMz
OjQ0XSAgIGdmbjogMDAwMDViMzggIG1mbjogMDAwMDViMzgNCg0KKFhFTikgWzIwMTItMDgt
MzEgMjE6MzM6NDRdICAgZ2ZuOiAwMDAwNWIzOSAgbWZuOiAwMDAwNWIzOQ0KDQooWEVOKSBb
MjAxMi0wOC0zMSAyMTozMzo0NF0gICBnZm46IDAwMDA1YjNhICBtZm46IDAwMDA1YjNhDQoN
CihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjQ0XSAgIGdmbjogMDAwMDViM2IgIG1mbjogMDAw
MDViM2INCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NDRdICAgZ2ZuOiAwMDAwNWIzYyAg
bWZuOiAwMDAwNWIzYw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo0NF0gICBnZm46IDAw
MDA1YjNkICBtZm46IDAwMDA1YjNkDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjQ0XSAg
IGdmbjogMDAwMDViM2UgIG1mbjogMDAwMDViM2UNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6
MzM6NDRdICAgZ2ZuOiAwMDAwNWIzZiAgbWZuOiAwMDAwNWIzZg0KDQooWEVOKSBbMjAxMi0w
OC0zMSAyMTozMzo0NF0gICBnZm46IDAwMDA1YjQwICBtZm46IDAwMDA1YjQwDQoNCihYRU4p
IFsyMDEyLTA4LTMxIDIxOjMzOjQ0XSAgIGdmbjogMDAwMDViNDEgIG1mbjogMDAwMDViNDEN
Cg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NDRdICAgZ2ZuOiAwMDAwNWI0MiAgbWZuOiAw
MDAwNWI0Mg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo0NF0gICBnZm46IDAwMDA1YjQz
ICBtZm46IDAwMDA1YjQzDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjQ0XSAgIGdmbjog
MDAwMDViNDQgIG1mbjogMDAwMDViNDQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NDRd
ICAgZ2ZuOiAwMDAwNWI0NSAgbWZuOiAwMDAwNWI0NQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAy
MTozMzo0NV0gICBnZm46IDAwMDA1YjQ2ICBtZm46IDAwMDA1YjQ2DQoNCihYRU4pIFsyMDEy
LTA4LTMxIDIxOjMzOjQ1XSAgIGdmbjogMDAwMDViNDcgIG1mbjogMDAwMDViNDcNCg0KKFhF
TikgWzIwMTItMDgtMzEgMjE6MzM6NDVdICAgZ2ZuOiAwMDAwNWI0OCAgbWZuOiAwMDAwNWI0
OA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo0NV0gICBnZm46IDAwMDA1YjQ5ICBtZm46
IDAwMDA1YjQ5DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjQ1XSAgIGdmbjogMDAwMDVi
NGEgIG1mbjogMDAwMDViNGENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NDVdICAgZ2Zu
OiAwMDAwNWI0YiAgbWZuOiAwMDAwNWI0Yg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo0
NV0gICBnZm46IDAwMDA1YjRjICBtZm46IDAwMDA1YjRjDQoNCihYRU4pIFsyMDEyLTA4LTMx
IDIxOjMzOjQ1XSAgIGdmbjogMDAwMDViNGQgIG1mbjogMDAwMDViNGQNCg0KKFhFTikgWzIw
MTItMDgtMzEgMjE6MzM6NDVdICAgZ2ZuOiAwMDAwNWI0ZSAgbWZuOiAwMDAwNWI0ZQ0KDQoo
WEVOKSBbMjAxMi0wOC0zMSAyMTozMzo0NV0gICBnZm46IDAwMDA1YjRmICBtZm46IDAwMDA1
YjRmDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjQ1XSAgIGdmbjogMDAwMDViNTAgIG1m
bjogMDAwMDViNTANCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NDVdICAgZ2ZuOiAwMDAw
NWI1MSAgbWZuOiAwMDAwNWI1MQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo0NV0gICBn
Zm46IDAwMDA1YjUyICBtZm46IDAwMDA1YjUyDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMz
OjQ1XSAgIGdmbjogMDAwMDViNTMgIG1mbjogMDAwMDViNTMNCg0KKFhFTikgWzIwMTItMDgt
MzEgMjE6MzM6NDVdICAgZ2ZuOiAwMDAwNWI1NCAgbWZuOiAwMDAwNWI1NA0KDQooWEVOKSBb
MjAxMi0wOC0zMSAyMTozMzo0NV0gICBnZm46IDAwMDA1YjU1ICBtZm46IDAwMDA1YjU1DQoN
CihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjQ1XSAgIGdmbjogMDAwMDViNTYgIG1mbjogMDAw
MDViNTYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NDVdICAgZ2ZuOiAwMDAwNWI1NyAg
bWZuOiAwMDAwNWI1Nw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo0NV0gICBnZm46IDAw
MDA1YjU4ICBtZm46IDAwMDA1YjU4DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjQ1XSAg
IGdmbjogMDAwMDViNTkgIG1mbjogMDAwMDViNTkNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6
MzM6NDVdICAgZ2ZuOiAwMDAwNWI1YSAgbWZuOiAwMDAwNWI1YQ0KDQooWEVOKSBbMjAxMi0w
OC0zMSAyMTozMzo0NV0gICBnZm46IDAwMDA1YjViICBtZm46IDAwMDA1YjViDQoNCihYRU4p
IFsyMDEyLTA4LTMxIDIxOjMzOjQ1XSAgIGdmbjogMDAwMDViNWMgIG1mbjogMDAwMDViNWMN
Cg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NDVdICAgZ2ZuOiAwMDAwNWI1ZCAgbWZuOiAw
MDAwNWI1ZA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo0NV0gICBnZm46IDAwMDA1YjVl
ICBtZm46IDAwMDA1YjVlDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjQ1XSAgIGdmbjog
MDAwMDViNWYgIG1mbjogMDAwMDViNWYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NDVd
ICAgZ2ZuOiAwMDAwNWI2MCAgbWZuOiAwMDAwNWI2MA0KDQooWEVOKSBbMjAxMi0wOC0zMSAy
MTozMzo0NV0gICBnZm46IDAwMDA1YjYxICBtZm46IDAwMDA1YjYxDQoNCihYRU4pIFsyMDEy
LTA4LTMxIDIxOjMzOjQ1XSAgIGdmbjogMDAwMDViNjIgIG1mbjogMDAwMDViNjINCg0KKFhF
TikgWzIwMTItMDgtMzEgMjE6MzM6NDVdICAgZ2ZuOiAwMDAwNWI2MyAgbWZuOiAwMDAwNWI2
Mw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo0NV0gICBnZm46IDAwMDA1YjY0ICBtZm46
IDAwMDA1YjY0DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjQ1XSAgIGdmbjogMDAwMDVi
NjUgIG1mbjogMDAwMDViNjUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NDVdICAgZ2Zu
OiAwMDAwNWI2NiAgbWZuOiAwMDAwNWI2Ng0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo0
NV0gICBnZm46IDAwMDA1YjY3ICBtZm46IDAwMDA1YjY3DQoNCihYRU4pIFsyMDEyLTA4LTMx
IDIxOjMzOjQ1XSAgIGdmbjogMDAwMDViNjggIG1mbjogMDAwMDViNjgNCg0KKFhFTikgWzIw
MTItMDgtMzEgMjE6MzM6NDVdICAgZ2ZuOiAwMDAwNWI2OSAgbWZuOiAwMDAwNWI2OQ0KDQoo
WEVOKSBbMjAxMi0wOC0zMSAyMTozMzo0NV0gICBnZm46IDAwMDA1YjZhICBtZm46IDAwMDA1
YjZhDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjQ1XSAgIGdmbjogMDAwMDViNmIgIG1m
bjogMDAwMDViNmINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NDVdICAgZ2ZuOiAwMDAw
NWI2YyAgbWZuOiAwMDAwNWI2Yw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo0NV0gICBn
Zm46IDAwMDA1YjZkICBtZm46IDAwMDA1YjZkDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMz
OjQ1XSAgIGdmbjogMDAwMDViNmUgIG1mbjogMDAwMDViNmUNCg0KKFhFTikgWzIwMTItMDgt
MzEgMjE6MzM6NDVdICAgZ2ZuOiAwMDAwNWI2ZiAgbWZuOiAwMDAwNWI2Zg0KDQooWEVOKSBb
MjAxMi0wOC0zMSAyMTozMzo0NV0gICBnZm46IDAwMDA1YjcwICBtZm46IDAwMDA1YjcwDQoN
CihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjQ1XSAgIGdmbjogMDAwMDViNzEgIG1mbjogMDAw
MDViNzENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NDVdICAgZ2ZuOiAwMDAwNWI3MiAg
bWZuOiAwMDAwNWI3Mg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo0NV0gICBnZm46IDAw
MDA1YjczICBtZm46IDAwMDA1YjczDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjQ1XSAg
IGdmbjogMDAwMDViNzQgIG1mbjogMDAwMDViNzQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6
MzM6NDVdICAgZ2ZuOiAwMDAwNWI3NSAgbWZuOiAwMDAwNWI3NQ0KDQooWEVOKSBbMjAxMi0w
OC0zMSAyMTozMzo0NV0gICBnZm46IDAwMDA1Yjc2ICBtZm46IDAwMDA1Yjc2DQoNCihYRU4p
IFsyMDEyLTA4LTMxIDIxOjMzOjQ1XSAgIGdmbjogMDAwMDViNzcgIG1mbjogMDAwMDViNzcN
Cg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NDVdICAgZ2ZuOiAwMDAwNWI3OCAgbWZuOiAw
MDAwNWI3OA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo0NV0gICBnZm46IDAwMDA1Yjc5
ICBtZm46IDAwMDA1Yjc5DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjQ1XSAgIGdmbjog
MDAwMDViN2EgIG1mbjogMDAwMDViN2ENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NDVd
ICAgZ2ZuOiAwMDAwNWI3YiAgbWZuOiAwMDAwNWI3Yg0KDQooWEVOKSBbMjAxMi0wOC0zMSAy
MTozMzo0NV0gICBnZm46IDAwMDA1YjdjICBtZm46IDAwMDA1YjdjDQoNCihYRU4pIFsyMDEy
LTA4LTMxIDIxOjMzOjQ1XSAgIGdmbjogMDAwMDViN2QgIG1mbjogMDAwMDViN2QNCg0KKFhF
TikgWzIwMTItMDgtMzEgMjE6MzM6NDVdICAgZ2ZuOiAwMDAwNWI3ZSAgbWZuOiAwMDAwNWI3
ZQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo0NV0gICBnZm46IDAwMDA1YjdmICBtZm46
IDAwMDA1YjdmDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjQ1XSAgIGdmbjogMDAwMDVi
ODAgIG1mbjogMDAwMDViODANCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NDVdICAgZ2Zu
OiAwMDAwNWI4MSAgbWZuOiAwMDAwNWI4MQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo0
NV0gICBnZm46IDAwMDA1YjgyICBtZm46IDAwMDA1YjgyDQoNCihYRU4pIFsyMDEyLTA4LTMx
IDIxOjMzOjQ1XSAgIGdmbjogMDAwMDViODMgIG1mbjogMDAwMDViODMNCg0KKFhFTikgWzIw
MTItMDgtMzEgMjE6MzM6NDVdICAgZ2ZuOiAwMDAwNWI4NCAgbWZuOiAwMDAwNWI4NA0KDQoo
WEVOKSBbMjAxMi0wOC0zMSAyMTozMzo0NV0gICBnZm46IDAwMDA1Yjg1ICBtZm46IDAwMDA1
Yjg1DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjQ2XSAgIGdmbjogMDAwMDViODYgIG1m
bjogMDAwMDViODYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NDZdICAgZ2ZuOiAwMDAw
NWI4NyAgbWZuOiAwMDAwNWI4Nw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo0Nl0gICBn
Zm46IDAwMDA1Yjg4ICBtZm46IDAwMDA1Yjg4DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMz
OjQ2XSAgIGdmbjogMDAwMDViODkgIG1mbjogMDAwMDViODkNCg0KKFhFTikgWzIwMTItMDgt
MzEgMjE6MzM6NDZdICAgZ2ZuOiAwMDAwNWI4YSAgbWZuOiAwMDAwNWI4YQ0KDQooWEVOKSBb
MjAxMi0wOC0zMSAyMTozMzo0Nl0gICBnZm46IDAwMDA1YjhiICBtZm46IDAwMDA1YjhiDQoN
CihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjQ2XSAgIGdmbjogMDAwMDViOGMgIG1mbjogMDAw
MDViOGMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NDZdICAgZ2ZuOiAwMDAwNWI4ZCAg
bWZuOiAwMDAwNWI4ZA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo0Nl0gICBnZm46IDAw
MDA1YjhlICBtZm46IDAwMDA1YjhlDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjQ2XSAg
IGdmbjogMDAwMDViOGYgIG1mbjogMDAwMDViOGYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6
MzM6NDZdICAgZ2ZuOiAwMDAwNWI5MCAgbWZuOiAwMDAwNWI5MA0KDQooWEVOKSBbMjAxMi0w
OC0zMSAyMTozMzo0Nl0gICBnZm46IDAwMDA1YjkxICBtZm46IDAwMDA1YjkxDQoNCihYRU4p
IFsyMDEyLTA4LTMxIDIxOjMzOjQ2XSAgIGdmbjogMDAwMDViOTIgIG1mbjogMDAwMDViOTIN
Cg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NDZdICAgZ2ZuOiAwMDAwNWI5MyAgbWZuOiAw
MDAwNWI5Mw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo0Nl0gICBnZm46IDAwMDA1Yjk0
ICBtZm46IDAwMDA1Yjk0DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjQ2XSAgIGdmbjog
MDAwMDViOTUgIG1mbjogMDAwMDViOTUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NDZd
ICAgZ2ZuOiAwMDAwNWI5NiAgbWZuOiAwMDAwNWI5Ng0KDQooWEVOKSBbMjAxMi0wOC0zMSAy
MTozMzo0Nl0gICBnZm46IDAwMDA1Yjk3ICBtZm46IDAwMDA1Yjk3DQoNCihYRU4pIFsyMDEy
LTA4LTMxIDIxOjMzOjQ2XSAgIGdmbjogMDAwMDViOTggIG1mbjogMDAwMDViOTgNCg0KKFhF
TikgWzIwMTItMDgtMzEgMjE6MzM6NDZdICAgZ2ZuOiAwMDAwNWI5OSAgbWZuOiAwMDAwNWI5
OQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo0Nl0gICBnZm46IDAwMDA1YjlhICBtZm46
IDAwMDA1YjlhDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjQ2XSAgIGdmbjogMDAwMDVi
OWIgIG1mbjogMDAwMDViOWINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NDZdICAgZ2Zu
OiAwMDAwNWI5YyAgbWZuOiAwMDAwNWI5Yw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo0
Nl0gICBnZm46IDAwMDA1YjlkICBtZm46IDAwMDA1YjlkDQoNCihYRU4pIFsyMDEyLTA4LTMx
IDIxOjMzOjQ2XSAgIGdmbjogMDAwMDViOWUgIG1mbjogMDAwMDViOWUNCg0KKFhFTikgWzIw
MTItMDgtMzEgMjE6MzM6NDZdICAgZ2ZuOiAwMDAwNWI5ZiAgbWZuOiAwMDAwNWI5Zg0KDQoo
WEVOKSBbMjAxMi0wOC0zMSAyMTozMzo0Nl0gICBnZm46IDAwMDA1YmEwICBtZm46IDAwMDA1
YmEwDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjQ2XSAgIGdmbjogMDAwMDViYTEgIG1m
bjogMDAwMDViYTENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NDZdICAgZ2ZuOiAwMDAw
NWJhMiAgbWZuOiAwMDAwNWJhMg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo0Nl0gICBn
Zm46IDAwMDA1YmEzICBtZm46IDAwMDA1YmEzDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMz
OjQ2XSAgIGdmbjogMDAwMDViYTQgIG1mbjogMDAwMDViYTQNCg0KKFhFTikgWzIwMTItMDgt
MzEgMjE6MzM6NDZdICAgZ2ZuOiAwMDAwNWJhNSAgbWZuOiAwMDAwNWJhNQ0KDQooWEVOKSBb
MjAxMi0wOC0zMSAyMTozMzo0Nl0gICBnZm46IDAwMDA1YmE2ICBtZm46IDAwMDA1YmE2DQoN
CihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjQ2XSAgIGdmbjogMDAwMDViYTcgIG1mbjogMDAw
MDViYTcNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NDZdICAgZ2ZuOiAwMDAwNWJhOCAg
bWZuOiAwMDAwNWJhOA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo0Nl0gICBnZm46IDAw
MDA1YmE5ICBtZm46IDAwMDA1YmE5DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjQ2XSAg
IGdmbjogMDAwMDViYWEgIG1mbjogMDAwMDViYWENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6
MzM6NDZdICAgZ2ZuOiAwMDAwNWJhYiAgbWZuOiAwMDAwNWJhYg0KDQooWEVOKSBbMjAxMi0w
OC0zMSAyMTozMzo0Nl0gICBnZm46IDAwMDA1YmFjICBtZm46IDAwMDA1YmFjDQoNCihYRU4p
IFsyMDEyLTA4LTMxIDIxOjMzOjQ2XSAgIGdmbjogMDAwMDViYWQgIG1mbjogMDAwMDViYWQN
Cg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NDZdICAgZ2ZuOiAwMDAwNWJhZSAgbWZuOiAw
MDAwNWJhZQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo0Nl0gICBnZm46IDAwMDA1YmFm
ICBtZm46IDAwMDA1YmFmDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjQ2XSAgIGdmbjog
MDAwMDViYjAgIG1mbjogMDAwMDViYjANCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NDZd
ICAgZ2ZuOiAwMDAwNWJiMSAgbWZuOiAwMDAwNWJiMQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAy
MTozMzo0Nl0gICBnZm46IDAwMDA1YmIyICBtZm46IDAwMDA1YmIyDQoNCihYRU4pIFsyMDEy
LTA4LTMxIDIxOjMzOjQ2XSAgIGdmbjogMDAwMDViYjMgIG1mbjogMDAwMDViYjMNCg0KKFhF
TikgWzIwMTItMDgtMzEgMjE6MzM6NDZdICAgZ2ZuOiAwMDAwNWJiNCAgbWZuOiAwMDAwNWJi
NA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo0Nl0gICBnZm46IDAwMDA1YmI1ICBtZm46
IDAwMDA1YmI1DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjQ2XSAgIGdmbjogMDAwMDVi
YjYgIG1mbjogMDAwMDViYjYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NDZdICAgZ2Zu
OiAwMDAwNWJiNyAgbWZuOiAwMDAwNWJiNw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo0
Nl0gICBnZm46IDAwMDA1YmI4ICBtZm46IDAwMDA1YmI4DQoNCihYRU4pIFsyMDEyLTA4LTMx
IDIxOjMzOjQ2XSAgIGdmbjogMDAwMDViYjkgIG1mbjogMDAwMDViYjkNCg0KKFhFTikgWzIw
MTItMDgtMzEgMjE6MzM6NDZdICAgZ2ZuOiAwMDAwNWJiYSAgbWZuOiAwMDAwNWJiYQ0KDQoo
WEVOKSBbMjAxMi0wOC0zMSAyMTozMzo0Nl0gICBnZm46IDAwMDA1YmJiICBtZm46IDAwMDA1
YmJiDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjQ2XSAgIGdmbjogMDAwMDViYmMgIG1m
bjogMDAwMDViYmMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NDZdICAgZ2ZuOiAwMDAw
NWJiZCAgbWZuOiAwMDAwNWJiZA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo0Nl0gICBn
Zm46IDAwMDA1YmJlICBtZm46IDAwMDA1YmJlDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMz
OjQ2XSAgIGdmbjogMDAwMDViYmYgIG1mbjogMDAwMDViYmYNCg0KKFhFTikgWzIwMTItMDgt
MzEgMjE6MzM6NDZdICAgZ2ZuOiAwMDAwNWJjMCAgbWZuOiAwMDAwNWJjMA0KDQooWEVOKSBb
MjAxMi0wOC0zMSAyMTozMzo0Nl0gICBnZm46IDAwMDA1YmMxICBtZm46IDAwMDA1YmMxDQoN
CihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjQ2XSAgIGdmbjogMDAwMDViYzIgIG1mbjogMDAw
MDViYzINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NDZdICAgZ2ZuOiAwMDAwNWJjMyAg
bWZuOiAwMDAwNWJjMw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo0Nl0gICBnZm46IDAw
MDA1YmM0ICBtZm46IDAwMDA1YmM0DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjQ2XSAg
IGdmbjogMDAwMDViYzUgIG1mbjogMDAwMDViYzUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6
MzM6NDddICAgZ2ZuOiAwMDAwNWJjNiAgbWZuOiAwMDAwNWJjNg0KDQooWEVOKSBbMjAxMi0w
OC0zMSAyMTozMzo0N10gICBnZm46IDAwMDA1YmM3ICBtZm46IDAwMDA1YmM3DQoNCihYRU4p
IFsyMDEyLTA4LTMxIDIxOjMzOjQ3XSAgIGdmbjogMDAwMDViYzggIG1mbjogMDAwMDViYzgN
Cg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NDddICAgZ2ZuOiAwMDAwNWJjOSAgbWZuOiAw
MDAwNWJjOQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo0N10gICBnZm46IDAwMDA1YmNh
ICBtZm46IDAwMDA1YmNhDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjQ3XSAgIGdmbjog
MDAwMDViY2IgIG1mbjogMDAwMDViY2INCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NDdd
ICAgZ2ZuOiAwMDAwNWJjYyAgbWZuOiAwMDAwNWJjYw0KDQooWEVOKSBbMjAxMi0wOC0zMSAy
MTozMzo0N10gICBnZm46IDAwMDA1YmNkICBtZm46IDAwMDA1YmNkDQoNCihYRU4pIFsyMDEy
LTA4LTMxIDIxOjMzOjQ3XSAgIGdmbjogMDAwMDViY2UgIG1mbjogMDAwMDViY2UNCg0KKFhF
TikgWzIwMTItMDgtMzEgMjE6MzM6NDddICAgZ2ZuOiAwMDAwNWJjZiAgbWZuOiAwMDAwNWJj
Zg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo0N10gICBnZm46IDAwMDA1YmQwICBtZm46
IDAwMDA1YmQwDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjQ3XSAgIGdmbjogMDAwMDVi
ZDEgIG1mbjogMDAwMDViZDENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NDddICAgZ2Zu
OiAwMDAwNWJkMiAgbWZuOiAwMDAwNWJkMg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo0
N10gICBnZm46IDAwMDA1YmQzICBtZm46IDAwMDA1YmQzDQoNCihYRU4pIFsyMDEyLTA4LTMx
IDIxOjMzOjQ3XSAgIGdmbjogMDAwMDViZDQgIG1mbjogMDAwMDViZDQNCg0KKFhFTikgWzIw
MTItMDgtMzEgMjE6MzM6NDddICAgZ2ZuOiAwMDAwNWJkNSAgbWZuOiAwMDAwNWJkNQ0KDQoo
WEVOKSBbMjAxMi0wOC0zMSAyMTozMzo0N10gICBnZm46IDAwMDA1YmQ2ICBtZm46IDAwMDA1
YmQ2DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjQ3XSAgIGdmbjogMDAwMDViZDcgIG1m
bjogMDAwMDViZDcNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NDddICAgZ2ZuOiAwMDAw
NWJkOCAgbWZuOiAwMDAwNWJkOA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo0N10gICBn
Zm46IDAwMDA1YmQ5ICBtZm46IDAwMDA1YmQ5DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMz
OjQ3XSAgIGdmbjogMDAwMDViZGEgIG1mbjogMDAwMDViZGENCg0KKFhFTikgWzIwMTItMDgt
MzEgMjE6MzM6NDddICAgZ2ZuOiAwMDAwNWJkYiAgbWZuOiAwMDAwNWJkYg0KDQooWEVOKSBb
MjAxMi0wOC0zMSAyMTozMzo0N10gICBnZm46IDAwMDA1YmRjICBtZm46IDAwMDA1YmRjDQoN
CihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjQ3XSAgIGdmbjogMDAwMDViZGQgIG1mbjogMDAw
MDViZGQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NDddICAgZ2ZuOiAwMDAwNWJkZSAg
bWZuOiAwMDAwNWJkZQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo0N10gICBnZm46IDAw
MDA1YmRmICBtZm46IDAwMDA1YmRmDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjQ3XSAg
IGdmbjogMDAwMDViZTAgIG1mbjogMDAwMDViZTANCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6
MzM6NDddICAgZ2ZuOiAwMDAwNWJlMSAgbWZuOiAwMDAwNWJlMQ0KDQooWEVOKSBbMjAxMi0w
OC0zMSAyMTozMzo0N10gICBnZm46IDAwMDA1YmUyICBtZm46IDAwMDA1YmUyDQoNCihYRU4p
IFsyMDEyLTA4LTMxIDIxOjMzOjQ3XSAgIGdmbjogMDAwMDViZTMgIG1mbjogMDAwMDViZTMN
Cg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NDddICAgZ2ZuOiAwMDAwNWJlNCAgbWZuOiAw
MDAwNWJlNA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo0N10gICBnZm46IDAwMDA1YmU1
ICBtZm46IDAwMDA1YmU1DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjQ3XSAgIGdmbjog
MDAwMDViZTYgIG1mbjogMDAwMDViZTYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NDdd
ICAgZ2ZuOiAwMDAwNWJlNyAgbWZuOiAwMDAwNWJlNw0KDQooWEVOKSBbMjAxMi0wOC0zMSAy
MTozMzo0N10gICBnZm46IDAwMDA1YmU4ICBtZm46IDAwMDA1YmU4DQoNCihYRU4pIFsyMDEy
LTA4LTMxIDIxOjMzOjQ3XSAgIGdmbjogMDAwMDViZTkgIG1mbjogMDAwMDViZTkNCg0KKFhF
TikgWzIwMTItMDgtMzEgMjE6MzM6NDddICAgZ2ZuOiAwMDAwNWJlYSAgbWZuOiAwMDAwNWJl
YQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo0N10gICBnZm46IDAwMDA1YmViICBtZm46
IDAwMDA1YmViDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjQ3XSAgIGdmbjogMDAwMDVi
ZWMgIG1mbjogMDAwMDViZWMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NDddICAgZ2Zu
OiAwMDAwNWJlZCAgbWZuOiAwMDAwNWJlZA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo0
N10gICBnZm46IDAwMDA1YmVlICBtZm46IDAwMDA1YmVlDQoNCihYRU4pIFsyMDEyLTA4LTMx
IDIxOjMzOjQ3XSAgIGdmbjogMDAwMDViZWYgIG1mbjogMDAwMDViZWYNCg0KKFhFTikgWzIw
MTItMDgtMzEgMjE6MzM6NDddICAgZ2ZuOiAwMDAwNWJmMCAgbWZuOiAwMDAwNWJmMA0KDQoo
WEVOKSBbMjAxMi0wOC0zMSAyMTozMzo0N10gICBnZm46IDAwMDA1YmYxICBtZm46IDAwMDA1
YmYxDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjQ3XSAgIGdmbjogMDAwMDViZjIgIG1m
bjogMDAwMDViZjINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NDddICAgZ2ZuOiAwMDAw
NWJmMyAgbWZuOiAwMDAwNWJmMw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo0N10gICBn
Zm46IDAwMDA1YmY0ICBtZm46IDAwMDA1YmY0DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMz
OjQ3XSAgIGdmbjogMDAwMDViZjUgIG1mbjogMDAwMDViZjUNCg0KKFhFTikgWzIwMTItMDgt
MzEgMjE6MzM6NDddICAgZ2ZuOiAwMDAwNWJmNiAgbWZuOiAwMDAwNWJmNg0KDQooWEVOKSBb
MjAxMi0wOC0zMSAyMTozMzo0N10gICBnZm46IDAwMDA1YmY3ICBtZm46IDAwMDA1YmY3DQoN
CihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjQ3XSAgIGdmbjogMDAwMDViZjggIG1mbjogMDAw
MDViZjgNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NDddICAgZ2ZuOiAwMDAwNWJmOSAg
bWZuOiAwMDAwNWJmOQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo0N10gICBnZm46IDAw
MDA1YmZhICBtZm46IDAwMDA1YmZhDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjQ3XSAg
IGdmbjogMDAwMDViZmIgIG1mbjogMDAwMDViZmINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6
MzM6NDddICAgZ2ZuOiAwMDAwNWJmYyAgbWZuOiAwMDAwNWJmYw0KDQooWEVOKSBbMjAxMi0w
OC0zMSAyMTozMzo0N10gICBnZm46IDAwMDA1YmZkICBtZm46IDAwMDA1YmZkDQoNCihYRU4p
IFsyMDEyLTA4LTMxIDIxOjMzOjQ3XSAgIGdmbjogMDAwMDViZmUgIG1mbjogMDAwMDViZmUN
Cg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NDddICAgZ2ZuOiAwMDAwNWJmZiAgbWZuOiAw
MDAwNWJmZg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo0N10gICBnZm46IDAwMDA1YzAw
ICBtZm46IDAwMDA1YzAwDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjQ3XSAgIGdmbjog
MDAwMDVjMDEgIG1mbjogMDAwMDVjMDENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NDdd
ICAgZ2ZuOiAwMDAwNWMwMiAgbWZuOiAwMDAwNWMwMg0KDQooWEVOKSBbMjAxMi0wOC0zMSAy
MTozMzo0N10gICBnZm46IDAwMDA1YzAzICBtZm46IDAwMDA1YzAzDQoNCihYRU4pIFsyMDEy
LTA4LTMxIDIxOjMzOjQ3XSAgIGdmbjogMDAwMDVjMDQgIG1mbjogMDAwMDVjMDQNCg0KKFhF
TikgWzIwMTItMDgtMzEgMjE6MzM6NDddICAgZ2ZuOiAwMDAwNWMwNSAgbWZuOiAwMDAwNWMw
NQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo0OF0gICBnZm46IDAwMDA1YzA2ICBtZm46
IDAwMDA1YzA2DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjQ4XSAgIGdmbjogMDAwMDVj
MDcgIG1mbjogMDAwMDVjMDcNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NDhdICAgZ2Zu
OiAwMDAwNWMwOCAgbWZuOiAwMDAwNWMwOA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo0
OF0gICBnZm46IDAwMDA1YzA5ICBtZm46IDAwMDA1YzA5DQoNCihYRU4pIFsyMDEyLTA4LTMx
IDIxOjMzOjQ4XSAgIGdmbjogMDAwMDVjMGEgIG1mbjogMDAwMDVjMGENCg0KKFhFTikgWzIw
MTItMDgtMzEgMjE6MzM6NDhdICAgZ2ZuOiAwMDAwNWMwYiAgbWZuOiAwMDAwNWMwYg0KDQoo
WEVOKSBbMjAxMi0wOC0zMSAyMTozMzo0OF0gICBnZm46IDAwMDA1YzBjICBtZm46IDAwMDA1
YzBjDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjQ4XSAgIGdmbjogMDAwMDVjMGQgIG1m
bjogMDAwMDVjMGQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NDhdICAgZ2ZuOiAwMDAw
NWMwZSAgbWZuOiAwMDAwNWMwZQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo0OF0gICBn
Zm46IDAwMDA1YzBmICBtZm46IDAwMDA1YzBmDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMz
OjQ4XSAgIGdmbjogMDAwMDVjMTAgIG1mbjogMDAwMDVjMTANCg0KKFhFTikgWzIwMTItMDgt
MzEgMjE6MzM6NDhdICAgZ2ZuOiAwMDAwNWMxMSAgbWZuOiAwMDAwNWMxMQ0KDQooWEVOKSBb
MjAxMi0wOC0zMSAyMTozMzo0OF0gICBnZm46IDAwMDA1YzEyICBtZm46IDAwMDA1YzEyDQoN
CihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjQ4XSAgIGdmbjogMDAwMDVjMTMgIG1mbjogMDAw
MDVjMTMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NDhdICAgZ2ZuOiAwMDAwNWMxNCAg
bWZuOiAwMDAwNWMxNA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo0OF0gICBnZm46IDAw
MDA1YzE1ICBtZm46IDAwMDA1YzE1DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjQ4XSAg
IGdmbjogMDAwMDVjMTYgIG1mbjogMDAwMDVjMTYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6
MzM6NDhdICAgZ2ZuOiAwMDAwNWMxNyAgbWZuOiAwMDAwNWMxNw0KDQooWEVOKSBbMjAxMi0w
OC0zMSAyMTozMzo0OF0gICBnZm46IDAwMDA1YzE4ICBtZm46IDAwMDA1YzE4DQoNCihYRU4p
IFsyMDEyLTA4LTMxIDIxOjMzOjQ4XSAgIGdmbjogMDAwMDVjMTkgIG1mbjogMDAwMDVjMTkN
Cg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NDhdICAgZ2ZuOiAwMDAwNWMxYSAgbWZuOiAw
MDAwNWMxYQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo0OF0gICBnZm46IDAwMDA1YzFi
ICBtZm46IDAwMDA1YzFiDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjQ4XSAgIGdmbjog
MDAwMDVjMWMgIG1mbjogMDAwMDVjMWMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NDhd
ICAgZ2ZuOiAwMDAwNWMxZCAgbWZuOiAwMDAwNWMxZA0KDQooWEVOKSBbMjAxMi0wOC0zMSAy
MTozMzo0OF0gICBnZm46IDAwMDA1YzFlICBtZm46IDAwMDA1YzFlDQoNCihYRU4pIFsyMDEy
LTA4LTMxIDIxOjMzOjQ4XSAgIGdmbjogMDAwMDVjMWYgIG1mbjogMDAwMDVjMWYNCg0KKFhF
TikgWzIwMTItMDgtMzEgMjE6MzM6NDhdICAgZ2ZuOiAwMDAwNWMyMCAgbWZuOiAwMDAwNWMy
MA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo0OF0gICBnZm46IDAwMDA1YzIxICBtZm46
IDAwMDA1YzIxDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjQ4XSAgIGdmbjogMDAwMDVj
MjIgIG1mbjogMDAwMDVjMjINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NDhdICAgZ2Zu
OiAwMDAwNWMyMyAgbWZuOiAwMDAwNWMyMw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo0
OF0gICBnZm46IDAwMDA1YzI0ICBtZm46IDAwMDA1YzI0DQoNCihYRU4pIFsyMDEyLTA4LTMx
IDIxOjMzOjQ4XSAgIGdmbjogMDAwMDVjMjUgIG1mbjogMDAwMDVjMjUNCg0KKFhFTikgWzIw
MTItMDgtMzEgMjE6MzM6NDhdICAgZ2ZuOiAwMDAwNWMyNiAgbWZuOiAwMDAwNWMyNg0KDQoo
WEVOKSBbMjAxMi0wOC0zMSAyMTozMzo0OF0gICBnZm46IDAwMDA1YzI3ICBtZm46IDAwMDA1
YzI3DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjQ4XSAgIGdmbjogMDAwMDVjMjggIG1m
bjogMDAwMDVjMjgNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NDhdICAgZ2ZuOiAwMDAw
NWMyOSAgbWZuOiAwMDAwNWMyOQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo0OF0gICBn
Zm46IDAwMDA1YzJhICBtZm46IDAwMDA1YzJhDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMz
OjQ4XSAgIGdmbjogMDAwMDVjMmIgIG1mbjogMDAwMDVjMmINCg0KKFhFTikgWzIwMTItMDgt
MzEgMjE6MzM6NDhdICAgZ2ZuOiAwMDAwNWMyYyAgbWZuOiAwMDAwNWMyYw0KDQooWEVOKSBb
MjAxMi0wOC0zMSAyMTozMzo0OF0gICBnZm46IDAwMDA1YzJkICBtZm46IDAwMDA1YzJkDQoN
CihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjQ4XSAgIGdmbjogMDAwMDVjMmUgIG1mbjogMDAw
MDVjMmUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NDhdICAgZ2ZuOiAwMDAwNWMyZiAg
bWZuOiAwMDAwNWMyZg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo0OF0gICBnZm46IDAw
MDA1YzMwICBtZm46IDAwMDA1YzMwDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjQ4XSAg
IGdmbjogMDAwMDVjMzEgIG1mbjogMDAwMDVjMzENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6
MzM6NDhdICAgZ2ZuOiAwMDAwNWMzMiAgbWZuOiAwMDAwNWMzMg0KDQooWEVOKSBbMjAxMi0w
OC0zMSAyMTozMzo0OF0gICBnZm46IDAwMDA1YzMzICBtZm46IDAwMDA1YzMzDQoNCihYRU4p
IFsyMDEyLTA4LTMxIDIxOjMzOjQ4XSAgIGdmbjogMDAwMDVjMzQgIG1mbjogMDAwMDVjMzQN
Cg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NDhdICAgZ2ZuOiAwMDAwNWMzNSAgbWZuOiAw
MDAwNWMzNQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo0OF0gICBnZm46IDAwMDA1YzM2
ICBtZm46IDAwMDA1YzM2DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjQ4XSAgIGdmbjog
MDAwMDVjMzcgIG1mbjogMDAwMDVjMzcNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NDhd
ICAgZ2ZuOiAwMDAwNWMzOCAgbWZuOiAwMDAwNWMzOA0KDQooWEVOKSBbMjAxMi0wOC0zMSAy
MTozMzo0OF0gICBnZm46IDAwMDA1YzM5ICBtZm46IDAwMDA1YzM5DQoNCihYRU4pIFsyMDEy
LTA4LTMxIDIxOjMzOjQ4XSAgIGdmbjogMDAwMDVjM2EgIG1mbjogMDAwMDVjM2ENCg0KKFhF
TikgWzIwMTItMDgtMzEgMjE6MzM6NDhdICAgZ2ZuOiAwMDAwNWMzYiAgbWZuOiAwMDAwNWMz
Yg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo0OF0gICBnZm46IDAwMDA1YzNjICBtZm46
IDAwMDA1YzNjDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjQ4XSAgIGdmbjogMDAwMDVj
M2QgIG1mbjogMDAwMDVjM2QNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NDhdICAgZ2Zu
OiAwMDAwNWMzZSAgbWZuOiAwMDAwNWMzZQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo0
OF0gICBnZm46IDAwMDA1YzNmICBtZm46IDAwMDA1YzNmDQoNCihYRU4pIFsyMDEyLTA4LTMx
IDIxOjMzOjQ4XSAgIGdmbjogMDAwMDVjNDAgIG1mbjogMDAwMDVjNDANCg0KKFhFTikgWzIw
MTItMDgtMzEgMjE6MzM6NDhdICAgZ2ZuOiAwMDAwNWM0MSAgbWZuOiAwMDAwNWM0MQ0KDQoo
WEVOKSBbMjAxMi0wOC0zMSAyMTozMzo0OF0gICBnZm46IDAwMDA1YzQyICBtZm46IDAwMDA1
YzQyDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjQ4XSAgIGdmbjogMDAwMDVjNDMgIG1m
bjogMDAwMDVjNDMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NDhdICAgZ2ZuOiAwMDAw
NWM0NCAgbWZuOiAwMDAwNWM0NA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo0OF0gICBn
Zm46IDAwMDA1YzQ1ICBtZm46IDAwMDA1YzQ1DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMz
OjQ5XSAgIGdmbjogMDAwMDVjNDYgIG1mbjogMDAwMDVjNDYNCg0KKFhFTikgWzIwMTItMDgt
MzEgMjE6MzM6NDldICAgZ2ZuOiAwMDAwNWM0NyAgbWZuOiAwMDAwNWM0Nw0KDQooWEVOKSBb
MjAxMi0wOC0zMSAyMTozMzo0OV0gICBnZm46IDAwMDA1YzQ4ICBtZm46IDAwMDA1YzQ4DQoN
CihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjQ5XSAgIGdmbjogMDAwMDVjNDkgIG1mbjogMDAw
MDVjNDkNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NDldICAgZ2ZuOiAwMDAwNWM0YSAg
bWZuOiAwMDAwNWM0YQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo0OV0gICBnZm46IDAw
MDA1YzRiICBtZm46IDAwMDA1YzRiDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjQ5XSAg
IGdmbjogMDAwMDVjNGMgIG1mbjogMDAwMDVjNGMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6
MzM6NDldICAgZ2ZuOiAwMDAwNWM0ZCAgbWZuOiAwMDAwNWM0ZA0KDQooWEVOKSBbMjAxMi0w
OC0zMSAyMTozMzo0OV0gICBnZm46IDAwMDA1YzRlICBtZm46IDAwMDA1YzRlDQoNCihYRU4p
IFsyMDEyLTA4LTMxIDIxOjMzOjQ5XSAgIGdmbjogMDAwMDVjNGYgIG1mbjogMDAwMDVjNGYN
Cg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NDldICAgZ2ZuOiAwMDAwNWM1MCAgbWZuOiAw
MDAwNWM1MA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo0OV0gICBnZm46IDAwMDA1YzUx
ICBtZm46IDAwMDA1YzUxDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjQ5XSAgIGdmbjog
MDAwMDVjNTIgIG1mbjogMDAwMDVjNTINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NDld
ICAgZ2ZuOiAwMDAwNWM1MyAgbWZuOiAwMDAwNWM1Mw0KDQooWEVOKSBbMjAxMi0wOC0zMSAy
MTozMzo0OV0gICBnZm46IDAwMDA1YzU0ICBtZm46IDAwMDA1YzU0DQoNCihYRU4pIFsyMDEy
LTA4LTMxIDIxOjMzOjQ5XSAgIGdmbjogMDAwMDVjNTUgIG1mbjogMDAwMDVjNTUNCg0KKFhF
TikgWzIwMTItMDgtMzEgMjE6MzM6NDldICAgZ2ZuOiAwMDAwNWM1NiAgbWZuOiAwMDAwNWM1
Ng0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo0OV0gICBnZm46IDAwMDA1YzU3ICBtZm46
IDAwMDA1YzU3DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjQ5XSAgIGdmbjogMDAwMDVj
NTggIG1mbjogMDAwMDVjNTgNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NDldICAgZ2Zu
OiAwMDAwNWM1OSAgbWZuOiAwMDAwNWM1OQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo0
OV0gICBnZm46IDAwMDA1YzVhICBtZm46IDAwMDA1YzVhDQoNCihYRU4pIFsyMDEyLTA4LTMx
IDIxOjMzOjQ5XSAgIGdmbjogMDAwMDVjNWIgIG1mbjogMDAwMDVjNWINCg0KKFhFTikgWzIw
MTItMDgtMzEgMjE6MzM6NDldICAgZ2ZuOiAwMDAwNWM1YyAgbWZuOiAwMDAwNWM1Yw0KDQoo
WEVOKSBbMjAxMi0wOC0zMSAyMTozMzo0OV0gICBnZm46IDAwMDA1YzVkICBtZm46IDAwMDA1
YzVkDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjQ5XSAgIGdmbjogMDAwMDVjNWUgIG1m
bjogMDAwMDVjNWUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NDldICAgZ2ZuOiAwMDAw
NWM1ZiAgbWZuOiAwMDAwNWM1Zg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo0OV0gICBn
Zm46IDAwMDA1YzYwICBtZm46IDAwMDA1YzYwDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMz
OjQ5XSAgIGdmbjogMDAwMDVjNjEgIG1mbjogMDAwMDVjNjENCg0KKFhFTikgWzIwMTItMDgt
MzEgMjE6MzM6NDldICAgZ2ZuOiAwMDAwNWM2MiAgbWZuOiAwMDAwNWM2Mg0KDQooWEVOKSBb
MjAxMi0wOC0zMSAyMTozMzo0OV0gICBnZm46IDAwMDA1YzYzICBtZm46IDAwMDA1YzYzDQoN
CihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjQ5XSAgIGdmbjogMDAwMDVjNjQgIG1mbjogMDAw
MDVjNjQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NDldICAgZ2ZuOiAwMDAwNWM2NSAg
bWZuOiAwMDAwNWM2NQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo0OV0gICBnZm46IDAw
MDA1YzY2ICBtZm46IDAwMDA1YzY2DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjQ5XSAg
IGdmbjogMDAwMDVjNjcgIG1mbjogMDAwMDVjNjcNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6
MzM6NDldICAgZ2ZuOiAwMDAwNWM2OCAgbWZuOiAwMDAwNWM2OA0KDQooWEVOKSBbMjAxMi0w
OC0zMSAyMTozMzo0OV0gICBnZm46IDAwMDA1YzY5ICBtZm46IDAwMDA1YzY5DQoNCihYRU4p
IFsyMDEyLTA4LTMxIDIxOjMzOjQ5XSAgIGdmbjogMDAwMDVjNmEgIG1mbjogMDAwMDVjNmEN
Cg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NDldICAgZ2ZuOiAwMDAwNWM2YiAgbWZuOiAw
MDAwNWM2Yg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo0OV0gICBnZm46IDAwMDA1YzZj
ICBtZm46IDAwMDA1YzZjDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjQ5XSAgIGdmbjog
MDAwMDVjNmQgIG1mbjogMDAwMDVjNmQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NDld
ICAgZ2ZuOiAwMDAwNWM2ZSAgbWZuOiAwMDAwNWM2ZQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAy
MTozMzo0OV0gICBnZm46IDAwMDA1YzZmICBtZm46IDAwMDA1YzZmDQoNCihYRU4pIFsyMDEy
LTA4LTMxIDIxOjMzOjQ5XSAgIGdmbjogMDAwMDVjNzAgIG1mbjogMDAwMDVjNzANCg0KKFhF
TikgWzIwMTItMDgtMzEgMjE6MzM6NDldICAgZ2ZuOiAwMDAwNWM3MSAgbWZuOiAwMDAwNWM3
MQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo0OV0gICBnZm46IDAwMDA1YzcyICBtZm46
IDAwMDA1YzcyDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjQ5XSAgIGdmbjogMDAwMDVj
NzMgIG1mbjogMDAwMDVjNzMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NDldICAgZ2Zu
OiAwMDAwNWM3NCAgbWZuOiAwMDAwNWM3NA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo0
OV0gICBnZm46IDAwMDA1Yzc1ICBtZm46IDAwMDA1Yzc1DQoNCihYRU4pIFsyMDEyLTA4LTMx
IDIxOjMzOjQ5XSAgIGdmbjogMDAwMDVjNzYgIG1mbjogMDAwMDVjNzYNCg0KKFhFTikgWzIw
MTItMDgtMzEgMjE6MzM6NDldICAgZ2ZuOiAwMDAwNWM3NyAgbWZuOiAwMDAwNWM3Nw0KDQoo
WEVOKSBbMjAxMi0wOC0zMSAyMTozMzo0OV0gICBnZm46IDAwMDA1Yzc4ICBtZm46IDAwMDA1
Yzc4DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjQ5XSAgIGdmbjogMDAwMDVjNzkgIG1m
bjogMDAwMDVjNzkNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NDldICAgZ2ZuOiAwMDAw
NWM3YSAgbWZuOiAwMDAwNWM3YQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo0OV0gICBn
Zm46IDAwMDA1YzdiICBtZm46IDAwMDA1YzdiDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMz
OjQ5XSAgIGdmbjogMDAwMDVjN2MgIG1mbjogMDAwMDVjN2MNCg0KKFhFTikgWzIwMTItMDgt
MzEgMjE6MzM6NDldICAgZ2ZuOiAwMDAwNWM3ZCAgbWZuOiAwMDAwNWM3ZA0KDQooWEVOKSBb
MjAxMi0wOC0zMSAyMTozMzo0OV0gICBnZm46IDAwMDA1YzdlICBtZm46IDAwMDA1YzdlDQoN
CihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjQ5XSAgIGdmbjogMDAwMDVjN2YgIG1mbjogMDAw
MDVjN2YNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NDldICAgZ2ZuOiAwMDAwNWM4MCAg
bWZuOiAwMDAwNWM4MA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo0OV0gICBnZm46IDAw
MDA1YzgxICBtZm46IDAwMDA1YzgxDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjQ5XSAg
IGdmbjogMDAwMDVjODIgIG1mbjogMDAwMDVjODINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6
MzM6NDldICAgZ2ZuOiAwMDAwNWM4MyAgbWZuOiAwMDAwNWM4Mw0KDQooWEVOKSBbMjAxMi0w
OC0zMSAyMTozMzo0OV0gICBnZm46IDAwMDA1Yzg0ICBtZm46IDAwMDA1Yzg0DQoNCihYRU4p
IFsyMDEyLTA4LTMxIDIxOjMzOjQ5XSAgIGdmbjogMDAwMDVjODUgIG1mbjogMDAwMDVjODUN
Cg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NDldICAgZ2ZuOiAwMDAwNWM4NiAgbWZuOiAw
MDAwNWM4Ng0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo1MF0gICBnZm46IDAwMDA1Yzg3
ICBtZm46IDAwMDA1Yzg3DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjUwXSAgIGdmbjog
MDAwMDVjODggIG1mbjogMDAwMDVjODgNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NTBd
ICAgZ2ZuOiAwMDAwNWM4OSAgbWZuOiAwMDAwNWM4OQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAy
MTozMzo1MF0gICBnZm46IDAwMDA1YzhhICBtZm46IDAwMDA1YzhhDQoNCihYRU4pIFsyMDEy
LTA4LTMxIDIxOjMzOjUwXSAgIGdmbjogMDAwMDVjOGIgIG1mbjogMDAwMDVjOGINCg0KKFhF
TikgWzIwMTItMDgtMzEgMjE6MzM6NTBdICAgZ2ZuOiAwMDAwNWM4YyAgbWZuOiAwMDAwNWM4
Yw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo1MF0gICBnZm46IDAwMDA1YzhkICBtZm46
IDAwMDA1YzhkDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjUwXSAgIGdmbjogMDAwMDVj
OGUgIG1mbjogMDAwMDVjOGUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NTBdICAgZ2Zu
OiAwMDAwNWM4ZiAgbWZuOiAwMDAwNWM4Zg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo1
MF0gICBnZm46IDAwMDA1YzkwICBtZm46IDAwMDA1YzkwDQoNCihYRU4pIFsyMDEyLTA4LTMx
IDIxOjMzOjUwXSAgIGdmbjogMDAwMDVjOTEgIG1mbjogMDAwMDVjOTENCg0KKFhFTikgWzIw
MTItMDgtMzEgMjE6MzM6NTBdICAgZ2ZuOiAwMDAwNWM5MiAgbWZuOiAwMDAwNWM5Mg0KDQoo
WEVOKSBbMjAxMi0wOC0zMSAyMTozMzo1MF0gICBnZm46IDAwMDA1YzkzICBtZm46IDAwMDA1
YzkzDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjUwXSAgIGdmbjogMDAwMDVjOTQgIG1m
bjogMDAwMDVjOTQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NTBdICAgZ2ZuOiAwMDAw
NWM5NSAgbWZuOiAwMDAwNWM5NQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo1MF0gICBn
Zm46IDAwMDA1Yzk2ICBtZm46IDAwMDA1Yzk2DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMz
OjUwXSAgIGdmbjogMDAwMDVjOTcgIG1mbjogMDAwMDVjOTcNCg0KKFhFTikgWzIwMTItMDgt
MzEgMjE6MzM6NTBdICAgZ2ZuOiAwMDAwNWM5OCAgbWZuOiAwMDAwNWM5OA0KDQooWEVOKSBb
MjAxMi0wOC0zMSAyMTozMzo1MF0gICBnZm46IDAwMDA1Yzk5ICBtZm46IDAwMDA1Yzk5DQoN
CihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjUwXSAgIGdmbjogMDAwMDVjOWEgIG1mbjogMDAw
MDVjOWENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NTBdICAgZ2ZuOiAwMDAwNWM5YiAg
bWZuOiAwMDAwNWM5Yg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo1MF0gICBnZm46IDAw
MDA1YzljICBtZm46IDAwMDA1YzljDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjUwXSAg
IGdmbjogMDAwMDVjOWQgIG1mbjogMDAwMDVjOWQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6
MzM6NTBdICAgZ2ZuOiAwMDAwNWM5ZSAgbWZuOiAwMDAwNWM5ZQ0KDQooWEVOKSBbMjAxMi0w
OC0zMSAyMTozMzo1MF0gICBnZm46IDAwMDA1YzlmICBtZm46IDAwMDA1YzlmDQoNCihYRU4p
IFsyMDEyLTA4LTMxIDIxOjMzOjUwXSAgIGdmbjogMDAwMDVjYTAgIG1mbjogMDAwMDVjYTAN
Cg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NTBdICAgZ2ZuOiAwMDAwNWNhMSAgbWZuOiAw
MDAwNWNhMQ0KDQpbICA0OTYuNDE4NjcxXSBhKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NTBd
ICAgZ2ZuOiAwMDAwNWNhMiAgbWZuOiAwMDAwNWNhMg0KDQp0YTMuMDA6IHFjIHRpbWVvKFhF
TikgWzIwMTItMDgtMzEgMjE6MzM6NTBdICAgZ2ZuOiAwMDAwNWNhMyAgbWZuOiAwMDAwNWNh
Mw0KDQp1dCAoY21kIDB4ZWMpDQoNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NTBdICAg
Z2ZuOiAwMDAwNWNhNCAgbWZuOiAwMDAwNWNhNA0KDQpbICA0OTYuNDc2OTUxXSBhKFhFTikg
WzIwMTItMDgtMzEgMjE6MzM6NTBdICAgZ2ZuOiAwMDAwNWNhNSAgbWZuOiAwMDAwNWNhNQ0K
DQp0YTMuMDA6IGZhaWxlZCB0byBJREVOVElGWSAoSS9PIChYRU4pIFsyMDEyLTA4LTMxIDIx
OjMzOjUwXSAgIGdmbjogMDAwMDVjYTYgIG1mbjogMDAwMDVjYTYNCg0KZXJyb3IsIGVycl9t
YXNrPShYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjUwXSAgIGdmbjogMDAwMDVjYTcgIG1mbjog
MDAwMDVjYTcNCg0KMHg0KQ0KDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjUwXSAgIGdm
bjogMDAwMDVjYTggIG1mbjogMDAwMDVjYTgNCg0KWyAgNDk2LjU1NTkwNF0gYShYRU4pIFsy
MDEyLTA4LTMxIDIxOjMzOjUwXSAgIGdmbjogMDAwMDVjYTkgIG1mbjogMDAwMDVjYTkNCg0K
dGEzLjAwOiByZXZhbGlkYShYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjUwXSAgIGdmbjogMDAw
MDVjYWEgIG1mbjogMDAwMDVjYWENCg0KdGlvbiBmYWlsZWQgKGVycihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMzOjUwXSAgIGdmbjogMDAwMDVjYWIgIG1mbjogMDAwMDVjYWINCg0Kbm89LTUp
DQoNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NTBdICAgZ2ZuOiAwMDAwNWNhYyAgbWZu
OiAwMDAwNWNhYw0KDQpbICA0OTYuNjM1MDE1XSBhKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6
NTBdICAgZ2ZuOiAwMDAwNWNhZCAgbWZuOiAwMDAwNWNhZA0KDQp0YTM6IGxpbWl0aW5nIFNB
VEEgbGluayBzcGVlZCB0byhYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjUwXSAgIGdmbjogMDAw
MDVjYWUgIG1mbjogMDAwMDVjYWUNCg0KIDMuMCBHYnBzDQoNCg0KKFhFTikgWzIwMTItMDgt
MzEgMjE6MzM6NTBdICAgZ2ZuOiAwMDAwNWNhZiAgbWZuOiAwMDAwNWNhZg0KDQpbICA0OTYu
Njk3MzMwXSBhdGEzOiBoYXJkIHJlc2V0dChYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjUwXSAg
IGdmbjogMDAwMDVjYjAgIG1mbjogMDAwMDVjYjANCg0KaW5nIGxpbmsNCg0KDQooWEVOKSBb
MjAxMi0wOC0zMSAyMTozMzo1MF0gICBnZm46IDAwMDA1Y2IxICBtZm46IDAwMDA1Y2IxDQoN
CihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjUwXSAgIGdmbjogMDAwMDVjYjIgIG1mbjogMDAw
MDVjYjINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NTBdICAgZ2ZuOiAwMDAwNWNiMyAg
bWZuOiAwMDAwNWNiMw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo1MF0gICBnZm46IDAw
MDA1Y2I0ICBtZm46IDAwMDA1Y2I0DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjUwXSAg
IGdmbjogMDAwMDVjYjUgIG1mbjogMDAwMDVjYjUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6
MzM6NTBdICAgZ2ZuOiAwMDAwNWNiNiAgbWZuOiAwMDAwNWNiNg0KDQooWEVOKSBbMjAxMi0w
OC0zMSAyMTozMzo1MF0gICBnZm46IDAwMDA1Y2I3ICBtZm46IDAwMDA1Y2I3DQoNCihYRU4p
IFsyMDEyLTA4LTMxIDIxOjMzOjUwXSAgIGdmbjogMDAwMDVjYjggIG1mbjogMDAwMDVjYjgN
Cg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NTBdICAgZ2ZuOiAwMDAwNWNiOSAgbWZuOiAw
MDAwNWNiOQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo1MF0gICBnZm46IDAwMDA1Y2Jh
ICBtZm46IDAwMDA1Y2JhDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjUwXSAgIGdmbjog
MDAwMDVjYmIgIG1mbjogMDAwMDVjYmINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NTBd
ICAgZ2ZuOiAwMDAwNWNiYyAgbWZuOiAwMDAwNWNiYw0KDQooWEVOKSBbMjAxMi0wOC0zMSAy
MTozMzo1MF0gICBnZm46IDAwMDA1Y2JkICBtZm46IDAwMDA1Y2JkDQoNCihYRU4pIFsyMDEy
LTA4LTMxIDIxOjMzOjUwXSAgIGdmbjogMDAwMDVjYmUgIG1mbjogMDAwMDVjYmUNCg0KKFhF
TikgWzIwMTItMDgtMzEgMjE6MzM6NTBdICAgZ2ZuOiAwMDAwNWNiZiAgbWZuOiAwMDAwNWNi
Zg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo1MF0gICBnZm46IDAwMDA1Y2MwICBtZm46
IDAwMDA1Y2MwDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjUwXSAgIGdmbjogMDAwMDVj
YzEgIG1mbjogMDAwMDVjYzENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NTFdICAgZ2Zu
OiAwMDAwNWNjMiAgbWZuOiAwMDAwNWNjMg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo1
MV0gICBnZm46IDAwMDA1Y2MzICBtZm46IDAwMDA1Y2MzDQoNCihYRU4pIFsyMDEyLTA4LTMx
IDIxOjMzOjUxXSAgIGdmbjogMDAwMDVjYzQgIG1mbjogMDAwMDVjYzQNCg0KKFhFTikgWzIw
MTItMDgtMzEgMjE6MzM6NTFdICAgZ2ZuOiAwMDAwNWNjNSAgbWZuOiAwMDAwNWNjNQ0KDQoo
WEVOKSBbMjAxMi0wOC0zMSAyMTozMzo1MV0gICBnZm46IDAwMDA1Y2M2ICBtZm46IDAwMDA1
Y2M2DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjUxXSAgIGdmbjogMDAwMDVjYzcgIG1m
bjogMDAwMDVjYzcNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NTFdICAgZ2ZuOiAwMDAw
NWNjOCAgbWZuOiAwMDAwNWNjOA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo1MV0gICBn
Zm46IDAwMDA1Y2M5ICBtZm46IDAwMDA1Y2M5DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMz
OjUxXSAgIGdmbjogMDAwMDVjY2EgIG1mbjogMDAwMDVjY2ENCg0KKFhFTikgWzIwMTItMDgt
MzEgMjE6MzM6NTFdICAgZ2ZuOiAwMDAwNWNjYiAgbWZuOiAwMDAwNWNjYg0KDQooWEVOKSBb
MjAxMi0wOC0zMSAyMTozMzo1MV0gICBnZm46IDAwMDA1Y2NjICBtZm46IDAwMDA1Y2NjDQoN
CihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjUxXSAgIGdmbjogMDAwMDVjY2QgIG1mbjogMDAw
MDVjY2QNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NTFdICAgZ2ZuOiAwMDAwNWNjZSAg
bWZuOiAwMDAwNWNjZQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo1MV0gICBnZm46IDAw
MDA1Y2NmICBtZm46IDAwMDA1Y2NmDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjUxXSAg
IGdmbjogMDAwMDVjZDAgIG1mbjogMDAwMDVjZDANCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6
MzM6NTFdICAgZ2ZuOiAwMDAwNWNkMSAgbWZuOiAwMDAwNWNkMQ0KDQpbICA0OTcuMjQyMTc3
XSBhKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NTFdICAgZ2ZuOiAwMDAwNWNkMiAgbWZuOiAw
MDAwNWNkMg0KDQp0YTM6IFNBVEEgbGluayB1KFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NTFd
ICAgZ2ZuOiAwMDAwNWNkMyAgbWZuOiAwMDAwNWNkMw0KDQpwIDMuMCBHYnBzIChTU3RhdHVz
IDEyMyBTQ29udHJvbChYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjUxXSAgIGdmbjogMDAwMDVj
ZDQgIG1mbjogMDAwMDVjZDQNCg0KIDMyMCkNCg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
Mzo1MV0gICBnZm46IDAwMDA1Y2Q1ICBtZm46IDAwMDA1Y2Q1DQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMzOjUxXSAgIGdmbjogMDAwMDVjZDYgIG1mbjogMDAwMDVjZDYNCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzM6NTFdICAgZ2ZuOiAwMDAwNWNkNyAgbWZuOiAwMDAwNWNkNw0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo1MV0gICBnZm46IDAwMDA1Y2Q4ICBtZm46IDAw
MDA1Y2Q4DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjUxXSAgIGdmbjogMDAwMDVjZDkg
IG1mbjogMDAwMDVjZDkNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NTFdICAgZ2ZuOiAw
MDAwNWNkYSAgbWZuOiAwMDAwNWNkYQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo1MV0g
ICBnZm46IDAwMDA1Y2RiICBtZm46IDAwMDA1Y2RiDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMzOjUxXSAgIGdmbjogMDAwMDVjZGMgIG1mbjogMDAwMDVjZGMNCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzM6NTFdICAgZ2ZuOiAwMDAwNWNkZCAgbWZuOiAwMDAwNWNkZA0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMzo1MV0gICBnZm46IDAwMDA1Y2RlICBtZm46IDAwMDA1Y2Rl
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjUxXSAgIGdmbjogMDAwMDVjZGYgIG1mbjog
MDAwMDVjZGYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NTFdICAgZ2ZuOiAwMDAwNWNl
MCAgbWZuOiAwMDAwNWNlMA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo1MV0gICBnZm46
IDAwMDA1Y2UxICBtZm46IDAwMDA1Y2UxDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjUx
XSAgIGdmbjogMDAwMDVjZTIgIG1mbjogMDAwMDVjZTINCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzM6NTFdICAgZ2ZuOiAwMDAwNWNlMyAgbWZuOiAwMDAwNWNlMw0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMzo1MV0gICBnZm46IDAwMDA1Y2U0ICBtZm46IDAwMDA1Y2U0DQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMzOjUxXSAgIGdmbjogMDAwMDVjZTUgIG1mbjogMDAwMDVj
ZTUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NTFdICAgZ2ZuOiAwMDAwNWNlNiAgbWZu
OiAwMDAwNWNlNg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo1MV0gICBnZm46IDAwMDA1
Y2U3ICBtZm46IDAwMDA1Y2U3DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjUxXSAgIGdm
bjogMDAwMDVjZTggIG1mbjogMDAwMDVjZTgNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6
NTFdICAgZ2ZuOiAwMDAwNWNlOSAgbWZuOiAwMDAwNWNlOQ0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMzo1MV0gICBnZm46IDAwMDA1Y2VhICBtZm46IDAwMDA1Y2VhDQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMzOjUxXSAgIGdmbjogMDAwMDVjZWIgIG1mbjogMDAwMDVjZWINCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NTFdICAgZ2ZuOiAwMDAwNWNlYyAgbWZuOiAwMDAw
NWNlYw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo1MV0gICBnZm46IDAwMDA1Y2VkICBt
Zm46IDAwMDA1Y2VkDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjUxXSAgIGdmbjogMDAw
MDVjZWUgIG1mbjogMDAwMDVjZWUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NTFdICAg
Z2ZuOiAwMDAwNWNlZiAgbWZuOiAwMDAwNWNlZg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
Mzo1MV0gICBnZm46IDAwMDA1Y2YwICBtZm46IDAwMDA1Y2YwDQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMzOjUxXSAgIGdmbjogMDAwMDVjZjEgIG1mbjogMDAwMDVjZjENCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzM6NTFdICAgZ2ZuOiAwMDAwNWNmMiAgbWZuOiAwMDAwNWNmMg0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo1MV0gICBnZm46IDAwMDA1Y2YzICBtZm46IDAw
MDA1Y2YzDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjUxXSAgIGdmbjogMDAwMDVjZjQg
IG1mbjogMDAwMDVjZjQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NTFdICAgZ2ZuOiAw
MDAwNWNmNSAgbWZuOiAwMDAwNWNmNQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo1MV0g
ICBnZm46IDAwMDA1Y2Y2ICBtZm46IDAwMDA1Y2Y2DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMzOjUxXSAgIGdmbjogMDAwMDVjZjcgIG1mbjogMDAwMDVjZjcNCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzM6NTFdICAgZ2ZuOiAwMDAwNWNmOCAgbWZuOiAwMDAwNWNmOA0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMzo1MV0gICBnZm46IDAwMDA1Y2Y5ICBtZm46IDAwMDA1Y2Y5
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjUxXSAgIGdmbjogMDAwMDVjZmEgIG1mbjog
MDAwMDVjZmENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NTFdICAgZ2ZuOiAwMDAwNWNm
YiAgbWZuOiAwMDAwNWNmYg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo1MV0gICBnZm46
IDAwMDA1Y2ZjICBtZm46IDAwMDA1Y2ZjDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjUx
XSAgIGdmbjogMDAwMDVjZmQgIG1mbjogMDAwMDVjZmQNCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzM6NTFdICAgZ2ZuOiAwMDAwNWNmZSAgbWZuOiAwMDAwNWNmZQ0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMzo1MV0gICBnZm46IDAwMDA1Y2ZmICBtZm46IDAwMDA1Y2ZmDQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMzOjUxXSAgIGdmbjogMDAwMDVkMDAgIG1mbjogMDAwMDVk
MDANCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NTJdICAgZ2ZuOiAwMDAwNWQwMSAgbWZu
OiAwMDAwNWQwMQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo1Ml0gICBnZm46IDAwMDA1
ZDAyICBtZm46IDAwMDA1ZDAyDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjUyXSAgIGdm
bjogMDAwMDVkMDMgIG1mbjogMDAwMDVkMDMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6
NTJdICAgZ2ZuOiAwMDAwNWQwNCAgbWZuOiAwMDAwNWQwNA0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMzo1Ml0gICBnZm46IDAwMDA1ZDA1ICBtZm46IDAwMDA1ZDA1DQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMzOjUyXSAgIGdmbjogMDAwMDVkMDYgIG1mbjogMDAwMDVkMDYNCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NTJdICAgZ2ZuOiAwMDAwNWQwNyAgbWZuOiAwMDAw
NWQwNw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo1Ml0gICBnZm46IDAwMDA1ZDA4ICBt
Zm46IDAwMDA1ZDA4DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjUyXSAgIGdmbjogMDAw
MDVkMDkgIG1mbjogMDAwMDVkMDkNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NTJdICAg
Z2ZuOiAwMDAwNWQwYSAgbWZuOiAwMDAwNWQwYQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
Mzo1Ml0gICBnZm46IDAwMDA1ZDBiICBtZm46IDAwMDA1ZDBiDQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMzOjUyXSAgIGdmbjogMDAwMDVkMGMgIG1mbjogMDAwMDVkMGMNCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzM6NTJdICAgZ2ZuOiAwMDAwNWQwZCAgbWZuOiAwMDAwNWQwZA0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo1Ml0gICBnZm46IDAwMDA1ZDBlICBtZm46IDAw
MDA1ZDBlDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjUyXSAgIGdmbjogMDAwMDVkMGYg
IG1mbjogMDAwMDVkMGYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NTJdICAgZ2ZuOiAw
MDAwNWQxMCAgbWZuOiAwMDAwNWQxMA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo1Ml0g
ICBnZm46IDAwMDA1ZDExICBtZm46IDAwMDA1ZDExDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMzOjUyXSAgIGdmbjogMDAwMDVkMTIgIG1mbjogMDAwMDVkMTINCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzM6NTJdICAgZ2ZuOiAwMDAwNWQxMyAgbWZuOiAwMDAwNWQxMw0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMzo1Ml0gICBnZm46IDAwMDA1ZDE0ICBtZm46IDAwMDA1ZDE0
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjUyXSAgIGdmbjogMDAwMDVkMTUgIG1mbjog
MDAwMDVkMTUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NTJdICAgZ2ZuOiAwMDAwNWQx
NiAgbWZuOiAwMDAwNWQxNg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo1Ml0gICBnZm46
IDAwMDA1ZDE3ICBtZm46IDAwMDA1ZDE3DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjUy
XSAgIGdmbjogMDAwMDVkMTggIG1mbjogMDAwMDVkMTgNCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzM6NTJdICAgZ2ZuOiAwMDAwNWQxOSAgbWZuOiAwMDAwNWQxOQ0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMzo1Ml0gICBnZm46IDAwMDA1ZDFhICBtZm46IDAwMDA1ZDFhDQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMzOjUyXSAgIGdmbjogMDAwMDVkMWIgIG1mbjogMDAwMDVk
MWINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NTJdICAgZ2ZuOiAwMDAwNWQxYyAgbWZu
OiAwMDAwNWQxYw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo1Ml0gICBnZm46IDAwMDA1
ZDFkICBtZm46IDAwMDA1ZDFkDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjUyXSAgIGdm
bjogMDAwMDVkMWUgIG1mbjogMDAwMDVkMWUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6
NTJdICAgZ2ZuOiAwMDAwNWQxZiAgbWZuOiAwMDAwNWQxZg0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMzo1Ml0gICBnZm46IDAwMDA1ZDIwICBtZm46IDAwMDA1ZDIwDQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMzOjUyXSAgIGdmbjogMDAwMDVkMjEgIG1mbjogMDAwMDVkMjENCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NTJdICAgZ2ZuOiAwMDAwNWQyMiAgbWZuOiAwMDAw
NWQyMg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo1Ml0gICBnZm46IDAwMDA1ZDIzICBt
Zm46IDAwMDA1ZDIzDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjUyXSAgIGdmbjogMDAw
MDVkMjQgIG1mbjogMDAwMDVkMjQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NTJdICAg
Z2ZuOiAwMDAwNWQyNSAgbWZuOiAwMDAwNWQyNQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
Mzo1Ml0gICBnZm46IDAwMDA1ZDI2ICBtZm46IDAwMDA1ZDI2DQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMzOjUyXSAgIGdmbjogMDAwMDVkMjcgIG1mbjogMDAwMDVkMjcNCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzM6NTJdICAgZ2ZuOiAwMDAwNWQyOCAgbWZuOiAwMDAwNWQyOA0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo1Ml0gICBnZm46IDAwMDA1ZDI5ICBtZm46IDAw
MDA1ZDI5DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjUyXSAgIGdmbjogMDAwMDVkMmEg
IG1mbjogMDAwMDVkMmENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NTJdICAgZ2ZuOiAw
MDAwNWQyYiAgbWZuOiAwMDAwNWQyYg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo1Ml0g
ICBnZm46IDAwMDA1ZDJjICBtZm46IDAwMDA1ZDJjDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMzOjUyXSAgIGdmbjogMDAwMDVkMmQgIG1mbjogMDAwMDVkMmQNCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzM6NTJdICAgZ2ZuOiAwMDAwNWQyZSAgbWZuOiAwMDAwNWQyZQ0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMzo1Ml0gICBnZm46IDAwMDA1ZDJmICBtZm46IDAwMDA1ZDJm
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjUyXSAgIGdmbjogMDAwMDVkMzAgIG1mbjog
MDAwMDVkMzANCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NTJdICAgZ2ZuOiAwMDAwNWQz
MSAgbWZuOiAwMDAwNWQzMQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo1Ml0gICBnZm46
IDAwMDA1ZDMyICBtZm46IDAwMDA1ZDMyDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjUy
XSAgIGdmbjogMDAwMDVkMzMgIG1mbjogMDAwMDVkMzMNCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzM6NTJdICAgZ2ZuOiAwMDAwNWQzNCAgbWZuOiAwMDAwNWQzNA0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMzo1Ml0gICBnZm46IDAwMDA1ZDM1ICBtZm46IDAwMDA1ZDM1DQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMzOjUyXSAgIGdmbjogMDAwMDVkMzYgIG1mbjogMDAwMDVk
MzYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NTJdICAgZ2ZuOiAwMDAwNWQzNyAgbWZu
OiAwMDAwNWQzNw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo1Ml0gICBnZm46IDAwMDA1
ZDM4ICBtZm46IDAwMDA1ZDM4DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjUyXSAgIGdm
bjogMDAwMDVkMzkgIG1mbjogMDAwMDVkMzkNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6
NTJdICAgZ2ZuOiAwMDAwNWQzYSAgbWZuOiAwMDAwNWQzYQ0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMzo1Ml0gICBnZm46IDAwMDA1ZDNiICBtZm46IDAwMDA1ZDNiDQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMzOjUyXSAgIGdmbjogMDAwMDVkM2MgIG1mbjogMDAwMDVkM2MNCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NTJdICAgZ2ZuOiAwMDAwNWQzZCAgbWZuOiAwMDAw
NWQzZA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo1Ml0gICBnZm46IDAwMDA1ZDNlICBt
Zm46IDAwMDA1ZDNlDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjUyXSAgIGdmbjogMDAw
MDVkM2YgIG1mbjogMDAwMDVkM2YNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NTJdICAg
Z2ZuOiAwMDAwNWQ0MCAgbWZuOiAwMDAwNWQ0MA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
Mzo1M10gICBnZm46IDAwMDA1ZDQxICBtZm46IDAwMDA1ZDQxDQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMzOjUzXSAgIGdmbjogMDAwMDVkNDIgIG1mbjogMDAwMDVkNDINCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzM6NTNdICAgZ2ZuOiAwMDAwNWQ0MyAgbWZuOiAwMDAwNWQ0Mw0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo1M10gICBnZm46IDAwMDA1ZDQ0ICBtZm46IDAw
MDA1ZDQ0DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjUzXSAgIGdmbjogMDAwMDVkNDUg
IG1mbjogMDAwMDVkNDUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NTNdICAgZ2ZuOiAw
MDAwNWQ0NiAgbWZuOiAwMDAwNWQ0Ng0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo1M10g
ICBnZm46IDAwMDA1ZDQ3ICBtZm46IDAwMDA1ZDQ3DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMzOjUzXSAgIGdmbjogMDAwMDVkNDggIG1mbjogMDAwMDVkNDgNCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzM6NTNdICAgZ2ZuOiAwMDAwNWQ0OSAgbWZuOiAwMDAwNWQ0OQ0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMzo1M10gICBnZm46IDAwMDA1ZDRhICBtZm46IDAwMDA1ZDRh
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjUzXSAgIGdmbjogMDAwMDVkNGIgIG1mbjog
MDAwMDVkNGINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NTNdICAgZ2ZuOiAwMDAwNWQ0
YyAgbWZuOiAwMDAwNWQ0Yw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo1M10gICBnZm46
IDAwMDA1ZDRkICBtZm46IDAwMDA1ZDRkDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjUz
XSAgIGdmbjogMDAwMDVkNGUgIG1mbjogMDAwMDVkNGUNCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzM6NTNdICAgZ2ZuOiAwMDAwNWQ0ZiAgbWZuOiAwMDAwNWQ0Zg0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMzo1M10gICBnZm46IDAwMDA1ZDUwICBtZm46IDAwMDA1ZDUwDQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMzOjUzXSAgIGdmbjogMDAwMDVkNTEgIG1mbjogMDAwMDVk
NTENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NTNdICAgZ2ZuOiAwMDAwNWQ1MiAgbWZu
OiAwMDAwNWQ1Mg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo1M10gICBnZm46IDAwMDA1
ZDUzICBtZm46IDAwMDA1ZDUzDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjUzXSAgIGdm
bjogMDAwMDVkNTQgIG1mbjogMDAwMDVkNTQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6
NTNdICAgZ2ZuOiAwMDAwNWQ1NSAgbWZuOiAwMDAwNWQ1NQ0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMzo1M10gICBnZm46IDAwMDA1ZDU2ICBtZm46IDAwMDA1ZDU2DQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMzOjUzXSAgIGdmbjogMDAwMDVkNTcgIG1mbjogMDAwMDVkNTcNCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NTNdICAgZ2ZuOiAwMDAwNWQ1OCAgbWZuOiAwMDAw
NWQ1OA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo1M10gICBnZm46IDAwMDA1ZDU5ICBt
Zm46IDAwMDA1ZDU5DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjUzXSAgIGdmbjogMDAw
MDVkNWEgIG1mbjogMDAwMDVkNWENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NTNdICAg
Z2ZuOiAwMDAwNWQ1YiAgbWZuOiAwMDAwNWQ1Yg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
Mzo1M10gICBnZm46IDAwMDA1ZDVjICBtZm46IDAwMDA1ZDVjDQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMzOjUzXSAgIGdmbjogMDAwMDVkNWQgIG1mbjogMDAwMDVkNWQNCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzM6NTNdICAgZ2ZuOiAwMDAwNWQ1ZSAgbWZuOiAwMDAwNWQ1ZQ0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo1M10gICBnZm46IDAwMDA1ZDVmICBtZm46IDAw
MDA1ZDVmDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjUzXSAgIGdmbjogMDAwMDVkNjAg
IG1mbjogMDAwMDVkNjANCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NTNdICAgZ2ZuOiAw
MDAwNWQ2MSAgbWZuOiAwMDAwNWQ2MQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo1M10g
ICBnZm46IDAwMDA1ZDYyICBtZm46IDAwMDA1ZDYyDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMzOjUzXSAgIGdmbjogMDAwMDVkNjMgIG1mbjogMDAwMDVkNjMNCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzM6NTNdICAgZ2ZuOiAwMDAwNWQ2NCAgbWZuOiAwMDAwNWQ2NA0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMzo1M10gICBnZm46IDAwMDA1ZDY1ICBtZm46IDAwMDA1ZDY1
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjUzXSAgIGdmbjogMDAwMDVkNjYgIG1mbjog
MDAwMDVkNjYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NTNdICAgZ2ZuOiAwMDAwNWQ2
NyAgbWZuOiAwMDAwNWQ2Nw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo1M10gICBnZm46
IDAwMDA1ZDY4ICBtZm46IDAwMDA1ZDY4DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjUz
XSAgIGdmbjogMDAwMDVkNjkgIG1mbjogMDAwMDVkNjkNCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzM6NTNdICAgZ2ZuOiAwMDAwNWQ2YSAgbWZuOiAwMDAwNWQ2YQ0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMzo1M10gICBnZm46IDAwMDA1ZDZiICBtZm46IDAwMDA1ZDZiDQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMzOjUzXSAgIGdmbjogMDAwMDVkNmMgIG1mbjogMDAwMDVk
NmMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NTNdICAgZ2ZuOiAwMDAwNWQ2ZCAgbWZu
OiAwMDAwNWQ2ZA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo1M10gICBnZm46IDAwMDA1
ZDZlICBtZm46IDAwMDA1ZDZlDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjUzXSAgIGdm
bjogMDAwMDVkNmYgIG1mbjogMDAwMDVkNmYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6
NTNdICAgZ2ZuOiAwMDAwNWQ3MCAgbWZuOiAwMDAwNWQ3MA0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMzo1M10gICBnZm46IDAwMDA1ZDcxICBtZm46IDAwMDA1ZDcxDQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMzOjUzXSAgIGdmbjogMDAwMDVkNzIgIG1mbjogMDAwMDVkNzINCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NTNdICAgZ2ZuOiAwMDAwNWQ3MyAgbWZuOiAwMDAw
NWQ3Mw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo1M10gICBnZm46IDAwMDA1ZDc0ICBt
Zm46IDAwMDA1ZDc0DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjUzXSAgIGdmbjogMDAw
MDVkNzUgIG1mbjogMDAwMDVkNzUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NTNdICAg
Z2ZuOiAwMDAwNWQ3NiAgbWZuOiAwMDAwNWQ3Ng0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
Mzo1M10gICBnZm46IDAwMDA1ZDc3ICBtZm46IDAwMDA1ZDc3DQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMzOjUzXSAgIGdmbjogMDAwMDVkNzggIG1mbjogMDAwMDVkNzgNCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzM6NTNdICAgZ2ZuOiAwMDAwNWQ3OSAgbWZuOiAwMDAwNWQ3OQ0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo1M10gICBnZm46IDAwMDA1ZDdhICBtZm46IDAw
MDA1ZDdhDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjUzXSAgIGdmbjogMDAwMDVkN2Ig
IG1mbjogMDAwMDVkN2INCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NTNdICAgZ2ZuOiAw
MDAwNWQ3YyAgbWZuOiAwMDAwNWQ3Yw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo1M10g
ICBnZm46IDAwMDA1ZDdkICBtZm46IDAwMDA1ZDdkDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMzOjUzXSAgIGdmbjogMDAwMDVkN2UgIG1mbjogMDAwMDVkN2UNCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzM6NTNdICAgZ2ZuOiAwMDAwNWQ3ZiAgbWZuOiAwMDAwNWQ3Zg0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMzo1M10gICBnZm46IDAwMDA1ZDgwICBtZm46IDAwMDA1ZDgw
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjU0XSAgIGdmbjogMDAwMDVkODEgIG1mbjog
MDAwMDVkODENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NTRdICAgZ2ZuOiAwMDAwNWQ4
MiAgbWZuOiAwMDAwNWQ4Mg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo1NF0gICBnZm46
IDAwMDA1ZDgzICBtZm46IDAwMDA1ZDgzDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjU0
XSAgIGdmbjogMDAwMDVkODQgIG1mbjogMDAwMDVkODQNCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzM6NTRdICAgZ2ZuOiAwMDAwNWQ4NSAgbWZuOiAwMDAwNWQ4NQ0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMzo1NF0gICBnZm46IDAwMDA1ZDg2ICBtZm46IDAwMDA1ZDg2DQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMzOjU0XSAgIGdmbjogMDAwMDVkODcgIG1mbjogMDAwMDVk
ODcNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NTRdICAgZ2ZuOiAwMDAwNWQ4OCAgbWZu
OiAwMDAwNWQ4OA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo1NF0gICBnZm46IDAwMDA1
ZDg5ICBtZm46IDAwMDA1ZDg5DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjU0XSAgIGdm
bjogMDAwMDVkOGEgIG1mbjogMDAwMDVkOGENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6
NTRdICAgZ2ZuOiAwMDAwNWQ4YiAgbWZuOiAwMDAwNWQ4Yg0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMzo1NF0gICBnZm46IDAwMDA1ZDhjICBtZm46IDAwMDA1ZDhjDQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMzOjU0XSAgIGdmbjogMDAwMDVkOGQgIG1mbjogMDAwMDVkOGQNCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NTRdICAgZ2ZuOiAwMDAwNWQ4ZSAgbWZuOiAwMDAw
NWQ4ZQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo1NF0gICBnZm46IDAwMDA1ZDhmICBt
Zm46IDAwMDA1ZDhmDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjU0XSAgIGdmbjogMDAw
MDVkOTAgIG1mbjogMDAwMDVkOTANCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NTRdICAg
Z2ZuOiAwMDAwNWQ5MSAgbWZuOiAwMDAwNWQ5MQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
Mzo1NF0gICBnZm46IDAwMDA1ZDkyICBtZm46IDAwMDA1ZDkyDQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMzOjU0XSAgIGdmbjogMDAwMDVkOTMgIG1mbjogMDAwMDVkOTMNCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzM6NTRdICAgZ2ZuOiAwMDAwNWQ5NCAgbWZuOiAwMDAwNWQ5NA0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo1NF0gICBnZm46IDAwMDA1ZDk1ICBtZm46IDAw
MDA1ZDk1DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjU0XSAgIGdmbjogMDAwMDVkOTYg
IG1mbjogMDAwMDVkOTYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NTRdICAgZ2ZuOiAw
MDAwNWQ5NyAgbWZuOiAwMDAwNWQ5Nw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo1NF0g
ICBnZm46IDAwMDA1ZDk4ICBtZm46IDAwMDA1ZDk4DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMzOjU0XSAgIGdmbjogMDAwMDVkOTkgIG1mbjogMDAwMDVkOTkNCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzM6NTRdICAgZ2ZuOiAwMDAwNWQ5YSAgbWZuOiAwMDAwNWQ5YQ0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMzo1NF0gICBnZm46IDAwMDA1ZDliICBtZm46IDAwMDA1ZDli
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjU0XSAgIGdmbjogMDAwMDVkOWMgIG1mbjog
MDAwMDVkOWMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NTRdICAgZ2ZuOiAwMDAwNWQ5
ZCAgbWZuOiAwMDAwNWQ5ZA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo1NF0gICBnZm46
IDAwMDA1ZDllICBtZm46IDAwMDA1ZDllDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjU0
XSAgIGdmbjogMDAwMDVkOWYgIG1mbjogMDAwMDVkOWYNCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzM6NTRdICAgZ2ZuOiAwMDAwNWRhMCAgbWZuOiAwMDAwNWRhMA0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMzo1NF0gICBnZm46IDAwMDA1ZGExICBtZm46IDAwMDA1ZGExDQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMzOjU0XSAgIGdmbjogMDAwMDVkYTIgIG1mbjogMDAwMDVk
YTINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NTRdICAgZ2ZuOiAwMDAwNWRhMyAgbWZu
OiAwMDAwNWRhMw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo1NF0gICBnZm46IDAwMDA1
ZGE0ICBtZm46IDAwMDA1ZGE0DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjU0XSAgIGdm
bjogMDAwMDVkYTUgIG1mbjogMDAwMDVkYTUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6
NTRdICAgZ2ZuOiAwMDAwNWRhNiAgbWZuOiAwMDAwNWRhNg0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMzo1NF0gICBnZm46IDAwMDA1ZGE3ICBtZm46IDAwMDA1ZGE3DQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMzOjU0XSAgIGdmbjogMDAwMDVkYTggIG1mbjogMDAwMDVkYTgNCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NTRdICAgZ2ZuOiAwMDAwNWRhOSAgbWZuOiAwMDAw
NWRhOQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo1NF0gICBnZm46IDAwMDA1ZGFhICBt
Zm46IDAwMDA1ZGFhDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjU0XSAgIGdmbjogMDAw
MDVkYWIgIG1mbjogMDAwMDVkYWINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NTRdICAg
Z2ZuOiAwMDAwNWRhYyAgbWZuOiAwMDAwNWRhYw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
Mzo1NF0gICBnZm46IDAwMDA1ZGFkICBtZm46IDAwMDA1ZGFkDQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMzOjU0XSAgIGdmbjogMDAwMDVkYWUgIG1mbjogMDAwMDVkYWUNCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzM6NTRdICAgZ2ZuOiAwMDAwNWRhZiAgbWZuOiAwMDAwNWRhZg0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo1NF0gICBnZm46IDAwMDA1ZGIwICBtZm46IDAw
MDA1ZGIwDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjU0XSAgIGdmbjogMDAwMDVkYjEg
IG1mbjogMDAwMDVkYjENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NTRdICAgZ2ZuOiAw
MDAwNWRiMiAgbWZuOiAwMDAwNWRiMg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo1NF0g
ICBnZm46IDAwMDA1ZGIzICBtZm46IDAwMDA1ZGIzDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMzOjU0XSAgIGdmbjogMDAwMDVkYjQgIG1mbjogMDAwMDVkYjQNCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzM6NTRdICAgZ2ZuOiAwMDAwNWRiNSAgbWZuOiAwMDAwNWRiNQ0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMzo1NF0gICBnZm46IDAwMDA1ZGI2ICBtZm46IDAwMDA1ZGI2
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjU0XSAgIGdmbjogMDAwMDVkYjcgIG1mbjog
MDAwMDVkYjcNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NTRdICAgZ2ZuOiAwMDAwNWRi
OCAgbWZuOiAwMDAwNWRiOA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo1NF0gICBnZm46
IDAwMDA1ZGI5ICBtZm46IDAwMDA1ZGI5DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjU0
XSAgIGdmbjogMDAwMDVkYmEgIG1mbjogMDAwMDVkYmENCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzM6NTRdICAgZ2ZuOiAwMDAwNWRiYiAgbWZuOiAwMDAwNWRiYg0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMzo1NF0gICBnZm46IDAwMDA1ZGJjICBtZm46IDAwMDA1ZGJjDQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMzOjU0XSAgIGdmbjogMDAwMDVkYmQgIG1mbjogMDAwMDVk
YmQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NTRdICAgZ2ZuOiAwMDAwNWRiZSAgbWZu
OiAwMDAwNWRiZQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo1NF0gICBnZm46IDAwMDA1
ZGJmICBtZm46IDAwMDA1ZGJmDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjU0XSAgIGdm
bjogMDAwMDVkYzAgIG1mbjogMDAwMDVkYzANCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6
NTVdICAgZ2ZuOiAwMDAwNWRjMSAgbWZuOiAwMDAwNWRjMQ0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMzo1NV0gICBnZm46IDAwMDA1ZGMyICBtZm46IDAwMDA1ZGMyDQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMzOjU1XSAgIGdmbjogMDAwMDVkYzMgIG1mbjogMDAwMDVkYzMNCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NTVdICAgZ2ZuOiAwMDAwNWRjNCAgbWZuOiAwMDAw
NWRjNA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo1NV0gICBnZm46IDAwMDA1ZGM1ICBt
Zm46IDAwMDA1ZGM1DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjU1XSAgIGdmbjogMDAw
MDVkYzYgIG1mbjogMDAwMDVkYzYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NTVdICAg
Z2ZuOiAwMDAwNWRjNyAgbWZuOiAwMDAwNWRjNw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
Mzo1NV0gICBnZm46IDAwMDA1ZGM4ICBtZm46IDAwMDA1ZGM4DQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMzOjU1XSAgIGdmbjogMDAwMDVkYzkgIG1mbjogMDAwMDVkYzkNCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzM6NTVdICAgZ2ZuOiAwMDAwNWRjYSAgbWZuOiAwMDAwNWRjYQ0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo1NV0gICBnZm46IDAwMDA1ZGNiICBtZm46IDAw
MDA1ZGNiDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjU1XSAgIGdmbjogMDAwMDVkY2Mg
IG1mbjogMDAwMDVkY2MNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NTVdICAgZ2ZuOiAw
MDAwNWRjZCAgbWZuOiAwMDAwNWRjZA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo1NV0g
ICBnZm46IDAwMDA1ZGNlICBtZm46IDAwMDA1ZGNlDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMzOjU1XSAgIGdmbjogMDAwMDVkY2YgIG1mbjogMDAwMDVkY2YNCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzM6NTVdICAgZ2ZuOiAwMDAwNWRkMCAgbWZuOiAwMDAwNWRkMA0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMzo1NV0gICBnZm46IDAwMDA1ZGQxICBtZm46IDAwMDA1ZGQx
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjU1XSAgIGdmbjogMDAwMDVkZDIgIG1mbjog
MDAwMDVkZDINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NTVdICAgZ2ZuOiAwMDAwNWRk
MyAgbWZuOiAwMDAwNWRkMw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo1NV0gICBnZm46
IDAwMDA1ZGQ0ICBtZm46IDAwMDA1ZGQ0DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjU1
XSAgIGdmbjogMDAwMDVkZDUgIG1mbjogMDAwMDVkZDUNCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzM6NTVdICAgZ2ZuOiAwMDAwNWRkNiAgbWZuOiAwMDAwNWRkNg0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMzo1NV0gICBnZm46IDAwMDA1ZGQ3ICBtZm46IDAwMDA1ZGQ3DQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMzOjU1XSAgIGdmbjogMDAwMDVkZDggIG1mbjogMDAwMDVk
ZDgNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NTVdICAgZ2ZuOiAwMDAwNWRkOSAgbWZu
OiAwMDAwNWRkOQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo1NV0gICBnZm46IDAwMDA1
ZGRhICBtZm46IDAwMDA1ZGRhDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjU1XSAgIGdm
bjogMDAwMDVkZGIgIG1mbjogMDAwMDVkZGINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6
NTVdICAgZ2ZuOiAwMDAwNWRkYyAgbWZuOiAwMDAwNWRkYw0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMzo1NV0gICBnZm46IDAwMDA1ZGRkICBtZm46IDAwMDA1ZGRkDQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMzOjU1XSAgIGdmbjogMDAwMDVkZGUgIG1mbjogMDAwMDVkZGUNCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NTVdICAgZ2ZuOiAwMDAwNWRkZiAgbWZuOiAwMDAw
NWRkZg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo1NV0gICBnZm46IDAwMDA1ZGUwICBt
Zm46IDAwMDA1ZGUwDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjU1XSAgIGdmbjogMDAw
MDVkZTEgIG1mbjogMDAwMDVkZTENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NTVdICAg
Z2ZuOiAwMDAwNWRlMiAgbWZuOiAwMDAwNWRlMg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
Mzo1NV0gICBnZm46IDAwMDA1ZGUzICBtZm46IDAwMDA1ZGUzDQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMzOjU1XSAgIGdmbjogMDAwMDVkZTQgIG1mbjogMDAwMDVkZTQNCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzM6NTVdICAgZ2ZuOiAwMDAwNWRlNSAgbWZuOiAwMDAwNWRlNQ0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo1NV0gICBnZm46IDAwMDA1ZGU2ICBtZm46IDAw
MDA1ZGU2DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjU1XSAgIGdmbjogMDAwMDVkZTcg
IG1mbjogMDAwMDVkZTcNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NTVdICAgZ2ZuOiAw
MDAwNWRlOCAgbWZuOiAwMDAwNWRlOA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo1NV0g
ICBnZm46IDAwMDA1ZGU5ICBtZm46IDAwMDA1ZGU5DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMzOjU1XSAgIGdmbjogMDAwMDVkZWEgIG1mbjogMDAwMDVkZWENCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzM6NTVdICAgZ2ZuOiAwMDAwNWRlYiAgbWZuOiAwMDAwNWRlYg0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMzo1NV0gICBnZm46IDAwMDA1ZGVjICBtZm46IDAwMDA1ZGVj
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjU1XSAgIGdmbjogMDAwMDVkZWQgIG1mbjog
MDAwMDVkZWQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NTVdICAgZ2ZuOiAwMDAwNWRl
ZSAgbWZuOiAwMDAwNWRlZQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo1NV0gICBnZm46
IDAwMDA1ZGVmICBtZm46IDAwMDA1ZGVmDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjU1
XSAgIGdmbjogMDAwMDVkZjAgIG1mbjogMDAwMDVkZjANCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzM6NTVdICAgZ2ZuOiAwMDAwNWRmMSAgbWZuOiAwMDAwNWRmMQ0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMzo1NV0gICBnZm46IDAwMDA1ZGYyICBtZm46IDAwMDA1ZGYyDQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMzOjU1XSAgIGdmbjogMDAwMDVkZjMgIG1mbjogMDAwMDVk
ZjMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NTVdICAgZ2ZuOiAwMDAwNWRmNCAgbWZu
OiAwMDAwNWRmNA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo1NV0gICBnZm46IDAwMDA1
ZGY1ICBtZm46IDAwMDA1ZGY1DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjU1XSAgIGdm
bjogMDAwMDVkZjYgIG1mbjogMDAwMDVkZjYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6
NTVdICAgZ2ZuOiAwMDAwNWRmNyAgbWZuOiAwMDAwNWRmNw0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMzo1NV0gICBnZm46IDAwMDA1ZGY4ICBtZm46IDAwMDA1ZGY4DQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMzOjU1XSAgIGdmbjogMDAwMDVkZjkgIG1mbjogMDAwMDVkZjkNCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NTVdICAgZ2ZuOiAwMDAwNWRmYSAgbWZuOiAwMDAw
NWRmYQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo1NV0gICBnZm46IDAwMDA1ZGZiICBt
Zm46IDAwMDA1ZGZiDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjU1XSAgIGdmbjogMDAw
MDVkZmMgIG1mbjogMDAwMDVkZmMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NTVdICAg
Z2ZuOiAwMDAwNWRmZCAgbWZuOiAwMDAwNWRmZA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
Mzo1NV0gICBnZm46IDAwMDA1ZGZlICBtZm46IDAwMDA1ZGZlDQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMzOjU1XSAgIGdmbjogMDAwMDVkZmYgIG1mbjogMDAwMDVkZmYNCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzM6NTVdICAgZ2ZuOiAwMDAwNWUwMCAgbWZuOiAwMDAwNWUwMA0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo1Nl0gICBnZm46IDAwMDA1ZTAxICBtZm46IDAw
MDA1ZTAxDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjU2XSAgIGdmbjogMDAwMDVlMDIg
IG1mbjogMDAwMDVlMDINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NTZdICAgZ2ZuOiAw
MDAwNWUwMyAgbWZuOiAwMDAwNWUwMw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo1Nl0g
ICBnZm46IDAwMDA1ZTA0ICBtZm46IDAwMDA1ZTA0DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMzOjU2XSAgIGdmbjogMDAwMDVlMDUgIG1mbjogMDAwMDVlMDUNCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzM6NTZdICAgZ2ZuOiAwMDAwNWUwNiAgbWZuOiAwMDAwNWUwNg0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMzo1Nl0gICBnZm46IDAwMDA1ZTA3ICBtZm46IDAwMDA1ZTA3
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjU2XSAgIGdmbjogMDAwMDVlMDggIG1mbjog
MDAwMDVlMDgNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NTZdICAgZ2ZuOiAwMDAwNWUw
OSAgbWZuOiAwMDAwNWUwOQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo1Nl0gICBnZm46
IDAwMDA1ZTBhICBtZm46IDAwMDA1ZTBhDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjU2
XSAgIGdmbjogMDAwMDVlMGIgIG1mbjogMDAwMDVlMGINCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzM6NTZdICAgZ2ZuOiAwMDAwNWUwYyAgbWZuOiAwMDAwNWUwYw0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMzo1Nl0gICBnZm46IDAwMDA1ZTBkICBtZm46IDAwMDA1ZTBkDQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMzOjU2XSAgIGdmbjogMDAwMDVlMGUgIG1mbjogMDAwMDVl
MGUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NTZdICAgZ2ZuOiAwMDAwNWUwZiAgbWZu
OiAwMDAwNWUwZg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo1Nl0gICBnZm46IDAwMDA1
ZTEwICBtZm46IDAwMDA1ZTEwDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjU2XSAgIGdm
bjogMDAwMDVlMTEgIG1mbjogMDAwMDVlMTENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6
NTZdICAgZ2ZuOiAwMDAwNWUxMiAgbWZuOiAwMDAwNWUxMg0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMzo1Nl0gICBnZm46IDAwMDA1ZTEzICBtZm46IDAwMDA1ZTEzDQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMzOjU2XSAgIGdmbjogMDAwMDVlMTQgIG1mbjogMDAwMDVlMTQNCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NTZdICAgZ2ZuOiAwMDAwNWUxNSAgbWZuOiAwMDAw
NWUxNQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo1Nl0gICBnZm46IDAwMDA1ZTE2ICBt
Zm46IDAwMDA1ZTE2DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjU2XSAgIGdmbjogMDAw
MDVlMTcgIG1mbjogMDAwMDVlMTcNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NTZdICAg
Z2ZuOiAwMDAwNWUxOCAgbWZuOiAwMDAwNWUxOA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
Mzo1Nl0gICBnZm46IDAwMDA1ZTE5ICBtZm46IDAwMDA1ZTE5DQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMzOjU2XSAgIGdmbjogMDAwMDVlMWEgIG1mbjogMDAwMDVlMWENCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzM6NTZdICAgZ2ZuOiAwMDAwNWUxYiAgbWZuOiAwMDAwNWUxYg0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo1Nl0gICBnZm46IDAwMDA1ZTFjICBtZm46IDAw
MDA1ZTFjDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjU2XSAgIGdmbjogMDAwMDVlMWQg
IG1mbjogMDAwMDVlMWQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NTZdICAgZ2ZuOiAw
MDAwNWUxZSAgbWZuOiAwMDAwNWUxZQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo1Nl0g
ICBnZm46IDAwMDA1ZTFmICBtZm46IDAwMDA1ZTFmDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMzOjU2XSAgIGdmbjogMDAwMDVlMjAgIG1mbjogMDAwMDVlMjANCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzM6NTZdICAgZ2ZuOiAwMDAwNWUyMSAgbWZuOiAwMDAwNWUyMQ0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMzo1Nl0gICBnZm46IDAwMDA1ZTIyICBtZm46IDAwMDA1ZTIy
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjU2XSAgIGdmbjogMDAwMDVlMjMgIG1mbjog
MDAwMDVlMjMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NTZdICAgZ2ZuOiAwMDAwNWUy
NCAgbWZuOiAwMDAwNWUyNA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo1Nl0gICBnZm46
IDAwMDA1ZTI1ICBtZm46IDAwMDA1ZTI1DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjU2
XSAgIGdmbjogMDAwMDVlMjYgIG1mbjogMDAwMDVlMjYNCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzM6NTZdICAgZ2ZuOiAwMDAwNWUyNyAgbWZuOiAwMDAwNWUyNw0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMzo1Nl0gICBnZm46IDAwMDA1ZTI4ICBtZm46IDAwMDA1ZTI4DQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMzOjU2XSAgIGdmbjogMDAwMDVlMjkgIG1mbjogMDAwMDVl
MjkNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NTZdICAgZ2ZuOiAwMDAwNWUyYSAgbWZu
OiAwMDAwNWUyYQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo1Nl0gICBnZm46IDAwMDA1
ZTJiICBtZm46IDAwMDA1ZTJiDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjU2XSAgIGdm
bjogMDAwMDVlMmMgIG1mbjogMDAwMDVlMmMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6
NTZdICAgZ2ZuOiAwMDAwNWUyZCAgbWZuOiAwMDAwNWUyZA0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMzo1Nl0gICBnZm46IDAwMDA1ZTJlICBtZm46IDAwMDA1ZTJlDQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMzOjU2XSAgIGdmbjogMDAwMDVlMmYgIG1mbjogMDAwMDVlMmYNCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NTZdICAgZ2ZuOiAwMDAwNWUzMCAgbWZuOiAwMDAw
NWUzMA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo1Nl0gICBnZm46IDAwMDA1ZTMxICBt
Zm46IDAwMDA1ZTMxDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjU2XSAgIGdmbjogMDAw
MDVlMzIgIG1mbjogMDAwMDVlMzINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NTZdICAg
Z2ZuOiAwMDAwNWUzMyAgbWZuOiAwMDAwNWUzMw0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
Mzo1Nl0gICBnZm46IDAwMDA1ZTM0ICBtZm46IDAwMDA1ZTM0DQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMzOjU2XSAgIGdmbjogMDAwMDVlMzUgIG1mbjogMDAwMDVlMzUNCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzM6NTZdICAgZ2ZuOiAwMDAwNWUzNiAgbWZuOiAwMDAwNWUzNg0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo1Nl0gICBnZm46IDAwMDA1ZTM3ICBtZm46IDAw
MDA1ZTM3DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjU2XSAgIGdmbjogMDAwMDVlMzgg
IG1mbjogMDAwMDVlMzgNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NTZdICAgZ2ZuOiAw
MDAwNWUzOSAgbWZuOiAwMDAwNWUzOQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo1Nl0g
ICBnZm46IDAwMDA1ZTNhICBtZm46IDAwMDA1ZTNhDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMzOjU2XSAgIGdmbjogMDAwMDVlM2IgIG1mbjogMDAwMDVlM2INCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzM6NTZdICAgZ2ZuOiAwMDAwNWUzYyAgbWZuOiAwMDAwNWUzYw0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMzo1Nl0gICBnZm46IDAwMDA1ZTNkICBtZm46IDAwMDA1ZTNk
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjU2XSAgIGdmbjogMDAwMDVlM2UgIG1mbjog
MDAwMDVlM2UNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NTZdICAgZ2ZuOiAwMDAwNWUz
ZiAgbWZuOiAwMDAwNWUzZg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo1Nl0gICBnZm46
IDAwMDA1ZTQwICBtZm46IDAwMDA1ZTQwDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjU2
XSAgIGdmbjogMDAwMDVlNDEgIG1mbjogMDAwMDVlNDENCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzM6NTddICAgZ2ZuOiAwMDAwNWU0MiAgbWZuOiAwMDAwNWU0Mg0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMzo1N10gICBnZm46IDAwMDA1ZTQzICBtZm46IDAwMDA1ZTQzDQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMzOjU3XSAgIGdmbjogMDAwMDVlNDQgIG1mbjogMDAwMDVl
NDQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NTddICAgZ2ZuOiAwMDAwNWU0NSAgbWZu
OiAwMDAwNWU0NQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo1N10gICBnZm46IDAwMDA1
ZTQ2ICBtZm46IDAwMDA1ZTQ2DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjU3XSAgIGdm
bjogMDAwMDVlNDcgIG1mbjogMDAwMDVlNDcNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6
NTddICAgZ2ZuOiAwMDAwNWU0OCAgbWZuOiAwMDAwNWU0OA0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMzo1N10gICBnZm46IDAwMDA1ZTQ5ICBtZm46IDAwMDA1ZTQ5DQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMzOjU3XSAgIGdmbjogMDAwMDVlNGEgIG1mbjogMDAwMDVlNGENCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NTddICAgZ2ZuOiAwMDAwNWU0YiAgbWZuOiAwMDAw
NWU0Yg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo1N10gICBnZm46IDAwMDA1ZTRjICBt
Zm46IDAwMDA1ZTRjDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjU3XSAgIGdmbjogMDAw
MDVlNGQgIG1mbjogMDAwMDVlNGQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NTddICAg
Z2ZuOiAwMDAwNWU0ZSAgbWZuOiAwMDAwNWU0ZQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
Mzo1N10gICBnZm46IDAwMDA1ZTRmICBtZm46IDAwMDA1ZTRmDQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMzOjU3XSAgIGdmbjogMDAwMDVlNTAgIG1mbjogMDAwMDVlNTANCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzM6NTddICAgZ2ZuOiAwMDAwNWU1MSAgbWZuOiAwMDAwNWU1MQ0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo1N10gICBnZm46IDAwMDA1ZTUyICBtZm46IDAw
MDA1ZTUyDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjU3XSAgIGdmbjogMDAwMDVlNTMg
IG1mbjogMDAwMDVlNTMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NTddICAgZ2ZuOiAw
MDAwNWU1NCAgbWZuOiAwMDAwNWU1NA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo1N10g
ICBnZm46IDAwMDA1ZTU1ICBtZm46IDAwMDA1ZTU1DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMzOjU3XSAgIGdmbjogMDAwMDVlNTYgIG1mbjogMDAwMDVlNTYNCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzM6NTddICAgZ2ZuOiAwMDAwNWU1NyAgbWZuOiAwMDAwNWU1Nw0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMzo1N10gICBnZm46IDAwMDA1ZTU4ICBtZm46IDAwMDA1ZTU4
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjU3XSAgIGdmbjogMDAwMDVlNTkgIG1mbjog
MDAwMDVlNTkNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NTddICAgZ2ZuOiAwMDAwNWU1
YSAgbWZuOiAwMDAwNWU1YQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo1N10gICBnZm46
IDAwMDA1ZTViICBtZm46IDAwMDA1ZTViDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjU3
XSAgIGdmbjogMDAwMDVlNWMgIG1mbjogMDAwMDVlNWMNCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzM6NTddICAgZ2ZuOiAwMDAwNWU1ZCAgbWZuOiAwMDAwNWU1ZA0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMzo1N10gICBnZm46IDAwMDA1ZTVlICBtZm46IDAwMDA1ZTVlDQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMzOjU3XSAgIGdmbjogMDAwMDVlNWYgIG1mbjogMDAwMDVl
NWYNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NTddICAgZ2ZuOiAwMDAwNWU2MCAgbWZu
OiAwMDAwNWU2MA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo1N10gICBnZm46IDAwMDA1
ZTYxICBtZm46IDAwMDA1ZTYxDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjU3XSAgIGdm
bjogMDAwMDVlNjIgIG1mbjogMDAwMDVlNjINCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6
NTddICAgZ2ZuOiAwMDAwNWU2MyAgbWZuOiAwMDAwNWU2Mw0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMzo1N10gICBnZm46IDAwMDA1ZTY0ICBtZm46IDAwMDA1ZTY0DQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMzOjU3XSAgIGdmbjogMDAwMDVlNjUgIG1mbjogMDAwMDVlNjUNCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NTddICAgZ2ZuOiAwMDAwNWU2NiAgbWZuOiAwMDAw
NWU2Ng0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo1N10gICBnZm46IDAwMDA1ZTY3ICBt
Zm46IDAwMDA1ZTY3DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjU3XSAgIGdmbjogMDAw
MDVlNjggIG1mbjogMDAwMDVlNjgNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NTddICAg
Z2ZuOiAwMDAwNWU2OSAgbWZuOiAwMDAwNWU2OQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
Mzo1N10gICBnZm46IDAwMDA1ZTZhICBtZm46IDAwMDA1ZTZhDQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMzOjU3XSAgIGdmbjogMDAwMDVlNmIgIG1mbjogMDAwMDVlNmINCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzM6NTddICAgZ2ZuOiAwMDAwNWU2YyAgbWZuOiAwMDAwNWU2Yw0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo1N10gICBnZm46IDAwMDA1ZTZkICBtZm46IDAw
MDA1ZTZkDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjU3XSAgIGdmbjogMDAwMDVlNmUg
IG1mbjogMDAwMDVlNmUNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NTddICAgZ2ZuOiAw
MDAwNWU2ZiAgbWZuOiAwMDAwNWU2Zg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo1N10g
ICBnZm46IDAwMDA1ZTcwICBtZm46IDAwMDA1ZTcwDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIx
OjMzOjU3XSAgIGdmbjogMDAwMDVlNzEgIG1mbjogMDAwMDVlNzENCg0KKFhFTikgWzIwMTIt
MDgtMzEgMjE6MzM6NTddICAgZ2ZuOiAwMDAwNWU3MiAgbWZuOiAwMDAwNWU3Mg0KDQooWEVO
KSBbMjAxMi0wOC0zMSAyMTozMzo1N10gICBnZm46IDAwMDA1ZTczICBtZm46IDAwMDA1ZTcz
DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjU3XSAgIGdmbjogMDAwMDVlNzQgIG1mbjog
MDAwMDVlNzQNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NTddICAgZ2ZuOiAwMDAwNWU3
NSAgbWZuOiAwMDAwNWU3NQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo1N10gICBnZm46
IDAwMDA1ZTc2ICBtZm46IDAwMDA1ZTc2DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjU3
XSAgIGdmbjogMDAwMDVlNzcgIG1mbjogMDAwMDVlNzcNCg0KKFhFTikgWzIwMTItMDgtMzEg
MjE6MzM6NTddICAgZ2ZuOiAwMDAwNWU3OCAgbWZuOiAwMDAwNWU3OA0KDQooWEVOKSBbMjAx
Mi0wOC0zMSAyMTozMzo1N10gICBnZm46IDAwMDA1ZTc5ICBtZm46IDAwMDA1ZTc5DQoNCihY
RU4pIFsyMDEyLTA4LTMxIDIxOjMzOjU3XSAgIGdmbjogMDAwMDVlN2EgIG1mbjogMDAwMDVl
N2ENCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NTddICAgZ2ZuOiAwMDAwNWU3YiAgbWZu
OiAwMDAwNWU3Yg0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo1N10gICBnZm46IDAwMDA1
ZTdjICBtZm46IDAwMDA1ZTdjDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjU3XSAgIGdm
bjogMDAwMDVlN2QgIG1mbjogMDAwMDVlN2QNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6
NTddICAgZ2ZuOiAwMDAwNWU3ZSAgbWZuOiAwMDAwNWU3ZQ0KDQooWEVOKSBbMjAxMi0wOC0z
MSAyMTozMzo1N10gICBnZm46IDAwMDA1ZTdmICBtZm46IDAwMDA1ZTdmDQoNCihYRU4pIFsy
MDEyLTA4LTMxIDIxOjMzOjU3XSAgIGdmbjogMDAwMDVlODAgIG1mbjogMDAwMDVlODANCg0K
KFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NTddICAgZ2ZuOiAwMDAwNWU4MSAgbWZuOiAwMDAw
NWU4MQ0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo1OF0gICBnZm46IDAwMDA1ZTgyICBt
Zm46IDAwMDA1ZTgyDQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjU4XSAgIGdmbjogMDAw
MDVlODMgIG1mbjogMDAwMDVlODMNCg0KKFhFTikgWzIwMTItMDgtMzEgMjE6MzM6NThdICAg
Z2ZuOiAwMDAwNWU4NCAgbWZuOiAwMDAwNWU4NA0KDQooWEVOKSBbMjAxMi0wOC0zMSAyMToz
Mzo1OF0gICBnZm46IDAwMDA1ZTg1ICBtZm46IDAwMDA1ZTg1DQoNCihYRU4pIFsyMDEyLTA4
LTMxIDIxOjMzOjU4XSAgIGdmbjogMDAwMDVlODYgIG1mbjogMDAwMDVlODYNCg0KKFhFTikg
WzIwMTItMDgtMzEgMjE6MzM6NThdICAgZ2ZuOiAwMDAwNWU4NyAgbWZuOiAwMDAwNWU4Nw0K
DQooWEVOKSBbMjAxMi0wOC0zMSAyMTozMzo1OF0gICBnZm46IDAwMDA1ZTg4ICBtZm46IDAw
MDA1ZTg4DQoNCihYRU4pIFsyMDEyLTA4LTMxIDIxOjMzOjU4XSAgIGdmbjogMDAwMDVlODkg
IG1mbjogMDAwMDVlODk=
------------03F05B075321531C3
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

------------03F05B075321531C3--



From xen-devel-bounces@lists.xen.org Sat Sep 01 05:49:25 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 01 Sep 2012 05: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 1T7gZe-0006IS-DO; Sat, 01 Sep 2012 05:48:50 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <rjw@sisk.pl>)
	id 1T7gZc-0006IN-9n
	for xen-devel@lists.xensource.com; Sat, 01 Sep 2012 05:48:48 +0000
Received: from [85.158.138.51:30366] by server-5.bemta-3.messagelabs.com id
	AC/CB-13133-FB1A1405; Sat, 01 Sep 2012 05:48:47 +0000
X-Env-Sender: rjw@sisk.pl
X-Msg-Ref: server-11.tower-174.messagelabs.com!1346478526!28014473!1
X-Originating-IP: [193.178.161.156]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8783 invoked from network); 1 Sep 2012 05:48:46 -0000
Received: from ogre.sisk.pl (HELO ogre.sisk.pl) (193.178.161.156)
	by server-11.tower-174.messagelabs.com with SMTP;
	1 Sep 2012 05:48:46 -0000
Received: from localhost (localhost.localdomain [127.0.0.1])
	by ogre.sisk.pl (Postfix) with ESMTP id DA7E21D3CCF;
	Sat,  1 Sep 2012 07:51:44 +0200 (CEST)
Received: from ogre.sisk.pl ([127.0.0.1])
	by localhost (ogre.sisk.pl [127.0.0.1]) (amavisd-new,
	port 10024) with ESMTP
	id 09501-02; Sat,  1 Sep 2012 07:51:34 +0200 (CEST)
Received: from ferrari.rjw.lan (0127ahost2.starwoodbroadband.com
	[12.105.246.2])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by ogre.sisk.pl (Postfix) with ESMTP id 9E8ED1D34D1;
	Sat,  1 Sep 2012 07:51:34 +0200 (CEST)
From: "Rafael J. Wysocki" <rjw@sisk.pl>
To: Daniel Lezcano <daniel.lezcano@linaro.org>
Date: Sat, 1 Sep 2012 07:54:58 +0200
User-Agent: KMail/1.13.6 (Linux/3.6.0-rc3+; KDE/4.6.0; x86_64; ; )
References: <1343164349-28550-1-git-send-email-daniel.lezcano@linaro.org>
	<20120724210629.GA1149@phenom.dumpdata.com>
	<50410811.70500@linaro.org>
In-Reply-To: <50410811.70500@linaro.org>
MIME-Version: 1.0
Message-Id: <201209010754.58999.rjw@sisk.pl>
X-Virus-Scanned: amavisd-new at ogre.sisk.pl using MkS_Vir for Linux
Cc: xen-devel@lists.xensource.com, linaro-dev@lists.linaro.org,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	linux-pm@vger.kernel.org, patches@linaro.org,
	linux-acpi@vger.kernel.org, lenb@kernel.org
Subject: Re: [Xen-devel] [PATCH] acpi : remove power from acpi_processor_cx
	structure
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Friday, August 31, 2012, Daniel Lezcano wrote:
> On 07/24/2012 11:06 PM, Konrad Rzeszutek Wilk wrote:
> > On Tue, Jul 24, 2012 at 11:12:29PM +0200, Daniel Lezcano wrote:
> >> Remove the power field as it is not used.
> >>
> >> Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
> >> Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> > Acked.
> 
> Hi Rafael,
> 
> I did not see this patch going in. Is it possible to merge it ?

I think so.  I'll take care of it when I get back from LinuxCon/Plumbers Conf.
(early next week).

Thanks,
Rafael


> >> ---
> >>  drivers/acpi/processor_idle.c    |    2 --
> >>  drivers/xen/xen-acpi-processor.c |    1 -
> >>  include/acpi/processor.h         |    1 -
> >>  3 files changed, 0 insertions(+), 4 deletions(-)
> >>
> >> diff --git a/drivers/acpi/processor_idle.c b/drivers/acpi/processor_idle.c
> >> index e589c19..90582fb 100644
> >> --- a/drivers/acpi/processor_idle.c
> >> +++ b/drivers/acpi/processor_idle.c
> >> @@ -483,8 +483,6 @@ static int acpi_processor_get_power_info_cst(struct acpi_processor *pr)
> >>  		if (obj->type != ACPI_TYPE_INTEGER)
> >>  			continue;
> >>  
> >> -		cx.power = obj->integer.value;
> >> -
> >>  		current_count++;
> >>  		memcpy(&(pr->power.states[current_count]), &cx, sizeof(cx));
> >>  
> >> diff --git a/drivers/xen/xen-acpi-processor.c b/drivers/xen/xen-acpi-processor.c
> >> index 7ff2569..7ef9c1d 100644
> >> --- a/drivers/xen/xen-acpi-processor.c
> >> +++ b/drivers/xen/xen-acpi-processor.c
> >> @@ -98,7 +98,6 @@ static int push_cxx_to_hypervisor(struct acpi_processor *_pr)
> >>  
> >>  		dst_cx->type = cx->type;
> >>  		dst_cx->latency = cx->latency;
> >> -		dst_cx->power = cx->power;
> >>  
> >>  		dst_cx->dpcnt = 0;
> >>  		set_xen_guest_handle(dst_cx->dp, NULL);
> >> diff --git a/include/acpi/processor.h b/include/acpi/processor.h
> >> index 64ec644..db427fa 100644
> >> --- a/include/acpi/processor.h
> >> +++ b/include/acpi/processor.h
> >> @@ -59,7 +59,6 @@ struct acpi_processor_cx {
> >>  	u8 entry_method;
> >>  	u8 index;
> >>  	u32 latency;
> >> -	u32 power;
> >>  	u8 bm_sts_skip;
> >>  	char desc[ACPI_CX_DESC_LEN];
> >>  };
> > _______________________________________________
> > linaro-dev mailing list
> > linaro-dev@lists.linaro.org
> > http://lists.linaro.org/mailman/listinfo/linaro-dev
> >
> 
> 
> 


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

From xen-devel-bounces@lists.xen.org Sat Sep 01 05:49:25 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 01 Sep 2012 05: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 1T7gZe-0006IS-DO; Sat, 01 Sep 2012 05:48:50 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <rjw@sisk.pl>)
	id 1T7gZc-0006IN-9n
	for xen-devel@lists.xensource.com; Sat, 01 Sep 2012 05:48:48 +0000
Received: from [85.158.138.51:30366] by server-5.bemta-3.messagelabs.com id
	AC/CB-13133-FB1A1405; Sat, 01 Sep 2012 05:48:47 +0000
X-Env-Sender: rjw@sisk.pl
X-Msg-Ref: server-11.tower-174.messagelabs.com!1346478526!28014473!1
X-Originating-IP: [193.178.161.156]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8783 invoked from network); 1 Sep 2012 05:48:46 -0000
Received: from ogre.sisk.pl (HELO ogre.sisk.pl) (193.178.161.156)
	by server-11.tower-174.messagelabs.com with SMTP;
	1 Sep 2012 05:48:46 -0000
Received: from localhost (localhost.localdomain [127.0.0.1])
	by ogre.sisk.pl (Postfix) with ESMTP id DA7E21D3CCF;
	Sat,  1 Sep 2012 07:51:44 +0200 (CEST)
Received: from ogre.sisk.pl ([127.0.0.1])
	by localhost (ogre.sisk.pl [127.0.0.1]) (amavisd-new,
	port 10024) with ESMTP
	id 09501-02; Sat,  1 Sep 2012 07:51:34 +0200 (CEST)
Received: from ferrari.rjw.lan (0127ahost2.starwoodbroadband.com
	[12.105.246.2])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by ogre.sisk.pl (Postfix) with ESMTP id 9E8ED1D34D1;
	Sat,  1 Sep 2012 07:51:34 +0200 (CEST)
From: "Rafael J. Wysocki" <rjw@sisk.pl>
To: Daniel Lezcano <daniel.lezcano@linaro.org>
Date: Sat, 1 Sep 2012 07:54:58 +0200
User-Agent: KMail/1.13.6 (Linux/3.6.0-rc3+; KDE/4.6.0; x86_64; ; )
References: <1343164349-28550-1-git-send-email-daniel.lezcano@linaro.org>
	<20120724210629.GA1149@phenom.dumpdata.com>
	<50410811.70500@linaro.org>
In-Reply-To: <50410811.70500@linaro.org>
MIME-Version: 1.0
Message-Id: <201209010754.58999.rjw@sisk.pl>
X-Virus-Scanned: amavisd-new at ogre.sisk.pl using MkS_Vir for Linux
Cc: xen-devel@lists.xensource.com, linaro-dev@lists.linaro.org,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	linux-pm@vger.kernel.org, patches@linaro.org,
	linux-acpi@vger.kernel.org, lenb@kernel.org
Subject: Re: [Xen-devel] [PATCH] acpi : remove power from acpi_processor_cx
	structure
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Friday, August 31, 2012, Daniel Lezcano wrote:
> On 07/24/2012 11:06 PM, Konrad Rzeszutek Wilk wrote:
> > On Tue, Jul 24, 2012 at 11:12:29PM +0200, Daniel Lezcano wrote:
> >> Remove the power field as it is not used.
> >>
> >> Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
> >> Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> > Acked.
> 
> Hi Rafael,
> 
> I did not see this patch going in. Is it possible to merge it ?

I think so.  I'll take care of it when I get back from LinuxCon/Plumbers Conf.
(early next week).

Thanks,
Rafael


> >> ---
> >>  drivers/acpi/processor_idle.c    |    2 --
> >>  drivers/xen/xen-acpi-processor.c |    1 -
> >>  include/acpi/processor.h         |    1 -
> >>  3 files changed, 0 insertions(+), 4 deletions(-)
> >>
> >> diff --git a/drivers/acpi/processor_idle.c b/drivers/acpi/processor_idle.c
> >> index e589c19..90582fb 100644
> >> --- a/drivers/acpi/processor_idle.c
> >> +++ b/drivers/acpi/processor_idle.c
> >> @@ -483,8 +483,6 @@ static int acpi_processor_get_power_info_cst(struct acpi_processor *pr)
> >>  		if (obj->type != ACPI_TYPE_INTEGER)
> >>  			continue;
> >>  
> >> -		cx.power = obj->integer.value;
> >> -
> >>  		current_count++;
> >>  		memcpy(&(pr->power.states[current_count]), &cx, sizeof(cx));
> >>  
> >> diff --git a/drivers/xen/xen-acpi-processor.c b/drivers/xen/xen-acpi-processor.c
> >> index 7ff2569..7ef9c1d 100644
> >> --- a/drivers/xen/xen-acpi-processor.c
> >> +++ b/drivers/xen/xen-acpi-processor.c
> >> @@ -98,7 +98,6 @@ static int push_cxx_to_hypervisor(struct acpi_processor *_pr)
> >>  
> >>  		dst_cx->type = cx->type;
> >>  		dst_cx->latency = cx->latency;
> >> -		dst_cx->power = cx->power;
> >>  
> >>  		dst_cx->dpcnt = 0;
> >>  		set_xen_guest_handle(dst_cx->dp, NULL);
> >> diff --git a/include/acpi/processor.h b/include/acpi/processor.h
> >> index 64ec644..db427fa 100644
> >> --- a/include/acpi/processor.h
> >> +++ b/include/acpi/processor.h
> >> @@ -59,7 +59,6 @@ struct acpi_processor_cx {
> >>  	u8 entry_method;
> >>  	u8 index;
> >>  	u32 latency;
> >> -	u32 power;
> >>  	u8 bm_sts_skip;
> >>  	char desc[ACPI_CX_DESC_LEN];
> >>  };
> > _______________________________________________
> > linaro-dev mailing list
> > linaro-dev@lists.linaro.org
> > http://lists.linaro.org/mailman/listinfo/linaro-dev
> >
> 
> 
> 


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

From xen-devel-bounces@lists.xen.org Sat Sep 01 11:24:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 01 Sep 2012 11: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 1T7loD-0000QX-1R; Sat, 01 Sep 2012 11:24:13 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <m.a.young@durham.ac.uk>) id 1T7loB-0000QP-QI
	for xen-devel@lists.xen.org; Sat, 01 Sep 2012 11:24:12 +0000
X-Env-Sender: m.a.young@durham.ac.uk
X-Msg-Ref: server-10.tower-27.messagelabs.com!1346498641!3937055!1
X-Originating-IP: [129.234.248.1]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTI5LjIzNC4yNDguMSA9PiAxMTA4OTY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19883 invoked from network); 1 Sep 2012 11:24:02 -0000
Received: from hermes1.dur.ac.uk (HELO hermes1.dur.ac.uk) (129.234.248.1)
	by server-10.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 1 Sep 2012 11:24:02 -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 q81BNbvs014945;
	Sat, 1 Sep 2012 12:23:41 +0100
Received: from procyon.dur.ac.uk (procyon.dur.ac.uk [129.234.250.129])
	by smtphost3.dur.ac.uk (8.13.8/8.13.7) with ESMTP id q81BNLDq018939
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Sat, 1 Sep 2012 12:23:21 +0100
Received: from procyon.dur.ac.uk (localhost [127.0.0.1])
	by procyon.dur.ac.uk (8.14.3/8.11.1) with ESMTP id q81BNLbB022661;
	Sat, 1 Sep 2012 12:23:21 +0100
Received: from localhost (dcl0may@localhost)
	by procyon.dur.ac.uk (8.14.3/8.14.3/Submit) with ESMTP id
	q81BNL2c022657; Sat, 1 Sep 2012 12:23:21 +0100
Date: Sat, 1 Sep 2012 12:23:21 +0100 (BST)
From: M A Young <m.a.young@durham.ac.uk>
To: Dan Magenheimer <dan.magenheimer@oracle.com>
In-Reply-To: <6dc36215-ef4a-4677-b0d5-7913a5ebb5f3@default>
Message-ID: <alpine.DEB.2.00.1209011213370.6523@procyon.dur.ac.uk>
References: <e927526f-b096-43da-a3b1-57d84daea825@default>
	<20120831211325.GB20594@localhost.localdomain>
	<da3e1ce8-0fcf-4c6f-88f9-cea859fe9ec1@default>
	<20120831222157.GA21232@localhost.localdomain>
	<6dc36215-ef4a-4677-b0d5-7913a5ebb5f3@default>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: MULTIPART/MIXED; BOUNDARY="8323329-673849467-1346498601=:6523"
X-DurhamAcUk-MailScanner: Found to be clean, Found to be clean
X-DurhamAcUk-MailScanner-ID: q81BNbvs014945
Cc: xen-devel@lists.xen.org, Konrad Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] xend/xm on 4.1/4.2 on Fedora (FC17)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<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-673849467-1346498601=:6523
Content-Type: TEXT/PLAIN; charset=iso-8859-1; format=flowed
Content-Transfer-Encoding: 8BIT

On Fri, 31 Aug 2012, Dan Magenheimer wrote:

>> From: Konrad Rzeszutek Wilk
>> Sent: Friday, August 31, 2012 4:22 PM
>> To: Dan Magenheimer
>> Cc: Pasi Kärkkäinen; xen-devel@lists.xen.org
>> Subject: Re: xend/xm on 4.1/4.2 on Fedora (FC17)
>>
>> On Fri, Aug 31, 2012 at 02:16:18PM -0700, Dan Magenheimer wrote:
>>>> From: Konrad Rzeszutek Wilk
>>>> Subject: Re: xend/xm on 4.1/4.2 on Fedora (FC17)
>>>>
>>>> On Fri, Aug 31, 2012 at 02:08:49PM -0700, Dan Magenheimer wrote:
>>>>> Is there a how-to for starting/running xm/xend on Fedora (FC17)?
>>>>> Is it different for Xen 4.1 and 4.2?
>>>>>
>>>>> I did find this:
>>>>> http://wiki.xen.org/wiki/Xen_Common_Problems#Starting_xend_fails.3F
>>>>> but it doesn't seem to help.  And this:
>>>>> http://wiki.xen.org/wiki/Fedora_Host_Installation
>>>>> only addresses xl.
>>>>>
>>>>> I expect I need to do something manually to start xencommons or
>>>>> something like that but obvious things don't seem to work,
>>>>
>>>> How are you running this? When you boot up does it work? Or is this not
>>>> working after your restart xend couple of times?
>>>>
>>>>> and I'm not a FC17 expert at all.
>>>>
>>>> service xend start
>>>>
>>>> But you also need to enable it if it wasn't enabled using systemd.
>>>> The syntax was something like (look at
>>>> http://fedoraproject.org/wiki/SysVinit_to_Systemd_Cheatsheet)
>>>>
>>>> systemctl enable xend.service
>>>>
>>>> (thought it might not be called xend but something else).
>>>
>>> That was one of the obvious things I tried, but it fails to start :-/
>>
>> Are you running in graphical mode? If so see if there are some weird
>> SELinux warnings.
>
> SELinux is disabled.  But yes, I am booting in graphical mode.
>
> Hmmm... manually running "/usr/sbin/xend start" seems to work though.
> I guess that is all I need as I can start it in /etc/rc.d/rc.local.

Strange, it is usually selinux that breaks xend. If you run
systemctl status xend.service
it should give you some indication of what went wrong.

Note that
systemctl enable xend.service
enables xend on boot (it is off by default in the package because xend is 
being deprecated), to start it by hand you need
systemctl start xend.service

 	Michael Young
--8323329-673849467-1346498601=:6523
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 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-673849467-1346498601=:6523--


From xen-devel-bounces@lists.xen.org Sat Sep 01 11:24:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 01 Sep 2012 11: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 1T7loD-0000QX-1R; Sat, 01 Sep 2012 11:24:13 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <m.a.young@durham.ac.uk>) id 1T7loB-0000QP-QI
	for xen-devel@lists.xen.org; Sat, 01 Sep 2012 11:24:12 +0000
X-Env-Sender: m.a.young@durham.ac.uk
X-Msg-Ref: server-10.tower-27.messagelabs.com!1346498641!3937055!1
X-Originating-IP: [129.234.248.1]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTI5LjIzNC4yNDguMSA9PiAxMTA4OTY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19883 invoked from network); 1 Sep 2012 11:24:02 -0000
Received: from hermes1.dur.ac.uk (HELO hermes1.dur.ac.uk) (129.234.248.1)
	by server-10.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 1 Sep 2012 11:24:02 -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 q81BNbvs014945;
	Sat, 1 Sep 2012 12:23:41 +0100
Received: from procyon.dur.ac.uk (procyon.dur.ac.uk [129.234.250.129])
	by smtphost3.dur.ac.uk (8.13.8/8.13.7) with ESMTP id q81BNLDq018939
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Sat, 1 Sep 2012 12:23:21 +0100
Received: from procyon.dur.ac.uk (localhost [127.0.0.1])
	by procyon.dur.ac.uk (8.14.3/8.11.1) with ESMTP id q81BNLbB022661;
	Sat, 1 Sep 2012 12:23:21 +0100
Received: from localhost (dcl0may@localhost)
	by procyon.dur.ac.uk (8.14.3/8.14.3/Submit) with ESMTP id
	q81BNL2c022657; Sat, 1 Sep 2012 12:23:21 +0100
Date: Sat, 1 Sep 2012 12:23:21 +0100 (BST)
From: M A Young <m.a.young@durham.ac.uk>
To: Dan Magenheimer <dan.magenheimer@oracle.com>
In-Reply-To: <6dc36215-ef4a-4677-b0d5-7913a5ebb5f3@default>
Message-ID: <alpine.DEB.2.00.1209011213370.6523@procyon.dur.ac.uk>
References: <e927526f-b096-43da-a3b1-57d84daea825@default>
	<20120831211325.GB20594@localhost.localdomain>
	<da3e1ce8-0fcf-4c6f-88f9-cea859fe9ec1@default>
	<20120831222157.GA21232@localhost.localdomain>
	<6dc36215-ef4a-4677-b0d5-7913a5ebb5f3@default>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: MULTIPART/MIXED; BOUNDARY="8323329-673849467-1346498601=:6523"
X-DurhamAcUk-MailScanner: Found to be clean, Found to be clean
X-DurhamAcUk-MailScanner-ID: q81BNbvs014945
Cc: xen-devel@lists.xen.org, Konrad Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] xend/xm on 4.1/4.2 on Fedora (FC17)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<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-673849467-1346498601=:6523
Content-Type: TEXT/PLAIN; charset=iso-8859-1; format=flowed
Content-Transfer-Encoding: 8BIT

On Fri, 31 Aug 2012, Dan Magenheimer wrote:

>> From: Konrad Rzeszutek Wilk
>> Sent: Friday, August 31, 2012 4:22 PM
>> To: Dan Magenheimer
>> Cc: Pasi Kärkkäinen; xen-devel@lists.xen.org
>> Subject: Re: xend/xm on 4.1/4.2 on Fedora (FC17)
>>
>> On Fri, Aug 31, 2012 at 02:16:18PM -0700, Dan Magenheimer wrote:
>>>> From: Konrad Rzeszutek Wilk
>>>> Subject: Re: xend/xm on 4.1/4.2 on Fedora (FC17)
>>>>
>>>> On Fri, Aug 31, 2012 at 02:08:49PM -0700, Dan Magenheimer wrote:
>>>>> Is there a how-to for starting/running xm/xend on Fedora (FC17)?
>>>>> Is it different for Xen 4.1 and 4.2?
>>>>>
>>>>> I did find this:
>>>>> http://wiki.xen.org/wiki/Xen_Common_Problems#Starting_xend_fails.3F
>>>>> but it doesn't seem to help.  And this:
>>>>> http://wiki.xen.org/wiki/Fedora_Host_Installation
>>>>> only addresses xl.
>>>>>
>>>>> I expect I need to do something manually to start xencommons or
>>>>> something like that but obvious things don't seem to work,
>>>>
>>>> How are you running this? When you boot up does it work? Or is this not
>>>> working after your restart xend couple of times?
>>>>
>>>>> and I'm not a FC17 expert at all.
>>>>
>>>> service xend start
>>>>
>>>> But you also need to enable it if it wasn't enabled using systemd.
>>>> The syntax was something like (look at
>>>> http://fedoraproject.org/wiki/SysVinit_to_Systemd_Cheatsheet)
>>>>
>>>> systemctl enable xend.service
>>>>
>>>> (thought it might not be called xend but something else).
>>>
>>> That was one of the obvious things I tried, but it fails to start :-/
>>
>> Are you running in graphical mode? If so see if there are some weird
>> SELinux warnings.
>
> SELinux is disabled.  But yes, I am booting in graphical mode.
>
> Hmmm... manually running "/usr/sbin/xend start" seems to work though.
> I guess that is all I need as I can start it in /etc/rc.d/rc.local.

Strange, it is usually selinux that breaks xend. If you run
systemctl status xend.service
it should give you some indication of what went wrong.

Note that
systemctl enable xend.service
enables xend on boot (it is off by default in the package because xend is 
being deprecated), to start it by hand you need
systemctl start xend.service

 	Michael Young
--8323329-673849467-1346498601=:6523
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 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-673849467-1346498601=:6523--


From xen-devel-bounces@lists.xen.org Sat Sep 01 17:05:06 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 01 Sep 2012 17:05:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T7r7N-0002OV-Te; Sat, 01 Sep 2012 17:04:21 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Santosh.Jodh@citrix.com>) id 1T7r7M-0002OQ-7B
	for xen-devel@lists.xen.org; Sat, 01 Sep 2012 17:04:20 +0000
Received: from [85.158.143.99:13942] by server-3.bemta-4.messagelabs.com id
	21/54-08232-31042405; Sat, 01 Sep 2012 17:04:19 +0000
X-Env-Sender: Santosh.Jodh@citrix.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1346519057!22671298!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNjc3MTY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17739 invoked from network); 1 Sep 2012 17:04:18 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-2.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Sep 2012 17:04:18 -0000
X-IronPort-AV: E=Sophos;i="4.80,353,1344211200"; d="scan'208";a="36519459"
Received: from sjcpmailmx02.citrite.net ([10.216.14.75])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Sep 2012 17:04:13 +0000
Received: from SJCPMAILBOX01.citrite.net ([10.216.4.72]) by
	SJCPMAILMX02.citrite.net ([10.216.14.75]) with mapi;
	Sat, 1 Sep 2012 10:04:12 -0700
From: Santosh Jodh <Santosh.Jodh@citrix.com>
To: Keir Fraser <keir.xen@gmail.com>, Sander Eikelenboom <linux@eikelenboom.it>
Date: Sat, 1 Sep 2012 10:03:54 -0700
Thread-Topic: [Xen-devel] Using debug-key 'o:  Dump IOMMU p2m table, locks
	up machine
Thread-Index: Ac2H5anSA9JOwrAdv0yUGY6DtFwLdQAfNVTw
Message-ID: <7914B38A4445B34AA16EB9F1352942F1012F0F6F4B98@SJCPMAILBOX01.citrite.net>
References: <1377403931.20120901011625@eikelenboom.it>
	<CC672AF9.3D8E2%keir.xen@gmail.com>
In-Reply-To: <CC672AF9.3D8E2%keir.xen@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Cc: "wei.wang2@amd.com" <wei.wang2@amd.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Using debug-key 'o:  Dump IOMMU p2m table,
 locks up machine
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org



> -----Original Message-----
> From: Keir Fraser [mailto:keir.xen@gmail.com]
> Sent: Friday, August 31, 2012 7:01 PM
> To: Sander Eikelenboom; Santosh Jodh
> Cc: wei.wang2@amd.com; xen-devel@lists.xen.org
> Subject: Re: [Xen-devel] Using debug-key 'o: Dump IOMMU p2m table, locks
> up machine
> 
> On 01/09/2012 00:16, "Sander Eikelenboom" <linux@eikelenboom.it> wrote:
> 
> >
> > Saturday, September 1, 2012, 12:57:45 AM, you wrote:
> >
> >> The dump should complete - would be curious to see how long it takes
> >> on serial console. What baudrate is the console running at?
> >
> > I think for ages, this part seems only to cover a bit of the first of
> > 3 pv guests which have devices passed through.
> > 38400
> >
> > And i wonder if the information is very valuable, gfn == mfn for every
> > line ... at an increment of 1 ...
> > Perhaps a uhmmm more compact way of getting the interesting data
> would
> > be handy ?
> > Or is this the intended output ?
> >
> >> The code does allow processing of pending softirqs quite frequently.
> >> I am not sure why you are still seeing SATA errors.
> >
> > The machine is completely unresponsive in every way.
> 
> It might schedule softirqs but that won't include scheduling or running any
> guest vcpus. The vcpu that happens to be running on that cpu at the time the
> debug dump starts, will be stuck unrunnable until the dump completes.

Why does'nt that vCPU get scheduled on some other pCPU? Is there  a way to yield the CPU from the key handler?

> 
> Well, anyway, I don't know how useful a massive dump of the entire p2m is
> going to be for debugging anyway. If investigating an IOMMU page fault, I'd
> just want the info pertaining to that fault, and all the mapping information for
> that IO virtual address, dumped. :)

It is not a generically useful command - its usefulness is in the same category as dumping the MMU table. Unfortunately, there is no way to pass arguments to the key handler - to say provide the VM and or starting gfn and length for a more selective output.

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

From xen-devel-bounces@lists.xen.org Sat Sep 01 17:05:06 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 01 Sep 2012 17:05:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T7r7N-0002OV-Te; Sat, 01 Sep 2012 17:04:21 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Santosh.Jodh@citrix.com>) id 1T7r7M-0002OQ-7B
	for xen-devel@lists.xen.org; Sat, 01 Sep 2012 17:04:20 +0000
Received: from [85.158.143.99:13942] by server-3.bemta-4.messagelabs.com id
	21/54-08232-31042405; Sat, 01 Sep 2012 17:04:19 +0000
X-Env-Sender: Santosh.Jodh@citrix.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1346519057!22671298!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNjc3MTY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17739 invoked from network); 1 Sep 2012 17:04:18 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-2.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Sep 2012 17:04:18 -0000
X-IronPort-AV: E=Sophos;i="4.80,353,1344211200"; d="scan'208";a="36519459"
Received: from sjcpmailmx02.citrite.net ([10.216.14.75])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Sep 2012 17:04:13 +0000
Received: from SJCPMAILBOX01.citrite.net ([10.216.4.72]) by
	SJCPMAILMX02.citrite.net ([10.216.14.75]) with mapi;
	Sat, 1 Sep 2012 10:04:12 -0700
From: Santosh Jodh <Santosh.Jodh@citrix.com>
To: Keir Fraser <keir.xen@gmail.com>, Sander Eikelenboom <linux@eikelenboom.it>
Date: Sat, 1 Sep 2012 10:03:54 -0700
Thread-Topic: [Xen-devel] Using debug-key 'o:  Dump IOMMU p2m table, locks
	up machine
Thread-Index: Ac2H5anSA9JOwrAdv0yUGY6DtFwLdQAfNVTw
Message-ID: <7914B38A4445B34AA16EB9F1352942F1012F0F6F4B98@SJCPMAILBOX01.citrite.net>
References: <1377403931.20120901011625@eikelenboom.it>
	<CC672AF9.3D8E2%keir.xen@gmail.com>
In-Reply-To: <CC672AF9.3D8E2%keir.xen@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Cc: "wei.wang2@amd.com" <wei.wang2@amd.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Using debug-key 'o:  Dump IOMMU p2m table,
 locks up machine
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org



> -----Original Message-----
> From: Keir Fraser [mailto:keir.xen@gmail.com]
> Sent: Friday, August 31, 2012 7:01 PM
> To: Sander Eikelenboom; Santosh Jodh
> Cc: wei.wang2@amd.com; xen-devel@lists.xen.org
> Subject: Re: [Xen-devel] Using debug-key 'o: Dump IOMMU p2m table, locks
> up machine
> 
> On 01/09/2012 00:16, "Sander Eikelenboom" <linux@eikelenboom.it> wrote:
> 
> >
> > Saturday, September 1, 2012, 12:57:45 AM, you wrote:
> >
> >> The dump should complete - would be curious to see how long it takes
> >> on serial console. What baudrate is the console running at?
> >
> > I think for ages, this part seems only to cover a bit of the first of
> > 3 pv guests which have devices passed through.
> > 38400
> >
> > And i wonder if the information is very valuable, gfn == mfn for every
> > line ... at an increment of 1 ...
> > Perhaps a uhmmm more compact way of getting the interesting data
> would
> > be handy ?
> > Or is this the intended output ?
> >
> >> The code does allow processing of pending softirqs quite frequently.
> >> I am not sure why you are still seeing SATA errors.
> >
> > The machine is completely unresponsive in every way.
> 
> It might schedule softirqs but that won't include scheduling or running any
> guest vcpus. The vcpu that happens to be running on that cpu at the time the
> debug dump starts, will be stuck unrunnable until the dump completes.

Why does'nt that vCPU get scheduled on some other pCPU? Is there  a way to yield the CPU from the key handler?

> 
> Well, anyway, I don't know how useful a massive dump of the entire p2m is
> going to be for debugging anyway. If investigating an IOMMU page fault, I'd
> just want the info pertaining to that fault, and all the mapping information for
> that IO virtual address, dumped. :)

It is not a generically useful command - its usefulness is in the same category as dumping the MMU table. Unfortunately, there is no way to pass arguments to the key handler - to say provide the VM and or starting gfn and length for a more selective output.

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

From xen-devel-bounces@lists.xen.org Sat Sep 01 19:14:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 01 Sep 2012 19: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 1T7t8O-00030e-OV; Sat, 01 Sep 2012 19:13:32 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1T7t8M-00030Z-L3
	for xen-devel@lists.xen.org; Sat, 01 Sep 2012 19:13:30 +0000
Received: from [85.158.143.99:32629] by server-1.bemta-4.messagelabs.com id
	2E/6E-12504-95E52405; Sat, 01 Sep 2012 19:13:29 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1346526808!27989165!1
X-Originating-IP: [209.85.212.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6535 invoked from network); 1 Sep 2012 19:13:29 -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;
	1 Sep 2012 19:13:29 -0000
Received: by wibhm6 with SMTP id hm6so2184431wib.14
	for <xen-devel@lists.xen.org>; Sat, 01 Sep 2012 12:13:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=lo6cFGjdF41uFen0A+xHuluh0Gzs+ifvMqxG5T/rKTk=;
	b=HVcRLDBtxAxgESlk6ZFpXD9zZkHyqx9+hN9OX7GyoY7CUpFcc8nClWiwznfTd2Thls
	sFOUR5a/2iWNG+U5TqOToKhrwrYahC6LbUn+77rzo/YvNBkUJmDhfLTPmQNSZ+y7HSmP
	TvvkNol506Sx3/lVmcyZwyqLUaQ/CQqoQNyi2nEAo9tJubzAgiPaxhgZxs6ylj8d0MDa
	NF9hqT4eS1P6JUFlI2wV+44UqFud4dQlF36HVAnfIK+kS3uLvjU6jwL9X+azdeugo3Me
	nbIkZrHPxCKvZRGjWAjzHTCQDXWvzHA4FKxDeNHktpHxUQg9Y8MoxKfMZDPImr3Lm8hH
	CwvA==
Received: by 10.180.20.204 with SMTP id p12mr12550432wie.7.1346526808585;
	Sat, 01 Sep 2012 12:13:28 -0700 (PDT)
Received: from [192.168.1.69] (host86-184-74-117.range86-184.btcentralplus.com.
	[86.184.74.117])
	by mx.google.com with ESMTPS id cu1sm8715755wib.6.2012.09.01.12.13.24
	(version=SSLv3 cipher=OTHER); Sat, 01 Sep 2012 12:13:27 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Sat, 01 Sep 2012 20:13:17 +0100
From: Keir Fraser <keir.xen@gmail.com>
To: Santosh Jodh <Santosh.Jodh@citrix.com>,
	Sander Eikelenboom <linux@eikelenboom.it>
Message-ID: <CC681CDD.3D966%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] Using debug-key 'o:  Dump IOMMU p2m table, locks up
	machine
Thread-Index: Ac2H5anSA9JOwrAdv0yUGY6DtFwLdQAfNVTwAATWEUo=
In-Reply-To: <7914B38A4445B34AA16EB9F1352942F1012F0F6F4B98@SJCPMAILBOX01.citrite.net>
Mime-version: 1.0
Cc: "wei.wang2@amd.com" <wei.wang2@amd.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Using debug-key 'o:  Dump IOMMU p2m table,
 locks up machine
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/09/2012 18:03, "Santosh Jodh" <Santosh.Jodh@citrix.com> wrote:

>> It might schedule softirqs but that won't include scheduling or running any
>> guest vcpus. The vcpu that happens to be running on that cpu at the time the
>> debug dump starts, will be stuck unrunnable until the dump completes.
> 
> Why does'nt that vCPU get scheduled on some other pCPU? Is there  a way to
> yield the CPU from the key handler?

It can't be descheduled from this pCPU without running through the
scheduler. You could try running the handler in a tasklet -- a tasklet
causes other vCPUs to be descheduled from that pCPU, before it starts
running.

So you'd register a keyhandler which does a tasklet_schedule(), and do your
logging work in the tasklet handler.

Worth a shot maybe?

>> 
>> Well, anyway, I don't know how useful a massive dump of the entire p2m is
>> going to be for debugging anyway. If investigating an IOMMU page fault, I'd
>> just want the info pertaining to that fault, and all the mapping information
>> for
>> that IO virtual address, dumped. :)
> 
> It is not a generically useful command - its usefulness is in the same
> category as dumping the MMU table. Unfortunately, there is no way to pass
> arguments to the key handler - to say provide the VM and or starting gfn and
> length for a more selective output.

Quite simply, there likely needs to be more tracing on the IOMMU fault path.
That's a separate concern from your keyhandler of course, but just saying
I'd be looking for the former rather than the latter, for diagnosing
Sander's bug.

 -- Keir



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

From xen-devel-bounces@lists.xen.org Sat Sep 01 19:14:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 01 Sep 2012 19: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 1T7t8O-00030e-OV; Sat, 01 Sep 2012 19:13:32 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1T7t8M-00030Z-L3
	for xen-devel@lists.xen.org; Sat, 01 Sep 2012 19:13:30 +0000
Received: from [85.158.143.99:32629] by server-1.bemta-4.messagelabs.com id
	2E/6E-12504-95E52405; Sat, 01 Sep 2012 19:13:29 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1346526808!27989165!1
X-Originating-IP: [209.85.212.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6535 invoked from network); 1 Sep 2012 19:13:29 -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;
	1 Sep 2012 19:13:29 -0000
Received: by wibhm6 with SMTP id hm6so2184431wib.14
	for <xen-devel@lists.xen.org>; Sat, 01 Sep 2012 12:13:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=lo6cFGjdF41uFen0A+xHuluh0Gzs+ifvMqxG5T/rKTk=;
	b=HVcRLDBtxAxgESlk6ZFpXD9zZkHyqx9+hN9OX7GyoY7CUpFcc8nClWiwznfTd2Thls
	sFOUR5a/2iWNG+U5TqOToKhrwrYahC6LbUn+77rzo/YvNBkUJmDhfLTPmQNSZ+y7HSmP
	TvvkNol506Sx3/lVmcyZwyqLUaQ/CQqoQNyi2nEAo9tJubzAgiPaxhgZxs6ylj8d0MDa
	NF9hqT4eS1P6JUFlI2wV+44UqFud4dQlF36HVAnfIK+kS3uLvjU6jwL9X+azdeugo3Me
	nbIkZrHPxCKvZRGjWAjzHTCQDXWvzHA4FKxDeNHktpHxUQg9Y8MoxKfMZDPImr3Lm8hH
	CwvA==
Received: by 10.180.20.204 with SMTP id p12mr12550432wie.7.1346526808585;
	Sat, 01 Sep 2012 12:13:28 -0700 (PDT)
Received: from [192.168.1.69] (host86-184-74-117.range86-184.btcentralplus.com.
	[86.184.74.117])
	by mx.google.com with ESMTPS id cu1sm8715755wib.6.2012.09.01.12.13.24
	(version=SSLv3 cipher=OTHER); Sat, 01 Sep 2012 12:13:27 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Sat, 01 Sep 2012 20:13:17 +0100
From: Keir Fraser <keir.xen@gmail.com>
To: Santosh Jodh <Santosh.Jodh@citrix.com>,
	Sander Eikelenboom <linux@eikelenboom.it>
Message-ID: <CC681CDD.3D966%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] Using debug-key 'o:  Dump IOMMU p2m table, locks up
	machine
Thread-Index: Ac2H5anSA9JOwrAdv0yUGY6DtFwLdQAfNVTwAATWEUo=
In-Reply-To: <7914B38A4445B34AA16EB9F1352942F1012F0F6F4B98@SJCPMAILBOX01.citrite.net>
Mime-version: 1.0
Cc: "wei.wang2@amd.com" <wei.wang2@amd.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Using debug-key 'o:  Dump IOMMU p2m table,
 locks up machine
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/09/2012 18:03, "Santosh Jodh" <Santosh.Jodh@citrix.com> wrote:

>> It might schedule softirqs but that won't include scheduling or running any
>> guest vcpus. The vcpu that happens to be running on that cpu at the time the
>> debug dump starts, will be stuck unrunnable until the dump completes.
> 
> Why does'nt that vCPU get scheduled on some other pCPU? Is there  a way to
> yield the CPU from the key handler?

It can't be descheduled from this pCPU without running through the
scheduler. You could try running the handler in a tasklet -- a tasklet
causes other vCPUs to be descheduled from that pCPU, before it starts
running.

So you'd register a keyhandler which does a tasklet_schedule(), and do your
logging work in the tasklet handler.

Worth a shot maybe?

>> 
>> Well, anyway, I don't know how useful a massive dump of the entire p2m is
>> going to be for debugging anyway. If investigating an IOMMU page fault, I'd
>> just want the info pertaining to that fault, and all the mapping information
>> for
>> that IO virtual address, dumped. :)
> 
> It is not a generically useful command - its usefulness is in the same
> category as dumping the MMU table. Unfortunately, there is no way to pass
> arguments to the key handler - to say provide the VM and or starting gfn and
> length for a more selective output.

Quite simply, there likely needs to be more tracing on the IOMMU fault path.
That's a separate concern from your keyhandler of course, but just saying
I'd be looking for the former rather than the latter, for diagnosing
Sander's bug.

 -- Keir



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

From xen-devel-bounces@lists.xen.org Sat Sep 01 20:57:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 01 Sep 2012 20:57:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T7ukH-0003Rc-MZ; Sat, 01 Sep 2012 20:56:45 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jean.guyader@gmail.com>) id 1T7ukG-0003RW-0J
	for xen-devel@lists.xen.org; Sat, 01 Sep 2012 20:56:44 +0000
Received: from [85.158.138.51:19453] by server-12.bemta-3.messagelabs.com id
	AD/B7-10384-B8672405; Sat, 01 Sep 2012 20:56:43 +0000
X-Env-Sender: jean.guyader@gmail.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1346533001!28140469!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-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13669 invoked from network); 1 Sep 2012 20:56:42 -0000
Received: from mail-vb0-f45.google.com (HELO mail-vb0-f45.google.com)
	(209.85.212.45)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Sep 2012 20:56:42 -0000
Received: by vbip1 with SMTP id p1so5308539vbi.32
	for <xen-devel@lists.xen.org>; Sat, 01 Sep 2012 13:56:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to
	:cc:content-type;
	bh=8n0lT9zV5qqM1eUis5ym4zTURs2dT1cA4FurfjfLwbU=;
	b=RARId9t6iIcuBp7urlA6gd2MAwMgc6qGlIkjEjzTInIZaNMsgi8F8e3Ab7Ir5Nm0Is
	09ew9Jc9Hs4M/p0UURnczr8AdeilDIW23AEdtXW8LEbxCHhJchZ8cKwr9J8ESQiOQd4o
	uYxBEVkx9JOrChyb0mcM4Dw2+s9L58gASEwh6Ljc4+UpA69DN+iA5T3pQ2nh9uolW9JU
	2qDvjDYuKSKdyDqs4o9AHLN7QMIEgozgRPg0IySGcUHtR9qkGl2RbyE5Zvq0km4cIblQ
	UHP06G5pju5I+2AAPnAg5fpsGwSm8AOjLJA/yKi/juudZcaJ2BptSu25oPxgYCOPN/Tw
	dWkA==
Received: by 10.52.31.230 with SMTP id d6mr6784878vdi.87.1346533001066; Sat,
	01 Sep 2012 13:56:41 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.58.91.72 with HTTP; Sat, 1 Sep 2012 13:56:20 -0700 (PDT)
In-Reply-To: <501FA05C0200007800092CD7@nat28.tlf.novell.com>
References: <1344023454-31425-1-git-send-email-jean.guyader@citrix.com>
	<1344023454-31425-6-git-send-email-jean.guyader@citrix.com>
	<501FA05C0200007800092CD7@nat28.tlf.novell.com>
From: Jean Guyader <jean.guyader@gmail.com>
Date: Sat, 1 Sep 2012 13:56:20 -0700
Message-ID: <CAEBdQ90pQtB7nEO-s0TJtfMhOow529_2de+jm3pwWjFna1H_2g@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 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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 6 August 2012 01:45, Jan Beulich <JBeulich@suse.com> wrote:
>>>> On 03.08.12 at 21:50, Jean Guyader <jean.guyader@citrix.com> wrote:
>>--- /dev/null
>>+++ b/xen/include/public/v4v.h
>>...
>>+#define V4V_DOMID_ANY           0x7fffU
>
> I think I asked this before - why not use one of the pre-existing
> DOMID values? And if there is a good reason, it should be said
> here in a comment, to avoid the same question being asked
> later again.
>

I replaced 0x7fffU with DOMID_INVALID.

>>...
>>+typedef uint64_t v4v_pfn_t;
>
> We already have xen_pfn_t, so why do you need yet another
> flavor?
>

No, replaced with xen_pfn_t.

>>...
>>+struct v4v_info
>>+{
>>+    uint64_t ring_magic;
>>+    uint64_t data_magic;
>>+    evtchn_port_t evtchn;
>
> Missing padding at the end?
>

ack.

>>+};
>>+typedef struct v4v_info v4v_info_t;
>>+
>>+#define V4V_ROUNDUP(a) (((a) +0xf ) & ~0xf)
>
> Doesn't seem to belong here. Or is the subsequent comment
> actually related to this (in which case it should be moved ahead
> of the definition and made match it).
>

V4V_ROUNDUP is now in v4v.c and I move the description above
the define.

Thanks for the review,
Jean

>>+/*
>>+ * 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
>>+ */
>>...
>>+/*
>>+ * HYPERCALLS
>>+ */
>>...
>
> In the block below here, please get the naming (do_v4v_op()
> vs v4v_hypercall()) and the use of newlines (either always one
> or always two between individual hypercall descriptions)
> consistent. Hmm, even the descriptions don't seem to always
> match the definitions (not really obvious because apparently
> again the descriptions follow the definitions, whereas the
> opposite is the usual way to arrange things).
>
>>--- /dev/null
>>+++ b/xen/include/xen/v4v_utils.h
>>...
>>+/* Compiler specific hacks */
>>+#if defined(__GNUC__)
>>+# define V4V_UNUSED __attribute__ ((unused))
>>+# ifndef __STRICT_ANSI__
>>+#  define V4V_INLINE inline
>>+# else
>>+#  define V4V_INLINE
>>+# endif
>>+#else /* !__GNUC__ */
>>+# define V4V_UNUSED
>>+# define V4V_INLINE
>>+#endif
>
> This suggests the header is really intended to be public?
>
>>...
>>+static V4V_INLINE uint32_t
>>+v4v_ring_bytes_to_read (volatile struct v4v_ring *r)
>
> No space between function name and opening parenthesis
> (throughout this file).
>
>>...
>>+V4V_UNUSED static V4V_INLINE ssize_t
>
> V4V_UNUSED? Doesn't make sense in conjunction with
> V4V_INLINE, at least as long as you're using GNU extensions
> anyway (see above as to the disposition of the header).
>
>>+v4v_copy_out (struct v4v_ring *r, struct v4v_addr *from, uint32_t * protocol,
>>+              void *_buf, size_t t, int consume)
>
> Dead functions shouldn't be placed here.
>
>>...
>>+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)
>>+{
>
> What's the point of having a declaration followed immediately by
> a definition? Also, the function is dead too.
>

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

From xen-devel-bounces@lists.xen.org Sat Sep 01 20:57:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 01 Sep 2012 20:57:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T7ukH-0003Rc-MZ; Sat, 01 Sep 2012 20:56:45 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jean.guyader@gmail.com>) id 1T7ukG-0003RW-0J
	for xen-devel@lists.xen.org; Sat, 01 Sep 2012 20:56:44 +0000
Received: from [85.158.138.51:19453] by server-12.bemta-3.messagelabs.com id
	AD/B7-10384-B8672405; Sat, 01 Sep 2012 20:56:43 +0000
X-Env-Sender: jean.guyader@gmail.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1346533001!28140469!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-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13669 invoked from network); 1 Sep 2012 20:56:42 -0000
Received: from mail-vb0-f45.google.com (HELO mail-vb0-f45.google.com)
	(209.85.212.45)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Sep 2012 20:56:42 -0000
Received: by vbip1 with SMTP id p1so5308539vbi.32
	for <xen-devel@lists.xen.org>; Sat, 01 Sep 2012 13:56:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to
	:cc:content-type;
	bh=8n0lT9zV5qqM1eUis5ym4zTURs2dT1cA4FurfjfLwbU=;
	b=RARId9t6iIcuBp7urlA6gd2MAwMgc6qGlIkjEjzTInIZaNMsgi8F8e3Ab7Ir5Nm0Is
	09ew9Jc9Hs4M/p0UURnczr8AdeilDIW23AEdtXW8LEbxCHhJchZ8cKwr9J8ESQiOQd4o
	uYxBEVkx9JOrChyb0mcM4Dw2+s9L58gASEwh6Ljc4+UpA69DN+iA5T3pQ2nh9uolW9JU
	2qDvjDYuKSKdyDqs4o9AHLN7QMIEgozgRPg0IySGcUHtR9qkGl2RbyE5Zvq0km4cIblQ
	UHP06G5pju5I+2AAPnAg5fpsGwSm8AOjLJA/yKi/juudZcaJ2BptSu25oPxgYCOPN/Tw
	dWkA==
Received: by 10.52.31.230 with SMTP id d6mr6784878vdi.87.1346533001066; Sat,
	01 Sep 2012 13:56:41 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.58.91.72 with HTTP; Sat, 1 Sep 2012 13:56:20 -0700 (PDT)
In-Reply-To: <501FA05C0200007800092CD7@nat28.tlf.novell.com>
References: <1344023454-31425-1-git-send-email-jean.guyader@citrix.com>
	<1344023454-31425-6-git-send-email-jean.guyader@citrix.com>
	<501FA05C0200007800092CD7@nat28.tlf.novell.com>
From: Jean Guyader <jean.guyader@gmail.com>
Date: Sat, 1 Sep 2012 13:56:20 -0700
Message-ID: <CAEBdQ90pQtB7nEO-s0TJtfMhOow529_2de+jm3pwWjFna1H_2g@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 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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 6 August 2012 01:45, Jan Beulich <JBeulich@suse.com> wrote:
>>>> On 03.08.12 at 21:50, Jean Guyader <jean.guyader@citrix.com> wrote:
>>--- /dev/null
>>+++ b/xen/include/public/v4v.h
>>...
>>+#define V4V_DOMID_ANY           0x7fffU
>
> I think I asked this before - why not use one of the pre-existing
> DOMID values? And if there is a good reason, it should be said
> here in a comment, to avoid the same question being asked
> later again.
>

I replaced 0x7fffU with DOMID_INVALID.

>>...
>>+typedef uint64_t v4v_pfn_t;
>
> We already have xen_pfn_t, so why do you need yet another
> flavor?
>

No, replaced with xen_pfn_t.

>>...
>>+struct v4v_info
>>+{
>>+    uint64_t ring_magic;
>>+    uint64_t data_magic;
>>+    evtchn_port_t evtchn;
>
> Missing padding at the end?
>

ack.

>>+};
>>+typedef struct v4v_info v4v_info_t;
>>+
>>+#define V4V_ROUNDUP(a) (((a) +0xf ) & ~0xf)
>
> Doesn't seem to belong here. Or is the subsequent comment
> actually related to this (in which case it should be moved ahead
> of the definition and made match it).
>

V4V_ROUNDUP is now in v4v.c and I move the description above
the define.

Thanks for the review,
Jean

>>+/*
>>+ * 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
>>+ */
>>...
>>+/*
>>+ * HYPERCALLS
>>+ */
>>...
>
> In the block below here, please get the naming (do_v4v_op()
> vs v4v_hypercall()) and the use of newlines (either always one
> or always two between individual hypercall descriptions)
> consistent. Hmm, even the descriptions don't seem to always
> match the definitions (not really obvious because apparently
> again the descriptions follow the definitions, whereas the
> opposite is the usual way to arrange things).
>
>>--- /dev/null
>>+++ b/xen/include/xen/v4v_utils.h
>>...
>>+/* Compiler specific hacks */
>>+#if defined(__GNUC__)
>>+# define V4V_UNUSED __attribute__ ((unused))
>>+# ifndef __STRICT_ANSI__
>>+#  define V4V_INLINE inline
>>+# else
>>+#  define V4V_INLINE
>>+# endif
>>+#else /* !__GNUC__ */
>>+# define V4V_UNUSED
>>+# define V4V_INLINE
>>+#endif
>
> This suggests the header is really intended to be public?
>
>>...
>>+static V4V_INLINE uint32_t
>>+v4v_ring_bytes_to_read (volatile struct v4v_ring *r)
>
> No space between function name and opening parenthesis
> (throughout this file).
>
>>...
>>+V4V_UNUSED static V4V_INLINE ssize_t
>
> V4V_UNUSED? Doesn't make sense in conjunction with
> V4V_INLINE, at least as long as you're using GNU extensions
> anyway (see above as to the disposition of the header).
>
>>+v4v_copy_out (struct v4v_ring *r, struct v4v_addr *from, uint32_t * protocol,
>>+              void *_buf, size_t t, int consume)
>
> Dead functions shouldn't be placed here.
>
>>...
>>+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)
>>+{
>
> What's the point of having a declaration followed immediately by
> a definition? Also, the function is dead too.
>

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

From xen-devel-bounces@lists.xen.org Sat Sep 01 20:59:11 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 01 Sep 2012 20: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 1T7um5-0003Vq-6L; Sat, 01 Sep 2012 20:58:37 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jean.guyader@gmail.com>) id 1T7um3-0003Vh-FV
	for xen-devel@lists.xen.org; Sat, 01 Sep 2012 20:58:35 +0000
Received: from [85.158.139.83:58250] by server-7.bemta-5.messagelabs.com id
	30/1D-19703-AF672405; Sat, 01 Sep 2012 20:58:34 +0000
X-Env-Sender: jean.guyader@gmail.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1346533112!27989257!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-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7509 invoked from network); 1 Sep 2012 20:58:33 -0000
Received: from mail-vc0-f173.google.com (HELO mail-vc0-f173.google.com)
	(209.85.220.173)
	by server-15.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Sep 2012 20:58:33 -0000
Received: by vcbgb23 with SMTP id gb23so5447386vcb.32
	for <xen-devel@lists.xen.org>; Sat, 01 Sep 2012 13:58:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to
	:cc:content-type;
	bh=ubssRgY8Ix1ujc7mihXN4Q1avEbiDqM2yAZmhY0uQUg=;
	b=w9lLAHVjm4gprw1VDvO60gd9uOfbMNq/5TvXCvB1wDMUbAB0eHNbckuTy+kwk0TSYr
	0ISOddHfXYx5LFCllMGRqXEP9QDPKe8SPPZD4Voum2KxlZD6Dx0ZON2o3w4/+Iyb+rN3
	dKOxo3M69YToFA4Lyk6PLw2WE+GBJWHWlQuQ5FCXp3eZ/dngZY9S6NWeZNG5SDaa/Crp
	Lbm0GUyEL5nPlkw6WIEFejDJXyvki6a2joOJWDI7Kf31brHHInXbdAcsX2/5gTW04qAU
	d8U1xJtUxOy1QB6OXpdn7DZl+6DkL1YVJj+BmCPzE9JkuPNThgKbBMbHHIU6+48nBIC8
	Vt9A==
Received: by 10.52.90.83 with SMTP id bu19mr6830943vdb.64.1346533112364; Sat,
	01 Sep 2012 13:58:32 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.58.91.72 with HTTP; Sat, 1 Sep 2012 13:58:12 -0700 (PDT)
In-Reply-To: <5037ECE2020000780008A7D5@nat28.tlf.novell.com>
References: <1344023454-31425-1-git-send-email-jean.guyader@citrix.com>
	<1344023454-31425-6-git-send-email-jean.guyader@citrix.com>
	<501FA05C0200007800092CD7@nat28.tlf.novell.com>
	<CAEBdQ90ObLybAxzYceEQyEVtpP7mMmPrn7NryH3h-+dTXBNDUw@mail.gmail.com>
	<5037ECE2020000780008A7D5@nat28.tlf.novell.com>
From: Jean Guyader <jean.guyader@gmail.com>
Date: Sat, 1 Sep 2012 13:58:12 -0700
Message-ID: <CAEBdQ93kXanGiP+yOhiecMZv3nYtNt9XvrXKvhA3WBdm3f+PKQ@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 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>
Content-Type: text/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 August 2012 13:06, Jan Beulich <JBeulich@suse.com> wrote:
>>>> On 23.08.12 at 13:57, Jean Guyader <jean.guyader@gmail.com> wrote:
>> On 6 August 2012 09:45, Jan Beulich <JBeulich@suse.com> wrote:
>>>>>> On 03.08.12 at 21:50, Jean Guyader <jean.guyader@citrix.com> wrote:
>>>>--- /dev/null
>>>>+++ b/xen/include/public/v4v.h
>>>>...
>>>>+#define V4V_DOMID_ANY           0x7fffU
>>>
>>> I think I asked this before - why not use one of the pre-existing
>>> DOMID values? And if there is a good reason, it should be said
>>> here in a comment, to avoid the same question being asked
>>> later again.
>>>
>>>>...
>>>>+typedef uint64_t v4v_pfn_t;
>>>
>>> We already have xen_pfn_t, so why do you need yet another
>>> flavor?
>>>
>>>>...
>>>>+struct v4v_info
>>>>+{
>>>>+    uint64_t ring_magic;
>>>>+    uint64_t data_magic;
>>>>+    evtchn_port_t evtchn;
>>>
>>> Missing padding at the end?
>>>
>>>>+};
>>>>+typedef struct v4v_info v4v_info_t;
>>>>+
>>>>+#define V4V_ROUNDUP(a) (((a) +0xf ) & ~0xf)
>>>
>>> Doesn't seem to belong here. Or is the subsequent comment
>>> actually related to this (in which case it should be moved ahead
>>> of the definition and made match it).
>>>
>>>>+/*
>>>>+ * 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
>>>>+ */
>>>>...
>>>>+/*
>>>>+ * HYPERCALLS
>>>>+ */
>>>>...
>>>
>>> In the block below here, please get the naming (do_v4v_op()
>>> vs v4v_hypercall()) and the use of newlines (either always one
>>> or always two between individual hypercall descriptions)
>>> consistent. Hmm, even the descriptions don't seem to always
>>> match the definitions (not really obvious because apparently
>>> again the descriptions follow the definitions, whereas the
>>> opposite is the usual way to arrange things).
>>>
>>>>--- /dev/null
>>>>+++ b/xen/include/xen/v4v_utils.h
>>>>...
>>>>+/* Compiler specific hacks */
>>>>+#if defined(__GNUC__)
>>>>+# define V4V_UNUSED __attribute__ ((unused))
>>>>+# ifndef __STRICT_ANSI__
>>>>+#  define V4V_INLINE inline
>>>>+# else
>>>>+#  define V4V_INLINE
>>>>+# endif
>>>>+#else /* !__GNUC__ */
>>>>+# define V4V_UNUSED
>>>>+# define V4V_INLINE
>>>>+#endif
>>>
>>> This suggests the header is really intended to be public?
>>>
>>>>...
>>>>+static V4V_INLINE uint32_t
>>>>+v4v_ring_bytes_to_read (volatile struct v4v_ring *r)
>>>
>>> No space between function name and opening parenthesis
>>> (throughout this file).
>>>
>>>>...
>>>>+V4V_UNUSED static V4V_INLINE ssize_t
>>>
>>> V4V_UNUSED? Doesn't make sense in conjunction with
>>> V4V_INLINE, at least as long as you're using GNU extensions
>>> anyway (see above as to the disposition of the header).
>>>
>>>>+v4v_copy_out (struct v4v_ring *r, struct v4v_addr *from, uint32_t *
>> protocol,
>>>>+              void *_buf, size_t t, int consume)
>>>
>>> Dead functions shouldn't be placed here.
>>>
>>>>...
>>>>+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)
>>>>+{
>>>
>>> What's the point of having a declaration followed immediately by
>>> a definition? Also, the function is dead too.
>>>
>>
>> This file (v4v_utils.h) has utility that could be used by drivers, we don't
>> use
>> them in Xen but we through it will be convenient to have such function
>> accessible for one to write a v4v driver a v4v driver.
>>
>> What would be the right place for those?
>
> I think public/io/ would be the best matching place, but it's
> certainly also not ideal. Maybe we ought to introduce public/lib/
> or some such for it?
>
> But then again I don't see how this comment of yours relates to
> the earlier comments I made.
>

Ok I have removed this file from the patch series,  we already have a
copy of this file in the Linux driver so those helper functions can be found
there.

Thanks,
Jean

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

From xen-devel-bounces@lists.xen.org Sat Sep 01 20:59:11 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 01 Sep 2012 20: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 1T7um5-0003Vq-6L; Sat, 01 Sep 2012 20:58:37 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jean.guyader@gmail.com>) id 1T7um3-0003Vh-FV
	for xen-devel@lists.xen.org; Sat, 01 Sep 2012 20:58:35 +0000
Received: from [85.158.139.83:58250] by server-7.bemta-5.messagelabs.com id
	30/1D-19703-AF672405; Sat, 01 Sep 2012 20:58:34 +0000
X-Env-Sender: jean.guyader@gmail.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1346533112!27989257!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-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7509 invoked from network); 1 Sep 2012 20:58:33 -0000
Received: from mail-vc0-f173.google.com (HELO mail-vc0-f173.google.com)
	(209.85.220.173)
	by server-15.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Sep 2012 20:58:33 -0000
Received: by vcbgb23 with SMTP id gb23so5447386vcb.32
	for <xen-devel@lists.xen.org>; Sat, 01 Sep 2012 13:58:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to
	:cc:content-type;
	bh=ubssRgY8Ix1ujc7mihXN4Q1avEbiDqM2yAZmhY0uQUg=;
	b=w9lLAHVjm4gprw1VDvO60gd9uOfbMNq/5TvXCvB1wDMUbAB0eHNbckuTy+kwk0TSYr
	0ISOddHfXYx5LFCllMGRqXEP9QDPKe8SPPZD4Voum2KxlZD6Dx0ZON2o3w4/+Iyb+rN3
	dKOxo3M69YToFA4Lyk6PLw2WE+GBJWHWlQuQ5FCXp3eZ/dngZY9S6NWeZNG5SDaa/Crp
	Lbm0GUyEL5nPlkw6WIEFejDJXyvki6a2joOJWDI7Kf31brHHInXbdAcsX2/5gTW04qAU
	d8U1xJtUxOy1QB6OXpdn7DZl+6DkL1YVJj+BmCPzE9JkuPNThgKbBMbHHIU6+48nBIC8
	Vt9A==
Received: by 10.52.90.83 with SMTP id bu19mr6830943vdb.64.1346533112364; Sat,
	01 Sep 2012 13:58:32 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.58.91.72 with HTTP; Sat, 1 Sep 2012 13:58:12 -0700 (PDT)
In-Reply-To: <5037ECE2020000780008A7D5@nat28.tlf.novell.com>
References: <1344023454-31425-1-git-send-email-jean.guyader@citrix.com>
	<1344023454-31425-6-git-send-email-jean.guyader@citrix.com>
	<501FA05C0200007800092CD7@nat28.tlf.novell.com>
	<CAEBdQ90ObLybAxzYceEQyEVtpP7mMmPrn7NryH3h-+dTXBNDUw@mail.gmail.com>
	<5037ECE2020000780008A7D5@nat28.tlf.novell.com>
From: Jean Guyader <jean.guyader@gmail.com>
Date: Sat, 1 Sep 2012 13:58:12 -0700
Message-ID: <CAEBdQ93kXanGiP+yOhiecMZv3nYtNt9XvrXKvhA3WBdm3f+PKQ@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 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>
Content-Type: text/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 August 2012 13:06, Jan Beulich <JBeulich@suse.com> wrote:
>>>> On 23.08.12 at 13:57, Jean Guyader <jean.guyader@gmail.com> wrote:
>> On 6 August 2012 09:45, Jan Beulich <JBeulich@suse.com> wrote:
>>>>>> On 03.08.12 at 21:50, Jean Guyader <jean.guyader@citrix.com> wrote:
>>>>--- /dev/null
>>>>+++ b/xen/include/public/v4v.h
>>>>...
>>>>+#define V4V_DOMID_ANY           0x7fffU
>>>
>>> I think I asked this before - why not use one of the pre-existing
>>> DOMID values? And if there is a good reason, it should be said
>>> here in a comment, to avoid the same question being asked
>>> later again.
>>>
>>>>...
>>>>+typedef uint64_t v4v_pfn_t;
>>>
>>> We already have xen_pfn_t, so why do you need yet another
>>> flavor?
>>>
>>>>...
>>>>+struct v4v_info
>>>>+{
>>>>+    uint64_t ring_magic;
>>>>+    uint64_t data_magic;
>>>>+    evtchn_port_t evtchn;
>>>
>>> Missing padding at the end?
>>>
>>>>+};
>>>>+typedef struct v4v_info v4v_info_t;
>>>>+
>>>>+#define V4V_ROUNDUP(a) (((a) +0xf ) & ~0xf)
>>>
>>> Doesn't seem to belong here. Or is the subsequent comment
>>> actually related to this (in which case it should be moved ahead
>>> of the definition and made match it).
>>>
>>>>+/*
>>>>+ * 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
>>>>+ */
>>>>...
>>>>+/*
>>>>+ * HYPERCALLS
>>>>+ */
>>>>...
>>>
>>> In the block below here, please get the naming (do_v4v_op()
>>> vs v4v_hypercall()) and the use of newlines (either always one
>>> or always two between individual hypercall descriptions)
>>> consistent. Hmm, even the descriptions don't seem to always
>>> match the definitions (not really obvious because apparently
>>> again the descriptions follow the definitions, whereas the
>>> opposite is the usual way to arrange things).
>>>
>>>>--- /dev/null
>>>>+++ b/xen/include/xen/v4v_utils.h
>>>>...
>>>>+/* Compiler specific hacks */
>>>>+#if defined(__GNUC__)
>>>>+# define V4V_UNUSED __attribute__ ((unused))
>>>>+# ifndef __STRICT_ANSI__
>>>>+#  define V4V_INLINE inline
>>>>+# else
>>>>+#  define V4V_INLINE
>>>>+# endif
>>>>+#else /* !__GNUC__ */
>>>>+# define V4V_UNUSED
>>>>+# define V4V_INLINE
>>>>+#endif
>>>
>>> This suggests the header is really intended to be public?
>>>
>>>>...
>>>>+static V4V_INLINE uint32_t
>>>>+v4v_ring_bytes_to_read (volatile struct v4v_ring *r)
>>>
>>> No space between function name and opening parenthesis
>>> (throughout this file).
>>>
>>>>...
>>>>+V4V_UNUSED static V4V_INLINE ssize_t
>>>
>>> V4V_UNUSED? Doesn't make sense in conjunction with
>>> V4V_INLINE, at least as long as you're using GNU extensions
>>> anyway (see above as to the disposition of the header).
>>>
>>>>+v4v_copy_out (struct v4v_ring *r, struct v4v_addr *from, uint32_t *
>> protocol,
>>>>+              void *_buf, size_t t, int consume)
>>>
>>> Dead functions shouldn't be placed here.
>>>
>>>>...
>>>>+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)
>>>>+{
>>>
>>> What's the point of having a declaration followed immediately by
>>> a definition? Also, the function is dead too.
>>>
>>
>> This file (v4v_utils.h) has utility that could be used by drivers, we don't
>> use
>> them in Xen but we through it will be convenient to have such function
>> accessible for one to write a v4v driver a v4v driver.
>>
>> What would be the right place for those?
>
> I think public/io/ would be the best matching place, but it's
> certainly also not ideal. Maybe we ought to introduce public/lib/
> or some such for it?
>
> But then again I don't see how this comment of yours relates to
> the earlier comments I made.
>

Ok I have removed this file from the patch series,  we already have a
copy of this file in the Linux driver so those helper functions can be found
there.

Thanks,
Jean

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

From xen-devel-bounces@lists.xen.org Sun Sep 02 01:59:41 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 02 Sep 2012 01: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 1T7zSq-0002uS-7K; Sun, 02 Sep 2012 01:59:04 +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 1T7zSp-0002uN-78
	for xen-devel@lists.xen.org; Sun, 02 Sep 2012 01:59:03 +0000
Received: from [85.158.138.51:5397] by server-9.bemta-3.messagelabs.com id
	23/16-15390-66DB2405; Sun, 02 Sep 2012 01:59:02 +0000
X-Env-Sender: ben.guthro@gmail.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1346551140!26339965!1
X-Originating-IP: [209.85.210.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24034 invoked from network); 2 Sep 2012 01:59:01 -0000
Received: from mail-iy0-f173.google.com (HELO mail-iy0-f173.google.com)
	(209.85.210.173)
	by server-15.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Sep 2012 01:59:01 -0000
Received: by iakx26 with SMTP id x26so8252710iak.32
	for <xen-devel@lists.xen.org>; Sat, 01 Sep 2012 18:59: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=OkTWrpRGudTT9+oqpra0TZhYg5kxfidJ4+n8pFVtkj8=;
	b=giAkbb9NLurBrDfEV2HdTGtu6OlSk/2FqrtQnohWeqQQga0/Otoy5V4sGW54HS7phi
	P/ubyLWk7rctEyzDhosGmv7YJzCQ0JoxyWe/cXaq8T5yYHOHmqMK+UEYto41V9lyjNAb
	RiCyDdcShgvuAJSQpgMurgP9IgNs0dvyTluJ4Eul1HB5eYIxAg/bDUnbGizWYXhNwPQx
	P8Ij0fcbhUnKFkvXgfisLdfaibL0pv3Z91oMcqq3jfJ3YM5YXaXezlAoN7SGlTZklvj+
	0urx+LanGQRIm3r+LsKWF2QoA6nyJK1L3lmwNCm0gIMtsfjwlKfxVnRCnKdgJoiF9rEg
	pkbA==
MIME-Version: 1.0
Received: by 10.50.173.69 with SMTP id bi5mr7176868igc.37.1346551140107; Sat,
	01 Sep 2012 18:59:00 -0700 (PDT)
Received: by 10.64.28.203 with HTTP; Sat, 1 Sep 2012 18:59:00 -0700 (PDT)
In-Reply-To: <5040F7B00200007800097E94@nat28.tlf.novell.com>
References: <1346148361.9975.3.camel@zakaz.uk.xensource.com>
	<1346425932.27277.230.camel@zakaz.uk.xensource.com>
	<5040F7B00200007800097E94@nat28.tlf.novell.com>
Date: Sat, 1 Sep 2012 21:59:00 -0400
X-Google-Sender-Auth: mbdcdpuTjd90foij-X3GEalDl8o
Message-ID: <CAOvdn6WKW-Aj=XrShCi+V-CM1x1Uw5LOPsv0E=BeEidxdoehrQ@mail.gmail.com>
From: Ben Guthro <ben@guthro.net>
To: Jan Beulich <JBeulich@suse.com>
Cc: "george.dunlap@eu.citrix.com" <george.dunlap@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [Xen-users] 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 Fri, Aug 31, 2012 at 11:43 AM, Jan Beulich <JBeulich@suse.com> wrote:
>>>> On 31.08.12 at 17:12, Ian Campbell <Ian.Campbell@citrix.com> wrote:
>> On Tue, 2012-08-28 at 11:06 +0100, Ian Campbell wrote:

<snip>

>>>     * S3 regression(s?) reported by Ben Guthro (Ben & Jan Beulich)
>>
>> AIUI this one isn't though.
>
> Correct.

This is still on my radar. I was in San Diego for all of last week.
It will be my priority to try to root cause this week.

Ben

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

From xen-devel-bounces@lists.xen.org Sun Sep 02 01:59:41 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 02 Sep 2012 01: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 1T7zSq-0002uS-7K; Sun, 02 Sep 2012 01:59:04 +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 1T7zSp-0002uN-78
	for xen-devel@lists.xen.org; Sun, 02 Sep 2012 01:59:03 +0000
Received: from [85.158.138.51:5397] by server-9.bemta-3.messagelabs.com id
	23/16-15390-66DB2405; Sun, 02 Sep 2012 01:59:02 +0000
X-Env-Sender: ben.guthro@gmail.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1346551140!26339965!1
X-Originating-IP: [209.85.210.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24034 invoked from network); 2 Sep 2012 01:59:01 -0000
Received: from mail-iy0-f173.google.com (HELO mail-iy0-f173.google.com)
	(209.85.210.173)
	by server-15.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Sep 2012 01:59:01 -0000
Received: by iakx26 with SMTP id x26so8252710iak.32
	for <xen-devel@lists.xen.org>; Sat, 01 Sep 2012 18:59: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=OkTWrpRGudTT9+oqpra0TZhYg5kxfidJ4+n8pFVtkj8=;
	b=giAkbb9NLurBrDfEV2HdTGtu6OlSk/2FqrtQnohWeqQQga0/Otoy5V4sGW54HS7phi
	P/ubyLWk7rctEyzDhosGmv7YJzCQ0JoxyWe/cXaq8T5yYHOHmqMK+UEYto41V9lyjNAb
	RiCyDdcShgvuAJSQpgMurgP9IgNs0dvyTluJ4Eul1HB5eYIxAg/bDUnbGizWYXhNwPQx
	P8Ij0fcbhUnKFkvXgfisLdfaibL0pv3Z91oMcqq3jfJ3YM5YXaXezlAoN7SGlTZklvj+
	0urx+LanGQRIm3r+LsKWF2QoA6nyJK1L3lmwNCm0gIMtsfjwlKfxVnRCnKdgJoiF9rEg
	pkbA==
MIME-Version: 1.0
Received: by 10.50.173.69 with SMTP id bi5mr7176868igc.37.1346551140107; Sat,
	01 Sep 2012 18:59:00 -0700 (PDT)
Received: by 10.64.28.203 with HTTP; Sat, 1 Sep 2012 18:59:00 -0700 (PDT)
In-Reply-To: <5040F7B00200007800097E94@nat28.tlf.novell.com>
References: <1346148361.9975.3.camel@zakaz.uk.xensource.com>
	<1346425932.27277.230.camel@zakaz.uk.xensource.com>
	<5040F7B00200007800097E94@nat28.tlf.novell.com>
Date: Sat, 1 Sep 2012 21:59:00 -0400
X-Google-Sender-Auth: mbdcdpuTjd90foij-X3GEalDl8o
Message-ID: <CAOvdn6WKW-Aj=XrShCi+V-CM1x1Uw5LOPsv0E=BeEidxdoehrQ@mail.gmail.com>
From: Ben Guthro <ben@guthro.net>
To: Jan Beulich <JBeulich@suse.com>
Cc: "george.dunlap@eu.citrix.com" <george.dunlap@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [Xen-users] 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 Fri, Aug 31, 2012 at 11:43 AM, Jan Beulich <JBeulich@suse.com> wrote:
>>>> On 31.08.12 at 17:12, Ian Campbell <Ian.Campbell@citrix.com> wrote:
>> On Tue, 2012-08-28 at 11:06 +0100, Ian Campbell wrote:

<snip>

>>>     * S3 regression(s?) reported by Ben Guthro (Ben & Jan Beulich)
>>
>> AIUI this one isn't though.
>
> Correct.

This is still on my radar. I was in San Diego for all of last week.
It will be my priority to try to root cause this week.

Ben

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

From xen-devel-bounces@lists.xen.org Sun Sep 02 02:09:42 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 02 Sep 2012 02:09:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T7zcc-0003Pt-AH; Sun, 02 Sep 2012 02:09:10 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Santosh.Jodh@citrix.com>) id 1T7zcb-0003Pl-4h
	for xen-devel@lists.xen.org; Sun, 02 Sep 2012 02:09:09 +0000
Received: from [85.158.138.51:60626] by server-4.bemta-3.messagelabs.com id
	95/5B-24831-FBFB2405; Sun, 02 Sep 2012 02:09:03 +0000
X-Env-Sender: Santosh.Jodh@citrix.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1346551739!9419520!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNjc3NDQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 902 invoked from network); 2 Sep 2012 02:09: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;
	2 Sep 2012 02:09:01 -0000
X-IronPort-AV: E=Sophos;i="4.80,354,1344211200"; d="scan'208";a="36532845"
Received: from sjcpmailmx02.citrite.net ([10.216.14.75])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Sep 2012 02:08:59 +0000
Received: from SJCPMAILBOX01.citrite.net ([10.216.4.72]) by
	SJCPMAILMX02.citrite.net ([10.216.14.75]) with mapi;
	Sat, 1 Sep 2012 19:08:58 -0700
From: Santosh Jodh <Santosh.Jodh@citrix.com>
To: Keir Fraser <keir.xen@gmail.com>, Sander Eikelenboom <linux@eikelenboom.it>
Date: Sat, 1 Sep 2012 19:08:39 -0700
Thread-Topic: [Xen-devel] Using debug-key 'o:  Dump IOMMU p2m table, locks
	up machine
Thread-Index: Ac2H5anSA9JOwrAdv0yUGY6DtFwLdQAfNVTwAATWEUoADm300A==
Message-ID: <7914B38A4445B34AA16EB9F1352942F1012F0F6F4BA7@SJCPMAILBOX01.citrite.net>
References: <7914B38A4445B34AA16EB9F1352942F1012F0F6F4B98@SJCPMAILBOX01.citrite.net>
	<CC681CDD.3D966%keir.xen@gmail.com>
In-Reply-To: <CC681CDD.3D966%keir.xen@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Cc: "wei.wang2@amd.com" <wei.wang2@amd.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Using debug-key 'o:  Dump IOMMU p2m table,
 locks up machine
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


> -----Original Message-----
> From: Keir Fraser [mailto:keir.xen@gmail.com]
> Sent: Saturday, September 01, 2012 12:13 PM
> To: Santosh Jodh; Sander Eikelenboom
> Cc: wei.wang2@amd.com; xen-devel@lists.xen.org
> Subject: Re: [Xen-devel] Using debug-key 'o: Dump IOMMU p2m table, locks
> up machine
> 
> On 01/09/2012 18:03, "Santosh Jodh" <Santosh.Jodh@citrix.com> wrote:
> 
> >> It might schedule softirqs but that won't include scheduling or
> >> running any guest vcpus. The vcpu that happens to be running on that
> >> cpu at the time the debug dump starts, will be stuck unrunnable until the
> dump completes.
> >
> > Why does'nt that vCPU get scheduled on some other pCPU? Is there  a
> > way to yield the CPU from the key handler?
> 
> It can't be descheduled from this pCPU without running through the
> scheduler. You could try running the handler in a tasklet -- a tasklet causes
> other vCPUs to be descheduled from that pCPU, before it starts running.
> 
> So you'd register a keyhandler which does a tasklet_schedule(), and do your
> logging work in the tasklet handler.
> 
> Worth a shot maybe?

Yes - certainly. Is there a reason why all key handlers should not be tasklets?


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

From xen-devel-bounces@lists.xen.org Sun Sep 02 02:09:42 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 02 Sep 2012 02:09:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T7zcc-0003Pt-AH; Sun, 02 Sep 2012 02:09:10 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Santosh.Jodh@citrix.com>) id 1T7zcb-0003Pl-4h
	for xen-devel@lists.xen.org; Sun, 02 Sep 2012 02:09:09 +0000
Received: from [85.158.138.51:60626] by server-4.bemta-3.messagelabs.com id
	95/5B-24831-FBFB2405; Sun, 02 Sep 2012 02:09:03 +0000
X-Env-Sender: Santosh.Jodh@citrix.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1346551739!9419520!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNjc3NDQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 902 invoked from network); 2 Sep 2012 02:09: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;
	2 Sep 2012 02:09:01 -0000
X-IronPort-AV: E=Sophos;i="4.80,354,1344211200"; d="scan'208";a="36532845"
Received: from sjcpmailmx02.citrite.net ([10.216.14.75])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Sep 2012 02:08:59 +0000
Received: from SJCPMAILBOX01.citrite.net ([10.216.4.72]) by
	SJCPMAILMX02.citrite.net ([10.216.14.75]) with mapi;
	Sat, 1 Sep 2012 19:08:58 -0700
From: Santosh Jodh <Santosh.Jodh@citrix.com>
To: Keir Fraser <keir.xen@gmail.com>, Sander Eikelenboom <linux@eikelenboom.it>
Date: Sat, 1 Sep 2012 19:08:39 -0700
Thread-Topic: [Xen-devel] Using debug-key 'o:  Dump IOMMU p2m table, locks
	up machine
Thread-Index: Ac2H5anSA9JOwrAdv0yUGY6DtFwLdQAfNVTwAATWEUoADm300A==
Message-ID: <7914B38A4445B34AA16EB9F1352942F1012F0F6F4BA7@SJCPMAILBOX01.citrite.net>
References: <7914B38A4445B34AA16EB9F1352942F1012F0F6F4B98@SJCPMAILBOX01.citrite.net>
	<CC681CDD.3D966%keir.xen@gmail.com>
In-Reply-To: <CC681CDD.3D966%keir.xen@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Cc: "wei.wang2@amd.com" <wei.wang2@amd.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Using debug-key 'o:  Dump IOMMU p2m table,
 locks up machine
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


> -----Original Message-----
> From: Keir Fraser [mailto:keir.xen@gmail.com]
> Sent: Saturday, September 01, 2012 12:13 PM
> To: Santosh Jodh; Sander Eikelenboom
> Cc: wei.wang2@amd.com; xen-devel@lists.xen.org
> Subject: Re: [Xen-devel] Using debug-key 'o: Dump IOMMU p2m table, locks
> up machine
> 
> On 01/09/2012 18:03, "Santosh Jodh" <Santosh.Jodh@citrix.com> wrote:
> 
> >> It might schedule softirqs but that won't include scheduling or
> >> running any guest vcpus. The vcpu that happens to be running on that
> >> cpu at the time the debug dump starts, will be stuck unrunnable until the
> dump completes.
> >
> > Why does'nt that vCPU get scheduled on some other pCPU? Is there  a
> > way to yield the CPU from the key handler?
> 
> It can't be descheduled from this pCPU without running through the
> scheduler. You could try running the handler in a tasklet -- a tasklet causes
> other vCPUs to be descheduled from that pCPU, before it starts running.
> 
> So you'd register a keyhandler which does a tasklet_schedule(), and do your
> logging work in the tasklet handler.
> 
> Worth a shot maybe?

Yes - certainly. Is there a reason why all key handlers should not be tasklets?


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

From xen-devel-bounces@lists.xen.org Sun Sep 02 04:42:06 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 02 Sep 2012 04: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 1T81zx-00045A-Qj; Sun, 02 Sep 2012 04:41:25 +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 1T81zw-000455-3A
	for xen-devel@lists.xen.org; Sun, 02 Sep 2012 04:41:24 +0000
Received: from [85.158.143.35:57151] by server-3.bemta-4.messagelabs.com id
	82/35-08232-373E2405; Sun, 02 Sep 2012 04:41:23 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-2.tower-21.messagelabs.com!1346560876!5315538!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA0OTc5Mjk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16893 invoked from network); 2 Sep 2012 04:41:16 -0000
Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25)
	by server-2.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 2 Sep 2012 04:41: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 D4762279D
	for <xen-devel@lists.xen.org>; Sun,  2 Sep 2012 07:41:15 +0300 (EEST)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id 788DC2005D; Sun,  2 Sep 2012 07:41:15 +0300 (EEST)
Date: Sun, 2 Sep 2012 07:41:15 +0300
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: xen-devel@lists.xen.org
Message-ID: <20120902044115.GD8912@reaktio.net>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="x+6KMIRAuhnl3hBn"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
User-Agent: Mutt/1.5.20 (2009-06-14)
Subject: [Xen-devel] [PATCH] xl.cfg: videoram and stdvga documentation
	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>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--x+6KMIRAuhnl3hBn
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit

Hello,

xl.cfg.pod.5 documentation tweaks/improvements:

- videoram: Document that only qemu-xen-traditional device-model currently
   supports changing the amount of video memory for stdvga graphics device.

- videoram: Better document the default amount of videoram for both stdvga
  and Cirrus.

- stdvga: Add a note that stdvga allows bigger amount of videoram and
  bigger resolutions.


Signed-off-by: Pasi Kärkkäinen <pasik@iki.fi>

--- docs/man/xl.cfg.pod.5.orig  2012-08-25 02:10:29.199847688 +0300
+++ docs/man/xl.cfg.pod.5       2012-09-02 07:16:39.316782158 +0300
@@ -716,10 +716,18 @@
 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
-at 32 bpp.
+option (see below). 
+The default amount of video ram for stdvga is 8MB which is sufficient 
+for e.g. 1600x1200 at 32bpp.
+
+When using the emulated Cirrus graphics card (B<stdvga=0>) 
+the amount of video ram is fixed at 4MB which is sufficient 
+for 1024x768 at 32 bpp.
+
+videoram option is currently only available when using the 
+qemu-xen-traditional device-model. Upstream qemu-xen device-model
+currently doesn't support changing the amount of video memory
+for the emulated graphics device.
 
 =item B<stdvga=BOOLEAN>
 
@@ -727,6 +735,7 @@
 emulated graphics device. The default is false which means to emulate
 a Cirrus Logic GD5446 VGA card. If your guest supports VBE 2.0 or
 later (e.g. Windows XP onwards) then you should enable this.
+stdvga supports more video ram and bigger resolutions than Cirrus.
 
 =item B<vnc=BOOLEAN>


--x+6KMIRAuhnl3hBn
Content-Type: text/x-diff; charset=us-ascii
Content-Disposition: attachment; filename="xl.cfg.pod.5-videoram-stdvga.patch"

--- docs/man/xl.cfg.pod.5.orig	2012-08-25 02:10:29.199847688 +0300
+++ docs/man/xl.cfg.pod.5	2012-09-02 07:16:39.316782158 +0300
@@ -716,10 +716,18 @@
 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
-at 32 bpp.
+option (see below). 
+The default amount of video ram for stdvga is 8MB which is sufficient 
+for e.g. 1600x1200 at 32bpp.
+
+When using the emulated Cirrus graphics card (B<stdvga=0>) 
+the amount of video ram is fixed at 4MB which is sufficient 
+for 1024x768 at 32 bpp.
+
+videoram option is currently only available when using the 
+qemu-xen-traditional device-model. Upstream qemu-xen device-model
+currently doesn't support changing the amount of video memory
+for the emulated graphics device.
 
 =item B<stdvga=BOOLEAN>
 
@@ -727,6 +735,7 @@
 emulated graphics device. The default is false which means to emulate
 a Cirrus Logic GD5446 VGA card. If your guest supports VBE 2.0 or
 later (e.g. Windows XP onwards) then you should enable this.
+stdvga supports more video ram and bigger resolutions than Cirrus.
 
 =item B<vnc=BOOLEAN>
 

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

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

--x+6KMIRAuhnl3hBn--


From xen-devel-bounces@lists.xen.org Sun Sep 02 04:42:06 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 02 Sep 2012 04: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 1T81zx-00045A-Qj; Sun, 02 Sep 2012 04:41:25 +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 1T81zw-000455-3A
	for xen-devel@lists.xen.org; Sun, 02 Sep 2012 04:41:24 +0000
Received: from [85.158.143.35:57151] by server-3.bemta-4.messagelabs.com id
	82/35-08232-373E2405; Sun, 02 Sep 2012 04:41:23 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-2.tower-21.messagelabs.com!1346560876!5315538!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA0OTc5Mjk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16893 invoked from network); 2 Sep 2012 04:41:16 -0000
Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25)
	by server-2.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 2 Sep 2012 04:41: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 D4762279D
	for <xen-devel@lists.xen.org>; Sun,  2 Sep 2012 07:41:15 +0300 (EEST)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id 788DC2005D; Sun,  2 Sep 2012 07:41:15 +0300 (EEST)
Date: Sun, 2 Sep 2012 07:41:15 +0300
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: xen-devel@lists.xen.org
Message-ID: <20120902044115.GD8912@reaktio.net>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="x+6KMIRAuhnl3hBn"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
User-Agent: Mutt/1.5.20 (2009-06-14)
Subject: [Xen-devel] [PATCH] xl.cfg: videoram and stdvga documentation
	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>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--x+6KMIRAuhnl3hBn
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit

Hello,

xl.cfg.pod.5 documentation tweaks/improvements:

- videoram: Document that only qemu-xen-traditional device-model currently
   supports changing the amount of video memory for stdvga graphics device.

- videoram: Better document the default amount of videoram for both stdvga
  and Cirrus.

- stdvga: Add a note that stdvga allows bigger amount of videoram and
  bigger resolutions.


Signed-off-by: Pasi Kärkkäinen <pasik@iki.fi>

--- docs/man/xl.cfg.pod.5.orig  2012-08-25 02:10:29.199847688 +0300
+++ docs/man/xl.cfg.pod.5       2012-09-02 07:16:39.316782158 +0300
@@ -716,10 +716,18 @@
 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
-at 32 bpp.
+option (see below). 
+The default amount of video ram for stdvga is 8MB which is sufficient 
+for e.g. 1600x1200 at 32bpp.
+
+When using the emulated Cirrus graphics card (B<stdvga=0>) 
+the amount of video ram is fixed at 4MB which is sufficient 
+for 1024x768 at 32 bpp.
+
+videoram option is currently only available when using the 
+qemu-xen-traditional device-model. Upstream qemu-xen device-model
+currently doesn't support changing the amount of video memory
+for the emulated graphics device.
 
 =item B<stdvga=BOOLEAN>
 
@@ -727,6 +735,7 @@
 emulated graphics device. The default is false which means to emulate
 a Cirrus Logic GD5446 VGA card. If your guest supports VBE 2.0 or
 later (e.g. Windows XP onwards) then you should enable this.
+stdvga supports more video ram and bigger resolutions than Cirrus.
 
 =item B<vnc=BOOLEAN>


--x+6KMIRAuhnl3hBn
Content-Type: text/x-diff; charset=us-ascii
Content-Disposition: attachment; filename="xl.cfg.pod.5-videoram-stdvga.patch"

--- docs/man/xl.cfg.pod.5.orig	2012-08-25 02:10:29.199847688 +0300
+++ docs/man/xl.cfg.pod.5	2012-09-02 07:16:39.316782158 +0300
@@ -716,10 +716,18 @@
 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
-at 32 bpp.
+option (see below). 
+The default amount of video ram for stdvga is 8MB which is sufficient 
+for e.g. 1600x1200 at 32bpp.
+
+When using the emulated Cirrus graphics card (B<stdvga=0>) 
+the amount of video ram is fixed at 4MB which is sufficient 
+for 1024x768 at 32 bpp.
+
+videoram option is currently only available when using the 
+qemu-xen-traditional device-model. Upstream qemu-xen device-model
+currently doesn't support changing the amount of video memory
+for the emulated graphics device.
 
 =item B<stdvga=BOOLEAN>
 
@@ -727,6 +735,7 @@
 emulated graphics device. The default is false which means to emulate
 a Cirrus Logic GD5446 VGA card. If your guest supports VBE 2.0 or
 later (e.g. Windows XP onwards) then you should enable this.
+stdvga supports more video ram and bigger resolutions than Cirrus.
 
 =item B<vnc=BOOLEAN>
 

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

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

--x+6KMIRAuhnl3hBn--


From xen-devel-bounces@lists.xen.org Sun Sep 02 04:47:02 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 02 Sep 2012 04: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 1T824u-0004Ca-JK; Sun, 02 Sep 2012 04:46:32 +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 1T824t-0004CR-JR
	for xen-devel@lists.xen.org; Sun, 02 Sep 2012 04:46:31 +0000
Received: from [85.158.138.51:64365] by server-7.bemta-3.messagelabs.com id
	57/32-32000-6A4E2405; Sun, 02 Sep 2012 04:46:30 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-8.tower-174.messagelabs.com!1346561188!28070450!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA0OTc5Mjk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2181 invoked from network); 2 Sep 2012 04:46:28 -0000
Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25)
	by server-8.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 2 Sep 2012 04:46:28 -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 396F227E6;
	Sun,  2 Sep 2012 07:46:27 +0300 (EEST)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id DD7FD2005D; Sun,  2 Sep 2012 07:46:26 +0300 (EEST)
Date: Sun, 2 Sep 2012 07:46:26 +0300
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120902044626.GE8912@reaktio.net>
References: <1346148361.9975.3.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1346148361.9975.3.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: xen-users <xen-users@lists.xen.org>, xen-devel <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="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, Aug 28, 2012 at 11:06:01AM +0100, Ian Campbell wrote:
> =

>     * xl.cfg(5) documentation patch for qemu-upstream
>       videoram/videomem support:
>       http://lists.xen.org/archives/html/xen-devel/2012-05/msg00250.html
>       qemu-upstream doesn't support specifying videomem size for the
>       HVM guest cirrus/stdvga.  (but this works with
>       qemu-xen-traditional). (Pasi K=E4rkk=E4inen)
> =


Patch sent to the list.

-- Pasi


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

From xen-devel-bounces@lists.xen.org Sun Sep 02 04:47:02 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 02 Sep 2012 04: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 1T824u-0004Ca-JK; Sun, 02 Sep 2012 04:46:32 +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 1T824t-0004CR-JR
	for xen-devel@lists.xen.org; Sun, 02 Sep 2012 04:46:31 +0000
Received: from [85.158.138.51:64365] by server-7.bemta-3.messagelabs.com id
	57/32-32000-6A4E2405; Sun, 02 Sep 2012 04:46:30 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-8.tower-174.messagelabs.com!1346561188!28070450!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA0OTc5Mjk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2181 invoked from network); 2 Sep 2012 04:46:28 -0000
Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25)
	by server-8.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 2 Sep 2012 04:46:28 -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 396F227E6;
	Sun,  2 Sep 2012 07:46:27 +0300 (EEST)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id DD7FD2005D; Sun,  2 Sep 2012 07:46:26 +0300 (EEST)
Date: Sun, 2 Sep 2012 07:46:26 +0300
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120902044626.GE8912@reaktio.net>
References: <1346148361.9975.3.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1346148361.9975.3.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: xen-users <xen-users@lists.xen.org>, xen-devel <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="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, Aug 28, 2012 at 11:06:01AM +0100, Ian Campbell wrote:
> =

>     * xl.cfg(5) documentation patch for qemu-upstream
>       videoram/videomem support:
>       http://lists.xen.org/archives/html/xen-devel/2012-05/msg00250.html
>       qemu-upstream doesn't support specifying videomem size for the
>       HVM guest cirrus/stdvga.  (but this works with
>       qemu-xen-traditional). (Pasi K=E4rkk=E4inen)
> =


Patch sent to the list.

-- Pasi


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

From xen-devel-bounces@lists.xen.org Sun Sep 02 05:36:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 02 Sep 2012 05:36:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T82qh-00051U-3S; Sun, 02 Sep 2012 05:35:55 +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 1T82qf-00051P-Cv
	for xen-devel@lists.xen.org; Sun, 02 Sep 2012 05:35:53 +0000
Received: from [85.158.143.99:63467] by server-3.bemta-4.messagelabs.com id
	0D/D4-08232-830F2405; Sun, 02 Sep 2012 05:35:52 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-16.tower-216.messagelabs.com!1346564149!16837776!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA0OTc5Mjk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18499 invoked from network); 2 Sep 2012 05:35:50 -0000
Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25)
	by server-16.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 2 Sep 2012 05:35:50 -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 689AA2B22
	for <xen-devel@lists.xen.org>; Sun,  2 Sep 2012 08:35:49 +0300 (EEST)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id 333162005D; Sun,  2 Sep 2012 08:35:49 +0300 (EEST)
Date: Sun, 2 Sep 2012 08:35:49 +0300
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: xen-devel@lists.xen.org
Message-ID: <20120902053549.GF8912@reaktio.net>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="neYutvxvOLaeuPCA"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
User-Agent: Mutt/1.5.20 (2009-06-14)
Subject: [Xen-devel] [PATCH] xl.cfg: gfx_passthru documentation 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>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--neYutvxvOLaeuPCA
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit

Hello,

xl.cfg.pod.5 documentation improvements:

- gfx_passthru: Document gfx_passthru makes the GPU become primary in the guest
  and other generic info about gfx_passthru.


Signed-off-by: Pasi Kärkkäinen <pasik@iki.fi>

--- docs/man/xl.cfg.pod.5.orig1 2012-09-02 07:16:39.316782158 +0300
+++ docs/man/xl.cfg.pod.5       2012-09-02 08:26:40.081639087 +0300
@@ -968,7 +968,43 @@
 
 =item B<gfx_passthru=BOOLEAN>
 
-Enable graphics device PCI passthrough. XXX which device is passed through ?
+Enable graphics device PCI passthrough. This option makes the passthru
+graphics card become primary graphics card in the VM, so the Qemu emulated 
+graphics adapter is disabled, and the VNC console for the VM won't have
+any graphics output. All graphics output, including boot time Qemu BIOS
+messages from the VM, will go to the physical outputs of the passed thru
+physical graphics card.
+
+Graphics card PCI device to passthru is chosen with B<pci> option, 
+exactly in the same way as normal Xen PCI device passthru/assignment is done. 
+Note that gfx_passthru doesn't do any kind of sharing
+of the GPU, so you can only assign the GPU to one single VM at a time.
+
+gfx_passthru also enables various legacy VGA memory ranges, BARs, MMIOs, 
+and ioports to be passed thru to the VM, since those are required
+for correct operation of things like VGA BIOS, text mode, VBE, etc.
+
+Enabling gfx_passthru option also copies the physical graphics card 
+video bios to the guest memory, and executes the vbios in the guest 
+to get the graphics card initialized.
+
+Most graphics adapters require vendor specific tweaks for properly
+working graphics passthru. Xen currently includes necessary tweaks
+for Intel IGD (Integrated Graphics Device) GPUs.  
+
+Support for AMD/Nvidia gfx_passthru is not yet merged to Xen,
+but there are out-of-tree patches available.
+
+gfx_passthru is currently only supported with the qemu-xen-traditional
+device-model. Upstream qemu-xen device-model currently doesn't have
+support for gfx_passthru.
+
+Note that some graphics adapters (AMD/ATI cards, for example) don't
+necessarily require gfx_passthru option, so you can use the normal
+Xen PCI passthru to assign the graphics card as a secondary graphics card
+to the VM. Qemu emulated graphics card stays as the primary graphics card, 
+and you get VNC output from the Qemu-emulated primary adapter.
+
 
 =item B<nomigrate=BOOLEAN>


--neYutvxvOLaeuPCA
Content-Type: text/x-diff; charset=us-ascii
Content-Disposition: attachment; filename="xl.cfg.pod.5-gfx_passthru.patch"

--- docs/man/xl.cfg.pod.5.orig1	2012-09-02 07:16:39.316782158 +0300
+++ docs/man/xl.cfg.pod.5	2012-09-02 08:26:40.081639087 +0300
@@ -968,7 +968,43 @@
 
 =item B<gfx_passthru=BOOLEAN>
 
-Enable graphics device PCI passthrough. XXX which device is passed through ?
+Enable graphics device PCI passthrough. This option makes the passthru
+graphics card become primary graphics card in the VM, so the Qemu emulated 
+graphics adapter is disabled, and the VNC console for the VM won't have
+any graphics output. All graphics output, including boot time Qemu BIOS
+messages from the VM, will go to the physical outputs of the passed thru
+physical graphics card.
+
+Graphics card PCI device to passthru is chosen with B<pci> option, 
+exactly in the same way as normal Xen PCI device passthru/assignment is done. 
+Note that gfx_passthru doesn't do any kind of sharing
+of the GPU, so you can only assign the GPU to one single VM at a time.
+
+gfx_passthru also enables various legacy VGA memory ranges, BARs, MMIOs, 
+and ioports to be passed thru to the VM, since those are required
+for correct operation of things like VGA BIOS, text mode, VBE, etc.
+
+Enabling gfx_passthru option also copies the physical graphics card 
+video bios to the guest memory, and executes the vbios in the guest 
+to get the graphics card initialized.
+
+Most graphics adapters require vendor specific tweaks for properly
+working graphics passthru. Xen currently includes necessary tweaks
+for Intel IGD (Integrated Graphics Device) GPUs.  
+
+Support for AMD/Nvidia gfx_passthru is not yet merged to Xen,
+but there are out-of-tree patches available.
+
+gfx_passthru is currently only supported with the qemu-xen-traditional
+device-model. Upstream qemu-xen device-model currently doesn't have
+support for gfx_passthru.
+
+Note that some graphics adapters (AMD/ATI cards, for example) don't
+necessarily require gfx_passthru option, so you can use the normal
+Xen PCI passthru to assign the graphics card as a secondary graphics card
+to the VM. Qemu emulated graphics card stays as the primary graphics card, 
+and you get VNC output from the Qemu-emulated primary adapter.
+
 
 =item B<nomigrate=BOOLEAN>
 

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

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

--neYutvxvOLaeuPCA--


From xen-devel-bounces@lists.xen.org Sun Sep 02 05:36:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 02 Sep 2012 05:36:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T82qh-00051U-3S; Sun, 02 Sep 2012 05:35:55 +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 1T82qf-00051P-Cv
	for xen-devel@lists.xen.org; Sun, 02 Sep 2012 05:35:53 +0000
Received: from [85.158.143.99:63467] by server-3.bemta-4.messagelabs.com id
	0D/D4-08232-830F2405; Sun, 02 Sep 2012 05:35:52 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-16.tower-216.messagelabs.com!1346564149!16837776!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA0OTc5Mjk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18499 invoked from network); 2 Sep 2012 05:35:50 -0000
Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25)
	by server-16.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 2 Sep 2012 05:35:50 -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 689AA2B22
	for <xen-devel@lists.xen.org>; Sun,  2 Sep 2012 08:35:49 +0300 (EEST)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id 333162005D; Sun,  2 Sep 2012 08:35:49 +0300 (EEST)
Date: Sun, 2 Sep 2012 08:35:49 +0300
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: xen-devel@lists.xen.org
Message-ID: <20120902053549.GF8912@reaktio.net>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="neYutvxvOLaeuPCA"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
User-Agent: Mutt/1.5.20 (2009-06-14)
Subject: [Xen-devel] [PATCH] xl.cfg: gfx_passthru documentation 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>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--neYutvxvOLaeuPCA
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit

Hello,

xl.cfg.pod.5 documentation improvements:

- gfx_passthru: Document gfx_passthru makes the GPU become primary in the guest
  and other generic info about gfx_passthru.


Signed-off-by: Pasi Kärkkäinen <pasik@iki.fi>

--- docs/man/xl.cfg.pod.5.orig1 2012-09-02 07:16:39.316782158 +0300
+++ docs/man/xl.cfg.pod.5       2012-09-02 08:26:40.081639087 +0300
@@ -968,7 +968,43 @@
 
 =item B<gfx_passthru=BOOLEAN>
 
-Enable graphics device PCI passthrough. XXX which device is passed through ?
+Enable graphics device PCI passthrough. This option makes the passthru
+graphics card become primary graphics card in the VM, so the Qemu emulated 
+graphics adapter is disabled, and the VNC console for the VM won't have
+any graphics output. All graphics output, including boot time Qemu BIOS
+messages from the VM, will go to the physical outputs of the passed thru
+physical graphics card.
+
+Graphics card PCI device to passthru is chosen with B<pci> option, 
+exactly in the same way as normal Xen PCI device passthru/assignment is done. 
+Note that gfx_passthru doesn't do any kind of sharing
+of the GPU, so you can only assign the GPU to one single VM at a time.
+
+gfx_passthru also enables various legacy VGA memory ranges, BARs, MMIOs, 
+and ioports to be passed thru to the VM, since those are required
+for correct operation of things like VGA BIOS, text mode, VBE, etc.
+
+Enabling gfx_passthru option also copies the physical graphics card 
+video bios to the guest memory, and executes the vbios in the guest 
+to get the graphics card initialized.
+
+Most graphics adapters require vendor specific tweaks for properly
+working graphics passthru. Xen currently includes necessary tweaks
+for Intel IGD (Integrated Graphics Device) GPUs.  
+
+Support for AMD/Nvidia gfx_passthru is not yet merged to Xen,
+but there are out-of-tree patches available.
+
+gfx_passthru is currently only supported with the qemu-xen-traditional
+device-model. Upstream qemu-xen device-model currently doesn't have
+support for gfx_passthru.
+
+Note that some graphics adapters (AMD/ATI cards, for example) don't
+necessarily require gfx_passthru option, so you can use the normal
+Xen PCI passthru to assign the graphics card as a secondary graphics card
+to the VM. Qemu emulated graphics card stays as the primary graphics card, 
+and you get VNC output from the Qemu-emulated primary adapter.
+
 
 =item B<nomigrate=BOOLEAN>


--neYutvxvOLaeuPCA
Content-Type: text/x-diff; charset=us-ascii
Content-Disposition: attachment; filename="xl.cfg.pod.5-gfx_passthru.patch"

--- docs/man/xl.cfg.pod.5.orig1	2012-09-02 07:16:39.316782158 +0300
+++ docs/man/xl.cfg.pod.5	2012-09-02 08:26:40.081639087 +0300
@@ -968,7 +968,43 @@
 
 =item B<gfx_passthru=BOOLEAN>
 
-Enable graphics device PCI passthrough. XXX which device is passed through ?
+Enable graphics device PCI passthrough. This option makes the passthru
+graphics card become primary graphics card in the VM, so the Qemu emulated 
+graphics adapter is disabled, and the VNC console for the VM won't have
+any graphics output. All graphics output, including boot time Qemu BIOS
+messages from the VM, will go to the physical outputs of the passed thru
+physical graphics card.
+
+Graphics card PCI device to passthru is chosen with B<pci> option, 
+exactly in the same way as normal Xen PCI device passthru/assignment is done. 
+Note that gfx_passthru doesn't do any kind of sharing
+of the GPU, so you can only assign the GPU to one single VM at a time.
+
+gfx_passthru also enables various legacy VGA memory ranges, BARs, MMIOs, 
+and ioports to be passed thru to the VM, since those are required
+for correct operation of things like VGA BIOS, text mode, VBE, etc.
+
+Enabling gfx_passthru option also copies the physical graphics card 
+video bios to the guest memory, and executes the vbios in the guest 
+to get the graphics card initialized.
+
+Most graphics adapters require vendor specific tweaks for properly
+working graphics passthru. Xen currently includes necessary tweaks
+for Intel IGD (Integrated Graphics Device) GPUs.  
+
+Support for AMD/Nvidia gfx_passthru is not yet merged to Xen,
+but there are out-of-tree patches available.
+
+gfx_passthru is currently only supported with the qemu-xen-traditional
+device-model. Upstream qemu-xen device-model currently doesn't have
+support for gfx_passthru.
+
+Note that some graphics adapters (AMD/ATI cards, for example) don't
+necessarily require gfx_passthru option, so you can use the normal
+Xen PCI passthru to assign the graphics card as a secondary graphics card
+to the VM. Qemu emulated graphics card stays as the primary graphics card, 
+and you get VNC output from the Qemu-emulated primary adapter.
+
 
 =item B<nomigrate=BOOLEAN>
 

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

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

--neYutvxvOLaeuPCA--


From xen-devel-bounces@lists.xen.org Sun Sep 02 07:14:02 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 02 Sep 2012 07:14:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T84N6-0005iA-Om; Sun, 02 Sep 2012 07:13:28 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1T84N5-0005i5-7F
	for xen-devel@lists.xen.org; Sun, 02 Sep 2012 07:13:27 +0000
Received: from [85.158.143.99:54387] by server-2.bemta-4.messagelabs.com id
	94/3E-21239-61703405; Sun, 02 Sep 2012 07:13:26 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1346570005!27723670!1
X-Originating-IP: [209.85.212.179]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23954 invoked from network); 2 Sep 2012 07:13:26 -0000
Received: from mail-wi0-f179.google.com (HELO mail-wi0-f179.google.com)
	(209.85.212.179)
	by server-5.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Sep 2012 07:13:26 -0000
Received: by wibhq4 with SMTP id hq4so2333328wib.14
	for <xen-devel@lists.xen.org>; Sun, 02 Sep 2012 00:13:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=VPjLZPtzsJv4Uh5RNI6HPNZqalZ+Cc5A8XxFaFo6DX8=;
	b=0sQb0mWUWfAZ6+3Gja7OE2N6l8kNRw4kT/UrR+aRQZ9sw0lR9F3J3edVXQF4c4dnN6
	lGVa6rY7RdCmb3wFfcJdqQb0WoSNDby8F8Zi61Bsx4sl0cGVjcGpxmyPDsNfj71Cp5gH
	/7PB9TDuckYgKyBZ5CxFhB/4z7QH1RCWvpYgHWcnk2SuOmFsQ4wxr4cNsQh4ZC44EIj5
	RslUhJRIbCqBneJbH7H3FPlxAcIuLdyJEAUUXhcQkFs4H8skYD3UCXEHAg4Y8Gi2qGk5
	buZduiyVcCsly33Rdk3gBKEzp7Wb2q/HuYht71pKi8h3yWjXcnKp/0LST7vHU0Nns1Y0
	wmsw==
Received: by 10.216.3.85 with SMTP id 63mr788664weg.134.1346570005747;
	Sun, 02 Sep 2012 00:13:25 -0700 (PDT)
Received: from [192.168.1.69] (host86-184-74-117.range86-184.btcentralplus.com.
	[86.184.74.117])
	by mx.google.com with ESMTPS id k2sm16990259wiz.7.2012.09.02.00.13.24
	(version=SSLv3 cipher=OTHER); Sun, 02 Sep 2012 00:13:25 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Sun, 02 Sep 2012 08:13:21 +0100
From: Keir Fraser <keir.xen@gmail.com>
To: Santosh Jodh <Santosh.Jodh@citrix.com>,
	Sander Eikelenboom <linux@eikelenboom.it>
Message-ID: <CC68C5A1.3D97A%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] Using debug-key 'o:  Dump IOMMU p2m table, locks up
	machine
Thread-Index: Ac2H5anSA9JOwrAdv0yUGY6DtFwLdQAfNVTwAATWEUoADm300AAKt/F2
In-Reply-To: <7914B38A4445B34AA16EB9F1352942F1012F0F6F4BA7@SJCPMAILBOX01.citrite.net>
Mime-version: 1.0
Cc: "wei.wang2@amd.com" <wei.wang2@amd.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Using debug-key 'o:  Dump IOMMU p2m table,
 locks up machine
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 02/09/2012 03:08, "Santosh Jodh" <Santosh.Jodh@citrix.com> wrote:

>>>> It might schedule softirqs but that won't include scheduling or
>>>> running any guest vcpus. The vcpu that happens to be running on that
>>>> cpu at the time the debug dump starts, will be stuck unrunnable until the
>> dump completes.
>>> 
>>> Why does'nt that vCPU get scheduled on some other pCPU? Is there  a
>>> way to yield the CPU from the key handler?
>> 
>> It can't be descheduled from this pCPU without running through the
>> scheduler. You could try running the handler in a tasklet -- a tasklet causes
>> other vCPUs to be descheduled from that pCPU, before it starts running.
>> 
>> So you'd register a keyhandler which does a tasklet_schedule(), and do your
>> logging work in the tasklet handler.
>> 
>> Worth a shot maybe?
> 
> Yes - certainly. Is there a reason why all key handlers should not be
> tasklets?

Some keys you want to print immediately (stack trace), or you are using them
when the system is in a bad way, and deferring the tracing may cause you to
get no tracing at all. There may be a few informational keys, for irqs and
the like, that could be moved to tasklet context though, yes. It's just the
tasklet-in-hypervisor-thread mechanism is newer than the key handlers. ;-)

 -- Keir



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

From xen-devel-bounces@lists.xen.org Sun Sep 02 07:14:02 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 02 Sep 2012 07:14:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T84N6-0005iA-Om; Sun, 02 Sep 2012 07:13:28 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1T84N5-0005i5-7F
	for xen-devel@lists.xen.org; Sun, 02 Sep 2012 07:13:27 +0000
Received: from [85.158.143.99:54387] by server-2.bemta-4.messagelabs.com id
	94/3E-21239-61703405; Sun, 02 Sep 2012 07:13:26 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1346570005!27723670!1
X-Originating-IP: [209.85.212.179]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23954 invoked from network); 2 Sep 2012 07:13:26 -0000
Received: from mail-wi0-f179.google.com (HELO mail-wi0-f179.google.com)
	(209.85.212.179)
	by server-5.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Sep 2012 07:13:26 -0000
Received: by wibhq4 with SMTP id hq4so2333328wib.14
	for <xen-devel@lists.xen.org>; Sun, 02 Sep 2012 00:13:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=VPjLZPtzsJv4Uh5RNI6HPNZqalZ+Cc5A8XxFaFo6DX8=;
	b=0sQb0mWUWfAZ6+3Gja7OE2N6l8kNRw4kT/UrR+aRQZ9sw0lR9F3J3edVXQF4c4dnN6
	lGVa6rY7RdCmb3wFfcJdqQb0WoSNDby8F8Zi61Bsx4sl0cGVjcGpxmyPDsNfj71Cp5gH
	/7PB9TDuckYgKyBZ5CxFhB/4z7QH1RCWvpYgHWcnk2SuOmFsQ4wxr4cNsQh4ZC44EIj5
	RslUhJRIbCqBneJbH7H3FPlxAcIuLdyJEAUUXhcQkFs4H8skYD3UCXEHAg4Y8Gi2qGk5
	buZduiyVcCsly33Rdk3gBKEzp7Wb2q/HuYht71pKi8h3yWjXcnKp/0LST7vHU0Nns1Y0
	wmsw==
Received: by 10.216.3.85 with SMTP id 63mr788664weg.134.1346570005747;
	Sun, 02 Sep 2012 00:13:25 -0700 (PDT)
Received: from [192.168.1.69] (host86-184-74-117.range86-184.btcentralplus.com.
	[86.184.74.117])
	by mx.google.com with ESMTPS id k2sm16990259wiz.7.2012.09.02.00.13.24
	(version=SSLv3 cipher=OTHER); Sun, 02 Sep 2012 00:13:25 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Sun, 02 Sep 2012 08:13:21 +0100
From: Keir Fraser <keir.xen@gmail.com>
To: Santosh Jodh <Santosh.Jodh@citrix.com>,
	Sander Eikelenboom <linux@eikelenboom.it>
Message-ID: <CC68C5A1.3D97A%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] Using debug-key 'o:  Dump IOMMU p2m table, locks up
	machine
Thread-Index: Ac2H5anSA9JOwrAdv0yUGY6DtFwLdQAfNVTwAATWEUoADm300AAKt/F2
In-Reply-To: <7914B38A4445B34AA16EB9F1352942F1012F0F6F4BA7@SJCPMAILBOX01.citrite.net>
Mime-version: 1.0
Cc: "wei.wang2@amd.com" <wei.wang2@amd.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Using debug-key 'o:  Dump IOMMU p2m table,
 locks up machine
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 02/09/2012 03:08, "Santosh Jodh" <Santosh.Jodh@citrix.com> wrote:

>>>> It might schedule softirqs but that won't include scheduling or
>>>> running any guest vcpus. The vcpu that happens to be running on that
>>>> cpu at the time the debug dump starts, will be stuck unrunnable until the
>> dump completes.
>>> 
>>> Why does'nt that vCPU get scheduled on some other pCPU? Is there  a
>>> way to yield the CPU from the key handler?
>> 
>> It can't be descheduled from this pCPU without running through the
>> scheduler. You could try running the handler in a tasklet -- a tasklet causes
>> other vCPUs to be descheduled from that pCPU, before it starts running.
>> 
>> So you'd register a keyhandler which does a tasklet_schedule(), and do your
>> logging work in the tasklet handler.
>> 
>> Worth a shot maybe?
> 
> Yes - certainly. Is there a reason why all key handlers should not be
> tasklets?

Some keys you want to print immediately (stack trace), or you are using them
when the system is in a bad way, and deferring the tracing may cause you to
get no tracing at all. There may be a few informational keys, for irqs and
the like, that could be moved to tasklet context though, yes. It's just the
tasklet-in-hypervisor-thread mechanism is newer than the key handlers. ;-)

 -- Keir



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

From xen-devel-bounces@lists.xen.org Sun Sep 02 07:20:17 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 02 Sep 2012 07:20: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 1T84TD-0005qh-JQ; Sun, 02 Sep 2012 07:19:47 +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 1T84TC-0005qY-DO
	for xen-devel@lists.xen.org; Sun, 02 Sep 2012 07:19:46 +0000
Received: from [85.158.143.99:6182] by server-3.bemta-4.messagelabs.com id
	AA/F5-08232-19803405; Sun, 02 Sep 2012 07:19:45 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1346570384!27724122!1
X-Originating-IP: [74.125.82.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6446 invoked from network); 2 Sep 2012 07:19:44 -0000
Received: from mail-we0-f173.google.com (HELO mail-we0-f173.google.com)
	(74.125.82.173)
	by server-5.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Sep 2012 07:19:44 -0000
Received: by weyz53 with SMTP id z53so2821277wey.32
	for <xen-devel@lists.xen.org>; Sun, 02 Sep 2012 00:19:44 -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=kfKFA2B7rxAhmbReoBU47bDede3hRnCJS0/bTFkazAw=;
	b=Y3ajfsPJEEVvpRrnwa8OFP1vl2awIjSpRtGQKbE03NhdDWbItHMXtNlUble3985yxA
	akOjx6ccYBQZ9N+I+i6xhNc2Z4BStsrjyFEYtXl+19Uh5cwBO9V7uk+5I3ha4fxjkeCt
	SBGw5FKvizebJOWuFo/nx+221gQjzZNm70Un70EQOqgcdotM+KIoG1Wdg4Ek4aTVJKQ5
	Bo4i27lQJtz/92cJGrh92BOagWpmoGWhIuLm4bBCeGA7ZueS5/x4PntB2dwpDi+YaoNJ
	njRQCwgpJRDJQlJdGP/JQAyjO8A41PX1irHE0N6mfXEWdmFf+ydoUl+SbCIgE9PXVzWf
	1B4Q==
Received: by 10.217.1.206 with SMTP id n56mr7323407wes.151.1346570384337;
	Sun, 02 Sep 2012 00:19:44 -0700 (PDT)
Received: from [192.168.1.69] (host86-184-74-117.range86-184.btcentralplus.com.
	[86.184.74.117])
	by mx.google.com with ESMTPS id bc2sm17041325wib.0.2012.09.02.00.19.42
	(version=SSLv3 cipher=OTHER); Sun, 02 Sep 2012 00:19:43 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Sun, 02 Sep 2012 08:19:40 +0100
From: Keir Fraser <keir.xen@gmail.com>
To: Santosh Jodh <Santosh.Jodh@citrix.com>,
	Sander Eikelenboom <linux@eikelenboom.it>
Message-ID: <CC68C71C.3D981%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] Using debug-key 'o:  Dump IOMMU p2m table, locks up
	machine
Thread-Index: Ac2H5anSA9JOwrAdv0yUGY6DtFwLdQAfNVTwAATWEUoADm300AAKt/F2AAA4elk=
In-Reply-To: <CC68C5A1.3D97A%keir.xen@gmail.com>
Mime-version: 1.0
Cc: "wei.wang2@amd.com" <wei.wang2@amd.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Using debug-key 'o:  Dump IOMMU p2m table,
 locks up machine
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 02/09/2012 08:13, "Keir Fraser" <keir.xen@gmail.com> wrote:

> On 02/09/2012 03:08, "Santosh Jodh" <Santosh.Jodh@citrix.com> wrote:
> 
>>>>> It might schedule softirqs but that won't include scheduling or
>>>>> running any guest vcpus. The vcpu that happens to be running on that
>>>>> cpu at the time the debug dump starts, will be stuck unrunnable until the
>>> dump completes.
>>>> 
>>>> Why does'nt that vCPU get scheduled on some other pCPU? Is there  a
>>>> way to yield the CPU from the key handler?
>>> 
>>> It can't be descheduled from this pCPU without running through the
>>> scheduler. You could try running the handler in a tasklet -- a tasklet
>>> causes
>>> other vCPUs to be descheduled from that pCPU, before it starts running.
>>> 
>>> So you'd register a keyhandler which does a tasklet_schedule(), and do your
>>> logging work in the tasklet handler.
>>> 
>>> Worth a shot maybe?
>> 
>> Yes - certainly. Is there a reason why all key handlers should not be
>> tasklets?
> 
> Some keys you want to print immediately (stack trace), or you are using them
> when the system is in a bad way, and deferring the tracing may cause you to
> get no tracing at all. There may be a few informational keys, for irqs and
> the like, that could be moved to tasklet context though, yes. It's just the
> tasklet-in-hypervisor-thread mechanism is newer than the key handlers. ;-)

Actually, ignore me, most keyhandlers are getting deferred to a tasklet
context already. At least when triggered from a serial irq. See
common/keyhandler.c:handle_keypress().

So your handler, when triggered by 'o' over the serial line, will be running
in tasklet context already. So vCPU execution is getting stalled just
because, I'm not sure, not running through the scheduler softirq for ages on
that pCPU is maybe confusing the scheduler? :(

 -- Ker

>  -- Keir
> 
> 



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

From xen-devel-bounces@lists.xen.org Sun Sep 02 07:20:17 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 02 Sep 2012 07:20: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 1T84TD-0005qh-JQ; Sun, 02 Sep 2012 07:19:47 +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 1T84TC-0005qY-DO
	for xen-devel@lists.xen.org; Sun, 02 Sep 2012 07:19:46 +0000
Received: from [85.158.143.99:6182] by server-3.bemta-4.messagelabs.com id
	AA/F5-08232-19803405; Sun, 02 Sep 2012 07:19:45 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1346570384!27724122!1
X-Originating-IP: [74.125.82.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6446 invoked from network); 2 Sep 2012 07:19:44 -0000
Received: from mail-we0-f173.google.com (HELO mail-we0-f173.google.com)
	(74.125.82.173)
	by server-5.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Sep 2012 07:19:44 -0000
Received: by weyz53 with SMTP id z53so2821277wey.32
	for <xen-devel@lists.xen.org>; Sun, 02 Sep 2012 00:19:44 -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=kfKFA2B7rxAhmbReoBU47bDede3hRnCJS0/bTFkazAw=;
	b=Y3ajfsPJEEVvpRrnwa8OFP1vl2awIjSpRtGQKbE03NhdDWbItHMXtNlUble3985yxA
	akOjx6ccYBQZ9N+I+i6xhNc2Z4BStsrjyFEYtXl+19Uh5cwBO9V7uk+5I3ha4fxjkeCt
	SBGw5FKvizebJOWuFo/nx+221gQjzZNm70Un70EQOqgcdotM+KIoG1Wdg4Ek4aTVJKQ5
	Bo4i27lQJtz/92cJGrh92BOagWpmoGWhIuLm4bBCeGA7ZueS5/x4PntB2dwpDi+YaoNJ
	njRQCwgpJRDJQlJdGP/JQAyjO8A41PX1irHE0N6mfXEWdmFf+ydoUl+SbCIgE9PXVzWf
	1B4Q==
Received: by 10.217.1.206 with SMTP id n56mr7323407wes.151.1346570384337;
	Sun, 02 Sep 2012 00:19:44 -0700 (PDT)
Received: from [192.168.1.69] (host86-184-74-117.range86-184.btcentralplus.com.
	[86.184.74.117])
	by mx.google.com with ESMTPS id bc2sm17041325wib.0.2012.09.02.00.19.42
	(version=SSLv3 cipher=OTHER); Sun, 02 Sep 2012 00:19:43 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Sun, 02 Sep 2012 08:19:40 +0100
From: Keir Fraser <keir.xen@gmail.com>
To: Santosh Jodh <Santosh.Jodh@citrix.com>,
	Sander Eikelenboom <linux@eikelenboom.it>
Message-ID: <CC68C71C.3D981%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] Using debug-key 'o:  Dump IOMMU p2m table, locks up
	machine
Thread-Index: Ac2H5anSA9JOwrAdv0yUGY6DtFwLdQAfNVTwAATWEUoADm300AAKt/F2AAA4elk=
In-Reply-To: <CC68C5A1.3D97A%keir.xen@gmail.com>
Mime-version: 1.0
Cc: "wei.wang2@amd.com" <wei.wang2@amd.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Using debug-key 'o:  Dump IOMMU p2m table,
 locks up machine
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 02/09/2012 08:13, "Keir Fraser" <keir.xen@gmail.com> wrote:

> On 02/09/2012 03:08, "Santosh Jodh" <Santosh.Jodh@citrix.com> wrote:
> 
>>>>> It might schedule softirqs but that won't include scheduling or
>>>>> running any guest vcpus. The vcpu that happens to be running on that
>>>>> cpu at the time the debug dump starts, will be stuck unrunnable until the
>>> dump completes.
>>>> 
>>>> Why does'nt that vCPU get scheduled on some other pCPU? Is there  a
>>>> way to yield the CPU from the key handler?
>>> 
>>> It can't be descheduled from this pCPU without running through the
>>> scheduler. You could try running the handler in a tasklet -- a tasklet
>>> causes
>>> other vCPUs to be descheduled from that pCPU, before it starts running.
>>> 
>>> So you'd register a keyhandler which does a tasklet_schedule(), and do your
>>> logging work in the tasklet handler.
>>> 
>>> Worth a shot maybe?
>> 
>> Yes - certainly. Is there a reason why all key handlers should not be
>> tasklets?
> 
> Some keys you want to print immediately (stack trace), or you are using them
> when the system is in a bad way, and deferring the tracing may cause you to
> get no tracing at all. There may be a few informational keys, for irqs and
> the like, that could be moved to tasklet context though, yes. It's just the
> tasklet-in-hypervisor-thread mechanism is newer than the key handlers. ;-)

Actually, ignore me, most keyhandlers are getting deferred to a tasklet
context already. At least when triggered from a serial irq. See
common/keyhandler.c:handle_keypress().

So your handler, when triggered by 'o' over the serial line, will be running
in tasklet context already. So vCPU execution is getting stalled just
because, I'm not sure, not running through the scheduler softirq for ages on
that pCPU is maybe confusing the scheduler? :(

 -- Ker

>  -- Keir
> 
> 



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

From xen-devel-bounces@lists.xen.org Sun Sep 02 07:43:00 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 02 Sep 2012 07:43: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 1T84p9-00064X-QH; Sun, 02 Sep 2012 07:42:27 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1T84p8-00064S-GL
	for xen-devel@lists.xen.org; Sun, 02 Sep 2012 07:42:26 +0000
Received: from [85.158.139.83:26732] by server-1.bemta-5.messagelabs.com id
	B7/8D-32692-1ED03405; Sun, 02 Sep 2012 07:42:25 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1346571743!27935380!1
X-Originating-IP: [74.125.82.51]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31598 invoked from network); 2 Sep 2012 07:42:23 -0000
Received: from mail-wg0-f51.google.com (HELO mail-wg0-f51.google.com)
	(74.125.82.51)
	by server-12.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Sep 2012 07:42:23 -0000
Received: by wgbed3 with SMTP id ed3so2564131wgb.32
	for <xen-devel@lists.xen.org>; Sun, 02 Sep 2012 00:42:23 -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=w9blQ7PuytmUt7yPAZBUqRok/xzKICKZ8fwlvU954QY=;
	b=hElaZu8TY8D5iTgvxxPoCW/disitX8m9ipGA0nHVHh2BkgY74X9KYyOybJlBrkjJHy
	pWlo4yuKUOfBi8qyL+BtR+TzhjPAjdh6JTcydVAGQVpda7uEf8/6Eo/tLxTxzcHCyodg
	bvvDg6zA15tEeaysSilpTxT4ddnfiLKU5+yE9Zr656n9ZDNWKQ+loQG4hD0iISetnFmB
	aEDI6fN2e/cQgsb99fZHHk+9buOmrJfroKfbhIODnyWyrgyBemNzB/Juu0SjPeyoNJK2
	EI+usMRfTraFo8gzQ5X5nhalwJszCkLDylKFclVcPl8FJPv3pHyoS1tVz/1/+2IMSzkM
	Py+A==
Received: by 10.217.1.79 with SMTP id m57mr7361500wes.121.1346571742957;
	Sun, 02 Sep 2012 00:42:22 -0700 (PDT)
Received: from [192.168.1.69] (host86-184-74-117.range86-184.btcentralplus.com.
	[86.184.74.117])
	by mx.google.com with ESMTPS id k20sm11657483wiv.11.2012.09.02.00.42.20
	(version=SSLv3 cipher=OTHER); Sun, 02 Sep 2012 00:42:22 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Sun, 02 Sep 2012 08:42:15 +0100
From: Keir Fraser <keir.xen@gmail.com>
To: Sander Eikelenboom <linux@eikelenboom.it>,
	Santosh Jodh <santosh.jodh@citrix.com>, <wei.wang2@amd.com>
Message-ID: <CC68CC67.3D984%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] Using debug-key 'o:  Dump IOMMU p2m table, locks up
	machine
Thread-Index: Ac2I3niJ0Q4uQqsNykiQU+v9bEIzQw==
In-Reply-To: <647712821.20120831234512@eikelenboom.it>
Mime-version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Using debug-key 'o:  Dump IOMMU p2m table,
 locks up machine
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/08/2012 22:45, "Sander Eikelenboom" <linux@eikelenboom.it> wrote:

> 
> I was trying to use the 'o' debug key to make a bug report about an "AMD-Vi:
> IO_PAGE_FAULT".
> 
> The result:
> - When using "xl debug-keys o", the machine seems in a infinite loop, can
> hardly login, eventually resulting in a kernel RCU stall and complete lockup.

We don't defer the key handler to tasklet context in this case (because of
'if !in_irq()' check in keyhandler.c:handle_keypress()). Hence the dom0 vCPU
gets 'stuck' while the handler executes. Possibly we should always defer
non-irq keyhandlers to tasklet context, even when executed via sysctl.

> - When using serial console: I get a infinite stream of "gfn:  mfn: " lines,
> mean while on the normal console, S-ATA devices are starting to give errors.

In this case the handler must be running in tasklet context. Not sure why
SATA interrupts would be affected as hardirq and softirq work will still be
carried out during execution of the keyhandler (the handler voluntarily
preempts itself for softirq work).

Would need more investigation. :)

 -- Keir

> So either option trashes the machine, other debug-keys work fine.
> 
> Machine has a 890-fx chipset and AMD phenom x6 proc.
> 
> xl dmesg with bootup and output from some other debug-keys is attached.
> 
> --
> 
> Sander
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel



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

From xen-devel-bounces@lists.xen.org Sun Sep 02 07:43:00 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 02 Sep 2012 07:43: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 1T84p9-00064X-QH; Sun, 02 Sep 2012 07:42:27 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1T84p8-00064S-GL
	for xen-devel@lists.xen.org; Sun, 02 Sep 2012 07:42:26 +0000
Received: from [85.158.139.83:26732] by server-1.bemta-5.messagelabs.com id
	B7/8D-32692-1ED03405; Sun, 02 Sep 2012 07:42:25 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1346571743!27935380!1
X-Originating-IP: [74.125.82.51]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31598 invoked from network); 2 Sep 2012 07:42:23 -0000
Received: from mail-wg0-f51.google.com (HELO mail-wg0-f51.google.com)
	(74.125.82.51)
	by server-12.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Sep 2012 07:42:23 -0000
Received: by wgbed3 with SMTP id ed3so2564131wgb.32
	for <xen-devel@lists.xen.org>; Sun, 02 Sep 2012 00:42:23 -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=w9blQ7PuytmUt7yPAZBUqRok/xzKICKZ8fwlvU954QY=;
	b=hElaZu8TY8D5iTgvxxPoCW/disitX8m9ipGA0nHVHh2BkgY74X9KYyOybJlBrkjJHy
	pWlo4yuKUOfBi8qyL+BtR+TzhjPAjdh6JTcydVAGQVpda7uEf8/6Eo/tLxTxzcHCyodg
	bvvDg6zA15tEeaysSilpTxT4ddnfiLKU5+yE9Zr656n9ZDNWKQ+loQG4hD0iISetnFmB
	aEDI6fN2e/cQgsb99fZHHk+9buOmrJfroKfbhIODnyWyrgyBemNzB/Juu0SjPeyoNJK2
	EI+usMRfTraFo8gzQ5X5nhalwJszCkLDylKFclVcPl8FJPv3pHyoS1tVz/1/+2IMSzkM
	Py+A==
Received: by 10.217.1.79 with SMTP id m57mr7361500wes.121.1346571742957;
	Sun, 02 Sep 2012 00:42:22 -0700 (PDT)
Received: from [192.168.1.69] (host86-184-74-117.range86-184.btcentralplus.com.
	[86.184.74.117])
	by mx.google.com with ESMTPS id k20sm11657483wiv.11.2012.09.02.00.42.20
	(version=SSLv3 cipher=OTHER); Sun, 02 Sep 2012 00:42:22 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Sun, 02 Sep 2012 08:42:15 +0100
From: Keir Fraser <keir.xen@gmail.com>
To: Sander Eikelenboom <linux@eikelenboom.it>,
	Santosh Jodh <santosh.jodh@citrix.com>, <wei.wang2@amd.com>
Message-ID: <CC68CC67.3D984%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] Using debug-key 'o:  Dump IOMMU p2m table, locks up
	machine
Thread-Index: Ac2I3niJ0Q4uQqsNykiQU+v9bEIzQw==
In-Reply-To: <647712821.20120831234512@eikelenboom.it>
Mime-version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Using debug-key 'o:  Dump IOMMU p2m table,
 locks up machine
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/08/2012 22:45, "Sander Eikelenboom" <linux@eikelenboom.it> wrote:

> 
> I was trying to use the 'o' debug key to make a bug report about an "AMD-Vi:
> IO_PAGE_FAULT".
> 
> The result:
> - When using "xl debug-keys o", the machine seems in a infinite loop, can
> hardly login, eventually resulting in a kernel RCU stall and complete lockup.

We don't defer the key handler to tasklet context in this case (because of
'if !in_irq()' check in keyhandler.c:handle_keypress()). Hence the dom0 vCPU
gets 'stuck' while the handler executes. Possibly we should always defer
non-irq keyhandlers to tasklet context, even when executed via sysctl.

> - When using serial console: I get a infinite stream of "gfn:  mfn: " lines,
> mean while on the normal console, S-ATA devices are starting to give errors.

In this case the handler must be running in tasklet context. Not sure why
SATA interrupts would be affected as hardirq and softirq work will still be
carried out during execution of the keyhandler (the handler voluntarily
preempts itself for softirq work).

Would need more investigation. :)

 -- Keir

> So either option trashes the machine, other debug-keys work fine.
> 
> Machine has a 890-fx chipset and AMD phenom x6 proc.
> 
> xl dmesg with bootup and output from some other debug-keys is attached.
> 
> --
> 
> Sander
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel



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

From xen-devel-bounces@lists.xen.org Sun Sep 02 08:44:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 02 Sep 2012 08:44:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T85mO-0006p5-AR; Sun, 02 Sep 2012 08:43:40 +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 1T85mM-0006p0-Ub
	for xen-devel@lists.xen.org; Sun, 02 Sep 2012 08:43:39 +0000
Received: from [85.158.143.99:38251] by server-2.bemta-4.messagelabs.com id
	AC/DC-21239-A3C13405; Sun, 02 Sep 2012 08:43:38 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-11.tower-216.messagelabs.com!1346575414!20525918!1
X-Originating-IP: [188.40.164.121]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13618 invoked from network); 2 Sep 2012 08:43:34 -0000
Received: from static.121.164.40.188.clients.your-server.de (HELO
	smtp.eikelenboom.it) (188.40.164.121)
	by server-11.tower-216.messagelabs.com with AES256-SHA encrypted SMTP;
	2 Sep 2012 08:43:34 -0000
Received: from 26-69-ftth.onsneteindhoven.nl ([88.159.69.26]:49677
	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 1T85jC-00006N-KF; Sun, 02 Sep 2012 10:40:22 +0200
Date: Sun, 2 Sep 2012 10:43:31 +0200
From: Sander Eikelenboom <linux@eikelenboom.it>
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <40501859.20120902104331@eikelenboom.it>
To: Keir Fraser <keir.xen@gmail.com>
In-Reply-To: <CC681CDD.3D966%keir.xen@gmail.com>
References: <7914B38A4445B34AA16EB9F1352942F1012F0F6F4B98@SJCPMAILBOX01.citrite.net>
	<CC681CDD.3D966%keir.xen@gmail.com>
MIME-Version: 1.0
Content-Type: multipart/mixed;
 boundary="----------03516D00221173D65"
Cc: "wei.wang2@amd.com" <wei.wang2@amd.com>,
	Santosh Jodh <Santosh.Jodh@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Using debug-key 'o:  Dump IOMMU p2m table,
	locks up machine
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

------------03516D00221173D65
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit


Saturday, September 1, 2012, 9:13:17 PM, you wrote:

> On 01/09/2012 18:03, "Santosh Jodh" <Santosh.Jodh@citrix.com> wrote:

>>> It might schedule softirqs but that won't include scheduling or running any
>>> guest vcpus. The vcpu that happens to be running on that cpu at the time the
>>> debug dump starts, will be stuck unrunnable until the dump completes.
>> 
>> Why does'nt that vCPU get scheduled on some other pCPU? Is there  a way to
>> yield the CPU from the key handler?

> It can't be descheduled from this pCPU without running through the
> scheduler. You could try running the handler in a tasklet -- a tasklet
> causes other vCPUs to be descheduled from that pCPU, before it starts
> running.

> So you'd register a keyhandler which does a tasklet_schedule(), and do your
> logging work in the tasklet handler.

> Worth a shot maybe?

>>> 
>>> Well, anyway, I don't know how useful a massive dump of the entire p2m is
>>> going to be for debugging anyway. If investigating an IOMMU page fault, I'd
>>> just want the info pertaining to that fault, and all the mapping information
>>> for
>>> that IO virtual address, dumped. :)
>> 
>> It is not a generically useful command - its usefulness is in the same
>> category as dumping the MMU table. Unfortunately, there is no way to pass
>> arguments to the key handler - to say provide the VM and or starting gfn and
>> length for a more selective output.

> Quite simply, there likely needs to be more tracing on the IOMMU fault path.
> That's a separate concern from your keyhandler of course, but just saying
> I'd be looking for the former rather than the latter, for diagnosing
> Sander's bug.

Are there any printk's I could add to get more relevant info about the AMD-Vi: IO_PAGE_FAULT ?

I have attached new output from xl dmesg, this time with iommu=debug on (the option changed from 4.1 to 4.2).



>  -- Keir


------------03516D00221173D65
Content-Type: text/plain;
 name="xl-dmesg.txt"
Content-transfer-encoding: base64
Content-Disposition: attachment;
 filename="xl-dmesg.txt"

IF9fICBfXyAgICAgICAgICAgIF8gIF8gICAgX19fXyAgICBfX18gICAgICAgICAgICAgIF8g
IF8gICAgICAgICAgICAgICAgICAgICANCiBcIFwvIC9fX18gXyBfXyAgIHwgfHwgfCAgfF9f
XyBcICAvIF8gXCAgICBfIF9fIF9fX3wgfHwgfCAgICAgXyBfXyAgXyBfXyBfX18gDQogIFwg
IC8vIF8gXCAnXyBcICB8IHx8IHxfICAgX18pIHx8IHwgfCB8X198ICdfXy8gX198IHx8IHxf
IF9ffCAnXyBcfCAnX18vIF8gXA0KICAvICBcICBfXy8gfCB8IHwgfF9fICAgX3wgLyBfXy8g
fCB8X3wgfF9ffCB8IHwgKF9ffF9fICAgX3xfX3wgfF8pIHwgfCB8ICBfXy8NCiAvXy9cX1xf
X198X3wgfF98ICAgIHxffChfKV9fX19fKF8pX19fLyAgIHxffCAgXF9fX3wgIHxffCAgICB8
IC5fXy98X3wgIFxfX198DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgfF98ICAgICAgICAgICAgIA0KKFhFTikgWGVuIHZl
cnNpb24gNC4yLjAtcmM0LXByZSAocm9vdEBkeW5kbnMub3JnKSAoZ2NjIChEZWJpYW4gNC40
LjUtOCkgNC40LjUpIFRodSBBdWcgMzAgMjM6NTg6MDMgQ0VTVCAyMDEyDQooWEVOKSBMYXRl
c3QgQ2hhbmdlU2V0OiBUdWUgQXVnIDI4IDIyOjQwOjQ1IDIwMTIgKzAxMDAgMjU3ODY6YTBi
NWY4MTAyYTAwDQooWEVOKSBCb290bG9hZGVyOiBHUlVCIDEuOTgrMjAxMDA4MDQtMTQrc3F1
ZWV6ZTENCihYRU4pIENvbW1hbmQgbGluZTogZG9tMF9tZW09MTAyNE0gbG9nbHZsPWFsbCBs
b2dsdmxfZ3Vlc3Q9YWxsIGNvbnNvbGVfdGltZXN0YW1wcyB2Z2E9Z2Z4LTEyODB4MTAyNHgz
MiBjcHVpZGxlIGNwdWZyZXE9eGVuIG5vcmVib290IGRlYnVnIGxhcGljPWRlYnVnIGFwaWNf
dmVyYm9zaXR5PWRlYnVnIGFwaWM9ZGVidWcgaW9tbXU9b24sdmVyYm9zZSxkZWJ1ZyBjb20x
PTM4NDAwLDhuMSBjb25zb2xlPXZnYSxjb20xDQooWEVOKSBWaWRlbyBpbmZvcm1hdGlvbjoN
CihYRU4pICBWR0EgaXMgZ3JhcGhpY3MgbW9kZSAxMjgweDEwMjQsIDMyIGJwcA0KKFhFTikg
IFZCRS9EREMgbWV0aG9kczogVjI7IEVESUQgdHJhbnNmZXIgdGltZTogMSBzZWNvbmRzDQoo
WEVOKSBEaXNjIGluZm9ybWF0aW9uOg0KKFhFTikgIEZvdW5kIDIgTUJSIHNpZ25hdHVyZXMN
CihYRU4pICBGb3VuZCAyIEVERCBpbmZvcm1hdGlvbiBzdHJ1Y3R1cmVzDQooWEVOKSBYZW4t
ZTgyMCBSQU0gbWFwOg0KKFhFTikgIDAwMDAwMDAwMDAwMDAwMDAgLSAwMDAwMDAwMDAwMDli
MDAwICh1c2FibGUpDQooWEVOKSAgMDAwMDAwMDAwMDA5YjAwMCAtIDAwMDAwMDAwMDAwYTAw
MDAgKHJlc2VydmVkKQ0KKFhFTikgIDAwMDAwMDAwMDAwZTQwMDAgLSAwMDAwMDAwMDAwMTAw
MDAwIChyZXNlcnZlZCkNCihYRU4pICAwMDAwMDAwMDAwMTAwMDAwIC0gMDAwMDAwMDBhZmU5
MDAwMCAodXNhYmxlKQ0KKFhFTikgIDAwMDAwMDAwYWZlOTAwMDAgLSAwMDAwMDAwMGFmZTll
MDAwIChBQ1BJIGRhdGEpDQooWEVOKSAgMDAwMDAwMDBhZmU5ZTAwMCAtIDAwMDAwMDAwYWZl
ZTAwMDAgKEFDUEkgTlZTKQ0KKFhFTikgIDAwMDAwMDAwYWZlZTAwMDAgLSAwMDAwMDAwMGFm
ZjAwMDAwIChyZXNlcnZlZCkNCihYRU4pICAwMDAwMDAwMGZmZTAwMDAwIC0gMDAwMDAwMDEw
MDAwMDAwMCAocmVzZXJ2ZWQpDQooWEVOKSAgMDAwMDAwMDEwMDAwMDAwMCAtIDAwMDAwMDAy
NTAwMDAwMDAgKHVzYWJsZSkNCihYRU4pIEFDUEk6IFJTRFAgMDAwRkIxMjAsIDAwMTQgKHIw
IEFDUElBTSkNCihYRU4pIEFDUEk6IFJTRFQgQUZFOTAwMDAsIDAwNDggKHIxIE1TSSAgICBP
RU1TTElDICAyMDEwMDYyMiBNU0ZUICAgICAgIDk3KQ0KKFhFTikgQUNQSTogRkFDUCBBRkU5
MDIwMCwgMDA4NCAocjEgNzY0ME1TIEE3NjQwMTAwIDIwMTAwNjIyIE1TRlQgICAgICAgOTcp
DQooWEVOKSBBQ1BJOiBEU0RUIEFGRTkwNUUwLCA5NDQ5IChyMSAgQTc2NDAgQTc2NDAxMDAg
ICAgICAxMDAgSU5UTCAyMDA1MTExNykNCihYRU4pIEFDUEk6IEZBQ1MgQUZFOUUwMDAsIDAw
NDANCihYRU4pIEFDUEk6IEFQSUMgQUZFOTAzOTAsIDAwODggKHIxIDc2NDBNUyBBNzY0MDEw
MCAyMDEwMDYyMiBNU0ZUICAgICAgIDk3KQ0KKFhFTikgQUNQSTogTUNGRyBBRkU5MDQyMCwg
MDAzQyAocjEgNzY0ME1TIE9FTU1DRkcgIDIwMTAwNjIyIE1TRlQgICAgICAgOTcpDQooWEVO
KSBBQ1BJOiBTTElDIEFGRTkwNDYwLCAwMTc2IChyMSBNU0kgICAgT0VNU0xJQyAgMjAxMDA2
MjIgTVNGVCAgICAgICA5NykNCihYRU4pIEFDUEk6IE9FTUIgQUZFOUUwNDAsIDAwNzIgKHIx
IDc2NDBNUyBBNzY0MDEwMCAyMDEwMDYyMiBNU0ZUICAgICAgIDk3KQ0KKFhFTikgQUNQSTog
U1JBVCBBRkU5QTVFMCwgMDEwOCAocjMgQU1EICAgIEZBTV9GXzEwICAgICAgICAyIEFNRCAg
ICAgICAgIDEpDQooWEVOKSBBQ1BJOiBIUEVUIEFGRTlBNkYwLCAwMDM4IChyMSA3NjQwTVMg
T0VNSFBFVCAgMjAxMDA2MjIgTVNGVCAgICAgICA5NykNCihYRU4pIEFDUEk6IElWUlMgQUZF
OUE3MzAsIDAwRjggKHIxICBBTUQgICAgIFJEODkwUyAgIDIwMjAzMSBBTUQgICAgICAgICAw
KQ0KKFhFTikgQUNQSTogU1NEVCBBRkU5QTgzMCwgMERBNCAocjEgQSBNIEkgIFBPV0VSTk9X
ICAgICAgICAxIEFNRCAgICAgICAgIDEpDQooWEVOKSBTeXN0ZW0gUkFNOiA4MTkwTUIgKDgz
ODY3MzJrQikNCihYRU4pIFNSQVQ6IFBYTSAwIC0+IEFQSUMgMCAtPiBOb2RlIDANCihYRU4p
IFNSQVQ6IFBYTSAwIC0+IEFQSUMgMSAtPiBOb2RlIDANCihYRU4pIFNSQVQ6IFBYTSAwIC0+
IEFQSUMgMiAtPiBOb2RlIDANCihYRU4pIFNSQVQ6IFBYTSAwIC0+IEFQSUMgMyAtPiBOb2Rl
IDANCihYRU4pIFNSQVQ6IFBYTSAwIC0+IEFQSUMgNCAtPiBOb2RlIDANCihYRU4pIFNSQVQ6
IFBYTSAwIC0+IEFQSUMgNSAtPiBOb2RlIDANCihYRU4pIFNSQVQ6IE5vZGUgMCBQWE0gMCAw
LWEwMDAwDQooWEVOKSBTUkFUOiBOb2RlIDAgUFhNIDAgMTAwMDAwLWIwMDAwMDAwDQooWEVO
KSBTUkFUOiBOb2RlIDAgUFhNIDAgMTAwMDAwMDAwLTI1MDAwMDAwMA0KKFhFTikgTlVNQTog
QWxsb2NhdGVkIG1lbW5vZGVtYXAgZnJvbSAyNGRiYWMwMDAgLSAyNGRiYWYwMDANCihYRU4p
IE5VTUE6IFVzaW5nIDggZm9yIHRoZSBoYXNoIHNoaWZ0Lg0KKFhFTikgRG9tYWluIGhlYXAg
aW5pdGlhbGlzZWQNCihYRU4pIHZlc2FmYjogZnJhbWVidWZmZXIgYXQgMHhmYjAwMDAwMCwg
bWFwcGVkIHRvIDB4ZmZmZjgyYzAwMDAwMDAwMCwgdXNpbmcgNjE0NGssIHRvdGFsIDE0MzM2
aw0KKFhFTikgdmVzYWZiOiBtb2RlIGlzIDEyODB4MTAyNHgzMiwgbGluZWxlbmd0aD01MTIw
LCBmb250IDh4MTYNCihYRU4pIHZlc2FmYjogVHJ1ZWNvbG9yOiBzaXplPTg6ODo4OjgsIHNo
aWZ0PTI0OjE2Ojg6MA0KKFhFTikgZm91bmQgU01QIE1QLXRhYmxlIGF0IDAwMGZmNzgwDQoo
WEVOKSBETUkgcHJlc2VudC4NCihYRU4pIEFQSUMgYm9vdCBzdGF0ZSBpcyAneGFwaWMnDQoo
WEVOKSBVc2luZyBBUElDIGRyaXZlciBkZWZhdWx0DQooWEVOKSBBQ1BJOiBQTS1UaW1lciBJ
TyBQb3J0OiAweDgwOA0KKFhFTikgQUNQSTogQUNQSSBTTEVFUCBJTkZPOiBwbTF4X2NudFs4
MDQsMF0sIHBtMXhfZXZ0WzgwMCwwXQ0KKFhFTikgQUNQSTogICAgICAgICAgICAgICAgICB3
YWtldXBfdmVjW2FmZTllMDBjXSwgdmVjX3NpemVbMjBdDQooWEVOKSBBQ1BJOiBMb2NhbCBB
UElDIGFkZHJlc3MgMHhmZWUwMDAwMA0KKFhFTikgQUNQSTogTEFQSUMgKGFjcGlfaWRbMHgw
MV0gbGFwaWNfaWRbMHgwMF0gZW5hYmxlZCkNCihYRU4pIFByb2Nlc3NvciAjMCAwOjEwIEFQ
SUMgdmVyc2lvbiAxNg0KKFhFTikgQUNQSTogTEFQSUMgKGFjcGlfaWRbMHgwMl0gbGFwaWNf
aWRbMHgwMV0gZW5hYmxlZCkNCihYRU4pIFByb2Nlc3NvciAjMSAwOjEwIEFQSUMgdmVyc2lv
biAxNg0KKFhFTikgQUNQSTogTEFQSUMgKGFjcGlfaWRbMHgwM10gbGFwaWNfaWRbMHgwMl0g
ZW5hYmxlZCkNCihYRU4pIFByb2Nlc3NvciAjMiAwOjEwIEFQSUMgdmVyc2lvbiAxNg0KKFhF
TikgQUNQSTogTEFQSUMgKGFjcGlfaWRbMHgwNF0gbGFwaWNfaWRbMHgwM10gZW5hYmxlZCkN
CihYRU4pIFByb2Nlc3NvciAjMyAwOjEwIEFQSUMgdmVyc2lvbiAxNg0KKFhFTikgQUNQSTog
TEFQSUMgKGFjcGlfaWRbMHgwNV0gbGFwaWNfaWRbMHgwNF0gZW5hYmxlZCkNCihYRU4pIFBy
b2Nlc3NvciAjNCAwOjEwIEFQSUMgdmVyc2lvbiAxNg0KKFhFTikgQUNQSTogTEFQSUMgKGFj
cGlfaWRbMHgwNl0gbGFwaWNfaWRbMHgwNV0gZW5hYmxlZCkNCihYRU4pIFByb2Nlc3NvciAj
NSAwOjEwIEFQSUMgdmVyc2lvbiAxNg0KKFhFTikgQUNQSTogSU9BUElDIChpZFsweDA2XSBh
ZGRyZXNzWzB4ZmVjMDAwMDBdIGdzaV9iYXNlWzBdKQ0KKFhFTikgSU9BUElDWzBdOiBhcGlj
X2lkIDYsIHZlcnNpb24gMzMsIGFkZHJlc3MgMHhmZWMwMDAwMCwgR1NJIDAtMjMNCihYRU4p
IEFDUEk6IElPQVBJQyAoaWRbMHgwN10gYWRkcmVzc1sweGZlYzIwMDAwXSBnc2lfYmFzZVsy
NF0pDQooWEVOKSBJT0FQSUNbMV06IGFwaWNfaWQgNywgdmVyc2lvbiAzMywgYWRkcmVzcyAw
eGZlYzIwMDAwLCBHU0kgMjQtNTUNCihYRU4pIEFDUEk6IElOVF9TUkNfT1ZSIChidXMgMCBi
dXNfaXJxIDAgZ2xvYmFsX2lycSAyIGRmbCBkZmwpDQooWEVOKSBBQ1BJOiBJTlRfU1JDX09W
UiAoYnVzIDAgYnVzX2lycSA5IGdsb2JhbF9pcnEgOSBsb3cgbGV2ZWwpDQooWEVOKSBBQ1BJ
OiBJUlEwIHVzZWQgYnkgb3ZlcnJpZGUuDQooWEVOKSBBQ1BJOiBJUlEyIHVzZWQgYnkgb3Zl
cnJpZGUuDQooWEVOKSBBQ1BJOiBJUlE5IHVzZWQgYnkgb3ZlcnJpZGUuDQooWEVOKSBFbmFi
bGluZyBBUElDIG1vZGU6ICBGbGF0LiAgVXNpbmcgMiBJL08gQVBJQ3MNCihYRU4pIEFDUEk6
IEhQRVQgaWQ6IDB4ODMwMCBiYXNlOiAweGZlZDAwMDAwDQooWEVOKSBUYWJsZSBpcyBub3Qg
Zm91bmQhDQooWEVOKSBVc2luZyBBQ1BJIChNQURUKSBmb3IgU01QIGNvbmZpZ3VyYXRpb24g
aW5mb3JtYXRpb24NCihYRU4pIFNNUDogQWxsb3dpbmcgNiBDUFVzICgwIGhvdHBsdWcgQ1BV
cykNCihYRU4pIG1hcHBlZCBBUElDIHRvIGZmZmY4MmMzZmZkZmUwMDAgKGZlZTAwMDAwKQ0K
KFhFTikgbWFwcGVkIElPQVBJQyB0byBmZmZmODJjM2ZmZGZkMDAwIChmZWMwMDAwMCkNCihY
RU4pIG1hcHBlZCBJT0FQSUMgdG8gZmZmZjgyYzNmZmRmYzAwMCAoZmVjMjAwMDApDQooWEVO
KSBJUlEgbGltaXRzOiA1NiBHU0ksIDExMTIgTVNJL01TSS1YDQooWEVOKSBVc2luZyBzY2hl
ZHVsZXI6IFNNUCBDcmVkaXQgU2NoZWR1bGVyIChjcmVkaXQpDQooWEVOKSBEZXRlY3RlZCAz
MjAwLjIyNCBNSHogcHJvY2Vzc29yLg0KKFhFTikgSW5pdGluZyBtZW1vcnkgc2hhcmluZy4N
CihYRU4pIEFNRCBGYW0xMGggbWFjaGluZSBjaGVjayByZXBvcnRpbmcgZW5hYmxlZA0KKFhF
TikgUENJOiBNQ0ZHIGNvbmZpZ3VyYXRpb24gMDogYmFzZSBlMDAwMDAwMCBzZWdtZW50IDAw
MDAgYnVzZXMgMDAgLSBmZg0KKFhFTikgUENJOiBOb3QgdXNpbmcgTUNGRyBmb3Igc2VnbWVu
dCAwMDAwIGJ1cyAwMC1mZg0KKFhFTikgQU1ELVZpOiBGb3VuZCBNU0kgY2FwYWJpbGl0eSBi
bG9jayBhdCAweDU0DQooWEVOKSBBTUQtVmk6IEFDUEkgVGFibGU6DQooWEVOKSBBTUQtVmk6
ICBTaWduYXR1cmUgSVZSUw0KKFhFTikgQU1ELVZpOiAgTGVuZ3RoIDB4ZjgNCihYRU4pIEFN
RC1WaTogIFJldmlzaW9uIDB4MQ0KKFhFTikgQU1ELVZpOiAgQ2hlY2tTdW0gMHg2ZQ0KKFhF
TikgQU1ELVZpOiAgT0VNX0lkIEFNRCAgDQooWEVOKSBBTUQtVmk6ICBPRU1fVGFibGVfSWQg
UkQ4OTBTDQooWEVOKSBBTUQtVmk6ICBPRU1fUmV2aXNpb24gMHgyMDIwMzENCihYRU4pIEFN
RC1WaTogIENyZWF0b3JfSWQgQU1EIA0KKFhFTikgQU1ELVZpOiAgQ3JlYXRvcl9SZXZpc2lv
biAweDANCihYRU4pIEFNRC1WaTogSVZSUyBCbG9jazoNCihYRU4pIEFNRC1WaTogIFR5cGUg
MHgxMA0KKFhFTikgQU1ELVZpOiAgRmxhZ3MgMHgzZQ0KKFhFTikgQU1ELVZpOiAgTGVuZ3Ro
IDB4YzgNCihYRU4pIEFNRC1WaTogIERldl9JZCAweDINCihYRU4pIEFNRC1WaTogSVZIRCBE
ZXZpY2UgRW50cnk6DQooWEVOKSBBTUQtVmk6ICBUeXBlIDB4Mw0KKFhFTikgQU1ELVZpOiAg
RGV2X0lkIDB4MA0KKFhFTikgQU1ELVZpOiAgRmxhZ3MgMHgwDQooWEVOKSBBTUQtVmk6ICBE
ZXZfSWQgUmFuZ2U6IDB4MCAtPiAweDINCihYRU4pIEFNRC1WaTogSVZIRCBEZXZpY2UgRW50
cnk6DQooWEVOKSBBTUQtVmk6ICBUeXBlIDB4Mg0KKFhFTikgQU1ELVZpOiAgRGV2X0lkIDB4
MTANCihYRU4pIEFNRC1WaTogIEZsYWdzIDB4MA0KKFhFTikgQU1ELVZpOiBJVkhEIERldmlj
ZSBFbnRyeToNCihYRU4pIEFNRC1WaTogIFR5cGUgMHgyDQooWEVOKSBBTUQtVmk6ICBEZXZf
SWQgMHhiMDANCihYRU4pIEFNRC1WaTogIEZsYWdzIDB4MA0KKFhFTikgQU1ELVZpOiBJVkhE
IERldmljZSBFbnRyeToNCihYRU4pIEFNRC1WaTogIFR5cGUgMHgyDQooWEVOKSBBTUQtVmk6
ICBEZXZfSWQgMHgxOA0KKFhFTikgQU1ELVZpOiAgRmxhZ3MgMHgwDQooWEVOKSBBTUQtVmk6
IElWSEQgRGV2aWNlIEVudHJ5Og0KKFhFTikgQU1ELVZpOiAgVHlwZSAweDMNCihYRU4pIEFN
RC1WaTogIERldl9JZCAweGEwMA0KKFhFTikgQU1ELVZpOiAgRmxhZ3MgMHgwDQooWEVOKSBB
TUQtVmk6ICBEZXZfSWQgUmFuZ2U6IDB4YTAwIC0+IDB4YTA3DQooWEVOKSBBTUQtVmk6IElW
SEQgRGV2aWNlIEVudHJ5Og0KKFhFTikgQU1ELVZpOiAgVHlwZSAweDINCihYRU4pIEFNRC1W
aTogIERldl9JZCAweDI4DQooWEVOKSBBTUQtVmk6ICBGbGFncyAweDANCihYRU4pIEFNRC1W
aTogSVZIRCBEZXZpY2UgRW50cnk6DQooWEVOKSBBTUQtVmk6ICBUeXBlIDB4Mg0KKFhFTikg
QU1ELVZpOiAgRGV2X0lkIDB4OTAwDQooWEVOKSBBTUQtVmk6ICBGbGFncyAweDANCihYRU4p
IEFNRC1WaTogSVZIRCBEZXZpY2UgRW50cnk6DQooWEVOKSBBTUQtVmk6ICBUeXBlIDB4Mg0K
KFhFTikgQU1ELVZpOiAgRGV2X0lkIDB4MzANCihYRU4pIEFNRC1WaTogIEZsYWdzIDB4MA0K
KFhFTikgQU1ELVZpOiBJVkhEIERldmljZSBFbnRyeToNCihYRU4pIEFNRC1WaTogIFR5cGUg
MHgyDQooWEVOKSBBTUQtVmk6ICBEZXZfSWQgMHg4MDANCihYRU4pIEFNRC1WaTogIEZsYWdz
IDB4MA0KKFhFTikgQU1ELVZpOiBJVkhEIERldmljZSBFbnRyeToNCihYRU4pIEFNRC1WaTog
IFR5cGUgMHgyDQooWEVOKSBBTUQtVmk6ICBEZXZfSWQgMHg1MA0KKFhFTikgQU1ELVZpOiAg
RmxhZ3MgMHgwDQooWEVOKSBBTUQtVmk6IElWSEQgRGV2aWNlIEVudHJ5Og0KKFhFTikgQU1E
LVZpOiAgVHlwZSAweDINCihYRU4pIEFNRC1WaTogIERldl9JZCAweDcwMA0KKFhFTikgQU1E
LVZpOiAgRmxhZ3MgMHgwDQooWEVOKSBBTUQtVmk6IElWSEQgRGV2aWNlIEVudHJ5Og0KKFhF
TikgQU1ELVZpOiAgVHlwZSAweDINCihYRU4pIEFNRC1WaTogIERldl9JZCAweDU4DQooWEVO
KSBBTUQtVmk6ICBGbGFncyAweDANCihYRU4pIEFNRC1WaTogSVZIRCBEZXZpY2UgRW50cnk6
DQooWEVOKSBBTUQtVmk6ICBUeXBlIDB4Mw0KKFhFTikgQU1ELVZpOiAgRGV2X0lkIDB4NjAw
DQooWEVOKSBBTUQtVmk6ICBGbGFncyAweDANCihYRU4pIEFNRC1WaTogIERldl9JZCBSYW5n
ZTogMHg2MDAgLT4gMHg2MDENCihYRU4pIEFNRC1WaTogSVZIRCBEZXZpY2UgRW50cnk6DQoo
WEVOKSBBTUQtVmk6ICBUeXBlIDB4Mg0KKFhFTikgQU1ELVZpOiAgRGV2X0lkIDB4NjANCihY
RU4pIEFNRC1WaTogIEZsYWdzIDB4MA0KKFhFTikgQU1ELVZpOiBJVkhEIERldmljZSBFbnRy
eToNCihYRU4pIEFNRC1WaTogIFR5cGUgMHgyDQooWEVOKSBBTUQtVmk6ICBEZXZfSWQgMHg1
MDANCihYRU4pIEFNRC1WaTogIEZsYWdzIDB4MA0KKFhFTikgQU1ELVZpOiBJVkhEIERldmlj
ZSBFbnRyeToNCihYRU4pIEFNRC1WaTogIFR5cGUgMHgyDQooWEVOKSBBTUQtVmk6ICBEZXZf
SWQgMHg2OA0KKFhFTikgQU1ELVZpOiAgRmxhZ3MgMHgwDQooWEVOKSBBTUQtVmk6IElWSEQg
RGV2aWNlIEVudHJ5Og0KKFhFTikgQU1ELVZpOiAgVHlwZSAweDMNCihYRU4pIEFNRC1WaTog
IERldl9JZCAweDQwMA0KKFhFTikgQU1ELVZpOiAgRmxhZ3MgMHgwDQooWEVOKSBBTUQtVmk6
ICBEZXZfSWQgUmFuZ2U6IDB4NDAwIC0+IDB4NDA3DQooWEVOKSBBTUQtVmk6IElWSEQgRGV2
aWNlIEVudHJ5Og0KKFhFTikgQU1ELVZpOiAgVHlwZSAweDINCihYRU4pIEFNRC1WaTogIERl
dl9JZCAweDg4DQooWEVOKSBBTUQtVmk6ICBGbGFncyAweDANCihYRU4pIEFNRC1WaTogSVZI
RCBEZXZpY2UgRW50cnk6DQooWEVOKSBBTUQtVmk6ICBUeXBlIDB4Mw0KKFhFTikgQU1ELVZp
OiAgRGV2X0lkIDB4OTANCihYRU4pIEFNRC1WaTogIEZsYWdzIDB4MA0KKFhFTikgQU1ELVZp
OiAgRGV2X0lkIFJhbmdlOiAweDkwIC0+IDB4OTINCihYRU4pIEFNRC1WaTogSVZIRCBEZXZp
Y2UgRW50cnk6DQooWEVOKSBBTUQtVmk6ICBUeXBlIDB4Mw0KKFhFTikgQU1ELVZpOiAgRGV2
X0lkIDB4OTgNCihYRU4pIEFNRC1WaTogIEZsYWdzIDB4MA0KKFhFTikgQU1ELVZpOiAgRGV2
X0lkIFJhbmdlOiAweDk4IC0+IDB4OWENCihYRU4pIEFNRC1WaTogSVZIRCBEZXZpY2UgRW50
cnk6DQooWEVOKSBBTUQtVmk6ICBUeXBlIDB4Mg0KKFhFTikgQU1ELVZpOiAgRGV2X0lkIDB4
YTANCihYRU4pIEFNRC1WaTogIEZsYWdzIDB4ZDcNCihYRU4pIEFNRC1WaTogSVZIRCBEZXZp
Y2UgRW50cnk6DQooWEVOKSBBTUQtVmk6ICBUeXBlIDB4Mg0KKFhFTikgQU1ELVZpOiAgRGV2
X0lkIDB4YTMNCihYRU4pIEFNRC1WaTogIEZsYWdzIDB4MA0KKFhFTikgQU1ELVZpOiBJVkhE
IERldmljZSBFbnRyeToNCihYRU4pIEFNRC1WaTogIFR5cGUgMHgyDQooWEVOKSBBTUQtVmk6
ICBEZXZfSWQgMHhhNA0KKFhFTikgQU1ELVZpOiAgRmxhZ3MgMHgwDQooWEVOKSBBTUQtVmk6
IElWSEQgRGV2aWNlIEVudHJ5Og0KKFhFTikgQU1ELVZpOiAgVHlwZSAweDANCihYRU4pIEFN
RC1WaTogIERldl9JZCAweDANCihYRU4pIEFNRC1WaTogIEZsYWdzIDB4MA0KKFhFTikgQU1E
LVZpOiBJVkhEIERldmljZSBFbnRyeToNCihYRU4pIEFNRC1WaTogIFR5cGUgMHg0Mw0KKFhF
TikgQU1ELVZpOiAgRGV2X0lkIDB4MzAwDQooWEVOKSBBTUQtVmk6ICBGbGFncyAweDANCihY
RU4pIEFNRC1WaTogIERldl9JZCBSYW5nZTogMHgzMDAgLT4gMHgzZmYNCihYRU4pIEFNRC1W
aTogIERldl9JZCBBbGlhczogMHhhNA0KKFhFTikgQU1ELVZpOiBJVkhEIERldmljZSBFbnRy
eToNCihYRU4pIEFNRC1WaTogIFR5cGUgMHgyDQooWEVOKSBBTUQtVmk6ICBEZXZfSWQgMHhh
NQ0KKFhFTikgQU1ELVZpOiAgRmxhZ3MgMHgwDQooWEVOKSBBTUQtVmk6IElWSEQgRGV2aWNl
IEVudHJ5Og0KKFhFTikgQU1ELVZpOiAgVHlwZSAweDINCihYRU4pIEFNRC1WaTogIERldl9J
ZCAweGE4DQooWEVOKSBBTUQtVmk6ICBGbGFncyAweDANCihYRU4pIEFNRC1WaTogSVZIRCBE
ZXZpY2UgRW50cnk6DQooWEVOKSBBTUQtVmk6ICBUeXBlIDB4Mg0KKFhFTikgQU1ELVZpOiAg
RGV2X0lkIDB4YTkNCihYRU4pIEFNRC1WaTogIEZsYWdzIDB4MA0KKFhFTikgQU1ELVZpOiBJ
VkhEIERldmljZSBFbnRyeToNCihYRU4pIEFNRC1WaTogIFR5cGUgMHgyDQooWEVOKSBBTUQt
Vmk6ICBEZXZfSWQgMHgxMDANCihYRU4pIEFNRC1WaTogIEZsYWdzIDB4MA0KKFhFTikgQU1E
LVZpOiBJVkhEIERldmljZSBFbnRyeToNCihYRU4pIEFNRC1WaTogIFR5cGUgMHgzDQooWEVO
KSBBTUQtVmk6ICBEZXZfSWQgMHhiMA0KKFhFTikgQU1ELVZpOiAgRmxhZ3MgMHgwDQooWEVO
KSBBTUQtVmk6ICBEZXZfSWQgUmFuZ2U6IDB4YjAgLT4gMHhiMg0KKFhFTikgQU1ELVZpOiBJ
VkhEIERldmljZSBFbnRyeToNCihYRU4pIEFNRC1WaTogIFR5cGUgMHgwDQooWEVOKSBBTUQt
Vmk6ICBEZXZfSWQgMHgwDQooWEVOKSBBTUQtVmk6ICBGbGFncyAweDANCihYRU4pIEFNRC1W
aTogSVZIRCBEZXZpY2UgRW50cnk6DQooWEVOKSBBTUQtVmk6ICBUeXBlIDB4NDgNCihYRU4p
IEFNRC1WaTogIERldl9JZCAweDANCihYRU4pIEFNRC1WaTogIEZsYWdzIDB4ZDcNCihYRU4p
IEFNRC1WaTogSVZIRCBEZXZpY2UgRW50cnk6DQooWEVOKSBBTUQtVmk6ICBUeXBlIDB4NDgN
CihYRU4pIEFNRC1WaTogIERldl9JZCAweDANCihYRU4pIEFNRC1WaTogIEZsYWdzIDB4MA0K
KFhFTikgQU1ELVZpOiBJT01NVSAwIEVuYWJsZWQuDQooWEVOKSBBTUQtVmk6IEVuYWJsaW5n
IGdsb2JhbCB2ZWN0b3IgbWFwDQooWEVOKSBJL08gdmlydHVhbGlzYXRpb24gZW5hYmxlZA0K
KFhFTikgIC0gRG9tMCBtb2RlOiBSZWxheGVkDQooWEVOKSBHZXR0aW5nIFZFUlNJT046IDgw
MDUwMDEwDQooWEVOKSBHZXR0aW5nIFZFUlNJT046IDgwMDUwMDEwDQooWEVOKSBHZXR0aW5n
IElEOiAwDQooWEVOKSBHZXR0aW5nIExWVDA6IDcwMA0KKFhFTikgR2V0dGluZyBMVlQxOiA0
MDANCihYRU4pIGVuYWJsZWQgRXh0SU5UIG9uIENQVSMwDQooWEVOKSBFU1IgdmFsdWUgYmVm
b3JlIGVuYWJsaW5nIHZlY3RvcjogMHgwMDAwMDAwNCAgYWZ0ZXI6IDB4MDAwMDAwMDANCihY
RU4pIEVOQUJMSU5HIElPLUFQSUMgSVJRcw0KKFhFTikgIC0+IFVzaW5nIG5ldyBBQ0sgbWV0
aG9kDQooWEVOKSBpbml0IElPX0FQSUMgSVJRcw0KKFhFTikgIElPLUFQSUMgKGFwaWNpZC1w
aW4pIDYtMCwgNi0xNiwgNi0xNywgNi0xOCwgNi0xOSwgNi0yMCwgNi0yMSwgNi0yMiwgNi0y
MywgNy0wLCA3LTEsIDctMiwgNy0zLCA3LTQsIDctNSwgNy02LCA3LTcsIDctOCwgNy05LCA3
LTEwLCA3LTExLCA3LTEyLCA3LTEzLCA3LTE0LCA3LTE1LCA3LTE2LCA3LTE3LCA3LTE4LCA3
LTE5LCA3LTIwLCA3LTIxLCA3LTIyLCA3LTIzLCA3LTI0LCA3LTI1LCA3LTI2LCA3LTI3LCA3
LTI4LCA3LTI5LCA3LTMwLCA3LTMxIG5vdCBjb25uZWN0ZWQuDQooWEVOKSAuLlRJTUVSOiB2
ZWN0b3I9MHhGMCBhcGljMT0wIHBpbjE9MiBhcGljMj0tMSBwaW4yPS0xDQooWEVOKSBudW1i
ZXIgb2YgTVAgSVJRIHNvdXJjZXM6IDE1Lg0KKFhFTikgbnVtYmVyIG9mIElPLUFQSUMgIzYg
cmVnaXN0ZXJzOiAyNC4NCihYRU4pIG51bWJlciBvZiBJTy1BUElDICM3IHJlZ2lzdGVyczog
MzIuDQooWEVOKSB0ZXN0aW5nIHRoZSBJTyBBUElDLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4N
CihYRU4pIElPIEFQSUMgIzYuLi4uLi4NCihYRU4pIC4uLi4gcmVnaXN0ZXIgIzAwOiAwNjAw
MDAwMA0KKFhFTikgLi4uLi4uLiAgICA6IHBoeXNpY2FsIEFQSUMgaWQ6IDA2DQooWEVOKSAu
Li4uLi4uICAgIDogRGVsaXZlcnkgVHlwZTogMA0KKFhFTikgLi4uLi4uLiAgICA6IExUUyAg
ICAgICAgICA6IDANCihYRU4pIC4uLi4gcmVnaXN0ZXIgIzAxOiAwMDE3ODAyMQ0KKFhFTikg
Li4uLi4uLiAgICAgOiBtYXggcmVkaXJlY3Rpb24gZW50cmllczogMDAxNw0KKFhFTikgLi4u
Li4uLiAgICAgOiBQUlEgaW1wbGVtZW50ZWQ6IDENCihYRU4pIC4uLi4uLi4gICAgIDogSU8g
QVBJQyB2ZXJzaW9uOiAwMDIxDQooWEVOKSAuLi4uIHJlZ2lzdGVyICMwMjogMDYwMDAwMDAN
CihYRU4pIC4uLi4uLi4gICAgIDogYXJiaXRyYXRpb246IDA2DQooWEVOKSAuLi4uIHJlZ2lz
dGVyICMwMzogMDcwMDAwMDANCihYRU4pIC4uLi4uLi4gICAgIDogQm9vdCBEVCAgICA6IDAN
CihYRU4pIC4uLi4gSVJRIHJlZGlyZWN0aW9uIHRhYmxlOg0KKFhFTikgIE5SIExvZyBQaHkg
TWFzayBUcmlnIElSUiBQb2wgU3RhdCBEZXN0IERlbGkgVmVjdDogICANCihYRU4pICAwMCAw
MDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwDQooWEVOKSAgMDEg
MDAxIDAxICAwICAgIDAgICAgMCAgIDAgICAwICAgIDEgICAgMSAgICAzMA0KKFhFTikgIDAy
IDAwMSAwMSAgMCAgICAwICAgIDAgICAwICAgMCAgICAxICAgIDEgICAgRjANCihYRU4pICAw
MyAwMDEgMDEgIDAgICAgMCAgICAwICAgMCAgIDAgICAgMSAgICAxICAgIDM4DQooWEVOKSAg
MDQgMDAxIDAxICAwICAgIDAgICAgMCAgIDAgICAwICAgIDEgICAgMSAgICBGMQ0KKFhFTikg
IDA1IDAwMSAwMSAgMCAgICAwICAgIDAgICAwICAgMCAgICAxICAgIDEgICAgNDANCihYRU4p
ICAwNiAwMDEgMDEgIDAgICAgMCAgICAwICAgMCAgIDAgICAgMSAgICAxICAgIDQ4DQooWEVO
KSAgMDcgMDAxIDAxICAwICAgIDAgICAgMCAgIDAgICAwICAgIDEgICAgMSAgICA1MA0KKFhF
TikgIDA4IDAwMSAwMSAgMCAgICAwICAgIDAgICAwICAgMCAgICAxICAgIDEgICAgNTgNCihY
RU4pICAwOSAwMDEgMDEgIDEgICAgMSAgICAwICAgMSAgIDAgICAgMSAgICAxICAgIDYwDQoo
WEVOKSAgMGEgMDAxIDAxICAwICAgIDAgICAgMCAgIDAgICAwICAgIDEgICAgMSAgICA2OA0K
KFhFTikgIDBiIDAwMSAwMSAgMCAgICAwICAgIDAgICAwICAgMCAgICAxICAgIDEgICAgNzAN
CihYRU4pICAwYyAwMDEgMDEgIDAgICAgMCAgICAwICAgMCAgIDAgICAgMSAgICAxICAgIDc4
DQooWEVOKSAgMGQgMDAxIDAxICAwICAgIDAgICAgMCAgIDAgICAwICAgIDEgICAgMSAgICA4
OA0KKFhFTikgIDBlIDAwMSAwMSAgMCAgICAwICAgIDAgICAwICAgMCAgICAxICAgIDEgICAg
OTANCihYRU4pICAwZiAwMDEgMDEgIDAgICAgMCAgICAwICAgMCAgIDAgICAgMSAgICAxICAg
IDk4DQooWEVOKSAgMTAgMDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAwICAgIDAgICAgMCAg
ICAwMA0KKFhFTikgIDExIDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDAg
ICAgMDANCihYRU4pICAxMiAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAw
ICAgIDAwDQooWEVOKSAgMTMgMDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAwICAgIDAgICAg
MCAgICAwMA0KKFhFTikgIDE0IDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAg
IDAgICAgMDANCihYRU4pICAxNSAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAg
ICAwICAgIDAwDQooWEVOKSAgMTYgMDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAwICAgIDAg
ICAgMCAgICAwMA0KKFhFTikgIDE3IDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAw
ICAgIDAgICAgMDANCihYRU4pIElPIEFQSUMgIzcuLi4uLi4NCihYRU4pIC4uLi4gcmVnaXN0
ZXIgIzAwOiAwNzAwMDAwMA0KKFhFTikgLi4uLi4uLiAgICA6IHBoeXNpY2FsIEFQSUMgaWQ6
IDA3DQooWEVOKSAuLi4uLi4uICAgIDogRGVsaXZlcnkgVHlwZTogMA0KKFhFTikgLi4uLi4u
LiAgICA6IExUUyAgICAgICAgICA6IDANCihYRU4pIC4uLi4gcmVnaXN0ZXIgIzAxOiAwMDFG
ODAyMQ0KKFhFTikgLi4uLi4uLiAgICAgOiBtYXggcmVkaXJlY3Rpb24gZW50cmllczogMDAx
Rg0KKFhFTikgLi4uLi4uLiAgICAgOiBQUlEgaW1wbGVtZW50ZWQ6IDENCihYRU4pIC4uLi4u
Li4gICAgIDogSU8gQVBJQyB2ZXJzaW9uOiAwMDIxDQooWEVOKSAuLi4uIHJlZ2lzdGVyICMw
MjogMDAwMDAwMDANCihYRU4pIC4uLi4uLi4gICAgIDogYXJiaXRyYXRpb246IDAwDQooWEVO
KSAuLi4uIElSUSByZWRpcmVjdGlvbiB0YWJsZToNCihYRU4pICBOUiBMb2cgUGh5IE1hc2sg
VHJpZyBJUlIgUG9sIFN0YXQgRGVzdCBEZWxpIFZlY3Q6ICAgDQooWEVOKSAgMDAgMDAwIDAw
ICAxICAgIDAgICAgMCAgIDAgICAwICAgIDAgICAgMCAgICAwMA0KKFhFTikgIDAxIDAwMCAw
MCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDAgICAgMDANCihYRU4pICAwMiAwMDAg
MDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwDQooWEVOKSAgMDMgMDAw
IDAwICAxICAgIDAgICAgMCAgIDAgICAwICAgIDAgICAgMCAgICAwMA0KKFhFTikgIDA0IDAw
MCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDAgICAgMDANCihYRU4pICAwNSAw
MDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwDQooWEVOKSAgMDYg
MDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAwICAgIDAgICAgMCAgICAwMA0KKFhFTikgIDA3
IDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDAgICAgMDANCihYRU4pICAw
OCAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwDQooWEVOKSAg
MDkgMDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAwICAgIDAgICAgMCAgICAwMA0KKFhFTikg
IDBhIDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDAgICAgMDANCihYRU4p
ICAwYiAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwDQooWEVO
KSAgMGMgMDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAwICAgIDAgICAgMCAgICAwMA0KKFhF
TikgIDBkIDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDAgICAgMDANCihY
RU4pICAwZSAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwDQoo
WEVOKSAgMGYgMDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAwICAgIDAgICAgMCAgICAwMA0K
KFhFTikgIDEwIDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDAgICAgMDAN
CihYRU4pICAxMSAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAw
DQooWEVOKSAgMTIgMDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAwICAgIDAgICAgMCAgICAw
MA0KKFhFTikgIDEzIDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDAgICAg
MDANCihYRU4pICAxNCAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAg
IDAwDQooWEVOKSAgMTUgMDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAwICAgIDAgICAgMCAg
ICAwMA0KKFhFTikgIDE2IDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDAg
ICAgMDANCihYRU4pICAxNyAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAw
ICAgIDAwDQooWEVOKSAgMTggMDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAwICAgIDAgICAg
MCAgICAwMA0KKFhFTikgIDE5IDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAg
IDAgICAgMDANCihYRU4pICAxYSAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAg
ICAwICAgIDAwDQooWEVOKSAgMWIgMDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAwICAgIDAg
ICAgMCAgICAwMA0KKFhFTikgIDFjIDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAw
ICAgIDAgICAgMDANCihYRU4pICAxZCAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAg
MCAgICAwICAgIDAwDQooWEVOKSAgMWUgMDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAwICAg
IDAgICAgMCAgICAwMA0KKFhFTikgIDFmIDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAg
ICAwICAgIDAgICAgMDANCihYRU4pIFVzaW5nIHZlY3Rvci1iYXNlZCBpbmRleGluZw0KKFhF
TikgSVJRIHRvIHBpbiBtYXBwaW5nczoNCihYRU4pIElSUTI0MCAtPiAwOjINCihYRU4pIElS
UTQ4IC0+IDA6MQ0KKFhFTikgSVJRNTYgLT4gMDozDQooWEVOKSBJUlEyNDEgLT4gMDo0DQoo
WEVOKSBJUlE2NCAtPiAwOjUNCihYRU4pIElSUTcyIC0+IDA6Ng0KKFhFTikgSVJRODAgLT4g
MDo3DQooWEVOKSBJUlE4OCAtPiAwOjgNCihYRU4pIElSUTk2IC0+IDA6OQ0KKFhFTikgSVJR
MTA0IC0+IDA6MTANCihYRU4pIElSUTExMiAtPiAwOjExDQooWEVOKSBJUlExMjAgLT4gMDox
Mg0KKFhFTikgSVJRMTM2IC0+IDA6MTMNCihYRU4pIElSUTE0NCAtPiAwOjE0DQooWEVOKSBJ
UlExNTIgLT4gMDoxNQ0KKFhFTikgLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u
Li4uIGRvbmUuDQooWEVOKSBVc2luZyBsb2NhbCBBUElDIHRpbWVyIGludGVycnVwdHMuDQoo
WEVOKSBjYWxpYnJhdGluZyBBUElDIHRpbWVyIC4uLg0KKFhFTikgLi4uLi4gQ1BVIGNsb2Nr
IHNwZWVkIGlzIDMyMDAuMTI1OCBNSHouDQooWEVOKSAuLi4uLiBob3N0IGJ1cyBjbG9jayBz
cGVlZCBpcyAyMDAuMDA3OCBNSHouDQooWEVOKSAuLi4uLiBidXNfc2NhbGUgPSAweDAwMDBD
Q0Q3DQooWEVOKSBbMjAxMi0wOS0wMSAyMjoyNjo1MF0gUGxhdGZvcm0gdGltZXIgaXMgMTQu
MzE4TUh6IEhQRVQNCihYRU4pIFsyMDEyLTA5LTAxIDIyOjI2OjUwXSBBbGxvY2F0ZWQgY29u
c29sZSByaW5nIG9mIDY0IEtpQi4NCihYRU4pIFsyMDEyLTA5LTAxIDIyOjI2OjUwXSBIVk06
IEFTSURzIGVuYWJsZWQuDQooWEVOKSBbMjAxMi0wOS0wMSAyMjoyNjo1MF0gU1ZNOiBTdXBw
b3J0ZWQgYWR2YW5jZWQgZmVhdHVyZXM6DQooWEVOKSBbMjAxMi0wOS0wMSAyMjoyNjo1MF0g
IC0gTmVzdGVkIFBhZ2UgVGFibGVzIChOUFQpDQooWEVOKSBbMjAxMi0wOS0wMSAyMjoyNjo1
MF0gIC0gTGFzdCBCcmFuY2ggUmVjb3JkIChMQlIpIFZpcnR1YWxpc2F0aW9uDQooWEVOKSBb
MjAxMi0wOS0wMSAyMjoyNjo1MF0gIC0gTmV4dC1SSVAgU2F2ZWQgb24gI1ZNRVhJVA0KKFhF
TikgWzIwMTItMDktMDEgMjI6MjY6NTBdICAtIFBhdXNlLUludGVyY2VwdCBGaWx0ZXINCihY
RU4pIFsyMDEyLTA5LTAxIDIyOjI2OjUwXSBIVk06IFNWTSBlbmFibGVkDQooWEVOKSBbMjAx
Mi0wOS0wMSAyMjoyNjo1MF0gSFZNOiBIYXJkd2FyZSBBc3Npc3RlZCBQYWdpbmcgKEhBUCkg
ZGV0ZWN0ZWQNCihYRU4pIFsyMDEyLTA5LTAxIDIyOjI2OjUwXSBIVk06IEhBUCBwYWdlIHNp
emVzOiA0a0IsIDJNQiwgMUdCDQooWEVOKSBbMjAxMi0wOS0wMSAyMjoyNjo0OV0gbWFza2Vk
IEV4dElOVCBvbiBDUFUjMQ0KKFhFTikgWzIwMTItMDktMDEgMjI6MjY6NTBdIG1pY3JvY29k
ZTogY29sbGVjdF9jcHVfaW5mbzogcGF0Y2hfaWQ9MHgxMDAwMGJmDQooWEVOKSBbMjAxMi0w
OS0wMSAyMjoyNjo0OV0gbWFza2VkIEV4dElOVCBvbiBDUFUjMg0KKFhFTikgWzIwMTItMDkt
MDEgMjI6MjY6NTBdIG1pY3JvY29kZTogY29sbGVjdF9jcHVfaW5mbzogcGF0Y2hfaWQ9MHgx
MDAwMGJmDQooWEVOKSBbMjAxMi0wOS0wMSAyMjoyNjo0OV0gbWFza2VkIEV4dElOVCBvbiBD
UFUjMw0KKFhFTikgWzIwMTItMDktMDEgMjI6MjY6NTBdIG1pY3JvY29kZTogY29sbGVjdF9j
cHVfaW5mbzogcGF0Y2hfaWQ9MHgxMDAwMGJmDQooWEVOKSBbMjAxMi0wOS0wMSAyMjoyNjo0
OV0gbWFza2VkIEV4dElOVCBvbiBDUFUjNA0KKFhFTikgWzIwMTItMDktMDEgMjI6MjY6NTBd
IG1pY3JvY29kZTogY29sbGVjdF9jcHVfaW5mbzogcGF0Y2hfaWQ9MHgxMDAwMGJmDQooWEVO
KSBbMjAxMi0wOS0wMSAyMjoyNjo0OV0gbWFza2VkIEV4dElOVCBvbiBDUFUjNQ0KKFhFTikg
WzIwMTItMDktMDEgMjI6MjY6NTBdIEJyb3VnaHQgdXAgNiBDUFVzDQooWEVOKSBbMjAxMi0w
OS0wMSAyMjoyNjo1MF0gbWljcm9jb2RlOiBjb2xsZWN0X2NwdV9pbmZvOiBwYXRjaF9pZD0w
eDEwMDAwYmYNCihYRU4pIFsyMDEyLTA5LTAxIDIyOjI2OjUwXSBIUEVUJ3MgTVNJIG1vZGUg
aGFzbid0IGJlZW4gc3VwcG9ydGVkIHdoZW4gSW50ZXJydXB0IFJlbWFwcGluZyBpcyBlbmFi
bGVkLg0KKFhFTikgWzIwMTItMDktMDEgMjI6MjY6NTBdIEFDUEkgc2xlZXAgbW9kZXM6IFMz
DQooWEVOKSBbMjAxMi0wOS0wMSAyMjoyNjo1MF0gTUNBOiBVc2UgaHcgdGhyZXNob2xkaW5n
IHRvIGFkanVzdCBwb2xsaW5nIGZyZXF1ZW5jeQ0KKFhFTikgWzIwMTItMDktMDEgMjI6MjY6
NTBdIG1jaGVja19wb2xsOiBNYWNoaW5lIGNoZWNrIHBvbGxpbmcgdGltZXIgc3RhcnRlZC4N
CihYRU4pIFsyMDEyLTA5LTAxIDIyOjI2OjUwXSBYZW5vcHJvZmlsZTogRmFpbGVkIHRvIHNl
dHVwIElCUyBMVlQgb2Zmc2V0LCBJQlNDVEwgPSAweGZmZmZmZmZmDQooWEVOKSBbMjAxMi0w
OS0wMSAyMjoyNjo1MF0gKioqIExPQURJTkcgRE9NQUlOIDAgKioqDQooWEVOKSBbMjAxMi0w
OS0wMSAyMjoyNjo1MF0gZWxmX3BhcnNlX2JpbmFyeTogcGhkcjogcGFkZHI9MHgxMDAwMDAw
IG1lbXN6PTB4YjY4MDAwDQooWEVOKSBbMjAxMi0wOS0wMSAyMjoyNjo1MF0gZWxmX3BhcnNl
X2JpbmFyeTogcGhkcjogcGFkZHI9MHgxYzAwMDAwIG1lbXN6PTB4ZDgwZTgNCihYRU4pIFsy
MDEyLTA5LTAxIDIyOjI2OjUwXSBlbGZfcGFyc2VfYmluYXJ5OiBwaGRyOiBwYWRkcj0weDFj
ZDkwMDAgbWVtc3o9MHgxM2MwMA0KKFhFTikgWzIwMTItMDktMDEgMjI6MjY6NTBdIGVsZl9w
YXJzZV9iaW5hcnk6IHBoZHI6IHBhZGRyPTB4MWNlZDAwMCBtZW1zej0weGRlNDAwMA0KKFhF
TikgWzIwMTItMDktMDEgMjI6MjY6NTBdIGVsZl9wYXJzZV9iaW5hcnk6IG1lbW9yeTogMHgx
MDAwMDAwIC0+IDB4MmFkMTAwMA0KKFhFTikgWzIwMTItMDktMDEgMjI6MjY6NTBdIGVsZl94
ZW5fcGFyc2Vfbm90ZTogR1VFU1RfT1MgPSAibGludXgiDQooWEVOKSBbMjAxMi0wOS0wMSAy
MjoyNjo1MF0gZWxmX3hlbl9wYXJzZV9ub3RlOiBHVUVTVF9WRVJTSU9OID0gIjIuNiINCihY
RU4pIFsyMDEyLTA5LTAxIDIyOjI2OjUwXSBlbGZfeGVuX3BhcnNlX25vdGU6IFhFTl9WRVJT
SU9OID0gInhlbi0zLjAiDQooWEVOKSBbMjAxMi0wOS0wMSAyMjoyNjo1MF0gZWxmX3hlbl9w
YXJzZV9ub3RlOiBWSVJUX0JBU0UgPSAweGZmZmZmZmZmODAwMDAwMDANCihYRU4pIFsyMDEy
LTA5LTAxIDIyOjI2OjUwXSBlbGZfeGVuX3BhcnNlX25vdGU6IEVOVFJZID0gMHhmZmZmZmZm
ZjgxY2VkMjEwDQooWEVOKSBbMjAxMi0wOS0wMSAyMjoyNjo1MV0gZWxmX3hlbl9wYXJzZV9u
b3RlOiBIWVBFUkNBTExfUEFHRSA9IDB4ZmZmZmZmZmY4MTAwMTAwMA0KKFhFTikgWzIwMTIt
MDktMDEgMjI6MjY6NTFdIGVsZl94ZW5fcGFyc2Vfbm90ZTogRkVBVFVSRVMgPSAiIXdyaXRh
YmxlX3BhZ2VfdGFibGVzfHBhZV9wZ2Rpcl9hYm92ZV80Z2IiDQooWEVOKSBbMjAxMi0wOS0w
MSAyMjoyNjo1MV0gZWxmX3hlbl9wYXJzZV9ub3RlOiBQQUVfTU9ERSA9ICJ5ZXMiDQooWEVO
KSBbMjAxMi0wOS0wMSAyMjoyNjo1MV0gZWxmX3hlbl9wYXJzZV9ub3RlOiBMT0FERVIgPSAi
Z2VuZXJpYyINCihYRU4pIFsyMDEyLTA5LTAxIDIyOjI2OjUxXSBlbGZfeGVuX3BhcnNlX25v
dGU6IHVua25vd24geGVuIGVsZiBub3RlICgweGQpDQooWEVOKSBbMjAxMi0wOS0wMSAyMjoy
Njo1MV0gZWxmX3hlbl9wYXJzZV9ub3RlOiBTVVNQRU5EX0NBTkNFTCA9IDB4MQ0KKFhFTikg
WzIwMTItMDktMDEgMjI6MjY6NTFdIGVsZl94ZW5fcGFyc2Vfbm90ZTogSFZfU1RBUlRfTE9X
ID0gMHhmZmZmODAwMDAwMDAwMDAwDQooWEVOKSBbMjAxMi0wOS0wMSAyMjoyNjo1MV0gZWxm
X3hlbl9wYXJzZV9ub3RlOiBQQUREUl9PRkZTRVQgPSAweDANCihYRU4pIFsyMDEyLTA5LTAx
IDIyOjI2OjUxXSBlbGZfeGVuX2FkZHJfY2FsY19jaGVjazogYWRkcmVzc2VzOg0KKFhFTikg
WzIwMTItMDktMDEgMjI6MjY6NTFdICAgICB2aXJ0X2Jhc2UgICAgICAgID0gMHhmZmZmZmZm
ZjgwMDAwMDAwDQooWEVOKSBbMjAxMi0wOS0wMSAyMjoyNjo1MV0gICAgIGVsZl9wYWRkcl9v
ZmZzZXQgPSAweDANCihYRU4pIFsyMDEyLTA5LTAxIDIyOjI2OjUxXSAgICAgdmlydF9vZmZz
ZXQgICAgICA9IDB4ZmZmZmZmZmY4MDAwMDAwMA0KKFhFTikgWzIwMTItMDktMDEgMjI6MjY6
NTFdICAgICB2aXJ0X2tzdGFydCAgICAgID0gMHhmZmZmZmZmZjgxMDAwMDAwDQooWEVOKSBb
MjAxMi0wOS0wMSAyMjoyNjo1MV0gICAgIHZpcnRfa2VuZCAgICAgICAgPSAweGZmZmZmZmZm
ODJhZDEwMDANCihYRU4pIFsyMDEyLTA5LTAxIDIyOjI2OjUxXSAgICAgdmlydF9lbnRyeSAg
ICAgICA9IDB4ZmZmZmZmZmY4MWNlZDIxMA0KKFhFTikgWzIwMTItMDktMDEgMjI6MjY6NTFd
ICAgICBwMm1fYmFzZSAgICAgICAgID0gMHhmZmZmZmZmZmZmZmZmZmZmDQooWEVOKSBbMjAx
Mi0wOS0wMSAyMjoyNjo1MV0gIFhlbiAga2VybmVsOiA2NC1iaXQsIGxzYiwgY29tcGF0MzIN
CihYRU4pIFsyMDEyLTA5LTAxIDIyOjI2OjUxXSAgRG9tMCBrZXJuZWw6IDY0LWJpdCwgUEFF
LCBsc2IsIHBhZGRyIDB4MTAwMDAwMCAtPiAweDJhZDEwMDANCihYRU4pIFsyMDEyLTA5LTAx
IDIyOjI2OjUxXSBQSFlTSUNBTCBNRU1PUlkgQVJSQU5HRU1FTlQ6DQooWEVOKSBbMjAxMi0w
OS0wMSAyMjoyNjo1MV0gIERvbTAgYWxsb2MuOiAgIDAwMDAwMDAyNDAwMDAwMDAtPjAwMDAw
MDAyNDQwMDAwMDAgKDI0MjQyOCBwYWdlcyB0byBiZSBhbGxvY2F0ZWQpDQooWEVOKSBbMjAx
Mi0wOS0wMSAyMjoyNjo1MV0gIEluaXQuIHJhbWRpc2s6IDAwMDAwMDAyNGYyZmMwMDAtPjAw
MDAwMDAyNGZmZmY4MDANCihYRU4pIFsyMDEyLTA5LTAxIDIyOjI2OjUxXSBWSVJUVUFMIE1F
TU9SWSBBUlJBTkdFTUVOVDoNCihYRU4pIFsyMDEyLTA5LTAxIDIyOjI2OjUxXSAgTG9hZGVk
IGtlcm5lbDogZmZmZmZmZmY4MTAwMDAwMC0+ZmZmZmZmZmY4MmFkMTAwMA0KKFhFTikgWzIw
MTItMDktMDEgMjI6MjY6NTFdICBJbml0LiByYW1kaXNrOiBmZmZmZmZmZjgyYWQxMDAwLT5m
ZmZmZmZmZjgzN2Q0ODAwDQooWEVOKSBbMjAxMi0wOS0wMSAyMjoyNjo1MV0gIFBoeXMtTWFj
aCBtYXA6IGZmZmZmZmZmODM3ZDUwMDAtPmZmZmZmZmZmODM5ZDUwMDANCihYRU4pIFsyMDEy
LTA5LTAxIDIyOjI2OjUxXSAgU3RhcnQgaW5mbzogICAgZmZmZmZmZmY4MzlkNTAwMC0+ZmZm
ZmZmZmY4MzlkNTRiNA0KKFhFTikgWzIwMTItMDktMDEgMjI6MjY6NTFdICBQYWdlIHRhYmxl
czogICBmZmZmZmZmZjgzOWQ2MDAwLT5mZmZmZmZmZjgzOWY3MDAwDQooWEVOKSBbMjAxMi0w
OS0wMSAyMjoyNjo1MV0gIEJvb3Qgc3RhY2s6ICAgIGZmZmZmZmZmODM5ZjcwMDAtPmZmZmZm
ZmZmODM5ZjgwMDANCihYRU4pIFsyMDEyLTA5LTAxIDIyOjI2OjUxXSAgVE9UQUw6ICAgICAg
ICAgZmZmZmZmZmY4MDAwMDAwMC0+ZmZmZmZmZmY4M2MwMDAwMA0KKFhFTikgWzIwMTItMDkt
MDEgMjI6MjY6NTFdICBFTlRSWSBBRERSRVNTOiBmZmZmZmZmZjgxY2VkMjEwDQooWEVOKSBb
MjAxMi0wOS0wMSAyMjoyNjo1MV0gRG9tMCBoYXMgbWF4aW11bSA2IFZDUFVzDQooWEVOKSBb
MjAxMi0wOS0wMSAyMjoyNjo1MV0gZWxmX2xvYWRfYmluYXJ5OiBwaGRyIDAgYXQgMHhmZmZm
ZmZmZjgxMDAwMDAwIC0+IDB4ZmZmZmZmZmY4MWI2ODAwMA0KKFhFTikgWzIwMTItMDktMDEg
MjI6MjY6NTFdIGVsZl9sb2FkX2JpbmFyeTogcGhkciAxIGF0IDB4ZmZmZmZmZmY4MWMwMDAw
MCAtPiAweGZmZmZmZmZmODFjZDgwZTgNCihYRU4pIFsyMDEyLTA5LTAxIDIyOjI2OjUxXSBl
bGZfbG9hZF9iaW5hcnk6IHBoZHIgMiBhdCAweGZmZmZmZmZmODFjZDkwMDAgLT4gMHhmZmZm
ZmZmZjgxY2VjYzAwDQooWEVOKSBbMjAxMi0wOS0wMSAyMjoyNjo1MV0gZWxmX2xvYWRfYmlu
YXJ5OiBwaGRyIDMgYXQgMHhmZmZmZmZmZjgxY2VkMDAwIC0+IDB4ZmZmZmZmZmY4MWQ4NTAw
MA0KKFhFTikgWzIwMTItMDktMDEgMjI6MjY6NTFdIEFNRC1WaTogU2V0dXAgSS9PIHBhZ2Ug
dGFibGU6IGRldmljZSBpZCA9IDB4MDAwMCwgcm9vdCB0YWJsZSA9IDB4MjRkYTUzMDAwLCBk
b21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMNCihYRU4pIFsyMDEyLTA5LTAxIDIyOjI2OjUx
XSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweDAwMDIsIHJv
b3QgdGFibGUgPSAweDI0ZGE1MzAwMCwgZG9tYWluID0gMCwgcGFnaW5nIG1vZGUgPSAzDQoo
WEVOKSBbMjAxMi0wOS0wMSAyMjoyNjo1MV0gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJs
ZTogZGV2aWNlIGlkID0gMHgwMDEwLCByb290IHRhYmxlID0gMHgyNGRhNTMwMDAsIGRvbWFp
biA9IDAsIHBhZ2luZyBtb2RlID0gMw0KKFhFTikgWzIwMTItMDktMDEgMjI6MjY6NTFdIEFN
RC1WaTogU2V0dXAgSS9PIHBhZ2UgdGFibGU6IGRldmljZSBpZCA9IDB4MDAxOCwgcm9vdCB0
YWJsZSA9IDB4MjRkYTUzMDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMNCihYRU4p
IFsyMDEyLTA5LTAxIDIyOjI2OjUxXSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBk
ZXZpY2UgaWQgPSAweDAwMjgsIHJvb3QgdGFibGUgPSAweDI0ZGE1MzAwMCwgZG9tYWluID0g
MCwgcGFnaW5nIG1vZGUgPSAzDQooWEVOKSBbMjAxMi0wOS0wMSAyMjoyNjo1MV0gQU1ELVZp
OiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHgwMDMwLCByb290IHRhYmxl
ID0gMHgyNGRhNTMwMDAsIGRvbWFpbiA9IDAsIHBhZ2luZyBtb2RlID0gMw0KKFhFTikgWzIw
MTItMDktMDEgMjI6MjY6NTFdIEFNRC1WaTogU2V0dXAgSS9PIHBhZ2UgdGFibGU6IGRldmlj
ZSBpZCA9IDB4MDA1MCwgcm9vdCB0YWJsZSA9IDB4MjRkYTUzMDAwLCBkb21haW4gPSAwLCBw
YWdpbmcgbW9kZSA9IDMNCihYRU4pIFsyMDEyLTA5LTAxIDIyOjI2OjUxXSBBTUQtVmk6IFNl
dHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweDAwNTgsIHJvb3QgdGFibGUgPSAw
eDI0ZGE1MzAwMCwgZG9tYWluID0gMCwgcGFnaW5nIG1vZGUgPSAzDQooWEVOKSBbMjAxMi0w
OS0wMSAyMjoyNjo1MV0gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlk
ID0gMHgwMDYwLCByb290IHRhYmxlID0gMHgyNGRhNTMwMDAsIGRvbWFpbiA9IDAsIHBhZ2lu
ZyBtb2RlID0gMw0KKFhFTikgWzIwMTItMDktMDEgMjI6MjY6NTFdIEFNRC1WaTogU2V0dXAg
SS9PIHBhZ2UgdGFibGU6IGRldmljZSBpZCA9IDB4MDA2OCwgcm9vdCB0YWJsZSA9IDB4MjRk
YTUzMDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMNCihYRU4pIFsyMDEyLTA5LTAx
IDIyOjI2OjUxXSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAw
eDAwODgsIHJvb3QgdGFibGUgPSAweDI0ZGE1MzAwMCwgZG9tYWluID0gMCwgcGFnaW5nIG1v
ZGUgPSAzDQooWEVOKSBbMjAxMi0wOS0wMSAyMjoyNjo1MV0gQU1ELVZpOiBTZXR1cCBJL08g
cGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHgwMDkwLCByb290IHRhYmxlID0gMHgyNGRhNTMw
MDAsIGRvbWFpbiA9IDAsIHBhZ2luZyBtb2RlID0gMw0KKFhFTikgWzIwMTItMDktMDEgMjI6
MjY6NTFdIEFNRC1WaTogU2V0dXAgSS9PIHBhZ2UgdGFibGU6IGRldmljZSBpZCA9IDB4MDA5
Miwgcm9vdCB0YWJsZSA9IDB4MjRkYTUzMDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9
IDMNCihYRU4pIFsyMDEyLTA5LTAxIDIyOjI2OjUxXSBBTUQtVmk6IFNldHVwIEkvTyBwYWdl
IHRhYmxlOiBkZXZpY2UgaWQgPSAweDAwOTgsIHJvb3QgdGFibGUgPSAweDI0ZGE1MzAwMCwg
ZG9tYWluID0gMCwgcGFnaW5nIG1vZGUgPSAzDQooWEVOKSBbMjAxMi0wOS0wMSAyMjoyNjo1
MV0gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHgwMDlhLCBy
b290IHRhYmxlID0gMHgyNGRhNTMwMDAsIGRvbWFpbiA9IDAsIHBhZ2luZyBtb2RlID0gMw0K
KFhFTikgWzIwMTItMDktMDEgMjI6MjY6NTFdIEFNRC1WaTogU2V0dXAgSS9PIHBhZ2UgdGFi
bGU6IGRldmljZSBpZCA9IDB4MDBhMCwgcm9vdCB0YWJsZSA9IDB4MjRkYTUzMDAwLCBkb21h
aW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMNCihYRU4pIFsyMDEyLTA5LTAxIDIyOjI2OjUxXSBB
TUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweDAwYTMsIHJvb3Qg
dGFibGUgPSAweDI0ZGE1MzAwMCwgZG9tYWluID0gMCwgcGFnaW5nIG1vZGUgPSAzDQooWEVO
KSBbMjAxMi0wOS0wMSAyMjoyNjo1MV0gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTog
ZGV2aWNlIGlkID0gMHgwMGE0LCByb290IHRhYmxlID0gMHgyNGRhNTMwMDAsIGRvbWFpbiA9
IDAsIHBhZ2luZyBtb2RlID0gMw0KKFhFTikgWzIwMTItMDktMDEgMjI6MjY6NTFdIEFNRC1W
aTogU2V0dXAgSS9PIHBhZ2UgdGFibGU6IGRldmljZSBpZCA9IDB4MDBhNSwgcm9vdCB0YWJs
ZSA9IDB4MjRkYTUzMDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMNCihYRU4pIFsy
MDEyLTA5LTAxIDIyOjI2OjUxXSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZp
Y2UgaWQgPSAweDAwYTgsIHJvb3QgdGFibGUgPSAweDI0ZGE1MzAwMCwgZG9tYWluID0gMCwg
cGFnaW5nIG1vZGUgPSAzDQooWEVOKSBbMjAxMi0wOS0wMSAyMjoyNjo1MV0gQU1ELVZpOiBT
ZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHgwMGIwLCByb290IHRhYmxlID0g
MHgyNGRhNTMwMDAsIGRvbWFpbiA9IDAsIHBhZ2luZyBtb2RlID0gMw0KKFhFTikgWzIwMTIt
MDktMDEgMjI6MjY6NTFdIEFNRC1WaTogU2V0dXAgSS9PIHBhZ2UgdGFibGU6IGRldmljZSBp
ZCA9IDB4MDBiMiwgcm9vdCB0YWJsZSA9IDB4MjRkYTUzMDAwLCBkb21haW4gPSAwLCBwYWdp
bmcgbW9kZSA9IDMNCihYRU4pIFsyMDEyLTA5LTAxIDIyOjI2OjUxXSBBTUQtVmk6IE5vIGlv
bW11IGZvciBkZXZpY2UgMDAwMDowMDoxOC4wDQooWEVOKSBbMjAxMi0wOS0wMSAyMjoyNjo1
MV0gQU1ELVZpOiBObyBpb21tdSBmb3IgZGV2aWNlIDAwMDA6MDA6MTguMQ0KKFhFTikgWzIw
MTItMDktMDEgMjI6MjY6NTFdIEFNRC1WaTogTm8gaW9tbXUgZm9yIGRldmljZSAwMDAwOjAw
OjE4LjINCihYRU4pIFsyMDEyLTA5LTAxIDIyOjI2OjUxXSBBTUQtVmk6IE5vIGlvbW11IGZv
ciBkZXZpY2UgMDAwMDowMDoxOC4zDQooWEVOKSBbMjAxMi0wOS0wMSAyMjoyNjo1MV0gQU1E
LVZpOiBObyBpb21tdSBmb3IgZGV2aWNlIDAwMDA6MDA6MTguNA0KKFhFTikgWzIwMTItMDkt
MDEgMjI6MjY6NTFdIEFNRC1WaTogU2V0dXAgSS9PIHBhZ2UgdGFibGU6IGRldmljZSBpZCA9
IDB4MDQwMCwgcm9vdCB0YWJsZSA9IDB4MjRkYTUzMDAwLCBkb21haW4gPSAwLCBwYWdpbmcg
bW9kZSA9IDMNCihYRU4pIFsyMDEyLTA5LTAxIDIyOjI2OjUxXSBBTUQtVmk6IFNldHVwIEkv
TyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweDA0MDEsIHJvb3QgdGFibGUgPSAweDI0ZGE1
MzAwMCwgZG9tYWluID0gMCwgcGFnaW5nIG1vZGUgPSAzDQooWEVOKSBbMjAxMi0wOS0wMSAy
MjoyNjo1MV0gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHgw
NDAyLCByb290IHRhYmxlID0gMHgyNGRhNTMwMDAsIGRvbWFpbiA9IDAsIHBhZ2luZyBtb2Rl
ID0gMw0KKFhFTikgWzIwMTItMDktMDEgMjI6MjY6NTFdIEFNRC1WaTogU2V0dXAgSS9PIHBh
Z2UgdGFibGU6IGRldmljZSBpZCA9IDB4MDQwMywgcm9vdCB0YWJsZSA9IDB4MjRkYTUzMDAw
LCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMNCihYRU4pIFsyMDEyLTA5LTAxIDIyOjI2
OjUxXSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweDA0MDQs
IHJvb3QgdGFibGUgPSAweDI0ZGE1MzAwMCwgZG9tYWluID0gMCwgcGFnaW5nIG1vZGUgPSAz
DQooWEVOKSBbMjAxMi0wOS0wMSAyMjoyNjo1MV0gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0
YWJsZTogZGV2aWNlIGlkID0gMHgwNDA1LCByb290IHRhYmxlID0gMHgyNGRhNTMwMDAsIGRv
bWFpbiA9IDAsIHBhZ2luZyBtb2RlID0gMw0KKFhFTikgWzIwMTItMDktMDEgMjI6MjY6NTFd
IEFNRC1WaTogU2V0dXAgSS9PIHBhZ2UgdGFibGU6IGRldmljZSBpZCA9IDB4MDQwNiwgcm9v
dCB0YWJsZSA9IDB4MjRkYTUzMDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMNCihY
RU4pIFsyMDEyLTA5LTAxIDIyOjI2OjUyXSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxl
OiBkZXZpY2UgaWQgPSAweDA0MDcsIHJvb3QgdGFibGUgPSAweDI0ZGE1MzAwMCwgZG9tYWlu
ID0gMCwgcGFnaW5nIG1vZGUgPSAzDQooWEVOKSBbMjAxMi0wOS0wMSAyMjoyNjo1Ml0gQU1E
LVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHgwNTAwLCByb290IHRh
YmxlID0gMHgyNGRhNTMwMDAsIGRvbWFpbiA9IDAsIHBhZ2luZyBtb2RlID0gMw0KKFhFTikg
WzIwMTItMDktMDEgMjI6MjY6NTJdIEFNRC1WaTogU2V0dXAgSS9PIHBhZ2UgdGFibGU6IGRl
dmljZSBpZCA9IDB4MDYwMCwgcm9vdCB0YWJsZSA9IDB4MjRkYTUzMDAwLCBkb21haW4gPSAw
LCBwYWdpbmcgbW9kZSA9IDMNCihYRU4pIFsyMDEyLTA5LTAxIDIyOjI2OjUyXSBBTUQtVmk6
IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweDA2MDEsIHJvb3QgdGFibGUg
PSAweDI0ZGE1MzAwMCwgZG9tYWluID0gMCwgcGFnaW5nIG1vZGUgPSAzDQooWEVOKSBbMjAx
Mi0wOS0wMSAyMjoyNjo1Ml0gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNl
IGlkID0gMHgwNzAwLCByb290IHRhYmxlID0gMHgyNGRhNTMwMDAsIGRvbWFpbiA9IDAsIHBh
Z2luZyBtb2RlID0gMw0KKFhFTikgWzIwMTItMDktMDEgMjI6MjY6NTJdIEFNRC1WaTogU2V0
dXAgSS9PIHBhZ2UgdGFibGU6IGRldmljZSBpZCA9IDB4MDgwMCwgcm9vdCB0YWJsZSA9IDB4
MjRkYTUzMDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMNCihYRU4pIFsyMDEyLTA5
LTAxIDIyOjI2OjUyXSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQg
PSAweDA5MDAsIHJvb3QgdGFibGUgPSAweDI0ZGE1MzAwMCwgZG9tYWluID0gMCwgcGFnaW5n
IG1vZGUgPSAzDQooWEVOKSBbMjAxMi0wOS0wMSAyMjoyNjo1Ml0gQU1ELVZpOiBTZXR1cCBJ
L08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHgwYTAwLCByb290IHRhYmxlID0gMHgyNGRh
NTMwMDAsIGRvbWFpbiA9IDAsIHBhZ2luZyBtb2RlID0gMw0KKFhFTikgWzIwMTItMDktMDEg
MjI6MjY6NTJdIEFNRC1WaTogU2V0dXAgSS9PIHBhZ2UgdGFibGU6IGRldmljZSBpZCA9IDB4
MGEwMSwgcm9vdCB0YWJsZSA9IDB4MjRkYTUzMDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9k
ZSA9IDMNCihYRU4pIFsyMDEyLTA5LTAxIDIyOjI2OjUyXSBBTUQtVmk6IFNldHVwIEkvTyBw
YWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweDBhMDIsIHJvb3QgdGFibGUgPSAweDI0ZGE1MzAw
MCwgZG9tYWluID0gMCwgcGFnaW5nIG1vZGUgPSAzDQooWEVOKSBbMjAxMi0wOS0wMSAyMjoy
Njo1Ml0gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHgwYTAz
LCByb290IHRhYmxlID0gMHgyNGRhNTMwMDAsIGRvbWFpbiA9IDAsIHBhZ2luZyBtb2RlID0g
Mw0KKFhFTikgWzIwMTItMDktMDEgMjI6MjY6NTJdIEFNRC1WaTogU2V0dXAgSS9PIHBhZ2Ug
dGFibGU6IGRldmljZSBpZCA9IDB4MGEwNCwgcm9vdCB0YWJsZSA9IDB4MjRkYTUzMDAwLCBk
b21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMNCihYRU4pIFsyMDEyLTA5LTAxIDIyOjI2OjUy
XSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweDBhMDUsIHJv
b3QgdGFibGUgPSAweDI0ZGE1MzAwMCwgZG9tYWluID0gMCwgcGFnaW5nIG1vZGUgPSAzDQoo
WEVOKSBbMjAxMi0wOS0wMSAyMjoyNjo1Ml0gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJs
ZTogZGV2aWNlIGlkID0gMHgwYTA2LCByb290IHRhYmxlID0gMHgyNGRhNTMwMDAsIGRvbWFp
biA9IDAsIHBhZ2luZyBtb2RlID0gMw0KKFhFTikgWzIwMTItMDktMDEgMjI6MjY6NTJdIEFN
RC1WaTogU2V0dXAgSS9PIHBhZ2UgdGFibGU6IGRldmljZSBpZCA9IDB4MGEwNywgcm9vdCB0
YWJsZSA9IDB4MjRkYTUzMDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMNCihYRU4p
IFsyMDEyLTA5LTAxIDIyOjI2OjUyXSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBk
ZXZpY2UgaWQgPSAweDBiMDAsIHJvb3QgdGFibGUgPSAweDI0ZGE1MzAwMCwgZG9tYWluID0g
MCwgcGFnaW5nIG1vZGUgPSAzDQooWEVOKSBbMjAxMi0wOS0wMSAyMjoyNjo1Ml0gU2NydWJi
aW5nIEZyZWUgUkFNOiAuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u
Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLmRvbmUuDQooWEVOKSBbMjAxMi0wOS0w
MSAyMjoyNjo1M10gSW5pdGlhbCBsb3cgbWVtb3J5IHZpcnEgdGhyZXNob2xkIHNldCBhdCAw
eDQwMDAgcGFnZXMuDQooWEVOKSBbMjAxMi0wOS0wMSAyMjoyNjo1M10gU3RkLiBMb2dsZXZl
bDogQWxsDQooWEVOKSBbMjAxMi0wOS0wMSAyMjoyNjo1NF0gR3Vlc3QgTG9nbGV2ZWw6IEFs
bA0KKFhFTikgWzIwMTItMDktMDEgMjI6MjY6NTRdIFhlbiBpcyByZWxpbnF1aXNoaW5nIFZH
QSBjb25zb2xlLg0KKFhFTikgWzIwMTItMDktMDEgMjI6MjY6NTRdICoqKiBTZXJpYWwgaW5w
dXQgLT4gRE9NMCAodHlwZSAnQ1RSTC1hJyB0aHJlZSB0aW1lcyB0byBzd2l0Y2ggaW5wdXQg
dG8gWGVuKQ0KKFhFTikgWzIwMTItMDktMDEgMjI6MjY6NTRdIEZyZWVkIDI1NmtCIGluaXQg
bWVtb3J5Lg0KKFhFTikgWzIwMTItMDktMDEgMjI6MjY6NTRdIElPQVBJQ1swXTogU2V0IFBD
SSByb3V0aW5nIGVudHJ5ICg2LTkgLT4gMHg2MCAtPiBJUlEgOSBNb2RlOjEgQWN0aXZlOjEp
DQooWEVOKSBbMjAxMi0wOS0wMSAyMjoyNjo1NF0gdHJhcHMuYzoyNTg0OmQwIERvbWFpbiBh
dHRlbXB0ZWQgV1JNU1IgMDAwMDAwMDBjMDAwMDQwOCBmcm9tIDB4YzAwMDAwMDAwMTAwMDAw
MCB0byAweGMwMDgwMDAwMDEwMDAwMDAuDQooWEVOKSBbMjAxMi0wOS0wMSAyMjoyNjo1NF0g
dHJhcHMuYzoyNTg0OmQwIERvbWFpbiBhdHRlbXB0ZWQgV1JNU1IgMDAwMDAwMDBjMDAwMDQw
OSBmcm9tIDB4YzAwMDAwMDAwMTAwMDAwMCB0byAweGMwMDgwMDAwMDEwMDAwMDAuDQooWEVO
KSBbMjAxMi0wOS0wMSAyMjoyNjo1NF0gdHJhcHMuYzoyNTg0OmQwIERvbWFpbiBhdHRlbXB0
ZWQgV1JNU1IgMDAwMDAwMDBjMDAxMDAwNCBmcm9tIDB4MDAwMGVmZjBiZGZiMWZjZSB0byAw
eDAwMDAwMDAwMDAwMGFiY2QuDQooWEVOKSBbMjAxMi0wOS0wMSAyMjoyNjo1NF0gdHJhcHMu
YzoyNTg0OmQwIERvbWFpbiBhdHRlbXB0ZWQgV1JNU1IgMDAwMDAwMDBjMDAwMDQwOCBmcm9t
IDB4YzAwMDAwMDAwMTAwMDAwMCB0byAweGMwMDgwMDAwMDEwMDAwMDAuDQooWEVOKSBbMjAx
Mi0wOS0wMSAyMjoyNjo1NF0gdHJhcHMuYzoyNTg0OmQwIERvbWFpbiBhdHRlbXB0ZWQgV1JN
U1IgMDAwMDAwMDBjMDAwMDQwOSBmcm9tIDB4YzAwMDAwMDAwMTAwMDAwMCB0byAweGMwMDgw
MDAwMDEwMDAwMDAuDQooWEVOKSBbMjAxMi0wOS0wMSAyMjoyNjo1NF0gdHJhcHMuYzoyNTg0
OmQwIERvbWFpbiBhdHRlbXB0ZWQgV1JNU1IgMDAwMDAwMDBjMDAwMDQwOCBmcm9tIDB4YzAw
MDAwMDAwMTAwMDAwMCB0byAweGMwMDgwMDAwMDEwMDAwMDAuDQooWEVOKSBbMjAxMi0wOS0w
MSAyMjoyNjo1NF0gdHJhcHMuYzoyNTg0OmQwIERvbWFpbiBhdHRlbXB0ZWQgV1JNU1IgMDAw
MDAwMDBjMDAwMDQwOSBmcm9tIDB4YzAwMDAwMDAwMTAwMDAwMCB0byAweGMwMDgwMDAwMDEw
MDAwMDAuDQooWEVOKSBbMjAxMi0wOS0wMSAyMjoyNjo1NF0gdHJhcHMuYzoyNTg0OmQwIERv
bWFpbiBhdHRlbXB0ZWQgV1JNU1IgMDAwMDAwMDBjMDAwMDQwOCBmcm9tIDB4YzAwMDAwMDAw
MTAwMDAwMCB0byAweGMwMDgwMDAwMDEwMDAwMDAuDQooWEVOKSBbMjAxMi0wOS0wMSAyMjoy
Njo1NF0gdHJhcHMuYzoyNTg0OmQwIERvbWFpbiBhdHRlbXB0ZWQgV1JNU1IgMDAwMDAwMDBj
MDAwMDQwOSBmcm9tIDB4YzAwMDAwMDAwMTAwMDAwMCB0byAweGMwMDgwMDAwMDEwMDAwMDAu
DQooWEVOKSBbMjAxMi0wOS0wMSAyMjoyNjo1NF0gdHJhcHMuYzoyNTg0OmQwIERvbWFpbiBh
dHRlbXB0ZWQgV1JNU1IgMDAwMDAwMDBjMDAwMDQwOCBmcm9tIDB4YzAwMDAwMDAwMTAwMDAw
MCB0byAweGMwMDgwMDAwMDEwMDAwMDAuDQooWEVOKSBbMjAxMi0wOS0wMSAyMjoyNjo1NF0g
dHJhcHMuYzoyNTg0OmQwIERvbWFpbiBhdHRlbXB0ZWQgV1JNU1IgMDAwMDAwMDBjMDAwMDQw
OSBmcm9tIDB4YzAwMDAwMDAwMTAwMDAwMCB0byAweGMwMDgwMDAwMDEwMDAwMDAuDQooWEVO
KSBbMjAxMi0wOS0wMSAyMjoyNjo1NF0gdHJhcHMuYzoyNTg0OmQwIERvbWFpbiBhdHRlbXB0
ZWQgV1JNU1IgMDAwMDAwMDBjMDAwMDQwOCBmcm9tIDB4YzAwMDAwMDAwMTAwMDAwMCB0byAw
eGMwMDgwMDAwMDEwMDAwMDAuDQooWEVOKSBbMjAxMi0wOS0wMSAyMjoyNjo1NF0gdHJhcHMu
YzoyNTg0OmQwIERvbWFpbiBhdHRlbXB0ZWQgV1JNU1IgMDAwMDAwMDBjMDAwMDQwOSBmcm9t
IDB4YzAwMDAwMDAwMTAwMDAwMCB0byAweGMwMDgwMDAwMDEwMDAwMDAuDQooWEVOKSBbMjAx
Mi0wOS0wMSAyMjoyNjo1NF0gUENJIGFkZCBkZXZpY2UgMDAwMDowMDowMC4wDQooWEVOKSBb
MjAxMi0wOS0wMSAyMjoyNjo1NF0gUENJIGFkZCBkZXZpY2UgMDAwMDowMDowMC4yDQooWEVO
KSBbMjAxMi0wOS0wMSAyMjoyNjo1NF0gUENJIGFkZCBkZXZpY2UgMDAwMDowMDowMi4wDQoo
WEVOKSBbMjAxMi0wOS0wMSAyMjoyNjo1NF0gUENJIGFkZCBkZXZpY2UgMDAwMDowMDowMy4w
DQooWEVOKSBbMjAxMi0wOS0wMSAyMjoyNjo1NF0gUENJIGFkZCBkZXZpY2UgMDAwMDowMDow
NS4wDQooWEVOKSBbMjAxMi0wOS0wMSAyMjoyNjo1NF0gUENJIGFkZCBkZXZpY2UgMDAwMDow
MDowNi4wDQooWEVOKSBbMjAxMi0wOS0wMSAyMjoyNjo1NF0gUENJIGFkZCBkZXZpY2UgMDAw
MDowMDowYS4wDQooWEVOKSBbMjAxMi0wOS0wMSAyMjoyNjo1NF0gUENJIGFkZCBkZXZpY2Ug
MDAwMDowMDowYi4wDQooWEVOKSBbMjAxMi0wOS0wMSAyMjoyNjo1NF0gUENJIGFkZCBkZXZp
Y2UgMDAwMDowMDowYy4wDQooWEVOKSBbMjAxMi0wOS0wMSAyMjoyNjo1NF0gUENJIGFkZCBk
ZXZpY2UgMDAwMDowMDowZC4wDQooWEVOKSBbMjAxMi0wOS0wMSAyMjoyNjo1NF0gUENJIGFk
ZCBkZXZpY2UgMDAwMDowMDoxMS4wDQooWEVOKSBbMjAxMi0wOS0wMSAyMjoyNjo1NF0gUENJ
IGFkZCBkZXZpY2UgMDAwMDowMDoxMi4wDQooWEVOKSBbMjAxMi0wOS0wMSAyMjoyNjo1NF0g
UENJIGFkZCBkZXZpY2UgMDAwMDowMDoxMi4yDQooWEVOKSBbMjAxMi0wOS0wMSAyMjoyNjo1
NF0gUENJIGFkZCBkZXZpY2UgMDAwMDowMDoxMy4wDQooWEVOKSBbMjAxMi0wOS0wMSAyMjoy
Njo1NF0gUENJIGFkZCBkZXZpY2UgMDAwMDowMDoxMy4yDQooWEVOKSBbMjAxMi0wOS0wMSAy
MjoyNjo1NF0gUENJIGFkZCBkZXZpY2UgMDAwMDowMDoxNC4wDQooWEVOKSBbMjAxMi0wOS0w
MSAyMjoyNjo1NF0gUENJIGFkZCBkZXZpY2UgMDAwMDowMDoxNC4zDQooWEVOKSBbMjAxMi0w
OS0wMSAyMjoyNjo1NF0gUENJIGFkZCBkZXZpY2UgMDAwMDowMDoxNC40DQooWEVOKSBbMjAx
Mi0wOS0wMSAyMjoyNjo1NF0gUENJIGFkZCBkZXZpY2UgMDAwMDowMDoxNC41DQooWEVOKSBb
MjAxMi0wOS0wMSAyMjoyNjo1NF0gUENJIGFkZCBkZXZpY2UgMDAwMDowMDoxNS4wDQooWEVO
KSBbMjAxMi0wOS0wMSAyMjoyNjo1NF0gUENJIGFkZCBkZXZpY2UgMDAwMDowMDoxNi4wDQoo
WEVOKSBbMjAxMi0wOS0wMSAyMjoyNjo1NF0gUENJIGFkZCBkZXZpY2UgMDAwMDowMDoxNi4y
DQooWEVOKSBbMjAxMi0wOS0wMSAyMjoyNjo1NF0gUENJIGFkZCBkZXZpY2UgMDAwMDowMDox
OC4wDQooWEVOKSBbMjAxMi0wOS0wMSAyMjoyNjo1NF0gUENJIGFkZCBkZXZpY2UgMDAwMDow
MDoxOC4xDQooWEVOKSBbMjAxMi0wOS0wMSAyMjoyNjo1NF0gUENJIGFkZCBkZXZpY2UgMDAw
MDowMDoxOC4yDQooWEVOKSBbMjAxMi0wOS0wMSAyMjoyNjo1NF0gUENJIGFkZCBkZXZpY2Ug
MDAwMDowMDoxOC4zDQooWEVOKSBbMjAxMi0wOS0wMSAyMjoyNjo1NF0gUENJIGFkZCBkZXZp
Y2UgMDAwMDowMDoxOC40DQooWEVOKSBbMjAxMi0wOS0wMSAyMjoyNjo1NF0gUENJIGFkZCBk
ZXZpY2UgMDAwMDowYjowMC4wDQooWEVOKSBbMjAxMi0wOS0wMSAyMjoyNjo1NF0gUENJIGFk
ZCBkZXZpY2UgMDAwMDowYTowMC4wDQooWEVOKSBbMjAxMi0wOS0wMSAyMjoyNjo1NF0gUENJ
IGFkZCBkZXZpY2UgMDAwMDowYTowMC4xDQooWEVOKSBbMjAxMi0wOS0wMSAyMjoyNjo1NF0g
UENJIGFkZCBkZXZpY2UgMDAwMDowYTowMC4yDQooWEVOKSBbMjAxMi0wOS0wMSAyMjoyNjo1
NF0gUENJIGFkZCBkZXZpY2UgMDAwMDowYTowMC4zDQooWEVOKSBbMjAxMi0wOS0wMSAyMjoy
Njo1NF0gUENJIGFkZCBkZXZpY2UgMDAwMDowYTowMC40DQooWEVOKSBbMjAxMi0wOS0wMSAy
MjoyNjo1NF0gUENJIGFkZCBkZXZpY2UgMDAwMDowYTowMC41DQooWEVOKSBbMjAxMi0wOS0w
MSAyMjoyNjo1NF0gUENJIGFkZCBkZXZpY2UgMDAwMDowYTowMC42DQooWEVOKSBbMjAxMi0w
OS0wMSAyMjoyNjo1NF0gUENJIGFkZCBkZXZpY2UgMDAwMDowYTowMC43DQooWEVOKSBbMjAx
Mi0wOS0wMSAyMjoyNjo1NF0gUENJIGFkZCBkZXZpY2UgMDAwMDowOTowMC4wDQooWEVOKSBb
MjAxMi0wOS0wMSAyMjoyNjo1NF0gUENJIGFkZCBkZXZpY2UgMDAwMDowODowMC4wDQooWEVO
KSBbMjAxMi0wOS0wMSAyMjoyNjo1NF0gUENJIGFkZCBkZXZpY2UgMDAwMDowNzowMC4wDQoo
WEVOKSBbMjAxMi0wOS0wMSAyMjoyNjo1NF0gUENJIGFkZCBkZXZpY2UgMDAwMDowNjowMC4w
DQooWEVOKSBbMjAxMi0wOS0wMSAyMjoyNjo1NF0gUENJIGFkZCBkZXZpY2UgMDAwMDowNjow
MC4xDQooWEVOKSBbMjAxMi0wOS0wMSAyMjoyNjo1NF0gUENJIGFkZCBkZXZpY2UgMDAwMDow
NTowMC4wDQooWEVOKSBbMjAxMi0wOS0wMSAyMjoyNjo1NF0gUENJIGFkZCBkZXZpY2UgMDAw
MDowNDowMC4wDQooWEVOKSBbMjAxMi0wOS0wMSAyMjoyNjo1NF0gUENJIGFkZCBkZXZpY2Ug
MDAwMDowNDowMC4xDQooWEVOKSBbMjAxMi0wOS0wMSAyMjoyNjo1NF0gUENJIGFkZCBkZXZp
Y2UgMDAwMDowNDowMC4yDQooWEVOKSBbMjAxMi0wOS0wMSAyMjoyNjo1NF0gUENJIGFkZCBk
ZXZpY2UgMDAwMDowNDowMC4zDQooWEVOKSBbMjAxMi0wOS0wMSAyMjoyNjo1NF0gUENJIGFk
ZCBkZXZpY2UgMDAwMDowNDowMC40DQooWEVOKSBbMjAxMi0wOS0wMSAyMjoyNjo1NF0gUENJ
IGFkZCBkZXZpY2UgMDAwMDowNDowMC41DQooWEVOKSBbMjAxMi0wOS0wMSAyMjoyNjo1NF0g
UENJIGFkZCBkZXZpY2UgMDAwMDowNDowMC42DQooWEVOKSBbMjAxMi0wOS0wMSAyMjoyNjo1
NF0gUENJIGFkZCBkZXZpY2UgMDAwMDowNDowMC43DQooWEVOKSBbMjAxMi0wOS0wMSAyMjoy
Njo1NF0gUENJIGFkZCBkZXZpY2UgMDAwMDowMzowNi4wDQooWEVOKSBbMjAxMi0wOS0wMSAy
MjoyNjo1NF0gSU9BUElDWzBdOiBTZXQgUENJIHJvdXRpbmcgZW50cnkgKDYtOCAtPiAweDU4
IC0+IElSUSA4IE1vZGU6MCBBY3RpdmU6MCkNCihYRU4pIFsyMDEyLTA5LTAxIDIyOjI2OjU0
XSBJT0FQSUNbMF06IFNldCBQQ0kgcm91dGluZyBlbnRyeSAoNi0xMyAtPiAweDg4IC0+IElS
USAxMyBNb2RlOjAgQWN0aXZlOjApDQooWEVOKSBbMjAxMi0wOS0wMSAyMjoyNjo1NF0gSU9B
UElDWzFdOiBTZXQgUENJIHJvdXRpbmcgZW50cnkgKDctMjggLT4gMHhhMCAtPiBJUlEgNTIg
TW9kZToxIEFjdGl2ZToxKQ0KKFhFTikgWzIwMTItMDktMDEgMjI6MjY6NTRdIElPQVBJQ1sx
XTogU2V0IFBDSSByb3V0aW5nIGVudHJ5ICg3LTI5IC0+IDB4YTggLT4gSVJRIDUzIE1vZGU6
MSBBY3RpdmU6MSkNCihYRU4pIFsyMDEyLTA5LTAxIDIyOjI2OjU0XSBJT0FQSUNbMV06IFNl
dCBQQ0kgcm91dGluZyBlbnRyeSAoNy0zMCAtPiAweGIwIC0+IElSUSA1NCBNb2RlOjEgQWN0
aXZlOjEpDQooWEVOKSBbMjAxMi0wOS0wMSAyMjoyNjo1NF0gSU9BUElDWzBdOiBTZXQgUENJ
IHJvdXRpbmcgZW50cnkgKDYtMTYgLT4gMHhiOCAtPiBJUlEgMTYgTW9kZToxIEFjdGl2ZTox
KQ0KKFhFTikgWzIwMTItMDktMDEgMjI6MjY6NTRdIElPQVBJQ1swXTogU2V0IFBDSSByb3V0
aW5nIGVudHJ5ICg2LTE4IC0+IDB4YzAgLT4gSVJRIDE4IE1vZGU6MSBBY3RpdmU6MSkNCihY
RU4pIFsyMDEyLTA5LTAxIDIyOjI2OjU0XSBJT0FQSUNbMF06IFNldCBQQ0kgcm91dGluZyBl
bnRyeSAoNi0xNyAtPiAweGM4IC0+IElSUSAxNyBNb2RlOjEgQWN0aXZlOjEpDQooWEVOKSBb
MjAxMi0wOS0wMSAyMjoyNjo1NF0gSU9BUElDWzFdOiBTZXQgUENJIHJvdXRpbmcgZW50cnkg
KDctNCAtPiAweGQwIC0+IElSUSAyOCBNb2RlOjEgQWN0aXZlOjEpDQooWEVOKSBbMjAxMi0w
OS0wMSAyMjoyNjo1NF0gSU9BUElDWzFdOiBTZXQgUENJIHJvdXRpbmcgZW50cnkgKDctNSAt
PiAweGQ4IC0+IElSUSAyOSBNb2RlOjEgQWN0aXZlOjEpDQooWEVOKSBbMjAxMi0wOS0wMSAy
MjoyNjo1NV0gSU9BUElDWzFdOiBTZXQgUENJIHJvdXRpbmcgZW50cnkgKDctNiAtPiAweDIx
IC0+IElSUSAzMCBNb2RlOjEgQWN0aXZlOjEpDQooWEVOKSBbMjAxMi0wOS0wMSAyMjoyNjo1
NV0gSU9BUElDWzFdOiBTZXQgUENJIHJvdXRpbmcgZW50cnkgKDctNyAtPiAweDI5IC0+IElS
USAzMSBNb2RlOjEgQWN0aXZlOjEpDQooWEVOKSBbMjAxMi0wOS0wMSAyMjoyNjo1NV0gSU9B
UElDWzFdOiBTZXQgUENJIHJvdXRpbmcgZW50cnkgKDctMTYgLT4gMHgzMSAtPiBJUlEgNDAg
TW9kZToxIEFjdGl2ZToxKQ0KKFhFTikgWzIwMTItMDktMDEgMjI6MjY6NTVdIElPQVBJQ1sx
XTogU2V0IFBDSSByb3V0aW5nIGVudHJ5ICg3LTE3IC0+IDB4MzkgLT4gSVJRIDQxIE1vZGU6
MSBBY3RpdmU6MSkNCihYRU4pIFsyMDEyLTA5LTAxIDIyOjI2OjU1XSBJT0FQSUNbMV06IFNl
dCBQQ0kgcm91dGluZyBlbnRyeSAoNy0xOCAtPiAweDQxIC0+IElSUSA0MiBNb2RlOjEgQWN0
aXZlOjEpDQooWEVOKSBbMjAxMi0wOS0wMSAyMjoyNjo1NV0gSU9BUElDWzFdOiBTZXQgUENJ
IHJvdXRpbmcgZW50cnkgKDctMTkgLT4gMHg0OSAtPiBJUlEgNDMgTW9kZToxIEFjdGl2ZTox
KQ0KKFhFTikgWzIwMTItMDktMDEgMjI6MjY6NTVdIElPQVBJQ1swXTogU2V0IFBDSSByb3V0
aW5nIGVudHJ5ICg2LTIyIC0+IDB4OTkgLT4gSVJRIDIyIE1vZGU6MSBBY3RpdmU6MSkNCihY
RU4pIFsyMDEyLTA5LTAxIDIyOjI2OjU1XSBJT0FQSUNbMV06IFNldCBQQ0kgcm91dGluZyBl
bnRyeSAoNy0xMiAtPiAweGExIC0+IElSUSAzNiBNb2RlOjEgQWN0aXZlOjEpDQooWEVOKSBb
MjAxMi0wOS0wMSAyMjoyNjo1NV0gSU9BUElDWzFdOiBTZXQgUENJIHJvdXRpbmcgZW50cnkg
KDctMjMgLT4gMHhhOSAtPiBJUlEgNDcgTW9kZToxIEFjdGl2ZToxKQ0KKFhFTikgWzIwMTIt
MDktMDEgMjI6MjY6NTZdIElPQVBJQ1swXTogU2V0IFBDSSByb3V0aW5nIGVudHJ5ICg2LTE5
IC0+IDB4YjEgLT4gSVJRIDE5IE1vZGU6MSBBY3RpdmU6MSkNCihYRU4pIFsyMDEyLTA5LTAx
IDIyOjI2OjU2XSBJT0FQSUNbMV06IFNldCBQQ0kgcm91dGluZyBlbnRyeSAoNy0yMiAtPiAw
eGMxIC0+IElSUSA0NiBNb2RlOjEgQWN0aXZlOjEpDQooWEVOKSBbMjAxMi0wOS0wMSAyMjoy
Njo1Nl0gSU9BUElDWzFdOiBTZXQgUENJIHJvdXRpbmcgZW50cnkgKDctMjcgLT4gMHhkMSAt
PiBJUlEgNTEgTW9kZToxIEFjdGl2ZToxKQ0KKFhFTikgWzIwMTItMDktMDEgMjI6MjY6NThd
IElPQVBJQ1sxXTogU2V0IFBDSSByb3V0aW5nIGVudHJ5ICg3LTkgLT4gMHgyMiAtPiBJUlEg
MzMgTW9kZToxIEFjdGl2ZToxKQ0KKFhFTikgWzIwMTItMDktMDEgMjI6Mjc6NTldIHRyYXBz
LmM6MjU4NDpkMSBEb21haW4gYXR0ZW1wdGVkIFdSTVNSIDAwMDAwMDAwYzAwMTAwMDQgZnJv
bSAweDAwMDBhMTk1YzQwZjYxOGYgdG8gMHgwMDAwMDAwMDAwMDBhYmNkLg0KKFhFTikgWzIw
MTItMDktMDEgMjI6Mjg6MDVdIHRyYXBzLmM6MjU4NDpkMiBEb21haW4gYXR0ZW1wdGVkIFdS
TVNSIDAwMDAwMDAwYzAwMTAwMDQgZnJvbSAweDAwMDA2ZmIwMzlkZTc5MDAgdG8gMHgwMDAw
MDAwMDAwMDBhYmNkLg0KKFhFTikgWzIwMTItMDktMDEgMjI6Mjg6MTddIHRyYXBzLmM6MjU4
NDpkMyBEb21haW4gYXR0ZW1wdGVkIFdSTVNSIDAwMDAwMDAwYzAwMTAwMDQgZnJvbSAweDAw
MDBhMTk1YzQwZjYxOGYgdG8gMHgwMDAwMDAwMDAwMDBhYmNkLg0KKFhFTikgWzIwMTItMDkt
MDEgMjI6Mjg6MTddIHRyYXBzLmM6MjU4NDpkNCBEb21haW4gYXR0ZW1wdGVkIFdSTVNSIDAw
MDAwMDAwYzAwMTAwMDQgZnJvbSAweDAwMDA4Njc5YzAyYjQxNjUgdG8gMHgwMDAwMDAwMDAw
MDBhYmNkLg0KKFhFTikgWzIwMTItMDktMDEgMjI6Mjg6MjNdIHRyYXBzLmM6MjU4NDpkNSBE
b21haW4gYXR0ZW1wdGVkIFdSTVNSIDAwMDAwMDAwYzAwMTAwMDQgZnJvbSAweDAwMDA2ZmIw
MzlkZTc5MDAgdG8gMHgwMDAwMDAwMDAwMDBhYmNkLg0KKFhFTikgWzIwMTItMDktMDEgMjI6
Mjg6MzBdIHRyYXBzLmM6MjU4NDpkNiBEb21haW4gYXR0ZW1wdGVkIFdSTVNSIDAwMDAwMDAw
YzAwMTAwMDQgZnJvbSAweDAwMDBhMTk1YzQwZjYxOGYgdG8gMHgwMDAwMDAwMDAwMDBhYmNk
Lg0KKFhFTikgWzIwMTItMDktMDEgMjI6Mjg6MzZdIHRyYXBzLmM6MjU4NDpkNyBEb21haW4g
YXR0ZW1wdGVkIFdSTVNSIDAwMDAwMDAwYzAwMTAwMDQgZnJvbSAweDAwMDBhMTk1YzQwZjYx
OGYgdG8gMHgwMDAwMDAwMDAwMDBhYmNkLg0KKFhFTikgWzIwMTItMDktMDEgMjI6Mjg6NDJd
IHRyYXBzLmM6MjU4NDpkOCBEb21haW4gYXR0ZW1wdGVkIFdSTVNSIDAwMDAwMDAwYzAwMTAw
MDQgZnJvbSAweDAwMDA2ZmIwMzlkZTc5MDAgdG8gMHgwMDAwMDAwMDAwMDBhYmNkLg0KKFhF
TikgWzIwMTItMDktMDEgMjI6Mjg6NDhdIHRyYXBzLmM6MjU4NDpkOSBEb21haW4gYXR0ZW1w
dGVkIFdSTVNSIDAwMDAwMDAwYzAwMTAwMDQgZnJvbSAweDAwMDBhMTk1YzQwZjYxOGYgdG8g
MHgwMDAwMDAwMDAwMDBhYmNkLg0KKFhFTikgWzIwMTItMDktMDEgMjI6Mjg6NTVdIHRyYXBz
LmM6MjU4NDpkMTAgRG9tYWluIGF0dGVtcHRlZCBXUk1TUiAwMDAwMDAwMGMwMDEwMDA0IGZy
b20gMHgwMDAwNmZiMDM5ZGU3OTAwIHRvIDB4MDAwMDAwMDAwMDAwYWJjZC4NCihYRU4pIFsy
MDEyLTA5LTAxIDIyOjI5OjAyXSBBTUQtVmk6IERpc2FibGU6IGRldmljZSBpZCA9IDB4MDBh
NCwgZG9tYWluID0gMCwgcGFnaW5nIG1vZGUgPSAzDQooWEVOKSBbMjAxMi0wOS0wMSAyMjoy
OTowMl0gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHgwMGE0
LCByb290IHRhYmxlID0gMHgxOGUwYTEwMDAsIGRvbWFpbiA9IDExLCBwYWdpbmcgbW9kZSA9
IDMNCihYRU4pIFsyMDEyLTA5LTAxIDIyOjI5OjAyXSBBTUQtVmk6IFJlLWFzc2lnbiAwMDAw
OjAzOjA2LjAgZnJvbSBkb20wIHRvIGRvbTExDQooWEVOKSBbMjAxMi0wOS0wMSAyMjoyOTow
Ml0gdHJhcHMuYzoyNTg0OmQxMSBEb21haW4gYXR0ZW1wdGVkIFdSTVNSIDAwMDAwMDAwYzAw
MTAwMDQgZnJvbSAweDAwMDA4Njc5YzAyYjQxNjUgdG8gMHgwMDAwMDAwMDAwMDBhYmNkLg0K
KFhFTikgWzIwMTItMDktMDEgMjI6Mjk6MDhdIHRyYXBzLmM6MjU4NDpkMTIgRG9tYWluIGF0
dGVtcHRlZCBXUk1TUiAwMDAwMDAwMGMwMDEwMDA0IGZyb20gMHgwMDAwNDIzNDVhMGRhNTQ1
IHRvIDB4MDAwMDAwMDAwMDAwYWJjZC4NCihYRU4pIFsyMDEyLTA5LTAxIDIyOjI5OjE1XSB0
cmFwcy5jOjI1ODQ6ZDEzIERvbWFpbiBhdHRlbXB0ZWQgV1JNU1IgMDAwMDAwMDBjMDAxMDAw
NCBmcm9tIDB4MDAwMDZmYjAzOWRlNzkwMCB0byAweDAwMDAwMDAwMDAwMGFiY2QuDQooWEVO
KSBbMjAxMi0wOS0wMSAyMjoyOToyM10gQU1ELVZpOiBEaXNhYmxlOiBkZXZpY2UgaWQgPSAw
eDBhMDAsIGRvbWFpbiA9IDAsIHBhZ2luZyBtb2RlID0gMw0KKFhFTikgWzIwMTItMDktMDEg
MjI6Mjk6MjNdIEFNRC1WaTogU2V0dXAgSS9PIHBhZ2UgdGFibGU6IGRldmljZSBpZCA9IDB4
MGEwMCwgcm9vdCB0YWJsZSA9IDB4MWUxZmMwMDAwLCBkb21haW4gPSAxNCwgcGFnaW5nIG1v
ZGUgPSAzDQooWEVOKSBbMjAxMi0wOS0wMSAyMjoyOToyM10gQU1ELVZpOiBSZS1hc3NpZ24g
MDAwMDowYTowMC4wIGZyb20gZG9tMCB0byBkb20xNA0KKFhFTikgWzIwMTItMDktMDEgMjI6
Mjk6MjNdIEFNRC1WaTogRGlzYWJsZTogZGV2aWNlIGlkID0gMHgwYTAxLCBkb21haW4gPSAw
LCBwYWdpbmcgbW9kZSA9IDMNCihYRU4pIFsyMDEyLTA5LTAxIDIyOjI5OjIzXSBBTUQtVmk6
IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweDBhMDEsIHJvb3QgdGFibGUg
PSAweDFlMWZjMDAwMCwgZG9tYWluID0gMTQsIHBhZ2luZyBtb2RlID0gMw0KKFhFTikgWzIw
MTItMDktMDEgMjI6Mjk6MjNdIEFNRC1WaTogUmUtYXNzaWduIDAwMDA6MGE6MDAuMSBmcm9t
IGRvbTAgdG8gZG9tMTQNCihYRU4pIFsyMDEyLTA5LTAxIDIyOjI5OjIzXSBBTUQtVmk6IERp
c2FibGU6IGRldmljZSBpZCA9IDB4MGEwMiwgZG9tYWluID0gMCwgcGFnaW5nIG1vZGUgPSAz
DQooWEVOKSBbMjAxMi0wOS0wMSAyMjoyOToyM10gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0
YWJsZTogZGV2aWNlIGlkID0gMHgwYTAyLCByb290IHRhYmxlID0gMHgxZTFmYzAwMDAsIGRv
bWFpbiA9IDE0LCBwYWdpbmcgbW9kZSA9IDMNCihYRU4pIFsyMDEyLTA5LTAxIDIyOjI5OjIz
XSBBTUQtVmk6IFJlLWFzc2lnbiAwMDAwOjBhOjAwLjIgZnJvbSBkb20wIHRvIGRvbTE0DQoo
WEVOKSBbMjAxMi0wOS0wMSAyMjoyOToyM10gQU1ELVZpOiBEaXNhYmxlOiBkZXZpY2UgaWQg
PSAweDBhMDMsIGRvbWFpbiA9IDAsIHBhZ2luZyBtb2RlID0gMw0KKFhFTikgWzIwMTItMDkt
MDEgMjI6Mjk6MjNdIEFNRC1WaTogU2V0dXAgSS9PIHBhZ2UgdGFibGU6IGRldmljZSBpZCA9
IDB4MGEwMywgcm9vdCB0YWJsZSA9IDB4MWUxZmMwMDAwLCBkb21haW4gPSAxNCwgcGFnaW5n
IG1vZGUgPSAzDQooWEVOKSBbMjAxMi0wOS0wMSAyMjoyOToyM10gQU1ELVZpOiBSZS1hc3Np
Z24gMDAwMDowYTowMC4zIGZyb20gZG9tMCB0byBkb20xNA0KKFhFTikgWzIwMTItMDktMDEg
MjI6Mjk6MjNdIEFNRC1WaTogRGlzYWJsZTogZGV2aWNlIGlkID0gMHgwYTA0LCBkb21haW4g
PSAwLCBwYWdpbmcgbW9kZSA9IDMNCihYRU4pIFsyMDEyLTA5LTAxIDIyOjI5OjIzXSBBTUQt
Vmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweDBhMDQsIHJvb3QgdGFi
bGUgPSAweDFlMWZjMDAwMCwgZG9tYWluID0gMTQsIHBhZ2luZyBtb2RlID0gMw0KKFhFTikg
WzIwMTItMDktMDEgMjI6Mjk6MjNdIEFNRC1WaTogUmUtYXNzaWduIDAwMDA6MGE6MDAuNCBm
cm9tIGRvbTAgdG8gZG9tMTQNCihYRU4pIFsyMDEyLTA5LTAxIDIyOjI5OjIzXSBBTUQtVmk6
IERpc2FibGU6IGRldmljZSBpZCA9IDB4MGEwNSwgZG9tYWluID0gMCwgcGFnaW5nIG1vZGUg
PSAzDQooWEVOKSBbMjAxMi0wOS0wMSAyMjoyOToyM10gQU1ELVZpOiBTZXR1cCBJL08gcGFn
ZSB0YWJsZTogZGV2aWNlIGlkID0gMHgwYTA1LCByb290IHRhYmxlID0gMHgxZTFmYzAwMDAs
IGRvbWFpbiA9IDE0LCBwYWdpbmcgbW9kZSA9IDMNCihYRU4pIFsyMDEyLTA5LTAxIDIyOjI5
OjIzXSBBTUQtVmk6IFJlLWFzc2lnbiAwMDAwOjBhOjAwLjUgZnJvbSBkb20wIHRvIGRvbTE0
DQooWEVOKSBbMjAxMi0wOS0wMSAyMjoyOToyM10gQU1ELVZpOiBEaXNhYmxlOiBkZXZpY2Ug
aWQgPSAweDBhMDYsIGRvbWFpbiA9IDAsIHBhZ2luZyBtb2RlID0gMw0KKFhFTikgWzIwMTIt
MDktMDEgMjI6Mjk6MjNdIEFNRC1WaTogU2V0dXAgSS9PIHBhZ2UgdGFibGU6IGRldmljZSBp
ZCA9IDB4MGEwNiwgcm9vdCB0YWJsZSA9IDB4MWUxZmMwMDAwLCBkb21haW4gPSAxNCwgcGFn
aW5nIG1vZGUgPSAzDQooWEVOKSBbMjAxMi0wOS0wMSAyMjoyOToyM10gQU1ELVZpOiBSZS1h
c3NpZ24gMDAwMDowYTowMC42IGZyb20gZG9tMCB0byBkb20xNA0KKFhFTikgWzIwMTItMDkt
MDEgMjI6Mjk6MjNdIEFNRC1WaTogRGlzYWJsZTogZGV2aWNlIGlkID0gMHgwYTA3LCBkb21h
aW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMNCihYRU4pIFsyMDEyLTA5LTAxIDIyOjI5OjIzXSBB
TUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweDBhMDcsIHJvb3Qg
dGFibGUgPSAweDFlMWZjMDAwMCwgZG9tYWluID0gMTQsIHBhZ2luZyBtb2RlID0gMw0KKFhF
TikgWzIwMTItMDktMDEgMjI6Mjk6MjNdIEFNRC1WaTogUmUtYXNzaWduIDAwMDA6MGE6MDAu
NyBmcm9tIGRvbTAgdG8gZG9tMTQNCihYRU4pIFsyMDEyLTA5LTAxIDIyOjI5OjIzXSBBTUQt
Vmk6IERpc2FibGU6IGRldmljZSBpZCA9IDB4MDcwMCwgZG9tYWluID0gMCwgcGFnaW5nIG1v
ZGUgPSAzDQooWEVOKSBbMjAxMi0wOS0wMSAyMjoyOToyM10gQU1ELVZpOiBTZXR1cCBJL08g
cGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHgwNzAwLCByb290IHRhYmxlID0gMHgxZTFmYzAw
MDAsIGRvbWFpbiA9IDE0LCBwYWdpbmcgbW9kZSA9IDMNCihYRU4pIFsyMDEyLTA5LTAxIDIy
OjI5OjIzXSBBTUQtVmk6IFJlLWFzc2lnbiAwMDAwOjA3OjAwLjAgZnJvbSBkb20wIHRvIGRv
bTE0DQooWEVOKSBbMjAxMi0wOS0wMSAyMjoyOToyM10gdHJhcHMuYzoyNTg0OmQxNCBEb21h
aW4gYXR0ZW1wdGVkIFdSTVNSIDAwMDAwMDAwYzAwMTAwMDQgZnJvbSAweDAwMDA2ZmIwMzlk
ZTc5MDAgdG8gMHgwMDAwMDAwMDAwMDBhYmNkLg0KKFhFTikgWzIwMTItMDktMDEgMjI6Mjk6
MjldIHRyYXBzLmM6MjU4NDpkMTUgRG9tYWluIGF0dGVtcHRlZCBXUk1TUiAwMDAwMDAwMGMw
MDEwMDA0IGZyb20gMHgwMDAwNmZiMDM5ZGU3OTAwIHRvIDB4MDAwMDAwMDAwMDAwYWJjZC4N
CihYRU4pIFsyMDEyLTA5LTAxIDIzOjA1OjE5XSBncmFudF90YWJsZS5jOjI1NDpkMCBJbmNy
ZWFzZWQgbWFwdHJhY2sgc2l6ZSB0byAyIGZyYW1lcw0KKFhFTikgWzIwMTItMDktMDIgMDA6
MTg6MzZdIEFNRC1WaTogSU9fUEFHRV9GQVVMVDogZG9tYWluID0gMTQsIGRldmljZSBpZCA9
IDB4MDcwMCwgZmF1bHQgYWRkcmVzcyA9IDB4YThlZDA3ZTANCihYRU4pIFsyMDEyLTA5LTAy
IDAwOjE4OjM2XSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDE0LCBkZXZpY2Ug
aWQgPSAweDA3MDAsIGZhdWx0IGFkZHJlc3MgPSAweGE4ZWQwODAwDQooWEVOKSBbMjAxMi0w
OS0wMiAwMDoxODozNl0gQU1ELVZpOiBJT19QQUdFX0ZBVUxUOiBkb21haW4gPSAxNCwgZGV2
aWNlIGlkID0gMHgwNzAwLCBmYXVsdCBhZGRyZXNzID0gMHhhOGVkMDg0MA0KKFhFTikgWzIw
MTItMDktMDIgMDA6MTg6MzZdIEFNRC1WaTogSU9fUEFHRV9GQVVMVDogZG9tYWluID0gMTQs
IGRldmljZSBpZCA9IDB4MDcwMCwgZmF1bHQgYWRkcmVzcyA9IDB4YThlZDA4NjANCihYRU4p
IFsyMDEyLTA5LTAyIDAwOjE4OjM2XSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9
IDE0LCBkZXZpY2UgaWQgPSAweDA3MDAsIGZhdWx0IGFkZHJlc3MgPSAweGE4ZWQwOGMwDQoo
WEVOKSBbMjAxMi0wOS0wMiAwMDoxODozNl0gQU1ELVZpOiBJT19QQUdFX0ZBVUxUOiBkb21h
aW4gPSAxNCwgZGV2aWNlIGlkID0gMHgwNzAwLCBmYXVsdCBhZGRyZXNzID0gMHhhOGVkMDg4
MA0KKFhFTikgWzIwMTItMDktMDIgMDA6MTg6MzZdIEFNRC1WaTogSU9fUEFHRV9GQVVMVDog
ZG9tYWluID0gMTQsIGRldmljZSBpZCA9IDB4MDcwMCwgZmF1bHQgYWRkcmVzcyA9IDB4YThl
ZDBjMDANCihYRU4pIFsyMDEyLTA5LTAyIDAwOjE4OjM2XSBBTUQtVmk6IElPX1BBR0VfRkFV
TFQ6IGRvbWFpbiA9IDE0LCBkZXZpY2UgaWQgPSAweDA3MDAsIGZhdWx0IGFkZHJlc3MgPSAw
eGE4ZWQwYjYwDQooWEVOKSBbMjAxMi0wOS0wMiAwMDoxODozNl0gQU1ELVZpOiBJT19QQUdF
X0ZBVUxUOiBkb21haW4gPSAxNCwgZGV2aWNlIGlkID0gMHgwNzAwLCBmYXVsdCBhZGRyZXNz
ID0gMHhhOGVkMGEwMA0KKFhFTikgWzIwMTItMDktMDIgMDA6MTg6MzZdIEFNRC1WaTogSU9f
UEFHRV9GQVVMVDogZG9tYWluID0gMTQsIGRldmljZSBpZCA9IDB4MDcwMCwgZmF1bHQgYWRk
cmVzcyA9IDB4YThlZDBjNjANCihYRU4pIFsyMDEyLTA5LTAyIDAwOjE4OjM2XSBBTUQtVmk6
IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDE0LCBkZXZpY2UgaWQgPSAweDA3MDAsIGZhdWx0
IGFkZHJlc3MgPSAweGE4ZWQwYTQwDQooWEVOKSBbMjAxMi0wOS0wMiAwMDoxODozNl0gQU1E
LVZpOiBJT19QQUdFX0ZBVUxUOiBkb21haW4gPSAxNCwgZGV2aWNlIGlkID0gMHgwNzAwLCBm
YXVsdCBhZGRyZXNzID0gMHhhOGVkMGM4MA0KKFhFTikgWzIwMTItMDktMDIgMDA6MTg6MzZd
IEFNRC1WaTogSU9fUEFHRV9GQVVMVDogZG9tYWluID0gMTQsIGRldmljZSBpZCA9IDB4MDcw
MCwgZmF1bHQgYWRkcmVzcyA9IDB4YThlZDA4ZTANCihYRU4pIFsyMDEyLTA5LTAyIDAwOjE4
OjM2XSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDE0LCBkZXZpY2UgaWQgPSAw
eDA3MDAsIGZhdWx0IGFkZHJlc3MgPSAweGE4ZWQwYjgwDQooWEVOKSBbMjAxMi0wOS0wMiAw
MDoxODozNl0gQU1ELVZpOiBJT19QQUdFX0ZBVUxUOiBkb21haW4gPSAxNCwgZGV2aWNlIGlk
ID0gMHgwNzAwLCBmYXVsdCBhZGRyZXNzID0gMHhhOGVkMGE2MA0KKFhFTikgWzIwMTItMDkt
MDIgMDA6MTg6MzZdIEFNRC1WaTogSU9fUEFHRV9GQVVMVDogZG9tYWluID0gMTQsIGRldmlj
ZSBpZCA9IDB4MDcwMCwgZmF1bHQgYWRkcmVzcyA9IDB4YThlZDBiYzANCihYRU4pIFsyMDEy
LTA5LTAyIDAwOjE4OjM2XSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDE0LCBk
ZXZpY2UgaWQgPSAweDA3MDAsIGZhdWx0IGFkZHJlc3MgPSAweGE4ZWQwYmUwDQooWEVOKSBb
MjAxMi0wOS0wMiAwMDoxODozNl0gQU1ELVZpOiBJT19QQUdFX0ZBVUxUOiBkb21haW4gPSAx
NCwgZGV2aWNlIGlkID0gMHgwNzAwLCBmYXVsdCBhZGRyZXNzID0gMHhhOGVkMGE4MA0KKFhF
TikgWzIwMTItMDktMDIgMDA6MTg6MzZdIEFNRC1WaTogSU9fUEFHRV9GQVVMVDogZG9tYWlu
ID0gMTQsIGRldmljZSBpZCA9IDB4MDcwMCwgZmF1bHQgYWRkcmVzcyA9IDB4YThlZDBjNDAN
CihYRU4pIFsyMDEyLTA5LTAyIDAwOjE4OjM2XSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRv
bWFpbiA9IDE0LCBkZXZpY2UgaWQgPSAweDA3MDAsIGZhdWx0IGFkZHJlc3MgPSAweGE4ZWQw
YWUwDQooWEVOKSBbMjAxMi0wOS0wMiAwMDoxODozNl0gQU1ELVZpOiBJT19QQUdFX0ZBVUxU
OiBkb21haW4gPSAxNCwgZGV2aWNlIGlkID0gMHgwNzAwLCBmYXVsdCBhZGRyZXNzID0gMHhh
OGVkMDllMA0KKFhFTikgWzIwMTItMDktMDIgMDA6MTg6MzZdIEFNRC1WaTogSU9fUEFHRV9G
QVVMVDogZG9tYWluID0gMTQsIGRldmljZSBpZCA9IDB4MDcwMCwgZmF1bHQgYWRkcmVzcyA9
IDB4YThlZDA5ODANCihYRU4pIFsyMDEyLTA5LTAyIDAwOjE4OjM2XSBBTUQtVmk6IElPX1BB
R0VfRkFVTFQ6IGRvbWFpbiA9IDE0LCBkZXZpY2UgaWQgPSAweDA3MDAsIGZhdWx0IGFkZHJl
c3MgPSAweGE4ZWQwOWMwDQooWEVOKSBbMjAxMi0wOS0wMiAwMDoxODozNl0gQU1ELVZpOiBJ
T19QQUdFX0ZBVUxUOiBkb21haW4gPSAxNCwgZGV2aWNlIGlkID0gMHgwNzAwLCBmYXVsdCBh
ZGRyZXNzID0gMHhhOGVkMGI0MA0KKFhFTikgWzIwMTItMDktMDIgMDA6MTg6MzZdIEFNRC1W
aTogSU9fUEFHRV9GQVVMVDogZG9tYWluID0gMTQsIGRldmljZSBpZCA9IDB4MDcwMCwgZmF1
bHQgYWRkcmVzcyA9IDB4YThlZDBiMDANCihYRU4pIFsyMDEyLTA5LTAyIDAwOjE4OjM2XSBB
TUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDE0LCBkZXZpY2UgaWQgPSAweDA3MDAs
IGZhdWx0IGFkZHJlc3MgPSAweGE4ZWQwY2MwDQooWEVOKSBbMjAxMi0wOS0wMiAwMDoxODoz
Nl0gQU1ELVZpOiBJT19QQUdFX0ZBVUxUOiBkb21haW4gPSAxNCwgZGV2aWNlIGlkID0gMHgw
NzAwLCBmYXVsdCBhZGRyZXNzID0gMHhhOGVkMDk0MA0KKFhFTikgWzIwMTItMDktMDIgMDA6
MTg6MzZdIEFNRC1WaTogSU9fUEFHRV9GQVVMVDogZG9tYWluID0gMTQsIGRldmljZSBpZCA9
IDB4MDcwMCwgZmF1bHQgYWRkcmVzcyA9IDB4YThlZDBhYzANCihYRU4pIFsyMDEyLTA5LTAy
IDAwOjE4OjM2XSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDE0LCBkZXZpY2Ug
aWQgPSAweDA3MDAsIGZhdWx0IGFkZHJlc3MgPSAweGE4ZWQwOTAwDQooWEVOKSBbMjAxMi0w
OS0wMiAwMDoxODozNl0gQU1ELVZpOiBJT19QQUdFX0ZBVUxUOiBkb21haW4gPSAxNCwgZGV2
aWNlIGlkID0gMHgwNzAwLCBmYXVsdCBhZGRyZXNzID0gMHhhOGVkMDk2MA0KKFhFTikgWzIw
MTItMDktMDIgMDA6MTg6MzZdIEFNRC1WaTogSU9fUEFHRV9GQVVMVDogZG9tYWluID0gMTQs
IGRldmljZSBpZCA9IDB4MDcwMCwgZmF1bHQgYWRkcmVzcyA9IDB4YThlZDBjZTANCihYRU4p
IFsyMDEyLTA5LTAyIDAwOjE4OjM2XSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9
IDE0LCBkZXZpY2UgaWQgPSAweDA3MDAsIGZhdWx0IGFkZHJlc3MgPSAweGE4ZWQwZDQwDQoo
WEVOKSBbMjAxMi0wOS0wMiAwMDoxODozNl0gQU1ELVZpOiBJT19QQUdFX0ZBVUxUOiBkb21h
aW4gPSAxNCwgZGV2aWNlIGlkID0gMHgwNzAwLCBmYXVsdCBhZGRyZXNzID0gMHhhOGVkMGQw
MA0KKFhFTikgWzIwMTItMDktMDIgMDA6MTg6MzZdIEFNRC1WaTogSU9fUEFHRV9GQVVMVDog
ZG9tYWluID0gMTQsIGRldmljZSBpZCA9IDB4MDcwMCwgZmF1bHQgYWRkcmVzcyA9IDB4YThl
ZDBkNjANCihYRU4pIFsyMDEyLTA5LTAyIDAwOjU1OjAyXSB0cmFwcy5jOjMxNTY6IEdQRiAo
MDA2MCk6IGZmZmY4MmM0ODAxNWM5ZWUgLT4gZmZmZjgyYzQ4MDIyNGIxMw0KKFhFTikgWzIw
MTItMDktMDIgMDQ6MjE6MjNdIEFNRC1WaTogSU9fUEFHRV9GQVVMVDogZG9tYWluID0gMTQs
IGRldmljZSBpZCA9IDB4MGEwNiwgZmF1bHQgYWRkcmVzcyA9IDB4YTliMGYwODANCihYRU4p
IFsyMDEyLTA5LTAyIDA0OjIxOjIzXSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9
IDE0LCBkZXZpY2UgaWQgPSAweDBhMDYsIGZhdWx0IGFkZHJlc3MgPSAweGE5YjBmMDQwDQo=
------------03516D00221173D65
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

------------03516D00221173D65--



From xen-devel-bounces@lists.xen.org Sun Sep 02 08:44:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 02 Sep 2012 08:44:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T85mO-0006p5-AR; Sun, 02 Sep 2012 08:43:40 +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 1T85mM-0006p0-Ub
	for xen-devel@lists.xen.org; Sun, 02 Sep 2012 08:43:39 +0000
Received: from [85.158.143.99:38251] by server-2.bemta-4.messagelabs.com id
	AC/DC-21239-A3C13405; Sun, 02 Sep 2012 08:43:38 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-11.tower-216.messagelabs.com!1346575414!20525918!1
X-Originating-IP: [188.40.164.121]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13618 invoked from network); 2 Sep 2012 08:43:34 -0000
Received: from static.121.164.40.188.clients.your-server.de (HELO
	smtp.eikelenboom.it) (188.40.164.121)
	by server-11.tower-216.messagelabs.com with AES256-SHA encrypted SMTP;
	2 Sep 2012 08:43:34 -0000
Received: from 26-69-ftth.onsneteindhoven.nl ([88.159.69.26]:49677
	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 1T85jC-00006N-KF; Sun, 02 Sep 2012 10:40:22 +0200
Date: Sun, 2 Sep 2012 10:43:31 +0200
From: Sander Eikelenboom <linux@eikelenboom.it>
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <40501859.20120902104331@eikelenboom.it>
To: Keir Fraser <keir.xen@gmail.com>
In-Reply-To: <CC681CDD.3D966%keir.xen@gmail.com>
References: <7914B38A4445B34AA16EB9F1352942F1012F0F6F4B98@SJCPMAILBOX01.citrite.net>
	<CC681CDD.3D966%keir.xen@gmail.com>
MIME-Version: 1.0
Content-Type: multipart/mixed;
 boundary="----------03516D00221173D65"
Cc: "wei.wang2@amd.com" <wei.wang2@amd.com>,
	Santosh Jodh <Santosh.Jodh@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Using debug-key 'o:  Dump IOMMU p2m table,
	locks up machine
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

------------03516D00221173D65
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit


Saturday, September 1, 2012, 9:13:17 PM, you wrote:

> On 01/09/2012 18:03, "Santosh Jodh" <Santosh.Jodh@citrix.com> wrote:

>>> It might schedule softirqs but that won't include scheduling or running any
>>> guest vcpus. The vcpu that happens to be running on that cpu at the time the
>>> debug dump starts, will be stuck unrunnable until the dump completes.
>> 
>> Why does'nt that vCPU get scheduled on some other pCPU? Is there  a way to
>> yield the CPU from the key handler?

> It can't be descheduled from this pCPU without running through the
> scheduler. You could try running the handler in a tasklet -- a tasklet
> causes other vCPUs to be descheduled from that pCPU, before it starts
> running.

> So you'd register a keyhandler which does a tasklet_schedule(), and do your
> logging work in the tasklet handler.

> Worth a shot maybe?

>>> 
>>> Well, anyway, I don't know how useful a massive dump of the entire p2m is
>>> going to be for debugging anyway. If investigating an IOMMU page fault, I'd
>>> just want the info pertaining to that fault, and all the mapping information
>>> for
>>> that IO virtual address, dumped. :)
>> 
>> It is not a generically useful command - its usefulness is in the same
>> category as dumping the MMU table. Unfortunately, there is no way to pass
>> arguments to the key handler - to say provide the VM and or starting gfn and
>> length for a more selective output.

> Quite simply, there likely needs to be more tracing on the IOMMU fault path.
> That's a separate concern from your keyhandler of course, but just saying
> I'd be looking for the former rather than the latter, for diagnosing
> Sander's bug.

Are there any printk's I could add to get more relevant info about the AMD-Vi: IO_PAGE_FAULT ?

I have attached new output from xl dmesg, this time with iommu=debug on (the option changed from 4.1 to 4.2).



>  -- Keir


------------03516D00221173D65
Content-Type: text/plain;
 name="xl-dmesg.txt"
Content-transfer-encoding: base64
Content-Disposition: attachment;
 filename="xl-dmesg.txt"

IF9fICBfXyAgICAgICAgICAgIF8gIF8gICAgX19fXyAgICBfX18gICAgICAgICAgICAgIF8g
IF8gICAgICAgICAgICAgICAgICAgICANCiBcIFwvIC9fX18gXyBfXyAgIHwgfHwgfCAgfF9f
XyBcICAvIF8gXCAgICBfIF9fIF9fX3wgfHwgfCAgICAgXyBfXyAgXyBfXyBfX18gDQogIFwg
IC8vIF8gXCAnXyBcICB8IHx8IHxfICAgX18pIHx8IHwgfCB8X198ICdfXy8gX198IHx8IHxf
IF9ffCAnXyBcfCAnX18vIF8gXA0KICAvICBcICBfXy8gfCB8IHwgfF9fICAgX3wgLyBfXy8g
fCB8X3wgfF9ffCB8IHwgKF9ffF9fICAgX3xfX3wgfF8pIHwgfCB8ICBfXy8NCiAvXy9cX1xf
X198X3wgfF98ICAgIHxffChfKV9fX19fKF8pX19fLyAgIHxffCAgXF9fX3wgIHxffCAgICB8
IC5fXy98X3wgIFxfX198DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgfF98ICAgICAgICAgICAgIA0KKFhFTikgWGVuIHZl
cnNpb24gNC4yLjAtcmM0LXByZSAocm9vdEBkeW5kbnMub3JnKSAoZ2NjIChEZWJpYW4gNC40
LjUtOCkgNC40LjUpIFRodSBBdWcgMzAgMjM6NTg6MDMgQ0VTVCAyMDEyDQooWEVOKSBMYXRl
c3QgQ2hhbmdlU2V0OiBUdWUgQXVnIDI4IDIyOjQwOjQ1IDIwMTIgKzAxMDAgMjU3ODY6YTBi
NWY4MTAyYTAwDQooWEVOKSBCb290bG9hZGVyOiBHUlVCIDEuOTgrMjAxMDA4MDQtMTQrc3F1
ZWV6ZTENCihYRU4pIENvbW1hbmQgbGluZTogZG9tMF9tZW09MTAyNE0gbG9nbHZsPWFsbCBs
b2dsdmxfZ3Vlc3Q9YWxsIGNvbnNvbGVfdGltZXN0YW1wcyB2Z2E9Z2Z4LTEyODB4MTAyNHgz
MiBjcHVpZGxlIGNwdWZyZXE9eGVuIG5vcmVib290IGRlYnVnIGxhcGljPWRlYnVnIGFwaWNf
dmVyYm9zaXR5PWRlYnVnIGFwaWM9ZGVidWcgaW9tbXU9b24sdmVyYm9zZSxkZWJ1ZyBjb20x
PTM4NDAwLDhuMSBjb25zb2xlPXZnYSxjb20xDQooWEVOKSBWaWRlbyBpbmZvcm1hdGlvbjoN
CihYRU4pICBWR0EgaXMgZ3JhcGhpY3MgbW9kZSAxMjgweDEwMjQsIDMyIGJwcA0KKFhFTikg
IFZCRS9EREMgbWV0aG9kczogVjI7IEVESUQgdHJhbnNmZXIgdGltZTogMSBzZWNvbmRzDQoo
WEVOKSBEaXNjIGluZm9ybWF0aW9uOg0KKFhFTikgIEZvdW5kIDIgTUJSIHNpZ25hdHVyZXMN
CihYRU4pICBGb3VuZCAyIEVERCBpbmZvcm1hdGlvbiBzdHJ1Y3R1cmVzDQooWEVOKSBYZW4t
ZTgyMCBSQU0gbWFwOg0KKFhFTikgIDAwMDAwMDAwMDAwMDAwMDAgLSAwMDAwMDAwMDAwMDli
MDAwICh1c2FibGUpDQooWEVOKSAgMDAwMDAwMDAwMDA5YjAwMCAtIDAwMDAwMDAwMDAwYTAw
MDAgKHJlc2VydmVkKQ0KKFhFTikgIDAwMDAwMDAwMDAwZTQwMDAgLSAwMDAwMDAwMDAwMTAw
MDAwIChyZXNlcnZlZCkNCihYRU4pICAwMDAwMDAwMDAwMTAwMDAwIC0gMDAwMDAwMDBhZmU5
MDAwMCAodXNhYmxlKQ0KKFhFTikgIDAwMDAwMDAwYWZlOTAwMDAgLSAwMDAwMDAwMGFmZTll
MDAwIChBQ1BJIGRhdGEpDQooWEVOKSAgMDAwMDAwMDBhZmU5ZTAwMCAtIDAwMDAwMDAwYWZl
ZTAwMDAgKEFDUEkgTlZTKQ0KKFhFTikgIDAwMDAwMDAwYWZlZTAwMDAgLSAwMDAwMDAwMGFm
ZjAwMDAwIChyZXNlcnZlZCkNCihYRU4pICAwMDAwMDAwMGZmZTAwMDAwIC0gMDAwMDAwMDEw
MDAwMDAwMCAocmVzZXJ2ZWQpDQooWEVOKSAgMDAwMDAwMDEwMDAwMDAwMCAtIDAwMDAwMDAy
NTAwMDAwMDAgKHVzYWJsZSkNCihYRU4pIEFDUEk6IFJTRFAgMDAwRkIxMjAsIDAwMTQgKHIw
IEFDUElBTSkNCihYRU4pIEFDUEk6IFJTRFQgQUZFOTAwMDAsIDAwNDggKHIxIE1TSSAgICBP
RU1TTElDICAyMDEwMDYyMiBNU0ZUICAgICAgIDk3KQ0KKFhFTikgQUNQSTogRkFDUCBBRkU5
MDIwMCwgMDA4NCAocjEgNzY0ME1TIEE3NjQwMTAwIDIwMTAwNjIyIE1TRlQgICAgICAgOTcp
DQooWEVOKSBBQ1BJOiBEU0RUIEFGRTkwNUUwLCA5NDQ5IChyMSAgQTc2NDAgQTc2NDAxMDAg
ICAgICAxMDAgSU5UTCAyMDA1MTExNykNCihYRU4pIEFDUEk6IEZBQ1MgQUZFOUUwMDAsIDAw
NDANCihYRU4pIEFDUEk6IEFQSUMgQUZFOTAzOTAsIDAwODggKHIxIDc2NDBNUyBBNzY0MDEw
MCAyMDEwMDYyMiBNU0ZUICAgICAgIDk3KQ0KKFhFTikgQUNQSTogTUNGRyBBRkU5MDQyMCwg
MDAzQyAocjEgNzY0ME1TIE9FTU1DRkcgIDIwMTAwNjIyIE1TRlQgICAgICAgOTcpDQooWEVO
KSBBQ1BJOiBTTElDIEFGRTkwNDYwLCAwMTc2IChyMSBNU0kgICAgT0VNU0xJQyAgMjAxMDA2
MjIgTVNGVCAgICAgICA5NykNCihYRU4pIEFDUEk6IE9FTUIgQUZFOUUwNDAsIDAwNzIgKHIx
IDc2NDBNUyBBNzY0MDEwMCAyMDEwMDYyMiBNU0ZUICAgICAgIDk3KQ0KKFhFTikgQUNQSTog
U1JBVCBBRkU5QTVFMCwgMDEwOCAocjMgQU1EICAgIEZBTV9GXzEwICAgICAgICAyIEFNRCAg
ICAgICAgIDEpDQooWEVOKSBBQ1BJOiBIUEVUIEFGRTlBNkYwLCAwMDM4IChyMSA3NjQwTVMg
T0VNSFBFVCAgMjAxMDA2MjIgTVNGVCAgICAgICA5NykNCihYRU4pIEFDUEk6IElWUlMgQUZF
OUE3MzAsIDAwRjggKHIxICBBTUQgICAgIFJEODkwUyAgIDIwMjAzMSBBTUQgICAgICAgICAw
KQ0KKFhFTikgQUNQSTogU1NEVCBBRkU5QTgzMCwgMERBNCAocjEgQSBNIEkgIFBPV0VSTk9X
ICAgICAgICAxIEFNRCAgICAgICAgIDEpDQooWEVOKSBTeXN0ZW0gUkFNOiA4MTkwTUIgKDgz
ODY3MzJrQikNCihYRU4pIFNSQVQ6IFBYTSAwIC0+IEFQSUMgMCAtPiBOb2RlIDANCihYRU4p
IFNSQVQ6IFBYTSAwIC0+IEFQSUMgMSAtPiBOb2RlIDANCihYRU4pIFNSQVQ6IFBYTSAwIC0+
IEFQSUMgMiAtPiBOb2RlIDANCihYRU4pIFNSQVQ6IFBYTSAwIC0+IEFQSUMgMyAtPiBOb2Rl
IDANCihYRU4pIFNSQVQ6IFBYTSAwIC0+IEFQSUMgNCAtPiBOb2RlIDANCihYRU4pIFNSQVQ6
IFBYTSAwIC0+IEFQSUMgNSAtPiBOb2RlIDANCihYRU4pIFNSQVQ6IE5vZGUgMCBQWE0gMCAw
LWEwMDAwDQooWEVOKSBTUkFUOiBOb2RlIDAgUFhNIDAgMTAwMDAwLWIwMDAwMDAwDQooWEVO
KSBTUkFUOiBOb2RlIDAgUFhNIDAgMTAwMDAwMDAwLTI1MDAwMDAwMA0KKFhFTikgTlVNQTog
QWxsb2NhdGVkIG1lbW5vZGVtYXAgZnJvbSAyNGRiYWMwMDAgLSAyNGRiYWYwMDANCihYRU4p
IE5VTUE6IFVzaW5nIDggZm9yIHRoZSBoYXNoIHNoaWZ0Lg0KKFhFTikgRG9tYWluIGhlYXAg
aW5pdGlhbGlzZWQNCihYRU4pIHZlc2FmYjogZnJhbWVidWZmZXIgYXQgMHhmYjAwMDAwMCwg
bWFwcGVkIHRvIDB4ZmZmZjgyYzAwMDAwMDAwMCwgdXNpbmcgNjE0NGssIHRvdGFsIDE0MzM2
aw0KKFhFTikgdmVzYWZiOiBtb2RlIGlzIDEyODB4MTAyNHgzMiwgbGluZWxlbmd0aD01MTIw
LCBmb250IDh4MTYNCihYRU4pIHZlc2FmYjogVHJ1ZWNvbG9yOiBzaXplPTg6ODo4OjgsIHNo
aWZ0PTI0OjE2Ojg6MA0KKFhFTikgZm91bmQgU01QIE1QLXRhYmxlIGF0IDAwMGZmNzgwDQoo
WEVOKSBETUkgcHJlc2VudC4NCihYRU4pIEFQSUMgYm9vdCBzdGF0ZSBpcyAneGFwaWMnDQoo
WEVOKSBVc2luZyBBUElDIGRyaXZlciBkZWZhdWx0DQooWEVOKSBBQ1BJOiBQTS1UaW1lciBJ
TyBQb3J0OiAweDgwOA0KKFhFTikgQUNQSTogQUNQSSBTTEVFUCBJTkZPOiBwbTF4X2NudFs4
MDQsMF0sIHBtMXhfZXZ0WzgwMCwwXQ0KKFhFTikgQUNQSTogICAgICAgICAgICAgICAgICB3
YWtldXBfdmVjW2FmZTllMDBjXSwgdmVjX3NpemVbMjBdDQooWEVOKSBBQ1BJOiBMb2NhbCBB
UElDIGFkZHJlc3MgMHhmZWUwMDAwMA0KKFhFTikgQUNQSTogTEFQSUMgKGFjcGlfaWRbMHgw
MV0gbGFwaWNfaWRbMHgwMF0gZW5hYmxlZCkNCihYRU4pIFByb2Nlc3NvciAjMCAwOjEwIEFQ
SUMgdmVyc2lvbiAxNg0KKFhFTikgQUNQSTogTEFQSUMgKGFjcGlfaWRbMHgwMl0gbGFwaWNf
aWRbMHgwMV0gZW5hYmxlZCkNCihYRU4pIFByb2Nlc3NvciAjMSAwOjEwIEFQSUMgdmVyc2lv
biAxNg0KKFhFTikgQUNQSTogTEFQSUMgKGFjcGlfaWRbMHgwM10gbGFwaWNfaWRbMHgwMl0g
ZW5hYmxlZCkNCihYRU4pIFByb2Nlc3NvciAjMiAwOjEwIEFQSUMgdmVyc2lvbiAxNg0KKFhF
TikgQUNQSTogTEFQSUMgKGFjcGlfaWRbMHgwNF0gbGFwaWNfaWRbMHgwM10gZW5hYmxlZCkN
CihYRU4pIFByb2Nlc3NvciAjMyAwOjEwIEFQSUMgdmVyc2lvbiAxNg0KKFhFTikgQUNQSTog
TEFQSUMgKGFjcGlfaWRbMHgwNV0gbGFwaWNfaWRbMHgwNF0gZW5hYmxlZCkNCihYRU4pIFBy
b2Nlc3NvciAjNCAwOjEwIEFQSUMgdmVyc2lvbiAxNg0KKFhFTikgQUNQSTogTEFQSUMgKGFj
cGlfaWRbMHgwNl0gbGFwaWNfaWRbMHgwNV0gZW5hYmxlZCkNCihYRU4pIFByb2Nlc3NvciAj
NSAwOjEwIEFQSUMgdmVyc2lvbiAxNg0KKFhFTikgQUNQSTogSU9BUElDIChpZFsweDA2XSBh
ZGRyZXNzWzB4ZmVjMDAwMDBdIGdzaV9iYXNlWzBdKQ0KKFhFTikgSU9BUElDWzBdOiBhcGlj
X2lkIDYsIHZlcnNpb24gMzMsIGFkZHJlc3MgMHhmZWMwMDAwMCwgR1NJIDAtMjMNCihYRU4p
IEFDUEk6IElPQVBJQyAoaWRbMHgwN10gYWRkcmVzc1sweGZlYzIwMDAwXSBnc2lfYmFzZVsy
NF0pDQooWEVOKSBJT0FQSUNbMV06IGFwaWNfaWQgNywgdmVyc2lvbiAzMywgYWRkcmVzcyAw
eGZlYzIwMDAwLCBHU0kgMjQtNTUNCihYRU4pIEFDUEk6IElOVF9TUkNfT1ZSIChidXMgMCBi
dXNfaXJxIDAgZ2xvYmFsX2lycSAyIGRmbCBkZmwpDQooWEVOKSBBQ1BJOiBJTlRfU1JDX09W
UiAoYnVzIDAgYnVzX2lycSA5IGdsb2JhbF9pcnEgOSBsb3cgbGV2ZWwpDQooWEVOKSBBQ1BJ
OiBJUlEwIHVzZWQgYnkgb3ZlcnJpZGUuDQooWEVOKSBBQ1BJOiBJUlEyIHVzZWQgYnkgb3Zl
cnJpZGUuDQooWEVOKSBBQ1BJOiBJUlE5IHVzZWQgYnkgb3ZlcnJpZGUuDQooWEVOKSBFbmFi
bGluZyBBUElDIG1vZGU6ICBGbGF0LiAgVXNpbmcgMiBJL08gQVBJQ3MNCihYRU4pIEFDUEk6
IEhQRVQgaWQ6IDB4ODMwMCBiYXNlOiAweGZlZDAwMDAwDQooWEVOKSBUYWJsZSBpcyBub3Qg
Zm91bmQhDQooWEVOKSBVc2luZyBBQ1BJIChNQURUKSBmb3IgU01QIGNvbmZpZ3VyYXRpb24g
aW5mb3JtYXRpb24NCihYRU4pIFNNUDogQWxsb3dpbmcgNiBDUFVzICgwIGhvdHBsdWcgQ1BV
cykNCihYRU4pIG1hcHBlZCBBUElDIHRvIGZmZmY4MmMzZmZkZmUwMDAgKGZlZTAwMDAwKQ0K
KFhFTikgbWFwcGVkIElPQVBJQyB0byBmZmZmODJjM2ZmZGZkMDAwIChmZWMwMDAwMCkNCihY
RU4pIG1hcHBlZCBJT0FQSUMgdG8gZmZmZjgyYzNmZmRmYzAwMCAoZmVjMjAwMDApDQooWEVO
KSBJUlEgbGltaXRzOiA1NiBHU0ksIDExMTIgTVNJL01TSS1YDQooWEVOKSBVc2luZyBzY2hl
ZHVsZXI6IFNNUCBDcmVkaXQgU2NoZWR1bGVyIChjcmVkaXQpDQooWEVOKSBEZXRlY3RlZCAz
MjAwLjIyNCBNSHogcHJvY2Vzc29yLg0KKFhFTikgSW5pdGluZyBtZW1vcnkgc2hhcmluZy4N
CihYRU4pIEFNRCBGYW0xMGggbWFjaGluZSBjaGVjayByZXBvcnRpbmcgZW5hYmxlZA0KKFhF
TikgUENJOiBNQ0ZHIGNvbmZpZ3VyYXRpb24gMDogYmFzZSBlMDAwMDAwMCBzZWdtZW50IDAw
MDAgYnVzZXMgMDAgLSBmZg0KKFhFTikgUENJOiBOb3QgdXNpbmcgTUNGRyBmb3Igc2VnbWVu
dCAwMDAwIGJ1cyAwMC1mZg0KKFhFTikgQU1ELVZpOiBGb3VuZCBNU0kgY2FwYWJpbGl0eSBi
bG9jayBhdCAweDU0DQooWEVOKSBBTUQtVmk6IEFDUEkgVGFibGU6DQooWEVOKSBBTUQtVmk6
ICBTaWduYXR1cmUgSVZSUw0KKFhFTikgQU1ELVZpOiAgTGVuZ3RoIDB4ZjgNCihYRU4pIEFN
RC1WaTogIFJldmlzaW9uIDB4MQ0KKFhFTikgQU1ELVZpOiAgQ2hlY2tTdW0gMHg2ZQ0KKFhF
TikgQU1ELVZpOiAgT0VNX0lkIEFNRCAgDQooWEVOKSBBTUQtVmk6ICBPRU1fVGFibGVfSWQg
UkQ4OTBTDQooWEVOKSBBTUQtVmk6ICBPRU1fUmV2aXNpb24gMHgyMDIwMzENCihYRU4pIEFN
RC1WaTogIENyZWF0b3JfSWQgQU1EIA0KKFhFTikgQU1ELVZpOiAgQ3JlYXRvcl9SZXZpc2lv
biAweDANCihYRU4pIEFNRC1WaTogSVZSUyBCbG9jazoNCihYRU4pIEFNRC1WaTogIFR5cGUg
MHgxMA0KKFhFTikgQU1ELVZpOiAgRmxhZ3MgMHgzZQ0KKFhFTikgQU1ELVZpOiAgTGVuZ3Ro
IDB4YzgNCihYRU4pIEFNRC1WaTogIERldl9JZCAweDINCihYRU4pIEFNRC1WaTogSVZIRCBE
ZXZpY2UgRW50cnk6DQooWEVOKSBBTUQtVmk6ICBUeXBlIDB4Mw0KKFhFTikgQU1ELVZpOiAg
RGV2X0lkIDB4MA0KKFhFTikgQU1ELVZpOiAgRmxhZ3MgMHgwDQooWEVOKSBBTUQtVmk6ICBE
ZXZfSWQgUmFuZ2U6IDB4MCAtPiAweDINCihYRU4pIEFNRC1WaTogSVZIRCBEZXZpY2UgRW50
cnk6DQooWEVOKSBBTUQtVmk6ICBUeXBlIDB4Mg0KKFhFTikgQU1ELVZpOiAgRGV2X0lkIDB4
MTANCihYRU4pIEFNRC1WaTogIEZsYWdzIDB4MA0KKFhFTikgQU1ELVZpOiBJVkhEIERldmlj
ZSBFbnRyeToNCihYRU4pIEFNRC1WaTogIFR5cGUgMHgyDQooWEVOKSBBTUQtVmk6ICBEZXZf
SWQgMHhiMDANCihYRU4pIEFNRC1WaTogIEZsYWdzIDB4MA0KKFhFTikgQU1ELVZpOiBJVkhE
IERldmljZSBFbnRyeToNCihYRU4pIEFNRC1WaTogIFR5cGUgMHgyDQooWEVOKSBBTUQtVmk6
ICBEZXZfSWQgMHgxOA0KKFhFTikgQU1ELVZpOiAgRmxhZ3MgMHgwDQooWEVOKSBBTUQtVmk6
IElWSEQgRGV2aWNlIEVudHJ5Og0KKFhFTikgQU1ELVZpOiAgVHlwZSAweDMNCihYRU4pIEFN
RC1WaTogIERldl9JZCAweGEwMA0KKFhFTikgQU1ELVZpOiAgRmxhZ3MgMHgwDQooWEVOKSBB
TUQtVmk6ICBEZXZfSWQgUmFuZ2U6IDB4YTAwIC0+IDB4YTA3DQooWEVOKSBBTUQtVmk6IElW
SEQgRGV2aWNlIEVudHJ5Og0KKFhFTikgQU1ELVZpOiAgVHlwZSAweDINCihYRU4pIEFNRC1W
aTogIERldl9JZCAweDI4DQooWEVOKSBBTUQtVmk6ICBGbGFncyAweDANCihYRU4pIEFNRC1W
aTogSVZIRCBEZXZpY2UgRW50cnk6DQooWEVOKSBBTUQtVmk6ICBUeXBlIDB4Mg0KKFhFTikg
QU1ELVZpOiAgRGV2X0lkIDB4OTAwDQooWEVOKSBBTUQtVmk6ICBGbGFncyAweDANCihYRU4p
IEFNRC1WaTogSVZIRCBEZXZpY2UgRW50cnk6DQooWEVOKSBBTUQtVmk6ICBUeXBlIDB4Mg0K
KFhFTikgQU1ELVZpOiAgRGV2X0lkIDB4MzANCihYRU4pIEFNRC1WaTogIEZsYWdzIDB4MA0K
KFhFTikgQU1ELVZpOiBJVkhEIERldmljZSBFbnRyeToNCihYRU4pIEFNRC1WaTogIFR5cGUg
MHgyDQooWEVOKSBBTUQtVmk6ICBEZXZfSWQgMHg4MDANCihYRU4pIEFNRC1WaTogIEZsYWdz
IDB4MA0KKFhFTikgQU1ELVZpOiBJVkhEIERldmljZSBFbnRyeToNCihYRU4pIEFNRC1WaTog
IFR5cGUgMHgyDQooWEVOKSBBTUQtVmk6ICBEZXZfSWQgMHg1MA0KKFhFTikgQU1ELVZpOiAg
RmxhZ3MgMHgwDQooWEVOKSBBTUQtVmk6IElWSEQgRGV2aWNlIEVudHJ5Og0KKFhFTikgQU1E
LVZpOiAgVHlwZSAweDINCihYRU4pIEFNRC1WaTogIERldl9JZCAweDcwMA0KKFhFTikgQU1E
LVZpOiAgRmxhZ3MgMHgwDQooWEVOKSBBTUQtVmk6IElWSEQgRGV2aWNlIEVudHJ5Og0KKFhF
TikgQU1ELVZpOiAgVHlwZSAweDINCihYRU4pIEFNRC1WaTogIERldl9JZCAweDU4DQooWEVO
KSBBTUQtVmk6ICBGbGFncyAweDANCihYRU4pIEFNRC1WaTogSVZIRCBEZXZpY2UgRW50cnk6
DQooWEVOKSBBTUQtVmk6ICBUeXBlIDB4Mw0KKFhFTikgQU1ELVZpOiAgRGV2X0lkIDB4NjAw
DQooWEVOKSBBTUQtVmk6ICBGbGFncyAweDANCihYRU4pIEFNRC1WaTogIERldl9JZCBSYW5n
ZTogMHg2MDAgLT4gMHg2MDENCihYRU4pIEFNRC1WaTogSVZIRCBEZXZpY2UgRW50cnk6DQoo
WEVOKSBBTUQtVmk6ICBUeXBlIDB4Mg0KKFhFTikgQU1ELVZpOiAgRGV2X0lkIDB4NjANCihY
RU4pIEFNRC1WaTogIEZsYWdzIDB4MA0KKFhFTikgQU1ELVZpOiBJVkhEIERldmljZSBFbnRy
eToNCihYRU4pIEFNRC1WaTogIFR5cGUgMHgyDQooWEVOKSBBTUQtVmk6ICBEZXZfSWQgMHg1
MDANCihYRU4pIEFNRC1WaTogIEZsYWdzIDB4MA0KKFhFTikgQU1ELVZpOiBJVkhEIERldmlj
ZSBFbnRyeToNCihYRU4pIEFNRC1WaTogIFR5cGUgMHgyDQooWEVOKSBBTUQtVmk6ICBEZXZf
SWQgMHg2OA0KKFhFTikgQU1ELVZpOiAgRmxhZ3MgMHgwDQooWEVOKSBBTUQtVmk6IElWSEQg
RGV2aWNlIEVudHJ5Og0KKFhFTikgQU1ELVZpOiAgVHlwZSAweDMNCihYRU4pIEFNRC1WaTog
IERldl9JZCAweDQwMA0KKFhFTikgQU1ELVZpOiAgRmxhZ3MgMHgwDQooWEVOKSBBTUQtVmk6
ICBEZXZfSWQgUmFuZ2U6IDB4NDAwIC0+IDB4NDA3DQooWEVOKSBBTUQtVmk6IElWSEQgRGV2
aWNlIEVudHJ5Og0KKFhFTikgQU1ELVZpOiAgVHlwZSAweDINCihYRU4pIEFNRC1WaTogIERl
dl9JZCAweDg4DQooWEVOKSBBTUQtVmk6ICBGbGFncyAweDANCihYRU4pIEFNRC1WaTogSVZI
RCBEZXZpY2UgRW50cnk6DQooWEVOKSBBTUQtVmk6ICBUeXBlIDB4Mw0KKFhFTikgQU1ELVZp
OiAgRGV2X0lkIDB4OTANCihYRU4pIEFNRC1WaTogIEZsYWdzIDB4MA0KKFhFTikgQU1ELVZp
OiAgRGV2X0lkIFJhbmdlOiAweDkwIC0+IDB4OTINCihYRU4pIEFNRC1WaTogSVZIRCBEZXZp
Y2UgRW50cnk6DQooWEVOKSBBTUQtVmk6ICBUeXBlIDB4Mw0KKFhFTikgQU1ELVZpOiAgRGV2
X0lkIDB4OTgNCihYRU4pIEFNRC1WaTogIEZsYWdzIDB4MA0KKFhFTikgQU1ELVZpOiAgRGV2
X0lkIFJhbmdlOiAweDk4IC0+IDB4OWENCihYRU4pIEFNRC1WaTogSVZIRCBEZXZpY2UgRW50
cnk6DQooWEVOKSBBTUQtVmk6ICBUeXBlIDB4Mg0KKFhFTikgQU1ELVZpOiAgRGV2X0lkIDB4
YTANCihYRU4pIEFNRC1WaTogIEZsYWdzIDB4ZDcNCihYRU4pIEFNRC1WaTogSVZIRCBEZXZp
Y2UgRW50cnk6DQooWEVOKSBBTUQtVmk6ICBUeXBlIDB4Mg0KKFhFTikgQU1ELVZpOiAgRGV2
X0lkIDB4YTMNCihYRU4pIEFNRC1WaTogIEZsYWdzIDB4MA0KKFhFTikgQU1ELVZpOiBJVkhE
IERldmljZSBFbnRyeToNCihYRU4pIEFNRC1WaTogIFR5cGUgMHgyDQooWEVOKSBBTUQtVmk6
ICBEZXZfSWQgMHhhNA0KKFhFTikgQU1ELVZpOiAgRmxhZ3MgMHgwDQooWEVOKSBBTUQtVmk6
IElWSEQgRGV2aWNlIEVudHJ5Og0KKFhFTikgQU1ELVZpOiAgVHlwZSAweDANCihYRU4pIEFN
RC1WaTogIERldl9JZCAweDANCihYRU4pIEFNRC1WaTogIEZsYWdzIDB4MA0KKFhFTikgQU1E
LVZpOiBJVkhEIERldmljZSBFbnRyeToNCihYRU4pIEFNRC1WaTogIFR5cGUgMHg0Mw0KKFhF
TikgQU1ELVZpOiAgRGV2X0lkIDB4MzAwDQooWEVOKSBBTUQtVmk6ICBGbGFncyAweDANCihY
RU4pIEFNRC1WaTogIERldl9JZCBSYW5nZTogMHgzMDAgLT4gMHgzZmYNCihYRU4pIEFNRC1W
aTogIERldl9JZCBBbGlhczogMHhhNA0KKFhFTikgQU1ELVZpOiBJVkhEIERldmljZSBFbnRy
eToNCihYRU4pIEFNRC1WaTogIFR5cGUgMHgyDQooWEVOKSBBTUQtVmk6ICBEZXZfSWQgMHhh
NQ0KKFhFTikgQU1ELVZpOiAgRmxhZ3MgMHgwDQooWEVOKSBBTUQtVmk6IElWSEQgRGV2aWNl
IEVudHJ5Og0KKFhFTikgQU1ELVZpOiAgVHlwZSAweDINCihYRU4pIEFNRC1WaTogIERldl9J
ZCAweGE4DQooWEVOKSBBTUQtVmk6ICBGbGFncyAweDANCihYRU4pIEFNRC1WaTogSVZIRCBE
ZXZpY2UgRW50cnk6DQooWEVOKSBBTUQtVmk6ICBUeXBlIDB4Mg0KKFhFTikgQU1ELVZpOiAg
RGV2X0lkIDB4YTkNCihYRU4pIEFNRC1WaTogIEZsYWdzIDB4MA0KKFhFTikgQU1ELVZpOiBJ
VkhEIERldmljZSBFbnRyeToNCihYRU4pIEFNRC1WaTogIFR5cGUgMHgyDQooWEVOKSBBTUQt
Vmk6ICBEZXZfSWQgMHgxMDANCihYRU4pIEFNRC1WaTogIEZsYWdzIDB4MA0KKFhFTikgQU1E
LVZpOiBJVkhEIERldmljZSBFbnRyeToNCihYRU4pIEFNRC1WaTogIFR5cGUgMHgzDQooWEVO
KSBBTUQtVmk6ICBEZXZfSWQgMHhiMA0KKFhFTikgQU1ELVZpOiAgRmxhZ3MgMHgwDQooWEVO
KSBBTUQtVmk6ICBEZXZfSWQgUmFuZ2U6IDB4YjAgLT4gMHhiMg0KKFhFTikgQU1ELVZpOiBJ
VkhEIERldmljZSBFbnRyeToNCihYRU4pIEFNRC1WaTogIFR5cGUgMHgwDQooWEVOKSBBTUQt
Vmk6ICBEZXZfSWQgMHgwDQooWEVOKSBBTUQtVmk6ICBGbGFncyAweDANCihYRU4pIEFNRC1W
aTogSVZIRCBEZXZpY2UgRW50cnk6DQooWEVOKSBBTUQtVmk6ICBUeXBlIDB4NDgNCihYRU4p
IEFNRC1WaTogIERldl9JZCAweDANCihYRU4pIEFNRC1WaTogIEZsYWdzIDB4ZDcNCihYRU4p
IEFNRC1WaTogSVZIRCBEZXZpY2UgRW50cnk6DQooWEVOKSBBTUQtVmk6ICBUeXBlIDB4NDgN
CihYRU4pIEFNRC1WaTogIERldl9JZCAweDANCihYRU4pIEFNRC1WaTogIEZsYWdzIDB4MA0K
KFhFTikgQU1ELVZpOiBJT01NVSAwIEVuYWJsZWQuDQooWEVOKSBBTUQtVmk6IEVuYWJsaW5n
IGdsb2JhbCB2ZWN0b3IgbWFwDQooWEVOKSBJL08gdmlydHVhbGlzYXRpb24gZW5hYmxlZA0K
KFhFTikgIC0gRG9tMCBtb2RlOiBSZWxheGVkDQooWEVOKSBHZXR0aW5nIFZFUlNJT046IDgw
MDUwMDEwDQooWEVOKSBHZXR0aW5nIFZFUlNJT046IDgwMDUwMDEwDQooWEVOKSBHZXR0aW5n
IElEOiAwDQooWEVOKSBHZXR0aW5nIExWVDA6IDcwMA0KKFhFTikgR2V0dGluZyBMVlQxOiA0
MDANCihYRU4pIGVuYWJsZWQgRXh0SU5UIG9uIENQVSMwDQooWEVOKSBFU1IgdmFsdWUgYmVm
b3JlIGVuYWJsaW5nIHZlY3RvcjogMHgwMDAwMDAwNCAgYWZ0ZXI6IDB4MDAwMDAwMDANCihY
RU4pIEVOQUJMSU5HIElPLUFQSUMgSVJRcw0KKFhFTikgIC0+IFVzaW5nIG5ldyBBQ0sgbWV0
aG9kDQooWEVOKSBpbml0IElPX0FQSUMgSVJRcw0KKFhFTikgIElPLUFQSUMgKGFwaWNpZC1w
aW4pIDYtMCwgNi0xNiwgNi0xNywgNi0xOCwgNi0xOSwgNi0yMCwgNi0yMSwgNi0yMiwgNi0y
MywgNy0wLCA3LTEsIDctMiwgNy0zLCA3LTQsIDctNSwgNy02LCA3LTcsIDctOCwgNy05LCA3
LTEwLCA3LTExLCA3LTEyLCA3LTEzLCA3LTE0LCA3LTE1LCA3LTE2LCA3LTE3LCA3LTE4LCA3
LTE5LCA3LTIwLCA3LTIxLCA3LTIyLCA3LTIzLCA3LTI0LCA3LTI1LCA3LTI2LCA3LTI3LCA3
LTI4LCA3LTI5LCA3LTMwLCA3LTMxIG5vdCBjb25uZWN0ZWQuDQooWEVOKSAuLlRJTUVSOiB2
ZWN0b3I9MHhGMCBhcGljMT0wIHBpbjE9MiBhcGljMj0tMSBwaW4yPS0xDQooWEVOKSBudW1i
ZXIgb2YgTVAgSVJRIHNvdXJjZXM6IDE1Lg0KKFhFTikgbnVtYmVyIG9mIElPLUFQSUMgIzYg
cmVnaXN0ZXJzOiAyNC4NCihYRU4pIG51bWJlciBvZiBJTy1BUElDICM3IHJlZ2lzdGVyczog
MzIuDQooWEVOKSB0ZXN0aW5nIHRoZSBJTyBBUElDLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4N
CihYRU4pIElPIEFQSUMgIzYuLi4uLi4NCihYRU4pIC4uLi4gcmVnaXN0ZXIgIzAwOiAwNjAw
MDAwMA0KKFhFTikgLi4uLi4uLiAgICA6IHBoeXNpY2FsIEFQSUMgaWQ6IDA2DQooWEVOKSAu
Li4uLi4uICAgIDogRGVsaXZlcnkgVHlwZTogMA0KKFhFTikgLi4uLi4uLiAgICA6IExUUyAg
ICAgICAgICA6IDANCihYRU4pIC4uLi4gcmVnaXN0ZXIgIzAxOiAwMDE3ODAyMQ0KKFhFTikg
Li4uLi4uLiAgICAgOiBtYXggcmVkaXJlY3Rpb24gZW50cmllczogMDAxNw0KKFhFTikgLi4u
Li4uLiAgICAgOiBQUlEgaW1wbGVtZW50ZWQ6IDENCihYRU4pIC4uLi4uLi4gICAgIDogSU8g
QVBJQyB2ZXJzaW9uOiAwMDIxDQooWEVOKSAuLi4uIHJlZ2lzdGVyICMwMjogMDYwMDAwMDAN
CihYRU4pIC4uLi4uLi4gICAgIDogYXJiaXRyYXRpb246IDA2DQooWEVOKSAuLi4uIHJlZ2lz
dGVyICMwMzogMDcwMDAwMDANCihYRU4pIC4uLi4uLi4gICAgIDogQm9vdCBEVCAgICA6IDAN
CihYRU4pIC4uLi4gSVJRIHJlZGlyZWN0aW9uIHRhYmxlOg0KKFhFTikgIE5SIExvZyBQaHkg
TWFzayBUcmlnIElSUiBQb2wgU3RhdCBEZXN0IERlbGkgVmVjdDogICANCihYRU4pICAwMCAw
MDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwDQooWEVOKSAgMDEg
MDAxIDAxICAwICAgIDAgICAgMCAgIDAgICAwICAgIDEgICAgMSAgICAzMA0KKFhFTikgIDAy
IDAwMSAwMSAgMCAgICAwICAgIDAgICAwICAgMCAgICAxICAgIDEgICAgRjANCihYRU4pICAw
MyAwMDEgMDEgIDAgICAgMCAgICAwICAgMCAgIDAgICAgMSAgICAxICAgIDM4DQooWEVOKSAg
MDQgMDAxIDAxICAwICAgIDAgICAgMCAgIDAgICAwICAgIDEgICAgMSAgICBGMQ0KKFhFTikg
IDA1IDAwMSAwMSAgMCAgICAwICAgIDAgICAwICAgMCAgICAxICAgIDEgICAgNDANCihYRU4p
ICAwNiAwMDEgMDEgIDAgICAgMCAgICAwICAgMCAgIDAgICAgMSAgICAxICAgIDQ4DQooWEVO
KSAgMDcgMDAxIDAxICAwICAgIDAgICAgMCAgIDAgICAwICAgIDEgICAgMSAgICA1MA0KKFhF
TikgIDA4IDAwMSAwMSAgMCAgICAwICAgIDAgICAwICAgMCAgICAxICAgIDEgICAgNTgNCihY
RU4pICAwOSAwMDEgMDEgIDEgICAgMSAgICAwICAgMSAgIDAgICAgMSAgICAxICAgIDYwDQoo
WEVOKSAgMGEgMDAxIDAxICAwICAgIDAgICAgMCAgIDAgICAwICAgIDEgICAgMSAgICA2OA0K
KFhFTikgIDBiIDAwMSAwMSAgMCAgICAwICAgIDAgICAwICAgMCAgICAxICAgIDEgICAgNzAN
CihYRU4pICAwYyAwMDEgMDEgIDAgICAgMCAgICAwICAgMCAgIDAgICAgMSAgICAxICAgIDc4
DQooWEVOKSAgMGQgMDAxIDAxICAwICAgIDAgICAgMCAgIDAgICAwICAgIDEgICAgMSAgICA4
OA0KKFhFTikgIDBlIDAwMSAwMSAgMCAgICAwICAgIDAgICAwICAgMCAgICAxICAgIDEgICAg
OTANCihYRU4pICAwZiAwMDEgMDEgIDAgICAgMCAgICAwICAgMCAgIDAgICAgMSAgICAxICAg
IDk4DQooWEVOKSAgMTAgMDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAwICAgIDAgICAgMCAg
ICAwMA0KKFhFTikgIDExIDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDAg
ICAgMDANCihYRU4pICAxMiAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAw
ICAgIDAwDQooWEVOKSAgMTMgMDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAwICAgIDAgICAg
MCAgICAwMA0KKFhFTikgIDE0IDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAg
IDAgICAgMDANCihYRU4pICAxNSAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAg
ICAwICAgIDAwDQooWEVOKSAgMTYgMDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAwICAgIDAg
ICAgMCAgICAwMA0KKFhFTikgIDE3IDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAw
ICAgIDAgICAgMDANCihYRU4pIElPIEFQSUMgIzcuLi4uLi4NCihYRU4pIC4uLi4gcmVnaXN0
ZXIgIzAwOiAwNzAwMDAwMA0KKFhFTikgLi4uLi4uLiAgICA6IHBoeXNpY2FsIEFQSUMgaWQ6
IDA3DQooWEVOKSAuLi4uLi4uICAgIDogRGVsaXZlcnkgVHlwZTogMA0KKFhFTikgLi4uLi4u
LiAgICA6IExUUyAgICAgICAgICA6IDANCihYRU4pIC4uLi4gcmVnaXN0ZXIgIzAxOiAwMDFG
ODAyMQ0KKFhFTikgLi4uLi4uLiAgICAgOiBtYXggcmVkaXJlY3Rpb24gZW50cmllczogMDAx
Rg0KKFhFTikgLi4uLi4uLiAgICAgOiBQUlEgaW1wbGVtZW50ZWQ6IDENCihYRU4pIC4uLi4u
Li4gICAgIDogSU8gQVBJQyB2ZXJzaW9uOiAwMDIxDQooWEVOKSAuLi4uIHJlZ2lzdGVyICMw
MjogMDAwMDAwMDANCihYRU4pIC4uLi4uLi4gICAgIDogYXJiaXRyYXRpb246IDAwDQooWEVO
KSAuLi4uIElSUSByZWRpcmVjdGlvbiB0YWJsZToNCihYRU4pICBOUiBMb2cgUGh5IE1hc2sg
VHJpZyBJUlIgUG9sIFN0YXQgRGVzdCBEZWxpIFZlY3Q6ICAgDQooWEVOKSAgMDAgMDAwIDAw
ICAxICAgIDAgICAgMCAgIDAgICAwICAgIDAgICAgMCAgICAwMA0KKFhFTikgIDAxIDAwMCAw
MCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDAgICAgMDANCihYRU4pICAwMiAwMDAg
MDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwDQooWEVOKSAgMDMgMDAw
IDAwICAxICAgIDAgICAgMCAgIDAgICAwICAgIDAgICAgMCAgICAwMA0KKFhFTikgIDA0IDAw
MCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDAgICAgMDANCihYRU4pICAwNSAw
MDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwDQooWEVOKSAgMDYg
MDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAwICAgIDAgICAgMCAgICAwMA0KKFhFTikgIDA3
IDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDAgICAgMDANCihYRU4pICAw
OCAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwDQooWEVOKSAg
MDkgMDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAwICAgIDAgICAgMCAgICAwMA0KKFhFTikg
IDBhIDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDAgICAgMDANCihYRU4p
ICAwYiAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwDQooWEVO
KSAgMGMgMDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAwICAgIDAgICAgMCAgICAwMA0KKFhF
TikgIDBkIDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDAgICAgMDANCihY
RU4pICAwZSAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwDQoo
WEVOKSAgMGYgMDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAwICAgIDAgICAgMCAgICAwMA0K
KFhFTikgIDEwIDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDAgICAgMDAN
CihYRU4pICAxMSAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAw
DQooWEVOKSAgMTIgMDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAwICAgIDAgICAgMCAgICAw
MA0KKFhFTikgIDEzIDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDAgICAg
MDANCihYRU4pICAxNCAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAg
IDAwDQooWEVOKSAgMTUgMDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAwICAgIDAgICAgMCAg
ICAwMA0KKFhFTikgIDE2IDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDAg
ICAgMDANCihYRU4pICAxNyAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAw
ICAgIDAwDQooWEVOKSAgMTggMDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAwICAgIDAgICAg
MCAgICAwMA0KKFhFTikgIDE5IDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAg
IDAgICAgMDANCihYRU4pICAxYSAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAg
ICAwICAgIDAwDQooWEVOKSAgMWIgMDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAwICAgIDAg
ICAgMCAgICAwMA0KKFhFTikgIDFjIDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAw
ICAgIDAgICAgMDANCihYRU4pICAxZCAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAg
MCAgICAwICAgIDAwDQooWEVOKSAgMWUgMDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAwICAg
IDAgICAgMCAgICAwMA0KKFhFTikgIDFmIDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAg
ICAwICAgIDAgICAgMDANCihYRU4pIFVzaW5nIHZlY3Rvci1iYXNlZCBpbmRleGluZw0KKFhF
TikgSVJRIHRvIHBpbiBtYXBwaW5nczoNCihYRU4pIElSUTI0MCAtPiAwOjINCihYRU4pIElS
UTQ4IC0+IDA6MQ0KKFhFTikgSVJRNTYgLT4gMDozDQooWEVOKSBJUlEyNDEgLT4gMDo0DQoo
WEVOKSBJUlE2NCAtPiAwOjUNCihYRU4pIElSUTcyIC0+IDA6Ng0KKFhFTikgSVJRODAgLT4g
MDo3DQooWEVOKSBJUlE4OCAtPiAwOjgNCihYRU4pIElSUTk2IC0+IDA6OQ0KKFhFTikgSVJR
MTA0IC0+IDA6MTANCihYRU4pIElSUTExMiAtPiAwOjExDQooWEVOKSBJUlExMjAgLT4gMDox
Mg0KKFhFTikgSVJRMTM2IC0+IDA6MTMNCihYRU4pIElSUTE0NCAtPiAwOjE0DQooWEVOKSBJ
UlExNTIgLT4gMDoxNQ0KKFhFTikgLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u
Li4uIGRvbmUuDQooWEVOKSBVc2luZyBsb2NhbCBBUElDIHRpbWVyIGludGVycnVwdHMuDQoo
WEVOKSBjYWxpYnJhdGluZyBBUElDIHRpbWVyIC4uLg0KKFhFTikgLi4uLi4gQ1BVIGNsb2Nr
IHNwZWVkIGlzIDMyMDAuMTI1OCBNSHouDQooWEVOKSAuLi4uLiBob3N0IGJ1cyBjbG9jayBz
cGVlZCBpcyAyMDAuMDA3OCBNSHouDQooWEVOKSAuLi4uLiBidXNfc2NhbGUgPSAweDAwMDBD
Q0Q3DQooWEVOKSBbMjAxMi0wOS0wMSAyMjoyNjo1MF0gUGxhdGZvcm0gdGltZXIgaXMgMTQu
MzE4TUh6IEhQRVQNCihYRU4pIFsyMDEyLTA5LTAxIDIyOjI2OjUwXSBBbGxvY2F0ZWQgY29u
c29sZSByaW5nIG9mIDY0IEtpQi4NCihYRU4pIFsyMDEyLTA5LTAxIDIyOjI2OjUwXSBIVk06
IEFTSURzIGVuYWJsZWQuDQooWEVOKSBbMjAxMi0wOS0wMSAyMjoyNjo1MF0gU1ZNOiBTdXBw
b3J0ZWQgYWR2YW5jZWQgZmVhdHVyZXM6DQooWEVOKSBbMjAxMi0wOS0wMSAyMjoyNjo1MF0g
IC0gTmVzdGVkIFBhZ2UgVGFibGVzIChOUFQpDQooWEVOKSBbMjAxMi0wOS0wMSAyMjoyNjo1
MF0gIC0gTGFzdCBCcmFuY2ggUmVjb3JkIChMQlIpIFZpcnR1YWxpc2F0aW9uDQooWEVOKSBb
MjAxMi0wOS0wMSAyMjoyNjo1MF0gIC0gTmV4dC1SSVAgU2F2ZWQgb24gI1ZNRVhJVA0KKFhF
TikgWzIwMTItMDktMDEgMjI6MjY6NTBdICAtIFBhdXNlLUludGVyY2VwdCBGaWx0ZXINCihY
RU4pIFsyMDEyLTA5LTAxIDIyOjI2OjUwXSBIVk06IFNWTSBlbmFibGVkDQooWEVOKSBbMjAx
Mi0wOS0wMSAyMjoyNjo1MF0gSFZNOiBIYXJkd2FyZSBBc3Npc3RlZCBQYWdpbmcgKEhBUCkg
ZGV0ZWN0ZWQNCihYRU4pIFsyMDEyLTA5LTAxIDIyOjI2OjUwXSBIVk06IEhBUCBwYWdlIHNp
emVzOiA0a0IsIDJNQiwgMUdCDQooWEVOKSBbMjAxMi0wOS0wMSAyMjoyNjo0OV0gbWFza2Vk
IEV4dElOVCBvbiBDUFUjMQ0KKFhFTikgWzIwMTItMDktMDEgMjI6MjY6NTBdIG1pY3JvY29k
ZTogY29sbGVjdF9jcHVfaW5mbzogcGF0Y2hfaWQ9MHgxMDAwMGJmDQooWEVOKSBbMjAxMi0w
OS0wMSAyMjoyNjo0OV0gbWFza2VkIEV4dElOVCBvbiBDUFUjMg0KKFhFTikgWzIwMTItMDkt
MDEgMjI6MjY6NTBdIG1pY3JvY29kZTogY29sbGVjdF9jcHVfaW5mbzogcGF0Y2hfaWQ9MHgx
MDAwMGJmDQooWEVOKSBbMjAxMi0wOS0wMSAyMjoyNjo0OV0gbWFza2VkIEV4dElOVCBvbiBD
UFUjMw0KKFhFTikgWzIwMTItMDktMDEgMjI6MjY6NTBdIG1pY3JvY29kZTogY29sbGVjdF9j
cHVfaW5mbzogcGF0Y2hfaWQ9MHgxMDAwMGJmDQooWEVOKSBbMjAxMi0wOS0wMSAyMjoyNjo0
OV0gbWFza2VkIEV4dElOVCBvbiBDUFUjNA0KKFhFTikgWzIwMTItMDktMDEgMjI6MjY6NTBd
IG1pY3JvY29kZTogY29sbGVjdF9jcHVfaW5mbzogcGF0Y2hfaWQ9MHgxMDAwMGJmDQooWEVO
KSBbMjAxMi0wOS0wMSAyMjoyNjo0OV0gbWFza2VkIEV4dElOVCBvbiBDUFUjNQ0KKFhFTikg
WzIwMTItMDktMDEgMjI6MjY6NTBdIEJyb3VnaHQgdXAgNiBDUFVzDQooWEVOKSBbMjAxMi0w
OS0wMSAyMjoyNjo1MF0gbWljcm9jb2RlOiBjb2xsZWN0X2NwdV9pbmZvOiBwYXRjaF9pZD0w
eDEwMDAwYmYNCihYRU4pIFsyMDEyLTA5LTAxIDIyOjI2OjUwXSBIUEVUJ3MgTVNJIG1vZGUg
aGFzbid0IGJlZW4gc3VwcG9ydGVkIHdoZW4gSW50ZXJydXB0IFJlbWFwcGluZyBpcyBlbmFi
bGVkLg0KKFhFTikgWzIwMTItMDktMDEgMjI6MjY6NTBdIEFDUEkgc2xlZXAgbW9kZXM6IFMz
DQooWEVOKSBbMjAxMi0wOS0wMSAyMjoyNjo1MF0gTUNBOiBVc2UgaHcgdGhyZXNob2xkaW5n
IHRvIGFkanVzdCBwb2xsaW5nIGZyZXF1ZW5jeQ0KKFhFTikgWzIwMTItMDktMDEgMjI6MjY6
NTBdIG1jaGVja19wb2xsOiBNYWNoaW5lIGNoZWNrIHBvbGxpbmcgdGltZXIgc3RhcnRlZC4N
CihYRU4pIFsyMDEyLTA5LTAxIDIyOjI2OjUwXSBYZW5vcHJvZmlsZTogRmFpbGVkIHRvIHNl
dHVwIElCUyBMVlQgb2Zmc2V0LCBJQlNDVEwgPSAweGZmZmZmZmZmDQooWEVOKSBbMjAxMi0w
OS0wMSAyMjoyNjo1MF0gKioqIExPQURJTkcgRE9NQUlOIDAgKioqDQooWEVOKSBbMjAxMi0w
OS0wMSAyMjoyNjo1MF0gZWxmX3BhcnNlX2JpbmFyeTogcGhkcjogcGFkZHI9MHgxMDAwMDAw
IG1lbXN6PTB4YjY4MDAwDQooWEVOKSBbMjAxMi0wOS0wMSAyMjoyNjo1MF0gZWxmX3BhcnNl
X2JpbmFyeTogcGhkcjogcGFkZHI9MHgxYzAwMDAwIG1lbXN6PTB4ZDgwZTgNCihYRU4pIFsy
MDEyLTA5LTAxIDIyOjI2OjUwXSBlbGZfcGFyc2VfYmluYXJ5OiBwaGRyOiBwYWRkcj0weDFj
ZDkwMDAgbWVtc3o9MHgxM2MwMA0KKFhFTikgWzIwMTItMDktMDEgMjI6MjY6NTBdIGVsZl9w
YXJzZV9iaW5hcnk6IHBoZHI6IHBhZGRyPTB4MWNlZDAwMCBtZW1zej0weGRlNDAwMA0KKFhF
TikgWzIwMTItMDktMDEgMjI6MjY6NTBdIGVsZl9wYXJzZV9iaW5hcnk6IG1lbW9yeTogMHgx
MDAwMDAwIC0+IDB4MmFkMTAwMA0KKFhFTikgWzIwMTItMDktMDEgMjI6MjY6NTBdIGVsZl94
ZW5fcGFyc2Vfbm90ZTogR1VFU1RfT1MgPSAibGludXgiDQooWEVOKSBbMjAxMi0wOS0wMSAy
MjoyNjo1MF0gZWxmX3hlbl9wYXJzZV9ub3RlOiBHVUVTVF9WRVJTSU9OID0gIjIuNiINCihY
RU4pIFsyMDEyLTA5LTAxIDIyOjI2OjUwXSBlbGZfeGVuX3BhcnNlX25vdGU6IFhFTl9WRVJT
SU9OID0gInhlbi0zLjAiDQooWEVOKSBbMjAxMi0wOS0wMSAyMjoyNjo1MF0gZWxmX3hlbl9w
YXJzZV9ub3RlOiBWSVJUX0JBU0UgPSAweGZmZmZmZmZmODAwMDAwMDANCihYRU4pIFsyMDEy
LTA5LTAxIDIyOjI2OjUwXSBlbGZfeGVuX3BhcnNlX25vdGU6IEVOVFJZID0gMHhmZmZmZmZm
ZjgxY2VkMjEwDQooWEVOKSBbMjAxMi0wOS0wMSAyMjoyNjo1MV0gZWxmX3hlbl9wYXJzZV9u
b3RlOiBIWVBFUkNBTExfUEFHRSA9IDB4ZmZmZmZmZmY4MTAwMTAwMA0KKFhFTikgWzIwMTIt
MDktMDEgMjI6MjY6NTFdIGVsZl94ZW5fcGFyc2Vfbm90ZTogRkVBVFVSRVMgPSAiIXdyaXRh
YmxlX3BhZ2VfdGFibGVzfHBhZV9wZ2Rpcl9hYm92ZV80Z2IiDQooWEVOKSBbMjAxMi0wOS0w
MSAyMjoyNjo1MV0gZWxmX3hlbl9wYXJzZV9ub3RlOiBQQUVfTU9ERSA9ICJ5ZXMiDQooWEVO
KSBbMjAxMi0wOS0wMSAyMjoyNjo1MV0gZWxmX3hlbl9wYXJzZV9ub3RlOiBMT0FERVIgPSAi
Z2VuZXJpYyINCihYRU4pIFsyMDEyLTA5LTAxIDIyOjI2OjUxXSBlbGZfeGVuX3BhcnNlX25v
dGU6IHVua25vd24geGVuIGVsZiBub3RlICgweGQpDQooWEVOKSBbMjAxMi0wOS0wMSAyMjoy
Njo1MV0gZWxmX3hlbl9wYXJzZV9ub3RlOiBTVVNQRU5EX0NBTkNFTCA9IDB4MQ0KKFhFTikg
WzIwMTItMDktMDEgMjI6MjY6NTFdIGVsZl94ZW5fcGFyc2Vfbm90ZTogSFZfU1RBUlRfTE9X
ID0gMHhmZmZmODAwMDAwMDAwMDAwDQooWEVOKSBbMjAxMi0wOS0wMSAyMjoyNjo1MV0gZWxm
X3hlbl9wYXJzZV9ub3RlOiBQQUREUl9PRkZTRVQgPSAweDANCihYRU4pIFsyMDEyLTA5LTAx
IDIyOjI2OjUxXSBlbGZfeGVuX2FkZHJfY2FsY19jaGVjazogYWRkcmVzc2VzOg0KKFhFTikg
WzIwMTItMDktMDEgMjI6MjY6NTFdICAgICB2aXJ0X2Jhc2UgICAgICAgID0gMHhmZmZmZmZm
ZjgwMDAwMDAwDQooWEVOKSBbMjAxMi0wOS0wMSAyMjoyNjo1MV0gICAgIGVsZl9wYWRkcl9v
ZmZzZXQgPSAweDANCihYRU4pIFsyMDEyLTA5LTAxIDIyOjI2OjUxXSAgICAgdmlydF9vZmZz
ZXQgICAgICA9IDB4ZmZmZmZmZmY4MDAwMDAwMA0KKFhFTikgWzIwMTItMDktMDEgMjI6MjY6
NTFdICAgICB2aXJ0X2tzdGFydCAgICAgID0gMHhmZmZmZmZmZjgxMDAwMDAwDQooWEVOKSBb
MjAxMi0wOS0wMSAyMjoyNjo1MV0gICAgIHZpcnRfa2VuZCAgICAgICAgPSAweGZmZmZmZmZm
ODJhZDEwMDANCihYRU4pIFsyMDEyLTA5LTAxIDIyOjI2OjUxXSAgICAgdmlydF9lbnRyeSAg
ICAgICA9IDB4ZmZmZmZmZmY4MWNlZDIxMA0KKFhFTikgWzIwMTItMDktMDEgMjI6MjY6NTFd
ICAgICBwMm1fYmFzZSAgICAgICAgID0gMHhmZmZmZmZmZmZmZmZmZmZmDQooWEVOKSBbMjAx
Mi0wOS0wMSAyMjoyNjo1MV0gIFhlbiAga2VybmVsOiA2NC1iaXQsIGxzYiwgY29tcGF0MzIN
CihYRU4pIFsyMDEyLTA5LTAxIDIyOjI2OjUxXSAgRG9tMCBrZXJuZWw6IDY0LWJpdCwgUEFF
LCBsc2IsIHBhZGRyIDB4MTAwMDAwMCAtPiAweDJhZDEwMDANCihYRU4pIFsyMDEyLTA5LTAx
IDIyOjI2OjUxXSBQSFlTSUNBTCBNRU1PUlkgQVJSQU5HRU1FTlQ6DQooWEVOKSBbMjAxMi0w
OS0wMSAyMjoyNjo1MV0gIERvbTAgYWxsb2MuOiAgIDAwMDAwMDAyNDAwMDAwMDAtPjAwMDAw
MDAyNDQwMDAwMDAgKDI0MjQyOCBwYWdlcyB0byBiZSBhbGxvY2F0ZWQpDQooWEVOKSBbMjAx
Mi0wOS0wMSAyMjoyNjo1MV0gIEluaXQuIHJhbWRpc2s6IDAwMDAwMDAyNGYyZmMwMDAtPjAw
MDAwMDAyNGZmZmY4MDANCihYRU4pIFsyMDEyLTA5LTAxIDIyOjI2OjUxXSBWSVJUVUFMIE1F
TU9SWSBBUlJBTkdFTUVOVDoNCihYRU4pIFsyMDEyLTA5LTAxIDIyOjI2OjUxXSAgTG9hZGVk
IGtlcm5lbDogZmZmZmZmZmY4MTAwMDAwMC0+ZmZmZmZmZmY4MmFkMTAwMA0KKFhFTikgWzIw
MTItMDktMDEgMjI6MjY6NTFdICBJbml0LiByYW1kaXNrOiBmZmZmZmZmZjgyYWQxMDAwLT5m
ZmZmZmZmZjgzN2Q0ODAwDQooWEVOKSBbMjAxMi0wOS0wMSAyMjoyNjo1MV0gIFBoeXMtTWFj
aCBtYXA6IGZmZmZmZmZmODM3ZDUwMDAtPmZmZmZmZmZmODM5ZDUwMDANCihYRU4pIFsyMDEy
LTA5LTAxIDIyOjI2OjUxXSAgU3RhcnQgaW5mbzogICAgZmZmZmZmZmY4MzlkNTAwMC0+ZmZm
ZmZmZmY4MzlkNTRiNA0KKFhFTikgWzIwMTItMDktMDEgMjI6MjY6NTFdICBQYWdlIHRhYmxl
czogICBmZmZmZmZmZjgzOWQ2MDAwLT5mZmZmZmZmZjgzOWY3MDAwDQooWEVOKSBbMjAxMi0w
OS0wMSAyMjoyNjo1MV0gIEJvb3Qgc3RhY2s6ICAgIGZmZmZmZmZmODM5ZjcwMDAtPmZmZmZm
ZmZmODM5ZjgwMDANCihYRU4pIFsyMDEyLTA5LTAxIDIyOjI2OjUxXSAgVE9UQUw6ICAgICAg
ICAgZmZmZmZmZmY4MDAwMDAwMC0+ZmZmZmZmZmY4M2MwMDAwMA0KKFhFTikgWzIwMTItMDkt
MDEgMjI6MjY6NTFdICBFTlRSWSBBRERSRVNTOiBmZmZmZmZmZjgxY2VkMjEwDQooWEVOKSBb
MjAxMi0wOS0wMSAyMjoyNjo1MV0gRG9tMCBoYXMgbWF4aW11bSA2IFZDUFVzDQooWEVOKSBb
MjAxMi0wOS0wMSAyMjoyNjo1MV0gZWxmX2xvYWRfYmluYXJ5OiBwaGRyIDAgYXQgMHhmZmZm
ZmZmZjgxMDAwMDAwIC0+IDB4ZmZmZmZmZmY4MWI2ODAwMA0KKFhFTikgWzIwMTItMDktMDEg
MjI6MjY6NTFdIGVsZl9sb2FkX2JpbmFyeTogcGhkciAxIGF0IDB4ZmZmZmZmZmY4MWMwMDAw
MCAtPiAweGZmZmZmZmZmODFjZDgwZTgNCihYRU4pIFsyMDEyLTA5LTAxIDIyOjI2OjUxXSBl
bGZfbG9hZF9iaW5hcnk6IHBoZHIgMiBhdCAweGZmZmZmZmZmODFjZDkwMDAgLT4gMHhmZmZm
ZmZmZjgxY2VjYzAwDQooWEVOKSBbMjAxMi0wOS0wMSAyMjoyNjo1MV0gZWxmX2xvYWRfYmlu
YXJ5OiBwaGRyIDMgYXQgMHhmZmZmZmZmZjgxY2VkMDAwIC0+IDB4ZmZmZmZmZmY4MWQ4NTAw
MA0KKFhFTikgWzIwMTItMDktMDEgMjI6MjY6NTFdIEFNRC1WaTogU2V0dXAgSS9PIHBhZ2Ug
dGFibGU6IGRldmljZSBpZCA9IDB4MDAwMCwgcm9vdCB0YWJsZSA9IDB4MjRkYTUzMDAwLCBk
b21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMNCihYRU4pIFsyMDEyLTA5LTAxIDIyOjI2OjUx
XSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweDAwMDIsIHJv
b3QgdGFibGUgPSAweDI0ZGE1MzAwMCwgZG9tYWluID0gMCwgcGFnaW5nIG1vZGUgPSAzDQoo
WEVOKSBbMjAxMi0wOS0wMSAyMjoyNjo1MV0gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJs
ZTogZGV2aWNlIGlkID0gMHgwMDEwLCByb290IHRhYmxlID0gMHgyNGRhNTMwMDAsIGRvbWFp
biA9IDAsIHBhZ2luZyBtb2RlID0gMw0KKFhFTikgWzIwMTItMDktMDEgMjI6MjY6NTFdIEFN
RC1WaTogU2V0dXAgSS9PIHBhZ2UgdGFibGU6IGRldmljZSBpZCA9IDB4MDAxOCwgcm9vdCB0
YWJsZSA9IDB4MjRkYTUzMDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMNCihYRU4p
IFsyMDEyLTA5LTAxIDIyOjI2OjUxXSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBk
ZXZpY2UgaWQgPSAweDAwMjgsIHJvb3QgdGFibGUgPSAweDI0ZGE1MzAwMCwgZG9tYWluID0g
MCwgcGFnaW5nIG1vZGUgPSAzDQooWEVOKSBbMjAxMi0wOS0wMSAyMjoyNjo1MV0gQU1ELVZp
OiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHgwMDMwLCByb290IHRhYmxl
ID0gMHgyNGRhNTMwMDAsIGRvbWFpbiA9IDAsIHBhZ2luZyBtb2RlID0gMw0KKFhFTikgWzIw
MTItMDktMDEgMjI6MjY6NTFdIEFNRC1WaTogU2V0dXAgSS9PIHBhZ2UgdGFibGU6IGRldmlj
ZSBpZCA9IDB4MDA1MCwgcm9vdCB0YWJsZSA9IDB4MjRkYTUzMDAwLCBkb21haW4gPSAwLCBw
YWdpbmcgbW9kZSA9IDMNCihYRU4pIFsyMDEyLTA5LTAxIDIyOjI2OjUxXSBBTUQtVmk6IFNl
dHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweDAwNTgsIHJvb3QgdGFibGUgPSAw
eDI0ZGE1MzAwMCwgZG9tYWluID0gMCwgcGFnaW5nIG1vZGUgPSAzDQooWEVOKSBbMjAxMi0w
OS0wMSAyMjoyNjo1MV0gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlk
ID0gMHgwMDYwLCByb290IHRhYmxlID0gMHgyNGRhNTMwMDAsIGRvbWFpbiA9IDAsIHBhZ2lu
ZyBtb2RlID0gMw0KKFhFTikgWzIwMTItMDktMDEgMjI6MjY6NTFdIEFNRC1WaTogU2V0dXAg
SS9PIHBhZ2UgdGFibGU6IGRldmljZSBpZCA9IDB4MDA2OCwgcm9vdCB0YWJsZSA9IDB4MjRk
YTUzMDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMNCihYRU4pIFsyMDEyLTA5LTAx
IDIyOjI2OjUxXSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAw
eDAwODgsIHJvb3QgdGFibGUgPSAweDI0ZGE1MzAwMCwgZG9tYWluID0gMCwgcGFnaW5nIG1v
ZGUgPSAzDQooWEVOKSBbMjAxMi0wOS0wMSAyMjoyNjo1MV0gQU1ELVZpOiBTZXR1cCBJL08g
cGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHgwMDkwLCByb290IHRhYmxlID0gMHgyNGRhNTMw
MDAsIGRvbWFpbiA9IDAsIHBhZ2luZyBtb2RlID0gMw0KKFhFTikgWzIwMTItMDktMDEgMjI6
MjY6NTFdIEFNRC1WaTogU2V0dXAgSS9PIHBhZ2UgdGFibGU6IGRldmljZSBpZCA9IDB4MDA5
Miwgcm9vdCB0YWJsZSA9IDB4MjRkYTUzMDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9
IDMNCihYRU4pIFsyMDEyLTA5LTAxIDIyOjI2OjUxXSBBTUQtVmk6IFNldHVwIEkvTyBwYWdl
IHRhYmxlOiBkZXZpY2UgaWQgPSAweDAwOTgsIHJvb3QgdGFibGUgPSAweDI0ZGE1MzAwMCwg
ZG9tYWluID0gMCwgcGFnaW5nIG1vZGUgPSAzDQooWEVOKSBbMjAxMi0wOS0wMSAyMjoyNjo1
MV0gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHgwMDlhLCBy
b290IHRhYmxlID0gMHgyNGRhNTMwMDAsIGRvbWFpbiA9IDAsIHBhZ2luZyBtb2RlID0gMw0K
KFhFTikgWzIwMTItMDktMDEgMjI6MjY6NTFdIEFNRC1WaTogU2V0dXAgSS9PIHBhZ2UgdGFi
bGU6IGRldmljZSBpZCA9IDB4MDBhMCwgcm9vdCB0YWJsZSA9IDB4MjRkYTUzMDAwLCBkb21h
aW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMNCihYRU4pIFsyMDEyLTA5LTAxIDIyOjI2OjUxXSBB
TUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweDAwYTMsIHJvb3Qg
dGFibGUgPSAweDI0ZGE1MzAwMCwgZG9tYWluID0gMCwgcGFnaW5nIG1vZGUgPSAzDQooWEVO
KSBbMjAxMi0wOS0wMSAyMjoyNjo1MV0gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTog
ZGV2aWNlIGlkID0gMHgwMGE0LCByb290IHRhYmxlID0gMHgyNGRhNTMwMDAsIGRvbWFpbiA9
IDAsIHBhZ2luZyBtb2RlID0gMw0KKFhFTikgWzIwMTItMDktMDEgMjI6MjY6NTFdIEFNRC1W
aTogU2V0dXAgSS9PIHBhZ2UgdGFibGU6IGRldmljZSBpZCA9IDB4MDBhNSwgcm9vdCB0YWJs
ZSA9IDB4MjRkYTUzMDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMNCihYRU4pIFsy
MDEyLTA5LTAxIDIyOjI2OjUxXSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZp
Y2UgaWQgPSAweDAwYTgsIHJvb3QgdGFibGUgPSAweDI0ZGE1MzAwMCwgZG9tYWluID0gMCwg
cGFnaW5nIG1vZGUgPSAzDQooWEVOKSBbMjAxMi0wOS0wMSAyMjoyNjo1MV0gQU1ELVZpOiBT
ZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHgwMGIwLCByb290IHRhYmxlID0g
MHgyNGRhNTMwMDAsIGRvbWFpbiA9IDAsIHBhZ2luZyBtb2RlID0gMw0KKFhFTikgWzIwMTIt
MDktMDEgMjI6MjY6NTFdIEFNRC1WaTogU2V0dXAgSS9PIHBhZ2UgdGFibGU6IGRldmljZSBp
ZCA9IDB4MDBiMiwgcm9vdCB0YWJsZSA9IDB4MjRkYTUzMDAwLCBkb21haW4gPSAwLCBwYWdp
bmcgbW9kZSA9IDMNCihYRU4pIFsyMDEyLTA5LTAxIDIyOjI2OjUxXSBBTUQtVmk6IE5vIGlv
bW11IGZvciBkZXZpY2UgMDAwMDowMDoxOC4wDQooWEVOKSBbMjAxMi0wOS0wMSAyMjoyNjo1
MV0gQU1ELVZpOiBObyBpb21tdSBmb3IgZGV2aWNlIDAwMDA6MDA6MTguMQ0KKFhFTikgWzIw
MTItMDktMDEgMjI6MjY6NTFdIEFNRC1WaTogTm8gaW9tbXUgZm9yIGRldmljZSAwMDAwOjAw
OjE4LjINCihYRU4pIFsyMDEyLTA5LTAxIDIyOjI2OjUxXSBBTUQtVmk6IE5vIGlvbW11IGZv
ciBkZXZpY2UgMDAwMDowMDoxOC4zDQooWEVOKSBbMjAxMi0wOS0wMSAyMjoyNjo1MV0gQU1E
LVZpOiBObyBpb21tdSBmb3IgZGV2aWNlIDAwMDA6MDA6MTguNA0KKFhFTikgWzIwMTItMDkt
MDEgMjI6MjY6NTFdIEFNRC1WaTogU2V0dXAgSS9PIHBhZ2UgdGFibGU6IGRldmljZSBpZCA9
IDB4MDQwMCwgcm9vdCB0YWJsZSA9IDB4MjRkYTUzMDAwLCBkb21haW4gPSAwLCBwYWdpbmcg
bW9kZSA9IDMNCihYRU4pIFsyMDEyLTA5LTAxIDIyOjI2OjUxXSBBTUQtVmk6IFNldHVwIEkv
TyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweDA0MDEsIHJvb3QgdGFibGUgPSAweDI0ZGE1
MzAwMCwgZG9tYWluID0gMCwgcGFnaW5nIG1vZGUgPSAzDQooWEVOKSBbMjAxMi0wOS0wMSAy
MjoyNjo1MV0gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHgw
NDAyLCByb290IHRhYmxlID0gMHgyNGRhNTMwMDAsIGRvbWFpbiA9IDAsIHBhZ2luZyBtb2Rl
ID0gMw0KKFhFTikgWzIwMTItMDktMDEgMjI6MjY6NTFdIEFNRC1WaTogU2V0dXAgSS9PIHBh
Z2UgdGFibGU6IGRldmljZSBpZCA9IDB4MDQwMywgcm9vdCB0YWJsZSA9IDB4MjRkYTUzMDAw
LCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMNCihYRU4pIFsyMDEyLTA5LTAxIDIyOjI2
OjUxXSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweDA0MDQs
IHJvb3QgdGFibGUgPSAweDI0ZGE1MzAwMCwgZG9tYWluID0gMCwgcGFnaW5nIG1vZGUgPSAz
DQooWEVOKSBbMjAxMi0wOS0wMSAyMjoyNjo1MV0gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0
YWJsZTogZGV2aWNlIGlkID0gMHgwNDA1LCByb290IHRhYmxlID0gMHgyNGRhNTMwMDAsIGRv
bWFpbiA9IDAsIHBhZ2luZyBtb2RlID0gMw0KKFhFTikgWzIwMTItMDktMDEgMjI6MjY6NTFd
IEFNRC1WaTogU2V0dXAgSS9PIHBhZ2UgdGFibGU6IGRldmljZSBpZCA9IDB4MDQwNiwgcm9v
dCB0YWJsZSA9IDB4MjRkYTUzMDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMNCihY
RU4pIFsyMDEyLTA5LTAxIDIyOjI2OjUyXSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxl
OiBkZXZpY2UgaWQgPSAweDA0MDcsIHJvb3QgdGFibGUgPSAweDI0ZGE1MzAwMCwgZG9tYWlu
ID0gMCwgcGFnaW5nIG1vZGUgPSAzDQooWEVOKSBbMjAxMi0wOS0wMSAyMjoyNjo1Ml0gQU1E
LVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHgwNTAwLCByb290IHRh
YmxlID0gMHgyNGRhNTMwMDAsIGRvbWFpbiA9IDAsIHBhZ2luZyBtb2RlID0gMw0KKFhFTikg
WzIwMTItMDktMDEgMjI6MjY6NTJdIEFNRC1WaTogU2V0dXAgSS9PIHBhZ2UgdGFibGU6IGRl
dmljZSBpZCA9IDB4MDYwMCwgcm9vdCB0YWJsZSA9IDB4MjRkYTUzMDAwLCBkb21haW4gPSAw
LCBwYWdpbmcgbW9kZSA9IDMNCihYRU4pIFsyMDEyLTA5LTAxIDIyOjI2OjUyXSBBTUQtVmk6
IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweDA2MDEsIHJvb3QgdGFibGUg
PSAweDI0ZGE1MzAwMCwgZG9tYWluID0gMCwgcGFnaW5nIG1vZGUgPSAzDQooWEVOKSBbMjAx
Mi0wOS0wMSAyMjoyNjo1Ml0gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNl
IGlkID0gMHgwNzAwLCByb290IHRhYmxlID0gMHgyNGRhNTMwMDAsIGRvbWFpbiA9IDAsIHBh
Z2luZyBtb2RlID0gMw0KKFhFTikgWzIwMTItMDktMDEgMjI6MjY6NTJdIEFNRC1WaTogU2V0
dXAgSS9PIHBhZ2UgdGFibGU6IGRldmljZSBpZCA9IDB4MDgwMCwgcm9vdCB0YWJsZSA9IDB4
MjRkYTUzMDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMNCihYRU4pIFsyMDEyLTA5
LTAxIDIyOjI2OjUyXSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQg
PSAweDA5MDAsIHJvb3QgdGFibGUgPSAweDI0ZGE1MzAwMCwgZG9tYWluID0gMCwgcGFnaW5n
IG1vZGUgPSAzDQooWEVOKSBbMjAxMi0wOS0wMSAyMjoyNjo1Ml0gQU1ELVZpOiBTZXR1cCBJ
L08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHgwYTAwLCByb290IHRhYmxlID0gMHgyNGRh
NTMwMDAsIGRvbWFpbiA9IDAsIHBhZ2luZyBtb2RlID0gMw0KKFhFTikgWzIwMTItMDktMDEg
MjI6MjY6NTJdIEFNRC1WaTogU2V0dXAgSS9PIHBhZ2UgdGFibGU6IGRldmljZSBpZCA9IDB4
MGEwMSwgcm9vdCB0YWJsZSA9IDB4MjRkYTUzMDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9k
ZSA9IDMNCihYRU4pIFsyMDEyLTA5LTAxIDIyOjI2OjUyXSBBTUQtVmk6IFNldHVwIEkvTyBw
YWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweDBhMDIsIHJvb3QgdGFibGUgPSAweDI0ZGE1MzAw
MCwgZG9tYWluID0gMCwgcGFnaW5nIG1vZGUgPSAzDQooWEVOKSBbMjAxMi0wOS0wMSAyMjoy
Njo1Ml0gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHgwYTAz
LCByb290IHRhYmxlID0gMHgyNGRhNTMwMDAsIGRvbWFpbiA9IDAsIHBhZ2luZyBtb2RlID0g
Mw0KKFhFTikgWzIwMTItMDktMDEgMjI6MjY6NTJdIEFNRC1WaTogU2V0dXAgSS9PIHBhZ2Ug
dGFibGU6IGRldmljZSBpZCA9IDB4MGEwNCwgcm9vdCB0YWJsZSA9IDB4MjRkYTUzMDAwLCBk
b21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMNCihYRU4pIFsyMDEyLTA5LTAxIDIyOjI2OjUy
XSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweDBhMDUsIHJv
b3QgdGFibGUgPSAweDI0ZGE1MzAwMCwgZG9tYWluID0gMCwgcGFnaW5nIG1vZGUgPSAzDQoo
WEVOKSBbMjAxMi0wOS0wMSAyMjoyNjo1Ml0gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJs
ZTogZGV2aWNlIGlkID0gMHgwYTA2LCByb290IHRhYmxlID0gMHgyNGRhNTMwMDAsIGRvbWFp
biA9IDAsIHBhZ2luZyBtb2RlID0gMw0KKFhFTikgWzIwMTItMDktMDEgMjI6MjY6NTJdIEFN
RC1WaTogU2V0dXAgSS9PIHBhZ2UgdGFibGU6IGRldmljZSBpZCA9IDB4MGEwNywgcm9vdCB0
YWJsZSA9IDB4MjRkYTUzMDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMNCihYRU4p
IFsyMDEyLTA5LTAxIDIyOjI2OjUyXSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBk
ZXZpY2UgaWQgPSAweDBiMDAsIHJvb3QgdGFibGUgPSAweDI0ZGE1MzAwMCwgZG9tYWluID0g
MCwgcGFnaW5nIG1vZGUgPSAzDQooWEVOKSBbMjAxMi0wOS0wMSAyMjoyNjo1Ml0gU2NydWJi
aW5nIEZyZWUgUkFNOiAuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u
Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLmRvbmUuDQooWEVOKSBbMjAxMi0wOS0w
MSAyMjoyNjo1M10gSW5pdGlhbCBsb3cgbWVtb3J5IHZpcnEgdGhyZXNob2xkIHNldCBhdCAw
eDQwMDAgcGFnZXMuDQooWEVOKSBbMjAxMi0wOS0wMSAyMjoyNjo1M10gU3RkLiBMb2dsZXZl
bDogQWxsDQooWEVOKSBbMjAxMi0wOS0wMSAyMjoyNjo1NF0gR3Vlc3QgTG9nbGV2ZWw6IEFs
bA0KKFhFTikgWzIwMTItMDktMDEgMjI6MjY6NTRdIFhlbiBpcyByZWxpbnF1aXNoaW5nIFZH
QSBjb25zb2xlLg0KKFhFTikgWzIwMTItMDktMDEgMjI6MjY6NTRdICoqKiBTZXJpYWwgaW5w
dXQgLT4gRE9NMCAodHlwZSAnQ1RSTC1hJyB0aHJlZSB0aW1lcyB0byBzd2l0Y2ggaW5wdXQg
dG8gWGVuKQ0KKFhFTikgWzIwMTItMDktMDEgMjI6MjY6NTRdIEZyZWVkIDI1NmtCIGluaXQg
bWVtb3J5Lg0KKFhFTikgWzIwMTItMDktMDEgMjI6MjY6NTRdIElPQVBJQ1swXTogU2V0IFBD
SSByb3V0aW5nIGVudHJ5ICg2LTkgLT4gMHg2MCAtPiBJUlEgOSBNb2RlOjEgQWN0aXZlOjEp
DQooWEVOKSBbMjAxMi0wOS0wMSAyMjoyNjo1NF0gdHJhcHMuYzoyNTg0OmQwIERvbWFpbiBh
dHRlbXB0ZWQgV1JNU1IgMDAwMDAwMDBjMDAwMDQwOCBmcm9tIDB4YzAwMDAwMDAwMTAwMDAw
MCB0byAweGMwMDgwMDAwMDEwMDAwMDAuDQooWEVOKSBbMjAxMi0wOS0wMSAyMjoyNjo1NF0g
dHJhcHMuYzoyNTg0OmQwIERvbWFpbiBhdHRlbXB0ZWQgV1JNU1IgMDAwMDAwMDBjMDAwMDQw
OSBmcm9tIDB4YzAwMDAwMDAwMTAwMDAwMCB0byAweGMwMDgwMDAwMDEwMDAwMDAuDQooWEVO
KSBbMjAxMi0wOS0wMSAyMjoyNjo1NF0gdHJhcHMuYzoyNTg0OmQwIERvbWFpbiBhdHRlbXB0
ZWQgV1JNU1IgMDAwMDAwMDBjMDAxMDAwNCBmcm9tIDB4MDAwMGVmZjBiZGZiMWZjZSB0byAw
eDAwMDAwMDAwMDAwMGFiY2QuDQooWEVOKSBbMjAxMi0wOS0wMSAyMjoyNjo1NF0gdHJhcHMu
YzoyNTg0OmQwIERvbWFpbiBhdHRlbXB0ZWQgV1JNU1IgMDAwMDAwMDBjMDAwMDQwOCBmcm9t
IDB4YzAwMDAwMDAwMTAwMDAwMCB0byAweGMwMDgwMDAwMDEwMDAwMDAuDQooWEVOKSBbMjAx
Mi0wOS0wMSAyMjoyNjo1NF0gdHJhcHMuYzoyNTg0OmQwIERvbWFpbiBhdHRlbXB0ZWQgV1JN
U1IgMDAwMDAwMDBjMDAwMDQwOSBmcm9tIDB4YzAwMDAwMDAwMTAwMDAwMCB0byAweGMwMDgw
MDAwMDEwMDAwMDAuDQooWEVOKSBbMjAxMi0wOS0wMSAyMjoyNjo1NF0gdHJhcHMuYzoyNTg0
OmQwIERvbWFpbiBhdHRlbXB0ZWQgV1JNU1IgMDAwMDAwMDBjMDAwMDQwOCBmcm9tIDB4YzAw
MDAwMDAwMTAwMDAwMCB0byAweGMwMDgwMDAwMDEwMDAwMDAuDQooWEVOKSBbMjAxMi0wOS0w
MSAyMjoyNjo1NF0gdHJhcHMuYzoyNTg0OmQwIERvbWFpbiBhdHRlbXB0ZWQgV1JNU1IgMDAw
MDAwMDBjMDAwMDQwOSBmcm9tIDB4YzAwMDAwMDAwMTAwMDAwMCB0byAweGMwMDgwMDAwMDEw
MDAwMDAuDQooWEVOKSBbMjAxMi0wOS0wMSAyMjoyNjo1NF0gdHJhcHMuYzoyNTg0OmQwIERv
bWFpbiBhdHRlbXB0ZWQgV1JNU1IgMDAwMDAwMDBjMDAwMDQwOCBmcm9tIDB4YzAwMDAwMDAw
MTAwMDAwMCB0byAweGMwMDgwMDAwMDEwMDAwMDAuDQooWEVOKSBbMjAxMi0wOS0wMSAyMjoy
Njo1NF0gdHJhcHMuYzoyNTg0OmQwIERvbWFpbiBhdHRlbXB0ZWQgV1JNU1IgMDAwMDAwMDBj
MDAwMDQwOSBmcm9tIDB4YzAwMDAwMDAwMTAwMDAwMCB0byAweGMwMDgwMDAwMDEwMDAwMDAu
DQooWEVOKSBbMjAxMi0wOS0wMSAyMjoyNjo1NF0gdHJhcHMuYzoyNTg0OmQwIERvbWFpbiBh
dHRlbXB0ZWQgV1JNU1IgMDAwMDAwMDBjMDAwMDQwOCBmcm9tIDB4YzAwMDAwMDAwMTAwMDAw
MCB0byAweGMwMDgwMDAwMDEwMDAwMDAuDQooWEVOKSBbMjAxMi0wOS0wMSAyMjoyNjo1NF0g
dHJhcHMuYzoyNTg0OmQwIERvbWFpbiBhdHRlbXB0ZWQgV1JNU1IgMDAwMDAwMDBjMDAwMDQw
OSBmcm9tIDB4YzAwMDAwMDAwMTAwMDAwMCB0byAweGMwMDgwMDAwMDEwMDAwMDAuDQooWEVO
KSBbMjAxMi0wOS0wMSAyMjoyNjo1NF0gdHJhcHMuYzoyNTg0OmQwIERvbWFpbiBhdHRlbXB0
ZWQgV1JNU1IgMDAwMDAwMDBjMDAwMDQwOCBmcm9tIDB4YzAwMDAwMDAwMTAwMDAwMCB0byAw
eGMwMDgwMDAwMDEwMDAwMDAuDQooWEVOKSBbMjAxMi0wOS0wMSAyMjoyNjo1NF0gdHJhcHMu
YzoyNTg0OmQwIERvbWFpbiBhdHRlbXB0ZWQgV1JNU1IgMDAwMDAwMDBjMDAwMDQwOSBmcm9t
IDB4YzAwMDAwMDAwMTAwMDAwMCB0byAweGMwMDgwMDAwMDEwMDAwMDAuDQooWEVOKSBbMjAx
Mi0wOS0wMSAyMjoyNjo1NF0gUENJIGFkZCBkZXZpY2UgMDAwMDowMDowMC4wDQooWEVOKSBb
MjAxMi0wOS0wMSAyMjoyNjo1NF0gUENJIGFkZCBkZXZpY2UgMDAwMDowMDowMC4yDQooWEVO
KSBbMjAxMi0wOS0wMSAyMjoyNjo1NF0gUENJIGFkZCBkZXZpY2UgMDAwMDowMDowMi4wDQoo
WEVOKSBbMjAxMi0wOS0wMSAyMjoyNjo1NF0gUENJIGFkZCBkZXZpY2UgMDAwMDowMDowMy4w
DQooWEVOKSBbMjAxMi0wOS0wMSAyMjoyNjo1NF0gUENJIGFkZCBkZXZpY2UgMDAwMDowMDow
NS4wDQooWEVOKSBbMjAxMi0wOS0wMSAyMjoyNjo1NF0gUENJIGFkZCBkZXZpY2UgMDAwMDow
MDowNi4wDQooWEVOKSBbMjAxMi0wOS0wMSAyMjoyNjo1NF0gUENJIGFkZCBkZXZpY2UgMDAw
MDowMDowYS4wDQooWEVOKSBbMjAxMi0wOS0wMSAyMjoyNjo1NF0gUENJIGFkZCBkZXZpY2Ug
MDAwMDowMDowYi4wDQooWEVOKSBbMjAxMi0wOS0wMSAyMjoyNjo1NF0gUENJIGFkZCBkZXZp
Y2UgMDAwMDowMDowYy4wDQooWEVOKSBbMjAxMi0wOS0wMSAyMjoyNjo1NF0gUENJIGFkZCBk
ZXZpY2UgMDAwMDowMDowZC4wDQooWEVOKSBbMjAxMi0wOS0wMSAyMjoyNjo1NF0gUENJIGFk
ZCBkZXZpY2UgMDAwMDowMDoxMS4wDQooWEVOKSBbMjAxMi0wOS0wMSAyMjoyNjo1NF0gUENJ
IGFkZCBkZXZpY2UgMDAwMDowMDoxMi4wDQooWEVOKSBbMjAxMi0wOS0wMSAyMjoyNjo1NF0g
UENJIGFkZCBkZXZpY2UgMDAwMDowMDoxMi4yDQooWEVOKSBbMjAxMi0wOS0wMSAyMjoyNjo1
NF0gUENJIGFkZCBkZXZpY2UgMDAwMDowMDoxMy4wDQooWEVOKSBbMjAxMi0wOS0wMSAyMjoy
Njo1NF0gUENJIGFkZCBkZXZpY2UgMDAwMDowMDoxMy4yDQooWEVOKSBbMjAxMi0wOS0wMSAy
MjoyNjo1NF0gUENJIGFkZCBkZXZpY2UgMDAwMDowMDoxNC4wDQooWEVOKSBbMjAxMi0wOS0w
MSAyMjoyNjo1NF0gUENJIGFkZCBkZXZpY2UgMDAwMDowMDoxNC4zDQooWEVOKSBbMjAxMi0w
OS0wMSAyMjoyNjo1NF0gUENJIGFkZCBkZXZpY2UgMDAwMDowMDoxNC40DQooWEVOKSBbMjAx
Mi0wOS0wMSAyMjoyNjo1NF0gUENJIGFkZCBkZXZpY2UgMDAwMDowMDoxNC41DQooWEVOKSBb
MjAxMi0wOS0wMSAyMjoyNjo1NF0gUENJIGFkZCBkZXZpY2UgMDAwMDowMDoxNS4wDQooWEVO
KSBbMjAxMi0wOS0wMSAyMjoyNjo1NF0gUENJIGFkZCBkZXZpY2UgMDAwMDowMDoxNi4wDQoo
WEVOKSBbMjAxMi0wOS0wMSAyMjoyNjo1NF0gUENJIGFkZCBkZXZpY2UgMDAwMDowMDoxNi4y
DQooWEVOKSBbMjAxMi0wOS0wMSAyMjoyNjo1NF0gUENJIGFkZCBkZXZpY2UgMDAwMDowMDox
OC4wDQooWEVOKSBbMjAxMi0wOS0wMSAyMjoyNjo1NF0gUENJIGFkZCBkZXZpY2UgMDAwMDow
MDoxOC4xDQooWEVOKSBbMjAxMi0wOS0wMSAyMjoyNjo1NF0gUENJIGFkZCBkZXZpY2UgMDAw
MDowMDoxOC4yDQooWEVOKSBbMjAxMi0wOS0wMSAyMjoyNjo1NF0gUENJIGFkZCBkZXZpY2Ug
MDAwMDowMDoxOC4zDQooWEVOKSBbMjAxMi0wOS0wMSAyMjoyNjo1NF0gUENJIGFkZCBkZXZp
Y2UgMDAwMDowMDoxOC40DQooWEVOKSBbMjAxMi0wOS0wMSAyMjoyNjo1NF0gUENJIGFkZCBk
ZXZpY2UgMDAwMDowYjowMC4wDQooWEVOKSBbMjAxMi0wOS0wMSAyMjoyNjo1NF0gUENJIGFk
ZCBkZXZpY2UgMDAwMDowYTowMC4wDQooWEVOKSBbMjAxMi0wOS0wMSAyMjoyNjo1NF0gUENJ
IGFkZCBkZXZpY2UgMDAwMDowYTowMC4xDQooWEVOKSBbMjAxMi0wOS0wMSAyMjoyNjo1NF0g
UENJIGFkZCBkZXZpY2UgMDAwMDowYTowMC4yDQooWEVOKSBbMjAxMi0wOS0wMSAyMjoyNjo1
NF0gUENJIGFkZCBkZXZpY2UgMDAwMDowYTowMC4zDQooWEVOKSBbMjAxMi0wOS0wMSAyMjoy
Njo1NF0gUENJIGFkZCBkZXZpY2UgMDAwMDowYTowMC40DQooWEVOKSBbMjAxMi0wOS0wMSAy
MjoyNjo1NF0gUENJIGFkZCBkZXZpY2UgMDAwMDowYTowMC41DQooWEVOKSBbMjAxMi0wOS0w
MSAyMjoyNjo1NF0gUENJIGFkZCBkZXZpY2UgMDAwMDowYTowMC42DQooWEVOKSBbMjAxMi0w
OS0wMSAyMjoyNjo1NF0gUENJIGFkZCBkZXZpY2UgMDAwMDowYTowMC43DQooWEVOKSBbMjAx
Mi0wOS0wMSAyMjoyNjo1NF0gUENJIGFkZCBkZXZpY2UgMDAwMDowOTowMC4wDQooWEVOKSBb
MjAxMi0wOS0wMSAyMjoyNjo1NF0gUENJIGFkZCBkZXZpY2UgMDAwMDowODowMC4wDQooWEVO
KSBbMjAxMi0wOS0wMSAyMjoyNjo1NF0gUENJIGFkZCBkZXZpY2UgMDAwMDowNzowMC4wDQoo
WEVOKSBbMjAxMi0wOS0wMSAyMjoyNjo1NF0gUENJIGFkZCBkZXZpY2UgMDAwMDowNjowMC4w
DQooWEVOKSBbMjAxMi0wOS0wMSAyMjoyNjo1NF0gUENJIGFkZCBkZXZpY2UgMDAwMDowNjow
MC4xDQooWEVOKSBbMjAxMi0wOS0wMSAyMjoyNjo1NF0gUENJIGFkZCBkZXZpY2UgMDAwMDow
NTowMC4wDQooWEVOKSBbMjAxMi0wOS0wMSAyMjoyNjo1NF0gUENJIGFkZCBkZXZpY2UgMDAw
MDowNDowMC4wDQooWEVOKSBbMjAxMi0wOS0wMSAyMjoyNjo1NF0gUENJIGFkZCBkZXZpY2Ug
MDAwMDowNDowMC4xDQooWEVOKSBbMjAxMi0wOS0wMSAyMjoyNjo1NF0gUENJIGFkZCBkZXZp
Y2UgMDAwMDowNDowMC4yDQooWEVOKSBbMjAxMi0wOS0wMSAyMjoyNjo1NF0gUENJIGFkZCBk
ZXZpY2UgMDAwMDowNDowMC4zDQooWEVOKSBbMjAxMi0wOS0wMSAyMjoyNjo1NF0gUENJIGFk
ZCBkZXZpY2UgMDAwMDowNDowMC40DQooWEVOKSBbMjAxMi0wOS0wMSAyMjoyNjo1NF0gUENJ
IGFkZCBkZXZpY2UgMDAwMDowNDowMC41DQooWEVOKSBbMjAxMi0wOS0wMSAyMjoyNjo1NF0g
UENJIGFkZCBkZXZpY2UgMDAwMDowNDowMC42DQooWEVOKSBbMjAxMi0wOS0wMSAyMjoyNjo1
NF0gUENJIGFkZCBkZXZpY2UgMDAwMDowNDowMC43DQooWEVOKSBbMjAxMi0wOS0wMSAyMjoy
Njo1NF0gUENJIGFkZCBkZXZpY2UgMDAwMDowMzowNi4wDQooWEVOKSBbMjAxMi0wOS0wMSAy
MjoyNjo1NF0gSU9BUElDWzBdOiBTZXQgUENJIHJvdXRpbmcgZW50cnkgKDYtOCAtPiAweDU4
IC0+IElSUSA4IE1vZGU6MCBBY3RpdmU6MCkNCihYRU4pIFsyMDEyLTA5LTAxIDIyOjI2OjU0
XSBJT0FQSUNbMF06IFNldCBQQ0kgcm91dGluZyBlbnRyeSAoNi0xMyAtPiAweDg4IC0+IElS
USAxMyBNb2RlOjAgQWN0aXZlOjApDQooWEVOKSBbMjAxMi0wOS0wMSAyMjoyNjo1NF0gSU9B
UElDWzFdOiBTZXQgUENJIHJvdXRpbmcgZW50cnkgKDctMjggLT4gMHhhMCAtPiBJUlEgNTIg
TW9kZToxIEFjdGl2ZToxKQ0KKFhFTikgWzIwMTItMDktMDEgMjI6MjY6NTRdIElPQVBJQ1sx
XTogU2V0IFBDSSByb3V0aW5nIGVudHJ5ICg3LTI5IC0+IDB4YTggLT4gSVJRIDUzIE1vZGU6
MSBBY3RpdmU6MSkNCihYRU4pIFsyMDEyLTA5LTAxIDIyOjI2OjU0XSBJT0FQSUNbMV06IFNl
dCBQQ0kgcm91dGluZyBlbnRyeSAoNy0zMCAtPiAweGIwIC0+IElSUSA1NCBNb2RlOjEgQWN0
aXZlOjEpDQooWEVOKSBbMjAxMi0wOS0wMSAyMjoyNjo1NF0gSU9BUElDWzBdOiBTZXQgUENJ
IHJvdXRpbmcgZW50cnkgKDYtMTYgLT4gMHhiOCAtPiBJUlEgMTYgTW9kZToxIEFjdGl2ZTox
KQ0KKFhFTikgWzIwMTItMDktMDEgMjI6MjY6NTRdIElPQVBJQ1swXTogU2V0IFBDSSByb3V0
aW5nIGVudHJ5ICg2LTE4IC0+IDB4YzAgLT4gSVJRIDE4IE1vZGU6MSBBY3RpdmU6MSkNCihY
RU4pIFsyMDEyLTA5LTAxIDIyOjI2OjU0XSBJT0FQSUNbMF06IFNldCBQQ0kgcm91dGluZyBl
bnRyeSAoNi0xNyAtPiAweGM4IC0+IElSUSAxNyBNb2RlOjEgQWN0aXZlOjEpDQooWEVOKSBb
MjAxMi0wOS0wMSAyMjoyNjo1NF0gSU9BUElDWzFdOiBTZXQgUENJIHJvdXRpbmcgZW50cnkg
KDctNCAtPiAweGQwIC0+IElSUSAyOCBNb2RlOjEgQWN0aXZlOjEpDQooWEVOKSBbMjAxMi0w
OS0wMSAyMjoyNjo1NF0gSU9BUElDWzFdOiBTZXQgUENJIHJvdXRpbmcgZW50cnkgKDctNSAt
PiAweGQ4IC0+IElSUSAyOSBNb2RlOjEgQWN0aXZlOjEpDQooWEVOKSBbMjAxMi0wOS0wMSAy
MjoyNjo1NV0gSU9BUElDWzFdOiBTZXQgUENJIHJvdXRpbmcgZW50cnkgKDctNiAtPiAweDIx
IC0+IElSUSAzMCBNb2RlOjEgQWN0aXZlOjEpDQooWEVOKSBbMjAxMi0wOS0wMSAyMjoyNjo1
NV0gSU9BUElDWzFdOiBTZXQgUENJIHJvdXRpbmcgZW50cnkgKDctNyAtPiAweDI5IC0+IElS
USAzMSBNb2RlOjEgQWN0aXZlOjEpDQooWEVOKSBbMjAxMi0wOS0wMSAyMjoyNjo1NV0gSU9B
UElDWzFdOiBTZXQgUENJIHJvdXRpbmcgZW50cnkgKDctMTYgLT4gMHgzMSAtPiBJUlEgNDAg
TW9kZToxIEFjdGl2ZToxKQ0KKFhFTikgWzIwMTItMDktMDEgMjI6MjY6NTVdIElPQVBJQ1sx
XTogU2V0IFBDSSByb3V0aW5nIGVudHJ5ICg3LTE3IC0+IDB4MzkgLT4gSVJRIDQxIE1vZGU6
MSBBY3RpdmU6MSkNCihYRU4pIFsyMDEyLTA5LTAxIDIyOjI2OjU1XSBJT0FQSUNbMV06IFNl
dCBQQ0kgcm91dGluZyBlbnRyeSAoNy0xOCAtPiAweDQxIC0+IElSUSA0MiBNb2RlOjEgQWN0
aXZlOjEpDQooWEVOKSBbMjAxMi0wOS0wMSAyMjoyNjo1NV0gSU9BUElDWzFdOiBTZXQgUENJ
IHJvdXRpbmcgZW50cnkgKDctMTkgLT4gMHg0OSAtPiBJUlEgNDMgTW9kZToxIEFjdGl2ZTox
KQ0KKFhFTikgWzIwMTItMDktMDEgMjI6MjY6NTVdIElPQVBJQ1swXTogU2V0IFBDSSByb3V0
aW5nIGVudHJ5ICg2LTIyIC0+IDB4OTkgLT4gSVJRIDIyIE1vZGU6MSBBY3RpdmU6MSkNCihY
RU4pIFsyMDEyLTA5LTAxIDIyOjI2OjU1XSBJT0FQSUNbMV06IFNldCBQQ0kgcm91dGluZyBl
bnRyeSAoNy0xMiAtPiAweGExIC0+IElSUSAzNiBNb2RlOjEgQWN0aXZlOjEpDQooWEVOKSBb
MjAxMi0wOS0wMSAyMjoyNjo1NV0gSU9BUElDWzFdOiBTZXQgUENJIHJvdXRpbmcgZW50cnkg
KDctMjMgLT4gMHhhOSAtPiBJUlEgNDcgTW9kZToxIEFjdGl2ZToxKQ0KKFhFTikgWzIwMTIt
MDktMDEgMjI6MjY6NTZdIElPQVBJQ1swXTogU2V0IFBDSSByb3V0aW5nIGVudHJ5ICg2LTE5
IC0+IDB4YjEgLT4gSVJRIDE5IE1vZGU6MSBBY3RpdmU6MSkNCihYRU4pIFsyMDEyLTA5LTAx
IDIyOjI2OjU2XSBJT0FQSUNbMV06IFNldCBQQ0kgcm91dGluZyBlbnRyeSAoNy0yMiAtPiAw
eGMxIC0+IElSUSA0NiBNb2RlOjEgQWN0aXZlOjEpDQooWEVOKSBbMjAxMi0wOS0wMSAyMjoy
Njo1Nl0gSU9BUElDWzFdOiBTZXQgUENJIHJvdXRpbmcgZW50cnkgKDctMjcgLT4gMHhkMSAt
PiBJUlEgNTEgTW9kZToxIEFjdGl2ZToxKQ0KKFhFTikgWzIwMTItMDktMDEgMjI6MjY6NThd
IElPQVBJQ1sxXTogU2V0IFBDSSByb3V0aW5nIGVudHJ5ICg3LTkgLT4gMHgyMiAtPiBJUlEg
MzMgTW9kZToxIEFjdGl2ZToxKQ0KKFhFTikgWzIwMTItMDktMDEgMjI6Mjc6NTldIHRyYXBz
LmM6MjU4NDpkMSBEb21haW4gYXR0ZW1wdGVkIFdSTVNSIDAwMDAwMDAwYzAwMTAwMDQgZnJv
bSAweDAwMDBhMTk1YzQwZjYxOGYgdG8gMHgwMDAwMDAwMDAwMDBhYmNkLg0KKFhFTikgWzIw
MTItMDktMDEgMjI6Mjg6MDVdIHRyYXBzLmM6MjU4NDpkMiBEb21haW4gYXR0ZW1wdGVkIFdS
TVNSIDAwMDAwMDAwYzAwMTAwMDQgZnJvbSAweDAwMDA2ZmIwMzlkZTc5MDAgdG8gMHgwMDAw
MDAwMDAwMDBhYmNkLg0KKFhFTikgWzIwMTItMDktMDEgMjI6Mjg6MTddIHRyYXBzLmM6MjU4
NDpkMyBEb21haW4gYXR0ZW1wdGVkIFdSTVNSIDAwMDAwMDAwYzAwMTAwMDQgZnJvbSAweDAw
MDBhMTk1YzQwZjYxOGYgdG8gMHgwMDAwMDAwMDAwMDBhYmNkLg0KKFhFTikgWzIwMTItMDkt
MDEgMjI6Mjg6MTddIHRyYXBzLmM6MjU4NDpkNCBEb21haW4gYXR0ZW1wdGVkIFdSTVNSIDAw
MDAwMDAwYzAwMTAwMDQgZnJvbSAweDAwMDA4Njc5YzAyYjQxNjUgdG8gMHgwMDAwMDAwMDAw
MDBhYmNkLg0KKFhFTikgWzIwMTItMDktMDEgMjI6Mjg6MjNdIHRyYXBzLmM6MjU4NDpkNSBE
b21haW4gYXR0ZW1wdGVkIFdSTVNSIDAwMDAwMDAwYzAwMTAwMDQgZnJvbSAweDAwMDA2ZmIw
MzlkZTc5MDAgdG8gMHgwMDAwMDAwMDAwMDBhYmNkLg0KKFhFTikgWzIwMTItMDktMDEgMjI6
Mjg6MzBdIHRyYXBzLmM6MjU4NDpkNiBEb21haW4gYXR0ZW1wdGVkIFdSTVNSIDAwMDAwMDAw
YzAwMTAwMDQgZnJvbSAweDAwMDBhMTk1YzQwZjYxOGYgdG8gMHgwMDAwMDAwMDAwMDBhYmNk
Lg0KKFhFTikgWzIwMTItMDktMDEgMjI6Mjg6MzZdIHRyYXBzLmM6MjU4NDpkNyBEb21haW4g
YXR0ZW1wdGVkIFdSTVNSIDAwMDAwMDAwYzAwMTAwMDQgZnJvbSAweDAwMDBhMTk1YzQwZjYx
OGYgdG8gMHgwMDAwMDAwMDAwMDBhYmNkLg0KKFhFTikgWzIwMTItMDktMDEgMjI6Mjg6NDJd
IHRyYXBzLmM6MjU4NDpkOCBEb21haW4gYXR0ZW1wdGVkIFdSTVNSIDAwMDAwMDAwYzAwMTAw
MDQgZnJvbSAweDAwMDA2ZmIwMzlkZTc5MDAgdG8gMHgwMDAwMDAwMDAwMDBhYmNkLg0KKFhF
TikgWzIwMTItMDktMDEgMjI6Mjg6NDhdIHRyYXBzLmM6MjU4NDpkOSBEb21haW4gYXR0ZW1w
dGVkIFdSTVNSIDAwMDAwMDAwYzAwMTAwMDQgZnJvbSAweDAwMDBhMTk1YzQwZjYxOGYgdG8g
MHgwMDAwMDAwMDAwMDBhYmNkLg0KKFhFTikgWzIwMTItMDktMDEgMjI6Mjg6NTVdIHRyYXBz
LmM6MjU4NDpkMTAgRG9tYWluIGF0dGVtcHRlZCBXUk1TUiAwMDAwMDAwMGMwMDEwMDA0IGZy
b20gMHgwMDAwNmZiMDM5ZGU3OTAwIHRvIDB4MDAwMDAwMDAwMDAwYWJjZC4NCihYRU4pIFsy
MDEyLTA5LTAxIDIyOjI5OjAyXSBBTUQtVmk6IERpc2FibGU6IGRldmljZSBpZCA9IDB4MDBh
NCwgZG9tYWluID0gMCwgcGFnaW5nIG1vZGUgPSAzDQooWEVOKSBbMjAxMi0wOS0wMSAyMjoy
OTowMl0gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHgwMGE0
LCByb290IHRhYmxlID0gMHgxOGUwYTEwMDAsIGRvbWFpbiA9IDExLCBwYWdpbmcgbW9kZSA9
IDMNCihYRU4pIFsyMDEyLTA5LTAxIDIyOjI5OjAyXSBBTUQtVmk6IFJlLWFzc2lnbiAwMDAw
OjAzOjA2LjAgZnJvbSBkb20wIHRvIGRvbTExDQooWEVOKSBbMjAxMi0wOS0wMSAyMjoyOTow
Ml0gdHJhcHMuYzoyNTg0OmQxMSBEb21haW4gYXR0ZW1wdGVkIFdSTVNSIDAwMDAwMDAwYzAw
MTAwMDQgZnJvbSAweDAwMDA4Njc5YzAyYjQxNjUgdG8gMHgwMDAwMDAwMDAwMDBhYmNkLg0K
KFhFTikgWzIwMTItMDktMDEgMjI6Mjk6MDhdIHRyYXBzLmM6MjU4NDpkMTIgRG9tYWluIGF0
dGVtcHRlZCBXUk1TUiAwMDAwMDAwMGMwMDEwMDA0IGZyb20gMHgwMDAwNDIzNDVhMGRhNTQ1
IHRvIDB4MDAwMDAwMDAwMDAwYWJjZC4NCihYRU4pIFsyMDEyLTA5LTAxIDIyOjI5OjE1XSB0
cmFwcy5jOjI1ODQ6ZDEzIERvbWFpbiBhdHRlbXB0ZWQgV1JNU1IgMDAwMDAwMDBjMDAxMDAw
NCBmcm9tIDB4MDAwMDZmYjAzOWRlNzkwMCB0byAweDAwMDAwMDAwMDAwMGFiY2QuDQooWEVO
KSBbMjAxMi0wOS0wMSAyMjoyOToyM10gQU1ELVZpOiBEaXNhYmxlOiBkZXZpY2UgaWQgPSAw
eDBhMDAsIGRvbWFpbiA9IDAsIHBhZ2luZyBtb2RlID0gMw0KKFhFTikgWzIwMTItMDktMDEg
MjI6Mjk6MjNdIEFNRC1WaTogU2V0dXAgSS9PIHBhZ2UgdGFibGU6IGRldmljZSBpZCA9IDB4
MGEwMCwgcm9vdCB0YWJsZSA9IDB4MWUxZmMwMDAwLCBkb21haW4gPSAxNCwgcGFnaW5nIG1v
ZGUgPSAzDQooWEVOKSBbMjAxMi0wOS0wMSAyMjoyOToyM10gQU1ELVZpOiBSZS1hc3NpZ24g
MDAwMDowYTowMC4wIGZyb20gZG9tMCB0byBkb20xNA0KKFhFTikgWzIwMTItMDktMDEgMjI6
Mjk6MjNdIEFNRC1WaTogRGlzYWJsZTogZGV2aWNlIGlkID0gMHgwYTAxLCBkb21haW4gPSAw
LCBwYWdpbmcgbW9kZSA9IDMNCihYRU4pIFsyMDEyLTA5LTAxIDIyOjI5OjIzXSBBTUQtVmk6
IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweDBhMDEsIHJvb3QgdGFibGUg
PSAweDFlMWZjMDAwMCwgZG9tYWluID0gMTQsIHBhZ2luZyBtb2RlID0gMw0KKFhFTikgWzIw
MTItMDktMDEgMjI6Mjk6MjNdIEFNRC1WaTogUmUtYXNzaWduIDAwMDA6MGE6MDAuMSBmcm9t
IGRvbTAgdG8gZG9tMTQNCihYRU4pIFsyMDEyLTA5LTAxIDIyOjI5OjIzXSBBTUQtVmk6IERp
c2FibGU6IGRldmljZSBpZCA9IDB4MGEwMiwgZG9tYWluID0gMCwgcGFnaW5nIG1vZGUgPSAz
DQooWEVOKSBbMjAxMi0wOS0wMSAyMjoyOToyM10gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0
YWJsZTogZGV2aWNlIGlkID0gMHgwYTAyLCByb290IHRhYmxlID0gMHgxZTFmYzAwMDAsIGRv
bWFpbiA9IDE0LCBwYWdpbmcgbW9kZSA9IDMNCihYRU4pIFsyMDEyLTA5LTAxIDIyOjI5OjIz
XSBBTUQtVmk6IFJlLWFzc2lnbiAwMDAwOjBhOjAwLjIgZnJvbSBkb20wIHRvIGRvbTE0DQoo
WEVOKSBbMjAxMi0wOS0wMSAyMjoyOToyM10gQU1ELVZpOiBEaXNhYmxlOiBkZXZpY2UgaWQg
PSAweDBhMDMsIGRvbWFpbiA9IDAsIHBhZ2luZyBtb2RlID0gMw0KKFhFTikgWzIwMTItMDkt
MDEgMjI6Mjk6MjNdIEFNRC1WaTogU2V0dXAgSS9PIHBhZ2UgdGFibGU6IGRldmljZSBpZCA9
IDB4MGEwMywgcm9vdCB0YWJsZSA9IDB4MWUxZmMwMDAwLCBkb21haW4gPSAxNCwgcGFnaW5n
IG1vZGUgPSAzDQooWEVOKSBbMjAxMi0wOS0wMSAyMjoyOToyM10gQU1ELVZpOiBSZS1hc3Np
Z24gMDAwMDowYTowMC4zIGZyb20gZG9tMCB0byBkb20xNA0KKFhFTikgWzIwMTItMDktMDEg
MjI6Mjk6MjNdIEFNRC1WaTogRGlzYWJsZTogZGV2aWNlIGlkID0gMHgwYTA0LCBkb21haW4g
PSAwLCBwYWdpbmcgbW9kZSA9IDMNCihYRU4pIFsyMDEyLTA5LTAxIDIyOjI5OjIzXSBBTUQt
Vmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweDBhMDQsIHJvb3QgdGFi
bGUgPSAweDFlMWZjMDAwMCwgZG9tYWluID0gMTQsIHBhZ2luZyBtb2RlID0gMw0KKFhFTikg
WzIwMTItMDktMDEgMjI6Mjk6MjNdIEFNRC1WaTogUmUtYXNzaWduIDAwMDA6MGE6MDAuNCBm
cm9tIGRvbTAgdG8gZG9tMTQNCihYRU4pIFsyMDEyLTA5LTAxIDIyOjI5OjIzXSBBTUQtVmk6
IERpc2FibGU6IGRldmljZSBpZCA9IDB4MGEwNSwgZG9tYWluID0gMCwgcGFnaW5nIG1vZGUg
PSAzDQooWEVOKSBbMjAxMi0wOS0wMSAyMjoyOToyM10gQU1ELVZpOiBTZXR1cCBJL08gcGFn
ZSB0YWJsZTogZGV2aWNlIGlkID0gMHgwYTA1LCByb290IHRhYmxlID0gMHgxZTFmYzAwMDAs
IGRvbWFpbiA9IDE0LCBwYWdpbmcgbW9kZSA9IDMNCihYRU4pIFsyMDEyLTA5LTAxIDIyOjI5
OjIzXSBBTUQtVmk6IFJlLWFzc2lnbiAwMDAwOjBhOjAwLjUgZnJvbSBkb20wIHRvIGRvbTE0
DQooWEVOKSBbMjAxMi0wOS0wMSAyMjoyOToyM10gQU1ELVZpOiBEaXNhYmxlOiBkZXZpY2Ug
aWQgPSAweDBhMDYsIGRvbWFpbiA9IDAsIHBhZ2luZyBtb2RlID0gMw0KKFhFTikgWzIwMTIt
MDktMDEgMjI6Mjk6MjNdIEFNRC1WaTogU2V0dXAgSS9PIHBhZ2UgdGFibGU6IGRldmljZSBp
ZCA9IDB4MGEwNiwgcm9vdCB0YWJsZSA9IDB4MWUxZmMwMDAwLCBkb21haW4gPSAxNCwgcGFn
aW5nIG1vZGUgPSAzDQooWEVOKSBbMjAxMi0wOS0wMSAyMjoyOToyM10gQU1ELVZpOiBSZS1h
c3NpZ24gMDAwMDowYTowMC42IGZyb20gZG9tMCB0byBkb20xNA0KKFhFTikgWzIwMTItMDkt
MDEgMjI6Mjk6MjNdIEFNRC1WaTogRGlzYWJsZTogZGV2aWNlIGlkID0gMHgwYTA3LCBkb21h
aW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMNCihYRU4pIFsyMDEyLTA5LTAxIDIyOjI5OjIzXSBB
TUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweDBhMDcsIHJvb3Qg
dGFibGUgPSAweDFlMWZjMDAwMCwgZG9tYWluID0gMTQsIHBhZ2luZyBtb2RlID0gMw0KKFhF
TikgWzIwMTItMDktMDEgMjI6Mjk6MjNdIEFNRC1WaTogUmUtYXNzaWduIDAwMDA6MGE6MDAu
NyBmcm9tIGRvbTAgdG8gZG9tMTQNCihYRU4pIFsyMDEyLTA5LTAxIDIyOjI5OjIzXSBBTUQt
Vmk6IERpc2FibGU6IGRldmljZSBpZCA9IDB4MDcwMCwgZG9tYWluID0gMCwgcGFnaW5nIG1v
ZGUgPSAzDQooWEVOKSBbMjAxMi0wOS0wMSAyMjoyOToyM10gQU1ELVZpOiBTZXR1cCBJL08g
cGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHgwNzAwLCByb290IHRhYmxlID0gMHgxZTFmYzAw
MDAsIGRvbWFpbiA9IDE0LCBwYWdpbmcgbW9kZSA9IDMNCihYRU4pIFsyMDEyLTA5LTAxIDIy
OjI5OjIzXSBBTUQtVmk6IFJlLWFzc2lnbiAwMDAwOjA3OjAwLjAgZnJvbSBkb20wIHRvIGRv
bTE0DQooWEVOKSBbMjAxMi0wOS0wMSAyMjoyOToyM10gdHJhcHMuYzoyNTg0OmQxNCBEb21h
aW4gYXR0ZW1wdGVkIFdSTVNSIDAwMDAwMDAwYzAwMTAwMDQgZnJvbSAweDAwMDA2ZmIwMzlk
ZTc5MDAgdG8gMHgwMDAwMDAwMDAwMDBhYmNkLg0KKFhFTikgWzIwMTItMDktMDEgMjI6Mjk6
MjldIHRyYXBzLmM6MjU4NDpkMTUgRG9tYWluIGF0dGVtcHRlZCBXUk1TUiAwMDAwMDAwMGMw
MDEwMDA0IGZyb20gMHgwMDAwNmZiMDM5ZGU3OTAwIHRvIDB4MDAwMDAwMDAwMDAwYWJjZC4N
CihYRU4pIFsyMDEyLTA5LTAxIDIzOjA1OjE5XSBncmFudF90YWJsZS5jOjI1NDpkMCBJbmNy
ZWFzZWQgbWFwdHJhY2sgc2l6ZSB0byAyIGZyYW1lcw0KKFhFTikgWzIwMTItMDktMDIgMDA6
MTg6MzZdIEFNRC1WaTogSU9fUEFHRV9GQVVMVDogZG9tYWluID0gMTQsIGRldmljZSBpZCA9
IDB4MDcwMCwgZmF1bHQgYWRkcmVzcyA9IDB4YThlZDA3ZTANCihYRU4pIFsyMDEyLTA5LTAy
IDAwOjE4OjM2XSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDE0LCBkZXZpY2Ug
aWQgPSAweDA3MDAsIGZhdWx0IGFkZHJlc3MgPSAweGE4ZWQwODAwDQooWEVOKSBbMjAxMi0w
OS0wMiAwMDoxODozNl0gQU1ELVZpOiBJT19QQUdFX0ZBVUxUOiBkb21haW4gPSAxNCwgZGV2
aWNlIGlkID0gMHgwNzAwLCBmYXVsdCBhZGRyZXNzID0gMHhhOGVkMDg0MA0KKFhFTikgWzIw
MTItMDktMDIgMDA6MTg6MzZdIEFNRC1WaTogSU9fUEFHRV9GQVVMVDogZG9tYWluID0gMTQs
IGRldmljZSBpZCA9IDB4MDcwMCwgZmF1bHQgYWRkcmVzcyA9IDB4YThlZDA4NjANCihYRU4p
IFsyMDEyLTA5LTAyIDAwOjE4OjM2XSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9
IDE0LCBkZXZpY2UgaWQgPSAweDA3MDAsIGZhdWx0IGFkZHJlc3MgPSAweGE4ZWQwOGMwDQoo
WEVOKSBbMjAxMi0wOS0wMiAwMDoxODozNl0gQU1ELVZpOiBJT19QQUdFX0ZBVUxUOiBkb21h
aW4gPSAxNCwgZGV2aWNlIGlkID0gMHgwNzAwLCBmYXVsdCBhZGRyZXNzID0gMHhhOGVkMDg4
MA0KKFhFTikgWzIwMTItMDktMDIgMDA6MTg6MzZdIEFNRC1WaTogSU9fUEFHRV9GQVVMVDog
ZG9tYWluID0gMTQsIGRldmljZSBpZCA9IDB4MDcwMCwgZmF1bHQgYWRkcmVzcyA9IDB4YThl
ZDBjMDANCihYRU4pIFsyMDEyLTA5LTAyIDAwOjE4OjM2XSBBTUQtVmk6IElPX1BBR0VfRkFV
TFQ6IGRvbWFpbiA9IDE0LCBkZXZpY2UgaWQgPSAweDA3MDAsIGZhdWx0IGFkZHJlc3MgPSAw
eGE4ZWQwYjYwDQooWEVOKSBbMjAxMi0wOS0wMiAwMDoxODozNl0gQU1ELVZpOiBJT19QQUdF
X0ZBVUxUOiBkb21haW4gPSAxNCwgZGV2aWNlIGlkID0gMHgwNzAwLCBmYXVsdCBhZGRyZXNz
ID0gMHhhOGVkMGEwMA0KKFhFTikgWzIwMTItMDktMDIgMDA6MTg6MzZdIEFNRC1WaTogSU9f
UEFHRV9GQVVMVDogZG9tYWluID0gMTQsIGRldmljZSBpZCA9IDB4MDcwMCwgZmF1bHQgYWRk
cmVzcyA9IDB4YThlZDBjNjANCihYRU4pIFsyMDEyLTA5LTAyIDAwOjE4OjM2XSBBTUQtVmk6
IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDE0LCBkZXZpY2UgaWQgPSAweDA3MDAsIGZhdWx0
IGFkZHJlc3MgPSAweGE4ZWQwYTQwDQooWEVOKSBbMjAxMi0wOS0wMiAwMDoxODozNl0gQU1E
LVZpOiBJT19QQUdFX0ZBVUxUOiBkb21haW4gPSAxNCwgZGV2aWNlIGlkID0gMHgwNzAwLCBm
YXVsdCBhZGRyZXNzID0gMHhhOGVkMGM4MA0KKFhFTikgWzIwMTItMDktMDIgMDA6MTg6MzZd
IEFNRC1WaTogSU9fUEFHRV9GQVVMVDogZG9tYWluID0gMTQsIGRldmljZSBpZCA9IDB4MDcw
MCwgZmF1bHQgYWRkcmVzcyA9IDB4YThlZDA4ZTANCihYRU4pIFsyMDEyLTA5LTAyIDAwOjE4
OjM2XSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDE0LCBkZXZpY2UgaWQgPSAw
eDA3MDAsIGZhdWx0IGFkZHJlc3MgPSAweGE4ZWQwYjgwDQooWEVOKSBbMjAxMi0wOS0wMiAw
MDoxODozNl0gQU1ELVZpOiBJT19QQUdFX0ZBVUxUOiBkb21haW4gPSAxNCwgZGV2aWNlIGlk
ID0gMHgwNzAwLCBmYXVsdCBhZGRyZXNzID0gMHhhOGVkMGE2MA0KKFhFTikgWzIwMTItMDkt
MDIgMDA6MTg6MzZdIEFNRC1WaTogSU9fUEFHRV9GQVVMVDogZG9tYWluID0gMTQsIGRldmlj
ZSBpZCA9IDB4MDcwMCwgZmF1bHQgYWRkcmVzcyA9IDB4YThlZDBiYzANCihYRU4pIFsyMDEy
LTA5LTAyIDAwOjE4OjM2XSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDE0LCBk
ZXZpY2UgaWQgPSAweDA3MDAsIGZhdWx0IGFkZHJlc3MgPSAweGE4ZWQwYmUwDQooWEVOKSBb
MjAxMi0wOS0wMiAwMDoxODozNl0gQU1ELVZpOiBJT19QQUdFX0ZBVUxUOiBkb21haW4gPSAx
NCwgZGV2aWNlIGlkID0gMHgwNzAwLCBmYXVsdCBhZGRyZXNzID0gMHhhOGVkMGE4MA0KKFhF
TikgWzIwMTItMDktMDIgMDA6MTg6MzZdIEFNRC1WaTogSU9fUEFHRV9GQVVMVDogZG9tYWlu
ID0gMTQsIGRldmljZSBpZCA9IDB4MDcwMCwgZmF1bHQgYWRkcmVzcyA9IDB4YThlZDBjNDAN
CihYRU4pIFsyMDEyLTA5LTAyIDAwOjE4OjM2XSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRv
bWFpbiA9IDE0LCBkZXZpY2UgaWQgPSAweDA3MDAsIGZhdWx0IGFkZHJlc3MgPSAweGE4ZWQw
YWUwDQooWEVOKSBbMjAxMi0wOS0wMiAwMDoxODozNl0gQU1ELVZpOiBJT19QQUdFX0ZBVUxU
OiBkb21haW4gPSAxNCwgZGV2aWNlIGlkID0gMHgwNzAwLCBmYXVsdCBhZGRyZXNzID0gMHhh
OGVkMDllMA0KKFhFTikgWzIwMTItMDktMDIgMDA6MTg6MzZdIEFNRC1WaTogSU9fUEFHRV9G
QVVMVDogZG9tYWluID0gMTQsIGRldmljZSBpZCA9IDB4MDcwMCwgZmF1bHQgYWRkcmVzcyA9
IDB4YThlZDA5ODANCihYRU4pIFsyMDEyLTA5LTAyIDAwOjE4OjM2XSBBTUQtVmk6IElPX1BB
R0VfRkFVTFQ6IGRvbWFpbiA9IDE0LCBkZXZpY2UgaWQgPSAweDA3MDAsIGZhdWx0IGFkZHJl
c3MgPSAweGE4ZWQwOWMwDQooWEVOKSBbMjAxMi0wOS0wMiAwMDoxODozNl0gQU1ELVZpOiBJ
T19QQUdFX0ZBVUxUOiBkb21haW4gPSAxNCwgZGV2aWNlIGlkID0gMHgwNzAwLCBmYXVsdCBh
ZGRyZXNzID0gMHhhOGVkMGI0MA0KKFhFTikgWzIwMTItMDktMDIgMDA6MTg6MzZdIEFNRC1W
aTogSU9fUEFHRV9GQVVMVDogZG9tYWluID0gMTQsIGRldmljZSBpZCA9IDB4MDcwMCwgZmF1
bHQgYWRkcmVzcyA9IDB4YThlZDBiMDANCihYRU4pIFsyMDEyLTA5LTAyIDAwOjE4OjM2XSBB
TUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDE0LCBkZXZpY2UgaWQgPSAweDA3MDAs
IGZhdWx0IGFkZHJlc3MgPSAweGE4ZWQwY2MwDQooWEVOKSBbMjAxMi0wOS0wMiAwMDoxODoz
Nl0gQU1ELVZpOiBJT19QQUdFX0ZBVUxUOiBkb21haW4gPSAxNCwgZGV2aWNlIGlkID0gMHgw
NzAwLCBmYXVsdCBhZGRyZXNzID0gMHhhOGVkMDk0MA0KKFhFTikgWzIwMTItMDktMDIgMDA6
MTg6MzZdIEFNRC1WaTogSU9fUEFHRV9GQVVMVDogZG9tYWluID0gMTQsIGRldmljZSBpZCA9
IDB4MDcwMCwgZmF1bHQgYWRkcmVzcyA9IDB4YThlZDBhYzANCihYRU4pIFsyMDEyLTA5LTAy
IDAwOjE4OjM2XSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDE0LCBkZXZpY2Ug
aWQgPSAweDA3MDAsIGZhdWx0IGFkZHJlc3MgPSAweGE4ZWQwOTAwDQooWEVOKSBbMjAxMi0w
OS0wMiAwMDoxODozNl0gQU1ELVZpOiBJT19QQUdFX0ZBVUxUOiBkb21haW4gPSAxNCwgZGV2
aWNlIGlkID0gMHgwNzAwLCBmYXVsdCBhZGRyZXNzID0gMHhhOGVkMDk2MA0KKFhFTikgWzIw
MTItMDktMDIgMDA6MTg6MzZdIEFNRC1WaTogSU9fUEFHRV9GQVVMVDogZG9tYWluID0gMTQs
IGRldmljZSBpZCA9IDB4MDcwMCwgZmF1bHQgYWRkcmVzcyA9IDB4YThlZDBjZTANCihYRU4p
IFsyMDEyLTA5LTAyIDAwOjE4OjM2XSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9
IDE0LCBkZXZpY2UgaWQgPSAweDA3MDAsIGZhdWx0IGFkZHJlc3MgPSAweGE4ZWQwZDQwDQoo
WEVOKSBbMjAxMi0wOS0wMiAwMDoxODozNl0gQU1ELVZpOiBJT19QQUdFX0ZBVUxUOiBkb21h
aW4gPSAxNCwgZGV2aWNlIGlkID0gMHgwNzAwLCBmYXVsdCBhZGRyZXNzID0gMHhhOGVkMGQw
MA0KKFhFTikgWzIwMTItMDktMDIgMDA6MTg6MzZdIEFNRC1WaTogSU9fUEFHRV9GQVVMVDog
ZG9tYWluID0gMTQsIGRldmljZSBpZCA9IDB4MDcwMCwgZmF1bHQgYWRkcmVzcyA9IDB4YThl
ZDBkNjANCihYRU4pIFsyMDEyLTA5LTAyIDAwOjU1OjAyXSB0cmFwcy5jOjMxNTY6IEdQRiAo
MDA2MCk6IGZmZmY4MmM0ODAxNWM5ZWUgLT4gZmZmZjgyYzQ4MDIyNGIxMw0KKFhFTikgWzIw
MTItMDktMDIgMDQ6MjE6MjNdIEFNRC1WaTogSU9fUEFHRV9GQVVMVDogZG9tYWluID0gMTQs
IGRldmljZSBpZCA9IDB4MGEwNiwgZmF1bHQgYWRkcmVzcyA9IDB4YTliMGYwODANCihYRU4p
IFsyMDEyLTA5LTAyIDA0OjIxOjIzXSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9
IDE0LCBkZXZpY2UgaWQgPSAweDBhMDYsIGZhdWx0IGFkZHJlc3MgPSAweGE5YjBmMDQwDQo=
------------03516D00221173D65
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

------------03516D00221173D65--



From xen-devel-bounces@lists.xen.org Sun Sep 02 14:59:48 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 02 Sep 2012 14:59:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T8Bdn-00089b-Js; Sun, 02 Sep 2012 14:59:11 +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 1T8Bdl-00089T-RI
	for xen-devel@lists.xen.org; Sun, 02 Sep 2012 14:59:10 +0000
Received: from [85.158.139.83:9817] by server-5.bemta-5.messagelabs.com id
	4A/54-30514-D3473405; Sun, 02 Sep 2012 14:59:09 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1346597946!23871711!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-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1183 invoked from network); 2 Sep 2012 14:59:07 -0000
Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com)
	(74.125.83.45)
	by server-14.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Sep 2012 14:59:07 -0000
Received: by eeke53 with SMTP id e53so1822412eek.32
	for <xen-devel@lists.xen.org>; Sun, 02 Sep 2012 07:59:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=cxbObWqzfKpGgJQIedRktVC+MyWwal42nEHioXLnv4U=;
	b=s6p0GnX8a9op8Vom9G5bcv0EQwgmqP02sUIE74gAil+3q9GesSMng163pur3uz+T+6
	mBUN9LaxrH4kN/Ozn3x8zzxi1dPnwPb5YQVHus9MZi1V5Fq9VmD9GWLyQyCQKSwaub1B
	YymMXrH0+hhiDz+wjh1mGbImVL0S/BcCjsEI1Z/frjmxjlJB1aLl9abY10lLZZKqKW10
	AsrmkwWpb2FMY1w6axLhEsrTY5XNGPEd63zA1gxKrGP1nl22VHnhTjGTRJoUD05cgYRf
	DCdP3INd78sqGDlZXVorWFSPoCQm0OQTrmByPL5niSGF/I/pd6O7H5/GIlgSaXoRawYs
	+A2w==
Received: by 10.14.4.201 with SMTP id 49mr17953608eej.0.1346597946743;
	Sun, 02 Sep 2012 07:59:06 -0700 (PDT)
Received: from [192.168.1.69] (host86-184-74-117.range86-184.btcentralplus.com.
	[86.184.74.117])
	by mx.google.com with ESMTPS id 45sm28739266eeb.8.2012.09.02.07.59.02
	(version=SSLv3 cipher=OTHER); Sun, 02 Sep 2012 07:59:06 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Sun, 02 Sep 2012 15:58:58 +0100
From: Keir Fraser <keir.xen@gmail.com>
To: Sander Eikelenboom <linux@eikelenboom.it>
Message-ID: <CC6932C2.3D99D%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] Using debug-key 'o:  Dump IOMMU p2m table, locks up
	machine
Thread-Index: Ac2JG3q9vAd49JMnbUy0lmDWqo6J3w==
In-Reply-To: <40501859.20120902104331@eikelenboom.it>
Mime-version: 1.0
Cc: "wei.wang2@amd.com" <wei.wang2@amd.com>,
	Santosh Jodh <Santosh.Jodh@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Using debug-key 'o:  Dump IOMMU p2m table,
 locks up machine
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 02/09/2012 09:43, "Sander Eikelenboom" <linux@eikelenboom.it> wrote:

>> Quite simply, there likely needs to be more tracing on the IOMMU fault path.
>> That's a separate concern from your keyhandler of course, but just saying
>> I'd be looking for the former rather than the latter, for diagnosing
>> Sander's bug.
> 
> Are there any printk's I could add to get more relevant info about the AMD-Vi:
> IO_PAGE_FAULT ?

No really straightforward one. I think we need a per-IOMMU-type handler to
walk the IOMMU page table for a given virtual address, and dump every
page-table-entry on the path. Like an IOMMU version of show_page_walk().
Personally I would suspect this is more useful than the dump-everything
handlers: just give a *full* *detailed* walk for the actually interesting
virtual address (the one faulted on).

> I have attached new output from xl dmesg, this time with iommu=debug on (the
> option changed from 4.1 to 4.2).

Not easy to glean any more from that, without extra tracing such as
described above, and/or digging into the guest to find what driver-side
actions are causing the faults.

 -- Keir

> 
> 
>>  -- Keir
> 



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

From xen-devel-bounces@lists.xen.org Sun Sep 02 14:59:48 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 02 Sep 2012 14:59:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T8Bdn-00089b-Js; Sun, 02 Sep 2012 14:59:11 +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 1T8Bdl-00089T-RI
	for xen-devel@lists.xen.org; Sun, 02 Sep 2012 14:59:10 +0000
Received: from [85.158.139.83:9817] by server-5.bemta-5.messagelabs.com id
	4A/54-30514-D3473405; Sun, 02 Sep 2012 14:59:09 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1346597946!23871711!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-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1183 invoked from network); 2 Sep 2012 14:59:07 -0000
Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com)
	(74.125.83.45)
	by server-14.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Sep 2012 14:59:07 -0000
Received: by eeke53 with SMTP id e53so1822412eek.32
	for <xen-devel@lists.xen.org>; Sun, 02 Sep 2012 07:59:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=cxbObWqzfKpGgJQIedRktVC+MyWwal42nEHioXLnv4U=;
	b=s6p0GnX8a9op8Vom9G5bcv0EQwgmqP02sUIE74gAil+3q9GesSMng163pur3uz+T+6
	mBUN9LaxrH4kN/Ozn3x8zzxi1dPnwPb5YQVHus9MZi1V5Fq9VmD9GWLyQyCQKSwaub1B
	YymMXrH0+hhiDz+wjh1mGbImVL0S/BcCjsEI1Z/frjmxjlJB1aLl9abY10lLZZKqKW10
	AsrmkwWpb2FMY1w6axLhEsrTY5XNGPEd63zA1gxKrGP1nl22VHnhTjGTRJoUD05cgYRf
	DCdP3INd78sqGDlZXVorWFSPoCQm0OQTrmByPL5niSGF/I/pd6O7H5/GIlgSaXoRawYs
	+A2w==
Received: by 10.14.4.201 with SMTP id 49mr17953608eej.0.1346597946743;
	Sun, 02 Sep 2012 07:59:06 -0700 (PDT)
Received: from [192.168.1.69] (host86-184-74-117.range86-184.btcentralplus.com.
	[86.184.74.117])
	by mx.google.com with ESMTPS id 45sm28739266eeb.8.2012.09.02.07.59.02
	(version=SSLv3 cipher=OTHER); Sun, 02 Sep 2012 07:59:06 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Sun, 02 Sep 2012 15:58:58 +0100
From: Keir Fraser <keir.xen@gmail.com>
To: Sander Eikelenboom <linux@eikelenboom.it>
Message-ID: <CC6932C2.3D99D%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] Using debug-key 'o:  Dump IOMMU p2m table, locks up
	machine
Thread-Index: Ac2JG3q9vAd49JMnbUy0lmDWqo6J3w==
In-Reply-To: <40501859.20120902104331@eikelenboom.it>
Mime-version: 1.0
Cc: "wei.wang2@amd.com" <wei.wang2@amd.com>,
	Santosh Jodh <Santosh.Jodh@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Using debug-key 'o:  Dump IOMMU p2m table,
 locks up machine
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 02/09/2012 09:43, "Sander Eikelenboom" <linux@eikelenboom.it> wrote:

>> Quite simply, there likely needs to be more tracing on the IOMMU fault path.
>> That's a separate concern from your keyhandler of course, but just saying
>> I'd be looking for the former rather than the latter, for diagnosing
>> Sander's bug.
> 
> Are there any printk's I could add to get more relevant info about the AMD-Vi:
> IO_PAGE_FAULT ?

No really straightforward one. I think we need a per-IOMMU-type handler to
walk the IOMMU page table for a given virtual address, and dump every
page-table-entry on the path. Like an IOMMU version of show_page_walk().
Personally I would suspect this is more useful than the dump-everything
handlers: just give a *full* *detailed* walk for the actually interesting
virtual address (the one faulted on).

> I have attached new output from xl dmesg, this time with iommu=debug on (the
> option changed from 4.1 to 4.2).

Not easy to glean any more from that, without extra tracing such as
described above, and/or digging into the guest to find what driver-side
actions are causing the faults.

 -- Keir

> 
> 
>>  -- Keir
> 



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

From xen-devel-bounces@lists.xen.org Sun Sep 02 15:15:17 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 02 Sep 2012 15: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 1T8Bss-0008MG-14; Sun, 02 Sep 2012 15:14:46 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <linux@eikelenboom.it>) id 1T8Bsq-0008MB-Pq
	for xen-devel@lists.xen.org; Sun, 02 Sep 2012 15:14:44 +0000
Received: from [85.158.139.83:49524] by server-9.bemta-5.messagelabs.com id
	B2/B8-20529-4E773405; Sun, 02 Sep 2012 15:14:44 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-7.tower-182.messagelabs.com!1346598883!24193391!1
X-Originating-IP: [188.40.164.121]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23422 invoked from network); 2 Sep 2012 15:14:43 -0000
Received: from static.121.164.40.188.clients.your-server.de (HELO
	smtp.eikelenboom.it) (188.40.164.121)
	by server-7.tower-182.messagelabs.com with AES256-SHA encrypted SMTP;
	2 Sep 2012 15:14:43 -0000
Received: from 26-69-ftth.onsneteindhoven.nl ([88.159.69.26]:60557
	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 1T8Bpk-0001to-4I; Sun, 02 Sep 2012 17:11:32 +0200
Date: Sun, 2 Sep 2012 17:14:41 +0200
From: Sander Eikelenboom <linux@eikelenboom.it>
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <217459398.20120902171441@eikelenboom.it>
To: Keir Fraser <keir.xen@gmail.com>
In-Reply-To: <CC6932C2.3D99D%keir.xen@gmail.com>
References: <40501859.20120902104331@eikelenboom.it>
	<CC6932C2.3D99D%keir.xen@gmail.com>
MIME-Version: 1.0
Cc: "wei.wang2@amd.com" <wei.wang2@amd.com>,
	Santosh Jodh <Santosh.Jodh@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Using debug-key 'o:  Dump IOMMU p2m table,
	locks up machine
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Sunday, September 2, 2012, 4:58:58 PM, you wrote:

> On 02/09/2012 09:43, "Sander Eikelenboom" <linux@eikelenboom.it> wrote:

>>> Quite simply, there likely needs to be more tracing on the IOMMU fault path.
>>> That's a separate concern from your keyhandler of course, but just saying
>>> I'd be looking for the former rather than the latter, for diagnosing
>>> Sander's bug.
>> 
>> Are there any printk's I could add to get more relevant info about the AMD-Vi:
>> IO_PAGE_FAULT ?

> No really straightforward one. I think we need a per-IOMMU-type handler to
> walk the IOMMU page table for a given virtual address, and dump every
> page-table-entry on the path. Like an IOMMU version of show_page_walk().
> Personally I would suspect this is more useful than the dump-everything
> handlers: just give a *full* *detailed* walk for the actually interesting
> virtual address (the one faulted on).

>> I have attached new output from xl dmesg, this time with iommu=debug on (the
>> option changed from 4.1 to 4.2).

> Not easy to glean any more from that, without extra tracing such as
> described above, and/or digging into the guest to find what driver-side
> actions are causing the faults.

OK, too bad!
With xen 4.1 i haven't experienced those page faults, but a diff between /xen/drivers/passthrough/amd in both trees show quite some changes :(

>  -- Keir

>> 
>> 
>>>  -- Keir
>> 






-- 
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 Sun Sep 02 15:15:17 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 02 Sep 2012 15: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 1T8Bss-0008MG-14; Sun, 02 Sep 2012 15:14:46 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <linux@eikelenboom.it>) id 1T8Bsq-0008MB-Pq
	for xen-devel@lists.xen.org; Sun, 02 Sep 2012 15:14:44 +0000
Received: from [85.158.139.83:49524] by server-9.bemta-5.messagelabs.com id
	B2/B8-20529-4E773405; Sun, 02 Sep 2012 15:14:44 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-7.tower-182.messagelabs.com!1346598883!24193391!1
X-Originating-IP: [188.40.164.121]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23422 invoked from network); 2 Sep 2012 15:14:43 -0000
Received: from static.121.164.40.188.clients.your-server.de (HELO
	smtp.eikelenboom.it) (188.40.164.121)
	by server-7.tower-182.messagelabs.com with AES256-SHA encrypted SMTP;
	2 Sep 2012 15:14:43 -0000
Received: from 26-69-ftth.onsneteindhoven.nl ([88.159.69.26]:60557
	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 1T8Bpk-0001to-4I; Sun, 02 Sep 2012 17:11:32 +0200
Date: Sun, 2 Sep 2012 17:14:41 +0200
From: Sander Eikelenboom <linux@eikelenboom.it>
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <217459398.20120902171441@eikelenboom.it>
To: Keir Fraser <keir.xen@gmail.com>
In-Reply-To: <CC6932C2.3D99D%keir.xen@gmail.com>
References: <40501859.20120902104331@eikelenboom.it>
	<CC6932C2.3D99D%keir.xen@gmail.com>
MIME-Version: 1.0
Cc: "wei.wang2@amd.com" <wei.wang2@amd.com>,
	Santosh Jodh <Santosh.Jodh@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Using debug-key 'o:  Dump IOMMU p2m table,
	locks up machine
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Sunday, September 2, 2012, 4:58:58 PM, you wrote:

> On 02/09/2012 09:43, "Sander Eikelenboom" <linux@eikelenboom.it> wrote:

>>> Quite simply, there likely needs to be more tracing on the IOMMU fault path.
>>> That's a separate concern from your keyhandler of course, but just saying
>>> I'd be looking for the former rather than the latter, for diagnosing
>>> Sander's bug.
>> 
>> Are there any printk's I could add to get more relevant info about the AMD-Vi:
>> IO_PAGE_FAULT ?

> No really straightforward one. I think we need a per-IOMMU-type handler to
> walk the IOMMU page table for a given virtual address, and dump every
> page-table-entry on the path. Like an IOMMU version of show_page_walk().
> Personally I would suspect this is more useful than the dump-everything
> handlers: just give a *full* *detailed* walk for the actually interesting
> virtual address (the one faulted on).

>> I have attached new output from xl dmesg, this time with iommu=debug on (the
>> option changed from 4.1 to 4.2).

> Not easy to glean any more from that, without extra tracing such as
> described above, and/or digging into the guest to find what driver-side
> actions are causing the faults.

OK, too bad!
With xen 4.1 i haven't experienced those page faults, but a diff between /xen/drivers/passthrough/amd in both trees show quite some changes :(

>  -- Keir

>> 
>> 
>>>  -- Keir
>> 






-- 
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 Sun Sep 02 15:47:53 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 02 Sep 2012 15: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 1T8COW-00007e-Q0; Sun, 02 Sep 2012 15:47:28 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <greg@wind.enjellic.com>) id 1T8COV-00007Z-3g
	for xen-devel@lists.xen.org; Sun, 02 Sep 2012 15:47:27 +0000
Received: from [85.158.139.83:4697] by server-2.bemta-5.messagelabs.com id
	C9/E9-11456-E8F73405; Sun, 02 Sep 2012 15:47:26 +0000
X-Env-Sender: greg@wind.enjellic.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1346600843!24195428!1
X-Originating-IP: [76.10.64.91]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19064 invoked from network); 2 Sep 2012 15:47:23 -0000
Received: from wind.enjellic.com (HELO wind.enjellic.com) (76.10.64.91)
	by server-7.tower-182.messagelabs.com with SMTP;
	2 Sep 2012 15:47:23 -0000
Received: from wind.enjellic.com (localhost [127.0.0.1])
	by wind.enjellic.com (8.14.3/8.14.3) with ESMTP id q82FlIud017693;
	Sun, 2 Sep 2012 10:47:18 -0500
Received: (from greg@localhost)
	by wind.enjellic.com (8.14.3/8.14.3/Submit) id q82FlHEX017692;
	Sun, 2 Sep 2012 10:47:17 -0500
Date: Sun, 2 Sep 2012 10:47:17 -0500
From: "Dr. Greg Wettstein" <greg@wind.enjellic.com>
Message-Id: <201209021547.q82FlHEX017692@wind.enjellic.com>
In-Reply-To: Ian Campbell <Ian.Campbell@citrix.com>
	"Re: [Xen-devel] XEN 4.1.3 blktap2 patches." (Aug 29,  8:54am)
X-Mailer: Mail User's Shell (7.2.6-ESD1.0 03/31/2012)
To: Ian Campbell <Ian.Campbell@citrix.com>
X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.3
	(wind.enjellic.com [0.0.0.0]);
	Sun, 02 Sep 2012 10:47:18 -0500 (CDT)
Cc: keir@xen.org, ian.jackson@eu.citrix.com,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] XEN 4.1.3 blktap2 patches.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: greg@enjellic.com
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Aug 29,  8:54am, Ian Campbell wrote:
} Subject: Re: [Xen-devel] XEN 4.1.3 blktap2 patches.

Good morning, hope the weekend is going well for everyone.

> On Tue, 2012-08-28 at 13:25 +0100, Dr. Greg Wettstein wrote:
> > Good morning, hope the day is going well for everyone.
> > 
> > The patches to fix the blktap2 issues which result in orphaned
> > tapdisk2 processes and the transitory deadlock on guest shutdown
> > didn't make it into the 4.1.3 release.  Updated patches to address
> > these problems are available at the following location:
> > 
> > 	ftp://ftp.enjellic.com/pub/xen/xen-4.1.3.blktap1.patch
> > 	ftp://ftp.enjellic.com/pub/xen/xen-4.1.3.blktap2.patch
> > 
> > The patches are designed to be applied in order and have been verified
> > to work against the 4.1.3 release.

> Please can you post these patches as emails with a changelog and a
> signed-off-by. You should also CC Ian Jackson since he is the one who
> does the tools backports.

.. [ material elided ] ...

> If nothing has changed since the previous posting it may be sufficient
> to reply to that previous postings with a "ping" message and CC Ian
> there.

Thanks for the comments and suggestions.

My target audience was primarily focused on other groups, like ours,
which are rolling their own XEN implementations and who needed blktap2
functionality.  I know I've spent tons of time trying to ferret out
the patches to get a solid implementation for our needs.  So I wanted
to get something which would get indexed so, hopefully, people would
find this when they need it.

Based on the number of downloads I see for the kernel patches and the
toolstack fixes there seems to be a sizable audience.... :-)

I shipped off the patches just before 4.1.3 was released and copied
Ian and Keir on them but I haven't seen them show up in the
xen-4.1-testing.hg Mercurial tree.  Ian/Keir do you want another round
of the patches?

> Ian.

Best wishes for a productive week.

Greg

}-- End of excerpt from Ian Campbell

As always,
Dr. G.W. Wettstein, Ph.D.   Enjellic Systems Development, LLC.
4206 N. 19th Ave.           Specializing in information infra-structure
Fargo, ND  58102            development.
PH: 701-281-1686
FAX: 701-281-3949           EMAIL: greg@enjellic.com
------------------------------------------------------------------------------
"God made man, the appendix was the result of a committee."
                                -- Dr. G.W. Wettstein
                                   Guerrilla Tactics for Corporate Survival

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

From xen-devel-bounces@lists.xen.org Sun Sep 02 15:47:53 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 02 Sep 2012 15: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 1T8COW-00007e-Q0; Sun, 02 Sep 2012 15:47:28 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <greg@wind.enjellic.com>) id 1T8COV-00007Z-3g
	for xen-devel@lists.xen.org; Sun, 02 Sep 2012 15:47:27 +0000
Received: from [85.158.139.83:4697] by server-2.bemta-5.messagelabs.com id
	C9/E9-11456-E8F73405; Sun, 02 Sep 2012 15:47:26 +0000
X-Env-Sender: greg@wind.enjellic.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1346600843!24195428!1
X-Originating-IP: [76.10.64.91]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19064 invoked from network); 2 Sep 2012 15:47:23 -0000
Received: from wind.enjellic.com (HELO wind.enjellic.com) (76.10.64.91)
	by server-7.tower-182.messagelabs.com with SMTP;
	2 Sep 2012 15:47:23 -0000
Received: from wind.enjellic.com (localhost [127.0.0.1])
	by wind.enjellic.com (8.14.3/8.14.3) with ESMTP id q82FlIud017693;
	Sun, 2 Sep 2012 10:47:18 -0500
Received: (from greg@localhost)
	by wind.enjellic.com (8.14.3/8.14.3/Submit) id q82FlHEX017692;
	Sun, 2 Sep 2012 10:47:17 -0500
Date: Sun, 2 Sep 2012 10:47:17 -0500
From: "Dr. Greg Wettstein" <greg@wind.enjellic.com>
Message-Id: <201209021547.q82FlHEX017692@wind.enjellic.com>
In-Reply-To: Ian Campbell <Ian.Campbell@citrix.com>
	"Re: [Xen-devel] XEN 4.1.3 blktap2 patches." (Aug 29,  8:54am)
X-Mailer: Mail User's Shell (7.2.6-ESD1.0 03/31/2012)
To: Ian Campbell <Ian.Campbell@citrix.com>
X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.3
	(wind.enjellic.com [0.0.0.0]);
	Sun, 02 Sep 2012 10:47:18 -0500 (CDT)
Cc: keir@xen.org, ian.jackson@eu.citrix.com,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] XEN 4.1.3 blktap2 patches.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: greg@enjellic.com
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Aug 29,  8:54am, Ian Campbell wrote:
} Subject: Re: [Xen-devel] XEN 4.1.3 blktap2 patches.

Good morning, hope the weekend is going well for everyone.

> On Tue, 2012-08-28 at 13:25 +0100, Dr. Greg Wettstein wrote:
> > Good morning, hope the day is going well for everyone.
> > 
> > The patches to fix the blktap2 issues which result in orphaned
> > tapdisk2 processes and the transitory deadlock on guest shutdown
> > didn't make it into the 4.1.3 release.  Updated patches to address
> > these problems are available at the following location:
> > 
> > 	ftp://ftp.enjellic.com/pub/xen/xen-4.1.3.blktap1.patch
> > 	ftp://ftp.enjellic.com/pub/xen/xen-4.1.3.blktap2.patch
> > 
> > The patches are designed to be applied in order and have been verified
> > to work against the 4.1.3 release.

> Please can you post these patches as emails with a changelog and a
> signed-off-by. You should also CC Ian Jackson since he is the one who
> does the tools backports.

.. [ material elided ] ...

> If nothing has changed since the previous posting it may be sufficient
> to reply to that previous postings with a "ping" message and CC Ian
> there.

Thanks for the comments and suggestions.

My target audience was primarily focused on other groups, like ours,
which are rolling their own XEN implementations and who needed blktap2
functionality.  I know I've spent tons of time trying to ferret out
the patches to get a solid implementation for our needs.  So I wanted
to get something which would get indexed so, hopefully, people would
find this when they need it.

Based on the number of downloads I see for the kernel patches and the
toolstack fixes there seems to be a sizable audience.... :-)

I shipped off the patches just before 4.1.3 was released and copied
Ian and Keir on them but I haven't seen them show up in the
xen-4.1-testing.hg Mercurial tree.  Ian/Keir do you want another round
of the patches?

> Ian.

Best wishes for a productive week.

Greg

}-- End of excerpt from Ian Campbell

As always,
Dr. G.W. Wettstein, Ph.D.   Enjellic Systems Development, LLC.
4206 N. 19th Ave.           Specializing in information infra-structure
Fargo, ND  58102            development.
PH: 701-281-1686
FAX: 701-281-3949           EMAIL: greg@enjellic.com
------------------------------------------------------------------------------
"God made man, the appendix was the result of a committee."
                                -- Dr. G.W. Wettstein
                                   Guerrilla Tactics for Corporate Survival

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

From xen-devel-bounces@lists.xen.org Sun Sep 02 16:31:29 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 02 Sep 2012 16:31: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 1T8D4X-0000l3-CR; Sun, 02 Sep 2012 16:30:53 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jmarcet@gmail.com>) id 1T8D4V-0000kv-2h
	for xen-devel@lists.xen.org; Sun, 02 Sep 2012 16:30:51 +0000
X-Env-Sender: jmarcet@gmail.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1346603438!9211189!1
X-Originating-IP: [209.85.214.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10391 invoked from network); 2 Sep 2012 16:30:40 -0000
Received: from mail-ob0-f173.google.com (HELO mail-ob0-f173.google.com)
	(209.85.214.173)
	by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Sep 2012 16:30:40 -0000
Received: by obbta14 with SMTP id ta14so10569317obb.32
	for <xen-devel@lists.xen.org>; Sun, 02 Sep 2012 09:30:38 -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=Q5Fvc2hG3hojIB0BowpFwa3gzePmYRN9cLHl+8D59DU=;
	b=rrZhSjSwsykqHfOX1zGU8a4Qs9WPzklhn281YxtzhZqPI9gY0bgHAoybx5y0MBOP0e
	R/YKBQsOks5a+bv693kHBcGOQxf8Z24BOFS7ugrC2r2brBOu7UkqZx6BU2/rRdxFdoNx
	8pcxnBc5CxUlIm1z5Apt7gfapAOjroCwQkKGWf2ofuv62XVdAhCkUSEeV3yV+0jn6S8l
	l6Qwawl+HKxdZEGnZPqpXpEVsxD/CBY1FJuh6Xo69aczbXDhBv/lFztewbW3LHMsCdtD
	MWM6l4SL5D42cyqcbyPbfygd5TVHs5dTjXeVABYm6bv8vbCirLS1J9NnfZ5rMK7qUNH2
	sGqQ==
Received: by 10.182.1.72 with SMTP id 8mr12152338obk.61.1346603438160; Sun, 02
	Sep 2012 09:30:38 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.60.12.164 with HTTP; Sun, 2 Sep 2012 09:30:18 -0700 (PDT)
In-Reply-To: <5040B7A40200007800097CEE@nat28.tlf.novell.com>
References: <CAAnFQG8z_ja1Wj2hX+0ZRsz5eLWr+U+7PoSiF9NePsSh2jbX4g@mail.gmail.com>
	<5040B7A40200007800097CEE@nat28.tlf.novell.com>
From: Javier Marcet <jmarcet@gmail.com>
Date: Sun, 2 Sep 2012 18:30:18 +0200
Message-ID: <CAAnFQG_vvHQL=NbY1SnMWCcTr73_8RYtNLfc00fqEsz57cd7Rg@mail.gmail.com>
To: Jan Beulich <JBeulich@suse.com>
Cc: Xen Devel Mailing list <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.2.0-rc4 bugs with GigaByte H77M-D3H + Core i7
	3770
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Aug 31, 2012 at 1:09 PM, Jan Beulich <JBeulich@suse.com> wrote:

> > [    0.358278] DMAR:[DMA Read] Request device [00:02.0] fault addr
> > 9fac7000
> > [    0.358278] DMAR:[fault reason 06] PTE Read access is not set
> > [    0.358286] DRHD: handling fault status reg 2
> > [    0.358288] DMAR:[DMA Read] Request device [00:02.0] fault addr
> > 9fac7000
> > [    0.358288] DMAR:[fault reason 06] PTE Read access is not set
> > [    0.358291] DMAR:[DMA Read] Request device [00:02.0] fault addr
> > 9fac7000
> > [    0.358291] DMAR:[fault reason 06] PTE Read access is not set
> > [    0.358307] DRHD: handling fault status reg 3
> >
> > Furthermore, later on, just after enabling the IOMMU, I get this:
> >
> > [    0.328564] DMAR: No ATSR found
> > [    0.328580] IOMMU 1 0xfed91000: using Queued invalidation
> > [    0.328582] IOMMU: Setting RMRR:
> > [    0.328589] IOMMU: Setting identity map for device 0000:00:1d.0
> > [0x9de36000 - 0x9de52fff]
> > [    0.328606] IOMMU: Setting identity map for device 0000:00:1a.0
> > [0x9de36000 - 0x9de52fff]
> > [    0.328617] IOMMU: Setting identity map for device 0000:00:14.0
> > [0x9de36000 - 0x9de52fff]
> > [    0.328625] IOMMU: Prepare 0-16MiB unity mapping for LPC
> > [    0.328630] IOMMU: Setting identity map for device 0000:00:1f.0
> > [0x0 - 0xffffff]
>
> All of these messages shouldn't appear when running under Xen,
> as it's the hypervisor, not the kernel to take care of the IOMMU(s).
> The logs you had pointers to confirm this - are you sure the above
> was seen when running under Xen?

I'm sorry I didn't make myself clearer. That dmesg output is when booting
WITHOUT xen, that is, linux directly over the bare hardware. Under xen
those errors dissapear.

The big issue I'm having running xen is that I can't use it since xen can't
get the cpu capabilities. On the same kernel, which also has kvm compiled in,
it works fine (kvm).

All the backend xen devices are built-in in the kernel. Frontend devices are
compiled as modules.


--
Javier Marcet <jmarcet@gmail.com>

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

From xen-devel-bounces@lists.xen.org Sun Sep 02 16:31:29 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 02 Sep 2012 16:31: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 1T8D4X-0000l3-CR; Sun, 02 Sep 2012 16:30:53 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jmarcet@gmail.com>) id 1T8D4V-0000kv-2h
	for xen-devel@lists.xen.org; Sun, 02 Sep 2012 16:30:51 +0000
X-Env-Sender: jmarcet@gmail.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1346603438!9211189!1
X-Originating-IP: [209.85.214.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10391 invoked from network); 2 Sep 2012 16:30:40 -0000
Received: from mail-ob0-f173.google.com (HELO mail-ob0-f173.google.com)
	(209.85.214.173)
	by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Sep 2012 16:30:40 -0000
Received: by obbta14 with SMTP id ta14so10569317obb.32
	for <xen-devel@lists.xen.org>; Sun, 02 Sep 2012 09:30:38 -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=Q5Fvc2hG3hojIB0BowpFwa3gzePmYRN9cLHl+8D59DU=;
	b=rrZhSjSwsykqHfOX1zGU8a4Qs9WPzklhn281YxtzhZqPI9gY0bgHAoybx5y0MBOP0e
	R/YKBQsOks5a+bv693kHBcGOQxf8Z24BOFS7ugrC2r2brBOu7UkqZx6BU2/rRdxFdoNx
	8pcxnBc5CxUlIm1z5Apt7gfapAOjroCwQkKGWf2ofuv62XVdAhCkUSEeV3yV+0jn6S8l
	l6Qwawl+HKxdZEGnZPqpXpEVsxD/CBY1FJuh6Xo69aczbXDhBv/lFztewbW3LHMsCdtD
	MWM6l4SL5D42cyqcbyPbfygd5TVHs5dTjXeVABYm6bv8vbCirLS1J9NnfZ5rMK7qUNH2
	sGqQ==
Received: by 10.182.1.72 with SMTP id 8mr12152338obk.61.1346603438160; Sun, 02
	Sep 2012 09:30:38 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.60.12.164 with HTTP; Sun, 2 Sep 2012 09:30:18 -0700 (PDT)
In-Reply-To: <5040B7A40200007800097CEE@nat28.tlf.novell.com>
References: <CAAnFQG8z_ja1Wj2hX+0ZRsz5eLWr+U+7PoSiF9NePsSh2jbX4g@mail.gmail.com>
	<5040B7A40200007800097CEE@nat28.tlf.novell.com>
From: Javier Marcet <jmarcet@gmail.com>
Date: Sun, 2 Sep 2012 18:30:18 +0200
Message-ID: <CAAnFQG_vvHQL=NbY1SnMWCcTr73_8RYtNLfc00fqEsz57cd7Rg@mail.gmail.com>
To: Jan Beulich <JBeulich@suse.com>
Cc: Xen Devel Mailing list <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.2.0-rc4 bugs with GigaByte H77M-D3H + Core i7
	3770
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Aug 31, 2012 at 1:09 PM, Jan Beulich <JBeulich@suse.com> wrote:

> > [    0.358278] DMAR:[DMA Read] Request device [00:02.0] fault addr
> > 9fac7000
> > [    0.358278] DMAR:[fault reason 06] PTE Read access is not set
> > [    0.358286] DRHD: handling fault status reg 2
> > [    0.358288] DMAR:[DMA Read] Request device [00:02.0] fault addr
> > 9fac7000
> > [    0.358288] DMAR:[fault reason 06] PTE Read access is not set
> > [    0.358291] DMAR:[DMA Read] Request device [00:02.0] fault addr
> > 9fac7000
> > [    0.358291] DMAR:[fault reason 06] PTE Read access is not set
> > [    0.358307] DRHD: handling fault status reg 3
> >
> > Furthermore, later on, just after enabling the IOMMU, I get this:
> >
> > [    0.328564] DMAR: No ATSR found
> > [    0.328580] IOMMU 1 0xfed91000: using Queued invalidation
> > [    0.328582] IOMMU: Setting RMRR:
> > [    0.328589] IOMMU: Setting identity map for device 0000:00:1d.0
> > [0x9de36000 - 0x9de52fff]
> > [    0.328606] IOMMU: Setting identity map for device 0000:00:1a.0
> > [0x9de36000 - 0x9de52fff]
> > [    0.328617] IOMMU: Setting identity map for device 0000:00:14.0
> > [0x9de36000 - 0x9de52fff]
> > [    0.328625] IOMMU: Prepare 0-16MiB unity mapping for LPC
> > [    0.328630] IOMMU: Setting identity map for device 0000:00:1f.0
> > [0x0 - 0xffffff]
>
> All of these messages shouldn't appear when running under Xen,
> as it's the hypervisor, not the kernel to take care of the IOMMU(s).
> The logs you had pointers to confirm this - are you sure the above
> was seen when running under Xen?

I'm sorry I didn't make myself clearer. That dmesg output is when booting
WITHOUT xen, that is, linux directly over the bare hardware. Under xen
those errors dissapear.

The big issue I'm having running xen is that I can't use it since xen can't
get the cpu capabilities. On the same kernel, which also has kvm compiled in,
it works fine (kvm).

All the backend xen devices are built-in in the kernel. Frontend devices are
compiled as modules.


--
Javier Marcet <jmarcet@gmail.com>

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

From xen-devel-bounces@lists.xen.org Sun Sep 02 16:36:43 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 02 Sep 2012 16: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 1T8D9i-0000tu-4S; Sun, 02 Sep 2012 16:36:14 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jmarcet@gmail.com>) id 1T8D9h-0000to-EA
	for xen-devel@lists.xen.org; Sun, 02 Sep 2012 16:36:13 +0000
Received: from [85.158.138.51:61213] by server-11.bemta-3.messagelabs.com id
	87/71-30250-CFA83405; Sun, 02 Sep 2012 16:36:12 +0000
X-Env-Sender: jmarcet@gmail.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1346603769!20082752!1
X-Originating-IP: [209.85.214.173]
X-SpamReason: No, hits=0.5 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,UPPERCASE_50_75,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5444 invoked from network); 2 Sep 2012 16:36:10 -0000
Received: from mail-ob0-f173.google.com (HELO mail-ob0-f173.google.com)
	(209.85.214.173)
	by server-3.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Sep 2012 16:36:10 -0000
Received: by obbta14 with SMTP id ta14so10574925obb.32
	for <xen-devel@lists.xen.org>; Sun, 02 Sep 2012 09:36: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;
	bh=tz/s9rw0lmw+JdgYx443qF4Bl1D+mleYV6fkmPqDStY=;
	b=KD7LCEfUkGyr/Q/Joudqb7jTK185YNl11lOyah2PON6OQ8JIv1tBe4o/rXcHPqFziZ
	kkCQwNs0OcuXHtmFo40kObqNrq/AdO0lGwBoKsmmNsCUU2a5ai+HRoS6qq7BFxiMOLE4
	sE+FFh9WPGWP36SoXLZgSgDeIthyDCmA3WOVqguC56XRtz859EE64WDyNCW6Cuxuqs+P
	Uqk/f8cKZJ19WXU+8TOc9U8R06l9MKhCEOMJi0oY87VR+2El0aazU/AVh5xBmFbzhjHW
	HmvGu6b5QYophjHyjZedV5dqvVaQDntEJ3hN/w5+mTpuSfjjGbkL55Ifi9sN8BWdcM8O
	rBoQ==
Received: by 10.182.174.9 with SMTP id bo9mr611050obc.19.1346603768815; Sun,
	02 Sep 2012 09:36:08 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.60.12.164 with HTTP; Sun, 2 Sep 2012 09:35:48 -0700 (PDT)
In-Reply-To: <CAAnFQG_vvHQL=NbY1SnMWCcTr73_8RYtNLfc00fqEsz57cd7Rg@mail.gmail.com>
References: <CAAnFQG8z_ja1Wj2hX+0ZRsz5eLWr+U+7PoSiF9NePsSh2jbX4g@mail.gmail.com>
	<5040B7A40200007800097CEE@nat28.tlf.novell.com>
	<CAAnFQG_vvHQL=NbY1SnMWCcTr73_8RYtNLfc00fqEsz57cd7Rg@mail.gmail.com>
From: Javier Marcet <jmarcet@gmail.com>
Date: Sun, 2 Sep 2012 18:35:48 +0200
Message-ID: <CAAnFQG8hkQuMvOBLP=LYG66A1MPps0Gj_UctXt7kEsuD2JxF-w@mail.gmail.com>
To: Jan Beulich <JBeulich@suse.com>
Cc: Xen Devel Mailing list <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.2.0-rc4 bugs with GigaByte H77M-D3H + Core i7
	3770
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, Sep 2, 2012 at 6:30 PM, Javier Marcet <jmarcet@gmail.com> wrote:

> All the backend xen devices are built-in in the kernel. Frontend devices are
> compiled as modules.

$ zcat /proc/config.gz | grep -i xen
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_PCI_XEN=y
CONFIG_XEN_PCIDEV_FRONTEND=m
CONFIG_XEN_BLKDEV_FRONTEND=m
CONFIG_XEN_BLKDEV_BACKEND=y
CONFIG_XEN_NETDEV_FRONTEND=m
CONFIG_XEN_NETDEV_BACKEND=y
CONFIG_INPUT_XEN_KBDDEV_FRONTEND=m
CONFIG_HVC_XEN=y
CONFIG_HVC_XEN_FRONTEND=y
CONFIG_XEN_WDT=m
CONFIG_XEN_FBDEV_FRONTEND=m
# Xen driver support
CONFIG_XEN_BALLOON=y
CONFIG_XEN_SELFBALLOONING=y
# CONFIG_XEN_BALLOON_MEMORY_HOTPLUG is not set
# CONFIG_XEN_SCRUB_PAGES is not set
CONFIG_XEN_DEV_EVTCHN=y
CONFIG_XEN_BACKEND=y
CONFIG_XENFS=y
CONFIG_XEN_COMPAT_XENFS=y
CONFIG_XEN_SYS_HYPERVISOR=y
CONFIG_XEN_XENBUS_FRONTEND=y
CONFIG_XEN_GNTDEV=y
CONFIG_XEN_GRANT_DEV_ALLOC=y
CONFIG_SWIOTLB_XEN=y
CONFIG_XEN_TMEM=y
CONFIG_XEN_PCIDEV_BACKEND=y
CONFIG_XEN_PRIVCMD=y
CONFIG_XEN_ACPI_PROCESSOR=y


-- 
Javier Marcet <jmarcet@gmail.com>

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

From xen-devel-bounces@lists.xen.org Sun Sep 02 16:36:43 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 02 Sep 2012 16: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 1T8D9i-0000tu-4S; Sun, 02 Sep 2012 16:36:14 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jmarcet@gmail.com>) id 1T8D9h-0000to-EA
	for xen-devel@lists.xen.org; Sun, 02 Sep 2012 16:36:13 +0000
Received: from [85.158.138.51:61213] by server-11.bemta-3.messagelabs.com id
	87/71-30250-CFA83405; Sun, 02 Sep 2012 16:36:12 +0000
X-Env-Sender: jmarcet@gmail.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1346603769!20082752!1
X-Originating-IP: [209.85.214.173]
X-SpamReason: No, hits=0.5 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,UPPERCASE_50_75,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5444 invoked from network); 2 Sep 2012 16:36:10 -0000
Received: from mail-ob0-f173.google.com (HELO mail-ob0-f173.google.com)
	(209.85.214.173)
	by server-3.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Sep 2012 16:36:10 -0000
Received: by obbta14 with SMTP id ta14so10574925obb.32
	for <xen-devel@lists.xen.org>; Sun, 02 Sep 2012 09:36: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;
	bh=tz/s9rw0lmw+JdgYx443qF4Bl1D+mleYV6fkmPqDStY=;
	b=KD7LCEfUkGyr/Q/Joudqb7jTK185YNl11lOyah2PON6OQ8JIv1tBe4o/rXcHPqFziZ
	kkCQwNs0OcuXHtmFo40kObqNrq/AdO0lGwBoKsmmNsCUU2a5ai+HRoS6qq7BFxiMOLE4
	sE+FFh9WPGWP36SoXLZgSgDeIthyDCmA3WOVqguC56XRtz859EE64WDyNCW6Cuxuqs+P
	Uqk/f8cKZJ19WXU+8TOc9U8R06l9MKhCEOMJi0oY87VR+2El0aazU/AVh5xBmFbzhjHW
	HmvGu6b5QYophjHyjZedV5dqvVaQDntEJ3hN/w5+mTpuSfjjGbkL55Ifi9sN8BWdcM8O
	rBoQ==
Received: by 10.182.174.9 with SMTP id bo9mr611050obc.19.1346603768815; Sun,
	02 Sep 2012 09:36:08 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.60.12.164 with HTTP; Sun, 2 Sep 2012 09:35:48 -0700 (PDT)
In-Reply-To: <CAAnFQG_vvHQL=NbY1SnMWCcTr73_8RYtNLfc00fqEsz57cd7Rg@mail.gmail.com>
References: <CAAnFQG8z_ja1Wj2hX+0ZRsz5eLWr+U+7PoSiF9NePsSh2jbX4g@mail.gmail.com>
	<5040B7A40200007800097CEE@nat28.tlf.novell.com>
	<CAAnFQG_vvHQL=NbY1SnMWCcTr73_8RYtNLfc00fqEsz57cd7Rg@mail.gmail.com>
From: Javier Marcet <jmarcet@gmail.com>
Date: Sun, 2 Sep 2012 18:35:48 +0200
Message-ID: <CAAnFQG8hkQuMvOBLP=LYG66A1MPps0Gj_UctXt7kEsuD2JxF-w@mail.gmail.com>
To: Jan Beulich <JBeulich@suse.com>
Cc: Xen Devel Mailing list <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.2.0-rc4 bugs with GigaByte H77M-D3H + Core i7
	3770
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, Sep 2, 2012 at 6:30 PM, Javier Marcet <jmarcet@gmail.com> wrote:

> All the backend xen devices are built-in in the kernel. Frontend devices are
> compiled as modules.

$ zcat /proc/config.gz | grep -i xen
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_PCI_XEN=y
CONFIG_XEN_PCIDEV_FRONTEND=m
CONFIG_XEN_BLKDEV_FRONTEND=m
CONFIG_XEN_BLKDEV_BACKEND=y
CONFIG_XEN_NETDEV_FRONTEND=m
CONFIG_XEN_NETDEV_BACKEND=y
CONFIG_INPUT_XEN_KBDDEV_FRONTEND=m
CONFIG_HVC_XEN=y
CONFIG_HVC_XEN_FRONTEND=y
CONFIG_XEN_WDT=m
CONFIG_XEN_FBDEV_FRONTEND=m
# Xen driver support
CONFIG_XEN_BALLOON=y
CONFIG_XEN_SELFBALLOONING=y
# CONFIG_XEN_BALLOON_MEMORY_HOTPLUG is not set
# CONFIG_XEN_SCRUB_PAGES is not set
CONFIG_XEN_DEV_EVTCHN=y
CONFIG_XEN_BACKEND=y
CONFIG_XENFS=y
CONFIG_XEN_COMPAT_XENFS=y
CONFIG_XEN_SYS_HYPERVISOR=y
CONFIG_XEN_XENBUS_FRONTEND=y
CONFIG_XEN_GNTDEV=y
CONFIG_XEN_GRANT_DEV_ALLOC=y
CONFIG_SWIOTLB_XEN=y
CONFIG_XEN_TMEM=y
CONFIG_XEN_PCIDEV_BACKEND=y
CONFIG_XEN_PRIVCMD=y
CONFIG_XEN_ACPI_PROCESSOR=y


-- 
Javier Marcet <jmarcet@gmail.com>

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

From xen-devel-bounces@lists.xen.org Sun Sep 02 17:06:24 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 02 Sep 2012 17: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 1T8DcT-000193-JD; Sun, 02 Sep 2012 17:05:57 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jmarcet@gmail.com>) id 1T8DcS-00018y-26
	for xen-devel@lists.xen.org; Sun, 02 Sep 2012 17:05:56 +0000
Received: from [85.158.138.51:44876] by server-5.bemta-3.messagelabs.com id
	76/6D-13133-3F193405; Sun, 02 Sep 2012 17:05:55 +0000
X-Env-Sender: jmarcet@gmail.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1346605552!28073457!1
X-Originating-IP: [209.85.214.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-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24347 invoked from network); 2 Sep 2012 17:05:54 -0000
Received: from mail-ob0-f173.google.com (HELO mail-ob0-f173.google.com)
	(209.85.214.173)
	by server-16.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Sep 2012 17:05:54 -0000
Received: by obbta14 with SMTP id ta14so10602111obb.32
	for <xen-devel@lists.xen.org>; Sun, 02 Sep 2012 10:05:52 -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=cnMaJBNnceGqFDWXJvdRPGVTbivOMVG6H6ys2HVeabs=;
	b=W4ciQ369aLD4gF2dN1ZeNImtA5rmiF2JmVjj/m+Q3hZuVnlsq0RwNup71h4ItxYcVb
	VuoH3z+Z7PerPiCM1F0dlPmoSQ3LoZTNrDb+5gcCChgCXF1adjtieLWjOIgGRRtvJxBy
	yZOkSd5L5FrXI1QgeZiDHNlFhbK8BPIwnm7rWTVUfrCd7E/yVQuOEq2YvAFFI4S7XlNO
	dLIN6S5jfDvwf1lltClFcKWF0I2NLE4BojBND/E9ECd2hn9LVIAHT+PQ3oDiY315Uc+f
	LKvn6sUez8pZu3gNRuXW22+twRY3Nurfx0Dnlii2Gq0EI61ezdlUJ+2OgmAWZSGQLM29
	2vzQ==
Received: by 10.182.177.7 with SMTP id cm7mr12236038obc.17.1346605552305; Sun,
	02 Sep 2012 10:05:52 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.60.12.164 with HTTP; Sun, 2 Sep 2012 10:05:32 -0700 (PDT)
In-Reply-To: <CAAnFQG8z_ja1Wj2hX+0ZRsz5eLWr+U+7PoSiF9NePsSh2jbX4g@mail.gmail.com>
References: <CAAnFQG8z_ja1Wj2hX+0ZRsz5eLWr+U+7PoSiF9NePsSh2jbX4g@mail.gmail.com>
From: Javier Marcet <jmarcet@gmail.com>
Date: Sun, 2 Sep 2012 19:05:32 +0200
Message-ID: <CAAnFQG_8=E1YFtBngaGzDPPvcSBBMsf4q5=+0g6oabLi-O+Baw@mail.gmail.com>
To: Xen Devel Mailing list <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.2.0-rc4 bugs with GigaByte H77M-D3H + Core i7
	3770
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Aug 30, 2012 at 12:43 PM, Javier Marcet <jmarcet@gmail.com> wrote:
> Furthermore, later on, just after enabling the IOMMU, I get this:
>
> [    0.328564] DMAR: No ATSR found
> [    0.328580] IOMMU 1 0xfed91000: using Queued invalidation
> [    0.328582] IOMMU: Setting RMRR:
> [    0.328589] IOMMU: Setting identity map for device 0000:00:1d.0
> [0x9de36000 - 0x9de52fff]
> [    0.328606] IOMMU: Setting identity map for device 0000:00:1a.0
> [0x9de36000 - 0x9de52fff]
> [    0.328617] IOMMU: Setting identity map for device 0000:00:14.0
> [0x9de36000 - 0x9de52fff]
> [    0.328625] IOMMU: Prepare 0-16MiB unity mapping for LPC
> [    0.328630] IOMMU: Setting identity map for device 0000:00:1f.0
> [0x0 - 0xffffff]
> [    0.328705] PCI-DMA: Intel(R) Virtualization Technology for Directed I/O
> [    0.328714] ------------[ cut here ]------------
> [    0.328718] WARNING: at
> /home/storage/src/ubuntu-precise/drivers/pci/search.c:44
> pci_find_upstream_pcie_bridge+0x51/0x68()
> [    0.328719] Hardware name: To be filled by O.E.M.
> [    0.328720] Modules linked in:
> [    0.328722] Pid: 1, comm: swapper/0 Not tainted 3.5.0-12-i3 #12~precise1
> [    0.328723] Call Trace:
> [    0.328727]  [<ffffffff8106ab0d>] warn_slowpath_common+0x7e/0x96
> [    0.328729]  [<ffffffff8106ab3a>] warn_slowpath_null+0x15/0x17
> [    0.328731]  [<ffffffff812992d5>] pci_find_upstream_pcie_bridge+0x51/0x68
> [    0.328733]  [<ffffffff814bd02e>] intel_iommu_device_group+0x64/0xb7
> [    0.328735]  [<ffffffff814b8a2b>] ? bus_set_iommu+0x3f/0x3f
> [    0.328738]  [<ffffffff814b86f2>] iommu_device_group+0x24/0x26
> [    0.328740]  [<ffffffff814b8a40>] add_iommu_group+0x15/0x33
> [    0.328742]  [<ffffffff8137ba61>] bus_for_each_dev+0x54/0x80
> [    0.328745]  [<ffffffff81cdaf83>] ? memblock_find_dma_reserve+0x13f/0x13f
> [    0.328746]  [<ffffffff814b8a25>] bus_set_iommu+0x39/0x3f
> [    0.328749]  [<ffffffff81d0367c>] intel_iommu_init+0x1aa/0x1ce
> [    0.328751]  [<ffffffff81cdaf96>] pci_iommu_init+0x13/0x3e
> [    0.328754]  [<ffffffff81002094>] do_one_initcall+0x7a/0x132
> [    0.328756]  [<ffffffff81cd2bac>] do_basic_setup+0x96/0xb4
> [    0.328758]  [<ffffffff81cd2533>] ? obsolete_checksetup+0xab/0xab
> [    0.328759]  [<ffffffff81cd2c82>] kernel_init+0xb8/0x12e
> [    0.328762]  [<ffffffff81615b24>] kernel_thread_helper+0x4/0x10
> [    0.328764]  [<ffffffff81cd2bca>] ? do_basic_setup+0xb4/0xb4
> [    0.328766]  [<ffffffff81615b20>] ? gs_change+0x13/0x13
> [    0.328768] ---[ end trace 9bacf275b2da9216 ]---

It seems I'm affected by https://bugzilla.kernel.org/show_bug.cgi?id=44881

Although that's a linux kernel issue which looks like xen doesn't have.
Maybe they can take a look at xen to see how it navigates the pci tree
differently.


-- 
Javier Marcet <jmarcet@gmail.com>

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

From xen-devel-bounces@lists.xen.org Sun Sep 02 17:06:24 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 02 Sep 2012 17: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 1T8DcT-000193-JD; Sun, 02 Sep 2012 17:05:57 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jmarcet@gmail.com>) id 1T8DcS-00018y-26
	for xen-devel@lists.xen.org; Sun, 02 Sep 2012 17:05:56 +0000
Received: from [85.158.138.51:44876] by server-5.bemta-3.messagelabs.com id
	76/6D-13133-3F193405; Sun, 02 Sep 2012 17:05:55 +0000
X-Env-Sender: jmarcet@gmail.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1346605552!28073457!1
X-Originating-IP: [209.85.214.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-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24347 invoked from network); 2 Sep 2012 17:05:54 -0000
Received: from mail-ob0-f173.google.com (HELO mail-ob0-f173.google.com)
	(209.85.214.173)
	by server-16.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Sep 2012 17:05:54 -0000
Received: by obbta14 with SMTP id ta14so10602111obb.32
	for <xen-devel@lists.xen.org>; Sun, 02 Sep 2012 10:05:52 -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=cnMaJBNnceGqFDWXJvdRPGVTbivOMVG6H6ys2HVeabs=;
	b=W4ciQ369aLD4gF2dN1ZeNImtA5rmiF2JmVjj/m+Q3hZuVnlsq0RwNup71h4ItxYcVb
	VuoH3z+Z7PerPiCM1F0dlPmoSQ3LoZTNrDb+5gcCChgCXF1adjtieLWjOIgGRRtvJxBy
	yZOkSd5L5FrXI1QgeZiDHNlFhbK8BPIwnm7rWTVUfrCd7E/yVQuOEq2YvAFFI4S7XlNO
	dLIN6S5jfDvwf1lltClFcKWF0I2NLE4BojBND/E9ECd2hn9LVIAHT+PQ3oDiY315Uc+f
	LKvn6sUez8pZu3gNRuXW22+twRY3Nurfx0Dnlii2Gq0EI61ezdlUJ+2OgmAWZSGQLM29
	2vzQ==
Received: by 10.182.177.7 with SMTP id cm7mr12236038obc.17.1346605552305; Sun,
	02 Sep 2012 10:05:52 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.60.12.164 with HTTP; Sun, 2 Sep 2012 10:05:32 -0700 (PDT)
In-Reply-To: <CAAnFQG8z_ja1Wj2hX+0ZRsz5eLWr+U+7PoSiF9NePsSh2jbX4g@mail.gmail.com>
References: <CAAnFQG8z_ja1Wj2hX+0ZRsz5eLWr+U+7PoSiF9NePsSh2jbX4g@mail.gmail.com>
From: Javier Marcet <jmarcet@gmail.com>
Date: Sun, 2 Sep 2012 19:05:32 +0200
Message-ID: <CAAnFQG_8=E1YFtBngaGzDPPvcSBBMsf4q5=+0g6oabLi-O+Baw@mail.gmail.com>
To: Xen Devel Mailing list <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.2.0-rc4 bugs with GigaByte H77M-D3H + Core i7
	3770
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Aug 30, 2012 at 12:43 PM, Javier Marcet <jmarcet@gmail.com> wrote:
> Furthermore, later on, just after enabling the IOMMU, I get this:
>
> [    0.328564] DMAR: No ATSR found
> [    0.328580] IOMMU 1 0xfed91000: using Queued invalidation
> [    0.328582] IOMMU: Setting RMRR:
> [    0.328589] IOMMU: Setting identity map for device 0000:00:1d.0
> [0x9de36000 - 0x9de52fff]
> [    0.328606] IOMMU: Setting identity map for device 0000:00:1a.0
> [0x9de36000 - 0x9de52fff]
> [    0.328617] IOMMU: Setting identity map for device 0000:00:14.0
> [0x9de36000 - 0x9de52fff]
> [    0.328625] IOMMU: Prepare 0-16MiB unity mapping for LPC
> [    0.328630] IOMMU: Setting identity map for device 0000:00:1f.0
> [0x0 - 0xffffff]
> [    0.328705] PCI-DMA: Intel(R) Virtualization Technology for Directed I/O
> [    0.328714] ------------[ cut here ]------------
> [    0.328718] WARNING: at
> /home/storage/src/ubuntu-precise/drivers/pci/search.c:44
> pci_find_upstream_pcie_bridge+0x51/0x68()
> [    0.328719] Hardware name: To be filled by O.E.M.
> [    0.328720] Modules linked in:
> [    0.328722] Pid: 1, comm: swapper/0 Not tainted 3.5.0-12-i3 #12~precise1
> [    0.328723] Call Trace:
> [    0.328727]  [<ffffffff8106ab0d>] warn_slowpath_common+0x7e/0x96
> [    0.328729]  [<ffffffff8106ab3a>] warn_slowpath_null+0x15/0x17
> [    0.328731]  [<ffffffff812992d5>] pci_find_upstream_pcie_bridge+0x51/0x68
> [    0.328733]  [<ffffffff814bd02e>] intel_iommu_device_group+0x64/0xb7
> [    0.328735]  [<ffffffff814b8a2b>] ? bus_set_iommu+0x3f/0x3f
> [    0.328738]  [<ffffffff814b86f2>] iommu_device_group+0x24/0x26
> [    0.328740]  [<ffffffff814b8a40>] add_iommu_group+0x15/0x33
> [    0.328742]  [<ffffffff8137ba61>] bus_for_each_dev+0x54/0x80
> [    0.328745]  [<ffffffff81cdaf83>] ? memblock_find_dma_reserve+0x13f/0x13f
> [    0.328746]  [<ffffffff814b8a25>] bus_set_iommu+0x39/0x3f
> [    0.328749]  [<ffffffff81d0367c>] intel_iommu_init+0x1aa/0x1ce
> [    0.328751]  [<ffffffff81cdaf96>] pci_iommu_init+0x13/0x3e
> [    0.328754]  [<ffffffff81002094>] do_one_initcall+0x7a/0x132
> [    0.328756]  [<ffffffff81cd2bac>] do_basic_setup+0x96/0xb4
> [    0.328758]  [<ffffffff81cd2533>] ? obsolete_checksetup+0xab/0xab
> [    0.328759]  [<ffffffff81cd2c82>] kernel_init+0xb8/0x12e
> [    0.328762]  [<ffffffff81615b24>] kernel_thread_helper+0x4/0x10
> [    0.328764]  [<ffffffff81cd2bca>] ? do_basic_setup+0xb4/0xb4
> [    0.328766]  [<ffffffff81615b20>] ? gs_change+0x13/0x13
> [    0.328768] ---[ end trace 9bacf275b2da9216 ]---

It seems I'm affected by https://bugzilla.kernel.org/show_bug.cgi?id=44881

Although that's a linux kernel issue which looks like xen doesn't have.
Maybe they can take a look at xen to see how it navigates the pci tree
differently.


-- 
Javier Marcet <jmarcet@gmail.com>

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

From xen-devel-bounces@lists.xen.org Sun Sep 02 23:48:19 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 02 Sep 2012 23:48:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T8JtF-0002OU-1j; Sun, 02 Sep 2012 23:47: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 1T8JtC-0002OP-Rm
	for xen-devel@lists.xen.org; Sun, 02 Sep 2012 23:47:39 +0000
Received: from [85.158.143.35:56853] by server-3.bemta-4.messagelabs.com id
	C7/FB-08232-A10F3405; Sun, 02 Sep 2012 23:47:38 +0000
X-Env-Sender: yang.z.zhang@intel.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1346629656!11911954!1
X-Originating-IP: [143.182.124.37]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMzcgPT4gMTkzMTUz\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2095 invoked from network); 2 Sep 2012 23:47:37 -0000
Received: from mga14.intel.com (HELO mga14.intel.com) (143.182.124.37)
	by server-11.tower-21.messagelabs.com with SMTP;
	2 Sep 2012 23:47:37 -0000
Received: from azsmga002.ch.intel.com ([10.2.17.35])
	by azsmga102.ch.intel.com with ESMTP; 02 Sep 2012 16:47:35 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.80,357,1344236400"; d="scan'208";a="140783320"
Received: from fmsmsx108.amr.corp.intel.com ([10.19.9.228])
	by AZSMGA002.ch.intel.com with ESMTP; 02 Sep 2012 16:47:35 -0700
Received: from fmsmsx151.amr.corp.intel.com (10.19.17.220) by
	FMSMSX108.amr.corp.intel.com (10.19.9.228) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Sun, 2 Sep 2012 16:47:34 -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; Sun, 2 Sep 2012 16:47:34 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.239]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.175]) with mapi id
	14.01.0355.002; Mon, 3 Sep 2012 07:47:32 +0800
From: "Zhang, Yang Z" <yang.z.zhang@intel.com>
To: Jan Beulich <JBeulich@suse.com>, "Li, Jiongxi" <jiongxi.li@intel.com>
Thread-Topic: [Xen-devel] [ PATCH 1/2] xen: enable APIC-Register Virtualization
Thread-Index: Ac2HWGKAUDDr53BWQZO2/Uq+OTcM5///rYGA//uVWHA=
Date: Sun, 2 Sep 2012 23:47:32 +0000
Message-ID: <A9667DDFB95DB7438FA9D7D576C3D87E2497F4@SHSMSX101.ccr.corp.intel.com>
References: <D9137FCD9CFF644B965863BCFBEDABB8779924@SHSMSX101.ccr.corp.intel.com>
	<5040C6CF0200007800097D65@nat28.tlf.novell.com>
In-Reply-To: <5040C6CF0200007800097D65@nat28.tlf.novell.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [ PATCH 1/2] xen: enable APIC-Register
 Virtualization
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 2012-08-31:
>>>> On 31.08.12 at 11:29, "Li, Jiongxi" <jiongxi.li@intel.com> wrote:
>> --- a/xen/arch/x86/hvm/vlapic.c      Fri Aug 24 12:38:18 2012 +0100
>> +++ b/xen/arch/x86/hvm/vlapic.c   Thu Aug 30 22:38:26 2012 +0800
>> @@ -823,6 +823,16 @@ static int vlapic_write(struct vcpu *v,
>>      return rc;
>> }
>> 
>> +int vlapic_apicv_write(struct vcpu *v, unsigned int offset)
>> +{
>> +    uint32_t val = vlapic_get_reg(vcpu_vlapic(v), offset);
>> +
>> +    ASSERT(cpu_has_vmx_apic_reg_virt);
> 
> Given the function and the assertion are in a common file, both should
> be named without using VMX specific terms (or moved elsewhere).
Correct. Since the common VM exits handlers are in vmx.c, it's better to put this to vmx.c too.

Best regards,
Yang
> 
> Jan
> 
>> +
>> +    vlapic_reg_write(v, offset, val);
>> +    return 0;
>> +}
>> +
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel




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

From xen-devel-bounces@lists.xen.org Sun Sep 02 23:48:19 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 02 Sep 2012 23:48:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T8JtF-0002OU-1j; Sun, 02 Sep 2012 23:47: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 1T8JtC-0002OP-Rm
	for xen-devel@lists.xen.org; Sun, 02 Sep 2012 23:47:39 +0000
Received: from [85.158.143.35:56853] by server-3.bemta-4.messagelabs.com id
	C7/FB-08232-A10F3405; Sun, 02 Sep 2012 23:47:38 +0000
X-Env-Sender: yang.z.zhang@intel.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1346629656!11911954!1
X-Originating-IP: [143.182.124.37]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMzcgPT4gMTkzMTUz\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2095 invoked from network); 2 Sep 2012 23:47:37 -0000
Received: from mga14.intel.com (HELO mga14.intel.com) (143.182.124.37)
	by server-11.tower-21.messagelabs.com with SMTP;
	2 Sep 2012 23:47:37 -0000
Received: from azsmga002.ch.intel.com ([10.2.17.35])
	by azsmga102.ch.intel.com with ESMTP; 02 Sep 2012 16:47:35 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.80,357,1344236400"; d="scan'208";a="140783320"
Received: from fmsmsx108.amr.corp.intel.com ([10.19.9.228])
	by AZSMGA002.ch.intel.com with ESMTP; 02 Sep 2012 16:47:35 -0700
Received: from fmsmsx151.amr.corp.intel.com (10.19.17.220) by
	FMSMSX108.amr.corp.intel.com (10.19.9.228) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Sun, 2 Sep 2012 16:47:34 -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; Sun, 2 Sep 2012 16:47:34 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.239]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.175]) with mapi id
	14.01.0355.002; Mon, 3 Sep 2012 07:47:32 +0800
From: "Zhang, Yang Z" <yang.z.zhang@intel.com>
To: Jan Beulich <JBeulich@suse.com>, "Li, Jiongxi" <jiongxi.li@intel.com>
Thread-Topic: [Xen-devel] [ PATCH 1/2] xen: enable APIC-Register Virtualization
Thread-Index: Ac2HWGKAUDDr53BWQZO2/Uq+OTcM5///rYGA//uVWHA=
Date: Sun, 2 Sep 2012 23:47:32 +0000
Message-ID: <A9667DDFB95DB7438FA9D7D576C3D87E2497F4@SHSMSX101.ccr.corp.intel.com>
References: <D9137FCD9CFF644B965863BCFBEDABB8779924@SHSMSX101.ccr.corp.intel.com>
	<5040C6CF0200007800097D65@nat28.tlf.novell.com>
In-Reply-To: <5040C6CF0200007800097D65@nat28.tlf.novell.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [ PATCH 1/2] xen: enable APIC-Register
 Virtualization
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 2012-08-31:
>>>> On 31.08.12 at 11:29, "Li, Jiongxi" <jiongxi.li@intel.com> wrote:
>> --- a/xen/arch/x86/hvm/vlapic.c      Fri Aug 24 12:38:18 2012 +0100
>> +++ b/xen/arch/x86/hvm/vlapic.c   Thu Aug 30 22:38:26 2012 +0800
>> @@ -823,6 +823,16 @@ static int vlapic_write(struct vcpu *v,
>>      return rc;
>> }
>> 
>> +int vlapic_apicv_write(struct vcpu *v, unsigned int offset)
>> +{
>> +    uint32_t val = vlapic_get_reg(vcpu_vlapic(v), offset);
>> +
>> +    ASSERT(cpu_has_vmx_apic_reg_virt);
> 
> Given the function and the assertion are in a common file, both should
> be named without using VMX specific terms (or moved elsewhere).
Correct. Since the common VM exits handlers are in vmx.c, it's better to put this to vmx.c too.

Best regards,
Yang
> 
> Jan
> 
>> +
>> +    vlapic_reg_write(v, offset, val);
>> +    return 0;
>> +}
>> +
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel




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

From xen-devel-bounces@lists.xen.org Mon Sep 03 06:34:10 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Sep 2012 06: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 1T8QE1-0000LD-96; Mon, 03 Sep 2012 06:33:33 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1T8QE0-0000L8-Oi
	for xen-devel@lists.xen.org; Mon, 03 Sep 2012 06:33:32 +0000
Received: from [85.158.138.51:5951] by server-7.bemta-3.messagelabs.com id
	E3/2C-32000-B3F44405; Mon, 03 Sep 2012 06:33:31 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1346654009!21879864!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM3ODU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9487 invoked from network); 3 Sep 2012 06:33:29 -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;
	3 Sep 2012 06:33:29 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 03 Sep 2012 07:33:28 +0100
Message-Id: <50446B5402000078000981F4@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 03 Sep 2012 07:33:24 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: <konrad@darnok.org>,
 "Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>
References: <1343745804-28028-1-git-send-email-konrad.wilk@oracle.com>
	<20120801155040.GB15812@phenom.dumpdata.com>
	<501A5EF7020000780009219C@nat28.tlf.novell.com>
	<20120802141710.GF16749@phenom.dumpdata.com>
	<20120802160403.02de484e@mantra.us.oracle.com>
	<20120803133001.GA13750@andromeda.dapyr.net>
	<501BF44602000078000928B4@nat28.tlf.novell.com>
	<CAPbh3rsXaqQS9WQQmJ2uQ46LZdyFzkbSodUabGDAyFS+qTEwUg@mail.gmail.com>
	<5028CEE70200007800094623@nat28.tlf.novell.com>
In-Reply-To: <5028CEE70200007800094623@nat28.tlf.novell.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: [Xen-devel] Ping: Re: [PATCH] Boot PV guests with more than 128GB
 (v2) for 3.7
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.08.12 at 09:54, "Jan Beulich" <JBeulich@suse.com> wrote:
>>>> On 03.08.12 at 16:46, Konrad Rzeszutek Wilk <konrad@darnok.org> wrote:
>> Didn't get to it yet. Sorry for top posting. If you have a patch ready I
>> can test it on Monday - travelling now.
> 
> So here's what I was thinking of (compile tested only).

Obviously, if this works, I'd like to see this included in 4.2 (and
4.1-testing).

Jan

> --- a/tools/libxc/xc_dom_x86.c
> +++ b/tools/libxc/xc_dom_x86.c
> @@ -241,7 +241,7 @@ static int setup_pgtables_x86_32_pae(str
>      l3_pgentry_64_t *l3tab;
>      l2_pgentry_64_t *l2tab = NULL;
>      l1_pgentry_64_t *l1tab = NULL;
> -    unsigned long l3off, l2off, l1off;
> +    unsigned long l3off, l2off = 0, l1off;
>      xen_vaddr_t addr;
>      xen_pfn_t pgpfn;
>      xen_pfn_t l3mfn = xc_dom_p2m_guest(dom, l3pfn);
> @@ -283,8 +283,6 @@ static int setup_pgtables_x86_32_pae(str
>              l2off = l2_table_offset_pae(addr);
>              l2tab[l2off] =
>                  pfn_to_paddr(xc_dom_p2m_guest(dom, l1pfn)) | L2_PROT;
> -            if ( l2off == (L2_PAGETABLE_ENTRIES_PAE - 1) )
> -                l2tab = NULL;
>              l1pfn++;
>          }
>  
> @@ -296,8 +294,13 @@ static int setup_pgtables_x86_32_pae(str
>          if ( (addr >= dom->pgtables_seg.vstart) &&
>               (addr < dom->pgtables_seg.vend) )
>              l1tab[l1off] &= ~_PAGE_RW; /* page tables are r/o */
> +
>          if ( l1off == (L1_PAGETABLE_ENTRIES_PAE - 1) )
> +        {
>              l1tab = NULL;
> +            if ( l2off == (L2_PAGETABLE_ENTRIES_PAE - 1) )
> +                l2tab = NULL;
> +        }
>      }
>  
>      if ( dom->virt_pgtab_end <= 0xc0000000 )
> @@ -340,7 +343,7 @@ static int setup_pgtables_x86_64(struct 
>      l3_pgentry_64_t *l3tab = NULL;
>      l2_pgentry_64_t *l2tab = NULL;
>      l1_pgentry_64_t *l1tab = NULL;
> -    uint64_t l4off, l3off, l2off, l1off;
> +    uint64_t l4off, l3off = 0, l2off = 0, l1off;
>      uint64_t addr;
>      xen_pfn_t pgpfn;
>  
> @@ -364,8 +367,6 @@ static int setup_pgtables_x86_64(struct 
>              l3off = l3_table_offset_x86_64(addr);
>              l3tab[l3off] =
>                  pfn_to_paddr(xc_dom_p2m_guest(dom, l2pfn)) | L3_PROT;
> -            if ( l3off == (L3_PAGETABLE_ENTRIES_X86_64 - 1) )
> -                l3tab = NULL;
>              l2pfn++;
>          }
>  
> @@ -376,8 +377,6 @@ static int setup_pgtables_x86_64(struct 
>              l2off = l2_table_offset_x86_64(addr);
>              l2tab[l2off] =
>                  pfn_to_paddr(xc_dom_p2m_guest(dom, l1pfn)) | L2_PROT;
> -            if ( l2off == (L2_PAGETABLE_ENTRIES_X86_64 - 1) )
> -                l2tab = NULL;
>              l1pfn++;
>          }
>  
> @@ -389,8 +388,17 @@ static int setup_pgtables_x86_64(struct 
>          if ( (addr >= dom->pgtables_seg.vstart) && 
>               (addr < dom->pgtables_seg.vend) )
>              l1tab[l1off] &= ~_PAGE_RW; /* page tables are r/o */
> +
>          if ( l1off == (L1_PAGETABLE_ENTRIES_X86_64 - 1) )
> +        {
>              l1tab = NULL;
> +            if ( l2off == (L2_PAGETABLE_ENTRIES_X86_64 - 1) )
> +            {
> +                l2tab = NULL;
> +                if ( l3off == (L3_PAGETABLE_ENTRIES_X86_64 - 1) )
> +                    l3tab = NULL;
> +            }
> +        }
>      }
>      return 0;
>  }
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org 
> http://lists.xen.org/xen-devel 




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

From xen-devel-bounces@lists.xen.org Mon Sep 03 06:34:10 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Sep 2012 06: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 1T8QE1-0000LD-96; Mon, 03 Sep 2012 06:33:33 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1T8QE0-0000L8-Oi
	for xen-devel@lists.xen.org; Mon, 03 Sep 2012 06:33:32 +0000
Received: from [85.158.138.51:5951] by server-7.bemta-3.messagelabs.com id
	E3/2C-32000-B3F44405; Mon, 03 Sep 2012 06:33:31 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1346654009!21879864!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM3ODU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9487 invoked from network); 3 Sep 2012 06:33:29 -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;
	3 Sep 2012 06:33:29 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 03 Sep 2012 07:33:28 +0100
Message-Id: <50446B5402000078000981F4@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 03 Sep 2012 07:33:24 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: <konrad@darnok.org>,
 "Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>
References: <1343745804-28028-1-git-send-email-konrad.wilk@oracle.com>
	<20120801155040.GB15812@phenom.dumpdata.com>
	<501A5EF7020000780009219C@nat28.tlf.novell.com>
	<20120802141710.GF16749@phenom.dumpdata.com>
	<20120802160403.02de484e@mantra.us.oracle.com>
	<20120803133001.GA13750@andromeda.dapyr.net>
	<501BF44602000078000928B4@nat28.tlf.novell.com>
	<CAPbh3rsXaqQS9WQQmJ2uQ46LZdyFzkbSodUabGDAyFS+qTEwUg@mail.gmail.com>
	<5028CEE70200007800094623@nat28.tlf.novell.com>
In-Reply-To: <5028CEE70200007800094623@nat28.tlf.novell.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: [Xen-devel] Ping: Re: [PATCH] Boot PV guests with more than 128GB
 (v2) for 3.7
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.08.12 at 09:54, "Jan Beulich" <JBeulich@suse.com> wrote:
>>>> On 03.08.12 at 16:46, Konrad Rzeszutek Wilk <konrad@darnok.org> wrote:
>> Didn't get to it yet. Sorry for top posting. If you have a patch ready I
>> can test it on Monday - travelling now.
> 
> So here's what I was thinking of (compile tested only).

Obviously, if this works, I'd like to see this included in 4.2 (and
4.1-testing).

Jan

> --- a/tools/libxc/xc_dom_x86.c
> +++ b/tools/libxc/xc_dom_x86.c
> @@ -241,7 +241,7 @@ static int setup_pgtables_x86_32_pae(str
>      l3_pgentry_64_t *l3tab;
>      l2_pgentry_64_t *l2tab = NULL;
>      l1_pgentry_64_t *l1tab = NULL;
> -    unsigned long l3off, l2off, l1off;
> +    unsigned long l3off, l2off = 0, l1off;
>      xen_vaddr_t addr;
>      xen_pfn_t pgpfn;
>      xen_pfn_t l3mfn = xc_dom_p2m_guest(dom, l3pfn);
> @@ -283,8 +283,6 @@ static int setup_pgtables_x86_32_pae(str
>              l2off = l2_table_offset_pae(addr);
>              l2tab[l2off] =
>                  pfn_to_paddr(xc_dom_p2m_guest(dom, l1pfn)) | L2_PROT;
> -            if ( l2off == (L2_PAGETABLE_ENTRIES_PAE - 1) )
> -                l2tab = NULL;
>              l1pfn++;
>          }
>  
> @@ -296,8 +294,13 @@ static int setup_pgtables_x86_32_pae(str
>          if ( (addr >= dom->pgtables_seg.vstart) &&
>               (addr < dom->pgtables_seg.vend) )
>              l1tab[l1off] &= ~_PAGE_RW; /* page tables are r/o */
> +
>          if ( l1off == (L1_PAGETABLE_ENTRIES_PAE - 1) )
> +        {
>              l1tab = NULL;
> +            if ( l2off == (L2_PAGETABLE_ENTRIES_PAE - 1) )
> +                l2tab = NULL;
> +        }
>      }
>  
>      if ( dom->virt_pgtab_end <= 0xc0000000 )
> @@ -340,7 +343,7 @@ static int setup_pgtables_x86_64(struct 
>      l3_pgentry_64_t *l3tab = NULL;
>      l2_pgentry_64_t *l2tab = NULL;
>      l1_pgentry_64_t *l1tab = NULL;
> -    uint64_t l4off, l3off, l2off, l1off;
> +    uint64_t l4off, l3off = 0, l2off = 0, l1off;
>      uint64_t addr;
>      xen_pfn_t pgpfn;
>  
> @@ -364,8 +367,6 @@ static int setup_pgtables_x86_64(struct 
>              l3off = l3_table_offset_x86_64(addr);
>              l3tab[l3off] =
>                  pfn_to_paddr(xc_dom_p2m_guest(dom, l2pfn)) | L3_PROT;
> -            if ( l3off == (L3_PAGETABLE_ENTRIES_X86_64 - 1) )
> -                l3tab = NULL;
>              l2pfn++;
>          }
>  
> @@ -376,8 +377,6 @@ static int setup_pgtables_x86_64(struct 
>              l2off = l2_table_offset_x86_64(addr);
>              l2tab[l2off] =
>                  pfn_to_paddr(xc_dom_p2m_guest(dom, l1pfn)) | L2_PROT;
> -            if ( l2off == (L2_PAGETABLE_ENTRIES_X86_64 - 1) )
> -                l2tab = NULL;
>              l1pfn++;
>          }
>  
> @@ -389,8 +388,17 @@ static int setup_pgtables_x86_64(struct 
>          if ( (addr >= dom->pgtables_seg.vstart) && 
>               (addr < dom->pgtables_seg.vend) )
>              l1tab[l1off] &= ~_PAGE_RW; /* page tables are r/o */
> +
>          if ( l1off == (L1_PAGETABLE_ENTRIES_X86_64 - 1) )
> +        {
>              l1tab = NULL;
> +            if ( l2off == (L2_PAGETABLE_ENTRIES_X86_64 - 1) )
> +            {
> +                l2tab = NULL;
> +                if ( l3off == (L3_PAGETABLE_ENTRIES_X86_64 - 1) )
> +                    l3tab = NULL;
> +            }
> +        }
>      }
>      return 0;
>  }
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org 
> http://lists.xen.org/xen-devel 




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

From xen-devel-bounces@lists.xen.org Mon Sep 03 06:42:54 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Sep 2012 06: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 1T8QMW-0000Uo-AF; Mon, 03 Sep 2012 06:42: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 1T8QMV-0000Uj-6V
	for xen-devel@lists.xen.org; Mon, 03 Sep 2012 06:42:19 +0000
Received: from [85.158.138.51:38960] by server-2.bemta-3.messagelabs.com id
	D1/2E-04862-A4154405; Mon, 03 Sep 2012 06:42:18 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1346654536!28250158!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM3ODU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26304 invoked from network); 3 Sep 2012 06:42:16 -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;
	3 Sep 2012 06:42:16 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 03 Sep 2012 07:42:16 +0100
Message-Id: <50446D630200007800098201@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 03 Sep 2012 07:42:11 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Keir Fraser" <keir.xen@gmail.com>
References: <5040FBEA0200007800097EE5@nat28.tlf.novell.com>
	<CC66A9E7.3D875%keir.xen@gmail.com>
In-Reply-To: <CC66A9E7.3D875%keir.xen@gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH,
 v3] x86/HVM: RTC periodic timer emulation adjustments
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 31.08.12 at 18:50, Keir Fraser <keir.xen@gmail.com> wrote:
> On 31/08/2012 17:01, "Jan Beulich" <JBeulich@suse.com> wrote:
>> @@ -405,9 +407,9 @@ static int rtc_ioport_write(void *opaque
>>          break;
>>      case RTC_REG_A:
>>          /* UIP bit is read only */
>> -        s->hw.cmos_data[RTC_REG_A] = (data & ~RTC_UIP) |
>> -            (s->hw.cmos_data[RTC_REG_A] & RTC_UIP);
>> -        rtc_timer_update(s);
>> +        s->hw.cmos_data[RTC_REG_A] = (data & ~RTC_UIP) | (orig & RTC_UIP);
>> +        if ( (data ^ orig) & (RTC_RATE_SELECT | RTC_DIV_CTL) )
> 
> Please change to 'if ( (data ^ orig) & ~RTC_UIP )'. It is shorter and
> matches the style of the immediately preceding line.
> 
> Once you make this change:
> Acked-by: Keir Fraser <keir@xen.org>

I made the change before committing, albeit I disagree - what
we care about here are explicitly the two fields that the original
version named. Their mask just accidentally happens to be the
complement of RTC_UIP. Whereas in the lines above we
specifically care about that one flag...

Jan


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

From xen-devel-bounces@lists.xen.org Mon Sep 03 06:42:54 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Sep 2012 06: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 1T8QMW-0000Uo-AF; Mon, 03 Sep 2012 06:42: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 1T8QMV-0000Uj-6V
	for xen-devel@lists.xen.org; Mon, 03 Sep 2012 06:42:19 +0000
Received: from [85.158.138.51:38960] by server-2.bemta-3.messagelabs.com id
	D1/2E-04862-A4154405; Mon, 03 Sep 2012 06:42:18 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1346654536!28250158!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM3ODU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26304 invoked from network); 3 Sep 2012 06:42:16 -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;
	3 Sep 2012 06:42:16 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 03 Sep 2012 07:42:16 +0100
Message-Id: <50446D630200007800098201@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 03 Sep 2012 07:42:11 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Keir Fraser" <keir.xen@gmail.com>
References: <5040FBEA0200007800097EE5@nat28.tlf.novell.com>
	<CC66A9E7.3D875%keir.xen@gmail.com>
In-Reply-To: <CC66A9E7.3D875%keir.xen@gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH,
 v3] x86/HVM: RTC periodic timer emulation adjustments
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 31.08.12 at 18:50, Keir Fraser <keir.xen@gmail.com> wrote:
> On 31/08/2012 17:01, "Jan Beulich" <JBeulich@suse.com> wrote:
>> @@ -405,9 +407,9 @@ static int rtc_ioport_write(void *opaque
>>          break;
>>      case RTC_REG_A:
>>          /* UIP bit is read only */
>> -        s->hw.cmos_data[RTC_REG_A] = (data & ~RTC_UIP) |
>> -            (s->hw.cmos_data[RTC_REG_A] & RTC_UIP);
>> -        rtc_timer_update(s);
>> +        s->hw.cmos_data[RTC_REG_A] = (data & ~RTC_UIP) | (orig & RTC_UIP);
>> +        if ( (data ^ orig) & (RTC_RATE_SELECT | RTC_DIV_CTL) )
> 
> Please change to 'if ( (data ^ orig) & ~RTC_UIP )'. It is shorter and
> matches the style of the immediately preceding line.
> 
> Once you make this change:
> Acked-by: Keir Fraser <keir@xen.org>

I made the change before committing, albeit I disagree - what
we care about here are explicitly the two fields that the original
version named. Their mask just accidentally happens to be the
complement of RTC_UIP. Whereas in the lines above we
specifically care about that one flag...

Jan


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

From xen-devel-bounces@lists.xen.org Mon Sep 03 06:57:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Sep 2012 06:57:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T8QaB-0000fB-P5; Mon, 03 Sep 2012 06:56: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 1T8QaA-0000f6-JV
	for xen-devel@lists.xen.org; Mon, 03 Sep 2012 06:56:26 +0000
Received: from [85.158.143.35:44848] by server-2.bemta-4.messagelabs.com id
	84/C6-21239-99454405; Mon, 03 Sep 2012 06:56:25 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1346655329!5920719!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM3ODU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29314 invoked from network); 3 Sep 2012 06:55:29 -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;
	3 Sep 2012 06:55:29 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 03 Sep 2012 07:55:28 +0100
Message-Id: <5044707C020000780009820F@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 03 Sep 2012 07:55:24 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Andrew Cooper" <andrew.cooper3@citrix.com>
References: <5040D05D.8090808@citrix.com>
	<5040F61A0200007800097E86@nat28.tlf.novell.com>
	<5040EB1B.80004@citrix.com>
In-Reply-To: <5040EB1B.80004@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] (v2) docs/command line: Clarify the behavior with
 invalid input.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.08.12 at 18:49, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
> On 31/08/12 16:36, Jan Beulich wrote:
>> I don't think we should specifically document the behavior for
>> unexpected value; instead, the behavior should simply be
>> "undefined".
> 
> Yes ok.  v2 attached.

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

Thanks.


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

From xen-devel-bounces@lists.xen.org Mon Sep 03 06:57:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Sep 2012 06:57:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T8QaB-0000fB-P5; Mon, 03 Sep 2012 06:56: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 1T8QaA-0000f6-JV
	for xen-devel@lists.xen.org; Mon, 03 Sep 2012 06:56:26 +0000
Received: from [85.158.143.35:44848] by server-2.bemta-4.messagelabs.com id
	84/C6-21239-99454405; Mon, 03 Sep 2012 06:56:25 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1346655329!5920719!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM3ODU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29314 invoked from network); 3 Sep 2012 06:55:29 -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;
	3 Sep 2012 06:55:29 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 03 Sep 2012 07:55:28 +0100
Message-Id: <5044707C020000780009820F@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 03 Sep 2012 07:55:24 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Andrew Cooper" <andrew.cooper3@citrix.com>
References: <5040D05D.8090808@citrix.com>
	<5040F61A0200007800097E86@nat28.tlf.novell.com>
	<5040EB1B.80004@citrix.com>
In-Reply-To: <5040EB1B.80004@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] (v2) docs/command line: Clarify the behavior with
 invalid input.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.08.12 at 18:49, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
> On 31/08/12 16:36, Jan Beulich wrote:
>> I don't think we should specifically document the behavior for
>> unexpected value; instead, the behavior should simply be
>> "undefined".
> 
> Yes ok.  v2 attached.

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

Thanks.


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

From xen-devel-bounces@lists.xen.org Mon Sep 03 06:58:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Sep 2012 06:58: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 1T8QbP-0000id-82; Mon, 03 Sep 2012 06:57: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 1T8QbM-0000iQ-S0
	for xen-devel@lists.xen.org; Mon, 03 Sep 2012 06:57:41 +0000
Received: from [85.158.143.35:55830] by server-1.bemta-4.messagelabs.com id
	DE/15-12504-4E454405; Mon, 03 Sep 2012 06:57:40 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1346655456!16333615!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM3ODU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28167 invoked from network); 3 Sep 2012 06:57:37 -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;
	3 Sep 2012 06:57:37 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 03 Sep 2012 07:57:36 +0100
Message-Id: <504470FD0200007800098213@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 03 Sep 2012 07:57:33 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__PartE5D4FCCD.0__="
Subject: [Xen-devel] [PATCH] make domain_create() return a proper error code
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
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.

--=__PartE5D4FCCD.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

While triggered by the XSA-9 fix, this really is of more general use;
that fix just pointed out very sharply that the current situation
with all domain creation failures reported to user (tools) space as
-ENOMEM is very unfortunate (actively misleading users _and_ support
personnel).

Pull over the pointer <-> error code conversion infrastructure from
Linux, and use it in domain_create() and all it callers.

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

--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -26,6 +26,7 @@
 #include <xen/serial.h>
 #include <xen/sched.h>
 #include <xen/console.h>
+#include <xen/err.h>
 #include <xen/init.h>
 #include <xen/irq.h>
 #include <xen/mm.h>
@@ -237,7 +238,7 @@ void __init start_xen(unsigned long boot
=20
     /* Create initial domain 0. */
     dom0 =3D domain_create(0, 0, 0);
-    if ( dom0 =3D=3D NULL )
+    if ( IS_ERR(dom0) )
             printk("domain_create failed\n");
     if ( (dom0 =3D=3D NULL) || (alloc_dom0_vcpu0() =3D=3D NULL) )
             panic("Error creating domain 0\n");
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -91,7 +91,7 @@
 #include <xen/mm.h>
 #include <xen/domain.h>
 #include <xen/sched.h>
-#include <xen/errno.h>
+#include <xen/err.h>
 #include <xen/perfc.h>
 #include <xen/irq.h>
 #include <xen/softirq.h>
@@ -309,7 +309,7 @@ void __init arch_init_memory(void)
      * their domain field set to dom_xen.
      */
     dom_xen =3D domain_create(DOMID_XEN, DOMCRF_dummy, 0);
-    BUG_ON(dom_xen =3D=3D NULL);
+    BUG_ON(IS_ERR(dom_xen));
=20
     /*
      * Initialise our DOMID_IO domain.
@@ -317,14 +317,14 @@ void __init arch_init_memory(void)
      * array. Mappings occur at the priv of the caller.
      */
     dom_io =3D domain_create(DOMID_IO, DOMCRF_dummy, 0);
-    BUG_ON(dom_io =3D=3D NULL);
+    BUG_ON(IS_ERR(dom_io));
    =20
     /*
-     * Initialise our DOMID_IO domain.
+     * Initialise our COW domain.
      * This domain owns sharable pages.
      */
     dom_cow =3D domain_create(DOMID_COW, DOMCRF_dummy, 0);
-    BUG_ON(dom_cow =3D=3D NULL);
+    BUG_ON(IS_ERR(dom_cow));
=20
     /* First 1MB of RAM is historically marked as I/O. */
     for ( i =3D 0; i < 0x100; i++ )
--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@ -1,6 +1,7 @@
 #include <xen/config.h>
 #include <xen/init.h>
 #include <xen/lib.h>
+#include <xen/err.h>
 #include <xen/sched.h>
 #include <xen/sched-if.h>
 #include <xen/domain.h>
@@ -1319,7 +1320,7 @@ void __init __start_xen(unsigned long mb
=20
     /* Create initial domain 0. */
     dom0 =3D domain_create(0, DOMCRF_s3_integrity, 0);
-    if ( (dom0 =3D=3D NULL) || (alloc_dom0_vcpu0() =3D=3D NULL) )
+    if ( IS_ERR(dom0) || (alloc_dom0_vcpu0() =3D=3D NULL) )
         panic("Error creating domain 0\n");
=20
     dom0->is_privileged =3D 1;
--- a/xen/common/cpupool.c
+++ b/xen/common/cpupool.c
@@ -370,14 +370,18 @@ out:
 int cpupool_add_domain(struct domain *d, int poolid)
 {
     struct cpupool *c;
-    int rc =3D 1;
+    int rc;
     int n_dom =3D 0;
=20
     if ( poolid =3D=3D CPUPOOLID_NONE )
         return 0;
     spin_lock(&cpupool_lock);
     c =3D cpupool_find_by_id(poolid);
-    if ( (c !=3D NULL) && cpumask_weight(c->cpu_valid) )
+    if ( c =3D=3D NULL )
+        rc =3D -ESRCH;
+    else if ( !cpumask_weight(c->cpu_valid) )
+        rc =3D -ENODEV;
+    else
     {
         c->n_dom++;
         n_dom =3D c->n_dom;
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -9,7 +9,7 @@
 #include <xen/init.h>
 #include <xen/lib.h>
 #include <xen/ctype.h>
-#include <xen/errno.h>
+#include <xen/err.h>
 #include <xen/sched.h>
 #include <xen/sched-if.h>
 #include <xen/domain.h>
@@ -196,17 +196,17 @@ 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 =
1u<<5 };
-    int init_status =3D 0;
+    int err, init_status =3D 0;
     int poolid =3D CPUPOOLID_NONE;
=20
     if ( (d =3D alloc_domain_struct()) =3D=3D NULL )
-        return NULL;
+        return ERR_PTR(-ENOMEM);
=20
     d->domain_id =3D domid;
=20
     lock_profile_register_struct(LOCKPROF_TYPE_PERDOM, d, domid, =
"Domain");
=20
-    if ( xsm_alloc_security_domain(d) !=3D 0 )
+    if ( (err =3D xsm_alloc_security_domain(d)) !=3D 0 )
         goto fail;
     init_status |=3D INIT_xsm;
=20
@@ -226,6 +226,7 @@ struct domain *domain_create(
     spin_lock_init(&d->shutdown_lock);
     d->shutdown_code =3D -1;
=20
+    err =3D -ENOMEM;
     if ( !zalloc_cpumask_var(&d->domain_dirty_cpumask) )
         goto fail;
=20
@@ -251,7 +252,7 @@ struct domain *domain_create(
=20
     if ( !is_idle_domain(d) )
     {
-        if ( xsm_domain_create(d, ssidref) !=3D 0 )
+        if ( (err =3D xsm_domain_create(d, ssidref)) !=3D 0 )
             goto fail;
=20
         d->is_paused_by_controller =3D 1;
@@ -266,29 +267,30 @@ struct domain *domain_create(
=20
         radix_tree_init(&d->pirq_tree);
=20
-        if ( evtchn_init(d) !=3D 0 )
+        if ( (err =3D evtchn_init(d)) !=3D 0 )
             goto fail;
         init_status |=3D INIT_evtchn;
=20
-        if ( grant_table_create(d) !=3D 0 )
+        if ( (err =3D grant_table_create(d)) !=3D 0 )
             goto fail;
         init_status |=3D INIT_gnttab;
=20
         poolid =3D 0;
=20
+        err =3D -ENOMEM;
         d->mem_event =3D xzalloc(struct mem_event_per_domain);
         if ( !d->mem_event )
             goto fail;
     }
=20
-    if ( arch_domain_create(d, domcr_flags) !=3D 0 )
+    if ( (err =3D arch_domain_create(d, domcr_flags)) !=3D 0 )
         goto fail;
     init_status |=3D INIT_arch;
=20
-    if ( cpupool_add_domain(d, poolid) !=3D 0 )
+    if ( (err =3D cpupool_add_domain(d, poolid)) !=3D 0 )
         goto fail;
=20
-    if ( sched_init_domain(d) !=3D 0 )
+    if ( (err =3D sched_init_domain(d)) !=3D 0 )
         goto fail;
=20
     if ( !is_idle_domain(d) )
@@ -329,7 +331,7 @@ struct domain *domain_create(
         xsm_free_security_domain(d);
     free_cpumask_var(d->domain_dirty_cpumask);
     free_domain_struct(d);
-    return NULL;
+    return ERR_PTR(err);
 }
=20
=20
--- a/xen/common/domctl.c
+++ b/xen/common/domctl.c
@@ -9,6 +9,7 @@
 #include <xen/config.h>
 #include <xen/types.h>
 #include <xen/lib.h>
+#include <xen/err.h>
 #include <xen/mm.h>
 #include <xen/sched.h>
 #include <xen/sched-if.h>
@@ -455,10 +456,12 @@ long do_domctl(XEN_GUEST_HANDLE(xen_domc
         if ( op->u.createdomain.flags & XEN_DOMCTL_CDF_oos_off )
             domcr_flags |=3D DOMCRF_oos_off;
=20
-        ret =3D -ENOMEM;
         d =3D domain_create(dom, domcr_flags, op->u.createdomain.ssidref);=

-        if ( d =3D=3D NULL )
+        if ( IS_ERR(d) )
+        {
+            ret =3D PTR_ERR(d);
             break;
+        }
=20
         ret =3D 0;
=20
--- a/xen/common/schedule.c
+++ b/xen/common/schedule.c
@@ -28,7 +28,7 @@
 #include <xen/softirq.h>
 #include <xen/trace.h>
 #include <xen/mm.h>
-#include <xen/errno.h>
+#include <xen/err.h>
 #include <xen/guest_access.h>
 #include <xen/multicall.h>
 #include <xen/cpu.h>
@@ -1323,7 +1323,7 @@ void __init scheduler_init(void)
         panic("scheduler returned error on init\n");
=20
     idle_domain =3D domain_create(DOMID_IDLE, 0, 0);
-    BUG_ON(idle_domain =3D=3D NULL);
+    BUG_ON(IS_ERR(idle_domain));
     idle_domain->vcpu =3D idle_vcpu;
     idle_domain->max_vcpus =3D nr_cpu_ids;
     if ( alloc_vcpu(idle_domain, 0, 0) =3D=3D NULL )
--- /dev/null
+++ b/xen/include/xen/err.h
@@ -0,0 +1,57 @@
+#if !defined(__XEN_ERR_H__) && !defined(__ASSEMBLY__)
+#define __XEN_ERR_H__
+
+#include <xen/compiler.h>
+#include <xen/errno.h>
+
+/*
+ * Kernel pointers have redundant information, so we can use a
+ * scheme where we can return either an error code or a dentry
+ * pointer with the same return value.
+ *
+ * This could be a per-architecture thing, to allow different
+ * error and pointer decisions.
+ */
+#define MAX_ERRNO	4095
+
+#define IS_ERR_VALUE(x) unlikely((x) >=3D (unsigned long)-MAX_ERRNO)
+
+static inline void *__must_check ERR_PTR(long error)
+{
+	return (void *)error;
+}
+
+static inline long __must_check PTR_ERR(const void *ptr)
+{
+	return (long)ptr;
+}
+
+static inline long __must_check IS_ERR(const void *ptr)
+{
+	return IS_ERR_VALUE((unsigned long)ptr);
+}
+
+static inline long __must_check IS_ERR_OR_NULL(const void *ptr)
+{
+	return !ptr || IS_ERR_VALUE((unsigned long)ptr);
+}
+
+/**
+ * ERR_CAST - Explicitly cast an error-valued pointer to another pointer =
type
+ * @ptr: The pointer to cast.
+ *
+ * Explicitly cast an error-valued pointer to another pointer type in =
such a
+ * way as to make it clear that's what's going on.
+ */
+static inline void * __must_check ERR_CAST(const void *ptr)
+{
+	/* cast away the const */
+	return (void *)ptr;
+}
+
+static inline int __must_check PTR_RET(const void *ptr)
+{
+	return IS_ERR(ptr) ? PTR_ERR(ptr) : 0;
+}
+
+#endif /* __XEN_ERR_H__ */



--=__PartE5D4FCCD.0__=
Content-Type: text/plain; name="domain_create-return-value.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="domain_create-return-value.patch"

make domain_create() return a proper error code=0A=0AWhile triggered by =
the XSA-9 fix, this really is of more general use;=0Athat fix just pointed =
out very sharply that the current situation=0Awith all domain creation =
failures reported to user (tools) space as=0A-ENOMEM is very unfortunate =
(actively misleading users _and_ support=0Apersonnel).=0A=0APull over the =
pointer <-> error code conversion infrastructure from=0ALinux, and use it =
in domain_create() and all it callers.=0A=0ASigned-off-by: Jan Beulich =
<jbeulich@suse.com>=0A=0A--- a/xen/arch/arm/setup.c=0A+++ b/xen/arch/arm/se=
tup.c=0A@@ -26,6 +26,7 @@=0A #include <xen/serial.h>=0A #include <xen/sched=
.h>=0A #include <xen/console.h>=0A+#include <xen/err.h>=0A #include =
<xen/init.h>=0A #include <xen/irq.h>=0A #include <xen/mm.h>=0A@@ -237,7 =
+238,7 @@ void __init start_xen(unsigned long boot=0A =0A     /* Create =
initial domain 0. */=0A     dom0 =3D domain_create(0, 0, 0);=0A-    if ( =
dom0 =3D=3D NULL )=0A+    if ( IS_ERR(dom0) )=0A             printk("domain=
_create failed\n");=0A     if ( (dom0 =3D=3D NULL) || (alloc_dom0_vcpu0() =
=3D=3D NULL) )=0A             panic("Error creating domain 0\n");=0A--- =
a/xen/arch/x86/mm.c=0A+++ b/xen/arch/x86/mm.c=0A@@ -91,7 +91,7 @@=0A =
#include <xen/mm.h>=0A #include <xen/domain.h>=0A #include <xen/sched.h>=0A=
-#include <xen/errno.h>=0A+#include <xen/err.h>=0A #include <xen/perfc.h>=
=0A #include <xen/irq.h>=0A #include <xen/softirq.h>=0A@@ -309,7 +309,7 @@ =
void __init arch_init_memory(void)=0A      * their domain field set to =
dom_xen.=0A      */=0A     dom_xen =3D domain_create(DOMID_XEN, DOMCRF_dumm=
y, 0);=0A-    BUG_ON(dom_xen =3D=3D NULL);=0A+    BUG_ON(IS_ERR(dom_xen));=
=0A =0A     /*=0A      * Initialise our DOMID_IO domain.=0A@@ -317,14 =
+317,14 @@ void __init arch_init_memory(void)=0A      * array. Mappings =
occur at the priv of the caller.=0A      */=0A     dom_io =3D domain_create=
(DOMID_IO, DOMCRF_dummy, 0);=0A-    BUG_ON(dom_io =3D=3D NULL);=0A+    =
BUG_ON(IS_ERR(dom_io));=0A     =0A     /*=0A-     * Initialise our =
DOMID_IO domain.=0A+     * Initialise our COW domain.=0A      * This =
domain owns sharable pages.=0A      */=0A     dom_cow =3D domain_create(DOM=
ID_COW, DOMCRF_dummy, 0);=0A-    BUG_ON(dom_cow =3D=3D NULL);=0A+    =
BUG_ON(IS_ERR(dom_cow));=0A =0A     /* First 1MB of RAM is historically =
marked as I/O. */=0A     for ( i =3D 0; i < 0x100; i++ )=0A--- a/xen/arch/x=
86/setup.c=0A+++ b/xen/arch/x86/setup.c=0A@@ -1,6 +1,7 @@=0A #include =
<xen/config.h>=0A #include <xen/init.h>=0A #include <xen/lib.h>=0A+#include=
 <xen/err.h>=0A #include <xen/sched.h>=0A #include <xen/sched-if.h>=0A =
#include <xen/domain.h>=0A@@ -1319,7 +1320,7 @@ void __init __start_xen(uns=
igned long mb=0A =0A     /* Create initial domain 0. */=0A     dom0 =3D =
domain_create(0, DOMCRF_s3_integrity, 0);=0A-    if ( (dom0 =3D=3D NULL) =
|| (alloc_dom0_vcpu0() =3D=3D NULL) )=0A+    if ( IS_ERR(dom0) || =
(alloc_dom0_vcpu0() =3D=3D NULL) )=0A         panic("Error creating domain =
0\n");=0A =0A     dom0->is_privileged =3D 1;=0A--- a/xen/common/cpupool.c=
=0A+++ b/xen/common/cpupool.c=0A@@ -370,14 +370,18 @@ out:=0A int =
cpupool_add_domain(struct domain *d, int poolid)=0A {=0A     struct =
cpupool *c;=0A-    int rc =3D 1;=0A+    int rc;=0A     int n_dom =3D 0;=0A =
=0A     if ( poolid =3D=3D CPUPOOLID_NONE )=0A         return 0;=0A     =
spin_lock(&cpupool_lock);=0A     c =3D cpupool_find_by_id(poolid);=0A-    =
if ( (c !=3D NULL) && cpumask_weight(c->cpu_valid) )=0A+    if ( c =3D=3D =
NULL )=0A+        rc =3D -ESRCH;=0A+    else if ( !cpumask_weight(c->cpu_va=
lid) )=0A+        rc =3D -ENODEV;=0A+    else=0A     {=0A         =
c->n_dom++;=0A         n_dom =3D c->n_dom;=0A--- a/xen/common/domain.c=0A++=
+ b/xen/common/domain.c=0A@@ -9,7 +9,7 @@=0A #include <xen/init.h>=0A =
#include <xen/lib.h>=0A #include <xen/ctype.h>=0A-#include <xen/errno.h>=0A=
+#include <xen/err.h>=0A #include <xen/sched.h>=0A #include <xen/sched-if.h=
>=0A #include <xen/domain.h>=0A@@ -196,17 +196,17 @@ struct domain =
*domain_create(=0A     struct domain *d, **pd;=0A     enum { INIT_xsm =3D =
1u<<0, INIT_watchdog =3D 1u<<1, INIT_rangeset =3D 1u<<2,=0A            =
INIT_evtchn =3D 1u<<3, INIT_gnttab =3D 1u<<4, INIT_arch =3D 1u<<5 };=0A-   =
 int init_status =3D 0;=0A+    int err, init_status =3D 0;=0A     int =
poolid =3D CPUPOOLID_NONE;=0A =0A     if ( (d =3D alloc_domain_struct()) =
=3D=3D NULL )=0A-        return NULL;=0A+        return ERR_PTR(-ENOMEM);=
=0A =0A     d->domain_id =3D domid;=0A =0A     lock_profile_register_struct=
(LOCKPROF_TYPE_PERDOM, d, domid, "Domain");=0A =0A-    if ( xsm_alloc_secur=
ity_domain(d) !=3D 0 )=0A+    if ( (err =3D xsm_alloc_security_domain(d)) =
!=3D 0 )=0A         goto fail;=0A     init_status |=3D INIT_xsm;=0A =0A@@ =
-226,6 +226,7 @@ struct domain *domain_create(=0A     spin_lock_init(&d->sh=
utdown_lock);=0A     d->shutdown_code =3D -1;=0A =0A+    err =3D =
-ENOMEM;=0A     if ( !zalloc_cpumask_var(&d->domain_dirty_cpumask) )=0A    =
     goto fail;=0A =0A@@ -251,7 +252,7 @@ struct domain *domain_create(=0A =
=0A     if ( !is_idle_domain(d) )=0A     {=0A-        if ( xsm_domain_creat=
e(d, ssidref) !=3D 0 )=0A+        if ( (err =3D xsm_domain_create(d, =
ssidref)) !=3D 0 )=0A             goto fail;=0A =0A         d->is_paused_by=
_controller =3D 1;=0A@@ -266,29 +267,30 @@ struct domain *domain_create(=0A=
 =0A         radix_tree_init(&d->pirq_tree);=0A =0A-        if ( evtchn_ini=
t(d) !=3D 0 )=0A+        if ( (err =3D evtchn_init(d)) !=3D 0 )=0A         =
    goto fail;=0A         init_status |=3D INIT_evtchn;=0A =0A-        if =
( grant_table_create(d) !=3D 0 )=0A+        if ( (err =3D grant_table_creat=
e(d)) !=3D 0 )=0A             goto fail;=0A         init_status |=3D =
INIT_gnttab;=0A =0A         poolid =3D 0;=0A =0A+        err =3D =
-ENOMEM;=0A         d->mem_event =3D xzalloc(struct mem_event_per_domain);=
=0A         if ( !d->mem_event )=0A             goto fail;=0A     }=0A =
=0A-    if ( arch_domain_create(d, domcr_flags) !=3D 0 )=0A+    if ( (err =
=3D arch_domain_create(d, domcr_flags)) !=3D 0 )=0A         goto fail;=0A  =
   init_status |=3D INIT_arch;=0A =0A-    if ( cpupool_add_domain(d, =
poolid) !=3D 0 )=0A+    if ( (err =3D cpupool_add_domain(d, poolid)) !=3D =
0 )=0A         goto fail;=0A =0A-    if ( sched_init_domain(d) !=3D 0 =
)=0A+    if ( (err =3D sched_init_domain(d)) !=3D 0 )=0A         goto =
fail;=0A =0A     if ( !is_idle_domain(d) )=0A@@ -329,7 +331,7 @@ struct =
domain *domain_create(=0A         xsm_free_security_domain(d);=0A     =
free_cpumask_var(d->domain_dirty_cpumask);=0A     free_domain_struct(d);=0A=
-    return NULL;=0A+    return ERR_PTR(err);=0A }=0A =0A =0A--- a/xen/comm=
on/domctl.c=0A+++ b/xen/common/domctl.c=0A@@ -9,6 +9,7 @@=0A #include =
<xen/config.h>=0A #include <xen/types.h>=0A #include <xen/lib.h>=0A+#includ=
e <xen/err.h>=0A #include <xen/mm.h>=0A #include <xen/sched.h>=0A #include =
<xen/sched-if.h>=0A@@ -455,10 +456,12 @@ long do_domctl(XEN_GUEST_HANDLE(xe=
n_domc=0A         if ( op->u.createdomain.flags & XEN_DOMCTL_CDF_oos_off =
)=0A             domcr_flags |=3D DOMCRF_oos_off;=0A =0A-        ret =3D =
-ENOMEM;=0A         d =3D domain_create(dom, domcr_flags, op->u.createdomai=
n.ssidref);=0A-        if ( d =3D=3D NULL )=0A+        if ( IS_ERR(d) =
)=0A+        {=0A+            ret =3D PTR_ERR(d);=0A             break;=0A+=
        }=0A =0A         ret =3D 0;=0A =0A--- a/xen/common/schedule.c=0A+++=
 b/xen/common/schedule.c=0A@@ -28,7 +28,7 @@=0A #include <xen/softirq.h>=0A=
 #include <xen/trace.h>=0A #include <xen/mm.h>=0A-#include <xen/errno.h>=0A=
+#include <xen/err.h>=0A #include <xen/guest_access.h>=0A #include =
<xen/multicall.h>=0A #include <xen/cpu.h>=0A@@ -1323,7 +1323,7 @@ void =
__init scheduler_init(void)=0A         panic("scheduler returned error on =
init\n");=0A =0A     idle_domain =3D domain_create(DOMID_IDLE, 0, 0);=0A-  =
  BUG_ON(idle_domain =3D=3D NULL);=0A+    BUG_ON(IS_ERR(idle_domain));=0A  =
   idle_domain->vcpu =3D idle_vcpu;=0A     idle_domain->max_vcpus =3D =
nr_cpu_ids;=0A     if ( alloc_vcpu(idle_domain, 0, 0) =3D=3D NULL )=0A--- =
/dev/null=0A+++ b/xen/include/xen/err.h=0A@@ -0,0 +1,57 @@=0A+#if =
!defined(__XEN_ERR_H__) && !defined(__ASSEMBLY__)=0A+#define __XEN_ERR_H__=
=0A+=0A+#include <xen/compiler.h>=0A+#include <xen/errno.h>=0A+=0A+/*=0A+ =
* Kernel pointers have redundant information, so we can use a=0A+ * scheme =
where we can return either an error code or a dentry=0A+ * pointer with =
the same return value.=0A+ *=0A+ * This could be a per-architecture thing, =
to allow different=0A+ * error and pointer decisions.=0A+ */=0A+#define =
MAX_ERRNO	4095=0A+=0A+#define IS_ERR_VALUE(x) unlikely((x) >=3D =
(unsigned long)-MAX_ERRNO)=0A+=0A+static inline void *__must_check =
ERR_PTR(long error)=0A+{=0A+	return (void *)error;=0A+}=0A+=0A+static =
inline long __must_check PTR_ERR(const void *ptr)=0A+{=0A+	return =
(long)ptr;=0A+}=0A+=0A+static inline long __must_check IS_ERR(const void =
*ptr)=0A+{=0A+	return IS_ERR_VALUE((unsigned long)ptr);=0A+}=0A+=0A+static=
 inline long __must_check IS_ERR_OR_NULL(const void *ptr)=0A+{=0A+	=
return !ptr || IS_ERR_VALUE((unsigned long)ptr);=0A+}=0A+=0A+/**=0A+ * =
ERR_CAST - Explicitly cast an error-valued pointer to another pointer =
type=0A+ * @ptr: The pointer to cast.=0A+ *=0A+ * Explicitly cast an =
error-valued pointer to another pointer type in such a=0A+ * way as to =
make it clear that's what's going on.=0A+ */=0A+static inline void * =
__must_check ERR_CAST(const void *ptr)=0A+{=0A+	/* cast away the const =
*/=0A+	return (void *)ptr;=0A+}=0A+=0A+static inline int __must_check =
PTR_RET(const void *ptr)=0A+{=0A+	return IS_ERR(ptr) ? PTR_ERR(ptr) =
: 0;=0A+}=0A+=0A+#endif /* __XEN_ERR_H__ */=0A
--=__PartE5D4FCCD.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

--=__PartE5D4FCCD.0__=--


From xen-devel-bounces@lists.xen.org Mon Sep 03 06:58:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Sep 2012 06:58: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 1T8QbP-0000id-82; Mon, 03 Sep 2012 06:57: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 1T8QbM-0000iQ-S0
	for xen-devel@lists.xen.org; Mon, 03 Sep 2012 06:57:41 +0000
Received: from [85.158.143.35:55830] by server-1.bemta-4.messagelabs.com id
	DE/15-12504-4E454405; Mon, 03 Sep 2012 06:57:40 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1346655456!16333615!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM3ODU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28167 invoked from network); 3 Sep 2012 06:57:37 -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;
	3 Sep 2012 06:57:37 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 03 Sep 2012 07:57:36 +0100
Message-Id: <504470FD0200007800098213@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 03 Sep 2012 07:57:33 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__PartE5D4FCCD.0__="
Subject: [Xen-devel] [PATCH] make domain_create() return a proper error code
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
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.

--=__PartE5D4FCCD.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

While triggered by the XSA-9 fix, this really is of more general use;
that fix just pointed out very sharply that the current situation
with all domain creation failures reported to user (tools) space as
-ENOMEM is very unfortunate (actively misleading users _and_ support
personnel).

Pull over the pointer <-> error code conversion infrastructure from
Linux, and use it in domain_create() and all it callers.

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

--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -26,6 +26,7 @@
 #include <xen/serial.h>
 #include <xen/sched.h>
 #include <xen/console.h>
+#include <xen/err.h>
 #include <xen/init.h>
 #include <xen/irq.h>
 #include <xen/mm.h>
@@ -237,7 +238,7 @@ void __init start_xen(unsigned long boot
=20
     /* Create initial domain 0. */
     dom0 =3D domain_create(0, 0, 0);
-    if ( dom0 =3D=3D NULL )
+    if ( IS_ERR(dom0) )
             printk("domain_create failed\n");
     if ( (dom0 =3D=3D NULL) || (alloc_dom0_vcpu0() =3D=3D NULL) )
             panic("Error creating domain 0\n");
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -91,7 +91,7 @@
 #include <xen/mm.h>
 #include <xen/domain.h>
 #include <xen/sched.h>
-#include <xen/errno.h>
+#include <xen/err.h>
 #include <xen/perfc.h>
 #include <xen/irq.h>
 #include <xen/softirq.h>
@@ -309,7 +309,7 @@ void __init arch_init_memory(void)
      * their domain field set to dom_xen.
      */
     dom_xen =3D domain_create(DOMID_XEN, DOMCRF_dummy, 0);
-    BUG_ON(dom_xen =3D=3D NULL);
+    BUG_ON(IS_ERR(dom_xen));
=20
     /*
      * Initialise our DOMID_IO domain.
@@ -317,14 +317,14 @@ void __init arch_init_memory(void)
      * array. Mappings occur at the priv of the caller.
      */
     dom_io =3D domain_create(DOMID_IO, DOMCRF_dummy, 0);
-    BUG_ON(dom_io =3D=3D NULL);
+    BUG_ON(IS_ERR(dom_io));
    =20
     /*
-     * Initialise our DOMID_IO domain.
+     * Initialise our COW domain.
      * This domain owns sharable pages.
      */
     dom_cow =3D domain_create(DOMID_COW, DOMCRF_dummy, 0);
-    BUG_ON(dom_cow =3D=3D NULL);
+    BUG_ON(IS_ERR(dom_cow));
=20
     /* First 1MB of RAM is historically marked as I/O. */
     for ( i =3D 0; i < 0x100; i++ )
--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@ -1,6 +1,7 @@
 #include <xen/config.h>
 #include <xen/init.h>
 #include <xen/lib.h>
+#include <xen/err.h>
 #include <xen/sched.h>
 #include <xen/sched-if.h>
 #include <xen/domain.h>
@@ -1319,7 +1320,7 @@ void __init __start_xen(unsigned long mb
=20
     /* Create initial domain 0. */
     dom0 =3D domain_create(0, DOMCRF_s3_integrity, 0);
-    if ( (dom0 =3D=3D NULL) || (alloc_dom0_vcpu0() =3D=3D NULL) )
+    if ( IS_ERR(dom0) || (alloc_dom0_vcpu0() =3D=3D NULL) )
         panic("Error creating domain 0\n");
=20
     dom0->is_privileged =3D 1;
--- a/xen/common/cpupool.c
+++ b/xen/common/cpupool.c
@@ -370,14 +370,18 @@ out:
 int cpupool_add_domain(struct domain *d, int poolid)
 {
     struct cpupool *c;
-    int rc =3D 1;
+    int rc;
     int n_dom =3D 0;
=20
     if ( poolid =3D=3D CPUPOOLID_NONE )
         return 0;
     spin_lock(&cpupool_lock);
     c =3D cpupool_find_by_id(poolid);
-    if ( (c !=3D NULL) && cpumask_weight(c->cpu_valid) )
+    if ( c =3D=3D NULL )
+        rc =3D -ESRCH;
+    else if ( !cpumask_weight(c->cpu_valid) )
+        rc =3D -ENODEV;
+    else
     {
         c->n_dom++;
         n_dom =3D c->n_dom;
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -9,7 +9,7 @@
 #include <xen/init.h>
 #include <xen/lib.h>
 #include <xen/ctype.h>
-#include <xen/errno.h>
+#include <xen/err.h>
 #include <xen/sched.h>
 #include <xen/sched-if.h>
 #include <xen/domain.h>
@@ -196,17 +196,17 @@ 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 =
1u<<5 };
-    int init_status =3D 0;
+    int err, init_status =3D 0;
     int poolid =3D CPUPOOLID_NONE;
=20
     if ( (d =3D alloc_domain_struct()) =3D=3D NULL )
-        return NULL;
+        return ERR_PTR(-ENOMEM);
=20
     d->domain_id =3D domid;
=20
     lock_profile_register_struct(LOCKPROF_TYPE_PERDOM, d, domid, =
"Domain");
=20
-    if ( xsm_alloc_security_domain(d) !=3D 0 )
+    if ( (err =3D xsm_alloc_security_domain(d)) !=3D 0 )
         goto fail;
     init_status |=3D INIT_xsm;
=20
@@ -226,6 +226,7 @@ struct domain *domain_create(
     spin_lock_init(&d->shutdown_lock);
     d->shutdown_code =3D -1;
=20
+    err =3D -ENOMEM;
     if ( !zalloc_cpumask_var(&d->domain_dirty_cpumask) )
         goto fail;
=20
@@ -251,7 +252,7 @@ struct domain *domain_create(
=20
     if ( !is_idle_domain(d) )
     {
-        if ( xsm_domain_create(d, ssidref) !=3D 0 )
+        if ( (err =3D xsm_domain_create(d, ssidref)) !=3D 0 )
             goto fail;
=20
         d->is_paused_by_controller =3D 1;
@@ -266,29 +267,30 @@ struct domain *domain_create(
=20
         radix_tree_init(&d->pirq_tree);
=20
-        if ( evtchn_init(d) !=3D 0 )
+        if ( (err =3D evtchn_init(d)) !=3D 0 )
             goto fail;
         init_status |=3D INIT_evtchn;
=20
-        if ( grant_table_create(d) !=3D 0 )
+        if ( (err =3D grant_table_create(d)) !=3D 0 )
             goto fail;
         init_status |=3D INIT_gnttab;
=20
         poolid =3D 0;
=20
+        err =3D -ENOMEM;
         d->mem_event =3D xzalloc(struct mem_event_per_domain);
         if ( !d->mem_event )
             goto fail;
     }
=20
-    if ( arch_domain_create(d, domcr_flags) !=3D 0 )
+    if ( (err =3D arch_domain_create(d, domcr_flags)) !=3D 0 )
         goto fail;
     init_status |=3D INIT_arch;
=20
-    if ( cpupool_add_domain(d, poolid) !=3D 0 )
+    if ( (err =3D cpupool_add_domain(d, poolid)) !=3D 0 )
         goto fail;
=20
-    if ( sched_init_domain(d) !=3D 0 )
+    if ( (err =3D sched_init_domain(d)) !=3D 0 )
         goto fail;
=20
     if ( !is_idle_domain(d) )
@@ -329,7 +331,7 @@ struct domain *domain_create(
         xsm_free_security_domain(d);
     free_cpumask_var(d->domain_dirty_cpumask);
     free_domain_struct(d);
-    return NULL;
+    return ERR_PTR(err);
 }
=20
=20
--- a/xen/common/domctl.c
+++ b/xen/common/domctl.c
@@ -9,6 +9,7 @@
 #include <xen/config.h>
 #include <xen/types.h>
 #include <xen/lib.h>
+#include <xen/err.h>
 #include <xen/mm.h>
 #include <xen/sched.h>
 #include <xen/sched-if.h>
@@ -455,10 +456,12 @@ long do_domctl(XEN_GUEST_HANDLE(xen_domc
         if ( op->u.createdomain.flags & XEN_DOMCTL_CDF_oos_off )
             domcr_flags |=3D DOMCRF_oos_off;
=20
-        ret =3D -ENOMEM;
         d =3D domain_create(dom, domcr_flags, op->u.createdomain.ssidref);=

-        if ( d =3D=3D NULL )
+        if ( IS_ERR(d) )
+        {
+            ret =3D PTR_ERR(d);
             break;
+        }
=20
         ret =3D 0;
=20
--- a/xen/common/schedule.c
+++ b/xen/common/schedule.c
@@ -28,7 +28,7 @@
 #include <xen/softirq.h>
 #include <xen/trace.h>
 #include <xen/mm.h>
-#include <xen/errno.h>
+#include <xen/err.h>
 #include <xen/guest_access.h>
 #include <xen/multicall.h>
 #include <xen/cpu.h>
@@ -1323,7 +1323,7 @@ void __init scheduler_init(void)
         panic("scheduler returned error on init\n");
=20
     idle_domain =3D domain_create(DOMID_IDLE, 0, 0);
-    BUG_ON(idle_domain =3D=3D NULL);
+    BUG_ON(IS_ERR(idle_domain));
     idle_domain->vcpu =3D idle_vcpu;
     idle_domain->max_vcpus =3D nr_cpu_ids;
     if ( alloc_vcpu(idle_domain, 0, 0) =3D=3D NULL )
--- /dev/null
+++ b/xen/include/xen/err.h
@@ -0,0 +1,57 @@
+#if !defined(__XEN_ERR_H__) && !defined(__ASSEMBLY__)
+#define __XEN_ERR_H__
+
+#include <xen/compiler.h>
+#include <xen/errno.h>
+
+/*
+ * Kernel pointers have redundant information, so we can use a
+ * scheme where we can return either an error code or a dentry
+ * pointer with the same return value.
+ *
+ * This could be a per-architecture thing, to allow different
+ * error and pointer decisions.
+ */
+#define MAX_ERRNO	4095
+
+#define IS_ERR_VALUE(x) unlikely((x) >=3D (unsigned long)-MAX_ERRNO)
+
+static inline void *__must_check ERR_PTR(long error)
+{
+	return (void *)error;
+}
+
+static inline long __must_check PTR_ERR(const void *ptr)
+{
+	return (long)ptr;
+}
+
+static inline long __must_check IS_ERR(const void *ptr)
+{
+	return IS_ERR_VALUE((unsigned long)ptr);
+}
+
+static inline long __must_check IS_ERR_OR_NULL(const void *ptr)
+{
+	return !ptr || IS_ERR_VALUE((unsigned long)ptr);
+}
+
+/**
+ * ERR_CAST - Explicitly cast an error-valued pointer to another pointer =
type
+ * @ptr: The pointer to cast.
+ *
+ * Explicitly cast an error-valued pointer to another pointer type in =
such a
+ * way as to make it clear that's what's going on.
+ */
+static inline void * __must_check ERR_CAST(const void *ptr)
+{
+	/* cast away the const */
+	return (void *)ptr;
+}
+
+static inline int __must_check PTR_RET(const void *ptr)
+{
+	return IS_ERR(ptr) ? PTR_ERR(ptr) : 0;
+}
+
+#endif /* __XEN_ERR_H__ */



--=__PartE5D4FCCD.0__=
Content-Type: text/plain; name="domain_create-return-value.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="domain_create-return-value.patch"

make domain_create() return a proper error code=0A=0AWhile triggered by =
the XSA-9 fix, this really is of more general use;=0Athat fix just pointed =
out very sharply that the current situation=0Awith all domain creation =
failures reported to user (tools) space as=0A-ENOMEM is very unfortunate =
(actively misleading users _and_ support=0Apersonnel).=0A=0APull over the =
pointer <-> error code conversion infrastructure from=0ALinux, and use it =
in domain_create() and all it callers.=0A=0ASigned-off-by: Jan Beulich =
<jbeulich@suse.com>=0A=0A--- a/xen/arch/arm/setup.c=0A+++ b/xen/arch/arm/se=
tup.c=0A@@ -26,6 +26,7 @@=0A #include <xen/serial.h>=0A #include <xen/sched=
.h>=0A #include <xen/console.h>=0A+#include <xen/err.h>=0A #include =
<xen/init.h>=0A #include <xen/irq.h>=0A #include <xen/mm.h>=0A@@ -237,7 =
+238,7 @@ void __init start_xen(unsigned long boot=0A =0A     /* Create =
initial domain 0. */=0A     dom0 =3D domain_create(0, 0, 0);=0A-    if ( =
dom0 =3D=3D NULL )=0A+    if ( IS_ERR(dom0) )=0A             printk("domain=
_create failed\n");=0A     if ( (dom0 =3D=3D NULL) || (alloc_dom0_vcpu0() =
=3D=3D NULL) )=0A             panic("Error creating domain 0\n");=0A--- =
a/xen/arch/x86/mm.c=0A+++ b/xen/arch/x86/mm.c=0A@@ -91,7 +91,7 @@=0A =
#include <xen/mm.h>=0A #include <xen/domain.h>=0A #include <xen/sched.h>=0A=
-#include <xen/errno.h>=0A+#include <xen/err.h>=0A #include <xen/perfc.h>=
=0A #include <xen/irq.h>=0A #include <xen/softirq.h>=0A@@ -309,7 +309,7 @@ =
void __init arch_init_memory(void)=0A      * their domain field set to =
dom_xen.=0A      */=0A     dom_xen =3D domain_create(DOMID_XEN, DOMCRF_dumm=
y, 0);=0A-    BUG_ON(dom_xen =3D=3D NULL);=0A+    BUG_ON(IS_ERR(dom_xen));=
=0A =0A     /*=0A      * Initialise our DOMID_IO domain.=0A@@ -317,14 =
+317,14 @@ void __init arch_init_memory(void)=0A      * array. Mappings =
occur at the priv of the caller.=0A      */=0A     dom_io =3D domain_create=
(DOMID_IO, DOMCRF_dummy, 0);=0A-    BUG_ON(dom_io =3D=3D NULL);=0A+    =
BUG_ON(IS_ERR(dom_io));=0A     =0A     /*=0A-     * Initialise our =
DOMID_IO domain.=0A+     * Initialise our COW domain.=0A      * This =
domain owns sharable pages.=0A      */=0A     dom_cow =3D domain_create(DOM=
ID_COW, DOMCRF_dummy, 0);=0A-    BUG_ON(dom_cow =3D=3D NULL);=0A+    =
BUG_ON(IS_ERR(dom_cow));=0A =0A     /* First 1MB of RAM is historically =
marked as I/O. */=0A     for ( i =3D 0; i < 0x100; i++ )=0A--- a/xen/arch/x=
86/setup.c=0A+++ b/xen/arch/x86/setup.c=0A@@ -1,6 +1,7 @@=0A #include =
<xen/config.h>=0A #include <xen/init.h>=0A #include <xen/lib.h>=0A+#include=
 <xen/err.h>=0A #include <xen/sched.h>=0A #include <xen/sched-if.h>=0A =
#include <xen/domain.h>=0A@@ -1319,7 +1320,7 @@ void __init __start_xen(uns=
igned long mb=0A =0A     /* Create initial domain 0. */=0A     dom0 =3D =
domain_create(0, DOMCRF_s3_integrity, 0);=0A-    if ( (dom0 =3D=3D NULL) =
|| (alloc_dom0_vcpu0() =3D=3D NULL) )=0A+    if ( IS_ERR(dom0) || =
(alloc_dom0_vcpu0() =3D=3D NULL) )=0A         panic("Error creating domain =
0\n");=0A =0A     dom0->is_privileged =3D 1;=0A--- a/xen/common/cpupool.c=
=0A+++ b/xen/common/cpupool.c=0A@@ -370,14 +370,18 @@ out:=0A int =
cpupool_add_domain(struct domain *d, int poolid)=0A {=0A     struct =
cpupool *c;=0A-    int rc =3D 1;=0A+    int rc;=0A     int n_dom =3D 0;=0A =
=0A     if ( poolid =3D=3D CPUPOOLID_NONE )=0A         return 0;=0A     =
spin_lock(&cpupool_lock);=0A     c =3D cpupool_find_by_id(poolid);=0A-    =
if ( (c !=3D NULL) && cpumask_weight(c->cpu_valid) )=0A+    if ( c =3D=3D =
NULL )=0A+        rc =3D -ESRCH;=0A+    else if ( !cpumask_weight(c->cpu_va=
lid) )=0A+        rc =3D -ENODEV;=0A+    else=0A     {=0A         =
c->n_dom++;=0A         n_dom =3D c->n_dom;=0A--- a/xen/common/domain.c=0A++=
+ b/xen/common/domain.c=0A@@ -9,7 +9,7 @@=0A #include <xen/init.h>=0A =
#include <xen/lib.h>=0A #include <xen/ctype.h>=0A-#include <xen/errno.h>=0A=
+#include <xen/err.h>=0A #include <xen/sched.h>=0A #include <xen/sched-if.h=
>=0A #include <xen/domain.h>=0A@@ -196,17 +196,17 @@ struct domain =
*domain_create(=0A     struct domain *d, **pd;=0A     enum { INIT_xsm =3D =
1u<<0, INIT_watchdog =3D 1u<<1, INIT_rangeset =3D 1u<<2,=0A            =
INIT_evtchn =3D 1u<<3, INIT_gnttab =3D 1u<<4, INIT_arch =3D 1u<<5 };=0A-   =
 int init_status =3D 0;=0A+    int err, init_status =3D 0;=0A     int =
poolid =3D CPUPOOLID_NONE;=0A =0A     if ( (d =3D alloc_domain_struct()) =
=3D=3D NULL )=0A-        return NULL;=0A+        return ERR_PTR(-ENOMEM);=
=0A =0A     d->domain_id =3D domid;=0A =0A     lock_profile_register_struct=
(LOCKPROF_TYPE_PERDOM, d, domid, "Domain");=0A =0A-    if ( xsm_alloc_secur=
ity_domain(d) !=3D 0 )=0A+    if ( (err =3D xsm_alloc_security_domain(d)) =
!=3D 0 )=0A         goto fail;=0A     init_status |=3D INIT_xsm;=0A =0A@@ =
-226,6 +226,7 @@ struct domain *domain_create(=0A     spin_lock_init(&d->sh=
utdown_lock);=0A     d->shutdown_code =3D -1;=0A =0A+    err =3D =
-ENOMEM;=0A     if ( !zalloc_cpumask_var(&d->domain_dirty_cpumask) )=0A    =
     goto fail;=0A =0A@@ -251,7 +252,7 @@ struct domain *domain_create(=0A =
=0A     if ( !is_idle_domain(d) )=0A     {=0A-        if ( xsm_domain_creat=
e(d, ssidref) !=3D 0 )=0A+        if ( (err =3D xsm_domain_create(d, =
ssidref)) !=3D 0 )=0A             goto fail;=0A =0A         d->is_paused_by=
_controller =3D 1;=0A@@ -266,29 +267,30 @@ struct domain *domain_create(=0A=
 =0A         radix_tree_init(&d->pirq_tree);=0A =0A-        if ( evtchn_ini=
t(d) !=3D 0 )=0A+        if ( (err =3D evtchn_init(d)) !=3D 0 )=0A         =
    goto fail;=0A         init_status |=3D INIT_evtchn;=0A =0A-        if =
( grant_table_create(d) !=3D 0 )=0A+        if ( (err =3D grant_table_creat=
e(d)) !=3D 0 )=0A             goto fail;=0A         init_status |=3D =
INIT_gnttab;=0A =0A         poolid =3D 0;=0A =0A+        err =3D =
-ENOMEM;=0A         d->mem_event =3D xzalloc(struct mem_event_per_domain);=
=0A         if ( !d->mem_event )=0A             goto fail;=0A     }=0A =
=0A-    if ( arch_domain_create(d, domcr_flags) !=3D 0 )=0A+    if ( (err =
=3D arch_domain_create(d, domcr_flags)) !=3D 0 )=0A         goto fail;=0A  =
   init_status |=3D INIT_arch;=0A =0A-    if ( cpupool_add_domain(d, =
poolid) !=3D 0 )=0A+    if ( (err =3D cpupool_add_domain(d, poolid)) !=3D =
0 )=0A         goto fail;=0A =0A-    if ( sched_init_domain(d) !=3D 0 =
)=0A+    if ( (err =3D sched_init_domain(d)) !=3D 0 )=0A         goto =
fail;=0A =0A     if ( !is_idle_domain(d) )=0A@@ -329,7 +331,7 @@ struct =
domain *domain_create(=0A         xsm_free_security_domain(d);=0A     =
free_cpumask_var(d->domain_dirty_cpumask);=0A     free_domain_struct(d);=0A=
-    return NULL;=0A+    return ERR_PTR(err);=0A }=0A =0A =0A--- a/xen/comm=
on/domctl.c=0A+++ b/xen/common/domctl.c=0A@@ -9,6 +9,7 @@=0A #include =
<xen/config.h>=0A #include <xen/types.h>=0A #include <xen/lib.h>=0A+#includ=
e <xen/err.h>=0A #include <xen/mm.h>=0A #include <xen/sched.h>=0A #include =
<xen/sched-if.h>=0A@@ -455,10 +456,12 @@ long do_domctl(XEN_GUEST_HANDLE(xe=
n_domc=0A         if ( op->u.createdomain.flags & XEN_DOMCTL_CDF_oos_off =
)=0A             domcr_flags |=3D DOMCRF_oos_off;=0A =0A-        ret =3D =
-ENOMEM;=0A         d =3D domain_create(dom, domcr_flags, op->u.createdomai=
n.ssidref);=0A-        if ( d =3D=3D NULL )=0A+        if ( IS_ERR(d) =
)=0A+        {=0A+            ret =3D PTR_ERR(d);=0A             break;=0A+=
        }=0A =0A         ret =3D 0;=0A =0A--- a/xen/common/schedule.c=0A+++=
 b/xen/common/schedule.c=0A@@ -28,7 +28,7 @@=0A #include <xen/softirq.h>=0A=
 #include <xen/trace.h>=0A #include <xen/mm.h>=0A-#include <xen/errno.h>=0A=
+#include <xen/err.h>=0A #include <xen/guest_access.h>=0A #include =
<xen/multicall.h>=0A #include <xen/cpu.h>=0A@@ -1323,7 +1323,7 @@ void =
__init scheduler_init(void)=0A         panic("scheduler returned error on =
init\n");=0A =0A     idle_domain =3D domain_create(DOMID_IDLE, 0, 0);=0A-  =
  BUG_ON(idle_domain =3D=3D NULL);=0A+    BUG_ON(IS_ERR(idle_domain));=0A  =
   idle_domain->vcpu =3D idle_vcpu;=0A     idle_domain->max_vcpus =3D =
nr_cpu_ids;=0A     if ( alloc_vcpu(idle_domain, 0, 0) =3D=3D NULL )=0A--- =
/dev/null=0A+++ b/xen/include/xen/err.h=0A@@ -0,0 +1,57 @@=0A+#if =
!defined(__XEN_ERR_H__) && !defined(__ASSEMBLY__)=0A+#define __XEN_ERR_H__=
=0A+=0A+#include <xen/compiler.h>=0A+#include <xen/errno.h>=0A+=0A+/*=0A+ =
* Kernel pointers have redundant information, so we can use a=0A+ * scheme =
where we can return either an error code or a dentry=0A+ * pointer with =
the same return value.=0A+ *=0A+ * This could be a per-architecture thing, =
to allow different=0A+ * error and pointer decisions.=0A+ */=0A+#define =
MAX_ERRNO	4095=0A+=0A+#define IS_ERR_VALUE(x) unlikely((x) >=3D =
(unsigned long)-MAX_ERRNO)=0A+=0A+static inline void *__must_check =
ERR_PTR(long error)=0A+{=0A+	return (void *)error;=0A+}=0A+=0A+static =
inline long __must_check PTR_ERR(const void *ptr)=0A+{=0A+	return =
(long)ptr;=0A+}=0A+=0A+static inline long __must_check IS_ERR(const void =
*ptr)=0A+{=0A+	return IS_ERR_VALUE((unsigned long)ptr);=0A+}=0A+=0A+static=
 inline long __must_check IS_ERR_OR_NULL(const void *ptr)=0A+{=0A+	=
return !ptr || IS_ERR_VALUE((unsigned long)ptr);=0A+}=0A+=0A+/**=0A+ * =
ERR_CAST - Explicitly cast an error-valued pointer to another pointer =
type=0A+ * @ptr: The pointer to cast.=0A+ *=0A+ * Explicitly cast an =
error-valued pointer to another pointer type in such a=0A+ * way as to =
make it clear that's what's going on.=0A+ */=0A+static inline void * =
__must_check ERR_CAST(const void *ptr)=0A+{=0A+	/* cast away the const =
*/=0A+	return (void *)ptr;=0A+}=0A+=0A+static inline int __must_check =
PTR_RET(const void *ptr)=0A+{=0A+	return IS_ERR(ptr) ? PTR_ERR(ptr) =
: 0;=0A+}=0A+=0A+#endif /* __XEN_ERR_H__ */=0A
--=__PartE5D4FCCD.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

--=__PartE5D4FCCD.0__=--


From xen-devel-bounces@lists.xen.org Mon Sep 03 06:58:37 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Sep 2012 06:58: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 1T8Qbt-0000li-Qh; Mon, 03 Sep 2012 06:58: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 1T8Qbs-0000lR-PR
	for xen-devel@lists.xen.org; Mon, 03 Sep 2012 06:58:13 +0000
Received: from [85.158.143.35:16480] by server-2.bemta-4.messagelabs.com id
	2E/C8-21239-40554405; Mon, 03 Sep 2012 06:58:12 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1346655491!5921061!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM3ODU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5728 invoked from network); 3 Sep 2012 06:58:11 -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;
	3 Sep 2012 06:58:11 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 03 Sep 2012 07:58:11 +0100
Message-Id: <5044711F020000780009821F@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 03 Sep 2012 07:58:07 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__PartC7F6DEEF.0__="
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: [Xen-devel] [PATCH] x86/32-on-64: adjust Dom0 initial page table
	layout
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
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.

--=__PartC7F6DEEF.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Drop the unnecessary reservation of the L4 page for 32on64 Dom0, and
allocate its L3 first (to match behavior when running identical bit-
width hypervisor and Dom0 kernel).

Reported-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/arch/x86/domain_build.c
+++ b/xen/arch/x86/domain_build.c
@@ -510,7 +510,7 @@ int __init construct_dom0(
 #define NR(_l,_h,_s) \
     (((((_h) + ((1UL<<(_s))-1)) & ~((1UL<<(_s))-1)) - \
        ((_l) & ~((1UL<<(_s))-1))) >> (_s))
-        if ( (1 + /* # L4 */
+        if ( (!is_pv_32on64_domain(d) + /* # L4 */
               NR(v_start, v_end, L4_PAGETABLE_SHIFT) + /* # L3 */
               (!is_pv_32on64_domain(d) ?
                NR(v_start, v_end, L3_PAGETABLE_SHIFT) : /* # L2 */
@@ -756,6 +756,8 @@ int __init construct_dom0(
             panic("Not enough RAM for domain 0 PML4.\n");
         page->u.inuse.type_info =3D PGT_l4_page_table|PGT_validated|1;
         l4start =3D l4tab =3D page_to_virt(page);
+        maddr_to_page(mpt_alloc)->u.inuse.type_info =3D PGT_l3_page_table;=

+        l3start =3D __va(mpt_alloc); mpt_alloc +=3D PAGE_SIZE;
     }
     copy_page(l4tab, idle_pg_table);
     l4tab[0] =3D l4e_empty(); /* zap trampoline mapping */
@@ -787,9 +789,13 @@ int __init construct_dom0(
                     l2tab +=3D l2_table_offset(v_start);
                 if ( !((unsigned long)l3tab & (PAGE_SIZE-1)) )
                 {
-                    maddr_to_page(mpt_alloc)->u.inuse.type_info =3D
-                        PGT_l3_page_table;
-                    l3start =3D l3tab =3D __va(mpt_alloc); mpt_alloc +=3D =
PAGE_SIZE;
+                    if ( count || !l3start )
+                    {
+                        maddr_to_page(mpt_alloc)->u.inuse.type_info =3D
+                            PGT_l3_page_table;
+                        l3start =3D __va(mpt_alloc); mpt_alloc +=3D =
PAGE_SIZE;
+                    }
+                    l3tab =3D l3start;
                     clear_page(l3tab);
                     if ( count =3D=3D 0 )
                         l3tab +=3D l3_table_offset(v_start);
@@ -938,7 +944,7 @@ int __init construct_dom0(
     if ( !vinitrd_start && initrd_len )
         si->flags   |=3D SIF_MOD_START_PFN;
     si->flags       |=3D (xen_processor_pmbits << 8) & SIF_PM_MASK;
-    si->pt_base      =3D vpt_start + 2 * PAGE_SIZE * !!is_pv_32on64_domain=
(d);
+    si->pt_base      =3D vpt_start;
     si->nr_pt_frames =3D nr_pt_pages;
     si->mfn_list     =3D vphysmap_start;
     snprintf(si->magic, sizeof(si->magic), "xen-3.0-x86_%d%s",




--=__PartC7F6DEEF.0__=
Content-Type: text/plain; name="32on64-bogus-pt_base-adjust.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="32on64-bogus-pt_base-adjust.patch"

x86/32-on-64: adjust Dom0 initial page table layout=0A=0ADrop the =
unnecessary reservation of the L4 page for 32on64 Dom0, and=0Aallocate its =
L3 first (to match behavior when running identical bit-=0Awidth hypervisor =
and Dom0 kernel).=0A=0AReported-by: Konrad Rzeszutek Wilk <konrad.wilk@orac=
le.com>=0ASigned-off-by: Jan Beulich <jbeulich@suse.com>=0A=0A--- =
a/xen/arch/x86/domain_build.c=0A+++ b/xen/arch/x86/domain_build.c=0A@@ =
-510,7 +510,7 @@ int __init construct_dom0(=0A #define NR(_l,_h,_s) \=0A   =
  (((((_h) + ((1UL<<(_s))-1)) & ~((1UL<<(_s))-1)) - \=0A        ((_l) & =
~((1UL<<(_s))-1))) >> (_s))=0A-        if ( (1 + /* # L4 */=0A+        if =
( (!is_pv_32on64_domain(d) + /* # L4 */=0A               NR(v_start, =
v_end, L4_PAGETABLE_SHIFT) + /* # L3 */=0A               (!is_pv_32on64_dom=
ain(d) ?=0A                NR(v_start, v_end, L3_PAGETABLE_SHIFT) : /* # =
L2 */=0A@@ -756,6 +756,8 @@ int __init construct_dom0(=0A             =
panic("Not enough RAM for domain 0 PML4.\n");=0A         page->u.inuse.type=
_info =3D PGT_l4_page_table|PGT_validated|1;=0A         l4start =3D l4tab =
=3D page_to_virt(page);=0A+        maddr_to_page(mpt_alloc)->u.inuse.type_i=
nfo =3D PGT_l3_page_table;=0A+        l3start =3D __va(mpt_alloc); =
mpt_alloc +=3D PAGE_SIZE;=0A     }=0A     copy_page(l4tab, idle_pg_table);=
=0A     l4tab[0] =3D l4e_empty(); /* zap trampoline mapping */=0A@@ -787,9 =
+789,13 @@ int __init construct_dom0(=0A                     l2tab +=3D =
l2_table_offset(v_start);=0A                 if ( !((unsigned long)l3tab & =
(PAGE_SIZE-1)) )=0A                 {=0A-                    maddr_to_page(=
mpt_alloc)->u.inuse.type_info =3D=0A-                        PGT_l3_page_ta=
ble;=0A-                    l3start =3D l3tab =3D __va(mpt_alloc); =
mpt_alloc +=3D PAGE_SIZE;=0A+                    if ( count || !l3start =
)=0A+                    {=0A+                        maddr_to_page(mpt_all=
oc)->u.inuse.type_info =3D=0A+                            PGT_l3_page_table=
;=0A+                        l3start =3D __va(mpt_alloc); mpt_alloc +=3D =
PAGE_SIZE;=0A+                    }=0A+                    l3tab =3D =
l3start;=0A                     clear_page(l3tab);=0A                     =
if ( count =3D=3D 0 )=0A                         l3tab +=3D l3_table_offset=
(v_start);=0A@@ -938,7 +944,7 @@ int __init construct_dom0(=0A     if ( =
!vinitrd_start && initrd_len )=0A         si->flags   |=3D SIF_MOD_START_PF=
N;=0A     si->flags       |=3D (xen_processor_pmbits << 8) & SIF_PM_MASK;=
=0A-    si->pt_base      =3D vpt_start + 2 * PAGE_SIZE * !!is_pv_32on64_dom=
ain(d);=0A+    si->pt_base      =3D vpt_start;=0A     si->nr_pt_frames =3D =
nr_pt_pages;=0A     si->mfn_list     =3D vphysmap_start;=0A     snprintf(si=
->magic, sizeof(si->magic), "xen-3.0-x86_%d%s",=0A
--=__PartC7F6DEEF.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

--=__PartC7F6DEEF.0__=--


From xen-devel-bounces@lists.xen.org Mon Sep 03 06:58:37 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Sep 2012 06:58: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 1T8Qbt-0000li-Qh; Mon, 03 Sep 2012 06:58: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 1T8Qbs-0000lR-PR
	for xen-devel@lists.xen.org; Mon, 03 Sep 2012 06:58:13 +0000
Received: from [85.158.143.35:16480] by server-2.bemta-4.messagelabs.com id
	2E/C8-21239-40554405; Mon, 03 Sep 2012 06:58:12 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1346655491!5921061!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM3ODU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5728 invoked from network); 3 Sep 2012 06:58:11 -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;
	3 Sep 2012 06:58:11 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 03 Sep 2012 07:58:11 +0100
Message-Id: <5044711F020000780009821F@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 03 Sep 2012 07:58:07 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__PartC7F6DEEF.0__="
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: [Xen-devel] [PATCH] x86/32-on-64: adjust Dom0 initial page table
	layout
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
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.

--=__PartC7F6DEEF.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Drop the unnecessary reservation of the L4 page for 32on64 Dom0, and
allocate its L3 first (to match behavior when running identical bit-
width hypervisor and Dom0 kernel).

Reported-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/arch/x86/domain_build.c
+++ b/xen/arch/x86/domain_build.c
@@ -510,7 +510,7 @@ int __init construct_dom0(
 #define NR(_l,_h,_s) \
     (((((_h) + ((1UL<<(_s))-1)) & ~((1UL<<(_s))-1)) - \
        ((_l) & ~((1UL<<(_s))-1))) >> (_s))
-        if ( (1 + /* # L4 */
+        if ( (!is_pv_32on64_domain(d) + /* # L4 */
               NR(v_start, v_end, L4_PAGETABLE_SHIFT) + /* # L3 */
               (!is_pv_32on64_domain(d) ?
                NR(v_start, v_end, L3_PAGETABLE_SHIFT) : /* # L2 */
@@ -756,6 +756,8 @@ int __init construct_dom0(
             panic("Not enough RAM for domain 0 PML4.\n");
         page->u.inuse.type_info =3D PGT_l4_page_table|PGT_validated|1;
         l4start =3D l4tab =3D page_to_virt(page);
+        maddr_to_page(mpt_alloc)->u.inuse.type_info =3D PGT_l3_page_table;=

+        l3start =3D __va(mpt_alloc); mpt_alloc +=3D PAGE_SIZE;
     }
     copy_page(l4tab, idle_pg_table);
     l4tab[0] =3D l4e_empty(); /* zap trampoline mapping */
@@ -787,9 +789,13 @@ int __init construct_dom0(
                     l2tab +=3D l2_table_offset(v_start);
                 if ( !((unsigned long)l3tab & (PAGE_SIZE-1)) )
                 {
-                    maddr_to_page(mpt_alloc)->u.inuse.type_info =3D
-                        PGT_l3_page_table;
-                    l3start =3D l3tab =3D __va(mpt_alloc); mpt_alloc +=3D =
PAGE_SIZE;
+                    if ( count || !l3start )
+                    {
+                        maddr_to_page(mpt_alloc)->u.inuse.type_info =3D
+                            PGT_l3_page_table;
+                        l3start =3D __va(mpt_alloc); mpt_alloc +=3D =
PAGE_SIZE;
+                    }
+                    l3tab =3D l3start;
                     clear_page(l3tab);
                     if ( count =3D=3D 0 )
                         l3tab +=3D l3_table_offset(v_start);
@@ -938,7 +944,7 @@ int __init construct_dom0(
     if ( !vinitrd_start && initrd_len )
         si->flags   |=3D SIF_MOD_START_PFN;
     si->flags       |=3D (xen_processor_pmbits << 8) & SIF_PM_MASK;
-    si->pt_base      =3D vpt_start + 2 * PAGE_SIZE * !!is_pv_32on64_domain=
(d);
+    si->pt_base      =3D vpt_start;
     si->nr_pt_frames =3D nr_pt_pages;
     si->mfn_list     =3D vphysmap_start;
     snprintf(si->magic, sizeof(si->magic), "xen-3.0-x86_%d%s",




--=__PartC7F6DEEF.0__=
Content-Type: text/plain; name="32on64-bogus-pt_base-adjust.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="32on64-bogus-pt_base-adjust.patch"

x86/32-on-64: adjust Dom0 initial page table layout=0A=0ADrop the =
unnecessary reservation of the L4 page for 32on64 Dom0, and=0Aallocate its =
L3 first (to match behavior when running identical bit-=0Awidth hypervisor =
and Dom0 kernel).=0A=0AReported-by: Konrad Rzeszutek Wilk <konrad.wilk@orac=
le.com>=0ASigned-off-by: Jan Beulich <jbeulich@suse.com>=0A=0A--- =
a/xen/arch/x86/domain_build.c=0A+++ b/xen/arch/x86/domain_build.c=0A@@ =
-510,7 +510,7 @@ int __init construct_dom0(=0A #define NR(_l,_h,_s) \=0A   =
  (((((_h) + ((1UL<<(_s))-1)) & ~((1UL<<(_s))-1)) - \=0A        ((_l) & =
~((1UL<<(_s))-1))) >> (_s))=0A-        if ( (1 + /* # L4 */=0A+        if =
( (!is_pv_32on64_domain(d) + /* # L4 */=0A               NR(v_start, =
v_end, L4_PAGETABLE_SHIFT) + /* # L3 */=0A               (!is_pv_32on64_dom=
ain(d) ?=0A                NR(v_start, v_end, L3_PAGETABLE_SHIFT) : /* # =
L2 */=0A@@ -756,6 +756,8 @@ int __init construct_dom0(=0A             =
panic("Not enough RAM for domain 0 PML4.\n");=0A         page->u.inuse.type=
_info =3D PGT_l4_page_table|PGT_validated|1;=0A         l4start =3D l4tab =
=3D page_to_virt(page);=0A+        maddr_to_page(mpt_alloc)->u.inuse.type_i=
nfo =3D PGT_l3_page_table;=0A+        l3start =3D __va(mpt_alloc); =
mpt_alloc +=3D PAGE_SIZE;=0A     }=0A     copy_page(l4tab, idle_pg_table);=
=0A     l4tab[0] =3D l4e_empty(); /* zap trampoline mapping */=0A@@ -787,9 =
+789,13 @@ int __init construct_dom0(=0A                     l2tab +=3D =
l2_table_offset(v_start);=0A                 if ( !((unsigned long)l3tab & =
(PAGE_SIZE-1)) )=0A                 {=0A-                    maddr_to_page(=
mpt_alloc)->u.inuse.type_info =3D=0A-                        PGT_l3_page_ta=
ble;=0A-                    l3start =3D l3tab =3D __va(mpt_alloc); =
mpt_alloc +=3D PAGE_SIZE;=0A+                    if ( count || !l3start =
)=0A+                    {=0A+                        maddr_to_page(mpt_all=
oc)->u.inuse.type_info =3D=0A+                            PGT_l3_page_table=
;=0A+                        l3start =3D __va(mpt_alloc); mpt_alloc +=3D =
PAGE_SIZE;=0A+                    }=0A+                    l3tab =3D =
l3start;=0A                     clear_page(l3tab);=0A                     =
if ( count =3D=3D 0 )=0A                         l3tab +=3D l3_table_offset=
(v_start);=0A@@ -938,7 +944,7 @@ int __init construct_dom0(=0A     if ( =
!vinitrd_start && initrd_len )=0A         si->flags   |=3D SIF_MOD_START_PF=
N;=0A     si->flags       |=3D (xen_processor_pmbits << 8) & SIF_PM_MASK;=
=0A-    si->pt_base      =3D vpt_start + 2 * PAGE_SIZE * !!is_pv_32on64_dom=
ain(d);=0A+    si->pt_base      =3D vpt_start;=0A     si->nr_pt_frames =3D =
nr_pt_pages;=0A     si->mfn_list     =3D vphysmap_start;=0A     snprintf(si=
->magic, sizeof(si->magic), "xen-3.0-x86_%d%s",=0A
--=__PartC7F6DEEF.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

--=__PartC7F6DEEF.0__=--


From xen-devel-bounces@lists.xen.org Mon Sep 03 07:31:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Sep 2012 07:31:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T8R7O-0001Mn-BO; Mon, 03 Sep 2012 07:30:46 +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 1T8R7M-0001Mi-DH
	for xen-devel@lists.xen.org; Mon, 03 Sep 2012 07:30:44 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1346657434!3638190!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM3ODU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8142 invoked from network); 3 Sep 2012 07:30:34 -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;
	3 Sep 2012 07:30:34 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 03 Sep 2012 08:30:34 +0100
Message-Id: <504478B40200007800098286@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 03 Sep 2012 08:30:28 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Javier Marcet" <jmarcet@gmail.com>
References: <CAAnFQG8z_ja1Wj2hX+0ZRsz5eLWr+U+7PoSiF9NePsSh2jbX4g@mail.gmail.com>
	<5040B7A40200007800097CEE@nat28.tlf.novell.com>
	<CAAnFQG_vvHQL=NbY1SnMWCcTr73_8RYtNLfc00fqEsz57cd7Rg@mail.gmail.com>
In-Reply-To: <CAAnFQG_vvHQL=NbY1SnMWCcTr73_8RYtNLfc00fqEsz57cd7Rg@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Xen Devel Mailing list <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.2.0-rc4 bugs with GigaByte H77M-D3H + Core i7
 3770
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 02.09.12 at 18:30, Javier Marcet <jmarcet@gmail.com> wrote:
> On Fri, Aug 31, 2012 at 1:09 PM, Jan Beulich <JBeulich@suse.com> wrote:
> 
>> > [    0.358278] DMAR:[DMA Read] Request device [00:02.0] fault addr
>> > 9fac7000
>> > [    0.358278] DMAR:[fault reason 06] PTE Read access is not set
>> > [    0.358286] DRHD: handling fault status reg 2
>> > [    0.358288] DMAR:[DMA Read] Request device [00:02.0] fault addr
>> > 9fac7000
>> > [    0.358288] DMAR:[fault reason 06] PTE Read access is not set
>> > [    0.358291] DMAR:[DMA Read] Request device [00:02.0] fault addr
>> > 9fac7000
>> > [    0.358291] DMAR:[fault reason 06] PTE Read access is not set
>> > [    0.358307] DRHD: handling fault status reg 3
>> >
>> > Furthermore, later on, just after enabling the IOMMU, I get this:
>> >
>> > [    0.328564] DMAR: No ATSR found
>> > [    0.328580] IOMMU 1 0xfed91000: using Queued invalidation
>> > [    0.328582] IOMMU: Setting RMRR:
>> > [    0.328589] IOMMU: Setting identity map for device 0000:00:1d.0
>> > [0x9de36000 - 0x9de52fff]
>> > [    0.328606] IOMMU: Setting identity map for device 0000:00:1a.0
>> > [0x9de36000 - 0x9de52fff]
>> > [    0.328617] IOMMU: Setting identity map for device 0000:00:14.0
>> > [0x9de36000 - 0x9de52fff]
>> > [    0.328625] IOMMU: Prepare 0-16MiB unity mapping for LPC
>> > [    0.328630] IOMMU: Setting identity map for device 0000:00:1f.0
>> > [0x0 - 0xffffff]
>>
>> All of these messages shouldn't appear when running under Xen,
>> as it's the hypervisor, not the kernel to take care of the IOMMU(s).
>> The logs you had pointers to confirm this - are you sure the above
>> was seen when running under Xen?
> 
> I'm sorry I didn't make myself clearer. That dmesg output is when booting
> WITHOUT xen, that is, linux directly over the bare hardware. Under xen
> those errors dissapear.
> 
> The big issue I'm having running xen is that I can't use it since xen can't
> get the cpu capabilities.

What "cpu capabilities"? I just looked at your original mail again,
and I cannot see what failure you're referring to (in fact, I'm not
able to spot any failure in that log at all). And of course you didn't
even attach a hypervisor log. What am I missing?

Jan


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

From xen-devel-bounces@lists.xen.org Mon Sep 03 07:31:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Sep 2012 07:31:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T8R7O-0001Mn-BO; Mon, 03 Sep 2012 07:30:46 +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 1T8R7M-0001Mi-DH
	for xen-devel@lists.xen.org; Mon, 03 Sep 2012 07:30:44 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1346657434!3638190!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM3ODU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8142 invoked from network); 3 Sep 2012 07:30:34 -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;
	3 Sep 2012 07:30:34 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 03 Sep 2012 08:30:34 +0100
Message-Id: <504478B40200007800098286@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 03 Sep 2012 08:30:28 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Javier Marcet" <jmarcet@gmail.com>
References: <CAAnFQG8z_ja1Wj2hX+0ZRsz5eLWr+U+7PoSiF9NePsSh2jbX4g@mail.gmail.com>
	<5040B7A40200007800097CEE@nat28.tlf.novell.com>
	<CAAnFQG_vvHQL=NbY1SnMWCcTr73_8RYtNLfc00fqEsz57cd7Rg@mail.gmail.com>
In-Reply-To: <CAAnFQG_vvHQL=NbY1SnMWCcTr73_8RYtNLfc00fqEsz57cd7Rg@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Xen Devel Mailing list <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.2.0-rc4 bugs with GigaByte H77M-D3H + Core i7
 3770
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 02.09.12 at 18:30, Javier Marcet <jmarcet@gmail.com> wrote:
> On Fri, Aug 31, 2012 at 1:09 PM, Jan Beulich <JBeulich@suse.com> wrote:
> 
>> > [    0.358278] DMAR:[DMA Read] Request device [00:02.0] fault addr
>> > 9fac7000
>> > [    0.358278] DMAR:[fault reason 06] PTE Read access is not set
>> > [    0.358286] DRHD: handling fault status reg 2
>> > [    0.358288] DMAR:[DMA Read] Request device [00:02.0] fault addr
>> > 9fac7000
>> > [    0.358288] DMAR:[fault reason 06] PTE Read access is not set
>> > [    0.358291] DMAR:[DMA Read] Request device [00:02.0] fault addr
>> > 9fac7000
>> > [    0.358291] DMAR:[fault reason 06] PTE Read access is not set
>> > [    0.358307] DRHD: handling fault status reg 3
>> >
>> > Furthermore, later on, just after enabling the IOMMU, I get this:
>> >
>> > [    0.328564] DMAR: No ATSR found
>> > [    0.328580] IOMMU 1 0xfed91000: using Queued invalidation
>> > [    0.328582] IOMMU: Setting RMRR:
>> > [    0.328589] IOMMU: Setting identity map for device 0000:00:1d.0
>> > [0x9de36000 - 0x9de52fff]
>> > [    0.328606] IOMMU: Setting identity map for device 0000:00:1a.0
>> > [0x9de36000 - 0x9de52fff]
>> > [    0.328617] IOMMU: Setting identity map for device 0000:00:14.0
>> > [0x9de36000 - 0x9de52fff]
>> > [    0.328625] IOMMU: Prepare 0-16MiB unity mapping for LPC
>> > [    0.328630] IOMMU: Setting identity map for device 0000:00:1f.0
>> > [0x0 - 0xffffff]
>>
>> All of these messages shouldn't appear when running under Xen,
>> as it's the hypervisor, not the kernel to take care of the IOMMU(s).
>> The logs you had pointers to confirm this - are you sure the above
>> was seen when running under Xen?
> 
> I'm sorry I didn't make myself clearer. That dmesg output is when booting
> WITHOUT xen, that is, linux directly over the bare hardware. Under xen
> those errors dissapear.
> 
> The big issue I'm having running xen is that I can't use it since xen can't
> get the cpu capabilities.

What "cpu capabilities"? I just looked at your original mail again,
and I cannot see what failure you're referring to (in fact, I'm not
able to spot any failure in that log at all). And of course you didn't
even attach a hypervisor log. What am I missing?

Jan


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

From xen-devel-bounces@lists.xen.org Mon Sep 03 07:37:28 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Sep 2012 07:37: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 1T8RDX-0001Wl-5z; Mon, 03 Sep 2012 07:37:07 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1T8RDV-0001Wf-GS
	for xen-devel@lists.xen.org; Mon, 03 Sep 2012 07:37:05 +0000
Received: from [85.158.139.83:62955] by server-7.bemta-5.messagelabs.com id
	82/B6-19703-02E54405; Mon, 03 Sep 2012 07:37:04 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1346657822!16945793!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-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4345 invoked from network); 3 Sep 2012 07:37:02 -0000
Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com)
	(74.125.83.45)
	by server-8.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Sep 2012 07:37:02 -0000
Received: by eeke53 with SMTP id e53so1990189eek.32
	for <xen-devel@lists.xen.org>; Mon, 03 Sep 2012 00:37: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:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=QINCF2nN76wb7CmLwNiQDTiFAQVkWzodF5J6fdAcun0=;
	b=hj8kG1GSn9CF4d6lznXexCs4xgppkbKS/vYwoLV3JQntjfikUn5tJgLzZDPEYY7wRZ
	zhdDhI9P0hNZX510s3vfTMsNGOcasiXCsinw9myrHltT3CnAN954kaA1l3+wugO6JWmU
	lIRcwiRkTSKd0pVg8L9QGBlXW9eLFLY1mqdK7xAZBghrq1wkmZQDr/RW83Vx6Y/FJ88g
	spgdFkedqtXePxuuDeVydV7TmSdjNf2qHUF9cNdtPu59Sof0Iw0DbtSVxPDacmZrtnTb
	fsQWu4CO4rZtApS64Bbf9CGxsgd1OZfEfPaMAWuk3/PLaJLhWu7bLZVUKoizX9rpOZfO
	CECQ==
Received: by 10.14.215.193 with SMTP id e41mr20323703eep.44.1346657822149;
	Mon, 03 Sep 2012 00:37:02 -0700 (PDT)
Received: from [192.168.1.69] (host86-184-74-117.range86-184.btcentralplus.com.
	[86.184.74.117])
	by mx.google.com with ESMTPS id u47sm33969294eeo.9.2012.09.03.00.37.00
	(version=SSLv3 cipher=OTHER); Mon, 03 Sep 2012 00:37:01 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Mon, 03 Sep 2012 08:36:58 +0100
From: Keir Fraser <keir.xen@gmail.com>
To: Jan Beulich <JBeulich@suse.com>,
	xen-devel <xen-devel@lists.xen.org>
Message-ID: <CC6A1CAA.3D9F0%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [PATCH] make domain_create() return a proper error
	code
Thread-Index: Ac2JpuYA3ZzoONFtQkWKioHzzWTW5g==
In-Reply-To: <504470FD0200007800098213@nat28.tlf.novell.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] [PATCH] make domain_create() return a proper error
 code
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 03/09/2012 07:57, "Jan Beulich" <JBeulich@suse.com> wrote:

> While triggered by the XSA-9 fix, this really is of more general use;
> that fix just pointed out very sharply that the current situation
> with all domain creation failures reported to user (tools) space as
> -ENOMEM is very unfortunate (actively misleading users _and_ support
> personnel).
> 
> Pull over the pointer <-> error code conversion infrastructure from
> Linux, and use it in domain_create() and all it callers.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Acked-by: Keir Fraser <keir@xen.org>

This is straightforward really. Can go in for 4.2.

> --- a/xen/arch/arm/setup.c
> +++ b/xen/arch/arm/setup.c
> @@ -26,6 +26,7 @@
>  #include <xen/serial.h>
>  #include <xen/sched.h>
>  #include <xen/console.h>
> +#include <xen/err.h>
>  #include <xen/init.h>
>  #include <xen/irq.h>
>  #include <xen/mm.h>
> @@ -237,7 +238,7 @@ void __init start_xen(unsigned long boot
>  
>      /* Create initial domain 0. */
>      dom0 = domain_create(0, 0, 0);
> -    if ( dom0 == NULL )
> +    if ( IS_ERR(dom0) )
>              printk("domain_create failed\n");
>      if ( (dom0 == NULL) || (alloc_dom0_vcpu0() == NULL) )
>              panic("Error creating domain 0\n");
> --- a/xen/arch/x86/mm.c
> +++ b/xen/arch/x86/mm.c
> @@ -91,7 +91,7 @@
>  #include <xen/mm.h>
>  #include <xen/domain.h>
>  #include <xen/sched.h>
> -#include <xen/errno.h>
> +#include <xen/err.h>
>  #include <xen/perfc.h>
>  #include <xen/irq.h>
>  #include <xen/softirq.h>
> @@ -309,7 +309,7 @@ void __init arch_init_memory(void)
>       * their domain field set to dom_xen.
>       */
>      dom_xen = domain_create(DOMID_XEN, DOMCRF_dummy, 0);
> -    BUG_ON(dom_xen == NULL);
> +    BUG_ON(IS_ERR(dom_xen));
>  
>      /*
>       * Initialise our DOMID_IO domain.
> @@ -317,14 +317,14 @@ void __init arch_init_memory(void)
>       * array. Mappings occur at the priv of the caller.
>       */
>      dom_io = domain_create(DOMID_IO, DOMCRF_dummy, 0);
> -    BUG_ON(dom_io == NULL);
> +    BUG_ON(IS_ERR(dom_io));
>      
>      /*
> -     * Initialise our DOMID_IO domain.
> +     * Initialise our COW domain.
>       * This domain owns sharable pages.
>       */
>      dom_cow = domain_create(DOMID_COW, DOMCRF_dummy, 0);
> -    BUG_ON(dom_cow == NULL);
> +    BUG_ON(IS_ERR(dom_cow));
>  
>      /* First 1MB of RAM is historically marked as I/O. */
>      for ( i = 0; i < 0x100; i++ )
> --- a/xen/arch/x86/setup.c
> +++ b/xen/arch/x86/setup.c
> @@ -1,6 +1,7 @@
>  #include <xen/config.h>
>  #include <xen/init.h>
>  #include <xen/lib.h>
> +#include <xen/err.h>
>  #include <xen/sched.h>
>  #include <xen/sched-if.h>
>  #include <xen/domain.h>
> @@ -1319,7 +1320,7 @@ void __init __start_xen(unsigned long mb
>  
>      /* Create initial domain 0. */
>      dom0 = domain_create(0, DOMCRF_s3_integrity, 0);
> -    if ( (dom0 == NULL) || (alloc_dom0_vcpu0() == NULL) )
> +    if ( IS_ERR(dom0) || (alloc_dom0_vcpu0() == NULL) )
>          panic("Error creating domain 0\n");
>  
>      dom0->is_privileged = 1;
> --- a/xen/common/cpupool.c
> +++ b/xen/common/cpupool.c
> @@ -370,14 +370,18 @@ out:
>  int cpupool_add_domain(struct domain *d, int poolid)
>  {
>      struct cpupool *c;
> -    int rc = 1;
> +    int rc;
>      int n_dom = 0;
>  
>      if ( poolid == CPUPOOLID_NONE )
>          return 0;
>      spin_lock(&cpupool_lock);
>      c = cpupool_find_by_id(poolid);
> -    if ( (c != NULL) && cpumask_weight(c->cpu_valid) )
> +    if ( c == NULL )
> +        rc = -ESRCH;
> +    else if ( !cpumask_weight(c->cpu_valid) )
> +        rc = -ENODEV;
> +    else
>      {
>          c->n_dom++;
>          n_dom = c->n_dom;
> --- a/xen/common/domain.c
> +++ b/xen/common/domain.c
> @@ -9,7 +9,7 @@
>  #include <xen/init.h>
>  #include <xen/lib.h>
>  #include <xen/ctype.h>
> -#include <xen/errno.h>
> +#include <xen/err.h>
>  #include <xen/sched.h>
>  #include <xen/sched-if.h>
>  #include <xen/domain.h>
> @@ -196,17 +196,17 @@ 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 };
> -    int init_status = 0;
> +    int err, init_status = 0;
>      int poolid = CPUPOOLID_NONE;
>  
>      if ( (d = alloc_domain_struct()) == NULL )
> -        return NULL;
> +        return ERR_PTR(-ENOMEM);
>  
>      d->domain_id = domid;
>  
>      lock_profile_register_struct(LOCKPROF_TYPE_PERDOM, d, domid, "Domain");
>  
> -    if ( xsm_alloc_security_domain(d) != 0 )
> +    if ( (err = xsm_alloc_security_domain(d)) != 0 )
>          goto fail;
>      init_status |= INIT_xsm;
>  
> @@ -226,6 +226,7 @@ struct domain *domain_create(
>      spin_lock_init(&d->shutdown_lock);
>      d->shutdown_code = -1;
>  
> +    err = -ENOMEM;
>      if ( !zalloc_cpumask_var(&d->domain_dirty_cpumask) )
>          goto fail;
>  
> @@ -251,7 +252,7 @@ struct domain *domain_create(
>  
>      if ( !is_idle_domain(d) )
>      {
> -        if ( xsm_domain_create(d, ssidref) != 0 )
> +        if ( (err = xsm_domain_create(d, ssidref)) != 0 )
>              goto fail;
>  
>          d->is_paused_by_controller = 1;
> @@ -266,29 +267,30 @@ struct domain *domain_create(
>  
>          radix_tree_init(&d->pirq_tree);
>  
> -        if ( evtchn_init(d) != 0 )
> +        if ( (err = evtchn_init(d)) != 0 )
>              goto fail;
>          init_status |= INIT_evtchn;
>  
> -        if ( grant_table_create(d) != 0 )
> +        if ( (err = grant_table_create(d)) != 0 )
>              goto fail;
>          init_status |= INIT_gnttab;
>  
>          poolid = 0;
>  
> +        err = -ENOMEM;
>          d->mem_event = xzalloc(struct mem_event_per_domain);
>          if ( !d->mem_event )
>              goto fail;
>      }
>  
> -    if ( arch_domain_create(d, domcr_flags) != 0 )
> +    if ( (err = arch_domain_create(d, domcr_flags)) != 0 )
>          goto fail;
>      init_status |= INIT_arch;
>  
> -    if ( cpupool_add_domain(d, poolid) != 0 )
> +    if ( (err = cpupool_add_domain(d, poolid)) != 0 )
>          goto fail;
>  
> -    if ( sched_init_domain(d) != 0 )
> +    if ( (err = sched_init_domain(d)) != 0 )
>          goto fail;
>  
>      if ( !is_idle_domain(d) )
> @@ -329,7 +331,7 @@ struct domain *domain_create(
>          xsm_free_security_domain(d);
>      free_cpumask_var(d->domain_dirty_cpumask);
>      free_domain_struct(d);
> -    return NULL;
> +    return ERR_PTR(err);
>  }
>  
>  
> --- a/xen/common/domctl.c
> +++ b/xen/common/domctl.c
> @@ -9,6 +9,7 @@
>  #include <xen/config.h>
>  #include <xen/types.h>
>  #include <xen/lib.h>
> +#include <xen/err.h>
>  #include <xen/mm.h>
>  #include <xen/sched.h>
>  #include <xen/sched-if.h>
> @@ -455,10 +456,12 @@ long do_domctl(XEN_GUEST_HANDLE(xen_domc
>          if ( op->u.createdomain.flags & XEN_DOMCTL_CDF_oos_off )
>              domcr_flags |= DOMCRF_oos_off;
>  
> -        ret = -ENOMEM;
>          d = domain_create(dom, domcr_flags, op->u.createdomain.ssidref);
> -        if ( d == NULL )
> +        if ( IS_ERR(d) )
> +        {
> +            ret = PTR_ERR(d);
>              break;
> +        }
>  
>          ret = 0;
>  
> --- a/xen/common/schedule.c
> +++ b/xen/common/schedule.c
> @@ -28,7 +28,7 @@
>  #include <xen/softirq.h>
>  #include <xen/trace.h>
>  #include <xen/mm.h>
> -#include <xen/errno.h>
> +#include <xen/err.h>
>  #include <xen/guest_access.h>
>  #include <xen/multicall.h>
>  #include <xen/cpu.h>
> @@ -1323,7 +1323,7 @@ void __init scheduler_init(void)
>          panic("scheduler returned error on init\n");
>  
>      idle_domain = domain_create(DOMID_IDLE, 0, 0);
> -    BUG_ON(idle_domain == NULL);
> +    BUG_ON(IS_ERR(idle_domain));
>      idle_domain->vcpu = idle_vcpu;
>      idle_domain->max_vcpus = nr_cpu_ids;
>      if ( alloc_vcpu(idle_domain, 0, 0) == NULL )
> --- /dev/null
> +++ b/xen/include/xen/err.h
> @@ -0,0 +1,57 @@
> +#if !defined(__XEN_ERR_H__) && !defined(__ASSEMBLY__)
> +#define __XEN_ERR_H__
> +
> +#include <xen/compiler.h>
> +#include <xen/errno.h>
> +
> +/*
> + * Kernel pointers have redundant information, so we can use a
> + * scheme where we can return either an error code or a dentry
> + * pointer with the same return value.
> + *
> + * This could be a per-architecture thing, to allow different
> + * error and pointer decisions.
> + */
> +#define MAX_ERRNO 4095
> +
> +#define IS_ERR_VALUE(x) unlikely((x) >= (unsigned long)-MAX_ERRNO)
> +
> +static inline void *__must_check ERR_PTR(long error)
> +{
> + return (void *)error;
> +}
> +
> +static inline long __must_check PTR_ERR(const void *ptr)
> +{
> + return (long)ptr;
> +}
> +
> +static inline long __must_check IS_ERR(const void *ptr)
> +{
> + return IS_ERR_VALUE((unsigned long)ptr);
> +}
> +
> +static inline long __must_check IS_ERR_OR_NULL(const void *ptr)
> +{
> + return !ptr || IS_ERR_VALUE((unsigned long)ptr);
> +}
> +
> +/**
> + * ERR_CAST - Explicitly cast an error-valued pointer to another pointer type
> + * @ptr: The pointer to cast.
> + *
> + * Explicitly cast an error-valued pointer to another pointer type in such a
> + * way as to make it clear that's what's going on.
> + */
> +static inline void * __must_check ERR_CAST(const void *ptr)
> +{
> + /* cast away the const */
> + return (void *)ptr;
> +}
> +
> +static inline int __must_check PTR_RET(const void *ptr)
> +{
> + return IS_ERR(ptr) ? PTR_ERR(ptr) : 0;
> +}
> +
> +#endif /* __XEN_ERR_H__ */
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel



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

From xen-devel-bounces@lists.xen.org Mon Sep 03 07:37:28 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Sep 2012 07:37: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 1T8RDX-0001Wl-5z; Mon, 03 Sep 2012 07:37:07 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1T8RDV-0001Wf-GS
	for xen-devel@lists.xen.org; Mon, 03 Sep 2012 07:37:05 +0000
Received: from [85.158.139.83:62955] by server-7.bemta-5.messagelabs.com id
	82/B6-19703-02E54405; Mon, 03 Sep 2012 07:37:04 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1346657822!16945793!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-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4345 invoked from network); 3 Sep 2012 07:37:02 -0000
Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com)
	(74.125.83.45)
	by server-8.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Sep 2012 07:37:02 -0000
Received: by eeke53 with SMTP id e53so1990189eek.32
	for <xen-devel@lists.xen.org>; Mon, 03 Sep 2012 00:37: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:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=QINCF2nN76wb7CmLwNiQDTiFAQVkWzodF5J6fdAcun0=;
	b=hj8kG1GSn9CF4d6lznXexCs4xgppkbKS/vYwoLV3JQntjfikUn5tJgLzZDPEYY7wRZ
	zhdDhI9P0hNZX510s3vfTMsNGOcasiXCsinw9myrHltT3CnAN954kaA1l3+wugO6JWmU
	lIRcwiRkTSKd0pVg8L9QGBlXW9eLFLY1mqdK7xAZBghrq1wkmZQDr/RW83Vx6Y/FJ88g
	spgdFkedqtXePxuuDeVydV7TmSdjNf2qHUF9cNdtPu59Sof0Iw0DbtSVxPDacmZrtnTb
	fsQWu4CO4rZtApS64Bbf9CGxsgd1OZfEfPaMAWuk3/PLaJLhWu7bLZVUKoizX9rpOZfO
	CECQ==
Received: by 10.14.215.193 with SMTP id e41mr20323703eep.44.1346657822149;
	Mon, 03 Sep 2012 00:37:02 -0700 (PDT)
Received: from [192.168.1.69] (host86-184-74-117.range86-184.btcentralplus.com.
	[86.184.74.117])
	by mx.google.com with ESMTPS id u47sm33969294eeo.9.2012.09.03.00.37.00
	(version=SSLv3 cipher=OTHER); Mon, 03 Sep 2012 00:37:01 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Mon, 03 Sep 2012 08:36:58 +0100
From: Keir Fraser <keir.xen@gmail.com>
To: Jan Beulich <JBeulich@suse.com>,
	xen-devel <xen-devel@lists.xen.org>
Message-ID: <CC6A1CAA.3D9F0%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [PATCH] make domain_create() return a proper error
	code
Thread-Index: Ac2JpuYA3ZzoONFtQkWKioHzzWTW5g==
In-Reply-To: <504470FD0200007800098213@nat28.tlf.novell.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] [PATCH] make domain_create() return a proper error
 code
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 03/09/2012 07:57, "Jan Beulich" <JBeulich@suse.com> wrote:

> While triggered by the XSA-9 fix, this really is of more general use;
> that fix just pointed out very sharply that the current situation
> with all domain creation failures reported to user (tools) space as
> -ENOMEM is very unfortunate (actively misleading users _and_ support
> personnel).
> 
> Pull over the pointer <-> error code conversion infrastructure from
> Linux, and use it in domain_create() and all it callers.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Acked-by: Keir Fraser <keir@xen.org>

This is straightforward really. Can go in for 4.2.

> --- a/xen/arch/arm/setup.c
> +++ b/xen/arch/arm/setup.c
> @@ -26,6 +26,7 @@
>  #include <xen/serial.h>
>  #include <xen/sched.h>
>  #include <xen/console.h>
> +#include <xen/err.h>
>  #include <xen/init.h>
>  #include <xen/irq.h>
>  #include <xen/mm.h>
> @@ -237,7 +238,7 @@ void __init start_xen(unsigned long boot
>  
>      /* Create initial domain 0. */
>      dom0 = domain_create(0, 0, 0);
> -    if ( dom0 == NULL )
> +    if ( IS_ERR(dom0) )
>              printk("domain_create failed\n");
>      if ( (dom0 == NULL) || (alloc_dom0_vcpu0() == NULL) )
>              panic("Error creating domain 0\n");
> --- a/xen/arch/x86/mm.c
> +++ b/xen/arch/x86/mm.c
> @@ -91,7 +91,7 @@
>  #include <xen/mm.h>
>  #include <xen/domain.h>
>  #include <xen/sched.h>
> -#include <xen/errno.h>
> +#include <xen/err.h>
>  #include <xen/perfc.h>
>  #include <xen/irq.h>
>  #include <xen/softirq.h>
> @@ -309,7 +309,7 @@ void __init arch_init_memory(void)
>       * their domain field set to dom_xen.
>       */
>      dom_xen = domain_create(DOMID_XEN, DOMCRF_dummy, 0);
> -    BUG_ON(dom_xen == NULL);
> +    BUG_ON(IS_ERR(dom_xen));
>  
>      /*
>       * Initialise our DOMID_IO domain.
> @@ -317,14 +317,14 @@ void __init arch_init_memory(void)
>       * array. Mappings occur at the priv of the caller.
>       */
>      dom_io = domain_create(DOMID_IO, DOMCRF_dummy, 0);
> -    BUG_ON(dom_io == NULL);
> +    BUG_ON(IS_ERR(dom_io));
>      
>      /*
> -     * Initialise our DOMID_IO domain.
> +     * Initialise our COW domain.
>       * This domain owns sharable pages.
>       */
>      dom_cow = domain_create(DOMID_COW, DOMCRF_dummy, 0);
> -    BUG_ON(dom_cow == NULL);
> +    BUG_ON(IS_ERR(dom_cow));
>  
>      /* First 1MB of RAM is historically marked as I/O. */
>      for ( i = 0; i < 0x100; i++ )
> --- a/xen/arch/x86/setup.c
> +++ b/xen/arch/x86/setup.c
> @@ -1,6 +1,7 @@
>  #include <xen/config.h>
>  #include <xen/init.h>
>  #include <xen/lib.h>
> +#include <xen/err.h>
>  #include <xen/sched.h>
>  #include <xen/sched-if.h>
>  #include <xen/domain.h>
> @@ -1319,7 +1320,7 @@ void __init __start_xen(unsigned long mb
>  
>      /* Create initial domain 0. */
>      dom0 = domain_create(0, DOMCRF_s3_integrity, 0);
> -    if ( (dom0 == NULL) || (alloc_dom0_vcpu0() == NULL) )
> +    if ( IS_ERR(dom0) || (alloc_dom0_vcpu0() == NULL) )
>          panic("Error creating domain 0\n");
>  
>      dom0->is_privileged = 1;
> --- a/xen/common/cpupool.c
> +++ b/xen/common/cpupool.c
> @@ -370,14 +370,18 @@ out:
>  int cpupool_add_domain(struct domain *d, int poolid)
>  {
>      struct cpupool *c;
> -    int rc = 1;
> +    int rc;
>      int n_dom = 0;
>  
>      if ( poolid == CPUPOOLID_NONE )
>          return 0;
>      spin_lock(&cpupool_lock);
>      c = cpupool_find_by_id(poolid);
> -    if ( (c != NULL) && cpumask_weight(c->cpu_valid) )
> +    if ( c == NULL )
> +        rc = -ESRCH;
> +    else if ( !cpumask_weight(c->cpu_valid) )
> +        rc = -ENODEV;
> +    else
>      {
>          c->n_dom++;
>          n_dom = c->n_dom;
> --- a/xen/common/domain.c
> +++ b/xen/common/domain.c
> @@ -9,7 +9,7 @@
>  #include <xen/init.h>
>  #include <xen/lib.h>
>  #include <xen/ctype.h>
> -#include <xen/errno.h>
> +#include <xen/err.h>
>  #include <xen/sched.h>
>  #include <xen/sched-if.h>
>  #include <xen/domain.h>
> @@ -196,17 +196,17 @@ 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 };
> -    int init_status = 0;
> +    int err, init_status = 0;
>      int poolid = CPUPOOLID_NONE;
>  
>      if ( (d = alloc_domain_struct()) == NULL )
> -        return NULL;
> +        return ERR_PTR(-ENOMEM);
>  
>      d->domain_id = domid;
>  
>      lock_profile_register_struct(LOCKPROF_TYPE_PERDOM, d, domid, "Domain");
>  
> -    if ( xsm_alloc_security_domain(d) != 0 )
> +    if ( (err = xsm_alloc_security_domain(d)) != 0 )
>          goto fail;
>      init_status |= INIT_xsm;
>  
> @@ -226,6 +226,7 @@ struct domain *domain_create(
>      spin_lock_init(&d->shutdown_lock);
>      d->shutdown_code = -1;
>  
> +    err = -ENOMEM;
>      if ( !zalloc_cpumask_var(&d->domain_dirty_cpumask) )
>          goto fail;
>  
> @@ -251,7 +252,7 @@ struct domain *domain_create(
>  
>      if ( !is_idle_domain(d) )
>      {
> -        if ( xsm_domain_create(d, ssidref) != 0 )
> +        if ( (err = xsm_domain_create(d, ssidref)) != 0 )
>              goto fail;
>  
>          d->is_paused_by_controller = 1;
> @@ -266,29 +267,30 @@ struct domain *domain_create(
>  
>          radix_tree_init(&d->pirq_tree);
>  
> -        if ( evtchn_init(d) != 0 )
> +        if ( (err = evtchn_init(d)) != 0 )
>              goto fail;
>          init_status |= INIT_evtchn;
>  
> -        if ( grant_table_create(d) != 0 )
> +        if ( (err = grant_table_create(d)) != 0 )
>              goto fail;
>          init_status |= INIT_gnttab;
>  
>          poolid = 0;
>  
> +        err = -ENOMEM;
>          d->mem_event = xzalloc(struct mem_event_per_domain);
>          if ( !d->mem_event )
>              goto fail;
>      }
>  
> -    if ( arch_domain_create(d, domcr_flags) != 0 )
> +    if ( (err = arch_domain_create(d, domcr_flags)) != 0 )
>          goto fail;
>      init_status |= INIT_arch;
>  
> -    if ( cpupool_add_domain(d, poolid) != 0 )
> +    if ( (err = cpupool_add_domain(d, poolid)) != 0 )
>          goto fail;
>  
> -    if ( sched_init_domain(d) != 0 )
> +    if ( (err = sched_init_domain(d)) != 0 )
>          goto fail;
>  
>      if ( !is_idle_domain(d) )
> @@ -329,7 +331,7 @@ struct domain *domain_create(
>          xsm_free_security_domain(d);
>      free_cpumask_var(d->domain_dirty_cpumask);
>      free_domain_struct(d);
> -    return NULL;
> +    return ERR_PTR(err);
>  }
>  
>  
> --- a/xen/common/domctl.c
> +++ b/xen/common/domctl.c
> @@ -9,6 +9,7 @@
>  #include <xen/config.h>
>  #include <xen/types.h>
>  #include <xen/lib.h>
> +#include <xen/err.h>
>  #include <xen/mm.h>
>  #include <xen/sched.h>
>  #include <xen/sched-if.h>
> @@ -455,10 +456,12 @@ long do_domctl(XEN_GUEST_HANDLE(xen_domc
>          if ( op->u.createdomain.flags & XEN_DOMCTL_CDF_oos_off )
>              domcr_flags |= DOMCRF_oos_off;
>  
> -        ret = -ENOMEM;
>          d = domain_create(dom, domcr_flags, op->u.createdomain.ssidref);
> -        if ( d == NULL )
> +        if ( IS_ERR(d) )
> +        {
> +            ret = PTR_ERR(d);
>              break;
> +        }
>  
>          ret = 0;
>  
> --- a/xen/common/schedule.c
> +++ b/xen/common/schedule.c
> @@ -28,7 +28,7 @@
>  #include <xen/softirq.h>
>  #include <xen/trace.h>
>  #include <xen/mm.h>
> -#include <xen/errno.h>
> +#include <xen/err.h>
>  #include <xen/guest_access.h>
>  #include <xen/multicall.h>
>  #include <xen/cpu.h>
> @@ -1323,7 +1323,7 @@ void __init scheduler_init(void)
>          panic("scheduler returned error on init\n");
>  
>      idle_domain = domain_create(DOMID_IDLE, 0, 0);
> -    BUG_ON(idle_domain == NULL);
> +    BUG_ON(IS_ERR(idle_domain));
>      idle_domain->vcpu = idle_vcpu;
>      idle_domain->max_vcpus = nr_cpu_ids;
>      if ( alloc_vcpu(idle_domain, 0, 0) == NULL )
> --- /dev/null
> +++ b/xen/include/xen/err.h
> @@ -0,0 +1,57 @@
> +#if !defined(__XEN_ERR_H__) && !defined(__ASSEMBLY__)
> +#define __XEN_ERR_H__
> +
> +#include <xen/compiler.h>
> +#include <xen/errno.h>
> +
> +/*
> + * Kernel pointers have redundant information, so we can use a
> + * scheme where we can return either an error code or a dentry
> + * pointer with the same return value.
> + *
> + * This could be a per-architecture thing, to allow different
> + * error and pointer decisions.
> + */
> +#define MAX_ERRNO 4095
> +
> +#define IS_ERR_VALUE(x) unlikely((x) >= (unsigned long)-MAX_ERRNO)
> +
> +static inline void *__must_check ERR_PTR(long error)
> +{
> + return (void *)error;
> +}
> +
> +static inline long __must_check PTR_ERR(const void *ptr)
> +{
> + return (long)ptr;
> +}
> +
> +static inline long __must_check IS_ERR(const void *ptr)
> +{
> + return IS_ERR_VALUE((unsigned long)ptr);
> +}
> +
> +static inline long __must_check IS_ERR_OR_NULL(const void *ptr)
> +{
> + return !ptr || IS_ERR_VALUE((unsigned long)ptr);
> +}
> +
> +/**
> + * ERR_CAST - Explicitly cast an error-valued pointer to another pointer type
> + * @ptr: The pointer to cast.
> + *
> + * Explicitly cast an error-valued pointer to another pointer type in such a
> + * way as to make it clear that's what's going on.
> + */
> +static inline void * __must_check ERR_CAST(const void *ptr)
> +{
> + /* cast away the const */
> + return (void *)ptr;
> +}
> +
> +static inline int __must_check PTR_RET(const void *ptr)
> +{
> + return IS_ERR(ptr) ? PTR_ERR(ptr) : 0;
> +}
> +
> +#endif /* __XEN_ERR_H__ */
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel



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

From xen-devel-bounces@lists.xen.org Mon Sep 03 07:39:17 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Sep 2012 07: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 1T8RFO-0001bi-Mp; Mon, 03 Sep 2012 07:39:02 +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 1T8RFN-0001bX-1j
	for xen-devel@lists.xen.org; Mon, 03 Sep 2012 07:39:01 +0000
Received: from [85.158.139.83:42020] by server-4.bemta-5.messagelabs.com id
	6A/A0-23042-49E54405; Mon, 03 Sep 2012 07:39:00 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1346657939!28041286!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-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24557 invoked from network); 3 Sep 2012 07:38:59 -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;
	3 Sep 2012 07:38:59 -0000
Received: by eaac13 with SMTP id c13so1582518eaa.32
	for <xen-devel@lists.xen.org>; Mon, 03 Sep 2012 00:38:59 -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=Z5i+Eio2Zaxvc1E32Awz79sj4yMuikhb5B1UrylKjqs=;
	b=i2OT4HRf9TYgGOOoUcq0UDNo9PbuUYkoQlpv/HqIngoFI849+qTDpWMijVASV35/0T
	2C3nI6kM+0oz6am5qJ4m41anelaFBj9x5awblWtdEbiKxSCuhS+1usmwLIszBG9SLVUZ
	slCkYYn5vp7VIrd/ZXQ/52wy3P1AIJe50iWkhHUsKMdCy4HSh3N/80iSOJFfJXNxU2M4
	Uz3A2qwr60X94ZDQMEJvQpRaEVKnkR/uRTE4In6P6m7cgcRcK+0EFhrJBgCkC9jaS5y2
	OCjQuqfpxo7jcfayFNRcxcB7b5dK6xvRubIt6Z1ltenHxHiX4FwPo0dEmRDBvL2DB7s2
	1Udg==
Received: by 10.14.213.137 with SMTP id a9mr20226068eep.38.1346657939551;
	Mon, 03 Sep 2012 00:38:59 -0700 (PDT)
Received: from [192.168.1.69] (host86-184-74-117.range86-184.btcentralplus.com.
	[86.184.74.117])
	by mx.google.com with ESMTPS id i8sm33942604eeo.16.2012.09.03.00.38.58
	(version=SSLv3 cipher=OTHER); Mon, 03 Sep 2012 00:38:58 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Mon, 03 Sep 2012 08:38:54 +0100
From: Keir Fraser <keir.xen@gmail.com>
To: Jan Beulich <JBeulich@suse.com>,
	xen-devel <xen-devel@lists.xen.org>
Message-ID: <CC6A1D1E.3D9F2%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [PATCH] x86/32-on-64: adjust Dom0 initial page table
	layout
Thread-Index: Ac2Jpyskr9SeAANVLkuzcy6v2yk5qQ==
In-Reply-To: <5044711F020000780009821F@nat28.tlf.novell.com>
Mime-version: 1.0
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH] x86/32-on-64: adjust Dom0 initial page
 table layout
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 03/09/2012 07:58, "Jan Beulich" <JBeulich@suse.com> wrote:

> Drop the unnecessary reservation of the L4 page for 32on64 Dom0, and
> allocate its L3 first (to match behavior when running identical bit-
> width hypervisor and Dom0 kernel).
> 
> Reported-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

This, and your other proposed patch to xc_dom_x86.c, I'm not sure about for
4.2.0. Are we prepared to possibly slip 4.2.0 for these, rather than put
them in 4.2.1 instead (which will certainly be sooner than our proposed
usual 3-month schedule for point releases)?

 -- Keir

> --- a/xen/arch/x86/domain_build.c
> +++ b/xen/arch/x86/domain_build.c
> @@ -510,7 +510,7 @@ int __init construct_dom0(
>  #define NR(_l,_h,_s) \
>      (((((_h) + ((1UL<<(_s))-1)) & ~((1UL<<(_s))-1)) - \
>         ((_l) & ~((1UL<<(_s))-1))) >> (_s))
> -        if ( (1 + /* # L4 */
> +        if ( (!is_pv_32on64_domain(d) + /* # L4 */
>                NR(v_start, v_end, L4_PAGETABLE_SHIFT) + /* # L3 */
>                (!is_pv_32on64_domain(d) ?
>                 NR(v_start, v_end, L3_PAGETABLE_SHIFT) : /* # L2 */
> @@ -756,6 +756,8 @@ int __init construct_dom0(
>              panic("Not enough RAM for domain 0 PML4.\n");
>          page->u.inuse.type_info = PGT_l4_page_table|PGT_validated|1;
>          l4start = l4tab = page_to_virt(page);
> +        maddr_to_page(mpt_alloc)->u.inuse.type_info = PGT_l3_page_table;
> +        l3start = __va(mpt_alloc); mpt_alloc += PAGE_SIZE;
>      }
>      copy_page(l4tab, idle_pg_table);
>      l4tab[0] = l4e_empty(); /* zap trampoline mapping */
> @@ -787,9 +789,13 @@ int __init construct_dom0(
>                      l2tab += l2_table_offset(v_start);
>                  if ( !((unsigned long)l3tab & (PAGE_SIZE-1)) )
>                  {
> -                    maddr_to_page(mpt_alloc)->u.inuse.type_info =
> -                        PGT_l3_page_table;
> -                    l3start = l3tab = __va(mpt_alloc); mpt_alloc +=
> PAGE_SIZE;
> +                    if ( count || !l3start )
> +                    {
> +                        maddr_to_page(mpt_alloc)->u.inuse.type_info =
> +                            PGT_l3_page_table;
> +                        l3start = __va(mpt_alloc); mpt_alloc += PAGE_SIZE;
> +                    }
> +                    l3tab = l3start;
>                      clear_page(l3tab);
>                      if ( count == 0 )
>                          l3tab += l3_table_offset(v_start);
> @@ -938,7 +944,7 @@ int __init construct_dom0(
>      if ( !vinitrd_start && initrd_len )
>          si->flags   |= SIF_MOD_START_PFN;
>      si->flags       |= (xen_processor_pmbits << 8) & SIF_PM_MASK;
> -    si->pt_base      = vpt_start + 2 * PAGE_SIZE * !!is_pv_32on64_domain(d);
> +    si->pt_base      = vpt_start;
>      si->nr_pt_frames = nr_pt_pages;
>      si->mfn_list     = vphysmap_start;
>      snprintf(si->magic, sizeof(si->magic), "xen-3.0-x86_%d%s",
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Sep 03 07:39:17 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Sep 2012 07: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 1T8RFO-0001bi-Mp; Mon, 03 Sep 2012 07:39:02 +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 1T8RFN-0001bX-1j
	for xen-devel@lists.xen.org; Mon, 03 Sep 2012 07:39:01 +0000
Received: from [85.158.139.83:42020] by server-4.bemta-5.messagelabs.com id
	6A/A0-23042-49E54405; Mon, 03 Sep 2012 07:39:00 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1346657939!28041286!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-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24557 invoked from network); 3 Sep 2012 07:38:59 -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;
	3 Sep 2012 07:38:59 -0000
Received: by eaac13 with SMTP id c13so1582518eaa.32
	for <xen-devel@lists.xen.org>; Mon, 03 Sep 2012 00:38:59 -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=Z5i+Eio2Zaxvc1E32Awz79sj4yMuikhb5B1UrylKjqs=;
	b=i2OT4HRf9TYgGOOoUcq0UDNo9PbuUYkoQlpv/HqIngoFI849+qTDpWMijVASV35/0T
	2C3nI6kM+0oz6am5qJ4m41anelaFBj9x5awblWtdEbiKxSCuhS+1usmwLIszBG9SLVUZ
	slCkYYn5vp7VIrd/ZXQ/52wy3P1AIJe50iWkhHUsKMdCy4HSh3N/80iSOJFfJXNxU2M4
	Uz3A2qwr60X94ZDQMEJvQpRaEVKnkR/uRTE4In6P6m7cgcRcK+0EFhrJBgCkC9jaS5y2
	OCjQuqfpxo7jcfayFNRcxcB7b5dK6xvRubIt6Z1ltenHxHiX4FwPo0dEmRDBvL2DB7s2
	1Udg==
Received: by 10.14.213.137 with SMTP id a9mr20226068eep.38.1346657939551;
	Mon, 03 Sep 2012 00:38:59 -0700 (PDT)
Received: from [192.168.1.69] (host86-184-74-117.range86-184.btcentralplus.com.
	[86.184.74.117])
	by mx.google.com with ESMTPS id i8sm33942604eeo.16.2012.09.03.00.38.58
	(version=SSLv3 cipher=OTHER); Mon, 03 Sep 2012 00:38:58 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Mon, 03 Sep 2012 08:38:54 +0100
From: Keir Fraser <keir.xen@gmail.com>
To: Jan Beulich <JBeulich@suse.com>,
	xen-devel <xen-devel@lists.xen.org>
Message-ID: <CC6A1D1E.3D9F2%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [PATCH] x86/32-on-64: adjust Dom0 initial page table
	layout
Thread-Index: Ac2Jpyskr9SeAANVLkuzcy6v2yk5qQ==
In-Reply-To: <5044711F020000780009821F@nat28.tlf.novell.com>
Mime-version: 1.0
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH] x86/32-on-64: adjust Dom0 initial page
 table layout
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 03/09/2012 07:58, "Jan Beulich" <JBeulich@suse.com> wrote:

> Drop the unnecessary reservation of the L4 page for 32on64 Dom0, and
> allocate its L3 first (to match behavior when running identical bit-
> width hypervisor and Dom0 kernel).
> 
> Reported-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

This, and your other proposed patch to xc_dom_x86.c, I'm not sure about for
4.2.0. Are we prepared to possibly slip 4.2.0 for these, rather than put
them in 4.2.1 instead (which will certainly be sooner than our proposed
usual 3-month schedule for point releases)?

 -- Keir

> --- a/xen/arch/x86/domain_build.c
> +++ b/xen/arch/x86/domain_build.c
> @@ -510,7 +510,7 @@ int __init construct_dom0(
>  #define NR(_l,_h,_s) \
>      (((((_h) + ((1UL<<(_s))-1)) & ~((1UL<<(_s))-1)) - \
>         ((_l) & ~((1UL<<(_s))-1))) >> (_s))
> -        if ( (1 + /* # L4 */
> +        if ( (!is_pv_32on64_domain(d) + /* # L4 */
>                NR(v_start, v_end, L4_PAGETABLE_SHIFT) + /* # L3 */
>                (!is_pv_32on64_domain(d) ?
>                 NR(v_start, v_end, L3_PAGETABLE_SHIFT) : /* # L2 */
> @@ -756,6 +756,8 @@ int __init construct_dom0(
>              panic("Not enough RAM for domain 0 PML4.\n");
>          page->u.inuse.type_info = PGT_l4_page_table|PGT_validated|1;
>          l4start = l4tab = page_to_virt(page);
> +        maddr_to_page(mpt_alloc)->u.inuse.type_info = PGT_l3_page_table;
> +        l3start = __va(mpt_alloc); mpt_alloc += PAGE_SIZE;
>      }
>      copy_page(l4tab, idle_pg_table);
>      l4tab[0] = l4e_empty(); /* zap trampoline mapping */
> @@ -787,9 +789,13 @@ int __init construct_dom0(
>                      l2tab += l2_table_offset(v_start);
>                  if ( !((unsigned long)l3tab & (PAGE_SIZE-1)) )
>                  {
> -                    maddr_to_page(mpt_alloc)->u.inuse.type_info =
> -                        PGT_l3_page_table;
> -                    l3start = l3tab = __va(mpt_alloc); mpt_alloc +=
> PAGE_SIZE;
> +                    if ( count || !l3start )
> +                    {
> +                        maddr_to_page(mpt_alloc)->u.inuse.type_info =
> +                            PGT_l3_page_table;
> +                        l3start = __va(mpt_alloc); mpt_alloc += PAGE_SIZE;
> +                    }
> +                    l3tab = l3start;
>                      clear_page(l3tab);
>                      if ( count == 0 )
>                          l3tab += l3_table_offset(v_start);
> @@ -938,7 +944,7 @@ int __init construct_dom0(
>      if ( !vinitrd_start && initrd_len )
>          si->flags   |= SIF_MOD_START_PFN;
>      si->flags       |= (xen_processor_pmbits << 8) & SIF_PM_MASK;
> -    si->pt_base      = vpt_start + 2 * PAGE_SIZE * !!is_pv_32on64_domain(d);
> +    si->pt_base      = vpt_start;
>      si->nr_pt_frames = nr_pt_pages;
>      si->mfn_list     = vphysmap_start;
>      snprintf(si->magic, sizeof(si->magic), "xen-3.0-x86_%d%s",
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Sep 03 07:46:01 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Sep 2012 07: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 1T8RLn-0001qu-Nk; Mon, 03 Sep 2012 07:45: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 1T8RLm-0001qp-8H
	for xen-devel@lists.xen.org; Mon, 03 Sep 2012 07:45:38 +0000
Received: from [85.158.143.99:23262] by server-3.bemta-4.messagelabs.com id
	96/7B-08232-12064405; Mon, 03 Sep 2012 07:45:37 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1346658328!18389350!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM3ODU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26084 invoked from network); 3 Sep 2012 07:45:35 -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;
	3 Sep 2012 07:45:35 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 03 Sep 2012 08:45:27 +0100
Message-Id: <50447C3202000078000982A0@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 03 Sep 2012 08:45:22 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Yongjie Ren" <yongjie.ren@intel.com>,
	"Konrad Rzeszutek Wilk" <konrad@kernel.org>
References: <1B4B44D9196EFF41AE41FDA404FC0A1018AF31@SHSMSX101.ccr.corp.intel.com>
	<20120831172410.GA19756@localhost.localdomain>
In-Reply-To: <20120831172410.GA19756@localhost.localdomain>
Mime-Version: 1.0
Content-Disposition: inline
Cc: 'Konrad Rzeszutek Wilk' <konrad.wilk@oracle.com>,
	'Keir Fraser' <keir@xen.org>, 'Ian Campbell' <Ian.Campbell@citrix.com>,
	'xen-devel' <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen4.2-rc3 test result
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 31.08.12 at 19:24, Konrad Rzeszutek Wilk <konrad@kernel.org> wrote:
> On Fri, Aug 31, 2012 at 07:27:51AM +0000, Ren, Yongjie wrote:
>> 6. Guest hang after resuming from S3
>>   http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1828 
> 
> Jan posted some patches to fix that. Can you test with an up-to-date
> guest? (so not RHEL6U1 which does not have the fix).

Did I? I don't recall...

Jan


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

From xen-devel-bounces@lists.xen.org Mon Sep 03 07:46:01 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Sep 2012 07: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 1T8RLn-0001qu-Nk; Mon, 03 Sep 2012 07:45: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 1T8RLm-0001qp-8H
	for xen-devel@lists.xen.org; Mon, 03 Sep 2012 07:45:38 +0000
Received: from [85.158.143.99:23262] by server-3.bemta-4.messagelabs.com id
	96/7B-08232-12064405; Mon, 03 Sep 2012 07:45:37 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1346658328!18389350!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM3ODU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26084 invoked from network); 3 Sep 2012 07:45:35 -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;
	3 Sep 2012 07:45:35 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 03 Sep 2012 08:45:27 +0100
Message-Id: <50447C3202000078000982A0@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 03 Sep 2012 08:45:22 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Yongjie Ren" <yongjie.ren@intel.com>,
	"Konrad Rzeszutek Wilk" <konrad@kernel.org>
References: <1B4B44D9196EFF41AE41FDA404FC0A1018AF31@SHSMSX101.ccr.corp.intel.com>
	<20120831172410.GA19756@localhost.localdomain>
In-Reply-To: <20120831172410.GA19756@localhost.localdomain>
Mime-Version: 1.0
Content-Disposition: inline
Cc: 'Konrad Rzeszutek Wilk' <konrad.wilk@oracle.com>,
	'Keir Fraser' <keir@xen.org>, 'Ian Campbell' <Ian.Campbell@citrix.com>,
	'xen-devel' <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen4.2-rc3 test result
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 31.08.12 at 19:24, Konrad Rzeszutek Wilk <konrad@kernel.org> wrote:
> On Fri, Aug 31, 2012 at 07:27:51AM +0000, Ren, Yongjie wrote:
>> 6. Guest hang after resuming from S3
>>   http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1828 
> 
> Jan posted some patches to fix that. Can you test with an up-to-date
> guest? (so not RHEL6U1 which does not have the fix).

Did I? I don't recall...

Jan


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

From xen-devel-bounces@lists.xen.org Mon Sep 03 07:51:21 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Sep 2012 07: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 1T8RR0-0001zZ-M8; Mon, 03 Sep 2012 07:51:02 +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 1T8RQz-0001zP-94
	for xen-devel@lists.xen.org; Mon, 03 Sep 2012 07:51:01 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1346658651!2450972!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM3ODU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21318 invoked from network); 3 Sep 2012 07:50:51 -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;
	3 Sep 2012 07:50:51 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 03 Sep 2012 08:50:51 +0100
Message-Id: <50447D7802000078000982B4@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 03 Sep 2012 08:50:48 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Campbell" <Ian.Campbell@citrix.com>
References: <1344935141.5926.6.camel@zakaz.uk.xensource.com>
	<20120814100704.GA19704@bloms.de>
	<1346421542.27277.218.camel@zakaz.uk.xensource.com>
	<1346425278.27277.224.camel@zakaz.uk.xensource.com>
	<5040F7140200007800097E91@nat28.tlf.novell.com>
	<1346428292.27277.243.camel@zakaz.uk.xensource.com>
	<5040FB490200007800097ED2@nat28.tlf.novell.com>
	<50409CE002000076000B3B44@novprvoes0310.provo.novell.com>
	<1346434547.5820.10.camel@dagon.hellion.org.uk> 
In-Reply-To: 
Mime-Version: 1.0
Content-Disposition: inline
Cc: Charles Arnold <CARNOLD@suse.com>, Kirk Allan <KALLAN@suse.com>,
	DieterBloms <xensource.com@bloms.de>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [Xen-users] Xen 4.2 TODO (io and irq parameter are
 not evaluated by xl)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 31.08.12 at 19:59, Kirk Allan wrote:
>>> In one of my Window's vm config files, I was able to get the vm to
>>> boot using ioports=['3f8-3ff'].  My goal was to do serial debugging of
>>> the Windows vm.  I also added irq=[4] to the config file.  However, I
>>> was not able to actually get a debug session to work.  The physical
>>> machine running windbg received a string from the vm which gave me
>>> hope that it was working, but then it never received further data so
>>> the vm eventually booted without being attached to the debugger.
>> 
>> Thanks, the question was whether it would be useful to implement the
>> 	ioports = '3f8-3ff'
>> 	irq = 4
>> syntax as well as the
>> 	ioports = ['3f8-3ff']
>> 	irq = [4]
>> but it looks like you are actually using the array version anyway?
> 
> I first looked at this last week.  I found reference to both formats so I 
> tried both.  I was only able to get the ioports = ['3f8-3ff'] and irq = [4] 
> syntax to allow a vm to boot.

So Ian, I guess I got mislead by there being references to the
non-array format - no need to alter your patch then in any way.

Sorry for the noise, Jan


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

From xen-devel-bounces@lists.xen.org Mon Sep 03 07:51:21 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Sep 2012 07: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 1T8RR0-0001zZ-M8; Mon, 03 Sep 2012 07:51:02 +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 1T8RQz-0001zP-94
	for xen-devel@lists.xen.org; Mon, 03 Sep 2012 07:51:01 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1346658651!2450972!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM3ODU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21318 invoked from network); 3 Sep 2012 07:50:51 -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;
	3 Sep 2012 07:50:51 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 03 Sep 2012 08:50:51 +0100
Message-Id: <50447D7802000078000982B4@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 03 Sep 2012 08:50:48 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Campbell" <Ian.Campbell@citrix.com>
References: <1344935141.5926.6.camel@zakaz.uk.xensource.com>
	<20120814100704.GA19704@bloms.de>
	<1346421542.27277.218.camel@zakaz.uk.xensource.com>
	<1346425278.27277.224.camel@zakaz.uk.xensource.com>
	<5040F7140200007800097E91@nat28.tlf.novell.com>
	<1346428292.27277.243.camel@zakaz.uk.xensource.com>
	<5040FB490200007800097ED2@nat28.tlf.novell.com>
	<50409CE002000076000B3B44@novprvoes0310.provo.novell.com>
	<1346434547.5820.10.camel@dagon.hellion.org.uk> 
In-Reply-To: 
Mime-Version: 1.0
Content-Disposition: inline
Cc: Charles Arnold <CARNOLD@suse.com>, Kirk Allan <KALLAN@suse.com>,
	DieterBloms <xensource.com@bloms.de>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [Xen-users] Xen 4.2 TODO (io and irq parameter are
 not evaluated by xl)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 31.08.12 at 19:59, Kirk Allan wrote:
>>> In one of my Window's vm config files, I was able to get the vm to
>>> boot using ioports=['3f8-3ff'].  My goal was to do serial debugging of
>>> the Windows vm.  I also added irq=[4] to the config file.  However, I
>>> was not able to actually get a debug session to work.  The physical
>>> machine running windbg received a string from the vm which gave me
>>> hope that it was working, but then it never received further data so
>>> the vm eventually booted without being attached to the debugger.
>> 
>> Thanks, the question was whether it would be useful to implement the
>> 	ioports = '3f8-3ff'
>> 	irq = 4
>> syntax as well as the
>> 	ioports = ['3f8-3ff']
>> 	irq = [4]
>> but it looks like you are actually using the array version anyway?
> 
> I first looked at this last week.  I found reference to both formats so I 
> tried both.  I was only able to get the ioports = ['3f8-3ff'] and irq = [4] 
> syntax to allow a vm to boot.

So Ian, I guess I got mislead by there being references to the
non-array format - no need to alter your patch then in any way.

Sorry for the noise, Jan


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

From xen-devel-bounces@lists.xen.org Mon Sep 03 07:57:51 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Sep 2012 07:57: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 1T8RXL-0002Hd-59; Mon, 03 Sep 2012 07:57:35 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1T8RXK-0002HT-28
	for xen-devel@lists.xen.org; Mon, 03 Sep 2012 07:57:34 +0000
Received: from [85.158.143.99:37027] by server-1.bemta-4.messagelabs.com id
	0E/7A-12504-DE264405; Mon, 03 Sep 2012 07:57:33 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1346659051!18539223!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM3ODU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24666 invoked from network); 3 Sep 2012 07:57:31 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-14.tower-216.messagelabs.com with SMTP;
	3 Sep 2012 07:57:31 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 03 Sep 2012 08:57:31 +0100
Message-Id: <50447F0602000078000982D3@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 03 Sep 2012 08:57:26 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Keir Fraser" <keir.xen@gmail.com>
References: <5044711F020000780009821F@nat28.tlf.novell.com>
	<CC6A1D1E.3D9F2%keir.xen@gmail.com>
In-Reply-To: <CC6A1D1E.3D9F2%keir.xen@gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] x86/32-on-64: adjust Dom0 initial page
 table layout
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 03.09.12 at 09:38, Keir Fraser <keir.xen@gmail.com> wrote:
> On 03/09/2012 07:58, "Jan Beulich" <JBeulich@suse.com> wrote:
> 
>> Drop the unnecessary reservation of the L4 page for 32on64 Dom0, and
>> allocate its L3 first (to match behavior when running identical bit-
>> width hypervisor and Dom0 kernel).
>> 
>> Reported-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> 
> This, and your other proposed patch to xc_dom_x86.c, I'm not sure about for
> 4.2.0. Are we prepared to possibly slip 4.2.0 for these, rather than put
> them in 4.2.1 instead (which will certainly be sooner than our proposed
> usual 3-month schedule for point releases)?

Holding back this one for post-4.2 is fine with me (as it doesn't
really address an outright bug, it just makes things more
consistent).

The tools side patch, however, I consider more important,
since the code is so obviously flawed (and that's irrespective
of this having been that way all the way back to the
introduction of the "new" [back then] domain builder). But
of course I'd like to see it tested with that big a domain first,
which I can't due to not having access to a suitable system.

Jan


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

From xen-devel-bounces@lists.xen.org Mon Sep 03 07:57:51 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Sep 2012 07:57: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 1T8RXL-0002Hd-59; Mon, 03 Sep 2012 07:57:35 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1T8RXK-0002HT-28
	for xen-devel@lists.xen.org; Mon, 03 Sep 2012 07:57:34 +0000
Received: from [85.158.143.99:37027] by server-1.bemta-4.messagelabs.com id
	0E/7A-12504-DE264405; Mon, 03 Sep 2012 07:57:33 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1346659051!18539223!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM3ODU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24666 invoked from network); 3 Sep 2012 07:57:31 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-14.tower-216.messagelabs.com with SMTP;
	3 Sep 2012 07:57:31 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 03 Sep 2012 08:57:31 +0100
Message-Id: <50447F0602000078000982D3@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 03 Sep 2012 08:57:26 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Keir Fraser" <keir.xen@gmail.com>
References: <5044711F020000780009821F@nat28.tlf.novell.com>
	<CC6A1D1E.3D9F2%keir.xen@gmail.com>
In-Reply-To: <CC6A1D1E.3D9F2%keir.xen@gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] x86/32-on-64: adjust Dom0 initial page
 table layout
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 03.09.12 at 09:38, Keir Fraser <keir.xen@gmail.com> wrote:
> On 03/09/2012 07:58, "Jan Beulich" <JBeulich@suse.com> wrote:
> 
>> Drop the unnecessary reservation of the L4 page for 32on64 Dom0, and
>> allocate its L3 first (to match behavior when running identical bit-
>> width hypervisor and Dom0 kernel).
>> 
>> Reported-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> 
> This, and your other proposed patch to xc_dom_x86.c, I'm not sure about for
> 4.2.0. Are we prepared to possibly slip 4.2.0 for these, rather than put
> them in 4.2.1 instead (which will certainly be sooner than our proposed
> usual 3-month schedule for point releases)?

Holding back this one for post-4.2 is fine with me (as it doesn't
really address an outright bug, it just makes things more
consistent).

The tools side patch, however, I consider more important,
since the code is so obviously flawed (and that's irrespective
of this having been that way all the way back to the
introduction of the "new" [back then] domain builder). But
of course I'd like to see it tested with that big a domain first,
which I can't due to not having access to a suitable system.

Jan


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

From xen-devel-bounces@lists.xen.org Mon Sep 03 08:15:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Sep 2012 08: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 1T8Ro7-0003Ao-Ng; Mon, 03 Sep 2012 08:14:55 +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 1T8Ro6-0003Aj-9w
	for xen-devel@lists.xen.org; Mon, 03 Sep 2012 08:14:54 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1346660064!9170447!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM3ODU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21711 invoked from network); 3 Sep 2012 08:14:25 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-13.tower-27.messagelabs.com with SMTP;
	3 Sep 2012 08:14:25 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 03 Sep 2012 09:14:24 +0100
Message-Id: <504482FD02000078000982E3@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 03 Sep 2012 09:14:20 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Santosh Jodh" <Santosh.Jodh@citrix.com>,
	"Sander Eikelenboom" <linux@eikelenboom.it>
References: <647712821.20120831234512@eikelenboom.it>
	<7914B38A4445B34AA16EB9F1352942F1012F0F6F4AE2@SJCPMAILBOX01.citrite.net>
	<723041396.20120901004249@eikelenboom.it>
	<7914B38A4445B34AA16EB9F1352942F1012F0F6F4B01@SJCPMAILBOX01.citrite.net>
	<1377403931.20120901011625@eikelenboom.it>
	<7914B38A4445B34AA16EB9F1352942F1012F0F6F4B5B@SJCPMAILBOX01.citrite.net>
In-Reply-To: <7914B38A4445B34AA16EB9F1352942F1012F0F6F4B5B@SJCPMAILBOX01.citrite.net>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "wei.wang2@amd.com" <wei.wang2@amd.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Using debug-key 'o:  Dump IOMMU p2m table,
 locks up machine
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.09.12 at 02:42, Santosh Jodh <Santosh.Jodh@citrix.com> wrote:
> BTW, I should add that 1:1 mapping for the VM seems very suspicious. Wei can 
> comment for sure.

For PV guests, that's very much expected, I would say.

Jan

>> -----Original Message-----
>> From: Santosh Jodh
>> Sent: Friday, August 31, 2012 4:58 PM
>> To: 'Sander Eikelenboom'
>> Cc: wei.wang2@amd.com; xen-devel@lists.xen.org 
>> Subject: RE: Using debug-key 'o: Dump IOMMU p2m table, locks up machine
>> 
>> 1:1 mapping is not the common case for gfn-mfn. It is hard to say how much
>> output would shrink by dumping contiguous ranges instead of individual pfns
>> in the general case.



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

From xen-devel-bounces@lists.xen.org Mon Sep 03 08:15:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Sep 2012 08: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 1T8Ro7-0003Ao-Ng; Mon, 03 Sep 2012 08:14:55 +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 1T8Ro6-0003Aj-9w
	for xen-devel@lists.xen.org; Mon, 03 Sep 2012 08:14:54 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1346660064!9170447!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM3ODU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21711 invoked from network); 3 Sep 2012 08:14:25 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-13.tower-27.messagelabs.com with SMTP;
	3 Sep 2012 08:14:25 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 03 Sep 2012 09:14:24 +0100
Message-Id: <504482FD02000078000982E3@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 03 Sep 2012 09:14:20 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Santosh Jodh" <Santosh.Jodh@citrix.com>,
	"Sander Eikelenboom" <linux@eikelenboom.it>
References: <647712821.20120831234512@eikelenboom.it>
	<7914B38A4445B34AA16EB9F1352942F1012F0F6F4AE2@SJCPMAILBOX01.citrite.net>
	<723041396.20120901004249@eikelenboom.it>
	<7914B38A4445B34AA16EB9F1352942F1012F0F6F4B01@SJCPMAILBOX01.citrite.net>
	<1377403931.20120901011625@eikelenboom.it>
	<7914B38A4445B34AA16EB9F1352942F1012F0F6F4B5B@SJCPMAILBOX01.citrite.net>
In-Reply-To: <7914B38A4445B34AA16EB9F1352942F1012F0F6F4B5B@SJCPMAILBOX01.citrite.net>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "wei.wang2@amd.com" <wei.wang2@amd.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Using debug-key 'o:  Dump IOMMU p2m table,
 locks up machine
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.09.12 at 02:42, Santosh Jodh <Santosh.Jodh@citrix.com> wrote:
> BTW, I should add that 1:1 mapping for the VM seems very suspicious. Wei can 
> comment for sure.

For PV guests, that's very much expected, I would say.

Jan

>> -----Original Message-----
>> From: Santosh Jodh
>> Sent: Friday, August 31, 2012 4:58 PM
>> To: 'Sander Eikelenboom'
>> Cc: wei.wang2@amd.com; xen-devel@lists.xen.org 
>> Subject: RE: Using debug-key 'o: Dump IOMMU p2m table, locks up machine
>> 
>> 1:1 mapping is not the common case for gfn-mfn. It is hard to say how much
>> output would shrink by dumping contiguous ranges instead of individual pfns
>> in the general case.



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

From xen-devel-bounces@lists.xen.org Mon Sep 03 08:21:29 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Sep 2012 08: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 1T8RuC-0003K0-Hs; Mon, 03 Sep 2012 08:21:12 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1T8RuB-0003Jv-0d
	for xen-devel@lists.xen.org; Mon, 03 Sep 2012 08:21:11 +0000
Received: from [85.158.138.51:18083] by server-2.bemta-3.messagelabs.com id
	70/83-04862-67864405; Mon, 03 Sep 2012 08:21:10 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1346660469!20311696!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM3ODU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10897 invoked from network); 3 Sep 2012 08:21:09 -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;
	3 Sep 2012 08:21:09 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 03 Sep 2012 09:21:08 +0100
Message-Id: <5044849002000078000982EA@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 03 Sep 2012 09:21:04 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Sander Eikelenboom" <linux@eikelenboom.it>
References: <7914B38A4445B34AA16EB9F1352942F1012F0F6F4B98@SJCPMAILBOX01.citrite.net>
	<CC681CDD.3D966%keir.xen@gmail.com>
	<40501859.20120902104331@eikelenboom.it>
In-Reply-To: <40501859.20120902104331@eikelenboom.it>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "wei.wang2@amd.com" <wei.wang2@amd.com>, Keir Fraser <keir.xen@gmail.com>,
	Santosh Jodh <Santosh.Jodh@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Using debug-key 'o:  Dump IOMMU p2m table,
 locks up machine
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 02.09.12 at 10:43, Sander Eikelenboom <linux@eikelenboom.it> wrote:
> I have attached new output from xl dmesg, this time with iommu=debug on (the 
> option changed from 4.1 to 4.2).

This one

>(XEN) [2012-09-02 00:55:02] traps.c:3156: GPF (0060): ffff82c48015c9ee -> ffff82c480224b13

also worries me. While Xen gracefully recovers from it, these
messages still generally indicate a problem somewhere. Could
you resolve the addresses to file:line tuples? And, assuming
this happens in the context of doing something on behalf of
the guest in the context of a guest vCPU, could you also
check what guest side action triggers this (e.g. by adding a
call to show_execution_state() alongside the printing of the
message)?

Jan


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

From xen-devel-bounces@lists.xen.org Mon Sep 03 08:21:29 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Sep 2012 08: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 1T8RuC-0003K0-Hs; Mon, 03 Sep 2012 08:21:12 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1T8RuB-0003Jv-0d
	for xen-devel@lists.xen.org; Mon, 03 Sep 2012 08:21:11 +0000
Received: from [85.158.138.51:18083] by server-2.bemta-3.messagelabs.com id
	70/83-04862-67864405; Mon, 03 Sep 2012 08:21:10 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1346660469!20311696!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM3ODU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10897 invoked from network); 3 Sep 2012 08:21:09 -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;
	3 Sep 2012 08:21:09 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 03 Sep 2012 09:21:08 +0100
Message-Id: <5044849002000078000982EA@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 03 Sep 2012 09:21:04 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Sander Eikelenboom" <linux@eikelenboom.it>
References: <7914B38A4445B34AA16EB9F1352942F1012F0F6F4B98@SJCPMAILBOX01.citrite.net>
	<CC681CDD.3D966%keir.xen@gmail.com>
	<40501859.20120902104331@eikelenboom.it>
In-Reply-To: <40501859.20120902104331@eikelenboom.it>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "wei.wang2@amd.com" <wei.wang2@amd.com>, Keir Fraser <keir.xen@gmail.com>,
	Santosh Jodh <Santosh.Jodh@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Using debug-key 'o:  Dump IOMMU p2m table,
 locks up machine
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 02.09.12 at 10:43, Sander Eikelenboom <linux@eikelenboom.it> wrote:
> I have attached new output from xl dmesg, this time with iommu=debug on (the 
> option changed from 4.1 to 4.2).

This one

>(XEN) [2012-09-02 00:55:02] traps.c:3156: GPF (0060): ffff82c48015c9ee -> ffff82c480224b13

also worries me. While Xen gracefully recovers from it, these
messages still generally indicate a problem somewhere. Could
you resolve the addresses to file:line tuples? And, assuming
this happens in the context of doing something on behalf of
the guest in the context of a guest vCPU, could you also
check what guest side action triggers this (e.g. by adding a
call to show_execution_state() alongside the printing of the
message)?

Jan


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

From xen-devel-bounces@lists.xen.org Mon Sep 03 08:33:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Sep 2012 08: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 1T8S6F-0003UE-O3; Mon, 03 Sep 2012 08:33:39 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <linux@eikelenboom.it>) id 1T8S6D-0003U9-V5
	for xen-devel@lists.xen.org; Mon, 03 Sep 2012 08:33:38 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-14.tower-27.messagelabs.com!1346661208!2397617!1
X-Originating-IP: [188.40.164.121]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 890 invoked from network); 3 Sep 2012 08:33:29 -0000
Received: from static.121.164.40.188.clients.your-server.de (HELO
	smtp.eikelenboom.it) (188.40.164.121)
	by server-14.tower-27.messagelabs.com with AES256-SHA encrypted SMTP;
	3 Sep 2012 08:33:29 -0000
Received: from 26-69-ftth.onsneteindhoven.nl ([88.159.69.26]:53493
	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 1T8S2z-0001Dn-Rj; Mon, 03 Sep 2012 10:30:17 +0200
Date: Mon, 3 Sep 2012 10:33:25 +0200
From: Sander Eikelenboom <linux@eikelenboom.it>
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <1925247026.20120903103325@eikelenboom.it>
To: "Jan Beulich" <JBeulich@suse.com>
In-Reply-To: <5044849002000078000982EA@nat28.tlf.novell.com>
References: <7914B38A4445B34AA16EB9F1352942F1012F0F6F4B98@SJCPMAILBOX01.citrite.net>
	<CC681CDD.3D966%keir.xen@gmail.com>
	<40501859.20120902104331@eikelenboom.it>
	<5044849002000078000982EA@nat28.tlf.novell.com>
MIME-Version: 1.0
Cc: "wei.wang2@amd.com" <wei.wang2@amd.com>, Keir Fraser <keir.xen@gmail.com>,
	Santosh Jodh <Santosh.Jodh@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Using debug-key 'o:  Dump IOMMU p2m table,
	locks up machine
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 Jan,

Monday, September 3, 2012, 10:21:04 AM, you wrote:

>>>> On 02.09.12 at 10:43, Sander Eikelenboom <linux@eikelenboom.it> wrote:
>> I have attached new output from xl dmesg, this time with iommu=debug on (the 
>> option changed from 4.1 to 4.2).

> This one

>>(XEN) [2012-09-02 00:55:02] traps.c:3156: GPF (0060): ffff82c48015c9ee -> ffff82c480224b13

> also worries me. While Xen gracefully recovers from it, these
> messages still generally indicate a problem somewhere. Could
> you resolve the addresses to file:line tuples? And, assuming
> this happens in the context of doing something on behalf of
> the guest in the context of a guest vCPU, could you also
> check what guest side action triggers this (e.g. by adding a
> call to show_execution_state() alongside the printing of the
> message)?

If you could elaborate a bit abouw HOW :-)

>From what i recall i also had these since some time on xen 4.1 too. Probably a kernel thing, in about 3.5 or 3.6 is my estimation, will see if i can find out some more today or tomorrow.


> Jan




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

From xen-devel-bounces@lists.xen.org Mon Sep 03 08:33:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Sep 2012 08: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 1T8S6F-0003UE-O3; Mon, 03 Sep 2012 08:33:39 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <linux@eikelenboom.it>) id 1T8S6D-0003U9-V5
	for xen-devel@lists.xen.org; Mon, 03 Sep 2012 08:33:38 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-14.tower-27.messagelabs.com!1346661208!2397617!1
X-Originating-IP: [188.40.164.121]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 890 invoked from network); 3 Sep 2012 08:33:29 -0000
Received: from static.121.164.40.188.clients.your-server.de (HELO
	smtp.eikelenboom.it) (188.40.164.121)
	by server-14.tower-27.messagelabs.com with AES256-SHA encrypted SMTP;
	3 Sep 2012 08:33:29 -0000
Received: from 26-69-ftth.onsneteindhoven.nl ([88.159.69.26]:53493
	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 1T8S2z-0001Dn-Rj; Mon, 03 Sep 2012 10:30:17 +0200
Date: Mon, 3 Sep 2012 10:33:25 +0200
From: Sander Eikelenboom <linux@eikelenboom.it>
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <1925247026.20120903103325@eikelenboom.it>
To: "Jan Beulich" <JBeulich@suse.com>
In-Reply-To: <5044849002000078000982EA@nat28.tlf.novell.com>
References: <7914B38A4445B34AA16EB9F1352942F1012F0F6F4B98@SJCPMAILBOX01.citrite.net>
	<CC681CDD.3D966%keir.xen@gmail.com>
	<40501859.20120902104331@eikelenboom.it>
	<5044849002000078000982EA@nat28.tlf.novell.com>
MIME-Version: 1.0
Cc: "wei.wang2@amd.com" <wei.wang2@amd.com>, Keir Fraser <keir.xen@gmail.com>,
	Santosh Jodh <Santosh.Jodh@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Using debug-key 'o:  Dump IOMMU p2m table,
	locks up machine
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 Jan,

Monday, September 3, 2012, 10:21:04 AM, you wrote:

>>>> On 02.09.12 at 10:43, Sander Eikelenboom <linux@eikelenboom.it> wrote:
>> I have attached new output from xl dmesg, this time with iommu=debug on (the 
>> option changed from 4.1 to 4.2).

> This one

>>(XEN) [2012-09-02 00:55:02] traps.c:3156: GPF (0060): ffff82c48015c9ee -> ffff82c480224b13

> also worries me. While Xen gracefully recovers from it, these
> messages still generally indicate a problem somewhere. Could
> you resolve the addresses to file:line tuples? And, assuming
> this happens in the context of doing something on behalf of
> the guest in the context of a guest vCPU, could you also
> check what guest side action triggers this (e.g. by adding a
> call to show_execution_state() alongside the printing of the
> message)?

If you could elaborate a bit abouw HOW :-)

>From what i recall i also had these since some time on xen 4.1 too. Probably a kernel thing, in about 3.5 or 3.6 is my estimation, will see if i can find out some more today or tomorrow.


> Jan




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

From xen-devel-bounces@lists.xen.org Mon Sep 03 08:48:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Sep 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 1T8SJs-0003kO-9u; Mon, 03 Sep 2012 08:47: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 1T8SJq-0003kJ-TQ
	for xen-devel@lists.xen.org; Mon, 03 Sep 2012 08:47:43 +0000
Received: from [85.158.139.83:48004] by server-3.bemta-5.messagelabs.com id
	2B/BC-21836-DAE64405; Mon, 03 Sep 2012 08:47:41 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1346662061!16960377!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTE0ODk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5107 invoked from network); 3 Sep 2012 08:47:41 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Sep 2012 08:47:41 -0000
X-IronPort-AV: E=Sophos;i="4.80,359,1344211200"; d="scan'208";a="14311341"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Sep 2012 08:47: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.279.1; Mon, 3 Sep 2012
	09:47:40 +0100
Message-ID: <1346662056.27277.250.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Mon, 3 Sep 2012 09:47:36 +0100
In-Reply-To: <504470FD0200007800098213@nat28.tlf.novell.com>
References: <504470FD0200007800098213@nat28.tlf.novell.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] make domain_create() return a proper error
 code
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2012-09-03 at 07:57 +0100, Jan Beulich wrote:
> While triggered by the XSA-9 fix, this really is of more general use;
> that fix just pointed out very sharply that the current situation
> with all domain creation failures reported to user (tools) space as
> -ENOMEM is very unfortunate (actively misleading users _and_ support
> personnel).
> 
> Pull over the pointer <-> error code conversion infrastructure from
> Linux, and use it in domain_create() and all it callers.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> 
> --- a/xen/arch/arm/setup.c
> +++ b/xen/arch/arm/setup.c
> @@ -26,6 +26,7 @@
>  #include <xen/serial.h>
>  #include <xen/sched.h>
>  #include <xen/console.h>
> +#include <xen/err.h>
>  #include <xen/init.h>
>  #include <xen/irq.h>
>  #include <xen/mm.h>
> @@ -237,7 +238,7 @@ void __init start_xen(unsigned long boot
>  
>      /* Create initial domain 0. */
>      dom0 = domain_create(0, 0, 0);
> -    if ( dom0 == NULL )
> +    if ( IS_ERR(dom0) )
>              printk("domain_create failed\n");
>      if ( (dom0 == NULL) || (alloc_dom0_vcpu0() == NULL) )

You probably wanted to change this one too?

I'm not sure the first message really buys much -- I'd be happy to nuke
it too.

Ian.



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

From xen-devel-bounces@lists.xen.org Mon Sep 03 08:48:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Sep 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 1T8SJs-0003kO-9u; Mon, 03 Sep 2012 08:47: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 1T8SJq-0003kJ-TQ
	for xen-devel@lists.xen.org; Mon, 03 Sep 2012 08:47:43 +0000
Received: from [85.158.139.83:48004] by server-3.bemta-5.messagelabs.com id
	2B/BC-21836-DAE64405; Mon, 03 Sep 2012 08:47:41 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1346662061!16960377!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTE0ODk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5107 invoked from network); 3 Sep 2012 08:47:41 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Sep 2012 08:47:41 -0000
X-IronPort-AV: E=Sophos;i="4.80,359,1344211200"; d="scan'208";a="14311341"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Sep 2012 08:47: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.279.1; Mon, 3 Sep 2012
	09:47:40 +0100
Message-ID: <1346662056.27277.250.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Mon, 3 Sep 2012 09:47:36 +0100
In-Reply-To: <504470FD0200007800098213@nat28.tlf.novell.com>
References: <504470FD0200007800098213@nat28.tlf.novell.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] make domain_create() return a proper error
 code
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2012-09-03 at 07:57 +0100, Jan Beulich wrote:
> While triggered by the XSA-9 fix, this really is of more general use;
> that fix just pointed out very sharply that the current situation
> with all domain creation failures reported to user (tools) space as
> -ENOMEM is very unfortunate (actively misleading users _and_ support
> personnel).
> 
> Pull over the pointer <-> error code conversion infrastructure from
> Linux, and use it in domain_create() and all it callers.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> 
> --- a/xen/arch/arm/setup.c
> +++ b/xen/arch/arm/setup.c
> @@ -26,6 +26,7 @@
>  #include <xen/serial.h>
>  #include <xen/sched.h>
>  #include <xen/console.h>
> +#include <xen/err.h>
>  #include <xen/init.h>
>  #include <xen/irq.h>
>  #include <xen/mm.h>
> @@ -237,7 +238,7 @@ void __init start_xen(unsigned long boot
>  
>      /* Create initial domain 0. */
>      dom0 = domain_create(0, 0, 0);
> -    if ( dom0 == NULL )
> +    if ( IS_ERR(dom0) )
>              printk("domain_create failed\n");
>      if ( (dom0 == NULL) || (alloc_dom0_vcpu0() == NULL) )

You probably wanted to change this one too?

I'm not sure the first message really buys much -- I'd be happy to nuke
it too.

Ian.



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

From xen-devel-bounces@lists.xen.org Mon Sep 03 08:59:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Sep 2012 08:59:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T8SUW-00048P-3L; Mon, 03 Sep 2012 08:58:44 +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 1T8SUV-00048K-HA
	for xen-devel@lists.xen.org; Mon, 03 Sep 2012 08:58:43 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1346662710!9178698!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNjgxNjM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21477 invoked from network); 3 Sep 2012 08:58:33 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Sep 2012 08:58:33 -0000
X-IronPort-AV: E=Sophos;i="4.80,359,1344211200"; d="scan'208";a="36592409"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Sep 2012 08:58:19 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Mon, 3 Sep 2012 04:58:18 -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 1T8SU6-0003kh-G3;
	Mon, 03 Sep 2012 09:58:18 +0100
MIME-Version: 1.0
X-Mercurial-Node: 241186e96a1ece42ad3bd14901b62d872f4abd9e
Message-ID: <241186e96a1ece42ad3b.1346662698@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Mon, 3 Sep 2012 09:58:18 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Cc: Andrew Cooper <Andrew.Cooper3@citrix.com>, Matt Wilson <msw@amazon.com>
Subject: [Xen-devel] [PATCH] docs: remove WIP notive from command line docs
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 1346662653 -3600
# Node ID 241186e96a1ece42ad3bd14901b62d872f4abd9e
# Parent  931134b81005ced9f3dc4080fbf66597da6aeb0e
docs: remove WIP notive from command line docs.

I'm sure they aren't perfect but various people have done a pass over
them recently and they are much improved. I don't think we need to
continue to describe them so pessimistically.

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

diff -r 931134b81005 -r 241186e96a1e docs/misc/xen-command-line.markdown
--- a/docs/misc/xen-command-line.markdown	Mon Sep 03 09:55:37 2012 +0100
+++ b/docs/misc/xen-command-line.markdown	Mon Sep 03 09:57:33 2012 +0100
@@ -1,10 +1,5 @@
 # Xen Hypervisor Command Line Options
 
-**This document is still a work in progress.  There are currently some
-  command line options listed twice, and they are defined in separate
-  arch trees, and some options are currently separate from their
-  legacy versions.  Please remove this notice when complete.**
-
 This document covers the command line options which the Xen
 Hypervisor.
 

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

From xen-devel-bounces@lists.xen.org Mon Sep 03 08:59:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Sep 2012 08:59:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T8SUW-00048P-3L; Mon, 03 Sep 2012 08:58:44 +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 1T8SUV-00048K-HA
	for xen-devel@lists.xen.org; Mon, 03 Sep 2012 08:58:43 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1346662710!9178698!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNjgxNjM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21477 invoked from network); 3 Sep 2012 08:58:33 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Sep 2012 08:58:33 -0000
X-IronPort-AV: E=Sophos;i="4.80,359,1344211200"; d="scan'208";a="36592409"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Sep 2012 08:58:19 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Mon, 3 Sep 2012 04:58:18 -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 1T8SU6-0003kh-G3;
	Mon, 03 Sep 2012 09:58:18 +0100
MIME-Version: 1.0
X-Mercurial-Node: 241186e96a1ece42ad3bd14901b62d872f4abd9e
Message-ID: <241186e96a1ece42ad3b.1346662698@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Mon, 3 Sep 2012 09:58:18 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Cc: Andrew Cooper <Andrew.Cooper3@citrix.com>, Matt Wilson <msw@amazon.com>
Subject: [Xen-devel] [PATCH] docs: remove WIP notive from command line docs
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 1346662653 -3600
# Node ID 241186e96a1ece42ad3bd14901b62d872f4abd9e
# Parent  931134b81005ced9f3dc4080fbf66597da6aeb0e
docs: remove WIP notive from command line docs.

I'm sure they aren't perfect but various people have done a pass over
them recently and they are much improved. I don't think we need to
continue to describe them so pessimistically.

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

diff -r 931134b81005 -r 241186e96a1e docs/misc/xen-command-line.markdown
--- a/docs/misc/xen-command-line.markdown	Mon Sep 03 09:55:37 2012 +0100
+++ b/docs/misc/xen-command-line.markdown	Mon Sep 03 09:57:33 2012 +0100
@@ -1,10 +1,5 @@
 # Xen Hypervisor Command Line Options
 
-**This document is still a work in progress.  There are currently some
-  command line options listed twice, and they are defined in separate
-  arch trees, and some options are currently separate from their
-  legacy versions.  Please remove this notice when complete.**
-
 This document covers the command line options which the Xen
 Hypervisor.
 

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

From xen-devel-bounces@lists.xen.org Mon Sep 03 08:59:10 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Sep 2012 08: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 1T8SUj-000495-Fn; Mon, 03 Sep 2012 08:58:57 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1T8SUi-000490-G6
	for xen-devel@lists.xen.org; Mon, 03 Sep 2012 08:58:56 +0000
Received: from [85.158.139.83:41444] by server-11.bemta-5.messagelabs.com id
	7C/85-24658-F4174405; Mon, 03 Sep 2012 08:58:55 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1346662733!21008958!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM3ODU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24773 invoked from network); 3 Sep 2012 08:58:54 -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;
	3 Sep 2012 08:58:54 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 03 Sep 2012 09:58:53 +0100
Message-Id: <50448D6A020000780009831B@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 03 Sep 2012 09:58:50 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Campbell" <Ian.Campbell@citrix.com>
References: <504470FD0200007800098213@nat28.tlf.novell.com>
	<1346662056.27277.250.camel@zakaz.uk.xensource.com>
In-Reply-To: <1346662056.27277.250.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] make domain_create() return a proper error
 code
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 03.09.12 at 10:47, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> On Mon, 2012-09-03 at 07:57 +0100, Jan Beulich wrote:
>> While triggered by the XSA-9 fix, this really is of more general use;
>> that fix just pointed out very sharply that the current situation
>> with all domain creation failures reported to user (tools) space as
>> -ENOMEM is very unfortunate (actively misleading users _and_ support
>> personnel).
>> 
>> Pull over the pointer <-> error code conversion infrastructure from
>> Linux, and use it in domain_create() and all it callers.
>> 
>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
>> 
>> --- a/xen/arch/arm/setup.c
>> +++ b/xen/arch/arm/setup.c
>> @@ -26,6 +26,7 @@
>>  #include <xen/serial.h>
>>  #include <xen/sched.h>
>>  #include <xen/console.h>
>> +#include <xen/err.h>
>>  #include <xen/init.h>
>>  #include <xen/irq.h>
>>  #include <xen/mm.h>
>> @@ -237,7 +238,7 @@ void __init start_xen(unsigned long boot
>>  
>>      /* Create initial domain 0. */
>>      dom0 = domain_create(0, 0, 0);
>> -    if ( dom0 == NULL )
>> +    if ( IS_ERR(dom0) )
>>              printk("domain_create failed\n");
>>      if ( (dom0 == NULL) || (alloc_dom0_vcpu0() == NULL) )
> 
> You probably wanted to change this one too?

Oh, indeed. I blindly implied the printk() there would be a
panic() already.

> I'm not sure the first message really buys much -- I'd be happy to nuke
> it too.

Yes, I would be in favor of that. Will you do the adjustment,
or shall I submit an incremental 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 Sep 03 08:59:10 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Sep 2012 08: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 1T8SUj-000495-Fn; Mon, 03 Sep 2012 08:58:57 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1T8SUi-000490-G6
	for xen-devel@lists.xen.org; Mon, 03 Sep 2012 08:58:56 +0000
Received: from [85.158.139.83:41444] by server-11.bemta-5.messagelabs.com id
	7C/85-24658-F4174405; Mon, 03 Sep 2012 08:58:55 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1346662733!21008958!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM3ODU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24773 invoked from network); 3 Sep 2012 08:58:54 -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;
	3 Sep 2012 08:58:54 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 03 Sep 2012 09:58:53 +0100
Message-Id: <50448D6A020000780009831B@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 03 Sep 2012 09:58:50 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Campbell" <Ian.Campbell@citrix.com>
References: <504470FD0200007800098213@nat28.tlf.novell.com>
	<1346662056.27277.250.camel@zakaz.uk.xensource.com>
In-Reply-To: <1346662056.27277.250.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] make domain_create() return a proper error
 code
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 03.09.12 at 10:47, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> On Mon, 2012-09-03 at 07:57 +0100, Jan Beulich wrote:
>> While triggered by the XSA-9 fix, this really is of more general use;
>> that fix just pointed out very sharply that the current situation
>> with all domain creation failures reported to user (tools) space as
>> -ENOMEM is very unfortunate (actively misleading users _and_ support
>> personnel).
>> 
>> Pull over the pointer <-> error code conversion infrastructure from
>> Linux, and use it in domain_create() and all it callers.
>> 
>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
>> 
>> --- a/xen/arch/arm/setup.c
>> +++ b/xen/arch/arm/setup.c
>> @@ -26,6 +26,7 @@
>>  #include <xen/serial.h>
>>  #include <xen/sched.h>
>>  #include <xen/console.h>
>> +#include <xen/err.h>
>>  #include <xen/init.h>
>>  #include <xen/irq.h>
>>  #include <xen/mm.h>
>> @@ -237,7 +238,7 @@ void __init start_xen(unsigned long boot
>>  
>>      /* Create initial domain 0. */
>>      dom0 = domain_create(0, 0, 0);
>> -    if ( dom0 == NULL )
>> +    if ( IS_ERR(dom0) )
>>              printk("domain_create failed\n");
>>      if ( (dom0 == NULL) || (alloc_dom0_vcpu0() == NULL) )
> 
> You probably wanted to change this one too?

Oh, indeed. I blindly implied the printk() there would be a
panic() already.

> I'm not sure the first message really buys much -- I'd be happy to nuke
> it too.

Yes, I would be in favor of that. Will you do the adjustment,
or shall I submit an incremental 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 Sep 03 09:00:29 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Sep 2012 09:00:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T8SVy-0004Kr-75; Mon, 03 Sep 2012 09:00: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 1T8SVw-0004Kc-Js
	for xen-devel@lists.xen.org; Mon, 03 Sep 2012 09:00:12 +0000
Received: from [85.158.139.83:54843] by server-2.bemta-5.messagelabs.com id
	5D/27-11456-B9174405; Mon, 03 Sep 2012 09:00:11 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1346662811!28018781!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTEzODI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19654 invoked from network); 3 Sep 2012 09:00:11 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Sep 2012 09:00:11 -0000
X-IronPort-AV: E=Sophos;i="4.80,359,1344211200"; d="scan'208";a="14311631"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Sep 2012 09:00: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.279.1; Mon, 3 Sep 2012
	10:00:10 +0100
Message-ID: <1346662807.27277.251.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Mon, 3 Sep 2012 10:00:07 +0100
In-Reply-To: <1346662056.27277.250.camel@zakaz.uk.xensource.com>
References: <504470FD0200007800098213@nat28.tlf.novell.com>
	<1346662056.27277.250.camel@zakaz.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] make domain_create() return a proper error
 code
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> > @@ -237,7 +238,7 @@ void __init start_xen(unsigned long boot
> >  
> >      /* Create initial domain 0. */
> >      dom0 = domain_create(0, 0, 0);
> > -    if ( dom0 == NULL )
> > +    if ( IS_ERR(dom0) )
> >              printk("domain_create failed\n");
> >      if ( (dom0 == NULL) || (alloc_dom0_vcpu0() == NULL) )
> 
> You probably wanted to change this one too?
> 
> I'm not sure the first message really buys much -- I'd be happy to nuke
> it too.

8<------------------------

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1346662775 -3600
# Node ID c4e822e1b491bb7efa962b38fff6f007f01596b5
# Parent  241186e96a1ece42ad3bd14901b62d872f4abd9e
arm: correctly check for error on dom0 allocation

Drop the redundant printk

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

diff -r 241186e96a1e -r c4e822e1b491 xen/arch/arm/setup.c
--- a/xen/arch/arm/setup.c	Mon Sep 03 09:57:33 2012 +0100
+++ b/xen/arch/arm/setup.c	Mon Sep 03 09:59:35 2012 +0100
@@ -238,9 +238,7 @@ void __init start_xen(unsigned long boot
 
     /* Create initial domain 0. */
     dom0 = domain_create(0, 0, 0);
-    if ( IS_ERR(dom0) )
-            printk("domain_create failed\n");
-    if ( (dom0 == NULL) || (alloc_dom0_vcpu0() == NULL) )
+    if ( IS_ERR(dom0) || (alloc_dom0_vcpu0() == NULL) )
             panic("Error creating domain 0\n");
 
     dom0->is_privileged = 1;



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

From xen-devel-bounces@lists.xen.org Mon Sep 03 09:00:29 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Sep 2012 09:00:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T8SVy-0004Kr-75; Mon, 03 Sep 2012 09:00: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 1T8SVw-0004Kc-Js
	for xen-devel@lists.xen.org; Mon, 03 Sep 2012 09:00:12 +0000
Received: from [85.158.139.83:54843] by server-2.bemta-5.messagelabs.com id
	5D/27-11456-B9174405; Mon, 03 Sep 2012 09:00:11 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1346662811!28018781!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTEzODI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19654 invoked from network); 3 Sep 2012 09:00:11 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Sep 2012 09:00:11 -0000
X-IronPort-AV: E=Sophos;i="4.80,359,1344211200"; d="scan'208";a="14311631"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Sep 2012 09:00: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.279.1; Mon, 3 Sep 2012
	10:00:10 +0100
Message-ID: <1346662807.27277.251.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Mon, 3 Sep 2012 10:00:07 +0100
In-Reply-To: <1346662056.27277.250.camel@zakaz.uk.xensource.com>
References: <504470FD0200007800098213@nat28.tlf.novell.com>
	<1346662056.27277.250.camel@zakaz.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] make domain_create() return a proper error
 code
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> > @@ -237,7 +238,7 @@ void __init start_xen(unsigned long boot
> >  
> >      /* Create initial domain 0. */
> >      dom0 = domain_create(0, 0, 0);
> > -    if ( dom0 == NULL )
> > +    if ( IS_ERR(dom0) )
> >              printk("domain_create failed\n");
> >      if ( (dom0 == NULL) || (alloc_dom0_vcpu0() == NULL) )
> 
> You probably wanted to change this one too?
> 
> I'm not sure the first message really buys much -- I'd be happy to nuke
> it too.

8<------------------------

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1346662775 -3600
# Node ID c4e822e1b491bb7efa962b38fff6f007f01596b5
# Parent  241186e96a1ece42ad3bd14901b62d872f4abd9e
arm: correctly check for error on dom0 allocation

Drop the redundant printk

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

diff -r 241186e96a1e -r c4e822e1b491 xen/arch/arm/setup.c
--- a/xen/arch/arm/setup.c	Mon Sep 03 09:57:33 2012 +0100
+++ b/xen/arch/arm/setup.c	Mon Sep 03 09:59:35 2012 +0100
@@ -238,9 +238,7 @@ void __init start_xen(unsigned long boot
 
     /* Create initial domain 0. */
     dom0 = domain_create(0, 0, 0);
-    if ( IS_ERR(dom0) )
-            printk("domain_create failed\n");
-    if ( (dom0 == NULL) || (alloc_dom0_vcpu0() == NULL) )
+    if ( IS_ERR(dom0) || (alloc_dom0_vcpu0() == NULL) )
             panic("Error creating domain 0\n");
 
     dom0->is_privileged = 1;



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

From xen-devel-bounces@lists.xen.org Mon Sep 03 09:06:35 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Sep 2012 09: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 1T8Sbw-0004ix-0i; Mon, 03 Sep 2012 09:06:24 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1T8Sbv-0004ip-68
	for xen-devel@lists.xen.org; Mon, 03 Sep 2012 09:06:23 +0000
Received: from [85.158.139.83:13723] by server-6.bemta-5.messagelabs.com id
	D9/B9-21336-C0374405; Mon, 03 Sep 2012 09:06:20 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1346663176!27696676!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTEzODI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23520 invoked from network); 3 Sep 2012 09:06:17 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Sep 2012 09:06:17 -0000
X-IronPort-AV: E=Sophos;i="4.80,359,1344211200"; d="scan'208";a="14311794"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Sep 2012 09:06: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.279.1; Mon, 3 Sep 2012
	10:06:16 +0100
Message-ID: <1346663174.27277.252.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Mon, 3 Sep 2012 10:06:14 +0100
In-Reply-To: <50448D6A020000780009831B@nat28.tlf.novell.com>
References: <504470FD0200007800098213@nat28.tlf.novell.com>
	<1346662056.27277.250.camel@zakaz.uk.xensource.com>
	<50448D6A020000780009831B@nat28.tlf.novell.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] make domain_create() return a proper error
 code
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2012-09-03 at 09:58 +0100, Jan Beulich wrote:
> >>> On 03.09.12 at 10:47, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> > On Mon, 2012-09-03 at 07:57 +0100, Jan Beulich wrote:
> >> While triggered by the XSA-9 fix, this really is of more general use;
> >> that fix just pointed out very sharply that the current situation
> >> with all domain creation failures reported to user (tools) space as
> >> -ENOMEM is very unfortunate (actively misleading users _and_ support
> >> personnel).
> >> 
> >> Pull over the pointer <-> error code conversion infrastructure from
> >> Linux, and use it in domain_create() and all it callers.
> >> 
> >> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> >> 
> >> --- a/xen/arch/arm/setup.c
> >> +++ b/xen/arch/arm/setup.c
> >> @@ -26,6 +26,7 @@
> >>  #include <xen/serial.h>
> >>  #include <xen/sched.h>
> >>  #include <xen/console.h>
> >> +#include <xen/err.h>
> >>  #include <xen/init.h>
> >>  #include <xen/irq.h>
> >>  #include <xen/mm.h>
> >> @@ -237,7 +238,7 @@ void __init start_xen(unsigned long boot
> >>  
> >>      /* Create initial domain 0. */
> >>      dom0 = domain_create(0, 0, 0);
> >> -    if ( dom0 == NULL )
> >> +    if ( IS_ERR(dom0) )
> >>              printk("domain_create failed\n");
> >>      if ( (dom0 == NULL) || (alloc_dom0_vcpu0() == NULL) )
> > 
> > You probably wanted to change this one too?
> 
> Oh, indeed. I blindly implied the printk() there would be a
> panic() already.
> 
> > I'm not sure the first message really buys much -- I'd be happy to nuke
> > it too.
> 
> Yes, I would be in favor of that. Will you do the adjustment,
> or shall I submit an incremental patch?

I've posted a patch, I think it and your mail probably crossed in the
air...



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

From xen-devel-bounces@lists.xen.org Mon Sep 03 09:06:35 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Sep 2012 09: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 1T8Sbw-0004ix-0i; Mon, 03 Sep 2012 09:06:24 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1T8Sbv-0004ip-68
	for xen-devel@lists.xen.org; Mon, 03 Sep 2012 09:06:23 +0000
Received: from [85.158.139.83:13723] by server-6.bemta-5.messagelabs.com id
	D9/B9-21336-C0374405; Mon, 03 Sep 2012 09:06:20 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1346663176!27696676!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTEzODI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23520 invoked from network); 3 Sep 2012 09:06:17 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Sep 2012 09:06:17 -0000
X-IronPort-AV: E=Sophos;i="4.80,359,1344211200"; d="scan'208";a="14311794"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Sep 2012 09:06: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.279.1; Mon, 3 Sep 2012
	10:06:16 +0100
Message-ID: <1346663174.27277.252.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Mon, 3 Sep 2012 10:06:14 +0100
In-Reply-To: <50448D6A020000780009831B@nat28.tlf.novell.com>
References: <504470FD0200007800098213@nat28.tlf.novell.com>
	<1346662056.27277.250.camel@zakaz.uk.xensource.com>
	<50448D6A020000780009831B@nat28.tlf.novell.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] make domain_create() return a proper error
 code
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2012-09-03 at 09:58 +0100, Jan Beulich wrote:
> >>> On 03.09.12 at 10:47, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> > On Mon, 2012-09-03 at 07:57 +0100, Jan Beulich wrote:
> >> While triggered by the XSA-9 fix, this really is of more general use;
> >> that fix just pointed out very sharply that the current situation
> >> with all domain creation failures reported to user (tools) space as
> >> -ENOMEM is very unfortunate (actively misleading users _and_ support
> >> personnel).
> >> 
> >> Pull over the pointer <-> error code conversion infrastructure from
> >> Linux, and use it in domain_create() and all it callers.
> >> 
> >> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> >> 
> >> --- a/xen/arch/arm/setup.c
> >> +++ b/xen/arch/arm/setup.c
> >> @@ -26,6 +26,7 @@
> >>  #include <xen/serial.h>
> >>  #include <xen/sched.h>
> >>  #include <xen/console.h>
> >> +#include <xen/err.h>
> >>  #include <xen/init.h>
> >>  #include <xen/irq.h>
> >>  #include <xen/mm.h>
> >> @@ -237,7 +238,7 @@ void __init start_xen(unsigned long boot
> >>  
> >>      /* Create initial domain 0. */
> >>      dom0 = domain_create(0, 0, 0);
> >> -    if ( dom0 == NULL )
> >> +    if ( IS_ERR(dom0) )
> >>              printk("domain_create failed\n");
> >>      if ( (dom0 == NULL) || (alloc_dom0_vcpu0() == NULL) )
> > 
> > You probably wanted to change this one too?
> 
> Oh, indeed. I blindly implied the printk() there would be a
> panic() already.
> 
> > I'm not sure the first message really buys much -- I'd be happy to nuke
> > it too.
> 
> Yes, I would be in favor of that. Will you do the adjustment,
> or shall I submit an incremental patch?

I've posted a patch, I think it and your mail probably crossed in the
air...



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

From xen-devel-bounces@lists.xen.org Mon Sep 03 09:08:22 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Sep 2012 09:08: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 1T8Sdd-0004nQ-GO; Mon, 03 Sep 2012 09:08:09 +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 1T8Sdb-0004n7-RO
	for xen-devel@lists.xen.org; Mon, 03 Sep 2012 09:08:08 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1346663117!9180137!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM3ODU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24644 invoked from network); 3 Sep 2012 09:05:17 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-13.tower-27.messagelabs.com with SMTP;
	3 Sep 2012 09:05:17 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 03 Sep 2012 10:05:16 +0100
Message-Id: <50448EE80200007800098342@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 03 Sep 2012 10:05:12 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Sander Eikelenboom" <linux@eikelenboom.it>
References: <7914B38A4445B34AA16EB9F1352942F1012F0F6F4B98@SJCPMAILBOX01.citrite.net>
	<CC681CDD.3D966%keir.xen@gmail.com>
	<40501859.20120902104331@eikelenboom.it>
	<5044849002000078000982EA@nat28.tlf.novell.com>
	<1925247026.20120903103325@eikelenboom.it>
In-Reply-To: <1925247026.20120903103325@eikelenboom.it>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "wei.wang2@amd.com" <wei.wang2@amd.com>, Keir Fraser <keir.xen@gmail.com>,
	Santosh Jodh <Santosh.Jodh@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Using debug-key 'o:  Dump IOMMU p2m table,
 locks up machine
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 03.09.12 at 10:33, Sander Eikelenboom <linux@eikelenboom.it> wrote:
> Monday, September 3, 2012, 10:21:04 AM, you wrote:
>> This one
> 
>>>(XEN) [2012-09-02 00:55:02] traps.c:3156: GPF (0060): ffff82c48015c9ee -> 
> ffff82c480224b13
> 
>> also worries me. While Xen gracefully recovers from it, these
>> messages still generally indicate a problem somewhere. Could
>> you resolve the addresses to file:line tuples? And, assuming
>> this happens in the context of doing something on behalf of
>> the guest in the context of a guest vCPU, could you also
>> check what guest side action triggers this (e.g. by adding a
>> call to show_execution_state() alongside the printing of the
>> message)?
> 
> If you could elaborate a bit abouw HOW :-)

I assume this refers to the first question above only (as I
assume adding the indicated function call at the right place
wouldn't be a big deal for you)?

I think people generally use addr2line for this; I normally simply
disassemble xen-syms, and then do a manual lookup (so if you
have the very xen-syms still around, just making that one
accessible would also do), as in many cases (having full
register/stack dumps at hand) understanding which variables/
expressions register values correspond to would make this
necessary anyway.

> From what i recall i also had these since some time on xen 4.1 too. Probably 
> a kernel thing, in about 3.5 or 3.6 is my estimation, will see if i can find 
> out some more today or tomorrow.

Thanks, Jan


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

From xen-devel-bounces@lists.xen.org Mon Sep 03 09:08:22 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Sep 2012 09:08: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 1T8Sdd-0004nQ-GO; Mon, 03 Sep 2012 09:08:09 +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 1T8Sdb-0004n7-RO
	for xen-devel@lists.xen.org; Mon, 03 Sep 2012 09:08:08 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1346663117!9180137!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM3ODU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24644 invoked from network); 3 Sep 2012 09:05:17 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-13.tower-27.messagelabs.com with SMTP;
	3 Sep 2012 09:05:17 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 03 Sep 2012 10:05:16 +0100
Message-Id: <50448EE80200007800098342@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 03 Sep 2012 10:05:12 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Sander Eikelenboom" <linux@eikelenboom.it>
References: <7914B38A4445B34AA16EB9F1352942F1012F0F6F4B98@SJCPMAILBOX01.citrite.net>
	<CC681CDD.3D966%keir.xen@gmail.com>
	<40501859.20120902104331@eikelenboom.it>
	<5044849002000078000982EA@nat28.tlf.novell.com>
	<1925247026.20120903103325@eikelenboom.it>
In-Reply-To: <1925247026.20120903103325@eikelenboom.it>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "wei.wang2@amd.com" <wei.wang2@amd.com>, Keir Fraser <keir.xen@gmail.com>,
	Santosh Jodh <Santosh.Jodh@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Using debug-key 'o:  Dump IOMMU p2m table,
 locks up machine
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 03.09.12 at 10:33, Sander Eikelenboom <linux@eikelenboom.it> wrote:
> Monday, September 3, 2012, 10:21:04 AM, you wrote:
>> This one
> 
>>>(XEN) [2012-09-02 00:55:02] traps.c:3156: GPF (0060): ffff82c48015c9ee -> 
> ffff82c480224b13
> 
>> also worries me. While Xen gracefully recovers from it, these
>> messages still generally indicate a problem somewhere. Could
>> you resolve the addresses to file:line tuples? And, assuming
>> this happens in the context of doing something on behalf of
>> the guest in the context of a guest vCPU, could you also
>> check what guest side action triggers this (e.g. by adding a
>> call to show_execution_state() alongside the printing of the
>> message)?
> 
> If you could elaborate a bit abouw HOW :-)

I assume this refers to the first question above only (as I
assume adding the indicated function call at the right place
wouldn't be a big deal for you)?

I think people generally use addr2line for this; I normally simply
disassemble xen-syms, and then do a manual lookup (so if you
have the very xen-syms still around, just making that one
accessible would also do), as in many cases (having full
register/stack dumps at hand) understanding which variables/
expressions register values correspond to would make this
necessary anyway.

> From what i recall i also had these since some time on xen 4.1 too. Probably 
> a kernel thing, in about 3.5 or 3.6 is my estimation, will see if i can find 
> out some more today or tomorrow.

Thanks, Jan


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

From xen-devel-bounces@lists.xen.org Mon Sep 03 09:09:30 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Sep 2012 09:09:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T8Sek-0004tY-VR; Mon, 03 Sep 2012 09:09: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 1T8Sej-0004tE-2g
	for xen-devel@lists.xen.org; Mon, 03 Sep 2012 09:09:17 +0000
Received: from [85.158.143.35:54592] by server-3.bemta-4.messagelabs.com id
	29/95-08232-CB374405; Mon, 03 Sep 2012 09:09:16 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1346663349!11963754!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTE0ODk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24455 invoked from network); 3 Sep 2012 09:09:09 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Sep 2012 09:09:09 -0000
X-IronPort-AV: E=Sophos;i="4.80,359,1344211200"; d="scan'208";a="14311907"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Sep 2012 09:09: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.279.1; Mon, 3 Sep 2012
	10:09:09 +0100
Message-ID: <1346663347.27277.253.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: Mon, 3 Sep 2012 10:09:07 +0100
In-Reply-To: <20120902044626.GE8912@reaktio.net>
References: <1346148361.9975.3.camel@zakaz.uk.xensource.com>
	<20120902044626.GE8912@reaktio.net>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: xen-users <xen-users@lists.xen.org>, xen-devel <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="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gU3VuLCAyMDEyLTA5LTAyIGF0IDA1OjQ2ICswMTAwLCBQYXNpIEvDpHJra8OkaW5lbiB3cm90
ZToKPiBPbiBUdWUsIEF1ZyAyOCwgMjAxMiBhdCAxMTowNjowMUFNICswMTAwLCBJYW4gQ2FtcGJl
bGwgd3JvdGU6Cj4gPiAKPiA+ICAgICAqIHhsLmNmZyg1KSBkb2N1bWVudGF0aW9uIHBhdGNoIGZv
ciBxZW11LXVwc3RyZWFtCj4gPiAgICAgICB2aWRlb3JhbS92aWRlb21lbSBzdXBwb3J0Ogo+ID4g
ICAgICAgaHR0cDovL2xpc3RzLnhlbi5vcmcvYXJjaGl2ZXMvaHRtbC94ZW4tZGV2ZWwvMjAxMi0w
NS9tc2cwMDI1MC5odG1sCj4gPiAgICAgICBxZW11LXVwc3RyZWFtIGRvZXNuJ3Qgc3VwcG9ydCBz
cGVjaWZ5aW5nIHZpZGVvbWVtIHNpemUgZm9yIHRoZQo+ID4gICAgICAgSFZNIGd1ZXN0IGNpcnJ1
cy9zdGR2Z2EuICAoYnV0IHRoaXMgd29ya3Mgd2l0aAo+ID4gICAgICAgcWVtdS14ZW4tdHJhZGl0
aW9uYWwpLiAoUGFzaSBLw6Rya2vDpGluZW4pCj4gPiAKPiAKPiBQYXRjaCBzZW50IHRvIHRoZSBs
aXN0LgoKVGhhbmtzIQoKCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fXwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW4ub3JnCmh0
dHA6Ly9saXN0cy54ZW4ub3JnL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xen.org Mon Sep 03 09:09:30 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Sep 2012 09:09:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T8Sek-0004tY-VR; Mon, 03 Sep 2012 09:09: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 1T8Sej-0004tE-2g
	for xen-devel@lists.xen.org; Mon, 03 Sep 2012 09:09:17 +0000
Received: from [85.158.143.35:54592] by server-3.bemta-4.messagelabs.com id
	29/95-08232-CB374405; Mon, 03 Sep 2012 09:09:16 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1346663349!11963754!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTE0ODk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24455 invoked from network); 3 Sep 2012 09:09:09 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Sep 2012 09:09:09 -0000
X-IronPort-AV: E=Sophos;i="4.80,359,1344211200"; d="scan'208";a="14311907"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Sep 2012 09:09: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.279.1; Mon, 3 Sep 2012
	10:09:09 +0100
Message-ID: <1346663347.27277.253.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: Mon, 3 Sep 2012 10:09:07 +0100
In-Reply-To: <20120902044626.GE8912@reaktio.net>
References: <1346148361.9975.3.camel@zakaz.uk.xensource.com>
	<20120902044626.GE8912@reaktio.net>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: xen-users <xen-users@lists.xen.org>, xen-devel <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="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gU3VuLCAyMDEyLTA5LTAyIGF0IDA1OjQ2ICswMTAwLCBQYXNpIEvDpHJra8OkaW5lbiB3cm90
ZToKPiBPbiBUdWUsIEF1ZyAyOCwgMjAxMiBhdCAxMTowNjowMUFNICswMTAwLCBJYW4gQ2FtcGJl
bGwgd3JvdGU6Cj4gPiAKPiA+ICAgICAqIHhsLmNmZyg1KSBkb2N1bWVudGF0aW9uIHBhdGNoIGZv
ciBxZW11LXVwc3RyZWFtCj4gPiAgICAgICB2aWRlb3JhbS92aWRlb21lbSBzdXBwb3J0Ogo+ID4g
ICAgICAgaHR0cDovL2xpc3RzLnhlbi5vcmcvYXJjaGl2ZXMvaHRtbC94ZW4tZGV2ZWwvMjAxMi0w
NS9tc2cwMDI1MC5odG1sCj4gPiAgICAgICBxZW11LXVwc3RyZWFtIGRvZXNuJ3Qgc3VwcG9ydCBz
cGVjaWZ5aW5nIHZpZGVvbWVtIHNpemUgZm9yIHRoZQo+ID4gICAgICAgSFZNIGd1ZXN0IGNpcnJ1
cy9zdGR2Z2EuICAoYnV0IHRoaXMgd29ya3Mgd2l0aAo+ID4gICAgICAgcWVtdS14ZW4tdHJhZGl0
aW9uYWwpLiAoUGFzaSBLw6Rya2vDpGluZW4pCj4gPiAKPiAKPiBQYXRjaCBzZW50IHRvIHRoZSBs
aXN0LgoKVGhhbmtzIQoKCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fXwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW4ub3JnCmh0
dHA6Ly9saXN0cy54ZW4ub3JnL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xen.org Mon Sep 03 09:10:53 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Sep 2012 09:10:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T8Sg7-00055f-3m; Mon, 03 Sep 2012 09:10:43 +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 1T8Sg5-00054x-Sz
	for xen-devel@lists.xen.org; Mon, 03 Sep 2012 09:10:42 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1346663273!4123890!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM3ODk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32473 invoked from network); 3 Sep 2012 09:07:53 -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;
	3 Sep 2012 09:07:53 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 03 Sep 2012 10:07:53 +0100
Message-Id: <50448F850200007800098356@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 03 Sep 2012 10:07:49 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Campbell" <Ian.Campbell@citrix.com>
References: <504470FD0200007800098213@nat28.tlf.novell.com>
	<1346662056.27277.250.camel@zakaz.uk.xensource.com>
	<1346662807.27277.251.camel@zakaz.uk.xensource.com>
In-Reply-To: <1346662807.27277.251.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] make domain_create() return a proper error
 code
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 03.09.12 at 11:00, Ian Campbell <Ian.Campbell@citrix.com> wrote:
>> > @@ -237,7 +238,7 @@ void __init start_xen(unsigned long boot
>> >  
>> >      /* Create initial domain 0. */
>> >      dom0 = domain_create(0, 0, 0);
>> > -    if ( dom0 == NULL )
>> > +    if ( IS_ERR(dom0) )
>> >              printk("domain_create failed\n");
>> >      if ( (dom0 == NULL) || (alloc_dom0_vcpu0() == NULL) )
>> 
>> You probably wanted to change this one too?
>> 
>> I'm not sure the first message really buys much -- I'd be happy to nuke
>> it too.
> 
> 8<------------------------
> 
> # HG changeset patch
> # User Ian Campbell <ian.campbell@citrix.com>
> # Date 1346662775 -3600
> # Node ID c4e822e1b491bb7efa962b38fff6f007f01596b5
> # Parent  241186e96a1ece42ad3bd14901b62d872f4abd9e
> arm: correctly check for error on dom0 allocation
> 
> Drop the redundant printk
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

Thanks and (if you care) ack.

Jan

> diff -r 241186e96a1e -r c4e822e1b491 xen/arch/arm/setup.c
> --- a/xen/arch/arm/setup.c	Mon Sep 03 09:57:33 2012 +0100
> +++ b/xen/arch/arm/setup.c	Mon Sep 03 09:59:35 2012 +0100
> @@ -238,9 +238,7 @@ void __init start_xen(unsigned long boot
>  
>      /* Create initial domain 0. */
>      dom0 = domain_create(0, 0, 0);
> -    if ( IS_ERR(dom0) )
> -            printk("domain_create failed\n");
> -    if ( (dom0 == NULL) || (alloc_dom0_vcpu0() == NULL) )
> +    if ( IS_ERR(dom0) || (alloc_dom0_vcpu0() == NULL) )
>              panic("Error creating domain 0\n");
>  
>      dom0->is_privileged = 1;




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

From xen-devel-bounces@lists.xen.org Mon Sep 03 09:10:53 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Sep 2012 09:10:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T8Sg7-00055f-3m; Mon, 03 Sep 2012 09:10:43 +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 1T8Sg5-00054x-Sz
	for xen-devel@lists.xen.org; Mon, 03 Sep 2012 09:10:42 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1346663273!4123890!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM3ODk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32473 invoked from network); 3 Sep 2012 09:07:53 -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;
	3 Sep 2012 09:07:53 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 03 Sep 2012 10:07:53 +0100
Message-Id: <50448F850200007800098356@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 03 Sep 2012 10:07:49 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Campbell" <Ian.Campbell@citrix.com>
References: <504470FD0200007800098213@nat28.tlf.novell.com>
	<1346662056.27277.250.camel@zakaz.uk.xensource.com>
	<1346662807.27277.251.camel@zakaz.uk.xensource.com>
In-Reply-To: <1346662807.27277.251.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] make domain_create() return a proper error
 code
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 03.09.12 at 11:00, Ian Campbell <Ian.Campbell@citrix.com> wrote:
>> > @@ -237,7 +238,7 @@ void __init start_xen(unsigned long boot
>> >  
>> >      /* Create initial domain 0. */
>> >      dom0 = domain_create(0, 0, 0);
>> > -    if ( dom0 == NULL )
>> > +    if ( IS_ERR(dom0) )
>> >              printk("domain_create failed\n");
>> >      if ( (dom0 == NULL) || (alloc_dom0_vcpu0() == NULL) )
>> 
>> You probably wanted to change this one too?
>> 
>> I'm not sure the first message really buys much -- I'd be happy to nuke
>> it too.
> 
> 8<------------------------
> 
> # HG changeset patch
> # User Ian Campbell <ian.campbell@citrix.com>
> # Date 1346662775 -3600
> # Node ID c4e822e1b491bb7efa962b38fff6f007f01596b5
> # Parent  241186e96a1ece42ad3bd14901b62d872f4abd9e
> arm: correctly check for error on dom0 allocation
> 
> Drop the redundant printk
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

Thanks and (if you care) ack.

Jan

> diff -r 241186e96a1e -r c4e822e1b491 xen/arch/arm/setup.c
> --- a/xen/arch/arm/setup.c	Mon Sep 03 09:57:33 2012 +0100
> +++ b/xen/arch/arm/setup.c	Mon Sep 03 09:59:35 2012 +0100
> @@ -238,9 +238,7 @@ void __init start_xen(unsigned long boot
>  
>      /* Create initial domain 0. */
>      dom0 = domain_create(0, 0, 0);
> -    if ( IS_ERR(dom0) )
> -            printk("domain_create failed\n");
> -    if ( (dom0 == NULL) || (alloc_dom0_vcpu0() == NULL) )
> +    if ( IS_ERR(dom0) || (alloc_dom0_vcpu0() == NULL) )
>              panic("Error creating domain 0\n");
>  
>      dom0->is_privileged = 1;




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

From xen-devel-bounces@lists.xen.org Mon Sep 03 09:11:17 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Sep 2012 09:11: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 1T8SgX-0005BX-I1; Mon, 03 Sep 2012 09:11:09 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1T8SgV-0005Au-St
	for xen-devel@lists.xen.org; Mon, 03 Sep 2012 09:11:08 +0000
Received: from [85.158.138.51:7537] by server-3.bemta-3.messagelabs.com id
	71/D5-21322-A2474405; Mon, 03 Sep 2012 09:11:06 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1346663449!20234038!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTEzODI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9258 invoked from network); 3 Sep 2012 09:10:49 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Sep 2012 09:10:49 -0000
X-IronPort-AV: E=Sophos;i="4.80,359,1344211200"; d="scan'208";a="14312062"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Sep 2012 09:10: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.279.1; Mon, 3 Sep 2012
	10:10:48 +0100
Message-ID: <1346663447.27277.254.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: George Dunlap <George.Dunlap@eu.citrix.com>
Date: Mon, 3 Sep 2012 10:10:47 +0100
In-Reply-To: <CAFLBxZZ7sBw-aKkF88jVkC5qbQetJEA2L_iPJ1iBXJ1RNDpjcw@mail.gmail.com>
References: <1346148361.9975.3.camel@zakaz.uk.xensource.com>
	<CAFLBxZZ7sBw-aKkF88jVkC5qbQetJEA2L_iPJ1iBXJ1RNDpjcw@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: xen-users <xen-users@lists.xen.org>, xen-devel <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 Fri, 2012-08-31 at 18:26 +0100, George Dunlap wrote:
> On Tue, Aug 28, 2012 at 3:06 AM, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> > hypervisor, nice to have:
> >
> >     * [BUG(?)] Under certain conditions, the p2m_pod_sweep code will
> >       stop halfway through searching, causing a guest to crash even if
> >       there was zeroed memory available.  This is NOT a regression
> >       from 4.1, and is a very rare case, so probably shouldn't be a
> >       blocker.  (In fact, I'd be open to the idea that it should wait
> >       until after the release to get more testing.)
> >             (George Dunlap)
> 
> I probably won't get a chance to work on this until I get back
> mid-september, so this shouldn't be a blocker.

No problem. Since we hope to do the final RC this week that effectively
means its pushed out to 4.3 so I'll mark it as such.

Ian.



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

From xen-devel-bounces@lists.xen.org Mon Sep 03 09:11:17 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Sep 2012 09:11: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 1T8SgX-0005BX-I1; Mon, 03 Sep 2012 09:11:09 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1T8SgV-0005Au-St
	for xen-devel@lists.xen.org; Mon, 03 Sep 2012 09:11:08 +0000
Received: from [85.158.138.51:7537] by server-3.bemta-3.messagelabs.com id
	71/D5-21322-A2474405; Mon, 03 Sep 2012 09:11:06 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1346663449!20234038!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTEzODI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9258 invoked from network); 3 Sep 2012 09:10:49 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Sep 2012 09:10:49 -0000
X-IronPort-AV: E=Sophos;i="4.80,359,1344211200"; d="scan'208";a="14312062"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Sep 2012 09:10: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.279.1; Mon, 3 Sep 2012
	10:10:48 +0100
Message-ID: <1346663447.27277.254.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: George Dunlap <George.Dunlap@eu.citrix.com>
Date: Mon, 3 Sep 2012 10:10:47 +0100
In-Reply-To: <CAFLBxZZ7sBw-aKkF88jVkC5qbQetJEA2L_iPJ1iBXJ1RNDpjcw@mail.gmail.com>
References: <1346148361.9975.3.camel@zakaz.uk.xensource.com>
	<CAFLBxZZ7sBw-aKkF88jVkC5qbQetJEA2L_iPJ1iBXJ1RNDpjcw@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: xen-users <xen-users@lists.xen.org>, xen-devel <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 Fri, 2012-08-31 at 18:26 +0100, George Dunlap wrote:
> On Tue, Aug 28, 2012 at 3:06 AM, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> > hypervisor, nice to have:
> >
> >     * [BUG(?)] Under certain conditions, the p2m_pod_sweep code will
> >       stop halfway through searching, causing a guest to crash even if
> >       there was zeroed memory available.  This is NOT a regression
> >       from 4.1, and is a very rare case, so probably shouldn't be a
> >       blocker.  (In fact, I'd be open to the idea that it should wait
> >       until after the release to get more testing.)
> >             (George Dunlap)
> 
> I probably won't get a chance to work on this until I get back
> mid-september, so this shouldn't be a blocker.

No problem. Since we hope to do the final RC this week that effectively
means its pushed out to 4.3 so I'll mark it as such.

Ian.



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

From xen-devel-bounces@lists.xen.org Mon Sep 03 09:15:45 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Sep 2012 09:15:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T8Sko-0005tq-UU; Mon, 03 Sep 2012 09:15: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 1T8Skn-0005th-8t
	for xen-devel@lists.xen.org; Mon, 03 Sep 2012 09:15:33 +0000
Received: from [85.158.143.99:26841] by server-3.bemta-4.messagelabs.com id
	04/F3-08232-43574405; Mon, 03 Sep 2012 09:15:32 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1346663730!28170160!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTEzODI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24515 invoked from network); 3 Sep 2012 09:15: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;
	3 Sep 2012 09:15:31 -0000
X-IronPort-AV: E=Sophos;i="4.80,359,1344211200"; d="scan'208";a="14312168"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Sep 2012 09:15: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.279.1; Mon, 3 Sep 2012
	10:15:30 +0100
Message-ID: <1346663727.27277.255.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Mon, 3 Sep 2012 10:15:27 +0100
In-Reply-To: <50447D7802000078000982B4@nat28.tlf.novell.com>
References: <1344935141.5926.6.camel@zakaz.uk.xensource.com>
	<20120814100704.GA19704@bloms.de>
	<1346421542.27277.218.camel@zakaz.uk.xensource.com>
	<1346425278.27277.224.camel@zakaz.uk.xensource.com>
	<5040F7140200007800097E91@nat28.tlf.novell.com>
	<1346428292.27277.243.camel@zakaz.uk.xensource.com>
	<5040FB490200007800097ED2@nat28.tlf.novell.com>
	<50409CE002000076000B3B44@novprvoes0310.provo.novell.com>
	<1346434547.5820.10.camel@dagon.hellion.org.uk>
	<50447D7802000078000982B4@nat28.tlf.novell.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Charles Arnold <CARNOLD@suse.com>, Kirk Allan <KALLAN@suse.com>,
	DieterBloms <xensource.com@bloms.de>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [Xen-users] Xen 4.2 TODO (io and irq parameter are
 not evaluated by xl)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2012-09-03 at 08:50 +0100, Jan Beulich wrote:
> >>> On 31.08.12 at 19:59, Kirk Allan wrote:
> >>> In one of my Window's vm config files, I was able to get the vm to
> >>> boot using ioports=['3f8-3ff'].  My goal was to do serial debugging of
> >>> the Windows vm.  I also added irq=[4] to the config file.  However, I
> >>> was not able to actually get a debug session to work.  The physical
> >>> machine running windbg received a string from the vm which gave me
> >>> hope that it was working, but then it never received further data so
> >>> the vm eventually booted without being attached to the debugger.
> >> 
> >> Thanks, the question was whether it would be useful to implement the
> >> 	ioports = '3f8-3ff'
> >> 	irq = 4
> >> syntax as well as the
> >> 	ioports = ['3f8-3ff']
> >> 	irq = [4]
> >> but it looks like you are actually using the array version anyway?
> > 
> > I first looked at this last week.  I found reference to both formats so I 
> > tried both.  I was only able to get the ioports = ['3f8-3ff'] and irq = [4] 
> > syntax to allow a vm to boot.
> 
> So Ian, I guess I got mislead by there being references to the
> non-array format - no need to alter your patch then in any way.
> 
> Sorry for the noise, Jan

No problem, it's a common problem when trying to figure out what xend
does or doesn't do...

Ian.



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

From xen-devel-bounces@lists.xen.org Mon Sep 03 09:15:45 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Sep 2012 09:15:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T8Sko-0005tq-UU; Mon, 03 Sep 2012 09:15: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 1T8Skn-0005th-8t
	for xen-devel@lists.xen.org; Mon, 03 Sep 2012 09:15:33 +0000
Received: from [85.158.143.99:26841] by server-3.bemta-4.messagelabs.com id
	04/F3-08232-43574405; Mon, 03 Sep 2012 09:15:32 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1346663730!28170160!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTEzODI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24515 invoked from network); 3 Sep 2012 09:15: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;
	3 Sep 2012 09:15:31 -0000
X-IronPort-AV: E=Sophos;i="4.80,359,1344211200"; d="scan'208";a="14312168"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Sep 2012 09:15: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.279.1; Mon, 3 Sep 2012
	10:15:30 +0100
Message-ID: <1346663727.27277.255.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Mon, 3 Sep 2012 10:15:27 +0100
In-Reply-To: <50447D7802000078000982B4@nat28.tlf.novell.com>
References: <1344935141.5926.6.camel@zakaz.uk.xensource.com>
	<20120814100704.GA19704@bloms.de>
	<1346421542.27277.218.camel@zakaz.uk.xensource.com>
	<1346425278.27277.224.camel@zakaz.uk.xensource.com>
	<5040F7140200007800097E91@nat28.tlf.novell.com>
	<1346428292.27277.243.camel@zakaz.uk.xensource.com>
	<5040FB490200007800097ED2@nat28.tlf.novell.com>
	<50409CE002000076000B3B44@novprvoes0310.provo.novell.com>
	<1346434547.5820.10.camel@dagon.hellion.org.uk>
	<50447D7802000078000982B4@nat28.tlf.novell.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Charles Arnold <CARNOLD@suse.com>, Kirk Allan <KALLAN@suse.com>,
	DieterBloms <xensource.com@bloms.de>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [Xen-users] Xen 4.2 TODO (io and irq parameter are
 not evaluated by xl)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2012-09-03 at 08:50 +0100, Jan Beulich wrote:
> >>> On 31.08.12 at 19:59, Kirk Allan wrote:
> >>> In one of my Window's vm config files, I was able to get the vm to
> >>> boot using ioports=['3f8-3ff'].  My goal was to do serial debugging of
> >>> the Windows vm.  I also added irq=[4] to the config file.  However, I
> >>> was not able to actually get a debug session to work.  The physical
> >>> machine running windbg received a string from the vm which gave me
> >>> hope that it was working, but then it never received further data so
> >>> the vm eventually booted without being attached to the debugger.
> >> 
> >> Thanks, the question was whether it would be useful to implement the
> >> 	ioports = '3f8-3ff'
> >> 	irq = 4
> >> syntax as well as the
> >> 	ioports = ['3f8-3ff']
> >> 	irq = [4]
> >> but it looks like you are actually using the array version anyway?
> > 
> > I first looked at this last week.  I found reference to both formats so I 
> > tried both.  I was only able to get the ioports = ['3f8-3ff'] and irq = [4] 
> > syntax to allow a vm to boot.
> 
> So Ian, I guess I got mislead by there being references to the
> non-array format - no need to alter your patch then in any way.
> 
> Sorry for the noise, Jan

No problem, it's a common problem when trying to figure out what xend
does or doesn't do...

Ian.



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

From xen-devel-bounces@lists.xen.org Mon Sep 03 09:17:00 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Sep 2012 09: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 1T8Sm3-0005yv-D2; Mon, 03 Sep 2012 09:16:51 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1T8Sm1-0005yj-JF
	for xen-devel@lists.xen.org; Mon, 03 Sep 2012 09:16:49 +0000
Received: from [85.158.143.99:49868] by server-3.bemta-4.messagelabs.com id
	D0/27-08232-08574405; Mon, 03 Sep 2012 09:16:48 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1346663807!21799151!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTEzODI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27088 invoked from network); 3 Sep 2012 09:16:48 -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;
	3 Sep 2012 09:16:48 -0000
X-IronPort-AV: E=Sophos;i="4.80,359,1344211200"; d="scan'208";a="14312183"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Sep 2012 09:15: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.279.1; Mon, 3 Sep 2012
	10:15:47 +0100
Message-ID: <1346663746.27277.256.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Dieter Bloms <dieter@bloms.de>
Date: Mon, 3 Sep 2012 10:15:46 +0100
In-Reply-To: <20120831193746.GA13009@bloms.de>
References: <1344935141.5926.6.camel@zakaz.uk.xensource.com>
	<20120814100704.GA19704@bloms.de>
	<1346421542.27277.218.camel@zakaz.uk.xensource.com>
	<1346425278.27277.224.camel@zakaz.uk.xensource.com>
	<5040F7140200007800097E91@nat28.tlf.novell.com>
	<1346428292.27277.243.camel@zakaz.uk.xensource.com>
	<5040FB490200007800097ED2@nat28.tlf.novell.com>
	<50409CE002000076000B3B44@novprvoes0310.provo.novell.com>
	<1346434547.5820.10.camel@dagon.hellion.org.uk>
	<20120831193746.GA13009@bloms.de>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Charles Arnold <CARNOLD@suse.com>, Kirk Allan <kallan@suse.com>,
	Dieter Bloms <xensource.com@bloms.de>, Ian
	Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>, Jan
	Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [Xen-users] Xen 4.2 TODO (io and irq parameter are
 not evaluated by xl)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-08-31 at 20:37 +0100, Dieter Bloms wrote:
> Hi,
> 
> Ian, thank you for implementing this io and irq support.
> 
> On Fri, Aug 31, Ian Campbell wrote:
> 
> > On Fri, 2012-08-31 at 18:15 +0100, Kirk Allan wrote:
> > 
> > > > Charles, Kirk, could you comment here?
> > > 
> > > In one of my Window's vm config files, I was able to get the vm to
> > > boot using ioports=['3f8-3ff'].  My goal was to do serial debugging of
> > > the Windows vm.  I also added irq=[4] to the config file.  However, I
> > > was not able to actually get a debug session to work.  The physical
> > > machine running windbg received a string from the vm which gave me
> > > hope that it was working, but then it never received further data so
> > > the vm eventually booted without being attached to the debugger.
> > 
> > Thanks, the question was whether it would be useful to implement the
> > 	ioports = '3f8-3ff'
> > 	irq = 4
> > syntax as well as the
> > 	ioports = ['3f8-3ff']
> > 	irq = [4]
> > but it looks like you are actually using the array version anyway?
> 
> I use this syntax with xm:
> 
> ioports=['0378-037a']
> irq=[5]
> 
> and it works good.

Great, thanks for confirming.

Ian.



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

From xen-devel-bounces@lists.xen.org Mon Sep 03 09:17:00 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Sep 2012 09: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 1T8Sm3-0005yv-D2; Mon, 03 Sep 2012 09:16:51 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1T8Sm1-0005yj-JF
	for xen-devel@lists.xen.org; Mon, 03 Sep 2012 09:16:49 +0000
Received: from [85.158.143.99:49868] by server-3.bemta-4.messagelabs.com id
	D0/27-08232-08574405; Mon, 03 Sep 2012 09:16:48 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1346663807!21799151!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTEzODI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27088 invoked from network); 3 Sep 2012 09:16:48 -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;
	3 Sep 2012 09:16:48 -0000
X-IronPort-AV: E=Sophos;i="4.80,359,1344211200"; d="scan'208";a="14312183"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Sep 2012 09:15: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.279.1; Mon, 3 Sep 2012
	10:15:47 +0100
Message-ID: <1346663746.27277.256.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Dieter Bloms <dieter@bloms.de>
Date: Mon, 3 Sep 2012 10:15:46 +0100
In-Reply-To: <20120831193746.GA13009@bloms.de>
References: <1344935141.5926.6.camel@zakaz.uk.xensource.com>
	<20120814100704.GA19704@bloms.de>
	<1346421542.27277.218.camel@zakaz.uk.xensource.com>
	<1346425278.27277.224.camel@zakaz.uk.xensource.com>
	<5040F7140200007800097E91@nat28.tlf.novell.com>
	<1346428292.27277.243.camel@zakaz.uk.xensource.com>
	<5040FB490200007800097ED2@nat28.tlf.novell.com>
	<50409CE002000076000B3B44@novprvoes0310.provo.novell.com>
	<1346434547.5820.10.camel@dagon.hellion.org.uk>
	<20120831193746.GA13009@bloms.de>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Charles Arnold <CARNOLD@suse.com>, Kirk Allan <kallan@suse.com>,
	Dieter Bloms <xensource.com@bloms.de>, Ian
	Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>, Jan
	Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [Xen-users] Xen 4.2 TODO (io and irq parameter are
 not evaluated by xl)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-08-31 at 20:37 +0100, Dieter Bloms wrote:
> Hi,
> 
> Ian, thank you for implementing this io and irq support.
> 
> On Fri, Aug 31, Ian Campbell wrote:
> 
> > On Fri, 2012-08-31 at 18:15 +0100, Kirk Allan wrote:
> > 
> > > > Charles, Kirk, could you comment here?
> > > 
> > > In one of my Window's vm config files, I was able to get the vm to
> > > boot using ioports=['3f8-3ff'].  My goal was to do serial debugging of
> > > the Windows vm.  I also added irq=[4] to the config file.  However, I
> > > was not able to actually get a debug session to work.  The physical
> > > machine running windbg received a string from the vm which gave me
> > > hope that it was working, but then it never received further data so
> > > the vm eventually booted without being attached to the debugger.
> > 
> > Thanks, the question was whether it would be useful to implement the
> > 	ioports = '3f8-3ff'
> > 	irq = 4
> > syntax as well as the
> > 	ioports = ['3f8-3ff']
> > 	irq = [4]
> > but it looks like you are actually using the array version anyway?
> 
> I use this syntax with xm:
> 
> ioports=['0378-037a']
> irq=[5]
> 
> and it works good.

Great, thanks for confirming.

Ian.



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

From xen-devel-bounces@lists.xen.org Mon Sep 03 09:31:29 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Sep 2012 09:31: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 1T8Szy-0006fB-1S; Mon, 03 Sep 2012 09:31: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 1T8Szw-0006f5-52
	for xen-devel@lists.xen.org; Mon, 03 Sep 2012 09:31:12 +0000
Received: from [85.158.139.83:21892] by server-12.bemta-5.messagelabs.com id
	82/AB-18300-FD874405; Mon, 03 Sep 2012 09:31:11 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1346664670!27563636!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM3ODk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8312 invoked from network); 3 Sep 2012 09:31:10 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-9.tower-182.messagelabs.com with SMTP;
	3 Sep 2012 09:31:10 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 03 Sep 2012 10:31:10 +0100
Message-Id: <504494FB0200007800098398@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 03 Sep 2012 10:31:07 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ben Guthro" <ben@guthro.net>
References: <CAOvdn6WwgBD-2yf1uu3m9-16=Tb5KUrybXf2KibtnxKbP7YtwA@mail.gmail.com>
	<CAOvdn6UBW-yTOMd3YSf5M9JiHLRivyaKL-qzcKG8epszqaKmGg@mail.gmail.com>
	<20120807163320.GC15053@phenom.dumpdata.com>
	<CAOvdn6XcRGKtJxGwJO8J+ZBJr89wfTLc1woW5rhtMM540H9h1w@mail.gmail.com>
	<CAOvdn6XUoSeGoo7X=AJ1kpDxZB9HZEv+TJ4v-=FHcyR4=CHK-w@mail.gmail.com>
	<502240F302000078000937A6@nat28.tlf.novell.com>
	<CAOvdn6WN3kxC8Bb9g6MpfLULu47EGSGCtajPc-SFeJ-8VSUQDQ@mail.gmail.com>
	<CAOvdn6Xk1inm1hU55i0phU2qvSWyJLNoyDdn43biBAY2OewPtw@mail.gmail.com>
	<5023F5400200007800093F4E@nat28.tlf.novell.com>
	<CAOvdn6U-f3C4U8xVPvDyRFkFFLkbfiCXg_n+9zgA9V5u+q5jfw@mail.gmail.com>
	<5023F8B80200007800093F8C@nat28.tlf.novell.com>
	<CAOvdn6XKHfete_+=Hkvt20G7_cJ-4i8+9j9YD30OxzQ16Ru-+g@mail.gmail.com>
	<5024CB720200007800094124@nat28.tlf.novell.com>
	<CAOvdn6VVJdhWVYa-gNVt3euE4AbGi1TijUCUd1wGzv0SCWEUYA@mail.gmail.com>
	<CAOvdn6USnG9Y4MNBhrDZmob0oJ8BgFfKTvFEhcKbXDxNmzfZ-Q@mail.gmail.com>
	<502B75BA0200007800094FD4@nat28.tlf.novell.com>
	<CAOvdn6Ww5oEj6Xg=XT4dWCYWUBuOdPqLz-CqNjz4HmCScE+==g@mail.gmail.com>
	<CAOvdn6Wsjds_dmZ0dwDTYmD-o-OqjBH5-b9mitAuUADE+A4_ag@mail.gmail.com>
	<502BB8FD02000078000951E0@nat28.tlf.novell.com>
	<CAOvdn6VD6bp13F-tvYdkBsj4hkhE7PTGZrapndtdHrDKeZqccg@mail.gmail.com>
	<502CCC0002000078000955C4@nat28.tlf.novell.com>
	<CAOvdn6VEuX7R2_wz74ZvCxMjC-=YUir9kP5sdxEVaKVspRUd_w@mail.gmail.com>
	<502CF0A8020000780009574E@nat28.tlf.novell.com>
	<CAOvdn6VsZvn_1TCWYeuyY5YuTcP8=miK2KwE4583nsj6Qjb_vg@mail.gmail.com>
In-Reply-To: <CAOvdn6VsZvn_1TCWYeuyY5YuTcP8=miK2KwE4583nsj6Qjb_vg@mail.gmail.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__PartCFFED6CB.2__="
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>, john.baboval@citrix.com,
	Thomas Goetz <thomas.goetz@citrix.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen4.2 S3 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>
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.

--=__PartCFFED6CB.2__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

>>> On 16.08.12 at 13:56, Ben Guthro <ben@guthro.net> wrote:
> Please let me know if there are anything else you'd like me to experiment=
=20
> with.

Attached a first take at a debugging patch.

While putting this together I realized that the situation gets
complicated by the fact that plain Linux 3.2.23 doesn't even
have support for post-S3 MSI restoration, so much would
depend on how exactly this is implemented in the kernel
you're running (i.e. whether you have a _complete_ backport
in place). I suppose you must be having some support for this
patched in, otherwise I wouldn't understand why things work
without IOMMU/interrupt remapping.

Jan


--=__PartCFFED6CB.2__=
Content-Type: text/plain; name="S3-MSI.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="S3-MSI.patch"

--- a/xen/arch/x86/msi.c=0A+++ b/xen/arch/x86/msi.c=0A@@ -207,10 +207,24 =
@@ static void read_msi_msg(struct msi_desc=0A =0A static void write_msi_ms=
g(struct msi_desc *entry, struct msi_msg *msg)=0A {=0A+ if(!(msg->data & =
MSI_DATA_VECTOR_MASK) || !(msg->data & MSI_DATA_LEVEL_ASSERT)//temp=0A+    =
|| (msg->data & MSI_DATA_DELIVERY_MODE_MASK) > MSI_DATA_DELIVERY_LOWPRI) =
{//temp=0A+  printk("MSI: addr=3D%08x%08x data=3D%08x dest=3D%08x =
bogus!\n", msg->address_hi, msg->address_lo, msg->data, msg->dest32);=0A+  =
dump_execution_state();=0A+ }=0A     entry->msg =3D *msg;=0A =0A     if ( =
iommu_enabled )=0A+ {//temp=0A         iommu_update_ire_from_msi(entry, =
msg);=0A+  if(!(entry->msg.data & MSI_DATA_VECTOR_MASK) || !(msg->data & =
MSI_DATA_VECTOR_MASK)=0A+     || !(msg->data & entry->msg.data & MSI_DATA_L=
EVEL_ASSERT)=0A+     || (entry->msg.data & MSI_DATA_DELIVERY_MODE_MASK) > =
MSI_DATA_DELIVERY_LOWPRI=0A+     || (msg->data & MSI_DATA_DELIVERY_MODE_MAS=
K) > MSI_DATA_DELIVERY_LOWPRI)=0A+   printk("MSI: addr=3D%08x%08x =
data=3D%08x dest=3D%08x (%08x%08x, %08x, %08x) bogus!\n",=0A+          =
entry->msg.address_hi, entry->msg.address_lo, entry->msg.data, entry->msg.d=
est32,=0A+          msg->address_hi, msg->address_lo, msg->data, msg->dest3=
2);=0A+ }=0A =0A     switch ( entry->msi_attrib.type )=0A     {=0A@@ =
-268,6 +282,11 @@ static void set_msi_affinity(struct irq_=0A =0A     =
memset(&msg, 0, sizeof(msg));=0A     read_msi_msg(msi_desc, &msg);=0A+ =
if(!(msg.data & MSI_DATA_VECTOR_MASK) || !(msg.data & MSI_DATA_LEVEL_ASSERT=
)//temp=0A+    || (msg.data & MSI_DATA_DELIVERY_MODE_MASK) > MSI_DATA_DELIV=
ERY_LOWPRI) {//temp=0A+  printk("MSI: addr=3D%08x%08x data=3D%08x =
bogus!\n", msg.address_hi, msg.address_lo, msg.data);=0A+  dump_execution_s=
tate();=0A+ }=0A =0A     msg.data &=3D ~MSI_DATA_VECTOR_MASK;=0A     =
msg.data |=3D MSI_DATA_VECTOR(desc->arch.vector);=0A@@ -1024,6 +1043,9 @@ =
int pci_restore_msi_state(struct pci_dev=0A             spin_unlock_irqrest=
ore(&desc->lock, flags);=0A             return -EINVAL;=0A         =
}=0A+printk("MSI[%04x:%02x:%02x:%u]: addr=3D%08x%08x data=3D%08x dest=3D%08=
x\n",//temp=0A+       pdev->seg, pdev->bus, PCI_SLOT(pdev->devfn), =
PCI_FUNC(pdev->devfn),//temp=0A+       entry->msg.address_hi, entry->msg.ad=
dress_lo, entry->msg.data, entry->msg.dest32);//temp=0A =0A         if ( =
entry->msi_attrib.type =3D=3D PCI_CAP_ID_MSI )=0A             msi_set_enabl=
e(pdev, 0);=0A@@ -1066,7 +1088,7 @@ unsigned int pci_msix_get_table_len(str=
u=0A     return len;=0A }=0A =0A-static void dump_msi(unsigned char =
key)=0A+/*static*/ void dump_msi(unsigned char key)=0A {=0A     unsigned =
int irq;=0A =0A
--=__PartCFFED6CB.2__=
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--=__PartCFFED6CB.2__=--


From xen-devel-bounces@lists.xen.org Mon Sep 03 09:31:29 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Sep 2012 09:31: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 1T8Szy-0006fB-1S; Mon, 03 Sep 2012 09:31: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 1T8Szw-0006f5-52
	for xen-devel@lists.xen.org; Mon, 03 Sep 2012 09:31:12 +0000
Received: from [85.158.139.83:21892] by server-12.bemta-5.messagelabs.com id
	82/AB-18300-FD874405; Mon, 03 Sep 2012 09:31:11 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1346664670!27563636!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM3ODk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8312 invoked from network); 3 Sep 2012 09:31:10 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-9.tower-182.messagelabs.com with SMTP;
	3 Sep 2012 09:31:10 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 03 Sep 2012 10:31:10 +0100
Message-Id: <504494FB0200007800098398@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 03 Sep 2012 10:31:07 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ben Guthro" <ben@guthro.net>
References: <CAOvdn6WwgBD-2yf1uu3m9-16=Tb5KUrybXf2KibtnxKbP7YtwA@mail.gmail.com>
	<CAOvdn6UBW-yTOMd3YSf5M9JiHLRivyaKL-qzcKG8epszqaKmGg@mail.gmail.com>
	<20120807163320.GC15053@phenom.dumpdata.com>
	<CAOvdn6XcRGKtJxGwJO8J+ZBJr89wfTLc1woW5rhtMM540H9h1w@mail.gmail.com>
	<CAOvdn6XUoSeGoo7X=AJ1kpDxZB9HZEv+TJ4v-=FHcyR4=CHK-w@mail.gmail.com>
	<502240F302000078000937A6@nat28.tlf.novell.com>
	<CAOvdn6WN3kxC8Bb9g6MpfLULu47EGSGCtajPc-SFeJ-8VSUQDQ@mail.gmail.com>
	<CAOvdn6Xk1inm1hU55i0phU2qvSWyJLNoyDdn43biBAY2OewPtw@mail.gmail.com>
	<5023F5400200007800093F4E@nat28.tlf.novell.com>
	<CAOvdn6U-f3C4U8xVPvDyRFkFFLkbfiCXg_n+9zgA9V5u+q5jfw@mail.gmail.com>
	<5023F8B80200007800093F8C@nat28.tlf.novell.com>
	<CAOvdn6XKHfete_+=Hkvt20G7_cJ-4i8+9j9YD30OxzQ16Ru-+g@mail.gmail.com>
	<5024CB720200007800094124@nat28.tlf.novell.com>
	<CAOvdn6VVJdhWVYa-gNVt3euE4AbGi1TijUCUd1wGzv0SCWEUYA@mail.gmail.com>
	<CAOvdn6USnG9Y4MNBhrDZmob0oJ8BgFfKTvFEhcKbXDxNmzfZ-Q@mail.gmail.com>
	<502B75BA0200007800094FD4@nat28.tlf.novell.com>
	<CAOvdn6Ww5oEj6Xg=XT4dWCYWUBuOdPqLz-CqNjz4HmCScE+==g@mail.gmail.com>
	<CAOvdn6Wsjds_dmZ0dwDTYmD-o-OqjBH5-b9mitAuUADE+A4_ag@mail.gmail.com>
	<502BB8FD02000078000951E0@nat28.tlf.novell.com>
	<CAOvdn6VD6bp13F-tvYdkBsj4hkhE7PTGZrapndtdHrDKeZqccg@mail.gmail.com>
	<502CCC0002000078000955C4@nat28.tlf.novell.com>
	<CAOvdn6VEuX7R2_wz74ZvCxMjC-=YUir9kP5sdxEVaKVspRUd_w@mail.gmail.com>
	<502CF0A8020000780009574E@nat28.tlf.novell.com>
	<CAOvdn6VsZvn_1TCWYeuyY5YuTcP8=miK2KwE4583nsj6Qjb_vg@mail.gmail.com>
In-Reply-To: <CAOvdn6VsZvn_1TCWYeuyY5YuTcP8=miK2KwE4583nsj6Qjb_vg@mail.gmail.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__PartCFFED6CB.2__="
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>, john.baboval@citrix.com,
	Thomas Goetz <thomas.goetz@citrix.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen4.2 S3 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>
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.

--=__PartCFFED6CB.2__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

>>> On 16.08.12 at 13:56, Ben Guthro <ben@guthro.net> wrote:
> Please let me know if there are anything else you'd like me to experiment=
=20
> with.

Attached a first take at a debugging patch.

While putting this together I realized that the situation gets
complicated by the fact that plain Linux 3.2.23 doesn't even
have support for post-S3 MSI restoration, so much would
depend on how exactly this is implemented in the kernel
you're running (i.e. whether you have a _complete_ backport
in place). I suppose you must be having some support for this
patched in, otherwise I wouldn't understand why things work
without IOMMU/interrupt remapping.

Jan


--=__PartCFFED6CB.2__=
Content-Type: text/plain; name="S3-MSI.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="S3-MSI.patch"

--- a/xen/arch/x86/msi.c=0A+++ b/xen/arch/x86/msi.c=0A@@ -207,10 +207,24 =
@@ static void read_msi_msg(struct msi_desc=0A =0A static void write_msi_ms=
g(struct msi_desc *entry, struct msi_msg *msg)=0A {=0A+ if(!(msg->data & =
MSI_DATA_VECTOR_MASK) || !(msg->data & MSI_DATA_LEVEL_ASSERT)//temp=0A+    =
|| (msg->data & MSI_DATA_DELIVERY_MODE_MASK) > MSI_DATA_DELIVERY_LOWPRI) =
{//temp=0A+  printk("MSI: addr=3D%08x%08x data=3D%08x dest=3D%08x =
bogus!\n", msg->address_hi, msg->address_lo, msg->data, msg->dest32);=0A+  =
dump_execution_state();=0A+ }=0A     entry->msg =3D *msg;=0A =0A     if ( =
iommu_enabled )=0A+ {//temp=0A         iommu_update_ire_from_msi(entry, =
msg);=0A+  if(!(entry->msg.data & MSI_DATA_VECTOR_MASK) || !(msg->data & =
MSI_DATA_VECTOR_MASK)=0A+     || !(msg->data & entry->msg.data & MSI_DATA_L=
EVEL_ASSERT)=0A+     || (entry->msg.data & MSI_DATA_DELIVERY_MODE_MASK) > =
MSI_DATA_DELIVERY_LOWPRI=0A+     || (msg->data & MSI_DATA_DELIVERY_MODE_MAS=
K) > MSI_DATA_DELIVERY_LOWPRI)=0A+   printk("MSI: addr=3D%08x%08x =
data=3D%08x dest=3D%08x (%08x%08x, %08x, %08x) bogus!\n",=0A+          =
entry->msg.address_hi, entry->msg.address_lo, entry->msg.data, entry->msg.d=
est32,=0A+          msg->address_hi, msg->address_lo, msg->data, msg->dest3=
2);=0A+ }=0A =0A     switch ( entry->msi_attrib.type )=0A     {=0A@@ =
-268,6 +282,11 @@ static void set_msi_affinity(struct irq_=0A =0A     =
memset(&msg, 0, sizeof(msg));=0A     read_msi_msg(msi_desc, &msg);=0A+ =
if(!(msg.data & MSI_DATA_VECTOR_MASK) || !(msg.data & MSI_DATA_LEVEL_ASSERT=
)//temp=0A+    || (msg.data & MSI_DATA_DELIVERY_MODE_MASK) > MSI_DATA_DELIV=
ERY_LOWPRI) {//temp=0A+  printk("MSI: addr=3D%08x%08x data=3D%08x =
bogus!\n", msg.address_hi, msg.address_lo, msg.data);=0A+  dump_execution_s=
tate();=0A+ }=0A =0A     msg.data &=3D ~MSI_DATA_VECTOR_MASK;=0A     =
msg.data |=3D MSI_DATA_VECTOR(desc->arch.vector);=0A@@ -1024,6 +1043,9 @@ =
int pci_restore_msi_state(struct pci_dev=0A             spin_unlock_irqrest=
ore(&desc->lock, flags);=0A             return -EINVAL;=0A         =
}=0A+printk("MSI[%04x:%02x:%02x:%u]: addr=3D%08x%08x data=3D%08x dest=3D%08=
x\n",//temp=0A+       pdev->seg, pdev->bus, PCI_SLOT(pdev->devfn), =
PCI_FUNC(pdev->devfn),//temp=0A+       entry->msg.address_hi, entry->msg.ad=
dress_lo, entry->msg.data, entry->msg.dest32);//temp=0A =0A         if ( =
entry->msi_attrib.type =3D=3D PCI_CAP_ID_MSI )=0A             msi_set_enabl=
e(pdev, 0);=0A@@ -1066,7 +1088,7 @@ unsigned int pci_msix_get_table_len(str=
u=0A     return len;=0A }=0A =0A-static void dump_msi(unsigned char =
key)=0A+/*static*/ void dump_msi(unsigned char key)=0A {=0A     unsigned =
int irq;=0A =0A
--=__PartCFFED6CB.2__=
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--=__PartCFFED6CB.2__=--


From xen-devel-bounces@lists.xen.org Mon Sep 03 09:43:37 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Sep 2012 09: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 1T8TBi-00070U-Nz; Mon, 03 Sep 2012 09:43:22 +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 1T8TBh-00070M-Hj; Mon, 03 Sep 2012 09:43:21 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1346665394!4128925!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTEzODI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 718 invoked from network); 3 Sep 2012 09:43:15 -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;
	3 Sep 2012 09:43:15 -0000
X-IronPort-AV: E=Sophos;i="4.80,359,1344211200"; d="scan'208";a="14312871"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Sep 2012 09:42: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.279.1; Mon, 3 Sep 2012
	10:42:42 +0100
Message-ID: <1346665360.25864.2.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: xen-devel <xen-devel@lists.xen.org>, xen-users <xen-users@lists.xen.org>
Date: Mon, 3 Sep 2012 10:42:40 +0100
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Subject: [Xen-devel] Xen 4.2.0 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

MTkgTWFyY2ggICAgICAgIC0tIFRPRE8gbGlzdCBsb2NrZWQgZG93bgoyIEFwcmlsICAgICAgICAg
LS0gRmVhdHVyZSBGcmVlemUKMzAgSnVseQkJLS0gWGVuIDQuMi4wLXJjMQo4IEF1Z3VzdAktLSBY
ZW4gNC4yLjAtcmMyCjIzIEF1Z3VzdAktLSBYZW4gNC4yLjAtcmMzCldlZWtseSAgICAgICAgICAt
LSBSQ04rMSB1bnRpbCByZWxlYXNlICAgICAgICAgIDw8IFdFIEFSRSBIRVJFCgpXZSBpbnRlbmQg
dG8gcmVsZWFzZSBSQzQgdG93YXJkcyB0aGUgZW5kIG9mIHRoaXMgd2Vlay4gQWxsIGJlaW5nIHdl
bGwKd2UgaW50ZW5kIGZvciB0aGlzIHRvIGJlIHRoZSBmaW5hbCByZWxlYXNlIGNhbmRpZGF0ZS4g
UGxlYXNlIHRlc3QhCgpUaGUgdXBkYXRlZCBUT0RPIGxpc3QgZm9sbG93cy4KCmh5cGVydmlzb3Is
IGJsb2NrZXJzOgoKICAgICogTm9uZQoKdG9vbHMsIGJsb2NrZXJzOgoKICAgICogbGlieGwgc3Rh
YmxlIEFQSSAtLSB3ZSB3b3VsZCBsaWtlIDQuMiB0byBkZWZpbmUgYSBzdGFibGUgQVBJCiAgICAg
IHdoaWNoIGRvd25zdHJlYW0ncyBjYW4gc3RhcnQgdG8gcmVseSBvbiBub3QgY2hhbmdpbmcuIEFz
cGVjdHMgb2YKICAgICAgdGhpcyBhcmU6CgogICAgICAgICogTm9uZSBrbm93bgoKICAgICogeGwg
Y29tcGF0aWJpbGl0eSB3aXRoIHhtOgoKICAgICAgICAqIE5vIGtub3duIGlzc3VlcwoKICAgICog
W0NIRUNLXSBNb3JlIGZvcm1hbGx5IGRlcHJlY2F0ZSB4bS94ZW5kLiBNYW5wYWdlIHBhdGNoZXMg
YWxyZWFkeQogICAgICBpbiB0cmVlLiBOZWVkcyByZWxlYXNlIG5vdGluZyBhbmQgY29tbXVuaWNh
dGlvbiBhcm91bmQgLXJjMSB0bwogICAgICByZW1pbmQgcGVvcGxlIHRvIHRlc3QgeGwuIChET05F
KQoKICAgICogW0NIRUNLXSBDb25maXJtIHRoYXQgbWlncmF0aW9uIGZyb20gWGVuIDQuMSAtPiA0
LjIgd29ya3MuIChET05FCiAgICAgIGZvciBQViwgSFZNIHN0aWxsIFRPRE8pCgogICAgKiBCdW1w
IGxpYnJhcnkgU09OQU1FUyBhcyBuZWNlc3NhcnkuCiAgICAgIDwyMDUwMi4zOTQ0MC45Njk2MTku
ODI0OTc2QG1hcmluZXIudWsueGVuc291cmNlLmNvbT4KCiAgICAqIFtCVUddIHFlbXUtdHJhZGl0
aW9uYWwgaGFzIDUwJSBjcHUgdXRpbGl6YXRpb24gb24gYW4gaWRsZQogICAgICBXaW5kb3dzIHN5
c3RlbSBpZiBVU0IgaXMgZW5hYmxlZC4gTm90IDEwMCUgY2xlYXIgd2hldGhlciB0aGlzIGlzCiAg
ICAgIFhlbiBvciBxZW11LiAgR2VvcmdlIER1bmxhcCB0aGlua3MgdGhpcyBpcyBtb3N0bHkgZG93
biB0byA2NC1iaXQKICAgICAgc3lzY2FsbCBvdmVyaGVhZCBhbmQgaXMgbm90IGEgYmxvY2tlciwg
d2lsbCBkcm9wIGZyb20gdGhlIGxpc3QuCgogICAgKiBEaXNhYmxlIGdlbmVyYXRpb24gaWQgZnJv
bSB4bC4gTWljcm9zb2Z0IGNoYW5nZWQgdGhlCiAgICAgIHNwZWNpZmljYXRpb24gb2YgdGhpcyB2
YWx1ZSBiZXR3ZWVuIFc4IGJldGEgYW5kIFJDIGFuZCB3ZSBub3cKICAgICAgaW1wbGVtZW50IHRo
ZSBvbGQgc3BlYy4gRGlzYWJsZSBmb3IgNC4yIGFuZCByZXZpc3QgaW1wbGVtZW50aW5nCiAgICAg
IHRoZSBuZXcgc3BlYyBmb3IgNC4zLiAoUGF1bCBEdXJyYW50LCBET05FKQoKaHlwZXJ2aXNvciwg
bmljZSB0byBoYXZlOgoKICAgICogW0JVRyg/KV0gVW5kZXIgY2VydGFpbiBjb25kaXRpb25zLCB0
aGUgcDJtX3BvZF9zd2VlcCBjb2RlIHdpbGwKICAgICAgc3RvcCBoYWxmd2F5IHRocm91Z2ggc2Vh
cmNoaW5nLCBjYXVzaW5nIGEgZ3Vlc3QgdG8gY3Jhc2ggZXZlbiBpZgogICAgICB0aGVyZSB3YXMg
emVyb2VkIG1lbW9yeSBhdmFpbGFibGUuICBUaGlzIGlzIE5PVCBhIHJlZ3Jlc3Npb24KICAgICAg
ZnJvbSA0LjEsIGFuZCBpcyBhIHZlcnkgcmFyZSBjYXNlLCBzbyBwcm9iYWJseSBzaG91bGRuJ3Qg
YmUgYQogICAgICBibG9ja2VyLiAgKEluIGZhY3QsIEknZCBiZSBvcGVuIHRvIHRoZSBpZGVhIHRo
YXQgaXQgc2hvdWxkIHdhaXQKICAgICAgdW50aWwgYWZ0ZXIgdGhlIHJlbGVhc2UgdG8gZ2V0IG1v
cmUgdGVzdGluZy4pCiAgICAgIAkgICAgKEdlb3JnZSBEdW5sYXAsIGRlZmVyIHVudGlsIDQuMykK
CiAgICAqIFMzIHJlZ3Jlc3Npb24ocz8pIHJlcG9ydGVkIGJ5IEJlbiBHdXRocm8gKEJlbiAmIEph
biBCZXVsaWNoKQoKICAgICogZml4IGhpZ2ggY2hhbmdlIHJhdGUgdG8gQ01PUyBSVEMgcGVyaW9k
aWMgaW50ZXJydXB0IGNhdXNpbmcKICAgICAgZ3Vlc3Qgd2FsbCBjbG9jayB0aW1lIHRvIGxhZyAo
SmFuIEJldWxpY2gsIGNvcmUgZml4IERPTkUgZm9yCiAgICAgIDQuMiwgcmVzdCBwdXNoZWQgb3V0
IHRvIHBvc3QgNC4yKQoKdG9vbHMsIG5pY2UgdG8gaGF2ZToKCiAgICAqIHhsIGNvbXBhdGliaWxp
dHkgd2l0aCB4bToKCiAgICAgICAgKiB0aGUgcGFyYW1ldGVyIGlvIGFuZCBpcnEgaW4gZG9tVSBj
b25maWcgZmlsZXMgYXJlIG5vdAogICAgICAgICAgZXZhbHVhdGVkIGJ5IHhsLiAgU28gaXQgaXMg
bm90IHBvc3NpYmxlIHRvIHBhc3N0aHJvdWdoIGEKICAgICAgICAgIHBhcmFsbGVsIHBvcnQgZm9y
IG15IHByaW50ZXIgdG8gZG9tVSB3aGVuIEkgc3RhcnQgdGhlIGRvbVUKICAgICAgICAgIHdpdGgg
eGwgY29tbWFuZC4gKHJlcG9ydGVkIGJ5IERpZXRlciBCbG9tcywKICAgICAgICAgIDwyMDEyMDgx
NDEwMDcwNC5HQTE5NzA0QGJsb21zLmRlPi4gSWFuIENhbXBiZWxsLCBwYXRjaCBwb3N0ZWQpCgog
ICAgICAgICogeGwgZG9lc24ndCBzdXBwb3J0IHRoZSAnLWEnIG9wdGlvbiBmb3Igc2h1dGRvd24s
IHRvIHNodXRkb3duCiAgICAgICAgICBhbGwgZG9tYWlucy4gKFJlcG9ydGVkIGJ5IFNhbmRlciBF
aWtlbGVuYm9vbSAKCSAgPDg4NTgyMTU0OC4yMDEyMDgzMTEyNDkwMkBlaWtlbGVuYm9vbS5pdD4p
IAoKICAgICogeGwuY2ZnKDUpIGRvY3VtZW50YXRpb24gcGF0Y2ggZm9yIHFlbXUtdXBzdHJlYW0K
ICAgICAgdmlkZW9yYW0vdmlkZW9tZW0gc3VwcG9ydDoKICAgICAgaHR0cDovL2xpc3RzLnhlbi5v
cmcvYXJjaGl2ZXMvaHRtbC94ZW4tZGV2ZWwvMjAxMi0wNS9tc2cwMDI1MC5odG1sCiAgICAgIHFl
bXUtdXBzdHJlYW0gZG9lc24ndCBzdXBwb3J0IHNwZWNpZnlpbmcgdmlkZW9tZW0gc2l6ZSBmb3Ig
dGhlCiAgICAgIEhWTSBndWVzdCBjaXJydXMvc3RkdmdhLiAgKGJ1dCB0aGlzIHdvcmtzIHdpdGgK
ICAgICAgcWVtdS14ZW4tdHJhZGl0aW9uYWwpLiAoUGFzaSBLw6Rya2vDpGluZW4sIHBhdGNoZXMg
c2VudCkKCiAgICAqIFtCVUddICd4bCB2Y3B1LXNldCcgY2FuJ3QgZGVjcmVhc2UgdGhlIHZDUFUg
bnVtYmVyIG9mIGEgSFZNIGd1ZXN0CiAgICAgIGh0dHA6Ly9idWd6aWxsYS54ZW4ub3JnL2J1Z3pp
bGxhL3Nob3dfYnVnLmNnaT9pZD0xODIyCgogICAgKiBMb2FkIGJsa3RhcCBkcml2ZXIgZnJvbSB4
ZW5jb21tb25zIGluaXRzY3JpcHQgaWYgYXZhaWxhYmxlLCB0aHJlYWQgYXQ6CiAgICAgIDxkYjYx
NGU5MmZhZjc0M2UyMGIzZi4xMzM3MDk2OTc3QGtvZG8yPi4gVG8gYmUgZml4ZWQgbW9yZQogICAg
ICBwcm9wZXJseSBpbiA0LjMuIChET05FKQoKICAgICogW0JVR10geGwgYWxsb3dzIHNhbWUgUENJ
IGRldmljZSB0byBiZSBhc3NpZ25lZCB0byBtdWx0aXBsZQogICAgICBndWVzdHMuIGh0dHA6Ly9i
dWd6aWxsYS54ZW4ub3JnL2J1Z3ppbGxhL3Nob3dfYnVnLmNnaT9pZD0xODI2CiAgICAgICg8RTQ1
NThDMEM5NjY4ODc0ODgzN0VCMUIwNUJFRUQ3NUEwRkQ1NTc0QUBTSFNNU1gxMDIuY2NyLmNvcnAu
aW50ZWwuY29tPikKCiAgICAqICJ4bCBjcHVwb29sLWNyZWF0ZSIgc2VnZmF1bHQgb24gaW5jb3Jy
ZWN0IGlucHV0LiBSZXBvcnRlZCBieQogICAgICBHZW9yZ2UgRHVubGFwLAogICAgICA8Q0FGTEJ4
WmFFY2kwbU9jRENnRlg5ems9d2gzejROZjFMRDVFNUZjeTdZMz1pb0RBTT1nQG1haWwuZ21haWwu
Y29tPgogICAgICAoSWFuIEphY2tzb24sIERPTkUpCgogICAgKiBbQlVHXSB4bCBmYWlscyBvbiBj
b25maWcgZmlsZXMgd2hpY2ggYXJlIG1pc3NpbmcgdGhlIGZpbmFsCiAgICAgIG5ld2xpbmUgKElh
biBKYWNrc29uKSAKCgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRw
Oi8vbGlzdHMueGVuLm9yZy94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xen.org Mon Sep 03 09:43:37 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Sep 2012 09: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 1T8TBi-00070U-Nz; Mon, 03 Sep 2012 09:43:22 +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 1T8TBh-00070M-Hj; Mon, 03 Sep 2012 09:43:21 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1346665394!4128925!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTEzODI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 718 invoked from network); 3 Sep 2012 09:43:15 -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;
	3 Sep 2012 09:43:15 -0000
X-IronPort-AV: E=Sophos;i="4.80,359,1344211200"; d="scan'208";a="14312871"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Sep 2012 09:42: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.279.1; Mon, 3 Sep 2012
	10:42:42 +0100
Message-ID: <1346665360.25864.2.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: xen-devel <xen-devel@lists.xen.org>, xen-users <xen-users@lists.xen.org>
Date: Mon, 3 Sep 2012 10:42:40 +0100
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Subject: [Xen-devel] Xen 4.2.0 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

MTkgTWFyY2ggICAgICAgIC0tIFRPRE8gbGlzdCBsb2NrZWQgZG93bgoyIEFwcmlsICAgICAgICAg
LS0gRmVhdHVyZSBGcmVlemUKMzAgSnVseQkJLS0gWGVuIDQuMi4wLXJjMQo4IEF1Z3VzdAktLSBY
ZW4gNC4yLjAtcmMyCjIzIEF1Z3VzdAktLSBYZW4gNC4yLjAtcmMzCldlZWtseSAgICAgICAgICAt
LSBSQ04rMSB1bnRpbCByZWxlYXNlICAgICAgICAgIDw8IFdFIEFSRSBIRVJFCgpXZSBpbnRlbmQg
dG8gcmVsZWFzZSBSQzQgdG93YXJkcyB0aGUgZW5kIG9mIHRoaXMgd2Vlay4gQWxsIGJlaW5nIHdl
bGwKd2UgaW50ZW5kIGZvciB0aGlzIHRvIGJlIHRoZSBmaW5hbCByZWxlYXNlIGNhbmRpZGF0ZS4g
UGxlYXNlIHRlc3QhCgpUaGUgdXBkYXRlZCBUT0RPIGxpc3QgZm9sbG93cy4KCmh5cGVydmlzb3Is
IGJsb2NrZXJzOgoKICAgICogTm9uZQoKdG9vbHMsIGJsb2NrZXJzOgoKICAgICogbGlieGwgc3Rh
YmxlIEFQSSAtLSB3ZSB3b3VsZCBsaWtlIDQuMiB0byBkZWZpbmUgYSBzdGFibGUgQVBJCiAgICAg
IHdoaWNoIGRvd25zdHJlYW0ncyBjYW4gc3RhcnQgdG8gcmVseSBvbiBub3QgY2hhbmdpbmcuIEFz
cGVjdHMgb2YKICAgICAgdGhpcyBhcmU6CgogICAgICAgICogTm9uZSBrbm93bgoKICAgICogeGwg
Y29tcGF0aWJpbGl0eSB3aXRoIHhtOgoKICAgICAgICAqIE5vIGtub3duIGlzc3VlcwoKICAgICog
W0NIRUNLXSBNb3JlIGZvcm1hbGx5IGRlcHJlY2F0ZSB4bS94ZW5kLiBNYW5wYWdlIHBhdGNoZXMg
YWxyZWFkeQogICAgICBpbiB0cmVlLiBOZWVkcyByZWxlYXNlIG5vdGluZyBhbmQgY29tbXVuaWNh
dGlvbiBhcm91bmQgLXJjMSB0bwogICAgICByZW1pbmQgcGVvcGxlIHRvIHRlc3QgeGwuIChET05F
KQoKICAgICogW0NIRUNLXSBDb25maXJtIHRoYXQgbWlncmF0aW9uIGZyb20gWGVuIDQuMSAtPiA0
LjIgd29ya3MuIChET05FCiAgICAgIGZvciBQViwgSFZNIHN0aWxsIFRPRE8pCgogICAgKiBCdW1w
IGxpYnJhcnkgU09OQU1FUyBhcyBuZWNlc3NhcnkuCiAgICAgIDwyMDUwMi4zOTQ0MC45Njk2MTku
ODI0OTc2QG1hcmluZXIudWsueGVuc291cmNlLmNvbT4KCiAgICAqIFtCVUddIHFlbXUtdHJhZGl0
aW9uYWwgaGFzIDUwJSBjcHUgdXRpbGl6YXRpb24gb24gYW4gaWRsZQogICAgICBXaW5kb3dzIHN5
c3RlbSBpZiBVU0IgaXMgZW5hYmxlZC4gTm90IDEwMCUgY2xlYXIgd2hldGhlciB0aGlzIGlzCiAg
ICAgIFhlbiBvciBxZW11LiAgR2VvcmdlIER1bmxhcCB0aGlua3MgdGhpcyBpcyBtb3N0bHkgZG93
biB0byA2NC1iaXQKICAgICAgc3lzY2FsbCBvdmVyaGVhZCBhbmQgaXMgbm90IGEgYmxvY2tlciwg
d2lsbCBkcm9wIGZyb20gdGhlIGxpc3QuCgogICAgKiBEaXNhYmxlIGdlbmVyYXRpb24gaWQgZnJv
bSB4bC4gTWljcm9zb2Z0IGNoYW5nZWQgdGhlCiAgICAgIHNwZWNpZmljYXRpb24gb2YgdGhpcyB2
YWx1ZSBiZXR3ZWVuIFc4IGJldGEgYW5kIFJDIGFuZCB3ZSBub3cKICAgICAgaW1wbGVtZW50IHRo
ZSBvbGQgc3BlYy4gRGlzYWJsZSBmb3IgNC4yIGFuZCByZXZpc3QgaW1wbGVtZW50aW5nCiAgICAg
IHRoZSBuZXcgc3BlYyBmb3IgNC4zLiAoUGF1bCBEdXJyYW50LCBET05FKQoKaHlwZXJ2aXNvciwg
bmljZSB0byBoYXZlOgoKICAgICogW0JVRyg/KV0gVW5kZXIgY2VydGFpbiBjb25kaXRpb25zLCB0
aGUgcDJtX3BvZF9zd2VlcCBjb2RlIHdpbGwKICAgICAgc3RvcCBoYWxmd2F5IHRocm91Z2ggc2Vh
cmNoaW5nLCBjYXVzaW5nIGEgZ3Vlc3QgdG8gY3Jhc2ggZXZlbiBpZgogICAgICB0aGVyZSB3YXMg
emVyb2VkIG1lbW9yeSBhdmFpbGFibGUuICBUaGlzIGlzIE5PVCBhIHJlZ3Jlc3Npb24KICAgICAg
ZnJvbSA0LjEsIGFuZCBpcyBhIHZlcnkgcmFyZSBjYXNlLCBzbyBwcm9iYWJseSBzaG91bGRuJ3Qg
YmUgYQogICAgICBibG9ja2VyLiAgKEluIGZhY3QsIEknZCBiZSBvcGVuIHRvIHRoZSBpZGVhIHRo
YXQgaXQgc2hvdWxkIHdhaXQKICAgICAgdW50aWwgYWZ0ZXIgdGhlIHJlbGVhc2UgdG8gZ2V0IG1v
cmUgdGVzdGluZy4pCiAgICAgIAkgICAgKEdlb3JnZSBEdW5sYXAsIGRlZmVyIHVudGlsIDQuMykK
CiAgICAqIFMzIHJlZ3Jlc3Npb24ocz8pIHJlcG9ydGVkIGJ5IEJlbiBHdXRocm8gKEJlbiAmIEph
biBCZXVsaWNoKQoKICAgICogZml4IGhpZ2ggY2hhbmdlIHJhdGUgdG8gQ01PUyBSVEMgcGVyaW9k
aWMgaW50ZXJydXB0IGNhdXNpbmcKICAgICAgZ3Vlc3Qgd2FsbCBjbG9jayB0aW1lIHRvIGxhZyAo
SmFuIEJldWxpY2gsIGNvcmUgZml4IERPTkUgZm9yCiAgICAgIDQuMiwgcmVzdCBwdXNoZWQgb3V0
IHRvIHBvc3QgNC4yKQoKdG9vbHMsIG5pY2UgdG8gaGF2ZToKCiAgICAqIHhsIGNvbXBhdGliaWxp
dHkgd2l0aCB4bToKCiAgICAgICAgKiB0aGUgcGFyYW1ldGVyIGlvIGFuZCBpcnEgaW4gZG9tVSBj
b25maWcgZmlsZXMgYXJlIG5vdAogICAgICAgICAgZXZhbHVhdGVkIGJ5IHhsLiAgU28gaXQgaXMg
bm90IHBvc3NpYmxlIHRvIHBhc3N0aHJvdWdoIGEKICAgICAgICAgIHBhcmFsbGVsIHBvcnQgZm9y
IG15IHByaW50ZXIgdG8gZG9tVSB3aGVuIEkgc3RhcnQgdGhlIGRvbVUKICAgICAgICAgIHdpdGgg
eGwgY29tbWFuZC4gKHJlcG9ydGVkIGJ5IERpZXRlciBCbG9tcywKICAgICAgICAgIDwyMDEyMDgx
NDEwMDcwNC5HQTE5NzA0QGJsb21zLmRlPi4gSWFuIENhbXBiZWxsLCBwYXRjaCBwb3N0ZWQpCgog
ICAgICAgICogeGwgZG9lc24ndCBzdXBwb3J0IHRoZSAnLWEnIG9wdGlvbiBmb3Igc2h1dGRvd24s
IHRvIHNodXRkb3duCiAgICAgICAgICBhbGwgZG9tYWlucy4gKFJlcG9ydGVkIGJ5IFNhbmRlciBF
aWtlbGVuYm9vbSAKCSAgPDg4NTgyMTU0OC4yMDEyMDgzMTEyNDkwMkBlaWtlbGVuYm9vbS5pdD4p
IAoKICAgICogeGwuY2ZnKDUpIGRvY3VtZW50YXRpb24gcGF0Y2ggZm9yIHFlbXUtdXBzdHJlYW0K
ICAgICAgdmlkZW9yYW0vdmlkZW9tZW0gc3VwcG9ydDoKICAgICAgaHR0cDovL2xpc3RzLnhlbi5v
cmcvYXJjaGl2ZXMvaHRtbC94ZW4tZGV2ZWwvMjAxMi0wNS9tc2cwMDI1MC5odG1sCiAgICAgIHFl
bXUtdXBzdHJlYW0gZG9lc24ndCBzdXBwb3J0IHNwZWNpZnlpbmcgdmlkZW9tZW0gc2l6ZSBmb3Ig
dGhlCiAgICAgIEhWTSBndWVzdCBjaXJydXMvc3RkdmdhLiAgKGJ1dCB0aGlzIHdvcmtzIHdpdGgK
ICAgICAgcWVtdS14ZW4tdHJhZGl0aW9uYWwpLiAoUGFzaSBLw6Rya2vDpGluZW4sIHBhdGNoZXMg
c2VudCkKCiAgICAqIFtCVUddICd4bCB2Y3B1LXNldCcgY2FuJ3QgZGVjcmVhc2UgdGhlIHZDUFUg
bnVtYmVyIG9mIGEgSFZNIGd1ZXN0CiAgICAgIGh0dHA6Ly9idWd6aWxsYS54ZW4ub3JnL2J1Z3pp
bGxhL3Nob3dfYnVnLmNnaT9pZD0xODIyCgogICAgKiBMb2FkIGJsa3RhcCBkcml2ZXIgZnJvbSB4
ZW5jb21tb25zIGluaXRzY3JpcHQgaWYgYXZhaWxhYmxlLCB0aHJlYWQgYXQ6CiAgICAgIDxkYjYx
NGU5MmZhZjc0M2UyMGIzZi4xMzM3MDk2OTc3QGtvZG8yPi4gVG8gYmUgZml4ZWQgbW9yZQogICAg
ICBwcm9wZXJseSBpbiA0LjMuIChET05FKQoKICAgICogW0JVR10geGwgYWxsb3dzIHNhbWUgUENJ
IGRldmljZSB0byBiZSBhc3NpZ25lZCB0byBtdWx0aXBsZQogICAgICBndWVzdHMuIGh0dHA6Ly9i
dWd6aWxsYS54ZW4ub3JnL2J1Z3ppbGxhL3Nob3dfYnVnLmNnaT9pZD0xODI2CiAgICAgICg8RTQ1
NThDMEM5NjY4ODc0ODgzN0VCMUIwNUJFRUQ3NUEwRkQ1NTc0QUBTSFNNU1gxMDIuY2NyLmNvcnAu
aW50ZWwuY29tPikKCiAgICAqICJ4bCBjcHVwb29sLWNyZWF0ZSIgc2VnZmF1bHQgb24gaW5jb3Jy
ZWN0IGlucHV0LiBSZXBvcnRlZCBieQogICAgICBHZW9yZ2UgRHVubGFwLAogICAgICA8Q0FGTEJ4
WmFFY2kwbU9jRENnRlg5ems9d2gzejROZjFMRDVFNUZjeTdZMz1pb0RBTT1nQG1haWwuZ21haWwu
Y29tPgogICAgICAoSWFuIEphY2tzb24sIERPTkUpCgogICAgKiBbQlVHXSB4bCBmYWlscyBvbiBj
b25maWcgZmlsZXMgd2hpY2ggYXJlIG1pc3NpbmcgdGhlIGZpbmFsCiAgICAgIG5ld2xpbmUgKElh
biBKYWNrc29uKSAKCgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRw
Oi8vbGlzdHMueGVuLm9yZy94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xen.org Mon Sep 03 09:44:20 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Sep 2012 09:44:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T8TCQ-00075W-QL; Mon, 03 Sep 2012 09:44:06 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1T8TCP-000754-5j
	for xen-devel@lists.xensource.com; Mon, 03 Sep 2012 09:44:05 +0000
Received: from [85.158.143.35:15766] by server-1.bemta-4.messagelabs.com id
	B3/14-12504-4EB74405; Mon, 03 Sep 2012 09:44:04 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1346665443!5949219!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTEzODI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5866 invoked from network); 3 Sep 2012 09:44:03 -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;
	3 Sep 2012 09:44:03 -0000
X-IronPort-AV: E=Sophos;i="4.80,359,1344211200"; d="scan'208";a="14312897"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Sep 2012 09:44: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.279.1; Mon, 3 Sep 2012
	10:44:03 +0100
Message-ID: <1346665442.25864.4.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Mon, 3 Sep 2012 10:44:02 +0100
In-Reply-To: <20543.33474.765508.72674@mariner.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>
	<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.1206291211320.27860@kaball.uk.xensource.com>
	<20543.33474.765508.72674@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "rolu@roce.org" <rolu@roce.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Jan Beulich <JBeulich@suse.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [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

On Thu, 2012-08-30 at 16:12 +0100, Ian Jackson wrote:
> Stefano Stabellini writes ("[Xen-devel] [PATCH] qemu-xen-trad: fix msi_translate with PV event delivery"):
> > 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.
> 
> I have applied this to 4.2.

You've not updated QEMU_TAG.

Ian.



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

From xen-devel-bounces@lists.xen.org Mon Sep 03 09:44:20 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Sep 2012 09:44:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T8TCQ-00075W-QL; Mon, 03 Sep 2012 09:44:06 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1T8TCP-000754-5j
	for xen-devel@lists.xensource.com; Mon, 03 Sep 2012 09:44:05 +0000
Received: from [85.158.143.35:15766] by server-1.bemta-4.messagelabs.com id
	B3/14-12504-4EB74405; Mon, 03 Sep 2012 09:44:04 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1346665443!5949219!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTEzODI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5866 invoked from network); 3 Sep 2012 09:44:03 -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;
	3 Sep 2012 09:44:03 -0000
X-IronPort-AV: E=Sophos;i="4.80,359,1344211200"; d="scan'208";a="14312897"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Sep 2012 09:44: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.279.1; Mon, 3 Sep 2012
	10:44:03 +0100
Message-ID: <1346665442.25864.4.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Mon, 3 Sep 2012 10:44:02 +0100
In-Reply-To: <20543.33474.765508.72674@mariner.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>
	<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.1206291211320.27860@kaball.uk.xensource.com>
	<20543.33474.765508.72674@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "rolu@roce.org" <rolu@roce.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Jan Beulich <JBeulich@suse.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [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

On Thu, 2012-08-30 at 16:12 +0100, Ian Jackson wrote:
> Stefano Stabellini writes ("[Xen-devel] [PATCH] qemu-xen-trad: fix msi_translate with PV event delivery"):
> > 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.
> 
> I have applied this to 4.2.

You've not updated QEMU_TAG.

Ian.



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

From xen-devel-bounces@lists.xen.org Mon Sep 03 09:46:45 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Sep 2012 09: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 1T8TEk-0007N7-Cf; Mon, 03 Sep 2012 09:46: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 1T8TEj-0007Mt-9E
	for xen-devel@lists.xen.org; Mon, 03 Sep 2012 09:46:29 +0000
Received: from [85.158.143.99:22461] by server-2.bemta-4.messagelabs.com id
	77/AA-21239-47C74405; Mon, 03 Sep 2012 09:46:28 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1346665587!20661815!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTEzODI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21544 invoked from network); 3 Sep 2012 09:46:28 -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;
	3 Sep 2012 09:46:28 -0000
X-IronPort-AV: E=Sophos;i="4.80,359,1344211200"; d="scan'208";a="14312946"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Sep 2012 09:46: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.279.1; Mon, 3 Sep 2012
	10:46:27 +0100
Message-ID: <1346665586.25864.5.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Kirk Allan <kallan@suse.com>
Date: Mon, 3 Sep 2012 10:46:26 +0100
In-Reply-To: <5040A73502000076000B3B82@novprvoes0310.provo.novell.com>
References: <1344935141.5926.6.camel@zakaz.uk.xensource.com>
	<20120814100704.GA19704@bloms.de>
	<1346421542.27277.218.camel@zakaz.uk.xensource.com>
	<1346425278.27277.224.camel@zakaz.uk.xensource.com>
	<5040F7140200007800097E91@nat28.tlf.novell.com>
	<1346428292.27277.243.camel@zakaz.uk.xensource.com>
	<5040FB490200007800097ED2@nat28.tlf.novell.com>
	<50409CE002000076000B3B44@novprvoes0310.provo.novell.com>
	<1346434547.5820.10.camel@dagon.hellion.org.uk>
	<5040A73502000076000B3B82@novprvoes0310.provo.novell.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Charles Arnold <CARNOLD@suse.com>, DieterBloms <xensource.com@bloms.de>,
	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-users] Xen 4.2 TODO (io and irq parameter are
 not evaluated by xl)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-08-31 at 18:59 +0100, Kirk Allan wrote:
> 
> >>> On 8/31/2012 at 11:35 AM, in message
> <1346434547.5820.10.camel@dagon.hellion.org.uk>, Ian Campbell
> <Ian.Campbell@citrix.com> wrote: 
> > On Fri, 2012-08-31 at 18:15 +0100, Kirk Allan wrote:
> > 
> >> > Charles, Kirk, could you comment here?
> >> 
> >> In one of my Window's vm config files, I was able to get the vm to
> >> boot using ioports=['3f8-3ff'].  My goal was to do serial debugging of
> >> the Windows vm.  I also added irq=[4] to the config file.  However, I
> >> was not able to actually get a debug session to work.  The physical
> >> machine running windbg received a string from the vm which gave me
> >> hope that it was working, but then it never received further data so
> >> the vm eventually booted without being attached to the debugger.
> > 
> > Thanks, the question was whether it would be useful to implement the
> > 	ioports = '3f8-3ff'
> > 	irq = 4
> > syntax as well as the
> > 	ioports = ['3f8-3ff']
> > 	irq = [4]
> > but it looks like you are actually using the array version anyway?
> 
> I first looked at this last week.  I found reference to both formats
> so I tried both.  I was only able to get the ioports = ['3f8-3ff'] and
> irq = [4] syntax to allow a vm to boot.

Thanks for confirming.

> > I think I'd rather avoid implementing both options unless there is a
> > strong reason to do so.
> 
> For me, I don't have a strong reason to implement support for both ways.  

I'll happily not bother then ;-)



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

From xen-devel-bounces@lists.xen.org Mon Sep 03 09:46:45 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Sep 2012 09: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 1T8TEk-0007N7-Cf; Mon, 03 Sep 2012 09:46: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 1T8TEj-0007Mt-9E
	for xen-devel@lists.xen.org; Mon, 03 Sep 2012 09:46:29 +0000
Received: from [85.158.143.99:22461] by server-2.bemta-4.messagelabs.com id
	77/AA-21239-47C74405; Mon, 03 Sep 2012 09:46:28 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1346665587!20661815!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTEzODI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21544 invoked from network); 3 Sep 2012 09:46:28 -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;
	3 Sep 2012 09:46:28 -0000
X-IronPort-AV: E=Sophos;i="4.80,359,1344211200"; d="scan'208";a="14312946"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Sep 2012 09:46: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.279.1; Mon, 3 Sep 2012
	10:46:27 +0100
Message-ID: <1346665586.25864.5.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Kirk Allan <kallan@suse.com>
Date: Mon, 3 Sep 2012 10:46:26 +0100
In-Reply-To: <5040A73502000076000B3B82@novprvoes0310.provo.novell.com>
References: <1344935141.5926.6.camel@zakaz.uk.xensource.com>
	<20120814100704.GA19704@bloms.de>
	<1346421542.27277.218.camel@zakaz.uk.xensource.com>
	<1346425278.27277.224.camel@zakaz.uk.xensource.com>
	<5040F7140200007800097E91@nat28.tlf.novell.com>
	<1346428292.27277.243.camel@zakaz.uk.xensource.com>
	<5040FB490200007800097ED2@nat28.tlf.novell.com>
	<50409CE002000076000B3B44@novprvoes0310.provo.novell.com>
	<1346434547.5820.10.camel@dagon.hellion.org.uk>
	<5040A73502000076000B3B82@novprvoes0310.provo.novell.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Charles Arnold <CARNOLD@suse.com>, DieterBloms <xensource.com@bloms.de>,
	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-users] Xen 4.2 TODO (io and irq parameter are
 not evaluated by xl)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-08-31 at 18:59 +0100, Kirk Allan wrote:
> 
> >>> On 8/31/2012 at 11:35 AM, in message
> <1346434547.5820.10.camel@dagon.hellion.org.uk>, Ian Campbell
> <Ian.Campbell@citrix.com> wrote: 
> > On Fri, 2012-08-31 at 18:15 +0100, Kirk Allan wrote:
> > 
> >> > Charles, Kirk, could you comment here?
> >> 
> >> In one of my Window's vm config files, I was able to get the vm to
> >> boot using ioports=['3f8-3ff'].  My goal was to do serial debugging of
> >> the Windows vm.  I also added irq=[4] to the config file.  However, I
> >> was not able to actually get a debug session to work.  The physical
> >> machine running windbg received a string from the vm which gave me
> >> hope that it was working, but then it never received further data so
> >> the vm eventually booted without being attached to the debugger.
> > 
> > Thanks, the question was whether it would be useful to implement the
> > 	ioports = '3f8-3ff'
> > 	irq = 4
> > syntax as well as the
> > 	ioports = ['3f8-3ff']
> > 	irq = [4]
> > but it looks like you are actually using the array version anyway?
> 
> I first looked at this last week.  I found reference to both formats
> so I tried both.  I was only able to get the ioports = ['3f8-3ff'] and
> irq = [4] syntax to allow a vm to boot.

Thanks for confirming.

> > I think I'd rather avoid implementing both options unless there is a
> > strong reason to do so.
> 
> For me, I don't have a strong reason to implement support for both ways.  

I'll happily not bother then ;-)



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

From xen-devel-bounces@lists.xen.org Mon Sep 03 10:11:30 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Sep 2012 10: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 1T8Tca-0007rV-Iy; Mon, 03 Sep 2012 10:11: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 1T8TcY-0007rQ-WC
	for xen-devel@lists.xen.org; Mon, 03 Sep 2012 10:11:07 +0000
Received: from [85.158.143.35:49467] by server-2.bemta-4.messagelabs.com id
	93/3D-21239-A3284405; Mon, 03 Sep 2012 10:11:06 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1346667054!13822691!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTEzODI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31862 invoked from network); 3 Sep 2012 10:10:55 -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;
	3 Sep 2012 10:10:55 -0000
X-IronPort-AV: E=Sophos;i="4.80,359,1344211200"; d="scan'208";a="14313652"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Sep 2012 10:10: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.279.1; Mon, 3 Sep 2012
	11:10:54 +0100
Message-ID: <1346667053.25864.21.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: Mon, 3 Sep 2012 11:10:53 +0100
In-Reply-To: <20120902053549.GF8912@reaktio.net>
References: <20120902053549.GF8912@reaktio.net>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] xl.cfg: gfx_passthru documentation
 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="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gU3VuLCAyMDEyLTA5LTAyIGF0IDA2OjM1ICswMTAwLCBQYXNpIEvDpHJra8OkaW5lbiB3cm90
ZToKPiBIZWxsbywKPiAKPiB4bC5jZmcucG9kLjUgZG9jdW1lbnRhdGlvbiBpbXByb3ZlbWVudHM6
Cj4gCj4gLSBnZnhfcGFzc3RocnU6IERvY3VtZW50IGdmeF9wYXNzdGhydSBtYWtlcyB0aGUgR1BV
IGJlY29tZSBwcmltYXJ5IGluIHRoZSBndWVzdAo+ICAgYW5kIG90aGVyIGdlbmVyaWMgaW5mbyBh
Ym91dCBnZnhfcGFzc3RocnUuCj4gCj4gCj4gU2lnbmVkLW9mZi1ieTogUGFzaSBLw6Rya2vDpGlu
ZW4gPHBhc2lrQGlraS5maT4KPiAtLS0gZG9jcy9tYW4veGwuY2ZnLnBvZC41Lm9yaWcxIDIwMTIt
MDktMDIgMDc6MTY6MzkuMzE2NzgyMTU4ICswMzAwCj4gKysrIGRvY3MvbWFuL3hsLmNmZy5wb2Qu
NSAgICAgICAyMDEyLTA5LTAyIDA4OjI2OjQwLjA4MTYzOTA4NyArMDMwMAo+IEBAIC05NjgsNyAr
OTY4LDQzIEBACj4gIAo+ICA9aXRlbSBCPGdmeF9wYXNzdGhydT1CT09MRUFOPgo+ICAKPiAtRW5h
YmxlIGdyYXBoaWNzIGRldmljZSBQQ0kgcGFzc3Rocm91Z2guIFhYWCB3aGljaCBkZXZpY2UgaXMg
cGFzc2VkIHRocm91Z2ggPwo+ICtFbmFibGUgZ3JhcGhpY3MgZGV2aWNlIFBDSSBwYXNzdGhyb3Vn
aC4gVGhpcyBvcHRpb24gbWFrZXMgdGhlIHBhc3N0aHJ1Cj4gK2dyYXBoaWNzIGNhcmQgYmVjb21l
IHByaW1hcnkgZ3JhcGhpY3MgY2FyZCBpbiB0aGUgVk0sCgpUaGUgb3B0aW9uIGlzIHNsaWdodGx5
IG1pc25hbWVkIHRoZW4gSSBndWVzcywgYSBiZXR0ZXIgbmFtZSB3b3VsZCBoYXZlCmJlZW4gZ2Z4
X3Bhc3N0aHJ1X3ByaW1hcnk/IG9oIHdlbGwsIHdlIGFyZSBzdHVjayB3aXRoIGl0IG5vdy4KCihB
bSBJIGFsb25lIGluIHRoaW5raW5nIHRoYXQgInRocnUiIGlzIGEgaG9ycmlibGUgYWx0ZXJuYXRp
dmUgdG8KdGhyb3VnaD8pCgo+ICBzbyB0aGUgUWVtdSBlbXVsYXRlZCAKPiArZ3JhcGhpY3MgYWRh
cHRlciBpcyBkaXNhYmxlZCwgYW5kIHRoZSBWTkMgY29uc29sZSBmb3IgdGhlIFZNIHdvbid0IGhh
dmUKPiArYW55IGdyYXBoaWNzIG91dHB1dC4gQWxsIGdyYXBoaWNzIG91dHB1dCwgaW5jbHVkaW5n
IGJvb3QgdGltZSBRZW11IEJJT1MKPiArbWVzc2FnZXMgZnJvbSB0aGUgVk0sIHdpbGwgZ28gdG8g
dGhlIHBoeXNpY2FsIG91dHB1dHMgb2YgdGhlIHBhc3NlZCB0aHJ1Cj4gK3BoeXNpY2FsIGdyYXBo
aWNzIGNhcmQuCj4gKwo+ICtHcmFwaGljcyBjYXJkIFBDSSBkZXZpY2UgdG8gcGFzc3RocnUgaXMg
Y2hvc2VuIHdpdGggQjxwY2k+IG9wdGlvbiwgCj4gK2V4YWN0bHkgaW4gdGhlIHNhbWUgd2F5IGFz
IG5vcm1hbCBYZW4gUENJIGRldmljZSBwYXNzdGhydS9hc3NpZ25tZW50IGlzIGRvbmUuIAo+ICtO
b3RlIHRoYXQgZ2Z4X3Bhc3N0aHJ1IGRvZXNuJ3QgZG8gYW55IGtpbmQgb2Ygc2hhcmluZwo+ICtv
ZiB0aGUgR1BVLCBzbyB5b3UgY2FuIG9ubHkgYXNzaWduIHRoZSBHUFUgdG8gb25lIHNpbmdsZSBW
TSBhdCBhIHRpbWUuCj4gKwo+ICtnZnhfcGFzc3RocnUgYWxzbyBlbmFibGVzIHZhcmlvdXMgbGVn
YWN5IFZHQSBtZW1vcnkgcmFuZ2VzLCBCQVJzLCBNTUlPcywgCj4gK2FuZCBpb3BvcnRzIHRvIGJl
IHBhc3NlZCB0aHJ1IHRvIHRoZSBWTSwgc2luY2UgdGhvc2UgYXJlIHJlcXVpcmVkCj4gK2ZvciBj
b3JyZWN0IG9wZXJhdGlvbiBvZiB0aGluZ3MgbGlrZSBWR0EgQklPUywgdGV4dCBtb2RlLCBWQkUs
IGV0Yy4KPiArCj4gK0VuYWJsaW5nIGdmeF9wYXNzdGhydSBvcHRpb24gYWxzbyBjb3BpZXMgdGhl
IHBoeXNpY2FsIGdyYXBoaWNzIGNhcmQgCj4gK3ZpZGVvIGJpb3MgdG8gdGhlIGd1ZXN0IG1lbW9y
eSwgYW5kIGV4ZWN1dGVzIHRoZSB2YmlvcyBpbiB0aGUgZ3Vlc3QgCgoiQklPUyIgYW5kIChJIGV4
cGVjdCkgIlZCSU9TIj8KCj4gK3RvIGdldCB0aGUgZ3JhcGhpY3MgY2FyZCBpbml0aWFsaXplZC4K
PiArCj4gK01vc3QgZ3JhcGhpY3MgYWRhcHRlcnMgcmVxdWlyZSB2ZW5kb3Igc3BlY2lmaWMgdHdl
YWtzIGZvciBwcm9wZXJseQo+ICt3b3JraW5nIGdyYXBoaWNzIHBhc3N0aHJ1LiBYZW4gY3VycmVu
dGx5IGluY2x1ZGVzIG5lY2Vzc2FyeSB0d2Vha3MKPiArZm9yIEludGVsIElHRCAoSW50ZWdyYXRl
ZCBHcmFwaGljcyBEZXZpY2UpIEdQVXMuICAKPiArCj4gK1N1cHBvcnQgZm9yIEFNRC9OdmlkaWEg
Z2Z4X3Bhc3N0aHJ1IGlzIG5vdCB5ZXQgbWVyZ2VkIHRvIFhlbiwKPiArYnV0IHRoZXJlIGFyZSBv
dXQtb2YtdHJlZSBwYXRjaGVzIGF2YWlsYWJsZS4KCklmIHRoZXJlIGlzIGEgY29tcHJlaGVuc2l2
ZSBsaXN0IG9mIHN1cHBvcnRlZC9ub3Qtc3VwcG9ydGVkIGRldmljZXMgb24KdGhlIHdpa2kgdGhl
biBJIHRoaW5rIGEgcmVmZXJlbmNlIGhlcmUgd291bGQgYmUgbW9yZSB1c2VmdWwgdGhhbiB0aGVz
ZQp0d28gYnJpZWYgcGFyYWdyYXBocy4KCkluIHBhcnRpY3VsYXIgdGhlIHNlY29uZCBpc24ndCB2
ZXJ5IHVzZWZ1bCB3aXRob3V0IGxpbmtzIGFuZCB0aG9zZSB0ZW5kCnRvIGJlY29tZSBvdXQgb2Yg
ZGF0ZSBpbiBkb2NzIElNRSwgSSB3b3VsZCB0ZW5kIHRvIG9taXQgdGhpcyBmcm9tIGhlcmUKYW5k
IGluc3RlYWQgaW5jbHVkZSB0aGVtIGluIHRoZSB3aWtpIHdoZXJlIHRoZXkgY2FuIGJlIGtlcHQg
dXAgdG8gZGF0ZQoob3IgYmV0dGVyIHlldCBzb21lYm9keSBjb3VsZCBmaW5hbGx5IHN1Ym1pdCB0
aGUgcGF0Y2hlcyBmb3IgaW5jbHVzaW9uKS4KCj4gK2dmeF9wYXNzdGhydSBpcyBjdXJyZW50bHkg
b25seSBzdXBwb3J0ZWQgd2l0aCB0aGUgcWVtdS14ZW4tdHJhZGl0aW9uYWwKPiArZGV2aWNlLW1v
ZGVsLiBVcHN0cmVhbSBxZW11LXhlbiBkZXZpY2UtbW9kZWwgY3VycmVudGx5IGRvZXNuJ3QgaGF2
ZQo+ICtzdXBwb3J0IGZvciBnZnhfcGFzc3RocnUuCj4gKwo+ICtOb3RlIHRoYXQgc29tZSBncmFw
aGljcyBhZGFwdGVycyAoQU1EL0FUSSBjYXJkcywgZm9yIGV4YW1wbGUpIGRvbid0Cj4gK25lY2Vz
c2FyaWx5IHJlcXVpcmUgZ2Z4X3Bhc3N0aHJ1IG9wdGlvbiwgc28geW91IGNhbiB1c2UgdGhlIG5v
cm1hbAo+ICtYZW4gUENJIHBhc3N0aHJ1IHRvIGFzc2lnbiB0aGUgZ3JhcGhpY3MgY2FyZCBhcyBh
IHNlY29uZGFyeSBncmFwaGljcyBjYXJkCj4gK3RvIHRoZSBWTS4gUWVtdSBlbXVsYXRlZCBncmFw
aGljcyBjYXJkIHN0YXlzIGFzIHRoZSBwcmltYXJ5IGdyYXBoaWNzIGNhcmQsIAo+ICthbmQgeW91
IGdldCBWTkMgb3V0cHV0IGZyb20gdGhlIFFlbXUtZW11bGF0ZWQgcHJpbWFyeSBhZGFwdGVyLgo+
ICsKPiAgCj4gID1pdGVtIEI8bm9taWdyYXRlPUJPT0xFQU4+Cj4gCgoKCl9fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QK
WGVuLWRldmVsQGxpc3RzLnhlbi5vcmcKaHR0cDovL2xpc3RzLnhlbi5vcmcveGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Mon Sep 03 10:11:30 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Sep 2012 10: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 1T8Tca-0007rV-Iy; Mon, 03 Sep 2012 10:11: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 1T8TcY-0007rQ-WC
	for xen-devel@lists.xen.org; Mon, 03 Sep 2012 10:11:07 +0000
Received: from [85.158.143.35:49467] by server-2.bemta-4.messagelabs.com id
	93/3D-21239-A3284405; Mon, 03 Sep 2012 10:11:06 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1346667054!13822691!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTEzODI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31862 invoked from network); 3 Sep 2012 10:10:55 -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;
	3 Sep 2012 10:10:55 -0000
X-IronPort-AV: E=Sophos;i="4.80,359,1344211200"; d="scan'208";a="14313652"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Sep 2012 10:10: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.279.1; Mon, 3 Sep 2012
	11:10:54 +0100
Message-ID: <1346667053.25864.21.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: Mon, 3 Sep 2012 11:10:53 +0100
In-Reply-To: <20120902053549.GF8912@reaktio.net>
References: <20120902053549.GF8912@reaktio.net>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] xl.cfg: gfx_passthru documentation
 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="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gU3VuLCAyMDEyLTA5LTAyIGF0IDA2OjM1ICswMTAwLCBQYXNpIEvDpHJra8OkaW5lbiB3cm90
ZToKPiBIZWxsbywKPiAKPiB4bC5jZmcucG9kLjUgZG9jdW1lbnRhdGlvbiBpbXByb3ZlbWVudHM6
Cj4gCj4gLSBnZnhfcGFzc3RocnU6IERvY3VtZW50IGdmeF9wYXNzdGhydSBtYWtlcyB0aGUgR1BV
IGJlY29tZSBwcmltYXJ5IGluIHRoZSBndWVzdAo+ICAgYW5kIG90aGVyIGdlbmVyaWMgaW5mbyBh
Ym91dCBnZnhfcGFzc3RocnUuCj4gCj4gCj4gU2lnbmVkLW9mZi1ieTogUGFzaSBLw6Rya2vDpGlu
ZW4gPHBhc2lrQGlraS5maT4KPiAtLS0gZG9jcy9tYW4veGwuY2ZnLnBvZC41Lm9yaWcxIDIwMTIt
MDktMDIgMDc6MTY6MzkuMzE2NzgyMTU4ICswMzAwCj4gKysrIGRvY3MvbWFuL3hsLmNmZy5wb2Qu
NSAgICAgICAyMDEyLTA5LTAyIDA4OjI2OjQwLjA4MTYzOTA4NyArMDMwMAo+IEBAIC05NjgsNyAr
OTY4LDQzIEBACj4gIAo+ICA9aXRlbSBCPGdmeF9wYXNzdGhydT1CT09MRUFOPgo+ICAKPiAtRW5h
YmxlIGdyYXBoaWNzIGRldmljZSBQQ0kgcGFzc3Rocm91Z2guIFhYWCB3aGljaCBkZXZpY2UgaXMg
cGFzc2VkIHRocm91Z2ggPwo+ICtFbmFibGUgZ3JhcGhpY3MgZGV2aWNlIFBDSSBwYXNzdGhyb3Vn
aC4gVGhpcyBvcHRpb24gbWFrZXMgdGhlIHBhc3N0aHJ1Cj4gK2dyYXBoaWNzIGNhcmQgYmVjb21l
IHByaW1hcnkgZ3JhcGhpY3MgY2FyZCBpbiB0aGUgVk0sCgpUaGUgb3B0aW9uIGlzIHNsaWdodGx5
IG1pc25hbWVkIHRoZW4gSSBndWVzcywgYSBiZXR0ZXIgbmFtZSB3b3VsZCBoYXZlCmJlZW4gZ2Z4
X3Bhc3N0aHJ1X3ByaW1hcnk/IG9oIHdlbGwsIHdlIGFyZSBzdHVjayB3aXRoIGl0IG5vdy4KCihB
bSBJIGFsb25lIGluIHRoaW5raW5nIHRoYXQgInRocnUiIGlzIGEgaG9ycmlibGUgYWx0ZXJuYXRp
dmUgdG8KdGhyb3VnaD8pCgo+ICBzbyB0aGUgUWVtdSBlbXVsYXRlZCAKPiArZ3JhcGhpY3MgYWRh
cHRlciBpcyBkaXNhYmxlZCwgYW5kIHRoZSBWTkMgY29uc29sZSBmb3IgdGhlIFZNIHdvbid0IGhh
dmUKPiArYW55IGdyYXBoaWNzIG91dHB1dC4gQWxsIGdyYXBoaWNzIG91dHB1dCwgaW5jbHVkaW5n
IGJvb3QgdGltZSBRZW11IEJJT1MKPiArbWVzc2FnZXMgZnJvbSB0aGUgVk0sIHdpbGwgZ28gdG8g
dGhlIHBoeXNpY2FsIG91dHB1dHMgb2YgdGhlIHBhc3NlZCB0aHJ1Cj4gK3BoeXNpY2FsIGdyYXBo
aWNzIGNhcmQuCj4gKwo+ICtHcmFwaGljcyBjYXJkIFBDSSBkZXZpY2UgdG8gcGFzc3RocnUgaXMg
Y2hvc2VuIHdpdGggQjxwY2k+IG9wdGlvbiwgCj4gK2V4YWN0bHkgaW4gdGhlIHNhbWUgd2F5IGFz
IG5vcm1hbCBYZW4gUENJIGRldmljZSBwYXNzdGhydS9hc3NpZ25tZW50IGlzIGRvbmUuIAo+ICtO
b3RlIHRoYXQgZ2Z4X3Bhc3N0aHJ1IGRvZXNuJ3QgZG8gYW55IGtpbmQgb2Ygc2hhcmluZwo+ICtv
ZiB0aGUgR1BVLCBzbyB5b3UgY2FuIG9ubHkgYXNzaWduIHRoZSBHUFUgdG8gb25lIHNpbmdsZSBW
TSBhdCBhIHRpbWUuCj4gKwo+ICtnZnhfcGFzc3RocnUgYWxzbyBlbmFibGVzIHZhcmlvdXMgbGVn
YWN5IFZHQSBtZW1vcnkgcmFuZ2VzLCBCQVJzLCBNTUlPcywgCj4gK2FuZCBpb3BvcnRzIHRvIGJl
IHBhc3NlZCB0aHJ1IHRvIHRoZSBWTSwgc2luY2UgdGhvc2UgYXJlIHJlcXVpcmVkCj4gK2ZvciBj
b3JyZWN0IG9wZXJhdGlvbiBvZiB0aGluZ3MgbGlrZSBWR0EgQklPUywgdGV4dCBtb2RlLCBWQkUs
IGV0Yy4KPiArCj4gK0VuYWJsaW5nIGdmeF9wYXNzdGhydSBvcHRpb24gYWxzbyBjb3BpZXMgdGhl
IHBoeXNpY2FsIGdyYXBoaWNzIGNhcmQgCj4gK3ZpZGVvIGJpb3MgdG8gdGhlIGd1ZXN0IG1lbW9y
eSwgYW5kIGV4ZWN1dGVzIHRoZSB2YmlvcyBpbiB0aGUgZ3Vlc3QgCgoiQklPUyIgYW5kIChJIGV4
cGVjdCkgIlZCSU9TIj8KCj4gK3RvIGdldCB0aGUgZ3JhcGhpY3MgY2FyZCBpbml0aWFsaXplZC4K
PiArCj4gK01vc3QgZ3JhcGhpY3MgYWRhcHRlcnMgcmVxdWlyZSB2ZW5kb3Igc3BlY2lmaWMgdHdl
YWtzIGZvciBwcm9wZXJseQo+ICt3b3JraW5nIGdyYXBoaWNzIHBhc3N0aHJ1LiBYZW4gY3VycmVu
dGx5IGluY2x1ZGVzIG5lY2Vzc2FyeSB0d2Vha3MKPiArZm9yIEludGVsIElHRCAoSW50ZWdyYXRl
ZCBHcmFwaGljcyBEZXZpY2UpIEdQVXMuICAKPiArCj4gK1N1cHBvcnQgZm9yIEFNRC9OdmlkaWEg
Z2Z4X3Bhc3N0aHJ1IGlzIG5vdCB5ZXQgbWVyZ2VkIHRvIFhlbiwKPiArYnV0IHRoZXJlIGFyZSBv
dXQtb2YtdHJlZSBwYXRjaGVzIGF2YWlsYWJsZS4KCklmIHRoZXJlIGlzIGEgY29tcHJlaGVuc2l2
ZSBsaXN0IG9mIHN1cHBvcnRlZC9ub3Qtc3VwcG9ydGVkIGRldmljZXMgb24KdGhlIHdpa2kgdGhl
biBJIHRoaW5rIGEgcmVmZXJlbmNlIGhlcmUgd291bGQgYmUgbW9yZSB1c2VmdWwgdGhhbiB0aGVz
ZQp0d28gYnJpZWYgcGFyYWdyYXBocy4KCkluIHBhcnRpY3VsYXIgdGhlIHNlY29uZCBpc24ndCB2
ZXJ5IHVzZWZ1bCB3aXRob3V0IGxpbmtzIGFuZCB0aG9zZSB0ZW5kCnRvIGJlY29tZSBvdXQgb2Yg
ZGF0ZSBpbiBkb2NzIElNRSwgSSB3b3VsZCB0ZW5kIHRvIG9taXQgdGhpcyBmcm9tIGhlcmUKYW5k
IGluc3RlYWQgaW5jbHVkZSB0aGVtIGluIHRoZSB3aWtpIHdoZXJlIHRoZXkgY2FuIGJlIGtlcHQg
dXAgdG8gZGF0ZQoob3IgYmV0dGVyIHlldCBzb21lYm9keSBjb3VsZCBmaW5hbGx5IHN1Ym1pdCB0
aGUgcGF0Y2hlcyBmb3IgaW5jbHVzaW9uKS4KCj4gK2dmeF9wYXNzdGhydSBpcyBjdXJyZW50bHkg
b25seSBzdXBwb3J0ZWQgd2l0aCB0aGUgcWVtdS14ZW4tdHJhZGl0aW9uYWwKPiArZGV2aWNlLW1v
ZGVsLiBVcHN0cmVhbSBxZW11LXhlbiBkZXZpY2UtbW9kZWwgY3VycmVudGx5IGRvZXNuJ3QgaGF2
ZQo+ICtzdXBwb3J0IGZvciBnZnhfcGFzc3RocnUuCj4gKwo+ICtOb3RlIHRoYXQgc29tZSBncmFw
aGljcyBhZGFwdGVycyAoQU1EL0FUSSBjYXJkcywgZm9yIGV4YW1wbGUpIGRvbid0Cj4gK25lY2Vz
c2FyaWx5IHJlcXVpcmUgZ2Z4X3Bhc3N0aHJ1IG9wdGlvbiwgc28geW91IGNhbiB1c2UgdGhlIG5v
cm1hbAo+ICtYZW4gUENJIHBhc3N0aHJ1IHRvIGFzc2lnbiB0aGUgZ3JhcGhpY3MgY2FyZCBhcyBh
IHNlY29uZGFyeSBncmFwaGljcyBjYXJkCj4gK3RvIHRoZSBWTS4gUWVtdSBlbXVsYXRlZCBncmFw
aGljcyBjYXJkIHN0YXlzIGFzIHRoZSBwcmltYXJ5IGdyYXBoaWNzIGNhcmQsIAo+ICthbmQgeW91
IGdldCBWTkMgb3V0cHV0IGZyb20gdGhlIFFlbXUtZW11bGF0ZWQgcHJpbWFyeSBhZGFwdGVyLgo+
ICsKPiAgCj4gID1pdGVtIEI8bm9taWdyYXRlPUJPT0xFQU4+Cj4gCgoKCl9fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QK
WGVuLWRldmVsQGxpc3RzLnhlbi5vcmcKaHR0cDovL2xpc3RzLnhlbi5vcmcveGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Mon Sep 03 10:19:28 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Sep 2012 10:19:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T8TkH-00082u-GM; Mon, 03 Sep 2012 10:19:05 +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 1T8TkG-00082p-7t
	for xen-devel@lists.xen.org; Mon, 03 Sep 2012 10:19:04 +0000
Received: from [85.158.138.51:51190] by server-6.bemta-3.messagelabs.com id
	B8/BF-29694-71484405; Mon, 03 Sep 2012 10:19:03 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1346667537!28256993!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDczNDQ3MA==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15650 invoked from network); 3 Sep 2012 10:18:59 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-4.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 3 Sep 2012 10:18:59 -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 q83AIoBq010593
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 3 Sep 2012 10:18:50 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
	q83AIna5029419
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 3 Sep 2012 10:18:49 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
	q83AImJq005330; Mon, 3 Sep 2012 05:18:48 -0500
Received: from localhost.localdomain (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 03 Sep 2012 03:18:48 -0700
Date: Mon, 3 Sep 2012 06:18:46 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20120903101845.GB26347@localhost.localdomain>
References: <1B4B44D9196EFF41AE41FDA404FC0A1018AF31@SHSMSX101.ccr.corp.intel.com>
	<20120831172410.GA19756@localhost.localdomain>
	<50447C3202000078000982A0@nat28.tlf.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <50447C3202000078000982A0@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@kernel.org>,
	Yongjie Ren <yongjie.ren@intel.com>, 'Keir Fraser' <keir@xen.org>,
	'Ian Campbell' <Ian.Campbell@citrix.com>,
	'xen-devel' <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen4.2-rc3 test result
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Sep 03, 2012 at 08:45:22AM +0100, Jan Beulich wrote:
> >>> On 31.08.12 at 19:24, Konrad Rzeszutek Wilk <konrad@kernel.org> wrote:
> > On Fri, Aug 31, 2012 at 07:27:51AM +0000, Ren, Yongjie wrote:
> >> 6. Guest hang after resuming from S3
> >>   http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1828 
> > 
> > Jan posted some patches to fix that. Can you test with an up-to-date
> > guest? (so not RHEL6U1 which does not have the fix).
> 
> Did I? I don't recall..

r8605067 xen-blkfront: module exit handling adjustments
e77c78c xen-blkfront: properly name all devices
569ca5b xen/gnttab: add deferred freeing logic

> 
> Jan
> 

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

From xen-devel-bounces@lists.xen.org Mon Sep 03 10:19:28 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Sep 2012 10:19:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T8TkH-00082u-GM; Mon, 03 Sep 2012 10:19:05 +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 1T8TkG-00082p-7t
	for xen-devel@lists.xen.org; Mon, 03 Sep 2012 10:19:04 +0000
Received: from [85.158.138.51:51190] by server-6.bemta-3.messagelabs.com id
	B8/BF-29694-71484405; Mon, 03 Sep 2012 10:19:03 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1346667537!28256993!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDczNDQ3MA==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15650 invoked from network); 3 Sep 2012 10:18:59 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-4.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 3 Sep 2012 10:18:59 -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 q83AIoBq010593
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 3 Sep 2012 10:18:50 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
	q83AIna5029419
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 3 Sep 2012 10:18:49 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
	q83AImJq005330; Mon, 3 Sep 2012 05:18:48 -0500
Received: from localhost.localdomain (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 03 Sep 2012 03:18:48 -0700
Date: Mon, 3 Sep 2012 06:18:46 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20120903101845.GB26347@localhost.localdomain>
References: <1B4B44D9196EFF41AE41FDA404FC0A1018AF31@SHSMSX101.ccr.corp.intel.com>
	<20120831172410.GA19756@localhost.localdomain>
	<50447C3202000078000982A0@nat28.tlf.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <50447C3202000078000982A0@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@kernel.org>,
	Yongjie Ren <yongjie.ren@intel.com>, 'Keir Fraser' <keir@xen.org>,
	'Ian Campbell' <Ian.Campbell@citrix.com>,
	'xen-devel' <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen4.2-rc3 test result
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Sep 03, 2012 at 08:45:22AM +0100, Jan Beulich wrote:
> >>> On 31.08.12 at 19:24, Konrad Rzeszutek Wilk <konrad@kernel.org> wrote:
> > On Fri, Aug 31, 2012 at 07:27:51AM +0000, Ren, Yongjie wrote:
> >> 6. Guest hang after resuming from S3
> >>   http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1828 
> > 
> > Jan posted some patches to fix that. Can you test with an up-to-date
> > guest? (so not RHEL6U1 which does not have the fix).
> 
> Did I? I don't recall..

r8605067 xen-blkfront: module exit handling adjustments
e77c78c xen-blkfront: properly name all devices
569ca5b xen/gnttab: add deferred freeing logic

> 
> Jan
> 

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

From xen-devel-bounces@lists.xen.org Mon Sep 03 10:23:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Sep 2012 10:23:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T8Tnu-0008Bo-A6; Mon, 03 Sep 2012 10:22: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 1T8Tnt-0008Bj-8R
	for xen-devel@lists.xen.org; Mon, 03 Sep 2012 10:22:49 +0000
Received: from [85.158.139.83:61772] by server-11.bemta-5.messagelabs.com id
	2E/22-24658-8F484405; Mon, 03 Sep 2012 10:22:48 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1346667767!28038877!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTEzODI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10320 invoked from network); 3 Sep 2012 10:22:48 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Sep 2012 10:22:48 -0000
X-IronPort-AV: E=Sophos;i="4.80,359,1344211200"; d="scan'208";a="14314083"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Sep 2012 10:22: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.279.1; Mon, 3 Sep 2012
	11:22:47 +0100
Message-ID: <1346667766.25864.22.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: Mon, 3 Sep 2012 11:22:46 +0100
In-Reply-To: <20120902044115.GD8912@reaktio.net>
References: <20120902044115.GD8912@reaktio.net>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] xl.cfg: videoram and stdvga documentation
 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="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gU3VuLCAyMDEyLTA5LTAyIGF0IDA1OjQxICswMTAwLCBQYXNpIEvDpHJra8OkaW5lbiB3cm90
ZToKPiBIZWxsbywKPiAKPiB4bC5jZmcucG9kLjUgZG9jdW1lbnRhdGlvbiB0d2Vha3MvaW1wcm92
ZW1lbnRzOgo+IAo+IC0gdmlkZW9yYW06IERvY3VtZW50IHRoYXQgb25seSBxZW11LXhlbi10cmFk
aXRpb25hbCBkZXZpY2UtbW9kZWwgY3VycmVudGx5Cj4gICAgc3VwcG9ydHMgY2hhbmdpbmcgdGhl
IGFtb3VudCBvZiB2aWRlbyBtZW1vcnkgZm9yIHN0ZHZnYSBncmFwaGljcyBkZXZpY2UuCj4gCj4g
LSB2aWRlb3JhbTogQmV0dGVyIGRvY3VtZW50IHRoZSBkZWZhdWx0IGFtb3VudCBvZiB2aWRlb3Jh
bSBmb3IgYm90aCBzdGR2Z2EKPiAgIGFuZCBDaXJydXMuCj4gCj4gLSBzdGR2Z2E6IEFkZCBhIG5v
dGUgdGhhdCBzdGR2Z2EgYWxsb3dzIGJpZ2dlciBhbW91bnQgb2YgdmlkZW9yYW0gYW5kCj4gICBi
aWdnZXIgcmVzb2x1dGlvbnMuCj4gCj4gCj4gU2lnbmVkLW9mZi1ieTogUGFzaSBLw6Rya2vDpGlu
ZW4gPHBhc2lrQGlraS5maT4KCkFja2VkLWJ5OiBJYW4gQ2FtcGJlbGwgPGlhbi5jYW1wYmVsbEBj
aXRyaXguY29tPgoKYW5kIGFwcGxpZWQsIHRoYW5rcyBQYXNpLgoKSSBzdHJpcHBlZCBzb21lIG5l
dyB0cmFpbGluZyB3aGl0ZXNwYWNlIGFzIEkgd2VudC4KCgoKX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2
ZWxAbGlzdHMueGVuLm9yZwpodHRwOi8vbGlzdHMueGVuLm9yZy94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xen.org Mon Sep 03 10:23:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Sep 2012 10:23:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T8Tnu-0008Bo-A6; Mon, 03 Sep 2012 10:22: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 1T8Tnt-0008Bj-8R
	for xen-devel@lists.xen.org; Mon, 03 Sep 2012 10:22:49 +0000
Received: from [85.158.139.83:61772] by server-11.bemta-5.messagelabs.com id
	2E/22-24658-8F484405; Mon, 03 Sep 2012 10:22:48 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1346667767!28038877!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTEzODI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10320 invoked from network); 3 Sep 2012 10:22:48 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Sep 2012 10:22:48 -0000
X-IronPort-AV: E=Sophos;i="4.80,359,1344211200"; d="scan'208";a="14314083"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Sep 2012 10:22: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.279.1; Mon, 3 Sep 2012
	11:22:47 +0100
Message-ID: <1346667766.25864.22.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: Mon, 3 Sep 2012 11:22:46 +0100
In-Reply-To: <20120902044115.GD8912@reaktio.net>
References: <20120902044115.GD8912@reaktio.net>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] xl.cfg: videoram and stdvga documentation
 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="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gU3VuLCAyMDEyLTA5LTAyIGF0IDA1OjQxICswMTAwLCBQYXNpIEvDpHJra8OkaW5lbiB3cm90
ZToKPiBIZWxsbywKPiAKPiB4bC5jZmcucG9kLjUgZG9jdW1lbnRhdGlvbiB0d2Vha3MvaW1wcm92
ZW1lbnRzOgo+IAo+IC0gdmlkZW9yYW06IERvY3VtZW50IHRoYXQgb25seSBxZW11LXhlbi10cmFk
aXRpb25hbCBkZXZpY2UtbW9kZWwgY3VycmVudGx5Cj4gICAgc3VwcG9ydHMgY2hhbmdpbmcgdGhl
IGFtb3VudCBvZiB2aWRlbyBtZW1vcnkgZm9yIHN0ZHZnYSBncmFwaGljcyBkZXZpY2UuCj4gCj4g
LSB2aWRlb3JhbTogQmV0dGVyIGRvY3VtZW50IHRoZSBkZWZhdWx0IGFtb3VudCBvZiB2aWRlb3Jh
bSBmb3IgYm90aCBzdGR2Z2EKPiAgIGFuZCBDaXJydXMuCj4gCj4gLSBzdGR2Z2E6IEFkZCBhIG5v
dGUgdGhhdCBzdGR2Z2EgYWxsb3dzIGJpZ2dlciBhbW91bnQgb2YgdmlkZW9yYW0gYW5kCj4gICBi
aWdnZXIgcmVzb2x1dGlvbnMuCj4gCj4gCj4gU2lnbmVkLW9mZi1ieTogUGFzaSBLw6Rya2vDpGlu
ZW4gPHBhc2lrQGlraS5maT4KCkFja2VkLWJ5OiBJYW4gQ2FtcGJlbGwgPGlhbi5jYW1wYmVsbEBj
aXRyaXguY29tPgoKYW5kIGFwcGxpZWQsIHRoYW5rcyBQYXNpLgoKSSBzdHJpcHBlZCBzb21lIG5l
dyB0cmFpbGluZyB3aGl0ZXNwYWNlIGFzIEkgd2VudC4KCgoKX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2
ZWxAbGlzdHMueGVuLm9yZwpodHRwOi8vbGlzdHMueGVuLm9yZy94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xen.org Mon Sep 03 10:23:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Sep 2012 10:23:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T8To3-0008CS-MA; Mon, 03 Sep 2012 10:22: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 1T8To2-0008CI-7P
	for xen-devel@lists.xen.org; Mon, 03 Sep 2012 10:22:58 +0000
Received: from [85.158.138.51:2079] by server-12.bemta-3.messagelabs.com id
	2A/97-10384-10584405; Mon, 03 Sep 2012 10:22:57 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1346667774!28191401!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTEzODI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22311 invoked from network); 3 Sep 2012 10:22:55 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Sep 2012 10:22:55 -0000
X-IronPort-AV: E=Sophos;i="4.80,359,1344211200"; d="scan'208";a="14314084"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Sep 2012 10:22: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.279.1; Mon, 3 Sep 2012
	11:22:54 +0100
Message-ID: <1346667773.25864.23.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Mon, 3 Sep 2012 11:22:53 +0100
In-Reply-To: <1346427131.27277.238.camel@zakaz.uk.xensource.com>
References: <20544.52351.298163.138907@mariner.uk.xensource.com>
	<1346425084.27277.220.camel@zakaz.uk.xensource.com>
	<20544.54022.744391.866200@mariner.uk.xensource.com>
	<1346425723.27277.228.camel@zakaz.uk.xensource.com>
	<20544.54514.22038.727353@mariner.uk.xensource.com>
	<1346427131.27277.238.camel@zakaz.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] libxl: fix api check 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>
Content-Type: text/plain; charset="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>

And now applied.

Thanks.



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

From xen-devel-bounces@lists.xen.org Mon Sep 03 10:23:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Sep 2012 10:23:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T8To3-0008CS-MA; Mon, 03 Sep 2012 10:22: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 1T8To2-0008CI-7P
	for xen-devel@lists.xen.org; Mon, 03 Sep 2012 10:22:58 +0000
Received: from [85.158.138.51:2079] by server-12.bemta-3.messagelabs.com id
	2A/97-10384-10584405; Mon, 03 Sep 2012 10:22:57 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1346667774!28191401!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTEzODI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22311 invoked from network); 3 Sep 2012 10:22:55 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Sep 2012 10:22:55 -0000
X-IronPort-AV: E=Sophos;i="4.80,359,1344211200"; d="scan'208";a="14314084"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Sep 2012 10:22: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.279.1; Mon, 3 Sep 2012
	11:22:54 +0100
Message-ID: <1346667773.25864.23.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Mon, 3 Sep 2012 11:22:53 +0100
In-Reply-To: <1346427131.27277.238.camel@zakaz.uk.xensource.com>
References: <20544.52351.298163.138907@mariner.uk.xensource.com>
	<1346425084.27277.220.camel@zakaz.uk.xensource.com>
	<20544.54022.744391.866200@mariner.uk.xensource.com>
	<1346425723.27277.228.camel@zakaz.uk.xensource.com>
	<20544.54514.22038.727353@mariner.uk.xensource.com>
	<1346427131.27277.238.camel@zakaz.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] libxl: fix api check 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>
Content-Type: text/plain; charset="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>

And now applied.

Thanks.



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

From xen-devel-bounces@lists.xen.org Mon Sep 03 10:23:22 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Sep 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 1T8ToD-0008Dq-2n; Mon, 03 Sep 2012 10:23: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 1T8ToB-0008DU-2S
	for xen-devel@lists.xen.org; Mon, 03 Sep 2012 10:23:07 +0000
Received: from [85.158.143.99:13773] by server-3.bemta-4.messagelabs.com id
	0D/69-08232-A0584405; Mon, 03 Sep 2012 10:23:06 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1346667785!22958392!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTEzODI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13086 invoked from network); 3 Sep 2012 10:23:05 -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;
	3 Sep 2012 10:23:05 -0000
X-IronPort-AV: E=Sophos;i="4.80,359,1344211200"; d="scan'208";a="14314089"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Sep 2012 10:23: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.279.1; Mon, 3 Sep 2012
	11:23:05 +0100
Message-ID: <1346667784.25864.24.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Mon, 3 Sep 2012 11:23:04 +0100
In-Reply-To: <50448F850200007800098356@nat28.tlf.novell.com>
References: <504470FD0200007800098213@nat28.tlf.novell.com>
	<1346662056.27277.250.camel@zakaz.uk.xensource.com>
	<1346662807.27277.251.camel@zakaz.uk.xensource.com>
	<50448F850200007800098356@nat28.tlf.novell.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] make domain_create() return a proper error
 code
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2012-09-03 at 10:07 +0100, Jan Beulich wrote:
> >>> On 03.09.12 at 11:00, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> >> > @@ -237,7 +238,7 @@ void __init start_xen(unsigned long boot
> >> >  
> >> >      /* Create initial domain 0. */
> >> >      dom0 = domain_create(0, 0, 0);
> >> > -    if ( dom0 == NULL )
> >> > +    if ( IS_ERR(dom0) )
> >> >              printk("domain_create failed\n");
> >> >      if ( (dom0 == NULL) || (alloc_dom0_vcpu0() == NULL) )
> >> 
> >> You probably wanted to change this one too?
> >> 
> >> I'm not sure the first message really buys much -- I'd be happy to nuke
> >> it too.
> > 
> > 8<------------------------
> > 
> > # HG changeset patch
> > # User Ian Campbell <ian.campbell@citrix.com>
> > # Date 1346662775 -3600
> > # Node ID c4e822e1b491bb7efa962b38fff6f007f01596b5
> > # Parent  241186e96a1ece42ad3bd14901b62d872f4abd9e
> > arm: correctly check for error on dom0 allocation
> > 
> > Drop the redundant printk
> > 
> > Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> 
> Thanks and (if you care) ack.

Thanks, I think any ack is worthwhile.

Applied.

> 
> Jan
> 
> > diff -r 241186e96a1e -r c4e822e1b491 xen/arch/arm/setup.c
> > --- a/xen/arch/arm/setup.c	Mon Sep 03 09:57:33 2012 +0100
> > +++ b/xen/arch/arm/setup.c	Mon Sep 03 09:59:35 2012 +0100
> > @@ -238,9 +238,7 @@ void __init start_xen(unsigned long boot
> >  
> >      /* Create initial domain 0. */
> >      dom0 = domain_create(0, 0, 0);
> > -    if ( IS_ERR(dom0) )
> > -            printk("domain_create failed\n");
> > -    if ( (dom0 == NULL) || (alloc_dom0_vcpu0() == NULL) )
> > +    if ( IS_ERR(dom0) || (alloc_dom0_vcpu0() == NULL) )
> >              panic("Error creating domain 0\n");
> >  
> >      dom0->is_privileged = 1;
> 
> 
> 



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

From xen-devel-bounces@lists.xen.org Mon Sep 03 10:23:22 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Sep 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 1T8ToD-0008Dq-2n; Mon, 03 Sep 2012 10:23: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 1T8ToB-0008DU-2S
	for xen-devel@lists.xen.org; Mon, 03 Sep 2012 10:23:07 +0000
Received: from [85.158.143.99:13773] by server-3.bemta-4.messagelabs.com id
	0D/69-08232-A0584405; Mon, 03 Sep 2012 10:23:06 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1346667785!22958392!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTEzODI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13086 invoked from network); 3 Sep 2012 10:23:05 -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;
	3 Sep 2012 10:23:05 -0000
X-IronPort-AV: E=Sophos;i="4.80,359,1344211200"; d="scan'208";a="14314089"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Sep 2012 10:23: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.279.1; Mon, 3 Sep 2012
	11:23:05 +0100
Message-ID: <1346667784.25864.24.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Mon, 3 Sep 2012 11:23:04 +0100
In-Reply-To: <50448F850200007800098356@nat28.tlf.novell.com>
References: <504470FD0200007800098213@nat28.tlf.novell.com>
	<1346662056.27277.250.camel@zakaz.uk.xensource.com>
	<1346662807.27277.251.camel@zakaz.uk.xensource.com>
	<50448F850200007800098356@nat28.tlf.novell.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] make domain_create() return a proper error
 code
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2012-09-03 at 10:07 +0100, Jan Beulich wrote:
> >>> On 03.09.12 at 11:00, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> >> > @@ -237,7 +238,7 @@ void __init start_xen(unsigned long boot
> >> >  
> >> >      /* Create initial domain 0. */
> >> >      dom0 = domain_create(0, 0, 0);
> >> > -    if ( dom0 == NULL )
> >> > +    if ( IS_ERR(dom0) )
> >> >              printk("domain_create failed\n");
> >> >      if ( (dom0 == NULL) || (alloc_dom0_vcpu0() == NULL) )
> >> 
> >> You probably wanted to change this one too?
> >> 
> >> I'm not sure the first message really buys much -- I'd be happy to nuke
> >> it too.
> > 
> > 8<------------------------
> > 
> > # HG changeset patch
> > # User Ian Campbell <ian.campbell@citrix.com>
> > # Date 1346662775 -3600
> > # Node ID c4e822e1b491bb7efa962b38fff6f007f01596b5
> > # Parent  241186e96a1ece42ad3bd14901b62d872f4abd9e
> > arm: correctly check for error on dom0 allocation
> > 
> > Drop the redundant printk
> > 
> > Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> 
> Thanks and (if you care) ack.

Thanks, I think any ack is worthwhile.

Applied.

> 
> Jan
> 
> > diff -r 241186e96a1e -r c4e822e1b491 xen/arch/arm/setup.c
> > --- a/xen/arch/arm/setup.c	Mon Sep 03 09:57:33 2012 +0100
> > +++ b/xen/arch/arm/setup.c	Mon Sep 03 09:59:35 2012 +0100
> > @@ -238,9 +238,7 @@ void __init start_xen(unsigned long boot
> >  
> >      /* Create initial domain 0. */
> >      dom0 = domain_create(0, 0, 0);
> > -    if ( IS_ERR(dom0) )
> > -            printk("domain_create failed\n");
> > -    if ( (dom0 == NULL) || (alloc_dom0_vcpu0() == NULL) )
> > +    if ( IS_ERR(dom0) || (alloc_dom0_vcpu0() == NULL) )
> >              panic("Error creating domain 0\n");
> >  
> >      dom0->is_privileged = 1;
> 
> 
> 



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

From xen-devel-bounces@lists.xen.org Mon Sep 03 10:23:34 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Sep 2012 10:23:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T8ToR-0008HB-Fi; Mon, 03 Sep 2012 10:23: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 1T8ToQ-0008Gc-JX
	for xen-devel@lists.xen.org; Mon, 03 Sep 2012 10:23:22 +0000
Received: from [85.158.143.99:2155] by server-3.bemta-4.messagelabs.com id
	E6/F9-08232-91584405; Mon, 03 Sep 2012 10:23:21 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1346667795!22925268!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTEzODI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31077 invoked from network); 3 Sep 2012 10:23:18 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Sep 2012 10:23:18 -0000
X-IronPort-AV: E=Sophos;i="4.80,359,1344211200"; d="scan'208";a="14314096"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Sep 2012 10: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.279.1; Mon, 3 Sep 2012
	11:23:15 +0100
Message-ID: <1346667794.25864.25.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Mon, 3 Sep 2012 11:23:14 +0100
In-Reply-To: <5044707C020000780009820F@nat28.tlf.novell.com>
References: <5040D05D.8090808@citrix.com>
	<5040F61A0200007800097E86@nat28.tlf.novell.com>
	<5040EB1B.80004@citrix.com>
	<5044707C020000780009820F@nat28.tlf.novell.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-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] (v2) docs/command line: Clarify the behavior with
 invalid input.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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-09-03 at 07:55 +0100, Jan Beulich wrote:
> >>> On 31.08.12 at 18:49, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
> > On 31/08/12 16:36, Jan Beulich wrote:
> >> I don't think we should specifically document the behavior for
> >> unexpected value; instead, the behavior should simply be
> >> "undefined".
> > 
> > Yes ok.  v2 attached.
> 
> Acked-by: Jan Beulich <jbeulich@suse.de>

Applied, thanks.



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

From xen-devel-bounces@lists.xen.org Mon Sep 03 10:23:34 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Sep 2012 10:23:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T8ToR-0008HB-Fi; Mon, 03 Sep 2012 10:23: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 1T8ToQ-0008Gc-JX
	for xen-devel@lists.xen.org; Mon, 03 Sep 2012 10:23:22 +0000
Received: from [85.158.143.99:2155] by server-3.bemta-4.messagelabs.com id
	E6/F9-08232-91584405; Mon, 03 Sep 2012 10:23:21 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1346667795!22925268!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTEzODI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31077 invoked from network); 3 Sep 2012 10:23:18 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Sep 2012 10:23:18 -0000
X-IronPort-AV: E=Sophos;i="4.80,359,1344211200"; d="scan'208";a="14314096"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Sep 2012 10: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.279.1; Mon, 3 Sep 2012
	11:23:15 +0100
Message-ID: <1346667794.25864.25.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Mon, 3 Sep 2012 11:23:14 +0100
In-Reply-To: <5044707C020000780009820F@nat28.tlf.novell.com>
References: <5040D05D.8090808@citrix.com>
	<5040F61A0200007800097E86@nat28.tlf.novell.com>
	<5040EB1B.80004@citrix.com>
	<5044707C020000780009820F@nat28.tlf.novell.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-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] (v2) docs/command line: Clarify the behavior with
 invalid input.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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-09-03 at 07:55 +0100, Jan Beulich wrote:
> >>> On 31.08.12 at 18:49, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
> > On 31/08/12 16:36, Jan Beulich wrote:
> >> I don't think we should specifically document the behavior for
> >> unexpected value; instead, the behavior should simply be
> >> "undefined".
> > 
> > Yes ok.  v2 attached.
> 
> Acked-by: Jan Beulich <jbeulich@suse.de>

Applied, thanks.



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

From xen-devel-bounces@lists.xen.org Mon Sep 03 10:24:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Sep 2012 10:24:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T8Tp6-0008QI-Tt; Mon, 03 Sep 2012 10:24: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 1T8Tp6-0008Q6-8j
	for xen-devel@lists.xen.org; Mon, 03 Sep 2012 10:24:04 +0000
Received: from [85.158.139.83:19597] by server-7.bemta-5.messagelabs.com id
	E5/F8-19703-34584405; Mon, 03 Sep 2012 10:24:03 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1346667842!28039192!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTEzODI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16440 invoked from network); 3 Sep 2012 10:24:03 -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;
	3 Sep 2012 10:24:03 -0000
X-IronPort-AV: E=Sophos;i="4.80,359,1344211200"; d="scan'208";a="14314100"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Sep 2012 10:23: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.279.1; Mon, 3 Sep 2012
	11:23:21 +0100
Message-ID: <1346667799.25864.26.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Mon, 3 Sep 2012 11:23:19 +0100
In-Reply-To: <20544.60599.275302.789129@mariner.uk.xensource.com>
References: <f9a7d8c439f9aa47b665.1346429767@cosworth.uk.xensource.com>
	<20544.60599.275302.789129@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Dieter Bloms <xensource.com@bloms.de>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH V3] libxl/xl: implement support for guest
 ioport and irq permissions
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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-08-31 at 17:56 +0100, Ian Jackson wrote:
> Ian Campbell writes ("[PATCH V3] libxl/xl: implement support for guest ioport and irq permissions"):
> > libxl/xl: implement support for guest ioport and irq permissions.
> 
> Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
> 
> For 4.2.

Applied, thanks.




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

From xen-devel-bounces@lists.xen.org Mon Sep 03 10:24:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Sep 2012 10:24:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T8Tp6-0008QI-Tt; Mon, 03 Sep 2012 10:24: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 1T8Tp6-0008Q6-8j
	for xen-devel@lists.xen.org; Mon, 03 Sep 2012 10:24:04 +0000
Received: from [85.158.139.83:19597] by server-7.bemta-5.messagelabs.com id
	E5/F8-19703-34584405; Mon, 03 Sep 2012 10:24:03 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1346667842!28039192!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTEzODI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16440 invoked from network); 3 Sep 2012 10:24:03 -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;
	3 Sep 2012 10:24:03 -0000
X-IronPort-AV: E=Sophos;i="4.80,359,1344211200"; d="scan'208";a="14314100"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Sep 2012 10:23: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.279.1; Mon, 3 Sep 2012
	11:23:21 +0100
Message-ID: <1346667799.25864.26.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Mon, 3 Sep 2012 11:23:19 +0100
In-Reply-To: <20544.60599.275302.789129@mariner.uk.xensource.com>
References: <f9a7d8c439f9aa47b665.1346429767@cosworth.uk.xensource.com>
	<20544.60599.275302.789129@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Dieter Bloms <xensource.com@bloms.de>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH V3] libxl/xl: implement support for guest
 ioport and irq permissions
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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-08-31 at 17:56 +0100, Ian Jackson wrote:
> Ian Campbell writes ("[PATCH V3] libxl/xl: implement support for guest ioport and irq permissions"):
> > libxl/xl: implement support for guest ioport and irq permissions.
> 
> Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
> 
> For 4.2.

Applied, thanks.




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

From xen-devel-bounces@lists.xen.org Mon Sep 03 10:46:37 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Sep 2012 10:46:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T8UAf-0000YM-6G; Mon, 03 Sep 2012 10:46: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 1T8UAd-0000YH-UC
	for xen-devel@lists.xen.org; Mon, 03 Sep 2012 10:46:20 +0000
Received: from [85.158.143.99:6445] by server-3.bemta-4.messagelabs.com id
	31/28-08232-B7A84405; Mon, 03 Sep 2012 10:46:19 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1346669178!22964028!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM3ODk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27927 invoked from network); 3 Sep 2012 10:46:18 -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;
	3 Sep 2012 10:46:18 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 03 Sep 2012 11:45:32 +0100
Message-Id: <5044A66802000078000983FF@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 03 Sep 2012 11:45:28 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "George Dunlap" <George.Dunlap@eu.citrix.com>
References: <1346665360.25864.2.camel@zakaz.uk.xensource.com>
In-Reply-To: <1346665360.25864.2.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] Xen 4.2.0 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 03.09.12 at 11:42, Ian Campbell <Ian.Campbell@citrix.com> wrote:
>     * [BUG] qemu-traditional has 50% cpu utilization on an idle
>       Windows system if USB is enabled. Not 100% clear whether this is
>       Xen or qemu.  George Dunlap thinks this is mostly down to 64-bit
>       syscall overhead and is not a blocker, will drop from the list.

A few percent certainly might be, but 50?

Jan


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

From xen-devel-bounces@lists.xen.org Mon Sep 03 10:46:37 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Sep 2012 10:46:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T8UAf-0000YM-6G; Mon, 03 Sep 2012 10:46: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 1T8UAd-0000YH-UC
	for xen-devel@lists.xen.org; Mon, 03 Sep 2012 10:46:20 +0000
Received: from [85.158.143.99:6445] by server-3.bemta-4.messagelabs.com id
	31/28-08232-B7A84405; Mon, 03 Sep 2012 10:46:19 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1346669178!22964028!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM3ODk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27927 invoked from network); 3 Sep 2012 10:46:18 -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;
	3 Sep 2012 10:46:18 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 03 Sep 2012 11:45:32 +0100
Message-Id: <5044A66802000078000983FF@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 03 Sep 2012 11:45:28 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "George Dunlap" <George.Dunlap@eu.citrix.com>
References: <1346665360.25864.2.camel@zakaz.uk.xensource.com>
In-Reply-To: <1346665360.25864.2.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] Xen 4.2.0 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 03.09.12 at 11:42, Ian Campbell <Ian.Campbell@citrix.com> wrote:
>     * [BUG] qemu-traditional has 50% cpu utilization on an idle
>       Windows system if USB is enabled. Not 100% clear whether this is
>       Xen or qemu.  George Dunlap thinks this is mostly down to 64-bit
>       syscall overhead and is not a blocker, will drop from the list.

A few percent certainly might be, but 50?

Jan


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

From xen-devel-bounces@lists.xen.org Mon Sep 03 11:49:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Sep 2012 11:49:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T8V8v-0000ts-6M; Mon, 03 Sep 2012 11:48:37 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jmarcet@gmail.com>) id 1T8V8t-0000tn-Jz
	for xen-devel@lists.xen.org; Mon, 03 Sep 2012 11:48:35 +0000
Received: from [85.158.143.99:46054] by server-2.bemta-4.messagelabs.com id
	47/07-21239-21994405; Mon, 03 Sep 2012 11:48:34 +0000
X-Env-Sender: jmarcet@gmail.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1346672911!22978158!1
X-Originating-IP: [209.85.214.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13894 invoked from network); 3 Sep 2012 11:48:32 -0000
Received: from mail-ob0-f173.google.com (HELO mail-ob0-f173.google.com)
	(209.85.214.173)
	by server-12.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Sep 2012 11:48:32 -0000
Received: by obbta14 with SMTP id ta14so11861071obb.32
	for <xen-devel@lists.xen.org>; Mon, 03 Sep 2012 04:48:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to
	:cc:content-type:content-transfer-encoding;
	bh=w3j2T6hMUSmDtO7rvXZXZhwBc44f+bF2S3vA2dHwsMU=;
	b=ExyJkGG9RqW2LWdzs8sguDcSqzTCBrjhhqqu4Rvfw6PtxkdWwgf1j7ZSUbkmViE+XO
	xq4Ye9Z7iM+Gmr1hZOSsYzruIAHel3arTqWMjACI3/8z8w/vMMu7VjbaXE0FkMDpCzqh
	n6XmnR5F7HmJCNLit4xoFfSrlzfOISNvA1qLQfezw4MlPv6HV3BfSF4GihcExsJrZjx7
	T10AyRepQ60Md7aYhtVMyrtn6CXmmafAFboi9j93g0UmDiHLSiJU6HVPHYYJP+f/qc9U
	Nw6ahC06mtHR6XGsgN7U6o2P8xk3WVxMt9fT2LnRgrgLLPfOsIygtvxxH2cMPMUJeTME
	1v1g==
Received: by 10.60.7.99 with SMTP id i3mr13536321oea.86.1346672911351; Mon, 03
	Sep 2012 04:48:31 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.60.12.164 with HTTP; Mon, 3 Sep 2012 04:48:11 -0700 (PDT)
In-Reply-To: <504478B40200007800098286@nat28.tlf.novell.com>
References: <CAAnFQG8z_ja1Wj2hX+0ZRsz5eLWr+U+7PoSiF9NePsSh2jbX4g@mail.gmail.com>
	<5040B7A40200007800097CEE@nat28.tlf.novell.com>
	<CAAnFQG_vvHQL=NbY1SnMWCcTr73_8RYtNLfc00fqEsz57cd7Rg@mail.gmail.com>
	<504478B40200007800098286@nat28.tlf.novell.com>
From: Javier Marcet <jmarcet@gmail.com>
Date: Mon, 3 Sep 2012 13:48:11 +0200
Message-ID: <CAAnFQG_4GwS0CKQnJ2gTW9v3GCmepy51Nw2BpyxtYNRX25D+6g@mail.gmail.com>
To: Jan Beulich <JBeulich@suse.com>
Cc: Xen Devel Mailing list <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.2.0-rc4 bugs with GigaByte H77M-D3H + Core i7
	3770
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gTW9uLCBTZXAgMywgMjAxMiBhdCA5OjMwIEFNLCBKYW4gQmV1bGljaCA8SkJldWxpY2hAc3Vz
ZS5jb20+IHdyb3RlOgoKPj4gSSdtIHNvcnJ5IEkgZGlkbid0IG1ha2UgbXlzZWxmIGNsZWFyZXIu
IFRoYXQgZG1lc2cgb3V0cHV0IGlzIHdoZW4gYm9vdGluZwo+PiBXSVRIT1VUIHhlbiwgdGhhdCBp
cywgbGludXggZGlyZWN0bHkgb3ZlciB0aGUgYmFyZSBoYXJkd2FyZS4gVW5kZXIgeGVuCj4+IHRo
b3NlIGVycm9ycyBkaXNzYXBlYXIuCj4+Cj4+IFRoZSBiaWcgaXNzdWUgSSdtIGhhdmluZyBydW5u
aW5nIHhlbiBpcyB0aGF0IEkgY2FuJ3QgdXNlIGl0IHNpbmNlIHhlbiBjYW4ndAo+PiBnZXQgdGhl
IGNwdSBjYXBhYmlsaXRpZXMuCj4KPiBXaGF0ICJjcHUgY2FwYWJpbGl0aWVzIj8gSSBqdXN0IGxv
b2tlZCBhdCB5b3VyIG9yaWdpbmFsIG1haWwgYWdhaW4sCj4gYW5kIEkgY2Fubm90IHNlZSB3aGF0
IGZhaWx1cmUgeW91J3JlIHJlZmVycmluZyB0byAoaW4gZmFjdCwgSSdtIG5vdAo+IGFibGUgdG8g
c3BvdCBhbnkgZmFpbHVyZSBpbiB0aGF0IGxvZyBhdCBhbGwpLiBBbmQgb2YgY291cnNlIHlvdSBk
aWRuJ3QKPiBldmVuIGF0dGFjaCBhIGh5cGVydmlzb3IgbG9nLiBXaGF0IGFtIEkgbWlzc2luZz8K
CknCtG0gc29ycnkgZm9yIG5vdCBpbmNsdWRpbmcgdGhhdCBsb2cuIEnCtG0gc3RpbGwgZ2V0dGlu
ZyB0byBrbm93IHhlbi4KCknCtG0gdXNpbmcgdmlydC1tYW5hZ2VyIHRvIGNyZWF0ZSBhbmQgbWFu
YWdlIHRoZSBWTXMuIEl0wrRzIHdpdGhpbgp2aXJ0LW1hbmFnZXIgd2hpY2ggeGVuIGNvbXBsYWlu
cyBpdCBjYW5ub3QgZ2V0IHRoZSBjcHUgY2FwYWJpbGl0aWVzLApoZW5jZSB0aGUgVk0gY2FuwrR0
IGJvb3QuIEnCtGxsIHRyeSB0byBjaGVjayB0aGUgaHlwZXJ2aXNvciBsb2dzLgoKQWxsIHRoZSBv
dGhlciBpc3N1ZXMgY29uY2VybiB0aGUgTGludXgga2VybmVsIG5vdCB4ZW4uCgoKLS0gCkphdmll
ciBNYXJjZXQgPGptYXJjZXRAZ21haWwuY29tPgoKX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlz
dHMueGVuLm9yZwpodHRwOi8vbGlzdHMueGVuLm9yZy94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xen.org Mon Sep 03 11:49:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Sep 2012 11:49:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T8V8v-0000ts-6M; Mon, 03 Sep 2012 11:48:37 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jmarcet@gmail.com>) id 1T8V8t-0000tn-Jz
	for xen-devel@lists.xen.org; Mon, 03 Sep 2012 11:48:35 +0000
Received: from [85.158.143.99:46054] by server-2.bemta-4.messagelabs.com id
	47/07-21239-21994405; Mon, 03 Sep 2012 11:48:34 +0000
X-Env-Sender: jmarcet@gmail.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1346672911!22978158!1
X-Originating-IP: [209.85.214.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13894 invoked from network); 3 Sep 2012 11:48:32 -0000
Received: from mail-ob0-f173.google.com (HELO mail-ob0-f173.google.com)
	(209.85.214.173)
	by server-12.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Sep 2012 11:48:32 -0000
Received: by obbta14 with SMTP id ta14so11861071obb.32
	for <xen-devel@lists.xen.org>; Mon, 03 Sep 2012 04:48:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to
	:cc:content-type:content-transfer-encoding;
	bh=w3j2T6hMUSmDtO7rvXZXZhwBc44f+bF2S3vA2dHwsMU=;
	b=ExyJkGG9RqW2LWdzs8sguDcSqzTCBrjhhqqu4Rvfw6PtxkdWwgf1j7ZSUbkmViE+XO
	xq4Ye9Z7iM+Gmr1hZOSsYzruIAHel3arTqWMjACI3/8z8w/vMMu7VjbaXE0FkMDpCzqh
	n6XmnR5F7HmJCNLit4xoFfSrlzfOISNvA1qLQfezw4MlPv6HV3BfSF4GihcExsJrZjx7
	T10AyRepQ60Md7aYhtVMyrtn6CXmmafAFboi9j93g0UmDiHLSiJU6HVPHYYJP+f/qc9U
	Nw6ahC06mtHR6XGsgN7U6o2P8xk3WVxMt9fT2LnRgrgLLPfOsIygtvxxH2cMPMUJeTME
	1v1g==
Received: by 10.60.7.99 with SMTP id i3mr13536321oea.86.1346672911351; Mon, 03
	Sep 2012 04:48:31 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.60.12.164 with HTTP; Mon, 3 Sep 2012 04:48:11 -0700 (PDT)
In-Reply-To: <504478B40200007800098286@nat28.tlf.novell.com>
References: <CAAnFQG8z_ja1Wj2hX+0ZRsz5eLWr+U+7PoSiF9NePsSh2jbX4g@mail.gmail.com>
	<5040B7A40200007800097CEE@nat28.tlf.novell.com>
	<CAAnFQG_vvHQL=NbY1SnMWCcTr73_8RYtNLfc00fqEsz57cd7Rg@mail.gmail.com>
	<504478B40200007800098286@nat28.tlf.novell.com>
From: Javier Marcet <jmarcet@gmail.com>
Date: Mon, 3 Sep 2012 13:48:11 +0200
Message-ID: <CAAnFQG_4GwS0CKQnJ2gTW9v3GCmepy51Nw2BpyxtYNRX25D+6g@mail.gmail.com>
To: Jan Beulich <JBeulich@suse.com>
Cc: Xen Devel Mailing list <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.2.0-rc4 bugs with GigaByte H77M-D3H + Core i7
	3770
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gTW9uLCBTZXAgMywgMjAxMiBhdCA5OjMwIEFNLCBKYW4gQmV1bGljaCA8SkJldWxpY2hAc3Vz
ZS5jb20+IHdyb3RlOgoKPj4gSSdtIHNvcnJ5IEkgZGlkbid0IG1ha2UgbXlzZWxmIGNsZWFyZXIu
IFRoYXQgZG1lc2cgb3V0cHV0IGlzIHdoZW4gYm9vdGluZwo+PiBXSVRIT1VUIHhlbiwgdGhhdCBp
cywgbGludXggZGlyZWN0bHkgb3ZlciB0aGUgYmFyZSBoYXJkd2FyZS4gVW5kZXIgeGVuCj4+IHRo
b3NlIGVycm9ycyBkaXNzYXBlYXIuCj4+Cj4+IFRoZSBiaWcgaXNzdWUgSSdtIGhhdmluZyBydW5u
aW5nIHhlbiBpcyB0aGF0IEkgY2FuJ3QgdXNlIGl0IHNpbmNlIHhlbiBjYW4ndAo+PiBnZXQgdGhl
IGNwdSBjYXBhYmlsaXRpZXMuCj4KPiBXaGF0ICJjcHUgY2FwYWJpbGl0aWVzIj8gSSBqdXN0IGxv
b2tlZCBhdCB5b3VyIG9yaWdpbmFsIG1haWwgYWdhaW4sCj4gYW5kIEkgY2Fubm90IHNlZSB3aGF0
IGZhaWx1cmUgeW91J3JlIHJlZmVycmluZyB0byAoaW4gZmFjdCwgSSdtIG5vdAo+IGFibGUgdG8g
c3BvdCBhbnkgZmFpbHVyZSBpbiB0aGF0IGxvZyBhdCBhbGwpLiBBbmQgb2YgY291cnNlIHlvdSBk
aWRuJ3QKPiBldmVuIGF0dGFjaCBhIGh5cGVydmlzb3IgbG9nLiBXaGF0IGFtIEkgbWlzc2luZz8K
CknCtG0gc29ycnkgZm9yIG5vdCBpbmNsdWRpbmcgdGhhdCBsb2cuIEnCtG0gc3RpbGwgZ2V0dGlu
ZyB0byBrbm93IHhlbi4KCknCtG0gdXNpbmcgdmlydC1tYW5hZ2VyIHRvIGNyZWF0ZSBhbmQgbWFu
YWdlIHRoZSBWTXMuIEl0wrRzIHdpdGhpbgp2aXJ0LW1hbmFnZXIgd2hpY2ggeGVuIGNvbXBsYWlu
cyBpdCBjYW5ub3QgZ2V0IHRoZSBjcHUgY2FwYWJpbGl0aWVzLApoZW5jZSB0aGUgVk0gY2FuwrR0
IGJvb3QuIEnCtGxsIHRyeSB0byBjaGVjayB0aGUgaHlwZXJ2aXNvciBsb2dzLgoKQWxsIHRoZSBv
dGhlciBpc3N1ZXMgY29uY2VybiB0aGUgTGludXgga2VybmVsIG5vdCB4ZW4uCgoKLS0gCkphdmll
ciBNYXJjZXQgPGptYXJjZXRAZ21haWwuY29tPgoKX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlz
dHMueGVuLm9yZwpodHRwOi8vbGlzdHMueGVuLm9yZy94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xen.org Mon Sep 03 12:49:36 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Sep 2012 12:49: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 1T8W5S-0001fH-9I; Mon, 03 Sep 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 <Ian.Campbell@citrix.com>) id 1T8W5Q-0001fC-8G
	for xen-devel@lists.xen.org; Mon, 03 Sep 2012 12:49:04 +0000
Received: from [85.158.143.35:13354] by server-1.bemta-4.messagelabs.com id
	14/BC-12504-F37A4405; Mon, 03 Sep 2012 12:49:03 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1346676539!13850533!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNzYzNjg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6475 invoked from network); 3 Sep 2012 12:49:00 -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;
	3 Sep 2012 12:49:00 -0000
X-IronPort-AV: E=Sophos;i="4.80,359,1344211200"; d="scan'208";a="206935017"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Sep 2012 12:48:58 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Mon, 3 Sep 2012 08:48:58 -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 1T8W5K-0007Yr-CP;
	Mon, 03 Sep 2012 13:48:58 +0100
MIME-Version: 1.0
X-Mercurial-Node: 99b7a5af9b3059bac2732a601fb1d574b9f02975
Message-ID: <99b7a5af9b3059bac273.1346676538@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Mon, 3 Sep 2012 13:48:58 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Cc: Andres Lagar-Cavilla <andreslc@gridcentric.ca>, tim@xen.org,
	Stefano Panella <stefano.panella@citrix.com>, Ian.Jackson@citrix.com
Subject: [Xen-devel] [PATCH] libxl: handle errors from xc_sharing_* info
	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

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1346676461 -3600
# Node ID 99b7a5af9b3059bac2732a601fb1d574b9f02975
# Parent  c4e822e1b491bb7efa962b38fff6f007f01596b5
libxl: handle errors from xc_sharing_* info functions

On a 32 bit hypervisor xl info currently reports:
sharing_freed_memory   : 72057594037927935
sharing_used_memory    : 72057594037927935

Eat the ENOSYS and turn it into 0. Log and propagate other errors.

I don't have a 32 bit system handy, so tested on x86_64 with a libxc
hacked to return -ENOSYS and -EINVAL.

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

diff -r c4e822e1b491 -r 99b7a5af9b30 tools/libxl/libxl.c
--- a/tools/libxl/libxl.c	Mon Sep 03 09:59:35 2012 +0100
+++ b/tools/libxl/libxl.c	Mon Sep 03 13:47:41 2012 +0100
@@ -3622,6 +3622,7 @@ int libxl_get_physinfo(libxl_ctx *ctx, l
 {
     xc_physinfo_t xcphysinfo = { 0 };
     int rc;
+    long l;
 
     rc = xc_physinfo(ctx->xch, &xcphysinfo);
     if (rc != 0) {
@@ -3636,8 +3637,20 @@ int libxl_get_physinfo(libxl_ctx *ctx, l
     physinfo->total_pages = xcphysinfo.total_pages;
     physinfo->free_pages = xcphysinfo.free_pages;
     physinfo->scrub_pages = xcphysinfo.scrub_pages;
-    physinfo->sharing_freed_pages = xc_sharing_freed_pages(ctx->xch);
-    physinfo->sharing_used_frames = xc_sharing_used_frames(ctx->xch);
+    l = xc_sharing_freed_pages(ctx->xch);
+    if ( l < 0 && l != -ENOSYS ) {
+        LIBXL__LOG_ERRNOVAL(ctx, LIBXL__LOG_ERROR, l,
+                            "getting sharing freed pages");
+        return ERROR_FAIL;
+    }
+    physinfo->sharing_freed_pages = (l == -ENOSYS) ? 0 : l;
+    l = xc_sharing_used_frames(ctx->xch);
+    if ( l < 0 && l != -ENOSYS ) {
+        LIBXL__LOG_ERRNOVAL(ctx, LIBXL__LOG_ERROR, l,
+                            "getting sharing used frames");
+        return ERROR_FAIL;
+    }
+    physinfo->sharing_used_frames = (l == -ENOSYS) ? 0 : l;
     physinfo->nr_nodes = xcphysinfo.nr_nodes;
     memcpy(physinfo->hw_cap,xcphysinfo.hw_cap, sizeof(physinfo->hw_cap));
 

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

From xen-devel-bounces@lists.xen.org Mon Sep 03 12:49:36 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Sep 2012 12:49: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 1T8W5S-0001fH-9I; Mon, 03 Sep 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 <Ian.Campbell@citrix.com>) id 1T8W5Q-0001fC-8G
	for xen-devel@lists.xen.org; Mon, 03 Sep 2012 12:49:04 +0000
Received: from [85.158.143.35:13354] by server-1.bemta-4.messagelabs.com id
	14/BC-12504-F37A4405; Mon, 03 Sep 2012 12:49:03 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1346676539!13850533!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNzYzNjg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6475 invoked from network); 3 Sep 2012 12:49:00 -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;
	3 Sep 2012 12:49:00 -0000
X-IronPort-AV: E=Sophos;i="4.80,359,1344211200"; d="scan'208";a="206935017"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Sep 2012 12:48:58 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Mon, 3 Sep 2012 08:48:58 -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 1T8W5K-0007Yr-CP;
	Mon, 03 Sep 2012 13:48:58 +0100
MIME-Version: 1.0
X-Mercurial-Node: 99b7a5af9b3059bac2732a601fb1d574b9f02975
Message-ID: <99b7a5af9b3059bac273.1346676538@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Mon, 3 Sep 2012 13:48:58 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Cc: Andres Lagar-Cavilla <andreslc@gridcentric.ca>, tim@xen.org,
	Stefano Panella <stefano.panella@citrix.com>, Ian.Jackson@citrix.com
Subject: [Xen-devel] [PATCH] libxl: handle errors from xc_sharing_* info
	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

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1346676461 -3600
# Node ID 99b7a5af9b3059bac2732a601fb1d574b9f02975
# Parent  c4e822e1b491bb7efa962b38fff6f007f01596b5
libxl: handle errors from xc_sharing_* info functions

On a 32 bit hypervisor xl info currently reports:
sharing_freed_memory   : 72057594037927935
sharing_used_memory    : 72057594037927935

Eat the ENOSYS and turn it into 0. Log and propagate other errors.

I don't have a 32 bit system handy, so tested on x86_64 with a libxc
hacked to return -ENOSYS and -EINVAL.

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

diff -r c4e822e1b491 -r 99b7a5af9b30 tools/libxl/libxl.c
--- a/tools/libxl/libxl.c	Mon Sep 03 09:59:35 2012 +0100
+++ b/tools/libxl/libxl.c	Mon Sep 03 13:47:41 2012 +0100
@@ -3622,6 +3622,7 @@ int libxl_get_physinfo(libxl_ctx *ctx, l
 {
     xc_physinfo_t xcphysinfo = { 0 };
     int rc;
+    long l;
 
     rc = xc_physinfo(ctx->xch, &xcphysinfo);
     if (rc != 0) {
@@ -3636,8 +3637,20 @@ int libxl_get_physinfo(libxl_ctx *ctx, l
     physinfo->total_pages = xcphysinfo.total_pages;
     physinfo->free_pages = xcphysinfo.free_pages;
     physinfo->scrub_pages = xcphysinfo.scrub_pages;
-    physinfo->sharing_freed_pages = xc_sharing_freed_pages(ctx->xch);
-    physinfo->sharing_used_frames = xc_sharing_used_frames(ctx->xch);
+    l = xc_sharing_freed_pages(ctx->xch);
+    if ( l < 0 && l != -ENOSYS ) {
+        LIBXL__LOG_ERRNOVAL(ctx, LIBXL__LOG_ERROR, l,
+                            "getting sharing freed pages");
+        return ERROR_FAIL;
+    }
+    physinfo->sharing_freed_pages = (l == -ENOSYS) ? 0 : l;
+    l = xc_sharing_used_frames(ctx->xch);
+    if ( l < 0 && l != -ENOSYS ) {
+        LIBXL__LOG_ERRNOVAL(ctx, LIBXL__LOG_ERROR, l,
+                            "getting sharing used frames");
+        return ERROR_FAIL;
+    }
+    physinfo->sharing_used_frames = (l == -ENOSYS) ? 0 : l;
     physinfo->nr_nodes = xcphysinfo.nr_nodes;
     memcpy(physinfo->hw_cap,xcphysinfo.hw_cap, sizeof(physinfo->hw_cap));
 

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

From xen-devel-bounces@lists.xen.org Mon Sep 03 13:16:40 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Sep 2012 13:16:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T8WVc-0001us-0E; Mon, 03 Sep 2012 13:16: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 1T8WVb-0001un-8T
	for xen-devel@lists.xen.org; Mon, 03 Sep 2012 13:16:07 +0000
Received: from [85.158.143.35:5727] by server-1.bemta-4.messagelabs.com id
	B3/FE-12504-69DA4405; Mon, 03 Sep 2012 13:16:06 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1346678160!16483578!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM3ODk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21793 invoked from network); 3 Sep 2012 13:16:01 -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;
	3 Sep 2012 13:16:01 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 03 Sep 2012 14:16:00 +0100
Message-Id: <5044C9AC0200007800098458@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 03 Sep 2012 14:15:56 +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] linux-2.6.18/x86-64: fix hypercall page unwind
	info
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This apparently was a copy-and-paste oversight.

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

--- a/arch/x86_64/kernel/head-xen.S
+++ b/arch/x86_64/kernel/head-xen.S
@@ -86,7 +86,7 @@ NEXT_PAGE(hypercall_page)
 	CFI_REL_OFFSET	rcx,0
 	.skip 2 /* push %r11 */
 	CFI_ADJUST_CFA_OFFSET	8
-	CFI_REL_OFFSET	rcx,0
+	CFI_REL_OFFSET	r11,0
 	.skip 5 /* mov $#,%eax */
 	.skip 2 /* syscall */
 	.skip 2 /* pop %r11 */




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

From xen-devel-bounces@lists.xen.org Mon Sep 03 13:16:40 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Sep 2012 13:16:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T8WVc-0001us-0E; Mon, 03 Sep 2012 13:16: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 1T8WVb-0001un-8T
	for xen-devel@lists.xen.org; Mon, 03 Sep 2012 13:16:07 +0000
Received: from [85.158.143.35:5727] by server-1.bemta-4.messagelabs.com id
	B3/FE-12504-69DA4405; Mon, 03 Sep 2012 13:16:06 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1346678160!16483578!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM3ODk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21793 invoked from network); 3 Sep 2012 13:16:01 -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;
	3 Sep 2012 13:16:01 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 03 Sep 2012 14:16:00 +0100
Message-Id: <5044C9AC0200007800098458@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 03 Sep 2012 14:15:56 +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] linux-2.6.18/x86-64: fix hypercall page unwind
	info
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This apparently was a copy-and-paste oversight.

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

--- a/arch/x86_64/kernel/head-xen.S
+++ b/arch/x86_64/kernel/head-xen.S
@@ -86,7 +86,7 @@ NEXT_PAGE(hypercall_page)
 	CFI_REL_OFFSET	rcx,0
 	.skip 2 /* push %r11 */
 	CFI_ADJUST_CFA_OFFSET	8
-	CFI_REL_OFFSET	rcx,0
+	CFI_REL_OFFSET	r11,0
 	.skip 5 /* mov $#,%eax */
 	.skip 2 /* syscall */
 	.skip 2 /* pop %r11 */




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

From xen-devel-bounces@lists.xen.org Mon Sep 03 13:28:45 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Sep 2012 13:28:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T8WhP-000255-HL; Mon, 03 Sep 2012 13:28: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 1T8WhN-000250-VW
	for xen-devel@lists.xen.org; Mon, 03 Sep 2012 13:28:18 +0000
Received: from [85.158.139.83:24923] by server-9.bemta-5.messagelabs.com id
	D9/E5-20529-170B4405; Mon, 03 Sep 2012 13:28:17 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1346678895!27614615!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTEzODI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10495 invoked from network); 3 Sep 2012 13:28: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;
	3 Sep 2012 13:28:15 -0000
X-IronPort-AV: E=Sophos;i="4.80,359,1344211200"; d="scan'208";a="14318489"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Sep 2012 13:28: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.279.1; Mon, 3 Sep 2012
	14:28:08 +0100
Message-ID: <1346678886.32462.9.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: xen-devel <xen-devel@lists.xen.org>
Date: Mon, 3 Sep 2012 14:28:06 +0100
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Subject: [Xen-devel] [PATCH 0/16] arm: support for initial modules (e.g.
 dom0) and DTB supplied in RAM
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

The following series implements support for initial images and DTB in
RAM, as opposed to in flash (dom0 kernel) or compiled into the
hypervisor (DTB). It arranges to not clobber these with either the h/v
text on relocation or with the heaps and frees them as appropriate.

Most of this is independent of the specific bootloader protocol which is
used to tell Xen where these modules actually are, but I have included a
simple PoC bootloader protocol based around device tree which is similar
to the protocol used by Linux to find its initrd
(where /chosen/linux,initrd-{start,end} indicate the physical address).

In the PoC the modules are listed in the chosen node starting
with /chosen/nr-modules which contains the count and then /chosen/module
%d-{start,end} which gives the physical address of the module
and /chosen/module%d-args which give its command line.

I will post a patch against the boot-wrapper[0] which implements the
"bootloader" side of this protocol shortly. With that you can boot using
the semi-hosting feature of the model (paths are host paths) like so:
        $MODEL linux-system-semi.axf -C cluster.cpu0.semihosting-cmd_line=\
        	'--kernel xen-arm.bin \
        	 --module zImage earlyprintk=xenboot console=ttyAMA1 root=/dev/mmcblk0 ro \
        	 --dtb vexpress-v2p-aem-v7a-xen.dtb -- dom0_mem=256M'

Until we know what bootloaders are going to become common in the ARM
servers world it hard to know who we should be working with to define a
proper protocol going forward and which bootloaders to supply patches
for. (see the mail with the boot-wrapper patch for more on this).

I suspect that we will inevitably need a tool which takes Xen and the
modules and builds them into a single self exploding image since
bootloader support for any protocol we end up defining is likely to be
spotty at least for the time being.

One thing I'm wondering is whether or not we should duplicate the Linux
zImage header (magic numbers, length etc) at the start of our image too.
That is this:
        
        start:
                        .type   start,#function
                        .rept   7
                        mov     r0, r0
                        .endr
           ARM(         mov     r0, r0          )
           ARM(         b       1f              )
         THUMB(         adr     r12, BSYM(1f)   )
         THUMB(         bx      r12             )
        
                        .word   0x016f2818              @ Magic numbers to help the loader
                        .word   start                   @ absolute load/run zImage address
                        .word   _edata                  @ zImage end address
         THUMB(         .thumb                  )
        1:              mov     r7, r1                  @ save architecture ID
                        mov     r8, r2                  @ save atags pointer

It's pretty trivial but I'm not sure of how much use it is.

[0] git://git.linaro.org/arm/models/boot-wrapper.git



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

From xen-devel-bounces@lists.xen.org Mon Sep 03 13:28:45 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Sep 2012 13:28:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T8WhP-000255-HL; Mon, 03 Sep 2012 13:28: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 1T8WhN-000250-VW
	for xen-devel@lists.xen.org; Mon, 03 Sep 2012 13:28:18 +0000
Received: from [85.158.139.83:24923] by server-9.bemta-5.messagelabs.com id
	D9/E5-20529-170B4405; Mon, 03 Sep 2012 13:28:17 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1346678895!27614615!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTEzODI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10495 invoked from network); 3 Sep 2012 13:28: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;
	3 Sep 2012 13:28:15 -0000
X-IronPort-AV: E=Sophos;i="4.80,359,1344211200"; d="scan'208";a="14318489"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Sep 2012 13:28: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.279.1; Mon, 3 Sep 2012
	14:28:08 +0100
Message-ID: <1346678886.32462.9.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: xen-devel <xen-devel@lists.xen.org>
Date: Mon, 3 Sep 2012 14:28:06 +0100
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Subject: [Xen-devel] [PATCH 0/16] arm: support for initial modules (e.g.
 dom0) and DTB supplied in RAM
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

The following series implements support for initial images and DTB in
RAM, as opposed to in flash (dom0 kernel) or compiled into the
hypervisor (DTB). It arranges to not clobber these with either the h/v
text on relocation or with the heaps and frees them as appropriate.

Most of this is independent of the specific bootloader protocol which is
used to tell Xen where these modules actually are, but I have included a
simple PoC bootloader protocol based around device tree which is similar
to the protocol used by Linux to find its initrd
(where /chosen/linux,initrd-{start,end} indicate the physical address).

In the PoC the modules are listed in the chosen node starting
with /chosen/nr-modules which contains the count and then /chosen/module
%d-{start,end} which gives the physical address of the module
and /chosen/module%d-args which give its command line.

I will post a patch against the boot-wrapper[0] which implements the
"bootloader" side of this protocol shortly. With that you can boot using
the semi-hosting feature of the model (paths are host paths) like so:
        $MODEL linux-system-semi.axf -C cluster.cpu0.semihosting-cmd_line=\
        	'--kernel xen-arm.bin \
        	 --module zImage earlyprintk=xenboot console=ttyAMA1 root=/dev/mmcblk0 ro \
        	 --dtb vexpress-v2p-aem-v7a-xen.dtb -- dom0_mem=256M'

Until we know what bootloaders are going to become common in the ARM
servers world it hard to know who we should be working with to define a
proper protocol going forward and which bootloaders to supply patches
for. (see the mail with the boot-wrapper patch for more on this).

I suspect that we will inevitably need a tool which takes Xen and the
modules and builds them into a single self exploding image since
bootloader support for any protocol we end up defining is likely to be
spotty at least for the time being.

One thing I'm wondering is whether or not we should duplicate the Linux
zImage header (magic numbers, length etc) at the start of our image too.
That is this:
        
        start:
                        .type   start,#function
                        .rept   7
                        mov     r0, r0
                        .endr
           ARM(         mov     r0, r0          )
           ARM(         b       1f              )
         THUMB(         adr     r12, BSYM(1f)   )
         THUMB(         bx      r12             )
        
                        .word   0x016f2818              @ Magic numbers to help the loader
                        .word   start                   @ absolute load/run zImage address
                        .word   _edata                  @ zImage end address
         THUMB(         .thumb                  )
        1:              mov     r7, r1                  @ save architecture ID
                        mov     r8, r2                  @ save atags pointer

It's pretty trivial but I'm not sure of how much use it is.

[0] git://git.linaro.org/arm/models/boot-wrapper.git



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

From xen-devel-bounces@lists.xen.org Mon Sep 03 13:31:20 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Sep 2012 13:31:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T8Wk4-0002BQ-O8; Mon, 03 Sep 2012 13:31: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 1T8Wk3-0002Au-8O
	for xen-devel@lists.xen.org; Mon, 03 Sep 2012 13:31:03 +0000
Received: from [85.158.143.99:63814] by server-2.bemta-4.messagelabs.com id
	4D/1F-21239-611B4405; Mon, 03 Sep 2012 13:31:02 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1346679058!18620742!3
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNzYzNjg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21129 invoked from network); 3 Sep 2012 13:31:01 -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;
	3 Sep 2012 13:31:01 -0000
X-IronPort-AV: E=Sophos;i="4.80,359,1344211200"; d="scan'208";a="206937950"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Sep 2012 13:30:58 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Mon, 3 Sep 2012 09:30: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 1T8Wjx-00089t-FJ;
	Mon, 03 Sep 2012 14:30:57 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Date: Mon, 3 Sep 2012 13:30:47 +0000
Message-ID: <1346679056-8108-7-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.9.1
In-Reply-To: <1346678886.32462.9.camel@zakaz.uk.xensource.com>
References: <1346678886.32462.9.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH 07/16] arm: avoid placing Xen over any modules.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This will still fail if the modules are such that Xen is pushed out of
the top 32M of RAM since it will then overlap with the domheap (or
possibly xenheap). This will be dealt with later.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 xen/arch/arm/setup.c |   66 ++++++++++++++++++++++++++++++++++++++++++++-----
 1 files changed, 59 insertions(+), 7 deletions(-)

diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index b466875..5f8a3d7 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -67,17 +67,58 @@ static void __init processor_id(void)
            READ_CP32(ID_ISAR3), READ_CP32(ID_ISAR4), READ_CP32(ID_ISAR5));
 }
 
+/*
+ * Returns the end address of the highest region in the range s..e
+ * with required size and alignment that does not conflict with the
+ * modules from first_mod to nr_modules.
+ *
+ * For non-recursive callers first_mod should normally be 0.
+ */
+static paddr_t __init consider_modules(paddr_t s, paddr_t e,
+                                       uint32_t size, paddr_t align,
+                                       int first_mod)
+{
+    const struct dt_module_info *mi = &early_info.modules;
+    int i;
+
+    s = (s+align-1) & ~(align-1);
+    e = e & ~(align-1);
+
+    if ( s > e ||  e - s < size )
+        return 0;
+
+    for ( i = first_mod; i < mi->nr_mods; i++ )
+    {
+        paddr_t mod_s;
+        paddr_t mod_e;
+
+        mod_s = mi->module[i].start;
+        mod_e = mod_s + mi->module[i].size;
+
+        if ( s < mod_e && mod_s < e )
+        {
+            mod_e = consider_modules(mod_e, e, size, align, i+1);
+            if ( mod_e )
+                return mod_e;
+
+            return consider_modules(s, mod_s, size, align, i+1);
+        }
+    }
+
+    return e;
+}
+
 /**
  * get_xen_paddr - get physical address to relocate Xen to
  *
- * Xen is relocated to the top of RAM and aligned to a XEN_PADDR_ALIGN
- * boundary.
+ * Xen is relocated to as near to the top of RAM as possible and
+ * aligned to a XEN_PADDR_ALIGN boundary.
  */
 static paddr_t __init get_xen_paddr(void)
 {
     struct dt_mem_info *mi = &early_info.mem;
     paddr_t min_size;
-    paddr_t paddr = 0, t;
+    paddr_t paddr = 0;
     int i;
 
     min_size = (_end - _start + (XEN_PADDR_ALIGN-1)) & ~(XEN_PADDR_ALIGN-1);
@@ -85,17 +126,28 @@ static paddr_t __init get_xen_paddr(void)
     /* Find the highest bank with enough space. */
     for ( i = 0; i < mi->nr_banks; i++ )
     {
-        if ( mi->bank[i].size >= min_size )
+        const struct membank *bank = &mi->bank[i];
+        paddr_t s, e;
+
+        if ( bank->size >= min_size )
         {
-            t = mi->bank[i].start + mi->bank[i].size - min_size;
-            if ( t > paddr )
-                paddr = t;
+            e = consider_modules(bank->start, bank->start + bank->size,
+                                 min_size, XEN_PADDR_ALIGN, 0);
+            if ( !e )continue;
+
+            s = e - min_size;
+
+            if ( s > paddr )
+                paddr = s;
         }
     }
 
     if ( !paddr )
         early_panic("Not enough memory to relocate Xen\n");
 
+    early_printk("Placing Xen at 0x%"PRIpaddr"-0x%"PRIpaddr"\n",
+                 paddr, paddr + min_size);
+
     return paddr;
 }
 
-- 
1.7.9.1


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

From xen-devel-bounces@lists.xen.org Mon Sep 03 13:31:20 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Sep 2012 13:31:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T8Wk4-0002BQ-O8; Mon, 03 Sep 2012 13:31: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 1T8Wk3-0002Au-8O
	for xen-devel@lists.xen.org; Mon, 03 Sep 2012 13:31:03 +0000
Received: from [85.158.143.99:63814] by server-2.bemta-4.messagelabs.com id
	4D/1F-21239-611B4405; Mon, 03 Sep 2012 13:31:02 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1346679058!18620742!3
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNzYzNjg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21129 invoked from network); 3 Sep 2012 13:31:01 -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;
	3 Sep 2012 13:31:01 -0000
X-IronPort-AV: E=Sophos;i="4.80,359,1344211200"; d="scan'208";a="206937950"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Sep 2012 13:30:58 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Mon, 3 Sep 2012 09:30: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 1T8Wjx-00089t-FJ;
	Mon, 03 Sep 2012 14:30:57 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Date: Mon, 3 Sep 2012 13:30:47 +0000
Message-ID: <1346679056-8108-7-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.9.1
In-Reply-To: <1346678886.32462.9.camel@zakaz.uk.xensource.com>
References: <1346678886.32462.9.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH 07/16] arm: avoid placing Xen over any modules.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This will still fail if the modules are such that Xen is pushed out of
the top 32M of RAM since it will then overlap with the domheap (or
possibly xenheap). This will be dealt with later.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 xen/arch/arm/setup.c |   66 ++++++++++++++++++++++++++++++++++++++++++++-----
 1 files changed, 59 insertions(+), 7 deletions(-)

diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index b466875..5f8a3d7 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -67,17 +67,58 @@ static void __init processor_id(void)
            READ_CP32(ID_ISAR3), READ_CP32(ID_ISAR4), READ_CP32(ID_ISAR5));
 }
 
+/*
+ * Returns the end address of the highest region in the range s..e
+ * with required size and alignment that does not conflict with the
+ * modules from first_mod to nr_modules.
+ *
+ * For non-recursive callers first_mod should normally be 0.
+ */
+static paddr_t __init consider_modules(paddr_t s, paddr_t e,
+                                       uint32_t size, paddr_t align,
+                                       int first_mod)
+{
+    const struct dt_module_info *mi = &early_info.modules;
+    int i;
+
+    s = (s+align-1) & ~(align-1);
+    e = e & ~(align-1);
+
+    if ( s > e ||  e - s < size )
+        return 0;
+
+    for ( i = first_mod; i < mi->nr_mods; i++ )
+    {
+        paddr_t mod_s;
+        paddr_t mod_e;
+
+        mod_s = mi->module[i].start;
+        mod_e = mod_s + mi->module[i].size;
+
+        if ( s < mod_e && mod_s < e )
+        {
+            mod_e = consider_modules(mod_e, e, size, align, i+1);
+            if ( mod_e )
+                return mod_e;
+
+            return consider_modules(s, mod_s, size, align, i+1);
+        }
+    }
+
+    return e;
+}
+
 /**
  * get_xen_paddr - get physical address to relocate Xen to
  *
- * Xen is relocated to the top of RAM and aligned to a XEN_PADDR_ALIGN
- * boundary.
+ * Xen is relocated to as near to the top of RAM as possible and
+ * aligned to a XEN_PADDR_ALIGN boundary.
  */
 static paddr_t __init get_xen_paddr(void)
 {
     struct dt_mem_info *mi = &early_info.mem;
     paddr_t min_size;
-    paddr_t paddr = 0, t;
+    paddr_t paddr = 0;
     int i;
 
     min_size = (_end - _start + (XEN_PADDR_ALIGN-1)) & ~(XEN_PADDR_ALIGN-1);
@@ -85,17 +126,28 @@ static paddr_t __init get_xen_paddr(void)
     /* Find the highest bank with enough space. */
     for ( i = 0; i < mi->nr_banks; i++ )
     {
-        if ( mi->bank[i].size >= min_size )
+        const struct membank *bank = &mi->bank[i];
+        paddr_t s, e;
+
+        if ( bank->size >= min_size )
         {
-            t = mi->bank[i].start + mi->bank[i].size - min_size;
-            if ( t > paddr )
-                paddr = t;
+            e = consider_modules(bank->start, bank->start + bank->size,
+                                 min_size, XEN_PADDR_ALIGN, 0);
+            if ( !e )continue;
+
+            s = e - min_size;
+
+            if ( s > paddr )
+                paddr = s;
         }
     }
 
     if ( !paddr )
         early_panic("Not enough memory to relocate Xen\n");
 
+    early_printk("Placing Xen at 0x%"PRIpaddr"-0x%"PRIpaddr"\n",
+                 paddr, paddr + min_size);
+
     return paddr;
 }
 
-- 
1.7.9.1


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

From xen-devel-bounces@lists.xen.org Mon Sep 03 13:31:21 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Sep 2012 13:31:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T8Wk4-0002BH-Bu; Mon, 03 Sep 2012 13:31: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 1T8Wk3-0002Ar-5s
	for xen-devel@lists.xen.org; Mon, 03 Sep 2012 13:31:03 +0000
Received: from [85.158.143.99:63823] by server-3.bemta-4.messagelabs.com id
	58/E0-08232-611B4405; Mon, 03 Sep 2012 13:31:02 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1346679058!18620742!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNzYzNjg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21037 invoked from network); 3 Sep 2012 13:31:00 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-14.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Sep 2012 13:31:00 -0000
X-IronPort-AV: E=Sophos;i="4.80,359,1344211200"; d="scan'208";a="206937949"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Sep 2012 13:30:58 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Mon, 3 Sep 2012 09:30: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 1T8Wjx-00089t-E5;
	Mon, 03 Sep 2012 14:30:57 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Date: Mon, 3 Sep 2012 13:30:46 +0000
Message-ID: <1346679056-8108-6-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.9.1
In-Reply-To: <1346678886.32462.9.camel@zakaz.uk.xensource.com>
References: <1346678886.32462.9.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH 06/16] arm: parse modules from DT during early
	boot.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

The bootloader should populate /chosen/nr-modules with the number of
modules and then for each module 0..nr-modules-1 it should populate
/chosen/moduleN-{start,end} with the physical address of the module.

The hypervisor allows for 2 modules (kernel and initrd). Currently we
don't do anything with them.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 xen/common/device_tree.c      |   57 +++++++++++++++++++++++++++++++++++++++++
 xen/include/xen/device_tree.h |    7 +++++
 2 files changed, 64 insertions(+), 0 deletions(-)

diff --git a/xen/common/device_tree.c b/xen/common/device_tree.c
index 3d1f0f4..226e3f3 100644
--- a/xen/common/device_tree.c
+++ b/xen/common/device_tree.c
@@ -229,6 +229,61 @@ static void __init process_memory_node(const void *fdt, int node,
     }
 }
 
+static void __init process_chosen_node(const void *fdt, int node,
+                                       const char *name,
+                                       u32 address_cells, u32 size_cells)
+{
+    const struct fdt_property *prop;
+    const u32 *cell;
+    paddr_t size;
+    int i, nr_modules;
+
+    prop = fdt_get_property(fdt, node, "nr-modules", NULL);
+    if ( !prop )
+    {
+        early_info.modules.nr_mods = 0;
+        return;
+    }
+
+    cell = (const u32 *)prop->data;
+    get_val(&cell, 1, (u64*)&nr_modules);
+
+    if ( nr_modules > NR_MODULES )
+    {
+        early_panic("too many modules %d > %d\n", nr_modules, NR_MODULES);
+    }
+
+    for ( i = 0; i < nr_modules; i++ )
+    {
+        struct membank *mod = &early_info.modules.module[i];
+        /* longest prop name is "start", single digit numbers of modules */
+        char propname[strlen("moduleX-start") + 1];
+
+        BUILD_BUG_ON(NR_MODULES > 9);
+
+        snprintf(propname, sizeof(propname), "module%d-start", i+1);
+        prop = fdt_get_property(fdt, node, propname, NULL);
+        if ( !prop )
+            early_panic("no start for module %d\n", i);
+
+        cell = (const u32 *)prop->data;
+        device_tree_get_reg(&cell, address_cells, size_cells,
+                            &mod->start, &size);
+
+        snprintf(propname, sizeof(propname), "module%d-end", i+1);
+        prop = fdt_get_property(fdt, node, propname, NULL);
+        if ( !prop )
+            early_panic("no end for module %d\n", i);
+
+        cell = (const u32 *)prop->data;
+        device_tree_get_reg(&cell, address_cells, size_cells,
+                            &mod->size, &size);
+        mod->size -= mod->start;
+    }
+
+    early_info.modules.nr_mods = nr_modules;
+}
+
 static int __init early_scan_node(const void *fdt,
                                   int node, const char *name, int depth,
                                   u32 address_cells, u32 size_cells,
@@ -236,6 +291,8 @@ static int __init early_scan_node(const void *fdt,
 {
     if ( device_tree_node_matches(fdt, node, "memory") )
         process_memory_node(fdt, node, name, address_cells, size_cells);
+    else if ( device_tree_node_matches(fdt, node, "chosen") )
+        process_chosen_node(fdt, node, name, address_cells, size_cells);
 
     return 0;
 }
diff --git a/xen/include/xen/device_tree.h b/xen/include/xen/device_tree.h
index 4d010c0..585fcc9 100644
--- a/xen/include/xen/device_tree.h
+++ b/xen/include/xen/device_tree.h
@@ -15,6 +15,7 @@
 #define DEVICE_TREE_MAX_DEPTH 16
 
 #define NR_MEM_BANKS 8
+#define NR_MODULES 2
 
 struct membank {
     paddr_t start;
@@ -26,8 +27,14 @@ struct dt_mem_info {
     struct membank bank[NR_MEM_BANKS];
 };
 
+struct dt_module_info {
+    int nr_mods;
+    struct membank module[NR_MODULES];
+};
+
 struct dt_early_info {
     struct dt_mem_info mem;
+    struct dt_module_info modules;
 };
 
 typedef int (*device_tree_node_func)(const void *fdt,
-- 
1.7.9.1


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

From xen-devel-bounces@lists.xen.org Mon Sep 03 13:31:21 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Sep 2012 13:31:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T8Wk4-0002BH-Bu; Mon, 03 Sep 2012 13:31: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 1T8Wk3-0002Ar-5s
	for xen-devel@lists.xen.org; Mon, 03 Sep 2012 13:31:03 +0000
Received: from [85.158.143.99:63823] by server-3.bemta-4.messagelabs.com id
	58/E0-08232-611B4405; Mon, 03 Sep 2012 13:31:02 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1346679058!18620742!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNzYzNjg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21037 invoked from network); 3 Sep 2012 13:31:00 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-14.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Sep 2012 13:31:00 -0000
X-IronPort-AV: E=Sophos;i="4.80,359,1344211200"; d="scan'208";a="206937949"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Sep 2012 13:30:58 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Mon, 3 Sep 2012 09:30: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 1T8Wjx-00089t-E5;
	Mon, 03 Sep 2012 14:30:57 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Date: Mon, 3 Sep 2012 13:30:46 +0000
Message-ID: <1346679056-8108-6-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.9.1
In-Reply-To: <1346678886.32462.9.camel@zakaz.uk.xensource.com>
References: <1346678886.32462.9.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH 06/16] arm: parse modules from DT during early
	boot.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

The bootloader should populate /chosen/nr-modules with the number of
modules and then for each module 0..nr-modules-1 it should populate
/chosen/moduleN-{start,end} with the physical address of the module.

The hypervisor allows for 2 modules (kernel and initrd). Currently we
don't do anything with them.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 xen/common/device_tree.c      |   57 +++++++++++++++++++++++++++++++++++++++++
 xen/include/xen/device_tree.h |    7 +++++
 2 files changed, 64 insertions(+), 0 deletions(-)

diff --git a/xen/common/device_tree.c b/xen/common/device_tree.c
index 3d1f0f4..226e3f3 100644
--- a/xen/common/device_tree.c
+++ b/xen/common/device_tree.c
@@ -229,6 +229,61 @@ static void __init process_memory_node(const void *fdt, int node,
     }
 }
 
+static void __init process_chosen_node(const void *fdt, int node,
+                                       const char *name,
+                                       u32 address_cells, u32 size_cells)
+{
+    const struct fdt_property *prop;
+    const u32 *cell;
+    paddr_t size;
+    int i, nr_modules;
+
+    prop = fdt_get_property(fdt, node, "nr-modules", NULL);
+    if ( !prop )
+    {
+        early_info.modules.nr_mods = 0;
+        return;
+    }
+
+    cell = (const u32 *)prop->data;
+    get_val(&cell, 1, (u64*)&nr_modules);
+
+    if ( nr_modules > NR_MODULES )
+    {
+        early_panic("too many modules %d > %d\n", nr_modules, NR_MODULES);
+    }
+
+    for ( i = 0; i < nr_modules; i++ )
+    {
+        struct membank *mod = &early_info.modules.module[i];
+        /* longest prop name is "start", single digit numbers of modules */
+        char propname[strlen("moduleX-start") + 1];
+
+        BUILD_BUG_ON(NR_MODULES > 9);
+
+        snprintf(propname, sizeof(propname), "module%d-start", i+1);
+        prop = fdt_get_property(fdt, node, propname, NULL);
+        if ( !prop )
+            early_panic("no start for module %d\n", i);
+
+        cell = (const u32 *)prop->data;
+        device_tree_get_reg(&cell, address_cells, size_cells,
+                            &mod->start, &size);
+
+        snprintf(propname, sizeof(propname), "module%d-end", i+1);
+        prop = fdt_get_property(fdt, node, propname, NULL);
+        if ( !prop )
+            early_panic("no end for module %d\n", i);
+
+        cell = (const u32 *)prop->data;
+        device_tree_get_reg(&cell, address_cells, size_cells,
+                            &mod->size, &size);
+        mod->size -= mod->start;
+    }
+
+    early_info.modules.nr_mods = nr_modules;
+}
+
 static int __init early_scan_node(const void *fdt,
                                   int node, const char *name, int depth,
                                   u32 address_cells, u32 size_cells,
@@ -236,6 +291,8 @@ static int __init early_scan_node(const void *fdt,
 {
     if ( device_tree_node_matches(fdt, node, "memory") )
         process_memory_node(fdt, node, name, address_cells, size_cells);
+    else if ( device_tree_node_matches(fdt, node, "chosen") )
+        process_chosen_node(fdt, node, name, address_cells, size_cells);
 
     return 0;
 }
diff --git a/xen/include/xen/device_tree.h b/xen/include/xen/device_tree.h
index 4d010c0..585fcc9 100644
--- a/xen/include/xen/device_tree.h
+++ b/xen/include/xen/device_tree.h
@@ -15,6 +15,7 @@
 #define DEVICE_TREE_MAX_DEPTH 16
 
 #define NR_MEM_BANKS 8
+#define NR_MODULES 2
 
 struct membank {
     paddr_t start;
@@ -26,8 +27,14 @@ struct dt_mem_info {
     struct membank bank[NR_MEM_BANKS];
 };
 
+struct dt_module_info {
+    int nr_mods;
+    struct membank module[NR_MODULES];
+};
+
 struct dt_early_info {
     struct dt_mem_info mem;
+    struct dt_module_info modules;
 };
 
 typedef int (*device_tree_node_func)(const void *fdt,
-- 
1.7.9.1


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

From xen-devel-bounces@lists.xen.org Mon Sep 03 13:31:21 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Sep 2012 13:31:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T8Wk3-0002B9-VS; Mon, 03 Sep 2012 13:31: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 1T8Wk2-0002Ar-Kg
	for xen-devel@lists.xen.org; Mon, 03 Sep 2012 13:31:02 +0000
Received: from [85.158.143.99:33378] by server-3.bemta-4.messagelabs.com id
	72/E0-08232-511B4405; Mon, 03 Sep 2012 13:31:01 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1346679058!18620742!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNzYzNjg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21001 invoked from network); 3 Sep 2012 13:30:59 -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;
	3 Sep 2012 13:30:59 -0000
X-IronPort-AV: E=Sophos;i="4.80,359,1344211200"; d="scan'208";a="206937948"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Sep 2012 13:30:58 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Mon, 3 Sep 2012 09:30: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 1T8Wjx-00089t-BY;
	Mon, 03 Sep 2012 14:30:57 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Date: Mon, 3 Sep 2012 13:30:45 +0000
Message-ID: <1346679056-8108-5-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.9.1
In-Reply-To: <1346678886.32462.9.camel@zakaz.uk.xensource.com>
References: <1346678886.32462.9.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH 05/16] arm: move get_paddr_function to arch
	setup.c from device_tree.c
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

It's not realy got any DT functionality in it and its only caller is
setup_pagetables.

Put it here because future patches want to incorporate of the module
layout in memory and I'd like to confine that to setup.c

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 xen/arch/arm/mm.c             |    5 +----
 xen/arch/arm/setup.c          |   35 ++++++++++++++++++++++++++++++++++-
 xen/common/device_tree.c      |   32 --------------------------------
 xen/include/asm-arm/mm.h      |    2 +-
 xen/include/xen/device_tree.h |    1 -
 5 files changed, 36 insertions(+), 39 deletions(-)

diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
index 08bc55b..52bb5c7 100644
--- a/xen/arch/arm/mm.c
+++ b/xen/arch/arm/mm.c
@@ -206,15 +206,12 @@ void unmap_domain_page(const void *va)
 
 /* Boot-time pagetable setup.
  * Changes here may need matching changes in head.S */
-void __init setup_pagetables(unsigned long boot_phys_offset)
+void __init setup_pagetables(unsigned long boot_phys_offset, paddr_t xen_paddr)
 {
-    paddr_t xen_paddr;
     unsigned long dest_va;
     lpae_t pte, *p;
     int i;
 
-    xen_paddr = device_tree_get_xen_paddr();
-
     /* Map the destination in the boot misc area. */
     dest_va = BOOT_MISC_VIRT_START;
     pte = mfn_to_xen_entry(xen_paddr >> PAGE_SHIFT);
diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index c4ca270..b466875 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -37,6 +37,7 @@
 #include <asm/current.h>
 #include <asm/setup.h>
 #include <asm/vfp.h>
+#include <asm/early_printk.h>
 #include "gic.h"
 
 static __attribute_used__ void init_done(void)
@@ -66,6 +67,38 @@ static void __init processor_id(void)
            READ_CP32(ID_ISAR3), READ_CP32(ID_ISAR4), READ_CP32(ID_ISAR5));
 }
 
+/**
+ * get_xen_paddr - get physical address to relocate Xen to
+ *
+ * Xen is relocated to the top of RAM and aligned to a XEN_PADDR_ALIGN
+ * boundary.
+ */
+static paddr_t __init get_xen_paddr(void)
+{
+    struct dt_mem_info *mi = &early_info.mem;
+    paddr_t min_size;
+    paddr_t paddr = 0, t;
+    int i;
+
+    min_size = (_end - _start + (XEN_PADDR_ALIGN-1)) & ~(XEN_PADDR_ALIGN-1);
+
+    /* Find the highest bank with enough space. */
+    for ( i = 0; i < mi->nr_banks; i++ )
+    {
+        if ( mi->bank[i].size >= min_size )
+        {
+            t = mi->bank[i].start + mi->bank[i].size - min_size;
+            if ( t > paddr )
+                paddr = t;
+        }
+    }
+
+    if ( !paddr )
+        early_panic("Not enough memory to relocate Xen\n");
+
+    return paddr;
+}
+
 static void __init setup_mm(unsigned long dtb_paddr, size_t dtb_size)
 {
     paddr_t ram_start;
@@ -155,7 +188,7 @@ void __init start_xen(unsigned long boot_phys_offset,
 
     cmdline_parse(device_tree_bootargs(fdt));
 
-    setup_pagetables(boot_phys_offset);
+    setup_pagetables(boot_phys_offset, get_xen_paddr());
 
 #ifdef EARLY_UART_ADDRESS
     /* Map the UART */
diff --git a/xen/common/device_tree.c b/xen/common/device_tree.c
index 04619f4..3d1f0f4 100644
--- a/xen/common/device_tree.c
+++ b/xen/common/device_tree.c
@@ -273,38 +273,6 @@ size_t __init device_tree_early_init(const void *fdt)
     return fdt_totalsize(fdt);
 }
 
-/**
- * device_tree_get_xen_paddr - get physical address to relocate Xen to
- *
- * Xen is relocated to the top of RAM and aligned to a XEN_PADDR_ALIGN
- * boundary.
- */
-paddr_t __init device_tree_get_xen_paddr(void)
-{
-    struct dt_mem_info *mi = &early_info.mem;
-    paddr_t min_size;
-    paddr_t paddr = 0, t;
-    int i;
-
-    min_size = (_end - _start + (XEN_PADDR_ALIGN-1)) & ~(XEN_PADDR_ALIGN-1);
-
-    /* Find the highest bank with enough space. */
-    for ( i = 0; i < mi->nr_banks; i++ )
-    {
-        if ( mi->bank[i].size >= min_size )
-        {
-            t = mi->bank[i].start + mi->bank[i].size - min_size;
-            if ( t > paddr )
-                paddr = t;
-        }
-    }
-
-    if ( !paddr )
-        early_panic("Not enough memory to relocate Xen\n");
-
-    return paddr;
-}
-
 /*
  * Local variables:
  * mode: C
diff --git a/xen/include/asm-arm/mm.h b/xen/include/asm-arm/mm.h
index 6498322..b0e5a67 100644
--- a/xen/include/asm-arm/mm.h
+++ b/xen/include/asm-arm/mm.h
@@ -138,7 +138,7 @@ extern unsigned long max_page;
 extern unsigned long total_pages;
 
 /* Boot-time pagetable setup */
-extern void setup_pagetables(unsigned long boot_phys_offset);
+extern void setup_pagetables(unsigned long boot_phys_offset, paddr_t xen_paddr);
 /* MMU setup for seccondary CPUS (which already have paging enabled) */
 extern void __cpuinit mmu_init_secondary_cpu(void);
 /* Set up the xenheap: up to 1GB of contiguous, always-mapped memory.
diff --git a/xen/include/xen/device_tree.h b/xen/include/xen/device_tree.h
index 8e1626c..4d010c0 100644
--- a/xen/include/xen/device_tree.h
+++ b/xen/include/xen/device_tree.h
@@ -39,7 +39,6 @@ extern struct dt_early_info early_info;
 extern void *device_tree_flattened;
 
 size_t device_tree_early_init(const void *fdt);
-paddr_t device_tree_get_xen_paddr(void);
 
 void device_tree_get_reg(const u32 **cell, u32 address_cells, u32 size_cells,
                          u64 *start, u64 *size);
-- 
1.7.9.1


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

From xen-devel-bounces@lists.xen.org Mon Sep 03 13:31:21 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Sep 2012 13:31:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T8Wk3-0002B9-VS; Mon, 03 Sep 2012 13:31: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 1T8Wk2-0002Ar-Kg
	for xen-devel@lists.xen.org; Mon, 03 Sep 2012 13:31:02 +0000
Received: from [85.158.143.99:33378] by server-3.bemta-4.messagelabs.com id
	72/E0-08232-511B4405; Mon, 03 Sep 2012 13:31:01 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1346679058!18620742!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNzYzNjg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21001 invoked from network); 3 Sep 2012 13:30:59 -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;
	3 Sep 2012 13:30:59 -0000
X-IronPort-AV: E=Sophos;i="4.80,359,1344211200"; d="scan'208";a="206937948"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Sep 2012 13:30:58 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Mon, 3 Sep 2012 09:30: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 1T8Wjx-00089t-BY;
	Mon, 03 Sep 2012 14:30:57 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Date: Mon, 3 Sep 2012 13:30:45 +0000
Message-ID: <1346679056-8108-5-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.9.1
In-Reply-To: <1346678886.32462.9.camel@zakaz.uk.xensource.com>
References: <1346678886.32462.9.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH 05/16] arm: move get_paddr_function to arch
	setup.c from device_tree.c
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

It's not realy got any DT functionality in it and its only caller is
setup_pagetables.

Put it here because future patches want to incorporate of the module
layout in memory and I'd like to confine that to setup.c

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 xen/arch/arm/mm.c             |    5 +----
 xen/arch/arm/setup.c          |   35 ++++++++++++++++++++++++++++++++++-
 xen/common/device_tree.c      |   32 --------------------------------
 xen/include/asm-arm/mm.h      |    2 +-
 xen/include/xen/device_tree.h |    1 -
 5 files changed, 36 insertions(+), 39 deletions(-)

diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
index 08bc55b..52bb5c7 100644
--- a/xen/arch/arm/mm.c
+++ b/xen/arch/arm/mm.c
@@ -206,15 +206,12 @@ void unmap_domain_page(const void *va)
 
 /* Boot-time pagetable setup.
  * Changes here may need matching changes in head.S */
-void __init setup_pagetables(unsigned long boot_phys_offset)
+void __init setup_pagetables(unsigned long boot_phys_offset, paddr_t xen_paddr)
 {
-    paddr_t xen_paddr;
     unsigned long dest_va;
     lpae_t pte, *p;
     int i;
 
-    xen_paddr = device_tree_get_xen_paddr();
-
     /* Map the destination in the boot misc area. */
     dest_va = BOOT_MISC_VIRT_START;
     pte = mfn_to_xen_entry(xen_paddr >> PAGE_SHIFT);
diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index c4ca270..b466875 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -37,6 +37,7 @@
 #include <asm/current.h>
 #include <asm/setup.h>
 #include <asm/vfp.h>
+#include <asm/early_printk.h>
 #include "gic.h"
 
 static __attribute_used__ void init_done(void)
@@ -66,6 +67,38 @@ static void __init processor_id(void)
            READ_CP32(ID_ISAR3), READ_CP32(ID_ISAR4), READ_CP32(ID_ISAR5));
 }
 
+/**
+ * get_xen_paddr - get physical address to relocate Xen to
+ *
+ * Xen is relocated to the top of RAM and aligned to a XEN_PADDR_ALIGN
+ * boundary.
+ */
+static paddr_t __init get_xen_paddr(void)
+{
+    struct dt_mem_info *mi = &early_info.mem;
+    paddr_t min_size;
+    paddr_t paddr = 0, t;
+    int i;
+
+    min_size = (_end - _start + (XEN_PADDR_ALIGN-1)) & ~(XEN_PADDR_ALIGN-1);
+
+    /* Find the highest bank with enough space. */
+    for ( i = 0; i < mi->nr_banks; i++ )
+    {
+        if ( mi->bank[i].size >= min_size )
+        {
+            t = mi->bank[i].start + mi->bank[i].size - min_size;
+            if ( t > paddr )
+                paddr = t;
+        }
+    }
+
+    if ( !paddr )
+        early_panic("Not enough memory to relocate Xen\n");
+
+    return paddr;
+}
+
 static void __init setup_mm(unsigned long dtb_paddr, size_t dtb_size)
 {
     paddr_t ram_start;
@@ -155,7 +188,7 @@ void __init start_xen(unsigned long boot_phys_offset,
 
     cmdline_parse(device_tree_bootargs(fdt));
 
-    setup_pagetables(boot_phys_offset);
+    setup_pagetables(boot_phys_offset, get_xen_paddr());
 
 #ifdef EARLY_UART_ADDRESS
     /* Map the UART */
diff --git a/xen/common/device_tree.c b/xen/common/device_tree.c
index 04619f4..3d1f0f4 100644
--- a/xen/common/device_tree.c
+++ b/xen/common/device_tree.c
@@ -273,38 +273,6 @@ size_t __init device_tree_early_init(const void *fdt)
     return fdt_totalsize(fdt);
 }
 
-/**
- * device_tree_get_xen_paddr - get physical address to relocate Xen to
- *
- * Xen is relocated to the top of RAM and aligned to a XEN_PADDR_ALIGN
- * boundary.
- */
-paddr_t __init device_tree_get_xen_paddr(void)
-{
-    struct dt_mem_info *mi = &early_info.mem;
-    paddr_t min_size;
-    paddr_t paddr = 0, t;
-    int i;
-
-    min_size = (_end - _start + (XEN_PADDR_ALIGN-1)) & ~(XEN_PADDR_ALIGN-1);
-
-    /* Find the highest bank with enough space. */
-    for ( i = 0; i < mi->nr_banks; i++ )
-    {
-        if ( mi->bank[i].size >= min_size )
-        {
-            t = mi->bank[i].start + mi->bank[i].size - min_size;
-            if ( t > paddr )
-                paddr = t;
-        }
-    }
-
-    if ( !paddr )
-        early_panic("Not enough memory to relocate Xen\n");
-
-    return paddr;
-}
-
 /*
  * Local variables:
  * mode: C
diff --git a/xen/include/asm-arm/mm.h b/xen/include/asm-arm/mm.h
index 6498322..b0e5a67 100644
--- a/xen/include/asm-arm/mm.h
+++ b/xen/include/asm-arm/mm.h
@@ -138,7 +138,7 @@ extern unsigned long max_page;
 extern unsigned long total_pages;
 
 /* Boot-time pagetable setup */
-extern void setup_pagetables(unsigned long boot_phys_offset);
+extern void setup_pagetables(unsigned long boot_phys_offset, paddr_t xen_paddr);
 /* MMU setup for seccondary CPUS (which already have paging enabled) */
 extern void __cpuinit mmu_init_secondary_cpu(void);
 /* Set up the xenheap: up to 1GB of contiguous, always-mapped memory.
diff --git a/xen/include/xen/device_tree.h b/xen/include/xen/device_tree.h
index 8e1626c..4d010c0 100644
--- a/xen/include/xen/device_tree.h
+++ b/xen/include/xen/device_tree.h
@@ -39,7 +39,6 @@ extern struct dt_early_info early_info;
 extern void *device_tree_flattened;
 
 size_t device_tree_early_init(const void *fdt);
-paddr_t device_tree_get_xen_paddr(void);
 
 void device_tree_get_reg(const u32 **cell, u32 address_cells, u32 size_cells,
                          u64 *start, u64 *size);
-- 
1.7.9.1


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

From xen-devel-bounces@lists.xen.org Mon Sep 03 13:31:21 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Sep 2012 13:31:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T8Wk1-0002Ak-Iz; Mon, 03 Sep 2012 13:31:01 +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 1T8Wjz-0002Ab-7v
	for xen-devel@lists.xen.org; Mon, 03 Sep 2012 13:30:59 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1346679044!9304325!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTEzODI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10718 invoked from network); 3 Sep 2012 13:30:44 -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;
	3 Sep 2012 13:30:44 -0000
X-IronPort-AV: E=Sophos;i="4.80,359,1344211200"; d="scan'208";a="14318573"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Sep 2012 13:30: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.279.1; Mon, 3 Sep 2012
	14:30:44 +0100
Message-ID: <1346679043.32462.11.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: <kvmarm@lists.cs.columbia.edu>, xen-devel <xen-devel@lists.xen.org>
Date: Mon, 3 Sep 2012 14:30:43 +0100
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Peter Maydell <peter.maydell@linaro.org>,
	Dave Martin <dave.martin@linaro.org>, boot-architecture@lists.linaro.org
Subject: [Xen-devel] boot-wrapper: simple multi module loading 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

Apparently kvmarm@ is the place for boot-wrapper discussions so
apologies for the otherwise Xen related mail ;)

The following implements support for a very basic protocol for loading
multiple "modules" and providing them to the kernel. The ARM port of Xen
uses this to support passing both a dom0 kernel and initrd to the
hypervisor "kernel".

The Xen side of this can be found in the series at:
        http://lists.xen.org/archives/html/xen-devel/2012-09/msg00065.html

With that you can boot Xen on arm using the semi-hosting feature of the
model (paths are host paths):
        $MODEL linux-system-semi.axf -C cluster.cpu0.semihosting-cmd_line=\
                	'--kernel xen-arm.bin \
                	 --module zImage earlyprintk=xenboot console=ttyAMA1 root=/dev/mmcblk0 ro \
                	 --dtb vexpress-v2p-aem-v7a-xen.dtb -- dom0_mem=256M'

Until we know what bootloaders are going to become common in the ARM
servers world it hard to know who we should be working with to define a
proper protocol going forward and which bootloaders to supply patches
for etc. If anyone has any pointers that would be very useful.

One thing I've been considering is a port of the multiboot protocol[0]
used on x86 to ARM.

It seems like there is at least the kernel of an idea to port Grub2 to
ARM[1] which makes a port of multiboot as well seem like a reasonable
thing since grub is the reference implementation of the multiboot spec.

Ian.

[0] http://www.gnu.org/software/grub/manual/multiboot/multiboot.html
[1] https://wiki.linaro.org/OfficeofCTO/Grub2

8<--------------------------------------------

>From bb3c6184beb57ba2649970b8e8568b29c0720294 Mon Sep 17 00:00:00 2001
From: Ian Campbell <ian.campbell@citrix.com>
Date: Thu, 23 Aug 2012 14:56:26 +0000
Subject: [PATCH] Implement simple multi-module support.

This implementation supports up to 2 modules, each with its own
command line.
---
 semi_loader.c |  129 ++++++++++++++++++++++++++++++++++++++++++++++++++++++--
 semi_loader.h |   16 +++++++-
 semihosting.h |    7 +++
 3 files changed, 146 insertions(+), 6 deletions(-)

diff --git a/semi_loader.c b/semi_loader.c
index 6677527..348a394 100644
--- a/semi_loader.c
+++ b/semi_loader.c
@@ -46,6 +46,7 @@ static void _print_info(char const **strings)
 
 #define CMDLINE_KERNEL "--kernel"
 #define CMDLINE_INITRD "--initrd"
+#define CMDLINE_MODULE "--module"
 #define CMDLINE_NOINITRD "--no-initrd"
 #define CMDLINE_DTB "--dtb"
 #define CMDLINE_FDT "--fdt"	/* deprecated */
@@ -99,7 +100,7 @@ static int _fdt_make_node(void *fdt, int parentoffset, const char *name)
 
 static void update_fdt(void **dest, struct loader_info *info)
 {
-	int e;
+	int e, m;
 	int _chosen;
 	void *fdt;
 	uint32_t const *p;
@@ -184,6 +185,31 @@ no_add_memory:
 	if(e < 0)
 		goto libfdt_error;
 
+	/* XXX this should be a loop & some string munging in lieu of printf */
+	if(info->nr_modules > 0) {
+		if ((e = fdt_setprop_cell(fdt, _chosen, "module1-start",
+					  info->module[0].start)) < 0)
+			goto libfdt_error;
+		if ((e = fdt_setprop_cell(fdt, _chosen, "module1-end",
+					  info->module[0].end)) < 0)
+			goto libfdt_error;
+		if ((e = fdt_setprop_string(fdt, _chosen, "module1-args",
+					  info->module[0].args)) < 0)
+			goto libfdt_error;
+	}
+	if(info->nr_modules > 1) {
+		if ((e = fdt_setprop_cell(fdt, _chosen, "module2-start",
+					  info->module[1].start)) < 0)
+			goto libfdt_error;
+		if ((e = fdt_setprop_cell(fdt, _chosen, "module2-end",
+					  info->module[1].end)) < 0)
+			goto libfdt_error;
+		if ((e = fdt_setprop_string(fdt, _chosen, "module2-args",
+					  info->module[1].args)) < 0)
+			goto libfdt_error;
+	}
+
+
 	if(info->initrd_start) {
 		uint32_t initrd_end = info->initrd_start + info->initrd_size;
 
@@ -196,6 +222,12 @@ no_add_memory:
 			goto libfdt_error;
 	}
 
+	if (info->nr_modules > 0) {
+		if ((e = fdt_setprop_cell(fdt, _chosen, "nr-modules",
+					  info->nr_modules)) < 0)
+			goto libfdt_error;
+	}
+
 	/* success */
 
 	/* clean up */
@@ -234,6 +266,18 @@ static void find_space(char **s)
 	*s = t;
 }
 
+static void find_delim(char **s, char const *delim)
+{
+	int l = strlen(delim);
+	char *t = *s;
+	while (*t) {
+		if (!strncmp(t, delim, l))
+			break;
+		t++;
+	}
+	*s = t;
+}
+
 static int match_word(char **s, char const *string)
 {
 	unsigned l;
@@ -260,7 +304,7 @@ static char *match_option(char **s, char const *option_string)
 		return (void *)0;
 
 	if(!**s)
-		usage_fatal("Option requires as argument: ",
+		usage_fatal("Option requires an argument: ",
 			option_string, "\n");
 
 	/* otherwise, *s now points to the argument */
@@ -275,6 +319,42 @@ static char *match_option(char **s, char const *option_string)
 	return arg;
 }
 
+/* Match up to the next -- */
+static int match_module_arg(char **s,
+			    char const *option_string,
+			    int no_more_room,
+			    char **mod, char **args)
+{
+	char *arg;
+	if(!match_word(s, option_string))
+		return 0;
+
+	if(!**s)
+		usage_fatal("Option requires an argument: ",
+			option_string, "\n");
+
+	if ( no_more_room )
+		usage_fatal("Too many modules\n");
+
+	/* *s points to the module */
+	*mod = *s;
+
+	find_space(s);
+	if(**s) {
+		*(*s)++ = '\0';	/* null-terminate if necessary */
+		skip_space(s);	/* skip any remaining space */
+	}
+
+	/* Now find the (optional) module arguments */
+	arg = *s;
+	find_delim(s, "--");
+	if (**s)
+		*((*s)-1) = '\0'; /* null-terminate if necessary */
+	if (arg != *s)
+		*args = arg;
+	return 1;
+}
+
 static void load_file_essential(void **dest, char const *filename,
 				unsigned *size, char const *failmsg)
 {
@@ -331,17 +411,23 @@ static char *fdt_arg = (void *)0;
 static char *dtb_arg = (void *)0;
 static char *cmdline_arg = (void *)0;
 static char *noinitrd_arg = (void *)0;
+static struct module_arg_t {
+	char *mod;
+	char *args;
+} module_args[MODULES_MAX];
+int nr_modules = 0;
 
 static const struct {
 	char const *option_string;
 	char **argp;
-	enum { OPT_ARG, OPT_BOOL, OPT_REST } action;
+	enum { OPT_ARG, OPT_BOOL, OPT_MODULE, OPT_REST } action;
 } options[] = {
 	{ CMDLINE_KERNEL,	&kernel_arg,	OPT_ARG		},
 	{ CMDLINE_INITRD,	&initrd_arg,	OPT_ARG		},
 	{ CMDLINE_NOINITRD,	&noinitrd_arg,	OPT_BOOL	},
 	{ CMDLINE_FDT,		&fdt_arg,	OPT_ARG		},
 	{ CMDLINE_DTB,		&dtb_arg,	OPT_ARG		},
+	{ CMDLINE_MODULE,	NULL,		OPT_MODULE	},
 	{ CMDLINE_REST,		&cmdline_arg,	OPT_REST	},
 };
 
@@ -391,8 +477,19 @@ void load_kernel(struct loader_info *info)
 						options[i].option_string))
 					continue;
 
-			*options[i].argp = cmdline;
-			goto args_done;
+				*options[i].argp = cmdline;
+				goto args_done;
+
+			case OPT_MODULE:
+				if (!match_module_arg(&cmdline,
+					options[i].option_string,
+					nr_modules >= MODULES_MAX,
+					&module_args[nr_modules].mod,
+					&module_args[nr_modules].args))
+					continue;
+
+				nr_modules++;
+				goto next_arg;
 
 			case OPT_ARG:
 				arg = match_option(&cmdline,
@@ -420,6 +517,11 @@ args_done:
 	if(initrd_arg && noinitrd_arg)
 		usage_fatal("Option --initrd conflicts with --no-initrd.\n");
 
+	if (initrd_arg && nr_modules)
+		usage_fatal("Option --initrd and --modules conflict\n");
+	if (noinitrd_arg && nr_modules)
+		usage_fatal("Option --no-initrd and --modules conflict\n");
+
 	if(fdt_arg) {
 		warn("--fdt is deprecated.  Please use --dtb instead.\n");
 
@@ -462,6 +564,23 @@ args_done:
 	} else
 		usage_fatal("Expected " CMDLINE_KERNEL "\n");
 
+	phys = PHYS_OFFSET + MODULES_OFFSET;
+	for (i = 0 ; i < nr_modules; i++)
+	{
+		unsigned size;
+
+		phys = ALIGN(phys, MODULES_ALIGN);
+
+		info->module[i].start = (unsigned)phys;
+
+		load_file_essential(&phys, module_args[i].mod, &size,
+				    "Failed to load module image");
+		info("Loaded module: ", module_args[i].mod, "\n");
+		info->module[i].end = (unsigned)phys;
+		info->module[i].args = module_args[i].args;
+	}
+	info->nr_modules = nr_modules;
+
 	/* move the kernel to the correct place, if necessary */
 
 	correct_kernel_location(info);
diff --git a/semi_loader.h b/semi_loader.h
index 6d9d565..a3a486a 100644
--- a/semi_loader.h
+++ b/semi_loader.h
@@ -57,7 +57,11 @@ static const char uImage_magic[] = {
 #define PHYS_OFFSET 0x80000000
 #define PHYS_SIZE 0x80000000 /* can limit on kernel cmdline if necessary */
 #define ATAGS_OFFSET 0x100
-#define TEXT_OFFSET 0x200000
+#define TEXT_OFFSET   0x200000
+#define MODULES_OFFSET   0xA00000
+
+#define MODULES_ALIGN 0x1000 /* Modules are 4K aligned */
+
 #define INITRD_OFFSET 0xD00000 /* qemu uses the same random offset */
 
 #define FDT_SIZE_MAX 0x10000	/* maximum size allowed for device tree blob */
@@ -71,6 +75,13 @@ static const char uImage_magic[] = {
 #define ALIGN_INT(n, size) (((n) + ((size) - 1)) & ~((size) - 1))
 #define ALIGN(p, size) ((void *)ALIGN_INT((unsigned)(p), size))
 
+#define MODULES_MAX 2
+struct module_t {
+	unsigned start;
+	unsigned end;
+	char *args;
+};
+
 struct loader_info {
 	unsigned kernel_size;	/* nonzero indicates preloaded kernel size */
 	unsigned initrd_start;	/* start of preloaded initrd, if any */
@@ -78,6 +89,9 @@ struct loader_info {
 	unsigned cmdline_start;	/* start of cmdline buffer */
 	unsigned cmdline_size;
 
+	struct module_t module[MODULES_MAX];
+	int nr_modules;
+
 	/* The remaining fields are set by the loader: */
 
 	/* There could be a built-in FDT, but currently that it not supported */
diff --git a/semihosting.h b/semihosting.h
index 40817c2..baad318 100644
--- a/semihosting.h
+++ b/semihosting.h
@@ -45,6 +45,13 @@ void semi_exit(void);
 /* semi_load_file: *dest is advanced to point to the end of the loaded data */
 int semi_load_file(void **dest, unsigned *size, char const *filename);
 
+/* Trigger a break point in the fast model... */
+#define MODEL_BKPT() asm volatile(\
+       "mov r0, #0x18;\n /* angel_SWIreason_ReportException */\n"\
+       "mov r1, #0x20000;/* 0x20020= ADP_Stopped_BreakPoint */\n"\
+       "orr r1, r1, #0x20;\n"\
+       "swi 0x123456;\n" ::: "r0", "r1")
+
 #endif /* ! __ASSEMBLER__ */
 
 #endif /* ! SEMIHOSTING_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 Mon Sep 03 13:31:21 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Sep 2012 13:31:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T8Wk1-0002Ak-Iz; Mon, 03 Sep 2012 13:31:01 +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 1T8Wjz-0002Ab-7v
	for xen-devel@lists.xen.org; Mon, 03 Sep 2012 13:30:59 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1346679044!9304325!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTEzODI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10718 invoked from network); 3 Sep 2012 13:30:44 -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;
	3 Sep 2012 13:30:44 -0000
X-IronPort-AV: E=Sophos;i="4.80,359,1344211200"; d="scan'208";a="14318573"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Sep 2012 13:30: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.279.1; Mon, 3 Sep 2012
	14:30:44 +0100
Message-ID: <1346679043.32462.11.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: <kvmarm@lists.cs.columbia.edu>, xen-devel <xen-devel@lists.xen.org>
Date: Mon, 3 Sep 2012 14:30:43 +0100
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Peter Maydell <peter.maydell@linaro.org>,
	Dave Martin <dave.martin@linaro.org>, boot-architecture@lists.linaro.org
Subject: [Xen-devel] boot-wrapper: simple multi module loading 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

Apparently kvmarm@ is the place for boot-wrapper discussions so
apologies for the otherwise Xen related mail ;)

The following implements support for a very basic protocol for loading
multiple "modules" and providing them to the kernel. The ARM port of Xen
uses this to support passing both a dom0 kernel and initrd to the
hypervisor "kernel".

The Xen side of this can be found in the series at:
        http://lists.xen.org/archives/html/xen-devel/2012-09/msg00065.html

With that you can boot Xen on arm using the semi-hosting feature of the
model (paths are host paths):
        $MODEL linux-system-semi.axf -C cluster.cpu0.semihosting-cmd_line=\
                	'--kernel xen-arm.bin \
                	 --module zImage earlyprintk=xenboot console=ttyAMA1 root=/dev/mmcblk0 ro \
                	 --dtb vexpress-v2p-aem-v7a-xen.dtb -- dom0_mem=256M'

Until we know what bootloaders are going to become common in the ARM
servers world it hard to know who we should be working with to define a
proper protocol going forward and which bootloaders to supply patches
for etc. If anyone has any pointers that would be very useful.

One thing I've been considering is a port of the multiboot protocol[0]
used on x86 to ARM.

It seems like there is at least the kernel of an idea to port Grub2 to
ARM[1] which makes a port of multiboot as well seem like a reasonable
thing since grub is the reference implementation of the multiboot spec.

Ian.

[0] http://www.gnu.org/software/grub/manual/multiboot/multiboot.html
[1] https://wiki.linaro.org/OfficeofCTO/Grub2

8<--------------------------------------------

>From bb3c6184beb57ba2649970b8e8568b29c0720294 Mon Sep 17 00:00:00 2001
From: Ian Campbell <ian.campbell@citrix.com>
Date: Thu, 23 Aug 2012 14:56:26 +0000
Subject: [PATCH] Implement simple multi-module support.

This implementation supports up to 2 modules, each with its own
command line.
---
 semi_loader.c |  129 ++++++++++++++++++++++++++++++++++++++++++++++++++++++--
 semi_loader.h |   16 +++++++-
 semihosting.h |    7 +++
 3 files changed, 146 insertions(+), 6 deletions(-)

diff --git a/semi_loader.c b/semi_loader.c
index 6677527..348a394 100644
--- a/semi_loader.c
+++ b/semi_loader.c
@@ -46,6 +46,7 @@ static void _print_info(char const **strings)
 
 #define CMDLINE_KERNEL "--kernel"
 #define CMDLINE_INITRD "--initrd"
+#define CMDLINE_MODULE "--module"
 #define CMDLINE_NOINITRD "--no-initrd"
 #define CMDLINE_DTB "--dtb"
 #define CMDLINE_FDT "--fdt"	/* deprecated */
@@ -99,7 +100,7 @@ static int _fdt_make_node(void *fdt, int parentoffset, const char *name)
 
 static void update_fdt(void **dest, struct loader_info *info)
 {
-	int e;
+	int e, m;
 	int _chosen;
 	void *fdt;
 	uint32_t const *p;
@@ -184,6 +185,31 @@ no_add_memory:
 	if(e < 0)
 		goto libfdt_error;
 
+	/* XXX this should be a loop & some string munging in lieu of printf */
+	if(info->nr_modules > 0) {
+		if ((e = fdt_setprop_cell(fdt, _chosen, "module1-start",
+					  info->module[0].start)) < 0)
+			goto libfdt_error;
+		if ((e = fdt_setprop_cell(fdt, _chosen, "module1-end",
+					  info->module[0].end)) < 0)
+			goto libfdt_error;
+		if ((e = fdt_setprop_string(fdt, _chosen, "module1-args",
+					  info->module[0].args)) < 0)
+			goto libfdt_error;
+	}
+	if(info->nr_modules > 1) {
+		if ((e = fdt_setprop_cell(fdt, _chosen, "module2-start",
+					  info->module[1].start)) < 0)
+			goto libfdt_error;
+		if ((e = fdt_setprop_cell(fdt, _chosen, "module2-end",
+					  info->module[1].end)) < 0)
+			goto libfdt_error;
+		if ((e = fdt_setprop_string(fdt, _chosen, "module2-args",
+					  info->module[1].args)) < 0)
+			goto libfdt_error;
+	}
+
+
 	if(info->initrd_start) {
 		uint32_t initrd_end = info->initrd_start + info->initrd_size;
 
@@ -196,6 +222,12 @@ no_add_memory:
 			goto libfdt_error;
 	}
 
+	if (info->nr_modules > 0) {
+		if ((e = fdt_setprop_cell(fdt, _chosen, "nr-modules",
+					  info->nr_modules)) < 0)
+			goto libfdt_error;
+	}
+
 	/* success */
 
 	/* clean up */
@@ -234,6 +266,18 @@ static void find_space(char **s)
 	*s = t;
 }
 
+static void find_delim(char **s, char const *delim)
+{
+	int l = strlen(delim);
+	char *t = *s;
+	while (*t) {
+		if (!strncmp(t, delim, l))
+			break;
+		t++;
+	}
+	*s = t;
+}
+
 static int match_word(char **s, char const *string)
 {
 	unsigned l;
@@ -260,7 +304,7 @@ static char *match_option(char **s, char const *option_string)
 		return (void *)0;
 
 	if(!**s)
-		usage_fatal("Option requires as argument: ",
+		usage_fatal("Option requires an argument: ",
 			option_string, "\n");
 
 	/* otherwise, *s now points to the argument */
@@ -275,6 +319,42 @@ static char *match_option(char **s, char const *option_string)
 	return arg;
 }
 
+/* Match up to the next -- */
+static int match_module_arg(char **s,
+			    char const *option_string,
+			    int no_more_room,
+			    char **mod, char **args)
+{
+	char *arg;
+	if(!match_word(s, option_string))
+		return 0;
+
+	if(!**s)
+		usage_fatal("Option requires an argument: ",
+			option_string, "\n");
+
+	if ( no_more_room )
+		usage_fatal("Too many modules\n");
+
+	/* *s points to the module */
+	*mod = *s;
+
+	find_space(s);
+	if(**s) {
+		*(*s)++ = '\0';	/* null-terminate if necessary */
+		skip_space(s);	/* skip any remaining space */
+	}
+
+	/* Now find the (optional) module arguments */
+	arg = *s;
+	find_delim(s, "--");
+	if (**s)
+		*((*s)-1) = '\0'; /* null-terminate if necessary */
+	if (arg != *s)
+		*args = arg;
+	return 1;
+}
+
 static void load_file_essential(void **dest, char const *filename,
 				unsigned *size, char const *failmsg)
 {
@@ -331,17 +411,23 @@ static char *fdt_arg = (void *)0;
 static char *dtb_arg = (void *)0;
 static char *cmdline_arg = (void *)0;
 static char *noinitrd_arg = (void *)0;
+static struct module_arg_t {
+	char *mod;
+	char *args;
+} module_args[MODULES_MAX];
+int nr_modules = 0;
 
 static const struct {
 	char const *option_string;
 	char **argp;
-	enum { OPT_ARG, OPT_BOOL, OPT_REST } action;
+	enum { OPT_ARG, OPT_BOOL, OPT_MODULE, OPT_REST } action;
 } options[] = {
 	{ CMDLINE_KERNEL,	&kernel_arg,	OPT_ARG		},
 	{ CMDLINE_INITRD,	&initrd_arg,	OPT_ARG		},
 	{ CMDLINE_NOINITRD,	&noinitrd_arg,	OPT_BOOL	},
 	{ CMDLINE_FDT,		&fdt_arg,	OPT_ARG		},
 	{ CMDLINE_DTB,		&dtb_arg,	OPT_ARG		},
+	{ CMDLINE_MODULE,	NULL,		OPT_MODULE	},
 	{ CMDLINE_REST,		&cmdline_arg,	OPT_REST	},
 };
 
@@ -391,8 +477,19 @@ void load_kernel(struct loader_info *info)
 						options[i].option_string))
 					continue;
 
-			*options[i].argp = cmdline;
-			goto args_done;
+				*options[i].argp = cmdline;
+				goto args_done;
+
+			case OPT_MODULE:
+				if (!match_module_arg(&cmdline,
+					options[i].option_string,
+					nr_modules >= MODULES_MAX,
+					&module_args[nr_modules].mod,
+					&module_args[nr_modules].args))
+					continue;
+
+				nr_modules++;
+				goto next_arg;
 
 			case OPT_ARG:
 				arg = match_option(&cmdline,
@@ -420,6 +517,11 @@ args_done:
 	if(initrd_arg && noinitrd_arg)
 		usage_fatal("Option --initrd conflicts with --no-initrd.\n");
 
+	if (initrd_arg && nr_modules)
+		usage_fatal("Option --initrd and --modules conflict\n");
+	if (noinitrd_arg && nr_modules)
+		usage_fatal("Option --no-initrd and --modules conflict\n");
+
 	if(fdt_arg) {
 		warn("--fdt is deprecated.  Please use --dtb instead.\n");
 
@@ -462,6 +564,23 @@ args_done:
 	} else
 		usage_fatal("Expected " CMDLINE_KERNEL "\n");
 
+	phys = PHYS_OFFSET + MODULES_OFFSET;
+	for (i = 0 ; i < nr_modules; i++)
+	{
+		unsigned size;
+
+		phys = ALIGN(phys, MODULES_ALIGN);
+
+		info->module[i].start = (unsigned)phys;
+
+		load_file_essential(&phys, module_args[i].mod, &size,
+				    "Failed to load module image");
+		info("Loaded module: ", module_args[i].mod, "\n");
+		info->module[i].end = (unsigned)phys;
+		info->module[i].args = module_args[i].args;
+	}
+	info->nr_modules = nr_modules;
+
 	/* move the kernel to the correct place, if necessary */
 
 	correct_kernel_location(info);
diff --git a/semi_loader.h b/semi_loader.h
index 6d9d565..a3a486a 100644
--- a/semi_loader.h
+++ b/semi_loader.h
@@ -57,7 +57,11 @@ static const char uImage_magic[] = {
 #define PHYS_OFFSET 0x80000000
 #define PHYS_SIZE 0x80000000 /* can limit on kernel cmdline if necessary */
 #define ATAGS_OFFSET 0x100
-#define TEXT_OFFSET 0x200000
+#define TEXT_OFFSET   0x200000
+#define MODULES_OFFSET   0xA00000
+
+#define MODULES_ALIGN 0x1000 /* Modules are 4K aligned */
+
 #define INITRD_OFFSET 0xD00000 /* qemu uses the same random offset */
 
 #define FDT_SIZE_MAX 0x10000	/* maximum size allowed for device tree blob */
@@ -71,6 +75,13 @@ static const char uImage_magic[] = {
 #define ALIGN_INT(n, size) (((n) + ((size) - 1)) & ~((size) - 1))
 #define ALIGN(p, size) ((void *)ALIGN_INT((unsigned)(p), size))
 
+#define MODULES_MAX 2
+struct module_t {
+	unsigned start;
+	unsigned end;
+	char *args;
+};
+
 struct loader_info {
 	unsigned kernel_size;	/* nonzero indicates preloaded kernel size */
 	unsigned initrd_start;	/* start of preloaded initrd, if any */
@@ -78,6 +89,9 @@ struct loader_info {
 	unsigned cmdline_start;	/* start of cmdline buffer */
 	unsigned cmdline_size;
 
+	struct module_t module[MODULES_MAX];
+	int nr_modules;
+
 	/* The remaining fields are set by the loader: */
 
 	/* There could be a built-in FDT, but currently that it not supported */
diff --git a/semihosting.h b/semihosting.h
index 40817c2..baad318 100644
--- a/semihosting.h
+++ b/semihosting.h
@@ -45,6 +45,13 @@ void semi_exit(void);
 /* semi_load_file: *dest is advanced to point to the end of the loaded data */
 int semi_load_file(void **dest, unsigned *size, char const *filename);
 
+/* Trigger a break point in the fast model... */
+#define MODEL_BKPT() asm volatile(\
+       "mov r0, #0x18;\n /* angel_SWIreason_ReportException */\n"\
+       "mov r1, #0x20000;/* 0x20020= ADP_Stopped_BreakPoint */\n"\
+       "orr r1, r1, #0x20;\n"\
+       "swi 0x123456;\n" ::: "r0", "r1")
+
 #endif /* ! __ASSEMBLER__ */
 
 #endif /* ! SEMIHOSTING_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 Mon Sep 03 13:31:23 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Sep 2012 13: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 1T8Wk9-0002Cr-AN; Mon, 03 Sep 2012 13:31: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 1T8Wk7-0002Ar-Kh
	for xen-devel@lists.xen.org; Mon, 03 Sep 2012 13:31:07 +0000
Received: from [85.158.143.35:41822] by server-3.bemta-4.messagelabs.com id
	B1/11-08232-B11B4405; Mon, 03 Sep 2012 13:31:07 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1346679061!14618481!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNjgzNzM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5130 invoked from network); 3 Sep 2012 13:31:04 -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;
	3 Sep 2012 13:31:04 -0000
X-IronPort-AV: E=Sophos;i="4.80,359,1344211200"; d="scan'208";a="36611263"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Sep 2012 13:30:58 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Mon, 3 Sep 2012 09:30: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 1T8Wjx-00089t-Hh;
	Mon, 03 Sep 2012 14:30:57 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Date: Mon, 3 Sep 2012 13:30:48 +0000
Message-ID: <1346679056-8108-8-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.9.1
In-Reply-To: <1346678886.32462.9.camel@zakaz.uk.xensource.com>
References: <1346678886.32462.9.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH 08/16] arm: really allocate boot frametable
	pages with 32M alignment
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This argument to alloc_boot_pages is "pfn_align" and not an order.
We've been lucky until now that the area given to the boot allocator
happened to be properly aligned and this allocation was early enough
to benefit.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 xen/arch/arm/mm.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
index 52bb5c7..aafc48c 100644
--- a/xen/arch/arm/mm.c
+++ b/xen/arch/arm/mm.c
@@ -353,7 +353,7 @@ void __init setup_frametable_mappings(paddr_t ps, paddr_t pe)
 
     /* Round up to 32M boundary */
     frametable_size = (frametable_size + 0x1ffffff) & ~0x1ffffff;
-    base_mfn = alloc_boot_pages(frametable_size >> PAGE_SHIFT, 5);
+    base_mfn = alloc_boot_pages(frametable_size >> PAGE_SHIFT, 32<<(20-12));
     create_mappings(FRAMETABLE_VIRT_START, base_mfn, frametable_size >> PAGE_SHIFT);
 
     memset(&frame_table[0], 0, nr_pages * sizeof(struct page_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 Mon Sep 03 13:31:23 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Sep 2012 13: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 1T8Wk9-0002Cr-AN; Mon, 03 Sep 2012 13:31: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 1T8Wk7-0002Ar-Kh
	for xen-devel@lists.xen.org; Mon, 03 Sep 2012 13:31:07 +0000
Received: from [85.158.143.35:41822] by server-3.bemta-4.messagelabs.com id
	B1/11-08232-B11B4405; Mon, 03 Sep 2012 13:31:07 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1346679061!14618481!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNjgzNzM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5130 invoked from network); 3 Sep 2012 13:31:04 -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;
	3 Sep 2012 13:31:04 -0000
X-IronPort-AV: E=Sophos;i="4.80,359,1344211200"; d="scan'208";a="36611263"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Sep 2012 13:30:58 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Mon, 3 Sep 2012 09:30: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 1T8Wjx-00089t-Hh;
	Mon, 03 Sep 2012 14:30:57 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Date: Mon, 3 Sep 2012 13:30:48 +0000
Message-ID: <1346679056-8108-8-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.9.1
In-Reply-To: <1346678886.32462.9.camel@zakaz.uk.xensource.com>
References: <1346678886.32462.9.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH 08/16] arm: really allocate boot frametable
	pages with 32M alignment
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This argument to alloc_boot_pages is "pfn_align" and not an order.
We've been lucky until now that the area given to the boot allocator
happened to be properly aligned and this allocation was early enough
to benefit.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 xen/arch/arm/mm.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
index 52bb5c7..aafc48c 100644
--- a/xen/arch/arm/mm.c
+++ b/xen/arch/arm/mm.c
@@ -353,7 +353,7 @@ void __init setup_frametable_mappings(paddr_t ps, paddr_t pe)
 
     /* Round up to 32M boundary */
     frametable_size = (frametable_size + 0x1ffffff) & ~0x1ffffff;
-    base_mfn = alloc_boot_pages(frametable_size >> PAGE_SHIFT, 5);
+    base_mfn = alloc_boot_pages(frametable_size >> PAGE_SHIFT, 32<<(20-12));
     create_mappings(FRAMETABLE_VIRT_START, base_mfn, frametable_size >> PAGE_SHIFT);
 
     memset(&frame_table[0], 0, nr_pages * sizeof(struct page_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 Mon Sep 03 13:31:25 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Sep 2012 13:31:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T8WkF-0002Em-3Q; Mon, 03 Sep 2012 13:31:15 +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 1T8WkD-0002CQ-1x
	for xen-devel@lists.xen.org; Mon, 03 Sep 2012 13:31:13 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1346679060!6921075!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNjgzNzM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26734 invoked from network); 3 Sep 2012 13:31:02 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Sep 2012 13:31:02 -0000
X-IronPort-AV: E=Sophos;i="4.80,359,1344211200"; d="scan'208";a="36611262"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Sep 2012 13:30:57 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Mon, 3 Sep 2012 09:30: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 1T8Wjx-00089t-AM;
	Mon, 03 Sep 2012 14:30:57 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Date: Mon, 3 Sep 2012 13:30:44 +0000
Message-ID: <1346679056-8108-4-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.9.1
In-Reply-To: <1346678886.32462.9.camel@zakaz.uk.xensource.com>
References: <1346678886.32462.9.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH 04/16] arm: handle xenheap which isn't at the
	start of RAM.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Also refactor page_to_virt somewhat in an attempt to make it clearer
what is happening.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 xen/include/asm-arm/mm.h |   24 +++++++++++++++++++-----
 1 files changed, 19 insertions(+), 5 deletions(-)

diff --git a/xen/include/asm-arm/mm.h b/xen/include/asm-arm/mm.h
index b37bd35..6498322 100644
--- a/xen/include/asm-arm/mm.h
+++ b/xen/include/asm-arm/mm.h
@@ -214,17 +214,31 @@ static inline struct page_info *virt_to_page(const void *v)
     ASSERT(va >= XENHEAP_VIRT_START);
     ASSERT(va < xenheap_virt_end);
 
-    return frame_table + ((va - XENHEAP_VIRT_START) >> PAGE_SHIFT);
+    return frame_table
+        + ((va - XENHEAP_VIRT_START) >> PAGE_SHIFT)
+        + xenheap_mfn_start
+        - frametable_base_mfn;
 }
 
 static inline void *page_to_virt(const struct page_info *pg)
 {
+    unsigned long va;
+    const unsigned long offset =
+        (xenheap_mfn_start-frametable_base_mfn)*sizeof(*pg);
+
+    /*
+     * Dividing by this on both top and bottom factors out the largest
+     * common factor of 2 which helps the compiler to use smaller shifts.
+     */
+    const unsigned long lcd = (sizeof(*pg) & -sizeof(*pg));
+
     ASSERT((unsigned long)pg - FRAMETABLE_VIRT_START < frametable_virt_end);
-    return (void *)(XENHEAP_VIRT_START +
-                    ((unsigned long)pg - FRAMETABLE_VIRT_START) /
-                    (sizeof(*pg) / (sizeof(*pg) & -sizeof(*pg))) *
-                    (PAGE_SIZE / (sizeof(*pg) & -sizeof(*pg))));
 
+    va = (unsigned long)pg;
+    va = XENHEAP_VIRT_START +
+        ((va - FRAMETABLE_VIRT_START - offset) / (sizeof(*pg) / lcd)) *
+        (PAGE_SIZE / lcd);
+    return (void *)va;
 }
 
 struct domain *page_get_owner_and_reference(struct page_info *page);
-- 
1.7.9.1


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

From xen-devel-bounces@lists.xen.org Mon Sep 03 13:31:25 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Sep 2012 13:31:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T8WkF-0002Em-3Q; Mon, 03 Sep 2012 13:31:15 +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 1T8WkD-0002CQ-1x
	for xen-devel@lists.xen.org; Mon, 03 Sep 2012 13:31:13 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1346679060!6921075!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNjgzNzM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26734 invoked from network); 3 Sep 2012 13:31:02 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Sep 2012 13:31:02 -0000
X-IronPort-AV: E=Sophos;i="4.80,359,1344211200"; d="scan'208";a="36611262"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Sep 2012 13:30:57 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Mon, 3 Sep 2012 09:30: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 1T8Wjx-00089t-AM;
	Mon, 03 Sep 2012 14:30:57 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Date: Mon, 3 Sep 2012 13:30:44 +0000
Message-ID: <1346679056-8108-4-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.9.1
In-Reply-To: <1346678886.32462.9.camel@zakaz.uk.xensource.com>
References: <1346678886.32462.9.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH 04/16] arm: handle xenheap which isn't at the
	start of RAM.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Also refactor page_to_virt somewhat in an attempt to make it clearer
what is happening.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 xen/include/asm-arm/mm.h |   24 +++++++++++++++++++-----
 1 files changed, 19 insertions(+), 5 deletions(-)

diff --git a/xen/include/asm-arm/mm.h b/xen/include/asm-arm/mm.h
index b37bd35..6498322 100644
--- a/xen/include/asm-arm/mm.h
+++ b/xen/include/asm-arm/mm.h
@@ -214,17 +214,31 @@ static inline struct page_info *virt_to_page(const void *v)
     ASSERT(va >= XENHEAP_VIRT_START);
     ASSERT(va < xenheap_virt_end);
 
-    return frame_table + ((va - XENHEAP_VIRT_START) >> PAGE_SHIFT);
+    return frame_table
+        + ((va - XENHEAP_VIRT_START) >> PAGE_SHIFT)
+        + xenheap_mfn_start
+        - frametable_base_mfn;
 }
 
 static inline void *page_to_virt(const struct page_info *pg)
 {
+    unsigned long va;
+    const unsigned long offset =
+        (xenheap_mfn_start-frametable_base_mfn)*sizeof(*pg);
+
+    /*
+     * Dividing by this on both top and bottom factors out the largest
+     * common factor of 2 which helps the compiler to use smaller shifts.
+     */
+    const unsigned long lcd = (sizeof(*pg) & -sizeof(*pg));
+
     ASSERT((unsigned long)pg - FRAMETABLE_VIRT_START < frametable_virt_end);
-    return (void *)(XENHEAP_VIRT_START +
-                    ((unsigned long)pg - FRAMETABLE_VIRT_START) /
-                    (sizeof(*pg) / (sizeof(*pg) & -sizeof(*pg))) *
-                    (PAGE_SIZE / (sizeof(*pg) & -sizeof(*pg))));
 
+    va = (unsigned long)pg;
+    va = XENHEAP_VIRT_START +
+        ((va - FRAMETABLE_VIRT_START - offset) / (sizeof(*pg) / lcd)) *
+        (PAGE_SIZE / lcd);
+    return (void *)va;
 }
 
 struct domain *page_get_owner_and_reference(struct page_info *page);
-- 
1.7.9.1


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

From xen-devel-bounces@lists.xen.org Mon Sep 03 13:31:25 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Sep 2012 13:31:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T8WkE-0002Eb-NT; Mon, 03 Sep 2012 13:31:14 +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 1T8WkD-0002CN-0O
	for xen-devel@lists.xen.org; Mon, 03 Sep 2012 13:31:13 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1346679060!6921075!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNjgzNzM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26849 invoked from network); 3 Sep 2012 13:31:03 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Sep 2012 13:31:03 -0000
X-IronPort-AV: E=Sophos;i="4.80,359,1344211200"; d="scan'208";a="36611264"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Sep 2012 13:30:58 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Mon, 3 Sep 2012 09:30: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 1T8Wjx-00089t-LQ;
	Mon, 03 Sep 2012 14:30:57 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Date: Mon, 3 Sep 2012 13:30:50 +0000
Message-ID: <1346679056-8108-10-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.9.1
In-Reply-To: <1346678886.32462.9.camel@zakaz.uk.xensource.com>
References: <1346678886.32462.9.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH 10/16] arm: print a message if multiple banks of
	memory are present.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="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 |    2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index 369e164..85487fe 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -218,6 +218,8 @@ static void __init setup_mm(unsigned long dtb_paddr, size_t dtb_size)
      * TODO: only using the first RAM bank for now.  The heaps and the
      * frame table assume RAM is physically contiguous.
      */
+    if ( early_info.mem.nr_banks > 1 )
+        early_printk("WARNING: Only using first bank of memory\n");
     ram_start = early_info.mem.bank[0].start;
     ram_size  = early_info.mem.bank[0].size;
     ram_end = ram_start + ram_size;
-- 
1.7.9.1


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

From xen-devel-bounces@lists.xen.org Mon Sep 03 13:31:25 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Sep 2012 13:31:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T8WkE-0002Eb-NT; Mon, 03 Sep 2012 13:31:14 +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 1T8WkD-0002CN-0O
	for xen-devel@lists.xen.org; Mon, 03 Sep 2012 13:31:13 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1346679060!6921075!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNjgzNzM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26849 invoked from network); 3 Sep 2012 13:31:03 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Sep 2012 13:31:03 -0000
X-IronPort-AV: E=Sophos;i="4.80,359,1344211200"; d="scan'208";a="36611264"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Sep 2012 13:30:58 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Mon, 3 Sep 2012 09:30: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 1T8Wjx-00089t-LQ;
	Mon, 03 Sep 2012 14:30:57 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Date: Mon, 3 Sep 2012 13:30:50 +0000
Message-ID: <1346679056-8108-10-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.9.1
In-Reply-To: <1346678886.32462.9.camel@zakaz.uk.xensource.com>
References: <1346678886.32462.9.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH 10/16] arm: print a message if multiple banks of
	memory are present.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="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 |    2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index 369e164..85487fe 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -218,6 +218,8 @@ static void __init setup_mm(unsigned long dtb_paddr, size_t dtb_size)
      * TODO: only using the first RAM bank for now.  The heaps and the
      * frame table assume RAM is physically contiguous.
      */
+    if ( early_info.mem.nr_banks > 1 )
+        early_printk("WARNING: Only using first bank of memory\n");
     ram_start = early_info.mem.bank[0].start;
     ram_size  = early_info.mem.bank[0].size;
     ram_end = ram_start + ram_size;
-- 
1.7.9.1


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

From xen-devel-bounces@lists.xen.org Mon Sep 03 13:31:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Sep 2012 13:31: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 1T8WkF-0002Ex-Hi; Mon, 03 Sep 2012 13:31:15 +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 1T8WkD-0002Ch-OS
	for xen-devel@lists.xen.org; Mon, 03 Sep 2012 13:31:13 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1346679058!9304385!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNjgzNzM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11665 invoked from network); 3 Sep 2012 13:30:59 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Sep 2012 13:30:59 -0000
X-IronPort-AV: E=Sophos;i="4.80,359,1344211200"; d="scan'208";a="36611259"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Sep 2012 13:30:57 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Mon, 3 Sep 2012 09:30: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 1T8Wjx-00089t-6g;
	Mon, 03 Sep 2012 14:30:57 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Date: Mon, 3 Sep 2012 13:30:41 +0000
Message-ID: <1346679056-8108-1-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.9.1
In-Reply-To: <1346678886.32462.9.camel@zakaz.uk.xensource.com>
References: <1346678886.32462.9.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH 01/16] arm: Zero the BSS at start of day.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Avoids surprises e.g. when loading via the boot-wrapper.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 xen/arch/arm/head.S    |   20 +++++++++++++++++++-
 xen/arch/arm/xen.lds.S |    1 +
 2 files changed, 20 insertions(+), 1 deletions(-)

diff --git a/xen/arch/arm/head.S b/xen/arch/arm/head.S
index cdbe011..131cdf9 100644
--- a/xen/arch/arm/head.S
+++ b/xen/arch/arm/head.S
@@ -127,8 +127,26 @@ boot_cpu:
 	add   pc, r0, r10            /* Call PA of function */
 
 hyp:
-	PRINT("- Setting up control registers -\r\n")
 
+	/* Zero BSS On the boot CPU to avoid nasty surprises */
+	teq   r12, #0
+	bne   skip_bss
+
+	PRINT("- Zero BSS -\r\n")
+	ldr   r0, =__bss_start       /* Load start & end of bss */
+	ldr   r1, =__bss_end
+	add   r0, r0, r10            /* Apply physical offset */  
+	add   r1, r1, r10
+	
+	mov   r2, #0
+1:	str   r2, [r0], #4
+	cmp   r0, r1
+	blo   1b
+
+skip_bss:	
+
+	PRINT("- Setting up control registers -\r\n")
+	
 	/* Set up memory attribute type tables */
 	ldr   r0, =MAIR0VAL
 	ldr   r1, =MAIR1VAL
diff --git a/xen/arch/arm/xen.lds.S b/xen/arch/arm/xen.lds.S
index 4a9d086..410d7db 100644
--- a/xen/arch/arm/xen.lds.S
+++ b/xen/arch/arm/xen.lds.S
@@ -119,6 +119,7 @@ SECTIONS
        *(.bss.percpu.read_mostly)
        . = ALIGN(SMP_CACHE_BYTES);
        __per_cpu_data_end = .;
+       __bss_end = .;
   } :text
   _end = . ;
 
-- 
1.7.9.1


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

From xen-devel-bounces@lists.xen.org Mon Sep 03 13:31:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Sep 2012 13:31: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 1T8WkF-0002Ex-Hi; Mon, 03 Sep 2012 13:31:15 +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 1T8WkD-0002Ch-OS
	for xen-devel@lists.xen.org; Mon, 03 Sep 2012 13:31:13 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1346679058!9304385!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNjgzNzM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11665 invoked from network); 3 Sep 2012 13:30:59 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Sep 2012 13:30:59 -0000
X-IronPort-AV: E=Sophos;i="4.80,359,1344211200"; d="scan'208";a="36611259"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Sep 2012 13:30:57 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Mon, 3 Sep 2012 09:30: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 1T8Wjx-00089t-6g;
	Mon, 03 Sep 2012 14:30:57 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Date: Mon, 3 Sep 2012 13:30:41 +0000
Message-ID: <1346679056-8108-1-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.9.1
In-Reply-To: <1346678886.32462.9.camel@zakaz.uk.xensource.com>
References: <1346678886.32462.9.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH 01/16] arm: Zero the BSS at start of day.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Avoids surprises e.g. when loading via the boot-wrapper.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 xen/arch/arm/head.S    |   20 +++++++++++++++++++-
 xen/arch/arm/xen.lds.S |    1 +
 2 files changed, 20 insertions(+), 1 deletions(-)

diff --git a/xen/arch/arm/head.S b/xen/arch/arm/head.S
index cdbe011..131cdf9 100644
--- a/xen/arch/arm/head.S
+++ b/xen/arch/arm/head.S
@@ -127,8 +127,26 @@ boot_cpu:
 	add   pc, r0, r10            /* Call PA of function */
 
 hyp:
-	PRINT("- Setting up control registers -\r\n")
 
+	/* Zero BSS On the boot CPU to avoid nasty surprises */
+	teq   r12, #0
+	bne   skip_bss
+
+	PRINT("- Zero BSS -\r\n")
+	ldr   r0, =__bss_start       /* Load start & end of bss */
+	ldr   r1, =__bss_end
+	add   r0, r0, r10            /* Apply physical offset */  
+	add   r1, r1, r10
+	
+	mov   r2, #0
+1:	str   r2, [r0], #4
+	cmp   r0, r1
+	blo   1b
+
+skip_bss:	
+
+	PRINT("- Setting up control registers -\r\n")
+	
 	/* Set up memory attribute type tables */
 	ldr   r0, =MAIR0VAL
 	ldr   r1, =MAIR1VAL
diff --git a/xen/arch/arm/xen.lds.S b/xen/arch/arm/xen.lds.S
index 4a9d086..410d7db 100644
--- a/xen/arch/arm/xen.lds.S
+++ b/xen/arch/arm/xen.lds.S
@@ -119,6 +119,7 @@ SECTIONS
        *(.bss.percpu.read_mostly)
        . = ALIGN(SMP_CACHE_BYTES);
        __per_cpu_data_end = .;
+       __bss_end = .;
   } :text
   _end = . ;
 
-- 
1.7.9.1


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

From xen-devel-bounces@lists.xen.org Mon Sep 03 13:31:32 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Sep 2012 13:31:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T8WkM-0002JH-W7; Mon, 03 Sep 2012 13:31:22 +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 1T8WkK-0002F3-V4
	for xen-devel@lists.xen.org; Mon, 03 Sep 2012 13:31:21 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1346679058!9304385!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNjgzNzM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11755 invoked from network); 3 Sep 2012 13:31:00 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Sep 2012 13:31:00 -0000
X-IronPort-AV: E=Sophos;i="4.80,359,1344211200"; d="scan'208";a="36611260"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Sep 2012 13:30:57 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Mon, 3 Sep 2012 09:30: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 1T8Wjx-00089t-7w;
	Mon, 03 Sep 2012 14:30:57 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Date: Mon, 3 Sep 2012 13:30:42 +0000
Message-ID: <1346679056-8108-2-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.9.1
In-Reply-To: <1346678886.32462.9.camel@zakaz.uk.xensource.com>
References: <1346678886.32462.9.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH 02/16] Create a raw binary target.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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 suitable for direct loading by a bootloader.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 xen/arch/arm/Makefile |    6 +++++-
 1 files changed, 5 insertions(+), 1 deletions(-)

diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
index bfac017..f296c2f 100644
--- a/xen/arch/arm/Makefile
+++ b/xen/arch/arm/Makefile
@@ -37,12 +37,16 @@ endif
 
 ALL_OBJS := head.o $(ALL_OBJS)
 
-$(TARGET): $(TARGET)-syms
+$(TARGET): $(TARGET)-syms $(TARGET).bin
 	# XXX: VE model loads by VMA so instead of
 	# making a proper ELF we link with LMA == VMA and adjust crudely
 	$(OBJCOPY) --change-addresses +0x80000000 $< $@
 	$(STRIP) $@
 
+# 
+$(TARGET).bin: $(TARGET)-syms
+	objcopy -O binary -R .comment -S $< $@
+
 #$(TARGET): $(TARGET)-syms $(efi-y) boot/mkelf32
 #	./boot/mkelf32 $(TARGET)-syms $(TARGET) 0x100000 \
 #	`$(NM) -nr $(TARGET)-syms | head -n 1 | sed -e 's/^\([^ ]*\).*/0x\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 Mon Sep 03 13:31:32 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Sep 2012 13:31:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T8WkM-0002JH-W7; Mon, 03 Sep 2012 13:31:22 +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 1T8WkK-0002F3-V4
	for xen-devel@lists.xen.org; Mon, 03 Sep 2012 13:31:21 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1346679058!9304385!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNjgzNzM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11755 invoked from network); 3 Sep 2012 13:31:00 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Sep 2012 13:31:00 -0000
X-IronPort-AV: E=Sophos;i="4.80,359,1344211200"; d="scan'208";a="36611260"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Sep 2012 13:30:57 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Mon, 3 Sep 2012 09:30: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 1T8Wjx-00089t-7w;
	Mon, 03 Sep 2012 14:30:57 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Date: Mon, 3 Sep 2012 13:30:42 +0000
Message-ID: <1346679056-8108-2-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.9.1
In-Reply-To: <1346678886.32462.9.camel@zakaz.uk.xensource.com>
References: <1346678886.32462.9.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH 02/16] Create a raw binary target.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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 suitable for direct loading by a bootloader.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 xen/arch/arm/Makefile |    6 +++++-
 1 files changed, 5 insertions(+), 1 deletions(-)

diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
index bfac017..f296c2f 100644
--- a/xen/arch/arm/Makefile
+++ b/xen/arch/arm/Makefile
@@ -37,12 +37,16 @@ endif
 
 ALL_OBJS := head.o $(ALL_OBJS)
 
-$(TARGET): $(TARGET)-syms
+$(TARGET): $(TARGET)-syms $(TARGET).bin
 	# XXX: VE model loads by VMA so instead of
 	# making a proper ELF we link with LMA == VMA and adjust crudely
 	$(OBJCOPY) --change-addresses +0x80000000 $< $@
 	$(STRIP) $@
 
+# 
+$(TARGET).bin: $(TARGET)-syms
+	objcopy -O binary -R .comment -S $< $@
+
 #$(TARGET): $(TARGET)-syms $(efi-y) boot/mkelf32
 #	./boot/mkelf32 $(TARGET)-syms $(TARGET) 0x100000 \
 #	`$(NM) -nr $(TARGET)-syms | head -n 1 | sed -e 's/^\([^ ]*\).*/0x\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 Mon Sep 03 13:31:49 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Sep 2012 13: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 1T8Wkh-0002XC-Dp; Mon, 03 Sep 2012 13:31:43 +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 1T8Wkg-0002Tc-LK
	for xen-devel@lists.xen.org; Mon, 03 Sep 2012 13:31:42 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1346679058!9304385!3
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNjgzNzM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11842 invoked from network); 3 Sep 2012 13:31:02 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Sep 2012 13:31:02 -0000
X-IronPort-AV: E=Sophos;i="4.80,359,1344211200"; d="scan'208";a="36611261"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Sep 2012 13:30:57 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Mon, 3 Sep 2012 09:30: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 1T8Wjx-00089t-98;
	Mon, 03 Sep 2012 14:30:57 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Date: Mon, 3 Sep 2012 13:30:43 +0000
Message-ID: <1346679056-8108-3-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.9.1
In-Reply-To: <1346678886.32462.9.camel@zakaz.uk.xensource.com>
References: <1346678886.32462.9.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH 03/16] arm: make virtual address defines unsigned
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

avoids confusion due to overflow etc.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 xen/include/asm-arm/config.h |   16 ++++++++--------
 1 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/xen/include/asm-arm/config.h b/xen/include/asm-arm/config.h
index 7d02cc7..2a05539 100644
--- a/xen/include/asm-arm/config.h
+++ b/xen/include/asm-arm/config.h
@@ -69,14 +69,14 @@
  *   - in setup_pagetables() when relocating Xen.
  */
 
-#define XEN_VIRT_START         0x00200000
-#define FIXMAP_ADDR(n)        (0x00400000 + (n) * PAGE_SIZE)
-#define BOOT_MISC_VIRT_START   0x00600000
-#define FRAMETABLE_VIRT_START  0x02000000
-#define XENHEAP_VIRT_START     0x40000000
-#define DOMHEAP_VIRT_START     0x80000000
-
-#define HYPERVISOR_VIRT_START mk_unsigned_long(XEN_VIRT_START)
+#define XEN_VIRT_START         mk_unsigned_long(0x00200000)
+#define FIXMAP_ADDR(n)        (mk_unsigned_long(0x00400000) + (n) * PAGE_SIZE)
+#define BOOT_MISC_VIRT_START   mk_unsigned_long(0x00600000)
+#define FRAMETABLE_VIRT_START  mk_unsigned_long(0x02000000)
+#define XENHEAP_VIRT_START     mk_unsigned_long(0x40000000)
+#define DOMHEAP_VIRT_START     mk_unsigned_long(0x80000000)
+
+#define HYPERVISOR_VIRT_START  XEN_VIRT_START
 
 #define DOMHEAP_ENTRIES        1024  /* 1024 2MB mapping slots */
 
-- 
1.7.9.1


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

From xen-devel-bounces@lists.xen.org Mon Sep 03 13:31:49 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Sep 2012 13: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 1T8Wkh-0002XC-Dp; Mon, 03 Sep 2012 13:31:43 +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 1T8Wkg-0002Tc-LK
	for xen-devel@lists.xen.org; Mon, 03 Sep 2012 13:31:42 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1346679058!9304385!3
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNjgzNzM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11842 invoked from network); 3 Sep 2012 13:31:02 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Sep 2012 13:31:02 -0000
X-IronPort-AV: E=Sophos;i="4.80,359,1344211200"; d="scan'208";a="36611261"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Sep 2012 13:30:57 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Mon, 3 Sep 2012 09:30: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 1T8Wjx-00089t-98;
	Mon, 03 Sep 2012 14:30:57 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Date: Mon, 3 Sep 2012 13:30:43 +0000
Message-ID: <1346679056-8108-3-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.9.1
In-Reply-To: <1346678886.32462.9.camel@zakaz.uk.xensource.com>
References: <1346678886.32462.9.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH 03/16] arm: make virtual address defines unsigned
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

avoids confusion due to overflow etc.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 xen/include/asm-arm/config.h |   16 ++++++++--------
 1 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/xen/include/asm-arm/config.h b/xen/include/asm-arm/config.h
index 7d02cc7..2a05539 100644
--- a/xen/include/asm-arm/config.h
+++ b/xen/include/asm-arm/config.h
@@ -69,14 +69,14 @@
  *   - in setup_pagetables() when relocating Xen.
  */
 
-#define XEN_VIRT_START         0x00200000
-#define FIXMAP_ADDR(n)        (0x00400000 + (n) * PAGE_SIZE)
-#define BOOT_MISC_VIRT_START   0x00600000
-#define FRAMETABLE_VIRT_START  0x02000000
-#define XENHEAP_VIRT_START     0x40000000
-#define DOMHEAP_VIRT_START     0x80000000
-
-#define HYPERVISOR_VIRT_START mk_unsigned_long(XEN_VIRT_START)
+#define XEN_VIRT_START         mk_unsigned_long(0x00200000)
+#define FIXMAP_ADDR(n)        (mk_unsigned_long(0x00400000) + (n) * PAGE_SIZE)
+#define BOOT_MISC_VIRT_START   mk_unsigned_long(0x00600000)
+#define FRAMETABLE_VIRT_START  mk_unsigned_long(0x02000000)
+#define XENHEAP_VIRT_START     mk_unsigned_long(0x40000000)
+#define DOMHEAP_VIRT_START     mk_unsigned_long(0x80000000)
+
+#define HYPERVISOR_VIRT_START  XEN_VIRT_START
 
 #define DOMHEAP_ENTRIES        1024  /* 1024 2MB mapping slots */
 
-- 
1.7.9.1


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

From xen-devel-bounces@lists.xen.org Mon Sep 03 13:33:48 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Sep 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 1T8Wma-0003FM-A5; Mon, 03 Sep 2012 13: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 1T8WmY-0003En-NL
	for xen-devel@lists.xen.org; Mon, 03 Sep 2012 13:33:38 +0000
Received: from [85.158.143.35:54957] by server-3.bemta-4.messagelabs.com id
	8E/B6-08232-1B1B4405; Mon, 03 Sep 2012 13:33:37 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1346679060!5380250!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNzYzNjg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30700 invoked from network); 3 Sep 2012 13:31:02 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Sep 2012 13:31:02 -0000
X-IronPort-AV: E=Sophos;i="4.80,359,1344211200"; d="scan'208";a="206937952"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Sep 2012 13:30:58 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Mon, 3 Sep 2012 09:30: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 1T8Wjx-00089t-Iu;
	Mon, 03 Sep 2012 14:30:57 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Date: Mon, 3 Sep 2012 13:30:49 +0000
Message-ID: <1346679056-8108-9-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.9.1
In-Reply-To: <1346678886.32462.9.camel@zakaz.uk.xensource.com>
References: <1346678886.32462.9.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH 09/16] arm: avoid allocating the heaps over
	modules or xen itself.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="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 |  119 ++++++++++++++++++++++++++++++++++++++++++++------
 1 files changed, 105 insertions(+), 14 deletions(-)

diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index 5f8a3d7..369e164 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -40,6 +40,8 @@
 #include <asm/early_printk.h>
 #include "gic.h"
 
+static __initdata paddr_t xen_paddr;
+
 static __attribute_used__ void init_done(void)
 {
     free_init_memory();
@@ -72,7 +74,8 @@ static void __init processor_id(void)
  * with required size and alignment that does not conflict with the
  * modules from first_mod to nr_modules.
  *
- * For non-recursive callers first_mod should normally be 0.
+ * For non-recursive callers first_mod should normally be 0 (all
+ * modules) or -1 (all modules and Xen itself).
  */
 static paddr_t __init consider_modules(paddr_t s, paddr_t e,
                                        uint32_t size, paddr_t align,
@@ -92,8 +95,17 @@ static paddr_t __init consider_modules(paddr_t s, paddr_t e,
         paddr_t mod_s;
         paddr_t mod_e;
 
-        mod_s = mi->module[i].start;
-        mod_e = mod_s + mi->module[i].size;
+        /* module "-1" is Xen itself. */
+        if ( i == -1 )
+        {
+            mod_s = xen_paddr;
+            mod_e = mod_s + ((_end - _start + (XEN_PADDR_ALIGN-1)) & ~(XEN_PADDR_ALIGN-1));
+        }
+        else
+        {
+            mod_s = mi->module[i].start;
+            mod_e = mod_s + mi->module[i].size;
+        }
 
         if ( s < mod_e && mod_s < e )
         {
@@ -108,6 +120,46 @@ static paddr_t __init consider_modules(paddr_t s, paddr_t e,
     return e;
 }
 
+/*
+ * Return the end of the non-module region starting at s. In other
+ * words return s the start of the next modules after s.
+ *
+ * Also returns the end of that module in *n.
+ */
+static paddr_t __init next_module(paddr_t s, paddr_t *n)
+{
+    struct dt_module_info *mi = &early_info.modules;
+    paddr_t lowest = ~(paddr_t)0;
+    int i;
+
+    for ( i = -1; i < mi->nr_mods; i++ )
+    {
+        paddr_t mod_s;
+        paddr_t mod_e;
+
+        /* module "-1" is Xen itself. */
+        if ( i == -1 )
+        {
+            mod_s = xen_paddr;
+            mod_e = mod_s + ((_end - _start + (XEN_PADDR_ALIGN-1)) & ~(XEN_PADDR_ALIGN-1));
+        }
+        else
+        {
+            mod_s = mi->module[i].start;
+            mod_e = mod_s + mi->module[i].size;
+        }
+
+        if ( mod_s < s )
+            continue;
+        if ( mod_s > lowest )
+            continue;
+        lowest = mod_s;
+        *n = mod_e;
+    }
+    return lowest;
+}
+
+
 /**
  * get_xen_paddr - get physical address to relocate Xen to
  *
@@ -156,6 +208,7 @@ static void __init setup_mm(unsigned long dtb_paddr, size_t dtb_size)
     paddr_t ram_start;
     paddr_t ram_end;
     paddr_t ram_size;
+    paddr_t s, e;
     unsigned long ram_pages;
     unsigned long heap_pages, xenheap_pages, domheap_pages;
     unsigned long dtb_pages;
@@ -171,22 +224,37 @@ static void __init setup_mm(unsigned long dtb_paddr, size_t dtb_size)
     ram_pages = ram_size >> PAGE_SHIFT;
 
     /*
-     * Calculate the sizes for the heaps using these constraints:
+     * Locate the xenheap using these constraints:
      *
-     *  - heaps must be 32 MiB aligned
-     *  - must not include Xen itself
-     *  - xen heap must be at most 1 GiB
+     *  - must be 32 MiB aligned
+     *  - must not include Xen itself or the boot modules
+     *  - must be at most 1 GiB
+     *  - must be at least 128M
      *
-     * XXX: needs a platform with at least 1GiB of RAM or the dom
-     * heap will be empty and no domains can be created.
+     * We try to allocate the largest xenheap possible within these
+     * constraints.
      */
-    heap_pages = (ram_size >> PAGE_SHIFT) - (32 << (20 - PAGE_SHIFT));
+    heap_pages = (ram_size >> PAGE_SHIFT);
     xenheap_pages = min(1ul << (30 - PAGE_SHIFT), heap_pages);
+
+    do
+    {
+        e = consider_modules(ram_start, ram_end, xenheap_pages<<PAGE_SHIFT,
+                             32<<20, -1);
+        if ( e )
+            break;
+
+        xenheap_pages >>= 1;
+    } while ( xenheap_pages > 128<<(20-PAGE_SHIFT) );
+
+    if ( ! e )
+        panic("Not not enough space for xenheap\n");
+
     domheap_pages = heap_pages - xenheap_pages;
 
     printk("Xen heap: %lu pages  Dom heap: %lu pages\n", xenheap_pages, domheap_pages);
 
-    setup_xenheap_mappings(ram_start >> PAGE_SHIFT, xenheap_pages);
+    setup_xenheap_mappings((e >> PAGE_SHIFT) - xenheap_pages, xenheap_pages);
 
     /*
      * Need a single mapped page for populating bootmem_region_list
@@ -210,8 +278,30 @@ static void __init setup_mm(unsigned long dtb_paddr, size_t 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),
-                    pfn_to_paddr(xenheap_mfn_start + xenheap_pages + domheap_pages));
+    s = ram_start;
+    while ( s < ram_end )
+    {
+        paddr_t n = ram_end;
+
+        e = next_module(s, &n);
+
+        if ( e == ~(paddr_t)0 )
+        {
+            e = n = ram_end;
+        }
+
+        /* Avoid the xenheap */
+        if ( s < ((xenheap_mfn_start+xenheap_pages) << PAGE_SHIFT)
+             && (xenheap_mfn_start << PAGE_SHIFT) < e )
+        {
+            e = pfn_to_paddr(xenheap_mfn_start);
+            n = pfn_to_paddr(xenheap_mfn_start+xenheap_pages);
+        }
+
+        init_boot_pages(s, e);
+
+        s = n;
+    }
 
     setup_frametable_mappings(ram_start, ram_end);
     max_page = PFN_DOWN(ram_end);
@@ -240,7 +330,8 @@ void __init start_xen(unsigned long boot_phys_offset,
 
     cmdline_parse(device_tree_bootargs(fdt));
 
-    setup_pagetables(boot_phys_offset, get_xen_paddr());
+    xen_paddr = get_xen_paddr();
+    setup_pagetables(boot_phys_offset, xen_paddr);
 
 #ifdef EARLY_UART_ADDRESS
     /* Map the UART */
-- 
1.7.9.1


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

From xen-devel-bounces@lists.xen.org Mon Sep 03 13:33:48 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Sep 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 1T8Wma-0003FM-A5; Mon, 03 Sep 2012 13: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 1T8WmY-0003En-NL
	for xen-devel@lists.xen.org; Mon, 03 Sep 2012 13:33:38 +0000
Received: from [85.158.143.35:54957] by server-3.bemta-4.messagelabs.com id
	8E/B6-08232-1B1B4405; Mon, 03 Sep 2012 13:33:37 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1346679060!5380250!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNzYzNjg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30700 invoked from network); 3 Sep 2012 13:31:02 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Sep 2012 13:31:02 -0000
X-IronPort-AV: E=Sophos;i="4.80,359,1344211200"; d="scan'208";a="206937952"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Sep 2012 13:30:58 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Mon, 3 Sep 2012 09:30: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 1T8Wjx-00089t-Iu;
	Mon, 03 Sep 2012 14:30:57 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Date: Mon, 3 Sep 2012 13:30:49 +0000
Message-ID: <1346679056-8108-9-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.9.1
In-Reply-To: <1346678886.32462.9.camel@zakaz.uk.xensource.com>
References: <1346678886.32462.9.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH 09/16] arm: avoid allocating the heaps over
	modules or xen itself.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="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 |  119 ++++++++++++++++++++++++++++++++++++++++++++------
 1 files changed, 105 insertions(+), 14 deletions(-)

diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index 5f8a3d7..369e164 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -40,6 +40,8 @@
 #include <asm/early_printk.h>
 #include "gic.h"
 
+static __initdata paddr_t xen_paddr;
+
 static __attribute_used__ void init_done(void)
 {
     free_init_memory();
@@ -72,7 +74,8 @@ static void __init processor_id(void)
  * with required size and alignment that does not conflict with the
  * modules from first_mod to nr_modules.
  *
- * For non-recursive callers first_mod should normally be 0.
+ * For non-recursive callers first_mod should normally be 0 (all
+ * modules) or -1 (all modules and Xen itself).
  */
 static paddr_t __init consider_modules(paddr_t s, paddr_t e,
                                        uint32_t size, paddr_t align,
@@ -92,8 +95,17 @@ static paddr_t __init consider_modules(paddr_t s, paddr_t e,
         paddr_t mod_s;
         paddr_t mod_e;
 
-        mod_s = mi->module[i].start;
-        mod_e = mod_s + mi->module[i].size;
+        /* module "-1" is Xen itself. */
+        if ( i == -1 )
+        {
+            mod_s = xen_paddr;
+            mod_e = mod_s + ((_end - _start + (XEN_PADDR_ALIGN-1)) & ~(XEN_PADDR_ALIGN-1));
+        }
+        else
+        {
+            mod_s = mi->module[i].start;
+            mod_e = mod_s + mi->module[i].size;
+        }
 
         if ( s < mod_e && mod_s < e )
         {
@@ -108,6 +120,46 @@ static paddr_t __init consider_modules(paddr_t s, paddr_t e,
     return e;
 }
 
+/*
+ * Return the end of the non-module region starting at s. In other
+ * words return s the start of the next modules after s.
+ *
+ * Also returns the end of that module in *n.
+ */
+static paddr_t __init next_module(paddr_t s, paddr_t *n)
+{
+    struct dt_module_info *mi = &early_info.modules;
+    paddr_t lowest = ~(paddr_t)0;
+    int i;
+
+    for ( i = -1; i < mi->nr_mods; i++ )
+    {
+        paddr_t mod_s;
+        paddr_t mod_e;
+
+        /* module "-1" is Xen itself. */
+        if ( i == -1 )
+        {
+            mod_s = xen_paddr;
+            mod_e = mod_s + ((_end - _start + (XEN_PADDR_ALIGN-1)) & ~(XEN_PADDR_ALIGN-1));
+        }
+        else
+        {
+            mod_s = mi->module[i].start;
+            mod_e = mod_s + mi->module[i].size;
+        }
+
+        if ( mod_s < s )
+            continue;
+        if ( mod_s > lowest )
+            continue;
+        lowest = mod_s;
+        *n = mod_e;
+    }
+    return lowest;
+}
+
+
 /**
  * get_xen_paddr - get physical address to relocate Xen to
  *
@@ -156,6 +208,7 @@ static void __init setup_mm(unsigned long dtb_paddr, size_t dtb_size)
     paddr_t ram_start;
     paddr_t ram_end;
     paddr_t ram_size;
+    paddr_t s, e;
     unsigned long ram_pages;
     unsigned long heap_pages, xenheap_pages, domheap_pages;
     unsigned long dtb_pages;
@@ -171,22 +224,37 @@ static void __init setup_mm(unsigned long dtb_paddr, size_t dtb_size)
     ram_pages = ram_size >> PAGE_SHIFT;
 
     /*
-     * Calculate the sizes for the heaps using these constraints:
+     * Locate the xenheap using these constraints:
      *
-     *  - heaps must be 32 MiB aligned
-     *  - must not include Xen itself
-     *  - xen heap must be at most 1 GiB
+     *  - must be 32 MiB aligned
+     *  - must not include Xen itself or the boot modules
+     *  - must be at most 1 GiB
+     *  - must be at least 128M
      *
-     * XXX: needs a platform with at least 1GiB of RAM or the dom
-     * heap will be empty and no domains can be created.
+     * We try to allocate the largest xenheap possible within these
+     * constraints.
      */
-    heap_pages = (ram_size >> PAGE_SHIFT) - (32 << (20 - PAGE_SHIFT));
+    heap_pages = (ram_size >> PAGE_SHIFT);
     xenheap_pages = min(1ul << (30 - PAGE_SHIFT), heap_pages);
+
+    do
+    {
+        e = consider_modules(ram_start, ram_end, xenheap_pages<<PAGE_SHIFT,
+                             32<<20, -1);
+        if ( e )
+            break;
+
+        xenheap_pages >>= 1;
+    } while ( xenheap_pages > 128<<(20-PAGE_SHIFT) );
+
+    if ( ! e )
+        panic("Not not enough space for xenheap\n");
+
     domheap_pages = heap_pages - xenheap_pages;
 
     printk("Xen heap: %lu pages  Dom heap: %lu pages\n", xenheap_pages, domheap_pages);
 
-    setup_xenheap_mappings(ram_start >> PAGE_SHIFT, xenheap_pages);
+    setup_xenheap_mappings((e >> PAGE_SHIFT) - xenheap_pages, xenheap_pages);
 
     /*
      * Need a single mapped page for populating bootmem_region_list
@@ -210,8 +278,30 @@ static void __init setup_mm(unsigned long dtb_paddr, size_t 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),
-                    pfn_to_paddr(xenheap_mfn_start + xenheap_pages + domheap_pages));
+    s = ram_start;
+    while ( s < ram_end )
+    {
+        paddr_t n = ram_end;
+
+        e = next_module(s, &n);
+
+        if ( e == ~(paddr_t)0 )
+        {
+            e = n = ram_end;
+        }
+
+        /* Avoid the xenheap */
+        if ( s < ((xenheap_mfn_start+xenheap_pages) << PAGE_SHIFT)
+             && (xenheap_mfn_start << PAGE_SHIFT) < e )
+        {
+            e = pfn_to_paddr(xenheap_mfn_start);
+            n = pfn_to_paddr(xenheap_mfn_start+xenheap_pages);
+        }
+
+        init_boot_pages(s, e);
+
+        s = n;
+    }
 
     setup_frametable_mappings(ram_start, ram_end);
     max_page = PFN_DOWN(ram_end);
@@ -240,7 +330,8 @@ void __init start_xen(unsigned long boot_phys_offset,
 
     cmdline_parse(device_tree_bootargs(fdt));
 
-    setup_pagetables(boot_phys_offset, get_xen_paddr());
+    xen_paddr = get_xen_paddr();
+    setup_pagetables(boot_phys_offset, xen_paddr);
 
 #ifdef EARLY_UART_ADDRESS
     /* Map the UART */
-- 
1.7.9.1


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

From xen-devel-bounces@lists.xen.org Mon Sep 03 13:40:54 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Sep 2012 13:40:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T8WtT-0003sk-6y; Mon, 03 Sep 2012 13:40: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 1T8WtR-0003sa-3z
	for xen-devel@lists.xen.org; Mon, 03 Sep 2012 13:40:45 +0000
Received: from [85.158.143.35:31095] by server-2.bemta-4.messagelabs.com id
	6A/11-21239-C53B4405; Mon, 03 Sep 2012 13:40:44 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1346679641!16487826!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNzYzNjg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5030 invoked from network); 3 Sep 2012 13:40:43 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-14.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Sep 2012 13:40:43 -0000
X-IronPort-AV: E=Sophos;i="4.80,359,1344211200"; d="scan'208";a="206938476"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Sep 2012 13:40:41 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Mon, 3 Sep 2012 09:40:40 -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 1T8Wjy-00089t-1G;
	Mon, 03 Sep 2012 14:30:58 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Date: Mon, 3 Sep 2012 13:30:56 +0000
Message-ID: <1346679056-8108-16-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.9.1
In-Reply-To: <1346678886.32462.9.camel@zakaz.uk.xensource.com>
References: <1346678886.32462.9.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH 16/16] arm: use /chosen/module1-args for domain
	0 command line
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ideally this would use module1-args iff the kernel came from
module1-{start,end} and the existing xen,dom0-bootargs if the kernel
came from flash, but this approach is simpler and has the sme effect
in practice.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 xen/arch/arm/domain_build.c |   23 ++++++++++++++++++++---
 1 files changed, 20 insertions(+), 3 deletions(-)

diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index e96ed10..2b65637 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -88,6 +88,8 @@ static int write_properties(struct domain *d, struct kernel_info *kinfo,
 {
     int prop;
 
+    int had_mod1_args = 0;
+
     for ( prop = fdt_first_property_offset(fdt, node);
           prop >= 0;
           prop = fdt_next_property_offset(fdt, prop) )
@@ -104,15 +106,30 @@ static int write_properties(struct domain *d, struct kernel_info *kinfo,
         prop_len  = fdt32_to_cpu(p->len);
 
         /*
-         * In chosen node: replace bootargs with value from
-         * xen,dom0-bootargs.
+         * In chosen node:
+         *
+         * * replace bootargs with value from module1-args, falling
+         *   back to xen,dom0-bootargs if not present.
+         * * remove all other module*.
          */
         if ( device_tree_node_matches(fdt, node, "chosen") )
         {
             if ( strcmp(prop_name, "bootargs") == 0 )
                 continue;
-            if ( strcmp(prop_name, "xen,dom0-bootargs") == 0 )
+            if ( strcmp(prop_name, "module1-args") == 0 )
+            {
                 prop_name = "bootargs";
+                had_mod1_args = 1;
+            }
+            if ( strncmp(prop_name, "module", strlen("module")) == 0 )
+                 continue;
+            if ( strcmp(prop_name, "xen,dom0-bootargs") == 0 )
+            {
+                if ( had_mod1_args )
+                    continue;
+                else
+                    prop_name = "bootargs";
+            }
         }
         /*
          * In a memory node: adjust reg property.
-- 
1.7.9.1


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

From xen-devel-bounces@lists.xen.org Mon Sep 03 13:40:54 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Sep 2012 13:40:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T8WtT-0003sk-6y; Mon, 03 Sep 2012 13:40: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 1T8WtR-0003sa-3z
	for xen-devel@lists.xen.org; Mon, 03 Sep 2012 13:40:45 +0000
Received: from [85.158.143.35:31095] by server-2.bemta-4.messagelabs.com id
	6A/11-21239-C53B4405; Mon, 03 Sep 2012 13:40:44 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1346679641!16487826!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNzYzNjg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5030 invoked from network); 3 Sep 2012 13:40:43 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-14.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Sep 2012 13:40:43 -0000
X-IronPort-AV: E=Sophos;i="4.80,359,1344211200"; d="scan'208";a="206938476"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Sep 2012 13:40:41 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Mon, 3 Sep 2012 09:40:40 -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 1T8Wjy-00089t-1G;
	Mon, 03 Sep 2012 14:30:58 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Date: Mon, 3 Sep 2012 13:30:56 +0000
Message-ID: <1346679056-8108-16-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.9.1
In-Reply-To: <1346678886.32462.9.camel@zakaz.uk.xensource.com>
References: <1346678886.32462.9.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH 16/16] arm: use /chosen/module1-args for domain
	0 command line
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ideally this would use module1-args iff the kernel came from
module1-{start,end} and the existing xen,dom0-bootargs if the kernel
came from flash, but this approach is simpler and has the sme effect
in practice.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 xen/arch/arm/domain_build.c |   23 ++++++++++++++++++++---
 1 files changed, 20 insertions(+), 3 deletions(-)

diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index e96ed10..2b65637 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -88,6 +88,8 @@ static int write_properties(struct domain *d, struct kernel_info *kinfo,
 {
     int prop;
 
+    int had_mod1_args = 0;
+
     for ( prop = fdt_first_property_offset(fdt, node);
           prop >= 0;
           prop = fdt_next_property_offset(fdt, prop) )
@@ -104,15 +106,30 @@ static int write_properties(struct domain *d, struct kernel_info *kinfo,
         prop_len  = fdt32_to_cpu(p->len);
 
         /*
-         * In chosen node: replace bootargs with value from
-         * xen,dom0-bootargs.
+         * In chosen node:
+         *
+         * * replace bootargs with value from module1-args, falling
+         *   back to xen,dom0-bootargs if not present.
+         * * remove all other module*.
          */
         if ( device_tree_node_matches(fdt, node, "chosen") )
         {
             if ( strcmp(prop_name, "bootargs") == 0 )
                 continue;
-            if ( strcmp(prop_name, "xen,dom0-bootargs") == 0 )
+            if ( strcmp(prop_name, "module1-args") == 0 )
+            {
                 prop_name = "bootargs";
+                had_mod1_args = 1;
+            }
+            if ( strncmp(prop_name, "module", strlen("module")) == 0 )
+                 continue;
+            if ( strcmp(prop_name, "xen,dom0-bootargs") == 0 )
+            {
+                if ( had_mod1_args )
+                    continue;
+                else
+                    prop_name = "bootargs";
+            }
         }
         /*
          * In a memory node: adjust reg property.
-- 
1.7.9.1


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

From xen-devel-bounces@lists.xen.org Mon Sep 03 13:40:56 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Sep 2012 13: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 1T8WtT-0003sr-Jf; Mon, 03 Sep 2012 13:40: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 1T8WtS-0003sa-4j
	for xen-devel@lists.xen.org; Mon, 03 Sep 2012 13:40:46 +0000
Received: from [85.158.143.35:31165] by server-2.bemta-4.messagelabs.com id
	CA/21-21239-D53B4405; Mon, 03 Sep 2012 13:40:45 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1346679643!5381629!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNzYzNjg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30660 invoked from network); 3 Sep 2012 13:40:45 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Sep 2012 13:40:45 -0000
X-IronPort-AV: E=Sophos;i="4.80,359,1344211200"; d="scan'208";a="206938480"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Sep 2012 13:40:44 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Mon, 3 Sep 2012 09:40:44 -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 1T8Wjx-00089t-P2;
	Mon, 03 Sep 2012 14:30:57 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Date: Mon, 3 Sep 2012 13:30:52 +0000
Message-ID: <1346679056-8108-12-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.9.1
In-Reply-To: <1346678886.32462.9.camel@zakaz.uk.xensource.com>
References: <1346678886.32462.9.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH 12/16] arm: const-correctness in virt_to_maddr
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="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/mm.h |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/xen/include/asm-arm/mm.h b/xen/include/asm-arm/mm.h
index b0e5a67..7440fe5 100644
--- a/xen/include/asm-arm/mm.h
+++ b/xen/include/asm-arm/mm.h
@@ -179,9 +179,9 @@ extern void clear_fixmap(unsigned map);
 #define paddr_to_pdx(pa)    pfn_to_pdx(paddr_to_pfn(pa))
 
 
-static inline paddr_t virt_to_maddr(void *va)
+static inline paddr_t virt_to_maddr(const void *va)
 {
-    uint64_t par = va_to_par((uint32_t)va);
+    uint64_t par = va_to_par((const uint32_t)va);
     return (par & PADDR_MASK & PAGE_MASK) | ((unsigned long) va & ~PAGE_MASK);
 }
 
-- 
1.7.9.1


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

From xen-devel-bounces@lists.xen.org Mon Sep 03 13:40:56 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Sep 2012 13: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 1T8WtT-0003sr-Jf; Mon, 03 Sep 2012 13:40: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 1T8WtS-0003sa-4j
	for xen-devel@lists.xen.org; Mon, 03 Sep 2012 13:40:46 +0000
Received: from [85.158.143.35:31165] by server-2.bemta-4.messagelabs.com id
	CA/21-21239-D53B4405; Mon, 03 Sep 2012 13:40:45 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1346679643!5381629!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNzYzNjg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30660 invoked from network); 3 Sep 2012 13:40:45 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Sep 2012 13:40:45 -0000
X-IronPort-AV: E=Sophos;i="4.80,359,1344211200"; d="scan'208";a="206938480"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Sep 2012 13:40:44 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Mon, 3 Sep 2012 09:40:44 -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 1T8Wjx-00089t-P2;
	Mon, 03 Sep 2012 14:30:57 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Date: Mon, 3 Sep 2012 13:30:52 +0000
Message-ID: <1346679056-8108-12-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.9.1
In-Reply-To: <1346678886.32462.9.camel@zakaz.uk.xensource.com>
References: <1346678886.32462.9.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH 12/16] arm: const-correctness in virt_to_maddr
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="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/mm.h |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/xen/include/asm-arm/mm.h b/xen/include/asm-arm/mm.h
index b0e5a67..7440fe5 100644
--- a/xen/include/asm-arm/mm.h
+++ b/xen/include/asm-arm/mm.h
@@ -179,9 +179,9 @@ extern void clear_fixmap(unsigned map);
 #define paddr_to_pdx(pa)    pfn_to_pdx(paddr_to_pfn(pa))
 
 
-static inline paddr_t virt_to_maddr(void *va)
+static inline paddr_t virt_to_maddr(const void *va)
 {
-    uint64_t par = va_to_par((uint32_t)va);
+    uint64_t par = va_to_par((const uint32_t)va);
     return (par & PADDR_MASK & PAGE_MASK) | ((unsigned long) va & ~PAGE_MASK);
 }
 
-- 
1.7.9.1


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

From xen-devel-bounces@lists.xen.org Mon Sep 03 13:41:00 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Sep 2012 13:41:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T8Wtc-0003uH-0f; Mon, 03 Sep 2012 13:40: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 1T8Wta-0003tf-3u
	for xen-devel@lists.xen.org; Mon, 03 Sep 2012 13:40:54 +0000
Received: from [85.158.143.35:31494] by server-3.bemta-4.messagelabs.com id
	B4/84-08232-563B4405; Mon, 03 Sep 2012 13:40:53 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1346679641!16487826!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNzYzNjg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5107 invoked from network); 3 Sep 2012 13:40:44 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-14.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Sep 2012 13:40:44 -0000
X-IronPort-AV: E=Sophos;i="4.80,359,1344211200"; d="scan'208";a="206938477"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Sep 2012 13:40:43 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Mon, 3 Sep 2012 09:40:42 -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 1T8Wjx-00089t-Tr;
	Mon, 03 Sep 2012 14:30:57 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Date: Mon, 3 Sep 2012 13:30:54 +0000
Message-ID: <1346679056-8108-14-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.9.1
In-Reply-To: <1346678886.32462.9.camel@zakaz.uk.xensource.com>
References: <1346678886.32462.9.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH 14/16] arm: load dom0 kernel from first boot
	module
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 xen/arch/arm/kernel.c |   63 +++++++++++++++++++++++++++++++++++++-----------
 xen/arch/arm/kernel.h |   10 +++++++
 2 files changed, 58 insertions(+), 15 deletions(-)

diff --git a/xen/arch/arm/kernel.c b/xen/arch/arm/kernel.c
index 2d56130..d82c3e1 100644
--- a/xen/arch/arm/kernel.c
+++ b/xen/arch/arm/kernel.c
@@ -65,13 +65,13 @@ void copy_from_paddr(void *dst, paddr_t paddr, unsigned long len, int attrindx)
 static void kernel_zimage_load(struct kernel_info *info)
 {
     paddr_t load_addr = info->zimage.load_addr;
+    paddr_t paddr = info->zimage.kernel_addr;
     paddr_t len = info->zimage.len;
-    paddr_t flash = KERNEL_FLASH_ADDRESS;
     void *src = (void *)FIXMAP_ADDR(FIXMAP_MISC);
     unsigned long offs;
 
-    printk("Loading %"PRIpaddr" byte zImage from flash %"PRIpaddr" to %"PRIpaddr"-%"PRIpaddr": [",
-           len, flash, load_addr, load_addr + len);
+    printk("Loading zImage from %"PRIpaddr" to %"PRIpaddr"-%"PRIpaddr": [",
+           paddr, load_addr, load_addr + len);
     for ( offs = 0; offs < len; offs += PAGE_SIZE )
     {
         paddr_t ma = gvirt_to_maddr(load_addr + offs);
@@ -80,7 +80,7 @@ static void kernel_zimage_load(struct kernel_info *info)
         if ( ( offs % (1<<20) ) == 0 )
             printk(".");
 
-        set_fixmap(FIXMAP_MISC, (flash+offs) >> PAGE_SHIFT, DEV_SHARED);
+        set_fixmap(FIXMAP_MISC, (paddr+offs) >> PAGE_SHIFT, DEV_SHARED);
         memcpy(dst, src, PAGE_SIZE);
         clear_fixmap(FIXMAP_MISC);
 
@@ -92,13 +92,16 @@ static void kernel_zimage_load(struct kernel_info *info)
 /**
  * Check the image is a zImage and return the load address and length
  */
-static int kernel_try_zimage_prepare(struct kernel_info *info)
+static int kernel_try_zimage_prepare(struct kernel_info *info,
+                                     paddr_t addr, paddr_t size)
 {
     uint32_t *zimage = (void *)FIXMAP_ADDR(FIXMAP_MISC);
     uint32_t start, end;
     struct minimal_dtb_header dtb_hdr;
 
-    set_fixmap(FIXMAP_MISC, KERNEL_FLASH_ADDRESS >> PAGE_SHIFT, DEV_SHARED);
+    set_fixmap(FIXMAP_MISC, addr >> PAGE_SHIFT, DEV_SHARED);
+
+    zimage += addr & ~PAGE_MASK;
 
     if (zimage[ZIMAGE_MAGIC_OFFSET/4] != ZIMAGE_MAGIC)
         return -EINVAL;
@@ -106,16 +109,24 @@ static int kernel_try_zimage_prepare(struct kernel_info *info)
     start = zimage[ZIMAGE_START_OFFSET/4];
     end = zimage[ZIMAGE_END_OFFSET/4];
 
+    if ( end > addr + size )
+        return -EINVAL;
+
     clear_fixmap(FIXMAP_MISC);
 
     /*
      * Check for an appended DTB.
      */
-    copy_from_paddr(&dtb_hdr, KERNEL_FLASH_ADDRESS + end - start, sizeof(dtb_hdr), DEV_SHARED);
+    copy_from_paddr(&dtb_hdr, addr + end - start, sizeof(dtb_hdr), DEV_SHARED);
     if (be32_to_cpu(dtb_hdr.magic) == DTB_MAGIC) {
         end += be32_to_cpu(dtb_hdr.total_size);
+
+        if ( end > addr + size )
+            return -EINVAL;
     }
 
+    info->zimage.kernel_addr = addr;
+
     /*
      * If start is zero, the zImage is position independent -- load it
      * at 32k from start of RAM.
@@ -142,25 +153,26 @@ static void kernel_elf_load(struct kernel_info *info)
     free_xenheap_pages(info->kernel_img, info->kernel_order);
 }
 
-static int kernel_try_elf_prepare(struct kernel_info *info)
+static int kernel_try_elf_prepare(struct kernel_info *info,
+                                  paddr_t addr, paddr_t size)
 {
     int rc;
 
-    info->kernel_order = get_order_from_bytes(KERNEL_FLASH_SIZE);
+    info->kernel_order = get_order_from_bytes(size);
     info->kernel_img = alloc_xenheap_pages(info->kernel_order, 0);
     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, DEV_SHARED);
+    copy_from_paddr(info->kernel_img, addr, size, DEV_SHARED);
 
-    if ( (rc = elf_init(&info->elf.elf, info->kernel_img, KERNEL_FLASH_SIZE )) != 0 )
-        return rc;
+    if ( (rc = elf_init(&info->elf.elf, info->kernel_img, size )) != 0 )
+        goto err;
 #ifdef VERBOSE
     elf_set_verbose(&info->elf.elf);
 #endif
     elf_parse_binary(&info->elf.elf);
     if ( (rc = elf_xen_parse(&info->elf.elf, &info->elf.parms)) != 0 )
-        return rc;
+        goto err;
 
     /*
      * TODO: can the ELF header be used to find the physical address
@@ -170,15 +182,36 @@ static int kernel_try_elf_prepare(struct kernel_info *info)
     info->load = kernel_elf_load;
 
     return 0;
+err:
+    free_xenheap_pages(info->kernel_img, info->kernel_order);
+    return rc;
 }
 
 int kernel_prepare(struct kernel_info *info)
 {
     int rc;
 
-    rc = kernel_try_zimage_prepare(info);
+    paddr_t start, size;
+
+    if ( early_info.modules.nr_mods > 1 )
+        panic("Cannot handle dom0 initrd yet\n");
+
+    if ( early_info.modules.nr_mods < 1 )
+    {
+        printk("No boot modules found, trying flash\n");
+        start = KERNEL_FLASH_ADDRESS;
+        size = KERNEL_FLASH_SIZE;
+    }
+    else
+    {
+        printk("Loading kernel from boot module 1\n");
+        start = early_info.modules.module[0].start;
+        size = early_info.modules.module[0].size;
+    }
+
+    rc = kernel_try_zimage_prepare(info, start, size);
     if (rc < 0)
-        rc = kernel_try_elf_prepare(info);
+        rc = kernel_try_elf_prepare(info, start, size);
 
     return rc;
 }
diff --git a/xen/arch/arm/kernel.h b/xen/arch/arm/kernel.h
index 4533568..2353e13 100644
--- a/xen/arch/arm/kernel.h
+++ b/xen/arch/arm/kernel.h
@@ -22,6 +22,7 @@ struct kernel_info {
 
     union {
         struct {
+            paddr_t kernel_addr;
             paddr_t load_addr;
             paddr_t len;
         } zimage;
@@ -39,3 +40,12 @@ int kernel_prepare(struct kernel_info *info);
 void kernel_load(struct kernel_info *info);
 
 #endif /* #ifdef __ARCH_ARM_KERNEL_H__ */
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
-- 
1.7.9.1


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

From xen-devel-bounces@lists.xen.org Mon Sep 03 13:41:00 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Sep 2012 13:41:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T8Wtc-0003uH-0f; Mon, 03 Sep 2012 13:40: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 1T8Wta-0003tf-3u
	for xen-devel@lists.xen.org; Mon, 03 Sep 2012 13:40:54 +0000
Received: from [85.158.143.35:31494] by server-3.bemta-4.messagelabs.com id
	B4/84-08232-563B4405; Mon, 03 Sep 2012 13:40:53 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1346679641!16487826!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNzYzNjg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5107 invoked from network); 3 Sep 2012 13:40:44 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-14.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Sep 2012 13:40:44 -0000
X-IronPort-AV: E=Sophos;i="4.80,359,1344211200"; d="scan'208";a="206938477"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Sep 2012 13:40:43 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Mon, 3 Sep 2012 09:40:42 -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 1T8Wjx-00089t-Tr;
	Mon, 03 Sep 2012 14:30:57 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Date: Mon, 3 Sep 2012 13:30:54 +0000
Message-ID: <1346679056-8108-14-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.9.1
In-Reply-To: <1346678886.32462.9.camel@zakaz.uk.xensource.com>
References: <1346678886.32462.9.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH 14/16] arm: load dom0 kernel from first boot
	module
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 xen/arch/arm/kernel.c |   63 +++++++++++++++++++++++++++++++++++++-----------
 xen/arch/arm/kernel.h |   10 +++++++
 2 files changed, 58 insertions(+), 15 deletions(-)

diff --git a/xen/arch/arm/kernel.c b/xen/arch/arm/kernel.c
index 2d56130..d82c3e1 100644
--- a/xen/arch/arm/kernel.c
+++ b/xen/arch/arm/kernel.c
@@ -65,13 +65,13 @@ void copy_from_paddr(void *dst, paddr_t paddr, unsigned long len, int attrindx)
 static void kernel_zimage_load(struct kernel_info *info)
 {
     paddr_t load_addr = info->zimage.load_addr;
+    paddr_t paddr = info->zimage.kernel_addr;
     paddr_t len = info->zimage.len;
-    paddr_t flash = KERNEL_FLASH_ADDRESS;
     void *src = (void *)FIXMAP_ADDR(FIXMAP_MISC);
     unsigned long offs;
 
-    printk("Loading %"PRIpaddr" byte zImage from flash %"PRIpaddr" to %"PRIpaddr"-%"PRIpaddr": [",
-           len, flash, load_addr, load_addr + len);
+    printk("Loading zImage from %"PRIpaddr" to %"PRIpaddr"-%"PRIpaddr": [",
+           paddr, load_addr, load_addr + len);
     for ( offs = 0; offs < len; offs += PAGE_SIZE )
     {
         paddr_t ma = gvirt_to_maddr(load_addr + offs);
@@ -80,7 +80,7 @@ static void kernel_zimage_load(struct kernel_info *info)
         if ( ( offs % (1<<20) ) == 0 )
             printk(".");
 
-        set_fixmap(FIXMAP_MISC, (flash+offs) >> PAGE_SHIFT, DEV_SHARED);
+        set_fixmap(FIXMAP_MISC, (paddr+offs) >> PAGE_SHIFT, DEV_SHARED);
         memcpy(dst, src, PAGE_SIZE);
         clear_fixmap(FIXMAP_MISC);
 
@@ -92,13 +92,16 @@ static void kernel_zimage_load(struct kernel_info *info)
 /**
  * Check the image is a zImage and return the load address and length
  */
-static int kernel_try_zimage_prepare(struct kernel_info *info)
+static int kernel_try_zimage_prepare(struct kernel_info *info,
+                                     paddr_t addr, paddr_t size)
 {
     uint32_t *zimage = (void *)FIXMAP_ADDR(FIXMAP_MISC);
     uint32_t start, end;
     struct minimal_dtb_header dtb_hdr;
 
-    set_fixmap(FIXMAP_MISC, KERNEL_FLASH_ADDRESS >> PAGE_SHIFT, DEV_SHARED);
+    set_fixmap(FIXMAP_MISC, addr >> PAGE_SHIFT, DEV_SHARED);
+
+    zimage += addr & ~PAGE_MASK;
 
     if (zimage[ZIMAGE_MAGIC_OFFSET/4] != ZIMAGE_MAGIC)
         return -EINVAL;
@@ -106,16 +109,24 @@ static int kernel_try_zimage_prepare(struct kernel_info *info)
     start = zimage[ZIMAGE_START_OFFSET/4];
     end = zimage[ZIMAGE_END_OFFSET/4];
 
+    if ( end > addr + size )
+        return -EINVAL;
+
     clear_fixmap(FIXMAP_MISC);
 
     /*
      * Check for an appended DTB.
      */
-    copy_from_paddr(&dtb_hdr, KERNEL_FLASH_ADDRESS + end - start, sizeof(dtb_hdr), DEV_SHARED);
+    copy_from_paddr(&dtb_hdr, addr + end - start, sizeof(dtb_hdr), DEV_SHARED);
     if (be32_to_cpu(dtb_hdr.magic) == DTB_MAGIC) {
         end += be32_to_cpu(dtb_hdr.total_size);
+
+        if ( end > addr + size )
+            return -EINVAL;
     }
 
+    info->zimage.kernel_addr = addr;
+
     /*
      * If start is zero, the zImage is position independent -- load it
      * at 32k from start of RAM.
@@ -142,25 +153,26 @@ static void kernel_elf_load(struct kernel_info *info)
     free_xenheap_pages(info->kernel_img, info->kernel_order);
 }
 
-static int kernel_try_elf_prepare(struct kernel_info *info)
+static int kernel_try_elf_prepare(struct kernel_info *info,
+                                  paddr_t addr, paddr_t size)
 {
     int rc;
 
-    info->kernel_order = get_order_from_bytes(KERNEL_FLASH_SIZE);
+    info->kernel_order = get_order_from_bytes(size);
     info->kernel_img = alloc_xenheap_pages(info->kernel_order, 0);
     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, DEV_SHARED);
+    copy_from_paddr(info->kernel_img, addr, size, DEV_SHARED);
 
-    if ( (rc = elf_init(&info->elf.elf, info->kernel_img, KERNEL_FLASH_SIZE )) != 0 )
-        return rc;
+    if ( (rc = elf_init(&info->elf.elf, info->kernel_img, size )) != 0 )
+        goto err;
 #ifdef VERBOSE
     elf_set_verbose(&info->elf.elf);
 #endif
     elf_parse_binary(&info->elf.elf);
     if ( (rc = elf_xen_parse(&info->elf.elf, &info->elf.parms)) != 0 )
-        return rc;
+        goto err;
 
     /*
      * TODO: can the ELF header be used to find the physical address
@@ -170,15 +182,36 @@ static int kernel_try_elf_prepare(struct kernel_info *info)
     info->load = kernel_elf_load;
 
     return 0;
+err:
+    free_xenheap_pages(info->kernel_img, info->kernel_order);
+    return rc;
 }
 
 int kernel_prepare(struct kernel_info *info)
 {
     int rc;
 
-    rc = kernel_try_zimage_prepare(info);
+    paddr_t start, size;
+
+    if ( early_info.modules.nr_mods > 1 )
+        panic("Cannot handle dom0 initrd yet\n");
+
+    if ( early_info.modules.nr_mods < 1 )
+    {
+        printk("No boot modules found, trying flash\n");
+        start = KERNEL_FLASH_ADDRESS;
+        size = KERNEL_FLASH_SIZE;
+    }
+    else
+    {
+        printk("Loading kernel from boot module 1\n");
+        start = early_info.modules.module[0].start;
+        size = early_info.modules.module[0].size;
+    }
+
+    rc = kernel_try_zimage_prepare(info, start, size);
     if (rc < 0)
-        rc = kernel_try_elf_prepare(info);
+        rc = kernel_try_elf_prepare(info, start, size);
 
     return rc;
 }
diff --git a/xen/arch/arm/kernel.h b/xen/arch/arm/kernel.h
index 4533568..2353e13 100644
--- a/xen/arch/arm/kernel.h
+++ b/xen/arch/arm/kernel.h
@@ -22,6 +22,7 @@ struct kernel_info {
 
     union {
         struct {
+            paddr_t kernel_addr;
             paddr_t load_addr;
             paddr_t len;
         } zimage;
@@ -39,3 +40,12 @@ int kernel_prepare(struct kernel_info *info);
 void kernel_load(struct kernel_info *info);
 
 #endif /* #ifdef __ARCH_ARM_KERNEL_H__ */
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
-- 
1.7.9.1


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

From xen-devel-bounces@lists.xen.org Mon Sep 03 13:41:10 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Sep 2012 13:41:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T8Wtj-0003wn-De; Mon, 03 Sep 2012 13:41: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 1T8Wth-0003vz-PQ
	for xen-devel@lists.xen.org; Mon, 03 Sep 2012 13:41:01 +0000
Received: from [85.158.138.51:22627] by server-11.bemta-3.messagelabs.com id
	4D/88-30250-863B4405; Mon, 03 Sep 2012 13:40:56 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1346679654!21983181!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNjgzNzM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10667 invoked from network); 3 Sep 2012 13:40:56 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-14.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Sep 2012 13:40:56 -0000
X-IronPort-AV: E=Sophos;i="4.80,359,1344211200"; d="scan'208";a="36611879"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Sep 2012 13:40:45 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Mon, 3 Sep 2012 09:40:44 -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 1T8Wjx-00089t-RM;
	Mon, 03 Sep 2012 14:30:57 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Date: Mon, 3 Sep 2012 13:30:53 +0000
Message-ID: <1346679056-8108-13-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.9.1
In-Reply-To: <1346678886.32462.9.camel@zakaz.uk.xensource.com>
References: <1346678886.32462.9.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH 13/16] device-tree: get_val cannot cope with
	cells > 2, add a BUG
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 xen/common/device_tree.c |    4 +++-
 1 files changed, 3 insertions(+), 1 deletions(-)

diff --git a/xen/common/device_tree.c b/xen/common/device_tree.c
index 226e3f3..60f3a03 100644
--- a/xen/common/device_tree.c
+++ b/xen/common/device_tree.c
@@ -45,6 +45,8 @@ static void __init get_val(const u32 **cell, u32 cells, u64 *val)
 {
     *val = 0;
 
+    BUG_ON( cells > 2 );
+
     while ( cells-- )
     {
         *val <<= 32;
@@ -139,7 +141,7 @@ int device_tree_for_each_node(const void *fdt,
  */
 const char *device_tree_bootargs(const void *fdt)
 {
-    int node; 
+    int node;
     const struct fdt_property *prop;
 
     node = fdt_path_offset(fdt, "/chosen");
-- 
1.7.9.1


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

From xen-devel-bounces@lists.xen.org Mon Sep 03 13:41:10 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Sep 2012 13:41:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T8Wtj-0003wn-De; Mon, 03 Sep 2012 13:41: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 1T8Wth-0003vz-PQ
	for xen-devel@lists.xen.org; Mon, 03 Sep 2012 13:41:01 +0000
Received: from [85.158.138.51:22627] by server-11.bemta-3.messagelabs.com id
	4D/88-30250-863B4405; Mon, 03 Sep 2012 13:40:56 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1346679654!21983181!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNjgzNzM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10667 invoked from network); 3 Sep 2012 13:40:56 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-14.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Sep 2012 13:40:56 -0000
X-IronPort-AV: E=Sophos;i="4.80,359,1344211200"; d="scan'208";a="36611879"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Sep 2012 13:40:45 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Mon, 3 Sep 2012 09:40:44 -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 1T8Wjx-00089t-RM;
	Mon, 03 Sep 2012 14:30:57 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Date: Mon, 3 Sep 2012 13:30:53 +0000
Message-ID: <1346679056-8108-13-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.9.1
In-Reply-To: <1346678886.32462.9.camel@zakaz.uk.xensource.com>
References: <1346678886.32462.9.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH 13/16] device-tree: get_val cannot cope with
	cells > 2, add a BUG
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 xen/common/device_tree.c |    4 +++-
 1 files changed, 3 insertions(+), 1 deletions(-)

diff --git a/xen/common/device_tree.c b/xen/common/device_tree.c
index 226e3f3..60f3a03 100644
--- a/xen/common/device_tree.c
+++ b/xen/common/device_tree.c
@@ -45,6 +45,8 @@ static void __init get_val(const u32 **cell, u32 cells, u64 *val)
 {
     *val = 0;
 
+    BUG_ON( cells > 2 );
+
     while ( cells-- )
     {
         *val <<= 32;
@@ -139,7 +141,7 @@ int device_tree_for_each_node(const void *fdt,
  */
 const char *device_tree_bootargs(const void *fdt)
 {
-    int node; 
+    int node;
     const struct fdt_property *prop;
 
     node = fdt_path_offset(fdt, "/chosen");
-- 
1.7.9.1


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

From xen-devel-bounces@lists.xen.org Mon Sep 03 13:41:49 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Sep 2012 13:41:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T8WuN-00047U-Rl; Mon, 03 Sep 2012 13:41:43 +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 1T8WuM-00045b-Mj
	for xen-devel@lists.xen.org; Mon, 03 Sep 2012 13:41:42 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1346679647!9326941!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNjgzNzM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18241 invoked from network); 3 Sep 2012 13:40:54 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-8.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Sep 2012 13:40:54 -0000
X-IronPort-AV: E=Sophos;i="4.80,359,1344211200"; d="scan'208";a="36611877"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Sep 2012 13:40:43 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Mon, 3 Sep 2012 09:40:43 -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 1T8Wjx-00089t-Nt;
	Mon, 03 Sep 2012 14:30:57 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Date: Mon, 3 Sep 2012 13:30:51 +0000
Message-ID: <1346679056-8108-11-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.9.1
In-Reply-To: <1346678886.32462.9.camel@zakaz.uk.xensource.com>
References: <1346678886.32462.9.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH 11/16] arm: mark heap and frametable limits as
	read mostly
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 used in virt_to_page and page_to_virt so I imagine there's
some small benefit to this (but I've not measured)

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 xen/arch/arm/mm.c |    9 +++++----
 1 files changed, 5 insertions(+), 4 deletions(-)

diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
index aafc48c..368911b 100644
--- a/xen/arch/arm/mm.c
+++ b/xen/arch/arm/mm.c
@@ -47,11 +47,12 @@ 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;
+unsigned long xenheap_mfn_start __read_mostly;
+unsigned long xenheap_mfn_end __read_mostly;
+unsigned long xenheap_virt_end __read_mostly;
 
-unsigned long frametable_base_mfn;
-unsigned long frametable_virt_end;
+unsigned long frametable_base_mfn __read_mostly;
+unsigned long frametable_virt_end __read_mostly;
 
 unsigned long max_page;
 
-- 
1.7.9.1


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

From xen-devel-bounces@lists.xen.org Mon Sep 03 13:41:49 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Sep 2012 13:41:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T8WuN-00047U-Rl; Mon, 03 Sep 2012 13:41:43 +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 1T8WuM-00045b-Mj
	for xen-devel@lists.xen.org; Mon, 03 Sep 2012 13:41:42 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1346679647!9326941!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNjgzNzM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18241 invoked from network); 3 Sep 2012 13:40:54 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-8.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Sep 2012 13:40:54 -0000
X-IronPort-AV: E=Sophos;i="4.80,359,1344211200"; d="scan'208";a="36611877"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Sep 2012 13:40:43 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Mon, 3 Sep 2012 09:40:43 -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 1T8Wjx-00089t-Nt;
	Mon, 03 Sep 2012 14:30:57 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Date: Mon, 3 Sep 2012 13:30:51 +0000
Message-ID: <1346679056-8108-11-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.9.1
In-Reply-To: <1346678886.32462.9.camel@zakaz.uk.xensource.com>
References: <1346678886.32462.9.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH 11/16] arm: mark heap and frametable limits as
	read mostly
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 used in virt_to_page and page_to_virt so I imagine there's
some small benefit to this (but I've not measured)

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 xen/arch/arm/mm.c |    9 +++++----
 1 files changed, 5 insertions(+), 4 deletions(-)

diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
index aafc48c..368911b 100644
--- a/xen/arch/arm/mm.c
+++ b/xen/arch/arm/mm.c
@@ -47,11 +47,12 @@ 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;
+unsigned long xenheap_mfn_start __read_mostly;
+unsigned long xenheap_mfn_end __read_mostly;
+unsigned long xenheap_virt_end __read_mostly;
 
-unsigned long frametable_base_mfn;
-unsigned long frametable_virt_end;
+unsigned long frametable_base_mfn __read_mostly;
+unsigned long frametable_virt_end __read_mostly;
 
 unsigned long max_page;
 
-- 
1.7.9.1


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

From xen-devel-bounces@lists.xen.org Mon Sep 03 13:41:58 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Sep 2012 13:41: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 1T8WuW-0004Ao-DY; Mon, 03 Sep 2012 13:41:52 +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 1T8WuV-00048Y-BL
	for xen-devel@lists.xen.org; Mon, 03 Sep 2012 13:41:51 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1346679647!9326941!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNjgzNzM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17783 invoked from network); 3 Sep 2012 13:40:50 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-8.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Sep 2012 13:40:50 -0000
X-IronPort-AV: E=Sophos;i="4.80,359,1344211200"; d="scan'208";a="36611875"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Sep 2012 13:40:42 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Mon, 3 Sep 2012 09:40:41 -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 1T8Wjy-00089t-04;
	Mon, 03 Sep 2012 14:30:58 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Date: Mon, 3 Sep 2012 13:30:55 +0000
Message-ID: <1346679056-8108-15-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.9.1
In-Reply-To: <1346678886.32462.9.camel@zakaz.uk.xensource.com>
References: <1346678886.32462.9.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH 15/16] arm: discard boot modules after building
	domain 0.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 xen/arch/arm/domain_build.c |    3 +++
 xen/arch/arm/setup.c        |   16 ++++++++++++++++
 xen/include/asm-arm/setup.h |    2 ++
 3 files changed, 21 insertions(+), 0 deletions(-)

diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index a9e7f43..e96ed10 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -10,6 +10,7 @@
 #include <xen/device_tree.h>
 #include <xen/libfdt/libfdt.h>
 #include <xen/guest_access.h>
+#include <asm/setup.h>
 
 #include "gic.h"
 #include "kernel.h"
@@ -308,6 +309,8 @@ int construct_dom0(struct domain *d)
     dtb_load(&kinfo);
     kernel_load(&kinfo);
 
+    discard_initial_modules();
+
     clear_bit(_VPF_down, &v->pause_flags);
 
     memset(regs, 0, sizeof(*regs));
diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index 85487fe..b23bdc1 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -69,6 +69,22 @@ static void __init processor_id(void)
            READ_CP32(ID_ISAR3), READ_CP32(ID_ISAR4), READ_CP32(ID_ISAR5));
 }
 
+void __init discard_initial_modules(void)
+{
+    struct dt_module_info *mi = &early_info.modules;
+    int i;
+
+    for ( i = 0; i < mi->nr_mods; i++ )
+    {
+        paddr_t s = mi->module[i].start;
+        paddr_t e = s + PAGE_ALIGN(mi->module[i].size);
+
+        init_domheap_pages(s, e);
+    }
+
+    mi->nr_mods = 0;
+}
+
 /*
  * Returns the end address of the highest region in the range s..e
  * with required size and alignment that does not conflict with the
diff --git a/xen/include/asm-arm/setup.h b/xen/include/asm-arm/setup.h
index 8769f66..3267db0 100644
--- a/xen/include/asm-arm/setup.h
+++ b/xen/include/asm-arm/setup.h
@@ -9,6 +9,8 @@ void arch_get_xen_caps(xen_capabilities_info_t *info);
 
 int construct_dom0(struct domain *d);
 
+void discard_initial_modules(void);
+
 #endif
 /*
  * Local variables:
-- 
1.7.9.1


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

From xen-devel-bounces@lists.xen.org Mon Sep 03 13:41:58 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Sep 2012 13:41: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 1T8WuW-0004Ao-DY; Mon, 03 Sep 2012 13:41:52 +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 1T8WuV-00048Y-BL
	for xen-devel@lists.xen.org; Mon, 03 Sep 2012 13:41:51 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1346679647!9326941!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNjgzNzM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17783 invoked from network); 3 Sep 2012 13:40:50 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-8.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Sep 2012 13:40:50 -0000
X-IronPort-AV: E=Sophos;i="4.80,359,1344211200"; d="scan'208";a="36611875"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Sep 2012 13:40:42 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Mon, 3 Sep 2012 09:40:41 -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 1T8Wjy-00089t-04;
	Mon, 03 Sep 2012 14:30:58 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Date: Mon, 3 Sep 2012 13:30:55 +0000
Message-ID: <1346679056-8108-15-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.9.1
In-Reply-To: <1346678886.32462.9.camel@zakaz.uk.xensource.com>
References: <1346678886.32462.9.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH 15/16] arm: discard boot modules after building
	domain 0.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 xen/arch/arm/domain_build.c |    3 +++
 xen/arch/arm/setup.c        |   16 ++++++++++++++++
 xen/include/asm-arm/setup.h |    2 ++
 3 files changed, 21 insertions(+), 0 deletions(-)

diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index a9e7f43..e96ed10 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -10,6 +10,7 @@
 #include <xen/device_tree.h>
 #include <xen/libfdt/libfdt.h>
 #include <xen/guest_access.h>
+#include <asm/setup.h>
 
 #include "gic.h"
 #include "kernel.h"
@@ -308,6 +309,8 @@ int construct_dom0(struct domain *d)
     dtb_load(&kinfo);
     kernel_load(&kinfo);
 
+    discard_initial_modules();
+
     clear_bit(_VPF_down, &v->pause_flags);
 
     memset(regs, 0, sizeof(*regs));
diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index 85487fe..b23bdc1 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -69,6 +69,22 @@ static void __init processor_id(void)
            READ_CP32(ID_ISAR3), READ_CP32(ID_ISAR4), READ_CP32(ID_ISAR5));
 }
 
+void __init discard_initial_modules(void)
+{
+    struct dt_module_info *mi = &early_info.modules;
+    int i;
+
+    for ( i = 0; i < mi->nr_mods; i++ )
+    {
+        paddr_t s = mi->module[i].start;
+        paddr_t e = s + PAGE_ALIGN(mi->module[i].size);
+
+        init_domheap_pages(s, e);
+    }
+
+    mi->nr_mods = 0;
+}
+
 /*
  * Returns the end address of the highest region in the range s..e
  * with required size and alignment that does not conflict with the
diff --git a/xen/include/asm-arm/setup.h b/xen/include/asm-arm/setup.h
index 8769f66..3267db0 100644
--- a/xen/include/asm-arm/setup.h
+++ b/xen/include/asm-arm/setup.h
@@ -9,6 +9,8 @@ void arch_get_xen_caps(xen_capabilities_info_t *info);
 
 int construct_dom0(struct domain *d);
 
+void discard_initial_modules(void);
+
 #endif
 /*
  * Local variables:
-- 
1.7.9.1


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

From xen-devel-bounces@lists.xen.org Mon Sep 03 15:06:29 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Sep 2012 15:06:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T8YDx-00058U-82; Mon, 03 Sep 2012 15:06:01 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <marc.zyngier@arm.com>) id 1T8Y99-00056k-Kt
	for xen-devel@lists.xen.org; Mon, 03 Sep 2012 15:01:04 +0000
Received: from [85.158.138.51:10214] by server-9.bemta-3.messagelabs.com id
	DC/2C-15390-B26C4405; Mon, 03 Sep 2012 15:00:59 +0000
X-Env-Sender: marc.zyngier@arm.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1346684458!28261595!1
X-Originating-IP: [91.220.42.44]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogOTEuMjIwLjQyLjQ0ID0+IDI5NjMxMQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23322 invoked from network); 3 Sep 2012 15:00:58 -0000
Received: from service87.mimecast.com (HELO service87.mimecast.com)
	(91.220.42.44) by server-16.tower-174.messagelabs.com with SMTP;
	3 Sep 2012 15:00:58 -0000
Received: from cam-owa1.Emea.Arm.com (fw-tnat.cambridge.arm.com
	[217.140.96.21]) by service87.mimecast.com;
	Mon, 03 Sep 2012 16:00:57 +0100
Received: from [10.1.70.21] ([10.1.255.212]) by cam-owa1.Emea.Arm.com with
	Microsoft SMTPSVC(6.0.3790.0); Mon, 3 Sep 2012 16:03:02 +0100
Message-ID: <5044C627.9050302@arm.com>
Date: Mon, 03 Sep 2012 16:00:55 +0100
From: Marc Zyngier <marc.zyngier@arm.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:14.0) Gecko/20120714 Thunderbird/14.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <1346679043.32462.11.camel@zakaz.uk.xensource.com>
In-Reply-To: <1346679043.32462.11.camel@zakaz.uk.xensource.com>
X-Enigmail-Version: 1.5a1pre
X-OriginalArrivalTime: 03 Sep 2012 15:03:02.0655 (UTC)
	FILETIME=[36FB08F0:01CD89E5]
X-MC-Unique: 112090316005705701
X-Mailman-Approved-At: Mon, 03 Sep 2012 15:06:00 +0000
Cc: Dave Martin <dave.martin@linaro.org>,
	"boot-architecture@lists.linaro.org" <boot-architecture@lists.linaro.org>,
	"kvmarm@lists.cs.columbia.edu" <kvmarm@lists.cs.columbia.edu>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [kvmarm] boot-wrapper: simple multi module loading
	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 03/09/12 14:30, Ian Campbell wrote:

Hi Ian,

> Apparently kvmarm@ is the place for boot-wrapper discussions so
> apologies for the otherwise Xen related mail ;)
> 
> The following implements support for a very basic protocol for loading
> multiple "modules" and providing them to the kernel. The ARM port of Xen
> uses this to support passing both a dom0 kernel and initrd to the
> hypervisor "kernel".
> 
> The Xen side of this can be found in the series at:
>         http://lists.xen.org/archives/html/xen-devel/2012-09/msg00065.html
> 
> With that you can boot Xen on arm using the semi-hosting feature of the
> model (paths are host paths):
>         $MODEL linux-system-semi.axf -C cluster.cpu0.semihosting-cmd_line=\
>                 	'--kernel xen-arm.bin \
>                 	 --module zImage earlyprintk=xenboot console=ttyAMA1 root=/dev/mmcblk0 ro \
>                 	 --dtb vexpress-v2p-aem-v7a-xen.dtb -- dom0_mem=256M'
> 
> Until we know what bootloaders are going to become common in the ARM
> servers world it hard to know who we should be working with to define a
> proper protocol going forward and which bootloaders to supply patches
> for etc. If anyone has any pointers that would be very useful.

I don't have any useful insight about bootloaders (I tend to hate them
all ;-), but what we (KVM/ARM) need is something that implements the
"boot in HYP mode" thing, as described here:

https://lists.cs.columbia.edu/pipermail/kvmarm/2012-August/002829.html

>From a discussion with Stefano last week, it looks like this protocol
can fit Xen as well, but it would be nice to have a formal Ack before we
push this into RMK's patch system.

Thanks,

	M.
-- 
Jazz is not dead. It just smells funny...


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

From xen-devel-bounces@lists.xen.org Mon Sep 03 15:06:29 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Sep 2012 15:06:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T8YDx-00058U-82; Mon, 03 Sep 2012 15:06:01 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <marc.zyngier@arm.com>) id 1T8Y99-00056k-Kt
	for xen-devel@lists.xen.org; Mon, 03 Sep 2012 15:01:04 +0000
Received: from [85.158.138.51:10214] by server-9.bemta-3.messagelabs.com id
	DC/2C-15390-B26C4405; Mon, 03 Sep 2012 15:00:59 +0000
X-Env-Sender: marc.zyngier@arm.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1346684458!28261595!1
X-Originating-IP: [91.220.42.44]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogOTEuMjIwLjQyLjQ0ID0+IDI5NjMxMQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23322 invoked from network); 3 Sep 2012 15:00:58 -0000
Received: from service87.mimecast.com (HELO service87.mimecast.com)
	(91.220.42.44) by server-16.tower-174.messagelabs.com with SMTP;
	3 Sep 2012 15:00:58 -0000
Received: from cam-owa1.Emea.Arm.com (fw-tnat.cambridge.arm.com
	[217.140.96.21]) by service87.mimecast.com;
	Mon, 03 Sep 2012 16:00:57 +0100
Received: from [10.1.70.21] ([10.1.255.212]) by cam-owa1.Emea.Arm.com with
	Microsoft SMTPSVC(6.0.3790.0); Mon, 3 Sep 2012 16:03:02 +0100
Message-ID: <5044C627.9050302@arm.com>
Date: Mon, 03 Sep 2012 16:00:55 +0100
From: Marc Zyngier <marc.zyngier@arm.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:14.0) Gecko/20120714 Thunderbird/14.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <1346679043.32462.11.camel@zakaz.uk.xensource.com>
In-Reply-To: <1346679043.32462.11.camel@zakaz.uk.xensource.com>
X-Enigmail-Version: 1.5a1pre
X-OriginalArrivalTime: 03 Sep 2012 15:03:02.0655 (UTC)
	FILETIME=[36FB08F0:01CD89E5]
X-MC-Unique: 112090316005705701
X-Mailman-Approved-At: Mon, 03 Sep 2012 15:06:00 +0000
Cc: Dave Martin <dave.martin@linaro.org>,
	"boot-architecture@lists.linaro.org" <boot-architecture@lists.linaro.org>,
	"kvmarm@lists.cs.columbia.edu" <kvmarm@lists.cs.columbia.edu>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [kvmarm] boot-wrapper: simple multi module loading
	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 03/09/12 14:30, Ian Campbell wrote:

Hi Ian,

> Apparently kvmarm@ is the place for boot-wrapper discussions so
> apologies for the otherwise Xen related mail ;)
> 
> The following implements support for a very basic protocol for loading
> multiple "modules" and providing them to the kernel. The ARM port of Xen
> uses this to support passing both a dom0 kernel and initrd to the
> hypervisor "kernel".
> 
> The Xen side of this can be found in the series at:
>         http://lists.xen.org/archives/html/xen-devel/2012-09/msg00065.html
> 
> With that you can boot Xen on arm using the semi-hosting feature of the
> model (paths are host paths):
>         $MODEL linux-system-semi.axf -C cluster.cpu0.semihosting-cmd_line=\
>                 	'--kernel xen-arm.bin \
>                 	 --module zImage earlyprintk=xenboot console=ttyAMA1 root=/dev/mmcblk0 ro \
>                 	 --dtb vexpress-v2p-aem-v7a-xen.dtb -- dom0_mem=256M'
> 
> Until we know what bootloaders are going to become common in the ARM
> servers world it hard to know who we should be working with to define a
> proper protocol going forward and which bootloaders to supply patches
> for etc. If anyone has any pointers that would be very useful.

I don't have any useful insight about bootloaders (I tend to hate them
all ;-), but what we (KVM/ARM) need is something that implements the
"boot in HYP mode" thing, as described here:

https://lists.cs.columbia.edu/pipermail/kvmarm/2012-August/002829.html

>From a discussion with Stefano last week, it looks like this protocol
can fit Xen as well, but it would be nice to have a formal Ack before we
push this into RMK's patch system.

Thanks,

	M.
-- 
Jazz is not dead. It just smells funny...


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

From xen-devel-bounces@lists.xen.org Mon Sep 03 15:20:32 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Sep 2012 15: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 1T8YRc-0005Iu-Te; Mon, 03 Sep 2012 15:20:08 +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 1T8YRb-0005Ip-9S
	for xen-devel@lists.xen.org; Mon, 03 Sep 2012 15:20:07 +0000
Received: from [85.158.143.99:19502] by server-3.bemta-4.messagelabs.com id
	1F/38-08232-6AAC4405; Mon, 03 Sep 2012 15:20:06 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1346685603!21242852!1
X-Originating-IP: [216.32.180.185]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27444 invoked from network); 3 Sep 2012 15:20:05 -0000
Received: from co1ehsobe002.messaging.microsoft.com (HELO
	co1outboundpool.messaging.microsoft.com) (216.32.180.185)
	by server-6.tower-216.messagelabs.com with AES128-SHA encrypted SMTP;
	3 Sep 2012 15:20:05 -0000
Received: from mail10-co1-R.bigfish.com (10.243.78.232) by
	CO1EHSOBE001.bigfish.com (10.243.66.64) with Microsoft SMTP Server id
	14.1.225.23; Mon, 3 Sep 2012 15:20:03 +0000
Received: from mail10-co1 (localhost [127.0.0.1])	by mail10-co1-R.bigfish.com
	(Postfix) with ESMTP id 0F8A86800B1;
	Mon,  3 Sep 2012 15:20:03 +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(zzbb2dI98dI9371I1432I4015Izz1202hzzz2dh668h839hd25he5bhf0ah107ah1155h)
Received: from mail10-co1 (localhost.localdomain [127.0.0.1]) by mail10-co1
	(MessageSwitch) id 1346685600697313_1544;
	Mon,  3 Sep 2012 15:20:00 +0000 (UTC)
Received: from CO1EHSMHS015.bigfish.com (unknown [10.243.78.229])	by
	mail10-co1.bigfish.com (Postfix) with ESMTP id 9C3F64A0046;
	Mon,  3 Sep 2012 15:20:00 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	CO1EHSMHS015.bigfish.com (10.243.66.25) with Microsoft SMTP Server id
	14.1.225.23; Mon, 3 Sep 2012 15:19:59 +0000
X-WSS-ID: 0M9S597-01-CHK-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 2D9391028099;	Mon,  3 Sep 2012 10:19:55 -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;
	Mon, 3 Sep 2012 10:20:00 -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;
	Mon, 3 Sep 2012 10:19: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; Mon, 3 Sep 2012
	11:19:53 -0400
Received: from [165.204.15.57] (gran.osrc.amd.com [165.204.15.57])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id 06A8849C1EC; Mon,  3 Sep 2012
	16:19:53 +0100 (BST)
Message-ID: <5044CAD7.8030800@amd.com>
Date: Mon, 3 Sep 2012 17:20:55 +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: Sander Eikelenboom <linux@eikelenboom.it>
References: <40501859.20120902104331@eikelenboom.it>
	<CC6932C2.3D99D%keir.xen@gmail.com>
	<217459398.20120902171441@eikelenboom.it>
In-Reply-To: <217459398.20120902171441@eikelenboom.it>
X-OriginatorOrg: amd.com
Cc: Keir Fraser <keir.xen@gmail.com>, Santosh Jodh <Santosh.Jodh@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Using debug-key 'o:  Dump IOMMU p2m table,
 locks up machine
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 09/02/2012 05:14 PM, Sander Eikelenboom wrote:
> Sunday, September 2, 2012, 4:58:58 PM, you wrote:
>
>> On 02/09/2012 09:43, "Sander Eikelenboom"<linux@eikelenboom.it>  wrote:
>
>>>> Quite simply, there likely needs to be more tracing on the IOMMU fault path.
>>>> That's a separate concern from your keyhandler of course, but just saying
>>>> I'd be looking for the former rather than the latter, for diagnosing
>>>> Sander's bug.
>>>
>>> Are there any printk's I could add to get more relevant info about the AMD-Vi:
>>> IO_PAGE_FAULT ?
>
>> No really straightforward one. I think we need a per-IOMMU-type handler to
>> walk the IOMMU page table for a given virtual address, and dump every
>> page-table-entry on the path. Like an IOMMU version of show_page_walk().
>> Personally I would suspect this is more useful than the dump-everything
>> handlers: just give a *full* *detailed* walk for the actually interesting
>> virtual address (the one faulted on).
>
>>> I have attached new output from xl dmesg, this time with iommu=debug on (the
>>> option changed from 4.1 to 4.2).
>
>> Not easy to glean any more from that, without extra tracing such as
>> described above, and/or digging into the guest to find what driver-side
>> actions are causing the faults.
>
> OK, too bad!
> With xen 4.1 i haven't experienced those page faults, but a diff between /xen/drivers/passthrough/amd in both trees show quite some changes :(

Did you also update xen tools accordingly? Sometime I also saw a few 
IO_PAGE_FAULTs came from nic if my tools version and HV version did not 
match. But using recent 4.2 and corresponding xl, my tests went well.
BTW: You could also try iommu=no-sharept to see if it helps.

Thanks,
Wei

>>   -- Keir
>
>>>
>>>
>>>>   -- Keir
>>>
>
>
>
>
>
>



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

From xen-devel-bounces@lists.xen.org Mon Sep 03 15:20:32 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Sep 2012 15: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 1T8YRc-0005Iu-Te; Mon, 03 Sep 2012 15:20:08 +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 1T8YRb-0005Ip-9S
	for xen-devel@lists.xen.org; Mon, 03 Sep 2012 15:20:07 +0000
Received: from [85.158.143.99:19502] by server-3.bemta-4.messagelabs.com id
	1F/38-08232-6AAC4405; Mon, 03 Sep 2012 15:20:06 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1346685603!21242852!1
X-Originating-IP: [216.32.180.185]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27444 invoked from network); 3 Sep 2012 15:20:05 -0000
Received: from co1ehsobe002.messaging.microsoft.com (HELO
	co1outboundpool.messaging.microsoft.com) (216.32.180.185)
	by server-6.tower-216.messagelabs.com with AES128-SHA encrypted SMTP;
	3 Sep 2012 15:20:05 -0000
Received: from mail10-co1-R.bigfish.com (10.243.78.232) by
	CO1EHSOBE001.bigfish.com (10.243.66.64) with Microsoft SMTP Server id
	14.1.225.23; Mon, 3 Sep 2012 15:20:03 +0000
Received: from mail10-co1 (localhost [127.0.0.1])	by mail10-co1-R.bigfish.com
	(Postfix) with ESMTP id 0F8A86800B1;
	Mon,  3 Sep 2012 15:20:03 +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(zzbb2dI98dI9371I1432I4015Izz1202hzzz2dh668h839hd25he5bhf0ah107ah1155h)
Received: from mail10-co1 (localhost.localdomain [127.0.0.1]) by mail10-co1
	(MessageSwitch) id 1346685600697313_1544;
	Mon,  3 Sep 2012 15:20:00 +0000 (UTC)
Received: from CO1EHSMHS015.bigfish.com (unknown [10.243.78.229])	by
	mail10-co1.bigfish.com (Postfix) with ESMTP id 9C3F64A0046;
	Mon,  3 Sep 2012 15:20:00 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	CO1EHSMHS015.bigfish.com (10.243.66.25) with Microsoft SMTP Server id
	14.1.225.23; Mon, 3 Sep 2012 15:19:59 +0000
X-WSS-ID: 0M9S597-01-CHK-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 2D9391028099;	Mon,  3 Sep 2012 10:19:55 -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;
	Mon, 3 Sep 2012 10:20:00 -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;
	Mon, 3 Sep 2012 10:19: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; Mon, 3 Sep 2012
	11:19:53 -0400
Received: from [165.204.15.57] (gran.osrc.amd.com [165.204.15.57])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id 06A8849C1EC; Mon,  3 Sep 2012
	16:19:53 +0100 (BST)
Message-ID: <5044CAD7.8030800@amd.com>
Date: Mon, 3 Sep 2012 17:20:55 +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: Sander Eikelenboom <linux@eikelenboom.it>
References: <40501859.20120902104331@eikelenboom.it>
	<CC6932C2.3D99D%keir.xen@gmail.com>
	<217459398.20120902171441@eikelenboom.it>
In-Reply-To: <217459398.20120902171441@eikelenboom.it>
X-OriginatorOrg: amd.com
Cc: Keir Fraser <keir.xen@gmail.com>, Santosh Jodh <Santosh.Jodh@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Using debug-key 'o:  Dump IOMMU p2m table,
 locks up machine
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 09/02/2012 05:14 PM, Sander Eikelenboom wrote:
> Sunday, September 2, 2012, 4:58:58 PM, you wrote:
>
>> On 02/09/2012 09:43, "Sander Eikelenboom"<linux@eikelenboom.it>  wrote:
>
>>>> Quite simply, there likely needs to be more tracing on the IOMMU fault path.
>>>> That's a separate concern from your keyhandler of course, but just saying
>>>> I'd be looking for the former rather than the latter, for diagnosing
>>>> Sander's bug.
>>>
>>> Are there any printk's I could add to get more relevant info about the AMD-Vi:
>>> IO_PAGE_FAULT ?
>
>> No really straightforward one. I think we need a per-IOMMU-type handler to
>> walk the IOMMU page table for a given virtual address, and dump every
>> page-table-entry on the path. Like an IOMMU version of show_page_walk().
>> Personally I would suspect this is more useful than the dump-everything
>> handlers: just give a *full* *detailed* walk for the actually interesting
>> virtual address (the one faulted on).
>
>>> I have attached new output from xl dmesg, this time with iommu=debug on (the
>>> option changed from 4.1 to 4.2).
>
>> Not easy to glean any more from that, without extra tracing such as
>> described above, and/or digging into the guest to find what driver-side
>> actions are causing the faults.
>
> OK, too bad!
> With xen 4.1 i haven't experienced those page faults, but a diff between /xen/drivers/passthrough/amd in both trees show quite some changes :(

Did you also update xen tools accordingly? Sometime I also saw a few 
IO_PAGE_FAULTs came from nic if my tools version and HV version did not 
match. But using recent 4.2 and corresponding xl, my tests went well.
BTW: You could also try iommu=no-sharept to see if it helps.

Thanks,
Wei

>>   -- Keir
>
>>>
>>>
>>>>   -- Keir
>>>
>
>
>
>
>
>



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

From xen-devel-bounces@lists.xen.org Mon Sep 03 15:23:20 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Sep 2012 15:23:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T8YUR-0005Om-GK; Mon, 03 Sep 2012 15:23:03 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <s.munaut@whatever-company.com>) id 1T8YUQ-0005Oh-L8
	for xen-devel@lists.xen.org; Mon, 03 Sep 2012 15:23:02 +0000
Received: from [85.158.138.51:39413] by server-12.bemta-3.messagelabs.com id
	5A/0F-10384-55BC4405; Mon, 03 Sep 2012 15:23:01 +0000
X-Env-Sender: s.munaut@whatever-company.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1346685779!20325900!1
X-Originating-IP: [209.85.212.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29327 invoked from network); 3 Sep 2012 15:23:01 -0000
Received: from mail-vb0-f45.google.com (HELO mail-vb0-f45.google.com)
	(209.85.212.45)
	by server-6.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Sep 2012 15:23:01 -0000
Received: by vbip1 with SMTP id p1so6910547vbi.32
	for <xen-devel@lists.xen.org>; Mon, 03 Sep 2012 08:22:59 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=mime-version:date:message-id:subject:from:to:content-type
	:x-gm-message-state;
	bh=6bwESrUG4G/iqiGNqbPCJZuDkb2cxObym25pnYrct0U=;
	b=XOpGuIgcsp8NajbQ5+MnOC09beiyMjqjh0e6SHugxz/z9hQOrAOXSI3b6KYxXPUrEn
	5Gd6/UV4aKpvJ2kUiueCBnP0IlHwSl1vuQwr6atRCZ6bU2WqX5Q3vCBSnBO73KyXjfBK
	H2DW244Xw0KzigD3KMg7dinWRmyR1N3Ktc0AYgYv0TBt3DkdKeImXn2TVjBq/KU0P47H
	V3czwMs3PUXrT9SwBx5FhdzB2pCXR9GaNM5faJsVmGbFtCFqLipIiVRWYpHP93Dsbz3v
	Ai2kQh0EjHTUaX7KIphe0ba7DD4fB/OBjWK4kePo4auLTfu/+K2JCWKh/YiQ9Gwvr1jV
	PfAw==
MIME-Version: 1.0
Received: by 10.220.228.131 with SMTP id je3mr12612967vcb.73.1346685779478;
	Mon, 03 Sep 2012 08:22:59 -0700 (PDT)
Received: by 10.58.70.172 with HTTP; Mon, 3 Sep 2012 08:22:59 -0700 (PDT)
Date: Mon, 3 Sep 2012 17:22:59 +0200
Message-ID: <CAF6-1L7skB4boJ_zw3RRjGNhb0sKPg7qmsZZUrs4fS5gJtitSA@mail.gmail.com>
From: Sylvain Munaut <s.munaut@whatever-company.com>
To: xen-devel@lists.xen.org
X-Gm-Message-State: ALoCoQltZ5B0HNd3DQRdaaU5qjnxOGei9rfq2gChrACJhvzueZEQpyYhsYZaOJ9lcx1DCvXJ6Zxh
Subject: [Xen-devel] Failure in Xen network PV driver when acceleration
	enabled
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi,

I'm experiencing a failure in DomU networking, seeing messages such as
"net eth0: rx->offset: 0, size: 4294967295" in the DomU.

The setup is:
 - Dom0 running recent 3.6-rc3
 - DomU 1 running a Ceph cluster
 - DomU 2 running of a block device hosted by that ceph cluster.

So basically when DomU 2 makes a block device request, the path is (I think) :

 - DomU 2 Frontend block driver
 - Dom0 Back driver
 - Dom0 RBD Ceph block driver
 - Dom0 Kernel TCP connection to DomU 1
 - Dom0 DomU 1 Backend network driver
 - DomU 1 Frontend network driver

And I'm seeing those "net eth0: rx->offset: 0, size: 4294967295"
messages in DomU1 dmesg. DomU2 doesn't finish booting at all.
>From what I can see in the Ceph logs, it seems that the DomU 1
receives corrupted messages.

I've been digging a bit and it seems issuing a

ethtool -K vif1.0 tx off

in the dom0 prevents the issue. (vif1.0 being the DomU1 virtual
network interface)

Note that it needs to be in the dom0 on the VIF and not in the domU on
the eth0 interface like I originally tried. It's also not enough to
disable gso and/or tso, you need to turn off all tx accel.

I originally reported this in xen-user and ceph-devel but now that the
failure has been narrowed to a Xen PV net bug seems more appropriate.
Thread archive available at
http://lists.xen.org/archives/html/xen-users/2012-08/msg00321.html


Cheers,

      Sylvain

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

From xen-devel-bounces@lists.xen.org Mon Sep 03 15:23:20 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Sep 2012 15:23:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T8YUR-0005Om-GK; Mon, 03 Sep 2012 15:23:03 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <s.munaut@whatever-company.com>) id 1T8YUQ-0005Oh-L8
	for xen-devel@lists.xen.org; Mon, 03 Sep 2012 15:23:02 +0000
Received: from [85.158.138.51:39413] by server-12.bemta-3.messagelabs.com id
	5A/0F-10384-55BC4405; Mon, 03 Sep 2012 15:23:01 +0000
X-Env-Sender: s.munaut@whatever-company.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1346685779!20325900!1
X-Originating-IP: [209.85.212.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29327 invoked from network); 3 Sep 2012 15:23:01 -0000
Received: from mail-vb0-f45.google.com (HELO mail-vb0-f45.google.com)
	(209.85.212.45)
	by server-6.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Sep 2012 15:23:01 -0000
Received: by vbip1 with SMTP id p1so6910547vbi.32
	for <xen-devel@lists.xen.org>; Mon, 03 Sep 2012 08:22:59 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=mime-version:date:message-id:subject:from:to:content-type
	:x-gm-message-state;
	bh=6bwESrUG4G/iqiGNqbPCJZuDkb2cxObym25pnYrct0U=;
	b=XOpGuIgcsp8NajbQ5+MnOC09beiyMjqjh0e6SHugxz/z9hQOrAOXSI3b6KYxXPUrEn
	5Gd6/UV4aKpvJ2kUiueCBnP0IlHwSl1vuQwr6atRCZ6bU2WqX5Q3vCBSnBO73KyXjfBK
	H2DW244Xw0KzigD3KMg7dinWRmyR1N3Ktc0AYgYv0TBt3DkdKeImXn2TVjBq/KU0P47H
	V3czwMs3PUXrT9SwBx5FhdzB2pCXR9GaNM5faJsVmGbFtCFqLipIiVRWYpHP93Dsbz3v
	Ai2kQh0EjHTUaX7KIphe0ba7DD4fB/OBjWK4kePo4auLTfu/+K2JCWKh/YiQ9Gwvr1jV
	PfAw==
MIME-Version: 1.0
Received: by 10.220.228.131 with SMTP id je3mr12612967vcb.73.1346685779478;
	Mon, 03 Sep 2012 08:22:59 -0700 (PDT)
Received: by 10.58.70.172 with HTTP; Mon, 3 Sep 2012 08:22:59 -0700 (PDT)
Date: Mon, 3 Sep 2012 17:22:59 +0200
Message-ID: <CAF6-1L7skB4boJ_zw3RRjGNhb0sKPg7qmsZZUrs4fS5gJtitSA@mail.gmail.com>
From: Sylvain Munaut <s.munaut@whatever-company.com>
To: xen-devel@lists.xen.org
X-Gm-Message-State: ALoCoQltZ5B0HNd3DQRdaaU5qjnxOGei9rfq2gChrACJhvzueZEQpyYhsYZaOJ9lcx1DCvXJ6Zxh
Subject: [Xen-devel] Failure in Xen network PV driver when acceleration
	enabled
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi,

I'm experiencing a failure in DomU networking, seeing messages such as
"net eth0: rx->offset: 0, size: 4294967295" in the DomU.

The setup is:
 - Dom0 running recent 3.6-rc3
 - DomU 1 running a Ceph cluster
 - DomU 2 running of a block device hosted by that ceph cluster.

So basically when DomU 2 makes a block device request, the path is (I think) :

 - DomU 2 Frontend block driver
 - Dom0 Back driver
 - Dom0 RBD Ceph block driver
 - Dom0 Kernel TCP connection to DomU 1
 - Dom0 DomU 1 Backend network driver
 - DomU 1 Frontend network driver

And I'm seeing those "net eth0: rx->offset: 0, size: 4294967295"
messages in DomU1 dmesg. DomU2 doesn't finish booting at all.
>From what I can see in the Ceph logs, it seems that the DomU 1
receives corrupted messages.

I've been digging a bit and it seems issuing a

ethtool -K vif1.0 tx off

in the dom0 prevents the issue. (vif1.0 being the DomU1 virtual
network interface)

Note that it needs to be in the dom0 on the VIF and not in the domU on
the eth0 interface like I originally tried. It's also not enough to
disable gso and/or tso, you need to turn off all tx accel.

I originally reported this in xen-user and ceph-devel but now that the
failure has been narrowed to a Xen PV net bug seems more appropriate.
Thread archive available at
http://lists.xen.org/archives/html/xen-users/2012-08/msg00321.html


Cheers,

      Sylvain

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

From xen-devel-bounces@lists.xen.org Mon Sep 03 15:30:25 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Sep 2012 15: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 1T8YbH-0005az-Cp; Mon, 03 Sep 2012 15:30:07 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1T8YbG-0005au-HO
	for xen-devel@lists.xen.org; Mon, 03 Sep 2012 15:30:06 +0000
Received: from [85.158.138.51:13160] by server-11.bemta-3.messagelabs.com id
	66/EA-30250-DFCC4405; Mon, 03 Sep 2012 15:30:05 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1346686203!22009514!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTEzODI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13811 invoked from network); 3 Sep 2012 15:30:03 -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;
	3 Sep 2012 15:30:03 -0000
X-IronPort-AV: E=Sophos;i="4.80,360,1344211200"; d="scan'208";a="14321838"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Sep 2012 15:30: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.279.1; Mon, 3 Sep 2012
	16:30:02 +0100
Message-ID: <1346686201.32462.32.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Marc Zyngier <marc.zyngier@arm.com>
Date: Mon, 3 Sep 2012 16:30:01 +0100
In-Reply-To: <5044C627.9050302@arm.com>
References: <1346679043.32462.11.camel@zakaz.uk.xensource.com>
	<5044C627.9050302@arm.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Stefano Stabellini <stefano.stabellini@citrix.com>,
	Dave Martin <dave.martin@linaro.org>, "boot-architecture@lists.linaro.org"
	<boot-architecture@lists.linaro.org>,
	"kvmarm@lists.cs.columbia.edu" <kvmarm@lists.cs.columbia.edu>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [kvmarm] boot-wrapper: simple multi module loading
	support
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2012-09-03 at 16:00 +0100, Marc Zyngier wrote:
> On 03/09/12 14:30, Ian Campbell wrote:
> 
> Hi Ian,
> 
> > Apparently kvmarm@ is the place for boot-wrapper discussions so
> > apologies for the otherwise Xen related mail ;)
> > 
> > The following implements support for a very basic protocol for loading
> > multiple "modules" and providing them to the kernel. The ARM port of Xen
> > uses this to support passing both a dom0 kernel and initrd to the
> > hypervisor "kernel".
> > 
> > The Xen side of this can be found in the series at:
> >         http://lists.xen.org/archives/html/xen-devel/2012-09/msg00065.html
> > 
> > With that you can boot Xen on arm using the semi-hosting feature of the
> > model (paths are host paths):
> >         $MODEL linux-system-semi.axf -C cluster.cpu0.semihosting-cmd_line=\
> >                 	'--kernel xen-arm.bin \
> >                 	 --module zImage earlyprintk=xenboot console=ttyAMA1 root=/dev/mmcblk0 ro \
> >                 	 --dtb vexpress-v2p-aem-v7a-xen.dtb -- dom0_mem=256M'
> > 
> > Until we know what bootloaders are going to become common in the ARM
> > servers world it hard to know who we should be working with to define a
> > proper protocol going forward and which bootloaders to supply patches
> > for etc. If anyone has any pointers that would be very useful.
> 
> I don't have any useful insight about bootloaders (I tend to hate them
> all ;-), but what we (KVM/ARM) need is something that implements the
> "boot in HYP mode" thing, as described here:
> 
> https://lists.cs.columbia.edu/pipermail/kvmarm/2012-August/002829.html
> 
> From a discussion with Stefano last week, it looks like this protocol
> can fit Xen as well, but it would be nice to have a formal Ack before we
> push this into RMK's patch system.

Yes, Xen needs this "boot in hyp mode" functionality as well, which AIUI
is main core of the proposal. The bits about leaving a stub hypervisor
behind when the kernel then drops to SVC mode is really an internal
Linux/KVM implementation detail. Xen expects to be launched in hyp mode
and will stay there, it launches the domain 0 kernel in svc mode (so
under Xen the kernel never sees hyp mode).

The proposal in
https://lists.cs.columbia.edu/pipermail/kvmarm/2012-August/002828.html
seems consistent with Xen's requirements to me, both for the hypervisor
itself and the guest kernels (including dom0).

The functionality I'm implementing in boot-wrapper here is something
unrelated to this, it is the mechanism by which the initial modules,
which are loaded by the bootloader and passed to the kernel, get passed
across. This is somewhat similar to the kernel's initrd except there can
be more than one, typically there are two (domain 0 kernel and domain 0
initrd) but you can imagine a world with multiple initial domains and
therefore 2*N modules. This has uses outside of virtualisation too, e.g.
L4 and Hurd both use multiboot (which is the x86 standard for this sort
of stuff), to load all the required initial binaries to get a usable
system off the ground.

Ian.


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

From xen-devel-bounces@lists.xen.org Mon Sep 03 15:30:25 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Sep 2012 15: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 1T8YbH-0005az-Cp; Mon, 03 Sep 2012 15:30:07 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1T8YbG-0005au-HO
	for xen-devel@lists.xen.org; Mon, 03 Sep 2012 15:30:06 +0000
Received: from [85.158.138.51:13160] by server-11.bemta-3.messagelabs.com id
	66/EA-30250-DFCC4405; Mon, 03 Sep 2012 15:30:05 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1346686203!22009514!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTEzODI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13811 invoked from network); 3 Sep 2012 15:30:03 -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;
	3 Sep 2012 15:30:03 -0000
X-IronPort-AV: E=Sophos;i="4.80,360,1344211200"; d="scan'208";a="14321838"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Sep 2012 15:30: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.279.1; Mon, 3 Sep 2012
	16:30:02 +0100
Message-ID: <1346686201.32462.32.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Marc Zyngier <marc.zyngier@arm.com>
Date: Mon, 3 Sep 2012 16:30:01 +0100
In-Reply-To: <5044C627.9050302@arm.com>
References: <1346679043.32462.11.camel@zakaz.uk.xensource.com>
	<5044C627.9050302@arm.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Stefano Stabellini <stefano.stabellini@citrix.com>,
	Dave Martin <dave.martin@linaro.org>, "boot-architecture@lists.linaro.org"
	<boot-architecture@lists.linaro.org>,
	"kvmarm@lists.cs.columbia.edu" <kvmarm@lists.cs.columbia.edu>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [kvmarm] boot-wrapper: simple multi module loading
	support
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2012-09-03 at 16:00 +0100, Marc Zyngier wrote:
> On 03/09/12 14:30, Ian Campbell wrote:
> 
> Hi Ian,
> 
> > Apparently kvmarm@ is the place for boot-wrapper discussions so
> > apologies for the otherwise Xen related mail ;)
> > 
> > The following implements support for a very basic protocol for loading
> > multiple "modules" and providing them to the kernel. The ARM port of Xen
> > uses this to support passing both a dom0 kernel and initrd to the
> > hypervisor "kernel".
> > 
> > The Xen side of this can be found in the series at:
> >         http://lists.xen.org/archives/html/xen-devel/2012-09/msg00065.html
> > 
> > With that you can boot Xen on arm using the semi-hosting feature of the
> > model (paths are host paths):
> >         $MODEL linux-system-semi.axf -C cluster.cpu0.semihosting-cmd_line=\
> >                 	'--kernel xen-arm.bin \
> >                 	 --module zImage earlyprintk=xenboot console=ttyAMA1 root=/dev/mmcblk0 ro \
> >                 	 --dtb vexpress-v2p-aem-v7a-xen.dtb -- dom0_mem=256M'
> > 
> > Until we know what bootloaders are going to become common in the ARM
> > servers world it hard to know who we should be working with to define a
> > proper protocol going forward and which bootloaders to supply patches
> > for etc. If anyone has any pointers that would be very useful.
> 
> I don't have any useful insight about bootloaders (I tend to hate them
> all ;-), but what we (KVM/ARM) need is something that implements the
> "boot in HYP mode" thing, as described here:
> 
> https://lists.cs.columbia.edu/pipermail/kvmarm/2012-August/002829.html
> 
> From a discussion with Stefano last week, it looks like this protocol
> can fit Xen as well, but it would be nice to have a formal Ack before we
> push this into RMK's patch system.

Yes, Xen needs this "boot in hyp mode" functionality as well, which AIUI
is main core of the proposal. The bits about leaving a stub hypervisor
behind when the kernel then drops to SVC mode is really an internal
Linux/KVM implementation detail. Xen expects to be launched in hyp mode
and will stay there, it launches the domain 0 kernel in svc mode (so
under Xen the kernel never sees hyp mode).

The proposal in
https://lists.cs.columbia.edu/pipermail/kvmarm/2012-August/002828.html
seems consistent with Xen's requirements to me, both for the hypervisor
itself and the guest kernels (including dom0).

The functionality I'm implementing in boot-wrapper here is something
unrelated to this, it is the mechanism by which the initial modules,
which are loaded by the bootloader and passed to the kernel, get passed
across. This is somewhat similar to the kernel's initrd except there can
be more than one, typically there are two (domain 0 kernel and domain 0
initrd) but you can imagine a world with multiple initial domains and
therefore 2*N modules. This has uses outside of virtualisation too, e.g.
L4 and Hurd both use multiboot (which is the x86 standard for this sort
of stuff), to load all the required initial binaries to get a usable
system off the ground.

Ian.


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

From xen-devel-bounces@lists.xen.org Mon Sep 03 16:20:00 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Sep 2012 16: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 1T8ZNE-0006I9-Ls; Mon, 03 Sep 2012 16:19:40 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <marc.zyngier@arm.com>) id 1T8ZND-0006I4-MM
	for xen-devel@lists.xen.org; Mon, 03 Sep 2012 16:19:39 +0000
Received: from [85.158.143.99:47076] by server-3.bemta-4.messagelabs.com id
	36/ED-08232-B98D4405; Mon, 03 Sep 2012 16:19:39 +0000
X-Env-Sender: marc.zyngier@arm.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1346689178!23004009!1
X-Originating-IP: [91.220.42.44]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogOTEuMjIwLjQyLjQ0ID0+IDI5NjMxMQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15977 invoked from network); 3 Sep 2012 16:19:38 -0000
Received: from service87.mimecast.com (HELO service87.mimecast.com)
	(91.220.42.44) by server-4.tower-216.messagelabs.com with SMTP;
	3 Sep 2012 16:19:38 -0000
Received: from cam-owa1.Emea.Arm.com (fw-tnat.cambridge.arm.com
	[217.140.96.21]) by service87.mimecast.com;
	Mon, 03 Sep 2012 17:19:38 +0100
Received: from [10.1.70.21] ([10.1.255.212]) by cam-owa1.Emea.Arm.com with
	Microsoft SMTPSVC(6.0.3790.0); Mon, 3 Sep 2012 17:21:41 +0100
Message-ID: <5044D896.60205@arm.com>
Date: Mon, 03 Sep 2012 17:19:34 +0100
From: Marc Zyngier <marc.zyngier@arm.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:14.0) Gecko/20120714 Thunderbird/14.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <1346679043.32462.11.camel@zakaz.uk.xensource.com>
	<5044C627.9050302@arm.com>
	<1346686201.32462.32.camel@zakaz.uk.xensource.com>
In-Reply-To: <1346686201.32462.32.camel@zakaz.uk.xensource.com>
X-Enigmail-Version: 1.5a1pre
X-OriginalArrivalTime: 03 Sep 2012 16:21:41.0561 (UTC)
	FILETIME=[33AAF290:01CD89F0]
X-MC-Unique: 112090317193808301
Cc: Stefano Stabellini <stefano.stabellini@citrix.com>,
	Dave Martin <dave.martin@linaro.org>, "boot-architecture@lists.linaro.org"
	<boot-architecture@lists.linaro.org>,
	"kvmarm@lists.cs.columbia.edu" <kvmarm@lists.cs.columbia.edu>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [kvmarm] boot-wrapper: simple multi module loading
	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 03/09/12 16:30, Ian Campbell wrote:
> On Mon, 2012-09-03 at 16:00 +0100, Marc Zyngier wrote:
>> On 03/09/12 14:30, Ian Campbell wrote:
>>
>>> Until we know what bootloaders are going to become common in the ARM
>>> servers world it hard to know who we should be working with to define a
>>> proper protocol going forward and which bootloaders to supply patches
>>> for etc. If anyone has any pointers that would be very useful.
>>
>> I don't have any useful insight about bootloaders (I tend to hate them
>> all ;-), but what we (KVM/ARM) need is something that implements the
>> "boot in HYP mode" thing, as described here:
>>
>> https://lists.cs.columbia.edu/pipermail/kvmarm/2012-August/002829.html
>>
>> From a discussion with Stefano last week, it looks like this protocol
>> can fit Xen as well, but it would be nice to have a formal Ack before we
>> push this into RMK's patch system.
> 
> Yes, Xen needs this "boot in hyp mode" functionality as well, which AIUI
> is main core of the proposal. The bits about leaving a stub hypervisor
> behind when the kernel then drops to SVC mode is really an internal
> Linux/KVM implementation detail. Xen expects to be launched in hyp mode
> and will stay there, it launches the domain 0 kernel in svc mode (so
> under Xen the kernel never sees hyp mode).
> 
> The proposal in
> https://lists.cs.columbia.edu/pipermail/kvmarm/2012-August/002828.html
> seems consistent with Xen's requirements to me, both for the hypervisor
> itself and the guest kernels (including dom0).

Right, this is exactly what I wanted to know. I just wanted to make sure
the kernel and Xen didn't have diverging requirements.

Sorry for hijacking this thread... ;-)

Thanks,

	M.
-- 
Jazz is not dead. It just smells funny...


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

From xen-devel-bounces@lists.xen.org Mon Sep 03 16:20:00 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Sep 2012 16: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 1T8ZNE-0006I9-Ls; Mon, 03 Sep 2012 16:19:40 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <marc.zyngier@arm.com>) id 1T8ZND-0006I4-MM
	for xen-devel@lists.xen.org; Mon, 03 Sep 2012 16:19:39 +0000
Received: from [85.158.143.99:47076] by server-3.bemta-4.messagelabs.com id
	36/ED-08232-B98D4405; Mon, 03 Sep 2012 16:19:39 +0000
X-Env-Sender: marc.zyngier@arm.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1346689178!23004009!1
X-Originating-IP: [91.220.42.44]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogOTEuMjIwLjQyLjQ0ID0+IDI5NjMxMQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15977 invoked from network); 3 Sep 2012 16:19:38 -0000
Received: from service87.mimecast.com (HELO service87.mimecast.com)
	(91.220.42.44) by server-4.tower-216.messagelabs.com with SMTP;
	3 Sep 2012 16:19:38 -0000
Received: from cam-owa1.Emea.Arm.com (fw-tnat.cambridge.arm.com
	[217.140.96.21]) by service87.mimecast.com;
	Mon, 03 Sep 2012 17:19:38 +0100
Received: from [10.1.70.21] ([10.1.255.212]) by cam-owa1.Emea.Arm.com with
	Microsoft SMTPSVC(6.0.3790.0); Mon, 3 Sep 2012 17:21:41 +0100
Message-ID: <5044D896.60205@arm.com>
Date: Mon, 03 Sep 2012 17:19:34 +0100
From: Marc Zyngier <marc.zyngier@arm.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:14.0) Gecko/20120714 Thunderbird/14.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <1346679043.32462.11.camel@zakaz.uk.xensource.com>
	<5044C627.9050302@arm.com>
	<1346686201.32462.32.camel@zakaz.uk.xensource.com>
In-Reply-To: <1346686201.32462.32.camel@zakaz.uk.xensource.com>
X-Enigmail-Version: 1.5a1pre
X-OriginalArrivalTime: 03 Sep 2012 16:21:41.0561 (UTC)
	FILETIME=[33AAF290:01CD89F0]
X-MC-Unique: 112090317193808301
Cc: Stefano Stabellini <stefano.stabellini@citrix.com>,
	Dave Martin <dave.martin@linaro.org>, "boot-architecture@lists.linaro.org"
	<boot-architecture@lists.linaro.org>,
	"kvmarm@lists.cs.columbia.edu" <kvmarm@lists.cs.columbia.edu>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [kvmarm] boot-wrapper: simple multi module loading
	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 03/09/12 16:30, Ian Campbell wrote:
> On Mon, 2012-09-03 at 16:00 +0100, Marc Zyngier wrote:
>> On 03/09/12 14:30, Ian Campbell wrote:
>>
>>> Until we know what bootloaders are going to become common in the ARM
>>> servers world it hard to know who we should be working with to define a
>>> proper protocol going forward and which bootloaders to supply patches
>>> for etc. If anyone has any pointers that would be very useful.
>>
>> I don't have any useful insight about bootloaders (I tend to hate them
>> all ;-), but what we (KVM/ARM) need is something that implements the
>> "boot in HYP mode" thing, as described here:
>>
>> https://lists.cs.columbia.edu/pipermail/kvmarm/2012-August/002829.html
>>
>> From a discussion with Stefano last week, it looks like this protocol
>> can fit Xen as well, but it would be nice to have a formal Ack before we
>> push this into RMK's patch system.
> 
> Yes, Xen needs this "boot in hyp mode" functionality as well, which AIUI
> is main core of the proposal. The bits about leaving a stub hypervisor
> behind when the kernel then drops to SVC mode is really an internal
> Linux/KVM implementation detail. Xen expects to be launched in hyp mode
> and will stay there, it launches the domain 0 kernel in svc mode (so
> under Xen the kernel never sees hyp mode).
> 
> The proposal in
> https://lists.cs.columbia.edu/pipermail/kvmarm/2012-August/002828.html
> seems consistent with Xen's requirements to me, both for the hypervisor
> itself and the guest kernels (including dom0).

Right, this is exactly what I wanted to know. I just wanted to make sure
the kernel and Xen didn't have diverging requirements.

Sorry for hijacking this thread... ;-)

Thanks,

	M.
-- 
Jazz is not dead. It just smells funny...


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

From xen-devel-bounces@lists.xen.org Mon Sep 03 16:26:00 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Sep 2012 16:26: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 1T8ZT2-0006eK-61; Mon, 03 Sep 2012 16:25:40 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <lists@dadigi.com>) id 1T8ZT1-0006eC-Ea
	for xen-devel@lists.xen.org; Mon, 03 Sep 2012 16:25:39 +0000
Received: from [85.158.139.83:6643] by server-8.bemta-5.messagelabs.com id
	4E/C6-17085-20AD4405; Mon, 03 Sep 2012 16:25:38 +0000
X-Env-Sender: lists@dadigi.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1346689538!25607597!1
X-Originating-IP: [212.227.126.186]
X-SpamReason: No, hits=0.5 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiAyMTIuMjI3LjEyNi4xODYgPT4gNjIwNzM=\n,sa_preprocessor: 
	QmFkIElQOiAyMTIuMjI3LjEyNi4xODYgPT4gNjIwNzM=\n,BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21302 invoked from network); 3 Sep 2012 16:25:38 -0000
Received: from moutng.kundenserver.de (HELO moutng.kundenserver.de)
	(212.227.126.186) by server-4.tower-182.messagelabs.com with SMTP;
	3 Sep 2012 16:25:38 -0000
Received: from [10.10.10.5] (e180140056.adsl.alicedsl.de [85.180.140.56])
	by mrelayeu.kundenserver.de (node=mrbap4) with ESMTP (Nemesis)
	id 0LbacF-1TtTsg3pSl-00lDHK; Mon, 03 Sep 2012 18:25:38 +0200
Message-ID: <5044DA01.9070201@dadigi.com>
Date: Mon, 03 Sep 2012 18:25:37 +0200
From: Daniel Di Giacomo <lists@dadigi.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120827 Thunderbird/15.0
MIME-Version: 1.0
To: xen-devel@lists.xen.org
X-Enigmail-Version: 1.4.4
X-Provags-ID: V02:K0:hm0J3L884tTBbfIuJOhn92YJyIJulfbJNqhbkjUTmdk
	GpLAfSBtL+yVMer0z3JSooIEzVQ4XgzeszBIMhyI3ojhXzHwWv
	n6gfn6ZKGTOTFdoh2WaN6ej9zj/ZIN/FFSvbXTFrqIzYuEpJUF
	4jA077f+SZz04sPrAF/l7sHSj2toVO+0XWi0h/M4p3VIe0zLjK
	90BMi9Wo6bAek8UvHUflWZ+FnCeq4E43YFflkB5n+OTDh3Ncza
	XrdWgKfoxTIr+gYxmxfcfMxBe5vMvxLMu6L6m1R6c5SDhC2dTB
	IdA0Efmcz8FqNHuJNnGjGDyuNe4KQ7hKw/mht0sMk2/gzgpRKB
	hNrkNkhjGMCl+03Yu2rs=
Subject: Re: [Xen-devel] PCI passthrough for domU allocated with more than
 4G memory
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Same problem here.
I'm using gentoo with kernel 3.5.3 (gentoo-sources) and XEN 4.1.2 as dom0.
DomU is also gentoo with the same kernel version.
When I assign more than 4G memory to this domU, the memory for the
passed-through Intel-gigabit-nic cannot be allocated and the
initialization of the device fails.
With 3968M memory assigned everything works fine.
Assigning 8GB RAM to domU works without any problems, when I use the
old kernel-version 2.6.34 (xen-sources) in domU.

Regards
Daniel
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/

iQIcBAEBAgAGBQJQRNn9AAoJEO8IGUBgh06fhtwQAJ0eocxHWeiEJSROM5SObIAm
V/ZulEaLOg/XmavL0KWGeNgHA3N/JtAvKMvpzLxjsGszFFD3h9ndtX0eRHnQPYC3
38tMNjIGllUzEiHl5ESCnaChrekI6/hH7NYqoMmXndbJkexUmlaJyRd6Rgy4SIhn
k6x2nwYG9gIg6wMVbQadbosYxOPKdKRosL1mglBuzK/J/c5hdqzxK4j6DfMVHonx
aXw1B1/Ga7zxwG9651bheCrDbXi8yVqadGoXjXZWhp2vQSxwh4k2QgOaTY5vgOjJ
UTkuhtlrAI3ZdyCHpLq8dd8oS6QUyQmjJdbQe5kTMufA5GGl4b//zU4pDieOqkFp
YCAPghCDk+l691Lg/UkvVgj4jgbTDsvcYtF3uM8h+dOs4L1R36WgSsuAqvwT+LjH
DWc5g7h6VsML4J5gcXsG0IvLycHvWhpiDbJD8gp0qzcXAamMRcBkAJhVal4JnwmI
2f4WMPyVEGjkRUgV22AOgNTjflxG9Rla9CbnPamYj4yVh47lsRix+hlZbrPUl3MW
V9UsKUpt+E6dCl56dq7YziZkZj9iLABG+j4rKNk93DTJMgPbwXck4BCXIrztm+s+
Y3QAh+5k0aM/Om3nUftcYrF3z8TDHWTCCXA/JRQ6G/PAo+K19pom6KpjanZQ41IC
G0t3eBJdeJpCNNvgtXiM
=QheK
-----END PGP SIGNATURE-----

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

From xen-devel-bounces@lists.xen.org Mon Sep 03 16:26:00 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Sep 2012 16:26: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 1T8ZT2-0006eK-61; Mon, 03 Sep 2012 16:25:40 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <lists@dadigi.com>) id 1T8ZT1-0006eC-Ea
	for xen-devel@lists.xen.org; Mon, 03 Sep 2012 16:25:39 +0000
Received: from [85.158.139.83:6643] by server-8.bemta-5.messagelabs.com id
	4E/C6-17085-20AD4405; Mon, 03 Sep 2012 16:25:38 +0000
X-Env-Sender: lists@dadigi.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1346689538!25607597!1
X-Originating-IP: [212.227.126.186]
X-SpamReason: No, hits=0.5 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiAyMTIuMjI3LjEyNi4xODYgPT4gNjIwNzM=\n,sa_preprocessor: 
	QmFkIElQOiAyMTIuMjI3LjEyNi4xODYgPT4gNjIwNzM=\n,BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21302 invoked from network); 3 Sep 2012 16:25:38 -0000
Received: from moutng.kundenserver.de (HELO moutng.kundenserver.de)
	(212.227.126.186) by server-4.tower-182.messagelabs.com with SMTP;
	3 Sep 2012 16:25:38 -0000
Received: from [10.10.10.5] (e180140056.adsl.alicedsl.de [85.180.140.56])
	by mrelayeu.kundenserver.de (node=mrbap4) with ESMTP (Nemesis)
	id 0LbacF-1TtTsg3pSl-00lDHK; Mon, 03 Sep 2012 18:25:38 +0200
Message-ID: <5044DA01.9070201@dadigi.com>
Date: Mon, 03 Sep 2012 18:25:37 +0200
From: Daniel Di Giacomo <lists@dadigi.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120827 Thunderbird/15.0
MIME-Version: 1.0
To: xen-devel@lists.xen.org
X-Enigmail-Version: 1.4.4
X-Provags-ID: V02:K0:hm0J3L884tTBbfIuJOhn92YJyIJulfbJNqhbkjUTmdk
	GpLAfSBtL+yVMer0z3JSooIEzVQ4XgzeszBIMhyI3ojhXzHwWv
	n6gfn6ZKGTOTFdoh2WaN6ej9zj/ZIN/FFSvbXTFrqIzYuEpJUF
	4jA077f+SZz04sPrAF/l7sHSj2toVO+0XWi0h/M4p3VIe0zLjK
	90BMi9Wo6bAek8UvHUflWZ+FnCeq4E43YFflkB5n+OTDh3Ncza
	XrdWgKfoxTIr+gYxmxfcfMxBe5vMvxLMu6L6m1R6c5SDhC2dTB
	IdA0Efmcz8FqNHuJNnGjGDyuNe4KQ7hKw/mht0sMk2/gzgpRKB
	hNrkNkhjGMCl+03Yu2rs=
Subject: Re: [Xen-devel] PCI passthrough for domU allocated with more than
 4G memory
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Same problem here.
I'm using gentoo with kernel 3.5.3 (gentoo-sources) and XEN 4.1.2 as dom0.
DomU is also gentoo with the same kernel version.
When I assign more than 4G memory to this domU, the memory for the
passed-through Intel-gigabit-nic cannot be allocated and the
initialization of the device fails.
With 3968M memory assigned everything works fine.
Assigning 8GB RAM to domU works without any problems, when I use the
old kernel-version 2.6.34 (xen-sources) in domU.

Regards
Daniel
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/

iQIcBAEBAgAGBQJQRNn9AAoJEO8IGUBgh06fhtwQAJ0eocxHWeiEJSROM5SObIAm
V/ZulEaLOg/XmavL0KWGeNgHA3N/JtAvKMvpzLxjsGszFFD3h9ndtX0eRHnQPYC3
38tMNjIGllUzEiHl5ESCnaChrekI6/hH7NYqoMmXndbJkexUmlaJyRd6Rgy4SIhn
k6x2nwYG9gIg6wMVbQadbosYxOPKdKRosL1mglBuzK/J/c5hdqzxK4j6DfMVHonx
aXw1B1/Ga7zxwG9651bheCrDbXi8yVqadGoXjXZWhp2vQSxwh4k2QgOaTY5vgOjJ
UTkuhtlrAI3ZdyCHpLq8dd8oS6QUyQmjJdbQe5kTMufA5GGl4b//zU4pDieOqkFp
YCAPghCDk+l691Lg/UkvVgj4jgbTDsvcYtF3uM8h+dOs4L1R36WgSsuAqvwT+LjH
DWc5g7h6VsML4J5gcXsG0IvLycHvWhpiDbJD8gp0qzcXAamMRcBkAJhVal4JnwmI
2f4WMPyVEGjkRUgV22AOgNTjflxG9Rla9CbnPamYj4yVh47lsRix+hlZbrPUl3MW
V9UsKUpt+E6dCl56dq7YziZkZj9iLABG+j4rKNk93DTJMgPbwXck4BCXIrztm+s+
Y3QAh+5k0aM/Om3nUftcYrF3z8TDHWTCCXA/JRQ6G/PAo+K19pom6KpjanZQ41IC
G0t3eBJdeJpCNNvgtXiM
=QheK
-----END PGP SIGNATURE-----

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

From xen-devel-bounces@lists.xen.org Mon Sep 03 17:52:43 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Sep 2012 17:52:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T8aoq-00087w-63; Mon, 03 Sep 2012 17:52:16 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andreslc@gridcentric.ca>) id 1T8aoo-00087o-RF
	for xen-devel@lists.xen.org; Mon, 03 Sep 2012 17:52:15 +0000
X-Env-Sender: andreslc@gridcentric.ca
X-Msg-Ref: server-12.tower-27.messagelabs.com!1346694726!9392546!1
X-Originating-IP: [209.85.210.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7200 invoked from network); 3 Sep 2012 17:52:07 -0000
Received: from mail-iy0-f173.google.com (HELO mail-iy0-f173.google.com)
	(209.85.210.173)
	by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Sep 2012 17:52:07 -0000
Received: by iakx26 with SMTP id x26so10032416iak.32
	for <xen-devel@lists.xen.org>; Mon, 03 Sep 2012 10:52:06 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=subject:mime-version:content-type:from:in-reply-to:date:cc
	:content-transfer-encoding:message-id:references:to:x-mailer
	:x-gm-message-state;
	bh=KzLGbJgUuJR0v8rFlwkvWgr51igWaWrvjzsCPkyzdLw=;
	b=kzseQf7cf0X/EroA8kHlAIhq3cf7IEiET8+lWfgPQiCx8kqnJMGV2PnWJUQYblc/PG
	B3RDCCpemkAVr/CUlpeA8yIzDWSu55mgSouxNIF2gFhejY8wfVg2ua6G2ASyIUcXe5dk
	fGkkP9UI9neiXq6SpH9K2HFnpkxB9mffKyScmYjBpoMfB6fgW4jvaUd9UfjSMWrHzOBI
	EQvUzNYI143Ksq47U6j8VtKVofYMYfTaTi6AwO7fDdVB8UmxPufBkKsBbC93YtkOcGYa
	X49cldAyC+72XvUzA83mBbX7QXKqlDFkNXUZHr97sTKQeFrZ64UqOfCqrpKVqvjlOxhY
	2FEw==
Received: by 10.50.10.227 with SMTP id l3mr11343037igb.71.1346694725946;
	Mon, 03 Sep 2012 10:52:05 -0700 (PDT)
Received: from [192.168.1.100] (69-196-182-10.dsl.teksavvy.com.
	[69.196.182.10])
	by mx.google.com with ESMTPS id ud8sm20667905igb.4.2012.09.03.10.52.04
	(version=TLSv1/SSLv3 cipher=OTHER);
	Mon, 03 Sep 2012 10:52:05 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1278)
From: Andres Lagar-Cavilla <andreslc@gridcentric.ca>
In-Reply-To: <99b7a5af9b3059bac273.1346676538@cosworth.uk.xensource.com>
Date: Mon, 3 Sep 2012 13:52:10 -0400
Message-Id: <36A750C8-EEC5-484B-8966-DD12B4459BAF@gridcentric.ca>
References: <99b7a5af9b3059bac273.1346676538@cosworth.uk.xensource.com>
To: Ian Campbell <ian.campbell@citrix.com>
X-Mailer: Apple Mail (2.1278)
X-Gm-Message-State: ALoCoQmiiEq32IZkx3vvsyAP/8b7V6sHNySNpgN5po7lQN4VRO63qh8cOeirZ8QbZ4f7JzJ5mjoL
Cc: Andres Lagar-Cavilla <andreslc@gridcentric.ca>, Ian.Jackson@citrix.com,
	tim@xen.org, Stefano Panella <stefano.panella@citrix.com>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] libxl: handle errors from xc_sharing_* info
	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 Sep 3, 2012, at 8:48 AM, Ian Campbell wrote:

> # HG changeset patch
> # User Ian Campbell <ian.campbell@citrix.com>
> # Date 1346676461 -3600
> # Node ID 99b7a5af9b3059bac2732a601fb1d574b9f02975
> # Parent  c4e822e1b491bb7efa962b38fff6f007f01596b5
> libxl: handle errors from xc_sharing_* info functions
> 
> On a 32 bit hypervisor xl info currently reports:
> sharing_freed_memory   : 72057594037927935
> sharing_used_memory    : 72057594037927935
> 
> Eat the ENOSYS and turn it into 0. Log and propagate other errors.
> 
> I don't have a 32 bit system handy, so tested on x86_64 with a libxc
> hacked to return -ENOSYS and -EINVAL.
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

Good catch!
Andres
> 
> diff -r c4e822e1b491 -r 99b7a5af9b30 tools/libxl/libxl.c
> --- a/tools/libxl/libxl.c	Mon Sep 03 09:59:35 2012 +0100
> +++ b/tools/libxl/libxl.c	Mon Sep 03 13:47:41 2012 +0100
> @@ -3622,6 +3622,7 @@ int libxl_get_physinfo(libxl_ctx *ctx, l
> {
>     xc_physinfo_t xcphysinfo = { 0 };
>     int rc;
> +    long l;
> 
>     rc = xc_physinfo(ctx->xch, &xcphysinfo);
>     if (rc != 0) {
> @@ -3636,8 +3637,20 @@ int libxl_get_physinfo(libxl_ctx *ctx, l
>     physinfo->total_pages = xcphysinfo.total_pages;
>     physinfo->free_pages = xcphysinfo.free_pages;
>     physinfo->scrub_pages = xcphysinfo.scrub_pages;
> -    physinfo->sharing_freed_pages = xc_sharing_freed_pages(ctx->xch);
> -    physinfo->sharing_used_frames = xc_sharing_used_frames(ctx->xch);
> +    l = xc_sharing_freed_pages(ctx->xch);
> +    if ( l < 0 && l != -ENOSYS ) {
> +        LIBXL__LOG_ERRNOVAL(ctx, LIBXL__LOG_ERROR, l,
> +                            "getting sharing freed pages");
> +        return ERROR_FAIL;
> +    }
> +    physinfo->sharing_freed_pages = (l == -ENOSYS) ? 0 : l;
> +    l = xc_sharing_used_frames(ctx->xch);
> +    if ( l < 0 && l != -ENOSYS ) {
> +        LIBXL__LOG_ERRNOVAL(ctx, LIBXL__LOG_ERROR, l,
> +                            "getting sharing used frames");
> +        return ERROR_FAIL;
> +    }
> +    physinfo->sharing_used_frames = (l == -ENOSYS) ? 0 : l;
>     physinfo->nr_nodes = xcphysinfo.nr_nodes;
>     memcpy(physinfo->hw_cap,xcphysinfo.hw_cap, sizeof(physinfo->hw_cap));
> 


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

From xen-devel-bounces@lists.xen.org Mon Sep 03 17:52:43 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 03 Sep 2012 17:52:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T8aoq-00087w-63; Mon, 03 Sep 2012 17:52:16 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andreslc@gridcentric.ca>) id 1T8aoo-00087o-RF
	for xen-devel@lists.xen.org; Mon, 03 Sep 2012 17:52:15 +0000
X-Env-Sender: andreslc@gridcentric.ca
X-Msg-Ref: server-12.tower-27.messagelabs.com!1346694726!9392546!1
X-Originating-IP: [209.85.210.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7200 invoked from network); 3 Sep 2012 17:52:07 -0000
Received: from mail-iy0-f173.google.com (HELO mail-iy0-f173.google.com)
	(209.85.210.173)
	by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Sep 2012 17:52:07 -0000
Received: by iakx26 with SMTP id x26so10032416iak.32
	for <xen-devel@lists.xen.org>; Mon, 03 Sep 2012 10:52:06 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=subject:mime-version:content-type:from:in-reply-to:date:cc
	:content-transfer-encoding:message-id:references:to:x-mailer
	:x-gm-message-state;
	bh=KzLGbJgUuJR0v8rFlwkvWgr51igWaWrvjzsCPkyzdLw=;
	b=kzseQf7cf0X/EroA8kHlAIhq3cf7IEiET8+lWfgPQiCx8kqnJMGV2PnWJUQYblc/PG
	B3RDCCpemkAVr/CUlpeA8yIzDWSu55mgSouxNIF2gFhejY8wfVg2ua6G2ASyIUcXe5dk
	fGkkP9UI9neiXq6SpH9K2HFnpkxB9mffKyScmYjBpoMfB6fgW4jvaUd9UfjSMWrHzOBI
	EQvUzNYI143Ksq47U6j8VtKVofYMYfTaTi6AwO7fDdVB8UmxPufBkKsBbC93YtkOcGYa
	X49cldAyC+72XvUzA83mBbX7QXKqlDFkNXUZHr97sTKQeFrZ64UqOfCqrpKVqvjlOxhY
	2FEw==
Received: by 10.50.10.227 with SMTP id l3mr11343037igb.71.1346694725946;
	Mon, 03 Sep 2012 10:52:05 -0700 (PDT)
Received: from [192.168.1.100] (69-196-182-10.dsl.teksavvy.com.
	[69.196.182.10])
	by mx.google.com with ESMTPS id ud8sm20667905igb.4.2012.09.03.10.52.04
	(version=TLSv1/SSLv3 cipher=OTHER);
	Mon, 03 Sep 2012 10:52:05 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1278)
From: Andres Lagar-Cavilla <andreslc@gridcentric.ca>
In-Reply-To: <99b7a5af9b3059bac273.1346676538@cosworth.uk.xensource.com>
Date: Mon, 3 Sep 2012 13:52:10 -0400
Message-Id: <36A750C8-EEC5-484B-8966-DD12B4459BAF@gridcentric.ca>
References: <99b7a5af9b3059bac273.1346676538@cosworth.uk.xensource.com>
To: Ian Campbell <ian.campbell@citrix.com>
X-Mailer: Apple Mail (2.1278)
X-Gm-Message-State: ALoCoQmiiEq32IZkx3vvsyAP/8b7V6sHNySNpgN5po7lQN4VRO63qh8cOeirZ8QbZ4f7JzJ5mjoL
Cc: Andres Lagar-Cavilla <andreslc@gridcentric.ca>, Ian.Jackson@citrix.com,
	tim@xen.org, Stefano Panella <stefano.panella@citrix.com>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] libxl: handle errors from xc_sharing_* info
	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 Sep 3, 2012, at 8:48 AM, Ian Campbell wrote:

> # HG changeset patch
> # User Ian Campbell <ian.campbell@citrix.com>
> # Date 1346676461 -3600
> # Node ID 99b7a5af9b3059bac2732a601fb1d574b9f02975
> # Parent  c4e822e1b491bb7efa962b38fff6f007f01596b5
> libxl: handle errors from xc_sharing_* info functions
> 
> On a 32 bit hypervisor xl info currently reports:
> sharing_freed_memory   : 72057594037927935
> sharing_used_memory    : 72057594037927935
> 
> Eat the ENOSYS and turn it into 0. Log and propagate other errors.
> 
> I don't have a 32 bit system handy, so tested on x86_64 with a libxc
> hacked to return -ENOSYS and -EINVAL.
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

Good catch!
Andres
> 
> diff -r c4e822e1b491 -r 99b7a5af9b30 tools/libxl/libxl.c
> --- a/tools/libxl/libxl.c	Mon Sep 03 09:59:35 2012 +0100
> +++ b/tools/libxl/libxl.c	Mon Sep 03 13:47:41 2012 +0100
> @@ -3622,6 +3622,7 @@ int libxl_get_physinfo(libxl_ctx *ctx, l
> {
>     xc_physinfo_t xcphysinfo = { 0 };
>     int rc;
> +    long l;
> 
>     rc = xc_physinfo(ctx->xch, &xcphysinfo);
>     if (rc != 0) {
> @@ -3636,8 +3637,20 @@ int libxl_get_physinfo(libxl_ctx *ctx, l
>     physinfo->total_pages = xcphysinfo.total_pages;
>     physinfo->free_pages = xcphysinfo.free_pages;
>     physinfo->scrub_pages = xcphysinfo.scrub_pages;
> -    physinfo->sharing_freed_pages = xc_sharing_freed_pages(ctx->xch);
> -    physinfo->sharing_used_frames = xc_sharing_used_frames(ctx->xch);
> +    l = xc_sharing_freed_pages(ctx->xch);
> +    if ( l < 0 && l != -ENOSYS ) {
> +        LIBXL__LOG_ERRNOVAL(ctx, LIBXL__LOG_ERROR, l,
> +                            "getting sharing freed pages");
> +        return ERROR_FAIL;
> +    }
> +    physinfo->sharing_freed_pages = (l == -ENOSYS) ? 0 : l;
> +    l = xc_sharing_used_frames(ctx->xch);
> +    if ( l < 0 && l != -ENOSYS ) {
> +        LIBXL__LOG_ERRNOVAL(ctx, LIBXL__LOG_ERROR, l,
> +                            "getting sharing used frames");
> +        return ERROR_FAIL;
> +    }
> +    physinfo->sharing_used_frames = (l == -ENOSYS) ? 0 : l;
>     physinfo->nr_nodes = xcphysinfo.nr_nodes;
>     memcpy(physinfo->hw_cap,xcphysinfo.hw_cap, sizeof(physinfo->hw_cap));
> 


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

From xen-devel-bounces@lists.xen.org Tue Sep 04 02:13:02 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Sep 2012 02: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 1T8icv-00069Q-LU; Tue, 04 Sep 2012 02:12:29 +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 1T8ict-00069H-J0
	for xen-devel@lists.xen.org; Tue, 04 Sep 2012 02:12:27 +0000
Received: from [85.158.143.35:18733] by server-3.bemta-4.messagelabs.com id
	A0/16-08232-A8365405; Tue, 04 Sep 2012 02:12:26 +0000
X-Env-Sender: msw@amazon.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1346724745!16564621!1
X-Originating-IP: [72.21.198.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNzIuMjEuMTk4LjI1ID0+IDE3MjI3Mg==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26787 invoked from network); 4 Sep 2012 02:12:26 -0000
Received: from smtp-fw-4101.amazon.com (HELO smtp-fw-4101.amazon.com)
	(72.21.198.25)
	by server-14.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Sep 2012 02:12:26 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=amazon.com; i=msw@amazon.com; q=dns/txt; s=rte02;
	t=1346724746; x=1378260746;
	h=date:from:to:cc:subject:message-id:references:
	mime-version:in-reply-to;
	bh=mp6tdlE9t0X6PN2JQF4pLdmNzt9giJ00lmCehQx46AU=;
	b=FOuAl69B6i3dUFhfDU0PNhkO8yIsPVfwggULmpBM593yyEDQS7j3cSuk
	jEU8q4wrkMfvF7NLGikXVJRBDI96rA==;
X-IronPort-AV: E=Sophos;i="4.80,363,1344211200"; d="scan'208";a="790662611"
Received: from smtp-in-0102.sea3.amazon.com ([10.224.19.46])
	by smtp-border-fw-out-4101.iad4.amazon.com with
	ESMTP/TLS/DHE-RSA-AES256-SHA; 04 Sep 2012 02:12:23 +0000
Received: from ex10-hub-9003.ant.amazon.com (ex10-hub-9003.ant.amazon.com
	[10.185.137.132])
	by smtp-in-0102.sea3.amazon.com (8.13.8/8.13.8) with ESMTP id
	q842CMSN032643
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL);
	Tue, 4 Sep 2012 02:12:22 GMT
Received: from u002268147cd4502c336d.ant.amazon.com (10.224.80.34) by
	ex10-hub-9003.ant.amazon.com (10.185.137.132) with Microsoft SMTP
	Server id 14.2.247.3; Mon, 3 Sep 2012 19:12:06 -0700
Received: by u002268147cd4502c336d.ant.amazon.com (sSMTP sendmail emulation); 
	Mon, 03 Sep 2012 19:12:05 -0700
Date: Mon, 3 Sep 2012 19:12:05 -0700
From: Matt Wilson <msw@amazon.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120904021137.GA7356@u002268147cd4502c336d.ant.amazon.com>
References: <patchbomb.1346353198@u002268147cd4502c336d.ant.amazon.com>
	<651347cccff7c5619ab0.1346353200@u002268147cd4502c336d.ant.amazon.com>
	<1346405211.27277.133.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1346405211.27277.133.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 2 of 2 v2] docs: use elinks to format
 markdown-generated html to text
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Aug 31, 2012 at 10:26:51AM +0100, Ian Campbell wrote:
> On Thu, 2012-08-30 at 20:00 +0100, Matt Wilson wrote:
> > Markdown, while easy to read and write, isn't the most consumable
> > format for users reading documentation on a terminal. This patch uses
> > lynx to format markdown produced HTML into text files.
> 
> s/lynx/elinks/ in the comment.
> 
> > diff -r 512b4e0c49f3 -r 651347cccff7 config/Tools.mk.in
> > --- a/config/Tools.mk.in	Thu Aug 30 10:51:00 2012 -0700
> > +++ b/config/Tools.mk.in	Thu Aug 30 11:56:01 2012 -0700
> > @@ -34,6 +34,8 @@
> >  DOT                 := @DOT@
> >  NEATO               := @NEATO@
> >  MARKDOWN            := @MARKDOWN@
> > +HTMLDUMP            := @HTMLDUMP@
> > +HTMLDUMPFLAGS       := @HTMLDUMPFLAGS@
> 
> Does HTMLDUMP="elinks -dump" not work?

I don't think so. AC_PATH_PROG() will just want the program name. This
follows the CC / CFLAGS model.

Matt


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

From xen-devel-bounces@lists.xen.org Tue Sep 04 02:13:02 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Sep 2012 02: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 1T8icv-00069Q-LU; Tue, 04 Sep 2012 02:12:29 +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 1T8ict-00069H-J0
	for xen-devel@lists.xen.org; Tue, 04 Sep 2012 02:12:27 +0000
Received: from [85.158.143.35:18733] by server-3.bemta-4.messagelabs.com id
	A0/16-08232-A8365405; Tue, 04 Sep 2012 02:12:26 +0000
X-Env-Sender: msw@amazon.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1346724745!16564621!1
X-Originating-IP: [72.21.198.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNzIuMjEuMTk4LjI1ID0+IDE3MjI3Mg==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26787 invoked from network); 4 Sep 2012 02:12:26 -0000
Received: from smtp-fw-4101.amazon.com (HELO smtp-fw-4101.amazon.com)
	(72.21.198.25)
	by server-14.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Sep 2012 02:12:26 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=amazon.com; i=msw@amazon.com; q=dns/txt; s=rte02;
	t=1346724746; x=1378260746;
	h=date:from:to:cc:subject:message-id:references:
	mime-version:in-reply-to;
	bh=mp6tdlE9t0X6PN2JQF4pLdmNzt9giJ00lmCehQx46AU=;
	b=FOuAl69B6i3dUFhfDU0PNhkO8yIsPVfwggULmpBM593yyEDQS7j3cSuk
	jEU8q4wrkMfvF7NLGikXVJRBDI96rA==;
X-IronPort-AV: E=Sophos;i="4.80,363,1344211200"; d="scan'208";a="790662611"
Received: from smtp-in-0102.sea3.amazon.com ([10.224.19.46])
	by smtp-border-fw-out-4101.iad4.amazon.com with
	ESMTP/TLS/DHE-RSA-AES256-SHA; 04 Sep 2012 02:12:23 +0000
Received: from ex10-hub-9003.ant.amazon.com (ex10-hub-9003.ant.amazon.com
	[10.185.137.132])
	by smtp-in-0102.sea3.amazon.com (8.13.8/8.13.8) with ESMTP id
	q842CMSN032643
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL);
	Tue, 4 Sep 2012 02:12:22 GMT
Received: from u002268147cd4502c336d.ant.amazon.com (10.224.80.34) by
	ex10-hub-9003.ant.amazon.com (10.185.137.132) with Microsoft SMTP
	Server id 14.2.247.3; Mon, 3 Sep 2012 19:12:06 -0700
Received: by u002268147cd4502c336d.ant.amazon.com (sSMTP sendmail emulation); 
	Mon, 03 Sep 2012 19:12:05 -0700
Date: Mon, 3 Sep 2012 19:12:05 -0700
From: Matt Wilson <msw@amazon.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120904021137.GA7356@u002268147cd4502c336d.ant.amazon.com>
References: <patchbomb.1346353198@u002268147cd4502c336d.ant.amazon.com>
	<651347cccff7c5619ab0.1346353200@u002268147cd4502c336d.ant.amazon.com>
	<1346405211.27277.133.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1346405211.27277.133.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 2 of 2 v2] docs: use elinks to format
 markdown-generated html to text
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Aug 31, 2012 at 10:26:51AM +0100, Ian Campbell wrote:
> On Thu, 2012-08-30 at 20:00 +0100, Matt Wilson wrote:
> > Markdown, while easy to read and write, isn't the most consumable
> > format for users reading documentation on a terminal. This patch uses
> > lynx to format markdown produced HTML into text files.
> 
> s/lynx/elinks/ in the comment.
> 
> > diff -r 512b4e0c49f3 -r 651347cccff7 config/Tools.mk.in
> > --- a/config/Tools.mk.in	Thu Aug 30 10:51:00 2012 -0700
> > +++ b/config/Tools.mk.in	Thu Aug 30 11:56:01 2012 -0700
> > @@ -34,6 +34,8 @@
> >  DOT                 := @DOT@
> >  NEATO               := @NEATO@
> >  MARKDOWN            := @MARKDOWN@
> > +HTMLDUMP            := @HTMLDUMP@
> > +HTMLDUMPFLAGS       := @HTMLDUMPFLAGS@
> 
> Does HTMLDUMP="elinks -dump" not work?

I don't think so. AC_PATH_PROG() will just want the program name. This
follows the CC / CFLAGS model.

Matt


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

From xen-devel-bounces@lists.xen.org Tue Sep 04 02:13:50 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Sep 2012 02:13: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 1T8ide-0006CM-3D; Tue, 04 Sep 2012 02:13:14 +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 1T8idc-0006CB-SD
	for xen-devel@lists.xen.org; Tue, 04 Sep 2012 02:13:13 +0000
Received: from [85.158.139.83:32715] by server-7.bemta-5.messagelabs.com id
	B9/A4-19703-8B365405; Tue, 04 Sep 2012 02:13:12 +0000
X-Env-Sender: msw@amazon.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1346724790!28204459!1
X-Originating-IP: [72.21.196.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNzIuMjEuMTk2LjI1ID0+IDEyMTU4Ng==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12852 invoked from network); 4 Sep 2012 02:13:11 -0000
Received: from smtp-fw-2101.amazon.com (HELO smtp-fw-2101.amazon.com)
	(72.21.196.25)
	by server-12.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Sep 2012 02:13:11 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=amazon.com; i=msw@amazon.com; q=dns/txt; s=rte02;
	t=1346724791; x=1378260791;
	h=date:from:to:cc:subject:message-id:references:
	mime-version:in-reply-to;
	bh=Mc25fUq8gdckxpk3CIAogWTIzT0gGcsH8KefzlCUf14=;
	b=EYTGX9+PzDlzmDLFYzvUHNmCWr8mVMKKCcHh8Gez/39vrlaUscz4qhau
	hSELDj/QSasvoYFIFDLQ0tk6rRd3Nw==;
X-IronPort-AV: E=Sophos;i="4.80,363,1344211200"; d="scan'208";a="434051480"
Received: from smtp-in-9002.sea19.amazon.com ([10.186.174.20])
	by smtp-border-fw-out-2101.iad2.amazon.com with
	ESMTP/TLS/DHE-RSA-AES256-SHA; 04 Sep 2012 02:13:09 +0000
Received: from ex10-hub-31005.ant.amazon.com (ex10-hub-31005.sea31.amazon.com
	[10.185.176.12])
	by smtp-in-9002.sea19.amazon.com (8.13.8/8.13.8) with ESMTP id
	q842D8Th017086
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL);
	Tue, 4 Sep 2012 02:13:08 GMT
Received: from u002268147cd4502c336d.ant.amazon.com (10.224.80.38) by
	ex10-hub-31005.ant.amazon.com (10.185.176.12) with Microsoft SMTP
	Server id 14.2.247.3; Mon, 3 Sep 2012 19:13:05 -0700
Received: by u002268147cd4502c336d.ant.amazon.com (sSMTP sendmail emulation); 
	Mon, 03 Sep 2012 19:13:02 -0700
Date: Mon, 3 Sep 2012 19:13:02 -0700
From: Matt Wilson <msw@amazon.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120904021259.GB7356@u002268147cd4502c336d.ant.amazon.com>
References: <patchbomb.1346353198@u002268147cd4502c336d.ant.amazon.com>
	<512b4e0c49f331e252ae.1346353199@u002268147cd4502c336d.ant.amazon.com>
	<1346405131.27277.131.camel@zakaz.uk.xensource.com>
	<1346416200.27277.203.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1346416200.27277.203.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 1 of 2 v2] tools: check for documentation
 generation tools at configure 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 Fri, Aug 31, 2012 at 01:30:00PM +0100, Ian Campbell wrote:
> On Fri, 2012-08-31 at 10:25 +0100, Ian Campbell wrote:
> > > +AC_DEFUN([AX_DOCS_TOOL_PROGS], [
> > > +dnl
> > > +    AC_ARG_VAR([$1], [Path to $2 tool])
> > 
> > Does this do something sensible when $2 is a space separated list?
> 
> Not especially:
> $ ./configure --help| grep mark
>    MARKDOWN    Path to markdown markdown_py tool

I'll fix that up.

Matt

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

From xen-devel-bounces@lists.xen.org Tue Sep 04 02:13:50 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Sep 2012 02:13: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 1T8ide-0006CM-3D; Tue, 04 Sep 2012 02:13:14 +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 1T8idc-0006CB-SD
	for xen-devel@lists.xen.org; Tue, 04 Sep 2012 02:13:13 +0000
Received: from [85.158.139.83:32715] by server-7.bemta-5.messagelabs.com id
	B9/A4-19703-8B365405; Tue, 04 Sep 2012 02:13:12 +0000
X-Env-Sender: msw@amazon.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1346724790!28204459!1
X-Originating-IP: [72.21.196.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNzIuMjEuMTk2LjI1ID0+IDEyMTU4Ng==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12852 invoked from network); 4 Sep 2012 02:13:11 -0000
Received: from smtp-fw-2101.amazon.com (HELO smtp-fw-2101.amazon.com)
	(72.21.196.25)
	by server-12.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Sep 2012 02:13:11 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=amazon.com; i=msw@amazon.com; q=dns/txt; s=rte02;
	t=1346724791; x=1378260791;
	h=date:from:to:cc:subject:message-id:references:
	mime-version:in-reply-to;
	bh=Mc25fUq8gdckxpk3CIAogWTIzT0gGcsH8KefzlCUf14=;
	b=EYTGX9+PzDlzmDLFYzvUHNmCWr8mVMKKCcHh8Gez/39vrlaUscz4qhau
	hSELDj/QSasvoYFIFDLQ0tk6rRd3Nw==;
X-IronPort-AV: E=Sophos;i="4.80,363,1344211200"; d="scan'208";a="434051480"
Received: from smtp-in-9002.sea19.amazon.com ([10.186.174.20])
	by smtp-border-fw-out-2101.iad2.amazon.com with
	ESMTP/TLS/DHE-RSA-AES256-SHA; 04 Sep 2012 02:13:09 +0000
Received: from ex10-hub-31005.ant.amazon.com (ex10-hub-31005.sea31.amazon.com
	[10.185.176.12])
	by smtp-in-9002.sea19.amazon.com (8.13.8/8.13.8) with ESMTP id
	q842D8Th017086
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL);
	Tue, 4 Sep 2012 02:13:08 GMT
Received: from u002268147cd4502c336d.ant.amazon.com (10.224.80.38) by
	ex10-hub-31005.ant.amazon.com (10.185.176.12) with Microsoft SMTP
	Server id 14.2.247.3; Mon, 3 Sep 2012 19:13:05 -0700
Received: by u002268147cd4502c336d.ant.amazon.com (sSMTP sendmail emulation); 
	Mon, 03 Sep 2012 19:13:02 -0700
Date: Mon, 3 Sep 2012 19:13:02 -0700
From: Matt Wilson <msw@amazon.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120904021259.GB7356@u002268147cd4502c336d.ant.amazon.com>
References: <patchbomb.1346353198@u002268147cd4502c336d.ant.amazon.com>
	<512b4e0c49f331e252ae.1346353199@u002268147cd4502c336d.ant.amazon.com>
	<1346405131.27277.131.camel@zakaz.uk.xensource.com>
	<1346416200.27277.203.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1346416200.27277.203.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 1 of 2 v2] tools: check for documentation
 generation tools at configure 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 Fri, Aug 31, 2012 at 01:30:00PM +0100, Ian Campbell wrote:
> On Fri, 2012-08-31 at 10:25 +0100, Ian Campbell wrote:
> > > +AC_DEFUN([AX_DOCS_TOOL_PROGS], [
> > > +dnl
> > > +    AC_ARG_VAR([$1], [Path to $2 tool])
> > 
> > Does this do something sensible when $2 is a space separated list?
> 
> Not especially:
> $ ./configure --help| grep mark
>    MARKDOWN    Path to markdown markdown_py tool

I'll fix that up.

Matt

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

From xen-devel-bounces@lists.xen.org Tue Sep 04 06:35:24 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Sep 2012 06:35:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T8mio-0000fv-LW; Tue, 04 Sep 2012 06:34:50 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1T8min-0000fq-GQ
	for xen-devel@lists.xen.org; Tue, 04 Sep 2012 06:34:49 +0000
Received: from [85.158.143.35:26667] by server-1.bemta-4.messagelabs.com id
	CB/AF-12504-801A5405; Tue, 04 Sep 2012 06:34:48 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1346740488!5480398!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM4MjY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29635 invoked from network); 4 Sep 2012 06:34:48 -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;
	4 Sep 2012 06:34:48 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 04 Sep 2012 07:34:47 +0100
Message-Id: <5045BD5C02000078000985A7@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 04 Sep 2012 07:35:40 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Sander Eikelenboom" <linux@eikelenboom.it>,
	"George Dunlap" <George.Dunlap@eu.citrix.com>,
	"Keir Fraser" <keir.xen@gmail.com>
References: <647712821.20120831234512@eikelenboom.it>
	<CC68CC67.3D984%keir.xen@gmail.com>
In-Reply-To: <CC68CC67.3D984%keir.xen@gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: wei.wang2@amd.com, Santosh Jodh <santosh.jodh@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Using debug-key 'o:  Dump IOMMU p2m table,
 locks up machine
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 02.09.12 at 09:42, Keir Fraser <keir.xen@gmail.com> wrote:
> On 31/08/2012 22:45, "Sander Eikelenboom" <linux@eikelenboom.it> wrote:
>> - When using serial console: I get a infinite stream of "gfn:  mfn: " lines,
>> mean while on the normal console, S-ATA devices are starting to give errors.
> 
> In this case the handler must be running in tasklet context. Not sure why
> SATA interrupts would be affected as hardirq and softirq work will still be
> carried out during execution of the keyhandler (the handler voluntarily
> preempts itself for softirq work).
> 
> Would need more investigation. :)

Isn't that because tasklets (i.e. idle vCPU-s with tasklets active)
get preferred in the schedulers? Some compensation might be
needed for the penalized vCPU, at least if that one is pinned
(not sure whether load balancing would be able to steal the
head of the run queue from a remote CPU). Sander - are you
by chance pinning Dom0 vCPU-s? And how many of them does
your Dom0 have?

Jan


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

From xen-devel-bounces@lists.xen.org Tue Sep 04 06:35:24 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Sep 2012 06:35:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T8mio-0000fv-LW; Tue, 04 Sep 2012 06:34:50 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1T8min-0000fq-GQ
	for xen-devel@lists.xen.org; Tue, 04 Sep 2012 06:34:49 +0000
Received: from [85.158.143.35:26667] by server-1.bemta-4.messagelabs.com id
	CB/AF-12504-801A5405; Tue, 04 Sep 2012 06:34:48 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1346740488!5480398!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM4MjY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29635 invoked from network); 4 Sep 2012 06:34:48 -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;
	4 Sep 2012 06:34:48 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 04 Sep 2012 07:34:47 +0100
Message-Id: <5045BD5C02000078000985A7@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 04 Sep 2012 07:35:40 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Sander Eikelenboom" <linux@eikelenboom.it>,
	"George Dunlap" <George.Dunlap@eu.citrix.com>,
	"Keir Fraser" <keir.xen@gmail.com>
References: <647712821.20120831234512@eikelenboom.it>
	<CC68CC67.3D984%keir.xen@gmail.com>
In-Reply-To: <CC68CC67.3D984%keir.xen@gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: wei.wang2@amd.com, Santosh Jodh <santosh.jodh@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Using debug-key 'o:  Dump IOMMU p2m table,
 locks up machine
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 02.09.12 at 09:42, Keir Fraser <keir.xen@gmail.com> wrote:
> On 31/08/2012 22:45, "Sander Eikelenboom" <linux@eikelenboom.it> wrote:
>> - When using serial console: I get a infinite stream of "gfn:  mfn: " lines,
>> mean while on the normal console, S-ATA devices are starting to give errors.
> 
> In this case the handler must be running in tasklet context. Not sure why
> SATA interrupts would be affected as hardirq and softirq work will still be
> carried out during execution of the keyhandler (the handler voluntarily
> preempts itself for softirq work).
> 
> Would need more investigation. :)

Isn't that because tasklets (i.e. idle vCPU-s with tasklets active)
get preferred in the schedulers? Some compensation might be
needed for the penalized vCPU, at least if that one is pinned
(not sure whether load balancing would be able to steal the
head of the run queue from a remote CPU). Sander - are you
by chance pinning Dom0 vCPU-s? And how many of them does
your Dom0 have?

Jan


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

From xen-devel-bounces@lists.xen.org Tue Sep 04 06:53:16 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Sep 2012 06: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 1T8n0A-0000qD-CX; Tue, 04 Sep 2012 06:52:46 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <linux@eikelenboom.it>) id 1T8n09-0000q8-2z
	for xen-devel@lists.xen.org; Tue, 04 Sep 2012 06:52:45 +0000
Received: from [85.158.138.51:42317] by server-3.bemta-3.messagelabs.com id
	FC/D3-21322-C35A5405; Tue, 04 Sep 2012 06:52:44 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-16.tower-174.messagelabs.com!1346741563!28359568!1
X-Originating-IP: [188.40.164.121]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16490 invoked from network); 4 Sep 2012 06:52:43 -0000
Received: from static.121.164.40.188.clients.your-server.de (HELO
	smtp.eikelenboom.it) (188.40.164.121)
	by server-16.tower-174.messagelabs.com with AES256-SHA encrypted SMTP;
	4 Sep 2012 06:52:43 -0000
Received: from 26-69-ftth.onsneteindhoven.nl ([88.159.69.26]:49204
	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 1T8mx1-0001w7-PM; Tue, 04 Sep 2012 08:49:31 +0200
Date: Tue, 4 Sep 2012 08:52:38 +0200
From: Sander Eikelenboom <linux@eikelenboom.it>
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <1576173912.20120904085238@eikelenboom.it>
To: "Jan Beulich" <JBeulich@suse.com>
In-Reply-To: <5045BD5C02000078000985A7@nat28.tlf.novell.com>
References: <647712821.20120831234512@eikelenboom.it>
	<CC68CC67.3D984%keir.xen@gmail.com>
	<5045BD5C02000078000985A7@nat28.tlf.novell.com>
MIME-Version: 1.0
Cc: George Dunlap <George.Dunlap@eu.citrix.com>, wei.wang2@amd.com,
	Keir Fraser <keir.xen@gmail.com>, Santosh Jodh <santosh.jodh@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Using debug-key 'o:  Dump IOMMU p2m table,
	locks up machine
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 Jan,

Tuesday, September 4, 2012, 8:35:40 AM, you wrote:

>>>> On 02.09.12 at 09:42, Keir Fraser <keir.xen@gmail.com> wrote:
>> On 31/08/2012 22:45, "Sander Eikelenboom" <linux@eikelenboom.it> wrote:
>>> - When using serial console: I get a infinite stream of "gfn:  mfn: " lines,
>>> mean while on the normal console, S-ATA devices are starting to give errors.
>> 
>> In this case the handler must be running in tasklet context. Not sure why
>> SATA interrupts would be affected as hardirq and softirq work will still be
>> carried out during execution of the keyhandler (the handler voluntarily
>> preempts itself for softirq work).
>> 
>> Would need more investigation. :)

> Isn't that because tasklets (i.e. idle vCPU-s with tasklets active)
> get preferred in the schedulers? Some compensation might be
> needed for the penalized vCPU, at least if that one is pinned
> (not sure whether load balancing would be able to steal the
> head of the run queue from a remote CPU). Sander - are you
> by chance pinning Dom0 vCPU-s? And how many of them does
> your Dom0 have?


Yes i do, could perhaps be the pinning of CPU0 ?

serveerstertje:~# xl vcpu-list
Name                                ID  VCPU   CPU State   Time(s) CPU Affinity
Domain-0                             0     0    0   r--    7711.7  0
Domain-0                             0     1    2   -b-    4048.1  2-5
Domain-0                             0     2    3   -b-    1129.1  2-5
Domain-0                             0     3    4   r--    1229.9  2-5
Domain-0                             0     4    5   -b-     885.5  2-5
Domain-0                             0     5    5   -b-    1192.5  2-5
database                             1     0    2   -b-    1063.6  2-5
database                             1     1    2   -b-     496.2  2-5
mail                                 2     0    5   -b-      42.3  2-5
samba                                3     0    4   -b-     178.4  2-5
webproxy                             4     0    2   -b-      49.9  2-5
www                                  5     0    4   -b-     104.1  2-5
davical                              6     0    2   -b-     119.6  2-5
backup                               7     0    5   -b-    1052.8  2-5
git                                  8     0    4   -b-      55.8  2-5
zabbix                               9     0    4   -b-     426.0  2-5
gallery3                            10     0    4   -b-      47.6  2-5
media                               11     0    2   -b-      40.9  2-5
torrentflux                         12     0    4   -b-      56.0  2-5
vpn                                 13     0    2   -b-     170.8  2-5
security                            14     0    2   -b-    2246.0  1-5
security                            14     1    4   -b-    1778.4  1-5
security                            14     2    1   -b-    1659.7  1-5
security                            14     3    5   -b-    1841.3  1-5
security                            14     4    3   -b-     981.1  1-5
creabox_hvm                         15     0    5   -b-     196.5  2-5
creabox_hvm                         15     1    4   -b-     255.8  2-5
creaexp                             16     0    2   -b-     297.8  2-5

serveerstertje:~# xl sched-credit
libxl: error: libxl.c:596:cpupool_info: failed to get info for cpupool1
: No such file or directory
Cpupool Pool-0: tslice=30ms ratelimit=1000us
Name                                ID Weight  Cap
Domain-0                             0   1024    0
database                             1    256    0
mail                                 2    256    0
samba                                3    256    0
webproxy                             4    256    0
www                                  5    256    0
davical                              6    256    0
backup                               7    256    0
git                                  8    256    0
zabbix                               9    256    0
gallery3                            10    256    0
media                               11    256    0
torrentflux                         12    256    0
vpn                                 13    256    0
security                            14    768    0
creabox_hvm                         15    256    0
creaexp                             16    256    0


> Jan





-- 
Best regards,
 Sander                            mailto:linux@eikelenboom.it


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

From xen-devel-bounces@lists.xen.org Tue Sep 04 06:53:16 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Sep 2012 06: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 1T8n0A-0000qD-CX; Tue, 04 Sep 2012 06:52:46 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <linux@eikelenboom.it>) id 1T8n09-0000q8-2z
	for xen-devel@lists.xen.org; Tue, 04 Sep 2012 06:52:45 +0000
Received: from [85.158.138.51:42317] by server-3.bemta-3.messagelabs.com id
	FC/D3-21322-C35A5405; Tue, 04 Sep 2012 06:52:44 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-16.tower-174.messagelabs.com!1346741563!28359568!1
X-Originating-IP: [188.40.164.121]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16490 invoked from network); 4 Sep 2012 06:52:43 -0000
Received: from static.121.164.40.188.clients.your-server.de (HELO
	smtp.eikelenboom.it) (188.40.164.121)
	by server-16.tower-174.messagelabs.com with AES256-SHA encrypted SMTP;
	4 Sep 2012 06:52:43 -0000
Received: from 26-69-ftth.onsneteindhoven.nl ([88.159.69.26]:49204
	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 1T8mx1-0001w7-PM; Tue, 04 Sep 2012 08:49:31 +0200
Date: Tue, 4 Sep 2012 08:52:38 +0200
From: Sander Eikelenboom <linux@eikelenboom.it>
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <1576173912.20120904085238@eikelenboom.it>
To: "Jan Beulich" <JBeulich@suse.com>
In-Reply-To: <5045BD5C02000078000985A7@nat28.tlf.novell.com>
References: <647712821.20120831234512@eikelenboom.it>
	<CC68CC67.3D984%keir.xen@gmail.com>
	<5045BD5C02000078000985A7@nat28.tlf.novell.com>
MIME-Version: 1.0
Cc: George Dunlap <George.Dunlap@eu.citrix.com>, wei.wang2@amd.com,
	Keir Fraser <keir.xen@gmail.com>, Santosh Jodh <santosh.jodh@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Using debug-key 'o:  Dump IOMMU p2m table,
	locks up machine
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 Jan,

Tuesday, September 4, 2012, 8:35:40 AM, you wrote:

>>>> On 02.09.12 at 09:42, Keir Fraser <keir.xen@gmail.com> wrote:
>> On 31/08/2012 22:45, "Sander Eikelenboom" <linux@eikelenboom.it> wrote:
>>> - When using serial console: I get a infinite stream of "gfn:  mfn: " lines,
>>> mean while on the normal console, S-ATA devices are starting to give errors.
>> 
>> In this case the handler must be running in tasklet context. Not sure why
>> SATA interrupts would be affected as hardirq and softirq work will still be
>> carried out during execution of the keyhandler (the handler voluntarily
>> preempts itself for softirq work).
>> 
>> Would need more investigation. :)

> Isn't that because tasklets (i.e. idle vCPU-s with tasklets active)
> get preferred in the schedulers? Some compensation might be
> needed for the penalized vCPU, at least if that one is pinned
> (not sure whether load balancing would be able to steal the
> head of the run queue from a remote CPU). Sander - are you
> by chance pinning Dom0 vCPU-s? And how many of them does
> your Dom0 have?


Yes i do, could perhaps be the pinning of CPU0 ?

serveerstertje:~# xl vcpu-list
Name                                ID  VCPU   CPU State   Time(s) CPU Affinity
Domain-0                             0     0    0   r--    7711.7  0
Domain-0                             0     1    2   -b-    4048.1  2-5
Domain-0                             0     2    3   -b-    1129.1  2-5
Domain-0                             0     3    4   r--    1229.9  2-5
Domain-0                             0     4    5   -b-     885.5  2-5
Domain-0                             0     5    5   -b-    1192.5  2-5
database                             1     0    2   -b-    1063.6  2-5
database                             1     1    2   -b-     496.2  2-5
mail                                 2     0    5   -b-      42.3  2-5
samba                                3     0    4   -b-     178.4  2-5
webproxy                             4     0    2   -b-      49.9  2-5
www                                  5     0    4   -b-     104.1  2-5
davical                              6     0    2   -b-     119.6  2-5
backup                               7     0    5   -b-    1052.8  2-5
git                                  8     0    4   -b-      55.8  2-5
zabbix                               9     0    4   -b-     426.0  2-5
gallery3                            10     0    4   -b-      47.6  2-5
media                               11     0    2   -b-      40.9  2-5
torrentflux                         12     0    4   -b-      56.0  2-5
vpn                                 13     0    2   -b-     170.8  2-5
security                            14     0    2   -b-    2246.0  1-5
security                            14     1    4   -b-    1778.4  1-5
security                            14     2    1   -b-    1659.7  1-5
security                            14     3    5   -b-    1841.3  1-5
security                            14     4    3   -b-     981.1  1-5
creabox_hvm                         15     0    5   -b-     196.5  2-5
creabox_hvm                         15     1    4   -b-     255.8  2-5
creaexp                             16     0    2   -b-     297.8  2-5

serveerstertje:~# xl sched-credit
libxl: error: libxl.c:596:cpupool_info: failed to get info for cpupool1
: No such file or directory
Cpupool Pool-0: tslice=30ms ratelimit=1000us
Name                                ID Weight  Cap
Domain-0                             0   1024    0
database                             1    256    0
mail                                 2    256    0
samba                                3    256    0
webproxy                             4    256    0
www                                  5    256    0
davical                              6    256    0
backup                               7    256    0
git                                  8    256    0
zabbix                               9    256    0
gallery3                            10    256    0
media                               11    256    0
torrentflux                         12    256    0
vpn                                 13    256    0
security                            14    768    0
creabox_hvm                         15    256    0
creaexp                             16    256    0


> Jan





-- 
Best regards,
 Sander                            mailto:linux@eikelenboom.it


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

From xen-devel-bounces@lists.xen.org Tue Sep 04 07:00:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Sep 2012 07:00: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 1T8n6z-0000zT-8t; Tue, 04 Sep 2012 06:59:49 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1T8n6x-0000zO-P6
	for xen-devel@lists.xen.org; Tue, 04 Sep 2012 06:59:47 +0000
Received: from [85.158.143.35:13915] by server-1.bemta-4.messagelabs.com id
	D5/CC-12504-2E6A5405; Tue, 04 Sep 2012 06:59:46 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1346741985!11381864!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-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4718 invoked from network); 4 Sep 2012 06:59:46 -0000
Received: from mail-ey0-f173.google.com (HELO mail-ey0-f173.google.com)
	(209.85.215.173)
	by server-11.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Sep 2012 06:59:46 -0000
Received: by eaac13 with SMTP id c13so1954112eaa.32
	for <xen-devel@lists.xen.org>; Mon, 03 Sep 2012 23:59:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=+dKocxMSLwymvf2YptnMx5FF4tHmPlfcOOodFO7BMUk=;
	b=jZGtponIaOY3uiMxbuAkKHVCad6FNi5FImNZcS+rVq9v07Qxvzar973nGFFoMUvVcB
	UN/Gvk/Xt4FZyFDFXVra5eJc+GYBwL7eHr1TRuc0/79M7XtriF3G5BzSjle1hHyZrina
	SS6i0h37VYrzGkEkIQPGW2LT1XxwoIUfuQqzE4q+DzOXTaY20RQ2bEYR9z/8KKkGpGrI
	AKozl9JdKlshZ4gJVNX623z8zxk5fJzIpdokd4rIfZa2NdFUQPgUQdHDpWmTrAjpMr3v
	uxiqs8J7tZhtz6GdRKClOhLymUCdoD5BRoCKirZdGYVrTiArm8AtNNhDD8pa9/r3wL2I
	ARSg==
Received: by 10.14.207.9 with SMTP id m9mr24718169eeo.5.1346741985825;
	Mon, 03 Sep 2012 23:59:45 -0700 (PDT)
Received: from [192.168.1.69] (host86-184-74-117.range86-184.btcentralplus.com.
	[86.184.74.117])
	by mx.google.com with ESMTPS id v3sm42636318eep.10.2012.09.03.23.59.42
	(version=SSLv3 cipher=OTHER); Mon, 03 Sep 2012 23:59:45 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Tue, 04 Sep 2012 07:59:36 +0100
From: Keir Fraser <keir.xen@gmail.com>
To: Jan Beulich <JBeulich@suse.com>, Sander Eikelenboom <linux@eikelenboom.it>,
	George Dunlap <George.Dunlap@eu.citrix.com>
Message-ID: <CC6B6568.3DAAD%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] Using debug-key 'o:  Dump IOMMU p2m table, locks up
	machine
Thread-Index: Ac2KatgUGFZFxbeHDkeffgybugnEcA==
In-Reply-To: <5045BD5C02000078000985A7@nat28.tlf.novell.com>
Mime-version: 1.0
Cc: wei.wang2@amd.com, Santosh Jodh <santosh.jodh@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Using debug-key 'o:  Dump IOMMU p2m table,
 locks up machine
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/09/2012 07:35, "Jan Beulich" <JBeulich@suse.com> wrote:

>>>> On 02.09.12 at 09:42, Keir Fraser <keir.xen@gmail.com> wrote:
>> On 31/08/2012 22:45, "Sander Eikelenboom" <linux@eikelenboom.it> wrote:
>>> - When using serial console: I get a infinite stream of "gfn:  mfn: " lines,
>>> mean while on the normal console, S-ATA devices are starting to give errors.
>> 
>> In this case the handler must be running in tasklet context. Not sure why
>> SATA interrupts would be affected as hardirq and softirq work will still be
>> carried out during execution of the keyhandler (the handler voluntarily
>> preempts itself for softirq work).
>> 
>> Would need more investigation. :)
> 
> Isn't that because tasklets (i.e. idle vCPU-s with tasklets active)
> get preferred in the schedulers? Some compensation might be
> needed for the penalized vCPU, at least if that one is pinned
> (not sure whether load balancing would be able to steal the
> head of the run queue from a remote CPU). Sander - are you
> by chance pinning Dom0 vCPU-s? And how many of them does
> your Dom0 have?

Jan, Yes you could be right, if Sander is pinning CPUs. Anyway, I wasn't
going to expend too much brain power on this situation. The case of spending
a few minutes in one key handler is not one I think is particularly sane.

 -- Keir

> Jan
> 



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

From xen-devel-bounces@lists.xen.org Tue Sep 04 07:00:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Sep 2012 07:00: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 1T8n6z-0000zT-8t; Tue, 04 Sep 2012 06:59:49 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1T8n6x-0000zO-P6
	for xen-devel@lists.xen.org; Tue, 04 Sep 2012 06:59:47 +0000
Received: from [85.158.143.35:13915] by server-1.bemta-4.messagelabs.com id
	D5/CC-12504-2E6A5405; Tue, 04 Sep 2012 06:59:46 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1346741985!11381864!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-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4718 invoked from network); 4 Sep 2012 06:59:46 -0000
Received: from mail-ey0-f173.google.com (HELO mail-ey0-f173.google.com)
	(209.85.215.173)
	by server-11.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Sep 2012 06:59:46 -0000
Received: by eaac13 with SMTP id c13so1954112eaa.32
	for <xen-devel@lists.xen.org>; Mon, 03 Sep 2012 23:59:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=+dKocxMSLwymvf2YptnMx5FF4tHmPlfcOOodFO7BMUk=;
	b=jZGtponIaOY3uiMxbuAkKHVCad6FNi5FImNZcS+rVq9v07Qxvzar973nGFFoMUvVcB
	UN/Gvk/Xt4FZyFDFXVra5eJc+GYBwL7eHr1TRuc0/79M7XtriF3G5BzSjle1hHyZrina
	SS6i0h37VYrzGkEkIQPGW2LT1XxwoIUfuQqzE4q+DzOXTaY20RQ2bEYR9z/8KKkGpGrI
	AKozl9JdKlshZ4gJVNX623z8zxk5fJzIpdokd4rIfZa2NdFUQPgUQdHDpWmTrAjpMr3v
	uxiqs8J7tZhtz6GdRKClOhLymUCdoD5BRoCKirZdGYVrTiArm8AtNNhDD8pa9/r3wL2I
	ARSg==
Received: by 10.14.207.9 with SMTP id m9mr24718169eeo.5.1346741985825;
	Mon, 03 Sep 2012 23:59:45 -0700 (PDT)
Received: from [192.168.1.69] (host86-184-74-117.range86-184.btcentralplus.com.
	[86.184.74.117])
	by mx.google.com with ESMTPS id v3sm42636318eep.10.2012.09.03.23.59.42
	(version=SSLv3 cipher=OTHER); Mon, 03 Sep 2012 23:59:45 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Tue, 04 Sep 2012 07:59:36 +0100
From: Keir Fraser <keir.xen@gmail.com>
To: Jan Beulich <JBeulich@suse.com>, Sander Eikelenboom <linux@eikelenboom.it>,
	George Dunlap <George.Dunlap@eu.citrix.com>
Message-ID: <CC6B6568.3DAAD%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] Using debug-key 'o:  Dump IOMMU p2m table, locks up
	machine
Thread-Index: Ac2KatgUGFZFxbeHDkeffgybugnEcA==
In-Reply-To: <5045BD5C02000078000985A7@nat28.tlf.novell.com>
Mime-version: 1.0
Cc: wei.wang2@amd.com, Santosh Jodh <santosh.jodh@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Using debug-key 'o:  Dump IOMMU p2m table,
 locks up machine
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/09/2012 07:35, "Jan Beulich" <JBeulich@suse.com> wrote:

>>>> On 02.09.12 at 09:42, Keir Fraser <keir.xen@gmail.com> wrote:
>> On 31/08/2012 22:45, "Sander Eikelenboom" <linux@eikelenboom.it> wrote:
>>> - When using serial console: I get a infinite stream of "gfn:  mfn: " lines,
>>> mean while on the normal console, S-ATA devices are starting to give errors.
>> 
>> In this case the handler must be running in tasklet context. Not sure why
>> SATA interrupts would be affected as hardirq and softirq work will still be
>> carried out during execution of the keyhandler (the handler voluntarily
>> preempts itself for softirq work).
>> 
>> Would need more investigation. :)
> 
> Isn't that because tasklets (i.e. idle vCPU-s with tasklets active)
> get preferred in the schedulers? Some compensation might be
> needed for the penalized vCPU, at least if that one is pinned
> (not sure whether load balancing would be able to steal the
> head of the run queue from a remote CPU). Sander - are you
> by chance pinning Dom0 vCPU-s? And how many of them does
> your Dom0 have?

Jan, Yes you could be right, if Sander is pinning CPUs. Anyway, I wasn't
going to expend too much brain power on this situation. The case of spending
a few minutes in one key handler is not one I think is particularly sane.

 -- Keir

> Jan
> 



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

From xen-devel-bounces@lists.xen.org Tue Sep 04 07:02:23 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Sep 2012 07:02: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 1T8n9A-0001G7-Mw; Tue, 04 Sep 2012 07:02:04 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1T8n98-0001Fz-LZ
	for xen-devel@lists.xen.org; Tue, 04 Sep 2012 07:02:02 +0000
Received: from [85.158.139.83:62087] by server-5.bemta-5.messagelabs.com id
	6E/05-30514-967A5405; Tue, 04 Sep 2012 07:02:01 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1346742121!25685685!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-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2100 invoked from network); 4 Sep 2012 07:02:01 -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;
	4 Sep 2012 07:02:01 -0000
Received: by eaac13 with SMTP id c13so1954977eaa.32
	for <xen-devel@lists.xen.org>; Tue, 04 Sep 2012 00:02:01 -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=oHvtHbLWPl7Dyx7z1l4Vx/Kbf4nkhTVV4Rqr9nI93eM=;
	b=d1wFG9qgKbmY6jt02GVhJUVtvg3Cl1L559u+uWMdMKvUtPhd5kzRKiISKrKI9U5wGN
	pgHTF6zBkT7Kq3w8N4EAaGk9utRrJ5TJhW6vrnetoRowd1ik7jJ942Hb4ANccxkuuLbY
	Znz8krUsbgbtsuhktId8GDnnZ4DWiJvA55sKJib2+7noQB5EMQZniKDBu2oEo8j1klT2
	YugVxrZPqRbJZ6HzjpgcRMduuF6Vu5uCMLopmU9k8TK9P58Ga2WvQHGxCmzhbiMn54ea
	dfbk6UqCQiYgDR44kPb3/ftj35G/AfQ6cAagtXfmFHtylcTh3ryYG6Q9Tf4BuvVhWBiO
	Vj5Q==
Received: by 10.14.211.3 with SMTP id v3mr24637561eeo.43.1346742121180;
	Tue, 04 Sep 2012 00:02:01 -0700 (PDT)
Received: from [192.168.1.69] (host86-184-74-117.range86-184.btcentralplus.com.
	[86.184.74.117])
	by mx.google.com with ESMTPS id v3sm42652597eep.10.2012.09.04.00.01.58
	(version=SSLv3 cipher=OTHER); Tue, 04 Sep 2012 00:02:00 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Tue, 04 Sep 2012 08:01:54 +0100
From: Keir Fraser <keir.xen@gmail.com>
To: Sander Eikelenboom <linux@eikelenboom.it>, Jan Beulich <JBeulich@suse.com>
Message-ID: <CC6B65F2.3DAAF%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] Using debug-key 'o:  Dump IOMMU p2m table, locks up
	machine
Thread-Index: Ac2KaypVHnBMx0Z6PkKEs6UxLRYpGw==
In-Reply-To: <1576173912.20120904085238@eikelenboom.it>
Mime-version: 1.0
Cc: George Dunlap <George.Dunlap@eu.citrix.com>, wei.wang2@amd.com,
	Santosh Jodh <santosh.jodh@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Using debug-key 'o:  Dump IOMMU p2m table,
 locks up machine
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/09/2012 07:52, "Sander Eikelenboom" <linux@eikelenboom.it> wrote:

>> Isn't that because tasklets (i.e. idle vCPU-s with tasklets active)
>> get preferred in the schedulers? Some compensation might be
>> needed for the penalized vCPU, at least if that one is pinned
>> (not sure whether load balancing would be able to steal the
>> head of the run queue from a remote CPU). Sander - are you
>> by chance pinning Dom0 vCPU-s? And how many of them does
>> your Dom0 have?
>
> Yes i do, could perhaps be the pinning of CPU0 ?

Yeah. :) Case closed?



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

From xen-devel-bounces@lists.xen.org Tue Sep 04 07:02:23 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Sep 2012 07:02: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 1T8n9A-0001G7-Mw; Tue, 04 Sep 2012 07:02:04 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1T8n98-0001Fz-LZ
	for xen-devel@lists.xen.org; Tue, 04 Sep 2012 07:02:02 +0000
Received: from [85.158.139.83:62087] by server-5.bemta-5.messagelabs.com id
	6E/05-30514-967A5405; Tue, 04 Sep 2012 07:02:01 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1346742121!25685685!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-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2100 invoked from network); 4 Sep 2012 07:02:01 -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;
	4 Sep 2012 07:02:01 -0000
Received: by eaac13 with SMTP id c13so1954977eaa.32
	for <xen-devel@lists.xen.org>; Tue, 04 Sep 2012 00:02:01 -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=oHvtHbLWPl7Dyx7z1l4Vx/Kbf4nkhTVV4Rqr9nI93eM=;
	b=d1wFG9qgKbmY6jt02GVhJUVtvg3Cl1L559u+uWMdMKvUtPhd5kzRKiISKrKI9U5wGN
	pgHTF6zBkT7Kq3w8N4EAaGk9utRrJ5TJhW6vrnetoRowd1ik7jJ942Hb4ANccxkuuLbY
	Znz8krUsbgbtsuhktId8GDnnZ4DWiJvA55sKJib2+7noQB5EMQZniKDBu2oEo8j1klT2
	YugVxrZPqRbJZ6HzjpgcRMduuF6Vu5uCMLopmU9k8TK9P58Ga2WvQHGxCmzhbiMn54ea
	dfbk6UqCQiYgDR44kPb3/ftj35G/AfQ6cAagtXfmFHtylcTh3ryYG6Q9Tf4BuvVhWBiO
	Vj5Q==
Received: by 10.14.211.3 with SMTP id v3mr24637561eeo.43.1346742121180;
	Tue, 04 Sep 2012 00:02:01 -0700 (PDT)
Received: from [192.168.1.69] (host86-184-74-117.range86-184.btcentralplus.com.
	[86.184.74.117])
	by mx.google.com with ESMTPS id v3sm42652597eep.10.2012.09.04.00.01.58
	(version=SSLv3 cipher=OTHER); Tue, 04 Sep 2012 00:02:00 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Tue, 04 Sep 2012 08:01:54 +0100
From: Keir Fraser <keir.xen@gmail.com>
To: Sander Eikelenboom <linux@eikelenboom.it>, Jan Beulich <JBeulich@suse.com>
Message-ID: <CC6B65F2.3DAAF%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] Using debug-key 'o:  Dump IOMMU p2m table, locks up
	machine
Thread-Index: Ac2KaypVHnBMx0Z6PkKEs6UxLRYpGw==
In-Reply-To: <1576173912.20120904085238@eikelenboom.it>
Mime-version: 1.0
Cc: George Dunlap <George.Dunlap@eu.citrix.com>, wei.wang2@amd.com,
	Santosh Jodh <santosh.jodh@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Using debug-key 'o:  Dump IOMMU p2m table,
 locks up machine
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/09/2012 07:52, "Sander Eikelenboom" <linux@eikelenboom.it> wrote:

>> Isn't that because tasklets (i.e. idle vCPU-s with tasklets active)
>> get preferred in the schedulers? Some compensation might be
>> needed for the penalized vCPU, at least if that one is pinned
>> (not sure whether load balancing would be able to steal the
>> head of the run queue from a remote CPU). Sander - are you
>> by chance pinning Dom0 vCPU-s? And how many of them does
>> your Dom0 have?
>
> Yes i do, could perhaps be the pinning of CPU0 ?

Yeah. :) Case closed?



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

From xen-devel-bounces@lists.xen.org Tue Sep 04 07:06:31 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Sep 2012 07: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 1T8nD7-0001Tt-Ia; Tue, 04 Sep 2012 07:06:09 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <lists+xen@internecto.net>) id 1T8nD6-0001Tk-5E
	for xen-devel@lists.xen.org; Tue, 04 Sep 2012 07:06:08 +0000
Received: from [85.158.143.35:47313] by server-2.bemta-4.messagelabs.com id
	7D/CB-21239-F58A5405; Tue, 04 Sep 2012 07:06:07 +0000
X-Env-Sender: lists+xen@internecto.net
X-Msg-Ref: server-2.tower-21.messagelabs.com!1346742364!5591237!1
X-Originating-IP: [176.9.245.29]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31505 invoked from network); 4 Sep 2012 07:06:04 -0000
Received: from polaris.internecto.net (HELO mx1.internecto.net) (176.9.245.29)
	by server-2.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 4 Sep 2012 07:06:04 -0000
Received: from localhost (localhost [127.0.0.1])
	by mx1.internecto.net (Postfix) with ESMTP id DA344A02EF;
	Tue,  4 Sep 2012 07:06:03 +0000 (UTC)
X-Virus-Scanned: Debian amavisd-new at mail.internecto.net
Received: from mx1.internecto.net ([127.0.0.1])
	by localhost (mail.polaris.internecto.net [127.0.0.1]) (amavisd-new,
	port 10024)
	with ESMTP id 8HVgjEBzbH5J; Tue,  4 Sep 2012 07:06:03 +0000 (UTC)
Received: from internecto.net (5ED4FDEB.cm-7-5d.dynamic.ziggo.nl
	[94.212.253.235])
	(using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits))
	(Client did not present a certificate)
	(Authenticated sender: lists@internecto.net)
	by mx1.internecto.net (Postfix) with ESMTPSA id 50549A0089;
	Tue,  4 Sep 2012 07:06:03 +0000 (UTC)
Date: Tue, 4 Sep 2012 09:06:01 +0200
From: Mark van Dijk <lists+xen@internecto.net>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120904090601.77377684@internecto.net>
In-Reply-To: <1346665360.25864.2.camel@zakaz.uk.xensource.com>
References: <1346665360.25864.2.camel@zakaz.uk.xensource.com>
Organization: Internecto SIS
X-Mailer: Claws Mail 3.8.0 (GTK+ 2.24.10; x86_64-pc-linux-gnu)
Mime-Version: 1.0
Cc: xen-users@lists.xen.org, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [Xen-users] Xen 4.2.0 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

Good morning, 

I realise I'm probably too late, but if it's trivial then maybe it is
possible to implement an 'xl reset vmname' function before the final
release.

Or is this not as trivial as I think it is?

-- 
Stay in touch,
Mark van Dijk.               ,---------------------------------
----------------------------'         Tue Sep 04 07:04 UTC 2012
Today is Boomtime, the 28th day of Bureaucracy in the YOLD 3178

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

From xen-devel-bounces@lists.xen.org Tue Sep 04 07:06:31 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Sep 2012 07: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 1T8nD7-0001Tt-Ia; Tue, 04 Sep 2012 07:06:09 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <lists+xen@internecto.net>) id 1T8nD6-0001Tk-5E
	for xen-devel@lists.xen.org; Tue, 04 Sep 2012 07:06:08 +0000
Received: from [85.158.143.35:47313] by server-2.bemta-4.messagelabs.com id
	7D/CB-21239-F58A5405; Tue, 04 Sep 2012 07:06:07 +0000
X-Env-Sender: lists+xen@internecto.net
X-Msg-Ref: server-2.tower-21.messagelabs.com!1346742364!5591237!1
X-Originating-IP: [176.9.245.29]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31505 invoked from network); 4 Sep 2012 07:06:04 -0000
Received: from polaris.internecto.net (HELO mx1.internecto.net) (176.9.245.29)
	by server-2.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 4 Sep 2012 07:06:04 -0000
Received: from localhost (localhost [127.0.0.1])
	by mx1.internecto.net (Postfix) with ESMTP id DA344A02EF;
	Tue,  4 Sep 2012 07:06:03 +0000 (UTC)
X-Virus-Scanned: Debian amavisd-new at mail.internecto.net
Received: from mx1.internecto.net ([127.0.0.1])
	by localhost (mail.polaris.internecto.net [127.0.0.1]) (amavisd-new,
	port 10024)
	with ESMTP id 8HVgjEBzbH5J; Tue,  4 Sep 2012 07:06:03 +0000 (UTC)
Received: from internecto.net (5ED4FDEB.cm-7-5d.dynamic.ziggo.nl
	[94.212.253.235])
	(using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits))
	(Client did not present a certificate)
	(Authenticated sender: lists@internecto.net)
	by mx1.internecto.net (Postfix) with ESMTPSA id 50549A0089;
	Tue,  4 Sep 2012 07:06:03 +0000 (UTC)
Date: Tue, 4 Sep 2012 09:06:01 +0200
From: Mark van Dijk <lists+xen@internecto.net>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120904090601.77377684@internecto.net>
In-Reply-To: <1346665360.25864.2.camel@zakaz.uk.xensource.com>
References: <1346665360.25864.2.camel@zakaz.uk.xensource.com>
Organization: Internecto SIS
X-Mailer: Claws Mail 3.8.0 (GTK+ 2.24.10; x86_64-pc-linux-gnu)
Mime-Version: 1.0
Cc: xen-users@lists.xen.org, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [Xen-users] Xen 4.2.0 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

Good morning, 

I realise I'm probably too late, but if it's trivial then maybe it is
possible to implement an 'xl reset vmname' function before the final
release.

Or is this not as trivial as I think it is?

-- 
Stay in touch,
Mark van Dijk.               ,---------------------------------
----------------------------'         Tue Sep 04 07:04 UTC 2012
Today is Boomtime, the 28th day of Bureaucracy in the YOLD 3178

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

From xen-devel-bounces@lists.xen.org Tue Sep 04 07:09:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Sep 2012 07:09:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T8nFk-0001j9-Qo; Tue, 04 Sep 2012 07:08:52 +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 1T8nFj-0001iw-77
	for xen-devel@lists.xen.org; Tue, 04 Sep 2012 07:08:51 +0000
Received: from [85.158.143.35:59501] by server-2.bemta-4.messagelabs.com id
	BC/9F-21239-209A5405; Tue, 04 Sep 2012 07:08:50 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-11.tower-21.messagelabs.com!1346742525!11383691!1
X-Originating-IP: [188.40.164.121]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11634 invoked from network); 4 Sep 2012 07:08:46 -0000
Received: from static.121.164.40.188.clients.your-server.de (HELO
	smtp.eikelenboom.it) (188.40.164.121)
	by server-11.tower-21.messagelabs.com with AES256-SHA encrypted SMTP;
	4 Sep 2012 07:08:46 -0000
Received: from 26-69-ftth.onsneteindhoven.nl ([88.159.69.26]:49230
	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 1T8nCY-00021c-QM; Tue, 04 Sep 2012 09:05:35 +0200
Date: Tue, 4 Sep 2012 09:08:41 +0200
From: Sander Eikelenboom <linux@eikelenboom.it>
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <4610648186.20120904090841@eikelenboom.it>
To: "Jan Beulich" <JBeulich@suse.com>
In-Reply-To: <5044849002000078000982EA@nat28.tlf.novell.com>
References: <7914B38A4445B34AA16EB9F1352942F1012F0F6F4B98@SJCPMAILBOX01.citrite.net>
	<CC681CDD.3D966%keir.xen@gmail.com>
	<40501859.20120902104331@eikelenboom.it>
	<5044849002000078000982EA@nat28.tlf.novell.com>
MIME-Version: 1.0
Content-Type: multipart/mixed;
 boundary="----------05A1A81AE2E0F0B49"
Cc: "wei.wang2@amd.com" <wei.wang2@amd.com>, Keir Fraser <keir.xen@gmail.com>,
	Santosh Jodh <Santosh.Jodh@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Using debug-key 'o:  Dump IOMMU p2m table,
	locks up machine
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

------------05A1A81AE2E0F0B49
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hello Jan,

Monday, September 3, 2012, 10:21:04 AM, you wrote:

>>>> On 02.09.12 at 10:43, Sander Eikelenboom <linux@eikelenboom.it> wrote:
>> I have attached new output from xl dmesg, this time with iommu=debug on (the 
>> option changed from 4.1 to 4.2).

> This one

>>(XEN) [2012-09-02 00:55:02] traps.c:3156: GPF (0060): ffff82c48015c9ee -> ffff82c480224b13

> also worries me. While Xen gracefully recovers from it, these
> messages still generally indicate a problem somewhere. Could
> you resolve the addresses to file:line tuples? And, assuming
> this happens in the context of doing something on behalf of
> the guest in the context of a guest vCPU, could you also
> check what guest side action triggers this (e.g. by adding a
> call to show_execution_state() alongside the printing of the
> message)?

Hope i have done it right:

diff -r a0b5f8102a00 xen/arch/x86/traps.c
--- a/xen/arch/x86/traps.c      Tue Aug 28 22:40:45 2012 +0100
+++ b/xen/arch/x86/traps.c      Tue Sep 04 08:53:54 2012 +0200
@@ -3154,6 +3154,11 @@
     {
         dprintk(XENLOG_INFO, "GPF (%04x): %p -> %p\n",
                 regs->error_code, _p(regs->eip), _p(fixup));
+        dprintk(XENLOG_INFO, " show_execution_state(regs): \n");
+       show_execution_state(regs);
+        dprintk(XENLOG_INFO, "  show_execution_state(guest_cpu_user_regs()): \n");
+       show_execution_state(guest_cpu_user_regs());
+
         regs->eip = fixup;
         return;
     }


Gives (complete dmesg attached:

(XEN) [2012-09-03 21:20:49] AMD-Vi: IO_PAGE_FAULT: domain = 14, device id = 0x0700, fault address = 0xa8ee82c0
(XEN) [2012-09-03 21:20:49] AMD-Vi: IO_PAGE_FAULT: domain = 14, device id = 0x0700, fault address = 0xa8ee8320
(XEN) [2012-09-04 03:00:34] traps.c:3156: GPF (0060): ffff82c48015c9ee -> ffff82c480224b73
(XEN) [2012-09-04 03:00:34] traps.c:3157:  show_execution_state(regs): 
(XEN) [2012-09-04 03:00:34] ----[ Xen-4.2.0-rc4-pre  x86_64  debug=y  Not tainted ]----
(XEN) [2012-09-04 03:00:34] CPU:    3
(XEN) [2012-09-04 03:00:34] RIP:    e008:[<ffff82c48015c9ee>] context_switch+0x394/0xeeb
(XEN) [2012-09-04 03:00:34] RFLAGS: 0000000000010246   CONTEXT: hypervisor
(XEN) [2012-09-04 03:00:34] rax: 0000000000000001   rbx: ffff8300a52da000   rcx: 0000000000000001
(XEN) [2012-09-04 03:00:34] rdx: 0000000000000063   rsi: 0000000000000001   rdi: 000000000000037e
(XEN) [2012-09-04 03:00:34] rbp: ffff83024d8a7e28   rsp: ffff83024d8a7d88   r8:  0000000000000006
(XEN) [2012-09-04 03:00:34] r9:  ffff83024d95ebb8   r10: 00000000deadbeef   r11: 0000000000000246
(XEN) [2012-09-04 03:00:34] r12: ffff8300afd11000   r13: 0000000000000003   r14: 0000000000000003
(XEN) [2012-09-04 03:00:34] r15: ffff83024d8aa048   cr0: 000000008005003b   cr4: 00000000000006f0
(XEN) [2012-09-04 03:00:34] cr3: 0000000068506000   cr2: ffffffffff600400
(XEN) [2012-09-04 03:00:34] ds: 0000   es: 0000   fs: 0000   gs: 0000   ss: e010   cs: e008
(XEN) [2012-09-04 03:00:34] Xen stack trace from rsp=ffff83024d8a7d88:
(XEN) [2012-09-04 03:00:34]    0000000000000029 0000000000000000 0000001e00000000 0000000000000000
(XEN) [2012-09-04 03:00:34]    ffff83024d8a7db8 ffff83024d8aa060 ffff83024d8a7e18 ffff82c4801805ae
(XEN) [2012-09-04 03:00:34]    0000000000012f22 00003fd9ab6d6ca6 0000000000000000 0000000000000000
(XEN) [2012-09-04 03:00:34]    0000000000000000 0000000000000000 ffff83024d8a7e28 ffff8300afd11000
(XEN) [2012-09-04 03:00:34]    ffff8300a52da000 000013ebba37e10c 0000000000000002 ffff83024d8aa048
(XEN) [2012-09-04 03:00:34]    ffff83024d8a7eb8 ffff82c480124a70 0000000000000000 ffff83024d8aa040
(XEN) [2012-09-04 03:00:34]    000000034d8a7e68 000013ebba37e10c ffff83024d8a7e88 ffff82c480189483
(XEN) [2012-09-04 03:00:34]    ffff8300a52da000 0000000001c9c380 ffff83024d8a7e00 ffff82c4801226ce
(XEN) [2012-09-04 03:00:34]    ffff83024d8a7ef8 ffff82c4802d8180 00000000ffffffff ffff82c4802d8000
(XEN) [2012-09-04 03:00:34]    ffff83024d8a7f18 ffffffffffffffff ffff83024d8a7ef8 ffff82c480125e31
(XEN) [2012-09-04 03:00:34]    0000000000000246 ffff8300afd11000 ffffffff81ece5d8 ffffffff81f420c0
(XEN) [2012-09-04 03:00:34]    0000000000000000 0000000000000000 ffff83024d8a7f08 ffff82c480125e68
(XEN) [2012-09-04 03:00:34]    00007cfdb27580c7 ffff82c480222ef6 0000000000000000 ffff8800030e14a0
(XEN) [2012-09-04 03:00:34]    0000000000000000 ffff88001a0800d8 ffff88001cd17bf0 ffff88001fc0b100
(XEN) [2012-09-04 03:00:34]    0000000000000202 0000000000000000 0000000000000001 0000000000000000
(XEN) [2012-09-04 03:00:34]    0000000000000000 ffffffff810011aa ffff88001e99e180 00000000deadbeef
(XEN) [2012-09-04 03:00:34]    00000000deadbeef 0000010000000000 ffffffff810011aa 000000000000e033
(XEN) [2012-09-04 03:00:34]    0000000000000202 ffff88001cd17bb8 000000000000e02b 000053fd0000beef
(XEN) [2012-09-04 03:00:34]    800000000000beef 740000000000beef 000000000018beef 000053fe00000003
(XEN) [2012-09-04 03:00:34]    ffff8300a52da000 0000003dcd5a8680 000000000018e0c9
(XEN) [2012-09-04 03:00:34] Xen call trace:
(XEN) [2012-09-04 03:00:34]    [<ffff82c48015c9ee>] context_switch+0x394/0xeeb
(XEN) [2012-09-04 03:00:34]    [<ffff82c480124a70>] schedule+0x666/0x675
(XEN) [2012-09-04 03:00:34]    [<ffff82c480125e31>] __do_softirq+0xa4/0xb5
(XEN) [2012-09-04 03:00:34]    [<ffff82c480125e68>] do_softirq+0x26/0x28
(XEN) [2012-09-04 03:00:34]    
(XEN) [2012-09-04 03:00:34] traps.c:3159:   show_execution_state(guest_cpu_user_regs()): 
(XEN) [2012-09-04 03:00:34] ----[ Xen-4.2.0-rc4-pre  x86_64  debug=y  Not tainted ]----
(XEN) [2012-09-04 03:00:34] CPU:    3
(XEN) [2012-09-04 03:00:34] RIP:    e033:[<ffffffff810011aa>]
(XEN) [2012-09-04 03:00:34] RFLAGS: 0000000000000202   EM: 1   CONTEXT: pv guest
(XEN) [2012-09-04 03:00:34] rax: 0000000000000000   rbx: ffff88001fc0b100   rcx: ffffffff810011aa
(XEN) [2012-09-04 03:00:34] rdx: ffff88001e99e180   rsi: 00000000deadbeef   rdi: 00000000deadbeef
(XEN) [2012-09-04 03:00:34] rbp: ffff88001cd17bf0   rsp: ffff88001cd17bb8   r8:  0000000000000000
(XEN) [2012-09-04 03:00:34] r9:  0000000000000001   r10: 0000000000000000   r11: 0000000000000202
(XEN) [2012-09-04 03:00:34] r12: ffff88001a0800d8   r13: 0000000000000000   r14: ffff8800030e14a0
(XEN) [2012-09-04 03:00:34] r15: 0000000000000000   cr0: 000000008005003b   cr4: 00000000000006f0
(XEN) [2012-09-04 03:00:34] cr3: 0000000068506000   cr2: 00000000f76e4000
(XEN) [2012-09-04 03:00:34] ds: 0000   es: 0000   fs: 0000   gs: 0000   ss: e02b   cs: e033
(XEN) [2012-09-04 03:00:34] Guest stack trace from rsp=ffff88001cd17bb8:
(XEN) [2012-09-04 03:00:34]    0000000000000000 0000000000000001 ffffffff81004942 ffff8800030e1040
(XEN) [2012-09-04 03:00:34]    ffff88001e99e180 0000000000000000 ffff8800030e14a0 ffff88001cd17c10
(XEN) [2012-09-04 03:00:34]    ffffffff81003941 ffff88001e99e180 ffff8800030e1040 ffff88001cd17c70
(XEN) [2012-09-04 03:00:34]    ffffffff8100b850 ffff8800030e1040 ffff88001d280080 0000000000000063
(XEN) [2012-09-04 03:00:34]    ffff88001fc10a80 ffff88001cd17c80 ffff88001fc12e80 0000000000000000
(XEN) [2012-09-04 03:00:34]    ffff88001d285b00 0000000000000000 0000000000000000 ffff8800030e1040
(XEN) [2012-09-04 03:00:34]    ffffffff817fa2f5 ffff88001cd17dd0 0000000000000216 ffffffff810700fe
(XEN) [2012-09-04 03:00:34]    ffff88001fc0e018 ffff8800030e1040 0000000000012e80 ffff88001cd17fd8
(XEN) [2012-09-04 03:00:34]    ffff88001cd16010 0000000000012e80 0000000000012e80 ffff88001cd17fd8
(XEN) [2012-09-04 03:00:34]    0000000000012e80 ffff88001e999040 ffff8800030e1040 ffff880000000000
(XEN) [2012-09-04 03:00:34]    ffff880000000000 ffff88001fc0e000 ffff88001cdb3300 ffff88001fc16e00
(XEN) [2012-09-04 03:00:34]    ffff88001fc0e000 ffff88001cd17d50 ffffffff817fb614 ffff88001d08c140
(XEN) [2012-09-04 03:00:34]    ffff88001cdb3300 ffff88001fc16e00 ffff88001fc0e000 ffff88001cd17de0
(XEN) [2012-09-04 03:00:34]    ffffffff8107f059 ffff8800030e1040 ffff8800030e1040 ffffffff817fbe7b
(XEN) [2012-09-04 03:00:34]    ffff88001fc0e448 ffff8800030e1040 ffff88001cdb3320 ffff88001cd17db0
(XEN) [2012-09-04 03:00:34]    ffffffff810acb78 ffff88001fc0e000 ffff88001cdb3300 ffff88001fc0e438
(XEN) [2012-09-04 03:00:34]    ffff88001fc0e448 ffff8800030e1040 ffff88001cdb3320 ffff88001cd17de0
(XEN) [2012-09-04 03:00:34]    ffffffff817fa814 ffff88001cd17eb0 ffffffff8107f6f9 0000000000000000
(XEN) [2012-09-04 03:00:34]    ffff88001cd17e50 ffff8800030e1040 ffff88001cd16010 ffff8800030e0240
(XEN) [2012-09-04 03:00:34]    ffff88001cd17e68 ffff8800030e1040 ffff8800030e1040 ffff8800030e1040
(XEN) [2012-09-04 03:15:12] grant_table.c:254:d0 Increased maptrack size to 2 frames


> Jan

------------05A1A81AE2E0F0B49
Content-Type: text/plain;
 name="xl-dmesg.txt"
Content-transfer-encoding: base64
Content-Disposition: attachment;
 filename="xl-dmesg.txt"

IF9fICBfXyAgICAgICAgICAgIF8gIF8gICAgX19fXyAgICBfX18gICAgICAgICAgICAgIF8g
IF8gICAgICAgICAgICAgICAgICAgICANCiBcIFwvIC9fX18gXyBfXyAgIHwgfHwgfCAgfF9f
XyBcICAvIF8gXCAgICBfIF9fIF9fX3wgfHwgfCAgICAgXyBfXyAgXyBfXyBfX18gDQogIFwg
IC8vIF8gXCAnXyBcICB8IHx8IHxfICAgX18pIHx8IHwgfCB8X198ICdfXy8gX198IHx8IHxf
IF9ffCAnXyBcfCAnX18vIF8gXA0KICAvICBcICBfXy8gfCB8IHwgfF9fICAgX3wgLyBfXy8g
fCB8X3wgfF9ffCB8IHwgKF9ffF9fICAgX3xfX3wgfF8pIHwgfCB8ICBfXy8NCiAvXy9cX1xf
X198X3wgfF98ICAgIHxffChfKV9fX19fKF8pX19fLyAgIHxffCAgXF9fX3wgIHxffCAgICB8
IC5fXy98X3wgIFxfX198DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgfF98ICAgICAgICAgICAgIA0KKFhFTikgWGVuIHZl
cnNpb24gNC4yLjAtcmM0LXByZSAocm9vdEBkeW5kbnMub3JnKSAoZ2NjIChEZWJpYW4gNC40
LjUtOCkgNC40LjUpIE1vbiBTZXAgIDMgMjI6MzY6MzAgQ0VTVCAyMDEyDQooWEVOKSBMYXRl
c3QgQ2hhbmdlU2V0OiBUdWUgQXVnIDI4IDIyOjQwOjQ1IDIwMTIgKzAxMDAgMjU3ODY6YTBi
NWY4MTAyYTAwDQooWEVOKSBCb290bG9hZGVyOiBHUlVCIDEuOTgrMjAxMDA4MDQtMTQrc3F1
ZWV6ZTENCihYRU4pIENvbW1hbmQgbGluZTogZG9tMF9tZW09MTAyNE0gbG9nbHZsPWFsbCBs
b2dsdmxfZ3Vlc3Q9YWxsIGNvbnNvbGVfdGltZXN0YW1wcyB2Z2E9Z2Z4LTEyODB4MTAyNHgz
MiBjcHVpZGxlIGNwdWZyZXE9eGVuIG5vcmVib290IGRlYnVnIGxhcGljPWRlYnVnIGFwaWNf
dmVyYm9zaXR5PWRlYnVnIGFwaWM9ZGVidWcgaW9tbXU9b24sdmVyYm9zZSxkZWJ1ZyBjb20x
PTM4NDAwLDhuMSBjb25zb2xlPXZnYSxjb20xDQooWEVOKSBWaWRlbyBpbmZvcm1hdGlvbjoN
CihYRU4pICBWR0EgaXMgZ3JhcGhpY3MgbW9kZSAxMjgweDEwMjQsIDMyIGJwcA0KKFhFTikg
IFZCRS9EREMgbWV0aG9kczogVjI7IEVESUQgdHJhbnNmZXIgdGltZTogMSBzZWNvbmRzDQoo
WEVOKSBEaXNjIGluZm9ybWF0aW9uOg0KKFhFTikgIEZvdW5kIDIgTUJSIHNpZ25hdHVyZXMN
CihYRU4pICBGb3VuZCAyIEVERCBpbmZvcm1hdGlvbiBzdHJ1Y3R1cmVzDQooWEVOKSBYZW4t
ZTgyMCBSQU0gbWFwOg0KKFhFTikgIDAwMDAwMDAwMDAwMDAwMDAgLSAwMDAwMDAwMDAwMDli
MDAwICh1c2FibGUpDQooWEVOKSAgMDAwMDAwMDAwMDA5YjAwMCAtIDAwMDAwMDAwMDAwYTAw
MDAgKHJlc2VydmVkKQ0KKFhFTikgIDAwMDAwMDAwMDAwZTQwMDAgLSAwMDAwMDAwMDAwMTAw
MDAwIChyZXNlcnZlZCkNCihYRU4pICAwMDAwMDAwMDAwMTAwMDAwIC0gMDAwMDAwMDBhZmU5
MDAwMCAodXNhYmxlKQ0KKFhFTikgIDAwMDAwMDAwYWZlOTAwMDAgLSAwMDAwMDAwMGFmZTll
MDAwIChBQ1BJIGRhdGEpDQooWEVOKSAgMDAwMDAwMDBhZmU5ZTAwMCAtIDAwMDAwMDAwYWZl
ZTAwMDAgKEFDUEkgTlZTKQ0KKFhFTikgIDAwMDAwMDAwYWZlZTAwMDAgLSAwMDAwMDAwMGFm
ZjAwMDAwIChyZXNlcnZlZCkNCihYRU4pICAwMDAwMDAwMGZmZTAwMDAwIC0gMDAwMDAwMDEw
MDAwMDAwMCAocmVzZXJ2ZWQpDQooWEVOKSAgMDAwMDAwMDEwMDAwMDAwMCAtIDAwMDAwMDAy
NTAwMDAwMDAgKHVzYWJsZSkNCihYRU4pIEFDUEk6IFJTRFAgMDAwRkIxMjAsIDAwMTQgKHIw
IEFDUElBTSkNCihYRU4pIEFDUEk6IFJTRFQgQUZFOTAwMDAsIDAwNDggKHIxIE1TSSAgICBP
RU1TTElDICAyMDEwMDYyMiBNU0ZUICAgICAgIDk3KQ0KKFhFTikgQUNQSTogRkFDUCBBRkU5
MDIwMCwgMDA4NCAocjEgNzY0ME1TIEE3NjQwMTAwIDIwMTAwNjIyIE1TRlQgICAgICAgOTcp
DQooWEVOKSBBQ1BJOiBEU0RUIEFGRTkwNUUwLCA5NDQ5IChyMSAgQTc2NDAgQTc2NDAxMDAg
ICAgICAxMDAgSU5UTCAyMDA1MTExNykNCihYRU4pIEFDUEk6IEZBQ1MgQUZFOUUwMDAsIDAw
NDANCihYRU4pIEFDUEk6IEFQSUMgQUZFOTAzOTAsIDAwODggKHIxIDc2NDBNUyBBNzY0MDEw
MCAyMDEwMDYyMiBNU0ZUICAgICAgIDk3KQ0KKFhFTikgQUNQSTogTUNGRyBBRkU5MDQyMCwg
MDAzQyAocjEgNzY0ME1TIE9FTU1DRkcgIDIwMTAwNjIyIE1TRlQgICAgICAgOTcpDQooWEVO
KSBBQ1BJOiBTTElDIEFGRTkwNDYwLCAwMTc2IChyMSBNU0kgICAgT0VNU0xJQyAgMjAxMDA2
MjIgTVNGVCAgICAgICA5NykNCihYRU4pIEFDUEk6IE9FTUIgQUZFOUUwNDAsIDAwNzIgKHIx
IDc2NDBNUyBBNzY0MDEwMCAyMDEwMDYyMiBNU0ZUICAgICAgIDk3KQ0KKFhFTikgQUNQSTog
U1JBVCBBRkU5QTVFMCwgMDEwOCAocjMgQU1EICAgIEZBTV9GXzEwICAgICAgICAyIEFNRCAg
ICAgICAgIDEpDQooWEVOKSBBQ1BJOiBIUEVUIEFGRTlBNkYwLCAwMDM4IChyMSA3NjQwTVMg
T0VNSFBFVCAgMjAxMDA2MjIgTVNGVCAgICAgICA5NykNCihYRU4pIEFDUEk6IElWUlMgQUZF
OUE3MzAsIDAwRjggKHIxICBBTUQgICAgIFJEODkwUyAgIDIwMjAzMSBBTUQgICAgICAgICAw
KQ0KKFhFTikgQUNQSTogU1NEVCBBRkU5QTgzMCwgMERBNCAocjEgQSBNIEkgIFBPV0VSTk9X
ICAgICAgICAxIEFNRCAgICAgICAgIDEpDQooWEVOKSBTeXN0ZW0gUkFNOiA4MTkwTUIgKDgz
ODY3MzJrQikNCihYRU4pIFNSQVQ6IFBYTSAwIC0+IEFQSUMgMCAtPiBOb2RlIDANCihYRU4p
IFNSQVQ6IFBYTSAwIC0+IEFQSUMgMSAtPiBOb2RlIDANCihYRU4pIFNSQVQ6IFBYTSAwIC0+
IEFQSUMgMiAtPiBOb2RlIDANCihYRU4pIFNSQVQ6IFBYTSAwIC0+IEFQSUMgMyAtPiBOb2Rl
IDANCihYRU4pIFNSQVQ6IFBYTSAwIC0+IEFQSUMgNCAtPiBOb2RlIDANCihYRU4pIFNSQVQ6
IFBYTSAwIC0+IEFQSUMgNSAtPiBOb2RlIDANCihYRU4pIFNSQVQ6IE5vZGUgMCBQWE0gMCAw
LWEwMDAwDQooWEVOKSBTUkFUOiBOb2RlIDAgUFhNIDAgMTAwMDAwLWIwMDAwMDAwDQooWEVO
KSBTUkFUOiBOb2RlIDAgUFhNIDAgMTAwMDAwMDAwLTI1MDAwMDAwMA0KKFhFTikgTlVNQTog
QWxsb2NhdGVkIG1lbW5vZGVtYXAgZnJvbSAyNGQ5YTQwMDAgLSAyNGQ5YTcwMDANCihYRU4p
IE5VTUE6IFVzaW5nIDggZm9yIHRoZSBoYXNoIHNoaWZ0Lg0KKFhFTikgRG9tYWluIGhlYXAg
aW5pdGlhbGlzZWQNCihYRU4pIHZlc2FmYjogZnJhbWVidWZmZXIgYXQgMHhmYjAwMDAwMCwg
bWFwcGVkIHRvIDB4ZmZmZjgyYzAwMDAwMDAwMCwgdXNpbmcgNjE0NGssIHRvdGFsIDE0MzM2
aw0KKFhFTikgdmVzYWZiOiBtb2RlIGlzIDEyODB4MTAyNHgzMiwgbGluZWxlbmd0aD01MTIw
LCBmb250IDh4MTYNCihYRU4pIHZlc2FmYjogVHJ1ZWNvbG9yOiBzaXplPTg6ODo4OjgsIHNo
aWZ0PTI0OjE2Ojg6MA0KKFhFTikgZm91bmQgU01QIE1QLXRhYmxlIGF0IDAwMGZmNzgwDQoo
WEVOKSBETUkgcHJlc2VudC4NCihYRU4pIEFQSUMgYm9vdCBzdGF0ZSBpcyAneGFwaWMnDQoo
WEVOKSBVc2luZyBBUElDIGRyaXZlciBkZWZhdWx0DQooWEVOKSBBQ1BJOiBQTS1UaW1lciBJ
TyBQb3J0OiAweDgwOA0KKFhFTikgQUNQSTogQUNQSSBTTEVFUCBJTkZPOiBwbTF4X2NudFs4
MDQsMF0sIHBtMXhfZXZ0WzgwMCwwXQ0KKFhFTikgQUNQSTogICAgICAgICAgICAgICAgICB3
YWtldXBfdmVjW2FmZTllMDBjXSwgdmVjX3NpemVbMjBdDQooWEVOKSBBQ1BJOiBMb2NhbCBB
UElDIGFkZHJlc3MgMHhmZWUwMDAwMA0KKFhFTikgQUNQSTogTEFQSUMgKGFjcGlfaWRbMHgw
MV0gbGFwaWNfaWRbMHgwMF0gZW5hYmxlZCkNCihYRU4pIFByb2Nlc3NvciAjMCAwOjEwIEFQ
SUMgdmVyc2lvbiAxNg0KKFhFTikgQUNQSTogTEFQSUMgKGFjcGlfaWRbMHgwMl0gbGFwaWNf
aWRbMHgwMV0gZW5hYmxlZCkNCihYRU4pIFByb2Nlc3NvciAjMSAwOjEwIEFQSUMgdmVyc2lv
biAxNg0KKFhFTikgQUNQSTogTEFQSUMgKGFjcGlfaWRbMHgwM10gbGFwaWNfaWRbMHgwMl0g
ZW5hYmxlZCkNCihYRU4pIFByb2Nlc3NvciAjMiAwOjEwIEFQSUMgdmVyc2lvbiAxNg0KKFhF
TikgQUNQSTogTEFQSUMgKGFjcGlfaWRbMHgwNF0gbGFwaWNfaWRbMHgwM10gZW5hYmxlZCkN
CihYRU4pIFByb2Nlc3NvciAjMyAwOjEwIEFQSUMgdmVyc2lvbiAxNg0KKFhFTikgQUNQSTog
TEFQSUMgKGFjcGlfaWRbMHgwNV0gbGFwaWNfaWRbMHgwNF0gZW5hYmxlZCkNCihYRU4pIFBy
b2Nlc3NvciAjNCAwOjEwIEFQSUMgdmVyc2lvbiAxNg0KKFhFTikgQUNQSTogTEFQSUMgKGFj
cGlfaWRbMHgwNl0gbGFwaWNfaWRbMHgwNV0gZW5hYmxlZCkNCihYRU4pIFByb2Nlc3NvciAj
NSAwOjEwIEFQSUMgdmVyc2lvbiAxNg0KKFhFTikgQUNQSTogSU9BUElDIChpZFsweDA2XSBh
ZGRyZXNzWzB4ZmVjMDAwMDBdIGdzaV9iYXNlWzBdKQ0KKFhFTikgSU9BUElDWzBdOiBhcGlj
X2lkIDYsIHZlcnNpb24gMzMsIGFkZHJlc3MgMHhmZWMwMDAwMCwgR1NJIDAtMjMNCihYRU4p
IEFDUEk6IElPQVBJQyAoaWRbMHgwN10gYWRkcmVzc1sweGZlYzIwMDAwXSBnc2lfYmFzZVsy
NF0pDQooWEVOKSBJT0FQSUNbMV06IGFwaWNfaWQgNywgdmVyc2lvbiAzMywgYWRkcmVzcyAw
eGZlYzIwMDAwLCBHU0kgMjQtNTUNCihYRU4pIEFDUEk6IElOVF9TUkNfT1ZSIChidXMgMCBi
dXNfaXJxIDAgZ2xvYmFsX2lycSAyIGRmbCBkZmwpDQooWEVOKSBBQ1BJOiBJTlRfU1JDX09W
UiAoYnVzIDAgYnVzX2lycSA5IGdsb2JhbF9pcnEgOSBsb3cgbGV2ZWwpDQooWEVOKSBBQ1BJ
OiBJUlEwIHVzZWQgYnkgb3ZlcnJpZGUuDQooWEVOKSBBQ1BJOiBJUlEyIHVzZWQgYnkgb3Zl
cnJpZGUuDQooWEVOKSBBQ1BJOiBJUlE5IHVzZWQgYnkgb3ZlcnJpZGUuDQooWEVOKSBFbmFi
bGluZyBBUElDIG1vZGU6ICBGbGF0LiAgVXNpbmcgMiBJL08gQVBJQ3MNCihYRU4pIEFDUEk6
IEhQRVQgaWQ6IDB4ODMwMCBiYXNlOiAweGZlZDAwMDAwDQooWEVOKSBUYWJsZSBpcyBub3Qg
Zm91bmQhDQooWEVOKSBVc2luZyBBQ1BJIChNQURUKSBmb3IgU01QIGNvbmZpZ3VyYXRpb24g
aW5mb3JtYXRpb24NCihYRU4pIFNNUDogQWxsb3dpbmcgNiBDUFVzICgwIGhvdHBsdWcgQ1BV
cykNCihYRU4pIG1hcHBlZCBBUElDIHRvIGZmZmY4MmMzZmZkZmUwMDAgKGZlZTAwMDAwKQ0K
KFhFTikgbWFwcGVkIElPQVBJQyB0byBmZmZmODJjM2ZmZGZkMDAwIChmZWMwMDAwMCkNCihY
RU4pIG1hcHBlZCBJT0FQSUMgdG8gZmZmZjgyYzNmZmRmYzAwMCAoZmVjMjAwMDApDQooWEVO
KSBJUlEgbGltaXRzOiA1NiBHU0ksIDExMTIgTVNJL01TSS1YDQooWEVOKSBVc2luZyBzY2hl
ZHVsZXI6IFNNUCBDcmVkaXQgU2NoZWR1bGVyIChjcmVkaXQpDQooWEVOKSBEZXRlY3RlZCAz
MjAwLjE5OSBNSHogcHJvY2Vzc29yLg0KKFhFTikgSW5pdGluZyBtZW1vcnkgc2hhcmluZy4N
CihYRU4pIEFNRCBGYW0xMGggbWFjaGluZSBjaGVjayByZXBvcnRpbmcgZW5hYmxlZA0KKFhF
TikgUENJOiBNQ0ZHIGNvbmZpZ3VyYXRpb24gMDogYmFzZSBlMDAwMDAwMCBzZWdtZW50IDAw
MDAgYnVzZXMgMDAgLSBmZg0KKFhFTikgUENJOiBOb3QgdXNpbmcgTUNGRyBmb3Igc2VnbWVu
dCAwMDAwIGJ1cyAwMC1mZg0KKFhFTikgQU1ELVZpOiBGb3VuZCBNU0kgY2FwYWJpbGl0eSBi
bG9jayBhdCAweDU0DQooWEVOKSBBTUQtVmk6IEFDUEkgVGFibGU6DQooWEVOKSBBTUQtVmk6
ICBTaWduYXR1cmUgSVZSUw0KKFhFTikgQU1ELVZpOiAgTGVuZ3RoIDB4ZjgNCihYRU4pIEFN
RC1WaTogIFJldmlzaW9uIDB4MQ0KKFhFTikgQU1ELVZpOiAgQ2hlY2tTdW0gMHg2ZQ0KKFhF
TikgQU1ELVZpOiAgT0VNX0lkIEFNRCAgDQooWEVOKSBBTUQtVmk6ICBPRU1fVGFibGVfSWQg
UkQ4OTBTDQooWEVOKSBBTUQtVmk6ICBPRU1fUmV2aXNpb24gMHgyMDIwMzENCihYRU4pIEFN
RC1WaTogIENyZWF0b3JfSWQgQU1EIA0KKFhFTikgQU1ELVZpOiAgQ3JlYXRvcl9SZXZpc2lv
biAweDANCihYRU4pIEFNRC1WaTogSVZSUyBCbG9jazoNCihYRU4pIEFNRC1WaTogIFR5cGUg
MHgxMA0KKFhFTikgQU1ELVZpOiAgRmxhZ3MgMHgzZQ0KKFhFTikgQU1ELVZpOiAgTGVuZ3Ro
IDB4YzgNCihYRU4pIEFNRC1WaTogIERldl9JZCAweDINCihYRU4pIEFNRC1WaTogSVZIRCBE
ZXZpY2UgRW50cnk6DQooWEVOKSBBTUQtVmk6ICBUeXBlIDB4Mw0KKFhFTikgQU1ELVZpOiAg
RGV2X0lkIDB4MA0KKFhFTikgQU1ELVZpOiAgRmxhZ3MgMHgwDQooWEVOKSBBTUQtVmk6ICBE
ZXZfSWQgUmFuZ2U6IDB4MCAtPiAweDINCihYRU4pIEFNRC1WaTogSVZIRCBEZXZpY2UgRW50
cnk6DQooWEVOKSBBTUQtVmk6ICBUeXBlIDB4Mg0KKFhFTikgQU1ELVZpOiAgRGV2X0lkIDB4
MTANCihYRU4pIEFNRC1WaTogIEZsYWdzIDB4MA0KKFhFTikgQU1ELVZpOiBJVkhEIERldmlj
ZSBFbnRyeToNCihYRU4pIEFNRC1WaTogIFR5cGUgMHgyDQooWEVOKSBBTUQtVmk6ICBEZXZf
SWQgMHhiMDANCihYRU4pIEFNRC1WaTogIEZsYWdzIDB4MA0KKFhFTikgQU1ELVZpOiBJVkhE
IERldmljZSBFbnRyeToNCihYRU4pIEFNRC1WaTogIFR5cGUgMHgyDQooWEVOKSBBTUQtVmk6
ICBEZXZfSWQgMHgxOA0KKFhFTikgQU1ELVZpOiAgRmxhZ3MgMHgwDQooWEVOKSBBTUQtVmk6
IElWSEQgRGV2aWNlIEVudHJ5Og0KKFhFTikgQU1ELVZpOiAgVHlwZSAweDMNCihYRU4pIEFN
RC1WaTogIERldl9JZCAweGEwMA0KKFhFTikgQU1ELVZpOiAgRmxhZ3MgMHgwDQooWEVOKSBB
TUQtVmk6ICBEZXZfSWQgUmFuZ2U6IDB4YTAwIC0+IDB4YTA3DQooWEVOKSBBTUQtVmk6IElW
SEQgRGV2aWNlIEVudHJ5Og0KKFhFTikgQU1ELVZpOiAgVHlwZSAweDINCihYRU4pIEFNRC1W
aTogIERldl9JZCAweDI4DQooWEVOKSBBTUQtVmk6ICBGbGFncyAweDANCihYRU4pIEFNRC1W
aTogSVZIRCBEZXZpY2UgRW50cnk6DQooWEVOKSBBTUQtVmk6ICBUeXBlIDB4Mg0KKFhFTikg
QU1ELVZpOiAgRGV2X0lkIDB4OTAwDQooWEVOKSBBTUQtVmk6ICBGbGFncyAweDANCihYRU4p
IEFNRC1WaTogSVZIRCBEZXZpY2UgRW50cnk6DQooWEVOKSBBTUQtVmk6ICBUeXBlIDB4Mg0K
KFhFTikgQU1ELVZpOiAgRGV2X0lkIDB4MzANCihYRU4pIEFNRC1WaTogIEZsYWdzIDB4MA0K
KFhFTikgQU1ELVZpOiBJVkhEIERldmljZSBFbnRyeToNCihYRU4pIEFNRC1WaTogIFR5cGUg
MHgyDQooWEVOKSBBTUQtVmk6ICBEZXZfSWQgMHg4MDANCihYRU4pIEFNRC1WaTogIEZsYWdz
IDB4MA0KKFhFTikgQU1ELVZpOiBJVkhEIERldmljZSBFbnRyeToNCihYRU4pIEFNRC1WaTog
IFR5cGUgMHgyDQooWEVOKSBBTUQtVmk6ICBEZXZfSWQgMHg1MA0KKFhFTikgQU1ELVZpOiAg
RmxhZ3MgMHgwDQooWEVOKSBBTUQtVmk6IElWSEQgRGV2aWNlIEVudHJ5Og0KKFhFTikgQU1E
LVZpOiAgVHlwZSAweDINCihYRU4pIEFNRC1WaTogIERldl9JZCAweDcwMA0KKFhFTikgQU1E
LVZpOiAgRmxhZ3MgMHgwDQooWEVOKSBBTUQtVmk6IElWSEQgRGV2aWNlIEVudHJ5Og0KKFhF
TikgQU1ELVZpOiAgVHlwZSAweDINCihYRU4pIEFNRC1WaTogIERldl9JZCAweDU4DQooWEVO
KSBBTUQtVmk6ICBGbGFncyAweDANCihYRU4pIEFNRC1WaTogSVZIRCBEZXZpY2UgRW50cnk6
DQooWEVOKSBBTUQtVmk6ICBUeXBlIDB4Mw0KKFhFTikgQU1ELVZpOiAgRGV2X0lkIDB4NjAw
DQooWEVOKSBBTUQtVmk6ICBGbGFncyAweDANCihYRU4pIEFNRC1WaTogIERldl9JZCBSYW5n
ZTogMHg2MDAgLT4gMHg2MDENCihYRU4pIEFNRC1WaTogSVZIRCBEZXZpY2UgRW50cnk6DQoo
WEVOKSBBTUQtVmk6ICBUeXBlIDB4Mg0KKFhFTikgQU1ELVZpOiAgRGV2X0lkIDB4NjANCihY
RU4pIEFNRC1WaTogIEZsYWdzIDB4MA0KKFhFTikgQU1ELVZpOiBJVkhEIERldmljZSBFbnRy
eToNCihYRU4pIEFNRC1WaTogIFR5cGUgMHgyDQooWEVOKSBBTUQtVmk6ICBEZXZfSWQgMHg1
MDANCihYRU4pIEFNRC1WaTogIEZsYWdzIDB4MA0KKFhFTikgQU1ELVZpOiBJVkhEIERldmlj
ZSBFbnRyeToNCihYRU4pIEFNRC1WaTogIFR5cGUgMHgyDQooWEVOKSBBTUQtVmk6ICBEZXZf
SWQgMHg2OA0KKFhFTikgQU1ELVZpOiAgRmxhZ3MgMHgwDQooWEVOKSBBTUQtVmk6IElWSEQg
RGV2aWNlIEVudHJ5Og0KKFhFTikgQU1ELVZpOiAgVHlwZSAweDMNCihYRU4pIEFNRC1WaTog
IERldl9JZCAweDQwMA0KKFhFTikgQU1ELVZpOiAgRmxhZ3MgMHgwDQooWEVOKSBBTUQtVmk6
ICBEZXZfSWQgUmFuZ2U6IDB4NDAwIC0+IDB4NDA3DQooWEVOKSBBTUQtVmk6IElWSEQgRGV2
aWNlIEVudHJ5Og0KKFhFTikgQU1ELVZpOiAgVHlwZSAweDINCihYRU4pIEFNRC1WaTogIERl
dl9JZCAweDg4DQooWEVOKSBBTUQtVmk6ICBGbGFncyAweDANCihYRU4pIEFNRC1WaTogSVZI
RCBEZXZpY2UgRW50cnk6DQooWEVOKSBBTUQtVmk6ICBUeXBlIDB4Mw0KKFhFTikgQU1ELVZp
OiAgRGV2X0lkIDB4OTANCihYRU4pIEFNRC1WaTogIEZsYWdzIDB4MA0KKFhFTikgQU1ELVZp
OiAgRGV2X0lkIFJhbmdlOiAweDkwIC0+IDB4OTINCihYRU4pIEFNRC1WaTogSVZIRCBEZXZp
Y2UgRW50cnk6DQooWEVOKSBBTUQtVmk6ICBUeXBlIDB4Mw0KKFhFTikgQU1ELVZpOiAgRGV2
X0lkIDB4OTgNCihYRU4pIEFNRC1WaTogIEZsYWdzIDB4MA0KKFhFTikgQU1ELVZpOiAgRGV2
X0lkIFJhbmdlOiAweDk4IC0+IDB4OWENCihYRU4pIEFNRC1WaTogSVZIRCBEZXZpY2UgRW50
cnk6DQooWEVOKSBBTUQtVmk6ICBUeXBlIDB4Mg0KKFhFTikgQU1ELVZpOiAgRGV2X0lkIDB4
YTANCihYRU4pIEFNRC1WaTogIEZsYWdzIDB4ZDcNCihYRU4pIEFNRC1WaTogSVZIRCBEZXZp
Y2UgRW50cnk6DQooWEVOKSBBTUQtVmk6ICBUeXBlIDB4Mg0KKFhFTikgQU1ELVZpOiAgRGV2
X0lkIDB4YTMNCihYRU4pIEFNRC1WaTogIEZsYWdzIDB4MA0KKFhFTikgQU1ELVZpOiBJVkhE
IERldmljZSBFbnRyeToNCihYRU4pIEFNRC1WaTogIFR5cGUgMHgyDQooWEVOKSBBTUQtVmk6
ICBEZXZfSWQgMHhhNA0KKFhFTikgQU1ELVZpOiAgRmxhZ3MgMHgwDQooWEVOKSBBTUQtVmk6
IElWSEQgRGV2aWNlIEVudHJ5Og0KKFhFTikgQU1ELVZpOiAgVHlwZSAweDANCihYRU4pIEFN
RC1WaTogIERldl9JZCAweDANCihYRU4pIEFNRC1WaTogIEZsYWdzIDB4MA0KKFhFTikgQU1E
LVZpOiBJVkhEIERldmljZSBFbnRyeToNCihYRU4pIEFNRC1WaTogIFR5cGUgMHg0Mw0KKFhF
TikgQU1ELVZpOiAgRGV2X0lkIDB4MzAwDQooWEVOKSBBTUQtVmk6ICBGbGFncyAweDANCihY
RU4pIEFNRC1WaTogIERldl9JZCBSYW5nZTogMHgzMDAgLT4gMHgzZmYNCihYRU4pIEFNRC1W
aTogIERldl9JZCBBbGlhczogMHhhNA0KKFhFTikgQU1ELVZpOiBJVkhEIERldmljZSBFbnRy
eToNCihYRU4pIEFNRC1WaTogIFR5cGUgMHgyDQooWEVOKSBBTUQtVmk6ICBEZXZfSWQgMHhh
NQ0KKFhFTikgQU1ELVZpOiAgRmxhZ3MgMHgwDQooWEVOKSBBTUQtVmk6IElWSEQgRGV2aWNl
IEVudHJ5Og0KKFhFTikgQU1ELVZpOiAgVHlwZSAweDINCihYRU4pIEFNRC1WaTogIERldl9J
ZCAweGE4DQooWEVOKSBBTUQtVmk6ICBGbGFncyAweDANCihYRU4pIEFNRC1WaTogSVZIRCBE
ZXZpY2UgRW50cnk6DQooWEVOKSBBTUQtVmk6ICBUeXBlIDB4Mg0KKFhFTikgQU1ELVZpOiAg
RGV2X0lkIDB4YTkNCihYRU4pIEFNRC1WaTogIEZsYWdzIDB4MA0KKFhFTikgQU1ELVZpOiBJ
VkhEIERldmljZSBFbnRyeToNCihYRU4pIEFNRC1WaTogIFR5cGUgMHgyDQooWEVOKSBBTUQt
Vmk6ICBEZXZfSWQgMHgxMDANCihYRU4pIEFNRC1WaTogIEZsYWdzIDB4MA0KKFhFTikgQU1E
LVZpOiBJVkhEIERldmljZSBFbnRyeToNCihYRU4pIEFNRC1WaTogIFR5cGUgMHgzDQooWEVO
KSBBTUQtVmk6ICBEZXZfSWQgMHhiMA0KKFhFTikgQU1ELVZpOiAgRmxhZ3MgMHgwDQooWEVO
KSBBTUQtVmk6ICBEZXZfSWQgUmFuZ2U6IDB4YjAgLT4gMHhiMg0KKFhFTikgQU1ELVZpOiBJ
VkhEIERldmljZSBFbnRyeToNCihYRU4pIEFNRC1WaTogIFR5cGUgMHgwDQooWEVOKSBBTUQt
Vmk6ICBEZXZfSWQgMHgwDQooWEVOKSBBTUQtVmk6ICBGbGFncyAweDANCihYRU4pIEFNRC1W
aTogSVZIRCBEZXZpY2UgRW50cnk6DQooWEVOKSBBTUQtVmk6ICBUeXBlIDB4NDgNCihYRU4p
IEFNRC1WaTogIERldl9JZCAweDANCihYRU4pIEFNRC1WaTogIEZsYWdzIDB4ZDcNCihYRU4p
IEFNRC1WaTogSVZIRCBEZXZpY2UgRW50cnk6DQooWEVOKSBBTUQtVmk6ICBUeXBlIDB4NDgN
CihYRU4pIEFNRC1WaTogIERldl9JZCAweDANCihYRU4pIEFNRC1WaTogIEZsYWdzIDB4MA0K
KFhFTikgQU1ELVZpOiBJT01NVSAwIEVuYWJsZWQuDQooWEVOKSBBTUQtVmk6IEVuYWJsaW5n
IGdsb2JhbCB2ZWN0b3IgbWFwDQooWEVOKSBJL08gdmlydHVhbGlzYXRpb24gZW5hYmxlZA0K
KFhFTikgIC0gRG9tMCBtb2RlOiBSZWxheGVkDQooWEVOKSBHZXR0aW5nIFZFUlNJT046IDgw
MDUwMDEwDQooWEVOKSBHZXR0aW5nIFZFUlNJT046IDgwMDUwMDEwDQooWEVOKSBHZXR0aW5n
IElEOiAwDQooWEVOKSBHZXR0aW5nIExWVDA6IDcwMA0KKFhFTikgR2V0dGluZyBMVlQxOiA0
MDANCihYRU4pIGVuYWJsZWQgRXh0SU5UIG9uIENQVSMwDQooWEVOKSBFU1IgdmFsdWUgYmVm
b3JlIGVuYWJsaW5nIHZlY3RvcjogMHgwMDAwMDAwNCAgYWZ0ZXI6IDB4MDAwMDAwMDANCihY
RU4pIEVOQUJMSU5HIElPLUFQSUMgSVJRcw0KKFhFTikgIC0+IFVzaW5nIG5ldyBBQ0sgbWV0
aG9kDQooWEVOKSBpbml0IElPX0FQSUMgSVJRcw0KKFhFTikgIElPLUFQSUMgKGFwaWNpZC1w
aW4pIDYtMCwgNi0xNiwgNi0xNywgNi0xOCwgNi0xOSwgNi0yMCwgNi0yMSwgNi0yMiwgNi0y
MywgNy0wLCA3LTEsIDctMiwgNy0zLCA3LTQsIDctNSwgNy02LCA3LTcsIDctOCwgNy05LCA3
LTEwLCA3LTExLCA3LTEyLCA3LTEzLCA3LTE0LCA3LTE1LCA3LTE2LCA3LTE3LCA3LTE4LCA3
LTE5LCA3LTIwLCA3LTIxLCA3LTIyLCA3LTIzLCA3LTI0LCA3LTI1LCA3LTI2LCA3LTI3LCA3
LTI4LCA3LTI5LCA3LTMwLCA3LTMxIG5vdCBjb25uZWN0ZWQuDQooWEVOKSAuLlRJTUVSOiB2
ZWN0b3I9MHhGMCBhcGljMT0wIHBpbjE9MiBhcGljMj0tMSBwaW4yPS0xDQooWEVOKSBudW1i
ZXIgb2YgTVAgSVJRIHNvdXJjZXM6IDE1Lg0KKFhFTikgbnVtYmVyIG9mIElPLUFQSUMgIzYg
cmVnaXN0ZXJzOiAyNC4NCihYRU4pIG51bWJlciBvZiBJTy1BUElDICM3IHJlZ2lzdGVyczog
MzIuDQooWEVOKSB0ZXN0aW5nIHRoZSBJTyBBUElDLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4N
CihYRU4pIElPIEFQSUMgIzYuLi4uLi4NCihYRU4pIC4uLi4gcmVnaXN0ZXIgIzAwOiAwNjAw
MDAwMA0KKFhFTikgLi4uLi4uLiAgICA6IHBoeXNpY2FsIEFQSUMgaWQ6IDA2DQooWEVOKSAu
Li4uLi4uICAgIDogRGVsaXZlcnkgVHlwZTogMA0KKFhFTikgLi4uLi4uLiAgICA6IExUUyAg
ICAgICAgICA6IDANCihYRU4pIC4uLi4gcmVnaXN0ZXIgIzAxOiAwMDE3ODAyMQ0KKFhFTikg
Li4uLi4uLiAgICAgOiBtYXggcmVkaXJlY3Rpb24gZW50cmllczogMDAxNw0KKFhFTikgLi4u
Li4uLiAgICAgOiBQUlEgaW1wbGVtZW50ZWQ6IDENCihYRU4pIC4uLi4uLi4gICAgIDogSU8g
QVBJQyB2ZXJzaW9uOiAwMDIxDQooWEVOKSAuLi4uIHJlZ2lzdGVyICMwMjogMDYwMDAwMDAN
CihYRU4pIC4uLi4uLi4gICAgIDogYXJiaXRyYXRpb246IDA2DQooWEVOKSAuLi4uIHJlZ2lz
dGVyICMwMzogMDcwMDAwMDANCihYRU4pIC4uLi4uLi4gICAgIDogQm9vdCBEVCAgICA6IDAN
CihYRU4pIC4uLi4gSVJRIHJlZGlyZWN0aW9uIHRhYmxlOg0KKFhFTikgIE5SIExvZyBQaHkg
TWFzayBUcmlnIElSUiBQb2wgU3RhdCBEZXN0IERlbGkgVmVjdDogICANCihYRU4pICAwMCAw
MDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwDQooWEVOKSAgMDEg
MDAxIDAxICAwICAgIDAgICAgMCAgIDAgICAwICAgIDEgICAgMSAgICAzMA0KKFhFTikgIDAy
IDAwMSAwMSAgMCAgICAwICAgIDAgICAwICAgMCAgICAxICAgIDEgICAgRjANCihYRU4pICAw
MyAwMDEgMDEgIDAgICAgMCAgICAwICAgMCAgIDAgICAgMSAgICAxICAgIDM4DQooWEVOKSAg
MDQgMDAxIDAxICAwICAgIDAgICAgMCAgIDAgICAwICAgIDEgICAgMSAgICBGMQ0KKFhFTikg
IDA1IDAwMSAwMSAgMCAgICAwICAgIDAgICAwICAgMCAgICAxICAgIDEgICAgNDANCihYRU4p
ICAwNiAwMDEgMDEgIDAgICAgMCAgICAwICAgMCAgIDAgICAgMSAgICAxICAgIDQ4DQooWEVO
KSAgMDcgMDAxIDAxICAwICAgIDAgICAgMCAgIDAgICAwICAgIDEgICAgMSAgICA1MA0KKFhF
TikgIDA4IDAwMSAwMSAgMCAgICAwICAgIDAgICAwICAgMCAgICAxICAgIDEgICAgNTgNCihY
RU4pICAwOSAwMDEgMDEgIDEgICAgMSAgICAwICAgMSAgIDAgICAgMSAgICAxICAgIDYwDQoo
WEVOKSAgMGEgMDAxIDAxICAwICAgIDAgICAgMCAgIDAgICAwICAgIDEgICAgMSAgICA2OA0K
KFhFTikgIDBiIDAwMSAwMSAgMCAgICAwICAgIDAgICAwICAgMCAgICAxICAgIDEgICAgNzAN
CihYRU4pICAwYyAwMDEgMDEgIDAgICAgMCAgICAwICAgMCAgIDAgICAgMSAgICAxICAgIDc4
DQooWEVOKSAgMGQgMDAxIDAxICAwICAgIDAgICAgMCAgIDAgICAwICAgIDEgICAgMSAgICA4
OA0KKFhFTikgIDBlIDAwMSAwMSAgMCAgICAwICAgIDAgICAwICAgMCAgICAxICAgIDEgICAg
OTANCihYRU4pICAwZiAwMDEgMDEgIDAgICAgMCAgICAwICAgMCAgIDAgICAgMSAgICAxICAg
IDk4DQooWEVOKSAgMTAgMDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAwICAgIDAgICAgMCAg
ICAwMA0KKFhFTikgIDExIDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDAg
ICAgMDANCihYRU4pICAxMiAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAw
ICAgIDAwDQooWEVOKSAgMTMgMDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAwICAgIDAgICAg
MCAgICAwMA0KKFhFTikgIDE0IDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAg
IDAgICAgMDANCihYRU4pICAxNSAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAg
ICAwICAgIDAwDQooWEVOKSAgMTYgMDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAwICAgIDAg
ICAgMCAgICAwMA0KKFhFTikgIDE3IDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAw
ICAgIDAgICAgMDANCihYRU4pIElPIEFQSUMgIzcuLi4uLi4NCihYRU4pIC4uLi4gcmVnaXN0
ZXIgIzAwOiAwNzAwMDAwMA0KKFhFTikgLi4uLi4uLiAgICA6IHBoeXNpY2FsIEFQSUMgaWQ6
IDA3DQooWEVOKSAuLi4uLi4uICAgIDogRGVsaXZlcnkgVHlwZTogMA0KKFhFTikgLi4uLi4u
LiAgICA6IExUUyAgICAgICAgICA6IDANCihYRU4pIC4uLi4gcmVnaXN0ZXIgIzAxOiAwMDFG
ODAyMQ0KKFhFTikgLi4uLi4uLiAgICAgOiBtYXggcmVkaXJlY3Rpb24gZW50cmllczogMDAx
Rg0KKFhFTikgLi4uLi4uLiAgICAgOiBQUlEgaW1wbGVtZW50ZWQ6IDENCihYRU4pIC4uLi4u
Li4gICAgIDogSU8gQVBJQyB2ZXJzaW9uOiAwMDIxDQooWEVOKSAuLi4uIHJlZ2lzdGVyICMw
MjogMDAwMDAwMDANCihYRU4pIC4uLi4uLi4gICAgIDogYXJiaXRyYXRpb246IDAwDQooWEVO
KSAuLi4uIElSUSByZWRpcmVjdGlvbiB0YWJsZToNCihYRU4pICBOUiBMb2cgUGh5IE1hc2sg
VHJpZyBJUlIgUG9sIFN0YXQgRGVzdCBEZWxpIFZlY3Q6ICAgDQooWEVOKSAgMDAgMDAwIDAw
ICAxICAgIDAgICAgMCAgIDAgICAwICAgIDAgICAgMCAgICAwMA0KKFhFTikgIDAxIDAwMCAw
MCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDAgICAgMDANCihYRU4pICAwMiAwMDAg
MDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwDQooWEVOKSAgMDMgMDAw
IDAwICAxICAgIDAgICAgMCAgIDAgICAwICAgIDAgICAgMCAgICAwMA0KKFhFTikgIDA0IDAw
MCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDAgICAgMDANCihYRU4pICAwNSAw
MDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwDQooWEVOKSAgMDYg
MDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAwICAgIDAgICAgMCAgICAwMA0KKFhFTikgIDA3
IDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDAgICAgMDANCihYRU4pICAw
OCAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwDQooWEVOKSAg
MDkgMDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAwICAgIDAgICAgMCAgICAwMA0KKFhFTikg
IDBhIDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDAgICAgMDANCihYRU4p
ICAwYiAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwDQooWEVO
KSAgMGMgMDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAwICAgIDAgICAgMCAgICAwMA0KKFhF
TikgIDBkIDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDAgICAgMDANCihY
RU4pICAwZSAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwDQoo
WEVOKSAgMGYgMDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAwICAgIDAgICAgMCAgICAwMA0K
KFhFTikgIDEwIDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDAgICAgMDAN
CihYRU4pICAxMSAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAw
DQooWEVOKSAgMTIgMDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAwICAgIDAgICAgMCAgICAw
MA0KKFhFTikgIDEzIDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDAgICAg
MDANCihYRU4pICAxNCAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAg
IDAwDQooWEVOKSAgMTUgMDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAwICAgIDAgICAgMCAg
ICAwMA0KKFhFTikgIDE2IDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDAg
ICAgMDANCihYRU4pICAxNyAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAw
ICAgIDAwDQooWEVOKSAgMTggMDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAwICAgIDAgICAg
MCAgICAwMA0KKFhFTikgIDE5IDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAg
IDAgICAgMDANCihYRU4pICAxYSAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAg
ICAwICAgIDAwDQooWEVOKSAgMWIgMDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAwICAgIDAg
ICAgMCAgICAwMA0KKFhFTikgIDFjIDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAw
ICAgIDAgICAgMDANCihYRU4pICAxZCAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAg
MCAgICAwICAgIDAwDQooWEVOKSAgMWUgMDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAwICAg
IDAgICAgMCAgICAwMA0KKFhFTikgIDFmIDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAg
ICAwICAgIDAgICAgMDANCihYRU4pIFVzaW5nIHZlY3Rvci1iYXNlZCBpbmRleGluZw0KKFhF
TikgSVJRIHRvIHBpbiBtYXBwaW5nczoNCihYRU4pIElSUTI0MCAtPiAwOjINCihYRU4pIElS
UTQ4IC0+IDA6MQ0KKFhFTikgSVJRNTYgLT4gMDozDQooWEVOKSBJUlEyNDEgLT4gMDo0DQoo
WEVOKSBJUlE2NCAtPiAwOjUNCihYRU4pIElSUTcyIC0+IDA6Ng0KKFhFTikgSVJRODAgLT4g
MDo3DQooWEVOKSBJUlE4OCAtPiAwOjgNCihYRU4pIElSUTk2IC0+IDA6OQ0KKFhFTikgSVJR
MTA0IC0+IDA6MTANCihYRU4pIElSUTExMiAtPiAwOjExDQooWEVOKSBJUlExMjAgLT4gMDox
Mg0KKFhFTikgSVJRMTM2IC0+IDA6MTMNCihYRU4pIElSUTE0NCAtPiAwOjE0DQooWEVOKSBJ
UlExNTIgLT4gMDoxNQ0KKFhFTikgLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u
Li4uIGRvbmUuDQooWEVOKSBVc2luZyBsb2NhbCBBUElDIHRpbWVyIGludGVycnVwdHMuDQoo
WEVOKSBjYWxpYnJhdGluZyBBUElDIHRpbWVyIC4uLg0KKFhFTikgLi4uLi4gQ1BVIGNsb2Nr
IHNwZWVkIGlzIDMyMDAuMTI3MCBNSHouDQooWEVOKSAuLi4uLiBob3N0IGJ1cyBjbG9jayBz
cGVlZCBpcyAyMDAuMDA3OSBNSHouDQooWEVOKSAuLi4uLiBidXNfc2NhbGUgPSAweDAwMDBD
Q0Q3DQooWEVOKSBbMjAxMi0wOS0wMyAyMDo1NTozMV0gUGxhdGZvcm0gdGltZXIgaXMgMTQu
MzE4TUh6IEhQRVQNCihYRU4pIFsyMDEyLTA5LTAzIDIwOjU1OjMxXSBBbGxvY2F0ZWQgY29u
c29sZSByaW5nIG9mIDY0IEtpQi4NCihYRU4pIFsyMDEyLTA5LTAzIDIwOjU1OjMxXSBIVk06
IEFTSURzIGVuYWJsZWQuDQooWEVOKSBbMjAxMi0wOS0wMyAyMDo1NTozMV0gU1ZNOiBTdXBw
b3J0ZWQgYWR2YW5jZWQgZmVhdHVyZXM6DQooWEVOKSBbMjAxMi0wOS0wMyAyMDo1NTozMV0g
IC0gTmVzdGVkIFBhZ2UgVGFibGVzIChOUFQpDQooWEVOKSBbMjAxMi0wOS0wMyAyMDo1NToz
MV0gIC0gTGFzdCBCcmFuY2ggUmVjb3JkIChMQlIpIFZpcnR1YWxpc2F0aW9uDQooWEVOKSBb
MjAxMi0wOS0wMyAyMDo1NTozMV0gIC0gTmV4dC1SSVAgU2F2ZWQgb24gI1ZNRVhJVA0KKFhF
TikgWzIwMTItMDktMDMgMjA6NTU6MzFdICAtIFBhdXNlLUludGVyY2VwdCBGaWx0ZXINCihY
RU4pIFsyMDEyLTA5LTAzIDIwOjU1OjMxXSBIVk06IFNWTSBlbmFibGVkDQooWEVOKSBbMjAx
Mi0wOS0wMyAyMDo1NTozMV0gSFZNOiBIYXJkd2FyZSBBc3Npc3RlZCBQYWdpbmcgKEhBUCkg
ZGV0ZWN0ZWQNCihYRU4pIFsyMDEyLTA5LTAzIDIwOjU1OjMxXSBIVk06IEhBUCBwYWdlIHNp
emVzOiA0a0IsIDJNQiwgMUdCDQooWEVOKSBbMjAxMi0wOS0wMyAyMDo1NTozMF0gbWFza2Vk
IEV4dElOVCBvbiBDUFUjMQ0KKFhFTikgWzIwMTItMDktMDMgMjA6NTU6MzFdIG1pY3JvY29k
ZTogY29sbGVjdF9jcHVfaW5mbzogcGF0Y2hfaWQ9MHgxMDAwMGJmDQooWEVOKSBbMjAxMi0w
OS0wMyAyMDo1NTozMF0gbWFza2VkIEV4dElOVCBvbiBDUFUjMg0KKFhFTikgWzIwMTItMDkt
MDMgMjA6NTU6MzFdIG1pY3JvY29kZTogY29sbGVjdF9jcHVfaW5mbzogcGF0Y2hfaWQ9MHgx
MDAwMGJmDQooWEVOKSBbMjAxMi0wOS0wMyAyMDo1NTozMF0gbWFza2VkIEV4dElOVCBvbiBD
UFUjMw0KKFhFTikgWzIwMTItMDktMDMgMjA6NTU6MzFdIG1pY3JvY29kZTogY29sbGVjdF9j
cHVfaW5mbzogcGF0Y2hfaWQ9MHgxMDAwMGJmDQooWEVOKSBbMjAxMi0wOS0wMyAyMDo1NToz
MF0gbWFza2VkIEV4dElOVCBvbiBDUFUjNA0KKFhFTikgWzIwMTItMDktMDMgMjA6NTU6MzFd
IG1pY3JvY29kZTogY29sbGVjdF9jcHVfaW5mbzogcGF0Y2hfaWQ9MHgxMDAwMGJmDQooWEVO
KSBbMjAxMi0wOS0wMyAyMDo1NTozMF0gbWFza2VkIEV4dElOVCBvbiBDUFUjNQ0KKFhFTikg
WzIwMTItMDktMDMgMjA6NTU6MzFdIEJyb3VnaHQgdXAgNiBDUFVzDQooWEVOKSBbMjAxMi0w
OS0wMyAyMDo1NTozMV0gbWljcm9jb2RlOiBjb2xsZWN0X2NwdV9pbmZvOiBwYXRjaF9pZD0w
eDEwMDAwYmYNCihYRU4pIFsyMDEyLTA5LTAzIDIwOjU1OjMxXSBIUEVUJ3MgTVNJIG1vZGUg
aGFzbid0IGJlZW4gc3VwcG9ydGVkIHdoZW4gSW50ZXJydXB0IFJlbWFwcGluZyBpcyBlbmFi
bGVkLg0KKFhFTikgWzIwMTItMDktMDMgMjA6NTU6MzFdIEFDUEkgc2xlZXAgbW9kZXM6IFMz
DQooWEVOKSBbMjAxMi0wOS0wMyAyMDo1NTozMV0gTUNBOiBVc2UgaHcgdGhyZXNob2xkaW5n
IHRvIGFkanVzdCBwb2xsaW5nIGZyZXF1ZW5jeQ0KKFhFTikgWzIwMTItMDktMDMgMjA6NTU6
MzFdIG1jaGVja19wb2xsOiBNYWNoaW5lIGNoZWNrIHBvbGxpbmcgdGltZXIgc3RhcnRlZC4N
CihYRU4pIFsyMDEyLTA5LTAzIDIwOjU1OjMxXSBYZW5vcHJvZmlsZTogRmFpbGVkIHRvIHNl
dHVwIElCUyBMVlQgb2Zmc2V0LCBJQlNDVEwgPSAweGZmZmZmZmZmDQooWEVOKSBbMjAxMi0w
OS0wMyAyMDo1NTozMV0gKioqIExPQURJTkcgRE9NQUlOIDAgKioqDQooWEVOKSBbMjAxMi0w
OS0wMyAyMDo1NTozMV0gZWxmX3BhcnNlX2JpbmFyeTogcGhkcjogcGFkZHI9MHgxMDAwMDAw
IG1lbXN6PTB4ZDZhMDAwDQooWEVOKSBbMjAxMi0wOS0wMyAyMDo1NTozMV0gZWxmX3BhcnNl
X2JpbmFyeTogcGhkcjogcGFkZHI9MHgxZTAwMDAwIG1lbXN6PTB4ZGIwZTgNCihYRU4pIFsy
MDEyLTA5LTAzIDIwOjU1OjMxXSBlbGZfcGFyc2VfYmluYXJ5OiBwaGRyOiBwYWRkcj0weDFl
ZGMwMDAgbWVtc3o9MHgxM2MwMA0KKFhFTikgWzIwMTItMDktMDMgMjA6NTU6MzFdIGVsZl9w
YXJzZV9iaW5hcnk6IHBoZHI6IHBhZGRyPTB4MWVmMDAwMCBtZW1zej0weGRlNTAwMA0KKFhF
TikgWzIwMTItMDktMDMgMjA6NTU6MzFdIGVsZl9wYXJzZV9iaW5hcnk6IG1lbW9yeTogMHgx
MDAwMDAwIC0+IDB4MmNkNTAwMA0KKFhFTikgWzIwMTItMDktMDMgMjA6NTU6MzFdIGVsZl94
ZW5fcGFyc2Vfbm90ZTogR1VFU1RfT1MgPSAibGludXgiDQooWEVOKSBbMjAxMi0wOS0wMyAy
MDo1NTozMV0gZWxmX3hlbl9wYXJzZV9ub3RlOiBHVUVTVF9WRVJTSU9OID0gIjIuNiINCihY
RU4pIFsyMDEyLTA5LTAzIDIwOjU1OjMxXSBlbGZfeGVuX3BhcnNlX25vdGU6IFhFTl9WRVJT
SU9OID0gInhlbi0zLjAiDQooWEVOKSBbMjAxMi0wOS0wMyAyMDo1NTozMV0gZWxmX3hlbl9w
YXJzZV9ub3RlOiBWSVJUX0JBU0UgPSAweGZmZmZmZmZmODAwMDAwMDANCihYRU4pIFsyMDEy
LTA5LTAzIDIwOjU1OjMxXSBlbGZfeGVuX3BhcnNlX25vdGU6IEVOVFJZID0gMHhmZmZmZmZm
ZjgxZWYwMjEwDQooWEVOKSBbMjAxMi0wOS0wMyAyMDo1NTozMV0gZWxmX3hlbl9wYXJzZV9u
b3RlOiBIWVBFUkNBTExfUEFHRSA9IDB4ZmZmZmZmZmY4MTAwMTAwMA0KKFhFTikgWzIwMTIt
MDktMDMgMjA6NTU6MzFdIGVsZl94ZW5fcGFyc2Vfbm90ZTogRkVBVFVSRVMgPSAiIXdyaXRh
YmxlX3BhZ2VfdGFibGVzfHBhZV9wZ2Rpcl9hYm92ZV80Z2IiDQooWEVOKSBbMjAxMi0wOS0w
MyAyMDo1NTozMV0gZWxmX3hlbl9wYXJzZV9ub3RlOiBQQUVfTU9ERSA9ICJ5ZXMiDQooWEVO
KSBbMjAxMi0wOS0wMyAyMDo1NTozMV0gZWxmX3hlbl9wYXJzZV9ub3RlOiBMT0FERVIgPSAi
Z2VuZXJpYyINCihYRU4pIFsyMDEyLTA5LTAzIDIwOjU1OjMxXSBlbGZfeGVuX3BhcnNlX25v
dGU6IHVua25vd24geGVuIGVsZiBub3RlICgweGQpDQooWEVOKSBbMjAxMi0wOS0wMyAyMDo1
NTozMV0gZWxmX3hlbl9wYXJzZV9ub3RlOiBTVVNQRU5EX0NBTkNFTCA9IDB4MQ0KKFhFTikg
WzIwMTItMDktMDMgMjA6NTU6MzFdIGVsZl94ZW5fcGFyc2Vfbm90ZTogSFZfU1RBUlRfTE9X
ID0gMHhmZmZmODAwMDAwMDAwMDAwDQooWEVOKSBbMjAxMi0wOS0wMyAyMDo1NTozMV0gZWxm
X3hlbl9wYXJzZV9ub3RlOiBQQUREUl9PRkZTRVQgPSAweDANCihYRU4pIFsyMDEyLTA5LTAz
IDIwOjU1OjMxXSBlbGZfeGVuX2FkZHJfY2FsY19jaGVjazogYWRkcmVzc2VzOg0KKFhFTikg
WzIwMTItMDktMDMgMjA6NTU6MzFdICAgICB2aXJ0X2Jhc2UgICAgICAgID0gMHhmZmZmZmZm
ZjgwMDAwMDAwDQooWEVOKSBbMjAxMi0wOS0wMyAyMDo1NTozMV0gICAgIGVsZl9wYWRkcl9v
ZmZzZXQgPSAweDANCihYRU4pIFsyMDEyLTA5LTAzIDIwOjU1OjMxXSAgICAgdmlydF9vZmZz
ZXQgICAgICA9IDB4ZmZmZmZmZmY4MDAwMDAwMA0KKFhFTikgWzIwMTItMDktMDMgMjA6NTU6
MzFdICAgICB2aXJ0X2tzdGFydCAgICAgID0gMHhmZmZmZmZmZjgxMDAwMDAwDQooWEVOKSBb
MjAxMi0wOS0wMyAyMDo1NTozMV0gICAgIHZpcnRfa2VuZCAgICAgICAgPSAweGZmZmZmZmZm
ODJjZDUwMDANCihYRU4pIFsyMDEyLTA5LTAzIDIwOjU1OjMxXSAgICAgdmlydF9lbnRyeSAg
ICAgICA9IDB4ZmZmZmZmZmY4MWVmMDIxMA0KKFhFTikgWzIwMTItMDktMDMgMjA6NTU6MzFd
ICAgICBwMm1fYmFzZSAgICAgICAgID0gMHhmZmZmZmZmZmZmZmZmZmZmDQooWEVOKSBbMjAx
Mi0wOS0wMyAyMDo1NTozMV0gIFhlbiAga2VybmVsOiA2NC1iaXQsIGxzYiwgY29tcGF0MzIN
CihYRU4pIFsyMDEyLTA5LTAzIDIwOjU1OjMxXSAgRG9tMCBrZXJuZWw6IDY0LWJpdCwgUEFF
LCBsc2IsIHBhZGRyIDB4MTAwMDAwMCAtPiAweDJjZDUwMDANCihYRU4pIFsyMDEyLTA5LTAz
IDIwOjU1OjMxXSBQSFlTSUNBTCBNRU1PUlkgQVJSQU5HRU1FTlQ6DQooWEVOKSBbMjAxMi0w
OS0wMyAyMDo1NTozMV0gIERvbTAgYWxsb2MuOiAgIDAwMDAwMDAyNDAwMDAwMDAtPjAwMDAw
MDAyNDQwMDAwMDAgKDI0MjQyOCBwYWdlcyB0byBiZSBhbGxvY2F0ZWQpDQooWEVOKSBbMjAx
Mi0wOS0wMyAyMDo1NTozMV0gIEluaXQuIHJhbWRpc2s6IDAwMDAwMDAyNGYyZmMwMDAtPjAw
MDAwMDAyNGZmZmY4MDANCihYRU4pIFsyMDEyLTA5LTAzIDIwOjU1OjMxXSBWSVJUVUFMIE1F
TU9SWSBBUlJBTkdFTUVOVDoNCihYRU4pIFsyMDEyLTA5LTAzIDIwOjU1OjMxXSAgTG9hZGVk
IGtlcm5lbDogZmZmZmZmZmY4MTAwMDAwMC0+ZmZmZmZmZmY4MmNkNTAwMA0KKFhFTikgWzIw
MTItMDktMDMgMjA6NTU6MzFdICBJbml0LiByYW1kaXNrOiBmZmZmZmZmZjgyY2Q1MDAwLT5m
ZmZmZmZmZjgzOWQ4ODAwDQooWEVOKSBbMjAxMi0wOS0wMyAyMDo1NTozMV0gIFBoeXMtTWFj
aCBtYXA6IGZmZmZmZmZmODM5ZDkwMDAtPmZmZmZmZmZmODNiZDkwMDANCihYRU4pIFsyMDEy
LTA5LTAzIDIwOjU1OjMxXSAgU3RhcnQgaW5mbzogICAgZmZmZmZmZmY4M2JkOTAwMC0+ZmZm
ZmZmZmY4M2JkOTRiNA0KKFhFTikgWzIwMTItMDktMDMgMjA6NTU6MzFdICBQYWdlIHRhYmxl
czogICBmZmZmZmZmZjgzYmRhMDAwLT5mZmZmZmZmZjgzYmZkMDAwDQooWEVOKSBbMjAxMi0w
OS0wMyAyMDo1NTozMV0gIEJvb3Qgc3RhY2s6ICAgIGZmZmZmZmZmODNiZmQwMDAtPmZmZmZm
ZmZmODNiZmUwMDANCihYRU4pIFsyMDEyLTA5LTAzIDIwOjU1OjMxXSAgVE9UQUw6ICAgICAg
ICAgZmZmZmZmZmY4MDAwMDAwMC0+ZmZmZmZmZmY4NDAwMDAwMA0KKFhFTikgWzIwMTItMDkt
MDMgMjA6NTU6MzFdICBFTlRSWSBBRERSRVNTOiBmZmZmZmZmZjgxZWYwMjEwDQooWEVOKSBb
MjAxMi0wOS0wMyAyMDo1NTozMV0gRG9tMCBoYXMgbWF4aW11bSA2IFZDUFVzDQooWEVOKSBb
MjAxMi0wOS0wMyAyMDo1NTozMl0gZWxmX2xvYWRfYmluYXJ5OiBwaGRyIDAgYXQgMHhmZmZm
ZmZmZjgxMDAwMDAwIC0+IDB4ZmZmZmZmZmY4MWQ2YTAwMA0KKFhFTikgWzIwMTItMDktMDMg
MjA6NTU6MzJdIGVsZl9sb2FkX2JpbmFyeTogcGhkciAxIGF0IDB4ZmZmZmZmZmY4MWUwMDAw
MCAtPiAweGZmZmZmZmZmODFlZGIwZTgNCihYRU4pIFsyMDEyLTA5LTAzIDIwOjU1OjMyXSBl
bGZfbG9hZF9iaW5hcnk6IHBoZHIgMiBhdCAweGZmZmZmZmZmODFlZGMwMDAgLT4gMHhmZmZm
ZmZmZjgxZWVmYzAwDQooWEVOKSBbMjAxMi0wOS0wMyAyMDo1NTozMl0gZWxmX2xvYWRfYmlu
YXJ5OiBwaGRyIDMgYXQgMHhmZmZmZmZmZjgxZWYwMDAwIC0+IDB4ZmZmZmZmZmY4MWY4OTAw
MA0KKFhFTikgWzIwMTItMDktMDMgMjA6NTU6MzJdIEFNRC1WaTogTUUgSEVSRSAhPDI+QU1E
LVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHgwMDAwLCByb290IHRh
YmxlID0gMHgyNGQ4NGIwMDAsIGRvbWFpbiA9IDAsIHBhZ2luZyBtb2RlID0gMw0KKFhFTikg
WzIwMTItMDktMDMgMjA6NTU6MzJdIEFNRC1WaTogU2V0dXAgSS9PIHBhZ2UgdGFibGU6IGRl
dmljZSBpZCA9IDB4MDAwMiwgcm9vdCB0YWJsZSA9IDB4MjRkODRiMDAwLCBkb21haW4gPSAw
LCBwYWdpbmcgbW9kZSA9IDMNCihYRU4pIFsyMDEyLTA5LTAzIDIwOjU1OjMyXSBBTUQtVmk6
IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweDAwMTAsIHJvb3QgdGFibGUg
PSAweDI0ZDg0YjAwMCwgZG9tYWluID0gMCwgcGFnaW5nIG1vZGUgPSAzDQooWEVOKSBbMjAx
Mi0wOS0wMyAyMDo1NTozMl0gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNl
IGlkID0gMHgwMDE4LCByb290IHRhYmxlID0gMHgyNGQ4NGIwMDAsIGRvbWFpbiA9IDAsIHBh
Z2luZyBtb2RlID0gMw0KKFhFTikgWzIwMTItMDktMDMgMjA6NTU6MzJdIEFNRC1WaTogU2V0
dXAgSS9PIHBhZ2UgdGFibGU6IGRldmljZSBpZCA9IDB4MDAyOCwgcm9vdCB0YWJsZSA9IDB4
MjRkODRiMDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMNCihYRU4pIFsyMDEyLTA5
LTAzIDIwOjU1OjMyXSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQg
PSAweDAwMzAsIHJvb3QgdGFibGUgPSAweDI0ZDg0YjAwMCwgZG9tYWluID0gMCwgcGFnaW5n
IG1vZGUgPSAzDQooWEVOKSBbMjAxMi0wOS0wMyAyMDo1NTozMl0gQU1ELVZpOiBTZXR1cCBJ
L08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHgwMDUwLCByb290IHRhYmxlID0gMHgyNGQ4
NGIwMDAsIGRvbWFpbiA9IDAsIHBhZ2luZyBtb2RlID0gMw0KKFhFTikgWzIwMTItMDktMDMg
MjA6NTU6MzJdIEFNRC1WaTogU2V0dXAgSS9PIHBhZ2UgdGFibGU6IGRldmljZSBpZCA9IDB4
MDA1OCwgcm9vdCB0YWJsZSA9IDB4MjRkODRiMDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9k
ZSA9IDMNCihYRU4pIFsyMDEyLTA5LTAzIDIwOjU1OjMyXSBBTUQtVmk6IFNldHVwIEkvTyBw
YWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweDAwNjAsIHJvb3QgdGFibGUgPSAweDI0ZDg0YjAw
MCwgZG9tYWluID0gMCwgcGFnaW5nIG1vZGUgPSAzDQooWEVOKSBbMjAxMi0wOS0wMyAyMDo1
NTozMl0gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHgwMDY4
LCByb290IHRhYmxlID0gMHgyNGQ4NGIwMDAsIGRvbWFpbiA9IDAsIHBhZ2luZyBtb2RlID0g
Mw0KKFhFTikgWzIwMTItMDktMDMgMjA6NTU6MzJdIEFNRC1WaTogU2V0dXAgSS9PIHBhZ2Ug
dGFibGU6IGRldmljZSBpZCA9IDB4MDA4OCwgcm9vdCB0YWJsZSA9IDB4MjRkODRiMDAwLCBk
b21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMNCihYRU4pIFsyMDEyLTA5LTAzIDIwOjU1OjMy
XSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweDAwOTAsIHJv
b3QgdGFibGUgPSAweDI0ZDg0YjAwMCwgZG9tYWluID0gMCwgcGFnaW5nIG1vZGUgPSAzDQoo
WEVOKSBbMjAxMi0wOS0wMyAyMDo1NTozMl0gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJs
ZTogZGV2aWNlIGlkID0gMHgwMDkyLCByb290IHRhYmxlID0gMHgyNGQ4NGIwMDAsIGRvbWFp
biA9IDAsIHBhZ2luZyBtb2RlID0gMw0KKFhFTikgWzIwMTItMDktMDMgMjA6NTU6MzJdIEFN
RC1WaTogU2V0dXAgSS9PIHBhZ2UgdGFibGU6IGRldmljZSBpZCA9IDB4MDA5OCwgcm9vdCB0
YWJsZSA9IDB4MjRkODRiMDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMNCihYRU4p
IFsyMDEyLTA5LTAzIDIwOjU1OjMyXSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBk
ZXZpY2UgaWQgPSAweDAwOWEsIHJvb3QgdGFibGUgPSAweDI0ZDg0YjAwMCwgZG9tYWluID0g
MCwgcGFnaW5nIG1vZGUgPSAzDQooWEVOKSBbMjAxMi0wOS0wMyAyMDo1NTozMl0gQU1ELVZp
OiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHgwMGEwLCByb290IHRhYmxl
ID0gMHgyNGQ4NGIwMDAsIGRvbWFpbiA9IDAsIHBhZ2luZyBtb2RlID0gMw0KKFhFTikgWzIw
MTItMDktMDMgMjA6NTU6MzJdIEFNRC1WaTogU2V0dXAgSS9PIHBhZ2UgdGFibGU6IGRldmlj
ZSBpZCA9IDB4MDBhMywgcm9vdCB0YWJsZSA9IDB4MjRkODRiMDAwLCBkb21haW4gPSAwLCBw
YWdpbmcgbW9kZSA9IDMNCihYRU4pIFsyMDEyLTA5LTAzIDIwOjU1OjMyXSBBTUQtVmk6IFNl
dHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweDAwYTQsIHJvb3QgdGFibGUgPSAw
eDI0ZDg0YjAwMCwgZG9tYWluID0gMCwgcGFnaW5nIG1vZGUgPSAzDQooWEVOKSBbMjAxMi0w
OS0wMyAyMDo1NTozMl0gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlk
ID0gMHgwMGE1LCByb290IHRhYmxlID0gMHgyNGQ4NGIwMDAsIGRvbWFpbiA9IDAsIHBhZ2lu
ZyBtb2RlID0gMw0KKFhFTikgWzIwMTItMDktMDMgMjA6NTU6MzJdIEFNRC1WaTogU2V0dXAg
SS9PIHBhZ2UgdGFibGU6IGRldmljZSBpZCA9IDB4MDBhOCwgcm9vdCB0YWJsZSA9IDB4MjRk
ODRiMDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMNCihYRU4pIFsyMDEyLTA5LTAz
IDIwOjU1OjMyXSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAw
eDAwYjAsIHJvb3QgdGFibGUgPSAweDI0ZDg0YjAwMCwgZG9tYWluID0gMCwgcGFnaW5nIG1v
ZGUgPSAzDQooWEVOKSBbMjAxMi0wOS0wMyAyMDo1NTozMl0gQU1ELVZpOiBTZXR1cCBJL08g
cGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHgwMGIyLCByb290IHRhYmxlID0gMHgyNGQ4NGIw
MDAsIGRvbWFpbiA9IDAsIHBhZ2luZyBtb2RlID0gMw0KKFhFTikgWzIwMTItMDktMDMgMjA6
NTU6MzJdIEFNRC1WaTogTm8gaW9tbXUgZm9yIGRldmljZSAwMDAwOjAwOjE4LjANCihYRU4p
IFsyMDEyLTA5LTAzIDIwOjU1OjMyXSBBTUQtVmk6IE5vIGlvbW11IGZvciBkZXZpY2UgMDAw
MDowMDoxOC4xDQooWEVOKSBbMjAxMi0wOS0wMyAyMDo1NTozMl0gQU1ELVZpOiBObyBpb21t
dSBmb3IgZGV2aWNlIDAwMDA6MDA6MTguMg0KKFhFTikgWzIwMTItMDktMDMgMjA6NTU6MzJd
IEFNRC1WaTogTm8gaW9tbXUgZm9yIGRldmljZSAwMDAwOjAwOjE4LjMNCihYRU4pIFsyMDEy
LTA5LTAzIDIwOjU1OjMyXSBBTUQtVmk6IE5vIGlvbW11IGZvciBkZXZpY2UgMDAwMDowMDox
OC40DQooWEVOKSBbMjAxMi0wOS0wMyAyMDo1NTozMl0gQU1ELVZpOiBTZXR1cCBJL08gcGFn
ZSB0YWJsZTogZGV2aWNlIGlkID0gMHgwNDAwLCByb290IHRhYmxlID0gMHgyNGQ4NGIwMDAs
IGRvbWFpbiA9IDAsIHBhZ2luZyBtb2RlID0gMw0KKFhFTikgWzIwMTItMDktMDMgMjA6NTU6
MzJdIEFNRC1WaTogU2V0dXAgSS9PIHBhZ2UgdGFibGU6IGRldmljZSBpZCA9IDB4MDQwMSwg
cm9vdCB0YWJsZSA9IDB4MjRkODRiMDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMN
CihYRU4pIFsyMDEyLTA5LTAzIDIwOjU1OjMyXSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRh
YmxlOiBkZXZpY2UgaWQgPSAweDA0MDIsIHJvb3QgdGFibGUgPSAweDI0ZDg0YjAwMCwgZG9t
YWluID0gMCwgcGFnaW5nIG1vZGUgPSAzDQooWEVOKSBbMjAxMi0wOS0wMyAyMDo1NTozMl0g
QU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHgwNDAzLCByb290
IHRhYmxlID0gMHgyNGQ4NGIwMDAsIGRvbWFpbiA9IDAsIHBhZ2luZyBtb2RlID0gMw0KKFhF
TikgWzIwMTItMDktMDMgMjA6NTU6MzJdIEFNRC1WaTogU2V0dXAgSS9PIHBhZ2UgdGFibGU6
IGRldmljZSBpZCA9IDB4MDQwNCwgcm9vdCB0YWJsZSA9IDB4MjRkODRiMDAwLCBkb21haW4g
PSAwLCBwYWdpbmcgbW9kZSA9IDMNCihYRU4pIFsyMDEyLTA5LTAzIDIwOjU1OjMyXSBBTUQt
Vmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweDA0MDUsIHJvb3QgdGFi
bGUgPSAweDI0ZDg0YjAwMCwgZG9tYWluID0gMCwgcGFnaW5nIG1vZGUgPSAzDQooWEVOKSBb
MjAxMi0wOS0wMyAyMDo1NTozMl0gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2
aWNlIGlkID0gMHgwNDA2LCByb290IHRhYmxlID0gMHgyNGQ4NGIwMDAsIGRvbWFpbiA9IDAs
IHBhZ2luZyBtb2RlID0gMw0KKFhFTikgWzIwMTItMDktMDMgMjA6NTU6MzJdIEFNRC1WaTog
U2V0dXAgSS9PIHBhZ2UgdGFibGU6IGRldmljZSBpZCA9IDB4MDQwNywgcm9vdCB0YWJsZSA9
IDB4MjRkODRiMDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMNCihYRU4pIFsyMDEy
LTA5LTAzIDIwOjU1OjMyXSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2Ug
aWQgPSAweDA1MDAsIHJvb3QgdGFibGUgPSAweDI0ZDg0YjAwMCwgZG9tYWluID0gMCwgcGFn
aW5nIG1vZGUgPSAzDQooWEVOKSBbMjAxMi0wOS0wMyAyMDo1NTozMl0gQU1ELVZpOiBTZXR1
cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHgwNjAwLCByb290IHRhYmxlID0gMHgy
NGQ4NGIwMDAsIGRvbWFpbiA9IDAsIHBhZ2luZyBtb2RlID0gMw0KKFhFTikgWzIwMTItMDkt
MDMgMjA6NTU6MzJdIEFNRC1WaTogU2V0dXAgSS9PIHBhZ2UgdGFibGU6IGRldmljZSBpZCA9
IDB4MDYwMSwgcm9vdCB0YWJsZSA9IDB4MjRkODRiMDAwLCBkb21haW4gPSAwLCBwYWdpbmcg
bW9kZSA9IDMNCihYRU4pIFsyMDEyLTA5LTAzIDIwOjU1OjMyXSBBTUQtVmk6IFNldHVwIEkv
TyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweDA3MDAsIHJvb3QgdGFibGUgPSAweDI0ZDg0
YjAwMCwgZG9tYWluID0gMCwgcGFnaW5nIG1vZGUgPSAzDQooWEVOKSBbMjAxMi0wOS0wMyAy
MDo1NTozMl0gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHgw
ODAwLCByb290IHRhYmxlID0gMHgyNGQ4NGIwMDAsIGRvbWFpbiA9IDAsIHBhZ2luZyBtb2Rl
ID0gMw0KKFhFTikgWzIwMTItMDktMDMgMjA6NTU6MzJdIEFNRC1WaTogU2V0dXAgSS9PIHBh
Z2UgdGFibGU6IGRldmljZSBpZCA9IDB4MDkwMCwgcm9vdCB0YWJsZSA9IDB4MjRkODRiMDAw
LCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMNCihYRU4pIFsyMDEyLTA5LTAzIDIwOjU1
OjMyXSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweDBhMDAs
IHJvb3QgdGFibGUgPSAweDI0ZDg0YjAwMCwgZG9tYWluID0gMCwgcGFnaW5nIG1vZGUgPSAz
DQooWEVOKSBbMjAxMi0wOS0wMyAyMDo1NTozMl0gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0
YWJsZTogZGV2aWNlIGlkID0gMHgwYTAxLCByb290IHRhYmxlID0gMHgyNGQ4NGIwMDAsIGRv
bWFpbiA9IDAsIHBhZ2luZyBtb2RlID0gMw0KKFhFTikgWzIwMTItMDktMDMgMjA6NTU6MzJd
IEFNRC1WaTogU2V0dXAgSS9PIHBhZ2UgdGFibGU6IGRldmljZSBpZCA9IDB4MGEwMiwgcm9v
dCB0YWJsZSA9IDB4MjRkODRiMDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMNCihY
RU4pIFsyMDEyLTA5LTAzIDIwOjU1OjMyXSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxl
OiBkZXZpY2UgaWQgPSAweDBhMDMsIHJvb3QgdGFibGUgPSAweDI0ZDg0YjAwMCwgZG9tYWlu
ID0gMCwgcGFnaW5nIG1vZGUgPSAzDQooWEVOKSBbMjAxMi0wOS0wMyAyMDo1NTozMl0gQU1E
LVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHgwYTA0LCByb290IHRh
YmxlID0gMHgyNGQ4NGIwMDAsIGRvbWFpbiA9IDAsIHBhZ2luZyBtb2RlID0gMw0KKFhFTikg
WzIwMTItMDktMDMgMjA6NTU6MzJdIEFNRC1WaTogU2V0dXAgSS9PIHBhZ2UgdGFibGU6IGRl
dmljZSBpZCA9IDB4MGEwNSwgcm9vdCB0YWJsZSA9IDB4MjRkODRiMDAwLCBkb21haW4gPSAw
LCBwYWdpbmcgbW9kZSA9IDMNCihYRU4pIFsyMDEyLTA5LTAzIDIwOjU1OjMyXSBBTUQtVmk6
IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweDBhMDYsIHJvb3QgdGFibGUg
PSAweDI0ZDg0YjAwMCwgZG9tYWluID0gMCwgcGFnaW5nIG1vZGUgPSAzDQooWEVOKSBbMjAx
Mi0wOS0wMyAyMDo1NTozMl0gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNl
IGlkID0gMHgwYTA3LCByb290IHRhYmxlID0gMHgyNGQ4NGIwMDAsIGRvbWFpbiA9IDAsIHBh
Z2luZyBtb2RlID0gMw0KKFhFTikgWzIwMTItMDktMDMgMjA6NTU6MzJdIEFNRC1WaTogU2V0
dXAgSS9PIHBhZ2UgdGFibGU6IGRldmljZSBpZCA9IDB4MGIwMCwgcm9vdCB0YWJsZSA9IDB4
MjRkODRiMDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMNCihYRU4pIFsyMDEyLTA5
LTAzIDIwOjU1OjMyXSBTY3J1YmJpbmcgRnJlZSBSQU06IC4uLi4uLi4uLi4uLi4uLi4uLi4u
Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uZG9u
ZS4NCihYRU4pIFsyMDEyLTA5LTAzIDIwOjU1OjM0XSBJbml0aWFsIGxvdyBtZW1vcnkgdmly
cSB0aHJlc2hvbGQgc2V0IGF0IDB4NDAwMCBwYWdlcy4NCihYRU4pIFsyMDEyLTA5LTAzIDIw
OjU1OjM0XSBTdGQuIExvZ2xldmVsOiBBbGwNCihYRU4pIFsyMDEyLTA5LTAzIDIwOjU1OjM0
XSBHdWVzdCBMb2dsZXZlbDogQWxsDQooWEVOKSBbMjAxMi0wOS0wMyAyMDo1NTozNF0gWGVu
IGlzIHJlbGlucXVpc2hpbmcgVkdBIGNvbnNvbGUuDQooWEVOKSBbMjAxMi0wOS0wMyAyMDo1
NTozNF0gKioqIFNlcmlhbCBpbnB1dCAtPiBET00wICh0eXBlICdDVFJMLWEnIHRocmVlIHRp
bWVzIHRvIHN3aXRjaCBpbnB1dCB0byBYZW4pDQooWEVOKSBbMjAxMi0wOS0wMyAyMDo1NToz
NF0gRnJlZWQgMjU2a0IgaW5pdCBtZW1vcnkuDQooWEVOKSBbMjAxMi0wOS0wMyAyMDo1NToz
NF0gSU9BUElDWzBdOiBTZXQgUENJIHJvdXRpbmcgZW50cnkgKDYtOSAtPiAweDYwIC0+IElS
USA5IE1vZGU6MSBBY3RpdmU6MSkNCihYRU4pIFsyMDEyLTA5LTAzIDIwOjU1OjM0XSB0cmFw
cy5jOjI1ODQ6ZDAgRG9tYWluIGF0dGVtcHRlZCBXUk1TUiAwMDAwMDAwMGMwMDAwNDA4IGZy
b20gMHhjMDAwMDAwMDAxMDAwMDAwIHRvIDB4YzAwODAwMDAwMTAwMDAwMC4NCihYRU4pIFsy
MDEyLTA5LTAzIDIwOjU1OjM0XSB0cmFwcy5jOjI1ODQ6ZDAgRG9tYWluIGF0dGVtcHRlZCBX
Uk1TUiAwMDAwMDAwMGMwMDAwNDA5IGZyb20gMHhjMDAwMDAwMDAxMDAwMDAwIHRvIDB4YzAw
ODAwMDAwMTAwMDAwMC4NCihYRU4pIFsyMDEyLTA5LTAzIDIwOjU1OjM1XSB0cmFwcy5jOjI1
ODQ6ZDAgRG9tYWluIGF0dGVtcHRlZCBXUk1TUiAwMDAwMDAwMGMwMDEwMDA0IGZyb20gMHgw
MDAwZWZmMGJkZmIxZmNlIHRvIDB4MDAwMDAwMDAwMDAwYWJjZC4NCihYRU4pIFsyMDEyLTA5
LTAzIDIwOjU1OjM1XSB0cmFwcy5jOjI1ODQ6ZDAgRG9tYWluIGF0dGVtcHRlZCBXUk1TUiAw
MDAwMDAwMGMwMDAwNDA4IGZyb20gMHhjMDAwMDAwMDAxMDAwMDAwIHRvIDB4YzAwODAwMDAw
MTAwMDAwMC4NCihYRU4pIFsyMDEyLTA5LTAzIDIwOjU1OjM1XSB0cmFwcy5jOjI1ODQ6ZDAg
RG9tYWluIGF0dGVtcHRlZCBXUk1TUiAwMDAwMDAwMGMwMDAwNDA5IGZyb20gMHhjMDAwMDAw
MDAxMDAwMDAwIHRvIDB4YzAwODAwMDAwMTAwMDAwMC4NCihYRU4pIFsyMDEyLTA5LTAzIDIw
OjU1OjM1XSB0cmFwcy5jOjI1ODQ6ZDAgRG9tYWluIGF0dGVtcHRlZCBXUk1TUiAwMDAwMDAw
MGMwMDAwNDA4IGZyb20gMHhjMDAwMDAwMDAxMDAwMDAwIHRvIDB4YzAwODAwMDAwMTAwMDAw
MC4NCihYRU4pIFsyMDEyLTA5LTAzIDIwOjU1OjM1XSB0cmFwcy5jOjI1ODQ6ZDAgRG9tYWlu
IGF0dGVtcHRlZCBXUk1TUiAwMDAwMDAwMGMwMDAwNDA5IGZyb20gMHhjMDAwMDAwMDAxMDAw
MDAwIHRvIDB4YzAwODAwMDAwMTAwMDAwMC4NCihYRU4pIFsyMDEyLTA5LTAzIDIwOjU1OjM1
XSB0cmFwcy5jOjI1ODQ6ZDAgRG9tYWluIGF0dGVtcHRlZCBXUk1TUiAwMDAwMDAwMGMwMDAw
NDA4IGZyb20gMHhjMDAwMDAwMDAxMDAwMDAwIHRvIDB4YzAwODAwMDAwMTAwMDAwMC4NCihY
RU4pIFsyMDEyLTA5LTAzIDIwOjU1OjM1XSB0cmFwcy5jOjI1ODQ6ZDAgRG9tYWluIGF0dGVt
cHRlZCBXUk1TUiAwMDAwMDAwMGMwMDAwNDA5IGZyb20gMHhjMDAwMDAwMDAxMDAwMDAwIHRv
IDB4YzAwODAwMDAwMTAwMDAwMC4NCihYRU4pIFsyMDEyLTA5LTAzIDIwOjU1OjM1XSB0cmFw
cy5jOjI1ODQ6ZDAgRG9tYWluIGF0dGVtcHRlZCBXUk1TUiAwMDAwMDAwMGMwMDAwNDA4IGZy
b20gMHhjMDAwMDAwMDAxMDAwMDAwIHRvIDB4YzAwODAwMDAwMTAwMDAwMC4NCihYRU4pIFsy
MDEyLTA5LTAzIDIwOjU1OjM1XSB0cmFwcy5jOjI1ODQ6ZDAgRG9tYWluIGF0dGVtcHRlZCBX
Uk1TUiAwMDAwMDAwMGMwMDAwNDA5IGZyb20gMHhjMDAwMDAwMDAxMDAwMDAwIHRvIDB4YzAw
ODAwMDAwMTAwMDAwMC4NCihYRU4pIFsyMDEyLTA5LTAzIDIwOjU1OjM1XSB0cmFwcy5jOjI1
ODQ6ZDAgRG9tYWluIGF0dGVtcHRlZCBXUk1TUiAwMDAwMDAwMGMwMDAwNDA4IGZyb20gMHhj
MDAwMDAwMDAxMDAwMDAwIHRvIDB4YzAwODAwMDAwMTAwMDAwMC4NCihYRU4pIFsyMDEyLTA5
LTAzIDIwOjU1OjM1XSB0cmFwcy5jOjI1ODQ6ZDAgRG9tYWluIGF0dGVtcHRlZCBXUk1TUiAw
MDAwMDAwMGMwMDAwNDA5IGZyb20gMHhjMDAwMDAwMDAxMDAwMDAwIHRvIDB4YzAwODAwMDAw
MTAwMDAwMC4NCihYRU4pIFsyMDEyLTA5LTAzIDIwOjU1OjM1XSBQQ0kgYWRkIGRldmljZSAw
MDAwOjAwOjAwLjANCihYRU4pIFsyMDEyLTA5LTAzIDIwOjU1OjM1XSBQQ0kgYWRkIGRldmlj
ZSAwMDAwOjAwOjAwLjINCihYRU4pIFsyMDEyLTA5LTAzIDIwOjU1OjM1XSBQQ0kgYWRkIGRl
dmljZSAwMDAwOjAwOjAyLjANCihYRU4pIFsyMDEyLTA5LTAzIDIwOjU1OjM1XSBQQ0kgYWRk
IGRldmljZSAwMDAwOjAwOjAzLjANCihYRU4pIFsyMDEyLTA5LTAzIDIwOjU1OjM1XSBQQ0kg
YWRkIGRldmljZSAwMDAwOjAwOjA1LjANCihYRU4pIFsyMDEyLTA5LTAzIDIwOjU1OjM1XSBQ
Q0kgYWRkIGRldmljZSAwMDAwOjAwOjA2LjANCihYRU4pIFsyMDEyLTA5LTAzIDIwOjU1OjM1
XSBQQ0kgYWRkIGRldmljZSAwMDAwOjAwOjBhLjANCihYRU4pIFsyMDEyLTA5LTAzIDIwOjU1
OjM1XSBQQ0kgYWRkIGRldmljZSAwMDAwOjAwOjBiLjANCihYRU4pIFsyMDEyLTA5LTAzIDIw
OjU1OjM1XSBQQ0kgYWRkIGRldmljZSAwMDAwOjAwOjBjLjANCihYRU4pIFsyMDEyLTA5LTAz
IDIwOjU1OjM1XSBQQ0kgYWRkIGRldmljZSAwMDAwOjAwOjBkLjANCihYRU4pIFsyMDEyLTA5
LTAzIDIwOjU1OjM1XSBQQ0kgYWRkIGRldmljZSAwMDAwOjAwOjExLjANCihYRU4pIFsyMDEy
LTA5LTAzIDIwOjU1OjM1XSBQQ0kgYWRkIGRldmljZSAwMDAwOjAwOjEyLjANCihYRU4pIFsy
MDEyLTA5LTAzIDIwOjU1OjM1XSBQQ0kgYWRkIGRldmljZSAwMDAwOjAwOjEyLjINCihYRU4p
IFsyMDEyLTA5LTAzIDIwOjU1OjM1XSBQQ0kgYWRkIGRldmljZSAwMDAwOjAwOjEzLjANCihY
RU4pIFsyMDEyLTA5LTAzIDIwOjU1OjM1XSBQQ0kgYWRkIGRldmljZSAwMDAwOjAwOjEzLjIN
CihYRU4pIFsyMDEyLTA5LTAzIDIwOjU1OjM1XSBQQ0kgYWRkIGRldmljZSAwMDAwOjAwOjE0
LjANCihYRU4pIFsyMDEyLTA5LTAzIDIwOjU1OjM1XSBQQ0kgYWRkIGRldmljZSAwMDAwOjAw
OjE0LjMNCihYRU4pIFsyMDEyLTA5LTAzIDIwOjU1OjM1XSBQQ0kgYWRkIGRldmljZSAwMDAw
OjAwOjE0LjQNCihYRU4pIFsyMDEyLTA5LTAzIDIwOjU1OjM1XSBQQ0kgYWRkIGRldmljZSAw
MDAwOjAwOjE0LjUNCihYRU4pIFsyMDEyLTA5LTAzIDIwOjU1OjM1XSBQQ0kgYWRkIGRldmlj
ZSAwMDAwOjAwOjE1LjANCihYRU4pIFsyMDEyLTA5LTAzIDIwOjU1OjM1XSBQQ0kgYWRkIGRl
dmljZSAwMDAwOjAwOjE2LjANCihYRU4pIFsyMDEyLTA5LTAzIDIwOjU1OjM1XSBQQ0kgYWRk
IGRldmljZSAwMDAwOjAwOjE2LjINCihYRU4pIFsyMDEyLTA5LTAzIDIwOjU1OjM1XSBQQ0kg
YWRkIGRldmljZSAwMDAwOjAwOjE4LjANCihYRU4pIFsyMDEyLTA5LTAzIDIwOjU1OjM1XSBQ
Q0kgYWRkIGRldmljZSAwMDAwOjAwOjE4LjENCihYRU4pIFsyMDEyLTA5LTAzIDIwOjU1OjM1
XSBQQ0kgYWRkIGRldmljZSAwMDAwOjAwOjE4LjINCihYRU4pIFsyMDEyLTA5LTAzIDIwOjU1
OjM1XSBQQ0kgYWRkIGRldmljZSAwMDAwOjAwOjE4LjMNCihYRU4pIFsyMDEyLTA5LTAzIDIw
OjU1OjM1XSBQQ0kgYWRkIGRldmljZSAwMDAwOjAwOjE4LjQNCihYRU4pIFsyMDEyLTA5LTAz
IDIwOjU1OjM1XSBQQ0kgYWRkIGRldmljZSAwMDAwOjBiOjAwLjANCihYRU4pIFsyMDEyLTA5
LTAzIDIwOjU1OjM1XSBQQ0kgYWRkIGRldmljZSAwMDAwOjBhOjAwLjANCihYRU4pIFsyMDEy
LTA5LTAzIDIwOjU1OjM1XSBQQ0kgYWRkIGRldmljZSAwMDAwOjBhOjAwLjENCihYRU4pIFsy
MDEyLTA5LTAzIDIwOjU1OjM1XSBQQ0kgYWRkIGRldmljZSAwMDAwOjBhOjAwLjINCihYRU4p
IFsyMDEyLTA5LTAzIDIwOjU1OjM1XSBQQ0kgYWRkIGRldmljZSAwMDAwOjBhOjAwLjMNCihY
RU4pIFsyMDEyLTA5LTAzIDIwOjU1OjM1XSBQQ0kgYWRkIGRldmljZSAwMDAwOjBhOjAwLjQN
CihYRU4pIFsyMDEyLTA5LTAzIDIwOjU1OjM1XSBQQ0kgYWRkIGRldmljZSAwMDAwOjBhOjAw
LjUNCihYRU4pIFsyMDEyLTA5LTAzIDIwOjU1OjM1XSBQQ0kgYWRkIGRldmljZSAwMDAwOjBh
OjAwLjYNCihYRU4pIFsyMDEyLTA5LTAzIDIwOjU1OjM1XSBQQ0kgYWRkIGRldmljZSAwMDAw
OjBhOjAwLjcNCihYRU4pIFsyMDEyLTA5LTAzIDIwOjU1OjM1XSBQQ0kgYWRkIGRldmljZSAw
MDAwOjA5OjAwLjANCihYRU4pIFsyMDEyLTA5LTAzIDIwOjU1OjM1XSBQQ0kgYWRkIGRldmlj
ZSAwMDAwOjA4OjAwLjANCihYRU4pIFsyMDEyLTA5LTAzIDIwOjU1OjM1XSBQQ0kgYWRkIGRl
dmljZSAwMDAwOjA3OjAwLjANCihYRU4pIFsyMDEyLTA5LTAzIDIwOjU1OjM1XSBQQ0kgYWRk
IGRldmljZSAwMDAwOjA2OjAwLjANCihYRU4pIFsyMDEyLTA5LTAzIDIwOjU1OjM1XSBQQ0kg
YWRkIGRldmljZSAwMDAwOjA2OjAwLjENCihYRU4pIFsyMDEyLTA5LTAzIDIwOjU1OjM1XSBQ
Q0kgYWRkIGRldmljZSAwMDAwOjA1OjAwLjANCihYRU4pIFsyMDEyLTA5LTAzIDIwOjU1OjM1
XSBQQ0kgYWRkIGRldmljZSAwMDAwOjA0OjAwLjANCihYRU4pIFsyMDEyLTA5LTAzIDIwOjU1
OjM1XSBQQ0kgYWRkIGRldmljZSAwMDAwOjA0OjAwLjENCihYRU4pIFsyMDEyLTA5LTAzIDIw
OjU1OjM1XSBQQ0kgYWRkIGRldmljZSAwMDAwOjA0OjAwLjINCihYRU4pIFsyMDEyLTA5LTAz
IDIwOjU1OjM1XSBQQ0kgYWRkIGRldmljZSAwMDAwOjA0OjAwLjMNCihYRU4pIFsyMDEyLTA5
LTAzIDIwOjU1OjM1XSBQQ0kgYWRkIGRldmljZSAwMDAwOjA0OjAwLjQNCihYRU4pIFsyMDEy
LTA5LTAzIDIwOjU1OjM1XSBQQ0kgYWRkIGRldmljZSAwMDAwOjA0OjAwLjUNCihYRU4pIFsy
MDEyLTA5LTAzIDIwOjU1OjM1XSBQQ0kgYWRkIGRldmljZSAwMDAwOjA0OjAwLjYNCihYRU4p
IFsyMDEyLTA5LTAzIDIwOjU1OjM1XSBQQ0kgYWRkIGRldmljZSAwMDAwOjA0OjAwLjcNCihY
RU4pIFsyMDEyLTA5LTAzIDIwOjU1OjM1XSBQQ0kgYWRkIGRldmljZSAwMDAwOjAzOjA2LjAN
CihYRU4pIFsyMDEyLTA5LTAzIDIwOjU1OjM1XSBJT0FQSUNbMF06IFNldCBQQ0kgcm91dGlu
ZyBlbnRyeSAoNi04IC0+IDB4NTggLT4gSVJRIDggTW9kZTowIEFjdGl2ZTowKQ0KKFhFTikg
WzIwMTItMDktMDMgMjA6NTU6MzVdIElPQVBJQ1swXTogU2V0IFBDSSByb3V0aW5nIGVudHJ5
ICg2LTEzIC0+IDB4ODggLT4gSVJRIDEzIE1vZGU6MCBBY3RpdmU6MCkNCihYRU4pIFsyMDEy
LTA5LTAzIDIwOjU1OjM1XSBJT0FQSUNbMV06IFNldCBQQ0kgcm91dGluZyBlbnRyeSAoNy0y
OCAtPiAweGEwIC0+IElSUSA1MiBNb2RlOjEgQWN0aXZlOjEpDQooWEVOKSBbMjAxMi0wOS0w
MyAyMDo1NTozNV0gSU9BUElDWzFdOiBTZXQgUENJIHJvdXRpbmcgZW50cnkgKDctMjkgLT4g
MHhhOCAtPiBJUlEgNTMgTW9kZToxIEFjdGl2ZToxKQ0KKFhFTikgWzIwMTItMDktMDMgMjA6
NTU6MzVdIElPQVBJQ1sxXTogU2V0IFBDSSByb3V0aW5nIGVudHJ5ICg3LTMwIC0+IDB4YjAg
LT4gSVJRIDU0IE1vZGU6MSBBY3RpdmU6MSkNCihYRU4pIFsyMDEyLTA5LTAzIDIwOjU1OjM1
XSBJT0FQSUNbMF06IFNldCBQQ0kgcm91dGluZyBlbnRyeSAoNi0xNiAtPiAweGI4IC0+IElS
USAxNiBNb2RlOjEgQWN0aXZlOjEpDQooWEVOKSBbMjAxMi0wOS0wMyAyMDo1NTozNV0gSU9B
UElDWzBdOiBTZXQgUENJIHJvdXRpbmcgZW50cnkgKDYtMTggLT4gMHhjMCAtPiBJUlEgMTgg
TW9kZToxIEFjdGl2ZToxKQ0KKFhFTikgWzIwMTItMDktMDMgMjA6NTU6MzVdIElPQVBJQ1sw
XTogU2V0IFBDSSByb3V0aW5nIGVudHJ5ICg2LTE3IC0+IDB4YzggLT4gSVJRIDE3IE1vZGU6
MSBBY3RpdmU6MSkNCihYRU4pIFsyMDEyLTA5LTAzIDIwOjU1OjM1XSBJT0FQSUNbMV06IFNl
dCBQQ0kgcm91dGluZyBlbnRyeSAoNy00IC0+IDB4ZDAgLT4gSVJRIDI4IE1vZGU6MSBBY3Rp
dmU6MSkNCihYRU4pIFsyMDEyLTA5LTAzIDIwOjU1OjM1XSBJT0FQSUNbMV06IFNldCBQQ0kg
cm91dGluZyBlbnRyeSAoNy01IC0+IDB4ZDggLT4gSVJRIDI5IE1vZGU6MSBBY3RpdmU6MSkN
CihYRU4pIFsyMDEyLTA5LTAzIDIwOjU1OjM1XSBJT0FQSUNbMV06IFNldCBQQ0kgcm91dGlu
ZyBlbnRyeSAoNy02IC0+IDB4MjEgLT4gSVJRIDMwIE1vZGU6MSBBY3RpdmU6MSkNCihYRU4p
IFsyMDEyLTA5LTAzIDIwOjU1OjM1XSBJT0FQSUNbMV06IFNldCBQQ0kgcm91dGluZyBlbnRy
eSAoNy03IC0+IDB4MjkgLT4gSVJRIDMxIE1vZGU6MSBBY3RpdmU6MSkNCihYRU4pIFsyMDEy
LTA5LTAzIDIwOjU1OjM1XSBJT0FQSUNbMV06IFNldCBQQ0kgcm91dGluZyBlbnRyeSAoNy0x
NiAtPiAweDMxIC0+IElSUSA0MCBNb2RlOjEgQWN0aXZlOjEpDQooWEVOKSBbMjAxMi0wOS0w
MyAyMDo1NTozNV0gSU9BUElDWzFdOiBTZXQgUENJIHJvdXRpbmcgZW50cnkgKDctMTcgLT4g
MHgzOSAtPiBJUlEgNDEgTW9kZToxIEFjdGl2ZToxKQ0KKFhFTikgWzIwMTItMDktMDMgMjA6
NTU6MzZdIElPQVBJQ1sxXTogU2V0IFBDSSByb3V0aW5nIGVudHJ5ICg3LTE4IC0+IDB4NDEg
LT4gSVJRIDQyIE1vZGU6MSBBY3RpdmU6MSkNCihYRU4pIFsyMDEyLTA5LTAzIDIwOjU1OjM2
XSBJT0FQSUNbMV06IFNldCBQQ0kgcm91dGluZyBlbnRyeSAoNy0xOSAtPiAweDQ5IC0+IElS
USA0MyBNb2RlOjEgQWN0aXZlOjEpDQooWEVOKSBbMjAxMi0wOS0wMyAyMDo1NTozNl0gSU9B
UElDWzBdOiBTZXQgUENJIHJvdXRpbmcgZW50cnkgKDYtMjIgLT4gMHg5OSAtPiBJUlEgMjIg
TW9kZToxIEFjdGl2ZToxKQ0KKFhFTikgWzIwMTItMDktMDMgMjA6NTU6MzZdIElPQVBJQ1sx
XTogU2V0IFBDSSByb3V0aW5nIGVudHJ5ICg3LTEyIC0+IDB4YTEgLT4gSVJRIDM2IE1vZGU6
MSBBY3RpdmU6MSkNCihYRU4pIFsyMDEyLTA5LTAzIDIwOjU1OjM2XSBJT0FQSUNbMV06IFNl
dCBQQ0kgcm91dGluZyBlbnRyeSAoNy0yMyAtPiAweGE5IC0+IElSUSA0NyBNb2RlOjEgQWN0
aXZlOjEpDQooWEVOKSBbMjAxMi0wOS0wMyAyMDo1NTozNl0gSU9BUElDWzBdOiBTZXQgUENJ
IHJvdXRpbmcgZW50cnkgKDYtMTkgLT4gMHhiMSAtPiBJUlEgMTkgTW9kZToxIEFjdGl2ZTox
KQ0KKFhFTikgWzIwMTItMDktMDMgMjA6NTU6MzZdIElPQVBJQ1sxXTogU2V0IFBDSSByb3V0
aW5nIGVudHJ5ICg3LTIyIC0+IDB4YzEgLT4gSVJRIDQ2IE1vZGU6MSBBY3RpdmU6MSkNCihY
RU4pIFsyMDEyLTA5LTAzIDIwOjU1OjM2XSBJT0FQSUNbMV06IFNldCBQQ0kgcm91dGluZyBl
bnRyeSAoNy0yNyAtPiAweGQxIC0+IElSUSA1MSBNb2RlOjEgQWN0aXZlOjEpDQooWEVOKSBb
MjAxMi0wOS0wMyAyMDo1NTozOF0gSU9BUElDWzFdOiBTZXQgUENJIHJvdXRpbmcgZW50cnkg
KDctOSAtPiAweDIyIC0+IElSUSAzMyBNb2RlOjEgQWN0aXZlOjEpDQooWEVOKSBbMjAxMi0w
OS0wMyAyMDo1NjozN10gdHJhcHMuYzoyNTg0OmQxIERvbWFpbiBhdHRlbXB0ZWQgV1JNU1Ig
MDAwMDAwMDBjMDAxMDAwNCBmcm9tIDB4MDAwMDQyMzQ1YTBkYTU0NSB0byAweDAwMDAwMDAw
MDAwMGFiY2QuDQooWEVOKSBbMjAxMi0wOS0wMyAyMDo1Njo0M10gdHJhcHMuYzoyNTg0OmQy
IERvbWFpbiBhdHRlbXB0ZWQgV1JNU1IgMDAwMDAwMDBjMDAxMDAwNCBmcm9tIDB4MDAwMDg2
NzljMDJiNDE2NSB0byAweDAwMDAwMDAwMDAwMGFiY2QuDQooWEVOKSBbMjAxMi0wOS0wMyAy
MDo1Njo1NV0gdHJhcHMuYzoyNTg0OmQzIERvbWFpbiBhdHRlbXB0ZWQgV1JNU1IgMDAwMDAw
MDBjMDAxMDAwNCBmcm9tIDB4MDAwMDQyMzQ1YTBkYTU0NSB0byAweDAwMDAwMDAwMDAwMGFi
Y2QuDQooWEVOKSBbMjAxMi0wOS0wMyAyMDo1Njo1NV0gdHJhcHMuYzoyNTg0OmQ0IERvbWFp
biBhdHRlbXB0ZWQgV1JNU1IgMDAwMDAwMDBjMDAxMDAwNCBmcm9tIDB4MDAwMDg2NzljMDJi
NDE2NSB0byAweDAwMDAwMDAwMDAwMGFiY2QuDQooWEVOKSBbMjAxMi0wOS0wMyAyMDo1Nzow
M10gdHJhcHMuYzoyNTg0OmQ1IERvbWFpbiBhdHRlbXB0ZWQgV1JNU1IgMDAwMDAwMDBjMDAx
MDAwNCBmcm9tIDB4MDAwMDg2NzljMDJiNDE2NSB0byAweDAwMDAwMDAwMDAwMGFiY2QuDQoo
WEVOKSBbMjAxMi0wOS0wMyAyMDo1NzowOV0gdHJhcHMuYzoyNTg0OmQ2IERvbWFpbiBhdHRl
bXB0ZWQgV1JNU1IgMDAwMDAwMDBjMDAxMDAwNCBmcm9tIDB4MDAwMDZmYjAzOWRlNzkwMCB0
byAweDAwMDAwMDAwMDAwMGFiY2QuDQooWEVOKSBbMjAxMi0wOS0wMyAyMDo1NzoxNV0gdHJh
cHMuYzoyNTg0OmQ3IERvbWFpbiBhdHRlbXB0ZWQgV1JNU1IgMDAwMDAwMDBjMDAxMDAwNCBm
cm9tIDB4MDAwMGExOTVjNDBmNjE4ZiB0byAweDAwMDAwMDAwMDAwMGFiY2QuDQooWEVOKSBb
MjAxMi0wOS0wMyAyMDo1NzoyMl0gdHJhcHMuYzoyNTg0OmQ4IERvbWFpbiBhdHRlbXB0ZWQg
V1JNU1IgMDAwMDAwMDBjMDAxMDAwNCBmcm9tIDB4MDAwMDZmYjAzOWRlNzkwMCB0byAweDAw
MDAwMDAwMDAwMGFiY2QuDQooWEVOKSBbMjAxMi0wOS0wMyAyMDo1NzoyOF0gdHJhcHMuYzoy
NTg0OmQ5IERvbWFpbiBhdHRlbXB0ZWQgV1JNU1IgMDAwMDAwMDBjMDAxMDAwNCBmcm9tIDB4
MDAwMDQyMzQ1YTBkYTU0NSB0byAweDAwMDAwMDAwMDAwMGFiY2QuDQooWEVOKSBbMjAxMi0w
OS0wMyAyMDo1NzozNV0gdHJhcHMuYzoyNTg0OmQxMCBEb21haW4gYXR0ZW1wdGVkIFdSTVNS
IDAwMDAwMDAwYzAwMTAwMDQgZnJvbSAweDAwMDA0MjM0NWEwZGE1NDUgdG8gMHgwMDAwMDAw
MDAwMDBhYmNkLg0KKFhFTikgWzIwMTItMDktMDMgMjA6NTc6NDFdIEFNRC1WaTogRGlzYWJs
ZTogZGV2aWNlIGlkID0gMHgwMGE0LCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMNCihY
RU4pIFsyMDEyLTA5LTAzIDIwOjU3OjQxXSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxl
OiBkZXZpY2UgaWQgPSAweDAwYTQsIHJvb3QgdGFibGUgPSAweDE4ZTBhMTAwMCwgZG9tYWlu
ID0gMTEsIHBhZ2luZyBtb2RlID0gMw0KKFhFTikgWzIwMTItMDktMDMgMjA6NTc6NDFdIEFN
RC1WaTogUmUtYXNzaWduIDAwMDA6MDM6MDYuMCBmcm9tIGRvbTAgdG8gZG9tMTENCihYRU4p
IFsyMDEyLTA5LTAzIDIwOjU3OjQxXSB0cmFwcy5jOjI1ODQ6ZDExIERvbWFpbiBhdHRlbXB0
ZWQgV1JNU1IgMDAwMDAwMDBjMDAxMDAwNCBmcm9tIDB4MDAwMDg2NzljMDJiNDE2NSB0byAw
eDAwMDAwMDAwMDAwMGFiY2QuDQooWEVOKSBbMjAxMi0wOS0wMyAyMDo1Nzo1Ml0gdHJhcHMu
YzoyNTg0OmQxMiBEb21haW4gYXR0ZW1wdGVkIFdSTVNSIDAwMDAwMDAwYzAwMTAwMDQgZnJv
bSAweDAwMDBhMTk1YzQwZjYxOGYgdG8gMHgwMDAwMDAwMDAwMDBhYmNkLg0KKFhFTikgWzIw
MTItMDktMDMgMjA6NTc6NThdIHRyYXBzLmM6MjU4NDpkMTMgRG9tYWluIGF0dGVtcHRlZCBX
Uk1TUiAwMDAwMDAwMGMwMDEwMDA0IGZyb20gMHgwMDAwODY3OWMwMmI0MTY1IHRvIDB4MDAw
MDAwMDAwMDAwYWJjZC4NCihYRU4pIFsyMDEyLTA5LTAzIDIwOjU4OjA2XSBBTUQtVmk6IERp
c2FibGU6IGRldmljZSBpZCA9IDB4MGEwMCwgZG9tYWluID0gMCwgcGFnaW5nIG1vZGUgPSAz
DQooWEVOKSBbMjAxMi0wOS0wMyAyMDo1ODowNl0gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0
YWJsZTogZGV2aWNlIGlkID0gMHgwYTAwLCByb290IHRhYmxlID0gMHgxZTFmYzAwMDAsIGRv
bWFpbiA9IDE0LCBwYWdpbmcgbW9kZSA9IDMNCihYRU4pIFsyMDEyLTA5LTAzIDIwOjU4OjA2
XSBBTUQtVmk6IFJlLWFzc2lnbiAwMDAwOjBhOjAwLjAgZnJvbSBkb20wIHRvIGRvbTE0DQoo
WEVOKSBbMjAxMi0wOS0wMyAyMDo1ODowNl0gQU1ELVZpOiBEaXNhYmxlOiBkZXZpY2UgaWQg
PSAweDBhMDEsIGRvbWFpbiA9IDAsIHBhZ2luZyBtb2RlID0gMw0KKFhFTikgWzIwMTItMDkt
MDMgMjA6NTg6MDZdIEFNRC1WaTogU2V0dXAgSS9PIHBhZ2UgdGFibGU6IGRldmljZSBpZCA9
IDB4MGEwMSwgcm9vdCB0YWJsZSA9IDB4MWUxZmMwMDAwLCBkb21haW4gPSAxNCwgcGFnaW5n
IG1vZGUgPSAzDQooWEVOKSBbMjAxMi0wOS0wMyAyMDo1ODowNl0gQU1ELVZpOiBSZS1hc3Np
Z24gMDAwMDowYTowMC4xIGZyb20gZG9tMCB0byBkb20xNA0KKFhFTikgWzIwMTItMDktMDMg
MjA6NTg6MDZdIEFNRC1WaTogRGlzYWJsZTogZGV2aWNlIGlkID0gMHgwYTAyLCBkb21haW4g
PSAwLCBwYWdpbmcgbW9kZSA9IDMNCihYRU4pIFsyMDEyLTA5LTAzIDIwOjU4OjA2XSBBTUQt
Vmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweDBhMDIsIHJvb3QgdGFi
bGUgPSAweDFlMWZjMDAwMCwgZG9tYWluID0gMTQsIHBhZ2luZyBtb2RlID0gMw0KKFhFTikg
WzIwMTItMDktMDMgMjA6NTg6MDZdIEFNRC1WaTogUmUtYXNzaWduIDAwMDA6MGE6MDAuMiBm
cm9tIGRvbTAgdG8gZG9tMTQNCihYRU4pIFsyMDEyLTA5LTAzIDIwOjU4OjA2XSBBTUQtVmk6
IERpc2FibGU6IGRldmljZSBpZCA9IDB4MGEwMywgZG9tYWluID0gMCwgcGFnaW5nIG1vZGUg
PSAzDQooWEVOKSBbMjAxMi0wOS0wMyAyMDo1ODowNl0gQU1ELVZpOiBTZXR1cCBJL08gcGFn
ZSB0YWJsZTogZGV2aWNlIGlkID0gMHgwYTAzLCByb290IHRhYmxlID0gMHgxZTFmYzAwMDAs
IGRvbWFpbiA9IDE0LCBwYWdpbmcgbW9kZSA9IDMNCihYRU4pIFsyMDEyLTA5LTAzIDIwOjU4
OjA2XSBBTUQtVmk6IFJlLWFzc2lnbiAwMDAwOjBhOjAwLjMgZnJvbSBkb20wIHRvIGRvbTE0
DQooWEVOKSBbMjAxMi0wOS0wMyAyMDo1ODowNl0gQU1ELVZpOiBEaXNhYmxlOiBkZXZpY2Ug
aWQgPSAweDBhMDQsIGRvbWFpbiA9IDAsIHBhZ2luZyBtb2RlID0gMw0KKFhFTikgWzIwMTIt
MDktMDMgMjA6NTg6MDZdIEFNRC1WaTogU2V0dXAgSS9PIHBhZ2UgdGFibGU6IGRldmljZSBp
ZCA9IDB4MGEwNCwgcm9vdCB0YWJsZSA9IDB4MWUxZmMwMDAwLCBkb21haW4gPSAxNCwgcGFn
aW5nIG1vZGUgPSAzDQooWEVOKSBbMjAxMi0wOS0wMyAyMDo1ODowNl0gQU1ELVZpOiBSZS1h
c3NpZ24gMDAwMDowYTowMC40IGZyb20gZG9tMCB0byBkb20xNA0KKFhFTikgWzIwMTItMDkt
MDMgMjA6NTg6MDZdIEFNRC1WaTogRGlzYWJsZTogZGV2aWNlIGlkID0gMHgwYTA1LCBkb21h
aW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMNCihYRU4pIFsyMDEyLTA5LTAzIDIwOjU4OjA2XSBB
TUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweDBhMDUsIHJvb3Qg
dGFibGUgPSAweDFlMWZjMDAwMCwgZG9tYWluID0gMTQsIHBhZ2luZyBtb2RlID0gMw0KKFhF
TikgWzIwMTItMDktMDMgMjA6NTg6MDZdIEFNRC1WaTogUmUtYXNzaWduIDAwMDA6MGE6MDAu
NSBmcm9tIGRvbTAgdG8gZG9tMTQNCihYRU4pIFsyMDEyLTA5LTAzIDIwOjU4OjA2XSBBTUQt
Vmk6IERpc2FibGU6IGRldmljZSBpZCA9IDB4MGEwNiwgZG9tYWluID0gMCwgcGFnaW5nIG1v
ZGUgPSAzDQooWEVOKSBbMjAxMi0wOS0wMyAyMDo1ODowNl0gQU1ELVZpOiBTZXR1cCBJL08g
cGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHgwYTA2LCByb290IHRhYmxlID0gMHgxZTFmYzAw
MDAsIGRvbWFpbiA9IDE0LCBwYWdpbmcgbW9kZSA9IDMNCihYRU4pIFsyMDEyLTA5LTAzIDIw
OjU4OjA2XSBBTUQtVmk6IFJlLWFzc2lnbiAwMDAwOjBhOjAwLjYgZnJvbSBkb20wIHRvIGRv
bTE0DQooWEVOKSBbMjAxMi0wOS0wMyAyMDo1ODowNl0gQU1ELVZpOiBEaXNhYmxlOiBkZXZp
Y2UgaWQgPSAweDBhMDcsIGRvbWFpbiA9IDAsIHBhZ2luZyBtb2RlID0gMw0KKFhFTikgWzIw
MTItMDktMDMgMjA6NTg6MDZdIEFNRC1WaTogU2V0dXAgSS9PIHBhZ2UgdGFibGU6IGRldmlj
ZSBpZCA9IDB4MGEwNywgcm9vdCB0YWJsZSA9IDB4MWUxZmMwMDAwLCBkb21haW4gPSAxNCwg
cGFnaW5nIG1vZGUgPSAzDQooWEVOKSBbMjAxMi0wOS0wMyAyMDo1ODowNl0gQU1ELVZpOiBS
ZS1hc3NpZ24gMDAwMDowYTowMC43IGZyb20gZG9tMCB0byBkb20xNA0KKFhFTikgWzIwMTIt
MDktMDMgMjA6NTg6MDZdIEFNRC1WaTogRGlzYWJsZTogZGV2aWNlIGlkID0gMHgwNzAwLCBk
b21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMNCihYRU4pIFsyMDEyLTA5LTAzIDIwOjU4OjA2
XSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweDA3MDAsIHJv
b3QgdGFibGUgPSAweDFlMWZjMDAwMCwgZG9tYWluID0gMTQsIHBhZ2luZyBtb2RlID0gMw0K
KFhFTikgWzIwMTItMDktMDMgMjA6NTg6MDZdIEFNRC1WaTogUmUtYXNzaWduIDAwMDA6MDc6
MDAuMCBmcm9tIGRvbTAgdG8gZG9tMTQNCihYRU4pIFsyMDEyLTA5LTAzIDIwOjU4OjA2XSB0
cmFwcy5jOjI1ODQ6ZDE0IERvbWFpbiBhdHRlbXB0ZWQgV1JNU1IgMDAwMDAwMDBjMDAxMDAw
NCBmcm9tIDB4MDAwMDc4NTE5MGZiNGUwZiB0byAweDAwMDAwMDAwMDAwMGFiY2QuDQooWEVO
KSBbMjAxMi0wOS0wMyAyMDo1ODoxNl0gQU1ELVZpOiBTaGFyZSBwMm0gdGFibGUgd2l0aCBp
b21tdTogcDJtIHRhYmxlID0gMHhhNzdhOA0KKFhFTikgWzIwMTItMDktMDMgMjA6NTg6MTld
IEhWTTE1OiBIVk0gTG9hZGVyDQooWEVOKSBbMjAxMi0wOS0wMyAyMDo1ODoxOV0gSFZNMTU6
IERldGVjdGVkIFhlbiB2NC4yLjAtcmM0LXByZQ0KKFhFTikgWzIwMTItMDktMDMgMjA6NTg6
MTldIEhWTTE1OiBYZW5idXMgcmluZ3MgQDB4ZmVmZmMwMDAsIGV2ZW50IGNoYW5uZWwgNA0K
KFhFTikgWzIwMTItMDktMDMgMjA6NTg6MTldIEhWTTE1OiBTeXN0ZW0gcmVxdWVzdGVkIFJP
TUJJT1MNCihYRU4pIFsyMDEyLTA5LTAzIDIwOjU4OjE5XSBIVk0xNTogQ1BVIHNwZWVkIGlz
IDMyMDAgTUh6DQooWEVOKSBbMjAxMi0wOS0wMyAyMDo1ODoxOV0gaXJxLmM6MjcwOiBEb20x
NSBQQ0kgbGluayAwIGNoYW5nZWQgMCAtPiA1DQooWEVOKSBbMjAxMi0wOS0wMyAyMDo1ODox
OV0gSFZNMTU6IFBDSS1JU0EgbGluayAwIHJvdXRlZCB0byBJUlE1DQooWEVOKSBbMjAxMi0w
OS0wMyAyMDo1ODoxOV0gaXJxLmM6MjcwOiBEb20xNSBQQ0kgbGluayAxIGNoYW5nZWQgMCAt
PiAxMA0KKFhFTikgWzIwMTItMDktMDMgMjA6NTg6MTldIEhWTTE1OiBQQ0ktSVNBIGxpbmsg
MSByb3V0ZWQgdG8gSVJRMTANCihYRU4pIFsyMDEyLTA5LTAzIDIwOjU4OjE5XSBpcnEuYzoy
NzA6IERvbTE1IFBDSSBsaW5rIDIgY2hhbmdlZCAwIC0+IDExDQooWEVOKSBbMjAxMi0wOS0w
MyAyMDo1ODoxOV0gSFZNMTU6IFBDSS1JU0EgbGluayAyIHJvdXRlZCB0byBJUlExMQ0KKFhF
TikgWzIwMTItMDktMDMgMjA6NTg6MTldIGlycS5jOjI3MDogRG9tMTUgUENJIGxpbmsgMyBj
aGFuZ2VkIDAgLT4gNQ0KKFhFTikgWzIwMTItMDktMDMgMjA6NTg6MTldIEhWTTE1OiBQQ0kt
SVNBIGxpbmsgMyByb3V0ZWQgdG8gSVJRNQ0KKFhFTikgWzIwMTItMDktMDMgMjA6NTg6MTld
IEhWTTE1OiBwY2kgZGV2IDAxOjIgSU5URC0+SVJRNQ0KKFhFTikgWzIwMTItMDktMDMgMjA6
NTg6MTldIEhWTTE1OiBwY2kgZGV2IDAxOjMgSU5UQS0+SVJRMTANCihYRU4pIFsyMDEyLTA5
LTAzIDIwOjU4OjE5XSBIVk0xNTogcGNpIGRldiAwMzowIElOVEEtPklSUTUNCihYRU4pIFsy
MDEyLTA5LTAzIDIwOjU4OjE5XSBIVk0xNTogcGNpIGRldiAwNDowIElOVEEtPklSUTUNCihY
RU4pIFsyMDEyLTA5LTAzIDIwOjU4OjE5XSBIVk0xNTogcGNpIGRldiAwMjowIGJhciAxMCBz
aXplIDAyMDAwMDAwOiBmMDAwMDAwOA0KKFhFTikgWzIwMTItMDktMDMgMjA6NTg6MTldIEhW
TTE1OiBwY2kgZGV2IDAzOjAgYmFyIDE0IHNpemUgMDEwMDAwMDA6IGYyMDAwMDA4DQooWEVO
KSBbMjAxMi0wOS0wMyAyMDo1ODoxOV0gSFZNMTU6IHBjaSBkZXYgMDQ6MCBiYXIgMTAgc2l6
ZSAwMDAyMDAwMDogZjMwMDAwMDANCihYRU4pIFsyMDEyLTA5LTAzIDIwOjU4OjE5XSBIVk0x
NTogcGNpIGRldiAwMjowIGJhciAxNCBzaXplIDAwMDAxMDAwOiBmMzAyMDAwMA0KKFhFTikg
WzIwMTItMDktMDMgMjA6NTg6MTldIEhWTTE1OiBwY2kgZGV2IDAzOjAgYmFyIDEwIHNpemUg
MDAwMDAxMDA6IDAwMDBjMDAxDQooWEVOKSBbMjAxMi0wOS0wMyAyMDo1ODoxOV0gSFZNMTU6
IHBjaSBkZXYgMDQ6MCBiYXIgMTQgc2l6ZSAwMDAwMDA0MDogMDAwMGMxMDENCihYRU4pIFsy
MDEyLTA5LTAzIDIwOjU4OjE5XSBIVk0xNTogcGNpIGRldiAwMToyIGJhciAyMCBzaXplIDAw
MDAwMDIwOiAwMDAwYzE0MQ0KKFhFTikgWzIwMTItMDktMDMgMjA6NTg6MTldIEhWTTE1OiBw
Y2kgZGV2IDAxOjEgYmFyIDIwIHNpemUgMDAwMDAwMTA6IDAwMDBjMTYxDQooWEVOKSBbMjAx
Mi0wOS0wMyAyMDo1ODoxOV0gSFZNMTU6IE11bHRpcHJvY2Vzc29yIGluaXRpYWxpc2F0aW9u
Og0KKFhFTikgWzIwMTItMDktMDMgMjA6NTg6MTldIEhWTTE1OiAgLSBDUFUwIC4uLiA0OC1i
aXQgcGh5cyAuLi4gZml4ZWQgTVRSUnMgLi4uIHZhciBNVFJScyBbMi84XSAuLi4gZG9uZS4N
CihYRU4pIFsyMDEyLTA5LTAzIDIwOjU4OjE5XSBIVk0xNTogIC0gQ1BVMSAuLi4gNDgtYml0
IHBoeXMgLi4uIGZpeGVkIE1UUlJzIC4uLiB2YXIgTVRSUnMgWzIvOF0gLi4uIGRvbmUuDQoo
WEVOKSBbMjAxMi0wOS0wMyAyMDo1ODoxOV0gSFZNMTU6IFRlc3RpbmcgSFZNIGVudmlyb25t
ZW50Og0KKFhFTikgWzIwMTItMDktMDMgMjA6NTg6MTldIEhWTTE1OiAgLSBSRVAgSU5TQiBh
Y3Jvc3MgcGFnZSBib3VuZGFyaWVzIC4uLiBwYXNzZWQNCihYRU4pIFsyMDEyLTA5LTAzIDIw
OjU4OjE5XSBIVk0xNTogIC0gR1MgYmFzZSBNU1JzIGFuZCBTV0FQR1MgLi4uIHBhc3NlZA0K
KFhFTikgWzIwMTItMDktMDMgMjA6NTg6MTldIEhWTTE1OiBQYXNzZWQgMiBvZiAyIHRlc3Rz
DQooWEVOKSBbMjAxMi0wOS0wMyAyMDo1ODoxOV0gSFZNMTU6IFdyaXRpbmcgU01CSU9TIHRh
YmxlcyAuLi4NCihYRU4pIFsyMDEyLTA5LTAzIDIwOjU4OjE5XSBIVk0xNTogTG9hZGluZyBS
T01CSU9TIC4uLg0KKFhFTikgWzIwMTItMDktMDMgMjA6NTg6MTldIEhWTTE1OiA5NjYwIGJ5
dGVzIG9mIFJPTUJJT1MgaGlnaC1tZW1vcnkgZXh0ZW5zaW9uczoNCihYRU4pIFsyMDEyLTA5
LTAzIDIwOjU4OjE5XSBIVk0xNTogICBSZWxvY2F0aW5nIHRvIDB4ZmMwMDEwMDAtMHhmYzAw
MzViYyAuLi4gZG9uZQ0KKFhFTikgWzIwMTItMDktMDMgMjA6NTg6MTldIEhWTTE1OiBDcmVh
dGluZyBNUCB0YWJsZXMgLi4uDQooWEVOKSBbMjAxMi0wOS0wMyAyMDo1ODoxOV0gSFZNMTU6
IExvYWRpbmcgQ2lycnVzIFZHQUJJT1MgLi4uDQooWEVOKSBbMjAxMi0wOS0wMyAyMDo1ODox
OV0gSFZNMTU6IExvYWRpbmcgUENJIE9wdGlvbiBST00gLi4uDQooWEVOKSBbMjAxMi0wOS0w
MyAyMDo1ODoxOV0gSFZNMTU6ICAtIE1hbnVmYWN0dXJlcjogaHR0cDovL2lweGUub3JnDQoo
WEVOKSBbMjAxMi0wOS0wMyAyMDo1ODoxOV0gSFZNMTU6ICAtIFByb2R1Y3QgbmFtZTogaVBY
RQ0KKFhFTikgWzIwMTItMDktMDMgMjA6NTg6MTldIEhWTTE1OiBPcHRpb24gUk9NczoNCihY
RU4pIFsyMDEyLTA5LTAzIDIwOjU4OjE5XSBIVk0xNTogIGMwMDAwLWM4ZmZmOiBWR0EgQklP
Uw0KKFhFTikgWzIwMTItMDktMDMgMjA6NTg6MTldIEhWTTE1OiAgYzkwMDAtZDlmZmY6IEV0
aGVyYm9vdCBST00NCihYRU4pIFsyMDEyLTA5LTAzIDIwOjU4OjE5XSBIVk0xNTogTG9hZGlu
ZyBBQ1BJIC4uLg0KKFhFTikgWzIwMTItMDktMDMgMjA6NTg6MTldIEhWTTE1OiB2bTg2IFRT
UyBhdCBmYzAwZjY4MA0KKFhFTikgWzIwMTItMDktMDMgMjA6NTg6MTldIEhWTTE1OiBCSU9T
IG1hcDoNCihYRU4pIFsyMDEyLTA5LTAzIDIwOjU4OjE5XSBIVk0xNTogIGYwMDAwLWZmZmZm
OiBNYWluIEJJT1MNCihYRU4pIFsyMDEyLTA5LTAzIDIwOjU4OjE5XSBIVk0xNTogRTgyMCB0
YWJsZToNCihYRU4pIFsyMDEyLTA5LTAzIDIwOjU4OjE5XSBIVk0xNTogIFswMF06IDAwMDAw
MDAwOjAwMDAwMDAwIC0gMDAwMDAwMDA6MDAwOWUwMDA6IFJBTQ0KKFhFTikgWzIwMTItMDkt
MDMgMjA6NTg6MTldIEhWTTE1OiAgWzAxXTogMDAwMDAwMDA6MDAwOWUwMDAgLSAwMDAwMDAw
MDowMDBhMDAwMDogUkVTRVJWRUQNCihYRU4pIFsyMDEyLTA5LTAzIDIwOjU4OjE5XSBIVk0x
NTogIEhPTEU6IDAwMDAwMDAwOjAwMGEwMDAwIC0gMDAwMDAwMDA6MDAwZTAwMDANCihYRU4p
IFsyMDEyLTA5LTAzIDIwOjU4OjE5XSBIVk0xNTogIFswMl06IDAwMDAwMDAwOjAwMGUwMDAw
IC0gMDAwMDAwMDA6MDAxMDAwMDA6IFJFU0VSVkVEDQooWEVOKSBbMjAxMi0wOS0wMyAyMDo1
ODoxOV0gSFZNMTU6ICBbMDNdOiAwMDAwMDAwMDowMDEwMDAwMCAtIDAwMDAwMDAwOjFmODAw
MDAwOiBSQU0NCihYRU4pIFsyMDEyLTA5LTAzIDIwOjU4OjE5XSBIVk0xNTogIEhPTEU6IDAw
MDAwMDAwOjFmODAwMDAwIC0gMDAwMDAwMDA6ZmMwMDAwMDANCihYRU4pIFsyMDEyLTA5LTAz
IDIwOjU4OjE5XSBIVk0xNTogIFswNF06IDAwMDAwMDAwOmZjMDAwMDAwIC0gMDAwMDAwMDE6
MDAwMDAwMDA6IFJFU0VSVkVEDQooWEVOKSBbMjAxMi0wOS0wMyAyMDo1ODoxOV0gSFZNMTU6
IEludm9raW5nIFJPTUJJT1MgLi4uDQooWEVOKSBbMjAxMi0wOS0wMyAyMDo1ODoxOV0gSFZN
MTU6ICRSZXZpc2lvbjogMS4yMjEgJCAkRGF0ZTogMjAwOC8xMi8wNyAxNzozMjoyOSAkDQoo
WEVOKSBbMjAxMi0wOS0wMyAyMDo1ODoyMF0gc3RkdmdhLmM6MTQ3OmQxNSBlbnRlcmluZyBz
dGR2Z2EgYW5kIGNhY2hpbmcgbW9kZXMNCihYRU4pIFsyMDEyLTA5LTAzIDIwOjU4OjIwXSBI
Vk0xNTogVkdBQmlvcyAkSWQ6IHZnYWJpb3MuYyx2IDEuNjcgMjAwOC8wMS8yNyAwOTo0NDox
MiB2cnVwcGVydCBFeHAgJA0KKFhFTikgWzIwMTItMDktMDMgMjA6NTg6MjBdIEhWTTE1OiBC
b2NocyBCSU9TIC0gYnVpbGQ6IDA2LzIzLzk5DQooWEVOKSBbMjAxMi0wOS0wMyAyMDo1ODoy
MF0gSFZNMTU6ICRSZXZpc2lvbjogMS4yMjEgJCAkRGF0ZTogMjAwOC8xMi8wNyAxNzozMjoy
OSAkDQooWEVOKSBbMjAxMi0wOS0wMyAyMDo1ODoyMF0gSFZNMTU6IE9wdGlvbnM6IGFwbWJp
b3MgcGNpYmlvcyBlbHRvcml0byBQTU0gDQooWEVOKSBbMjAxMi0wOS0wMyAyMDo1ODoyMF0g
SFZNMTU6IA0KKFhFTikgWzIwMTItMDktMDMgMjA6NTg6MjBdIEhWTTE1OiBhdGEwLTA6IFBD
SFM9MTYzODMvMTYvNjMgdHJhbnNsYXRpb249bGJhIExDSFM9MTAyNC8yNTUvNjMNCihYRU4p
IFsyMDEyLTA5LTAzIDIwOjU4OjIwXSBIVk0xNTogYXRhMCBtYXN0ZXI6IFFFTVUgSEFSRERJ
U0sgQVRBLTcgSGFyZC1EaXNrICg1NzI0NCBNQnl0ZXMpDQooWEVOKSBbMjAxMi0wOS0wMyAy
MDo1ODoyMV0gSFZNMTU6IElERSB0aW1lIG91dA0KKFhFTikgWzIwMTItMDktMDMgMjA6NTg6
MjFdIEhWTTE1OiBhdGExIG1hc3RlcjogUUVNVSBEVkQtUk9NIEFUQVBJLTQgQ0QtUm9tL0RW
RC1Sb20NCihYRU4pIFsyMDEyLTA5LTAzIDIwOjU4OjIzXSBIVk0xNTogSURFIHRpbWUgb3V0
DQooWEVOKSBbMjAxMi0wOS0wMyAyMDo1ODoyM10gSFZNMTU6IA0KKFhFTikgWzIwMTItMDkt
MDMgMjA6NTg6MjNdIEhWTTE1OiANCihYRU4pIFsyMDEyLTA5LTAzIDIwOjU4OjIzXSBIVk0x
NTogDQooWEVOKSBbMjAxMi0wOS0wMyAyMDo1ODoyM10gSFZNMTU6IFByZXNzIEYxMiBmb3Ig
Ym9vdCBtZW51Lg0KKFhFTikgWzIwMTItMDktMDMgMjA6NTg6MjNdIEhWTTE1OiANCihYRU4p
IFsyMDEyLTA5LTAzIDIwOjU4OjIzXSBIVk0xNTogQm9vdGluZyBmcm9tIEhhcmQgRGlzay4u
Lg0KKFhFTikgWzIwMTItMDktMDMgMjA6NTg6MjNdIEhWTTE1OiBCb290aW5nIGZyb20gMDAw
MDo3YzAwDQooWEVOKSBbMjAxMi0wOS0wMyAyMDo1ODoyNl0gdHJhcHMuYzoyNTg0OmQxNiBE
b21haW4gYXR0ZW1wdGVkIFdSTVNSIDAwMDAwMDAwYzAwMTAwMDQgZnJvbSAweDAwMDA0MjM0
NWEwZGE1NDUgdG8gMHgwMDAwMDAwMDAwMDBhYmNkLg0KKFhFTikgWzIwMTItMDktMDMgMjA6
NTg6NTBdIGlycS5jOjI3MDogRG9tMTUgUENJIGxpbmsgMCBjaGFuZ2VkIDUgLT4gMA0KKFhF
TikgWzIwMTItMDktMDMgMjA6NTg6NTBdIGlycS5jOjI3MDogRG9tMTUgUENJIGxpbmsgMSBj
aGFuZ2VkIDEwIC0+IDANCihYRU4pIFsyMDEyLTA5LTAzIDIwOjU4OjUwXSBpcnEuYzoyNzA6
IERvbTE1IFBDSSBsaW5rIDIgY2hhbmdlZCAxMSAtPiAwDQooWEVOKSBbMjAxMi0wOS0wMyAy
MDo1ODo1MF0gaXJxLmM6MjcwOiBEb20xNSBQQ0kgbGluayAzIGNoYW5nZWQgNSAtPiAwDQoo
WEVOKSBbMjAxMi0wOS0wMyAyMDo1ODo1MV0gaHZtLmM6MjQzNTpkMTUgZ3Vlc3QgYXR0ZW1w
dGVkIHdyaXRlIHRvIHJlYWQtb25seSBtZW1vcnkgcGFnZS4gZ2ZuPTB4ZGMsIG1mbj0weGE0
YTBiDQooWEVOKSBbMjAxMi0wOS0wMyAyMDo1ODo1MV0gaHZtLmM6MjQzNTpkMTUgZ3Vlc3Qg
YXR0ZW1wdGVkIHdyaXRlIHRvIHJlYWQtb25seSBtZW1vcnkgcGFnZS4gZ2ZuPTB4ZGQsIG1m
bj0weGE0YTBhDQooWEVOKSBbMjAxMi0wOS0wMyAyMDo1ODo1MV0gaHZtLmM6MjQzNTpkMTUg
Z3Vlc3QgYXR0ZW1wdGVkIHdyaXRlIHRvIHJlYWQtb25seSBtZW1vcnkgcGFnZS4gZ2ZuPTB4
ZGUsIG1mbj0weGE0YTA5DQooWEVOKSBbMjAxMi0wOS0wMyAyMDo1ODo1MV0gaHZtLmM6MjQz
NTpkMTUgZ3Vlc3QgYXR0ZW1wdGVkIHdyaXRlIHRvIHJlYWQtb25seSBtZW1vcnkgcGFnZS4g
Z2ZuPTB4ZGQsIG1mbj0weGE0YTBhDQooWEVOKSBbMjAxMi0wOS0wMyAyMDo1ODo1MV0gaHZt
LmM6MjQzNTpkMTUgZ3Vlc3QgYXR0ZW1wdGVkIHdyaXRlIHRvIHJlYWQtb25seSBtZW1vcnkg
cGFnZS4gZ2ZuPTB4ZGMsIG1mbj0weGE0YTBiDQooWEVOKSBbMjAxMi0wOS0wMyAyMDo1ODo1
MV0gaHZtLmM6MjQzNTpkMTUgZ3Vlc3QgYXR0ZW1wdGVkIHdyaXRlIHRvIHJlYWQtb25seSBt
ZW1vcnkgcGFnZS4gZ2ZuPTB4ZGUsIG1mbj0weGE0YTA5DQooWEVOKSBbMjAxMi0wOS0wMyAy
MDo1ODo1MV0gaHZtLmM6MjQzNTpkMTUgZ3Vlc3QgYXR0ZW1wdGVkIHdyaXRlIHRvIHJlYWQt
b25seSBtZW1vcnkgcGFnZS4gZ2ZuPTB4ZGQsIG1mbj0weGE0YTBhDQooWEVOKSBbMjAxMi0w
OS0wMyAyMDo1ODo1MV0gaHZtLmM6MjQzNTpkMTUgZ3Vlc3QgYXR0ZW1wdGVkIHdyaXRlIHRv
IHJlYWQtb25seSBtZW1vcnkgcGFnZS4gZ2ZuPTB4ZGUsIG1mbj0weGE0YTA5DQooWEVOKSBb
MjAxMi0wOS0wMyAyMDo1ODo1MV0gaHZtLmM6MjQzNTpkMTUgZ3Vlc3QgYXR0ZW1wdGVkIHdy
aXRlIHRvIHJlYWQtb25seSBtZW1vcnkgcGFnZS4gZ2ZuPTB4ZGMsIG1mbj0weGE0YTBiDQoo
WEVOKSBbMjAxMi0wOS0wMyAyMDo1ODo1MV0gaHZtLmM6MjQzNTpkMTUgZ3Vlc3QgYXR0ZW1w
dGVkIHdyaXRlIHRvIHJlYWQtb25seSBtZW1vcnkgcGFnZS4gZ2ZuPTB4ZGQsIG1mbj0weGE0
YTBhDQooWEVOKSBbMjAxMi0wOS0wMyAyMDo1ODo1MV0gaHZtLmM6MjQzNTpkMTUgZ3Vlc3Qg
YXR0ZW1wdGVkIHdyaXRlIHRvIHJlYWQtb25seSBtZW1vcnkgcGFnZS4gZ2ZuPTB4ZGMsIG1m
bj0weGE0YTBiDQooWEVOKSBbMjAxMi0wOS0wMyAyMDo1ODo1MV0gaHZtLmM6MjQzNTpkMTUg
Z3Vlc3QgYXR0ZW1wdGVkIHdyaXRlIHRvIHJlYWQtb25seSBtZW1vcnkgcGFnZS4gZ2ZuPTB4
ZGQsIG1mbj0weGE0YTBhDQooWEVOKSBbMjAxMi0wOS0wMyAyMDo1ODo1MV0gaHZtLmM6MjQz
NTpkMTUgZ3Vlc3QgYXR0ZW1wdGVkIHdyaXRlIHRvIHJlYWQtb25seSBtZW1vcnkgcGFnZS4g
Z2ZuPTB4ZGUsIG1mbj0weGE0YTA5DQooWEVOKSBbMjAxMi0wOS0wMyAyMDo1ODo1MV0gaHZt
LmM6MjQzNTpkMTUgZ3Vlc3QgYXR0ZW1wdGVkIHdyaXRlIHRvIHJlYWQtb25seSBtZW1vcnkg
cGFnZS4gZ2ZuPTB4ZGQsIG1mbj0weGE0YTBhDQooWEVOKSBbMjAxMi0wOS0wMyAyMDo1ODo1
MV0gaHZtLmM6MjQzNTpkMTUgZ3Vlc3QgYXR0ZW1wdGVkIHdyaXRlIHRvIHJlYWQtb25seSBt
ZW1vcnkgcGFnZS4gZ2ZuPTB4ZGMsIG1mbj0weGE0YTBiDQooWEVOKSBbMjAxMi0wOS0wMyAy
MDo1ODo1MV0gaHZtLmM6MjQzNTpkMTUgZ3Vlc3QgYXR0ZW1wdGVkIHdyaXRlIHRvIHJlYWQt
b25seSBtZW1vcnkgcGFnZS4gZ2ZuPTB4ZGQsIG1mbj0weGE0YTBhDQooWEVOKSBbMjAxMi0w
OS0wMyAyMDo1ODo1MV0gaHZtLmM6MjQzNTpkMTUgZ3Vlc3QgYXR0ZW1wdGVkIHdyaXRlIHRv
IHJlYWQtb25seSBtZW1vcnkgcGFnZS4gZ2ZuPTB4ZGMsIG1mbj0weGE0YTBiDQooWEVOKSBb
MjAxMi0wOS0wMyAyMDo1ODo1MV0gaHZtLmM6MjQzNTpkMTUgZ3Vlc3QgYXR0ZW1wdGVkIHdy
aXRlIHRvIHJlYWQtb25seSBtZW1vcnkgcGFnZS4gZ2ZuPTB4ZGQsIG1mbj0weGE0YTBhDQoo
WEVOKSBbMjAxMi0wOS0wMyAyMDo1ODo1NF0gaHZtLmM6MjQzNTpkMTUgZ3Vlc3QgYXR0ZW1w
dGVkIHdyaXRlIHRvIHJlYWQtb25seSBtZW1vcnkgcGFnZS4gZ2ZuPTB4YzksIG1mbj0weGE0
YTFlDQooWEVOKSBbMjAxMi0wOS0wMyAyMDo1ODo1NF0gaHZtLmM6MjQzNTpkMTUgZ3Vlc3Qg
YXR0ZW1wdGVkIHdyaXRlIHRvIHJlYWQtb25seSBtZW1vcnkgcGFnZS4gZ2ZuPTB4Y2IsIG1m
bj0weGE0YTFjDQooWEVOKSBbMjAxMi0wOS0wMyAyMDo1ODo1NF0gaHZtLmM6MjQzNTpkMTUg
Z3Vlc3QgYXR0ZW1wdGVkIHdyaXRlIHRvIHJlYWQtb25seSBtZW1vcnkgcGFnZS4gZ2ZuPTB4
Y2QsIG1mbj0weGE0YTFhDQooWEVOKSBbMjAxMi0wOS0wMyAyMDo1ODo1NF0gaHZtLmM6MjQz
NTpkMTUgZ3Vlc3QgYXR0ZW1wdGVkIHdyaXRlIHRvIHJlYWQtb25seSBtZW1vcnkgcGFnZS4g
Z2ZuPTB4Y2YsIG1mbj0weGE0YTE4DQooWEVOKSBbMjAxMi0wOS0wMyAyMDo1ODo1NF0gaHZt
LmM6MjQzNTpkMTUgZ3Vlc3QgYXR0ZW1wdGVkIHdyaXRlIHRvIHJlYWQtb25seSBtZW1vcnkg
cGFnZS4gZ2ZuPTB4ZDEsIG1mbj0weGE0YTE2DQooWEVOKSBbMjAxMi0wOS0wMyAyMDo1ODo1
NF0gaHZtLmM6MjQzNTpkMTUgZ3Vlc3QgYXR0ZW1wdGVkIHdyaXRlIHRvIHJlYWQtb25seSBt
ZW1vcnkgcGFnZS4gZ2ZuPTB4ZDMsIG1mbj0weGE0YTE0DQooWEVOKSBbMjAxMi0wOS0wMyAy
MDo1ODo1NF0gaHZtLmM6MjQzNTpkMTUgZ3Vlc3QgYXR0ZW1wdGVkIHdyaXRlIHRvIHJlYWQt
b25seSBtZW1vcnkgcGFnZS4gZ2ZuPTB4ZDUsIG1mbj0weGE0YTEyDQooWEVOKSBbMjAxMi0w
OS0wMyAyMDo1ODo1NF0gaHZtLmM6MjQzNTpkMTUgZ3Vlc3QgYXR0ZW1wdGVkIHdyaXRlIHRv
IHJlYWQtb25seSBtZW1vcnkgcGFnZS4gZ2ZuPTB4ZDcsIG1mbj0weGE0YTEwDQooWEVOKSBb
MjAxMi0wOS0wMyAyMDo1ODo1NF0gaHZtLmM6MjQzNTpkMTUgZ3Vlc3QgYXR0ZW1wdGVkIHdy
aXRlIHRvIHJlYWQtb25seSBtZW1vcnkgcGFnZS4gZ2ZuPTB4ZDksIG1mbj0weGE0YTBlDQoo
WEVOKSBbMjAxMi0wOS0wMyAyMDo1ODo1NF0gaHZtLmM6MjQzNTpkMTUgZ3Vlc3QgYXR0ZW1w
dGVkIHdyaXRlIHRvIHJlYWQtb25seSBtZW1vcnkgcGFnZS4gZ2ZuPTB4ZGIsIG1mbj0weGE0
YTBjDQooWEVOKSBbMjAxMi0wOS0wMyAyMDo1ODo1NF0gaHZtLmM6MjQzNTpkMTUgZ3Vlc3Qg
YXR0ZW1wdGVkIHdyaXRlIHRvIHJlYWQtb25seSBtZW1vcnkgcGFnZS4gZ2ZuPTB4ZGQsIG1m
bj0weGE0YTBhDQooWEVOKSBbMjAxMi0wOS0wMyAyMDo1ODo1NF0gaHZtLmM6MjQzNTpkMTUg
Z3Vlc3QgYXR0ZW1wdGVkIHdyaXRlIHRvIHJlYWQtb25seSBtZW1vcnkgcGFnZS4gZ2ZuPTB4
ZGYsIG1mbj0weGE0YTA4DQooWEVOKSBbMjAxMi0wOS0wMyAyMDo1ODo1NF0gaHZtLmM6MjQz
NTpkMTUgZ3Vlc3QgYXR0ZW1wdGVkIHdyaXRlIHRvIHJlYWQtb25seSBtZW1vcnkgcGFnZS4g
Z2ZuPTB4ZTEsIG1mbj0weGE0YTA2DQooWEVOKSBbMjAxMi0wOS0wMyAyMDo1ODo1NF0gaHZt
LmM6MjQzNTpkMTUgZ3Vlc3QgYXR0ZW1wdGVkIHdyaXRlIHRvIHJlYWQtb25seSBtZW1vcnkg
cGFnZS4gZ2ZuPTB4ZTMsIG1mbj0weGE0YTA0DQooWEVOKSBbMjAxMi0wOS0wMyAyMDo1ODo1
NF0gaHZtLmM6MjQzNTpkMTUgZ3Vlc3QgYXR0ZW1wdGVkIHdyaXRlIHRvIHJlYWQtb25seSBt
ZW1vcnkgcGFnZS4gZ2ZuPTB4ZTUsIG1mbj0weGE0YTAyDQooWEVOKSBbMjAxMi0wOS0wMyAy
MDo1ODo1NF0gaHZtLmM6MjQzNTpkMTUgZ3Vlc3QgYXR0ZW1wdGVkIHdyaXRlIHRvIHJlYWQt
b25seSBtZW1vcnkgcGFnZS4gZ2ZuPTB4ZTcsIG1mbj0weGE0YTAwDQooWEVOKSBbMjAxMi0w
OS0wMyAyMDo1ODo1NF0gaHZtLmM6MjQzNTpkMTUgZ3Vlc3QgYXR0ZW1wdGVkIHdyaXRlIHRv
IHJlYWQtb25seSBtZW1vcnkgcGFnZS4gZ2ZuPTB4ZTksIG1mbj0weGE0NjNlDQooWEVOKSBb
MjAxMi0wOS0wMyAyMDo1ODo1NF0gaHZtLmM6MjQzNTpkMTUgZ3Vlc3QgYXR0ZW1wdGVkIHdy
aXRlIHRvIHJlYWQtb25seSBtZW1vcnkgcGFnZS4gZ2ZuPTB4ZWIsIG1mbj0weGE0NjNjDQoo
WEVOKSBbMjAxMi0wOS0wMyAyMDo1ODo1NF0gaHZtLmM6MjQzNTpkMTUgZ3Vlc3QgYXR0ZW1w
dGVkIHdyaXRlIHRvIHJlYWQtb25seSBtZW1vcnkgcGFnZS4gZ2ZuPTB4ZWQsIG1mbj0weGE0
NjNhDQooWEVOKSBbMjAxMi0wOS0wMyAyMDo1ODo1NF0gaHZtLmM6MjQzNTpkMTUgZ3Vlc3Qg
YXR0ZW1wdGVkIHdyaXRlIHRvIHJlYWQtb25seSBtZW1vcnkgcGFnZS4gZ2ZuPTB4ZWYsIG1m
bj0weGE0NjM4DQooWEVOKSBbMjAxMi0wOS0wMyAyMToyMDo0OV0gQU1ELVZpOiBJT19QQUdF
X0ZBVUxUOiBkb21haW4gPSAxNCwgZGV2aWNlIGlkID0gMHgwNzAwLCBmYXVsdCBhZGRyZXNz
ID0gMHhhOGVlODBhMA0KKFhFTikgWzIwMTItMDktMDMgMjE6MjA6NDldIEFNRC1WaTogSU9f
UEFHRV9GQVVMVDogZG9tYWluID0gMTQsIGRldmljZSBpZCA9IDB4MDcwMCwgZmF1bHQgYWRk
cmVzcyA9IDB4YThlZTgwYzANCihYRU4pIFsyMDEyLTA5LTAzIDIxOjIwOjQ5XSBBTUQtVmk6
IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDE0LCBkZXZpY2UgaWQgPSAweDA3MDAsIGZhdWx0
IGFkZHJlc3MgPSAweGE4ZWU4MTAwDQooWEVOKSBbMjAxMi0wOS0wMyAyMToyMDo0OV0gQU1E
LVZpOiBJT19QQUdFX0ZBVUxUOiBkb21haW4gPSAxNCwgZGV2aWNlIGlkID0gMHgwNzAwLCBm
YXVsdCBhZGRyZXNzID0gMHhhOGVlODE4MA0KKFhFTikgWzIwMTItMDktMDMgMjE6MjA6NDld
IEFNRC1WaTogSU9fUEFHRV9GQVVMVDogZG9tYWluID0gMTQsIGRldmljZSBpZCA9IDB4MDcw
MCwgZmF1bHQgYWRkcmVzcyA9IDB4YThlZTgxMjANCihYRU4pIFsyMDEyLTA5LTAzIDIxOjIw
OjQ5XSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDE0LCBkZXZpY2UgaWQgPSAw
eDA3MDAsIGZhdWx0IGFkZHJlc3MgPSAweGE4ZWU4MTQwDQooWEVOKSBbMjAxMi0wOS0wMyAy
MToyMDo0OV0gQU1ELVZpOiBJT19QQUdFX0ZBVUxUOiBkb21haW4gPSAxNCwgZGV2aWNlIGlk
ID0gMHgwNzAwLCBmYXVsdCBhZGRyZXNzID0gMHhhOGVlODFhMA0KKFhFTikgWzIwMTItMDkt
MDMgMjE6MjA6NDldIEFNRC1WaTogSU9fUEFHRV9GQVVMVDogZG9tYWluID0gMTQsIGRldmlj
ZSBpZCA9IDB4MDcwMCwgZmF1bHQgYWRkcmVzcyA9IDB4YThlZTgxYzANCihYRU4pIFsyMDEy
LTA5LTAzIDIxOjIwOjQ5XSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDE0LCBk
ZXZpY2UgaWQgPSAweDA3MDAsIGZhdWx0IGFkZHJlc3MgPSAweGE4ZWU4MjAwDQooWEVOKSBb
MjAxMi0wOS0wMyAyMToyMDo0OV0gQU1ELVZpOiBJT19QQUdFX0ZBVUxUOiBkb21haW4gPSAx
NCwgZGV2aWNlIGlkID0gMHgwNzAwLCBmYXVsdCBhZGRyZXNzID0gMHhhOGVlODIyMA0KKFhF
TikgWzIwMTItMDktMDMgMjE6MjA6NDldIEFNRC1WaTogSU9fUEFHRV9GQVVMVDogZG9tYWlu
ID0gMTQsIGRldmljZSBpZCA9IDB4MDcwMCwgZmF1bHQgYWRkcmVzcyA9IDB4YThlZTgyNDAN
CihYRU4pIFsyMDEyLTA5LTAzIDIxOjIwOjQ5XSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRv
bWFpbiA9IDE0LCBkZXZpY2UgaWQgPSAweDA3MDAsIGZhdWx0IGFkZHJlc3MgPSAweGE4ZWU4
MjgwDQooWEVOKSBbMjAxMi0wOS0wMyAyMToyMDo0OV0gQU1ELVZpOiBJT19QQUdFX0ZBVUxU
OiBkb21haW4gPSAxNCwgZGV2aWNlIGlkID0gMHgwNzAwLCBmYXVsdCBhZGRyZXNzID0gMHhh
OGVlODJhMA0KKFhFTikgWzIwMTItMDktMDMgMjE6MjA6NDldIEFNRC1WaTogSU9fUEFHRV9G
QVVMVDogZG9tYWluID0gMTQsIGRldmljZSBpZCA9IDB4MDcwMCwgZmF1bHQgYWRkcmVzcyA9
IDB4YThlZTgzMDANCihYRU4pIFsyMDEyLTA5LTAzIDIxOjIwOjQ5XSBBTUQtVmk6IElPX1BB
R0VfRkFVTFQ6IGRvbWFpbiA9IDE0LCBkZXZpY2UgaWQgPSAweDA3MDAsIGZhdWx0IGFkZHJl
c3MgPSAweGE4ZWU4MmMwDQooWEVOKSBbMjAxMi0wOS0wMyAyMToyMDo0OV0gQU1ELVZpOiBJ
T19QQUdFX0ZBVUxUOiBkb21haW4gPSAxNCwgZGV2aWNlIGlkID0gMHgwNzAwLCBmYXVsdCBh
ZGRyZXNzID0gMHhhOGVlODMyMA0KKFhFTikgWzIwMTItMDktMDQgMDM6MDA6MzRdIHRyYXBz
LmM6MzE1NjogR1BGICgwMDYwKTogZmZmZjgyYzQ4MDE1YzllZSAtPiBmZmZmODJjNDgwMjI0
YjczDQooWEVOKSBbMjAxMi0wOS0wNCAwMzowMDozNF0gdHJhcHMuYzozMTU3OiAgc2hvd19l
eGVjdXRpb25fc3RhdGUocmVncyk6IA0KKFhFTikgWzIwMTItMDktMDQgMDM6MDA6MzRdIC0t
LS1bIFhlbi00LjIuMC1yYzQtcHJlICB4ODZfNjQgIGRlYnVnPXkgIE5vdCB0YWludGVkIF0t
LS0tDQooWEVOKSBbMjAxMi0wOS0wNCAwMzowMDozNF0gQ1BVOiAgICAzDQooWEVOKSBbMjAx
Mi0wOS0wNCAwMzowMDozNF0gUklQOiAgICBlMDA4Ols8ZmZmZjgyYzQ4MDE1YzllZT5dIGNv
bnRleHRfc3dpdGNoKzB4Mzk0LzB4ZWViDQooWEVOKSBbMjAxMi0wOS0wNCAwMzowMDozNF0g
UkZMQUdTOiAwMDAwMDAwMDAwMDEwMjQ2ICAgQ09OVEVYVDogaHlwZXJ2aXNvcg0KKFhFTikg
WzIwMTItMDktMDQgMDM6MDA6MzRdIHJheDogMDAwMDAwMDAwMDAwMDAwMSAgIHJieDogZmZm
ZjgzMDBhNTJkYTAwMCAgIHJjeDogMDAwMDAwMDAwMDAwMDAwMQ0KKFhFTikgWzIwMTItMDkt
MDQgMDM6MDA6MzRdIHJkeDogMDAwMDAwMDAwMDAwMDA2MyAgIHJzaTogMDAwMDAwMDAwMDAw
MDAwMSAgIHJkaTogMDAwMDAwMDAwMDAwMDM3ZQ0KKFhFTikgWzIwMTItMDktMDQgMDM6MDA6
MzRdIHJicDogZmZmZjgzMDI0ZDhhN2UyOCAgIHJzcDogZmZmZjgzMDI0ZDhhN2Q4OCAgIHI4
OiAgMDAwMDAwMDAwMDAwMDAwNg0KKFhFTikgWzIwMTItMDktMDQgMDM6MDA6MzRdIHI5OiAg
ZmZmZjgzMDI0ZDk1ZWJiOCAgIHIxMDogMDAwMDAwMDBkZWFkYmVlZiAgIHIxMTogMDAwMDAw
MDAwMDAwMDI0Ng0KKFhFTikgWzIwMTItMDktMDQgMDM6MDA6MzRdIHIxMjogZmZmZjgzMDBh
ZmQxMTAwMCAgIHIxMzogMDAwMDAwMDAwMDAwMDAwMyAgIHIxNDogMDAwMDAwMDAwMDAwMDAw
Mw0KKFhFTikgWzIwMTItMDktMDQgMDM6MDA6MzRdIHIxNTogZmZmZjgzMDI0ZDhhYTA0OCAg
IGNyMDogMDAwMDAwMDA4MDA1MDAzYiAgIGNyNDogMDAwMDAwMDAwMDAwMDZmMA0KKFhFTikg
WzIwMTItMDktMDQgMDM6MDA6MzRdIGNyMzogMDAwMDAwMDA2ODUwNjAwMCAgIGNyMjogZmZm
ZmZmZmZmZjYwMDQwMA0KKFhFTikgWzIwMTItMDktMDQgMDM6MDA6MzRdIGRzOiAwMDAwICAg
ZXM6IDAwMDAgICBmczogMDAwMCAgIGdzOiAwMDAwICAgc3M6IGUwMTAgICBjczogZTAwOA0K
KFhFTikgWzIwMTItMDktMDQgMDM6MDA6MzRdIFhlbiBzdGFjayB0cmFjZSBmcm9tIHJzcD1m
ZmZmODMwMjRkOGE3ZDg4Og0KKFhFTikgWzIwMTItMDktMDQgMDM6MDA6MzRdICAgIDAwMDAw
MDAwMDAwMDAwMjkgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAxZTAwMDAwMDAwIDAwMDAwMDAw
MDAwMDAwMDANCihYRU4pIFsyMDEyLTA5LTA0IDAzOjAwOjM0XSAgICBmZmZmODMwMjRkOGE3
ZGI4IGZmZmY4MzAyNGQ4YWEwNjAgZmZmZjgzMDI0ZDhhN2UxOCBmZmZmODJjNDgwMTgwNWFl
DQooWEVOKSBbMjAxMi0wOS0wNCAwMzowMDozNF0gICAgMDAwMDAwMDAwMDAxMmYyMiAwMDAw
M2ZkOWFiNmQ2Y2E2IDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMA0KKFhFTikg
WzIwMTItMDktMDQgMDM6MDA6MzRdICAgIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAw
MDAwMCBmZmZmODMwMjRkOGE3ZTI4IGZmZmY4MzAwYWZkMTEwMDANCihYRU4pIFsyMDEyLTA5
LTA0IDAzOjAwOjM0XSAgICBmZmZmODMwMGE1MmRhMDAwIDAwMDAxM2ViYmEzN2UxMGMgMDAw
MDAwMDAwMDAwMDAwMiBmZmZmODMwMjRkOGFhMDQ4DQooWEVOKSBbMjAxMi0wOS0wNCAwMzow
MDozNF0gICAgZmZmZjgzMDI0ZDhhN2ViOCBmZmZmODJjNDgwMTI0YTcwIDAwMDAwMDAwMDAw
MDAwMDAgZmZmZjgzMDI0ZDhhYTA0MA0KKFhFTikgWzIwMTItMDktMDQgMDM6MDA6MzRdICAg
IDAwMDAwMDAzNGQ4YTdlNjggMDAwMDEzZWJiYTM3ZTEwYyBmZmZmODMwMjRkOGE3ZTg4IGZm
ZmY4MmM0ODAxODk0ODMNCihYRU4pIFsyMDEyLTA5LTA0IDAzOjAwOjM0XSAgICBmZmZmODMw
MGE1MmRhMDAwIDAwMDAwMDAwMDFjOWMzODAgZmZmZjgzMDI0ZDhhN2UwMCBmZmZmODJjNDgw
MTIyNmNlDQooWEVOKSBbMjAxMi0wOS0wNCAwMzowMDozNF0gICAgZmZmZjgzMDI0ZDhhN2Vm
OCBmZmZmODJjNDgwMmQ4MTgwIDAwMDAwMDAwZmZmZmZmZmYgZmZmZjgyYzQ4MDJkODAwMA0K
KFhFTikgWzIwMTItMDktMDQgMDM6MDA6MzRdICAgIGZmZmY4MzAyNGQ4YTdmMTggZmZmZmZm
ZmZmZmZmZmZmZiBmZmZmODMwMjRkOGE3ZWY4IGZmZmY4MmM0ODAxMjVlMzENCihYRU4pIFsy
MDEyLTA5LTA0IDAzOjAwOjM0XSAgICAwMDAwMDAwMDAwMDAwMjQ2IGZmZmY4MzAwYWZkMTEw
MDAgZmZmZmZmZmY4MWVjZTVkOCBmZmZmZmZmZjgxZjQyMGMwDQooWEVOKSBbMjAxMi0wOS0w
NCAwMzowMDozNF0gICAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIGZmZmY4
MzAyNGQ4YTdmMDggZmZmZjgyYzQ4MDEyNWU2OA0KKFhFTikgWzIwMTItMDktMDQgMDM6MDA6
MzRdICAgIDAwMDA3Y2ZkYjI3NTgwYzcgZmZmZjgyYzQ4MDIyMmVmNiAwMDAwMDAwMDAwMDAw
MDAwIGZmZmY4ODAwMDMwZTE0YTANCihYRU4pIFsyMDEyLTA5LTA0IDAzOjAwOjM0XSAgICAw
MDAwMDAwMDAwMDAwMDAwIGZmZmY4ODAwMWEwODAwZDggZmZmZjg4MDAxY2QxN2JmMCBmZmZm
ODgwMDFmYzBiMTAwDQooWEVOKSBbMjAxMi0wOS0wNCAwMzowMDozNF0gICAgMDAwMDAwMDAw
MDAwMDIwMiAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDEgMDAwMDAwMDAwMDAw
MDAwMA0KKFhFTikgWzIwMTItMDktMDQgMDM6MDA6MzRdICAgIDAwMDAwMDAwMDAwMDAwMDAg
ZmZmZmZmZmY4MTAwMTFhYSBmZmZmODgwMDFlOTllMTgwIDAwMDAwMDAwZGVhZGJlZWYNCihY
RU4pIFsyMDEyLTA5LTA0IDAzOjAwOjM0XSAgICAwMDAwMDAwMGRlYWRiZWVmIDAwMDAwMTAw
MDAwMDAwMDAgZmZmZmZmZmY4MTAwMTFhYSAwMDAwMDAwMDAwMDBlMDMzDQooWEVOKSBbMjAx
Mi0wOS0wNCAwMzowMDozNF0gICAgMDAwMDAwMDAwMDAwMDIwMiBmZmZmODgwMDFjZDE3YmI4
IDAwMDAwMDAwMDAwMGUwMmIgMDAwMDUzZmQwMDAwYmVlZg0KKFhFTikgWzIwMTItMDktMDQg
MDM6MDA6MzRdICAgIDgwMDAwMDAwMDAwMGJlZWYgNzQwMDAwMDAwMDAwYmVlZiAwMDAwMDAw
MDAwMThiZWVmIDAwMDA1M2ZlMDAwMDAwMDMNCihYRU4pIFsyMDEyLTA5LTA0IDAzOjAwOjM0
XSAgICBmZmZmODMwMGE1MmRhMDAwIDAwMDAwMDNkY2Q1YTg2ODAgMDAwMDAwMDAwMDE4ZTBj
OQ0KKFhFTikgWzIwMTItMDktMDQgMDM6MDA6MzRdIFhlbiBjYWxsIHRyYWNlOg0KKFhFTikg
WzIwMTItMDktMDQgMDM6MDA6MzRdICAgIFs8ZmZmZjgyYzQ4MDE1YzllZT5dIGNvbnRleHRf
c3dpdGNoKzB4Mzk0LzB4ZWViDQooWEVOKSBbMjAxMi0wOS0wNCAwMzowMDozNF0gICAgWzxm
ZmZmODJjNDgwMTI0YTcwPl0gc2NoZWR1bGUrMHg2NjYvMHg2NzUNCihYRU4pIFsyMDEyLTA5
LTA0IDAzOjAwOjM0XSAgICBbPGZmZmY4MmM0ODAxMjVlMzE+XSBfX2RvX3NvZnRpcnErMHhh
NC8weGI1DQooWEVOKSBbMjAxMi0wOS0wNCAwMzowMDozNF0gICAgWzxmZmZmODJjNDgwMTI1
ZTY4Pl0gZG9fc29mdGlycSsweDI2LzB4MjgNCihYRU4pIFsyMDEyLTA5LTA0IDAzOjAwOjM0
XSAgICANCihYRU4pIFsyMDEyLTA5LTA0IDAzOjAwOjM0XSB0cmFwcy5jOjMxNTk6ICAgc2hv
d19leGVjdXRpb25fc3RhdGUoZ3Vlc3RfY3B1X3VzZXJfcmVncygpKTogDQooWEVOKSBbMjAx
Mi0wOS0wNCAwMzowMDozNF0gLS0tLVsgWGVuLTQuMi4wLXJjNC1wcmUgIHg4Nl82NCAgZGVi
dWc9eSAgTm90IHRhaW50ZWQgXS0tLS0NCihYRU4pIFsyMDEyLTA5LTA0IDAzOjAwOjM0XSBD
UFU6ICAgIDMNCihYRU4pIFsyMDEyLTA5LTA0IDAzOjAwOjM0XSBSSVA6ICAgIGUwMzM6Wzxm
ZmZmZmZmZjgxMDAxMWFhPl0NCihYRU4pIFsyMDEyLTA5LTA0IDAzOjAwOjM0XSBSRkxBR1M6
IDAwMDAwMDAwMDAwMDAyMDIgICBFTTogMSAgIENPTlRFWFQ6IHB2IGd1ZXN0DQooWEVOKSBb
MjAxMi0wOS0wNCAwMzowMDozNF0gcmF4OiAwMDAwMDAwMDAwMDAwMDAwICAgcmJ4OiBmZmZm
ODgwMDFmYzBiMTAwICAgcmN4OiBmZmZmZmZmZjgxMDAxMWFhDQooWEVOKSBbMjAxMi0wOS0w
NCAwMzowMDozNF0gcmR4OiBmZmZmODgwMDFlOTllMTgwICAgcnNpOiAwMDAwMDAwMGRlYWRi
ZWVmICAgcmRpOiAwMDAwMDAwMGRlYWRiZWVmDQooWEVOKSBbMjAxMi0wOS0wNCAwMzowMDoz
NF0gcmJwOiBmZmZmODgwMDFjZDE3YmYwICAgcnNwOiBmZmZmODgwMDFjZDE3YmI4ICAgcjg6
ICAwMDAwMDAwMDAwMDAwMDAwDQooWEVOKSBbMjAxMi0wOS0wNCAwMzowMDozNF0gcjk6ICAw
MDAwMDAwMDAwMDAwMDAxICAgcjEwOiAwMDAwMDAwMDAwMDAwMDAwICAgcjExOiAwMDAwMDAw
MDAwMDAwMjAyDQooWEVOKSBbMjAxMi0wOS0wNCAwMzowMDozNF0gcjEyOiBmZmZmODgwMDFh
MDgwMGQ4ICAgcjEzOiAwMDAwMDAwMDAwMDAwMDAwICAgcjE0OiBmZmZmODgwMDAzMGUxNGEw
DQooWEVOKSBbMjAxMi0wOS0wNCAwMzowMDozNF0gcjE1OiAwMDAwMDAwMDAwMDAwMDAwICAg
Y3IwOiAwMDAwMDAwMDgwMDUwMDNiICAgY3I0OiAwMDAwMDAwMDAwMDAwNmYwDQooWEVOKSBb
MjAxMi0wOS0wNCAwMzowMDozNF0gY3IzOiAwMDAwMDAwMDY4NTA2MDAwICAgY3IyOiAwMDAw
MDAwMGY3NmU0MDAwDQooWEVOKSBbMjAxMi0wOS0wNCAwMzowMDozNF0gZHM6IDAwMDAgICBl
czogMDAwMCAgIGZzOiAwMDAwICAgZ3M6IDAwMDAgICBzczogZTAyYiAgIGNzOiBlMDMzDQoo
WEVOKSBbMjAxMi0wOS0wNCAwMzowMDozNF0gR3Vlc3Qgc3RhY2sgdHJhY2UgZnJvbSByc3A9
ZmZmZjg4MDAxY2QxN2JiODoNCihYRU4pIFsyMDEyLTA5LTA0IDAzOjAwOjM0XSAgICAwMDAw
MDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDEgZmZmZmZmZmY4MTAwNDk0MiBmZmZmODgw
MDAzMGUxMDQwDQooWEVOKSBbMjAxMi0wOS0wNCAwMzowMDozNF0gICAgZmZmZjg4MDAxZTk5
ZTE4MCAwMDAwMDAwMDAwMDAwMDAwIGZmZmY4ODAwMDMwZTE0YTAgZmZmZjg4MDAxY2QxN2Mx
MA0KKFhFTikgWzIwMTItMDktMDQgMDM6MDA6MzRdICAgIGZmZmZmZmZmODEwMDM5NDEgZmZm
Zjg4MDAxZTk5ZTE4MCBmZmZmODgwMDAzMGUxMDQwIGZmZmY4ODAwMWNkMTdjNzANCihYRU4p
IFsyMDEyLTA5LTA0IDAzOjAwOjM0XSAgICBmZmZmZmZmZjgxMDBiODUwIGZmZmY4ODAwMDMw
ZTEwNDAgZmZmZjg4MDAxZDI4MDA4MCAwMDAwMDAwMDAwMDAwMDYzDQooWEVOKSBbMjAxMi0w
OS0wNCAwMzowMDozNF0gICAgZmZmZjg4MDAxZmMxMGE4MCBmZmZmODgwMDFjZDE3YzgwIGZm
ZmY4ODAwMWZjMTJlODAgMDAwMDAwMDAwMDAwMDAwMA0KKFhFTikgWzIwMTItMDktMDQgMDM6
MDA6MzRdICAgIGZmZmY4ODAwMWQyODViMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAw
MDAwMDAwIGZmZmY4ODAwMDMwZTEwNDANCihYRU4pIFsyMDEyLTA5LTA0IDAzOjAwOjM0XSAg
ICBmZmZmZmZmZjgxN2ZhMmY1IGZmZmY4ODAwMWNkMTdkZDAgMDAwMDAwMDAwMDAwMDIxNiBm
ZmZmZmZmZjgxMDcwMGZlDQooWEVOKSBbMjAxMi0wOS0wNCAwMzowMDozNF0gICAgZmZmZjg4
MDAxZmMwZTAxOCBmZmZmODgwMDAzMGUxMDQwIDAwMDAwMDAwMDAwMTJlODAgZmZmZjg4MDAx
Y2QxN2ZkOA0KKFhFTikgWzIwMTItMDktMDQgMDM6MDA6MzRdICAgIGZmZmY4ODAwMWNkMTYw
MTAgMDAwMDAwMDAwMDAxMmU4MCAwMDAwMDAwMDAwMDEyZTgwIGZmZmY4ODAwMWNkMTdmZDgN
CihYRU4pIFsyMDEyLTA5LTA0IDAzOjAwOjM0XSAgICAwMDAwMDAwMDAwMDEyZTgwIGZmZmY4
ODAwMWU5OTkwNDAgZmZmZjg4MDAwMzBlMTA0MCBmZmZmODgwMDAwMDAwMDAwDQooWEVOKSBb
MjAxMi0wOS0wNCAwMzowMDozNF0gICAgZmZmZjg4MDAwMDAwMDAwMCBmZmZmODgwMDFmYzBl
MDAwIGZmZmY4ODAwMWNkYjMzMDAgZmZmZjg4MDAxZmMxNmUwMA0KKFhFTikgWzIwMTItMDkt
MDQgMDM6MDA6MzRdICAgIGZmZmY4ODAwMWZjMGUwMDAgZmZmZjg4MDAxY2QxN2Q1MCBmZmZm
ZmZmZjgxN2ZiNjE0IGZmZmY4ODAwMWQwOGMxNDANCihYRU4pIFsyMDEyLTA5LTA0IDAzOjAw
OjM0XSAgICBmZmZmODgwMDFjZGIzMzAwIGZmZmY4ODAwMWZjMTZlMDAgZmZmZjg4MDAxZmMw
ZTAwMCBmZmZmODgwMDFjZDE3ZGUwDQooWEVOKSBbMjAxMi0wOS0wNCAwMzowMDozNF0gICAg
ZmZmZmZmZmY4MTA3ZjA1OSBmZmZmODgwMDAzMGUxMDQwIGZmZmY4ODAwMDMwZTEwNDAgZmZm
ZmZmZmY4MTdmYmU3Yg0KKFhFTikgWzIwMTItMDktMDQgMDM6MDA6MzRdICAgIGZmZmY4ODAw
MWZjMGU0NDggZmZmZjg4MDAwMzBlMTA0MCBmZmZmODgwMDFjZGIzMzIwIGZmZmY4ODAwMWNk
MTdkYjANCihYRU4pIFsyMDEyLTA5LTA0IDAzOjAwOjM0XSAgICBmZmZmZmZmZjgxMGFjYjc4
IGZmZmY4ODAwMWZjMGUwMDAgZmZmZjg4MDAxY2RiMzMwMCBmZmZmODgwMDFmYzBlNDM4DQoo
WEVOKSBbMjAxMi0wOS0wNCAwMzowMDozNF0gICAgZmZmZjg4MDAxZmMwZTQ0OCBmZmZmODgw
MDAzMGUxMDQwIGZmZmY4ODAwMWNkYjMzMjAgZmZmZjg4MDAxY2QxN2RlMA0KKFhFTikgWzIw
MTItMDktMDQgMDM6MDA6MzRdICAgIGZmZmZmZmZmODE3ZmE4MTQgZmZmZjg4MDAxY2QxN2Vi
MCBmZmZmZmZmZjgxMDdmNmY5IDAwMDAwMDAwMDAwMDAwMDANCihYRU4pIFsyMDEyLTA5LTA0
IDAzOjAwOjM0XSAgICBmZmZmODgwMDFjZDE3ZTUwIGZmZmY4ODAwMDMwZTEwNDAgZmZmZjg4
MDAxY2QxNjAxMCBmZmZmODgwMDAzMGUwMjQwDQooWEVOKSBbMjAxMi0wOS0wNCAwMzowMDoz
NF0gICAgZmZmZjg4MDAxY2QxN2U2OCBmZmZmODgwMDAzMGUxMDQwIGZmZmY4ODAwMDMwZTEw
NDAgZmZmZjg4MDAwMzBlMTA0MA0KKFhFTikgWzIwMTItMDktMDQgMDM6MTU6MTJdIGdyYW50
X3RhYmxlLmM6MjU0OmQwIEluY3JlYXNlZCBtYXB0cmFjayBzaXplIHRvIDIgZnJhbWVzDQo=
------------05A1A81AE2E0F0B49
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

------------05A1A81AE2E0F0B49--



From xen-devel-bounces@lists.xen.org Tue Sep 04 07:09:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Sep 2012 07:09:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T8nFk-0001j9-Qo; Tue, 04 Sep 2012 07:08:52 +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 1T8nFj-0001iw-77
	for xen-devel@lists.xen.org; Tue, 04 Sep 2012 07:08:51 +0000
Received: from [85.158.143.35:59501] by server-2.bemta-4.messagelabs.com id
	BC/9F-21239-209A5405; Tue, 04 Sep 2012 07:08:50 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-11.tower-21.messagelabs.com!1346742525!11383691!1
X-Originating-IP: [188.40.164.121]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11634 invoked from network); 4 Sep 2012 07:08:46 -0000
Received: from static.121.164.40.188.clients.your-server.de (HELO
	smtp.eikelenboom.it) (188.40.164.121)
	by server-11.tower-21.messagelabs.com with AES256-SHA encrypted SMTP;
	4 Sep 2012 07:08:46 -0000
Received: from 26-69-ftth.onsneteindhoven.nl ([88.159.69.26]:49230
	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 1T8nCY-00021c-QM; Tue, 04 Sep 2012 09:05:35 +0200
Date: Tue, 4 Sep 2012 09:08:41 +0200
From: Sander Eikelenboom <linux@eikelenboom.it>
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <4610648186.20120904090841@eikelenboom.it>
To: "Jan Beulich" <JBeulich@suse.com>
In-Reply-To: <5044849002000078000982EA@nat28.tlf.novell.com>
References: <7914B38A4445B34AA16EB9F1352942F1012F0F6F4B98@SJCPMAILBOX01.citrite.net>
	<CC681CDD.3D966%keir.xen@gmail.com>
	<40501859.20120902104331@eikelenboom.it>
	<5044849002000078000982EA@nat28.tlf.novell.com>
MIME-Version: 1.0
Content-Type: multipart/mixed;
 boundary="----------05A1A81AE2E0F0B49"
Cc: "wei.wang2@amd.com" <wei.wang2@amd.com>, Keir Fraser <keir.xen@gmail.com>,
	Santosh Jodh <Santosh.Jodh@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Using debug-key 'o:  Dump IOMMU p2m table,
	locks up machine
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

------------05A1A81AE2E0F0B49
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hello Jan,

Monday, September 3, 2012, 10:21:04 AM, you wrote:

>>>> On 02.09.12 at 10:43, Sander Eikelenboom <linux@eikelenboom.it> wrote:
>> I have attached new output from xl dmesg, this time with iommu=debug on (the 
>> option changed from 4.1 to 4.2).

> This one

>>(XEN) [2012-09-02 00:55:02] traps.c:3156: GPF (0060): ffff82c48015c9ee -> ffff82c480224b13

> also worries me. While Xen gracefully recovers from it, these
> messages still generally indicate a problem somewhere. Could
> you resolve the addresses to file:line tuples? And, assuming
> this happens in the context of doing something on behalf of
> the guest in the context of a guest vCPU, could you also
> check what guest side action triggers this (e.g. by adding a
> call to show_execution_state() alongside the printing of the
> message)?

Hope i have done it right:

diff -r a0b5f8102a00 xen/arch/x86/traps.c
--- a/xen/arch/x86/traps.c      Tue Aug 28 22:40:45 2012 +0100
+++ b/xen/arch/x86/traps.c      Tue Sep 04 08:53:54 2012 +0200
@@ -3154,6 +3154,11 @@
     {
         dprintk(XENLOG_INFO, "GPF (%04x): %p -> %p\n",
                 regs->error_code, _p(regs->eip), _p(fixup));
+        dprintk(XENLOG_INFO, " show_execution_state(regs): \n");
+       show_execution_state(regs);
+        dprintk(XENLOG_INFO, "  show_execution_state(guest_cpu_user_regs()): \n");
+       show_execution_state(guest_cpu_user_regs());
+
         regs->eip = fixup;
         return;
     }


Gives (complete dmesg attached:

(XEN) [2012-09-03 21:20:49] AMD-Vi: IO_PAGE_FAULT: domain = 14, device id = 0x0700, fault address = 0xa8ee82c0
(XEN) [2012-09-03 21:20:49] AMD-Vi: IO_PAGE_FAULT: domain = 14, device id = 0x0700, fault address = 0xa8ee8320
(XEN) [2012-09-04 03:00:34] traps.c:3156: GPF (0060): ffff82c48015c9ee -> ffff82c480224b73
(XEN) [2012-09-04 03:00:34] traps.c:3157:  show_execution_state(regs): 
(XEN) [2012-09-04 03:00:34] ----[ Xen-4.2.0-rc4-pre  x86_64  debug=y  Not tainted ]----
(XEN) [2012-09-04 03:00:34] CPU:    3
(XEN) [2012-09-04 03:00:34] RIP:    e008:[<ffff82c48015c9ee>] context_switch+0x394/0xeeb
(XEN) [2012-09-04 03:00:34] RFLAGS: 0000000000010246   CONTEXT: hypervisor
(XEN) [2012-09-04 03:00:34] rax: 0000000000000001   rbx: ffff8300a52da000   rcx: 0000000000000001
(XEN) [2012-09-04 03:00:34] rdx: 0000000000000063   rsi: 0000000000000001   rdi: 000000000000037e
(XEN) [2012-09-04 03:00:34] rbp: ffff83024d8a7e28   rsp: ffff83024d8a7d88   r8:  0000000000000006
(XEN) [2012-09-04 03:00:34] r9:  ffff83024d95ebb8   r10: 00000000deadbeef   r11: 0000000000000246
(XEN) [2012-09-04 03:00:34] r12: ffff8300afd11000   r13: 0000000000000003   r14: 0000000000000003
(XEN) [2012-09-04 03:00:34] r15: ffff83024d8aa048   cr0: 000000008005003b   cr4: 00000000000006f0
(XEN) [2012-09-04 03:00:34] cr3: 0000000068506000   cr2: ffffffffff600400
(XEN) [2012-09-04 03:00:34] ds: 0000   es: 0000   fs: 0000   gs: 0000   ss: e010   cs: e008
(XEN) [2012-09-04 03:00:34] Xen stack trace from rsp=ffff83024d8a7d88:
(XEN) [2012-09-04 03:00:34]    0000000000000029 0000000000000000 0000001e00000000 0000000000000000
(XEN) [2012-09-04 03:00:34]    ffff83024d8a7db8 ffff83024d8aa060 ffff83024d8a7e18 ffff82c4801805ae
(XEN) [2012-09-04 03:00:34]    0000000000012f22 00003fd9ab6d6ca6 0000000000000000 0000000000000000
(XEN) [2012-09-04 03:00:34]    0000000000000000 0000000000000000 ffff83024d8a7e28 ffff8300afd11000
(XEN) [2012-09-04 03:00:34]    ffff8300a52da000 000013ebba37e10c 0000000000000002 ffff83024d8aa048
(XEN) [2012-09-04 03:00:34]    ffff83024d8a7eb8 ffff82c480124a70 0000000000000000 ffff83024d8aa040
(XEN) [2012-09-04 03:00:34]    000000034d8a7e68 000013ebba37e10c ffff83024d8a7e88 ffff82c480189483
(XEN) [2012-09-04 03:00:34]    ffff8300a52da000 0000000001c9c380 ffff83024d8a7e00 ffff82c4801226ce
(XEN) [2012-09-04 03:00:34]    ffff83024d8a7ef8 ffff82c4802d8180 00000000ffffffff ffff82c4802d8000
(XEN) [2012-09-04 03:00:34]    ffff83024d8a7f18 ffffffffffffffff ffff83024d8a7ef8 ffff82c480125e31
(XEN) [2012-09-04 03:00:34]    0000000000000246 ffff8300afd11000 ffffffff81ece5d8 ffffffff81f420c0
(XEN) [2012-09-04 03:00:34]    0000000000000000 0000000000000000 ffff83024d8a7f08 ffff82c480125e68
(XEN) [2012-09-04 03:00:34]    00007cfdb27580c7 ffff82c480222ef6 0000000000000000 ffff8800030e14a0
(XEN) [2012-09-04 03:00:34]    0000000000000000 ffff88001a0800d8 ffff88001cd17bf0 ffff88001fc0b100
(XEN) [2012-09-04 03:00:34]    0000000000000202 0000000000000000 0000000000000001 0000000000000000
(XEN) [2012-09-04 03:00:34]    0000000000000000 ffffffff810011aa ffff88001e99e180 00000000deadbeef
(XEN) [2012-09-04 03:00:34]    00000000deadbeef 0000010000000000 ffffffff810011aa 000000000000e033
(XEN) [2012-09-04 03:00:34]    0000000000000202 ffff88001cd17bb8 000000000000e02b 000053fd0000beef
(XEN) [2012-09-04 03:00:34]    800000000000beef 740000000000beef 000000000018beef 000053fe00000003
(XEN) [2012-09-04 03:00:34]    ffff8300a52da000 0000003dcd5a8680 000000000018e0c9
(XEN) [2012-09-04 03:00:34] Xen call trace:
(XEN) [2012-09-04 03:00:34]    [<ffff82c48015c9ee>] context_switch+0x394/0xeeb
(XEN) [2012-09-04 03:00:34]    [<ffff82c480124a70>] schedule+0x666/0x675
(XEN) [2012-09-04 03:00:34]    [<ffff82c480125e31>] __do_softirq+0xa4/0xb5
(XEN) [2012-09-04 03:00:34]    [<ffff82c480125e68>] do_softirq+0x26/0x28
(XEN) [2012-09-04 03:00:34]    
(XEN) [2012-09-04 03:00:34] traps.c:3159:   show_execution_state(guest_cpu_user_regs()): 
(XEN) [2012-09-04 03:00:34] ----[ Xen-4.2.0-rc4-pre  x86_64  debug=y  Not tainted ]----
(XEN) [2012-09-04 03:00:34] CPU:    3
(XEN) [2012-09-04 03:00:34] RIP:    e033:[<ffffffff810011aa>]
(XEN) [2012-09-04 03:00:34] RFLAGS: 0000000000000202   EM: 1   CONTEXT: pv guest
(XEN) [2012-09-04 03:00:34] rax: 0000000000000000   rbx: ffff88001fc0b100   rcx: ffffffff810011aa
(XEN) [2012-09-04 03:00:34] rdx: ffff88001e99e180   rsi: 00000000deadbeef   rdi: 00000000deadbeef
(XEN) [2012-09-04 03:00:34] rbp: ffff88001cd17bf0   rsp: ffff88001cd17bb8   r8:  0000000000000000
(XEN) [2012-09-04 03:00:34] r9:  0000000000000001   r10: 0000000000000000   r11: 0000000000000202
(XEN) [2012-09-04 03:00:34] r12: ffff88001a0800d8   r13: 0000000000000000   r14: ffff8800030e14a0
(XEN) [2012-09-04 03:00:34] r15: 0000000000000000   cr0: 000000008005003b   cr4: 00000000000006f0
(XEN) [2012-09-04 03:00:34] cr3: 0000000068506000   cr2: 00000000f76e4000
(XEN) [2012-09-04 03:00:34] ds: 0000   es: 0000   fs: 0000   gs: 0000   ss: e02b   cs: e033
(XEN) [2012-09-04 03:00:34] Guest stack trace from rsp=ffff88001cd17bb8:
(XEN) [2012-09-04 03:00:34]    0000000000000000 0000000000000001 ffffffff81004942 ffff8800030e1040
(XEN) [2012-09-04 03:00:34]    ffff88001e99e180 0000000000000000 ffff8800030e14a0 ffff88001cd17c10
(XEN) [2012-09-04 03:00:34]    ffffffff81003941 ffff88001e99e180 ffff8800030e1040 ffff88001cd17c70
(XEN) [2012-09-04 03:00:34]    ffffffff8100b850 ffff8800030e1040 ffff88001d280080 0000000000000063
(XEN) [2012-09-04 03:00:34]    ffff88001fc10a80 ffff88001cd17c80 ffff88001fc12e80 0000000000000000
(XEN) [2012-09-04 03:00:34]    ffff88001d285b00 0000000000000000 0000000000000000 ffff8800030e1040
(XEN) [2012-09-04 03:00:34]    ffffffff817fa2f5 ffff88001cd17dd0 0000000000000216 ffffffff810700fe
(XEN) [2012-09-04 03:00:34]    ffff88001fc0e018 ffff8800030e1040 0000000000012e80 ffff88001cd17fd8
(XEN) [2012-09-04 03:00:34]    ffff88001cd16010 0000000000012e80 0000000000012e80 ffff88001cd17fd8
(XEN) [2012-09-04 03:00:34]    0000000000012e80 ffff88001e999040 ffff8800030e1040 ffff880000000000
(XEN) [2012-09-04 03:00:34]    ffff880000000000 ffff88001fc0e000 ffff88001cdb3300 ffff88001fc16e00
(XEN) [2012-09-04 03:00:34]    ffff88001fc0e000 ffff88001cd17d50 ffffffff817fb614 ffff88001d08c140
(XEN) [2012-09-04 03:00:34]    ffff88001cdb3300 ffff88001fc16e00 ffff88001fc0e000 ffff88001cd17de0
(XEN) [2012-09-04 03:00:34]    ffffffff8107f059 ffff8800030e1040 ffff8800030e1040 ffffffff817fbe7b
(XEN) [2012-09-04 03:00:34]    ffff88001fc0e448 ffff8800030e1040 ffff88001cdb3320 ffff88001cd17db0
(XEN) [2012-09-04 03:00:34]    ffffffff810acb78 ffff88001fc0e000 ffff88001cdb3300 ffff88001fc0e438
(XEN) [2012-09-04 03:00:34]    ffff88001fc0e448 ffff8800030e1040 ffff88001cdb3320 ffff88001cd17de0
(XEN) [2012-09-04 03:00:34]    ffffffff817fa814 ffff88001cd17eb0 ffffffff8107f6f9 0000000000000000
(XEN) [2012-09-04 03:00:34]    ffff88001cd17e50 ffff8800030e1040 ffff88001cd16010 ffff8800030e0240
(XEN) [2012-09-04 03:00:34]    ffff88001cd17e68 ffff8800030e1040 ffff8800030e1040 ffff8800030e1040
(XEN) [2012-09-04 03:15:12] grant_table.c:254:d0 Increased maptrack size to 2 frames


> Jan

------------05A1A81AE2E0F0B49
Content-Type: text/plain;
 name="xl-dmesg.txt"
Content-transfer-encoding: base64
Content-Disposition: attachment;
 filename="xl-dmesg.txt"

IF9fICBfXyAgICAgICAgICAgIF8gIF8gICAgX19fXyAgICBfX18gICAgICAgICAgICAgIF8g
IF8gICAgICAgICAgICAgICAgICAgICANCiBcIFwvIC9fX18gXyBfXyAgIHwgfHwgfCAgfF9f
XyBcICAvIF8gXCAgICBfIF9fIF9fX3wgfHwgfCAgICAgXyBfXyAgXyBfXyBfX18gDQogIFwg
IC8vIF8gXCAnXyBcICB8IHx8IHxfICAgX18pIHx8IHwgfCB8X198ICdfXy8gX198IHx8IHxf
IF9ffCAnXyBcfCAnX18vIF8gXA0KICAvICBcICBfXy8gfCB8IHwgfF9fICAgX3wgLyBfXy8g
fCB8X3wgfF9ffCB8IHwgKF9ffF9fICAgX3xfX3wgfF8pIHwgfCB8ICBfXy8NCiAvXy9cX1xf
X198X3wgfF98ICAgIHxffChfKV9fX19fKF8pX19fLyAgIHxffCAgXF9fX3wgIHxffCAgICB8
IC5fXy98X3wgIFxfX198DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgfF98ICAgICAgICAgICAgIA0KKFhFTikgWGVuIHZl
cnNpb24gNC4yLjAtcmM0LXByZSAocm9vdEBkeW5kbnMub3JnKSAoZ2NjIChEZWJpYW4gNC40
LjUtOCkgNC40LjUpIE1vbiBTZXAgIDMgMjI6MzY6MzAgQ0VTVCAyMDEyDQooWEVOKSBMYXRl
c3QgQ2hhbmdlU2V0OiBUdWUgQXVnIDI4IDIyOjQwOjQ1IDIwMTIgKzAxMDAgMjU3ODY6YTBi
NWY4MTAyYTAwDQooWEVOKSBCb290bG9hZGVyOiBHUlVCIDEuOTgrMjAxMDA4MDQtMTQrc3F1
ZWV6ZTENCihYRU4pIENvbW1hbmQgbGluZTogZG9tMF9tZW09MTAyNE0gbG9nbHZsPWFsbCBs
b2dsdmxfZ3Vlc3Q9YWxsIGNvbnNvbGVfdGltZXN0YW1wcyB2Z2E9Z2Z4LTEyODB4MTAyNHgz
MiBjcHVpZGxlIGNwdWZyZXE9eGVuIG5vcmVib290IGRlYnVnIGxhcGljPWRlYnVnIGFwaWNf
dmVyYm9zaXR5PWRlYnVnIGFwaWM9ZGVidWcgaW9tbXU9b24sdmVyYm9zZSxkZWJ1ZyBjb20x
PTM4NDAwLDhuMSBjb25zb2xlPXZnYSxjb20xDQooWEVOKSBWaWRlbyBpbmZvcm1hdGlvbjoN
CihYRU4pICBWR0EgaXMgZ3JhcGhpY3MgbW9kZSAxMjgweDEwMjQsIDMyIGJwcA0KKFhFTikg
IFZCRS9EREMgbWV0aG9kczogVjI7IEVESUQgdHJhbnNmZXIgdGltZTogMSBzZWNvbmRzDQoo
WEVOKSBEaXNjIGluZm9ybWF0aW9uOg0KKFhFTikgIEZvdW5kIDIgTUJSIHNpZ25hdHVyZXMN
CihYRU4pICBGb3VuZCAyIEVERCBpbmZvcm1hdGlvbiBzdHJ1Y3R1cmVzDQooWEVOKSBYZW4t
ZTgyMCBSQU0gbWFwOg0KKFhFTikgIDAwMDAwMDAwMDAwMDAwMDAgLSAwMDAwMDAwMDAwMDli
MDAwICh1c2FibGUpDQooWEVOKSAgMDAwMDAwMDAwMDA5YjAwMCAtIDAwMDAwMDAwMDAwYTAw
MDAgKHJlc2VydmVkKQ0KKFhFTikgIDAwMDAwMDAwMDAwZTQwMDAgLSAwMDAwMDAwMDAwMTAw
MDAwIChyZXNlcnZlZCkNCihYRU4pICAwMDAwMDAwMDAwMTAwMDAwIC0gMDAwMDAwMDBhZmU5
MDAwMCAodXNhYmxlKQ0KKFhFTikgIDAwMDAwMDAwYWZlOTAwMDAgLSAwMDAwMDAwMGFmZTll
MDAwIChBQ1BJIGRhdGEpDQooWEVOKSAgMDAwMDAwMDBhZmU5ZTAwMCAtIDAwMDAwMDAwYWZl
ZTAwMDAgKEFDUEkgTlZTKQ0KKFhFTikgIDAwMDAwMDAwYWZlZTAwMDAgLSAwMDAwMDAwMGFm
ZjAwMDAwIChyZXNlcnZlZCkNCihYRU4pICAwMDAwMDAwMGZmZTAwMDAwIC0gMDAwMDAwMDEw
MDAwMDAwMCAocmVzZXJ2ZWQpDQooWEVOKSAgMDAwMDAwMDEwMDAwMDAwMCAtIDAwMDAwMDAy
NTAwMDAwMDAgKHVzYWJsZSkNCihYRU4pIEFDUEk6IFJTRFAgMDAwRkIxMjAsIDAwMTQgKHIw
IEFDUElBTSkNCihYRU4pIEFDUEk6IFJTRFQgQUZFOTAwMDAsIDAwNDggKHIxIE1TSSAgICBP
RU1TTElDICAyMDEwMDYyMiBNU0ZUICAgICAgIDk3KQ0KKFhFTikgQUNQSTogRkFDUCBBRkU5
MDIwMCwgMDA4NCAocjEgNzY0ME1TIEE3NjQwMTAwIDIwMTAwNjIyIE1TRlQgICAgICAgOTcp
DQooWEVOKSBBQ1BJOiBEU0RUIEFGRTkwNUUwLCA5NDQ5IChyMSAgQTc2NDAgQTc2NDAxMDAg
ICAgICAxMDAgSU5UTCAyMDA1MTExNykNCihYRU4pIEFDUEk6IEZBQ1MgQUZFOUUwMDAsIDAw
NDANCihYRU4pIEFDUEk6IEFQSUMgQUZFOTAzOTAsIDAwODggKHIxIDc2NDBNUyBBNzY0MDEw
MCAyMDEwMDYyMiBNU0ZUICAgICAgIDk3KQ0KKFhFTikgQUNQSTogTUNGRyBBRkU5MDQyMCwg
MDAzQyAocjEgNzY0ME1TIE9FTU1DRkcgIDIwMTAwNjIyIE1TRlQgICAgICAgOTcpDQooWEVO
KSBBQ1BJOiBTTElDIEFGRTkwNDYwLCAwMTc2IChyMSBNU0kgICAgT0VNU0xJQyAgMjAxMDA2
MjIgTVNGVCAgICAgICA5NykNCihYRU4pIEFDUEk6IE9FTUIgQUZFOUUwNDAsIDAwNzIgKHIx
IDc2NDBNUyBBNzY0MDEwMCAyMDEwMDYyMiBNU0ZUICAgICAgIDk3KQ0KKFhFTikgQUNQSTog
U1JBVCBBRkU5QTVFMCwgMDEwOCAocjMgQU1EICAgIEZBTV9GXzEwICAgICAgICAyIEFNRCAg
ICAgICAgIDEpDQooWEVOKSBBQ1BJOiBIUEVUIEFGRTlBNkYwLCAwMDM4IChyMSA3NjQwTVMg
T0VNSFBFVCAgMjAxMDA2MjIgTVNGVCAgICAgICA5NykNCihYRU4pIEFDUEk6IElWUlMgQUZF
OUE3MzAsIDAwRjggKHIxICBBTUQgICAgIFJEODkwUyAgIDIwMjAzMSBBTUQgICAgICAgICAw
KQ0KKFhFTikgQUNQSTogU1NEVCBBRkU5QTgzMCwgMERBNCAocjEgQSBNIEkgIFBPV0VSTk9X
ICAgICAgICAxIEFNRCAgICAgICAgIDEpDQooWEVOKSBTeXN0ZW0gUkFNOiA4MTkwTUIgKDgz
ODY3MzJrQikNCihYRU4pIFNSQVQ6IFBYTSAwIC0+IEFQSUMgMCAtPiBOb2RlIDANCihYRU4p
IFNSQVQ6IFBYTSAwIC0+IEFQSUMgMSAtPiBOb2RlIDANCihYRU4pIFNSQVQ6IFBYTSAwIC0+
IEFQSUMgMiAtPiBOb2RlIDANCihYRU4pIFNSQVQ6IFBYTSAwIC0+IEFQSUMgMyAtPiBOb2Rl
IDANCihYRU4pIFNSQVQ6IFBYTSAwIC0+IEFQSUMgNCAtPiBOb2RlIDANCihYRU4pIFNSQVQ6
IFBYTSAwIC0+IEFQSUMgNSAtPiBOb2RlIDANCihYRU4pIFNSQVQ6IE5vZGUgMCBQWE0gMCAw
LWEwMDAwDQooWEVOKSBTUkFUOiBOb2RlIDAgUFhNIDAgMTAwMDAwLWIwMDAwMDAwDQooWEVO
KSBTUkFUOiBOb2RlIDAgUFhNIDAgMTAwMDAwMDAwLTI1MDAwMDAwMA0KKFhFTikgTlVNQTog
QWxsb2NhdGVkIG1lbW5vZGVtYXAgZnJvbSAyNGQ5YTQwMDAgLSAyNGQ5YTcwMDANCihYRU4p
IE5VTUE6IFVzaW5nIDggZm9yIHRoZSBoYXNoIHNoaWZ0Lg0KKFhFTikgRG9tYWluIGhlYXAg
aW5pdGlhbGlzZWQNCihYRU4pIHZlc2FmYjogZnJhbWVidWZmZXIgYXQgMHhmYjAwMDAwMCwg
bWFwcGVkIHRvIDB4ZmZmZjgyYzAwMDAwMDAwMCwgdXNpbmcgNjE0NGssIHRvdGFsIDE0MzM2
aw0KKFhFTikgdmVzYWZiOiBtb2RlIGlzIDEyODB4MTAyNHgzMiwgbGluZWxlbmd0aD01MTIw
LCBmb250IDh4MTYNCihYRU4pIHZlc2FmYjogVHJ1ZWNvbG9yOiBzaXplPTg6ODo4OjgsIHNo
aWZ0PTI0OjE2Ojg6MA0KKFhFTikgZm91bmQgU01QIE1QLXRhYmxlIGF0IDAwMGZmNzgwDQoo
WEVOKSBETUkgcHJlc2VudC4NCihYRU4pIEFQSUMgYm9vdCBzdGF0ZSBpcyAneGFwaWMnDQoo
WEVOKSBVc2luZyBBUElDIGRyaXZlciBkZWZhdWx0DQooWEVOKSBBQ1BJOiBQTS1UaW1lciBJ
TyBQb3J0OiAweDgwOA0KKFhFTikgQUNQSTogQUNQSSBTTEVFUCBJTkZPOiBwbTF4X2NudFs4
MDQsMF0sIHBtMXhfZXZ0WzgwMCwwXQ0KKFhFTikgQUNQSTogICAgICAgICAgICAgICAgICB3
YWtldXBfdmVjW2FmZTllMDBjXSwgdmVjX3NpemVbMjBdDQooWEVOKSBBQ1BJOiBMb2NhbCBB
UElDIGFkZHJlc3MgMHhmZWUwMDAwMA0KKFhFTikgQUNQSTogTEFQSUMgKGFjcGlfaWRbMHgw
MV0gbGFwaWNfaWRbMHgwMF0gZW5hYmxlZCkNCihYRU4pIFByb2Nlc3NvciAjMCAwOjEwIEFQ
SUMgdmVyc2lvbiAxNg0KKFhFTikgQUNQSTogTEFQSUMgKGFjcGlfaWRbMHgwMl0gbGFwaWNf
aWRbMHgwMV0gZW5hYmxlZCkNCihYRU4pIFByb2Nlc3NvciAjMSAwOjEwIEFQSUMgdmVyc2lv
biAxNg0KKFhFTikgQUNQSTogTEFQSUMgKGFjcGlfaWRbMHgwM10gbGFwaWNfaWRbMHgwMl0g
ZW5hYmxlZCkNCihYRU4pIFByb2Nlc3NvciAjMiAwOjEwIEFQSUMgdmVyc2lvbiAxNg0KKFhF
TikgQUNQSTogTEFQSUMgKGFjcGlfaWRbMHgwNF0gbGFwaWNfaWRbMHgwM10gZW5hYmxlZCkN
CihYRU4pIFByb2Nlc3NvciAjMyAwOjEwIEFQSUMgdmVyc2lvbiAxNg0KKFhFTikgQUNQSTog
TEFQSUMgKGFjcGlfaWRbMHgwNV0gbGFwaWNfaWRbMHgwNF0gZW5hYmxlZCkNCihYRU4pIFBy
b2Nlc3NvciAjNCAwOjEwIEFQSUMgdmVyc2lvbiAxNg0KKFhFTikgQUNQSTogTEFQSUMgKGFj
cGlfaWRbMHgwNl0gbGFwaWNfaWRbMHgwNV0gZW5hYmxlZCkNCihYRU4pIFByb2Nlc3NvciAj
NSAwOjEwIEFQSUMgdmVyc2lvbiAxNg0KKFhFTikgQUNQSTogSU9BUElDIChpZFsweDA2XSBh
ZGRyZXNzWzB4ZmVjMDAwMDBdIGdzaV9iYXNlWzBdKQ0KKFhFTikgSU9BUElDWzBdOiBhcGlj
X2lkIDYsIHZlcnNpb24gMzMsIGFkZHJlc3MgMHhmZWMwMDAwMCwgR1NJIDAtMjMNCihYRU4p
IEFDUEk6IElPQVBJQyAoaWRbMHgwN10gYWRkcmVzc1sweGZlYzIwMDAwXSBnc2lfYmFzZVsy
NF0pDQooWEVOKSBJT0FQSUNbMV06IGFwaWNfaWQgNywgdmVyc2lvbiAzMywgYWRkcmVzcyAw
eGZlYzIwMDAwLCBHU0kgMjQtNTUNCihYRU4pIEFDUEk6IElOVF9TUkNfT1ZSIChidXMgMCBi
dXNfaXJxIDAgZ2xvYmFsX2lycSAyIGRmbCBkZmwpDQooWEVOKSBBQ1BJOiBJTlRfU1JDX09W
UiAoYnVzIDAgYnVzX2lycSA5IGdsb2JhbF9pcnEgOSBsb3cgbGV2ZWwpDQooWEVOKSBBQ1BJ
OiBJUlEwIHVzZWQgYnkgb3ZlcnJpZGUuDQooWEVOKSBBQ1BJOiBJUlEyIHVzZWQgYnkgb3Zl
cnJpZGUuDQooWEVOKSBBQ1BJOiBJUlE5IHVzZWQgYnkgb3ZlcnJpZGUuDQooWEVOKSBFbmFi
bGluZyBBUElDIG1vZGU6ICBGbGF0LiAgVXNpbmcgMiBJL08gQVBJQ3MNCihYRU4pIEFDUEk6
IEhQRVQgaWQ6IDB4ODMwMCBiYXNlOiAweGZlZDAwMDAwDQooWEVOKSBUYWJsZSBpcyBub3Qg
Zm91bmQhDQooWEVOKSBVc2luZyBBQ1BJIChNQURUKSBmb3IgU01QIGNvbmZpZ3VyYXRpb24g
aW5mb3JtYXRpb24NCihYRU4pIFNNUDogQWxsb3dpbmcgNiBDUFVzICgwIGhvdHBsdWcgQ1BV
cykNCihYRU4pIG1hcHBlZCBBUElDIHRvIGZmZmY4MmMzZmZkZmUwMDAgKGZlZTAwMDAwKQ0K
KFhFTikgbWFwcGVkIElPQVBJQyB0byBmZmZmODJjM2ZmZGZkMDAwIChmZWMwMDAwMCkNCihY
RU4pIG1hcHBlZCBJT0FQSUMgdG8gZmZmZjgyYzNmZmRmYzAwMCAoZmVjMjAwMDApDQooWEVO
KSBJUlEgbGltaXRzOiA1NiBHU0ksIDExMTIgTVNJL01TSS1YDQooWEVOKSBVc2luZyBzY2hl
ZHVsZXI6IFNNUCBDcmVkaXQgU2NoZWR1bGVyIChjcmVkaXQpDQooWEVOKSBEZXRlY3RlZCAz
MjAwLjE5OSBNSHogcHJvY2Vzc29yLg0KKFhFTikgSW5pdGluZyBtZW1vcnkgc2hhcmluZy4N
CihYRU4pIEFNRCBGYW0xMGggbWFjaGluZSBjaGVjayByZXBvcnRpbmcgZW5hYmxlZA0KKFhF
TikgUENJOiBNQ0ZHIGNvbmZpZ3VyYXRpb24gMDogYmFzZSBlMDAwMDAwMCBzZWdtZW50IDAw
MDAgYnVzZXMgMDAgLSBmZg0KKFhFTikgUENJOiBOb3QgdXNpbmcgTUNGRyBmb3Igc2VnbWVu
dCAwMDAwIGJ1cyAwMC1mZg0KKFhFTikgQU1ELVZpOiBGb3VuZCBNU0kgY2FwYWJpbGl0eSBi
bG9jayBhdCAweDU0DQooWEVOKSBBTUQtVmk6IEFDUEkgVGFibGU6DQooWEVOKSBBTUQtVmk6
ICBTaWduYXR1cmUgSVZSUw0KKFhFTikgQU1ELVZpOiAgTGVuZ3RoIDB4ZjgNCihYRU4pIEFN
RC1WaTogIFJldmlzaW9uIDB4MQ0KKFhFTikgQU1ELVZpOiAgQ2hlY2tTdW0gMHg2ZQ0KKFhF
TikgQU1ELVZpOiAgT0VNX0lkIEFNRCAgDQooWEVOKSBBTUQtVmk6ICBPRU1fVGFibGVfSWQg
UkQ4OTBTDQooWEVOKSBBTUQtVmk6ICBPRU1fUmV2aXNpb24gMHgyMDIwMzENCihYRU4pIEFN
RC1WaTogIENyZWF0b3JfSWQgQU1EIA0KKFhFTikgQU1ELVZpOiAgQ3JlYXRvcl9SZXZpc2lv
biAweDANCihYRU4pIEFNRC1WaTogSVZSUyBCbG9jazoNCihYRU4pIEFNRC1WaTogIFR5cGUg
MHgxMA0KKFhFTikgQU1ELVZpOiAgRmxhZ3MgMHgzZQ0KKFhFTikgQU1ELVZpOiAgTGVuZ3Ro
IDB4YzgNCihYRU4pIEFNRC1WaTogIERldl9JZCAweDINCihYRU4pIEFNRC1WaTogSVZIRCBE
ZXZpY2UgRW50cnk6DQooWEVOKSBBTUQtVmk6ICBUeXBlIDB4Mw0KKFhFTikgQU1ELVZpOiAg
RGV2X0lkIDB4MA0KKFhFTikgQU1ELVZpOiAgRmxhZ3MgMHgwDQooWEVOKSBBTUQtVmk6ICBE
ZXZfSWQgUmFuZ2U6IDB4MCAtPiAweDINCihYRU4pIEFNRC1WaTogSVZIRCBEZXZpY2UgRW50
cnk6DQooWEVOKSBBTUQtVmk6ICBUeXBlIDB4Mg0KKFhFTikgQU1ELVZpOiAgRGV2X0lkIDB4
MTANCihYRU4pIEFNRC1WaTogIEZsYWdzIDB4MA0KKFhFTikgQU1ELVZpOiBJVkhEIERldmlj
ZSBFbnRyeToNCihYRU4pIEFNRC1WaTogIFR5cGUgMHgyDQooWEVOKSBBTUQtVmk6ICBEZXZf
SWQgMHhiMDANCihYRU4pIEFNRC1WaTogIEZsYWdzIDB4MA0KKFhFTikgQU1ELVZpOiBJVkhE
IERldmljZSBFbnRyeToNCihYRU4pIEFNRC1WaTogIFR5cGUgMHgyDQooWEVOKSBBTUQtVmk6
ICBEZXZfSWQgMHgxOA0KKFhFTikgQU1ELVZpOiAgRmxhZ3MgMHgwDQooWEVOKSBBTUQtVmk6
IElWSEQgRGV2aWNlIEVudHJ5Og0KKFhFTikgQU1ELVZpOiAgVHlwZSAweDMNCihYRU4pIEFN
RC1WaTogIERldl9JZCAweGEwMA0KKFhFTikgQU1ELVZpOiAgRmxhZ3MgMHgwDQooWEVOKSBB
TUQtVmk6ICBEZXZfSWQgUmFuZ2U6IDB4YTAwIC0+IDB4YTA3DQooWEVOKSBBTUQtVmk6IElW
SEQgRGV2aWNlIEVudHJ5Og0KKFhFTikgQU1ELVZpOiAgVHlwZSAweDINCihYRU4pIEFNRC1W
aTogIERldl9JZCAweDI4DQooWEVOKSBBTUQtVmk6ICBGbGFncyAweDANCihYRU4pIEFNRC1W
aTogSVZIRCBEZXZpY2UgRW50cnk6DQooWEVOKSBBTUQtVmk6ICBUeXBlIDB4Mg0KKFhFTikg
QU1ELVZpOiAgRGV2X0lkIDB4OTAwDQooWEVOKSBBTUQtVmk6ICBGbGFncyAweDANCihYRU4p
IEFNRC1WaTogSVZIRCBEZXZpY2UgRW50cnk6DQooWEVOKSBBTUQtVmk6ICBUeXBlIDB4Mg0K
KFhFTikgQU1ELVZpOiAgRGV2X0lkIDB4MzANCihYRU4pIEFNRC1WaTogIEZsYWdzIDB4MA0K
KFhFTikgQU1ELVZpOiBJVkhEIERldmljZSBFbnRyeToNCihYRU4pIEFNRC1WaTogIFR5cGUg
MHgyDQooWEVOKSBBTUQtVmk6ICBEZXZfSWQgMHg4MDANCihYRU4pIEFNRC1WaTogIEZsYWdz
IDB4MA0KKFhFTikgQU1ELVZpOiBJVkhEIERldmljZSBFbnRyeToNCihYRU4pIEFNRC1WaTog
IFR5cGUgMHgyDQooWEVOKSBBTUQtVmk6ICBEZXZfSWQgMHg1MA0KKFhFTikgQU1ELVZpOiAg
RmxhZ3MgMHgwDQooWEVOKSBBTUQtVmk6IElWSEQgRGV2aWNlIEVudHJ5Og0KKFhFTikgQU1E
LVZpOiAgVHlwZSAweDINCihYRU4pIEFNRC1WaTogIERldl9JZCAweDcwMA0KKFhFTikgQU1E
LVZpOiAgRmxhZ3MgMHgwDQooWEVOKSBBTUQtVmk6IElWSEQgRGV2aWNlIEVudHJ5Og0KKFhF
TikgQU1ELVZpOiAgVHlwZSAweDINCihYRU4pIEFNRC1WaTogIERldl9JZCAweDU4DQooWEVO
KSBBTUQtVmk6ICBGbGFncyAweDANCihYRU4pIEFNRC1WaTogSVZIRCBEZXZpY2UgRW50cnk6
DQooWEVOKSBBTUQtVmk6ICBUeXBlIDB4Mw0KKFhFTikgQU1ELVZpOiAgRGV2X0lkIDB4NjAw
DQooWEVOKSBBTUQtVmk6ICBGbGFncyAweDANCihYRU4pIEFNRC1WaTogIERldl9JZCBSYW5n
ZTogMHg2MDAgLT4gMHg2MDENCihYRU4pIEFNRC1WaTogSVZIRCBEZXZpY2UgRW50cnk6DQoo
WEVOKSBBTUQtVmk6ICBUeXBlIDB4Mg0KKFhFTikgQU1ELVZpOiAgRGV2X0lkIDB4NjANCihY
RU4pIEFNRC1WaTogIEZsYWdzIDB4MA0KKFhFTikgQU1ELVZpOiBJVkhEIERldmljZSBFbnRy
eToNCihYRU4pIEFNRC1WaTogIFR5cGUgMHgyDQooWEVOKSBBTUQtVmk6ICBEZXZfSWQgMHg1
MDANCihYRU4pIEFNRC1WaTogIEZsYWdzIDB4MA0KKFhFTikgQU1ELVZpOiBJVkhEIERldmlj
ZSBFbnRyeToNCihYRU4pIEFNRC1WaTogIFR5cGUgMHgyDQooWEVOKSBBTUQtVmk6ICBEZXZf
SWQgMHg2OA0KKFhFTikgQU1ELVZpOiAgRmxhZ3MgMHgwDQooWEVOKSBBTUQtVmk6IElWSEQg
RGV2aWNlIEVudHJ5Og0KKFhFTikgQU1ELVZpOiAgVHlwZSAweDMNCihYRU4pIEFNRC1WaTog
IERldl9JZCAweDQwMA0KKFhFTikgQU1ELVZpOiAgRmxhZ3MgMHgwDQooWEVOKSBBTUQtVmk6
ICBEZXZfSWQgUmFuZ2U6IDB4NDAwIC0+IDB4NDA3DQooWEVOKSBBTUQtVmk6IElWSEQgRGV2
aWNlIEVudHJ5Og0KKFhFTikgQU1ELVZpOiAgVHlwZSAweDINCihYRU4pIEFNRC1WaTogIERl
dl9JZCAweDg4DQooWEVOKSBBTUQtVmk6ICBGbGFncyAweDANCihYRU4pIEFNRC1WaTogSVZI
RCBEZXZpY2UgRW50cnk6DQooWEVOKSBBTUQtVmk6ICBUeXBlIDB4Mw0KKFhFTikgQU1ELVZp
OiAgRGV2X0lkIDB4OTANCihYRU4pIEFNRC1WaTogIEZsYWdzIDB4MA0KKFhFTikgQU1ELVZp
OiAgRGV2X0lkIFJhbmdlOiAweDkwIC0+IDB4OTINCihYRU4pIEFNRC1WaTogSVZIRCBEZXZp
Y2UgRW50cnk6DQooWEVOKSBBTUQtVmk6ICBUeXBlIDB4Mw0KKFhFTikgQU1ELVZpOiAgRGV2
X0lkIDB4OTgNCihYRU4pIEFNRC1WaTogIEZsYWdzIDB4MA0KKFhFTikgQU1ELVZpOiAgRGV2
X0lkIFJhbmdlOiAweDk4IC0+IDB4OWENCihYRU4pIEFNRC1WaTogSVZIRCBEZXZpY2UgRW50
cnk6DQooWEVOKSBBTUQtVmk6ICBUeXBlIDB4Mg0KKFhFTikgQU1ELVZpOiAgRGV2X0lkIDB4
YTANCihYRU4pIEFNRC1WaTogIEZsYWdzIDB4ZDcNCihYRU4pIEFNRC1WaTogSVZIRCBEZXZp
Y2UgRW50cnk6DQooWEVOKSBBTUQtVmk6ICBUeXBlIDB4Mg0KKFhFTikgQU1ELVZpOiAgRGV2
X0lkIDB4YTMNCihYRU4pIEFNRC1WaTogIEZsYWdzIDB4MA0KKFhFTikgQU1ELVZpOiBJVkhE
IERldmljZSBFbnRyeToNCihYRU4pIEFNRC1WaTogIFR5cGUgMHgyDQooWEVOKSBBTUQtVmk6
ICBEZXZfSWQgMHhhNA0KKFhFTikgQU1ELVZpOiAgRmxhZ3MgMHgwDQooWEVOKSBBTUQtVmk6
IElWSEQgRGV2aWNlIEVudHJ5Og0KKFhFTikgQU1ELVZpOiAgVHlwZSAweDANCihYRU4pIEFN
RC1WaTogIERldl9JZCAweDANCihYRU4pIEFNRC1WaTogIEZsYWdzIDB4MA0KKFhFTikgQU1E
LVZpOiBJVkhEIERldmljZSBFbnRyeToNCihYRU4pIEFNRC1WaTogIFR5cGUgMHg0Mw0KKFhF
TikgQU1ELVZpOiAgRGV2X0lkIDB4MzAwDQooWEVOKSBBTUQtVmk6ICBGbGFncyAweDANCihY
RU4pIEFNRC1WaTogIERldl9JZCBSYW5nZTogMHgzMDAgLT4gMHgzZmYNCihYRU4pIEFNRC1W
aTogIERldl9JZCBBbGlhczogMHhhNA0KKFhFTikgQU1ELVZpOiBJVkhEIERldmljZSBFbnRy
eToNCihYRU4pIEFNRC1WaTogIFR5cGUgMHgyDQooWEVOKSBBTUQtVmk6ICBEZXZfSWQgMHhh
NQ0KKFhFTikgQU1ELVZpOiAgRmxhZ3MgMHgwDQooWEVOKSBBTUQtVmk6IElWSEQgRGV2aWNl
IEVudHJ5Og0KKFhFTikgQU1ELVZpOiAgVHlwZSAweDINCihYRU4pIEFNRC1WaTogIERldl9J
ZCAweGE4DQooWEVOKSBBTUQtVmk6ICBGbGFncyAweDANCihYRU4pIEFNRC1WaTogSVZIRCBE
ZXZpY2UgRW50cnk6DQooWEVOKSBBTUQtVmk6ICBUeXBlIDB4Mg0KKFhFTikgQU1ELVZpOiAg
RGV2X0lkIDB4YTkNCihYRU4pIEFNRC1WaTogIEZsYWdzIDB4MA0KKFhFTikgQU1ELVZpOiBJ
VkhEIERldmljZSBFbnRyeToNCihYRU4pIEFNRC1WaTogIFR5cGUgMHgyDQooWEVOKSBBTUQt
Vmk6ICBEZXZfSWQgMHgxMDANCihYRU4pIEFNRC1WaTogIEZsYWdzIDB4MA0KKFhFTikgQU1E
LVZpOiBJVkhEIERldmljZSBFbnRyeToNCihYRU4pIEFNRC1WaTogIFR5cGUgMHgzDQooWEVO
KSBBTUQtVmk6ICBEZXZfSWQgMHhiMA0KKFhFTikgQU1ELVZpOiAgRmxhZ3MgMHgwDQooWEVO
KSBBTUQtVmk6ICBEZXZfSWQgUmFuZ2U6IDB4YjAgLT4gMHhiMg0KKFhFTikgQU1ELVZpOiBJ
VkhEIERldmljZSBFbnRyeToNCihYRU4pIEFNRC1WaTogIFR5cGUgMHgwDQooWEVOKSBBTUQt
Vmk6ICBEZXZfSWQgMHgwDQooWEVOKSBBTUQtVmk6ICBGbGFncyAweDANCihYRU4pIEFNRC1W
aTogSVZIRCBEZXZpY2UgRW50cnk6DQooWEVOKSBBTUQtVmk6ICBUeXBlIDB4NDgNCihYRU4p
IEFNRC1WaTogIERldl9JZCAweDANCihYRU4pIEFNRC1WaTogIEZsYWdzIDB4ZDcNCihYRU4p
IEFNRC1WaTogSVZIRCBEZXZpY2UgRW50cnk6DQooWEVOKSBBTUQtVmk6ICBUeXBlIDB4NDgN
CihYRU4pIEFNRC1WaTogIERldl9JZCAweDANCihYRU4pIEFNRC1WaTogIEZsYWdzIDB4MA0K
KFhFTikgQU1ELVZpOiBJT01NVSAwIEVuYWJsZWQuDQooWEVOKSBBTUQtVmk6IEVuYWJsaW5n
IGdsb2JhbCB2ZWN0b3IgbWFwDQooWEVOKSBJL08gdmlydHVhbGlzYXRpb24gZW5hYmxlZA0K
KFhFTikgIC0gRG9tMCBtb2RlOiBSZWxheGVkDQooWEVOKSBHZXR0aW5nIFZFUlNJT046IDgw
MDUwMDEwDQooWEVOKSBHZXR0aW5nIFZFUlNJT046IDgwMDUwMDEwDQooWEVOKSBHZXR0aW5n
IElEOiAwDQooWEVOKSBHZXR0aW5nIExWVDA6IDcwMA0KKFhFTikgR2V0dGluZyBMVlQxOiA0
MDANCihYRU4pIGVuYWJsZWQgRXh0SU5UIG9uIENQVSMwDQooWEVOKSBFU1IgdmFsdWUgYmVm
b3JlIGVuYWJsaW5nIHZlY3RvcjogMHgwMDAwMDAwNCAgYWZ0ZXI6IDB4MDAwMDAwMDANCihY
RU4pIEVOQUJMSU5HIElPLUFQSUMgSVJRcw0KKFhFTikgIC0+IFVzaW5nIG5ldyBBQ0sgbWV0
aG9kDQooWEVOKSBpbml0IElPX0FQSUMgSVJRcw0KKFhFTikgIElPLUFQSUMgKGFwaWNpZC1w
aW4pIDYtMCwgNi0xNiwgNi0xNywgNi0xOCwgNi0xOSwgNi0yMCwgNi0yMSwgNi0yMiwgNi0y
MywgNy0wLCA3LTEsIDctMiwgNy0zLCA3LTQsIDctNSwgNy02LCA3LTcsIDctOCwgNy05LCA3
LTEwLCA3LTExLCA3LTEyLCA3LTEzLCA3LTE0LCA3LTE1LCA3LTE2LCA3LTE3LCA3LTE4LCA3
LTE5LCA3LTIwLCA3LTIxLCA3LTIyLCA3LTIzLCA3LTI0LCA3LTI1LCA3LTI2LCA3LTI3LCA3
LTI4LCA3LTI5LCA3LTMwLCA3LTMxIG5vdCBjb25uZWN0ZWQuDQooWEVOKSAuLlRJTUVSOiB2
ZWN0b3I9MHhGMCBhcGljMT0wIHBpbjE9MiBhcGljMj0tMSBwaW4yPS0xDQooWEVOKSBudW1i
ZXIgb2YgTVAgSVJRIHNvdXJjZXM6IDE1Lg0KKFhFTikgbnVtYmVyIG9mIElPLUFQSUMgIzYg
cmVnaXN0ZXJzOiAyNC4NCihYRU4pIG51bWJlciBvZiBJTy1BUElDICM3IHJlZ2lzdGVyczog
MzIuDQooWEVOKSB0ZXN0aW5nIHRoZSBJTyBBUElDLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4N
CihYRU4pIElPIEFQSUMgIzYuLi4uLi4NCihYRU4pIC4uLi4gcmVnaXN0ZXIgIzAwOiAwNjAw
MDAwMA0KKFhFTikgLi4uLi4uLiAgICA6IHBoeXNpY2FsIEFQSUMgaWQ6IDA2DQooWEVOKSAu
Li4uLi4uICAgIDogRGVsaXZlcnkgVHlwZTogMA0KKFhFTikgLi4uLi4uLiAgICA6IExUUyAg
ICAgICAgICA6IDANCihYRU4pIC4uLi4gcmVnaXN0ZXIgIzAxOiAwMDE3ODAyMQ0KKFhFTikg
Li4uLi4uLiAgICAgOiBtYXggcmVkaXJlY3Rpb24gZW50cmllczogMDAxNw0KKFhFTikgLi4u
Li4uLiAgICAgOiBQUlEgaW1wbGVtZW50ZWQ6IDENCihYRU4pIC4uLi4uLi4gICAgIDogSU8g
QVBJQyB2ZXJzaW9uOiAwMDIxDQooWEVOKSAuLi4uIHJlZ2lzdGVyICMwMjogMDYwMDAwMDAN
CihYRU4pIC4uLi4uLi4gICAgIDogYXJiaXRyYXRpb246IDA2DQooWEVOKSAuLi4uIHJlZ2lz
dGVyICMwMzogMDcwMDAwMDANCihYRU4pIC4uLi4uLi4gICAgIDogQm9vdCBEVCAgICA6IDAN
CihYRU4pIC4uLi4gSVJRIHJlZGlyZWN0aW9uIHRhYmxlOg0KKFhFTikgIE5SIExvZyBQaHkg
TWFzayBUcmlnIElSUiBQb2wgU3RhdCBEZXN0IERlbGkgVmVjdDogICANCihYRU4pICAwMCAw
MDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwDQooWEVOKSAgMDEg
MDAxIDAxICAwICAgIDAgICAgMCAgIDAgICAwICAgIDEgICAgMSAgICAzMA0KKFhFTikgIDAy
IDAwMSAwMSAgMCAgICAwICAgIDAgICAwICAgMCAgICAxICAgIDEgICAgRjANCihYRU4pICAw
MyAwMDEgMDEgIDAgICAgMCAgICAwICAgMCAgIDAgICAgMSAgICAxICAgIDM4DQooWEVOKSAg
MDQgMDAxIDAxICAwICAgIDAgICAgMCAgIDAgICAwICAgIDEgICAgMSAgICBGMQ0KKFhFTikg
IDA1IDAwMSAwMSAgMCAgICAwICAgIDAgICAwICAgMCAgICAxICAgIDEgICAgNDANCihYRU4p
ICAwNiAwMDEgMDEgIDAgICAgMCAgICAwICAgMCAgIDAgICAgMSAgICAxICAgIDQ4DQooWEVO
KSAgMDcgMDAxIDAxICAwICAgIDAgICAgMCAgIDAgICAwICAgIDEgICAgMSAgICA1MA0KKFhF
TikgIDA4IDAwMSAwMSAgMCAgICAwICAgIDAgICAwICAgMCAgICAxICAgIDEgICAgNTgNCihY
RU4pICAwOSAwMDEgMDEgIDEgICAgMSAgICAwICAgMSAgIDAgICAgMSAgICAxICAgIDYwDQoo
WEVOKSAgMGEgMDAxIDAxICAwICAgIDAgICAgMCAgIDAgICAwICAgIDEgICAgMSAgICA2OA0K
KFhFTikgIDBiIDAwMSAwMSAgMCAgICAwICAgIDAgICAwICAgMCAgICAxICAgIDEgICAgNzAN
CihYRU4pICAwYyAwMDEgMDEgIDAgICAgMCAgICAwICAgMCAgIDAgICAgMSAgICAxICAgIDc4
DQooWEVOKSAgMGQgMDAxIDAxICAwICAgIDAgICAgMCAgIDAgICAwICAgIDEgICAgMSAgICA4
OA0KKFhFTikgIDBlIDAwMSAwMSAgMCAgICAwICAgIDAgICAwICAgMCAgICAxICAgIDEgICAg
OTANCihYRU4pICAwZiAwMDEgMDEgIDAgICAgMCAgICAwICAgMCAgIDAgICAgMSAgICAxICAg
IDk4DQooWEVOKSAgMTAgMDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAwICAgIDAgICAgMCAg
ICAwMA0KKFhFTikgIDExIDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDAg
ICAgMDANCihYRU4pICAxMiAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAw
ICAgIDAwDQooWEVOKSAgMTMgMDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAwICAgIDAgICAg
MCAgICAwMA0KKFhFTikgIDE0IDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAg
IDAgICAgMDANCihYRU4pICAxNSAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAg
ICAwICAgIDAwDQooWEVOKSAgMTYgMDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAwICAgIDAg
ICAgMCAgICAwMA0KKFhFTikgIDE3IDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAw
ICAgIDAgICAgMDANCihYRU4pIElPIEFQSUMgIzcuLi4uLi4NCihYRU4pIC4uLi4gcmVnaXN0
ZXIgIzAwOiAwNzAwMDAwMA0KKFhFTikgLi4uLi4uLiAgICA6IHBoeXNpY2FsIEFQSUMgaWQ6
IDA3DQooWEVOKSAuLi4uLi4uICAgIDogRGVsaXZlcnkgVHlwZTogMA0KKFhFTikgLi4uLi4u
LiAgICA6IExUUyAgICAgICAgICA6IDANCihYRU4pIC4uLi4gcmVnaXN0ZXIgIzAxOiAwMDFG
ODAyMQ0KKFhFTikgLi4uLi4uLiAgICAgOiBtYXggcmVkaXJlY3Rpb24gZW50cmllczogMDAx
Rg0KKFhFTikgLi4uLi4uLiAgICAgOiBQUlEgaW1wbGVtZW50ZWQ6IDENCihYRU4pIC4uLi4u
Li4gICAgIDogSU8gQVBJQyB2ZXJzaW9uOiAwMDIxDQooWEVOKSAuLi4uIHJlZ2lzdGVyICMw
MjogMDAwMDAwMDANCihYRU4pIC4uLi4uLi4gICAgIDogYXJiaXRyYXRpb246IDAwDQooWEVO
KSAuLi4uIElSUSByZWRpcmVjdGlvbiB0YWJsZToNCihYRU4pICBOUiBMb2cgUGh5IE1hc2sg
VHJpZyBJUlIgUG9sIFN0YXQgRGVzdCBEZWxpIFZlY3Q6ICAgDQooWEVOKSAgMDAgMDAwIDAw
ICAxICAgIDAgICAgMCAgIDAgICAwICAgIDAgICAgMCAgICAwMA0KKFhFTikgIDAxIDAwMCAw
MCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDAgICAgMDANCihYRU4pICAwMiAwMDAg
MDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwDQooWEVOKSAgMDMgMDAw
IDAwICAxICAgIDAgICAgMCAgIDAgICAwICAgIDAgICAgMCAgICAwMA0KKFhFTikgIDA0IDAw
MCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDAgICAgMDANCihYRU4pICAwNSAw
MDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwDQooWEVOKSAgMDYg
MDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAwICAgIDAgICAgMCAgICAwMA0KKFhFTikgIDA3
IDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDAgICAgMDANCihYRU4pICAw
OCAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwDQooWEVOKSAg
MDkgMDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAwICAgIDAgICAgMCAgICAwMA0KKFhFTikg
IDBhIDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDAgICAgMDANCihYRU4p
ICAwYiAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwDQooWEVO
KSAgMGMgMDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAwICAgIDAgICAgMCAgICAwMA0KKFhF
TikgIDBkIDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDAgICAgMDANCihY
RU4pICAwZSAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwDQoo
WEVOKSAgMGYgMDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAwICAgIDAgICAgMCAgICAwMA0K
KFhFTikgIDEwIDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDAgICAgMDAN
CihYRU4pICAxMSAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAw
DQooWEVOKSAgMTIgMDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAwICAgIDAgICAgMCAgICAw
MA0KKFhFTikgIDEzIDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDAgICAg
MDANCihYRU4pICAxNCAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAg
IDAwDQooWEVOKSAgMTUgMDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAwICAgIDAgICAgMCAg
ICAwMA0KKFhFTikgIDE2IDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDAg
ICAgMDANCihYRU4pICAxNyAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAw
ICAgIDAwDQooWEVOKSAgMTggMDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAwICAgIDAgICAg
MCAgICAwMA0KKFhFTikgIDE5IDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAg
IDAgICAgMDANCihYRU4pICAxYSAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAg
ICAwICAgIDAwDQooWEVOKSAgMWIgMDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAwICAgIDAg
ICAgMCAgICAwMA0KKFhFTikgIDFjIDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAw
ICAgIDAgICAgMDANCihYRU4pICAxZCAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAg
MCAgICAwICAgIDAwDQooWEVOKSAgMWUgMDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAwICAg
IDAgICAgMCAgICAwMA0KKFhFTikgIDFmIDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAg
ICAwICAgIDAgICAgMDANCihYRU4pIFVzaW5nIHZlY3Rvci1iYXNlZCBpbmRleGluZw0KKFhF
TikgSVJRIHRvIHBpbiBtYXBwaW5nczoNCihYRU4pIElSUTI0MCAtPiAwOjINCihYRU4pIElS
UTQ4IC0+IDA6MQ0KKFhFTikgSVJRNTYgLT4gMDozDQooWEVOKSBJUlEyNDEgLT4gMDo0DQoo
WEVOKSBJUlE2NCAtPiAwOjUNCihYRU4pIElSUTcyIC0+IDA6Ng0KKFhFTikgSVJRODAgLT4g
MDo3DQooWEVOKSBJUlE4OCAtPiAwOjgNCihYRU4pIElSUTk2IC0+IDA6OQ0KKFhFTikgSVJR
MTA0IC0+IDA6MTANCihYRU4pIElSUTExMiAtPiAwOjExDQooWEVOKSBJUlExMjAgLT4gMDox
Mg0KKFhFTikgSVJRMTM2IC0+IDA6MTMNCihYRU4pIElSUTE0NCAtPiAwOjE0DQooWEVOKSBJ
UlExNTIgLT4gMDoxNQ0KKFhFTikgLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u
Li4uIGRvbmUuDQooWEVOKSBVc2luZyBsb2NhbCBBUElDIHRpbWVyIGludGVycnVwdHMuDQoo
WEVOKSBjYWxpYnJhdGluZyBBUElDIHRpbWVyIC4uLg0KKFhFTikgLi4uLi4gQ1BVIGNsb2Nr
IHNwZWVkIGlzIDMyMDAuMTI3MCBNSHouDQooWEVOKSAuLi4uLiBob3N0IGJ1cyBjbG9jayBz
cGVlZCBpcyAyMDAuMDA3OSBNSHouDQooWEVOKSAuLi4uLiBidXNfc2NhbGUgPSAweDAwMDBD
Q0Q3DQooWEVOKSBbMjAxMi0wOS0wMyAyMDo1NTozMV0gUGxhdGZvcm0gdGltZXIgaXMgMTQu
MzE4TUh6IEhQRVQNCihYRU4pIFsyMDEyLTA5LTAzIDIwOjU1OjMxXSBBbGxvY2F0ZWQgY29u
c29sZSByaW5nIG9mIDY0IEtpQi4NCihYRU4pIFsyMDEyLTA5LTAzIDIwOjU1OjMxXSBIVk06
IEFTSURzIGVuYWJsZWQuDQooWEVOKSBbMjAxMi0wOS0wMyAyMDo1NTozMV0gU1ZNOiBTdXBw
b3J0ZWQgYWR2YW5jZWQgZmVhdHVyZXM6DQooWEVOKSBbMjAxMi0wOS0wMyAyMDo1NTozMV0g
IC0gTmVzdGVkIFBhZ2UgVGFibGVzIChOUFQpDQooWEVOKSBbMjAxMi0wOS0wMyAyMDo1NToz
MV0gIC0gTGFzdCBCcmFuY2ggUmVjb3JkIChMQlIpIFZpcnR1YWxpc2F0aW9uDQooWEVOKSBb
MjAxMi0wOS0wMyAyMDo1NTozMV0gIC0gTmV4dC1SSVAgU2F2ZWQgb24gI1ZNRVhJVA0KKFhF
TikgWzIwMTItMDktMDMgMjA6NTU6MzFdICAtIFBhdXNlLUludGVyY2VwdCBGaWx0ZXINCihY
RU4pIFsyMDEyLTA5LTAzIDIwOjU1OjMxXSBIVk06IFNWTSBlbmFibGVkDQooWEVOKSBbMjAx
Mi0wOS0wMyAyMDo1NTozMV0gSFZNOiBIYXJkd2FyZSBBc3Npc3RlZCBQYWdpbmcgKEhBUCkg
ZGV0ZWN0ZWQNCihYRU4pIFsyMDEyLTA5LTAzIDIwOjU1OjMxXSBIVk06IEhBUCBwYWdlIHNp
emVzOiA0a0IsIDJNQiwgMUdCDQooWEVOKSBbMjAxMi0wOS0wMyAyMDo1NTozMF0gbWFza2Vk
IEV4dElOVCBvbiBDUFUjMQ0KKFhFTikgWzIwMTItMDktMDMgMjA6NTU6MzFdIG1pY3JvY29k
ZTogY29sbGVjdF9jcHVfaW5mbzogcGF0Y2hfaWQ9MHgxMDAwMGJmDQooWEVOKSBbMjAxMi0w
OS0wMyAyMDo1NTozMF0gbWFza2VkIEV4dElOVCBvbiBDUFUjMg0KKFhFTikgWzIwMTItMDkt
MDMgMjA6NTU6MzFdIG1pY3JvY29kZTogY29sbGVjdF9jcHVfaW5mbzogcGF0Y2hfaWQ9MHgx
MDAwMGJmDQooWEVOKSBbMjAxMi0wOS0wMyAyMDo1NTozMF0gbWFza2VkIEV4dElOVCBvbiBD
UFUjMw0KKFhFTikgWzIwMTItMDktMDMgMjA6NTU6MzFdIG1pY3JvY29kZTogY29sbGVjdF9j
cHVfaW5mbzogcGF0Y2hfaWQ9MHgxMDAwMGJmDQooWEVOKSBbMjAxMi0wOS0wMyAyMDo1NToz
MF0gbWFza2VkIEV4dElOVCBvbiBDUFUjNA0KKFhFTikgWzIwMTItMDktMDMgMjA6NTU6MzFd
IG1pY3JvY29kZTogY29sbGVjdF9jcHVfaW5mbzogcGF0Y2hfaWQ9MHgxMDAwMGJmDQooWEVO
KSBbMjAxMi0wOS0wMyAyMDo1NTozMF0gbWFza2VkIEV4dElOVCBvbiBDUFUjNQ0KKFhFTikg
WzIwMTItMDktMDMgMjA6NTU6MzFdIEJyb3VnaHQgdXAgNiBDUFVzDQooWEVOKSBbMjAxMi0w
OS0wMyAyMDo1NTozMV0gbWljcm9jb2RlOiBjb2xsZWN0X2NwdV9pbmZvOiBwYXRjaF9pZD0w
eDEwMDAwYmYNCihYRU4pIFsyMDEyLTA5LTAzIDIwOjU1OjMxXSBIUEVUJ3MgTVNJIG1vZGUg
aGFzbid0IGJlZW4gc3VwcG9ydGVkIHdoZW4gSW50ZXJydXB0IFJlbWFwcGluZyBpcyBlbmFi
bGVkLg0KKFhFTikgWzIwMTItMDktMDMgMjA6NTU6MzFdIEFDUEkgc2xlZXAgbW9kZXM6IFMz
DQooWEVOKSBbMjAxMi0wOS0wMyAyMDo1NTozMV0gTUNBOiBVc2UgaHcgdGhyZXNob2xkaW5n
IHRvIGFkanVzdCBwb2xsaW5nIGZyZXF1ZW5jeQ0KKFhFTikgWzIwMTItMDktMDMgMjA6NTU6
MzFdIG1jaGVja19wb2xsOiBNYWNoaW5lIGNoZWNrIHBvbGxpbmcgdGltZXIgc3RhcnRlZC4N
CihYRU4pIFsyMDEyLTA5LTAzIDIwOjU1OjMxXSBYZW5vcHJvZmlsZTogRmFpbGVkIHRvIHNl
dHVwIElCUyBMVlQgb2Zmc2V0LCBJQlNDVEwgPSAweGZmZmZmZmZmDQooWEVOKSBbMjAxMi0w
OS0wMyAyMDo1NTozMV0gKioqIExPQURJTkcgRE9NQUlOIDAgKioqDQooWEVOKSBbMjAxMi0w
OS0wMyAyMDo1NTozMV0gZWxmX3BhcnNlX2JpbmFyeTogcGhkcjogcGFkZHI9MHgxMDAwMDAw
IG1lbXN6PTB4ZDZhMDAwDQooWEVOKSBbMjAxMi0wOS0wMyAyMDo1NTozMV0gZWxmX3BhcnNl
X2JpbmFyeTogcGhkcjogcGFkZHI9MHgxZTAwMDAwIG1lbXN6PTB4ZGIwZTgNCihYRU4pIFsy
MDEyLTA5LTAzIDIwOjU1OjMxXSBlbGZfcGFyc2VfYmluYXJ5OiBwaGRyOiBwYWRkcj0weDFl
ZGMwMDAgbWVtc3o9MHgxM2MwMA0KKFhFTikgWzIwMTItMDktMDMgMjA6NTU6MzFdIGVsZl9w
YXJzZV9iaW5hcnk6IHBoZHI6IHBhZGRyPTB4MWVmMDAwMCBtZW1zej0weGRlNTAwMA0KKFhF
TikgWzIwMTItMDktMDMgMjA6NTU6MzFdIGVsZl9wYXJzZV9iaW5hcnk6IG1lbW9yeTogMHgx
MDAwMDAwIC0+IDB4MmNkNTAwMA0KKFhFTikgWzIwMTItMDktMDMgMjA6NTU6MzFdIGVsZl94
ZW5fcGFyc2Vfbm90ZTogR1VFU1RfT1MgPSAibGludXgiDQooWEVOKSBbMjAxMi0wOS0wMyAy
MDo1NTozMV0gZWxmX3hlbl9wYXJzZV9ub3RlOiBHVUVTVF9WRVJTSU9OID0gIjIuNiINCihY
RU4pIFsyMDEyLTA5LTAzIDIwOjU1OjMxXSBlbGZfeGVuX3BhcnNlX25vdGU6IFhFTl9WRVJT
SU9OID0gInhlbi0zLjAiDQooWEVOKSBbMjAxMi0wOS0wMyAyMDo1NTozMV0gZWxmX3hlbl9w
YXJzZV9ub3RlOiBWSVJUX0JBU0UgPSAweGZmZmZmZmZmODAwMDAwMDANCihYRU4pIFsyMDEy
LTA5LTAzIDIwOjU1OjMxXSBlbGZfeGVuX3BhcnNlX25vdGU6IEVOVFJZID0gMHhmZmZmZmZm
ZjgxZWYwMjEwDQooWEVOKSBbMjAxMi0wOS0wMyAyMDo1NTozMV0gZWxmX3hlbl9wYXJzZV9u
b3RlOiBIWVBFUkNBTExfUEFHRSA9IDB4ZmZmZmZmZmY4MTAwMTAwMA0KKFhFTikgWzIwMTIt
MDktMDMgMjA6NTU6MzFdIGVsZl94ZW5fcGFyc2Vfbm90ZTogRkVBVFVSRVMgPSAiIXdyaXRh
YmxlX3BhZ2VfdGFibGVzfHBhZV9wZ2Rpcl9hYm92ZV80Z2IiDQooWEVOKSBbMjAxMi0wOS0w
MyAyMDo1NTozMV0gZWxmX3hlbl9wYXJzZV9ub3RlOiBQQUVfTU9ERSA9ICJ5ZXMiDQooWEVO
KSBbMjAxMi0wOS0wMyAyMDo1NTozMV0gZWxmX3hlbl9wYXJzZV9ub3RlOiBMT0FERVIgPSAi
Z2VuZXJpYyINCihYRU4pIFsyMDEyLTA5LTAzIDIwOjU1OjMxXSBlbGZfeGVuX3BhcnNlX25v
dGU6IHVua25vd24geGVuIGVsZiBub3RlICgweGQpDQooWEVOKSBbMjAxMi0wOS0wMyAyMDo1
NTozMV0gZWxmX3hlbl9wYXJzZV9ub3RlOiBTVVNQRU5EX0NBTkNFTCA9IDB4MQ0KKFhFTikg
WzIwMTItMDktMDMgMjA6NTU6MzFdIGVsZl94ZW5fcGFyc2Vfbm90ZTogSFZfU1RBUlRfTE9X
ID0gMHhmZmZmODAwMDAwMDAwMDAwDQooWEVOKSBbMjAxMi0wOS0wMyAyMDo1NTozMV0gZWxm
X3hlbl9wYXJzZV9ub3RlOiBQQUREUl9PRkZTRVQgPSAweDANCihYRU4pIFsyMDEyLTA5LTAz
IDIwOjU1OjMxXSBlbGZfeGVuX2FkZHJfY2FsY19jaGVjazogYWRkcmVzc2VzOg0KKFhFTikg
WzIwMTItMDktMDMgMjA6NTU6MzFdICAgICB2aXJ0X2Jhc2UgICAgICAgID0gMHhmZmZmZmZm
ZjgwMDAwMDAwDQooWEVOKSBbMjAxMi0wOS0wMyAyMDo1NTozMV0gICAgIGVsZl9wYWRkcl9v
ZmZzZXQgPSAweDANCihYRU4pIFsyMDEyLTA5LTAzIDIwOjU1OjMxXSAgICAgdmlydF9vZmZz
ZXQgICAgICA9IDB4ZmZmZmZmZmY4MDAwMDAwMA0KKFhFTikgWzIwMTItMDktMDMgMjA6NTU6
MzFdICAgICB2aXJ0X2tzdGFydCAgICAgID0gMHhmZmZmZmZmZjgxMDAwMDAwDQooWEVOKSBb
MjAxMi0wOS0wMyAyMDo1NTozMV0gICAgIHZpcnRfa2VuZCAgICAgICAgPSAweGZmZmZmZmZm
ODJjZDUwMDANCihYRU4pIFsyMDEyLTA5LTAzIDIwOjU1OjMxXSAgICAgdmlydF9lbnRyeSAg
ICAgICA9IDB4ZmZmZmZmZmY4MWVmMDIxMA0KKFhFTikgWzIwMTItMDktMDMgMjA6NTU6MzFd
ICAgICBwMm1fYmFzZSAgICAgICAgID0gMHhmZmZmZmZmZmZmZmZmZmZmDQooWEVOKSBbMjAx
Mi0wOS0wMyAyMDo1NTozMV0gIFhlbiAga2VybmVsOiA2NC1iaXQsIGxzYiwgY29tcGF0MzIN
CihYRU4pIFsyMDEyLTA5LTAzIDIwOjU1OjMxXSAgRG9tMCBrZXJuZWw6IDY0LWJpdCwgUEFF
LCBsc2IsIHBhZGRyIDB4MTAwMDAwMCAtPiAweDJjZDUwMDANCihYRU4pIFsyMDEyLTA5LTAz
IDIwOjU1OjMxXSBQSFlTSUNBTCBNRU1PUlkgQVJSQU5HRU1FTlQ6DQooWEVOKSBbMjAxMi0w
OS0wMyAyMDo1NTozMV0gIERvbTAgYWxsb2MuOiAgIDAwMDAwMDAyNDAwMDAwMDAtPjAwMDAw
MDAyNDQwMDAwMDAgKDI0MjQyOCBwYWdlcyB0byBiZSBhbGxvY2F0ZWQpDQooWEVOKSBbMjAx
Mi0wOS0wMyAyMDo1NTozMV0gIEluaXQuIHJhbWRpc2s6IDAwMDAwMDAyNGYyZmMwMDAtPjAw
MDAwMDAyNGZmZmY4MDANCihYRU4pIFsyMDEyLTA5LTAzIDIwOjU1OjMxXSBWSVJUVUFMIE1F
TU9SWSBBUlJBTkdFTUVOVDoNCihYRU4pIFsyMDEyLTA5LTAzIDIwOjU1OjMxXSAgTG9hZGVk
IGtlcm5lbDogZmZmZmZmZmY4MTAwMDAwMC0+ZmZmZmZmZmY4MmNkNTAwMA0KKFhFTikgWzIw
MTItMDktMDMgMjA6NTU6MzFdICBJbml0LiByYW1kaXNrOiBmZmZmZmZmZjgyY2Q1MDAwLT5m
ZmZmZmZmZjgzOWQ4ODAwDQooWEVOKSBbMjAxMi0wOS0wMyAyMDo1NTozMV0gIFBoeXMtTWFj
aCBtYXA6IGZmZmZmZmZmODM5ZDkwMDAtPmZmZmZmZmZmODNiZDkwMDANCihYRU4pIFsyMDEy
LTA5LTAzIDIwOjU1OjMxXSAgU3RhcnQgaW5mbzogICAgZmZmZmZmZmY4M2JkOTAwMC0+ZmZm
ZmZmZmY4M2JkOTRiNA0KKFhFTikgWzIwMTItMDktMDMgMjA6NTU6MzFdICBQYWdlIHRhYmxl
czogICBmZmZmZmZmZjgzYmRhMDAwLT5mZmZmZmZmZjgzYmZkMDAwDQooWEVOKSBbMjAxMi0w
OS0wMyAyMDo1NTozMV0gIEJvb3Qgc3RhY2s6ICAgIGZmZmZmZmZmODNiZmQwMDAtPmZmZmZm
ZmZmODNiZmUwMDANCihYRU4pIFsyMDEyLTA5LTAzIDIwOjU1OjMxXSAgVE9UQUw6ICAgICAg
ICAgZmZmZmZmZmY4MDAwMDAwMC0+ZmZmZmZmZmY4NDAwMDAwMA0KKFhFTikgWzIwMTItMDkt
MDMgMjA6NTU6MzFdICBFTlRSWSBBRERSRVNTOiBmZmZmZmZmZjgxZWYwMjEwDQooWEVOKSBb
MjAxMi0wOS0wMyAyMDo1NTozMV0gRG9tMCBoYXMgbWF4aW11bSA2IFZDUFVzDQooWEVOKSBb
MjAxMi0wOS0wMyAyMDo1NTozMl0gZWxmX2xvYWRfYmluYXJ5OiBwaGRyIDAgYXQgMHhmZmZm
ZmZmZjgxMDAwMDAwIC0+IDB4ZmZmZmZmZmY4MWQ2YTAwMA0KKFhFTikgWzIwMTItMDktMDMg
MjA6NTU6MzJdIGVsZl9sb2FkX2JpbmFyeTogcGhkciAxIGF0IDB4ZmZmZmZmZmY4MWUwMDAw
MCAtPiAweGZmZmZmZmZmODFlZGIwZTgNCihYRU4pIFsyMDEyLTA5LTAzIDIwOjU1OjMyXSBl
bGZfbG9hZF9iaW5hcnk6IHBoZHIgMiBhdCAweGZmZmZmZmZmODFlZGMwMDAgLT4gMHhmZmZm
ZmZmZjgxZWVmYzAwDQooWEVOKSBbMjAxMi0wOS0wMyAyMDo1NTozMl0gZWxmX2xvYWRfYmlu
YXJ5OiBwaGRyIDMgYXQgMHhmZmZmZmZmZjgxZWYwMDAwIC0+IDB4ZmZmZmZmZmY4MWY4OTAw
MA0KKFhFTikgWzIwMTItMDktMDMgMjA6NTU6MzJdIEFNRC1WaTogTUUgSEVSRSAhPDI+QU1E
LVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHgwMDAwLCByb290IHRh
YmxlID0gMHgyNGQ4NGIwMDAsIGRvbWFpbiA9IDAsIHBhZ2luZyBtb2RlID0gMw0KKFhFTikg
WzIwMTItMDktMDMgMjA6NTU6MzJdIEFNRC1WaTogU2V0dXAgSS9PIHBhZ2UgdGFibGU6IGRl
dmljZSBpZCA9IDB4MDAwMiwgcm9vdCB0YWJsZSA9IDB4MjRkODRiMDAwLCBkb21haW4gPSAw
LCBwYWdpbmcgbW9kZSA9IDMNCihYRU4pIFsyMDEyLTA5LTAzIDIwOjU1OjMyXSBBTUQtVmk6
IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweDAwMTAsIHJvb3QgdGFibGUg
PSAweDI0ZDg0YjAwMCwgZG9tYWluID0gMCwgcGFnaW5nIG1vZGUgPSAzDQooWEVOKSBbMjAx
Mi0wOS0wMyAyMDo1NTozMl0gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNl
IGlkID0gMHgwMDE4LCByb290IHRhYmxlID0gMHgyNGQ4NGIwMDAsIGRvbWFpbiA9IDAsIHBh
Z2luZyBtb2RlID0gMw0KKFhFTikgWzIwMTItMDktMDMgMjA6NTU6MzJdIEFNRC1WaTogU2V0
dXAgSS9PIHBhZ2UgdGFibGU6IGRldmljZSBpZCA9IDB4MDAyOCwgcm9vdCB0YWJsZSA9IDB4
MjRkODRiMDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMNCihYRU4pIFsyMDEyLTA5
LTAzIDIwOjU1OjMyXSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQg
PSAweDAwMzAsIHJvb3QgdGFibGUgPSAweDI0ZDg0YjAwMCwgZG9tYWluID0gMCwgcGFnaW5n
IG1vZGUgPSAzDQooWEVOKSBbMjAxMi0wOS0wMyAyMDo1NTozMl0gQU1ELVZpOiBTZXR1cCBJ
L08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHgwMDUwLCByb290IHRhYmxlID0gMHgyNGQ4
NGIwMDAsIGRvbWFpbiA9IDAsIHBhZ2luZyBtb2RlID0gMw0KKFhFTikgWzIwMTItMDktMDMg
MjA6NTU6MzJdIEFNRC1WaTogU2V0dXAgSS9PIHBhZ2UgdGFibGU6IGRldmljZSBpZCA9IDB4
MDA1OCwgcm9vdCB0YWJsZSA9IDB4MjRkODRiMDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9k
ZSA9IDMNCihYRU4pIFsyMDEyLTA5LTAzIDIwOjU1OjMyXSBBTUQtVmk6IFNldHVwIEkvTyBw
YWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweDAwNjAsIHJvb3QgdGFibGUgPSAweDI0ZDg0YjAw
MCwgZG9tYWluID0gMCwgcGFnaW5nIG1vZGUgPSAzDQooWEVOKSBbMjAxMi0wOS0wMyAyMDo1
NTozMl0gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHgwMDY4
LCByb290IHRhYmxlID0gMHgyNGQ4NGIwMDAsIGRvbWFpbiA9IDAsIHBhZ2luZyBtb2RlID0g
Mw0KKFhFTikgWzIwMTItMDktMDMgMjA6NTU6MzJdIEFNRC1WaTogU2V0dXAgSS9PIHBhZ2Ug
dGFibGU6IGRldmljZSBpZCA9IDB4MDA4OCwgcm9vdCB0YWJsZSA9IDB4MjRkODRiMDAwLCBk
b21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMNCihYRU4pIFsyMDEyLTA5LTAzIDIwOjU1OjMy
XSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweDAwOTAsIHJv
b3QgdGFibGUgPSAweDI0ZDg0YjAwMCwgZG9tYWluID0gMCwgcGFnaW5nIG1vZGUgPSAzDQoo
WEVOKSBbMjAxMi0wOS0wMyAyMDo1NTozMl0gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJs
ZTogZGV2aWNlIGlkID0gMHgwMDkyLCByb290IHRhYmxlID0gMHgyNGQ4NGIwMDAsIGRvbWFp
biA9IDAsIHBhZ2luZyBtb2RlID0gMw0KKFhFTikgWzIwMTItMDktMDMgMjA6NTU6MzJdIEFN
RC1WaTogU2V0dXAgSS9PIHBhZ2UgdGFibGU6IGRldmljZSBpZCA9IDB4MDA5OCwgcm9vdCB0
YWJsZSA9IDB4MjRkODRiMDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMNCihYRU4p
IFsyMDEyLTA5LTAzIDIwOjU1OjMyXSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBk
ZXZpY2UgaWQgPSAweDAwOWEsIHJvb3QgdGFibGUgPSAweDI0ZDg0YjAwMCwgZG9tYWluID0g
MCwgcGFnaW5nIG1vZGUgPSAzDQooWEVOKSBbMjAxMi0wOS0wMyAyMDo1NTozMl0gQU1ELVZp
OiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHgwMGEwLCByb290IHRhYmxl
ID0gMHgyNGQ4NGIwMDAsIGRvbWFpbiA9IDAsIHBhZ2luZyBtb2RlID0gMw0KKFhFTikgWzIw
MTItMDktMDMgMjA6NTU6MzJdIEFNRC1WaTogU2V0dXAgSS9PIHBhZ2UgdGFibGU6IGRldmlj
ZSBpZCA9IDB4MDBhMywgcm9vdCB0YWJsZSA9IDB4MjRkODRiMDAwLCBkb21haW4gPSAwLCBw
YWdpbmcgbW9kZSA9IDMNCihYRU4pIFsyMDEyLTA5LTAzIDIwOjU1OjMyXSBBTUQtVmk6IFNl
dHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweDAwYTQsIHJvb3QgdGFibGUgPSAw
eDI0ZDg0YjAwMCwgZG9tYWluID0gMCwgcGFnaW5nIG1vZGUgPSAzDQooWEVOKSBbMjAxMi0w
OS0wMyAyMDo1NTozMl0gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlk
ID0gMHgwMGE1LCByb290IHRhYmxlID0gMHgyNGQ4NGIwMDAsIGRvbWFpbiA9IDAsIHBhZ2lu
ZyBtb2RlID0gMw0KKFhFTikgWzIwMTItMDktMDMgMjA6NTU6MzJdIEFNRC1WaTogU2V0dXAg
SS9PIHBhZ2UgdGFibGU6IGRldmljZSBpZCA9IDB4MDBhOCwgcm9vdCB0YWJsZSA9IDB4MjRk
ODRiMDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMNCihYRU4pIFsyMDEyLTA5LTAz
IDIwOjU1OjMyXSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAw
eDAwYjAsIHJvb3QgdGFibGUgPSAweDI0ZDg0YjAwMCwgZG9tYWluID0gMCwgcGFnaW5nIG1v
ZGUgPSAzDQooWEVOKSBbMjAxMi0wOS0wMyAyMDo1NTozMl0gQU1ELVZpOiBTZXR1cCBJL08g
cGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHgwMGIyLCByb290IHRhYmxlID0gMHgyNGQ4NGIw
MDAsIGRvbWFpbiA9IDAsIHBhZ2luZyBtb2RlID0gMw0KKFhFTikgWzIwMTItMDktMDMgMjA6
NTU6MzJdIEFNRC1WaTogTm8gaW9tbXUgZm9yIGRldmljZSAwMDAwOjAwOjE4LjANCihYRU4p
IFsyMDEyLTA5LTAzIDIwOjU1OjMyXSBBTUQtVmk6IE5vIGlvbW11IGZvciBkZXZpY2UgMDAw
MDowMDoxOC4xDQooWEVOKSBbMjAxMi0wOS0wMyAyMDo1NTozMl0gQU1ELVZpOiBObyBpb21t
dSBmb3IgZGV2aWNlIDAwMDA6MDA6MTguMg0KKFhFTikgWzIwMTItMDktMDMgMjA6NTU6MzJd
IEFNRC1WaTogTm8gaW9tbXUgZm9yIGRldmljZSAwMDAwOjAwOjE4LjMNCihYRU4pIFsyMDEy
LTA5LTAzIDIwOjU1OjMyXSBBTUQtVmk6IE5vIGlvbW11IGZvciBkZXZpY2UgMDAwMDowMDox
OC40DQooWEVOKSBbMjAxMi0wOS0wMyAyMDo1NTozMl0gQU1ELVZpOiBTZXR1cCBJL08gcGFn
ZSB0YWJsZTogZGV2aWNlIGlkID0gMHgwNDAwLCByb290IHRhYmxlID0gMHgyNGQ4NGIwMDAs
IGRvbWFpbiA9IDAsIHBhZ2luZyBtb2RlID0gMw0KKFhFTikgWzIwMTItMDktMDMgMjA6NTU6
MzJdIEFNRC1WaTogU2V0dXAgSS9PIHBhZ2UgdGFibGU6IGRldmljZSBpZCA9IDB4MDQwMSwg
cm9vdCB0YWJsZSA9IDB4MjRkODRiMDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMN
CihYRU4pIFsyMDEyLTA5LTAzIDIwOjU1OjMyXSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRh
YmxlOiBkZXZpY2UgaWQgPSAweDA0MDIsIHJvb3QgdGFibGUgPSAweDI0ZDg0YjAwMCwgZG9t
YWluID0gMCwgcGFnaW5nIG1vZGUgPSAzDQooWEVOKSBbMjAxMi0wOS0wMyAyMDo1NTozMl0g
QU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHgwNDAzLCByb290
IHRhYmxlID0gMHgyNGQ4NGIwMDAsIGRvbWFpbiA9IDAsIHBhZ2luZyBtb2RlID0gMw0KKFhF
TikgWzIwMTItMDktMDMgMjA6NTU6MzJdIEFNRC1WaTogU2V0dXAgSS9PIHBhZ2UgdGFibGU6
IGRldmljZSBpZCA9IDB4MDQwNCwgcm9vdCB0YWJsZSA9IDB4MjRkODRiMDAwLCBkb21haW4g
PSAwLCBwYWdpbmcgbW9kZSA9IDMNCihYRU4pIFsyMDEyLTA5LTAzIDIwOjU1OjMyXSBBTUQt
Vmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweDA0MDUsIHJvb3QgdGFi
bGUgPSAweDI0ZDg0YjAwMCwgZG9tYWluID0gMCwgcGFnaW5nIG1vZGUgPSAzDQooWEVOKSBb
MjAxMi0wOS0wMyAyMDo1NTozMl0gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2
aWNlIGlkID0gMHgwNDA2LCByb290IHRhYmxlID0gMHgyNGQ4NGIwMDAsIGRvbWFpbiA9IDAs
IHBhZ2luZyBtb2RlID0gMw0KKFhFTikgWzIwMTItMDktMDMgMjA6NTU6MzJdIEFNRC1WaTog
U2V0dXAgSS9PIHBhZ2UgdGFibGU6IGRldmljZSBpZCA9IDB4MDQwNywgcm9vdCB0YWJsZSA9
IDB4MjRkODRiMDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMNCihYRU4pIFsyMDEy
LTA5LTAzIDIwOjU1OjMyXSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2Ug
aWQgPSAweDA1MDAsIHJvb3QgdGFibGUgPSAweDI0ZDg0YjAwMCwgZG9tYWluID0gMCwgcGFn
aW5nIG1vZGUgPSAzDQooWEVOKSBbMjAxMi0wOS0wMyAyMDo1NTozMl0gQU1ELVZpOiBTZXR1
cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHgwNjAwLCByb290IHRhYmxlID0gMHgy
NGQ4NGIwMDAsIGRvbWFpbiA9IDAsIHBhZ2luZyBtb2RlID0gMw0KKFhFTikgWzIwMTItMDkt
MDMgMjA6NTU6MzJdIEFNRC1WaTogU2V0dXAgSS9PIHBhZ2UgdGFibGU6IGRldmljZSBpZCA9
IDB4MDYwMSwgcm9vdCB0YWJsZSA9IDB4MjRkODRiMDAwLCBkb21haW4gPSAwLCBwYWdpbmcg
bW9kZSA9IDMNCihYRU4pIFsyMDEyLTA5LTAzIDIwOjU1OjMyXSBBTUQtVmk6IFNldHVwIEkv
TyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweDA3MDAsIHJvb3QgdGFibGUgPSAweDI0ZDg0
YjAwMCwgZG9tYWluID0gMCwgcGFnaW5nIG1vZGUgPSAzDQooWEVOKSBbMjAxMi0wOS0wMyAy
MDo1NTozMl0gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHgw
ODAwLCByb290IHRhYmxlID0gMHgyNGQ4NGIwMDAsIGRvbWFpbiA9IDAsIHBhZ2luZyBtb2Rl
ID0gMw0KKFhFTikgWzIwMTItMDktMDMgMjA6NTU6MzJdIEFNRC1WaTogU2V0dXAgSS9PIHBh
Z2UgdGFibGU6IGRldmljZSBpZCA9IDB4MDkwMCwgcm9vdCB0YWJsZSA9IDB4MjRkODRiMDAw
LCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMNCihYRU4pIFsyMDEyLTA5LTAzIDIwOjU1
OjMyXSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweDBhMDAs
IHJvb3QgdGFibGUgPSAweDI0ZDg0YjAwMCwgZG9tYWluID0gMCwgcGFnaW5nIG1vZGUgPSAz
DQooWEVOKSBbMjAxMi0wOS0wMyAyMDo1NTozMl0gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0
YWJsZTogZGV2aWNlIGlkID0gMHgwYTAxLCByb290IHRhYmxlID0gMHgyNGQ4NGIwMDAsIGRv
bWFpbiA9IDAsIHBhZ2luZyBtb2RlID0gMw0KKFhFTikgWzIwMTItMDktMDMgMjA6NTU6MzJd
IEFNRC1WaTogU2V0dXAgSS9PIHBhZ2UgdGFibGU6IGRldmljZSBpZCA9IDB4MGEwMiwgcm9v
dCB0YWJsZSA9IDB4MjRkODRiMDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMNCihY
RU4pIFsyMDEyLTA5LTAzIDIwOjU1OjMyXSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxl
OiBkZXZpY2UgaWQgPSAweDBhMDMsIHJvb3QgdGFibGUgPSAweDI0ZDg0YjAwMCwgZG9tYWlu
ID0gMCwgcGFnaW5nIG1vZGUgPSAzDQooWEVOKSBbMjAxMi0wOS0wMyAyMDo1NTozMl0gQU1E
LVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHgwYTA0LCByb290IHRh
YmxlID0gMHgyNGQ4NGIwMDAsIGRvbWFpbiA9IDAsIHBhZ2luZyBtb2RlID0gMw0KKFhFTikg
WzIwMTItMDktMDMgMjA6NTU6MzJdIEFNRC1WaTogU2V0dXAgSS9PIHBhZ2UgdGFibGU6IGRl
dmljZSBpZCA9IDB4MGEwNSwgcm9vdCB0YWJsZSA9IDB4MjRkODRiMDAwLCBkb21haW4gPSAw
LCBwYWdpbmcgbW9kZSA9IDMNCihYRU4pIFsyMDEyLTA5LTAzIDIwOjU1OjMyXSBBTUQtVmk6
IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweDBhMDYsIHJvb3QgdGFibGUg
PSAweDI0ZDg0YjAwMCwgZG9tYWluID0gMCwgcGFnaW5nIG1vZGUgPSAzDQooWEVOKSBbMjAx
Mi0wOS0wMyAyMDo1NTozMl0gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNl
IGlkID0gMHgwYTA3LCByb290IHRhYmxlID0gMHgyNGQ4NGIwMDAsIGRvbWFpbiA9IDAsIHBh
Z2luZyBtb2RlID0gMw0KKFhFTikgWzIwMTItMDktMDMgMjA6NTU6MzJdIEFNRC1WaTogU2V0
dXAgSS9PIHBhZ2UgdGFibGU6IGRldmljZSBpZCA9IDB4MGIwMCwgcm9vdCB0YWJsZSA9IDB4
MjRkODRiMDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMNCihYRU4pIFsyMDEyLTA5
LTAzIDIwOjU1OjMyXSBTY3J1YmJpbmcgRnJlZSBSQU06IC4uLi4uLi4uLi4uLi4uLi4uLi4u
Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uZG9u
ZS4NCihYRU4pIFsyMDEyLTA5LTAzIDIwOjU1OjM0XSBJbml0aWFsIGxvdyBtZW1vcnkgdmly
cSB0aHJlc2hvbGQgc2V0IGF0IDB4NDAwMCBwYWdlcy4NCihYRU4pIFsyMDEyLTA5LTAzIDIw
OjU1OjM0XSBTdGQuIExvZ2xldmVsOiBBbGwNCihYRU4pIFsyMDEyLTA5LTAzIDIwOjU1OjM0
XSBHdWVzdCBMb2dsZXZlbDogQWxsDQooWEVOKSBbMjAxMi0wOS0wMyAyMDo1NTozNF0gWGVu
IGlzIHJlbGlucXVpc2hpbmcgVkdBIGNvbnNvbGUuDQooWEVOKSBbMjAxMi0wOS0wMyAyMDo1
NTozNF0gKioqIFNlcmlhbCBpbnB1dCAtPiBET00wICh0eXBlICdDVFJMLWEnIHRocmVlIHRp
bWVzIHRvIHN3aXRjaCBpbnB1dCB0byBYZW4pDQooWEVOKSBbMjAxMi0wOS0wMyAyMDo1NToz
NF0gRnJlZWQgMjU2a0IgaW5pdCBtZW1vcnkuDQooWEVOKSBbMjAxMi0wOS0wMyAyMDo1NToz
NF0gSU9BUElDWzBdOiBTZXQgUENJIHJvdXRpbmcgZW50cnkgKDYtOSAtPiAweDYwIC0+IElS
USA5IE1vZGU6MSBBY3RpdmU6MSkNCihYRU4pIFsyMDEyLTA5LTAzIDIwOjU1OjM0XSB0cmFw
cy5jOjI1ODQ6ZDAgRG9tYWluIGF0dGVtcHRlZCBXUk1TUiAwMDAwMDAwMGMwMDAwNDA4IGZy
b20gMHhjMDAwMDAwMDAxMDAwMDAwIHRvIDB4YzAwODAwMDAwMTAwMDAwMC4NCihYRU4pIFsy
MDEyLTA5LTAzIDIwOjU1OjM0XSB0cmFwcy5jOjI1ODQ6ZDAgRG9tYWluIGF0dGVtcHRlZCBX
Uk1TUiAwMDAwMDAwMGMwMDAwNDA5IGZyb20gMHhjMDAwMDAwMDAxMDAwMDAwIHRvIDB4YzAw
ODAwMDAwMTAwMDAwMC4NCihYRU4pIFsyMDEyLTA5LTAzIDIwOjU1OjM1XSB0cmFwcy5jOjI1
ODQ6ZDAgRG9tYWluIGF0dGVtcHRlZCBXUk1TUiAwMDAwMDAwMGMwMDEwMDA0IGZyb20gMHgw
MDAwZWZmMGJkZmIxZmNlIHRvIDB4MDAwMDAwMDAwMDAwYWJjZC4NCihYRU4pIFsyMDEyLTA5
LTAzIDIwOjU1OjM1XSB0cmFwcy5jOjI1ODQ6ZDAgRG9tYWluIGF0dGVtcHRlZCBXUk1TUiAw
MDAwMDAwMGMwMDAwNDA4IGZyb20gMHhjMDAwMDAwMDAxMDAwMDAwIHRvIDB4YzAwODAwMDAw
MTAwMDAwMC4NCihYRU4pIFsyMDEyLTA5LTAzIDIwOjU1OjM1XSB0cmFwcy5jOjI1ODQ6ZDAg
RG9tYWluIGF0dGVtcHRlZCBXUk1TUiAwMDAwMDAwMGMwMDAwNDA5IGZyb20gMHhjMDAwMDAw
MDAxMDAwMDAwIHRvIDB4YzAwODAwMDAwMTAwMDAwMC4NCihYRU4pIFsyMDEyLTA5LTAzIDIw
OjU1OjM1XSB0cmFwcy5jOjI1ODQ6ZDAgRG9tYWluIGF0dGVtcHRlZCBXUk1TUiAwMDAwMDAw
MGMwMDAwNDA4IGZyb20gMHhjMDAwMDAwMDAxMDAwMDAwIHRvIDB4YzAwODAwMDAwMTAwMDAw
MC4NCihYRU4pIFsyMDEyLTA5LTAzIDIwOjU1OjM1XSB0cmFwcy5jOjI1ODQ6ZDAgRG9tYWlu
IGF0dGVtcHRlZCBXUk1TUiAwMDAwMDAwMGMwMDAwNDA5IGZyb20gMHhjMDAwMDAwMDAxMDAw
MDAwIHRvIDB4YzAwODAwMDAwMTAwMDAwMC4NCihYRU4pIFsyMDEyLTA5LTAzIDIwOjU1OjM1
XSB0cmFwcy5jOjI1ODQ6ZDAgRG9tYWluIGF0dGVtcHRlZCBXUk1TUiAwMDAwMDAwMGMwMDAw
NDA4IGZyb20gMHhjMDAwMDAwMDAxMDAwMDAwIHRvIDB4YzAwODAwMDAwMTAwMDAwMC4NCihY
RU4pIFsyMDEyLTA5LTAzIDIwOjU1OjM1XSB0cmFwcy5jOjI1ODQ6ZDAgRG9tYWluIGF0dGVt
cHRlZCBXUk1TUiAwMDAwMDAwMGMwMDAwNDA5IGZyb20gMHhjMDAwMDAwMDAxMDAwMDAwIHRv
IDB4YzAwODAwMDAwMTAwMDAwMC4NCihYRU4pIFsyMDEyLTA5LTAzIDIwOjU1OjM1XSB0cmFw
cy5jOjI1ODQ6ZDAgRG9tYWluIGF0dGVtcHRlZCBXUk1TUiAwMDAwMDAwMGMwMDAwNDA4IGZy
b20gMHhjMDAwMDAwMDAxMDAwMDAwIHRvIDB4YzAwODAwMDAwMTAwMDAwMC4NCihYRU4pIFsy
MDEyLTA5LTAzIDIwOjU1OjM1XSB0cmFwcy5jOjI1ODQ6ZDAgRG9tYWluIGF0dGVtcHRlZCBX
Uk1TUiAwMDAwMDAwMGMwMDAwNDA5IGZyb20gMHhjMDAwMDAwMDAxMDAwMDAwIHRvIDB4YzAw
ODAwMDAwMTAwMDAwMC4NCihYRU4pIFsyMDEyLTA5LTAzIDIwOjU1OjM1XSB0cmFwcy5jOjI1
ODQ6ZDAgRG9tYWluIGF0dGVtcHRlZCBXUk1TUiAwMDAwMDAwMGMwMDAwNDA4IGZyb20gMHhj
MDAwMDAwMDAxMDAwMDAwIHRvIDB4YzAwODAwMDAwMTAwMDAwMC4NCihYRU4pIFsyMDEyLTA5
LTAzIDIwOjU1OjM1XSB0cmFwcy5jOjI1ODQ6ZDAgRG9tYWluIGF0dGVtcHRlZCBXUk1TUiAw
MDAwMDAwMGMwMDAwNDA5IGZyb20gMHhjMDAwMDAwMDAxMDAwMDAwIHRvIDB4YzAwODAwMDAw
MTAwMDAwMC4NCihYRU4pIFsyMDEyLTA5LTAzIDIwOjU1OjM1XSBQQ0kgYWRkIGRldmljZSAw
MDAwOjAwOjAwLjANCihYRU4pIFsyMDEyLTA5LTAzIDIwOjU1OjM1XSBQQ0kgYWRkIGRldmlj
ZSAwMDAwOjAwOjAwLjINCihYRU4pIFsyMDEyLTA5LTAzIDIwOjU1OjM1XSBQQ0kgYWRkIGRl
dmljZSAwMDAwOjAwOjAyLjANCihYRU4pIFsyMDEyLTA5LTAzIDIwOjU1OjM1XSBQQ0kgYWRk
IGRldmljZSAwMDAwOjAwOjAzLjANCihYRU4pIFsyMDEyLTA5LTAzIDIwOjU1OjM1XSBQQ0kg
YWRkIGRldmljZSAwMDAwOjAwOjA1LjANCihYRU4pIFsyMDEyLTA5LTAzIDIwOjU1OjM1XSBQ
Q0kgYWRkIGRldmljZSAwMDAwOjAwOjA2LjANCihYRU4pIFsyMDEyLTA5LTAzIDIwOjU1OjM1
XSBQQ0kgYWRkIGRldmljZSAwMDAwOjAwOjBhLjANCihYRU4pIFsyMDEyLTA5LTAzIDIwOjU1
OjM1XSBQQ0kgYWRkIGRldmljZSAwMDAwOjAwOjBiLjANCihYRU4pIFsyMDEyLTA5LTAzIDIw
OjU1OjM1XSBQQ0kgYWRkIGRldmljZSAwMDAwOjAwOjBjLjANCihYRU4pIFsyMDEyLTA5LTAz
IDIwOjU1OjM1XSBQQ0kgYWRkIGRldmljZSAwMDAwOjAwOjBkLjANCihYRU4pIFsyMDEyLTA5
LTAzIDIwOjU1OjM1XSBQQ0kgYWRkIGRldmljZSAwMDAwOjAwOjExLjANCihYRU4pIFsyMDEy
LTA5LTAzIDIwOjU1OjM1XSBQQ0kgYWRkIGRldmljZSAwMDAwOjAwOjEyLjANCihYRU4pIFsy
MDEyLTA5LTAzIDIwOjU1OjM1XSBQQ0kgYWRkIGRldmljZSAwMDAwOjAwOjEyLjINCihYRU4p
IFsyMDEyLTA5LTAzIDIwOjU1OjM1XSBQQ0kgYWRkIGRldmljZSAwMDAwOjAwOjEzLjANCihY
RU4pIFsyMDEyLTA5LTAzIDIwOjU1OjM1XSBQQ0kgYWRkIGRldmljZSAwMDAwOjAwOjEzLjIN
CihYRU4pIFsyMDEyLTA5LTAzIDIwOjU1OjM1XSBQQ0kgYWRkIGRldmljZSAwMDAwOjAwOjE0
LjANCihYRU4pIFsyMDEyLTA5LTAzIDIwOjU1OjM1XSBQQ0kgYWRkIGRldmljZSAwMDAwOjAw
OjE0LjMNCihYRU4pIFsyMDEyLTA5LTAzIDIwOjU1OjM1XSBQQ0kgYWRkIGRldmljZSAwMDAw
OjAwOjE0LjQNCihYRU4pIFsyMDEyLTA5LTAzIDIwOjU1OjM1XSBQQ0kgYWRkIGRldmljZSAw
MDAwOjAwOjE0LjUNCihYRU4pIFsyMDEyLTA5LTAzIDIwOjU1OjM1XSBQQ0kgYWRkIGRldmlj
ZSAwMDAwOjAwOjE1LjANCihYRU4pIFsyMDEyLTA5LTAzIDIwOjU1OjM1XSBQQ0kgYWRkIGRl
dmljZSAwMDAwOjAwOjE2LjANCihYRU4pIFsyMDEyLTA5LTAzIDIwOjU1OjM1XSBQQ0kgYWRk
IGRldmljZSAwMDAwOjAwOjE2LjINCihYRU4pIFsyMDEyLTA5LTAzIDIwOjU1OjM1XSBQQ0kg
YWRkIGRldmljZSAwMDAwOjAwOjE4LjANCihYRU4pIFsyMDEyLTA5LTAzIDIwOjU1OjM1XSBQ
Q0kgYWRkIGRldmljZSAwMDAwOjAwOjE4LjENCihYRU4pIFsyMDEyLTA5LTAzIDIwOjU1OjM1
XSBQQ0kgYWRkIGRldmljZSAwMDAwOjAwOjE4LjINCihYRU4pIFsyMDEyLTA5LTAzIDIwOjU1
OjM1XSBQQ0kgYWRkIGRldmljZSAwMDAwOjAwOjE4LjMNCihYRU4pIFsyMDEyLTA5LTAzIDIw
OjU1OjM1XSBQQ0kgYWRkIGRldmljZSAwMDAwOjAwOjE4LjQNCihYRU4pIFsyMDEyLTA5LTAz
IDIwOjU1OjM1XSBQQ0kgYWRkIGRldmljZSAwMDAwOjBiOjAwLjANCihYRU4pIFsyMDEyLTA5
LTAzIDIwOjU1OjM1XSBQQ0kgYWRkIGRldmljZSAwMDAwOjBhOjAwLjANCihYRU4pIFsyMDEy
LTA5LTAzIDIwOjU1OjM1XSBQQ0kgYWRkIGRldmljZSAwMDAwOjBhOjAwLjENCihYRU4pIFsy
MDEyLTA5LTAzIDIwOjU1OjM1XSBQQ0kgYWRkIGRldmljZSAwMDAwOjBhOjAwLjINCihYRU4p
IFsyMDEyLTA5LTAzIDIwOjU1OjM1XSBQQ0kgYWRkIGRldmljZSAwMDAwOjBhOjAwLjMNCihY
RU4pIFsyMDEyLTA5LTAzIDIwOjU1OjM1XSBQQ0kgYWRkIGRldmljZSAwMDAwOjBhOjAwLjQN
CihYRU4pIFsyMDEyLTA5LTAzIDIwOjU1OjM1XSBQQ0kgYWRkIGRldmljZSAwMDAwOjBhOjAw
LjUNCihYRU4pIFsyMDEyLTA5LTAzIDIwOjU1OjM1XSBQQ0kgYWRkIGRldmljZSAwMDAwOjBh
OjAwLjYNCihYRU4pIFsyMDEyLTA5LTAzIDIwOjU1OjM1XSBQQ0kgYWRkIGRldmljZSAwMDAw
OjBhOjAwLjcNCihYRU4pIFsyMDEyLTA5LTAzIDIwOjU1OjM1XSBQQ0kgYWRkIGRldmljZSAw
MDAwOjA5OjAwLjANCihYRU4pIFsyMDEyLTA5LTAzIDIwOjU1OjM1XSBQQ0kgYWRkIGRldmlj
ZSAwMDAwOjA4OjAwLjANCihYRU4pIFsyMDEyLTA5LTAzIDIwOjU1OjM1XSBQQ0kgYWRkIGRl
dmljZSAwMDAwOjA3OjAwLjANCihYRU4pIFsyMDEyLTA5LTAzIDIwOjU1OjM1XSBQQ0kgYWRk
IGRldmljZSAwMDAwOjA2OjAwLjANCihYRU4pIFsyMDEyLTA5LTAzIDIwOjU1OjM1XSBQQ0kg
YWRkIGRldmljZSAwMDAwOjA2OjAwLjENCihYRU4pIFsyMDEyLTA5LTAzIDIwOjU1OjM1XSBQ
Q0kgYWRkIGRldmljZSAwMDAwOjA1OjAwLjANCihYRU4pIFsyMDEyLTA5LTAzIDIwOjU1OjM1
XSBQQ0kgYWRkIGRldmljZSAwMDAwOjA0OjAwLjANCihYRU4pIFsyMDEyLTA5LTAzIDIwOjU1
OjM1XSBQQ0kgYWRkIGRldmljZSAwMDAwOjA0OjAwLjENCihYRU4pIFsyMDEyLTA5LTAzIDIw
OjU1OjM1XSBQQ0kgYWRkIGRldmljZSAwMDAwOjA0OjAwLjINCihYRU4pIFsyMDEyLTA5LTAz
IDIwOjU1OjM1XSBQQ0kgYWRkIGRldmljZSAwMDAwOjA0OjAwLjMNCihYRU4pIFsyMDEyLTA5
LTAzIDIwOjU1OjM1XSBQQ0kgYWRkIGRldmljZSAwMDAwOjA0OjAwLjQNCihYRU4pIFsyMDEy
LTA5LTAzIDIwOjU1OjM1XSBQQ0kgYWRkIGRldmljZSAwMDAwOjA0OjAwLjUNCihYRU4pIFsy
MDEyLTA5LTAzIDIwOjU1OjM1XSBQQ0kgYWRkIGRldmljZSAwMDAwOjA0OjAwLjYNCihYRU4p
IFsyMDEyLTA5LTAzIDIwOjU1OjM1XSBQQ0kgYWRkIGRldmljZSAwMDAwOjA0OjAwLjcNCihY
RU4pIFsyMDEyLTA5LTAzIDIwOjU1OjM1XSBQQ0kgYWRkIGRldmljZSAwMDAwOjAzOjA2LjAN
CihYRU4pIFsyMDEyLTA5LTAzIDIwOjU1OjM1XSBJT0FQSUNbMF06IFNldCBQQ0kgcm91dGlu
ZyBlbnRyeSAoNi04IC0+IDB4NTggLT4gSVJRIDggTW9kZTowIEFjdGl2ZTowKQ0KKFhFTikg
WzIwMTItMDktMDMgMjA6NTU6MzVdIElPQVBJQ1swXTogU2V0IFBDSSByb3V0aW5nIGVudHJ5
ICg2LTEzIC0+IDB4ODggLT4gSVJRIDEzIE1vZGU6MCBBY3RpdmU6MCkNCihYRU4pIFsyMDEy
LTA5LTAzIDIwOjU1OjM1XSBJT0FQSUNbMV06IFNldCBQQ0kgcm91dGluZyBlbnRyeSAoNy0y
OCAtPiAweGEwIC0+IElSUSA1MiBNb2RlOjEgQWN0aXZlOjEpDQooWEVOKSBbMjAxMi0wOS0w
MyAyMDo1NTozNV0gSU9BUElDWzFdOiBTZXQgUENJIHJvdXRpbmcgZW50cnkgKDctMjkgLT4g
MHhhOCAtPiBJUlEgNTMgTW9kZToxIEFjdGl2ZToxKQ0KKFhFTikgWzIwMTItMDktMDMgMjA6
NTU6MzVdIElPQVBJQ1sxXTogU2V0IFBDSSByb3V0aW5nIGVudHJ5ICg3LTMwIC0+IDB4YjAg
LT4gSVJRIDU0IE1vZGU6MSBBY3RpdmU6MSkNCihYRU4pIFsyMDEyLTA5LTAzIDIwOjU1OjM1
XSBJT0FQSUNbMF06IFNldCBQQ0kgcm91dGluZyBlbnRyeSAoNi0xNiAtPiAweGI4IC0+IElS
USAxNiBNb2RlOjEgQWN0aXZlOjEpDQooWEVOKSBbMjAxMi0wOS0wMyAyMDo1NTozNV0gSU9B
UElDWzBdOiBTZXQgUENJIHJvdXRpbmcgZW50cnkgKDYtMTggLT4gMHhjMCAtPiBJUlEgMTgg
TW9kZToxIEFjdGl2ZToxKQ0KKFhFTikgWzIwMTItMDktMDMgMjA6NTU6MzVdIElPQVBJQ1sw
XTogU2V0IFBDSSByb3V0aW5nIGVudHJ5ICg2LTE3IC0+IDB4YzggLT4gSVJRIDE3IE1vZGU6
MSBBY3RpdmU6MSkNCihYRU4pIFsyMDEyLTA5LTAzIDIwOjU1OjM1XSBJT0FQSUNbMV06IFNl
dCBQQ0kgcm91dGluZyBlbnRyeSAoNy00IC0+IDB4ZDAgLT4gSVJRIDI4IE1vZGU6MSBBY3Rp
dmU6MSkNCihYRU4pIFsyMDEyLTA5LTAzIDIwOjU1OjM1XSBJT0FQSUNbMV06IFNldCBQQ0kg
cm91dGluZyBlbnRyeSAoNy01IC0+IDB4ZDggLT4gSVJRIDI5IE1vZGU6MSBBY3RpdmU6MSkN
CihYRU4pIFsyMDEyLTA5LTAzIDIwOjU1OjM1XSBJT0FQSUNbMV06IFNldCBQQ0kgcm91dGlu
ZyBlbnRyeSAoNy02IC0+IDB4MjEgLT4gSVJRIDMwIE1vZGU6MSBBY3RpdmU6MSkNCihYRU4p
IFsyMDEyLTA5LTAzIDIwOjU1OjM1XSBJT0FQSUNbMV06IFNldCBQQ0kgcm91dGluZyBlbnRy
eSAoNy03IC0+IDB4MjkgLT4gSVJRIDMxIE1vZGU6MSBBY3RpdmU6MSkNCihYRU4pIFsyMDEy
LTA5LTAzIDIwOjU1OjM1XSBJT0FQSUNbMV06IFNldCBQQ0kgcm91dGluZyBlbnRyeSAoNy0x
NiAtPiAweDMxIC0+IElSUSA0MCBNb2RlOjEgQWN0aXZlOjEpDQooWEVOKSBbMjAxMi0wOS0w
MyAyMDo1NTozNV0gSU9BUElDWzFdOiBTZXQgUENJIHJvdXRpbmcgZW50cnkgKDctMTcgLT4g
MHgzOSAtPiBJUlEgNDEgTW9kZToxIEFjdGl2ZToxKQ0KKFhFTikgWzIwMTItMDktMDMgMjA6
NTU6MzZdIElPQVBJQ1sxXTogU2V0IFBDSSByb3V0aW5nIGVudHJ5ICg3LTE4IC0+IDB4NDEg
LT4gSVJRIDQyIE1vZGU6MSBBY3RpdmU6MSkNCihYRU4pIFsyMDEyLTA5LTAzIDIwOjU1OjM2
XSBJT0FQSUNbMV06IFNldCBQQ0kgcm91dGluZyBlbnRyeSAoNy0xOSAtPiAweDQ5IC0+IElS
USA0MyBNb2RlOjEgQWN0aXZlOjEpDQooWEVOKSBbMjAxMi0wOS0wMyAyMDo1NTozNl0gSU9B
UElDWzBdOiBTZXQgUENJIHJvdXRpbmcgZW50cnkgKDYtMjIgLT4gMHg5OSAtPiBJUlEgMjIg
TW9kZToxIEFjdGl2ZToxKQ0KKFhFTikgWzIwMTItMDktMDMgMjA6NTU6MzZdIElPQVBJQ1sx
XTogU2V0IFBDSSByb3V0aW5nIGVudHJ5ICg3LTEyIC0+IDB4YTEgLT4gSVJRIDM2IE1vZGU6
MSBBY3RpdmU6MSkNCihYRU4pIFsyMDEyLTA5LTAzIDIwOjU1OjM2XSBJT0FQSUNbMV06IFNl
dCBQQ0kgcm91dGluZyBlbnRyeSAoNy0yMyAtPiAweGE5IC0+IElSUSA0NyBNb2RlOjEgQWN0
aXZlOjEpDQooWEVOKSBbMjAxMi0wOS0wMyAyMDo1NTozNl0gSU9BUElDWzBdOiBTZXQgUENJ
IHJvdXRpbmcgZW50cnkgKDYtMTkgLT4gMHhiMSAtPiBJUlEgMTkgTW9kZToxIEFjdGl2ZTox
KQ0KKFhFTikgWzIwMTItMDktMDMgMjA6NTU6MzZdIElPQVBJQ1sxXTogU2V0IFBDSSByb3V0
aW5nIGVudHJ5ICg3LTIyIC0+IDB4YzEgLT4gSVJRIDQ2IE1vZGU6MSBBY3RpdmU6MSkNCihY
RU4pIFsyMDEyLTA5LTAzIDIwOjU1OjM2XSBJT0FQSUNbMV06IFNldCBQQ0kgcm91dGluZyBl
bnRyeSAoNy0yNyAtPiAweGQxIC0+IElSUSA1MSBNb2RlOjEgQWN0aXZlOjEpDQooWEVOKSBb
MjAxMi0wOS0wMyAyMDo1NTozOF0gSU9BUElDWzFdOiBTZXQgUENJIHJvdXRpbmcgZW50cnkg
KDctOSAtPiAweDIyIC0+IElSUSAzMyBNb2RlOjEgQWN0aXZlOjEpDQooWEVOKSBbMjAxMi0w
OS0wMyAyMDo1NjozN10gdHJhcHMuYzoyNTg0OmQxIERvbWFpbiBhdHRlbXB0ZWQgV1JNU1Ig
MDAwMDAwMDBjMDAxMDAwNCBmcm9tIDB4MDAwMDQyMzQ1YTBkYTU0NSB0byAweDAwMDAwMDAw
MDAwMGFiY2QuDQooWEVOKSBbMjAxMi0wOS0wMyAyMDo1Njo0M10gdHJhcHMuYzoyNTg0OmQy
IERvbWFpbiBhdHRlbXB0ZWQgV1JNU1IgMDAwMDAwMDBjMDAxMDAwNCBmcm9tIDB4MDAwMDg2
NzljMDJiNDE2NSB0byAweDAwMDAwMDAwMDAwMGFiY2QuDQooWEVOKSBbMjAxMi0wOS0wMyAy
MDo1Njo1NV0gdHJhcHMuYzoyNTg0OmQzIERvbWFpbiBhdHRlbXB0ZWQgV1JNU1IgMDAwMDAw
MDBjMDAxMDAwNCBmcm9tIDB4MDAwMDQyMzQ1YTBkYTU0NSB0byAweDAwMDAwMDAwMDAwMGFi
Y2QuDQooWEVOKSBbMjAxMi0wOS0wMyAyMDo1Njo1NV0gdHJhcHMuYzoyNTg0OmQ0IERvbWFp
biBhdHRlbXB0ZWQgV1JNU1IgMDAwMDAwMDBjMDAxMDAwNCBmcm9tIDB4MDAwMDg2NzljMDJi
NDE2NSB0byAweDAwMDAwMDAwMDAwMGFiY2QuDQooWEVOKSBbMjAxMi0wOS0wMyAyMDo1Nzow
M10gdHJhcHMuYzoyNTg0OmQ1IERvbWFpbiBhdHRlbXB0ZWQgV1JNU1IgMDAwMDAwMDBjMDAx
MDAwNCBmcm9tIDB4MDAwMDg2NzljMDJiNDE2NSB0byAweDAwMDAwMDAwMDAwMGFiY2QuDQoo
WEVOKSBbMjAxMi0wOS0wMyAyMDo1NzowOV0gdHJhcHMuYzoyNTg0OmQ2IERvbWFpbiBhdHRl
bXB0ZWQgV1JNU1IgMDAwMDAwMDBjMDAxMDAwNCBmcm9tIDB4MDAwMDZmYjAzOWRlNzkwMCB0
byAweDAwMDAwMDAwMDAwMGFiY2QuDQooWEVOKSBbMjAxMi0wOS0wMyAyMDo1NzoxNV0gdHJh
cHMuYzoyNTg0OmQ3IERvbWFpbiBhdHRlbXB0ZWQgV1JNU1IgMDAwMDAwMDBjMDAxMDAwNCBm
cm9tIDB4MDAwMGExOTVjNDBmNjE4ZiB0byAweDAwMDAwMDAwMDAwMGFiY2QuDQooWEVOKSBb
MjAxMi0wOS0wMyAyMDo1NzoyMl0gdHJhcHMuYzoyNTg0OmQ4IERvbWFpbiBhdHRlbXB0ZWQg
V1JNU1IgMDAwMDAwMDBjMDAxMDAwNCBmcm9tIDB4MDAwMDZmYjAzOWRlNzkwMCB0byAweDAw
MDAwMDAwMDAwMGFiY2QuDQooWEVOKSBbMjAxMi0wOS0wMyAyMDo1NzoyOF0gdHJhcHMuYzoy
NTg0OmQ5IERvbWFpbiBhdHRlbXB0ZWQgV1JNU1IgMDAwMDAwMDBjMDAxMDAwNCBmcm9tIDB4
MDAwMDQyMzQ1YTBkYTU0NSB0byAweDAwMDAwMDAwMDAwMGFiY2QuDQooWEVOKSBbMjAxMi0w
OS0wMyAyMDo1NzozNV0gdHJhcHMuYzoyNTg0OmQxMCBEb21haW4gYXR0ZW1wdGVkIFdSTVNS
IDAwMDAwMDAwYzAwMTAwMDQgZnJvbSAweDAwMDA0MjM0NWEwZGE1NDUgdG8gMHgwMDAwMDAw
MDAwMDBhYmNkLg0KKFhFTikgWzIwMTItMDktMDMgMjA6NTc6NDFdIEFNRC1WaTogRGlzYWJs
ZTogZGV2aWNlIGlkID0gMHgwMGE0LCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMNCihY
RU4pIFsyMDEyLTA5LTAzIDIwOjU3OjQxXSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxl
OiBkZXZpY2UgaWQgPSAweDAwYTQsIHJvb3QgdGFibGUgPSAweDE4ZTBhMTAwMCwgZG9tYWlu
ID0gMTEsIHBhZ2luZyBtb2RlID0gMw0KKFhFTikgWzIwMTItMDktMDMgMjA6NTc6NDFdIEFN
RC1WaTogUmUtYXNzaWduIDAwMDA6MDM6MDYuMCBmcm9tIGRvbTAgdG8gZG9tMTENCihYRU4p
IFsyMDEyLTA5LTAzIDIwOjU3OjQxXSB0cmFwcy5jOjI1ODQ6ZDExIERvbWFpbiBhdHRlbXB0
ZWQgV1JNU1IgMDAwMDAwMDBjMDAxMDAwNCBmcm9tIDB4MDAwMDg2NzljMDJiNDE2NSB0byAw
eDAwMDAwMDAwMDAwMGFiY2QuDQooWEVOKSBbMjAxMi0wOS0wMyAyMDo1Nzo1Ml0gdHJhcHMu
YzoyNTg0OmQxMiBEb21haW4gYXR0ZW1wdGVkIFdSTVNSIDAwMDAwMDAwYzAwMTAwMDQgZnJv
bSAweDAwMDBhMTk1YzQwZjYxOGYgdG8gMHgwMDAwMDAwMDAwMDBhYmNkLg0KKFhFTikgWzIw
MTItMDktMDMgMjA6NTc6NThdIHRyYXBzLmM6MjU4NDpkMTMgRG9tYWluIGF0dGVtcHRlZCBX
Uk1TUiAwMDAwMDAwMGMwMDEwMDA0IGZyb20gMHgwMDAwODY3OWMwMmI0MTY1IHRvIDB4MDAw
MDAwMDAwMDAwYWJjZC4NCihYRU4pIFsyMDEyLTA5LTAzIDIwOjU4OjA2XSBBTUQtVmk6IERp
c2FibGU6IGRldmljZSBpZCA9IDB4MGEwMCwgZG9tYWluID0gMCwgcGFnaW5nIG1vZGUgPSAz
DQooWEVOKSBbMjAxMi0wOS0wMyAyMDo1ODowNl0gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0
YWJsZTogZGV2aWNlIGlkID0gMHgwYTAwLCByb290IHRhYmxlID0gMHgxZTFmYzAwMDAsIGRv
bWFpbiA9IDE0LCBwYWdpbmcgbW9kZSA9IDMNCihYRU4pIFsyMDEyLTA5LTAzIDIwOjU4OjA2
XSBBTUQtVmk6IFJlLWFzc2lnbiAwMDAwOjBhOjAwLjAgZnJvbSBkb20wIHRvIGRvbTE0DQoo
WEVOKSBbMjAxMi0wOS0wMyAyMDo1ODowNl0gQU1ELVZpOiBEaXNhYmxlOiBkZXZpY2UgaWQg
PSAweDBhMDEsIGRvbWFpbiA9IDAsIHBhZ2luZyBtb2RlID0gMw0KKFhFTikgWzIwMTItMDkt
MDMgMjA6NTg6MDZdIEFNRC1WaTogU2V0dXAgSS9PIHBhZ2UgdGFibGU6IGRldmljZSBpZCA9
IDB4MGEwMSwgcm9vdCB0YWJsZSA9IDB4MWUxZmMwMDAwLCBkb21haW4gPSAxNCwgcGFnaW5n
IG1vZGUgPSAzDQooWEVOKSBbMjAxMi0wOS0wMyAyMDo1ODowNl0gQU1ELVZpOiBSZS1hc3Np
Z24gMDAwMDowYTowMC4xIGZyb20gZG9tMCB0byBkb20xNA0KKFhFTikgWzIwMTItMDktMDMg
MjA6NTg6MDZdIEFNRC1WaTogRGlzYWJsZTogZGV2aWNlIGlkID0gMHgwYTAyLCBkb21haW4g
PSAwLCBwYWdpbmcgbW9kZSA9IDMNCihYRU4pIFsyMDEyLTA5LTAzIDIwOjU4OjA2XSBBTUQt
Vmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweDBhMDIsIHJvb3QgdGFi
bGUgPSAweDFlMWZjMDAwMCwgZG9tYWluID0gMTQsIHBhZ2luZyBtb2RlID0gMw0KKFhFTikg
WzIwMTItMDktMDMgMjA6NTg6MDZdIEFNRC1WaTogUmUtYXNzaWduIDAwMDA6MGE6MDAuMiBm
cm9tIGRvbTAgdG8gZG9tMTQNCihYRU4pIFsyMDEyLTA5LTAzIDIwOjU4OjA2XSBBTUQtVmk6
IERpc2FibGU6IGRldmljZSBpZCA9IDB4MGEwMywgZG9tYWluID0gMCwgcGFnaW5nIG1vZGUg
PSAzDQooWEVOKSBbMjAxMi0wOS0wMyAyMDo1ODowNl0gQU1ELVZpOiBTZXR1cCBJL08gcGFn
ZSB0YWJsZTogZGV2aWNlIGlkID0gMHgwYTAzLCByb290IHRhYmxlID0gMHgxZTFmYzAwMDAs
IGRvbWFpbiA9IDE0LCBwYWdpbmcgbW9kZSA9IDMNCihYRU4pIFsyMDEyLTA5LTAzIDIwOjU4
OjA2XSBBTUQtVmk6IFJlLWFzc2lnbiAwMDAwOjBhOjAwLjMgZnJvbSBkb20wIHRvIGRvbTE0
DQooWEVOKSBbMjAxMi0wOS0wMyAyMDo1ODowNl0gQU1ELVZpOiBEaXNhYmxlOiBkZXZpY2Ug
aWQgPSAweDBhMDQsIGRvbWFpbiA9IDAsIHBhZ2luZyBtb2RlID0gMw0KKFhFTikgWzIwMTIt
MDktMDMgMjA6NTg6MDZdIEFNRC1WaTogU2V0dXAgSS9PIHBhZ2UgdGFibGU6IGRldmljZSBp
ZCA9IDB4MGEwNCwgcm9vdCB0YWJsZSA9IDB4MWUxZmMwMDAwLCBkb21haW4gPSAxNCwgcGFn
aW5nIG1vZGUgPSAzDQooWEVOKSBbMjAxMi0wOS0wMyAyMDo1ODowNl0gQU1ELVZpOiBSZS1h
c3NpZ24gMDAwMDowYTowMC40IGZyb20gZG9tMCB0byBkb20xNA0KKFhFTikgWzIwMTItMDkt
MDMgMjA6NTg6MDZdIEFNRC1WaTogRGlzYWJsZTogZGV2aWNlIGlkID0gMHgwYTA1LCBkb21h
aW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMNCihYRU4pIFsyMDEyLTA5LTAzIDIwOjU4OjA2XSBB
TUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweDBhMDUsIHJvb3Qg
dGFibGUgPSAweDFlMWZjMDAwMCwgZG9tYWluID0gMTQsIHBhZ2luZyBtb2RlID0gMw0KKFhF
TikgWzIwMTItMDktMDMgMjA6NTg6MDZdIEFNRC1WaTogUmUtYXNzaWduIDAwMDA6MGE6MDAu
NSBmcm9tIGRvbTAgdG8gZG9tMTQNCihYRU4pIFsyMDEyLTA5LTAzIDIwOjU4OjA2XSBBTUQt
Vmk6IERpc2FibGU6IGRldmljZSBpZCA9IDB4MGEwNiwgZG9tYWluID0gMCwgcGFnaW5nIG1v
ZGUgPSAzDQooWEVOKSBbMjAxMi0wOS0wMyAyMDo1ODowNl0gQU1ELVZpOiBTZXR1cCBJL08g
cGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHgwYTA2LCByb290IHRhYmxlID0gMHgxZTFmYzAw
MDAsIGRvbWFpbiA9IDE0LCBwYWdpbmcgbW9kZSA9IDMNCihYRU4pIFsyMDEyLTA5LTAzIDIw
OjU4OjA2XSBBTUQtVmk6IFJlLWFzc2lnbiAwMDAwOjBhOjAwLjYgZnJvbSBkb20wIHRvIGRv
bTE0DQooWEVOKSBbMjAxMi0wOS0wMyAyMDo1ODowNl0gQU1ELVZpOiBEaXNhYmxlOiBkZXZp
Y2UgaWQgPSAweDBhMDcsIGRvbWFpbiA9IDAsIHBhZ2luZyBtb2RlID0gMw0KKFhFTikgWzIw
MTItMDktMDMgMjA6NTg6MDZdIEFNRC1WaTogU2V0dXAgSS9PIHBhZ2UgdGFibGU6IGRldmlj
ZSBpZCA9IDB4MGEwNywgcm9vdCB0YWJsZSA9IDB4MWUxZmMwMDAwLCBkb21haW4gPSAxNCwg
cGFnaW5nIG1vZGUgPSAzDQooWEVOKSBbMjAxMi0wOS0wMyAyMDo1ODowNl0gQU1ELVZpOiBS
ZS1hc3NpZ24gMDAwMDowYTowMC43IGZyb20gZG9tMCB0byBkb20xNA0KKFhFTikgWzIwMTIt
MDktMDMgMjA6NTg6MDZdIEFNRC1WaTogRGlzYWJsZTogZGV2aWNlIGlkID0gMHgwNzAwLCBk
b21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMNCihYRU4pIFsyMDEyLTA5LTAzIDIwOjU4OjA2
XSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweDA3MDAsIHJv
b3QgdGFibGUgPSAweDFlMWZjMDAwMCwgZG9tYWluID0gMTQsIHBhZ2luZyBtb2RlID0gMw0K
KFhFTikgWzIwMTItMDktMDMgMjA6NTg6MDZdIEFNRC1WaTogUmUtYXNzaWduIDAwMDA6MDc6
MDAuMCBmcm9tIGRvbTAgdG8gZG9tMTQNCihYRU4pIFsyMDEyLTA5LTAzIDIwOjU4OjA2XSB0
cmFwcy5jOjI1ODQ6ZDE0IERvbWFpbiBhdHRlbXB0ZWQgV1JNU1IgMDAwMDAwMDBjMDAxMDAw
NCBmcm9tIDB4MDAwMDc4NTE5MGZiNGUwZiB0byAweDAwMDAwMDAwMDAwMGFiY2QuDQooWEVO
KSBbMjAxMi0wOS0wMyAyMDo1ODoxNl0gQU1ELVZpOiBTaGFyZSBwMm0gdGFibGUgd2l0aCBp
b21tdTogcDJtIHRhYmxlID0gMHhhNzdhOA0KKFhFTikgWzIwMTItMDktMDMgMjA6NTg6MTld
IEhWTTE1OiBIVk0gTG9hZGVyDQooWEVOKSBbMjAxMi0wOS0wMyAyMDo1ODoxOV0gSFZNMTU6
IERldGVjdGVkIFhlbiB2NC4yLjAtcmM0LXByZQ0KKFhFTikgWzIwMTItMDktMDMgMjA6NTg6
MTldIEhWTTE1OiBYZW5idXMgcmluZ3MgQDB4ZmVmZmMwMDAsIGV2ZW50IGNoYW5uZWwgNA0K
KFhFTikgWzIwMTItMDktMDMgMjA6NTg6MTldIEhWTTE1OiBTeXN0ZW0gcmVxdWVzdGVkIFJP
TUJJT1MNCihYRU4pIFsyMDEyLTA5LTAzIDIwOjU4OjE5XSBIVk0xNTogQ1BVIHNwZWVkIGlz
IDMyMDAgTUh6DQooWEVOKSBbMjAxMi0wOS0wMyAyMDo1ODoxOV0gaXJxLmM6MjcwOiBEb20x
NSBQQ0kgbGluayAwIGNoYW5nZWQgMCAtPiA1DQooWEVOKSBbMjAxMi0wOS0wMyAyMDo1ODox
OV0gSFZNMTU6IFBDSS1JU0EgbGluayAwIHJvdXRlZCB0byBJUlE1DQooWEVOKSBbMjAxMi0w
OS0wMyAyMDo1ODoxOV0gaXJxLmM6MjcwOiBEb20xNSBQQ0kgbGluayAxIGNoYW5nZWQgMCAt
PiAxMA0KKFhFTikgWzIwMTItMDktMDMgMjA6NTg6MTldIEhWTTE1OiBQQ0ktSVNBIGxpbmsg
MSByb3V0ZWQgdG8gSVJRMTANCihYRU4pIFsyMDEyLTA5LTAzIDIwOjU4OjE5XSBpcnEuYzoy
NzA6IERvbTE1IFBDSSBsaW5rIDIgY2hhbmdlZCAwIC0+IDExDQooWEVOKSBbMjAxMi0wOS0w
MyAyMDo1ODoxOV0gSFZNMTU6IFBDSS1JU0EgbGluayAyIHJvdXRlZCB0byBJUlExMQ0KKFhF
TikgWzIwMTItMDktMDMgMjA6NTg6MTldIGlycS5jOjI3MDogRG9tMTUgUENJIGxpbmsgMyBj
aGFuZ2VkIDAgLT4gNQ0KKFhFTikgWzIwMTItMDktMDMgMjA6NTg6MTldIEhWTTE1OiBQQ0kt
SVNBIGxpbmsgMyByb3V0ZWQgdG8gSVJRNQ0KKFhFTikgWzIwMTItMDktMDMgMjA6NTg6MTld
IEhWTTE1OiBwY2kgZGV2IDAxOjIgSU5URC0+SVJRNQ0KKFhFTikgWzIwMTItMDktMDMgMjA6
NTg6MTldIEhWTTE1OiBwY2kgZGV2IDAxOjMgSU5UQS0+SVJRMTANCihYRU4pIFsyMDEyLTA5
LTAzIDIwOjU4OjE5XSBIVk0xNTogcGNpIGRldiAwMzowIElOVEEtPklSUTUNCihYRU4pIFsy
MDEyLTA5LTAzIDIwOjU4OjE5XSBIVk0xNTogcGNpIGRldiAwNDowIElOVEEtPklSUTUNCihY
RU4pIFsyMDEyLTA5LTAzIDIwOjU4OjE5XSBIVk0xNTogcGNpIGRldiAwMjowIGJhciAxMCBz
aXplIDAyMDAwMDAwOiBmMDAwMDAwOA0KKFhFTikgWzIwMTItMDktMDMgMjA6NTg6MTldIEhW
TTE1OiBwY2kgZGV2IDAzOjAgYmFyIDE0IHNpemUgMDEwMDAwMDA6IGYyMDAwMDA4DQooWEVO
KSBbMjAxMi0wOS0wMyAyMDo1ODoxOV0gSFZNMTU6IHBjaSBkZXYgMDQ6MCBiYXIgMTAgc2l6
ZSAwMDAyMDAwMDogZjMwMDAwMDANCihYRU4pIFsyMDEyLTA5LTAzIDIwOjU4OjE5XSBIVk0x
NTogcGNpIGRldiAwMjowIGJhciAxNCBzaXplIDAwMDAxMDAwOiBmMzAyMDAwMA0KKFhFTikg
WzIwMTItMDktMDMgMjA6NTg6MTldIEhWTTE1OiBwY2kgZGV2IDAzOjAgYmFyIDEwIHNpemUg
MDAwMDAxMDA6IDAwMDBjMDAxDQooWEVOKSBbMjAxMi0wOS0wMyAyMDo1ODoxOV0gSFZNMTU6
IHBjaSBkZXYgMDQ6MCBiYXIgMTQgc2l6ZSAwMDAwMDA0MDogMDAwMGMxMDENCihYRU4pIFsy
MDEyLTA5LTAzIDIwOjU4OjE5XSBIVk0xNTogcGNpIGRldiAwMToyIGJhciAyMCBzaXplIDAw
MDAwMDIwOiAwMDAwYzE0MQ0KKFhFTikgWzIwMTItMDktMDMgMjA6NTg6MTldIEhWTTE1OiBw
Y2kgZGV2IDAxOjEgYmFyIDIwIHNpemUgMDAwMDAwMTA6IDAwMDBjMTYxDQooWEVOKSBbMjAx
Mi0wOS0wMyAyMDo1ODoxOV0gSFZNMTU6IE11bHRpcHJvY2Vzc29yIGluaXRpYWxpc2F0aW9u
Og0KKFhFTikgWzIwMTItMDktMDMgMjA6NTg6MTldIEhWTTE1OiAgLSBDUFUwIC4uLiA0OC1i
aXQgcGh5cyAuLi4gZml4ZWQgTVRSUnMgLi4uIHZhciBNVFJScyBbMi84XSAuLi4gZG9uZS4N
CihYRU4pIFsyMDEyLTA5LTAzIDIwOjU4OjE5XSBIVk0xNTogIC0gQ1BVMSAuLi4gNDgtYml0
IHBoeXMgLi4uIGZpeGVkIE1UUlJzIC4uLiB2YXIgTVRSUnMgWzIvOF0gLi4uIGRvbmUuDQoo
WEVOKSBbMjAxMi0wOS0wMyAyMDo1ODoxOV0gSFZNMTU6IFRlc3RpbmcgSFZNIGVudmlyb25t
ZW50Og0KKFhFTikgWzIwMTItMDktMDMgMjA6NTg6MTldIEhWTTE1OiAgLSBSRVAgSU5TQiBh
Y3Jvc3MgcGFnZSBib3VuZGFyaWVzIC4uLiBwYXNzZWQNCihYRU4pIFsyMDEyLTA5LTAzIDIw
OjU4OjE5XSBIVk0xNTogIC0gR1MgYmFzZSBNU1JzIGFuZCBTV0FQR1MgLi4uIHBhc3NlZA0K
KFhFTikgWzIwMTItMDktMDMgMjA6NTg6MTldIEhWTTE1OiBQYXNzZWQgMiBvZiAyIHRlc3Rz
DQooWEVOKSBbMjAxMi0wOS0wMyAyMDo1ODoxOV0gSFZNMTU6IFdyaXRpbmcgU01CSU9TIHRh
YmxlcyAuLi4NCihYRU4pIFsyMDEyLTA5LTAzIDIwOjU4OjE5XSBIVk0xNTogTG9hZGluZyBS
T01CSU9TIC4uLg0KKFhFTikgWzIwMTItMDktMDMgMjA6NTg6MTldIEhWTTE1OiA5NjYwIGJ5
dGVzIG9mIFJPTUJJT1MgaGlnaC1tZW1vcnkgZXh0ZW5zaW9uczoNCihYRU4pIFsyMDEyLTA5
LTAzIDIwOjU4OjE5XSBIVk0xNTogICBSZWxvY2F0aW5nIHRvIDB4ZmMwMDEwMDAtMHhmYzAw
MzViYyAuLi4gZG9uZQ0KKFhFTikgWzIwMTItMDktMDMgMjA6NTg6MTldIEhWTTE1OiBDcmVh
dGluZyBNUCB0YWJsZXMgLi4uDQooWEVOKSBbMjAxMi0wOS0wMyAyMDo1ODoxOV0gSFZNMTU6
IExvYWRpbmcgQ2lycnVzIFZHQUJJT1MgLi4uDQooWEVOKSBbMjAxMi0wOS0wMyAyMDo1ODox
OV0gSFZNMTU6IExvYWRpbmcgUENJIE9wdGlvbiBST00gLi4uDQooWEVOKSBbMjAxMi0wOS0w
MyAyMDo1ODoxOV0gSFZNMTU6ICAtIE1hbnVmYWN0dXJlcjogaHR0cDovL2lweGUub3JnDQoo
WEVOKSBbMjAxMi0wOS0wMyAyMDo1ODoxOV0gSFZNMTU6ICAtIFByb2R1Y3QgbmFtZTogaVBY
RQ0KKFhFTikgWzIwMTItMDktMDMgMjA6NTg6MTldIEhWTTE1OiBPcHRpb24gUk9NczoNCihY
RU4pIFsyMDEyLTA5LTAzIDIwOjU4OjE5XSBIVk0xNTogIGMwMDAwLWM4ZmZmOiBWR0EgQklP
Uw0KKFhFTikgWzIwMTItMDktMDMgMjA6NTg6MTldIEhWTTE1OiAgYzkwMDAtZDlmZmY6IEV0
aGVyYm9vdCBST00NCihYRU4pIFsyMDEyLTA5LTAzIDIwOjU4OjE5XSBIVk0xNTogTG9hZGlu
ZyBBQ1BJIC4uLg0KKFhFTikgWzIwMTItMDktMDMgMjA6NTg6MTldIEhWTTE1OiB2bTg2IFRT
UyBhdCBmYzAwZjY4MA0KKFhFTikgWzIwMTItMDktMDMgMjA6NTg6MTldIEhWTTE1OiBCSU9T
IG1hcDoNCihYRU4pIFsyMDEyLTA5LTAzIDIwOjU4OjE5XSBIVk0xNTogIGYwMDAwLWZmZmZm
OiBNYWluIEJJT1MNCihYRU4pIFsyMDEyLTA5LTAzIDIwOjU4OjE5XSBIVk0xNTogRTgyMCB0
YWJsZToNCihYRU4pIFsyMDEyLTA5LTAzIDIwOjU4OjE5XSBIVk0xNTogIFswMF06IDAwMDAw
MDAwOjAwMDAwMDAwIC0gMDAwMDAwMDA6MDAwOWUwMDA6IFJBTQ0KKFhFTikgWzIwMTItMDkt
MDMgMjA6NTg6MTldIEhWTTE1OiAgWzAxXTogMDAwMDAwMDA6MDAwOWUwMDAgLSAwMDAwMDAw
MDowMDBhMDAwMDogUkVTRVJWRUQNCihYRU4pIFsyMDEyLTA5LTAzIDIwOjU4OjE5XSBIVk0x
NTogIEhPTEU6IDAwMDAwMDAwOjAwMGEwMDAwIC0gMDAwMDAwMDA6MDAwZTAwMDANCihYRU4p
IFsyMDEyLTA5LTAzIDIwOjU4OjE5XSBIVk0xNTogIFswMl06IDAwMDAwMDAwOjAwMGUwMDAw
IC0gMDAwMDAwMDA6MDAxMDAwMDA6IFJFU0VSVkVEDQooWEVOKSBbMjAxMi0wOS0wMyAyMDo1
ODoxOV0gSFZNMTU6ICBbMDNdOiAwMDAwMDAwMDowMDEwMDAwMCAtIDAwMDAwMDAwOjFmODAw
MDAwOiBSQU0NCihYRU4pIFsyMDEyLTA5LTAzIDIwOjU4OjE5XSBIVk0xNTogIEhPTEU6IDAw
MDAwMDAwOjFmODAwMDAwIC0gMDAwMDAwMDA6ZmMwMDAwMDANCihYRU4pIFsyMDEyLTA5LTAz
IDIwOjU4OjE5XSBIVk0xNTogIFswNF06IDAwMDAwMDAwOmZjMDAwMDAwIC0gMDAwMDAwMDE6
MDAwMDAwMDA6IFJFU0VSVkVEDQooWEVOKSBbMjAxMi0wOS0wMyAyMDo1ODoxOV0gSFZNMTU6
IEludm9raW5nIFJPTUJJT1MgLi4uDQooWEVOKSBbMjAxMi0wOS0wMyAyMDo1ODoxOV0gSFZN
MTU6ICRSZXZpc2lvbjogMS4yMjEgJCAkRGF0ZTogMjAwOC8xMi8wNyAxNzozMjoyOSAkDQoo
WEVOKSBbMjAxMi0wOS0wMyAyMDo1ODoyMF0gc3RkdmdhLmM6MTQ3OmQxNSBlbnRlcmluZyBz
dGR2Z2EgYW5kIGNhY2hpbmcgbW9kZXMNCihYRU4pIFsyMDEyLTA5LTAzIDIwOjU4OjIwXSBI
Vk0xNTogVkdBQmlvcyAkSWQ6IHZnYWJpb3MuYyx2IDEuNjcgMjAwOC8wMS8yNyAwOTo0NDox
MiB2cnVwcGVydCBFeHAgJA0KKFhFTikgWzIwMTItMDktMDMgMjA6NTg6MjBdIEhWTTE1OiBC
b2NocyBCSU9TIC0gYnVpbGQ6IDA2LzIzLzk5DQooWEVOKSBbMjAxMi0wOS0wMyAyMDo1ODoy
MF0gSFZNMTU6ICRSZXZpc2lvbjogMS4yMjEgJCAkRGF0ZTogMjAwOC8xMi8wNyAxNzozMjoy
OSAkDQooWEVOKSBbMjAxMi0wOS0wMyAyMDo1ODoyMF0gSFZNMTU6IE9wdGlvbnM6IGFwbWJp
b3MgcGNpYmlvcyBlbHRvcml0byBQTU0gDQooWEVOKSBbMjAxMi0wOS0wMyAyMDo1ODoyMF0g
SFZNMTU6IA0KKFhFTikgWzIwMTItMDktMDMgMjA6NTg6MjBdIEhWTTE1OiBhdGEwLTA6IFBD
SFM9MTYzODMvMTYvNjMgdHJhbnNsYXRpb249bGJhIExDSFM9MTAyNC8yNTUvNjMNCihYRU4p
IFsyMDEyLTA5LTAzIDIwOjU4OjIwXSBIVk0xNTogYXRhMCBtYXN0ZXI6IFFFTVUgSEFSRERJ
U0sgQVRBLTcgSGFyZC1EaXNrICg1NzI0NCBNQnl0ZXMpDQooWEVOKSBbMjAxMi0wOS0wMyAy
MDo1ODoyMV0gSFZNMTU6IElERSB0aW1lIG91dA0KKFhFTikgWzIwMTItMDktMDMgMjA6NTg6
MjFdIEhWTTE1OiBhdGExIG1hc3RlcjogUUVNVSBEVkQtUk9NIEFUQVBJLTQgQ0QtUm9tL0RW
RC1Sb20NCihYRU4pIFsyMDEyLTA5LTAzIDIwOjU4OjIzXSBIVk0xNTogSURFIHRpbWUgb3V0
DQooWEVOKSBbMjAxMi0wOS0wMyAyMDo1ODoyM10gSFZNMTU6IA0KKFhFTikgWzIwMTItMDkt
MDMgMjA6NTg6MjNdIEhWTTE1OiANCihYRU4pIFsyMDEyLTA5LTAzIDIwOjU4OjIzXSBIVk0x
NTogDQooWEVOKSBbMjAxMi0wOS0wMyAyMDo1ODoyM10gSFZNMTU6IFByZXNzIEYxMiBmb3Ig
Ym9vdCBtZW51Lg0KKFhFTikgWzIwMTItMDktMDMgMjA6NTg6MjNdIEhWTTE1OiANCihYRU4p
IFsyMDEyLTA5LTAzIDIwOjU4OjIzXSBIVk0xNTogQm9vdGluZyBmcm9tIEhhcmQgRGlzay4u
Lg0KKFhFTikgWzIwMTItMDktMDMgMjA6NTg6MjNdIEhWTTE1OiBCb290aW5nIGZyb20gMDAw
MDo3YzAwDQooWEVOKSBbMjAxMi0wOS0wMyAyMDo1ODoyNl0gdHJhcHMuYzoyNTg0OmQxNiBE
b21haW4gYXR0ZW1wdGVkIFdSTVNSIDAwMDAwMDAwYzAwMTAwMDQgZnJvbSAweDAwMDA0MjM0
NWEwZGE1NDUgdG8gMHgwMDAwMDAwMDAwMDBhYmNkLg0KKFhFTikgWzIwMTItMDktMDMgMjA6
NTg6NTBdIGlycS5jOjI3MDogRG9tMTUgUENJIGxpbmsgMCBjaGFuZ2VkIDUgLT4gMA0KKFhF
TikgWzIwMTItMDktMDMgMjA6NTg6NTBdIGlycS5jOjI3MDogRG9tMTUgUENJIGxpbmsgMSBj
aGFuZ2VkIDEwIC0+IDANCihYRU4pIFsyMDEyLTA5LTAzIDIwOjU4OjUwXSBpcnEuYzoyNzA6
IERvbTE1IFBDSSBsaW5rIDIgY2hhbmdlZCAxMSAtPiAwDQooWEVOKSBbMjAxMi0wOS0wMyAy
MDo1ODo1MF0gaXJxLmM6MjcwOiBEb20xNSBQQ0kgbGluayAzIGNoYW5nZWQgNSAtPiAwDQoo
WEVOKSBbMjAxMi0wOS0wMyAyMDo1ODo1MV0gaHZtLmM6MjQzNTpkMTUgZ3Vlc3QgYXR0ZW1w
dGVkIHdyaXRlIHRvIHJlYWQtb25seSBtZW1vcnkgcGFnZS4gZ2ZuPTB4ZGMsIG1mbj0weGE0
YTBiDQooWEVOKSBbMjAxMi0wOS0wMyAyMDo1ODo1MV0gaHZtLmM6MjQzNTpkMTUgZ3Vlc3Qg
YXR0ZW1wdGVkIHdyaXRlIHRvIHJlYWQtb25seSBtZW1vcnkgcGFnZS4gZ2ZuPTB4ZGQsIG1m
bj0weGE0YTBhDQooWEVOKSBbMjAxMi0wOS0wMyAyMDo1ODo1MV0gaHZtLmM6MjQzNTpkMTUg
Z3Vlc3QgYXR0ZW1wdGVkIHdyaXRlIHRvIHJlYWQtb25seSBtZW1vcnkgcGFnZS4gZ2ZuPTB4
ZGUsIG1mbj0weGE0YTA5DQooWEVOKSBbMjAxMi0wOS0wMyAyMDo1ODo1MV0gaHZtLmM6MjQz
NTpkMTUgZ3Vlc3QgYXR0ZW1wdGVkIHdyaXRlIHRvIHJlYWQtb25seSBtZW1vcnkgcGFnZS4g
Z2ZuPTB4ZGQsIG1mbj0weGE0YTBhDQooWEVOKSBbMjAxMi0wOS0wMyAyMDo1ODo1MV0gaHZt
LmM6MjQzNTpkMTUgZ3Vlc3QgYXR0ZW1wdGVkIHdyaXRlIHRvIHJlYWQtb25seSBtZW1vcnkg
cGFnZS4gZ2ZuPTB4ZGMsIG1mbj0weGE0YTBiDQooWEVOKSBbMjAxMi0wOS0wMyAyMDo1ODo1
MV0gaHZtLmM6MjQzNTpkMTUgZ3Vlc3QgYXR0ZW1wdGVkIHdyaXRlIHRvIHJlYWQtb25seSBt
ZW1vcnkgcGFnZS4gZ2ZuPTB4ZGUsIG1mbj0weGE0YTA5DQooWEVOKSBbMjAxMi0wOS0wMyAy
MDo1ODo1MV0gaHZtLmM6MjQzNTpkMTUgZ3Vlc3QgYXR0ZW1wdGVkIHdyaXRlIHRvIHJlYWQt
b25seSBtZW1vcnkgcGFnZS4gZ2ZuPTB4ZGQsIG1mbj0weGE0YTBhDQooWEVOKSBbMjAxMi0w
OS0wMyAyMDo1ODo1MV0gaHZtLmM6MjQzNTpkMTUgZ3Vlc3QgYXR0ZW1wdGVkIHdyaXRlIHRv
IHJlYWQtb25seSBtZW1vcnkgcGFnZS4gZ2ZuPTB4ZGUsIG1mbj0weGE0YTA5DQooWEVOKSBb
MjAxMi0wOS0wMyAyMDo1ODo1MV0gaHZtLmM6MjQzNTpkMTUgZ3Vlc3QgYXR0ZW1wdGVkIHdy
aXRlIHRvIHJlYWQtb25seSBtZW1vcnkgcGFnZS4gZ2ZuPTB4ZGMsIG1mbj0weGE0YTBiDQoo
WEVOKSBbMjAxMi0wOS0wMyAyMDo1ODo1MV0gaHZtLmM6MjQzNTpkMTUgZ3Vlc3QgYXR0ZW1w
dGVkIHdyaXRlIHRvIHJlYWQtb25seSBtZW1vcnkgcGFnZS4gZ2ZuPTB4ZGQsIG1mbj0weGE0
YTBhDQooWEVOKSBbMjAxMi0wOS0wMyAyMDo1ODo1MV0gaHZtLmM6MjQzNTpkMTUgZ3Vlc3Qg
YXR0ZW1wdGVkIHdyaXRlIHRvIHJlYWQtb25seSBtZW1vcnkgcGFnZS4gZ2ZuPTB4ZGMsIG1m
bj0weGE0YTBiDQooWEVOKSBbMjAxMi0wOS0wMyAyMDo1ODo1MV0gaHZtLmM6MjQzNTpkMTUg
Z3Vlc3QgYXR0ZW1wdGVkIHdyaXRlIHRvIHJlYWQtb25seSBtZW1vcnkgcGFnZS4gZ2ZuPTB4
ZGQsIG1mbj0weGE0YTBhDQooWEVOKSBbMjAxMi0wOS0wMyAyMDo1ODo1MV0gaHZtLmM6MjQz
NTpkMTUgZ3Vlc3QgYXR0ZW1wdGVkIHdyaXRlIHRvIHJlYWQtb25seSBtZW1vcnkgcGFnZS4g
Z2ZuPTB4ZGUsIG1mbj0weGE0YTA5DQooWEVOKSBbMjAxMi0wOS0wMyAyMDo1ODo1MV0gaHZt
LmM6MjQzNTpkMTUgZ3Vlc3QgYXR0ZW1wdGVkIHdyaXRlIHRvIHJlYWQtb25seSBtZW1vcnkg
cGFnZS4gZ2ZuPTB4ZGQsIG1mbj0weGE0YTBhDQooWEVOKSBbMjAxMi0wOS0wMyAyMDo1ODo1
MV0gaHZtLmM6MjQzNTpkMTUgZ3Vlc3QgYXR0ZW1wdGVkIHdyaXRlIHRvIHJlYWQtb25seSBt
ZW1vcnkgcGFnZS4gZ2ZuPTB4ZGMsIG1mbj0weGE0YTBiDQooWEVOKSBbMjAxMi0wOS0wMyAy
MDo1ODo1MV0gaHZtLmM6MjQzNTpkMTUgZ3Vlc3QgYXR0ZW1wdGVkIHdyaXRlIHRvIHJlYWQt
b25seSBtZW1vcnkgcGFnZS4gZ2ZuPTB4ZGQsIG1mbj0weGE0YTBhDQooWEVOKSBbMjAxMi0w
OS0wMyAyMDo1ODo1MV0gaHZtLmM6MjQzNTpkMTUgZ3Vlc3QgYXR0ZW1wdGVkIHdyaXRlIHRv
IHJlYWQtb25seSBtZW1vcnkgcGFnZS4gZ2ZuPTB4ZGMsIG1mbj0weGE0YTBiDQooWEVOKSBb
MjAxMi0wOS0wMyAyMDo1ODo1MV0gaHZtLmM6MjQzNTpkMTUgZ3Vlc3QgYXR0ZW1wdGVkIHdy
aXRlIHRvIHJlYWQtb25seSBtZW1vcnkgcGFnZS4gZ2ZuPTB4ZGQsIG1mbj0weGE0YTBhDQoo
WEVOKSBbMjAxMi0wOS0wMyAyMDo1ODo1NF0gaHZtLmM6MjQzNTpkMTUgZ3Vlc3QgYXR0ZW1w
dGVkIHdyaXRlIHRvIHJlYWQtb25seSBtZW1vcnkgcGFnZS4gZ2ZuPTB4YzksIG1mbj0weGE0
YTFlDQooWEVOKSBbMjAxMi0wOS0wMyAyMDo1ODo1NF0gaHZtLmM6MjQzNTpkMTUgZ3Vlc3Qg
YXR0ZW1wdGVkIHdyaXRlIHRvIHJlYWQtb25seSBtZW1vcnkgcGFnZS4gZ2ZuPTB4Y2IsIG1m
bj0weGE0YTFjDQooWEVOKSBbMjAxMi0wOS0wMyAyMDo1ODo1NF0gaHZtLmM6MjQzNTpkMTUg
Z3Vlc3QgYXR0ZW1wdGVkIHdyaXRlIHRvIHJlYWQtb25seSBtZW1vcnkgcGFnZS4gZ2ZuPTB4
Y2QsIG1mbj0weGE0YTFhDQooWEVOKSBbMjAxMi0wOS0wMyAyMDo1ODo1NF0gaHZtLmM6MjQz
NTpkMTUgZ3Vlc3QgYXR0ZW1wdGVkIHdyaXRlIHRvIHJlYWQtb25seSBtZW1vcnkgcGFnZS4g
Z2ZuPTB4Y2YsIG1mbj0weGE0YTE4DQooWEVOKSBbMjAxMi0wOS0wMyAyMDo1ODo1NF0gaHZt
LmM6MjQzNTpkMTUgZ3Vlc3QgYXR0ZW1wdGVkIHdyaXRlIHRvIHJlYWQtb25seSBtZW1vcnkg
cGFnZS4gZ2ZuPTB4ZDEsIG1mbj0weGE0YTE2DQooWEVOKSBbMjAxMi0wOS0wMyAyMDo1ODo1
NF0gaHZtLmM6MjQzNTpkMTUgZ3Vlc3QgYXR0ZW1wdGVkIHdyaXRlIHRvIHJlYWQtb25seSBt
ZW1vcnkgcGFnZS4gZ2ZuPTB4ZDMsIG1mbj0weGE0YTE0DQooWEVOKSBbMjAxMi0wOS0wMyAy
MDo1ODo1NF0gaHZtLmM6MjQzNTpkMTUgZ3Vlc3QgYXR0ZW1wdGVkIHdyaXRlIHRvIHJlYWQt
b25seSBtZW1vcnkgcGFnZS4gZ2ZuPTB4ZDUsIG1mbj0weGE0YTEyDQooWEVOKSBbMjAxMi0w
OS0wMyAyMDo1ODo1NF0gaHZtLmM6MjQzNTpkMTUgZ3Vlc3QgYXR0ZW1wdGVkIHdyaXRlIHRv
IHJlYWQtb25seSBtZW1vcnkgcGFnZS4gZ2ZuPTB4ZDcsIG1mbj0weGE0YTEwDQooWEVOKSBb
MjAxMi0wOS0wMyAyMDo1ODo1NF0gaHZtLmM6MjQzNTpkMTUgZ3Vlc3QgYXR0ZW1wdGVkIHdy
aXRlIHRvIHJlYWQtb25seSBtZW1vcnkgcGFnZS4gZ2ZuPTB4ZDksIG1mbj0weGE0YTBlDQoo
WEVOKSBbMjAxMi0wOS0wMyAyMDo1ODo1NF0gaHZtLmM6MjQzNTpkMTUgZ3Vlc3QgYXR0ZW1w
dGVkIHdyaXRlIHRvIHJlYWQtb25seSBtZW1vcnkgcGFnZS4gZ2ZuPTB4ZGIsIG1mbj0weGE0
YTBjDQooWEVOKSBbMjAxMi0wOS0wMyAyMDo1ODo1NF0gaHZtLmM6MjQzNTpkMTUgZ3Vlc3Qg
YXR0ZW1wdGVkIHdyaXRlIHRvIHJlYWQtb25seSBtZW1vcnkgcGFnZS4gZ2ZuPTB4ZGQsIG1m
bj0weGE0YTBhDQooWEVOKSBbMjAxMi0wOS0wMyAyMDo1ODo1NF0gaHZtLmM6MjQzNTpkMTUg
Z3Vlc3QgYXR0ZW1wdGVkIHdyaXRlIHRvIHJlYWQtb25seSBtZW1vcnkgcGFnZS4gZ2ZuPTB4
ZGYsIG1mbj0weGE0YTA4DQooWEVOKSBbMjAxMi0wOS0wMyAyMDo1ODo1NF0gaHZtLmM6MjQz
NTpkMTUgZ3Vlc3QgYXR0ZW1wdGVkIHdyaXRlIHRvIHJlYWQtb25seSBtZW1vcnkgcGFnZS4g
Z2ZuPTB4ZTEsIG1mbj0weGE0YTA2DQooWEVOKSBbMjAxMi0wOS0wMyAyMDo1ODo1NF0gaHZt
LmM6MjQzNTpkMTUgZ3Vlc3QgYXR0ZW1wdGVkIHdyaXRlIHRvIHJlYWQtb25seSBtZW1vcnkg
cGFnZS4gZ2ZuPTB4ZTMsIG1mbj0weGE0YTA0DQooWEVOKSBbMjAxMi0wOS0wMyAyMDo1ODo1
NF0gaHZtLmM6MjQzNTpkMTUgZ3Vlc3QgYXR0ZW1wdGVkIHdyaXRlIHRvIHJlYWQtb25seSBt
ZW1vcnkgcGFnZS4gZ2ZuPTB4ZTUsIG1mbj0weGE0YTAyDQooWEVOKSBbMjAxMi0wOS0wMyAy
MDo1ODo1NF0gaHZtLmM6MjQzNTpkMTUgZ3Vlc3QgYXR0ZW1wdGVkIHdyaXRlIHRvIHJlYWQt
b25seSBtZW1vcnkgcGFnZS4gZ2ZuPTB4ZTcsIG1mbj0weGE0YTAwDQooWEVOKSBbMjAxMi0w
OS0wMyAyMDo1ODo1NF0gaHZtLmM6MjQzNTpkMTUgZ3Vlc3QgYXR0ZW1wdGVkIHdyaXRlIHRv
IHJlYWQtb25seSBtZW1vcnkgcGFnZS4gZ2ZuPTB4ZTksIG1mbj0weGE0NjNlDQooWEVOKSBb
MjAxMi0wOS0wMyAyMDo1ODo1NF0gaHZtLmM6MjQzNTpkMTUgZ3Vlc3QgYXR0ZW1wdGVkIHdy
aXRlIHRvIHJlYWQtb25seSBtZW1vcnkgcGFnZS4gZ2ZuPTB4ZWIsIG1mbj0weGE0NjNjDQoo
WEVOKSBbMjAxMi0wOS0wMyAyMDo1ODo1NF0gaHZtLmM6MjQzNTpkMTUgZ3Vlc3QgYXR0ZW1w
dGVkIHdyaXRlIHRvIHJlYWQtb25seSBtZW1vcnkgcGFnZS4gZ2ZuPTB4ZWQsIG1mbj0weGE0
NjNhDQooWEVOKSBbMjAxMi0wOS0wMyAyMDo1ODo1NF0gaHZtLmM6MjQzNTpkMTUgZ3Vlc3Qg
YXR0ZW1wdGVkIHdyaXRlIHRvIHJlYWQtb25seSBtZW1vcnkgcGFnZS4gZ2ZuPTB4ZWYsIG1m
bj0weGE0NjM4DQooWEVOKSBbMjAxMi0wOS0wMyAyMToyMDo0OV0gQU1ELVZpOiBJT19QQUdF
X0ZBVUxUOiBkb21haW4gPSAxNCwgZGV2aWNlIGlkID0gMHgwNzAwLCBmYXVsdCBhZGRyZXNz
ID0gMHhhOGVlODBhMA0KKFhFTikgWzIwMTItMDktMDMgMjE6MjA6NDldIEFNRC1WaTogSU9f
UEFHRV9GQVVMVDogZG9tYWluID0gMTQsIGRldmljZSBpZCA9IDB4MDcwMCwgZmF1bHQgYWRk
cmVzcyA9IDB4YThlZTgwYzANCihYRU4pIFsyMDEyLTA5LTAzIDIxOjIwOjQ5XSBBTUQtVmk6
IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDE0LCBkZXZpY2UgaWQgPSAweDA3MDAsIGZhdWx0
IGFkZHJlc3MgPSAweGE4ZWU4MTAwDQooWEVOKSBbMjAxMi0wOS0wMyAyMToyMDo0OV0gQU1E
LVZpOiBJT19QQUdFX0ZBVUxUOiBkb21haW4gPSAxNCwgZGV2aWNlIGlkID0gMHgwNzAwLCBm
YXVsdCBhZGRyZXNzID0gMHhhOGVlODE4MA0KKFhFTikgWzIwMTItMDktMDMgMjE6MjA6NDld
IEFNRC1WaTogSU9fUEFHRV9GQVVMVDogZG9tYWluID0gMTQsIGRldmljZSBpZCA9IDB4MDcw
MCwgZmF1bHQgYWRkcmVzcyA9IDB4YThlZTgxMjANCihYRU4pIFsyMDEyLTA5LTAzIDIxOjIw
OjQ5XSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDE0LCBkZXZpY2UgaWQgPSAw
eDA3MDAsIGZhdWx0IGFkZHJlc3MgPSAweGE4ZWU4MTQwDQooWEVOKSBbMjAxMi0wOS0wMyAy
MToyMDo0OV0gQU1ELVZpOiBJT19QQUdFX0ZBVUxUOiBkb21haW4gPSAxNCwgZGV2aWNlIGlk
ID0gMHgwNzAwLCBmYXVsdCBhZGRyZXNzID0gMHhhOGVlODFhMA0KKFhFTikgWzIwMTItMDkt
MDMgMjE6MjA6NDldIEFNRC1WaTogSU9fUEFHRV9GQVVMVDogZG9tYWluID0gMTQsIGRldmlj
ZSBpZCA9IDB4MDcwMCwgZmF1bHQgYWRkcmVzcyA9IDB4YThlZTgxYzANCihYRU4pIFsyMDEy
LTA5LTAzIDIxOjIwOjQ5XSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDE0LCBk
ZXZpY2UgaWQgPSAweDA3MDAsIGZhdWx0IGFkZHJlc3MgPSAweGE4ZWU4MjAwDQooWEVOKSBb
MjAxMi0wOS0wMyAyMToyMDo0OV0gQU1ELVZpOiBJT19QQUdFX0ZBVUxUOiBkb21haW4gPSAx
NCwgZGV2aWNlIGlkID0gMHgwNzAwLCBmYXVsdCBhZGRyZXNzID0gMHhhOGVlODIyMA0KKFhF
TikgWzIwMTItMDktMDMgMjE6MjA6NDldIEFNRC1WaTogSU9fUEFHRV9GQVVMVDogZG9tYWlu
ID0gMTQsIGRldmljZSBpZCA9IDB4MDcwMCwgZmF1bHQgYWRkcmVzcyA9IDB4YThlZTgyNDAN
CihYRU4pIFsyMDEyLTA5LTAzIDIxOjIwOjQ5XSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRv
bWFpbiA9IDE0LCBkZXZpY2UgaWQgPSAweDA3MDAsIGZhdWx0IGFkZHJlc3MgPSAweGE4ZWU4
MjgwDQooWEVOKSBbMjAxMi0wOS0wMyAyMToyMDo0OV0gQU1ELVZpOiBJT19QQUdFX0ZBVUxU
OiBkb21haW4gPSAxNCwgZGV2aWNlIGlkID0gMHgwNzAwLCBmYXVsdCBhZGRyZXNzID0gMHhh
OGVlODJhMA0KKFhFTikgWzIwMTItMDktMDMgMjE6MjA6NDldIEFNRC1WaTogSU9fUEFHRV9G
QVVMVDogZG9tYWluID0gMTQsIGRldmljZSBpZCA9IDB4MDcwMCwgZmF1bHQgYWRkcmVzcyA9
IDB4YThlZTgzMDANCihYRU4pIFsyMDEyLTA5LTAzIDIxOjIwOjQ5XSBBTUQtVmk6IElPX1BB
R0VfRkFVTFQ6IGRvbWFpbiA9IDE0LCBkZXZpY2UgaWQgPSAweDA3MDAsIGZhdWx0IGFkZHJl
c3MgPSAweGE4ZWU4MmMwDQooWEVOKSBbMjAxMi0wOS0wMyAyMToyMDo0OV0gQU1ELVZpOiBJ
T19QQUdFX0ZBVUxUOiBkb21haW4gPSAxNCwgZGV2aWNlIGlkID0gMHgwNzAwLCBmYXVsdCBh
ZGRyZXNzID0gMHhhOGVlODMyMA0KKFhFTikgWzIwMTItMDktMDQgMDM6MDA6MzRdIHRyYXBz
LmM6MzE1NjogR1BGICgwMDYwKTogZmZmZjgyYzQ4MDE1YzllZSAtPiBmZmZmODJjNDgwMjI0
YjczDQooWEVOKSBbMjAxMi0wOS0wNCAwMzowMDozNF0gdHJhcHMuYzozMTU3OiAgc2hvd19l
eGVjdXRpb25fc3RhdGUocmVncyk6IA0KKFhFTikgWzIwMTItMDktMDQgMDM6MDA6MzRdIC0t
LS1bIFhlbi00LjIuMC1yYzQtcHJlICB4ODZfNjQgIGRlYnVnPXkgIE5vdCB0YWludGVkIF0t
LS0tDQooWEVOKSBbMjAxMi0wOS0wNCAwMzowMDozNF0gQ1BVOiAgICAzDQooWEVOKSBbMjAx
Mi0wOS0wNCAwMzowMDozNF0gUklQOiAgICBlMDA4Ols8ZmZmZjgyYzQ4MDE1YzllZT5dIGNv
bnRleHRfc3dpdGNoKzB4Mzk0LzB4ZWViDQooWEVOKSBbMjAxMi0wOS0wNCAwMzowMDozNF0g
UkZMQUdTOiAwMDAwMDAwMDAwMDEwMjQ2ICAgQ09OVEVYVDogaHlwZXJ2aXNvcg0KKFhFTikg
WzIwMTItMDktMDQgMDM6MDA6MzRdIHJheDogMDAwMDAwMDAwMDAwMDAwMSAgIHJieDogZmZm
ZjgzMDBhNTJkYTAwMCAgIHJjeDogMDAwMDAwMDAwMDAwMDAwMQ0KKFhFTikgWzIwMTItMDkt
MDQgMDM6MDA6MzRdIHJkeDogMDAwMDAwMDAwMDAwMDA2MyAgIHJzaTogMDAwMDAwMDAwMDAw
MDAwMSAgIHJkaTogMDAwMDAwMDAwMDAwMDM3ZQ0KKFhFTikgWzIwMTItMDktMDQgMDM6MDA6
MzRdIHJicDogZmZmZjgzMDI0ZDhhN2UyOCAgIHJzcDogZmZmZjgzMDI0ZDhhN2Q4OCAgIHI4
OiAgMDAwMDAwMDAwMDAwMDAwNg0KKFhFTikgWzIwMTItMDktMDQgMDM6MDA6MzRdIHI5OiAg
ZmZmZjgzMDI0ZDk1ZWJiOCAgIHIxMDogMDAwMDAwMDBkZWFkYmVlZiAgIHIxMTogMDAwMDAw
MDAwMDAwMDI0Ng0KKFhFTikgWzIwMTItMDktMDQgMDM6MDA6MzRdIHIxMjogZmZmZjgzMDBh
ZmQxMTAwMCAgIHIxMzogMDAwMDAwMDAwMDAwMDAwMyAgIHIxNDogMDAwMDAwMDAwMDAwMDAw
Mw0KKFhFTikgWzIwMTItMDktMDQgMDM6MDA6MzRdIHIxNTogZmZmZjgzMDI0ZDhhYTA0OCAg
IGNyMDogMDAwMDAwMDA4MDA1MDAzYiAgIGNyNDogMDAwMDAwMDAwMDAwMDZmMA0KKFhFTikg
WzIwMTItMDktMDQgMDM6MDA6MzRdIGNyMzogMDAwMDAwMDA2ODUwNjAwMCAgIGNyMjogZmZm
ZmZmZmZmZjYwMDQwMA0KKFhFTikgWzIwMTItMDktMDQgMDM6MDA6MzRdIGRzOiAwMDAwICAg
ZXM6IDAwMDAgICBmczogMDAwMCAgIGdzOiAwMDAwICAgc3M6IGUwMTAgICBjczogZTAwOA0K
KFhFTikgWzIwMTItMDktMDQgMDM6MDA6MzRdIFhlbiBzdGFjayB0cmFjZSBmcm9tIHJzcD1m
ZmZmODMwMjRkOGE3ZDg4Og0KKFhFTikgWzIwMTItMDktMDQgMDM6MDA6MzRdICAgIDAwMDAw
MDAwMDAwMDAwMjkgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAxZTAwMDAwMDAwIDAwMDAwMDAw
MDAwMDAwMDANCihYRU4pIFsyMDEyLTA5LTA0IDAzOjAwOjM0XSAgICBmZmZmODMwMjRkOGE3
ZGI4IGZmZmY4MzAyNGQ4YWEwNjAgZmZmZjgzMDI0ZDhhN2UxOCBmZmZmODJjNDgwMTgwNWFl
DQooWEVOKSBbMjAxMi0wOS0wNCAwMzowMDozNF0gICAgMDAwMDAwMDAwMDAxMmYyMiAwMDAw
M2ZkOWFiNmQ2Y2E2IDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMA0KKFhFTikg
WzIwMTItMDktMDQgMDM6MDA6MzRdICAgIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAw
MDAwMCBmZmZmODMwMjRkOGE3ZTI4IGZmZmY4MzAwYWZkMTEwMDANCihYRU4pIFsyMDEyLTA5
LTA0IDAzOjAwOjM0XSAgICBmZmZmODMwMGE1MmRhMDAwIDAwMDAxM2ViYmEzN2UxMGMgMDAw
MDAwMDAwMDAwMDAwMiBmZmZmODMwMjRkOGFhMDQ4DQooWEVOKSBbMjAxMi0wOS0wNCAwMzow
MDozNF0gICAgZmZmZjgzMDI0ZDhhN2ViOCBmZmZmODJjNDgwMTI0YTcwIDAwMDAwMDAwMDAw
MDAwMDAgZmZmZjgzMDI0ZDhhYTA0MA0KKFhFTikgWzIwMTItMDktMDQgMDM6MDA6MzRdICAg
IDAwMDAwMDAzNGQ4YTdlNjggMDAwMDEzZWJiYTM3ZTEwYyBmZmZmODMwMjRkOGE3ZTg4IGZm
ZmY4MmM0ODAxODk0ODMNCihYRU4pIFsyMDEyLTA5LTA0IDAzOjAwOjM0XSAgICBmZmZmODMw
MGE1MmRhMDAwIDAwMDAwMDAwMDFjOWMzODAgZmZmZjgzMDI0ZDhhN2UwMCBmZmZmODJjNDgw
MTIyNmNlDQooWEVOKSBbMjAxMi0wOS0wNCAwMzowMDozNF0gICAgZmZmZjgzMDI0ZDhhN2Vm
OCBmZmZmODJjNDgwMmQ4MTgwIDAwMDAwMDAwZmZmZmZmZmYgZmZmZjgyYzQ4MDJkODAwMA0K
KFhFTikgWzIwMTItMDktMDQgMDM6MDA6MzRdICAgIGZmZmY4MzAyNGQ4YTdmMTggZmZmZmZm
ZmZmZmZmZmZmZiBmZmZmODMwMjRkOGE3ZWY4IGZmZmY4MmM0ODAxMjVlMzENCihYRU4pIFsy
MDEyLTA5LTA0IDAzOjAwOjM0XSAgICAwMDAwMDAwMDAwMDAwMjQ2IGZmZmY4MzAwYWZkMTEw
MDAgZmZmZmZmZmY4MWVjZTVkOCBmZmZmZmZmZjgxZjQyMGMwDQooWEVOKSBbMjAxMi0wOS0w
NCAwMzowMDozNF0gICAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIGZmZmY4
MzAyNGQ4YTdmMDggZmZmZjgyYzQ4MDEyNWU2OA0KKFhFTikgWzIwMTItMDktMDQgMDM6MDA6
MzRdICAgIDAwMDA3Y2ZkYjI3NTgwYzcgZmZmZjgyYzQ4MDIyMmVmNiAwMDAwMDAwMDAwMDAw
MDAwIGZmZmY4ODAwMDMwZTE0YTANCihYRU4pIFsyMDEyLTA5LTA0IDAzOjAwOjM0XSAgICAw
MDAwMDAwMDAwMDAwMDAwIGZmZmY4ODAwMWEwODAwZDggZmZmZjg4MDAxY2QxN2JmMCBmZmZm
ODgwMDFmYzBiMTAwDQooWEVOKSBbMjAxMi0wOS0wNCAwMzowMDozNF0gICAgMDAwMDAwMDAw
MDAwMDIwMiAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDEgMDAwMDAwMDAwMDAw
MDAwMA0KKFhFTikgWzIwMTItMDktMDQgMDM6MDA6MzRdICAgIDAwMDAwMDAwMDAwMDAwMDAg
ZmZmZmZmZmY4MTAwMTFhYSBmZmZmODgwMDFlOTllMTgwIDAwMDAwMDAwZGVhZGJlZWYNCihY
RU4pIFsyMDEyLTA5LTA0IDAzOjAwOjM0XSAgICAwMDAwMDAwMGRlYWRiZWVmIDAwMDAwMTAw
MDAwMDAwMDAgZmZmZmZmZmY4MTAwMTFhYSAwMDAwMDAwMDAwMDBlMDMzDQooWEVOKSBbMjAx
Mi0wOS0wNCAwMzowMDozNF0gICAgMDAwMDAwMDAwMDAwMDIwMiBmZmZmODgwMDFjZDE3YmI4
IDAwMDAwMDAwMDAwMGUwMmIgMDAwMDUzZmQwMDAwYmVlZg0KKFhFTikgWzIwMTItMDktMDQg
MDM6MDA6MzRdICAgIDgwMDAwMDAwMDAwMGJlZWYgNzQwMDAwMDAwMDAwYmVlZiAwMDAwMDAw
MDAwMThiZWVmIDAwMDA1M2ZlMDAwMDAwMDMNCihYRU4pIFsyMDEyLTA5LTA0IDAzOjAwOjM0
XSAgICBmZmZmODMwMGE1MmRhMDAwIDAwMDAwMDNkY2Q1YTg2ODAgMDAwMDAwMDAwMDE4ZTBj
OQ0KKFhFTikgWzIwMTItMDktMDQgMDM6MDA6MzRdIFhlbiBjYWxsIHRyYWNlOg0KKFhFTikg
WzIwMTItMDktMDQgMDM6MDA6MzRdICAgIFs8ZmZmZjgyYzQ4MDE1YzllZT5dIGNvbnRleHRf
c3dpdGNoKzB4Mzk0LzB4ZWViDQooWEVOKSBbMjAxMi0wOS0wNCAwMzowMDozNF0gICAgWzxm
ZmZmODJjNDgwMTI0YTcwPl0gc2NoZWR1bGUrMHg2NjYvMHg2NzUNCihYRU4pIFsyMDEyLTA5
LTA0IDAzOjAwOjM0XSAgICBbPGZmZmY4MmM0ODAxMjVlMzE+XSBfX2RvX3NvZnRpcnErMHhh
NC8weGI1DQooWEVOKSBbMjAxMi0wOS0wNCAwMzowMDozNF0gICAgWzxmZmZmODJjNDgwMTI1
ZTY4Pl0gZG9fc29mdGlycSsweDI2LzB4MjgNCihYRU4pIFsyMDEyLTA5LTA0IDAzOjAwOjM0
XSAgICANCihYRU4pIFsyMDEyLTA5LTA0IDAzOjAwOjM0XSB0cmFwcy5jOjMxNTk6ICAgc2hv
d19leGVjdXRpb25fc3RhdGUoZ3Vlc3RfY3B1X3VzZXJfcmVncygpKTogDQooWEVOKSBbMjAx
Mi0wOS0wNCAwMzowMDozNF0gLS0tLVsgWGVuLTQuMi4wLXJjNC1wcmUgIHg4Nl82NCAgZGVi
dWc9eSAgTm90IHRhaW50ZWQgXS0tLS0NCihYRU4pIFsyMDEyLTA5LTA0IDAzOjAwOjM0XSBD
UFU6ICAgIDMNCihYRU4pIFsyMDEyLTA5LTA0IDAzOjAwOjM0XSBSSVA6ICAgIGUwMzM6Wzxm
ZmZmZmZmZjgxMDAxMWFhPl0NCihYRU4pIFsyMDEyLTA5LTA0IDAzOjAwOjM0XSBSRkxBR1M6
IDAwMDAwMDAwMDAwMDAyMDIgICBFTTogMSAgIENPTlRFWFQ6IHB2IGd1ZXN0DQooWEVOKSBb
MjAxMi0wOS0wNCAwMzowMDozNF0gcmF4OiAwMDAwMDAwMDAwMDAwMDAwICAgcmJ4OiBmZmZm
ODgwMDFmYzBiMTAwICAgcmN4OiBmZmZmZmZmZjgxMDAxMWFhDQooWEVOKSBbMjAxMi0wOS0w
NCAwMzowMDozNF0gcmR4OiBmZmZmODgwMDFlOTllMTgwICAgcnNpOiAwMDAwMDAwMGRlYWRi
ZWVmICAgcmRpOiAwMDAwMDAwMGRlYWRiZWVmDQooWEVOKSBbMjAxMi0wOS0wNCAwMzowMDoz
NF0gcmJwOiBmZmZmODgwMDFjZDE3YmYwICAgcnNwOiBmZmZmODgwMDFjZDE3YmI4ICAgcjg6
ICAwMDAwMDAwMDAwMDAwMDAwDQooWEVOKSBbMjAxMi0wOS0wNCAwMzowMDozNF0gcjk6ICAw
MDAwMDAwMDAwMDAwMDAxICAgcjEwOiAwMDAwMDAwMDAwMDAwMDAwICAgcjExOiAwMDAwMDAw
MDAwMDAwMjAyDQooWEVOKSBbMjAxMi0wOS0wNCAwMzowMDozNF0gcjEyOiBmZmZmODgwMDFh
MDgwMGQ4ICAgcjEzOiAwMDAwMDAwMDAwMDAwMDAwICAgcjE0OiBmZmZmODgwMDAzMGUxNGEw
DQooWEVOKSBbMjAxMi0wOS0wNCAwMzowMDozNF0gcjE1OiAwMDAwMDAwMDAwMDAwMDAwICAg
Y3IwOiAwMDAwMDAwMDgwMDUwMDNiICAgY3I0OiAwMDAwMDAwMDAwMDAwNmYwDQooWEVOKSBb
MjAxMi0wOS0wNCAwMzowMDozNF0gY3IzOiAwMDAwMDAwMDY4NTA2MDAwICAgY3IyOiAwMDAw
MDAwMGY3NmU0MDAwDQooWEVOKSBbMjAxMi0wOS0wNCAwMzowMDozNF0gZHM6IDAwMDAgICBl
czogMDAwMCAgIGZzOiAwMDAwICAgZ3M6IDAwMDAgICBzczogZTAyYiAgIGNzOiBlMDMzDQoo
WEVOKSBbMjAxMi0wOS0wNCAwMzowMDozNF0gR3Vlc3Qgc3RhY2sgdHJhY2UgZnJvbSByc3A9
ZmZmZjg4MDAxY2QxN2JiODoNCihYRU4pIFsyMDEyLTA5LTA0IDAzOjAwOjM0XSAgICAwMDAw
MDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDEgZmZmZmZmZmY4MTAwNDk0MiBmZmZmODgw
MDAzMGUxMDQwDQooWEVOKSBbMjAxMi0wOS0wNCAwMzowMDozNF0gICAgZmZmZjg4MDAxZTk5
ZTE4MCAwMDAwMDAwMDAwMDAwMDAwIGZmZmY4ODAwMDMwZTE0YTAgZmZmZjg4MDAxY2QxN2Mx
MA0KKFhFTikgWzIwMTItMDktMDQgMDM6MDA6MzRdICAgIGZmZmZmZmZmODEwMDM5NDEgZmZm
Zjg4MDAxZTk5ZTE4MCBmZmZmODgwMDAzMGUxMDQwIGZmZmY4ODAwMWNkMTdjNzANCihYRU4p
IFsyMDEyLTA5LTA0IDAzOjAwOjM0XSAgICBmZmZmZmZmZjgxMDBiODUwIGZmZmY4ODAwMDMw
ZTEwNDAgZmZmZjg4MDAxZDI4MDA4MCAwMDAwMDAwMDAwMDAwMDYzDQooWEVOKSBbMjAxMi0w
OS0wNCAwMzowMDozNF0gICAgZmZmZjg4MDAxZmMxMGE4MCBmZmZmODgwMDFjZDE3YzgwIGZm
ZmY4ODAwMWZjMTJlODAgMDAwMDAwMDAwMDAwMDAwMA0KKFhFTikgWzIwMTItMDktMDQgMDM6
MDA6MzRdICAgIGZmZmY4ODAwMWQyODViMDAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAw
MDAwMDAwIGZmZmY4ODAwMDMwZTEwNDANCihYRU4pIFsyMDEyLTA5LTA0IDAzOjAwOjM0XSAg
ICBmZmZmZmZmZjgxN2ZhMmY1IGZmZmY4ODAwMWNkMTdkZDAgMDAwMDAwMDAwMDAwMDIxNiBm
ZmZmZmZmZjgxMDcwMGZlDQooWEVOKSBbMjAxMi0wOS0wNCAwMzowMDozNF0gICAgZmZmZjg4
MDAxZmMwZTAxOCBmZmZmODgwMDAzMGUxMDQwIDAwMDAwMDAwMDAwMTJlODAgZmZmZjg4MDAx
Y2QxN2ZkOA0KKFhFTikgWzIwMTItMDktMDQgMDM6MDA6MzRdICAgIGZmZmY4ODAwMWNkMTYw
MTAgMDAwMDAwMDAwMDAxMmU4MCAwMDAwMDAwMDAwMDEyZTgwIGZmZmY4ODAwMWNkMTdmZDgN
CihYRU4pIFsyMDEyLTA5LTA0IDAzOjAwOjM0XSAgICAwMDAwMDAwMDAwMDEyZTgwIGZmZmY4
ODAwMWU5OTkwNDAgZmZmZjg4MDAwMzBlMTA0MCBmZmZmODgwMDAwMDAwMDAwDQooWEVOKSBb
MjAxMi0wOS0wNCAwMzowMDozNF0gICAgZmZmZjg4MDAwMDAwMDAwMCBmZmZmODgwMDFmYzBl
MDAwIGZmZmY4ODAwMWNkYjMzMDAgZmZmZjg4MDAxZmMxNmUwMA0KKFhFTikgWzIwMTItMDkt
MDQgMDM6MDA6MzRdICAgIGZmZmY4ODAwMWZjMGUwMDAgZmZmZjg4MDAxY2QxN2Q1MCBmZmZm
ZmZmZjgxN2ZiNjE0IGZmZmY4ODAwMWQwOGMxNDANCihYRU4pIFsyMDEyLTA5LTA0IDAzOjAw
OjM0XSAgICBmZmZmODgwMDFjZGIzMzAwIGZmZmY4ODAwMWZjMTZlMDAgZmZmZjg4MDAxZmMw
ZTAwMCBmZmZmODgwMDFjZDE3ZGUwDQooWEVOKSBbMjAxMi0wOS0wNCAwMzowMDozNF0gICAg
ZmZmZmZmZmY4MTA3ZjA1OSBmZmZmODgwMDAzMGUxMDQwIGZmZmY4ODAwMDMwZTEwNDAgZmZm
ZmZmZmY4MTdmYmU3Yg0KKFhFTikgWzIwMTItMDktMDQgMDM6MDA6MzRdICAgIGZmZmY4ODAw
MWZjMGU0NDggZmZmZjg4MDAwMzBlMTA0MCBmZmZmODgwMDFjZGIzMzIwIGZmZmY4ODAwMWNk
MTdkYjANCihYRU4pIFsyMDEyLTA5LTA0IDAzOjAwOjM0XSAgICBmZmZmZmZmZjgxMGFjYjc4
IGZmZmY4ODAwMWZjMGUwMDAgZmZmZjg4MDAxY2RiMzMwMCBmZmZmODgwMDFmYzBlNDM4DQoo
WEVOKSBbMjAxMi0wOS0wNCAwMzowMDozNF0gICAgZmZmZjg4MDAxZmMwZTQ0OCBmZmZmODgw
MDAzMGUxMDQwIGZmZmY4ODAwMWNkYjMzMjAgZmZmZjg4MDAxY2QxN2RlMA0KKFhFTikgWzIw
MTItMDktMDQgMDM6MDA6MzRdICAgIGZmZmZmZmZmODE3ZmE4MTQgZmZmZjg4MDAxY2QxN2Vi
MCBmZmZmZmZmZjgxMDdmNmY5IDAwMDAwMDAwMDAwMDAwMDANCihYRU4pIFsyMDEyLTA5LTA0
IDAzOjAwOjM0XSAgICBmZmZmODgwMDFjZDE3ZTUwIGZmZmY4ODAwMDMwZTEwNDAgZmZmZjg4
MDAxY2QxNjAxMCBmZmZmODgwMDAzMGUwMjQwDQooWEVOKSBbMjAxMi0wOS0wNCAwMzowMDoz
NF0gICAgZmZmZjg4MDAxY2QxN2U2OCBmZmZmODgwMDAzMGUxMDQwIGZmZmY4ODAwMDMwZTEw
NDAgZmZmZjg4MDAwMzBlMTA0MA0KKFhFTikgWzIwMTItMDktMDQgMDM6MTU6MTJdIGdyYW50
X3RhYmxlLmM6MjU0OmQwIEluY3JlYXNlZCBtYXB0cmFjayBzaXplIHRvIDIgZnJhbWVzDQo=
------------05A1A81AE2E0F0B49
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

------------05A1A81AE2E0F0B49--



From xen-devel-bounces@lists.xen.org Tue Sep 04 07:31:32 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Sep 2012 07:31:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T8nbM-00029v-2n; Tue, 04 Sep 2012 07:31:12 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1T8nbK-00029m-Uo
	for xen-devel@lists.xen.org; Tue, 04 Sep 2012 07:31:11 +0000
Received: from [85.158.139.83:54624] by server-7.bemta-5.messagelabs.com id
	03/EF-19703-E3EA5405; Tue, 04 Sep 2012 07:31:10 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1346743869!28394376!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTE2MDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32220 invoked from network); 4 Sep 2012 07:31:09 -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;
	4 Sep 2012 07:31:09 -0000
X-IronPort-AV: E=Sophos;i="4.80,365,1344211200"; d="scan'208";a="14327530"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Sep 2012 07:31:08 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Tue, 4 Sep 2012
	08:31:08 +0100
Message-ID: <1346743867.10570.2.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Mark van Dijk <lists+xen@internecto.net>
Date: Tue, 4 Sep 2012 08:31:07 +0100
In-Reply-To: <20120904090601.77377684@internecto.net>
References: <1346665360.25864.2.camel@zakaz.uk.xensource.com>
	<20120904090601.77377684@internecto.net>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-users@lists.xen.org" <xen-users@lists.xen.org>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [Xen-users] Xen 4.2.0 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-09-04 at 08:06 +0100, Mark van Dijk wrote:
> Good morning, 
> 
> I realise I'm probably too late, but if it's trivial then maybe it is
> possible to implement an 'xl reset vmname' function before the final
> release.
> 
> Or is this not as trivial as I think it is?

What is it supposed to do?

Ian.



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

From xen-devel-bounces@lists.xen.org Tue Sep 04 07:31:32 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Sep 2012 07:31:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T8nbM-00029v-2n; Tue, 04 Sep 2012 07:31:12 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1T8nbK-00029m-Uo
	for xen-devel@lists.xen.org; Tue, 04 Sep 2012 07:31:11 +0000
Received: from [85.158.139.83:54624] by server-7.bemta-5.messagelabs.com id
	03/EF-19703-E3EA5405; Tue, 04 Sep 2012 07:31:10 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1346743869!28394376!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTE2MDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32220 invoked from network); 4 Sep 2012 07:31:09 -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;
	4 Sep 2012 07:31:09 -0000
X-IronPort-AV: E=Sophos;i="4.80,365,1344211200"; d="scan'208";a="14327530"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Sep 2012 07:31:08 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Tue, 4 Sep 2012
	08:31:08 +0100
Message-ID: <1346743867.10570.2.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Mark van Dijk <lists+xen@internecto.net>
Date: Tue, 4 Sep 2012 08:31:07 +0100
In-Reply-To: <20120904090601.77377684@internecto.net>
References: <1346665360.25864.2.camel@zakaz.uk.xensource.com>
	<20120904090601.77377684@internecto.net>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-users@lists.xen.org" <xen-users@lists.xen.org>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [Xen-users] Xen 4.2.0 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-09-04 at 08:06 +0100, Mark van Dijk wrote:
> Good morning, 
> 
> I realise I'm probably too late, but if it's trivial then maybe it is
> possible to implement an 'xl reset vmname' function before the final
> release.
> 
> Or is this not as trivial as I think it is?

What is it supposed to do?

Ian.



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

From xen-devel-bounces@lists.xen.org Tue Sep 04 07:34:51 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Sep 2012 07:34: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 1T8ned-0002Su-AD; Tue, 04 Sep 2012 07:34:35 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <cdelorme@gmail.com>) id 1T8nec-0002Sb-7x
	for xen-devel@lists.xen.org; Tue, 04 Sep 2012 07:34:34 +0000
Received: from [85.158.139.83:29107] by server-9.bemta-5.messagelabs.com id
	5B/6A-20529-90FA5405; Tue, 04 Sep 2012 07:34:33 +0000
X-Env-Sender: cdelorme@gmail.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1346744071!17138312!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-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2237 invoked from network); 4 Sep 2012 07:34:32 -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;
	4 Sep 2012 07:34:32 -0000
Received: by obbta14 with SMTP id ta14so13683510obb.32
	for <multiple recipients>; Tue, 04 Sep 2012 00:34: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=Yl2VNIJXO2hBbzyzxaXPafnu/SdZmw/XtyMjFL9Bw0s=;
	b=YiSyuvlKRvFaubW6Dk2dDzOXrWFqzNfEUJwkWhxUqHMMU5xR/V8cijFBPEsXGXfrya
	AM3JFV673c2KTbzxMXozOjzdSMY3Ndro5KpTkUrXvNFoXbTo3OCynIDj3CLVf487dYOZ
	0sRjDh5Qs6JisnS3VvLpWMJiykAKZWvp69gz47Wab0JvZOLe33y3LDima5X0EHBfRmL5
	IXLjbHnZlHGe0RcnYNK+E6bLNaLnHuWtCMH21f5HgBNf8ck377tD9RATEorLnEz5sPvC
	FLvd0HIRzf0gdb7kIZgqQdrlQB0qmeszjS/fB6O9nYrJ1nlveU+ZuCSgyPkkvX6jetg2
	BWYA==
MIME-Version: 1.0
Received: by 10.60.170.229 with SMTP id ap5mr15430194oec.101.1346744070818;
	Tue, 04 Sep 2012 00:34:30 -0700 (PDT)
Received: by 10.76.115.197 with HTTP; Tue, 4 Sep 2012 00:34:30 -0700 (PDT)
In-Reply-To: <20120904090601.77377684@internecto.net>
References: <1346665360.25864.2.camel@zakaz.uk.xensource.com>
	<20120904090601.77377684@internecto.net>
Date: Tue, 4 Sep 2012 03:34:30 -0400
Message-ID: <CAA7N5RZVgv+Q4cNrs_A-mvfTNZOoUusJMEA0vvqN8OzjCxYzoA@mail.gmail.com>
From: Casey DeLorme <cdelorme@gmail.com>
To: Mark van Dijk <lists+xen@internecto.net>
Cc: xen-users@lists.xen.org, Ian Campbell <Ian.Campbell@citrix.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [Xen-users] Xen 4.2.0 Release Plan / TODO
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============3886292734653545403=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============3886292734653545403==
Content-Type: multipart/alternative; boundary=bcaec54b4ac0f1cb1704c8db490b

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

Would reset be different than reboot?
http://xenbits.xen.org/docs/unstable/man/xl.1.html

On Tue, Sep 4, 2012 at 3:06 AM, Mark van Dijk <lists+xen@internecto.net>wrote:

> Good morning,
>
> I realise I'm probably too late, but if it's trivial then maybe it is
> possible to implement an 'xl reset vmname' function before the final
> release.
>
> Or is this not as trivial as I think it is?
>
> --
> Stay in touch,
> Mark van Dijk.               ,---------------------------------
> ----------------------------'         Tue Sep 04 07:04 UTC 2012
> Today is Boomtime, the 28th day of Bureaucracy in the YOLD 3178
>
> _______________________________________________
> Xen-users mailing list
> Xen-users@lists.xen.org
> http://lists.xen.org/xen-users
>

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

Would reset be different than reboot?<div><a href=3D"http://xenbits.xen.org=
/docs/unstable/man/xl.1.html">http://xenbits.xen.org/docs/unstable/man/xl.1=
.html</a><br><br><div class=3D"gmail_quote">On Tue, Sep 4, 2012 at 3:06 AM,=
 Mark van Dijk <span dir=3D"ltr">&lt;<a href=3D"mailto:lists+xen@internecto=
.net" target=3D"_blank">lists+xen@internecto.net</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">Good morning,<br>
<br>
I realise I&#39;m probably too late, but if it&#39;s trivial then maybe it =
is<br>
possible to implement an &#39;xl reset vmname&#39; function before the fina=
l<br>
release.<br>
<br>
Or is this not as trivial as I think it is?<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
--<br>
Stay in touch,<br>
Mark van Dijk. =A0 =A0 =A0 =A0 =A0 =A0 =A0 ,-------------------------------=
--<br>
----------------------------&#39; =A0 =A0 =A0 =A0 Tue Sep 04 07:04 UTC 2012=
<br>
Today is Boomtime, the 28th day of Bureaucracy in the YOLD 3178<br>
</font></span><div class=3D"HOEnZb"><div class=3D"h5"><br>
_______________________________________________<br>
Xen-users mailing list<br>
<a href=3D"mailto:Xen-users@lists.xen.org">Xen-users@lists.xen.org</a><br>
<a href=3D"http://lists.xen.org/xen-users" target=3D"_blank">http://lists.x=
en.org/xen-users</a><br>
</div></div></blockquote></div><br></div>

--bcaec54b4ac0f1cb1704c8db490b--


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

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

--===============3886292734653545403==--


From xen-devel-bounces@lists.xen.org Tue Sep 04 07:34:51 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Sep 2012 07:34: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 1T8ned-0002Su-AD; Tue, 04 Sep 2012 07:34:35 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <cdelorme@gmail.com>) id 1T8nec-0002Sb-7x
	for xen-devel@lists.xen.org; Tue, 04 Sep 2012 07:34:34 +0000
Received: from [85.158.139.83:29107] by server-9.bemta-5.messagelabs.com id
	5B/6A-20529-90FA5405; Tue, 04 Sep 2012 07:34:33 +0000
X-Env-Sender: cdelorme@gmail.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1346744071!17138312!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-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2237 invoked from network); 4 Sep 2012 07:34:32 -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;
	4 Sep 2012 07:34:32 -0000
Received: by obbta14 with SMTP id ta14so13683510obb.32
	for <multiple recipients>; Tue, 04 Sep 2012 00:34: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=Yl2VNIJXO2hBbzyzxaXPafnu/SdZmw/XtyMjFL9Bw0s=;
	b=YiSyuvlKRvFaubW6Dk2dDzOXrWFqzNfEUJwkWhxUqHMMU5xR/V8cijFBPEsXGXfrya
	AM3JFV673c2KTbzxMXozOjzdSMY3Ndro5KpTkUrXvNFoXbTo3OCynIDj3CLVf487dYOZ
	0sRjDh5Qs6JisnS3VvLpWMJiykAKZWvp69gz47Wab0JvZOLe33y3LDima5X0EHBfRmL5
	IXLjbHnZlHGe0RcnYNK+E6bLNaLnHuWtCMH21f5HgBNf8ck377tD9RATEorLnEz5sPvC
	FLvd0HIRzf0gdb7kIZgqQdrlQB0qmeszjS/fB6O9nYrJ1nlveU+ZuCSgyPkkvX6jetg2
	BWYA==
MIME-Version: 1.0
Received: by 10.60.170.229 with SMTP id ap5mr15430194oec.101.1346744070818;
	Tue, 04 Sep 2012 00:34:30 -0700 (PDT)
Received: by 10.76.115.197 with HTTP; Tue, 4 Sep 2012 00:34:30 -0700 (PDT)
In-Reply-To: <20120904090601.77377684@internecto.net>
References: <1346665360.25864.2.camel@zakaz.uk.xensource.com>
	<20120904090601.77377684@internecto.net>
Date: Tue, 4 Sep 2012 03:34:30 -0400
Message-ID: <CAA7N5RZVgv+Q4cNrs_A-mvfTNZOoUusJMEA0vvqN8OzjCxYzoA@mail.gmail.com>
From: Casey DeLorme <cdelorme@gmail.com>
To: Mark van Dijk <lists+xen@internecto.net>
Cc: xen-users@lists.xen.org, Ian Campbell <Ian.Campbell@citrix.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [Xen-users] Xen 4.2.0 Release Plan / TODO
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============3886292734653545403=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============3886292734653545403==
Content-Type: multipart/alternative; boundary=bcaec54b4ac0f1cb1704c8db490b

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

Would reset be different than reboot?
http://xenbits.xen.org/docs/unstable/man/xl.1.html

On Tue, Sep 4, 2012 at 3:06 AM, Mark van Dijk <lists+xen@internecto.net>wrote:

> Good morning,
>
> I realise I'm probably too late, but if it's trivial then maybe it is
> possible to implement an 'xl reset vmname' function before the final
> release.
>
> Or is this not as trivial as I think it is?
>
> --
> Stay in touch,
> Mark van Dijk.               ,---------------------------------
> ----------------------------'         Tue Sep 04 07:04 UTC 2012
> Today is Boomtime, the 28th day of Bureaucracy in the YOLD 3178
>
> _______________________________________________
> Xen-users mailing list
> Xen-users@lists.xen.org
> http://lists.xen.org/xen-users
>

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

Would reset be different than reboot?<div><a href=3D"http://xenbits.xen.org=
/docs/unstable/man/xl.1.html">http://xenbits.xen.org/docs/unstable/man/xl.1=
.html</a><br><br><div class=3D"gmail_quote">On Tue, Sep 4, 2012 at 3:06 AM,=
 Mark van Dijk <span dir=3D"ltr">&lt;<a href=3D"mailto:lists+xen@internecto=
.net" target=3D"_blank">lists+xen@internecto.net</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">Good morning,<br>
<br>
I realise I&#39;m probably too late, but if it&#39;s trivial then maybe it =
is<br>
possible to implement an &#39;xl reset vmname&#39; function before the fina=
l<br>
release.<br>
<br>
Or is this not as trivial as I think it is?<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
--<br>
Stay in touch,<br>
Mark van Dijk. =A0 =A0 =A0 =A0 =A0 =A0 =A0 ,-------------------------------=
--<br>
----------------------------&#39; =A0 =A0 =A0 =A0 Tue Sep 04 07:04 UTC 2012=
<br>
Today is Boomtime, the 28th day of Bureaucracy in the YOLD 3178<br>
</font></span><div class=3D"HOEnZb"><div class=3D"h5"><br>
_______________________________________________<br>
Xen-users mailing list<br>
<a href=3D"mailto:Xen-users@lists.xen.org">Xen-users@lists.xen.org</a><br>
<a href=3D"http://lists.xen.org/xen-users" target=3D"_blank">http://lists.x=
en.org/xen-users</a><br>
</div></div></blockquote></div><br></div>

--bcaec54b4ac0f1cb1704c8db490b--


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

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

--===============3886292734653545403==--


From xen-devel-bounces@lists.xen.org Tue Sep 04 07:45:58 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Sep 2012 07:45: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 1T8npN-00035D-6d; Tue, 04 Sep 2012 07:45:41 +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 1T8npM-000350-85
	for xen-devel@lists.xen.org; Tue, 04 Sep 2012 07:45:40 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1346744734!8641146!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM4MjY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8121 invoked from network); 4 Sep 2012 07:45:34 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-3.tower-27.messagelabs.com with SMTP;
	4 Sep 2012 07:45:34 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 04 Sep 2012 08:45:33 +0100
Message-Id: <5045CDF302000078000985FB@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 04 Sep 2012 08:46:27 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Sander Eikelenboom" <linux@eikelenboom.it>
References: <7914B38A4445B34AA16EB9F1352942F1012F0F6F4B98@SJCPMAILBOX01.citrite.net>
	<CC681CDD.3D966%keir.xen@gmail.com>
	<40501859.20120902104331@eikelenboom.it>
	<5044849002000078000982EA@nat28.tlf.novell.com>
	<4610648186.20120904090841@eikelenboom.it>
In-Reply-To: <4610648186.20120904090841@eikelenboom.it>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "wei.wang2@amd.com" <wei.wang2@amd.com>, Keir Fraser <keir.xen@gmail.com>,
	Santosh Jodh <Santosh.Jodh@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Using debug-key 'o:  Dump IOMMU p2m table,
 locks up machine
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.09.12 at 09:08, Sander Eikelenboom <linux@eikelenboom.it> wrote:
>> This one
> 
>>>(XEN) [2012-09-02 00:55:02] traps.c:3156: GPF (0060): ffff82c48015c9ee -> 
> ffff82c480224b13
> 
>> also worries me. While Xen gracefully recovers from it, these
>> messages still generally indicate a problem somewhere. Could
>> you resolve the addresses to file:line tuples? And, assuming
>> this happens in the context of doing something on behalf of
>> the guest in the context of a guest vCPU, could you also
>> check what guest side action triggers this (e.g. by adding a
>> call to show_execution_state() alongside the printing of the
>> message)?
> 
> Hope i have done it right:

Yes.

> Gives (complete dmesg attached:
> 
> (XEN) [2012-09-03 21:20:49] AMD-Vi: IO_PAGE_FAULT: domain = 14, device id = 0x0700, fault address = 0xa8ee82c0
> (XEN) [2012-09-03 21:20:49] AMD-Vi: IO_PAGE_FAULT: domain = 14, device id = 0x0700, fault address = 0xa8ee8320
> (XEN) [2012-09-04 03:00:34] traps.c:3156: GPF (0060): ffff82c48015c9ee -> ffff82c480224b73
> (XEN) [2012-09-04 03:00:34] traps.c:3157:  show_execution_state(regs): 
> (XEN) [2012-09-04 03:00:34] ----[ Xen-4.2.0-rc4-pre  x86_64  debug=y  Not tainted ]----
> (XEN) [2012-09-04 03:00:34] CPU:    3
> (XEN) [2012-09-04 03:00:34] RIP:    e008:[<ffff82c48015c9ee>] context_switch+0x394/0xeeb

Now that - in the middle of context switch code - almost certainly
wants to be fixed, but we first need to understand what it is (and
how it gets triggered by the guest). I.e. once again this requires
resolving to file/line - care to do the conversion yourself, or send
(or make available somewhere) the very xen-syms?

Jan


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

From xen-devel-bounces@lists.xen.org Tue Sep 04 07:45:58 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Sep 2012 07:45: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 1T8npN-00035D-6d; Tue, 04 Sep 2012 07:45:41 +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 1T8npM-000350-85
	for xen-devel@lists.xen.org; Tue, 04 Sep 2012 07:45:40 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1346744734!8641146!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM4MjY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8121 invoked from network); 4 Sep 2012 07:45:34 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-3.tower-27.messagelabs.com with SMTP;
	4 Sep 2012 07:45:34 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 04 Sep 2012 08:45:33 +0100
Message-Id: <5045CDF302000078000985FB@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 04 Sep 2012 08:46:27 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Sander Eikelenboom" <linux@eikelenboom.it>
References: <7914B38A4445B34AA16EB9F1352942F1012F0F6F4B98@SJCPMAILBOX01.citrite.net>
	<CC681CDD.3D966%keir.xen@gmail.com>
	<40501859.20120902104331@eikelenboom.it>
	<5044849002000078000982EA@nat28.tlf.novell.com>
	<4610648186.20120904090841@eikelenboom.it>
In-Reply-To: <4610648186.20120904090841@eikelenboom.it>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "wei.wang2@amd.com" <wei.wang2@amd.com>, Keir Fraser <keir.xen@gmail.com>,
	Santosh Jodh <Santosh.Jodh@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Using debug-key 'o:  Dump IOMMU p2m table,
 locks up machine
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.09.12 at 09:08, Sander Eikelenboom <linux@eikelenboom.it> wrote:
>> This one
> 
>>>(XEN) [2012-09-02 00:55:02] traps.c:3156: GPF (0060): ffff82c48015c9ee -> 
> ffff82c480224b13
> 
>> also worries me. While Xen gracefully recovers from it, these
>> messages still generally indicate a problem somewhere. Could
>> you resolve the addresses to file:line tuples? And, assuming
>> this happens in the context of doing something on behalf of
>> the guest in the context of a guest vCPU, could you also
>> check what guest side action triggers this (e.g. by adding a
>> call to show_execution_state() alongside the printing of the
>> message)?
> 
> Hope i have done it right:

Yes.

> Gives (complete dmesg attached:
> 
> (XEN) [2012-09-03 21:20:49] AMD-Vi: IO_PAGE_FAULT: domain = 14, device id = 0x0700, fault address = 0xa8ee82c0
> (XEN) [2012-09-03 21:20:49] AMD-Vi: IO_PAGE_FAULT: domain = 14, device id = 0x0700, fault address = 0xa8ee8320
> (XEN) [2012-09-04 03:00:34] traps.c:3156: GPF (0060): ffff82c48015c9ee -> ffff82c480224b73
> (XEN) [2012-09-04 03:00:34] traps.c:3157:  show_execution_state(regs): 
> (XEN) [2012-09-04 03:00:34] ----[ Xen-4.2.0-rc4-pre  x86_64  debug=y  Not tainted ]----
> (XEN) [2012-09-04 03:00:34] CPU:    3
> (XEN) [2012-09-04 03:00:34] RIP:    e008:[<ffff82c48015c9ee>] context_switch+0x394/0xeeb

Now that - in the middle of context switch code - almost certainly
wants to be fixed, but we first need to understand what it is (and
how it gets triggered by the guest). I.e. once again this requires
resolving to file/line - care to do the conversion yourself, or send
(or make available somewhere) the very xen-syms?

Jan


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

From xen-devel-bounces@lists.xen.org Tue Sep 04 07:55:11 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Sep 2012 07: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 1T8nyD-0003HB-8W; Tue, 04 Sep 2012 07:54:49 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1T8nyB-0003H3-AN
	for xen-devel@lists.xen.org; Tue, 04 Sep 2012 07:54:47 +0000
Received: from [85.158.139.83:30162] by server-4.bemta-5.messagelabs.com id
	87/49-23042-6C3B5405; Tue, 04 Sep 2012 07:54:46 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1346745286!24468746!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM4MjY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23284 invoked from network); 4 Sep 2012 07:54:46 -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;
	4 Sep 2012 07:54:46 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 04 Sep 2012 08:54:45 +0100
Message-Id: <5045D0190200007800098608@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 04 Sep 2012 08:55:37 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "George Dunlap" <George.Dunlap@eu.citrix.com>,
	"Keir Fraser" <keir.xen@gmail.com>
References: <5045BD5C02000078000985A7@nat28.tlf.novell.com>
	<CC6B6568.3DAAD%keir.xen@gmail.com>
In-Reply-To: <CC6B6568.3DAAD%keir.xen@gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: wei.wang2@amd.com, Sander Eikelenboom <linux@eikelenboom.it>,
	Santosh Jodh <santosh.jodh@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Using debug-key 'o:  Dump IOMMU p2m table,
 locks up machine
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.09.12 at 08:59, Keir Fraser <keir.xen@gmail.com> wrote:
> On 04/09/2012 07:35, "Jan Beulich" <JBeulich@suse.com> wrote:
> 
>>>>> On 02.09.12 at 09:42, Keir Fraser <keir.xen@gmail.com> wrote:
>>> On 31/08/2012 22:45, "Sander Eikelenboom" <linux@eikelenboom.it> wrote:
>>>> - When using serial console: I get a infinite stream of "gfn:  mfn: " lines,
>>>> mean while on the normal console, S-ATA devices are starting to give errors.
>>> 
>>> In this case the handler must be running in tasklet context. Not sure why
>>> SATA interrupts would be affected as hardirq and softirq work will still be
>>> carried out during execution of the keyhandler (the handler voluntarily
>>> preempts itself for softirq work).
>>> 
>>> Would need more investigation. :)
>> 
>> Isn't that because tasklets (i.e. idle vCPU-s with tasklets active)
>> get preferred in the schedulers? Some compensation might be
>> needed for the penalized vCPU, at least if that one is pinned
>> (not sure whether load balancing would be able to steal the
>> head of the run queue from a remote CPU). Sander - are you
>> by chance pinning Dom0 vCPU-s? And how many of them does
>> your Dom0 have?
> 
> Jan, Yes you could be right, if Sander is pinning CPUs. Anyway, I wasn't
> going to expend too much brain power on this situation. The case of spending
> a few minutes in one key handler is not one I think is particularly sane.

Which imo would call for reverting the patch. But then again, other
key handlers can easily take pretty long too (particularly on large
systems, albeit it is clear that the one here is particularly bad), and
declaring all of them pretty much useless probably isn't the best
choice (as then we could as well rip them all out).

Bottom line - _I_ think we should try to do something about this.
An apparent option would be to have low priority tasklets (for
just this purpose, as all others we certainly want to take priority),
if that can reasonably be integrated with the schedulers.

Jan


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

From xen-devel-bounces@lists.xen.org Tue Sep 04 07:55:11 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Sep 2012 07: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 1T8nyD-0003HB-8W; Tue, 04 Sep 2012 07:54:49 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1T8nyB-0003H3-AN
	for xen-devel@lists.xen.org; Tue, 04 Sep 2012 07:54:47 +0000
Received: from [85.158.139.83:30162] by server-4.bemta-5.messagelabs.com id
	87/49-23042-6C3B5405; Tue, 04 Sep 2012 07:54:46 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1346745286!24468746!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM4MjY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23284 invoked from network); 4 Sep 2012 07:54:46 -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;
	4 Sep 2012 07:54:46 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 04 Sep 2012 08:54:45 +0100
Message-Id: <5045D0190200007800098608@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 04 Sep 2012 08:55:37 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "George Dunlap" <George.Dunlap@eu.citrix.com>,
	"Keir Fraser" <keir.xen@gmail.com>
References: <5045BD5C02000078000985A7@nat28.tlf.novell.com>
	<CC6B6568.3DAAD%keir.xen@gmail.com>
In-Reply-To: <CC6B6568.3DAAD%keir.xen@gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: wei.wang2@amd.com, Sander Eikelenboom <linux@eikelenboom.it>,
	Santosh Jodh <santosh.jodh@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Using debug-key 'o:  Dump IOMMU p2m table,
 locks up machine
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.09.12 at 08:59, Keir Fraser <keir.xen@gmail.com> wrote:
> On 04/09/2012 07:35, "Jan Beulich" <JBeulich@suse.com> wrote:
> 
>>>>> On 02.09.12 at 09:42, Keir Fraser <keir.xen@gmail.com> wrote:
>>> On 31/08/2012 22:45, "Sander Eikelenboom" <linux@eikelenboom.it> wrote:
>>>> - When using serial console: I get a infinite stream of "gfn:  mfn: " lines,
>>>> mean while on the normal console, S-ATA devices are starting to give errors.
>>> 
>>> In this case the handler must be running in tasklet context. Not sure why
>>> SATA interrupts would be affected as hardirq and softirq work will still be
>>> carried out during execution of the keyhandler (the handler voluntarily
>>> preempts itself for softirq work).
>>> 
>>> Would need more investigation. :)
>> 
>> Isn't that because tasklets (i.e. idle vCPU-s with tasklets active)
>> get preferred in the schedulers? Some compensation might be
>> needed for the penalized vCPU, at least if that one is pinned
>> (not sure whether load balancing would be able to steal the
>> head of the run queue from a remote CPU). Sander - are you
>> by chance pinning Dom0 vCPU-s? And how many of them does
>> your Dom0 have?
> 
> Jan, Yes you could be right, if Sander is pinning CPUs. Anyway, I wasn't
> going to expend too much brain power on this situation. The case of spending
> a few minutes in one key handler is not one I think is particularly sane.

Which imo would call for reverting the patch. But then again, other
key handlers can easily take pretty long too (particularly on large
systems, albeit it is clear that the one here is particularly bad), and
declaring all of them pretty much useless probably isn't the best
choice (as then we could as well rip them all out).

Bottom line - _I_ think we should try to do something about this.
An apparent option would be to have low priority tasklets (for
just this purpose, as all others we certainly want to take priority),
if that can reasonably be integrated with the schedulers.

Jan


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

From xen-devel-bounces@lists.xen.org Tue Sep 04 07:59:58 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Sep 2012 07: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 1T8o2u-0003PH-Uw; Tue, 04 Sep 2012 07:59:40 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jmarcet@gmail.com>) id 1T8o2t-0003PA-QO
	for xen-devel@lists.xen.org; Tue, 04 Sep 2012 07:59:40 +0000
Received: from [85.158.143.35:47302] by server-2.bemta-4.messagelabs.com id
	67/11-21239-BE4B5405; Tue, 04 Sep 2012 07:59:39 +0000
X-Env-Sender: jmarcet@gmail.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1346745576!14010572!1
X-Originating-IP: [209.85.214.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	ML_RADAR_SPEW_LINKS_8,RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3090 invoked from network); 4 Sep 2012 07:59:38 -0000
Received: from mail-ob0-f173.google.com (HELO mail-ob0-f173.google.com)
	(209.85.214.173)
	by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Sep 2012 07:59:38 -0000
Received: by obbta14 with SMTP id ta14so13720754obb.32
	for <xen-devel@lists.xen.org>; Tue, 04 Sep 2012 00:59: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;
	bh=yJfNvXtPVE8uxO/hkJqmKnNLWhEIM8s3SCDbYTDlB8w=;
	b=SRCzj+rFRnu3X7D/vRAkmKFU53It0GG0JetsIs1nVqHjQ7kP4GVzN0C0+Yi65v6x0o
	ufQLsk/OTBzuzfAGoosRMg8d0KbOyHUTsB5uVWQayR+qd/781XpJZA2x2s6ysHq2y60j
	WHs7mN8fbQvPtHVnrynAFMqOIbf8cZAehY7Wg8F8p2tZqgkU/+Zp5hKbt2/aTxE6J3uK
	UaqyPCM+6BmooMTEZ91FRAgtHNv84rdyk1eT4uMySrVP0h67fRqMtb09iRSLwlhTmCTX
	T0Wjx30rUx+L450mrjemZr4FNWIkHLWeZEPUefXkJzEbQdBbwHbMi3y46GGEhZzaVzAU
	zTNw==
Received: by 10.182.119.72 with SMTP id ks8mr15698074obb.10.1346745576671;
	Tue, 04 Sep 2012 00:59:36 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.60.12.164 with HTTP; Tue, 4 Sep 2012 00:59:16 -0700 (PDT)
In-Reply-To: <504478B40200007800098286@nat28.tlf.novell.com>
References: <CAAnFQG8z_ja1Wj2hX+0ZRsz5eLWr+U+7PoSiF9NePsSh2jbX4g@mail.gmail.com>
	<5040B7A40200007800097CEE@nat28.tlf.novell.com>
	<CAAnFQG_vvHQL=NbY1SnMWCcTr73_8RYtNLfc00fqEsz57cd7Rg@mail.gmail.com>
	<504478B40200007800098286@nat28.tlf.novell.com>
From: Javier Marcet <jmarcet@gmail.com>
Date: Tue, 4 Sep 2012 09:59:16 +0200
Message-ID: <CAAnFQG_7JW9Zb91RteXrRGuFL-aNrDGdwz6aQ4LUq9bNKQ4KYA@mail.gmail.com>
To: Jan Beulich <JBeulich@suse.com>
Cc: Xen Devel Mailing list <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.2.0-rc4 bugs with GigaByte H77M-D3H + Core i7
	3770
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Sep 3, 2012 at 9:30 AM, Jan Beulich <JBeulich@suse.com> wrote:

Hi Jan,

>>> > [    0.358278] DMAR:[DMA Read] Request device [00:02.0] fault addr
>>> > 9fac7000
>>> > [    0.358278] DMAR:[fault reason 06] PTE Read access is not set
>>> > [    0.358286] DRHD: handling fault status reg 2
>>> > [    0.358288] DMAR:[DMA Read] Request device [00:02.0] fault addr
>>> > 9fac7000
>>> > [    0.358288] DMAR:[fault reason 06] PTE Read access is not set
>>> > [    0.358291] DMAR:[DMA Read] Request device [00:02.0] fault addr
>>> > 9fac7000
>>> > [    0.358291] DMAR:[fault reason 06] PTE Read access is not set
>>> > [    0.358307] DRHD: handling fault status reg 3
>>> >
>>> > Furthermore, later on, just after enabling the IOMMU, I get this:
>>> >
>>> > [    0.328564] DMAR: No ATSR found
>>> > [    0.328580] IOMMU 1 0xfed91000: using Queued invalidation
>>> > [    0.328582] IOMMU: Setting RMRR:
>>> > [    0.328589] IOMMU: Setting identity map for device 0000:00:1d.0
>>> > [0x9de36000 - 0x9de52fff]
>>> > [    0.328606] IOMMU: Setting identity map for device 0000:00:1a.0
>>> > [0x9de36000 - 0x9de52fff]
>>> > [    0.328617] IOMMU: Setting identity map for device 0000:00:14.0
>>> > [0x9de36000 - 0x9de52fff]
>>> > [    0.328625] IOMMU: Prepare 0-16MiB unity mapping for LPC
>>> > [    0.328630] IOMMU: Setting identity map for device 0000:00:1f.0
>>> > [0x0 - 0xffffff]
>>>
>>> All of these messages shouldn't appear when running under Xen,
>>> as it's the hypervisor, not the kernel to take care of the IOMMU(s).
>>> The logs you had pointers to confirm this - are you sure the above
>>> was seen when running under Xen?
>>
>> I'm sorry I didn't make myself clearer. That dmesg output is when booting
>> WITHOUT xen, that is, linux directly over the bare hardware. Under xen
>> those errors dissapear.
>>
>> The big issue I'm having running xen is that I can't use it since xen can't
>> get the cpu capabilities.
>
> What "cpu capabilities"? I just looked at your original mail again,
> and I cannot see what failure you're referring to (in fact, I'm not
> able to spot any failure in that log at all). And of course you didn't
> even attach a hypervisor log. What am I missing?

These are all the xen and virt-manager logs:

http://dl.dropbox.com/u/12579112/hypervisor.log
http://dl.dropbox.com/u/12579112/qemu-dm-Windows7.log
http://dl.dropbox.com/u/12579112/virt-manager.log
http://dl.dropbox.com/u/12579112/xen-hotplug.log
http://dl.dropbox.com/u/12579112/xend.log
http://dl.dropbox.com/u/12579112/xend-debug.log
http://dl.dropbox.com/u/12579112/xenstored-trace.log.gz

In the virt-manager logs you can see an instance of kvm and an instance of xen.
See the difference in the cpu capabilities detected.

As far as the hypervisor goes, the only error logged is:

(XEN) sh error: sh_remove_all_mappings(): can't find all mappings of
mfn xxxxxx: c=c000000000000002 t=7400000000000001

If I can provide any other useful info please ask.


-- 
Javier Marcet <jmarcet@gmail.com>

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

From xen-devel-bounces@lists.xen.org Tue Sep 04 07:59:58 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Sep 2012 07: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 1T8o2u-0003PH-Uw; Tue, 04 Sep 2012 07:59:40 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jmarcet@gmail.com>) id 1T8o2t-0003PA-QO
	for xen-devel@lists.xen.org; Tue, 04 Sep 2012 07:59:40 +0000
Received: from [85.158.143.35:47302] by server-2.bemta-4.messagelabs.com id
	67/11-21239-BE4B5405; Tue, 04 Sep 2012 07:59:39 +0000
X-Env-Sender: jmarcet@gmail.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1346745576!14010572!1
X-Originating-IP: [209.85.214.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	ML_RADAR_SPEW_LINKS_8,RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3090 invoked from network); 4 Sep 2012 07:59:38 -0000
Received: from mail-ob0-f173.google.com (HELO mail-ob0-f173.google.com)
	(209.85.214.173)
	by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Sep 2012 07:59:38 -0000
Received: by obbta14 with SMTP id ta14so13720754obb.32
	for <xen-devel@lists.xen.org>; Tue, 04 Sep 2012 00:59: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;
	bh=yJfNvXtPVE8uxO/hkJqmKnNLWhEIM8s3SCDbYTDlB8w=;
	b=SRCzj+rFRnu3X7D/vRAkmKFU53It0GG0JetsIs1nVqHjQ7kP4GVzN0C0+Yi65v6x0o
	ufQLsk/OTBzuzfAGoosRMg8d0KbOyHUTsB5uVWQayR+qd/781XpJZA2x2s6ysHq2y60j
	WHs7mN8fbQvPtHVnrynAFMqOIbf8cZAehY7Wg8F8p2tZqgkU/+Zp5hKbt2/aTxE6J3uK
	UaqyPCM+6BmooMTEZ91FRAgtHNv84rdyk1eT4uMySrVP0h67fRqMtb09iRSLwlhTmCTX
	T0Wjx30rUx+L450mrjemZr4FNWIkHLWeZEPUefXkJzEbQdBbwHbMi3y46GGEhZzaVzAU
	zTNw==
Received: by 10.182.119.72 with SMTP id ks8mr15698074obb.10.1346745576671;
	Tue, 04 Sep 2012 00:59:36 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.60.12.164 with HTTP; Tue, 4 Sep 2012 00:59:16 -0700 (PDT)
In-Reply-To: <504478B40200007800098286@nat28.tlf.novell.com>
References: <CAAnFQG8z_ja1Wj2hX+0ZRsz5eLWr+U+7PoSiF9NePsSh2jbX4g@mail.gmail.com>
	<5040B7A40200007800097CEE@nat28.tlf.novell.com>
	<CAAnFQG_vvHQL=NbY1SnMWCcTr73_8RYtNLfc00fqEsz57cd7Rg@mail.gmail.com>
	<504478B40200007800098286@nat28.tlf.novell.com>
From: Javier Marcet <jmarcet@gmail.com>
Date: Tue, 4 Sep 2012 09:59:16 +0200
Message-ID: <CAAnFQG_7JW9Zb91RteXrRGuFL-aNrDGdwz6aQ4LUq9bNKQ4KYA@mail.gmail.com>
To: Jan Beulich <JBeulich@suse.com>
Cc: Xen Devel Mailing list <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.2.0-rc4 bugs with GigaByte H77M-D3H + Core i7
	3770
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Sep 3, 2012 at 9:30 AM, Jan Beulich <JBeulich@suse.com> wrote:

Hi Jan,

>>> > [    0.358278] DMAR:[DMA Read] Request device [00:02.0] fault addr
>>> > 9fac7000
>>> > [    0.358278] DMAR:[fault reason 06] PTE Read access is not set
>>> > [    0.358286] DRHD: handling fault status reg 2
>>> > [    0.358288] DMAR:[DMA Read] Request device [00:02.0] fault addr
>>> > 9fac7000
>>> > [    0.358288] DMAR:[fault reason 06] PTE Read access is not set
>>> > [    0.358291] DMAR:[DMA Read] Request device [00:02.0] fault addr
>>> > 9fac7000
>>> > [    0.358291] DMAR:[fault reason 06] PTE Read access is not set
>>> > [    0.358307] DRHD: handling fault status reg 3
>>> >
>>> > Furthermore, later on, just after enabling the IOMMU, I get this:
>>> >
>>> > [    0.328564] DMAR: No ATSR found
>>> > [    0.328580] IOMMU 1 0xfed91000: using Queued invalidation
>>> > [    0.328582] IOMMU: Setting RMRR:
>>> > [    0.328589] IOMMU: Setting identity map for device 0000:00:1d.0
>>> > [0x9de36000 - 0x9de52fff]
>>> > [    0.328606] IOMMU: Setting identity map for device 0000:00:1a.0
>>> > [0x9de36000 - 0x9de52fff]
>>> > [    0.328617] IOMMU: Setting identity map for device 0000:00:14.0
>>> > [0x9de36000 - 0x9de52fff]
>>> > [    0.328625] IOMMU: Prepare 0-16MiB unity mapping for LPC
>>> > [    0.328630] IOMMU: Setting identity map for device 0000:00:1f.0
>>> > [0x0 - 0xffffff]
>>>
>>> All of these messages shouldn't appear when running under Xen,
>>> as it's the hypervisor, not the kernel to take care of the IOMMU(s).
>>> The logs you had pointers to confirm this - are you sure the above
>>> was seen when running under Xen?
>>
>> I'm sorry I didn't make myself clearer. That dmesg output is when booting
>> WITHOUT xen, that is, linux directly over the bare hardware. Under xen
>> those errors dissapear.
>>
>> The big issue I'm having running xen is that I can't use it since xen can't
>> get the cpu capabilities.
>
> What "cpu capabilities"? I just looked at your original mail again,
> and I cannot see what failure you're referring to (in fact, I'm not
> able to spot any failure in that log at all). And of course you didn't
> even attach a hypervisor log. What am I missing?

These are all the xen and virt-manager logs:

http://dl.dropbox.com/u/12579112/hypervisor.log
http://dl.dropbox.com/u/12579112/qemu-dm-Windows7.log
http://dl.dropbox.com/u/12579112/virt-manager.log
http://dl.dropbox.com/u/12579112/xen-hotplug.log
http://dl.dropbox.com/u/12579112/xend.log
http://dl.dropbox.com/u/12579112/xend-debug.log
http://dl.dropbox.com/u/12579112/xenstored-trace.log.gz

In the virt-manager logs you can see an instance of kvm and an instance of xen.
See the difference in the cpu capabilities detected.

As far as the hypervisor goes, the only error logged is:

(XEN) sh error: sh_remove_all_mappings(): can't find all mappings of
mfn xxxxxx: c=c000000000000002 t=7400000000000001

If I can provide any other useful info please ask.


-- 
Javier Marcet <jmarcet@gmail.com>

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

From xen-devel-bounces@lists.xen.org Tue Sep 04 08:08:55 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Sep 2012 08:08:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T8oBU-00042X-4B; Tue, 04 Sep 2012 08:08: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 1T8oBS-00042R-IY
	for xen-devel@lists.xen.org; Tue, 04 Sep 2012 08:08:30 +0000
Received: from [85.158.139.83:33511] by server-12.bemta-5.messagelabs.com id
	86/21-18300-DF6B5405; Tue, 04 Sep 2012 08:08:29 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1346746094!17145869!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM4MjY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12505 invoked from network); 4 Sep 2012 08:08:14 -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;
	4 Sep 2012 08:08:14 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 04 Sep 2012 09:08:14 +0100
Message-Id: <5045D3430200007800098622@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 04 Sep 2012 09:09:07 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Javier Marcet" <jmarcet@gmail.com>
References: <CAAnFQG8z_ja1Wj2hX+0ZRsz5eLWr+U+7PoSiF9NePsSh2jbX4g@mail.gmail.com>
	<5040B7A40200007800097CEE@nat28.tlf.novell.com>
	<CAAnFQG_vvHQL=NbY1SnMWCcTr73_8RYtNLfc00fqEsz57cd7Rg@mail.gmail.com>
	<504478B40200007800098286@nat28.tlf.novell.com>
	<CAAnFQG_7JW9Zb91RteXrRGuFL-aNrDGdwz6aQ4LUq9bNKQ4KYA@mail.gmail.com>
In-Reply-To: <CAAnFQG_7JW9Zb91RteXrRGuFL-aNrDGdwz6aQ4LUq9bNKQ4KYA@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Xen Devel Mailing list <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.2.0-rc4 bugs with GigaByte H77M-D3H + Core i7
 3770
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.09.12 at 09:59, Javier Marcet <jmarcet@gmail.com> wrote:
>>> The big issue I'm having running xen is that I can't use it since xen can't
>>> get the cpu capabilities.
>>
>> What "cpu capabilities"? I just looked at your original mail again,
>> and I cannot see what failure you're referring to (in fact, I'm not
>> able to spot any failure in that log at all). And of course you didn't
>> even attach a hypervisor log. What am I missing?
> 
> These are all the xen and virt-manager logs:
> 
> http://dl.dropbox.com/u/12579112/hypervisor.log 
> http://dl.dropbox.com/u/12579112/qemu-dm-Windows7.log 
> http://dl.dropbox.com/u/12579112/virt-manager.log 
> http://dl.dropbox.com/u/12579112/xen-hotplug.log 
> http://dl.dropbox.com/u/12579112/xend.log 
> http://dl.dropbox.com/u/12579112/xend-debug.log 
> http://dl.dropbox.com/u/12579112/xenstored-trace.log.gz 
> 
> In the virt-manager logs you can see an instance of kvm and an instance of 
> xen.
> See the difference in the cpu capabilities detected.

Sorry, no, I can't. I don't see any trace of KVM in there. Also I
fail to see how this relates to the wording of the subject of
this thread.

> As far as the hypervisor goes, the only error logged is:
> 
> (XEN) sh error: sh_remove_all_mappings(): can't find all mappings of
> mfn xxxxxx: c=c000000000000002 t=7400000000000001

That doesn't look good, but I can't tell you much about it. I
wouldn't expect you to use shadow mode anyway on a Core-i7 -
are you intentionally turning off HAP for your guests?

Or is all of this thread really about virt-manager shortcomings
rather than problems in Xen (in which case you likely picked the
wrong mailing list)?

Jan


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

From xen-devel-bounces@lists.xen.org Tue Sep 04 08:08:55 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Sep 2012 08:08:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T8oBU-00042X-4B; Tue, 04 Sep 2012 08:08: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 1T8oBS-00042R-IY
	for xen-devel@lists.xen.org; Tue, 04 Sep 2012 08:08:30 +0000
Received: from [85.158.139.83:33511] by server-12.bemta-5.messagelabs.com id
	86/21-18300-DF6B5405; Tue, 04 Sep 2012 08:08:29 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1346746094!17145869!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM4MjY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12505 invoked from network); 4 Sep 2012 08:08:14 -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;
	4 Sep 2012 08:08:14 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 04 Sep 2012 09:08:14 +0100
Message-Id: <5045D3430200007800098622@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 04 Sep 2012 09:09:07 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Javier Marcet" <jmarcet@gmail.com>
References: <CAAnFQG8z_ja1Wj2hX+0ZRsz5eLWr+U+7PoSiF9NePsSh2jbX4g@mail.gmail.com>
	<5040B7A40200007800097CEE@nat28.tlf.novell.com>
	<CAAnFQG_vvHQL=NbY1SnMWCcTr73_8RYtNLfc00fqEsz57cd7Rg@mail.gmail.com>
	<504478B40200007800098286@nat28.tlf.novell.com>
	<CAAnFQG_7JW9Zb91RteXrRGuFL-aNrDGdwz6aQ4LUq9bNKQ4KYA@mail.gmail.com>
In-Reply-To: <CAAnFQG_7JW9Zb91RteXrRGuFL-aNrDGdwz6aQ4LUq9bNKQ4KYA@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Xen Devel Mailing list <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.2.0-rc4 bugs with GigaByte H77M-D3H + Core i7
 3770
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.09.12 at 09:59, Javier Marcet <jmarcet@gmail.com> wrote:
>>> The big issue I'm having running xen is that I can't use it since xen can't
>>> get the cpu capabilities.
>>
>> What "cpu capabilities"? I just looked at your original mail again,
>> and I cannot see what failure you're referring to (in fact, I'm not
>> able to spot any failure in that log at all). And of course you didn't
>> even attach a hypervisor log. What am I missing?
> 
> These are all the xen and virt-manager logs:
> 
> http://dl.dropbox.com/u/12579112/hypervisor.log 
> http://dl.dropbox.com/u/12579112/qemu-dm-Windows7.log 
> http://dl.dropbox.com/u/12579112/virt-manager.log 
> http://dl.dropbox.com/u/12579112/xen-hotplug.log 
> http://dl.dropbox.com/u/12579112/xend.log 
> http://dl.dropbox.com/u/12579112/xend-debug.log 
> http://dl.dropbox.com/u/12579112/xenstored-trace.log.gz 
> 
> In the virt-manager logs you can see an instance of kvm and an instance of 
> xen.
> See the difference in the cpu capabilities detected.

Sorry, no, I can't. I don't see any trace of KVM in there. Also I
fail to see how this relates to the wording of the subject of
this thread.

> As far as the hypervisor goes, the only error logged is:
> 
> (XEN) sh error: sh_remove_all_mappings(): can't find all mappings of
> mfn xxxxxx: c=c000000000000002 t=7400000000000001

That doesn't look good, but I can't tell you much about it. I
wouldn't expect you to use shadow mode anyway on a Core-i7 -
are you intentionally turning off HAP for your guests?

Or is all of this thread really about virt-manager shortcomings
rather than problems in Xen (in which case you likely picked the
wrong mailing list)?

Jan


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

From xen-devel-bounces@lists.xen.org Tue Sep 04 08:08:55 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Sep 2012 08:08:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T8oBa-00042x-GL; Tue, 04 Sep 2012 08:08:38 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1T8oBZ-00042W-6W
	for xen-devel@lists.xen.org; Tue, 04 Sep 2012 08:08:37 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1346745885!4296471!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-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7946 invoked from network); 4 Sep 2012 08:04:45 -0000
Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com)
	(74.125.83.45)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Sep 2012 08:04:45 -0000
Received: by eeke53 with SMTP id e53so2488847eek.32
	for <xen-devel@lists.xen.org>; Tue, 04 Sep 2012 01:04:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=axV4W47eX7/ByDKtExRW86JYEt3N714aqk8zGKPU5YE=;
	b=hV1HpUXZ0w9H7ogVO2qiltSjI33cUcjVDCvuQ1t1Fkxqcx6USnKlJixzXGPfDMgyhp
	3/8x6pgwLx3bMsd/6W4Kar55Zp00IizqApex8dz9icEXi75jw+w/wHnrkv3ObOzuokoR
	PIEmZySAmPi8+zzNsdt0NvScfuJpADWEDL841LBo0+R9/SDoPkU7vjPQc4xIVF58T3LN
	ypXnBm+fjkD52r3JoZozsurYr0jVtSuJMgALbRb517ZXXpTeth41xkLzCVUerrHVCG+g
	4yEwUQiHLfxgD+SZtM2hH1N0tE8ArdqG/mgPGzHthLVcx8OH7BYoHNbm45mj8qLU3evc
	ZBpA==
Received: by 10.14.213.137 with SMTP id a9mr24912372eep.38.1346745885046;
	Tue, 04 Sep 2012 01:04:45 -0700 (PDT)
Received: from [192.168.1.69] (host86-184-74-117.range86-184.btcentralplus.com.
	[86.184.74.117])
	by mx.google.com with ESMTPS id k49sm43147200een.4.2012.09.04.01.04.43
	(version=SSLv3 cipher=OTHER); Tue, 04 Sep 2012 01:04:44 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Tue, 04 Sep 2012 09:04:39 +0100
From: Keir Fraser <keir.xen@gmail.com>
To: Jan Beulich <JBeulich@suse.com>,
	George Dunlap <George.Dunlap@eu.citrix.com>
Message-ID: <CC6B74A7.3DAC1%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] Using debug-key 'o:  Dump IOMMU p2m table, locks up
	machine
Thread-Index: Ac2Kc+5zmAQer1s5wU6OpsJ21FMcnA==
In-Reply-To: <5045D0190200007800098608@nat28.tlf.novell.com>
Mime-version: 1.0
Cc: wei.wang2@amd.com, Sander Eikelenboom <linux@eikelenboom.it>,
	Santosh Jodh <santosh.jodh@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Using debug-key 'o:  Dump IOMMU p2m table,
 locks up machine
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/09/2012 08:55, "Jan Beulich" <JBeulich@suse.com> wrote:

>> Jan, Yes you could be right, if Sander is pinning CPUs. Anyway, I wasn't
>> going to expend too much brain power on this situation. The case of spending
>> a few minutes in one key handler is not one I think is particularly sane.
> 
> Which imo would call for reverting the patch. But then again, other
> key handlers can easily take pretty long too (particularly on large
> systems, albeit it is clear that the one here is particularly bad), and
> declaring all of them pretty much useless probably isn't the best
> choice (as then we could as well rip them all out).
> 
> Bottom line - _I_ think we should try to do something about this.
> An apparent option would be to have low priority tasklets (for
> just this purpose, as all others we certainly want to take priority),
> if that can reasonably be integrated with the schedulers.

Do you expect to be able to use the log-running key handlers and still need
a running system afterwards (rather than using them as a final
dump-everything when the system has already gone bad)? Then I suppose you
would need something like this, with voluntary preemption in the key
handlers. You then need to be able to recommence the keyhandlers where they
left off, retaking locks, finding their place in lists, trees, etc, even
when state of the system has significantly changed between preemption and
resumption. Well, I'm sure it can be done, but can anyone be bothered.

 -- Keir



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

From xen-devel-bounces@lists.xen.org Tue Sep 04 08:08:55 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Sep 2012 08:08:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T8oBa-00042x-GL; Tue, 04 Sep 2012 08:08:38 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1T8oBZ-00042W-6W
	for xen-devel@lists.xen.org; Tue, 04 Sep 2012 08:08:37 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1346745885!4296471!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-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7946 invoked from network); 4 Sep 2012 08:04:45 -0000
Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com)
	(74.125.83.45)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Sep 2012 08:04:45 -0000
Received: by eeke53 with SMTP id e53so2488847eek.32
	for <xen-devel@lists.xen.org>; Tue, 04 Sep 2012 01:04:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=axV4W47eX7/ByDKtExRW86JYEt3N714aqk8zGKPU5YE=;
	b=hV1HpUXZ0w9H7ogVO2qiltSjI33cUcjVDCvuQ1t1Fkxqcx6USnKlJixzXGPfDMgyhp
	3/8x6pgwLx3bMsd/6W4Kar55Zp00IizqApex8dz9icEXi75jw+w/wHnrkv3ObOzuokoR
	PIEmZySAmPi8+zzNsdt0NvScfuJpADWEDL841LBo0+R9/SDoPkU7vjPQc4xIVF58T3LN
	ypXnBm+fjkD52r3JoZozsurYr0jVtSuJMgALbRb517ZXXpTeth41xkLzCVUerrHVCG+g
	4yEwUQiHLfxgD+SZtM2hH1N0tE8ArdqG/mgPGzHthLVcx8OH7BYoHNbm45mj8qLU3evc
	ZBpA==
Received: by 10.14.213.137 with SMTP id a9mr24912372eep.38.1346745885046;
	Tue, 04 Sep 2012 01:04:45 -0700 (PDT)
Received: from [192.168.1.69] (host86-184-74-117.range86-184.btcentralplus.com.
	[86.184.74.117])
	by mx.google.com with ESMTPS id k49sm43147200een.4.2012.09.04.01.04.43
	(version=SSLv3 cipher=OTHER); Tue, 04 Sep 2012 01:04:44 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Tue, 04 Sep 2012 09:04:39 +0100
From: Keir Fraser <keir.xen@gmail.com>
To: Jan Beulich <JBeulich@suse.com>,
	George Dunlap <George.Dunlap@eu.citrix.com>
Message-ID: <CC6B74A7.3DAC1%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] Using debug-key 'o:  Dump IOMMU p2m table, locks up
	machine
Thread-Index: Ac2Kc+5zmAQer1s5wU6OpsJ21FMcnA==
In-Reply-To: <5045D0190200007800098608@nat28.tlf.novell.com>
Mime-version: 1.0
Cc: wei.wang2@amd.com, Sander Eikelenboom <linux@eikelenboom.it>,
	Santosh Jodh <santosh.jodh@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Using debug-key 'o:  Dump IOMMU p2m table,
 locks up machine
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/09/2012 08:55, "Jan Beulich" <JBeulich@suse.com> wrote:

>> Jan, Yes you could be right, if Sander is pinning CPUs. Anyway, I wasn't
>> going to expend too much brain power on this situation. The case of spending
>> a few minutes in one key handler is not one I think is particularly sane.
> 
> Which imo would call for reverting the patch. But then again, other
> key handlers can easily take pretty long too (particularly on large
> systems, albeit it is clear that the one here is particularly bad), and
> declaring all of them pretty much useless probably isn't the best
> choice (as then we could as well rip them all out).
> 
> Bottom line - _I_ think we should try to do something about this.
> An apparent option would be to have low priority tasklets (for
> just this purpose, as all others we certainly want to take priority),
> if that can reasonably be integrated with the schedulers.

Do you expect to be able to use the log-running key handlers and still need
a running system afterwards (rather than using them as a final
dump-everything when the system has already gone bad)? Then I suppose you
would need something like this, with voluntary preemption in the key
handlers. You then need to be able to recommence the keyhandlers where they
left off, retaking locks, finding their place in lists, trees, etc, even
when state of the system has significantly changed between preemption and
resumption. Well, I'm sure it can be done, but can anyone be bothered.

 -- Keir



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

From xen-devel-bounces@lists.xen.org Tue Sep 04 08:12:09 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Sep 2012 08:12:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T8oEj-0004Gz-9M; Tue, 04 Sep 2012 08:11:53 +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 1T8oEh-0004Gk-LP
	for xen-devel@lists.xen.org; Tue, 04 Sep 2012 08:11:51 +0000
Received: from [85.158.143.99:16483] by server-1.bemta-4.messagelabs.com id
	EC/77-12504-6C7B5405; Tue, 04 Sep 2012 08:11:50 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1346746310!21351303!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-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9946 invoked from network); 4 Sep 2012 08:11:50 -0000
Received: from mail-ey0-f173.google.com (HELO mail-ey0-f173.google.com)
	(209.85.215.173)
	by server-6.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Sep 2012 08:11:50 -0000
Received: by eaac13 with SMTP id c13so1979690eaa.32
	for <xen-devel@lists.xen.org>; Tue, 04 Sep 2012 01:11:50 -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=6HvvyS+mhfR45jJLqt5w+C0iIQxeYgOMyYfg1myQtkI=;
	b=GSzTKUH11gnDDdjxvPQytHOep6K/H8ubiq4AuEachNX8kkV8ZF2+x7WPxfoTCcCb2L
	zA8UblaB3dnKTprlqe1dg+lLYD3LDyNCTbeIEeHkRSCCIHT9Hat2+LzUieCXf/oen59J
	q3LOM4Tcv7yytrxHT/DAXdapKLhrmINmzG61L1SszpQSj3bgR7ZYvxue88cLulhPJTY2
	4TlflHj7I1OVHEpkoY3sSEc2VGWufHz/QiSlEargV63NqimgXUT9RaC0j7UO5AjijBq9
	rlXwKdiufCHMUl/yLIfwEC6yLrKUtQm0RA4HHevbZPBBr9q7j8DpRxs748CEgS/VRm3r
	KQBQ==
Received: by 10.14.184.133 with SMTP id s5mr25108562eem.31.1346746310075;
	Tue, 04 Sep 2012 01:11:50 -0700 (PDT)
Received: from [192.168.1.69] (host86-184-74-117.range86-184.btcentralplus.com.
	[86.184.74.117])
	by mx.google.com with ESMTPS id y1sm43216469eel.0.2012.09.04.01.11.47
	(version=SSLv3 cipher=OTHER); Tue, 04 Sep 2012 01:11:49 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Tue, 04 Sep 2012 09:11:42 +0100
From: Keir Fraser <keir.xen@gmail.com>
To: Jan Beulich <JBeulich@suse.com>,
	George Dunlap <George.Dunlap@eu.citrix.com>
Message-ID: <CC6B764E.3DACF%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] Using debug-key 'o:  Dump IOMMU p2m table, locks up
	machine
Thread-Index: Ac2Kc+5zmAQer1s5wU6OpsJ21FMcnAAAPwgG
In-Reply-To: <CC6B74A7.3DAC1%keir.xen@gmail.com>
Mime-version: 1.0
Cc: wei.wang2@amd.com, Sander Eikelenboom <linux@eikelenboom.it>,
	Santosh Jodh <santosh.jodh@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Using debug-key 'o:  Dump IOMMU p2m table,
 locks up machine
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/09/2012 09:04, "Keir Fraser" <keir.xen@gmail.com> wrote:

> On 04/09/2012 08:55, "Jan Beulich" <JBeulich@suse.com> wrote:
> 
>>> Jan, Yes you could be right, if Sander is pinning CPUs. Anyway, I wasn't
>>> going to expend too much brain power on this situation. The case of spending
>>> a few minutes in one key handler is not one I think is particularly sane.
>> 
>> Which imo would call for reverting the patch. But then again, other
>> key handlers can easily take pretty long too (particularly on large
>> systems, albeit it is clear that the one here is particularly bad), and
>> declaring all of them pretty much useless probably isn't the best
>> choice (as then we could as well rip them all out).
>> 
>> Bottom line - _I_ think we should try to do something about this.
>> An apparent option would be to have low priority tasklets (for
>> just this purpose, as all others we certainly want to take priority),
>> if that can reasonably be integrated with the schedulers.
> 
> Do you expect to be able to use the log-running key handlers and still need
> a running system afterwards (rather than using them as a final
> dump-everything when the system has already gone bad)? Then I suppose you
> would need something like this, with voluntary preemption in the key
> handlers. You then need to be able to recommence the keyhandlers where they
> left off, retaking locks, finding their place in lists, trees, etc, even
> when state of the system has significantly changed between preemption and
> resumption. Well, I'm sure it can be done, but can anyone be bothered.

My pragmatic take would be that: (a) Really long-running handlers that want
to dump every page mapping of every domain are pretty bloody stupid, and yes
we should consider if they are worthwhile at all; (b) moderately
long-running but useful handlers which nonetheless take a long time to dump
to Xen's console, I would consider a sysctl to allow dom0 to request dump
into a supplied memory buffer.

>  -- Keir
> 
> 



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

From xen-devel-bounces@lists.xen.org Tue Sep 04 08:12:09 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Sep 2012 08:12:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T8oEj-0004Gz-9M; Tue, 04 Sep 2012 08:11:53 +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 1T8oEh-0004Gk-LP
	for xen-devel@lists.xen.org; Tue, 04 Sep 2012 08:11:51 +0000
Received: from [85.158.143.99:16483] by server-1.bemta-4.messagelabs.com id
	EC/77-12504-6C7B5405; Tue, 04 Sep 2012 08:11:50 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1346746310!21351303!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-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9946 invoked from network); 4 Sep 2012 08:11:50 -0000
Received: from mail-ey0-f173.google.com (HELO mail-ey0-f173.google.com)
	(209.85.215.173)
	by server-6.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Sep 2012 08:11:50 -0000
Received: by eaac13 with SMTP id c13so1979690eaa.32
	for <xen-devel@lists.xen.org>; Tue, 04 Sep 2012 01:11:50 -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=6HvvyS+mhfR45jJLqt5w+C0iIQxeYgOMyYfg1myQtkI=;
	b=GSzTKUH11gnDDdjxvPQytHOep6K/H8ubiq4AuEachNX8kkV8ZF2+x7WPxfoTCcCb2L
	zA8UblaB3dnKTprlqe1dg+lLYD3LDyNCTbeIEeHkRSCCIHT9Hat2+LzUieCXf/oen59J
	q3LOM4Tcv7yytrxHT/DAXdapKLhrmINmzG61L1SszpQSj3bgR7ZYvxue88cLulhPJTY2
	4TlflHj7I1OVHEpkoY3sSEc2VGWufHz/QiSlEargV63NqimgXUT9RaC0j7UO5AjijBq9
	rlXwKdiufCHMUl/yLIfwEC6yLrKUtQm0RA4HHevbZPBBr9q7j8DpRxs748CEgS/VRm3r
	KQBQ==
Received: by 10.14.184.133 with SMTP id s5mr25108562eem.31.1346746310075;
	Tue, 04 Sep 2012 01:11:50 -0700 (PDT)
Received: from [192.168.1.69] (host86-184-74-117.range86-184.btcentralplus.com.
	[86.184.74.117])
	by mx.google.com with ESMTPS id y1sm43216469eel.0.2012.09.04.01.11.47
	(version=SSLv3 cipher=OTHER); Tue, 04 Sep 2012 01:11:49 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Tue, 04 Sep 2012 09:11:42 +0100
From: Keir Fraser <keir.xen@gmail.com>
To: Jan Beulich <JBeulich@suse.com>,
	George Dunlap <George.Dunlap@eu.citrix.com>
Message-ID: <CC6B764E.3DACF%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] Using debug-key 'o:  Dump IOMMU p2m table, locks up
	machine
Thread-Index: Ac2Kc+5zmAQer1s5wU6OpsJ21FMcnAAAPwgG
In-Reply-To: <CC6B74A7.3DAC1%keir.xen@gmail.com>
Mime-version: 1.0
Cc: wei.wang2@amd.com, Sander Eikelenboom <linux@eikelenboom.it>,
	Santosh Jodh <santosh.jodh@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Using debug-key 'o:  Dump IOMMU p2m table,
 locks up machine
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/09/2012 09:04, "Keir Fraser" <keir.xen@gmail.com> wrote:

> On 04/09/2012 08:55, "Jan Beulich" <JBeulich@suse.com> wrote:
> 
>>> Jan, Yes you could be right, if Sander is pinning CPUs. Anyway, I wasn't
>>> going to expend too much brain power on this situation. The case of spending
>>> a few minutes in one key handler is not one I think is particularly sane.
>> 
>> Which imo would call for reverting the patch. But then again, other
>> key handlers can easily take pretty long too (particularly on large
>> systems, albeit it is clear that the one here is particularly bad), and
>> declaring all of them pretty much useless probably isn't the best
>> choice (as then we could as well rip them all out).
>> 
>> Bottom line - _I_ think we should try to do something about this.
>> An apparent option would be to have low priority tasklets (for
>> just this purpose, as all others we certainly want to take priority),
>> if that can reasonably be integrated with the schedulers.
> 
> Do you expect to be able to use the log-running key handlers and still need
> a running system afterwards (rather than using them as a final
> dump-everything when the system has already gone bad)? Then I suppose you
> would need something like this, with voluntary preemption in the key
> handlers. You then need to be able to recommence the keyhandlers where they
> left off, retaking locks, finding their place in lists, trees, etc, even
> when state of the system has significantly changed between preemption and
> resumption. Well, I'm sure it can be done, but can anyone be bothered.

My pragmatic take would be that: (a) Really long-running handlers that want
to dump every page mapping of every domain are pretty bloody stupid, and yes
we should consider if they are worthwhile at all; (b) moderately
long-running but useful handlers which nonetheless take a long time to dump
to Xen's console, I would consider a sysctl to allow dom0 to request dump
into a supplied memory buffer.

>  -- Keir
> 
> 



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

From xen-devel-bounces@lists.xen.org Tue Sep 04 08:13:55 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Sep 2012 08:13:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T8oGP-0004US-ES; Tue, 04 Sep 2012 08:13:37 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <linux@eikelenboom.it>) id 1T8oGN-0004UD-QY
	for xen-devel@lists.xen.org; Tue, 04 Sep 2012 08:13:36 +0000
Received: from [85.158.138.51:60192] by server-10.bemta-3.messagelabs.com id
	A8/9D-10411-E28B5405; Tue, 04 Sep 2012 08:13:34 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-6.tower-174.messagelabs.com!1346746414!20441214!1
X-Originating-IP: [188.40.164.121]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14446 invoked from network); 4 Sep 2012 08:13:34 -0000
Received: from static.121.164.40.188.clients.your-server.de (HELO
	smtp.eikelenboom.it) (188.40.164.121)
	by server-6.tower-174.messagelabs.com with AES256-SHA encrypted SMTP;
	4 Sep 2012 08:13:34 -0000
Received: from 26-69-ftth.onsneteindhoven.nl ([88.159.69.26]:49701
	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 1T8oDH-0002Q8-Il; Tue, 04 Sep 2012 10:10:23 +0200
Date: Tue, 4 Sep 2012 10:13:30 +0200
From: Sander Eikelenboom <linux@eikelenboom.it>
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <4710608674.20120904101330@eikelenboom.it>
To: "Jan Beulich" <JBeulich@suse.com>
In-Reply-To: <5045CDF302000078000985FB@nat28.tlf.novell.com>
References: <7914B38A4445B34AA16EB9F1352942F1012F0F6F4B98@SJCPMAILBOX01.citrite.net>
	<CC681CDD.3D966%keir.xen@gmail.com>
	<40501859.20120902104331@eikelenboom.it>
	<5044849002000078000982EA@nat28.tlf.novell.com>
	<4610648186.20120904090841@eikelenboom.it>
	<5045CDF302000078000985FB@nat28.tlf.novell.com>
MIME-Version: 1.0
Cc: "wei.wang2@amd.com" <wei.wang2@amd.com>, Keir Fraser <keir.xen@gmail.com>,
	Santosh Jodh <Santosh.Jodh@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Using debug-key 'o:  Dump IOMMU p2m table,
	locks up machine
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 Jan,

Tuesday, September 4, 2012, 9:46:27 AM, you wrote:

>>>> On 04.09.12 at 09:08, Sander Eikelenboom <linux@eikelenboom.it> wrote:
>>> This one
>> 
>>>>(XEN) [2012-09-02 00:55:02] traps.c:3156: GPF (0060): ffff82c48015c9ee -> 
>> ffff82c480224b13
>> 
>>> also worries me. While Xen gracefully recovers from it, these
>>> messages still generally indicate a problem somewhere. Could
>>> you resolve the addresses to file:line tuples? And, assuming
>>> this happens in the context of doing something on behalf of
>>> the guest in the context of a guest vCPU, could you also
>>> check what guest side action triggers this (e.g. by adding a
>>> call to show_execution_state() alongside the printing of the
>>> message)?
>> 
>> Hope i have done it right:

> Yes.

>> Gives (complete dmesg attached:
>> 
>> (XEN) [2012-09-03 21:20:49] AMD-Vi: IO_PAGE_FAULT: domain = 14, device id = 0x0700, fault address = 0xa8ee82c0
>> (XEN) [2012-09-03 21:20:49] AMD-Vi: IO_PAGE_FAULT: domain = 14, device id = 0x0700, fault address = 0xa8ee8320
>> (XEN) [2012-09-04 03:00:34] traps.c:3156: GPF (0060): ffff82c48015c9ee -> ffff82c480224b73
>> (XEN) [2012-09-04 03:00:34] traps.c:3157:  show_execution_state(regs): 
>> (XEN) [2012-09-04 03:00:34] ----[ Xen-4.2.0-rc4-pre  x86_64  debug=y  Not tainted ]----
>> (XEN) [2012-09-04 03:00:34] CPU:    3
>> (XEN) [2012-09-04 03:00:34] RIP:    e008:[<ffff82c48015c9ee>] context_switch+0x394/0xeeb

> Now that - in the middle of context switch code - almost certainly
> wants to be fixed, but we first need to understand what it is (and
> how it gets triggered by the guest). I.e. once again this requires
> resolving to file/line - care to do the conversion yourself, or send
> (or make available somewhere) the very xen-syms?

> Jan

Hmm don't know how to get the file/line, only thing i have found is:

serveerstertje:/boot# gdb xen-syms-4.2.0-rc4-pre
GNU gdb (GDB) 7.0.1-debian
Copyright (C) 2009 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /boot/xen-syms-4.2.0-rc4-pre...done.
(gdb) x/i 0xffff82c48015c9ee
0xffff82c48015c9ee <context_switch+916>:        mov    %edx,%gs
(gdb)


How to resolve the RIP could be a nice addition to the http://wiki.xen.org/wiki/Debugging_Xen, so one could easily refer to that on how to do it :-)

--
Sander


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

From xen-devel-bounces@lists.xen.org Tue Sep 04 08:13:55 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Sep 2012 08:13:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T8oGP-0004US-ES; Tue, 04 Sep 2012 08:13:37 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <linux@eikelenboom.it>) id 1T8oGN-0004UD-QY
	for xen-devel@lists.xen.org; Tue, 04 Sep 2012 08:13:36 +0000
Received: from [85.158.138.51:60192] by server-10.bemta-3.messagelabs.com id
	A8/9D-10411-E28B5405; Tue, 04 Sep 2012 08:13:34 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-6.tower-174.messagelabs.com!1346746414!20441214!1
X-Originating-IP: [188.40.164.121]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14446 invoked from network); 4 Sep 2012 08:13:34 -0000
Received: from static.121.164.40.188.clients.your-server.de (HELO
	smtp.eikelenboom.it) (188.40.164.121)
	by server-6.tower-174.messagelabs.com with AES256-SHA encrypted SMTP;
	4 Sep 2012 08:13:34 -0000
Received: from 26-69-ftth.onsneteindhoven.nl ([88.159.69.26]:49701
	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 1T8oDH-0002Q8-Il; Tue, 04 Sep 2012 10:10:23 +0200
Date: Tue, 4 Sep 2012 10:13:30 +0200
From: Sander Eikelenboom <linux@eikelenboom.it>
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <4710608674.20120904101330@eikelenboom.it>
To: "Jan Beulich" <JBeulich@suse.com>
In-Reply-To: <5045CDF302000078000985FB@nat28.tlf.novell.com>
References: <7914B38A4445B34AA16EB9F1352942F1012F0F6F4B98@SJCPMAILBOX01.citrite.net>
	<CC681CDD.3D966%keir.xen@gmail.com>
	<40501859.20120902104331@eikelenboom.it>
	<5044849002000078000982EA@nat28.tlf.novell.com>
	<4610648186.20120904090841@eikelenboom.it>
	<5045CDF302000078000985FB@nat28.tlf.novell.com>
MIME-Version: 1.0
Cc: "wei.wang2@amd.com" <wei.wang2@amd.com>, Keir Fraser <keir.xen@gmail.com>,
	Santosh Jodh <Santosh.Jodh@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Using debug-key 'o:  Dump IOMMU p2m table,
	locks up machine
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 Jan,

Tuesday, September 4, 2012, 9:46:27 AM, you wrote:

>>>> On 04.09.12 at 09:08, Sander Eikelenboom <linux@eikelenboom.it> wrote:
>>> This one
>> 
>>>>(XEN) [2012-09-02 00:55:02] traps.c:3156: GPF (0060): ffff82c48015c9ee -> 
>> ffff82c480224b13
>> 
>>> also worries me. While Xen gracefully recovers from it, these
>>> messages still generally indicate a problem somewhere. Could
>>> you resolve the addresses to file:line tuples? And, assuming
>>> this happens in the context of doing something on behalf of
>>> the guest in the context of a guest vCPU, could you also
>>> check what guest side action triggers this (e.g. by adding a
>>> call to show_execution_state() alongside the printing of the
>>> message)?
>> 
>> Hope i have done it right:

> Yes.

>> Gives (complete dmesg attached:
>> 
>> (XEN) [2012-09-03 21:20:49] AMD-Vi: IO_PAGE_FAULT: domain = 14, device id = 0x0700, fault address = 0xa8ee82c0
>> (XEN) [2012-09-03 21:20:49] AMD-Vi: IO_PAGE_FAULT: domain = 14, device id = 0x0700, fault address = 0xa8ee8320
>> (XEN) [2012-09-04 03:00:34] traps.c:3156: GPF (0060): ffff82c48015c9ee -> ffff82c480224b73
>> (XEN) [2012-09-04 03:00:34] traps.c:3157:  show_execution_state(regs): 
>> (XEN) [2012-09-04 03:00:34] ----[ Xen-4.2.0-rc4-pre  x86_64  debug=y  Not tainted ]----
>> (XEN) [2012-09-04 03:00:34] CPU:    3
>> (XEN) [2012-09-04 03:00:34] RIP:    e008:[<ffff82c48015c9ee>] context_switch+0x394/0xeeb

> Now that - in the middle of context switch code - almost certainly
> wants to be fixed, but we first need to understand what it is (and
> how it gets triggered by the guest). I.e. once again this requires
> resolving to file/line - care to do the conversion yourself, or send
> (or make available somewhere) the very xen-syms?

> Jan

Hmm don't know how to get the file/line, only thing i have found is:

serveerstertje:/boot# gdb xen-syms-4.2.0-rc4-pre
GNU gdb (GDB) 7.0.1-debian
Copyright (C) 2009 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /boot/xen-syms-4.2.0-rc4-pre...done.
(gdb) x/i 0xffff82c48015c9ee
0xffff82c48015c9ee <context_switch+916>:        mov    %edx,%gs
(gdb)


How to resolve the RIP could be a nice addition to the http://wiki.xen.org/wiki/Debugging_Xen, so one could easily refer to that on how to do it :-)

--
Sander


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

From xen-devel-bounces@lists.xen.org Tue Sep 04 08:20:59 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Sep 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 1T8oNK-000538-Un; Tue, 04 Sep 2012 08:20:46 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <linux@eikelenboom.it>) id 1T8oNJ-00052y-Os
	for xen-devel@lists.xen.org; Tue, 04 Sep 2012 08:20:45 +0000
Received: from [85.158.138.51:63317] by server-11.bemta-3.messagelabs.com id
	3E/4C-30250-CD9B5405; Tue, 04 Sep 2012 08:20:44 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-8.tower-174.messagelabs.com!1346746826!28428572!1
X-Originating-IP: [188.40.164.121]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30153 invoked from network); 4 Sep 2012 08:20:26 -0000
Received: from static.121.164.40.188.clients.your-server.de (HELO
	smtp.eikelenboom.it) (188.40.164.121)
	by server-8.tower-174.messagelabs.com with AES256-SHA encrypted SMTP;
	4 Sep 2012 08:20:26 -0000
Received: from 26-69-ftth.onsneteindhoven.nl ([88.159.69.26]:49732
	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 1T8oJw-0002S1-Vp; Tue, 04 Sep 2012 10:17:17 +0200
Date: Tue, 4 Sep 2012 10:20:24 +0200
From: Sander Eikelenboom <linux@eikelenboom.it>
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <1894818567.20120904102024@eikelenboom.it>
To: Keir Fraser <keir.xen@gmail.com>
In-Reply-To: <CC6B764E.3DACF%keir.xen@gmail.com>
References: <CC6B74A7.3DAC1%keir.xen@gmail.com>
	<CC6B764E.3DACF%keir.xen@gmail.com>
MIME-Version: 1.0
Cc: George Dunlap <George.Dunlap@eu.citrix.com>, wei.wang2@amd.com,
	Santosh Jodh <santosh.jodh@citrix.com>, Jan Beulich <JBeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Using debug-key 'o:  Dump IOMMU p2m table,
	locks up machine
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 Keir,

Tuesday, September 4, 2012, 10:11:42 AM, you wrote:

> On 04/09/2012 09:04, "Keir Fraser" <keir.xen@gmail.com> wrote:

>> On 04/09/2012 08:55, "Jan Beulich" <JBeulich@suse.com> wrote:
>> 
>>>> Jan, Yes you could be right, if Sander is pinning CPUs. Anyway, I wasn't
>>>> going to expend too much brain power on this situation. The case of spending
>>>> a few minutes in one key handler is not one I think is particularly sane.
>>> 
>>> Which imo would call for reverting the patch. But then again, other
>>> key handlers can easily take pretty long too (particularly on large
>>> systems, albeit it is clear that the one here is particularly bad), and
>>> declaring all of them pretty much useless probably isn't the best
>>> choice (as then we could as well rip them all out).
>>> 
>>> Bottom line - _I_ think we should try to do something about this.
>>> An apparent option would be to have low priority tasklets (for
>>> just this purpose, as all others we certainly want to take priority),
>>> if that can reasonably be integrated with the schedulers.
>> 
>> Do you expect to be able to use the log-running key handlers and still need
>> a running system afterwards (rather than using them as a final
>> dump-everything when the system has already gone bad)? Then I suppose you
>> would need something like this, with voluntary preemption in the key
>> handlers. You then need to be able to recommence the keyhandlers where they
>> left off, retaking locks, finding their place in lists, trees, etc, even
>> when state of the system has significantly changed between preemption and
>> resumption. Well, I'm sure it can be done, but can anyone be bothered.

> My pragmatic take would be that: (a) Really long-running handlers that want
> to dump every page mapping of every domain are pretty bloody stupid, and yes
> we should consider if they are worthwhile at all; (b) moderately
> long-running but useful handlers which nonetheless take a long time to dump
> to Xen's console, I would consider a sysctl to allow dom0 to request dump
> into a supplied memory buffer.

Is it necessary for this case to let it be a key-handler for which one can't specify parameters to limit the output ?

In this case both hypervisor and kernel are running fine, so a interface via say "xl debug" should be perfectly fine and providing parameters should be possible ?

>>  -- Keir
>> 
>> 



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

From xen-devel-bounces@lists.xen.org Tue Sep 04 08:20:59 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Sep 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 1T8oNK-000538-Un; Tue, 04 Sep 2012 08:20:46 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <linux@eikelenboom.it>) id 1T8oNJ-00052y-Os
	for xen-devel@lists.xen.org; Tue, 04 Sep 2012 08:20:45 +0000
Received: from [85.158.138.51:63317] by server-11.bemta-3.messagelabs.com id
	3E/4C-30250-CD9B5405; Tue, 04 Sep 2012 08:20:44 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-8.tower-174.messagelabs.com!1346746826!28428572!1
X-Originating-IP: [188.40.164.121]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30153 invoked from network); 4 Sep 2012 08:20:26 -0000
Received: from static.121.164.40.188.clients.your-server.de (HELO
	smtp.eikelenboom.it) (188.40.164.121)
	by server-8.tower-174.messagelabs.com with AES256-SHA encrypted SMTP;
	4 Sep 2012 08:20:26 -0000
Received: from 26-69-ftth.onsneteindhoven.nl ([88.159.69.26]:49732
	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 1T8oJw-0002S1-Vp; Tue, 04 Sep 2012 10:17:17 +0200
Date: Tue, 4 Sep 2012 10:20:24 +0200
From: Sander Eikelenboom <linux@eikelenboom.it>
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <1894818567.20120904102024@eikelenboom.it>
To: Keir Fraser <keir.xen@gmail.com>
In-Reply-To: <CC6B764E.3DACF%keir.xen@gmail.com>
References: <CC6B74A7.3DAC1%keir.xen@gmail.com>
	<CC6B764E.3DACF%keir.xen@gmail.com>
MIME-Version: 1.0
Cc: George Dunlap <George.Dunlap@eu.citrix.com>, wei.wang2@amd.com,
	Santosh Jodh <santosh.jodh@citrix.com>, Jan Beulich <JBeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Using debug-key 'o:  Dump IOMMU p2m table,
	locks up machine
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 Keir,

Tuesday, September 4, 2012, 10:11:42 AM, you wrote:

> On 04/09/2012 09:04, "Keir Fraser" <keir.xen@gmail.com> wrote:

>> On 04/09/2012 08:55, "Jan Beulich" <JBeulich@suse.com> wrote:
>> 
>>>> Jan, Yes you could be right, if Sander is pinning CPUs. Anyway, I wasn't
>>>> going to expend too much brain power on this situation. The case of spending
>>>> a few minutes in one key handler is not one I think is particularly sane.
>>> 
>>> Which imo would call for reverting the patch. But then again, other
>>> key handlers can easily take pretty long too (particularly on large
>>> systems, albeit it is clear that the one here is particularly bad), and
>>> declaring all of them pretty much useless probably isn't the best
>>> choice (as then we could as well rip them all out).
>>> 
>>> Bottom line - _I_ think we should try to do something about this.
>>> An apparent option would be to have low priority tasklets (for
>>> just this purpose, as all others we certainly want to take priority),
>>> if that can reasonably be integrated with the schedulers.
>> 
>> Do you expect to be able to use the log-running key handlers and still need
>> a running system afterwards (rather than using them as a final
>> dump-everything when the system has already gone bad)? Then I suppose you
>> would need something like this, with voluntary preemption in the key
>> handlers. You then need to be able to recommence the keyhandlers where they
>> left off, retaking locks, finding their place in lists, trees, etc, even
>> when state of the system has significantly changed between preemption and
>> resumption. Well, I'm sure it can be done, but can anyone be bothered.

> My pragmatic take would be that: (a) Really long-running handlers that want
> to dump every page mapping of every domain are pretty bloody stupid, and yes
> we should consider if they are worthwhile at all; (b) moderately
> long-running but useful handlers which nonetheless take a long time to dump
> to Xen's console, I would consider a sysctl to allow dom0 to request dump
> into a supplied memory buffer.

Is it necessary for this case to let it be a key-handler for which one can't specify parameters to limit the output ?

In this case both hypervisor and kernel are running fine, so a interface via say "xl debug" should be perfectly fine and providing parameters should be possible ?

>>  -- Keir
>> 
>> 



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

From xen-devel-bounces@lists.xen.org Tue Sep 04 08:22:20 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Sep 2012 08: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 1T8oOf-0005C5-EC; Tue, 04 Sep 2012 08:22:09 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jmarcet@gmail.com>) id 1T8oOd-0005Bs-W1
	for xen-devel@lists.xen.org; Tue, 04 Sep 2012 08:22:08 +0000
Received: from [85.158.143.99:51071] by server-2.bemta-4.messagelabs.com id
	BB/92-21239-F2AB5405; Tue, 04 Sep 2012 08:22:07 +0000
X-Env-Sender: jmarcet@gmail.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1346746925!28047936!1
X-Originating-IP: [209.85.214.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	ML_RADAR_SPEW_LINKS_8,RCVD_BY_IP,spamassassin: ,surbl: (ASYNC_NO) 
	c3VyYmxfcmVjaGVja19kZWxheTogMCAoYWJhbmRvbmVkOiBkbC5kcm9wYm94LmNvbS91LzEyN
	Tc5\nMTEyL3ZpcnQtbWFuYWdlci5sb2cp\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19850 invoked from network); 4 Sep 2012 08:22:06 -0000
Received: from mail-ob0-f173.google.com (HELO mail-ob0-f173.google.com)
	(209.85.214.173)
	by server-5.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Sep 2012 08:22:06 -0000
Received: by obbta14 with SMTP id ta14so13754677obb.32
	for <xen-devel@lists.xen.org>; Tue, 04 Sep 2012 01: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:from:date:message-id:subject:to
	:cc:content-type;
	bh=LZZQ/wh5m587xbilPVmcjyE+U0thfDA66HXPUEM69r4=;
	b=S5FLc4xpco8RgEs5FDHGu1GrtYBTukGFhgHQfYFXd5SS4zZSYZgYmExLKg7+eNZfaQ
	Eu/BGXagkOqKsL/9xvNs0KrxSKGLqkmdgkfx2oP/H5JrBFoTf/eOsAP+n4oqK3+EvT1V
	zQJsyasahsHU+5YwtgsHe9Or46UKoYKRUl/G4nLTF5YcWOr6MOLRxt0MQIoKmgVsP1aG
	41+dN2JylU2gOz+2bIy/XrMf3dAV7RBfOsoOo5N0PfW5zcghLpFjU/FTS9ZC2wafTd7V
	W5+3JsRhMIqxTwdVXcubLbV944CHnkGysZin4BG25ZfzVU4dHIt6fr4tTgKmnYHiz0kX
	3V3A==
Received: by 10.60.172.199 with SMTP id be7mr15435549oec.93.1346746924710;
	Tue, 04 Sep 2012 01:22:04 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.60.12.164 with HTTP; Tue, 4 Sep 2012 01:21:44 -0700 (PDT)
In-Reply-To: <5045D3430200007800098622@nat28.tlf.novell.com>
References: <CAAnFQG8z_ja1Wj2hX+0ZRsz5eLWr+U+7PoSiF9NePsSh2jbX4g@mail.gmail.com>
	<5040B7A40200007800097CEE@nat28.tlf.novell.com>
	<CAAnFQG_vvHQL=NbY1SnMWCcTr73_8RYtNLfc00fqEsz57cd7Rg@mail.gmail.com>
	<504478B40200007800098286@nat28.tlf.novell.com>
	<CAAnFQG_7JW9Zb91RteXrRGuFL-aNrDGdwz6aQ4LUq9bNKQ4KYA@mail.gmail.com>
	<5045D3430200007800098622@nat28.tlf.novell.com>
From: Javier Marcet <jmarcet@gmail.com>
Date: Tue, 4 Sep 2012 10:21:44 +0200
Message-ID: <CAAnFQG8TjcMngY8KX3kBa=ZZXGZHuUpmrorGe6PGQ35Fp66G5Q@mail.gmail.com>
To: Jan Beulich <JBeulich@suse.com>
Cc: Xen Devel Mailing list <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.2.0-rc4 bugs with GigaByte H77M-D3H + Core i7
	3770
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Sep 4, 2012 at 10:09 AM, Jan Beulich <JBeulich@suse.com> wrote:

>>>> The big issue I'm having running xen is that I can't use it since xen can't
>>>> get the cpu capabilities.
>>>
>>> What "cpu capabilities"? I just looked at your original mail again,
>>> and I cannot see what failure you're referring to (in fact, I'm not
>>> able to spot any failure in that log at all). And of course you didn't
>>> even attach a hypervisor log. What am I missing?
>>
>> These are all the xen and virt-manager logs:
>>
>> http://dl.dropbox.com/u/12579112/hypervisor.log
>> http://dl.dropbox.com/u/12579112/qemu-dm-Windows7.log
>> http://dl.dropbox.com/u/12579112/virt-manager.log
>> http://dl.dropbox.com/u/12579112/xen-hotplug.log
>> http://dl.dropbox.com/u/12579112/xend.log
>> http://dl.dropbox.com/u/12579112/xend-debug.log
>> http://dl.dropbox.com/u/12579112/xenstored-trace.log.gz
>>
>> In the virt-manager logs you can see an instance of kvm and an instance of
>> xen.
>> See the difference in the cpu capabilities detected.
>
> Sorry, no, I can't. I don't see any trace of KVM in there. Also I
> fail to see how this relates to the wording of the subject of
> this thread.

Hmmm, I just checked it again and certainly, it doesn't mention kvm,
it just says qemu. From the virt-manager log, the kvm entry:

[Thu, 30 Aug 2012 02:32:24 virt-manager 4483] DEBUG (connection:1239)
qemu:///system capabilities:
<capabilities>

  <host>
    <uuid>90022b03-3404-1305-6006-130700080009</uuid>
    <cpu>
      <arch>x86_64</arch>
      <model>Westmere</model>
      <vendor>Intel</vendor>
      <topology sockets='1' cores='4' threads='2'/>
      <feature name='rdtscp'/>
      <feature name='x2apic'/>
      <feature name='xtpr'/>
      <feature name='tm2'/>
      <feature name='est'/>
      <feature name='vmx'/>
      <feature name='ds_cpl'/>
      <feature name='monitor'/>
      <feature name='pbe'/>
      <feature name='tm'/>
      <feature name='ht'/>
      <feature name='ss'/>
      <feature name='acpi'/>
      <feature name='ds'/>
      <feature name='vme'/>
    </cpu>
    <power_management>
      <suspend_mem/>
    </power_management>
    <migration_features>
      <live/>
      <uri_transports>
        <uri_transport>tcp</uri_transport>
      </uri_transports>
    </migration_features>
  </host>

>From the same log, this time the xen entry:

[Thu, 30 Aug 2012 02:32:24 virt-manager 4483] DEBUG (connection:1239)
xen:/// capabilities:
<capabilities>

  <host>
    <cpu>
      <arch>x86_64</arch>
      <features>
        <pae/>
      </features>
    </cpu>
    <power_management>
      <suspend_mem/>
    </power_management>
    <migration_features>
      <live/>
      <uri_transports>
        <uri_transport>xenmigr</uri_transport>
      </uri_transports>
    </migration_features>
  </host>

>> As far as the hypervisor goes, the only error logged is:

>> (XEN) sh error: sh_remove_all_mappings(): can't find all mappings of
>> mfn xxxxxx: c=c000000000000002 t=7400000000000001

> That doesn't look good, but I can't tell you much about it. I
> wouldn't expect you to use shadow mode anyway on a Core-i7 -
> are you intentionally turning off HAP for your guests?

Nope, not intentionally.

> Or is all of this thread really about virt-manager shortcomings
> rather than problems in Xen (in which case you likely picked the
> wrong mailing list)?

Well, I wanted to check and compare xen to the other solutions
I had used so far. I used virt-manager because it supports xen
and I already used it. But the issue I had with the cpu not being
detected leaves no trace of error anywhere, hence I didn't know
what to check.

If you believe this might be a virt-manager problem, not xen's,
I will try creating a xmdomain.cfg by hand.


-- 
Javier Marcet <jmarcet@gmail.com>

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

From xen-devel-bounces@lists.xen.org Tue Sep 04 08:22:20 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Sep 2012 08: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 1T8oOf-0005C5-EC; Tue, 04 Sep 2012 08:22:09 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jmarcet@gmail.com>) id 1T8oOd-0005Bs-W1
	for xen-devel@lists.xen.org; Tue, 04 Sep 2012 08:22:08 +0000
Received: from [85.158.143.99:51071] by server-2.bemta-4.messagelabs.com id
	BB/92-21239-F2AB5405; Tue, 04 Sep 2012 08:22:07 +0000
X-Env-Sender: jmarcet@gmail.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1346746925!28047936!1
X-Originating-IP: [209.85.214.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	ML_RADAR_SPEW_LINKS_8,RCVD_BY_IP,spamassassin: ,surbl: (ASYNC_NO) 
	c3VyYmxfcmVjaGVja19kZWxheTogMCAoYWJhbmRvbmVkOiBkbC5kcm9wYm94LmNvbS91LzEyN
	Tc5\nMTEyL3ZpcnQtbWFuYWdlci5sb2cp\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19850 invoked from network); 4 Sep 2012 08:22:06 -0000
Received: from mail-ob0-f173.google.com (HELO mail-ob0-f173.google.com)
	(209.85.214.173)
	by server-5.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Sep 2012 08:22:06 -0000
Received: by obbta14 with SMTP id ta14so13754677obb.32
	for <xen-devel@lists.xen.org>; Tue, 04 Sep 2012 01: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:from:date:message-id:subject:to
	:cc:content-type;
	bh=LZZQ/wh5m587xbilPVmcjyE+U0thfDA66HXPUEM69r4=;
	b=S5FLc4xpco8RgEs5FDHGu1GrtYBTukGFhgHQfYFXd5SS4zZSYZgYmExLKg7+eNZfaQ
	Eu/BGXagkOqKsL/9xvNs0KrxSKGLqkmdgkfx2oP/H5JrBFoTf/eOsAP+n4oqK3+EvT1V
	zQJsyasahsHU+5YwtgsHe9Or46UKoYKRUl/G4nLTF5YcWOr6MOLRxt0MQIoKmgVsP1aG
	41+dN2JylU2gOz+2bIy/XrMf3dAV7RBfOsoOo5N0PfW5zcghLpFjU/FTS9ZC2wafTd7V
	W5+3JsRhMIqxTwdVXcubLbV944CHnkGysZin4BG25ZfzVU4dHIt6fr4tTgKmnYHiz0kX
	3V3A==
Received: by 10.60.172.199 with SMTP id be7mr15435549oec.93.1346746924710;
	Tue, 04 Sep 2012 01:22:04 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.60.12.164 with HTTP; Tue, 4 Sep 2012 01:21:44 -0700 (PDT)
In-Reply-To: <5045D3430200007800098622@nat28.tlf.novell.com>
References: <CAAnFQG8z_ja1Wj2hX+0ZRsz5eLWr+U+7PoSiF9NePsSh2jbX4g@mail.gmail.com>
	<5040B7A40200007800097CEE@nat28.tlf.novell.com>
	<CAAnFQG_vvHQL=NbY1SnMWCcTr73_8RYtNLfc00fqEsz57cd7Rg@mail.gmail.com>
	<504478B40200007800098286@nat28.tlf.novell.com>
	<CAAnFQG_7JW9Zb91RteXrRGuFL-aNrDGdwz6aQ4LUq9bNKQ4KYA@mail.gmail.com>
	<5045D3430200007800098622@nat28.tlf.novell.com>
From: Javier Marcet <jmarcet@gmail.com>
Date: Tue, 4 Sep 2012 10:21:44 +0200
Message-ID: <CAAnFQG8TjcMngY8KX3kBa=ZZXGZHuUpmrorGe6PGQ35Fp66G5Q@mail.gmail.com>
To: Jan Beulich <JBeulich@suse.com>
Cc: Xen Devel Mailing list <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.2.0-rc4 bugs with GigaByte H77M-D3H + Core i7
	3770
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Sep 4, 2012 at 10:09 AM, Jan Beulich <JBeulich@suse.com> wrote:

>>>> The big issue I'm having running xen is that I can't use it since xen can't
>>>> get the cpu capabilities.
>>>
>>> What "cpu capabilities"? I just looked at your original mail again,
>>> and I cannot see what failure you're referring to (in fact, I'm not
>>> able to spot any failure in that log at all). And of course you didn't
>>> even attach a hypervisor log. What am I missing?
>>
>> These are all the xen and virt-manager logs:
>>
>> http://dl.dropbox.com/u/12579112/hypervisor.log
>> http://dl.dropbox.com/u/12579112/qemu-dm-Windows7.log
>> http://dl.dropbox.com/u/12579112/virt-manager.log
>> http://dl.dropbox.com/u/12579112/xen-hotplug.log
>> http://dl.dropbox.com/u/12579112/xend.log
>> http://dl.dropbox.com/u/12579112/xend-debug.log
>> http://dl.dropbox.com/u/12579112/xenstored-trace.log.gz
>>
>> In the virt-manager logs you can see an instance of kvm and an instance of
>> xen.
>> See the difference in the cpu capabilities detected.
>
> Sorry, no, I can't. I don't see any trace of KVM in there. Also I
> fail to see how this relates to the wording of the subject of
> this thread.

Hmmm, I just checked it again and certainly, it doesn't mention kvm,
it just says qemu. From the virt-manager log, the kvm entry:

[Thu, 30 Aug 2012 02:32:24 virt-manager 4483] DEBUG (connection:1239)
qemu:///system capabilities:
<capabilities>

  <host>
    <uuid>90022b03-3404-1305-6006-130700080009</uuid>
    <cpu>
      <arch>x86_64</arch>
      <model>Westmere</model>
      <vendor>Intel</vendor>
      <topology sockets='1' cores='4' threads='2'/>
      <feature name='rdtscp'/>
      <feature name='x2apic'/>
      <feature name='xtpr'/>
      <feature name='tm2'/>
      <feature name='est'/>
      <feature name='vmx'/>
      <feature name='ds_cpl'/>
      <feature name='monitor'/>
      <feature name='pbe'/>
      <feature name='tm'/>
      <feature name='ht'/>
      <feature name='ss'/>
      <feature name='acpi'/>
      <feature name='ds'/>
      <feature name='vme'/>
    </cpu>
    <power_management>
      <suspend_mem/>
    </power_management>
    <migration_features>
      <live/>
      <uri_transports>
        <uri_transport>tcp</uri_transport>
      </uri_transports>
    </migration_features>
  </host>

>From the same log, this time the xen entry:

[Thu, 30 Aug 2012 02:32:24 virt-manager 4483] DEBUG (connection:1239)
xen:/// capabilities:
<capabilities>

  <host>
    <cpu>
      <arch>x86_64</arch>
      <features>
        <pae/>
      </features>
    </cpu>
    <power_management>
      <suspend_mem/>
    </power_management>
    <migration_features>
      <live/>
      <uri_transports>
        <uri_transport>xenmigr</uri_transport>
      </uri_transports>
    </migration_features>
  </host>

>> As far as the hypervisor goes, the only error logged is:

>> (XEN) sh error: sh_remove_all_mappings(): can't find all mappings of
>> mfn xxxxxx: c=c000000000000002 t=7400000000000001

> That doesn't look good, but I can't tell you much about it. I
> wouldn't expect you to use shadow mode anyway on a Core-i7 -
> are you intentionally turning off HAP for your guests?

Nope, not intentionally.

> Or is all of this thread really about virt-manager shortcomings
> rather than problems in Xen (in which case you likely picked the
> wrong mailing list)?

Well, I wanted to check and compare xen to the other solutions
I had used so far. I used virt-manager because it supports xen
and I already used it. But the issue I had with the cpu not being
detected leaves no trace of error anywhere, hence I didn't know
what to check.

If you believe this might be a virt-manager problem, not xen's,
I will try creating a xmdomain.cfg by hand.


-- 
Javier Marcet <jmarcet@gmail.com>

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

From xen-devel-bounces@lists.xen.org Tue Sep 04 08:22:51 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Sep 2012 08:22: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 1T8oPB-0005Ft-RY; Tue, 04 Sep 2012 08:22:41 +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 1T8oPB-0005Fg-CN
	for xen-devel@lists.xen.org; Tue, 04 Sep 2012 08:22:41 +0000
Received: from [85.158.143.99:48403] by server-3.bemta-4.messagelabs.com id
	2A/A5-08232-05AB5405; Tue, 04 Sep 2012 08:22:40 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-10.tower-216.messagelabs.com!1346746908!21996902!1
X-Originating-IP: [188.40.164.121]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20228 invoked from network); 4 Sep 2012 08:21:49 -0000
Received: from static.121.164.40.188.clients.your-server.de (HELO
	smtp.eikelenboom.it) (188.40.164.121)
	by server-10.tower-216.messagelabs.com with AES256-SHA encrypted SMTP;
	4 Sep 2012 08:21:49 -0000
Received: from 26-69-ftth.onsneteindhoven.nl ([88.159.69.26]:49734
	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 1T8oLH-0002Se-Hy; Tue, 04 Sep 2012 10:18:39 +0200
Date: Tue, 4 Sep 2012 10:21:46 +0200
From: Sander Eikelenboom <linux@eikelenboom.it>
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <768327829.20120904102146@eikelenboom.it>
To: Wei Wang <wei.wang2@amd.com>
In-Reply-To: <5044CAD7.8030800@amd.com>
References: <40501859.20120902104331@eikelenboom.it>
	<CC6932C2.3D99D%keir.xen@gmail.com>
	<217459398.20120902171441@eikelenboom.it>
	<5044CAD7.8030800@amd.com>
MIME-Version: 1.0
Cc: Keir Fraser <keir.xen@gmail.com>, Santosh Jodh <Santosh.Jodh@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Using debug-key 'o:  Dump IOMMU p2m table,
	locks up machine
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 Wei,

Monday, September 3, 2012, 5:20:55 PM, you wrote:

> On 09/02/2012 05:14 PM, Sander Eikelenboom wrote:
>> Sunday, September 2, 2012, 4:58:58 PM, you wrote:
>>
>>> On 02/09/2012 09:43, "Sander Eikelenboom"<linux@eikelenboom.it>  wrote:
>>
>>>>> Quite simply, there likely needs to be more tracing on the IOMMU fault path.
>>>>> That's a separate concern from your keyhandler of course, but just saying
>>>>> I'd be looking for the former rather than the latter, for diagnosing
>>>>> Sander's bug.
>>>>
>>>> Are there any printk's I could add to get more relevant info about the AMD-Vi:
>>>> IO_PAGE_FAULT ?
>>
>>> No really straightforward one. I think we need a per-IOMMU-type handler to
>>> walk the IOMMU page table for a given virtual address, and dump every
>>> page-table-entry on the path. Like an IOMMU version of show_page_walk().
>>> Personally I would suspect this is more useful than the dump-everything
>>> handlers: just give a *full* *detailed* walk for the actually interesting
>>> virtual address (the one faulted on).
>>
>>>> I have attached new output from xl dmesg, this time with iommu=debug on (the
>>>> option changed from 4.1 to 4.2).
>>
>>> Not easy to glean any more from that, without extra tracing such as
>>> described above, and/or digging into the guest to find what driver-side
>>> actions are causing the faults.
>>
>> OK, too bad!
>> With xen 4.1 i haven't experienced those page faults, but a diff between /xen/drivers/passthrough/amd in both trees show quite some changes :(

> Did you also update xen tools accordingly? Sometime I also saw a few 
> IO_PAGE_FAULTs came from nic if my tools version and HV version did not 
> match. But using recent 4.2 and corresponding xl, my tests went well.
> BTW: You could also try iommu=no-sharept to see if it helps.

I have done a make world && make install, after that checked the date on (most of) the binaries and libs.
All should be 4.2, will try the iommu=no-sharept, but as said, this wasn't necessary with 4.1.3.


> Thanks,
> Wei

>>>   -- Keir
>>
>>>>
>>>>
>>>>>   -- Keir
>>>>
>>
>>
>>
>>
>>
>>






-- 
Best regards,
 Sander                            mailto:linux@eikelenboom.it


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

From xen-devel-bounces@lists.xen.org Tue Sep 04 08:22:51 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Sep 2012 08:22: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 1T8oPB-0005Ft-RY; Tue, 04 Sep 2012 08:22:41 +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 1T8oPB-0005Fg-CN
	for xen-devel@lists.xen.org; Tue, 04 Sep 2012 08:22:41 +0000
Received: from [85.158.143.99:48403] by server-3.bemta-4.messagelabs.com id
	2A/A5-08232-05AB5405; Tue, 04 Sep 2012 08:22:40 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-10.tower-216.messagelabs.com!1346746908!21996902!1
X-Originating-IP: [188.40.164.121]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20228 invoked from network); 4 Sep 2012 08:21:49 -0000
Received: from static.121.164.40.188.clients.your-server.de (HELO
	smtp.eikelenboom.it) (188.40.164.121)
	by server-10.tower-216.messagelabs.com with AES256-SHA encrypted SMTP;
	4 Sep 2012 08:21:49 -0000
Received: from 26-69-ftth.onsneteindhoven.nl ([88.159.69.26]:49734
	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 1T8oLH-0002Se-Hy; Tue, 04 Sep 2012 10:18:39 +0200
Date: Tue, 4 Sep 2012 10:21:46 +0200
From: Sander Eikelenboom <linux@eikelenboom.it>
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <768327829.20120904102146@eikelenboom.it>
To: Wei Wang <wei.wang2@amd.com>
In-Reply-To: <5044CAD7.8030800@amd.com>
References: <40501859.20120902104331@eikelenboom.it>
	<CC6932C2.3D99D%keir.xen@gmail.com>
	<217459398.20120902171441@eikelenboom.it>
	<5044CAD7.8030800@amd.com>
MIME-Version: 1.0
Cc: Keir Fraser <keir.xen@gmail.com>, Santosh Jodh <Santosh.Jodh@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Using debug-key 'o:  Dump IOMMU p2m table,
	locks up machine
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 Wei,

Monday, September 3, 2012, 5:20:55 PM, you wrote:

> On 09/02/2012 05:14 PM, Sander Eikelenboom wrote:
>> Sunday, September 2, 2012, 4:58:58 PM, you wrote:
>>
>>> On 02/09/2012 09:43, "Sander Eikelenboom"<linux@eikelenboom.it>  wrote:
>>
>>>>> Quite simply, there likely needs to be more tracing on the IOMMU fault path.
>>>>> That's a separate concern from your keyhandler of course, but just saying
>>>>> I'd be looking for the former rather than the latter, for diagnosing
>>>>> Sander's bug.
>>>>
>>>> Are there any printk's I could add to get more relevant info about the AMD-Vi:
>>>> IO_PAGE_FAULT ?
>>
>>> No really straightforward one. I think we need a per-IOMMU-type handler to
>>> walk the IOMMU page table for a given virtual address, and dump every
>>> page-table-entry on the path. Like an IOMMU version of show_page_walk().
>>> Personally I would suspect this is more useful than the dump-everything
>>> handlers: just give a *full* *detailed* walk for the actually interesting
>>> virtual address (the one faulted on).
>>
>>>> I have attached new output from xl dmesg, this time with iommu=debug on (the
>>>> option changed from 4.1 to 4.2).
>>
>>> Not easy to glean any more from that, without extra tracing such as
>>> described above, and/or digging into the guest to find what driver-side
>>> actions are causing the faults.
>>
>> OK, too bad!
>> With xen 4.1 i haven't experienced those page faults, but a diff between /xen/drivers/passthrough/amd in both trees show quite some changes :(

> Did you also update xen tools accordingly? Sometime I also saw a few 
> IO_PAGE_FAULTs came from nic if my tools version and HV version did not 
> match. But using recent 4.2 and corresponding xl, my tests went well.
> BTW: You could also try iommu=no-sharept to see if it helps.

I have done a make world && make install, after that checked the date on (most of) the binaries and libs.
All should be 4.2, will try the iommu=no-sharept, but as said, this wasn't necessary with 4.1.3.


> Thanks,
> Wei

>>>   -- Keir
>>
>>>>
>>>>
>>>>>   -- Keir
>>>>
>>
>>
>>
>>
>>
>>






-- 
Best regards,
 Sander                            mailto:linux@eikelenboom.it


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

From xen-devel-bounces@lists.xen.org Tue Sep 04 08:38:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Sep 2012 08:38:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T8odx-0005nG-IF; Tue, 04 Sep 2012 08:37:57 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1T8odv-0005mh-UN
	for xen-devel@lists.xen.org; Tue, 04 Sep 2012 08:37:56 +0000
Received: from [85.158.139.83:32304] by server-10.bemta-5.messagelabs.com id
	F5/01-10969-3EDB5405; Tue, 04 Sep 2012 08:37:55 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1346747874!28410030!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM4MjY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31722 invoked from network); 4 Sep 2012 08:37:54 -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;
	4 Sep 2012 08:37:54 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 04 Sep 2012 09:37:53 +0100
Message-Id: <5045DA360200007800098688@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 04 Sep 2012 09:38:46 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "George Dunlap" <George.Dunlap@eu.citrix.com>,
	"Keir Fraser" <keir.xen@gmail.com>
References: <CC6B74A7.3DAC1%keir.xen@gmail.com>
	<CC6B764E.3DACF%keir.xen@gmail.com>
In-Reply-To: <CC6B764E.3DACF%keir.xen@gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: wei.wang2@amd.com, Sander Eikelenboom <linux@eikelenboom.it>,
	Santosh Jodh <santosh.jodh@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Using debug-key 'o:  Dump IOMMU p2m table,
 locks up machine
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.09.12 at 10:11, Keir Fraser <keir.xen@gmail.com> wrote:
> On 04/09/2012 09:04, "Keir Fraser" <keir.xen@gmail.com> wrote:
> 
>> On 04/09/2012 08:55, "Jan Beulich" <JBeulich@suse.com> wrote:
>> 
>>>> Jan, Yes you could be right, if Sander is pinning CPUs. Anyway, I wasn't
>>>> going to expend too much brain power on this situation. The case of spending
>>>> a few minutes in one key handler is not one I think is particularly sane.
>>> 
>>> Which imo would call for reverting the patch. But then again, other
>>> key handlers can easily take pretty long too (particularly on large
>>> systems, albeit it is clear that the one here is particularly bad), and
>>> declaring all of them pretty much useless probably isn't the best
>>> choice (as then we could as well rip them all out).
>>> 
>>> Bottom line - _I_ think we should try to do something about this.
>>> An apparent option would be to have low priority tasklets (for
>>> just this purpose, as all others we certainly want to take priority),
>>> if that can reasonably be integrated with the schedulers.
>> 
>> Do you expect to be able to use the log-running key handlers and still need
>> a running system afterwards (rather than using them as a final
>> dump-everything when the system has already gone bad)? Then I suppose you
>> would need something like this, with voluntary preemption in the key
>> handlers. You then need to be able to recommence the keyhandlers where they
>> left off, retaking locks, finding their place in lists, trees, etc, even
>> when state of the system has significantly changed between preemption and
>> resumption. Well, I'm sure it can be done, but can anyone be bothered.

It may not be that difficult for e.g. the 'd' and '0' handlers.

> My pragmatic take would be that: (a) Really long-running handlers that want
> to dump every page mapping of every domain are pretty bloody stupid, and yes
> we should consider if they are worthwhile at all; (b) moderately
> long-running but useful handlers which nonetheless take a long time to dump
> to Xen's console, I would consider a sysctl to allow dom0 to request dump
> into a supplied memory buffer.

At a first glance that sounds like a viable option, assuming that
the bulk of the time otherwise is being spent actually getting the
data out through the serial line. But if the long-running-ness is
in the nature of the keyhandler itself, then this wouldn't help
much though. And I'd be afraid that ought to be the common
case when not running with sync_console, since actual serial
output happens asynchronously and hence shouldn't affect the
latency of the keyhandler's completion too much.

Jan


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

From xen-devel-bounces@lists.xen.org Tue Sep 04 08:38:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Sep 2012 08:38:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T8odx-0005nG-IF; Tue, 04 Sep 2012 08:37:57 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1T8odv-0005mh-UN
	for xen-devel@lists.xen.org; Tue, 04 Sep 2012 08:37:56 +0000
Received: from [85.158.139.83:32304] by server-10.bemta-5.messagelabs.com id
	F5/01-10969-3EDB5405; Tue, 04 Sep 2012 08:37:55 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1346747874!28410030!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM4MjY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31722 invoked from network); 4 Sep 2012 08:37:54 -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;
	4 Sep 2012 08:37:54 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 04 Sep 2012 09:37:53 +0100
Message-Id: <5045DA360200007800098688@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 04 Sep 2012 09:38:46 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "George Dunlap" <George.Dunlap@eu.citrix.com>,
	"Keir Fraser" <keir.xen@gmail.com>
References: <CC6B74A7.3DAC1%keir.xen@gmail.com>
	<CC6B764E.3DACF%keir.xen@gmail.com>
In-Reply-To: <CC6B764E.3DACF%keir.xen@gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: wei.wang2@amd.com, Sander Eikelenboom <linux@eikelenboom.it>,
	Santosh Jodh <santosh.jodh@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Using debug-key 'o:  Dump IOMMU p2m table,
 locks up machine
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.09.12 at 10:11, Keir Fraser <keir.xen@gmail.com> wrote:
> On 04/09/2012 09:04, "Keir Fraser" <keir.xen@gmail.com> wrote:
> 
>> On 04/09/2012 08:55, "Jan Beulich" <JBeulich@suse.com> wrote:
>> 
>>>> Jan, Yes you could be right, if Sander is pinning CPUs. Anyway, I wasn't
>>>> going to expend too much brain power on this situation. The case of spending
>>>> a few minutes in one key handler is not one I think is particularly sane.
>>> 
>>> Which imo would call for reverting the patch. But then again, other
>>> key handlers can easily take pretty long too (particularly on large
>>> systems, albeit it is clear that the one here is particularly bad), and
>>> declaring all of them pretty much useless probably isn't the best
>>> choice (as then we could as well rip them all out).
>>> 
>>> Bottom line - _I_ think we should try to do something about this.
>>> An apparent option would be to have low priority tasklets (for
>>> just this purpose, as all others we certainly want to take priority),
>>> if that can reasonably be integrated with the schedulers.
>> 
>> Do you expect to be able to use the log-running key handlers and still need
>> a running system afterwards (rather than using them as a final
>> dump-everything when the system has already gone bad)? Then I suppose you
>> would need something like this, with voluntary preemption in the key
>> handlers. You then need to be able to recommence the keyhandlers where they
>> left off, retaking locks, finding their place in lists, trees, etc, even
>> when state of the system has significantly changed between preemption and
>> resumption. Well, I'm sure it can be done, but can anyone be bothered.

It may not be that difficult for e.g. the 'd' and '0' handlers.

> My pragmatic take would be that: (a) Really long-running handlers that want
> to dump every page mapping of every domain are pretty bloody stupid, and yes
> we should consider if they are worthwhile at all; (b) moderately
> long-running but useful handlers which nonetheless take a long time to dump
> to Xen's console, I would consider a sysctl to allow dom0 to request dump
> into a supplied memory buffer.

At a first glance that sounds like a viable option, assuming that
the bulk of the time otherwise is being spent actually getting the
data out through the serial line. But if the long-running-ness is
in the nature of the keyhandler itself, then this wouldn't help
much though. And I'd be afraid that ought to be the common
case when not running with sync_console, since actual serial
output happens asynchronously and hence shouldn't affect the
latency of the keyhandler's completion too much.

Jan


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

From xen-devel-bounces@lists.xen.org Tue Sep 04 08:38:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Sep 2012 08:38:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T8odw-0005mq-BB; Tue, 04 Sep 2012 08:37:56 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <lists+xen@internecto.net>) id 1T8odu-0005mc-T2
	for xen-devel@lists.xen.org; Tue, 04 Sep 2012 08:37:55 +0000
Received: from [85.158.139.83:30807] by server-10.bemta-5.messagelabs.com id
	26/F0-10969-2EDB5405; Tue, 04 Sep 2012 08:37:54 +0000
X-Env-Sender: lists+xen@internecto.net
X-Msg-Ref: server-14.tower-182.messagelabs.com!1346747873!24161474!1
X-Originating-IP: [176.9.245.29]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7458 invoked from network); 4 Sep 2012 08:37:53 -0000
Received: from polaris.internecto.net (HELO mx1.internecto.net) (176.9.245.29)
	by server-14.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 4 Sep 2012 08:37:53 -0000
Received: from localhost (localhost [127.0.0.1])
	by mx1.internecto.net (Postfix) with ESMTP id B5FA9A02EF;
	Tue,  4 Sep 2012 08:37:52 +0000 (UTC)
X-Virus-Scanned: Debian amavisd-new at mail.internecto.net
Received: from mx1.internecto.net ([127.0.0.1])
	by localhost (mail.polaris.internecto.net [127.0.0.1]) (amavisd-new,
	port 10024)
	with ESMTP id vw8Xola+U6dl; Tue,  4 Sep 2012 08:37:52 +0000 (UTC)
Received: from internecto.net (5ED4FDEB.cm-7-5d.dynamic.ziggo.nl
	[94.212.253.235])
	(using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits))
	(Client did not present a certificate)
	(Authenticated sender: lists@internecto.net)
	by mx1.internecto.net (Postfix) with ESMTPSA id CFAF0A0089;
	Tue,  4 Sep 2012 08:37:51 +0000 (UTC)
Date: Tue, 4 Sep 2012 10:37:50 +0200
From: Mark van Dijk <lists+xen@internecto.net>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120904103750.112fb44d@internecto.net>
In-Reply-To: <1346743867.10570.2.camel@dagon.hellion.org.uk>
References: <1346665360.25864.2.camel@zakaz.uk.xensource.com>
	<20120904090601.77377684@internecto.net>
	<1346743867.10570.2.camel@dagon.hellion.org.uk>
Organization: Internecto SIS
X-Mailer: Claws Mail 3.8.0 (GTK+ 2.24.10; x86_64-pc-linux-gnu)
Mime-Version: 1.0
Cc: xen-users@lists.xen.org, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [Xen-users] Xen 4.2.0 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 realise I'm probably too late, but if it's trivial then maybe it is
>> possible to implement an 'xl reset vmname' function before the final
>> release.
>> 
>> Or is this not as trivial as I think it is?  

Ian Campbell wrote:
> What is it supposed to do?

Casey DeLorme wrote:
> Would reset be different than reboot?
> http://xenbits.xen.org/docs/unstable/man/xl.1.html

The already implemented 'xl reboot' sends an instruction to the running
VM. If that VM doesn't understand this type of call then xl tells you to
try issuing 'xl reboot -F', which sends an ACPI reboot instruction.

These are convenient commands to be issued to a running domain so they
can properly shutdown. But today I found that these both do nothing
when a domain is frozen, e.g. a windows bsod or a hard Linux crash.
It looks to me like there is just one way to take care of that:
(manually) destroy and recreate.

Back when I used xm I remember using the 'xm reset' command that just
simply emulates a manual press of the reset button. By coincidence,
today I found xl lacks this command. In effect I think all it does is
'xl destroy', wait until the domain is properly released and then 'xl
create' it again. This is a bit more convenient than manually issuing
both commands because the time it takes to destroy a VM varies.

So my request is just for convenience and this is why I called it
trivial. Also because one could still issue something like 'xl destroy
domain; sleep 30s; xl create domain'.

(In fact, in my zsh shell env I wrote an xl function that is a wrapper
to the xl binary. Another thing is that it allows me to do 'xl edit
VMname' which issues e.g. 'vim /etc/xen/hosts/VMname'. And when I issue
'xl create VMname' it actually executes '/usr/sbin/xl
create /etc/xen/hosts/VMname'. I like convenience; who doesn't? <grin>)

-- 
Stay in touch,
Mark van Dijk.               ,---------------------------------
----------------------------'         Tue Sep 04 08:23 UTC 2012
Today is Boomtime, the 28th day of Bureaucracy in the YOLD 3178

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

From xen-devel-bounces@lists.xen.org Tue Sep 04 08:38:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Sep 2012 08:38:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T8odw-0005mq-BB; Tue, 04 Sep 2012 08:37:56 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <lists+xen@internecto.net>) id 1T8odu-0005mc-T2
	for xen-devel@lists.xen.org; Tue, 04 Sep 2012 08:37:55 +0000
Received: from [85.158.139.83:30807] by server-10.bemta-5.messagelabs.com id
	26/F0-10969-2EDB5405; Tue, 04 Sep 2012 08:37:54 +0000
X-Env-Sender: lists+xen@internecto.net
X-Msg-Ref: server-14.tower-182.messagelabs.com!1346747873!24161474!1
X-Originating-IP: [176.9.245.29]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7458 invoked from network); 4 Sep 2012 08:37:53 -0000
Received: from polaris.internecto.net (HELO mx1.internecto.net) (176.9.245.29)
	by server-14.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 4 Sep 2012 08:37:53 -0000
Received: from localhost (localhost [127.0.0.1])
	by mx1.internecto.net (Postfix) with ESMTP id B5FA9A02EF;
	Tue,  4 Sep 2012 08:37:52 +0000 (UTC)
X-Virus-Scanned: Debian amavisd-new at mail.internecto.net
Received: from mx1.internecto.net ([127.0.0.1])
	by localhost (mail.polaris.internecto.net [127.0.0.1]) (amavisd-new,
	port 10024)
	with ESMTP id vw8Xola+U6dl; Tue,  4 Sep 2012 08:37:52 +0000 (UTC)
Received: from internecto.net (5ED4FDEB.cm-7-5d.dynamic.ziggo.nl
	[94.212.253.235])
	(using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits))
	(Client did not present a certificate)
	(Authenticated sender: lists@internecto.net)
	by mx1.internecto.net (Postfix) with ESMTPSA id CFAF0A0089;
	Tue,  4 Sep 2012 08:37:51 +0000 (UTC)
Date: Tue, 4 Sep 2012 10:37:50 +0200
From: Mark van Dijk <lists+xen@internecto.net>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120904103750.112fb44d@internecto.net>
In-Reply-To: <1346743867.10570.2.camel@dagon.hellion.org.uk>
References: <1346665360.25864.2.camel@zakaz.uk.xensource.com>
	<20120904090601.77377684@internecto.net>
	<1346743867.10570.2.camel@dagon.hellion.org.uk>
Organization: Internecto SIS
X-Mailer: Claws Mail 3.8.0 (GTK+ 2.24.10; x86_64-pc-linux-gnu)
Mime-Version: 1.0
Cc: xen-users@lists.xen.org, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [Xen-users] Xen 4.2.0 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 realise I'm probably too late, but if it's trivial then maybe it is
>> possible to implement an 'xl reset vmname' function before the final
>> release.
>> 
>> Or is this not as trivial as I think it is?  

Ian Campbell wrote:
> What is it supposed to do?

Casey DeLorme wrote:
> Would reset be different than reboot?
> http://xenbits.xen.org/docs/unstable/man/xl.1.html

The already implemented 'xl reboot' sends an instruction to the running
VM. If that VM doesn't understand this type of call then xl tells you to
try issuing 'xl reboot -F', which sends an ACPI reboot instruction.

These are convenient commands to be issued to a running domain so they
can properly shutdown. But today I found that these both do nothing
when a domain is frozen, e.g. a windows bsod or a hard Linux crash.
It looks to me like there is just one way to take care of that:
(manually) destroy and recreate.

Back when I used xm I remember using the 'xm reset' command that just
simply emulates a manual press of the reset button. By coincidence,
today I found xl lacks this command. In effect I think all it does is
'xl destroy', wait until the domain is properly released and then 'xl
create' it again. This is a bit more convenient than manually issuing
both commands because the time it takes to destroy a VM varies.

So my request is just for convenience and this is why I called it
trivial. Also because one could still issue something like 'xl destroy
domain; sleep 30s; xl create domain'.

(In fact, in my zsh shell env I wrote an xl function that is a wrapper
to the xl binary. Another thing is that it allows me to do 'xl edit
VMname' which issues e.g. 'vim /etc/xen/hosts/VMname'. And when I issue
'xl create VMname' it actually executes '/usr/sbin/xl
create /etc/xen/hosts/VMname'. I like convenience; who doesn't? <grin>)

-- 
Stay in touch,
Mark van Dijk.               ,---------------------------------
----------------------------'         Tue Sep 04 08:23 UTC 2012
Today is Boomtime, the 28th day of Bureaucracy in the YOLD 3178

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

From xen-devel-bounces@lists.xen.org Tue Sep 04 08:52:16 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Sep 2012 08:52: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 1T8ora-0006QH-Vr; Tue, 04 Sep 2012 08:52:02 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1T8orZ-0006Q8-2I
	for xen-devel@lists.xen.org; Tue, 04 Sep 2012 08:52:01 +0000
Received: from [85.158.138.51:24869] by server-3.bemta-3.messagelabs.com id
	61/2E-21322-031C5405; Tue, 04 Sep 2012 08:52:00 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1346748719!19586733!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTE3MTg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 673 invoked from network); 4 Sep 2012 08:51:59 -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;
	4 Sep 2012 08:51:59 -0000
X-IronPort-AV: E=Sophos;i="4.80,366,1344211200"; d="scan'208";a="14329442"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Sep 2012 08:51: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.279.1; Tue, 4 Sep 2012
	09:51:59 +0100
Message-ID: <1346748717.6712.12.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Mark van Dijk <lists+xen@internecto.net>
Date: Tue, 4 Sep 2012 09:51:57 +0100
In-Reply-To: <20120904103750.112fb44d@internecto.net>
References: <1346665360.25864.2.camel@zakaz.uk.xensource.com>
	<20120904090601.77377684@internecto.net>
	<1346743867.10570.2.camel@dagon.hellion.org.uk>
	<20120904103750.112fb44d@internecto.net>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-users@lists.xen.org" <xen-users@lists.xen.org>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [Xen-users] Xen 4.2.0 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-09-04 at 09:37 +0100, Mark van Dijk wrote:
> Back when I used xm I remember using the 'xm reset' command that just
> simply emulates a manual press of the reset button. By coincidence,
> today I found xl lacks this command. In effect I think all it does is
> 'xl destroy', wait until the domain is properly released and then 'xl
> create' it again. This is a bit more convenient than manually issuing
> both commands because the time it takes to destroy a VM varies.

I can see how that would be useful.

I think it is now too late for 4.2.0 (although it might depend on the
patch) but if someone were to produce a patch for 4.3 we could consider
a backport for 4.2.1.

I think you would just need to expose a libxl function which ended up
doing "xc_domain_shutdown(CTX->xch, domid, SHUTDOWN_reboot)". This would
kill the domain and set its shutdown reason to SHUTDOWN_reboot which
would signal the xl daemon monitoring the domain to restart it.

Wire that libxl function up to xl reset (add it to xl_cmdtable.c,
xl_cmdimpl.c and docs/man/xl.cfg.pod.1) and you are good to go, I think.

Let me know if you want to give it a go and require more guidance.

Ian.



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

From xen-devel-bounces@lists.xen.org Tue Sep 04 08:52:16 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Sep 2012 08:52: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 1T8ora-0006QH-Vr; Tue, 04 Sep 2012 08:52:02 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1T8orZ-0006Q8-2I
	for xen-devel@lists.xen.org; Tue, 04 Sep 2012 08:52:01 +0000
Received: from [85.158.138.51:24869] by server-3.bemta-3.messagelabs.com id
	61/2E-21322-031C5405; Tue, 04 Sep 2012 08:52:00 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1346748719!19586733!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTE3MTg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 673 invoked from network); 4 Sep 2012 08:51:59 -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;
	4 Sep 2012 08:51:59 -0000
X-IronPort-AV: E=Sophos;i="4.80,366,1344211200"; d="scan'208";a="14329442"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Sep 2012 08:51: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.279.1; Tue, 4 Sep 2012
	09:51:59 +0100
Message-ID: <1346748717.6712.12.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Mark van Dijk <lists+xen@internecto.net>
Date: Tue, 4 Sep 2012 09:51:57 +0100
In-Reply-To: <20120904103750.112fb44d@internecto.net>
References: <1346665360.25864.2.camel@zakaz.uk.xensource.com>
	<20120904090601.77377684@internecto.net>
	<1346743867.10570.2.camel@dagon.hellion.org.uk>
	<20120904103750.112fb44d@internecto.net>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-users@lists.xen.org" <xen-users@lists.xen.org>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [Xen-users] Xen 4.2.0 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-09-04 at 09:37 +0100, Mark van Dijk wrote:
> Back when I used xm I remember using the 'xm reset' command that just
> simply emulates a manual press of the reset button. By coincidence,
> today I found xl lacks this command. In effect I think all it does is
> 'xl destroy', wait until the domain is properly released and then 'xl
> create' it again. This is a bit more convenient than manually issuing
> both commands because the time it takes to destroy a VM varies.

I can see how that would be useful.

I think it is now too late for 4.2.0 (although it might depend on the
patch) but if someone were to produce a patch for 4.3 we could consider
a backport for 4.2.1.

I think you would just need to expose a libxl function which ended up
doing "xc_domain_shutdown(CTX->xch, domid, SHUTDOWN_reboot)". This would
kill the domain and set its shutdown reason to SHUTDOWN_reboot which
would signal the xl daemon monitoring the domain to restart it.

Wire that libxl function up to xl reset (add it to xl_cmdtable.c,
xl_cmdimpl.c and docs/man/xl.cfg.pod.1) and you are good to go, I think.

Let me know if you want to give it a go and require more guidance.

Ian.



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

From xen-devel-bounces@lists.xen.org Tue Sep 04 08:54:29 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Sep 2012 08:54:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T8otk-0006fH-7K; Tue, 04 Sep 2012 08:54:16 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1T8oti-0006f6-Py
	for xen-devel@lists.xen.org; Tue, 04 Sep 2012 08:54:15 +0000
Received: from [85.158.139.83:31117] by server-9.bemta-5.messagelabs.com id
	59/0F-20529-6B1C5405; Tue, 04 Sep 2012 08:54:14 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1346748853!28414139!1
X-Originating-IP: [209.85.215.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28419 invoked from network); 4 Sep 2012 08:54:13 -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;
	4 Sep 2012 08:54:13 -0000
Received: by eaac13 with SMTP id c13so1996606eaa.32
	for <xen-devel@lists.xen.org>; Tue, 04 Sep 2012 01:54:13 -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=ZmdxEKaNiqfz1zaTf2RgHJ66iQhYTz3+1B8bGgL+h+s=;
	b=wljSap92C+LlaThL2Fy4f/nUQ5JYAsy5kQPf5+KXF2p+WbrlDe7YkKlove2k+Sz+hG
	qSR54+BkpMx7ROL3gLLUHVLNbMEdK9cMgmyCP0IBtus9E0szZ8rYmFwUC9IDkoqwsQw8
	BxIPK+L5NsCE1OGmiibqq95Fl8M7HEs+KGT+CRsZS91bhw+//HBEb5hGQTU5SbXEa/xi
	csHC2wG3Bj/A5GP4IxyP4s1TM+6ftIVWAe4HVD94n4YkqcNvdzUZefw/onsW9I7uL6Xn
	vNktS7McSPipgmyRtC40ikoOUj7GT+BDCwveZ4rsiYgK7EWcpXj8Vnve76jFs4K6kbwL
	V//w==
Received: by 10.14.223.9 with SMTP id u9mr25160745eep.10.1346748853365;
	Tue, 04 Sep 2012 01:54:13 -0700 (PDT)
Received: from [192.168.1.3] (host86-184-74-117.range86-184.btcentralplus.com.
	[86.184.74.117])
	by mx.google.com with ESMTPS id h42sm43510644eem.5.2012.09.04.01.54.10
	(version=SSLv3 cipher=OTHER); Tue, 04 Sep 2012 01:54:12 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.33.0.120411
Date: Tue, 04 Sep 2012 09:54:02 +0100
From: Keir Fraser <keir@xen.org>
To: Jan Beulich <JBeulich@suse.com>,
	George Dunlap <George.Dunlap@eu.citrix.com>
Message-ID: <CC6B803A.4A8E0%keir@xen.org>
Thread-Topic: [Xen-devel] Using debug-key 'o:  Dump IOMMU p2m table, locks up
	machine
Thread-Index: Ac2KetSIIXAo9+QaXE+y6WvmNgbl1A==
In-Reply-To: <5045DA360200007800098688@nat28.tlf.novell.com>
Mime-version: 1.0
Cc: wei.wang2@amd.com, Sander Eikelenboom <linux@eikelenboom.it>,
	Santosh Jodh <santosh.jodh@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Using debug-key 'o:  Dump IOMMU p2m table,
 locks up machine
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/09/2012 09:38, "Jan Beulich" <JBeulich@suse.com> wrote:

>> My pragmatic take would be that: (a) Really long-running handlers that want
>> to dump every page mapping of every domain are pretty bloody stupid, and yes
>> we should consider if they are worthwhile at all; (b) moderately
>> long-running but useful handlers which nonetheless take a long time to dump
>> to Xen's console, I would consider a sysctl to allow dom0 to request dump
>> into a supplied memory buffer.
> 
> At a first glance that sounds like a viable option, assuming that
> the bulk of the time otherwise is being spent actually getting the
> data out through the serial line. But if the long-running-ness is
> in the nature of the keyhandler itself, then this wouldn't help
> much though. And I'd be afraid that ought to be the common
> case when not running with sync_console, since actual serial
> output happens asynchronously and hence shouldn't affect the
> latency of the keyhandler's completion too much.

Well then, have we actually seen problems with async serial output, a
decent-sized serial output buffer, and the 'd'/'0' handlers? Because if not,
we don't have a problem to be solved. :)



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

From xen-devel-bounces@lists.xen.org Tue Sep 04 08:54:29 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Sep 2012 08:54:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T8otk-0006fH-7K; Tue, 04 Sep 2012 08:54:16 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1T8oti-0006f6-Py
	for xen-devel@lists.xen.org; Tue, 04 Sep 2012 08:54:15 +0000
Received: from [85.158.139.83:31117] by server-9.bemta-5.messagelabs.com id
	59/0F-20529-6B1C5405; Tue, 04 Sep 2012 08:54:14 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1346748853!28414139!1
X-Originating-IP: [209.85.215.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28419 invoked from network); 4 Sep 2012 08:54:13 -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;
	4 Sep 2012 08:54:13 -0000
Received: by eaac13 with SMTP id c13so1996606eaa.32
	for <xen-devel@lists.xen.org>; Tue, 04 Sep 2012 01:54:13 -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=ZmdxEKaNiqfz1zaTf2RgHJ66iQhYTz3+1B8bGgL+h+s=;
	b=wljSap92C+LlaThL2Fy4f/nUQ5JYAsy5kQPf5+KXF2p+WbrlDe7YkKlove2k+Sz+hG
	qSR54+BkpMx7ROL3gLLUHVLNbMEdK9cMgmyCP0IBtus9E0szZ8rYmFwUC9IDkoqwsQw8
	BxIPK+L5NsCE1OGmiibqq95Fl8M7HEs+KGT+CRsZS91bhw+//HBEb5hGQTU5SbXEa/xi
	csHC2wG3Bj/A5GP4IxyP4s1TM+6ftIVWAe4HVD94n4YkqcNvdzUZefw/onsW9I7uL6Xn
	vNktS7McSPipgmyRtC40ikoOUj7GT+BDCwveZ4rsiYgK7EWcpXj8Vnve76jFs4K6kbwL
	V//w==
Received: by 10.14.223.9 with SMTP id u9mr25160745eep.10.1346748853365;
	Tue, 04 Sep 2012 01:54:13 -0700 (PDT)
Received: from [192.168.1.3] (host86-184-74-117.range86-184.btcentralplus.com.
	[86.184.74.117])
	by mx.google.com with ESMTPS id h42sm43510644eem.5.2012.09.04.01.54.10
	(version=SSLv3 cipher=OTHER); Tue, 04 Sep 2012 01:54:12 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.33.0.120411
Date: Tue, 04 Sep 2012 09:54:02 +0100
From: Keir Fraser <keir@xen.org>
To: Jan Beulich <JBeulich@suse.com>,
	George Dunlap <George.Dunlap@eu.citrix.com>
Message-ID: <CC6B803A.4A8E0%keir@xen.org>
Thread-Topic: [Xen-devel] Using debug-key 'o:  Dump IOMMU p2m table, locks up
	machine
Thread-Index: Ac2KetSIIXAo9+QaXE+y6WvmNgbl1A==
In-Reply-To: <5045DA360200007800098688@nat28.tlf.novell.com>
Mime-version: 1.0
Cc: wei.wang2@amd.com, Sander Eikelenboom <linux@eikelenboom.it>,
	Santosh Jodh <santosh.jodh@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Using debug-key 'o:  Dump IOMMU p2m table,
 locks up machine
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/09/2012 09:38, "Jan Beulich" <JBeulich@suse.com> wrote:

>> My pragmatic take would be that: (a) Really long-running handlers that want
>> to dump every page mapping of every domain are pretty bloody stupid, and yes
>> we should consider if they are worthwhile at all; (b) moderately
>> long-running but useful handlers which nonetheless take a long time to dump
>> to Xen's console, I would consider a sysctl to allow dom0 to request dump
>> into a supplied memory buffer.
> 
> At a first glance that sounds like a viable option, assuming that
> the bulk of the time otherwise is being spent actually getting the
> data out through the serial line. But if the long-running-ness is
> in the nature of the keyhandler itself, then this wouldn't help
> much though. And I'd be afraid that ought to be the common
> case when not running with sync_console, since actual serial
> output happens asynchronously and hence shouldn't affect the
> latency of the keyhandler's completion too much.

Well then, have we actually seen problems with async serial output, a
decent-sized serial output buffer, and the 'd'/'0' handlers? Because if not,
we don't have a problem to be solved. :)



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

From xen-devel-bounces@lists.xen.org Tue Sep 04 09:25:55 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Sep 2012 09:25: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 1T8pO0-0007Ut-QN; Tue, 04 Sep 2012 09:25:32 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1T8pNz-0007Uo-Cm
	for xen-devel@lists.xen.org; Tue, 04 Sep 2012 09:25:31 +0000
Received: from [85.158.138.51:22510] by server-10.bemta-3.messagelabs.com id
	20/14-10411-709C5405; Tue, 04 Sep 2012 09:25:27 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1346750725!24444631!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM4Mzg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25208 invoked from network); 4 Sep 2012 09:25:26 -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;
	4 Sep 2012 09:25:26 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 04 Sep 2012 10:25:25 +0100
Message-Id: <5045E55A02000078000986E4@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 04 Sep 2012 10:26:18 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Sander Eikelenboom" <linux@eikelenboom.it>,
	"Jeremy Fitzhardinge" <jeremy@goop.org>,
	"Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>, <ehabkost@redhat.com>
References: <7914B38A4445B34AA16EB9F1352942F1012F0F6F4B98@SJCPMAILBOX01.citrite.net>
	<CC681CDD.3D966%keir.xen@gmail.com>
	<40501859.20120902104331@eikelenboom.it>
	<5044849002000078000982EA@nat28.tlf.novell.com>
	<4610648186.20120904090841@eikelenboom.it>
	<5045CDF302000078000985FB@nat28.tlf.novell.com>
	<4710608674.20120904101330@eikelenboom.it>
In-Reply-To: <4710608674.20120904101330@eikelenboom.it>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "wei.wang2@amd.com" <wei.wang2@amd.com>, Keir Fraser <keir.xen@gmail.com>,
	Santosh Jodh <Santosh.Jodh@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Using debug-key 'o:  Dump IOMMU p2m table,
 locks up machine
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.09.12 at 10:13, Sander Eikelenboom <linux@eikelenboom.it> wrote:
> Hmm don't know how to get the file/line, only thing i have found is:
> 
> serveerstertje:/boot# gdb xen-syms-4.2.0-rc4-pre
> GNU gdb (GDB) 7.0.1-debian
> Copyright (C) 2009 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
> and "show warranty" for details.
> This GDB was configured as "x86_64-linux-gnu".
> For bug reporting instructions, please see:
> <http://www.gnu.org/software/gdb/bugs/>...
> Reading symbols from /boot/xen-syms-4.2.0-rc4-pre...done.
> (gdb) x/i 0xffff82c48015c9ee
> 0xffff82c48015c9ee <context_switch+916>:        mov    %edx,%gs
> (gdb)

I'm not really a gdb expert, so I don't know off the top of my
head either. I thought I said in a previous reply that people
generally appear to use the addr2line utility for that purpose.

But the disassembly already tells us where precisely the
problem is: The selector value (0x0063) attempted to be put
into %gs is apparently wrong in the context of the current
GDT. Now, that's GDT_ENTRY_TLS_MIN on the Linux side,
and ought to be valid. I'm surprised the guest (and the current
process in it) survives this (as the failure here results in a failsafe
callback into the guest).

Looking at the Linux side of things, this has been that way
forever, and I think has always been broken: On x86-64, it
should also clear %gs here (since 32-bit processes use it for
their TLS, and there's nothing wrong for a 64-bit process to put
something in there either), albeit not via loadsegment(), but
through xen_load_gs_index(). And I neither see why on 32-bit
it only clears %gs - %fs can as much hold a selector that might
get invalidated with the TLS descriptor updates. Eduardo,
Jeremy, Konrad?

Jan


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

From xen-devel-bounces@lists.xen.org Tue Sep 04 09:25:55 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Sep 2012 09:25: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 1T8pO0-0007Ut-QN; Tue, 04 Sep 2012 09:25:32 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1T8pNz-0007Uo-Cm
	for xen-devel@lists.xen.org; Tue, 04 Sep 2012 09:25:31 +0000
Received: from [85.158.138.51:22510] by server-10.bemta-3.messagelabs.com id
	20/14-10411-709C5405; Tue, 04 Sep 2012 09:25:27 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1346750725!24444631!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM4Mzg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25208 invoked from network); 4 Sep 2012 09:25:26 -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;
	4 Sep 2012 09:25:26 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 04 Sep 2012 10:25:25 +0100
Message-Id: <5045E55A02000078000986E4@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 04 Sep 2012 10:26:18 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Sander Eikelenboom" <linux@eikelenboom.it>,
	"Jeremy Fitzhardinge" <jeremy@goop.org>,
	"Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>, <ehabkost@redhat.com>
References: <7914B38A4445B34AA16EB9F1352942F1012F0F6F4B98@SJCPMAILBOX01.citrite.net>
	<CC681CDD.3D966%keir.xen@gmail.com>
	<40501859.20120902104331@eikelenboom.it>
	<5044849002000078000982EA@nat28.tlf.novell.com>
	<4610648186.20120904090841@eikelenboom.it>
	<5045CDF302000078000985FB@nat28.tlf.novell.com>
	<4710608674.20120904101330@eikelenboom.it>
In-Reply-To: <4710608674.20120904101330@eikelenboom.it>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "wei.wang2@amd.com" <wei.wang2@amd.com>, Keir Fraser <keir.xen@gmail.com>,
	Santosh Jodh <Santosh.Jodh@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Using debug-key 'o:  Dump IOMMU p2m table,
 locks up machine
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.09.12 at 10:13, Sander Eikelenboom <linux@eikelenboom.it> wrote:
> Hmm don't know how to get the file/line, only thing i have found is:
> 
> serveerstertje:/boot# gdb xen-syms-4.2.0-rc4-pre
> GNU gdb (GDB) 7.0.1-debian
> Copyright (C) 2009 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
> and "show warranty" for details.
> This GDB was configured as "x86_64-linux-gnu".
> For bug reporting instructions, please see:
> <http://www.gnu.org/software/gdb/bugs/>...
> Reading symbols from /boot/xen-syms-4.2.0-rc4-pre...done.
> (gdb) x/i 0xffff82c48015c9ee
> 0xffff82c48015c9ee <context_switch+916>:        mov    %edx,%gs
> (gdb)

I'm not really a gdb expert, so I don't know off the top of my
head either. I thought I said in a previous reply that people
generally appear to use the addr2line utility for that purpose.

But the disassembly already tells us where precisely the
problem is: The selector value (0x0063) attempted to be put
into %gs is apparently wrong in the context of the current
GDT. Now, that's GDT_ENTRY_TLS_MIN on the Linux side,
and ought to be valid. I'm surprised the guest (and the current
process in it) survives this (as the failure here results in a failsafe
callback into the guest).

Looking at the Linux side of things, this has been that way
forever, and I think has always been broken: On x86-64, it
should also clear %gs here (since 32-bit processes use it for
their TLS, and there's nothing wrong for a 64-bit process to put
something in there either), albeit not via loadsegment(), but
through xen_load_gs_index(). And I neither see why on 32-bit
it only clears %gs - %fs can as much hold a selector that might
get invalidated with the TLS descriptor updates. Eduardo,
Jeremy, Konrad?

Jan


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

From xen-devel-bounces@lists.xen.org Tue Sep 04 09:40:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Sep 2012 09:40:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T8pbq-0007gI-7X; Tue, 04 Sep 2012 09:39: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 1T8pbp-0007gD-4Z
	for xen-devel@lists.xen.org; Tue, 04 Sep 2012 09:39:49 +0000
Received: from [85.158.138.51:20991] by server-4.bemta-3.messagelabs.com id
	58/AF-24831-46CC5405; Tue, 04 Sep 2012 09:39:48 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1346751587!22146807!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM4Mzg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4648 invoked from network); 4 Sep 2012 09:39:47 -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;
	4 Sep 2012 09:39:47 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 04 Sep 2012 10:39:47 +0100
Message-Id: <5045E8B802000078000986F7@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 04 Sep 2012 10:40:40 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Keir Fraser" <keir@xen.org>
References: <5045DA360200007800098688@nat28.tlf.novell.com>
	<CC6B803A.4A8E0%keir@xen.org>
In-Reply-To: <CC6B803A.4A8E0%keir@xen.org>
Mime-Version: 1.0
Content-Disposition: inline
Cc: wei.wang2@amd.com, Sander Eikelenboom <linux@eikelenboom.it>,
	George Dunlap <George.Dunlap@eu.citrix.com>,
	Santosh Jodh <santosh.jodh@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Using debug-key 'o:  Dump IOMMU p2m table,
 locks up machine
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.09.12 at 10:54, Keir Fraser <keir@xen.org> wrote:
> On 04/09/2012 09:38, "Jan Beulich" <JBeulich@suse.com> wrote:
> 
>>> My pragmatic take would be that: (a) Really long-running handlers that want
>>> to dump every page mapping of every domain are pretty bloody stupid, and yes
>>> we should consider if they are worthwhile at all; (b) moderately
>>> long-running but useful handlers which nonetheless take a long time to dump
>>> to Xen's console, I would consider a sysctl to allow dom0 to request dump
>>> into a supplied memory buffer.
>> 
>> At a first glance that sounds like a viable option, assuming that
>> the bulk of the time otherwise is being spent actually getting the
>> data out through the serial line. But if the long-running-ness is
>> in the nature of the keyhandler itself, then this wouldn't help
>> much though. And I'd be afraid that ought to be the common
>> case when not running with sync_console, since actual serial
>> output happens asynchronously and hence shouldn't affect the
>> latency of the keyhandler's completion too much.
> 
> Well then, have we actually seen problems with async serial output, a
> decent-sized serial output buffer, and the 'd'/'0' handlers? Because if not,
> we don't have a problem to be solved. :)

To a degree - we have seen (large) systems becoming unstable
after making use of these keys, but obviously people were
instructed to use the keys because the system already had some
sort of problem (e.g. were dead locked on some spin lock, and
after use of the debug keys additionally got their time screwed
up).

The 'o' key here just gets this to the extreme, which is why I'm
wondering whether it was a good decision to add it in the first
place. And the same would apply to EPT's 'D' key. The more that
these keys would presumably be used when a guest had a
problem, yet their use could render the whole system dead
(whereas 'd' and '0' generally get used when the host is in a
bad state already). Perhaps a minimal step would be to build/
enabled these only in debug=y builds? But really this functionality
should be exposed _only_ through the tools (similar to xenctx
and lsevtchn) imo (and along those lines I think 'e' should only
dump Dom0's event channels).

Jan


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

From xen-devel-bounces@lists.xen.org Tue Sep 04 09:40:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Sep 2012 09:40:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T8pbq-0007gI-7X; Tue, 04 Sep 2012 09:39: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 1T8pbp-0007gD-4Z
	for xen-devel@lists.xen.org; Tue, 04 Sep 2012 09:39:49 +0000
Received: from [85.158.138.51:20991] by server-4.bemta-3.messagelabs.com id
	58/AF-24831-46CC5405; Tue, 04 Sep 2012 09:39:48 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1346751587!22146807!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM4Mzg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4648 invoked from network); 4 Sep 2012 09:39:47 -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;
	4 Sep 2012 09:39:47 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 04 Sep 2012 10:39:47 +0100
Message-Id: <5045E8B802000078000986F7@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 04 Sep 2012 10:40:40 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Keir Fraser" <keir@xen.org>
References: <5045DA360200007800098688@nat28.tlf.novell.com>
	<CC6B803A.4A8E0%keir@xen.org>
In-Reply-To: <CC6B803A.4A8E0%keir@xen.org>
Mime-Version: 1.0
Content-Disposition: inline
Cc: wei.wang2@amd.com, Sander Eikelenboom <linux@eikelenboom.it>,
	George Dunlap <George.Dunlap@eu.citrix.com>,
	Santosh Jodh <santosh.jodh@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Using debug-key 'o:  Dump IOMMU p2m table,
 locks up machine
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.09.12 at 10:54, Keir Fraser <keir@xen.org> wrote:
> On 04/09/2012 09:38, "Jan Beulich" <JBeulich@suse.com> wrote:
> 
>>> My pragmatic take would be that: (a) Really long-running handlers that want
>>> to dump every page mapping of every domain are pretty bloody stupid, and yes
>>> we should consider if they are worthwhile at all; (b) moderately
>>> long-running but useful handlers which nonetheless take a long time to dump
>>> to Xen's console, I would consider a sysctl to allow dom0 to request dump
>>> into a supplied memory buffer.
>> 
>> At a first glance that sounds like a viable option, assuming that
>> the bulk of the time otherwise is being spent actually getting the
>> data out through the serial line. But if the long-running-ness is
>> in the nature of the keyhandler itself, then this wouldn't help
>> much though. And I'd be afraid that ought to be the common
>> case when not running with sync_console, since actual serial
>> output happens asynchronously and hence shouldn't affect the
>> latency of the keyhandler's completion too much.
> 
> Well then, have we actually seen problems with async serial output, a
> decent-sized serial output buffer, and the 'd'/'0' handlers? Because if not,
> we don't have a problem to be solved. :)

To a degree - we have seen (large) systems becoming unstable
after making use of these keys, but obviously people were
instructed to use the keys because the system already had some
sort of problem (e.g. were dead locked on some spin lock, and
after use of the debug keys additionally got their time screwed
up).

The 'o' key here just gets this to the extreme, which is why I'm
wondering whether it was a good decision to add it in the first
place. And the same would apply to EPT's 'D' key. The more that
these keys would presumably be used when a guest had a
problem, yet their use could render the whole system dead
(whereas 'd' and '0' generally get used when the host is in a
bad state already). Perhaps a minimal step would be to build/
enabled these only in debug=y builds? But really this functionality
should be exposed _only_ through the tools (similar to xenctx
and lsevtchn) imo (and along those lines I think 'e' should only
dump Dom0's event channels).

Jan


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

From xen-devel-bounces@lists.xen.org Tue Sep 04 10:54:18 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Sep 2012 10: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 1T8qlQ-00084E-5F; Tue, 04 Sep 2012 10:53:48 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <joej@edwyse.com>) id 1T8p9A-0007Np-CA
	for xen-devel@lists.xen.org; Tue, 04 Sep 2012 09:10:12 +0000
X-Env-Sender: joej@edwyse.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1346749794!7056668!1
X-Originating-IP: [69.46.34.206]
X-SpamReason: No, hits=1.4 required=7.0 tests=INFO_TLD,
	ML_RADAR_SPEW_LINKS_22,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22569 invoked from network); 4 Sep 2012 09:09:54 -0000
Received: from mail.edwyse.com (HELO smtp.edwyse.com) (69.46.34.206)
	by server-5.tower-27.messagelabs.com with SMTP;
	4 Sep 2012 09:09:54 -0000
Received: from localhost (unknown [127.0.0.1])
	by smtp.edwyse.com (Postfix) with ESMTP id 613182755;
	Tue,  4 Sep 2012 09:09:52 +0000 (UTC)
X-Virus-Scanned: amavisd-new at edwyse.com
Received: from smtp.edwyse.com ([127.0.0.1])
	by localhost (ewcs9.ewcs.com [127.0.0.1]) (amavisd-new, port 10026)
	with ESMTP id 5pwtHxqzT+vN; Tue,  4 Sep 2012 02:09:47 -0700 (PDT)
Received: from questor.julianfamily.org (50-47-12-159.evrt.wa.frontiernet.net
	[50.47.12.159]) by smtp.edwyse.com (Postfix) with ESMTP;
	Tue,  4 Sep 2012 02:09:47 -0700 (PDT)
Message-ID: <5045C55A.2010301@edwyse.com>
Date: Tue, 04 Sep 2012 02:09:46 -0700
From: Joe Julian <joej@edwyse.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120828 Thunderbird/15.0
MIME-Version: 1.0
To: Ian Campbell <ijc@hellion.org.uk>
References: <50454404.5080503@edwyse.com>
	<1346747064.6712.6.camel@zakaz.uk.xensource.com>
In-Reply-To: <1346747064.6712.6.camel@zakaz.uk.xensource.com>
X-Mailman-Approved-At: Tue, 04 Sep 2012 10:53:45 +0000
Cc: Wei Wang <wei.wang2@amd.com>, 684661@bugs.debian.org,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [Pkg-xen-devel] Bug#684661: Xen panic on 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-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 09/04/2012 01:24 AM, Ian Campbell wrote:
> On Mon, 2012-09-03 at 16:57 -0700, Joe Julian wrote:
>> I'm also getting the same error. I don't have anything with serial
>> ports, but hopefully this will be of some use.
> Thanks.
>
> Wei does this give any hints to this bug? This is the Xen BUG at
> pci_amd_iommu.c:33 one I CCd you on before http://bugs.debian.org/684661
>
> Joe, are you able to press Shift-PgUp to scroll up to the top part of
> the trace? (I must confess I'm not sure that works for Xen, perhaps its
> a Linux-ism).
>
> Looks like you are already using the vga= option to increase the number
> of lines displayed.
>
> Ian.
>
No, once it's hung there it's stuck (doesn't even reboot in 5 seconds 
like it claims).

This was actually the Fedora 17 build, 4.1.3-2 and coincided with me 
having to remove 2 gig (bringing it down to 2 remaining gig) from an 
Asus K8N-DL due to memory failure. I tried rolling back to 4.1.2-15 with 
the same result. I found an old reference to this motherboard suggesting 
that with less than 3 gig, there's an iommu problem: 
http://www.gentoo-wiki.info/Asus_K8N-DL

I'll get this memory replaced and see if that has any effect.


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

From xen-devel-bounces@lists.xen.org Tue Sep 04 10:54:18 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Sep 2012 10: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 1T8qlQ-00084E-5F; Tue, 04 Sep 2012 10:53:48 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <joej@edwyse.com>) id 1T8p9A-0007Np-CA
	for xen-devel@lists.xen.org; Tue, 04 Sep 2012 09:10:12 +0000
X-Env-Sender: joej@edwyse.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1346749794!7056668!1
X-Originating-IP: [69.46.34.206]
X-SpamReason: No, hits=1.4 required=7.0 tests=INFO_TLD,
	ML_RADAR_SPEW_LINKS_22,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22569 invoked from network); 4 Sep 2012 09:09:54 -0000
Received: from mail.edwyse.com (HELO smtp.edwyse.com) (69.46.34.206)
	by server-5.tower-27.messagelabs.com with SMTP;
	4 Sep 2012 09:09:54 -0000
Received: from localhost (unknown [127.0.0.1])
	by smtp.edwyse.com (Postfix) with ESMTP id 613182755;
	Tue,  4 Sep 2012 09:09:52 +0000 (UTC)
X-Virus-Scanned: amavisd-new at edwyse.com
Received: from smtp.edwyse.com ([127.0.0.1])
	by localhost (ewcs9.ewcs.com [127.0.0.1]) (amavisd-new, port 10026)
	with ESMTP id 5pwtHxqzT+vN; Tue,  4 Sep 2012 02:09:47 -0700 (PDT)
Received: from questor.julianfamily.org (50-47-12-159.evrt.wa.frontiernet.net
	[50.47.12.159]) by smtp.edwyse.com (Postfix) with ESMTP;
	Tue,  4 Sep 2012 02:09:47 -0700 (PDT)
Message-ID: <5045C55A.2010301@edwyse.com>
Date: Tue, 04 Sep 2012 02:09:46 -0700
From: Joe Julian <joej@edwyse.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120828 Thunderbird/15.0
MIME-Version: 1.0
To: Ian Campbell <ijc@hellion.org.uk>
References: <50454404.5080503@edwyse.com>
	<1346747064.6712.6.camel@zakaz.uk.xensource.com>
In-Reply-To: <1346747064.6712.6.camel@zakaz.uk.xensource.com>
X-Mailman-Approved-At: Tue, 04 Sep 2012 10:53:45 +0000
Cc: Wei Wang <wei.wang2@amd.com>, 684661@bugs.debian.org,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [Pkg-xen-devel] Bug#684661: Xen panic on 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-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 09/04/2012 01:24 AM, Ian Campbell wrote:
> On Mon, 2012-09-03 at 16:57 -0700, Joe Julian wrote:
>> I'm also getting the same error. I don't have anything with serial
>> ports, but hopefully this will be of some use.
> Thanks.
>
> Wei does this give any hints to this bug? This is the Xen BUG at
> pci_amd_iommu.c:33 one I CCd you on before http://bugs.debian.org/684661
>
> Joe, are you able to press Shift-PgUp to scroll up to the top part of
> the trace? (I must confess I'm not sure that works for Xen, perhaps its
> a Linux-ism).
>
> Looks like you are already using the vga= option to increase the number
> of lines displayed.
>
> Ian.
>
No, once it's hung there it's stuck (doesn't even reboot in 5 seconds 
like it claims).

This was actually the Fedora 17 build, 4.1.3-2 and coincided with me 
having to remove 2 gig (bringing it down to 2 remaining gig) from an 
Asus K8N-DL due to memory failure. I tried rolling back to 4.1.2-15 with 
the same result. I found an old reference to this motherboard suggesting 
that with less than 3 gig, there's an iommu problem: 
http://www.gentoo-wiki.info/Asus_K8N-DL

I'll get this memory replaced and see if that has any effect.


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

From xen-devel-bounces@lists.xen.org Tue Sep 04 10:54:21 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Sep 2012 10:54:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T8qlP-000845-4s; Tue, 04 Sep 2012 10:53:47 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ijc@hellion.org.uk>) id 1T8oRL-0005Uc-TT
	for xen-devel@lists.xen.org; Tue, 04 Sep 2012 08:25:09 +0000
Received: from [85.158.138.51:56309] by server-10.bemta-3.messagelabs.com id
	A1/A1-10411-6DAB5405; Tue, 04 Sep 2012 08:24:54 +0000
X-Env-Sender: ijc@hellion.org.uk
X-Msg-Ref: server-9.tower-174.messagelabs.com!1346747089!28527322!1
X-Originating-IP: [80.68.92.230]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29784 invoked from network); 4 Sep 2012 08:24:49 -0000
Received: from aaar.vm.bytemark.co.uk (HELO aaar.vm.bytemark.co.uk)
	(80.68.92.230) by server-9.tower-174.messagelabs.com with SMTP;
	4 Sep 2012 08:24:49 -0000
Received: from localhost (unknown [127.0.0.1])
	by aaar.vm.bytemark.co.uk (Postfix) with ESMTP id 2E82D14910B;
	Tue,  4 Sep 2012 08:24:44 +0000 (UTC)
Received: from aaar.vm.bytemark.co.uk ([127.0.0.1])
	by localhost (aaar.vm.bytemark.co.uk [127.0.0.1]) (amavisd-new,
	port 10024)
	with ESMTP id 4OeEDTNlJ64S; Tue,  4 Sep 2012 09:24:43 +0100 (BST)
Received: from hopkins.hellion.org.uk
	(cpc22-cmbg14-2-0-cust482.5-4.cable.virginmedia.com [86.6.25.227])
	(using TLSv1 with cipher AES256-SHA (256/256 bits))
	(No client certificate requested)
	by aaar.vm.bytemark.co.uk (Postfix) with ESMTP id 39A641418B5;
	Tue,  4 Sep 2012 09:24:36 +0100 (BST)
Received: from firewall.ctxuk.citrix.com ([62.200.22.2] helo=[10.80.2.42])
	by hopkins.hellion.org.uk with esmtpsa (SSL3.0:RSA_AES_256_CBC_SHA1:32)
	(Exim 4.72) (envelope-from <ijc@hellion.org.uk>)
	id 1T8oQx-0001U5-7m; Tue, 04 Sep 2012 09:24:34 +0100
Message-ID: <1346747064.6712.6.camel@zakaz.uk.xensource.com>
From: Ian Campbell <ijc@hellion.org.uk>
To: Joe Julian <joej@edwyse.com>, 684661@bugs.debian.org
Date: Tue, 04 Sep 2012 09:24:24 +0100
In-Reply-To: <50454404.5080503@edwyse.com>
References: <50454404.5080503@edwyse.com>
Content-Type: multipart/mixed; boundary="=-tkzN+QYEI59Tez8y2Lgk"
X-Mailer: Evolution 3.4.3-1 
Mime-Version: 1.0
X-SA-Exim-Connect-IP: 62.200.22.2
X-SA-Exim-Mail-From: ijc@hellion.org.uk
X-SA-Exim-Scanned: No (on hopkins.hellion.org.uk);
	Message bigger than SAmaxbody (256000)
X-Mailman-Approved-At: Tue, 04 Sep 2012 10:53:45 +0000
Cc: Wei Wang <wei.wang2@amd.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [Pkg-xen-devel] Bug#684661: Xen panic on 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>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--=-tkzN+QYEI59Tez8y2Lgk
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit

On Mon, 2012-09-03 at 16:57 -0700, Joe Julian wrote:
> I'm also getting the same error. I don't have anything with serial 
> ports, but hopefully this will be of some use.

Thanks.

Wei does this give any hints to this bug? This is the Xen BUG at
pci_amd_iommu.c:33 one I CCd you on before http://bugs.debian.org/684661

Joe, are you able to press Shift-PgUp to scroll up to the top part of
the trace? (I must confess I'm not sure that works for Xen, perhaps its
a Linux-ism).

Looks like you are already using the vga= option to increase the number
of lines displayed.

Ian.

-- 
Ian Campbell
Current Noise: High On Fire - Speak In Tongues

QOTD:
	How can I miss you if you won't go away?

--=-tkzN+QYEI59Tez8y2Lgk
Content-Type: image/jpeg; name="IMG_20120903_165005.jpg"
Content-Disposition: attachment; filename="IMG_20120903_165005.jpg"
Content-Transfer-Encoding: base64

/9j/4AAQSkZJRgABAQEASABIAAD/4QJgRXhpZgAATU0AKgAAAAgACAEPAAIAAAAESFRDAAEQAAIA
AAAIAAAAbgEaAAUAAAABAAAAdgEbAAUAAAABAAAAfgEoAAMAAAABAAIAAAITAAMAAAABAAEAAIdp
AAQAAAABAAAAhoglAAQAAAABAAABXgAAAABQQzM2MTAwAAAAAEgAAAABAAAASAAAAAEAC4gnAAMA
AAABAGQAAJAAAAcAAAAEMDIyMJADAAIAAAAUAAABEJAEAAIAAAAUAAABJJEBAAcAAAAEAQIDAJIK
AAUAAAABAAABOKAAAAcAAAAEMDEwMKABAAMAAAABAAEAAKACAAQAAAABAAAIUaADAAQAAAABAAAJ
rKAFAAQAAAABAAABQAAAAAAyMDEyOjA5OjAzIDE2OjUwOjA0ADIwMTI6MDk6MDMgMTY6NTA6MDQA
AAAB7AAAAGQAAgABAAIAAAAEUjk4AAACAAcAAAAEMDEwMAAAAAAACwAAAAEAAAADAgIAAAABAAIA
AAACTgAAAAACAAUAAAADAAAB6AADAAIAAAACVwAAAAAEAAUAAAADAAACAAAFAAEAAAABAAAAAAAG
AAUAAAABAAACGAAHAAUAAAADAAACIAASAAIAAAAHAAACOAAbAAcAAAALAAACQAAdAAIAAAALAAAC
TAAAAAAAAAAvAAAAAQAAADEAAAABAAAOugAAAGQAAAB6AAAAAQAAABQAAAABAAANaAAAAGQAAABT
AAAAAQAAABcAAAABAAAAMgAAAAEAAAAEAAAAAVdHUy04NAAAQVNDSUkAAABHUFMAMjAxMjowOTow
MwAA/+EHy2h0dHA6Ly9ucy5hZG9iZS5jb20veGFwLzEuMC8APD94cGFja2V0IGJlZ2luPSfvu78n
IGlkPSdXNU0wTXBDZWhpSHpyZVN6TlRjemtjOWQnPz4KPHg6eG1wbWV0YSB4bWxuczp4PSdhZG9i
ZTpuczptZXRhLyc+CjxyZGY6UkRGIHhtbG5zOnJkZj0naHR0cDovL3d3dy53My5vcmcvMTk5OS8w
Mi8yMi1yZGYtc3ludGF4LW5zIyc+CgogPHJkZjpEZXNjcmlwdGlvbiB4bWxuczpleGlmPSdodHRw
Oi8vbnMuYWRvYmUuY29tL2V4aWYvMS4wLyc+CiAgPGV4aWY6TWFrZT5IVEM8L2V4aWY6TWFrZT4K
ICA8ZXhpZjpNb2RlbD5QQzM2MTAwPC9leGlmOk1vZGVsPgogIDxleGlmOlhSZXNvbHV0aW9uPjcy
PC9leGlmOlhSZXNvbHV0aW9uPgogIDxleGlmOllSZXNvbHV0aW9uPjcyPC9leGlmOllSZXNvbHV0
aW9uPgogIDxleGlmOlJlc29sdXRpb25Vbml0PkluY2g8L2V4aWY6UmVzb2x1dGlvblVuaXQ+CiAg
PGV4aWY6WUNiQ3JQb3NpdGlvbmluZz5DZW50ZXJlZDwvZXhpZjpZQ2JDclBvc2l0aW9uaW5nPgog
IDxleGlmOklTT1NwZWVkUmF0aW5ncz4KICAgPHJkZjpTZXE+CiAgICA8cmRmOmxpPjEwMDwvcmRm
OmxpPgogICA8L3JkZjpTZXE+CiAgPC9leGlmOklTT1NwZWVkUmF0aW5ncz4KICA8ZXhpZjpFeGlm
VmVyc2lvbj5FeGlmIFZlcnNpb24gMi4yPC9leGlmOkV4aWZWZXJzaW9uPgogIDxleGlmOkRhdGVU
aW1lT3JpZ2luYWw+MjAxMjowOTowMyAxNjo1MDowNDwvZXhpZjpEYXRlVGltZU9yaWdpbmFsPgog
IDxleGlmOkRhdGVUaW1lRGlnaXRpemVkPjIwMTI6MDk6MDMgMTY6NTA6MDQ8L2V4aWY6RGF0ZVRp
bWVEaWdpdGl6ZWQ+CiAgPGV4aWY6Q29tcG9uZW50c0NvbmZpZ3VyYXRpb24+CiAgIDxyZGY6U2Vx
PgogICAgPHJkZjpsaT5ZIENiIENyIC08L3JkZjpsaT4KICAgPC9yZGY6U2VxPgogIDwvZXhpZjpD
b21wb25lbnRzQ29uZmlndXJhdGlvbj4KICA8ZXhpZjpGb2NhbExlbmd0aD40LjkgbW08L2V4aWY6
Rm9jYWxMZW5ndGg+CiAgPGV4aWY6Rmxhc2hQaXhWZXJzaW9uPkZsYXNoUGl4IFZlcnNpb24gMS4w
PC9leGlmOkZsYXNoUGl4VmVyc2lvbj4KICA8ZXhpZjpDb2xvclNwYWNlPnNSR0I8L2V4aWY6Q29s
b3JTcGFjZT4KICA8ZXhpZjpQaXhlbFhEaW1lbnNpb24+MjQ0ODwvZXhpZjpQaXhlbFhEaW1lbnNp
b24+CiAgPGV4aWY6UGl4ZWxZRGltZW5zaW9uPjMyNjQ8L2V4aWY6UGl4ZWxZRGltZW5zaW9uPgog
IDxleGlmOkdQU1ZlcnNpb25JRCAvPgogIDxleGlmOkludGVyb3BlcmFiaWxpdHlJbmRleD5OPC9l
eGlmOkludGVyb3BlcmFiaWxpdHlJbmRleD4KICA8ZXhpZjpJbnRlcm9wZXJhYmlsaXR5VmVyc2lv
bj40NywgNDksIDM3LjcwPC9leGlmOkludGVyb3BlcmFiaWxpdHlWZXJzaW9uPgogIDxleGlmOkdQ
U0xvbmdpdHVkZVJlZj5XPC9leGlmOkdQU0xvbmdpdHVkZVJlZj4KICA8ZXhpZjpHUFNMb25naXR1
ZGUgcmRmOnBhcnNlVHlwZT0nUmVzb3VyY2UnPgogIDwvZXhpZjpHUFNMb25naXR1ZGU+CiAgPGV4
aWY6R1BTQWx0aXR1ZGVSZWY+U2VhIGxldmVsPC9leGlmOkdQU0FsdGl0dWRlUmVmPgogIDxleGlm
OkdQU0FsdGl0dWRlPjgzPC9leGlmOkdQU0FsdGl0dWRlPgogIDxleGlmOkdQU1RpbWVTdGFtcD4y
Mzo1MDowNC4wMDwvZXhpZjpHUFNUaW1lU3RhbXA+CiAgPGV4aWY6R1BTTWFwRGF0dW0+V0dTLTg0
PC9leGlmOkdQU01hcERhdHVtPgogIDxleGlmOkdQU1Byb2Nlc3NpbmdNZXRob2Q+MTEgYnl0ZXMg
dW5kZWZpbmVkIGRhdGE8L2V4aWY6R1BTUHJvY2Vzc2luZ01ldGhvZD4KICA8ZXhpZjpHUFNEYXRl
U3RhbXA+MjAxMjowOTowMzwvZXhpZjpHUFNEYXRlU3RhbXA+CiAgPGV4aWY6SW50ZXJvcGVyYWJp
bGl0eUluZGV4PlI5ODwvZXhpZjpJbnRlcm9wZXJhYmlsaXR5SW5kZXg+CiAgPGV4aWY6SW50ZXJv
cGVyYWJpbGl0eVZlcnNpb24+MDEwMDwvZXhpZjpJbnRlcm9wZXJhYmlsaXR5VmVyc2lvbj4KIDwv
cmRmOkRlc2NyaXB0aW9uPgoKPC9yZGY6UkRGPgo8L3g6eG1wbWV0YT4KPD94cGFja2V0IGVuZD0n
cic/Pgr/2wBDAAMCAgMCAgMDAwMEAwMEBQgFBQQEBQoHBwYIDAoMDAsKCwsNDhIQDQ4RDgsLEBYQ
ERMUFRUVDA8XGBYUGBIUFRT/wgALCAmsCFEBAREA/8QAHAAAAAcBAQAAAAAAAAAAAAAAAAECBAUG
BwMI/9oACAEBAAAAAcGbJClGZOEgwkL58yLkpC1mYILMcCXyJSu61EYBAEAtASsgnonoEEShw6L4
GY6GpAUQMIUEqLk2Sk0qUSV9VhPRJr6pbAJSZvVq59C5GsiUnl1UhREjskjWg1kk1Nz7cy6JIA0B
aFDglJcEkSkpUEKUQMKSDSRgAgCStKgZGkuiQCBgKSZKCiSrkolICQFJUQIjJSDBo6BIBgSLVKer
wycGjoAZG05duHJJdevNShz7dlMua+YC3ThJdkEZERjn1HNYJHQ+XRSeSujdam5LT1WrknukjIL5
kZceCEGkGSx06ISsz7LS2QRJNTvslHcuRrHNRI6q5LQRdi5dS5dDIlDiTpHPoXPoAQUhY4cRzSEI
MAGQMgDHPqgKIGaSMJC0gwQAMgZhJpJQUQJSVGlIMwgwlaFoWkJWQAUCIAphnwPo7JLhJrBBJckG
3JKiWS0qLqo+CEJWA6WpPRPM1oJaEmCCkp6HxWEdCPka+SeaunbkglAzQhaUgJ5cyIAEYMwZGFAI
IiMGawDPmolICiCTBAKSAEgwSiSSgRmgwAZoMkGEgEYBAjMECMAGACAMgYAIAyAMEYBEoAgDBGDA
IgDMgAQCgCABGAYIxamTVkhYCiWDSCIhzBAAjAMwoIIiMGoKIgkKSSiIlEZpANJmlREACAJQBAyJ
REoEAZAEAYIAAEYNSQRGDIGQMEZkDIjNIURKCTUgdEkZoNaS6oPoOfQFy6p5AgZAwQBgAgZGAYBA
gYABAGCAAMAEDAIGADAAIAyABkADABEYMAEAYtzRhFk4dpIOXXfgln2b9kxpEYCTMxPykZCcAAFS
Fngo21Iq8xP1TnbIaDtbioyVmqrK5MqtZpGrXNxyoknYabEkq2WiOpPa9Ut5bKdH3iOqdulqHFkQ
BkADIyB99Jna3nvIIAVaNDpNb03jm9wtWbI0ur0vS3OZWO855FadDUHQJzMpPRKTWNP5ZZJ6hXqv
ptV46AUHNJTULYjIoRJAAgYIGRgAAGQBkAAAAAADIAwQAABggZAGRkAZAAyMAgDIyUQBkAYt/OOh
nGhkaXXW2M+ElVp/OZd/n8cgdXhN+vdWjcZXLFOa+k+unyXCDtPGsWo4bs9OBsbeBny4NpFVesrV
j2irtleht6nEu2WoVuz53z1HPbbGSLASURMsW2ZcUEaTBlOWFhHPnsPPKuuRz50hIf7FVbnEIdtZ
WqWdFcszANnUhTbtHw080eV6wOqddo2OeQpT9duFQt9GibRJ0oamzrM9V3fGiMACMAjIKIAGpABg
iMGRggCMyMGkwFIAUQAUkAGQBBSTBKBA0mDI0mZGZEZ3Js1gprYsjf6X0zLQ4uv6O8PKK/rGb1tI
vlnZQFq7VesW+0ZPNoqKUyey0a7lBO5BdSt5022iHRKOqdcSqk/1bxEzlVls9G1WmV6/xPCaJ7T7
DM0a3VS5IrM304RMxkLFJkACc7FGKg9Gioao3ynVh8qEAktsqts5w3d13qtuOqWVDHhLOqZbk12W
6ohbP2pdtEE9jSn8k1ysWbP2t5z9pokFYlP6jZLDldEJaQACAUkBRAKIEYCQtAMyJQBpNSSUEgGA
DIyIzIlESgSkqIjIAyCVGDIAAro04QNg1rIj2HnlulxVP02u27M63r2b1knGw0qJVqdM4Vib0DLW
/SIQchsdOuaIbrIHVbkdPs6Y/jKu6RdiqsysoOazzS8yi9gozfQMrVq9Buq4yTqtwp1y5VyaM4Ca
ytggAkmpxuGeRPfVsr636lRcNZO9LJMptFHu3CM6d5Oj3U6bbmzVtJPaXcWsJNcXdcsL2k3JtGd4
vnYco1qvWfPrdDZ/ab7k+tVOzqI6pnyAaTMJURgAzSDIwkAyUQBGRgwpIMiMgogCBmjohSTCDUAD
BkCAAAMAjI0dE3PkygpfTqf3uraDtdcfzGdXij87hncSjtqfBELoeawt3Ow5ZKPKVwJ1oczyrdk7
1Sedw3CfRUbW4qctJxcTa+VQtb+lxOjZUrYajWdKZR7t24rlib1/pY6xF3ZtR7lKUKrNyQYCg40q
fb1y95bG7A3VkXbtXEF0uN+q9W0RGf2uz5620iu06+OKFL3WixGix9Eus5nfW/VOuaJwz+9y+VOd
KrdHvMXUpm551Y78zplxZNs64kZpMjBqNBkFBIStJkZAwRgzIEDMAl81kZGgzBKIlAiMjUkAAJWk
lJMAAGkGLnwZQarFIo4Kfya2SKzNwsixh0hcvYmUZOwEdNykRBhKUmHk1GNZUoxzJQyZVg1kTjHE
jFJkeLBy8izdMeshyYP3TFMhxaOkcebxpzd8ePTsz5cwSkqSOnV0OLhvxcdubfmggZrcp5rVxLsh
HUuSlAjJKlJT0IloSsIUvmXZHEunFXTmOxoMFxIkmZkZdO/AdU819m478E8+gSEqJQANSCMwRKSo
GbpHFwlu4Xx4kDCTJZAyNCgEqJSQDMiAuTdpCE7fJTzfuTTybnx6HHISZyElDN1pAJACpOVghPx8
ZPda/ITFfjiSQIwRKMgoISsgAc9Yqpxt0ZAWR1U39lrcCCNBgkkdksVVhEmOikESrJbalFXuPptw
laQ6utbqXAzNJkYBgGgzM+ZLVZr3TYLQ+FBuVjzw9BrlAbqSSgFgIUQSB3U2I+ltvlaqeiHnNus1
DbaBEZo1WgwDBKUpISonSWhqJYXOaGeaXWwZ3aX6smZpCgRkDM0AgAoJMKSaVEV14M4NV9fxsq3e
zCV9YjtWG9kocOkutr0TJm5tuc8xigJPS1RpynKBs4rVi4ts4jySF8zMd5oox85imdtj6+kS+osn
HE30HYI1pMRMpl8QQIiNJ9diTWoh5EwlzTTUFLa3AWONTIRspDv3EBaMorYJRpAORtLdq5mYCs3p
efpOQ2Kn3uIaPifVa1pqVuzanmg1AiXKX3pTpawwVEuM1mCer3ZqPfGUaJF/QdBaUy7ZzTjIySZr
mNBcUmbn4DPrhN5cQcX6wwM0xklyNLvKKPc8traDUEKBKNICTUgyI+iUmaTF24Nq+/2/Kk6u7yy6
prV6lF5hTNZo9Q5nNadNZZeSq9Kv1ZroFp0iq3PpS7UcSmX70u4ZBDpSZJUR6Jd01OyNIOgWONhE
nYtWqlvFXsQaRk+4pNxyeAQkkGYEltlYpmpNInOZJVdIp7Zqdc+dbmuhwVhc0q4ZVUkpBg1DQrU6
p9mZx2fdO0Ok5Pbqhc20S8cdq3bCpdqzmkJAABix6nWYq2NYmjJdRnNUntNXtnKBdu31NuaajZKD
RiBkAo79as7fW7jX6iXWP5rlNybjnXZzp2qtyZQdgx6DSZGtKQFEZAEYBAyMyIxdeHCvyO3ZGw2W
TyO98aVoMVaaBSNcptL4r1lFkzK4FU6tJtIwdLPplVuC6bZ+kXyl3tIt2QQ/NBmaC6bA6hoGckql
VJ1lCpVP6xTbsdSsa2kRZO9DvGWVhJoBGSnG1VGm3WyVaj2JFWITWyUi98a7LdelctDig3jLKmgJ
UZKVpkrMUbjcIXObK5o/NUjttGvDaLdnKU22rqFozmnIURGRrmrfZ6jzsgyizy2cc1PtirlrjkoE
xULOmFm86qvMGRgK0C4Z09kpJ7kVqlsxCpPbs57Sz1TWfq88/wA6veXVhQIGRGokgKIlA0kogCBn
cuPCvvNbrkdorKJnow5Kj2quwmiZtAJ6ak7l6LPScHm99rlaJUlpDuL5zJVW1dKvNPorNWCVJNST
Xo87zr9idxGaW6JrKTf6LOV5jcGtNuD2kyFngM/jEpSoiM5Ta61QdPexGXT/ACrXNXbQrhVILQo+
iXWbz/vfapn0ckEZdEdLTp81ldkloXLnrmtoNdu0OrVXSOWe2m0Z7x0at0BkkGRGDl9UTUpifgs1
D+GQO81otUrWgIoNgtlFb36CpLdBkFJNUpo/enS1ggM+W5jUDverPB0y9taVZbFQ561RGfsSA6Eh
SDCTBGAo0AwkjM0XXi2gROzrLoymnvdoygJSN7dK8jkJiytmMk6r0MvlzMhLzFfKxRMfMdIJzNQT
PkSiSokqfzAiZJzERyVciC3knHc5Nuzd943rIR7blyMiURjvJJZO3TaPQEAz7vUce5tOjhsh3zbc
0pIJ6BVuvrzOK314tSBAEt0kgrmakks2vIwlRGC6LWQBc0mQJQ7ECXzJZkS+KEqAIKBdlpCkJQaT
MdFGhQI1IMxxIgRgLSAQCuajSoEDJJmE3Pm1r6Hknw68nDp1w4NSIu0UlCpRZnGkhBKSRGagqUaN
SAMjnXVa4pMKl4vmZkYIkKIBaAoWeUqzAJIyI0HzCiMGZGa0oAOXuVahL7wpVmnqUL1X+0+wgLUu
j19JdLFaavpq6DxuVLVb+dduXOGoWhc2ExmXfSH9bgNCq1CSvgZAjBmYMEgzIjMGDBEYWhSSBGRA
wYWkAwlRBKiUFINJqAMglJqMkgAzCDMzSCWCQZpMC5821fTfLDWLdBznZ0ENyhIS40CC5npD59D0
jq1SoMUEbt63capRarICNdPuFqt2VR7Il2fT8wh+/eMe94fvJ8ouW7QzIG52xlU4PrGKlWfJ0mGa
p6TLhcLPdYZ914xljOB0aXrVf1mr0LWo2pSVoibJRrxTou2xFceQQ155TJiDs3So3LPOGgVJr1u2
Z61SWelZRWbR30NpT7vkybpkiAklglEZEAADAAMAyAMgpBmkGCMyIyMAyCTUCNSARhQUhKgCMgSg
AASiBGRgjBGhSLvzb17tumewmvyebTklVLXYVUHONTg875pse0dsqvDqC5vF5xXeb3WnMS10Go51
pMrnF26xcDo8HRqintqF9zZlfCpsjaaJMv8AhC3VdOzHiU5uWewWoco501eiZLOs449tWtHOt2eK
g7G3k8wthVDT+GUXHRscabRSKBrMnkur832VTExV9EqnWfkH1ItDHlOUa55DcW+eutJrqNVxRxr8
Nn0bo8o8ptqzKozNc5kaVBJgGSkmCMjBKIlEADMiMEAoggzMjIGZKQoEFJMjAMGSSMzSkLNIWRpB
kDIjNBKBKufHhX++95tV9hseTWaSz69M7BV811WFzzgUxui8/wBErka3lX9FonNzpUnXKvs+aHoj
+h3XJG8psdfyOG4KntlyU9Yzpxde0BN0CDu1mrkLR25SO55lXtvzrroOXaX0auK5lDNWm2CjFdHW
f6LB2zMrR0od+4ZZZtWxFruGe0zR5zLNrzTSIJxQJDR8V7PbNfqsuCu3XPdBgGlGjL/IZZNbFhUz
rEByoTnW+dJueWMrflvIAJURGARmSgRqSCMgRLAMiMgDUhSFpMgYBGAoiBpAUaTMAjIyABAwpJkZ
AAJURgJWdzb8K/015nV9Sim/Xpwlqi+KjaXQqnzPQbi3EzVS4Szul0VD3UJFGYakiIsKYedhFxts
iq7QOBy2wsIO9ZI21NulCiirGwr+ftkz+257A67nlR1g3jZh3YZY07a5NZBLaK7plseReTsC67Pw
yK56TjzHaaLnuuymPaZJkxm01yYVX80ummZ/ceVURbqfYJpOdOlZ3e9IyDhsjKi3XvXavolbzlNh
qnBKiMEoiABkAFEokrIjAMyIGRGZpMEYIjUkwSkqIGRkYBLIjBJJYMjBGlQJQSQIEoEBzvbdrBc5
W3w8nBTsg5bsoTtzbSFX5oOwqJ4+dwTbsuKiwuzykJBzEhDTfHkUtGEtu2hkkqf68ZGFZTKwzmG0
ROCEYJS9nGTSZYxcnKNOHNBR3JUu7hyl+zPX43N4nihcv1hnT+ObyzeOkO8b2f8AHm6TwLq2Zd3v
BwppwdturgmaA27vOTZ4vgOqOHYmwHMjJHVJAjUFcjPmakG4ShJmrpx6d+XLsjiYI3A4dO7VTjjx
dHxdI4uFtku23Nwnm6Mmjg2i3DUJU74t1ug2cm3T3boI0kok3fi2geDmVbu2Uh2ck3b8ejdxE8iN
KzNZEfMB5YIuPsSq9ITMDwsjES7SKnhXIvmBJzkLZ+ld52GAirAmvqtEfP8AVNTsSK5Z38I8Y1pP
Mw4uLKs2l/T3lshJexViJsnGsWztVayYc3rlSrLPUld3gYq7ilQCFpJXe/P89mrhS4rQo2gtyN7o
6c6t9qzlGj1um6K8qt2FJtEpW6to0DRdGk881BBZBeLFlUIpEnqrfKWxvdDsWd2qb5ZzoasjjSU9
1lxlFtu9BhNTisv1CYp9uRW510zouiNc00mSzbUGchi2g2LI5rQKRnoLUZPGrNpgr0n340XQ4zJ+
IIgCu3NvXuVyvVIvtTtTaX48nUKmkaFRKryI0qBmQR0LTbnVqdrLHMNLd0Nzd4mZgp2urk69SzZl
rcvT7AzQ75c6FrtZyy5alnsxD3etPe0PYazZI1eVxCAd40eDzzX42h2+WrsHpsO+hpmJYunGbyEf
bbE5g56Jc9mE5TeFmjKo6gm1khZq/tOcpAWOJ4zGc0bn0tevVSi67AQjuzV2pbTR7BGI71U9MYVm
1xi415R+GvY/sNEgZJWfWrWs7Y2ZrE6BULurP73whyZ5MjpZNuyyM0+CrL++5tFbZmFlka3YM3lN
J4U24tir1hyaR1rJdhzSF0PjUZibrsfr2UctAql2GcaHyptszqjkQJabvx4V/nt8DSdcsdAK0VCZ
uSqdk2i98nagc1GCIwrtt68wmdRyeH2uk0fSpfNNLjZ3KjvdQu3OCe2NzTbC3VI0S8ZNeEU/UZCj
Zzaro6hJA+yZWq22uZVCF11q34452rLqlskfltx0TILvJOqFFX6m3yJXIx718qr3BdLteb9bTTtH
q/Su6VwrE+yne9Luzauy9NzJv20LV8RZb1n+ca3MYnYtjxWwXVFUpGmS/eq2RUby749p0bVtvymt
a5P4651PDNLi4mZtVbtbeIsLWEexuMhVv23EYHd6xk+nXbBpXc8bkLuzZZhpVtKnXDg3hp3G9Xq1
b3XIqbtrbNdxZIod7YZ/JW6TTWrGun2zNqAkiUDuvLhXk7nWKJqt5yt1ac+ski+j8j0GRyFrzMGS
kqIx22g8ks2p4xH7pQaHp03k+zU66U+foaNQx47NP2mrOoS096NdshtclRrbcKzQNbzK8JcRuf2H
Ra84ls3ozfrol7xo90yWsbFHZda9OxbWoCdZPaQw1vIW2l8Hzt1TLr1odxgXeeO9Tw9zqraxUiai
rA9z+/tqzMVTMeK7hsODtN9zWjajN4vMbjhui8FPs8VsTWn2vhziX9I0zDum849MXV1nbDXMD16A
r8loFOuD7KtOiuSIfKknZdzwJhu1JzjRL3gc1umG22yQFnpjHUIhlNQs3BinargMju+L13aoWibv
j8iV+ZU2u3uclsr02KjJnNqWkGRpvLbhA8tYkKFrEK4ZTEZJQ8XP5jqFUoPBKQYNJgx12zrkNp1P
HYvcqRnOoTuSao0m2neKKXgkZjatRqE+0b8ZONomlv8AKIfaISlahj0xoK87k7TBKufDLKjx66ld
cXebPl1P2ljkt50LHbdYusbYYlBmzp2gc6BcZilld4jjZmcTKpiTlO2e3N3nU1barW9KZZTBc+ui
6bjDLb6Lm2wyeJ23U8d6alxpNrkK/TNJgaBo7zMe9+yOb2DPqvrEYyZXjJH2jc80mbbnFltUbm+g
DMY1HS36TmsFrUXmOiz2USukUKD01dFsk3W6lokHTru/z3vcM6l9OpVS1PlmV/sFcr2lRVCvRUO4
T8DTtAg6G0BLSpF44N4JpJ3eCm61ZO8hzimDSQhZuqNUkkyUQCVH0u51Kcm6lzt0ZXLQ4q8jPM2s
sqH7voaBlpyGllwPGchEWFcAzsbeIkobnPHCzbiCczbSvNkdJiRhU2GLi5xcE/k4Up1EdJ9GjV80
jJAR7h9FolWxSIZh5G85Dg2PuxJ814PCj+CFvHzHi+Jm77Mg8aoc9mqlJb9U81dORnxPuOXY+au/
Dl2Ph37NB1IuyGiOfTq65cXJturhp078OL7lxcdW6HzJLxLLv3YqkGXB+TJ31aiSY83JMOzninu0
bpNAIxduHKCZd53g7jpJb42nBv3j38U15GRgjNBhRz03XUWSMh7B3rMjO19tZGkHPuq47sNdYWhp
BzMpWVWSFirSitSszWE2iJg7WdVk7FV29vjK01SJ211hjcoyt2WQqLm21yHuzap2WWp3a3V6AvHO
mWGxUkrrCVq696ROWemMr/B1K9O6JcJiKiLhwzeHSp9pnDOLhas7Ro1cpmjvKteOdMtj6t5zwCpj
UqBc5mu03S4PNbfc8w2IKy2/06C1dxT6ZrGdv732ymqJ73bRq1RdVGVXyzZoejQOf6i5yi623OuO
hxOe6f3yu43GgR2jRea6e/yW5Wuix2kQ+c6e8yFvrMFB37NqkSAaFKu/HhCMLfpee6BVLdEWdq1l
KxJZho9RpbUgAlYCQuW2BxB9JzhU7iKpYuscznlU+4Kq1hUyj58qhc+ddle4grIqoW7lFOHXasWo
q1Zm/BvJd8tqfKQ2riplIuqpam8XKc3MPKdq1amLV1ykYCbEJOx/dHKWgJrlGzEXJNeMzWZ1ocvn
2k560v2e53yXa9pqefbDEVOUs9dp+00yaYmqqP7dmk3HVrVbrlOg5lp8RAWfO7jZfPth57DGw2bc
J60SdN2HJLYxfxGSokt6omjRsV0fP870htSbw2j2s69zjTWtEvDdnGWdxm+msqNdeDeHtfbNNObU
e6tWsXJMLtUpmpUeu8wDNIvPBNfa7OvK9YuNNrWhVLvoCIPE7pacYYclJUCBpUd21ul3lxRLccPz
nOlJvApln6MYyy9KPdyqks+5V60OKJcxBOZE6pcetIuCYvjOKpd1VTbRQM442Lb6XeE1ib78q9bV
0e7CuPnh1m3KpdxKE6yKqpb+lOtIjmc72pV5TV53qyi5SOeT+K2rrmULy6aXrOHsd6z/ADXZZLD7
Js2K2O4lUK7eqJpFYNzcXtEtMRLCqWOiQWyeenGqx1pR2zKWnstYbvn1jl3dFzApT0FSr02gJF05
pl6b0+2pgHMo6ol+5022piBOdqDoHGm2xMezsPSjXzhTLaUTwlur6OdVexYrWFJSa+d758IJnt/H
KdG07O4XQ89e2ps/xK23TFo5BJMlESgq7azVbmqm2lcc0m10y6LqNkU1hrE5pNwVU5pwVbtPaj3Q
QDmRXUroVLt6onjNdqXdCqFipOat7Ht1GvZVWbdIrdrcUS9ca9IPSq9v7US5FBrletKvqKXbUxza
dcUO+ClWkcIaUx2R2erjPYONSq57T5/a7/mlD1qUxad3LBNNbrml56z1vKWDSW1+mXTHtfj6xYqA
113AZ3WMM2SsWLr3zRvCbnQ7XByLDH0yO81S5Q3RLexUy08a/aoZ01Kw0q0coO0QUlHHYaZaGsTY
YKchlz9Os7GPn4CZj4zN9aEvnuh5RSkmAE31tyg2OmW/NNTjJKu26vSKKPoOPaLH5lw5ERGtAUDn
te7x7aUc1K0rrM13aRk/1p9p61uTfNoOyqplt61/tLpq9sVTLS7g+Nj4VG6dqZNyETHWnhmFY4P9
YnIuEuXCmXF5T5Ceja1d+VGuLyri0xlVvaKLaperNrhF06/9qDZZ6qRN+YUHQHebyFzr07KJzXOO
XbTdOxOP3SkZhtD7Ebhq2NOtMFXuzHhA2ONyTtuFMlZGv0jToDPNbmqHUNKx65aSyqV6TB1vQGVF
v7bM6kfSy6nTKlpKM3tFtznno9bp+hdc8nrjnzXSa1Ur68zmau9Aa6NW6df3uczd4z5pocFT706z
3hpbit3CMzeKQDIC9tEwsY+vURN1exrlkw7aImqzZao0RzJSDMJCjXYLHVU2mHip9zWXlirTays4
OXfVx1PQrKwca/LyFd62GJjJ4oJ/MQHKxRsVYBBupuDa2JlBtea5GyRLGd5Q8hIwJzkawneMS7lY
TnOMY6VXFLmojhMsGEk4ijlI5rLcGD1zFuH0e5cFFx3NUhIx7SY4x77pHdHzXk8HPuSW/Xg2U7NK
+XDuTfr35F15oUaVdEI7JCjbNyV3d8m7noz7OmyHCEPEtHfViHjLlIc0Oz4MnyGJqW+j0B+GT5DD
o/4durVhySRkory0ENFrnEyEXI9HptSjn8PKRLFPNRJURAKMO7QmuT7+sd7HDxdkKNsXOvz3aDg+
aVd7TA2F7BxdoioGSlYS3dGHR6VUhycXZzzpMtL1GN5nNWyBiLg2q9hlah0t0DBXMqfO2KmFdIKu
3UUmwWKncL3C1K6uaPN22lMdAhafenmfsrquraJW6ZxSqQ0Ys4udrzU9Gq1R0nrWL2mj299U865m
czq+eXiRr1T02vZrdbXmWy8orImZlLbTl7PWcun7keTVhYmNgGOaVa8j76bXcy2TtWbN2pNxVE1j
RK9nutdc31qNc4bsTvFYlMvvOKVjtpNxyDVu2MNtpqVgeOcOigAlRXtsiIibLq2faPVrXAXCGXN0
6dyPQ4jN2hGRAGSgR3LXYXNtaGbWC21um67EdicRRo75a4Zx2o6Dml1gZSOfKzLTHWbaxRIe1x9w
oFYUNJirzjeo88+oXN9tC3MBPdapbW0TJBzBTi6zaWjTsUhXLAiCsjBXMpSu2DjDz0Y+Zqkq5YGM
bU9jhIZ1l9c4Eu47XUc/2GFq0xZq3TNspE/HdeFae2zMp6Nreu2/Kr/mmoRtWt2ZX2dxHc8Zr8zc
GWfXTU8p5bVi15iJuqZUSrzs2UwO2USu26Zz7htOQ3tl0jafZNARnejNIDs0zuw6Xku2427t/TNN
jjsde6pKVlK2sJqNEtdJuuN1IkmojvjVMHF6tb8V0jSa3nesVKN1Lmzwma0rDYdJkkAGYCtV0XJG
e451Q9iTlti07JLq7e0mraPXbJ2ZRd1kqDbYeSc0y154/tmZapAwNDnNRgbcKZm94uGfbBnOfw3O
e3aoXbnASTrnXradJuZwXSWKrW9VJtyocpRxTLwmn2frGs57pS7vyq093Zxs4pw1QIzKqeXTUNcw
qP8AQGcZvtUnhNn2bEbXbF0mBv8AneoU925t7ygW+El01S05tHa5hGpd3vaVKpycpmNE9BZbdncp
mmaJXo2wefm/obMM42qQwa47RgGivn1Qo+m2d1QLsVck4ShaxmCdywLRmVIca7WbFxg7JC8pVfZp
XrTWrdhlaJABneW6YaL1u2Yldtfp1F1jP+Og1q04dI6vhUPyNJKIyIwvSdMw8t5y2kbGePW3WcS0
xnIsHtaqu0ZRFz9outSmaNe+1LtWeMtKx19IaXjurU1/dazBVvWMti90y+hNkTu9Uq8pr0m851e3
rpF1RCOZJVPugp1sTEHK9qZdTplnXGNp1xQNC4VGzG3h5ilWqSRTrLVcl49bttGAs/Q+VUXYX+JW
LdfP2qsnEl3zZtsWOseE7sFIuORa8xqdozdOs4FYWe2cqTG2GQdUKm7zmF9rdgqmUEu+7H5x7ehM
mo+yOMRtu3edNdavCrvHSI+Ds1bledUVasKtO6ec9T6ViN12r2k6db6DZkt7JAMrJnOj4zUCIyNF
+4coeJvOpZjorOYq92q8m6y7UsXvqspY80kAolJWlem6bh6N3zbPdsGOWnWMZuks64S9adu4ks07
bfUp+KkICc45vdLdnM8JXJ9fyiS0WFr8PpmKuNzzvMm/N9rNijq/cVUm3OK2uxx1WvR0a2SFW42+
MqF8OiWuVqzK7R1JvXahWicq8PocdQL+5zun65YK5Y0ZfQeStT0zEOO5Z/mm2PsMuer4u907lV7s
zYx09H44/wBrpU5IV2k6bXqBq87n01NVyNurXPNDjIxnf4ymX1jl9aR00a85I12CnZ/rXfILboGZ
o0jhRrm/p9f0Kq1bRE55OzedWy+Z620dFBts1UeNjbU62HSL5yVF2yHzhgSAAL614xMU4uzeTrVh
XKKiuVYstXstbjuKSIAzIzJVsl6qq4QkBcE1aTnK0dp5RU6bJhLx1b7W2KdP4WLn4+LtPeK6SkPC
TEKVo7V9pLwHe0xNd4JVJWKMYTxwMjK19FjjIud6wbqXgm881ipZxAu5WG4T7OFlXkH0mYhvMcox
+7heEw7jZXlBseapOTiOM0zYyC47q+YofG3cDjz7c2S3iS6ob9kN3HfitXMuo5ju05dkH34tuSVu
nLM5Dg2eKYd3bXjI8Wz1TJcjG8pPgxedY7vIxqJRq2kVR3SRjecjwYyYjuz6LaIBGQF+ZcoqIFgc
O4uQ7yK2SYeTg5eLjeA5hRKIJWRzNshYi0JrcxMVgrXEQdpXWJSbrnC0xdesjqtPrDXWFqY1yyvq
m6s9eibi1q1jlKrMzcXC2pNNiOZ97p1p01ZKk0u8NWre5r9uFUsEhAQN0iaxce9ZviOGfWyQob66
1OrrKR0OLpN3fUu+1Gorn7vmMcYkdK5ZzdbDnXfSqnTtPOsX1FDu7+n5rzJdh1PN9Fe1asaTVs5v
9iznaWsRHWnlXLkKxjaDtmrRGOMw50u80OB1JplmlT2Sz16qdQ1XjlelTuVTF7q9L1JGSaZPZfK3
iu0PUuuRaVPZhKXOuVHUuGSadM5TP2+s43zJJkDvnHhFQk9tFGuMVYoG6wqpynWTGrovMIpKDMAg
Rqc7LNNoC2lTbaIN1JIrltTTreIhE1zq1tFWspsG0x1qFx51udHOPm1VO2JhVMLnWeM7V8tZlZNv
jsv1JzSE32Dz3ZY40BEe0tsP0fV2wJh1R19xnX4vN7vLVemyEXocjKVmwNGMzH4y72Wzeda4k7nt
lRzzZYenzdorNP22i2WIds61K2PNZ2Jruv2/KdCzPSWdRuuUae9xrb8TjdtpdypFZttjqc9VrtAW
7Mc6Ox77mOnx1UtPPtTbz2y7UW1Vm+7mj6AeW6k3qU33eZ7pZZfp7SqzLzrRtL5ZdpvCpTfV3RNI
55dp2DVpC0AHfW/KLhtC1jBrdsEbkGz1auauE4Vw2bEK63ASFEDSuY9D0i69IBzJ86ndOtDuHSHK
ZVTLp1pVnXGtZ9VLuiqlPOWMdYOlKux1WXeN4CwZDeLZkc1faflDIaJsmQwm41HNtOsWOSWzZLOW
jnXqPoc13qtmVGcOmOaHL0rZsqpW4xmcarDIsELOuWUVIcpKAK0PsFpHHtqWs4Yy37Osz255hVz2
LCLrZ10OMvOfapTnDm3Ps9t8HIu6hbMqTqOGaj3fG3m8iTpNO1ZlxVVbLneUrtHoCh3nlT7SlFft
5Ua9c6nYi6Vm4lQb+ioWJfaoXo850BNQsSl0zROWe3oqha+PWpX3lnt/wKtEEg033giJhtD1zA5z
c4XKNgpVf1Sn3nEWu2YdW26TIGRkopr0HUrmcF2lBVLb1pdrVEomhUrh0pdl7xrGwdKRdxUp1y2i
bMdNuJ1eYdt67Y8eda7mEFp0ZkjFdu2/EYPf6XmOpWfE5LcsWuz5v3yuwaqdOtKoxt0o2iZFz3bH
afucVRdvwtxrMDYezeDm+cXac3faRhVE49L3tXntt6KyahbJIYXatz886/EyT/pm/PYcYbNp7YqD
ccn1vhSLrlL7R8MnU7IjLtCzq5QFP3rHZO1Rc9nGblP75SbgxZy0TPViSkqnbYrhKQVorMhIVa1Q
jt3XbXW3r2v2WBkHlYt9e7uYKzV+SdVi5VnvIwM/hUIaSUg9AaoiIezbNntrevq1dq28lMe1zHrN
PY0w5ICTUSkmHuvzaq1aelTsfWJTNFULiupzUhEsLGVSti6zMP46EtQp1x61eQlY6HtKqXb+laeK
m647kahlzUtC2LGoDeKrk2vT2KT2x5BJ3fhGOTd1y0Maheiz9F8xSc2zK6Tu8dk+ycmVavbShX17
ndvnmGNz+vYxQOfTV9Kw5vvOd5puLrBr9qOKTWjcq1c2kdHzsZjkvttDsLyuVDTqtn+xymc2aUrc
fcY7KLxEUzX5ms0HVYHLmY63LRM+h9QhM/vUzm0joFGgNIYUK4z2dub9S4XRGNEtdkzrpodPr2ht
KLbLBnnW91ODv7CmWiyZ05vlLrLcgkA780RHQfS2OXkJK9Zg45FSs1an4KIQhKkgGkGXaTtMXG2I
63Jz1YTaIeHsLmtOrBAtbKxgpx9XOlhg2Nk4wMvI1vpPw7CwogZSRgJGZaQ9g5V2J4HN2SBY2lrX
Z59WO9lhI21dIB9IR0NPsoma7QBy9ecWKOhbMdclJWPiJrlDS3aJfSTKF7zERFc1S0jE8ZxnGyi4
py9jikDauUo59W7Lq/5p6NR35tno4l34n1Q17lwcr4G44s0BTt4zS+4tpBDTu9jSlGjN8bB0/iFy
bJpJKju8pE8plmwkO8S6fxRTEa1kzipZ1FRXMyBA7614MIMWF+pt1eSfRsmAloSSYQ3DmkwRkFEt
MrcoyBs7uqP7FXGFuY12xPKq8s9ejbcxrVgkax0tMBDXDjVLBMVJdtr8LcUVGcnaiVyga7cxT2PE
5K8xFau3WlTNlp7W9wtXuvekTVnqDO+QtSujmjTNppzG/RNOu8hQEaBSuWhRtFv0hnsrdqVBaZF5
2yNVv0GiwWnMM30SfyqT0ejVrU2ea6BP5ZK6LS6tqvDKtAtmVOtJqVJ1ZeOTupYnY9MrWea46x28
XfMOOnwuJNw+1O7Z1H6bF5fq0nj10uVHrmpNMp1KYyG23Ol1zT+GSavI5PaLdUq3p/LIdXksptFq
qtb0njk2pv8AMb+1kfPjQiQYGgNURsDJbfV5R1IRFyiVTlXmsnlrDksLy5GpBgwYXstjKr3LnVrG
bNjYE1S4cq9N9GzCcOoW5Vcme3KCsx1K1c4WQ7HX7Qqp2lUM5dHXrIvPs7aONok3NdsyavZ+LZD1
zWbGmDnm6Gr2Qq1iTDTTboyduq7Y28FGazidoln9fsDTjJRUpELlMxzcprd4qfier2GnYGScV60w
okY6XrE93q9xhubltLVO3t6rdIpu5gE6d562Wm3iL5tpKVznSmtGvWQ570te85nprKlXTg3hLS9y
7UmdMuXDjW7s5y3U2VJuKDp997ZXqvKgW8Jqt+LKtZ5Z7dOXOt2jEtAvPnOM5KSDTobbnGwNr33A
Zbc+GLa7FUvWOvfDq1vWOUxqlfMGsJM3fpGp2vvHR9iOl3gqhY+7KJs6qVdVVOactoWzdqXclVh/
Jcq7aelMti4TvJlVLf1plp7Q3Nli8dI+hqva3EVwmF1K4ipWTtFs7AqmXQ6hY+jGOsaqZdkVic7N
Ip7lW2ZTo0VNuGsRY+1KuqK5IUzIEWL0NTbkmvSrrjA2jrSblzgn7tFct3Sk29EC+dKrNvKm25MK
5isp9DYPuNRt/OFcP3VKvJUq1ZPmq7nulDv/ACptpKL5WDpn2icKZaxHsbO4zjROdGuSG0PcDzTS
kUW4JYRF155zop5/d27KKnMB0TTfMjA0mQLQWqY6Ate+4R03tGL6zV6trFMvuP1XesgpDVJpJYJR
peej63aOrOMsPWlXI6nOOm8FaFU64rq0y54V22dqRcV1x9IFWbWqm244JzIir23tTLV0h0tsUjH3
oqpW7pFJmFU25nUrE4jWc31pd0KqWJbFjP8AWl3VNWnezSKkcW3nNL/DWHq1hrG4ol64V6XpOR8b
H6Co175VuW7Krtle55fGsQ+W7qVu7UK8tIl4qTpFwXS7tHtelfo2+Ylq9Vt8YORWOiWoVu05DQV2
XeqVbo9jNQU5H8bBUrFG85ur2WObztdmI7tKVW2xLOer03CyLyqXGIjrBCyURIyFMvEIwOF0XzdH
pBAC/cER8BK7jW+lmTGWiFdyeSaZnPS6Y5B8EhJgwDPrrVvXULb0rMtIxUXZF062d6vJSjGEtC6f
aHFfczLKBtZVC0OIETzSuWxdOs7qB42VlWrimh50yc6ldGtTuaqhYpCFjrYyqd0OnWV/BRdwbU67
LpU/MwcRdWdKvHfPXWnVasX5lQb66z+es1Zrmjx2SVbk81i7Vas6W0zbQJfN395qtS03ll18sGbu
dBp9P1Dll96s2Ynp1Toeq88o0q5VWhalUaPqHXKLZecxa6bWM0aK7Xq8Z0y02t0bRHuazV7z6L0q
Ap11ks7kr5RI3RoalXOSz6QvdIi9DhqlbZOhPbvSo6+Q1Vt76jXOZrFH4GRkDvzbkwr/AEsM3y4B
/Mk04ViegZZhBt08waTAI1KfXOPiJ15WHdhgGVlZwc3IVrvY4FjY+MBKStfOxRUTYk1+Qmq6izxU
TPdK++mK/wArJHws66qzDiH9saQk67rzqcgmlibQkw6gO89As7G2hpZ3ArnIhrPtYWUf1+Ql0QEt
yhpB/ALmYppLcohqlb6YYtJXjHu3cSqQaNZFDJz3Yk94t3SWzno1DjjxdJaPOvDm6b8H/Jq7W2J8
zYmXR/3YqkGXCU5R7xxHqk2bOY5xj6QhVS8eym+UPIyUIJuNZTSISWkYBc3DcZ7pASziDhiIGCO/
NeTKvKnp5l3aSkn35tIR/FdjrjbkkjJSVEYPta52plc4CBuAqczO12xO653no+mMVpVcWfefaVSy
KqJ3CsWmSb12wqrE3IwvTlTuU7PUlnzHW6ytNc3CrQ18aU22ytatfWrS0pD0huSuukVawTERUb5G
1i/dKtLy0NHW9tnTfUKLDabQ5O7tc1gAu6aBR4DU43MtLmcrmNFo9Z1aPzDR5/KJnRqRUtZZ5XpN
lyaS0imU3XOeQ6XZcnkdHqdE13nkuj2jLOum1jGGqpLYLXl56TB5vq7rHtDsufNdDZZhrDnIr9Za
E00Rnleruclvs/S47Qm2Zal3ya+ztKY31pVbgmCmGbzzpySADToTMmNdcbozi7m14T7TpJRTzOmN
9yeq8eRkAYBmJD0B0zqWvNXo2yRGTa92ip+vSsU0tOStShbbs1KnoGyV6ZRR5DSMY1StV6fluQZc
bLEu8fiNzlMEgeYl/QLTM7tPVKB1KGzLY2vB4y7wp2HHnjOB1DT86tlXtcN0eU3pN9Ycrfyg56hV
vcMv47Ril14S1DyZM3vkJY4oSURMQr95WbVGNpKOloCY7Vi3xLWTZyVYsvWl3eOYSPGTptx65/oc
VGPO0pQ78jP7/iVH6XfcM20hOdaI2huU69zPT22faJygmtleZXq/DO9ARDMbY6yrVeebaGmBaWlx
lOr8c20WGec4zJNUYYxz5KSZDQmyGVcmPS2Hx2+yWH6T2z3S5N7kOcbvnecNeYSojIKJVi9E0TO9
geZFP6xkde3emQekRLrIrz1Z2djX71L1l+wkxH8ioOuZLoPCJc2BENQL7YIG3VjLbhfMGrvAXbfM
zpe1R+U3m/43z3DNFXplGZvo8TKOOUVdZijWSMkelbladC3zPY3T4DtY7HVuloyuk77ldwlu+a5P
xtXoWm3nnWpZ1wgrV3ol45V2TdtYW1Lo134V+Re8q7bl0i586/JOk1u4lSrlygX73tTb1zpF0w6g
9dB2imXlNFuvKC7yL6gaDyo90KuOphxn+hpz+98YJc73zrSkZzfyrXWadZhqfHONCyRlpAYMcmjE
oBkStCb8mdblPTGOQHoCRxXQ2dM0qqXbP813bPs4Y8gDMGRkqX9HZvnexyWI2jZcOg/QlDiNQp9x
gizbTWWeS1puLN5Sbj2i+BZTuGUx7rVVxjJ/lkxqNblnOfRuqYdV+B2T0LktI3aNyC+aVhfH0FlT
+5Vy0MoKnavSKnLWe/12Yz3RDq8xH9aLC6fB0yAmtlcsHdDzn0Nmd9rVkqWOcbP6Fot7awkqrpXp
97R7s1hpIdoCwPaHeI+PdG/qlncUe8RjZzykarYnVStsSFcbDUZ3vWLVhtNVcd2qMyIOyQEw2ibh
VJng1mKvZuEHa4F22EzTbkzrlxh+rNzI023cqrc4tLSReZBO3qIvOaymCcFEaDPQOHFnXe+3Cv6H
Cdplo6c5jba9X9IyGtN+PRIMjIy6T3oWg5jtUjill13HK7vtOqOssXD+L6NHbGmUvcHHPk/qlk60
Dpp1N4v5mNlGzBK3lfubbP7FbsvzJgdz3TMKJvMfjGkX/Dl7hm7DTG5S8KfB2yzWN3SDmGa6nb+E
TbGTOeiU51eOlavLavwup1yOsXPLc/4PNaulVrGmtM00KTzWXvlLrOmsMz0ObzGR0Gl1PV47L9Ds
OVu9Mo9P1thll9s2VuNOplL1Thl94tWVq1Ck5y3U7vtszjjp9RqOjDOLNbM6ToVbqt/FBm7nnzbQ
65Vrv2oUxb6PwvFfr9z6UeUtNN53WuxF7Z1e8Ljc7arQSjO+tuTSv8Zyzxj+NmpBfNtX5GL7lAcO
CSUAEkFnKXSNr9mcVd/PQTKzcK/YJGJfPeULLCuMLO5YyvCvSbutS842iZxvDT3avOpOMY2PjXpt
/EVFsUpcIqv2zpU5ibrfG1RkJZ3cVIOeENMoqnG28eL1rBznNlOdGnU+MLLsI+a5c+cgcXJcq4yR
1cz0czmeEW8dxpyUe3k+ce+6x6Xrbg9DV4pkru25vEc3S2xumodhi36cnEhGM0DtJOY3rJxzeY4x
sg+gXE1D8JnlDyz6uuJ2FaWHlATEnWHFjgWlhawsrK1jvZK+xs7evzj6pMiJREDvzXm1r3GZt8dI
w9geu+DaLRzZP6q04pIGRAjWby9d6fOWGo8LrD1m3d6dL2WqtLtEVm1u6ZJWitRd2jarbXtOe2ur
xV6YVC2yFMd2+sxF3YU63SlIguYkdHi6bcpOjvblVITR4yk3WUokhc6hD6BF0m6S1DkbrTIbRYyk
XqSoExc6XBaXF57ocpnEzeqTAafE5cy5rmdZZ5dolky1/pdLpeu8IK6cqNee9Gy4Gu96dlWo9aax
0Ck51rqKvrkZXZOR5Mp5zmeTjtqNzyCnl0mNksOXyl7r1C1hWP6XOZu6vkNnuq9sj0iXoHe5M861
RWVaJJUR1auFA0rplGiPaW7sZUPQFZho3eh46RGkENDbpZV0bZJUzUYR8HnJ92jK1RdWzSiNEED5
qCiUen6Cut2nkwKR6Vm0FXLC34c3/at2YVydJvwkO9XsyYGd5CPlO1dnygptIjZNzW7Gms5HGK2m
x965ZOcVLcusZIu61Ym7CRbuo973gJkMX7V9EvncHONW0iwkI/u9g5tnzex0pHlIZllqV6Ns1Rzr
cIGhXOcp0LsNKscFM12vWlVQnK7HbFZspuNRufWjXrFdsr9K0/H2G75tpGRQOuVh0+y70Hm1Dp4X
pOt0DSRmWlM65JO3+dacWXag1q8m/e5zp3LMdP41GVkXuYaqjLNPRT5h64zfVOWX6Uqlzznrnuie
VuZERBWhtubWudPUOY0XfrRjU/ac+ttlfZ3jG1weRMeBGAYAJe9y3OdVUrf1qFk6xrOfVT7f1qNh
cRzSeTUreurTblnFWNdRtvSry7trE2HpUbausyL9rDyWDQPT0Yzl3jKFtPSoXAqzKSDSEs3SmXA6
1Lu2sJZutLuia5KPG0JZ+tIuZ1yTdt4OzdqRdSrEtRsV59Ni1jA2/onKM038sD0fXPPunyTzNFWb
P9hzl3OWeZzmyRT+Tod8wDQJLJdHknUvVbn59vNgz7V7BluoZ7bfOtd7ahqNYu4z2/cqnP8AbrS7
+WdaHzqc05d0TRE5jpKKjNvHWdaSeYaUmjWTq5oOjnl+mFR7QXeh3vyzzQDIHoTVDavK9O57Qd9s
GVy0pRbxGTUVi+zxGPsOaQS0mSi6bjP8Z46dc11KzmwYzwqNv6VGydWkZPrqFu6VSwd2sRYlU+4K
rE04bxNh6Um5LrMz3bREng8D29Dsp7u3ibB0plwXWpZxzhp9xTbcK/K9Ewdh7Uu4iuS/ZMHY+lQt
hV6WCoie60u6cq7M0HHefTTte85D0nitG31tgmj7F5x3Ot2hXXMXup4oiMtex0SWp957U+3YXp8j
jNpkNAeZLrGC7jjMhqXCu3bKtR88VTrednhCkYqdrM31q9zhubhvI1e1il3uNjnqnFRu6KLfWUO4
fKqF4Tn2itq6+k+VPv8AyznRuVIyFsYCVJ0Nvyb13nr1voGp02zJfczppvKFp2YU1vyCSUogCXeN
X7Uyxy9dYW9tS7w4pctO16PuLOo3JzTJucr8ZcWtQtrmqSk3DQ9wbVG3dqu/noaHt/Cm3LtS8wje
mj6Y2ptxd1J9YIKFu7elXJ5T389EQV3aUu5OKdJWOAg7y2ol3fUOXs9agL+2z6+P6JI2ytVnSGGQ
Vjl02TRcG6bzmOcby3wvTdFwq2aC0g7Y2g+8nAYvedVzy4d6JG6NnsNsBZ7cHNKlp2GyrUs646sy
bFPwWUR3V3oFizN1otJruis6LarDnvW/06A0BnSLPYKB2vlPibpwp1hsFFXcqtGW1vWZqbpbm0V2
NtTeuTUnS2aTIiB6G04N4Bu/uEXJxEy6d8GcYkuDmBbc0kkAyBqNxZJCtvpuFaWNpDTTuDVOwzSf
bwsu8hek3Fx1gFek5GCXPw7Gf5Q8hJQaJ6Pi54V+TkoCLbh1aFQUlKQCbJCsJxcE/lq8udio2eOB
fyUEmei2UwcJISUGU5EsZvlFSD+EEvGNZbhDN+S5iQiSl2LCWKKeP4lb/nxeGyJyxbSC2/Zcd1eR
glm7N6pl2fxfOTaNJJxELkY5ig+r+aheU41iJh3AupyFkJSJZWTjUyJHSZcM7Lxqk4+qFimoaPtT
Sr2ztUpmZgqpKWOnWd5Qm5JIyJd/b8W9fay2gwU9WrV2luMa3jXNbs9NiOSDQYIwCX30GXo8hcat
D3lpS7dLUpxb6xCX9lTbZLUtd0rEFfOFItkzSO10rEBoDakWybonW71qt6A3o9tmaNW+SJLUG9Cu
E3R+91rVa0VpQbnM0J5eKnX9GZ0C6zeevb3T67psfn19mc3lL1SoLTovONIlswnL3Sa3q0Xk8UXf
R77Ra/q0XmOmy+UWPQKBBapF5jqMllFru+fQOsxmWajN5FaLzn8BrEflmoy+SWi8Umu6oyyfV4bH
LbuOFUIK7axo9WzDeWeE7ZJ5HO6FCy0BaKdKzWS0jrHWHeG8V3nqPaulInWttqHO4U+WbSLBlc/P
mv33ANY45/kSSIEadGbIaV1rs9wy3ZYaVg7JGOJ2Aa47rlUyxnxMjJIPoheg6txYSzbuweuK9YeE
dKN+zB/3gp/gxft3Ua/7V6xtGclwdRUg5gZ7gxkeLiIk3FfnWsZjkONntXaImOTd42eRzpxDTHBs
74P4xw5i5NvydspSN7uoqUZh5FyzFEjFS0f0dwdhj+MnmWUJsu/wdhZsZZg+i3slVrM2iZpi5h5a
QpN0bQs236wFie0G/sazaG6q9aH+b6QzqNp5yeQ0qz755/zYlvvRnPLprX8NjPReP07aE5ptVIu3
n2w6JRtARULZPtIFxLsHNJvPnLXl4tq+hY9Ga3mlW15jIWeZzafr1g8xIIEAjRW5cK609LQeR7Zp
mSs9Hz95fXVWwPS53CoziouagQMK2S/Q1nXS7j2qsq9bQtmXS7gutSMjxgbQqn2xcA8kuFdtS6hb
OtfdyPOAs3SoWbtAuZTjW53Ba0r0Ot1KFXrQuoWpcA5kudfs/Wm25VdeyPKAsval29ddfveMBa1U
q5lWpd02grO4ol4FYl6HiRW70RTLyirTL1jFWVzQr43rM05YRdhd0G/FUJ/u0ibG4oN841OxdWUX
Zned6DwqFjcFVe2B+nMSzlPV96Qi8E03YPMTz0xgtG9Dssf9HZXquTXfKbPePPNi0m0P4ukXQ+lL
u1PXkDeQ3uq2LMqls0Tl13uN+z+RgZzzIkjSEp0dqXCvNPRTfJNru9Dg7xndlfMpTCdLlsKYcAkg
DJRdNZ0KIs3WmXEq9JuUQVj6024CvyLvnBWXvTbemBfvCgLJ0qtmXAvHogLL1qFnXBO34r8xhNYH
oJUlIFX7H3qVnEO8cpg7B2qVpODfd+kFPdqjZ11+U7FBWNdStfOGkVKiJnvUbZziJLPMf52r0HV7
Y3i5Hl2jZB9T7cyjpNo5Yd5in2plGS7F/E9pmq2BozlYWcjOU/WZ+LEtHP6rN5H6CyrG2qpH0hEe
f9Y17y3JelsEpXo2Lx70fnt84QQTP0phle52qGaTVMurWt6TnlggHU/EWGrvrHR57zroezYbqjTK
80LmACXoDfm3gWWi6bn+pUa7xdgY84+m3vItVz+gt+SQkGCMLsmxSVOkrJBQN350S5SVLe2qBr94
40m2yNSc2mErt540q2SlRXaYeu3jhS7Y/rHWyw9cuxUm1SVOy6LF71ZFNtMlU+trha3eOFKt72pu
bLC1u+caHdXlPdWmBregtaFdn9If2ytVrRmmfXyRz2UuFXrWkR+RVdLvWLzS6/pkbm2kyGYzt4ok
DqELm+nSWU2C+51C6rB5pp8llM/oGcQeqwGdaZKZXN33O4nToap6SuiP7hEZJHiR1ZtmF+sOXPtE
pNZ0prn12moVczxq1gcUWLu72r2tjUJp3X7Z0aQNmZw1h4snPRrV5SZrjzrVuKAQIdL+zRygGDq0
tZWDmuz3m1bsXcZIQbPmlJAGQM1LmZiKKZYMZlUM9kIg5pnHypwzmTiUzDWPmlwLuTim06zjZftD
u5SI4TrCOlesK8mIGLak4sTqDdTEGiwR8XMrhXcrB85+PjZjtBvZWB5T8awm+cQ9kYMTsYwm+UTI
vYQ5aKay/KGbhMjLsGkuUW5fRJyrDlKN42WESO7bm8dx8qqK6v4rjJcxKnH93cW8fIgky8M6mKyw
IOrH0rEtPVRdmh4a1dKpMWCr87fDQVpdUqYtNIF5gK5detGmrbR0XuuVy8d6FPWvP06BWqzfCzfg
gkqIj0VlzRAx0hqENY6XcVTvKPRWZyk3OmQLRBERmCUnoLBp8BTNDcZ9P22kxmiwfacawFq502p8
yTcbPXroinvbFSa9pcA6t3CsTruBXPMYK1JhLGTXK4RMpqis8tlioh3uu1DSeed3KfoPe/VWp6Y0
z29zebv73Uq1prXNNEl8zY61nTHUGebaNK5nPXWjQOqxWQxSVWTZGOR6nOZNN6LSKXs0fH2RdIuf
ai5KkONW0LLtJTUOtupObb5UIvTExyeqwU7kLLdcRuk/TsQ5dLhtjnLrrN1qFvp5Zp686ur6Hh7m
vM9LFBuZNoWxyGb6Lxp1ubqiJOYzy786tbovqzXP0O1nnOTElJkY0ZryRX47V9NxvYuMlS75CdbZ
Xe2C6aMYiOZBKkmk1GvZL/WqLs0JmOrikOb1BWGt2arxlrrdYfV5xsvevOeh92KaXredyUlS+l/g
rAuvTyGZpgkXHBqqnZLi4i5RsfVtKQzvrHyLc+zSSjerqPftO3SOl2CnTCQY8ajtWMWCQkY9/HuH
sFONGUpmeTIVrev0KjbvTs/015nvTVM/ucFPUur6HGx8zXGetzGaWWGmXtAv2G7tRshkNQe5patG
wxpudTuFmybQsr1byrEdN5sUZaH+Uaw3z69FFRdvd5Pq/DOdB5xcZb++W6q2oF65RsTcXOU6rzzf
QOUK1tLjMtQbUC98a52Y+dS5mQA0Rvz5QUdu9lwTT9qz6g7FS4LVltfPNk0zz7B8UpJRAGY7+grD
ic3suS1beKvlOrWPH9W5SGZSU3XL5AsrJNOavJp69azY8e1GvMrZxjLhGPezB7XnUpE5Dp/LIINP
oSS6TSKzbOtNtDmCVLisWpdLtvSA7y3OsW3rSLgqBdv+dcnsQ3PNLy0l5BlB2ntRrwVTlqPh3Jxt
Wq+dVekMXzX0jHYDrGpec9jRM5nMdKPtmRdrzYp/O5ZhIyFB0DzTssZhGtXfFWmoaJ5z2SEjtLtO
f2zNNL8rQXff5xvYHmYafyzu8lD8LK8yjWOGZ6PwhWtpfZDrnDMdJ4wjO0yGP67yynUW9aOyvsi1
3nlWmIqDyO8/IJfIAaJwS3g4vbLxh+p6JXs807PJWz0y9YFb71gkJxSk0GAFl12m44ZJ7vjVP9B1
XKtNuOM7ZSrzHLoj295Pzf2q6wzZvYTrFgxfU2OeOr3Z1Um7dqDcqFUNU41u649U2p7tOunfWu2P
pVbII7q8XAWBdWsiYpz37V+w9KzY0Rjvp1gn+NbpQ57u/LpEyzqr2ZvGPs5yHh21/V/NLv0rhVB9
JQ2B63qXm7favbuLrOH+i44upXrZaI/hJ/vWpfFNvYYF6DpmZ60z0rAPRPm+u2X0rltyh+3neP7a
fqvGnXDi3YTXagaJxo1z6REbb2+eafzza9SVWidBY5nrPHL77MUhpo0Nl+w88m0OwZoWnVjPNgbY
bTiQpJGeiNiawcdatpo1/pN8hrTH8+WaafjenVHPGnJCFEYIlH13Sy4lMbHllR3SAyPVLLj+izC+
Uk1jpDjCZVftIqs6UB1m6nBahzp1j7xsyTVD3nRrBIUB3bMaheYuOudqNZpir8LlEVO9Jo9pl6oi
2w9Vv/Gh3OSpvW3wVT0bhn90lM9c6jC0G/NM5v0pnMtc6lWdLj8hrnJxsd8wt5teYUDeovFdXuGJ
XG7NoW0prL97V8n0i/0O29M96XPM+mn8sntcJU9Wkq1RtJzCPsOo1Bhbs7raVPtA6USdtVF4XquV
64daTLWemIuEFCWdVVlJ2rJs0PFzXavPZivnNx0dKqhn0lBHLRvF/wA4TgokgJLR+HDlCxC7J2cM
JBbxbVvHvo17ENuHNIStKkmS+k5LRBTTOOmThnslF85omcn3juUlFw8hMMHvaF5zMXynFRTt9Dd5
KPay/GElOsEUjDsiR1nJaD6TMU0nOMTISEJ3l4fhNM4uR7RDuRjec9GRswuFkJCG6zPGEk+MbKPI
FMq0Zy7eEahcnJRzaXTDyrqF6SrIphtGTSYpmtul9JspooLrIwfKaauJURbt9AdJuPqnVT60VSM5
qU4tx1GwTtM6XKsRV150m02GhubvVoK9Jodssefdr/U4DQ+Oe2615m9v1Qrmk8s0vFnyx/pFDmpf
F+CkkkElWiteSIaGf6vF2Sp2grHyYdaTas3vNYp7bgQBkhRmrpo9ypsPpETSb49z2bt1Oi9Dh6Zf
3efTdtpsRosTSb68zucuVMiNDiaRoTmgzNtpsdoETSNBcZ3ZLNTKGzJejXijwmpweeag5y+0XKq2
NzClMt8qgQJHZK7JTrOi3zjSb+5gO8s2ougN6ZoJVXNdeOianHY3AkLbtEZkmty2SWLQqNT9mjWs
t3plwVScjLm92K651fudXeWCk0Lfc6fXOqxWgQUgTKdw2uB/6TxnLeY7aRras30FUHxne9A0fjQL
+1Z8X8tn93Km3eLSSZ6kWfpVblBOhF26nTDisXKtP+9euuYbD5jqBJJJgl6DxRyhYfQ9sxjR5xzn
2lVtV6g++BXCz4dBNSIjBkYVY/QERLt+UnESDdEnCyfNrIR7/hykYqS4tZGNf828lHPefF/Fvkcn
8a/Jq/YOufF9HOcTqnNx6Nc0N1olOp2x1/OdUNjPQM5Re1qz95yp2i6fSZSAszJq7rsBau9Ve3xl
HynBzCT1M0mKgky2b48jpsGtZzT99o2ea2rNJnUMyv1fsWfV3SYLvI1TtqL3O5xtJPs8vuIbrnTi
05s32Wj3E6hcKHdUZXsDTHcuPv6Jd9JZ5nGo8cv0jnA9Jh1muqIy/S29beyb/NtQ45no7etSEm7z
nT2+YaVwqU26f0DQ05zoGbatWcGpqQRKJGj8uBQkNquv+dLX6EquQ7lWaRryXvnvnteD1NokiIwF
AXbfqnb+1Zl3TGNsHSoWzrV5l4ziLEuqWnvVJp4zibB1qVq71eaeMIuxLqVq61iYeM4ywioWnEqA
3mfSUVi+rXjDHW6ZBTfQFeo+tRTzLLzAS72DO6T9bdRE4IhzDVuxZvAapfV12Tio2bn2EqmNg5eh
4fx7bhqfmx16TxDOvSMX572LTfOm4MZ7NJyNre1Yg+0CenqBJNZJ/Qr35j3iq0Wx3l5N59ofGhX7
g6r9M06n2nyzHOvR6nUs5zfUSyvSeVdcyz3LtXTlGpNqpJyj/LNYTkup8adKyEjlWspyDXGdNsPW
SzbT05Drua36Io+KpIBSRonJPGEh9G23CrjqrPMNSoLm45jqeGvtTwqqtUkRGYAXafQFZt6a/MAo
2TcVuyCBmkoYyfasWY4GaPmwlO1dsKYaXPkwlelcsPSDlT4tJLtXZzFqLweelITF9SvuEd98xyle
h67Udapt4jomq3ThnyXOuN3tDvXBh2HajwnPpsLaNd0mk6NM5npFkrxPs3yHh32bUvM0l6Swmjek
IPz/ALJpfm/fq7bW3aiP7xlYoGg7DSnjR26ihke8QNFnLA5lqVcUVC5RfWtVvW4dz5gZdda05Oe3
xdZOyN6JpKMv0h3SlXKGoeutcm0yTzpzoFczzZI/H9Tncof6TTaFtsXjGuy+QTGoZ5Wt6hcFo6CI
EZ6M34c4eGldpi5+uWhtbWTVeTavkGgwebxvNANAWSQt3qd6q8Nf2VFu0hQ5O41aEv7Ki3eSosja
6rD39lSbrJ0KUttYhL6xpN2eUaYtNYhb7HUq8uqRK2aq5jEcZjeWOOalcMUktdzWm7dGZrrPVpIn
ygbE1zyq7UbST4US78oC/sY1lNNaNfWGbX+WzWq7FOZzeIzJ4Dm52C74i82XMaPukRjuq2rFrjdG
MPZ1VZ8+qmY6Tc6Pb1ZtK2bN5W+taLdUUi0yVVVZoasXlvRLg/plN59Xt4a1Semqau212JtHGuTE
rWOligGk5zgpN/A9ZqJbSKIx86iusgw4yHJk67R3V0z6OGsc2CCMyGit+HKIiBMySufV046t+cW7
YOmDVrxIJURpUlQkZg46QdRfR+y4yfJnKLinj2ObOm7SU7MXUnEcphkxmTiXz6KEm0i5FzDd5OI6
TMbDtkLsD6BeTMOxsTOIm3VfeTkZzleMVIdIPnNc+EvHxUn2iJZ9EN5yLjZlMHKyNedTbKKlWsFz
SqQm49hMrgpGTgRPRap1nEWRNcaIQmVmIizIrD+VqiZ9lIy5VuFIukzK0+w2Go215UKwhb+9t6Nc
Z7PJC702H0ZjQrvYMyk9CocPpsdnOgWLKpjRs/gdWisz0ex5DYNFzeG1uFzHUJzG7Po2XXNGIoQa
AZA9CRw5w8I71Nw4YSD2xN2Dum2jNrZH59H8eakrQB05rEttXLL73YaBw0us0PVCiLOmtWBcBm7X
iLnpFIunSvNbVXG1pVW7D2g5N6wy2e0DJ7FcMy0aRj8pr6JTZnGf2G1VCK0KKoeiuc6tVkpbHQYO
laQrNLvOUcr3XqjpKM2vsznzy6VuraXxzfQn1IuPUqVemONVlCrts8TkuxvsitV6oVa2OI6dnlUs
DmkZL2YyG5WbP7vyrsm/qNF9CZFbZmkUmCEPP79IeXfRTiJtVOn/AC+27bFoHfP9EjIqRTK0q1u6
PeoRMjFWKrTLmp3WAcSVWuNZdSlUt1Wl5GmXWHYWarWKvS0hQL/QtP8ANtJRzBgjToqOKIWEtfoP
IJ7R3GYafXo/RW6sMTq2J01qQIiMIWfS+7nVM62ePoFotFKr2uVaZbv4mpWvtU5CKhdas9FnIuWV
DzdEZ3utwlwkHdetGUWe9Yvdrjkukw1gxfPuGw6Alz1h5vnGSzY27xxCzBQ82zQOneInEwdgbtHA
cwk4ut2dtGyaFw03I0u4M4OazTGeXTbdXyuub/nGfbRzyu06RlWkVu0ZlDaTWJx1V32jqo8zz6P6
He8L3jLLJMUfPtZtWLabcOfm/wBN5dW9XjbH5GZOvTsfMvO1D0dWX6U3qk48XRdGVlunop871603
QizTSW9Os6O9RvJZxo7ej3VqVeuqM+0PMtHifPFSJSAkho3JHKHhbn6EwA/SbbC9si8z2ThYMHqX
oXEqE1TzIwkwoump7Tjdc9A0zJdqlsRsmvY/bJ7pWoyx0bT6q0mLLO02Zi5F7UrNn0wzz26T9FnL
BboYprFC13LtQYSOM5/w3C8x1oXTrf2qE7IxDGzppd07UqyvILjPpp92VS7W5ry5rjVbqqg3rpVn
8uyrdrVUbcKpOUDCuPXc9R8zSfpLB6B6agfPu0aR5w3qAtWdT1Yi9kwaR0efn6T14y3eiXrzJ6Eo
NRltN5y0vm/SzWPzP6RxPM7HoekeR2z303Ezj5dEv7vJNUaVSdc9KHovbJtaYUm2H2oeiOse16Op
NuQ6pF7cZHrzKg3loVauj/Hdbzu3rx/K0qQkENF58Ew8HZvRGUOdeLNdIqKbrleo5FF7PidJaIQZ
EYI1Lv25YzUvR1IyjXp/FJfase0AOpFVPZaBQo6LmNdrz2t25EDM8m1V63CpwNVtWoOIuTydWsUC
7VS449nbfWtI4PO8NMpj5Hl04d3UHKHGSTc+a3sNJ9YmVbEEPop93hpfjy7NJKNcS9CvkW3dZdlD
fvteoeZZf0lgtC9N1vANs0Lzlv1dtbZdQeW7OeeXarqtOkebR43h853mrVSesbOZY1/Ddrv3nz0V
kORa5eKViZONU0/nmGlus7mLfWKbrjDJNYe5ZPX+hVLZYvHtflcXs2kZzT9yrmQbHJYra9JzKr7f
Wcj2h/ht50PJuuvwXn6vpJISaNJ5s0xEL31SYbGuXsKWJ5noGf2Vtm0ZzRzIwoAgrR9WzGvbPXsq
1qXyKb1DMl6CcVPpjm8tF5XJ63XZR7Xoq219/YObKS5RVYuNd5WrnU5q11brLxWX1TlK6/M0J/cq
tBaFHUe9PqFMW2mRmgw1I0Dtn9is1J4X6BpuiJzu22KgLv8AValpjTOL3M5/b5yIoWjw2WRHPvrd
ryJ9qucU7aIXK9Onclttuj2U+irSryoUfQ7DT7WmhSNgz+ftrCq2zjT7Lx4U27Oa3a6vXrvypbEd
XNsZQk33r7mZg+U00jJHvDOJWKQ/aNnyo/q5ZB235OzaL7sujlvxd8W/Xs3U5YMuZJBkD0JDTnGQ
iJWWJSXcgvnwj+zDoUU2ShABqSZKNzNOYpzLRfKV4MX/AFYS7iMdO2sYvkyOf4OJKKj5fjHO3zSV
6tWL5s1lTZ9nTNpLs66xSc1MwR2CMjbByhJSQglTsKzsbSHlXUA4sEE3sUbFT6q/ITFfTZIRhYuV
dmZOuTUxFQdgYVvkSn9sjoGx961I2CrcLTHixx0LZjqMWkHYJmEt/OmS03Rud1rdgme1cl3VZsfY
synLjU7xwr+bEqZ0+Jz7RZbKrFoGcxuqQOe6dM43bNCzKM16v5nrcri9u0bLIzZK1lmxSeJXjQcl
4a/U802TvhKdvqcRquQZ8gJJaQrROLZMRBr1efjJphMTQ5dqtK0d9I5dDtkJMEYIKU/3R7lFputD
gtWiMz1N3A2Q6/Ldo/KmXJvc9aolxTHxNshs00d9TNELpGuD5u3USvrHvuiMmqHKb2iQoc5Za1D3
xlRL64othnqsxu8ZTL+qg2ubp/O5xVP0A8/ukpTXdnhavoHLPL4+qFu4PKfa+OMVBB6HtUFkm1dM
ludxodd2WCetJWsP5KlZg7h5Te5Sl2MoWa51uleiMLmX9qjo9NhjK9pvm+3bbmGgYtWKUTrepmTq
dthUT9Zs8PynqtZ4B1OUO9xsLbKzO1+RsGcaEwq12gX0HNSmbaQ3omhxDdoz46zltvzPMqykkkZg
aJz4oiIKV9JZox2p7lt7bQN+kDx6j7nkudM+RAIUCUFW/wBE1LO9e5UCSvtHrWzVF47LjRrS9gJC
PgdNt1CnISeEBPUC2yWKuLTdKA7vdNq+kNKZdnEjB2vHsubaxpzSZXAWPnDyiuTCXVXbKmBnuTbh
JdK1ZhWrGI1Uguu2dVQtvOEkHHOBsbunXFtXJzOMS4Otu1jF470Flefb1E5LfdDxvVYOzY1z0mm3
LhCTd35U+V7Ic0y4YT6AxbMbftOYs9YLzvpd+oujWjHNEr2fZEmT9T1m09W8JbnGZ6Y2pFuJvDWx
xmemt89uwaRlnc5ppnCh3bhGcbA4zrR29Eu3KvvHMy5q8/RrH5nrCEGkAtI48Siq9MeocVrnpCZw
fUl5dqrS35JlPorM8uj+Q5qIzIwu8+hMtz/0DFYrp17xI92y11dODKCmqHqNaipe0WapyUNMu6rY
s553rC3ut1Cl3bRMtkLNQbNJZ/JWa+ZBlLfX9Oibb1pltcVaUlY6EtpUq496ZPyUOws/OlXfvRrS
7gEWHnUrn1oN37VV9LNa1bxSbmdVmM/wzh23TT/Mst6SwGi+m6rge5aF5u9C1C6UKdoLjVvOc7fr
PYqo16y/WjXLzR6SyTN/SNJy2Yv2hYXvuA7VBaF5tO33/wAoCQ9R1e2oOs22RyTWmFDu7cq5bZTJ
9TY59f2iIefm8i1SPo+hRbRlLzeY6M2oGixDRdazD0JBXTEdq84UZBkkkjSOPEouBdekKrBbJzqV
mi+Nnza80+j7TlGeMUoSZqIgF2f0bluc+hI3GND0PEeW+5fIWljNrq7S312Hqvbc4KRrFqasn+cT
9xxmft2OWlxpGcXisV7VaxEVO0X7Kc446PrvLu4j3/AuzV+1J2wec+bli95cJBj2Pi8j33NjLsF9
Wrxi76ws4yTOVK1Q6++R5k3dbjpHmyY9FYNSvStXwXcLx5036IsbXpXXE/S2WSbDo9Tf9q9MdKVX
9zpuLeh8MTrTqKz3ZPNG5Tb7P7h0q3n5LnUdXi8o2Fzjl0u2ZxOswWU7I6xO83/J4zaKblu0vMLv
2gY822am5ftHXEr/AHzGF63SM82ppivfeY+Dt0HgzRASQC9DQ15x0Ci73uEmYazyblu3odlglPs6
jOCORqBJUlS7hrtJpet8ssvlry89QqVd0ntDzfVrETLPOeesRbh/C1m7RVP0GZo0VYc6u1ya57aY
aL1HrGVy1VzPobk81Ky0VV7q1e0BtQ7tL58+u1SgtEjKFfZHPJq30hjoMJS9EVnVmtNA5aHVqpo3
HPLjP0C1zkLTLzFZ1GJ7abYsykb/AEWu6rD55oUjnFktEa0nuVfknFRrN7k63YuNMl39Msk4zpk/
X+N0Fa5Slekp1ixluddiwp5OMGUquHeOI8SDXg+SycdmCunLm56NXqWvbuw6PUMnq2DlwzaPlxnZ
20e9Y2L5GkjIj0Xk34sIDlJ2Hk6Yy7lzzbx4Q16w7RHEBRJIyWpxLzcJysDKKnVQb6UjJN1HHKM4
PkOCbBydybKFnOEA6nIqZ6cGMvwrzJLi1vm/JzxrkGgP7UyhrF0rkjN13nZ4dxMR8dYOVVbHyVYF
crCzrU+ut2d9BKm2FU7WaqubXBV0jd3FhTuJHaLLT0XiCq95VSbHZKPH3iG43ZNTsr+ruLHH0i9s
aDeJrOJW90mF0uMz3RJjLLBfs8qNqv8AlGjpyRslTzXpbHbZo2ZwOz13Kdjl6BpK84vMrUcUQS7Z
uGP6m9qdT16lVbXizXQulbeyxedLTvHma9az5o3vqrzPGEkwEHoqOHOPrydbutPvdZtLh1yUxbwV
fvOVVJnyWRERkYW49ASubPNEqVG2BlkuqysDPcWC1dMmjebK6bHRbMkoG0M8wv8ANZvoyJOE6u8w
qZ2LUzk2zKYynNGxarp1ao2utcq0qWzSR0CGmGTqCeymX0tcZaN0hDcO6zPdKhOPFRneZx65aT51
umiUzK1ROqXvjj1CKd3h7HR1nTULidRtSoTP9/yqDus0JatTruo22pTJ1K4Mo6YYP4WXcVW4RLSb
hJnEdzs+J6Rh2fNTVbvUGfZzsnGjFrma0H0lmdjTGvs3mrxk1wiaXvF4w3VMf2Bnmup4xCa/Rqxd
rRYci2bz7oWmeTdg1Dyv6WyHWPLVXCFpJI0bmhMZXuvqKl5/6EnMwmJym2+2IzfGN2p2QR/AEQIz
JSp701V8502SzdxqOfVXa6vwscc4ze0yUVKsq3oFwpEvBzvavzNReWzEG9svWdSNrgZzpTK5bLlm
3PU8uy5k49E2rLl7DmlT22sZvp0xR9CrlgyaUtkBL8K3cb5XeUdNrjeLPOL8zoNu0mrW2e89aJM4
tYdBotwj53O8M56Nv9K0AqRbe8M3nutEu+E7fneLavqDaZr8o5r9ma1+RlWtXuznMNNa02xumUFc
XOZ6XW5yTodsqWe4urpqHpPzdU/UVMwDe795Mu/o7zPc7+2qdW0XHfQeSO5+9TWTX2n2p1neg4df
KvlWvzOF3K4arUWl08mzfpPy/wCls10XyjBJIiBDRkcubGuK9X5xnHoa+YhYbFmN7VY6Zhu8QGKx
3JAIAGYFi9NUHKtve4hcNaxev+h8/jdFiXcBJZ/p0NVZ202muPa3ZXVZmqZXNTxLhr9Rb3Kn2m7R
dQpum0em7JE5VWuHb0TZcDs+24hW/RtAyHepHI9mgLLSZKmWCwZROXO1k0r1idRPIQjfL42967XZ
G6YTdH+D7lPR/GMms+wrnoXoWl30Ue2OIVvPLo1z827zT8hs2wzis60pzkGsca3Iv01S4u8w0xpU
7Iaa7a3WZaXjlh1fPnVStXlNXa7enfKsV6fzjGtvvvk67+m/Ju3K42OTxGQ2TBXFSmvSmVaFjW1x
dE0CJYUeb0fFXeeXzVk169+WrrunnnfsP2fynXkgEkFo3HmllXefoKQoWyx/E3sZM1BweX7Jn2Xs
OfNKjSE9DXMemqLku3SeHWzWsZgPQ1EidGi5hzXm8ywhanFbwxeQc40UqiSF/wAlLQcd2AR8g/g6
r1ueKdtyySgMEufQlhwS3bHidd9C0bJN4kcg2aGn+jCFcylVr1I3OcaRcvFP+TezVBo07W3IUb1j
V4dYnvDcVqeVjefcrLvPdiynhUbd1pVqcVqmbfB021SsRORgkIyToVzRmmhPs5sNqqNe0phl+oP8
luFvzzJNa17MrqjMcZT11PccErvo6m4V6Dm/Nd/2TB32r86NozFnXbPHYRbtnzW4OKLW9azuetvO
t2ptXIO65ivQYyn3mTp/WfqWRcgCCQNFDXmxr/Ke0qCslTuDuSbsK8jtDzlCjW/NJKMkGoKnNWjM
/wBFkM5mrpS4fSIin32ThpJ3xhZhNDjNL58ZeNqdua066WGtViyUi+WJNdl+tLY2Kgi/1KrcCcan
PZlOXqiQmmw9A0d/m9xsUWcuivynWl1LSZGFsjKj2ZxWrv0ZQ0/FUCR0KrynXPLhIt6lb4ijtU97
Pa6kwvUBA2pVSmp6nSFm416x8azYXFady0PCWJhCTbmuu5iC4T0dGzKoV6/hkSq2L3hDtQt+/jFS
jNlKJjHbyNOWZcHXeN7uY/lMtGr7rF9pGLEuxayHWFdScOJuOjZ0Qk44hoBKUqJIVonPi3aV/hI3
JrJwU88eiObMHMVJVpjwQgjIGQUvtc3NckJ+vNLXGQNo7VeXmK6izxsLYU1+SlYEWaLhLQmsTclW
V2aDh7hxrc7IVeKsrmu2+CrLdSZW9x9atLynyljqXK5xXaXZxVl5U+CQQuffnY+FNsbio3B/BdJm
Nh7VxprDQ6rC3qqP7dwzyDR1vVspDXQISmaJ0zm32TPl6JVqtpXHNL/O5jK32kQGpxGc6TL5TZNA
zuK1eCzLWHuRXG95hYLvHZbpjjDYAdtB1epZ5tJYrp9vyF1q1NoG0Nsa1S0Y1NaVSaLtbbE9gn8V
s+jUam7FxxbY5TFbrdqLXtUb41sr7G9Tiprym1QlRESdGHPixrvDWdPznUatZ2c6zN9X22Y6jnee
x/NAMEoIProesrp1qd13rOs63bzptodVt1Ms4G2IqVpcVuRlmEJaedWtHatTD6Jj7Kmq2ntR65s8
RDzGb520SWuanX8+13hlOmS+bvNCh5VhKVjrOZtVlwVo3KJ5lKQEmurvXruD7WRkpdOoXoTOIDec
VtruSy/GRad/HNu8d1uxpgLGyT0DiFnkV+1xSJGLlIp06hLFBLm63YG0ZNRMtGLm6fbXGfX6H6sq
954VM+pKPeo1spxL5zoXbNNNi4Z+4ks20dxlGtxNTsa3ed6f1x7YWFDuCjoukd8X2ppmejcoyvT2
GaboHkJiEJWRI0Uk84+v8PTrbGN/0LMojRaG/wBJOneetYc4VENyCQoBCj9BWA5Y6xaXNPsveIRM
c63ZnFPs7qB6SvCEsbio2btAvJJrD2PpULV3rcq9Yxkq2tMQI+m5tUeavQl8x/vs2V1rbK7lup2H
MtMiJvJJWwQ881g7hc4JpwlOscxLMdAr1K0Z20nJ+HYXzLs89FZFcn8nk2LJ0b0HRND6UG4uIHlY
RRNA7Zroaay6m2tUva8x03lTZ6QYQFsc5rpaaBcekUysq890aMibDGN+Ed5d62P1hnWhN4JzLHRd
EPNdEa1yVeim3/pl2nNKjYepVLQF5Xp7aj3ANa9dl5TqzbPr5zhmLjzxp2veOWAUgEE6MXAmda4e
n22L7fq2WRGh5tOTC1eetVkcHheJEZAgB19AWJM0KzZnFQs/WJ4zXOt2jvTrU4gOstzrtoc0y096
8+k2kJZ+lPtTirTEhHRUzB2XomtSmcZAzVvN+wGW3nFaX6VpeJ7rY8b2esXCsdaXM2jHZe3XJy0r
djfRjXvGwNDv0jnVWsmyyrZNFx/1DmF3i7BQMHGiegKfeRSraca3me1Ku/TP720hHb9VYtTrOdDa
1meBwM8/z3QG1QuDUomVkaHeXmP6sxYJrPnhU76gpt+rhueEtUbE4qF1gRJQdkrEm/qturneZqVv
r5T9csNXk5ajXeKgrhX38XJymfXxnUJeK0DyA1I0kEnooboZ15psmlZlr1fnoiyQriMq9ux3Wanl
EWnmlQIEXRejau4rs32juMxzgbB0r8x1jlSXOEnl1+b6RvSQ4RM+mCmzinjxozmeUJPFXcx2CyM+
DrPcjYdt7uODz205BT/QdVx7bJ3GdfaSvbnDImq9V8+3CdYE9rs0Iu3Vhdgh2+f2WegrfyrNY2ip
k8c5TkvKf3WZrTG6R9G0Tpm92mKJ1utfpumN8w0iTzGcu1IrepxmW6s9yO4XLNo3V63mmwLxm/3L
KbjZmWP6y1wqCU6v+tZ5TNhj8h0+xY/IalntV1qLy/RJ/IZnSM1idShc40WVyiwaHmsbp9YpehuM
1nbvnHDRqtVb2uhaBJ0ilIBcwpA0ZLbjwgGT7So+brFo6yqY1hBy8BO1WKb8CT0IEk1q7XuUq7yw
wUfbmdWs7+pSU/Wm1sj61aXNRlJ+vNrZG16z96nLzVUO3Q0Fa01Ofl6hD3Wah5rnS641636eo7i7
1qv3xnSrhK0mXs0fzlyr0i5q1dukhDz7OqTjuvWlw0J03rdgj69aUNuc+1g7Azp8Tz7zdhrfO0w8
RYFQElI19c7Btp1pGyruv95eF5TTBjJ9IV+6jDlI9vK8Ix88iHMlHc5TjXUGpzLtmUh3hXUnEiXb
cZbnDT3SAZIC5KUhrIdc7T9XkJ5owneleh7hBQFs7Usx2vDymVnmEkYItHRw4ca6yktKj52qWrrM
8ozlAzFUsdVhG3JBmAkyM12i8wFcvran2iXpi7nAS0hEN57jSYVJKvZKn2tStB0vpc6dYZ6Pq1sh
6ZwIkgdrdaqDX0FeLbVWV8iKle10ayz1KXdq9WtAb0e4SNFkbnVO9n4Uu096Vc38bIO+mZTVpz6D
1esy09Gw9ub5bU0OtNuOfttLgKHpi8zu1kznro9QqWqtM+051UWV/otY1yHzDVZHJrfd85jdYr2Z
7GeP6HbMuXp1WgtK5ZTlQO0+g22BbZP41IbBRMs9FREdNuaRceNdwju0d7dpWOadFR/Sw0/q7s1e
kOkPnG417zdtOk+RJpNh9A0Kz+R+fMwCSvQ0ckNa601TZMm1iLnq7c4Q7TVuuH6jA5DFcEgAEQMd
d7uFPrWsQmZ7FzzO42SJmoOXgeNlzeHKv2na4BwzmId6ujS1+xqakLTF9s9oNidQBzcFD6/peEZ/
ysu7um5OnMNLdoOVDPt06x0j3g5Y45+S+7KUjnBQMbNTFbY6PkejdcviN7oMc9v/ABhpbLcSF19C
RrxPGSiZFu2moKT7wc/GJfVSCtFo71G0s4mdjnsNJzFDupU25MOHF9J0G+Hn2gR8W7qXnYdNa9B4
ZVfS+VZ7szvIZLdcJ02Hs+X07ZatNyUCx1N/kl8h5ObxnZfKmhX7zyveapOXbzladc75BriKRoNS
eeR0pNBGk9EPkTSttfQFz896tuNDzvYqTE651ifN9tveA1tuhJAyMASHprtjlu0jIo3dqBnu0Izz
U4p/mFleMp9lBW61wqGch3jeXClatj1Z0W+ybOqxlmjK49v1Urt9seBZu10HeYC5OKZY5KBb2VvU
bsuj293V3c2wrV3RRLumFkHLCNcZZfKjm2nXHONxpOb6xb8xyfYL1xZyGQ4sjTfQdG0RVAubqvN7
LypWgdM20IqlJU+h7BLyOaadzo1rdxMVaO+daOM9vCoFNgTRdCPNtAiuCqB5+V02rcvJch6k8/5r
6gjfNmx7L5S9EQ1oza11On+kPKFk0K12zOpODtctkesY/csGrHorhhW3XHzN6uz2+QEjWE23I9e8
bISASTLRC5mzrjXdNBwPUdfq2eafQO1tr1u88XK7YBXmqUggZGFd/RrvELnqeKRPorNsv3zlnWv1
S4QwpFpf5s6m78s6pZncYljme05VWpvYZGtdphrkj6/y/OP5zeI5s0v27RNocVaceRAl01i09KrY
+9fevm8PYhVLZ2o1iko9m7bVWiNd2yKn+m84h9YRUs4lN060KzZzhPLRvQNYtp1O1cGfJ65rNm6U
y5sop/UqVb9FTSrywgbJG9mXaUqdnTWrfBOA3la1OHXrU1gpGpeeF9te3byJK+qPO9A9Nx3mvZNl
8qei61dGT/O5u6ZFNYXpm95jZovnKcGNupU1he9Y1nHo+xeXPUMJY6fNsa5o9VT5ZJAIjSWinwJj
ANLpu+faHWbjDW6HPlnOkYzp1bymL4IMkhSTJTn0a6w6+aRjkdvNBzDdiyzWUd3nJq2fsKdne5Sr
ZfeuTp0Z/olR5PJLg4DaQjYub6LZve+WZezl9vnYVla2NZuR1CwSNdK0RdavDWl297TpKxQnaVOo
2PtX7zDtsz1TET9BUijbFxh1SPRhLFjmbFMbVa6Iw0uvUDUxlV8seYOtJo9T1iMz7U3FE4X/ADmF
1ys5lrbvHrrdMs56tSaLrrXJNEteS99PoTfSWOO1YONYuGMP9Vzuo66wyfSbFlM5do+BtyK07lKf
Tb1YqXbioL+y0i2veFGsVcYXkqNZpFjH2NrVrEuqQyCCQEloptuXCCj+1x7yEPMd5M2LevzEPK16
Oa8ySQNSAA4uMhXnc7CsLO2r0++rsjNtOMuqDdd67C2WTZy3KtyLyAl5towmG8JMOIB9IxLWXRHy
qIast1TFshoy0ca7OSNWd2OutrTFwVlXWZOYrR2iFbWdvWZOQgZ14wr81BosvKuz3ZgJuGa2FrVW
aektMwQno6NnUQ8m9r/WYiOM2zj5Z3X+8nDpnI6MnChpN9B9JeMaTjeFmX9cczsC0k5Goci6zM7W
BaIyFs3aqS89Uzt8JC2zrTZ2xUdV5rcFdxRLXYs9caDT67obWgXiczaVv+f1q+orGqdM3pSSSCBJ
0ccOPGCjH2sMp2t2oTyGB1Gy57dajU2nJKTMiIGfS0afCUPSuudWi00Vto0C9k2UfNlRqvx5ddLc
N7HzpVpcVC0yUc+7rz99bqPWNUgKjqNVO5JodIYr0y41aMv8bSr/ANaFZLHTW97r9U0LjRLpK0GT
uFWhNDjaFobzPbFaKQ10Cu0/Sueb3uaz6RvFPb3Q8oz8SWuW+jR+mwed6sMvvs/mz/QKdWNVjcy0
2Vyyy3Oiwmqw2Ya93ye92XOVaPWqDr7fJ9Ok86k7vV8R32WxrJ1S2/2esVzS22V65zzO9SMBFXhG
Y6nyzy/84flYumc6Zwz/AEVjF9nErQ7r1z/RYaPl4ew4T6ToVI1akWfyWEGgIUNDHJHCvx2hb3ju
iT0jQdIrZ3iBcefbpM4dX2qEGZkQUS90v1Xp+vQeaa2VBl7jCzsHPVRhcafFHVrRrsZxZzLdIjYC
bl69H6JnNx70CD2ur1LaM3k3clTsPi7RviZFLaQa9hyds3iWkk0Ls1eM3XSLmOLV80ctur2HlCip
lmaub2IlHNYsObo0zLsNToPoarWo65ZW7fm7eU+1vKFeOEJJqXAWJ5nWi86RcOTaPnXmd6KrNdF4
V55KCkaF2yjUsK3rIsmqar56fybXGue3brHV+6usk2BpmWjFBN7O5yrXeWUabyrfWecZpqvPKtQb
VGdddKHpAyvU/LuyFRd1haz5iJJJXzM9AVzRxr0breyeerL6RruNbpVKTsfXt5vXsWD0xpxASZKB
LceibTiU1suR1L0DUcm2OcyTWGUlmc6tpaYJlbLE2jkPe7aM7UK21Cg6TZqNrcFnWiWuo4/vFWkJ
xxTMPiLx6Dr1wfU2bmYaLtiKVdu9FtElWV2FjVrsdEuzmnTMrEQ9x50S/dc+uL6tCxs6ffjzm+YF
L6vlGJ8tR9CUPRl59dnNc52RvSr/ANMx0kqnLyUdA3Feb6WjPrl2h2dlFC0Y8y0VNZczjWn39eXa
fg+6+fMjLpf/AE9lWrt89uamERanmS662zDSeUJwsjrI9i55NqTSqyMu8y/Vix/YWVFs/YqBqDnD
9t8pbSUTbKLf/IppIEghopc0coCM0zc8MumuNMq1ehqumd6Zg8jp+DUxujmaTMEFdt0uOISG549S
PR9PyHYrFk2zVK4tW1Qlp7OeCtGnm9enHrRo4Kv1OA2nP8+9E12pakcLje9wjxL+CwaIt3oCPsK4
aR68eD/tX51UBOBh0cHEzXSuz5RMiSGsj2r08uAn23DoO8LLuK5P5lH6znGF8dA9BQc+mFsMUrsz
koh46hLBFIl4OVacJaFlmLefqc8uBn44+reZqU49pltaxkkXfFvSPnnIi7WP0YpnB2h1mWlrzO8v
K5H3bhmOsJybSJChdr7BZptHDF9ZmMlmNFpueblGYbtsthtx0PMqR6K55fpkdmeGFzAAI9DTz5t4
WKlNxZT8LZOVsZshl+m5VfYHMItujkojBAld98sWNyetZnUtxr+S6/OZHoktw6v+UPJJqWaa1Zoq
ROpTb2vXHiyzy/ZzA7jG53p/aPrWic6/OChZZHutZvlZr+hMKNfXVAsFlp7O9Q1R0Plm14nM/d3e
rVjSo7PdFeZrY7dQW2kVujalxzC8WPMn+hURF74ZBSA81i85o21CpUTWuGVaDYMskdHz6v6pB5xp
rvLLTdczaahVKRp5ZhdLPl7rR6JXtMiKHdZnOJW85/1vdFoxn1tdqo3K9VmAuQps3PU87ZW2Fn4V
mWlqt2scC3nG0NKOYF5JwqZJoxfd4x32jur7m0d8YhoSUmkgvQByb84OLXPSyuPV3J9miYSRinkX
HtUoQDNIMldJ6diG881ipdxCPpKHKb4spXtD9n8NHzfWOllwXeWiHMszhJRvFTj2uPpdgxnxByve
sxXIO7PyiZR/A9ZuHa2FqwsjOFmu0AzeMSmuzCe4QT+Sr8jKxfSS4wK5qtFPxsP15yFlbVaPLrMz
sEixxcRYRBSslWXFig2NnZV+yOqtJTlXK0xNftiatYZeoOLRAxN1Z1i7OKtE2+rv7eyoEWOstoEP
UL68zix3POuOlV1za4ioaJzyuDUtd/nKrqDTKLjZse0uzVuuaYyxB5tuR6RN06SjcUvGw88bz8uZ
pIAaGrlxRAxL3Yej+Nl3Fi5tu9LsuZXKJzqK5oQEmAaVudct1SY32Gp1/wCufWmdqXO6QdXvpUW2
TVK63GuV3QOFEusjRJez1qLvEfS772o9gnqem6w1UvpZpRWgs23tst0mbzKVvtLrurxqn5Qcn3o2
bKavNvdw9iOpWF5TJ+RJapfJLFbstp++0vHHZbLaFZRlgmNysVSbX6Houmoza+ylCkrhWq5pDDOt
MXnNwm6kyvsZn+o8M60LvUHlmjKdpTWhWrs2oO/eb7fJW7EcjHfX90pmNel6zjW0SGbtNjqNuznR
c25Xeg0F/V7R6KiImJsreWqUjSmmwt850PImHobJNWwvbs9vPmjXXjRHmJXI0mhQ0NKeaa/E270d
kc5qvXMNMgWWj8BgyNUw2itUoBAEZqt3oOJmusTJ8+SOryHlusHLm06dFxcx1g5g416ZsZDvCTXS
HlC4c33SGlesHMG061jC4MazuNFpu1QObaXKZq+02jWyMmqFFXiAR2rFh01pClKOGsV1y+4y2ZHs
uaahC5bYtcoMdZ4iwMZzLcIPSvQtIvy6FdhAd5cqXe+2Z6QioWB5HwdscZjqAzS/qgE2JNE0Jxk2
qcqbN07N9syqK9I+c6Zrdy8311Tv0jffL9p9Fed6n6ho2Eeg7P5x9Cs7B5nu1uoex526vD5lV5yS
hXdYs3nrd8jkNGt1Em57GNjqU1QNCa1qzll/n8+ZECIaEpCeUDEXj0bgnP07zwnaojN9k42HA6j6
Fw7OWJcwDQYUd49BV23ualLyUZHWJVTtT6lWOSgeU9zq9rcUq0v612m2tctnWmWx9TZuXiIyzlTL
g8pNjk64mMwGuI2nbMJh/SGb5D6GGAanpmD6yUrQn0e00HNet1s/WDQ9fs4SToszlNe3JnmXoqkU
XZnlctrFp2jpXLsIPUfQVG0RWfXfrXk2NtTr2vNdK50yekomHty850ks5vfSA5WJFG0Htl2nN6hM
QknmGYOvV/n6027DahHG737QfIV69QeQ2nq3IMh9CWLzj62wTeKS/wARv+h+WLDM6dZWGd36R5Uy
6IySu1KY9Lcoqx5pq3nX0Nm9gnOFHeRnmsISSkhegmlDaDjLJ6PzN5qvfOtBq3O45ZqWQN9TxehM
UpIiURmq07+yk+jDuXfh1cxkj0jJLigw6jnnVhI8+PZHZk7cRUkpi9R0b9HMa97R7zmldUw+ILW9
swyD9H5xkXonngOo6hhevRlh6N6ZIWnPoyn61eY2MkeiG/STpMZTtzwWB9N0WqbHxirBTmltiZvM
cNRdfQPA+XeQrE65q9m5RT1a6/OvqPczptp6xjacVQr/ANs2vXepSU1H1LQBWr5Vo+o7rntmZ98K
yk33pi2eTNO3zzFEepsxwr01J+aPQrvrHWAUe4M6FivpKfol3LENVmMc3KNdYlrlQpe0Qtbt7mkx
uqweb6m3wagkgkqSD0Dpz484WHXrFl5IOYsJsOebX2g2WPz2Ib8jIgRmF9tK0GpwehsKHepTPpi4
U+L0CKpF8c0KdtFOaX+Cp+gnn9rsNE7XWs1zQm1EucpRJO3VKI0GLo9+c5jUW41DSMxi9fqmea8r
HdEuGUWO4tGNh5QL11Us11Gy1uzNqDZZGoaATfMr1mPTXq5RNQ4NDnoCLuDLLK2jvfblnvHRarVt
FaZ9d5fP310p8RoUDUL2qiWCz0MXetQN1b0y0yVLe2uoMblF8LQ3husi25uWdUjR3tKq3KytbOei
Y6dTEybhmpw3YOeTQ5BBvGzJ2jg8JmHTcOUNHKmiO62rtlHcUkQQaS0U0ceETCiXsfJRSLtxw5Rf
dj04RLbhzBpIwYUJO1R8fPlBSkhCKnYtlYOEFKvoKWkmEPPNYad7wLmcgeFjj4ayHXpOSgOs9DRt
obRNi7V+utx3uLityEzX0WiKhrOlpPcoaZ7VqE5BM/MMLDzrj2QgJaWjez5NT62CtQQXbZyPjbFx
o8Jz6St9jKtcXtFnbFSzukM6m4yKtbXP4pCX164HamNBvfKj6M8r1jc8smuFkypeuZu8u2U269x2
KQw6WnYanm+yuMS0e+Y132GjTdlg6hqLTDqsg5HaFxGkNcV1eSw7aJWrRt645tq3PMdC7VbCdssu
H72081wqQhJAxoISnjEQXfbpmOmeD6xIbyVVls3k5TJa805kCIjMKcbVdISuX9pSLu7pMzYIGOtr
OnXbtUZ50cTYI2s3U6TaJSqO7BEwdwRTbc8qExMQbC2NY+bOr4xDc7jvScm0qcy+V0Ok1LXo9fZ1
X+stSs2XGP8AeXcBPLr0z1qj5/INOFpyS0WnLc/d89WkbG1Q9yTGeXXX9wpeX79F4vsMtlEpqVOt
lWstLO35DV+tdvW+U+Zrtvqdg51MSMtE13XfPG7w+RtvRWSaNmWYem6ToGA5KHHoLTc9oHo/PMr9
BV/NbrbqnomMbJjsHtWUOe2eaFs9Kk870pkqvOspsmj4h233Gq3tNEqV6stP2GKgoWz5fhIIiCUl
o5cj4wsNM+psth9+fZDoTerahIHiNG3nIsvj+JKQASjOw+l67bekE/d8Iid61azuKxLumLMUKw3V
3VZ93EolkwFk7VKyOq6+k20JZF1WzOqrNO2zCLwCvp1rec1p+51rL9VmchsGpZZem0rQIa7wsquu
T1+bwRvnzWvSeQXs8jndkzPWa3RNRd07M75qLeLk8jwlDz0dfvP0rvuHU/0lRsZ3qUxvdICyeb79
Y63oUBXtHk6y9ZzzSCdwGW7ZitI2q3ZX6FxWs7tMZtp1Qi7EiY805mJH1JPeUdQ3jy609RZRivqD
p529Owlh8z7NVU6Pks7rJRTNrZYpry55pqHm9ptWo+c9bp+ObZY8L9MPijK1YstwMuQSDI9AVzCI
WDmfVuP1P0zNYFqYzHXIi65Blfo/KMnY8kJABGo5/wBOVy5Oay8lW0BZu9MtruozUlGRfXKLRoUl
UrE+heE/yq1rdUyzyFWdzTWvWpVNtz6mTb+MYMfP9cTrG94fUfS9GxP0HIeeNH17A9Z4T1Y61bnp
mOd7lb5KGZvpVnCTFZ4ZRH73S849KUurbpUYLLrNtwqM1m+BIcehr95Zt/o7zLB+pctxX0q8wv0z
ler0SSyDUHvn+y2/RmstkmslW3bWSyGmzfoPy449UeatEuLym6Fhe888R1/AsmS69KTvk7UPR3jv
v6y8+5t6cb4n6qwXeq3DZvocxhMlXt6fyWTazFqbLseCyvCF9CQkdnlj0bC5XJdo0KpPZzBssTyU
kJNOiKSjlEwjj0tGVvV01+0R7ax5doFGrmp5HnrLnzCVEZGuS9EPHTB52ipNDV4gcHXWKlOcbHqt
bZPeNkDj5ImnZXRhIHFyxMHakcHykOWLDBoLlrG44vU/R1IxzfHeA6Nq+F6aqWcirrsFThsw1zSI
APIt+qOtVUbZ7seFQvpan0baatHOettaNn+QYyHfou6+Y7hv/nquenc1xX0wrCPQDCUVyVCzcRnm
ZeoOSejvKtL5VLT4eFy/WvL2geicMbbO0rNpVDtZ7n5oqxyvpl95e1zXPNp+jMmyf0uywHe5yunY
zzW8qx2j+hRVb7F4hsAzXambOs3CDj7eisWhvXcP26VxzU6xkjdKSBEBoiufDlHwPO36FFyMRZ5J
62ZU6chuwosbxLkQMwRL6WTSYer3rrRbHN08XSvV6786XaJen2Obiaxb2FQt0jR5Wz1NldYWt3Tv
RrHP0o7lX6/fGlburinUhki8X6nwWjxNJvrvO7NZ6I5ubaMnVwq5CsU662GvWDlTJaWrNseRlOsN
TToEbUbpJ1J1PQsZamNBjuTm9SFGmbJUOFti67cE1OwysN3kOUDM8a2djacpSMiJxs1mERrR5Dvp
WK4SvJq6cQ/SQjIjmvtJuYtcjG85PixkOjGT6xy3zSNeOY3u9i+0nHtZrnEOpKNcvmajgw8k4Vop
LifiIBCSSRJM9DVy5co2C5zV2jZSIsLt3x4RHTg361hhz5pBoUAQU5vMnU3Vmr8bdI2s2t1UJicq
/G3w0Bck1Sdlqou2QUHd2lRtj2oSllrEddoisXZVMsE5Tl3GuUxsXfQ5SjzFpqTG9wtUvgaWDhAz
3Wq0zgld3ns9lLtTbLMUZ5b6nF3+Hpug9M/tc/RV3urVvSY3MYYO9EudA5aRWaXqXLMr/PZlK6HQ
69rMBnGrusmut0y49TplE2Rpkul2LIbFo+b1/Zq7lWzOsY0C8ZIjYaLhDdPbTNtoGW+h2Xn3brRh
dh13P7b2aVy5dPPd/wBNyydlPPek6/VMo3tHnC3bnUZPnI1O3+Qi23V8+wHu21zXI3zBXSQRpCRo
oTzRFwJbnbalocS/fOWsk250qv37J6GzQkgaSBqXYvRnHLr5YKI00iv0DXG2VafJ5y/u9XqetxWY
aq4zK1WmmQmp1/PdYRlmiTmcuNCqdO1yLzPUnuW2q30LGINN19CoynTJvK5fRaPUNiiXKJGtsbJW
887Qz7dXWCatesvuRxEj1a8ZIQs8K9Y27NyrpGSSsbyBN59Hx/Xpyfw8qqFsMUJKGlmRSERKNWs9
WZrpX7JGG7jpmuSsrR7ozgLKx7Rz6Vz+9FQb/wCas5D30/O5Xw3nHKR6YzDNdy50/XMd2Dzi83Dz
1v8AV4XXsFr/AKMyXWW9YdwL+cyPb871fJNfyvBvTzDI9WmoG1ZhpWFY2EAJNB6GpKExtd6+uKFm
3pC149PWTOb9ae+WYb6IouNRvFBJM0GZ9NF9EZzQt5hMm0q15G41/M6lulUzHW5TILDqWSwm60XO
Nr54/e79jw2rNKNusFkur2LFZ3X8fr++UfLtv64fQGB6v6Eyqk7/AF/GNmsWF2PYcZvj5/ncTdK7
c4+Esdv5Uy6ua1IV66Iol8VSbQ/gmlna02/Jz6/Lp8vn3ncap6HoeiHQLt3rfWfj63chnmjFSbLI
QjG0tqRoKs6vy6w7mmFeuB53o6KTaXcI2sfOiaGecX/zVlypr1Gvyluuv+SJn0/gWa+qq9jHp+i3
XA9lwmqer89pXorML+5zbR+dUkatIyHlS6Xjbcj0Rjl+kV3JfVdERac00TAMl5p5gzQrQyIFFV8e
t6Zl/ou5Y7Mzud36Os9Swj0PTMZjGyTQpJmFKuvpLJM59J1/E9aueEyO649SfR1JyLbpfC7PsuJw
fonOMl9D8MN0bSsKG+5JnnpGtYhtlmwGybbiFa9I55j3opHn6tcxo3ozGc89O1PCd7sPnW77dgWq
tp9oilJ03EhNXyz5TMaJXnURaE0+5Cp2XpE85nnWrYdKuaKzNZZg5ah6Epl5Ok3XhDvHSa/ZHFEv
nCqWpu14SXeoW9VGv0bFSiesFOPaNeGlatcT34HLU+0nULv5Yo/SQ9QcvLm0bb4+m/V3mqj+p6vl
3pzHNhj6EjOfQeYVb0NlGoQTKy0S1PcP03r5XvWm2/O9hi8m1Kr476jyKeaWseXqwlKDBJXoQHJE
ZBI3O50TUoSXN6ze0l9xo+k5lnjHmXMHyNZrO/egMwzz0JC4pr1oxGW2jKqT6FqWQbXKYjbtTx2J
3ajZXvKMO0+94mvbsupG9QONbLYMKtWtY5Bb7Rcn3sYLV0nqG55PSvQdcxPcpvz7oGqYhdLC5OQh
20nFQuOa3pHn2Q3fN7FIZ5O2qpQWjRWf6crLb5P5y7v1OqupReCVfnObrbsxVptRomws8d1iaxyz
6DmcLsVZyfbemHada8ffazm1K2+LxbYJnC7xo2PR+10rLdvRiOn27GHevZhknNUz6BjsK1+34LPa
7lVT3SAybYJ6lS841zfQ6rnOvyGexGlZ5BajD0HV+WS6FYM0f6BE57o0PQdAkKpC3qmVbmQ5pBkn
Rknw5s6/xktBYS1etDmQQwim3Vm6qzHhy5mCSslF0nL7EQNs60uem6ou1Q0HbeNVsMrVHFlrrG0M
a3a3VSlJ+tt7TEQlqFRsMvUe9khIu3MqzZnVPiEFP3CHhLaip2WSqTmxwLW0phZ3vBiYgK/ZZCsO
5+A6S1YVZYBjZmMFYe1bkpit8LFDs7Azrrc1Ss3FNJvjDzHSJdSUS6k4jnNMYTsng4k2vd+yjpbh
HzaouWDWGlVwT+Tr6UHMycdWOR9ZGwQXGdZxU07rMlOwE08iETzSnISpzZ42Rmour3OPrV8XV7cv
hnlpkc/lb3TLvncRM6BSaZzCAlJgtEMceLKB4WDSYWyVW49ZImDJkISdokQ35pIJJaVGqe1JlULk
+pEpa6pH3qJqN6XRrLYKci5Qdbv3Ck2+VpT221aHvkdTLy7olisFMReIKr6DxpFtlaDR2qbvpsbT
dA65/aLDRl3it1/QmVFvUhn85bKU00CvVLSOGfXeaz+Qu9OhNMg6Lpas3uNlzeubVnMDskXjNUR0
vm51jKttVi+jXbIOmwUuxPYyFtvPFKP0bWj0DU5yX4ZtqkXm+sqhbQxe+dN4cefJL0H5vp/Z56S6
9/MFSDrd9czLPPRtbwP0f08/6doFJutXmYNNr8ywhR+i+isy0Kp3DNtA5ZffuTrtUdT8p+mYvB0+
ofPG+4blPpLtL+TqyEgiBp0RaEJYV5vvl0zPX+K2ViiZOaja9kGuUTJ43mgERGAO3oOyP4mSDGQa
dQHcTILYSXBHfg7ZdnTB9y5u2rrnzeMXAbyDZfVq649OrR7xh8Hrbj0dMSLZyni8ad+rF9zT2bu2
ynca+Wxft1HxfRzp3BzfFlKNV8ejyvO6BsWS2J/KZVgROvQ+m5fWt/znM/QdeyvUJ2jadm+i4avY
MotXKhavb6Rbc90ZrVZ6nZrs1XzK07ZiHoDH6BsGgeftMeVrQKBonk+iLlvV3DENA1Pz7y9KYhn3
par0bc6LbPLGr3Cm6FwoGrvc7vdYtsdS7VmtJ3zE872XRsf9IecYje7N5l9A9su1XKNU8r58lBkh
RHoiSImFe4epmeKbvq2SNNNzGbvrynedNsbYRDcEkQBkpSvVzSclY6EtXSi2+RpVhk4RlZedRt7y
jWiQrPedZ1m5daLcJGlzUtDRtnKnXJ1R7JK1btYGVXlvOdOkPUrSySsA1tTen3Y6NcHdXfTUXC27
jTLwdMs7yAE+zrVxTS7qKlYH0OzsjeoWfzn6Cz278pPPfNyZH0tdPK1+3zzhC+nsvxH1EWE+k61Z
cY03KL1KZRYNUf1+Vqly51uTqrmFwG5eh8KHo/zDp9qn870ivxdrznR/KFF6THq2veaPQGmePbp6
h8s1j1lnNM9E5LrGX2vzz6IouWWrR79WrZgu8NKDcKtZcVzi9egvJ0z6u8db67ufm/0TnOnoxjZf
KFEQkAiItFNXImNdb+lX+ObzcabX7vRbIXN7gW1xWGxDdAACiJavT3SVc8o2Y71exuK3Md2fCTOB
nu9cm+kX3ciIm+9csDityndpwlFwE44rc32i+z1EQvz7Un/pbrOLZ85BUJPnW7CIl/15sJNcDYyg
J/ixcdRHSvSAsHCHnmaTDqEd4Z6Gpr1zMY1iKXnoy8eVLx6M8xQ3qvIcY9QHiPpbM9QaVSDuDaiQ
VL9OMbDnOmVlcpDzma8GumeQNL9J+XtbsM3Q7rmUrfKBoXkmmdZv1dXfNHoTR/IN59MeX6z6vz7N
/SNMs0jSptmtpklP9X1az1qzZJq7GsX2vxGea34/2L0f5bueonkWw86vU9WzrzW2SkjCTTohjmhj
BNb7tNL0Cm3fjPtG0FBTlA0bNKE0bpMwFJMHfdk5UC7y1CkbdVoDQY+kXx3QLDYqc1vURTtBLP7j
NUVzc63Xb82oN8fZ7O2ymMb5D0rR055cp/NcxYL0TXY7PNGeZlbLXnhaHVafqTPMtJkstsV4z1jp
1XoOsc8p0KyZVL6NnVf1mvZxrS8hv1syGd1eHyzS4DFIwPd4ncFu+o4g13LPcy31hj2uztVlpVFD
uhY5GbpBNrZVM51WuM9DKmVucyvRb3l/PRIuFs7qgy9kqmYEuW1KHzvRHuZWS3UOP0OEp96kKrNv
WtXtDOivbfGIl4GFtEOqbRCNXMHMvYgTDPi9KJRIQ7JISlRED0Mw35NoFo5tpyMTL95A2Ddg8i5C
AYceT10jvH8gEqXMdY1w+ZIlWLWxFCyUpAcH7BtP8op6uPcO2BSDdk+DRx3ZG9ZNpLkyfKZdHTBo
ku8gGjjoz6O2aH3Fu7Q1cdmXRy1Jxz5OU8OvXgjvzR1Lj0Pka+PRaUL5I5g+6UdAlZclGAZpUaVc
zILSRpM0qIkmlJq59CUQJIQkkrMyJQQsiCuXQwkGRpJRKAIwQIEgySokqUAQIiQgJIJMEWihXHk3
rzSw7RV7tSL9wsXFomsylCveeU5nz1mYR2yxtx5qU24pU6dc+bvgrcOOS6DbsgrPApfW6dVkm3V2
bKd8+DlTTpLQzFJoM0kFGkERGowaDBg0LIzSkx0SCIzIEoEZkRl05ktIJRkkIUQMEFpBhIMlAiWR
pI1pQpRJUlXMwQCFKSAQPn0IIWg0giWRJABKIwCIwhSkhREZpMBJAgZJJSVEZAkmlAUklJPQ1JSl
nXme36Ni+02FtTNHqru9x8R5+1TlhcJx0zd5DOmjmAS/TmtabzOtyFW4XOrZ3uU3gtq2LDKSzdbF
tGc1KxuaZMT1CsE9FR9tLN2WiZTUkEQVzWQIGSiSYJQLmsGSiUkjUSTMlBJmkGQClc0LBLQYMGkJ
6c1EYIjMBBqVx6EYCTStKkkZggCUgAgDIA0qQACM0kQIAiMAGgwYBEDI0LIEZ8zBpIGRpCkAgDJB
kARAwnQ1r5BnXWXoG4YHp280Cj7JnzHSe7XzfoVs891zjL+rp3KdIZRLR1I5ZkLHTtko7az3WJ8+
6ZaMIndpxKhNF6VvuaQuxRtfmbhTZSoRF/skfl+W2ekwaAoISsBZIWRJUEg0mYBAzJJrIEo0kYME
RKURKNC0J6ElKwCBkRpMJUCBp6kgwokmFIJYIAlJC0hJJAC0qIICkdEEoAJIgkjBpNKiIGhZGCCQ
DSCIAyCiJJmQIyBERgkko0loZr5I5V5lsGrYrrtq4UnQKZLP6XecA1JeGwXDR93fV+cpMe+mpHPM
ejdM2XPRoZ9cJ0azYLYdnxnN2Asvo+Dr+nZM01l5GvKjDXlddpUDo+WU5JGEmk1ElaTBJCgQBGCM
BIWfNRqSaVAgRpNR8zUaVJNAAMAlJMJIwCMKUaefQAJUEmQSDUkGCIjCkGCBGgGYSRrHMwlBAghS
eiVJBBJgBSUgwZEaSMjIySoghRAyCTNBkCMaIR8U8IJjK7TE2ml30WLjGsqRcqFes/pzTnpFpiLI
5ka5ESrqoUBtMbLJ1jpLozy5zWUTehZ1n7cddcnYi00Gnam9ZJm42EtSM9qM5Xow0klZhSUdBy6p
6JCUhClDkDJfVKSMBJr6I5Ah0AIjSsySaVJJKgtSASenMJUB16ISkEZn1RzSoIMuiB07J4pCui+a
unDiQU4RyQZE5Xx7cm/MiIkGAZpLolJpWkgZAAkgEZGogkJBgjCDIAzBEY0EDly5wUf1tD3uwle7
82qISXhH8RHNTLsOg6FyBHYJirx71xxnntccz0E0srKCsHRlNiLlnEBBEOM1Pxs6quOZCvxFuiYC
VstcnetSmpmsS8+1jp5NUj2jCZvEdR2nPrbbXVIu31OHJSrjZc+heZS97p8MAAZpUXMFyBOtDsue
VvipSU8jHW76BlUHyJSB11FlnCgkwgKOz67A5KxKX2yVqPS3QmGRfaU16axmrkTnQ9IxPZlYHAJQ
okpUojJCiURGSTIwCCCUkLSaFkEhJgAgCMJNRJPQlkhDeDj7FvFWulbuEfb2PCWps5kGj1LL4vgk
yMjSskj04+xepXq2UfaV5RfLJng0qp0nW2w6uYXq+r+ZcGHXbbFXpjtByLumQmwZhmW03HOLjTaP
r8fm+wd5DkfSlNYLMZz0Cw87QCJP01ZckrWt4syetojctB800ZuvQtyxCPmmiZDizk27E2/Gpcjs
3qleQV/tBSDiKo3ASm47J5p7Oa+8qlsq3o6h5Zejqtoe1Gp3+F3qWkclqEfbJ6Xuz3NtM8uUnUNJ
uEFyyuoW7h6EVnNu40vzOEEaSURBaDJINSUmZERkAEgECMgREZGYCSUCAMhoZhJcK8x1jZMJ0LXY
3MNdqbDVCj/Odnvnn2qt+ZAgCMwXqyOw+y61UoXeM7om4Q+W6RYspda7mduEjUape4yROEf3/rX+
3SR41qazPXM45ae9rsvQC0SmV7R2E2wjZyqUa/5zlfoOa821/lc/UsBhFy1vFdMl2tbvjzzFQOa9
i3DE9VcLePEM5AovhFwfm/iel+mMzY6cwjJt9WvMdefbRtLvN9IEI+xHcvNvoOiOLpBMtBVTsu3q
kW6v2CuTfbChs2HaRZ7J5nmNir9liJSEs9Lsk8iuhVf8lKBIVzMyMgAZJBGEkRgkrIjSADSCNAWk
zSQAAAMtEBJHCBjtY2bArR6Gr2UbXR4TTYuw+c5nUvPVTa80EFERkoeqGeG63Z8icegchz70jV8S
2yx4JZ9pxDSFTEMcDCajmDO126xwrU5vnW5nDdpp7W62qMTD2ZdKtjumWfL67stZyPb6nh/oKc82
V1Fm9VUzz5e/RPnnaBYusBKeaKFyPTPSGQ69luqduPRSOLlnFwHmRmu7eqMUs1orllkKJn2YtZH1
YLHVLHQXV5y7TfLXo6tSzHHdavmbwNe9A5poVetmV6Z1w7c8Xr9OvHonMbv5z0XSoNxWtWwmjajq
tMe9KX5mMiSpAMAEZGSkgJIkqQEmoiQauaiBpBkZAEYSojBHoKiSnhBx1v8AQGcXeXk6nfaw5ksw
07D9AXiVe480gGSkBY9OSmKQ+0cantmUZ56MrWLbRYcJtGwYxe30l3610p+uxWW3rXITr0Z9XNcq
GyV/ELXtdefNXLuHlOkZIZo+tmcWMsZcehWXnGERcfTdO8/abu+E6Jysht3OH09XPQN0yO/pfisW
B/Bt5Vw0gMQQu0egcgZ62itXHOPPstJONith027cs5lLvkec+nqxXNM4Z/oyM1wyehdI3Cn1i4cu
lv4QlD0zNO+d0Sw+hZTE9co9t86bdomDbA080RqOZkZmSQlSwkLSSuQ5kRoSogQJSQCUSVJM0gGE
mADGhErnx4wsb00KVewsy+nzjm9OtNQtFVrDfigiASZKM7/cqbUpC5NLTXq1fedFt0pSJG0Vlpch
FTLiK4P4mmWC2QkwuqdJ2qPLY3oj23Qs04rL+UhOVijYGxxdWsEHDy15hKa35yd4ZVKbstZdLfMH
ze33t1X8y71t3MxvOPdOWvFwtLrXZ5Ge0yFj59UZIR3Df7InOM3atpEoZb6I6ybfhMOIPqUcbhj1
dszI+jhzGoU1PmhfdKnUlCt+3NPVu8k4BoSjczjSH5qLtKlESMlCTfGvNyQDIgaTSZAAgQAM0gGA
QBjQgrlx4w8aq8P3cfK9pfq0RX5qpWSBrHDlyIgELMj63y30qrqm427TNKdXKtQd9jqbeXsPYRAT
LmvU1mOVvt8FaO1XcTtQgNDgKNZb0ysPSIi7DVntjatH2WwVkYQFl1WLyWNQfdY6dEd9cd4/EIkd
GueWVrkalEQVyVyQ3LrYNnquacC590c+yBJbdVMsINeZm4JSloLTdi89Vgudv1bA2vRLTmhVy9B+
cIUj59+bVfV56AvGR4426F3LQPRHmXO09p7QtwhfN9fLpY/StNwX0Pb/AD/6DbeZqFzBKQaVA0hJ
LSFJIGAQBKNIAGiErkG8LFz3omn2WQl69fIfnaq1JYbeOuK1xqlBEa+QMdPSNoxKm6Tcc72xWX3S
y0Flp9YoewsOhOouHmeWdpjG+4WWqSXPr05xlR1/Oct2y4ZvynrG24Lfwc5Ez+QZxqyMnjvQ0l5s
rfKa08oC5lBRe+L8v1rm52694ZcZSGmu8eiXbw3LvTqGhVs9IZjXNEb0O6dqFcpKApHorMazprLJ
6WLTrkQpxNcc413RfN94eZftlpwo9BisNqZdNg2rzjq8pHVrRWOGSeqUbf8ALdQz2mXGr6PxzDeK
754o2hb9L0G8QEJGdLvaM+jtRYVtnJVLzCgIANBgA0kDASZGDSZAjNIWNCI0DnAxGgeicJeejeGI
bdBUzX+6fPTXasCojRPNJpWhRBfpGZwez6rQIf0RnuY7y2xfSLzibnccnnbH3p1buUBbmkVKW55W
pLhIrqdixfXagNEeYxTdgcWeqW6tcLfW7NG5TSdtq+JbpbvM9b5aZ6BlKfdjjWUvF+Yatzd+gtDy
vYYCw9wkKHOBlcXxfmLV6jzy19ZSBsb7JtJbO/OfofP7Mqm55nHXVvQ9VTxsD9j1kcU1x/jz3R/O
PoiQ4+dMnS4070t5W9BdhJO2uOaZZKNdaPeMf2nOZSyx+d6tV++A+iMf2St2vLdIlfN27TEJE2d/
Xo6TovmFAIlBJGk0KIGREZgjABAjBAaCownjCRN49GYn39CFjOv02H06haPg/PYMGo7FCSCFAGY9
G2LB7fpOf1P0llmS+kmOGafoGCut/wAYvbno/OnReoZbDPbZpMO3YWvlXZbEdmgM+t2p47MTea7H
DWDET2mCtbWtZtqmeZVvlm8zVk/R+jPK7Y4+STBq8z1rirdNazbS6HpIjZE2fbtESGP4dzVNeq6P
bIaxyjRzmGhNZDzN6QpNmiaHVaH1070LBsWNnfnBz9PspZnDbXnd+pUdktLWeoej/Mm7QHn31NWI
vOFaPl/pWCcU7UaotrBQW21mRbYnlXp2dlcf2RPn7OvVcb5i33U8r0B35xyhCSBgkkYIAEAADBAj
ABkQPQjCSbRUTIb+2dvJDjbYvm8yTVMkufHHoFunmCACFrPddFyTOdLutQ12gZbvTfDtVuWJSOzZ
Y6u/RvMsWnflGZHZ9grkoqtd56kxGvR+KSW05bLcsl1e7Uuv6IxqGtpzmTgsmsG7RWAQ5a9qRset
btJk2zXkbDQ7nk2kvIKQol960ixt5xvU6w64NtopTLRWNDvzOs6weSZl6BqkJpTDL5Ts4tTWPtFu
zem3xhVrixr1A2eCY3qFo9oEVzvWY6FB47e9GicQjObrRbtk2jUK+1i/R+Yal1z0Z6uZ1SmK7NHV
K1uOzDTZHM73C51zNBAuvNJkCABqSgKAIAwAkGBoYPny4xkOJu0cllJyLlo2gJWHkIyE4cuINKiB
LI523Q9eRPlLJg5WQg+8nF8JhEdYekRJOI+Nctol3YGEo6guMzCtp5US+koxt3g3c/GsJZuwsXWA
5MWDy1Naw2Q5mu7M3zJupxq9sVS8tZ8uim3aZ5x3I+jzpKay/Z5HV+Su3FKyuno3N8MTJxjcFoWr
vqhjsZI+lefnDtYV1OHPpOWGsw3I9D0R3Qc8sDNtYq9XeHNBmSkgALSkzSSUgdEmkERoNZklPIiB
EogAkiMlESiACVEQNSQRgtET15o4RMN00ezcguYniarqVioFni8/juHMAiCkqSvTdLz3P+10r2hW
nP8AnpFSqWqMsz0aYgrD1r0o/gswjePHRtFqttXWelmplK1yvdrW6r6Gmc6RYGWaafDwmjimQ0HR
7Jt/Hz/BIkdmTkk7s+S11fPk6Pga2TDkcv6Ho+adOitj54z0ctk9EcXHRssuko3a2PbsJozx1ZPQ
3fIc3jX/AG7DabonLMKlbpstipeHwnaU9Fq8n6jveY2Cz1jzLA8QEKIgZGRoUlaUg0ggoiBklRAI
NINIIERggFBJEtBmRAGAQAM9ACxz4w8NMem6hw0x7RdBiGN7bd8N5aVidCZJIJSYBl13fRsKqmuW
bMd0a5rcrPnrbVqRSdohOrpPKjWR/UXcVH6/P1SSYTgr0lQdQp2aDXJ7pmNJe3C15zr1eZWAour2
DLM/3m7eYq2nTvQzPzrN7PkOiSEdD2xvWLE5zXIWZ2/0lm3S5HX9IaYhqUlXFT0bDWcQ7R7Wbe/h
5G1Zjg+4TXC5wE9BQ75VmY9UvM7wzfLbOZzo1Ti5zEtif4b6Jd064ZnpnkeiIAQaSMEoElSDIyUk
BJgIUEqMJJKkmk0ggRgGQABAAwkBREZADQyBnxiYOe9V4rX/AE3JYJs/LK9lVK4ZQ/SGFZxHcAaE
rBA+m7aFgFi1fM676UpOMb1I4JfNXwht6EyzveUw9csVI0ysxVhuEjXJFjL9adacI1eJwfT73H3u
AaVW1Zfnvo5LK5cIDDN1ZYFsWg+Y6ui0en4fz9YfR2Sa50UEM6bf6zS8FaHYfVNB56VzqFmh6Ptb
GA7SEAzvVRnuMnmmjxU3lOu+aufoZ7XpqFe1zQcl1ONj5CNf1TjP5fvVCvmNbVn3mre7xh2r3ODs
WbaV5Do6DNBgiCkAgARBJmCQakgGCASDJIIGREYIwCAMECMAGQAAMaEQNHKLhZL1Nn8RuDvMdErb
C/5dqOQwmyYrnbLmhJkZJ6BW3ahhkbskfmfoij45uMtgt01/Co30VlkzYuM+uktL9SIGtzu3Qi4e
0cYh7jmxNcS3KpwurV64nToOh7X0jZJLCk3rIKbv1l8yVlDz1DM5HE+i8u0qHsJV2vM9SwPMWyyn
fUVOgdL5UybsVXuVIZ2tt5t2rRPMuqaC5zjQlNMQ9A1rz3Y+w3QqHa5CsWysd3Ll5EM/Nrz0rI1f
jZuWHbXM+da96pqLqxU/y5H8yUhSTSSkmCIGlKjIJSogpIBESiNIBAiMAJUkyUQBKSQM0mAAAnQw
vnzRGwpareI2Wh7JYFtkZne8/sjXLodvzIINSFEs9M2DPcvlNbregV7LNee5DcrxlaNao0JpXaDs
amDCXicpmtVrUw5pre50htpScuttcr+rSNenXTGn3ddQsXTP5qs0Od16JyKLSvQ9CzvtpFJmKrbG
FoZ1+3ZpF6dKt6Zba3X7EqudbpT7TJ1CdbZnfZfMO+gMuu6wuCVDRmuecCc39xT7XAzrOxwMHeGd
Ti4ldmstMstWsUXbypba6wMJZKRGK5pM0KSCAAI0GRGACBEaiCQCIEaVAgklEARqQZpMgYIjAAAI
xoJhPPmwgkS9iQ5aybt4hvFuI/ryhm3DiYIjIwspW2MoJo+N/YIRnZW0HPdoGSmoiT7xbiQj67xT
xc2ljLvIdrNxcDYFFOIaOnHCmMk22a619lZISGZsn9350hhyLt0MI6KPpc5Kjx1wsNWtLhrRYLpc
LwVZsjiHsHOHb2OMz+wN6g0Fs2xWF14JSZpB9tCuWeU7gTnSbVlNSU+0K7ZvSORzOv1/M9ZmshqX
LiQCAQUkc1JBggCSZAwQUkyAIgEmQNKiCVECASoyBAAEYBkACNd+UkI4sYItdusBaIywy/Ti8rkh
n7uSyauN+KTIgFEBqm1Zllj3T6doV0zyO1WtZ9sDbJ9PnIGc5seT1GSxTdjqupU208GvGartB1+v
8bjTmVrU9xCORrMpYc/fXbNeDLL+u+zPmqr8ZC3uotx3Zc5iN1684RQ9r0rzccpEVFs79PzLuHZT
b1znld1qFsOb6DDYTQeXS8ejfOvV+mDsbWBZWrl6KYt8ZrcxG+l+OL47d9S0qI7YzV53TLTgkzuE
ND+V2RJIiCQEggZAkqUREELIAiBkDSQIzQsgQIyASDANJkDACTMgRgHoAMJ5xsC69XUqnb3O5Xc+
9Q0WTPI8x9BZBlTDkg0pWSiWNf2LBoLZneW78wyq+3LJhsma0ze6qxtjM8uujtpLRcXostVpqHsQ
pdsyvRIqMslNqVc1K5NJqKx7nuGeaM2wxev0/Gdk03zJUT2TbOlWlHUTA32qwepwWKS20Ytsjuu+
b6xI+oZxznEHqlL0CAhp7vNnHus087c+mp+hfPmvWThGP3OE3PQaTeqhbq3IIxb0HmGBWz0NE26n
XGpzSW0vFc5ODfeNmIQRKQAlIBAwkAGRGDSASVGgGk0mYSoBJGCCVGRAGRpMgZAGQBkehoUEoj4D
v66zjPfRlwwvQZPKdZj7Tl+Qek8myWM58yIEFguus7RgjnZM5ovpKCwvZrf5+ntzxKr+k89Z6HGS
EMnPdhpNTslvt0M4r1vXULNiGhdcrk9CRTtIzPYWEFlmvQWNejovzk539pg2uab5hqZ+kNFrFa0O
OsHI2lB0blQ67smW6zUIHD4OR9WRU0h7ldOlLRp3nOa3oQchQfOSTu/qLz1q/fL9hYWXzbpN7zzT
Kbasw13Nce9SYZTfSGZ1r0RRLpke055NwUzZY+vvPH7QglJgiCULUgiMjJXNQIzSRJMjUkEkwCMw
REFEQMAiBGSkmDIGlSQZaNyUEIj4E/SHWoa8mLmmzOy5ndqZWdTyDPWHNBEojSnqrUN2yHOdOt+b
7RC4br9vwac23Gqv6Oz+K0RtLvqsiaio3NePoavO2zxq9j8011xQJWwVxhYcZ3PgzzHaMlofpmL8
+6vPYe39BS/maslt2ssKXeoazp4ppmmt8amNQx/VGdexni426ydWEwyh+r6IzzU4WQotzp+bdG9x
3nG9Ib+a9y0Pv5frcmx364ZDeYeczfcMgjHOJSW/XrHr1AW2t3rnh+nTHm6iklAIyI0GhRJWEpMw
CSEKBpSogZAiM0mZJAURAjBhJkDIAEYAMiBloQWhHBtXudh1GKl6tdn73ixqkpE9U0hm3boBkQB9
EWXUIShtdAa2dvQ7dMUeQt1SjLxGVy6vIGXdtIWYYUx1dI147gI6zQLa2qhJldS5O63YrDG1yeh2
V15VGai4N3d2tOZE/ubutumLrm55s7CVdmJGvyciy1GyjPqizi5FEc+kIntIRakOLlp3aDxpEL3b
s5TYta885jIcHEhCc2vfi4ZFy5r7dOK+Ljn14N3HJqEBBoMJNIQtIMgaVEQIjPmSiCQYABEQNREA
ZEDIAgRgAAgYMgRgaCDPlwbQHCYvUbNRM88dm3jks+biosOHE+ZAKSajndLiaSxmkSt4rcHeG1Mu
j+ky9nhJx1BOJWNo0SlMxosLYn0FF22ApV7DK9sKrQ+HMadN5nfO1T0bvU6uxrkpsPTG4Hku3bLR
M6Qhukn+4T1I0gqjOv67lUZ0m9kjshrnGd26WhZh6VfsDXJs87Ses3LMMyaPvQF054XC73k1oueW
Y+xHMJNKVEYANKSJJgkpSRpAIxzMAwSTIlJIyNBklZGkEskGklKJIBgiUCNIAUSTBAyMEZGWiIWk
cWcBw2y/0TU4iS7ybWTJvTahpWSZ2x4EkEpIUFaT6FybLZzWKPe7lRYjVqzn2ws8r0+Yg52Hkquq
w5Zwbw+r6VTLJAznBPLOtUiIa5ZlVO8rCwO5WHF9pj6rfYvnVXuT1bcdB8z01vJa5ueaVuWr2aRP
N96XsOPb5x6pod685TrXT5l3U6W0lOFus2Yx+5itS2e4Tqem2aqz2e1a06DA5lU9X0+lXKn2TyfW
kEYQokqCT5qBEkkmklJQZJUQSRGoiIjCQZBK0oABmAgAySDANIWkiMzQoiAAMiMAAgFJ0IwCJjX+
Hq6EyP0RfckfXrMLral0DAvSVCxOKbkk0GAOpaT6Bwiv7jFZh6A64doOkYke65TRfQdbqWoNBlt4
hp53EIvT6uzMbLrqNqx+2v6hcWqLY5iIuxN/O+szlP05vC4PsSsF0jXvMdMLWN3fVay1ua820Ti5
9JWjFfRJ8hl+pZPqkY44uYqSkMUc6Zg1Z9EoeTHbMofWqff69P0y8VSqWGzx8p1rFprVg8j1tBAE
RkRGREZDmQPmZJMJBECCFAiBmlICuZhR8wACIKCFIUZEZAAAAEACABkQMAEZA9BCiLm0gOfp/jj+
/X3MF2zOr3FT8BhnomiYlFcSIINSTUeg+icRru3wOUb2vAtG1LAOvobHc59O06vafWrozr1H1uo0
R1M65FvqToSalZ8Xu05jTjQb8ilNL1Fu/Peq2auWaCl8a1+kYzseoeYqcXoPSu8ROZ5oPmel8u3o
+z436AhJtLB7gGpVO2vpWg3d/lupZnHQ28+a91jLBHSODD0HDuKhpdHo/XVpCOeU63QXfybH8lJM
JM0hIIkgiSY5qIiIGhRERBJgiMEAkJMGkEDMgREogCUggowgGAQMgACABgjACdCMzRxbwHHVNYoe
lVm0HNNjpDgUzRclojHiaQRK5rUq6+jaJjktsNS0AsK0vQcPd7ZldJ9A1qhayptNM1xztplLHfK7
K9YmAulbpGuvqLPSVdm+9d7SXKhaU9pFqXRHDTH3m+H5/rqdC2wV6df1egujjNPe0PRafMSdwjfM
UNwtG4QdUtDWUtHSCyjTMO0PT4+kVagvNbuWUX6qXKv3xhnmjMapzueL1Xpz4KC1kElyQOQCTQZk
k0pUk0ggEgkqIiMwkySkGQBGaQZAyMgRGDCQACMEAZAEZAwZAFoSFlz5NoVo8uxPYqddyCGMbzW1
XAMePJJkQIGo3lzRW2cv2evYfvJRvCX5xMv3ipSRinD5rDqTFLsXJw9Yxku0jpJ2yfuY0SbThIph
GnNMrIwjTkw62cV5lyW/nI1kp1r9gPPM6bmtSXWyuMWjCJJqIuhhPSf5wsryigSkpcSFtiK3wD2y
PqjHI6Sdvgavw6WW3iLi7DSa/wA0GhKeiQSTNJoWk0BIBGgyMjIiQRmlREARggAEmCMABKgCIyAA
AMgAZAwQ0IjSni3gmdj1mFtdRuveUJmzjhXrNnVdZckkEGAozsG7weVxtzbSenVmj6u2zPQ5vM5q
+Vyw9odEvwyyu8OFq2as2V5FQV4rWbaa5gNHh65ZXrJ8pxlmcJktsmMyZcs8db5L+dqrwXoOxYfD
OeEVyHeWNu67Mpf0Li1NkGsO2D2Q4veimXL0pn1E9A5tmEn0i2Et03S91vD68q8borIsY63vWbfX
8GgT227LSl/RvOMQgBJAGlIIAA0Ek0mRoIKSEGaQaQgzBKIkgKCVEAEgwSiBEDAABAgZkCBjQkKA
4toJruehZJtMjyg7pWpWwtK3h+20rGojlzQaSNRLVcfTuP5feNVzq73PO43X6RRNugcx1d5X7bWr
JmfW9UN+1rmo2yty9cthVmdzy7oqd6zAavXLJkkJuFSfEmyQrjOLzneWaftHmajcV7dquIafN13D
6wV63TlRb89pVY2/E7tbILBamra7hBXPrIVfJvQOad9Yqud66vOKRuNA1en3KCiZTo5i1+ZNrvst
n+gQEdJ4rVvRz2Qo9z8hV1KTSkwEmEpJaQaCAIlIJIBJMEQIySolJBGlQCVJCkpUpAMGkjCVkRmk
gZGAAWgGZklpANfSc1gu07DmsJruYP7u5rfnTc2uBQjZKFJC0ka7h6cxSqbzXMm36cwC57DhEf6H
y7MvRUdmuyxb7PLhQr5yp8rfJSIk4Ge7Vaw5LJ3DI7RYp2Sr8zhuls5exsycQj/zlrNh863nbfMl
I4K17fsi17ONI82Z723fWF5Pq0J1wv0PkusZRWqJCK9GaM3b94Gv416YpWRep8gs93gKW706m3Co
XHJNdr8BbY1NOvWJeh6ZdMc2iq+XPRMnm23Uy2+P4EkGEgESgXNRAlpIcwaUGEpSApBGZABJkCNI
MEDBAGEBQIyBAGRGYIlECMHfVhSCaQTTeL5iW4W2Fq95oto4Rsvg+213D4nlyBhBmCXafUuS5vql
jy3SLN5/tO0YTD+lMpy70jE0XXKveVVWAu8NUoOJ9CsJKoXdjGy2OXi25P3tNyFRtWR6xh+izMCm
0dazStNxvP8AdtE8y0nivZN7ybTa9Y/NVY7ejLK/y/T+EDjPo3ML1EtsWqx7frArM5n3nia9UU7C
PUHaEna/Scn0ahb5aomsXY8+0c6DZ/Ocb6LtkBX7b2wPa6Nl3pGUzHz1wQRqSkAkqIElCjCkESUI
MkkRAiLoREaVECI0GAFEkyMAGkyMJUDJIABggaTA0BKlo4toVpP7tW7nRL/0sHKLgoScpd0y2ss+
fMiBGXRC5r0HEZHG6w1sslj9rvmWcdapFH19rm2mTEDLPOVYn0Zkz1yEeS1dql/rNd0mRp025qcr
OVyk3egyOgJzufmM6s0ZSpLUeGXRPPpodyzm1ztbsVnELEsXm60jDk3imubRETN66V2ptIeyV6ky
t7iaXbZeqXJNFiOfSXt9SmoiVjJUoDrFlJ2eqTMPLxEhHR0/LUtqlB918TU2QD7d+bRBuHC2wNhx
SEECJIUkzSCUaUkpJKIEZEsjIjI0gwCIwZAgRmQIwL8sEjjyh49xZHL+Nle7/oz5M3EY7gmfHigG
glkFJdW3vXmfZ0mzcIac7wT6XgSsTJxIseEmiuxaR1tKXckyiJxvVpWairOuOTLMo+b4spGixM3a
qk0OK76BI51BIJJqBur1oCM1rK7tp+b0BJI6aPxg5TnC1ouhmpQSV/lc4s76h8F8+SFdOqiBHYbj
l/FYLmSufV1qlvyujcy73jTMOulxwBkuRver57k7ZWraqKtXNDxrM+XJJhISAYSYBGEAAAEZGAEg
AjANJgEYBAAAAEDv5g+ZN4SOtm6Ve9VS5t7U0bOqw8zPSc6zmPbJNXIGFGJv1HVcXj9OPjr9ZznY
eeTabO5fKaLXLAyXEdpTLaymKvW2VawNHETYYvL9OeUfUKJEaMxewXGxR85iFF2+/edrRK5TD7no
HmmjN0AKCzlfStXym29a1JyFXmHzCA9FUnMLrwotfTMXiuWpTtrSdy7496FYYFZZqrUBn0t2h8oC
QeV/YLF51lJVm2gpOMZXBvv9dd5TT7M13WU8zehz8dNbdtl3q9syCoP5xndLt1pVl8eQvAlpIgky
AAIwaQSVpBEsECBgyBEZGCABBSDAAIwWgpUaTb19jtOv4JrWlRGd63Sj0FMJ5z1l35/rzdBGRGSg
c/6uyLM9SvOTaFfsk47bl9J3+rZTszqh6VB2DG5m1wFqja5okxXpeEsSqlY6C/smeaRU2ehRkpjM
rqFVuMVlDzXfPFf3Nrhdy3vzPROCQSjI7N6dq6L4mrWCWzS5P+OF7hTXtqh8gzAtR9AULQWEhz89
a53x7fo7K9xEL5YhpD1HZxUrcxiCmvPW6Sq05bfaZP2unXCt2Cuz8Guyl52seq+R570bW9BqVuoF
3beWbRv9G0WqWfxXBclguSlJIjBGQACUqNIABGRkAZEDBAAlJBmkBRJMlHfjSsg2gmW26155v+81
HOtoztvoDXp5z06w+dq+2QQSRhRKnfV2T57vUTj+uX/z3K79hdV9L53jnopeVbZVrdV3uZaVyzKT
t95ZPqVeetWnsyRo+H97po50S7ZFEbREWWPhcx3rA6Tuzvz1fN28zUPiYV1CVu/U8VKNXliSefWz
lO+b9zr09DZPF1I9R9BoKALFKfv835m9NtK3p2cRWJtZH1dGVuH2Wq9qvdsY1mOx/wBAUq7UBvf8
51uoz+f65lWXX/YPLmg6n523zOsq9YUS+4ruNY8vemqvm/pXP7j4tjuZgkkAkwCIKIglaUrCQADJ
BmDSAYJKiMlJMiWQBAxfgOpc2kRH6HvWXaW7kqnfqpJFQNAw3Wa9i8S35giUaTAlvWlOxyQ2CoTl
7wCU3fFql6PoGQeguuTbC0nXMIahHUKi+j27tjJVefRlOjWzPZSV6d2b2tPZyi6LzzzvpOYNLBhU
d6As3myo8nlhdLWk1ehoeCvK6lbCp1ylalhfoyuQWicMWg3E7sPWBkefmZt6d7ea9W1DNr68oeXS
HTSbmyx/Vql0z/d6baIbz5s+kP8AFcdWvdrjimrUW7+eNS1LGtWf0iuYk41bYMmskHa8p0GlZptm
h+c6GkiAIiMiSZpIgFEkKIlEAhRhIBGCBmSVKQDSAoEQBnfiJaOXKIjnGmupSsWhzNKiWEBN1iyU
WIa8kIMyUQLr2095Q4a0SDuTqDq0VllbWNZtfWr2GXi+77lCyXKsNLjzKWiYKwx8XZe8U/cQXeYi
2k60hJHlCTb2LZtIvraCrsenQNsegzaZJU+DCWRFSrx/6OrfneJe8OT1N81x5BYxGtS7x3JwbNXV
u6KS3mb45XQ2zckc1nzWTvcNCa+Y4JRun/SOlodoY6SyoJuOsvI8I+QZQjfmFcCSRJIBJAAEAaCN
REZBJkSiJQI0AzSYIjNJgjAIyMEBoKOqSb8ouLc6B2lISf6TiWhQMrVLDVYNs35mkEojButXfZ/B
ST3jovGjXKZokra6izv8U7mouOsfHP6whL/Um7uwRlVuUdn1otFS0bnAOJ2O7yZ57mrd3qstkL1z
Tu21z2GVLku37Pk1a6I4dSQS0WrZMe7R8BGpQ6cDosuUp6HxiJ27Hqr3Jlw59H7hPJHR/u+YUXor
mbbq3cONT2qs4JXW7q0egqOi/eb6cUxc93LB6HysPo92jNdYgvNtPRzCTTzBGRERElZBJgEpKiSR
mlSSMjNCiBpUaQQANJKIyBgENASoKS2h4u3ej6Dc+s/Wb9BnYa86wfT4XGoVokkpMBaFPvXFSxbl
sjSI2isZztcXlWpyOZzd/rFpq1nqEXes5jBX9A1Suy9atDfkuh3N/nOn5dGa9XLXTaXrNKhOjTYs
xza4X3M8503b/Nmecuuobfg1xskJWr5BQ1tdZ5Lazgl8sdVxmHcbTyczzt9QoTfsE0q+ZrVtK4Y5
nInvQEvV3Ui1a6VSKHe3tWfZvp2KbRT9WhbHEV1LO9zlQtWeZ5QJX0RMs2b+Br1kuVEvqKNbMgwP
kgJBIIEaSSpAUEgjSDBkg1AgRGCNBmEmpIBKBAEZkQM0g78sgaeEPFal6C88Wb0LE49uNSq+uEz8
32vSvOVXZAkpBKAN/wCt85ybZp3GdI1TCkegMmz30VW8Y2+ax7Ym0jkFu48rlU+F8kop2xlOldlq
LEabkd/U4nmTzEZ2951qb2s2eFjcN0q7eeJ70F5roPEtY9DYzsdIu1cs7fNtPj65R9rxvZckY5PD
PPVj5wxm4KvZJ6awR5t+DaxYOGM4wrWt54wQ6zuSazi0P6FqUm8y3Vc51KEdxkrRLy5xnWJOLlKL
d/PuwVeUsXGM43rE9koGgprU1jmBc0kpKUkRoAIjCTBJWlJkokmAkwakkkzAJSAYI0rIyIyNJkZK
voHRBt4iK0j0RhNj3RnkWyZ0i/0W+eeLhd/PdVbJSRAjUFO/W9Hx/WrFl01sPn9r6SxbPvTtQxTb
bHj+3UjR2cZQL13yg+ezdJLPdETX5vMT1DFE2PVTznQMj1PJ5+9uoCXptvxLXc/xzUNs8z0Rt003
0hkmq0TQEsneX6qwqlB3nINazDnkER19PWsVa1YVlVs9O4lWPSVTl2EFnOf9NM3TPec+Vqw7aomo
6f5xkN2q9k8t6xnev2N5menjCaD6mjbLSbvBU7z1tWtHnN9f0e/Ui8Uyfc+XqHzNCCSkwRJBEAaT
JJgglRgkmaSMKIiAMySZkQMJWkzQYIlBV9HPoSeMVETfoGPsEdYG1xiS45jpmN6ZTMwieSQSQYMl
d/UB4rW9idFoGInt+WUvfa5jW3v8d06X4uXXaqy6szpm9tEy8dQNEh871aw0OYmao6nYjKtSzN3p
3Kv2GRonPlli9yc4ZAJLT9Uym32OqsrPx4a/TMPn9Aym6TlVbWFaktq7dc3o9x03OKfrKK3oDCv3
R41bdKC6bzmb3KYgbdmbbbr1FeV2BzOlVdahwq+rwgsdYYU9v30RpW7RXpxFhrVQ0io1AubdHNJE
SiQAQIzSSTNKyIiMiBkZEoECMgRgAiABgAwkA0nfjM0cucbDKsdhVw7OpTux4xD+LewbFtyQaUg+
iSUdmloSL6P1S/OMlFRjuQjkSvBMs3bPii48uRS79pKFGPzhFy7KTeNGku3YyK4mScRzvtwrrFkL
PI1iG5JUjoSuiz7bFrmVZNHoNI66VKlT6OjrarrU5eXhaKzQ6s6rJq/Oh0u41SJvkdnsYa1nbdrs
3nSlkklG+0XrnkWg3N0k+tg55vT0vrzZ8zgkdJrR6pU9KVk8RxQCMyTzMEADSQIEYUSTMJIyJREZ
KIgZEsiIAwRGaDBhN+WFjjxjIbtscs6YyT2y8mbmk2fM7vVaBHt+YQpIMyUv0VJ47V7JZq9snPK9
HnstnNCoEFrkDIPOcPNrzmh82szu8a7k+dTvEdl9wuGb6xB1mzSSG0hxZTLXm7Zu81TmMXumgec6
E2IgFH2k55URvFp85G/ikykT1c9KxGl127Zsb2CAlPMlTPQfQsVTtXaVbMvQWJ6C46+c6cU7OOoS
Z9E+al9uVYmHV815GcZpEy0z6AhoSK0bFcXvGj6jHweOV+f2R/g951bnlHnvikEYCUKIJCVpJaUG
FJBGAEGCAMAGCIAyBEYNKkgyIzK/A1AcoiFtXp/K5bVXOZ6fWW1+bH56sl0wKqNeKVIAMKHb1rWs
Tl9pq8XttAoW81TM9h65faL5n1/rNwy6K1SkTXOpXq4wUjXrUddk6n3tuXannkTq0NYRFPTYF0wm
8XfFNWhsWs/onzjnjQIWYU+9D3eGxO+aNjm096kxvFGeW7lgGaI6axveP7DjezeYaQ69RyzusXDh
mWW+p8Q27zrUolkrZNrRQ6luHnfc3R4VsaeEnx7KbQ1oexXljR9o8zOfQ0fOVuxxhHIphXRHA+SU
oBpASEgyBGQIyBEDSAoiJRAgZAAEZKIlJIjIyMlEAL8ZKSvhGQly9T4Fw9LDCN1gc82VjK+eC23z
xTmHJJc1qSswv1pV8U3CTxa7bZg8B6Uy7KfSUbguzXPC9uibJQLLRJa3ZO+0Se496zZnEE7qVK2n
DZGwaE4qtm6QT2r0DTXucazg9D2bQvN856L83542CiUrpL+qqFn8FqWk0XSquxt/SEgbTnOW1gj1
jesi17Idg8vUyQ9T9XkJasEzG0+oMS2vBmdUri9D9GVcsT9L+Zty4WzDdZbNX6IkX3ztLaNIebvU
Hn2H9F4252On2XO9mxjTsr1J9WVVny0XMyJCkmlIJRAyQogAAgwC6IUkgAYQZgGEGoJIAyMjSZLv
R9EqTxjYayenc77az0znR6b2t2R6thNhuuCVZoSCBAGOh+q2mIyGvVWP2zDKz6YzDKPSEbhesX3E
Norl2XGQEq9qELmnoKX71y1QLmRyOb07MHcpaecHY2TOTzqP0rN3Nv8AOV22DEaPt+o+Z6Nw6ybt
RLd+g3PHF9HveWajERtkJq3kfMsNJdOerbBjOscWHnjn39CUO5urLgOU6p6BxSZ0Jr5zadrnu/HJ
IjeME0KPvHmRu2svoBOT6vXW/nr05LedPSflPYqxjVh9J2LD9cp9uhbYjCdv5+U6sRJBIMwQBJBk
EktISFJAMjBEYAI0koiURLJIURggkGQF+CwXLmxg1ancOXE5uwHG8c8vWc3mmUyOQEJIgozNWxWP
MaxZrbwuGfMNLqtQ09lnl8lc/sNmj+U0VZmF0uv6MnhOxFStjOq3aTrruUrxTsbFWZpWLKwqsg+q
9h41brfkUmP5XDbpLoSuFFrEXVbO+q1h71iTdK6FWdW07tVchTXpORjt1tfPNsdd9O8I1fykOqws
tfvK+U7huUdXDJ4o4PmHEoRA2zB3wbmxctSN2bbtwcc3DXi5Z8EkEpCAtIIICiBBSSIBRJIyMyIl
AGkEZGRkASTMAjIyMjvq0qTy4tYET9iV2Q+fqQiHkIZ5HQrfggBIAJS+lqsNbhOjznaJKrP7HWE2
uFhbjz4z3CInFVWtcyVd37ezNaxYjpjq2Vu5OyhptnymlVKo6JApuVJrvWuFq1jySrcXFh6pkb1S
q2yMiIm5lPajnmmucYbaFbcbjS58kLeuubdPQFyJHbrpGr0TK2p3LeovCaccjpmm55k7E13jZse0
Gx4vnDNAQCBJMjSCMIUhJEQQREaTAIiBkQSAZkZEaQZpAURESgkGEgKIjASoiMjAvphR8+cfAOfQ
EzHWVu5srblK1Sdx+288cgG3BRoMlGhXX0xNYXWdDuFC3LhkmoTOWzeg0Ku7JXJaOlYJlY6XResT
P7rEuGE5Eyrah2S2YvcmmhU+Iv8AHU+7V/jfqTaGnGjWXLKRp22ec864PtKn69dNMxyoXhvByzml
UprKb9oWM2y3ZhnGsTuDai5odAZdtTu8PEzbyDJxT69rVR3+tWrOajOW+baQvnO8bFZqfcM3qVgh
dinM7uNXkPKkPyCTNBBJAllzSYSEKIkpBEYAIABAJRBJmCNBglDmakg0kolEQMEAQI1AkgyF+IdA
SI2AmvW+RQvomSxPVWVH1h2WCwO64HQ2nFISZKIGPVDfBrpreXq3rKaR6Gp2Sbg6xK/6Ljenpmck
Veqff4iEukzGL4yZwriAqesee61t0ri+n6HjDDZqxeVMXlasnnq6XTBevpPznnPC5+kyqfPRsX0V
UnF2JhV/OkZJ73oeD3PRF45ap/I9yjsxxdvO+raexPQuLqDlMkndLqdprdmoV6joOwtI3H96z3U6
xac40evwN9VDu4WQ8hxRISZoSaQEg+ZkkyJJguYBkQMECBEAaFAkmFJAASZAlklQIgCUkEpCjMIM
A034GDBRkHJ+ucnqnpKVw/Vomia7TdAwyv7xglBZcgSQCM1j1CeDapa8rX6BxCl+maBj+/OMC0jV
MI2+o3iFfZbY7piDmb0GSd0S7vK/3rdG3DBH2zef+MxuOYX+oZXatqj5Gt2HANX54Fa/RXnPOG07
vdxplR3HKtIqVsgbhCxfmyP6avuGWT1ge5ZL3TCdcs+ZYi1n/VOYs3umN3sW+yalbjke5wNmynYq
/WrZzhZ/Gad6grFmy/X6r5+l/SFFt0C28rNgggSAQSklERpSZJSYCSCiSRpMiJaEmaTBAGEksiBE
ogCBkZEsJJRoBgEZEDvazATzj4bp6Hk4DQGBWWNXJY7qWTWCXxKutUpCQZGZn6Ns+M07YJmrbJjl
Q9F0bH9+XhOm6HiGkSj3i55x0g1qGUb1KsX/AHzy6dMg0e85nX7ziOr28YzrGZZzZPRFNb3XLDsm
JM99s/nip8rNvUzRcx3VlE3RrR9ohseZO+cTsEM6i5PNNIlcj1t3mHF90tM9X4jXKll2kRdRyfme
i6pmdghbPRdALPnebL0LTMpu9Xt2WS+s5vL2DC4rny5JCCSAggkyNKQtCQCIjI+aiIwRGCIyJSCA
M0qIjSZGAkwS0mkEogQIwaQYF9Jak8+LSD52C8tXDGYlHbFvXZSGlIWDb8EGSUmDUsrPYIGF6WDn
MxjOZ5Q8x2hnzxiczxaP+kOlcVxmXnCU4Q7xcU9fNz7teUoiPfJimPZcimISnkU09g4/kFuEd7A2
iEnsGxYNCai5jMjrqXFncRUx0g4hrYdcno6mMG+maJh+dvJSAiAuUsUXAJ5yFocxUnWoRJd3ltjq
zwTK3Dqwh56q1/ghBJ6cgkkmkEaVJBGRBAUkiBpUkEDJREaFJNIAUkAA0AwFGkiIKBEYSDAA0BPP
tzLk0g+d00CLlYqyyXfiVZlarKs6PGtkEoiBEpStQv2c0h3aYjSJfNZ280WN0yvUjVebSxtK9aBS
c84JcbBIx1ua0q6Ky2R0rNtTTXVWVtD2fhn+bcZfcahkk7Zc+YbdfcFz5uuQkOEx6Kz3I3KubzhH
dujWObia9Oc6lo/LOsPYuNd1rLdBsbbENLmsS3HjRMQdnvd1rWHQitR0zrDWnF8nZObro+iRuEVp
rqutsXcVP07zjB8UEYQRpIkmRECANJoNICVpMiBpMiBLSYSAYSk1BCkkpJkDACTJQIBJqSDO9A+h
8kM4FXpVxT9hRC2BMdaeLjH2GjYlRmfMj5kSjMu3om2+f4rW5/MPQUDl2u9c2n7zncXsdLs1etNU
pmlVyKe1qw6lFdYKzCORDKueQ6znlb1yHsfaH7RzRxUb/wB8ngdZq2Syvpbz9mbaw+gZKo5L6Vpc
XpPHN7w6znQ5Co4RDl39RtXDbvz82Nbr6Yin1esPXzrpNirlq83yT7dc81ujXmvxUzjr7WYizpx/
K9P151T7ZGs+mb5xvlilc80PyhS+SSSkySZJBoSZoAJSACCSUkJUQUkGkAEAAk1c1pNINJgjM0Eo
yAIlAiMjI74noSiTHwK/YGf5x6Nt2G6DPZBq7uQx7M/SOJ5kw4JCQYIKX6Hs3n++6Xi7r0Tkubek
IDDd0nvPF917B9NkZLOpUqvrGZp0ST58mck4juEdle84pPSVxdxUqGyJBTSqTrpXnywa/wCeOXpr
z7mPHUPQmGsaj6aptyk4yBufXJ9QrEBg0epz6eaPmTjh5w46F6LjX9WlMDpPoKxV6yec5nTdLot1
pl2yHZKn5rtmwnY4Z9l+p4PvNbtGY6fw8qbPesV9C55oPkmooHIEQASSSIECIySojBEkERmSVpJS
DACTCApKiBggEGFAESiBAES0gKIhfCUoJSwgj9WxOeb9LZ3YW9e0TN9BzWlbriOcNE8lclgGFK9A
XPB++vVmm+i8azj0xWcS2q0efLbt2B7JAW9ac6sVny5vStduIq1u5MndDh9qyZDnUOdUtZQzt7zp
EdeXvbFNYy/JdU3TzpmnLR/QtILIfS1Nmkte809zvRsqxBDoOPTTKMs/fPsTXd9+w3cohXmGN9Lz
WR7C1q2G6Ln3oGyRdauR0u1SFIva4o/PlX3XR46iaGeK37jhHpCw0Tzmx4jmSQggZEgAGRJIEZKI
II0KNJGlYIBJkRkApIAIAECWgyBkZEpKgQIwZX0jMuaW8Dx0TXK1bandX7pDXNbnSZlGVQ3AEkgE
KB9NX0/Lc9tGl1nTc+o+2wWVa+8x653nJp+58IyyqrLx/Sc+1iRhrI0zi7nnmhWGq9ZmusLTH1e6
opludUeem6kyOkI059mkJzdabMVOD0Sux9tY1a3M0TNVh9qnuebt4+uXdrw117wzOj2JXGidLydR
s0nTGC0v7VVZivTDayop9kd1fvE81Wuuybfq0VwYTEzVW5N2iOaSIgREkEtPNSSUk0mkjSQBpMGa
TBEQMGkgaQojIBJgERggFBJGZGlSVXg1oXz48oNtKWVblu/cukcGaeA4RTbhyMEQJRK6yM+1iOLo
5WXiOM7HsJ9ELKvW8mqLeuIiD4pXOTTKeKvyLyriwxdgfNqdCmt5d4SNuzHvLRlQ5xHK82bPqzyK
R0lWf3ZlT0FyWqa1Gk1W56hT8xjj4oKR1HRM+ezEFlUYTnQ+fPTizuP1LP4rT4rIYzo/2B3ktbXI
a3ZqzkUU6mNf447ElJbFYKxTtPpeRRvMkBKSBkkglZJJRBJAgAk0maVpSDNJkRmQMiSZmkwEEsiS
oGRgiUQAIKvRLAHJpDNtK16mX6oXXpKtVRR1PlL5NXGrcySSkLT0PZNYyHOJzSqJr09lM9oNAr+x
1TONpapkUwrpxA5R0j3O9PI2UXXrPwz19pGQ61WaXQpBrG7JpeJzmmVmwVyfzeZyunartXn/AC7n
0tPpOGwL0RneeW9NXsfRl6GpWMD0xl2d3Vvn8Dy7a5uuN7HQr15npS9W3FpQdRi4rG/R2Ha1TpTD
ZFzctI4VzPoO8a9nmh+Yq5sl0e9qjRoa865mukNK9ZfNWbcwhACDSCI0mkgYIiNIAAQDMjBGSTIj
IjUgGSiQZgiUARkAAZBBqSZKvYJRhLGE5eplY/6DsdGOz0m5zpZlknoTJctikEgkqIKX023SvPB7
ZEUD0dSss20sgv8AeMd67Xk9v6y9DqOtU248q5OXBkzKTXHNE0LXce1OAgozUGNO05WYWuRxzT+1
hwS1WbEW3p3Bcs5Tno+z1fDvRVD6aJHZpqb7HNa7U3FPSec2+zjBcq5npPojGNnxnZ/MdIeeoZN3
W7Ywxeqeo8Q27ztRrR6FXGyjfn1fZtM2SW82aFckOxHSrvJLPYpkVay+dcm5JSQSgwkGgyHNYSSy
IEkwCCkkZGRBJgwkwkEoA0mSQZkDSYMIUaSM0gXxRGoksoTj6s44pvehZO9u2TaCU/QsV9I5bkEb
zSQUQI1r2zS/PFx0/J4H0tmeTejGeCa/fPOth3nA9V5SsbKUOP17CCuttnGtenZaMY8Mg9A4nHy2
zcldsnkNJzCbmPO3C/7Z55ut1899PTmCZXy0X0bCsvPnpap0bZCibM5y3SYyU85eis8v0VXstp6V
aR6CxvZsj1rzBU3PqFpLxlr85Z/bPUWGbXjshSNY4crVxhHF6870jQ9vok/5q32UeU2z2bzPXtO2
DnTbz5hzzmRcwSFAkGgGSSWkEDIAEkjAABEaVAEQJIUkzAMERBSSUCBkRmkjILK8mYNIbQLXetAz
LZ43u2loubocxE0XXcWobTmSAAk1KPYtfxajarZ863fOsj9Es8H129+fJ/dMIvctL8X0GuQhGWKa
5f4fpL0mxv8AH7Bq9B6yEjHvO2KMPROWXHt58vOm06p6dh9Y3HS/ONE52j0V3isZ9EU+G0JdDvnC
i3qVoGYei8663hnhQdNrnqmLafK1DKXitZzq4SFlw7MdQ27Fz2Gued+PKe30sq06rSjO95FZMZir
RvUdQb/W3R3bDz23L8U58+aSBERkQQDSZGkjNKVEZESiCVERKQYMgaSACkkDJQ5rIJURqQQUAAQI
r2C6ny5N4hnJ6pxlKxbHMnzja/0aIKpM+XEkpCyMKOy3evVc7gzscPCW/jV7C7rEhN187LziZhcO
t3X4uyvI6a4V+S6wUu9bc5NiykEx/aTjXCYl68h+SY1Ey/gmHLo8HPi+bpdFyeuGiVNFdmye6dS0
vrWMvh2KZJOyz55lmXE1EtJBREQU5lTj2SzlXrWE5G6lFRDMKm3TVs9jYdvxJISRc1EAk0pIGQBp
BkQMgaAZhJgkqVzCkEZgERpCwkGQAASZKNJKIJvagoI5NolhN6Wym63aesgTRk25R0hTIzhxJSQS
Vkpdn06s0JM81s1zpbW/1uuaI1od6k4O1lWLE5rOfskONAttbvHCmWSRzfjqOf3+Q7VuxNGVh5RD
vrCOpmKzZ1R47Zr7imetyMiMlOX3ZOpP8kbdiC0MmyJDaWMJueJ0Lv6Nx6hu+DPiTh905pcI5kji
pxa97XidKaz/AKHU384Q0xd9pa4bTms76ORwqmkU/wA71zmXI0ISoHzBAgDSREoECCTIgYBhKiSF
ERKSpKiIAJMBIUQMgAQMiMAIvSwaiS2g2eybXlGsMJiDtcNIvo+tZrquU51H8kkkua1Erpq26YNS
bzpmTbi6y+y3fP4fYqXn+4wD7g4j6hbCoUlCHt6Y3hJdFR8W00DEjabjnda1qGzTRpDMbzPSNLvm
SW6oZPMel8MylmRGFH00fX29T1jjh2jS1fXKNMTqitY3eGw70LEUikb9hNqvUVhFWVe91XRLU7ip
GnS+Ia+5fT3FxFwE1bqZePMK9+ew7tMbFc8t2GRsefaJ5tzDikuZBASakEtJkSkGkK5mQQoAyBGE
LSaSIwtBkYIwRAEZAEoiMwhQSDMJvRKNYDevs/S1z877RqVBgNVzSUvHSmeffQlSxSIRzSSTJQNW
ubP51d7jmdZ9JU3Ft+e+fdR0jAX+9YpZbmqlRN0zjY6HwuU0Il6tw2iu2J+gcRpO5JxTSNQzuA1z
FrVc8NttqvmAK23BYL1FhmVNEBSzHTbNTicp16Oouz51oMSqb8/5pysHpunZb6UjF+fvSOJ2m81P
CIDrvtwxJzusLaFUyUxbejh33CORd/Nh3bVMG2LNLu+61ectPmvWzxT01Sbv5pzLmgcyNINBGCB8
yUEkDIyIjSFEQABEQUARkAkzJSUgLSaDNJqSokgAyBleyI+hDjAsvQmkYDs2gVep6DnFtbgYTvdN
xOO4pPkoEalHq+24A32SvZt6Mo2ObrK4Deti88q9HYXoofSrnLX+kY22h75pkdBzMkybxeY+gchr
W/8AndzK61RLRBUTfc15Z1fNLwnX6riVy9GYFlrcd+yi7L03UZ7DNEn4C21Kyw009850g3Xpl5n+
qUqf8/elsklLdJ+a6r12nR6hE6MXdUX28yXJjN7AvOtA6ZpVdVcnnWN7bpvfMNNFSvtBmmUvz8nw
ZElBERmlIBJCkA0maAZECSZhJqSaSMBXIzJRJUQNAUSkhJkogCMKSACNN8IBSUN4hldN9qN9od75
WJm0q8fI06+ZFUW3NBJWgz6EegbrnGUzOyUnV6hkW6niOl3nE32zZQWjdqzbThUStTyXU7jVbQMw
tsplN9udUod7yq333lk13r7DVukBF2TPuU3mTbW7Dj9fQ91qbMd0Nzjsvlr7QbjK1DY5rFutvOsV
W01ezVB5C6FSnFthnV56Q0PxqfpKt4e+foz9j0eXpMHMQsqJTPZ2sBd4jW0ixmpHpEUe80SEQnmE
AIUQNBElRAlEg0qMgSTIlEDBBJoJYIKSQMgCBkDVzCkgwEmACMJO7mOhJ484uNc3Bw6bSHR2po2b
G1OKacOQSRpJSwt9OCH49+jqUY8pRvHyfeM7yDN/2jnL2OiWxiSmWUr1izkIVnONJGQ6RT1TSWNh
VbB2eu2lUZM+VpsdVrfGR0F6YMqvVuYQRdekluUZj9kfHCMtDpFVbrLr1c3OtPpbnGV5Ni1ik5/P
aRUaS3Xf7q2iLDyq+Z8HM/ptWoDbnd9F6QELbc0qTTkhISgjSgyCDIiUgAERpMAiMJJQCQDCSBgE
Rgi6czIyBEsgYCSUCBkRGBeVJ6ESeMPHWXdYa21C4cbLwZpgHVFu+YVNnwSSEqHRB9rtvufZL00W
AuugZ5Fa7UKBs7DJtXkoSztoOWXFY5x5o2y21G4t69YnGeMdfyHQONjg+MkaUtMU3iNs1dpVfvOZ
VHUtow3KmnWw2Bubs41w6rsI362ybj2c/wAY904rV+3DBcubdLZYYyd3HGs+t6YZ67r0NbGO/m7x
qsvtjkc3mb/ldQoUnq2gHKY9U13SVl7QqEX5ggUFzCEAwgBKTSlQSCBgJCVElQCTBAEaTCVEZJUC
BkQSowglGZJIzSXRJAlGV3NRdErbQsdsu9efdWvDTPNQp7m6cq/5+2WKwqI5ISRAuiOitF9CefK5
r1nxvfWuWXi4ZN32LKqxv+eyEucblupx3WTgD0jlCd+8g1gZTN9exjP7HvWHyWt0nKdxjel2rk7W
61nWkWHGIT1Pi+Qt530vKQU49TXZznm2Js7T6WOuT0q2r88KZdXWDZVzn/T3WDh9GyqTtfaDszWs
1DYqBf6fcKvKOKvaGELbI2kZTt0jYa3Zq1OdfPsd6Ig7dUbX5HrvFKkL4khQSkkmQSEkpSSAQo0k
YCDMIMEZkRggQIwCBpUgyMGEmQBgERpMJvBrJYVwg2G47d5qve6VbOtnzfhoKGnnTYuvnyH58ySa
QOiV6D6H8+r2/MaL6Sg8K2u1edbxtHnnj6OxmdubJHOLpG6YqxvlpnIXidgawElhPoXIKV6HzPM7
Rs1dbWrMdpi4jNX+y4S62LzvF+psVyNu93y61i7q61Sxxdb8/NZLf7TUr7To7jdCloCdwzLOb3dr
3SM49G4npden2dvq/TNdnynWqFf8X3CnYi41d1ktt0WvdcF9PUu+47skR5g9Bc8r9F5/efH8Okkq
SSUkXMgAQQQURGCBJWQCTSDCFhJAwaSMyAUgjI0mEKCgRAjSakhJgxd1EoyU2iI7T/QeRaJMuKbo
NInOVKvGE7LTsbjUpQaSCyPpe/RORZvpd1y/aYTDNmuHnq17f59Zek8ge21y4k6c/l6r1xO8bTVX
chAP5XOIva6HnO3efrpb7FlNwg6HvBxTV5MZDqGKZ/sezeeM64T/AKAsUe+ptyq2gN8Vpy5zYper
yD+OpNpc857lldF7SOzzFbwb0V1pWic8q2XjjeRScbr+tZdNNbJVNELMtI7UdWAo0va8+4SEvlt7
rOT7noOBZmXFANQLilHNSQlREkAgFEkyI0ktBkYSARggZoURAGkwQIyUREojSDSRkoiBndwFKHDl
Fxj3XHUrUrM6mlQ8TCylesNAh+XNKQRBZhU3pkVQ+N5Y2uOp1370ixzVN72qvx1u6Qk70h0yMBW7
NMw02VVkJCsWB+yhZSFcWThU5Bkwta0c5WHZFB8bI/rsehUtIx/ePkNW1vAeOwuobF2Mehw0SpfL
pwuG1Oo3FIDjx6rTIJvfoDBctQFdXHDk3cdXxsuHLq/ekgkMWSej8mPHiTl2zZkfaQEQzTzSaTIi
MiMIMJB81GlSSBgAKQrmZkCBESgRmkGSkmhRpBAyJQSYUV2AUsuXCMjXV/kXEXMdJRHBEJI1ydqc
U3bnyCjSoDpKaQ1o7ST6PbxX4O9MqjcndJsFkrtm7VyVkoCjMCXab7VrqdSd2KhQ+pU21TZ16xN6
BS+c5sbgJ7jMGlSj9W0HJ8/bB73NBdLNI1a069jdPdb5kdR7BPRLZoOvbqouiE9UdtlqtRfQ7ZPV
M7s+IwCutj3fpiFT4WH0hzNC+uCZy/tO2SWHUVsLf6ByDLVnaPQB+eaDw5hIIEgwYQoERkRpIAGa
TCVJMjIlkRBC0mARBKlFzUYBhIBAyMFdlBZAkRMTbvTlFtKp+s3uBXNV1ziGp1PH41uXFQSFLIXT
07kWWy+zUW6XegwOy0qgbnXcp2xDCXiu9cczuPyMfHbvMVWV4uXkSygtLx/rGbJVKhptGj30U46a
pm1Z3TJLhTcskvS+NZE2ldteMKlfYKsaVxqm3U2iwe94PaZnnX701yGl8rdr8jVJGxQMJeYyF1ms
YdrnXN9Af12yXPJca1jtPT/FUDW5Ogye7YDD+lfO1U3m2JhZGCqdkpu5YvXtlqsjON4ny62QCQZA
glaSIKSCMgEmEqMiAIEYBAjNIIAKSCWEBKjIAgCMyIyuxgKM0w8RqHprzjP75GZBttSq2tiN836H
bvOMG2SSDQsLAuvpfBa3vMJlPopOEanfMBntvw+v+is7jtPawmeatmmpQUdPWZdbnOTlNflsI3zL
Mr166Yjqy69rIpeMb1TMh3jr5/tm74dT/VGPZC2uXp8yqFwZwXSlQ+3x7TGPQeD6TLyylc8PyhFq
9PQnSdTH16xVrL98zCs7w4yXTIjhRdg82yO/HEO+EX1t3m9h6LxOielKbje/9Yi8MEQuieeM99XZ
PZtCTU5RNe8s8SSQCCMERjmowQIBJhJGtKOqDJIMiUhYQSjNJGRGCIAKSADPmoAlXU0l3IkRMTo3
p3BZjc2OSbDm/W70m7+ctFsfnaE4BHNYSo1Hb/T2FVrao7KdyVgel6f51lvQeAV705lEjc4K2dcy
abBj8Rzs2u1/i0tzOBkcQ9BZvn/ozC7XeMzulizqL7ab5olvSHnGsb91wKS9O4rkfG3+oIiaKIkI
VnUeGyUuXwr0jiF2e2fpUIfO6UVg9QY/T/SGXu+VvkvPe9sOEw6zrRcxxG9+h6bhd+j5jTlZ9e5P
HOep+ULN6h8nbHLeaNP2/hSLVM5fRPRlGtDKz5XoJ4djKCBGgjIJJRINSQEgwkyMlJMgRAjSoAkg
KABHzWAlSQSkgA0gKSZ3dJhQ584+Hm/QqH7Sab3OK5cMx0fHdXzPPo9A5kYSYPrYfS1Oxh1tNV0B
GEaxdcHsOxYrEegc3rWt9oC1tmkfLxOI3rVKRbF5rO2jH7PplcyjU8b06396ZOustbWjHpvVMel9
DyCJ1+64vUkzWwUS+xU1yrN3b0+309zXtRzaS4WOGt7Ol3By57Z3StPnaiLXEZbdLPQdCjW83U8/
carG5utDrSG9VsNcma1Zc0lNDzC201u40R7RLpS7eytLWrWuNpVva5olBJABpI0kSkGCBAEEdOZk
oEZGCIgZkRLQZAEAYSojIiUkjMJCkKXc1pMxz4M4bpZ53szdd5BTXhHdWnWHZcUo5gjAA6OZ/tFs
3HVxINubvm3d92HV3xddmnRy1iuSSdyie7lih/Gs36ES4iXq4JqDQjsJeZrvFvzmLBDQXBPRSzIG
gKc2+sMDQlanV1JM2UdVLXVWNkkaZY5qhxwkLbKUmIJLy6xSrjwpVlVQ4rglKCPn0BBIIEaEmSkj
mAkIBcwsgEpIyBGQBAERhK0hKiJSVBIMEAgzIGkwZEZoM0GRg0KCFFdzMKJPNjCO9msfDk7f2Hmy
cUmzZlfKNR2LdJJM0gy6zXoeFxyOvIc65UKLtENl+svMjvVyqNx4wMq4jscYcUadqFCv7euyM3QK
ttOYylpd0m95rl63jDi/bNd0t+K3XOKvp2y47kbUWB12YSKGbztFWzbPOvCUj4aS76VqvDH6kxe6
zpfmxfoSB89bTdPMUJatB07nQs5hJG47hjV+5TldsXPKMZZoSEoWlACkJMBICVJI0kSk8wSVpJIU
EAGkECWhSFERggDBIUADQoJMjCFECBhIUAkjBAgCUV3NaVkERsHavWeSOdb75fp1baXzjy873O0+
eYFuSAgzCOirD6rxPP71reP6RasxGv5fW93z7Ot8g4+0wcnkV0na/YIOI1jvVZdjOlTbRmOr5fn9
p2Xo1z6F01NAkrrQIjY+fnfSpvG696nyrGm0t6KnG9E0qKp+hFmxahhG3JrWTbtDWFjLNSVnPHZ/
P+2SkTSdG5+YpTf2ruPfoZxmRehcuvkm85xvOE8z8OJqQgyNA5mRnzBlyWpIQaSMkpCTCSUkAyCU
maDNJqIgEmCNIBg0hRAkmkKQagSQYIGQAIwaV3QGYBIj4W3+ucDj/RisP22BoWvRkt5xntV821tt
yIAjBH2n/VGLVD0BTss3mc876FrvnR16Iw6n+k6HAa/W5KtTWR7zlsHeLdM159FWVFVsXnrf88y6
5bK/huE+xweT2J5BSkZJ+bZT0FgVR9UZRjTfv6d72eP7dch2Ctss23zGdn85CR3CvyTGVot7eea5
D0b58tN3kO1esOEbdkk1oUP2g9I8+0v07neg0a9SUCK95v5cyMggESUkkzSYSQAIglJGSDBGgwoi
QRhK0GhQSZkSkmRhKVEYIjIyJSCNSFGEEZkRAzSFJB9LmDI1ISwhJv1ZTWWr86ToNKkJ/IdZwS9y
+AQnEi5gyBqOb9WZnlN20vM75YvPt22bzwPRuJUn0zQoPUoeek8/krDT15FJeiqdK8CW7q+f7zUo
Z7dI0u/F3X+dnbNnXJxiew5Pl2lb3huUN+vqC0to7u5zHSoCGh9jxnVWUX51ssBoWzx+faCnP7Jo
OZYn6Mko+WVWs/y2zehHeQ6tWXNS2KBibL0xfXuXm6tlz5qBJPmXMJSSgggZIWXNaFJVzCVINIBK
QEmYCQZGkgk1IURGSVkAQABGaSWglAgCMiM0qJBkFHdkqAHImcH00a9suJzc2qOY0u3Ui5UOtMgk
iSogow819OcR107T/XPbPYaG5vFKYXyGr12c1yfeRsXMxFLnbXBTPWqd5mozk40iLCwgLUirzbuq
yhceTlEb0ryLTJ1WN5PPUffAoOT4MXXRl3kYF29g2Cl9pZn24vAtTNvMFHdELUZODZ8mPY+oOQ4R
6+JvVtGfMOHHBjx5EEoCOiVczSSySRkkHzCTMINBkZBK0kELNAAMjIlBJkCM0gAzIiABA0kZAjMA
kqI1XQyBnyQ1hCt1rbOW0nIp5CCk4CRg4hnxA5gwDCnd9d06NcPe1xZVy2OKjMT1RdXCAmJCBXNR
lJYIVMX+vWpxW+NrpsDf4TnfOEdZ2dQ6WigVXiXJY62KAj9E0LPs9aOtK0TNaCEi46FjdhteWxvI
nXVajMWja8loRd9H06hZowVsV8KrWJWf5dyb8A/uexwWOQaLbuHehZI2PRtZo2KxDYElKkBSSIiM
iBAJAJBAwRoIwRKQogkEaTNKyJRJBEogpJJUtIIgRmCNIIEFAiCiF0USwEpZQb30ZMV67tednjhM
V6Zw26oxmBbIB8lI6EFyvq2l4wnXmjXZqXnm61/Jdu55JpVggLNV5mut7jiPVvEbXdKRZ4WTcR/K
kazmNrbzj+My5GvQ/LM5aLirWzr+r03MJX0dluNMinfSeXxtj75/oNqxneHWB0Ln2vWkV1dm5Z/d
tTxCj6tUN6p9vz2p2GMrG2xWc6pFsJap5RKbrPQFirFVK22Cq2enS0BolIv3nXMeREXNaSUSTBEE
gkgyIkGgzSlRJUCNBmOZmRGADIyQSiMEQWkiAWkgCMwRBKyBkQCkXU1pM1IYwU16/wArp3omWw3V
+ed632X57b7f5zqTRHMEpACukp6wyTNNon8V1+6YLYdqwyK9EZbm/oqv0nYozljeu0+3COXd11Wy
snp1S0YJtNGb3Gxc2DbtKwNiHRrxkEYA23bHs69TZrizI7J6dzWXvC8tk7ngW0vfOtaJzvmkRnCd
TE93mJXTQKlaaxZ860mseddZu+CbIeeb1yg8H3emXrhJUm8H51vVxsy+Ue/rFp88ZaSEGkiNSUqQ
SiIIBEEmgkhSQaASkpUfMyBGpICxzBA0hSQRgJCiMAiBKCQZEZEZpUkrwCCgZMIOQ9iZ1SPQsnju
kV2uajnmk4KnafOdO4IIgkGFKkvV+Y5ttHbJdC0XzpO7/wCd470zjOdek6tWthzvSWdPp225pTXc
xtNZe1PQuVQtXnveKhjr30RSKVpF2a12yuc1RodQiM50K3+e+PqPL8SarkPVtAb3/tni9E80bLaM
yyxpM+pGDto+N1CTGNUzccd3+t2LNNgq+Cejsjd6pmNstOTyFto2L+ku0/lOt8fPS9hdWDJZa1xt
l8pV7mlKua+aVERA1K5mgkEaEpAQo0pIyNBmOagCIKQZmEoBgyMglQSoEkKIwhRpIjNAUAkKK7GR
LJJM4NW5X6p3CAm59uDyLU8ivcRkMZxQSVJMlLDz061xGM2ZpL23AbXr2F8PQGUZ/wCiaxmmzuoS
y8VV6abYhLbxntr75/1vWT99ai8002BpOo98wn7RkuiTlYbW6PzDQ8XgdZ0fGaNxFm3ikw8xK59e
5nEJrWM/6Som0tuVQsUZcYmp0Tn1u+h5ld6Vds20bOrDfVVSUkaYWfFJ6jUuzeRjranLNLlKdXdN
zyrqbhuEuC4o5n16cuwLmfJHFCSIIMESTABGkAGlK0KQZktKDBAzLmazSkwpJkCIyMECIzSRg03c
goxxRwg0zFuQrm+fdWqIt3Gu4hjw5JQlRGSjLvYnUSx6OXrnlwdhv16tunY+rpmbzjE8UpcSR9nT
Nu/ZsXpcpBy2em07dSYO0pclGxDblKzDKC4F0Wa1A+aegKW0hw3oJqgEJRyCntxrba0Oqi35mjqc
k/r67hW2tz60hgrj2V3s07S4pK7VZY8pUqVVOTq32CgRXPm/vUcxvSKLYJDN4TnzAJJpASDUlICQ
Zkk0mAFklBgyBGCJQIEEhZoIGaQREsAgRKuSgajQTODGi6xV7VVbg8cciqk3n9ki83jmYJC0BRKN
16AkMXg7NPwm0ROXa6vKr9acrf6ZU7SIlco0x+ERyvmzZ7f+UDyt1Co+10ktC4t5muwd2aOowO+j
aXzJWfVXStmyvHWincyfGRDBTlm5dNVdOUd6Hp2VSyYKP59Lj6M85Rnos8EecmnXu12xGFPPSvm6
S9FM8HqzpoJKW3vlRszhpja4fQa3XrzmGI2TRdVa1fJIR3aPQWVTcjJQ1iaZ954apIJSFpBIWkGO
ZgjIyNXNREpKTBLSAACBkaTQsIUARGCIKIEZHcjMlkYZwa/VXLNt0fUae6QV2cqw6P1zAqazSlJK
IyAf+rqJkNj2vPnOvZnW92zih77V8w13rWb5Tbhj0noNCtsXVdfkKbYq/aOlEu2UahR5RU/JReZ1
6u6TfMUuGqYVBejMQtU/j9T9RZ9ijR56InF1u8N6tYulZtnetv5GKw/eaKWiMsQztPbVdv8AO2l6
JXmdr41mxFVLk186WHd/Od71jC9UzXSM9nrhU7dCTCI7jhG6R3n+9b157jfRDOarVgati86+kqLN
W9w1bxY8mMiJIBBINPRJJWkwglEE9EA0maUglKIEDI0J6EREZpWkAkkogoiCk3MzCiM2kAv19Wsk
3+6YleZnJtXaWPEqj6Bwags+BL5l0SFB36uo2T7w2xnUdU85SnoTAq76UzLLfQ7PMt1qljz66Y1s
1RqVsu01W5qt2w6VdPOe113KbLr8TRrp1zbZ/PsZfthwbX6Ris/6SxXOPU2fYk1nfV9XmELgqnrt
Tt/KnwVxiKrlPpWsWSsZnFQJi2+oMF3eqOZaBiq9qsHXZ2Oxnr6g84zO3eZ/ROcaPn9isVJudblK
pq+DaExx3h6Vxmo+ictj9uplozTcvOuc+nKdaqzabBERJ+TeZBBAjIyIAc1pBktAAIGkyBBSCUZE
tAAIgQMEZGRpBpJQIjMrl0Ih0STWCT6UsOY7ZxinvFtZ8p0XMWmn4LUOPJJpNJmanHqWHxeY1umK
13zx39FYRVPTWYZX6Ja5rttSuTij97BX2WdRvpyozkPItuzPIN3iseuWjZ/NTMDC2vBdl7W/BN88
8170bneQXf0TjmPNpv0+84RD4s61io2F3EwV0q/nd16krLO28sXqCkXve8Q1bmhq/VlenxFU7alk
EJ6Cwef1XzbrNnkcYzBwPRUtjOuVOenGch5x9C+bdCi8anPRdjxDXKNccs3JhSr0eCbG/wDLlVJJ
IBJMEEmtJkgyMESkgjAI0qJKyJIMAJMEaDWk0kCM0rIiMjSq5hJjojjxhm1l1uLla1bJJ43j6dYq
rYq9UGI5pNKOiQfTrqM3nELZ5pzMUGQudNYaBWK5oTOnXSUrM49a16cZ0aTusBMuapzsNUf2RFfs
ENB3IVPq5grFMQcDPVfrLVrnZpasxKH/AKFs8fgMm2hnfBrMKhZlrDnYGrGbFl1jrB4UUS66HzeM
23Y26nbCQfx6TaazfpbzZXeYcGTzoTcuQe82zZHV4GXHiEGlHbkkc+ZkgyJCVGk0qSAaTSYSAY5K
NSSIyAIGSkkARkZkDSDIgCIwSkgJvCULUrkjjCtZ6+NZeEsHR3x4xbiK7Na614cyBpAMH3uk/UIb
rJIt3ao2GXqDyz1fhdIl7KxPCwsKRFL5yGiQVikq/E3Kr1e68IfRuURZ29afy8LJPhmVTR0sETH3
TSKLnjY7ts2fZtdtGx+C6c0dDktKzGN1yPznUbtk9Qbo5IDjuSe/MzRw6k91u75TQmp2vvBR3JHF
PWa1O75dnTUaxpXDE6eT7bbNiuesSTzIGCSEoAQDQrmtKSAMwSkAlEkyBgkkpCyJaCMjAAQYJQBE
pJKSRgGkgSrkFGsc1NoRvs2wZpqEJON5ePkm681aXDGKoz5GhKwZBXX026wqJ06w0Xeq9lG5scn0
yYzKW0Os2uoWesxV+xXnyg9X0zPrvVp7m3Vm+xUPvKOpljlR6/R7tSKrs2LG2r+w1DKn/o/PsRYl
L+ks9z3adH8+2vrVpZ5EXa7YnnvomiZ56ci6XEQMzl7LvrNpgVPusYzmcx7aTXdvp9jotQtkNbeF
IvQyWq6Tqtgod0otJuVTZ7rjVwaxOq02e8sRKUpJC0BKTIgSQkyCVoBpQtR8jANBKASYJSQAZEAg
1EErSEqB8lESiJQIGlIF0MlhSDbQvD09M4TuugZh0vOX3qw98ly/0LjmZMuYQDBpJbn01F4lo+kY
lcdpwqO9E5HRPRNUxbfXGSbZHPcO06LfzcQ1v/SqWhg5cU+4YHqsRVL/AGE2TCKeSUr500uadcIr
JRvWYZf6fpGGx65r1HRO19f0a9qptqiHVRvPnit+lqlmnpLMnE/BTvmxhY/UuSLmbU+7065+e9gt
FOtFdnqLpOeWiV5MoKgV2X2bL9grdhznUM9zLd8e57g8z62xTryfGpJBERBASDQRAEtJ8zB8zMJS
a0pNKgRoWQIAJUlSSAMJCjIjI0EYBAwDQSyuaVJNaVN4Nt6VtmFbhd6GytWcaLWLTScx3/Hcxap5
giUDT0celG+IaZccnkd386sfTmG0b0xRsh3CTyrecs1qDiM81+tZs7f7dXp3NdT50W9eediZ4ie/
wWf3O3ee73q2Mbr5w3am1CBuml+d4709QcOYk99WVK0cbTUZLO2WzVCyZTruY5b6Lr2M+n8klbhH
OfODKx+nsakZG3PhA2jzqnT8v9AV11WdNoNlp/KytKt30Dzb09K1p9VNMpMvGQ9q52LM79EQfm1P
NCOakkgxzMjIkhKiBI6IMgCSYBgjSRggRgEYBESiABpBGRAEakoWtCkoURXYEDMuaIVhom503QKH
eDl+HCgzcBzsGMV5HNKVEFGSl+gLZiVW02yQ+pYVz9A5DSPRVLx7e+2L7HIRkwbuqT6MWbeg6dYH
VLi9FzeG2jhlOjNc31J7mM7asij9SxTRL/xyPTcXr2napj2ethO+gqlFXxlU76eT6JT5/Mdir+a7
fXqRr1CgNptNZofU5lzULJo2Y0TQY+j1NK9As+V6bRL3X7nGUnReFKhq4V3uWYaTRL5ykU0q6Rdc
ez2Sty4JXx48i5mlR8zSfMwELJIMiIjIzCkJUQNJAGpBGAAQBAjIgAogEmRGCWgEZ3AKJXTghERH
yFw6OmMi4cc+Md0bE3j2zdKDJSQYV0lpRlHk77vQxddmfVzxT3UHnNq94seHE1SHVbxu0ecOUgTV
8TOHQs5J5CcFSD6Jakvg6nGkEjiCLqS+qO6+szE8m5rQvpIdLVrDTHrP1550xc7w9wKO5de9jmKg
x5DvbY2EscvT2BTFspsEOnaXudcrbcpG89YSxqiIa00vjdqnT2iEBJpNSSHNKiMJSsgRBKyMElSF
pNRJBoM0mFEhQSSiNAMIWAQIlESVAjuYBH0SjjDMrXuUBaqndETzRswYx8bM5ZBtUIIGSQtfTX9F
x+lTVyqmydcm0Wy5VM6JnUTr9ZlHrKLsPLJKufKybtQ7wqNrt/qXKzdGs1Xc2ozpv032OxIK2C14
C11Gh1HQdtzrEo4IWlY695p600u7YMzeNF91K3mjZJGofS3N8mRa8Oy4TrIWDeE5tnMa9ue54pQf
TC8Mhek3vmDZuxf6Npso2w6C6aPYrAmORYuCI8P1+ZafzSSTURGgERpURpMgCCTSZpM0AAyBGRGZ
AwklJCFGkwaTI0qSSgREAm7AgayDeHZbjs2Ba5cYuoaDTJu08qDj+6ZnlcdyIgaC6Ebn0JL4K526
CqvoHN6LvtNzfY+GX3e30PR6JfsZ469mtyaUfWpqm2mn3HrQL7kDHXo/rmjDUXlOj9Vq9C0+qRGv
UrIL1bMfp3pqp4UwIkmal6Hv/Cl3t5gdu0ehSlkFRv8AWvN0Si37/HFLzMZDzi8VutlhbJGSSYxn
k3oXH4v0JjzvUk5np7THc62qyWPO9EqTiS87aFp2aZL6H52vPtEGe37zDnnEgkGCPmpJhJLIJNBr
5koJIEAoJNJKMglSVBIAIJBpWQBpBKSFkXI1JVcgSjJZcoZhvGt+cdJ2qgVnWMsnZ2RqOF+hc9yG
PLkEqQpQV09Bznn/AFe54dO+gcAhPSeV5j6LhsL3Cy4hvlTuGX6FjGmJzWx6HNVyw0q7dKTdMyvW
KtZ3RLD1gYm4wTMWRrnGl8s8zH0dlGW+nKpgzPmayLsdx3zjk12s2M72cVXLRQ859J5RmUMHHoDS
8R2mjRgsspmtylqvZYNxB6f5zqfp3K6Z6c84axJVSubjSZSuSuFeo8103B99z7DnezsW89ivpnLN
PVlWreU6QgII1ISpBmlaULJKkGpJAyQZg0GDSRmEggQBpAIKSSgZEEmRgjQAZkdwNCj6JQiIj9R3
fLNIcvazb6rPV9o5yvaMmzVsSEKCVBSe293DDGWxsqfv+D1b05k+Y+jYnC9mt+HbxUL3yr/GT4RF
GpPqKAsNVtEG6V2atWSLLzeVB1Z2zV81d53qXPIb3TsbtHo7L8PaBw+Uaz0LVZ/I+GwVCzt+bOS8
0RPpawYXSus1v8NzsTLlUZ2wYbW+q/RDzHNdrPWo7LW803PCJLUk41uPCl9vOiNr1XLZrlaKdeV4
PfInGN60TCJLZMnwJCUhIIyNIWlJGkJMyMiSFAEZJUAgKBGSTNJKSZkDIiMAgSgk0GSVkDTdELIz
LkiNjXWoO5KsWdzJiIiOSmzmksOXEiACgE9rxa6jWJG5tLPSud2rlc0GMqF66UyyzUG7lOdbneNK
VeIx1J1RhbKvNyR1ieFYsTmpTYS1eco2fZV2UrXGdnqvF8e2+WpZmVYzVvWk2OFdLNymBbv3Fu2T
rFYdDueDqPJLhmakdyD0G2Pmjo0XI82C1cXPRsgcO/JXR4ce3boWSSLkEhJJBEZkS0ABKQFkk0hC
iBmEGCLoREFBJhJpBpMjCDAILIgkloAVzUm7ERmaeaYuOeaJIPoWZcSPNq2jO8PIVOPb8UhRJWCP
rZrzW6iqU42eap7+zVTjd69B3Zsiwx8Na29Gg0L7aHHzE1DVi9V6n2uRoWgvqDYLTRF3+mzfDPb3
cW+eRsNH3DTqTm7Tl36qSOt31DIa4/2jKIBTnYumNRrdPft0Kx3zKm5BKzGpV6lc1PtWveUUVry6
EOmxSuDRrqY1i9ZFQGvPorlomyIx3L26EqQCIkhJERoUklEQIyUQSY5mCUlR8lJUACI1ERpSYIwa
TSlaQaTBkAkwDQAaLkYNRJVyioy9+j83vfWXq95ge8zDRuUajm+bx/FABGlRjrtmpYDVr7pGT79G
5Rqz7MbBfM/gdnqlopdxqkJoWTxS67o+uUO60e5xfN5mGu1ui6myZWKFXJwcnHSeM60xzavbNW8o
Hour4NGpCVGar16byykHt2BWKbTYrPnWY1znM7E7qGqy+DubpSZaXVCbLVfPshpla3Sk2ij022Ve
/VOm+iYzzFx0/U56g3Gl024UzRKnT5DXKl59b8yMjQEg0pCUBY5rIAgQIyBkQBkkEFkaULIJNSVc
y6EAgwCMAiWkgAADQSkGq4JWQWhfOIi9a9C+cbZvNezLZ6JHacus+etlj8MYc0JBAyNR7boXnO27
PivX0Vj1D9H03GfQSsB1u84VtXGYwm99Yy816O0lVXsUe+cU+2YpcJGJt3Cfb121lTLjTbWxhOzr
MaXvlDyL0pX8AZAzSZ9LZ6ni4XKfQ2B7tXnNUvXXFclRpW9V2gWyz+edlvdWhbkjItizHK/Rdqpl
nrNjoOl5xH6g38wajdvNWj63mGwVay53qOWlpfDy1fdaz7AGxEkKIhy68wCQtIIBSQaTSQAJKjAS
Rg0GQCTIwokgyBg0kCUkEDJREZEaDBkq2l0SsGkoiL0f0lh1n1+LzjT80n5OvT+B7RAYnH8Vc1KQ
CC17Ppvnae1ahVb0rhlI9MZ/kW+uMC0vUfP/AKMyrWYA8r0jpjsmjbYiz5BsnCiX7AtCmK9aW0uq
rWnpR71TpibzGm7HT4PVPPVe9P1nz+yJfU1l0tvp6iSWJ+l8M2+trrtglMjydFx1625Z00WkaXW+
9Ysvmlj6ugcui9TzD0TW+9d0zPrZDWXzXrloyzVvMr30rXjg9GoVph7Rkrq60LAeSTQaFhJGhSQC
AJJGokpUkwCJKjIGCMAJAIEYUlIMAglRoUEkZAKQtABBSSCrcFhKiLgxiZDdn0pWrYi1MWUbULVn
2jY/VW6CCQRg1q1DYsozK4ahTNkySi+i6Vj3oTlguv2/CdQsrEpfrTbH2yGreiq67mKvSdVoVT23
rkl2eYnpVtxSwaXkszpkFTtA44/qON1vQdcyjNkLudl6joc9IUhUPqmaarZoeoV2arcqbuW55Sz1
2jzT0wrG2mi2zHYs+mg2vL9Iz2+wVlbVHREVqlQYvNvy3Rs80Gt2ljXL0zypglJGhRJMglSULCUq
CSMGgJMyJYSk1HzC+SjIiJZoJSTBAJ6IANKkpMwCUlKkKIyJIuiAowfJEbE97HNLR1cOejfg06sz
jmPJBBAIKCy7L6cDAWS0ksLSoJMERKNBqUklABCwgzMlFx7Dn1SgggdeZpPn1SnvqkwAEVzPCQpE
n6Am8mzBIvNjFfoBrQjqlKglSUqBq5moiURpWggOaiUSiSACSYPipJJMERkaARKCAEhaDIyIwSTM
gRhJAGSuZkoySZklRJCiBEakmRGCAJSCJRBIuCkqUQVzjoaX3R+vjKi0xzd3UJjMdDzaktOKSMc1
mZg0mowlRhIWtKjNKeiQa0GAaVmSehJI0qIyBGDSDAIAIJSAYWlSAakqAMlpHVBAGfIF0Mgrmsgk
wCMiMKQDB809UAJURkQSoJMJIiIJUaDBJUgwkEpBpJaTNCkkDIyMlJIjBpCVJCTUaTIJR1CTCAFJ
UkyMiBkQIGCtyjBpUBFxF09T4fJbSMg1+osNN5xHnbTHmCRjY0AlpNKgAnshRpMzSa0qMAlEZAKA
IlpWASVINSFAEol8jMGRcugIjSDMjIlAEvn1R1AQQNRHzBgzMySS0kpA6JIjBmgErmFEkGaUmlZG
gwhaEKIjIiM0mkElSOhEQI0qAIEAkzM0EQMjIjBBJmaQRAyBmgJURdUJJRIMyM0BQt4I1IWBGwtx
9WYZx9ENcc2akQelQU55y0aw+fIrlyAQtJglAuh8ws0qAUkLNI6ICkLMAjUgwCCiIJMKIlAJNJKU
kjNKDBmpASoGkwZhSTMBKkmZIUpCiBqAQaQZmkBHRBmkc181hJpBKCi5l0SEAlJSCMAgRGCAQogl
QAJSQkwAOfQEg1JBLQAQABEtKeiApBkakAkmDBGRoMEm5AGQNKWULK+kG/C1KhrrWJDrl2mYbrdN
ydnzQEkYBp6JLoAFElRA1EsyBAAyBmDIJUAYJREAfJa1ISDSaeiAo0EAYIjIwDSZhZAzIAECI1c1
ALBpASF8zUkkdCI0rSkBKkmk0qBJSoiUfMyAANIJINXNSSUhSVI6JJaSNAIzBpIBIWhSQCBGCI0q
IwSiCVICTMwkAwkjBXJKySouaGsGu12wN+knIrY8ISUhZOpsEcSSFoIGZgwAYSs0hYSoEOiTSsJM
1EEglBKjIwlQQozCFJAIyStXIwFoMAgaFgyMlEoEZ8yUZhIUkKSZBSQlRGSuZmEAwEGEqBAlBJhP
MKIAAc1EDSAYBEaSIwhYIEYIjIAyASRgEZGkunMzIjJK0mRmg0gEoAiCiCQBbyUAZEllC9NDvMa6
azUmbJFZm6ZaqbXmvFKSBkDMGE9EmAaVkSyMwRkApSFkACUrkZA1A0koBJmgGkGskmCMkmAYM0GF
JMyBLSSyNI6ICTUSyCUmSiAIGYQpANJK5qBKQlRKIkqSAlSVERKShSkEZGZJMiSaiBBZEQCTJIBq
QRggAQUriFKSQI0qIGRoURGAQIEDJSbegKNQCWUJLeoIKG09xTbxAC4RXTA792w2I4JJKkBRkZpC
lEhagkGpI6ICiLoQSZg0EsyAIGaQFAEZAAiJQIGkBRBaQDSpJpClEkLMgCABGrmsAIURLBI6JIgD
JK0kkBKgQBpStK+RA0qNBpUCIBJdEq5ksIMGkGQMglIUaSUkyBAAEDJRJSoc+hAgoAgEmQIlIWhQ
Mgm2qMJ6JJTKDmvW+TVL0XJ4hrjHOdh4vPOM3qHnKC4IQoAyUYSoAGDCQZgjACjIEaeqAZ8+hAGE
kpSQARjmtSQDSS0GCUhQUSTUlXNaTMEFkCBkYBEsjNJpMKCSAIyBAECSYJAAUkiUEkpIM0kaTIwO
ZglEaU9OZmlSDMBBmkEYBGSkAJMyAIjBBKgDSZ8zMyASaFoMERg0gW1aVcuqiS1gX/qWvVvaE0S8
VBxass1PBrdaMAh+SEhQUEhQAIGSlIWAZGRggpXNQUaTNAURkpCyBAlAjBAlJUlBqIlGhZGCSoAj
IyI1KSZpJXLoYIAlERGagkjNJBKiHTiCSkEpCVgczBKBAyBhIIjMJBIWaVAJQoGRKSRKQZglIMJI
lBCzSQIz5dUhKgQIgZmgGlQSRkokmYTblIHQHzJrBJverQErFWSa6MW1Cu2f3vPqm358wtaQoGRp
6ElRg0kFJ7JIKBKSRmojNIBGSVgzSQNCyR1SSTUAkAKIwDSDANIUkKCFGFJBLIEaTBpA68wZEoJM
Ek0qShBkgwRAzSRAlERoMGS0ElRkRAEtJAAEZABBmkLQYSS+ZGoERkASTBmQSaQFERGCNXMlBIAU
STI7WFAF05k2gTn7XydNZXp24c49xGOI2L58kGroCWYCkKIAwtJKAUAkdTSSkmZAGCIzSoESkko0
l05rCFhCkhQSAYBKUSTNJggAlZrQrmsjM0GXRBoUpANR80rJKj5qJHJPLitaTJJkQAJIMAzSk0KB
AlICwgzIglQSRkQJRAGQQogZEAaTSXVBkpANIUQSZEaTMjIjQoiBhVoWogZKJnBd9p0SkX+HlJPl
zlK3L4/dI3JI3iuXPqaenJfZufbh1QoI68h3b9e3BRpWSgfTmXTmtXHqfDqk18HHJR8ui0GRdU8n
HJQT24L6N3B8eyefZIVz7cld2/boxfJ4u+B9uXVA6cV9G7kNnnPm54mvj15rcRzvpXK+3QojQoIU
RKSogkGR8lBSFkEAwDBBJkCMJBpUEGQSAEqIGCBKCVFzUFJBAwZESgQIJUQIzJIUDs5molAlNILv
6rgcy36045dXdC06QV59bbL57rPCd3eThOkwxi7GmpW/tSbf3p1jdwDuUZxNjKq23tSLl3plq6wb
mTZR08KvbO9GunWl2ztASTyPZzyata+1IuneiXFzV5h7Gt5hFfs/aj3brRbr0qs+7hVy3CAtHWlX
LvRrr0p9md153KMYmynTbl2oV47Uu1dq7ISUawsXOr24YJjvBC0kFEgGpJBKkgyMgCBhCkgKIBJL
SaCMyQoloMIMBINKiBGlZINaFEQBpMAlJBkD5ggaTUgyAO2gJWDCedfX6iaZhu1lym1tqrotI0XD
+Gx+eqvxuXoGfrhWSLhLmyq115U25dajYX9d6z0VGWtjWLpwqFxVVLG5gHEzFR9lZ123t6nc+dUs
3euSEnDNrGyrdza1G68qjb11eZewnOfZV+3N6heeNNuyKlZXMB2lWkHaEUu8Ci3/AJUm4Krsg94Q
VlOk3g890blRL3yrE4pqwmXFIunbzrnpFyWREvksgZGklJBGSTClIIJMwAQIyUQ5qSZAwEGZERpC
kGYI0qSRhaDQQUkjURkaFBISFoAMjQdrMzIzQnnBcdP2Ol3ynXB4vmrLNKym6R+RseXW6ch24d+f
N6z79WMhwZyrA3THutu/ZdXMY9DSUbcXjF0GbrhwkGPZTCRZ8JKN6uI6RbcX0epxHyTdtIxndzHv
ubR8yJ0zc8W8kwW5jXxMnjZXVr1RzfsldmDo2Ug1T3bdD4uW5rbdVtXHBHZiaQaSQoyJQI0kaiQs
IJaQaApIUSQYSZAEaSUQBGkwSVBIXy6JNKVkRkpCyIiMGEglGSSIlkoIUQAFoUtCjJCEQzWTtPfs
2fOHXFqx7te0Yz4oVI9eLYjSAOi+IQpBKNRr5AyJTvsanHEI58uADro35o5giNJglEaTIjNBkFIJ
QCkAAwaVA0mkEskqIzIlBIWgjANBrSQPn1SDQgGQCQDCTQFGglAEEgzCTSlaQXRIMkrJAIlJCkAy
NJGoIMjJC0qIyIL5gEF8zNJgAJBBRpMiWSQRGVsCgAakcoHlddlq9vqNxXJM+MBI0ybi8/jisu1C
qZo3QDWi/wAjmfM+PEj79eiTLnxTLbG8gLqiuv8APdCxqI42jZq7l8ctjz5GXNaufZKTBGlZJIAE
ojNCjSZpNZEaQaVGRGQVzNRGAR81mSOg5mQMkrQfPoSQSTSCUAARmEkAZJCiIzQFJ6cwAFINIMiM
gkuiCMJBLSCUkyUkyCTQsIBmEmAaUmogAQIwkgF2kAzURqbQKN+u2N7XYqcJquXCYTisLrGIVLjM
+lY7tmtgqMjIln2qNs+0AUGnIc6nNwvZ1xziEG3WnPJDXq9OjH9d821hz6VYWLIOtjwllyHRJBKw
pKkBSQZEYBKNAMjSAa0KBEZpUkjSAYMjBKJCkqIyCDAM+SwRBIMJCFhCySFkRkRGQBpNPTksBIMg
EqJRJSAoIBpCwk0qSRkDQsIMjIGkwRkRGQIzSZoJQBEaFBVrSXQgtKm8Hw9C27D9a1fH5C25foPK
2Y1S99wultJX03B55frjWYywSOOXZ9BWzO4OicbV6SzfRIPvMYXQE+gl4lMejqnU9VxzY/NdZdeo
oez5DQDrrdJGvmSjSC6JStC18zSYSZGnoRJClHzMzSAaQCBklYSlZkkKSSlDmZpCTCiSkA0GRBaC
WkGY5qIyUg0rJJoURpWk0mYSRAwgyUZERKIAiNJmRBaQZBJhKggwRpLokgaVBCiCkpMjK1mSgXRB
8YVprWwZnqMe+j5GOnc7uVIjtGxCriX9J5zR95ZLrVklsfuFgrNmosbnXGzehqHoFXcWfCs/Rrt0
r3XTMKjN7oOgeaYBfoLtacGkrZhLQJILR0R05gAlAyNRJMkpUQSDUk1hJrCSNJEk0pWkGpAWk0GF
EZGEmQJC1cyWRJUkglQIEZGvmDPmaVAyQOiQZIUQJRJIGZGRkCJaEqCQYI0ksiUlRElQAQDNJKSA
YIESgkjMgLQowSyJHGKZPdK6Pq9ZnbzmxgJKIlYitNimtHhKjcZHhFdntXtjqnXdzRYDk5v83Vxy
lKLCG70aUrlpptZ0CYq1J4JldIq9PNbIh0Ilkok8zQtQACVJMyBGhBLLokwtfVRGlunilaQYCSWC
Br5GlQVzJSUrSAoi5qUgEDNKVpAMAkmCMkLJSB0SglJNSUmZEYCj5mEmRkCM0mkABJKBA1JA5qNC
VoUYIgCAAIwAkGLUAsiMITDMpbSjlICe6P8Am2j+bPkKrw4SF1g7FT2pISS+SJu7qintan4WyMae
04GpfWTfQLRRH26IJKrA9qbVIPssyUq3PKQxSLBYqTzB9eYJRBKeKUrUtBjvf7HB8bRF5zENlBJg
EDUjmazSZEauZqJIAMgSFGkkqSZJMyMwkwSkGCIJBqIgDSZEZGpCiNAM0KSpJEoIUQJZAiMEpJJU
kGZJUQIJABqJCiMjSQO1hKlkaTRCMtR3PI9PW+gbTDSkkwz6D0DH6i1sm/xktjjtmycLrUdyvHoe
Gd9co1eKYJxeuIeWnk222PxuE4OLJIc20o0r+yM8hYc3VnfxEx1aRu5SXnODR02Sbxye7x8rw49u
nDk0c1RgJC5dq1w2TMdOjdYola2TzrQW5JBmRpUCJQJKiUBy6JANKQaAoiMAiNIABLSklkRGACAC
kpUlSQDQQUSiWgEaFoUaDSSiBBRGk0hfJSSUDIBJGZhIQpaAlfNQCU9CtZ8+hF0CURDDZtg8+3/b
83gNRzabt8nluT71l+bs+237Nk1gleNank5XnDef9OcUvMh2NeRjOa+m7bn2yrXY7A6vxmfQ7hyl
gxyHZo/DI0Svoe05xqKYWv2+J82whON/mc82GDkLJzipYmhUO3+ZIM9l1Gq0OhXfP7Jukn5/125e
a6VxSYABEYQZgjQFgGlRJCFECBA0AEDBA0qQpIMyMkktICiJJpMyBEtKkAlkRLIgtKDSZGRgySaF
LQQIjJZJBkAYQoJC+ZGDIyQsrUlZGowlMNGatt+PXK+R9UuVIt0G8jM03HKM7bvfQVwrU3UI3lfm
lMx9vP8Apas24ZLrbem3nzzTE79Zp7z7qsXl1T4OvSnC5pxSuQuxyeAR69G25VSu9esiaTM+cIlK
9lvVLuNc0PrBT3Wq2fnRLh5i5y+lTeOJiNtxqe7egMPhPRvm6hoQSjQpIABgJBGoySkdCSpJJAIj
SDHMwAokqQrn0IGgzSZKCVICQoGkjBkEgyBkYCTIA+ZLQoyANKDBBYSSkF0SZEAQBKQZkZEZHZjW
RLBcyi4mU2LvK1C8FYuUTXz5t5HMInnObRn2js5plS7byqWdouG8NKdYHtZgL5HZHXy0zR+ebu9N
y/MuTz0hZ6QysDPENq74i56WDSG7OQot3YvU5PyLjq03k+p9qjMU29KzjRIOZRjN36VnXXOM1W01
zbJuoKtkHh0fzUCABqQvl0JII1ElRAEYIkGkkpM0kRA1EDSSiMgEkakGhQNBgjJRJBLStCkGZBBm
ZEpBpBpURAECUQSahzMlAgaFEvkFEkyJQJPQk2kzQpYSXKOiXlrkT4OezwN+TPoz6xPDkSXKz59S
SpSEhZ9EmQQZhHbmFJMcukp6PgcPYcljl0vt6VGZTH9EAADWLEmpZrz6JJfPrwWpJDmZmCC0Go0L
PkaiJKgkALIIC0kS0p6mgjJCyCkJ5FzBEkGkzBgiBEFAEASApRJMiURkSiUkiIjCgEmSuakGRGDI
0koglYBAGSEmFER81KSZEAYIgZC0mlRH0SfOLjLHv8DYWM/H2qJJ7XeFQumW1Vtyeu3Keg59EhRG
gdeSunI1clKIuXcuffivsog3AXzPpzHVJESyQtST5LI1pMwSuXQkdEGR8+hAKNClIMk9QkAGAS1N
+po6khQ5dzSRGtKuK0x0XxC+YStCkKJSQCMABIUEmCBAAGlaS6JSRA1c1mkgCACVES+YBmEEaiIl
IUQQACNQBEYSZEQUQIWsyJK1g0R0NovozA53c4DOtWpR6WKPh201XJGS9ZvnSqWoVS1dqxNuYVxI
NI2eKs2brTraupWjrWZl5FlJcYaw9KhbetMt3WoWjpByDxoxmelUs7uk3HvR7b1rE64iykTgbF3p
VxcUe6rpNxOAk3TRjM9qnbnFBvgot7RUrUIrpJpr9m7Ue79870E6PdF1mZ7sms4dStzjz3mnEjIk
dUGEGCCxzWCAIAxzUYCDIGrmFJAMAgRqQCMjCVoQsJBGoiBpJSkKQlSFpCkmQSpJGZpASFptCiSo
1mgRsPePSeJyu1Q+c6bnkvMtOmIbPWMjZONv1ThT70VKt7yoTktWV2WEirjHVm6cahcV1CzPKpLS
8Bzs0TA3NlVLtyqNwXT7I+rTyah2Fnjq/cmtVuCKnautYl5CAOwRMRbmNXuvCpXEqjZnNafy8K0t
EbX7fwqF34VG3rqc8+rTyai4i2Nabe+VHvvKlXLrUZ11Dc51vWLgnzfniQkgZKCQaTBLQZEpCkgA
wZJCVJUYSkgtKiMjJSCNXPogyNAUEkYIlnyBmaQhaSWkIMyMEaSWlSDB8rYSiMzCFRsLI7pIOGE7
xskfyZVWy5/pWR1PiLN3fxzzrHSbdvItx2bOeZOWa3sTIlGzDZnKszcNHHNL2Me9YiW5MJdpwk47
sGsgzW+h3/SKlGrSZjDdRzzm1kWHfvGv+cfMxqZKLcdY2UZ8ZOKc9YyTZIkozq8hpRuylGAdMXTZ
DxkUhF91x7/i0fwiAAlSQR81AAlAkKMA0pWRoAQDCj5qNJBYSADIERkAAARgjJIBGCBpMGCIjBEh
RkZKJHRIJCwqyqBBQCebOFVPTxp6OuvXhx5KbFHN+RJIzI0rBpILIGCBKMyIjIGCUZEE9uZglGhZ
K5LMgpJkSiNIAUhCzBAEnoQIEoiMEZKIJLoEmAaFg0hC0GAkGFBKVER81jmZKNJoUfMKI0mkzNAM
0kZJM0qBAlJIzIlESTWlKiSZLIjBEaUKNKiJSTJKgAaQEmASTMyUSAABaTSolEoJjod7rtmYLdOJ
1ux61uUo1vzuvceCTA6AgZEsjJKjACTIGRkDBg0qSDBqQnokAwZEaVLCQSkmYSRGRhJkSiBmkyIE
ojAASZLIyMA0nzUaQo+ZhClEaQRGk0giWAhZoNSAaQZhBmQIESFkFGgAwQXzMIWhYIgQCVIMKNAU
RpIyUgJWRGlZErmZhBpWSSURkpB2k0dEKJYEfCWP0/mHHYO+WaXXOGkMYbB9VYY0w4pUZkQUaTNH
XmZAKSD5rUgwaFBfM1AlGRABSTNJmQMAkqNXNZIUpJEpCkGrmSjA68jIBJgyMzJIAM0gGpBAKSYJ
CiMjAAMkKQFEgKIyMgaQpaCSSiMgRjn0SCMwkwRGQIzCADBgEkzIjAQZq5glc1gJMGRBIMgDSAZJ
NQ52oEZLC0GzgJ71LlUJv6ci1msV7R42Q8/aXIYZG8kKUpICeqAaR05EOiQCANK+ayWApANK0mST
UaDMzUhRBJgwQASpIABABBkZmREZoWQJaVJJYSFEkzIGDSQAAASRqBEDASS+ZAzJSTSDABGgGZ81
pSZhJmaDSYWgjBpStISaiM+ZmgzBERhaAaUmFJIgZoWCPkZqJK0GgGCtANZGAlHGAdeg3UPdOcVb
azIu820bFdWqWXMiMjJQQo0kolkkgFISS0rAQtKiUakmRmgKPmDM09CT1SSTJSVEXQuZpMgRECUk
GCIzCTAJRgJUYJSUgyWfJRkYCQEEowYBERpASRqAMlIIyNRJIGRgiMAIJRkpCkgyIyNBhRBJgEpC
kGRkpKiIySoJBggCNXPogyQOhJQaVKI7EsdCSo+aW8EiwXTko30qpq1hZiGkqqxSk+60p5n0BcjJ
STNIJBGo18VdOaSNx1QhXM0AyMIIzWtKgRIWoBCwtXJKEkEmkGokkSiJQI0rIAlAwkwDJKVgJMyU
RBKgFJQojACSSsEYJRAIM0glpNJmSFmk0pWCSYMlBAMJWhSTCQYAIiUREsEQSAaVAiM0kZGkyMjI
0EojIysqyWRKUhTSDRdNBhpSNnXym3OAlqhYalEN12+48KbCFL3CpQ/EAKJdjho3ig5W0VLgCRyN
zc+9Tl+tZHILSXFJr6dAoySSiNKiNzco2tcefJCDIA0giBKAAUlRAKSYSa+agQWhRJCepJNIJQIg
o0GDSEkoJWklAHyUhZAyBgIMGkzBpSDI0mlYQSyIyNBmAAREZAAjBEZpCiStABKIjIySoGRGCLna
FGD59TQfKvufRJ1fU0120xRXCIXh1/bY5HHquxR1Fr5K2jNs9kX8XylWj3Z8jzmP59tLveQP+0TB
NE3r0TWsZ0uDoqF9ZDpXITh1scuz4TTeKmeMRNdIt31j3noXPM1kI6tsSQDWhICTIzCVA0LIgAoA
iUkwADIkrANASZKABAlGEkpPNRpAMEZGSyIEoJNIMiBkRmSeiCUk0hPQkqIjVzCjQaVkSFGRGAk0
dAklEQBGQSpIMgFBJlZi6Dmo1JHGvvvTdWz7ebJiGoc851zm9872O/8An6IGib5zqdxY0y6N4C01
ea6wsvVNJyfII7j22e+5JscexwSNVre1YBVt+rcpDWKRsLbOcSj530fwjbJItovm1aWFMNaI2Hmp
7PLLyr+HRnAlKQlY5EDASDIzMgCNKwYSpKiMESSMlpJSTSolINSDBEaVpNIUlQQZkYSolESDIlJU
RmRkQIGRhBGFEQMGk0mlSTQZgGhRAkmogSQDIzSRGaFGRAgBZ1JAWhSkcIFfoN7R9i5Vmy17pacv
07D7lOYdEL0DbIqTKgstMgrMrM9NVl+lY/rWZ55Aceuoa/hG8Vaw+cYU77vnnWvb+1dc558nOq5n
rd3sFyg9Cz1hoOeUzW46WZXOnXDgxqDC2VXI5DjBzL6rv7BUG5EAEqMEYMgFJJRpMgkzMgkKIECM
zIjAUSUqQFkkwYMIIzAIBaARnzUQBKSZKQZLSlSTSDIlAEZoStCiNJgEkKMIJQIjSoJUkyAASFJM
gEnaErIwCSnjDNbBp8ZLQdkl3UfypFyo96z6v8OmhXKI62DrRbjJU2Yl68Vhjco0ecxqtBWu3jId
Kr0vjUaeo6fi9a3xll2uNKHqXTMM1RK7hLwCbFGQFza0y9qy7QqvMSSIp3MVbHdrolB19vlOgWvE
+CTBkRmQUQSlajJK0GsjSQMiBpJZGEKIi6ERkZJBGpJkoiMgRkoiNJGACCevMwEkowk0qCUmZpMy
SDCuI6EpCkmQJRclmRGpBEYUgyBkZJMjIyVzs5pWAD5IRCs3siolL5rPj0SfMwZmhQQrpyCxw7gE
rkpCwEDqkiMAkdyQfXknqgGDNJdD4dSR0CB25maSNXMz59S5qCB0IAlpNJkZ8zSfQgRmSVEpJqIc
1mgjMGgwEhQAQsiAUkyMjSZGQAAUgBJhINaQkEsiAJSF81EZEokqIgAQUhZGkyNBggaQYQoAjI0m
EEsEpJBFpACyII5Jg2j98paVGklJSpCwErSRqCVEAYBoNJpJZF0MyQvmpCjBpMGELIBKwDT0MhzW
EKIwEhQSAkGlQCkGgwsglRGaAsjQoGEgGFJMiILQApBrQQUhRGQUkyQoEAXTmYUkgCNPQAggyAIK
SCUQBKSAkzVzI1JIzT05GaDSsyQpSDPmo0gjIgDR1QlaQCCSOzkYNJq4FyiI99IH0JJmEmRhaSM0
GFpASlajSrmai5l0SYMzIgAC6IMlJURgyIlJUCUAYIJWpAIjSaVEYCuS0gJUlaDBmQIwQUZoBrSv
mZEZpI0mDIwAlQSskg1pLn05mQWkAEFJIyCiCkGD5rQFoBgBJoMyMiURqQpINBkARkDBBKwRpIAE
vmZAlBBmS+ZkR2RKlJNR8OaIdg4lVGDCkmRGlREoGQCwhKgSwtBBK0mQSFKQZLSs0q5rSC6BJpBm
kAlkS+awAZEpJpIyBGACMjJQQZg0kaiNK0mFJStCzQpC0mlRA0GDSDJSTBAjB81GklGgzIgnolRo
CVGSQojIyAASrmFc1gkKMGQSDBKSlPVBmZGlAHVBGSFoUpJp5moAgQXyXztA5L6IC0tiiY5xJqCy
NfMzJRGRmg1pJC09EBZGlaQRgESj5mZAzBdE8+nNQNKkmRqBAwai5rSsjSZpIunNJKMkKBhIWDSO
iUo6klRKSsgELJQCARmhQXz6JQaTJSjQASVmZJAQDStJmOawoJSnoakAGOXQkrSZlzUkzShQNQBG
EGEktC0ERrUnkOhggSTIiANBdEBRoJRJP//EADcQAAEEAQMDAwMDBAMBAQABBQMBAgQFAAYREhAT
FCAhMRUjQRYiJDAyMzQHJTVAF0JDRFBgRf/aAAgBAQABBQJz1avcVc7qpnc3znviKuKq5yxN8ROi
b4qZ+ePvxzhvn9ub79eWc83xMVcTbonztiLnxjcXFXbp+N832xHZyxG+3Hp2844qZwzhm2bZx3zb
EzbfFbm3tttnHdNsVNs23zj7bZtnFMVubLm2bZx3xUxrcVMcufPVExW9Ns36e2Im+bYubZti5tip
0di5vm+cs5b5y90XFduub41cT3xcRc+cXo34RMc3N8+Om/Vrt8b7psmImIvvip79ETF2xube6r0+
c/Hxm2Ln4RfdfjF9ujUxUxvRcTouOXEXP/4r7Ynz84qeye+bbYmOTNs3zbquLiO9t8Vc36cs5Zv0
54nvm+Kub9ffN836Jm+2cuidOWb9N83z56b9N83zfbEXFzlm+J0391zfN8/G+b9N85Zvm+3TfN9s
33xc3z5z4zfN8XN+v4X3Tqi5yzfpvm/o5Zvidd/dM+cXo/PhN+jcb7Iq7435XN8Vfdq4q79G4q5v
jlxufGKub9N8a7N/bfN83zl0auIuK7HL775v7fHVq41c9uiO2xHcunLN+i5vt03zltiLm+b4nRy4
mfjOXujsRfd3T8b+y41cVcXP7c3z5xFzfpvm+IvsuIvuq5viO36b5y2zl0cu+Lm6Zy6b5vnLN83x
HYjs5Zviu9ueK7OWNdunPbHP91XfOWK/N85Zv7NXGE9+4mc85Y12c854js5Yrt8R/vyxxPfliP2x
SZzxr8V+dzEfnNNnPTOeITfO5tncxCJnP37nvz9+eKTHO3xH+/cTZSJtz90ImKXfELiF3zuJupd1
Qud5M7m+c/fuYpfZXpnLOaYrs5pnJM5ZzzlnPOSZzzlviu9kcmcvZX53MR6bd3O57c854rkzl78s
55umI/OSYrkznnNM5JnLOWcvbuZzTN855y9vjOSYjs5Zz3zlnLOaLm6ZyzlnL33zliuznnLN8R+c
85ZvncxdsR2K7N83xXZyzfN83znm+b+26Jm+Ltm+b+/LN83zfbOWKuKvRVxOm+ETHdN8Y7GvxzsR
+dzO5nNM7mc0xSe6E3xX7Lzx7854pPbnm+c85e3PEf7c87iJncxH53MQmdzFfvjnZzTHE2xCe3JM
54j/AHaTbO9nczuJiGTFOmd1M7yZ30272d1ud5MUud3O+md7376Yhts7+2d/O9tiHTFKmyHTfvZ3
s76Z3/bv55DcUvv387yLilTFNnexDpiSM8hM8jO/nfxT55GeSmeUi4snPIzycWRnfTPJzycU++Kb
O5ndzurndzu53M7md1c7ud3O8ud9c72d7O/iGzyFzyFzyFXO8ud3O8ud1c7ud1c7y4hlzyM8jO/n
krnke3fXfynJnkLnkrnfzv7Z5Gd/PIXFOueQueQueQud5c7655C531XO8qZ31xTrneXO8ud9c765
3lxDqmd5c7q53VzvLneXO8ud5c7y53VzurneXO6ud1c7q53lzurneXO67Oa5zXOa5yXN85Zvm+b5
yzfN83zdc3zfN83679N+m+b5v03zfN+m+b5vm+clzfN83zfN83zfOS5uvTfN83zfN85Lm/TfN83z
dc3zfN83zfOWcs3zfN+m+clzdc3zfOWb5vm+cs3XOWb5yzlnJc3zkubrm+clzkuclzkubrjvfHfL
l2xxMQmd7bO8q53c7y53lxDrneXFMud5c7q53l37y53FxSrnNc5rnJc5ZyzkuclznnLOWc1zmuc1
xSLv3FzlnLN+nLN1zkuc1zmudxVzuLnNc5LnJcRVzdc5rnJc5rm65yzfEcuclzkubrm65vnuubrm
65uub9d+m/o3zfonp+eu3/18V/pbdUTfOPXZeu2bbdNsVqp14L14rnFU6bZwXptiDcuK3bojVXFa
qdUG5cVqpm2dp+K1UxBudnjkxY5Eztu37D9uwTFC9M4quIAi4o3J/wD7A7FTC+2L84wSvV0N7MZF
cTHxlbg46kzw13bVkXEqX4SucxEriKj4qtxlc9+Fj9vAwHmwsNR4qbZx9ts26bdNs2zjiM5ZFrHG
xaR+HrXCR49s2xUXptm2bZHiOO5KJyNkwHCVoeTotK4jZVQoceJUWDXrIV9EqMkRFEseKpnNov2z
K5Q52F3h0ylbJpu0hgKxYNY6QrqBUZKhOE4UVxXgouTJtOoUcFd4FO47TUSMa6Evej6d5D/TzEx+
nGsbKjdolfWLIUmn/wBkqEoHKm2bYjcrqhZCJp5mSqPi08dROhxu89tCjhTInYJX1ayFWhajZ1as
d0eI4zo+n0Uc2n7bfHXnX0neYahag5URQO/+AIu6+tpBqz6EFUsaPgwo+25GquK1U9CJvlZWqdfo
QUZZ1HZUERSkr6ASCn0bUGSI4Zamm7uGoBObYVro74Fesh7aMDW2tL28HFc8tVTCVkukYopERREq
qvuOJUAdlnV+O6HBUxI9SBjLKlbw8Z3crKpjWyKcD2ToCgJWVndctUBW21PwWNAcUsGrjsHZ0glH
IiqF9bC8gkerAjLilaxlfW90oq+Kg7WoYmafjCe9wIQsHHhGWwrwieyDDGxBV7lk1kd44VY3uqkI
eFgxpLLOD4pNs2//ANP26bdNvRt6dsVM44ZPZcCPmtZVtRtr2hspo7HNtIntT16ZNYIZo4xOC54U
JNYPtx4rHR7Cr/dCis8W1FtIrDDak6D3WnDwdttitXNsaNVxIr1x0R6YglXPGfiQnbAFwLHlCjhb
dCeSVHQ4JbNnwoCyXyq9QYqZtm2DZyfWwUEN1kxCTIqHZCrdyFM2E1itmNNW/wAgAWwRjsUMSwhI
7K6vRjSWLROPHSYCLWbmKZkFgpDZmS69O7HAkUbbXmSfE7yV9ejUkWXi5v5wm1yLIVyQWRp6SlnR
UE9LxBgS/M8zSK+NYbulVQeEYlgrX2TkKoq5xcWmfiwnAJCa0UWTYyWHiPUsazYncgRCq6PySNLD
3poQpED9V3PMjIUdZARuS7F0d4HecEdajpUoiQgwp6yHW0PZCt9/6MWtfIcmnHbGpnBQFepnLSv5
LQORigdDL9c2ZDfJkllSGtjS1R5KeEw628JomKm3WI3maNFQMY9iRJPFsqHBgN7tnJfHSplOmDkQ
WukSG+IGFPMsmxjNWPXxGijzZpWyIy+YAEFnkWhVjsp5JHpYQWd1w/FAOxM6RIA08athNRlqcjS1
z3Sg+ExZdi5Y4ayUZS2kRvEMdAxzSTJIGzyYkGG3uW5yMymMQrL+KiZp4SoS2Y9GCt3lZXgakefI
J3oC+TDsCugSnzSyMo2vYS7N+x9oZ+QxOIbuI2HXvR47OCQ0iqa4ArviUkKjCaPL08jWyYygd/8A
av8A8G39bbr89duu3p29W2bdPzm3rd7Zv7F+F+a0aPOREZEnO7h66Q5pBAbJCVqRhyzKSXAbyjSY
vv5aoSvf/HXtlxw0GK3TYsd6tJGTuQ7VEQvRqe9XWI9vYCLDiGRgQsab6cxc8YSJZQ+yoeRSRa5r
cM7tRZf+anlMjutpzTqvv1hpufb/AK9I6847P4sNNnWQu6etZweVE8iyTcMYHEkhEUIf9N4Ny1/+
rGT79qPmSvD2zS27kmN3jjjYqbRoqbCmB7p6waNY1E8q12ckQHbLbt+29FV1ZAVyyJiRwCehpEJE
7N0iMWA3yTuRsILbsTlmkGRsBVWOsZjnezR+MsiQ1GwmDMhQP9rGT7x2RkTHN/jQE4hkC5Gq04NZ
/uWjeWRgIM1t7hKn9ESbrWgQceReOjkbcsOyPL4zXNa0I5zSGuhMVIEFx1GxkQdhYd1z15LEnkiO
kz3yEXrC9jM28LtjVY3+nDT7k5GqatRrTG9pFi3kMbGdyYnKLFT+GVrVNX7JHi+0qwRquiIzyJyf
clpuBqDz5iwU+xI4uPW7JiJ/Ks0Rcjo3v2Hsz4jIg8h+0KAmzrBUbKq+Pk6gTbNPlZytytYJXbyo
H+i/i2RWJ/Gv/eTWwnGV7hwQzZinJHCpnxIqRRzrFedUNeEu1HGLCKkwc+C4kiLH7ImCRR6iG1pl
67ddv/h/Ho29G3XbNsTPnPz6NvTtm2bdNuidNv6Hx02xfjpt02/obdPz0XPwmKnR/QzfZ3zV/wCW
R7w5C7vhovOvYohT07gyiVsitdtGlzUa7tqQ8X2hec4J2H7obn/OJPuQF/iW3+Zegk/fV+0S0c5D
tlkYgXuIdjv4b5vA9jYNkIPkxY1gZSuZ3Ys5OJQRnSVNBcDF+ekRPvDdvAUyjLGXeHCXiSyN2lrS
ciHd96wXcEYyuJI27QF/jGN2zwfaLHenlWjla6vfzJLcndOu8dhlUq+0aI5FFOIrDV6rwR38q192
w3ueS0f9mMzuS3sSPFmSFeRjl5Vu7oVwqqWn9pFo37BUcr2ALvC/0rDn3q73ixmp3rnfK7/Tke04
7kJHRxEM9+0aARFHYq5hKnl22vRsu23Iler3vtCIkc+Li9Uz85tgP74P+hat3IyGR6RmKOUb/WLJ
JHOOSSaSPGSOKwlEMUkAmz2cVp69JS2lYkZqpsvSGqdwT2kgkCZJAHIKHCkN7luJz1qGOY852+VO
+9FiRid2YVrRRTp402ORJED7USLKYsuzE4raobmlnSE5lJ3Y7YhO6R6CjVsxrh2UcndqmKIbZLfN
s298NbGewllKbxGZCxXwyd8b0jxa2Uzu20V0h1UJQreSUJmnWKknUDVUe+xaySwkObBe+REckWPb
kaYtA1FDfkVHK73o/wB8i3Xg0rlUtM9FiXEYjz0W4RK9qzbkbuzTkVBagYqlcm39TbFTNs29W/T8
9Uzf+nt026p0/Ho2zbqvRc+Om3vtt0/PXbF6b+r5xPUnq+c3xcX4L8L8wScSDlIePYROK00fk+ZM
SMyNL8jJ8fYkJnGPJgqY3hMAwK/x5xP5VY7eHcu2PAi9xz5TYoZxkKRc+MZ81chOxKg9946tEYwC
eYjf49mPi8SbvDCaUQavgQx0FFmk5lqTMC61lsVF6hJxWDYo8aRmK6ZNbFHFtdjuRktreMYZ7TkW
NMbKayOwOWNltkCy9ljjIsuWyKMNptIYRJjftxmTLLm+JYd5rYzEWwsO22FZqxWsHISTJbGH9TXv
RZTZjEGKPllY83wHp35klviHXdYY+4WA3iG3Gm8M3YM0jZgkrGNWbwFlbOR43wBkcrxxBRrD+SYb
ZTAlaPLPbK+fyzgJqWM/INg4LxduS2XMZGY6c7vQprJKPVkdtlPUiudvm+6dPnEz85tjF4rU2COD
4YjYfsxxQyCNKe5iitWJ3IDkYdhRlEkUDXSlC0U1E7sGw8N82zWXi9Wu2yqtey7vgVLGemBlvESF
PEccqaMbDynKSstUVCygjZOsFK+HPWO8c2OcVjZIxEluGWBaCI2TNGNsqY57q2z4K6WBW2M/m6NL
UJgWQDin2aIjpDlJWWzVw9iJGS5ikdXWKx3pYAc2zsUc4clRvhXAXhnWY2sKbuFqLAAxzJ8cw5fu
WvmrEIC2jFFaWSEa8iqtPajjDtpSSHL7rWyvGNPtByREX91VZ+OqXEF2GswNatk5JAbyOUTrQQn2
VhHljJ/d1/HXb0L1/PT59Ce3RfSv9BOvx6Uz4xPR89E9G2J89N+m3pXr+eu/T8r1X0Jip6Nsf0L7
ovy122RJ6hdLsmHHCsmxssLBZSwrHx8JaoUjbwbWpfAw1y0uJccRlkKQgLbsjkSPIfFskitlzlk4
q75vi5v7xZrgZ+oUTCXncQE5RkdqFVSTMdJXfZYtq8GfqR+SbV8lquxHrivV2fPoGZR427KxhpTj
5ywFmUGHsimTffAynhV1yZyPMr1aZWKy3ONCS3nzf3FPJHwlkUuK/wBxSFGrrmSqFM4io/BWRgoa
a82csFLIFSWZit7iuxpeKvnFeiu3xhFGqW0pqEnGMm64KecKLay9nySFxsh48+qykR085EQqoqTj
55RN3SXvxpHNxZp8UivXntg5pWI8735yxhnMxZZVxzt83xeqdF6b9GlVuNmFx0ojsaVyZ5ZceRXL
yxp3tzyi4sgi4ruWbdN9s33zjidEI9Ec9d998R+2d52KqriKqYhHYq5viPVMUrnZy3zlnNc575y2
RH4r985ZyXOWcs5bY1ypjnb4i5y3xXYuJvnumKufCb452Iu+cV2VVzffN8V2b9OS589EXN85b5vi
vzlirv0X1J0Ru+KB6Yrds2zsvXFE5OiDc7PHemKmyom+eM/HNc3r8/0l9e+Lnx0X5z5zbEauJHIq
OArMT5YJXY8Stz8tE5+eO/Hic3r8dFz59Hz6U9a9PjonXbpvjkxfbC4/Exg1dniOYjQOIrwPZghq
9z4rm42C9cWufjoBExIT34WOrMFEeVCgUSjjqXCRlZit68s+cAFSq+uc1hGcVVejlxM3zfF67ZGh
OOr6lzWvArHBApHNqXKh4aizb3jVylQtYokcNWrGiOMq1DuB4yiV3t13xeu+b+rf0Imcds3xV6w6
9x1fS7NkxHCcGO4rx027Zdb2s7S8odSpUkVHFhAKxYUFx1+i/tlwVCq+2b4jsXN836r1g1qyc+ht
2mwVC5Uzb0Kipm+2cs3xvutfXLIctIxGzK5RZGiuK8FC1WTqXg1QLzr6buoajTaXEdHWBXukq2jY
rLCpUKkTivRM39/z036fGbYqYmbb5tiJm+Iirjmq3p89Gt3Wur+676QLhZVKicCI4hIlSNo59MxW
EiuaWqq0VXVISZZ1yxVrq5xlZVBayzpeDSsUbt839G+fGb+2Lm3VG5tnxiYMTiY+O8fTfo1N8ra7
uKyJHclrUJkeE574teITZFYCQM0B4y1tZsixIxMtaxwlrq/uqKNHYyzp2uEYSjd/QXGpnFc49FTO
O2KnQUdxsLHeHFzbrtnBUxEyFCUqx4ghNk1oJUd0BwywK1GNWHEk5PqnAkV9Y1AKaCNx6sUqPLAs
YvTb339/UnXb1bY70L6FTo9NuhP7CfI28nVddulp2hipBte6xg+1VX+9k0YchMYQRniaRyDVkSKw
jLCr3yshIg7lnAta9iKeG0wpcftr0RPdEyrYvM0dqhmM+/4jnJ4ZMeJzMRMi1ayGyYvYxc/CZCB3
zR4yRWDlsO+fXplfXbYaYwKnjNksi1nIr+MRBObMbLrtjR4bY4vMY4k2Ciskj4vXqub+3T4z8DE4
ijrHqhat7cUKtUVc8iLUvRDRXiXbIFZ3xT4fYzbHYmQI/eMMDYog2rSnnw2vbXV6MbKnLHcxjZgR
1v8AIM7whxJ3lLYV27wRUjB+p/yJMRDhmg7blzb2xfRt0Ym60oW+KaX2C2hmnyPUkOn0B20mtcBF
b709a2Wy1gJHR3z0hC7hWRUjgbaL3yx2mjVlc1uT5Sx3Q3pME6uYsmTtDBXWLzksYSESJCQAZFk8
cho0lRrMKDIvq/GInuCM4zmUH7FpXOdLq/GSFTLIRdNZMp1jpx/dQRBSHXMNgkcnFekNvI0UCCin
mlbKRiSYsGGxS20hwcpjOOkuG3vSGeKCFLJ5c6K0oYcRoo0+UVpYrvKi3sZAm67dfz8Z85FjqZ8e
hY5hNNi2m1jozq2l7zU02FyWFF2WObxdQtG4t3HE0Cpm2JkZNywwtbEluP5EL78KFFZ5Vu5zEpHv
aSYBvclM7EaOU6SZQ0JDr47WxLFTPPXqpY18JAm9aZtkGIp3xaRjxv08FW2FS6O+uqGkxKGO/LGg
aJjmKx1A4aF1KEKI7qJnN1fUIRFoQOyfQIMdFHRFuXPYtJyV0mMnkWze0GC4iGmiaoYKo+DPqyPm
RF7Ma8VHTV6J6k674vTbr+XehOu3Venzjk9yp7E/vhtRxgsayNaE5GgSOD4zElCIFADtjqQ9R7xp
UX9xpajfVLuFVa9ey1jb9uzhOXKv7ka6TYit6JkGG474kNgGyP8AX7PdmBhiaLiHLaOxM+FrLAQA
2MlDEXrSf7Ng37MQHB8luwAInimCr5MJv2YzUQ9sxXErR9s0ln3Zjf44o/7yJvCmf5fz136b9Eyi
r0ex42tzsNIkmGxhxDGITpgHOs+09r/Z8O2bGbOneQvWn/253vHFGTkVv8SGn8eSBHmqkRoWJ/Ks
2cshx2jPOT3Km8bxf3MT+PZp9939D5yGid6tROzdo3jGVFLFVvZLYKx02SMzDf3QbJYmTJ/k473V
c+crP9g3vH7Ld2t/iwU3bNGj5FSzbHJ/LtWIrY7EQkpPttT+K8LXOhp/DuE+67+gmadF3n2B1iJX
J3Q20jaTCe18eQaQB0i1a8J/7ost8Zx55DovuufmD/sIm0NEY/I3+jCb92y4eTWtTunX79qmwwoN
Mk/68RN4L+HkV/8Ar6h/2F9a++JlXKaA3LvxnkmRnTLdhnU8wRhzRSmOJcKIchyPIBXtUkgz0d0T
IfuWKn8Hvs71d7xIjf5lq9GPr9nyJiL3LBd48YzXNJ+6JC/1TFY2VWf4tR/uNn56L0ROiLmndnkv
HqIY7Eo3lue+lRNZIHMrz8jWRo2SH9x42vdhCF26JkJN5MJrfDc2PyKaOwdere/bFQJK7i85/wDJ
cezIhGPjzE+zDH245b7syWuSVFthdmWvVfSno9vR8+pOm3v1+ejs99y/D/7q/wDzg94Nkn3wJu+q
GoxzP3jsA8C1H+GwmIJxUWQer9o8qcoDRJXkCvvdR/5Kf/XvP8rujPdaKO1QTZCpK91iFJ2pkaUh
huiouWKl32948F5kkR1Cq79aX2kz3fbAbuEOv2AL/GkG4SIK/YjuRD2rtlrzdwkv3dJ/fHEZe4T2
iz1+8uL1ROm2bY1N1odkDPs2xF+vte2TLfIWFMcrXRWnyxjuGrk2dBrHSklwuy5cTETKj2lSl5AA
R6le/wDjQ3Isea57ZFWuw2uTybX+2te55Zr0arnIsYxS+Q39sW027q5v0XNun4xMYvvSb+JeIqqx
FV0GSWM0bmScs6/ZHN45WVnlpPgJGxfZcTK1djc0fEQZVPy4xq8zeNsx6FquTGOK3ybPcoYQyKea
VrWsIj40thmyYy9qJbO5FX1J0TNLL+69TklS1Ww7gfOTEGeEsWeOWtrWNJhW8HUtck99vWpFRfbr
Dd2zBKkiIaKbyAv7UaDKb3reM8r6ZjhLJmMSTPTyAxIxGmlyUaCvlNfGmQDLJh/x4twVCkXrx9CJ
iJkSH5DhDkVqRZCTB2dUgyx60o2xLArlta4ZgmGo3UUccg91BGMa+3WO/gStkNNGl1b3nARIkWHY
s821grNbUgWJkyeNHvekuOCpcGTLlNCCsmsfGsK5xCxf4YLgyFMvo+fQnzptyIa7C4zQ1RVcemUO
CpCsFDmy2utYyTByGdotCwb330ISCdui4nzXrtJB+6vkwSvkfSXqKnmtAW1rnzh1g/BZIsmI+TtP
jQ698csywYmRXISFMglWwhr2od37y/z6FxP6Sejb0fnovTfFxcL8P91iLsSBOaSNZxeS1MfuHLKS
LHh2Pk5Zx+WVQ+0Owh9944DQjhqiNtnbko37ivn/ALoEfvOYVsMNnJ75OjPZaWQiMlR+RWERQyI7
Ulsh8EjsVuWzWI3lutWYfbtCtc9esOR2ShltltDFYN1hZozIFnjozDLIkNiDFaffbxmNYNkUc603
dBneSwcRjH2Vg0KHIryfn4zfpvm3VvzSzUakiMknGV4hJIUbJDIwyjDH7GWrx8CO/fV2bYrLGYh3
L841fYB+06tsWyU7IWOn2XHIVpwc1oj5KlNis+qO78WSyYxe1GbYWXdJBsuWdgWWNl2kOXuuf136
/npCHzNX7CDeMQmCegzxexJCyMwa2R2tGdUe6ts0iZPsElY73XoInB1VZo7OQWpY2WyQ7FwSDOKQ
OZOGBpJ73Fr7Bp2kOEST7FSOrbdWk7wnpZ2KNQxVeq+/p3zbp+aiWsZ7CsMgmo0Nw/hKr5wDD/jJ
k+cxjJD0c6BYLCfNsllI752zfEXKq0WMvmhVljaI9oJrglgWoZA508Y0NKVz6q59zTwcJ89TOg2K
xiBsgEFa2KYYquXPjpv6oMxYhg3kcwH2UVqWtp3XVV6NjFtIL8n2o+2cvNY8l8dxbIphu6fnfIE9
0Z472M8VhaKTGmVr4F8xjJtyJzHmcR9fa+M4l7Gck2c47okxwCA1BHcKfaoVCE5L6ET0w5SxyR9S
xu07UEPafZuNlVqFIrf1FBXJ12MgyvV7xHIFxpxTpi9Bv4LWXXj5+ooatl3TCs8he7A1I0Q5t0My
PLyfW3HiLI1CEuSJjiErLpIqfqOCuTLoT2nL3XbdUXovRfWmbejfquJ126fjHYuEXZH/AN7XbLDm
KF5bVhRxJ6RlsLRspIUvx1PcNM8V4wafXw4a9Y/BXPbWXK774lp47Zszylhz0jZKs1Ox3v0+MTIs
twF+v/tbdLyPY910e6UTV1Lkye+R07rs339G+yxpjgY69I5pjOK4Z1Y4d08bZM50hUeqZGtXx8Pb
FMnNVUMlwVdeme0p3Ge7ptm2fPo983wJlFjLuQ1H3Uh+OkK5Q2xgYuoJi4eYQ+L875v1ToIzhqto
ZWkKr8Qm2Dsjjwskhs3wUwgMfZHIiv3VhVYv1Q/F5nEVXY70fn0MXjjbA7UfNKROW+ClkDn1E+Ek
kfjlzfbN9/RtjHq3Ellx73LnLGHI3HmeTFXGGczPKIqKq5v7+URqOer8d0VM2xeqdNsqCC7pYIyY
MyRI9kZCk5KipIIiuM52OXFTN1xN16cVTG5yVFRX5zXFXPfOaonz0R7kxXZ85+5Mc5VRV6fOLm3R
cT0b7Kr85b5viLiuxcT0JnxiZyxXYmb+/LN85Y1dsV2I7fN83zf17ehF2znirnLOeb4ub4vp5Z3M
55yzfFf0T2xXdN9s5+7n4rvR+V+EX3/Pq2zbonRUz4xc+c/KYvVM/GO6ET2J/dg0V2eG5GtErnOi
PbgxK5VhubjIL3p9Pdi1rmYkF7sLGcJRRXGwsZwsEBxsJCeJHJ7r1jQ3yMNGUSghuMpobgYvsvzi
++L60xM36CiPI17FYu+b+jfN98iQHSEkVKhaRnFc36tTdfBdwezguJ036cum/VeiZ+F9s3zfE+YV
Y6Qj6XbJEftv67rn46L6tvWi4q5vi9Nt8475BgulPTT7UbOrFAogKR8Wk3FKqOLHi4ur6tTY+iTj
NiOA+FBdKeyhbxn07w5BpFI1KQW0mkRGR6tSFZRhaj6BhGz65YzuPv0RN8rqt0l0qiaEMOG4pwxl
AwsXvNsK5Y61tap3LRs42FWsd9VVeSqU0ZMPSDcOJT/y1owsxKUKrZ0rQjEDmWJTJwm0aIOrr2Ff
Y0bY4zM4vix++SJTiRv0yOrrSj4Nr61xCMphOHZUvbwjODkarlULmepPRvm/RMX0L6/x0TPz85+N
/wCl+V9H5679NsX079Px6d+u2Lnznx6U9sX526fHRfRt6N+ie3Vem3oVPfbCpuhE92/NVW9zLBog
jqWo886EjhV9d++cBg21CDOI6jE5e2QUGI1y2FUjkq4DUW8AgVrisYQ8ZsgUyH2l+OiJ70KtbljA
7i1tegUveDc8VxFSvJj47mqkdzsSE9VdDezHM2zbqKK4mfTibPiuZkSE4z41e1kexhq17me4oDn4
+ARmK1UwcR5cbWP2dCcLKGR++2GnYfFcVTR3Dzbboib5W1yke+vb4s6IrVZEcZG1pM+lkRCAVigg
PNj6sjUeJWKCKpl+lEwlYRidh3MdWR+LTkRDR3CxUxM3yOnM0GOjInmN7tgNDlLWPxKUqtNEeHI8
Eh1+hmchqx4UBXENj6orG/STK0oFE5U91xE3wda96CqSEU1OQaNjuc8VM96PoXsx0NyEWpfxDRlL
kmrcDARVkPZp4itXTxR4aIoHaaAijnyfFfYSmFFUC5TJbewLz2vFIbzlVwUbCLO8c1qRhs00Dnlk
d0NHWAzNCxFjTJEhJMNO5FNLZFkntXlWoUu145r8BRukY/TKpkuqdGytr3SXwIzIzLFP41GxvduU
IjKR5+7YCY/Gxkjx2WZPNkRmmitnfTnumllvgbjDYWHZlyr50hKYxHGuVTx6wKvmS27RhW3BYR+c
2YDvCsaVRYEropnXBZbYDZCHl7KGJDa0c2aVkiL/AC4V3FQJ6QTCmt68LBEbxd/T3xevzi+r5z4T
07+r5z49X4zfpvn4679UxcTF6r/Q39C/0E9KYuJ0Xrv03xPbN9/S9fdcJ/ab+6Ozm+uEnhX5HeRF
NwfBekkax2hbdyVcSi9mTI3JZJljLSk7jCOauDC1uXyZy4uo17or1qNVydEX3qpKsPEa045KoEZk
WVNi1jGjSIzLCvTaDGGVqxRAcSGwzLKP2nqnSKzuEgwxdn7Q1sAjeyueFjhORQ2hBbMVCyIQW9sk
NDCmwkYaDAYILpMVjpaCeOpGjJc0HeGOC0DLVzOTvnGfNVMCjXEb2baUJ2UxGOd4g0zYT1tYSDdW
sRGNjNIlvBaN1VAa0RJYAKQ8cwocFpZDYyDagUdl3CaxCJ+7bNsrBcpEZiJGuU7TokxGmGBhB9wf
ObCY9IsJgBFtAscoGSRV8VjXGCJcQAntvITQq9NlXGLxWkcyUM3bjonCQIUMTJb+IRtnses0o2Og
MbIA6QyMWTGZIitd4MkdyxEJcI5JJ0MWja1BXTW9sr/eh4ZJ28ewJxLCcjjQURQXfDO5u/T/AA43
G3aUi96s38Uih5J/gst1kVlbtkqWkYcMnmSTJ4Yf1BsSXYMlCqAsQCg+5LDzBCC5kuQ5iMAonvnN
c0kj/U7TM2/hyguNMgVyCbZWXaQ5lK6HFdIfFjJDHZWakyhK3vSFakezVqmpveVNKsccc7bBlzX+
OWtkjCWNNAVZzN2RE/ivRjj1n+rqFPvhK8Di2pyse7dfTv8A0tun4TNsX1fGfPoX+rt026bdN823
zbp8dN8Xpvi9N844qbYmbdE6b4ufj1p6Nuqenbptm2J03z4zfH4uP/tL/dF/y1n+ndpuVm+9IFzA
yf3ttQqj6D3bYS0BkxzpRaNvEdjKUBoEzvsv12Y/50/+0eocVcXETK4XdNXj7Ipo+8MAe1NeqMEt
mFrptqx7KJ/Ml07ZtT+6LfbdxyYqZGVWOrZ6ub4jDOnjMJQvckqIn8KxG5xaiHyMVWQ2xJDSjsk3
mon8Gd/n7p+NLy8pHJ27JFeKYFyOdi4mVbl8iR/pSxOVaxrmyZK/xfqCxz+UlgZBtihhTWmy9T2r
f9O4RUOPvJmnuXKdLSNi3zUydYukNf8AOJkZytJEcroNw9e7H9yxV/6+VKcKT9X77h/uiSkVZUH/
AFYn+SU9e9EduTUibtImLiZpfL5VQYrVwGNkkKWLO3YSM07J8cgXUX+rZJtMTdIiuY2aEsbYp43G
c5iu0wrlFqBy8Xr70bl8iduseWu5gqvdrd/DvVd3V+dLuXL9VawftJjf6c9X+XXqq17YDTSpxvDE
Vp5z6yO8Mqy/dFMN5DrBK1ke2MBsC7kHLIIvjUpe5Jvd+1QI9T2LmopH92M0Bu+96MiRYaELbS3R
U8M05ZEV0ddNgaXL4qiYR6rlMi+VO/1ZKKj6P/ZtUV0fT7VR90PvOkVRBpVCIw879oYJmvjzIxvL
hL48W9J3JFSBsg9rTsCB7ffpt12xf6q4mL1Xpv036J/UX1fPTbPjN+v4zb07dE6/PXbp8Yqe3RfQ
nRPjombehOv49O3RcdhML/dHds+rnNUFlF7qV8feQ4iRARLZDHsg821Au1llG7+R65rWwkaNb9fe
hdl+5NooO8SNtDFbze+qr0bmnYqKSxneKyusvKacaCMR/kBWo3fJgtYGheiGvXJ2qdyeJfuRxXdI
nuSNCa8QhOE6c1qjVyJJr5KEjPht3ERkeTK2lMh/ZSe37gJCFjvrEIQsAYg1YW9+afgCrleUy6Y1
iu+ekAvbLGOkiOeMNjIQmOlGRqishIMteXtnQzJQY7WRHWTUMODKTY9eOQ5YIgCiymBkmG2SjKwY
3W7RDx/zm2VgUKaNxYC5A3lXAR5g7IC4Ds8Tu2WvmIUDq4ZHvK0Aq6W1XWctrCVctqkvjI5pugk5
LRjYJts1pBSE2fUvGhFiBNg2tiNuisJlB/ryYjXrMltCCW/mXlnLBLydTNQQbhGPGduxKEI0yQRj
xWgmsfXDY8sNzWAvODnI3ctG0Ym2isIE7eBqqxY+O6GEikkNihrZ7XmMIUjBxwCyyMET48wcgTog
Uy0KMYyO3dRIzkSQN42ymxJnIUoSMHHy1sEdlfbpiGFllZ5STWIAvjmxvYA29Ub36cmsA69ltKir
70D2NUs0Lg26N7tVIQMjzAlR0gMdJVlvJiTI5wKsZiWtmm0KycAg54TCtLREQhHPyMd0d57xZLSO
3Xp8Z8+hPTt6tvX+fjN98T0fP9HbNsT+htm2bdV+M36rn4xcX0b4ubYv9Dbp+PTt6V9sT0J1dirj
sL8tXI8pRu+tMUQZ6MPOuWnSJK7Di3bSNjXgxsdfhXH6garQ3PB86f5KwrPxcmWXk5DmJHdLuVM1
zuWL1gWfiLKs1l5DsfEWXbrJyLedhv6k3yXarKSHP8TJdqsrI9u4DJctZLl982xi8ViXD42LqRdp
Nu+Xiu941g+Nj74jmeS7kO8eFr7chHSLUh0jWj4y/qYzckW75SRrN8TDWxJGAsHxVlz3ysd1a7ZY
1oSPhrkp8BPcBf1BIXJEpxl5e4LYsfCWpiZ9XPwHNeJ6Xx8NbmNiHcjw3hgo+9kOQslxcdm3QB1C
v1qRh5rzIKQ4K/W5GHmkkIm+R5rwYl7IbhLMpcZPeJTTHFwc4ocLNIZF982xPZQ2JhI61kOa8ivV
r1a4VpIHjrY7ka9xy1LO3HtzEZh5ZFxffFzbbEXbA2BhoSwMRHu3UMt4c+qn2NIcTGEVq/UTohZR
Ct5KmDmmZizzPRz1VwjvEqWJ0x84hMYdzF+oHxLIuElvJg5bxZ9SNhJDyZvgzuGqTjbOO5+Nlla3
zScXmV+ctsSW/HkV2DkEGiSi55b8eVXYhFbjjK7OW+CIrcbJJhCq9UXZWmemd52KTEIqZ3nYpnOT
liGXFe7N84dFTOOcMVqpm2bbdeK7bLnFVxROzg7FY7psrs4qiL026oNccNU9HziDVcUDkzbbGjc7
EjPXHBczNs7DlRQvTNvSwD3YoXt6INXL4xEzbEbvniEVHjVnRgHOQgXsRG754pFxY5Ezjtg4zn46
EVMUasxrc8UjkUSt6NA8mPE9qMbyzxXYkQi4+K8abY2O5+OjvZ0azlixSJjmq1em2NjuXHhcPPnG
t5YkUi54hNlTZWAc9FjExw3Mxrd1UDscxW/0Nsf74vw74L/djEVyshOVqCVXvhubiCVXJAeiMgOJ
i1Tkz6Y/ZILnYWE9mCiuepIbhYMKkUsF7Mc1Wrm3Tf35Y1c5Zyzlm/XfoEClc2oJseE4eNaqqCtc
XJFY4WEHssSE42OpXIho7hYESkcOpe5JNcosjVrjKlMuSKpzEDEc8jaZy46nVEkRVErkzbrGiOOp
ahwxijOIQVIuzqXJcJY6xYTjr9FXjJiOEu26w610hJdasfHIqK1OSxqd5GSK9RlDQq9n6fTclBsh
IbmmBSKRsqpUSdh3ONSOcn0FFyVVqHItJ3mza1Y2fHTfN+gQuK4FBySbTqHO3ssCnU7DUXBsiOoX
w4T5LvoSI00VYTotw5uOC6YyfUq1IdU86pp9mxKNqNfWv74NOpxWgY1J9UoFVNs36BEpVjUG7JlJ
wQonNJXVDj4WibxlwnBdCgulObp9nCxqHAyDXvkEZp0LUfQCywr3R3Lm+b5v0TBMUroFEhmStPog
pMVwX1tWspf0+zjZVjoyxIrjkj0LONhSqNpBqxesYCmfComcJlA1GEj9ktZU99H0LFZaVzoZa6Es
p4aJnbtKXsoMHMtdSIrJdCx441KqnHUgY0tIIjZdMoSw6YY2JVxlS1o+I4dYpygpxIO1okYjYbnG
r6ZjWnohFCyCoZgamMgvDibyaUDgyY3bk1VQj2lqAmS0grDLtm2bZDj94kWpGIc+oCUJhKIvQAVK
tbWNRv0wBcsKt0ctZUp2uMRuSKoUkP0x3kwa4ImSqgMgM+K6KVU26xQ919fVsEI1bHMOfE8WTTVf
fxsOLteVKAWqieU8dcGK2xpxmCwX8itq2tGSDFkMFSbS/EjwmB8GWlvRtGWDXgANh697rClHIDCr
VeYUMEZtjTDkR2wFWTX1o4zCV8WWhq1Yk+LHi+Gw9fzPXxzAlB42NXWIjfBiSyW8DwS0lZ5T/GiC
bqGoaNqM9uC4maf8d+ahrAjBxyph+S7xo0IIvAkttdPJygVrAhaSucSxpRGixK1ylDBjDSzpBGjn
E4ROm2bbehyLitx6exk/c3KeuWQsoAgDh8HTZcNhAxa1yyZIGCBUcCpM7YcG4ZWRI7HSJ9Yjm1ld
xJdRmjbCXgTsskhsYPac5Nl/HVOqLm+b4nRM07AQrCOYDLMTXMrgoeV2GxhEcM4pifyKqG1kVSs5
3PFuUMXuukcY+TGMMyJFaEEi0aIzBocDGjBINcsHlfJ8zLsKJjYLi59MJhYbxZFiqd9TXNEliNPH
pozXmnl8JIEryn2kJCZEgtjj+oDUs+Ej2Aio6VWx2DHqBqLisVz6mq5KKO1grZEHKZcMZFbfbka7
vAFAQkk8lIiCc2wCyvakqX/HDFsnlNPjo6NSE55cRFMkqG4Sr6NNgQhZRPDZJmDLH7aOlRwoOP5r
OVrwc6gjIo5crsFsyseymH3ZB/47XTRmHXBb27KY8BqwiyWTuEUsi6VqVco0olwjGiHWEkr+nS5J
qSR0oq9OMyX4aRCpOZIqmrMViQxRrTyDWVc0jIMBscMm0UROCTQueyCU9w4uVJCvS84PaCjfJR2m
HJkuqfGyHAdKd+mn5JrCRs0/EQ5bEiV4quwdLyxq2OeGKkaOyzd5kqOkqPVV7WZaTXRSQH+cO/iI
B7k60oVWRLH2oo7bZJi9+VUB2iSpxIcu3mMlN0xH/dcEJFG60aaPBEr5zx/xB2ihdWFYc2oBGVun
0kdy6J2WrbkK2I2T5B9lBAiNaG1mlGeC/wAqMGuY6bbE8UFRJI917FaNFvX8IjzGkMVEiGGpZ8EX
GDJnHr5lnMbYPiUIjNl6baxJAFAWijKpZw1WKK2dFd4XnnHpsGx9LtyBA8eVPZ48auMZh540eODs
+JLrC+VX/Zhw47CzbwrwZQFLmq46IJ2J8omVQFcdof4T5p6+TZm+pSKACsHecwGk2/mRqKMvK7G5
wRXRo+RhKewjB2gyZRYEusnJLNexllAqYBIi35UcAE2QZkaqJ30Xtw68DHNuO6siiRys8VnlXe4g
VTiMfqESJHFYSEbAjKaUJ6AryhUtrCDtCszmrrGfM+oD03H7bdQiJwbbLMDXUSPT9Pgdlhp1BD08
i858ZJKWunljN08RGLfx/LDSV5ALarxcFENCHWlbP/trq+M1xbghmSaTd+amjtE7Fzf0bZ84uPT2
N/cxN3afGix9QmXkAvB1WTyB+MxmXsnimnvd08HdWURYeUpUK5xG4wTcvk+1urV04XuMv2IiF+dv
Tv6UXFwbeTtPD4Ctx/tPKdvp8PIslnIEwqgJH+9LhDRse2TtPkSFPmnx7Mtx/bSU4Z4RO5GNXNcV
qduPZPc4tdBJIVVbEG83nygRBgD5MZVs2jKlTXNY1N2vlj5x65FGWWFDtiRmCyYu5D/6bYiOKqfx
JrlDJoZbzrep+yrjIc6BQTIyKrbwHJXIvKtrVIppKRg1hO62wB3T0w+06xL2CeQyQMEMTX2CfxqD
/NKIxuTa9sgU2N2Xr0T3XTg2olmNrgyidt9O1HyGjRQXH2ytd3S0jEaK6anExnKtAjcmNRRS39k1
GZXDlBG4kZiDbfPXesr1kOVzIgpMxZJ40VAgfciE88sBg0bURlgBClqRdpxf9qyZuOPFa18lv8cP
vFPFa8tciNjXabyKusyRJZEGE3my3D8MP18fclzRmFVgd3ws3yzhNUGmw8JVozuZAE1smwT90lP4
rQMVyJtFrk2ZOY1xqlERNTM/eTEz86dI1SyXbBtSffribHr9vG1AVm6k99NlR7blU7Mon76IrUMR
yJGtytcfTjXby5Iw5EKMj9QDc3IEhAkizo5kltVRQfaFI7bpdbt2Af79wqZBYxDX/wC4I4/eNXVz
Yo7W04ZBlJ5kVyKC+kNctfGU5YUVwxtYit1IBoj6clNaWWRGR7MiFPp8LVBeSyxSxdRETIklks9x
7MAo3pLTcEAKgjmuwjOPaXFq2dqRbua19ZxWXqj/AFne3WjkIw3c2i3MpsgoDqIlKfvA1JLaPOS7
6clZdHQQpRe5IqZKikhJyhXUppjadj9x1jP+mig2yWOalj8Ehn8V8TU6GWQPvxK1uwJx2tn1Sp3V
/wBq+cgWQntI3Ujf48IHkviwWwQXFnyWBMc2SA3OHqCcj5DH8H6ek91l9N8cNYiLPExEhcY+55MZ
BVSIku7MoR1BFlR7iP4MuJqdwWwb/wAvLRnPAs8aGLUXdPIH34FYnHLArBya9GrL1T/dn59G+Lsm
Lj/g39wv8lB/q6gbsrU/dQBc1hl3ZdR1R2nd0Wwk9jJ7/LyiYrFtDqF1bP72Xn+In92m981Gn7C/
K+/9PfBrsunTK4V4VWoVd30RnMky3cY096vLHeoy1xFJEvSqr1+dOmc5Lp6tYz9x4LUbFnTzMkQn
d2KWv78lBthjsJZJTqhijPO/1Dovd7525CvGxWRbgJiSC7R65zSHtiqBKqUQxZbE5lX+P5C97faH
ZL/I0z/dfb7RJniP/UYnpXzEOK9PtkJvfk9vsRrKY4pKEmwrR6iWmcq5euxJZBZUyDFkTXp41H7m
vlVrK5VfGvmIh3pnzjfnTT3dy3VUBK93QHKkkblWFbEVSIv7tNOVQXzl2c791A9zZFmvEEhVcaia
3x7kzmkonuIOxhpJkKJIY58xxnBjFa9F/hWSfeEM/HT5eIrXk0lOq4UzfJn/ALww3PceUREFFVHR
5riMkwP2xHw2y5c1/hDMQ051ZFeGRYbOjna5xRwzjSritSN5ysly15xaIqMl3SOIyqaXvWB2opXI
aJwKhu4jYtedrm2o3+TTNUQtRlQik+cTKHfybD/WlqvdCn3ahVSDf/5/nNLIqF1Hu0Bf7qprvII3
lAsN2m0rttqRjnM0yi875vcG+nI1lWIjDGXaLXSGkDYRCJLrm+PFBLYthcR3ShU8crD6hkNUNIzn
It/tRZBXPJCRXHhbpAvGObI0xsp7pHoKpX7Opmu79GJfJsG/xJI1YTTv+vqOMQxI1IU2Qh/TZE5E
mgr64wDzpTGsiKjok+GV0yt/ZAiT2MnXMFZjKiO6Fmo5bCtd874mVQlWS1i+JYtckgQ1etENWB1S
N/dT3fp8D+WoBqoHorSVoVecDdoFqN7Jel3fu1BGfIDSxiBW+4na/TbnhhVhQSFejIdTYty5qHFP
D/hi+qDSbaASyj1tc6Kl9YNeOhbsS59ohCc8rhKQ8Ru0PUIlSeJFeumhdpdUBc4VS9EnMVC1z687
5DqJ/Zov2n1AJxgUjOw3UP3SCriuyshqBsqwG83sWvBBK2ejuFdXWDPJuqd0osHaM2+lNlLyz56p
i5vjsXHrhvlnzRT2NbZRvKYGN/LD/GiJccjz2eQKmFxyzB32x6zZIuwjXzv2URN33S8gRh948ESR
GXlh3cd79Pn0bb5suJ8589Py1N806Ltjuh8myG8XUQNzSk5hshoMsQXcLXIiR7sO6vT92nxIxtuz
mxydo9dJR8c9YhisVsYEIzCPmg8hI9MxqnCOI/m2SD6S175sYYgnXYlIDm823jRSNiyJQ2ykhQ0j
LaTeCwbBDt8MfOwntEwbfMk1cNsfJ8VDtsI6BdHarjVjWiFdsR2V69uZKMnjTHfcq7HsYiMlte5k
RlpO8h0KrEdoYgoaWNh+2gKjVlx2yc5tjCt5PdM7omacE0bbHi4U4exKcKEMPj410JqOEPmWnRgR
3DGPYRvF+nwtyYrHisBo0tHORrDRRyVC1sVGS2OlmYw4xVkcb7FgRChSmnC+ujGWWMIhhn+PIGQU
ph5A47JNg7uV9i2SxeyPLK0yrttl+y7J05oG00xrnyRCOgo0YS2BRR1jSxyBLCj72RQMZU2LXikd
jkk5ijlE8WTBsByWFkCC2xsVI+ruEXO6BcsrPbK+zfHLHkDMyZMaBkuY47nriY35084bMkHG8Vsx
veriDbIjSBsBf8Hqn7X0hxDDZGEYUzbu0DmcvKH2rripqOw8QinBJH3hR8n2v3IFmI41dHXLOyaN
kOzcEobIJQ2lq1rfMd3aq4GQcuyGxs+a45KqWgJFtaCMAzuS1BWDMKzjoO+MM+V0x0SQK5jyAfVB
gJczASRUcwAFPbxSMtHMcWptliKy2iEQtvGEljP75ai77DjXUfhOnuM+pvWgb9WgOyZbAaMst3cr
NQC7dheDcOTIcRy9PzTThRX/AKiicLmUOQ6IVAkh6jhsFb3MWYNF2JT3MaK2VqSIVk57SGqZo4hW
6lh5dTAzMgTViFj6liuEXUEHjZWrpT6vUbI7F1NDyffNkDBMcI0TUwkDY3SGb3l51WoWRlmalCRJ
UhxnwZnivm6jHNC/5rZTYj26qh7XM8E5oHoItfqeMEE+/iyWNdxJV6iZExdUQyNn3jDMrrBIpP1T
FK2RqGO5j5fOTE1FEGKTqAJGklOeSt1AyPi6khZNvGHGOW5hYmphNDY3LSse7ku3T89F6P8AnH4f
5T2yMdWOHdsQSTW981+14gyuJXXbXCh3TQNXUA8fqIXFtz9yfaeSsKZ42TbfymxZKAJJu+4x71eq
/wBD89d8H+18S/WKKTqBZDXk5vg2XhY7U7nNlS1lPAfskTUbmtl3D5Sb7uiXaxENfvM0p+bo1k6P
jdSvRJF0Q2RbJ0Zf1QTF1GVUkWj5GR7kkZP1GTJVo+RiryWHYvh47URXYSe57xX5RtdqEzkNNcbB
SXje6+LwPLcZQyXBcmoD7LqEqpJmOkYIvbcO/ONprZ50ZIVjnWxiNI5VVrlTAWxAJIsyyG8/eNcG
jYa6OVCGcRQTHgX68duGuTFQj1di9EXbI9mSOn1w70NIUrgyXBcl5I2kzXnxHqjg25hIW2KRHv5O
jzix1ddSHIc7iYKQ4asuzNR9wd6Nmva9LoyYt2dcJaFKgpxA59ZNhbIpcUqqoZ5AYWxIZFfvgZLw
qtsZyPJyVH8VS1K1pJTyYGU4SpaHz6qdMLPeXBTyDz6odcJKeXByXCX6kbPPemEMpMDJeHFsCPRX
qqoXjjbAuz5CvXng5RBtJLc/HO9AjOEqziLhCq5UdxXyi46S9yOXfBncxFmPXHu54x6szySbOc5c
RcaVzc773Y5+695yZ3CLjjOXFdncxSb5y3xrts5rtz3z4zuOx3viZu5uc1VFX3TP3Yiu3VFxOWxO
aYirictleubquNG92cXpjl90XNldiuVuIiuztExWETFVd16sb79h+ORUxPdUA92OY4efOMG52Ojv
bi+yom+JGJhWq12NC96OGQfRg1djwkTF+Gt3xsUmzt+W/u0BH44D2ZvjBOfjoxWZ7pjU5L4r9iNV
vQcUhEeIg8+cExX46ORmKu2N5OVscitfyauNCR2PC9Mc5cY5caN7sc1zMb+7FAXHbp61XN8f/d8Y
7JHzg2quMgEexYzmv8B3Ht7P+nuVooTyZ9KfiVS54DuRYLhIGOpFNBcxox8nkr3o17OOLvnx6d8+
Ou/VMhw3Hx1O9ELHUSijqVR1D1bIgOEqMVXx6ohmnqXCaQez4cJx1WkdseG4ajjq9wah7myq5wM7
bldFq3HQ1Q5iFG5josN0h30R3GRDcJRhV7g0znNkVSgxR7LCrXyMLSq1pgKNYsZ5nNpXubKguAqD
VXgp3PbJqlFhBq3IVa4+OpF4yIyjdGiuO5lG/aZXODiMVXRqVSNk07hMIJWLCrHyXfQlRJUJwlAB
xniofaZWOFhGKzFxekCA+Vn0JEbKgOC8QFIQFBuybUOCnaVFhU6nQ1HwaeOolhQHSHJp9EZNrnAw
QXEdGoebJlR22vYrVr6hZDCUScZcV8d0KCSW9NPtRJlW4OMCryRKHmyXSdtDBUboFQsjCafajZkN
8d0OG6S4enGI2wqHBxoXOWFRdxkjT7WtPFUL6+oWVi6fZxn1yxXRYTpLw6dHxsqVQ4gVcSvoWlbI
0+zYkR4zV9E17PokZcm6f4MrqbynpRxUQ+n2PHNhOiu/OfORwqZ0KiYo5+n0awguJaun7+E0+N7b
GudFfXQXSniox9u1pPHaMKvJXUje1KoWqyNTq+QOoANj6QRMl0zhnjUwmD+kxnJaUXba9nF3x1gw
Vkvj6fYkeZX8ZkCoawaVsfazoU7cGAppAacSDtaJvbIJWkqahTrYUo2BisR00FUBI/ixNz04XDSu
V00NeIQroQ2trI3feGvCEQxAct9SoJIEJ0h8OkYgb+GkY9PW9/FjRQJ4QJeXdb4heg2clqqvuuHE
itHcUScIkBxSwq4MdkyoBKFJrnxzVdQjWeFENlvSuA+qqe+oocUTbajaQcWE4hodaOMM9bGlBl1p
I8itqUa3xoZcvKbsvq6pTYyNGCyzpRmBFrnPPBrhRhPr48sU2qJGkVlTxb2ob0vaLsEqqtTqKNFA
K1pAyYgK5zpEGuHHEsGLNZNq3xJFZT8ESPELl7SdstZVuOoo8YDLeiEePDguIWDAFHQlfElMta58
GREApH1dM1rNTQRiHU1ylVRRIgbd0dzfUnR2K3fHZIxEymr1lPIAcaPza+w8ZpIzatVkvisDFrFG
80lgxNC8T8GFjpMysa9kOs7Z7iI0ccLu0QDByRWdf28c3ZXdVXoidV9FfF8gsWE2KFDCK6yrEctb
VcUfICLJMNphR6j+QvCGxnCYyZU/diwmxhpJErrCvRW1tTshTiDhYzZQAVXOVxbDYAop6T6z98CA
2MJZg0LYQEI2sqm8imZFVzGTRJVK6SwDYgQSmHdaVnJa6tbHEs0bSTojTirav98kzYaN4zBnqVdL
ZFZEEGWw7rCu5ZXVvZwk1kch4jZgoVQiySqyK0RGzWSqjkYMNsQLJo3lsq5CjqapoWmmsjOeFs0F
rD7L3pt0hA8iREhNixhWLFJNgodlZUtGsmS2K5jWzgpUI6a9qQhRZrZi2lSjlg17Y4lsmjkSYbZA
66qa18qQkZAK2aM1SjpTmJDDEnIYlpVtK2BBbHESwQZiRkkir6hjTSz+K2GVJ7JdS1x+w2HHj2KF
PY1zSsrqtI7JNh45O02WCPUsSTKJ4bK+Yk5JtW15hgSGIdvylToLTsraxoGTbLw3jRk0AadqTJSp
EDW2HmJNgsQij7cXz5Pl8OcTzWwyksynfWq7s372Oc75xEyiArzyW9iOy39pad2XUh/hyZjo8i5l
MkN0sDd1mV8Zp7JsiPXiUk54u1F+sdp1V2zkummRlCply6egkfdq5lc0xCWJ2sAOq80rdLByXpvt
JGr3rIrIDYrN0eGc5B25G7wxRZ3lr/p18JuWksgzVb/Lj3UVsWXRTxdu2X+MVyhljvS9qJ3TyR/s
hQIzH5eClPcWvktyNKfDIS4NLyqhqzLuwTsU8sYTAM04dV+59LOb29R1xJS6fjvi5qhzHiz8wk3k
V8ZrYktx3TYe54UGGNsy9cUTaBxFdYRWKWeztxoBD+ZLC0satA1kSyeV86uVSxYkQaTr5XDFROKw
liBjiTBoKPDcdZhwtLDgBY2PcKZ0yq3LHDFZ5993Gioe8x9tHa4xm9uHG7qzHohYdeFrRXSGfKpU
XssisSw1ByGKi7gltgDcUo+MGH5Hkkaha6tC3tXHedMqNyCDGZ52oOQ2UqkZmp4qEZW1SBSGZrna
pZybVAb4lzClSZMmqMDF3339CZ8ZvjsTHe2SfluaVCiB1EVWDa9WOo5HdakZuXkngyj9yzY/dZKa
sNKiR3COejUGFqrc/wCE/wDdp8yuW7EnbkeznYqehc36ridNOInlWTPsRAuSRIanaAiePKCriwWb
R4zE71sPnlULtukNRxprP44I6oZ7P48ZPszI6lNXM4iCxEkW4u7lVG7BZTUVxv8AWWOvNreUWIzi
ywCpDVQuDOCd+1Zu2FG7RpLf2qn8QkTkUDP48Zmy2Qe6SpH2sen8qz9xRYvbkSGIgWbdmRG7xISb
R4bEQ1oJHkrA9px2/dmt3jijcDOT+PFT7MsCEPXJsHUCfdInv+aNNph/9dkROf8A/bRE4jnh7xKl
nFiN/k2Y+TYMdAy56btd/rLF+4Bv8eG391gFHlqQ9vHt3k2bUcyNH4yJXuJqfxixdyRPaJD/AMli
PmSoF2yGT+RPbuEMdrSl/wAIP9aQBCFr2bRY/wDsWg0etYFBlmN+7MYjo7IrWuVNwRv8EoDSHqkT
sjT+XajR7YQWjPbvVoY1swo2OERyojg2A1JKrK1AtsLBI7ZslTOdn5Z86cc3uTNuxZv+9XE/kQVT
xdRETfury02rVS44oKQTYlAVFMVyePcub39OteiSTNHkdzCrqBr1Ssru9ivZCFMsVOetjokWfekh
mHftOOucAsoo2PbHFwFaQkfLFuEH1COpJCbggJtFl8POqkRrNULsWhd9+y/0ZSbFhgUr6+AkcVha
qLKN38ewtARCx1DPZeV3YLUVXtOlsiCmzHSHDf8Auo1/h6oRfI06B3bsrQcF1bNHOXUoVa3PzB/2
Yaf9chmebX+0SF/6F2RBvr3N8mw/yWXsCEQb48j/AFYHtBJJH9Qrdkjxf9++Kg2wSDIayTZ9j+2N
AMx4nL/DgfuiyJLBWNZ8R/8A0NQF7DIRWldZO3dM9oMCWJ+N9q+D7hmSWCtKvZXMT+dqAiDyGYZ2
WX90pNoUCSJ79tq6v/wypLR2VWiKQO3m6iIgWQntOO9K0eR5kUsSK0PK7QeVmzIs3UiwZEciWAb6
K2JKxem/T8Y/o7JGN+dLr9vUjeSKmy6djvXN043cffKVfvzzdgUuV5aUglGW1Iow1Nj3Mt/8B/cm
nmqwl5+0Uj+92L0367ehOmnU2NOX7MU3I5/8Af8AXkyEGaAq+OD/AC2b+OV5eb5C/clLuAUrkdV/
jRV+zPN2S1rvtieiHtSozK+R3Xyn+5feL5C90a/xojk2sZCAJVv5Jz/kWf8AZBP3Sy3bNRd4xDbG
ju/jxXfutSdpah/PHOTvTl3DEOryyNuyJUWPKO5h4C8o8VU71w/tpVvV+F/vlr9gZ1cV/tHA5O3Y
G7BK1329QqnMvSndtLK7lHQ7lkNXaPGVFbZvUJapf2I9Ek2jt217nvNKcnFXfxXlc2RHciRYb03t
HKx1Q9cI9EPZfuHAI4hJSp2xvRY0krkPD/ZDiPTu3DnMWlc5XHenkTf3BjEe+RIciR4yo6NOc4Zq
1f4wHtSTbo5G1CucSWRO5J/dFB3HEe5Gx4b0cGwUjJVQitjCM3zbfdw6vkSRdmaoSkcjq3vmMjuM
WNXoUs+V4aPBInEkRngVc2xM09/t2HtFnKvejb9yq/0NRb9786U3Qmo1cgX786bfypH+nZuVJOl1
+3qXdE0xumWQmmc6MkKNLIaY9KcjXVqfxLwDnSh1BSM7pIRY1xKV1cR5Iksr/qMr/UjsJ5qqiQ6y
S1w7eCR0usb2QajKkg9JHK09kiuhzAkQ1AiOPat7Ecr1eWhX+JqMBCG06xQikiZKmzxrGA+LJnEm
0L4rQRCFdTCUcTU4CPkabciC1HGId+mAuA7VT28F+UyK/tmqpjJEOXUlWaAqRIsK0H59zAWY2oju
h5Ps2IQ7mz40KqLHkzpwxBqZ4zR7CleWaB6RI8W0F9Qu6/6nGqoawm2VszkpknRYdI+PMlTmRxVN
gwo7WoceUF6Qo8e2Glhaw0tA1de6E2ytR9xshs6LHpFjzJU9gAVFkMiW1OsqVGckELLhnn2kb6pH
qq18EVrbi5hkNmw4lKseXMnMigqbMRmXNI6VLivSAEFuPzLWJ9VjVMB8MGop7DMH+12nRORNSsVz
al6EhXUIxbCtXti1MvKXi9fjq7PjHfEj5b/dp+cgcms8wZY3GTXtSOAlxxNIRDirQcTzw9wUaq9x
jQBLh38emJtJs3p46ohC1wPHHe2SLj13VfR8Zv6vzXyfGLGmNmjDCaF9naNEyutUeMkNh3mkNhiD
cp3/AGmDENkRs+3RCwpqSxsgDYaxntjpCt05Ejsl4U7Yg0t/voRs0Yo44jbC2a1YdikgbIg+c+c0
A4Fv+8gBysc9kMb7fYwpKTRsjjj5Y2iItdaIVnijcWVMYBsW32kcWzWq9sNki2+9FmsljZFEFbC1
RiV1sjs8URXSZjYow3G0hismj+1GZNttnwrBsoaAGNZ9mg2QLb9zhDNkiS2Kyymd978/IDdl9VZJ
JGgAo6dPQKV1urScBSEkSGRmPuOJY0oc0XEQUsbP3rrVCJ2QLk6cgRxbbtm+3JYU7AMk2ju9Dmtm
C4jBljae1Xabo5onLOntAKJcds7CBljMYcdsq0Vx4VkyQxWhHllZccq7bZVQRMlzmxmCtnNkgmCl
teUQG2NoryVlm2QP7LUtLThlXbKLGFAVJs9gGMtHJIhzxSQlOILLSyUq1QBFRBhHlla9vKSY10cw
wGVgwCbqHtK53zjfnTqjTJMgbx3I2oWr4+RGO1gdQcC4zZp6MwgjtCjLHl7ITTzho58obg3iNUlF
ZeIvfFIb3ggwlonkecEzE7CLYTQoGpt2tc4scmS5YhMsJHeLWPRhwTwsHdSWK6BcMM15Y2Wdo1go
tm6OePaBMK1tWsb5HKTXyo3ZdaR9rp4DDq5KRS2VwIwSu+5U2/i59ShlQlnGY0FttO+swyolnCbl
xchICjmxwPHdQ25MsoRmgtkiSPrcFWuuorMtZ3kuXomVdm+GVmoYxA2lt31aZWkgahF2514JzDSe
6Wru/FcbU8VyT5zpToM90VwtTxnBs7jvoh3I+u1IMDZ1+J7DSVe6rt1h4TUkd2T5yySxZroxganj
uj2d130adeVZqJsVJupBlGWS57q24dDcbVEUjZlgskkaY4JY+qQtBY3XkNUy71eo2xUmamEVhZCv
JXW6w1PqqOds6wWSWLLULwarC0Fld+SxDqi1epEjZL1GMjDyHEcB+xK7U4ACmajjyh1914Ku1XCe
6VqQJklyXGd13xer8VcX4kpnwscyidGvEEw05Cm+vJ2PL++O9QYY1yMTl1GPHX4+K3X75tz32xZX
YfLu0MwJeBX3n2jGUqri9PjN/WnyuNVUyHZOjY/UykZJkKZwZKjUOoFEyXaOkYhdsiXDo+SL1To8
nJY05wHP1BuM8xxnDO5jg3zxNk2bpKK9ciW74qG1AQ7Xl7ix5ShX9QP4yJrzYwytUF08KSrUklFe
u8ayfGwt4UzXmV7gyXDey/I1smc4+dxUWPckC09sQ6OIqrFnPjq/UBHsNIUijMrHDvDDbJnOPiFX
eLbPBki5KTHlV+R5jwYt6R7DyXExhlaorsgmSbJ50e/fHLvnx0jSnAX62RWyJalxpOKguChSRYuP
ndyNYEBjrsr0JIUjhSVEqXJUQ01xV7i5GtyAYazcXHE3WPNeDH3JXI+QrsaVWuZbka08xxl5e4LE
oULZEKjyKuBmPC51yVUIdSK0uzm25BtNLeXO5gJ5AISzIVryb4KS4S/WDLhDqVeXFzLIw0JNeXFX
3BNJHV1oR7Xl5YCYSPiWxtiHUrgziAT6sZMW2O/CyHEx3yuIuBkPDn1M+FO4uI7ZWWBW4WU8uKvu
KWQeOnkdjn74MzmL5ZseRX4juOeYRueW/PIdv5ZM8smOkPXO6qK2S9uKZy45++NfjTvxTOXOa53C
45y7b+6OfjiLnLGZzXOauxGuz92Kjt+eNftnczub4mbERVftiOzjiv8AdFXFERcc16Y7F6JjFztv
XHNc3N8Yxz8UJkR3yxvLEjk2fui40T1R4SMQY1diRCpjo5UTZd2xyqniGTHNcmDRVXxTLj2K1cbG
K9HhKPGMUmJBLiwz4+MRiYIBCIUBGYq4j1TOe+MYpFdDKxrlVqriYKMR+FCRmfOMikfhBEFm/ujd
1bEIqK1zFYJ788M2FCVmcvT+ehOi+6SE98burgQXGwkVRq2te5phdpWQHPYKC56/SXri1K59Ncji
VpGI0Cq99c5re1+76a/gQDmYvt6fzv0+cX0hb3MBUEe2VVPBjmKjokB50JTua04FE6KBx1SmeuSo
ShVrN3AqXkSRVuEgILzvbRrsWmVqLEcjg0jyNWiXJdcoMVOOLm+b4FjiObTF7b4zkLHpXEb9DVMl
VjhKCMpnto3cZla6PnFUyHCcdZVS4LAAUxm6fdt+nVXD03aQFC4zf0+uLp72mQvHX4zfADU5AaeV
6fp3C6e7QzA7T4VUSW0lE5jJMZwlVM+ekKA+S/8AT+yTK9wMGJxHBoeQ5VQoWvYrFr6l0lCUXFsq
K6O6FBfJc3T+zZta8GNa5z4tDzZLpFY0wVG6tqnycJQ7Mlw3BWHDfIe3T6cZ9UoMYJXOiUHNkqi7
YyDUbq6rfJx1A3abBfHdDhvkvZp5nCfT9hOyqvhUPcZIoeLZAFE+uqVlY/TguM+sdFdEiukEBp1i
snUahagndyv0/wB0crTzOMqMoCIirlXR+TllTeGyLFU5Y9CJrLSEwGO33XrFAsh0KgZ252nthlAo
y1dP3sfp0b0s698MlfAdKeGhFwtaJY7QhUr4FGzjM0+nCFTOedtNHYi0gTZKpXCkRKQbGfSQLltS
dobkVq79NshQXSHh083xZVfxmwqZowsrQuW2okQcCscYoacfauNPIjHBVhKim762lKMcavFzmMqB
DH4kfebEjoOS1EJi++JkPbuxawR4t/BSLIr4DpL4tCxoL2IkSXTVffY8McCfTo8xLis8N6dEyCHv
liVQgDmVMeVHkR+xJpahFYtdFO68rfBJTQElubBjhZdUo3AhB7x4dSMIZNbHkgg0v8gniREGKJLb
PpmikiiR4ohSK6Q66pmdmnqFK5BxhDuqNpBQa0hTRoIojT1seYAEHwZzgxAxxS68j59eBYwI/dnV
9YyOFYkScOyguhSuK5wXK14xSAxY0mJqGMkeemJmmnAc+4rgoCsr3ySRoIYrDQo00FlXugnjpsSh
SNLBqKE1i1dUjYxJ1eCQavjzI1lEWHK6bejfH584vtkjNvepg+SQcEcUU4rHSoYRkiyKruSGRGCj
xiMWaVjGDEYTndtimJAa8X0nhLmxGtiv+3Lr3DkjtKvjhh8XdPnrt09sXPxt0/NABClcNkYcpGGE
QO8yDCQcdz2OW5YxrtPQke05GAW3YNR1IfImPC2OMpBSB1cJjUmzGxVh7S2SIwxGNYhjshT0lut4
7UF4zjvSmfhq0g8YFz301QjMLHa0I4qEsjtSOEE9DSLCIjhV9YgkfLYJ5ozZQpMPjKp4YmtuQN7F
OxEsJLkGIt0jFJcI90K0F2ZN+wRYJEkgvh/dbTmei0pWZDH4kn6uNBDuWkOVqOizA859fGQcbyWI
+64uV6e6ZED3jQYSRA/URtLNgocdbUta6VIbEazjNESoRZfBIoY0tsglpVoVK+vSMMtgwRZERJIo
NO1pJJ0iNjFbYCk07XSUEkQQJrTFtK1CDrK5oAmsmxylAksUSpb5EgqRGxT+eyZUNccUdIgQ2LSG
sICGHWVrQsk2SRSdlJYQVDfKkP8ABbCm+eljUtIUMRIoR2e8mdCbIFW1TBtnTvEcJEmAHUN8+TtC
DWz1m5eVreNTUq8kETBN1Em8Wkr29u0mviNmSjSFd1RfegHyOdnYB9Va9sxENLqgIkKRYujSLiSy
Q3S8b91qV0Vp7MciNWB7liZnajMtcrXDK++7zM088r8uyoDH3quHVskEJZyGMAGp8siaXCqS9M9p
kSueQ1dXsiM3R4DKn1eYxSRYsaWOSbh4lfFa1tnMIyRAcsqLfRmxpdHNF2rjbxK1v/YyGK+LMr5n
fMCUJa6r8zE01HyTpdmxYbwHraRDJFjeKDWLf5FBPEFwjNkx9UJ/M029PF1HVlll0/GfFTVrmvTb
FxM0/GV5pzF8VluWvMb+dNqwKODcvLXzLKzSyBpaIo81GNyx23z+FREUk0wt4a2BK01NLbIPewHT
G0MFYLtUH2FGlSpyV9U4J5ap2YYGpCnd98+B96HDAxlhqFxUZp9CNLq1qMA2xO9tPFcpJcpGRKeN
3J7B/wAQ0k9bJYBbeWCji8C6ejObbVbq6ZR7eFPpxWC2NY6DIrq1Tkr6oYGW3+rpUaKuouaDoWvY
7VwEUFXTc0gwRxn6k/a+sIha6woivnxEUETUbkdPxfR+cd0XbJS4nzpUW6Xq9sTnLzopXLGgaqXB
kCKqcrpZR9wMkPYbWTPIkOJwGNrCrYN+zN9j0Jd5FkNFiSm/vVPUq9fjN+jfddMg2yeL7cuUoFr0
78uO3+Lb/YKYyyX0YkaO5H+2TLc7NOgTlLZzBLMsctHIUjZURpnRBIBt2928SKWU+KBkQdlZd8kC
vYIBJAGOlNCQVbXMI7h28XdQ8HMnFZ3QghsESUv7A/68qPyfCTYFz9uRR2Lilt1VY1a7ty+6wo3V
4XrOp0G0nIT66A+YQTkhBExs+QkVBt7COy6gIJF5K+nq3IkyWgwx9j2Edn2Lr7JpUhSYvSo/3Nt4
joiOIP8A1orcsAIYtUHtY5n357N2QwduRLT9n/8AQLDaQ8VNo8ZE5WYEe+oD2lIz705n2gx+MiR+
4Qm7R5MVCEhN2jxERS2Y+TqoSCfIT7s5N44YjWmK3+MBv2ZkdCErm8YwG/yLNvcdWg4HmJ++Un8Z
I7UJt/Hhp/HlhQhatmwWJ/Ks28m14UGaxYj2gjMQQB/vtg8hVDO3HmK1HrXjlMua/wAYi4mN/u0y
9qrM4oK1cjD1pv5UNUWNqBzd+8vd025Fbcq3sSScXade1xTqnYtyo2VpxrslmYPIj2PzUTHq2tq1
K96shglWPlSq6M1sSbdkhSGXzTCqewaQfgTBs4imw0WY5ewJk+O8kxm4K/2jSODpdZt2tUp/K09/
mt/9dpuxMDqUHbHaxTPnV7JMajiNZHI393JGoaGOTNlvbXR62QsmNqz/ADA/y1H/AJ+p/wDeoAKg
LG3FXOrJY5+aoCoX9dOTUGaY/jHtpLTngH7JoJ0LF1NLbya7ZdNzEMK/k+MJ7t36el9uRIftGtpT
ZJ9NReSW1v8AS2VVj9RXVQNmV1h4T6/UPnPsI/IcRu1b5Yw2kBNosL9067MgUrSMNK1m7+JT1/lF
4DrgWdosh9DKUU5xV8a7meWfSacs1U9RCi28iK6ZaPslqPaCkx4rixijlBrobWQvNc+wvPaHpVM1
AZohwCtMe2Chy2CeFC07JdIJqH954IEDXytSmBYCVJUS+AkWwXNui9Nujvbo74k/CJmkl2bqFNwE
b+/T0Z3cG5Gsugd1lS3+UZ/CNNl99tRHcOROcrQVdnuWY7mGw/zULFbIsF/jTP8AK7Pzvm/Xb1J7
Lpk69y0erQTnq8teZRnjvV0a+K5xUdxdpsziC1CRzGld+7T0hUkzl2jTSK4+nht8e4mEjrUHfIFZ
RO+WPDbDHZz98jhepxonh2ntIaaTlfa+Lg7sRHMKjwOIj5kxe0GJYkJLO3cAP8U2T2iwV3Fd+5KH
dsq0/wBZznMIk6WNsGzOSTIRHxZId5kKG0Ma3mqmab+J0lAYtw3ezsFK2pB5E0jEjx7Ka4roZlbI
iOc+LfEd3Xri5+ar2mN2dFUzkOL2jxlTazeo3VROWK9vesV+zXFUpJTv2Iu4JBXDPFXaNGeiutlV
q1CqRSO2JYe4ob3ENKcjQhcix5LnNPA/bFjEb37fllS5XZKe1CS15AC4ikI9Ejxno4M1zmHrl4xg
Easm4VUFUvVTSiN5yF5gG4iyCORsaGRrxWDSMkVa9sCHb5dtu4dXzcS7OjW/Xu3lJaeYS4LwFUP3
i6hM9pqFVWPqdvu5OiZp3l5diqpFsH7kiovcqf8AQ1GrkMnvmkeW+pt+wVfek/2pafxLBVQ+lnJ2
dSo7bS/PLEPfe4PiBnFlzS/SCCWD/pXYCOlJSEI1hz1z4t1JV0IjnxDGf9QsfuRoQy+cZyePXSWv
DaQCrLr2+PF1EXyZNBFI0tu1XRVjP8p1AR4YEQ4pe6JDr3J2L3zFmCjSzDqNxSL8LzxqNVSLqoTu
7CilM6qYrYGpYxXS9POTxdTQiyjacG6OzVrke1V6JmngO7thv4cwajPDEpS1g1ZA1QBfMam7tLAV
jtUjeWMnzRAc6TIavgz2qKRpcqcdSwSS2acjPiuvWpIyVpd7WVNYeKewNwj09gyRGnUjiS+8OBHg
XI1s7et+piqon05upp7ZLdJt9tVewFVXZRx3OlcOUOxE4EnSxWpmpoJJMeDQOItpWfTj1CI6DIhE
+ryio0NeVCQPGeK0tG+TX0Fh4Uu0r0tA1sb6eE1kMxrVvkRKBFjvvw7vryIWusKsr7iH9qFqV6Fs
l67eh+2fj8yfhFyimeO45WzWT4ahPUBQIJ1wgTMIkqNHidqUZvKOKtRSdtoXWBEWNALxnGInhyF5
y6uJwZa2SDGYnJy/0Pn0JmmB7LYIjwz2dstWLuyo6Ike+D78eT6APaFdsQjJScX6cFyLJ2eCzFsW
glI1kuKkvIgmw2tkNfIkM7jB1SKWRCEFIklpQnrWGISGIIp6oj6tndPHa3xzq0MtzkOEFawRJspo
wQrVHufFGZ0iU2OOQfzJNVCaNZTWlHIhDGYcAZRBrRsLNkNZH587AB08S0ejjUcrsOkMZLaKsCJb
RrGpSPRJtiZjo8tU5VYu7IjOa2PfsbzJi5+QG7b6e0QrewPlNsEC2Hcfe4ilseccdki34mjTWTRo
0IMsbVEystebVGJVlz2gZGt9pDXDkscRkds61XuQpzZYlYEWWVpxSpteSfaekuagGx7btyxnHIG4
rANm2iuNBsmyWL2mZYWfbSrt9sR4CpNmNAMdu5kmPLHKY8owJZWrnurLRslu4EyyteKVdqo3NKEq
S5jY7PqislQ545YyHENLWz7yo7k6hKIbbEjHCq7BjMe0J8QrIrbqb3nu66bcNmSpIiAuGN7lRw70
aQxkfUXEmIqd2iKxg7UrCBnMRhtNuYjzSWKK6Rqk0/ZJFxTsMjTCjY62Ty/LGZvMLFsZYkDUWqNx
xhuyXOEIM+QhS1BWtKCwH27WU3uwrZhxqQDcs7ViDh2bo5o1mIwbW2bxHI3NAlgQT7KORtuYLMrL
xjhunRlyyuGIyquu0v1GK/DW4BjS2ck8dzHMFboQCXlgCWDT86OJG3UNuTbaEVsW4bDkfW4L8PeR
BpZzllOXonzR2keJhNRw3sujikHrJKRii1LEGy7tATWMdxfV6giR48/UEM4jrualtgwiP1XDey4k
glFr7J0R4tVRHMLqeKxZVm4p4WqBNG7U8NctbrymwrB8YotVx+zZ3Pl4wqtdXaoYFszUjTsOZSPq
7VIGXF+2eLfbKa2SA79YgVtvNZPdXz3xCj1cLtH1YBzbCesw1VqhsQT9YgVLG9WW2ru1grK1QGTg
NUdscyYh5NdqbxUmakYdiHVCwNVtjjkaka90nUg5IKu+dWqutI6rL1Gww5Be4vzi4nROm2ETN8cu
SffNsERWLX3ShSbYpKcG/wCwA0vvGjXfYGK64v8A1KzE1GPYl/zdJvUIMMjgR97uFC/e+vdsB5bj
udir6Pn0KuJ1TK638FCaoUiSZPkuhyPHI3UytSdarLxj+L42oVjNlX7jo9/NYNj4eO1K4jZUpx1i
y3R3M1EqNLfvc0Vi5j26kcjU1M7JF446RbV8Vf1Q7D3ZJGPdusWWsd6ajfwkWrpOAu3gz9RquSrN
58GdzFHeuEkmxU+DP23h1C8Y01GRuSbJTpGuCAz9Rvdku1edGSFa5LojRkkKVwyqxwNQFE12oCES
XMU6hkKFS27yDc9XZGkqBzNQERsqzdJx3uq9EXAyHBVL8nbkTnHVCLkW2eBJFo4qPKqrFsXx1W8I
TDHV7hSXDcy8I1h5zzZ3V3jWzwIa3cZHm5YCc8GOunvQ8hSuYdRuDclRsiwcXO4u8azfHwtuQyOJ
ycGa6MrrwioeUpVaZWqO3KJsmep05+8axfGQluQrSF3wMlw3/Vy8SSHFVC8VZbFG01i8+KTdQT3x
cfakK15VdnLI9gUDX25noyW5jvrMjclsUmFJzxem+RpjwY63O5ClUmMerVSzM1DTnFzl7jnFCj7E
r0c7lgTPEq2JtnnV+NfxVLAuLOIud9Vd5hm55pdlkuciHVF8wmPlPXFXfBuVuIciJ33LncVM7z8U
iqm7t2ue1XPdnPGOcq83Zy5KjH591VXdMbyXGtPjuSZxc7EYbdRkxyqmbpivzuZy3XtkXHJwxXdP
zg2udnjmTFxqY2IVWkG5nRgXEV0cjEcnuNivV0Q2Pa5MRF3bFK/HheLoKO8uPinHi+2NYr18E6oZ
ijVExkMr0KF4k+cGB5EdCO1NsENz1WDI2e1zVxsMz2lCUWfKgjvfhIZm4u+CY57vp5+JGPEqIq42
CZ+FjkEmAjuKhYR0xVVMY1XqsEyIVrhrv6E9D8VMVMke3Rqb5FgvLh4SgUda4rZEdRKCA8zG1zlc
yldn0d2ErnMV9S/bxlR61T+28XB7K1z2HjqNXp6F6p7euJEcdWUb1STXuCqBVXR6Z72yKlwkINWr
DrnSEdRuY2THUSxoqnelI7aXAUOIJVdFqHEaancxCjViw698jPob9pEVwcABxnjo1ckqtcDFGqrD
pnlSRSuGhgqNYUB8lVof2yYbgqILikFQKqSqpwMeJWrCqHHaamUbThVjocJ8l30D9sqAoMYBxHx6
JXNmVLhY8TmugVL5CFo1aw0Vw1h0rjNTT6JkmkUTYtY85GaewtGiJKhuC5U6jRXLCo+8yXSKNCDV
joNW+Vj9PcWyobwLHA6Q8VB9ubVujojV5Q6RTNkUasQFYUxx6dYqEoGNSTWkY+Lp7m39PiydTdpI
0FxyC06zjPqXBRAuc+Fp/uNk0PBo4DnSBabBx/TwOUvT4xjKFWngUnfabT7OMyIsd9dWvlOTTwuN
lWOjZ8Zv7b5DhPkPBp4bUn0Xab4y9yBQoVsnTrHMdAUUqNp4RRWld4ub5vldXulvJp5jI8oPaL02
yLGU74dANo52nU4kjKMtXSIdDafE5tjXLEJW1qynjoxcLWj7GAApSwKNnbnaeR44FG9TpVRxISkC
VJFMopMWjYJiVsciW9AoWvTi7N9823yvrnSXsoGsilrf50SoYIKV4XJbUHEdfWqZ4akaDuKHZnZX
nTUaly2p2jBUBQsn6SMY/HBk6OJ7KunaueMEeFpwyh1dS1s08SOBoYsY2aiqhBjuTbOW2J+7KysU
7o0EIW2tGOQOXHdGIvt0ELuOqKZNvDibXtFwWsq3FcCICOOxpBSQpWP79bVMjsWHGlNtKV8c9RUY
0MVuX1EiMrat5yAiAiMnVgZsb6SRkmuqxxmpHhycuqUsc1NS75/FGy+0+wjKyrecgYseIyVXAs4z
qsg5dbVCii/jSFuaZwSU9RuiOiDS9o2nDX1TykCAEMZYMewikqiBmV9YyMMTIko9zRujmpafljlj
jbf0LCBqKh5yDjgh5IgAs4bqt45cKsHDE1sWWW4pXAPS1Hsj4yN1JRNKx7OD83xc267Y9ejsk/GV
kTyDxa1kcF0YfcqBsIGxq1eSDBaITisbO7bOyKQNzyNG4iQmvDIqeMpYjUiz28ZtYQZWWdYjkki4
OXoqf0gM7hausQIlljG6bCaccGo5EfwiNY0c0RqnlKjw2RBpIYZ1lV7pWVSCa+UIL5UNJQYVQjiv
cyG1ijlsk1O8oENsQDZA3usq7dtbVIPCSRhU8ZsoUapR0hyMisGRsps6r5GjQWxQtljcS1ru4yrq
2sQ0hgXOC2WAdRzmKxsNgijmZY1W5IUBsQaSx850BCMrKlrcMdoM7TZgvo6PlqJsMcc7JS2FejXD
mMEJLdHHcJCxxEZFfJtmjWsMk1l9GRqlbsq585Sh7svsoITpTHNnjR0mpiNbGeZjCXXByaaiI9Tu
bHyc5hgwwISwQKCCspj0rwNUlifxkrD+StgNgHPseI4ln3jzI6Ej19YwLSzEAV4GyhR6hnkmd4rI
pmzW2EZIRVuWNHFt+7IkbdgwudjGjoOOs5u9urSP05G3DKk9h9oVhBgoySnfpU2xqZ0daSvawEuZ
4rgNSaFKhPMPtDFXzfNW5go1tG5Sxrqq8hsuA+K6vr1lPq4LI7JiIsa3bxkL0TNPg5yZbOwFLBrm
y296ZVxkZCPM8Y12dsjNLRVfliZ0RJloM4KoCvsJA+1FHbJyruBsvFkI7Tylfl0VgnGvFUdUpyOt
pDWgFRJOJ+koyZM0r22Q615D1kFsRr1RwXK1LaxbzjQQTRyZStdGr4jWhspxRnhr5US3E2HYU8tn
bu0Txadv/ZTmq+MarsEe5JMd9K9r4NxAlPlVjHCiXk9Yc09uSW3Toysffr3gV+n2vRdPxVyy072W
UcVrYt4U3k0znFBq2M0J8/NOxHS+w0MJhJL53HvQayM1FvyF79Cr3tWINZl0nZDSLIY+zjNXBCay
EVsl1gH7sCtA3vag7nLTqPTDhZ5F4ijFTodpbQLXoAaNgGbILPjfcra0TEl6g7qrptjmLIjtce8Y
rQU7DjLNE1zIo2sr5Yjms4n766CBnmaiQm2mxvGSUJqnuW7BqmFaSeJvCIJrK6SEprSMncrYAm+Z
qPuEzTwnjJIA3vX27RUzCMWwGxyRmolY+MR9qH7tZqFrW2/rf747FyTn50uz7tp9qPLVVPRS1Rww
NKlk/sBCRxbQSbxZMZB5GnK6YEnECKwrpTOIrVNpFUR3mGZvDsl2M7p85v8A0apP5rGp4h4iuPHZ
/GiIm9mNxHVA+3jhp5Fin2ogFZJOn2mpsCXHV5YibBjs4usx9x1SPg4zOMian2AAVsgrdwCb9mZH
7r68fEIGJ3bQXcWsEoiHYjiSE+w0HE6t5AAz7c6N3H1reIWNRDWTOaVwe0SWzdxW/YWLsdqbxo6c
WTwdx1SzgJG/fs28210ftSLRv2mN5SokMCY79oLNXeTBjDK2GNoW6gdhvlffET302JvMjE7FmZQk
i/fk17G9i9REU51JlAJEHaMaoJR1Y+jajpD2J4tm7slojuK+UNhMjMRi6gX7UB3IsQI0dK37Ub/B
Ijo4sBuwAt+9Ys5LWiQZL9NwOa4r6qu7CTpyDDXK0sobUSNcu4FQndkUjUUN4iduIRTyEjoAa2QW
vlHGUVY3+LMjo8tUzgIafyLQaOyBHRki7TeNp7/CeS1C2VY2SOmr2CY4TUeZm8e+jcCr0YvvplW8
pm3btS8T1hUWVDVFj6hc3fvbl065O1cuTsyjKj9OERz5Kp2Lcmx9Ob8JRGsWG9jl1KJ21VXc8K9k
MUiwWZMgR0HGn3joh2Xw5AKnsEMTg/GM4glRUdPc7tBHOjmfNYvag+0MvbdIr/8AW1Qn8vTDlce9
/wBaMfxpTNSR3NBZxjksq0ZwU8dQx5VmCO6MRsqPqQSjkVNYshXqOAJlis2exjRg+FkHEo6xqePO
IjbGq+NYN2Njcpf9s/8AoxjD7g/aHX/FiRBz6lUVzv8AcvXINkIzCssvhE2gR5TFkxvavr/Ylwdg
JVQ5CzS/7N69Bhr5LJAZ/wDaJu8CPLZ5cRNq6uT+RcyWRjVRWlmH9j3j+Aq+UyRFm/4wp/1Y7Fjb
CL/oVv8AvX0lsZ9ORppMlPuXr+DayW2RFm/2BT/qQzmJZRP9CB/tXUlI5KkyGnSf8t6vbZVymyIM
3ZUAn/VBnCS1D7VuoV5W/o26vzfpK6aWd960948tqoSjjuKaMvaHaj7owi4WA3bRpc1XLBjObLIv
GPFse3KKTuR7ld5NUxfJX/TtP87sXp8+nbNuiZW/7YX7xSyuB4z/AOPGciLZk7S1ROalX785324s
jmeS77Il5Blm4Eif4I67Os39tKt6ucZfvSl+yEyvOT/CB32Jx+2aD7iCuxLZ/BKwvdQyojzr9hpV
8rfYEdycbQygdXLyGxfvWS7JXE7jpKpuX3D3F8hnsCOuWROD6x24+Sdye77dcRSPs3IoDie0sacd
rwrzh2YV7rJMiO6ikukCv2pxMn7tvdM0+ZUmyFVI1o5XFCRWlqXq+HqIi7qv7tKmVcuCcAyn7kpy
PSS538S2IvkaZbyHcnUGUUp0jL4fNrophEq55nSiNRQhVO3Ne4ciEuwQETyLbfhVqrn3707VLH7x
5jfHDYSlI6rIvlCVVi3RF7vL306RyxdQuVEpvaZL/wBaexzzhjS1SoInh2ivHIqd2x2Gakq13eKs
5OLdFa4ND/gtvaYic4RbLwixL1ClK/8AjXkjmV+bY1M02q+VYL/GnP3PE379f/paic7u/OaTVeGp
N+y5V5UHLzJvtGn79/TLU8TU7X5phqoywAkkpQJDjyTSJ5A1BAviqnh3ISvkNpFeMUwtYSPeSSvi
vcSH3XfU7NvOPVhI2ZMVEjwDNeCyhF8yJ9iJqEnkydPRSCLdscSM2G9Tk069g6uIdkkzto9eqOjX
8UxJ1Q3tQtWfuNpgaeNqkijylf8Ayz/uhOjz1O+uKwVFPa4F3VPlHrk8GPqeWkgi9Kw3ZPHltmRE
o3jnklNjx6izG517TOnHrRfThPthJNsRJaRqusWHlraDGkGayTFdQuZNJLZCi1VwJ5rirWwWsF9N
FIuBeVNalrErqrwXW1sIWVdgyTHJQKOYWUyHEq7oayrqo+o5Xh+mBk3YvIPxtYlfTeAW2uRiypsW
SopqBHTDSm18SsuxLOuKlLRteFKwEq6H5J3MtokCnSvJa3QgJTWjJUU1F/JlSWV0esvBvlW1R9Tb
BZ9OFIvROlSHstolfU/Ty2l2MWVFiyREJQtSVNlMrotkZJMjqnX2x/x8KuSM/NPK8YjJTZgLaL2n
0UdBjsbVIzospJIDRk8safxvpqPM4DAq8iLEcVPqISp4dq5Fk00LZLKybFDJP3ir0X3xP6H5jk7Z
Ku0aUaw2vfKmtihi2/3lRsxrEbCZKukQ0aUksYYrArZWaCSvtkeixGFJKlNjDj3O5v2zRtRkRsu1
+7FntlDZHYNbCzQSQLXlixmHU8psVjbj7zHtmDaJkZsy04vgz2yWNjDY+wnoFsC12c8TJKEkNiid
b7HCdkwbWjipPteL4Fmhm9kaOnWKBbCufuuEOVhDsitNcbGjyGzBtCOLlhYJkMLJIvpAEI4zQgE9
kg5awLsiMFEbeyUchPdy9NPgYj3va+PcDRCwhdyVXOYwF+1r0VPu6fYwTLJGODMZsSgC1ScmOBcs
b3NPzEGp2CkNjCFEWwmt5jAEgxwYwiT5bWCg2qI5ey/JMtoGDtuEoR2SmEIwGW9j3V0+dGFtpDFD
IdyfSsYhxGH2NRI3lEYimqCCGG64EYM3jyY81hg+NHVZ3bYKutUGTvBIkiY0DPq6+VEmsktIYQ22
1n3c05MZ2DKFXTJ7BBsJHdLQuGhFlj7N61vJ3Rq++nCNHkmSNw7lre7TqxJAJTGg1BxI0SbGpDsY
K1OwgZiI0umntw0prhXSN7unbRAYsoZs77AIlo1Z75LC43ttWyljYKqtmua4giZNmCEKxKhZFGRE
kCnDQdnKaw8K1bIEpAsy1t29uBbuCYNmN4re5aiCk8pESWNrSWAXpbSR8q66GUPlgy2uGoylue21
bGI/JNuEQrOWsp9DbjjAv7BkskcrgkrdQMcJ1rDYllfNUMWc6LIi6gjvDbXiEGUnJfyqe7PbKu5W
Iq6liOZaW6yXRZjgkh6mCorO/QjFOqvp9QpHSVqIDmy5SyCV1o6IR+qI3C1tvNcCQ4ToOqBsDYag
Qw1Mqvqr/wALJGqREbKmKd0GwdFeurAOFZWz5Tgn7b4Oq2AHY6i8obzKrqq+WvWRqphmyZTpD4dg
6I9NXjcCztnTHDMo3wdU+MKw1F5Qu4vKqvXV7j6saVJUtxnw574rv1g1wrK0dNcM3B1fq4kUU7Uj
prFJu+rvXV6ytVtM2TIUroVg+I5dXo8FjavmvcuLie/p9sfi474kf2r8sdssG3WIk+3ZNSHdpGbO
nLKfCufFb9a5v/UzUz9SNXDXvdc6/wDtd5VkfXlYEhu4UN344pc58p7l6L0Xrtm2LidUXI8l4VZq
FzGyLB8lVKqLFvHxklXb5COKu8SzfHwuonkQ0xTODJcNwtRKNJVoSTndXeLdPjZJvHHRxlcsae6M
q6he5kiY4yjO5jg37hJJs3GTurvGuHxsNeqdCmVyx5zgO/UL1bJmuMrDK1wL14Ek2rjI4u6xbZ8b
DXalQx1IoJbgObfv4ypqmxp1Yse7eJJFq4yONvkW1fHx968jSyHPdHtnRs/Uy4W5UzRT3DczULmt
JqFzkkTFOrnb4ufGRLF0ZU1ETjKl+RgjqFwb97Wyrd0hFf7xbkkZH37zIYykdFnPjKmoycZc1ZGC
O8TxX5GMW9c7JUtxnRbokfP1E9ck2TzJ3tlFdvayVYPOiF94lq+NhLghkebnkeSoHmtiHa5++R5L
o6pqEqZLnukI0nF0e7KJp7ohmuNusWyIDE1AVMkWZD4rsDclEwli8yKTdY9i8CFtylx5VdkSxJFz
6+TJFkQ+OfvgZbo7kvJG0iW4yuXfomRpr4+fWDqhZClcIyjd9Wk4eaQ+b4OwMFrrOQ9HP3UEh4MW
zOqPO5+DM5ipZSW59QO5EkP5LPMmfUzY+aR+NO5F8wyYSU9ycuWMI5ipKLjpDn40j8cc+zirnJc5
kwhlVE+WdxEcYmOMrsa5c3euKRUxHLmzkVznJi++IMhEcx7M3xiOfnaM3FcuN98WOXYnJuL1bghu
djo5G4u6Ym7sSLIc17Xj6DjmKj45xou+CY56ugSGITkzGJyxIRnNKJ4c29xxSEwkUwsXBBcTHVx2
Nfu1WN3X6fIehY5QJ84CGUqEgHFnwoRKRVrJDWlRzMaiqraw5GGjFD0HCMbCV5xp8KILjYtbIRCM
INzGKqtrTOQwCBxPfAwSFw0A4kX3wFcQqfST5IiEB0+ei+knRckf2r7435hQnHyVXLHbFrVkNkwX
AyJAdIT6arHso1dn0ZcLUuZi1C8SxFC4dQ8jDxVE6PWqVsiC4WObi9fz139UWO4zhUiubKrVDijc
r4lQ8zTUzhNMBzFhV75C/QlRsqEocCBxXio3qkuqeFVEu8KoeZpqVRtOFwlhwHyVSkVEmQXCwUdx
HBpHOZLqVBijcjoNS4yFonNaeK4SxILpD/oW6Sq1wMYFXvj0Tnjl1DgtIFzVg1DpCGoeDZEVROhw
3yXpQ/tl1jhKgVe+LQOeyTTqFCiUawKp8rCUKtZKjOCsOI6Q9NPftm1igxBOesOhcQcmkUSHCo1V
OsSK6U8enURs2pUOdtecOic9sqj4tkAUbq2qfLx2nmtbNgvjuiRXyHj0+nCfUODnadyhUPeGeh4M
khcHK6odLz9Pt2mQXx3RIbpRG6dY1k6mcJiCVSQaBCsk0KNbIiuCSup3y8dp4aMn1jgLFhkkvBp4
aMsKTsogHc4NApWn0+xGS4bgPixnyHh063tWMTxiQobpbg6dDxsKPtt8de7W0HNkiga5syE6MSqp
3TM/T4ONnUrFyHDWUWJQBa2yoFY0wnCXo1FXKqodJxKAKjtqVwHQ4D5BItAFjLHTiKxYrkLVUacT
UASJZ1roJqqrWQqUoFS5pFAsGE+S+JTDYOx06jhuhvaeqpEehqIBWWtW+EWpqe+raYfG5oe1kSue
UkKnGIdhQMeEkN7D09Lyx9KN6XFOSMarq1Mo6sTR3dAnGJAcY0GoYIc2gGYM2G+KWpqXyH/Q2JGs
AdqRVVCmcKuC1lzQo5kSuIQ1dVDAOXTAkCl1RI8mopuKJXxzZfUbgrU06mUUIAR21GMoZAXRydAB
UrqakaieLEfl9Q9vKenUzhR48dltSMkxY9YV0iBXDijdCiyx2dOWLLpqVqNcOK5dQ0WU1Q8zmR40
ZljTgnwxVT0lQq0MZjQxZrbakJGkU9Nxb/EXNRUDX5T1LjOaIERk2rFYRBVBPNhQBw2NHFlrc0T4
simpkGxSxkzUNH3h1NO8j29iA2XABZQ2VBPOhQWQgsbHnOu6N8UtRU8B96PmoKRCsp6d5XJ2IjZl
eGzggpXtmRYY4Q2JHsMn0PhzYCAjRR30M8mdWjnwZgvHlerlj/dVbjvmQnsvzBB3z19Y2ODUEgSM
0/wcGyru8lZXIBtg9g5AGMcF0gbCncwiR4rSCsqhHPjQ2oC+ajD00ka5OrUKObG7T1TF9adF6MTd
9NUtax0kQFPGbKFGp+UlWMijG5ktJ9TyJDgMih8sbn2Nej2VtSiYU4wY8DZgh1G8rgyIMZhycn1S
K+HAbGF5bN51e0jK2pa1TGZGXtslh+jcpaibDYE7JWWVZyWvrmxR+WxHzoSHHV06NcYrQY1jZo31
HKZ47YggSWSFsqtHZArGxhPksY+TCbIFXVCKUpEj4xGzRmpkfKbGbEEKQwzrSpRyVtY2OIkpo3SY
bZIoNO1DFckfAcJjbqAgnEbsq4FnN1RWtCB0xgHHjNkgh0yeQdyRWge2aybTI84IqRRMlteSwrkK
2vqmRmllNA58ZskMemTyDuSMyKZJbZlO15hRUjCbNa4thXIZlbVtAw8xsZ7hJKCOnZ5RtojYh2zE
n1DSvBESOIc5qlnV7TirapgUlyUjKg0lhHUM8ou0UcOUkvLuubwoABYjRp2tRs/kUNe1oZUtIeC2
mCbUs8syJDFBmJKyxrWEUENAhbZfyZcNsgNdVtYs+X4eR1bLDqGAgnqm3SuH3pESEgI62bmyDR2y
Y8CraJZ8hYuQneWwlWxZkljYgK2wWS+0r2FZHhtAElm5st4Ukxa6saJ9pJWIlaTyxlrGLNksSLFr
LAhyWUFp2Q4bQR5NgVktrEkRINc1prY7ozKYrpI5dc18iSxIsevmldKsYzTCgRGhBLllSTHTyoMO
tZ5VydQJRleVuqIrUHpqcNo3ORwbBu9rWR2jh2Uk/kwN5MGNXM865O6MKgeR2WMRj3mGgosUx/Mm
AQkWtitFHuHndMq3KaLrCK0M1Uzb3oxo+VKGgYsd0hZ5hoWHVx2sj3qldIqOT4o4jPqV85ww0KGG
63jte57EFBF5BLFWIWDWR2iZedx8uj34eOz6hqDdAUQyx3WoWq/gjYLBnfYNRCQK4LWrqEZSyaFr
kZ2WrN1AqtDSiKF1oJqrxRtYMB32A05V1YJvc1AMhj0AlFjhtSXqJHdiiivjLajarmtRsIEQz54/
eurRtV1/GLJPRDcNnaa2TqJrnCpY74zdUoiRK5CyMi6ceKSQiRa6zehJ2fnfqvRffFxUyR8OzTqb
zjJtCs1V56ST2zxmtKKb9gMsrizq5OUWVH91mq2XCftG5tI57eIr/wDzRCK2SH90W7bsd6f1I/8A
nrtvCmAV5q9vEIWp3bJiuyrEo3yBo4klv2Bx9pKt3jx27DsI/ddWs2ExiIWzH3Erh8CyGorip/H8
bYyNRY4GIiWEfuGrR8Bo371mzk2uD2iyWY7/AAFDuUabx4zUTJ4eZKtvBOKd6xbyZDj9s8hvJFT7
JYu5AJsGOxG5YB5Oqh9vFRO9OHuOODtypHuxrfsyY/Ikdv2IrUQliLm6rH21vWbikt/dkJP5MNP4
0uN3HxG/ZA37lgLuLVi7akb++U37IwbHe1FCFE7M0HJ8BP44k+5ZjR+VgkEQyfvlN+02Psdzd44m
7CmAR5IDfsjb92xEj0rQ9oh0/fJbuFAbFVN48ZPtTA8yVrNgjb96yb+2ABGmuk+xFkujmhkV8W9T
nJpm7QpwUIepYjRNb/Ism8kgARppScsIm0dQpyan2IiJwmiRxKwew9TJvj/lMpU/mOT+J228xt/j
xE/bORHGp2psqfyrNEUcUTWnnbcf/wC2VjFID/Xip72LWqar2THf7Np/iiMZ3Jv9u38XixSR/aNF
T99rxWRVoiPKn37NPsRUHym/4wJ/H+240JP4kT/YtEb3atG9/VSfxKh38oX+pOX/ALmD/wCcR7Fk
1/7Y0X/cuFbvVoxZUxPef+yPGINzSr9iJ/qnMxJ9Z/g1k7+R8Y350/8A7M3/AF40kZMVf4kD/XlH
GyxrFTti/wDQvyNYKARpTWPssn2hQZTHERU8CvT7c+WwFlUKj3p7ztQm7DIB2SMsv7i/+fCntccS
f9fXJ7WstsewqX9wv/8AeajJ2B1stsoVn7uX3roFgx8sCf8AW1v99tLbGn1JEMb/APudRk7QayWy
SK2/vc3+BX2LHyRJ/wBdXZbT2w7CsIhSf/3OoTIAFZKZMjarXeHGKWItZqSVIkmG2TWTdmyl6Knp
cnt//JfmQmfOafdxnlXeBZsXyKqM4h4Te0KezvClx1FLr/2RrCcrSCjOLJjp/GdYqCaI3dBqBv3o
g1dJjf6t89PJevXb26/j0R12JVu5Q5pe2SEu4hKncs38MqS95x14lN7gaRfJ32BHduywL2n1ruTE
cndsHcW1pu647k5E/wAPed5LV+xHX2sSKx9a/caPTu2C7MrDK8p1xV3AUypKF7BA9N7R/DK127Oa
d2d/jgHUhTKnFP8AFIPxkgXYIFTlakVmVblejnfemqqjhvV5CuTtjciilEc08RftCcnK0erErXc8
vVRBSv7l+IXseC5HQ5hHMNDXYAnJztHqNKxyvUr05yF3DGI5xyuRAhcnbnv4HhO2CIidy1d9ut3U
kgiIQ67xxuVTuciBA/cc5XJIrkVoxkTv2qqja3dxDlajiu5AZ3FM5dgRnorJ6PSTW7tAMid+2RVH
XclLcvTxxIr5den8G9/2qUrVh2HJsmrXgJhG+Tao5zKxz1kSzNHj38wKwnf5o0EIzXss2vQ1XuwG
pCo/Hp0qHoyS16EhuERD9xBx4MhrstRk71Ojgi8pvlWSd0Ncx/kzzo1rStICQAySWOQcWBJa5bYb
1dUNUQySmpLnp3w14S+TYSWtaEyGjSY0hJIydqJDlMcS5jvKtKx4mSJjWyZ38gMCKZp7GWwbIR0L
HlQDNkx3ePDgzWLKuor5aUo3AzU8pCCp4RlM1i+BYRnjn1MxpYU6rKsmK/xYcSxYs64hOnCpIz4u
TrJjHlK2XGjU5QyZc1oA1Ngw4LSodIkxV8GLqiS2VJxFypkpHKpmzooKR8eXLmjjR6SzYYNtTulH
iubBAK3H9UsYyWIKuudBy2txMUMps2OPTzgzZk5kOPS2zDZZ0iTZENWVwkuRpZz4v1UFZV+Bl1cs
YsKc2bEbp/ty5k9sKPS3DHLc0iWRIqtrg/XGedMG22BX1SV+XN2xmVlgOXFTT3YlzrBlfHpb1jyW
dM2e+Ora4H18fmyhMuYcCrStbcXjWOq7Bk2K2hbGlTrNkGNS3rSvt6dtgQXGujfXhrNlhZcRIVb9
NS2sxyjJpkMqJC0+WLMMdBV0/wB5eL8+l3RcP8OXZa83YkQbFkmPbQ0206JNrSySIyssvJFYx2uN
E/aCRCQp3RWBGAidi1NtOqzJ42oCp3aSEm8uwbEFPkpIM5fVtnxi+gS7PprZNlAw6lktisHcp3ml
bMGIY4jZ9sncgWCSGpGYj7GyaBldcfucJkrCyGxWLdNSQMzZgxjHFZPteDoFmh2oAfKdPQDIdyik
exkxCGbFG+4RDBlMlMaIUbLCz2WvtEKnYGr5k9oWRLhO9xZKa8jY7D2yMJFmtljawQMnWbWZXWrT
Z2BKsua0LAXGxU7c1jiMjtl22xYk5swbWDj5Ps2jSutkLjhiIsia0LRXKJIYQctrnsjttrFH4V26
74J/B1NbbtUYiYeW0LWXO0rusljUjAtm2vF8GxZIZxENZ1kjG1txyVUCTJEtAMZb8ZA5DJQ1cwSW
Nr++BZJJHsJqz7Jom1tvyf8AbJhpaAYlxxkikMkseUY0srVGurrNpmIossLFBtrLbiRHifkiW2ON
bhGSI8xkljnjYlvZ9zKkYdo5RoK1YImVth2HtKJ6SpjI7FuXMlxZ45LXnGxLa23yqtUM3uhVLC1R
ja647ZhSxvZKsGRmWM9Tve7oF6sdT3KPakkSpZ2vBtfcOGUEwZmzZwwDJbO8ittWSGFlCay1t3Ey
pusbIG5LS1QaQ7VwSxZzDDmWLADPZvdIqrjvMJNY1lpa919Tc9tWzB8be445FtHCLDtGnZNtGAaa
xeQ1Tdc8LYjay0tFM+rtlArbMTx29w3A2DwmrrgRg2NwwQ5MxTmpZo2iSzAjbaVHcOFZuiGHdieG
4ue4wE1wy1l+NRTr0TQSZbimprvsKW/j8bSzWS+vsliEBfx+xcXyHYUnJcTGLxypuvEUmp4bksbV
ZToU50c0fVAOzbXzZDO+7eq1G0CTdTCcORKcV9XbOhq/VsZUtLJZpIstQPh6tEyPZ33lN7yq6s1C
sNJWqWlZJlOM+ss3QlfrAb22VkswseUoXw9WtAGz1AswSlVVq9RugZL1UhWlkOKsGxfEc/WHMdhZ
LNIGQoiQtYLHDY6gWa1S5WaiLW5K1b5DSlc98KxfCV2sXvFPsFmlCdRPi6uJGDPvnTR933rdRFr8
k6qJIYU6vJW6oNXo7XBFyw1C+aJ7uS+rjjsdi4f4d8tdtkGxfGWVeocddb+Hk+z8zIVmsXH3alf+
pGtazUrW4bUPcxt8rGHkqcoL5YzJctZT4lusNJdg+Tjl6L0Tr8rti9fjEwBlE6PqFwmybR8rO5xW
LbKBDX7jNeZXuiznx3O1K9GSZjpCjMo1BfKFsi3dKTl7xrR8bC3rioUivWPMcBU1CRGyJzpCoVWL
Gvnx2ybdx8cZd41m6PhL1SIaSpFDLcFzL5yNkT3HxCq18e5cFsi4UuOKq5GsXx1ffOc00lSuEdRO
Zfv4SLFZCIVdwXJIyEuHFQhlcsaweDH36vaeSpVFJULg3qoyXZKVEMqZFuXx8Ndd1pTK9V6csjyH
DUN+5jT2LjJ3dli3L42FvFLj5HJ0aaoXLfudh5biuZIVigvSDbJtHHTu+8e3fGQl28yEOr1BMcF3
156oeYp1YdWKK6Ixp7R58eXfIlq+Nhbt5EJJ7mBlvE7687Y01xlaVUUN44TJNm8+KTlkW1dEwl64
rSlVVi2b42JqAyYW+KViyPcN2UKHtXyUcT3i2RI2FuCPRxVdg5CjX62fYslxFQnuO5MBsme+Rj3Y
7Pw3BF4KlyfDSXExr1xlmUTHzXmRX4GUUK/UjuapFdjDKNfqp9iSHExCe6TjCR0x5EV2COQeOmmc
jn7qxyo7zS4QzyKi4hiMRxXvzljHvTO8bHvVcTdcXvKj3u2R3ujCOxXFbirurea47vMxxHYnJy9g
yI/dub40BXo5hR584MT34sY7cVV3YiuVYh1QjXMxfnbE6CC8iOgyG472cxquXwjq0rFH0DEMRCgM
PN1XBCIXH18luORUxoldja2SqEEUWJvyFAMfDQZAM3wMd5sJVSmI9ijexnJW1Ul7ZEUsbG4GtMdD
V8gGfkEd5lWpkI0o1ErRK9WVB3NkRigxMBVlkoetkAzdd48Rx8JTSG4QaiIIPcVtKZ7JcQkVBCUi
spZDmrTHa0oXCcKpKbPoR8lQyxsX+g7F6GT2f/ciZBhOOpqjtshwFkZLrXR0iQlkOWqcNQUnNPoW
+FpODUpHLkqA4KxKhTjmQljuiV6yElVjgI5qp1+PR7Z8epPfIFYshH0KjZKjKJ0WK6S5tD+2XXKH
O0rnxaZxGyqdRIRnBYNYsnH0fBHwXIUFE5yLRZMrXByFUuKn0JNpVKrGlEo3Yjs3xn7lhUrpI5tc
sdYVU46JQ4el7bSxXI+HRuIyTTKNpwqx0aO4xPoGwzRVEWJQ9xq6ebhKRrGpVq8zdP46hYmSa5zH
xaDmz9PDbkqn7WRKNCpNqPFR/wC1yrlbWvluk0fYYZnB3TbGJutfRuM01AiNkxVC6BXvluTTzWsm
1ygwAXFKDTrdpdIomOErVrqXvoWhTZtY90genhbLp8O06peJ0OgarVoI6ZMo+20rO27nnPN8AJxS
RtO8hTa7tmhafRzUoo202iRiDgPJJDp4aNnUXbZErnyDx6CK1i0cVcnUrxugafZx+hxMn0KMbX0n
fX6HDahaALknwFjvgCYUgqCMYNvASK6JGWQSPpxigtIXikq6XysSoisw9CEqWMBYj16NT3qqfyHf
RAcbelWPlfXvkljUY2MsqDmLwyJJqqNOEikE5tnWuhFqadxlSoG5lxQdpYFc4xIlOxg7OhYQfgPQ
9TS8EPSCK20qXQi09V38bVh7d3ScMr650gkSnYMVhQseFa8jJFVStah6kR0t6d0N1RU93PpTGtvK
HZkKteU0GrYAU+kHIAStIKTT1CMaasEZtzTEjGqKjuq2vEjbrT7XNgVjjHh1YhDm1A5Q5VUQEmpp
mDasMJsuqNwH0lMpFHEAxl3QsOKSBwH79IkdZBKinYFOzEKt9Rdp1JT9zEZGC24pRnFDqHvkRYIY
gzRI84M6mJGm1FM0LESMZ9/Q+9LT9zNo0dttUDlx4lQR02NCDCE4EWeCxoyR5NVTtANCxCP1DQe9
LT91HPiwmWlUKfGh0pFmxowoI08ayDbUbgS6upaBjZUYhNR0PNKOmUjEOCEywrRWUWHRv8uPHHXi
a6PYhsqN8edW1bIg0nRym1HSNItJTY6SGHlnWjsY1HToh7Gcymj11sO1beVIOYZQIYIepwyz2leK
fEK3tkTovynod7Z+NvY2O/ujM7hqeq7Q7uUIAtOObvZQWyGVtYgEuSsDlarCR5EhojlON4oImPbZ
VDTJXwkEzUYkRaeWwSnhJLFZROy56bZt6U9Hx0TIrO4WuhtFEcZnK8aiZpiGhBnI2PlsgyBqQIew
UDQiORhGWI95NVCaOI87GuHHGWVK2jigzUknnxGq1sxgWMtmEM8bHAsY/KQ2jI9CUj2YSI5i01Mp
FhRmDFdx0cWIBGAmT0EQTGnjjq0WS/jHQatlNua7tZQwhJhgp2Jw/wDsYTNo82xQDyXCOymYw6Tj
JGZXHbKbOjsE/wA5jUiWCHkzI7XAptt7SH3WT4DmPjB5mpo42jtBJ2J6bGd84mVg+7NjR+3GeZqZ
c7KtBFTxzFaNbfg4WnY/I5vtMkyGFA4KEmxY6Mjukt3hga4k53YZAP33WImtxZ6MHBn+Y+YNqgNA
dLks0qVUPQOAniv7tNUIDAgb2poG/UUGgweaqSij7gItaxHyTJGVrElCKJsOSa2aPKszjJauaJG2
LBNhz3SynRO3CE3t2kp8d9UqyAakAjX1dS8xIIOINSsTu6eaNMExqg1IxO7Qhb4dqYoS1b3GDqUb
Uxye+VYULIiw0CB1i5Jh4rShra1o8nyvFdCVJQ31bHSzNSMGvnOkPsa9pkjw0AAk945igQ8evrWs
dayXRcrn+YEla1ZsvaMGtmPK+0htIKLEbHjlnPSWoUPFrq5gyXEh4EqSLKCaua+XMTxQ1UsryWkN
pRxIbQxpkwzZjG+TFgQWtNeHeHKMrzslQmPlTW+NHrJBkk2UVpGQo7RRJsiQs6P9+FXwRpJvilG3
TznvbOhsU1g3sR68shJNgBrg14Wihz3ndMgp3oWqwtFOXG/GmxIsiwZ2QViHSXMjtICvjtFCs2nJ
OgIpYcWOz6hqDuMHpxpBvsAMUk1vajwhnSVIEj4tcFqRLURjTapquiRQM+pajV/DT4nhfZibynt4
Q6+MfzTNRYVcNFiW4HybCoRfGCNv1DULXKLT8dwCWTW9yWiNhw4ZFmPbvAqxo2LcQyGsqZvEEcaf
UdTMeoaCIsRbViK+anGJXQ3pJInKDXMTxLmI+VZ1DdgJMHGtrSv+qx6enWvzWO/06IIhsq6tsQd1
eIGOV3N/4X0b9HYvQyY7+6qRFmxkRId+5fIrJChkVj0kAlIgWXshSyKT/BLAjsnyVjnqH7g8hrnc
Ua3Um27HbPqFV8bUjeLyN6r8ehei9aYfORFanYunKHCyfIWgGjAWzE7cyYqLpoX3Ds3j2h1AsJfK
lw2/Yuft5UzXKYre4KNEYIti5eydCENW13YZYWCAZTxvMwvCOneYVFhtLLDHQY46LlqL3hLuI8ca
kYmw4vzYD5Oqx8Fu2pwgT1FJ5q+LYLxnwJbFDIEMymqGPZUhUTpIWESIJg8u1XtxNnPghGjpW/Zq
Pch1TjLr0MyVGWIfT1ipX2P+CwT7ruunmN7g0Txrgvaf3vIPStRBXP7Wnkudmm2IrJrU7E+SoSVC
oQ4WJ4t09Quopb5BJSNVIrGNy63QMSIWWSPHZFDOseLauKnbkFYFVOB4o0ZhTNCjUAn7LMG0oe3Z
cjebk+1ET9k4KOJVt+3qNNkqKvlj3JGHa2alWBDfLLHC2Myzte2lTbsVO+hch/22cRDmGFsZsQiP
FqZER9dLcAlcVXRNR/5tN/tiSn7KDbt6m35k+fzSf7b1/juE3uDT+NFT9k9qPNUtRBN/27L4hMak
ib8L/gc1ivCnGLC+LFiPkVKJx/8A7iz/AMcFrEPNbu3b+P8Ab5A9osPLLgsqrRqI7/ZtP8ULh3Jy
fsZ/rq4fOKm0SH/fZqiS6rbkRP5Nq7iGK4bnz/cQ/eG14+9C/wBWE379q9rC1KtU0pORbRdgwSse
kz3DGT+F3mNlQNvG1iv8/Gpml03Pbrs2FJYVkj/DF/0ny2DnVrkWLD/9C7P4+VpmmPO93WS8Y8Ga
M7T+0WF/qSJzA2VY7cMT/wBLUR0ipWHbJNY/Nh7RKyewjSJ/Dr0/iSrBkW3qlRQR/ey1GXsCrJTJ
RbNP3zE/i1dmwmO/0a1d4k+yZFt6teQ4i/8AZaokdkFTKbNfa+7p/wDq1No0zie0GB/pz7BsS7ql
3Hqgjg2QNRTBD05YyJaapGp41XVpEFcXTAtkFcVy4vrXF6G/tf8ANT7TIjkdCvR7yYMdxZNWPsBl
bFZeRlG+iT+PZzFG48V8l1WxWhsJqxZMCV5AdSe+MGriVH7Y2ol+4THdV6J6kyAZRGhu3iX5V332
fpYziAvXOaKQqqTTp3eXJf8Ax7YqvNHMoTV71dGvyLyoGo6TOXtCrZpTSpo0eGHWox1hK8dh2nlO
06m0e+byGxxmqCWQLhagFtXzGyGWjt8B7AsJj2HhqpAh2Y6yerUqlVUvHIrIvvOH/q226FjyJDEb
ZyUdCcpAAEjXWxHCHSSHGy5GjxvCQTquyK6Qb90WqdtIsFVGwl7gdQjRHacZtJn+4bJv3HpsuJlO
VWzEJvGuyO5tfs/Tz1fFvSq1hne+lDLvZOVorB6qWtMqSwvV0a/KvPTCfttHqIVJMIZ9jHQyR4SA
ZPmoPHRDFfUptF1DvkVktMFPJGIK+EXIJ0IOY9Fkq3aOsonmp/gjETLDn3q7cY5UdsozheKKXJLL
I2rJ3IMFAAspiphq2STN3xyR5st7qlz2RUVCGtkVoql2wNUJuSMxVLW7pA1E1ymoWp4OoHla6jVz
4mp0TCdKZ6Mlq5CxiBKsjuIMEGSjm2I3qSqRRR0lNSXY/eHXDI2RPktYjSo8Ro5fJ7nbjQZTXpbD
I4tS1QCWW3y7FvfBXx3skWEpGoM6ECWEbyGlQUSumNetxGeV1W1wBvmtSfO/kxq2KVh7OWjEiyWl
DIrS+U1/jxq+e15LiK+QtSxYoj2DGyZieZGrq4gD2MxGMgzGlAerKshpEixa2ya49zCWYtUFYbJd
m1hjq2bFgVLop7Ge0Q6qYw8WXUEdJaRsKLqOSkmTiZRSkjHKVtgCLTrHPPsGRx09kyRHsKRZMlpE
gxYlwz6jbQUsg1cJa4c+4a0jTNsIsWj8WXYWY4waO0ZJFYUXlye6yvjw71i2VnBZaR6+Cla21u2I
8cxljHBQpHlWlqyGOjuGmDY0bJZXkbWxot8z6nNiNtIsCC2uZa3zFLDnssI4aJkWXZXI4YqW7aRt
jSimFcdtdHjX6JZS4zLYMKCytHcX6KSFPHZRo9EOHMtLhkYVHcIVlhSjlHPLSvjTSfVpgdLvI2LH
StEto2dKlg5x2abeQs/TwfFJ+0noXq7F2XN9sN8E+Yhe0WotkIK1jNe2jEnenzEhR6m48oloBDJW
IjBzIzTPSOMYYZUTNQlTnQnTsakMm1PHQzySWxAWk3yHq7Fz8+jbf0plUDuyITkSNeDRXP8Acmn2
tDHt+LhTdkfpoSIQqtUNwxvOCHvSoLmtDeIi5UyOzJcRskIIoxElTGtwJGuGeM0z/DExkaQwL5Am
ScHBCNtujWYNO6SkawMeyVqpEko5hoYzOQzQDNaIKQ17JguQwMtrHuZUw2OxnHs2kYbkgiGRH1wV
cwjADHYJ3jjGdkdg42TpbdxAGZg4McRJUtrQ1UhqHOjCIhWBZakQ56uMAWGVj2W4Bph/Z3SgExxR
lZ2L3g8gWI6TVKIYrng4MjZH6dawLJb2PHat2NSib3gkZ2L9GvfQyUEUjhGZHQAVPMbzQjFE6MBx
DDEjIExmHaAiuGJEtdkfXcXmgnYwNiZjXx5bCBc0POTMawca24HQg35IltCOusWmMYjHtYwOSe0x
WHH2ntC50jt9ljQ+cBokaeWwA4dwjpBJQyoGWNmXJGEbUNGzI0piCs1YVtTOaJhCMJnktEy9nIVz
16AJ23VF0j2d9jstLVB5XXLhEBMaQc2xaBjrh6Sq+2aYZZbGstrVSvrLvlnkJta3HDINu4BY09ph
zrNgGOtH+TWW6Gaacxg7O2eV9Vdqi+aza2uNshWagLDsmnFPtWga+yI49TdIRprIQxWlqp31Vy4T
0sWcbi53yNYPEavt2FBZ3TGjJPep6e7TC3QmDsbR0glTbujPHciUdvddzATXiNXXw1BYXouBJbnk
prtBYa/C0VnZLKJXWqwns1JFUN1eLJQr1e5VxuMdxWnvliYXUweM+wfLJAsHQiD1PHUVteOlqw6t
dX6mYBlhqVj2PkuK6qunw3m1aByTp7pZYk10cgNWNQVpdrNxpFTKzU/iMnamQzSSFISuuX16v1gh
UnT3SixZjo5R6wVkaxunTWNJtlfqYkLJmp1ktIXm6utnwnG1k8qSprpBASlCUGsCijzrsk7OeV2p
TQssNTPmNUiuyvsyV+F1eYzZMpZBQyHALG1hIAKyuCWCR5SgeLWskI52pzzRgmkA5mtJaM/W8lFl
6ukSGkdu7N+qJ02xyY7Fwv8AaT53yFOcB5NQq4USesd865dLSHOWLhb5xlBqFwh/qZ+F1C8iMvXi
yXLWU+HbOhpMmuluiWCxEmWzpSOdv0X07erfIchQOHqV7WyLd0vOXF8e/fHaW+dIacnN0OwWLn6k
I5JMxZOBN47x6gIjJFs47eezo14QGLqJ2Fs3lUF68SJqR64XUDnJ9QfzHqF4kfqFSJKlKVRv4uj3
z4uGvXGaO1cxzdRvbhLxxUJIV749w6OhrxStKdXOi3Do2N1GuFu+61li4b26hVULeq9EnOQgdROG
12oFc2TYuNkW6fHz9RYe1cdAznicmpFahL1So6WqkBeqBv6ic5JVt32k91XpElLHVupV2l2Pk41y
tfGv3BSTerIQj1e+Jaui5+pHPSVL7zo8pQOZqN7UmWvlow6jdHvnCYuonLhLNxHD1CQbf1CR+FvX
vRlg8ZE1E5VkXpCIY6kURe24WoXsbIt3SEjXBI2JqQ2HtnnTvryBdkC09o4zQTHCd+oTMX9SFw1u
+RjL8o2rqE6q+8KTEmPYVdQGyRZENiG4qO6OJn1cpHyLIhmxrEkbEvz467M/GT3Mel9Ia19yUiFJ
yxcToAqsd9XOuFkPJiO9x2RxoacQuOeuBmFFj7Q5MI9y4wrm59TlcXyXlVN92SZI2lkFejV3xjit
x0uTs9yrjCcc80uPM5+I7EO/HPKue6qxhlxfJVHIqYzk5eMhmOKuI/E5rj1fiMcTEhSFzxZSY8JW
4EJC54UnCDINGRTEz6dLXPBlNx43jzlndxXcsExz8dAko0jHj6LiYmAjlNj66SPN/dgnEX6VK2KI
gsai4GuknQ8I8duAilPj6qU1HsVjo4lIv0iUqSAkArd1UVWc+SK08bPfeNCIfDUkoeEYo3gApXfR
JCskRSx8anuGnNJSTUHionusaC+VhaKQxr2Kx4I7iubQmcyXCLDVjFVQ0xjtlVB4ybe8WC+UpqE4
kcNWPjgcd6afM8cmCWKrGKro9IWQ2XUHjMRN8i1xJWG0/IHh2KJ3xiYvX4XN8fitz5wvwX5RMiRX
Ge+lVoo0LummVKhHEid8jqVRtj0vcRaLfC0WyDplfkyqeHINYp2zq3x0gw/IyVTqNCjVMXF9G2b+
lM2wA1IsSjV7ZFN22mjuY6vqFPhNPcWyoDh5FhOO5mn/ANkypUGLHVXQ6JXMk0vBhQKN8GrdJVaJ
EbLhKFY8Uh3hof2TKlRYoXI6DRvIyRSoNh4yjWBVEkr9DRqTK9QrHivkPFQ/tl1HZxQu5wqJSMPQ
oNkiKolrqt8rF083abWuBkeM6QUFAiNm0/ax4XI6HRKRhaNGtlxlC6uqyTHfQGok2tcHAxHmILT7
OEyl7bXge10CjUrTUSMbMiOCq79PnIkV0kgdPNaObTdpHhdzgUClGega1kqI4K1tQ6Y79PiRs6rU
ORIjpJQafYjJtJxaQDmvrqLuNNQojZUR0d9bVPlPWjHxn1jo+Roj5LwafG0c6m7bHx3dyvoUc09A
NGy4bwPq6t0pUpB8bOsfHyHDfKKDT4mtn0XFPHd3q+j5NPRD4TYboq1dO6Tn0USMsalwFgw3yix6
EI22NHxYoHNLW0aKM9GNWzoL4xKyoU6/Rgqy1p3ByHBfINHpBDZZUSK2QFwnqvRMr4nkEh0rGCsN
PscMwFZIqaRHMNTCey1rfFfUVvkq2oE1l3R9tkGKpzQqdoWT6JhR1lHuTwmCQlQOQNaFrJgKwYWe
Ix+XtE0OO9lR2csYxzlqKZZD5FCiRI9XysQVqAE2M0uXtAmU9PyVK8SJeaf3wMVSGptO+2oq1gA6
WiJIMaI0ScssBDflbTtYNeHcm1A5EemgCZhxCAoQsOmrITQD6CZ3HUtNuklAR2Xj2FevRMgRfKfV
1DIze3GkLd0XYdR0u7EbFGl1TNlCrKh5CijBgjPDBZRZFK8Muuq2RhBWKYt7RKxaOl2RTxg5c07J
YqylISSwQYTHABPiyaN7JtfWsiBGaPILfafTlQ0nBj5ceNlzTjnR62jc+S1ooA2tDZxZ1A4U2DXN
giBOjyJF9Q7rSUvBhLAMdLOrHYxKuhc6YrhV7Bdm3iTaAg50OvbXhHZBln1BQK51HUdkRbQMdLms
HPi1Wn3+QpxVrWOHdRZGnnNnghsqwx7QUuRqSg2b6NvQuL75xwiboRP3CbzfSVKIO2kDihpit8iT
GbIFXU3jktCMAOlK04ZhEGvkscKvG1+Tq5CpXVyAzUgdmVx0AVgmTQ3MDsYRNsXpvn4zbNvRv003
WodpnNiNjuZOFJqEWQGK2KIcphX2Ncjm1tWgWllNC8sZskMOn++TjFaJ7JmSadHHDDZFEyQ15LCu
QjK+qQDCyWhc+OkoMena6STaO2ORsnJtQ1xww2xRMkjV9hXoQddUtCwp0ErgMkgDUNWWRGxxge2S
s+pR5gwkiiSQnOwgIQdZUtA0khI6qJJQWUzHSCsSOgSNkZYVSFdGhJGF5Le5NgIUdfVtDhDIB3bb
LC2nTyXsQDAFbIW5rkRkhnFVxibuoatrBGMgcaJsoLadvkv2A2MdktbCrR6x4bACSQiPlQWlZXVT
Y6nMkfGMbLAyoassjEjtjHbKWfVtLkeE2OJJLUNMgNK2DVtEskyAxokkh+kMWQ9iR2RDtlZOrGld
HhIEXltQ0qG0w4Fa0ayj+HgmpKGlS3ySMSOyJIbJydWsIoIiBEs3iaREQg4NW0WS5Hi4BElC+lMW
UViRRw5PkrYV7S4CIgApM++eMhxQK1o8nyfFyMnli1HDaPHdET30zGVxpTFAEk9OJB+TMgR+MSTM
7LrkyHdpaHsGyI6Os6xY8NBE7k+YLtBWxTesVpR3QpSuqUJ2LaQOKd16pm1KF2uTN8WHp5hnLpyC
mT9Mo1Kmoe8ldHbFSWqOjVnH6vagIaPTQZgJVijXNDFaGOWQXzGiSREOjY9pTS2vzVv3I2jf7rYD
jxjUU5MiiNFmAVHQz0p3zhJ2oc63fEkFmnsH6eE6OHVRELlTWjfGlaeCcbaxYdpBitZBtqU04szT
xoyOaqOxM0mBHyLf7Q6Zp0LZgaRsQSCgSRnLPiJygQI7GyNQteTNOBcF0sLfKtf2AqQlaexGnajj
RIEmOUk+u/dAgBb52pBvI3TQHAJMCnfuGcA1cQgizm7hhsT6bKhklWNf/o17EWx1IB526djLGLYM
RTXTfs1UF4CS2J2YbNqyXXPk3Fcn8CvTey1EBTOoIyxZE1iONdM5BqIDgLMb9uK1G1h61ZFvBTeu
rv8A0dRRVkO09G8STKanPUDOYqOvWKO428X89F6J1fi+2b4X4L/fG/2Klv8AG1Q5e5HMo30ZkMEj
UEzUJua6Y/wShI/LY3i5QEV4iS0RR7KmpG7De7Z2m15A1Km7S4vVM/Pr0n/o2Iu66nH2Ue3c0xu4
gR+MoicmMZ9qaHm6G37Ak/dYi55Us4OIm5JXuFgNpLk3ExE4Tgo9YabBE3908fLK1nbI9u7jp9to
dpKp9kafsnB5LBbsEbP3zx7pAZxKVvuZPsoFGnVu4hN/bPD7wG8QiT988W+QB7FInuVv2lB/I23A
FicZouWVzfto37k4e+QR8S2zdwTG/ccnuNP31H+rNHutezZiM/fPFulcHtlkJyV7fsOFsVjeUeOz
J4t1q27M4p3LFntCEjSmZhW/YUX3mpvHAmTxI59Wz9vD7tgNMhMRpzom72p4zhp32N3jxWZPYjn1
jfbj9+yZ+2CxEMduFbtHeNO4xP48ZqcJrUUlSzcaJ9+yb7QG7SZbf2kT+LwTuN/wQ0+3PY1xKdPs
6nTCN2XbB/OlV5ZYf61rJXvUxecqJt42pCINWyFWRp524tRPRg5R93aX/dk9U8OyP/K09v40wzGP
jOao9SjcU1RUcEkymQxtlrOnjAgYsjULgSFuBFHSGEqPe0jnNTxhgT6jJegQQpwzEsWKuf8A9qjh
7x0/jX7tpOjl5rqf/WpLFIBl1PFcyDYRp2Wtai5Gao4xLuMyWqd2LbM4zqSo/bY2DK8MblayI0VY
wYvFW3g0ZYxXbQDX4WzUA2VFvY6Am7Y3NI/5rt/bj18lhWTl+2L/AEGTmNkw/wDUr/8ANeSWxZFQ
XvyJSbyLpeMetmtOKd/iB/5v1BrJ0D/Tg+8zUUlsJ9HISRKmL9+/f2wVdg2UOav2YvvWfU2htK9f
4Va7ex1HJ8NaSS2VKnbd28cjA1FgyUCUv2oi/wDVus0BbwP9Ou/9DUk3wyU0hJMmY/7t4Ttxqaeh
48x37Iv7qx1oke9h+0CvciztSzPCdSyEkyJS7v1G/sBo7Hy4t0qLE/8A5KvX56bdHe+O6E/tL8x1
2PTERYmpAKQgg8i1EfsBKRHpfxds00nEVrJcHDhdMWlEoh3ZlDlNYeSHUfuNWq/NOtUYdSuTgRcd
6d/UmaTKiRLN3HKhVcjyIhJK7hjEc6WRdhjfuycRWPif4BETlZP4JVOc5CPRCGduIJHLMe7iMZEc
ywerHwl+yMic7F68arljyIjzLyENXOmOXYQnpxsHuR8T2E16bzl/bWKrsK9EUjtwtV3mKuwQEREs
nLyhL9tjkR9g79tcq4R6Jj3chc3pO58Qgem1k53KD7D5ohJ67srt1WzenYnO/evyL5pCIseyVUfA
9m91vcsV3bA3XDPTFduBeSy2v4RwFTLLfuV37GoVO7YKqsgNdud6Ijno+MiP77XcARipk9F7ld+x
veTv2fu2A1eckqIqv5AaxyHaTgCKdN7BHdytVWN8hvkWCqRkFioSWdqY4ncjqN/daVGBjHauT2O7
1b9lnkt8mxXusgNVDTTo3O4jwKN/kIRGBhyGqyxG9SVv2BakMi4T5xvzpZr2ltd/Hst/Jq2uWVCR
3h6m5d0fu7S43NBqZju27dXaXE9DWaKsOduk2hcng6kjHISjRzYZwIeTKAseOeHKsTAp/CK5ecWw
qJRpX6f4CHYGgLVWcyUYiu8aA9yWNwJ0mPRwJEU1gZrBBkoUBK0vkvO2PGshusJWlIJoa6kikPFg
VauNK0mqtoauRBNYHbwG9roxKQ62gnduLaqj7iqanh6pK5JGkHoj7RjzR6fmAN8FyzIpELBk0B1s
oy9mLqJ3cnb+6fOnZrYkg7m2IIFMsMlxbNC2psWSosikaaWWWyFGq7tPKs6xtikGP9NDLvGJKcVl
pGhUzYj7m5YFKW0bLjSKVhJJ5rK+NV6ga+XYVw7RI0dKwU6/RJXfHbRodOyIW4vGxko7hsgRqYZJ
EycytBVah/mzYQrQUZjKwU/UDVkAlMto0amDCNc36Rm0N02QOVThIWfZNro1dqXaZKrxWoxNHVBl
3/8AJBOHbRwVQopbjUHYyiukkiPTBeWzs2wI8DUb2yjwh2g+Y6uPJ1A4skEptzGDXigPvtQYvyvX
4z8qvRybYvQi+xU92L+6iukak4bTDrxt8+RKbHjV933ZU/gYNS1osnDabBhGMcWQ3uakMis0udGh
1EdOFSNDl8gcQVvZeS9y47pt6duu2NynsvGwRRzBK9sZsu62LBsmyWNYJmWVmg0rbnkvEZslzWhG
244nEccxivHHZMt9iwbNp0RBDywtO2kC35P+0XJE1oGJb7FDJZKG4jANmW2xYFk07WINuWFj20g3
PJ/2zZImNC36zsWNMbKHzZHbOteC11o06bDbk2f20iXH3eQy4eW0SPt9ix5Q5QlewDZtpxyttEKi
qNqzbBBth3H3UeEqGltG0txseNMZJGr2BS1s90kP5OVcY7bKW47S8xlQ0tg2kuPvxprJTHEYPLG0
4LXWzSpzYmTrFBpDufvd0RULLaJDW6tkRpzJLHEY1LG14pWWqFZ3GJk2w7bYNxsVhmEQ8xoWkuPv
x5zJLHGY3LG1yrtkK1SDywskC2Fco0jTseh5iBaa4Xvw7FkkbzNRtna8sqrdDp3mbWNkgkr7jg8U
ppMlzWx2vt3eXCsWSWOOxG2VrzWqt0I3vNVLK0aJlfdKEjJTXpMsGCZaTlkkfm+MXZ2mi8WS5nMF
3s4tG7aQCcqA1C9HpG28iol9oV1K5hkInPTRla2VORw7lyPPp+24MWSpMJPbHZCt0fOJM7jRnRMt
bIYxQLhpGuko7LKzEERy8y6dkI0j7ZiikWnbnx7JhRrNE3Lq4QqVVy4Tm2ouN3cuKlQZqSI1mEKS
LcD2ybVoZkS7AYLrSMLLa5U2Vl8PgtxD3sdRCQbj9yTAvxhjXMpJRa6asUsbUcd4DX4xvsrwMkVZ
qMYc/UUDLLUg+3JP3n/lME/itTf+Lh9UhcybOdINX2T4b11WBR2lu6Y4R+BIGqmgZYal8hilVXVl
/wCAsjVrSslS3SHwrB8VyaxRorG2dNcwysfB1WSMOw1G6Uxxlc6uuywXH1gQrTyXmJEmOjvbrEzQ
2NqSe9hFasHVB4Q5upCzWdz3r7csFxdYSCIc6lfFlPjvTV8lgZ1m+crCqjompZcNk2+POZyyDbHg
OPqqUVHk5vjyXx3fq6a0cywJMe0uzoupJkNsy9kTcV+QrY8Jx9UTDYUnJU+V9blxflfbCr+0vymR
zKJzL6Q0TZz2ST3RTMAdQufeHe2NeFHi6jNj74zmityMWXPfJWNOfFyTZEkZHlrHyTbmkYqqqr75
+Vzf+kx+2RLYsfC3JZDXP948xws+vm4yJTzYMyicK4MNsixIXFIqrHtCgx9yUrXl5uDLcJ6XhuJ5
TiqwytcG6KHJFiQydz3jWRBYS5I/CF5uDMeFUvy8DTnGxpVY8F4QWSbR5kV6qsWyJHx9wUmFO5+R
5bgr9eIjTznHxDK1wLsgWntXHxSLkexeDHXb34WSr3CmOEqX5EZInvPjT7ODcFGh7Z5muKqrHtXx
8ddvNhzq9XLvi58YN/DIt0UKGtiHRxd1jWLwY6/IVDSHEUEpw3NviIyROcdUJs6NeKBDXDpCOMq5
HsiRcfdFKj5LnOFLcNW3puMic8zu9ssa5MJp7Up2uKqrGsiRcfdlIhZCvUMtwnN1Cfiaa8q93bAX
RgJItCGRS5FsCRcfdSCo8yucOU4bkupHA0t5cQmyitzhQ9mSQ3urkacWPi253I8qq4ZnMd9Yl7Fk
vIvPbGW8gLCTzGxSbqvRMjTTAT6rLwp1I4ZnCVtlKw0oj8R2DmSmNNMlOzfdY8gjMdMmOaQj1wZF
3SVLxZB8bIczGnlPxxZaY+QTGvLi+ZjnOzZXKMEhMcQ7M7vLGeQXHNkixSe4mvIrostGv5tc3dyj
hynIVpR5ywUQx8fGOJFIu7GvJi10tqE3Y5qclbVSCoaKUONwcKRIQtXKAz4UblcqV0giFa4OL79U
wQXFX6FK4GE8Dm7rgKg8lsmtkxUb75GhPkYWjkix26OCFxVSgkKw8Msd8SsJKz9MyslVMiJkWK6V
jdOHVptPSRMI1wlR2K7N8bkWvJLybTnhNiQnSsTTBsLpk40IBRFh05JmSNNGGxWKiwqUspP0sbaX
RGiJEgPlO/ShHIfTBgt8d/dBpshWu0ubJleSE6HRFlJ+lC5YUJobERd4sN8h5dOFZH4L3YFKSVkj
TBx4Yasf0X0fno/3z8E+Dru7IUZxnCo/t+HvMNQ8Qihq6StLsyNT88dRN2dSN4sqOTptMomwq3vO
sKjsNhxu+QtNsyRGUbnJti9E9um3rTBDV7q6h7jZFIjElRFG+uq3SHfQ04Ta1RYCE4pI9AnGdUcE
JHcj6+lc9hqZEbKiKJ1dUrJclAxqT69RYCI4xQUCcZtPwQkRzX19JzYSia1kqAonV1W6WRtGxGTK
1RKKG4pI9C1Em1HFpY7mOrqRSjPSN4S4DgrX1b5T20I0bPq+04MN5jgoGNbMo0a0kZzX11D3GGo2
IOZCULq2rfLVtCzafWqJAwnFMCgY1kylRqGjOaStoUIwtGxGTq9Qq5my5tkWI+Q8GnxjZOpkahIj
0LX0SPaSjHtPgOA+sqHy3pQgRLCo7WR4JDnjUImtm0ibFiuaStoUVDUY+M+vWM6sp3SXJSBRtlTq
HIkB8k0WjGJs2l/aSI9hK2k3YamYrJ1c6O+ppnHeyoFtZU6hyFXumFj0YRMn0bVa6C9DV1IiMNTM
cOwrXAfU0ymX6QLja1CiyvrllEj1Axjn0TXNfCI2TW0bWMPUjIywrXxiVFN3HLVjVtpSKzK+sfJL
HqhjHYUbSDlRVjvXoISvdUUvLErWcbqh45WVZDkj1bBNsqNhmLWF8mtp2jHIqRmZaVL4z6al3X6a
xUuaHKyocV8etYMdlRDOIdURJFZVJHaesGZLWmJHPUU37FgsVLyg/bUVTzuBAaBlnSikiZUFSXW1
jY7DV4ztt6R8Y1LSoiLCFve0CPynp3vIGEIA7CmFLElMRJdfWMjsJDCdlxRujHpqTZqAEmXtC0za
ekUzxRQxmz6gE4H0R7ZkCsHEDbyo7Bm/eWjqVmPjUrAxtWxWxpm/RMbmm61D4doI+agrBGj0UbyJ
CRBQgvCGeCXD8ezpqpg43cjvJquvZFdpStSTkgoISW1eKWyDWsjw/wBQRWyzxGTINZHDGPLvY0TI
J2T2aqgNERtfIfi1khMcNWLXQHSn0tMMDdWiRIul6xixri/bUZUzEtkt6NpZQY7K0UK2DOLfUSBP
V2II0RNUlJKKxJMKtWJElz9U+FlTMW0SwFGgS5t6GCyqvT2OXsKO9sC2iAgh1NIPLMxsmDKgqttQ
07QZLE1kWsq/LsX8KkFZcjsH6rokj5+ExcTFX0Li5+CfBk92/wB2nqxHMs3siAizEdZCa2TFBSoy
XPIkYFHMQ7pz+20U39sHiZ8qG0o4lb2SXw0UMU3iyoRmSwXlegsMmznf0E6flPnTlekkhOMMcWQ2
Y6fVNe+PDSMNZzWvmw2mbAq2jyQdI6ia2aFKlrpRUbGZGkNlOnViEfGgtjC8xrSS4TThr6xo8kSU
Ao0bLF9Ka+UVqR2R5KHJPrUJkWE2KHykY+TDQ44NW0anIgFEjZY/pLXyyNQLI8lsh1jWo9Y0NsYb
pTWPkw2nFXVbRJIMkfB8ZYfpLVkqxAMDIack6saRY8NscSyUY6TDaUUGraNxnIBRI2YN1Q18lw+y
IB2nJb1/7JQ+D1zbNO1rWxzEQOD2ljdVtU7hIBkcyGfNrUI6NCaAanRhJERphw61g3GIkdQIkpi1
jVkvYgGgOkh8+tQuAhoEXko0kiI0woNa0KySoDA8ZQXVjFkEH47Ipu+s2uaTAQ0CFZXAp4iGHCrW
jWQTs4FEONa1qyCj7DIp++6dXtJgYiBD5vE54rShgwGsSbJ8XI+0kX01vkmb444UnyFmwEfgonaF
5zklFjtKGFXtYk6R42Rf5A9SREY13SnF3pIYqBB5qpILH7oYMBrVnmcEkLaUJtcjpUzaMOukOO6f
DQmMjIACzSeU+P3QQIDGJZncEsL+SJK9vm2H8cdRIId06E12NjoKOkkvnOB3Y9dCRqWpntfX7nAk
FizbVPHDRvK9bGI16NA0EVpjeeoENGrIjUS8UnkVW5gtht8+45ABRuNvZRWuagOzFRSundpCQ6uM
xmXqFJIpkVY/iMWdaRVdGPpbuZZVZIDqGyFGWFJ8iNrT3mdEyOzmTTEXtC1IBeL7t/Y0xDRxbYCE
ivnkqjxWefYV8fhC1B3IUiXYLZZpWJ2B6qhoUcK0d3Ipe7EfQDfLV3jwbGS91hU1RJGOIKtANVvJ
LYUeuE08GS27pRmWmqUiRxmJ3dVAcSJpkqsFcUzbFayKkDHE7sjUQuQaWuWEmpvaHEE6S6opkiju
bpkYZCLKl12n2nDXxkg5qyX3zVVY6UQIR14L+8WU+HFcd9ZVthsvb5scdJUdxHuUZDo50HT4XMka
lF3gVNf4AdYptA67Z+V6u+FXoVPaR8tT301/papX9jlVrtNye6xWIg9SHVU0t7Nlt3S2egB6bO4r
Cy+1kd7Stv0+2b/JpP8AeHUDdwSE/c759K9Uzbdc0Ym4LEaPytFxkk/uKn2iR/5G32gonGeL3rU4
gan3JrOeQQ8JBk3UifZKH+QifaGntOCjsrU4han75rN8hC4yn4Rv2zB+81NghT9s4aLla3ZjW/cm
t5NhD4yCJvjm7hML7w03CJuyThouVzOLEb++czdIY+JyN3xW7iMNO8z9wgNTLBnvWJxbx/fOZu2I
LgewbuCyHsVzdsYm7qJv8SaNFysZs1WbEsGftjM4lIn7VanYKP7wU3EJqK+eNN61OKKn75qJwisR
DERNnN+w8ad4KfYjN/dPH+6sYjW7fdsm7pEbsWS39jm/xiC5GF/gjJus9E7lWzNtj2aIjYTE7stn
7CN/jPG3vCbvHiN/bPa1S1aJx2Tv2jU4wGIh5fwbbxla3uDT+NDbuOe1vOqb9vVSb45vvmn/APcK
n8dUahGJ/Ght2DYIimqNlENP5VsibV/HyJqZI/11ViEYiJHhL9mwVqGqdlANP5dr7JXK1Tzv2tOn
8dFZ3Gp/Hg+w56p5VQvIKf71sv7a17HSrBP2SPaIN7Eexf41en2rFyJLp3cgN97G8XZlYVpJE937
DL/FEdqOF/q1v9liVBT6d6EH/wD9C7meHHqbhtkuooLXw4ntJpP9LWPvJ+M/OR39l2mJXdDq6X44
Xk5O0xOfyuCdqFOkrJkVUlQzIBlfC1ROc6U1/B+lZDii1hMeCNUN704IEDC/Uch1oje7WgpVPYlK
KtHbWj5pNIN2zVe3hRDEFiXUh5IeqozYlbbRpz76UwIqEbCM1TbGhE02d8tj2okvUz1YClsPOHqL
7sWmpUAG4uGRmHUx3NATA2UqNmnSOksva9JsqMFlYK4uXy3CikOSpp2xxXV0gkIIxHU2q3Qcg6q8
05jfwqaZ5MjVD1ZEpZbpkbWC9yD1/G3o2xfn4wq4b3X86WMnjakF3WKFVfRQ+wJZKKl3E7jdNtVu
WJFQao6blJG8bLp3BlDYKXLv3jnTcumhKIOoSJ25C/udi9V9SfKJmkCowU9f2VXJSHIiK5yOC9z1
l77BE9NrRVyuRWgQiI+Y79lXz7hnomK/mIiEWZvwEMiLlkqtSv8AYXdRHzF5MreXMhETOe4yq9Zv
9oxPTLLdG1/sHupzl+465F7hHomc0UZOSym/sYEib2n9tfu0fdTnL9xV+/N70TEfyGRHrMa7gKMV
OVpuuQEVje8iPmO5DhNdynFTx7N25Hrg/wC6gOnZsuSpX/tY4yc5q82Qmu5mKmzSIoXNf5I3owUY
ydyfu5YH7EedvcnO5jhovI504oVHgVju+x6DBFOnOejnPgfbTyG96e7uMhtXlIOiN7yEjqxySBl4
BiyE3shue+t+01ZDe9YfdZCY5Hy5DVTvISO8T1M0vaBClIuT2OeSu+yzyG+RY/eZCE5hpklrcUyF
D47u93u2GHLRWzxq4tevjs1MZHqTEylejJPe78ZYr+64/ajwJiOZYge8lenjiZNb5c5PIZXAcM8+
ajV8juBJAe4pJKCjwJjXDso7jvgfxY457fNmp5Q6yK+MexnI1yH7ofpz0MaS0Ia2waQNnCdIJB/i
x22LfOmN8sVbCWIa0sWjRklJIFq3+TIlJHDVWTCMtK900sZfCCO0b9QmtSwBV1vgPtLNosFMbJB9
HVJUmW2MGotWESyrvOJFRIEaLYNLY3cbz4tDSEriagkN8OrqXSS1YOzF1PSvkFkh7L0xMjs7r9NR
0CLV8NZINlGul4u624+/FsQuiyaWP3pUJvCHquGrZUdnN+mo6AbrGN5MapegJkaQ00RdOsSf30BB
qFEVLqnWeWHp8I0Gg66fbAZZRomlxAzUEQEcQXcn6XgoNNQR0lRtPzGDS6oWWha0P01tpc9maCQO
3jBgigZJvGnnCRCVy6W5yX00ccesDEfIm6WGYsEf07I0xkubawfOHC0uONkyEAL2N51zdMp331cZ
saczsT9KQFM87P4pjEorCKQdvG8Qdc3UN6spc39G/VfbN/f5x+H+d80/beM7myUBzGNsByGihfW1
WwLIYeNWtaEktWkaEQhIyQxhL+Q3s6ZkcXXUpihhIhZYyjjit7bvuI73VcX1fHoTKqcsV0OwZLGr
xgSxt+Lq22QyfaywtEC2Jd/dYUZ2yZbQMJcuQ0SaySNXjAywtVR9fao/EcPJ9ijGxrj7rCjkNkS2
BaS3+7CnskscRgksLXhldbo9UeLJ1jwbFuvvNMI7TS2Cae52LCsGSWqUYksLTg6utkevMWTLBBJH
uuMlhhnYeY0bT2+xIdgyQNxWDSdacMrbdCZzZkueg0BcI2QKQwrTSkE2RcbEh2TJLFKxiWlpwbIJ
zcuJ7LS23YUMhhmGlNGkm3+7CsWSBqVrcsLVGLV26Pb32cJc9BNjXG0gchhWnltG01v96JYNkMeZ
rcsLVG5V26K3ut2m2SBbDutislMI08xo2yLhUPDsmShqdESytcqrhHJ3mZPskE2HdqM7ZTSNkzmA
Ga4XvwbNkkayGtSwtv31VshM8hFSxtEElfdqI7JbS5LntCx1w/vwrNsphJKMSytubqq554khNrO2
QbYFyoiBmtKydYNjts5qyXuxFwBVG6ouuaIfLW4/bXXLhEBNQrZ9o0DVtSIersklDPYNEOytnSCV
l1vnlt2trvfK+2cIgJ7His7doUSxJ5FbbNOOVYsCGytXnLT3S46yY1Le57i19o6MWPaDIO0u2Nb5
r0NVXTHil3YxhsLBZJKi4UGOuY7WW1ysjIFm+KSJeAcK2vUcjZj2krL4aMl6hCwc2f3y1FwsfP1H
E42dw6W6HPdGNF1GBA2moe82JZOAcGpovaXUsVmW9x5mU9xGiM/VsXJupohGzjd8n4yKXtEhasAA
djqkUtj3I4tRqFkBDazG9LCUks9XY+ARNbN43F19RbFKoCxNXOCOdqp8lnc3JXamLAx2uHuybqB8
tldqQte39alx+uSqki5fKNH1dJAMmspDmWFk6c9ruKwtUyITDawkEYK0IE36ymYfVkozXyHFfBup
MB0rUsuSjZCoQOq5oB/q+euP1XOI1lgYZP1fPahdTzToCwMAn6qn7fqqcuSL2UZBalmAD+qZ+xdR
zStIRXvh2R4T3almKw8t8l0e0kxFPfTDNevJVzbr89d8+MX36Pw/92Derci25woswji/WJDh953d
baSO2K1MDPrkrFu5C59RkKsmwNKQElY+GspB0EdwnPtTlY5cd1X46J6V6NXbIlgSPi3Mg2Ge5yhk
qBUupPGRJIbEercFbGDhrEp0VV3DYPFjriQ9pCuJgzuG5lvJahZRDZyVFHaHChLKSfHOduGc8OfX
CvaaSpVHKUWCvDtQ8whsaTZQWhxYSzKXCP8A3BnODn1syoeQpFZIcxw7kzUkTnnzmu4bMwsLZlKj
iOVQzSBz6xIVpyvJgzuGo7yQxp55DZ3FRY9uUOEtynR5FcsecQOOuTuachC45cVc3wb+Cxrc4MNa
mMjyquR5pA4t1Ic0p3EcKU4bm3Z2skTySM7nFY9uYOGszGRxd8jzyAV10Z6FO57hyXDeO7kIkma8
uITAWpw4azIdHGXcE4gHOuDvQxVc5h3MVl5J4nlvLncXI9ocLT2Jj4plyPMLHV9tKIjzq5RSFY5t
xJch5LyK167jsJIkNNOTFKqrHlmBj7KU5CFVyiK5qpYTFaaQ9yteu4p8saHlHKjn74vRPZRFVi+X
Ldhe7iP2wcmTsRZL0VcCcjVV0xyE5YMi41ZbsM0qKNr3K0E9uFHJRGcnOZDlLjok1qF5NVpds8h2
OfnPBI9yvhymo1qvc2tlOx1XPahGPE4QnnV9VKYhGuHiOwUQxsNHOHARCysbp+c7P0/OyRXnjYCr
OfF07MXDQDx8BTyZDf03Lx+m5jEMEkdWbkxlNIM0oSR3hivkY7TstrJIXxnb++2+J7Y1Mi1BZmSK
KUHF9nRYb5Ck02drTgfHIMLiqLTxTtm1Z4eN3VYlQSZkjTx46cP3xYDpCu00XjKikikAJ5Hh02U7
J9OaC1Gq7INEWW2TpswWPHwWDXPkuJpV/bmRiQSx47jkBpZ8hllSlgo1qudX0D5WS9LnE0jFG6DW
EmK7ST+E+CWDIjR3HeDSpCttac0DGsVxK/TxJjZmlzBY4TmOrqokxTaOejZ8F8AsSG+UQOknGFaU
Ra9omKVYOmnyWTtJkCwrFGq/0He+O6OyR8/ORAOK+LRfZlw2jktpUcE8FWyRUnIUWoR5HUbWolOx
U+kfdlUezI1b3jy6XshDH5y/ozXClwlC5zdvVt0/OJ0+MRcrYSzChomoywqEFiA5FhUf25lOiMmA
7S1NSpkWmbwnwOwsGEsowqNrWz6vt5Bo+SfSBpkio/bGqFIVtMFjXVDFSwr+0rk2XN891Wop3ylm
0qBFBqVkEbTDa11MxyWFUoMq6TuI6kH259cocZHc8kHT32LOB42U1Shx/RxNx9cBMkQUeSNRDYxa
sK5Op1a2BRIrfpYm5Jp0VkakUpWU4Ro6qY/Eo0cdtMFjUrBKs2nawU0PB64mQ4bpRIlEIbZdOnCT
CcMlbSbo6nHwsaxQLW06yFHTD2sqjhgoLzSItKwbJtO1WHgOG+rpUUZKhitsaxQuqad0lyVI8sqb
ikWsIc0anGNk2mRzTQnsNWUjWMJUsIllWOAtPTd3PpY9rGlRuQq15jR6tgxzqlCMNXlbJraZBsPV
MKy0q/Hyur3SSxqFqAuYXYfV1zpTo1YwbJ9O0jHVhPJq6ZomGrBkSyqXBfT02Or2uba0nHKuqfIK
GuYMdhTNKyZDdFI7omVULySR6lAin04jCPC7UuoqERh4CPbc1yRXUNU0mOgoNLyoZ26aH5B49agB
zaoRR1dGiYoVHj4DTDWpGKYKOg2NjIbL+mG0at2X3xUwQe66ioeSz6lBxKuqQ07w0jMGxJC3tI1y
U9I0LewNcvqJrxQIDjyKiia0OrISAHpAYyJI7A2xO3JW6gNRkUMcIWHjPJMrWFFVCCIEiVGE6GMU
lmrojQlo6dTui1IxR9SREWzqadscPcApNQUTZIijUb2+2bZSVnmEDFHAENRTWXWn+Eqpp2xwslgc
W/pGyw0FDhjhhJKhDsI0fTytsRiZXCjGDYMutO8ZdXVNhhbZifIu6ZJYqOkyTZCr2yIo7GNE085s
5WsrAwJ4rMV7pv8AlV1YyBHS7G6XeUiTg6foe0k+4FWuUA7WLE07xsHuZUhr7VloO703vLgVyQI7
NQCJNuahk+PRULQMn3o695BstIkLTrUspJh1IKm1bagudOosyNASvBG1CM8y8pUsQUlG2MGxvmV5
XAbZw63TqDnzZbKgVVZttBavpPG6r6dsXHJm2OT2kpiJmmK9DZMVsIBp3fnV5UkRnUyEkSGpHBVT
O7OkuVogy1aseQ0x1jNIJlW1km0FtGM7sy6Wa2Wy4rEQcpvF6/0U6om+aRioseS/sZOkiKCsB3bX
toMJZbMs2IQ1THRkM8jtLbPaRmmIqcZH2cIdhsCxrRSDkaViI8B5LIryWm6wHL2rpiPwNE4+Lp32
mVKhyqp1O+BEaJLQSdupAiMnvUSV73FHJiNMRQoFg5PItlAa8FdGGM0NrXC1KNEHp/2jzyuYhJp0
yqMso5W8RxSPcc4muawSIyQV7DMTuCAFo1nuViVqq9s7+OpbhrWVlksg81U7Fov3XY1M01Xt7JnI
HI20lhqprzuCgWBP3CTq9CsjQkAIh+298ZDBiVjWEkL2Mir5IiVjVkPD2GRi9wkyvQjY8NAjfI7b
yR0OKLXoxx3djI20ljq1vkEH2WRZHdfNr0IgIaBESRwI+MhhxK9rXS3dhYyJIa6uTvlYgBxD94lv
BRQ0ydgkbioNTMRDUUNEBLL2XQ/5LPp6eTIakccM3dWdC3wcZBBWUqSSRUKKFXI3J5XBfERJItSR
OOO+canvpaHuSePtBPYI1BC8ydGicYs2X462clJTtNw+Ma1coHWVg1wtMwtzzw8IpLHbKt7SRrOI
Uh64TmR7ia2OdlkawWpGoEuDIXIVGxieADLKhGZtJRqqw2JHyzTnDovtzbaN5gaGrdCLOXk4jO1F
A4vmlAhIbXjh21LNaYWtF3FX2ZK9H2EifmmYixl1BORoI9ieeSFRjYaU7sxrC4kjlRxEsSVqeJEn
BS2lgheCKIXuBs46rcSh9uFHjF89wkfDt2duftjU3zRQUcmoGqo6GO6Oa0AjllD4QY0N6yu3vBqh
tQdxFdKn0rFQAGJ9U1IzllJCWGW2YmSU4wo1WvlIz/r6hidu4hLMsaMXbCBn/ZalD5DaOH4ZbduS
m/wYdb97besqU2i2ld5llRDQQxNT6pqUPeSor0gut9ucpONdX1jUPt/1lU3aNYVqTLOmHwEBn/Z6
mAhh1EBK5bln75yfwKyqGN5P/Mrf9KZXMl2lUPiKG3/s9SgQ46mIkQ2ufau9G/Rc36LnyrviViZo
z/W1I3cBM0xK3cJqKPUBFQen/wBksiJ27P8AYzT5nlOWR22RJDC5cLuCf/n0mu57b90Wan339dv6
Ivd2mkTs2SJ2ZxlQunHJ3nInauX9t0EnekV+ygu9kQshVfp1E7Vjt2jSHCmQd+yfgjk/x3THEdV1
SDSRJQDYpvNmEYgW/UA9yWo5OQRNYwX98wfIcJP3ydlSMqK3/wDqSG/sYNPKkf4LEzo56g6ljahT
cdPMQTDGTPGQiMhdiSv+Jm3M6bMB/abjzb/YWZ2jvlNK2Hl7/YOO6UWBDbEDPn8GTS8iL85pr3iz
2plYmOT90tv2ozU7703YjdwSWIpIqfZjs+5YMTesbxxzfuT2JwAxO6VPtIn8c7NzRkTsR2pzsERH
VTdlcn3bBicIjU75f7OP8c7U7sb/AF4zP3WDf31KImOT71iiI2E1ENaJ/HdJcKbVEV0XUv8AfQe8
ec1FJToiNRqeRa7bQdu/MT2Mn8ZUb3hp/Fhe456J3afZR6oTCJ+7B/OlHI5LNyeJcG2PQFR0qIqe
PqQqMcI25tPOTx9Ska1hzbv0oRqttHt8KabnMo+SRp8kQjRX8g3sN55FXWtjss7FsRldIWdYlZ2I
svUZo8l96AqU0pPHafuklJ/FiC5TbU7IwqiwFMfMF9yV7RmFa0pPaHbu2sNKf62sf8LEzT1ShMny
GVorOyfKJX2DYhKy9FIfMDziSR87SpqmhBe3XjZpyxahfqQjJCVqhsHN8+cu0OPPapd/4t372K43
NGL+3UZO22mMhpNm/Ji/wYk9qmVdodXsobOwSJaU5UUIF3tNUP7A6eR5RrZ6ZLX+BAsOclXbQqdU
UVnP8S5pX8wBen1PVT1HHopXlPuHpk3/AEKuc9x3P4wap24LaY+JcUrt2Ae36pqsjxBpJrpi25Uy
Yv8A19VOK6Q4ifTqon8O2mmhXVQ7+NEKn1XV5CMj0El8rLYyc7Fd4dHMOpTERtfWvT6fayTx7usf
tFgO/wC11a4iRtPnfJzXBP8Art/ZV9CdNsdi9Hrkj5zRh+IbxndCeMrCafhdlPLazLQKHHTx1HOk
79lyEkOq4XjGs/aPT2K+VOdyi2H+xpkCidalRsaY7cjui4no/HoRds0Wruza79qYv3dPud9QIv2L
nfuMVWvqVXw77fYvzpNzlZa78H7+fE/17RS9+N/rLDaUh/sskMNLfTwnRTzPcUmK98jx5EfA3agy
puEmllP3DBXLRVRlK96se5GuM7mKIx3lSSI0VpyMajGqRrsavQcYr1c2ULKLuqNyJ3JX+KK4qzH+
7G7duyUqGiruC6XZ4yS1Wo7jA3JUUdANCkmfZFZSnPeR2+L002dEDPRXpBTghJCI6S7uCijVpCGR
rByEcE4nLJC/tijyPuWCc8gp2sJJTuSn90UcateY/EYzcgPY7yBE7YY8lO5YNV6wPtK6UiFmO7oo
YnNeeSiI2TyEQSqQZu0CNMTnOYpHwPs46U3vTV7w4gVY+1l/Y8ckiZUjcyPqGKQuUJuIJY1e+v8A
sN81qSpn32QxKMs2Ztnkd0PjO7yn7UeBMRzJ4nFLXL4wdSHQjn/3bYzNIhJztWL4dsjmSqUDyyYz
FSJqgT0eBikLp0ThR9Uhc5rv7tJxn9y3C5Yktrg2NO9Fh3teSSSpEsaN2Eky50dRh+imkmj1jYUg
38iNK01IJMNRsjiWaeK+gPKlEl7+HVuUUu9jLNDpysfXPtJbRYyU2QD6ZxmWcxoo/i/VJWn4XiB1
PWLOSVCdXn01x8PWT1Ra5vdf9ADJBXaX8KTMOg4olR92JUSDfE/mtIqZWfePUs7UO8Tx5kexbOjC
p2Nk2tsOIGeXvSN8bmnLZIjpCDshQYra1tneIpYNiydHZUiHItrhsdlFdI/JdcGfkiSyviR9Rf8A
YkUdkKNGHXpZ33I1dbMnASsEw9xeJDHp+8RVlV4JuS5rK2LH1Go7LkOxAIAa0dvqFxD1Vy2xj/Tx
iJcagSMmn9QfvLADLybPbWhDqIg7ELx2oHDFXMs9QEKapumTQ+CEZbm78XKC/VjiwBS22loOtjRt
RFZOjPFaif2q4FnfvknqLptiJYQgFur9Rv05eua58QUllvaMghiX5xzIrgWg5hB1ke8t3WL+q+p3
zi/B+lPYrEJHntlgtGtbIgyWMj2FyrZsaawgI6sbJMdqjA0bcdMYw1rOZ41NIRljLmMWHv350QjA
At7hX49/uq4vX5zb1tTddPPYAU47CCsfYmnOLSeSxRXeyvhtR8mDJYgbgjXskL9yheMIZh2uHN/Z
Kq7JjhPQZcJMaNkKc1cM9hEEgx5IOwRBS2GHwYj7B7OMtf36bcwCFksUQZqCOpWFxpWCSfZo3K+2
aVnea1tjaIxK5WlJEM1g5r2vZHIMZlaJyMM0LT2aMcGawwkc1qyZ7Wth2LX49zHKSa1jZUhppEVr
OJZKDbaWPcWhltClpMRRzH7vdi4ntlTaLHfGmsOwspBtmW/7622acZTtTLC1QaV1ynJJDHJLsEG0
FwrTgnMOwstBtl2y92BatMNxkTLC34ZV3Xv32vyfYoFsa3VpgzWGYeWgkk3C92BZtOJx0ZlnbZWX
W+d9u0+zaJkW4cw4JrTskzUC2TdcSV1o043yeKW9srspSK7I8xWMsSq9BWPiHFMQzZU9ANJbv8iB
aNOw0vg2xtnOyou+WJJTLS34JAuXxzBnoVk2zZHbPmqd7nb584z2XTshWMmTu6K5VrzafLscVg1A
3shH5BVGmrZrRCupzSCOqd+gkoMcyzY8NoRCGo7nZnkjeh7ZgBV1yiy1shFaycAeWVsNqwLgZgun
x0y0vh9shFc/T84AEkX8dw3XTRSxXMZzfrEUaW1wshae67T36gjIlrbOlOpZYQFBfxBNk6hiES2k
Nkvqb5kaPeWqT3xSqB8HUgeLtSQsstReQ0Mjtn/VYmgnG8k2+VUxsQotYAYy3vWTm1l14Cv1aJ7b
KyfLcuJiLgiKmQNSuhtmapWS0x1e+st3wHE1fzbLnOkvjS3BILVpBjsbok3EL+6BqQ9e2Zqg8tqm
VXxbIkRztXmI2VKWUQJ3CUWqpYBTbcs1EdusTUEqCkrUMqW1X+8WaSNi6omlSQdTEEZw1ZqWcAc2
0NMRHKuRbiXByRey5aK/9wZbwY/UUx6FO4zxlVuDu5oRyZxpKIuygspEbD2kiQm/uGQ8WPuZT0K9
SvGRWY20ksaeWSTiYycaPhbI5Ud7r+fWvy5Ns3xfiR74uMVd4s6QHCyzFVlhIa0j3vI2fIY1k06Z
9Rlrn1GXjpR9yyzkRj3Mc6dJVvdcjvMk8Skc5Vxf6Hz1TEXAWJx59SlvQr3vUEl4VS2lrhpBS4j1
Y4FlJw06QTHqvIM8gs+pS3ocxC4OSQSjuJOFsjvxLAg8HcyVx1rI2JYEdg7Iw1+tS1Q08xMcquUB
jCX6vJTHznvcO3OzH3EpUPJcXAyXsX6pI4nO4uDlOErLiTj7iRj573uBbyW4+1kbFmPcoLYws+tS
HYaxITBznjwdzJVC2kh6Okqjg25xIWzkkQr91FIePHTZBENy3VerVyPYmDjrSSZpCryFNeFfrEly
GIR+MNwwVtIa08gxk7i8o9mYGEsJJmkI7ePIKzPqcxyGK9yiK5F8+YNpznKncVMDZlBhrQxkUqrg
JjwqtrJNh3uXBOcmebM4mcd+clRY8uU3DS5D8cRcjkkIjpk9UNzyOY7MZPnIhbGWmKRSOCWU1p5E
pc3VVB5TccSaqFc7k0itxsySTDd/Ecu4lm5IU6NV3uufGJgZRG4iTjIYRmYIisUTpZsNElpm6tcE
p3Y6DMehWOGrHuxkeYVJEcw8jBKbPpU/YsKWHG81eOrnPR1VOHhUKJe5uvdXFevQIHlx9ZKE0Y3P
UdFKKhKCWJCheFY8R51Jp+UPCjeJW77xqwslJMIkTI1aSYn6bkZ+lZOHqTRcjUhpbf0rJTJVeWJk
StJMxdLyMkackAZsrVRds5ZGC6S9dMH4S45YZHe/oG1VyLQklNmadPFHsqZBq3S8LpMvGSB8QkaO
6Q5ml3GZY1Bq/BjVyw9POltl6ZJHZx2WBUul4bSHFsqISGWJEdIcPSndHZUpK/Gic90LTj5Q52ly
xxcVR1dTkl4fRy8JcEkMkGE+UQek0eO2oS1+BCpHV+l3SWWGlnBa4LmOq6MkvC6MRUsID4EiBXPl
kHpDkO50+WtSOBTug6W8gdlpRwQIFyOq9PkmNPo32nQXwZNXVumEbpJqivKMlelBQ/U22Okewxfb
HLvievbo/wB8+cXJKL0ix3FfWUn2rWCkdYdM0g7CvUR4VJzEysYh/ojOKVLFwtQndLRN7TqtUlEp
EQBwbSYtU0gLCrUOEZwVff8AoJ036MTktPSqVv0dnCfWKNYFY6QUNKxqT6ZUTwXOLBpGMHIqGqyZ
Acx9XR9zPo4+NhVqzIVUskg6UbGzqnZvgPcSFSNGKRUpwmQXMfU0vPFqWcbGr7eQax8gw6gaJOqf
Z0J6lh0jWMkVCOZMr1GSrpOWfSh8LGsUeQat0goacbEnVXt9PI80GmaMUmqarJsBw1qqP2dVMVs+
q7eQKl0ggqkaZOqNk+mvIaFSMEORUNVs+vUb6ij/AGOqmK2yq+GFFwXb3xuUdN3WfSW8LWrQK1dd
5ZRVA2jsKtvDxN5FfTsGKTUteyfD7JKenR6Oq0Vh6VCFDUsCPxGvyfTNc2vphBZ4jEWTVIQdjF8c
i7579IMR8slfRIwVrVI0ldToJnYTJVShBtpVdMBWsG2XVNIxtNtKDFYNqA7uWNGxyQK0YGJH3dMq
WlGyhV8mPBQbJ1W0rItIvlMg9hjYndy3p2tYGI4pqai4su6vtjrqhZBwxEEOfUtMOyguiP608FJJ
I9b2hzq0ZWFhcJtVUo0RoLHNva9scunqxDtfBRiXVWJ46OF3jirUCOXXjOyqomswgUC5YDTDSrEG
d4zWNEBps1DUs7KifugTLjmObkeM4y0NEu1pUtDGpqtCSTxRxkAwUnLumR6VdM2OLgLL2kR7Kuv8
iRV0bGA1fDaJNIwmGDYNBFxbSFivHOkeCKLGFNikPPq2mBT1LGCl2ESMcMdkmPqWv7MxKmW9Fq5T
ErCNFKrmDPH1jXk8lU6J8tzT9R5akaOsEHhNFZ6eRJkGvbXgFZCknvaFp2UVIjGSbMUV82EyxjVm
nGtmyCiqQwpA7UVrptvmxK9tdHi3I5Eq8o2yWUdG0YpVuOKWRDZaRa7Tfbmz5LKkFbKZahs9Ot84
cJtdHhXw5Ey9o2yx0dK2OCwu2QykiMtYdVp1Gy5sxlUOolttw2unWJOWI2tjV+oGy5t5RNmipqds
eLN1C2NJNFZZQqrTzWTbSxHUDqJn1cM+iYk+QFtUCtvvMl3tIyW2orGxYcvUCx5hogrGFUsfX29k
HvRLGhNExU9/j1bdVxUxclr00pE8ghWNixrWf5EmhmtMGRVNO97UihZO7lq5VUXkEG9kxCyAjR4j
VqOPLBwi2qcJlDYd5bKE0gLAXAz02/oonWjj+TObHSOBk370yIwrYVe0LTyey8SJKEKtb5En7LYZ
vIWTWtKXsdgLZn3pUVphQ4DQDPIULxNSQINa1p5S9lsI/lOkV7SE7XZH5a92TEaUUOA0LTn7Thoh
whrmoeR9psQvfWTXtebsIEbJH3JMZDDiQGiYc3aUY0kCDWo0p/tJEN5GSq9pCdhBCZI+7KiNKyLD
aJhjdlzGJJEGvRpZH2Uhv8jJVc0pex2Rtk/dmREIC0jdsq9AMV5qeNsCUXs5bmQrNNxt2yWdhsyS
1zIAe9YCj8QSJSMyeiFk00T7UsnYcErCkOz7Ufu92WxO06wGHIkoslzyoo5MDypA6KO1pqUPE9K7
vVNU2MyENNrgaLIjMRQmQ3dGnIAIqKSY7sZD/kstGJGVLZH5WqRqWclrWBs2LgfIIRG/x48blk0n
YdC/lD8dozy2qoq4B2yLeMjgQadBvr2dvNRN5spYewbB6jyEnkj1LERuKnRibrpOF++ePtx5VkiJ
FZ5s6HFRIk6X4r7CQkoumoaDi3DljvsLPm3S0Rqnsg8IxLPtuqydwFpA754A+1EurDxDDkHsSVov
EbayElPg03aY6PyS0pBGHR0PtGZ462yK+HSbiPcQmTR0Na2I+bs4slnaiRmkSXLEjoQpI4VnSTUk
A1uvtpEjWxruOGbhNMhVKqCSumn+/FjUoBS57+0GtJuydUBkyowvHhlg/Upg6rsjWu7iXtMkWTp9
P4k8IzEvtOqzNtlxmaRYnj6lH3VoYqxzWI0Qtqm8GvhKMspqLEr0/hza1JU+oGjIsJv/AGGpY/kp
QxPEkWifetm7wayv7WSW/wASuTavlVaSrSnYg4cFN7LU0bynUUXxpNmn3blu8WvgIHJifw4Cf9UW
Ckmzp2okKuT/ALbUcZp3UkRIcu22716n8atgMCyZ/qwk2qHwWHtatP8Ar6z2ttQxmSHUoEBNnt+9
ftRR1UMYgT0+1G/8ZkEciygf+aNP+9nyvEjj7dzE1DTrXFT+gvt0VMXJXTRa/vt/9aV7H04VWEif
vHeKrWQEVLZu3YsHtRlYR7rNDKMMSc0j57kdHuU+/p1f+wkp/Gt/85MVM+P6KZpP/wBUqfY7aeYq
chjT9s4abQU2C3+6c3daxqI9f7jp9tzE8rb7Y0/ZPaiJCTYA095rEyt2R7k3cb/G9qeSn+NjU4zm
ptEb9oSbOnImV/yqfuM37aonlN/xs/tnIiZD9hDTd05iZWptj/75CfZRqeT/AP02J+2a1N4KcWCT
d1ixEyuRMftvIT7LGp5L0/jXqbEJ0rFRJNN/hvPiVJVr9Ou5jsl+zZmURKEvI43J4t29RuiSN5FR
7Cv3e1QRz5Cv3EL/ACT/APXZXLJOITQjsbDg2mZ5Ap5mxUZbBMouHeE8bWQn8suGfdiJxGV6d5n+
KIn77FEV9Tsi34u5lbVoHClQLLSz7qxDo0sAjFxP8MJPax27lR8W8jxiCsxnZXvY4ll/jjnYNsQ3
Mty37NWn2bBPuVCbi1V749vHo350m9rm2j2+JcSPv6eK1p4r/wCHqeQjSRifyNPkaotUlRMOTmXS
Z2Py2KiRJkjuzaRjuxPngjlik7se4r3SpcGA2IO0tUitpSeVMlfYhSb40eWt+E+VU5rQDP3CTv3R
q4aklW0xkRlNYtnLKH92xT+GI6d+Z/q2/tY6WT+HrT3yruHV7U1g3KWd9UyTDTvSV8SDDvPIlzw7
irRcB2F66PMgu8iHACiSriSOOg7oA0ubVkpaJNoUiU5lrbR2rEns4TU9sZmktuxqYvYJRn7xrJyO
Nar/AAKyepllORI1YqOiTJ/i2Fa/+JBenn6rK+MtBI75bEid64/0KqW8qy3okatc10CVNLHta0nG
FXkb9S1cQkdNNnccliRvdu3bw6OUUyziNbHrnI6umSix7qtfwhVxWpZ6wIUTdOGIc1oVO9eL3IdE
eQ580zexAIj6mQ+SG7gr26+uMiWOrkP29Ove5Zh072ot3xNPKdWWBm8IbudSqyxX0de3XxV7t3qX
dIGk0XNeL/H2xem+b7Zv1VcXp85JxfnSR0GacvkR7CMoy6agbN8tsfJaJKH4qis+K+KdhCnjQO0c
3+sCcQdqR/MNx/sadiqsqWVGRrUnI71916behE9vRp0qBsu6hQtERZ7yIwYTNelix78ifaCyQ3nM
/e2sG5mFOjXqVCC7LllOKjGCOipYCcRQfbC2SiOmLzbWCcNCnRrlL3RMC9ZjjIjRnR2TxuIoPtiZ
JbymLzbXDUTXnRHKXuDQT1kqRGtHIR2TROIoF7Y2yUR0xVe2vYrGkOjVeXuCEBySu5xYKSi5NY4j
gP7bGSkR01ylbAGomkkoiuL3BCC5sgp0aG7fyK/pH3UtHv4961yNk/5NLI5GWnLs2SL3KFrlnJv4
t6ju4FFU9KjuxqFjttPLtIk/uFHEZkwqooRRcmtI1FqHPynH2G3IHGQVIRqnRYbgagIq00lxUtXq
j470WPNiHdJiftjBlIhZzFK6GvYQq98jovFkyGeUSRRNTGUTFSLSyASAfsiR5KI6aHuugr4zdQSe
eCpZEjKWA6CtvN2G69O1aCUaRlwruxVyuLZYlM+GvjC1FKR2E+ca330mByPt2cotsJRSKGM4smOx
UiamjO5Q28jadAo4+qwOexGry0jGVmW4FWFJaoLGnOjoNtWeaSuZ40UQ2yJdnF+2Kgc94K9sM53o
eMfTqEkyqpoBOkkCXTXcOae3lDqX+Oa5iJYjoq36dlnOaMjZiSQjr0Ge5s2hBHittJNFESNH1HXt
m5WVnbLK06AzaWA2vSXNakmQ9sqHEpBR5VlNQQa2YxwJ1IKTLjqkSNAsWulXsVlkkLTow5bgHGPS
EasI8AazLiWjIU53OXjFzT1146GQdi0farRTtRtfKgz2WEccEMd95qBAJSXqPwsCPKWzs2Vkev1E
qS1cOwG1Q1gZuoVfMrrRtgFIQgPvNQdtaG7/AGvhALlrbsgR67UL2Sm9uyCV46wE2/IaZVWjbISx
gxnXmonctP6gwkURUurlkAVfflZJA8VkGRIHVhmXhpEynt0sAlCGMtzfue7T19wxQMcy+u0htrrs
gJYChsRT54a6Oa4KeVTXDJ4jqGO67vSnXTl9wwqA7Oob1A5pqXtJmPBJax4K5dS2vnkxfTv6N8Xb
JGLkCU6M+tuGmFecESmljaC7tX86yyRwVON0hJje2x4+UmYxjzWLPF8j/tVsmLFsTISXXFGINvbY
UqvcvyuLm/8ARAVRPp7j2SYPjY2uyQrpWEDPEZJti1jXW7kNBtGkGWYxjZ9o7lW3G+JKZ27Cy4JD
ula8M4RkmT0Y1bd/eg2jDMLMaxJ1ps6uuEVfLG5s+z4ZDulQgJwjJMsGsR9wrTQrJhmGlNa2fau5
Vlzviy2cJ9mjMi3CoYM5hWy56Daty9Dw7NhmGltZlhbu51tujkWSzjPsuGQrhe6KawuS56Caty7v
QrNhhlltGk62/dXW6ORZLVSxs+DZh1I93v0rlRJNXMRo7eR3GSf3EpJaMZMloQds799CZAqyaihu
35XPRkmvmbCtz9xgJfjyY1ikkavVqmsUYkOya9pSc1cVqNZZNDI8jvNe/ZLmQNcjGRpqqbwZZylI
yBao5qn5YaegWPt+EqPYNOyVYNC2NcbyPN7o0flgdqDgzhFTntkuyQI2XPCTGnNOOdZNA2RYd80D
3YSW0LLa1cbGm/fRy+A7CwR4m2fYkAsGkZYW7RNnTFO5eg/ZdPSmMHMsWEHbER5NPGahWWomhu5j
SLBeg5NbZBEK5sRqMpE71FPCwUy3A8NgdpCUt2jRJZRXJMuhBDXXzO+tzGIjbeKPLG+Yj4N+AonX
MRMs79qte/m6is48cZtSRijbedmQzUcNcfqGMxLG3WS+nu+wpdUR+3Y2TpS0llGh4zVcVrTaoivR
tyopLNVRHIXVkZGSLYhDwtVMEN2ro+1jerLStv8Aw8/VwNpup0lNjWjwGbrJqYXV7XJLsXSCwNWO
iBLrT2srp83FXfomDIrFh6qNEFN1CWc3uLvBuSQFNqs52HluM6PLcB36ultHNtCTMYZUdG1HJhsl
3x5bee+Q7I8RxdSzDNNIcVwZDx4mppjGSpxJSo/AXkiKki5kSs39wTCxVffySI8ykcwqsxl3LRsm
UWQ5jtsFZSIzS2Jzt5e45JQq6zkvRz+TmOVM+oyeJDvfnLlgphAoWWQ2NXGFczHTzOxSb4Mjs8mS
1CFeXGcs80+yzTLjncs/K+hOv5d7Yv8Ac72yQuO+U9silKxDFORBGkJhFIqjKZMR5sYabnemY551
Vxjri8t0JIVr91VppOz1Iqri++L136J0/O3Xf3EZWKOZKXCNK7FVWOZKO3HOkPa7duDkkbnflvwn
PdplG5sw7kf3nIm+7HymY58h2PRdw95uKSWuF5riGcNWWJkwkpxMQipg5pWY4xy47dFC4653pitJ
z3Y9zVZIlKhnEXE5K4JpQ8ISUTH7pgXSGop5jkLyXBd3ELNwymdikVqinnTCmkGa9VaoZZWL5Upz
SvVVD3kxp5jkP33YT5d0Y5W5GnysIeUrSPXePMMzElTHNkEeqikOEo5c1zZJDqiP2WNLl4U8tyPd
s6PLOmd+cqSJZN2TzNxp5zkfPkjx0pz1FLmqjpEtuGKr8E1Xq3zRYSebYckuMJOchzyM7m6g8veQ
knO6rFCeSTH+axDyzYIpd2pN2Oc6KhN3ADMVDNksxz3co6Si4YEzgTfI1eaQv0yc1T+ZHzm56hgT
StkhkBx69EzlglduOvnSGyYJxYxVTARJEjC1UoeK1w3AaQuLSTH4eOQDxI52BpZR2yK6RGWNBfJx
umzuQ9LIAghKZ4tPyCIWgljw4Sx3c87uyKTfpGiOk5IpTBECOp3C0wV6F0udiGjkA+LXklY/S5Ea
cLo5GNVVj0pJCTIT4WQahZqfpZcXS26Tax8HEeqZzxVxFyJXklLK08+KzfZ0GsdLUulV7bq8opEX
TneaulG7WdIWFi+3TbAhUroumvIZP0ySKLivKvpVlIbR6K2TFfDJAgLMVmkmEFa0xKxYwXGdE0yk
hllpbsDQao6toVlIfR6cZcMsQ1dVllk/SA3CuKIta+LGfJWHpbvDtNKqELRO3q9POlIfRzXNlwnw
5FVVvnPTSIu1eUD658SG6Q6HpLmO10l2RKBWkqNOLJSXpBvGfCdCNT07pjl0qxRXtESsJBgukkia
UG8dxpXsRmRXqao013GH0gJ7ZUAkU9NSLLVdLBUV/Svrj0OnxzR6i0uyFG36r6/yT3xU2xUyTn5C
LuPp6Xk23hMAOnrWyA3FV28qKfcJK9jCjqm8FgD5Hq03+jI4cqmUZhU7exbRuyaugtKOxqVahxcF
VMXNvfbp8dUTpv02yABZB4lO0YplUnGcDtlqqZHDfVs7dpAQWUlZ5bmVLESzrEY0UXvy4dQwY5lU
1WQKfkqQRsRa1pWkpfvMrhDY2Ex+WdX22mF+9RuztuzZcqKd0l5KVrQMq+9LZWDGxITCZY1Gza6l
Rzkrx7WNT7VtQ3EijTFrmkatOiyWQhDRISGyZT+8WnaNiRmJkyp3HNj9p1JGaTJFX9mxj8H0tKpE
l1CME+H3JcKqYIXjIuTKlO3Pjdp69K6G6YaLUDAM1a0jZ9WrH1NMjGrXtVLGo2yupFIVkBqJNqmv
aymcSREqmBbIrmvSdTr3aulaASwmubaVOzaqjXGwm7TqlHNj0riSI0BoWSa5pWTqh3frahoRrC5J
bU2+VNJxVITdrCnR7IdGrpIoDBMk1zSskUrnSK+pYAT4aPbbUm6U9Kg2pCYqWdM0rYFEqmFDa1sm
taVhqJ/lQqxoAuhNe2bQo80OraIHY3fKq0IEFF/JHEaxs2sYcdpXLFf03yih+QQVajBT4Y3idB7c
6sq2oI8VnG+goN+na1pBuhtGl9AYQVBA8iUle0Q5cRhWVdOmxWiCTw2lE2vYKUqAa2MBhV1JWscN
kE5MdVSUwscgchwnSloqJGJd1jAxqSra80xgIaV/Ym5cU7SLAq0iBY4ZF1DSNKylgIWRBqBNjaxA
0K6ViMWNcyI0Bf1DAXLWwFLUdLKOhKOWJOKotbXvkvoaUY01HDYyN2+7O09WtZHkGY2Q6EKRKlIy
DDgXYppr2ua6FJTgffGe66dpkLkyQOqHGVtgGTp9Eshx0rI8S2HOJqCgbISlp2x48i5YyVMgMsId
Jp9Gnsp7KhIZG2IpOnmfUHRmVsWBcJPLqCjadtPUsjwT3zRy5cFk+HSUDRmuLRlOysK22jyaBn1C
QNtXEq7nzTX1Gw2VdWyNDLfcZsuEyzhUdEwci6s/peVRkswGohNnz0bVxKS5dPJfUjDur4DIkBdQ
vWfOgssINNSDG69uVrFpzfUo/wBEEyfbkSqj0Fw+at5TCK8MRsWALUBjWUyG2dXab5APqGCs0Fpp
ssFu2yqnVOu/Vcd8uyUnttmnQeRNaBseLeT1ITTc9MJBSYzx0ijnzd7COvKMbmMjpyOPCRrmSIDC
ufF7YNQD+5TWKtMeO0gLiOgiE9sX+hv0TEzSkbuznj4iNOQeTG+VLhB4x5UjsLbSWmZpiNxiy/s5
PmNeylF3bF4+I5M1GZBVrhz2v2r90j2REFi23JaxCNbZFa9gafuqtMNMl1DWtr6hZBYMZsfJDEQE
diNknZ9uC0ncMNr8QCMY83AhBNeKVISI4Uskp4l7Y58xonfVO46uV7GlMzkio4SoXye3yj2UFTya
mrSIpm/x7IaJMpitdk7j44+P1Ibdw8C+SREWPeDRHkTZUzSkRO1I+ykQncyRAa9yx+2NhV7xoqFC
CFxbIL2nAYhhjgoj5X2cgu72Fgo4j4/aEMv3jxEKIULgyQRWPAJDBFA2fMRRJCXuoWC1SlB2Rxzb
mkxEIwcPiw5VYUYUOKNBRHzlUWQV77XQE70kHYHFKriy4SOayGgxEMrDJHQwI0BN57lE6u+83wU7
80fZFBKriyo3HGDRYz4q9/htHiR0dlkRRvgp5ANTx0a12bY1M0lFa1Z7O3HmWaMyFtLmxgfxrCb4
xJUpJsnTsZEBdO8d9hZ91NJx0QtqPtxy2XF1WTmCyrhyDQx9qJc2LoxY3fsnwGpBFPkJNPDqO0NY
65Z1gTDoqLiMDOw67YpIlIiifcRmSUpIQ4qSf3y7FvbhwROGexCnhRrBsKxqJffj62/yaXOiRLcY
Ziu08AjJdS6HIpq9qR1qe4O8qljyqGnYMAnOaa+GpIcOIo7WnCiRdTp2iVVxyluOkuNBrhCPqBu1
fLT+VgE3fpVn8XUMbyZFDH7GSW/zr5qeJWwEjrZIixwptXJAQsuE3/r6tv37+L5EqkEgSS0RZeoE
/i18JoUs9ljg9qkcFhJUFv8A1tR/sX0ZsuVQAQUiW3+bqRqOj18VoR3H+Jn/AI4YQnSIP/mUzf5F
yFkidRiQUySn8rUrU7ddEYAVz/Z8U0WGB0qN/wCTS+5LcA5E2mZwlE95upEaqV8cYR3P+Qzf+phR
wuOP/wAeiT+bf2KwGiEy4i6hrFrZS/0Fxc+cXJPwuaVdtaSPeHbJ/KpVc2TXf47Vf2GYv1CD/gnE
bxVVWyC/tgFZJ3jFQke/T7lb7Ttt4uoG/dIm2L0XF6L6fjEzSZGop/YdyTZ9cbjKhORY147CE+5p
4jXgs3J27Ai93ThG906p2rt+y6eRyx5JG5Fc0jLhjlyqqUHkgyBY+c48sYkaCVatikJaikMrHCax
rm8vZ4u1/LIuzQFa4j27L/8A05PHyG/4rKGsk0WI2KOZNQTTGfLLV1SAaY6CZKs9yQLpOApTCPTb
sNiIqtcgilfyBd/5tNncsk7t43BfqQF2B3GqQifZu/cj0xPnSX+vMyvROT/dTbdn9qymf4Rf2T0T
lX+zB7c7PZMrm7OcnvKTYQ03kJ/han2pe3cgp9of91ovFa35d/fOT7cfbvu/wp/ikInegp9mP7Ps
9kWr2RXf5rFftxV+8f8AxL/ql270fbx4vzZ7dymxf81t7Dg7d+b/AGM/YB0sKSHe8aCmzZ/uWn9w
6rx/RnzpIzXNtSJ4ltI3laeOiSY7/wCNqeQjTxC8JOnzIodVSEY0hOZdJSEel0dEiGL3p1KNWR7K
0HFNEXvxLOs8qVGhtiDt7XjmnuRZdj9uCa5OCX9dcbK6zH2I0lpDWSt8apGhDX9j4KUM7zkkD4yr
T/SiyEfOsnfwpn/p6c/09aru+utJMRi6qksyjlLPFY17SnWMKLHrZLCj1i5AkgajioGssxSj3RWt
iLK5WlKVXRNaSn95hVRQX0kOUNjJlFvnotdMX+UnvkdNiaYI1IepDrFkURFeM5GrOvV5waeS+QSy
MjQRntdXLKMOfGejYVSZqm1OQgD0TlVJJWum6gVTQaMhiZaGa0EV6Pq2lOKyARA1tLJZ3dULIHJo
Xu2PJas/UG5IdAsgiXMhO2AqEqxJLFaAf2q6llMSRqhkhsugc5qFlM8/U+54mnkkqy5ls4hI01VC
BLHZ9xBV1LJY5dSAkebSKo2pLZ9R1SN8qNp4chGXUwbXc0NV1kSWGyIdoa3TjucnWLFdH079uPr5
28rqvv13zfNsVOi5J+F+dPnQNl3kPEt4XEmnYXJ6ymxR99stllE4zYbf484JHmbXcHImwZ8hwLCK
XnG1D7Ep4KkkkK0Ue7NzKT36/n17dNJtd5p91FcN2MNikkV7eMW9YuF9s0mNWxLVNxTU/fppirOJ
uobxNnadInh2wHFZTDUEcrUM97ODJICSHtq+yRHbhsYTik+jqxr5j4i1lySRIQq9lj9jSl5CgR3s
OR6IjTI9rwq4/e4sExCZLarcfXPkrBq2tM8PFp4hZBJdV2mpCIV1TVmEbvo1oCo7JI17yLuG7Gvd
0/BeMxRcgdhRz09wuiEWYiogL5diP9s/Ol5aMbJ+82MPsYeZsrZHdCOMqFfIRg401HpIF3CBJ2Ws
nJ3Zf3mxm9jDzkR6n7wmB4kJLRjI0xCjOHmQZuyMM/70xFOsb7CmnbPKbvCCHg883tsize4woeRR
n7QwTkU01vfyJ9hTWCNKQvfGEPbdLncWx5iECSPuTye0KJPRzpbO+6K7x0WxRJUkiSBxx9p8qamd
3ugLV7yu4gYsSci5KF3nRn+KPUM1Hufti/Av3ZpKNxy2ajotsFRy9Px+5IC1PH1PG/dBGhzafEgw
aqjoRvFWl0kBBrcsa+Mdnj2VVJRYlpUjmmi7R4sbgc9mFCDj0jVUUVsSQd7ZEYmngkk2dekcDi9o
ulmIr7Pg+LVEbHJagFPyniDgjsbJrJDJiSQihDCW+tmtZXx2TpNSJkeNqCACY6tr0E6TTRD5VAHD
GawTzjlZJjQFbEzVAxTRI5Rk0oxrVtnsLEZCRlzWKwcXV0dkhI7eRa+kCUMOGCC3Ut8i4R3J+DXZ
aK77SOQc1ppIq4Bb9fMhTmzwIMEPL6/5EpLzvsdHE5be6bEFT3rxm5DntkzhVoC6iK+ZWz2WAHrH
iZd6hcZ9De9xHDEi3t+gEp7pwCR3snCs7McAK3hVm1VoOcIpQxm3N8+QSgvvZXAy/wBRdpai6fHk
AlAmCuLoNfG+rFfKqLcMsciXHjJc3L5h9P3/AAw8iMzL6/3WpuHwzgsI08NzdjhgHPI2TUXgJQpd
nFAyytnzzUWoUGhbGEmahvFM/Ss8UVJlnXy3HtoUUdzYOsZHp+cXq7HfLlw6Y5MCRRvprvLOQMoK
OwGNl5acspbXiI80ZSAsBtF5YnLJsGIjbZvas5POVEt2pHupSFJUShCDa2v7DHUiuX+j89Ez86dl
DAn1Maitio9at7RyYdkxBW8phUIn36meMTJs5hBWC/dojtj4tgztXL0I+ntPHxs8ZWvmIxg7VGkb
YjIxpWJkqYzaLbM3U7XJLmNRtgbm+kMgXDsW9uVN4EDZtM3yERJtnxbCuOD22AyNn2XFtdbJs+Q0
ud9jUSexjvOY5jZDMnSBuZDO1rmmRGT7Pt5XXPFzpiEalm1MsSo81dIbsk5EZNM1Hw7Rqt77VyVY
oxtlKQz39Icx0d9ZcNKw81rEn2yqtZdZ5zFbPteOQrZRmHZsM2ZZIJrrZ3fhXDTMPPaJJ1srnVd5
7OmMVtjZ5X3DgvHYNOydaoNqWz2miXDTskz2ibKtXEfV3m7Xz2IllcK5ay5UJGWDCJYW6MwVo9h4
ds07Zdm0bZVo55Ku6RWvsGI2ytletbcKNyWAnNs7f2iWrwkiWw5DZ1s0TS2T3ErbpHsLaDY2XcOe
WtvGFZ5YFyfcjYMNu8cuNbgIKxu2sbMkqd+Lg12WjsQgHKvQPZZyGFfRyhx3JfgQd1YMkLCIgjxL
2KEdvdAO0hOR6a4jgFK1HGeydI7zqm+SM1NRwVSVqQStr9QME92p4mJqaGmT9RIU0TU4UG/VEVqW
WofJzn++pvhRBm1hHKNl24Zv1aDCauC5ky0fIysvfCU+rGvZMmvkvqrxte0etBo02rWmQVw4B2az
TDauR7X2b3Gj6teFhNTO7szUjpguf74WqSxBG1iUjQWrxnTWhkSfemsFC7tvBqyUFkjVUgzDmUzl
Toi7YIrmLH1LMislXhpedxd41tIhYfUMw7Xk5uAcgsXUU7Y8p0lwyKmMu5cdkizLJRHe450iNhbq
SVHEV7hlczFuZaoQ7zK1ypjbCUFpZpCo1cFJKJH2Uh+EXkonuTHSj48iqrHbYkgzMecjsa/GOfjp
JsVd1a1XY6QZEV7n41c+7jyPXEVcb3NnEJirtjX59x2OXbGY7vKjnuxy7+r46/h2LjvfD4T5yOjl
xwjbBGXCCI3BCI7PHMmDjyNvFkbkjH27BtiDcmIIytINyK0RXoQRGI5Oi9E9W+L1GRWYFso2EjGT
H7sULzvXxjuwwVarCETBhklQsZ7MR7h4J0g2PimREG7dgJWKOS1CdxqiSS5EDLwvfbiyHtXzipj5
ZHY5/LGPXcXkKhHETBDkLiAlbSBGTG8kUUeUqFYRuLIIxQyTmx/kDRDGI4QZap2JbcMGS3GDO9Uj
ylw0cuDjHeqRZmeJLwozMwQZOdmZhu+3BMkGVsaa1Dik4XdMVesQJyY6NKa0vJFE15FZGmIh2lTG
clcGLL2kAkMx67LEjnLhIstjS8kWMx5neDLahkIis5ucGDK2kBMPPfIsWQbCxZbEdyasYBjOWBLG
0yOZgWuI8NbLVJEcwVRV3jVkkySK6SHHcmrFhnk4SqlMaYbhYAbzuZTS+EmMUCsRXOBUSDNkV5wI
9dlh1pZOGp5A2ka5rotSaRn6fk5KqjRkYxXPDQHM2TWFjY5Nl6ga8rg0JTNmVBY+Na7lFqSS8kae
INCCcFY0F8pf02ThKgljKFjj5H004jZtGeJkKsdKxNL5J068DQQSvIzTW6E0xxSVEJEdzzn0294V
W+VknTzo4okF0hwdNMXDaXbkuAWKSBSulIfSrUbJiPiPANSui6d8htjXOhEr6Fsxq6ZExyaWEqSq
J4SRtNjex2lQKkqgJGLF0sMo00yBql0mNWzQeGepgsmuPpMfbg1HelfpQDE/TMbLGgCBr0Vrk+Ey
HEdJdE0u1RWumFGNoHISr086SyVpIT2Sob4JaqofNVdKj7d1RFgPgwnySxtL/at9L9oLAPeWq033
2StKDUc2G+HKp6Z0ty6VFte0rq0ldXOmPi6YZ2rnS6CCOIR5qnTXNkvSw3CnQHwi01A6QpNMB4ag
oFr31NY6W6Np0SBu9MNaEEMhDVGmmdqXpYD2S68sWRR6f7im0/HezUNC+uNUU75bw6eAMV9ptvYi
QCHNWUAmMnaajyA2MAlfIixXnfSaXa5usKdkIdHSOmY2oiCDqcMYOL6N8Trvnzi/CpiptknHYJOb
6Sm3SyjMEGijpIy4qk2papXMmw2BfEgscN8QaPkQGcAVLVba03HINSnYvYaAylAMrbCq5MlRlC56
f0Pn0JkQfdPXVLRBlQGObaxkA6gquY/BZxtoCDSmgeWcdc1iWFc3g6N3JcGpaIUivYrItS15nxWC
RkRpmyapO4OKIbBha9bCsRBygK0nikx0cmcF3paVZBFqWoAlahZYoDBMaBrnT6tFZApGoRIjcnVS
OZIgr3aelaNtrV9tlTHap+0NrRiQjplaioKIISINFwta17Y8Ng0cxMBC7iSa1vcaJjUFGaRZtVyW
NXtEzte8msRw7WJ23OTbpWwHTTRK1scb4LSNs6ffKqmbHH4bVSwqOSV1H91kNjUlViEZ9CUkuPXt
A0kNHpPqFc6tqWx2eI1UsqfdKmkQapFbkyqQjAUP8gcNg2kgtI2XR8jV9W2OLxGubaU3dyppGhxI
yJk+raVkWh/kDiNG0sFpWS6LlJg1rQD8Rr0taRCJUUrY7Ow3LCpaYdfQo0zYjRpIgtKx+n+UuLBb
HF4rSNnUiPJFrUYFRsaSRWo8Meib5KR2iSTAaYd1W+O/oib5puJ3ypAa0c0DFYsP+fX1qNCcTES9
itV+na7cJo7BZdgGQOmoPcKsIYRShsc2tqWMHKJGARsRpo6REDJLKjjWG0cluo4bXjDRyZOfpqYx
DwSx8ra10p9HSsE2/hsFD09XorrY0euyrIOe21qWkKCAkIIjjkO1FTNOKhgteSHXj8bWY2sJp+aI
cOfqEAn08lk0VuJjTnuBRwVlqk81lFa0Y7cMcQ9SskSQqj4epBKSdpyGQJCh/h0zUdc3EpYsN2qz
5YaiJMRy8lTBM5O0zTJxtbRKzIfGwAtCNLGUjKqPU2jbLL2jYVIVeyJD+u7zpNe2ZDoqcY3XNqtc
6DtYR20rUsrJyVkektnWa31MwqxYA4sFl64ljLgMlwKKpGLLu0fELW7WEcdKNtncm+mx9O2ZZyXl
OMhGRmxYMe7O+ymQWTa+hrBiZf2xY0mpd9QihqBNs747q6NpmwNLZd1YnGfHSNBrrWQW0nQWzIFN
BYONe2Mlk2AqzIkOrC2y1FLfAFpqWeSzWNe16UNCkYUAzUXWSd19TCY2v1IKZJPKqZEdq/Pr2xcX
p+JKZ+asaEmww9mPfylXKKd2DiEkwfiJGZqCYvcqvePME7lJsu0ysJyZIAw+Di8B6lTZIEtYxgN7
8a/jcHkbi+hfQnVM0/H7s5GbBmzOys8nluqAcIk16gydOaXNLRuOSmqNkyeiJAH3rRBfamTfHdWS
GmZNC57a1jhjsSoNPqikdVsexZslvANW06/TRtyVWIrYlOhZEWM0CKieO4e0sjNxgE5JJURWoD9h
3KNzGd0E4TQmpTtIlv8AuYWR4p3X/tRKVzpcj7ZJ/wB4DXvI3ZBTpvjqtm+Q+rc4QrSUjU+pOO+A
1whllN5jIhBPB99rN4+oGbOKnTSQUcKS3gkInJ54jXqsbgNXKhlChQhhoiTVUeQ07omQkR8wfbSC
7k48NOb4/ATSKkh8dChHERrZjlG+I1DBFCTnPZ2krX88NDapCx+2EBF8gsZpBBiI1kx6tLHH3ghh
N52TVZlY7uI+G1Syg9kUV69+RGR7WRkYKQ9UMMKFjx4bcs925V/dZ4be9YD7YoDl702OiI1v2SRG
99U2jRAo5LTfnWt7sfVAEa1ybLg28l0kFEy0FwjT7PtLU7SZQRJ4lpM8UjpSS5dABvj6gesd02z7
2aWA1q3AuID2ijLWEV8aZFGQsdnCJeziiNWwyS1ErYQiyPqMsVUwQlYzlYRhFbR07GsCnbJdjUkO
kTtraRkPlWBokenKdbJtErw8T26J9Pi2zoc2mlqWNrZPuiI5uVcAkt8JEgg1PboZ1HHeVtfGaF2o
yK2LyeWRR06o6bPZDjQ4H1M4GgiIZ/KHVSEDcSTeQBaxjsv9PINpE90TInufTibQ7aMh5tINGI//
ANPUDOQqmG2OS1aigIn/AF8eGxSgT+BUJvllHZIsaVqNxW/9pqRNx1kZkcltsoy/+bFjC5N/8ymT
7Vixj7Oj2TB+9pqVG7VwWCLcp7Sm7VsEY3qn/l0yIoJbRvs6RvFo03tNSublcNjD3Se9hskCAguL
/wDzan/SP2XWlP7jh+9vqQjWOrkYkq+cxr2oLswIzRG1BEGZ9SvCBP1TGj2HijnRdSQErrTF9f49
k6LknH/NP7WAP9S+Re/DRVkUm6AnryHdMXu0y7xpp2Myf92RX/tjvsOyYEtCi1Jie5q//V1Fhcd0
2xfn0bZt0TNOGaM6PTtXj/cJe3Jpyo+NcvRWy3/v0xKaRJ5E7VsT7lFJRshHIgL16LmmUVRyTINI
J2HbZiV7a+qQayDIJp5jjyIg9gWc50VUue8yukiTEO1cF+4R2cpL3cBjkjdIe3fGf45qoro67Dvv
2ppdV2sV3DYp9yhgeWVo0jssbHjg5H34E8aqxEcK8RyPqa1NpBOw2XIdNJXVyAYc/abNnu5wrvtt
BYhO9jkUGof7y+67ZpD2BL+IHu5cJ/hXZZAf8I1yeqcq/wDtb/dZLs2B/cRd1P8A4U2dIZ/hH7sn
L92v/wAbP7rN2VqbOJtyl/4Qe5//AOiz/FL9zwP8Iv77Vfeq9nP/AMlgv2Ivud/+PdPHkqimjL/G
Aqb2v+WoxXJ3rTbhA/2Jibo1OAn2Ykkf5I0NOLLFfu1C/wAfVKouP6NzSRkXLc3GJbn7h9OHQZgk
/iamk8nwn9o1DI5A1dJ2Z3O4TSUrmy8kcIvc71lUARkazt1BIhr34c2r8iY0TIQbWxKddMAeyVbf
sgPmHHYrZy1yFeAaytsQyC2ZGpGpmo/NSWZIGaelvmjI1GzbRd41cfuz7kjUgE3Sz097wtbr++Iz
meirmDjantFi4MJZxGNsKxdNWB5hr0bVgU0VJFiYTYcK1snSpmnRN8a7e9s93vBmIV9nJ+pRWaUk
lkF1G1qQCL95uRHbH04ZEi3qkFLpN2RvJb9U1BuaLp1SlJaym8HFaSADyksWlQUOnkty/adkylVQ
hSUi2mo0dIiae77320tiNUrSV8MEhkspkDCpJjO3qCJIdZVG8eMCaxbbU7HTI2nxGa65nsTHnbIg
18CUCcaQ0MGjmsUN1XyH2dUvixY1gP6tqeM+xj6ejSI+XVmxFMRsuBV1Z48yZMYGHQ2AzRLmnkmt
oT/DiV1mFbjU8B1qKhjviN1pYtKEc2Tmk+4rdTq/zK56Oq7mAYuoq93CBrN3O7z59G3XfZF9ui5I
X2VPeCTtSq6waYFzC5uoonck95sMYZ7ZSXMRCNqU2BYx3Gd9NRoo37RagN230xu5F1Cv7auD5RBl
QEe8kdxxMX0p6kyhEr5qJ9u9Z+7bmSkbwhXLf2S/8mkAqmTW/Zs27EpBc7D/APo3rNl00VGx7EKy
G0sVYrSKj39r9smK4xH1SCWO9OFlDU6rUINkh7oq11pKPIjkXsvfxOV3cECErJhCoxrJfNTAV5O7
wZbv77tPwlAyWLkO3iK12lWIgrB3AckiukRq1pGCo1acf2hXbkUte1Ozdn4N0+3vFUKIw0FTknVj
WMbVOM6to2xnvkoMV8fm8i+++abmdlrnodkcfYw85GYGZ3hdr7rpXbHHsEc6QPuqI3ZT6hsUzu+0
DUBkifwxktDDQXF5JiMZGsEfhxd14zdljLJO6de8gPsrJskY5JSGEwKMcedwZDsEI0okcZsjsDBY
op5P3kju7GSLJGmdISQIQ0G6XP4Mi2CGE8SOe6Z2Qw7JrnyUQ6xy+Oj7VqSXSEkiAxAumWKI5khC
xywBPkKdo48WybzPsZzDpGFfT0IQnu78j910sNrctuLo1wHjI08JqnY5iRtTARywGc5FFwYDVDGG
TtcD6UG0WXDhkAZiRrGslp4syICQYJWx4sIoyEs2jkJFpwY1rYsg0hsiOtTFU9nGQUd70ebSjUE6
0Kx8WrlNFliwU3K3tQhWN0wMoM5JYBjEHNRXTe3URUOStcMILyMOUqjbGsa2YwcLVZkKXT/aeVI7
CDhRhxX6htWMjaXL/LtZrfp53fztO2LXBmohXtnIoSjj/UfHQoYcYcV2prdnZJ7vT2wTtloL1RKJ
7DMs7ccALL4vnQJjZwTyRQWWt645qO68prnCFl9qPbKS8cF4jDMO3vWRQjtyJJrLUcwcyyBDFY3Z
Jciiv+bXSY7c1BqBSvo7l0UoZ8cgLu+YBgbQw5VTchlDnXQIwJ9oWZJ0/qDbCW0MSagv3yyU1z4T
wXMQse+1G1BAnEGeo1BHIywv4wgSrEso+n9SIBpr+G1bm6LNNTXDq8w9SwCAvdSIUcaY4JqrVMUg
7XU0do5Mt8kleZgZVXqevDHuNRQpDKPVQorHajrdrLVEZsWVIJKPt/Q+cd0X4N7o72VrtlqrZY7p
FuOQGrsEAa1uGlHT2nYyRbCLkS3G0a2gVyTcCRg7tjEuJiSHVdu0Qrew7+U8xgRzrpOEmSpVVcXP
x0+ei5v6aOUkZ7LkXatJgzrHIg5dfbjayxsRFZJ2UlNYsjskWg3jsyNe6nlNjOZcCVlpIGZK+f45
RXDCotiNqLcIhA3A3NScFXSbEXEFyg3/AFMREkWAkbZSu46qkIA0W3Zwm2DOUe5aqeePJdqjWhtn
NOG4a9k62RGim7ngWI0atoNzbUjHpVWHitmWjSDMT7lVbtG1JwnJJtGtbNmd98O4RGW05pmVU1Ir
wWw3s80OS54lbFlt7jZYkbY2zUSTJ7iu+U+QnUTqq8/aW0HxnWakWtuVCqWonssLfI9q4Zo10MqT
bVjGvs396uvW7HtRtbOtFe+uuFGqWonMsbXlkW3cJ4LoZGTrZEati9siBdteORbiY2bZqUlZecE+
rAVthbK50K3UBQXUd47G5aqMnuYaFeMcyXciRkmycQtZeomPuo+1nauK6stnR3tuozm2VvzyPYOE
SJeDUc28HxLNc8lXfoxDX4GslWjjPr71qD+uRcsL4asZaOaaJqELx2V816SDqV35xjtsqLwEUcjU
8YrbCUh1qLEUN36sj8LS1ZKdCkeOePqmOEdnqEMpjibnr9RCiikaqERkuT5Dq7USxc/VwNpep0M2
FqXxXLq8eLrITclX6yDR9V9hrtXjXLC7WWrV/dA1QsQBNYd5jLp4is1nth9WKVkiashYN8WBknVZ
DMkSnHfXX564f60kbG1XIM0h1cRmo5AWSJTj4IzhKLVMoLH6vmbSZ5JmRJZYjz6gkSGq7m6JYGiO
dqKWrWXUkSHnlkPHqKaFr9SzXpImkk4vRMY9W4y3liZInGk4jlTATDiw9nIfiu3UR3Mx06Ts5znK
j9sSTIRCHITE3xClFhJBnIi43uY+RJ4ueq4j1TFkkTHEV2ctsY925EI5E3xoibOHJbiqu4/fOwfZ
26Yxu6+OVcIAw098ZGM5PEMuETg4QXkx8Q+xI5BYi+4RKXCwj5ts5g1cqxybJ8gjkPn00y4eM+Pi
9Pj0L6HY7Fw/w/pGEpFbXE4DjPe4sB4UGBxH/Tyogqx5M+kvTH1b2olcR+HiODgYZDZJiOFgYrzY
WucLHt4quLi9fjFz39TV2yLFLJVaojGlCo3Da8zmVZVQ8NzMTlyDXHMh6942uarFjxTHxasrEWK7
kKqMqfSCYaM8WBryFxKwuxoZRo/kzO+5M77tnP5YiruCvkPQ4yDwMA5UbVFTJEIjM7blcGsK5JEB
zMfuxY4yyHrDOFiNI9zacj0+ikwtMQaMriuc2oPsavKiFG5mdxUzmu0cLjuDTHVPpBlQtSRuMpik
X6GXFoyIkuIocXqAbyqGkO5siA8OcV3jVUgzDVRBoQbhrFgGkq+mKxDAeJQBKdzKMqslVzxZGqDG
b+nyZIqXiSPXEkKPT5MNSvYh47gqhFTO6uK/fGOVFi1h5KSax0dIlYSVjdNuah6RzEeB6Pj0RTpI
o3hTsP7kegeVF037Sql0fIdKWUn6XREkUbgtIxROBHJJf+n3NFIC4CxYxJCs08rmzKwsbOa53VXO
W+AA87had5Nl0rwtIxWOz5xqKqwal8jHaaa5k6tJEyFDdIcPTaKlhSkj4wTnEhaeaVkrTbWNMBwn
19O6ThNNMUc2ufEUQlI6HQuIyyrlh5XwXSlFp0OxNNi2PTEEaLpxjkdpuOuWOn3gyBRqZG6dj5M0
3sNsF6niadY5k/TSMZ2HtfW0anabTI1bYQXQy1lS6S52nBqO3onQmwIiyliaaZws9N9sY4zlLXaf
UrT6YC5k2C+CaqpnzHO06Pjc0z4eJvlZUvmukaVayO+GrZdZpxz2WVMIQzp2yr75t0ANSOp9NqUc
rTQntsIDq89FSrNx2nWMZqCi8LKqAswkbS6DFcadY4AgL5FNprmKXp4JhxdOu8xunhgH9EA5LbT3
akV2nRtF9JDve6bb4ysVj1TPjNuWVNS+aQWlxshzKn/uINAIAvCiOy+000gKOlccgqiKMWotNtUO
n6fvkWBBjCbWxJeWem+NnEqosULB15lvtNMIOm0+xoXfTWFlUgJcWxhLAnabaHyDU8U0W3joC205
p90l8uhC2F4/fuKqhDGjrNqkkTqQU6HZRVhS8X1ouLm2Obth0/aT5am60NNzbNjjEGmYx8mfWtKK
np1Qk+KNjKyMwrDhaNzwDUcOuY5tnRorKip4D1BCRjaPhkmtaUdpA7L3t6L6fjqnULOZqysYIBIz
FbcRUHmnK1CtWINjbSE1GVsLyJwoLRsmwmOZPj/ya2taMBYzHNHVNcd0domiE02S6pqqMYgtG1hH
zIDFHYRlQjYBXY+CVmKFUylplM4dW1Aza1HSBQmjHwYr5NcjhxadEK2OxMlVzSsm1jkLS1DBMsqx
EFCE1k1vDgJGPLJgtUbQDHmzVx0Bjx2sTi/6eQmLVFamnwIMqIzgEbXvNBbsjWNR3DkkNHhvo6Dw
qe/x00xXcmJEaiWcRvCuhpIlihbMlxW8ZsVHSq2AjAkit2uo7UTTteii8RrUPBa8jIWw0CPnIrUc
EImAz9iqkFrxXUNExKmQ9VpZLcLGcNaapdIJXVbeF3WImQK9GjINjHNgIUTqZrjpEQTXRGnaetaI
4+LWRmDK6fBY1I6IxqEDydBa8NrWq49HToPD1TPF1BH4SNNwebHxmCbaiRWOqiHM/T8huOiOE6gq
/ZRsDhobTDva3tPVMTKuN5B4FagAN4OdYVSGHUUiCV/ALjQkkMFRp5KgSINrGyWz6ZryxK5I0dhG
EW2qkIKrgI2TWwR9nWAEHmnOKALaCHlY9k5pq5rpB2MixYk9smTYQWOZDhsCGVZ9mS2O08WPUNfK
nHZXNCNstsmja+YsVsGPGlMl5b06GytqmgjvsG+RJrkkRaikYx1hN+n4FiTBrRp9QNtWggTEn5c0
yFyHXNhxEteUybXJKhhpXOsqWsZGbaNR0KrrUkWlin08FpOsZinY5HJn5RMoo/clw46ChFtUHK1E
Rs2RpeGjY19O8GRdWApELRcTdbfkGH9bY8NcHyLmPH7de+2UEuqKI0nVbDlBpgchmapltiDXVT5A
qGLJc+6sBgiQKB04v6SCiTdIjQVbTEPKqq9lcxCIcH9mobRvch09XJFMnq1IlXCaOJay5S2MBvlw
rm0JS2rzyr0lPFWuFqjUOziXs2xTT9S6Oy1txgysM11ZMpZBrqvEo66+iOnaiqNNNHiiQMC2VE1F
p3UMfecbnDgq1uooq86t9AVbgS9mu1IRpbrb3XPnNvUvR2SPgvzG9zVEdGRdRnVqQZix5Ne9Jg/C
aJmoJSsZpt3KLNArlmS1jDoy8xGVhEDGaxNSM9u8sc1M7vxNRhRGl9scnp/OJm3VPmoD3pgB7hnn
8fJs5JGUAO3DsPtJOs800DnIKPYU+eosDtNnRhbhnnWOtPOQ2SRdxlfH7KzicWEnPeWsiKNZclGt
jwWyHeExMPARRiqu5IjRUEg/8UofGU1nMaRuMlf7GBTjM3ZkVOQ7RrRPo5iFWxdyBNd2ZKXD9qMB
O7IlIg5c9zS14HmUh+21oEmkHWezqfm2fD8JVtSLlKEiOkSthzLdwX13fmkGbthvSoql+VwTO4/T
gUYCyb2kmWGafEikcFPGnzuw4HGZNrwo4NsfxyTpCS30IEay1TsMBZcigTuBcBEkO/17CeQB4IHk
XyOyzg2aXw+DXR/Y1cwpK+uRjYbEG28GqpXN3FMAncht2CISOdZs4pVbuy8Z2UjlPMfED47bSyQb
AWRClhiYR42/x2wkMeLFQCn/AHR76L/I0yFqDvftsnWiuyogqdraXk24pkYtFH+xabq+rZyBqoaN
xflPnS40dJINEiDYqSnCTsRhIg7Jq96tZvGCFvduG5RsXkYLVJYMRkeKNUmTxtWKs/wbCkl96NrH
3yJIeNawRSDq2INsh+0s4+caIBGSLd2w4jleA0dO9uiR67+y6F3D0rOA3MTzrj/WqwI2TOaiic3a
L2E8gTU8auYiNtwoWZTjRoeP/YXjeQakKCNYJ9k3+kELe+jf4dUASEXblLHyi04EZNtUb2hRxyM1
PRtaFvRvzpdoe6NUWJqmQ1kivVhZFDwQOsSjYiPV59JPDteq1sOfIQh9LuF3kenhapltWTpJheNx
Jjwx1EoUpdZxnuHQUSmyRIFWgNZus7GojNHAutTSq+yFq0Bo9FIDIkyEQ+RhoMM2E11mZ6Q4kG+i
TDWgFICu/wDL7o/qVR/q30J869q6wcQWotRNjPGx849BRIJLi2HWx5M8ss1VqjwUDrQZjRz+RAg1
zD2VlP8AFmMVVqrn/wBnS3/on9qutF5N9ED48BNYuLaED5lXeCQFp/RX3xcVcP8A2k91j/tNULvF
1O3BDV5NPCUQpDuQdQBdmmv9adJQeWarJykarYs6csZ1dPQzNRruhU5uoPaBqNN0kf3O6b+pMRPf
pTnQEmKT7F+VExzuJdNye9FtyJwnO5P0tJ3LJf8AYuCpzrJHYlxn/ZvSojdMN7jpD+Da+Whyzh82
RKxGOkmQLJsp5X1w9otrIcBGXBHZDsGYyaxUjKjmTG8pX9gvLb5W3JjPZk52RPYd7/bppV78v3Ba
79ykgpJOguwOyncUrIDiquwW2E1yrRN/YUiDb5+2XBEeynhpINw7LLSw4ZF/myokVABsJvYbPmdx
XLvi4J3B+mTo+PbH/ZYl3JpiTyeQm0a9LyfVSO3JgF/j6hNndUZNOGR47w37IS9ywjoo46zW+Q77
kZ1bzO5qBbZTHuygZ+23coRpdyGFHY7rGsG8K43cy22ekNqo2wnNEaETuiD+19m/Ktf33I/IyNAQ
DZkvstnrIkKERhvgXaI8Lu5G8lI5Az2EIxyKHUT0YXTB+YtSH4jjN8mfAh9sMN6I++Y1W07k7Niv
3KhdgaqIi49PdE99MO2kkcixuX8h5E8cBWqCwdxfWrtEAVqltVyjd9wpU7s1yEjhcvm2BUbEtf8A
f04n8XWSZEgEOg5c+tbp2QSWEomulWr1BDp7I0mdOYjhMYjI8+wkMsI6c4kJ7US8IrX0XJIrpLVn
Wrucamc8k2fIaxncR0cryed3O1Grjpxu1e01NuyIklqzrhe4Gg7jzWUlqNcdr4bWn88x+zEJqd8C
RVakNONMIrIVOfeZq7m+No9hWv1Xt4Sr74zNPsc6ULfwNQ8/qURquLplitj6+avJi7ZowStXVTXO
gLvz06JzpLWr9NvmK2x0a5EDraM6ULScd8ZL5iSCEi+JXyAzLSQ3TPiuqS8q6/qZEm2FpdzxGUld
Kq58uTLgKqwEc5lzdt79fp2sPGkWZ2si01gwkObSmfaDkMgQakDJ0rU6SGhrtLmmZDoGQJNmJY8V
lJNsZNrpPxY8KvLNbT6eMMxZra2FRS2lNeRXEsAP/wCtuIr2W+nKp4pMhv8A1sOuNAtxFQlUCiki
ukMgay+IhbbN+nsnqdm/Q39pPka/u07atUNpF8kddDRZvNIwI9uhjWgkMGjH2x2Ie7g69qMgogk1
G79mmDK6JfP3bXRfMfHc2JFvZ6EUq4vo29G2J1rAKeXF/wBe+H+0i7u02JBQ7Zm4pqcX6TD96QvI
dwP7leJSzAKnYvR/t00btZIb3UrovjkeRFcjU4yY/dISsYjYjkaywipIaOqGEc5OwsOWckivf9iS
7iZH9wXi/wAhxUYxk5FUoULnd7TLST31ooaAcUaOFdR030vszJj0QUonKbAEiAlA542uY1sPYGSv
3t8bbLTkjdNuThYvRGWJVcTT231DuN7F2XZ5X4vQLebtPMQUe24uFZpxJpYCNUiose7T99SHuSq9
UQGoWouIPmahRoxXXFw4j0DPjmR8dYo+807WjDwfk4TVxsAe0REA+Y1shv04TFsw9tByS+RQO4tt
jNXIElOE2OMpIxWhF9Ta2Q97Tox6AxJbCmVBdl8URSyoLEaKCioyuAx7ZDRAvZi8qFyuIIzfFvhI
U2neARXzmkZGXx7WNJa4AitYWzkNeKBYNY9yoXFkpHZeWKHI/wCcqZfiFiWTZIkY3lYWqCZV3LCo
7iVSzWxRAvkbK7rTtYVkRs2+RkqPPSSJiNRby5Rg64flmrHMEG7Rp0r4oEx0drkgObEGa1ak4kny
AxQsCW2tBjZEsUMMgEeU89kePGvUSQjkM2TPHDC7UKpNizUmC7o47bi9VX1V35TE4JlxfdplLffu
YrSNsLccITNQP8qDLbLESWKIy0v3PPTXCTGK8Ysvr/8AapVI/TAtskzkfHbYsBNM7yWi4Qs1PfNM
xf7t8b86WYPmtmLxdUKx5qpjPIr5wIodSywHENqKbTh48YdtZgOGyVCS9LkjBV93HQGpzhMWiuvG
VbGHJR1tGjMJqFppn6ghECK0rhrb6kjqKk1KLPrFfvO1SEQJsl0s+nZkWKVmqoYxW12Fx4WqIpAO
v61iXupvIFTXL4T01XB7N9qF05dP6kDBaTVsF2N1dAbknVQiFdrOC9P1fAHl5q8MyPpy/jV6l1lC
2vbx9ianv3VzpWs4RGA1mMRrS7HMl1utABiLr4HC31WKaGm1h4TP1zFy51h5YXOV71X1bddk2X53
9i+7SfKfNfPdFezUInCDZtDMl37XiiWChmP1Aztxb4TMdqALsfqESNDfMTLW1bJSntvFHZWzZCVc
xIySrxrmyJKlc73zb0r0Xpv0TKyV4xouoxNZY2opOKqd+vuxhSXdCI2eZCLU2bIrf1CBR2E0ZkgS
kjFj6iDxsLQUhAy/HOC/bt9bj7HukR4NQM2+tAXC3guLLrZ7L0KoW5C5thO7zoJuweJfMak23YTI
15xxLoC5LuBualm5hY2oWcZd01yeYvfg3A2J9fArbCwCVsKb4zi3THjefc1feNYn1sC466AiGukQ
gLwSo64BxsbJDZW2KRUlXbCDkF5OhSPGMO/Gg7GUh3P9+oXcCV10wLZN4ArJxUKSrsmgxdQA7dnN
GdYEhAEj6ijjHZ24JLe7xkV16ITZV4AjDyti1+oUGn16KqSL4eQ9QMbjr+M7F1BFaki8b3I+ogbE
vI2WNv3cGXiSvvhhbKvxFbGu+wrNRRXJI1CDY9kqlhaiaNJeoROaK2VkgOpw8P1LEyXqMT2Rb9AL
+pou0vUQ3tkyXGfW2SQ3D1WHhPuGGfD1IKO2dqUR2Hk8312oOww2phOx+pWPa6evej6qYxk/UPk4
Qiuevvm+I7K+4dDxdXorJVi+QoJbwmZqxWDm3JJLvIXeLqR0UczUrpSFkOe6vuXw8dqkjmyZjjLW
3RYGfrEyYXVhDIy0eMzdXSEQ2qiFa+e9zgapkCYurpK5KtHylhXciE39VydpN6SXjS7ODqKXHHJu
DSs7i7xLWRCw+oJRmPN3FjyngIS/no0sh5lGRzHNuZjGyZxpGMcqKGdIBhrKSdFXdwjPHi2c1UMV
z1G1VwZZAUWxl7eQ9zkly8fOlNwhVKubYi+43uxXzFaVz92rjFk8SrIxMZ3VQjJOyruolXFDKdj0
c1W/KRjkaRJA8V/PBCIXCRZDEVcY1SYsAyoRjxKnuoq8pWmCUCpgYzzYSDJHi++DZyc6rkcXsezG
fKVhJDTQyxcR2+BgPkYarkBTfABcZVpZGxRvC9jd3JTnIhoJo+bZGrjS0PUSAptusetOdFoT5Nrz
RW4mL1X0ri4uE+CfORxKTA0j1H4aoUlMqCSIqm+iuRkemVV+hPbi0ztvornLIqngbFrnSHSqpwEj
xVkOLVuE0olRVTFxcXpvi4nVOn4GzksSmeRpahw8KFRuhVz5KupXoyRD7WAiOORlEu0iuUOdlVfF
pHEQ9O4WHCo3Qq18lrqZw2SI7hZHikkPHSORJMJ487a8gUjyJIqFFhQuTIVS86Po1ahozxZHiuku
bRK1siC4WIJz3RqNVbIrHCaQTmrDqXHa+l7bZAHhyJAfKd9C4tlQFFjIzjPBRO2k1jgo4b+UKneR
D02ySY7g57qsKmJIbMqew0MN5ij097TISBUjfdei5EjkkOBp/ZsuqUadh3KHRdxp6Tg2QBRLAplk
4tAjWTILo6xIb5Th6dTaVUPZkOhc9v6famHpeGApnSXj0+NELRNakyI6Ou+2c135LiJu6DSOkNl1
KgSFVPPiUQsLRM2LBewsTT6EbJoUYj4JO9G08zitCHJdKo1hUKlalCDaRp9iZHo3kePT0djSUIsn
1yxciD7xAUIiMs6vx1jxXGfG021WWNf4jq6o8pEoQI01GxzbCvfFfm2DYrlrKXvY7T4OFjUEj5Ar
nSFDQD4WOnuLRQyKaFQM4S9OiVkmC+MWspO8haEfCyqiRHV1Y6S4NCPjaUaiyHCcUkPT7eM7TrOJ
obxmq6JStkafG5lnUviPqqh0jPoDVS5oljpCgPO+LQtQdnp1jmNgE8isoeTZVAJ7LKrJEPUUrj59
CaiXNC+OtbWPlEjUDWDs9PtcMMAnlVlB9uXQDKOfVPiSKShcVzqNnG6oXR3UWnlkI6nQeSKMZhGp
HDmVunUaKbRDIy1rXwC9Bj55TUjjubTCCy606wooFSU0iuoBjFOpAlFIqCx5dJp1vEtSJW3tAsc1
JQqdfpMcI7/TzCBrqchzQqSPHDOpQSgmpyhmU2nxja+uiuy/oXxzUNDzxYURjdRadYUdPRvkmi1k
aIKdTAmR/oRmzKehBEG6JEkLqDTroptP6e3Z2og01Hpxp20tI85BxIteOdUhsIaUL0nVdUGAJRRZ
mXmm3xpVHp9AsV0RM1Lp5sgdBQuM5PEgssasNnCi0BPPhQQ1gf41iKfp3w7OOyPBig1FDky7WoFY
V0sXak5tn5xei9Vxc2wyYT52zTlR3mygsjhjEE6zfFYaLGo/5soDBBqlYdZTGDxvBzYccb3TqdCD
rqnsvvIiNZWvaI6RmSh3NX2VImLi589VxPb0b4macq0lL2WCR8dh2yqXmWLAbFE1oiJYVSPytqUA
n7EWVAaVkSlTvdpo8fGYdsin5nBDaAXaGRLGpRzYFWkdqI1Ml16EZCpU7naaPHxWSGkpucgMVscf
aa/J9VzyvrEjMRGZMgIQcKobz4NZhIjTtWmR52RkCztNLk2nR7ode2MNGMydWI9sCmYJUajVPCaY
Y6ZPIaBAp2WlS5rOCV1Kpi11a1B3UFvGtqWhQ7Ua21azCt/c7rpaDzEkdBpYia5kSL3Z0eGjRymD
4T43KTVQuIiiYiXYE20/B3H2GjaYLXkHETgvDukhteHigXd8e7BMIO5h8nM08U2P029qSK54Mpqb
mtZWs4XcBjMr4TVZI7YnBjNOJapqnWO0CIBshsmB2isKMbIhBmfOjMRolYPByxEesdjgxoTFdOVk
fK/hMbqKBxynr39+rhscHU8dGpp2KxViwh9jU4WtLQwm9mwK2MsIbZIdURUbjsTKSN5J4degQMOx
5ZtahR1lOjUOZkd6xEkCj0zfKM1sNoUbNyZTIUooTYkcMphyWNXyZW1DRCNNYExYKHFApmMPPKlf
gdpzTUqPmKBsIEaX5jrOqR2QaxkcJLDjJLCSRHrKdrSWUnwVjMSaJ1Qj50pjYMevl+ctpVITIsBs
aN9SV8yRXoaPT1TB5aT3RyRGebHFTtSbakSCKokunLZVLXvSK2JDBZvfKlQWkDUMYMdwyY6XVD/i
jiMPO1Abw2UZ3Ss1hAaMDMT5rQ96XTQGhiWM07Z8ISS4kGvYkvU5nxWUBCHbPrWNlT2+JX1Eo5D2
cFhQ1kVo4s2TIdYxA+VBroA0k6sOUOac5lZPgDSZbL40CifJ7ltDY4MCO0VdIfJLaxRJIr6iExJO
rHl5ab58ZUZjZ+oGrHh6dbIa64iscyOJoKwo5JrWOxD1lPHZ39WNMc2mhuahY7Unao3ZF02A0XLs
Tc4oOpjRpJLViISrqBt21JGLOnafYrBsE36lqtrlj6YikhM1yiDragUqyHA0s6GeadsWsmOQkvF+
NuiZ8dNum+Ln4Lhf7kzSw0WJqR6oFDKEtBL8oCRWIzUEnts0o9XDlB7jZpfGzT0pSsIduwRsdmoR
+0n9hdLHU0G+EiskM2c75X0r0XNs2z8aTGn06azfKzdR9pFNJZs0G6TiMRUUSIOYisULdwhEnGaz
KpVc1BI4koeyRt/LeNHY4KIOU1WlY3cQgpwnMXatTcTApzlj9om/kOEjseLYZuTTMbyGICI2c1Uy
CnIQwpymj9oO/NRIrjC2GqOSS1iPEwCcZreOQU5DGBOU8W2QPd02Mh8BDQeQ0RmWwt8hBRWzwJkm
s7rbGF2lemy/GCZzdpoSNDZM4BnzlY6iRCGQaeLaSnAfHOkuTUi3DcvUGSZynfp5iIy3b22BsHeT
DXmEwkQqe0W1IXu10N6NcbssEqTCrEaxvaZsaG0pYMJqJF2al6PcdY37c4SKSI3YYmo59ozbKlFV
b5nFkQJ5DwjQTbe17TQPPMJAh9lkuf4w6q3aRZRe4tOFGJcxu6SNAaJICNaPVeU1l47q2R3ouqfc
mn3bgsQbrBbwj6qX3d00s3+UVE8QQ9pTxp2AsRoLIfI1Y3+HHHs+4ZyyjZs8jE71k1OxFHxmyGfb
RNo8wf3Yo/4sVqZdD7hKFqKNRp5tqn2a0SNnTW7jf/rvEjTBanYhN+1bsR8mkanjcU866TcVSNrZ
M1P2HTaGxjUkIn8aD7AsWNdIqETsDT+XfM3SmRrSTfdZ3+nFGxhyJ/CqmLtMkRRmjO5xoDFSXqLi
pKhG89bf6rP7WZTf7tZ/omViSav/AF4Cfy9RcVkU6tVZ/wDtXP8AoQXj3ne0KJ/ovINsqtX+LW/7
WoXtZMpXNcWf/uah/bBgGYTLP/WB/wCWOWJJUD/zaj/YvDMBPo3IU8r/ANHUxO3GrZY5LbdfstTe
qjWIlkw/arp/9i5nMi2NC9ClfstjqsqBj1swctt3/a//AMmBZjIcXtU0q8h2liyLbUb+5g//AFNX
HSKGnmNmrrr99XAlngtpNTTbGdYCbIq5afyeu2fjr+dsX5VML/aT5auaUIngakYrwKJVfpiKscPd
RR6gi8k0v7ZON2mynLMzT4VCK1O4KU1p5DL5d2zU+9pFnCFfL+yS797/AJ67f0NIuRKqY/jlOv2e
SIaQ7dsdf55F9lf9ucu6iX7IXoiTX+1X7Da/7kp3tEd/Mc7HE3HLdyMNUQQiftsF9q1dgseiPlv/
AGwV/kueiK5+4zLvIYuwxEThYL7QP8bCJvNd+2vVeXNEcV6KNXbzGuRBMIitsHe8NdmDKmT37pX5
LMg8+qMTK6Q0mWfxFXZlhN4PjfeHfR2op2/cX5H7P0qdXRrQuwrYivJpg6ofufxL8261x1ZLqifY
1Cb2e9UJpoyuBcl4hiu7llG/aAs5UlD+6B8BHFInYbOKWRlEFR5cewfKkpIbOKNYtwLhWSmmy2cn
bhNThYznBLAJ3QiVrCWy5Wps6zah8FC4NnyuOFgHkkq6vtjlE8ds8MiW5XHhEi30py0kl7mEc0hb
FO0Goeu2q0XaExyyaVNoupmOcWjGiR7yWUS0xHGjapGm7lxq5pciMkPKjow+XkEN2wgkNcKeju5X
u7cSNKapbReWUu6ONJakia9Cx4rXebOkNYwZ0UM1rlMEnbixJSOW5VVfRoogLLb5liTugq2v86fL
RieQ14TiesjvduPAmt7d2j3EqPsQ0mos61d3w0gieVPlI3FkIWL45fMPIQEevmIrLQRClrl8eICa
iy7reQLT4CgWdOb3TnQ0YEQ3nTJaR49WRHhvIBjWNPuKGKU1sm9Y+blEB8dms57XC/CL71bkZKq5
zfHnVZTzAlSFDr7Nin1CBbHKWMsMM21E+fLMk2FV1BYx7q0YCPWWDXxpFK803yGwolXbiebUFf8A
Vsp4/gAlXQlsphEsoVNTLAW8uRADWWTDw10+qz5E1kCHRXg3ku6z6s+vZ9KjkvxLZzuNtCqaT6Zl
9qEIcq7RkuGmnNp0+zFWw9P34zrb07bV0Xanj/qUTrSejbqPV1DaxuoNSsGSvsmT4g9OijzLa5ZX
RtN6hYZljRDsDtktqARNWDNbTQMuIkCvZVDt7oM+U/TMd8Sr0y+BLsZbItbJdzkL8+rfouKuf24X
4Mnv+dMW6DDI2lhWKjbKO9oYqXv82Y9CiqAJHdNahGgiMZkXiJ10dO1pc+y3BkUUYXlS4nGIC7sU
VCu3c75xc39C9N8TEzTln2M5NksTjGZIt2jMCayQxo2jWXYIzIlohs7LSOPKQLA3De6jmyE3SO01
qgiBltksYxg8l2CCyHZNPnba5x5XaaO4b3N2yG82gaa1aJ4ZTZDGo0eSrFA5DtEkJxbuaX2mx7hr
iPVp0UyCa+2awg5DZDEVBZJsu2sWxQ7e23eRLQbY1s16u4mx5kE36s1pWHSQxF7OWdkjWkkqQtE9
BjsCtc2JKTJQmFVhkE28kI7D/wB6/I05P04jQhsSI4Vp+0umhtG7ut7F61FWqEj5VeZEFfua7Fbz
PQq0bLcrXAQqAnwJbXgINilbKRjI8hjlmcHYgG4AiAKcrTM7DN7UKMYjuUigK0LbWQiigTE4ykaV
4ZLQjNcIOT5LZDe8gcbZtfK8hvaUbXkIFqZFKzty0QhHxmduTHH5MWOiJ5KRWju0dKLKQoosposv
Td5tREa10E7WBueJVqpzGtlL3sBISMHUU5CKT3VMrpfjFrrRsoTHNatrdIxlRec07iOWdaNjMj6h
2kjlJJYaW2Kybf7SYFmkwSFaNt1fq1Ki88hG8d7a6aBldfu74zIYcuyHGYW+f5kCxbLESQyKO4v3
OfT3ffa17Uy3vkYyovnMKIrSMsrkcdn197ZUGxZMHJnsiCs7xxDUlykhvljE27v+WU164LwyR8bj
UDBsjXJRyYNmOUOfcMiil3BCmpL1pWutAAFb37zloL1r2PLGcsq8HFA+4KthCuo5xWeohgFYWL5h
OjH7ZTXixnJfRWtvtSLIZBsXxywNQRnitdUiYwkx5ZFLqMbEkamjtHbWr5xqm8dDVNUxeN7qBZqQ
pyxCQdUx0DaapQg/JcQlRqdsXJmsY6Dn2JJxqq8Wvx2sYvbu7x1gsSasYkLWQWR7bVHlBaZeVTqv
wUma2ERsiWSSequXVyl12NW21y+xNElOjFja47Me31MSwChFRarVb4DZusu+18hxH1dw+uwuvVK2
xsiWJokx0UgNdlCG31CSxa0my1urT16T9YGmDQy9yv1jJgNX/kE6ZbajNZt9vUnxm2fh2O+N9sfh
/lMjlcJ0TUSsG+z5SF1D9pJq+T+otxxtQ8M/VLVxdSIifX9nTbnyUg2Dor5V53mxZnYKW+/YeUpl
cvu736fOJ6ds26sJwdCvnCafUfeQ0lxFh2jo+fqJOEme42AmujuBqXgku2WRimex0S9UTDag76Hl
q90K1IDP1FuyXPedY890dQai4tl3KnTyHbxrxWIe+7uSJPcdCt3AxdStVsuwWRkSe6OodRbNl2zz
4ktWPi6g7WHvO6hpLnOh3ChRdQo9suc8zotm8Kj1EnCXaONjJjgui6hcxsm87yEmO5Q71wMJqHmy
XNUqtNxdBvUBhNSsexL1RvbqcWG1CwiS5biq5c/LHcXV962NhNTIVs2V3319n4uM1M3hY2iS0iye
wQGp2iZOvUktUmxYWoWxUNqdh2yZXcJCvnRsTVI1SRqNH5H1Col/VY8/VI1STeKQkbU6NR+p0ck6
3WTjTLyg6gWO02pUKg7pwVHqpvE2o1Kh5ryPh3z4+SNSdzGWL2GFqpWt/VCphtSuJgtTOGn6qcmP
1Y5yPtHd5mrSDbM1AWWjZT0dH1MYLCahK9xb152Q7okPP1XIw2pivQdsQT01TI2PqY5WypDjKvyv
tiKuQ7AkZXakmcDzHnUMh43Dv5jWSrM0h/c/dHt5cdJFvIO1xOeRZx4mPu5z0NIeRQGexfq89Gnl
mLjHuTAWk0TT2Ek+clVYxpocJNsCNI528chGq6dPYhCkfjXLjJc3aSeQ7EXAkktwx5iorlXI7iJj
iWGPe5VHvjGz+JVMiou6ibJVDJLb0E178dHl7Pc7kPliR5qoZDDUTFeqVsrHwZnF6Kxy9Exm+4oJ
TNkQJEdGLgorpGFqZAk48FE1SL9HlPQwCAVuDrCSmmrZEfAAUrvoMhcJSyBIjPuCpzma7T8hElxn
xlRcVNs36AAp1JRHYIUdXEFQlI1+mpPGRCJFdEhvkufps+0iO6OSHAJKz9MSVWRp44kgVRZi/paQ
jv0rIydSmgpGE4pA6cLIbY08mFjcg0757ZmmjR2fC7rnuuCGr1jacNIYmkJDss6g0HF/obLnynwm
bYT4N85GEpXQ6N3bkQeEhtF9k0NzZAqPYQKjliUOyfRN8WkVXyKJWMjVqmNJp1EIcTmf6MvblRFE
rk6L/Q36J8/msrXTHNoU4zq7sYMLiFj0P7JlSo0IHg+BTPMw1LwHMjqHK6tfLIlDxSVWK1YtF+36
K3JdSrMh0qkxKViYamRGy4yiVd0zlnLGtV619E4rJtZ2Mh0qmRKQbUkUuyEgO7sag/ZIpkYkmOo1
gV7phHUKBHKjK19fRq9n0djck0+yLXPcYNEjGToaBwvzyxXKmct+nviOzfKyvSRh6NGMmx+0q9Gt
96ujdIT6ExGz6xRrBqnSnDoBo2ZTcEbBI80PTzWtk0jWpJgua6toOTS0jeM6sUS1tQslzaNnGfUc
Ei1rikj0LGNmU6IhYD+5BokVp6ROM6teNaukUqfR28J1QrVr6buJ9KG1DU6ObIqn96HRo1smma5h
KlzTRKcbWOq2LkmiR2RKUbUWsGivpmuZawOw+pp1I19InC1rPGyCPukiU6OFaVXAlbTDaz6e3JlI
1zYNB9xaxGNJTtI22rljPX5wIlK+po+SLTtVttS9vKupcZwqZGtsqNFaKre8sKk4MmUjXMl1RAmq
6PdpaZFZaUyhyqpu85tMjWW1Ei5CqSFNFo+A51E17BU6pMjVDGD+nb5cULeNNQOdn0bi24o/2VlQ
Q5AUbWCsaJpGfSCeTWUDWjlU7HMs6VwJNJp/mj6pES8ofano3SFHSsCO2o2GFGpyrJrqBgwy6dhG
zqJ4ZVLp5Ea+rZx1BQKNKWicbPpIRjuqBkgNBQK4kivBCxkIUlNVUjYrMXG/NPCWUaDQABHlQBEb
OgrHs9PUI3sNEC3NTVrAO0xT+Vh4AIiXtSM8ejg+VKj1AYsaXFDKFR6dGhLCRBrsigBPZIoGDsnv
gQhRJcWe7VlMNY447it+nnx4XDWNGcd+nNOZPrgNh6eqWybGxfHp49ZZRrTNUUTXtoqJsOP58Yht
SadZMDp0AYgpepowZEZB2Iq9I9dY3Gp4sAVFeCts10JErtHVrT5N4VYZgAWcRQfztKmMB96JPCGN
SvbTSH4+mkMTSsJppM3asi1OrXWh9QVozQCf5Ou+3pT5XFTbNsJhvnbNK1iSUONsUEma1bOHwkRn
UvclSBNCKvO0syXs0Yzt3j9spyV7CABToM9tFRoXP8abXlZLFdVacJAuL3N2zfpt6FTr8dEzS0Hj
CJxHlpwe2iid2WrODZZBuY4CEsY0btBI5qZdMaqUERGRH7MztsMdw0YwclqypAWvY4jQq2a1Xua3
t2sLuEZROfjqLikmCo3UtL718FnC1iJzjx0aMxEG/ttIJtY3uvag8aNJCW1X70sNgkkRG+NYjayX
FlNRo5rFM4CFEGrbyOPtpZu5Z4rikDp1z2rp5EyTV9vI9QpMTT/7ZVYocFGUz9P16hyRGb2L0fEj
k6UcPyzx4qCCzg506sQjItYgWq5oVJDbIHHqUYRwuxgxMkNNUtUyReywL2EdOq0JketQbeTRuNBa
YcaqQavRI+NAyUP6UndWOgWiVp8l1SK4EHtMQrO5Ir0e2JBaiTXdtYrGlE6uRSkGkZoOMps+IgHe
awSQJXddN4IxLETGtuuRwvR8e7GhZVNBTtSzNHlw9CJV1SoSqA3sajRoSRp42jBOMQqiaQEWKNMt
DPE6v+8DVIWtxcT3ygjd80eI0EUUxHmlVyFFAq0E2TL8cjQJJDGqk789yQ2QX+akmrR5nASJGjTe
+awrGuZCrmgGecrJCxGnjQatGvt5Ph5B/mDtGMrzJcLKbRpIeazE1zQw2xoyWTvKJBQwK2saNLaW
6OSA3y47apvm2j/FDTyHynT61r87LYkKPOKs2TCaaPU17QMtJhByoYvJiRqxiS9QkdHZQPeZsyuY
ppTPGgQJJ1k2ENpAV0NoY86SbzYQfIiQGoM+qIjpS6fiLGFrkv2PxjfnSUbkSazaJJt1gGC/6jZ1
Qe3EvZJYEizs/qWaSicA6p5MZJv1UGkYXIlkz+Ctq+BI07K7g9RVH1ItNE8UGsrN4pEdJVplPWjr
g3dt58iq0wEMfxIKOt6aOaNpzTvF3d8VZjecHTbuxY3sRbKJSU305bk/3Zaca6DXE80jEfVSimWy
oqFxlm2I6mPY2xJ82Ow9i/T8D6czWVyM49IVvZBqON5UD6qeDJoqBSujNixV1C7aBpWiabCRo8Qb
IoZmGr0rJ0tiTwQNOCr3alneNCd+534z4xfn0b4vUjd0N8pmhkRa+/3QZl2fpWWrmBG3hqAvbbp9
yrNe1HhsE7WUEpSn8pGMjkYVb1Ps2acT6NerktGfZnpxK/Nv6XxkRncNRNRIlsnBs+Y5H6aYmSmb
As5CjWpehpImo4Vu9Rr5HfNTtTx7b9rYk1yWCfuGgWoeR/inIQpq+B2WypPabXp5akY0achOR0Rh
pAQo1sF2yWjNljN/bIEivamw4370nj9qxFRLduzamcqTlNyBd7c4RFU8FiK5rf2RmouTxJs+uQyR
qhrZDwIJvcDliNr0rYfsCCJzbqrRErKdBrFYiPl7eNff3vTPzpFNzqxFCJv8lrE4dtEZOH92Gn2x
jTeyb+2sTbO2iumM/ZGbtI4JxcNO3KZ/Iip9kbEyyb71jfZBpysGftrWr3CNRcM1Oy5v8tjd44E2
yez3iN2GJP32jN21TdiahZuyJXq8oWtjst7bjiOfMJU1XbaSZ44fLbIsKhvGPqVe0tc1008eG0A4
JGuZq3+2r9zQANajvaPDyyEjsgpxDqv3RyfuRNl0kieQbbxWsRstU+0Nv2rBm5K5v8QDdn27d3UT
f3PankWSfxobESdJT7f/APRlNahAJ/Gif227EcWi/wBbWKftoFjdqreHnNRXqT/X2ahm/wCvC/w2
jW9+mVPCZ/t3SJtScfKlf3z0/ih4tkv/ANWGn2ZvFC1XvEj/AOe+27tA9HrKTc9n7Q4jmpJlJ/Gj
/wCvIKxh6124IgF8q/swwMppjZw9dR1aD5btjfnSk7ks4qMiXszyp1BL8aTWv7kXWtl/IjEUC6Zl
94Wtp3iRO53yaUnuflsfswZkjzLHS8Nowak1C+tNSH84eqKpZM2tqhwA6jvF207u6dJTatNKKO0H
qeXtRamiCDHuoUuQdyMj1LRTLLVVgSti6Wti2OXIW8pv/nV1l3HEdwq6qh782fZR6iPbTJNqXZW5
pamZ2NVXSVLSyXHLoeQ9wtaHeCorP5FjVhaleEziXmpfas0cidu+1GGoRmtRuyJZfVDanJ4cDSVj
KlF1CJjoC5t6l9s3xE26b9CLshvnNDGRIVx90UwXEulYPaYOS1rbkPeZTBUVkcisBIe+QSmieNIs
VVoqWyVx7Uvcj2n+xpECjW2enYsF3K7F9+m39EbuC6YK4ldbvXty37v0eZziS3r2Lci86wysmDVU
DeEVMI9Ufp8iug3D141X3bR/7WNkPWcVOYhwWo6Q/tNlNLJWhF2gWX9iNN3GySx1FfjalTNbIZYk
RVFt2553jfHdyEJzWJOXkkBdmXBU4ViK6z4/x7gDnOHAIzIUg45AfcQV4pbSXMbWkV4xsbys/dhm
l70Zj+5HFxZEKiOtf3pFYmzt0MRd498mzn4qbLpMiDMhOQQ/5e8jWNkI5srdxo5ODByW72LuaQP2
55KNdJLzZGRUI47WtSQjhm3WQEiMEKU3LHdywHcGeUnOe/kOH+1xZLUx5keJEXvtMjRBejkuSG5V
L3OC0qNJZP5tr/2usFSRgoWzLB5FdJqHOyojfzhAQUfUE1yLXOc6XTb+JqxSKmleOWKfxKddm6kC
pVZT5Ajzgyxf6gOHHUHfc6j5eNqpUwi+7V99Ll4SHH5Rxid35EhBgjzGvDPG4j4hOzEjT0Ulm7vL
TMUKGnokmUfux4QHpMnzUY0cxHjkx3kP5CBjQZ7Vbatcd1Uixo92RJhnae5M0tBNGPPO0TPLR4fE
I+XJktACunteKzA+U+D/ABIYbFqyrF/lMpo7o759kxpyS0PHBBekuwnNBHr7FqsnQXSjBIkKFCtW
OPcD87KWL4A5dsNZppCSosCrcCVc2w44YFi0gTVTpMryGwo9POaXNWQVn5pyL4kfXcpjxontjPnS
cfd9im8G4iuiWFIzuSatvCHrOG50iOncdpUPAWtovlh4KJ+j42XLecA8VYVppuW1I2oaf6lLphpC
A0gpdnegU0Wt0sqvl1A656SEkwF0kj50uhBHhSFa0+lYiq6cn8GjeldYX8P6tGoqr6XmqLlgcr7c
djEHTAjmt75kfKLi+NdaZdZS4Omo4I2qoYoNnph+0PXzucsbVe7Sdc6KPVMbzK+L/DtKOcw8B1co
J9k7z4WnJjIUm9oPrSRKAEBZFhDhTZw0twV+nPpTtVW448T89V6r03z8LnLC++F+fjNP2vhPDKbN
BaCYkqERgo8298eSkxpgx2tbJI9rxDA1jmvYM1lKaoKWRtaz5TVjOTvWURRxg21mnGQ/m564vRfS
uJi4mAbzLRuaGNau3FP/AGO0wnjod6du4aikphI+UM6KO62XEbyl1D2sj2bkUYDeLYx5jTC7LUKa
VsgJDXIdrX4oWcQmQKve0zeyxiWrG7NRHHpStECaZMjTEVDMaTHSEGwlsgyCkNO0pUEllYo51Yxj
SDOissGororBub440e+RwaGzbzOrTIw3ab9SRr3SmmbwRMfwE+LNa5iH4vkyUcyNMaikOmeYijvF
5KT2VfmuleMWstWHF3EyZZIHIF20jkO0iHnIFrL1EOKa07XyeCS7tBEg2jZA1MiZYW3aStuUJndR
2S7FAtjX330lsNhpaBQ97xkRLJsgbjI1LK4Qa1l0wze63J1ogUq7hCtO9C42X2GSLztGBPZJY+S0
KMt0fKbMaouO5JzGIKMdo7F9iiw7k/M1M5HGrZXaDfmR+U07xpnmoYYJ3afZzN8hvGdqCVFlWiBH
XXbH5IVTYk3xA39mh3r7rkOUoHU902SNJDGNtr3KW+VuCkMI20uUC2NfvZIiz2SRzbUccc27e6RV
XDZTHTxhHb3qkylvsbNC1tzfbMrLp4TRrARh2l20SQbpVmiPHIxs4Ed17fo9KS95qlmAbbi+UuVN
y+MUNlHUdxqBqNFbGaauuxSB2F8IQp1mQx6S/a1r76MIVxdvkrUXjor230RiXWo+5kWxcA0DUkV4
bLUzEYWweU1NqNg2n1NGaC1t3S31F0sNR6rhbXN95WUl74Tv1RBJkjVUUbLi1fYk6D23pNRx4Qz6
0ikZcTEmmpbRle9muAMFeXw7HIR/FJE1sEI7bWIZo3k7pqfVLa8cjXTDMsZvmEqL59dn65G1svWv
ebB1GSLIXXyo1Neqi2upiWLKzV5IY36+Xa01KWxai/uq9UErEJr4z2kuiEkj14cQya5M9s6wJNLX
3Bq9T62kFaeY4poer5cIX69lNwmuJZUmzXzZULU8uAKfPNYmG9WOiapmQQl1fNOnNXmgXciA42q5
hsFqScBjbI3fXWE5GF1ZPenkOUoNSzYo36rnObPsj2Lt839KYvT46O98X2R39pm+/wCRuyDbmjIe
yKZRW52sLIeZwLgzGsuDMVuopG36iPjrg3ItwZ7RSSBM+3ORiSHNKlsbhJO8jnOXF9/6g3cXRr4g
EW8NISU9SLGtHxsTUJiNkyiGwEpwHD1AVrJFkaQnJWEDdkBhLkx0MRyrFtTBRt8dUPamIgrowsZq
ErsdekXCWhHPFfkZj9RPekqwcVVKqOjXhQ4W+KVo7MjMHemw9yZ6FkuV4LUosfcHKhSqr4loUeJq
A7cPdFKg7IzVbenRC3Jy42aUbhahI3H3pnoacRXBvShT9QmXJFmQmR7cwc+vGfi3Rdvqz0cy7kuZ
9WO3Jc958f0RdsiTiAVt4fhImkMozuG+PcympJsylRSryi2Zw4W4kEaUr3rHsCBVbuU9siSV6ikk
G4NzLRsucc2IVyOiWskaSrSSXHmVViz5AlJcS1YY6kUByMc22moyTLKXI0woMFeTeMm5lkQh3PdG
nyQ4WymPaksgiAvZey3M9uSLuU5rTuV6S5rhnaVVCZwXBuLDJUyUREK5r4trMTCyp2EszvwE+QzE
s7HjJsJJVAY6K2ZZq0sqxehnvV2JiLkZx8UlkrTOJuFyqrVsNpDpGNXdQ+ZtI8tEV3vH72EbN4vV
24mkdiAn7GUqKzdVZGlvaYEpmNVUyMKURSxZzULy3AMj8dXzNjDeNWoq4kGWRh4pg41eWBhmOhay
QNE9ljgeVSU8pEIN4VENSY2lORkiIWNjUVVDVFOkmpkAT3RY8J8jCUJ9niULwRlIv0A72S4hImN9
8jwXHUunzo0g3CIvv0bkaM42fpkipLhkhujtc9wtPklJOpyQ2jYqrEqSTEPpoo2uEo3xILpKu0uR
WyYZIjwieVwdNkMyfSmgoNrnrFonykk6aKBnF7Xwa0krHaTKrZcQkE0WK47waXc9lnUGr0E3uLB0
8SS2dpg0diIvKvpiTFLo57WzYz4RYUJ8p7NIuKK3pCV+RhrIJB0oSWOw0mWKFBryq9Pll5J0W9Ml
xHwz1laSc9dF7iuKclY8f71rNPlnpe6bfVsrojpr42jHEE/RHte0ZKtdv6a+67Y5MkfORgKV9TQc
hWdegXQ6XmKfXKF8Si3AOmTmlGjWpTMdhKT7paD7f0l3lmouAHxeMwdOnan1jhY9myr1X+lT1yzi
jo2oljT9tPFUkmJp/iOVSojZsXtPqKRSsdSIjLKu7OVNd5r2UicZlPkKiRGLUsTJFLsyNT8l+lMw
tQjm2EJQq5rt+Lkx2CGpHVVD9qfUcErabuYlUNuGp+bT1Du9DpEGORUJxLVqpY9SxjG1rXYel949
MNqfTm7rTIrLSAoMqabm11QnCyr+1kUfORCqEeK1re0kavdJLFoEaK0gdpamn7mJVtaj6jm2yrez
hW7KuNGpHVFIjk+kN42FTwyBSKUoqlqJMp/2/SHvkQ6Zg2HqU2m1buVbQtYz6SnCzqVblbSq9zal
qNn1HsGmeU8apaNkqo3Q9Q/vQaVGsLUoqWVSrFqqPPpScbKm/bApFI8dQiNnVG7PozvJhU6MbJqd
2zaZe5WUaNxalHMs6bbKqkVyjqERJ9Mjki0jlkRqdGMl1CObJpnNkVtIjGFquTbOkci1NJ7JV/tt
KVHJVVfFyQPZ1R3G3lYkdV9lyNG776mk/atZ+21ouTaejV7hVCI2xpmkbHoyLLiU7WMmVKObKo3J
JrKJrGFqm8LikXKWi5IlQza2o0Iyuo3POCmYNk6oa5H0rvMrqNghmq2cLijVr6SgTitWNEuKHuhp
KFxXDqgDZY07Djj6fe2bEpRxxHrBvbY0Csl0+n2ja+ABUu6DmlDp9X4sGOxLSnQwazTrlkiqwQwn
rRyGzNOr5dXQsiicCOXL7T3JaDTv7HDiotxSNmAfAUMrTtIxoZAgMXVkAaMTpDjqc1HQtAJ5oqlu
aRsoWntNblI6NCbIgDmgHppUsQQg1gWEDPy8045TU9K2IBJ8d57yhbKDp7TX3JM6PCQ9eOwjx9M8
bNzRVEeMUNmy50z/ACq6qHAiiuQypOoKDyhac040aTLwEJ8yAOzi1mmOE2XIHRAgyh3ArLS//YxY
LKqNE1CKdK1Fp1JQKGhYAEzUAYsidAHaxaTS6Cl2NmOhDXnHdxZGl2ts3BZTxqvUArGRqDTrT5T0
44cOTqlo51pWstIVbSo21q4oowtfrxqdDR2OFqSQSsgaZt5k5utIovATF6rm3t6Pjovy9Mke7s0p
C8o7hNiguZ6vJQy2ygGqkkvILxQDm8rN3vH76jeKS0sgUdjxEqk8mbG4RrZOzMoZ7ZSWcFCBsI/Z
KRMX4/pJmjov8Mq9lZ8hhG1cdCWqs4jlSWolg1pzwIyMAYyCy1I0qabiI2Ob7WKdhDcftuI5DuRF
FIO0CtnOK4b0QVkFJDm0SbOo25Mq+K01LxyBHTa3EiZEEnGVyaoE5DbCa55m9nAOQ+ToyDxbBgsr
pDyqcrdn2bBO+s9yQF6dm6b3H1sb7MkiCy0Kwja6rVxKwSNZfCTjUbCfCY1Q6gGmVI29uUjmZE92
3om8ZafvVM09H8iWCLwEMv3DwkOwFdwQz+yoxIcQqtEednjpGckhC1vIni9pgjIpZEBCoGv7TSn7
T1jpIECt2WQqRsj7ShrWJ3CB7DIh0M6TWo9RwkCzyeJiRGnHHreGTC+OoWeUNtYnckp4w4Z/Jw9a
ik8VI4xzNzyITSsjVyDSRKURmgSSEFWiPnm8VIL/ADGvq2uKYSRgwJbilk16PwUJADJNcyQSMh4s
me2CRkgkjKtqrG1Xxwnz85pqN3ZLY6R4kea50mRCaQUOvaBs2W4ZY4kkxgVze7bkUKVL3SkfXNdI
lsSNGgSHkkz4DXNBGbGFJlPSakZpY0KC0eXR3tfVp5IG1zFl269mNSPeU06C1+OEkeKM5lnFitfH
rIjQMtyl8msZ3oYYLUlXzlYzT3NyS4bXFlN8eDA7qzJkdrgwgNCKcpnToQkJEhxWoTUznudQtdxk
RWeXbqooFON/kzwI8QxNHGMMpLKMNFiS4yku60faiajI+GWytnT+iZppu8lze3CFFc+e0aOiVYka
l7GfJnUYuAO236jqVFcDTsJYb7NiZKTjAh1v8t3vBqGograEsmxox9qMFn/ZarCp2afhpDLaInOz
T+BAre2Y6fwqxNok6u8qzpm8YkJP+w1VG8p9BDbENaJ967TlCq69kZZf+rX+1eWsaezq28YNan87
VMNk2RRR2xTz/wDb1G1CRaquHDbaf4Qf+QOrGaxh+9ZfkUd9o2UWQL/kD/zdFOMiTWBOKBHhMzXh
TpFTpvi9E675vip7YqY7dMk+7s0L7Esv9ewT7+mJatPD9w3z+LIL1dbC2WPZcUSrO91qknshj2DC
ustli3ntI0oq/VJafx7j/MTHZt13zfN/SNN36ZVqgs9kHZnc12m3opHtTxbkisWAXlIgbKC5XbDS
Nzafc1RWe3BTv+oR1+0/j3SN+1OjvkHhQUjMlykE2qd5bzbBalmLdVGc0dG8Ib8tGfthpxSSrdwt
3HH+ZyJtXNy0buyPWcy/tC2ytEZhCvkFqKzssPJ7TXzWml1Wyju/bITfLMyMgWQit4339vluBJrD
qob73Sl3RkrjtFROF98S/wDJ+dKf7jP9fZPKCn20RONin3ICbDEiZZonCsTPblJT9gmfymp+1yJw
nM3PE/xDTLViK2sbs1Nt56JwgN+9thUTtEb/ACY/+FnxZoiurE/azblaf21Ldnv/AL5W3ZEieUn+
H/8Apz28iwU/jiy2RFylbtn/APUsf8UFNpRfgv8AikNTvM/0tRO+/WSQKOE5FBqtq4T2VM0gn8o/
+qm3mO/wj/xWG3Ov/wBQW29ttz0/tsv+ey/14Dk+oyf7FT7UvbvCVPHi+7LhUQ1GvKGn+3b/AOOk
cnnSfiR/r91ElOX7MX/FZkRhahd4If8APdqiLQkQhZC/dsP9SGZPLlORAg9wyjowsBd40Vf3XhGi
k0Be60ip5lw7jEqpKGmzF2jov8c0tGSQL/DlTHgu60ndh64sn93ffPnG5pn/AGjf6YpzfJZ+2LWu
RWXMxI0ykfzCj0+pajJ2x0knyTWhERsr91fCse5Kc5Gw6pyKK1sViWNKu8aMRPqOqz+OPT0hZJLM
iNNZrvX1U95zSnoyHWva+HNmujWtSu0WCZPP1gckV+nSukEsjJ5N2v8AApphJTrEiDiwHItcWaYF
vX/sgVr08zV5Sgmade4rppEWbqvmtfp48mUy4LxYD91VGPLFbgXs1l2/uXWiGcQf8hburtBJtH13
u2p0O1zQa5XanTp+PUnxnzn5dkhM299GSEDJlO7obSM4RtLwE4jmNCk5UkjSMorX38SV3DHiwezM
k+0WPPcyzkG5Q7v/ADaXhqyXPM1I9u5FKTFzfF6rm3oTG5ork2HZbqyx/wAmmVd55VXs3jlR43O8
mDu2Pd78JC++leXg2fJRx/a1bsoT8/Jav2mRkdkn7aSIj5eUsfxsnpyY+ue4pBEi4zUCgyjsfLZY
F3SO5FbYo9Vg79pp2tWW7kkL7aHchsSPs2XyXJNbu2vjf9kwaIC5k8cG5zpNXugrzdG6dX7xUR4o
X7Vuk5D8V5pNUzYVzHVyVns2xa9yVvJrbxycZnsVV/dpoyAmgLyC0a9/yEYNkxrsmNV5AE7bWTm8
pq91kNe1jpqNc8/dGJqtK6WjUHLR7ZDVcYRkYMU9qunblyG7tY6e1r5Be6OI1RuLMRmJK7g1YqmS
QgxgnNfk5qkdDJ2WfUE7s13eHCTsqee1rnyUKEQlQxpaDECcj2HEryiOgQAsWqScqmyv/joSwa00
o3eHECoyzLBGIyYhglAryllIOLJiJMe+h/dSj7EXVZUdj/nfbNNSUFI8nuxwxXd+dOaIUSwQgpUZ
ZBGSEixotq1xJ38jKxnhNPatZKNI8gEOH2pFpZtEgLBDDfDUx5ExsePX2bXsnh8x8TaDHS5Gk6WT
yhVkXwlsbcbHtneTHZW8pFlYsCKrtmGZKhea9DMgRIt6N0qf/NbXR0rmTrsbJiSklxolagj3VyMA
621aca1ySZEicyBGrb1j3zgpY5EG2rAbUQ0sHHSbGrq5kF97fjDldbMlA+ljMeytxwYsMq2VnXt4
RNaQkK9fbG/OVM3xDwLZtgBtUHv3l6yCHT2oGnw0EU9ZEsVTGBqhr7FXMsWRwAq0uNUfyqy0SfGZ
Vx2F1FqJIo9P6g5Y+vDMWwsxVUWDqZyzv2WY2+PUjsdVOJMrLZlkBIUeK7U2p+2mnNQdxroACrdX
jKuLUakIktiDsxmkBqgztSGNPq7RlmPx40LNQ6pc8mm9Q82rFBmoNRtgAo9RHBJF2bEVhZBqo36j
OefUWQ7UJVBDS+1KWYTTuoke0jIqJqTUqxl05DHPLXxI8DLYEWeGPLDR2ZkjW0UESHWs1nqRshnx
6d/UvR3tkj2X8wJixTVN0koFzwIymlsGC3t3DWutGkj9wSmbKaoUVu5ZTGlkWDVD5CMtn2DVj2L0
NLgmGMVra+0k/cc5cXov9BMEn7qA7AAnSEUVmiK/TxGixZbVFcq0i1rW+XDmN7VuZpGyNu9SyGDD
OMjxyHdiVW2rCBcrHqeajGxbNitIRpc/YjXy2BI2YwybtalkcaNe7kemlsGyVNa5oLFrcUzSo6T2
mSrntki2TDNLLaxGWyeQCchBuc3lJINWIZgLFs9HBt5HJ1c9Ek181GjtjNKyJMSLJj2TTNbMQazp
KFHG4o+JJRjZ5WlZHntC7vtMnkdtLewRckO5OVMAZQupbrkzy2K2wtkGkG9chQzmHbNsWhZ9ac00
K2adh5jRtn3So+tu0I10pqNsbrjlbe/uZPG9s62aJorxyHi2bJDJU9BNl3bu/XXKFYWY1jLG7XKq
9V2JMZwsrjg2vvHsMGyGds+1aBi3ZEPAuGyByLBg2WF0976q+5M85iNuLrfKm8Vjh2I3JaXjRpHu
nMPDtRyBTrgYhybp5D1V40jS2ghjtLpxVp75WKlkLjbXmUtyzPJjPw9qOMK5tPKVy7rgCuE6kvdm
uuQNbb3KnyouXxnhu46tttQJtFs3CkQb4JBWeomIyRaEKao1AxGSNRR2itLd0p9PeeKv6kjo21vv
JSDZOjlj6kjdqy1KwqLOcsit1KNBzdUB4TrJ0k1Lf+LhNVxuFleOlOrbN8Ig9XRUHa6k8nBynsNA
1SNg7HVaFHIlqctRqLwmn1gJ4Z9m+Y+stXQVTWQeNrevmZGlPCSJrFgA2GqvKR5HEdV6nfXpM1n3
RzJbpRKy1dAc7XG7LG3JOdT2q1Lv185rLfUK2mfnozduVtyWue/W5CMmWL5ZI8pwXD1nICKxvyz8
GRUdC1NIgtmaqPMYpFI6BaSIBCaumEaeU4zxSCCxNYTWDm2pbBWuXeNqCXCZM1BKlN5+8S0PDebU
s17Xk7pBSHjd+pLBGSpZZjmPwV1MiNlW0iUnJdwTTRsLezi45Vc4RHMz61LRpjEO9irg7GRHQ84s
hGuwMownPsZRER2MeRuPnytiPeRzHPHn1SRj7GQ/EI5zvMO1HzTJhXc1VM+fQvp29sX2xfiQvRuR
iGbhTyCNDIkJhlKqxznTENKY4cuZiyJmFLKVVLJ4OcTn5EjtuI7khpXEqkXHdF9K+jfExFyNMOzP
JlkQ6vVRnIxRypuxnFXObmOBJl4Ux3NfvkeSdMU8tzSveuCklZg5M3Y0k2yTiiwM6Y9CTpTELKKq
gmSd1kzNjmI/E3coWy2ISZIaiTS7glylwsmTsUj1yOWRiulcHFIxwrCRu2XMVDzJGKdzlH5bkOEu
fuYsY0pcM6WrXq9HR5R83mYeVIbjJR1cMs/YkuWiFlkRwJE1cMaaiHO96vXN/ZMEVzVjvnvacElc
3Vix3zXYQUt6Ga8axzyFXhNchgvTGEI1QtnEQ0UqYKIZzhxpqIeHJzsFVwIkxmEBLXDicNWySDX6
ibZxnOxhXMUJZZkNDM1ooz3qOvm7GrpeFE9ixYkkmEiTGtKx/KLXmKi1szDV5m4GpMXPpEtuOppO
SIjg5HFIIq1cpWHjvCokI7GVsoqS4hBdPJK3FIr8jRXyMZTS1aamOjZIVE78riZFhlOv0U/GRGfH
wIXlcyjK5JdcYGMarnBqCHw9KYOKxWLFriScfQla00d4nRYjz5+n3qyVCfHwYVe4VE4rZVMWM1o1
yLVOkoXT7xtKFw3RYL5Cu045UmRCRXxwOMo9P9xs6nJGaNqqsejdIafTjwNcNzSQqx8nH6ZXaVEf
EfFiOkK3S/JlhUkhZHH3Vj6d77ZunHhaADzPj6cUzHaWTJ9MWFgAOMsfTJDNsoToT66qLLz9LJxL
pL2mw3RSdYkZ53RtLqVljpt0VGM/fXaffIbL0n+yRHfFLWVBZrnaQ3Za1T6wsKI+W8GkVUdrpp0R
lVQmlt/SOyS9JbMgU5pJ26P3aXRrVZbVb643TliIrlpdPmn5c6RSICkpST3N0grWn0g16WNU+DKp
dMFlZI0axGTa4sOXTaVdIF+jmsy20lwDS6fLMcmjGcZOjhkbaQHV8mmh+bJZo1pItvTLCn1OkUID
9JAy80l2Y9HpgUsGpdMMr4u+6UVMs9wdJR2jLpiMuamoHVZ/nNv6CZ+NvZccntI982yOLukqKP8A
ZbQEGCprGEHc1atbUUyLHJWM7gKhnb+msVxqpu/0JrmSqNWyEp29mzhdmRCrWPFZU6tQ4O256epe
iYvvm3QQ3FJT0aNZ9LYrbGm2yrpe6RlaNuTqhFalS5549SMbJFU17ZlU5H1tKjB/TWObY1PFKuk5
YysbtNp/2x6hSGFVtY2RVNc09S5Swado2OrWOZY1Gy1VPviV7dptQm0Ol5yB1g2pJqkc0tQ5xYlS
wQyVaK2xqF3qaNBM+mtVLCo9q+j5GZXMyXUIrUpnPkgq2CaetRyS6dVfXUrQjWuRW2NR7VlGiKyu
aqTar2j0qkOGtY1JNWj22db2lK3iuJlLCSVIjVTeM2ra1kuEnkVlSiCNWI1txE4ZR1KKz6UnG0rk
ZlVWoY0erTjMq0yLUoiLCRuEqOTB1jBP8dmNrEK25rkZjoZOXgGXHxXjyDDWUSmoft21Og2V1SmE
gIxG1aFHKpEIWLVNYw1WitkUze7GisRjIbXuk1KMyPCYiPjMRzalrxXsLtkpKhO2Wqag7qG1ErQq
smtp2kDqKuQCNikKv0iTja0g30FSjmSIQg4lcwwdRVyCRc23yuirJNVUaDH4Ily2pO62nodsSEFu
TqlpGRtP/wAoVcEDJFcwiTdPo6TW07QDdECRtvRc8paLg3sR0ywqUMOp0/8Af8YEdsmvYZq6d5yo
laOEB4BSGW9D3H09I0AlSO9bajQ7KPTmyv8AHDkqubIFG04nnJFBXidHFNSx08jpFdVMhA7keVl7
QtKOi0+0QiyIrST6lkqPVaaRJZnArhLHZLb9GFEnkuwRBVs8do/UMIfY01UIQ4YwxM1mxPN06+PF
DK1SJCQ0SYDW7BjInxg/nSEBsgspzYUWVIDJACK0t1BjJFhushHfqTgeVpaC0UeztGxjan7RYeia
5r0tJPgxnyhTG1Edg49nfzQWcBiS4Z7GFVWFhq4z3UZSnZrhonNiaXLIY7R5Mn0xq/KGhWU6ugMh
B1Uv/VaQCNY2sLCXEdpoxpArOsEedPVlTCo751ifUNYNmA1iFsetnWFjLe5jK+i4FzWMmWGbpxxH
h/5AEiSafTxz5WgeCPYon6jInCuqy2D7aQjfpWlXqsvUFb9Th2+my1QdD8VFrVhliaOFJYL/AJBV
v05MXqvqRfb36OT2kZt76ZD5Fi0KCj3k3k/TU9HZ4TZaPjpEFNm7T4vvHOrwvWwR0mFso5MBpXHj
I0GoGfvoLJ3flx0eG6B2yvT3d6l6p00wBJFiokEIcl3kmjo8YYiDZKL2lE3vCBBTlKTtZBf5CLCa
QxQ9pgTbnkR0e1sRBjMZRPaxCjBARMlbiyG7yGeCilkA4NjGVxTxUIviIMbyqx/ZQogwERJK9nIq
94bYCK+SHtNim7jywkK50btjQ6tOQCGEKCjGSH9pwG99g69N5Te0kInex8Fr3ljoJgzr3yRkMjYK
DYYiiIxqGGGA1MlfZyGvdS+it2mj4vX3VPnSMXhjg9sM2ftgkSTYwY32bGZ2FsCtluo46cJ7/HSw
nNJmng5IZ2BmsEU0NyPHLYqEj/4rWb4r40oktYpVEydtKcCpRqOr0yXWo51VTtGkMPaZbs5x6tm7
bEKqtc3iPxmvfPTsirDKZ1wDtsdZueStG9Mn2CDCbUXBYZTzTQy9mNZOSRMqBI2PcyVivmy/NdVU
3HIQ+0HU4+bqrT+4/wBPuXJlF20qR8R2sXuLVj4RtWOxV90+dJhQkl4+1EAQnmGAjxR47RMsSEbI
hs5xARWI68RyZR8nsJFY49gnCLVdzy5gWvZ20YGR3POaJHR4sdrGXvJxadOcVgGeTdb9jT4nNJJj
tcslvGLHCRs4o0UMUTRjtWELKrWfwo4WoTULXFTTou2hRN8myTaFVAcObNYjgsajQyIzlnR27RYj
ERNRAdJJRM4A1r+xtRWEsMjRBVINR6gU60d9IA+uMsmPrdVWVFGR+UVFslnZiq41taOsTYmATcmk
InZZas5wrGwJHJpaN3zbchajMsOXXbzptUPtRNYNY1FmFlk0pHaEdyxHQWT3jmUb3PiSIEV0hi8Y
l40pbagoER1tbhq49HvdTJbmVMWNrONNJZOjTEqIgwRBjf3r2P5NdpkRQ5aNhplb2tmd1bbUSI6J
WxmR81Su1VS077BYkQVWDUOp3Sl01qTxmPtKqQ+E8L2XFV9StZD2UgK+WssVuMptTg+zCj2tWWVc
Me+s0ajmkvLFa4T4w7eFQ1hYE65sYddGq50Wdn/IUYvZT36bdd/UuJjslYmaT/8AVKu8e6b/ACKR
XtmVbvtW/wDik7+dAXYFiZqN/ctoIqjEK2RSlIjo+ol2Wl/9cv8Agv8A/ITF9W3oTNIe1sT+1dvO
ft2v/wClYInCK77Md2TcqUxNu7K24j28539rtu3O2RY6bDBtwnKm1Sn2Wf5Je20Xbyl+SL9uT/mE
n2hbcLDbauT7Q195qptX7KZP7pC/sdt5jf8ACn9lnkH+we2Tviubtjf7pO3Eaby2p+13+Oam54rU
7Y9ss9u3XJ7X39k//IuJ86SO16Ff/FvjcXUEjc8EiePqJ6Jg5XCVQParL4qcJxV7mlzNeywenjzH
7z6xqtFNkMY8Co8NhCWQWPEbHHPmoFtTyMSUnYAbULgmZZsO6FKYjYpu5k1OQK4aothJGFYJWmGJ
uz7Ff21fsS5TuBiVezznbFHbWRDvhAUx6yuQY7axSK2NPV86pJ3I2rJTW5p2Okl5BJEDXSO+lwiP
kwmI2PJmdt55zCDq2/ttrJkVaw6SgarFxxflu2aQX+RIVPEG9FmkcnbGv7LAic4P+qFU5W7+K6fd
uNXJ37BfsVxkWxkrsxy/aklRZDHfYjuRWXBkG+lX+ExyeRcO4soTd2SdyI6Uv8YZuU0zthRnIo7M
3bJXLvCARFJdv4O049SIQieTZO/h1kju2Ex/AKO3FLN/JAv8aGRHt1BJ7BqByrG1BG86VFhMrI15
dvlEPAkMWq3WXT/6OtROdM01Q9xlrYsqgTnSrh8iGSKq4mC9s0S96rqJ6sgKRSG0w5WzHLtD1EYi
2teqtkaeVXQf+QjParM0Urs1i5zK2gVXzK7/AELUpvrtSv8ABZTsl2t1NSmAUMm7LpWG+AfUycqy
NFIdxK6VBSLrSYEenbuTZP1Ad0ev0s7nF18hFkaVarY5ytZZ6kY6RXaaHIXL4jDR62rZDhagtZc+
T+litA6ORhotcU5aRvixY5kNaawarw0ftDk/s1FP96zTscqWclUSr0h7m1ixz4tInCDBei23/IMd
0mNosKiB/wAjPRYGKub+jb0J7Y7N8d8SulAdI9kE6Hj3kNeWmoCK/wAxsVvktlinxN5MX2jTAPKX
weL1/wBabJUNgA+8TUTkXKKF9+RJRoLoiEcT5XF9829O+fPXTx0jWTDd8TY6988hEYKcjmyBqVWv
7I485vKQvcSGzxmrMa0jpHdaICoc0pGoKahEOHuuQ3bYKem8n7qRf44/NRr3yO60Au2QsxG4OYhU
cFXEWRwGGwTJP3sju7LPPax5i95kcXaV81GL5SFYgvuvlcGinI/JLO84ZeyxliiOOTutj/Zx09GP
WShWjHxKSXwwc5CIUXcJ3+2wVh+6R99Au7LbuYnCY/k/G/Okgq3Ce8a+bu+lCrpkLbs6ib+7s9yR
RNRg7xv256fd0sLtisv3Ak/ssawyOBYR+8aGqCEjGkdMDsNa9CuhR0jvlbECSqYQsyH2WusjCJpy
SRWWD+Iq8yZaAQy1vGOMli1jzvQ7I7UDhpTSkaJiCnxfIfIqWtFXhQVgx7WwdRGVxqsfeNTIjY2q
GNcmmHoN0siGFV7DW0cjix5CePMB3SPjOClTIRB28ZslavjFj6rlo5M/On5iRZIpjZIQxUQtlbNC
Ktt2yRviNOQ01sOPDvWvKdElZH4VzJGoBNmJK8sMaKwD7e7YLIVsyYJsJpC2FqyMCpvmSMMFstfI
HAAPUY/NI/yhxQsr22eoWMkRbBJgBRBtfcXjQjp71klHQmyHyrBkCNB1K18kiJLRvaqxzdTsZPjz
Wz48eOOKt/qJGJU3jZwkhCIS1umQw0mo0I5wkm5IlBrAU9ik+bNF348TTzO7fQQBj6fpH7xh9sF1
WoUlIrUiWtR5zwU0YQda9tubZ8ZGapCaVieMy6RCRLQCAm6SrlcpHIkfVkZgzafi+TIrGoCNrEA5
CRx9w2mI6Rg6gVhondbBsKO3ZIjkqQkLIshV8WgsRndPhgnLHjRIrbW4jRJjZAbCKyFEh5qy8AwA
PcmmGxgAt5Uc0ajuxAkSxwZqpYxa9ltqUh7GlvQygyreLFGy/wDLtAW0NYzUq0JKuIDI9QWFNshO
rQZqHU444dP6hdCkEtYEyLH1BDjn1DZxWPrNSQpYEmU7M1LqtjIukbmPEU97VHSXqSHGjVOrXpYO
vakwvr9aDNUX62sheu/Vem+fGJi9FXD4uDerHUV7xyxnCMGosBhbbWqPbTXHAL7ITiR7QfDzwcpV
oJmOuG9qwlI+SC6YoLaYh3QJwhBsbjdJEhSq9ei+hfSmMJxWjvVZjbYKtn26LkS4URAW43JNtR7O
s3sPBu2OYa0FwsLVXPqrtUT6oJWWVqitgXDhPDbick61a1Pqrxmh3TCMk2o2pMtHOfWXe7VtB8LC
05ZAuVE8NqJ7J9siIG3IMsS6GRsq2YxJNs7uV121WvtB8LG1V61t128bbCVllctTIty4JY9yIjZl
wxiEtnoWBeMcwtsPadbcnVl7s36sFW2VtySDduE8FwNzZ1w1rfqzhnhXbHpKthtbZWKlV798XG/N
HZMEi3AVDcyWkWplIIkW4Eg7icMuANxlVloMY7K1ERksyKentGMSRcDIOzkIr6i77bfqIH4e4Exs
XUCIRboBES1jDyXeDR8a9EVrrONlncM4qfctRbjC2TqEJBgv2CKl3HI0t4EaT7hzyV2omcZWoQo1
l05ZINRg7X1yNvM1FHUK2CJOXUgPGspfkkqpLY5YupY4RW90CSyNPdGkRtSBeF2pQCJKvhGbC1M0
eLqSHk7UontgaiWO5uqIbkk6mj8LOwdKevwmMfstNqBYmE1eHt2Nq6XkC0fDezV4kbY6h8rAynjJ
E1U0I7DVDTtIZTFrNSLCbJ1ax45c98h1bcLAc7WbFbPuVmLGlvjkBrFGDsdSLNxpFR1fqp8MUvVr
5WFkd8lbeFrnm1or2TLJ8t0Wa+I/9blRtjePm4IvbfF1YaMObqYstvcV74F8euyVqwhhFlvOsSaS
Gq6zOjJdkSdgTKJwdVygjl3hpmQbc0BzdZyRo/WkpVlagkTchahlwh/rOYmE1TKkNDqSWHF1ZNbh
NVzHJMmFlu398Y7gsW9lAYbUEsiPMpHxLA0fC6hn5JlPlOAZws+vTGNlWcmRg3bYC2kDaSzluzdd
xSTBb9UlYSbIfgJBWYthLx1jJTHGcRWzzMRbE+PIpMa7BmMNFlHXGvdnelcSlkbNXGMfiuLjX8Va
p1xUkphFNgxK7FZIxWuTG++JHkLjo5Gp3F3QZCIgZCY9XJjHricnYQT241d8SKV6FY8ePd6V9X4V
ei5Jxfn8xwOIroZ2iFGI/DRyibGCUuLAeijrzqngGx9eRqfTzbHC4eCgmchwuYoYj34aOQeOR2Li
4vTbpv0TqnSKBxVHXHVpIzxqqLzDXSFaWEQeFYu8eCZ7XwTsaRjkyOAhnJXGRDxyMxrXK8dcdzTQ
iixzXZHhGIhIJmtex6LHrTPb9MNh4Tx42O97x1Btjw3jxzXco9ad7SQCCwrHNyNDJIT6cYbThezI
4XmIypMiHjEZnae50eqO5pq8jEMxW5FrCnR9WRiHE5josIkh30cnGTFePBCeQgaY3E8J4cbEeV46
UitWlc1JUNw8cz36MVyrGqTkaaocxpBOEsSvLJx9K9GyYjhZHilkuZSP4ya5zEYN7nR6Mj2yKlzE
DUlK5tHshadWIkApCBolwlL7SobwqrlTO6uK7N/eFWklYeocFgK0hXD0+mxKLbJMB7Vi0ji4SiRq
FhvY+LQdxP083Y1GrcBp3ln6dYmO003aXXLGWFVulYun02lV6gVfZd8a1XLCpHHRNPsyRQIzI9UQ
rmadZhtOtRJ0NYzl6JkWO47gad/ZNo+wnZ/fBoVIw2n0Y2VGcAlfTulYTTacZ1a6IsGE6Uo9M+06
kUGQaFxm/pweS9PIxsKlfIf+m2bH00PhOhuhuz36BYr1r9PPktsaPxkrKEkrE0y3JWm04Or3slxN
NcxzNNI1rK5/fh6Zd2l00xcmacULoml1MP8AS+yn0knbsYfhyKqgJKQ+l29u0rnwTVcV8ooNKd4V
5VJXkqKIkxS6W7Y7OO2Kal04+Xn6VyVpVnC0gOgSts2xqZUwHTXg0lsK6012mRwKQ9VpRxBT9KjQ
UqK6Eej02+ahtKNaK+qVrzU9Utgo9JcA3emO3lLpRSiXTA0yx0s1waPTKnkfpYI0NpcTm3lStdIX
NtkRMDHcVaHSvfbqrToo0XTOm/KYShhgQ2mY8gU2jKCxpdLjQU7TMZ4z0pQWVTpyM0H0qu5XulWO
jaf0uNUdV1gVk6biyQ1+l1ZYfR66KH6TAlMs9KPSwhUMIEccOsI7UWl2rHCNxT6b0v3M1NQxh11J
SEnPgUcKMy207GmRLSAWvP0Xrt6G++b9HdJaYqe4B9wlDSJtaRxsFQxxmbZ1CEZS1HEcyMMbocFi
jfGGj5ERitDUoVltQZGqUQF7E7OU4hkHOqEeyfEUDnt/qBH3CUlMg2MjsyfVI9sCj3K2INuSa5pU
JSK6TGr2BG+EwjbGn/fXVDQNSKzafVIra+l2ekdiZKrWFaOi5SRQmDYSCMiGqU8hghsQTGEfNrEc
2LTNY5sZmS6xpGRqXco4bGYWA0rZFLyNGrWAH4Y3JYU6LlfUJHRsVi5Oqkc2FTbPbFY3D1yFYtF3
DAgsEx0Jj0nU3cdCq2hGkVmWFSipXUqDUcRiZKq2kbCqEY4kRo0DEYVtzWI1Jgu2/NvfT0Lyjxa5
OEyC1BzoiLKrK5GiNBGjLaMiZQ137UgMRtrFa1tPAQxgV7UZOgM2iVybGCMapXsKx0NoCfbbkeKM
7buCiItU8zlonph69wsrKl0h9RTsaO1rBoCsrm4YIg4GIOQyTTcjBrmha+IIqS6prXhaMbQeOV8q
CzgLstQkyMjo0QJhagit79HVp2ixgoy6iouMoyGz9OEYga1wZELgEQ5sZSEr2GFDqWtyc4MbI0Uc
sGpoKDxfdVTBp76Ur0OqxRAHaMG5seE0tlCgMjgn9h7LQLTH0/WtHHldhmXoxuZpOtaVhUEBspgi
vjQxxwns2pKLBYQAVFEcbUTGujMZKiaiio4odNd1rtM/tkVZIz6GiUz4cRkMWpxorqOGwMayu3xp
MYTZUVlG002UdlYMXCyZNgChyX6jZGFTWRbA1z2wMdqcEccbVhpkvlzi2YEPc1URseLLsWctSPYb
NP15mkhNcwGoYnl2cKvZDi3VxN7rQlNNoo4xQ76ynAlVm8iJrxrWk6MzRsJrks5LogJVuKRDpQpI
tXMSPG+topbF6TrKkAg4Ntb+FI1PPHKDouGjA3kt8MTLlk1kdE8ST5/1iO3+BM1M2tlmtJlzJqWr
FjapRLWTF0W5RF0Q1rbTT74JNOac2aFGDZrD/Q01x+n6rhyjTqEbxxfFHItNRynQomlpkiQmqo6R
Y36ukyQ6dqDuJc2jK+FH1hLV3gzrCRUDUEPUGoDVlw+bN1ASir/po9V6iVCH1DOsW6aoXR2akuWR
Y+mtOfuAQQE1P/42kYjOxq6TIE3TDi9j/kiMwLOu/VeqLtiZ+cXJPvjsp2o+xjBQYNQSXIShnePK
isSYwsVscd9J/dVLyjzAK1ZM9W5Wk3EUbDJ2ERmpWe1dMWNIa3uR9QhTc+L7dPz/AEKJiPs2jRgj
EeM/DkEEZvbnbsyB9wAorVfLHwyARXmKBHkKFGjc9zZKj5BZHRBzdx5ETuBBFTJouOV7ldlizi3y
HEfXBVCv+O0nblchvAzmEEVu1gxWJWuUjUjI4kkPFI7tzuAhFfHawZnOaYbOYRRGolgijyD+9g4r
VWaHg2A5XOWO17yx+I0crZCCQg2xWsZN3G+InMYxoizg7thMVuXf9lh/ldifOlI/aVA7RrSaoVjm
SXLrQ/YuDKBZE5JRKEScbT7Q59jvmnh5JZsCXZdo9aTujnx93Rk2FdyXMfDaQ7gv8dhzJJIGtTis
Fq5JgMV1bWtbgWINk9vKPWbZYxueVw+DERHEsG7DrOSluh7B3knPXw+0lpZ9gRLmS8lZDNKKA/ix
p5WyJtUzhG1CRYywiLYljUw0Z9IDlzVtA0RSrJr4f7v7I8QnPLKJ3VgN7IdWP9nt26ATd+kI6DbZ
JvFsrV436aH3jKm7buY6GerL58mvbwiaocoFJPdJkaYD2o94n8SPZOWZEf3oz67aVIdwjWjTmmUl
MrG2ViyEKoEtqeSOLDEOTElYSK054MYccLffL4XMdQ5VjTK5jyD+2CBl6BDuoRowGsG7hoKR8jNh
1MXUWoVOSOJ0h9BQcMtrkcGPUvbYWIP8WripFNSQH2jwgFVAjmSQOd73L0TiaNDeWdRN4UiPSNOF
E5R3I0OtufkZtkLj39LoJAXSsSBNmq6RpDsIpduGppDPN0+8SyYO3i64khEsMv3NNuE6LqQohQIB
FkWtc1zIb7GubKNuSBIrCnt6akHBFqnUvji0fHSS/UNgSsgV+uCkz6vEsCRmsZHFHQb72O08HTsd
RAttQQq6RCOyUCCJR2Oo1ag6tGeRrP3qdNacVyTpoamLbXRrSRXSfEkQdaRO2B/nQ7enee8qaYUE
Gp9T+O0IiTJGn9P9hLm9BURI1g+dcVc+GkICRiEuGsdX6f4ol7LHGl070LL/AOTV/Z6t8/OfOfnj
774uScX+6pXawE7+PqJv3IQnEl0qdsM39wb0Tu7TO/jTpTWsnMcV0H9sY1r45o0pDC1J7oFN5Uf/
AFtRrhflU9G2fj0be1F7Wu+45bvvJ/iE5O3Yu/bVu/ihciPmuysd/Jc7Z51/YRUWXv8Aba5O3Yu9
oSp2AvTJzvasXdbVf2KXsFqbNpTr+5qbIOa9OUfbtAem1i72rPZg3Jzlv9on+zy9yKnA67yRL9sb
042L/wBsBfthImTX/tr/AO5F9zvThvvNaqIzmissF5OhrsMae883abAkoTLoe7bL2KvynsukZPJ6
m/iX0lFdTn7cytN9nUR9kUqtkacNuO7NsKxMrjaVlcklk/jWJOc+qZxFYT0C6GTvCm1/dKyKgGWU
xyJSjc4kv7ceXOkMlDs35DtxNbBmMOsn/DAYmWc3x8rJHkDYiNdPf+ys/wA9m3uCi1qNWfK7DbBs
iS6uid2TXQUGG9tOxkOW586nJ3ImqZDlTSWylI9BtJbjYW0sO+xwSsPXXMhDD+9HjhRiXlgSKtOd
ZMfVw0ajugXbLo07iJdEUcGzIpJWlpD2nV32NTyHukVJFFIqXqSFrOS5ME9UJpMriA1MRWxqRe9Z
jRGRDWEj6m5vONGpUNJtJSVwpKntCaUAsduqGq6NGDKR4JMmCQOs0TKuw+oCvC8QwNvGu5Uhs+Bu
6FGc1MvnPRdPc/HuReZKFCZXxbqdIllkUZhj0nEQ8iVtDh31k+RNoVXzIntG1pzWVodP2X+/YpF/
6+Y3/t5i/wASAM6XhNkBD27WpGmdaUm/g692cdVzfBpmi2qiatR308aKzNJsVTTf9S45jtalFWXU
Jxga9Y/yh++aOYrAa4Yr4emE2ktXeCteZb4H7INZXDcfVEw0YcbTUiYunIf02Rq0LpFdWackyMst
PkrmBu5XHSbykHqjueLp928DVVeU9vQjUUP6iMdxqGItpF0/WvgpaygTSvCkODJrrC4nn0SowxNI
98P6dNFnViKKDDiCNY6sWSwFXpA810LTQ66XZiUEIdFNtZdno7xow5Lxt0aAmaqG4lXpO3GwWpaF
1wSrElULXFyKxL61zfPziri4rt8k++OTIz+3IqrFskNzDQzdORPvGmeKyHatltt4qFyrRGhmxe69
8NrRgcjBagfxWrkfxNQk9qaB3HkkoMVzLQykXF+VTF6b9ds26b5AN2JldPZIAsfuPLKRjA2jFUzE
PjVSOxbNrC91JDBDQGSLBonCmodOx+88rg2NaMLhWIVe6gGNtWtKpUkNZsDJUtrl8Jpmwq1AHIZB
tHYtdhBoVXSUEwVo3mRySEGqBR9o1hGyUOxrEFh7BBZHsWnRWIriy0G0FsxznbHXudlv1ZrCeQh2
t2BkizQTgz2mTgiOkT0CyNbNMrmtIvfQTY1m1z5iodsPYWXMpFZYORxXdNKC7LuTfGvmpyqA7yq9
ydnUOy5w5yqLZjbpUcKwbuTTIkC2W9PHs3I2VUy0UUwSGdHK0LBHY90vZzGQUcrRpGIQiEE6G1ST
4iNbJe9pdNrwScROxXykTLBjT5De2OyVcNERshJTB8QYW1a+QJ7VCeN3DS61rBB4isWykbCvzI4t
OzmeocjQam4rmnTtjSXyEMDwUeSTGEJQwRkYyvRhSTWABCtGEycJJKxTNhg1RYI/HLiYFu79KsSO
y5VPFt0RD6TD+95EWNqVrXOoQ96RWuRsbVXEmR2I6ZpxnZDqFzXgiEbDsoc1smO6D96ZZDEOtmMe
GwheWoq8IwiniiSZKJMaKvFHzUJozBwRd+TQs8eNfFa0dXYNIMtehXyLBkGOPUbWWACsljmWgoQ6
W282xNwOKNWAYTUDooo+l5LGWdvaMSFOXlO0tHaQopQ0DqpGPzS1v46SCDOOHZBCtlNGMsKyDLjJ
GiiJd6hFGFp++HJYUEQ6ybcNfGv7L6nLzfILW97T0iJGBdz4pYtjxfM0o+GFsi3hODqcwiG0x47D
xreCIOrJ0UuVnbSRS2dfGj39xBNHZK7M6n1PFMFZ9SjrXVQAioNRxGxiXFUZf1LWx2z9VtbZC1FX
GEuoayPmpNSusFgvaI1NqGvjgttTwTjpNVDARdTVT8l6whCAS4LJsKnWEcTLLWwe1W3SBm/rWv4J
rGsRbLW8Ysei1ekZV1rWKtlrMXj0GsBRldreC/P17BHkvWYymfr6Fia9gpl5roMqOFfem1nHiima
9jmH9SX6lA14wYL3WazY73b5v1Xrt1/OOXfF3zf2ke6OxF2Wpt3QSPvglDX2rQEn3jStqrbxHl1A
xyxtQiHn6hA7JF+JWN1EPaysEl5AvEEKzsfJWBatjtm3qEQ0hz1cvo+c26J136J7ZVWz4hA6mDxm
Xffxs1wixdQtRsq+QjZE5731992mk1GzjPsXSMgW747maia1s257yBsHBLH1I3aVftK18t3OFqBG
NNqFiskWTnEhahaxv6hjrky9RyMtXjMLUrGtl3aGRZb0fD1EjcNqFjmypznur7tQtXUQ+M61U6wr
R0V4tSD4zrvvIOY4ZImpGsyVqBHtkTnvfX36hQmpR8ZtmshYFs6PiamGrJ1x38jz3xixtSjY2XqB
pUBavEeNqMeE1GHaxuvIwjubndKm3SLn6qCrLK0ZKyDL8UkfVARssrscpGG4ng6kGBsvUojNlm7r
628ZDR+rAvHOneUtfdrGxmpg7SNSjc0Go+05urROz9VByXqLvZF1QjM/VUdcsL/vo4y867UDYyE1
YwzG37hlHq0XE2qxvbKsXHfC1CsVD6p7rfqb0OHVyDaurmZJ1Z3WusFU/wCpl7MuUp1hS1jEj6w4
Nn6jWW1kxzCRNVuE12ruTZt2SSsPUZILf1o7aZqZ0nItuaKRurytSVqohWSpT5DlxfbBv4LB1JIi
sPq2QZkqU+S6vuTQEXVshzJtmWa6HNfDezVcpGzbs81GEVjwajlBSVqaUdpJCvLFvJEZn6qlLkm8
kSFi6gkx2rqeZs/VMri61IYiajltwmo5jkNKed41c1R38sKGu5J2x7KUFfrs9WyLaUZN13DZywoe
xknwEsgHfW52Pu57cLYyDoBz2KQkxzV33Acgs8+e7DFOTGEVFHJlrjiyhq6WUijkSEx0mfs8ziOG
R6L3Jy4aRIXHdNsZ7YIxN3glkxzXCc1y79uUZCRjswRMZ3noaJK23Vqs5Lj4Mlc4PEowPIn02SqE
AQWDY42fT5eHgymoiq3G7lxa2Ts5jx4IDyY6tkIjk4uYiqqVR3sMB8fGt3UUEx2mrzR28vdnJ6/S
5D2ljEj5HhFkZ9GlLkitNFyLCfLSTVHCnsnQQ1Iv0aURJEV8Vfx0G1XYylkGbMryw2u6/Pr26flf
bOOSMdm2RIymelIohx4D5BZFMoWRYKySOplYgaRz0+huTCUStRlI52S6x4ciVDzNmwFj5Dr1ktlV
jxoQasVyenfFXE6r1Y3ksGkUjT0zmNkgUKwq18vEpFa2XBUSx47zFHRuVsqseHO0qki0r3NkVCja
cCjdAqnyWupFRkqG4WQ4DpT2UP7ZdaosHHc4kWjdxk1DhocSsdBp1Ox9JxZJhuEsKudJVtFsyZXK
FARHSCx6DZJlS4aOju5wqDkw1LxSVGcJ1dUPkp9C2ZNgKFIcF0twtPNa2ZU9rEiq8sWhTjKpuKGj
qwlfRq9pKJEbOhKDINUsvGUDWsn1nZwrVZ0/IhKV8Cg9pFJs2XDULq+kU+fQEaybWKHIFasl4tPp
xm1HbQMRxixdPJtKo+CRaHniUDNiUbUT6IryCoWIjqRvGfXdlpG7O26NRXZV0bpKSqLtMkgUZK+s
dLd+nkYKVXK0kCh3YWkTtza1wnV1GpsWhbwn1HaSFVvO8VAiMnUXFG1pFNC09+yXRo1JVc4ZKyiV
7TULUZYVThrXVDpCs0+xGWNJ28jVbzFi0H7J9EiJNjOjvzbfBD7i0+n1LjtPtay0pFFlbTOkkHpx
GtsqH2i1hCFg6Z+1PoP2nrCDkVOnVK2Rp39lnTLHdS0iyVdp3iy1olZlbUvlEBphWis6D9rKwvk1
mmtxzdPIjJ9S+Oel06p8JpzgO6pXR1qqN0hw9M8R3FBs2FVFPJg6W2DY6dTgaqIKRT6X5Nlae4tt
6Z8Y1Jp1ZGLppqNu9PKjaimJLNG0u1gbXTiOYCoL5NRpZiCm6bZxsKR8eZRaZ7mF02Nrb7T6iyko
XS3M00MQ73TbSCOB8cvRuaeo1mP/AE2AQ7/TzVFU1r5cuu0xHCCxoo5BSK5Y1lQaYGo5FJGa3U1S
kJ+mqBJmLRRQtudONK6q01GBHeGu7tnp4Z42n9NhAph1kfPpAZQtSVS183TenUI1auGPNR0TXZQa
YGMdqWtissnskTdO6cU+eFBjjvdODlRqmgMaXEqoteGXXxp8W8pn1kjSdN5i+JEhhuqAMoVJRBjg
kXtWCZKqo9jCoWxocq9rwOgKNyO+M0hSNOwyxIbdXUgTRgxiEZ4J8WO5i6b053FdIjVwrKpHbw7e
vdXyN/QvT8dU6bb4qbYffZ+MbuunqVOFhwEKkKJ0uVCaZtdSoItg1gkq2MIyQjGPL2lFChsI2ypU
Iyvq+A7+KjUpDjapoLTCuYHYUrcTFTETNv6G2UUbyrAMRohSGjVtzHbvTV6DjKNjW2o2PzTFej87
LR5ZDYrIcFDWQozWCktZwnRkfJr4aDjkQbWW4WuZp2CnY7LWJZDY5tNDQk1kdjEmtGrSxkJPhwkY
EzRo23E1co69EAomDbZiG5mn4KPe2OxiWDRqyPEaWwBCawcpo+FmBry1cFGiINjGXA2qzT8BOHZY
Ntk1ipVQ0LNDEaxJyDVpIrSzYMJEFIaNG24WuWlgNQTgsG22GxzZzf3bZtmmo3elRISIKYguE4CP
kVMFO1IQbG3LWq3T9eisUTBNtWsVKeMh5IojRMloN+RIjOMlzAKALJA5QmBJ57B5CewzLqI1UbSK
Ry6damSqdWZUUjiPqq5gR2wGuikr1lTqWoaJHhYoiVyFnNjNjiGQUrJlMhXRa1oG+QzlLrEKyFUI
LCyRx1dCbLEGjRDFRkJg+3YMkUiPKyIyKEMpkl02oQmQqtI7HTmDNJr2yBQ6VrSTJLYTkC2cLU9c
gsVPfNOwklGjwmxYw7BpizapCtralkZJFkkYz4bZIYlMiGmykr2x3JYjJRtfJIxsONDsPOfPqWly
FAZCD9YXyZNew4qyoZGyfYrEMJjZ0cVKzyrA6QAVc36m2ZTtIXtNhRYdusqVYVrTMrq1kNku3cKX
4zZUaDUjCa6nugpXG+oAJTMdMmPSHEpbJ9g+wqxnSOBsMDbcnnniMkBrK5kbLuzJHkQ/5cUVUNJd
zJWJHoZRJiTKwZiPRIkOBaHLNnQmHHWwWxR2NodlnFG2XF1oBI0roFm66PBwj3pngFL1Gj4+kQON
Mm7+M/ULorwk+o3EAfaiWtiWvmXlolqTS4O1D1KQsZkK7bMc77kQNEZtsd3bhStRyRTa6FIuJDCM
qId1P+tXFBH7EHVjzRi1Nqlo47No03TEiYf6AWFMqBNHCuGyZFvWN3hQgsbL1h3lHpgbwC16Fvja
NgqCPqgLzV0TUJGnrJTCwC6Wee2ii7UeF73x2tIy70wEoHVxWTNMQfGh6whEkABbyLRlJpiOGN9L
ruVzpoLwUg0ZG1PXksJ9EitH/wAk/tm/HT4xflfRtiZvi9ZGP+Qf5KsaeNqR7kbFOoJdQXy2KFrG
X5800vKLLjo7LE6gbRn5B7zFxuamZtjiKIlYvOJqJicDtxW7Yvr/AAiZtm2aUD99Bco9obs4wvly
qse4Lb7WTJrlNpsaMHYj4ssZzmZp13dO4SePaSFDkQvlSYAkeG3coVPJUpKAadq0ZwZYz1Gun0Tl
JEiAtZLhZVk78qKPePbEUSrJ756Qe47b7aTpyo/Tg04zR8Q2ktwsol7phiRY1udQ5FP5MmrHyDcO
UeSJndJp9qcLRvBllOcN2ntnOIxPGuJKhdVl78mENPHuiKFVk+RJo2Io7hO2yznuRTk5rjU3zSom
o4TP4t2dwVhSUkyqpnEF87s4eb3D6db+219o9lYKN+mmcsO37FjKcKRTm5DmgR+RW8GXqvV1bXOX
Fe2MNsrzJA4bGDIaNucTCurYzERmyJLbzjw4Le8NrWJghIkqc3cdSPhJ2wibsUfGaifty0CjnwU2
j5aD5jpG8W7ZKbyDXh4WGO/tmATyBpsNE2y5FzdTp/D1j/aqY350f/sSU3AEKDnOxMsgp3Y3+smW
wULlJ/rfme3nHqRoOe73x/8AjeJGS8b8W4kV9am0JPm1G0jKJqMxU95abx4IhssnfCZMEzuh/wAL
MtxtI+k/1P8A+pZIix6dGMmk+Cf4kYxkr/8AiP8AstmsU1d/pt/yXCIraTjuT+6Z/qxe22Sb+wX9
srgkiDt4+vf3SukEvYLpqUyTG1PLZGrZEjyJGjbBpFkkQAL6wbKm6ZnNBJjO7gNdWaOkVx+weilJ
Ki61sEiV+nwpLnMb4cQOrGyZs0XehQ9PLLtRNBUxNR6hfONVyPEl08jyoevLVYgtFf5Jh/GBV6uf
ZTLGIwwq/wD1S2QhWlevKLF2WTqacKCSlM2QT/kB/GNo6wfIi6wsHV1R5DjOqtSyYGQdZzDyY5O5
Hq/e51ERRVmmzrKha5CkE+lZTzwf+QLQtfF0i3eya5Bxn6rqWGPq2IVlO7mC2tmwLyjf3B/8kO3t
lxeu+J13z4z8dPxIx+D9n1BOUTUI1ekcCkl0QPFGRyOZqCIr00uv8WfJUeTBPlJTM2DZzXRHVM/y
A6hXliiUhKj9sPUC7tOv7if1NMSFZYdxWxr4q7pIcGRUF/jXhV4SHry0kdSRbUqq2zJuTS51815F
8a9eqrDM4cyC9Wx74i7Hf9zTJlfFtSLwsV3LpKQ5zpRV7F0VVfUGUc2MT+NfEVEeVWkoSr49yVeE
9VV2kzueKwKvauiKrtNnd5yFVI96VVyIVw5VYRUDeEXjLfxLpkyrHtyr27R3J2kTuc4hV8a9J++o
K5s+GR3j6geq4pVbI0+Ve1eFXhZP3IvT86TK7y2OXxNQvdvXvcObUvXtaie7YrlQ+mSOVl0R3YtH
q4ukyuVJD18W0IrptTt2rWQQS1z3EFJgoZ6xvHZOcQy00JQkk/6thGOSSiyAZG1G2OlTbjmrJdxC
a6bELX6jHJK13JnkIkmYTcdduhHnaxXkRR/udK7qNGyQ16T93lhrxjtktV1k/dtRyYjpLWklk+zA
R3lmOgs7yOYdrySUIjABktI215Eyr+1G1fK5NVf2tXNHERkghuccDCunSToJgZDSMsGvIQLu3Gjz
GkW2VzspWOFFWYxJE9/IFQIiS5cxoMUyPCscpJpzoEceWwrLYZTvgt7EQU9jjWyKZtCAgWGnNZIk
EQkWuiFSfOlNjijy2lZLimLKQjY8eHPYVLsL5OVAVixVsR+bYfyI1DCKA8+ewGd9po7Kwr58uUyK
CtnskCt4RZZYf8SHFthklW4lkjooT4Y5lsIcsxEkxYNSQUy1sBRA189kgc6oLJmMKyDE1XNSVM6B
/eukQ9uNrOOsiG1qjdosCqWzTnCs46x5unRKSVDbwi62iO8yE3uG0yHtQ9dxHSo2lF7Ug7kNEh0Z
BWcgiCiVARtDqiBKsD1+i9g2tP4dlRC7MH/kCESS/R5WoWd/IhU2nyw5dtKbEhUN0OUGTptsybIm
Bp4VNqcJ5trVsum18NlPH1bdpbStIwljh1tDdNqnM7L6rTxLBlLpDwy29wKoiaUlebJuIrpkGkiO
rRazkfUp2mobosbXtc+cHTUhkaej/JgM0S7zJlLEhxNMajaVZtCGwkTJwqGHqC4W6n9FT1b4nxi/
GO98P8OxM07eI9kxjTjrYqNsSSkAGDe92RYcSjqRtjNmsaZeyxo4hGjZqEvIem5KeJdnRzaWO0xF
ktAO4sUIpX4rt+u/rTPnNLhTyEIihvGI7Iwu7Nq3taC52cyU3YmnUaEM96Ky2aiE0wNrSK9OxeJl
aLnMhEb2brZzTpvIo9hCsnIo7RuztNsQaGe1QXTU50wf5QDJ2LpUc1BoWXTkRgbZyOZYf5NPMQI5
r2qC59nacGjCDM3sXmy5XMR0uuM1A3Tke2Q3eRQvaIdoVrg2jPu6bRAop2qC9am9Iz+VFO1A3zkf
g2NfKqCo0VwRHss/8jvnNs0yiDVkhvjXzt8qmNWXWSGNFfPR7XI1ZdCRo22xWvHa/wCTTvETSyW+
PbqiSKWyYozq06DlIFgbFivOZpWDjs3O9kZ7JzCjUTVfYdpjJj0cbTioJs2U3x7x/wBzTeyPHKYk
efO8eRDshyRvkjE221BwdVXbTp3Rty3vO0Om1ArlYYZMn27IrI+o3eXFmslskz2RmzdROSVWW7Jg
3SRx2W+oMptQoXGnHtb3yMbVagVCilCO2yuGR2W9osx6rifMGW6MSkvGSRLLCJl3qLZKLUPJUlhT
LfUKDZXahIyRHsgnZY3TI7TajL51VciliPaBjiutQOIWg1D3G/UY423upMo9QECUVjG43Wo2jZHv
jJMgXUeSGw1EIAp94YsyjvhmYW5jABd6hfJdRag7OMuYrEv9TbpV3pIxoV3FMG51OxjH2xll1Gpg
lFP1JHEC0vHzD6f1F28XUUQYr7UayHUl4+EQOpYfbvdUNfkSyKKXW6pjPBa6rAgpNoWRJotUsC2R
q2GwN5dvsX0N46Cqavho3UOq1lNd89K8rQSK3VsCMG51fEkhOTuzKLU0OGOXraGo7yxbYG09cBrn
pruIwepNQhs0qpaQzRNdQQhu9ZxpwI0lRyKvW7AidryJtcaxWWlVrocWKv8AyFHwv/IgtjaieawF
/wAhBEy51o2wHClOiEgf8geOB/8AyKN7bzUxLdKyyJXP/wD0L7d1fltnAO4Lq/XJYobbWR7EUQqx
jQ/+QixwS9fllMOVZB6nV8iqaX/kQzm2tm+2NVXRqpXf8iScla9lGaKeVkwH/IEsIbLWkuwGBeGV
+sZlc13/ACHOy21LLtwxZSxCC1zNCG4vJNurl67+tF9vz+Fzf2L8E/uTI5nBeDUr1Glu9smRfPKM
FgQB3ahe9gdRPZn6n3x+pHuaO9K3Jlm46V9uSHku1JJSHZOjIe5eVhCK9y4qdFX1fPVMr7B8PA6p
Jwl2r5KNkdl8XUjhpJu3nacqvdDvHgwmonlbLkqXIlk6IjNTEc2VYPNgZKgKDUrmJKuXyEcZecS+
eDCXrztlHUqw7R0VE1GR7Zk1xljzHRnC1GRGS7VxkQytJE1EQOSLwhkOZSOi3L4ufqApWy5SnWLY
OiKzUheEuxfIQMhQvBqArEkXJDNIRVJEuyAwl6UzZR3EyJaEi4zUJnpLmENkaW4Dg6iMxsu1MZql
4Ph3xhpIuzmbJepHO91XEXIdi+NgtRSXsmz3yMDIcB8fUZxpLuJB2qRecW+OBC3korZJXPdEtjRs
S/lESXKMfAT3xlBqGZxPdynIO4KNw9RynY69lbSLgxcBdShZ9cmuSXPOZN13iTZkdpb6ZxPJfIWH
IkBxbqcxJNkYyxbCSxSWc4iHe9XR5JRK2zsFZKKUqje5uBsZzWyzyS4m+8WbKHkmTLejlcqxTyB4
+bPe2R3NxHeNR2U17Jamcg3OTI55+0p81+PRc36IvuA7x53p8lsiOVEY5yYGTOVDxpLsXkxwJErC
AnvxzHtWOUrVeydIQkcrFBGK7PGnqh4R2KKO8mJFnbHhS0z3RUlEHjpBX9BvXGjkHQkQgcBFIXFr
ZioWtONGoqKKDIKhoUgKDRSY2tkEb9IlOR8QrCNq5Lm/RZmEppI2qxWOFCMbC1EkaORRuCx5nEo5
DkOF4HITZFeuJ+7I0Nx8/T51yTTyQI5qoub7Y33wMdSubp0z0lQixHMbvgKQklkumNEaz3yNUukq
bTsgeOYrCAiPkL+mzq00EkQsekJLb+lypk2nJDyHXvmJ+mDcZOnzgYu7HZ85tg8g0RZiT60sB8Gp
NNb+kz5M08eKxgXvWPpmRKZPoTwGRxOM8GlynY/R8hyHqCxjg0acgv0dIyRpCQEbxKM9dQGmLK0j
JG0jHCJWxHziP0UdwvpBWTk0ad4LSE+uNkGA+YRmiikDcUhq1P6Hx6HY5PbDYT5TK+I6Q9lAjQsr
uUo1JxEKsc+WSjRrI9HzV1AjcWhTgGg3yfRqxtZS99thUdhK+D5CyKTiOXEULl9sX+pXV75Txaea
iTaJMWucpYFAiDPRpwmVyidWUilxaROM6qcPIFU6SQdE1MmUqtxK9zjxKJEZIov2ya1wyV1F7Po0
4TKpRZXUyyFZRtRs6nViR6x5TAo2tSXS+xqx/dg0SNYWkTjPq1HlbSdxPoicbCpVmQah5jDpk4y6
ZUb9Le88Wiaxsil/bLrHMdX0P7XUicbCqVmVdK4uDp28Z1PtkWnc84KRvGXSpsWpcpINE1jC0icb
Cq7WEFwVelRULJUVI3abTftbTveeFRta2VS/tmVDudfRbMJSfssqhzcrKJXYOkTjPptsi0qkLHpG
8ZtP+19Q554NEjWHpf2zKdWvrKH9rqT9llTq1KyiV7h0iI2fS7YCleSRFoURsyl4pJqFUlZQI1hq
PZljTO5VVB7/AEP7dlTbJAo1IQNCiNsaXGUblPC0+iDmUX7JdMqFqtP/ALDUOzLanVuV1Upzw9MN
QGoK1IyU1U6Wsega0dlR7JZV7ozn/O2I3KKr8x8fTrGjtqZrEFB3n1mnGdiyo2tZaQEFJ0/p9CMN
QMaK9rmiTTtL5at0+JG2VKxy12nBsC6qjo6fQorKujGjnV0RiGo2EFqCsSMXxSOcsYjc2VFrKp0o
tbpwQAakp2Dyk08NscsKEN0ujYUINNKWxBSRgDsKJj0i6e4T2Q68IhRIcpZdGNCDhQgjb9OeWXVx
1jyoHduKmiBHjzqwDhajgNjSNMDB3Q1sdRasjoGQ2IV6eAfaDCcU9NSCjxyy60RpFSGXH1LD8KV0
G3fNJ0bXoSNEHmoq4RQ6arPMljhR4kawhx5IUrUS3pqkcWNJbGLmqq8YT6TpBsFJ8Ziz6UUswooa
+JG1JCmSrSoFIjUgYsFhtVwklNjjnxNTV3ZsW08pcfUSGoglR2n9PPlPhwBQhawiDLMqoA4sU+s2
CsXgZPhwNNNW0lTwUglGG5igqI9RaTtTxqyLR6ifb5fRQDxmo4goMTXT509Sd2I8CStT1cNkWI25
jyya1iDBMoBygHiGeYOoJZImpa2S6RH1zVyJNi2M/wAzT+n2RgztUir5FjXCtot5XrWT/UmL0To7
2xehvgnzmlatrg2RGxxRp6fU2MQ4I9PxNYK0A6SUkjJzs8tvGs4GSVCYZkGsQGahjoxsGQkM0drZ
YbyuRqHZxc7ovo/PRejMoKtooxCoFWibJEyoa4xWJHQBGyckVbSkbDSONh285UNpGRaxomkKgHqB
DiBUpzKiRkCrZSPqWlM6KkdgTtI6ZXoXAVyAYpmjcWM0441UjcMqR8GiSWfSkcUgUC0BWlWRWoR7
IKBYkhqFPDaZoKxBNIRI69lpxiqU5FYkZI7myUfWIQqxUA0UhHvkV7TIGvQLHyUCR0ZshgKpGKZU
jYLjJZ9Ja4hA+O0MhD5bQW8LMPAi5CF3ZNRA7YiHQCoJshgqpOR0SK2O9JSEqke9YiRxildx8iuQ
2CgIFr5nZK6K2SMFW0eSpHiYLaYNtO1CGakZkWQkvDVTSPSI2Oxk7mY9e2Q2PXNAh5nYJ2ElDBVt
Ys03ipGd5o1qWKQg0jChTfKIetaRRQ2AZ9Q4ySw2GZHrmBywnrFeNqSgDq2NJOJ4o68/msJVjeQj
EjghT3HPawmuDU9oUhiordXN3fpyAxsa3lujLCVJYNWwmiR3QTN3aMiJwlvUQbC4arKQXk2at4sn
2yCc4qT5VeFBRLewWG+zsGyX6UjdqDaHWMEVq2Sdy8h+GVbQy8Y8/UPjGgpJsytM2FElx/rMtmlU
Gwunka2VRtcalpWQh5qFqq+KqeNLrHlnM/aGMNvHUJitWoVxIeqC/TkjzZdvlFA+mi1NqFgcfqWW
dmnIZySLA7QRa1nmW6p7Wdq+tlP5XxKbTYY42Jtl3AWdcQtMxxAXT8fJtI2M+K/lHl6fcacxEjxt
XH78zpAA6SbTcZY8PU3JkabqAhWaKgOGs8amiS7wtdmnoxbCwY3iy/OSpltOS7mU4PHhasATt1F+
siSRPJjw9M+LMuJKR4Kyjnm6e06uW90Koi0lX9ZkSR1lY1o4E1h9NDPZRITIIQFUqatGvk1xULCJ
pZpJ7/4sWof3Gaor1sZdDHSKL/khVTKWmJOJGCGoi6r1S6cQSPeml9PvatzcCqoWmo31GwG3tt1a
z6ZIq4Ui/lRIgKoQCNK3U3vqilT+I+RGkSbfTnasK79sGVTsm29U3aLrd2996vx6V6Hwqe+aV/dW
aiTcZHK0mmZanZ8JqMq7aVXcMhrHNtF7aaZKqx3TGMUZWkTUWyssf79Le9bftTjK/udip6/zv0Rd
nVf+nNH9urb/ABo/zPGjsqB/e2+7KT7aj2m7bM2Tt2TMit+yFqcZ7EVKdn7WJ9yWm6RxJ5ipthUT
tTRJ3gtTsiROFkxFZWM2CH+6a1FSuZ/IRP3yGpxKP+cxPt7fbsm7ZDT7YkTLBiKyqb+1ifvlN3QL
E8tMf/ZOYnkxk+2z+20YijrGIjRpk1vJtePYlsiIG5Tcjsq/ewrf8VixO5BT7SfFoiKKqZx6HTcc
Vn8lMX4mNTy46bCy2aipXN2Zk9EUVUxEdhf7BMTz0+MsWt7kVNg5aNR46j/DknZR1rUSZjvgo2pL
TpbIi5C/1ssURw6ZNmYf/FCa1LKf/qSnq21p3K6Dqvfu0HtBtmtXKpNoetF/Y7EyMuxNJHYUVi9B
w7eUhZWkTsaRV2zVktGn08dopEReUbWkpjciG+9p87Tw9RGayBUKsmxA3tRvrQFmSW846Ub5c8Ih
1QL6/cQmkxIodRTXwgQNXlZkC3BImCnAIiKi5dNaoYYu0CVqIYZqfcFHTiy3I0Zad3KDqqOsxaWk
ZXA1JqBgEkmMcum6pZphRg1sTUmpHGJpKwcw6rs3VtisidpCtF2LmYsZIjuYIaIt69yMRbuAx8+7
jyRxhoIErVZR2TNpEXWAkFN3xMglcA2nJLpETXU50Sva7uP0VPIVLY6xoE6Y+ZN0vMIGax24tY2R
JFnXHcE9GZx4H/INiSOLRoWmNNd4sOn1HLmTrISFh0mmkdIvbmNTgmPk3UjSzOEP/kn/AA10yZHS
BqMsOZ/+gQnZBmtnh1BLaw0dvCIW7mLqCOvch1ypmqJpIVhRvcQWpa76tYCiipYuodQluiyK88ZN
FQWSnWBEqa61uH20jTRXtsYyqsTUxnmuNEJ/E1eRyLVf6eov3aqpv9Qrl/Usz/WrPeCaxlx76vXt
wtauRdQf0d8TF6LhsL/dmkpDfp9yPujfF5SaaMkULZrFy7jIZumRKLLNysRY75GUYe0y7L2809Yu
kMvX8kOLuyNPj8aFemRWyl/c/pvnzm3TbfNum2Jn5pZLXw5iK9sFeyAUvi6YXmleije6SiFLI5s7
bllEMiMZKRzJqKRYxOAgzETJruSVu4U8tGkkFQjYzVQ5JKNXzEIwrVeVpuAhS02m7vSEqiGyYjXy
S82QWKN7paMe+V3GcFcfvowbJjXtmopXR39sY5rd5j1I2EnaTzEY40jusANyGdKRmJMQjJA1KZhe
2Nk5Mm/dSGvZa2ejVkm7jIjFG+2kJ27YqPI5fevdwk1UppBy2OKSOTtiZYN5TV7zIX2sdPaxSyO4
OM1zSkmIPGzEIwo3PkNkdsIrBr8mo42Q17LPPbzmP7o69nZUtg0blk90YhuSQSY0bRzWkSSJSmGZ
BBHYsc6fuZIH2GOsmNJIN3R14VCQ85ol8ppWdh7pBZbQjBYNMk0TjuA9AAHaDcWd99tcPxmGtBjK
Y/dDBjuZJuJrWRhAWVY1rO3D1JG5uo5aNDPE46xVbEjausUJj+gPddEj4MuU3g2Yu1L0iBVklT7W
pwL5NONSSoCcYes4/dWM1XE0uzhE1MPnG079myUiPjtqv+zK5GDiCYjL8BJKxdLbDqGtjZqCP5Y6
7SaOS5heFkGZKMai5eBe/McqOBJqnFsd0ECJdjIWdC89Rca6LDlssZ9g1XxomlUlSLvT7AA0OnAt
+/jXyl2maWjOcZ/+PVUP+dpKaPxbeP31iuRkcStFcS08uGDSPORKrBVrYxkKA+n3Esu42LF1VIST
NxPbK4SyJGngKGHrSJ5cbtKM+jYJA5bD7sC1i+HN0pAIQyJxFrKB25NNGdLkU4VDC1xX+U3SMxkc
5P58Sv0z4B7awHHj1/7olnpX6lNFpyKAFbLECRf0P1psPTMWCzWJYgX08R8uXUxVjRNSi4mrZSS4
n6T/AJ8qUOuhUuq0dYvhAs2z7KPSQ9MWa2su1rfqUas0oCDmsIsQNVoJyNzV52sph/GjKvvuYzgL
WVY2EfRt2Ib7KA2xZAlNEmqK9op9GRr4BqgKy9VXo4EXSmp1VViAc3VmqB1gpMgkov8ATXFXoVcL
8pmn7hYTmSmSI6tY2z81jIyXKtsCTGGDAewT5BmkxO2xgJjBLcTGvZpua0Q7WcjmVnF8hZrQjt7T
vOM/lm+KuLm3Xbp+c26Ud0oFDMEXJdgMLTXytkQ7RkhhZYmssbnitVdpJa2UPjY2zRsrr9e4OYN+
TLJgkbeuYaLYMOw81g0sLri6uuWGGs0bWWVxxytvebxTBubOtGDaC9VsiPYjK2TYsY2RduaaDbMO
J8xjWWVztlXfd5Gyxq2xtUY2DfcXxp4yNmWjRNdeuHJh2jDNPPYNk+8VH1l407FnM4WlzxbWX6uU
c8StsbhGDBfuYaNaMe2VaMG2TfOYWvu2GG+xE1tvdcsMZXvVca/bKO7USxrIZG2Fy0TW3zkkQrcZ
myrQY2zr53erb5pmOsGIO2v9sqdQ+4rITmWt40aQr9zDRbYZG2FywTPr5PLr7sZWSbYQ2WV65xae
+5NdajaK21BlRfOa8VsFzbW/RjYt8UciFdDM2fesE2TekWTU3zTMk3Ihis75xH0uoeOfWBNHcahy
ovHxyRrsD22uoGtRl0Rsqv1AIg7G/EMc25eU1LqNvA98Bobm9dIWimx2jj3sUY7S1imGl14kmJqM
BWXGpGK2XLfJJ0jvRj6O8jRxWepYhAWZ2yC6dtAQ0fqqKob2yEclBLHELH1VFGPUN4CSsI7WS6zV
MMI7nU8aULzu1Mq9XiQK6qh5Z6taq1msgoFdXw34/WgOK6pRksesorkPrSMg7q7dYOrJKQzRNaxR
suNWhlsq9ZJGxddRMtNZtkNj25WTIeuBhDcax81KLUf01U1+Hb/9CDl1q9LFtDfrUFtNYeYFXciU
epVrEd/yEzt3F59QdVXL60i683YLXBBLO1M6SaJrt4Al/wCQ90ttSFsVqdYlrhL/AMiuy01kaaxV
V78RcgzXQyi/5BMBlhrg9gJpFaeu1pIrwn/5ClGbOnPnlqtRGqsf/wAhy+NtentcgzXQnD1/NC2x
1fLnjAZRkiazlw2O/wCQJjksL+RZOia1nRRO1/YYXXVgVo7mS2Qmt7FrZOs7AzSldIJFlujObrGw
EyZqWbMHBvpUBrtZWCpNvpc4bC8HC1RMjil2smwyJYlhO/Vk9MXVljk66lzxxphIuTrmXNa12RJ5
Iau1BOXJE4kxw5Lhr9fncUtpTTmsTylFbSQs+tzEyRLLLVC8cdcSkYaQ+Q53Xbpv6UTEx3smL74T
CfOD91iypTWFOZXeXJVjiP7g5MpWDmym4k+YuOnS1zyZPIxzvwRSscY53tGQjHPkSHNLvuubdAhU
2Piq3BRlJj4bmY9u2cc2zbomN/bgLU4sfZlLjiK5Q2BAYtuZ6EkK9WSHhc23MjSTHlxr/cB5mFId
cc5d4xpLcKaVxK5245DwKtsfZ8pX40qooZkpWGkkXFf7isTCR9kV+OKrsDMIHFtDOR0hX407hqlo
dEfLeTN15DsDDx80pM7qqo5hQ46yM9HEV2CkKFfqZ8dIe/EerXNsitwk0j87i4KeUePsCuxScsFI
eLFtD48yvxVxVxuNercHOMxHzSkxXrjJph4s8r8c/lg5BBZ9QNs8ryYhXNxtiVEJIcTOW2MmkG10
wrs7iqrJJGYswrkcRVVhXNzzipjyqTGkVmNmFbj5D3Zz2xssjMWUR+dzGyXpiyyLiuzuq3PLLjiu
dncXEkEbjpDn5y9+6u/ddnLO6qZ3lzliFcmJJJikXOed52OIq+hF2zuYpN83xHrnPN8R2Oeq5uuI
7N85ZvjXZv78uOc985ZyzniquK7py2xXb5vivxHbJyxFzlnznLOWK/N8Ven5Ry5vm+cts5Zy2zfO
e2c98+c5b5viqq9dunPN83zlm+/TfbOWb5vnLOW+Iucs3zfOXtyzfN8V2b79N83zfOWcs55yzfpy
xXZvm+b4uJ7Zvirm+csRc3zfOS5v05Yq4q9V/oou2L74uKmET2N8/iqg+UQFK0cc8Daa2naoS1Lk
nJStYGLVtcV9M1jWVDXtFSte+bp77VdR/es6hGjgRE8p9M1wrKrUKlHxzbppitYeLZ037KSk5NtK
xrEPFXueI5McBUxI6rniuxYzkxzFTNs3xFXGCV2JGds4SpjRq7EjOxw1bkdv3qesYUdrVI1JIuD6
GG07Z1Q1B2YOyZ2Lm+QISyTMpEbHsq/tq4G6+MqqsRyYolTEjuXPFeiKFUxoVfnhv2WK9iINXOSC
52LDI3HDVMDHUznVThsKFR9N836b574q5vnLpv6FTfpvnLOXXbpvm+K7PnFXpv1+Om+J758dPxm+
J039PLbN9+irnLEX2TbfN839CZ8dN1xFzf1J7Zv61XqnVVz5z46qub4mb4uJm/Tl03zfrv6N8+Vz
fp8+jfFz4xVxVxM2z4/oKub9d+m2b4vp3z56Jirm+b5v03zboq+/Lpvm/Tf174ub+2+b5vnLFxf6
e/RUzbPjCLhvnNGRGvjWLuwI09fLqJDZUdtS1SWTvHHSyu7KlIrh+S6PlRMQpHNRyDgsG+7EnZlE
WLKopSWAbuGnGWzYr02XbNKWPA44zZbUhNjDtXcyDpOafQG5MouOCokciUaNyRQorLGB2HObtn5r
IayzR9PoNPojVyyqO02sqEe1tA1WWNL2kOztrpIqvg26btnexdHEXvy/3Au04lenQA0cSjgsaQcN
vZu4SZGrEe4VA3Fom8J1PwfDqEVCafRw51SoyQKJO0lOzJlQ1GwqBHvZQJsfT+zbOs7K0A2+SYA1
Zasajl9O/TboubYvoVubZt0Trv026r1TN836bYme+b5v/RTpv036L1236Jm2bdN/QvX56p13/ori
YuJi+/p+M33xffqnt6tt82xc2/qr6N/Vt6k67+jf+ivTfN83/p79FxOi9Fz89F9G/wDQ/Den5XCN
2aX53zQ3+hdp+w7f36Sc/Ya7t1ByXNNe0txGtHbFa5dN74eZ4+RZ7ZGXP+tarsbRvvEuf7LD/MTp
V8/OolXsS/8AANqkshCawbjNQliVnCqIhmzl7SsRCh1BHREM3FzRAWnJK/Yx132zyJqScgRuDIab
5dRW8bYaNLo33gWifsn+5dILtMlJ/Huk/e9ccuDcrF09aq+YyUqR7qW52UMtXy2qjRfUGNQ/GQ+M
HggNnCso7e8ASNDZ2SxlW5adKpqPQpEE181qtuiNVBPeyU88jtzHPVXZt6Fz8pi9EXF6bdE9Cejb
Exc2xOiehOm22b5t/RX3xMXrtm/pTPz03xPfr8Yvviehf6O2be6JjvT+VTETPzi9dvQvo/HVU9Px
n5/PTfouJ03zf0r1T0b4vp29C/KpielfQv8AQ/PT8+rf1Jn49Hzi9NtsTFxVxVwnu02bZo2YgRTd
pAp8NWyqWO2NGZaNYs1qSR1cZRT5qKoGQnGfVRUAS5/xUMt3k2huQJo+9OoY/hguZacJhEUrvn5z
SUFCmHISK1ti2Sxw2tkkN9k6mcWY0nb02vEdo/dIhE7N+v7D+yrmiCIMsr7jCVClkMr+1IHt2wGV
j7B/Nlwz7mlB9mJaj/ZZs4l0kHY50/j3bP3F+VTfETKJ3bso5UKGfBR6VkDsTHN/j25CBdp+epzO
ds2IdUyc7cgSIo7GD5Ckq+2ytdwbOc96dsqNtBvylRr5RAMUdq1Ee5Pf0q3oiZt0/P4RfSiYidV/
o7Zt1XEzb0fn1L0T+nt7/HXbPxt026fObev59e2bYufOfCdNs29W39JfnbNsXETPyuLnHNs29G2c
fZU9Cp60z89d/Si9d/6X46fhPR+fSi+jfqn9JfjFTFx/wb5yHNfEJX3oyxrGYPvgt2ePLtV8qPdM
cCNaA5fVwub9RA3Pq4mFsrhrx1Vi2PNm3DHDjSm+etyIYrO277iv3Xppe0ZEBPumKlRcpHJLvBNW
LeiK1bCNllbC41Fv2sn27HNi3jO1bWTToV267b5WTFgyIt6IrfqcbJt0xFg3qK19wJuGuBkZOmDI
SrtRibLuAkHZnaV1LPGBFuxKK0nDLhPddt82yORRlrL5vbNeCVgrhncS9YorWewqRpixTxNQCIz6
6FiyrpjkjX7M+sR3JLuhNbG1CjXjugkae3CjbK07uCkuCVbsitkHUquxG74rdsXpxxUzjnDFTbNt
84ritxEzhnHOOdtc7a5xX0o1c2XNs2z56bZ29849Fzj6NsRm+cM2xfQ1m+cc29O2Jm2bdNs29unz
i4mI3fO2ucVTNs+c2zbFT3VOm3TbOOdtdttsVM+PRt0Qe+OYqYubdds+OiZ8Z841u+cMVu2bYvTb
EEqr2lxR40arigciKzp+VxG74g/ZW+ys6bZtiY1nLHCVqcfdAOXHM2VcVP6y9Pjpv6V9G/RM36b+
hf6C4n9LbonpXo/3aboxF3iQCvwwXjUUAvAwlaseCZzWQX7/AEuRt9MOmPrzKr4B2MbEeQjq0omd
lVIleZGmEo1cmL0R6tzuuzuZ5DtmmXPKemeS52dxc7ztkKqYr1dkOrJJY6kc1smMolR72KwpHZxe
qbOyLXmMhawjGlErFixCSXfSCtaeO4agjvkOFSl2kwCDzsq5waQj0PUPYgKoj3JRvx1QVieARSMp
SLjqZ20mvePHNVi83LivdtvyyFCIfC1L2NHWuK8dCRcfSvah4L2LGqHmR1E9GyYKixsdxHhonKKT
XODj2ZCr3yVfRuawkFyPjUTnNk1HbYWPssGodIQlIo2yInbdDpnFxlAuGoVagqZ5HM09uhKDikmu
cx3052EjKPFbssOCp1Dp7m2fSqFDB4uVM2xreWV1O+Ti6eVrJlYoMiw1kFWi4jlROyu2y8ffjiJ7
1lP5OH09wZMi9l6p0RMhxO+9tBxZPidh3HOOImcMUe2I3NsRmI3OOKzOObZtm23QbOa1mnXSWl0z
2x2VcoFVmKzOGcN8czFTp79E91p6lZik0tsGzh+M9WZwziucd84YqLg2brUabdIHeUvhs23zhnDO
GcFziuKm3TjjWLldWPlvjaMVBWml+2kmM4JFHiDyFDWQWt0crwO0eiZaaX7SU+kVkJ+j8n6QRorK
GsM6N90ZywEF5FpdIrIZK0ijGXFQSCZUxEzjjBcso9NksCT9JNBDbWPJPq9Ho8NjpFvC0rnwZGL/
AE/j0758/wBD874ubYmLierf1b4nqT+jv0VPbbH/AAf5ynhrMPCq2hj2wxIaBBGQFhTcyhrGDjgj
j8h0EaCYAS42EN5y0jXjHR8J0+ra0LxMDYgiDKG3qNskh4OVOi9UzfN+u+L0o4DPDniYNtq9irwV
60tKpXS6hrRghdywiVrGClRRI22hfuqKtowOiDQdtDZtp2uRWNhsa20iM2rYKGnBgtRJkYa5ErGN
aYYw4yIMo3wBsJuNiRxDMlvBbxfWOVfoxcNAePIVcpyUlK1jbGsY0MKubuQTAtCAchkmnaQga5ok
WMN6WtV7VVSiEDVs7OoIaDyPBdJPRUrWJKrB9llUhJTYTRDtSsTIkLypMKtQY7HgxEF5VhX17Wie
omEdAYUQKlrcktFGQMcchlnWta8Va17bKo9pMRQuqZgwPqVFIZfRGIOwb9x2/SCLuyaWsa0RxBa2
8YxU04HkY8dqRrQXM7Kd7kbp9y5IpnixsJyk0zEyZFY6PfD4ndn5YmabBucgWeLeN+9Gpnnz9N74
WgUeAoXkxdOOx2nnNRlE97/029rV04THUj+TqFzUFSvKsyoWOjm7Z84iZUR+7Lq4bY0aXIHwuANO
6Pppz2u0zthaVyPHp53Ful3LkyhUKHFwf8YmRgKR+loBROcnJuoIqmsI+mHkYul1yTREYq6af2kg
Ksn9NPQSQnMm0SoKJrAnJK+tfLUWk3bP0vxQtM4ZYulXkY7SWyWVE6KgQq98XTDzjlVKxJGm6lke
PZW3096Iywj3WnuciZp5RDr9PmlZGhtqCn1cMYaCZNmGsXMQEdrWinz5iWAk5C1wLtyhAUi0mmXn
SFp8I5Uw7a+JSXDrRL2nZJC7Saqz6CbynaQcIFNpwkiTCiMhBmf6em6xhJF7YLXRKOe+xDrKrG2M
1d03zbNum2bf0F6L0+P6S9FzbNv6qYmL/Q+M+eq9PnNs29ie2SFXlmhxI9877QLOQ50nTFj3mChs
elmqRxwJCltuHMEsbor6ub3JzV9uCcrFu8W5bsfSUxx8tgp2rNvE7sXF6b5v6vnPjNP/ALq+7cvC
Sv7qWr8hwgtjDt7No26fb3ZqA/jWUlwVQ/lyKsHMFo5QZMm9x+nAbCsmKFtnY8M06zkUweMewnKF
1ZJ7wZkbupEF2w251FkZhZRQfx2GkpIIKvaqLGEiy4LH5XVaDyIxBpMTkGEnvNjdxsAHZYxGq6Yz
ZkDkprMKdpJyR5cWT3AX373U9a1uRRINCJyZEj7kkB5CkVPcyuq+0ZAog5lZ3npWeOeCz7J4W52/
bF5zUWXtIyELti1MmzK24RH9psodzVozDi7ZNKf4r/8AwT/8q9NPg7kmAzjGviKFLSzV2aZ7ZUkR
E8aUjB2FdXDILwRNdLqGPZFoEQsSMwCSF2j6g/zv9lxnzpRRvwsVvjzIfesa6qGMJPEYQtWMrY8A
QG9gePiiegq0Q3KEedgWzqsSknVwuxTwRvbqeCMTCp9xMT50wFCHH7D1Sd0Z2nY/1F5UBFHELGn5
YwhgyHHEondpuXEIfj27GskfkbN3aYoe9jGjjNX+2LAbLtE2anzkiELuSI41jxQouoDgZ2ZxvHua
p7TRdaBTt6QrGNj2NoOsHG1FEsQRIgpk1v7G75qKKLw6Wi78oAkAG9qWkyvbxhW0dpH16bQ7axSF
JaAE4bY4II9SXLZJ6DTyyCK8NTFutTOkyabVADBZJryEbmtWKadpzTjirIOGoj0NitlMtGI+NUCY
KRcP7UOktWWgkgR0dqO8bDdSAakLZdyM7g6YSBddDaVtM1rW63X/AKtv9nTbF6bZt129S+peqelc
Tpvnz/S39v66p03xccm2HT3+M0I7Y9h+4FmzaRpaM9CRXbCumKRleNRWrS8I1nL7rqcKssJRVEGu
uO6ae9PFu1+/o9qtNaL9m3/zuz8r1267dUxfjTS/9fdpu2Q37tEcfblpzHZx3NdpuRxmoZUjX5si
SOxKqSr2L437ZBdiaXkd2NbSPt2ZuTtLSlI+Qb7F0Xc1QziCxm9hK83eBMh994oaAbOl8cp+4sx6
cQWEgwzNsibxLliJX2TDvO5O1GRN7CV2m1slTDH8y37Ngr92zf8AalLvYVyfx7r2dBtxCyBajO5X
fsjvRX2EnsirZXkYwTUeZ/bGGweSV2GkRrODZc9zJAnd2NcGWK8V+bnVyFMLUheTIFe+VIgJ2A38
wfGQ7uE0q3YV8n2bP2L+d8pDKOVVPUkXVJl2kLydpBV7y/6t4ipMo/8AXnvVsofuPbCFVJkr/Vv0
XvvzbGM99KIqS/8A+2L/AOqL/BJRy2Yf8OEJwRruTcc7igS93pL/ANamarQ6rbuKQ37u2ImUBHNl
g9w6wc9z9E/6t4iuiaRGo8u/9Sv/ANTU058QsnV6EDLN3ypkf/LpxqJW2fLyP/6VUm06XI8YP6lk
veKwKWQZdwxa56XM0qCj2z+/bUCbVusGqotLL/1urRKYFfUzFzTAHAPKMscC6hnkLbTZhw0uoTQj
RZjJAL/Umz6g6Gg3LTPNAarIupn+ZLqR9qBYpyiQNPc7doGQo9waZZSZOmCCEwJO/SVUrymuQIEr
PqtieQCoi3+oCWRdDyGNS1a4sWginEXUkpg4ej4RAuzWFa8742oZURul7mXOPJVWAoJiKfUEYkoV
BFLFDr2wGOKxNm9PnPj+ntm3o26belcTFxc/G/RFzf17/wDwbenfHe+H6acneHKSU2QG8h7ZRBQA
ZdykTEleSBkVPP8AZ0dIKKYQWhkzyNWPAN/3Uo6LGsUQs+oieEO2sEYOwP3SuzfF9e/X8aYKn06x
EhW2MTtrCsHwC1ti2ayxjNK2ni9uya5FBfMRchh70usVOxeNRyHZ9/TbEBGs0Rw7MfF+lR9tTKig
u2fvppjXgmDQ6Rdo4hyWOdI4vY2A17mx2Ri99rxlgsISZCY1s/7ZNMt7eHLuCLIRqy0Q7YTWxmSL
RonsmtktajB5a2bWshgSQaBsgrmM17bAKBJplvF3dTsClow0h7TshsbHx1mxjnS2mYIDWELPaJBW
DStLHQhnSWhDPekosGrY1fJbEHY2HlmrhsEOytWRxz7B0h1TE8laVjQj1FLb2Z5OZelALkese1Aa
mc1+SfYulRozFM3sX23epJrWhlzGvkjntaEVoMikM1CmmscC6H3n/SiPz6IbFqyMzTUdBk7ze1YH
aKZX2DSx1iteU1iMLA2Y3ssblrFgWI3x2ThOWxthiyntGlZItxhXzGSRBlsA6/kNMw1c8xfoZFz6
IRMoa3tHARqi1W5r3aVtWgR5GSmx2igtsLIcssMjOxq16Owidw0epIZG0BEVtKVq0M5Y45L2Oxti
N4W2bIc3vCljDGjxVvrcAM0/qNk0KyYwWaj1N7VX8mdXEEKNqYrCg01eDG8ix5mKsWGJdRhj2TJs
eWNoosZ+p7qO0aFVCM1BLAx0p536d1E+I8VlEI2/1OOMLT8sUvLbVDYI6XVArICTowJqWUQzWErh
vvrmKkOidAkFHOromaj1XvlXqEQIWo9RPsio7K6e+G+m1NHlCn6kjRR/XksrFt/FhxA60c+faXUA
8ac9pJulbKvjjNqCv4TbtAWFXqmGePc6wjBj2U8tnIxeq4iYrc4Zti4no2zb3zbOGbb4qZt7u6/n
F/8A8B85+cVM5Y/4Pi+2NdstTf8AjNm2zJCR9QtEyys1k5B1GgRN1CxHD1QLj+phoptRIpT33cGy
copi6i5hWd/LTUCdudYPPj3584vXbpv6E+fzlXqLxGrqlhGT7Dv45fevsCQSv1GhGRrvtPHq1isn
23kpGkeMaNqdBpLvvKaQq9+HqJI6G1MhmS5KnWBc+Jn6tRzZ1islINs+LgtTt4k1LzRl+Qb2apTb
9UZL1C4uA1Mo8/Vg1yXqBxWlOpVg3Xh5+quY3XyteLUvs/UXtLsSHWHdEj47UqqyVOJIWFc+Jg9W
+0nU/ebMmqd0G48XG6qVzH3xVKDUj0R+onvSTZGe+NqN4c/VC5LuiFyJelDjdUPXJV6V+CsCiKzU
z2JKv3GTy3NM3URGskz3yFX3yFYPiKHVRuE26LJwrt3dIc10UgtYFG2ZqFZbXk5ugXL4KLq8nGZa
OlrGvCxmuuDFe68kIxl0cL36qM/P1IdVrHJOQMEKp4Qt7GM0bSWjoJf1dJyRbFlOjXx4efq6TkrU
J5GDv5AmnsiSFDeyY7U1BIw1uaRke2LFw1yY2C1FJChNRynui3JZJIMeO5rY8XCRo21sdIbnaklI
km1NKwUh4VbqKUxHajlvz6mZSJqSYxJFtIlJCVvfrhwkGjYS45IO1zJHHV97IXPq0nc08x3CupIk
dfSlwsh5lFKeDHXEpyPe4jhGUapcSm4SxkGxh3MVlhLXCLYEa5Xjc2ykjx1nLdjnOKqN3zsO2X9q
tfiTjNQhXEVpnsxx3kVJJB55RlXy5S4qTlQhjbskEZj5RlxXbrzVcXpy2xDkTHHe7GOxndOqVcjj
IYQTkzuKmKdy4i4r1xd3KMCkz6OfgYKhcvT5xExg1dgqk5EPXljYrcRMVMTGt3yPXkkZJrSxk2wU
Z5cLTmYztfuBVFkJJqjxsI31flev5/q7f016J1XHJjske2bY1v7q6odISbWeMyJSqYcyuWPkKmU4
/on7x6d/b9CwtHs52nlRj61/fWjd2yxVYYNKqjnV5AY5u2L13zf1775+KWm8oT9Oo1s6D2Fd7KIK
lclW5qOCqPg0PdYSh4jmwVAtfUeTjdP7Mm1aiyNAWSUGnk4SqXstWKqlhUCqyRR8Wx6NSPbQN2dQ
N4lpnd4dC3j9BZtOpuzhRcV44u+bKuVNO6QptPcWCpeZx0KbOo04zKlzcg0Sq19Aitn1ShwEJxSx
tO7jsarsI5nF1VUOkudp3YQKROTdPt2bp1FydRcEi0Kuz9P/ALJtMo1r6FXJ+nkRDUGyR6Lk+XQc
Bz4XZewakeGoc5sqvcHFYuVUJC5EoEe20oUCyUHtv6I3EGuINc474gVztLijVMAPmSqou8y0ouwK
aPtuzfbI08sfKWRLnZKCYAps+R3Ccir2lTEEudpVzsrnBc7arnZXOyucFzhii93Jt03xr1bkSYdX
VlUY0a97sZrjEKna3xQuTOHv2lXFCucMQW+LHXO2o8jGLvU0TjRdRAWE3mQqpHcuOC7HJt123RAq
qdpc7LsQW+IBVxwVTEZ76brRSHLp8HZ1FGSNIbHV2PjqiozKSofNNK0yyNCsQcJrRb4gfd4FTHey
IuLjMooySpD9PxQxb4bRTuyudhccBWo0Suzx344Lm4rcazFC5MixnSCUGmGNY+oiubqTTHssZ7F4
+/jLsgVVViuzx3MzSixXSR10VwtYQ0BMVuccYPlkWqKZNP6XeU466HDDa0QZYLOofClEjq3GAV6r
Gc3KqofOJT0AIMfX0MQq+DEdJzTWmBxmXEED6+h0+s+YCviVseVWxLKNqWkdVk9P56b/ANff+qmK
m3RUxUx6bZJ98+Mp43mTIUBsUF6djGUb2EBOqfJSJXpGjlMxkoTG9nvja/kN52wxOGakRZR4KMBb
t7EyokDlCtKxHinxO0QjcXOPTb079fhukhtfXWJGiHbTO6qD7j6Wl45JhMQfaYayiRUaCQ9qMuGs
c2jgokd/AbbRzFTTURCYgmBSyINUiRWmsQxkGKYRnGCBismvQKQdpA5Y2CVbEYsrjtKlkNioWo7p
F0/kqmVja6meUlPWtEksDXAhxWq+TsBsAnkIWvaVyREA1h2FdZQGvHBhsGcA2oLUg2pkCsWUanrW
hwo0eMspsYxtRME2nsFlJIA0uJDaJqSmucWvaTAxWhbKlK0zBoUQkQcgwkKy6qFVyA8OVXoIg7Gs
QjbCvcFYk18J2nJvkivWfYsU+45OlfEWS+Lp7myVp1WpGpVKYelVc39LOybQKJINM8pKeN2A3beU
KzT77l6BZzXTcZRNt0/jGiukS4WmN0XTSJh9P+8XSiuZ+knbytMKxIWllJj9I4TSqtYLTaudMoOy
gNN8h3Fd4qr8/GJ75Tx++Wpa9kbVDFympHTMZpZBtkabTjIpeJoOmubJemOA/oqukh0zya3S3HLL
T3bSDBV0ypEQMfVw3LlJQOnK3SXFsjTPBtzW+J1pq/zSF0p2AVumu+Sz0942V+muYmaR95el+IyU
r0l0envFz86iB3rKu0sijk6VbwkUvanUVUkFhBoYeoaloS6f0ystn6VBtN0qzt3dasIvRM0pWJJS
TFL4k6JzuYelGqIWkAsyx0q3hT6T75k0tGaknSolZf1LoJ9P0Kz3TdKDHF0/XdmyN9oMAkt9nKG0
oQ6cEd83Sakkg0gEEaJppkyc3TMRjS6YjubMpvptpF/1bWiFObf0JITxJyyjoXTSR6iPAi1yMcDV
LZBpVOjkiWtbFlTrXSwygoNGNblxSR2uo6YdcFpEeuuAOkVultNtjg5oi2qK6u0oPhF1gI8gOmo7
4wP+SGt+mb+lMXrtiYvp2/8AlVcRer8kYuaN97SQ3+LdL9/Tk5RGhI0grNyCASRztYreQLIKMSPL
X6iEmwWkY/DpuHUCbE0o9W2Mxv8AFu/8zk93Yq9U67e/RM/Ginf9Xcf2zf8AJRVqHzgkcdtZqmUf
3ZMUaeNcP7SpI78ujanauk7eTpiqXTbERtk1EFbTOC6dVCE4J41wdQ5QnUgZI2uSE1GNulVchQXE
Vu0dj5nkyARmoMssI3yDCekGOxMAqNUqbjitVDSRo5sRrW4P++Q3dsYX8uc1OzNmOjyayQpAagyn
jsbgdkz5zUQeL66vdJLDjpEGyyR0hf3iaP8AlvXiN1ojV7rDEHtwev8AO39jhbJS7rETIE90E8J6
Sg3cFqNmDRhNJf4r3/Xs0+8uInvpuG5XV4uDCBaZsOK1k3N8mREkti1jQYx7Vy5/0bT/ADO6AXiu
kpTTss2IsSpiNJYLtGDEuUlSXBa5ejk5IicU6NYjVuRooYbE8fWLERdkzbETKSR48msfzh6uanLT
0RoYdzaurm18hZkOfW92VFCoWfOXP8KfAXlDfNVkycJCxpRvEuK1/dhayai5pqMwVfe2r6wcTWKH
j39kEz1X3amaLb/Lkf4qD51MvGLpU7jxLKS6MMD+6BlaJppUpIuNXJUB024ixfGHmtf4+aQtTTMm
lUEWTYSJtzWMQde5zW4ssI81jLYd6/CY3NJncySX/HfO4W+nHqSBc2f00IrqMSPXuR0V5WCT6jFT
NQ2EWZNpgwxCdtxTxmWcheIY0wb5cn2j1FsRlqvsusLN0KPpj/SkSAx2JcwUbe2gZ06In8WLZELa
ahhjNAo9PunTIUMFPG1BqfzJtJ/5tzPHFmVhELG1tJeGZSHfIhTDKCJB1BzuP1NWuSLJDKbqKUGJ
X1era0sOLaRJrjvaMFCRhWajsWV5KWQknP8Akv8A8xPjovoXEzf/AOtfn0OySnTSD0bbEJzjXcdU
kacr+7IhPaEdhscMmL2rGO7aNZSXvWNEck4v7YgrVQTyH5RdQe5NLx3NmyyJ4t2qd0ny7F/o7Yq/
t0T/AOXbN3bPYrSUFmMauXyGWtcuVfMNmFy+PqEjtiPc11A5fFvHrxmO3fpAjngs3r27bdS6Xe5L
Dm7x756qShanjWpXtbSke4B4yFd4qBZOeR7oEN7Je20e1A95O1Ja0V06IlPfJMM8n2Y70c+ze5B1
DnuRHtYsgv7I/LvzjJ2Jyd6ZTt+zeBXZl06C+o1D5chCfb1EZVWgjIrLYvaFWy/+yGfcI2vdIkmR
gLQr1NXMlvNFJwjtMj5hvcMJFRNQ7cK6q7xgNbDFe3LcVHSDaVAoxXv+tZr953tg/wC/TAWIwhe3
jXckCn81y8UCfmXF/tiIqGuP9K0YrSqzfFZiNXNGBXaenKLUfanS/wB0eqiPZPXoaQjX9JBeDRO5
DyyYpAR04i1gHnjmbZwzjlYPeVVM4QNXD3WjdvB1HFdJypF2YG6cpRHDYJ3Jmox8pNb/AKRIrnT5
r0ZFm/yLqqTjX6uHyTTzv+t1NFdKZF0mr2XVU2Jnbxo9s0g5BypHuKqjqBdSN5xtIt4RrGOskYG9
sLCtJloFSvT2HAYjbSXy7EHfxtaiUzdDv4yJI+8I2nUimguRYl/GkyCD01JeG+h+ORGb5284ZpSI
5ZL/AHTUEB7rTTwlFX6xAposc5RSqIiPrdTV0icsXSZFDqWGlc/TV4kAttrOM6JQ2/C0HJZYRYdA
gJl9ajhxtN1SkkElCG+/r/qIdOqggaoqy2YoOj92Ta1kCxir/Gj1jhWtw9niwAx66Jq7VqnNGXtm
0vfikAsaNlq/mKohn31JYgYOsipIDZR9T0PiLFY+Y/S8RYkHW0RZlYre2bRNcQK2I1LCobdKs1hV
CuWhAGoj641Ky4Nm3o3z5xfQv/xbdd/Uq+2/s7Fw+LkCYsOVU27ZQbYbStoUaAVlbdhtVaeVGO1h
Dx3p2Xgar38WEkTW9iVIT6os1vj3D+7IrRsCK0tUGObK7z3Lvi5v6Fz5zbpv0+U0bLRlfJ2KO4jt
THFUb6K+5rJIwjYgGpMAdvau1a/ANR82nK1grgrXNsPc2nuMcc+QxR3HzpxEY7yGNj3fFyUNoiMV
zZDWFZFaO0Z3FlsIxox8pRBR1DYNe1zGvWV22NtjNe7Tmwmums7A7BjCrKYZBnHHSyvEDkG4ZJZ5
omNtbpONcrT5BkiGy0MIrbZGo/TrmDcyePsXpmkyknsYO3sWvZ5TgyqW8acfnjay6vEayte2VgGh
ElhcNEyrtuUoNkJwn2QxJa2zTGhyxhHb3n7ZMlxn0qMIStkijMvLYbxzS8iO98auy6cu2jxbFjmM
uh8WWg0LNvWIOvv2vMe/axI18wqLbDGSfaNOORAWU/8ATzsTTq4em7GUMoURJduFY77ZsadFuRGF
9QjhWVqNiE/ULFAbUX8oeoB9luohcLXUacq7UQ0A/UyNP9aEUYtQDZltIbOVmn+efpnfH6c45Dji
hzId1FaDUlsCS2h1C0efWIhUl6gBGGPVn836/GMwWpAjdZWLJRoHtDkyxRW32qGqlVKRJ8PUMNor
+7jyko9RpHKmoYJWytUQxikdy6IPSu7U0psoql0BwNSiEMuqwiJY6ljzRaXT+OUzQMt9XBE2q1a4
ckurYrmj1iHjK1OMUsGsYpBN1kEMi61ICWOvsnRJETW0fs3Gs2EbRatWJn63h7WOtwvEGtlXh2aN
VU/Ra5N0r2GVFyOne/XsNGzNQskzI2uY42XOtASxEMpTUeqiVqt/5Bjo2x/5AE4NlZlspHLdPyx/
FaPVb6x0j/kQaCl3p5s0Gv2Ro0rUR5csOv8AaPH1aWPOZ/yQxqSv+R+TH3Z5E2J/yK0IS/8AJbcs
NVyJ0iz1caWHGuyFYviED/yKUILvVsm4Sm1QSmS51ka2bS6okU2Xmsi3A4UlYpY//Ix44LD/AJCk
TBIXctVraRWjP/yVJcyTaFmSoX/IEqvBc61l2oc+cX1Ln56L6UxMXr89F9a+tM44uLvjskYq+6ZB
lGivLankNi2kmMkme86Q7E0bPrR+Tb6U3Pr8nC3El2LbnchpD3lS1k8CyXucO1kbSJRCY9cXovti
dfnNuu3TbIUw8XGXMxWypJSY/wCWuUajuJHFtgUbgXsrCy5EjHK8bwXUpmPnyZLSo9MDZGBn1aSR
Dd12DlFi4K3mOQpDmQfcG4U+W3H2EpyLKkNeyxmIiWMxckTZJEbYHDiX8nDWpjo8qqsWWYONsJnF
8g71DLmIiy5bkkd12AeZrlPMVDdzByzR1DZTXIWxlK1ELIUcaSzO5YIh1kLgVOilbIcj2rvHCZuN
fNcwwT4hCgcOZNIh/IVBNLyC6fxIs5UL3Gr5MjYxHri7rkfubhbO2kjlYRvvn5YqooDynY9xx55x
90kmMqRDIhyHbg5BR46bIdgJpUdV2MbgltDxbaJlvYAe00wm6zZDsUzt/LKmLYScWQVysOXARCmw
wDx87pMUjlxDkzuK7BJIdhY52pUTEjFjaiiNb+p4aYfUsF7bae05O6/O4Ryo9c770RSvf05uxFVu
UPF0iJMC4GqpjD4ZeT2ou464zmnC4Wb5zVOlDdMrsi6oaRr9RuYljq8Tm2Eryi7rkNE79POihj3d
nHfGloiyI8N8hU00V2O06VElQ3RXu+ds47rHgEOq6cLwmVr42flcbsmU+o31w42rZEjD6kmxxWGu
SSRkc6WaNp8kls+sdCyLXOlq3SpEbOrHxcXdFcu+cs3zfN0zfN/bdM5Li++b9EXN0zl77+/LFXdN
85dd9s5ZvnLpvm+b5viriLnPbOWb5vuquxf6CdN//o26p8J7rip7beyph8cmMbydTUynydUoIdZU
oZLSn7TKim7w30zUICiR7VpG8j0fumn0cybSKIrKBOxZQewaJUteOxplYhgqxXdPzm3T89d/bEzS
1b5gXUbWMtISCwqfujRXHelGrRngqN1RR7ifQt4Wlb2cpanyXMo04WdTwSDXKeUGibtPpmtaeCqy
a6jRByKRqMBRo4jaZrE+kNc09InMNSxMbVsdljTojZUJWO8dcdHVMYFXupKNSuLp/iEdMjpA6do2
pVsflhS7rX0XFPoyI20qNkBVqU9fp1OzcVCBSsrWqn0wLUDUDek+kTItGiJYwhiasZCng1Q2sbXB
cs6mb23VSvk12nU7V3TpHbTVHcxtQJjPpIyNs6ZGqGj3bYUyswgXDdTCYR9dWiK23qGDDOHxK7Ey
OFSvptOq8VvTdpkgKsWijJIkfS2JGuQIMyRnOVYD8dCe3EjOxtefZ0E+yRn4sImfTS7EjOHjum+Q
B9wtTWCWLqCM0SNjPfngkdn04iIGG5xKLTvId7T9lpgLuOA8mfSSY+A8WNhEdn00q46uK3GQ3rn0
4iJ9NJx8J6q6E9uMgvfiBMDEfP4OiyzYSvI3KSndKO6hEyLfwFGZzFa4cZxcWARiUVSs8kGrBBCa
KGUzUGn9sWrejVjKitgE2aOVn0yY9PpZGZpimGMUuRGhMAkaeDVtWwKfORYqyHx9NkVaWiHBFyjv
W5oUKM9Q9HlhuEoq8hUiVjiyKSpFAj3wmLAcNXS9N6bfLICKKMLWEJCuoKEcIDpsfu3NE2UC0jeJ
JX0pm+b75v0Vc33xFxem+b5yzf1b5v8A0N83zfN+m/TfFxfSn9P8f19+idV3xUw6Y73WpD5FhDhJ
Fj3thxbpue3ksJJbQ1/iCtJvbLXu3jySPGQs5O7F2UUmAyQqx07WohbOobPmWTEQgLyKgnPZti/P
Vfb1Nz8aDT+BZE4MtpTnlCHvlp6lBNlOGFhXpKn18fYEuX2ctJbSppmN9iU/x0sZzVzTokIYjeyO
wnptG2lWEaPxBMl8crDsMydvwq0cqWD2hx1uqurCFXLEzeCVnfX6G3JlG3aBR/drIaAwvuOO1O9M
R3Csa/d8dpHvCg2MluWRLio8LUHHkRHtcHUi7tHfeHn1w0olQRyB2aVxRog7KOYrnRCxSNuH5VNO
r50po44pw1lQitIDUe3ZodnpZDe4VYx7R37kGyusxmU8RDstqvhj1fHXSJ3PDd/6dt/ndif3UMBp
MhjQce1A0se5G0ZNOxeSujv8WVE70+Dp0fa/ToVWXptnCHptHvSgCiH08NzW0TUMLTrMdp8fG9pu
yhx8XbYntlEFDya6KrA6lAqLT1DTsZp9mFoG8RU7BHjsQYLETSxnwkkzIWnQiEtKBcn0LWZDomPa
yjjtSbQsVkKkGRw6ACYajCrI2nmdy3pmBHA0+NQS61gpwKQbhpSAydRNRtRFCHpqiOPOw6VI01p9
iitKFna0lE8dJ/LxqBhBunDYQLqYRxi0o3yLOrAEVTRCaz6dHyTTBM2rTgGzrUsWQYvhx9bk+1Ch
vkO07p1oWFeAch/9oYhW2pPdooUaQ+RpdDv+kRIcSfZtr7LT1z9UZfrtXadp/PnRozIo8uY/ekr7
N8ByWCp+3WHtYqu/oX56b7dduq5v0+Om/Xfr8YmL036Iub4n9DbF9Cevb0L/APH85tie3VVyRip7
0K/9q3/W1B/mrHKObTu5Anu2j2bneXVL9mwVnbkEVZsMnCM2xYr9901H803/AKy/6mo/7y4vodiZ
v036fGfjQXvBtv7bP/Y03FY9XtQQ7iW/erKiTa9yJHviImFkbyNOkaorl7e1Ym/fpYrHJMIix7su
ztPyGLIjkTxr8qMXTu6iORo2QTMJlsJX5Cq9lI9sYbpzjzYokQFja+K51sM7YBxrgTtVV90GLY0h
6MZDkse5E+4Tbi3j50j/AF7oqskURFUOoP7JQ1JIoafZDkSGOosO+QxUE0UgUpbKta5sOl2I9WxB
3NkQive5hdOL9nUH+PT41TJchoBwZTTt1EPcbFK2XTucQd60aNsNu5o5PsXX+lb/AOZelXZvjEqD
qaLqGUQQpriFdpSS5JDP3AIm1sH/AA8k36OcjEdNC1Fn87D8OuWjJqCzGZsheRdsT5qiOHKq3q+D
rD+3RhVfk13CPAKpo2pnqBaYjiwNSyCCBpRjyS1x80I1s7UXZoX9yNZS/ECuoRuDQye/NkP7QQ6i
ZvAlpLW5TeNE/wBbUq7TIHvDMRzbOUn8arlP+tE/a2/bIPOonCiyK4oigOVgh05xmPNJ2hUp0OS5
fwg6VkPOzbLuUR1kJNgyrWLCx2oYu1a7uR720dWCqJjp0PVsbvs03p5Iwbq4HWho7J9lalXZrJvd
sDewoUsn1z86vkFFCajkXQyLxvvetoLxtRLHrKE9QGbIFaymje7+11ivnOXZurSc7FcXqvXb0b9N
826bdV9W+LiYvqRcX/4d/wCsv9JM/GLiph8d81ROFhGktNGvonczT8LuygHSIzy2SWXMPd1Z/r2D
XkJ9N9xJxi2Ul0eVEkcompXe1HDVZJJKNjX5ke8i47Pj+j+fnNBLtDsmcx2sZUJX2awSxJjJQp8B
CN8VR2Fd/gv2KrTJ+7S7VbDuGfbsG8X6RH28mp9i6RUJRjVbIKfxdQMVU00VPFsEUjKUSiaRGle4
KMZLjkO9lX2jB/wWcFTudT8WypB69aGzkSJDHq6OIuxZ33B1cdRvLKaJz5jStHHVDTZaDBM3mHpB
8BXYOTCx+1OqUagtQFXbTR0TJf3R1kPtFI5q40TeNhGId5aPZkir3NRg7QbgHcFTbCyzZ32VQOwl
8dqsq6xHELIZDDd3SmWOJ0ommYfYHdOTxLV33V6Rnoh6CSnYnQ0lJcQWiTTEdfMEmw5DONoB6eOa
a1JCORWoRq5bx3yESnexkOLxnL8ak5NKQxCYgnKvYdnYXKmOqyq1nbh6qY1zdHu4OtHo2LTu3i6v
MmadmNdElwkl5HCyDMIvMS0jzlnVbIqUgezE1C3eJJ3bI0YBWJMTeJcchSdHzm9maPvBjbdvULOc
iD/prHRx7OS0ESqnsS7YRJDLGrF2rleyej1M2tbb6rSa3Stz4TkVk8QI4q9lxapLPUxR18YdlHI+
4iNaSGdpw2OnvOO6kiwwVEoats63z2wo3hRjmDKm2l8GDFtrQlkemn+Easth2YWV4REvL8UYWn65
rcNcRgFsY7J0QtSkmdR1X00U2P5Me9rEhPpY/mS4EdY0TU7eOUl22xYlcJpNSamFWRpUtZxl6Ivo
3zf+in/zLidNt+m+L136L/R2/wDjRfbfFxcP8O+UVUXT15+6XMGUVPKGFbO1Z26K4w8wRHxLAbGO
kBe+VPC1PqzOFvNR5Yds3xb2ah8qpIxBs7tu0qSpldi/00zSlg2Gx1qErLeSFcO7d1TavgF+riMP
yQLKiW4WitrIZEcVPIqrMIR2NuIjLErSvpp4QMPdCcG3lsNlJJEFR3QkFb2LH5VW/ikFbCK36sIS
fqFneZeje1LULVnXYuMfUIXYltHyddB42E3vvo5ow4l+LtFvGDKK9ERFuQsSyve5lbf+/wBeF27K
8UuVU8SZE1AILZd6IzbGajzwr5jA2Vqkha6csI0XUInN+vBbkjUmxY2qBcf1HHyXqUTxhuBPLF1K
ADZOpBGH+oGBKHUcdUJqUKNn33kEBfBEK0vVkY8qvypmsivhakAFltqZshJR+85V6NXbKfUCxc/V
4uza3nlOpbkcLP1kJBSr5jz/AKqZ2F1C7yG6sY4IdV8CM1dHVsvVolZF1Q1pf1qFB21qk11ZA8ks
XTqKiacbhqBrGE4VsmNrMQmWupRzsqLjwHS9UIZkXVHYZaXPnZV3L4GfrRvbl6gMYsLWHZYuuB7T
dTLJfD1mkdljq5k5hSd0tdqrwmytcocc6Z5ToNm+E9NcJwbrRWuS4damiN4xLm3+lsttTEmKE7hk
hazfEHY60fLQpXHeuJgyqN1fq4kEc3WhJTY1mSPLNq0hRRrM4ZMjV5CjhapPDcmvi7TtZHmpAuTQ
Tj14ZiS9cSDsFfSRHmWRZq74122VtseCpNZzHMkTjSTB1bKjiPYmlGFqyUAbbmQ6QLXEwOSNeyld
YXUizyId8Zzdazwsn6qmzmxLQ0N5NazlZLnFmu39/wD5d+if/Hvv/wD4HbqqYvtm+H+HfKZHY4i+
PJRohm5mEZEGAiuWIfGRZS54svCRJPFIsniYBEcOOfjIYRrgBkKhgEbj/bFxcXpti/0IYHHcOqPt
IjFZhE2z5wbTpjueRgyCL9NOrZEV48AJ7nDqjqh4D2J2nI4FfJc0lWVqPGrHRoRi46sKjfAfzFTH
VFpy7Hr3pgqsrmpTmVJFaVmEa5i91zcUz9sBGcZzak3F0InMVI92LSl2PWvHga9x8bRv4SK94U7a
8otSUySK0gci1bjr+nXZ9CVFdSuc5unnYmnn5Io3MbIi9pzk3VOTlh0jpDf0ztn6cdtMq1BkesdI
VmnntZLr3Azw3LhY7mYqbZFjrIdH073GyNOdlkgPaevTb34752s44rd07aYmbZtvjWc1r6Vx0k6d
7LJAO05N966hWVh9N9kYjvrDh1q8afrh+G1u56TrJ0xVai4xuy1tQSZjNKcUNppOJKR/eBpb2dpZ
uy6eVCC0g5zX6WazJdE0LImm1kKzSjWpL05wbJgKF8KgfIbOp1A0jOOb4i5Sz2RDQ9VCcliF1iO1
i9l/Fc45w6cPZG5tm3vtvjGK9afTj5uP0fwHZ06x1Vu2LnDBD5up9MPn4fR3bHb1qxV3xGcsZH3y
n00+cr9FoxtvSOi45rkzbOPvBhPlEr9FK4V5p9sHBhUhafSDpbJWjUEK3qXRH/l39L8+jfN+m/pX
p8/1PnNv6KdPjPnpt1X/AODf1r89Py5N8cm2H+HpjE3XT9LzyZAYwVLHYQk2qa4dNT7OlwRsWBXD
I0sEbHyYAu2GnY9lpQbZEpk7F9AaFtMAT2T6hHtsIXZeRvRcT1bYmfn86KiNkI6AIYrhRsw/u+DX
ukPFRNYKzgdjKOpRBOgsaO3iM20/WoZzK8aJZQxokSAhp0atYjLCGLjLhIsmsqmtGeELtx6xjyLE
GFkcQz5KrG7jGNiB7RXz4DOE+v8AufTCY+teiMhucSiovd1WJApWNWT4QwsCgTrNqWuyJStDigDx
sKtHMFUbyq+rEwF9BYxlFEY5khAgZIsI6ZElhI9JMUbYsqPIJYRWKCwgqQv0V7kbUuEWueEbD2sU
agQZhahjMblJVt4vCJrLUY941cNUsadNpcDtOq5Q4hKKSGU23A1Ytu37ubb5GApHBoSEaunyIj6p
6KykIqNoH4epeHI1a8+fp56oWudFdpZ45DZ8VsgNxVOa54+27Skhh8niR8W1HylxaMhs/TT8mUzw
YZitVcis5l07AYGJYWKQWxSpKjyRBjlNfiAldM84ShZ3Xu4tn6maN77fz3wwoAEq47MhzGmGeg8m
bGijiCtKtkkdzV+O5yYuD+dPg5na9PCv2uJKj0DyDHpgrlkadcNoaZ5S/pZ7WJpp7snVaxchQHSV
fpwgmU1V3p0aMyCAFqORJtaxkoJdOOR0ioeN7NMEeEEDtT4AGx4ciwGF2qSixg12qKR890bSzArH
jshBFdDLLs61koJNMv5yqRwnxtLFeLT1EKOltNWHGsZ06yzSlK05yvZCjVVwlkupaoZYkhOB1XPn
qqdF9v6n59C5tn5/+hOi4q//AFJ1RMfhfh/zDTeVWRUGDUMpwkqZ3ZkwWpLY2GwTL+Vxyhcr40+O
7JE9RNrSdwDmo9GtRuanHtldMdHmCYhQaiCjVNi4vq36JidNBfFj7BtyKpoUZZRquraAc6Y2Owhv
qEqnEigtCLHyfYdx+mAcRWDe0OzsNs08ndMUOwLKaosiF8yZCFvHtDqDKWf38kj7rKyN2VtS9tpC
mkkrIqhbOnoiRq/v46AEaSoQtodU1SRI6Bxfhv7ZUgXcHBh9ortt3p+xyObNIPlHmy0hmqpiSAX6
7iojo1swaSGGpGvSXAfDzyTyXafr/GbPkIrYlWx6fTwZNrB8LQpIrq2EWYWKqRY9pKSTJq28Ytw/
tBtLRXZTXrhPjubMHcVScZoey/RfuG294ds3Y7samaWqENgoIRIsULknQRDdGrhKzwwcrGpY4dZX
ojmxBI25qWOBpNnA2T69sht1V9l2j/Ykv/WjwvKso8IUZnbYuW1eJ0e4F2zKmQ/YunTd2FKitkoF
iDHqp796ejdII5468ALxDT0OIjS1YTulVHjZBs2KPxwlN0mBcYYWqwesgp21xcHsmaUkjaVGNVt9
tHsKTtyIquQbTAZIZArxhWTIYzGCYxuo3tLM01RpEw4mnHEgeLbP92gioGyKuw4E0Mo30qOpLWUO
HEqpIZ9qn9usSIFSSiSVpqR84lfXiqo7LhkqzJ/aGGMU8i/srrQZjvrI732M1ldFpC+RDOglatdE
ksr65IJ5rUfHqY7ASbxdq2V7Sts26L0TF9O/9bfovT46/nomL6N//k/H9Lb+jvi4mKmGTH5GXaVX
P5QtTN/bHY50jT7HDCVNx6gjKpNOf4LCYg22KKbKr9sY9sscscyGHqZ26gTnOiL/ABtSe7Te+L6N
9826fGb9W5oF37p/+G4T72nHsa/mijuAkcoirGk0xv49+bdkl693SkrvitjfatTbl0lK5mKf+PfF
XlUyFHOhl2j6ikft00zk2VI7Iqud5DrAHdyNVoNZ0pI7HFIaXDRPHvDkZiWptoFwxqRrcZCNdybu
1Ty5HZHAsO+Xb9z12aQm8xzv4987d+mt+1fN+2GYYDlu5DMpJXmDu47eFNAaZ5uMUCWDj2cVf48q
zHHWTeI8UlfNm1Fe0Ib+w7CDnO86lIr42pSqwU1yuLAgvlEpYqxB3s8bRyiocmjG7Bs/9O4XY7vl
M0d/gMZAMfqAaOnWKyCQF3jFftYOTkjAtHjSI51h/p6a/bMkqrQxHK8OrWIxukG/flf69Pulm5eK
SdQsCSfdOkBs3OIXIXsakaja/UEosdtQ9xIEyuSWbiyGC2lnnv8ApkmOqfUGs07IkvmSkRY1lLOG
ZTyZ5zp8Iu+WlsOrZDkpMj6yX7bk3VGYie+m2/zGJsmqhr5WmP8AztQEcOIPVjmZVEUsGexXTnfF
6bx7LTuoUlrLlsiBgagSfcmX7cJpX2c4qCi0QnmuM1iF5w1Y3xp0f/BrvmpKOqWeWvgCq4+qNV9p
NHS/5xv8cQch9lMKgotQF8m43zVgVOHTqcK7V7SPj6bY4dcpGo+yRzo1AGQ1+pJDQ10l3OT6lxMT
0b9U9a+rfPn0fhOi9fjrt03/APt29XxifC9HYX4J8jXZ9HasPGt4/fHUQ08tZCRmQrpJJLYKHbTM
7I7CP3XrARBRHNYDUT9spJP8XUL92U8Hu4slAAvZqEc/3x2b9Pz1+em/XQbtiyFQormFu9znxS0d
62S042GHNr0dIp9kDeNRUlpxJpYfYBabKK1YjCaTB2yP28e9GnKpF3pcJU8e/Yjm6ckoJTqh218Z
IyulM7nNqsLC8gxqxoEjyGdqXGbIUtY1jLZrGLQoqyYz/wCK4yNMUiHZDjNA6bZNj4C2bJawbVWx
smgH/vlpw9odoNHiHCa5/wBMYRteJkNt7YN4adktVlzLb2QzEDZwZzSALCbIJKhCENpWstY0xjYm
o5KPfXi70ym28fUKtcOSznLpIjBMsbVkYVlZulPrI/kvoIzY7LiSxkWzJzKvTSdk1jCubKYytjsy
0cMRa+YxIz5rHT32AhsFZiLjTsYSbLY6PTlQctVaRqmFHZqa2aZ+lGtDkgjWBbMbGsgy2SRfTw87
l0Zg5ER8gn0guwKszH0k3gI4Ry87wYg41qM5CI0jAQQiyyJFEoBRjtDFDGfcXAgx6mMyc6FEBEbb
6gHHbU2YyQ9V2DSrQTRNr9US/LxlMV2fQzY6kMmaVitGVCsVL9Rml03AUW/IzwpZESZpu6Y4LVGX
F+NUb+ZFnviPkailyBw5roxaLUA5I3zACFdaj78mrPGhRz6zYKZJmx5UaF47rQckLmawKEq6QnhA
y/1bsB5XGfDlujP09qRhxusowx32qPIkU8mLEjTNZ9qW61izIdbfiiyFlQZTSWcKGK91WpJlLqYE
sEzUESKLUmozWUnF6L026p6dv6Px1Tqnp29C9V9O/p2zbpv02/8AqTFxV26F+CfOV1gSG5uowyBA
uGhkTL9ph19qsSUTUo3ZH1KIefqUDlPqQb2t1G1EtLHzEgahQA7K28nIF2OMyfeuKhTK9XL0X+ht
0/NPZfTTB1aNWzr3yMMTk5hFE+PqTYT7n7kXVgwpN1H5TTF5lhajZFw2qEksmyu/lbcthJ+rmvZM
sllLCneC8erkaOZdeUgZb4xY2qeKP1O1UffEUotVcU/VWSdUOM0WoSBVmrm7SdT9xJExx3QrLxcF
q3i0948qh1I9jf1Jukq3fIyLYkiObqZVbMsSSMh2boSh1YrMLqzuJ9berxamIxC6ke5Js4psiWz4
WS710nHl3WFqAsVE1e92Sr4khEkOaVl+bhIkkkZHO6MQGpjjSVdGkI9zu4y+KJsmyJIxzt8hyyRH
B1PJYkq8PKaVyuXPjI0t8Z0fVUliE1PJKkiYcz2X5xNW5P3H6gkPaC/kAx+qJJMXU0riK5ko9mqJ
zcLeTTtIryujWMyKjr6a9CyCkdHupoUXUNiqNlnlFrosfikeKmPjxuNrK8TG385cNcTiY2ykgd+q
ZrU/VE5cNbyJSxrSaNPrFlsc0mQsaRJj4+ysn4Vkk2DlywoRJMjGklhylK16hWFt3IC5ZGh9qVKe
wizbFWmNJcrLmWFC2cs/SMw++mGyVNmqQIh0ZyVK972uA4eBcZmOdYPR6EY5ZsjZCP384yI2YRqr
ay8IchFbIczHOV+fGI7GyHjzzpDsQi4ssvFHrv5JUa0jmKs+SmPknNiLtiSXsx8gpOiYuJm/Tf0b
+vb0L89V/wDk367e2fOb/wD279PnouKmF+C/LchxnlclM7tCrlJILTOGwEDvmdRqNseiUmfp/jjq
DZo6JXJLqXiyJUOM2bWKHIVYslkmoexDBUblxcX0b9fz89NsrIflnBpr9k6m7GGHxdx3UFe9zSxH
DysrFlY2gV7Z1QocDBcdwNO8kmUnbTxV70Oh5tPQcWzISidX0ffb+nNmPpncw0Ht9ARclUvbyLRb
p+n0yTQ8ElRuy5WrnBc294MB0l4tNr2zVGxI2nv2/p5uTKPgkSmcR7NOI5s+lUKOiqpK7TynbPof
HbW0vfVNM8WPoWplhXIJDC/d2t84LjG7uqqRJDZmn+yM0ZfIq9OuOlhQ9hsOp754+mtmOoE2sqPt
4yoeXJNUQOEEqZVxPILX6fY9thpxADnx+09fbPnGplTC8l8bTXIV3WeKrm+6iXHMXOO2fGb75Eb3
C0un0KyfQsECHUtOYOnQtY/To1yZp5ULD0y1GLQD3saDgyW48V/nzMSbLXK6vNZPiaZGMdjp9rUs
ICge5mdtVyBAU5K7TI2iWhEuTNPbZE04JrHUIcdQg4C00jzfp+OiG0+NzbytdEVTnRWPkkUcGQbK
TS6KwmnwcLmhUWFjKiqxUyOBXrRUQfFZEEHDHRrdSE3dp+G2QcVFG4ajrOyWh0w1RFoo7mXdD2sO
ztP39Xxi4mLm3p3xVzfN9/SufGbf1t/Ttnx12/8AkX07dfn0b+lP6S+r8fnFz8bb4X4f8p86ap+b
ZjBgFWmGtg6Kw4YNLwlTxsAynUZ0loMbnGE8UEA3jm1YzsgVTRD1FFRqUUkTcfDbJFd1vaUjNsXF
9H5z5zbPjNumh2o+e9rRgup/Fxn9x9TWOO4VcMYrljBJpuAiRX9sTbNzHpp+KhpCMYDLJ7No8dpr
ONGaIU14+NkjSFqoaMCcg2tiMYYp9gjhH75JkZjcfNFHyHY+SWWxqglwPIImn1dh6BWIypc4tHTI
LOKbEitfMI1BCiyVMY8NpcDXMDizGNJLhIYS1zRS69jWx9QNTxdOom006hFKszI6QckpY9C46fph
USZROGgKx7zUMRwh2Dd4gBNdMgI1se8RPCoAtc6WRwgVpXmy6G1I8B4S5MrmmHZ1aiUEh8IulrR8
xti3eJcf5X4nyAKldp+nKxzE4s1QLkWHppx0/SyNyfp/ttmRuy92JgXcH6TkKaLcv4QaaW76l+G8
uStRcevEcS0KazOxHBuAK6ZW6Yccc+l8Z2na9keNPmrEyOTyY9pTNO+VQbJB0087nwW1jiaoVEoP
KM6xlsiiNrZrFhXMyfN+Go5HZdNO4cBr2RNaKjWjCrloNN99WVARyF/YyFZGPOlxmyBG037l0495
Q6V8ccBOMXUAZBglgWGz4BnmpNN9tqeyTY6Sbd/2xwLCQWxngaaLesRs9enx0X+ivTfp+MXpv7b/
ANXfPz/STp858en56J609Xz0Tpv1Tovo39S/1Pz1TF+C4TpppieDqReLWlcM1BK8lm2ajk7JpVd4
8mO1yWJliM0+XnG7jd81MmHcoiU684upG/tNjvX8ej86HXaxlpvGu/8ALWxvKkV8FscVrPSO3v8A
lS9PsRoLlvFtjOVC6ZamT2J49vLUead+4ZrU7F0ZQrCKkiXWNRI947tLSS1JIVO4OKMbC2zvtpEI
c8WIkUdjZ7LWxEcyXIBFQksZGQgje8PFqYUe0pW7jCwbTKvvkoHGc1Pt3pnBfpyW44b33BUTWx1J
YCK1sUUhB0je6ELAtydGaRsSpYxRq1MnrtEsTvjStMSiFjXn+pQOdzJtxArMvUVYvlPgyqab54re
vb27ESMJor9rJ/8AqXf+d3uqZpmq8lRCZDEi8kng785EQIxXaHmTY7Sgvw8DPTPjB+66O9o97/o1
Hta/jF35F/xVwnJbl/sZBSRNC3ths47Sgr02iWKN7cL/AFreb4WRCMmx/YbdQ2qnNp3TiudLksrw
XlyWaWBEWQalpWQg3V02G2icQsWTLFEYErTD1hHcXNOaeUqlIKvj11v59s/+0Ks+oEXYVVbqWY1u
66gsvp8er1axoU1ZDdgnBmhSoCkiQdIwhP7g3f8AtP8A7QvGtjJXaNf/APqddui9dvSqZt139G2L
12z89NsVPQvr2zb0Jnx0+M339Ke3TfOXo/GJ/RX0L6tv6ydd836b9VXCruhflM0wbeBqBncYgFea
gi+KJCNXL+JzzSqcRWUlRZJG+UzT4u2C4mLEdTz/ADAaiduihU5qh3CNqJ6bGXHdFzb0/PROmiv/
AET+8W+GvOsmNhSYsxsgNlC7rZkd4C6Yc50W7e7hNRXE0aRzx2D3IK3cvkaYI/6mj18XUD13iuck
urevjagc7jpfZcluVoqohHSJQkJgoDWZZFc3PCMQtaziC9Er0bCktQdgWBkPU/ePGL3QuNykSl2D
AcV0zdExSJsfmSV3O2C/L3X6ZGrRXI+YFiGUzocpqadaRGY93FsmzN3GSjvMFftC38mw/wBS2ApT
aXCrA241JFoR8FtOSxaEZGZcqnhx63zZkGIOAC/u0RpSOkl0fGcxJ/8AqXi/yFxuaNIignoqhjps
I/8AvE9xQoTmz5DuIL8iOkvaucMa330iNUBdN5wacC/VsiSlLJxU3QMFgikXYU+2JDn116MkW+1N
slHYsLGsgElJEF48a9L5xqsHjwTJ9odUhbRjEEOzhyrGRI0r2BUMZB2pHcGXx3PsqF6OrtQwnTUr
BdiFYxkmySmDXR9Saied2k5jYszmkgMOveGVaS2xounoKul7qiajgrLHE020iG00rXVofHhckV1i
FTx47eIJ5vGtUI2SGDUeNMubAcSJPP5M5f6G+bdF6fGb5v036Kub/wBPb+lv69unxm+L/UT46L03
zf8A+Lb+qufHRMXFwnwX5zTV4gEM5hggjI2wWUgY8S9VZ0giSGVSNjultQ+dgYhRZbBN1FIR4tMT
EZFvZbe3RBQjizmRhW1p5Dirvi9d+m3r0mXsWSSGkFbgGRJiI19RdOgkDLZIDYDEYtKRoWXB2OZZ
L9zTe0Zk2QxwbtzOWm0a17ZQ/Hu3sflWznOrpLGCu5A35WT2xZaSmnQSjA49wxChsGEY5BPJIfGa
OPasxxBnw5I4WXM1j1o+Ljw5wmAlWQxnZYtK0RQhdZ3bGJA1Eh3jnhRLW8RGQjJMfWnFHZMliePz
AMKJwnoyWGKkvUaNIC1YdiFjpljaBFlfeMMxbIYnS7ZhB9wRpNdLAEcmwC4TLYcczbAR2JYhA26v
WlysliCO31D+yXMed9O4bj1UsEZltei7FkfukXppy5SI4dwMw2Xw0ydeNaSHehKxLKMxbfUScPpR
LB36adi6WXCVCRXU1oCMOzuwPj1U4ApJ9RBaCvvmNPN1O1mQNRhMgjMM22J24Vs5XSPLOPHGeRam
4dCJA1IEg7fVLUbS2zFNYaqaIdVq5pV+vx0ki1JCen1+CzLXVEXx663ayzmarE6NYS/JlUGo0i4z
UkNWzNVxxMHq1EfcahdLart1CdRLRaoSMkjWEVgp+oXTZUfVMeNHJq0jpj9WgJHrtVjjmZq+HtL1
pEYMWqnpNbrGM9jdZgY+61ECWlFqzxMka4ioK5vS2Jdt84KmcccmJie+cd8aPHMzhm2cFxUxMVN8
3z5zfp+OiYvr/HTf0/leu3p44mb9FxP6G/Ren536benb/wC7b26L8uxcJ8FXFwSrvFupLGLYF7jr
iSRiSXDMl1I4hvZKYmopeP1BJcjbg7cmTiHyLYnjJIsCnyNZFhYayMfDPVei4q+yL606b4AjxvjX
E9uSJ8o2FVVz8x7OSBHzyPUV1KZn1CVIaZrnKKxPHz6tLK03dfg5hYqit5rsI6QbEc8BBW0zCHky
EcJzXAlTG55k5UMU6qGbMTPOm4aXNciyTDcl3NTHW0kmPM56ie8bhS52xXmJgHS253p2G778Qb+Y
/N4laZyIR4VDNnPx0mdn3TuaGcifztjRjOwQZSYjJuGjyFwUOQipFlrjoctEKJ4nPmyWZ58nFMR+
R2yn46LMRDNJiPK3CI9UVVwY1coIU1Wnr5jUKNWYqYq4i4HvKqQJLkN3GLzI3FkGyLJUZ4F9CQbd
TQm47VEFUuLgB8eR3JXEcu65u7OS5ursAj+VJZlhgttQsIKYbvE2Vc26cl35e+64vwmI1dvdOm+I
irkamefJNa6OnH3j1rzrIhuFitzbOO3RFXOCY3I0JTKLThXNl0zo2PGqZwzt4MarkShLLw2nHhbJ
jdhyrnDfEHtkWvfIc3SxuM2ofGx7eOccRuV9QWbiaSPxTShVybp98VsKnJLc/SpmMn1z4yqm2Ln5
zbpv6Nuu3Tf0fjb0J1X+jv8A19s36Lnx0/PoXqvReq/1NvVtm/t+cXovvj/gye/zlbDdJeCjRofp
u819EihbUqs1aJEFEpEepKBGZ9CTgKiR2TdPK1tXSdxLOm7TayC2Q6TR7MnV6iVzOOO6bdFz85v6
aSP5dgCgThZ1oxtmsaxw2K9YVM4g5lU4OUdV5SioG8bGoRiQ69SzYtCm0+ma1DQdpFbRfsPRo1ln
AQK0tJ3G/QmoMlIjiAoURv0oe8ykRUiUjWolaLeVTsVlnB7TljOx0Z2dtd6qofJJG02xoJdQ1DRa
NqN+mC3mUqcYdFyIyjY0djTJxLWr3qbTzVFa07AipqpD42oA1p4wW4SOMr4lIzj9ODuWlauR6UTE
JEjMz6WF7L6AglWC9+fT3ZArHGLWUDBjPUiVtvTbLDpOWTqLg2TFUS1TGuPTRQlbY1YnR7gKDKvT
5zTUNkkkmAMce0GnfZEc9fpZcfCcxHM2zjiomwhcsbXEXHV5GY2MrsbXvXEqiKj4jx5Ug7kqPBC2
HfNa0rIriqlUbYlYZmEZwzbbOO+CjucroBEaOOr1SvLn00mfSyOwteQORRqpaOGFImp2sE6BAdJP
WUQo0bUlWoldGXmKpIRHUhcLDcLEZurK4rkZDd3NP0DADVw0W1qGyhT6d7DFgPHga4hspdOvkHjx
hQhPYGWzUdJ2sK394I7iuBpwnCkoBxGKcTXWlQyWKxpCNKWueNAVzzJpTtQkmXsWC2sth2orWH5o
aurHWjSWGQ6+oWFFPB4x8X07ejbNuidd+nx1Xrv6Pzm+b+hcTF9Hz0+P/j2/rbf19s458Y/4KufC
6OrkKCwckUbbJGz4BElhHTNQtmqRx0M5ZDp/LZJysbUmQrSMQrY8NkfNQCRBhnLXSK1WzgX8FESQ
3Zzk9O3Tb06R/wDY5bR7+UqKVVISlqFJjQMjCuLBu+loydmURY+Wdgm1APuySs7QrCeiIBUlWMYH
AE6dwyeZJD6SOnYmSnR8hzWlkH37UJhvKmcRjlWvB9e+RIMczWBJD817KBNpFGxGtpEcarrGx0yS
1PLen2QCN5TmorWia3JksgjoJDDnMYA9ZJYUFz/p6fdss3dRSoUhXVoCjkIn2Rxi+WX9orS9cJ8C
RJmyY/248iH58hmnxNQlANUgU7QEk/sDWkIV1qBHx4ls0UngyWO4p8kCUD9GFeqzf9W9T7zs/Lfn
S8L2lxFWMeF3p9bpsTBLTAyy0+3t2UTxyO6UMNDvi0o+3OoBvHCqmrIFQiVv0QKJcUiDZRxGuOKP
sG8ifyqPT40AtYBEsKwSCuANGZ2NzSdOyVlvTMaCgpGkIemCiDpguRKyM1LekYookUaWUALRh1ZG
Qa6aGBB5f9vxqSpbYyWV0YaOggdmoqZomUtK+TJSnjNDJp/GnsTiyfHKspPZHxY5iy9OsPkemjxg
1yDR1gNxY9KB8fL9u8AYFkStN6cQbJZwgxMmwSvnJ8duKU0zTzJCgqYsQGpJjQmixJFoWirPpkTz
hulmTcVbBdHs5ibxL5P+y267Zv0TqnTbrti5t0VM29C5t0Xpt7+jf0b+pem/9H5/o/PoX077/wDw
N6r87+7sJhs/GiNvpuoU/Yb3fpM7nNzUZHIukncsK5vG2ImaVe5QnmNBgjNM3UH+CwT7mlV2h6i+
JX9z8X0bYnpT3zS3tcP/ANbUCfvrgoaXCAwIbiQ/Yj/5GmiNUVuREFayFV2lTtekl6ePeSP3afOz
yIxE7GoD8VjyGjl0708e+KiMpXvLMR6MCCax0ie1SCHVKSS1jYY7Wze51KJHCtpzorW37CNrpjCO
ZMYqNXdJLNzboxjLFj5K/u6WDmocC/b1MuaUVVHcp/FBZpBI3VA3JXTRWGLBbz/talmN0o/7wTYv
dm1FW0I7u1SMlI7uBVdsdNC3AymmUyogq17VWy9oVgjnSdNIZW3CjaC0IjiaKyZ/rXn+d3Rvzowz
+4X/ABQ287VfYQJpn2j05M1F/nXBN3dpWoRWp+1EwzlHbs/tiFc6XbJvBhEVtoFdxXP/AK8dNgap
mGBKbfyHMsDOkEVMY3bNEe0Qg0I2PHQGWbuMOCu8S3tPp5pmqBvjOlKadULvXaz/ALKcxPND7h1a
hCn0iLsxCFaJjtQQ0W+uxyGaetIvHf2tLGP3k90nTf5DffLCW9ltHZ3HXJXBh6TcrgzDdgdQZZCX
y/wdOae45Y2Qq4ArklrbJ8SZzvIZk+S76zGYhXXpXjgPY9ZOmKsYo+orT6bE0fMdNsZC8QwJzpNj
Ndwh3buVp1T3REzbNsT3zbqvo+ev42zbNum3Tf07+rfPjqnTfNv6/wCcT+r+P6Kej26Ivtm+Jm+P
wufOaKmIyDaM7wzwVSZSR2xwpZD5Wo0OzT8dQGs+XFsIh3UsfsNv3bN0xMeQeoH7sUCnk0zfFi6g
lJxO/wB3YuL6N/R+c0z7XHzGvYquzuPhFp7tsocmO07Lau7btKMUca6b+yxbsXSLFaaU3eNdMXuU
o1dOA3lG1Cz37alNR/698z9mnV7cozuQYcNWzSOTiILNrQRSr9EXaBsFlsDyM+h+0wToSQ7OWSVW
vc6OYm0khOQY8FyTSFQA2WLC4+MskpDNjAtD+aXTMRRCsBd2M+r7hFomObR1ixcIdg1cRrmCr3LM
kEQIGmR9swqMiaiPuTTslvbsWPktZSGVAyEhFU/lDiRPGy/tWDDU1/mFdIFAj3t53VEx0oula7x8
nPRsW8f996++N93aMjbPen7WbAtGGQgY1Xxmy5DY4Ll/ekrHXBx3I/TshvYOzuPR3tJRPqrP7BgQ
ZL6YwMSoF5NmibJesayfAlNKGwqGzylowRY9qxvd8V7sSM5F0jIQA9s2y5OnbjN4R9Xja5p02LTx
1NIrx9qHqwaPFFckWfWy2yo0iGIrYBwxzy46SwRNNgAuowAjMjzfHkP1vuBbVxJtFfDnCWEJxbW5
FXhpI7ZppVlHiq9wZ0Uc9KeWN454eIoASXQ7KynW4a8N5eEsy18nxy0l+yaLxBqW4vBV4qGM2U+b
cRYePcGwiagjNjH02RpKzXchqjpLL6eWstRWgGRgxc1VqhgREI45OqJm2bZtm2JjkzbNt82zb0J0
2zbpxzbovVc+c2xc2xfRtv6F67f0k9O3Xbp8+jbqmbZ+fV8/0d/fo7HLi4fEyssSQi19qKVFlHF5
rLUbY5LZfPbajeGLNE1z7EJUSfHG0dsNj7e1Y9mn7BAJbWzHtqTD70m5GMdjZOkkeuK70b+n8dKc
6Rp8W7C5lnPDxnGaQgZBI76zULCgnWQnOrLeOFJ90Mo7CQhX0dgGOwt+J4raYhlopAwODqAKCtrR
pciFGOZBvQBZZXQytbOcGVE1EAjPrYGZM1Hu+NqQey6gDvI1IPgPUjWkZqCKuH1GJG2dosh1ZLYA
0TUwhMmX6K+LqQTmfqICJY6i7jYl26MUWqBsZY6hU+QZ7BFi6mjAQmqwlYTUCDMHU4FR2qQok3UT
nvh6pHt+qQollqZSsjWLhSXama4U6T5Lqy7dBUWrQbH1aNWTbh5y1+qkjtk6yYRk2xJIfC1IMDLL
UKy2ver8r5fhlh6vjibY6vbKbKOpXO6JlTqYcAbtfR3DnXimPA1kgWu14DaTqZbJ9fTNM1NOixdP
jTDE+m4XWQ0RNZ8crZ62E5E2S7vkgZa3JZq1dz9Oxv8AyCjWWOo1nLV6pLBYmv0RJWrXS8qaryGj
0+JUdp8KZMjNr8PrEgV/XZtv1MVZAdfuEy01W+wxV5Og2DoRA6+KBLDVxbBvcVzq/UR4CSNZnOz6
tISQDXRgIbXskiT7Etg7f3cuI7bIVmSE9NcyeEy1PNfD1TIhjmXB574mp5MNky1NOdD1NJhMm6rl
zWxphI5ZVnInJwXFXbIdgSG79aTUbKsDzCRtRyojJdkaY6NqSVGZNszTnxdRS4Q5llIsHIqpkOyk
Q1kamsCtO4piZtm2I3O3tnb3TjnbxQqmK3bNum2NZvnYdih2zboiYg+SNAuOjOTO3iC3xY7sIxU9
S9d+i+hfSq+pc39e/o39W/T8Zv8A/ByxMX3xcVcXF+JGb4NqqsWIfYgiorYp+28T0cOEdWChyVXw
ZaYkKTt4R+RYZkRkZ5HFhmGjY7iPdCMxCDciuxcXN82zbqvv126DZ3FjUx1QlYcTTDUa4wSvxRva
0bHvcGoM5D1xGZ2lR4Kwj0LUPZhAKxY1cQuLSmaw0N4sBBcZzKN+xa8g8DUEJiUT1Q1SQWDqnlVt
C7D0z24cDmYrETqIavUFE8rTVjo+Bo3Hz9OKmGo3AxILnEFp5XJIp3Ca+OqOh1bz4SjcFoa55nj0
0qtXTm2GpO3gKFTYmmF2PQqJB0ryObpp2xNPqNBUbnuJpxWNmxOw7jkKA+Qv6aVo5kXsubEeTHwH
sRzVascSlfC04p2n0z2hzo/Ze7omKuJnzidBEUb4mrZYsgWVhNbPuJkNJ9yaTior3I1d6O0DCX9Y
xmCubkc1xE3VGrnFVzjg2rvWafWW2zp0h4C/mQ8/WdnjtY2e0jUU6Uj3q5Wrv0RmbeyM9kZviMXO
G+NZ70lC6yy0oPEa4f76qjfPfZU3hY9u2IzfOyq45u2Km2b585tiN3zjnHFHiMXOGV1U+aSXplYQ
jD2Lx91ZnDOGK3EbiszhiMwYVe6k0os1hdIMYO2pnx3PHsvDO3vjA+9Lp8lgQ+jBjBZxvGl0OlyW
C2WkWR4sxnCRtjW74KMr8pdNvmvZowDG3emFjYWOrXcMRuaX02yzxNHRNv0dETLrSgwBodI+Yr9G
RkHqDTxIb3psq+vbqn9BMVM/GL/SX+sn9Pb0/j8YubYqY/D/ACvzTQfLJDqGBBOjjbKj1rHR5NHz
k/SmMDDiDUxa0TWMhhcga4ZSyaNjxwaLia1qmjFAE1s76cMo7ep7eGHxc7F6/jPjp+cTPzTM7tpF
rgtZcqMTbF6EIECmdWUP2rCsYJmna1JCirxCbZRWbAgIWxiVY2Mnxh8bCInk1NSxojxRoy4jtRKC
qRWeCFrCwWFMKvEEaOC4smsa5rABj55kfk+I0oreJ+5tS9+PpyNR8NzVpKRXuj14QisYDFkxYIgi
74VOeA0rI9G1pOEcKSoDTDl1PGTT1owitYzFi0YGvK9WgHMuQteOUyYaJGGILpwnSCw2EY3sxHPv
Qo4Y2yBjGJkowkIO6q3dzxPvadrGMaRjXjvm8ZFRDEo5tSjmWFconRJCQT6etQy8mMR0e9T77unv
nzi4mb5vm+Qmq91CnAGpvfAQnyXB02Xi7Tj0SRVKN0XTSmQmmFG19cqFZQPc1mmnuyXQqFGAVC0L
eEfVSquQq58nB6WIqH00rGzoTgKvt0hRlkOXTRGCSuVZH6ZejGabVyM0qR2StMOAwsbtF0mN8cGq
nLxrK50otPAbBi31ckyPLr+0SDpMshn6NcmWWn1j4ZnB22NT3rqUs5RaMJtI0i4bR6eeUi6Weufp
F3F1E/vUFSleOxiLJBY1Khlg0s9zBaMIRJulnAyNpYpstqjw8rdLllDtaZYOVNW+xyRpUkYWnKxJ
E7ZsYMG6SXLta5ksJ9Kuw1ITvD0gRAQNPukSoUJkCPI4oyQxjtQV7QsjWmywrJd7FrOWVFO+aUWl
mBBDhshilX7gWJQMlCmaTU8i008sXK/RxZAo8x2ln2evXymaPlSpQJY0MNrGxY8DUBJdjbQRzIlu
Ps2Lne3Xbptm2bdN/Rvnz6Ns3xfQvRPVv/T29f4/qJ032zfCe6HXPldDR2vDafZDNlKsjTk/yQNi
DTLcqADSSHFsTDUgpCuiOoZ3kkzZMuE/i2C9uRpSS6ZEvY6IyY37jvlcVMTF9f5pF/7US7xtQPVM
27pKOlTY72RR29osh+kwcRWLOIrSwVmUDe9KcL7FpNWPkV6zZkEX8a1MsdZE1ZJ6AewLXcTYlnvN
T7wRQeMuYu0edIK41ZWKqy5yRAwo/nvWAEDDCErfp7DGhxGhZk5v8lqcxNgNbLX2TLMb3Gjt+1ek
8V+n7Pyh2n+nTGRhilGUZasZlDVeNIGn2vAYkgq8RWDyGkwIDMC1GC5L9RyZEadtrXrGfQW71kKv
29Qf5a21fBJWzWThW9Wjh2gEC7Ri/uk/697/AJ39E6fObZtm3SoOMcin4Pi6qEjU01VsRkiQGGwJ
RTWW1eiEr46ME5jXpaxxw5tcIbwOIIb5kJkgJ+3CsqxWviatGiJpevYKLNshV7FuIksWoCsfj/lq
Zo0DSSpA0IGLUI2we1OEIjCtcRBtI1hx3zmRpWm5DJMXULEWHU3A4BoMpsqPb2TIEen2ubJE4Jlu
Jj4VsrfKTIo+RNPwmRoObb4YrI9mvtkeYkl1sNoR0dqlmKdN8UE+982ZSyPIgmO0Df2lGFGsHrJq
c6RvCs1dG8l9DTMrWFGhhwa5IVqX3HFAMc+QvGPVXKTCeIHuX1slZGoEYSDm26apjpDl6GOQpLL/
AEbBn/YU1O+cSsqxVgLLULVmM/sOELzM+Prfh2zwDkZNlMrYd1eEu5enNOOlkGMNZGiX/wBVuDf4
4wgMNK/1bt29svX46b4i/wDzb+vfrv6t/Qv9Xbonvm3tm2Ox/wAHxuaBcnZuU3BNZsbSscmJ8agC
pQ0KKOxIXtis5ffdpoKifYSVjNrbRJmXC/xrFdz6PTjHvnftnf5n/K/0PjomU3tZx/8AV1E32hcW
Sq4zOzajcVk0DhO0jL74bQ2wbd/MmmJa99xv41+XkStlLHlwSfx9SH3xTuCbTp+5HvJH26j79i13
Zjts3PmlZzAyq3PKMkMU45JLtPM2BeqqMSZKZkS1UKi1IF2RjocctyKTfgH6gRbBn7mfGWJ93xXb
h1MVHZpFP22abxZClCf6hPa2hnHkKrUz8PsDLYp+4VoB3eFOlgLAepI5ERJ7/YcIjnpqFiePQMX6
jt9vUAl7saC45dP1Phtu7QYw2EnyCaQGqLJ/wXv+cnz02xG7Zxzjm2I3IzeJ9PJ/A1U3cWnl/h6l
argaeZxgq1HKR/aYN/cZqpvIlP8A6MsaumvXZl27nNoU41mrGch0G307VQVOCPVSiZZQDBxzfdG5
ov8AbMX52Td/+Om/svnObCdqyQFsiW6aTRyfwtQN5QHIqSNP/wDmX8F08ena50CUR3Bp7+c6RaGs
SClsVD8Mjboap/8ANurI8BGWNtJFFUy2ZPimdvI1Au1dopftWYHSYh9PPiZp5vCt1QrmxAaklplW
7lX6rjuMSsYo4GtZCxm6W1E+QtlZihxaC9dOtDpzDWQztm2shseFpmC901CbM1fXOltHfzKtundR
T7KQ5eCakeU1joiO4brBvOGOkNMtqusHWg1ZqtI7aI+1hHK0oZFdLLY82gGsV1reR17KaghrNgSo
LoknTLEbA19LJHgaJlMjyjfdDWVcsdhayWRoNgVDz1679Nuu/p29O/pTrtnv6Nuvx1TouJ02/qfP
9DbE9sRd8TEXHOxy74dM3zSdi2I9x2zA2sDY9MJsWPJv0jFLISUGHFQc2SiPjhrUcSIJsc1wZHD0
8ZUnW5kUCh8mwrmJDFe2jdpBOSv98VcX56Lie+L6EyqdxsopGuDcQ+9liFAEp7tYjxGbLZbQEe3T
Efxm2fFR3DEa/S4k7qq3xb0W7qoHdlV7mpHvmI7FZ3JWnthCuuLkhkSHZskoQIoKJIkzGBYCQx7J
kZJD/pQmjiyRhWUjZOJVha267Y0gj7sqnc1oJpmodstrxjiM78ueyOMF+hiD7Zln2Y4YCSvqMmhj
sjJK4qF4A9wcEZEhxQxll3A46isWnY0Au9KsAgGJ4parAEqrKDFCy0Q1gw4yD7wANu7Jp30MRoTb
ptetEuU0QQ1srtkcVpZulkrxJIk6fijiJYzxCjXJ+6d/yuBCpMFSlen0QmJRkz6ITPoRMWjKjYVa
rZFU5rIuoZA+zR2w0wislJ5IYQl1QPy0mjKNliBuXsxhsqf9Fdky5uhR44C/ULSuKNsbUckbgaev
GY7tykJIixBXUhswjKMr8/TxsqoRaw4LUDxpaxVy1vQiFUGGke7kDSHZqneh/uJRFCKJczAtiTyo
knTF+1jFs47WWOqACmw7YEoW8QS6gv4/AdMeY5NMG3bp0w301ksVnkRTJKtosIP1thraTex0jafu
QsPqe6AsfTV8sAjbiI5tzqKK7K6xiePqCwimhmL/ACdMahbwbKjG6a/kJsGUSOpbGQfIkl8Z+n9T
NeORfQwjstQrZWES5gxob9bEWxNqCHJiWpGFk6RsosVHXcEaTbCI+1iW1aMa3cDJN5BjTdQa05gV
znuCVWrp3VDoTv1JX8NS6uWVmnLmHEh32uPuVurwSI2qrGPJk6b1TGBE1pfhs3AO4C6Z1e0LTaur
Rj1Nqc10bbZP6Hxi9U6r/U32xF9Cdds3/pbdF+U9KYnq3z49Cp7b4/Dri/IXq1abUnjsn3TZGA1K
1BTrBZRI+pmiEDUw0VNXCdn6sDi6k3fM1B3WwrHxDy9Rd5kWw7By6k7jJUt5nOXFxcX536LiLi+h
MEqjLD1fwSTqhDsln8h2Vt8WBknUHl5F1QoENqrvMlSO/ldcugN/WHJkuwdKWJYOgEHrB20u6dLT
vOYaPqt4ck6hJKQhFeSLqA0dP1O9cNdkModSGEn6sIuO1U9yfWStI3VxGYTVLzJKmuPkaS6OUOqD
sSRellYC+kAz9TSVSRbGPjTPaUV9KYkqwPIwMssYg9SymtTVMlUNbGO4N7NCjr+a5JUw0jI1tMBn
1+ftJspUjI8qVFVt7OyRaTD405gl/Uk0WE1JLLj5pXvDfThIuoLJMk3Ek6Mt5YcLOLKxVwLnsdHt
7FjTWM46FVVVV9802wJVC2MjU8Tb+JnOGmc4i4d0VG3cpqP+tTRqS3lmxpyMI2+njQlzMK1XO5ht
Jjc781chEkSpVdskTUcvthnySkc0rmK20mMR9jJIoyvG76pNRX2EsiacPHbgZ8BE+pwMsLGEop89
7iNbKdhUMjmypLc5Sj48atXfbElSExZZ3puqq0jmK6Ydyc1xsg+yyZOQ38TwL2vYP9R1mF1JWcbu
2jneiyn4RpeKOVuOeR6I5yZ+5y753jYrt17xNuT3YP8AupKaKUIKqMFba3HXhtLEtjIzbE3xOWBh
GPj4b46IB5XfS5DhmivEiZu7ZHPXBNXcUApcLWSGI8aiXjnHfGtyPDefPoh3Y6sMJHDVVDVEVJVa
UeO3THrvn9ucs7i4uImL6d/6SerfNv6add+q4n/xJ/SVMdh8+VAnJ1fSuMkqq7Cx6VSilV7gPjUf
dGyk/e3Tv7U097u0/wDcNQ8WCrHOMei4sZDVZP0JeEqC8Sub7u9sXpt6d+qLgk5vrtP9xkmg7TZs
fsu2wENxsfXPGkWIpjxtPbpMo1GhIytNB0/3ENp7g2dB7K1tKshF05xHPq+xkCuWQ4Gnf2y6ThkO
gV6fQGpkqh2yNRq5zdPt2Pp9u1hX9hXDzguccjRHSH12mO4yfSdnIOne4n6dRuSqJNmUyuNH01+y
dQ8UPBVjqigdJSXpxACh1fkSA6ZYjH0o2ZKrxpkLTvdxaJjcPRZF04jsdQjHn0EbkuqtAYQTuXaV
MBF7jqnTSvZPqBRmT2N7kOpdJyVRqJpo6idAB5EirpWK2Xp8aBtonZM75xquRaZh5pfovbi2ilER
HyFz+SuOWQmcXvzx1x0dUxA52d87OKxcooPlSJFIIUWUT6fJTVU0WSbidNQwX472xfhEwYnOzs7Y
0SuzxnKnjPbnYc9XhVMrY/elRqITYl8FojVte6UcemmAhXEPsE7O+JEdixnNwg+OL8JiJvgwuXFh
P3cBzM8XfEhKuLCcmRIjiEq9NDHG1HX+K5QriAdskZy547kzxXZ2ffxX7cOONC5yINW5puslSFEJ
Bst6dssdlVLGe6MqY0XJfFc3KenfPJX0oYgNV1w2s03pxqDlthRxagKAhMRFyLCLJyr04Qx4dVHh
Cl1QJbLyjWO/xXZ2ferrvINU0wYIHyoAyzaoEodfpXlOHEjgZa0YpYryrdAKvRF6b4nq26p0T0fj
ovp/H9LfPnF/+hPVvn5z5x2SOmnoflyY9e2HGupQ1dTuGUMul8hw4TY0YUkfnK1jQDls7gHDNJdG
G5raZrZM+K1seQZsWxrnsmMuqr9soXB702xcVM2zbrvm2/ogr/NgNagL2ejGzSd50GE6QSsqGiFb
oMLNMRfILxSMywMNzWCYe0jR0CGbJYrbN7SEpoiICVJa1LYzFbpmI1RFIgGuKwshiIIKzSOmEC1Q
mnsiO+tGklGjXAtANkvFp9XYTTq4eoUb6OjRuMajG2Y0UwG9sL5ZlmdpHjHBGx0ub4rkYkkdjXtY
ep7bQzv9Wm/bLM5WjmzpvciGkGlRk4xznk+an9s++SErtUyJMiA9xI2oNjGjaf7qSdN8G1NQiSUY
gh2/lmfLgFYtHPDxfHZIFb0+2OY+MTSdnIOU3+HUCfeX2zbG5paG5CmE/wAOzjufNqtLKVq6ZYzJ
unUa2JT8zA0yxW2enVEyupO5jdKo7HaYajbeoWNmnYKoSWFzok+MpJlXpVFGumxJlrQo1kuPweuD
bu6h00kkVzReLlHprvsJppGvTTDXZ+mgIl1RdjKCv5ymDXs3cVzpun6xkfNvbUsEaNpKDz3M07FY
h9OBcy8qViPf8omVdes01fpUMcX0CLllptqZF06JQi00BqTNNDcyophMexnNt/CYYFVUillbpkGL
p+JxJphFkztNhFFqapJVpP06AcZa9Sz67TIGxbul8Y1SJA1966RyhK50SbVimSJ+mG8KrSQxpZ0b
EkVlayuE1ytS8B3isbwZe0Ei1LL0m+G2RGUJK2rJMJU0QYAIqCR9z3ViaeQrYtnGFISRpkLw1+kU
78urj16Dej2H028tj8NGu7dTCkndXcvE/wCQ0Rmf/wAVxU9C/wBLfpv/AFN/Tv6fj/7NuiL0T2xe
jsPn50Gm8ud/p2Sr5elpfEjFRWWz+3Fryq+4GnINoJBLTSnPseSIjXtfk/8A1LpNj6NJvl01O3Zp
98mb4vXfovVM/MT9syB/r6j9mNTmSiqmtDPkpGHYzXldpViI2aiLHuZaiXTjkKcW3ZvZHZdBJ35t
Xt4+oHIPCyVJI09xaO1VEjjludYw15gVBNPJXkGdDeaRWVbY7bS0bHbSD8nJZ2QxtuAnQDxnMBzG
sRd0nM5ZHT7ZHCYbfk1MtBouRP8AFqZ3HNLSiPSw/wBaLMbGlsuhEYJ4ZSuq03E3gMhxNK9eQrsS
vkafo8nTWQAxSlspkUPaYqckCNB2C+2d0Eh9lVscGcLxpGnJxJSWUVnZuEahtGruUn+HUHsZ+b9N
IzXd1fdqsQtuNOAlvDLPcxCMjVqtN8ZJYj49TJd55P2sgSVks1OJqxtLzH+SX+wDELcL+xthqo8O
bN1QOQKcXuk294/s/T3/AJk6GkrIgOwGyMonJjrYY5F/ZgdHpZpEsm+6atcrJWl7eSaYvtl9PkFk
0IkFW7omOkCYmrbMRVX5T50QNqzFxTDblpZAHFojeRDtZD46D90spZI1qz3brGbJ7ulCkbMd7YO+
H5QrEMk83/T03/7Uv3i03jeSxWplk4LI0JUWHZSxx8huR0XU8t8U9cV0uPNcsMcC63u0tIbsCRir
PcNET3w2qe1YOYhmWNW6RaU9OyuDqnU7IA9IucSDYyWxmVclshuqCqGBpac+XAezt5YTSz7sQ0GM
2qHMs/7mtbxS0sRwjwSd6N/yM9OKfGLiZt/S+enz0XEzbFzbPx6tsRP6u3X8f0Pn1L6NvR8Zv7L0
X2RckZ+dFF7c2Q7nGtozmyNL137mPa1lgxDRwxezc8toswxDmq4bgzrBdo1VaO82c/eFcfuPpSOo
W3B0UVj7mJi9F/oNyMv8qtXeLqASua7lHNS3DTjki8hlnAUeaN5I+x3SPc797T/NLMSr4moVXkPl
36ffx9Q77SN+ek1d2LvfhAdxtmL/AB3oRZ7E/jCgtV1oRRNfXFkuoo3jMu2qRn0d5HOAavxmpzsd
TSnSgTiKhEf9k4SOsBftD5LMnI86xk7QNRSkK/S0dyLMbyjy61Xn+grxoYBAG32zfDxnksR/sDPI
19lARGxtVyXK7S3FByCqzGLu1P8Adle4KmC4UqcRGRGw1sJsOGKtBqC/44UyyC6SgPYY3+HULvvu
xflM0gJXSvw5natxvR4m1zlsf7Ua9H59zyDf4a0fC1em6Q4/jt1SdrY+kROfNd75w8e65oQczT75
siVpocYFgHgXtLgxrvpwqLA6Wj+5K+F1a0gjlOZ66bjqWaicc1jG+7pcqDn8kI2VRiVKxzfFuoRp
o4+mFQd9CbHf2+WIFc0gTsyy/vG7TJTns6QcUGmV/gX7+OB/x3J2/WIpULHl045eQa7ha/Oamjqy
boySjJR290NXTLBmS/8AUsjuZa12sYwIl1e/U5OnLoR40ytZNe4g4IHb6gsW8IQOTJwtR1vjOgid
JkVMdYtfeM9hPQg3aec6weRAsrxD31XqltePuvOTSV6yMkuIOwFGiCrxW9i24lVcEddBFPFMdaVy
RJYSIUTtNOdYlegQ1WowypM2qHOeQgqyNqq8S6l/HRem/wDRX175v1XPdM9+nx6vn0fHo+Onz139
C9U6/HVf6e3VVxVw+fGVc5YJqm4ZNDdDYo6YgwBuLpQZAs0PG/YsjyG9hgh81ksGefYtUMGSjbeX
YNWLIf5FlFIKNHurvlhzK/HLi+vbouJgncD1Ng1Y9jwIy3UfIUp8V1FesnCszC40LmCSZPG8F2Vj
l07x5jsGIC9kjflXxdMrpwwjupg3I53KXSnYBlpYiIw8tBTK61aYKEEjpl6xjYNyxzSTAlX6hGYN
btjDNnsM108AGXNowixXM8ursQxg2VwzIN0wrUng3sL9rRgv3MkxrgXG01EnCPN8mXWzgxkJcAcy
ZbMCSLaRnNbaAGlpqXbIGoWEYlqBuWWo0Qf1DnPHqEbY1vP8p9Jb+G5t8FzE1MNcl6hQZIuogEb9
djiS71J5Dam3ABttqbk2TKdIfAIwciruoQGWWpx9qxld8yr0T2XTtzGhJ+rYrh2l61ZVXqwPD9UQ
Uy01gjkqdWphdUxkx2rY5GUknyrFcs9RBhZcXT5hKK8jwmv1pB7dlfdyRW6wCMS6yhJlnqzzEg0a
zcTSTM/SjMaVaZSa6YPCf8gB7cTVrFkJruHwvL1s93zlJbBrl/XcVg7rUTbFY0h8Z9drYccNnrpk
htXqokYrNfRUSXrsbxwY5b4w9JMciaRYiFomwMZq1kDHa/jJlxqklhlPqn6YGx1Qs4ya47ceZYOl
mqtY/Tkl/wDITCsr9WrEO7/kcG1tdpaErVMwsG2mjHEO8472cyHBmH8iQv7sbkOwfFfH/wCQfHHb
aqkWuU2ovpLbbVUmxSq1QWuHb6lW0yDJ8Qof+QkAy01w6wbXa0LCb/8Aou6WetJFijdSHBEO90oq
s2wRlC6Brc0EVnrmTPZVWr6w03WMiYGvtpFY+brQ80NZrCRWov8AyQZuWes5NmyId0UotfyIwrnU
su7RGccVu+dtccm2bf1tvSnTf+gqZ8epOq+jfPz1/H/x/HResj3x2M+YUiQHCTZBEDNmMQ8kh8FO
kjaOwltc20nZ9TnLj50xznypao172kdKlqzuvR6yZbmmVyufjk916/HX8+hMikl7OPP2Or1xUwbn
szyZDkHJOzGHnEQsc233BOGWY/CAkvxWPEozylztSyIUL24wp8YyYTCxn7BjFxsaYiFjyMah0xke
YuPjTEwoyNxxzJnkmxXOXERVUMc78fGOzGwyExlZKw1cfFjKiirjkwleViOEqKKOZ6/Tj8fFe5Q0
pVz6OXCVRG4yse97aMuFpyMxsB7lHQvXHUpGY6vdyDSFej9POx1Q9HD08VyJp4uEoSDwsNUc6Mrc
Vipg2csi0D5CO00VjZMVQq9OvsubImfGe2bJibJm2+IJN+CZpeUCM1s1hmXte56yR8F48s7Kb8ds
4ZwTAu7ZIus/Hb/+hNTF/wCREyy1I6wx+3JU6VtKs3G6PejJdU6OSFpwkln6S2ybQOAw7FYq7YmN
ZyyDSEm5KqlirREkMwTrHg89i3LW9mtSNCfbnZop7m2VMsHIdc6W4WjXok3TTgtkhUBOiZxxqZRy
hQzQ9QwcNM2j6jsDyzq3OPsiZxzhviMwQFdlbpSRKHO0m6OyVDUDuObY1uNYqrV6cLY5O0w+EkDS
ZpjV0Q7HaHIiXFUsBd8buuNEq5U6aPPw+jyiFOrnxXqme+IzfIVe6S8WiCdm4onV2AjOI+t0YWWO
w0cSMyZEdHIvpT07etP6af19sT59C/8Awr8/jEzb3VMcmSUxcjCUhKaj5sn1bQjqKlDCtaftpV0n
MK1KNeKhaovozdy0re6unOQ3UatmkoUbHkw+M6PVMeG0plGhRcVeno2zbPjpv6Gp+6lo2ujzqwIW
WjGI7bK2qdKwtD22Q6/vTIdC1Gz6pjUmQ+Mipo0UcqpY0drCRmUdKhW/RhsFaVrUyorPJMGjY1ku
rYroVE1EfCExx6pr2BqBo/xQBb9OYZt1XdrHRHKroBMdGc3K2sfILW0IhBtqtrMraRiDfGCx5qtC
MbQqskFSILJdawjbCq4PoqJFbLrA9iBDaSaKEELJJYwnHIMz62pG0ZkAxz61hmgpBDeYceO1sQUh
raQfdUAI42NDJxaoPLnEjtBKjSSzIw3AZWtKWZSN4T4DhOh8QmopMU+HjDcG/YjCPT1J0a3BRXlx
tIdcJTEYisUBNLvEZtuFroU4fKQGnKfP08VEPWPDgK4hl+gF2PXOAoakpsSkMriUZWNKFw8X52wf
zpGSMr3Ls3i2bbsG2OMd0A8yZFYcF0LtSHfKJlBRPnliQRQxWlSyWyqGlfLwMlpnaihjdF01OaCb
8rqU3kTKKnHXxLO+BVr5seeDUCtYbpCrSS8/T5kz9NHyVXuj5QRucohUSFc/yZw6GQrGadkEyRRl
Ax4VY+LUmk5IqCRk0tRtk4c44IAHFYBv6DdS0JmNZVFI99EaOyj0++aeDDZHbqBqLApr6K2DK10M
ciGfyo//ACCu2IzfKmjfNyHpVGmEMUCPAuAWTr6kbKC7ThkV9aRCg02fbT9IOIK8vPpDLi2lXGaU
oWEybMFWRoU0VrH1fRMAxyepeqf0Ns2/r7+tMXr+cX+nt/RXp+N/ZF91xckIuy5pwHkTwxGx4t9Y
OV2m7JFXwWSm+OyMGXPX6jGfyiyHlEUVhzlN/tdGY58lv8e8+3I07Y+S+yiIsezFwMT2x3XfFX0p
0Y77lJ/qahM5jZBVc6rrHSiQYTIQrq0YiaZHyklFwDPsOKBf5dhCDtGsZzgrMl+WSiDsCwM6PllY
7rpaP+yYqiY+x/mBL3QGikdK27YLazcN0Jp5rxOSFHOv1AwaBrWGrAokiqR76ipaBqZZt3yMu4TV
73yWpxYiJlu4jWw0VQ3jWhdS2ozpJX+PWrxnPXkKXS954ajxZEX/AAHruclP2tR2+T4flJGD2Auk
Na6ZxkjrIiRh2j1HDmTpJj6WrCCJbzGxowr1Y02JKZLZa1PNs+OoC6RT+W//ABX6fdfi/PXfEzbA
j7r9N0Y2R3hjDyWED2Xg2Mfolfa0/wBGtrvPsgwgx2KAa5dVg+xSQGbeKLa9q2MHSRgmE2MFmHhD
O3UUZoDOzfBr76K/3jf4qj/3C/46v/3if26gXaQq5HbyfpuO2PWTmGIMCOaG0EiWK/OzA5qm9E0O
n1VbFuTve7ZmrV5ShW8mMyQZ53KmMzSBhIvjibgiiMupasaA0lIEM7xoo7NWR7WuUUmGQwImSIg5
Y5NK6RPpaxIMe4rEli09H8aNYxUmiqYqRBWMhsZjWR7CNFqI8cl5LArocRkMOWsdTwpcdRH03p1T
uKYVdH1LbpbzaOifNLBgirAQ7ZthYy2dyNU1TIEma7hFrZwLESUkXyLewFXx4LucOVBjSsk6djFH
TxFhjuYjZoqiI2GPWvtVdF9s36b/ANHbNui/0dv6q5v1T1bddvTvm/8AQTonVccvubF+dJu2uHf6
N63aRS9xsqBv4s/fxS8ktYK7RrSQzaJutt3O3Gj2bDEN/g1D/m0p/vT/APUuv9gny/NvV8+hE/dQ
u3h6ib+1/uSjCNgLIruFkj1JpWS1SGKnjXpd30cpAyob0WPqQ2R5CRZNIVCRtQnRopRfuaWmNKKz
Kg45H+RZ1ze3Hl2o2SP80eVWLIkCjMgBuLVSLppvMduVwRfXjALCtmmMK1GjI5kMyXtwA3gOZcIK
UF3dHlmVrR17+YNTbbaZd96X/rSZbocsepiIlXdJLMsdrka3iku27coTu4NG7Za2HgsgSfKDfvWO
5NUPFlDZLYCvHbQaevSXKK5sKPe27jEGjiv0xWmblnIEGPbSWlNpJF8pf8eoV+8/PnNs44iZxXEb
m2Vyfyaz/S1bz5CmzkZM7z10SuWn+jpf/ae9BtJqWKx57BbBAR2xxjOwuX3vX6S37VqVQwk1eMLL
iz896pm2Jmik/lm/xVSbXZf8de1Uuyf2agX+Ttkb+6i/8uxtQ1bIcps2Pa/7n51LbTBnIchnadT+
e32ywTjcjX9uqYb3yIWmXnZaQvEXbGtzSibTyfFK1UJqVf8Ar9N7rPdmomq2x05/5l5/lH8WNqlV
b1FolkC6u2VbNNzfOjW5HjDSqR0bVRESJpUZWVxntXLjux7AP/IfBtFdfWRW8tY0GA9bC4igaAOu
bspJNDRumEiQw1cfV2rle7/j8qI+dv41GWSaXcmQNdpARll82ePqsJC2Nd/o6tef6lW7+A1yK/UD
isj0PdUGvzIOr/C9Ns3/AKW/q3zbEXF9C9E9fz/ST07dduu3T8enfPjEX3z84uOw+OzT5UBZRpaH
jXcPkumoe+PmsiMbMHKFOh7zYqfw5UZ5Tigdo8hU8PvqO2Uu8O/XeRp+H2H2cxrAWhkKd7sXr84q
e3pbiLstC/8AiXcdSNnR1FlVdLFeI7JQrWvR6aajqOZIT+LeC/fVB7s+H/q6gFyxre7I0+3YF+Pd
ktmz9KB7YrdvITm+PaRJDXRjwlLJGqBjR3DflqJx0Fp9XNhjZDdP2kNZQdxbSCyGxXkcfTbVbHsX
e8eS1Rmr+9J5tjAbdMc9wkmLzHBFcWHmSNNV/Fxm8hSqxrzsqmKldUIA0iUyMgprCISv78lXtjiD
ZCMthGSdkUSRQ3s1JR4FE0uRRBrQ6ku0e3SZ07d7KZ405/3dNViGJImArQXd4p3haso2mKxAvkFQ
Ib4yOO52b4xquwcMj8Svfn09+fTirn00uRoRQnp5iePLhjmvdAiRw3pGd7R4UCCdskWrmMiT1KyS
EVPFa6caNGLHnDkCC8IVtCjJHoQIEFqrfDtWsUggueqVZlz6WVM8B7M0bFQKk9mFljiXAJjJIhwB
BPb2ookaV3LGT9JNgqwzH0ZUbA1hPG7NOSWfSykYed8ZqtGKbfdNHxUcXffNUEQMnT2pEkjfFjyH
TpoYEazK60lpVGVEqTZp6E8M53zswKatvROHo0DO5vmrGsbI0tNY+tv7AfmNmiSPqKUhpcPUMmvb
Mu5FllHfEgPiTgTwzbOPXCi2f160NOj10Ss1YGebUwwFAzi6TptgRwbVGOhRSsj3DJwPH1JJSVZa
TsY4IWrNXKVU+ay0fXlpL8VkEsmPEDa6m+rWUMsWvgt1wF1lYviy4lDfxyNNEiSXSJ8auA/WLiXN
faRrQFndxamPfXxr0+/T5/o7YuJm/p29C5t1X29P59SdV67+pVzfpvm+b4q/0tum+KvWR8Lg3K11
Df8AZybagMKotxR0uLhDspbloBOtwmIC9A0aXMZFlXwkca+Y4RJ+8/8AUI+zMmIeaC9AANpbukKU
m6qirm3VfTv1/NPqYEcR9SRTMs53kq9cqLt0J8rUAZDa+8DGxdVAeOzsvLysmjhkFq4HbtLpJGRz
tFJi6rBGZP1IyUhz8iV+pAxGyNVhkMmTO+Sv1EkVE1VFdkrUaFbD1Q2On6ujLi6xEjTajVSi1gFi
F1eDjPuXS8BJ7Z4ur2R2StUtlJE1P2MTVosl6l7+eeRpgasUbZuonyWilOGaPq1sfF1u16StRd9Y
+rHCxdY8smXhZWQ9RFhJ+sUyTqR8hIlweK9ur1TJOqXEaliRDD1crGydSkk4YjzZAtiQMl3RpeHR
XZCvywhTLk0vF3yOVQEj6tOJsrVMmQw5nGcqZtlDCSaWPUha1KuPn0uPn0oGfSo+ErQMSxnOrs/X
ExmStUypaKVxCRtUTYiF1jOO184rig1bNjtfrWeRJViacsXUEuGhNTTzudfTXIPU9iN0jUdiZHEc
V+nK8ThjgR254sfa5CIQXXcmA92rrMiHmGkLF1FOiNXWNo5G2JrA9PDA0HiRsdGjbXc7xEkTiynB
t5kdrb2exztR2KoaWWT0BPPFz9SWCIeWeUoSlErLezVppEuSunxxWRUSBn8DBCjuP+dTHlDkmeQi
inSI2Ou7B2OKU6hmSAI50o7nzZiNfuucc292YOdKFhCSpOI40fHFkysRhY+GlSiZuqL9UksR1hLJ
ndVuPsJStTPIKxuKuI7bGSyhwk+SVGkVuPmyHtR646dJcgjkEv1KYmFmSCo122ecZiEMU2b9F9/6
O/Vf6C/0tv6e3oROiJ6Px6k6J0TrtiLidF+HdDfDvluQ4jpKuqHhaCuU+SK5QNDXvkYlQRqtonvx
KIiYSnexFpycXwyI9tK7gaK4bm1LnpIhPEjmqnRf6KZ+cg1D5TV04rWSYax8VMGPuYkNW52VV8Wi
cdhKDssPHUboVQ6RjtPuayZBdHWNBcfGadVzJdSocDEV5AUDipIo1FkancXG6b3w1ArMbUuc8WnN
2v05k2uWPj2fu7e+cFTGMV7q+idISTRKBsSkcfGab2aXT/DCVbkJE084jZOnu22REcJ0KsfKc7TP
BiV2542mObP00jcJpvi0en1I9umEahdP8cjadcV36WRqJphHZaUvjICIpiQtLPeO0qfFWtoHS8dp
ftssahQ4KucRxqgokKJUwAub6zT7CDPpdGBs4XZe5vQJyR1HfWDU+u2WJfWKrFsrKU9sGe0EudYC
eWScy9vfFHiDzgu/bXHN6fj+7K+A6SR2mFjxCxNj02nmEZc0DAAkB4E75hO0/Dl2L7apJEDLKXuK
3fOGcM4dG+2NkSUxJElcU0rPuuXtqudrO1nazhitzbGs3xA7uoNNunO/TsVEudO9lDgMJ+5c5F3p
ZU1hIbZHZsqVsxlrWujPXEbg4j35QaaWQv6fibXmnuwkiMrX9rbEHurRrvTUT7AgtNRBiuqztyqP
S42BkafjPFeUboxCNVFXN839W3uub7epV9vnE9G+fHqXp89F9G3o36b9dsXr+XZv69un4/8Ag+On
49f46/jFw+E9ljM7hKKjRB2QxBDp5gSJZVaFFT0/aHMGERIUMThkaBhCgE9WVwlZOofutqmoC5Cg
jVfaIO0qUe2fGUJHpi+lOnz6N80xGG6FZvFHFZykK7tqRaSkUizKoUYUKK2VZxIQgimNE5toJqnp
61rAyEFxu2DVmnK5qsc0TG2rGZRQWmkNAKOyU0RHw4I2MmTRCI2M2QJ7BRnnvQsyEjZY7uO1MSne
VfoLkw9Y4a1NJ33w4jIYrkSOHXRWjFOs+0dgmmElSxTFKOENGtlttaxEdQQxiYdOYmmbGsf1MCOO
v1K2wmE/sLajhL+o3STBYhBHshQcmatRrquT5cbUY0elJSILpbxPImxY7YgWWDDFnwGkFCaBpDwW
GFa1HBVR0YunL0siQv7mahT7z/nI4e66u0wQzV0qm0yg7OaepERSMR476q7WQqR857NIcUPphEaO
gc5/6Y3z9L7NsqdY2Pbtm/vCj98mnKdgcKzusva9Iz9JSHHBPB5MeXptcmQHAfpaM4ItSo5Y44jp
MyHo37T9JNRLWk8XCt2xfkTFetHpZ81P0exMnaXQLYGnEOqaR3eTSbUZG0wpT2emkiNg6U7wLmsS
E+LCdJKPRqJGSq7U+KBsePItiinPG0zDafSQSw088C1+kNw01WyI+wkuix6maSaLU0Njozm8n0NC
+cT6EAYhjaJrrYyWJRNK0ul0kun6aeMkTRydlune5NhQRwQq9FjsiNPdyCdoNPYHkybuMw0Cw/bL
Vf6y5vm+b5v0X+gv9fb0L/Q/G2Ln4/8Am2/ob9V9s23xcPj/AO6p2WfDYg4uoSuQtJNdHl17mnC9
EYO4lK6XVe4J0XjhZ6slxncgYvxqRPuaeO5lkViOiXzfvOxUxU6L6PxidNt00r/oag/sL7uoqlTY
jWQgXNspHaYHyP20WPcSVjZDIsuXXtRI12/xnFlOlH08PjHuf2jsLBVfpcSIk1u4Js9RHrDd8EiE
1SNVGAulIr6emc98iWOuBDctodYwYovLjFwohmLAijCJF3yxHzFC/wAR4wlemyMb8WoO6KuajQ6i
dwbp+zMSQZf49z/lix1kP09T9hLm2bHE2R502sjCZjV/ZqFquJTUyyyorK2LHkNsJfs3oQe8hybo
GO0ckv8AiuDuDKorby0n1zSCuQtYXS3+4nsLUf8Anevv85p7trJhnH2SS/eysGDSjvhyjOXi26tk
lyaKMgIlpbpXLEMkuOXiKb/akWUkrNSxm+PJ/v2yvnOgG0zefUHFf2h39ysgmi/9cxUCMb+43Vgk
AbSsxZQrv/z6Qghz2FQrHTCDzUdmMjTuVzsqR85cIKAiXGpHVh36pEcGnLDypBydoMOR5QOPvdf6
kP8A1dYpufT1UxrcsojEOnxKUKOT3x1ysWy7feyxmeDG07MfNHK48a3htqT2r6KjJOKAAa2NJ1B5
dm7CuD3fyG5UNog+6t1ZJWw9MTGymbZ//SaxrbGTsgYDxulWn/n2P+3tnz029Px1Xpv/AEFxMXpt
/R39Sr6kxcVfQubehfWqdF/pKnpX1behvtm++b473w2P+axeM6ERHxdSCXnWRlkS6kfZjnbyDcRl
ZIqF/jWk/i1RKaSDdsN1uoJrCoQWpXfuohr573IkC+9ylXN8X0/PRvx10iv8C/Tdpm8X6fsg9uWx
ZDbOA5q6cM9k5CKkO/IqkhneGXVPVY2oyKuEIrSaYO58e/I7tyv7tIHeRlm9WxpKq6wrmowFtKO0
0JeYC1qHPIVsEEwh5z9ORHR0t/eOUB2nCSVGe3VrA5TWbbBliTgGNt2raQZJUJVUHJMsyqrapHdr
UZ0zTjHeaVP41yFe5peK0iy3eNFtJLjSI9SQqBiygmhIqR71WrOqAtFH1TMcxYd0SAoNZEeSIVTR
5Ujty1MijjDK+ZMOgI8tizptHStiDvLxkYc6YsoulY7/ACdv2ajX7r8/NeBxS1jigCJrZDLyqajN
NtQU837hSaN3dr/aLqKO6QWtGook4m9q73SujuCupSI2HJ/cXjvnDNFuQZ5De4Gdp9W5pUCiHcrt
CgLvE1kv79EjcgLZnOAGA4s+IpYg2ohhamqBjadv7kblUm0qO5HA1DVlmyWaQ7YNOR0j2MlikBAC
seNzTlZiU0eMnGPrAa86q7kxpX16OkaTfklWUOWySEtUQ0wpWxxAirbWo3dpbaL5MPTxGwlngdJB
VwnQgXJWyiRwirI2qdUuM6iOgJYJTJQ/or3z5cpkUNbBWwsWvUa30BZsKUsisLRS58uW32R8pYly
ZqSo9RUugF1PZhg173d4ip7/AB6Pnpv1Venz1T1L139CdPx616KmJ/8ALvn5X36b9ExfUi+6+jf0
L129G+Li/C4bCf3Ry9o1HdskCso6SB0UdrDTrFIo6q88tLMKGdWrwFKitMZ8YYm+S1A2pUSwhSk8
XURUc6kiI1LO3ZHBYSvII9cXF67+hOm2L8aTko2HPa2Q24jsFgZCxy014kxs4YyDpwIkzus8W+4r
lWHuyq4rRx71w35tzk0KtAG6IN7J+3c0wNI7LCSJ4rMjGSaqzaQJAjMpZ4YgYFm0qSVHIwEeINr5
4I5XHSS1I0ceXMwDG/5Taf4xRWswfbg2rSMcNhVPaCjCXUW0mLLGbJtyKMKTZLNmUoGRsdKHteKL
bTkto3W9u3tlkfyqiXGkBa0OS7kUYU6x786BajHF1DPSQR65SMaQ8WcJA3tmiOqb5shFtY4R3uoV
LmnCCblrqVoQz7F8t0TipaRARmzLoIBXE1Dld75tlJPSEaFZRTCSxABL3UYiNg2ixZkC9EQVrqQL
RVGpRlz6nGKkrUII46ywWyt1+ZloGGlvavtCi0yV2fpZ+P0u9qBOtNIhaiAQVvqcHCouowxX2oQl
bX6ljjjXNmk2TRW0OKCw1DDQEe+SNLjaihFG/UNeFtzqT6oYGmSGb+kHZ+mXgyFbJBz9Q12WerI7
WaTO+bOVdksNSRIbRasf9QZqqEVjdYxmkvryPMYpV35vXG+zqG/dDf8ArGAjbnVDp5KTUUSvj22s
nHNA1mBY9leNJLqtXgaC01pHQVbdODPuNWPmIqbY16plFqR0FV1vBay71IS0LVariQYlnqo0mRF1
qJsa8s2WB9N2wKwv63rdr/UgLEtFq1IgpmvIYxWc4tpKVuIzHJ616L139G/oVM39H56b/wBPfN+m
/tm3Tb+j+c29S4vo+ev46/P9bfExVx3Qqbtf8/mBKfEImpSFCC5eB8i7JJSHYkhr+oj7h1Sdqfqs
uG1ER+LqEzkNLcUjb2QNhpinc29MMcie+Tj993Zvt6NsVPXAs5MRv6omK2TKefHYGQ8D1vZJWx7Y
8bG6knOQ8k58FILFe3Uc5qGsZMpv7muHezhI60nSml5vwFrKAi3c8yEUr8DIPHVttZbFmzDIKfIH
jbeyxbSxVDyZDlbcTB46+nOR8p5lRyooZs5MdMmvaw0hqslWSYYs4uPa7cRpTcK2WXHNc1w5ktqN
kz9nlO/BxzLjo8t+OgFxBHYrBz9iAl7dl2MiyVR8A2xYzm5+5mJJkIjXmLgoMhVMyWPH7rm724vc
fnHbET3jxJD0dVy1Q0ZWL8YvRvNudwme64JiqoqqS5poJQYqLm70z92+kxtDhJY2M1CZpTVFgCG8
Gra5jf1nXJkzV0AjLOwSWT8Jg2qqxqYx0Np8oWsjuc5unjkRdOlbh4qgV7c4ImVM1sI0bWMJjU1W
LgXWcdUlBLbL+lT7EoiR80w4UIala9l1SPe98ftrFpCS8XTJWpIrnxsVPfbEbkeK4+Jpg6tk1r42
OFsqt2TZMjx3GUemTExdNGYn0knJNMnVkuC6Kq9OO+MTAxVI8OnJBWTKUgccPhm2cETIde+U9mlZ
L0/SZ8kaeNHQNa8xF0vJRsyvfGxzdui9U9C9F+fWubehcX0Kn9BUzbpvtm3r/PXb1pi/0V9G39Tf
PjFzbq5OhMKnuzKuudIc6gRgodX3DTaLtjrq1TkJR9vItD3GrRI1TUCbD0/uk6mcF0Wi5js63xnw
ahDMn06iQwVZiptjuif0Uygp/METTzBstYTQK5PeNFcZyUj0R8Ties09zZJoWsZZV/juqKTyEdp9
rRWdX28qqzynh03xZY1CMaCD3ZMHTn7JtK1mQtP9xXUjBIalZxbR8jDoxia6oE5tpVdtHh3XxXbd
nZAxnEdT6a7rLKkaAdVQ93HUoh4amY5pqX78DTrWMnU7VyyrFG6kollEJp8bA+A0tjEpQDEaABiy
wCYlbSMPhKwA8JUNI0WneRUq44WLWCNl1U9rCQ3OcsJ6ZWREcaBVC7OoKxB4aPwWrqUmZJ081g5c
NROjsTvU0UHF9aJRX0dBlf8AP5RN8FFc/ErX7PhuGlIMZJMGCHsanhsC/tcnNryPxa4jc+8JWlsH
4SLIXHAVF8Fzk+mOwkHt49uKmN9srVYkimAHxb/gyFpmrYbCePHaFI8tmp6tgkN87e4mcl05phJG
Oqozg2tR4xKMYfFIVrGkihktuhrAladcwoLVzWwYFettYRoQYAGzoRSakgMYMg9ysryq1IjlLp+h
HHDyGi21MyWKXVkYR8RzcFAIRdNVwhlk2kKEkGdHshWEUUco9uGq65yEMHjiNwYldkKgIYdDpxrM
eYUfJ9cOcO0pngMWCQaDhEK7SQmRTyrONDZW3se2dZh8mJU0w4aeWJS3lCySOxj9kqpi9Nuq5v1V
MX0b/wBH59Kf09/SmL8qvp9//m+PX+dvSie6dF6EwvyBN3abqkaC4mpFHSzUSR2Elih06RVuJiRc
pz90U072PfYJxiqjhyoLJOBjNGzUw+OU1tup4aHDdRO0QiYvRc/Hr5e2i/8AQvJTxtnyXkfHAsh9
LTIxtkcEYUNPKtooeEebO45ZnbJfRx2oCXL7OWs1r26VjfamGdHSzntVNPs70gn2BTbFMgEY4do+
S58Rq9iysWQ1fbSZjqlrxAuCtO+Np7uItCxEmVCNylovdjEG20TePAREFZMO80disC0LOdnIcAVc
R0kN5GY1lLLCxHLsMf8A6rF3DZQpByeBIGSv/wBeyilMYDOAkXfLMDzirwuAC3F31j6eG1q0IdrK
l8fKv/VlxGyW29OrMrrJa8oDjmDtKjlkyMoSaac7zhryFqRNyE+cq4flHr9NCCF9MJuWtSxrP8U2
ocqwdXJ+7Tun0ktSojohaYL0m1CMmwKcaCk0YisSob5gqUL2JUx0S5o2NFNEg3riYP8Au0x/5uqV
2i6YTav1V7xNLf8Am6p/1D/O2achpMmMGgRskndKkhacVA3tpIjtksVzY4tUT0lTNFf6uof/ADtH
IisvCKOuHPNCkTdQEnNpKR8ojKqOyPIqFj2LfZsqMVZqfDYoHlnacZJWNUR4gb6YkeTVU62I6yvb
XA1GTYUb2jnjsksvqLx3OFsTTmm1M4qhhRwOQgbuE6XIie0UqAWZY0Q5aVtEGCPVUkEQgWyLF2mq
da5kmcMRV9sHXkZZv926l/8AQX074ubdNsX+gv8AX/Po36belOu+fnfN+n56r136/lcRPSvVc+fS
nz6V6J19t3YX4IvuBfu0n+tqZPYBFZIoDqQXwmoXuV+nF3jze327Uru7Vu/jrOGj0XfNU++V/wDv
A/1NR+zy/Lm4v9L8aJd/19//AGyvYmmoLXpJf2A2p3vNp1w/IjqnY1EbisEqJLqHIsfUREZhDq6R
pszHCt3tSNZlcptKSB7yHIgLgyrIo2v7U2UACgL3RXENxnVFS2MO5t0CyhVZh5L1ix3ajch2WopE
iLJEwIioTJiIoITeLJ88UbAF74mptlhx7VYRrh6h/wBeiX/sV/15pvEmg1SNGRb+PKN4rCsCLtMn
2QoahJ3RNZxWZMbCHBmNmD4pviyhtddWI1HUrvFNJ7RZMdDCuhcTaZSVzlIxka8M1x9M+80SbD1L
/ldnxmj2IpzfsDMupMSVKvnymDdzlVH+lqz2LUN2gkMwKPt4rcENLSYiNExMvnKy0jrvHsLjwplv
qMRI0w3eKuImDzS//m6s/wBXTP8A5uq/9XS6bV2rP9My/vRPfRy/9g75+oxlM7+2j/utJjoEW01P
Klqi83aK/wBXUP8A5+j1+3fJvA8V5ZRKZ8RtFZQhpy+3aW0Xvt/tl2KJMT5ly3jtozGkW/K8UFsc
hDRLawgJp2wNYxtQsRQxl3jskP8AqtmNCQafT6yZZTArY1pqF9pYV/vCtbDxTRF5RdTyFZPrtyx7
Z/jxJqPJL0hVjcK4sUq4VHZPsrYnwy0c+eT2ZqR/Kwd1diJi+tcRevx/RT5XNs26b5t/R/H9HbNv
UvXb0Jm/9Bc267dPj1L03xPlVz5x2GT2Jg/Z1DLR8W9j99tbC5TK5jYgmTBly/h9xmnW8A3Ck3bW
vI2CzthuZTgHq5Klj6lVNqiG58hCoGLqIyPKRfdVxUzf39W3RPjRH/n3bO4ybHcx9XdeG8J2yhWd
cjsro7h2kf3h6iReSNV5qFv8fUDFyS392jxduLet3HPaqE0kP7k5P4lo3hKqDJ2biMshaxnajtGw
xLLdsdtOWatbXJBJOdzC+ldINJpkiMJYygu0oYxR2ar2IRk7VtDWUWELsR/qQu5K/lpBjeELUVm0
i6fgu8tW/ts67uHDRsVsGj7MxzkCMckZEtIbpZ47OyBsob1tg+WKrirGjrKYj5S8wtoTHJYwEiJT
LvGNH7p5ZkBH8ZbOdGECqjag1Crsc5Tl01VL3v7W6iKilcub5pM6Nkd5DhdptJUm0qRQ44g87CAz
tw9UtRcppTVj2sD6i4GnBgHXkaAktiHaNURLYCGsRt4D1gBr1IPZWhcq+M/PGdkeKriUQexW6jaj
oWmpjEj2MJJw6+GkKPqyxZx7KvVIzkXSwnR58kiCDBKi35iI0dQLtiumo6vntRhRN5LpSP2YFwxH
waq4SukjeOyBHoo4CaplBGIEvsSCa6+wyxc+bSX45oVgBee4uBVwaCIkos20ixFKoZ8SHDjimnoY
5kgwGwB6ntBbwXdyH4re/aTQhG+fHr4uoNSEtzAXtu03qVpGPhikraWoaoFOxt5JnWUeuZHlgso+
qK9Ir9GlR8PWkho4lZL8QtLessxNgiGTU2qw1oDFdIIrc2XNtsXPjqq+vb+tvi4nTfr+Pj1bepc2
zbqvXb+tv6/jovqTo7EXHfH45YT9yF+WrlBdPjuScI4IRhsmzrZjQVds7vSLAJGwJrAoSSIrzzgj
Ey2ajL2ahVq7Ro41/NadtMQQQW183hKkqVV98X29HzidFxOqZpO1ZFAW0AZlxKY/H/NRcOiKW2jv
FBkhWUK+C0NzZtLkJzWzIF5HAO3uBGR7tz1VxFiDsb8Jhzz90lFYRooz6iAUVrMbIdU3yDRt3Dfk
rUjGir9SMGv6kikxupo4sn6lR5I+poqp+pIo8ttReUnc5Fq9QRYjZupgnZE1GjHN1LDVJeqRqMlq
byYGqAtbP1YwrXTFJIh6iiR0/WUZzbDUgnrE1aFifqyJtYao7yQNTePjNYw8maxGRsfUZAHDrONx
kaxC5r78/fj6yBxfrSOjbG+fPWu1c2Ix2to6pY6mfLyvvmwGz9TrJQxnFUT+0WDrAAWy9boYcyW6
S5U6AkOjlg60SK1dfBXJ+ojT0r5/gmDr5omWeqPqOV+oTQFZr5rcl63UyCu5ApLdb7NTWj0X9XOU
jNevYOxvi2OQYzpR4NCPtN0+LC0IUS1RsEo9dGjJP1gWeyFalglHr+QNsjXUiQ2mivuJQaAG36fB
hqwcJLfURm5HklAYuqpTmi1vLjpL1nLlsKRTkERRvjaymxWSdYTZjFe4pIOoJlc0msp5UlyCzHo1
c7eKxUyLMLEd+srDhJlyZbw6nnRAyrA098bUcyIxbWUSSPWk9jTawsTNLJIQ8bV8+G12t7NyGsZM
o57GTMTtZxXByCheHV9kNkyxk2Lod3Kgjm2EqyWLbTa5JtrLsMh3UuAky1lWSs9sjTTxHP1RZlaf
uSH9vO3vjhqmOTovpXN/QmfnFX0fn+nv02xPQvoTNvSub+nf1bYnq39S4np3zbpt0T5z4z4xejv7
Sp7/AJjsVyjjSeKNKrnRTogxPcqxZOCiynYkOXjocrEiSVwoCtxkQr8KAo1ZHKTDRiNxyYuL0TPn
pv1Tpvie+R4anxtKfYkN4MdnHdWhXZWKmR4Di59IK1Dx3CwEJx1HSF2PDePGxuTg0pCYereJFBus
emIZHUjx4yvc/B0C7Oo1Zjq5eQqBSY7Tzkw9a6Pjxe7hpsnw1OWRqxZGOoXBYKscRzNNK7H0CsQ0
FzHxqMknC6eUOHjqNQw+8rdOvex9b2iRtOvMjtL4TTysbLj9peGbbYiYCH3ljaaI4c6B4z48J0h4
NLuVkqlUKw9POk5+l+OStPdpr4TuT657UILirGclr6FZDf0rsyygLGI5OoA9x1ZplTNtKHw2OF+6
q046ayzqUiYrc44rc2xExB75AgLJJG0pyHbVviuER4CQLqzM4EWwIO2n2MF0uaeU7OKpit6JkOdI
iOpZFjPxKqXwtizAkrtLElD/AEkxFsdMdlkoPbXE91YPKbTRJqWdG6KtNT+WQekgcX6THlxRrEyn
qfNOzSAVZeVKQXVFGSxI3R40bYaV7YpkdQP25LwyPGeYlZpHkGdpVGinQHAeqb4g8BGUzqrSPcF+
kw5a6W7Q5gFA9vy0fvDrnSXwdHt7VlpVGDmQ3BercRmRIanJW6PR4v0hHyz0r2WQKJ8yQLRoGjvd
M+I2SLtuXF/qrm2/Rf6u/pTqmfPp36b+vboub4vVc32/oJ1VP6W3o+M29l+HYX5TKCoWQ5atggAj
jdYyKpixoFM7zJFUwY66uGXD1oRYSAJWRqhj0tKFFbWUiIzUVe0CU4BObOqUIOdB7D3t2xc4+jbP
jPnqiZtmj4TJQjwRAHdHYquZydX1rpD0080YZUVvl09MxoZEMSMu4rWt0/UoVjoQWMtog0ShrkkF
ZXhAyyjMVsSCh50KrEEU2MNcgVA+UtY8VrI7JQyVwxkdJhRmRO1My7gNY1a95H/RiYWuePINa8xa
ilHEFaRmeNT1rGpOlAiYII5Qz0iFkDjBhCeMUlLio4Jp6pa7HAGrDCRbaKNogWNyAD5t+F7SIswj
KIjkPTvCg4rnO07RI1m2alGjJmlq5io5WtbIaI5ADaAS3IyzTRWFGKGFZJ61jxWdW4T9lEWlvxOI
39zNTsRDP+cRu+VcUqmqwqKLqZu8RGdyXSp24upt+UWE6SQeln7E005GkrVQkbTTysLptwkrnur5
Ud28e/qlkrNgOA6okLElQn92Jq9vEsKqLNKzSBFQ+mFG2bEWO53RibZpGeTvL+3Ed515twaLUBiW
RmI8d61GSXJjEzTNF5qtQcUcuIyaMQSVdj+YxiFLqJrVhafsHhnfK3xCTbSsgshRb3VP0w0a9FLi
3RWkkVOnXWeTtPvhJpKrG/J0xsEFbP8APHe1DDZI0w5rItIWRIi0Hgm+G/U7F1q5vJuo28ZoI7nk
p9LdwVZTiiOt7NKwFbN+oRbujGckrS7gshafLLLBofp8oi7NjWFkS3e3m2NDHFyyvfBlqNkwGrYb
Ycl+bdNuiZv619/Uub9Pz0X1L0TonTb17f0vx/R29KYuJ1Xqvq2xOvzm2O+C+yp86RjM8bUZXBZH
nOBJqCpLE2MNi6lmdlumCK8M+O4qS5ixR1Ju/H+cREbmqU2SJLfHkwWpIj6kCjFMm2Ozf0behOif
OhP9W7/xWCqha2GssldVsiDubhApXfyrCEPaLbHdGdKlrOJp8XAFwqgyxtFI/S8fbLFq9m0s3MzT
rFLJKzcVrYLHylm90VlA8rIIkAC+lEasSIawJEAOsjSZq2UmJTiEMjI/KbEG/KerYFqZObyjVq/s
nQWyFjjQIme+WYlNHpw9oF4n8Wpu3+YjtxmXa3BJYoJFeI75VG3jX17WGBEY1k+tGUVRVMfKRvFM
1HE5HoRIGHY+0V1t2Z0WyacMaKxD5cGdHnUtw2U2ZW98dzEQL6D/ANAHuLU/+Yie+V8RZJKWmHAj
Me1+ak/0a44wza3i6Jq4bWu0xGEJCFaNhJAlGX7ljDAgxOY0iXMZoLKH/qOVrsuqlrx9vtT67/R1
anM+n4TYkHNuWarYNkhy4i4maPX/ALIv9sH/AN4n9sT3vn/Gof8Aa3yP+5+nGolXOhJOGAKAFb/7
mHmgipqfU6SMof8Aebk3/wB0fxqpf5KPKmUtX5pqyE2FHnw2yxUkdIw5g2mbWtaxttI8UNfNZZRw
RWR81NqVIr6rUoJIRT4RX/i+E49jp7TbRpa2oqqPRylmxJw2Fyua1obqf9OSHKZYxRRmRk1LqrtS
KzVMeQEFjBOTpNjiIQH+PXa/zndN8367elfSvoXE9K+pM+MXp+fV79V9Xx0367+hUxc+M36pnz6d
/wCh79N8+PRvhfg3ymaRfvD1Q1VYjOT9MiexmakA9y6U9gTJXYbZEWXlA1Wgn2axCRJSSh6qX2H7
yan/AF9TO2aZfTv6fjonzob/AFrr/FY+5dLlEPDv7obaG7lUyVhz4Bf42pJG+eQoT6dkd6PqE/7J
L9yaWmuMO2N249oRVJpaW7vlIrYt8Xc2ngtaC6syxmVBlkgsYHkPiw2Vwbiyed2nwOZIme0SYUoZ
TJ0nnH1SATau3BYLJdwBA27d7YFi5VmceMmTj9odQRSM1AVGRqhd7NntHuUI2SKTYbQbGb5Y05BH
EGNzpLGEL/iJdNrDR9YgMUb+4PVUrZ+mDPLHu3K2FMVeYJssS0MmwkSiP7Q7d/kS9N0PHLSzFCDa
zkkl081XTwN4i1Ov3nfOaTTeSReIKjlx1J7xNtpNMm1fq1vLKB0kRQSmlSXB7rKeAgZEqR4zBu5t
1E3+fCX+IrHfVJm3iH/fZQE4wtVsXyKxd4NtbGgK20spTLphXFVN8441uaQH/PL7shtVl6/+2HEJ
9bIuzL56OlccCzZ2nv8Ay9QW5aodVLdOhW6bzM1Sx/k5p1ivmN9sskUVzHIjxagqCyJNdpRGRpko
1IbTty+fH1HqH6cLSdisoVowjwU8YscOqpPEGmYDolecvdbqGteKW2AY2acoSJLOVBDqqtsmTcXA
aeNZWxraTpOU0kG6EYgqmMSNF1YVD5p+I6HXmVSJfVLwTA15TZpiiIOTJM0AocpksNpAlnsAp2Aa
ymNk2C58+jff0fPoXEXPlM29e3VfQuJ/VXFXN/6KZt77dd+q+rf1r69839+m+2EX2P8AKLmlbZow
zUSYMNfxsYpGxYw9QtLJsEbJFRiQC2gu9g6xGjhOaFup3orNNyf4+pS8m1EPyC+U2EC7npIe9d8d
/QReidNDFRgpuxx20HtqhnxyUl82SyWBpmeFtZQdmxb8aLnHuSNPIggXqc0ltTuaVB2mW/FwrfZp
NLA2MdzfG1A1N9PWKdiUBJeRO3DCCewpZioYcWoEql7EArpKSBtrQvNZtBEFNchDaRjtipYlb48G
wamSQMlKMwYoJOpEFLFJZLa+THgiublZhqSuRheTVSyYBr4gRPGOEJhZdkGMGDdskteYbSmmjcK+
c1V0/HQ8gRWIK/c05aFrY0a5OxI9g5O7TVTVSKONCbfaiajaIaS5My8FCBbW6zCC/eXT9c2Ph5ow
Dv5jTyHe+JlJPSFIh2bZIG2AQLcTWEBFYyVYQijbG1LLZ26KdFI1rBqsizFFZH1IHzlmDMMduFVv
pTXkq5onxnHEzNQahCwFPwlTgyRKHU80bk09qEJx8wSMmWkWIGc91tJZpqQ7E0ydMJQkFmlUHFe6
dHa2xthxrCtuQygd2IxbzUoo4WVMmzJ+l5GfpqS3KqS2BD1dcMkO07bgHAW0jGnrZxGpqmaIx0TN
JvAMq2kTbVE8RD6f1MoXNtYT23GqYsSPOnusDNmHEjzFMtdZkhEq9QgkBs9TxYga60bNsZuq40WP
S6ydIkX9nElR9PnhINbqujjvtUPmnBqoUSstbI1rJaq5V2hIJq/U0QobfV0aMGisxkn2ur40cFFr
FXu1HcwJQNN2VcOI/UNaFmo9TEtTaeviVpG6nr+3qnWSHYqKqrnx12xOm3RPQubdd826L0Xoq/1V
6/jbETr8+j5zfombbdPzv1Tr+PV+On5zb+hvm2IvVej8N0iHeB8XVDGMdeI45tTo4IZ/blLqpvCP
qwYc/V4lwurWq1NTtallarNHAvvBHPuVmpX3n09k2+dNaUiuxUxfRvie+J6UyqtH1it1oqpNtlmK
Rd8ARQkZqkjBBuXiOmsStbLvSTcaRRmDq8ocl6kLNQjuSx9THjMJqs0hpjeSsO6NXtXV8hzZUx8h
Y80sVwtVS0SRqKQdgLiRGVuq5jUXVcxUkXJ5WM1LMjJ+sZvGRbyJS8t1jX0yO12o55msnyAvbqSw
Gh7ydIQiuJkezlxsPaTD45zuYb6cFqaksVw1xMk5HspoM+u2ioWTMkYEkiJi2diREnzkaVTGULZU
dUs7NMMeWVw7Ce1CybE6OGTBzJgUdMszIQRsFIPHw8o58VvFG75HlTW48tk9pWPz4zfExk+SHHWM
lyvnSX40rmq2zmNwksxMYV7M86WmOkSCY1Vxp5OcJDcc8ir5J0Ty5O3uuIqpiSZCY55CYjnNcsk+
Kcr803PgRxMvatEW/rUy1vIRBGjSiEKM7HOxivRzI0s2NAoD1t9VCAmp6jF1VU5f3sWTj38s5Lnv
siuXOC57pi5s/ET3XE55xzbbptjGYOvPIx1SUSEFtjhpvjRryHWkk4tEfYlcUKPHxXEbjWKuMqCl
x9U8KPHnDNsYL9460p8+hSMJXEFiBV7vohnIetdHx3ti9Fz4/pb9V9C4mb9Vzbb179FxOqf1Pn07
e/X56/nNum/RMX0r0XPjoubZt15Yi+zkxW472af5+chR+66Jp/kMtXwkLQcgtrl8hNP/AGo9FyV+
nEbi6e/a2h3yZRqJsOmUyTahY6Qq7yllUSjQ8fhm2O6fnomL6EXEymgLNIPTOw7GrQCPZ7sGqqKr
e9poqiWqp3Scdpv7c+t7GV9Y6U4emv2WFL2sjQlOaLpzkkyiQeOi/frtOuMyTp5BtDRKQrNOI1hK
FvEtIvdjacRG/p9i5ZUvaaQXFVEqZxXBjXKfT75uS9OJHDApHSjJpto2Eom5OplGWu0yr2SdPtYy
wreytdVOlmHpVohSq3jMr9Ns7b6QbXO0+Lg3T/dkLRCG19Ex6A01uT6CFrWUgnZYUbUSLptjWOpR
Jk+h/bWaaYgn0wm5L0+jhLTqsg+n+DJcRRKNn7qaoZwSjCrL6IgCuzbEzfPn0JjE5Y0CuxI7sQK8
tPacSVl/VIDDDVFQKriRnLjozkxIzt/Gdixnpj2KmOTEwQO6unNLDcPUVQwBaOIJ0plcDjqGF2pL
47mrDF3JNbUx2QtRDaMyC5q2C7Z8Fw1ViJi41MRN8FFe7FgFxwHIjYzlzxH46K5MSM7HAVMWO7O3
7oBXZ46plJTvsDw6sEMMitjyh3dKsYhIjkxAZW17pEiDUhhBWRA71hUBkhtA+MZGb5FrCysp9NvO
WPCBDFOqwzRW9K6OR0ZzcUarlZBUkmHCiwYw7KuOW0pwyA02nEV/aANLygZKFaQliP2xei9Fxc39
S9ds2zbrt/Q39W2fGb+n46Jm+LidF9X5xMX0J0X0fj07+n8575t1RdsXoqbq/D/O3vo+p8lskTIA
Cz2ksIvCRGbQ/wAqajIwKeSw5JzkEwcxnbg9siSIjJDIVYkXNShRg6me2KRgWyw3tf2VKnHF67+h
OqZ8ZoVN3TzdgFxYKYqtUi01M4yuighhsHpJmUkRBx5UxEy7Ox49LxU7cyR2Ms5bFbpuMhTnd4zJ
0xitiDbJtQD8ePKnMys7b8uJhhNquRgWLxxXH1I9VoyGkJekYjY9G6Rn6bRqS6bg2no3GLEitiBn
JvFqRo1luY7Ereax3w2ELLN4keDL85LuA3s0XZAqZdv7U79X8Bw72ZOltXiKz1CyI9LGwmErkeke
0tkr3zNSSZC6ZfILEt57IY5GpiGXT4ZK5LnDErSIo+1IJP23w0xsGeF45Q7ao5pLjKF9JKKkwH+L
VP8AnInv029LE5Zp2gWwc3TgGtNp9nAdIjZUUSBBOjtMGdCR82v0wIAloAZP06m0Oga4Y9Oibk3T
rHjtYnjkdiJmmKpC5HEmWYGFjrsyzH/ikVY5BLmhQQ6ev7k0ItgalAo5OntOsIL6LHyfQiUNtGaA
vvjG5p6lWyOGiijG6kAuS6UbJf0AJBjogMbO08x2DoI6AgUrC2V3SAZE7CmPp3T7e3d0bGi0lH7M
S37ix6VpGiso7D5J0+Ewa/SqIWXABAc0iGGPT/8APX3TUDf59VUEnGgVQa8MNRubeiKcNM0jYdjH
Gc8zTwjBrNLtGTUMMFeJk6fYP0/p9kJlxcDhZHT7NrGkHsAboPXOzJruu+bdPnNtunx029KYub9F
6/PROq9d/X+c/Hp26fjp+fQufHoTrv8A0F/oL6UxF36kTdD/ACnvmgf9HUn+F5F56XldzpqUqtbp
b3w7Ee23Xss0yZzwPOweNcjs1L/hOqo/Ty8o+pm7JIx3y7rvnz0Tp858Yi++h02Jaf61p7HooflF
ABsEN5YEetaiGl12yR9RvQOOkOJK07xaC7VGgsJLu7pbhk3bxrmSqE00rHlRUc3UB+BNNOe4cztI
2IVvbvRuJlPSKV0yaOujxpS2U8bUjRZGomDkmswFytcJg2vR2FbyHXps6UYQWxytIxqe8pqOFV8W
5cf6cMjm2wF3DqP/ACxo6yC0VI2OO+u0jMLK70mBZQhshmaYOqBLlFTLMKYo62NbWjp5tPaf9rOy
ZXhm3BCyoGqBIOJqGIYrc1Eu8igmn7hAtWPfPZ3qP/fj/wCHVHtKL8ridNs2zbOON9l0zbh2eRxB
ypBQBnW5Blojvk1+pZZYsbTCLKmmXiOpspMixkJ9mnepI1nIeDGfGp0RspUz3yunSAPq3KSv1bIM
JIaP80X+JkznYWnvXhMo7IHuHVjuE+gvhmSQJTJaHkRBWJiSHbe40XfQ7U7F4RwoEXUEiG990aaa
D/pEK761ifNX/wCpdf8AnUb47ZsMgnhlmCIVKYZx2EhIrKqUktmpSqGFpyc+ZCMNok1LPkSpsDVR
4A6vWEifJf7NNVutbSvrxVodT6qRq6X/APLtJzYKVUjyo2rjKENBKfLrZTUjpZrIt7aioWQWah1E
yqDEeaXZB9wzrdoJMdeQ9cOR1gq4vTbp+eiL1TE9H46/ObZtiYq/1fnqvXfr+P6CdF9+qerfp8+n
fr8dN/T8dG9N83x3wf5zQchEiXid8R4vCVpuEgmqViLdx0OzTwlE+zIoxKMkzKWN47NQEcJunrFZ
I9Su/YwanLSJ2AamM1WFdvjsX36/n07dNEL96xTlGtY7kLUWroDos1k0NnW88fHeKTSb+NqPluZP
36QRUjahReM7dCaP5I6238a1b93TyL57d/Dvmu72mHJ2NQI4rNOicMEmOkkhUSLGkRjTi1lSsOQV
f4tjWvkyPoCgYW5lQV0xay5pZbuIK1+478TpKUwVDGfLYN8t/eZVxXAzUE5oxVkVxLIbe2y+hueT
TwtrBy9sF2blJrqhJGG0+m9WHsRNVyW76fRPH1YdWppwCSJLvtjkVMieaVpxsYP0nyn0em1CabMZ
ECfezm09UKsjag1CgmyJLpJtP1ZCSht4Jqp+8h67qvviJtiN5Z2lztLjRLnbwYuTqKnTcbSiVRoZ
uoxsEbTUhvhzq9J2Bisr5hdihralY82eZARdPv5xpMbyMVyDZqKQhpPDGj9gN4lpDNfBlVw5pJdc
1k9ibNhmR93cO4V0ISyLdjeDNWRUdJp6VvbAIoSmGwgb3iknhiM45oyQ0TJ8bygQtJiES9gChOgf
6Sw0WXJOkYYDNMyLE7Eu1Z3Idg3sFoNUjqxah1Olsmk70UNDBHYx40YdeC2sG3EuDEZWxAzwSnao
qEYlZp3z0qNPDr1urgdeKoGIETVeruOM/wAml9QDE2XCFZCa0VdGkS01HZhGOviR5oLBpKtka0Xf
F0qhpsmojDjU94KThqcJpNtbgpYtrZLayuu+bdN//iXNui++fj+pt6E9O2bdNvQvXbr+E/qberf2
6IvTfZVXHLh/nKG3WA+HYsmgsGDSZHmDBDkXT0sEnsfHr3sQsg7To3shYGexFv56EHpuYgx31gwg
qJiFJKtRRA2Vksh71xV6b5tm3Rc2674maVkpGkJNGcF04SYVfuVlw+EQViKTHe8Rp8CwEEN1NY7H
qjpdNJFGFb2QyNmv5l08YIBTLYTwXElCv025g3/WAIG5msKtFc9hzJwCo+4FEDGv0fIW5AVobSMJ
bTUI0WHdiMxLOMPLnULHpLkdx2n7CNDZLv4xRR79oysuYj0PqMQGTrorz12oxqyZqpvbm2DpRKqy
hAb+p4W1pdRiJXz2x5krVInBmye+Wl1B2Gs1HAdkrVYBjsrJZj6zUoogbe3SctLYJXvZq+I9rNWw
GLa6sGcdddwwIuroomW16+wyksgV62Wre808l53tXZ9XqSFEZJ1xHcKwsFmPXpFAsksDTI1Z+mGJ
n6WbiaWHv+lBYumBtxxfo+frmI3JOuxOZYWD5pKi+dX4uvBduZqOTJkQtcDANP8AkKPtYamLZv02
JR102WkIFvqwkvKyi8tG6WHn6WHltUDiigajWpeTX24g6jeKWX/kFHii6nfGl2WsnzxU9ytW9v8A
yIiNttSrZrVapNWon/IeyT9aHnNpaVZuM0qJM/Sw8mV30rP16sXCf8hke1J0i3nxGduJe3j6htvq
CTaLW6qPWDk63OdF1oZRyjvkm4741vuJXMdC1hJrxTtXS7FlbYFrizdTy5w6+zPVEsNWyprK7Vsi
sYb/AJDluYaxNYHdfynx3D3dwxCKNYmtpUAdjqyZatq7ctQ6dqWZZMrrc9U+Tq6ZJxmvZw0//QJu
TNcz5Yos40Q3/wCgz2CtLc9w/FTPj0bYvTb17dN8+M+V/wDg/PrTp85t6k6fKJi+jf07b5+ei+vb
pt029HxifLvfovwfoH+6KaWxrySMR0xzf3q5CS1a0kxcQlhnOe7N5S4Tv7CQ2G8jGKbZ7ZKo9rsV
MVOm39FFwKOfjYUxcIA7Mf8AKe2blzk/BMOXEgSVaSO4aoMrsHBkPQ0J487a8mQTEwkAjMc12Bhm
Kv0oyZ4bubKYj8WmKiPhObgaw78WmLhq9wcczfNs90zbfBRPIz6MRrfEe5R0RXItC9uGhOGoqwkh
VoHMw0VRKgeTg0RCsNA8d0emJIz9NvxNPkRC1ZEezTj3IunnNxKcjnJpp6t/Tb0SVRqBixOT4umy
HYajdFyPp0sjP0u5uO084eSYnbIsJ6Y8apiN3dCpHzMXSruE6vWK5ydIUx8EwddEGia+Iufr465+
vz4mvpC4/XUlcn3x5+O984YqY5Ns5b5+UTEbkJ7RHgangRwW+poskZ3cnxdUzYjF1zY5+ubLJeoZ
ljkCC6WUWjt2WUDxXu9s+emyrnFcRMaPksPTjzDkR1C6LqGbBams7TF1na7zNQ2E1OKuxU2ypnCh
HZrqE1l3qQdlmyvWvqyzCM0ZlpSPhuKLivDEblHp5bLF0W3Z2kGpj9O7nboxNnaORcstOeGMv96J
uqMyvrHyiC0V+y106+FhRcVVmIzKKlW0emiGtz9FouWWlFhMrNPusiP0Psy0qXQ3Ebtir6dsXpv6
fxi9duu/9Lf07ehcT07ehfQqYvVejvfPjN+qen59O3XfPz1TomfOJn46KzHJh8XKmH5RK6h4AsYQ
xFiUzSR5tQrZQaNOxGq2OO+lYjWVLFxtIxz52nW9qupN329K0IqiJ3CHpmOZZ1qhc9m2Li+lPfE6
LiL00vESbKDSjGC8QIkMn740dTPiae5Ds4LYuUFJ3WuqhMZcV7GJR13lvSnEJlpXM4w4HfmQqYQR
z68fE0LaVU0bEDLrhokamYUxIYIzBxhyWyKdqEGCLHGFoJK21U1o5MZe6lc9cJBe3ARXPdQafYxk
2CLxqmpYUp2xogwgFLZPpOboVUGKIsYBkt6fjlDTeSZsQLW28djLCA6JHjlt6/uMEJ7FiAEc9vAj
5GaGYJsOOF8m1iRm18qPNy/C3whbJLqwM8W3AzuxxoIVhdRYr5uoIjmVw22JyVLXhsqxQr2+BKi8
iMwPEgtUMRhye6u+WpvkKrLLVunS4emIBI1KWSj6Eo8dQlawdSQjvoZM/T5UbJhqJX+2fljOWQaM
0tE0yREk074+RKZ0tU0qZMPQmC0NMQ2Noiq9+nSsaWK4a6bjFa5PbNWftmP+VwSK7IFEedjdKmTJ
NGSMlNROkFYFjA3tO4ZBQnmeHSp3IXS5R4ymIR36eINf0yXJdW+K5sdXOHpkyhbAVJVPWMr4xLgA
5MyEycI9C4j5VU+O6Pp0skenQeNHtZ76+O7WU7bTdkexmyjeOA2sZzX2Wp5kxO2qujQ3HfC0o7sV
NWOEOfdhgHKAc4Fjp1zjzaQsTIOnzzG05008Wx1zHjs01dyLhk0Hkgjxxwgxb4Mqdd1jJsayZ2Tu
zf0e/VfUvp39G2J6dv6G/VcRPTv6vz0X0b+/TbN/UnX59Cerb0IvTf3zbEx6ZI6aGiNNljtHhzJz
nyaGekgawhOdYkSNGp5bjTJDVeIhnxcpZqSiYg2tW9bvGeV0aRQH82PqSK1jZP8Acvyvr/HRM0Uv
86UqpBuHO8gQ1O+iotssJ7IApElZ8miFxi2pHRnTrTvP0rH2FacmjsbXbNNC7kmS37FjZqDK1Vm2
AR7Bs5roi0U/vstIqym08TxxX0twU7smc+krkhCuLPvOrqFrhkrQjybAZtTUjVeiI3JCcg1f7Mso
Xlsr46RgfLpu6x6Yb0y1YjocC+ZHkDdzbqb2Os+SuUtUWXLcRkOPb2pCyIFUpsggbHj6mkPZg0NO
XT1b9Oh38xCJUUTBtaiNS4XZ4So8cytbIdK0+3tmQlYalumyxyq5JQ7iF47qr91hE/19WJ/JKnSr
jeVIqYUcMV6x0yeOOuQYwwAVjVwgmlaOKBkvxwsRgwGbqavaBDp+7KSKkqTDCEUd0gHO2YJ7a6EO
FHwwWlZAaB5SNCFjO1IFI0+h54xCiiTNXr/MevSoAh5VcIYoppjBEtDh7dTdQ0Nv9vU13H20vXsQ
E6zBWMiyhz48kQos3ttyPLGd+oYLHR6Sjad6MRBz6lBS09kkVzFe34BYgbNk14JCleKFHp7gEkpV
jnZ9LiEQMRtRPU4HtSuikXUNCjAjhuIegoWxR3N0KvZGcro86EMxwewi2Y4llIhimo1BQAanvGWc
impnTi18BlaD64yTaF/xxYAgyZPvGuV/7F3RM26qnv8AHRMVei+jfPn+jt1T0bYmL1Tqnq2675tu
ub+rb3/oJ1T0Lnz0+Ou3oTrtm/V65I6f8fL+23TlDmN4l0ywnLL9jngov2zXP7Y7aX3800xROny/
EbAntmNvF/jTPcmk/aNqf+2Su7nfO/oXouJ026aM9rGV719wn3tPMa86FRobgBXOAZYsukP3I+pJ
H7Sk+5pWZ3h3ZeEeequJpab++SXhFujdw9DL7EqOTkDUsrcmlQ8ktJ/iDppyzW3ETu5VVDYrLm24
ZWdw1iicYtpJKOWt0d6QdQgEyHbRpZHrsyv4vdcWLoAqaW6YHbJRO2OrP3ZNuu0EXvbRP8GqE+/X
R/KlV0RkOPqK1cr0aUpBXNhFSlkPkxdVNRGaYrmZdzfDjUpfOnnXthqiOIHUi7DFY2SLCurB0oSc
w6hRENp2jIc8qSOCC8smHPUoqzo3tH1b/sE6RXkAWhsCFF22nyfAKj4/+B7+Kou6Kv8A3cn/AF6Z
qti6udsEnyrPeH3hGpZpOygmSMnQSDMz+yx1IkEr76VJBpp6vmWq7QKn/Qy6c5AD/s1cn8tW5xwD
XoShkyAiY4UrL2oc4dO3t2jl9rSmLKkULO1XauGrxaearKy5dtMblSxzZWoHca+n1WRj/Ib2J2p1
kzxPQg5HkvsEXghBum3YHoFdRhceHFpylcepmBzSbCMh6jYpQFo5QG6PjmFMtU5QKWjaF2oNRiqB
hmln2FeRCwrhJXmR2KwN0izrqCnjsvRulQZkZ0YmkwNZC1fNLEhaTMgrCR+4NaGU6xnP7cKyMhpu
3vm3p26qnRc/HTb1bdPyvXbr8+n59Kf/AAbdNvQnqTomLiYqdE6L1XPnNs9uiZtm+L05Y7JHTR1g
kcjpLZUe3gbHoI6AFJu2RyFO2UGHFQU6V7xgVivJFjtjv1ARFBpqQqOvCo4Ix+TKqheGDUVm0mFX
dV+eqYvo3zf3+M0g7jYvXnEt4C7uIoX0l33EOJkkVhB4G0+3txtRj7jZCfd0iDtsu2cx2De0XSkZ
e9MTeNdD7ZqUPdmRk2iaiDmlpbRhnt8xKiKkQbpgySTuRwRUqGMSAOErZTSBJUNkGl1oosaxc3u6
RiIhpSoga2S0SzgpOSvAyGCfftinHLbNYIYYbdQXrSLTQO8Znsy7jDItWqDtCSmMhXJ+cqijheMl
WwmRkFCj6ntWmXTJmpE1XNYVunpbY8vymyARihA22MIjYcYB2MqRNNNnDigCiWs502PWRLu+fJJv
yfp2mRmOIwLNTzUkSV6VBBJIgBCQMYKAy2sQiEGaJsadfjQsWeNY0aWki5VMe8cQepLZJpW1Rn59
INlZBWOaMwBRhE2O27uI8cVZajmDdAGQlpLiRI+nJ4yTr+yE2FSTBrCXUAWyyPGVjLKOuak2kF+j
ySL9DO3IVcSOauNHKEIBhy+uI0WNGsmjsKu1FOBY2EaGGk1IAp3jFJaWQCCI9ullc/COcMKaq1IM
jUM4arqGw4jM5Daf1LuvlARuo9VbJpt0ePFt9ZjhkjXQZsIVtFjWKviSmd+LDFP1cB1lGmRZcdix
I+Wupgd+11UONGmyCTpLHKmae1E+K5ljFe3Uuq2RxaWMDa+1gKBlVqIM+Pqx0fu6Tswtg62thSEj
ndHdpzVDCNfaQxs1ZqktgvH2RMcnVM2xW5xzbFzfpt0TFX+ntt0RenxidE6pi4npROu/p3/pbdfz
i5t6V6r7+n5zbPjN89s3zfboq4nvnxjl6H9+kcrhkqtSIMc69HJSPqdggT7PyixdTDCMOpANI3Vs
Z2fq2PsupWK6fqBkltbZpCWdqPvtgTxxTS9Ud1kmS4yuXFxcRfV+MTPnKuasE4tbD4T9QsltKu7m
EVj4eqVjCfdoSQHWjAtm6o85rybkh6sSKyTqzyGyT+QtffLXtfrDuNmTvKWvtPBxus12mXKzViy3
w3i1g8aE1e8jWXhRlbrErc/WhMmaiLMSLqY0Nq64JkvURZiuer1gX54LF1bIeiW5WlHq6UzC6okG
SQchsh3cmDkjUcuS0r3vdG1LKiMTWc5MkakmTGjOQZCXU0jXIQro0g0FzNV2DckagnyUMryPBcyY
aGnlkKie8a9nAa64sHPNZTpCAnzoufqO0yROnS8FLkQlPaSpGOVXYm+RrqdHR91ZnaVSPcqbdE3w
FvNj4mo7NcNOknX6tMaNsgilbaTUzRkd6kM7gK9nyHGoBhc8HiOTeFk4sRo5todh/qVkTDKd6jlG
Bn1afhJMg+DKQOEkSD42WcTe6Tf6hM2SXIbmn3jIccytYn1CsTJdlW8LKxd3nzpmPKQ2bYwpgYpz
Fxm6Yhpi4qyFzS0PnJXNVqqSXJuu2cM2xEXGpIcjmqzO4TERd+RMYmNHJJhY8pMVitTuEzuGXGsV
+DiGfn04zsdXFTEgF28CRn0wiYUbh5t77rgx42KQuLAKPHs2xcduubY1m+JFe/CxnMzbNsRm2IzG
Q3vR1eViFZxVyYqdd+qpn4T+ouJi4mL0+PRt6FXov9X36fn+mqYnTbfrv0X07dPzi5+VTDdI7ebq
+peZsmo7DYtKp2Sa5Y7w0ila2j/f+m02TTiZ9CVHmolRga1XvkUjmDBD5ldSbDkxXCc9u2OzbouJ
1/PRPbN8hBU5I2nFIyZSeM0zeLms3wMN78fCczIVespWaa3ZPqXR8BFUr4unFekykUOeMqlg6eUy
SaDtoaL2n11M6ThNO8GrUO74dOqrH6fTjKqXMWLp5X4unmLk6k7LTC4r284riNysqCTHv0x2QjqV
LJDpVEY/TqJk+qUOVmnHSkLplo2WFa4ORoDjFi6T2DZ1/jmq9M95j9OMZn6bRUfQKSQ3TTRsfQN2
tavxscH37K71less0bSo2D/TzOT9Ns4xtMsRH6fG1f06xW2NXtJLRKwZ4iiXb91NQ82D06PhfQEi
nJ84mMGq52Vzs7oo1xBrnbXId9KhNLq6eRpSkkuoqtst6aeBwuYSiM4bshR/IkQdOhHCuY7Rk4bq
glxQqmdrPHVcWOuPbtn5zbfGC3zxVxY+2drfFBiDxQ4gHORQq3GCV+UOmmvFf1/iEBLkQs/UVm5C
kkS1UfsglVPHdnZVMrYCyzO04MEGyDwOrcaFVztKmVNUScWDRAihmUoJA7esdFc4O2dpcpovfmjq
owW+LCV5a6O9kesjtG+PCRfp8ZyatjsinRfcEZx1h0ZDEq6AMQMqojyhXdK6KQgdlUecFymqnTCR
KKNHBrKGKCVBK7Ow7Fjuyop3T3V9FHhBnUkeWK8pnxCu9lVcXpt0+MVd+i5t1X0fPpRf6m/RP6W3
Rem/9Lbpv6Pz6ExUz46rm/Vem2+Obh+mn4fkya2pZGjX01nKkUTg2FJ5To8FsaOyQNZuzEC2SLmP
tGMSKMjB0rWSbWKxIgSsjSojmSxXlQjGnbs5/t0XF6ben4zfNLoj7NnEcW+tE5EVFyrr3SXwaQQQ
X3bR2l4De1JMwDbUg1ZpmIhjGVsZthIE5sADZFoMbY8aZKE9s1Gmm1UZI8aXNZkBgzEspjogqmS6
clgIYsPqUcVlPaGsi26DYD6W6YVNNqiSaJwUg1LpBqqtbXiL7iphN7tnLJGFUSCygSoLZK7NiAi2
STnWsBvYooYhE+c1MvCcHVw44P1XLlyornPBYXIYJH6nlSi1aFWLqJ7ZBYmlnEY/THskZac0nWez
aC3nWE05ECOdrBAZE1LOmTWftbKsggsh9mSK2p0XJcfsvqrOS2RFdyj6t/2yJ0hRVlGgaQagXaSR
XTtM9oMOlU5x6WYqWenfHSupHWBx6VYNhNNJsGI+BPYu7ZdF5BrakWKlLBcWUxj/AB7aK51hB020
gxaURuS9MJ24GmnyTJpoCIbTI+NxXeI9/wA5S13mFTS7HommQNba6e7GVmlW9r9OxssdNNQVNpny
MbpyOiS9OM7dRQ7mENNreAySB0ZHzYWnRNDL00IjG06/UG6XE5jNNR2stNODDlPVsiDKLYWpKsYm
tGpn6f073x3en2R2aTjIKNcEKyNSEM+PawUlrL0wxQ12lXEPbVbascjVM4rdL1xzTpD+AZmrpgJE
AEm2nRh9oGspDZEyHEWQ6h04OMEIQDlWhHjiaecfa4jNOA+lQvFE0s8suz01HFD09exa04JCSA68
TmfTVcyWVmnIiNu9LjaLSEdBR79xkhabUyRNaCasF/vi5tn56L79N/6KelfSv9Fc3/qJ1/HRPVv6
tsX+ht0X26bdV+JHumaHTlKP7Qbf/Z01MVjmO5MtC9qHXk52Q05AsxtBlLLc6WrkRGvR6Wn+nZ/5
9JPVwdRp9qUmzydV6Ji4nX5zbbNL/wDou94F77Ghx/JPU1jYoby1c1EKppNA1rIt6iIObLc8ulRI
xliieLbynoTTTdyuRHDuzqF1L9+ZF28fUhOy7Tcl+HG1zYKDZl/u5IFSso7GiqQS7R1jNrojAR5t
4AJpE8JGU4BNTkiud7tgsUUqQjFbFcPj785CchV42DPY/wCk+SVJ8Jyujao/zIzuE07p9NrSzZAH
IM6yk0VGkUd5dNjD06PzpHTUBBdmND82TVVbKwGor3i1qvlyNP0LIYr26bEHPlrIJQWxRPaBDA1E
JiPrP96J/q6t/wBsnvn503/6Ke6YqbpX17xycmN5RKALWBvLElcGPrD9rbFkywZ/YGYhpN4xHV1b
NeGxCvIepHqyfpk75ESzlviDavJghtb0cVjM1XMYYq4ie9LJeCUH3Aa1aKbInAI7bZFc1uSp4I4q
i4CfJTSvZOsTxB/XJSSoZFJF1bYSRPoat9jKCLsDT41E9Y9lCcr4c22SJLtraMkDTVvImWhf2Cup
cmRK00ATpEVo2jktG4dS4bmTStEladp01Kd8aLp+xWwhlGoW6ntTzJdBWfUpEeMKvj6q1O+QSsje
TKqKkdcDVOpkisjALONQ6fZCZqLUQ6cOi5JJiWBUCGtmMlH1E/hW6Ts3zQKzZNaXBzSIyfeqf/O1
ym8vTdIxgeTGLJRFj6ZXcdtISKlVLbLdrd21ars/PVE67Zt6Px1/G3Xf+hv1/PRMX17Z8dF9K9Nv
V+Ovx6l9W+fGJ0/CYnU6Ztmiydue56PgXcdWn05B5Obsxk8SHjhAoLZF4xZx3mLUwVEexdwjU9sr
pNk7eFY/ukaXAomahMihmL+9VxfUnX85pt21mnvCvhKpYEzwT19m2YKzr+6kuO4BNKuV8bUjncZG
/d0a52XSr49jvz0y97ppd/Cu+Xeguc2XX/6upeSv0nt2rxy9rTTXplgHv5HjNhhszyJ5oVMQcgft
FuIrynbSF2fdSqzKHUUmdMevEdYZSPvkUgNMjcyO8zRrJJyHWRipKuZLQRWsWRNhN4RtSRnPLWCT
6lHag4+o5LnStK1rVbaGeKP9GkTnUtf9PdOK8UdrrQ77aMcY9IMa4lqXtQbI3I2mGoSY5e2C+M4h
QAccmnqBkMV7ethjnz3Sn0sN5ZcdnbBrB38ojs3zTq/z2r9skxEf+E2z7y2En/Xp14D1DFdLHE0m
r1StZHnNTjlY7/tLz/za1vetWJxbq0PA+kl/hagfswP+FHI7L6MeSkTTReF5ESM/jnHbKiOpZ428
B6sE4Z6Qr/qHNHsl0kmXKkaaQUepoUHkdTjLJA2QG0a0U6rKhIUymbNLVgZBkWInGjRmKOPqGN3Z
8ZnajaxjciE35aQL2pxE7jJWnhKy02hG03qUEEGo9TNsM0jcCAybEbYBgw2V0e8sGWsmrgJXQvJb
KzUdN2i6I2SXdP7dbMJyl6YXeeVdh3j+5ZaSqxLH1JqgNPGNLLMkaRvBwjSAssotZVsrWakthy30
VX9NAKwAYuqqLKalfNWEHx4up6l8wtIVpIE+A59idvMNXZMqJs+AO0j19cOtDrvUoZi7e3o39Px0
29W+b589U9e+IvTf17f1Pz0X+hvjuqf0Ns33xF9Kri4dM/NVO8KRU3bZQrgDDConjEO8u1EtZZd8
So18nup2GxxteSSNp7Ge1Y1Uft2FhPZ4oU8mwCUUGNeXTjkITkq/Kpm39KjIg58eW18e3EPhL/vr
rJ8F8GxZMBb9pSUpWxQXUgbxzdu7ptqRx2UthA2z2vJpYbW4+wGobwrXOomdyVHnCGG/lDIlHaNh
vbJHJRhxQ0dfISd9REQQyR2PsraONkG8ZITvA3tLyOIU6T3yaXeIKGuAKMd2wUls4J0+qx4Y7bUD
ilqL5hhH1CEArW5dLfRkisY25hoyzsoz2BlsHZl1GFsWzP5R9PXcaNHW7hFxt9BGyZqoaSQagiHb
+oYMdt/qFs12nLQcF15qYR2GL3FoZjYcqZqoKxZcnvPoJUcBbDV7EBNsCSyt9301rXRhF1hCaK4s
/NevzlVKbElF1kDxE1K8ks2s4/jwNYiG4+sYaNXWUUgo2qmjkj1hXq2VrqGwcPVQVln1zEUFXqZg
JFxqxssdFcR4JP15X8bu/FZLSaoDVitdTtnlbrcDYkLWCjkM1zByZrkSsjxS30pmkmORNJtwNYyo
eXW0SPlzqJlqojOj5WaybFD+vouW2sCzkqNVuhJ/+gRcsNc94ZjkOSm1U6syV/yCxRsvZXlM18FB
t11saRrFhTs/5DA1t1q36mjl5ZGO6OSDrjwwWutCz2O5PXhviD44EjgvrtbOhhs9bFmsqLb6Ue01
wSYGn1EarLa6zWwFS3rqc1vrl9kDnusCf4JZP/Ib5EckhxDw9WkgRpcp84rfbBl7a1WuH1Y7L/kM
swFfbPgybD/kI8oFfdSIJ5+vyTo1LrB9O3/9QyT/AMkEkDg6rPBkm/5JIQcP/kKTGZZXT7SXV69N
Whttey7MOLm2bbejZc2/p7dV9H56/nb+h8//AA75t6E6/CqmL6fz8dfz0/H46L8L8Lh/dFxqe8A5
wqSZNe0c6XwKUz1HKlMa2bNaqWNk3PqNkuOlzNyHluxHkRzzy1RpCMcSTMXCvc5XepExU9G+JgVV
rhmnY50xcLvuuMOZmdwq4w8jEbMKhAkTEIZuNSWVroxkT97cZ5b8dGPx4vZjEkuxIUhcWOqYOJId
joUpEeEjcGA5M8CXhIxho5HJiuLm64ibq0auVtedydhyKKtMTPpJcLDcPGQiEz6QZELFcNe3uoqs
pcPXuj4OO8mNozPx1OUeGh7PFVPNhaZwke3gqtztpm22K3EGiYjcVMiVj5KvoXjaSPxd4bsUapnH
ItUSY5mlyIkuvWKrm7dUYmbZxxW74jM45x3xQpnbzbBRu4/9Om7UiOolxRIucMXNkxG4MKvWLpgh
xStPuithXhqlP/0GSmf/AKJIybrOTOG0L5hG6VN2ZUXsvROS11KWwdMoHQRvHxdW0r5+H0u+MKUJ
RPXEaq4MSuyv06aakjSpAMlQ3BxWYuIm+MDzWHpg8oU2sdCfBqCTXt0gXY+lSCYWIoyQ9LllsmaW
LHZIjuE5ybf0Ezfpv0XN+u/TfN9sR+b5v15Zvm/XbNvRvidPzm/XbPznz/V39K/0/wA4nVOqdNvT
ti/G+b+heqr6N+u/X2x2G9sd75FH3HUdE4iWVQ2PHqKlpW3FN221NL3RkqWNKOhY4f0Vu5qRvNdO
o4K0atlmokZE8X+eynY4VrU9lxGbYv8ATblYPvS4Gn29m2hAjtmJ+9g1csCjcdtlV+IOgqvLc2iG
JlpVNa2FC78qJp8Yh2NSxGuiby6rTzezNqhcbOL2C0VEhUPUiaxaRCyB0wQDSFHNk+kTIVTHEPx4
7nWNO3tTYvEvhPdjoj24wO66d075DiVQUBEqUkzfAjxxMigkZZ06ZV0TAjLCA9LWn2SsqXS5Uepj
xw6khtEagrQsCWRXsVsEMhh6FTThwIsIN5LDuRnJw4TzYtWTCRHMxsRSKlSXCw3Dxov3aZAEorKM
NYUeAkuW+kb2bGsUC8OLqSzgBSO0bhaqEgpBOnHkoK4hmDqzOwlWUbGRVeo6g64WtINBQnlc6qIm
LSm4miqJdOAQkuxUfhWPuaNWGkr9BOmHrSBRW5FrSysLXPDml6JpULIHFQwWTBW9Oo5B6oglFXvk
EJUkC7TFMMAijTt3fvJpaYlgWtrxxmajanhPHu7SzXtHNTlDtP8AZ2yppyz1iaZ/lfbgx48sU5l/
ToiFpConhucR9IYLNMU7ZBWMTt6vRFk0URsaFa3n0wkY3lxn0YyzzHHBAGQKwDqanSOhF919G2b9
N8dm+flev46L1/Oe/VfRvt6N8T4Xoq5+fVt03zfpv69/6C+hMX3/AKi5+Ou+/pXEzf36/ObZtn56
rifCfO/v+cXD4uadB37CvisBE1FYPcXTtn+7xmShNEyKKTYK+xiu5RpDiCLHsu5KT3RwGOfLbvGs
1UU3T9gsnLmG10eW1GEdi+nf0KmJlF/6MZf4Ooiv767kfT0ynVzhVUe4svNNpUHENqRwm2NxmlQ9
00z9oJ9r2kq18uwaNUjWFgsZSH+ozKwXbiWkh0Z9RZNOWxG4wqSC8BbiT4wpFrKkuoKl/O5sWMZX
0vm46lEPJdWPjW0felCEyOx39lZ9qRYxllAqIHhtds5xvYNZ3vKnDR0aJaBrjRyocWq/8wrOXkOo
fJWMLsR2bKs6OskBtPpjNPq6THpo8ZhIEd2XEIbWUVaJzFqwql/UIFtDQ+YSPFHFbP8A9KRKfGl0
t0yaOZWpKHbQPFfCT+ZXf6Wrv9h3SuaN8mqrguD4MUOSqoZRQIIvNZBC1LKqGUNRGB3kro7cSLGK
mpapAZptkZ7pEdrozoflWEKsBCA6TA5XQgKKLAWVKqakUGLc1DSrUM7cC1hrKLAH2o0xwEPIrQyx
waoENup5oGFotSyCylTJYPLta6EyBFTflcgUsWmoGlVEaxJy/wASxbvKpaZ9kWLGDWR4Ng2fJsBd
+NVw0hvsHMZHGkaaAFJHCbUU2LEjQNQSo5IRXSImsF2kUBe7XHgMlq1nbaxd3Wcby2VMZIo9WrtB
Vei4nXbqqdV6b9OPq36r136fjqvTfovXbF9W3RfQno29P4zfpv8A0d/Rv6NvVv0/Hp339HzifOfP
T49Cri5I3VF+dLrwtQf6WoU4zKhHNPB38Wbv4r0VlnB/1bSWzaEjvqPc7caJbNkElL/Guv8AY0p/
dc/6tjt334ub4ufhOm+L0T53ymX/ALKJ7wtRJ92uEhple4YI92pi49yjLpeW0obw3bjzn8iaTltR
00qCjXJO6XTktojjJyDqCRzLWSkjy6wvei6pl8c0yPulmnSIKqtknGuI/cFU0e5LWzHAC05pk6vb
xi3s2QOQuoSuZUXIWDFZxzvyM1pJk+X4YKe0Wxzj7lXiOLKa+bOXjEmr/PrP9LVafdGjmEDqWUFY
JlPGRNstJ614aac+wDwRFsV4wnT5EM8csu1PChDhgEdhsvf9avC0MVkhz7Ww/wBKwT79FUSJcrk2
DF1DYjOaD/uVybQ9X/7D83xmaX/8+635t9mx4TAvWUNpz/69Vv8AVz+wqF3IWqvaNphqfUTf46pN
rg3+Od3GSifUiip7oNa6FLbMBeXYK8VKbvwLmU6NlWrnQtWG2kUyL4E532bIJEkadT/sHZOOsOzF
r4TWUt2y4Zaye1Gh+8XuOdezf9OLVktJ8OGGrjal1Spn6Gd+2xI4UahOWTmoSIyv0i0nbVU21OEr
5gGL3qz2r9Wt/k1KIlfqqQYUirVVgIqcrkhBCpO46NrQyDgu91xU9K4q/wBDdc98TFxPR+c2zbFT
pvnv60xExeipm3T8+hfQvp/O3o32zf1r6NsXqvTbNsXN/Rvi5+N/QvynX8b+lMX3XExc/OGXF+aQ
3ZsINi0ka9goRunIfvJnMgjDYMlinQ95cRP4kqEp5Aq5sZ0h6JCjmc22eXevtk5y6GF2W3tm1gJh
ORHdV9G3v1TKldrCG/8Ai3cJSOkNcElFe8FdwlCtq/tZpEXbDft5snN4H0kBe7ZN5RbgfbLp8Xcm
NTjDvw7OiD5yahnCLqQXPNLnQT57kkjpK1YxZkhncT9oDVD5klaNsZoDtQc6r80v6fHHDbtawmmo
vdmv9hwCoGTYIkoVNA8NtlbtgvFPbOFFgDjkv7sYxwIKz5McfaBeQ0O6HVi2LQtKoWtixgWoyksA
+ayriJDjlthMknckoIdPjc+QkeDIbJYYUJo4yWz2PFCmNeFjRslTSsdHNCSZYRfGqYeodRqdzn81
0/Sd3GIgxarlNLJeu+fGNXNLf+cUDTLMmDhigW45iK0aSTSRuBFe1lxYTBii6cM3s6tnj7WjoqqU
v7RmOOJbRpaTAtpA9y8JCjx5Z0eeLrCTBFMsy2T9PaiUSjaKWKztw1gaj/uZtjcxqwdfcBsmajjs
30/TIEfFc1BCGxr0Qh9NxUiwbXZIlPZCkCKggEJIGUFYaPATUmqnmd75U3Ba4ldYisQSZceuCS3W
+svIjVkSDq4E6TqEYyx9N1jJOMZwZbRhFFS2wVZIgBmKWQGCGRq7/t4M0VkCxtY9WG5uz3B9s44q
Zt7qmbdePRfSnTf1p0/Kpi/0Pz0T1bYvv/URPR+PR+f6H5/obdN+m3qXouJ02/ofGIq475XoXH/L
F2dS3axFPqSMUVbeBjZaXqTkqrpkMa6iAVwtVRkZ+pojVPqgT3ydSjUTLFGyyaoGoHTGvlpqgAQW
Nk+U5zt+vx02zb3T1RDdo0TWABDmapjGHJL3HI7Za3UvhsnagbNWDq0MRkzV4pDJJu+tVqEVcw2t
mEbOm+Y+rtm1zl1q3jOt/OdCl+KceuGCbO1D9QwUp4Sg1e0KP1sxyOviOkC1r28TXDcmawdKbF1K
+Jia6RuTdXPloWQplrbx9Y1dbEVr7wrjB1kRmE1qV7Zc8kvIN0avQurZBhnlEOsHUZq0bddSUyTr
CTIbGvjxHM1pLRJWp5MlATZEY49WzGIbVcw7XzDKQGrZgUdrGcRsqceWoNSyoLC6qmmfI1NOkMi3
8uHh9WTj5+qZ/ANzKjllX8yY1VVcXIWoJ8JhNVWZGyCmM5egR8104Hs1txJJHBZ2Ew7oljIgqXUt
iZjL6eiJPkNMS6myWhsZcZpph5ORrSZBauo7UiGkEK4N5Pi4up7N7TTpEvNt+rVVisu540NLPJUE
2RFwpzzHALKi4WRJMrbiePPrtjhrCXJwe7lZNnMQsuYRBmPFx9lOK1ljMYjDSFakZ2eI9c8d2w3S
BYRZRs4vCppMl6NVw1JLkGQcuRHT6nNxZUp+C7g1aWwchUlPRybY2WdmEIQ2IzfEjrjob9nA44rN
s2zbGB5Z4jseFW45mK3F9O+fn0ridFzfOPTfpvnz0XE9s36bdffomLiYvRPRt6F9G+fPVOm/pTou
J8YmJ1X26JipiL/V+OnziJ6N836fjN8VN+hfh/yz5gRHnz6GqMj1SlWVUOjpDr1mI6i4YPT/ADT9
Pe76JzM+hOVr65zCfQ1cwsTgQdGhGyoTguezbHJtjs36LiL6W9As5OiUKyGm092myQ9pypgwKTPC
exseM4z4+nHOSZSvBiAXuRqF58kUKhaYHF0GjdJUmm1E2TDULodY6S79OORhqlzHxtOOJi6c2yXS
uFkOhdIz9O7ZLoVGw4FGqtzbOOQITpDmaYc0RKxWmj6XVzF021Em06gSDSvlK7TSCbPq1CrIqvfA
0oQo7Wq8N1fSOnOTSnBpdO8Wx9MvKX9KtRH6cRMsK0YEqtOEl4XTaMZYVbgq4ey9tcVmcM7ft2/Y
UVSO+glaw8ZRLx96aj8lg9KjVt7WpEeRqdI0jsFia2OzITZNsK9iIF7me6Dzt5wyip/qJ7XT4okc
o07tTSvsjXNEkEBx7Y/omNTdO3viCzt4g9s7edvbKSs8swtPR+GoITYkhye/HEFvlBptZqrp+Ntd
UXZw4FYvHGs5O0xQjOBaKNslJGyw0+N0oGnY42fQ4yrfUfjI8P7vG3xQ8cXETfBRnkynoizCx6GM
Advp9jhy4TgK4WIPKSpWeaPp6MAa00R2Xun0CwoOLvGXGA3Wi066W4dFFYy+04jWyo6ieuOzb0bd
Uxeq+nf0bZt0XN8239S9N/R8dN+m+Ln4T0J0Tr8Zvv8A0V9K5t0TF6fPo+PV8enfE6/Ob+6dPx0V
MImO+YjO6bT1KnbtzChi0+8ZHTq9sllVSoBLMghPgNG4JjBacihIoYou3JpGvMsEbY1sxoZ9ZIEY
dpUNKycLtlf8u+en42zb0pkD/bqgDbHv7RgMlF7z40RZDqbT7e3fDCFmla9DOL24rLF4iMq4yGsR
BHFBMMIrZDELY1cNoI0mQJ2XaM56ehNYGRLYzBiHIkSSJEj1tm+cafGHwW5DBHDv3zJE4I/GlQVl
SGacLh6Jw0ZWucWhpUhDX9yQY7X2E2S6MCpnlnLNhNkNixmQQhtWySWNc0gqqvZ5aL7arT7tCBoo
1vZmirAI80VE2yykvixzXtkuQWGtJSNZDjwrPz3Wte18ePp8kp36XdkvT6ibCoiSn/pJyZI01wbC
YOBMC0UkVtTe0gChdXXEmM+ARSw9X/5ifK432WuA4x6vmyPqRjlk11CslGaUerjaX/bOgrGLpWM8
CX/dfGiV75RqaAyFGsoflguYrQPJ841N8oqZZrmaTbtZ6f8AFSm015jSaTYqfpLiOwqnRy0enSNR
qft1b/tw4TpJW6SRkYNbxniE0AktjumGE0rE0531n0DgkiaS4R33jtP5Nvp1o+hYRlZqC4SrcbUM
y3fQV5oMbUkxrmQdKbi/S4Ey6052EkhVj62sJMLA08CJHggZHBcTpADRCKeLMpkkzbTTPYbWaUU7
K6uZVTLFjnw9OwJEY1qxXwomlken6YjZO000KxAtBGtJsxtgxO4PVgWhlu+VTfptvitxOnziJn4X
ovp+Oq9Ns+M3xc2xExen5zbPxvn56fOJi/KZ7dU9v6S9FxPVvi5t7Kmb5v6VxOu+bdV6b79d+u2b
YnTfonT8rn5X523wuE+afbzqhqeLqZfu1chRSqsqFjPXiy2kKSbUf4J0ZqIsx7Z8V3KOhGuV39mo
PaTp0jkmTG/9fbp/Jf8AK9F674nTbExMrv8Abql/iak/uYzmWgpERlvZNiCmy3SC6XCjEtGco1rN
e1+lx8nnbyDcSXBdRtWTKCidq+J4xI5HSpVWiNh6hVApTzXulOZ3QxQhAW5VVAOuWVLr64VaC4vO
6alr2Mj2NzGgOLPjyBVEUJSqvvjBqGwI1rkjNENV35ETdkeMwMo/+CfNKCVUlcWHq32Wlvmtb3Yx
1ErVYaUOPhJsUyMiAk5FrkjHOnIUIbAyXs7jRsQTMktYo4UdkcWP246lVnfpLp0Ygwtlg1JFaF8d
dpVX/o6wT75flc/NRNdCNWG78PV/tI0pPdMybJ8WPEOsiPqwTRn0lOfJW3/84VqWskaesiWcW5nO
gRZ8x8170xE9gMV7tLVZgx8s2I+DS/6L3cnYaAM8qXJSGIb+bNVfvsqGqaFu24p0UY5K4R4BkXI9
6opzQ91b2z+mxpBiS5GmaBu1taDqo55Jr6XRUDIA7+/ZWj01yn2T0z2TLaWEUAUR9pOqaplaHUeq
WAdUqrq6YUISRFR0a+s3102EXzY80vghmX8k1jG14Bg6jUAblypvntsr2JkqdHEMS8hyZYhvF7t1
ou013yvX5zbNs2xMRM26fhffGpm3VenHqvReidF6/GfPT89d8+fWmL6E6r0+c+MXPzv0Xp+d9uu2
bZ8Zv6Pzm23o3z8ev56KvT56b4vTfoq4b4J7OrHcZ1KVHRdTx1KtZE7sirB48d+zmXUPgel/17eY
5rwQ3kkA/bEJa+NYBN3Y2ol/ladEvlS3p4Fw7+Q/5XN9v6KZDXjJqP8AV1INXYNezJqLhkgVjD8h
k6G8DtJFe5l4qpFnqvc0uR/lynKkK2VymqyOSZCVfD1E5yka53c0+qrF1W52aXXc1k5Ui03fWdOZ
zDX17IqXdgQpB1JiEr04x9RhUxR00hcS1kVCVurpEuU1d2xC9ywuN/C0wwqPc9GYYiduOMxJ887Q
RpiqeXTsVkLVIXEcYTuUasOZamOsaBf/APYGNROa3S0dwQuI1qyibhqIxklHktAvL9s6yse8rZ5G
Q13jXU2aMzW2Jw2QF7+mdNt2uLcdYG0tiTSVsVxzwGKOFrBfvEXrCRVPVM4V+rxbu0X/AJLxdq6p
/wBHWLvv6IGqutG84Fm3gfRxE8W2gunjtqLxhmZs7gq5Wj4y4W3iB762M9OUOoThCMdonRSd0XL3
twLIAFvAWrAL5NNZFDKkaiiDijuXSbSNMZKD9Fe+wnzGQ49LXOsLFCqzLyD5kaTGWLMrNvp+sDKs
zRUUZHzXPSPG0yeYeLTMq5J91F9Bmy5U/TLRBqawVcDVGqe0xr+ZNP2YTwrSodYEGg4UaU79Q3AG
JEBJGk+PcVboR4mnCyUoKX6W2fbCjnJ7jfpuVJmSNNtiBqbEMwMuh8qYaQKAC8s0tLBevHNum3sv
Rem3TbNtuu3uqZxxfbPnPz6Nun5/OfPRPQ7ETpt6Vzbb1L0XF6fK7b+nbp+M2zbptvn42xPQq++K
vRc398Xrt6Ez8+pc/O+ETCYEnbfp7UPJknjJFVoMcqztexHprpTZNewqQCoEBBNOUxBhak9vYnyE
fZxpzWxbZ/kTakI447y99pB+653v6d/XGXY9NNTxrMIyNsURpo8wkQlTbtljvEF2tNjSOOzljeG1
Vqm0qFGrImD8e6I1xaACEkBmiaHUJGKsFiFlVZhx41/JERKmekKSOc2YMLQRln3zVOG0E8SDjK+X
NhiDDvWEeqAKs6zixA2dgkkmmGi7i2UftluRgmMsQSWMmRoiXmoe5lLqBDI+6ixxXt+6YtAkdzQ2
cVo7GdFIyK6KabFkQQpcamRo6q+4GFZQStddQog7jULpBKjUI3skamjBFNvyHl1uogEClxXjy51U
Nw6jVDHIlzWvyx1RGaGNPDIsZ2qwR49haknOzTs6tAJ2qq4Y724+oFd1pjAFIj6rrWi1FfRZaaau
g177vVopYqzVsWOC5ufqMmi1FWwAzdY1rg2U1sk1LerAxus4LW2+pDWxYmmHEZ+kl2/TDwoC6Sry
TrSG1q61ikDB1rECO21SSQSp1kGJHLrNzpn66gKMOvw9y+1GCfnznb903RaXUD65Xa8itHa3si0P
C1hFgRZmp5UuYHXcdkefaeXJg66BEi2dq6zPp/ULaZf/ANAg5/8AoEJUtdarLyDrwYRO/wCQYu1p
q808kvV5JEdUc53DIU98B4P+QwDDeauLcNodTjpR3Wr5FqtPrL6cKz1MlgWJrqPFBM1/3hPmGJLr
9dpEAv8AyRHy51ee3bWWZqx7f+RG8L69k3bkFxRRrijXovTbEZ7dvOPHFTETNsa3OOcc47p2s7OK
PO3jh5xxU6b9Ns26J89d+q5t0RcX+onVfUnT46pi9N+u3tm2bZtm2cc/H9NEz89OXsnXf0E+CfLc
jPc1zZ01zBypAlLJlvwJjjXypvJs+eifUrFMfNnPx8ma9qvJyWTN4uITl5cxzSOIqqmKnpVOi+j5
xi4CRL2cee5Cq7fEeRidwz8bJkJiFmlx4jJiEMzGFmPx4TNz7jMQ8xcSNJditeNe4d2dmQTFA5uM
ZJzxZePjlGrENniylwgZHFeaKryovdeufOMR2MgyH46K5qigGfn0w2EiPHnjOfjawyoaM4WcHbii
lLhYDhYwKvxlMZyfSipnhOV/0Qi4tK/H1r2YlOYrG0hMfTvajatxXfQSbvqXCwdUSTjdPlTPoL95
MFY+KDbFYuIzbI0Fx8TTZVw9c+Mj098XGpii90aiZxxGbYo0xW7Yo0fnbTfhnDO0iZAl/Tzg192m
/wD6LhP+Rd0sbV1o+DTkmpLqvCwjPZWZxx3tm2e3QI1e4enDqA8dQuRN8hUJZaSqEkVhR8F29uGK
3EbnHEbgISmdJqXxcVv7hD5vHpkxBSoqx1GFXrC06eSyXp00YZwq1ytzb22xG5wxo/eDRlnYfShg
jkRFC57VTExrd8r6Q03G6RNkvTRYyRNNnmp+jJCY7RZuNhTur3OTPnGBVy11Eadj9GnCOXCcFysx
WZt7jHvlfpg89llSPrcg1j5rhaJPsfRpxtk16gWv00eekzR0iMyVFcB6/LsXquL1T0/j8Ztti+n5
z4zfqvRP6Hz0T0fHTfOO/Reu/Rc36b7ej8elc26fHVOnynRUzbfFT2InsX5G3daWoU6rRNYGLBae
VMo0aGtqFeU1K0SQ6NHtfSIxxKRnENA0iWNCoyRKHmO3goE9dWMIO0pOKGAo3PxV6fjqi9FxOgm7
uoqBpQ2NUOO2wRvd4b5AqHycl0axw1kLzDRNPMYOyp28VhfyqzTzezNpxo2dD7RqLT/cHIpRNbbw
EDmn6TzF+hiYOVTp3ItCIYkgxnOn0ica2jEjXwoqOl0rHjsYnZL4rlx0VyZ2lTKGjfNIymjjY+q7
9iKpjR2MixDraUzUbTUCcX14HJbUuRaxTy4NJHiB1NCaDNOUjS4YUQDWQo8hgKYIykHHGws6uTGL
EmyeEMAwFgSSSoQyBhwYkIKzK5xC1giMiwo8QZ7KtY8YwkHdV6GsHadagbCsUCuHstFOgBZGYAod
VgaIxPnETBAeVW1Rth1xCY6I5rm1BXI6qImeG5yrXkZn0kqoSKo8j1pDYtLIx8B48+llcg6kr0LW
EEjGKjtNiGKDqlzHF7Kvc2okOR9MZMOBWKqbLtn50+NCTSkG2DbO3kRRr3KBd4eomo6vWKsgiUUj
H0x2IKsIV30g3J9GdEHXvV+nqdsUOp4HkBlRHAdTD5zO+wUK4cpJmnInlzv2hYZwZQLCueYhoLwY
CpMdhoLwrFhvkOJTmjpSVHnSQhFXR408NgmoKNFaemMmeIvIVMZjq2bCr4LdaJIl8fIFEs4UTLDW
44pq+b58XXeyY1m+V1USaQOkXiLGjCrgQ7cFg/UFC0wyURsWC5CfQJPHTdJ5ckAWAHrxOQtIwxjg
3966kHT2TrSFY0o5c7cNXErbUNwLVNC1GHXYi9d+qdd8+eiYuJ13z5xei9FTrt6l9Xx1T1/jp84n
VM2zb1/nPnovT8+jb2+cXE9sdhv7SZH936XgMSPqaa8Da2y8eRDXzRCgDE7UFgoloiqQViwncLYd
t0N/cCQLS40aNTUzNjU1k7vljoWFdA7cgmL8585tm/Tb0x1+7Qf6+qSE3IvJ1XVukkhxB1oNQW6H
dpWPu+duwEy17WVK+VY8FbFm2ax87/nTK8XbjWcx0V9jYeY7ToO3EtSvAsG1aeTJ3LFrq0o51iXs
xp9zJc6lrDyS2c8cOPBrXWhv0+NrZFMNEDSKeZEishCTAfas5olPHpqt0MhdnZ/ayOp/OMxHhZYB
rZcKUk0Grl/bQSmJEtYf1B1fG8SNljH8mObTPueCWtw9lMNmj6kgn3E1IkZbGZOkVdBxOV3AVvan
aSvgHs5AmtiRr+1/n0l4yWOZXNlitq/xnD9zUv8A5+sf8pflcjicZ2ntPhjxTwQOeWujx4tTTjOf
xAIj64D2srI4pf0mNukKM/JunkOYNfHjsWMFcsawKJFgR3hZEANLKsEWO0Y22NeEPjarjtYTS9Kw
iGdEit3iSA6hAMRnO98b7rpLxObozHDtA/y9P6fYMbODXai/fX0VSIMftswkYZWwARgTnRY7MGke
SORHjVsuFKEVllNjxB3E1kqTpU0YZ+yxyXzO3N0ZE2V4/a2mPgyqcDEg6tE0culjCHX6pjok3TlI
kbLKC2SDT8B0GdYC70SqrUr5No5GQo7o06OKgjjk6isIlfCDCfZSqOgHXj1PqVlcJznyy0VC+WUb
RV0TVFyy3nVlS+aWrqh1gRXDJtpObyi1tUOBKs38INdLj2MZtDHbKvrWJUQAXUgEmilEmQNe/Gji
PdCmQQTGxwDjiG9zpluJDxaWtHWm1X7VBvci+r89V6fGbdPnqnTbNvSif0Ns26J6HJ6V9P49H46K
npXpt6vz6U6F+CfMf2Lpl28XVackFv3NNuIos1CN6P04v2bCU0TJu5pNXukd1x25AiIRNTu3LVIq
Th+9de/5iLjk6J1X07YH/Jp1f4+p092t3NRsCAN28pGHa5rtLTWLlgRBxbOR3ZOm5bAn7n2NQn5F
qZLY8uAXvR9VTE5iMgpVBJQ8fUUjgOmb35e/ixI182RMsBdyNApfJlTJgquPOnEmno2cY2ppZwFH
qR4m0lwPZLOORyLvhGtNZyj+MGtu1nnVu6u9mvmN8wv+O2X+Zp//AM/VibpHsywDj1oVMqpiz4l7
ZPr0XV8tMoLd9smoI7Vi0dWk2ZIIyBEt7UswsCSeESu1JMLI25hswd6fS1rIMXU90rHmer301ceX
JjM8KLqeyEUoFV0il/8AP1kvEhfZcqP9+P8A4ISq64tvavqP9Gdax67P1XGdg57plsX+zT67phSt
CMmrobHWl8swNCqrXajnOhPla4E+KWQsg2nU/wCq1h86cXer1qm44pp7WzWSXrwzjnzmnm/zlxWc
rpERracriSr/AP0oC7RLPUYKoiareZtJJNKvZ/8Ap6d/0taf4tL/APmaqC47ZNYSPlSi+c341Eip
N0gUiTpH7QzFc+xqV3rtVp/Oqf8AztTyfDsqLUSW62lilfHoLz6xY2TnNh0Ek0w+onoyr0e0nL9v
Z1EAp7OhphwQ6k1Clc0lTLmujxO1KrY7Y8TXFuUhaarfOJWVg6wGrtV7t0I5WSrHl4lNJkyp14RB
1WkBlWZ+3s62jELPYP8AdptP+s15/bpZNqzXJHtbpnf6X3E8q+V6QdOkkHfrIqBpuXJcRM+MRc+e
n59K9dsT0pi9FxM+M+eier8L6N/6m3Rf6C9NsROi/PXbrvm/T8b5vj8LvyF7P0vbDaC0CkpkSFtN
iEbDix7och9uBshtEziy4EpXhquLIuzGXhOMyoL9nUmzn0cTuElS2xItxJQxHLvjs2z4xcTF67dR
J+/ThE8e/i+Qs0Pjvqbl0VwjMmCt6xNtKR1Qtom8a1HwNp8Pcmqm0O9FxJXj7surYrIupI/J3DuG
02PhG1ILuNoydqeczTxoNYrJk07RjjI1orOtJOkM040TIJWBbbQVmuBptrR3I2DJTx+9LAnELF7F
hKVJIKmqWKa0sGQWxrRkwcerZ3ru4HEBHA+0NWA8eJdw/JbIrldIg6WR2birIvktt5RKVpGVNb4D
dUWDRB0aTNRnayIHiSbDqQqAGn0ZJlyGxQeWhboZWsi6gPzk18RZZ6qECoiai1NzUh1KtDSrMJFD
2I+sJLSmeu6/GVpUFKrJ7JMcERAlt/aupZ7HDnVbbFw6mJBCh2Ou5clg42mjcslWoYpX8ZscGno4
3Xvj5XB7UPVA2KA6pzgR1lmrAdmDqljVjaatBdiZXJPxK2LABqCUEx2wyvzwC46C9E0jX9ySuW7x
RLSvnMnxxoGEWzVhYtPZhkCk04phDMh10epsQnvrmUMEDTEhpIOtZrc0lci7DmjdmqrWGi6RieRM
zV6DGXRkNMfx43z2BsNN24pEc9eGW8bEYzXD/vwrWVWum382ySrtHVhKe4FahNIjV4Zd66+smvi1
MODrEMuZbjAQUQrSRi1cQ5f44RzpjHXMOUJIOppHlWGjJYI7NU6ueViey19gWIekvxWIiyYsIVnq
Vbmxhuh1VcHXQzWlx4suDpmJFmSY7QRxWMaJMZTX0eLLlx4czGlh10e31m89tT30ezBOt4VTEv8A
Uci9lLi9PwidF6L/AEfxm+flMXqmfnbPhenz60xU6bf0UzbNs26b9dvSvzm3TfFxM/CdU6Ji+3Tf
bHLjlwvSsmkhkj6oj9v6yPypepxyBQrJIpyamCTI2p4sdP1TE3kaqCrW6pGFJ9n5b4upWRgWFn5Z
YGoY8INleOnKR3LPyq9Pz039TF96zVAoQzawjFHPmeU7l71106DkzVDJzIGowwWm1sMjZ1h5j6m4
ZWI7W4VbPuEn5Xy2QiprhjGWOo0n4I3aLF1myOydqxJieQ9pI2q/HamuWZN1CWUYGslC1NcsXJOt
1MOPqN4CJrrbJWsnmbIkukOrLL6eT9dvYknURZJAazKBHa4KRJlmaZkK1fAxdZnIyVNLKWuvH1TW
a9kohdbSJDA3Zo501xKRJd/Jn4E5YxR6wljQus5ZElSzSlg2xqxJNyawVzVVYV9LgN/WVguTbibO
Ub3CKTVEx4yncZ0WcSASRqWfLaqq5cg3kquGusLIiSDmkud85GGhS09c6JGhtkc9Qy2AgpZFjlTV
lo1DX1lMRpzRylvZx2x7SXDSRPkyyC1LZR0fqu2fnnyXkZqOzYki0nzMVPcJHBL+pLJuSLObKQBi
R3JqGzahbKwlM03BjlK2HB28KBliKAEBLA0Uq39muGklOobSXFwtnMkZ9SmOYGYaLn12yRTWUuQg
yPDj50o6DmyANIYpnDe8WLaTNt3EcB5hK6XYYVSuVJZwp9Umrm6vdTaYeYMSheF1nZhqQXNmS2lb
dRnMHCSDmxjntVSmKjROwjj55cluebKx0iQ/GMdn8pW9hzcdzTHJjW4iY1CJjmnJjh8MI8j8+McU
zs5vHnkyN3STuzkqYkk2ziEfnxncfjlc5E+dt8XPz0VPWnv036bbYub9Nuu+2LidV6pi9N/R8ovo
Xov9LbqnX8589Nts39Hzi9Nun5/GfjNsf7Ib5yCBxcBQc2uquJyUa9plerypRKjA0PPHafx+n14t
oVfkqqeDI1O4yTK7xVBWKdsyrfHRzNsd7Z89F9+qpm/oTG++V1M6U0mmnMbLidhy/I2K9fBciNBu
6Jp9xmyaFwmvj7PhUpJCG08omnjKF0OrWXn6Z4slVzgLFg+S4emndqTTuDkSheZP01tkqkcFItK4
7l0yqZJ08rWyY6iXh78M4+8eM4r4mlXqGXWKE0LTL3tXTeTqRQ5DqXyiJpdw2T6hQ546q6s0wSUl
rTeE2DVvmkHpNWsJpvjjNOOKZmkUY12l+OWFOkdtdpN5mrpVGZK08qZB0jux2lUTP0n+2zg+MZ7M
7eDD3HMpDcDxeznHZaajfOQWkmObe1XhPe33XEXZarU8iFlTNmWLNTjJ3Vb70tN52F0uxkeeBBP4
YglxR521xB529siwnSnv0r4kCWHg5rffT+mkkDv6psJePvQaY8tpNNB7dvWuiPehM2JisXZfbq1m
dpVxRrnbXGi3TtZ2lzt4o8VmIntx2UYFetFpfusfQRuFzRujPKBWqo87e2RtQWEMX6ts3ZMPJsFV
udpyY5m2cd+g28lFBI5aTTCERdPRON5ROiuIH9zhZ21zTWnklt+iQRIfT8Yo7urWGbhyzt+8aK4x
KTS42ikaeiEFd0ToRCs4YuL74746/Gb+j8b5vv6Vzb0p6VxcT+hvm3X49O2KmJ7dF9um+beleiYv
pXPxt609KZ+c+c/O2fGbYvx+cd7oX3xvzpap7+SRBr445TJNgwTDhDR/y7FBxA0xhmywKMDe+NzI
YROSdVMkNg1rAt1PHRFpJo25Jr2yxWsHxikTPxm3RM3z5xOm/Ri++lhNUF7Yshtny/JcEHcdR0PP
LaLGiApovkTGgHFjyyCI0oWvs66GyPEkyBvy6Rim07AGKPJkjat+8fa0rAa5sk7I6E7UkrWtixx3
TyzZUYbgNsY1YxmqXyJHba+LaRfJkt08RUJQubjoCoTT2n0GmEjNNbSCrHj1lwedLnRkOKtr2wmf
WWKebAbIHDq0fYDRrGas/wAOlgNYC5sSwmVEkkuIjURZx3Rox9Q2XKukGsppF7QodpMkWBkRGTNW
Bi4LVk2XNb/bYRXz536WdxNpvtsitFXyguBKBcU+7ZEVQur7mVBWpO6RC1n/AHG9s5YnvkKOpTUv
dDF1Ox7jDApn6dpZETHe7ZUJ0uaDRyoN+k1RDUL2mXSznMFpFeM3TrxOoaVIuHF3g31UkXAx3GPR
jLHjaoGTuwR85cIXZiS7TwzShLfybXTnhDqKNbI9xptIIDM4r8YxN8p9Juki/R7MstL9plfpZTBH
pD7kjSjWCrdL99bOg8UjNIooLCIgCVlY6caVpNoAUsBr7QqoIVdZSSzZ8Zp4/wCl+8wtAVJSaQaO
PB075pWaRjtyTpQXbjaffIlt0eHYmkBKltWLDVo980/p50xxKqKBHr2xV9hMfZzANPHZpdshhtOv
8oej2sCTUhqdY4p2oZsULYMS7ltuLaPo6Og7DSQmh0xBak6eZwImnpMskm+AwlbM/wAuL8L1/PqX
0b5+ETptm3T2z89ffE6bbYvRcTouJ6F6bdVzf0Knr/OJ6Fzfpt7dFT1r609sXE9CYuP9sNjfnRf7
o2qf8aPVr9OS+63NUn99Le7Jkdpm20hY2URFeFTMR2atTZ0R20qu/dE1Mn3zY7ExfVt1EnvpVfs6
qTH+7tO0/eWZJZWgsZ5JBNKB95DUcC4kqF9D/IlBanZvTeM+GrpM6tRrYmotgqUzzl08NBxLpqdi
JMf58fc0YcQI5Fi5fFPGfIl01KyGK+vEbmn4LXss7MFa1tpHlir4oZMt37UySNQzlTdgRxxELvn4
dFaySn9ltIJGl6cK8sDViKo6K88dVlRpKRu2gjSGAwk6IRrY0SSsyF9PWPchMKIaI58j/XsG9yXp
3T6Cy6umQ20gUaC5v/pKpqIEsFxKHILUXD68kNG2EXUsFsdRr9yi/wDN1kuzzL7r8plbOWFIp5Ky
4GsP8mlqVrUlTUjlf/ZQAa6RnFcuZzIhI7lIBtg51lYoni0t0eZOlGWPHu7mRONGkOAelkOl1+sk
3SiKIcwZEKPWMtjE0X/g1J712j/jUn/myP3O296UaEnCYjB2GqZkafN1dHNH0lPLOZayXxYsUilj
NaiZqD/Oz3ZYsQ9tUVgogiNY5vjhjW0j/EEovKlLtFo7xTyvHcualtnw8pmIyB7JimG3IZBHdqSw
PABW60KFLq4S2fp3Tr5Tykj1EOuviXd2b+wRwONJ/wBeku3LYdrlmq7l8ANRSksTRIYqyPqbUr5z
tM0jpjxjaBqZW/tvbFyMiRJgjTLz/wAqV/m475tm3p+eq4mfOfPVevznvm/Xf1qvtidfjEXF9s+e
i9PynT56p7Ivo/Hp26b9duiL1+Ou+Jnt0/Po3z5zbombdPjN+r8NjfnRRmpH1A3vjWK7ydOQuyzu
t31BE7qabYo23BnCGsYk5acXay7mOjEqJvkC1Uu6whqSRBd2ompXopCO3Veu/VfQ3E+dJO5B1Qzf
CDVj6O7TjJD5Y7OscJ2lyP8AKluXwLZy9+pKrZkXfw9Qq5TBI5pqLdYuqXOV5FVHaQc9wtSqvapf
/Re7jAEpfqxf9avrGtdf2LmY2rkSVpB9qPqgamVlVIKqSZNKsbWUp5YxFKB5VdazVVI1IMq2BHox
O81zCDkGnHegAWru/K02NWQNTDc9kgKtcOtKbNOxXRa/Ub/JeWiexmkIrguvno2AWOSQfS1ORkq1
kICJVcZNsVeyC2kONYUa/wAHVEd8gsXTBZKT65I5NOab8hbKxBUxrW4fYFhgeUlKJQ12s1/eVfdc
TBJutAxWVerRK9+n3b11gNz7In9lGnafcEMOPGiW811hXlikif6wnb6gtV412mS/9nNGposnTKjD
ID2z6fGrKzVwleyG1VmRG8Iurgr5GiXorLwLjwtOQnxGaj/807fudtco2cJ7F+1PoDS5aaR8aPpJ
nbfax3SokUXajiOhXXEZxzt/a3UIXMlactfEm22qIbYlDZqy27jZseuo1izr2yHCi6YqndxT7ZqO
sWTlU5HQdR18qbIiaVKoqQaRk1HCfOHA0byammBDnGPGp4modQEuz6enNhzByBzwQaDxZ19ZigRN
NVDlMshjH6kqVnNoQNDA1FEmTkr9HMGGritgFvIhJbY6cRPP9NvDNHZw6ijbXE1ffAhQvdc2xei5
t036IvRem+b9FxfRvi5v0T+mvVcTF6b9Pj07erf1qmJ03z4zf3+evxm/T4/p/hOie2Lm2KnRckZ+
aG6dEWNMbNFJaNk5s9keEy7d9QfKYQFYqMdL2kY1BAFHntauo5SGShmo0OpZjSpRR2uy1uWRhTpj
jvd7r8dF6fjFz8dExM0rLaME9rJDLhjGPGZwn01/3MnvA8On46ISTMG4F24bi6fChZDJQ2A1AQbl
rhISZXSBAjagkBcm3I9C4cMFxKAQQZKRp0GybLCwIGEtr8Y0g2wnCekUxCSogAx74feUgJOFsIUE
d3ZskkoWDLKBYRmBn2wgyY9mGSMZocd17qJqsp7/ALittYoR3mpFPlEgpD40+GIU2bEINSRpNlFL
XhS11OAI4V7wlAsIRGJaQIrdQajSWtS6vYB+oIUMNvqB859HLZGl2epgeLJk96RRajQaJcVz8nas
iRY6WY5882qo0OHZWr7Ars01KrwsXU1aEeobpJ5nYvSqeEcqNqqrCDUGpoUplBqdoMLqutRgdaQy
j/VLRzR6rrHtJrOsAOy1I6ylg1jDjw4WpAjsrfV4JceHZEhSoetYSButbtOOFKRkyPrOrAG81dCm
Bp7GPGlN1xWI2+1HHsspbQsEw9ThVIkpJY9SG3AzSpSN/R78TShYyg1Iyqauva1MuNb+YPQzXqKV
JbGFZa3YjKrUh4Rya+gqyPrwSZd3TbR3D2Qe2I9WrSarWvyT/wAhA4GtzS7FNegBF+vy3zn65E+P
VatfXkT/AJCi7TdfoQMDUEiGf/8ARI2xf+RBPZE1Udk65tzXDuONfxWm1U+oeX/khjmSLU8yWLXz
RRHXEw01uvESNA162KH/APSA7v8A+SBNx+qpBrH/APRE4i16Uci61F9byk1SWoSX/wAguMGQ58g3
DOGKxc7edrFZip029e3RV9K/PRc+c22xU9G3T46rm2b9UzbF6Ln52z8b9Uxcau2Lnx0+fQvwnTbp
tvm3XfFzf26/lOu2fHXfomfnPwvR37UNi4DIx5jGK+Rv3JStVXo9pprsQ83PIskxxrBc7kvYqHVR
kkNQrirjCyUx7Trjvlcd0X36p8fPTfqmAIdM/nrhu7i41zm42QZ2IYzMYWYTHANic2OaaW5XRjri
o5mI6TnjyH48TmY15sQMkiujvbjBGxI8zHxzJjEOuNjStnglJj+Tc7hc+4ubYjVXAxpD08cjcZGM
9fp8jCRHsTtquJWmIj4bhYgnPxtWdUWsKiDguc5Kc2fSTYeI4KK3FZ07e6gryFx9e8TXjzgiYjds
DCeZSVBWI8PDokbOHHNvcUN0jG0JFSVXOjNVNsXoi5wRc4ozFXdEY3Nkz8dlMaJNuPu2O1yvqXjE
QfHFRc7aKvDOGdlExG7YjN8jVvlPPCdGdpvw2EHOqR5ZathxApqOQ2e3/kYzc/8A0Y2P/wCQpBGT
Zb570HgGIjqS4rYUWx1FXkjTT946++cds4YNiqsOmLNU+mygYaMonObis6NHzWNp2RIHMrnxF2yD
TlmpI0ucDZEftOVvujfeFAfLc/SMpg5UN0Zdtl3zb2azfI8Eh3C0hKc2wqnw1Ue2cfdU94kN0h49
Gyno7R8hqDpDPP8AouUqJos+TtMHhNi1L5hV0TKaybXOiLHrnnezRUp47GlJDx7dsVMXr+d836b9
E+dsX29K9d8/Hx029Pzm3o/OL036J/8AEvVPUnRU3TqvX36bZt0+c+MTquOTfJHyib5VQFkPrdP8
Rz4rGyQUjHRyU6+YOkRI8OqYR5KRjWtqRuQdIjyWen9mVlHyy8q0AlRBafJ1Mjhy4Sx3OTZXfPRe
qdPz0amaaqElNlUogsumDa7b3hV6ncunlGEUXuS6zTrUDOphqydE7Eil08hWSKUTW28BIzqGl8vH
UoWMu61AtpKvzCsogCHOqG5X0DGhWFE5S6Rrh1lGNXFiQx4SoYUNtB7JPHdnjuxwlynqSTjRaKPH
FZ1iedEpARg+PCe6ypmdqo073i/TYzUsqVFynohI4yV4M+mgkMh0gRlMKKJhJdY3LqSAuMA4i+E/
Hx1YgGIj6SFHfG1LDGMBmbuSCR2eM5i6bHEKlrBGsOdFVCQoSyjj00wYbKqUDlFs7T8qDHbC8aQH
Vsdg3m+VX3zbF6csb79Gs3yPAKVPpZsdFcxdN0KHfeQGLEkgc1zIryu+lGwkNw8FXlLiVxVVawzc
jQnFJR0w4cTU1cvkyB8VVvtxRuMar8+mm4+OvL6aVGsr3vVKc2GrSiRKt5sZTkc4lQdiKFUUUVx1
fWlE2kp/OkCEGtjjOGwHf0vbwtYbPEernVZWt01SeUUIkYPWKbS68SSJMCK2HF74ZGX4RtnDpJD1
WjkNyklLWzUXfNQ1pVOYCszhtkeOpSRtKkcCmpBwRmt44ZNnVsnjkUxUKWC8Tx1JjZppIte+01rH
hrS27rePKUFdMstXQoAaHUy3j7QXfh1laOuGG9jnnXVK2aylo2QRyb2PGl2VYOzDdRPCMufGb5vi
KmLidfnqvv0/H9HbN8/PT46b5virvm+b9F6Kv9Pfqq58dN8+Oi+/VU9C9Px+MTNvbNs+Om/oVfR+
PnHeynzfbNGRmkbbO8eKaa7yqGX5I/BHyupHixaKQpXT2q8RZSxGU0tJSKm6DC0eaob+2HNfGLW/
yganjoJxU919sXr+eiZ8Z89EzRy7i1Ry7J3qqwoDpJKmpZADf3aNSiZ35as4xZlmsZUP9QnQB8It
lMfGJOnecSgDwi25Xx32VqkjNJxla20c4Ym26LJY/uRfpZVnmXtRbK5kNLVwJVoY8hlbEDGW4lj0
0FjD0gkQ9L3JVdXMrgpktvG2M3vx6+mWPNkKnbExGNMsl1i1qOHcWJwGq6g1rIMYdZEp53mpcQlm
jJpn3FQuWTG05GAxaaMuXVI1gqTT3k5Hjsij1N/qUdeI6tp4/G4pWjHpL2luaj0tKZj2zIz4JqS9
7mSoTZg7euWO5E/fpv8A83WXyf56rm+bYmNX303UeedkCLHGoIRckwoo5UAkdw5LxNZfSgklaaDD
eLwwKl7UsC2njRDhZXRgqWAA7Io4UCSNWvbdy4gI80yFMubZQuj+U2FGlR4mmxCPe+MMVbVhiR+0
zJteKQKnDFc14IkVHxQSg3Ff2ZmnKNAZbVzZMfTUN0R9oHyItLX+A+0UbY7BxZ0eNp4IZGppkOBD
qtQy4hIJnSYusf8Ac0rCSTLzUhPpcrTNak3PZMVrXJd17IUxi/YIwcod/Rdh6RXPNp/TjQstrYUJ
o/7ZNMwxh/2wpsfy51EGY9oo1XF1BYDs5NBp6GeNFiDhj1w570h1qyDUNOlaGbcCWcZPtxqQUeS/
GZJphyjxv8WsV/7BfQrc/Hx6V+NsVOip61TN/Qqdd9/Xt6k6/HXfE+MXPxnLNvV+em+L7+hMTp8+
j87ej8J75+ej/fJGbZoZ/wBu994shi97TLTK7NSDIRNO7tfKMgWW8hJCac/YljYrEdCmpKZqpfto
u5aH2BqxfcuL74qdF9uiL7fKonRqZtt00h/j1R/jkfOmhCYOzK54Z7XoXTcpgjIX+NqCR3ZFTKbH
l15u9G1RN3JGOgJNDJSQDVEngwi/d0vYpIHeG7UMa96wgs7UMmpOE5/8iI2pWZOVQ1Ee4siTiaXZ
tH1OYgmR9Rlitqb1hDJcwy4x7SNseLpj17IY+oXyZpWcm/iXPYI4l+2+rWxsiPDURba4fYEg28mr
YmspaZRWL7MSBahHvQbXX8Fintw2BNkACokOkLqVOUejqBx47ZIlLa/+fpj/AH7IqhiVhVkRdXBa
J0KIWTKrgOgwtV2ICkY/9+nP/N1l8mXdevzm3smbZx/dUWhYL4ksc4BqztjuGSmk0V/ZqP8A8+PW
vJIgQRwYkaeGWTUX/naOTL4zgV4daMigkWS2FjWf6Gq47pM2REePFTOOM9s0Y4hIy7IkvuPu2L+y
Zq2PDKfVZTA0g9xS6i9q+r94F5NSBd0moB3OWdi2sDp63S3lWplBG09LNNfqd6NrNHdxRrx21Gwp
JYW7Fqv/AD9ZJ/IpnvbNYu7dSvcSXpFd627um0wg6yNISZPkz7AX+Onc76nft5V+nqFB5qDULKUc
OWWdahXcMiXJ8sfs0vM94JEQWsGPJDBWlKj4UyLmkHOfB1q9GA0TEGsbVNm+ug6ZkK+zk/4oJ5ZZ
soiCBFf3AyZEts6OnAOqzoSzXonRV6r136e/X46L6N836Lm+fGKu/XbFXE989vRti9Ns+Om/9Beq
4vxi4nXj7Ztm+bb9Nuu/Xfovp+c26Nzj7rm+b4bE9l0lYNjPJKScGxg8JFGJIwDagayQciTAVwO1
Ksm9wMSpTIrGCfqV6KPTMjmzUpE4wIvkmjvSDGv56SHEdi58dPz85t0T0Invo5/2b0flMsoSxlgW
D4pq+zHLHaVrStpYqsn7bQb4KsJBGr5NYztxNTC2cxvcLpsXCLqQHcwqfc0eDgy8H3QjXsW0eU18
P6UrppiNixK/tqO3gEnli6Za1kBw4hLeJ9QyJpf9t/GCHIcfuSKsKggzU42DzNOCHTKOdZTGxAwr
tkxralhy21oKvFUPaQFvWvschaXBHYSmB3z6faRKiB4ASWgmTJaeXGj6UGr5QI1abyWnDXBbEbbo
hWQZbHiBEQM2wchYtHsKzlg8kEULYUa/mJYzqOtBVxtR6pwplK+jp3WL6+L4kXWcpvcKvuuJjBK7
GxH7JGdniuzxn54zm5p2OBVdTtOMAlCPWE4G+kLUYceEcxt1IhQFhzGTAxwBr32yNkRdOwfFBbi7
kKfxQgCdt+n7QcqKaOFrdQzwPMkMjs8ImVlQ88kaxaeDA1PHsC3QwhWuningdp8BC2poNdE0dJaW
TqmawUOnejq7V05hbCtvJFTljqKXbJTW5Kp9bOFaxymi1QC27tR2fOLTwq3V8ewPqKOBwNO07JuD
Gg2W9eGQ2ghjkWe6Jmr0ECTpO9EJJcIE7BxoVeO3vI0y3jkY+OOOCOSzv4xZd9qgNYGbMLYSGEc1
dOap5J/G31Pq9gU0xGjCj3GsQw5ALCJawodnDrrGRGhTcEkSvFrDUTLU2ipYWRde2IlHHkqB+mdU
tlM8iGHNT6vJOJpnVLgZ5MLfVmse013J7/nrtn5zbFxE/o/OfPRM+cX26bb9Fzlt0TF6fGL0TovX
b0JjsRMXPnp+Pnrtm3oTPzvi9N98TqubYvXbfNvRtn4RM36Iub9PlVw6bZ+QPVjqrU/jMlagbLcm
qGtEWepJAtT9pkfVDI7v1gB+P1iJzU1M1HWN55iVt4lck+/+oJXXDK9bDUzpzTFV2L74uKuL0+MR
d+iJm2fnEXKi9Ssa7XIlydb+fjl94U98Mj9X8xQL9sRy67YqWFx57q+ckN6a6TjY6gWegD9k4db+
Oybq50xqk5Eh6s8JknWbpDHy3EfC1GSG1Nc7ZO1MWdkbVz4jU127Z+ujEb9eMh2a7eFJGuSnZJnE
lLAn+AZmupDEmajPPyNqw8Rq64kIk25NYLDlkhl/WMrjKsDTFi6pkQWfr6UzHa4mlat1J8gWtZzM
Nq+cZHziuIDVk2O12tJ78lzTTCRdSy4YyalmSHm1FMOOJdyoOSdUT5DXaml8I9tIilbrGyaknUth
LaGUUEiRqawOjnuI7K+6lViLrCzVsiWeUrl6BRHFp9OxkjpRREz6LCxaWHn0aHn0WHvbx48ETtS2
QXF1LaFa8jjOGR4XpqGyRsg5pOBuJsNprywk4txOKwV1YiQ1xZnRyruvzGnniYW5nSGaXhxZLmRK
1E8asyd4MUNhYllPE54XFmyjoGdKiN+u2WxJZ5KjkmjI+XJPjJ8tjXOcRdsRMVdsZOOBHSpB0E5w
nd+QfGDcPCnkla2QcKLYTMWZKJgjlErp8xcQj34jnNVsqVjzSX4qdtyTZLcWbJcjFdujXvVAY8ap
ibtxZEjOHv3jYuIR+Na5caklccyQmKzjivImK53TuO2UxXYnsnJc7pFzbpvi9Ns239Hznx1T4Xou
J8YvTbqub+jb17Ztm+flM+MXp8434VOn5+M+c329H56J1/HVEzb0fnr+d+i9N8/CdFzfbovR2SOk
YfN1fTOM2VT+PkejUzJVe4JY9K4rW037/wBOeyUCYtF+6VQqNsarcZZlKoGxoCyVPRqJpgKxVTbF
zb0b5vvm+b9Nt8TK6u8xyaW4pYVniI5MYxXKyve7FjOasCifJwunFGkmIoXQKl8lXaaVGzICx1jV
7pL2aYXtz6l0bAxVK6Lpp72zKJwch0L5K/pnZZWn3DQFM8xGaYVGm045rZkNY7lb79vbOOCApHV2
lzSRT6pYjq/TRJTP0qqZMoFCwVY+QYOk3tDY0qx0fHVFqtOlnLZUHhsaBzy1mliSWS9NKJkiE4K1
OnCzsLpXttnVigdWUhZxnaS7bZ1OonwNL99tvp9IQni96TTTpyO0i3H6Y4tt65Irx05nsPEUK8fe
jo3WJGaQYuX9L4GPb03zy5KZ50pc8uTnlyc8yTjZUjKOlNbKukxsDYxUAZW7LEieWUOkBii2cdoC
cM44MSq6n0y0gLugFGiSR8VVvTfEV+NY/ZGE4qN+VtO+wLa6aZAhHHwcrM7eKPO1nZ9uziMyk0r5
rb2tZAM9Ezjvnb2wQlctHpZDsdp2MjLmmdHeQStztck4bYjcRnLO1tggq9aDS6HZfUMeNCP87e42
b4KG9VotLNe19BF7d7ROiOeDjnDOHv287fLFHxzTVD9SclFXxm/RYR01FSrBc/5dnxm/RVz8rn4X
pvtir03xfXv6dun5xPXvnxif1FxFxffoq5v1+c+PV+ei+hM326/OL6/nr89UTfPj0OyR74n92noX
kHh17Yca4tELIqDjKCTSqZ6RWRIsSYx8s7kaAMxuR1YYx4gzNjVKAJqIKNDXTWRTCa2aO+ruxhW7
Yvz136fGfnqnzo1jVbbykiBtLF0t3HktLSrIdKhRocZjUkWNfFbHhyZjMu0G8un4TRx5UxqP1Co3
D0nCarZcpsfLgwnh0xDSQaSZsURzhPkILI8eVeFSYgUNHSfGrHn1aQxYW5o18xpZItOPc12nnpki
ucImndP88ROLbcLS2fsGOG6lFmSRNeGsrGRslXTQSSxGzRPq0JZRRsADUv8AqacrElnnzG10aBOb
aMl0jTF2ZXxYVv5759S06QITIAGXvclS4DTjozuflpE8yPYVD466f9q7UM6VFwtzbqjJpVlwpEeb
Gt6drklxlC+HZyYS6dkEkwNY4bFxM26b7Zv0avvpuSUUz5HJ06+QWyp1i5RwClkmSQsSxa5T1WlT
TGm0n2U/Sbgi0u529rGWXFk6WVBz4fYIubZAhvlGjaM+27R7USTp93k0lSlcydE8oN5WtgvpNOLY
NTRo0S1o1iFrtLLIEzR/N0nSLBBrNNuOaMFAhuqVs1s0LBGqKt848rSDI4KKA0tkd3jx6qxkmmWU
VsiN+le6N9CTyf0Y1oK+kbMlt0hHalzplIral4Y8mvsY0tNSqq1h0/c1u+af086ar6uLGdId2QVM
6aSysozDxW6UYYT9PP8AK/Rgmxq+nZNnM0jFal3plIzIl7Kp1eyyv107BfXw9dnRon/O/u5c9tt8
36Ozfp+F6fHRcXN8336flcTPz8ev8riYufHpXNtvSufGb++b4q4i9fj0bdPx03z567dF67dV67b9
Vxeu3TfoufjN+nxm+L75J9s/Oi1/ky/9CwX+TpuVxeNeQ70vCNULvO4o8Fs5oGUEhyvKdoUGVpU1
D/rHXiTTbtxaqT9pF93YuKuJnz1+eidE/dmjV+1qNP45/wC6grPMIrRVsW4tHyiaeYhZAURQagJ4
7oDvJm1qNbG1I5AKshTSNPtYONf8Wx5ssj10oNg0skasORKcybVPcaIaPH773/xrSO48ui0+0CXl
42KLTkfziWU8daIGoQS0YkedN4dobEVEthbHD7gRsRhpG7hi9mSozO9F/wAOpCvDK0kchg6o/wBP
SHuyzChx1jGsXJKI4MMYxSVxf7ewMR3/AOOgX7siQ2MkiKycIFgCqwlzWHxkSLNHf1iQ3QLMlcar
elnG1PBZGaq7O0v/AOfrP4L7Y7367bdNs2xEyg/3m/2RZ/kyNSBb4dDPLGlJ+5pmoW3CxBAgTHzZ
l4ZwK7SDlcSbKSFHjF8gGqxoOYRf3J75pawBFL3lMLy5cbLfUa89JW0izS4lEiQ5kmRPkadqTRou
2yalYi12k5RJC2ExIMWBOZKj2WoXxLGuK48LVlvKAaOLypVPXR4gS7PTsx49tL/145w+XNXaHQXi
yJXb2zVNwSKmmqMitYiMSx2WDYf7OhduWo//ADCN5F07p50l8yXGpIVNdEubyX/gjywkkT/aHp63
I6Zx99XXL4+aboPtsRg8npvBm/7lXrRIEeotfq0fWcNrHF+M36pm/RMd0T439KJ61z4RExVxc+fX
8p6N+iddunHoubepeiridN/bN+q+2J0/Gfjfp+VTf1L6tunxi4nT8r0XJCZ+dJSEHLMVCQbaGrC6
dgbuU4wpYtbIDDjKCwOqthlYaUSth9hb1zu1RWbiZqBeUZ7HFJp4fZFqgzVwjt3O+fnF9uie+KmL
02xOiNzRy/s1A3lFmicx1Hc+I5CpOFbVOy1vIM+Hv4WoUXvjcvd09v4uquTnP/a7SfLtao5ds26O
0duq3vvDZ+2zr3J4Vi0zrGL/AKUWuYaVezyRwpXyJ66djLFzUzeY2VBjvUUinxNYTmuqJD5MO1O7
6gR38UIC/WHqjBiksc2xZILJF9iLfmSRJ0cJzI+pGKSJph6RktnPILT8coxmnMHIlk7keoinSxnT
GRsSUwgmxJRLGdIbFjaaKhS37XPjQU4RbevWxlyKB7M02Fwa7WRffT2nlmmnTY9JFubolkYInHfp
sSirtZu2wzv3Oz8bb4jM4ZxzguIxc0+Fz7BU4j0+u87Uy7VtIndnImzSiUFw124aeK4J9RLtWaPY
qZqJ3GBV/wCjq5f5rm/ua3fKWmJYGEyVVsC/ywanrEit0OVvK0iumxi6dbAwa/ZqmGbJvmd2v0cF
7c1AFx66WsiO+M5e9SvR1dY6eW0k3tUOrzTtt4U241hC8OgteFn3WWEasolizdRWwoMTStO9r1kN
R+oalZDqhyLBeA31ycm8SZCIs7SVaWElzHdKgU+m3LLmzo1JEu78t4fTs9tfMYcdnFrdPNgzdR3A
oUXS9M9j3SxIXUdQsl1KRH15YRVupqbxKvTjJcmx0grc0/BfBh/8gy2Daq9V6fHVfQnX46Li9N+u
3T8dEX0fGfHRUxOnzifPReqev3674ub9NsToufjPx+OqpiftXE9s36fKfn8Zt6V6bdd+idfxvm+H
90XIUt8UtJetlDt3Bc2mmiBGtrdylr7JjowSjLIfLY4Y3AErrESGuLJrxUcloiXVkN4KprXnlWYI
QbGxdJI92/VcXETpvm/TfEz86VkoFTyRyWX3Yaiv2WnvHRyElgNHhsC+xHZAZH1FIC/K0aFmV80E
cF/KA9o9nyqSTHhgurCOQcgiKXTJI8QdjaRiBsJTGzaa+bIEixFdaaiBEj01yLtGkQ5CjsIMUb9R
BbMSfFlt+oQYLL+6bMJW8STIFnEjx7m6itdAvY5gtm1zFu9UDRldqJzDxrqI1t/q1C5TGDJkw7Sv
ijk3NeUdjcCZLq9RRnBs9XxY4pluYsik1KJRydWQo4ba8fONR6gQbv1TBCK71Ms9+lLkEJHalq35
aayhiDT6u+6mpKp2SdY18YR7j6nYfq+DAh2t6SwNy3XTc2BFxNX1gmah1Eyye9d1xjd8raAs1rdI
FXP0gXP0ibE0iVM/SZcrITaZ07XEJgqLVAIR9R6uDYM01cxK1369rMs71tnLp5phRIdgKaupXoyv
rdW19eK+1eKyyDriNGidmTqSSmizKn6JLgquRSYmu4QEf/yDAY241Ga4dWWz60jP+QobWXmsC2eU
+umRAzP+QBKhtfAICBr2HFDL/wCQ4pQTJfllY7bKPVv0tZH/ACOLtzrM9mdV9+KYj9so9Wuqskf8
kDUZLc0iZ/8AobGw23srzSa/R0aq1i+AY/8AyOwrI/8AyDwEmpFSy/8A0kOy/wDJYExdeuWZbXJr
km+cspNVkqHSP+SVeN9oUk13/Ij/AB23Mny1/wCQn+LVauNWmP8A8lEKyN/yHIAFmqJH1D/9NXY3
/JZijlyizT/lfbPnoufPRfRt0+MVcT3xPbFzffPnpt0+Vz5z8Zt1/CZ89Px6V9l36L85ti9N/QuJ
6vjN/V+Oir0T0pi/09sTPfNl2+Oi/G2LhsVMH8x4xH4sOQjRxjvwgXiwUY7sSNIRUhTc8WXninx8
Q48YMi4QEhERj1xYp9ntVFemL1Xp+Ou3VpHInkHzvPVPnN9l7hc7hM7xlzm7O5neLvyIuI7bO6TO
692Kvuj3JnceuKq5yVMUhMbu3HKq5+7PfOW2fuzZy5vtiO9nfO67om+LvnLbF984JsnThn9uIuey
5xbirvnsudtu+L8IxMb7Y73zii4qIi5wTPbE+OKbqnRWo7ODM9ts3wbuDoOvEhB//Sxon/6Wxc//
AEtqZ/8Apbc//SstNbvs2PdyV22b5857bxJaxZFXqeJKEuoKuK3UeqktMc7nn4T2yp1eepEv/JMn
P/0mRtZ6zlWTHP5P/O/tidPnomLm3TfFTfEREzfbpv7b9FXN1z56J13zfNvfb3z8r+3rv777Y7Pl
N+m+2b9d839s39sXE6L7elU9CdPhEzbPjHYnp29ui5vm2fOLiLi+/Venzip0267b4vt6dunzm2Kn
RMVMVMRM+c/HoTNs2z8Z84mL0+eu3T46qno26IuLidF+NsNn5gxu8WjouTbkIIwqWCN7LaoRVq6d
ODoYkOOqEokhBV76wakNRscIVJxk2VSMcWCBrpf0wTw21YoFe3bFTPjF9CpifHxm/X4zfN+m/VF9
W+fnN+m+b9N8+MReu+b9N836fHo+c+M5Kub5v036fGKuIuLirirnLpv6d8/Ce/RMVPVv1Rc3Xpv7
9PhN8THM3xGNTE2b6d+iZtiZviYvzvn4zfpvidfjF+V6Lm/tn4+M+c3zbOXsruiZviLv0X3XN+m+
KvTbF98XPwmL0/Ho/Kriri5vm+bZv0VOu/TfF+E3xPRtiehVzbFxPbN0xPV+V+c29uir03xPRv03
9C9N/b8/nbquIvp+Ou/T56b9Uz89N8+MVcTrvi++flcP8b++m9iS4zOxAvTuU+n568hBYYUnjHit
kuJZATnDOJ8ZYFh35KfHabvcJvEkuUcrT0l0lupo7e2f5d132xc5dPxm+b9Fx2J139CdU6b7L/QX
N9sX3z8dN+n4xM3zfpv77YvpX1fn8/leruidF67bdfjFzfN899k+F+Ez858rtnwqZvi+jf1J03xF
3x2b4mLnviYrds/Pxi+/p+M39t/b8dV6LiLnHPjE90/HVMXE6fGb+3T5z8/jN/SufPTbN/V+c/O3
t09+vzm2bdfnNs26bbpm/Tbpt7ri9EzbovVei9VzbPyub4vuvRE6r8J0/OfhOq579dvfp8dNvU71
7+x/j86bXhNC7/r7wSpKqI7nHhD7cazGpANGorKK/hEs5/NauO4R5hVHGrLnuutl3hzl+9plNk1G
5FFI/ufn4Vei4idd+iZ7Z+V6L6ETpv7b5v7/AB1TouJm/oXNum/TbPzi+jfrvie+Lm+b585t029H
yu+fPoXExPQmb4uJm/VV3z4xFxcVcRdk33z4zfPzir0/PReie6riej5xM+em/Tfp8pvm+JiZ+d+i
rn4/G/RXYmfjNs/O+OXE+Pn0b9N8/OLm++IuJi9FT1r60xfb0L0+OiZvnziJm3vm3VFzfdc/HXZe
q9PlPjp+Oqenf26bdF6p8+jb+h8Z+c2xfn56qufjr89Nuq9Fw2L7LXyvGk1N02WC0ioRmnI3vaXH
hMg2fmjlhRspip4qQEIZzGBdYyG+JVk/nWEhHRHDQ02tjeJG1BcMLhn79F6I7br+PSvp/K5vi9fj
quben46fKL098TN8367+3RVzdOvxidNum3T8+/VfQvziZ858dE/op0VcRcXqvtm3RcT2Tp8Zvn5z
87dN8TN+n/8AH0b4nyvzvnz0XPjp+eu+b4mLiYvoTpvielUz2z8er4zbPxt6F6fHVfjFz46Lib+v
bN9s39+n5z4xfV85+fnNum2b5vn5XPyufOInX8YiYvXfp8/0Fz8dPj1fnETFTNuu3T5z5xMX0b4q
+5ccv7mJ+6vmFhuJqeSdgL4sVJNqaZkW4NCRmoj8k1eZEbq+QuE1GZ7j35jsFOeF5r8x2imrGKbU
UgzDkUjlTo7qnr+c26bdNs26pi9N+i+n8r132XfE9P5xV6NT1fGJ0VMReiJi5+N+i4i4vo3XqiYv
RMXpv6EzbqibZv79Pz0RcXp+Vzfr8Z85tm3o/C9ETPjEXPxviZt033xem/VU998XN+nx1+MVeiKu
fnpv12zb0qvVeq9FXpvm/TfdOi4mb9fnr84iZt7dE6/Ce/T4zf1b5vm+L79F+E6r0TN8XG9N83zf
oubZ8eheidF6fnb1fGL0+M+c2zbonziYmfn84vt02zbCpit9xN5LVVbj4Wj7YYFT5K2VKoUrKnyF
NTINwtPqrVoVw1Dxb+n9w/SXNkPofspG/kJRK4UyvUDns2VffoqZ8dPf0be/52z4xeiYub+hcT+1
MXNvb468cTFz4xXcs26r7Y30/PT8Zvi4nt6d+qejf0b9N+m3RFxc32xM29+m2+bdUz4z36Ji+2b7
4i+lPj339+nznxm/RP3J198/PVfQub9VzfZP/wCSpm2L8Lnzm23RVxffE+VXN9+idN8+fRvm/X56
bb9U67584uIm+Lnx1/Ob4qYnTfPz1Tp+Ns+Oqb+jbF6ImL029Cr1+E9W/p/Gb5v1T4Trv0/G3VM3
9fxm+fGfOfHRei7r0+PQ5MKns/2WtZ3D6fr2jDqG1Vi6fs0a50TzBw69IaWFlxmwDK4B5ZByPPQr
xtRQkrGuJLjo2LML40upsEltua5O3JbxI70bYmO9lzbbr8epeiJ02TNuiZ+eu+J6PxidEz8pipi4
nXfPjPnpvm/Tbpt0TN/R+dsTNsVM26b7dfyqZ8JiLum/9H8u9Pz0+Onxm+fGJ0/Ob4vTbF+fT85v
7/n56Lipnxm/T467elev4zlm++JiZ+VT+h8YvTbpvnwiLv0X0b9UX2/PTbPjptm2b+rfqub+nfov
XbqubdF+MRMXpv02z8589d/6W3qXNs+MRdvR+VTouInTfPn0l+H+7qj9kumdvF1L7Fr1e2RTEUka
W/hHmb+VUe4LF40SO93njNwix7JhnS1/i2/+bTP+W5/1JnsV2L1+c2919+i4nymL12xOnt0Tpv74
uNz89W4uIu3RExUz4z8Ynx+VzbNsX56belE6beyddsXPjN+vx6PdU26bdETqiZ+ds26L8dds29m5
t6ds2xPZMVOvxifObYuI3bPzv6fnPjq73RE9l6bZ+MXPxi4vtm26dFXExfVv13xF6fj1fHRF6+2J
irnymfHRUxc+Ou3VevyvoTNuiejbpvm3o/C4mLm3r267589Ez8dV+PwnRM2z875858Jm3q29CZ8d
Nuu2bYufjfN/Yi+z/ZYRe3IopzfDu4fkJVxd5IzsgASxHKZaxN31ibRZ4ilOCu7OO/0mSHhslLyh
WbVWZp+IoluZbWRpr+RHdF9Hxm+6u6J12zbFT3z46J1THelfSnXbonT8p7KmKmb/ANH32z85v6Ns
26J0+F675ti4qYnti4mKnt0TF6bdfz0+c26b+jbfET2VN8TPzi5t79PnPzn4z87dNui+nbNum69P
jNs/H4+Exen5zbFXE9+m2bZ+fjou+bZt6U9a5v029Hxnz029vQmfObbdVzfqvt0T26be3RcToufP
o/Po3xVz8dE6fGIub4i5vm+fjPlExPTvie+L0+P6O/TfNvbf26b7K75TDLj/AO5Pmkt3wnuvohgV
9mGPJtr0UhtPbtAprqNIeG9hsb9Wgrkq+BhdQgaHzE8x+oAJGJKaSWy8iRY9laPlOe5VxffFXonX
bNum2bZtm3tm2bZx6bdNsVNs2xUzbPzm3TfNt8/PVUxN845xxPlfnbETNs4++bdfnE6bZt12xUxE
xUzivT8rnwufnNs26L0+cXEzbrt0/Oe+cV6bdFTETNuit3xOm3v8Ztm3RExUxEzb32zbNs226bZt
m2fObdETFTPzt02zbptn52xfZE+FTNun4x3T56bZttm/Rfbpt136b+jfPnPjN+irif0PnPjoq9d8
3zfPwi4qZ7Zy9G/T8dV6r02xM+M+UTomb+/Tf1fjNs39/wAZ+MT42zfFXPjovRUzbPjPyvt03677
Zv04L6k+cX3XbC/D/wC9qZEiqTB0a7fTuT31LgsbCcZfo7kaOiV2LQri0SpiUrsfCe1zahXNJFVr
2VTyIcDhqreipipiNzbfNsc3ETptm2bZwzh0X2zjnHNsRM45wXOOIzpxzjnH24Zx2RG5xzjitzji
piMzji5x2zbNs2zbFbiNzjnDOOcc2xUxM23zjm2cd8VvsiZx3zj7cc44rfZG5x9kbnH345tnHOGc
FzhnHOGImcc7eccRmcc4Ztm2ccVucM2xW4iZxzhnDFHm2bZt77Zx90btnHETEbiszhiMXOGcMVmd
tUzguI3HMzhnFc4Zx9+OI3OPuo8UeccUecN04ZwxW74rdk226L/QTFTqu+fj8bdN1zbqvxi4ubYv
Tbf0b7ejbp8dNvbonRE9K9FxMXfN+v522TNum22L7pt7Z8Zvnz0+c2zbPj074ufObe/X3TPn07ej
5zbbPnF6p6N8VMRM+PU5Fx6KuP8AkCcnadp+8sxkeACscKRKlQmGDApuBLJgANrhAIySscZXsCrY
teFwptIndFWsZGtBsFNrvHKG2qEcyQPg922LiM5qOve5qV7lV1e4SMgOJnhvaq170QcNz1WE9qtr
3qniP5rAImMr3kx0JUf9OeiNgkcroThYkB7sSG9VfCeNrILyZ4r0cte9GsjOfixHNz6eTj4jlV0B
6YyA92OiKipDeiNhver4T2Y2A9+JDdu+A5mMguLnhu38AjUbDc/HwHJja5yt8RVcte9uMr3vx0Vy
O+mlxkF71fBcPEr3qiQnK59e8SNr3vxYL91ritayIr8dAe3ErycfCc5X17xoyvI/Fhuaq1xWoOA8
6ugvYrawi54L3PJXPCg60r0dBe1XVhmoKveVXwHCX6UVUbAe9z6sgkZWmfiwnI99UZqBrTkwsEg1
bUmc1lc96krCDwdWczfBJyfUmGgqwplJXvGv0c/AcAhHPqSDRlScjfBejyU5hIGpKfH1rmOSmM5g
qshXnqiAwVMYo0rHucemLHQNOY2PqiMetIdGhrCHU1MYSsopL2JWkc8lGYOBpZB8LWPG/wChHawd
KY6mqCRsbRHe1tMZ7z0Zo6ApTHa6oIhTaekCbFpiysLSlCv6dkuYKoKZ5qE0fBadkGbOguirti5t
0TPz1TNs2xF9/SvT46Kufnp+On429ts/OfHr3Req9N/Vt026bdE9+juu3o+em3u30b589fnExevz
1/PT5xMTNsVM+c2z8b4voXE+E6+3o/HR3xvtnzhcL8xf82l0Tx9UKqZDkdo9KZpxuY1rbqS5ZFD+
8c6IiqaW5kmuLyj90ZMKidq/T71A9zTymIsKzaiSXpm2VsbumgVAnhZptnK3qmJlfTs4fp1rnWNO
wY6ymYirp1hFk0gwhi1CKdaBhGJQiAJalCS20QyMFp0bMn1TXSI1GNwhabGx1tUNyvpR9tNNjV1l
TjYOrpWY7To3rMphBjwalrjO0+MifQwBClSj5aUYntDp8Asn1KEkx6UTgi06BjreqbvXUw1GmnQ9
y1qmIKrpmIj9PBI6ZVBFGrqdvdfRCJn0eOILKhHTPowSMBRxo7ZtV3JMeoCoQ0UYS29Yj3QKkaBb
RRkfbVjFHVU4mo6jjPdMrQtj1tQjSvo45UdVgFHDUbylqAlYKpjAbMqu9NHVBcENPGjLdVinJCqh
IJlJGa63r0IOoq2CH9FjOfPgDWPU1CCI+ojlx0ELARqd3mOrAFayvjhbIqCFmsrguECrjxMt6x8k
0KAMcZlQATrmC6Q2pr2xw/RwPLYQ+7HqahYqvqQnwsZjQwqV4Zb68J0ZFFHaanK+ekQZWCgDiJa1
JZcmJEawA6oYFua8k9tZB8UH0oXOzirJj09U+vVa4Uhxh/ZgUpIsp0MczFAkVi0ZFn9hpmpEbEbY
0xpsoAPssgsjZb1pLFa2IsMCV42vs4j5wKitfWtWvGdZQVcKtpiQD+G2Tjm9tNU1jwqRd1x2Lie2
Kub4nTf+p+V6fhFTF9G/vnx6l6JidPnqmbdPyq584vo5YnRV6r7Yi9N8VfQvTbPjNs2z8dfnrv12
9P53zfFz8b7Z+V6IvX8enbNvbbE6fjP/AORF9i/3AVEfpQ6LG1EHvMjx+R6OP4wiFa9t3DXlQrsK
2nOGrIzpBIf7Y5bRY1gGT34moPc9Exe9JftEtHbyHLie2Uc2OAlVME8fmhyxs4wsq7IB080KZMnx
2trreNJP5QskTgtYO3iOkJJHxJMCjTXMVho0hjxeWHJ9xDjvgSxnEskSZY2kYGVc8UhiyBNybYBE
yutgSnqUbckTBMZHuoxZPdYiElCa197FbJGdjmeSLabfRoxIkppxeQJMsLgEVtbYDljUw0ybZBjM
rLkVg5xhtw84QmxL8Mo/eY1pJY2sXUQfKaVvBZQsm6iDGLFkocXlCywvxQG1th5ofJFvPtxwh1V1
9Rx0gTckz2AHB1H553GGPCTRsb+qOcvvjY3zBKkvVPjyI0hCh8wRMstRNr8rpyzQLODvZXaQB1Fy
Sza6aBmS7JsUdXqItmYkwAcJOY0QdTmkTFkiE3zRkbI1OUUsUhEC2yCfLPUr4D4Et8iN9TC99tdr
XDp7ItiNbaOMk+x8INTfSLMkmzjxMNNRBRNSSps0lgCMxs0ZxyNTyWz0kNCIFmKWlrqQ0E8OU50U
NxHlFu70tUynnGnR3X0Tv21g6CGgt5Vo6RdRYbzzv49TqCZZzJdtFrsSxbLjLqOYSzLMFCDGtQWL
LfUMmHMjye1DjX8aeW+uy1qU0opov6khvkXdk+ADTdlIsmy9QwoJpcvjEobmXbS597Dq0ZYDlxtT
2pZR9+nx126NX3XE9K5v0+ET0L7584mfn87e/wDU39+v56JiZt126fGb+6Nz4xE9uu/vtm2fnbFz
8Z8Zv0Xrvv0+V6fHReiJ/R29C5+PR8ejfOW/T59Dl998f/YX+5F2XT2oFi5zbMjiGwdhJnoCNX3L
3yJrmFHVt7ApMXvOJ2wDFJRobGQnnQpKJCti96ZTRGhZeX6I0pVK7FwRVCT9Wl7QdRSAumahLNQW
pSxxpqI/KRqYh2RNRrBQuopBiLqwrhRr1YzpOpzysHqozBpeuaUuqzSGA1UaM0t4+QV+rTKOPqY0
d0rURZmD1aYLE1JKYWTqg01kTU5ITH6jkFI/VZShiaiJCyRqeVJVurpIhDviDPJ1XKlNj6pkR0Jd
FMcmqpJBxtQyIqyrw0xWapkiE3UEgT5GpzzhR9USIY3X8hxDaqkGHE1EaCkjUUuU5mqZaDFdFAWX
qeZKQGqpcVi3RnyD6ulHHG1HKirKvpEx/wCsJaBj30kJJWpZk3A6plxh/WpTjyNVTDDi6kkwUk3s
yWVNVzWDBeSIxZ2oZtikbU0yK36xJSTI1TPksiaglwUkXMiY92qbBQx7iUEkm9mTcHqadHCltJ7x
tSz5DY2oJcLJFtJmF/Ulh2gWsiI+TdzJuC1BNjDZZyUNI1DPktjW8uEw1lJkEdqKweONZyY5JNvL
m4y+nx2NnHYaRfWEloLibFYacaST63P4AsDxXSbKVNQd3PjM+oSO5IuJ01sa0lQmkmnkPdeTnsFO
kRnyJ0qXjbicJjZZWlPbTZTBWUyM0sk8krraarBTTx1LLkSsZZTAjSSUZDT5MloZx4ze8QhCWMpz
QyDAUkkxl8+VxY97HOlyCY2WcTFe5z3TpL2sklChDPPiy5CJzVXLnuifPVM236b5+eSej8dE+Num
2J0XPjpvm+b9Vz56bYvoXOOfhPZVzfb0fnrvm+fn/wDlvi5+On4679U6fPr367en46/hffEzbquf
n0r1XN83z2xcT29C589FTbHfBvnAt5YAsxre8Zq96WqMcRHIaZg5tliWFmmPmTn4sqW7HuKrkkTc
eQiObNm4VSuz3TFzbdGJzxsN654j0R4VRNsTOO3TbNsRMRiriiVM45tn5xV2xFxV6bb5x6e6Zt6E
xo+Wdhc7eNCq54ztnCVudlcUedtcVNuiL0YJXY4LkxzcVMXN9um2+J7Lnz6Num6rir7ouL0RcVc+
fWmb4nuvwq5tiJtm/Tfpt758Zv03xXe/zm/V2Intt13z56Ljc/O+fnff0p7r84ntir029vx8qq4v
p/PtnwuL8dPjrtv0X59SLi5v036J0TFTovtie/Xb0belPQ3F6fnFzbPlei9Fz4xfj0O6KuflEz5x
Exc26bYuKnXbN9s3z59S/GLnziJvm39D8ehem2bYq+hPfNscmOwv9zW7rU16ndEo0GEsRqz3UjUj
AqldJJTtGGDSoTC0iDx1OzjGo2kyyo+3kGh7o7aEgD1tQj2WVRxyQLtqqdKeF5BounUcwlExq2tN
22lArX9pUxWYglXOyqZ29sVmUVP5WXNSyOx4tl7S4oMcm2OxOjWb5w2zt5w2zt75wxzdujfmFCfJ
JXaT4jJQixtF98GmBKwunRsyRQbEk6baCLGrvJlSNNDBDmA7RHZ85U1JJxQaTYEdpQo1JUdQu7av
x0MjEVuL03xcTfN/bN8Renvm+Ln4xOnxi9fyvXb2xFxei+jfNunyq5vn5/K7pidE9G+2LidE6J74
uy5vt63e2b++Km+fGb5+Oi++fGbe3znynTbfontnz0XN83xOq+lPboqdN8TF9/Qmfnbrv/S+M/PR
PbF6qub5+Oq9Pxnz1T26/HRfb0L7onRcT4z5xFRcVc/uzbr8+j5zf0b7dE6/j59C+6+nbqnX3zfH
+2H/ALg/3aSitel6ZQDZMc2VUn8wTK1jX30zssoCq9LQb3uJYePlQRCMNHYZGR0EzUifdqrFzTOj
oeHcCRp3Nz4ysI4Z6dyrE4v8y4ezxodWsp66cVWzqrsOhUalGzTu75en9mHiKM9HGIwN8wqDiQnS
iC0yrBv08m1pW+Njm5tgRKQlXppxBu00iZLoe2kbTyvYPTPJ83T/AAZLjdp6+2N+dHwBuXUc18UM
DUKiUtu2VKiuV0KEwnmSyNR9j/oVn/oWX/nWf+Z2Rm8i6ahMBEtJ5/LiD8uPqSO0RdMV4ZZdRRY4
Yx/nonR3xt6V6fPX5z4Vc26bYnRPbPzv6dum+6/jo7Ez8/K5vnJcXPzv7dGrti+65+d98TonTbN+
S9Pz122z3xMX2Xqq5ti4qrnx13zfFXqvq390x2L0+Ou++fOe3RM398RcX46b5vn5zffqmb+2/Tb0
fPRVz56Jn56fj49G22bdPj1flMcvTbFXbE98/Ob7JiJt6Ns+Ov56Jnvm/oT2x3z0XqnT85t606b4
vw/+03yNdl0gv7NRN5Mcxe5pphMVf234XZp72ydKaNs7+Qal3YI1qoJUaU07dTf313tJj/6F77SC
Ln5grtIpF/i2l2CI+dcPsHU8AyBjfOpI7Rj0+VTLbHdGbC/kR79qClaalvPmpv8ADpcLeWoJZogg
6n4ZaXg5uEX3/NCJpJaqoa8NzJPPMNPBpSqYt1JfFyMxJETUDEad2NzR/wDj1X+5hGclrQOYaB7Q
bLUwISw7l1jPsP8Azq13/ZWH/nWn+Vci+x6H/SmvEM1Wu4NVf7AJUkOS1nkx2Lm2+b+j5xPjPnF6
ri4nx6Num3RPfF6bdN9+i4ntn5RM9uipnzidNs2zbr+Pxt6Uz3xfbN+i9F6cvb85v032zbr+Px0T
3z8Jnz12xeu/T85+cTpv6NsTptifObdfx8dPbPlc+c+On46KmJ0XPyvT89EzbNtvR+U+VxvXbbp8
dPz+eu3T4xM+MXouKmb5vi58Yvt039Px6FxUz5zbbq75TqvRc26/jr84mLn4X4Mnum6ZpW1ZHw7k
mDkQkZKr0SLHbfI+TNZ5IqZvB1mPvpGrmDZDc1i6gLsekP8AY1M7d1LD7r5M1sKNZy0MRVzffK9v
ORT/ALIuohe9c5Gyo5kWNERwjXbvIDp1eL796cKlyeLqVf5GlRbJqBndDp0jRluk8tgNPd19zVsh
teib5QP4zFKjocetXzphkHA08TcuoXor4D08LUbk8h7sa7ZdM2jApYs84dfpvmSwjMDIjJwg6hBw
JQPRso5ULBhVrmzrUqCgWDuRFwTuJKK4G6PNrFnFR7aqJeWKST6TjhM7USx2Ryr75v7Yrds3z5z8
7dV67Zt75t6Px0/GbYqbelEzfPnonoRubYvRPfF+V+VzfEXr+fQvxm3X56KnXlnzn5/O/vv0Toqd
ExP7c3xPj0b++fOL0+c2xU9CdV9e3RfhMTpt1X2679duqZ7dVTp85v12679F6fOL036L03xen56q
mIvXf26bdNsTNvSnT5X0fHVM23xc3RfR+ExcT0b45fY3t0juVj6/VBITD3SyS/qpVF5itP8Aq16i
DqxkdF1oN2P1cwjWar7WS7RZz4molhjm2i2DoepEgCnW5JquXfF6V85sQgdbha2w1Eyenc2fX6lS
IhtZDJj9VDeOJqBsQk3U3mZH1iyOGXZ+WSBrAEEcnWQZIw3DwHBrOOjSa1ErbC0JNcrd84YEjgug
6rbEb+uAbWGpXTUrtRJWpN1QksjNaNFHnWSzHdI5XhWBq8cVpNcscwWomtkLr6Pxtr5tlgJKhJC1
oOOP9eRkSx1OSwx5Vcq9Ic58R4dbtAKw1KWxV71co5Zo2PmyDK5d8b0TFzbqqZwxU2z8qnROn5X3
zbpxzbNum2ybdFxExfSmfnozEbiM3TtbJwzhij2zb3di9E/tzbNuqpidF9sXPx75v03zfPwie69f
xt13VOn5+MRc2x2b+v46fHVc3zbF9uqe+be+/XbEXN823z49HLfPznxn59CYnRc/G2fGbf1Nt8+P
Tt1VOu3RcTqnz12674nzm+J0TPjF6b9PnFxVzfqvTb1J09836L8q3fD/ADkSO57oNH3WSazsKCi5
CNAUZhUnIQaXm5aBGp9BTZKPk+ZSvDkOpU+WFf4uRa3v5OqXix41aqptn5jA7zv0+vYZCV5PoCtA
cPbejds4++2bZtnHFTbpBhrJePTvJHad2wlO8byUL2BbEUjyURBhDWvMRunHIkmmcFpmKxcX523z
bOONbgIT5L5lY+Jjm7Z8L8YmfnjvnHOG2I3Ns2yDVEnum0joLSN4YvvnxiJviJnDOO2OamKzEbsi
D3yDp8kxszTrogii2V3t047rX1hJ5JmmyQhvHs/hnHEHnDFZnb9u379vfFZ7I3OGcc2zbptuqMxE
3xWZxxG74xi71elZNgP9EFak/Tj4TazTx7Bf0MTJulnRhSY/ac/N+i4i5y9+idETNvbPz858dd8+
em+fPTbpvt6Ez5xcX5X526b58rm2fGJ8/jpv1TPjN/boi8cX567dNsRdsXE9G3Xb29G/T84nz036
bZvm2+fn8dHYn9BOie2L8/HReqL1ROu+berbPnPyvTfPjFz8b4qZ+cX3zbp8Zvvi9d/bp8dfjPnP
jJGNb76chd972Mro8yy7suuktkx31HMkp7YQKuepiWBlG0dh+2A5piTILTJDrkBmpx7JUWaDx0Zk
wNxG7B3pt0piNDJjvbMjAo1bJtysjRVg+UZaJcPTOYgqt71WlfyfSu4mA4TiY3KCd2DRTfxRS/Jk
SYbEJYia2FWNb584KOi1VU0I5uoxikPkBkitETvu+dsCBTODQke01QQDY0JxH6dpmhFqCuUrpkdQ
uf8AGCTngqgrmhpiOw9Q8WCrnmclAVUNTEAihVHaZL4wdSSkLhk3xcRcYnLIlIY7HUBWI6G5HCoT
Eb9FK156kgsbGVX6dabbUjd4kv8Aa93QfuukiLFHqCa44nj5ui0BzMXThkx1U9jm6cOrVoDPeakK
DA6ekGR1AVFPRFA0VGeS19WRpCaeOEZg9tcT5DHcVQaYklY/S0luS4DoywIazZDtGjjxAoGNONri
JHj12pZ9hLmgGsZNTxasCaunzJAWd+HqBGpKJn43xy79fxnx0b033zbPzvi4q43ombdd+ifHX4zf
Ez85v6fjrtm2fGJ0+en4+cTqvT36b9Pz6fjN/fr+c/Pq29O2b5+cX39HziLi/Pt1XquNxenyufjP
npvi5v0/PX59W/oX0bZ+E9s367ejfE9uu3TbFyQuN/u0ev7rhv8AFkb9zTshWqJdx6hK5coV+5Ja
xR2r+3lA9cNYoN4TNKmqPfAr96p94upP85cX5Gv7tMTVen9qX5VMSlrxoF6ha48djxRO135IRRhx
xsnM1FEQJCfOVP8AtwG84TBDEaU9XGsfeDX+1gb/AF0/1ZFWsuV9GOwc8SjI75yiYnej8XJMrGEC
GVHrJVVNZMHeWwYLbOW2UR+bZWPYORVIycExgRCSa9pwVFWMA5l/FjGkSo8kMp40nadMGU3VcdqD
Pti5si5B/wA9Ty8d0ZhWSYLBWrGtYNBiRbSCwoaWhamDlhU2ov8ASmf3qmJg1RHaZmjkJqYTfH07
XNky7CYOqj1ty21eavGyRvtjeDcnRGFQf2x/s3lxmSRwQtHGa1v1m7YngT/8m3vtmjqwZyXFqlSC
Jq0M5NRzopMhWHhyJeuZEkJHK9aEMRx4Rqtq3HcWEwLfNhnqGYVyviXbFbJd0/OIvVMd6vz0/Cb9
ExcTPlfj0JiJ0VM+PQuIno26b5+VXfEzfEz46fCYub4q9N/Tv74nRem2Jm++Lm2fHRV6qnRMX56f
HVE9G+KvXfptv03zfr858dPzt6vnp8Z+N8/OKvVP7t/V8Z7dNs/K9fjomL0XOWIub9N+u/suScT5
0pKaM0oiSAWMRWFoAI3EtGMfPY2SOrCopdnv2QwyyVrhdgmoCKNtHMeRNTL+yGBSmr3diLqMyEM9
2b5GZzfQRGgClmNVtI7TZXF7QLG4ljkOsZx2VL3eXcf6tCv29VbK8nzlSn8iBukCKj/OnKiLPdyh
QwuSwORGx2S0UDpxgSO53YN57HdjPnSMYbW2E9wTKXlCuN0laYIna1EBZZJtW4CPbsuB+dLf4bNi
+f8A2RYr0UF6J7jso5JhyYzgO0burdVJuOQ393HEbsulIzCSbWW+HGrJLpAJu62pV/iIb3kf4BO/
jV3L6jqJOUWa1e7xzhifOjf3O1K3ePpNfvao94mlxOQ0pfuS3bAaVVfM9hb/AGVNszf+PCdvHa1f
rVz7wZ6fdgVxZ5bDT5oDNFO3zVf7wipZU586gdAbAiJLlP0jHjQ5gP5TdMm7NPAIOdN9oJKMk7BV
T40uEnGHqR28x/zi4i9Px+c3zbfPjpvm+2fC9fyuJ1/H5Vc33z56bZti9PnNs236KuL0Xpv6NvZF
Tpt0Xr+Nts+fTv03zfNsXN822zfb0J0Xqq5vvm3RfbEz8fObZvm+6r036r7YnviJm3Rc/HxiLiYv
vn49Hz6/yub9PlcT5Xp8Zv7ehV6/j8dd8/PT8Insqb5758Lv7qub585IzbIpngdTaiZtZToxMg2c
MMWVZIsiJeRkBGsYjTLZwis+owxtHcCQtzZDkJR2YQpeWQ5GUhYw8s75vakSXGx3vnxlcRjDLdR2
Q22zvqDriO2NBuxkc50QmS7aNGFX2DfMtrgTw09qIIr6xZKc5d+lAjFMKxjILyYwHWepWqaHaDlh
Z4onXV+1rau+/e48VWkvgsbZyUkFXEftlBd9lCSI7kHahemoThetDcIFEsIbW31wOUpF5Kntgf7t
K/4JTQNdcajEIVTfMMnKC5bG9hw4x5XmyaKTFggtrOEURgrJM2kOufRT5WDPWkZYR5A/rMYRZNnE
Us3UEYcaPqFDyp+oY7Y1bfhM0ttBjZJuYpY0gHmmSjNn0M2ErSAzT0uFABZ3cF4YV0yNKZbwZA23
FbBQmqBy7Cz1PG7EHUKFlztURHtPqqGyIupe7INqmIKFVanEuGvK4WfqeEWNcTAyZOk7eLATU+o4
85tNe+CRt/VHb+qKqEPUGoXWz4st0QsnWUyUKLOcCVX6phmEmoaYWXmtGHZSaoE1n6ipky41tHaC
TKdKLnvm2ceqpjfZPz8Jt7r88ffETfFbm22fOImKmJnHPjNt8VPfb22z4xOi9Ns2xc3zfovR2fOL
1T2xcTFxPjrviZ84idd/dVxUz8J85tti4vp399vb46O9sam+bbdN/f8APrX2zfoq7Ji5viLi4iZ+
E6bYmKub79EXqvznzm3Tf39+m/VPRtv13983xfjpv0T43xeiY7ovwmfHTfPnEx2KnQ3xgMj1zj46
rWO0dU8qFidrBVT34lTu5KNyZ9Ffjql2PrXCakBTK+vJHRIanUkB8drmZtjs+cY3ZdsTfFbvnHZU
VzcX36bdPznBVzZW575uuO98TdM91zZcXffdem2+cffb244qbqnwvNcRFTN1XoiZEF3TUyshx9Q8
CIf2e7lmzlxrdujm+6N96S0iQMTV1Vi6srMm6sgkDKeh38ds4e22yb+zWY5uIzbGsRHVWo6+vCmt
K7Ha2rcuNTAsBE+4qDTNts4I7OGbeyMRqrnbTdW4mKNFzjyzjtnBFxE9lYiojOOLnbbnbRcT2xyZ
xxExRoucE32xW74oUxGo3NsTFxG5tvm22be64jVXFbnDOOObnHbFau7G5x3zt7Zw2zhipjUzbOPt
xzbbNt845tnDOGK3bETFZipm2ImfGb74vX4z8ehc339adfjNsXExcT2z89PlV9Hz6lzff0fHXbqv
t03z26bZ8Z89Ez46fOLn4zbFxM3zfpvt0T0uT0fnfPnp+VxUxUzb2xE9W3T8ZvnwiJtm3VHYmfjH
ZIT22yqi98tZTtGG6KDenjhdHnVKELHrhhAFsZZJo8cQmeOTGRBEPNpmOZCp2sNqCGwY6nxlcaAO
QG0geM8ibZtm2+MA4meERqNgkXPHVVWE9uJDc7FjKjnRHIjIjn4+IrcbDcuJEdu+K5mNiudixl3W
I9rGR3ExYqtXwn52Fdiw3JiQ3ORYy54rkxIrlx0dyZ4ztkF7rGc1EjuXOyqudFc1Ejudix3JjAET
O5L3cknPHcTPHVVWK5iIBX4sdW54rlxAqq9lcSIrlcBUXxlbnYcqrHVF8Z+dhVVYzm54znYoVzxn
Z47sWPnjLnj8nOArM8d2dhUxY67NiudnYVM8ZyIgFXOw7dI64oN18VzE7CqiR1xYr8SK5cWM5meM
5c8dcUCoviuxAY6KRuJFcuLFXEiOXPGcqujubnhOeiAVVWM5MSKq54yoviO2SG5cWG5qpDfjY3u+
K5mNiOVPFc3FiEbjYr346I9q+C9UbGVcWE/Gw3qnjOTFhExsMj8WG7dIBVxIZFV0MjFSAVyJBe5X
QXsxkF70WG5qrWm2ZBeTFgvZn00qo2E973V5WYtYV6FiuDm/RPnN+u2KmJ0/Pznx6Fz8YnoX5xOm
3tnzi58Z89PjN/R+EX0fPTb0b+j36/PRPXt6V9O6Zt75v75+VXp7en8bdPnr+E6Jnxm3Tf0bdEXb
p8Yq7omfGbbK7pI+PhdL7eQf9kKyevk6en8SxxMOy6IgBV5OUsjO7Hns8MVNKUpVO1rRtG7NTJ+z
dWE0+7uR9TsRXG+ca33oathGrp1CoSiGAQKRFlrQNKxunGiGWoR0odEwox6ZazJ1Q3vRaJjmM0x+
60qG5Ao2KP8ATHIlpSjCKspWrj9MoRZVEMEeDTo4jtOIRH6eZHAymQkv9PNKMWmGhYep5Sh0DHjD
pZqLZ1DecKgZ22aXTnbUzBJW0bHDXS/Mk+kYAVdSNc8mmELhtPijRodOhJJNNNM1NNjAF1Oj5Sae
YUcbSwg5NqN5EahG4INKDa+2qEatdRDcJNKscS1phiHWUrFQmlmFfMpAR41ZSt7xtMNPn6djxwMp
0dMfpxhRh00AA5NQhZgtPicGLpYInWlW3vwqMLwD0sLu3dUNjaqkGoXaVEUtlTgACqpmOcbTAzON
Rx40SJU9ySfTgzsFp+PFASoQ836CIg4umowMsqxpJkelC8ANMRmEu61vOspg9hNMAU11WhGKlpht
aXTITEnVccEOpqGKY+nQHz6RGix49YhLA1IGQOPQxYzJdZ3Z7KeOSPD09Eiuu6zvSIFSDxA6cjsL
fwUVtNVDaH9NxyGtoIki0FWgHHoI53nrwBiVtSqTZFNHktZWRo4XVjy2L6sEkcWmjREsap8maCvC
+NHo40R17Wukuq68bIrKKK013B7oKKsSMx1JGKSdFYkWmp3RTHpo8pz4g40fUEErSEzbfp89Px1T
r74q9ExM/K9d/R89VXpvnxnz0T53xeidFz8IuLn4ROi/0vdPR8rnxn5+F+fSvrXNsVPfPz+f6CLn
xm/X36fj59C+/Tb2zbpvvm+ybp0+cTN98+MkL+386dJxlK/uwriMrTUcLuEjlaAdkJJA4wlDNIbh
HkyHylrI/YfcFcFlNZqbNRu3Gm/eof2C1M5FwnzvgCIhKOyhuwc0aNkzY/BlzAWQCULtlmg4ntoD
DQpQXCdLCmTbSAF9dMAUayhJk+whjyrsI0jHSBtyfPiDbX2UM5O8PaVLjoyPaQSmacfE8oKM+rQO
+A43MdJCjZFpXjLDkDINTjTJ9lAAtfMjnGphpk+fDDldPjHzm1MmSo42wbaFIMr2pkiSFgxW0B8h
hGq0hxI0txXjOAjXjUzESZcV8csGQOQJSMTLC1gxcrZwJbFe1uTZ0YDa61iS3q9rclTACZEuoRz7
oiFkCGz69A77Hoo1OPaReQgljmaUSmGmTryHCdAmDmC7w0WxtI0NKuyFOxSsbk2wDGZXXsaeVz2s
yRMGJgdRRzSebWo+UNGl1LEHICVCC8gapM1LHilhyklBU4ssb8FflbZNsGKcaLYWwoLKm8ba4p2C
yVYDjMr9RssZDjDHhZTGDbqdpJKGa1iyxKknVCAkAPzCkkT8sdS+A6BMdMD5YXutdQfTB1FoS1H5
oRrYWfgjqL8ls90oQskS+yGFqo1hMIYYGrJaonarMs1DdsbZ4zMsNVFgyYsh5ADsQyX2+oi1a1U4
s8P1SOpbm4JVBpbeRaMLaRQvsJz4wKfUMu2PIswQcNM3jaouTTDLm/p/O+fjPzv79Ns2z4XbPlcX
Pjom/TbZM3Tr7dflfjr+Mb7ejb1J79F6L6d+qdN+m/vv79UxUxOu3XbfomL7Lmy7qnROmy9d8+ev
429uidPx0T4xc2z4xfbFz8Z+d8Vc3XN98kfGQ5job6TUCSh2wE7dJxGy1tXCJXTvICgecx7VcMcJ
Gq4qNNdSEWLQm2kXclOxVxu8cskdcG1sfKI9d1XN9sgX7q9DalOdzNXG7Qr50YsnVJ5SB1YQDFv1
dINrAp2RtWmirI1Kskn6wIggamMB8vUzpiC1Y6OL9TGaSTqx8xkLU6wGk1Sd5H6weccTUiQXn1Uc
7mawI0QdSII8rVx5KA1aQTXX3dkl1kR442rSxklaldNIzWpGiFqkwnztTunpG1e6GL9UmUx9Xuli
han+njJqsxiO1mV4od/4JJOrJEtW6zewbNQcZUrWZ5LY2tCxcLqJ0mQ/WplFF1WeKszUb56i1uQE
cWqpLSTdWkmsiasfAE7VMo5i6xMUcLUxICyNVypbv1mZgA6hJHNK1lKm4DWJozfrzySpGtZRhw9W
yIWStRHnl/WklI8fVEkL5+qT2TRazPGAzUUnvy9XSZga/VR69h9SS5RX6xmKKFqQteSZquZMUWsp
QAtvjCkzdYzZg4mrJcIRb2RJkl1pNkBialkwXzdRSLFyazmjALUEoR52qZk1sbV02CN97LkHNq+c
UVfqSXWLM1DNnEbq6eMUS8kQiztTTZ7I2qZsNn1uUsqXq6wlsi6imQMPey5xn6vsnhiXMqCSbqGb
Y4DVc+IJtrI8mXqewmhi6inV4z20qSVdV2Sig3MutJLups/A6nsoghWhxHm6hsLFsa9m17HW0kx5
GprI7IlvKr3SrabNd+pLFomWJwFk3k2YgLubFEs05DGvrEzY9xMhZJnypz/rtggle4i5+Ovx029X
xi5vm2/T4xVzfrv6OPVU6KmJm3VF9vx0/Cp02zfqq9d+m3Tbbqnwq5v1Xptnt029Ht1367+3z03T
PbPjFXfNuidN826fGfPXffo70b5t0Tr+c/O/T3z8u3zbFwyboqYzI7CYnlbc5Lsd3saSRs0kxmNk
2Lc8yyVO9L3IWSuNKVFcaQ5EOcWOkSnY752xfbPlfjpviYuIuflc+OvzidN+i574nyub+2+6JiL0
X3z4zfdM32zffEXFXfp+Vz8cl23998XN8/Ho36brir775y6e+b474/CLiJvnx0+c+em/XdUzffN8
5Z+d+m+b5vnyiLm+b7Y1ds/O2flVzl0V23RFzfN8X2zfPhd9s33xHbdN/bbNvZufj89FXN+i9Pjo
q5v0VN8/GfObYiZ75tm2Lie/pT5+Oi4idfyqb9Pjpti+3oXr8deWfGfly58+lU9H5XEzbNui9F+d
8336/K4q9Nuq+j8fOLiYvz029Hz6Nts36bbZvnx1XFXE+Oi/HT5xU9vjNuu/o9+m3o/G+2fPTbDY
vzHF3H0tL3MsK8cePUVrTpZ1CNWspubSVjEMylZw+ks3NUN5SKJEEGmXv2dM0MWDD8gsikRRz69Y
7np7774ub58p0TqnVOvz6VzfEzbN8Rff0L74nt0Trvm+fPo/G3RfbNt+m3TbbF9vQnvnz0T0758Z
y6Lnzm+cs/GL023xUXE9l91xE6f/AMlzbpt0+M36Ji+/VF91xVxW5tjVxd82xM3z8riNTdd833RO
nvnx0XN+nz022zbN+n4z8fnHLm/Vfjp8Yq+++fHT85vi4nt0Vc2z46fnp8/0NvQvVV9K4nVV2z5z
8Z+Ns36fn8/K79Fz49G+3X85vi+rfqufKJn5xfnpv74qYi7Z+d+idfnrvi9fxv0T2xfhE9uvznxi
dJHwuU7UdIrQNHDvpL+/T2bu6EDZSFCkIJZLizgryiE5hWNZJIOxzVEkJFfdM4xyEeA1DJdLbqOM
1oS++O9uqelF5Zv1T5z49HvnxnLFxFz36fn4zfNt8+Om2fn4xM+E+MXN/bffFxvTfN8cvTfbPfb3
xMXqq9ds+Oq75v033xfhPbFfsiLt0Xd2e64vtidFX332TffN9+m/RMXpv777oubezl2VV6KvT56b
qmJnLr74rts3zfE6Lm+bZ+cXFXfoi7Z+MXPxi9FzfN832679Fz8dFTfPjPjovviehF3/AKG+/Ren
xm+bYntnziZ+dunyu/RcRPRvnz6Uz56/jfomfn56/HX8r0XNs2xfZdvbp89Px0+cXp+dun4Trv6N
sTPj0/novzib58ej4TffPfOPo39jf2v+ah+0qtX+FfhVT1oXd+qRwQ2m5mKNwZsV3GJYTmuStC5J
EkyjDWW/cW5XnGlL97S/tmpPeObZMcmLi/O+/XbomIm/Rc+cRM299vf8KmfjF+ETE9unzm22b79E
6b9Pzv7dNsXF6b+hUzbptn4xMTNsROn5675+MVMRM+M26KnT8JirtnziZ+fz8dN83xOv4zfN833z
fNs/OJi4i4vtn92bbejbqvRfZeObZv0ROi+2bdNuidflVz5Xf9ye+ImL7dN82z8b5unT4xXZ8pv0
5Zt7bdPjE6b579F+V6L6Nt+i+2J79d+iN6bdN/ZOirm3RPfHdEz87bYmfn+gvVvyqL05YnRffPjP
x89U9Hzm2fHpTptuvHrvip6F6bYmfOfn5zbPno5N+jl3xM+M3z8fGb5vthP7X/MQ3ZLR3TJILKOh
WUkbkeys/DZCsvKyeD7wl4xXVzSH7TAZOInh1pUSVYFTwlH3JNWLxQ31o0uEdurlzfPjNt829vj0
J02zfPxi5tipm2ImL026bbdduvzi+nbNs23T074mKmIu2flcT46fjPz09s+M/Gbb9NsVMamKnvti
Z8ehem+cs+c+MT4X2z56L1TF6b4vt12z8J0Xr+eq7dFzfpvt13zfFX0I3PyvX8Z8Yq75viJm/X4T
0onT5z4xFz56b9V9s3/pp1XFxcR2b7Z+Onxm/t029CLm3T56/nN8/Pxnzm22fjPxi9Ez49C5+em3
v6FxOnznx13z5z5zbquL0cmfjN9s/Pxnzm3T8p1X3z3Xp89HY/4J8p75EklBiaplPBHuixVk3RZ+
RbgsTG6iNybrI7UTWRlwmpSlU2ojGaKc+MU+pTSGisFAY+pzSmFM4qr7L02xjd87eKPNtunFc2zj
m26be+fjE3zbET22zj032zfPnNs4e/TbNsX0NbvnDpt77Zx6cc26LnvjsXp74mccT2zbfETPzip0
2zboufObZxzjvnD2VvTbPyvyubdPjNum/t+N83zfPjF6Kub+ydfyufj8qm2b+2L8L7Z+NsTqmLiJ
n4zfpt0/PTfEz39G3T84no+ei9fn0fOben4x2J136b9PjExc39C4mLm2Li9Vz89d83z5zbPdF26J
i4mJ6Nvb0/jPxi4no3xFz8575858dPjPnrt0+c26J1/Hq29/xt036fnN/bEdi+yIv7fnNvZ/9r8Y
3ktZXuPn0RWR4lcp5E+nUI4NapnHp1agdP7tWi2U1Fs36CqjdWOQi0a9jxfu/Q1UUqEoHPbtm+Nb
yWuqvJVunka11DkyG4Lu2udrZYkTvu/Tn7JsPx3bbZw3ztrnHOOcds4Y0KvWJTEKw8dWPdm2bYmR
YjpLpFC6MJ7OKo3OObYrcRN+jGbrCoSSRyaIgmEFwdX1BJr59W6Kit2Xjn5azOOcVxcXomI3EbnH
OOcc45xzhnDOGKmcPZW7ZwxGYjcEJSLF02YrJ9a6Hjx5wzbNs+MXqmb++L026bdPjptm3XfN+u/o
229G+Jie3Tbrvm2L79FXN83TPnNsTZeirtm3smL02zfpvsqrn4b7Z8+n2zfPjNunLFzl0XN1zfou
fPVVxPfr8LiZvm+/TfN8X26fGfOLm/X49H4+V9CdFxFxcT175v03zbPnpumfOImb+r8r0/Hx0/G+
L0/K5+Pzy3z5zbrv039Hvt+Oi/Lffqi45ML7uis5E05XM7N1YOA2osUEdWeaOPX+KlhZKw1fIeUB
phWG85H5HGhQlq0UssXGLIMsabWT0mpeVqIM7eKr8sXZdNWBMkSHiiwSPlN1BFRXNo1exaFch862
RCesiPc1ileSE5jo1M6Ri0G2SKh4sjVLzr9AXD1DhNranukBXtDDtq/ZxmcXOzfG5pxyMJcTEJH7
LpBFpScUonvZIr3R8I3bFxvzRxGyDftgwyyBSGzmp5VAdI0e/P3sBBfKdKrnxVi1r5KkrCAcyiK9
q0RNpNe4Cvb0Y3IdSWTiafNsaqIHA15Dv+gFwtK8TWQ3GcygPhaMzcbDd3WUJ34+gO1v00ncdTlb
jaI+x4DgrWjI2RT91wdVj+6GvJMX6BITJNOUCPZxxffN/b8bZtm2L0RPSuL03zbN1Tp85uno/Gcu
iJ7qmbZ8LnwmfhPbp75t7/GfK4vt6N+m+b589OWb5+c+cTpvtirm/v8AjHYnTf0ovXbFX3z4z36p
1Tr+d+m+Jn56IvX5TF+fQvT8fGb9ETNs/Po/HTfPxv0/KZvn56r6Pjpt6PnF9s/H536fn874ufjf
ptnv/Q+M+enuuNz5T5zkqYTfC+zoC/e08v8AG1J/dHc7v0RHEZOL9meqpLqlTxpZBtQHJZkeQo40
W0Qjpz+QLV+0jTq/fu/eNL/vX3xibZpxfu8WECxrAsaBTzCIgmNXllwEaLUv4xiyGSHyalOQQjhx
EuxmNIgtKCthDjxzXgRyCAbKjCtRQjgkIsW7umKh3cnOzbB+2aalhelyJniQTMjygCZIA2WJ0i9r
mLHkJxVU3xiZpcDEdJajol2dzCxpOx6IoZg9UCax2mADUWpgpvpqONwS1bJE4oWCGMSFXUsMYhm+
V+asLTSaxseLHNasGScSOZlJXCjxnr+6TAGQFNViatpqCPXESyjzA1FYE82ytQ1WQJbbhspo4EtI
43AiTWTC3dSirX1YqoEGa2ZmoU7sys8eJHLbq19nLiFBM27n42zbExUzfE+UToqZtv0TFz3xev59
uu+b9d/bE6/jfPZcXPjF6/j8r7dN8/OfC9Nt/R+evxn49G/T8dPfETptm2be22J0/Kpn4Rem3Tf0
L6Uz89PnOO3RV45v7J8elFxcTfNt8VM/PX46bY7Nun/8UxffNs+Ovzm2+InX4Xptt6kz467+teu3
XfE9CZ+Pxie3ROirjsKnvHL2yaatB9i0AkhsKJ/KGRsKKGxbJS3iI9apNothHeU46/stRyeIkh4p
yk3hWKc5mn43F97Ka0Ul+7uWJ7rpxF70t+wak6mxyoyTZzCsH5tmRZCH3q1/hoxzZ8sqNGciPiAj
PbNe/aOAn8eSB7rGOu0OSTazjlRYE6qfILYxlivXPnGZpdqoa3TeL7pOrV/gCX/srx28Wd/k+Mau
ac5LImf6VoxWFav7tJ/49SNzTMhrY92FZK0I/FCI6On3NmaKJt/andbvn4RffBI5X1R5MYYJMeYk
ypQb4BUZBs9QWAysn2kxKZ/2NTMc88elNJXTIvEbqj7i6VRWDu1/nNX/AK2ld/Onu+/dryiae/a3
VDVcapdKAwMoM1bqiaVDi7boNNIn5OqiQFyDVlsCTqMsJrm+8WC+W6Vp08QJG8V3xPj84vT56Ji4
mbZ+dum+b9Nt0z5xvx+UTp74qp0Tpv0XNt822zbN+qpibLm39FfQno3z4zfqq4ufjbETpvt6ds+c
X4TbPnN+n5zfG9Ns2z4zf3z567dU6fjpvm/Tboubr6PnoufHRfnbrtnvtviZtm+O6fOL126L039K
e3VcVM3zfN+i5t09+i/HRcTF9sT3z4TF+Fw392+Vk58V4tWQ0CO7D5U3UYJQa+3ZEIXUsY6A1VXs
T9S1u8nVMNyfqiKgXWTVkO1TE8fzBulC1LBiAsbNZJHE36NXKGwhxcnakhPBWX0WNkjUgnnBfV5W
fXKsSWV6kolXqKCMDrmtTLLUaPdX6iivZ9TrEyy1OFUrdSgXEsqt+WOo4whPsN5NTqGPtJ1JCAGz
npNJvt0Z/dp2VCjJLu4JGTpQlmQdQQwwwW4PNuNQRSRpBub1X3bmmZESOp7qC8d3KAY0RW96qsYE
QFvaQSijWaxZEG6hnHcalAIcDUbhyhWcGUNLOsi5qDUCTnEfuuQJKRTV15EkhbMrRrbapjo2p1IE
qeZWb2mpYcUNTqRj3rOqzLK1FBgAiamR0hthWykffVlcyRepMnE1LDZDprsA5NlqmN3I19CkAdfw
hLZXsHhA1FDOJtpUDy71aDtkkKctBeQYEHUV0GwL8rpa4hVo9SajjWOOd76WsY0A+oNTxJEcr+4u
3tiZtn9vo/P4z46L1RN+i/Ge6dfnqvoX4/HXfpv1Xo3p8+v49C++J8ehPT85viejb2+ExMX4b8fK
fGInTb323Tbpvm+b475T3xMX1fHTb3Xpt03zfomKufHT4zfqmbY5eu/TbNvZc36/HTfqnvnyvVPQ
nVfQi+r3XExd+q4iZ84uLi77G+cEuNxXb4mI7p8Yi4q79Fz5z8dN+m2fnjtnFMRPbim+yYnsitbv
xTN1TFRCL2m7oqJitRc4Jnx04tzZqZvm/VWtdiCRM+M4NzZq4jERV989sTFai4rG4i7JvvnBHY1i
NxF2xWouNTj04oucW4q9Ez3xzUdnaamIqJjv3YrExv7EcnPO01Ea1NlTfO03OOIu2cG7q1FxG8M2
R2cUTODd9m7INuJsnRWI5URERfbFajl/txcc1HZ7Jnv0REzboufGbdd+m/Rfj8InTfEXN9sT3zfp
ti/O+fj4z8cc/O/X8YmJunTfp+c9s26fnomKub7r8YielM/G++L7YnTfonv1X1Iu+fP9H85viLnz
03xei++K3fPjqub7Z85+N9un46fGfnqucvbN8/PrVffE9C/OfKqnT4Xp+entnxi++Ji++bYuJ8be
nfPwmb7enbPjF98X2w3zgvlPfp+ExFz5xM9+n5zfExE6qu2J75+c/KLviO6e2++KvvvibbbJiuzf
FXEX2+Om65viL1T4z4zZNkxcRcVc/OfObcfSnyqdN/bfr79FTdcXpvnzipnxnz13xPfF9s3zli+/
TfExVzfbN+n5T3z5xc29k2xPfPnE+N899/n0b4uJn5XPZc+PQnxiLti+/Xfptm2be3znxnz0Vevz
m+y4vVM44vRPTttm/v6PhOiLm++b9PjF+Pjoi4mL1T36J8J79FTfPbPnExem+flem3VOnzn56/CZ
tn4zb0/PT5xc326bdF6bZttm+J0Vc+Om/wDRXEz8rv0+c2z2xOi9PwmL139O/TbovRfhV6Pw3v0F
m+2fGNd0TE6fOKmcuqdFX2Rc23xM39C9Fzbrt7JipvidNun4X0Iufn8758IjtsXPhMX0b4vRPZNs
/K/2/j0pn5xU6b9PjNvT8Z8pt0XFxG+y5tvi9d8TPnN/b877J0/G+fOfHVent0Xp84jcX36bdfj0
qvVPlffojvbbp+E982zbPjPx0b89E+OqrnxifP5zbFTpt7/hN8Vem2bb4vVOnz0XEXF6fGL1XNsV
MTF9P46pnx0/O+LiL029CfGe3r+F9Hz0VMTovRU9e+Jm+L0X4z8L0Trt139uW/Tbp+d8/Oy5vm/u
vTfZE98d7Ynvi4f3VcF/cmb5vnz0TFXrt7YufObdd9s3909067dF98Xfrt7L79N+iY7Num3t1+MT
Pnono3xF6fjbdPy5d8983xF36J7dUXPn+h8Z858p+eiZv039Cr0/Pz0XNts36+/ROnyift6b4ucc
+cRM22TPfPx02z3xPbHZ89UXonum+/XfpuufjNsd8/Cr85vv02z4z46J/b8+lffovv6Num/RU2z8
r8J6Pj0/lei9FxuLipm+fnouIvROi5vi5t7ImL85+M9s36be+3TbHb7dNuu+3T8b4uJ8bbJ0+ev4
+M33V2Nx3zt12z8pn5z4xOi+2fGL7589PnptiZt0Xf0r84mfn8p8L8fGLhuglxq5+cTr+FzfN8/P
zjffPyufhM/PoX53z8p84mL8NTE+f/5bdF+On4b/AGp0+Eb74uL1/CYnX4xV9s/Ofn0/jonTbbov
T8YvwvT8/j1JifO3tn56quyJ75+fx0XE+f8A+XVOiY7N/Unwub74np/O/Tbqny7+5V6r8/hPn4z8
u9um+Ji+2L8r8dfz+eien56OX0Ljei/DfQmLn5xPQvw336Oxvx0/K9PxiZ+ev49CZvir6Pxv0RMd
7Jm3t8Z+Vz8Zv79FXF6fGLie+fnPzi9Pz0TPwnRPR+F6fl3y753z/8QAQhAAAgIBAwMDAgMHAwQC
AQALAAECESEDEjEQIkETUWEycSAjgQQwM0JScpFAYKEUUGKCNLFwJEPBU2Nz0eGDkoD/2gAIAQEA
Bj8C/eor/QUY/wB4L99f+1vn/T8/6Cv+zV+8z+D5/wBm8/8Aa+f9t4/7Nkxj91n/AEXP4Of+24//
AOE+OvHXj8HHXjrwZXXhmen0syYR9LPoZwy9rPoZ9LOD6H/g4f8AuWkZRhGVRgqjjpbRajgyXWDg
tK/3vBlHH7ikjg4KL9zgo461RbOMHAm+nBwWVQkkcHBVFtUjCFE30ZVDaQ4nBaRX4La6Wl0ycZNp
njoyqLZhG03SQ6Rx/oUi5cmEi4oa6ZX4co8LBhCVFyqxuKybaLlX6mEkY46fy2XGjYvcb1Ev1G40
NULcsDSSHQvYW+jdDJtS8ic0v1G40ewnJUUnG0XHgqj8xIvTKEU9puhk47bNro3Q4EtZZM7TscT9
Rbq4KuJaf/A7WEzbPbElsp45R8f7jo3zRSkr9h7ufYuKLkuSOPJbNpgWC0jKyj4NpuSH+HES3E4P
pOBbhYs27P1LoaKM/gSFNmykbhtrybaQ8FeDdRspIcqFLk2UsDZwVjpx5N3sVSr3NyLNvsXyZXRx
4PUrgUboUauJb8mF5L8jjLg7T6Tgi2rFJcm2LSRKWpzQ6FKI1Ln3EixR/lZdDmkbIjZwXwxxkN/u
1Rlj8lV1uuDtTixSlqOrKeWOipFr8EEKaKV7UW1kn8FQKmu4T+TCO76JG73RuXsL0/5TuXgbrJ2+
fYenPPyL7jr2FSxeUJvyOXsKMF+o9/KIoqKyOM+BOrLXsJx4TNz5Jm2CFp6g2LGLG4Oj0tR54PUH
txQ9/hDlp4O9/wCBN8WSafk2sTtkF5NT3NyiNS9hIUvJcSv9wQv3MeUW/AqYjBV/PRs2Ni6NIYi2
OvwbmdzReKKxlllKhm2xPz0Ytw1Fr8ERUSfyfYmRKEfoJi+xgk6JIYhEfuKvYsiS/wCB2PqnXJfu
um5jiW/fpISfg3OODb6ZuVGS5UPaP2OBtCE/gXuIkhk4+OmSLH+6QprLHH019zKimYyiMv1HCkOj
Kx0pY6boZMql+CP3IkvgRqC3Mewh0hXuL7dHZKiYrI7RWRfwbhfYkNSJ7SJkhXREr56agkzBYo/z
WNMQvlk08+TUH7UJmcSHnBg3M2xHPwVKNkpQVEURjuofDwJR/wBwIX2JfcSQlIdGffo0bl79HbwW
MXR9V05MZIt+5fsZGouyxIt+Rnb+GLESjRnkmvcs3CMewlQvYaGZGbkJi+4jZWbFYzgbeBDF8DPg
x7DFR/5IfT9DCFdostSaHuyx4I10XsLbwKJFE0WkSc/YTsuJ3L93H79bohYv7RyXNm2fktrwbYcG
5ooyOvwKyNew/wClsSZNWXAuZFWbY8kfCTEvg2p2XDyPdyNFx9xSmjnyVH2K/lFEkhzgS3ctHPA9
nJ33j3GRSfgxxZRLJvhz4LmbbOPJ2iYoqWb4Ny4vwSUnyPaPHjrRKuOk0Nxi6GpexH3Py/fwSUvY
v/b76JWOZu8ESi+i6/HR0X0v8G0bMiS8FDo9hMs2jMjUa/CtM3NocUO+BPBZ9ing3G2JtbNw4xyb
uuDazebUVJ8lmGbjLG26GlwKyOfAyKKG6LKvJdHszY2Wx0x5N3I9O6LXJskzebY8HOGbuRxjybrK
kz2Glx+6Rsfkt1/kfBfg2qS6RbI3JL9TO1/qO6JUWc/5/CoamYincWhqGDcnk7mv1Oyr+C7NuoXB
xaHTwK322Kdpew4x/wCDfYo6lWdrRyVLKLTX2KTwX4FJvPsVD/KLsUdRjcal0z9InviVF0bkyptX
7lQ/yWz6oxkh96LXAmnRmVSKh0lGTrBjjopEtryWVJ9o+7I/TZGZU5d52vA9r7vb/cPwbVyK8Lor
FOr6ZWSkNPDL8G0szG1+P+EdsaN8svyYicV04tH8JFVt/cYK2lvp2qzuXS0U0ZMFRoz07GVJ9LRt
tUZ6dkju6dplmTBl46WuTE8HfK+lQkZ1DuZ2ujEzvlZZidItyydzswfXgz0qMqO5307XRmd/vMM+
uR9TMOj62Zd9Prl/k/iSPrbX4uOuJNHN9OTlvr9T/wA9eTL689efx89cJmf9Hx/obrBnpiJx0xGz
6TPTg4/1uI2W104Pbpg+kyv+zcUUjJQvk468GUWjJgz+Kjj95hHA0UjjpRkvpwWV/qeD5OChX0o3
NHBwfHRmf3fGDCH+7zwYoZRbWS0iqLkjticHB9P+qyhcIxwVRcqL0zZR3/8AJS22PArWCm42boZK
f+i7TuX4bawbZUmN6eUU4n5mCXpZZtouaNuN3wbku1ltYKmKekNfu+Px9p3KvxZ695KWms+CmvJv
muDbtQlFYZvas9N4n7E5aa4R6b5/7Bn8ClNYMOnRcvJhG+S6J1Zt4fV0jKHSKLivxLA8DSLSPpMr
pf4VEujabkjcxJoujKOBpGPctmz3HKh/usGUXtKODgz03Nfhovg9M3UbqKXBfJ8GMDjLkVIs2G6v
3ixkqX0naXVF0cdNzrBePwRQnVYK/lHKsslKiocmf16bliipJ0z79ElxY5V4H+6pItmOD3M9MdKm
0jtr8CT6JLi8lk8cFRXIoy8EfuWuUW+GZXg3lQ9+R7lwNL90lQt3JhFUbpfSYzIckNCjqeR19f4I
kGuRU+1EnLJJCURRl5E2vI6XMTfZpyfsTdZHGLpElLNRMfukd1I/lMI70j+Ub06ZTFvrnyS2V+n4
EiNrk5iSlCsexUl/KR2EYTeCLr+Yfp4wb7/U0m1naSh/5HqRXk1E/YtcV/2OGLyJxGhZoz0UfHLK
N3k2FlDrpjk7vb8KwK6MD+5x0bhx0kpVdeTFV8fhdeUIi/jo/ZD+3SlxZ9xfcX2NwyX7rczEa6X4
LaK2mFXSpXx+FH6CkuRdLJfHTaxNCrpuPsh/ulu4MewxXwXGmZ08HBgqnX4YC+UfbpIyS9iLMirp
ZNj+w/3eD1PJtfFi2tNnHaSg3yOi4Hd+CJF/BNvnpqEVIqJD7kkRrkX2Eam79CdeR/ulvVxsvTf2
Lcrgf+SEo4lXBenqYNmvG5e45R8icHUjvd/giR9yaaRqVwT+xHcQoj7WX8FYsgvgmU0ar8fu4/cl
txTH3OSKcaIwk1F1yb9Kcv8AI9PU039yzt5K1G/wQI3gv1lF/ccXqpoe32NNvyyMokfuOXwVHk0v
7BT+T0tlk5JUOPP+vx1YukhfcVldMdNw0XeC/jr90P8ABfkSXHXP+B7Snx1r8CP0EvIkSHEfSzAv
uR+xt+ej/dL7HFnbBr7Cq0Vqclo5fS+fxKvYUa8iGY4JbumMkXWL89dkY8+SmNr92/jg9ikbZr9T
3G49LfBxX4IsXuNeCP2Je4pRVv2G58sWTt5E2u1dFRUeJFN+B/u8FFeWb7bj7G2UTdHFFFNHj8EW
QS9js+lvJTJ+4pQ5Rc/Jpr5JbfYSfC8lfAvkco20TUn4HX7qlyJpOcB74bccG7CPV02bNXTr5HNc
oaIqT8jcGrvj8CIx3ZE1aVjixpvwRcROXg58lRfgu3t9iKfhDheWbok0/KHXH7qP9xKkO1g4I6ul
hs2a0MDnwxxIqau2ScPqTqvwQZFr3G6ayXbJ6c3mqI7fBCUvHJFX5JbfaiSkaULzVFL3NyWDUT+C
TXn/ALGs0Ubj4R8jjZZXTgkho/Q/Xp+n4VE3m0ubE0dxfR3zRj8FlG42m1m7Bz4L8FmPBURQbzRu
tGwb/dbTPB7Huc5+Onz0d+xa/BYoydG5M2o2vhm7kwzcZeRspcChI31n3Kjkv90kJcFl+Be5cSvP
TJf4VCbN2DbFnOBNvJ2sUkypsfH6FJ4FCf0lpJm2LL/dccibrPuPaWstFTSsuLSY1yMTRn8KTeBT
uO72HGGDdZ3UqHsaf2L+TZqYXuzDVmHQvY3PUUWVpu1+7Uheo1u9jdGSR2/SKGu+1IxIa05WNicH
TNs/wxaeEZn30drwbhrVl9hrSkWxKT7bOx5ORNeDvvedjx+7UkxLWTc/LHsiOnQoa1uNH8O37jjp
4LYnB1R3yv8ADGOpmB9A/TW03DjrK/Yfp4LFv7o3wXBbWWRjPMb4MwZL0sWW/wDsizwU33Fj2cdE
vBk4sqhlnx0yilx+HBWy6L249j2KkV6eT26UnRl/hwbdpb6basz0x1wzbRuf7vBSeDMsFnYco7n+
4uOCt2C30qLwdzvp2OjulfTDK9SjL/d4K9Q757ulRlR/EO6V/uOT62Zd9MTaRl30w6PrM9K3sz+7
2ze0xL/A1fHuNmD6pHL/ABcdcfj89MHH+xef+0Prgtooz0swcF0dplFJdMGfw4KMIz+/tIr9zdfi
ouv9JZj/AFtJfc46Ui5IuKKZbWDCGJI4yWlg3TWDMTsRtM5+w9iOOldcrBaiY8CtlDfgtrtKoaoc
msHGTsRtfBmKZ4JSj4NoryScKv4Ns+SUkhoSFvSKSibkZWBYVlxRTMGV/uxSawVxWBtnai2jODgq
h0SMIpowJS4fk7fw1VsuK5O4wjgujg+npx+HjplC9jgeOnBx0wj6Tg2uPBxkboyvwRbRdDdGEVWT
K6cHBTMHBwVRwfSZX4IIUjZLC9zs6XtZVGEcYODCMousGfwXRwXRtrpdG3aXRfTaiy30boX9JZxg
7SpcmPcsqXB8jbQmlizOS0VFurHu5JJrBWk2Xqs7cyE+C1KzgTrBTqxlM/LGtXgovwbeYSN75ZKP
+Co2j8x+BSiv0PY5bRNLyjcJxXg2aiz8lrFjj8FpYL9jbGG37Cbtr2M+xa5Kj4HuXJL3IqQ2h/7q
QmvA4/yiFZddPbBZV4NxTLWOu1j/AAciYyrwZRVI3JFeTuO38CQqOUhtG3ij4H3KzjAnQ8Cj7sUp
RNu5WNrLGvcx7HchqPVEY/zdJJPIoyN1G3orVHBdG+imjHI8Xnq2kPrErwOiO/Ns3UbWccl0baLr
BVcFbSqoeOtiVZMxVDa4ZmrL2/4GnH/JuSQmkbWi1EaSsr0ZWfwpWVt2oxw+m28HyO/YdC3dPkyd
pIpe5nkrG4lt4KfLFKY0ju4sdLgpwpWZqhSVV0r4GlxZ3n5ZG+CP2HLihEoo3SKiWykWxxRtfJni
jHTd7FPNl0L1OBU8kWuKEzVtZ6TLhyNS/wB1x+5L7dMLJByZXRdEU+Be3SxCP1/AkIYrE37H1lJn
6j+4/t+C/JU3Ru8j2vBGxjoyZO0h9+kn8lfyjsVj2Mz+CKI17DwRFL3Q74F7CbXgxjpQ9p2nd5Z7
n0OzhofVbRe5kj9z5okyMOCz9ekjD6X+Fv3NpvXJt1MMuJbdxP0IiJbjmKOYse0V+BvrL7DZEvr8
dI/cQ6vo5c0Uj2FuVDr2GqLeEbRRw0bvgm2dvJ34sW73KRteU3kivgeqkbYps3pVZnkWMmPbomP5
iO+ekqGRiXVke1lfBFDcfI9xJo2y4LjX+60bLHIVnsjYXRfTI0n0iMplspZ/BuZSZTeRarF9i3wW
ooXtZL3P0F1V8CfBzgfuWbRvHTk2WRmbbGZpEmuDDNr/AApkcjdotcIq8DoRRijk2WXeTlFJnJlD
2yT/AAK3RVobsTsrwNoTKs3UOI7OS2yueqRFjGVIwUYK+DczbY31V8C8D6bvI8+B0R3G3wWuioZa
9zbJ5HI22SzRmn9zhClHwK84N21FGBSxaHXFcDrFik6yWkkc8FTf2E+1lRKmzmMvuY20dtGTHS3t
b+SrVUdrszwfXEbjOP6EZLgztivkuLgUn4FnAm9qY46Z3Oy4lNU/92IqbyOSGky+RRsr+YyNIv8A
l/BwbYY/Dwex7nsZz9zMLKWD3HijaX+Cq3I/ho4rpjJWyjcbdqkXW0Soxk+gziztW4yqLid34cFS
LRRb6VHJbNl4NyyzhHcWVE5Ll+C0VZ3MtHJ3Pp2swzuZ2syXFnc8/gqMinO+mClPBmQrEdsjulf4
ajM7p307XRyWy0Y1CpSvpiVGZdO2VM+spyMMxqYPrO5nbKj62d0r6YdH8RmXYqm6PrZnp9bMmJtH
1s+p9MOjLvp7H1P/AD1+pnnpyfU7M9PJn8XHXj8HHTg+ln09ODh/i4OPw4Rw+mEfS0cdLSMxr8WE
cdb24OOlqJnphGYvp9J9DKMKz6DK6YiZVdO1WZiyjjBiGC3FlFJHdGuv04/DwZXX6S3HpwfSZVdL
rH7uvw3tKo4KRdHBwcDSOCkdyKRx/oMHBkrpddOC6MlI4/Dto4H+LCLaNq68dLH0460lZuoUH5E6
PBZs8lywYKLZ46X+NJIsuum6WEXEoxwVRdCiotlyRhHFI8D2oUEi5mBuvwcCci4o20KUkWl0qhYy
YVG2rO7kx/8AX7ikXNDahwVRwdsUPGBKjMcjcUU1T/BRc45G4o2ibWCopDXg+DKSLibS5obhVo2s
74xO1ISrBc0mziMS4nGBWolw++DZWROaRNxaTXg2y+kTlXFlVExyOApOJikx2vwJHeN6ZKPt1wJy
wVaPptCnJFdtjcKHCuDv/wCST08s2tV+BIjOatMlt5Rtaqy68WbJKpDnDjpWojdork9PyRnJYHCK
7imvq4L1cH5eWXHC8ilPho2pps3aaJRa4dFaiFPSXJ6VZIy1FwS2LKRFSXa8mnJx9zZjd7G6McEt
PxZua4PSSqXyf+NkfZijqRzxZ6mksJWWcdJb43S/5NV6caah0XtZL/qFtpn5asT0lWLNOc12s9P+
Yc9P3olFx+hm2ayeporl8DTVfvYyawP+UfkTSzQ7WDPT26bawx0juQzJhD/fptZKcUXhFeELBLij
ajdRt89E2jgXGSzZsLaHxfyUo39jMdqGy6ODKFgV8jVDk/LH22fTXS6PTwN0beDFFlClJFCYuLMQ
XJurklNorBgQ9qsUZQotmz2HSM/h7kfCKIrxYn8Eoy8DoiU+OixgteDJaFGJ3l+T8tm6caiOzGF4
6ZyKclZS/wAdOODih6deeS65Lr9RRWcn6DtFQ5PzXgaS7i+D6rPcpHODg4LR6c/qfv04qkbP5Pcu
vA3VjjAyff8ABwPYvBs1OTsXk4yd38MVJcGVizdAmmu6vJaQnHnaS09RX9yTxRH0v+D84Ul9RtjB
icrSIJ/0m9LyKMF5HvXgqhUv8GyY5rDNlcCkm2mae7mj7SEq7rJy/kI/YTO1G0slXO09KeCU6wzu
WS4G2SxZPaXJ8mfYSXuOS4bJqQ3RBafkWnqeWLUrz+CNGkjVd9smKS5Hf9JCcfBtf1l15NSj0pN9
pGaEnzZqS/lbNN85JJeWcYNWnUvAtP1LS4I6hFPDNZ/8myLeTZN3tgQlXknsxkuTvcas/wCaKFD1
Oz2Iz+TZLncNrK3GovOCWpFs04+UaT8EZQdVKzU0pXKTwrIb8JnKJT0s0Sv+ocX5SN+nn4Q4yw9x
rJZsldjftE0TdtwmbX/WftDr+WxLTfKojHUzUTTkuX+6fV/CspcdFeS6MERntZZTLRJ9M+4/36Gx
xsvyzPsPPImV8FrBTLLNvJRua4HXsMuXB/SbeUbpYK3q/Y3QLKXHR/c7i0JCFP2FgbXNlSJH2O0y
WUKUkbWOXSi/kq7Ny+o/QnfuZNyQ1+BEhpFyEWhWKhscbwLp28H3O5Jj2mRSlwVwKPMWJ0Sg1wcZ
GZHX3In6EWX8DJ8dKo3T5H8Cziz5ocXE7UsjpYsyX5JL5IqXFio/Uj9iyJqDUiVfYX4K/mH9hqIr
LQ/c+CC8lMwLceyo7R1kitR0L03fTuEll+4mvYY93JMXsJPgjtPkqJFyRsgyLkrtikuLGvNiUUIa
eRtFOJJv2O3CM+wlpy2n50tyIuH6kvYhR94izg9OUf1JyWCuXRC/cg4iXi/wKLVmm0hxSqhOrLqq
ibGvqXSmjUdWSkQwn9zfXmqNu2tpDNZN0o7hdmw1ZFkdP0lf2Ivhs1/ggpGo1/Qaf3NRvg0ao114
o2jb8ZyPY8EfaTHLzZPRrh8ifsacGsCwvYfzk0vHJf8A1Eb9rNvqxbuzWrjeTlfEUJauajZpasHh
m2Wnu82ylpqP6DXwaM/dcHo7F9xyWLka39jNPeyTjxtNH97J/AsdFJlHwZLYq6YdDyS6R+R/v6KX
SujEfoV0S8DSF9zcjteCV+xS46NJ9nRfK6f+JtkxJPLL+B1xZ2Dsj79HDrn3JFi9y0UL2L+CvBT9
i0W+mGRuTcT9Bv5MGfwuuGYGQZdj6Zzj8D+xnyz7I7WdwlXSo5+xGTjWRfYk17lpMSlzQqLlhEbM
FU+3pSHS54O7kbeaP0LisMhuVZJP4NqTN0uDcenX6j+xUh7BSl0wbF7kbJUbo8Et/k/T8CwNr2GR
+4yS6L2LXnpFpC/sHZ+gqRlUfJu5FcHFEL/pHEc48MluEhbGbtR+aKXNivyyW3FD3ECPvY8UrFfu
fl2s+Ce5+C67ekv7SVkl/wCJ+Wt3yZwJT8slt8mb2IUb8ED6XVkr5JIjsIuTNq9/wJpGl8Jkrjty
YH/aRdWl048mpQ75I0Qj5snuNNfJ2ZyLeqyTjfIpJeLItxIWftGm3y8D1IfUW3zE084se3y+R7/B
qad5kT9xv/8AhoZGvccfknKuSjSshXh2W/ajRS+SeGu437makZcqRq7fZCU/6K/4NKvYusMbf3Nt
8o0Us0mOVYvkjf8AWa6vlbTdH2IOWFsaIbf5f3qhfgtCgXwbCyxouiusvcoRKN2/38cjfTcV8dF9
yr8DZQmMj9xo3WNX4HwUcl7kLPgttDqh0bjbZXz0vyOnkUWb20bE+idobtDoivcqxu7Ej9BiTYm2
jDRQnM7RxRkyNDr8EW8MatNDM+CrwOhIST673yZHRsszkx20PJ7l1Xydoslvk7cFfykXd4HtwXZU
mdptR6cpFuhqLLk+TuKoUl4FbN2wrhm1v9Delkau8G+DryLc0/uNrBtT/U9OfCE6/UcYsr+Vs3Om
OnyO/wAFuhq1wWhbjmP+RtVnopWkPuQ6FxZ9UcL3O3gqQrcePJcJR/QteGVLbExLTNqd4Oe27It7
b+SoG+8m3UklSO2S/Q+BNk1GXSO/HyJb19y00yLXFnfNRZhqSZJxknL4K1ZqJJepeBuOTufay5TR
cJJ/BfsRjqvtvkuGpZyRhrT7T6iS0pDnF0zbrvuoktN/b8MfUePcxKy9M3S4FmnWUPZzRZJaiz4N
ryxyisMi9RWrPNF6f/IpJ8CWom5eTtTRcZVFm3VtqsH0Djp4FPcVrq5s26eEWRjq24IrTVNlsk35
NqVdtGC3k+lr3Q9kdr9xS9hKWm96K2EtvkUdVb0lRnTHHSwOU1utl+mz8pUyM3lIUZ6Gfc/Ljswb
ryJaqbiP8rJKOnhCl8jjrRe4rS7R/uH0fVMa1HmsG9PAtPybmKCeTu5M5O2zdZz09hyNun2jbdv9
8mbdllbKGy0tx9BdV0S9Pgpw29KS3M+mi+n0HFF8lbTCM46cde1WcG4rwcFvk3I2103R5OD6TJZw
O8G5G0t9KKeF0qJnjp2spZO4t/g7Snx0uLo5O4spcDT4LOxlblRk7XRVnJuvJyclSO1n1GXjphnc
+lxdFXnpg27zMrO2VH1n1nc7MSo+vB3Ssw8n1YHkyYlgpyx05P4mC307Z0Zd/h7XR/EZl30xqNHc
2+mJNFbn0w6PrZl30+qR9bPk5aPqMvpy7OenJ568Pr5/B8GD6X/gwjKfT6W+uIszB/468dfoZ9D/
ABXtZnp2wsyq6YMxfTB9JT6Yi/0PprpjJmFLre0yq6dsbMqumD6GZ6Wosz0wZXTBlPr9JTx0wjPX
Cv4Mqul0ziv3L/FdFUXRVCZg4OCqLaKLo2l0V+4X48I46Ujg4KLLPk461046cF0UYLQyvJbOOt0V
RSXTKEqE3jr8Dft0qKLfSvJbRcensi10pFv8XwY5ODai2zBtLkYRXT5OCkrLkYOBSkqR2qzIqyj/
AMjjAox5N0y4qyi5YR2DTRRdZMLBSyxPUwXFFGVgwjgVIW9ZLgsG1cieqsD2LBso3aitn00y4xob
ku2J9J+VHge78CRco2boRHHyJyVnaslVQjugi4UKJc42NxQ4tcFSgmdsaEkuWd8VMxBWb40kNfg4
NzVmxI7kiqjZujT+w4VW0SltN+m7+xt8ici8YiODwrISbi7RS9OzFMlFLts2ypM7HH9BWK6/U7du
74N8UcDteColi3yS+5UKY64v8CtG1ru+Tdprwbdp+Z5RL0+RRrl0XNGy8jnBYZGTWDbPk3aSNrWU
L1MJons9vBs2m6aNtZN+muyzc1g26hu0o/JsojLUJ7F4HCsFzR6fMpEp6S7RSaHHU5FLQxJ5FptZ
ZGWpx7E9iykbNrRc14sUXHLHqaS7LotrCY4TQtTRXuxQcabIy1F8E9kc0ODQl7m6UbaZOWmq7jc1
hMktWPDPyfqv98nWDMaEuYmDgyiceFE9j3PucEjCLZSXgeP320VmxcjpYE2sm1otI4wcIdUYRdGy
u5jkkbmja0htKxqsGUSSrAklyXRsqmWuTfJZKpMbSOO3o44MLkvybaVm6huSKwYoS8CwbENpF+Ta
3yXRJyXDPgYseSz0zcjc1kzRuSH1jAVfqeng3Icq5K9j7jxgwOBg+RQ8sbG2ijjkWMFrB6ZZaVG0
bJS25vnqsC8Hpn36JVZuHKihp/YWD2Fpv6X5OLLoSSsjL3RJ0extmsrBGVD280KNMTlzRqR+mitI
b1Xmiks/g4wYRt1Fki4rlnGRqX0iSWaI2sCcfBNOrRdEa/ps9PU+pk5C9JWz87/kTHpwFJyZXmi3
iLOS4ZQ4tG54O3gz7ktnO3BunuUbIX7E9XzdmyP+SSkvBGRHuV+xL+0lJCg0Re6RBWaskP0o9rO5
Nlx5Rta5N7bJw+DvdDcenztE9MipkPi+sERn5sw+xPgnvz4JLaR9IhCYnX8x2Ye09RvBp7l/KTaX
0yHGLpcmpuzgXaiPpyrJtnxORJuObFtx2HqSk6TNByV+TWxWcDhB0mTjPNRNOo88laTqmVqeZGp2
mm15gepb7WaTas/aMecHp6bpMlGeagaLUfJJQbjUjvlakzU7UaNYbgzc5fSzScs2z9pwbIvDROEs
7YGhhcmr6Xa9x3v6mauO68MtrxZCPuz43mpjOCWzOmy2m0V+9X2MFo2s3DS8DKLTPkplokulH6fv
smMYE2yLGyRnNIf3K6Ix7G4QxlGBroul/PSXSi0UixDHLyV1a6foKfRjb9xol9yh+xEoTEMd+Db+
Cz9BMQx2V7dKYq89KN3Lvoy34GkIoi0IobGMSY0R6JpUIZL3JEhX0X3P0EyIyV+CQymJLyN+wo8P
5L7LEvBOvfgUpcmC/wAFYskS2i3Z6M9yI7JbeDIv7S19Q37mXR2Pd9jApSXSKvHBGRtirQ/UpfA3
7leChT82Pd7G3dbIVwSGpGpXTA/faP7iRuaybIMkzbq3ZiNqhbI/UKU0VHkyI1H8DNy/pEpxsTgq
LfD466ZH7mpFk/uS+xDdxZpuJ/7Cf/idv12aX9pOv6iUXV0a1ES37mlsH9yD/wDAnD+azR+xrfci
pUaz90aftY78ujR2kvc0v7TWha3bjR/U/aH7MhGf6mu1xsNH7mrJ+5obP1NRmj/Ya8ccmgvuftZp
qWD9pkvpcDR+5qyf9RoODs1ZM0/zVdEXCalkipNK5n7Qej6ak2am6KxBvgioLElf72Ium54KGyi/
Bj/Bn3JSQleR/KH0/T99QvsURQyj9Bl9fsbPPt0kL7jb9ujfRdHERIz5L8dLPsLo4jsZaFfS+iJF
VgbY7HJdEWVXkXS6MmOsF02NdGX4LeDkwK0IwbaHYy1wNsWS4+xE56ONPJTJKy4m9kTHsJVwyPTC
tD3DLiJv6RfcVCT9xFWSaVpj34dF3g3Q8Cl4JIdcie6WPcp80S1GvsUN+PBUvwL3Jf2khffpLpDo
xUf+vT9C1fAnLgivcctvBtUXRGfsJebHUW8m7gw6K3WJy+o2y+mySj/QU4NL3NO/6ScL8nqw/wAE
92Dt5LccDrnaiW6O0yam0bk/JP8AQ3Qg5FSVdvkgn4Py42zuTRuzVC2qyafsLbG4+41/4l6cWyCm
qfyQS56xl7ENNPNm9XtY4SZLK4ISjykRc3/kj3ZsajK7jRm6ILdlIcE8uR60b22STL3cI06++C5/
ysec2VHPbRedpGDfBqQv6mPWXBK/MTT7hP5tDlLwySvIoRd7YG6qshBv6TWjf1vB60fA7fMTSp4v
JcP5mPd/K+TUjF3IUU/p0xXlNkdN/wArZrbX9bJakHQ7f8lGk1wmLZ/M7J78bHZqaaeWUpNWaW5/
zCr/APeWa1fBcIWvc1U8P0yDXFfu30UbLRGPixSNvIyWDavYtoo+aJLwP+0SLZsT8fvtwkvCN+Db
5Q1J8im6wfB8Hx0wKNnqYs22NMUnR4L6XaKiKJvdFJmROTXS179NyKQot5N7ZVmeBO10tFWOSaNp
teLFNuxpMz9JbayPbgwKLZuKRTfJcqZj8G5ci0zd5GkS3cPg78naYLbLibUbGzf/ADG1My8MTlke
0Ve5l/BgcUxabZuxY0mWyO47cCrCTEmWsMpM9OTL5GkxS8FyyXHtO1+TbJ0X5GkzZKVlvuHsZvbF
uyXHA0XJJsxBRZtiNPLLlGx9qR2efwXWR58DcTuKwkN+TPBGVfqPKHQuLOVwPbVlSFu2/qWtq+xH
4Zlo3flmNvHg2SLuA6cP0G0R3Fbo8m+LVplSklSrJe6DIxjK/sXeLyJykosS03z7Ck/BGXqRRW+L
HskrM+5NKadrpUn2sv1ENwnZGbeLM6qZ/Fv9CcNKalaK1X4P4qSP4tkmvosX5n+TctVWP2/ApXhe
BXLvoezg3J0xrVlVKkVpys3C9V9ln5d2e6FngS1b3n5T7fktM26+cYoktJ8lnc24vkuKaY3eCMle
CtRd3kShhF2VrXPGCUdJONobZlui1F7hu8MUr4Ns493llQtI5oUdSLmiS004tqhtl8lrT2yJO+1i
kvAoamncvcUY4osUdWLcKJLSuNobeRSfg2y0+++RJQyNU3HddFvQK0obMGf3yWo8EZx4PTvKHMcX
yW+OnsWUslo2q+DcbUslv9/zgcfTp+5bZaNrhZWUizKtFJNGTDMIvptcelnuVtLMG2jLLPca46Yy
cUNtlo27S7LRXJnBZgrbRktG1r9euH0tnaU49a5/FaKM9KvB7dO1lV0tdM9NvPXsZldLQlZksqLw
ZfXBbMFWZfTDKfS4ujMjLz0pPBl9Lg6Myvo3GVGZFtlRkfUfVR3O/wAHbKit+C5OzB/EdHNr36Up
ujM+mHR/FZl30+tn1vp9UrPqkfW2cn1v/Jlt9cNnLZ5/Q5lXXyZ68Ppwz6WZX4cGYvpwfR0wrMab
MwaM/hxGzNrphWfQ11vYzPPTEWzKaXT6TMGcHbGz6TKMH0YM9O2NmUzBiJiBmLXTCs7otfgwfQyn
17VZ3RpdMKzMeuI2VJUYR9JbWP3/AAUbulorpwVRbRt8l0UXRn9/QqRnpwcdKR7dK6X04MFUW4nB
x+GkrLZt8ls4OCl0qumEWKC6e58m7gy0XX4FE5o5yN8jiey6U1+D46cFRVlyMFG6SpDoyYRfk4FG
jc8HaUy2qRa7h2VFGeS6KrInqDcENMtx7S4rJxgqKsz9RcUbfInqLkfpo2tGV2nZBnFIpHeOUUbP
Jc0XCGSmcFyWBtKhRLnGzsx+GkXKNs3QRtfInOO5GIUd3AsFPTyborBtXJc42XBIafB3aSbKhppf
JXhsuSs+hM3wVfhVG7avYekuDdKKL2xX6m+H/BwLEbN0K/Q2NZE2YVUh6b8EW0niyq00fyIx+Bbj
djgwIbnz7G1G5oSk4L7lR/4G/wAG2hb1yiXp8j0ze1hGz+YtLFkcciWpg9TTTs2PwRlNYaJbMm2r
F63aVo91m5LyfmduDZHufwRlprnIpS+kUZrg36K8WKMkR9SP1Im9NZ4NRai7UQf/AI2emsv4Nyh4
bJafyQ1JRs1Yx+qMR6b+/W9RXZLbDiCGoraq6uM43SLUa/Ls4FLUjyT2R7vBJNUrE3wQWzlkPTVN
zo9SSvax6MoZRquMKqI9N/f9xx+GPsW1ggocXk/4FgyenSrkuijAsFnBYopZHJP9/lHA2Rj7s3UO
NIwKTRTRdq6PgVowjg+k4LdGUv0PoaR+g9scHBwbaFKSHglfCOBQ2fqX5N1GVY5UKPuJeRllpDWw
4wcIpR5NxUVycHApS8M8Cio9pfuUWOJjrGPT03Vsbo3NGTi7OMHFIcDgsUHVs4NzXTC/QWBVg2YH
jkxHNclM3V4JOsdOKF2mFR6djlRdfqKPvg/QbcTBVfoRx5L4Hp+BtoTowXyXtMDjLEvYtIcpryKl
Q/c3UVBNv7HfBr5/DVD2m2f6o7F5FimSjP8Ah+BJLlC3IUo8fBK6ZcV2nas7Rx1V3EmkhPSVryfn
KhSXgenp4kb5yf2KpPtHJ8Myxy01ZUoltD2mffJqenzWDu3bfcgn7Dn8jhAlvWUjHgisN0T+xL7k
UudhKnLb9z8xyr7i3RszCmP04nptEXJDj4EytR7cEpR4Pgl/aXpM26nKiKvb8G4jX9B6U32Xybo+
5Je9HqxlVcENP+ZGna4ZL03TselqXxtHNeTTh7RJQk+2Ujd8EUuCP3HtdO/AovUcrwWacX/SOUcd
w4J/lmruzVI+lZRp+k6yQhN3bNSSWd3Jt9R8UKdEVL+hocl5bIQ9rNW32zYtSsUL1NqfyPbKJHHb
uNX9DMkpDjnbeJEcYZylIfxpGla8iWnKqZown5lk1Kj3eobtTCI7Gsexo/8A8yya92iWrFPk1t/N
Fx42/u30iSrFFii2XQ6HJ+RDaKF9i/IxmHwfNEv31+5+g43YpPo3fBH7kSxxss/QaQjJgw6M8C8C
04/YTaKlJDpm+hV0kxX7dEMdlCkja8V0tnI8cjaXRSf0lfBu5o46WkbUxasyrot8dO0z1gL7G7zZ
RIplIsotC6bvPv0fR0LopH6DJDRJdMEfufoRaXkXR2hj6UL7n6CkR+wxj+OuDJ4MMYzKT+59KQ6/
Bwh/Ybi8i3CQ0Z4Isd+xUeD2P0McjfNnfKi4tP7CpeRTaLtEY3jghJcjjtTQ7kkyTfIlH2oojJfV
Z3YwbVO2Rr26S3cmpQzPuan6EpezEpT8FciajVksZTMDsjtiQaJylyOJD7kvkok/grVjZu01Sou7
9vwbdvg3f+J2qiPm2TksEtKsiNOG3uvkysDNrVkZe8R4zFl3/KRezdZHt2Wep7vghKKun5NvpKBp
SvO2xr3kThNpGrXEnZ+hC/6smjKHFkvmZGuLM8p5HFfT4IR/U05+9jXGw0CG113EWpbl7MitTnca
32RKH8qXBo71dKyckqcZmtpeIsT/AP4RpEW/Mj9mlHwTvjeTcP8A91Zoyl7GjHxuHKPiRL9m28Pk
175JaceF+9z7k6GbmUNj+GRfwSii2J/Bsb8jY66V8Eq/fbfBfuhtka9y/ga/lLIkuleBfYdi+x2F
z5NtcnA4wINryfp07foEpOhZ6UdvsbWKQ/sJVdmfbr90OhEYz46KPhsTocV0ydt9M+C1gavBDo1+
CBgkvkyMtFvC6Nrk4oXTjDY76Ki3gRj2EL7dGh2PJcRMX3Mewl5sQ/t07hm5eBNqkK/cx7ChtfJD
7FIuriPd5OTs5Qm1SHTNvkpcn3HZUXQ9zyjHlfgXsT+wxV0f36JMVcdEf+hb9y/gW1eBb/8AkhH5
LS4NqhULIz9jTXkxFtX7G62ik6ZHyRk+WbXxZPb/AEobem1kh8RNvyerBv7EtzyPaW4+TUpZJJxc
bN0bkRjLTf3NNfBqZ8n5ONM79SUSEZytkdis1N2JEnQtkbHGXJKahcb5NRPmi4RtHetvb+HdRKv6
Bpka9ycX8Dl/L002+DBnk3eCK87CdryV/wCJp7c0ae8Wmvc3RjTG5oi/aBHS8ti1qxZJN0h5xRpV
4yiDeKeSWms5NP8AuNXxnnopGjH7mpf8zNKN5SNPZ72R9RLJBr6d5rfoS1Urg1yaP9pqU+ZmvNrt
fDJ7fGlRHT1MbUadOvNicn/Dkai87hqP/wC6o04yxg/ZZ/JS/rJaiXbuP2i/gco+37t9Ij25MIUh
xTye+BkYl0L3P0PiznwNCl5NpJ+/77cV8EkL46N2JEST6LU6MjF+xyc2umGW8/JdrA4l2eChXx03
WJG+1ZtNrwKbrHVSsq/BuckJ9pfsUX4s58DKZ9WC7KwPwvc58DoV8ISsb/BaFB8m/wAsaHfDFuZ2
tGPcyzHJtFCXJvGW32icmjtZh+RWzHI1YoSeTc8saRulwy3k7cCp8PIrZcSrNkmW1Y6ZuvB3OxtY
O1+RRk6pHz7m1Pg2yZbyzD/Q9S8CbyXHtJJdIuu73HZKDfwZhuHS2j/BbjbJFx/wd/PgSwi1RXgj
weC/Bwmx8fT02Mztf3LVIhnB/KfyMeI8Cg2i+wliI34FYlujg3xauynKK8ZMzgbYO8Cz23kTc0mb
YMuTsg/UXHBXqo3Qmm7Ns5KFF+pFiUJWVN8szqontmpYI6vFEd2pT9ioyVMltnumSjqz2UsFesVv
X3H3dkmfxT8vUt/hrWxjDNu7wbtLg3SKt17D2CFGVqaZtySawmR9ZPb7opXwKWktpaYlJO0XBPcb
lKldla9uZ9DPy3gUoijOD3HbhFpjhqwcsYZKOnHaWyPbuSZOC8u+kd0dyRXpMU4qqN1kVqaV0dml
QpXi7onGendn8FEdi27SO7ugnbFWnTRrQnG1Lg9WHb8IcdSG/BKEI7dxuvJKGrp7rHKGntkRg9LM
Y0Q7d0E8o/gE1pw2bkZ/fVJ4LXuSh5ZvKo3NYPj2MRotKjbfg3Hp+Tez09r3f1Gf3/Fo+guqLNqg
NbaEbdtlbCzCs27C2XZ9NmIjnZW0rZg9kWjMT26Wjgt9MKii7K5OSxR2lV09zg//AKFm2hsTK22Z
il0tCXS0VRlU/wANo2vwc9NrdrrhlFlp0VyW+uH0W19Mlop8dcZM9cnPSvBlmR7WbW+i2yo5HbOR
R3GX07WNN9aTwU5Fpn1ndMdv8Ha6K3Ft2XF5PrO6XTtnRTmz3O2W1lb2dxgxNmZM+T+Iz65GZtl3
TM6jPqb6/XKjLPP6HMzkwYuzPXyul7ZH0yH2tGD6JGU/1MKz+FI+iRW1r9Pw/wANszGn+GuS3ps4
6WoWjujXSoqzMGumD6MGelxhZ3KunajuiZMI+h0U+lxVluNdO1WZhjpSMQtFSVdLSO6OOnaZ0+lI
vbgqSrphHdGunaZh0ovYd37/AIFeC66XRto4OBY5Lo21k3UUX/oFRiJlFCZx04LoqhJLrRdFlHwN
89FFH0nBQnXX4LXTakWzjpu8deMGafRRot8nBRZaKNzPBaQ17GXgtGfwUjdIuPA0Xwe7Mm1Itjxg
o3SwYNiWDuefk7ciSjYnqKn8nJaRSVlvn2MLBtFLU8lwPTMmDco5NpepwPah2cdpiOS6x+BUjuj3
FwWCvJu1InZGqFCSMRyOuvGDEO4kvwUhOcUzdpxo2ic47io6aszwVQl6aN0Uq+DauS5w3FwSRLeu
Cnoqzs01EUcK2XKKkUtKNm6NV8FfgWDhDgd0U/uV6cTfHCOMCTin8m+CujbWRSmSaQ4vwy6iYWm6
MRh+huaxZXYiVVwbJtc+TmB/L+hKcP8AHXArQovb9mbtNZKfWkbpo2vn2JT0lgzHgqeBS08tnptZ
sTmsjjFW0jCwKU1g2+fYlraP0mY0kVqIfpxuT8mx+4nqIcEr9y4rtYpyiKD54PV0v5UPcsI70S9K
Pc8I9Lbg3ThdGxRWDelhkNSSwxQlH4JT0YVsRtkuBb4eCXpwVywjZWL5PzFwLSUUjfBWmQlJLIoN
V4Ja2nHOnHI93jIt8VmI/Thy6Q9OvNF6kcoWlsXuRlGPbIhqSineMihKMfY9bRht2pXQ4vx+9SMo
2IrmkdqwZXCIw8MuiXwLAsckZUO0fBt8jkl++ihSaNj5LSLkjKwXFYKrBwbEkbqN75KlyOSLa4Mp
DpISrk4NlZZaQpNG10Wh2jgaSEq5Ezb5NyN7WTKLrkysI4wNJCxyYRtocqHJrJkuhYwjgcVRuo8f
YjHbj3LHHBxZxRf4I2sCdEjHlmDa8DaHLyZQ/wD6KoTocXgbRwZjRvZnIobcCLSNrLq8Dm19un/7
D1K6bfk/QXtZF14JR4owcUxKsPyP+YtOkZmO3uQpVkpDfKHKjA4tG/yvJn2LMiFayP7fhWLQ9q4R
U+fYjs9xOsjUsIX2LlEjLwSQ5JYO3+k2an1exJrk/JVj9f2Iy9jbpcm6eETTSeC5XFH1Njlp5SNr
WBdM+GTWn+h+Ze2xJ+xuoitNOrJbuiVptmoyf3HGPO0k/F3yQ9WT22Y5HLTtx9iSnyKWnk28IuTb
VjS5YnqRsr08m7TiSflChpD3+Ii29VZBrzE3+IvBByWXyftGOBQ03SZs1M1EhjNmp6fPgucsSHa8
Gk0s0WpdsWd6t2a+PBtg6sWnP2IPb5NT08Mc5S+ojj+UhXJ9T2wY3LPdRq4xsNOOm6TwQ05vi2Rl
WdxrR0+3B6k5vOCFr+UX9x2yexOye7OaJdv8pp+nKvg04T49hdqu+TUUcPaeo5fFmnhfQhS/8yXc
9m60au7OUieElsZoRg3+hpachOs7jU2YltPVbeeTStf/AKshX9ZOpPD3E7/rP2jaqV/vb8lR9iTe
clWXRgv5wUOSNjI9GSIU6M8kvwV+5h03fI10w6KGykJkRsbKL6Z6psQ8DNvwP7lDE+iYhoZT8DKJ
Eein89H9hm3qz9Bq8CxkdHIt/cVBUP8AAn5P0HtIuXBgtcm1kaJDijcxfI2hex3KztVDO8xGmIyN
lfA+nsSfsVkU5G2xv56NxwQb4svjAyMH7nFFOWR1X36fI146U+BVgl8kja+S+DwYf6D+xf4ZMe3B
FMSGL2FXFdHtfbZXkf2JV9RfOOSpNIbjk3IUmsdFH+UjL3OLR3SjGyUusWvcblhFR1NzMewidk6G
z4s1fYlP5O6ZUWxPblqz4R+ZZJ6f0mWJ+D2ocf5ER/tLKkalFSNSuK/AjS/tNRebNM1iCkTcfMTT
+5qWaewl9jS+xqrFn6mr9jSUvc3R42s0/uas34NLbVn6ETWg2hr3ka39ppb/AOo3R4cWQ+5rSf8A
KiMU1ZD+xC/uNTTbXsTfvIn/AGGnu/qIOJH+41J+EhRXK8Gn/wDy0JL+s1ISdeET+Zmr7emz9nv3
NOa4aI/3GrN8JGzymaf/APLRGv6zVi342j/vNd/P77/1GX4Eh0JfJZKIpNcsRJX5NwyLFZL97pjF
H3H0svnpfwURJFH6GRsvpZXyJDEujHJFkeiQulljLXSPSjI0UX0vkv5H9jdEjHnJ8se1WY4FKXP4
Ujd8DsVe59vwMbIUI+BFxY93N9N6IKTtEWxnwzJIuJueCZkb9h5ERJff8ERv4MIW/EDa+TGUx7uW
cjceSMmMkackR/qJLwRj0f4PgmvglZCvci3yPor9hfPT7k/7SSZL7Etqb+x3e3khHkusrwOO2UUs
EZt8Gl9iVab5N9uL9hxTFWSDfLKlx4NTaO4UrP8A1Ir/AIN2nw2UyWzlMTcayalK/gcZ4s3abcjM
MEL5UR/c7YNwsmnjgZb8RMPBbFXOwlulJK8ULUlqSZKF5Zvhd/A97/l8lJp9VJkYp29p6vdTIxbq
jVi3yzfDx7HdjHkh3D253Du8Ernn2NNJ3g9TNN2bZSqjUt88G6PJByxSo0435NTblTwOz9CEFyes
vpbtmxusmpnnBBpcIjJ4ohFc7idfzEyK9lRHTvN2f9RxbscGaj8basg14Rpyf8uCEVzuyaiXE8E7
En/TRpaX812LVUv5rJ6bfyan9NUQp1tRpyf8uCMEre7LJ1xLtNW87iK57aNPS+bP+o8uVmpCT9mi
eov5v3L/AAMpZqOSxVyJWfImUbhe48nxY7GhSY4EpfvVI2+WKToopl+C1RgovybSn5N8qx1+5yYF
E3Ys2lM3Mw+mWdr6bbNxVlNibplGPfp2io2t5N/kqzkTlwYZ+vR00bbLbRu8rJV8G3HSo4Q/wb3y
JWNojf0lX0rwLOSWejnIQ6FC8nedpl4FfdZuUaYkmbJPk3PI8l3gtswOI9xIZchD2iTElj3GRa4s
gm7wXsMNL4HBuslvJh/ob7pCd2NrA4Ip80W47iuBsyrP0JNfgT22/ckNrn2FuViXFD4vpHCQ7Vjo
ukx8ZRaHCfNYPpTY+ImmO6PpgPjgjFl7oGVF/YlKPBFe7FFyjj5ISTV34MyXNZL3wGk/AtzwJ3Hi
xqH/AAb5MjepDgzOJu02m7GptQ8F+tE2wd4Ix1JeS3rKyWydknyShOe3tHtdotOjbqz8UfxTbpST
Iyi6V2z8zUqRt0p2Z/B3PB2ye4e3gUr4K1W915K0nZu/mIx1t21D9O8otnODzZjEfYTT4Nuou73N
mm2XeSMJXKJUY065HbLvAo7cpGH2iY46um5P3HHT7cl3khuuaRcdLYxt5LQovSqVVZ7ITTHHUhuH
CPb9iyON0V4MQpls3IUHod1cl/y+wmicJaW+/JKMY7C28kMboxdmNNJ+43ZgUHpdyVWbnjxX+gqK
r7leaE+KO4sxHB9JizZTN/k9Ojczbtbfj4HKX7+0Vtsu+n07j6aLPc+l0Wyzjcx3gs90exd9K20Z
6U1fSxeel2WiqfTkrk9ui8lHJg2uJyWmU8nsX0qqLF7GOOlplNHH4VSsqi2WjiimunFlbRswUWy4
umVKJwXZWZI46J+SuTnphnsZLRTwZ5LRVfoZwWhJKx3gsxko7sdNp3PPTtKfR7GcmZdLg8nwW/wd
stpmZbLXJ9Z3SvpSlgqUjJ2Sof5mC27MH10Z1LFK8o/iZMzaZ3SO10fU2Zm30xZ9Uv1OTF/ofVMy
+n83XG79DO5ffrncl1+mTMqunbHcd0GumI2Z03RlV0UvTbXud0a/D2qzOm+lGIWipqn07I2d0elR
yz+HRTVGDEcGU107VZnTfTBewqSp9LjHHud8a+emImYuumFbL2lSVPpcVZ3RrotiszHHSoo+mzbN
UIuMR7o107Ud0WUWjg7o1+/4LotDs4NrMrBhdOCqNxk4M/v0kZowUX1x1pF9KL8HC6KutGTBRbWD
BRx1pFvpQmz36UkX02rkuRgovhHv0qsdOCooUpvJcclfgSijnJaFHyJzLRTLaqJh2xlJCzkwiksi
ergexWUy5YiY8dNqFa7huKNvkvUOxDTLawYyy6wUkd6yNxWDaKWqsF6Y7Eoo7o93uNeBKIt0e4uC
NlZN2qrG9NcFNM3NdpiOS0sFJHfpq/cvTVG18/gTksFelktLAo0d2mpMctJKA4VkU5xTO2FFCbWC
vSQ56f0+xVUd0E2XGv0PTp2XNJjpRicWmW8FbF9zfprBVHdFSHKFI9NrJcv+Su0tLtE2VKMWj1NJ
cG2hXX6jcav4JRaE2sFUrHFe5GTKx/gvR9jZJZM0vuTqtxs29pumhRckPU01j/7IuSFGTX6l6azR
tms9aRumj03keporAnJFSwb9NZ5PTksic1ROleORL+Rm/UQoe5LU0Vgtm3UVFacec2em15oi9RGp
FJOonbHDN814FBpW8D1tFVRclwVOItkV3G2lV0RlOPHJKMVwi4rteRak19SFp7VfBLW0YpfYbksL
wbZwXuflRVtnpV5IucFaJrGInYvkhOS+pChtim8E9bSjhew5aiSUSmor7nbBXLNig/pbpEXKK7Wa
kaWEKsabVmhq9krR6K0+9lpLc5VZqQ/pdfvYxRbRKKxIjHDdHahWiNeZFjTiI4LSH9ikVLktLwP9
7Fc5N9FOJ2pDb4Eq4Gl4El5LoUK5HNI3uIk0i0cYOCqFjlmEbaQ5G5o20jCOMCpG1Uccm42tIckj
e1kSowJVjpsVGEJ+Smbkhza8nwOkK1jotPFseBOsmSxuuDI6Q2Pol7idZKdFjk1wZ4HRFVizCPT8
l0cCTLocmj7DE6OKPTrI3RdCUhMc9p8dFgwqHp0cF0V03beOjXFDa5Ppz0a9yMq8HGC+Tft6U8HB
dVR6d4LobUaRhbq8FvyN11jETrwKFdvuW1YxpeDPsKVCrkkpe/kzETojFLt4s45NR0diyZXjyJ0N
rDRWrz4O4ToSiuw3Vyajoezk71k08eR1yh7l2sz7CdFQ+nyW0TwNQFpz5FqCV8CYo+LIzojGCxZJ
y54JOjs5Fp6nlkX8ktvsb/5TTvzGxyXKZs0/p5J+ouMHasdcojtx2j1Lwmae5Xg1WlVM2acqHGed
qIS2nZgrUl9TJYs09qpuJvcnUWQvLNalwzZFun4Ns87Ymlhck1p4kdz+p5J4NKvMWOW51F4Ibst8
n7RSIwhJ5HCedsDTx5NVQ7Xfg3yb7/cla8Gh9mbtz2xZb/qP2jH8pBJv9DZLxB4NLC+o1oww7Nzk
7nyTx4NH+0lNt7YyE3/UftWOImmoSaXwShJ/TBmjj+Y/aFDDsTk/rZrvztR6cZSr2IarvAr8TNaX
Kb/c4/Ai17Et3uIj9hid8SGMWmX0lXsfqaaWLY79h/vdP7i/tG7P0L6MRQn0aXscsr46MYun6iXS
74KGUYI9E/nrfS+li6X+NO+t/JQ+jGPpp/cT8V0rx1aF0UhDGV0yfHVS8kRmRof4F9hP2IjHY10o
vySNq8ikfqUO/wDHXI66foKWLF9hjKH1iaf9p+oiQ7JkeioYvsN+zEjUFZKiA0+CNdIolfhkTUFu
JbfYiSI0P7ESe7lMxxZMW47SP6irg0vsyH3NMkpE/Zsl9iG73I7SP3H9j5IfYl9xqWcGrRXz+BP2
RJKuTT+xrfMjZLmjVaIFv3NKvDJGn/aakcXuNM/aCCk182aslxtNP7kpfJpOJNml/aa8G82aZ+0U
aW50aslw4Gj/AHGrN+5pV4J/Y0V/4mvp3m6RFfJ+0/2mlu+7JzXDgzS/uNeT9zS2+Ksn9jR/tNeP
zSI/3H7V/YaF8LLNTUXD02aP9x+0SfG40HDmLyftX2Rui6bI6Wq+1+xHcuZGqlxu/dvpERIVCJUJ
fI/sOJHU+SXwUfoYIP2YyX72P3P/AFKP0GMYuldH9uifSyxdNvR9LYyx4EYFGse5kof4GLoomejo
TfTHt0QyvBnpjpQ+kPuVfgWPI76Wi+mMjXyLpH5Zno5It9a8iHQkvI7GXHIn0wba8kUOjHA9xyPb
0ki/bHTjyNeS1wPd56dvJclUV0wbfkjfsSotK0S3eTHWLZCv6Rx92aa+CZuhmPsS3iydpcsJDEvg
57WyFmqjfHPwS3+SA6FeFFkmRryjt4bI2TVm6Hgcp81waeSVHcqjHglfsQ+S4/RJ5FFmpkUtPlew
pTeSMPJGSh2+5BedrFqSjheSCvItSN03kqTJ58C2fVybtRu/k01f8xKn4HKVuHgp+EVfkWtC/wBC
Sf8AyNxluXW5YKg77UOWdrIxb4RKF5cj1Y8klJ+CFvt9zavOTdLwNX5yVHxE9TLUvAoSdbTVjf1M
9Xb3D39vbRpO+1Ca4kNvNMmlyQhHmMcnqe+TZJ8Gov6mb1Rb/po0/ZM995OuFka8s04fzRjk9aPl
2bJPhmt/54R6l8eSLf8ATRp44Y/abGvHJJcuiGljdGAtaPvwbeaZq2tu/CN/sqINv+VxNJJdsXlm
GvzHZJeFkloydJo0tjT1KN7ukacX4katcX+9jIhBPuN5fk5M+RS9n0TfAngmiNe4/scimyRKa/ep
myy3XTnD6OjDyKJvsqzLNzowyr6dtdNvubyrMis+wzkuLKs2s3sqzPBlowzk5MHJsbpm+02PIjJ2
mGVfTky+TfZyc4Ms7eBrqmKDN7HkjnAr8nZhFWJWWuTkcX7m6WR5OcCvNjax0UX4LXJVji3yWzkT
8CbydmCimWjkavkt5OTd4FY3HtocLwXKKbK4H22z02y3kdCkvp9i+bG12lRFGUqwXQ0mNNl8jzVj
9uqkmbZuqOEbUza3gvkwzf7CvL9hywqNqeCMJvwcDhB8Dd4bN3KMPkU1L6WJSyxy7eBpS7RRk8Ft
ocIPg3XyXaHlbhSvhihN5+R5i/sYeBW8Ce5cDhBjknyd068HZX6Ft4sV6iSK9VD705GJfli748Dj
B/4N1jWpOnQ1CVs3bhR1ZUmy46mTDpCfCRHdqbZUbdOdqvw1KXa3k7ZSOcEZJ1R3vv8AJt0uC4s2
61tVSJR0m7fuW3Zy68mFkbu4sTToUNaL3WL03SL8i33KKRJacXGy2Pl2V6T+42n2+xFrwbdTT3O+
TbB7c9I7luSVDUdNxbVDbdlx8len4G+I+xGSfBslp7nZSjsyfJD+aC8DUY0+LG75G4+SvSXA5cJ+
BT9inp7/ALlJbekajvUcUVs22W2cKaqqZnRRKH03k+f32BR206oV+DjAjIo1R9NnFEks2b2OPuKT
ON2P9BZtqz26e5VUXdlpm1wLeOlMfsXZ8FVQ89KcenJXJ7dcdMMprPSynwUZZg4ouy0Uc9Pc9umO
CqLstG15fX3X4rTKeev9SK46YMou8FplHt0//YPG0stM+kbZhiT6/wBXwexdiaeOnJaNvLOenubS
zHSizBl9O1nJyJxdFFyZyKKeDuf4cFbi5Mwzamd076Xpy2sacrMlo5dFyeX0qMnXsdzbfTsKbZks
+qbLfTt3fod1/r07b/Q5l0wfzGb6dkW/sVK/16dqZmMkZZhH0S/Qz07Ytnfa6dqsv02ZMCfpP7nd
Gvw9qtlvTMmC/StFSjtft0/LjuO+FdO1F+lgqSowXGNo747en5aLkr6dpmBtliXS48FTXTsO5X0p
IusFS5MFpHeq6dqPotdO04s2yw0UjciLmsNlJFobaKkqZhH0nev3+Cx4syhpIVoujg4Lrpuod/6L
jBfSkLHSkK10aLrHTaZXRm6jwWNP8GMm546XXTBSRcjHTai6NopM5VF4NsDuMO2VQpSfPg5RjgyY
wV0+DdWSvwUhSmWs9OMHGS6FGKtnesjcVgo3TR2o2V+p38+52naheoq6XBFF9UkrsTku42RN00Zj
kbhHAoI7o9xcVRsS4O+Fs/Lg0WlgvVRW1jlpKkJ6kceUfwz8qFDsqQq0h7VSEkbpRtmFg3SjZT0c
j9PS2j/AnJYNvpKxuKKqju0037jlppIem0JzimdsFEquTdJY+Snpq/cc4HBmCfyNwpM9NoTlFP7j
xGP2MZi/IpSVIr019xy0kU1wVSHs+o2OPkTl/wAmVGP2LgriKTVFVEcof8G2jxke36vg9Nw+wpTw
zLi/sJxXaJyWDbaHOH/BTXBmojUabFBRw2Jywzbijdpq0KU0bXKvuOemuEbZc9aQpakTZyz1dKPJ
Gc42KDwbtOOauxxnEW5bcDUFfybUu1suaFp8/B6ulgUpI2zVC2QX02enJYI7o1g1NsU/AlGttm+c
bPSUFfyetBVb8CnJeSpxWBShFJ7bPTkseBOaRqKMV7CUVi8m6STxZHRcVb8D19KNJvwb5LKeTY4q
/c7UrqxacuPki3RqrbF+BpfSXJXasjpVFWPW0o/U8HqtfSyUGo4O1RwrILU5ZucE4qVUJemoqWOD
V1XUEmQn+XK44HpLSSrzRC0oXbslH2f7xij7ilWRqhKXljpGUPAqXgracDwPBVdEpcGF4H++ivcW
DbQ3EUmZ4LVZ9iK8CdEuBRj5ZdG1pDZdDjRwVikbFG/kf2KiuTKo+kqhSmikR+5hG3bZdDdYKGkN
pFy+plUQXycDWyz6cG9DwcG5o9xQ20N0NMeDg2sSijjwP8EFREaPkTooZKVeS2hpeRLlWJ0NcUN1
ls4GqFL2MswsDJqPB9XTYlk3SWR/CICFHYz7jlWT3Pgviylk3ONIyfVZ9FLpuRUNNy+xclTI/Ip/
TRT9j4MxTY6LFJfB2RuI96rBjqrFKvAtP+T3Lq7HjyVEt+xurJa5HGayZRx4FD+Qv3JOioeDPNEX
Rgany2NNCx4Eo24ilXJqTryNaayd/KiQO0a1F5HYqXghX0p5NzXJqMcdJZFGf1JEH5s7Se7KY7Xg
i17ENn0p5Mo1XRJafJGGp7Gn/cPauDfL6X4M/wBImlkSjwPd9Rjrb9yW3GCWq5foRv8ApHJLyRUf
pWSW/LRx4IrSeWRhqPlidZs7cdpLWcn7Glf9JqNLh4Eoy7TU3O9qI9qEtNtEYzf1SHjyR2Ye0lrS
nZot5wa7r+YpOWxrg1VLwjTJbMGmrdSfBqYRp15gS1t0sPBoXnB+1UvJ2t17GpF+Imj9yahjuNJN
vukauPJprz6ZKbvtkaH2P2n+4w3TNaL/AJYGlGbrBX8rdohu8M13/wDxCMYuQpvFcs9PT7pJjf7x
ml5yS9z9SLTI+5ZSf3P0LIq8F/BRfRe9mc9v79X4P0HKJtkRoZKNl+X0lTI7vB8Ublyja+Tu9i10
2wvkUp/UNWepJHND7kxewq6bn4ZkyY6MYyMPBYmbbOLO2NG3wmd2SoDMsTSz0ZkbobNvlEvsP8Ge
ej2kVI+B0ONirno/Y3SWTI3E9jKO1EvcXNCS5Ntl1yZdGMs30jkZFrlMR9Kvox9FRvme1DjyhXe3
ptixxk8nBxRG89HXsP2Elwbn0yUWjHFdUR/tE/kRIfuOhdMdP0L8kfsSJbiddM8EaGfoSb8Mj7Go
UyW0j0jXT9Ce76rEagtxJx9jTJWRUcEkRr2NS1lF+DVI7l5Lj7Gn9yRDB+giaki//L8D+5NkaqyP
2KJKVcGq/Fj+xGUvcg4kX8ifwOK+qzSX/iT+5sfNGu/cX2Iyfuacoj+5H4iamnedxo/Y1v7jbN+D
Xl7oiX7s0XDw8k2Q+IGvpfzbjR+x+0v5IQmzXl7xNId+ZH7M48Jo1vuQftpmtpfzORoL/wAT9p/u
FCXB+0Pw4kHF52i01PC4NJ6380qNaC86g5TWUrJ6Ok+9qzdJU3+8fTTGWRS8C6Wlli/tEkKRXmhP
wLOei+4v7f38a9xP4Giy3xY6HZtEST9xNEF/4jXgyY9jbLhnyObGolyTI4oaR22y5lSkKS4ZXSKX
uZ6NosZH7lDZhMWC37DO3k7vcwOSQoNY6T+46MjodeR/YePwQS6NM9iNjGND+w75NOvfpNdG0NSX
kowjYuTe7rno6suN18i3iSl0/UsUfkVjRa4Mmc9NmmLfm2Koj04LvN7PZnbdieq+7p2l9I0vJHBa
R80PZa+Ud/sfp1iRr+krxZH7Eq9xziPcIe03T4Rn3MexS+myCfsTr3N2nkm2I7RSl46V8Dz2NkE/
Bq/c3aX1D3EIlIvU4i8DEvgtN7G8kU2apu0+Tv5ryaaHFZv2G5XSZJtkV5o3Qva3kima2S4c8m6X
Jpq+WSSd3jA272krZBKVti1I8N5EpOsjad11z7k9uU8F/wApTl4FG82Q1YryOLwO3hIivixbvBFc
9xKn4olq+GRUnwh6fG6Xk9ZcklLGBO+2iF/dC+GNJ3kqPtRv9xJv6USg8OcsHr43FPFojP8AlSIZ
VPJ4qLJaf8xWFtjRvVZIwq6wT05Y9SR6zqz7xIz4ihK8PJakux2akI83yNJ/THaepGlfJGPND0pO
t8rHr8uz+6NHaQlk/tyasKVJi2rnTovURppVupskvn96mbPMhyJfA88GopPC46IXRn6kTBufBz4M
fvofBtGUhRHbGeo+jZFCV8LpIX2NyEr6ZPBsizL6OiiMbOclNncVdkM4FbO1jgRkyhs8GSkbbMuz
tVHIm82b/JRJ/PSiC8Fx6Nr8CnLwUOiKfFiSx0oX9Q/sOhTmYG0KF0Z7kNxjRyJpm6UbfuWuBxs7
o2dq2DzZTEvgTX+RIvZ0cW+WW8mDPT+GhPHJgtwHWB9qZ/DiOmK3SPdDjwOz6FI4SJdqNln0qQ8J
GH1sUZvgWKGosabxJ2KXNjrAtQV5Y5YRV4Kkd3g2xY+7tbN2B06N9iTeRyxZiWGbZM7mhxg+Gc8v
Ju3LnyY8inupoSbRdrix1LBtlxR9ceCUIMuy5aijmsna02b3IUZS4yS7k8Dd4O544P4y4JRhI3Jl
6s6dm3TnuY5N+SMdSdRHtnZz2lp4F+ZtaX/J+XPtM9cEVqN7LOx5L3YNyf6Ebvgex9hzkrWt+w1p
YLYt2YXkxGmW5YFKL4FGcLZi0uklqx3YpMaiqscmJruzwKtNxZKTeGb0+CEHp8f8nsIyt2KJRjHb
ZfJfOeD+FTHJvnwKa5QtP0VP5ZxsS6cbk1Q8KF4wW8s/L97Keml8jk2b48ihKNpCvFexujhkdOlg
acUrHKPkVxXFHESqpDfv++WTZst+5J+5JVyYPpybdhmBSiXRuaoVcI+DA1x+/tFUUyyikizBhGVR
uRhGS06PcwunDZlFUbiqsqmi2Wcbjg5ODijcc2cUWcWcFMtH02VRuspo46e6OLPYTXTC/U3clPo1
X4Eba6WU0VXT3K2nsWj6D2LKasrYWJVwfSU8G5PycGY0i2JlGeDHcVsPYs2vPTcmcLqks0cUUz1F
yKjuMFCkUzBgqWC0YkVu/CmmVvM9KUsHc76draKbZkwfU5Hemn89Khuo776dl/oU4z6/WzL6ds2v
sd+59OyMh7vUa6UjKlRnp22/sZ3L7narMabR/Dkd8GjtjZ/DlR3waOyG4/htH8JncmvwUi46Vo7l
t/D2xst6eDODtL2YKnGulwRepHp2GUhplLk3KJU1XTtWDu46dqM8Di/BguPBWov16do7XTtRdjUs
NFJG5MqfkowW+OlR/wAj/mHGWGikhTR3rpaQ5SXaunajHJtfP79UWbPYscUJ104Lro6RdHHS/wB/
SE2jCHgyi1X6HBS6e5VFsso+OtIzyYKN0ztXT2j04NsTJhG2sm6SMHBlUi+TCNisysj2oryKWoi4
nAnXacHwbUK+TCKoUtRUdqOPwKMRWrLiiqFLURcVkeC2qRiI2kbIo7l3DcUbayXqFxRwJv6SlEws
FJHfHuMI21kUtVFwiNUd6pHBaRtSO+FsuCo9PyXqqx7Y0cG6a7TaoFrgpLB36abJbUentdilqI7I
JG2i58G301fuNxRVY8i3QjJ+5enGhp/gSM6aZao9MjKS3H0KI2hM2vTR6kGq9hQMxUhtUmO1wynp
Rf6D7UhJukzEVL9D+HH/AAS1IPj8KcoiVK6JQ5yLCOIm6HgTmjbSN+ln9DZWRNxybqoz7l4Pqicq
X2N3Bt3xHhOycXLa4n8SK/U+pS+wtvPWhOaKUttLydr3fg2oT1I0OC7mjfGPIpyVo2vDHPSjQ4yW
UzujtaJJJPcKK4sucT06t0eppxFqTQoVTN0IpUhxl4FaSG4JPdg2r6Gy5RPTpOs0erprkjqTFCUV
fFDlGKVIamuBWlxyOqduvsbV9O43SS/U9HbG1kjq6fLzQtSQtPbD2G6VqI4zWasWFwSSUe90Usad
mUsZPTxfJDU0V3SyR1ZrPBsdXxQ5xrdGHA4zV4sSlSswlU3RcV2bqG2vpybMYyLV0+Wtz/esSFOh
qkSb5bKSHJrJ4whOujxRjJwVQ6IrxZhcjr99GbESaFg4Nnks3Vkosk2vPRqlg4MI2DdCfkpljbXD
6OKSI4MGz+YbN1ZKZY5tccdKI4xZhG04LrJksT25RRQsGFRsLo3VnpZbXTakXXVG6svPSzdXSS9h
YMI2nFjddE/ctxuujSODCoUPc9xuij7l7ejQsHFHp+S6sb25Z7ljlXSQrRxQtP38jvI8GFZZddGm
q+D6TCqjZ46N0dsdx+g8fgtrB2lSIbObyRxkalg2rLoi5KsHBRvrtsk4m18m9cj9DwP1eaLfCFDR
5L1XySh/M2b9WNoxpjnowO5eRYP0M+5WjLbI/PdqySfI38GH2Lkhf8xfFyIq7P0ZH7m2Mtr9x1ru
vuRWrbIJf0nqRni/cgpeCfp/zFXV+x3P+UjFZZBy0YsdaSTIweYshS5izOrUfYb3bkV1T/8AIm4n
qTeJMdrwKvYtS7V4O7LNXBthKiGnJtqvJB15J7cew9WT5wRdeEWkc45+xPd3MnjwQhBtZ8ENKTwQ
/uJRjjA9Rt5NK1/KcfzG7ODUTyzjwQhCTjnx5NPTkL+4pf0olrO8ml/YS/vHK37mt8Uf+rNLa+Ga
UD/2Gv8AwolqtvJo/wBiP/cnqL7mvfKaP/U0696NHS4+D/2JwXmCJajzuP8A/AP90+un9z/06J/J
nksojfTtfJFlMvpaIMftf76DGjb0Qn0ZYvt1fSiLF0bKH0YihdWJdWLourK6sXRPox/gZ+hLpH7i
/t6V1b9xdF0dj60YF0T6Mb8ldGY67ukjP4V+FjXVdGWL7DGOiX4Pt0kovgViORNkfahu/Bhl3kZ2
vJwd09o6zgWxcm6aGj/xZj+mzZsrIr1KHOsmEfoXFZFudHZLcNn/AKksZsj9n0j9hfYi5PbG+Tu1
BelLcOkZ8RFpZ9QjXDNnuKdHs2qFeSC3krd4IV4Zo/2s9Fwt+5bSqRKK6r+41LNKKrHIxGpptrnz
01CG7+o3/Bp/clLwkQjFi+wvuT028k/uS+xpSk/JDUXFEP7icvZEYrlGn/af+xqQl9kakvdj/tNO
b43EJx4I/wBxKftFHp/zp5NP+0l/eTg/OEa3y0P+1mjh/UaeouCP9xqS9onpeVk0v7Ef+5OEoun2
o1/uP4gzQe27lZpa1YZD+81J1e2KHpbWnHJ//gH+9g/Yf9huF9xWUOSRFMdHBFe3VmEQsfx++imS
aLfTA+joWPPVmemCq6r7mTkbRnrVPqqXkz1bYvw/qZOTHRGDbTro0KvcV9MGSXuPoj9CNe5no66I
x0oaI+xb6Oi30wSxjoy0W+j2lvrJVgpkqLSs7umC2IpdK8kjcsolfnpg3SM9FGse4rHRuhkdj/B8
WSJWQoXuZFRn2L+DJ8WatGfcfuXpw3ZGp84KqzsVv2PzIuKIy5oxzsotQ7fc3uTUvZjhGRHyvY/9
TvNunyXqQqmNjj/4m5fRZC3ihelnIlqKsCUI7nRs/aI+Tf8As6F6kKyN/I/7Ra9dppp+EzTfyQKs
ipe5Wk+6zUjqPuZvX08mmv8AxFqxlcbsgpDkusE35PfcSl/KTjuyjThf8uSGv5Rtlg1M88Hj7mXd
LkglnI64eCTXBJfBDT88i1kknY08E5eOEK2qQnaNOP8ALuyS7lTxRKUWkvYrl1RDReHyLXxuJRJT
a7WqI7mmqsXtHyRjHxI5WcEnDF/Btit0uCOjJpO7I6/83uSX6ktR4xSI33YE08QI1W1S5H/5Yobj
237ihp02lRDQbXuyP7Q/q5uicU73ZHOXDVURl9SSIu/pfkjWIqV2dztydUSccKj04NPG1jr99sbz
VDv2sknVGPYkm8Jifv0yeCkSozzZKnk7uLLXgaXH76KFb5MMwU3RuuxpMpikzDF7WW2YwYNrZv8A
Jhjst5MPorZjBybW6N1nJTYnaZg5EYOSmzd5OSrLeeiyc5KWCryKLZeB5OS3kxgVPyZ6NJ/gUX9j
c8mMC9jLMYOTa2X5GrGmJ89McIuzGCkxRk+jGm+TdyMT+Tm7MYKTFGRgaRT8l2mXYmn5OR+DbFmy
WK6YO54bPcs3/wAovcb4ZtTNsnk4/UpM2t4bL5HQ/wAFpKh4G/KI+4l5O4X3EvDR4qjAmqpEq8kn
5FBvJyh3JH1YZiSLc4/5MNcj7ksH8SP+RxdSY2J71EreuPcTu0hXNLHkv1oslCLKnLDHeouaNkHw
zvlttn8dGdWhShLfFeSO/Vpl+tbHGDK1J1SP4wo6OpbFqS5RprfTvI2neSM74Iqcnu8i2PHklsl3
G3Vk9tUfU7+StGTG27/Alq3KKJbMYLbs3XgxHwYfaJp8G3Ug5scYRcS2R3JyivB2QobbLibZR8UX
4E14NktNS+RpLb8ItkWkmo+GJekrHKTN0eRaexYVG5rb8FocaUrHF4vpFwf05orbEbvk3RYtPDSV
Fy6OMHhjUnzz0i9GVbfBU2iT9zdpumbN1qqFKcrZZWlPD8D9Tz0UtKdUU5D+f39pjio8+R6tdzFF
qi0RiofScUfQitpbH7Hady5LRTVGf362spqumGbWjJyUsndjpjJxRZcWbWv8FywWmVyZOTtyU00X
5MGxxMlorlnt0W0+mjLOSttnsWmVyj26YKao5LQltstracmO4zgyYZwc/gtFfUcbemGZiOyzbVll
2Ve49ulr/B4SMs7WVXBbOTadyromjN9Lizbtot9NqVoz07P8FSRktYK5Lnz0qDO7p2f4Kl03Lkrw
d3JZti20d9r8NabaNsnIzllxdM/mZ3tv79EoSeDvb/Xp2MxuM8mHTOzezvlI7Xk7ZSf2M70Zk39z
sszvO6Ur+elxhL9Du3xXycnZu/QzGXTtLUXRUsGOS1puR+Ymvv0vTjZ3abVdKjkv0rRU47ZGDdCF
xO6FLotisucNpko3KG5FSW1/hwb40VqKn0uFHesLp2l8lPlFI3R8lTRjBe7A3JWjtR9dG76ipqn+
HtTJOWUjBe4vLNkuTGDFsa8ieVfRurSGorgu2XHJ6e13dG6qL5KmnkXKs5bHKsLptSFqZHDyhYas
vLGpL97npVFv2PTRuHp0fJVGelUcHBZXszgr99SFKZhDxg4x04NpnDMZKoUpf4MIqhY7ejNsTu5O
0qsm6SO0ZddvR4FFIW9ZO2PRS1Fg7enGD5MI2xQr5LUTabtRHah4LqonBhG1IW5ZO1G2jfqI7V+F
KCsjvjbO2NI20btSOTticHcu0xHuG0jZWDujk7Ym2sm7VjbHticYN0l2GIZLSoqsGY2y4o21my9W
KZiJwbprtK2Jm5I208MVwtnaqNnkUpoxGn03ai7SvTG4o4NuxMbSoWntwxOUU38j7EmYVoUplbEO
URblSEtiZ2qmU+tIUpFbF/g3afJ3KqZW1MbSQoJCb5+R9qX6FxjgUpo+lV9jdpnciqX+B/1HpuJf
kd8n5awKUynRv0uROcKElgdLuHDbhGcMak7Liu0Upr9Tbd+Bz0sMe5YsWa+48ZPSrAm1tHasuC7T
fOJt3Y9j1dOFM7leRK9o+23zZ6dYPzI065JL1blXA6E+UO45O3j8KdX5Ixaq8EtSMVcUST4TO6CR
9KyLTX0Ni1NiZ6TWVli1NOu7OCLl7WJSjzguO1UiEtq4PQ25HLasmrHsde5Xp7vkvZUaumiEly/Y
7NO0Z0zKoXbgT8mqqG/O2xJ6ak3xgTcEsWaTiv5sn2NTSVdnJHVql9To05x1IvxTPTjoppurRLfi
3Rr6e9JpefJ+WozIblytxpakns3SJPRrUrhD36WxDnqfyxNFx1U/DQtNaa9O+UP1MXLJq6Wl3R3c
kXOJBLi2azfHqUN3tUXRr07SVWPU01iKt/v1Oj9D1HjxRH7D1KGiTXvRwdyRdFDwPA8cngbr985P
o17Cxyewo+5wbqz0v3La46baEYRtL8m+qZRdG5rgVGw4MG0uhzrpZxhHsbfYjgwJe42bqz0v3Lo4
NhwYVG0+45VnrdcdNhdDXWMqzXSy66bROjCorpddb28Fm2hYMI2l8nGeifubqz0oVowqQojZx1vb
0cXyZRdC06w/I8WcI7VZZdZPkqSo4L4oUK7H5LLSO1WJj8dUvkv4K/kNxuo2wH9i6MG2f1CteS68
FfyCZuoqHgtouvB2o2avNn6jr2P/AOGJm6vJthjJclx07V4Nup7mfcljwSldxE2vA5peRRhhWS38
0cHbzRGGpmzK5Y69hyvtRG/YdLybYOsk1LwqIYEoy2jfqZM8e4lLkcj9fwJe5+gpRlTWR6E8yvkc
/dkkbd26K4IS+Taetpv4YoP7GnXsR8bcnpSd/chH/wAT1qoUVwT2S2tm7VuRzWCLrtTo7+0/L1FI
7Y7BSrlCilg1dvJKH/jRG0JL2If3Gtp+6IyazI1P7EKMbN01fmycdN5E5PLZckv/ALKj4izT0+KE
/wCUuqVGzSf5fDKgbpZfJLS0pdzZLVaTlVs2wVEH5yNy/m1bP2jT4TZpNcTayftX9qX7/T+xgtCs
sklyP79G48jb8GSyRIlfgzz++l79J+wukJfPVi6yF0h9+rbEmPpJ+BdF731f4JUIZH7lFDF1YhiP
t0f4G/c/Ql0RH7dEuti6L79X+NdGMX7h/hvohPpL8GRi6J9GPpNdUfoL79GTsx0VirkX3P0P1F9h
ktw66IpeBH6EfuL7dJ2OhkbIxjh9P/U+bF9h/cdkmMX2IpeBfcf9pVZsX2Je9krJyQkKTVlR01HN
Em6yRXjcI+b/AAbl4I44iP5Q5Dj44JEvuaaXuKflnpPgUlyQi/ES4+UK8og4f0j0L7eBSfk1HXbZ
ntr2HhuPwR/uNYvSZ+dbRp6cruBH0ryyTn4ZqyS/lsitLU2EXqu3ss0/7jW1FmjTWxx2mrBZuFEZ
yXg9OC7mqwbnFlxg7NsdVw+D8x32GglHhibSweno2lFig4NWRm/6bPS08yarBv1LaJpwvG3I4enF
foRn7xZp4UanR+0TSt7qNJNfRR+1q6wv38InaURfubSTGWjgaGyvYfyh17jsmvj99NMtZJNkeix1
whWPJaJN8CMCrgz1VjLRLcIwRXgz0bQmzkwS+4hi6uhX0tDvo+vyYFfTBno66JkV8GC30wdwjHTI
zAm+mDOBdPdMoZaM9LQm+DPRlDE0XLnqr8CKP1KGhtDs+elsVlI+LKHRKUTJP36xF/aL+kS6N6Yy
vJjkUp4MlfAv6ORZ8GC9MaHnwLbybtQpvyOP/iJ/ypn6Fp8sc9Pka4GrQjfL35My8m27wKX8nsVd
YOfJu03mySZV+CMS5ZIrd/MNLKo9RfT7CV1g+rmRvX1Ek8HP6ijGVWhNz3ZNpuus2KD9yWpGapO6
Gn1UfDMcbTDHF+BP3ZONkovJBkI2etH6RL3Iu+UdssoV+MEEn/KPXUnfJGDNaXJa1HGjue40o7lT
dkocxl7GSW2S4EiLfNmovk1tNvuS2ouV3E5/lo0trwnbYs3u8E2u3yeisp+TRSXhj1ZbvsVtd+5+
0abq0XGPBTx20QUX/MThXLO5NjcY1JI0EudrHqPORRcPPk14R+lMjq+ZKiEfZMg3iDe4in3OWWjU
cY7F9VEtNSuL5/fq/BzyiPyKViheBt+SRtvo6JZ8E2+LP0M/SY7cDiv33wZZaMMUWzeslJmRWx0y
vBlnaYNrZu5Hk5E2zHTLMdEpG7yPJkTux0UjukYOTbJm7ycnODdd9KsqTMGGbZMs5PqF5H05MDQ3
1pifPTt9zLPYpCjJljyc8l3ZyLOLOem2LyKEi76ZdWKV2WJrhGXnptTFCT4LHTGnxIUhu6FK8I5y
XwUmbZyPgdGX9ZayWKXGRO7Y2ykzbN5PgqLybX9LZfP4bNs3npsiypPFiaZh8o3p5OfF5G2+Dtlg
Sm8jbaqzbDg2/wAgpb1TNsXlnq7v0FmmlmzdvTf3OcG3Ul5qy/Ui0bYMXd23wJ+pH35NsHlo37nY
lOe2kPbNSY/Y2TlSvkcvWTKTwRrgW7UqXI1py8G68+5WtOqQ/SnuY5PJU5dtl+pmzEsEZbsLwR3y
d+RwhLtaPUsSnJ3RcW7Ki8H5qz8FRtDVNstdU+TatN8eCUYw8eRsalC2zaof5HL3Iy27qfB/CopR
2oUkrojF6dUqwSXpJeC1gfapqqP4aX6FcfYkoxUkzOmjGlX6C1X9S4FDDoaqJukJmxZTNvg3xdNu
zO2zI5N3ZenKqO6RvWGKCn2x4OUbXMepCVSeWfVZTkboam1p2fxD+IU9Tkjp+p2o+sp6g5PlkZaU
9teD+J/yXqy3MT0p1Q92p8NF/v8ABSV4oUpfUbOF8m/ybfBdWzg+kusneduCpcFo2+F/oMMpoyYZ
Ucnd07TODJ2lHcWivB3Lp2ncj5MMpsstG3lGV0xk4LMMrwWy0yqsz05szFmTtK2FyMM2qF/J34fT
t7jMWumLPoZb/DUcncqHZ2G1xr5LZhlV0+Ttyd+Olx59jKMlopK0dxyVHJ3c9LhyVJYMstM2v6S3
0pWzvvp2M4wZZaOWzu6VCz8xdPyrv4KnfS4fUfzf4MvJZUN1fY/Nv8Ko7d0kPff69Oy39jvUulac
mmZUnH5M4Pkxukd6o7VZhOvY7oMwXCLPpl/kqXJyfU+va3ftZulC0UXDTLengqSplRW4/hdpU8Pp
2Rs/MjR+WrPos/h0fmwo7F/kvbZ3xo3QWDJdYKnyUi4I2TWSom7wbZ8/hxgt8FeTBadm2caZg3Jt
FyzHpy4l3uRXBRuUmOElkpG62i2tyMCu0ParKlhmI4LRs1IsSSPZl7W0URdPI5Zoafg4wblY4aiE
o5svMRSeUYF2sbS4Rtksj7cFxuxwl/yJJWXtoTp0JLyRtcok4fyq2U8P9/SE5IjH3N1Cil5LK6cF
UYibGi6NhjLOP3/auBDaRsrJFtZMDNzOB4wUuDPJhG6SMmEcYR8nbkf4bku04L/lOB0fLL1EOkcC
jHLZ3q5DN0ldmUcG2MRb1ZiOS0hSmilEvaZXaZgPbEysH0FKJ9I+qUVgVxyYRVG6aMQLSN0lgrad
qPToXbkdRKo3anJiIzc8R+StpaRVV7iW2x4NijZuksn0pDdWj1JlbUNxRXgXamYQoRiXKKbPpSLS
wVWBdoxPwfTY6ibNuBN5OEi4xtClNG2kOUEd6qNijSr7DpDvj8CTFSH4Z6fgUqyVJItcCk+TY+Bz
jQ015MYHgVI22Pdk+nBUXgatP7Dmlko4fSkKUokseDUxaFnaUpqX2LUclyibefg9TTVM2uk7MrwY
9heoX6m0qOpvE6MrYyo6tstx3FNeaP4lHb3RJbV5IvwfTkUILyKco2jYqv2PUjFWSi/HVM7or7kt
tSXApRwb5Rweljd7HqJZfsKT5RtaiiqXF4Nn8vJlL9Seyn4FOD2ryjez0VW49VfWzdLwKM0jHtZt
5jeBf8mqof2m5IUl7C/Z8WepVyZKclmLNs+fY91tsSa7ZMzijVr+03QXaRlVYF+z2vk9RK3Jk5NX
KDNj+r2F/NUbI2vqFb20av32r5HKNRiuSMorLjZ6SluXlinWZvknKr2Pkenfd7Ge7bCyEWlnwLd2
rgmnGnJ7UjV14LsUq/fqTXk+xGfEUyKRvoZP2stKzuVD6bkjPsOQom6hr985tZLPkvwhOhqWDtI9
uaKGXXnokYPpwK/Y9iodzE5YsdF//Z4OBOSwhJLpwdqsuSFaswLT9yy5r7dJEDtjZfpjc47WYGpR
rqkkZXTCO5G45yPtx7n6EuqlWX0yXXTYcGEUX8F1l9M8l102s4MISLG6z0+5uro4vx0whIstLJjP
S66OL6UvOT9CiLo2ovyXRjkqXJwXRt8F1ycFQLY3X4IyaLiNPki0QpD3DhyZWaLF8uhz8NkmsG1v
KIyrI3CVfA9+aJS23RHZcEXNm33ZucN5XoIco1H4FJrIlRP7ErRFb/TwfxHPIo15JUSk32sz4id+
F7na7VEvsfl+1G0jKRH3Hp6kqjxgWpGTs+0TbCVLkTlbyUxx5pi7TgjJrFjr2RLX3PIr8QNReOsV
XgqPsaabbXsxOvI69ierb5IX7Gp9xJXRqxfgiKCIfL4GL+0nrfJCzWRXsasX7EBwNONZbGQr+k1N
WuHyaJ+0/wBwn5NePjYaX3JR+TTrNskzSr+k1tXH1Giftf3FdXRrx9omj9yUJYVmjGNPPg1DQX/8
M1tVZ7j9m+zP2v8AuQt3NH7SvCiaJLc67j9nS4bP2j/+Z+/X3JMwRj7FkqJdHXJJewun6EzV9j7I
n+9Qq8DKTL8tmRtCchfYdG3wUukf/oTZkwVEU5rPSuYo+w4tlR8lLr8J9MdVXJR24yIZGL6cGFz+
DPXPBjPRm1Crk5H1h0XViH0fRi6foWLovuPrXVsXRDH+J/YqLrNGeaL9mL7D/CvwTGfBL8CGNRYr
ZRyW+BfYefHSLvPsMcU/JH+ke51kltymYOCVeDLtEq8GzwJb7dEZL3FZIk4iep7C9Ii/kf2FHy2S
/sH7kr9hr46KTQ/G057CMnHcrIwjCmP+w2CnXix6cefgctSdP5F+bEwRzlsl8Uenfklf9BP46xfw
QkQZFe7JfYejfdYvsS+5teLwTfuIWoab8Wc+T3wamlTVSNP7Gt8sqn3KjVk8WiJuim79jSltrIyN
eIGpouLXcaX2Nde7I9ra+DUk8XE08m+C3WzSm47UmSyadZqBq6Li13WaMfaz9r/uEow3QNaUsXE0
i9NbrkaUpx2tM1H8kGvGlwaujOLSbuz9nj8H7T/cXGLceDXlLmSRpfYvT53H7PPUVZ4NVXl6v7+m
/JJIoU6NpZqe1n6FDLXsOHt0mSk/JT9h/vpNskOyC8DYzBC/bq2x0Rv3P0I7XixX7FtGCSinXuPd
0e0u8GTauT9Oj2neX0k/HR7c5I37DOzBmVl6jvpgfNCvpHbdWdx2nY2J6juQyUvdjoeeuCCMGTno
2xDE1x1wW+n6GSIx+xR8ioz1yIwMaGjBnpgtn6HbG1YtyykPAl8FrpXv03SMlfBf8ohjcB37FX+C
6wV5JEHDjyJeaL+TajPsOvbomTSFfuIvT9ypEjs5aL1e4jKqJ+9HqfVAtw7jbCbUfYuWpZKnmiW4
qD8C3OyH3JQTuz1P5R5rtLUqKbvA0pbcChJ38k/0NRC8iThGDrJvWqn8WTT/AKC/BCv6Bo5oitzI
3I9fdeSefZEtaNW/BKN52UOfVJ+wlfgtO0hJPhkleOB6yas234FBum2LUlV2PKwNvEa5IqXcqO10
jbHxLJV/B6q+o2Kp+D05utzsWrLPsOpL7HqyqiF92MjcXtS9zbp1V8jjKXd9Jv21IWnFqx6Wo8yl
bPVlHdfDOfB6rwuCP82Mktq21kcNN9l8m2b8bUKeza/c9LTlcrPQ1JYnK2ettu+GUnTa4FrylheB
Z3UrZqS+mioz7LNmo8/ShPaoj0tN/SLS1Z3btnrYybYyzJHqynmqQuMK3ZOa7ducDV9l/vH1S8Ft
22QkvEj5oSTwPc/5Td79LMGHyiUmYY/ZstG2L/0DQze/cobRG+BfYddKXRT9mU5F1ZRl9bQl5PpK
4JUX/M+lP3Pcxg5KkxtFDlISGbZYPEjGDk5OOjybsPohPamexSMvyOh/gQnYykypPokmKLLRyW3j
oylwdz6UmRjNlodM5Eyy14MvJkpMUJvAmuGYZbfJgdjfsLORs2ReGY5KY/Bt8CcT5FK+Gc5G2NJ4
FHUeejUWdz7X4N1j9xu/wJqVUfWv8jf8xW6ivUj/AJGt1lvAvzFlEmpp49xNcCl6iVe7Heqv8lrw
R026LetH/I0pEnKVJozrIv1Ykdst2R7tTZ4P4yY4Qalfnpc9TYxr1iTT7RbtasFx1rMPgUNSVRvk
lWpZ9QvW+n3P4pnUySceLwOEpVInt4IteD82T3Xkw3ZKOnLFUKbFFX9G039N0laFUHV8WVGO0W7M
bs7Y5Mv8LUo7hxjHbY/kT+qKd0YhUi2KSYtNw4M46Uqd+41JJIbE4OqyUbpFxdC01LCO7p+XLn3H
vfS4Spo2ymbnllxwzZDUx7C9Rljelq0VPUtFlwlRtetaNzy/cxhmyOu68I/Nlurp+VqNWVPU6Jwl
TM6rHJ8s7XRXqOvYXqO66dmq0ipTtf6HsPzCovDN0uSk8F3k5PJubyVJ4LXJt/lL8lKWDPP7/wDL
M3R3HaUd5aNsZIyy3ydsqMcFzO1lLg7jDOemWdrPc7+i9MqRuvJUTJ3HaVVo7jDPc4LeGbY8dMnY
zyZO19O7gsqOTvLO0qS/F2M7jJgo3SLspZO/g5OxncZLhZWzBcjB2p0XNV07ZHdLpcZUVubRkxZ/
NR33+pyfl2fmWZL0rKlFtHfhn5V/oZUl+h3N10/LcnE74tHyXp7kdyZ3KjDNsW2XNdPy09vyfmt3
+HtlRiUqPzVTMHY22XqRPYqMpFtOjvR23+hiMnH7n5kaPyzydyl/k229xaujNn5jz05fWkXXaUuT
cqLo26n1FRRdZKkqfTs5+T8zk7Dk+s7y49v3L3qzvFtxZ/ERu5KkqfVKzepJpmybz+GjMto5J7qM
8nkuMjbPkSSL3tFtXHp3YJOD3UV59jjBcJOzZNfqUkX59hXFtCSO5EpR4RtkqZ9DaLjdjjPx5Eox
tFyWRNJuL9yjdKBKemuDa+TMcHbHI4TVCSXJbj/kUquLKR3RJzgvp8G1/UW44KilbJacuPc4wXix
Sr5IuVUxyS4ju/0OC3ErjJe0SrAm0bWs+C6OBYMRIqsG6hQWMl1keP3+6XHR4OCuRtI2UJzidsSq
N01gwh4FjtOLY6RsrItyyYRwbpoxEtIX9NnGTCFGKyJyVsxGiqN00YicCtdpiJhG2KIuStmEYRvm
j6TCMqoiW0dI2xWTKuRhIwjdqZZ9Jhfh9SZ9KMGeClEbo2IT22zgwb5H0ooXbZt2r/A6PeR9COPw
pJXEWMij7nFsrah4KS7RKh4M/SdsV/grYv8ABwLbyfTf6D7f+Bf0o2xRwd3BhGRujahbo5LaN0l2
+xGC4H7/AIVZ7Idq2bKw2JpFSLiiLaKfA5xjTQ01wxPgaaPpK3UO+4bcDEq/U5sc4pKRUU3+h/Cl
/gzgpCc1ZJ+xO1gWdqO2e8vbkTmr+Slk9SMcm1umZSsljg3P2O+W0/jIgtN74m6SoenGdy9jMVwK
4i0pupsco5XB2ItaeDOmRjJZs7Y4N8IdqZnn8EZNFNLHkxxIjJcWRnQ9JVceTcl3VYpNEYSq26RK
80hpoe6tqRcf5vApqOLybuB6X9IpJZeTfXBDSdW3RqP6qRTWPBTwil/M+BT24suttD0rtR8kJqOX
kU3HgWlzJk3zSKdMV4RXmT4PU2qtxdVix6f8kfJpyrnNm+uJUf8ATxuU7r7E3V0khx7W3kh4vCXu
R9RZm+D1EklfBfGLJRrsXk0XhY3WKdLEqF+zxV91P4NV1aqlZ+0aUZYFXnSonJq1d/6B346e6Q1f
wJ0exCKLHeEbUZIyS46WR0pDf76MfAqFp+7G6MIwW/YcqMDsi6MGwZx0tjnXSmcGEKHTjq5+ejsW
Om3phdMjlXVY6KPTCMFl10dkXXHRR8F0S6wS9xfYySotrktDRwWOyO3kWPBngs7TPAmPuyXVRHY8
XE7oHbpkUo4bF2iI48mDHFncMwV5HJ8G3Sds/Md2WVB5E9xkeDB89OzkfqS3RMI31liOCx7T9B/g
UmWsEo+xGXsKvYySjeDbzjnptN/uyVEovwQL31kp5J0skUm0kK8i017m5QT+6K9OK/Q9pCdWJUTi
ayoiptrHgW139zTg15JUTfuS99qHuG17Eyvgp+w9tm2X0t4JxfFnqRuz4oiiOpJdyZUfc7lwylJL
7lcmnrQVZIMcXmx6umjPX/1Ni8kY/wDBpr5KR6nuxP46b/MSUWTFEgqoh7WYPUfJF/8AiSPUf8pq
xP0FH58kIoj/AHCXwerh2af9pJ/JKTq0jXR/6kYt1k0YRqvg/wDYiv8AwR6kWrNL+wl/eTk+UrNf
7o/9SCn/AFYNKEeBf3Ff+KHqwy2zR/sP/cm/5o5Nf+6j9pZF+PTtiwu9jkr2t/v9U/8AUkKPgyOi
LL6c46NdJCvo/wB6hEesmL7dZi6Q6sXTJJoXSPRjF0Y2hdI/jfy+iEL8LMdEfbo+sWxP4HXSNDQ8
iQ0OmJyYvsSPjpz03y+m+D2JJMizKNqwbrTMroqRwcr8CGkW1no0mK2R710mxmDd4Qu+jtmpdOLF
7FjRI/Qdfgj7+xklGJtm/sfAqIuXFia4ol70XeLIpfVY7KXuQb+kqb7h7OD36NDlL3J7PA4yl2ix
4oi00hO8EjVE5rCR+WqNNv3JUQj8k/sfcn+hOx1DdaO7Sz8ie1JEMeTdzkentqj3pFkdPYqfkt+T
UO6W0tau5mnCMryQNvhkn8Uaq6v32kJeE0Kfg0/uWhQpquT9BIcGnc3gbfJP7EJxjuVpsjN8EPuX
HOD05RakuSK/8Rq+eBw2YeLJN+SXtRpz04783g09Sa2kf7i45aR6U4tUaf8AabV7jioPbLFmpeLL
/wDE05aUdzvcaWpqraR/vJShlqI9LUjwaf8AaY8zJVG4ydGqn5ZP+w0n+z/Ve40dXVxKiGeZGs4f
Woqh6eqqXg0/iBFe8xtL8qTyTT8yP2qUcqyVf/uTRvjaaH9z/fzFX9JKzdLnk22XzZF+OjiRl09P
wxjPUY1Y6/ewYqN38vWoi3DMEt2PYWeifjpyJRIpnJgluFkwbvC6cnb7iv26YHfW6x0aO0XTB3dd
3jo0Kuro7url4KH1h9yN+w2MtjHYq6x2+5G+aGT3e5j2L8CRhFRRunbFEdG5tovc3Qo0JyVCJEXH
3HuKLX4HGuwyiorInbqypckkY6VfJujhHe8jybVWBOfBgavgwMkr/BFjQ2J+EKPmjd8iR+hJxKfJ
B/JJe/A/hkDEksm32J8FQdYLnLeRdUSjeWeo5Jj7Va8lKeDdLVfJNbqNSLd15ErrAlv3Gnmsjj7n
qmpG/BucqROO6yS3USjiUUc7ZGJ2kjSibPklqKTyS+xD7ENXdmLEtxrZyim6wfXu+WQSrLsh72er
5NS64Jy9+ri/ODudow8UQS4Tyyr58EpxwPTjl0RhfCI6k8PmytydE3LiWEZ7kOnRBp9sWbW8vwPU
qvklCDvBCEnwLVnF3zY1F59hzk63FvvjVFx7aIPd2JmyTuTfBv8ApZ6WlK/FkdGb7UR1JR+bNmnL
Psb5S+o3YlSHK9tClu/Li7FCX1yfkulEenpzxwLS1H2oU6i088np6Ty+BylK9xuuOEuWPbVp+GRn
u7U+CMNVrfJ+RtSh/k9PSltXDYtLUvZBVkjP1NPjcPT05Vfsaj1ZU5Plm162nTivJFw1YVwsnpr6
YP8Af3EqUvA6SP0FsI7mKRQ3Qq6KQ8i+5a8DjFlv97a5EpjkikzLLwOmY4FbycnazbJ5NxhitnOR
nOBWzBhlS4O0wZOcnJzgW4wdjKmy0YZngtM5P/ESb6VEqTLRhlSZaGz4M8nJ2sqTLQ0hvqmxGD9S
KXgaQz5ZRY5P3MdPgVPwWZZyWO3k5FtZ3DUBCdlpm0sdujcngx05wYaLbJO1gq6Zz/yNbhvdhl7k
civixS3r/I3uTaKi+kZbkj60c4Ypb0ik8jbf4E/US+B/mR/ySKnLZk2+qjmy5cWV6vgk1qJ4NyFL
1Kor10SpkdPUko/JnWH6eomT3zqzOtk/iEdkrLnPbngxqDjpvlZLHve2S4K9Qm77Wyt43CRz9iEN
R9vJ2/UPJ+dG8Yo7bX6mVZKcX2yZlf8AJt007Iz3cEVqQuR/Doex4Z3d0UqP4RUO0c1m3lHdo5Ht
hQpc0Rhsuj+CvvQ/5UX1T9jZt3ZsprajInDwbeC2XE2YqqO8tG2M8FN9FLSlTRUp4LeTtZs3v25L
1HufSoajRWpO49N0JUzM2X79NvrOlg/Me7pWnquK9jvm30vTntZUtRmTBXqySO+W9+/SlNod6jku
lptNex/El9r641Wl7M73Z28m16rKeo6/0PYfmSsqEqO92drMPJmbPqMys226L8lbsGeTteDv/f4K
i7idzvp2SLk7XTtdFN4O4wUpM77MHbZ3vp2HudyMMrdgz07ZGbfTtuJTkdxg5O9mDB3nyXB0d7wW
zsOXR39KizKfTsf6HdZkuB5O/wDDWm2fmMs7Gzls7uTB22fmZPk7Lo77PkrTbMt0dzbZ2yow3R3s
5Khe07mzJ2q2eVH4Kkzsuzyj8xnJ+Xe075M+SoTZ5KlKjsbLyVNnyXptpH5lv56flWd0nRRcI2XC
4x9h+pbPk3J1E/M7vn8Pa8m5Pt+53mDsb/UtmcG3TbTNzyVJFRdG67O6N/JUTDL/AODasMtSPqRU
vw0rNz4XsbS/US+5cZo2zVMpY+TE8myXJgxg7snNH1UYmjLtfho37mUcMuM3fsem4lybiYmy7bX4
KRct0WOencivItydM7GzZqKn4MK0ZtM4ez/6KiuS9SJKemuDa8MVxs7Y5JQnGvkVLB3RqQsXDyJQ
E5wJT04vBTXd7EXKFo/LVEoSX2MLB9O1iaXbyyKj5LnBMlqaaFF/VwJzSZhJfY2SX2PgqlZ7x8/B
2n5lWSno1us2ebE5/rY9iW6rJQkvOC3x8nMbOxdnuNucLr3NXVjXZGy/9Aki2jghJqztVEXJHgui
qI0cCxgvaJLGTw6G6K/fKCFaMIrzZukfSMUvBVFnpxFasbo3NGYmEiuEcWfSXQ6OGe3ROWInBXhH
BiKG6FKaK2mFZunycIxEziJhIxFHBlG3ai0jgWLY8ZY0uRTmjg9KhYNtIbofVJLAltycGFybtRZO
KLUTdNYKoeDbWBYPBSRclk4G4o3z5KHSO5dtiVHAlHyzKKLijfJFDwdy7RJRoeClwJVkpjcVkUpr
PTETu8MikqH2iS+kWB2hNYVipUcotxsvwUVtH+BHsVX6ij4bE6Mqy4oUtvjo2lkqi+DbSOKNsp7R
urRJ7EfUona9yO1UxqMLP4R3x2iSFaJPwakq8ne9qPy3uSFjlik0jt5R6lZo2T8D9/cca8lteD8z
CMX+p+XwboRwXKOCqyLFoi2iVIcF/WKVGzCaIPyKW20hwjCs0Tl+hqR9n1Umh7liIvKasi9uJCks
EorFYN23uWbN9ViyOi+WSbW6yVx4Zt/4F8rKIz2LJu4GrwuDdS4FqNU15I6HNvLG6tMmnHhnn4RG
8tq2RlSyzdxRK+P5TdSTq7I6m1cEdCOY3TJSavwTVJ0VH9EiCa7uXYp0sslitpPcnt/lFaWERml4
IaUE9u7uHNr6ma1fyqxKKy+DTWos7bdkZfzSkTxew1HL6XiJbw4o0tVfzIjpKDWmnk3tfXI14J49
SjWhH+akbuV7f6DaJ/A9Oxad/SKz7EIr3PkvwacDPRl+xHTfDG/37lVro9xDb7kfsZHQrWbLRRKX
gTQ1ITR2i3FmyDyXqOyjfJdMIv8AlFFLpIwS3GeiXz0Ylp8eRJ9NsfqZep0wL+kZsj5Fg+RN8CQq
JCo/8TPI+t1l9HYsHAo9OOOmTjo7LrpQnRddH9jgpIyXXSiLLoS+RnBgpnHSmIuhIujgpFPnq4sT
OD+I+RFjoz7EsfgjLyWSiQbP0NpOPgSXsNrCFEUvdnsSj5NNlvmz7EtvLE5/SuijHKsuODJxkT2i
jRJGpES1FeCWxVg0ojS9x/LNQ1YuN3wyyf3JfoNSjuTKjpix+WyD9Tkl/NghS+pib5ojFD+5Ld/U
Q97JSWJXyQ9R1kUfqVlqCi2yf3NX79I/ck/sbfkkvg0+kH89Mf0k5vNCRrEY/JXwaf3Gvg05RoX2
P0NTUfh9Ncgpe5tXCiaX9xKPg0mvNH/qQNTU/ms/U/aPsaal7m1cbTT/ALjUT4NJw8n/AKmiaup/
Oj/2P2v+w0o6mckkvpUDS/uNXdwaOxVY/sfs32Zrz/miaf3Nf/8Amk5+xFtWtm5iVVvz+9fRe1C+
xItCslQpvGT9OkH46bWP7DNL79K/fRjx0dC3kX8Drqx0xLyfoMTeT2O0qjfNZMENPw3z0UWhqhdM
j9ujSYukF89ElxeSqH7le4nJZ6YNti7l0cqz1tDjYj4InI2S6w+5L8H26SKP06P8FkR9H1S6foWI
fRj6ossQ/c+ekvx5Nt5YqGNdJ/gj7jsmkKMj4F8ik8qy0S96N5CKXcZEl/UQbdpm2SzZa4Z9mZwO
EMs7s5JOOGSTk5RXgzBpe5BrUihd6YzUaZe3cOXFGkx1/URijUPuM1Bx04brO7T/AMm6XNEFQpS7
UvYlsdqjd7EYubUlEXpvcW+Bbf6iLfNiin/MYeRQjqC3SuJNXwzU+/SP3JZ9jdTavwOUvYhk7cvJ
FONDsrzsHp+m6b5FeDWyLUgtyT8G+eMGn9yXp8kYzX0lfAo+dpLTaxJ2md3JruyM9HhPJ6ksYNL7
k3DLYlrcxZz4IR/8Sca/Kkyvk/ac/BGegrUWb9TD2mjG/wCY1vS+rwJa/wDL4G3hUaML/lZqbsac
5Ci/c/a2muKNOeivpHKTy4Ggty+r3NX0fqbEv2j+Vk25KjRSy9jNRzk/Sk+CEX4bwas1w9U1ks5R
O/8A90fs39n719IN8CSHM3sirGQkuLP0ElwQk+bKIU+WfddIz9hq/wB/fjpZCvciv/EYx2MZd46M
0xqIlLnpgohL5KMG58lEY0fI7MDbF0UvYoswOUuDjjpS+npUBTlJtIromUNG9iLfD6KfgyNLrGLf
kdfgcihqxdKvpk56WJDyX4K/AjkvrZQ1ZgyZfSxZOeS+j7uqV9LKsojLd5spnJyP7D/BF2SVkiLK
vwXd/Alxk58E+/NYKfJF2NWKXizSRvumnZtvCJNspPk3N2/ki0SizemcLBSbQpSk+SSvyTV4O72H
tfg0rZzaY9ZE43yb5rP2KXBO+R5wd8O5exJLGCCtCRNLhmo//s2exC0bPktK4mmWnUk7Not+lbZc
FtonoRl8l+/RC0263MuXdF+SWx4oWpfaiEbt1bN6Wx8k4QePc2ydYo3NceSoO2VN/XI31uiyWduB
at9sfBGPnljdbPI9PTfb7npzfikKThb9z0tJ5FGUr3PJ6lJp+5jtdeD1b4IQlVrLtkpUli8EoRfa
enqYXCtid6bJaOhLu90c/W8nq74L2tlp5eO0Ws5N1wiMNWST+SVSi8fynbLbH2HDUkq4Vl+pF0PS
0nXyLPbJ5Z6j1YJt8CWm1J8YPX3NshDW1FFryzUrVTdWqHudR9hx1n28G6OtFktLSlhP6kQWrPa9
1salrKmT9LWy4ukb5fy4/fpoUZ+C8Z8EUdkhKcjLR9SN1oVNEskJJ8M58HJyuCkzL/fL3OUPJc8n
I6Yv6RKzEkMV/wCTlF3YovhH1I5Q7Zzku0clM3Wh2YM1Zdo3WJWi9yHkyy0zDEmzlHK6cn1IeTwi
9y/yUmZZu3I22KXJhpH1I3qSNrZdofcN9bQk2fUilI2yZ9SHFMy8F2OmbrEmzk7WbZPJe5FRkbW8
G60OmbtwrZdlqVUbZsvcjang7ng3bkdsjduFcjEkYZsnMvcjtYlJ4L9RDjBlykW5bTDsu/IlOQ++
y92DbOdH8VWVGdjlfay5T2yGoSLvqhbp7ZFPVG48HexL1Tte4T8WJLV+41GVs3C3SqaK32Nx9yMd
aXajMpWNaMifqHc7MNkXp3SPzOS1GxrT+hlsqce4caY5J3Fs/huhqEdp9QvUdpLA1CO3BcnZJS01
O1yfwx1po3J2rtozo/8AA1GO0U9zvwRhLTTryKaVDjKCTu7NwoJJ5srbX2FrR5RxtZUsG9coUYyV
IcZOr8lvPz+C1hijvSijufRvSlTeCpTstlwlTK9V0XKV9K09Rr4Z+ZPd0vS1Nhtnq2fJ2uvkr/qG
0XJ2cmNVqJme7p2zcSnOUkWYK9aVHc7MHbKSXwd83L79O1tM7pv9SzBzP9TLvp2uSRTv9eloy30o
w2f/ANenbbMt/wChwZsqN2dx24M22fVI+pmXgxdHcdrwZwdkmjvd/v8AB2ywd3TE3+hcm+nbLJmT
Mnsds2d2SkYmzls8nbJ0Zm2d0mc0YkZk+mD+Y7mdln1M7mylyYk0jubZiR2ydlucik2Yk0VubPqZ
2l7n/kuVnYjEmvucs7rZ22fU/wDJ3M7NyMzbO78P5aZls7io2ZZ39FVpHdJvpenZmXSocl7mdzKX
Jak1+o/Ud9LhaO6VlSZ2WfU69imVHLOaQ9+V79LhKi3KzOD8s7pMqXJUOS9+DvbZSRe5xO57jJcb
XyXu3L7lPDLWD+IzOTb/ADF7q/Ud5/DtifUXyUZbSO2RUuSlg5s7kJItvJa7kZ4P4qRcZX9jY1kt
yLUnIpp1+Jzu6KpmZNHY7ZtksCcrouEnfyVIpFytHwW7/QpmEyolzTv3MMikrh5s3U8nDZujE2C3
JtG6MWPScbyZ02cYG4cjXWkj83T58jnpKja8SLlC0Ptp0OM1SMK7Klp9xvivyvIklgvU07PU0lk2
bXYnOG5D2pJ0bJRFg7oJMuC7BYwd8UzforuNleaYpTSl9yeFhGxp/AnLBlRsbh9AsYO6j1NM9PY7
sW5q/kn9LaQ4yjUfBep2pnhm6Efy78EG122ZabIz0V3cmzZnyJ6mHXsamxU0sDhNCUSD1Pc9TTVN
yITmqRt1Wk/c0/8Ap5qV81/oEhSksF0jPuS2oucciLorpwNpEbXgZFY+5aQ7/fRh7kcHCHQtSS5H
gbR/4ro5EdJeRY6W1hM4GfBhFRHIo4OKKFKawYj4NrWDgodI3zRgtI2r3E2uRkt5jk8dOMmDKKrp
wW0YVdOBUirG+SWOqX8olRRhci3K304N00UcCx2iSRwYXJldG0jdOOT2HgyuxCVHBwcGcjpbS2rf
T6TP0ixRwL28n09HjIsZ6fSW0JMdKzdWPYSrB7ix5Fg27ujnWSmcFx/AsHdgaFFcNkW14KRcURbX
J8jx3lezoTeCvBxybZOi48EmU/JcRo7EfSjviLGCOCTS5NSXix70XFeCKrkTpUPZisEpbcpHcsoU
ayTr+oy1eBrZuY5qNCdqJDHqfERR9PZfgch7pJ0uBKGng3e8WRUVyxPFEr52EkKUY2Y/ZsDi9Pb1
S9yMpI285ok1nAntWS17Fe7E6XI5VlHo12LyKVLJK4WkzZC+aol/afcuK4XgrUVSbLpDltzXI9Pa
9kfIm1yTainXuenpLI7X8oqWWdseF4K1YtbnizdXDFJf0jg4flRZGUlyajSxFj0tGL+6HvXEfIvk
7Y3tNuuv4khtrgg1/SW49kHVGm5rDyazgq2M9LSwnmybmuIUQSjzyz8tcYK1v55eTUlFd90b5q3z
ZHSifs8H51CTiuGS0oY0juuS/wBBpr5OOD01wR0z3volH3I/Y3Ihpv3F0f2GJeGf+pf77Tl4iYGK
K5bIxrNdGicvcs2sjLwYGmKuWOh7hs2JG/UdjHNo4MI4wJJV0vpkSMGMFG7oyX3NtOxz1Hh8dHBC
d9LNsbyRc2XZs04/qXN2zPRPcMdY62+b6NMWOiXRjozk4MDs46V4E+rv26YMnHT4E66Iz0wZ6YKL
LF9zPTBT6YKL6frZEchpHcS6og+jVkZMT+BijzfJQ2iC9hOvJg2v3ogy3HPuYJKDyxS1XuPbAoLK
8ifBXqKRtcM+4uLFFDXyasfke+G4kktuDT9jHuIk/Nmpp1yxS/Q1Peztk0KU7ZL7ElF+BLbaoi9m
35JV7kop8sU5CUnWKFqyX2IxlGn7kv7CVkT6Y/oPViqrrp/cX3O7+qyVcCI/KIKNCH9ic/Ni+xP7
j38LJJLgiJGmoe/T9DUn/O2QNf7nezVriiB3cGkoe5Ih9jVmudxpH7R9ypq8Wa9cUaX3Hv4s0VDh
MkaX9pqTxv3Gh9j9p/uKnV1Z+0/00Q+w93Fn7MtPiyW6q3eRR3xjcRSU1J/Bo3KmnZqP/wAj/p3o
re8bjWk4qqonpL96+mi/kn0hXNkbMGfch9h2Q9rF9hJ9GyH9xH+0f75RGOnkUnwiEhmCvbpgUJc9
H7ikzI9vTfPkwQinixGDOBC6Y6bfIhiXyfoSZLPk/QkKUuClwNIcmRTZg/UU2uj04lvk5O3KEpsX
fkwPqkP8TK6v8KGV+4iMof4bLEPq/wAF9XZtrPuKihof2J1+CMRkkhJ5P0MEX7FpVgn710gms30r
xuIChtvJfuX7MyqHp6OT8xZslXuavp6jk/6RerDbEjepUqFsluLZOXmxuJKUvY0+nHBJfI38kfua
v9xBEZON2KEfODFOTHtW1Pkj6rbzWRv5Jv8A8hSrKPSvCkJ+bEl9O4l//LNT05bZFubkvgh6m7ny
feyf36af3I/LHKKtN1glKXSOzLoTnh2JEkuaNSEo/l3aZtfsS+ZG/Syrocp9F6X1UReqqaYiUV/S
TjP6bsjF+EambuQtXSfYNyfKEryhPS+ojLX5syzav6Cak70m8EYvwa2buR6+i+01HN5aIdywrPyX
TeSEv2jmLJdyyxRjmoEt7eyTNOG5dqNXa/qkf9TpS7TU3PmJHvWIkVp8/Vg0/VfdCXJLTjLuc/Ao
R15Gj6jt0fs226sl/cLUhDss/aL+Cf2/et9IS+SrHKi2uH0dPpH7GDPJ+hh+SP2GL4Yl8D/fRft0
ZXuyCGMm356Mg/ESukU+bGkNS9+mCrwRlWSulvn2HWCEVx0yUjf46VYn46bVmzuro2fqMp8NmERl
wkyiH3P0HRKUsmDLwYR7IU27/X8KgOunPTd0kr6UVfXkq7NxyPJY8lX1yzmyzngqxyGhrd1WelnJ
Sdm6yrK3C6LJ8FizkQp3wUSW4saHT/BB2SyWi2LP8o3HkR+hIUSPgaE77WzTFJxvIlwTbK8F1kj7
jg/cc9lSJSjWPHSDaNvyaiXG4e+Nktq24It8URzaeT1ElFk4J5vk9SUL+RL54J3G0zTUeLNH9RNe
5HfLaLdHcmJqG3I435G/eRL7kpf+RCC5vg3NeSaWcUKU+2SI/l3Fq+BPZtRsUuCT930shpzfanYt
RxUkyUYPa64HrN34OU9qzZurb9iovtUsGyT7pOi5pfc9PRltfBGM3aFN7X5yOMGlJ+w9XdcmZce1
eRvFr+llpvZF8C09Vq2zfugenouo+5FN3EjP1IW/DHDTdt+xv3W35PzJxi4ryT2Si6HPf2p4iLT1
5Un5N3qxNul2xXn3I2+0U/VSkbdGVtqrPUU7b9z83US2xJ+nqb5DnJ/ZHp/tEu2XLLhq2NLGmR/o
Xgj37ZGzRluTVM3KVP3GtabU4rBqLQnclwOcnlmnPUW6C5RGrjL2s7PqSwyGlryey7ZuX+TUj+zy
dtY+5LU1Hcn+64/DZHc8D8WT9rKjLI02cmZUXvHUkz6jDvJGN8D8i3SoqErL/fW8M+sdPIm+BJyG
lLolZ9aHTszg+ofej4sy0j60cmXk+pGJJ9OUcjG2JORakJWXuHmzdeDLMM3SZ9SsrePusp+48lij
Ivej6jJUpHa7GfUfWPNlNn8RFRefwKjbJlqSO1lTZbkjamcmZj2yss2ydFqaZiRUmfWrHtZbeDLO
xm7dgSkx7ZWclSkX6g6Zzgt6mSoSs3Ji9SQ9sjdZtm6O2Q0ngW54P4lSGoSFkW+VHZIu2bdRj2yL
TwKM5cHJWnI3pi38m2EvwWJSw/crcYPzDbbOw3PJXA1H/wCzcKL08ryY5P1FGVtJH8MrTW0lui5b
j+HZ/DZGce2hKcL+T+Gh0/0Nx6exOnyVt/4N0eLtn8NP9B7YIyzGVwVs2/YtjjDuiytiGqX6G/yK
F8FlxYlzFFY+w3PlinpumsjjN4bsbE9OVMpyb/UdSpNkpOWZeTap2kq5MyLm8/gwzE+3g/MnfTsm
0VObZfudknF/BT1Z0Zt/cwdupJ/B339307N1/wDid8p/bpcUZc6M89MTaMyb6Y5M7jgwjKbM4ZRi
Lo7r/XpiEjuUq6XGDkj6WZVHbFtn0HdHb0wrMxpFGDOm+narH2HcnH93n8fwUuS5IqPJ3I8nkwv8
mDJcDJ28F1/oMNmV0qJ5MmOS8syunblFvJR5PPS1ZyzlnJ9R9T6YNy4NshexmTfSlyXmuvaXJm1X
I4PJbO0+pmWzPWo5Pqpfc5ZkvwfVL8W2GWfV/wA9bbpexzfRNMt8jsqB9Vv5ODPb9j+J/wAnJjB9
bPqbM/gwbvB3WzHaj+KWjbWRNy2HLkbaO6W0/iP/ACYtnd2n8T/k7W2Z5KjY25SGjCszJ2Y46c9K
hkTk3Z25RT60K1g4yP2KRm7G43KJtrJeoqPy4m2hOSdGLs4wUi5JnwfBnB2oUawXqRbMJlw4O+GD
MLG9OND02hb4DlpcmyWJFzjgxGimsHwU4ZN8F2mELfpjlpI2NZLcdyHUNptlHAmuCpadSN8V2nyL
A7hUkuR6SRucbQ+zbQ1+BI3OKkhx2pD05cCZTgh6kMw9hULdUvI3DD+D0q7j1HWCSaVj03wdyiyl
FClBbY2KTknZlQPU01tkOL5X4IqnQ9y59z0YfSXPH3KXpyFOCp83R+ZHtvkq7FLRWeRetGmLdOP6
lKpfY3K1p3R39vvZUHGTRpvTWXkjqTjwem2lP2NWUYcInoshHWvdKQ5pWnKjUguPBCc42rIrb7kt
CPG405yh/g9D/wDW+zNWcYK+ET0XzH/QKUkP+U1NzvODC8DckLwX0YqH2kbRIUXXyYyPH76Mfdkc
dG0hTayzI6Q4+IkcDIxXliwcF9GfBSSKtDY0kfSZj0Up8GFwhL5Fg2jwbmiuB0jalyxYTZZNMRtt
HBRVljpGIsyiT1P06fUmIrCOUMf4FJq+nBL2TIjIx92LHSQpVyZFg4Kss2pI5GyqO2OC3HB3I3S+
kSrphFMteDc1lCMZFKjuaOT3K4KvI2VFCtDZj3E6Mj4H6aODbLkTrJ3mOC11oiOK5OB48iTH5Re0
ydqE9ubLocVyW4jUlwzKNRLwb9y7eUfRuG9u37kC9t0bPScbGPCeCMFo8vki35HKvJtatF8qiPbg
UkUuS9o3WUj0jKu8l15NnPgk45wJ7TtxaF8suvJuSyiWm/pOLxZKNdvIrRqe5qyaxZ+XH+XwPtcY
ex3rP4OLowv5D0dS05PkSjl7qOM4LeYISVW0QbXkUoYZqXiUcZJzSwzCp7SenqYt4Zu/+iv2Z1Ki
Hr22b1XF0bdLT2N+w9TVnJ3k2t+Ceo4XGTszAk4R4Q4bMRE32tDlHKJ2PZzRPUk+X78mmn/SOaRD
T012J2anqLNG3SeKIJ4SZFvNEYaUu+/8HpyeWqs3y5Zp6bxKqEveQ9aK/LuzUUiairFJ0bV/Uasp
K0pW0R046e2SIanvZNvjczSS8uz187bscZf1I/aXHi/38F8i+w0afs2IuiVEGWNEGUYJI3RZBsk/
30PZCr2GOPkivJY4ser4kWNEH7GPbpP3vpLo9OKs9TU+oZvZwjgyu1CpdL6bvH4dxzx0lOJtPW1J
On4KKjkWpqWijdyfT/wcHajYj1NR89GlkU5dqGh9VH3IRGSTN3uX8DiRneF0aIwIIsrpYzao3bFO
ZyXz1rb+oqVFdM/g7TJa5KeInycjV9vgUtuRjbESRngSLQ4oUng+pSOBfYkdxOhrqvsX7iv2E6JG
SWBIp+COCVH3NT7El4Y38GoJRk4ik1uQ8eCHsIuqHR+griRo1P7iSJIj9hIivIvuT/tN3yL+0/Un
9+n6GmiKRp/cn9i35ZL+w3SVi2k/sTZlpOitynfsS1Yqn+CO6VTP/QkovKIPVlWcDUXZJt5uqMy7
bNPY/J3OlkbjxYtz7j42ktODyLzY/WdEPSdo/TBGUl+jH/LghGXdC8xE1g9KP0eT81tahJ0uLElR
t8G9fVZu1c+44aSysZNPPgZNSVtI1vuYVpCbol+z6L/ML5n5PU1Fk5S+w5z1Ny8EVNborwQhDR+o
1JVRqy81ZpaUcbiL+T9p+48/yml/azUT43M0po/6b0Us1Y3xcvBrQXh/v4P5IV/QfcrnIrMMbIjY
6Ie5b4E7J9NP7fv18si/gYp+xuGMWn5XRoSf8zF9hkpfPSa9ikOclnp2vBH7Doy8GRZ6Loo/g/QZ
M/QY5SzRgqz1J56bYW2RvpVjHJrjo0mJFV4KsfVS9iIyRXsL7EkRh7jJCfNEGMaXCFI2mDfLo46f
+RbuTtKzKPshNqj6jkRaEnz+BFGENLkbFLbwRhKPx0y6Et58DZBjXwNcqxeCtxZRL2FGRMfX7IiK
/Yo1BWTEyTZAlRHHBNPkUumpguOBJcI36vNEC4+Bxl9N9HX9JpxV1Zpt80T/ALiUoq/sNzF9iNG5
raL7k/7SENrq+RX/AEiz5Jyirs7hvwQcOaFLUw2zSV+TU96Eq7F5Jf2HpwhujzZtenRNpW6RqX9y
tO/o8EfUTX3F70x/fraJ/wD8sd8EEvfpOl56afsUvYaaqmWh/wBhq2q3cMW7naLZyQU1RpxFKC7k
SWpH8u8Gnq7alyRiOcI2vA3OLjKilqNEfzW0hXyT38N4JRjzRNzXLI3/AEkYJ8sX7RD6WTjN7X8k
9X3WDb+zrlUxPXV+4rXLH6OX4JT1EnFj1NlbY2zsX6EdSUeCUZOsmrP/AMT9nnFdq5NOHkm5f/rH
gerXKohHyoMnq6n0O3ZoV5THrtfl7twov+o15Lhv9+it3gbSGn4ZH7GyxldMiyTrkjZI+zIx9h/v
tOvDF9ulCiMkerxfRsh8EV8dJRfv01JXyV0rx0USjix1gUN+BWxOyhS6VZfT015JP36MlfuMiv8A
yEUfIkcl30/UdDMlj/Al7kV5GSN8vJyNil0ZsIIYxI3FdK6UZPkbQo+o6I3JseTksaPq6YKbMDtZ
ODPAn6eRr4Gk8icptlH6ij0s5u11lC6MjXA6fVMtMsqzbfcZGrJRvkXktYIV7lpm/wAjV3g3uO4q
qJXEe159ivTX+CSqsEVuK5Rv21k58nbnApbFgSumem3zIU6uLHT8G8jm8G76WKMM0za/qeKLlE2w
dkYakqIykrTySjHHwOfh4ou7o3fQ0La+HgjFvvk+C5JFab+C3k374+7JRVZNRWrWCKco8e5u3IUI
eMfg3PUjF85Gt8PprkaUlJr2IucqNvqxf2JS3KViT+myEvWj9mV60cIlKIvU1Nshx9VcFwe6uGVJ
44M/tETs1UQ3Pakypa6ouOsiXpzjPBs1p7Ui/WTZJaU7Y5sj67ad5ZtjO0actF8SyVrzqRcHk9PS
n2szK0Lue6jZpP8AL8jWp7Ui2jtwQa4UuSqv9T6cmrp6d90aEtXSVV9Q9scj2OtNjzaZWy3R3Q7K
wjS1dPTS2Za9xQnobZeSvSsnHT0tl/zChrw3xUaR/BJQ0Y7Gxt5f735644Ns5Ep3SYkpEp3yL4My
oyx9x9WCSi7NrdDpmcFQf7/cVKeR7WJ/NlORW47RJvg+odMszIxI3LgW5mJFpnJe45OcHdM7WUjc
U2jDKbPqHtlk3Xg7pD2s3Wd0j6sjrkdYsq7ZuEpSOTkVHfND7ik8FFbizeU5mH+CL9hbmfUSrgSe
CvUO1jYk5nbKxTFbofeboe4t/BdnazvkZ1Ct2TdBlakh1JjUXYmZlk+o+rBbbGoTN1lajOxm98CT
Z8lQeStR4Pk7Hks7uDydotxSNyZUztVM2vk3xdCU8s7LQ2/wJ+x9OTk3ReRJq6wXwizbJbjbHBfk
Xlew0ofqdzs7I2Z09v2Ko3x5uzKspqhS3ZQo+x7EnJ8jUJYMf/Rll3kUU8I/Meej9KWGbZ8FsUof
UuCnJ0XJmOTbvdcHe+l6c2kfmN0XZcG7M3+p3GMnZuXwjulJI+p37nbqTZ3TlXyO+fwYbT+DEp0V
qN7un5bkz8xv9enY3+h3KddKR/NRUrX36dlnfaR7lRyZjS6UjEGd2H0uMbO+DXz07VbMw7elG5ae
DK2/fpcI2d8a6dsS9nSo8l00bZ8iNyWDMaXRbDjBRiLo4s7o4/0NJF0bPJdHprkvpl2cdMjWcGUN
LJx+/oTfBz03Lgt5XRRS6PBQm+lHt89Ul0p8G1FvHXcyzJSPfpSRuPfpeV0+Dh7ejwKKyZbG0UXK
zHXc8Lptjyd/Jj8KUVZbeR0ikKTtGBovNdaR8mLL1D6jtR3GTt/EpuzFly6PbE2UXNWdqFDyxPUt
mLOxG6aPpO2JUuDMWdsTikJH05HRSyXKNjpUbmrR3af/AAdsKM8fguUT+HTLisHBmBcFRtryJzjZ
2Qo20JtWfQWlcRYwVLTHKBVC3Qse2NM2UJtWZhR2q4kW0ZiiWppxFhi36amNxW1/B6dFuJ9FMqm4
kW0U4I36R9J3QTG4qmj03Etx/wAji4JG2u0i2jMBammu3yJ0Zgn8ku09PbcS3/gcdmRqu33/AAJy
iJYZugqaNko8CtpP2Y6jbNtXF8Clq9rKpM36a7S9SODbcWb9OPcinHHkW50/ZjqNs9NJtNieqtvy
Uu89TTWG8inqRwbfPyb9OPBmOPYqSp+bHsjl+UPS8WXqRocYLdXJ6mlDnwR1NWFihWeD1NNVt9ju
jwz8xUztim5cHpJVFMUtWFklBLB+WvqFOcbQtJRW9ktfTjXsOU1x4NupFL5KhBd2bPTa7LwQ3wiz
V2JSSVCf06XLbITT08x5P+nhBOXuxOkpSfJqw/pl/oFNo9sD8kaRvawccDa649zgljyPBJP3O1WN
of72OrJdpFGCiqNr5MI3NZMjaQ5NYF7GBKhJIryYLrJkwjfNZ6YOMI20UcF1kyNqJvaM9OMCVFHB
SRRwbqyZ6XRVYKG6NzXaJUNUXtz7mTtX4VNnch0PHAnQxR+TjoxOjIiyiyhLpSXTwYQpTQsY6cGR
texbj0wXR3dLRzRtrJZZ9NmENUb2u04JUW1bFjkcfkX2K2WbttEvfqlRurg2UcHFCiNob2nBhCx5
N1Dh5OMCtEdOvqG/BJ7fJhH6ELQnwbX7nBdeD0/An7l15HGPgchY8CaWaEpLyccjdZRLTf0i+wnX
IoQ9xyrnBJ0diztILUXcQtcscqyiUGrj4LrhESPoy7LyR9VW7ySklwdmHRH1FkvzV9YR8EXXKNOG
n9HkW5ZJtIktLEhLV5SIYsTSyScpboyl/gbawN1jaKMHUV4O/knS8jWkKOr7EMeTt8Dc5Ykzc14H
L/xO19sTuNWlVDhpOrdEYarvBprauRrTw6wb9STe5luPgUl7G/f2xdlyy/c1lXBGGnJpNi09R7qj
5NNVyya0u1+C5yve8knXg0pJZcR6rm9sHgi2ryftLrgjGN7fZEoSztgaKryamnpvY7u0RU23vlmz
9pkucCjvcoLHItZqsUad+LNWa4cv9BpP3Q6NyIouiVE/uWS9hN+5TMDG14ZFy5sY/wB7p9JX79a8
C6J/PV9ODA0LpF/PWQuskLovl9XQr6YGIwIz1z7dMD+5lHHS+lH0jx1SElwWh2buW2Ifsbn4P0MC
i2R9i0OL/wAHyWMrT5FLUzI56ex4FjHSkWZOPw2i3J7ejVna+0V8jycnBx04wYJiQpDfmxfbrL8H
3Qn7i+3RsRPpIiMXyMX2N3syBqfcpkiL6LpL7CfyR/tH9ydjof2IG1eCH3J/YT8s/wDUj9yd8IVc
WahFP2FXg0iR8s1Psd3AlLUqfsdhqkVLg7PB/wD4+sSP9rJtrgUvBqC3HaaYiKgqEP8AtJ3yX4NU
ip+WXE0/ubiChQvsfoa0X9V9Nc01OuTdHijS+45PhI0tjT4uj9CH2NeF96Yj9pNOM/JKa9jR+45P
2NHZngkaP9pr6X8240z9r+5DTng1p+HE0PuT1XxdGhKHCZ+0L5E9F15Nmp/TZpWvc1kuNz/evrpM
mUJ+5RIkvnpJDi+bGzkZJGSQ/wB7D7jY/v8AiivkX26PrZMXSH36yoQ+mpYukfv1Yur+/Vda6uuu
WXfR9MrwP8CGMp+OjQl7j+wz9SF8jMloUa6XRkqCwZMDik2vdi3mZ0xNO+tVdmemOlF0OMVk3TeB
YyV5LvajtYoenJv3E58mR7TJMVe5/wCpx5F70VE7vYlX4K80R+BX7GCVeTJqCaJN4IEvcT9hiXwb
VlNkLJ58lwyPcIxybn7lX5Gv/Eglxdkb/pP1Jy0s2OyX2IbeUbp4bZBX5NSPwR9kV/4kRvT/AJmK
zVYtnO0vV+o0lfklHyOTfb4JRvwQ+TTnDwyG/mzVdn5X1UP1MOhRvOzqpPCIK/5COpBvbeUQUnRq
vcuS9N0x+o80aUd6sUI5Y3O9tkouXBSd3EWrHjyhKTo1HGebobi6+w3qPKRCN/J6fKZn6bGnLK8G
1O1tHr3h+BRlLajVcZZbpCmnta8j3exCN8eTbzuH5ybXbl7EYJ/yj1/fIoTdGs+HJ0i/byNy/pNJ
fyp/UVypGHaQ9P6p34FCL+mFD1vMiMJOvg1IYjLUlgeu+USbr6SL21pwI7mnGWTFJRNTQlKvchtq
XbZLWp08GnuklUZGrJcOX7rH4tPTf8pjyKL/AJhfAtK+Rkvno8ZJIZqqzklH55KGrG/3sdNvBdmM
GTk3WclWXz02t9eejl5Zycm7pVnJXBycloyzkvpts910qznpyVZuHk5L6VfV5MPlkVd9GhdGPoiM
RjN75YiQpv8Al6PBRFewxMRuooycHBXT6UXYlwRH0uihZ567b6XQn04Hg/8A2C/LS+aL4Kvq/Jui
rsqqHhFWPFmSWeTHSLOcls2p5NknkTZJXQ74bNyyj2ItPgWcschqLNuo6lRbHFPgcZcNinyh06Ny
8Ec5rJu4ZWmzbN9zwW6ZUJGyb7bsjJ5TyNQdYN92WnVLg3WrFtfDIwnKpN8sc24s2wlzgUNSVxFL
fF4slGHI5bvq5LckvFM5T+xu3cPBHT1JU+WxvfF4LhhEYTmouMTc9aJSmpUzfGX5d5N8tVKV8HZL
cx3dfgqcsMuOqPT05eeRSvzYnq6m2Vm3Tnu+T1XLJs/aJ0ksEtk7wSbkJSl2CcW0OEZdopJ8Oxeq
+7yNaUxycnk2a9uNUhrRTuhyk+SsuPkx9X3NsZ9limpCWou7y/c26MqG7K1Y740NacXBtEtSbtsV
ZR9Kj8Dlu7fYU48o2T0+7+o2Qb0/lHJUo74/JKMI+nao3SdyO3Kuz+HQ5ybo3x5I6UtO2iMV2pf8
nyNV6ka4ZOFenuVYN3LJRxJPg+hIqTx8f6G4umKMrf2FOqo25PV4ZWWzKPpf+DCsbyjyOvPRsrJf
75O+BbmUWZ4Kz0tGWzFl+RWdqY2fBt29OaO6x1gUvJljoszIrN9MMplLguypMpJl2ZZjk5wfBTsp
F2Z3MxZdncztZyWZKL5R3HbaOeqO4wixXwjh9NxTRSVG4SfJVf8ABuRnJmNMqPJk+ncfQblhFOLb
PorpZUosrK+5fg+h2YhRYk+4ra4jmKO0+j/gqqKpn8Ir0mLV/wCCvTK2NfYUuGVt3G5Jm1xo7O4z
pNH0ZNy/wZ0rK20W/wAFw5K2NL5HZ28lbW6L1LT6VpZPzLRnk/Lz8FOLozydrMJs/NxIxyVDc0fm
3+vT8i6ZU02d/Pydl7jmVfYueOnbuaPzL6flSH6ltGS4XZlSSO7kxyXFuj8y+n5cpfofmXt6dt/o
fTLb9+mDct1fc/McsmC4xs7kypY/D2nfDHv0qN2fTaKfJRaK1FTMFwR3Rx8lIyrPpsceGi1k4Kmq
/DRvrA4eUXRfgqaKSL5/Q2TVM7Uf/wBi1kaS80fUzkbn4NqW4tKvguUO2+iSN+ft+CkrOGjh/wCD
vg690V/oElkU9oo+5uayRhXJbRVdMI2nA41wWbDC/wBB8HBwbVk7lkdI2ilJYMdE19PW5LpwNyiV
RhD/AAUhSkjguSwcFxRtSyLerMRHgrwXWShTmcGEUkZML9yryYiPrg3zWPY+geBYMxyNxjQoJcmV
bMRKSN01+h2xODuVI+hGEbRXFWOo0baLmrZiJhG6SPoMKhSaP4Q6gVETkrZ9IlQt0UzEC0qO6KP4
eC/TSK4LkfSNxEmfQJJUjiyvTQ+yulOCPooxx1pCckfQhyihbo0fSNxjkpoWCtuRJLFibicDlFCb
TPpwjdFZK24Fg+nJtksC2lNJjajTLmVQ5QWTuQqQ6WTZRxTGnE7V2EXNFco36aoTaEsMfbTXsbK4
LeGNVZ28NkZaiork9TTVe4pSj2lR/wADajlcFa0eGfVX3MPcj1K2+fwJVaLfbIcUlKz048SYpakf
A4xVnqxVMU5R5yUSnFZQ4viLE5RJRrDHujujZ+Z2+BuGURe39Bdu3BWkhzrjg7Y2z+Gd0aFtVicl
/klUcJGq/wDyN04UkuReknn3G4LPgjOSv7i0FFWepFd7fJ3OEnHFHpbFL3ok9v8AKR0+3LvI5bIz
+xFw0kk/g1qSSsU5PN0Nutq8kFuWVZracVhSGpaXZVJk/f0hpK3Z9J9Bq+rzAcorEY2T03p7Irhi
b8QciX3/ANBHUaEaeFRgU64MonH2FS8GSVdJYOPA37lKPCNyQ1++hL3HaGSb8HA7NP2sRRKiDrlG
RHB6fSikr6YMma/Qqjfqf4MI46LHTdWemB/JGKq+i6KPTdXR0jauTPXPTgpEdxdEqXXOdosCicGI
lPo3tyZ6XtODacHBtLSPpMl0XtOCqODg2F0cFbTKLSMo4LaPczCi0ZeRRSstrwJLyyxxo9zdWLMo
vwhbXYuzAm0NpHajvWaJmeiLo2F1ycG1cDdEu0qPNC3EcF+w9OS6XXgUFwXXJKVeSoDb9j1JrjkX
oywL1ZJqyqy2SxlI2/yideLN1YsqGMjbXOCTrgW1U6FGaI2vqZJ1wShXZ7l1whY5IqHFlyWWybrg
cYYwL1PCNPHLs7VlMmnmMmSbR+hFR4XgW7lmovkahJx+w03u7fJKP/j+BeMk65J+q+3iJpzrCNIc
4yqN5Q0spi/tN8HTo9KV+ob3y2TRLT1JXF8G67yLxTsaPy5OMk+UU3aISbp+bF+y6Xd7sUpvb+g4
epFv2OxK35E5cigl8Gp9ialjLNlckL5QtMx/ST15N8i/tNdQk45oWtrrd8ku6scHrxlSXFCg22Qk
1hMf7PF3OUv8ELJL3Zqfs8Zb7W09aaFGqmTf/gb2tzlkjekJRhV+5KUF9ckOPCcaHJbbYlTzpjf+
gX9xIb8kIsWCVGoKx0TXyKzAmNmrkf2JfvYRfuQSHXS+b6MUn46OjbIivA6NhkvyMUY3ybpcnJv6
cotcC6WZ/AxDFpjLMvAn+DgbrpV5O1EdxwOkb2si6PrqC+3RDI/fqxdWR6L8TH9xdF0ZfV9HRuke
w4pjXlilLuZKNi6Skh3lWJtFRJm1iyY6c10nXVfc/Qj8i+3RiJiskQ6R+Rn6F+bIfYn9yR8k18Hf
KmiPpys/Ul/aR+WL+0X3NS/AiZAkkaX3NQj8j+xEm37kfuapGyVGkMUfJI/9STfuJk5eLJPUiXDC
oleXVi67Wldk5eCcPEWRW3cn7kGLTS5LXJ/6klV9pv8AcUXXJKXuU/p3UJrBsjG+6hyeBRh/UXPt
ayS0tF3flEnqXufuSa/pNeUJvcmKOou1eS5T7hbJbmScuKJbVhMctJ5og9bLbN5u9oktLzZFe6NX
WkuZcFPsfwb6b01wJVkcmrpWKEcakuKHqSfcyFu90jWlpy2Sj5P2Zzy3yXWbNeLeEzU/sNP+0Xra
e68IvS0f8HdDa7NZw7Wo4NX1dRzo7lxpD/0Dj7SGUeo+TbfSaEONE/kx7EtO+BP4GarflH6Ev3t+
xCbGNtk146M04ry+jLIMZnnpFeOm6ujxgpjJOJczukhSjwxdFXuZ6NCsYn0ZaIxrBno6Fu6Mko2K
Mvwquj6zvyL7dEMXXAr6OjIjH4MGejrosmOrOwW/mumDJRdGyKHOV2UzcNRIUZJ0fJUetwbsjulc
CN8mB+kLf7EuqRt+BPwc+BZO0p8mpnyWibniyGRo3vhHJ+gq4sj9h58ktg9+GSjydnYL1HeRX7k1
8EWvpQrf8pHPkk9PyypGpkjXhG+ZpR3eSa5s3/yklfghTvAnF4vgjbyma3cuR7fYe/2NOO5Gz3ZL
WbtNk1Z2u+0WpH/AoydUakr/AJiW1krfg1I3mvwRfGSaNW8qT5I2af2I6i8MSL+CSXO02PwQ+5JG
XalKyOfIp7niRK+mzTlWPB3Scm35FqdqHFexqamVuY9zXbkns+kUqJL4HFvkpJ8EF7CSdlJ84oep
HtbyaWgmpN4VG6uRSk5bL4J7l4o0Y6Wck37RNKuSMF9UsI07jVM1NL35Em6WmyCi7bZLX/rZrRjn
FEtGXMEaba4yLt4Iaek++U8k4rug8EnHNjjL6vTpL/Q7Hw2bm+SH9O4wyKvDdHN4N3uUXQ301L4F
npcRqxv97GPuR010Zfl9LN0v5ejIx8EYrwM3CN/4MIro8IYovyRiizkT6VYuiihSq2UWZLUelX1y
+jwbivwWUPqmJN+DA8lWWclWLI+nPTDyJSZZyUy0ciSeBZ6UpFNlnJz0eTkWRuzbZVn3G7G/Bzx0
+TJJj/pYtuSryZOykWVZW6+jQ0uqaFGb7hyGosUdQ3WhqLOcMUrMMUovhiTl9xvcios9PV/Qb3Jk
oweTudxsT3pMpUSlqZRF+rHg3R1E2OKfAoa0uXyOS1EbYSwd0u0jL1FdWxqDPU3c8nfOpcFQmmbl
Lgjp68vmzt1FkqLwVJ4eBbdTwShpywb0/Ni9WdTbK0pJkp7u7wRh+0P6US2ang+rBUncWXCTv5Jb
JYIx1W3G8n/9WS9N069xtu1+Dbqafd4aKLXvYnOG5CqNUflqjfSk/ZiXo7aVYJRUe9jkbdTST/8A
Irbg3f4I43RXgzpZGlHbY9RqzMb/AEO2G02rFG2a3Ufw6/QSXYZK5R9OD1k8iWz4ODc3+hFwfBt8
i1JZkjZuwcjqR6833E4QliS8nqavImvBtU7j8nJKb5ZGenP6fBTkOMdSk8ktXf3yF3/8iuX/ACPU
8t2bdOeDOp/yJ6sr28fvff8ACoq5Itql8lIuf1I27WZRmDK2nBVDmvqYotfqb/5jbTMv98n0+mkZ
6VyZjgtFIyqRuMZPoLZ/UZgz+k4s+mjhl3+nSjksSSsqulNM+l/cuzBW3BfkwrODKPc+hlUyylk+
mi91HFn8M8o9zETuVHbyfScHd+DtK9Nju0WsFKJ3LaWYVo+llyEoFemzuO0pQO5UWYjbO9V07MlO
PaWy4PJTjg7sHaytmDJkrTK1FRfkpZRjTNsngb/mKUcHeXB0xKKbXufmcewzbC6N20qR+XZ9LaH6
mC9Pkwx7md/P4PynTPdH5nJjk7Hg/OMH5Vn5t10/Kwzubo7jt5PqckfmpmDsnJHe3LpenOjunaMn
Zyc2vuZwI7eD8wwdg5SyU+Sol2VJUzBaZ3rpcMDlLuXTtRdmyXJgvwd/HSky4/4Ns1T/AAbaZaZU
1XS+C0m108xNy/8AoaKpmLNs0UlZfH3G2sdOKN0Smq+5W1l2z09VZFtW4txN3MRbfJe1jmvA7wz6
O33LirZs1ELarFJwaL24NqG3EnqR8eDb5PotGO1j058lQVik4OzKe1mBPZglqfyoSgrs3bC6FccP
/Q0jfJH6itH0iclyVRwcCVH05Iw2l1kjp+5ayN1+/wCMI4G9otNckXJZMRKN00YiMT/lODCFcTg+
nA3JYMxMR/Cl5N0lkwjdJH0GIm1IW5ZMRFEWFZiJwZWT6S1E4FOaPpGbS9o3RSViwcUb5r9D6UfS
PHWlyKWojgdIuS7ClHA3RSXaLtyfSYRclk4G4ouSODgyu0SSHgSSFaOC4xN0lZwOkLcsCVDwJJCx
k4MItrJwOkXJGIjwNNdou0faJJYbFg4wXBCclkpLBe3J3xFXA8DaXVUKTicDaWTuj5KofaU1hC8M
4sVLAm0cG+KFKUTwSqJTWELhFUbawzuVGKkboKhSnHBSav2Liqkd0bEm0iS2/qbax7HdSO2pJicV
huhSnHHuVCSlRaj8m5xFFYkS2xGnbpn5i2yRhKRHauWKWpHDH6eTdFUzfKO5L3NixL+kfbZ6H+CM
tSF4GoDnFKMkusYoWrJWvZnpQilI3bcvNlS5vyRhKMY+CW1Jqhquw/MiuOT8us4E4YzkU5JOvcek
q3I3JZ5LmqZHTko+xKkmh87TvUaWTsSSkRcV5I6j/wANEtFVcTfGOXmy2qZDRdXLBJ0mqGtuFwdz
qKMVUxT29rdUKdVglpR/lFKMe7kU6/UhoN9zdEprOCSlG/JzRHjv5QtTaqb4N/0e5qw/pWH7mnKK
2+WyOpt+xD9ki7bdP4Jzq/CNTScopRfDZ2pKRqfMhOUcuXJqz/Z/rXCG9d3bNeTisQ/0O726UuEy
/gXbgo9NCZlG04FJLpvRGHlDY/3ybXz0o4sTGmQUfMhUvBkdEcdFEwJJdagtwr5KSM9MCnNZOCkj
BgyX1sryXNUusY6cbyS3EYr3EZGLUYlRIryZ9hir2ODuJdc+Cyjg4K6cdKZx029ODacHHW66OJwc
G3wXRdGOnBgqRwXRtLos2os4KRUjgwsm2RdF0JeLN1ZNtW2XGVHe7JYMdKH9jayxNFLizc+SToSj
g7vBEdIcHwx4MLwQrgjayXXkqPgbkjPsLaKM80xP3ZKvCPhix/KKSO1/TI7+Wyb9hKPlC35o08E9
vgk28NkrWTHsKSeEQ3Go68myA1L2IYOzkVvDfA38j2qu03rFYFuy9pp1G0aaN0ZUryvclfD65Xk1
K/pRPVbfODPsN/JtX0pkovJwKK9iCkQx5JUamt/Uz7RGLykOI2KK/mRBVRp+99Ja3NvAvt03umok
kT+wokIRNN/KGjf7kfsf5J6jrA6NX4RCEsZFpx8RNP8AuHB8EJxzu8i/tNP7GrrOt0T9TXcXVM0X
qT3Wal+5p7VcNw/+olsz5P8A9Gkmr8GvGMcbcv8A0Or0kenfkQ6FI+3RrwJ9H0fs0foP96kJR+kY
6Yv6n0dCciP2HRTeLFXBghGPNivrS4EMcvHSUeJCeDBX4n13SRjBViS5Yptdw8i+OjGuUhY6MhXu
K/KGK+iGPpIiOhDF1Yuti6R/BXW/wUP8K/Aunz+4XRP5P0EvkjckmdmSd9UfoQP0ESIEumoR6Lo/
sRfncR/t6Svp+hEmiH3J/Y069z9CJqtkDVNOyZpkiKRMX2JLzfBA1Pubn7EmQEzt4WB/cf8AaLT/
AJmxf2sht4ISFD3f4M+5qf2npfzLkz/SfqO/OBtkiL+BYwaefJKvYeio7drP0KNjj9WLHJkyM6ui
M/5TT+5Jo9LY47WK/Yx8np1iY2/JqfY056cd3chakotYNNf+RJwyxacobWhe9EfsS01C1PyWzW+U
aM9JblYpzXKNL+41PS+tEI60Nuw/Q0l7xNbSp+nKXIvuftDjlNmhfJOv6jR/vNbbzYr8yP2v7f6H
Ut0KvYnJ5R6j+5tMEZeDBtFKuekdO8FdFqNc9H++djGL2KGaW1/zEP7R9I3yMjZghXuZN1GDyhxf
STRe44bN1Nffr2memDJXTah7uSKfgRtIU82Q/tGarfuYENka/qI/bokYYtw+rsiOQkNCfSjBnrbE
cl+OnJgyVZg7jk5N3R5MGSrMGemGbjkavnpkqzBk5MM3HJh9Nt1gurE4y2lXdE6H1pZwbjD8Cp2Y
9zayaUjB3EbkfDPVs5MSvBF+wk3VIpSvIxxkNblwJG7wQW6qkSp8nqWVfgjUrOfJtbyjVW7JXsi3
5RprcYfJLVsknI7XxEUvIk39JNJ8yHu8kl7ozIhG78j1F/VZ6e6nfBLbLxR6j5RTfEWhatdppm9c
p/gTa8j2PEnVHrPEjbz28IhHdtZepxzZJKSdEr+l4Qv5lRcWacVVKWWUpXu8D1vpkOEHcmsURjJ7
WjdqRvyOKmnXgnKSpS4M90R124IV9EWRj/V4HqfSPS05brFpTdNIU9WF+RrSdy8RHLVdeo+Dc1cR
tPaRlfZF3SFFu2/BKdV5J6ehLHuLR1H9KwLUlFe5LS0W914RN603JzYp1vXGRtPa+MC/aHLti8RI
xnJOTy0yU1SpXglDR1Hs9xaOrLEVSFPdH3Hofs7d34Jz19VQnOXDI7dWFL5KetBrzk0tGLWxd2BP
U1o7J+D8rVj25o1f2XTe6Uuf3Xt+F9NyZ3MdURWODsfBHc/ButWVaGxFEJ3gqyOcWJR5KTL/AHyj
a+4xsUniTORly8CW5YGJeLFFMw0ep7CTYmjkWT3OUcnJyh8MX9IlZyZZdnJhi3M5RV9LsfcKV4Oe
m5n6D7h+zZhnOTkx05Ks5ORqy+m5FSZd4HUjueC7PqLvAlZd0dshJs3WVFlSZycl3guxuxNPFiTZ
usag8lTeTcVFlSeDkdPIpbsCt5G7O1m2bybrX+RxiyMZysvcios3OXaxNyQ6lk3KZWo8mJIqMqNs
2Xu/5JKLwbdX/J9aHU0NXjraZGOrIbjJMajIqUriXvSY1Fm+xb5JMqErLTFHWkYmv0PqwbZvtG4y
Q4xlg3JkdzqXllacz1LyfmvJWnIu8EVrO4eR7ZV+pWRvcxf1V7jUHhkZ7uBLW+q+TbpS/wCRybI+
p3RSqjs7Wc4Fl7fJjt+xLa8MUlLKIwnG5LyNadxLcipx3KqR2ujc3Ys2rujbspmXgTS3L2ZVOP2O
Kr8MZQzXhlVX2NzlZcXTNko3ih5E/JtTuJtyi3yKWlOq8FOVIuUrZcXRtu1VFz46bYSbibZyW0Ze
nqbSt6HKXJcZOLNvq2jdrPc+n5epI/M1G/jpenNop67fwW+TDa+xS1mkbpz3PpUNeSK1Jt/fpenq
Si0d+q/06XF0fxZG6Tt+7LTcfsfxpGdWX+S3JyfuVDUlXtZmepku/wBX+6vo/wAX5R+ZZUODvkVB
4LcrMXR9T/wZO6R8nNHOTtl2nf8Av1seD4MsqLyc4O5mHRh4O7p2Hc3R3HYZ4KZ2nwexbkVE5O4+
TtwvkqUumDMjuydnBl49j2Ki+mWYyzDwd7vp2t0dxnkqEmZdI5wJRPqpex3PB9QtrdHezP4O10fV
cS5yvp+XPBcnfStNnc2zJ2cnLQ91tnYYnSO6VlIuMqO+doyYlR/EwZMOioajPzG2YMTr9TunuMl6
ctp3alo+TGCvUdHdk9jGrJIuUr6dk3H7GZ7vuZO10y/U3fcyezP4jr7nNmDGo9pb1G/1M/gxgxNn
eVEvcNvK6c0Wm2U+T2LUhqRRdsprBR5L5RkzZayU1RhY9yx7lgwi+BvwUcNFq5G18nDotXFlTKSN
1Oy/CElkuUXkbj/g2JZR3pmFk/8AESWS5J2UxbY7rMxZcY5NslX4Kii5adG+N/Y2+S3p2vce3tZt
ngxDcj6KkZXYzbHLL1NPJvghN6do/hscoqmh6e22nVC3abs/h0VXZ+DAu09TbsxycWhPbk+lWzZt
tfBckjhWek8pvtYm6kjKiiWpp1ge5IT7TbFJzNvCHFtRS/qP5OMi/Z4LL9hObXHk5gx6mkld0h7p
RlWP1NXWW3tXgsjLhFynEpZkyTX0Ln9++iSN00OlwRsbiiMpIzwcFULA+0X3PpIquWYyYQ1+9SWT
dJclUOkXJFUNpCjWBGEbUuS5LPRtRFKeOjpHGBYODbR3c9MI3yj0ui3HAkhm2hYz0wi5q/ucGEbp
LBSWDgS248kVRwccnGTgdI3Sj0dIyu1CSicHH4M5SFUaHgUF5F2nBwJtWcDwbmj6SqPpKPczGzCL
UR4O2DZ9NIyjCwRwcHB7DoWBLacCfsfSUXRwjJfwUkK0Y/wPAoiJHbE+g7oibWDLRccjdcddtWXR
Vqz6S2ingeLR8HeqOzInXkuSGoZHihScTb5H24H24sUZ4HtyjjB3rB+Xmy68m5rgcFyfTyK0KE+e
CTStD7cH5iPylyRlGNWxSkkSjBdywfTwb5LgWlSTH23uH20kzbOKG4LFG99l5ZFOMZfIkoJJsfux
74/zC01FUiMf5d2TT1I6sXfg9NaalK+UPUkqRqbPf8ELXInXGDUkqdDpdvJj+mx6eN98Gmo+ZCml
VGyeB4VuNohuQvZ4P6i4kdGCvT8l6i5K1O2T+lxNv7G90Td+0ew46a7zd/8AsP5hblaIyccCSj3e
5IvarRX7M5LPg3a+XRDGbN9VXNGotSLSf0nrbE6yjbDT2Sqv1PUc2oWd/JqySRpx/Z3OMb/lPzea
8mjGCp2Qkk4+9G2bt/J9kJxWdhq+o5enZHf7E849Qnpf1cl8xP2dfFjX7O3GV+DS9aTlnyay87v9
Cov2FWMEoLB6b/lOOkIry+lkIdEyR8pi0ZPyPH75RYvsR066cdLZdGEM46KAr6cY6N0Y6XRgcWLB
hFdL63XSmcdFD8GS6MGTgwbWLHXPTBTHj8Db/mN3wUyMvHRpiS9yK6NeTPuWin1djYq7UZKODhFU
dq/G9p3G49OCYpNsdmMikm1Gx7nmhL5OBm2PJuaz7lDj7ixk8FtWbUeRr4JdcryY9hLwxWvBhGOE
zu8knRUR7skcHabZe5wS2qsEH4Ip+xxke3wXLJLBFI2y8ELXk1NuDc3hjtXgjSFTxFkbJus2bYus
EreUjTwOh2+WPBj2PUbwQXwS97HCxktuMeCO5zf3ZuqpRJaUHYtK7TZCb5KXmQowbj9jfqd33Jxi
9rG379Uvc05eCXwShpy7W8xPVcot8tWV7xJ7GlNeUQ3tc+Tb8+Dc2j05z7bqyNNPGKJbvBs0u5Xw
K+2kb5asd68H5eaNrzfApzVGP6awerqPdbqN+Dfsi65wba9LNCUpxn9hUvBueIkojg+Pc/8A0meT
8n6aI7+LM8GkoLyanuRx23/kUv4bXuPQ0JVX86Hp68qvyXPU3M/J4NNtbqZu+kc34PyZJJLNieus
bSenov8AMI+kVLnebht57RRUljhF/tcSEv2dUmSnv/LU+P8AQr7FDO39TPsYIX/Ufp00peCymyTG
aJIv9/p9WL7dGSfz1Qui+/WQushdI/fqxdZ/cXRC/C/wSI9ILrIQx9c8o/QZtfv0kK3yR6MsaIr5
6LcOjKtHFDplz5Ny5Ns49vubjHR9Kkdpn8G5ofgqGUKNCdDjZukYJG5830ojfuRo+rBV2WdyN0fJ
Kx9P1P0IDESXlkCR+hMXRdH9iEfNkH/49JsRIi/BJ+DT+5M017D+xEkvLeCBqCfwajNMf3El4GP7
EYebIP8A8SX3G/0G2el4ZbS4HpaP2HORDDNMhX9RGUkU/ai0+35Knj8GnfA6xyTlL3HXkb8+mTUn
g069zPuV/wCfTT+x2YdMTkQr2IJSlRGx6klaQ9uWuEb23FexBT/qJV8m3ZP/AAb1MUN11jIvV4bJ
OBJs063Pu8Dv2NL7jjpfUQWvzFj0rFKknVj/AGXRjL039TPUX/0PTrKIQcJVY7xgjXg06zkkTb9i
S/8A4ZrOUKViv+gv/wAyO1X3GpZ/6kNkd1OzQTW0l77v9DCT89HI3tcnsN8kGvfpSIPzYyFPljv2
GR1fYa/fKT4E0zf7FFX156MuzB6jOTk+OlWYKOejl0qzcUbbMFHJgbOTDN5RV9asx+BzFkqxS6fV
1Y+tvB+nRPwhkhVzZp/bo0RH9iH36J2c9bfSjcx0bFIj6jyPJyX0yzBYo2WU7ouivk+Ris/QmU+b
6UIqzl/5OX+pV9K9kTL6K2YeD1DkVSFIqyS3eT3H9iPfQs8nq8H1HbKze/BV8CgpZs7spjimNbue
Bexv4ILd9LMP6h6rGr8CSfCE5L5HFPCJwv8AmL5jwY9iPsiKTvyPUpKXNm2L8kqdPijfJZRtT4FB
v+Y3SjakSjGXgcxJG7Uh+okttslqONw3YIRrg3zSdZILFl0nG7Mx2yJRgluvrGPuablVfc24fk7e
H4FqWn+pLK+miU7W9EXaj92bG1aY22qfAoN1nk05Nxyvc2tpxSJbFcUKMZcRPWco2Vdfqast6yzv
1I0P6GR2uP6EN+rFR+5cZabR6WjXqfBFN0nyQkteLHD1Ysnob1FNierqxJenqxlSFqaLraKOrJRa
Xkk4zg0s45JTnOtLwiClrr6T1FrK/kpakcL2NWWtNx3T5LjqxNmg1JvGBT1p2vcjKeuvcj+zet9b
5Q9TSmpau7wOOtq7aVFw1Y7j0v2eXqSeMeDTWtPa7yytTVRrf9Pq76jde5PX1sQaqKI+tqJuuGJ6
WrsJaa/hRfPv/ob8oUZvgrcmJXwNJm2TPqyVuSPqFUkPuNOafDOfBh3kSWKRUXZn97aFHU5ORqLO
54MsxIu+0Vs+qjtZU3Z9WRqMhKTwZHtZuvArMMtFS5LsdMqcjMqHtZcngyzDLTO5l2VFlTkclJmZ
dtmZGJG5CtmGdrKm8nI1FlN4OTDN27DFZiQ84/BHc0it6LTsyVuHmzc+Bd6Pqsv5Fboa9RG6MkVO
VFvUids7Ms7po/iRZcWjM6P4sRqOTcRuVFepE+rHud2ojt1UzD8lajo7Jpm5vtK9RIv1IlRnFi1O
EUp5G1wXIr1TtlZvi8C3zpmNTHuXGeSpujLHGE7PzH2/czK39xrTnn2Lu+tm2Uit2TtlgVcFN5Go
ywbtwlNlQZubybZ8FRbLvAs9vscNMxI3JitcKh7W0XeTbJ2NR3IcpeRNd0fYrhlvg3xu/g7osdSa
sUvKNnKMKi3lnY7XA1RchSg6rJUvqfke5mPAocpcHfKi9N9LO9myM243xZyPezteDk+S9V/P4NsZ
vb7FN2i3yflz2/B9Zeo7ZcHRS1XZ+ZKUvuWVHUx7H1t/ct8n5ba+x9cz8ybaOzUcPsV6sz+NP/J3
vd9ylqOj+NL/ACZz9+j2Tkv7Wd85L9T/APaYnM7pyr56XHcvsVLdXyYMSkfz/c/Mv/Jgw5HcmUuT
y18GdOX3Pd/J23fwfRIzh9MRs7otdLVs7lKP3/d8fuFR3Pt9jts7jtwVmzFmW/0PJ5MnOP8ARdv/
AAdzZkpcnJmyi42jutjtFI4MlLk89bjuRlsplmbM2VEzJnkwX0yXEttjsqN2XudndkpF7mZ6X4PL
+5kwc9NqRdnlmD6qPqf4aQrk6Z5fS90qPqfSo2jLbMm2JcpPp8HkxZtRlsw3+K8pHufBlsxZVFtH
BtLlZyztO5H/AOwtHweaPI/HXHJukeRySyZWDKLijP4Kid0clxRtfJco2WoFSE9tn0nwVHg7oZHs
RulApwLjHJ9Ni3aeTshRVY/DvcLQmo0Xt3IzpDqNC0i5QsbjGmem1kTlp3ZnTLgv0M6f/BT0v+C/
Tr9BR92XttGYUyv5Soq0X6X/AAUl5F2ly00io+5urd8C/KJdtM2Sv8FLB3wvA5QxXsenTuzfLj5J
YVnpy58EXhfcyootLtE0juSZvguDe6/U/lG1HuHHUdNPydzizwyWOz8FRVsUpqveyU4pX4ojKb5K
nqxQ9lOvJHThG4yZeo6fsyVU6Fpbe1ilOS+zNq1FKXsbtJdz4o/O7WhRepFMk9NbqQ/Vi9rFv1Nq
XuVpS32Jxh+TdMvV7X8lQmpMU9KPyPTis8G7Wiv0NTUjHKjSFj8sXqxpknox3SeEShqKs8/6FIjK
aK4SG8cjpD3RE2WVgRwYRx4GxfYwh/vVHyxTmjgbSLcRKjCsWMCx0VItx6NpG6SsqjCLrAlRgtrB
go4NzWTgbSLawfTQ6RVCVFUYXJlZOC0i5I4owj4EttHBwcFGEW1ZnBhH09W6H1t+BWeCMPdix1Tr
npKiT+TJiumeuWjFDpGDjom4iwWjgyXE4PYwW0dzopO2WjOCrX6nubV7iwVwx10+qyO76RG3k3I3
NH0m5EscfgTqxXEe3gVcMVxO3EjHN0KTRJNFYN1fJmKPh4HjFEdP0+Td8Wbk1digo7n8Dk1TZNQW
V4NztMw2ZQpNFR58kMcog0uUR046W63XBGU1ySnXBjhFpLgjLUVfIlpTX6HfF7b8jbrkltmsIUYL
t9y35gaS5RClTaHpvDbJpZawRklRHd9TFp/+ZdZWSenowe00/XjSs05RWWacND6HLJF6qzY6X834
IXHwRlEnNpZdUak4q42S2KqQ9PUfHuaO2sM03XcOM+LpEo3nHArj/KRnDjyXh28o7cdp2Tfpi387
bJQ2J3ncR9GW2G62h+s8/I9DRpyuxb9Kn9jMTsjYtTVj+otOLwiBH3I+jKW3d4Z+Y7YvgvT+qhLW
XL5Y/wBo0+2VXYobUm1VxPW1JNtlN1JIlpwjiUrizT15N8j3l6Ev5eGRi3S8kZM9P9nn+Zf+D0n/
ADKsHqO5SfuLR/8A1jjtSPWnFOUs5FprtZrf4I9ixES/Z243zRo6Wq7aVmi4xzKXP+h0Iv3KRtvD
Ixf0ifgbRXyL7G+yEfnpTGkSIK8N0X8DfH73Ri+DBD2b6WOjcMwST8MXSKvkXRvrgdljS4FK2Kzg
XV7TJwYHEXRIz0bXTgdDvpg2ivour6MfW/cT+Bl+3RigQLQ0+jaEn79L6PaXLg9ii6XSqFgpDK6e
3TA0xtcjgp4E5c+41Y9kqQtTVyUJX0tcUJci3HJuQ9PeJtH6fgn+CJKicD1CvglnAvuRRafybXln
/qWiMfY/QjJj/tIwjLF8G7U/5HGJ6j4E9RV8j9NkY1eRUs9Iz9heKRGW6PIqNX7lP2HX2PnYJzRX
81Wh6cfIly2RnJUVf8tC1G6r3NP7DcZcCc8xZwqoU48H/uU+B/mJyN0V8kVJVt4E56m2XsLZleB3
9N9Y732+RenK8E3J/Ya05dpz3E93FE9PTeUR9b6m+SG36R+9f8i9XMReld7cjc3kfoypWL1PY2X+
Z7EvTx2koPuTN04riz0v2fuk1RCeorm8serpfUkR/wCpbp80JRznyRUaWPccrts7nSR9Vx8EdPVh
cm6HLS7UPc7wQ3cEFCl9iS9yOpP/AJLpWvYuUuxcWz1NsZ17mnD0VveOCezt3LBtS3Y7hS/p/qH+
z/s/8b4Zl7tR8s9TUR43cdpDW/adSofJpv1oJm+GqtRmpHUe1PySUHcVE0lOSW6Xk3R+naaFcX/o
dH+4bE/Y09pG/bp+pH4RIjJe5j+kSbL+CRo1/Ufp++/Z/v00v7usiI+mqR6Q6sQ+kvv0fnIoeRdF
9+rXW0SF0j1a6s/Xq2IZH79X0Y+u32ESRXuMkbvkg/cfSv0JfYgv/LpVWfoe/StNXI7zHsdspV/S
d8TMqMSslZj8NlG6ilyXbS9hKXuXQ0mKQh0vFH6lvgrd0erDLIwlAjfR7BOXLNT8ER15HeMm2xy/
8SvD8kNvuRbJm7yPd7CS4qyUpeTt/pshG3s9jP8ASeo0Uv8Agumo+zJRfNCr2Oy4EdTUlv2lNU/Y
3VVCh7mm/dGko2o7vBp3yT/uG9PlIe7kjpfBdeD09NSS4N7luRUudw9vglp7sIi0aXvtIf0i/tI0
Q+4n43mrXsatyltHf9JE09t7N3ghfNj/AL/wL+07fZmeT9TWr+k1lLzwadGlZdXUujv+kx/Sd3J/
6Ep12kU/6SWu6eT0/wBng2/gc9TdnkjpyJQh9TiyKcMHqRlKIq1bRepLdghsZH3NOcI3HcZK3eBR
0+SL1W7XuLQvd9h+muFgnvxpf0EZbKZJuOfBDasWZwyep5HD9lWZIUtem3yZjy8EvR5XA9TWz8D1
ElcVZUZtL7ilJvkntJ6ep26kVtog09jh5Fv9jT0dGW70/q/0OnL2kc/oM3T8MdDp2fIo/HX9C0+G
Qf8A4jZvfHJ+hJJ/vdPU9hd2WbvYqyt3Sir5MDfllyZh2bzkpS6VZtsx0pl0buOlWWVZW7rVnJZd
mGbjkrd0wbbOen1FXZuMyMMs5Ntj89GPru9xfYZv9h/YkJGmvbpj3In6EZezOfHT2OSkW0exQ20X
wUpNIWc9K6exz03EY3yYMo3URS6PokSskvkq7wZRn/7O3IntK4Kuz3M4JJPn8EWyhv5N/wAjf/iM
TIxeKJfLNnyV7ornB7WPa8VRHUNt+KEc4M0TjurwbbXHke9KioPJHd7lPFo3f0oST4Qp3H/IlfA4
bu2TuxSbWfce1+PBbklXuVvVG5yhIe2iWdtz8ksr6jUmJuai/kXeu1D4ZtljwL8yL7T0t67SEnJO
3Z/FVSZ6q1Yk4JrgSeoo7Y+Tc9eNlxkqTG0+xPqt/wBPki/WWV/gl+csIb0+C3qbJLw/JJeuu4a0
2p55F68trv6iMfXWBuMvUbF630GP2jwOtTfjA9TTxGxx1tRabfBu9ZORs09RNfB+Zq02XOeSo6lC
lpPdB4F6mp4L09RI9LT+n3RFzjuh/SL+V+cm1PPjJs1m1C8FySb+WT9B58Kz/qG9meCtZ5XDJrQe
fayWtq9ykxbvb3LWmiUNJU/exR/ao3C+S9is1F+zYlWMjf7RHLRb0VL7sxpV9jScIYUrZnS/yfwo
mpDT0syVITfvY1PQSn4aNnodvnJP9ph2pu9qHH9o0bnfPweloQcHf1fA/wB++sbfaZdk/llJkrfJ
bZmRmRSK3GMEYylwqGj2KiP993ZifVkaib0xW8naWJTdGGjHBlmZIwzdZ3Sz8lRN24Sm6MM3Xgps
5yVFm7wVKR2s3bhJumNJl2VKRzkfSnI7ZG9MqTO1lpiU2fUWmd0sFN59ykzdudHdIqA5XyU5HOR7
X+BKWCtx2plsScqHtdm8zKik7NyO8qy1wJNndZ2WXJ4PLPKLizutnGfuVFsti3G3P6m5WZi7Gknf
uXboUZXIqKkj1HLgrJ9MiluPV8mxRbLNyyV6b/Q+n/JuWBRkrPpf6j5iU+5H0f4RWYjcc2fSNbWX
LrYklaK2Fy5K0+D6RuZcOTEGzvTN3kSWaHGUWbnyVpu0VR3Y+Cosyn+h3YN9iruKao7n+haK7vuV
N4OyRhFSlRfkqLbRU7LhLazte84a+TvmNw+oy5SXydx2OmVGUj822Y5KjqSLlKR3zcj8vUa+C5Tm
d05P7nZJotS1a+BrVlL8PbNr7F3KS+53KmXbX2L05SkvuXq307G2d8GyngpNr7HEpWbZR2nbG/sc
SO+LKUTh/Yzp2cUUr/QuN/qbZxqR28luLKkqft03qJ3xp+/Tsid0a6YLjp/qfmRydqP4RunDajsM
wpdaXJ9GDbPHT46JH0dv2O+NL3/0D6pIvyOBwONcHHTN9OOm7pu6Z/fJItrpTMLHv12oyM2ibLrp
u/l6ZKSODCNh7F103yXXjHTg2ozyYNonKOTtRRu4RddK8H0jxgUEdyODabpLLPpG/Bx2n0jpV+Da
sibiYRRukrPpGfB9JwbUW4jqJe0+k7YUfTg+g+k46cdU5R/Q+mihH0FIuStn0mDuPoMI4PoG1HJt
otxyfSYjZcon8MtLCFaP4ZiJtPpMRK60i2fQbolUfTY9qHBxFgrbRs22W0ZiWl2kbiU4DcFRTVC7
bH25PT2l0ZgdscCckZiqN8F90Rvg8MlJRVo21j2E6R9Jtr7CnJU/kykXGPb5IuSpFfUOWmsm1wI8
EqjlHpbMlvD+RramUo9j8iepg8SN+nEuUcHMSbgsrybNTlfgTksMpNE9iyh6bjiLpivtfsOO2/lC
0UsN4Qp6ir5HWaPUgv0Iy1VaNqYnCPk3aicWenGVz9h7YLix+taV8ii9SmPYk0dqxJ1RGWpC/sKH
EvZlwWfBGf7Rp2vcUL2+7Y3o/Sb5K1yKLVM3QXBsnhRf+T86FP3JelFfcb//AFbYpOnZ3QSFtpeR
SlFSF+z7N2ozUa013eDU/ZnpRuPBqy9JWkStVkZp6r2ybV5Iwlpxi3jJPUgktkbE4xtH0NHdFoWr
Jf5GpqEaEowi21uJRl9Pj/RKckZNTxk4JTceeiZwMQ6Qu0lgjCfgtIbr99pw8CKow0LBVDolOrz1
fsiOBkEuGyKo4RJqiLrJkZqS9hYHRGPhiVdHQseDI/clKvJkYlRHAyP3FgpjoTrkyMn5oWBkULBT
NvuRwZJUNL8EW0NeSKOCmiW0jgyh0N0W0UulbTjpRlDrPTg7UKU1k4G6ycYQsDjtRwK0bduTg4PT
pH0n0m2kbki6F2jaQseS64NlI4LaPTZuQ5URVG5IbrjqsFtcI9M4MoWmbvccttHabmJ0X7HptHBx
lIel/KLBurJtj75HN8scmsI7eaFv8I08XbHS4JaLySwYRGCWBN8septzZ2YY5aizRF1wWvBtn7nH
LHt8IcFdCtZo3VkUIf1G6a5JTrg7MOj81cEMeSW1fSakX9DZK1mhUQ09PghvXIqWXL8F/wDiRnDw
bZOtT5JT/qmatc0akNd1iokZ80jRj8GX+UxR003chsjq6fjwRjdTXI68xNTVcpNN+SV+IGrp6M+y
PBHU1rpHe/pFHTVxUuT7i1tJ8Lgjj72Tjp4dYNSc5TlbNNyj2WadKrFGM2oREp9xq9qwKGi+eSOn
OTljyRpd0yMvg/Lw7H+z/tHMfJp07dcI/wCoqVEdP2R+0fclGf0sc9FW35Qv2eS7pMg/ZUjT1NF7
ZQyav7C86jxKRHfGlRt5Zv0o+Sa9sEVH34JQlnbGj9nj/wCP7vj8Wn7bkQ+YIw6IU+WIeCSNMbGi
LfsU2YJicZVTNO/MCX75anyWMUXwskfsOhR8FLyWho9Tyyxkb8H6Do23yRXgwMvzIx7DFJiY6Nku
CJgrqzf/ADMsZnx0dGy8WRXgwMtcsv4Gb+jyJPwyJgkvwKvIhivno6FAiWSTEx/Yoz1ajybtR2+j
iuBORVmDgpEhuvJS6S6PoxdbI9ETXRrqxS+SP26NiNT7df1JIh89XqebNP7dM+xL79K+Rx6S+xCX
u+s5EBkdxqJCJEdqH03+bIV7DO72654sko46T+xB/wAzP0ETcvBAkRUjUoh9zU+xBLkkIb83Rp0Q
X/l1U3HcdkdtIluVurPUSpWKLgk7o1JvKRqRj/KxRlBNGm/dHpxVPiyEsP7lqO2qNrQ9R/Uf1bVZ
PQjpJbXV0S/ts1u3dCx5Se0cNL6fIpryzdVHpRjb4P8A2NTV52k9P09qT5NzWUaaNXTb7xP5NU0Z
auE3yb4O1RpNcohCfsSnD6vklqTdylllQn/khpyqn7C1H5Rr/wBxqSjhkN+aRoz0u2fujTjPPbZp
x0v58fY1G8uskZP6VEkoq5ryRjBPJqNeWQ05xbwas/c0v7f9DD7mn77BiS9yI8kmiCGh0Rv2N3gU
mTZsXuad+Ikv30NNcPrGcfci/eIyxNjJWen46w+WfoPpBvo2ySl0ZBLh9GKXmyD+Bjsz0Yo+OjIP
5o/QZuXuachjJL2F9hkV7jGWvc0xkvwbRDIV5Y/sMUvNkLGSs/Ub+CN+5gW3g7utRuh37lL2Lg6O
6dlTs7SY7eBRSsUhmC2cmBMTZgpCXsUYHu8lWOsm5mS0RxhMi37HI9pUsGp1W73H7l12ouxMqPDZ
C/CJK/J+WNTwzbfg7T1JoWfJJx9iD/kRbfgVM/L8kVPFGpGxbPYm9TlkI2S2+Te/p9yVyqRafCIb
PpvghvdYJZ8j9P7DUzbuxQlElLV9yK3K7JOP2FNfQhuTykQp2xODw2JamKNWO5YKj7F6hpQ3jUf5
iWpnaS3SqQmpXiyE4ydJ3RHe6pFJ3T60iX2Kjy4myXKINqu41Uau/wDmfIpLg0V8HreERQxqLrB3
YdmpXlUamq+Gx3/SerFVKQtPTntgd9S+5pwgrTfgz5FKH8uS7S7iaj5NScrqUiUpM2J8Edfdk75L
BrY54O6mjNLAv2bQy/JFvxE2RHB8oT2uvsb53fyOMqJatfVM1NKPLNmpjBo6GnUpX4Faf01kjt8K
zU9R14Iwj3boE9Vxkot3QptqLWckv2dvM54PXkuHhk25pLaett2wWEv9FsbylRz4Jt/ocj07PuKP
t1omQySoepL3OaGln98tV+HjoyKIr2Qz7s29Gz1Hy+khN+BfYdEYryyMTB8ifl9Gb3WOjIx+SK9h
n6iR8jYtR89GX/SfoOiK92RXhdGY8lDPUfjg5HQosh8GB/gUvcoZufg/QYl4I/Axi+R/Y3ezOenJ
yYPByiix20UuCNHI8m4WeDdZyWhbX5KcjdeRqLNk2bh0zntE7HTFtyhWy9xUZZFHUdM3McVI75YE
91sauhrx13J0KM5Dl5KjIrUkbrGos75drZGTfJ2ui02kLdKqOxiUJChqy/UcrtjUXZWo+3wRk52+
SWx0b91QfJunLPsdskjdGeBQ1Z8IeyabNsJHp6krvyXGSsnGMsm6Uv0Iucu7kqDxR6u9n50qpUjs
dFxm9qfgjp/tEu2+RuE8myEsGZ4IvdwiS0pcnq7z86XdZ+TqW/Yeo24kYftD7UsD9Oasrd2G2Uri
WsMlp6bZfnqpyW5LwJbduM5GopX9x6nCFHUglP4HHbz8i2pVd4I+ppKS9xdn/JL0YIUpRUkV6e34
HCEVuHq3mz09WNv3Z/CiflLHFENOenxyfwjGlQtdU4L+Ur0hxjp7WzdDm7FDU0raP4I4K4xN2myp
Q2v7HLjDyvcUoYaNkkpfoPTj2HqR+vmxab002vJKOxfqiU55bZWxTjVFenX6HqSk/wC0XpOlzR9K
T9khxSP+p3/mENNq2iWnexNUfI4RalaPAtPUlUU7wKcHU15Fp3aRH1XiP+hfS0ypRZu8FJZ+Tf5Y
uXRweTB5+5TNqHeCvBXgz++xlFJMytpuiUr6WJUU4s4P/EpJtDtG5FJMymi/PTyjJXj3KyZMG3bI
+lm+slJO/g4ZYkk2Vsf6mTB9DODcikmzMWixKslOLMmMmISO5GCqdGYin5MI+hov8Hafw2zuW1+x
a5NqhuPoZv8AJiNn0Fs/LyfTbL1OTtMQMxLyfTZmH/HRKGWfRkqeOi2LtKcUdx+WfTS9zvZ+Wyp8
Hcfl/wDBVP8AU7zGGVG2fmY6VBYO8zyflSaKbZ3na6fuYbO9mOT8tn5hn8FwltMakmi9TJ2uvsVC
Ta+T825dK05tFt7vudyo7JuJe50dyyPZaPrk/sd5StfJ26kqN03uM4O2bX2Z3T3ffpyVGUmXNUdh
W50XMo7Gzv46XAt2bZR/4O2KOR3FFPk7LO7uRTO03WVLH4Kj5PYt9xn8FWWjvX6nuWkbpLHwYPpZ
aWBweKMKy/8A9hsnycNdN0ro7UzJaz+g08P8FHDR38HbFr7ozf8Agbq/0Kiu72OGhypsSim2/Be1
pnD/AMENKUG3L2FPbJFVL/A2k1+g9OX1ItRefY3USjJU0zbGNm/a+L4P+n2ZNyv/AAenNU+lQVil
tl9y5xde/wC9x+KqLcadGyi6FChPaZRlGEcDwNuPBhDtGI/v0khLbZwbaLcTETg3SRwN0ZWCtpwb
aFccn0lG6SODgTax8n0jqJVYF2mEbaFuWTETCFKSPpHSMrCPpHjBtSI+5wYiKU1k4HSN01gwh4OM
CVHBto+k4HUfwXJYMI4KrAlRwUhWsn0mEXNHA8HcjET6SkhYOB7UJy5PpHguSPpHg4wLtPpMRPpy
fSdqo7on04HSyK1g+kfacYsWDg4wK0cDcUULhOiXwRlQsFbR+34FgSSodqj0kJtUzgVe4pTQ2qZh
ZE5K0Yx8DVZO7DKWorMKx7122V6iG1UkOsGIn00UxRorVXcxxj7CepHNG3f3FxzZiOLoSl2sdK0P
2I3h14PypOQt0VTZ3JYNkXbJtQppHpx+kXqQtsbjQ5Rx4FHVhfyR7eULbjJ2xs/hig1TE9SCdoWk
13MuC5Fir/Bva3Je5tcFGyTx8DT8SoSlprHklVVVnpL6XkW6EZNolGNJ8EZabqV0LUa3Je56e2MZ
Gk8c2Z04y254J6Gnoq06JXXBl6chaENFOXwW4qO4itLO4vZaPoNsuRTlDBsjFP3bRoxqrZFpJtr2
P+kejn3LccyROVUkd1YLSXcrHLVns3P/AAJxnHUZ3ae2/gX7RKouJGS1FOoj0tPT/LXmhzf9Nk1J
du4hLT5o19KeJQx9zSWl9UvqIPQXa3kUprbL2I+k6beWXLxSI6kI74LBD9nS72/IpyX6oh+zbrk3
VE776jglov8AcX+4fSOpJZawZwZ+kjXlHqbT7G5e/TJZwNViyWDbL6bN3uNpfvoyrNWZLN1dGiqO
DYcF10bN1dbo4NpwcFHBdGTg3UcG04OD0zg4OOm6jjpdHBsODg2e/TjpwXR9ihuh9IQfln2K6XRf
TjptODgWmWX1ui0UXXT0zjptRbLMFsstDhLr6fg4LNqLkjcxbR7i6HtR6chySGnSdiomkKVeBKPg
3zyT60Jv2sc14JqX1fJu8FLwjbqPBCuNxpjXCJqOfBdZFNGkrzY2vYU98qJ/ERaKRGVyjEW53RKK
+m+Twz6YijFZbIyat9IPxRp17EdTOGRXsjclmzbp8Fzy2T1NPmrIw3V9i5Pn3EovMeBw5sWpI1Lf
8o5pWjb8UPdmK8MWzMd2RTaqQkQguLI7r3+TD/4PUXjyQ+ER1WpJFeIRIryusYRHapuhasXVKrI6
EuY4FOa82TS55NXTbtM9fbh8EY+yonqJ8fysh7J2xJ4bFq6cnF+5HT1H3J0NL+ZE9bb9Ts1H7mst
OUsy8C1dVbneWbFLuWKP+p/aIJr/AOj86oL5H6C3YIzS48C2qnWTMaNHUSs0/tR/1D2n9qNWVZsh
C/0JQXsae3m1kjKbbj7MblFLaPR0n+X/AFCjG5fApvlmybzRL9pk0nOWE2Rj7E9fTnUpS8Mjq62Y
/wD2R9SEfubofSR+4/uf9NJJz5NH9qgvql4Ees33RyNfJqr2/wBF+z/YkL4FfjpM/UyS2kLMlxP0
JmmmSH+8j9zT/sJMX2H01esBdLF9ujP16yI9I/frIQxk/v1iR6L79ZF9ZEekOrF0Y/uP7D6afSCH
0YujJC6RF+4Y+qfyL8OSVdGRfn8EOlMnXSQqNQW10Rsl9xErIk/t1idvNGo5ElF+SMXzY34JbeX4
O/Nmk17D/wDHBGcs5O1UOMvJadLwR3ZpWelS3E69je8ns6PT082OTWaE4OsWNa0W7ISl2oxqJfcw
7FfJEho7OfIn7or5Hu9hfc9JLNCnKNOhxg/8D1NVCfKLSqlkejpSz5HBo3fFjglTfLN+3wRjHyaU
ny0L+4bk6Q162T0tLut8ir2sj+zKPb7iv+aJCusZRfke7xQ4xV4s3vl5Iacnas1Jx54NXf4dI7Xi
iMv/ABsek/p5IOPuJy5Fpw4LkruROUMbSenKXYpe5qJqzU1mkrfBKP0usbR60rcPESS+xH9D8iTr
iiE/2qEpx82fw8/c9SCpGlo7bfuRr+mz0vVez+kg35RrJf1GnKOn6ieCUpKrNLT5ijc9vHklo/sq
rT4bRepHA5S53UPUSvYOUvpTwmQab/Qg/O0/aIyk5KLwjR/sP2eMcWyAv7j9TUyK/Yj7Gppx03KD
wW/c1mnz/otGPmhih5ZD7FEmSj/5GB2fqNo58kiUebZCL8Eh/vF9zTz/ACjSEn7DswSb8iMCl4XS
rKRTKMHd0wOQutFWOhJ9MDfXcIqykZKsddMmByYuift0opGSrHQ2x/YfSEn79EZFGzBk5MDbOeil
0eTBko7TJyOjcZ6L2MlWdpko7TexZMCl4M9MCscbO0dijZ2nqMaT5N6+m+SCGxQswJSZNJ9UZ9h/
ck/6hN8WTX/ibvYgzR+xqfcUfI/sL7DUiVf00LV8jv2FJcm2LaN3P3Jw4o2/+JeffJjD9xJa0uTu
bbvyR+BU+IkNTNRFf8sT07W6y15Kk+By8DjElqard/8AkeLEvKY1fJr/ANwp1hkv7SOqvHJJX7F+
xBf0xNOXzY1H+b2JSluSkzElSZjNRI6214O5pbYip3XWMYq/I7VPA1/4nor6iEpxo1Ij9pMU6uLK
9o0PWqmiO3NMUWs2bqZsnKpbhqOdxPVr6nZNbu5mk17C1dTKWasqtpqaSkZWDvhT+B6Wg7kRVJqO
TbVNkdd8REo/00P9pxbHvlVKjVg32uR6k+4nTppHrS8npSwjKjI1XtSlVWcrMzXz46R19yuXCs22
uB6/bv1H4IaU+1Rjyac21255I/s+5epfFmn+17425kanF59yX7TujvZtv8zbhEdHXdQWcsWq9l82
PQ0JfmvKolq6kt05eX/ooxlLBubIvAqZFbuxnP4HlcjyTUnlseScpNYZysDS/fR05MXcj6i08CyX
Fna8mXkbtDpm2b5ZdjqRz2iycnazMsnI9sjZNl7kOnZTeBZHTLTFkvcjtZU8MvcOmVKWC7OS7wR7
i9yO1mWXuGos2zlkvcdsjueGcjplpkbkfUNKQ30wKEmfUOmbnLtFk5o7XixWzcVFm2bLse1ndLBl
mJF7u0W6WTD/AOTtkbZsu0NRYlNl7kPYxylPAnuQ6f8Ag3JvaJSZhq/uVFihqMvdH/JKMZHfK0Xu
Q1GRvTI73k7ZL9C4yqitSR2zjZtjKheo1GQovUTob9VWdsrVibktw9rolJytPqmR7+4271+h2v8A
UXqSr2H3xtk9mbL1eBLcq8WdklL7CnLixL4Gk/8Ak9SDpG3V+r5OI7vuUpkU2se5nYVFxHNPDeS5
U/uNRpfY2p9vuKRSS+w1HD+BrV8nCK0mz1rEpeBrTfOBuT3GYpn0UbYKjdLKFBEpe5UlaqitpLat
ticXg8k8NxkLUgtrqiEZY2qjh/4Htk4myT3Ixf8AgqI5N2356744Zxb+w4Hq33cihbdDjtaX2N2o
L038FL/6H6knkUtN0zau42ylRvT7japPBV/4RepNkdNalpcHJTketv7xL1Ebd/Jv1HczdF0ylP8A
5HDUngrT1H+pXqmzU1O32E1hi046lo/P1XKPsRejqODXsfxXX3P4tmzV1e3mhPTltY462s5R9ihP
Tm4tH8dierLcztdFLXaPW9aXqIXqz3G2Gq0vuV6z/wAl62o5VwYFH1pNfLN2o90vd/6Sk+0Tb7ip
F+TF0YyZs4wXbO6zsO+xuHJU2zP4MI4KMr9xW4zLp2szKj3Li6PqMvp2vB39Ox2jusydjMyMswYl
SO6XSkzMr6dsinKzLLUit2DMrOTEzMunZKjMunafWZZuTyYkZfTE2jMjkxJozPBn8GMH8RndKyzt
nR3ajOTtlR/EZlnJW90ZlfTtm0Zm2WYlRmbZkwfxJFtmGfxJGZX0+pozNvph19jM31xqSX6mXfT6
nRl9OWfV156YZ9bOWWYk0c3+5564x+P268f7tXkjgjH3MIjFLFnA40cF0PB9JO0PBNPwYOPwKTVt
j2obkh4GqOOvBx+LjrwcEL9y6GMjwcFfgUSNRODg4OOmEcdfpOCjg4ODakXX/wCSFq+bMC1X/KyP
yb6yNGp7GPYpj+5THKizfH3ybhj6x0Hjo6NsctltH0nBwZRiP4NqQrR9I3QrR9I3Q0uSFjJGpHwv
wxI0ujOMl0fSceTgvaUkJ7cn0jwbmj6T6R0jV3GF4O3/API6+4yRG/p8CJGtYrHtJ/3dK89JD+4y
f36x9PkjfNEhqQul/gk+uq/YscJYKXkTK6S+CK+RkjUMD62aek+ejHFljiYF0X36fBXV5JD9PycH
d/8Akfa35L9xY5ZE22M1H4Yq9h2TXHTUg3ddJRXJQyVdVrNYuujVm4x05Y78Msf2Jddb56W1gh7I
x1ZFPnoyU/6hD/BBiS6OXv0uLJbzHRMrphFDSZyNtk958JD/APyOpQf6CTebyQd3THTRGUXiz6jc
pGZoxMfecmo2/qPqHJ19zkw/wS0pe9mJEk2brOcF7rO15JqTrJ9RVjSfW/D5FukXuHseSpSyJ7j6
hV75EcmGJXlG3cS2/gUhRbpo9y7KsfuKcf1MzOS7sSui95hpj3PHuZZz+g9vBuRtZb/f8f7i4/0H
Bn/Y1xtGf+S/Bku+07cHLOWyvJl4NqwZtm3yfBn8GMHL6VuMNo+uX+TMrOTk5ZyXRx0w6K3M8nyW
2zyexi6+C8sydpe6XSvJbODjpgryeenBgyznp2tlvP3ODlnk4LaODgSSOOuEXRtoVnHS6rpVF0cF
0ZRlGInHTK6Iujgr8Cfg4GUXX4rPpGvwUi2v9Gm4n01+84tG7Z/x+Dj8PqVcRtfu0lwRckpWOo5H
FquqjQpOsn0pjqFG54+5xFjqGRxeOuFbN0sfcfah47Pw/TtRJ4lXklpQWExSk/0ZW2/sSi12+H/s
Sl4MoXi2foKo+TjwbPIn0o4PpxRx4M8C8m5If71GlS8DO3pumsGIkYeCODg7ayzgyNoU65M0OieP
pFg4ODJZdGS6HRx0yiqwLBaODJg4OKKRwJy5s4yOkbfArQ68DdHA0kcYQsdIrwJig1kwjgyjg9hO
h0jJUxDwOusI+BYKaJJDb4sspe/W6EkhbokscIf4LaxYsFJHBwcdOC9pVHBeSqLo7R/ggvBDGWOL
5Go5LZwVRwXT6V1SSI2qRJeKIQii5ROCkrN1eD0qybqIwSyRg0754NRpEdqMxOBRrkTcWfQy6EvL
8ClKJGHhuharSZFJX7m5r6h7UWkfRghKccclaL7r4N+qvy2PdVkdqpUQjpt7bIbuWskK/qEbpx7f
c2+EOSVUsUbZx/VjdckrjVHpKOPc3asKdXYsXAUIfqa32NfVlzY5QVS+D82P8o514v8A2JqGPYd+
DbLk3NGOiRyTQi6ySGakJ5o/Ql+9X3ND7Eh2W1g9hrk9R5EMUfk/QY4kYlopsc/MizJfRDotvt6b
eS2iijjo+q6YJ3xZfwRXGaL9j7nHRotodDwPBQ8EZV0UulWc9Mcnpy56PHTTGyXVMiWvYeSA69hK
XkTwUy45NziY5NT7D/Ao+Rr2QoiuJtfJ2n02z+GitiG6s+iP+CvTjX2LrBKSXA3JcDpeCX362/BB
fA3E3y4LcFtJenHCI6lYsU9qZUlFfoTmkuCl0QpyWBQVIf2NzyolJUjKRB7eWai2L6Sqwai2pdpF
pVHyKaVEscoWq1wb9ReLG6SxgXmKyKMcJdHJqpMlqqNwTpMjppLBHUSxdmmiUmaZUkmnSFPb2kpR
jSSPR0+V7eBTkr+5/S6KhPCeWbdWdUqFUrkIhFZe4jOUSl24JangpjjDwbvkcWst8G70luIaPO7F
MjNU5P26Sj7n7QvmiMZcMkoD/tf+xNVdJG75EmMz5IlEm/KE17Hptj+Ro1WfoP8AfaH2JGfcpD2j
sjo9JEPl0feJIvyQn0kbXzE/QS+Rfbp+nTgcVySc/PS4/wCBbotGWYYzH4Zffpp/3DL9jMkYlZfR
1yZLGxxrBG0YFEbZJxIpQsW72P0FPKEpEh0aNjH1ivcRJdPix/2kX8kfsQoj0rwT+w/b8CR87SJH
+0j7EPt1vq/jpMlYv7SX36qjT+xJX5P0KRrWhfc0zcuEPTt2OfSP3FXuQrg/9TUHOr+BqGizTlq4
yTr2Fq1g1X8C2kT9D/BUf6S1cYjU3bJTStolGGm/8D9XB6N9t8kJuSTkR0Y/S5UaeT8rzghGWGen
DL3eDTi+ScfclKVu5eR7Y/Sh6MIvYbpR2slpQtOIpS+kjuf0xIzfCZ4wShCfZ7kVuS7Socm7VFC8
s9SaqPRasOUz04an0kVqTtXTNRr2P2mE5f5Num6lQ/W5rk2Ka+n/AGE+jt1Yqd4L+T9DLwXyeoUW
+nJQhL3F8o5G7/faP2JEhVmN8CzlnA9Tx1j7JkV8DNpGBgZuf8x+hu9jnx0rpge5Foovo6l2lt5f
Sr6JHJyWNWLUZXR+BSbyz9CulnJybxZOTcNWNITcT2PTTFgdPI8m55EuCiXWMn4KJUz9SMhu/Bfm
xfYiIo3DQ6MI+nHv0UmXa44FP2FkWpjB8l2VZG34Pqoask75OcGHybTHsNxRwcHcske5YXuS+TZZ
VollEdJSRGO5do/ZkqLSx0uhaU8G+0SzngbeMC71RvtMuGJJijqSoc1THGDybpur9yOn6kcD2yTJ
aDlWR3PA6nFka9iPfyrNyabJQSN/k2wlg3TeRRm+3wRe9N1ZJQkS19bUW/2Z2SV14G9aVY8mnL1F
XJ/FSXyblONklHUUp+5q6mrSkds8mzSlefBe78y+Bwg6h56XF0fm6lSqkdmomP1P4KkS9KePBJSk
/R4sm1LNUi9N9gnN7dTwST1r9xT0J43WL1Z9/lj9HUtnqTePCf8AsXZqce525KfJ7IUW6MlHJfBS
dnrJlewtR8I2rH+gjCT4K89dyeDDplsrwY4N3grcYZvM4KTLYkzaP2KV0ZOx0ZTPJizB+YcOztZb
FZWS1Zw2VnpXJw4suxWrMJorJYsGE2dpmLOBO6KlFtn0tHNFPJTg0YiNvJTixpWbvJtot9OxWVsZ
mLS/BuRVGSxJHH+Czb/9CdMqsG738FSK8ClJ89PqH5Py8FLkuXJXKKo5pFcnczbDgv8A/adzOxnc
zDLsUdTyXuTR9R9WRuEjDR3yE4SqjmzlI37slRPzGQ3cWQ7lx7n1H1I/Ln/gxqYPrpFyl/g7dT/J
9Zc3bOyVFergtstFepg7puvuYdP3O3UkZnJI7vqMazP48v0O5uX3MF11qOrJI7pOX3MScX8HdNv7
nbLafxWylrNFx1JNFTk39ztk4/Yzqz/yX+HE6+x3Sb+5g29zL2FTb6cn1Pph0ZdmC9hT/FaVn5ka
/FUI2d8a6dqsUnGoso7Ily08e/8A2/g9hPopUcHk4FGixRLFFl1/oFNo+kfSjg2ibiYicF0YQ3Rt
o+kdI2ibMIdrBmJ9IklgzE4ML8KdF7TjgyjETCLaMxMI20ZifTRRxaPoMo+kxAeC2j6SoxMxPoPp
o+k+k4opF0cdFZ9I3t/c8dEhdo+0a6rZKjM8D7hreZ/0CiptHqPUbHt1JKjunfTj9woxnJfqLVc5
Tb92SqTVfJmTl9zCOPw3+CumRb+Sl9VewkvLOOqxZdd3knHx0+l/iqXA/wCwUYcdc9ODMX14IRiv
JHU1Y2jbFZ+5ugu73JJrjHS6OMn0s+l/4I6evC/kivSVMioR+/4MQwLcr+5BShGL/wDsnsiqolGs
HsYMqiO1YI74Kc649j1IQ2tojFLcxamrH9DV/KiqRKTvbuPzIwx/MS9KKdjlXb/21afgWPA0R+xh
FNVgjD3ZdIa2kUcEZJHBCdeSKXJdD/faToY0JIU5Ib8GnCP+SOOCh1yLHgoY5NeTgZ8CddLODgs+
S6GXWDgwjKwLA8cHGTCMo4ODaWZI0lwSodrF4FjgaHddLf8Az0uj0xOjgUUi2ihpjdCuOBVTMIeD
BG/I8EvwcGEONcF7D6DgTrhmUP3J9UKkcDSLcbPoopRPoPpPoPos+g+g+k+mjdtHj8H2EqwTF24P
oPoEq5F2jew2UfT/AMGYD7KFp+zNtE93AsH0ozA+/XaNuHCJUuBLbyJuFtm7ajETZV5IasufbppR
+SLe3ixuKi/sLT4TLxY4PyPGZG6WF7ngdJS+xxj8ClGdNZaJ9+ayRhJ4Zhp4zZbcb9jtSf2H6i2x
T5Of+B7aZxXuRvFslVSonCSxuJ7cbVg1JSfZfBqKXFEpqnfJHZHyRlLEvNjX0pP6kVd/odrz9jTl
wjR/tJS8+w5L6ekZOOC3X0+TfFLk09PSb234Kk7fyJTeyXJWnG3XgX/Uxl9yENPubIuu4deCMI5b
I6moqdCia6XsalrJDT0G8+xsm3iPk3Ur9/8Atv6C+wzZYpF+TTXz0tEYkbMMn9j9Rw8dH+9ZpkiQ
ptdHGLN75vpLIot4EYNtirpQpeT9B5EZ6OjdI9jYi2isdPBSJH6mTHWR+hGv6jPt0RjpIzxYmbU/
wVYmKiXt0rklg2OWD9B4MGkMl1usGYm1oljz14ycFIkT6ojaJGp9zjgenSMxXWnkpY64RF+bI/Jq
fgj8kJDRGf8AMdvIpvyJwiUz3N0fc05eWel44NS/CIbfJCb5Y/0FJLPB2c1Y1rS7n4JbHfVf3Gp9
jWE/NDcvGCMokJP+ZHqVbI45EyFeGJXfSU4LPJGM/pJzXKHGcrinwaNKsHdJR+5b1Yk1Dlv8FJ4J
/wBrIVhmeSxPf3NcCa4s75qJfrI2X2ylyL/p2h7vp8kPRlbbyTfwRivBq/Y1tHO2+i048yJt/Vgv
Wnsif/IVEIaMty9zR/tHoSdwJNxyOVdt0kKUuyvJp/s2lPG7NEPuL1POC17mm9N1K0b58mrqLmKJ
z/aHUVL/AAX/ANRXwbtCW5fBv1vGUQ/M2V7laGopsnKf01k1XD6bNFzVonKP00R/7ar9ikWb/BTM
Gm/ktG0hN8PB9haT8sb6b2V5/fM0fuSJY8ijdT6WQivpfJgYtv1WQb5oYyxjK/l6fqR+w9ot3PVx
gjc+naZeDvKVl+66PaLd0wN+OkKytw/t0ymKKNxIgzHsT3MX2Nxnk7GRbn2HcMx7Gem6S89HFHvZ
p9H0RFiosl0kujJfcZL3/AiZK/clXkk/HWKv8CfSiCNWiusPuaYpfYivJ2kIvkryLZyRZ/7GmR1P
5TVfwQUc0zSRf2IoqPtRukrGl1V+5OvY1L8lfBOJFLwQj7IwyD9j/wBR2Pbhkdztk6FF+5KHuS13
T8mnR+VLarFKWrLJJeV+BOsMkvg02vfgz5Mf0kNOWrLnJCneT8mUo/Y3S1X+pJLlYs0/Vk6vJKOn
JW34Jauq3UpFwf1j17/Qnp//AKySJftM8bsijPUSky+V4J6bebNsHJL4O9uNe5CMZI0f7T1v5TZJ
1uZKTrGR6Gg6i/8AgU1mskNB1GXLIyl72PdJVHJuUX6ad2ipTSisjjpT3biWrFbbyenpt2/BlVhC
gv8AJ6T8OhTlH5s1or2J/s+tzN4E55iiVyqNHo6P0R5f/bY6q5Ir4yPGRDcfBFt5YpexRdEXRRov
5GrIJPlifk5/fxh/NfRsuLo9Kb7jmxz9mcjK8CVoZtXD8iicodCl56Nii30o5OS3RuTRSZbHwPaQ
f/Iu5cFWc30wzMjnI0iE5clbh5MMUnh2VusdPJHNYHk3xZ3PJusai7YpT6NRkT3PyZkcihfJusqL
G2zuORpMfWMJumbtxW4b3IwyWT6j60cjW5f5MdOKMiyNKXJuvDFckXeRLdgb3IjnFi7kcq/cdSv7
CtlbsH1IabRUXdl7T6Tg7/0EpT4OyRtk+0uU0dkkfV2s5GtypEKads0vsXqOhxg7+EPW1fIoy1Ek
dskNTxCzvaJR05RsqKqPufTZ9BvSqjZqc+7OySrySjavhGpI3S4JR0n/AMj9T6GzmP8AklBtMWpp
u/At7XB2tOHsYfcerfkipVaWStF8o/Pz9zx/ka0/q+CWq+6B/D/4P4bG3FxHDUifTn7nraaxYlOK
HCMMj1XhsSeYr3MpWSUOX7HqTfb4X4FGXdH5Gks14I60n2LhEYOGYxohrRm4xj4I6c1bSo3xxp3d
FTgrJKC5P+onJ44RGM4bml7GNL/gU1iF39zZG4vbtvrvg8ijPlKuDansg+RpZTNsV6aqhbe5I9PZ
sjVEdSLyiMXDdSHp7aTHOWW3Zt+tDS06/Q/6hvbKz0q3L3PTtxX/AG+4Swd2Cl3IyJQ46Y4Mp9Mi
l5RTRb+oqjuf7/8ALuvYpxO/HS1ybXk3J5MI7sG5GMmS5FRyUXI7WY4LkXG0z2PJadHa76VPgxMo
y+n5bMl7qZh307z8vp3HZItZ+x3YLL03tPqO87G/sdxkvT5Ks78nbKjDZepk7eTkyzPJW+kdzvp2
OmdsqO/8GCoajotzZ9ZTlZcLiVLUbO2bR3TtC3SwLfIxJHMSWxnZKj+Ky2zt1JRP4rLcslbnRgre
0fxJGWYlR8nbOVfc+uR+a7XyZaOY/qPuivsN6Ricv8mZykcmJs7pSfT6pV9z6mLe/wDJFb0tqHtl
jpg3W6O59MNnuLdHdeDs0i3puvsOGzJa46QvixR9SrQ4x1UOiooyum1/gW2Nl0cfg21cWdkHL7I3
z0mkS09n+Ub3yy9mPcyqO2Nl0Z4/f5/2I+lFyWDgyhuMRSaOD6SqFg+kXaXQlXLOC0jK/fb2rycD
6VRwUJtF0OlwKTRwM2ezPpHQtMjjpwcF118Dx+Ckdys+nBVYMrpwZWTgdIqi66KzlHgwjMTgSXFk
W0UhujbQm0Mtozgxk46YRwZqxDfKJJcdaXkTaH2jEmJ0YODgzHBg7dxmTKyfSfSZX4IoWM1ZI4Pp
PpKo3zQ6XTCPoPoPpPpMo+k4PpZVHHTt5PqdHfJs4I9ptSV0YXTCstxwRwVsju8s7Uvuhzo4Koum
bYTl+h3OUkZjR6s1Zu1YxSN8IdrLXtdllRyJyVWRcl3+w4dt+w3FY5HUTuMRFCskXsW//wChvauT
Wjz3G6a7T04QW35KiqcqIzlHu8I9KTW77D2r5Y4/7U0dP3YvFDgqsWm3ldHjBGuWz9C/Bpplo9ik
vA6wxfs8vqLo+/779Rkr4FFcico5HZpqKwmKvY2skjT9+jJz92XXSD8ITQ49O07ujjp5Ln03UcHB
biLBL7FebO07umD02XR+pHaYKf2Iw0/8i389HtHTwb+RQjaZvmzJzkjtF9iJ2uhb+SymsmENpHa9
rIOTvo+sZkaG2SoU10UGJyPB20y9vTtoqsmaMUPFfhXtQ93AqVngxRlIjFcEr8GyPFi3cn/9jcsx
PFHyPbkdcnd/wdvI91KhNK8m50mzY6SsvFHJvWULa1u6OScSWz9DfrI7ODUtZGo4bNaM3dC9Rdtj
cKaN8l2nb7Hqakbvg/hnaqZKH9LK8i0xr/xEooWpqx/Q04RSsl9hTlK0+CXtR8rkXFXZ3JY8n5LU
5XeCnGnyP7k582xQgq9+mm/Fof2FqN2rGviiP+1ND7jEJoV80OiF+5+g8mjXG7pteOksml9x/v39
+khSl5MD9hbuXwfoNkW322RP0HTO3NDGkbL77EOmJ+DJ2mDdJdIw/lLPgtMT6t/Jk7er6Kvcj5x0
SXuJ1fR/cbY1g4NzXTbAT82Q+3SPsZO0bIrS9xb/AGP0HRpjH1hFcNkbNsBuaPT8IX9vSH2/Bl0f
XZFLz0cZEuCX36wryQskV7EmuRSfInDDZGUuSoewnq5d89KlPI4RZJm4eVY64JT9hxk1ZqNeCP3N
L7CrncaRBLhmr9iMLwT+EzmTh7Fa6wflPA3qOomv6T7SzXkh/cmpO0hGnD+Tcaf9qPzdSn7HY9zP
U8tlx5oWrP6jHMokZ6q/QfcljwOcn23gm/ghD+g1P7WSjFtro46XO0ueZ+WL7EvuS38WJeX8i1I/
SzR03zuJP4IaVeeST+CK/wBn3+HRfszBaFJ+OjSLXufobfBpy82NGnt8yyfoMhqVj3Npzf76a+ej
F/QKneB0jTXyfoSGaafPRk2/5jAyEl46wXkwJvpgohKiijCyVF/5LlK4l+R/cx05MG8oxnIvt0g/
dj+w6Zz5Ght+5TMG3wZRSXkX2LEijJRvfv0aizgiNEuum/kWfBY8G7wRXwKXuRfsRVlnKKhJr7Fy
my/Yf2G4yo+tvpwfSRII/Qf3JLyJeRV4FCzIiW18j3N0UuSujgpNW/cuXsav2JOMhxlLLQkRivAn
/wCRp/YWr5RqW8tHPDN0eGb/ACbVzY02bYt8FTfJh4H492R/Z9P/AAPNe5tjPuFqP+XJHbmkKbQn
9Mh6SknK+ChQ4oUW7UUdr+DdJvYuEKQs98h6td3uelHmeLI/tOosvhkYSnl+Tes2bIdruqY0+eCU
CUqryexDT5IanlHpt9/0o9Rx7iai1JtUPVl5/wBqWsEdPVlTOTmsmJZJKbzZW4rekW5oVSKsi0/5
irKT8nK4HGD/AH8oN8s+tD8sdChf5Ze4u/1K3DzYn4sj3qjkwRqRSkPaZdSK3DKlhGZGGfUZki7i
zFFbsl7k2OqGJPFFWXZlo7Wh7WVqujtaY1Fne8ldpyiMo+Gc5HRz2HdI7ZIWRd5e+JhxZ3yr2K3x
Y8xo5wZmdskfB9SO19PzPPkVTQ6lZf4K1JYP4iHT5Ep8m3fEjqRfDKTyKXhFKQ3KWDMzskXI27kS
2leD6T6Dg3+CrHTTY/YpSKsaT5E/A1bsTg+BLUvBaTRi6KY4qzcJPx7G1F1QmuDNtlrcacVF/qaS
+B4tkopOP3FO+73FBt0bYWOcnnqmbXdFR/yf9Q3bNqTsetuf9o9Nxu/cbzT9jG5m2pfqPUU22fzM
7Yslqt8rgzKl7dU4M21aFqTf6C01lJUhak5ceBQXclhC1uJIo26blKNeT814N0cM5/5Ns5G6EslL
/wCzdqu3/tZKPJ3SZ2t2d9s7G4/Yy5X9z6pH1MzJv9T6mdyd+5cXKjuO1s7v3/byfVI7rfz17JUj
uZ2SlR7mUVC0zMmZRUcM+qX+elcCab6V5Luj6pGUYs5Lt9Pql/kq30weRLkvJy+uelF5Msuizgqj
B5OOtWW8l5R5ODBnJRaRx0o4G8lfuOPwUcG7bnruo3KJaX6Fbf8Ag+mX+Dbsz8o4oyjB8H0H0ZFF
RLcT6DbGJbhZmBe2i3HB/DHUCngujj8Fzz9xRw/g31yP9zgo+kvafT+Ci6x8l7Fj2OPwLFGEmNxR
x1UYoU5efBxkairN88L5G1FfoPH+2EKTXSf36S3LyX1xTOC0j6fBLAla4HSHj99rSeTIxiwceD5I
trNHA6Rva8mUMa8IVodEUvLFg4LrpSRweCuTgpI+k4NtCckbUsnBkaiYRwV5G6OBWh0iNovajwmZ
VHKO2mN0Pajgha4Z3YEltZe1FHBVJD46OojO9EayyUqJdaStlpHBVHHTKOOl1wLBLGR4F8EY1knj
gcUjjHXPRJ8CnRxZHU28m9ngc9tfoJ0rG/Y2+k/8CjtrJBLyrFpqNi3LlHHamKEUjER4/Ap15HjK
iQivLE6Lp0XQ4qJlM+kydqG2jY15NkfHLHor6iTrurg4KUTfKNEIfJpxiqtWz05cvBq0+i7bRDGT
bHhZbJaCiTddyQ+0whTlGkz1JK68DlH6/FHfFxiXNU/JdVGI47cktRLk1Irw/wDa+kn7ir+mzGBL
3ZY6HFOmQ99o5Ir56U8lJYJohG8PwN/A/wB9rH6DKSwJ1kZH2sX9o2bfJGLLRkc/cx7Dsg/6X1/X
o/uM2rBZs8m5maPcuurx0bXVZP0M8Ea6RGN7RuDo9O2Jm03yPpG4oaiyM5ZM+wkmJ+5uHG8mzUyv
c+43XSJIl1jJ+StiZ/DRYmV5G0jgrYmSlFYHH26PA8H6mr9huhRUFZ9CJSraY6RYsUqO4UY8Iaj/
AMCnPKKWK8H1YR9aow0z1IrgUZOmhTu31qDpkU+RtLLX4Nkolfys05eNxv2rB4ijKT+T1K7rFCat
yNu1ULS01mbFOcfklFpZPuySNNkn8E9NrvWBScbrwdyVexf8qeBfYU06dZO/Nke20eE/LI6MPDJL
4NOS5kyb+B6Ml3IUpQ48FukvCHP3Z+bSj8l6dfcdDTNTbjBP7ms/n/ameui//Ij/AGdIpc+5FSJF
vhEPsSRa9z9Cm8CkSNOS8SL+B/vv2iPSRTfdZ2lkXVqxf2kjd5RGXkZI2e3RkY+JH2GbvN9Jfeuj
lQ0jT/pvp2sqUXXudwkpFj6S8dV0a9zT+3SksGYMi35Gb6GRheCJVjSFHwJ0NI3XyzIkvYbElwR3
DVjETJdYfY3S4KQvuIoowhryTNRfJJrktja5aK+TV+wxs2qI8NFvpH2shQvSISn9QpMxwhw0rLj9
R/EIx1G2jVv2H6Tf6Edwr9ulzVkdVKr8H/qN9UR+xHH83RbT0s+xCT5NKiX2NPUXKYtOfnFj1JNO
vBVUo4JUXJdsfJqSfsPU/ksY1HHaacTS/tQ643CdXE8J1lj0dF5fBv1JXJyyydexldkTVl8HqJdh
P5PhG32EtNtYKlk2tpSOz6ic9byNN5Zqv5/2vF+zEr8V0d/yswOF8Fe4l8GPPSvgwyN/0k/cjMqx
pfvtc/QcjfB1JHpze2S5T6Rr3Ip+w6NvuJDGb/cryNkZf09GjZeb6P7lX1Umir6XRURTbfXkvpiR
uKsv5EvbrwLxRKmRGrLfBGmb2PuQl0dC+OnzRGPyXgpYJZwfAuESjuRLrBN8FFyaI0/Jll2Jt9G9
yGkyX3OVRyjanyKcvJJtrg5/UWVk3SaHso7Y2fSK4ihLBlpordhEluKtMt02Ryv0PqN6JRT+49R+
5uwhqEhOUhpeCKlIahnwfTg4LaG5uqZu3L/JyqsUE0NbluMEdGTo3RakP7dN0Hk2Sl2i1IvIoasq
fuOe5UQ0IvEv+DEk3ttkdPwxO7dWLdKsia1I19ztkn5Jb3tpM26cs8DnN7pM3RIw15UOSmvchpab
7XhkZRkr25tkIwfZeRNyVvOR6Mpdsmd0018j26ix4IvSl/g/OlUqobjO2hwhKtLz/tlU+082SdVE
qLJyk/qI+Tk5spFcHIoyxQ14FHijtyv37fiR7j29FOLqSNs8MU/qK/4O0UvYSdxZiXRKuChjdWir
MG+Ik1k8o3J2ja7s4ZSbHf0nA1FlnwVk3RZ3Jnk5wNptnDRlujjcj6WjKkbo8FbGfRRkSSbR5Vll
fUfQYTN/8xtpncXHkrYZizfwymrMvHS9Pk/hts+lmetxZTWClpm6eDbyKSKaMO0cFG6Lqytt/YzH
aXLLOxOUUVtZclTKjk4Pz+0WUZo+R7JZO1WjOEXGRhmWjMitOVmT8yz8m0eS55NqbSLlcjtbSL/a
JZ+S3KJhoeyUUytGdfKPrZepKyo6tH5mra6Xpya+xGWtN17dNR+3S0jJem2mZnKi23ZS1mi3K37l
eo6+5abv3P4zLnqOX6nbJxMyvr2ycfsU9eTRyV6kkvhlt2zatWSX3LUnfuY1pf5O7WnX36dknE7t
WUl/trtL4NnsWbK6ZODg8lm6r6JmEZ/fbTg463XTHBbiXRtFg4NvkTaOOl0YQlRlHB9JwcZOPwqk
XtNu0zE+k+k4PpMFH0j7RYPpOB9MdEjg+k9Ohdtje2ho+k+kuunHTaKqG6Q1+BCdDx+NRE6Q5Kun
dRij6ROVIqhySGo6somNZ2Z1mJSbkhbqTO1Dx1iqE3yUqFSwLcYHXI7VJM5/4O2mOm4mNaf+T+PP
/IrnJilqrHyVEdIooihTmjtwOpomrK1D7koQWbojqa+BpD7R/wC7H1U6+Tg1LMIlNx56Jn0nCTLq
x7YiUlRLBsl4OPA3X77VtXguhpDE2heB1yQdcoaoZqP2ZldOMCx0hXmQsDVUNjpDwZ6UuCzCODg2
0K0VWDjg4vA04nBwenVDdFsW2i/NEB0h9jo27as7on0l0dq4Z3omOTXDFsG/JF/I3E7lRuO1odDd
G6PJFyRMl9+qoUiK9ikuTc4n0Dx+BPyZ9h/ccfF9HfBlWSfsj02+2zUT4opI3SVn04N9Z8CpWKUl
z4McGIn04La4PT0dzkerrPt9juJQhKRHbe0V810XouiCm7kS96KWRTmsEVjA/hEtKS7CSayXSZtU
RSayRRWhLbgzqsUJtybI6ku0XwQjLix0sRWEPTnfpmqmvBJLC/3fpP8A8SRGSdUyPnpJI0/uMlRF
+6Oej+xax3Cv+gl++1BfYZtOBoSm8MXwWir6NjVm75P0JZFfjo6J+1mTDHR5MmxMTaMmGhMx0xwZ
MC6Q6NxIbj9BJ+DLMF0VFdODdRtRMcoshvfPRfcd8FRrpcXi8ojgbGRNQfWMmuRKv1LRGzCqkPRo
njP4FYl8dGhdZ/Y4J/Zjk/DIRXCQ5PlEDuIkGLUpNDpUlk9OC5Fra3BjFIcYPt9ykRlJd7HFPuPU
n5L1XSFOH0sl7C1NRdpjtS8G2LtDIbeSb+B/s8uR0ljk+WrNurV9FOMU4M9Sr9kb3wiMvcX3GRUO
TV+xNfH+7smj/aNo2+bI+PJyNkV7MZLBFP2HLwiLJG35IX/RRL99NCXx07+JeTtYxVimQ3cjJWO+
jsr+UwMg1zZ+iJEr5sdE93uUWbYcicvc/QZ2ypHfkjDNm4aME7eBWckWi2NIgx1yPb2n8RsXqO+j
ZUYsju4ESJFELGK/cajydzb+4/cvwJ/SxpHuI1B9dNlIQiX2JM1H8FdcFv2H1nH26NG9ZkTb9jsl
USL1Hk2QdRIpsitNkYy8cihDPg04El7oyjbFYRsvtLq2KD9yb9kadyxZH4ZjhGnBkIeFyeEkPT05
CbfI3HyPVk/sTz3Mf7TLgkl/NyX8UbvqPpao04Pkq8+xtRpr2RDUfFj2vEiWu5c+DUTl3NGpqeP9
3x05OqwjLy0ZEPTbwuldGYNT7Gnkk0bpeWcjp4/fNvgQ7kkOiEHmInfIlasS4GOheBj25FL5K3IZ
9uDLGON1bORsWTk3Mw8m1Mz0agbm1aKsvcfUmOR2s2ydF2NRY3ISeBrkpnK6Kng+pUW1ZccH1Fs5
OclWNJ2JcH1mDanyeBxjIbbK1HXycolCL5G+q05Fpp/qVaFJPyZmhtSTZsj/AMG9xycdO7ESt6oa
jLBvcu6x5V/cm3LyKpJfYW6SN2m7RP5Gzt1GXN2xXLtF3x/UcYyX6EtTVnmzslwP1pf5Iz3r9DOo
kfxEOEJo9aT7LJRU42zd4FGbx8ly1I2PZOJJ7jbCWBstcijrO/udupDcRz+XeSozrHAmpPb7ii5r
gq1tO6cWS9OUdx6jf5bO6UUOnaOyVz5K1n/k7ZLcNf8A6v8A+/8AeCNtWvc9RfUU1SN6fcUYTZlH
DZ5+x3YK0+DuRUP8GbX79ODpnwd6M9Ox4N3kw7R3I7ioSwV4LkdjoouaN0XtZiZkvyds8HJ3Wn7n
a7PJl4N257j61R3z6djpn1YO+7O2To5Z32dt38H1No77LTo7JtozqUcts7ZOvkps7m2dk5L4P4kk
d73HZaMykfU6Lt37mNVmdZmZNnZOR/Emd3JjUki5Nv79MHbqSo7psz+Dt1Zx+zN2+RUpyZ2zlH9T
+NOvuRc25R82JOSR/EifxIj9OVnbNozqzf6nLRmcn+pyZk2Km0LcpP5GrH7fg5a+xzf3MP8AB9TO
X0pF5o46dql9ypfi46YVlyTRwfHTHS/TODg4OOlRRckcfg7FZbi/8H0v/BckyoQb+xbi0Z/3HgVr
Iopdpe0UaFg4PpG9p9OS9pmI6Q7V5HtX7+OmXt6Oul0ZRbWD6R4HCuDgdIUa5YnRwNibR9JSR9J4
swjjpwYOOq9jKV+wo0cFGImYmUOkKNG6WBySwJmTCKSE3go4M0Vdvo6RwcCVCcjBwWzCODve37i4
f2JSS4GvwZFVcEkun0mV04ODg+lmUcHBwZRTMeEYRhWfSZiV1wrPporbk4PpPoMxEhXHLJ7UKlhi
U13se1eTgxE4MrpaiRhWWyOtqL7I2vbfsNwWfYaSMowmJSWBRilS/mKxJe6HNLD4GvYSSFKccCnq
Rz4RscoqXsPbHPkagjKMRY1q9sq5LnqWOelgiqt2YXf7ktJS3S8olOKwkOPn/cUJvyMU/wCUjRv8
lDvwztJKRZTMF+6H/Q2RfNjwP96iyuicke1GxcMjaPgZPU8MTXt0g1lLktDizaubP0PgkjtJOXBY
1AU5cHd0yumFgWOvaZfaZMIilw2ZG3gSiMX3HtY36kjvdiS9i92Bv2HFClbihbh+UZMUW0PaPcOX
kejP9L6N10vd5NQl+CLi+R/CNvyKU8FDcUNV1yJtUNwySi/DFeDA5UPKs2+6K+Ramp5P6fuPKHWO
u+WcFxQ96whNcFv/AIK9MlOPB6c8EWuCTbIPt3fPS5NJ0bv5F5MaaP4aN8eGZXaLTrjyabrFkF7I
U92LEOLredtFPL9zV9M2wdNmrGbs+xNRXkWrqojBxV3hCFrbpbd3Aj05VvbO2khpx4WZFaE6k348
CT1JTVm3yyOjF2/JNeaNzd7smt9if+3310/hkj4I30nRL7mSezkW73MlxESNEmP97DqlzQq9h0Rc
uLyRa46SoVeOSQ4o2yfdYhieo8PAvsfoTafk7iovpfSo+5fwPad2GW8Cz0iy2OC5QukPuJkzTz0a
Z9RaNyPsemuSX2NgpNDjFm7zRk+o7SVlRJnZ9VkfVPkdH6mr9iX4KvCZP+0nZjxEacsEl8Eq6JM3
yK6duE2R+xqRbwSHFOsmn9hL5NL7H5cqipDXpuR3Ra6v+0pkq8kmaf2I5pE1cRSi/Jp2f+pHvaRp
f2olFW1ZJNUbpvbH3K32LbwiEG9sz/8AaaWmpXOxP3IaX/kIj6b5kRU+NuSez3ZquTyzcasvkr3Z
62svI3J00sIg7/LTI/Yjp/8AkI0tl85Fu4q6JrTxbaG9R22z1qt+Bvy0etN8yJv2EqdRNZ/Bqf7e
f4Ixv+YYoVhsizb5Gya8bjtJN8DXyOh7n5P0JR+SC9iX77TK6bocmeelohEYycvDP0JM05+IljIx
+SP9ozU3FIlISZZtgW0UcFsuEqZCO7HwZ6UhzFZgUirJRWRX4Ght+5hHBljp8j1PA79j7Cfwciz4
K05NfYuTYotle42OKZ6rQ6qxxjI9+mpfkf4Lflkl8EnZ+h6lYJSk6xgdHArXkUfgi74LIEfsSl5Z
KF5N3iyK9kKf/kRXlGfLG8WS2nDOBRfldVop9zeTTXwfoNJsj8M04iv+kgvCZCuUhyn/AJNSG9Ub
OUOU0OpJJC1Ebc8UR1/CIxbysIWo420S7u4X7VqfpZWpL/BLbK4jgvpLX0s/oiR/Z19KHX8h2y7L
FIUJPu4R6m25D7u7gX7Vq+WfmO80OnjwYxtYqfklC+FRFr7iz3+SWpVf+TPQ0stjnJd3+4lJS7fY
j3K/kg74ZiSIvdgzMvejM0ckql5PqHb8jzZKUnTvyUmc4/faepLhH8RDaakNrApQlQoajSaP6kLb
PA8pjojb7itw6H6kqdm1THVM3z+kxqIeUz1I8WLdOi4zixZO6dF3Eq0PdLBfqIqM4yHRc+DbuRcW
d0qO3UQ1GVnc+xmJ0xpSG9V0jt1EYnFCcXgy6O3VLjKxb3TPropS3HqSKUiypZgZZUNQ3WJaqf3N
unqMtvBX0OhqMzPIpNbl7HmMiotlv8CjKDteUbc/Y36Tp+4o6nK8n8xs021fubp5s8HCMGypbja9
wpJOhIcc/oc0vY4srbKy4xZWot/2K9KSNsdys36uWcI+k3wPTjutFSjM9SnRShL/AAfR9zcKaybd
kilHb9zc+TFyK2NC1b48FenbNuxn5jx7fg3QZt2/qXqPt9jbFYRunKl7C04q0jdLtNqe5G3hHqwf
eP1HV+3XdDlG2Ju1ZXmz09P6S9WV+TbAb1XZs0pKvkvWl+nS9KRt4Ru1Jbn+54/Fx+Lg468f7L7J
OK+CpFqzu5Lt0YnI+qR9UmeTuyYwXJ2ikZt/cz++oxJmWzOfwJJtfY5ZkoxZlFGGy7ZkxZeTjr7n
ByzFlM460jye/SlaLzZVF7elGIl7Slg+lnDRiJwcM8nB9JwcF7SuH0qi9pR2qz6a6Ujc0XtGv3Kk
uUJbd5e1JHB3de/DMyX3HsyX+Hc42YVFaUsL3MbTwfmUN+f3SL210+kljj9+oxi2JyRJfukqE9TC
9x7KZx+FduBuLUmkemuROWI+5KcKdEoe3XgzHBW5MbjEfWMpY8nu/scm+FM3avar5Kg1fyWolf7I
XkVkI4tssjUcWLHg2FmKGqHtyydo4JqVJ+xgbS/faMXwWMwhFyR7G5ryZHhG3wiI+CEV/MxNopDF
KS6bcFtGxcl0ZNqplpDpHBwVQm0JbbdCikJtHpo4N1G2h0iPsbmrJzrgla8l1hDVm2LF25PSrJwP
chRXk3e5t25GvguiMfkUpJMkmlVH6idqRwPBuatC2rK8GpfhEv3UfuRxmiWCki2i8lNFtFqJtos4
ZaQo15IKvBLAlFGUzgeOu2Ks3SRsNzRdGINl7Wbaz0x7D+5FJd7G6z5Nop06PpZwyuqUUd0cl7Sk
hJRZTgzYo+aN0l3+B6b+rlHp+4m1dl7cH0m6rQ8HqVcR7vB2Ky5rKNk1wyoqoRRLRr7EnXcN7cEd
NR5FOUeSMUrjZs01nyye3+g/N+kjHSrZ5o1q4Nb79EoryZit4oaar3I6EY3HgUZ8NEpQji/A6jwO
dYJKXEUbf2SLTaL/AGlt4FCXlj2rtirJ6Lh+Xwau5d6WGammuI/7IcvKZg3P+VkU+WXWemrkS+B/
BL+7px0c4/UiL1PqskS/e6IxiQptHsNeOCKN0Smz1H5PmhpkX4ixDyemL7G5DjYjd02ps3z5Gjc/
JkxEToWOkZCN3WDusisk6sqiRO/c5RwmKUUJC1PJI2p0RcsiS68ZPUS4NjQ38DYv6BeRyoZ+pqfY
l+6ip8ClEv4N81fkuaSRuStEJRjaLopqxSku0U6v7ihtSbJdvdRHcsSIyiL/AMkerSfsbtZ0jdHP
3O2kuq3K8k40RlKNpseFRJxVVgtukd1OPuboq8m6KrAmyUJxvJp60OGSlNXuQntqO42xwl46akpV
fuOMfHSP3IzS7peeu2PnHSUY8x5FrpcMbUdrgx68+6vYbjCl7kZ8G6bpF4lEWzETjyjSrFmzjdQp
Km6Nsspj/wDLuJXwLb7Waj9kT0JfUsG/08o+X4PWiu6T6V7mpP2dI7puS9jVNZi7XtOE51l+xD9l
0c2Q+yNz+vcRPQl9EmJygpXknq4io8DfGjf/APsKUo8H9MFzL3Fp6edOEqsmRlGtz9jW/tNb/ZGr
9z9CZF+BGDVE/gaRq/ctDjeV0mhX7jJ/vdHoyG/CFtp4GZ8CdUxoZ6RfmhoglxJn2JMWp5IfJRKx
NC06Pub2jA+aIXzR2s8yG9VV9xVNCaIx6bPAn0ihEj9Rknpl0fmLycdNn8pn2G4cohH3YnLno/sd
3SZX/iSEkuWKX/A43THRXyav9o/3UGukft0jXsZMqzcKRFkTTfgm/gS+SH3NMihRSvtOxy00d8t3
Vf3dZfY1X8icRwlD4N0hv46Z8ywRXyKMfYSnySl7D09LRqj83BJy5fTT+5on5ENzHLbtRH1n38kv
sftIzVHpx5bJSmiKFt5ohovF4NJvkjtV5RpJm9c0R09d0mOcZpy8Dlqy80TS8ktSb/LRqW8sn+0f
yXY1X6l+PBs05cCjqZgyTXhFTtx9hNxaNVIdLG4WKn5fsP8AZ/2Z/mnq60t0nyzTlF2qRHZKocic
nSiiM9PMYsjjdUaJR8IUJKlY39jbpy22iCk6uVk9j3blholLUb9JM1nOSVrFmtqR+lv/AGRKEnW5
nNkfl9FG+ejl7iRbJdNZWLJNCJK7H+90H8jGULTm+33LWSVCTGNin7nI3Ym/5R37EhR8EMjHnkSv
wepaErT6ZZdo2KsdL3RsaVCXsU3TouyrPUsxI22XJopSQ14F4Gm0ZkjlF7kfUjBvbMSNyknYnaPq
4JZ4PqXB9QtOLN08Wy7VEvc3T55KTQ+7BGN5E32k1vttGPwXR9JwcHBwRU8ZFDgrnB6e7uRkrwj0
93Pjpt4oW0iWySjLPky8EYWlRXOORablXhl8oeEhw0k39jg4wKfgTnPbI/imyEuTbuV8jjuTGoux
J+5HTtKyUd6ZjORaU3hm/wBQjKJHuyzf22OEVufB6ko1ZwxSrgWjr9qMyi/7h5jXshNKoe/uTlGW
ao1t8qT8ihCeasqeE2X6lHp8kY+rGI9Naqb9y14Foar2pHMZfddJQ/QTg6KnqNo3QdMUNeXCN3qq
T9hRUvylydskqiKMP4PuZ1FF7fPuflfTfJ+bSdYLeui41NXyLbOOmf8AyEyM9KROGg8vijfqSc5v
yy0bNWXZ8m710l7Ho/s2Y/At7UNTzZ6X7JLdT8FftEkp/Jf7O9zvk9PXaTNmjLcuC4uiOl+1S7ST
9a2lwOMXWkvbz/sm1hihrePPuRrNM25FK+HZsbyWzJ/+wbTtFJkp57ikx6klus2xtGX++jNcoqUH
Z9Mkzd02/VAxaEnArIyvTtG3ay80OSjafKK9NnsKa8Cj6eTho3G3a2fw2eUfS3R/CK2tG9ZK2H07
Tk3x5PowcUVyfwTKcTfGVFbbR3KkboGYn8M4akVtszA7k6EoO0fSjMWj8ttn0FbaN3EjFMp0br7j
bF2cUd1GJX8FzfS4SqXuUnaO/Bnnr3tJrwxfSjhH8p/KfyGNrZ2OmvY7dU/M1LN8JUylqlS1jfff
7lR1Tfvl9yCnO17EIrkqEqfwO9RstYZjXZ36u5G6MnFs7f2hndrNl6s9s/kzqQcj+JFD260StLUZ
cZzO+Um/kpa8j+NOSM9O3Xmv1Klqzf6lsuLor1p/5L5Z26so/qV/1E/8kJaknJfJFT1Yqkfx4o/j
RPyHf2O3Um/1PzNSb+L6ZnJ/qYk0XKTk/npjWlXsW22zGpJL4Z3TlL7siRnJ5ZuirZLPePUm+3wv
wYbR/NIzgxf2Powdzf26Yk19jMpdO3eZcjLbL6/Q2fS0ZjSKMQf+DuTX+0KN2TjJdWVWC6OD6TCP
pPpNpe02F0O/3yQm0fSZ6YRxRtouh4Nom45PpGXRwM4LaMIyhYLSMo4/EkkW4lJGYnBwbdpe0wiq
Fiz6R4M0ZKSL24Pk+kyq68dcCk4ncjtODjooixkckkx0utqTj9ivXnV+4pW/vY61Zr9T+NP/ACfx
9T/J/Gn/AJMtt/jpjaS4LhyVFHcu0tr8fk+qSP5zlkY+CPF0VEiqwPCepRSXTg+l/hwj6WU0cHlF
1gjFR8ilP6peCkuWcH0tHDODjHTjphHFMT9SUYIUbv5HJcpcDVH09OBLa2bNinKssvTjTaI6msv/
AO4/UjCA/Rldvr2wbEpJlOMZPy2YjFP3RJ7Tg+RRawRuClNr/AtOXp734odQUX/9jlNUkxR9OGPL
JOEUpVwh2qX+yV+Kq4FgSj7ngVROBadZL2oraVRW1G+sDdEpNdotvsNpD/e6C/8AIWOEPHTg7kPg
nNrzgzEZprwJ1hDEl5ZdG1oZF0U0JFxNmzHuJswxRUce6LljBsifSfTQlQpNCSwiHydoo1gVouhR
LFgqHJM1PuSaHtiL1VREil9BkeSMdN7kyMp8m1F0fSU1wVBVQ0uDczY1Ux0N0XF00VqStWT/ALSX
XJv8Mr2NvubpLBwi9o00cIbS/U7hPbR9JdUb/ca9kKPuKc1X36OlQ+iN8zj/AAOclg4VCukYr/A3
WB+yNnwR3e5GdZLHJLI5PEPJQ9tGVXVQQvV+v46b19KFhfc7ufg/LyW+bJSuqPUccjurQt1UUk0J
NKm+Sb0/A9J8J0TenWEenFcCc8SYtsbjZpJeckVouoo03L6qHupOjsSdG7XXzRDT0/cSS7xpeTQ9
iEfZF73s9kfS/wBSmRpYFvivU/8Ao1fTNuj9THHVd0afqfY/Lrcxy1o9t+RamnjPDIyWU0R/aN3a
umDTjoS2x8kN7uQ8fV/s/Vv2I/YmOF+RNdGKy0aiZbMOyY2ah+hL97ov/wAj/wBUSFHyxSopDEMa
FN82L7Dpi3Po2VL6RF+SlwhWLix0eXk3SNsRajzZ9JzQ/gxjpF+RWLi+qkIlToe6V5JGpeD6kYcW
XESErW4dFeRTn/k2/BuiriZ5KfBPo1F2xySLh2uyMZxpkpMe0f3J/wBpL8EdPlD+xTIr2QtHb2lP
yOfC6aifsPT/AJUSfsSb8Cfmhaf8qZqfZm1+5/ahRf8ADZ9Za46L7i+4rRtNKvL6PTlwJWVF0m+C
L+ByXO4jpudw4ofwbXJ7b49yFLky0vuZ1Y/5J7c+OtvpnUiv1JxU1Js3Gm4OrZH7GnGEtq3EPlIe
npy7bEm/IyenqdqXAoabs1fsav3NX7Gp6jip35L5Xih+rKKfizSriiUZc0aTXFEZabymjRk/qmaj
eXFG/XfZFl/9RH9RTT3Q90Lc83gRH9mWld+TbJWmvJHThG4vkja76/wejoy3Tl7E5SdyeSMp8E3H
gTTp5O93tQrYtJtx0149yEFwkL9ljp3EXyiip+URkh/7P1F7lfBKT4N4k3XSPsWbcjl7oVexLSfg
v3Gh7vPSX73R/uE/eKJCmvBGK7WMbNW+PBj2GRr6S+kGudwv7SQyF8jFfuYIZYkzczbBG52RT5MF
q0blP/IobdxclRFdE7dEbOTt4O42ryS+5JD9mYsft0s3+BX4RGPyKiVM035oW0VkmSRJvizUbP8A
xst1gcYvpfhs1P7R/guvJXwWxP4N9Y6YZz2exP7FDQ17m28pG7/yJCl7ja8ovbaE3FWNdVDz10dN
crp2T2ZO/VckKQl7H6ifs7LXDQ9Tlij7G3Tk4/Yb1Ju68s7eOnBn3JKPlcjnPUdfctO8DS8GkjTf
wQf/AJGnJO+0cn9QtvCGSlua2ewt8rz5JRX8xPXl5Nb7Fp0kQjqS7o+4nCfapWR0ZOpLyRlI7u2E
RvTzpxZBbtkYeR1P1E/JfDYoepLk04P7mlqPwRcc4P8AqLVG6TpIf7RaTY9HRd6rHqar3TlyelP6
Xg5Tj4ZjC8s/6XS/lwRXF8scI6u+SxQv2nwRlB2qP+pscpYUUS/ZpS7l5Iy1PBbxCPgfp400/wDP
+z96Pq8F3QvsXF8ENzFM2jmzFFWSdiyRS4E72v2HFfvtN+0iGfA3Lg7DfDk2yxJIabX6G5cH6D28
m582bR1yZa/USbXBIX9LZHKHkWohd6FN1/k2mZGaPpVlLBbkmZhFlR4IbuCnKLNyrB9SL7fvZtVF
S+ls3WmxqP8AwXrOkKpxY6kv1Z/LRe5FxlE7RbpUy98WOMaIaj4KjNDzgUZfT7l+orK3oTTwZ1UY
1Im2Ev8ABbklLyVGV/YtkXqfT5Ft1khxhONP2G/wR3y2aiMakb9xamnK2hb9Tay1rxsa0537Ufny
2s7ddN+xt9XJuXv0cVKpGOBb+2a8mNVbj1NJ9yEtWW1/JjUHDRnvPU1H9XTwfVhHMWOmlIepq/5M
8j25b6XqL/Bxb9xuN/ApxdMUdV5HHQs3a0rRnn5GtPk3zlUeaZweDfHn4FDVz8H0Djp2kzZKxSjl
L3Nmbqkj1H2+xt1DZpQkm/JPU1Fucj+DklthtT8ielyRjLRcqN04bCdyqTJahfS4sUZwlIah2RY4
7d1lRvTjVWbXbQkoUqqxT5o2y09z+xsWnSO7dJex/B/4NkI0j0kvmx6k3uk+iaPT2uZ6cYOHyep9
U/PyelCGz5N6m5O7PT9P9Rp3KzOh/wAG1XBe5vg3fkUdrlQ4yb04Mr/aH5Lo/MPy5Y9j8wqGUctH
uunsdztG5YkZdoviRV2Z/fIXpzZmeDu6XGTizunaOzU2n12dx2y2nbqsuds+SoajLcjJUZyMydHc
dspJfB/Ekd0myoykX6kj+JKvYzJmNSX+T+LIzK+i2Skdzb+52No+uRlt9O2TR3f5KO2c/wDJmUja
22WrPqkZs8n1SLuTOC6ZwVReUi8lZZZmy6Pk463n9Dlsp/gyY/BgycdIz3rd7D2O2xyaGZOOvBGS
8CU9C69j+Az+A6MaWxFl+elpG7azbyzdWPsfQWkV+D6ce59Iloq18mEj6SUJaT+5x3F7ShRhGy3E
uhp/iUtXgSU02epCL4sqb2w9vx4WTdJYPpK/CqTLkjfXaeDFErXH4E44G2rodx/AoxRGc3yd2Cjd
wi6Gn/syjc0WJ0NpEW0cF0cFH0lVg3baIQ6NpDv96kabrwPdH/A9vTjBZsXgVpH0igvLFg+kbSE2
cIdHxZmikkXRWLPpMnMS4xHSODjosCc1kpeRORttGEcYPkwjg3aiJOKqkTsrYvuV2m2LTv2N0kKO
E+m6RlKJaNzWD6Ul7nbktmXE2wpku2qG6wdqHgT1PpFGE7JLasIf7rtVnBbQnw0dvsSdcEki0jg7
kdsTgyjCK2l0Z65NPS25JeyQor3NsVUYoWgl3e5NOKtIkkusWl2ihCK+9HbFJoWnOPPHSUY328m+
qfkcWvPT0or6nyab2/mNf4K1MyG8VVlR5b69qsWDKGn4Iy22huv5KEkKWw+nBmJVHbC0dywerPhZ
N0u3Tj4Ruj3Q+S9PNjbRsjG2XONEXJYI6OnheZD81IjCctriR0dHT3Nvkhq1Vkkun04IJox2wiss
nDT8OiU4LPsPGDalbFKUGkxajSfsjjdJ8FThsiz1Z+Fk3y7YriJuStex6sOKv/ZkYmEel/KKHsJy
HXghBe/TcxJiN9ZJr4N3k9OXMS6JfvY/c0/iJLI7FgTqhxSyTl7nb4Q9xBrwxe40xQXuLHg+OnHm
zciKZgi7xZkaiJu0d78FLgtxHSFtQpNdNNmCMhLp2YFu5E/BtTJ/Y1PufdDbZGWSIpvqsiiUzbY/
kk0PTTPU1OSSfLHb7GzA2kND+5L+0f7lRXLFqaiz7HcoQ+46r9DsF9iY/wCm6FGME68s+iI9RIwi
tiN6WGduUjGnErakx/gj9zV/tZ/7Gp/az/2J/Zj6JC2+Rei6kQU8z8n7PNcvo5Yj8npwdn6kfsaf
tZD7C+44xyjdPnr6f8zwfw1gagk65wb155PTmu68MnHxRDGCE1FPwRjJKN8YKcVxgWnHmzbtTnIl
Ue9Lg1IezoWmycF7kJz4sTSTi/Yc0t0iP7PS3yYoQVYz0nHysjScueBakl285E5OoR4JLT+jdz7k
bieFSyxwh9McE4vyXFVeTUkTiorcsNHq1b9ipJW8JGlLi0J66X3Y/Tw/BOD8YI6c+Bwgfox/7LgM
dnZ55IWTohfv0oi/BGRs8k/t0mL7D/ex+5p/2khX7l4sagZNn8yG/gdMUZ8yE/YlRGTzG8irhoY5
CaGiKTrJbyRhWWyxYwWxwgK1mztdEo6nHwZwhLci0xdI6dCfRpiZXwS+5IlJZs+mRscRYKI6W0T6
LApm5MpwbLcNoxTfA2lSQ42e4m29nySTaTJDH/aP9zp/cgPa2vsbYpz+4/VVdJkn8jlLhG1ZYopV
FiSQ9ruhk0/YlKPNkoS1KY64/BD7mp/axfc1P7WJ/JqfZj6R+5p/c3av+COtDEZH7N0cYatR9i5y
tiImn7biD+C4q8nqSuKRnrH7k/sa9n+ej+xFi+5oEPsb9u68HqQ7JIlKVSnROfF5FLTVslLVVNij
5oe/zwLZ4R6zvt8CjLS3NYHPZsaNSdbm8G+ar4IQgqVC/Z4twh7idYPGOZEv2T9kl+vsKMncnZLb
9RJ6saisWajfknqV+XfJta7rNG72bjR+xpKE5RhfCNK+fkcVyhS0VckSlrLa2VfgX+yb6abZtTsc
hTaKY68kJL3Gj4Iy6Qp1uGiMfdm9nI2n+9X3NL+0kZIwm+0i07LolIX2GyP/AI9GbPkivZEiiKGQ
k/LKshL2ZktFRNzRt4MFtf5HimKMdWSf3Em7wRKFMy+BwTz0ybIvyW/ckiytpuLky0eoW3hGBFWj
ZETdfqcr9CUYshbHBSHJilOv1Kj7eBpMoUpe5OT9h/g4wfSz6WfQfSRltNrLlwPuW4pNW+KO7E6J
7iauslXyOcqsjU0sl7h5yzapJjXEn4JxkSpeSkmz6WfQzMWRkyTlxRfCE9yyep/MTW5W0ScIuUS9
ouxkYSe1r3KTusIgnKiHmMDd4JviPSOpOucl3g9SONrsUNR0KUkpNElaWMI/Ki5QifQfSablGhjl
iC8npab+BTl4ybrVE5prb4EpSSZpRu9pv3q1C6MFaR+cRin28Cbcc+GW2vhH5j/KT8ie5UuEODqK
ukyWoqz5Nv8AJYlBpSZqRclfPJzjyLU9RYhZ25SJN8qI/wBn/Zn9/gvl+WKcWJTklNLySnugks4F
+zwl+QnljlGS20n9x6NL0zduTajaZ/0spVKPkU57ZP7lvUjUf5Ux6mi2tK8ltxvzFjm5xlXEUzfO
T9L+WP8Asy06Nmq6KtMSciShIitTUz8l7q+SvVRe9Nipqj6iGpeEVvVkJP6UUpq/kw8fv4RnKh7Z
5OelajuB2yO593uV6g0pWhy1DbvMPBHUllCqW07Z8iaYk8Mre7N27gS1bOWNQlgSkZcrGozYpp7l
7HcjtbR9VoU6sS2uJi7KknL5PoZUG0b06KnGX3Go2vuKb7hL02vsV3FwuLKnFsr0WVUkJSjuP4Uj
ti0XzZnTdjqMj1ayU9IqEWjuKjG0fSzIobbSKzFdFOPJXp5P4br7m6XX4QltOKOPwflG3aexvbtm
2OUbJJUepdSKVSo4R+axLTdpe4nhHKMNMqfnyXLkUrjJ+x3bUfyDravk2/s8uCnNG7UlbK09RUit
8SK15YZFflv5P5DHpj9OSX2Y3qOzbDUqI/zeSvWPzZ7un5M9p/FL1dTdZem6ZS1Gfn6jfwRtwv5P
q0znTFLTlG17dJ7dV7F4Lk7Z+VNwK9fBc57itLUcfg3SuTNvqtIy7f4K09ZxRWpqPUiXB7Wd+pKS
9i9NOLPzNR17GCoaziipftEmi7ybf+olRd5KhqOP2Mu+vZqOJUteTXtZh0bXrz2+xdlevOvay4Tc
Wf8AyJf5PzNaUv16VDVlD7M/M1ZT+7/2M/3FF564RWS1Z9TM2zCZtaLrHS66Z/fKS8l7WcV04MI2
ixZwVQnR9PTCLcR4Ko4Hg+kvacFUfSfTn8NUJ7Tg4ModRKozE4Koqi3EcEuDMTguiqs8GEZRmKMR
RwUkbnEovbhn0jwYRfRIt0Wkh9b0puDP4v6n8T9T+KbVqm+Ws7or1h+o7/dKKLnHuNpclk3IdC2a
jiLfrS2/c3R1JL9Rr1Zy/U9/xY1pJH/yJ/5P/kTf6ndJy+/TP40hSmqgUvtwOUOPA0tSUPsz+LP/
ACfxp/5FHSuWeWL133MdZkSxhdcI3an0lJM3RVp+xRkx0j24IxrPuLSist0RnrrngagsjxwV/uKM
fcUpLwZr7D+49qydyM4LKoVGURaWLHjwR9rElTG0iv32m68D8MZSQnJFyKWEhXEwQSXLLcSuCXuR
bVlbaGSlz3GYlLybqFBRrJuLdG1RybqGjjpwJtYFGKz7ixyJ0Q09nLLrktoXhFo4N38xNP2JuXAk
lFmzYOx1RGPp2n5Qm1yNOjbFJm+qIpcs9TUXRKsCUVWMj0/I3XBT7ZGMjwKS5QtNxQ/lD60kbqMo
7Ub5ocPglIW1GV/k4KoxE4OOqSFqSVscX5JSXJLc7wbFyOSRTQvcVcGyrFKfL8H0oeKrqjc8L3Z4
HKMR71lGYdpiKNlUXRv28kscEYpcik13PJCLXkhpx9si04w/L9zbJWmS7fJ2wN+oqfsSe36eDfBX
Ik9RVJC1KyMtrtIxxz7CjFUjZtfpcDjJWhyXuJRj5ocpqpGxRwj04c+WQSXke9XWSUquvBOGqnXK
sm2sryakf9xaHnJL7HIo3g3PJJpVggvk/Q3mnD5Ivo+kIX2vI5D/AH2gS6KTWOjjFi1CvglkjfgR
LJs+RfBu4NorJMhG/PRSZj2HTYpzyUnTN/KstoajNWUKlXRfHRSkY6pCa5ocZeCT+CRt5FNqiSsy
8C4ZgkJtYEmbruKZS6RkMb82T+zE4OnYoP6uCTGojP8A1H17nle4tq2/Y+kukenGFfI2+EPTjFrJ
aXJTjuFqbavwKFcn2JYqjfQ+m9LcvY2+ntJT/pJpQof2HKXCFLwyUo82NSWVEl9yUpOpJm5ZwPdG
ooa3Z9i+kF4NKEeKsemtO1fJnUSHH55Jz/pQtSqL8i+5pfYa92Rk1bGzS1PkR/5bhHoy4bFUd/nJ
PU8o1dSQt/Bq7P6j/JFtYKitsUsv3NPQ0nhPPSC/m3dHov6WYSdZySn/ADGpqTkvUfv0fvZa52jv
gezmjVNX7/7cf4tD+4/QsiUySIP5P/UaNLUrz0UG+Td8DZGRX7/RJdFGOHWejFp/yl/p0hs8s/Qk
blymQ3eRrx0aeaMEL4cj9CO2VLcdxZhGE9o1L36S9Js36ls2zsuIvuIjseLFu5OSo5O5UbfJqDX/
AIjLfuS24GrwblZBb5VZC+SvmjA4LgwtxGHpN26IT4sivA2jc8Im35wVEWpLklFMbL9yvgl9+q2Y
a8kfUz03cDv3JpeUepJMiiNIjF8kKGajfkS/UlXX9ScV5HqTJ2P7ml9iZOT9iaQ0sZ5NuZmVyeol
zwV0gzSa/pRLbG1Z6mpz7EkuDUiuWhQfJV5NqNNfBJ/JGL1WtP2N+5btv/JBPU/LTsi4vNZFK/y+
Rzk6UUepH6Fmy4/YkvPJPRm6ZUeRxk7nLkh+zQd+5ttJLln/AE/7PKvehSln5YpQd4PVlN7ESnN1
jB67+i+R15wNR5RKMNRxaI3qNr4I3zR+Y8MqLxLhk9Scrb4RKMppSZOb/md/7ihP2ZSf6DG/kwx5
EV8dIjiaX9xzyhJe56g4+Rv99p5yMeTfF5IwniRmkbvF8lWPJ9j9CWRQ92R3YOTArx8jyRlHhMSv
InIpMuyrO5lRl0uSY1py/QS92K+lJikxryU3hsUpZQ1puiMbE2ss+q/glgkuMjVil4T4Ftwy9o1w
/uQleLGPPROVY9yMW+EXHk2vlYOBqDI6k9sn7M2wwNsjv4ZGSnFkqdtr3Jde+O6LF3L9T64v9Taq
/wAj1H9DE3JceRxGt2yi5Tjf3Htoxwunc7fsbNLJcuWfSWZzGxXqxuvJ6dxf2P4ipijCXahL1It1
5E7tXk2ergkoaybY8KUJeWJS1YxMa6kejopOxSly+ilHlHp60qL/AOoVjjpTUierJY8dJJailqDl
f5XuZ1Iocd8XHwdk98vgbPrlXtfRRm+33MyyVpfQKLnT82L0X2pm3UnUvk9T9nfkUdeSscdDk/6j
Wlduxw03z5PnpFaksFtqyov8uyMG6aE9G9iYo60u5Dlp4t5FLV4s+p2btD6vcUP2l4H6X1j1dV3H
xH/cm+D/AENrjQ5JWZHsVouilpmdP9Tga2m7yjbsZb5NtGf39aeUbdhclXRShhlS4HsdFYaLkjfB
1IrDL1Is38MqMt33O7gyioTwvc28nefly2mJNo7zsn+hzZyi5umY1CnrWdzss7NTHsfmM7J0z+Id
8jJUJyL1JM+So6rP4jK1J2XptxMt0ZKhJx+x/Ekd8m0ZWTt1Jpexbts4MOjGtM7tSUi4Wju1Zf5M
uzEmvsd0nL79MH5c5/5MzkZ/B26ko/Zn8Wf+Tm+nZeT8xt/cw6P4s/8AJbnJ/qR1LTHLcNpjeuse
59R9R2vJcODlnuUrLy0WUkXTR5ZUl13Thuj7CXp3I3LQe0cfTHLTg0vczGVluJlq2iW17seCUqKL
jFnBTX4NsU2XJFMyV0qMbE9rPpHHafSNPx14ODCuQm1RkrpwVpIzH/g+j/guSNsI2ZiZX+330WMM
uiUWuGblEa2iwfSVtL2n0mEW10vbZx+/U6ModZ6JUcEYVyJuJ9JYnRxk4ODMR4NlCe0fafSZiYic
GTtQ3Q66cCSVm6Sr7l0bmhFqJVCbSHjplDrLR6fsLcrfThDnLCPB2oyqR/8A1MUN0YRwVPBlD2o4
E2sFxQ8CUsIjU4yGks0PFfg4PpZlFaj2+xF1ZKjB9Lo+k/Lm4sxqSZerbKP4f/B9GDMfwQ9T6fcU
4JSG2lZLV1I2lkvUUYRN2nUom6K5XWsi1NaFaYtPZUTdsx8HYuC5uo/JmKz5Hmo3VI7W5UvJNzO1
diZtUVS5Y9NU2ucCnHG7I0jcoOiEKy2LV1Y7m+Db237EnBVLySSg2kd0aO2Fl6sbo75RX2N+jmPy
jR1NvY3kVJUPZC1Zx0pG9rAtbVjj2EpOMPCHjufA1GN0K4lQi2Q9aNP5N2pqKvgktC+33JRq2b5R
T1Hk9Pet/sSnBcZaJR4/2+l7sjJ81Y0Pfy2YRwWhH0iss4SZtoYtKX2Gx/vtP7kkiVmBSkhrh/BC
XMS0PcbV7nHg2skQtZPgZKVcsx4MmBek6yd/IzbocCetybYluPTCFKSFFKkhGBbHgSlybqyXATmW
enFp/JJ/A2L7DcZyRFym2r6JxbqxJ89KgVJ3IjBK2d/LMCksJZEZWRtIWnJdvRtIfgXe6I/Yl9+q
QnOtzRwPghXuR6erq4ij6TtVC0+BWsD28m32Fux9jER6iWBrqukei+3SP26wXyR04qoxwOHp1p/1
E014NWPsbZcFyxGKKj+pP7DNSVZJVzZKabdyybc8eSLaI6W3hfUQddtka4o9W3yL7Eoyatvg7KHH
4zIcP2bV737Hqa05T+5siqNGPuzS/tHGascku33K8i1dVVEppRjRCS4aFLc1GGaRpX7Elq1b4OxJ
PiinU5UVo6i3+Eja9WUvg9SWJNENO7m2M9bc+5k/sP8A23X4If3Gn/Z0g17n6DPiyP2Hu5IbOLM+
xtfSRp/cf7/T+5IkRlPyVH2LlZl99i9iSTF6sse4q9h0W3ixbXaH7jp4FTtrkk37CUX5O8y6Zg4E
5DjAnLUO0nDUWF5ErwUmYHfTueS10e4pC+xIf9pvKcxaak9zE6KFGfLFIs3yN8eC+lOSNi6Rh7ks
ZopYybX3R9x7quhn2I/Yl1znJOvEcDudx9ilCRC/6iJEjRc5KJjUt+w5v6RLhdIqOLkaX2FBuomy
Mo59hv8ADHpEZE+OkfbcM9Fayep/SS+xr/c9WK3Mca2jk/JP7dNVeSiUEvJCeovqI6e+tT2K/WzT
0FLdqtkfsQ0f/IRFwd2+D8zCpOiSh5bJajTlqS5FGHHySlr/AFI0ZvlM0vsS0r7PY1FLxknqz+iy
32QXCIwi/wApSNH7Eof1YNJ+6I7H3Jn7P6nlZNV6X2RqT1HbbPVkt1IlqvnwetqfTeE/BL7ENDa+
TU/tY0v9vx+5pq/5em2S46UmOhL2Q1EUpIf2Ite5b9hkZezGmY/esh9xkhRk+wstEF4Q+iiR/tJD
Ip8jGSfufoQf/kL7FrmzPsXyVp8m6d2ZwOKHhl24SKhrMT1p7mYMiaXnpts2pnczZF/Bu8M2/Bwf
TkU9uDuwkYkJr3Ip+ClLIkijbeRqDyzdLUk19yvPz0jL2JyZXhSPaVDUclvLZGfB8JEutMdeUObp
/cpQ8CUfc00Rl7Cic4HJu5DjwRW7AlawRkvcgvZEs56cH0s+loiq8kEZ5o2WbWemhaad0qOD6WQc
li7NST9jd8kpX4Jy8yZOyWcvJQ35ZJM23W5nwb9tsrFoWrzk2KE7qj/qJckYt54QtbbckPNzY/2r
W5fCYlqyttks4ZKLpJYyYQ4Q4NLRjO3Zotex638x6cprdITtYjZKEJVpeRP2I6GrhIjOUd3lMbk1
uXgl+1a2F4Reo+PCG4vto3R4WWySXsKN52inEjGWNTgertqXuS0tNqepLBLUn9Uv9wbJywfUmTaa
aKU/BJOWCK3H1Ityj/kxJI+oxnIrkvpHtE5SXA46bo5/fem5JUfxYjUa/ToozlcS1OLJTnNR9jat
SDQ62ic8R9/YpakR1KMhPxYvzUYnFja8i3T2y8lPUijDvJs1XtR/HSNsNRSO+eTOomdurHaXGaaF
v1aZcNdDSdikxd21/JjVTZWo8F+oVp6lnqJn5ktsioalinJ2rFna0fUi9KeStRsxJ2NQngrWkZkb
dKbY5zzAy2mVpyYpx+kqaY1FtMxLBtmpI4lfuOOm3XyL1I7pf1D2WW2RnzQk9On8G2KkbuqlF0yt
TSlM7dGSY9rcYjm16htWjIxFr7mU9SJ/AmVDTnA9Xe3/AOJ3aLZ/DlRuWl2lLTY/y9tiiK42zgfa
KWmqopaP+CthLUT3X4K9EcPTa+R6us99f8F7dqODfHwPSR6y+o7YY9zEDbJUbnyJrlCUY3RtlGhy
l9Rtj3Iqjdqu/wAClps2Ujdqy/QWlDa4o3az4dmyNOItZzz7FIrg9TUdy8G2DVHKFrak8rwVqyxx
Rx0uDpmyMopDf7RPd9jZoyVD9ef6FaLx8jevP9B+jL9D/wDSNS/jpu03Uja9Sj1NR7pe/wDuHBic
qKTdo7m2dtn1tn8SR/EkZnI+uR3WXFyX2O52Yckd1/v8H1yRm39/wZO2y6syjFlmSki6Znr5Ko4Z
dG3aXlHk4OPwUol7aRSL2nBQu0+kopKzc1X2Fp0XtPpMRKMmOlJG5xHE2ot5OD6T6S9pVF0cFFtY
L2jX4EkW1bPpo+Tc1hIx+NIvbY8G6LpnpxmtvuX6uRx9RMb1ZW/xfkz2ivXwf/Jz7Hpeserr+fc+
lG6MaHj8ClKNQJPbSMo7nTMUN1RtawZr9RrihduBYRcUSVdVCKyb9ZbX8lwp/Ykmuu1cinq49rPB
uhFfoPHTgSihS1cP5Lhn7DVddq5FPVxfueDdBWvg27LRTasuEcfBTX+3MilR3ew4xI0vBLHaJui8
HJeC8FxQk0SI20XFD/fbmeCUUl0WDc0R045tm6SO2h0Rk0UMbecnyMcfYTeDBckZ/wAFxSO4q6O3
KGdvBwZQsYE5xTkNqNM3TVitV9jcuGLBlceR7MjdG+dNI27UkJEaXgp2UrR2nBbKoWpqr9Cqx7Gp
7C1WrM4RtwJRVYPQWm79xqiSf1XwYobSE/Yho+lTF7Mf4IOEdwt0akRZGvcWPBLBhclvptosuja1
yab90OcR4F7SZpSJfJSViwPtOPwQ0nxZJ+2RRmV4ihfs9dhOL4oa675/SuRQVacEZz7MjpriT6ai
nHbGPApPlGxfS5CI6f8ALZCMV3NZYtLT96sk5S4iVD7irjk//qerNJ7T1H+g5VTRBwVWxySPThHg
i9ReaKXCWCOlX5RJeKFHwJRVinqfT8knSecG/buk+Bau2r5RHZizftNqVZohvXmiVeFg9KX8ElHw
zsXd7kNFRvOWJTXbLI4rm/8AbiNMls8C1Ob5FfsWokkiF8lopsT+OmCZGv5mJv8ApMe/76S+Svgk
L2FKRsgxN+9iXuSzg9NeRfY3Lg2LnpuWKKs3vyNeyGiPkyJEtmBXbiXav2NkePInI2x2srCN7XSS
Gi2KKGOKKZuFo7KXubvgTZHOaL5LUSmvJwSpFy4RS46NvyyvJJ+wtzwKneD1Nuem+PgSbyN7fHSJ
p/Yl9+qiiLlFObX+DtYv1PzFcSMo+SL9zc0pXwW+BvbyKoWvYj20ypLAvuaX2Nj59hzSwR+5pCRG
SXfLz0p5RPbxf4Ifcn9mI1PsyH3J/Znz0X3ItKmKLdUKCzR+ze/Rueok/Y9HSX2+CBEj8sh9j9Tb
CbivZHffIowVWOMuTVivDojGfBq7eNxDU+Tcs+43CG3c+RaOnHe0xerJRZ+Xqwc+kYxyxa2sv/7m
6TSfiI9Z+WR38DUeLNPUqxTw4vlHbDZ5I6Ojmn/gXryUZlaWpB6nXUlJrdZCuCX9z/27pE9ol5I7
uk5EBjUSK+DPApIkQ/uP/Ql++lR+hIVtKXsztL5QlV7y/YkKa8EH/UNexaI2SiSPT8I3eaP1Itex
LYuBOXNG1G6socYWStPLH9iT05O/Yg5x7UbZam0fpT3Emy0flilPnoyVlFi/tN0Tt4IQnwyN+UN1
kUPJP7DUvcjCnbIyXDGl4O7ODA2z8rUoj6k24kpPwhqORas1SGm80OummvgmuuR/2k2/cRXyQF9h
+YWbXydrHOeZIUtu6xPixP8A8jS+xf8AKat8UfqaP2IvxZplaWj6j9x9m1He/wAEH8k/sxX7k/sR
lWLNR/DH0RH7kfSpyfuR1Z/UfstdJXKX+ekGiP2Iyf8AUack/CO1DnqK3Rei1dl68lfga0ZLfRL1
Zd0sn5f1Il6vMvBHSjmT8D3fVMUapUak39KOxP8AQhOVonNulRL9p1FascpNJ1hex6k3+XeEbLzg
Xo8o26jubyQ0IZlxgjGXL8EvFxo1ZlwiR1pePclqSdJC1IOyL05VBsipP6FljhGnm3/tLj90yELy
vB9yi/YenfA/kS9jHk7uSieTTtk6IyHbrA/b99JN89G8G6D4FCf1dIFP2GyMfciSKQjlFC1Hgqxt
MirzQ7PqP1NqY5SkkYaKN0mdkoswW/ORx3G1Oy5FXwJX2+4ndobjL9D04+XRHUmjDVG6R2tUxTaH
Uso5s3yHtY6FP2I5SSNi5kzY8MpmBSkk7NzVMenpvB6uplWbI9tHOBL3I6mGObkOn1tuk2LO7Bsq
j9BRTqnZCN1SP0FBYl5FKNFzHBPLLw/1GrWPkTtLJGO9f5NznH7j04SN+pJRazkh3xVL3OUbbpL3
Lbj+rJJpVXga/Z42rMnBbN8pJOy3rR/yerhq6Itziv1N/qQv7j09N238ktav06fAtPUHGGfAoymv
8m96saj4ZfrwJyhJSvwuic5xi4u8l/8AUQ/yS1NOac/CQtPVl/k3etAl6ctzY5tbc4Py9Rw+xerq
Ob+SO14PzZ1Ifp6m6Z637TPbG/J2Ti5jX7Q6g3/MV6sbfsSerqpP2ZjXgRhoutG8sjGLj6iHqaja
h/LDpFpuhPV1VCY/Q1N8mf8AUftk6fsz8ianN+xX7VLF+Tt1U5+yPzppTfuY1Y/ZHpaUtuj5aO6X
Zxkt66j8H/T/ALFP/wBhyb3N8v8A26nCVMqV2LU9jYj1W7RtVnHSk6PI8kYU8eUPkS2W15K3NL2/
ftqO6z+C7G9tdFOP1I2S07+R6qV2V6Z9DiRn5RXolbKLNu269hx9LpthHcvkr06LkmXplPSK9Not
ZP4aP4Zc1RUe5H0xO+uijDKRtnGkb4vLMUzuSR3G3Tl+h+YiyoyVfJiv0K1GflT/AE6fmM/KltO5
tlb2d7yfldpV2bp8+52zZ3TwdxWnqNIp6jY5aiyfly2nfqN9a0tVndNsuXP4Py9XavYt6zsp6zot
S7vcx+0SPzNaUv1OyTi/dH/yJGdebMN37levNL7m71Zlz1JS+526s4/qf/In/kuUnJ+7MNo/j6n+
TvnKf3Zak4v4P4+p/kzrSf3ZetPZMxq2zu1KHHS1N1+xenuhH4O/Wn/k5v7nbOUfsy4znX3F6tv3
sinPbXhn8RH8VDX7PNstsxJx+zPql97Prn/k56/xJV9zOen1y/yZbf4exSwXNX8melHLOyMjKbO+
P4e2Mi5RaMmOlnbBs+h/qfTRtq2fw5GYUV/tp9Ujd/wKNG6j06Lopqzg4OB1E4H04H++kvCOKHx1
uii6ssYvYyWkUhNo4NnkTlEwcGVXSksHcq6OkNfgui6GkjuRiJhClJHA8CilZmrNnuJyVFUYqxqs
I+m2YiZ6cYO1cndRSo4FOdK/BwNpEo+DiyqEhN07P/Il+74ZwcHqaipL3MLBwcH0s4ODET6a/Aj1
tVNfD8kmo8+xUqTR9PJJRVuzMaFAha+R15Z9NmNP/g7oY9/w4jZ9LOD6WfSzg+lnBddMIymLarib
dqk/LZt2pfKOOWcdIqsCW3dKsnp3D1PYl27WkbenYipLCNiiq8uR9KT8UcGYtHBHdHBb2/LkelBx
lL7EnGKjJI9TVWPcUNsF4SZKWlGn7Iaf+3Yyf+TK8EL4I0j1awZOPJ9Nse5FqJVIzTG17ChJeeS/
cb/falmPYkqMC7Rp4ZGMeLLXsbWqJVyQdFMZKbXkxwO3R7ioaZujkrTFLURbxRs0nbL1VRS5Lrno
8CtYFCK+5Musn5Qnqcm5oco+PBksw05dFqf0s2xcrIpSdX5E5e2Rpcv2Fsk1AXqZkNeTbpNo3a7O
7Js0d1+B6v7RK0+BQw2y0J7u2yiSklUjFDaRwRhvdGn9if3/AHV12lJIdRFhURjFUPcroUILliep
9TOC1wcIzTY9iGuq1GlIWn9KSJOS4IbfMjT/ALUSnLlnqLj4Oco2e41y7oWrqcHA2iSXC6r/APaR
httryUKmsvAuIlPJu0+BRf1k4P6U7Y5wXkkoK80b9dClpLBK1UhR0+WzUWo7p4NPf7nZ9TJS1VSv
yQ1I0sm6OU/Y9dvtu6JfY+RR2uvcppNrmRJ6SVWRhpS22Vqu5LBp+pSwJadXyOetGlfAtSElB80e
ktR+m8EdWaufiyOjalqTwaf2PUjqNRg+DTvLocEq7v8Absfez9CyEejivY/UyS2Ed3J3Oi1k/Q/U
0/sS/fap+hIycZoavArdUKiVEVP6WUsl+TntsWU7J2OMWKd918HwNRdETvaRUM/YlYpSQ4qrKbuK
OOEenOFfIqaZhowSRJeD81pHZwMdkoxGRSk6IP4JFIWpJZ8EoJinP6Rd9CccokxSawjGPYcY9xHW
1UUsM3rxwJa09rIxhLdJiJNEdNRcl7ly52jQjT+xP90oLsmuTsdDtNlwuLFLUdyF6Tqzdq92eWak
vZGzU1N0b4NT7Er9zS2OreSP2JofRLT1XGPsaUp5l7ihCe2PwaTkaf8AaiWj4RqHa67jSf8A4ob9
pHp8NYO2VfYa2ucaLlFx+Os35SG4OmS3t6lmnUNlPk0bzghC+32665L7mr6str3C9KSnFEnrSUYG
o9J3GyMpcGrJe5GSdcknP+UTT8XRVuMYijTmLTeh2+5P7CSWDGHXdL2P+m/ZsyFeWRlI3+7NNxdO
iEpc8Dcc1GyS3dkf5SOpOPf4Q4x79Z4o09fXu749jS/tRLR8yZpv3Q/fd/tfH4q8jr2NpGXsfUrL
GvkwO1yJDaFY/sV5sjfsT/faqMexJm11tMOxtIgl7n/qMr3NOL9x9JX0Ymj5osgS25Fft0ewd8G5
j+xwb26aNsZ2fnVtJUZKiKza3kqBJyNidkZrgjH2JPwShLJ9olc2y5I7EJFL7Fr2KT4Rcvce3FLA
9zbiy9vgqiE2sIlnNcDjEU5YkOEH/gtsjqEY+xOvf8PH4KFOrYl4KZjwKNkb4RFJUSS8ktZmo3i0
S+5DxtY5PiKJV1j9yEU8m6ZpwWMkV7I1n7s1LMfTdkI+yFnMmR43f1HdK4kt6uNDSr9Ou2X8yNg5
zzm6IuNfUaX2Fr3k3yYpRNTU9yUf1J/LHCfsbdPjg9GXnBX8r8m1YiuWR/ZdLhYsUbSXljjpz3NY
J60eeByfgU/PsOO78yWD/qJUnPyf9L+y/U8McpO5PyehPyK8rwz+mET0tP8AhxwKLajCPk/LnvvF
C1f5Zuhj19We77kpwhtlCPJ/07dT08WLWku5D1NRq0sRHrVtj4X+3VG+1sTu7NN/J2sjT7TMsl2i
ujpjSdnPkl3WxzfuOMXkef307fJW+P8AkdVYxc7PYtyXAkmlXlm3dG69x8WQzhsXfG/uPKY/YjLf
H7Wcx/ydtDnOSi78m1Tj/klVHpydGdWH+R7ZQf2G5SrJ/ERalA7HEzqJF+rCzYqf2LIt6m1+zGo6
sbKcse5nWR2aiYpxkR9SSi/kahNMtvyL8zbI/ixsezVUmObeDbHURviKGv4P4qK0tRMu8FSlRzZc
3izu1EfxDbpzx8H5l7vc/L1Gh08M/N+ocdKVlyEyKlcJIktN5HL36qKFu56cHBwcUe6RUoNyGtG4
lydiUn2lJNS9xakHVMS1tOTO3Ro2xtJlvyeo1u+DZpRcVwepqpv7n0n0jpUymnOPwbYact3uetqw
9SJshotOqJazhafg2RjL9RzcPUTK/wCnMae35KknqI/+MVp6fpoerrRc5MzBWfQjfpLKHB6Lm1yV
HQ2kN7dc0aUXzR2aXqMe5vTXwbXH1V7mNLaOD0d2KtjnLrceTY4bvk2KOwepH8x/J6aWxfc3Rbl7
qzZ6Sijb6e4aWhT9xaureOELQWIryNvLfL6XF015FDZvNr/Lib9FG3+HH4N2l3L2I1GtpUtOz+Ch
w2qMWS1VK5N2Vt4N+u3/AG/7UX7utObjEzJ2fW6PkxLBiVGZn1mZtHfk7G19jvdn5cnE752Z/fVF
tHbqS/yd8m+vbOS/Uy2Y1Z/5MylJfJk7dSSMymZMNr7Cpz/yd1sw6PrlX3LcmbaL7i7Z5R5o5kZt
9Pql/nqq5N1FJWXk8vp2l104L2sUXyYRe3ptqy2izakZ6bmiqL8GUXRwNlF10owXQ4vx19SGWU9C
2Y/Zj+AfwT+CZ0DugoLpj8cXP6bFpvV48GyEi4ihHNHCOEVq4RRe1ko+34V0SJaklhK+laU8fJ9c
T60VqyVfHVT1Y3Eqro/LRkSjG0ZWR9uF+C+MWeLPkjpR8maM/wDA2hr26pKOC3yPBx1SPq/SzlI3
rj4HjA9vP3Mx/wBv56e4m1givN8G6iKisFtG2jwe46O3JLHkuiSfuduR4/fSiy3RtVWM2+S2qPcU
pFYGxOsWZqx0ONC3DoUF5E5GKZdGXR25MozNFQe44Goo+lnBVHqaqwSqNUOUl2nd2lx4O1C3LJ2j
dG6S7UbFBURT4stijdNlqKaZv1OCro3x+kuWDukn9hvSyOVZOLRGW2vuaOOWRUVRtnyPbdjnjHg4
Rx0jpyjtm8EaXazU+C+vYse/Sy0ultHBVZLHj8G5LtPJlHbA/wD7DdHBtos4FWnuj7iNSuL/AAbo
xqPuZTPchJ8HpJdlUSn4NsVkVp2WbUqZ5Z7jTRSFq8JkYEdq/Mkj0H9XuVLnlEq8Mpo3rEScXyep
DT3v2P8A4xKWrHb7E9RLc14JJfs9JfBslp7Rv3FGK58m+cc1gjLb+YQ0p5lL/gSl9LJqHgyvBuSr
Fla2I+T/APRq1JEnrw2+x6fuVBbYrLJfs6X2kTk13xQ9Nf7glL2HtVC1L4ZFe5bWR1g1PuYHbH9+
lpU+jcX5IN+SWBr97JER91owKcom2PKF9yLPgcEI3I2jn7mPA1J5Ial2kJEtzFfV7OaFG+fY9SR6
UOT1J1krDPCPUa4NqwTQ49NvSSXI97skyOhsz7ojL3JP5Nq1KiRnJbkhW62oahOlYp61yIxiPa9t
FOTkd31M9GDt8Hq6se5lLg0BOy6sbUDdDFCTeS66afwaX2NX26qKI1BbvNlNL9OkVBLJmMX+hUoo
enVSLcF9y4rci1w+qXt4IR04JYNnn7FRRHbFbny+jUkSglkcpQSSLUU4MVYghRilCKEa336wjdfc
jGEUvejZJWfSuCP7PG/UNh6KTc+B/tMoqTlwKWs2r4SFqQzB+5B7fq4Poj/gnCHMeT1Es+Rak8fB
iK2LFGnqrixfYeq6vcInoNd5c158eRulCC8Gt3KKKlq6dfc8S+xF/wAk/J/G06fyOpRl9iWrprB6
cVbI6mqrfsxaad6ksUjTk+WjUnPkgvFEtOaXdg7ld+UNpbIR5JaenGlHmRHbE2qvlkP2XRylyT+x
ozTW5s1v7Wan+4NUZJfJGuOio1F5LfsSSP1LOc9JGmTH+9kIfsdzSfyVpjbYpuO5EfZjPkTqihi0
6yvI5e6GLTq7FIZBksWXVH3N+ojZD/gi58H/AKlxnLHgUfTsqUoxNunqqbGSmjtVm5qujJ+xIgyB
L7igKlmss2oTirEqtG7U5F8nqSVnyxynkk14Q9xBrk7OBacyN+USFqZ04L/k7vYaiaZpfY1Pv1Ut
J9wvVTiWhNSdWQ+34NT7Dv3If29VLS+oXrKiyDt7bI/ZD01oub92Pb+zbUzUcuTUIdIbfch9kan3
6x2OpEfX4rkv6i4TcUyK9mN/A5r6RR+TTcU20vBG8ZP2YR+0tn6i0vTTV1Z6m7tq6Ifs8Y1BSuyE
vdEYRXbdlvwsl6fKfgznFD235Zt05OLF+ZJk1Pd/7GnCOJPGBy9SdEvUlJ/cmh6+ork+ENbr1SGt
ry88exotext0l2TfJpxf1JZEtPOTR3cxiaij73gpm9c8G3SdblyKUpW2+WT2+VgW/wDhwNeX/ias
vFl/7flFuhV7F/JfsKPv0lL3K+Bt9P0JZ8n6EkvcXhIaTH+9+BIbOx1Qoaj7ixVw2RvwiRQujRv4
sr4JMjL2K+CTIZH8mWkbeaGk+RyckKXabUW2N3AdG/jcSsavpW5I2pnI5bkenAjqyFXCJSkz4Pqz
R8CluW48FbkhqLFb8G2LGpOrPubE8i3cHa0xTrgk9y3eENvME8m2Hgai8GfJHUmjc2lFE66r1voF
teD4Nu/usi2+EKKlluiMmy179Lk9kTZpu3xRe2j6RPVj2mGVuVCW63ZiXBvltY06T/8AEm4/SOCf
JFbvnB6XuXiSH3cGObMRMxFPU07Q40kx7ZRX6k4Slb+D1niBHuH6jTfsT0o4V+RXKLR3SSS8Igo/
ysX2HKTjA9HSfwXHBt9bt4PVvv8AcWlqPPyb3OKPQ/Z3l+T1NTUjKcvPkjDRznLN0nHu9yS7ZbvY
+qFfc/iRr4ZDTUbjHyLuhXOTt1dNfqQ/Z4Z7itP6tvg9bUbb8fHRQ1ZYFL1Yr7ktH9me6T8oevra
kXqP3Nmg90/cfqSSlXkfpTjJ/A4amooccnpaU92KItOmhaOvKiUvXg6zSP8Ap/2eXp6fmv8AcKcX
Rt1pHazbZGW7CZTZvfJmR2sbGouxtspEpzzZthhF/vvUq68CT05FQi10uPa/c2yi5i1HHHszatJo
pJoU/YS9LPwVsZZWzeV6UkOxtQ3H8Nj7dpuj/gr0LKWjVj1KbszolegVt2lVvP4B9OxHuKEYbkbf
SPUWPgr0ivT2lyFHTW5FOG03S5FFJSSO2BUo0jfH6ja12lsuDKoprBbbNsODvZfk2wlaN3k2z4K0
5dvscn5r/wAH5b23yfmSx1qGqfVgvU5/BWnq0V/1Bepq2bVq4FOTuRsjq9r8Hqaz7ubJvjBJes1D
2N+tPu+TunE/ixG46sCXo6tI7ddtF6s3Jn5eq4GP2mR+ZrSkdk3F/BWpqykioa0olvUbl7lf9RKi
/WmX+1a3cs9x3a8bP40R7daNlfs+q4p+x/Hl/k/Mm5v56dmrOK9rO/Vc/udrcfsdv7RP/JWpq6j/
AFI6ksqy/BKS1ZKPwy/wY5P4uq/1M8mJyj9mc2Y1JJe1nOfc7Z6lHdLUr79Mas18Wfxp/wCTltn0
yZ/DZ9J9L/Q//WIvZL9TmUS+WYk19mfJ2bv0O6L/AF6ctfY+uX+euItncq/D2wsuUGv9sUcHBlWU
0XRVHB9JwXtNtcF0bS1Er99tMouh9OC3gpIvacFLJlHBt8l0PtKLo4KSLkjBVCk4nBiI1+BVEtxy
OCidyODgtx6PAopZN045FFe9G6cTgvabIxO6J9I304KoVpWfSYqzvpGEPiz00iyuilONnCTJL90o
wykbWrLkhNn/AJElGUl+p9Uv8i02K6t5JV1468fh8nl/qcdOGcdODgwhaurw/DJY8j9KdFeqy9aT
l0wcdIxrkmlTnWRx/BFRVoSkt0vJUY7ZHHnpwRT4EvTTpclXDd/TY16dfJHs3v3Kk9OL9rP4aolG
K/m6VFCi48i3q5VwOOxRfuPtxZXTgjSs2yhvfljUFgwfSy6EttoSnBSl/wDRUIpS9x2qK/2tXg3S
Xg2KhVzQntMrNGysl7VQ+2um2hyrBhEtyxZ28Dkl++UWjdtQ4pDFg3SwOEK+6ISaNtIlwSk1/Nwf
Sh8HwRpeB8Gml7mEOLSN2GdsbHvjRbwbdN7ju06iZqxuKxZwcFUcd5P7Ep1mz8vLHPVWRWh7VSXg
cKHOjfNdL8KRtUs/JGOm7hZBy+pjd1I2fs9sjLX/AIjNmmrZukjg31grTeRKf0EpvwOC+r4Ixjbg
2R3c1kfqLEnh+xaHJIyaenHU7b4NJvmifVRRGU6i37nii45+xtatI4X6lpY+DZBC4H2kadRk+CD+
CU3my6pCmlwOHHsJGY9zLkkNxSHa7I8srA9tFdfcVJRRWL+xcVgU9es8dHKCslqan8O+j2pD3RtJ
4Nqwooc2j0483wQ3xSflj9Pk9GuD+WIk8/oKUPpQtTb3EX78jnSVnajfrKkhS042q8EpVUitH6mT
Wt9UWaeFfA9iTn8EpaiqCxk9XTpfI9OL7eLFrzlJv5NSfsjU0dF9iFOcp3Zpwf8AKsjUX/MRjFci
nrRy1gl6a7oofp/UzVhrO6yQuuRuNNkrXYvclONKkOE/sqFOH0SP8EVqfTfR6mllIk67qNug6nIe
nru3EWpWaeS/f/azs/QnkqTItcMkzcyK+B7WTXyWy07JEjLP0H+9XRm0UpRyOECKk+WfIpDVkG6d
5JP2KTwKb9xrxRLazdKXBCie3kXLyd9DUK/Q+KFccGasjpx+kvarNjhkvA5Y6NEo/wAp3ukVptNf
HRoaXNkxKOo4q+DTb5Jm3yR1dRYNq5qhxiLU1o9w4Qy/g9XUy+tfzeRqK8mcanlj048EVzbI6uor
m8ocIvPkciOnK5J+ROXLVjUcGmaX2NXqhfbo0/JqTuobuOmqvglNKmyL0vqY1+0Nxl8EJQzkh9kT
0l/KTvwbIukab90WubG5kHDlsi/dFJV0zOK/Uls6x2OrNJ+8Uej4XJp6V79z6d0lH7sk3qRePDHC
NVYvRntNurBv5Pyn6cbNKbfdKOR6enPbG6IN2q/mFC7S8s+TdDDbNFvmiOlwvLZOtRNscd/5N1Rq
O3hOiSnqtx9j82SjT8iUZJx/8SW9pQ+TV9N2t3gg5ZRqyjxuITg6kbpcxN0nfmh6duOn7EVWLNse
I8yH+zaD2Q4bIw5I472v8D/Z9F/mMz3zfJHU1I9/9JSd6r9jW1dTMpCcvc1Ng2ubJac87PJF3dn/
AE0Lhp/Bp/c0hJC15/4FHck/azV9tpqmlKXBquHHwL7Mr/ab6u+jkJsivYa5F7F/A40xyfkVEtO7
pn3JL5Mn6D/e6Yxm58MVSGz5INjQydtmPYYsuvY+aGae336PIvuNReTubefIojaWaHGntI6kmV8H
absmxbZEYThUST+Ce73NsW7+B7r/AFMuh7BznwOL5ZGS9yFkhRkiNYSRyLUmt2BrTVyZulZQ3p/W
fxMD9XU3Mzl2TZLJcsl8VDBLNkYrLYtXVXd7Eo6bz8GWQaVmnH2RqV56oj9ir6YPq/K/pNT7EoPk
hGJu1I2jTjBVkS9jXJr3I0iC9kTn8j+xor5IfYwJaM3D7Dlrark69yjHTTSIR9kieom02/BBy1JS
r3ZuXsNrVlTLk3P9TdHEn5NsvpJRkvBGsd3BpfBKcms8I1NP6Rwi9r90acZZaRBryzSj7I3J19ip
SlKvdl/JJe45un7koxfdfglDXm/1Nn7PLHwPR1Hlm2zYnjzIj+x6Dtrk9P8AyylqqfjBPWX2Gvk1
WTEyb8bTGWerNJ0S2vfrPCoetrT3Sfj2Nk+BZ7WrQ0nbfLI/sOg90/LQ7xJktOGpulHwS1o+xHOV
k09PyiGtHhEUnlPg0/2hcGovdGro63EnRtbw1hm2OF5kf9JoZ24cl/tdT8IXd+hdpCZ2PyZl4E0K
JvZ2nJqS92JbvBL2LbqVcFR4/fQfyVfJJvkwLb9PkVsUY/VZGxt+SVEZNrPyP2O09RyXI18e49pl
pV7lWsfJJLkWnJ/qd2pH/JdxOaifXFfqbnsZ2pX8H1JG64P7scYxj+g2LUc47vZjqS/yVwju1If5
HtcGboMT1JbWY2srcKUtRbvk/jKxtakWLU9zZGas3WKOpqJP5M60SlrKjtkth366Q9mtFjUa/Ql6
s9tjhp6imvgbFKbqJthqIch+u9rXDNulPcW2WR3S9OZ2aqlIbi+q1JcG3T1ckXJ/lo2w1M+w/Wm0
i9PU7ju1Gn8D7vy/c79TJ+TPJPV/aP0ZL05dxPU1LVvkrTbZv/aF3XhnncS9K8+WbNXDXkjKEu1M
2W1NIctS/TO7LK0E7L1HUOTg+ij1HGypwyNwjRui8la0W/gxoscdC4Ia17l7Feg2bNDTcbHOb3Mr
VuUeMDjpaTU/c9aUrX9JtnpNsb2S2PghJaHHNlPQdlaejt+SzdDkUNXSc2bNCD0y5Pc+u5co2aml
v+TZpactND1px9Vt27PT0dOUDdJvUjyenDR2v3kb2t2bPRhptL3HZvS/Q9OGi+NuT1X9RPRWm3u8
o9TUdv8A+uuyUXqj09DQenfk9eXe7uQ9LT0XC/I9bc5tu2h6K/Z9rfMmNS0/UcvJ/wDFHGP7Lget
yv6Sl+ylT0nKR67WyndI9OWn6g9KEPSXue7/ANsXpPad7wVpvB+YVpvBh5MTZ9Rl5O52i4vazubl
EuLqR3ybiZ/fY5O2cjvk2uvZqSiZm2dutM+uTXydxUdSSP4szvO2Tj9ilqy+x3tsw2mUtWf+S5uT
+5T5MTml9zOpN/FmXI7ZT/yfxJ/5MykzDcfsfxZ/5OW/u+mG/wBC3KZt5MbkjLkUztuzutmUeTG5
GW/1MKzg+CnExB0eSunH4u2JbWCkXt69qMocWq/BeOnBx046cHBwKo5FOXlX04OF14OCkrFOmkWr
NkYbqK/6dH/x0OPoqNlqNtnqO/sZ6VFf8Gb6e2De4s2/gunRup4KfP4KWWb2nXtRtl4KijyOW14N
jXd7G6nRuyU/96KIm1aHwmLA9qyRbRVHgrBwcG3bg3UemL3G6H+9hD3N1Id8/A6Ei2mXQn7masdD
hWExN0OqFpoU5UOqK92bpcHhipYO5oajTODukk/kqMom4aRwZXRT1V282NRXCHjtszj5OypGEKWo
s+xSqxtIcKwhQUM+5g36+Ct9G5cMjFLBlYXLHHSlfTti2cGUUkfTjpwLtylk1HtSor28H0+B4MkY
StahGUYraydL8G5RdFKJbiVWS9h3Ro2xVs+nJwV5R3Kx1BcYJfc7Vjpcl0/LWDuPW1VhC3NQXhI/
+mbVHLM8GyCtm2aP+olG5ezOeUSS9xdvaLShiuX7j80zPNi3ae3HJrX7El07Y49yEWqSzZjt04nZ
3L2ZvgsM3eDYlbN04+LFLUXHkdYrhIr3ZGS+qXkUPSeoyOo40pr6WS1Gqibn2wXsXHuj7CkuHkf+
84x+C0sk9P8AwKD5XInLyPauCME8dG/BsYjc49xP4HOLpm18o3V4Jr2f73S+5JmHjopNYPFjVYI4
Ny4HHyOXuxuPgalyb0KPmiW4glwR+R39I/uVElKQmvqNv/0erqNtHpJ5N8+DhDdDxgUIKkS+xqL3
ZtGUydc0SWo7VkvgaaqbZGa4YxacdWl7CnqyshBeBvybLofuJVgrl+46lEbE8O+lo3ai/LXk26ao
1fsOUMOym8/JaQ/k0/uaRPrBamI2duYHG2/cdck4y+qz6bHKMeCv/wBYZhZ25FKK5yKpVqexqR9k
bFxZGK01aWWbN0d3si4rFG2PvkUdlyZvgiCNN+Iij8kPV+oW2vufSpT/AKhR0vqRDQlHD8jXwemv
1IQgqdZFtdSJx9sn/Uav03wKMUo/Brf2kxYpWUqjX1SNZQ4iOHuzUS9i9T6bOxdrHNrf7IcZKpfB
WniN4Rp6kvqlyX8kfguQorhEiMPBqxX9RH9R/wC84n6FicfJCydEb5IlG4UiUH4NT7Gp0j9if73S
+410inj7lRXcN3gt5O1UivI/cUFyuSbfkf3FB83g3/BJGVdi+CRuTxZdWTSg456b5jhD/gi5fTZE
7J0kzY4t/It7SZUdRX7dJSX8pvq2NuO0sbZsRqEfuQJCnFdyIxloeeSM303KO5jnNZLo1Gibi3LI
o6kUoiSWfLHsd0Q+5CMfJKF4Xg1SXuQem3BLkW54iv8AI1Fmm/k0yf4f2evcj9ic6uUnyei33mp/
aP7mp9jU+5ATXuan9rM+5qf2sb073N8i9Sb9M262nud8i1IYXsyUWt8yMjtTf2IOaps01B9yNL1+
Wa2z+mkTc3fyRJfY9TbwJS0G68j1IQcNvuSnWXg0nVWjb4RrfYdLt8lRwlzIf7P+zYS5fsTvLa5N
0VbNbU1IuPjI15ZqylezwRr9S5ZgRpeTROMYNKiMYTlBfBpbnb+RryRlBbiU9RVbwRT9v96aUmbb
HMTYr8H3ITXv0rwKxklY7Nq8ifBtvhEn7/vdF/I/kbMOj09SX6sxkbSI2YGbvcropfJRJkF8iJMd
+5SG372LTZ2+xnIp4wbbPg3zSOzBDUsf2NS3yzaiRV/c55PVxZ6cGQ1PBCK8ItnKZ4Em6SQ1fk2l
e56docE8M3SZBKcTDu0SW7LIpvjJHI9ZurJK7NkcxXJW7NEowdIzyQ1ZxI+EkalP8Fi3K6HKUs+x
iVs9aX+SdO7Qq4NR7uUSzybE+ELX5iSv2FO9qMZtG+aK3RjL2HsfbYtKOnuSFLU7cnozdJEZSqXk
fct/t7H/AFGvnSsy068Dl49io9tkNRpbuekpYs2XSboSxuZLcLTU1cT1pV9x7ZblJGtKTSt+D0P2
f6fPRbfpE7j7Dc3GKX8qFCE/yk/8nsl/yS0lSp0TmtvHJv3RpCiqpG+bVoX7PuVoUp1IuU0ox8F6
d+n5N3bnwbpSXwkSc3Wl4+f96IUdR9vuVHufyZlWSov9TbqSO6VI27i94qZtTPVZ6cXkjOXBs05Z
+S7/AH0ZewoyUioJ7vccvfpt1rkdl7fk27GhqMXZvFFwbkvKK2yNw92nu+T6ZfYeGepKO74NvpTO
2Mor5FKODv0nI7dJo9XLS8Hdpy+xjRZtUZI705n/AMcpQcEZKUN5T0meqo0V6Flejt+xbsxcjatK
huYoxgpxMaJXo18jkluvwfwCvTf6D1I58mNOynBo9TybVCythc24/YjGC3r5FKkmjZKj8uR/Khx7
aHq6clufgqTSM9FHRlhe5TaN2pz1SXIk/J+VLbIfqzPy5m16qP4p6vqd/ubNTU7T8rUaH609zZX7
Pq7Y/wBJnVwbpzcmfl6tI/8AkF62rvf4LRUNfB+bquZWlqbEP1Z7z8qTgjdq6jk/kqOu0kf/ACWf
m6zn0qOpKKK1NaTQ/Q1HBlS/aGylrv2K9R55PpkYizKK0tSUPhFaspTidnZ9jbLWlKPsbotxl7o2
z15OJWlquJ/8mRn9on/kuEmpe6Ma03+p+bqza9rOCoasoL7n5mpLU+76fS39j6WZX4cRb+xlf7sV
G5opLrwfSfSYRwbWjdtNjLor98kW0XtK6YMm1F0fBtLo4KLrBwZMIuiqFKj6Tgs4HtRT/BhFyibE
jc0cHBhYMI4NpuknRVCpWhGEZWDx0dcm7b2nA8fjpCl8HHRTksF7UOlXWM1yhQWjbHqa0diH+Fe3
kuKwYKj7kaX7zwKySXuY6rUn2w+Sv/2Fwj+B6upwcUZRprT4Ylyzn/A9SKw/xXFWJOPb7ij9Q56S
4Q7XVRXuKLy/cpD1ILA4+S+icsL3K238ktTRWBp+P91QiRbWBw8ly9x7VaMxKoxFG3YKkfTdkZRW
LGqyskZVgSihz2jj+HP7jR+5e3hDio0xsVIuePuNKt3wbpGYIbwT+5HtTwPhEYr3PpQ00hV7inS4
NjSPGBtR48Di9Lai3g2x2uhQjp3H3G3gagjuRwbUsi1NRd/gZJtZTHKKtj9SG2jjJUF9x6dIlIvU
XamKuOlx5NujG0RnPlmDdpq5FbcC9T9R7VUYo2USlWRvbgzEeDaomYje0/Pjg7fI2kZRGGnLt9jT
k+Sf4I7c5FFLwbWXKz6XQ3tNrVF0XVIqrzkVRqTHF8oaX4OO04S+43WBzniPuzscWeHIUNuWxaup
2Cftg1fuUkXS3VZHTksWR04/TFDW38u6ocZKx9uGzbGPmjdNd/senBbvgSjKWmn7EPVe6fuJ1ckj
0dO9P5Pz5uepP3I/s+m09Q3a9Jv3MUbofTXgoSivJU131n4K0+GRhofdkJzWX4JVHBcEvd0epq0k
/cUMZNSMHUmT1NacpL5Jx8m/Wq2eP8EZwVxTzRpwiqF6X8KD4IOa+pZRKMff/dWnZS9un1YF7kn7
Ij7X03kYrgiyk8kvt0cb7REv3un9x/2jEvcjOSx7myHgy+WRsbNifaKb8kl8DUGb5Ea4JbeSKk/J
FI3+R2LcPbVlLgdLBumsnpQeLN8lubNupH/BuVI9TDXXHlndwNQaf26SR9zU+xWlPbki5cjZ6b7f
ud2rD/ItnB+ZKinqx/U7XF/Y3Ikn5NsRxfkUY4XR+pwdn82b6Pf9PyP0yMHbsjJ8SHgh9zTJfgUo
5+CE+DcVJLCJansR1H5Gz05cJGoT9POcoc9TD8G6H1McpdcC1HOoe3TVvwrIfcvpHVmrrwb39kiL
8MnD3kRn2t8m7zZpzwpX0il9bkM9CbxJ4OFjyP8ArkOc+ZeD/qdX6fYcnSfhDbbq8IU5xub4THGL
vUeDfr973dMtL9TVucXfhM7FcBcOfv7H/S6Eu98s0m+Sbmk3Rp1xQnF4NOfG/wByc3/KS1FNra/p
FDU0m5Ia04OLRk+TOpFfqO9SMm/CZFmqpJbmyD+CS/8AL/dWi/kWfBcelElaFJH6G1JtkdRokKMn
9Q5fHTcxXyS/e6f3P/QeCMnwhRj2r2LQxXK2YHYop9tjflonZBRde4mMW3Dsz7EydmOSe6TaKN9Z
HpwTI6jXkih0vI3Fujao2Q0/SoTJ2Srkk5tyz5MsdOxN/STcvJ25yRsdFCqU6NOEnbHpweDmQ9xl
0Pa8k9TU4IqTzIsrS4+BS19TBA2fs7qA3qalL5NsnukL9o1lj+ljjHEv/oe52iLSvJpJ80S62I0r
8jl46T+5AonPxRqIa8le6IwRfD66dmlXsT3S/J8I1IrloUfZmTcvcojGPKdkF7InqfJFT1nsJTWo
t9EZ6k+xMUou8EdWUvylnknOcqdYH+1SX5SY0mlZjlYFF+9GhXsSg322Sny45J+n9bHq/tLu35Ia
kapsmly0SvWlsvybt7l+op0k65HofsuZPlnqT7pXdkNPf3IUlKvcSk9sILkrQzBPJCNpKC5JR3KW
7ybWvqYp+GOTXczT0VP8xvJOvKwxy9SW1nq7t2xXyRhCVzgskdbd28s36j2wiicofSnz/upNeCMG
9r9uk/hjUHmhqbPcotiSqySs0n8kleKI0zfJ7Rwgxt/vdN/Il8DlLA9vBug/0Emz/wAhSf3OR7eB
akmjaS2m7GH5FFew6yyMXgSbRL3JWK5L/Jutf5IRjKsmWr+5vk4v9R7do4btpulKL/UaqL+w6N85
JNPyX6i/yYfJ3TiNxlD9GNaTr7G3Ve37l3G/uSUGKerqJS9mKPqxx7DfqQZL1NRJClGcBx0f+BrW
V2+WK9SI9s0y9Nn50tr+S4yi2LVTbSYvU1Npu9WNmzS2y+xWtL0y5aqbHHSlGRv13sh7mzRmpY8D
3Ponqz2T82duspNIlKLu/wACev8ASvJGPrcDWlPdY/WltPT0p39hRlPNG+L8m1y2vyOMdR2xyhx7
kYyf5ZmfcLT0foeBOTts4LVo268sF6MnuHul+hTwOWi8G3VeRTTfpeTN7iW76PA1obn08vpFaj3Q
MK5lyf5XsLTjBp1n7kdWM3HTXhi09WL3L/k9SKrNmxwdx/8As9Qe6NxZ/Dkfw5EV+zrbRGGvByn5
O3RbI+mq0k+BaOnuVKhtu2+X03RIxnouU0hw0U9LT4Klpbn/AFGzRfo6fuOGspamKIuGjSXuR0/+
m4XgcNDScJPyevKbcjZrabmz/wCPI2af5On8Fwbryd37P3DW7Zo+xhf7rTg6ZW64mHR3u0XpOmW5
GJHLO4q8GeTEsFy5KU20d/7+tObR3zbR3dPy5uH2LnqSkyo6son1ykXM7NTaV60jvtnbJx+xUdWR
c25HsUtaf+TMpv7syVpzkkfxpluUrO3Un/k/izO6cjEmjGtP/Jmbl930xJr7H8SdFNs7XJGZTf6m
ciq/0P5q+enLOzcy5ORhG65UcG3aWrPJwfSeS6KVs4dH0lbTKPpKZdde2B9Jtf4b6We3Xg4XWqFq
7d1eD/4h/wDFY1/0g3KG1M7F2o7o/h460haj8jvpuUcFyK6Z/Cko3+h3Kule4prCfwU8dLp/4LaG
vx9qf+C2v+CvwLbEtp/4N1Y+x2LCPJfcNS/BUItEpVJlNfhuMajR34+5tgmW0y8lSQtkRyawimq/
2Cv9C+t0ZW0lFZRxmiSaxYseDg4R4HgxEdrwKPuzuwOSX75EZOuB3Q9vHXc10W5Ie1HpkZyoeDav
Jul/yYpjkJs8WJRLmVGSZhG6biit0RtLA0jg4KFjt9zaln3NkeDPjyNQluG0eprfoUqG0haaQk43
ItHq6n08nfWmi4ZRuasucYxj7j/NRsUk17i3OKRt05KUvYdQSZep9Xk9OM1v9jgztv3ZtlKO74E4
wTixaUUfScdIrWe3UIzhFOL8saivwdsbZmI6i6NtW/YT2n0m1I+nBiJUjti2vc+kSayXRiJbRVC7
VcvI6RhWLso+kp/gimrHhUo0kTpEcWfwvTaLfgqKtnBbjgqKK25Lo21k9TUipSfCN2ms1RTIvlov
FKNUN8IjEqPbGPsSuSaqyXpRtFTRuisHcsnYrY3OJtfFlR7YrmRJQe5cND1YLkvZgSrkhKUajzYr
1IqVW/c9HQ0N6urEtSPK4fgnovV2NSFp6Ol62eSOtWy/A35o9xRhGzTUo8lRwlzI1NPTeY4+5LW0
0l8Dajg2Vk37RbuEbIdsYmn9hald2OSLWn6reRa8obPg02opLllvthH/AJJOGVdOI9eH0sa9v+24
/wCzL7kJNXg2xKedzLkWjbDArzgTTwRjJ+SzuVlI+zPTeRyaHXH72K+SP9pibWeixg3SwyUYF0XH
wPcbvBS5SJbyMkR+SV8Ciiy1wUVDyiUnJ0ORshRHV1JMcLzQ5tY5PCHQo0KEMe/SY4LySlMSaux1
4Q7faySfsTnPm8C1Ii+BL4ER07vpsLpm7TbibZ6n+D19Sx5qTJaa1MEdWd7ib9kSjHUojzLuyRi3
iCPVhKpG3UeTCOBe6ZAl0wVHkjq6sb1JeBQjy/BLbGq8mrr6ix4K9ND7aNsnUvYuSujtyRpdjeWK
MNPHyfw0b+EJruRS00ScY00bdR1GyL03uiRa8ktfWjcfB+bs018kpaVS+UYx+Beo/wAz2JQ24o2L
3PW147r4EsKK5SJVjOBas4KU5cH0R/wOLilZraTV6nB6ktNKh7IxlEUtRdjzZv0u7THLX+l+D8r6
PkitWPdZt2qmUuB6zKv6kS04S+pkJOKbnl2VFVbIdiuXNjjpxqz1JxvyShtW7kmpc8koe468xG5c
WhqEVXDHqOpLwhrUSUmqSQ5d1NilKN6ngejpO9ZjlqSbkxPwJOW2EOWSjpX6ceSKSYuN65l7C0NJ
2ocs1I+5GceWasjbBRwqaPV5X9I/WiuKUUS1dCWyMuELU1XczS+ESUlij8/heRQ0vo+CSapJGx8N
ko6f8ysl9yT/ANpw+5D7EmhVzZ3e3S37i+w0Qa4s/QWnLyWj9SDGP97H7kf7Ri+4nhyGocD38iUV
kk/cmbH9V4N79hoW5XYn4Q0iOpLK9jCpM2+yHT2ifO1D0lCmNjlLg2qk6OcdH6U9pU47mbtSov5F
+bH/AD0peCWpV14HDZtQhkYx5J/YfsIX2NyuS9hL0BasltLgrZnRG5x2m6i39BcVUY8Il7WerpLc
yGlOCpmfMT0482RaX5kuWPQh4Mu2R9K0L1ZW1yxqDsi/kgN9dI0v7TWNSiJ+dJr7H5cJSZCWV9yf
9pq9HOX0xNqjKZshpyhH5I37mk19Kyx6cbUjffLNM0/sR+5DF4FH9mk9pf7Q7f4Is/Qz/UKuEj9p
3C+ZGl/abJ6cpy+BvR/ZHXuzdqqs2a/2Jfc0/t004xVtxLkiCXvkj9iyMd3bfBqtezLlmmaRf2NE
jqVdVg2LS9NryerqV9iWps2x4RJwVyvgnPUg4RiqyS+5qTd7GiP9Qt2YOQtVx75Zoejpd2tLA/2i
StyNOEl5NNRX1ZP+lg9kU6wRUVcT/wAqy/Yl+y/sTt+WLfK5NmptVyPzIbYRNZjn/wDq7vo27cLw
cCNPB84NJQnKC/8AEVtv7ih5aPy1crslqa8do3LCL/2kxP2Id1jK9jJS46L4O03SH9iG1+R2/HRS
JRbG0/3sfuQ+wyhRk8e4vI5I+5QyMvZlfA5MgZ9jcKPyIf2GjavKHPwJN8i2l+LLcVZsvgdI3SSH
COCGXhmmvgnNm2JKZlmHyLWwTgn3CkvcjHp6cSO9mXhEnuVXwzCRL5PTvPkfybbybJOot8iScZf+
QtQlKTSxhEafkjJuqQ6Irk5SlV5Hp6TaXwXMjOSdcohBcJDpj6Qk/cjT4JanlmqzZeS5Kx2lHHJG
OnTr2Jy3Lg1F7sUJSRtWVI3ThZHR0mt7xtNOK/UuXNFIjFcpmnCi5ewtHd3Cvgk9qXySjoZfB9DP
oZbixakvpTLFqN9qZcHwqJylJR3l3cUR01PuRv1FY96jCNF6T/Ls1rkraPqXIoJ3twei+WbpbXR6
ejnUHqyaqy7Q2mm7PXlKPwrHuaSfOR7GnnwR0Lpm6VNm1cLgeTdoSpla+pj2QpReBZW6v8kpOUYR
XhC0Iy9PQTrPk+qNRWaJ6dKMLpM9TdC4+bNN748e56k9rl9yvy1BeBOH0qRpTepGlH3G4Zyd9Jpc
j/Z/2R7U+WN2237kZwdUKE5Lf7tkpucIpZwL9nhNQ/ZvIpb4VtvD5Hpba01g9R6kF22rZJamrFZv
ItOGpCvufm6sP8mp+xOSa3Umfm6kJf8AsOtWKhFXyLU/Y8QhiytSUVNLO7yT1d8Go/yxY224/s6+
mHWv9pKUXjyVKVs9VpKPwbYMbk8MSWUKNmWbYsy7ZvRt/mE/A6+v5G0zP76MZcmIZ9zd077lE2Qi
0Lt7vcrMmbqo7o2fQzCwb5R3IrZKjtToWpV/AktNm1Qkmb4uhKWm5Udug18ilG6Tszptl+jTHFQk
hzfcivQNsIOJbN23cV6bFNR2FPR3FLQouVr4LWfg2LSobmVCG8/gjj6Q9Xbcn4Z/BMx2G+Msn8O/
sbVAbn58H5eTuwWJQ7vucYO/H2FP+ZHpvguTs36X1G2dFvnoo6MsfI4t4L1JZ6xhxb5FtnyP1p7o
+ESg3mQ5aMqP4ioqc+09SMts/c2S1cH5OrVilqauVk2w1cGdY3y1G5rJ/wDIPzddyXsWzdF0yo/t
DR+drOSN2nPbIx+0OvgrU/aHtN+tqKLX9Xk/iwP4kP8AJOS1IPHuS/6XU2o/+Uy9Wbm/k/J1HFHf
+0SNkv2iW32L0puLMftLK1Ndyj7G7Te1/BU9duPsbdLVcC9TUc38lwk4v3RX/USN05OUvcvSm4s/
jTovUm5v5PytRwKlrsy7YtW3CRctWX+RynJbvER6rxH2/B+XqOC+Cp605Iw6fud+rOS9jt5+Cnra
n2spftE1+p/8if8Akp68/wDJ8m31NXaZTspScfwdkpQ+xnVnJfPSnqz2+1mGVLWm17Wdk3H7H8ef
+TOvOvuYk0/czrTf6ndqzr7mDE3H7HdOT+7/ANrJF0KImkbGsl0cZMxOCqODg9ul8L9+qRdFPrdY
Kouum0WDCopmEXWRm2i2iqOMHBhHB9BdFfgSRvcRQo3tH09KjGy3E4KNzjg4oSirsW6Ns4NqieLO
DGX7HqSVL2Z9J2o3T/5OD2JL260jc40Z6bpR7TMUjjqmbK3m56eyJ3zePHRSq4jaq0uBrz+NQjyx
ymvzPcoQ9WdfFlcdPW1X+X7DquDFr7H8Wf8Ak/iz/wAmZSf6/wCgpIWrrYj7DSRwcddsNTC9z+MX
+0T3fj+k362IFJUWl8nHT5N+px5O7t/uY9nPgca46pJWLU1/PERpQ2usD7cL/cUXXJnkUnVCUV4N
9GVwYiqMxRwblEdLJlDpCW1X8jdD/eoj2oaURs4E2sFY3D9iPYuB8IjFC7VfuNMSjWX4N22zbSG4
1ZGbVlOKoSO1LCPS9PHuW0NJxb+RQ09O/sbtRVgcdPmy2jg2i1taP26NNYQ5JXt4Q9OUNsPcfuY+
t+R6VZG68WPd9CYow+lcC+xvX1Ufkq2epqqpF0S1IK5D/LwR/wCoQ6/lWD0pL8uxuuDaqc0Qhp/S
2RcuaySjBGYnAvWjcSPp+w3FGSMNKVJsjObuX4Y7VmxRUB7ioK2RnqPbHmiX2Y4wVyFu5+TCsqsH
bF2LdHJSQtScc/JKD4kN3kUYckYuI3PyRXyaUKrFmyax7lQXbZdYNtXFeTekV1WrqKo+L8mKO3kb
kqHuS2LgbilfwS9RYj5IquRTaW6rHEUFG7N0UntWaFCX2JNLEVhG3Uj+XJ4Jpq5JYZu28kdOMbbN
063Lkf8AQnycr/BJwpyPT28CuSs8DxgxkUmu33NJV5JNL6VhFai/Km8E4yV4FPCsWnXk3OvUQ/2f
RV5yKepKSjzSIwlLtgsyZ6ek7iR3+3A5aKtko6i4ZqakfqXBqR/aPplk1JSWV5J/7h0vcf2MOskV
z0lARkUY+5nmirz0kQ+4/t++Rpk+m5q0OMfA5Sl+hGT8kl8DjBm6fhkUuKJbWR3ZIqI5LkipPNny
Wzm0hbi7Vj2jVWxamoh6em6PVmtx+ZD/AAWqS+TfhxXgSj03L+YqQ9kluFXRS8n6D9ObiLe9z9xV
7HpPtryLdqx/yVpO4ne6RXrRK05qTPWjkqeoon5U05s1fsSUVkj+060e7whwT7mPV5lIr0953SjB
teR7K/QSzKLN74ZKuSP3IH6fgjPyR1Jcn3P+o1VfsacGrcyf2NXVa7l1g4tOXk05e6Jfs9dq8k5e
Yj0JfQT1OdvBNTwkR1I8ojOf1EPsfnfoRmuGjZ/OkS+x+pq/bo+kIyVxIRWIpGxUtFfBjc9Sie99
q4N+n9VmnN/VJZH4P2Yj/aLTurfLFKLUp/BSzfJpKLTk+SZoQj9Rqv2Q/wBm1Mu6Q5bVjz5PQ0+Z
YZpvy8mWl9y3qQX6mrqaaXNWR9CW2T8jX7W3N+5+Wti4yKc8RXuObqOnH/kXjQT7UT+xoRj9Zq/2
j/ZZ5XCN2LXwelpLvl5LdycuZHhVzMf7N+yy2afDkKe5xrmQo7//APZiNZIlJ8EFp7ePBqk/v/uH
TyOhx92KTPqVkmhfBg7kJCfyKxka4sz7fv4MkZ9zYuzw+jwbXwmN+aJWQS8s+aJCp07FZMvyRtvg
x7GTHsfVKjPsPUkss9LTXwbp2bSSSMOUV7Ixn7kIenVuiE3hsp/SalcktzlyWxtMj/SmSk/CMGSN
ex8iqUyMZ/ULRg88YLtkt1/r0ko3RvlcUibfkleckq/ljgpvyJD2o3STQopC1dbtivBSqLXEV4H3
PaR2q8kFLka+PwL7mnfki/YXuaVfST+xqxYvQdSY92pJL7kPV1HJt+TR+xqVxZrkr9zUhHLY9SaN
q5TIX5INeERXuzRX/iTn4NT3qjbHkm5qrGPpFkX/AOI2je1k1orwjZDMrNOHlImk+DQlH+UX2G+C
D1deW35eCS0dVSmz19abd+5LY8SJftE3f9OSUHJepPFH/V6ixeDZvVvwR1V7kK8C9HUlFeyL1dS5
fc1dBeCCh7F69MhpUvcubUNOP/I1bjoLhLyRlLglLTdxeB67lcfCJxnL8yeFE/6zU+4tNzSnL+UW
os/AmlTfItL9ne3TPz2t7NXQtcGn6baceaNNPwj1Z4hJjUZXCQ58zJfs27drS8IbfLz/ALhjp/ye
4vJDN2c5KvtZmSG/k+Brycjpkc+BqLsUpYXubISTwN3f76ORttHYxOLNmo8luSsc20rZtUvA9rLx
j3NqkmOn3CyRjav7ku7Jtvli3NDcpoep/KRW5Ub7V/cWnF5uhbpf8lylH/JKto4xdFylH/I12tj2
rAt8lGvcivVjj5N0Wmzu1Ir9RzWpG/ubNPBsm6+WW5Rb+GSjpOkb9eah8MUFrRR/GizukowQn6kB
x0ZZ9xy1VuUmLdqRJOOojbD6SMp6y3P/AIO2UZEkn2m+cqNsJxN4oasttFz1VI/LnFv2FLWlt075
Ix05xlgtvt6X+0T2T+Tt1k64Rui+38EHr/wyMPX4K0dTc6NmtLZpryb1rpyQ/U1dtlwl+W2LfrD9
Odv2Iy//AFakVv7kh6+o+x+TZoyPVXnkj6s+4el+ys9XX703kjDdJUbNK2z1P2hXHwLuY1o/8lRu
SfhFPRk2eooOK9mLQWZvwJu2cSPUTlF+5s/anfg4ZLS/ZsJmvOfnyPVmsL2Jaf7NBqXFsc9ae6Mn
bPpyS9W2mP0ouK+TJgs/OTlBH5Om1MX7Rr9yv6T09PS2ySrB/wBQ52vY9OWk99VZKWrFvS8I/gtk
oaGk4yfklrakt6k7aM/s8iXpaEt3hj/aNVN+yQ9zah/T0wd1zh7H5X7O1L3PX1nftEjpQ/Z2pKNY
9z/qZTr/AMRab0W5JcjhqaG53eD/AOLIx+yux/tSW2P9JX/TdxKc9NvTf8pUdN6aRU4erGqJQ0f2
fZJqrJampJzk/wDj/ce3T1Go+x38+59bkjypGZWiozZ/EkZ1D6qO92VCTR33ZUJtL2PzHf7/APL1
HEzqyPzM9O10ynqSO3Ukj+LJouZcZuP2MasqLm3Iq3FmNaf+S5OUj2Z26s1+pmU5fqeTsnNGdWZc
rde5jUl/k/iT/wAndKVfc+pn8Wf+Tu1JMydrO2c3+plsqLkcyO6ylZ/NRmylZ5M7hra7L7rPJk5Z
5/z08mFJ/c7o7RnHTEbLaM9L569qs4ZTTX4eDjpwcdODjpxkUpLD68deDgyioQuX2NrVNG/9plsm
ngv1U2VoyUpVj4H+0yW/2iV/0qP/AIyGv+lRu1Fn2OBbuDZ621v3JRjrWyTSqP4e1F0ZX4OLLimO
M+V07IP/AAbqdFPrsjyX/wDsNsufw1FFtf8ABTX4FGNillfobnb/AEPSismUziRuldfYcIJnkpoS
ijc0+BqUf9uKhOSIwXllmFg3NHgvB4ZhYLihWi0hOXA9qsp/vot0Zo/LfTBuo2IUpUNJIUKyb5Hh
libKxY5IWCnVnbQpTo22rLQ9+K9z64jcVY0jg46JRXabX3S9z04C381k2qa3exaPU1O2CKHtQ563
aU9RJm6HBJyVnfGMUOtRWVp0/sOkfSZRHdwbktyFKKowXtZlCjFXPyS2xoeBaZxk46L15VOz1NKK
kjC/d/SfSVQtTVj2LNH5cP0MqioR3H8M7lkwsFKNstwaRtSx7kHqRvUf/BJwjgqRy+lJWKW2kJVl
m5wpHbHcfw2d0aLUWfQXtwcHarLlCkRj88lKoxXMvce3uR6iWHwXtdFVk3OFClNUl5O2oQj4Jfcj
H5NOEFlq2x6bmvZpklp+XgvZSL2EU43n2E/DRKW3t6qKWWeq4tEZtbtT5Foyn3seO7kltW6mVJUy
4x7fcf8A1D2uOVZWjH12PUcPTZp60qjGXJv05evP+k2vR9P5JQ+TCW98v2Jfs0Zdy82OcVUkRnJJ
z9iGg3cny/YxW9/ze5KL9/8AbcW0duDe/BFMvybUfqYMl+5R2qhi9m+C37DpfvoDqTRlioWpNfox
6emkb/dlLmh7iMvkS4bHfAoidFp9pt8m43RI6T5Mc0LUt0P4RKEfpFKUnVijJ5odLB4PD+xGCWBY
7/L6WSS8o3u6HfkSXBd1CxJ+xthKkKerdc5EnxFYJT9yMc4G+4UKKl3M4Ny4PU1VtgKEFSF9jdNr
njo5x4GinwPajdHDXAtLV+ryNoZ9mI/T90nq40/cUVpravI9rj+gpaj2orQkpJc0NzxD5Pyqf2Ly
5H8NHqJYKhmsscvT/wAjSil8oktWWyV4E1mPgl60ktTwidcX1S18Lwxenwx6mpleEhaUUlqy8Eb0
05vLs+iP+CtqVZHpqO6S5Jak4KK92Yiqlw0T0orPgWrrR4WENRhUjVU/qNi8s1I/Anq/RZ+XFZ8j
1J1NeEOM0lN+EbYfS2Q1Jcy5JfDFJ4zk+w56cuR/tP7T+Z9z6VX2KcV/g0dSHk0/7USg6l/+wc0u
0UFHc2R1deN+yFoX+bPCS8EH7qyeu/qUiC+CelNLfJ4s3Yj+hJuKWmuW/I/+nWzTvwb56kZM2aWE
R06ajXJFQW75Lf1s0/2TT7pXlmovgh+1/wA0mMRq/tL5gzT+w0vf/baP0Jfcj0bjwUZGlyRPYXuS
+whfYfv++0xjZGU2m6wVp+w91ijVts3v2K9juW6yMiSXBGbyhUqVDS9jcJKNJle5Dw2JnorT/Use
O1M4W4cU3tMruoqE9uCmnN+5u1lt+5/FRcXaNOH83kb/AKUPQ2VXkz0UfNkX8HHZHkxSSGot0bIR
szom/UVfBurJuk6ivJXq2yOhp5iylxFGru9yC9xTlG9RnpRl3+xqj+5OceUbpcipCjpWn7o/Ol3e
WbdPoj9P3UVmUG+Du8+43oOmP1Zbok/t0Saw/JDTjGKdZZOGndw56anyhyjzZslF2iGo+LNEmkry
dyrrZJz+lIRGU/cj8oen6Upsl6P7M1fk1pS5F9zR+x6so70vBUdNwaPVma2pW1Pg3RVu/Brak4uK
+TPk1HL6BVz5JuWURNImR2yayQfurGnk/wACm9P1W/B+X+xpmlLWh6avCNL+1Gum3WR+56+ssvhD
WJalYS8ENbWlndwaL/8AFHoRhhyIX/TkXpP6WQUn3VkitO6rIlpRszOcPZIe+Tk//I03/wCJ6m3K
Oz6po9TVdyZq/wBpDQem1CLNSb4Rpy8NGpowi9kpGnfiOSe1/wC26brpa8s3ex6Sosl7Cr2LmUiW
ckWybIlvA6/fR+5S6Lu7SrtjaPt0ciH3FfsOXgSEyQ0REvJH4KXLFqUZ9hyj5McDc+Rws7S9RIcY
kYpvk04nqN4KXlHqjkykxarHG+7gclyzb/KZ5KtY8HaimenuWDbHhm6TNPa4p+49r5JXJZIvwiMU
7olrt0SjZqeyZLT9xQckkj0oZPUk1v5z4PR0f+Byly+S0u33I6ZtTHX4MI+k4ZhMyqPz8SI7HVex
Unx5ZKMWm/g2yefYSktyNNblGV+C4O/BNuVbjbuVEn5kNS4JqJB+UyEFLKRPVltv+pjhovd4wXsZ
9DIqS7fZiyopLj3HBYV0LX4oT05cKj1JpM7tqpYSNVx+h8EYbk22aUtyo1Nr+DdoijrcEVDi8l2m
OTcYR9l5PSjJLRjxZ3SUUlmvJKEaSukT1LjwepKcaRGCapEp6kkPvjti/cWVX3HtkpSfsPQlzwL1
JRaXyN9kV5bIaf7Oq2vLNKpxfavJLUU4pvnJpfs0XuW7n3HDS/iVij19V3ITTpoWjrP4VnqbtO/6
rP8Apf2Wf5ksOR689WEtR+7I6Oj3O8yLcoq8U2amlUZeE0XKcP0Y9urGMfuR0NH6Y+SWm9RRaXk0
9PTmpuvApReeRaP7TLu92Sn6umn7pj/Zv2V+npLmXuejrvdHhWLU9XSv3sl+y/sn1f1jnOe6T/c3
/sbn9x8fgTR+amxbFUbs9ONnqGxJluDbZwylFobyYOLKSwW4O/c23S/f07/Q/hOy6roppvb7GyGm
0b3p2yvSbHijfKO74Nq0pFVX3I6lXXg2+k19ilFxXuKZt9P/AAbfTavyzd5Mx3n8B2fS4oS9Ns/+
O7KWmz1Kv4K9Bm1abi2XJnqVuZjSwfTsFH093yfwR3cUb4tv4Nq0zdP/AARjGNpH8IrZtR6yefY+
hMrZhm9/UJJXR9Ju1JMUdNWkKT8Gx4R+XlFYSNj49x6kXlmBxkj1ovv+TY2qLbz02/s7x8lbk/sb
9Z2+sU3tvyRc5RbZ9UT+W/ufVExKB9UTdpyju8UVo6uDbLXwXqPc/k3QdSKjrl6897Nuhq7Y+wt+
vwbJa2Ds12VPXk4jlLl9H6M9jNs/2mW1+EbtfUSa9zOpp/5P4kP/APYctPVhfwxr1Xs9jdpy2SK1
dZyRt0dZxP8A5LPztRyPydT0/sL1tVyNsf2iSj7Hc7fv+DbpajgvgrU1pSj7G6D2v4K1NaUl7F6e
JfBWpqyPy9VxP/kzO79ok0Nw1HFs/wDkS/yP1Jub92drcX7o/wDkTM683EdYKWvNL7n/AMib/Uvc
79x7m5P5OOlrD9z+PP8AyW8y9zGrJfFlvLMakkvhmG79yvVmZ1Js4O2bh9juk5P56YbT+CvVn/ko
9j+LP/Jz/tVfuFaOC6FGi6Ko+k+kxE3bT6S9tFFqJT/eowfRkyq63RRwfSUy0Xtz0pGY5OClktnA
sFbS6NtH0jpGfw79r/Uo3Uzg4NkUzvjbMIo3KOPcujakb5LBwNUbq7TgeCortOMnsd0S66b3iPyY
o4KibnHBnpf8pwqKX4Ma81+p/wDImf8AyJ/5P/kT/wAn/wAif+T/AORqf5FLU1ZOH3HxhDj0UPJF
yre1ZS6o3TayXD8OG19j65f5PrkZlJ/cjpxXJGlnyz46cfi9SeIfJKKWL/AkLU1u2Jjn7GFg4/FU
csjq662x9vceppqnY+uIHqa+I+xSjRhY5/GnL6eTuSj8yZ2U1/kvbjn/ALE/9h+5va8G1YimbaVi
ltHaGkuC9qO6KFwNOI3WDC8CTWbwz3G6/fRbQ2ojvonJYMtHb9IntVji0hbHeS68G1o7eSM2jbVE
vctl0qMnavk9NaNq+TdPlok21fszbo6akbtVUbII3UcFC1dRdiFFYS4RBNYO1YjHCPTlGoWNND1K
/MbPR/5L9zZikRhp/SI9SS7S0qS4RYsYsexVCJsqjHJtiqflj0a80N1nknBu0jauUcCRGP7N7ZHk
jL9q7l5FtVL2Lijg/JntN2q7mfp+6UVLsfg+8ScpJjxgU4LCHjKRJT9ze+2JaWTfPk1YSdpHpx5s
lKja11jpwWRPUrc/DMUxQivgVruHpm03S+nwzwYWODfL6h70qRKUak/gba+kjprCiS1P1ZKKfAox
WGSkqk0jZJZsnKK+iOEKOpmGoalrKWGbpC0oR5HKVbkrJaMaw8lWv8G6HchP9owr/wAEf+nluUPB
P3bGXQpzj2e7NGMY8vyTa/lWB+r/AA5s1NyylyKeMi01HyOUmvU5HpXHank+r/g3w7oktPRyjfKT
S9kOGo238mnBPur8Hz/26/8Aui+xP7lNkX7oSRIjfsS2Fs7i4sXSBL9/+nRYsaWHRJZSNzrBFLii
WyWRKTFtJNOpCUpYbKTVikzkTu2ye4ioyuF8GeBNyW5EtnsONXYtTU4+R6elg9XVyX6afwfTGBSr
BtgqXgyQ1VyR3exe9b/YwIlORAb03tZ3y3fcQxJjUax0lF8MSj0f2E/LZL+01S58F+56WrLaju1V
IvSzEYmm5RbN7+kb89Y/b91Ej9jU01xE3+T04vlmfMTa+LIRjwomop8Q4JOPLNax6rIzf8xqV1Xq
LvvDHLTfcSlrd0UL0U1qR4J+s+Bz03UvcT1HvtkZ6mr2y4j0vyicZu4pYJar8cCnKcbq2OH7LOlJ
5NKc33Pklo6UtmnwQ3yq3yQenOMp/BXPuaUdNre34NW+KNCEOTWfwS/Z5280OW1X7n/TaT2yY/2j
U1pRT/5K3W/k1v7T4Jv3Q/uS+5u1FtgbpVGMeF7nqP8Ahp9qNW/Y/Z4Qrcma/wBiX7PPKukN1+p/
0ulab8i/aNSclf8AybVJX7N5Nf8AtJvwmen6G/5PV2bBat5lHz/uPnrFJ+DdXk3iTkYyP5FXNDj4
EYxgo/QpEbHkfj98l8HFC02q/wDI9xtCXufI7I7X5MksnyRsr46cspEb9xMg1J1Yr9iWrNccHp6M
clzRtYkvYwjeuRQXnAp6n1GjD+VDf/ibrf2M+Eci2fTZFy/lVkto9wqKng/JeSb1XbFp3kex5HPU
dxIqTpse15oi3LsslKTrFGpJeSCjl2aafsSdYO1EVJUylyLUn26a9yktuMD724+x25kd2CP2/dQp
Fe0TXP8AJFLkr/xoi5eXgi1/Sa8peWP7mtLwL5Zpmp1VfTfIlBPUXyfmR58D1EiWeRaUfc9VkWv6
TWeo20/ccUaspLA4x9xw9acK8WRlJ3k0/gnKf0XgeaIy1tWWz5ZqR/Z9S5s9bXm37WyXpu1MevPx
9JLTb/Nn/KP9s1fLwem5re/B6yy7IV4PVt+nZrfKJRfJOWoqtYJacPqNut4d5O9qKisRJbv4Kfav
cjKRJ6b7Zktd59iehe7W1MbUL9r1P8HpPUjvl/KLXjnJpryj1s7LNZLyjW9Vq1kX/Tr/AIHCa7iG
nfdVf9oz/wB9UockVKWT605exd7cC2SO/UVm9TjS+RR3I3bo2Ykj6k3Q035KUs0ZaX3K0pqTG7/f
O2Z1I/5HslbGRhPg3SmjfGSUTYpr/JLZJORFN0vkUVqR49yXenLxQk323yJepHd9x3O/sP7m56kf
tZ/EVfc3w4QouSgbnqwv7jhCSk/g79SK/U7taP8AkdTh/kqGEd+tH/I2pacmNQ+kj6ktsfdkdN6s
cG9SUmLfqpL2Ny1IuQ9PSr7m2T7X5LepFscNHC+C/wBp1Ni+So6yor1rE9CdpeCL1pqMvZm3RnGT
fseqtRplftE1E7NSM2blPFihrSpe7MakbJKD7T87Up+x3a6Nv7PNSbRs18QXkuWpGx+jqRkyMtV1
o3k9PR1E5R4JNvtLL/acSO3UTPy3ZfW67T6WeTycM4Z6mpHjJOMP4jwamprut/B6Wi8Vyb/2hd3g
5dn/AOi/y8Clrwf6EvTTW3mzJ6bxLyKGh9KFBruSHqRTjA8nEj1N7UfKNmsnuQ9kcjy1pilF48oS
cbkVoPZBeDZ+1RcpC9CDWcm307kbHo0ShHRdslPolrXKCH6Gn3EtXVfnCMl9EtVepBcIktPR2zfD
F+0a8t7T+k9LS0HCaVI/6h6l/wDibPSbnVWOWot0f6RrT0Gpe5s1dFzH+0yhcW72n/xmf/GPWWj2
+Im7UbUP6eq3L1Iew1pfs22T8i/aNSTk74PSh+z121Z/1EtSV+x6XoW1GrPUcXOH9Jt0/wBmpmyW
l6j+SX7V9Kf8iP8A42SUYfs+1tcj1dWbk34f+5k9O4y90d02/uVHUkkVJtnbKSPra+xjVkfxJX7m
ZyszKUvuYk0XKTaKi2n7ouUpP9/iTR/Gl/k7pOX36/xZV9zE5L9T+NOvuZk5fcw6P4sv8ndqyl+v
TGpL/Jmbf69Pqf8AkzNv9Tk5aP4kv8n1N/cw3/k/iT/yfVL/ACcmJyX6mZyf69eWv1OWeT6n/k56
cv8Az1u3/k89M9cl9K/Bkx146XXXJx+BMWnL9muvKP8A4rP/AIzP/jM/+Kz/AOKzZHQ2fJfn8HBD
UiuGfnyWm+KG46iHp6WNP8C046SnH3Mfs0T/AOOhw9NQiW/x4/Hj9/f+90hNox9QmzsRckVwWNWu
mCqwcZHFtI7cjx/t7yf/AN/+28/9rv8A2KjA02bL4E2rJNYOcFEpDj7CLrpcRKQ6H/8Ak7n/ALbF
DQ2R2kEV0sa8jl7sUl7G2T4PuNfIhj/7t8//AJFhP2ElLDHKrL9unNkXWbNo2+BJCRNkc4okvk9R
4RKEX/8AiCv9u7oP/wBTa4OjCO9UjsRvlA/h2fwzdt/5NvH6m5cm14HqKO5s2bWh3z/+Ba/7ln/s
N/8AZV22fTR9JaRwVtL2H0l7S9pt24L2jhRdf6yv9RX/AHn4/ccfuef9/wAF7m6spGxce5T+ro20
JIb8meBJ8ixg3odIlqLwU3Zuol/t/wB/9Tz/APgOH3P/AF6JoyTrkTfv0fuX4Exx4ZqEui+xO/fp
x/2Sv9h8/wCn5/1uP+1V/wB0gznNDZRngwKa8MZSlUSMpcjQ4p9rK+B/JY03TG/9w15/02P9ze/+
vVytDudzHJzqL9xrTkfmzpCjvpe5tWsi/VtnbOyt9yPUbwbd1s3N4NsZqUvg+rt/0XPTP+++f92P
ruoovJgyjB5PJgpm6imWimv98O/36s+3+1s/6Tn9w+iE6HuWRyfFlQS4O5CTRwKO0wcG5Kx3Evw2
dnd8m5IlH260cFUWzCK2m6jCOC6KODCK8l0YiZLopI7jCwVtZuaMI4LrBRlH0lUcYODKLoqsmUYR
VFuJhdLrBVHBhFUXRhWcF0VWTKMI4LcaKoyi9rKSMxMRwbayXtZUVkyi6wbVFsuSLUCqyXKNGImY
s3bKRSWS5I+jHubatl7TGmbXHJbiVGNszGjdGGPc27XZclX6HbGynHJucKibYxtndGi1DBt22/gu
UcHbFs2tZLembY6bfyLcuRTUe02xVvguaLjG17m2sm5w2rkqEbO43KPabErkXNHbp4NldxcoUjsi
d65N+2omyMbZc0XGODZWTdKNIeyIlKOWblCv0NsPq4O7/wCjco4+xtlz/va+kRYGJ3SF5G6o+BDm
bF0q8kvsMUb7fY/Ql1iJLLLdIqKM5ZeCqO7m+DwjGRuXBwkO8v4PZGEZaElhX03NocYo9y20iond
li4R25Lmjwh+WZxE4pGcsSSpWJVXybmyoROMm5v/AIKgjKyJtr/B2RLnHJ7foSUVbG2sWcKJSVsV
RpCtUW1bKhDBTj+pulk/Kgd0BNlacD8yJ3f/AENQhkc5x/QpqhpQ/UUtnahJqsF+nufyRWnCoplO
Jv2NlaWmVKGTc438FaWmkxucMmYscdPTr2JT1IYKcf8AA4x0hTen2IUdhjRV+7OyHYiMJQN/o2/k
XpQ+44z06b5N/pWxw04JPgfqQz7ib07JacdNRxjBKc9PDfsU9OzbHSUUepsuBtemjs0lH5FOMe0j
pvTXtRvWnGxLTS+TZOETf6abHpwitxL1IrPk3S00yWmopYpD1ZxTNsoqkenGKUfg9drt9jbKKa9j
tjGK+Deq2WLTlFew5wgl8kdtUuRaTSPU9OO73PTVfLJKWUzdOEbHpR/Qeo6aO+MX9xwjXGD1tTC6
4/cr/u1f9uef3EX8iHQo+RSY0mWhdFqUMp3TJMf+S/kol1/Ni2zclUT6rLnH9TdpcH1ltbkVoozN
Iz3o2JPcW5KJ9W77G3Y1ITtRPrv7H5kC49q+T+IrLnGy9NUjOpGzK3H5cTM4r9T+s2Q03uMyUfuX
e5fB6ezuLbUfuYmmKL0rkxS+g/iL9DuhvLgtq+T+JH/I3KO9D9PT2L3O7Uiv1G/qNmnpV8luaj+p
uvcemtDPuKTko/ctTT+woPR3tiniC+T+In9jOnvN7j6ZXqxscnHefw/TRT1Y/axy+oWnHQ2r3O7U
jH9TcnvPRjo38m6epGH3ZcZbiOlHS32R1JNQfOTGqpfYX5am3werOPpfc2+sm/ZDlGO4cp6XpxXk
2vWj9hzit1G30tun/Ud+tFfqb49yPRhpJpOmxOepGH3HKEt9C0I6KlZHU1JKDazZ2am/7ChDTUm+
LFq66Wk/k9OGqpS+ByUbHPWh6aPT/wCo7vZD1FHdXud2ko6fuhR1P2iMb8G+HcPShpx9NcyN2pqq
Jv03vR/02lpxl8kZ6s4wdZsfo6u9L2FpQUckdX9oahIelpa+5+UXCKy8Wep+0VGz/p/+o/M9iU40
68jlq7fSXsKE9fu9ketDOLtkoLb6aeS9bV2WetpT3+1n/TabiLU19VRrkb0tTel7kNHTnFW/JHV/
aNRbuXQ9PT1roj6c4rcx6v7TqR//AKH/AE61XKRLV09RKh6utqx2e1i0J635j8I9XT1EsXljUtaK
hF5F62tW7wj1NHU543MlpS1PUiuK/Bf+830WjJ0vc3L2Kb/wdjXA4yfk9xFtdJCZyjHBvljyenp8
Dl1UlmvAtNaSh9jc1uKnHajbDT/wbmr+Cth2afd7m/8A4NmyvkclDe37nmNeDb6d/J6u3dL2ZSjs
GvT3/LFqyj+jFBQ2r4G/rfyZhtrwenDS2/Y3yW74Nvp7TatLPujfn7Gz0y46W5/JntNnpL7nq7FO
XybfT9P5TKUdwtWUVjwbFHYl7H/7z7nfg9NacUvdDn9Tfg2yjtRshprije5foenspe5cIKRub25u
kbKPUSuRT7ClFSFrNdyFp1tHXd9y9Q9FRpD1Ltv3Ns6jE26fHB6rnn2PTdbStNYFOUq+D01W0erG
txWpPb9hRjn5Fr2nM2SaS+CSg7v3FPVeVk9JSSib1O5/Jt1ZYXselpyW09X1O7/g9PUmtnwVpSwb
9TVafOD0vU7Rz051N8srV1bR6enq9vB6z1O/3Nmpq9vsitDVaXyLU1dTdJGz1qiPU09ZqZWtq7kb
NPWcYHq+q3qe7Ns9e4+xWjrbTfr6jnM2f9Q9g56Oo4zfkS1tZy+xs09eonqqff7lan7Q9vsbdDXc
Eb9TU3T9zY9d7DdparhJ+RetrvUo2Q/aGo+x6nqP1P6hw1f2iUosrR13BCnrarlO7THD/qJbX4G9
LVcJe5+dqy1Puenp/tEow4o3x1Wp/wBRWrrSa9jbo6z017DnOcpu+Tb/ANRPabtLWcGXqa0p/c2r
9okom5aj9T+oqetKa+TZDWlFfB6kpuc/dlPXlt9h+lqODF6uo9R/JUdecV7GW3+6v8b/ANRf/YL/
AO1+/wCH5NsJy2nLUvc75NotYZamzGqzM2Zk2UpszyUtTtRcnbGlqPb7Hc7/AA8fu8/6PKx14/c4
/wBJ7fv+f/xWi3j7ihyX5NrQjlGa6cYO1DdcFG6VIbjx+CkcIrBaQ0cfii3wYH+4z+4SRvlGsHg+
BO0VaF24Nw9M3Yuhrqko4Zmkdq6Ui3Gv+++377kr/cdfu1+/RFjSFMVs3eRxXImy02bZssyNIv2F
F5TNxJLqtrrJfwW3g/Q3bT6TKN1f5PpHg2Hai5YEkuRNwOEh9UkbnFn0lpF7S9haQ0+sZyzeStPt
ZWrz8mktPjyJ+aHvbasivNkh/cf2H0ijdWTbD6UPesjN02Oq3GP+5XfV/uH+DP8Aq3/3HH7uv3mf
+yxHR8kbGOQkfImj9Cmy+kT5ox1j9+jtCjDgUnOkVKakWuSpPAtjoluzgtYZHe7G+SL+S9J19z/9
Jdv4NsY/8dVuIuOMD0pPsN9ZKnnJFRfLN0uSXWP2GV5IXjJEaSp+5u8D+w/Yf9pLppv56Scukvuf
/o8qN37RJv8A7jf7vH41/wDgdRk8mBfLNw4WX462zAmnmyzAmhqTz7D6x9j9By8CspMbb8mPYp+/
SWfB+ouji/DKRe3/ACYr8G34HqFfBfuyP36Pqk2foXJY9zShDmyn7Dn02p3g3Vgp87SXSL9mKEZW
Jq3k734wOi9XI8R3fA//AMS1/wBk3LkqcPUfuLVr9D0tv6nqx5PTUNpXo2Z0L/Q7dKh9ls3tUbdj
+5csG1aXd/UOT/ApShvRt/6docVDadvJWrFzPy4OJtUafyOThKV+xw0jYoS3G9/8ij6Lv3Gowp+5
vXHkW7SbZ+XpOLG5eeu5clamm5sxoOJULSO5WRw6PTjB/ccvfqnF0bdXTcxrT0ZJnq60XNlPTf2O
KXsbos2amk5mNGisqPgvrceBR9OVofMF89PytRwL1NTd/sjH/csf9zz/AK5XESrBu2lUXKJVGYmI
nBwcHBwcGetClRto30V5/dfSfSJG6vAom6ikLDsuv3FJGf3ijGJ3Kv3XHS6dG9/hUYG6S4/1HqVt
ieS8s7Y1H3Ld39xvL+DP+kv9xf7tf71ieG0RlP6bNkRS2lDXg7Ud1X7HCOD6eihJJFpDjXXu4NsT
dtwbX4RuXDEcdbop9VDYpX5N+1Di4pCx5OPBLHkWPB6s0ekoL7lyY660i8l0VQ5Sy/A6RXWvInRm
JxgqKMo9+mVX6D/Bg3bS6NtCe2ilEtxFStiU4bY9H+BTlp/8H0NRO1Wzc4YODbRuqikjuLUcG1cl
yRuUWkj06uRvadD60lbFKuT4KfItJcm/mW22L1V+WmLT/Zk7WEhKX0EnNcI9KHKEtL6GyHq5bVsk
l+G/wZ/eL/WL95j/ALdf/cERG/gd+4kJkkihbjswISZaGR+/R/gUKfSvFm6UbK9EbpD01HuN8o2Y
VGOsSJymxYxZ+gyP26akkhpSdDTd9e7TcvsJLS2focDWrByzg7FSGpx3Mc4qr6p6mYiShtikLS9P
uN1G+Ubkem9PJbnGK9hNfQiKWmPH4I9u/wCER/I2x+SnFJkY0JKKSotQjY5bUetqrnhHowXHR9V7
EYLTowqwbpcJm5aar2NvpbfuQlV5PZGFFX7G9xyJRwvg3VG/c7khRSVDwnknih9LN81fkUtm5ex+
Yo6S+StFqUvLR6sY3R6cYbbVG6Ts3ftMtpH0mnIfp8PkrXeLyyMYTi2hvR8rBPdz/ruf9r3+6x/o
Of3sVfkpdFL2NljY0dpcijchbhkTI89UKdHp2XEf2KhBNGY0d31dX1gfoP7iMewmR+EUuTbGOGzu
+ol13Un9yMIRsvy0X4sv4HS5LfVH6EMeSN+3Se1Wbs0U+SIqGuqc15L0lkuf1F/In8Ec+R/Y/Qm3
79JfggIr5KRZpjNPPkZ+hyX8CY34smSNumv1N0uD9ClnBUYUjdLkWldZN2G0j0tPuYpz9rI3F4NT
+0csxXwQUYurNNP+k/8Av/S1/okNfP8AtLP/AGJSizbqT2/c7J7n7m16tTFKMuCnqpslqT1kr4M/
tCO3WQ36iSKjK0d2pR2vcbtbVS+GOGjLHwW31i5cCjHVjurhF+pUBfmKUvgcXOMEbv8AqIDjDbMc
pSSyOMZpuvB3asV9x7ZX1uc1BL3Ni1419x6nrw/yYlaTO/VjD7s3evD/ACbNKVmyf+Wb3rRwNb8D
a46qD7fuKcteH+Rr1YqP3PypWKDx9zfPVhIagsD6If2N+pJKRs03bQlKexfJulrQf6jWm4tl3hsX
50W/Yb9S2PZ5ODCLlH/B+dqpfDNmnNbfcUvVVsSWqpY8EV9EE+RJaibo2z1FH7m6OopyZ36qJPSV
x9+nDE5qkK5q2O9S6Ht4lK7F6uujdCSE96WmhbNRTdCc3sghRhqIr1FuIx407NvqptI/Ml6cB6kd
VSmfm66v+kctHES9dpP5PT0pJ/YSfbH3PzddNjenONj24gepFZPT20vuLWq/uJftM1D4Ny1I2el+
yZXuV+1SwfWvuOH7I9zHOf8A3LP+o5/2rZT6V05ZWTyfJl30zf4cPryz6pf5OX+Dnr5Pql/k+uX+
enLOWcnJ9cv8/i5f+Tl/5PJ9VI+pv9fwQj8iV9zXA5udP7jMNn1P/JzfS1Jr9Tlv7l/tMdzOGv0P
P+Bx0o2/lG5Xk8/g5fW+TZKHd5Ppf+Dhr9Bw0tOvk89fJ5/BwcdMrpwcHBnrwcfi4/7Kvw5/3ukb
pLBt019zvVy8CaXkzEaccm7aYQsGEd0TtVUfmXuMI4/BgyX4KLo46cdeDg4MFeS5I4OC6KSODjpw
YXS6K8mUXRwzg4OC0nH5O3WkXqakmXRRlGFfTjBSVmY0cWVWTKMRbKo4MIyjBwcUcHBwUolHBwcG
EU+ThnBnBxgryZMK+nFIwZVH0nBwfS+nGDjccH0ujjJlUbkmUZi19zCZR9LOLMrPsfTgrlmYtfcx
Fv7I+lmYNGIt/ocUXtf3MJv7H0s+h/4ODMWOtOT6fw2l7lKDbMxL9NpFKLsppo7YtlNZL2Uvk7Y2
d0aL2OvsNKNndBxRjTlXvR3f7IX/AHJV7Es8G2TFJoaXRFpncZLQx0d2cH2/BumxVEdm5yqJ2xHK
eBex2qx3gSjg/qLpJFROUy6SRSyy5cipGf8AguVL4O1Dbo9onbGxuVG1YXuUu4uSSFGJ/Uy2kjbD
LO76i+EYXgbmKke7HuxEwv8AI+MHtGztQ3Kr9hKGF7iSVsuVI2acSnyXKkioHcrYuFEW2NsbmvIq
qI/5n9jioi20h7u6VC2xqBUUXOV/Aowjg+nu9zfqNV7G3SWTuXcbpUkflxPzInKSO1bn9jujgxUB
/wA8kZhULO1bTu7mJQ09sEJbawb5vc/ZGzR08WK4VL3N85Y9kKOlp5Z+Zp9wm32/Y7NO2OWrp5Pb
9CSUN/3HKWl2XwUkoWPt3yIv06gJbNuKNzj6jIw09PsTz8iThTPUl3+aoUNDR59itTS7n5PUeUvB
t0tBbuMEvW0c/In9KXihx09FNoc9XSxZVbPOCUY6dv5PUel2CXp+n9h9m+/LLjpVBCjLSrFHqenu
+4o6OjUfg2amjUvJ6rju+DZ+z6CbfsSjq6OX7ik4foOOlox3ccDlq6V58oXbVexJaeity4Hq6kdi
f+6l+LP4a/An4PmhuiLNrY2fcx4R6dYI2Np0U+iS5Mjz1W7gjp6cZbjLo7rZ6avcfVtHb3L4Nvdf
sKu1H139jvUi9PEfdn1p/Y/MsvR4MzRepcj8qz60jv7l8G3Tvd7GZJDuW5fBszvFnaPvTXwd1pna
6XyfWj8zcXpYj7s+tH5qb+T8o+uP+S59xWjdmZRX3Zcnuj8GzT+ou1H7juVr4NjvexSXaj6l+glN
Pcy4KkfUi9ZP7l6C2w+TMkXqrdQ/Rj+pmcV+pc+9fBs0oPcZaX3Lfcvg9OOl+YKWEh9yZslpdwpL
tR/Ei/sz83Tv9Dfpx2RK9SN/cctSG6vJ+XDavczOK/Uua3ocdHS215LlNR/U3PvR6Wn+z93uJuSj
92OV7l8Hpf8ATtzFP6fuOpqVex6b/Z3KX2FqbfTT8M/iRb9kXPR3m5afpL5KerG/uOUoepR2aD0l
8oqWpFfDZureenpfs9f+VHdqRj92bl3npQ/Z7ldG6UlD7sbjNSPR9DdMjqTrSO3VjP7MUfR3Xwep
qQ9IpasW/ZMcvS3xs3vS9OPubfWhu9rySmob1FWzGhth7lS1YL7s9SC3j0dP9nVJ02XqakYfdm/T
e/2H+zx/Z1uQp6rWk/Nsb09T1UvYjo+hFt8C1datJtWenp6yn8I7dHdF+56urFafsel66lP2Q9SE
FOKN+ppqEPg9OWut/seppLdi2bPRjGPkXq6vpuR6ui93sShq/wAvCX/ds/6vP+tx+7UoChN97xRv
dIb9hJMe4uNYNpbRFIa8jXTiznuHnH4MacZ/Jf0np+kvub/RU2ZWz7G1ae75Ytb07fszatL0/wC0
d6fqX7ik9LbXij0o6O1e5ua9T4Klp7fsbI6Ff+Rvpy/8Ta9FQ+w1HRTfub5X9kbFo18s3LRTYnW1
exsekvuPU9Fz/Q7I+minDe/kWs9O6/lZs09L018GYPVl8ilLTrb/ACnp6f7PSN8oufwVs2fY2Q0M
/wBR6knKv6T01p7cVZS0FJ+4pNNfB6fofqPU9FakhUths9G/lnrT0dz/AKTbGHpx+Bp6W/7i156K
x4NmnpemvguV6rLnp7a8D04fs9fKHOScm/5TZ6WxG2Ogm/6je7S/pPT9FRN0dCM2Z7Een6O75Y9b
0VJv3Etnpx+Db6e/7n/US0+7+k9OOnsM6XqP5FKcEorwelHSUfsPUcN/wxRlpqCPShpJfJ60m3/4
np+moIqGlFv3N8m41/LZ6Xpqvcc46e6TMrb+p6S07/8AI/6japansbH2fY2KPqfIteaW5eD09qil
5Q5RW9v3E9VUl4R6MYJR/qPW+p/0tmzUSUPg2aaTR6s33HpukiXox+r3FKcttex6cdqXyPWi9+oy
ptr7G3Sr9T/qJSW82NpR+BvTdnq60rkuBaKaUaoeppzufyL158ex6elJKI9d6jlqs9PU1e34Nuhq
YYtTU1W2naPT9TsqsD1NCfe/LPz9Zv7Hp6WrceMj11P833HHW1u3zRs/ZtRxgLW1NRy1Eem9aoey
L0NXPybtbWcvYWkteoI9WOo/V/qNutrb4+x6ejrOET1tTWctReRwl+1PYP8A6fW2Wb9fXlJnpx/a
HGHFHdLc/wDtd/8Aa+f9Zj9wnBuMvdH5k5Sifl6kkfmOyoTa+xjVkY1JH8Rl72pH5k3JHY3FnfJy
PyZ7WXqycv3mP9Nf7/n/ALPz+/v/AFnJj/XV1X/cq/1d/uX1Vn1K/Yy0hbcoyik0cxKbiJKjCKos
ow7+3+h5/wBrfH7muOq//AF/ukmJx5KFp9GYeEJDl4FG7a6bkNEtmMijL2Gy/wB1X/Y8/wCq+PwX
+Ov31Ff6Bf63H+mf72/+98/vfnpEiSYqFuGomeBMcEbn7mPY5NxMQzH+q+TP+xuf9Xz+6z/3Ln8a
/wC28/hrpz+J9E+aIwT/AMm5ZLswUIUTdQqH9hr5P0Gjc8Dgn+PP+1r/ANBX+hr/ALpn/ZL6KUHw
ek9JbfcckuT8yO1j2x3G96dmdFH8Ev0lg2y09qPUjC/gqUNh6qV/DNmzYXf+0q/Fz+NdOf8A8I2/
3apF7BraXtODgv08n0F7DdtKoctptouqOMfg+mz6KMIfVJI3bcjVfuMDlQ17fhSSNz/ccWbnF0Wi
mjETP+n+PwUbs19jP4l/q764/f3+LH+g9/8AUYM/99v/AE8V7m5+DZEzyZN1G2LLbyf+Il03JDQ5
r/Aoy5JSr8EdPwXHkfqHYsl5PJHt/Vjk+STUSmuvAjycCswiUkvwpvlMcVk4OOmV+CO7FEVCKqvY
e6kNrgaeJNGCoo7kYRT5LODP4LUemUdsbPpLdm2MW39jJ7I2eS6o4Ko4OCmhbIbh+qqwS+D8tY+x
9JbX/bcf9i5/2rj9/E/TonFi3YQ0jPLfSXubrFIpsdDXSQ31iVN7R7HuO5YFWkpH0KP6CfmyxxwX
Ru2J4PTWlRu+BycVI9P0Mm+kej6Fv3N9E9OOmvwIUfSz7j2xpi3x3CnsVex6MdNInPz+BTlJH6DW
nqdopanckKtLaYWB9ieDCqi9ndRFtUvYSjBH0JEpYvrGMpKJUYxm65Nno/rRlpSFPapSK9LH2MpI
nqNKWTY9C38De6On8MepicCvRTLUNiI9ikLVcU/ND01pKPgSSzJnqaiTfyPYqSNsnUWVpxUnXJte
lGK9x7ppTHXH+kv/AE3P4+f/AMApsXcNlEfBybzI1GTSLfPSlKlZl+BikSW7kfVdHuyKj8qVFbxP
Wleeifg5KRdeSP2KHLwJP2GJfBKVOimX1QzPuRH9x+w+vkr/AMSQj9BjbfKLRcvYVPBegrZtUKP/
ANI46pQsXqJ7Giks/J6iQvca0lgvUVRHb8HarL7khxbyvctdIoX2JX7mn9xpew7xguOS5xew27c/
Jvis/BXI3prBUv8Anoo6Z39FGCtnqTW1fb/Sr8D68/jz/vvn96mnj2Nupcpj1KcYmyDdlzboq2KO
6RalJlQkyoztinfbZ6a1HdDnLMWbdGTc6N278G7W1HGXsbdPV3Mfq620UtOfaVq/tFM/L1ouQs4N
uprqLNy/aMn5Mk0f/pGvHS+Dcv2lGzQmmbdbVWmi1+0pmzQnvZ6nJWvqx0yT09WM37Mc656Y6Xqf
tCTP/lRoU9KVxFCeulL2JTlqqMTbDVTk/wAEZa+soP2H/wDpMaH6UtyI7nUbIr/qY7iTWupyO2Tc
C9XWipexs0JKX2M8PyyL1P2mN+xujrRs2xrb1UnHf8MrWnp6dcI3L9oh+hs0pX8kY6s1pR+S3rxY
46M1OXwVqyjpR9zdL9ojIa0Zxl8Dcqin5Ll+0RY9msm/YWo3UUxR9dN1wSnrauxWL05+oz8/XUX7
CjpftEa8lrWjqzK1tSOmWv2hHp/s7Ur/AJi2SjPUUXR+S8dH62pT+TbpZS89N+vNR+Wenpanqv8A
qMf634/2Jz/pl/3jB8nH4M/uOOvB9P69ODgwdx//AHPk4/Dx0z05/BfTH4Mnn8Hkwf8A9Pwefxcv
/Jgycvpnrngx/wDZ7/fpfTH4OOmMdODHTJjrhfvvb/Q/H7z4Mf8AYq/7cvwc/j9v9bj8L/cX/wB7
y/3OP+1X1x/2Vfh5/wCx8/7k5/7hx++z+8z+9+P32Of3rM/78z+6yc/9ys5/0HH6/wDZPj8T/cv9
4xe/+1fj/sr/ANOv9I/3i/7C/wDRr/QP/bq6L/Uv9yvwf//EACkQAAMAAgICAwEBAQADAQEBAQAB
ESExQVFhcRCBkaGxwdHh8CDxMGD/2gAIAQEAAT8hcHcoamxoqFv0xNyHYOM0hVptSeR7Q7shwZE2
PENFe7JfKE0DGQecDqWWN6ujBspZK2M2xmWhtjL0M9YK3l2Z0U9BW3oc0LRchtRO3ZnNRDrkhJOD
SajQq0xT4OAVIUN2GZqYNELDJVqwRoizqWh/cX7CRB0kKzDNEmm9Y+GSzJQfQYt8mTeDBoQuDIIX
EY4sIbnAsi5gg1cjSRCdHUEvtDdaMqDTj9EiJ21k3I4MBLVgohfJlzSEsIbQTDcVyx8XiBZE+SKY
3A0ILLLXobjgqzg2PZYSOMJw0bla0XFkplLkb/BPvRRjRgDCyyqfQEuRTYsbgktMUr0dgiylyJFk
xVJWbTg0MeQma4GXQ3zMzyNcC9jWZTdNkMIowceRDYY9YlG3RkuBuibQ0n2UaJBkkFgblyJGSmLb
yPT6L30PhBuxoWpsTZSzsQ/scojAN0JtxjZZLfBlkryZmAeLR+IqSiha0i/DIbJ/DSjcRhjbWs3k
wY1m8maybLofdEo3xChuZtFGiqUWfx7NlCiJoda+Ca0cPAkXk4m0G/gU4KJ5GbRiaD9ZxgVwYRZl
rgkbo0Flv4tkwHWO0fRhvaLDo3XkenCK7HWTcr7MG6KhvLmWLRlMbrgbN3gTBmbLyUgzd6LSfQxk
PlleQlaOmPdFdol8IypkC4jBNSYFtqCzknnRnyHBCpjR6MfYWPI4KGc/RONrNdC0HPsVpDmehi3o
sziLh8VyO0XKEw2hzAjlD4JxBx/B6RaOFDSvJw4sDuixXAmm7sapBU0NfEPwN0+xk18L0Pk2LiFY
Im+xQN5I3gkJJuQn0JWE8lB+DGm+yXyUMTLuRvBvByTg9hK8EW8CxEtnYnFRq3s7CXz9Dw2RR6Hr
1IOXxsRC4FinwKvjrkRwLTlGkfZif0CS4MYuVFBHIWEsOcHGh2bujdYExSDk6Yrfww5Y1mxonnZx
y070SIbeB1p6EPAS3yIfYq5Y1TEuwTyLlwJ2KTOShuoVO3HxztKbHcyJMqZMqJOSOp5ROSeRfI7O
B2qNX4CSOA8CHzgQ1OAxdOGJz0U8Qcv8JCRXIrJbOU4JYYGJQ3rolFaNa8kP0RBp2YXMMSLmE8iI
mGrpOCHgiRDkBJmxiSyMJPREWci2hK9iZsw5E7kUuSTtKFGNE9/E+BigWZGRDG4lMdKWECqckM0r
yNN9E7MikS8jQ3kklkaK5HqNeQ+VMccCG10RhE0SvLEMjsi7Gs2RyMEMSS10xrBQglg/Ix2/hi4S
4cESGNQ8cYRDMa0bukNeBwF0ZpzWYdow8sg9jLQ3nsghclQWHhfHs2UcolN8GgaxK5ITzkssGC2a
XRMLJCW6XwiWWia8/Ykh3DWslumHOyMrg98CVtkdvx8KOxPZhkW6LDZEJXI+w7lKBq9mh9YTyEn2
M0eRTFMzJzUWy07BNEpKrTK1SCVp0SrnA9dGgbOTUJDq9jWOWIZyY1gMBqmNe4UexLyGlrZRRiZr
qEie8fGa5Ed5ORBeSk6G9ZcY0DR8iRLyJ2nkSNCA0ehSwJE/Irfv4HLYkT1R+Ylnlmzk3f8A+AQs
2HKFUXgSGwwFmhtCOxKKDQG4btmCfHYySNiX6WV2N38FvyLUf+QPFDANqJ+wnG0fk4uBlmEj4Ekb
lsgoYiDItQSmcH5zBgqim/gv2+NJM+GNjH3nn+B9olnnG8855iPJryYdllsbdsgNylOpljajd8id
F9jZljd8ldnmKK7PYovkrKKyuys9iuyuyvv4UUUrsvsrsrsbOSyixu+Suy+yvgbkVldlyFrkrsrs
8hRfJa5L7LfI3KUtclFdldllFFllt7K+xOufgbuS+y3yUX2WVaVbTzFSUrsbUoUJS78EuSxu5Eg8
gvipRs2fHZRqYnYbGfwr0ZoTIOh2KSGTM5n4DHu//AxuEyK+j8PgooqkuTQhYMiATLkbtjeDdsrG
zZ5hI5FIjmjS2ec+/wCNlVgSK/g81F3lstiYoyMkDzF85JMsUKSMxQtDb2VlMdXgq7MsrSwVlLkr
4ZjrM8/PgNfFdP5mB1fCVf8A/nz/AP4z9Gjj/wDK/wDwhO+ME+GvEqNs+PiCdwSb+E7eEN9lPi8Y
NuyIJUw2iQgm6Z/Q9hT4TPSbGnkQTPSNA4x8qfGhZm3F8JNmgd9DDCMVOLJkga00bhZT/wARsPxI
Rm9C4S9Fv/CbdX0JzDM0Atur6JP/APnF89koIrWxYHvwmzJkYQqMHU9odNLYY9qzKanXG7BQp2Bz
MHRVtDWgWYZZZu1BvAphN8JDPRKzFZNTyHsISgqho4gGu8QzQkzJiUK5gXjJLec5ILgOwBYdegqY
atBLjjnFwPaa0Jich0oVgkbUDSVCqp7LLifoYVwEO4kxnoc8BaBWR7sUOiFJZHmWBjZrOrbglcGt
MeWmvBcopWQxaLaocAD5GBooY+BKiTFFpfYpiNXgeFBa1oNzwixoWxEYGtk2sMQBNhLaotzyDhjL
OUIxMq8Dqg1Plqf/ALkIT4gkMS8iZlDu0dCmqJeBvSGlRxp8JX4a8Qn6PJASXkdlZyLxOuEEVJwo
yWNmyGSJBkTLhjxF8BUqwJa4Pw5aUxBvRlQzQECy9Spo4cin2Cc28l2uE8wwZucwvkWZiTwObJwP
MFBhFTEIFrIwMPImsVdmjXtgyGiY8JBxLI6uT4aQ7sohdSxRRYja5WSkEr64G3cJsY0KtvYta73R
CBbqhPePpkexekL7UdjA4+w2bgNDIlrDFOt8lbGya5dofCZURBr+PIvgtcE//wBZ/wD5z/8Ac+Zi
k+YT5hL8Qn/4nw18Qan/AOn/APqE+Z8QmPmCZ/DifCwJ8Q0IQRMlFmRG+Suouej2Qzo45FZwkOdl
SvkQ6YVQnTAb9RH+vDbuGNxTSmsTpXc9Bfa9hFZR/wCisaxScaHwGAxM/RpFR5weRbgDZpO/RBLI
yWZEJhPRdkaXAjvtyIFxqYjnKQA1KE3DUyyYuwxLQjZDxScJZ6NcqC5U+CLIrwcFl4EOX4UyrwKc
rnQ6qrszwVKKmuLhCc3MoiryJGkldRH5oTRSNjlvkQJnb5FiMrktiN4CWLZUifLDEcPQxis5WZGd
NNCoWaYjbkOSGFYEiGoOK/8ABl9GRRZkiJPKNgBcDN5BPG4LssEMSPloTM8D2jkwRIqVXbZsf32V
FlhCFSXOBTHMRJ7LKOFByIsVvF6FQeCDkGbOGQWzkmCVicXY3qsplGWoyizPRdRCJvYcCgMwRppW
ORz84MtYmy+EmQym1gsEvhLjsVcmJqWdnyJemwq6JVRpwPwIPQZF+WRRWbeBomuxnKMf3KLyB3cZ
8jHvJwI9g8bJLDgGZ9F4GkTAwru0NB/MC0VixC1GccRP+BYJEiiyVe4QGh5M4bfwbf8AwIjreAxh
YzoiebdLQ4yG1BVtaxRshZfHQ+2jkh/d08DApKpCYijWIO1tjSLlBmhrVNKP2H+O62T0DFCS0WjL
lb7G5HETtNXCuDUlFrOuYWbXJHKp8sbYOdMb2UGcE+ZDXw/QkQeINeTgSpIQidI4SkmxKrHw0ciw
LkagvhKNRmC/HA5Ph5Eps36GYQ3HoWx7Y+eRbJkmRrJM5Gh7FhEvgehVURokF+jkWzVi5PscCPoW
Kh/CY6JkWEWEGwsi8FRdPQSxk50cMTrJk+jBlHdsjE34IhwEKUnwDqOMoMPBBitJ8mHo0JeihzM8
EVNjZPOGUehmw1wM7wLDycgNIWKbHlDZSEICjwr2PSQ2hKasCMfCHMAWwlH2LlTvNKsMInwZs8mO
3l9DNT0ZLMjURyKp7Ml7Qdy+iYjJ5fYQ3MZwNYuUZdsSsuRCJoIg5ux5TA3JIKc5Ux7SJR3sR16U
Gslx7kHhRCvwxKfgVUtBPQCU8GQ6EyeRHNBd00EksmsXVLFErEEV8rBCNs2BWhKBoQyM7YsxVaTF
BbI79exQgqVbciZVwLf4Lo0xV3xZNwGt76EdgmJtJguhmvUEe4RB57Rk0Zmx4HeCREwJG3SX47Vk
TqkrULFvQZ1MR0iRwSCwStUhxYdjWmiLyuTMONjWYCfZwhJi8BkXIbLrJUj1szM2GRXhjers9kpC
3BXiyY0MfG7bdjsOmYj6QiuOZweqM2L8S1hYxPw876cQLkslN7KIUlDW6NPo6CsPBzI4oiqVQQpb
PtWSk2F/2Em2sYY03a0zD8sxDO8klHjTHSOlY9VwKj0IQDjKE9i7PtYBlgmfIRh+vQ06zJ/ZEeDE
EehoqghLsKK8ozBiwinDI4OVwieAllMVB3Jf2ZeTOHgM5WFRMnJho2JNjV+DJ5GcHHY0L53wMWBI
mPJJwb0QJRn/AEeGQuVDplrBJs2ILYq+CZNqPAW9CX6NR2GWyEx4ppGGcjyQ42LkNiDRkx/hZwPs
dkI6JFj0b4GJiGb9CBLgeFg7DVgzn6EP0JLQ1gdEbGFGjemCNqFIE4EHJkLexbeMCvETNImPNNPx
DM3w0yGMjWdSA6pwXKzgWBydjPmN2v6NFZnRc2ajufnA6nkwU8ckPFn4qYP3CHNLOhza0JdM1yMn
1ojAXYyrOJ88FQArJe6OXJ4IKLH4eHpkpqLG2o0I0XlnSHKyKkCnovQ1cD/KZFMHyJaLkdQLy7pn
MvEstsqrpBT4RMTDHVNmOfgOCNdD2iY9PQVE9IeEaMhky2Zn4BqVs+B1RkKlcLZTS46KrgYBuOWC
UK5DOk4OmbMLEELI6NR9hS24Nx1Mt4cBhTvotGyaZCWNcjqyEnYmP0Bhsg1GRkScHwZBbewgeAgC
1/wS+cnZZFZl+WoibDLb46EZ4ejVRJj9nZH0IpYNjwWobQlWiaCxcCwEvqEpZtDXNImDQXHaC1iO
BFaEh1QbYGqIkbZyjfsB1A47zEHhr8wt4ElpilG5UCDSI0CMdQRq5OtDqPzoxqJbgyGfQY2UvZYi
S4DsClME8b5Ma3kIW1WK7cIRgJMkVKkz2K3lDy63f/Q1TmNiDxXBKlUsHd3ng3ydPJWfchFewFEV
Y2hPB3Bplxu1sQqs86EkpG68CaxzwKTzMsRpcNIZbhoVKWsrSRwUoeKBMpAKEKORpthlhTmOfo5A
q9lCEtQk5ynS3MxDgzwEwJdWZHTDLZzsGBPgqYh4KGkL40PeRei5yNnJtCY8iyhFUVopaPYmLGCs
po8CWDQbrFoSxZ8PQTMdFSLToZWocGljZMWCwMsXwmBM6NXFGrRwsfFHkwxB9BUW9GAlWcM7Fkbf
yE+GSXZp6FSKEMWcGEbHjg8j/RhxRviCVQlfpkIlehL4Q9kg0MwWCOzOzQiWguz0MS1N4SJnNQwd
5LLLsjKO1yLR9sIW2M2ISxcwZnkWQ/RdPhcDW2MhbK8pCmu0HIirY9K5gxrkToeWUZr7GyaoGmER
d5ikq9ZGtdhEmxHC1gQrWCg3AiPQlvCvIp2nybuktxRKDFzgY957EhwOIXeCk9aGLcdDPWkkIstt
vsqJRgqJM5olVwKYMDeYos01bRrCxuByKi6OHO7Q8tNVcDZNyIS7Mg8pK9iHNojdAKW72YkDxGRE
W7sihhdDGKuVWDHYZG6Lp2Ik0llfGZSOFFnJGWU7nomlhwO6iN616ogsE0RvNeBARobkOiLbQqML
QpyJd02tQYE2JE8E8mGGITuIWMrofmoP7NT2x8AuNCbTMViDfhB32Ui+mik8xyZP0BqFrUNHJOWy
96LVF6GsYTtF4ia5FozuAmkmYSgyzSj5dFxpmg9bORyjnTQ51fZ0J0MMtXJO74JMStxnIqN9rfkP
WDyHkcYNLy2OzA6+EJdBtkigM+Q8P/yI1lsnwRZbYw5zyoM/Aet9cDKuczQ/UnRnvIUbS4rgpBdd
h0GdFiTy2O8xccD608PgUkzjtlozmhymXgTsj2TWKpXAwvTzoNQzCYnNsEaexIq3TGTPwEsi0VXN
/pi+sTBmDMsbuUz0MhQ47WRc5A+g3HX2Jkf2Do3oUBxJisx4HIbsfq3KQ2jwzobrPInkWHkeX8Iy
JIWxCiqQw0yQg5IhLIjFG6HoTo0LefjLpE7EsEEs6NPKHnWhcjcc+Mwi5IWYE8/BtjJZGuDm8DVN
B4EEskbwTOBhNGTJcIqdk/R/Bsffwl4Fi9CjHPhxgbosIJicDZhehfB5M4Gn0YL4Gj1oS/CRkqO8
GYuEb7ooqFh7TgwQfJjWkOhSfHAmyVIlglF5aGVloWRx0NiGdFn5YGN8ODIbOiO6ibpoMI7RXVHr
SFCPQ/xolzj/AIPYm0P0mu+RIRT0kPDZd4jq1ayNSefwxnbL0f8AzRKxw3DbnkuBpzZpagnUTm+U
T9dSmHZ4omWmJ4r3Y1qHpjdrcmxL6HNHPKGdtSzDzgeR1XhEDZNF1kTwMc6ZTsZiGFa1GqQWcHYr
dUvgUrID7RsN7djbbCYqpgvpUk4EAZiWV8WED2M5L8GcuzO3CkO/SagMkRiaj+g2B5GxQ0rPfA4s
s/IzTWNuZUFDapdQY17i7MGLl0f0ZgJ4O7kQvSMGeYNmU3Yvs6l9izLBnfdRx4DPH2OqJSUAkf8A
kGmfOMzG2OSNbPsF0FZYRobdwTSh9MYyZvLG4c2G/TBPuMe2jTo8I6+HoL4mi4TGAU2tHvkk7X6Y
GJsDg25f9G8itku/0vv4dJpGnv4T3oV77SH1Bh+Ct3DJM+RhjIJ2lExsdIFBLtpzwRaiH9gp8jHv
Iwm00JK2NsLAnoSkzyD7lFBSijRjoTCx8JH0dEEEs+CmQQZfIa2EEjEjmZJbEoxyCIPxIy+DhU5t
JQ1gplkY+/hKJlpoudfEFUVST4aHkSxkRkJmkoWGK3RwjToQYKJqGiC8/A3xRu19iZD7AaOX4Ilh
9kOy0XnkTwJDQq30PRqsQhleSZTHUYEwY6KuR7GongSrFwNcDdG6eQnD+mCLER0fYLWjR3XBkxTE
pbHSsSBYaR9kS2NkawFM04wL6v4K61F4PDBhNRkaQ65NCrF+BF+C3ROehLcoTbiuiGR4QbO6KPGu
hN+jkKWUU3ehszoJEr0K+Pjxmw5gLYgoeS6DeQtzWTD32x5gkZg657LkRFSTFuGyGw2CvZX2QW/o
bbZmbKc5wJT4LCHb4HgYxhxRHAnVTbEqwj6twNS0JqtGDFRruLXKGnAXgjGOaYlghYeQ8lXBjgVh
rg7DI3GzM7G1gQol2iQ36R6DUYAiQ9ODhFqwskyLS7NgZJ8HYoL0ZGM76HcLCEtFVSOjk3VnRtlE
hFryKNgHm8xJ4CxhRyiqWcDJw09lGgwflgqqRoyMs5wQZ8fwMPRU3iH+BFlCePhrAzsHqeAUjNyx
haqBStKKsT5E7ZzDJ3IvylNdi3M2IuxNK1ZRzQsz4C5EYzyRHUNsCG0NxlEG/YRNzZHBSPtDvzHl
BswaYCAPojoWWMaJD0GLGGSkmCK4FVxOizSWXKPQcZmZbycBBBu6IbUjA7ljkh/XIrKppvC0P6aa
8D4fxGL0cqm3R/Cw/wDyDBZNsgimTGGcdGkX4mewhwTQuqyYEQqJ8TF+eME039jfdgoKCEbKa4GK
VjJqXiROTyQ6miUVg16HI0LPxOoGsjwznRcG2PQ2JDgkeTJGR4RLwVJ5Q2KGNmCiWdiV9kOxhwSd
LiEFCGfBoLljkRJ8bMV/C5rOkECCBmv+R57HCa4Zg6QVIXQXzWB5wvijkMlgW19BS5l1s3gDH3gb
JjQh1DoWS51bySfY/wAwFlB4L5TMwEJ2N4yWqrkezXCEo9Pi1Us7MFJyOsqoYbSjzhC8WCar4RE0
1cFPUmKupF2pJbQlCTyEpHFJ8qtL8aENyIx4WWLgqxHBKZa1BVoVFy7JNKZ4iQL0s9FeafEwTgnk
vORFbSMGZcFTwIQ+eYJTqIUbV2kRbbJtw3miinDaMJU1RLdtegpO5I7hNFbDOTFMxsaq6w9MfF2V
EPWhIIPAkdH/AArfJ7KPobOeiiwXJ3tYneF4ZyqjfkODQwzB4G2xBcR5aQsCSGuxfesWJYCMU6xT
KMHmMyqpwMT1oJOF2OwjBwdIibF+JdHDBlpCl28DHwpvAk3fwmMieYbrNoc+y5c/DP8AwFJhiIss
ckUjjFR3kCYllFSNq8ZHRo8ZMWLbHnkX8mY4XELCRa4ceBWiVauijqXIV9L/AORziejDSWNrgUjk
NvSV6IVwoKxN8PQjvdQtolh6OhwY6KEmS4bF/TkzTI4NECyEwlFE8JNtMe5Qvrdf8ISOzNcdBJax
iDXiyjJ5URj6s8DOUJjAUn5EVTIbxDrUJN04qX5YS6Gz+DJPQzlGhAyaBSbC8C5as8j6YHgzQynE
wh4iCyx4eijdQ3OBo9iQTCQStMs+0c80Iep6RJxJcldVJ1BirV0MG5OCvUSBvnkJnWhctlG84xoL
XZmCdvIwFmmzvQTNm3bXAzWZVob2yErx6i1O8BOSqNcm8BC0t/BBLThZHWPxEN4HnMHsdwKvLOCK
cC0QmPRaMhVjcwSp0IkcjeRbNBvwOv4ZbE85EyV9olv4LMBBfoSLy4noa0zBiSBX3bGd6wK0+YY/
CZFPqaFNu9CWl+eCgkoh+KxLoM3kgnGtmYyjLBCEa7MADFSrOYHNfsxOf7G7Ua6MIq0h/oNC7osn
A+cFweh1+TB4ZBjn9FRvAbpLy/iEknY4y03kWyG/2CElrYZ/AMWLNPMCcu6NhtLI2moLDMuBOtiL
g/4KaK9kZAs1Ck63iQq5K4GiyfszFDQiJjxHEXJHax4Y38WbIbfAkcUfxsFeRoSnfKQ4N+MXq8DT
XIuMCN5xRulQhKa42NFqboqUDoDIbiEzs/rFIP0XHwz9Owvz0I540by+RAwC4GhMVdETCfgdJ/IW
5HKDM9mx8jr7ha2OFzVVEJPWC81Exl1YjrROI/gDoQbkUdfcPuMDOxu66FpqD7L4JVE50afYh5Zz
Cwx8i1KSc+CP0eMkhpEvkxpFoYDktLgv/d4IAng6sjJs0pX/ANMcF7/Cc0JQZL1ydp4iLlWKo7Pd
Msu2injSMDMhdrEHnbMkGCe9ispdMKn4gwdxowYpg3g4YljZOx4ECxHpmGxJiysDdNPKQwt14MmO
qzZjI+m4PMJtyJ8iywNoI00Pdm5b+Dz8FTXKZR3ZwWh5kcIaiJW/+Q83qP8AnYQXAsw8SO8JWx62
EiyvNYHhKtckvrBExp4RORsNUWMGRYuymyQy4FwJo+9CM8B5G6qSSb4P1T0EmgfYTUo666c4XBoz
5vyNFSEvoRg8mAlk8mZdYHDpMplTpYpui8hjXBx9bsjgEtIqUsQ0eA/0kpOr2Nw1nCRl/tS0xGRs
nI9Exs9iEYnENVayZEdhI2cUoS6HOThzJj0byaZPoYNC7ZJnY3F56IxmnBlR+4l4j8kF1jrpTOWP
hWWHs4tkfAzJunEnA0L6EpP4U+elSg4GLkzsM1NborhrsqruEFSVx2M5B2UTcJvIr6MW7DSPkqzu
slG2KDDnApCuBWEGdpY7ZfBaORDJjo31yOtwz0hELmIlHum42MbvJCXh0ldOTJ2MS0uNRzD0Gn2+
DV8vJjsyeDNG8n4GEYPwbjoaHQagZLXobal4DASDsZAT9jUF7QzZkPDCUbg6HCEj8GhRkeKi0tNG
VKoVBvKWhQclUlbA7mH2Z5seu+DgcSF2Co21NiW7WRbKDJG1qscYuc/CZ6MRadilE/sPV+Mlm2xW
52gfa32EzY9CrUmEryvQZTL0XtO/Yh6vIUxAlcGxKJ6xjgsxEcHrx2Qu3lBxFVNo/wBIwHwfwHjb
IzU9iAjkHV+Crc9DMjjfglxci1QrpXcj4LkVHjgqlWMZMsCElxNkto2m+ODEWYYkEmc76jDlrCb5
LqeSDW9RUUfsa4kXELYuSVCHXDGQriIsv+AIDDf8HDvYV5L/AMpyMw+hLNW9kWJBmBYmCcw9Mclk
R1wO5hgxkmqKiQ2RHCxDTfwWfj4qMgrhiBUzikT2HSKoXgXOqpVCP0uCbGEWBQLIacUUC0bFhCnf
IryOnguEKbQz+EaVdi3eFtdGZarkWEstBsuUoYMllVhDYEsEJP3wvsnK8N+CWv2DnyCQtZpFh2Ei
NeRrkwQ7+4Cx5DHC7PFJRfDzElyVUSOVCZJaRrhZTEvsMcsvqgjC2JdjCgYXI6ea6JID4Msri7Yx
vGYcmO7Y7ALgnxTkdNNfYXh6LZgJiZSyUu7fByw7DJuvYeRCnmEbZghRp2iLgpRPk2yTEPDPQ0aZ
ORjIsM5qG9jgTkNPBhHuPHaPnY2Wh2wnPsFFXvELqLHZgWkSok0shPSf0wu72Io5RhIioChOpJi6
GNsSjM2RFtUS3OSwe0EPayuxusTXJgwtnahH6FG45JgTryMSY4YJqPWHkaVWhVUVyGBan9iT38SK
iQs+EGpZ7Iq8YEbd9lx+w5JJA6dLyPajvA1NkMmfY1IAytRjSjTaHve9GXllDVb0aJwb/BYGQ88U
WUOVZ2lcUb1L2KNxPQnJRLsTmkbL6Ds62vhS3AqWSXYduQajVNgYhceTq6cjlD2KzfAxLuAXLLnY
OqgQyYFJKXQ1ImOofQncITiUIY1C4+xrkw0hveSxsiWxPgeBIUymSaRnnYmaTyLTZRjRVZyiaUh8
ZhoxiiFpMQQRkZMEnfBhMyCcNIaWDCkz7KOEKHM8iojRZJCWCKGP9E5C6yM+pjFD91AxMR8UtY1D
a2dbMjPPJc9j9FEkO4toWwhZNNwMtSAqIaHDhKilnI1Pj7JS69WNfyL6qT4KdHXumdIRw4+Fq5+R
UHMqPusIkjV78mVWQnRdiK09UhaSdQVZveJw8D83yQqtlVoXToehkZf6KjWzYyQ2/hpoXvS2i8jl
GhvaF0YRq3XAkasJD65Wa7rPLjIxh02oVo9EXgYEefEJ9OS9jmUEAbvdJMogyC285LDrH5z5LwOL
ei78LgZVK0I6dMr5Iz9gzOP4ei4GFhc6E85yxZfQzEmnwLV3foG1NZmGj1nQ0BGFHySPICXWnA1b
GXCGqH3bNsTONCVIHHkVnAoV2xW5A154/Y0A8SboW2Bj6nzciMhlMK06Wa8J4Y5JrphbGF5ctUdU
oodHya+BOGkNGByI9aJnRPhsjaideoUqTMuBrBpUpinJz4NhrBtj6IThliR/EbH2aTA2F2ZN6jZS
8K7FFXQehtm8CaQjrcwV+6iyG8QXYn6NKweKgcl7VtHKyLkvuBmE4Smh2mqJrZnaMmWxCUHLiryR
BWu+RTaX1pF3h0Jx5JKitwb7jNkhYcAc3J9GqnplsYFt2QSliM2S8DQ2KsaU8Pyx2nyUrP0tGC5H
A2d0R3wd/hIhIIapgxUx1WMNCdiuIDKzyxOk/wBmAcn4H24y2Ns6HKiGbKL4EpgfnShu2DslsTIJ
YbEbUERMMoJzgx4SOoXVn2IolRPBtHAg9wo2TQ7NoyMN4MpBm2ZhoU2wlBTLLQ8xaxZOfAvoLcMv
KF1FIcX3Bw8PJ9ZASQDFgyLW8DXps6bTCZLBINHij6u37ErMRmD4NDMEjRokouREUbhvkUJ/YHp0
bCeNOiZW030ZgzzSjXXtmQZKkNvDRwNDumoPIFZwLADWzVHzOjGaY2LdV+xs55Mx/oZcsyGBTypn
jLLZyPQbaMDwN4+FG2mmJtsXufBjIK6MWDNUejwbFEJWzkzAUNaGMd5+DTY2bcK+FybGCxF02N+B
j0YLmjj9/K5E2jaM5MH2+xQNFB5mZg4McngWMC2JkhvjJT52PIv6KYRt5DdjBujd+SanKZjZGzJL
8CiYMMT7Gkx5FyiNjZhoeA8YE+h4GOCX2EzogsGAiI0YGGl7F8F1m8jgbh2JZGk5k2y6ZKdixMOa
TsNEi7Lhai6/8DeX0P3w5JAqVKXZQqnxiiR5GrISvBlMwWZ10NrLK5+IXW38S7NjZL4Jwaez/Rp0
l2RTBkPKOzY9WDw3A5MisronMseGxJiVkWdFsgxbNfBZ9miUitIK+2h8WoZS+Lb+jQrWynBsaDau
hLJtgk4MtE5DDWMyLhFhTSIKmUMcmoM4+RZy2ZGqxIeTAxRHJsf34Thulyaz8HSN0aHFECBduVHc
oyNLRtU6K/QQ52Qo4GLVrBWjSjUEQ27I9/PQubBX/di7afCH1vSHeNMWmq7QQh9DZ0HkXI6Emj7/
AMBEDEzzmlFfxcs4s6uxRVRs5apmypzR/HAYoGjmSRa+gwwahRlptpMW/wDrzF2VEKZVDlzlirFT
PkVQCIFG6KgfRLMDaY2mBRA+9CpangQ8AwkshVYS6GORCMSsTV6NvyNvRHgaHjBRlIWCNOmXswkK
IxcEwLrRx0/g9CUGrz8SRobOBB1lUvL4RfBUi/HBPHw1WQZRsiYMY+TE4ymvkdPISrRZ9FVNi2eQ
4aGMCuclFj4UcDpwLR7ZqIPLVEoLk0bvwMn8aX2L7DWRc4NM2hN1D5D0SKsetDyR57Eyo2LZTfgk
To8BaJyVdE25Ll6KBkiWfsfvzwaSkI/75NA4MW6JeMNQrF2+hUgI8+wmksFzBzZnaXDGyNCrpu6F
uqa4Y99wPM2zCxRtaMXwiLDQS2+mUQ2GHUJJwJrTHhJC3LDXysl4GozejVuNmCa+hOm5LyYX3PQM
HmoQ/CCW0zY4jjRAzl6jONhSdB6ZOKKOBBHedoa6EP7hIa0MJSi0kbSkhjoRCMOQF1MJJtCWqvRc
J4OSCMQT+5djsDoptZH2NUNtXwaEHlxijqY6Gp1pWQlzaxFppP8ADUZxRzX5E3ULHe4/3oe5mc6D
qMSiGIbFsQq+4wPEcqREKy6M1TrFVBdds8ipFkKLsV5To68WzK1bE3COad2NTqNz6GpM0VkqxC54
sQ230mLU0q4Ix7nQm14U0S7MVjTbcGtngwLM30yUcvUILlyXDL7UQ5NlNcEMnTQwlvkRNJlM0lFk
fBSrRFeFXQqKbsZicD762hWfoNobxpm2mSFRFaIK6ekyXEwsS5yFLJuqcHPDyyIVbm0HyJ8cC+nZ
5HgBQiz/AMmHBrgXVv8AkIdhNwcsJoU3uhiC9D0ZAxVzFf6Kv2TH0SdWF+6T1+iHtJJLpk02xDQ3
YOhTmIT3FGuRaG8FF0X7OM7G0KJ6N4LorY1ORvNL9hqJ1ZNi0JwexhewpwVP2RCHK+PY0Muh9NiD
8I3obnk2zRQ8fB5K5PQTGqJ/CjuRFyeAuRG8C3keSBKkGXCHcFOCuEZySFuxkaVNjy9FNvQ1HoWE
yH4+Eodmvh0NCZXJoTAo6PKFMENsPIhKJ8k0N0j+Aj+KqR9zEVceiMwZMZPy0bGVQZoEdcPDJZNh
C6nf4X9U/hxJgG97XZjPyN3mKhgYMrwVIoYF4LQ6UbhBoh+s24Yi4GI4UK6FH3FJj2XSZvQ/uGt4
Qt2IQ+EtBZiZSzgkrd8r4Qbq03Ipk15iE3dIOEpGM4RjJXAg7MBZSDI3itaHUrsgozw1MclGiiE8
18WB0nvOTUgSHpQUJvA3OiyQxzLfHQ+OKGSoRuVLhCokNaHzMXkYz4sBCJGKap5QwxYJ8MBTLngs
GyEVYxQI8AWlRp6pPafCKyEEbhzTM9MYVLEFIJ6Qma9h5QlwcoPk9aMxKdiVIeBPaSJkanRuPA66
XOg1SnwGqB0UaJorbX0NClfJjxt8cmELtBuXsNCk1Ly2dakRQTWYO3CjNa7kW8oMgxjj7EstdDo2
5gNrPUmYzjvBhMV5Ekf0MHMZLLdiNbiLaKyMmIYtifYyqQarmDZJyNYZQlGRulljcPAWVp86Qr6Q
WxV/gWNkTrfYkOQXfzLFVGTYOVlRikW8ismPdEsck9FBX43aOtKnGQ7Bq3saHuFe8yK1sY9IU/Bj
yOHQtyYP+isw0vQtk+iGNGWQ7hZ2Yp0YuU1UkNs1zgW3xGc6ezPMbozaJkvg0GhSFvA3kmDwNT4X
weVDWhkXRrC1a+EjTHoosYI58LI04OCmOhLJOyHA1IyDjQ1BK+R5CTo+BjQoORfArTOIIRi+nywH
rE4dPkGrMBuK/CYtyOnr4JBuITx8RvJyPKFoycJCuYEhi4FOd/Bp5hOTnwN8D0Z6R5aGyvRI27DB
NIyyPQVtrBobEY+434h0+KIWIqJTMnAyI7ke6PIut6TGyRa214g8FvwcaQZVmzELjt0WIz0bHRSP
jYtcnI/oJj4XpjKOhWTwPSDwIgzqKhvTYxreniYhgS3uYGbFCRRiAoxDEovI2ypeRhB6sQebbyIQ
ZhszS7ejDeEVyYY7ByxZLjiCuhZDkQSdlc0X8Y0QLoZXZiNjyPrBENjXkYUby5CSZBbDyFszfIl1
mtMSQe0GWG3Yxun2YL2RGBmZR7ETHkL9ULhCppI8BlTWfY1sPRkWlHcMeHUYfoJrZQokXcV9hcGs
PRQWPNji+pGj1YKa+mYOCHM5RsF6LMSM4jOp8JiWhMeszp6EuCFmjTC7qHFmmUzFZqBkq25TZcNF
xxXFGlri/ok8IwGXsYmCCKNyxt0k56ovgbHPL0IZYrgZrYaRgPIx1FchRStfI9DKye2LubbSZmG3
ENQuggQwsJjg0mENIxoNitDJp6hk0jOCCNNeRu1RBFeToZjNyhFRYCoTIhjdCEqZlJ/Bim/ecClz
hMYnDwuDLxO5KJRVPIhF0sG9dGOEuS7pdBaeDGw6UEfk5f4OZqKNKoQg21Byom9FiYryQupClrWz
ImNn0JXw0cWLSOE6NQy4XBJ/YkbMEPvQzSmkI0N8CVRseytjuDYnhi0Wi2N4omPgnkezstCow8Oi
EiEZ7+IvZwIg8i1Da2Op/LEM0ufjjyPQjfHwboWRt/FG1rPZkQ8EzSPgUPJWzyHs/wBGoIRsUMlJ
0wcIWEJGEOB+oZMGP4tP4wfkcMT4L8bRjaTOeywWpDeBZcmBpCyhClvImVgarI1Y0Hkc2RYEpURG
CuTY4aGSlOxBzk6Ubq+aMb3MYTJZGuDWbMBf0LUisRPQhdyKZiiNvZiQs3JoK0hrMpwcUgqV4xEW
FA3WFz8da71nIyzcxHteLCixkVtjE+lhiAmrDec+w/8ARjij6HW21ErKvEKmGRlhG52Lzlh0X1Qc
jzSyf3FQLIUmFnYnk69jdJ9C5fFyI/tCLjUJmPYxOWmmB1IsG1lY8CHWGskiwpv0I4UWCj/UM1p5
IgS4Zr3ItSnbJpguCafx2RjyJ0ZVNUEIBIhpDrK9BP64qmYLc4ih07UXpPA722xCarJkIGRGvQZJ
j0xflBZMPwKluvoUotFy7YnTRXwPNqMpJq+iFbkwoqskg0E82xv3/R+bX2QXMQyJMvsYDRRmhzSz
EZGYYsnTLNSjo2dAjhZThD6ZNwuDX6Ku6sVt3J0OalnlkaRLwK1p5MS4pH+qJmEdt2Ix0vkRk8Ue
zDsxheRddB1htnaYkIyehZUN+FwsuzGrUVmplxLddl2UtBDIxk67Q8IK98F1aXkO+mxaTEJvSzgk
XmWIya5INco9FALLrNmiE8ClaGJ2LlmDsX0E5EryjELjnY1w+mTcxioXeRgclg8iKD22cnKqjriu
ehDmZpmlYqbRseEJYI20JPZTkmTb40LQlHk2yEViqGqxJiTIxL4MhzIrkU4GxD2hNQqRyQ5nw1WK
r8ENE5KhJ2/G1fjNU1FGH8NZF4Cwqdob4EqxItFtCEKFgwx3gTNnZHYpLsTcQ3kTJUPMPZDuPI8e
QiGno56GjNDwJYo1eBZxII0hwGuRHIx2/iU8Oik1gz8iySGR2NuF7P8ARmrWlTY1Wjw8b9EtFk05
QwrZMfPYjPvgR48UxnKkTuVexgeaexpoi4Y123sQl0J+CNXaXCM67XY6jwowbynQ+XHhBrWBwoPz
HfCMdvRmXMj8jMibWihjUX8MoWgirL+JrpCbMfDG58n+QUft3mi23NJB5gmfmGgRJKbERoJOSHTN
BrCsOmMi8MQ11p6HLiK0qCyUgcCzOwQaDdNjUcLrBHeROqWBKk/oexj9lLow3ZAnWCdF9Mp4Mq5M
VIOeFY9tnoWmChIcxEcTDumyDLhjIqK/TP8AtIZmMVi8HBK9lzb0XkDa6NcN/Gg3IfQfNyY410P0
RlLaJzaCGBCQq/ZRJuPAjbknwV0ZrIG2V+AjMpcJ8DMoR9xuZ4D/ALGNK2aWQSps9G/m6fYFsm6I
a69jk28lQzuIlcUVP7K56fhjRt8GM80/DEDVRPlryZ4/cIGme5TRZPd9CsYjmJ2JxZNDS1d4ptlF
ZeBPo6pvVHAjKbd9k6m/7NqxxWs+mK8sdjDRt+jhZ/NjI3fsy1NUhdUdt5byMYqw6a5TLZv7GZH9
my5EXE6XTIHm2x058I3pY7G0TPv8K0mYkyjYtOQ0+hqD4Au9BuRDenP/AOQc5l7Emtm4mg9JeYNm
C+DXYscDEjO9I2DL3886INsP0I61fReyHmV+jDP6hsX9joWVJm3B9z0PZGheBQ6sWNt1Oz2YgqNG
nDdWh7QVBNGGSErwbceEQSX0OeJElTQTbF6HalkT5BuW+h80xPyVfkptrE2X2FuG62MLH0PbsJKr
fyhvh9j+AIyfAh1Ni908iRzkY8SyZT7DMlBNQe8CoX4bIxdBl+K2VGmaIswkh8GsmPNRNRt7FhOI
I4LcqDWPIkSGh+CxIfHRXgTZD6NGbzAuxrQgpK/CSV5UyLaCLsKIJ0ZeV8Yaq09D5DRkHgQ5RX/g
TIK68SYZm6wMXEKQYo9QbXBHI2Sh4ltLcjNrwQyVjSPAauJBZC1OMSA2PKIPAb9hZSQnSiAwyrUK
xLAhtFHL6P0QawY2+iPag5C37JkkYgKzNLhHc/4bmJvljNKOjRckIeIiOTRjLCE4XiOT55+IvrGZ
eIbEVRsPBS7H3zHvRKJEiWXAvsrookwUx8wSXqPhnEcjt4wPx6KGpIOsNwcmY9lG1GLZOsRtNCmJ
CNVvZZRS1CUk9hIG/Q922dUQJbCfQ2MNzUnsQy/jY0P4meLPRJQk2twnGTfQjLQo8FP0NkUmZvo2
rnge8HKBGhEWaNj/AIZMrmGQGMaZwqM5q2Q6LwIZm/oNdWBfkXCDtLgsryLGWZMSdfA5TbRorkHO
h/aekIy/sVV5vIth6Q3iGocZMMUF0O7gsC3KcwPpWbogE/IjufZxYOKC4/wPpYnJh5TeB0GyE+Vt
jfOBBhTUhbWhujZ+UXynfBZoaRAWcRkKec4JF4nsTX/mEBKBYnGqs5FRpx3GlWTwxyBseB8ZLB1X
JzcrgsKvY2pOiVgSp20YIzZyQYzSxuDRE/A9K2HjezYsJKJXjtnPWOBsaamIhXZPA8q47qFf0lwh
MU2ahgdYQdOuBIeJ3A9aQxPJ5UIgcUnUdH7ECKqmwwR0IT59ByU1yPn22IV7oy30cPxbC9BVnsnb
IJPGG02xG49JJ0kOadpwcuqEOiFuPI6DM4eVvsjWdPGRFrTOqIfkRMGWP2pVD1UmsuzLkmoxTVKh
K/oRkPTZZju3NDbzPgV0ugwpgpwqNGPFgyUbYVH6hExMqD9sUcFclMAvPFPBfpxIIUmRtDiHlIn8
iPcNEfmGf5Fjcy8HR6z8HYqmLCI9mxuxcgobyVDmEQTZlkH8M2MYU8lH00U+ERmduBpPPB2V0Nlr
NkIcrAbWktbGZuRfirRwlHklkUvy2LBbnI92QaDXPfwnKONjFLh34NtDFN50fRsVyMqMvCUeEWC4
MIKn9FeLqmmOmRV7bwWhG/Ro6oWsjyJQBVInZgbwIVZxNEjX2M5Zu02GJDdBdZ7lodoab8CCDnun
wgjlSo0kS8kLoJBAqTgLelUPzZ/A1WFaJPXcjU4xHU9oq0y5L6jXgbNUl6IJl0eIShLRiD7FQsHB
JSi2fYm5FGDxGEO2RpaZeIn4KepkrOS0Kmpy1wJyE3Lope9fCWzwI7GTDEsCQ0OmRWRQGJms5gk2
rwoTxeBihLl5FYPei+LMFqnbg8txubF37CImg4Jq2MuhYRgAvM0PsVQajhnKYWNoVfKTqAhzkDXn
JhZx4GZAtnkjTcj6pl8dCUojZ8mO4OBTydF2IJ2DAmew0jCH4Q7zVGFx3awOEywW3gDIVREaMpLc
wbtPAX2xXbHKrMNI5mxheychA0xiDSDhoJLmG8iNE5HY9v78EJkq9oYWQ3RPLqyhGFlKui20lQxH
EEsoUtkxmINK/sW9OWHSQ6eBur4DplTi8FCjf2MH7xHULSMu/twE3AtGpVFySE+sseB9SAy1d30E
MlVE8rUg49dj/hqxIQ+Q+KY1MFNbHI3DKMFPY30INKm03tinknSF00JKNM53o7cDZhXYvI7wSGgW
f3BJqNNK0R5vkqX2VjK6nRg/DNJJ5QjNaJ3IueW4HaBpqzhD2cQRIrGkmjWAUXgqF0YGbP4BHZp4
2MVWBBlxoUeRlE9ycvwZIoUYwAzAyqOx0Pgd0YkSZ1OPa1m+6fIqnNQwN5P4KU04CXdush6DWjUS
aZeuGTpRHLozPZcj9iJfwU5x06M/Pt42VDBsSdXleQ8/JMs2hCX0YItCcQYQvRRWjzrBj6wXkjXU
bjOzYusiXno5xHUOlZMKlFpRi1C7vLGOl5D2+R5FUorZRDGVJWj/ALqmK5xRiaNQ/A+hYmfRipn2
UlFx2PRU8TngghFcCGul/wCGg3huD20MtN8oq8PM8Df7DFU0BrLKc8wRPKUTny12Ezg4+Dw8iZIA
scWpTHRjjMCF3wNBi2iQbBHEkYFpxBU0+WJTfYoSsYYO1dDsYLLF8IfmUMjmuA34jrPIsQ3Cxnk9
C47LfBn7ODAU1okrvAmbrZsQm3hpFx/QKQuAU+nAVuuxZg33OPIxWBJi1+AlyFhm0vYy3KYjUMJj
YE3cXZMe2CUwyQ2HDvyJaPwZ4xHshtQs7wIkrujppDXMW60GfuPctfZA+xKjTGE2wl0qLZhPBQdg
xvKY0tqphYmMZuI9qC8DBsKYkOYOReRUiecFLTjYmsE1ZbEQ+xhBnYTZxDQtlFgwUizYslwOvfLG
IxzJi6MMGzhLAmRg2hVRhJwYYoxlB59h3bW1oe5NOgjWxNEFiOSVpjgQR6UxcXYyDJMlspuiNE6M
pMsS5QwJWyxRFbwyxhpaovAbCp+RmC6gQXEeCicuAq9AaT5DTijZafku0nsIBNJ9Dlgk2kSsEMST
mOjFnAlW7uBcJBudYI4lzEcG5GBCucE0XgIz6E9dzRSS6YlLunDpweHrDFbgmuGwlUZadNLwLZem
UdJ0I4+lG4Z9CvaY1W34GGD6CLRqIveLkWezZVbLLHFrnoTyd9kobWzn4l92dF+6WcsfBIcpGAuT
wyByRUtF1OGTmgilLWC4M7hktqUxrs2SBISrcxgRjGQ9bgIZ0M5egnWcKoSQZEosGpB2NEQ2x2aJ
tWNpRn2RUzka7NW1yfIyboYU1Nc7MP0Kj1yZw2Iars0lRaGt0GyPtVOwq8XpD5HIxWwsCcEmazWT
QMNwoKNkktPBGyLQaysOC8CcrYcGsjgnGOESRiifDIGLJbfZRbIwSoKbQ8pKcSSjGpHMaMEWdjGI
iUKXu1swHiRUdcGMgqOHo8oEajs21YMazySv6Jqb5aFQxogi8l8GF7kMbLSilB61tC7a1SXFZx6E
0uTbDkekwQz8dhJ5+gVSRgecVWBHo/5CQTu9sGLCjiIL58gW/QQjlJr/AISfNFRp/mYCHClLAx0u
ix+OoaNi7x6Hqu1/1jWSB/0wmLYnn4/d0bI3GHizBIMoNuUZ9Q54ZMEaEOR8Fa6w6E84Fq0085tS
JqcmzSi1ThgaeI2zIiVMiMsNOfIPkxhNWDa6MNIucmyZJkezE0U/Xw6k2hkyIc29iAjwMry0XIeK
fJQPDQZOI0oaF5DsMFcvmdNkRcE35LRfQtoxeTPVIix7SoTVG15Hqp/xFWm7giS9Bp3FBwRsFYWG
IKugZ3wF07yZtpMmIQXTTvRWUqz22M40EJbYr+4SJBA08GRGSPa2yStEsaIe1eePQiplwOXQSed3
ItPYiabOxuPOBrLaCrh2Fbu0RO82YFp7OQ2yYB9DBVNhoZtPsVxuJwZOrZW3Ry8BPTeBliNxjm5s
OG9D+BtRuQHLa5EIiYqxJq+xhcLWYClEuhqWylQJHWfWngbwEME8lA5wx3y1eBBtTZ2K0aGzdROe
TZYoq5g3Or2VnafI+j5EBQwhbiiHqmD03gyNvmNtB6Epj+xwgzqRbDmpW8xqZp7GwtzRtDhbhZWx
48iDzGvwJ19DRcWk0J9rG0OztxIh3Vsxh57GTGhhEYvsP5z8kg9jqXSFR3gd4mEbTZinbZ7ACPYo
B9D6LeB0Unk3fNlpIsqC6022IWlnQekr8ubPqLguhpDyUg+J2kH08xPPBUy1hCjg0+DVGoJ9FSRG
rFxAT/8AhGD+whQJc0lZ4y7bGnCVNE0JhbBzanI/4qsbZzGByw1tYIbajp2ZHqiYWRX5j2rHILtq
k4Hi9DJJjCoYid2aPJd4Y0eFLA0bnA8KqVUKHNp88CLPDUVsJkNn48TyFhibWwXsgs2KR8hhGFl9
CYBatHdODeJ+CRwoe6aZ5EiRJnYtM+o1rNWOhxMj9mIgyfuDo0UcM1llKJGPyMbfCDrFqoW7tjFK
9Tmhp03xSJ0IPu5IeWpyDGp8j3ySDHm5YleDZZFN9DYDWCNbX6HCJA5HLKQa9ZvA9mGnGm8iPgBF
itbVO8DcadMO7RlBElIlqQUDNMK76A8j59NCFMf/AENmlB7M86lrLW1C+BdtVa/rHLY3kbfQ1mmw
ubCuhavI03sZOjEPU4IqJrK8krJglo17JxI/0UisN5fQps26ZCvMaty2IcyiycQi75TpNbwuRfhi
kucja01yLdNDz8Dw/hGNTInjRlpJl1RsT5ImaJfQpmypcYwhKZotzLpK8xS04DD2xK4x+XBiFrRs
viVhbWvjVWWrilJhEU3ocwrs3L8KiM9kWbOF8SO8gpQrS0J7S0RlyYG/vgMOslfa8hDCAziPyJOd
SUzIIs05wMjYS9lSp+TtCFHY1kTIQpcrGyc7uRI04oijNdnB90YO+R6DvSOGfoUmF4MgciVPXgVx
kWBagasmcC1j1F2CP3iBUrxRSfmY+DQ5yUU11TPiko7x5Kq8iPkj2mWh1YCI04j8lYib/R3UJwYl
GpEYRjrlCghtZE80SfBE3Ye1k8ic7bgZRW2E0/qOTyTF6DiCpuD77GOvxohxKxOl2S8/GijRkIWL
Xka09YbmG/DJwpoiQ+mOO90Y5HRDJLyMpwNmka1OUWgH+CTb+BvZjYzC0jHk0Wn5aFpg0MVf5hPg
jeQkjSnxQoidMj0NoHzRDMFtUdeSeoSCnXyKihrHIqsFWbKpJS0hDOqXZTjXA2tx5sbYtsQdW1s3
5LjcDNe5JiLUcMTVqbD9aA/qXt5FxLxMq9mD4sxWaSa0mY9UnNEjtIPjccoYrYfY/eJNCHGVhdmW
7Ey6Sii9Jh+8kxBvWNMUMleGY97ZaNBBIP8AhuG85INo8GOLDeowQvOW+xSbOCxN7YFNVPkxigzo
xtR06QoIb7V85K9qZ9FlXBIkJjN8hrbyNaxPPwa8KyFDw2iMBXyJwZtoglf1E2IYnY5tcwY/1cJM
JmITS9P0RqT0ujKL3kNlK7j4TQUraWGhqEGfQAUyqvLK2rS1G6/Jf5r+Gf6NUe8dJDk8PsYmEoND
a+zZLAtc0uvIiKRdqQVIG1uuWWNLlNrsRsO3eCbPprLKRpTdEjCKRkjRfDt2jF+S4N/Mmla9MVqp
uR8m63HyS7oH1PyITfvEx9iXkw0NuR9bY7KLY2pUXI8OvnlDNbJtejJHt02pciyKpgWOB78YZB2I
0wHrQdvRbNjaehUQMYKc8FB7+Z0wlXCOSOA28I8GIT0ZBNBYWQ163zSxLhCSNmEpnZcociPY86OT
CWxaNGEh5ZRRLK6HnCGX8CRjvM5WYzSXIxpY4ITFej83B9pRd1whhR9i3e6esMY1JLQyvZBjbXRp
HAm7PJOHtYJKpTGh+CjHoTcb6G1Vz6LqdRnNjFPCFkSJ9iNy3sX5bTomZXhnFoWm6GaYawXDfxoL
xn2Qrx9jypPQ9C74EVJMYpGv7OWNF19JYHJmRoS5X7Pw4lbu+zMyg1Jl/ouG2qJuPIkP9JLdRjSt
nb4oIR8eSilPwHNsXqCf6YxYPiifnPJJdm+iDeI20N7LNf8AulbZ0G1fImtjLpkIscv9v4jY/wDh
n/tI9NGNiRWAoal/o8iFUYiA+ymdTMcWT9EB768szGwq8alFlcF5g4f3Nx0yjX3KGMZCSMNmgUcg
4gpifLHtY24tDLCM5HtsvRjK8OxhZTmTT03KI437FM9jxS6MdlSzyQrkfs2+ezMJ5Fb+kfcAfwkx
JVwmUmdO2UVjTMy5TNaP2KcnsO+zHw9MePj9jdlCSi9QVWTfdFMY55G9ifaR2o/ajBk0tDjHHnJm
In9D0aSkymvZcIUldHyCm0yAfrI3s00HNkfBVn3C8ti/TYM5xBday5SMVx0bfZvoLB+iH2nV7FaE
gt14RidCnCrFpTV6Fta16FIaguxI2OcIjI18cQHlb6IwF3r4MojYhwvMExPZfPwMR3OyGILBngHI
65YnnI6wGzeweQ8DHiMlZpdDq9vYyQSaBzA2Nma9RTn3QytJkbBCfQLsfYNeyaLNXCrVIbqmCr2L
rN6HYaMQilTCwuHBt1G9mhfg55EFoYMG++Bin+IjfAgocuIchm6Y7kT8HA8iK/gjodw+hrJC4Z/c
kQ4wcSCSwR/rGyOYSRUXg8b9D5LHU9YZm4+gJkaLYw2xZEtoQ9xJFotJUJQwnkh+SQP/AKjZhgTy
JU3JbZBl2HxNRkuFw8OhomBggWIiIwmPkJI2WllLsekyWCS2hluhSC+GOn0YUE6MLZDkTRcFkkay
E38BV0Gxg3TkTG1kbQ4MMqg0SVDwgVFm2b8GYIm0sDGTIxTaghghGtfBRIyfRScFlUEPeOCXQ6pr
IlWhTg4i2ScF1V8oa1Zl8DVxY7HGTIw+GiwwrQOmiFZFbG4m2soZ5bXY6pZJww+So9RakTiThYLP
QtPQW7zJ+NjXNdDknTQzG1CWB0iGBJM4IA7TBVfQftp4MlFaIyMm7LtDOyZHQwwZWNA+yKKrkUWV
9WirqdETeAjB0hza9lpWRxXQKuuLoZlU3TNcmdCdMKnyZKzyhmwNsTf4xnffImHHiJ+BCGtcjIQ4
wQumFIcfOBu9BYEFNxRaSZrbRjredDZLyg9EaeSTxlocmwCASwyemn32aOLeBAVsl5XsVzX/AAwJ
tiwB7NNVwJeaCiwwvo8o2Z4A5jtHW5JXSXAvrJDguyWjso9ITm9VyP8AsGS3lNBy3pHR9AVSurYK
AogphtE2SKmEYOHZmfIFY1feKVuT0jHgQIftqG94vG4hdsWDPV2EWF8Is3YtEFKsjWUn2Rw/IlN5
KKU0g00zzpF5uDyhLRgkMf8A2EJaloPLjqmZiVPJiqdi0WxYxORlbUEE6RLI8Fk8HKZIOYxQcAZb
HKPztB07gPJU3+BndOGKUa2NxUbYj5H3FyTsQ4TRroVnLGKjkmIolTROXH9DGbvwR0SiR9RGslhm
r45IA0mK2n/JvHVeC1VkFIgsYvjWyDdEZZYIiZrUMVjEw89Ge2tuiTGYTbG+mJDV4yRl0XHPJA+k
J0thdkQrBaUSNOMcBbxcCM1fLeht2NExkWzKZrEGJmGekJnWTYFicNsoo1WKBg5FhIabJRg5NJVZ
BPGmN1E5SwPZVuJsRzAh0qxiy3oy5XJ1MQteSPkV6OT8mSwHyZgxRC/CC7LghyLMFs8RqMthHgg7
ZHciWD7sB4ZQv8mDlJdMlllFOoxELgXJioYuxvOBLhoV0jybPU6wK92HKTQRAhUsWInpESFlppg1
QrcMFvOCKo0alBB/wBdYiQmTpJsposHDEUX9QpqwMdgW1R1cHlYIjUkO1DLwZ3q6xhJVPA1Qumha
QqJVT7CgllB5XhcHC0ESSgRaSgqHBjEKS8moK+BpRtcIzkuTat7IPZWIf8AUQtwcw9jWSObDbs7g
9ouBnUbb8KAkkLyWMFoxGPkkkSrJhowkJbmC2O3KQf1fw5Lp4k4GdpMBcbNkO4KFaw9+0YO3kWaa
WX2IGreDd3FGAUClawsIbcZeIIrmxMCWO32PVY2K7SyLdJJrNO/CPwJ/tgiqTPDB9HIx0y5R9nDY
rcie46v7CZYLTGN128rpDgZyZMyGR7ipDmyag0a7zgTM5lBtwduNEJ2cMXrsnImNtfPwYDqp5Ccx
7wR+xRtUM0UXHYjTcqLyFlglVipjFXEEA9hy6XIrvDa8CaYOdnCu6Jhch2rDk1E8UpB4OB+k7ecD
BG7EwNdMTlrfsZ2yLp3YXAylX9sUx2Lg+nqYS8nRPvBoaY3AhRLPAURXAJiJJ3rIy0SqMdVtZ0Ns
CkUZXFGFJzqYaFN/aHZVs15pRRiJDFa1RqmWaxqtWnaJNUMPkUV4t0Q2xgj5HhnXP2Z9WZhY5ilX
ZqISMpJdZKS+3obM8JUdU1bEAlHQS+FE02K4p2DstyFdkwMZFQtMridDCXl0Z7N7dDLviCLWvhGd
xicDAhmVPAWmhEKlIT2Kl2poQOcMTwnYlSmjOAAkSpY4ZI8RO4idzVvY5IVfYVu+96oi7HM3k3Sd
2ISo2Jsjsxt9JF2R20bCVP8ADI7QjLG3mZhioCbgo8s0Ja/ZPkWtGuRLPJX6Oltpn0JwymyOhTK/
SnhF47G2C2k+Czzb+R7iGM6o7jXyPkh9zDxHQkKiUi5PSJRTCGjUBJOcC8gzI0NtGn8S7wRqDrVE
FsrshBXGKuzBrkpSC6sUloW91EJyuCLwVKd8B3Xtu0dm4iNLDwmhU75i5tGKWRb4g0eFpdTx7FWw
ryNE3RRkqM13kTo0OBdifkyfxyn4P+yKdoV2UW3U0JJ4cwOxZrLiyBoA7nY2dwYixSHE+Ql1c8lP
+pn+IOCtQus7iFQnJlNSfRK4TLAq6LiuCfvKEUe9UUhK40SSeEPpba5QsU9nBVJHYXUU4L7IBsyN
lpCmpdnoEfYhEYwK8YgW3sUHtQWpLgkDGg/xh52DToqSXJ0u9d0md1SXLnZjHnAnpwQRRcTGBTZQ
g1MbEWcitewQ67pNKuBXCbEpbC5dpgWtStoY3cHzJj9C1eUF5+RSn1FtPsTsj0FJiZwZOtZp0DIc
FNUVULjJnx5ohd3RFyqsCLw1i84FajLcEP7RLk84ERW8C1/gau5hkLbQrmRRktHCOJhNpYbuDNzH
wIVNKrkVF0JPKNSJVos5aghqQka2zzqmQTniOVELKFcwdSiAPnDeluBqjZjH1NPQ1WPkXYaLR9kg
KlekSoghaS8jdrGeBHMrRw14MS6nodJjjkz9lwM1ZLLgfgljBuvYgSlcl+lvAW1glyccRAaiwK3t
KCrmDfkkHAzdC088mJKu+AiXRx/BWGiX8EsR2uDXuKo/Kkcq0oNrVLZ9SovwZzb/AAw8J9mLhGD7
Xhzh6K99Ksx3NqDo10M5YZYFoz0gSUYWzi8kndsZ6gQ68DlM5ejOZzJk5M7KY+AoqPpUkwYirqnp
2g1RPY6HA4hxjRCRf/Mnui/4NiimRl3BF2VGhxsxWOjhpfZh2lyY4Yaq0Wkz/wCZq/AtJU+eS9tJ
0v0+mOJo7sVK3AI8DyCXWmBfY7ZTTVgztmIm3hJiTMZp2IqhCgJ1a26HyE+Bm1oxTisMxITTSgTO
2UvCYq5G8SNpBP5T9HXrtTcUJD7E6jqSFVNLBAwkk99DlfOokkaDurPPYybbUj+zQoHWiQNgo4gG
q8klxnJT+GMGWvjz0Ivv4kLNxC2WcZGNx5ITexDNwNkyiTwKauiMPh0GjnlRsWZgz7Ah71g+hyTH
CezIS0FjdmXImBIcCdNymgs0WGT9Zg8jvApv2LvTMycp6N4+BsNsR3uxprzkOlm5FO1VNXrsQlbw
yPMwLYrSVhDRN5FQFoaoS9A2HF+SwkRrQilzgdLmUQZ70MzPA8i8M8hNkbmJwGqcxuDlBcGoi4kx
qdPwdUcFq3YxmoY7JEya20sikJlQQlvIzVeITTozq/6IIjmigbk6QElvQ626ZZUypsffERGSWEnw
dIN5ZJ3zQzWSYiolGIYabEJazgvYs7JqbiFJRNh+Q1tuKlB0Mz1OArkTU3hiHyDpRpmkjxBLPXWd
uhxV1TEDeSm7skYka7o8ngYVtC6dCGZtSQ72EJqsGxMT0mV15Zl7MVZSgzJWUiKT4yPqYzlDFrNp
CyT2PNHBb7QzFpQOnM6hK9V0Fq3MDJ8VQaG5CCNtAqbM8hXipcVnMQeTlUbIytBCHlWw2xnarWJC
Et8IPCcoyNhY2eRUG89hun0WnwgjdPtHZKvTG28BKViEBpN0VFMXynRaVLDQdrcMQ3ulkK6tn0L1
GspTe+hSIi/RJRvkcpSk52fz4SnOiNwouINdd0LVV1gR1tsRXAs+xeYx0YtB4jaHg/QcpLih2a3w
IpslXRY2hKLkY4WeGQVYIMF6XBzlGiCwwngrkYU/WGVg4SGtpl8CIbcDwhlltkurJkSO9liu44H8
1uw6L1EFpRmWuBmVSeA84wrZacyYtk4thZF5p4Jjoy1wInpubJCTwRZF0YEzzARDTCSmEYcMYK6R
7UUMEP8AgDIimY/eVIQXTkfRtPb8wpqjCQSNtDj/ALeB1XJ2Tlw0JrkuIfy8tFkzHGcEk630JRnN
wzd7/EO+jBmcBGuzIkdyEqhwTsZkZwn/AAwbYRdtECwy1aM+3lrhC3PSGSSxPxRnLwXQ32OwQDFh
SZwpQjZVmo08bodPNjR6YAZfSmmy16giYz2Nb+h9I2kCcz0N9AgrigFMFRf022x1wImBZDPsxY6x
sZ/QY3Ctc8sRtbr4mNXFNiodnCDNPH6J1mYI3AS4jYmYiazgMuZPBEW1BIdvAlULKJnQ8EhrHum2
iRkrJaLgIXFM8aOhZag1kSg/2HwHEgbPZ9MUZmyN8KAx5WEwa17FtlYeWpEZwzwbSIfqGf5kLgwx
o7CybXC1kUsmKXDad7GmCLgYdn+F8qijMoaNTolLS+RQ4c4zB4jSi4Fry2GZI0sQftivJS2USSWY
oUc1XCHxyHtUg6NRYFZGnopqrGjICbMz2YFluAaAZ4QmFINc8GFeBwHligpXomwi5IY03suuwXee
3IhUDpj7a0PdHg2dZcRqNQYRq80q7V8sfkmLaXhy0NM8XgYkyU0MrlkmAhuWJPsi/wCpssOYz+Pi
w8tgV4Sy4KYSwOPfCyMcYg8hUoQzKcC+m06ZabsfgkHVIm8Uej17K/UMxsh7Gg+IIhI2WBFWKMk3
a+MlXvmXLnlodchZh7ahJwWIzCTHYg+kGm0FPOEpgmhG8SG5B8DFB1oVh4Ynhan60bpY48jwVDLJ
Q+YylN5G192JwFh0zvgiRYwQd0fHxAYanfIrwhxR9VXNMBkxEhLyOnTdEaZCKnJkmFTGUbLekWp1
UyXSsmqIqu8xluGojhaqUbOgOqOypw6C81b5Z3FzGX9RaYUkJJjyieSR6mmKHThjzNATS9wxWBWm
shc3aQb0nYiC0py/U3Jfm5lD7vYhktayF20QdykSDLa7LFMxX4Qp4wngQgvcOBYfRVwYYwiL8GKd
ZXyIYmio6uK6Hou4+hUubSegzXC8Dc6m2JRDwT90jAxQpleWTDRuEe7ERcZkQ5Gun0eQ2jl7bl4H
BsvkPbuSqjOUVwPW74QfaDzI3tmcK4L2HJ4vPZTt9jeMnGi9JJ8MfBnxyMAjPApMtbZXMTBYYmqQ
oyEadSGY1j+2Gw50RGpoXJqCHMllEL7zq9hOahxTVP5oUmKizyUb6Kj3q3yX6o3lUq2iTOjPXwdD
fGuhnhe4ylWs+BsRwRIFGeBAWKdex1mRs8m0M98GkxDHnNt3kRcOvgRMV4Gdm2TZY55GtlnAnTqc
CEOvBBjXIUngYLTThg6k4l2Y6EeRx7Abth5ZSJvMj3ds6NYbb8CWCb8ZFssUusUdKoopVqHRHJop
K/hG+zZU40fONFrGGnBMj4EsQeHBmp8FX4hvU3YQ3oIPlngRWQtQ3ZfReQMdI4yPTqNHJsbRm2Jz
0D5ZGo3NDs1z2JTM6BlmF7Ko2KmMOKOiMk/I+puic2NWnseNgpIyIS/Y4CaPoYydFa0eyExey5Ki
kw2MXY4yQVENiJJsbEj+3wdc8S0exjO22LOxCziLuX878m1EeCeSqnzzTLGTKU2YJPRnGxAaeUJ8
+5/4kNcoLRehMbGKwVuBg2wyieTaDyYie/sW3RusSXA53nLbGVt/RauRTTaY7NoUGlcfZfy6OtR/
/AjWL7LNb7EBjwQgU5bM4/0SOjyjKz5jIvwMmLDTaMmVvY9to+zQVD5iY82bxeBmbH4Zy2I2yHSk
K8obXZsifYLX3ZjbP42QdrJFdUc9Y0yYYbOuBvsuxqaVOW+eDnyDq0HKSMQ6rG8CWqoPQmVaeiao
J5N83YZt8mGRMwwbvRkV0unP2i3bJsvZo9sMnrauIxvVy9Nmy3kSuT2Ez/zG6Q6bM8mNFlGszpss
o4TeL5TMc/cZhtCS/wD7Rrdv2JwxIUHsvDY2bN7n0mJbeztlA07b6EseLwLU1MpYEf8A9DdZrf38
Du4MzET5RqQY2G6VVL0QwU8Du0QWl7RhfKQ2ab6FyaMBreBbrXgcYQ4Y2YqVOsMygKUPDGDigY9Z
yTLXgrvKFh5wYdJuiq2i++oPGbCU2J2aRc5ER6UmbXsN0mU1CwYF1k6MYlZDWr2O7X5KN4ZXsyT9
PhQZ9mO+KYSstnB6nwDarGBmjI1GaZ5DLRCPWMU/6E7LoIp3hEYfoa5mysatmZa7DrexvB9FMYNi
vnXw2vA38fK5G45yKlEIMu0I7di8ic2Oi1yLqnkcVWUKRtY6g7qkYVkfzpE+Azu0Ez7jswxaQyZG
sGCdjxEjTEbG0mM6Ila6OCoWxjQhyIvlGh/hOLZdaFwJCCQisx+BMNM0F0UHMPtGPL9EYtdm6Qrk
XmGd1sIrQgxj4Hu0Khksr9Laon5EGo3MHpayExWApI3wPWT2Oz0JdIrfPAjeRDXa0JyYesRWVbJu
3R6E8KKe9pwJFIOeguaOWBrga1aQ/gXbl6K39SFwfJ0irwQzlB6bTUYk05wYuHSHtCR25yJ0XmPJ
vo8IFqhYNU7L4RbJgq6dK0dfY7KfRApHoi2NCEM2+jK7WBcBtuEpLYc2sNi2ZT8TEWEyJ8iEigXw
31K6RCOtWhK3Gz9IBdTREc7sUajkOFBRuXJDjJDX2LlwwBPwHTnsX2DuH6wEanYwzCS0x0AlKMF5
n6ySODVlKkM1HdIbaJUMytF1BiqnpDjLXQnaeVaWi9Bs5joTA8IyOYyOCLiZGrOReOsZFYMT6IEC
rEbI2wTLCiMhstjAqlz8KqS2Zlj7LF0hD9R5xoW0gIS1P2EmEpfQmrs9QaUyB0JhpDQntCYt5yLK
C2TFMwo9hqx7Id2z8isiXTEwpcjM2l5FkujsVrmssY6BAf20ODU2RwSopUX+2Bobs8fY2Nt0caY/
7qkzSkwLB9El5N9cXhEtC8iCSxREiSpZIxMnLQnR0qevsx4fseSzIJeTbOx4+M8GPjpoaOnxsXE0
4J+oN+BKZqnILblYow8kxiSrsw0Cuv6NYivgblkps8S2iL+QkQX6ElJOWy+2VU4LiMLyitEvYw6y
08CyW6aE4JhWYvGtBlBrLQqEbTg3k9mMxyyyIU8GbRHnbqL0adDJDJcYuirTQqisfTFhcTCTyi2U
sGAhCS8j/wCSPow0ThfFLYsnIV7Ot4kxknkW4iE3FMjnJrgAcqUI93ExDjmVrLplJUx2diYCxpEv
0cfCDSfspqeihLr7D4LYrTDSPMyDl0smQRjZm4FQzIks1ehrSpNDpuMhdwYo3b5iFhmDGV4FosPZ
guUIdFSZeZzOwi0MBpj0XAbzRRGos7Rh9kNJQWcjIkehWi7pnQjpq21swBa0Yn8AjRkJ4HzRobLf
BMA2SuVwICiLs1iQd0OcE9UaGkySCRwa2MnBx4MiECnOJomOK5GwlSjOWFLeCFyrbYuRJ+RFpZCG
AXnslwUMz00R5KkYvpvNhJKCCK8HmkJZGKBJIYcOiJmjPzHMHPoQy9AoJZYwVBbV0KaqDJpT6FuX
GqgNXj1XBmMHMisySQwDVMLcIeM012ZWCHsMkzHGWxYaS10T+AE8njge8y4wJShJEZpUCBwbEkaR
C6EVmqJb5PowZGls4SShneWKO9rv4eJJaHtw4wNx2mSrCWhydJ5g1NkEpwXIIzstwtyPYS5ZjwcZ
0JasHRUElEl4CG+VbH0skkuUPllMLzcdozWPhGB6aEMZE9BXYoI6rAy00j2X61YJB3ZOS3MiFTS1
Yxt5RLQybxc0hEi0B91U3mmkpoxMJZC1d8BHH7sGjxyKZH4F10uTkgPo04zaVFsFrkLTEGrA3J7B
ea2+xLAWW42hxuORjrWexFdUZN+08YKeiViMs4VkRe1sxS5QWDyKC8qWw0M0+QxcjLhCK0t+BONQ
pfUEFKyxoa4iXoVpJf0FQuuEIsZK2FhU3uJok0ugnJqPaHfgiyU8BR2/roth4FL+SNwpdG846nR9
qFlrMxGORM8BdRitLk+GUf8AOSYYZaHQaRlpRPJlCVLIus5iaeZRg8wjPWikW5RQQXKMAVDSMGkL
f7A2I3d7HDwHXU5D5as3sZZwZPFmOvKWzRpREO5KPk2OeBdTVmVfb0I2ayFp8GewnkpSfRgeYkgn
scBSCjhwaMbsQ0gB8k2vRmQqH6Iy1WuyC55/Rk4X8BoOHIzRYgY9yuB+kH1lg1huxAUEeTYokfg2
iksC/RDq2LFZCLeoZcMqURvKIh8H9COLyz2M51+uh1DqsmT6XJM7OOVrgvkTB0/yyTdqrDOa1JgR
MUr/AKYOOEgyDPBeRLsb+nw8sG1f+mLssoKVCKFtmTgUas20YlzwJUBZ4YHH1tggvAnEoP2cMyka
h8jHLaTHfRHZBaGQK5CfuHUS4LJg2MuTBEceTfwTfRXBPYJVKFN+0LUp0cIEJUdpYGmPhoUv9kKE
10yWOkSOTYtN2hopuhhPr4p55iK7Ept3loajeGcjG3byM0ruGRj00M5GsRCg6N/4OCi3eRyjAhEK
2Rmy0Isay0UvYW/wG6wN6owpYrop6LsaW2mh7JWxMLOTAp4sYuChgdyQYgyRCosCdp5G3IlGcaPd
rB+fsGY0IxSz01Dab4g9ZHfgS6+dDSUVRajbJpPLIhqMXWIeLey7p4Ep5uRWnSEl90OTpOxtMuQU
tqmYe0S/J0RdrIt140Tr6ESatCg8GHFvkRxkHGUVMO9Ieez0Va0IXCCUnkQ9R92EOG08USosuQV0
YIyeMi/KfAnugQ4uBiY3czkd2Ee+F+aqMWzAi2lwLUny8iQ4y9jbrkwqMGLoYt9vSFpbQyJt4DNP
KSLhcUWP45FxWROPst+GImH6KuyyhdBXE2KDZHEJZI6hLAVbZm2cx1VTbyZfgvqf28GN6KLsHuhp
1gZyP+B0uUVInND/ADggmHLDZlKUTZcPYgjGk1tLZAxgMMNorNm4QkpsUZEV2FKt/VwN7ERK7cHN
3Q7hZPLBWXUEmYdX1ehGt+LYq/FsZrSAc77EU/HYxkRcCmo9M1epPRwlrQkY1oWulkK31CAvgZip
twO36Lw1fwPkbFXIbp6MwhJrOdD20JpmZrBEApMGMjZ7exDTzCQy4BZaHTWS8SldGxKykWwmsQeM
EJSxm/4MldaqE4/ZEjHnsT6D0DlNchr2my4iAMoHurYZyBTPIp3NAR5U49Yj2dDe04aJKn/E5ASP
Y0bRLeLgfA0j5HHBWxBzixE1kjnIlWa4GRnMsOQcBS72CbJFiz6oOq7suxLf1HJj6IhaTUjGfCpa
OTjO2dBYcrxLHYpM8k+yQY2kj495IRO9zwgCQliNRbHEkkv6aiL4YZJD9EwLD4Rv4KqYvgbobKJg
2dCOSt6IoGsiUQWeR0TAxJfgOemw3ZNJdklZYkGGX7hyPUTNAXr02IqsF8WEZg/hi9GD6NswxDX0
YKJ7wawJlFZaCco5eF0d0NBZ8E+Jhyk2ijiCQzLsR7DXuWX52hnWHl8CLGz0QNDiQ/0V33ode9hx
IFbGsMTWy5UjwTd5EK98FRwlkwyOU9g02lwLbZwJZcBz9kbgoPCh0KNOfYj48iFhg0xCJ+jdY2ZY
rgUoKk6Jdou7I9S8MXt6nL3oe1lsU1exEyRLgSwIY+SpfSHv6TMOWoJZccmIbCVJZfQaFERciToo
5Uh+Qmr7H7EKrqHyJbHtisGUQdYGC7wcWxtVzRld8jYiOxedzk23vgYYajyvhY/JO1Eu70Qs+d5I
VI2JGZ84HjdeRDvaEnYsOscvQkG8wz1Q+ROMY3RzkWN+iWW645HUEzLM4ZClh2MF4hcNhxYRZmYw
hyd6SmNSaEbYHdZfDH1JwTqmrGBsHoazDcHfyQit1pGXhWxSdeYZWIlMfQeg/vCHZ3RvyxG0u7FR
tzD/AAU1QnsByaOC0tCuqXgUsfckDGH0Mv8ASMoY2+AtZVh/wK3z4+BWK+AtzEV8ibL2sg+DnKjK
uWEM/notuhSiadpzDFp5pGS0xDLCXAhNS3k+jOHpTGxGsSO2QxHQzhZbLt73CzaT2NexLH0NrQ22
UGxK4RBC5YpzyhIrIsxXq5H5wOEJlh4u2LDCdx7EElpgfxSWaMxiW5F4SlgZUwEnA0yxVGgiWhpz
FoxIafGiBvXzcSDbBiHORfpZUFERt7DvDc+R6kYRkezzq2UmWnYnItMEw1cwsPK9nlDdfwyr6USH
Gtm1Jb8ATgwCk4LpaipN0ktv8mo4Up3w8k1vkJivIWY5VVYnbv8A6FpTynwG4pWVGNmnCME7Yx5B
/wCCQbW3C/UqXg6uK9n2kh/uqIpz6/0VCKiT7Nyqn2HMEH9ia5G1mTKsRn8fIIS7J7NucMBAuLWj
0S5Nv7KU2mvQ7a2onRvT1R0lTTI0UG+y0wXw34+KUc0Q1gno9xUyTQtBuZyagOxChusgrTyxNxo8
IjHk6KrCyK5CDm+FwY9Ai5ouJ8jT8jtPRv0X5EX+SL29HJFUfmfGiXkXnBS0afQk8iJM4RHejbJM
b6Fmkp3KJp6EYO1EVVLAhJI2Nu6eRVbLgEMSKA5nRgm1oSsmsjYlRnmqQkxewQU2sZFSQsCe/wBg
sUsJo0lqF/8A4HlJO4NKpVPZ1ofJYjSUEd06KY2hpyGjICwVBk4NCbgOUaEbtcDaVRJZOBdAqUbD
5Fu0noN95PQKNvoJD9MWh22NqaUNqIn5HJMPDHq3TDCYoSZ5UzsQ/gMqKiJus3fBkhUPXsGozkNF
YsgrjkHpDdA3JKIqBcD1zULiGIKG37MwR50i8glM02IBP6IcjDeC5GuQomCUxIKWIIW5XcQlySiP
acJLLsH0ccHakLTVXFH1slQ8OdC6lFIdIfNFMUQPOfIpXBGL9HM/vIovIzBTaVIQOGhGMEraQKfd
oP6+WfbcGXnQiNaPQ+HPgcJeAxgq7N85nZMn2i5TM2cST05M6r2J8YaFQOmNN6Fomci2JThrFG3Y
k9tB5NpwdjAuHCMzlb7FuCh6pr6YxLPD2xgRrIau4z0Rxxtke40n0ZUw+RHa4KNZcemaczhz6J+T
OtK6px2YNGjBdsb535gnqtCWcsFVrfIi4q4nRdGmTA+6DkM5H4Y4wHFHB3An9FyLulGstGsi7M4X
KuBwye2QHrgPEkjxs0C+siO/DBKk5TEbWdQVjt4JoxgRtImHzwLNB30Rsdj2hX9qP34FOGehrV1F
T0qnRLlE/I9tMmoNbeURnAsIfBjZvd4PY7J1Z5+CfeDJiueVmIta3zSx4THW5ZOixJnnFE58sIoC
jLDK+lCTGNU5zsvKsTY+4Uk/ZIMjvgrro6cIdHSLWeaJYoTN8DEnjCVFneqjd5GMq4cmG19jEfgh
6HRq5G9toxyUIhHOCN2iHIhqswWCPEpiW6LE4Lkss9mJPXwP7Sz6DsuOTglMHXIl3Lh9CHTAnYgm
cb9ilOok5BEyMEQI4XgcLwfQ+7jr8jSUFORKMJ/Mh5KhlgtLe/Zr7zY17esSrRgn2aFwZfJGSFim
UpLsdUqU4xIsV1n7vCGdgki2qj0XHZqQTUDBlNkhmf8AQt7ITkycMctHp0WvJ9jH3UmdzOwODZ+h
q9fFTexPHyWqh8EDNCeS0YiqVEKkY++g3szYoULliwRjD4dF1E8Dv8XX2TKCJjojxieiEI+gtprG
MD0oeOhkHbb/AARW+4nwiCSfsI0uaT00WvEeCq28DgS6rgOIRiiOtI/1OFxqrzRZ2bKn+2J/8HkJ
CLGmI22TGi8i1ajg1pXsbkwhXWQpmt7H5TV7FheUWOi0TCTtFaeUxOLeIZllmGYFEjXgBySDY9IW
WxnPDwKrkIPDhWjzDdHKU9yK2AWtlnTKBkyZCpiyw2Ccbx5Y5cm8j2r/AKNfwHlvRQN9FARiU72N
2zc/ona2eR1Sy9D3PgUXXDgT7KN7CnBRV3yZy5LWQtBBg3lqjS3GItw1C0gdRQzj655G1eciZqF4
pHliYY4g50YiuDGJ5oZJnaVqN3Brh/Y19gaiUNtj2vbRUlnV0N2IrwdjPW90Tyi8kZEgxSlBdj7r
GVXYik0htk2/I6zRI0xocv7EsyP+JG7JT7H7L4yyTNwNMV8n7Ma0vLJvJFaZFN4aCq/bLqmHc7zk
zZmJmXI8Ywgnsx5ovU39MSqmvcZ23/RhJHfRKl+ZkH7SGS0rbJODtIrqITNYxIweYM5bvobNvbCx
XMEM/oTFJUp2kf6qQ5vsdpA1ES0XoZMZcpCuZZeGWZVIkayRLIiU3wh8wxDMnshPTcqKYrT6HEFl
Q2s3NLnGjlx8Czh7QjaJDfT0JSyTrH5ItVmEMMzSrtDbENR0OrevAbpxqMiUzYlsG6Yk24i4TNpr
sIEOF6N3Lysjo2nvpiQi0adoZFDGCSE1xeT9kROvAmNK3oY5l5GsexVTfRuInlE9gxo8lg7CpIg4
XR2US/Rl+PEh815HNjJlRCIkNGvHGrs5WI2XHbg0aCyZJPKevhRI/wACO+2xNVE+1BiaH5JR4cGz
gWRrPwLbPYlnBeB3EEo4RBUWYOi/Ax46d7eBpcYIiFgg84RlDdEFEcRfqFLkxPwMxsvpDbGh8mot
tG+pErIOHiIQA6xMwbHzXAw3yQoLxSdIipoQXPIk6KPVQhNMUJV8FyBLTWWVpNcCttY3Jpojl7S1
uNjtpLAqDNvoSFToJcBajNKCkl5GBf0MrJ1CKiJ9ivbDpgCq4TdEs5nY+prMeRDV8cC0itjUYfZt
D4IbjaHqWp2ZtKGRxiCXV2ytCT65H0sRFjIn0rVHOcmAlOUhZYLDg3aRVMbwhHKiMjqXwhrGsdF9
IccEldeQYniCiiy9ClDIxtjgR2xnI1lb8wjGXtD3Um8DVJGW34CGTnMFWkSFYHEbPceukG47gqRb
ELSiS8hZpZh3NPco0KLzqHXI5apKcmympJSiSFplNiMrFnCMsfwCYyRCsRiaDXmi7pI/Jxe7BCRe
mMKTkRyTYT8ngoimlKZyBMhKxo8i8JmuUMnRIJa1C805ZN3HrI3UJp9COvQZOmO5HGZlRXbgbVwx
o+zNg4gCLXN8mC4TYrupyhFEinLW6IvG8PkZxg3NiXCK2bxJInsR0TSFuroElbAk8j4Sw42Y7cZo
50OhiM+LMHG2NVIbFi04Flp7Q5xd4RDVFU+BZcDw1DA3cFKsgYKdokNKoYBZGKVWSnNXQmJkcIY8
l/ibJFCrhiUVW0poX6iJ5+wrS0yhRbbzEKdilcCpWCIPoMuUZMEjiOj9+BjbGKJnJtjnAk4EFOFS
hJgGuRpWRsr2OSVgYv8AO9EinKMhOU8HEI4KKTNyLMp5QT+XwzxYoRdMIRJVzsdczNkRGmrrH/vQ
Y7XCgRmltqMSGXCQHTHI3BO579zEEj9iI7MUyJJTyMBDdgUHFLXRBTDaMqlxt6N/Ic+CZEwzs4G9
ZIvJj1yPZDZtoa6EkybXSMwsz9FXKNKkbH/CZZh0tEPtjW624MrRh5WPBB4gQxJbkNMcBFaTSElW
oT3AR3wMkEQvXgLG7sx1B7kxYz/TkI28GsciFn2NYH6JC+BLBgG1mUDsXEZaIsLFFfjBlEnAY102
DI/wLmFgzbBcPqJyFy0THOwuFauEOkdYUOoowrOhyvBsi3iL6ICX7gkRNiglJyMKk8XBrETENS/Y
pXjZEsGrwSxlGDUEuXnoxtbaMNvdFBEFJfViHKjQsVKCVVg+RBaKl0aWdcP8+DPN6jtJFgqqkY0Z
8nWxRSRY0LipCe/0EhKloLTLOdCnKYI4rbFaJ4ItkDYhbFmhMJU2NnBRIU9WFBD9oU44LoTPVHgD
9GyFMXr9hrJpuUJj4J4QliPGoQUVdkX63sTyEhjF9xCgtJp1CXUgz0wYsy1TAo3lsXIPMMQKoYo2
n9BOrA8SQJ6LVs2ZVLRKjf8AJWomnmIVSqFRcuBVmtDQ7rlkQqwIQ5n8A5F9CyDtIzYjkYjmDlew
g5s//wBG000bXXOdEd4CY5HFR+VTJ7He6kfI/wAH1LjsfEqEonyEwlmkLekLMidYrGNvIybEOiQt
e2LxMPQaSGHixO6l6GsG2mKjzjFES1BzhvyXp4P7EH0Xlh3PLlD9hKIdGRDSmRkFTwJz31FIgsFB
zHRyXOhVv0BKKwQk/KMCSgo+AMVcpLAsHkNzBTHEupk0U6ZiUKNJbyNxUXBQiCOHQ9jVJ2Ku2n0M
SobE2M+FNKj0XXisHFCVEhVqCJT5GKDqpUVlTngnF+UIIRdoIdkNyoeBaxVhEnWI3aQ7k2hrIlqJ
XoPC1srEGkscJUA6sOtKuBqvFKMyn6HKl7BmiTAY7mQtNH/BKMzZObMwXMhkP8G1SphBHRuMZXlj
tfgmumqYh44fwYmyVQyHoo7ZSXJhDrYTkfJfRF1zOCtjmIUzRD6J+YsjWKlKejOc5CIzwIkkpVIt
BMPTkS5DyUiVOL0TLGsgaBVDJ9K8j9BSUFRqQHa5GaEFSqmkciwiQy2UcSlGr0JAi01yHut4bafY
xPwcbJFqI17hUhzNkA24ZFEfNFuPO1BHsaiEAhWiFlH+nJwxOC+EeRkx7ghVdHpgW75ozMKLiK5F
Xi4FCHgW5YYZZXjAY7zg0kZVVdLB9E1htCklpmTYjNLl0K5kMgBMPs1kWQ46GRYLkYoNoWTNEXeq
KQlgQLbYs5lJbYlaWBzwBkv3o9oDW+HBxwEu2RaJZRZnI/pSCGoP8ZpmboTkS9lFS20PieGIZYi6
yhd7ohrcBDtHgZnS1kEZpeUOSd0z7emISHQzpDrVDgSyx2S0jBqqYGuUehgmW+AvNkXgfCmQ5hJm
R1PBTrsyGw+9t5Rb/eM0sFDSN5GT+xi6dEEGz+RMQV+BjvQh8DLeDNOmDQhOTP3MJZzyYAVH4P8A
SMKxVrzsNeudUzyE+PwPxsJpETtzhsRmntIIvgSOthyknnBX5BTwGHbwSaSrODuz+ib029E0JuYH
TAPaq9BEb/CytxDDcEIQlwQQVNZM2SVF81hEjkjjpNNvTG2s4Qzvh2KV/T4vnQYacsDKF2PXiOXT
SZXUuSYrPDtCI4iM12KqRpP4vJBCHreRq+oLZa1tI9iJ+TDOsZg3s0wP4AIcFEcgRjs4a5I8BSC7
KS6fgg004Y+0NHCrB6INbyvA1+7noqOef+mB9QipY5JobKDJRGU6/AuLl9CwTH3OsJfBsPMoedgt
b3SC45JXEcNI5NofTTs5D3zwgipmlfAlNH5E6V5BjquUyuj1hm24lkVHifAhMe2R5cUuCiOSEUUq
MaerL2VIn0LcapkrLK5JyssIQLpibWzbImfwZCwunjPukxMP6xcy52SqyLBgzQeGmTHKprQ9r/8A
ITy1ZtmuCYOSjT7CT1XeRsl0vQidtM4A1/4FqRlh/j/wainusRulwI4aovxX/g0GSUC9N5BC+2oj
Qsg6kqkwucBSGzSin6FTQwkmn00/o2WWUn6MPqacE2fT/ToZf4OGVq04M3UM+c3/AAX+pV8mHhPz
JT/+xGey7+ju6zkZJK6/6cY2/wCCwjWY18SPLniLRpuF7EU/V/6KUaFiIaNmiIlaVGLHpg2ZI8Cf
rgXS/wDzEs1mjQ1SPgojyeehjryph2kLb6OQoUdB1RrGqEPR1EyPQciJ2Z8iY+KaMosQ3BpDZs3b
s9B5RDSRtk/OxTy1gt3Ip5yLbqMAVrJei7E5WCJ4BePlPYryicrgd5THjXkJemxfjmr5QlZsxEzg
sKyNp0ISbmDVaw3kere2hbZK9mSdzJAxLx2RlN0nOLsjwRFYbPH3oQqP4Qe25yI5uh1dP6K1XOCM
4U0jNH8dXZkCjgkbkpqkPkMIb6DYh3sfNxC2Ks1UD2UClM8hFOQoz7M4YLGK28EgxRyyOXUGQbSi
DJYTH2xvl4bGM3kvwsnxcjnTcZiWFkV0Y65GavcAt8Rm6l0djfNpEG1LLgupJtkwWNXDZP8A+mMh
t3gW0tE46bplaQhryjgvmE2JLSi839HKzmSedi0MFaEG9GOaaGjfHYqfbkd06p7XY4K4C67iXCNq
YOAchoaQcgOoWlppmaZgbTtrP6VjCounYZ2TQ8Fbbg3jtUlVhdfDNmXZPStSjp1mGO/rDM7hkVGe
EM7eKJ1jZQo8CM7gyynjOUOiyzkVJ0/wSxfdN04wwGCTxojy0rwGFngRXsChpRVKhhppro3GxqIR
9Pfj4wAiw2lMiNWbDCfaouuk4ItLhDJYiLBibekv4Jx2GbnjP0Zz81bG1LqIjQNGIO1hJhJ+IVrY
mNyXFI7BEiD2eMpY0THUCqB6gi6FgHUamWkbTll3c1g7cl04LCJWNknm6JGjAwtOGgdvKEItCceB
OgQVIRI7o0ZWrg3YjYly8C8mVF5NsU2m2IW8N0QGAO33OXofaMduSwQraIjsmTfYXIyaRAtoqLDX
AmgZrNk4tldZIb5wVFb08mNvN5fgbF6ZTKEzn0RUmwBLV5wGqTXsQDJ6szLKa2hWxupC15ReESy0
HezKaGgboTFI1OjQMNTKibTkxDiNaTLMtQ0mpJgOJhm3Fvzy8CwEULjuU3SwsQ8CfMqjpCKpIYJ4
ROYEqyL+L/AZZpPtFikwFkHH+I00NTRcjyNBvBbsgS+Ql7YkrQuKO6FtY2LwhAmV59D4hsqxVdnF
5Em5YSSw6KKmzSSfPxadGyUEJTnAQUJKURR1URK3gc9jaGGxyZogpcGb4LhiOaMzTbKOjkKbvgyQ
6TQ8WpOxZEhmk3Y2wJZwQOOTLlxyx/tVkzx+HPLBZFjwHkasqJdi1bWbkue0WOJjoWqaMcBqpDZd
M0yUJa2G+RCeoiU0I7szkr0x9kshJC5p1oVdk5HC1X/CNqWcJvA9lG4SyJIk7JhOyuirZKCaGmL2
QFYtBkWhLfhoo9cxhlgiJWDfUuBAznOB7EP6D3sSiskQ16Dc32Hucp9I0oOGLJMdsd+CrYk4eA7u
iNWAtTkrIpwg6Tony9h9uBZqFOg6j0JRuEXeg5SoRmV6LfHyS0qHBmKoV/FOaySG3MbZTiW7Egtl
gZyEXEHciS6oyBRSPz+mduNCGu3o33fDGIPeIOvSOmmO0VTXlhiRuhWtIokFeapzs7cjWJUFiEwV
GiUsRvxYEVeFZQ/iIQrdcGZNlh+UehSSfgkGpEO+xAavF8DicvCEcpcw5IWF5GNKYIpFOVqF8agY
SMtMgC+BcxApdyqLpY2xFIwf0IJ6raU5BZyU16GWXY1dMy6WLyFPtWy6mB65M4YspPVr1Rra+IjD
KNcCaNVbr4F+AumzXwexhoYc9pYKxKBmvIbkpWQ+pNZKNa5mIkvXjBSMYk34GagYH6Q2W4YNRn+s
RKyIqQ2r49h9I0JiOvA9DJ9hdD2kEgvEeF+AgQ3Yci5KETmHdSpBStG32LSw6iUVNjIx/Zj8SND2
Nq2+R5EAzfeDMniVvQXkWzNMxLnVE3m54MT6vYz003KGreX2LFUwbN1UWl+BMUaVp8jmvM5E8VWD
A9lyGfafhqF2Iobl5M5AyYb2Cj+r+CKZJBXyLfE0xy16dwzz6lFXyOh7ouxBLatdiyAeLFwVu/CG
CV/c7LfLVGiOPNhn0uJN8DUDJ0NjvzyXmvaexwi68DAyiCl32dIRCKBVEyHbmncCE+GPwb0i1F6j
sU9bhPkSKNOwMxdYgPPwJxqAhrZiDIR9lYEnxL7ITyNqNz8DfYwxGLjyOirSajnQ0TMToXR8CnAt
9rfYpCppcGrqVrpHLcfAspT/ANHUSlwObXN8lC9hZezz0PbzHsBEHMOdfA2MbMMEInkXAco0MEXB
MEn4Fljx0fs4KdEuhmjaYuKk1lk8mvobtljVO+g04vAdKZ4Yhq9EdaeR1CH5Iww0KlhlpyWcMfGZ
tlQm2LHD2y63Ehpj6+0wNXHgvLYt/iQiwhhyFcGZ6oUN+hMaiFCT8hvqfkZSmJOOjKEKcWjZM6r2
MmMBDJ8nujLtBrOqzTVpcFYb7FeZ3Zd5F2n5D6nU3yMszok0Y2jNsfQ4N6fxNhOhseoPX+g3EafQ
p70IKdDDZTdZKpFWoXpvY6m2KU2GFJmGI2e0ZFpD3diRpbclceWnNgps19OybePTFnuLw6IzuuSq
TKcDMrkQ7L2xxS/oc2WRMblDwiH5KOTCTnfRnEvoyqUMrZMGRyIx/wBHcGJMo6pizS8M/wDOBV3z
RZXPTp+dBQyK1fQibUr0PMusd4tWmJ2GyfnQpeQVzyKmOzOzZLTsdh3DSK2J/wBhhcLHTO338PGK
xvVF/wDsFWaao2l0ZyVqfDmuT1K43h0OWz5mwb2Ye/RGRZ/JrSyjbDCLghZGtPtio2suUKud4jKn
DHUxzXhCTr+0JK2f2bDKOkvI3hj9sTXhZZJLh2iEd+xmu4+BwFeSF2OYGnhv0PScRqwtqtryx94T
+i005wobA8BmydMg0XQp/bN00Yp99DSvsBNvg6KfGyAPOhptf0MXI2VekMt3wJujuCpzgTCWRPsS
ah3EE2n5KiwvidmSR4CitHvIjMp0xrwX1+5jlnfA6wJ1Qq/dsyc0YdaNuTnAl28o9UzRZFk8Nqhd
cm7Ynp1bE9kKRtnzBzR0sX1NmBUhxl8iuj/LPstHehWxNZQ+opUqBkbCSS2MVRnE65NAvtmVUgmf
JEytG3Y2CnbG3TkaR2EskyQyU5EO8jMRrQ5tFPQyGj4HWCnAhrqfJCJockhjrIjopuA11B++Xg54
UwktWwc0bNZMvxogxasH9+KH/CP0WFrBtExosNm3gyoF4DNpIYQFhlh8QYMZGNTRjTEtgq9+h81B
UULbSejAFg1YvGG7Q7unlES0MBMM0WsYPGiXrItYJ+RE4pdFn4dzhl+DkwqJUJ78wobN1mLWNswF
VDSiYpBpPsSzTeB2SUSFXA7HqzTfQxNaQvo9DSC8MaWl8IY2QuX6kNUjLoZU1gXkd9hSty9CNtYF
KW+hBRNxBhZkMzIeNTNODnqZYpN0yNsREZG24KtpPKouW6hl4D7ZJkj6CvJsX7FdmTU3ApbwITcp
rCQmzQtxHohs8bRIp/UzcU0o8prBJmOxwYBiS9nmnIIF6/GD+kUcZHY9fZ0TM+uaGdICz7hnZh1s
eJmFdRt4IsG0OSK/QjUmSpTOSi3YVdBkqIJuqNwo4GsxUJqYLkQlEonR9CiBdjJfbdDrTvdYM1vA
rdjYk2c0Q6KFzThyNjVHkMgu7TFBFXcZ97qCWbONiAuYsdVVmIvl9R1bWspjWlvMDA6cb2j7KJC2
yMCBIuYRMGyjFug5HqR7Qc9jNCR4qxaNUQbZrDSHJX9hm6cC5otOF8Tlj7s9CQhiZVYIFFeA6wjm
0IVYS24YyByhVUnFwhRZ5ybA+hLb1QiyVwxiC/AkLsZPDRBMeIllwr3HkYFtqng0Ctm7CZgaz+gW
U2ykKL2MNhmsld1aSHNxHEXjsZ0aOwdZEf6Q+hAyUoCuROrla5NuG0asLyKefyyMVqBTwX9Mqati
DU34MZxTmM663VsTTeGRXe4myK1E+jWw2LmXzhNd4H4+FtQuGuGXvMZEybWQoaHEM+Ksf4IECeND
MgoZHtNeRnCa0EGmmgQty28EUugLntUyJ2U7CJwxT0FlhdBaGCl5pjNITxfgq8EbYqdt1SxBWm01
n4FrPboaeNCCECckGSAwlsVmAywvJVjh1DddAY5YozQK3A+YrB9GMk1bTyKM+C8D/wCCZcFznWFI
PI7PJyLMG58H0Gp8iZPR7hgWKFbFBWwTRgnsR6f/AIAffI30cPQgFVhCRLCSNJQgKTyZoohzehDN
ZQaUYTwKHkjHsk+tmMVaxSAnI8DcOB5eDnI9isuexPjEng7LHNVILOcsTnlZqErGDkNRA41GiXNs
mAGEYEXoLlfhbuIpl2Rgs8iH3BwNBioOWqObEChVSFELL2blFoWIZlHSwMRTjnkaSwR1sbaEkjH9
CaLYJUKzcL1p4TF8MLg559yi6pB1UQX5QeCMsLxB1VXJUeR+BYVI6O5Tg40mSGsMCdJpQQw+hJdj
QoRJEIIEI3PsxE/KrhiK1HNKJsYGaKaQky+YO3cB7ddpjOuKzCiyJ72wcoIh1opIZKchockjFSG5
zfA5tS+xUa3DEpqCdzkT7rAX6moxtrjuhBeAxYXY5oBohe4QglhKiaaqFWsrESXwQypTpnEa5OHF
aIUJ9jbaTHJM3mlIyi82MWrgLXMQxZWDQ4j0ECpnlseaLiiGrzEljsZxo0EXTFqjbpLRdKSaKedy
hfYnCQPAj2MzU3oyVHBg7jKdCQjTTEShvRnCsFCPlDyQprNnH5Cpkux1pKW6JhbrEEPa3Z02o+hr
LAm54hIYBXD0JRwHJLdCpaNP0LpzHFOaaRv65RCadgpJBgCMw+JFhck4q0MOtHGPzdWSM2GK5fEm
9RtjejFaHtPYJdz1MgtV0Fy2opamEFvzLP4KOhRXCFUcRQ7hTrEQSu3g2Ktp8i081i32xXTKsx0J
TEScwg53NUUeRRIeOXINiss6mNKy27rOQhnAEUQCfJK9jbwqgV8TZpkMkNxJMEc010MpnNaRkANm
Whhr4t0WbSUIqJnYzp8akKdG4fs5YHMpjRWb0SHEtK35IWbPRFgOhJ3Rho1OtyFeebEP/MYCNj7L
ZI6h+c3DlTKYnDd60KQOSTHaNmRMdKucx/0MAzNLVCVpwf0WKUKqZDkUvI3/AMl20bsiHvEY2E9h
6MITcaHH3En2M+NFTFE6WGfQx1jJFsFtZeic9vP0OKMr0MHDjkMCPlcGor4D8+6uBvSoyTthB/Qo
URwb5FYJvksCZ6/QgDVFDcxCMMVuYN/QxghsFtiGOTYJnyKp/wDsieQTsZDWYG6xPA/8MMoVH2OP
aRBKD6QuyL+csJbbwYxtUX2ARLuHQVtJf2SKkGiC+amiZ8GU8Fa2JrGCkdIQ61OgQupDHvMkWZFm
jl5gt3y9niplGTGB6PsUtPIhEHjw7f5Du2skUsJj7tD7gtwtlKa1lBilnkcUlwPyXh2YkK1Ces1o
6QkIfBk2kNRYtMVFihqDsp4HIf3BWMss/PhZXFPY4Jx5LbvbMS84HTiGOgxn5eR6oYBPgZoQkLmi
E6SM+zBS3RdEN2YQxRYVE4GSAMszpKarQW5vujo3RYEJui510O84JePkzPKOMEOfmD1tlbfoYq8I
zzCJh8DyuT0jBwL15QhJo9i6M1CSPG3smpwtCn/Yk6JZ74FyodaHcTCPQESXAuovQmxpCFEKZOcD
HeW4bdZawV7sX7lqDIvDzpGXCmRkviQOcWEmhGAlK06JsyRKdlDyFeQZ8icvoK9aRT4hbE1ye+Qs
Yg4AgOzuq5H4DEPHoXnsIT6Yl+Q8ToyuXQzYRpTmg+EDDhFGeRJvgTn4oIEcoZYKKqxRIltpD5DK
1Fol1Ek0VH42KQ5+8UlNaGGwLJbj/CiRt2gFZ4uKaVsU3l0PK8cMRR6SD0tsNGDKXEbOKPLEpLAk
yygPXzCYXlqaEwRLgqneAsHhkQkonbKr6UeY/wD1FoJKwx63lC6vyLoKEyb7Q8c0lDnLWhh3z8A1
JWzPse0kRoIWlYwMcajRPj02QZbCxBreSDvJGggb4GEJychDHWAxzcqi/eYkh20LXPChSY/Ipikh
lmicqag6y8bExT9cUhzWn8FjcMNousMw7iSD0F82voRxpkS/fPPqhzvWR9ev/Ap10X/WybDVDRgt
vMDf6n8Ll8DnXF/o/ioJfsR9OEjaxhUMoyFJ9vOBUZFaDP6N/BhIuRun0S6MtjoS+bHpJjA3R4ps
2StpkhM9impJZYtRuRGXrgQJSi2BZs5fgQnXZDHxRaXGwyyd3ZRujyKErkHl+kQS+jEd/DC1DvIo
18KXBcGT6eFRutByuz2bryNq5MkswouLsUhc0dYNiSnlFInsM9zGaTBRLydUvospxjmQfZZJYG1S
Qr6Dx5vLImLAwgxjMQn3gmQWYhiF4sw1aHJM0wxTeDVo+6zgV7TUfIll4GTaMamuWIZpg5QSsFkT
2LU0qwS7nJkHHwggxk8EH8B98lQHQ3hMeLrH1CUZLxHRawEMmzJWYOGNvIwrFp1F5EEbIL4B0bgI
OxlFXgaQsvAVd3kcqDd4HURExCzySms4MfvLPgWF4EXOBJGB4yiqrsa00uhnhNLyXbcJ2zmB2KeQ
l45gTzfgh7utj6GxO3kNTZMyLsWBF55SojInkGpZxtCYcHsOK9ELNNvjAz3Ae3wS7RHTjsHsU28i
J8+RJv04HyYgiGy2ITyeijxeQ6fhEZM7E4bQKWVnA4HUTGxHnYWT20WdRMB/dXBxoqyNcu9G0ymF
q7EGyGRKumIdspZKkWyJceA6OCwjbHO51iDqiSbGq0jFBtol1vNwk91tm3QzReDiMIju6EW02N2r
fAw5pl2XJr/geCaiPkrZuBuhD3za/QkIq4LKbV2G+ivD9CKuwx5FoHePoPu0CNpkx2OO9DyU5ERE
pFaOMGiPsNYmxohW5oWB0KDviKLFwmH9eKFQ4OeghpawqEck8obrEUXXRUM0FoZjUzeCDF8pwfJC
Gpq450SQXKmtPNBfy6GhQ75ZpYmgvZsAz22ufJW2R74FbaeIYZNcGkysDLi4RsE2lS3mCoeVkOYy
dh/GqkJsjd4K6jx0oVWtMieZ7E82w3SdURqaQ8wf2xi3vOyYnGP8w2xOmGIKY3mY2YJBu8ydGCwV
nWOKpvYojWUwFPyQJ5DVz2a8HTTQx8yzaM5uB/RLQY64OuKi3cANjbAoYLep23cDYrjcI+052RBT
fUS9sMvo0dDcNmh5eEVm2TnGBUnl+yWwhhccQpkS1FFJy15Gk5xHkRQS/mFCSYpVdohQFoy4gn4B
mvAjbk4PsNRcumSODNxdFEYHExtr0aKjYTjsbmC0QbxBXUMURtlBYbhnYyxpJIQ7AVG2slCpGIj7
jIvPI7SryPmQQ2WB4S6HiYyWYYvKdFA5G/rpj3XYVjehadipSrG8JBnnQ1oaIxQJ5Ntt6FNNIYCV
5omD+hfdl+RYBo5AjLFJ3JsfkuI99mDq8Clt1eTDiAmx8khgENoLueL2MrajGxQkiE8lMBE0oI6t
jp0IKgKkt3BzSSQkXBVmqMfqSQytSsyRXOLIppjGqYmcfBDXOK+9jgQL6ZjX6qDeKS5scFwE7jhR
jwNMlGEITe0cTJA3FRmEYW6OwSjQ+fPI9LktmM6uRvMJtDLFWOyt6sfBD4KBMTIOaILNLIhqu6TK
04KDv5Ylwv2WCQSK6PI/HTvw9DHRkefQ95UmoE6Qqfw2V8KxC8VqNMD7qzzQlu62RKlkMduzaXpF
yZQZKs0WmHydPRTUr5H2khoongn38CXJLE0KdBZGZl3UQxLGhmyTrdE3DzZbSbXA4qvpBO9lsLNR
MQcNIZUTaDQ2nYsjW0NV7IuU0Vl8pQ0TFAhiWx0dx0qUY9jNt5NGJRZOcRWCNMYzwyzkmrNLJFXZ
LDO6ORixkHBrN5aG/BrBTYo5S9nWQYxZqZsgs5LlOiNsyQ7TeQv4DkKHRIzarODQ8XCImC5HG1bx
kwFjDELe8+REhCJLsW3tsyicdSbGJfKPwJwG3DJaTjHIjb24PvTkPujVRQ4x2Z1DcZk9FSGKakeX
BjAd50PstzljOBhE7sKo6NmbI6JzEcR8kBd2GqpSCbndyE+iTTuhc7VjIXSekOoNj5g9Ry3/AAxV
zt0LzESIgTKObm32NFNDZVMHL0ug6DXJjutxU3JQlxEzngZm3kfI2A5LdkGNde5SPlWLhXCLWhPW
2BtbxEVXMrWxhcbLoa23c+SAcRgahWLAoNG7rl/HSuasE6hk73QgzrORLbRzuW4sFNq9j9kpQw5J
gxsRLDDvQkawt6cEOTZtBjmxBIb4EsYNfLL4vVvZs+Kgsm+iiyKPsd/AHbuvIkLhMpVYszaU9n+p
Mh2KZmywQNieESpWkFEu3kxm2BnXUMY8nQZlso2K/ASFZzfg+hERyMtmbktbKelE7pwTOfYwP8Cx
+pi5Myq4K1PRHl80XywL7HZNnsQ39h4Ns9sUWm8eTU3OGZ7UhZageNbLcteTMck6NwhUdf8ADK2U
UCtr7CDLaIAxuowjeSo4tGLHHZLtGK2xf1IrrCxRgSaGZyLa09jnU67LJujlNm0Je17K1gIjJnZl
Z3IkkxtaLfFBj0nl8D63ke5KkzASomTW+FLpNpFVuiMo0CVpshjK6yneDxqPmj7auC0CfaObUSrT
Qt0S6d6CyoWB0vuu87GhaaoZe8uwVXIz1TlMUR1D2wLsJoHmpu+EMZtTHd1yXZWcqF02jLIyUiIF
nHuFFHW+s6HFMNoqDyJmoziM0eX4Y4MneqNt3HyxZTJzn4DcQcLgIp7eTd15HUWRmvMj7kPgjeDL
p6tEKkxj2JkTsHuNu0fsQVMscDV0tlC2C87jI+Nhq2NLEeB5wnI8yLU1yX9JEh43Hsb5Gc55FnP7
GSkWOzkoqrNevhBPdRBHoS+B0kZR57HcMlHRhdXrkVaZaDHZHtm8dHI6KSdeMIQmXsxJs9sQeVXw
EVJ0nX4KkvZnaGJsDfBkJ+Qypd8iawsUnZcinaGOWfRqml2YhIzmtlCiCTdHEDxl+BRkQVDboiEp
vj3keyFSKsG51RSPN7MvB3Q/THsybIOB/uwREmRFcnkXYDwNmYhaxHaNXDHzAcD1pbZNyrsa4HlF
UouRnJu0VqZ8AT8/0jKiIKaXLF676G8eguiWrzTKOJbKZ1GkVlHQuhk7khm+b6JmcRBDBRBobEJU
T8FaLXCR6SgVXjJ1ZM4UWjYWfhoWD+G2RFq+jyGokhWdFrJZ+FCgdgcUxLA4ziAZcSFlVsZ/sjRo
H6DEKTIeKouzenpm8EECLDHTBVTRMfF6EFtDfYmOxamcEqJgQrx5L+q5GRUjSs9HGam2QftzCIHY
NTZyzHsj2mIcuMZdfggQ8iG/0JvCV7KDaXgXtDJJyIAvw4lBYI8l/Qjn9BLzSEVGJTvC6y19lRxP
BdxsRPrRcZeiKaFBNeCq2pgPeh2MXaFOHpR1RpDgRciEkkF79FCDXmDFUmmehoJF6Ho3h2Ll6+jU
4FyB/AixPC07+Ie7kTDo1n4NiViM8P8ADMVlyOqZuHzRobkOHwDOjHGQ2FyNBsjKH16T0Ju7MiuK
eRGaE5yP0JixvAxmV2hLE2/oqY06HNbENKMzJD8zNwKpbqkJDy4kJtT5NoPpBnKUKzc5N9hYndoZ
95koe8KuBNwIj3NiTpeBpGGaUxaBgrT+hz/UIxORJ/MZ8HKz08BXDIhYL0VFJnhEqURcCRQB1J/0
I6YM2SFIWWP72QSF9mxhhVpIUqeYqoEVAXorpvcGfBVjWmk6FWjvEQnIoE5bGihuq+hOTlWM+/SR
42ikcuU4sC2QNaQqzE2MVtwN7AZREfCvsNexOhEeTaMSHo9uDsReEGNzgmuhRSvgNui4FWKkkc+x
JcRo37aC0zz/AAnHlvVoxYbdCn28hcnsQxLoIKgXeYXP8hfdU4YoGzKaDfv9C03hw0XhGmi4ySim
/YhG3bcoZ7wuEXgkAvSEsTpV2Q7ibCWRcK7RCgkFbJ4eB6wF4PWlqPLQBkCXGOB/1bCpNYgXdfeh
0X7MbWGhQ3pdDU5YnoTgj0aZmuUPHiyAVbC3wEPpium3YIMIkmxToNoK/wDDwMR6S0YnVGmCttn8
jklnma3IS08z8mOP0DWmcwjI0hKEwISkMJoO0VwFxpUtbYwotxNBFibWsi7MSXM0VHwrmiS6bCFY
CSlWokIa6a8E0l8iOrm2kLwyzIksIxbEleMNt/GkqmSvDTpyKoHRBec9tiEHuIyGDHk0UXsPYhr2
btNGMBrLlEIfZV0ZOHJEOwG7w9D2BoeY0YmpocqOzYqZ12jSCuDHV0Uma6E1tUMUXMELppiMpULY
1mfIPcExWm8HoSs0QYbx8Hp1tkYKRRViVFz2PoPoWQqn0aIvYUJGgaJVNkAMIREwFogLULEzZ87M
T3JMCeACWTBHcJejBgEy4+A5GkN9OxmpWoJstEZ6EiiIoUXEEYlE0P8ALRFWazCH1uGhk64E+Ekh
fKfGBGSCVZZMXxdHgGYhLjKHtbyLSXsHpCzseHBdGZT5EdBpZHuUiRaiu/hAw/XcM5QY1ZkteLkk
U7H2wwEH/Ao2TeBPAhxLCwa5WCrNtCCmyyWZQdjU3NoS2weAi4gNoXgbKI1HTCNUsOaACHy2Kwti
jRAnNTSWMiv03wAqfF7EVz3kansurrZwXLKfwbgkD1FFoeCmh7THG4LU2pBJVVszlY8GrqlSQJXy
xGmX+mRK4ZXREYSnidge2tnr2qPYnpFQLtBxlFyJpLNUp/JZDDmVBJXXI+VhyzTyrBZbFf4OZBpB
6TexIY1oqR7JaFoldloxab6GwWWBRkReSumZaHNrVwbCbMQf4DQwPddB9SnobXhBlFQrskwjeVui
qrOUEseimbMiC1ylwLX4AlA8Q53FOVMY3QpYn0MaDqCQkljY+pzRfCaPA+CsRRLoYiMiMXgIJTtP
+CKrRvyLEFtxtu+iY+wtJNDczeF0OL3RK3LAleYTwVTM3Pg+SHktm3ynRrNZgZsyDg9aUnAkxcH/
AATE2HbOHcFvzJCC1lcNBkG9NbQm8yQZqy5WkiSbRGQ1gM3jPY4RhUe0wvDjYy95Vg4C9pqWgsCP
+CEPIX4sWHlPRGdahVjnUdFnG8D3LyNUYpfYTApwL6Im0hCCprREkUSYExFmIPMq5pvgcZMikZ58
DEoRdC9LV7QoVlR8nWWWiyzNrRKqSa8CFnlozfXDkw9UPUbJr6MaQOswStZMNZf2PfZszRbD7GBr
iI8WxJ9GdrwVk1jIXKq0z/pGU+QZFnMMjl4TxLoSfTRgiybKdJmIcvIkwwtnJpUfw3fIkZX0YW26
LoHE14DgPsNy3vQh0V0UrLMb06EnAtQXV5RaPQTGrLDbGUNUUCIltcjEk8hyAHA51CQ1hm8mHYXY
8cYMudfCZFhmRwKNHnkiApFCGrka/oxDI2JrhNDT3tGWJaFuoKQnnA1mC9esmK4QFVumQ2JbNFq2
XAdE5ZhOIZLG8iMk42LQl6MFR130UKnuPwLCEi5i+SYFnODG0UGNYQ2mdowWsMr3kzbQmLCotXUE
02c+IUBJR7FFk0PugYGlPRHMZBILIthEIuT4FbTr02RYl0bqH6ZhgqFXkT+Xg4/wMvuFH+RFWNCr
Fla74Jo5jAS5YkzAVqJwDmxZnJ4FSl5MsPmCbX0RlqZ6JEGGwQ08E4NEGvI4xryh0aehnXLlMShE
WWQF5FaXIg5PjSu9E8YEuJ+j2q4h2EEESu5mkV+9CVeCtuhgMz/TLvYc6S91JmCNQENYYFO6YmqJ
QoZmjxEZrwyaiQtJESbCVUkkb2UWEOJyeRSzPTFvZVo0W4RRaQzUbWBlXkyF4lcCtvmoU4F/g8eU
I7VMC34C0/sVujQmIRbrDYtPlnAieHaMXQaH5xCUeKGuGURWhy7iDWPaJgORLdEIPlj6OY1yJqiM
DNHBr9nfgHjFIMkubFzq3TLYNlXFcrpmMMQIFa2J6BCchE1FIt7Ci0TEOJm6LU3DE7UVy6SmpNm4
KUNQmY9Mnkyx9FV0Kt9VkGSt8ENvCL+F4eRqoYrSwmLPiVjTiRJnQMEO4xJX8FdsZaGsupdeRbOu
wiGyDeqxeCkbHTqLlEMOFZhCxaNMWZQlKtBcy5NOqtH7M4cDV82PMw1n6ORTSayhP/p2OmnhUosC
N2wQVzZgVuCESzU8nGhA6R8MsOuj9GKWAs92xltqg55Lwbf3HJuoyBqMVYxVCML02LdR/wDuNWDM
r2psu0cu2NISluv9GyLoapSybeSLIlIJlKmoNPrqTfk3H4BQmFXB7OCHobnNh9ngNBLdKJMejZWJ
W6aZNmIIqiGr8mZOUXI5wIJw2RTLwUOcDXmMKA5EiTW49/HrZTg5MZCbtZWiCbyLs7CmjvsatjQT
nBm/DD2NBzHHw9i0yqfFl7tBvhJ0YUijlKg0qbsHJtcjCK8KD7rqCksIeAFQejyOwA8PRQenoYxa
BUTVZCYK26cyJoesVlQaq6dDmxr0Sa+cuttvvghtJocLdDEfeIrrgxYrEQXi4XFZn4nENjMezSrC
FPumRYPReTdCued5FlOxj6Jujy8S3r3QcHsuCNdGD2FVGK8HUvQcjikQzsY8GIyGKWBVHn4MEnfk
ZjWUjeRUkPY5YzQ5OIPotm/MEJYoIV1sJjZ4EENb2ZnXsYSUDto2jkoLW3rOS9MuxQvCWC8vUxDP
NUNZ0nkZ0Xcig1qUUXtuCYrjaN6cfBkzkiH3iImVti0Y4E5JhwZZLC8EsNLOyPoDJk0sjds20oWe
oTxJxERIjPZehJPvJvL6HvbqDHYxwdHEX9ANDDSf8Iz6GUEkHjKpNjyq4GDYlkYFwNyMzEJC4zUV
Fh4M3uahiSW/B4lCzxeRWxvSZIzQ53AhoIycrvRljKyLj1A8YnQwHa0IKby0Ok86g7rDaY6ZmRcT
NLS8LLyM6rR5E5VtRlJy8maKDuEOblvaH3gHoJttGJu46uUwTHN2ibq3DKOViHBTZh5Gq2Lc8gfj
oL0KUrIq7TZrPQ5oyRalJumPHSRXLaTAbsDp2k38OfiGBhyNXgj6ouRIRJ4+hSj1COxXNiqFNjHo
jVE0PMgB+l9YzHhENp9sGMIs49o1YxsEpYgerZFvxFI9uIwm1eOkwjkXtVEgrBRi9oXBhM2asV0m
5kH04lwFkBa/Y7uuLoeVSnEjGwRDM8tkYTZOezS0to4BmfTMUWhSnTyCYsryZl9g/wBwhkY3CI/P
RK6NTl1Me41IDeJBYpGFgxpGhOqbW0FOanYqBWosvG1Exfn85CNcxODI08Z3ontcpaRPCp5bhbfs
N1mlJV2HBFm2u2iwEVxTorZxkPZDEL8FhshUHhkzeDa7kp3o8DszPXIxeqWS+cyLNDyZdBo2OAXZ
lRag/wDp7KBwfItRmm24HH3iD2TIlbjJeFlozzYT/Sw1LOxwdcmTXsdBqHH/AETiyKsWKiMxKqJl
pYGYssSXI4Ic9pURIgwbs0lrN7WsiiXLEXcLLIKaSs9iMiJuGQboXYKm/YxBov2weOQV0C9oGLSf
ky6vok9sCl6dsa3hwH/6guNOamM66BZcmSJEKSRgVI6zCOmEjJIySigqvbA8uxCFDLMYE6F7wWJZ
JggTC4JAmi5K1EOk9h7Tex/R4glr2jHK2eicb4JhEqciXQ01USE0Mw4f027cjjpFrVyYkuR/csso
eRVh/wBQl0PIm1wKsJYJeeR72ePhAG88DdgR/wAMwO6JpkW6mIVCfcdYxyPOQSIRMXRbCwJHQ5Tr
mjXzaezA3BHSU6JsBZW0GVspYRjSaOIl9iM6wTkYVckTLb7YsiJBpy93sSGvwJsLBJhDjYxvD+Bz
oLgRaJvsyrybWR0vRzVKD8mmIJnUH2qTyweEQFBVE8jUK8kkrSISVJ5CuvDzPiEgSTASkNChNYhU
namMy8NF9c7tMR2sKsbsSQs4zyWfbEc+xPBmuB1F5/wRQcaH+cliMe8CspClw5li1kuqhabaWGb+
avkIqpbjIe2ybRrZnOu0UuJXRoZLYI81UVoTE824Nqi3wieGiF4t5L62gQ2dKoysx4JV6yasfSZe
InGdaOgeCsg0jgtaitTMJ9eWMWhoOMlyQtglLwbxCttjYqaeBtbauBUYSqRFydC9hiSn5DQ2+BF2
PU2yhw3ZGNu4Q9sbXrqUoi0gqlpZ55EBlKQrE65HHrS8C77vTHRu3RA4dZcHMc2VEdVJn63Izwpc
ibUKZHuHPIyC3yUGCm6DkMsVDhTrY4Ed2mXWaFBqpBdVvm1kZfV1GNTL7FEkwUgxrlpDWvW8skOC
ryNO02kO35XwHA9I6CSbu4Xr1PYnfsVtJdw4FC4IvK/9Cc9NFJ0Ly+Q0pHw2JjMVgypJvky0V7Bu
obEkdMT7F6hY4MZV2orsVMOjprowSk055FKElVOSIPZc/E18YPLMNGXAjrCGacUMdibAjrkb8le7
UsUksyZtG30haypRzgRMiXPI1Ot9IaWVR+6XoRMJwKdKF5duRMizgdh+qNBjXxo6WCVE2xaHV5Mw
5OjFG55ilexc0mCnDpFso0YDmtyL7TnAofhHbI01WTGuyAW0ryQKUngMJzfoW26pkmn4A5yLwkaI
ITptpls9yHbKclUD0oiQsH+ERjS2TejCL9n+GByoWV9BCU/ZW3slSPQzay8DWq32Z+Toz2iJgI0I
evhUiGi9DGpkFPoG2XiHFrAejyQjbvnkf8DgrjpC8qmI4MY35GzfBYI538aS3si+0I+pyaeIeWce
U5sqhzG1T4E7KZt+GOcmk3ghLjMqjhsTYfaRM28cCxO9csaV/gh9dIYubTFvkueyJ8ghuGe4EfKL
F7I9qPx3PA1k68wmXgOCoY8ebH5PC9m5rqkiuE/c9ITOuNnS8WlQyQZM80o3cQaRnpmJaJ9MclsR
StIegGh/fhiV3VIaKMWtsFFw4QdFwZUc7rqHq0bCnZkxLRvHpYb1sarh9bw3v4DzvJdodiNQtWDJ
argzL+jUfkJD42nlIM1rJZCdD/TyKXyhe3n/ALG8ckyuDdpjG3CLtjOszyPTtyKz0bDPS4bQ8Dkz
vtJQmEBuE17E/wASN5v1g7ir5HWjMWU+Aq4rOg8dH8GWbdHKgI2wU+dRv0hPJ+2Mfr8htfpJq1eT
e55FnkrhwYw2hflgIzyIJkuklZorYya0lLEJPJjcq14Mcp1yrRJOLMZjlXLFW4YRMvsspF0n8CEN
1tCXptdic2zMBBdUewhcVPBMEyc4Myn5CCY9hRXIaTB2aH/4Q5qip5Z0ORrSyxHrHwZWNLibEbNi
NG0Bi3An2iEOiZLFWLmn0OC6u3NCbAX8KvDQ0pS1gT/ykZrWXgzxDuTpwgkjAk5VUYCRl9DGROTF
cUvbegy+8PIbv4JVDS6EH+lDUcnR1IhWmQ3AshYIXF5X8LSqvYrKxMYGpGh0ErH0lXQ3JLg/4YxH
rD4Fe6tFuy5GU2I2+KR9aHutGAmTFMsydjA2PQtjrYvwSUZZOteywxWWTJ7+5jGsoW+gqozTEbSp
agVlptwQrofEq/A7Z0VMQYMsroZ8CyppdlEKjB5xFl+HrA8uj5NYKOeQUlJMdOBJmnkxufkZWLyj
F6CXN7LLNvoZE2Q2ybBBWVJDBsEVPk0KmxshwUIM5OJGLszfTwNWng/kEKPLoetpBSTa4VC1tl56
hi3ahlAB9amNiwgibGoLRCYr2xAWTkczBRSVr0b72iUD8EW7kJTXlNr2D1hB1YceWJb0CeeOYcnD
iJy8vgfEsD6tHoUh5nIqFhwCrUuSA0sMuPEigvRC3XwMnD6F5wXJXeTYtHUsYPQgNzycTEYzAeCL
Im1fQtK9LorVt2kOqTvJiI4yYc2cjwmIKmw56Emi58i2JdQ8NFYKJarBiovouGz30LKCkqKLQjuI
iO7ItOOgyrPOBP2iGBp1EaGLNCI7K20MC1azgeskiQZuMcEvKSOOXCHSKjJ17K+AaHI7lC7HnKFy
+EtCcywVrZEMHhP4QlGJS/tBOxiS0mlaSLhpmGVUbNbyQaVG6DkzFKWo0MseOUV1+aQrXtbYRjH8
mXFdwi4mahLYuQTjTdjayYN2CitDFGnlojOv2jnG8HH6hWtDZr2uGxsN3Robao6N3HkXdsENTZ4F
jaefA3Fr9HoTbNVsthkIZBhvD2NBOsRjF5fHw2EApB1dFObY0SlMyuFCzEL8ZUFlYFSEVyVpDDRv
byISbMCUs2hqw3mIkTnsQz6zHY36LD7CYmrYl5NDhMa1GR6bTG5WkphzS5uD5V18oT1hwnI6sLeO
zuAILZGr6CD0Y4MgU0VGuok4hiYRWCIMuBC0p1vNQ5SGngllicqSaiMddDBTG9SzJJwWVCZaToZm
g0UtEjTr0wJSpFYMylVgS5UcSJKgYLbOtMKaF2SYbwPiZ0S6H6D6Aozgs0bHzWB6eqMGkPKaeyDr
F5ZWyUayUVI4DsXbrv4ryK4PVlKOaxd8mN+gTaeMQRkkPPIIGZEPAqhI4FShBpijWsWzBCzyh6N8
kWKMuBDy5KsqjFg8BsJ4yZMwN4JEVtmQtik6p0JBpRdiUlFgW2j2aaUQgSkzGNVvoTvIKzPshiWV
ROnLAiKLHBF8CYEC0mJLhELjJJtmaKrhD6Z2s+AabjkonWA0iU0J3DE0KXuKUTBhNULCsw5sstjO
lQgiLk9EFmKJcDcq4+PAuOWB1XVrGZ5uFHPFSwTlYZbK/JBlF0MGqykLtYt5NWEJI2Wx3yVF1M2T
MEp5KjJZ4N3UuGaokkPaiig4LsrS6Nkit1wUnxKZXq0IMW7PA4qeIkKCkpOWLaEvBEJUbcH9tKRO
CvmDfKwhZMrgM0zQu0sIixjAyS5sScWDUrLQZakE2WvmDei2eQ7lHNGNLCHDcNcD4gtUkEuaw0QV
izomfgltILjLeWhWTnwaVoepJMQzE6MNSBTRY6CXEw4ZKk3bBvU8GC06tGo0+MCnFJwIplfoT1o2
+SswA1My60uZ9mDeXakYyo6FVm6aHERzTHItFkF3ItF+lSH9DGh0Bf4hcmg1BaO3KSG8wgtvJXI+
vGrMl3c0GqeFoy3FWT2UYOKGVEhiknAP/avDJrzYXwcRjDSdCmNv1gbynkacs4FYjwxincV5VZzO
SpjNy/jyK62lFEVSsj7jDs18ybLs+4RJVTwImzWAxU3HZlGLhwXTCfonCctvAnmVxWZ3TCG/zqs3
GTFMbRkObc32L2qUgvaMWrbqOikeBi5AawmtRRGQNbcGFBMjsLaI45mhil0hXIawz6I1SjZEB1ZU
HPUteRwS6sEppXhzkS2DOBmKUjzT6DqjYMsUid1E6xedNcGEnhLSrNQpV/gxGOGHunDcZgC4f6bi
mmUNSOzFIIeJEajsPdpVnWS3gJpZHpRvieBqEUg/RtWxnCmD/pF8F/yPcjtli+jFcnt+msaozgon
bdIZRrP/AJBlOTjgZ6pVuMoX6foxLhzSHC3BluQkie5f2LJHJCARpH5/9Fa2pIrOib6UUV+P+mmE
Baum6Ijf/dDXtpoxfi60NBrJ9GujAUhTLOiRobtrhGMInpcCqvMGVtFDtUcxG0jX2Q/yYKt4DxYq
pTP6KukLD0MayRjGDuP060CirA1fhMjxoPZtjwN0V4MpiXYn24/jq63YlFX2YBuExcopKghQ4Q18
VkFMLp42UPA9nyIVjRpiHvAkiT44Gg2SuCROEtGs0N7t2La5N8JYSFRS7JdFANcagp15Li4+Gpbi
5ztluiDW3nQhu7PC4JzLGOZ8icyP4iabUooejQOC7gafxVK0cOhUTWgpL4TOAS9AyUllIhTX/BXr
HRKaOkmLnqC3iWVxaIQRUuGKqGIXRwd8leJD1pWSy3gRmIk7FkrhwcLAl1ZBcScF1syYKeTGkR62
KShH0o2tr7+ElhQXgIaWL0LnbAn2EdprDoiCgL5i/ACk66NViVPBicZQp+BF0vkVOQwr6Fi96E16
H3J+llb+K4sSmGssku1jAhEvAdWjo2QzJEy9DiW1qldU2EDJsPhRbSHWVNG8iDdVImy2YM7XaUe0
hLByvPITOhGQ0G5sxAqVF5NtvpgRUnCaLlyiDjNVrol46poCVGyhHSdcjlgyd/X9GqFyO2vscyNF
NNhKQn78mf8Ab/DV4ogbbGWjVeB+j2fa0PXSmuRYA6OZ6LXlMcttvETc8sogKmCJFHybGZSTTxDF
yt1kaCBkHYh9d0ryPp4Y5BeZye5uNYlDHCmRlGAuhxOmWdMUEr+9kP7yosNNiVJNtCoGUusZD+hP
hxj4npKVg7CTlWEmOqXY+hYmUqvBz5mfoh1tRdHX/hi42C6bxLwPFDa93R2JXCSIZ6b/AAQmOl0c
T3ks68P9HseP8Atrlh+hg/EpPn/yEQ1J9w6XlA6lf/pmROTupeTOvHIh5pU/0R0vr0IbqPpGLWAw
FdtkzPS7hszHDXDPMI/0kDvpdZMOim/RZcNP9Gq2fA+hdu2TQ1ZWIG5234JyMX4JWPL4fmK1ngby
JWTJHnwmIS20KsYo+df+w93gkxqDFvO1IYiZtHbL4Eytg9YBkk9Mciuuwwe2hgwS+iE6vbJf18J8
TI3n4JDZXRZL2chk0yTfxCPT7FfJnuhYE8PAtdfAlJuBfpmnwGwb3DllsfGWCNGx5K+2DLxoV5Rw
SeYLBWMfkCfwAWZVWs8iCmxdUzClORMG9FWPLQpWNPgWjwFcWOtoaociwonFljcZI1eRgV4F0SsY
gmmBoYq7bgcb97GlMTnHIKrRJF7HkHloXQuxlsHB3aOc+o2MeGZxsiUuzMNm8onW69USlidG1hgl
tyM5UdmU1OxDYWpZCuKNCqGM5K2jKLlkZ8RDmskUVz4NSqxRWwwrQ8MXFnL5YiqG03k6BBHdv8BF
cEFR2C5IZVqe+BSwZQ2ck6JeDGxLYc31E1DSQgtyJUXshqNZFl+BBJ0bSrOEZwlgDMnKF1DUwb8u
iml0Z4K6PCgSDJvQ+Ky2NjONDBLloaMy6MYQgvkEmXSJ6F/oh63SrSwUF1nKJhM3Q4f/ANh2ObkP
2FFXbdBGZJRCP64YEIYwUFZpFTaFayNiTIk5yX2NEEj4UMrumaIeswV0ZNHfV4VxK8iUuUTUsvf2
RTx030lwxVNo9jmeREGq4Flc29PwLKCOJlPEXlq16IghsF6Exfhri8kIVducCTjgmmaxngQXh+Qv
ikX8rZ5ntbNjjLXNoEYBsW+BCVhsLpy6aE9OIENWVRUttoUBxADuMcwZmwlVePikMAjVZC4To7Ku
DaXCwG7aYZ6J3cq2PnwzfQ2WVcH6IlckkUrXhBwWlsyIECm3yOh7YM9E2xmiINN9lOaWKmI1lEpM
TwkPyOsaoi8BEVrGRjeVmbI/mRjutPCcopwsCsWEiTmMzn+I7GhscbKJ9CqIS8KyICFoMNJnIByd
wLaTcQespX+4dTwlbi7FNEyR4HtawW2MlptlDkawkThC3YSomuadmaETItNBKiBiSUMipbqWmNAQ
5ROBRR7YH1waPKRnRmtRizywdOCiT4aosCixGMrGC27BvYmsFn6JIx3yGwq1OaBS2R1DQ32kyUwe
ox2hrAWJVbwYZk0xxWEQrRFRONXwKafE4cPIbnKQOkzgi7Kz+HwOR1klJ5EmOHYWxdIyV+FDdIaS
w/wSR3KvYqK4bEbVGfJZIKY/mFDCfKGqCiHrc8mIO1walw7MM1FNBPyYw72QhiBaT4eNjUmJtjqX
OYpPnJKsoXYlKWXsWkPYqwol6QXhC1kSNjnUhkrDJTGnS4mSEc6CKqr2VPB9hL1GBLtgxJpy54GO
M6cpVNPAxx9CyAh09scpZvk/gwRi98C2+lkfqwITAshIqt8GPOL4sbDHUppSE4OiWoX3HtsEJW62
bMXyINUEQRU89LJM4VckWMC04w/I8XYDbIhJdUF9ld4HqkyFMqZxSsjQqmRS1j6NKTCO7WIyLCFm
EFqo3ASPCCdzBm0aWTaQfFX4L1i5MRFwRmgcDgUW0bG4moQ9HyBIZSc8lai9j8no5iT2BNVKQw2k
LJxZwPaptwXwkKlzL7MCqLnkV1pBvC1Ry05RVRC+I4ZQoyfAkFIbyiO83eDS08kVSJDijoczCYdG
BbbRO+uQ59Mlehb7ALvSm8D2G3VoUzoUMuFRiEdpZZkGj7Q8WfTGDBQSF52l5M7XMFRdg8iOXmHK
SqS5XTudHMSbpoBecClpElXK2O+vWQnbM7lObRcMyVwXo4MMD5InLJUxcce3o2d6ML8NIXITtLka
CJa6GjROPyNEaVtLGrMkfFexSDOUJWWjVrRD4QpgmSYn0XRPVnAiM57MaG3PEGDUJKFNN+oajnRl
GN/DBjEtYZqg8RiAtnteR0c6DDW+DlZC9Ga66GDSqZojfocplvseW5ZLChgWSpUNIu9/BRRRqk5p
jhTTG4RqQ+Xnkbc66DZB20ekahNhnmFgTtXgp/LFHkfsHHUmQsMynTX4vobJzYxC3vX2Y0jQxXLd
jpM6voSYuGNQogLlauKWCwxYDkbFj2W3Ymi7VML9biDXO2rZ7IMjvLwDGylIMXu06OFG5hAr+Q9P
YxS71CBItK59l0+VfwbEhpbLmDx9jVMmLRxDVSjTgZ0vgi5CFgW4t8GiByiRDJaUI2zE8SW7F7VK
9tnCwcvkfYZFhDWRSNb4FV4F5EbQx4EOG7Q8PkPRdPgmSE9jTK9fDcMiHvwJzQxsCXKa4M4ztFGb
b3SHiE39wc3EtEyEzA9iF/0ZtoumryZk32Gtd5+FBuY15D8hhYgEuBaIifKZfcR9C4E4De6w0N8r
ij1CrmlfNFVZJqegZrt5Htu/olTJLGWL428qObRlAmosrp2Na74G2Q/3mE7ryGnWzbfqi/7ajg9h
zZIXb+4ho+w26ZMQlh6Y+Rb4TG1sSMjXFEmyxKxgbbItjZFD2TIxpX6MzeXhj6WmXXVmNjAo3lMc
z/0gznkgyIWpteKPggpASC+o+dHCbV2Y14a3kcs2SzyE5/FGNzZS7JkPiO+SUYKpsZM61kn1S9Dc
27RHYqEJdNY9N+i8rkqQ3mkE2B+7kZ3IYx0+RgblMj/Vh8Bt09GZgzw70PI6Zl02GJ+H7HN7vIiV
jSpt/oVj0J2Y6pyK3HkaLQ4hvJL9e0mN+h9DhbZ2LjyNQbWH5BPngxttYGs6SJCdJ5aiD2HSu39R
Ghq9DSveVEUbPEQ5J7g8nJ3cDLOuDpOTPoK8xYwS2WrpDxcHWTP9Q4oyyxLSS5CD6JhvDpveyRJG
9hX9u5RRrt9kQlZ6EAaApcMSZfoQDFppl2yLaN6pixchibgcwvijB3gxANmPLRURarky9m5MOETy
V9hECVfA+Lg/9cGbZNMTL2T2bYmyRv4ZH/2T+hQ4NfM0JVX6MY2TIXHRYVGRoj0SGVcGLcDFi5uR
trJ0wJoTljJYKVyRPJohBvmuDANo+DEeEakZ2TzQrYvWf0RRt4IVTqbH7AogWSPlITm8cvGxh00j
kFvgLNG4/A//ACGB+PsyKik10ZjeDWxZ7qiKu3AUTy8poVET0o8ahLgU2oiv731DMa8Cw27yiNWd
5HZrPGjD0CrSp+XJwQ0NOEhscdhuGmb+FTyeD7InpkwwGgyLaUOxZsKZFiyMRFTN2CGrcQU9V9CC
Ql9CDNJMrpoMsD2rhsa9l5KUzBB9Vfod2RYJB5Eh028jFJeRqITKM6nOpknb8FuGrCCY3k8D1mm+
mjVtCCrIgjfAVmmAip9DAnR/xIPtB2PJyM8VforpgVkeyW8PXYtkVI/JAYvAY6RfAjoXj8iInpQz
sg6s22N4FPgH5TPR+CQI4KyFhnDKir2g11UherHCqfPA6fmMT5biIeYNTy+i+YI5/nKFYj7HzShM
pzljg0CrjBn+gQNjtDIbPEPBqDpmZ5exYWVcDW/qCfbvAsoHWaY4fUXIFAWByN1bpCgj+QkxZXd6
PArq9OIRlIfgyr+BbU64EWBuCa0dspRNiGtdzBcc36iFmzaETPcUMSmOEwpgQGXYHPBaw/AgyLJg
WS48jW/oEz5CwLfodgGSJtEMGE/ATS2axtiom6XNQttdkQTbiLQjXmDkxC3UzaRLtqPU8bj5MPb7
ID+ktjMy+Uzyvba2ODRLEQ7p8DcCWBGRkqSS8NDt1qShuBhpJEzpAh0n2inEs4QmjzkXKnzjAqng
Ygvzn0YDn6GzTT2GP+yRZ40xb/QGYlpZBzY3/BFxXp8bCxkqCoUENSruIyF7YS5NjDGmP4VLNQln
eQ8sahdaBlxFwNGe56JcW+hocIE8sHc+IFoq9CBJhdFUVr/SxJBG0zDQx54UuhbpGg9MhrS4RF0o
IhdkyRYDyCUcnHlCY2aiGAAw3o6aRKvgQGU0xUISuPBxmz+SUXvQ/auAS6EjyJ0uIOS09BlO1SWU
Qianj7NW8FDuZGxN0UmBt0AbqJ0ED1SEUN2F+j8DCmdyvsw7MVg3GeUHSfFw0jAKgBcaqNqdwgrZ
7J97+RaX2ZhZpE0T94SxoxXa70cZTGE/moSnBtihduLs1oYQ7TD2JnAsIRmXYsoVMRw0Q8spjQ2V
HSC7M9DmlWJ4Gqnk3MMcMvRWx40TFRxSsnoZfkmysoYStBaeFKloj4iF4DOJHmC2eBSQqgMybW6E
ojB63R0YasYGzK+iCF2XHkrORtsag2wlmaaOJm0noarE9CGlSBGpKusD0QmQ4kuahDSa/AYyU0Iq
DHQ2Ab4MJfwU6sWzlIkUbpNkYEkiiwJUCpjA3gsZXTN0eBjqey0QiKIQ19LRxCUWhPWsDYKuhFi0
GVjbQYMHjgyihk3AkykvAecRjA1INEFB9pbeRXwRDwdV4G6bGMGcKKLgPcs4OAGonOo0RlIc1bMx
BMGWTODHJuGB1sTdYGuDMOySklCQ+r4EMqvJiiY6HhWWhMlbR7YKMq9IeYqg7VYtYF3BQhHCFLDL
yxYUhh5ZZYSwboTMo0h4cWSgq7wLXwkPHUVSeXzJVa2RcbUTXLMndkLzXDClB9iGTVGoZCzNrKCX
A5zpqn0W82LroxhqJDxignw9s14g0E75HpkqQytL5DmzBI8hKfELqlCuyg6ZL+ik9IKY6bhGiY1N
Ks1xGckq0e9cGG19aELignAaNIQjkJDd4NoUamhTmJSwZORqCpRtWFZ4RVBu4sN0r+hT1WAu+VBj
Spj6hN6GVgJkczKSBKnW4LG0JQTI0EplIFevLC8ikbVDlDLzguyNOv0N3qyMMrBUWscHL0EeNTA/
YOBoLaMT2Co4Js6ZJpNaS/QQw2xBmtwbRCue/gu1YYj7VFbmZPIlwuKQhM9B2bayHfyES1sUG1mZ
wRPUZtvdyeBiJOpAciQ5Z1slYXArvnsRCmED61LofB5NCycuWbVAqMpmLu7wJGIq7Y4dCLRHOdNr
QbNwNIg1UUtZ74psxltu6dF9w1BnDvQhTCHPdC8C6iDxCKJbaYmKMGC00lfoyQwley82oJVtkWs1
uF2iB2m0sxPUR/CZNvtQsvsmFMuxlI14Qpmwey0zcwRchuuk2utTIBjlySlry3wMa4HWxDdSSq4H
X6rOWFBSJwMoE1UblZI5o6xMv4SC4Uhi4v4RKQyPbwiZtk+ODINQtb8kiN2Yw/Xi0JIKoKehkmOT
R1UciA/IMz0xnNGlcomdIgwZBEIbgTuKup6N9lTwWJCJdvJP+iJhtoPWwcFhsw+DDMn6GQaZkRFo
qm6FmGncSro0MzsztcaMYmxoYphGdU+gEOW2F4PBcSZMguhcy5ZVFusC2RWWyTfE4JZKck+MI0LS
gjPYG/sdR9CnVjHQlqZzETJd0JWEH9FH0ilwZgmkyhTx8Bg3ZlFvJ+i4Six42jiwJzC06+KCpscH
QhP1/QxHgRtsesyf0ItmMKjJXgSmArCF3XwgpsDlmtCkloUgiPgS1x4EOwsD9N2iz6SDGJkW2NxC
1K4EifyK61BVOini0aRm/AR2TU7WhYr+P0IEtJioUJar0UJssxPISLwuEOFFEI4ycDg1ySW+hLd6
LjplynSK/wCQsP4RCgmGsCfvMCbgr3EqdxRUylWCTCJNkJUwdQFupvQqeHEKRe5KIgK0awPCaLM6
F7g4nYi23kT34IL6PewlKKRmYMLeWhGK6FPpSJMJ5gkf+EEumXxEE6aaMw2RhkR1LwZv0Q+giScD
LSiCdQhNyuD7Sn7BDlo77Q9gwD/BBTsJV0yDs3D3ghQU/U7vuhD2gtlqCEjQURB1+SFeTkdDKVlB
6KyX8Hx/R6ij1cGfqzl7EAJNkYF/A17RM6G+5yKeEwx52aIWlRpJIRIKTwZvX2CJOxiNPpIrfQ3+
CNvUv9CdCzsZy2hKOOfsc0HZjPMhB8G1H/C48B6PZjAbGTthm+RmgnRIv/QRt0HRSmaqIKjtlYhX
gJVK7IFNOYy7AVGRwLKUfcdXtbx/BGmU7YjFnNMOAjyPjNBUWdVkFFFYDNlbyc3WPoXaUbKWMGlz
glLE2nIJSfgh5XeUJ4Cuj+7bI8UEmVvPmPr3DErNDxs4xa6oMjGzSwxxbyyiSFeRrr4YA5jvTZK8
BDWRVQTSVWKJTowkcHKv0gYtBKFWYW4IaN/B4Zx8QYC8ikzrgduwKr/gzdmDG7dwn6rui/4gz2dK
waq1yaPYGTTZ7Gr5xqJzAtbPoYnWQZK6IlSVptidA4h6DdFLCKIdbGJ2DeRmhd5YxyV4GcqMgGlS
zMwh0SCaInP0LRRepzr2hyYsdQu+XBRDkze/YhlECNqJcgiJNMcEtPoR8kbUP8IO+ZvZu+Rq+qIQ
m1E8THbHUH4Xgg0E2bJjVU15G8CVExEKQ2Fsw6dYzYW0PA+cNkOCsbWdiRVi0kLGHIIl2Nwmgi3v
R57Dz7+EeMJ7EZuYZ25LMb0mh9FrI5jaUrAIrXyNzuBltEKVelBj2HH21wRWwyqi+3KxESTO2Uuc
E7SCUeINaQrq2C4bYyhPJMNz8S0bcl3BgbUNdGJfRCQzk2BGIs2MJWSnOy0gg5yZc2OzEJHpKjhG
aU0uQujrZktVUWTs3nMJJn0E1vPSNB1ozRpoS+oeF5qLfXEEy3MonDD4G9qCE502KeR6MUnVD7no
7RTZ6HpXkUgnTJsYgoqNYfCmbonPocq5JdvR1WYo0QvlKN4Y3Py2QzfC2LIirAzhfE5zXnoxYIrb
PLhF3uYLGZMxD6gPaeXHKFoOluji1F5FIJ1+B1Y7yGOkwHxEpdC17jMGMkFSxrFaUu3gRhDmaUo8
tm+mNjrm1pYE4Sj31AJxmbLrkYDEWBQFmarfZx2VTFUagdmAKkozMcRnmsmyQVyR5N0TiZAN4UIh
mWLYXDcA5peFyLOBvDwuMikODXIbbTEysrkTNdj2y5J0uvIzO4TDqSNdmtrUK6W7DKNMBtilLkU5
qn1oSmxtJ7LvAXK5J7Ms0ZUMO9iq7ieKhsPtaLYzaVwxfIryKDzVFthCZNqSJyVJNl6EzriHAtMr
unKNOEMY0q+plNdQixJvLcCbv9zUcEkIeA1wiVqaJv4KXJNMgmm3gT8/R+fkBSvnT7H0rd1Hwb9p
KYuGyD8jYlK1Ay4zGDbqnhqOQgXiCbnowLRNvBybXZzggseSqG42cjBjejVWsRGZaujfaMiKMJhL
WF5MpM8u7HvLKCvTw8mHmibUEgylJHyCmGNgjGXW1HJb3RF/ZyWheKilFROSwtHgTbFWx5D10JMd
Qzgm5yYhQK1iMBTJE+mKuRMsbAOfV5YxUPkwReCZOuLKgUDQXLWxct4VU7cikQmjeAro/DHNPGhn
PnsYku9FPr2dqtMblgcTvISshXNPsYbzISDyGfm1diikItnV7McqogbLLYO9vjt1PAI7J4DPHINm
5GMFn+klc09GpKexZ1afkcR5AwMxtMOhOQXytJi3YMzQRR+x/fHkOqdEt3hF4rDkenfwnDVLZs5Q
nNJOxqdSBj7E3AneRdQKdxGO2A0NaEnrAM+S9GsigoYLfI+cmkR0ZFb4LbzGroXhMBitFmacHKTw
MmUoRTyjwY/k8TPImsxcFcnQv8aaIHCE5FELZuB1Z4Dv+wKEgmljyf1VFk18DhiTZosqvUY0eR5x
4/wKh2DFxEN0jsRs0RknwHajoi3NjLEFJQ81xtDJlxO7MiCJi4+yJXCSyJeKp7MyNo269haF0dVV
4IY/UxvgqYqtRlAZIZMFWD/BGyUiRsymbQUme13oko0VjylDDQuycYMDN+QeIDoPTWZ0nWZsDIyJ
yXY10KThV6zdEQGVYcBa8AsbT90TCbn5+PAUxunwTE2IqYiTycKGGeIUtVdY7152LMU9vgvJ+gEQ
t8g17oVYTJc6Q2R9zhHCK/0RzlCtCcBOggx2q4pEYyjNeRfA8mWNzOoYE5YxiEZk0mUzae3yKcrF
NBZLqoXAgImoYmVbgaF10T31GuB9p5YWBJJtGJiWbcmAj0Qj8mbFpG0TEgW1GxiU2g7tx0TJ2RwI
tcQWq3R2bP2JkaeeRkSLxQzaco8RwzeuULRafVFrHzR3/wBcWavYfdcD7EhWiEE2OjloGRYvBpV1
ykXVV2ixDwZDUeJkupbKXYoNNf2I6CSsrL/RE7Jp1zblmem67VHRnGPJkB05ZfFPpsUMJO7eBoFd
aPwtmk7Iy/1gVpPTY+vxCgak1kWobd2afBYKhIcCweg0w7bodwqf/wBm5cj2h1lGN+wIaxFeBqdf
Qk7bjKaFxDaKmNn+WYLJ9icuDws6o4Ng4XFBrTnoXnTWBF221splwPoxEwNYGhse4bYrTLQlgamP
hpHocHapWSEY0j8kPlyOE7GhYqptjwYvbGPYa8J0Ok6ogMjHVf0bYQsOxWyf9NTTwWW9hv0Gsngr
TITIyXL7CpZfYyieTW4FrvsxjZ3klYWZevp8UEOZo/0AGj1RtJkqQXgZw2lL2b7TNGnOSpifgWG5
PwWY8heh+AhP+miNVwSlQZHcmrsSMPbKymOVuzMKhqmmcIPYzJqjWg8yfqmEJ5DwzJQwYrPa4Ygy
mhvjdChq2fDHhIWO23kSWNoJ5q+hoezKxyjOAeBu3gxqdCn7VH1PB5Fio9utC+5XQ+AoMJo4A00N
G0zYZXaOEcL+zW7FN5CIeTFGPM+yuMoiIpBobMSx4LdCxpyuRguuxtfqDX3zUOrdRnd6GMQl2wzN
j8jzQdfEiUyrsbSGhm+Pgux4+ybNjlIbIiMN5CiplcIapu2NW2UFvCLXs2AyaPwZao36F+Lcornt
5JZ7eBAtX+DPqu3wI6k9ieKn09jxZedDAMLtA3f+Qs7SiOucBX5ubdEqTtJbs7pcTyFrwkzsOqbe
8k8jqXhM2BF+8S5F8sWJUGgRCb4vsQZPJZFRF2AY+ZC2qVapb0bCKRdBgIpP7XJFJIPlFscIXJwa
UpFuxg+Jz0QvqF7g0Vhk8G0Lar2YMko1tI8CjDEdt9CPLqqQqcFyij8Di2Do2ZsnGb+/DIk+mMxp
PAhItJn7iGRzkbRH3YxMnpD3ZCrwNieFkEzyNxpy2ELj7g9A/RY193Zl0XCcLIhYoJbgzII7jaGI
P5CS4c65IoGvwSZTYKYmeiDqua0LSSvoYjUmqsD72zQywKTa0MTs4E/vDlEy5vInUbspQyqhmAei
G+9ujFZTAELw2mYso8IonFoa4JIXydBsx1D1NyIlY8bIuQlotYjlyvoSJbQp2Uxj4jrOVpFISt/D
TEvI3LJ+iMAVbINajUdiTRCaJcjVv6iHxYI5hDSozkrbgm4LkfQjMkVrBoZck9g2qKwlYKaS7Iy5
NIXiTbE5qdGhBeJclx5udDWMBEOAiNF9DOeAl5IsdP4Vdm+3MhmWG3geEvsO4g6RHkQiCWfjyeIU
M8YvAnJwQDnqGcSvB0NjJOhaT4ULsgTlpoWq+tFK0iQueNDx8fgQvNi/JTIwGEM8YXRcE34Hqr2N
6Rjge3g8CUkP6FeChNWBx2ZEqfZ/dAvll6IyQQ2hURWRbWnLHWxiCtVwWngDzQQ4wI/l1EVdW/Ix
G1IcqXll9RxnAwloyercExS6jelIbSsFNYFlh+ikmvRocTEcGmWyEIjPgbiogLNuCQVAkzU4HukY
fZb94sJfBZVhvAmaJmovUqLhFYde2IrQ7QyqacIa79QdvEEhli2GL4yNKilJphyhgKXhFPBRkJPa
aHkjS43hF+UzlFCkvBij9HjEPQpjQbarOEI5dsCciWBCWaiWU5wUiek8gaE80U/nYH3niHy+iMUI
GZoRdJAlPA8FkSldyQcQnUZBtTgwXLsVII5KDbiMTEryWkTbXRPY8DVschGWZePImXikEDsVDx7C
uRezCRjClez9vSLLyD1HahjkuQjTuWBlaaDp0y2S8CXLGxavBLl3sWH5HgTFeZI3+FTEG+Rks/Ih
oehtnEGH1XaNCy4yXBG5SsGCTJZduSIbqG0p5fhydGV2ldQSVVKFAjHJDEPN9E1GmckbSLn0I9rO
oMlNJlYE2Mxon2J8BZk/QIC0doQAjuh+UmdgpoTcsaE6Uv6axvCN68vlwnlrFkGpIs5kjAVAatSi
EYN4diWmOnDGLtGiumfc4EdUZcwXS3Wxqcnw5nVBpXDMulAptkuLZRiabhdoU+BFldky9rFjY28r
oiC2/Dnjihkdaw7Ec1l58Cirk4ONi0myezMXQQHg2bIWMiI0w83DFfS5+gySRpijE6Das232y8rb
XLY5GSn+yDwmOUJk0kzHmZGlDQXwsbHnfwfBufZjyI8jPXMGRC1A5CRniWOmX9LDPsnRRdfQxykk
hMcaQQaaWGFdbwQBLfBny2hi9wTgfgl6xdGAGEOOxqiTFabnwzaILQsUXw8HS5KNGUAfJLC0iZbz
F25wQaSFkyJbEVJa8IvKI10qIjmcDbN7CVeMIpkdeRhhExoeBgpLkdTcsdiWcDSGtjs19CCkglS2
j6ELmg8tQl1HcUnUcOZwO2V8QE1ET0YMgl0sB4VZHNRuhMSlaMNIRPzgcGFS0fHZESOToyy3BFAT
wI9SyYeh4H8JWLBhiQz5n4NHaQ2Ia8CsE6rmWEfeeCMlFM4q0kxHkjYuusTEOKRE1sJCtUzzBUUF
OiN57MWJ+g4qvI4UYFXXJ6FJ0c8CsK0VcArOM+DSReDGuG4McLQmGTmG6lWuCFUH6LfQvEoQT0ET
GGaAJDVKqbjHeKoPXmDCJ6CspWzQ3jBpGSJNYHdy4oqclQX2A+StiOYpdHYAq8JTP3POjGAZI9Ba
q9DSyIwbmPegJ21oJ2xb9HWBZFfmDRl8MYddFUPamDtcExXfqxSUnNn8WLGUJISjJoK9pbEpc4Bd
FuJDOQMeBD+UCFplMC26Xct+9madSxCUXoiS27ltiCdaBiWrNYohvRrScleYYPlkvOJhOFmd/YhS
TRzy6KfbBM7MR4vRcIemlbWPidtGrF8e2jB3AxErecYLOXeRD3kZJDh0HUYmwWhC+A/ROWy3g1g0
2BJQ2ldDXPBNl3LR/REfRZ+tIJxUEXwzqXwqgySON/guOas4HECwZLYo1NVDCZdiHUrRmyxkP52u
I3IokNej/ogFFtvaH005MZUsiU7SeyYpp6GEsUS6c8uBVxiciNHOCSapoBlmZ/Ipazcj23Sbts/J
ZPNZGiXEzuE04aDyeOBF3hhTwyW4xcEdhNxK0yT/AELf5onCzBSmU89C5S1i8SyGOdslCNWER7Yp
aTwHKpkxvwEvkDAZ5I0Q3TSOAyL9EXfsfWmnlEOLTkmEcDdg0N4Sw2+L5M26J5F6N5khoxV9NeTz
lUcdGnwOa8so9Qi4EIrLe2IJ6GTrQPA8DZ5ga21isXECT3DK9NDejCftCxsZl8CLwJjjZwJ+CEZp
mAeMkNMQuPA3YSGVdf7B6g5viuhLfp4pS8LA4oY/s9iVOJZEV5uCgT5FMrUZNExL1QcLVsQMrkdk
moMBEWrQzgU2IE+0hPhUSsHkVV9D0zXgC5uzUKXgybqXDVNi7hDb9jHy8Yp01wblkZw1G+BO6mRu
qvLGSyXBwYmMB4TtWMFK0R08OhwuBq8a6byyFvIVHgUu02L2FtEILr/hA3onAndC/SFUsxiPTPTD
7WXR4FBRzFsi7LI/IgrmwpPliXh4LukLk0gp6BgvFEJbKETgR8WhRDTeBb3Qati4XDJh4+DQ2uzT
iYOklH2yJMFRhdNQTDyCPOqHmAmhhTD8irju04IivokXsRDXAqo6Y1fZBUy2Qj8M5+TYssaiaq4G
GejSQYAnds3LS2Os5E11ZosU7bHBg8i9G4noRzByHKuZ/wCGQ7/YiJra06VwSs8Ak5dNIW20S5oo
HWGCkZhc8i2kjRQ1ZwZnYf6E03TCHNJEn0LbOIihsrGC2mLRSD2MbGtB9LEDxgjOlCGORWRx0Yse
UM6Tz0N8TVkoTpoh6zfU5GSvwNBzlkobJmvRjimSC1zHWGFCItvyIHj7MnppMbT4EwDSUYdW6uhL
JpuiqvApPwZLAqNwp1SwLRldnJZQfQJkUFmuShCt7sk7llUa4NGeNLIhpPCVOdsrK9lx9zMVRlBc
NaYmSEy0Qs2MrQZbup/RIIWVJ6FSwT9GaSJNoba3kl+aGcBHkQl5YE6raL/FtUfaVk1FTGpnocKj
EaBSHBNlN41j082ak+eUoVuy0QySzFOVC2OXHt3peylyFNNFoeFv9myrA4uPGOG8pv8ATGVlohOS
SiIfiGAENTfJk81ri6EWEqvAQYG0/BpjHhjQdZRRkmJzRTGPJLxI84FJ4wYMSW7FMgkLeRjTOBXP
TAfTiFyZPcHvyNnlyDltrRcb3MCOXFOMaYxTQW/5N2M0+DWTk7+CWPhP4e6Y00NN8jYTmBlcG8DS
L2zBz8wdldi/nuYF0HdoO07kY8rRZ/JG43XJE+gjfvNFxybEYGLjTC+NsOZDyJozUJlHlm6eBvMS
RIhEgQ1ndOSUGD+CkGZXRfE8tjDkSAw0OxsZ4HelwZsYX5UXL2NyB5HcobNMcFyceGIAtEiluSkO
7ELHLYuJBehfj2atBlwIZSQWOSKhsm5yL/zMihshingIomJdC85kWAiUxWnkKYnuC8Ux78m2OgUU
d5JiXA6qolDwJkeHgn+wljbhWjHcxmMFTwzSPMKbHODxGhT1kmNrhi8aOWKiI22YG/yJJWjtTgjY
YZviBKW7IwYkNAeS7W6i8vKO4A9LuEKlUwOmJC9iaEpWUqEvmDP7KJQb4FqmhKVqIULplOBWmG1K
sRJeHyMyFG2+BHWDGtQYUc5ChyOGNJob3PiI3D2nBXhNpw5SHg0OUr6FXeR3RbkRhpIqlk47A3Tv
oJovFjpJORwKzZPJKFd5oyqjkXnVPTFRMYFjq9iFA3JL+G3BBT3gJAIiQnVsnAtpRaXZoi+WNcrg
yVZOVIkKYdHNZkCbPFGq7vBBQpl2W+rdA17qdpsopRbD8y7NG1bjLaQ9ik6Nu1keiJcfZKkadB5S
bQ5mSBTspmTN8DIolA8yNSR/87Rb5vVJs6DtQKIalwUNvCZY8uJSfQnMGWBiXTwGQlzKiA8XAvBP
YHFk0oMUU+2ZUkiPQppNV4IK2rTQ4dAJGhkeh8mKRcG8J4KggKt2CRTZjnldkQxYM5ijwOaUySh8
SluUmJT+GjlqqUZbF0dHcxGGC1qDsvvjuStoYEpm6sekIb7wIDUdCQzCkGY0aMxlCO6aQyS5scma
2VVjrq3ae2Uq0086Gxlz7ICnVtO5E9TFl5FN9rBdDzbZrS3IqZYcg+TNqSo5oZMlQSJPik2MG6tZ
H4Nm7w0N8Fcb6I0txI1wIMO0obep/Ege0ewrK8Qa2lu0ZkynYwqRyDAYr+i1s/4NaSo0VwKGg8TJ
SmKbbGyN0WB+XyaMQ5wRwTx5HpT02TKiqz5OY0FS3FEf2B51sxmSO9esQyaSwN0GMeHYlanyxwSf
BbDVIJWVIQoeRHXMTZCjaZhyIniXkaHorTQsNpex58PYRmUXcORjmluFxRILboYAUFBJEyWvQ4in
Y5XbiCa8t4JZSQmlGWFPkpPuMWB2aSiMssaL9L7NyI5psTWQOWElC3upbQj4EGeSC4zZzAYT7KNG
BaMn8MqEO2RUpniJCG8EZuo0hLhopkfgdY1Xki6rYzyHB3zQgNRuDUsMsbXYoLJoV3g5qFNVXYn9
tF9wj63g/IhDuBvZituwvJXiL7gkYMddovgKWdYKMSQ2zKEmERum4NxoyC5o/AcU2ci2LdijEKtT
tlQVwZ6wH1PJjirgfnfQURX/AJCQhQ88WjHJuRDRY/R+5FUd9DismERFz5Fk3mtDPUkXMTscVDE8
hL2tGglLTRmpn8sWmczd09Mi7yNi+b/JoUdllB3gViu4bEDc56Ce+tsMQvmu2x5wfIRZeOHsphDN
0KEq6pgThqKbYZCMsGZv6hgBkFS3c7GRNOkyNDsRZuyxk/3qBzE3Qk62q8GTMWlgLfMQixosY6M1
E1weiIX9DOmNsVHfQjW6MDqbLsahKpykfgJagQ9KsPzKFdV+DKt+L8EdWytEdEoKJZ3Jip5hdmT9
c3QyUa8j1PsSLIxD1ZIArSSZUjbYwG8BZkswMa9ZpvBYzfghwF8MJRS/yTHZUaW6Q8fVMel7ZnWg
yz7aHLIZWi5FmYQnsfsiN8DOktJAtIJqUc88mX+QoJqM3sdX+QqHyilSmmcg68y4psRugKO9FSGY
edmUg8TDoR/tGi5RMsn2IwmNyaEpdF4NDyIHxhq8D6w09p5pHD8HDBeVPgPaLdjfI/tRjXXVD1cv
jwbV4N8LDSY6su2mxsjFt8cGUNjahv4zaEjykOPAnAzNmbEkgiW014KbJmRzBk+wc3Dh3E7oXOXs
ktsvRy4FGZwkVq12M1XoLglUTMR0Gr4i0eBafw3kuRj0KJDRwjBjlBSlt4HzMGJ5sgnjEsurvJjs
ivI0LpIjBIbGmBAWAOq1DSEYsgjGVOEVv6M1NmGzXRs7PJ5SN7/ZUSC1r/ZpZWEhHoZQGE9lQ3LB
DXLJRtH7FgX7DJ3TTloVSSXvwJLOZoUj6gZh2+Bkb5IIK7H6FL1XY2uQ1T8IKPBbJ48iZQa2z0Nc
zyMd0/BrI7IU0WNDeRyynCXX0SyOaOSUy6/RHTMXR5JGu0yEzG5hUYF5HAYRhhRzzRZtfI0SGngd
U3kvi1gNiRfgFOvcbpKxkypr2NbTIoNgDpDC1WPrR+EJKqPqsaM/9gWK0ME6rtoUSH0UPkf55H1J
Idnh4qKLqGKAEsR7NFQ3WzDgcJCHEc0zfYXCfQNKh7Yrkt5HqeZeRNQdi5sJ80zj2cZ/gVDPkPY3
gp7Dwx7vUyGdjPeQ7MhNPwULDmidtN+xNVtyOqjfTPVbtkbBj8Tr4Y8ApRv1hgtn4YmUrXWTdb2H
aRHRbMGjcmXGEp2KyNz2SWP2GOcGX7J69mJ78iWMBGTHVMRX1k0SKZmDBxe0+Msay7MTrmLn6CxS
9svwf8G1VJ9mBWvwW19I02n4DWKljCHH6iG+kfqmcIvQDjRBsTzYosUh8MNwzseCgz3HgQkMUibr
4FGiMcjRKNxLHoRFET6MgH0iO5w8jqDoi5NaRLafpzIlpKssUeA/IiXJTHwrjbhkmvQ1jzj/APwa
87iBIopz5OH9UzhaQrm3gUqpwqG06NOVxpjBZDoYwT67LpNchRVcoTH1zTFOVjwQmKtlnJB7RJdE
CReGZfYEHCzhG4TiZYemyxC84UDQsXBtu10PtLFJXWmPIbVY7Qg7Ea+qSTyJheUTDG/DkSWSTqi9
SnwXApMgrJ95avQ9NXTg5hKjs4G/JwcEKHtmCtZHhdLoqXsko0xbSFUquqI6KmiFZuF0KtlYjLDI
AJnwEjG/DBKvojNecDTML9ZH/Io+e5PRHLjA4YM+AfxOyqnJN4MtCz38IPEGoSVZIcgVCSRPAxLR
PYvwmIqBrUasUAr3gbScgYq+0QlOkJwbxgVykexUX4i5KCmRjYzThxjkkxfp+UWlEazwBLSJsPad
9iLv+ZlaGIssGVJY/GQxVL7KzkG7aHPQyS5TZlSzLpicTFnBhGscImOSFkq6TGNJB96CsiPnkQJj
At78kd3WxUfnGYvsaFxZm4IpdOyaS+x7N4ENZcQ/D4SrA6TvSg24KmKMTSvwObO8EJdTnsWQwQnW
m1jTI3wMilYL0el2SbmYwRmBeBcVfwV8QuULQfoRQk/KEluciaGiSp6HhtUt6LCSwIjWxxgr08FW
5ydfZIMqWCc2noG97vhDParHQkQIKQj7wYF/ghbtILtqS5FzTKMnz9C69+Bk4BpNFjgOBpp/AnoJ
dNDXy8ISw2sIalSXoajSLPgWWXvR55w3iNSBpdGahHgJ5icD8i+ozprDY0MVEElj0LTEEwew9UAl
CcGLMzlCybgnIz/QFhMARdMAsKSMVlbfIjcRNvDF6P3G9wbLlU1vpiTyWaYxn9yYIePJcbfHwQYx
K1GLCHnk2kOSVsJgZVapjDK1mMSlmBsREzw4eoCCY3Juji2Uxi6GOigKjDUPoIvDehGnqmalJMVQ
tli1YONr4QQdKE+o/MCTgxBgpYFSU5I0xlyIzNdhiPjTjT4O05SlHnCDU2kibTNFBazkAySiraB5
5YrDjy1CfX2iKrJgbvUXCYecwVvGLRjDHI05u0SmyWGCkeegrJuqwEfoRWiT5IVdClPu2PZwASDB
CRuTsEBiSuRZybgokiaDOZkTcFG/oGTw5RvgJTZxSdCYYplHO7lzoz+nILrZjfgQlGKfYrpq2W62
r7Mivc7C7N7AhYLfwJzRjfBP6Z4nPlIOQvAc3xNJj+YxIsFxImyXhuydeaLs3Xh3NjAr53QeVUI7
gOgJElOhim9f2YMbN0h9oRy3RfCcIbfDXkTPZCHmZMFYgM14kVXoc+5O+xs8mkg053jBCGOzI9ps
UNdCnqkIqTg2cFEOwTNWi6MLMIAzBDFML4jabJkayQ5G2QW/gkVFmCX6tEIKJYnA+9Y+BYrkp7fk
Z4x3lrJZEHWFoWBKGIS4mOiCvhtiyir5FCJgwrBtBURAvAnTIVAXbjaJdCJElTZZzL8GBpVk9NSu
ecEwKsLA+rggtNGFzXoUFKKGF2Y3tq01Ix0UkssoUrg6+TZOHgVaaxYNjg7oaqKKGq4pqayJK0DX
B2bc0Pm6/AS3XoaVMuhpiXBZ1US3L18BVpsglqtoT84Q9EN5soc6VtRsTEG9eTKDT9EA3gU2x4EL
nDF4CRtNG8nBOcrF3FxTIIVmso/0QeGBH8gOZD3gYd6NCPIIYtGvDT0VFXsIziCIpkZCWzNnIyQ2
wpmJyS6DRegOOGEIfYryMu43PopgtEMy5DGLdCQU0Ggb5HpNOw+EMZ2AQ/x7BLUhXOxGJVFSyT2L
WRK29sV0JNw0yWhDcJ10aWZLDXkzdtfZAyTvJcXNwSZHGBIxaYL7hIy58nsBhkKZNYNF5FtNK8mP
s60GsZXZW00SECOjnI6z9j6NguId7DIVvClsojKiHLIdkXniE+XQzvHsU8dWEkxFcjRk9hUjov15
5H20BOpxh0ZJUkE/iLVeYrVmoWBtUZ7CAQr1xCaVhPgY/wAGBm3UH8s6oXxioX9rCFJE0K+NHGkS
HmCqFlozTLsbvWDWGjDJQnpoRt8TyPI3JsxsFlqYQnj6Gxk0sBIGUv8AgjJLORZbLOzIQhSYlweY
movJ0QaK+9ZbWFSz9FMMm2mIb24EVbrhbCbTl7IGk6F1GTkqs4CVRJeBb8q/6eVV/wAEzVsbgnLZ
ssV2tVk87kkaE5GhEpC8KMIy/X+ldHAPLBmxpfgL8gOAT3BDPxC04yOggv0ceXgsrx/0umFL+DGK
XBt+omb7cpHBn5ML6ijFMwochKENJaEtIQvp2xt0uSjWfhIa+MKHnSIM1k0Km+jCZJX2KnOm1Ecj
5YjnIhDTMFmGDUryYoYOxgsaf0SHcDDvTGGHshqV+CNcwTiM3CBRdm/mxjcZS3x8XWbUK/cOqtow
BJ/RXHkSqhNTsTm1CCd4P3CGce3WODZh5sT1YIZgdYE0ZRDQups+RNHwMU6FnvdFL1iRjwET0F0I
9woroSzyIkoqv0UO2xUj0ICZ0XZAq0FMsVeRKkqh6HyxLfRgZyMkeiBPkxYiHiHXgVkjC+WbFhhR
N3mh07iUbqsF1NI6p5EksCgtVsVc+MDMk+DN8uhVFhwnK2pucKDLgrfYzWKrJEexBaSSRCuFi45b
R0qG5uDjH/NBC2eBTRLAtpwU8aSJNUnjZFou1wOCEkD9vReru7MvaSODXAsIV2m0DaWmS53CfUYj
0cIYp9kYxGt9sqfQDJpekZEvuKxIwvEqmKSixBE2ISOK+y5qlMUahFHgGuIW3nORDYy7AuX0aQgn
KsOz0OBoI8wapGjQ4gBx8pBHJH/kUmVSCmsm0OClLaLVpJrsTSt8QY2NtpjoXioUO6qg8V5ZE+xD
4fFHyzrshmzCGMmnmOF5SOBUqXUBktMEc28iFfhTh6Yh3QJlyEyxYJomiPQJ0Lb0U+z2Lk4f8Gup
5ULzvAv4JReGn/gjteVs7QYwOR3DWSOfQjmQXoyt8mfLh9ZGfWEoUu1ajJ2bklPAYHeQhujAaN0p
mvrS49FiZ4jJi6X/AASR5jNM+QiDuM+TLHoNPKQLoiZqXsZyrK4KvKWi9C26uw7L4Cl26FbXNAnB
WKCi6WqVgzRhYQF2n+l3GaSXoYbXyKK8cDcyV4Ms8DginzOjJG2Y88i06MPFkbZeH+jMEdJfQx2m
+WxRTesxeTVuaLBZx0jkChotT01fQplFsL/tkOyTD/o+pWj0Onoyj2OKulCkb3McRUDJYaE7klwS
2QU5giLBIux276MNQy+DMjJ8W6URc6M9DWExsZtswYdTcbhIZNoPRMXDHSwxmRESBcqBIbwKJWjF
kvJg3gzlnyMYbxDKZOGOxoMoIbGZjAw8/B4EhsQGaQtCehlMJob+9E+MVGOmYNCTrh5lZu0aQpm2
x3foVSxWOvxJJ0iWuyUexmSDEts74SJfajLhgLG9fDhLKKnfiGlaXAXkDpRsoIMqUPA0BrwL1Zrm
cbnIpqwkDQgeRLPcNo5GNiuwzoTbwJxsYH8BrBuDpT4OkrybPGBBjVO4h4O0Zu0LWk+Byt2ZCEup
jZZpipEswbjeoonI0plmd2ciMxcIe2CanMZ6M7OSg8tCe2CtfAVdOCOB/wCDCw1l8sc7oTG8A6Zz
G92eRHVi2W0eXrwJqpdmVxfRbYYw+LkWy21gcxhdjeMpD+jVEkGAngY6qUGU2bTI36lwvITtXVyN
5hti0PbHX5mMe0MR/QMwt+VkWGx7FRgVaiCZ5VnB+uGeNBhYi3uC1KGbjyyylkxJkg6GmzREog1K
r/gpB2Fuszgiqo+42KtLg4Z5DSmBzAahMNSLIa5XBzW5ydELRp9h/VOzCXrYaLb229iMo1jhBxIQ
12nDehvYiyV/T+TXIojeISKrwnRf+oA3cppwTVyKl00KGqaD7gbQHiLPnAmmZLZfsq2OgITPkYrh
aFpYgyXFljsz3kiocycgim8cvoQNxl/Cias9marJCEpGX1pMrjBCzdZFQNZCMhxtPoX21eCtoS8k
qdTCM6EyShIzBRKSvZWlk8GBHGBMZcxljPLpBXSaKgm1sxGLiTJQcZGlOglvCUZEpUnExVDMbM2T
QmNdtiI7YUjjdP7GLjwDCV6YsDYwxxBGQ34+CTIWdMSUZVMeUS7KJPBldCbr5XexSS9w8tJkg5sO
+ODV4rbFVSnDHHdQl2Zd4o3BkXdpneSBT47uXyyV2K4sGiRa/gZMZ0nGZqUo1kHc/DE4LOpBd1NX
Ia2cpBpbjAZ72DkZLuCqmcoij9CfyjyCtGrXo3PCAWttY+zFQpPhi32OijSmB8ofcaKPhjxiDu5F
Oh4IbSCOiVlJlZDrLz4F3VpdiixxkZhuU/JXihYSad8iTiq7IYteIZ6wxpvgbZbHLkHb8BYYP5XJ
c4EhrBRDyKGtoTecXkdkpTnkQyGjHeNzYo1QgkGfLWyGfsWCFTfRSrCG+L2KYKAxN9izAkzkJLW2
2iPz+R7rAyfKdcWmK62Z2RNMMtxWCCwY5AiSwm2VKdsCDoVuTKCFjQ59yF5C8jZoPKu2zOiFPWBS
n7FhZszsLVoFtQ2I6QvDRmFX7CmmT9x4DFIJBL0wJYsjcMYJZNGgyrhItVhLIun2IBJIcjqMNM8C
E8W2VlqmZ0s8HrpJi1bYLbeMCltPJ5F6ioWEUELmkg7KUEEuFoZU5RbyGmYZp9l9V8ssWkYkJQmC
0txitcfJZQptIarJvItNqx5rjIDa9Bw/SohOCexLWR2KcE7FSpPaDGJhcMdkDuya6OWNkVvwxzLY
UQkbV9B/Fjh0avBY55OiYm6bHRYuFSw1maMkdw2OGg7KeB2x1jNTeYPm2tszq+GWLkTUawbEXIRM
pb6PIipjRH+B+l4GoEnsVtaJMfsDyhjKbTtJhDNmDF5FxB0hFiET+iWlCjuOSROsTXNHYdtsb4LH
FAQ60y5/6A0K7b/CAaq+CCzPC5HtvtltTSdZMQ4n3MfZO6U2Z+x4NrJXsF5aGg42p9j0u6rwPe7+
DkgM0WF86hlS7bZTjN3RZRRIPWLiCpPO/I0r2uCrGdQRyg4mfCNF3kNCr8xDlMwCZ3kUhTRyYPAs
XkhGVE2/8M9FXgpbUdUnwprJWoOL6y24x3ieSGRe3yIuxC1uK0TD7eRs+8nn4wmeulHPIYzV0xxV
Sn0fD6O2sMl9cpMUNh3DY+IXG1ZUehXqfVGHnsU42vRpEIzwUlXDGpgfmjujAFe1RO8mKTCNRlgS
9j7BhWa8opgFTLI7b2CmwPl3uOCZPZDBvJKz8Tbkcx+4Hu28s/8A4B+5gE3LXI95NB8MvJnbXiim
o8DJmmIgn4T4tpYGrI/02J9GI1BqKaQWqd6KViPhiGvsXFHkUR6Xg5oy0sDpQXO/4Z+hEA6f0kkb
DcEQpteWISxf6HptWOsjZFfD+CWDAb+HISG8iBVoV0ejQtdikZFqpCr7ODMbIaeEtT6C58ilbJ9W
JC0O3srGwoVp7RknvxDFLAq1TXIuy46YzrkNRPgBtVGFpOTvRwEZknsyXiYHTDSPfGU4ydUr0Z1z
Y+1b4FGTno5hCsIjUEmxp0iqL+xkdV/RMvoNFRp9nmJLqXSGOZPdMqotUb4DoS9jI2yUTb9Ezium
iyoI9jQ0PE1s1CR/wkZZsTYDfCE5pTnGh2efbs2fRQbR60Ule4+mhHHFiT/ZDnNsNaQlAE1FXKsn
gTvt0X0yFTuI30gra95obu3TLLxDL30sh2v9lVbohWrzOGdVLzyPG2MalMLfqNGPTaE9iRnr2zOe
jzsi7TxBSbf2NjSfkZJMI3AlYkcp8jOPD8Ey55QlXYEH2Qgy9lpPAZsRDKlciwVF6eKCPNoKOm0N
kTm+l4FGY7C+r9mMaMR6XkxY0trgxFXkZoIWp8+WPEYxudvgak9NJNwbsS1oRKz/AEenykJzdOhD
/QL7Z8cn6ZY/iO0Qlqy8CM2q0kE1NkLsFXU4PqceTsCKxz4Qi5xyxOWjKJn9RtHjuFbSEnMIxmkL
GNhCuShwC0mE+hpsxpoTAyCHfxSF8vZwRxqKvJhQaaD3oVNCIusXfg4MR1wxJwxNro87oQ63Pf0P
PmjkXOkHxrw0ihpybCnRwFxm9woy3qMCo7Q/HozZXmyKAngLSrCWN8RwLAuGkSIzsso8bgjI6J7M
1UmOx3QlDpF/Y/NvKbFjLzo9TWGX2atXKI52EKqFsdN5hNciItsCvk3TBupYK5KuYFm1rprZeEst
FwsKTBOVS5aHmH4t7GKWgkuRKl6mkYTOvpN3EZomD/wEFWWoIxunof1VYH2iZ9GVUQabG22B50My
RRevnkrElyIZHMJqiD2HbgzisNurSLETVGcAzdOyL7QfWM9FdM0OyJKlaKIdbzxItmNbHToBQBki
jIHj8Gnn4eGB6Mw5DyOGbNkZnOxGpbatKbQLxI0IS1xzoeZIYEokMcYVwhCMc1S+hy0YWyUbzoQB
FBb/AOEmU0e97GBTXQdbFaI/ZhUlMNDkhBEmnaCvBUj/ANDEVTS6KM9ohYmEQS6EKcvRpheDCkIO
xKPUEGFL0NTQkYAhyIVntChpT0iqzP0I7yHaLmCncEu32HuB7E4Fh1oijwEqu0UCXXQyTZ5Ep1Fi
OrQx8U6BvBWpWTM5GaNCHclEJdsjnF4YFowalOkxHRUlxBiqcdFqhHsS6/SGtTThELDbPtDD6oH5
ELlVjUlByZ3oZMC6CKxjoasGJLnyCZtEPnHQ1GDYI0aLolGbGICwELoeWTgyJyeTgtZwTdfBio4C
w7n8NQx0NWzsWGra3PkwJCguobmyBllWxCYPsRCGIM2H5R743kuFvFHxRtC6nfQtIp2PMPZ1nRqM
7FgLuVFVxB2dW0IDykYHcXQrCBw+ZngYlG3g4QnIurloTTUcF9EuA/5XYmtX2FRFm8EgQl9YnvAp
XxC2R2IcWnjgywTFESrN9IiDXTVfidjRVognPAXYG+XOKxdqHRQf7KTJITowQ6EqpHahsUkThRBE
slFQ8WtJljg08yJH/wAwwQsexCVbZyhgV+g3bsk7Q1NwQyU2mhvSTZafgMWrzFUOzwBiWmro+K2X
A8TqDPzjTwISHwGihX5OkUGWqKCEZluwLkWGah3qZvsK+DCGCrIHDq2H0SGMI+TJ4vyNcSpLuKTD
owW3hpiVGBtnIH1FbaJaFRFv4QYtGOhcnYl0TS08lFkmIGJR3AfZvBStebkepESYBxMjIeqv0VCA
dYX0SWc14Ks1eAPBYRCVIfWNFUzbXoQfemMnAXWhIbLZngg1IZiF0jnoVaqQqDkbXocsEtOYJDpK
DQ01JuEJNeFHRBMR4W8CaErvQ/atP2iEc6MooFH3CQnhh6g6qmhwOxGIsGuStGUWL5JT0Tahuhmv
IxQhlSW4VgsanIUr6DPKSM30WziYLn8h3rLI7FtcioM0i0RiC5pIzEKumG1Q0fyDxIccJZMmDL4y
NjZpD0aRRvgwMjQAU+yS+USO4rdRWLgW1MLojlsI3RQ0PANDywxpieNA10DPJRBnidgFDqKXQ2MD
JcfJcpdCGYTeBdMfhQgtusX+mLxnlsKnMse25lFoREg4NIfH3Bla4KJhDk/IKaMzLGR0UD7ohyMY
1k0VeZgj9GO61wLyNsvoUey5FpsDkwaFStIVnbQWh7XIh9cw4mA2II38gkypkWOHgU6JyOp5oza4
HSnQnOWinTUMkkYUrhobPgWYuB7JnXgwk/DIQb4zmUFMTRCklhUYjWQqS5mMJmFTJjDWzNTgbeTi
KaqKdCIaDca4GVJB6cTVsjcijFn4pMyEDCCapzeKDGhLFmgO3BqlkyYJirVjY4LDBOa5MHkFtF91
yK3j0Lwqw+9khI35HwLYNoGgtiY8DNzysC8NZotI0vEuM5k2EbC+PorGxaFUdPPZ5bxcmjY5o8MI
fM3yZwbMFdLK7GNSxGmHQLXSXJw7BpEBWWRJNMp9DEmmN0JVInBhzcxcIZAxVY2I2Mh1TrTA+spa
mWzWkicVHgLuqUFzvGJXMYCJCnI4Ip9i+mk9CcZpp8C6onkLKKgxCCWYgTG5g76oi6vQnSiGkbYJ
ycBEXwJxkb7Hi0jaEy6j/DcoyLsVV0EXdBamyt/Ih1aK2ucmF4doouW0Y8XNQhUZDSkj4pkgv36F
OMl+VI2NC7GqM7htaHZTUEQm8B7CuiGNc5JruIwlJaDHPocim3niNhxz+Dk7Wi8iJpeUE/IthNNJ
8LRdjmDwGPKriTs4Bl/w3Wsm4jD6P8GveTZyg/wTBv8A+wbI7CvoZXn7S/0SE9rbpiYMng5PX/DA
cEom6GFeXY5oWWFK64FWmMjpw5wBF4EZMHHkbjHn4e/hosDfhsZoehVLR42CegK+JC1tcTGceCQ7
F4IdyxQ631Ai2UhXeWCQ0zJxIchTUhpDLxn2CWMyDGwkvhszhj2cl+GJqtaQyf6LJhFbPDYrQXKR
je7TeaVHUFuDBrAJNSnkQkIcTzRh2gsnXHksGTFMZPAwlp3IxVISRyAtzotRyKPDInuE1rZlcIbC
WAvP0IYU7iNI+RZDq/ReatBLkouqJKm1gIqcjfkkhuRUiEyqdkgY3wmNVdn2UBRT2LaVWxFUsEE+
jfQ07SFg0vQhEoGYRSb7ErIyS5ZgtiQb4FpBlAqbfAxLbYqaFYJlZFfeY5sOhDeOkOmotHg1d5Mx
40ZlDESRVItWwtU7M/SL9yyOZ8CPrETAjNJc1TFhmRwKnsxdfSHQGh5H3TLwUyMERLkjERZtiIhD
VdFMekF1srCEb2hlwqbD4l1Bk2vQmfhp8TK+40ZoYex3GW8C0/EDYXJo3/dBGwpIvIN8I3XOWYC2
2PYosiewYXRlIeDOUwjmVJ5cis0xWRsps6FptnyE0S6Hsw0OQLkhV6Gspsm3ipjjW1s0xXWKZx1g
xxaNtCWHsa7TDRvYpLbjiMXfgP8Ac0WDfI9EvQ0onyEye2I1vWs2mCj3KofbWahNXBzspOlUbGzl
MfbktmPhtvoxMbQb3DshPiFwRGslg/8AlAQyfCxKQsH0FDsHlSxf0WZGVTQyupoOIMon7K+ysQgT
3G55kd70Y2ODHPdB5E/OrIg9aDwly5TCG8G0NjOQVhaNDFOMNQQE0Y7HOC4LXC4MStigU6W2/EkJ
QiX4JvwSr+Cpu5P+D3I6xFu//AcOwZOsOCRmGyyxJXoxrivj8DBLiGHKjV+hKORRVO2jr6E8cexC
O4XyVK7eDPyir5KTnBNNwfJwqWOhIZpll1w1HWcPsdush0KauCIYpjh8IyOFNchiQ8DCP7Hj4ehy
ZNHoxyZIZR3AtifQtywIWjD0YMMDgMj1TE5iLmHkJWtB4gNDFCD8rou2TFZGOOQ8fAQ5r0PQ4XI2
Hso2cEwaguzIQ0pIy/A5nBChvVj3HIYQWkTyU7vseFmcT3aMJllacGXOMZ1JyFhFeiuHmzLEnDWI
OK6GXK0FqTopU56HbmggI3gRm1csegNXDO4INezw+MKTG00GhNayxLhkiC+EHqhq1pDl7Al+MjhT
fA51GUzAng1jGEePgmAK2TNgYstwqpmpkpSyKs39hjWwuAdHpix7EHg7lSTIm9iEKVGqdTZBGJnX
BVdCmq8CSQTY+rPk8wIWgtObgzHCpdkhMdsDGhZCcKIUFyvaYnO2xEFWBL+7ExsSQhuU6W+FEMqY
FhrI/wBgyVWhFXKL33BBCdZFoiMmEOvkiDcSF/GGI2Cb9DFpkiE0xLLEp2ISzuKGyU5hWSsRNJLZ
KJe8G+SQT0FnbUSbnxJU5ZkvIigcoV7FNcNPbMqRZr+DUi4mxUuGTJeXsT1ICRvM2u3kcFXlvA7d
fzH0krEVsQMnJYKtyyOk6Tj40ErFJtjeMN5HWV9NDe1BNmN50mMfnGyiyErrWihqo+Ao2tJtjuxI
V1DA6hXkTmA+b7DFtbJjAd5VNE7RpjJEp2BnkIstZuKbU5YueyD/ADjxGHLkGvDNor1chWoGKZYy
8DZYiENt3SLK+AMEfeiyk29C13Vli+AT6hQwZBI5Eklcb2MocEVzSA6cxkIoNWBWdoQwBvgJGoqj
GBqUfhCYx1qOnJqhvm4l5GnzEWJM4tix2wriGUJxoGts2p0P4JVxGZsmWx0Sp0ZC81rFR8FmyAJe
qA4urmx+ZBGK6RzRUER5fhDOm0q7ZkztxEUfUHgG8I2QStuW22P91lkZlpx5mAyOsZzjbGi7y1tJ
wLBs7HMwjIoeLNpzwMabFbPbbNsaHskMbLa6MgtaZ9Eh+UetEkbDXIIWssYwQdyLJDRQ34F/CklF
+L8Vm2SF8LZv8OCDnb+kmbwLsxO1d+SSPFyyYhpp8+xmCMahtFuaXjEM6lNJj+pORcYXNGarYJ8r
JDbQhJiPPAoLJ22LrOfQxZC7GoPDM0j+OSroRjgNY+CXsXRpVkbBb12PhI/TEhGGmK2MmqSIaKXa
zItLQ6K3nIhsTT8pmTFbkMos0HSP2FNn6EUUDHP2GkjJMvMNGv7CmSJoSqNEHs2EwX9C/wB3Y8tQ
lcY3wTADwxfsVjcDOD4JI0S5ZX0I8aMunfZsLex2ysm+UQf/AFMYWxVVyk0b6CU2GMvvwQqHsltm
N+4T0NV9iRHF2WBRdi0pgeBV9mJxRWWZeRYyKTsCfl8svqY4Y9iinoYrErcvsqAf3t9mOCZmjPBL
wJHp+R1bV+maSeRDyZgfrptIg1qydoXsW2U3MVFWlNIYeTQoto2iXlvlsi7E9Kj0JDYekJu1xRG0
izhlY3YqlprsdLGW7Wu6KSS9jdVi7HpMiNiVDFA/Yrru0K9vcIpN0PCX5Iabp5LJMLOWP9JhwKC4
NmSDBZ3cgwrOUV2H3opcCOuZdDeWJULcQ2PBMZU2n0MZtC7ZZ2hqUSg2TTtDDYamPgWYdMYZfydZ
yNhnG7HereBLxuqM2peGKzEYV9MphtPWeR2V9GUWqvLG27LfkW07d5zCkHleR1twmR15FI8Klm8D
yKzcjElF+hLdaej2OFUmtjJv6N8DkmTE8jitQ/I8QBJMgo0QE/WDfQ7QvZzS5E7DfIW4pTRJIonk
0D+FOFyP+LQM37OkMnwfwwicN5zWPkjYS7oxAwGLbOQiMsrFPIyB/dT/AF8TzEcAQWQEw1IQvOvD
+Lixn4HZdWox9jLHmBZHqq8tFrmfI1w2p0TcOw27MaJxVoMZkYG3WH9a6zHBewM4Dsy6hiivHOCV
ffbGy8lso7Q27cTGESZv6G0kX5FVV2Wf6N2vszDAmb0bapyi+Rjy4yFNrhERRdB5sdjk12Ks+IaF
2n0HlhiNDofev7wObsa/+BvDL0hzJO3XYZ2J5N6R2V5DXfA9m3kmEbHskJVRYG3jJPBdIPVf4Jmj
qTNdJfAk1on5LyhvPHl5GdIKq7bffxcms/EehLBC8MScEe2x2HP2Z4xG/Yy6GyeGT8Ig2pvuOQ9f
JoxDtNmINzgxGsFhCH7tr0KFR9GJbT9iY9XoiHV0JqZk2B3kCY3bwOYrGmGxuSl0PDdhPNTJ9Uy1
D2NnOhKhfgrwHSFfGF0SyZhbr9szjH2PbLyK5skWNLrop185JLdEIZrH0gGuG+BWgMXzGR6xDqN9
qMg2XkqIfgwYvImPokK6/QzYHlo0x8BFZD8iE2QjiToWzZ8sfRmEWSJkXsQfePw+DBre0VHgxRZu
c0VseCj+E3ojtxltJyqLPsLi2fEK1rU0hgxiknRpz9miW+KY2DYisvFMimvsR6p3yUy0vQr163ls
fqN+ReStD/meBdR5sbb2Jqr84Guq83gfYHkiV9j9gA7dcdn0aDDKuMn3gAxCXJb5emIKk8CYKhhM
PJQNP2O6jYYNcRwQAGTBkrwBrTI8jnLBkOAGxoOA/raHCDBO2ZmsBYV65IWn4MYLVxghA2PvY5lO
aXAmoKGxlQ2TE+yo8uFiqOBvbfQnphREQ+UNmN5cmYqg/pzykYl+gppgs6I0TtB8qs4Hx91yHKbk
0T2VeCq++9Ewi6bMnnK8nZfxFrG8IcpZSYvjp2Rm64bEFt9jG4sAKckEPgNMIqHzTdibSjW6rEEV
do6KK/YZdfZl2fbF1Da6YppG6FEy9woDHkMRHYimx4HFlMeyHELN6KybFGYaRB0cgfI3QwcouTrC
zsEgsvNiK4vJBjRFwSHkyYVDbHmmXSaMsSib5F7H4M1CRScGQvgXA3Em7QlpkFhlVGHgwkXnGhyE
Tuk41WR+cj00iuYvwMy+Ibbbj/8AIo8vMRXPInV0iFDIwL7NkNplcD28T2MXJ8PRLWAkQglNfAzq
+okZ/Appy22kjAokPBU3MsyfI17+MWMrQVUTF4VDJA8YaHtF4hc7wmo0KwWTQVHZfyH+eZsPhVKF
tjAkuHBbNbYpZ0Q7aJYyWNrnA+7CrCFFm/oFK/Br4Yz+FgjsSSQ7insg0Uk09+CW/J3i2MtvQe4C
u0QbkpeD9iAvWlEL0I0I7JJj2KWSTin/ADgO7EPNJ4HlymwtyH0LgQ4HuDV+J+jQzgTWBFSJsbvx
lqrDKdsa1wdEkCcEpRygrFUtcsyLuEOzJskTLZLUt9D1gcOiCIgf0X0JpjbJMRhyeMIG+hwRFFRB
WUk5MpE8iShOhGTloU0lnlGF0MLIJNnRPESGiwmo2EkW+RdwipJpiQz9vi5FcwyWnyMHA9umCyJV
rAtlIRRhXVEYscCYpCSZ2Y6WuRo7JnAxKGMafCZJO2WQyvZjhNjWknghiIlyKFEvApsHjbwRZJDl
EEoNGmfRGgxvUMnZNhdaW5uDlpbFcZkRGzpXpBgZYLPBswLOqg/RG4Y5bPImYX0cUCqorXg3vux3
JBrw9iUzS1UmhKJPQe8G5CBSeWArpIkhzomOVE0H3CXjGR5wGCrOGLqSgskpOhSlwb7ERQ30gbO4
TWEQlQr4KDGV0YuZdCHBQYImS6rnQ1H8MGMZJ4YpNRJSyhSQC7gDQ1ZCQCafBkEjc+GYjdB+Emoo
IBoaoX0NWxMOCBXswQ3lpmBL7wILc5YZILnbIRzl6NReBtW3TwNMC+hq2xSMuadHshpY00GmnwMc
SVaHLRp8j/8AEyhIomahgNnfJM5SMUQXIUEJ6DS9QlGIRD4FyUS0yQCu2UJJTSZs2Z0UGLazBE5T
f/Air3cE90lRoQMyIjfBJBGLMlJkUTv2Ul49Idbw9Ibw+uFRv4cntohtXjmSCmmEbEnEqE5KGiyd
jXtBJjkqmzQlCpSaaM5q3RyWvJG3SNgqtlYKLhqrZPsT3F4wRoHXyGlnD3owuRrMFASaFiro24Yt
lzbgqSL8DfRc9D5ua5EfF4RT2y6eQxvWV1FBk3aFKJ2lgZYUL5vkTM34EEthNFEBsJjw6EdWecGL
MR4L43A3whKzPGBF+Xf2VzTFRWKjGC44Na6KXfokwaGM0522cilkbtEKS3cb6EXPGMozGHfLYRVV
k/SBBpkE5Z3p5ZeJBdU7P78N4F2PIsfGz6DOYP75HhNjXsMzXR4HYcZhJUkg7yJm8jmjlyqKzYO6
kkkJdDHb3Zp4IPcFWVON7ReWGLkWgukrvNBKm1XAtya5GKmI2PLORmITpDbI10JGx2qZE4QxRic7
wIL1ZBnNJHcppk4ojCGjARlYLZDwL4gckAuBoWL1tkiGdecJ9jNktLoUQ84MwR5ShGsX4HeZnSNB
agMMu0KuWGNx4wPbZpdjgZoq2gu8jhnCzBthXoT400iMLEK5PdQZGYxUWzZkEyrpF8iy/wCldDs3
LhT0LhoXVvpj7gQ1m2UqgI2A6tDmi0TF3KiAmZmRYVkKkQ/uAzHkKpDhpTL1lmJPh1aVmaGWJllX
kT2VcGUwojEhGBlllj20tGAYVNgKF9ds0soayzPgBVkuDDPkOQg/uEU7E1TKQxoYXFoZDLIgOZEV
Tgjs8MWYyMyLgh2FwLBMlDxpiNa4lQbjI+CKWH1f8ENNqMr9SC02mrTn41Fw64BE2LgavKOcMp34
pdFkU5/eC1RDYNiUs1JxuJvZZkNRjCin4YHoii8e3kQLaiE9B2duQpTuMEx3f1F30XA1MmZfghVP
6wYS5Glq2oK1XmyorC4Q1IA0MIuRbKtzB7whl3K/Rg17E/TgQTycO8dDEbyYKzyJaOaU4HZ7wJpq
jH9KK9KxomXb5EY4mL704iFmjppuwjTD0Es+VUO3ga7NwTJiFx2cRDwEENIX00LmjdeRaqj2MO3G
CorW3KDEyQ8Q/wCsB0TYoJ2fURRglF4wlPSvBZez8OUCq5GPK04G1EmNKNNQsCJrsQx1IZeUhqDX
jZ7nPAs9LPNBMUom17Fo0hDYDZgkCvAgEqcF9FRV6ExxhWoUjoiBNPxt3R4JPpAS/aSfBbQqmaMn
bsKvqGJ2RhMS4EYnyY+UTfO+xNKUtGV7/oIpASPB56GDCRgf2JxkSC2+doOLisarJJ4Vq5GLkQ0U
omUi4DyRCVOornYR4mUaQh8jezSKDoppCO9S6ugirf2LrX+xZpLcXAO+1oXHhs+qCJLYNhdBPvQx
fsPt7MhoVIaBHJwLImHls0IPLhtikNQ4gFb5PwXjNVpmses3I1JtIOY9GRfORhmbwVJjj9jg8Y0t
57Go1GFJUii3U3wOuBxItiMbMKZPsS1LQha5Zjgy+gV0kQOjMAUjIwUIF0KQdc4LPbNMPu9ib3ui
NI8GliCqeRnZcikNbgxvqQb5gVsmI6UiuPli4i9xTeg+0dDQmK95JAjrVHHwpmGaPGIzrlk2Ipy9
kYFTo+rHcMgo6FPMyVh0MinCFUNa2JVSEHb8DqYy8NC30UquoOimMq+yCjX6m1M3REmeB059CKzs
j6B1z5Iewnro6kTG2BkkPkG4GhSxn1TYORkkEwMYjaVRDpbYiVOnkqKuZ3AmRUTkg0huZBDyQXtj
dURa0Y0yjIsx7OAwkqG8exbz7tFtJMzI5VlMJKD0Hpt9FIbeO0YqEGRleRZd1NBiJ7T+hY8kvHAx
fcJUqpXViF5rLdKhnkMlg3w4HJSLLJFVXlpCqSrJGck2P+isb8QcacGIlrvsZ1i5MgsqsfhaYtfY
8TjZVGVxyujMeJsrXD/THdTeSRojhne29Tgf4YcsSrsBvAqOIgyay2yPd4JC+JSVIUGdrRNicKwC
SWf5kQj9CGhlWwxmyCpnIzU6vAzyhTzKIfCiq7MFE6yQ2p2lZ9nYh0LraIjE3nnRgfVRUEXuBXuc
zksYGIq85kjZQ0hFeWtj0avSLd5BMtLlcQ9CvQltUmuRngqJSpwDQXBKC5tIGWVJux/OeTE4tMf4
cuLyUflbeRKBm0GrKo+RapcKUtU9WuiaC5OCEb8xUU1ZRyWDepwOuGBK5HgROoybI0uBikVtYj+j
yOTEONCFpNFbE4nJjbGkOn7B9sew5EUanllIaTzwlR3j7b7hatyZ7JI9z9jkrhnqCNPcKIl6IWGW
j6Hslq+EI/iZi7GmfiG4zppCB7IejqIqQKQ3uYTEahqBHakkJeWKmmPLESVzgNs5YZGN3f6Fi5ny
mrTUC0PJk3ifBl2NVoa4EHBNIWxPJt/BNhONuDk7kqH0HDEUg+w0BTp5Is0XBW+RyvyEvQPY/GRo
XYc5hk5a2IHDGqJdohNCHcHa2kYJksCsLZceRkSyy7wY5vgybbevgBobbkQfQthcazo1fcYGMz8Y
c6GNbOjysIaB0LEdmgYMsUfYQXMfA6HnEhsZ0F5Ysp6gPzoKDgyYM13UU+ZMMa0JdGVbkv7EvGlm
jk1IEIK4EojtJTFc7D1EmR6PrwlW6i8T2PExebURUpMi+0QWEJz0E5ItRVgTxbdC1+RsyZaxySCy
IzHkVPAbkXgsgTQ4JwvxSaMRmuBI41kQmpDIwieBOGjlpRbMQ/TtHQ3oRvgsu8JGpsRZ6F60piQb
2pRuJqxLkWkeUhpFKmJfexCnMC4on0NQkCaC6RoZdB0NRD1J8cCk0H9DAtHpkYZV2hPoVROzew5D
xnIl/Yk63+DGU0hM3C0uji5ZEloLtqynLbFwoqM1OwpL9oxhkgglZ7MEBPbH6rawWpwQkIWtCKI1
CQ1ipTY+cBgMmsHW+xq0akjPOnCVpLYSzseTHCSh7VDQdGZs3TBwLZsWRRURPbrApboMXa4/ZZ7M
q+B5Fcq/zJODE5kKyE220NCjYBg8HsWals1DBNMY+RO5IZDdhiNS1VlhAjVCOcODL5QOTkdHWOSm
7qy/047xKKcRqB3/AKxD/anbYZThbBU5vQbh+QL6Qad+SpjEE1KZkgyyrekJdPVqGFiUaMhSXXeR
jWKrYseBbtD0JqzkbcDfFWOY2t0xtjztmcCFshdSfRCQrOMlvWSOA/Hkdzyx39q0Oj3qAtrtBjTn
FeRwYKpGGPsGZJMSjpC0ktxRxaU9J7Q4KN7N89V5E7CYT0ZbnDboXXOk4Y9BlIzkVDEpfshZSdTC
hrEssMzBjD2Pvmu2aJinyY50+ZkRcGht0mRtwWfjkiEug9vgfIzc4HoQ40ayLMhrmSL65op/Vqad
3skYtGLJbUs7MjDyZ6qwIAGJ6IKgmJKNyWvIQbKGt9C7Y0EOYYg1Fb8Kuic/GxIohMI8S9GQEocp
TgUONAMw7VRgIUhGcRtCDi4yFPH7HOmDNpcbQa4Ku0rXY0r9RUNXksJp4HTKYkTaPs7l6oiQiVnQ
2gLHYk6GORtU9sb6iJk4txDWDoYYpjL/ABZZxHpUVcXRsdGReB+Qz6FsfOBypZjq8p0mQ2xRhHSI
/QtdYTojKpJRMYp0LKxMT6t6FkaVfQqmuGxGCldswJGOyBrbobZusQJGGE0jIL+9i/1BMfsKNfOh
URVCHdvoUm+dlMLkIBTvQxl+xhU/ZjI0ex71CVSW8o0LRMfhimwLXKP63eSIN4EVcxWMi9rkpFhS
VjeRu4pwQ2N9C43l8icki0Jehh3dEUlYIJMhLY0SYXkUzb7MmP0xeb4tcDVIv6AzE7jya8G+xB1R
tDqqnbRMfSHRZzlmIyuB4ZdCmWy8pmXv2xbcVeciYZpVkdcrwPzbHQ8lq6CCYBpXDpse8I3RKi+h
N6iZYycOiSqELXVl0tGm+Q9XXQ+n0Xsb0jpc8C7rCyIBEJC232Vtfs9+B0abJHMhpwhawnktixxV
5hgcT4DkmkdOcAUhzkn+Dx2C7Grmp+QqEm1MYMnHRXcxYEzVJGKCvSESLZFEiPMGMSpMhNrB1Mnx
ElHd5TMXhK8kWRiUKh43ksKRnCHc8ylwx/IsdnQTNAmstOPJJ1uFaN44HDNZ2yjQ2TXyJ1GDwcXe
haTGihvgitzcPj4xbED6Yth+jywYfsAb80sWn7oe6uM/Yt2a4SzXJJXtDNN9i75pntbMB9KxhK9h
So/wTTx1NoPliZqK2zT9FIreUZpX2bjjMwq6KixOynhfRKl+yL5kYxSZWofKKRrz4IjSjOxIYNr9
0xuYbpowTFpEVWr0hMm9HyQdaNhMuiSyOGN6MNbTERBW/FcEadPZgPXZc2r4OGztGHOxVPfwbN/G
QyiT4GfkQmNaI3iNkWWI8VF2bqThDw1ioFfJOF6GZj5HlSb2xvZ+lwUjMbCDoMsIhPR/oj3ojmfg
L6ajoNFfGiNE8Cw+SHglEaLsPJkILRr+xkqhOVEdx/vAjYRIZhYZIfkzIQ1LsdWv8DKT2FoLLcEh
tMvbIqul02zEqwZYn2YBr+xyJnZYSTSZGg2L2M2MRs+jPxN5Y2baPJOBNgPIh3EScwWW+gV3K+xM
HZEO/aHtqPUYp5jgTG3VFfDZmwP0f9AJD/FlU0l5LuQ+Udw2WCo/oD/UKIeXTM8OjBMXhlxl+R66
tFoeSNZFZDaWjZXgLXbjk01W9QtOLeSGQ7HoUkUJU06MBYc5OymfgMOXpOi6doE5J/wHzJrybZTs
Ul8mR2f0GPuY4w2O4zlkheXJTGxctAy3uNFI0d4GfK1/TL1eR426Ck6fZazJtwWHm8HG+rYTtq3y
JFQxrnbDpgeSEUXb5QTxz7YwnHYoKRl6lAsq1Oxqw28HMbA38URc2IZo4LZfYh72FnwiBYZfIurR
yZgrxEWv0K7ZBhyOIKivQhZIfm0b2bHYxKH7NPQ5piiKtKOF4KUTOBI6e2Gms36EByvkRBCifeQk
0bSCQ7HBTfARhf0ZQKehxbOYLZgccXKhSvFvYik9aEZ5fWGGM+yUlkRct7K5Ne3DgA4kGR1I5Bd9
8QxFskUiV4YgGsIOj6Bbj2LU/Blwl6IkUGw5M1cHk/R1exNC0+rgQ8CiwZrI/DMYx0K60Z/FeKN4
YfaIXXpuGSkzhv2JapdjAW62FjpeS3Zoeh+o8GiBUVSnJ3YVUSk5XI7Z3odYWGpwQc7W4JMMD0pl
dSHDKkYzQ1XFFTBBle0ScahYaNDw3BAlSTbUzGs8NU6TKCrZETyKbJ4NRl+6L9jWXW0loQCsXiJ0
tDc5DpujcbFrkSgvbbcEy79Foxp22uzNf6fYrU8C9sv1jKT4OGha4+HnjYfcTkvkISHLzyeMifG3
koXVnkMSJQVy/FIfdlmRPBkiDRH8TJ9HGzVjrZubErbJsHq5Zrk3olySkZEBIh9BP6XBR4iyKqys
gIhjYeBGIp6JLTnQpZb+huxYQuMSu0MmNdD9QiCGmbHHkzR5Y0bCVJWaC2JDkXQP7dpNton2kKpn
QmvwIiEHUjQl4oikmRYGQkcJ4ByzpWoiGlMWppGoJIdqmnBdwuwh4DkRUo3pEEFSzEmyYk4PBiGm
hCX4JNcCOrdBWThEHHI/FVHhLeCOySE0tCBlQFs2K2McLWBYOmVlEKyeSCfgOWiT8iwiLxR5hYRM
ArYPaGF/gj9FBM0sENgcJjboh7QNHc+x+KSDUzgeEE8+BGRr2zK0kU8JsVUuIhaDkhjyTFRCIzPB
s5TGiS7GpVscCMOmk9didNI7G8DOqWcHCAKBNPoSiNwcLY9DJ95oQ5HgjThkArooTzBeBu8WvRMQ
heGTD9wIdzuhQPCHlINxCNYMciGkNKSeisRCLF1pC2pSG5q9FzmfgUkytoR1cvoWnxFiIzg5BfIe
coRttPwWtrAl8WF8SDdFKXK/nxMljkmRRqTEpwoDc3dPMFwaxsaKWAvkuypKJMGmTNoJUouDRWcY
y0OVNl7mgx6dCNBQKQBE1m8Cy4loXqdi9H/YhtCK6KBJoiSvEqK8GGhZUzZN3hYICSXMIe0SRRT1
bZeBfkUPIiQTNkq1gdNVYOafYoAr3v8AkWyTC4fF0swNZwa0Fwr3KGX+BmKHPg4I9PyOrapblNm2
3RJ4YvRCkjSB13WMBCLuAyP0RrgYs5cjV6IwaRPJ4EnUfwHwJkijcJgOkNnIxdmGaz3RuAJwWPEr
XP4JLhgoTHyl4g5QngeSGrk89h0YUs1o7JcKeELZBhdDsnhJ4P5lFDWVz0SiZsowlMEd+oN8opR5
OmkSeKKquBqJcnwLaGbwjk5V34LpGJHNcqeBm7y3lD02/kXnq2hDXSBCyqyypGxFQijyGdgyCkc1
DTkKNlrvhS7RvLMIYT2gT3HW3AhJpWNAvYbetiE8in2L4yyysLN+BjYcc/Eh5K+zE8jfonUMmhOB
gGTZbQmazLFT08MV3mHKFSG6SEKbpIPeb4HvQatyie5RUJfjJLaWMjXaGIeJd+HCackGNZEhnPwa
5ZkOBeCR/B5cpsVI44HOxEcvhCw1NC3QIpB9W2ZVwaDzuPiRwjGCPpSLBZN1XksNDqbGX1fwVjeB
3Vs7cy+xvgX/AO4BPwXgwdeCZJ+aTQfBDjuKwe0cJSfRhqNMfE0uAjFpofiHDP8ApaZYeoehhsTT
4E+R4onKwJyKExeqix49FtwG6yPQ3ttZJCsL4+IU12S6Ze4M6KDZGxctifLpsrlgRk6wOD7YSTmH
cIJtBGv0iFcFUb/pxVWDEPYrMTdgxNlZgZi/UKDWNgurfI8FwoTIlCbGoijpup8UVXyCeB2AODX0
MgmWiS+aUFrAz1cjXcBnTkXPIJMy7Fpf6GlPIzlWMkl7ZPixoSxXd/DCwuUJStLTRAcUQqUjSogb
rsRtE7bFI4GqO2NQhVWVVPTCTtTAmZg9wh8mZrMjEWGE+omGILtRDI8jbU9PB2bSLthzjpoUd1TF
TTYg8WkhKzK0YA0kNYeUzDwg6VX0ykg3ORatvIk3HQr12HPbT4Kjkd0KReOo9SLTkOO5RLcE8CVj
GbYhe2x+mv4wgqnxk7RKTNZCIN4CzmG4IBlJ/wDuy46DjNOEVBAeoZ4IxPvCqK6FWN1CoCDrNzI8
fbgQt4CsKLkbSaxrGSVb2GXAvSEjfhwWxwlqStNFrpbHMUkYiBMuxkUhLItyAyU6uIOua+jQ34hB
geTZokpmNo674GlBc3oba8EHuyUoxlWNNjY8xaOTB49hXlsSnY4SEo0LyyWy3qqwoyJ2eZqHmKlg
icjTyK6zm4LbVWyZFkwNEUBorBU/JyO2NK9gKMm7hoaUzIpKumiCnbDwPmDXkI0C9owxtVQsNU+o
53KbCjqTyzQhKmi0NEu92OTvKuBqnl5sv+gynknESb0K+Rj+lo3eHwP0DWX9FuW1WvwZF1BtjOB6
LSMWxo+ip4ETdfCHBuycg7ZiZM4VDL4aCinQUt+i3LIXZ2uh1fUYhZwJ2Wlx0Uous2MyCHuLmlyd
ivP2LnoRWlobI1yId/DWT2XA1RvDwJMo3ES76ie+SW8qJTsm9n1sxrsQq9AuV4HFtitmLxd2+NWd
J/BX8C4+B58LMKGDiCkn5ZQjuMf2KIY/wbEPKmjlLq4EOeSunEMwbGqGheQXZ2yEZwGh/wBEO0/g
8SISl8eBCUkhUTwELayNhYQ4qYxhDnzGSawUjY1bJYpUJRiJIoETL3ORPRVcBTkyg6zJWZM7tyGr
M4YrOtCJm1nRmu2FpLkoQbHNvsZRdIVO7HRPJ8Y15RWCMKIKzLNEuE7SGUYhDVoc5g+1GkbXXBop
/wC6JkS+xbV2Iu5Q8aEZeq0KusJoRPrRD0IXRRLS/bHhwQjgMiTHQhTtNWhY9PTGRVljBXUAgCN+
GVjdnLEwdzoTE1DG1HlkejIs0iOM/s1M2bzKiT+WEVhFMjeHngQ3LFZ0BHjosJMVCN5EFsFpGOuV
YtrDgz3yabOC2kei2umODeD0/KYOGRmnlVaLXGNeDMpNMvA2NvMsD+iEmmN18pgt/gWRvb2OXHbA
+m45kmbFjYHfCTATWR8BDm+RwbROQQzeRPWjsMpP7CRrwf8A2PFK0wVXwlFm0UY/OeAVccAPHliK
JPRDkEXzFZWYENEnBTu58Cwma8PmjoECiVwEXXTi/vEFzk2SWMCJbDFp3htnQaGzhOHGjdnP0Y6a
7CImusGRjsqYouq19ihkdaCosBsjCLCK6KbTykJUPiHZUrwmaMAQw3GOINUCSgpOQ07W7sUfJslK
86x+NjIJaaiLHAhslhnJf05fgji2yrofE7ZSKKhJsY7bWH/O9AZmr2MXEUherpf4Gkh03rwTCuT4
FiVeKRGleCcfkxA3kVuJCH3DcKitRDtYCbjf6Iqb/QstK0CiOaplj2Upc+h4wnlMyRclYck8jZkT
kcPD4f0zfOeiqTGJnTotwqRCLApTNNyCcFEgyJb9kIy2Z9iOQdUGuLgVaFrIiwWBY8sXkGBSwOkC
wFInjoS24Pml2MtwKCNojHRMIzNEzYXIxUl8pUIbO5HP7uD0OawUCG1vFNph/BR9aJqE351skT1A
uuahLu7NnOyoUmFakO8R4tFKLBwPjPDIxow5bFwIVVUcl1bWSyjvSGpIK6+K+QO8jSV0KqV9BpDA
XgRWtn9IMiXAx06nAnKm4iaHs7N5CN15GeOTbdt+R2M4XwCtOBBUgjYWy9DVrso8jGhHYIOvpCoq
0JYQwYbFfqhaW0ZpwiOvGRNOUMW22y6ZrJhG+xxXDY5mmWedEmy5vFLNYGMEcEGaio0vYriRG0i9
Ij/YChlgV1zUZgyxi8YwYporwJTbqY6baCRQ6eZQcFUKFKh+cVwhLEjkrzIWa0zw0xsYo0zviexe
acYhSh3RwWh3FRIqZGCwTiJTaXJthPCo6TyG0egj8iGrHJVcq5MHVWqZulTw6gkriclFvW+TVwaK
HG5WIYLCwcKHkU70xvaJBHLYGujyS5fAlE01qDqFI+Jem45GLCtDAJhiUurumArZVIwtRkJLiUk1
TH4JofUM7o5FXFMa10MwVSDqXKaK9rbofTubEMbqQW4U5ghybagxs2TdNIqr0boaocodcA1qkFUP
rTagpW78iJKBtwJcdNj0++qyOjqto1afIhuQZBULYqiNhcsZhIuw2RH2NwrpiG3l0WTGcZFHjdJh
xFTfsmmGj4DaAqahbbo02MzvahI9c3gXrbNA2si32R5yQB3uoRqbkaULUOapbcCO3McobG7xIMJe
94g83Uqje7wNxhokjgKYHmd0oIq9Tzge3zhLQnWTA6NQBMsk1yeRmU3lXgeIU6ey080b6MsEcIs1
snnknan2HYziMbpN+2Nb9iZShqN+AhtTpi+4dUyzJzNvA4VRp5HQJhik6FRltsR3oS1eD9HzPaHD
FWNn2AhnSsOozIlEynsmOgoZT24/ZZpyprSGp1dbZkhrZyPIsDTZgYLrBmMhtBxhlsfwi29OTgUX
9A9yNrEFEUfBEiyaKytR2DKZnCF2GdiQUY0aHd8SGhUYzCXQ2J9rR/cHdtjQeRMjXTFssNBL4WCD
x8bOCTFeSMiDITOhUCBN9jjl8DvexKnD9GySuqbMizPOvIgqzjqqj3uyZPf2F5CLuHSNZ9seZDzp
fsyaCnQn0Yz4H2E1/ghl57Fel7OyfAvRJcDStU+hIAVTcDJGitiz1eRSgoYr8mXzewqpLWDO6sWj
ytPAnl9saa/uj5/2Nx+RBA/BWLWswxXE3RnRK0LdVpiWLsQVrwqNTwdj0MZnTbZjh+xr3vNG4+Y8
ZhGSVjSGJ0RpQm6SRvmDBmeWJbGEID1hbNtHJyyEdigsmJ+DOU7wNdH2Q3k6qMsPQf1JByOx1MCW
AO60xdUvYn0zfkTBii+VZkT9mZnsV/7B1UB2Yz/qmQeKxV6hBovAn6exIoTLhji7b9lbn0G1Thd3
ZROmLbJ9oYt3kRhDuDLTa1WZr7o/PkS5t2ISSdvsRazOD3sGSjh+CMY8RWuA7rFlLBouDdyJUwVH
RMoYAb1qigt1cidtMPoQ0pe0MDOs6O0Xul2tU4Fs1+BjgrDTNBHkGV9+YXy+AmYEt/TIgm0IIz0M
n+pYjapr0YuvEqWcWq+2H0mxkrcikfRResHApbyJ6oRoc4ruOzozdptgrYd11sz00pMeAlYtR6Nx
N9swI80clyPkb5rG1V5HSmuiQmhlTJy9ukPiq5DEdeGgeI+R+vmO56Y4OqZ5ORZVkwszDCn5ENh5
DlhOCWQeHgtvloW3nZg1WKf7w3yeRp0afAl0wbUO6Ds3OLwP9R5g1a39iTTqi2Z0oyyNPlUjrolN
JdkGoUWHAhhmfgrsUlLs6TkZvKquBqEy3iIlJt19jlJ/ikK8l8Ur+wh3OnNz/pWLS6HlOh7ziAno
E3QuQSyz8GyMw5O2LPAkk3ooni6E/eRJ+cRnYew9N8ODUrE22NUTyYEHSsi6Kms7Haxvx8dGeOit
OSIcqgWdfkUkvURnCKBLnqNaY+MPKGn/AODH5+hoSX6IoRdDKDVF14D+3WOjQ4PT+DZMTgWAzZsc
jT4MnkayIMWnInhp+BbaUGTBNAakQHM8QfSd5XBGt/BwlezGlnoVRG9YENRakUawHafJpExOYjN1
iBovoNiIdfAqfUhn1aOWuSIMehl5ehzAvLbztHMmXIpucFXGxHZNPpo1QOuBOeD7RTiYyj/RLLmU
RUsR5Fw03yQ/cRZBpaQ/tfgWkIPQ0aZYWiRLYlIbOYNcuj7XhT63ZKxEJrJwMIfUKJTc9Gerfgtx
EPuXQ1Ba+jkSIscQntJ2RgFq1TUWJepPLhkXWNKCsprwXWvS5JK299mNGknwQ3+CvumUaG+H6SDc
Ogk2xUKUzgzXZvWC6yhYjOF5Eir/AIN7xCKSyYhngNZg2on4HRs9Dok09mMbehY8RAdoRFd3BpO8
nRs/VKKqi54twWwn8ENUCO7yoh5qD0DOengROJ4HePYa2MJSSo5VQvI009FDl+rEetBJJt+ik8vg
Ss2hgRvY8tblIaN4+Ac0yUPuCx9BHLs4ggiF5a2LFbFoyLqwNuThyjArxITmyvR6C5oa0h+zJLxL
RZWdMUFIpQnCQtnumjXQcobhjiCyz1Dk3eGhqqeskTHmDyHe0N31VaN6lcoWMkkJslrbF+lqoim0
2uUaEfgeIQIS0dvhezYi7FYS/osxZ4JcHMWrkRzDcEPSFjaRO6HV4EJC9iH1YT6GkcH4NDGSWzCk
7g/GscuOMcjg/O5WB8AhkZ1Uh+Wl7jqDBdWlRS7Hp5PtCJ3NgobxGsjV5QkaXehn89pEH174MKoE
Nro+glc4XCF7gx4Geeqhb10mxl+aYcOCxyhMwvwCvQ8i0F/zmT8C33t7EuUTA8ijyJJpM+CbomwT
2P7vF2GdyUIQs9buDmkLLo4ZEYoAy5Gjmlac4ZRwWbSWF5F1pV+RdqIkJCOnIWhE7PgZo62EKijk
uILMqsQYUDlowP00tiNbrhDbaENCxtuApz5eGyGupi+HAl9Dk8BK5nzSV8iKqEJQ6bJVLZnk8lNm
tnZONJEHpY0oaVGh1eDcIJpQnhROCjK0XJjAxRexayIpy8CWZDmEkdVGiGibR7Kvwaok5IQ18GtE
bKkzJmQ2gIqkkNkp8CMfb2KqINAF/wDwF9T6Em0MLCD+79DTSRBilCdI5cEdUl4Iaw4kjYr/AHIM
psOz4DvIHEohqwMNgzOBBSEJdKlRbYyEdMngSbUC4h+ZsFwYcJmWY30L4k9GeiR7eOXhcouuVjy0
GvnXRh5NehgaSaGnblgXURegmyJM1xFXY8ig6C0ht4LSjB9WhA5L0NTVCPRxBtQhqtnXjsxUorhH
H6wGkKUxxhhadEuIQDlGG+MIVt72x4DBLbSEcBGO1sYYONJGKutj73C1uDmrK6sNyhcMw1H12P8A
pI4ITo0CxSgwwPGgqgP9U0KNURzizN1TRmTjg17Ho8NKLXfAiNYORuhUmiXohoEZmIm9hh9pEhDT
XRNEaQpUruTIdHAli3KMjSDgq+qKhlWEL9cC1DDYjKGmc/A6OlG15p8iY4DHrLcFFJqDUhTwK+D8
GLh2XlfoLkFDhUehF2ji6HpFwaFMpRHVW+MIiiMQzMy6JIuOiqrQU/dghU9loacEoSjZyJO+jD+F
vOwmCsWxlTVWiUoKDJuBWrSZQdeEpoVQRr2PSVZMSsWMymDkteBO/NgSrq2UUGpJEVOzHChtf0Ro
UY0MhUngVVIkSqUedCpiBjKRZiuXt5GmiLsiy+xZlZ0GqzsShLnGxmKT2zbCsdmEh3kT4qaOO2SY
k27PeDBNm1no1RKNNYYKAuBXNg2GD5CKL2f4KBSaog+VpOcG07WBHcwxa3Rwqs9ViWq29BYlG6EF
teeMZmqb5FclH4GzjLpbK/BN6OX6HYwZhnVMyFdB/wCRJ2WURGUzwJWbewwgqMg7MLY6qYqS2OhH
th04wIaIo7LIcYY8CSAmU5yVFjl/gsQ3YaeRLSLQ0a7yyHQKUymJnqON0JwDPdbsENTQ12KC8wno
VJ17DifnpvUDQvI1+B+RMUbgmL8NxoeQ2NDlZnkWrOfIirAme2PMltFY/wBmuMdEN3cHOqUjQxm9
ldHQ5coiNxIiuFzaLJL0jvHGzKN2/MULRNKYeTEbkyLI9kz8E/lQT4FKlVb9jaS4OaIFklwalQXO
PClGMFQjvMEO9C+CG6aKF5yNtCpiXAEFql2hOHszb0I1DAOhlgw1RPDBtlSHNqisaIdaCLc4MBRV
cB7HIbZwk4/WKoIMpbjYkchNouB1NYGwDLTkyNUV0ggaohNhUhZ5JL1TLTMRYKDUD/iEa5FtVrEL
cBPOC+bA6EqjWGeZmRXZaiEOocN4wslzMi5S4CNqZVJ2BC6GvlRoHgTZjVjiqrk20IqllJwuml7D
2XpgwOaOiPpC3yPbiMcjpCng6hz5yQPoyV8l/EyVW7GKT6PpiM9bw0Kcy5UlhxhmQxXI4gS0Q1Nv
JpVCSf2Mm0Woxj5V3gf3CE49aI57FrAhi5ZoxM+RKyi3gs1FlrAbsyEkyhYZynGffCG5llCXEEZF
wz7aIpWnwLT2+AlqEzjEYUJD6OM5FFm0eAlBLoIqq4otOW0xenkSYOo+rKFPUT5z9xii0wIrP3dQ
ow5Cr8hfXgY/LRFrtBERA9bRZ+5Ge4F88UUBKvYRo8YEByNMV4jidTghC7TLZ3RXBXeRE1Wi9iPg
QhINbMmQvIJhK/ZtPQqa21gh9tQiFMVVHX8E+9ojJlZGVhqsIzjFk+3+D1jOej2RM3F2Q8apk1sU
4HsiyXwSE6iOqwbN6DcCx5C8Z9mT1yY6zaUZ+ywRiOzxFi4oEYdDC/MSWoYL1FTcH8pW42aWC6Y6
nxcah1BojwLoWUzK5Srggimv/mB+GFbKO8ktgQRcP2L0wEx4eX/4D1j/AEVKlTSpNYGzZRxKxCYv
sbgjY+TExaP4SwG8b2WxZPCHrvA6TZz8PZzWCOLPA6TkbdSciyniDH1RNTWA23EGKc8QSzgaANZU
wbtahzSy6NjvS2bMKx7yJkbNFMORKkJyXwZEmLTiosrrEf2CzXzQ1TuIKuitPUiKKJpcwaRUgbya
0Rz4tEJ1RPcUYLjaFQWRqc0IjwIxY9eIZqZaEO1ke2aMyALZzgevMBNTAXM+HaceC/kTXI02RCJk
eIzwQ2ghbwYXZicmMGfkcM7edZFrfgTESvsXrSx7FqQrxUOUptwZPA4UsiaGsQZoaxDsGkhuEFwq
NWalIJvxTD0OTTinIunsskJg2yNaSs4MrtdC9oPpgQ+8oaWp0zIdOZ9tmEXkpjxxwLrKwMBZ6G5U
TiGeh2W8aK7T0hTV0GZSVHmZVN5I8CMrVFvWVvQ1WT8D6AE0IYx7FyGNWngpLR6R5qEWBDEMdsen
hoVHImdvRvogJqcGMDTu8Rn6CFW0+S4V3sKdI5KI5LK5TwLKYFGRMNaIKJdYGtzQwrYX/gyATZIq
uy7ENdUgTDjyaXIoJTCqCIh7czrwTjpGVWpqVVSLb0hCVlQ3PFCRsM/gUT42tiLQcu1czc4QtThB
1UJ7SZgDAMxywefzRCdgzW+B5Z5gzTtnmFPQyvGnyUhhQyHjgYXrJsVn3hRZuQoxPxDaI8P8GRdG
xCmHHWjL8FUXcZZbYJBr7uiyI8GxOISGN0MaGtocGnGhcyE1kTRzxwxu2VJSDggLWpTOWbDhxjH2
zoVGQbEFG1bsNPNNOihDaSGOwZRoYOeaPUr8BbRSNexv4t/BwTFDtfvs72B3sw5I0cKM99TiXNlN
E4d5NmC7is0Wz1rlboSNrGJZpraNkoS6kz62DsqRywqs69BGQnI2JGXKYRWaqHmblFaroy0IHJUK
8i0rLfRh3NJ2MRosRhXzA6lE3UEbp5fkVjBbrYy2yqEC0229ikVkUl2KIhAXesTYneE0/sSoMY9j
kIPBPRyNAp/9G3kPmKKVDcZyVP0lEVoxD2uPsnyTYzKmxxSJsGZtaFuBtyNTLY5m4EMKjGuZQS14
p9iGmJkT7IVyzLoxBhZDeRaE6smSMHgI2NkTh6aRAhkeIEKnNE0v6MEm90Xh3tzBor+g7K6KP9Bj
fJRjhly9FbaOUeRijKJIXJch0GWtFnOBykmYaDco8CMe7hqIaPBTMaBFSTJblYpteBkioIroSCcS
E91TYlKGV5gXZyYqEO84WIznwFSnybXgRnsFE64EGJ9qWZ00+pkw1jqp4Gk8q0hVhJGybGVF2YXS
R7cMJeG2SvcHg0XWmzQmq5hizBzdMI4usCR1SmyZ3exFggEqyFJXyLu5FLK09/DzMHTFQ6ngI2uT
u46cX0NiovBfalFPwoQhVsXi/RuhkedMCIcryEhdpkNYG7NNjaqU0PTJvYnghVYkc2ZHnRoYnDae
BajCrmo6Ed4z2TEqY7jwLTURok5yCG2gtEUESyQW+FvQ96REf9RDOBhOxiV45F2rCkGhSGZHgskc
VIhh5yIQkDLupgVga5NNB9ivOSV1wD4SooSfBMlf0PhExTe4QcabtpSKexZZiwZSfHexyrBaUfnm
ymfTIhWgbD1qiNlkw10LN7w8DBkpyMmkFMtWIIaMGTHyROUyvOxRiUmwBpxO6ZeJwMlYFivkSrWd
JocNIxGPAzTBCd8Iwwx5Yyo5oyzZiH6qwXLndTFJkMTsz4dVi1S4VIZWg2hrSmjPhJIamr4GAzVy
eYKMwIdG/wCh1U0omKgLoEMlZPJTG5DjUaa9BLZh4a6EdiG/ksFwV8joKo/k2ibE3U7pvxaoMG3I
8jYerrUy0mmvoawba7yT0J0NjZF8PZ5QxMcrMvkNXSCnGyUZQTXQ0LDyDeT56G7CbdOiGWdEqME8
4Y5C/szJU9UR8hcORkI49TxHOSQm68qKVk3UbKSm+yQ8IkmvI2+5mkOTz9sa1nnFSTSzrGxYdVS6
LUw1kWzqys07MAGUs8DLCQuDyL4qUBpX22sdVJlDWh0sReNmJRLA3wHtfF+Hr0chzPilP+jQ6jgb
o9WxMkVSgnehosVIHpnDyborZIeCQl7Ntx+GqzOCbXgyDJ4KqSy7Gqm9eR0sxjVNjKw4Dq72WGCm
aPISPXxRuj+CLwLKGJ2T6C4YkhOc7IPbPBhq9GZr0+4LXhpMvGZ4IdHoTvmJvnsVi1FkUIZS5FEt
7HkHlCs1UumVuK8HLC7FlbPQlONy6KbfjYjIaoyp2PkWLgMVGpbTcNVF5ZuJsSOBQ9xImH4QtiCm
9kdMs8eSUsVGHQ3NsW2M3yXGNELy9kAqF0LepGxaIVVIX3A2W0MT1YpVQzwm2SDJwiZQ0+qNa9Rj
03SGtjyVNdOitV+Ee4trycjbNDcfwGSJX4umN3WB/dpb7MM2XIEWYN8tUOwh/OCJ0QRbx0XW3oUE
/wCBMdDn42ExX2QsyoQXmhChLTSGlExiFNvwMC392h1TE70ZD5voSoOOEOVpRxB+XX0hwGvlCyMw
hh36EJnL3sa/Nc4HxEJ4sJLxz5FiTxyjaFW1wJZUPkSn690/nKLhLr2YtYujAA5rZzCM5nQetn0G
J2vifAWg1eRRLMP48DHsIMDZ7F1uE59NhD0hjgpVmixRBrX9Bk7BN1hpr9yjDeXDEZwYnaR95Lex
wZ9xhqOkOqKFmjN4AlFdiuZp+BmVOxurtgU0Nnul2MCqJ0VF6JOL2jkWyJZHkJGPKNiE1BxeA0xw
/ZDP4hin8GOFM+aa7ZZSdFG8vd7Lnf6N/wDZBRHHyFBO/ZR458YFL0DKVJ0b2SOfgYzUMw8kPqK6
Y3QsI8NjtAjTvyyia+oYnyjBidj9axtrujJyq3ocJU8iy72LQzxQ8sUW5Uu2E7ezdR0pXL8BrZys
k0pHxwVk4MjTyQ3yITCRnMCdFZFWYttuxHE9DOywl/CYjm9DwwvKF9aSh/H7qS9CyjnsNvuYHgvI
hyn+A5bP6M2q8BIynCGV6OSES4RUJXhlqFVUzEiYoeZcpwksI7RPqeCpT+8DHMQytFxIEjwJmlFn
gSe0cC0NX4LgZNg1U0Y5EViO/YhbFMvkKcjYGQ3YdiyOcGvyWh71gNzr3TevwQ5JX5KdU0twzVvs
Y4z6Hu2ZC/4jtiHaPHwzBTXzgbH8H4Hfp8EWJvwE88/QxHokJaXTkJo6R0Uog2jkgzYitHRq01Co
nIW1x00Rt2GEwziV/C1lB3CV55IUF5he/wAhOSH1BMl4G3PIgZG9Dk6bWyQ/waC0pno/5hHlzQpM
sY5t/s04SFRMloqJqs8IURLwQYy9Drmlc6Mq7bKH+Q8NMcFCPgo/cTp7FbLkas+SE1BhqjWi2Ykj
OCJ8NEA1HFSr5HLN4C/zEbwrL6EtrZtjjNeYNbDZMVzy4EsVfQ9tMIDgdieDPosOZs6XKKAu0Hho
cIQRHt4FX2RDuKvoaFg4FL6bEuEmhieIPYXpiXJo32MpS+hNFc9C6PkQ9pL+ClYNjiFaqC+iFRvR
lifcI1Kw56DhGLLbQlIv0VkkGwoI2huQT3GuEMsY8+hDcN00Q7XaGEEmbWaJ/sjXnkjEcEhrOhIQ
f2FG1Ni8oiyXhDyYlM8r46hXhyX2b8od2kUIvsREr8Eo/wCTLlWNB0zD8AneL6Q4uyRi2410OCwb
pDxiiJllcozNQHYwzokojo1Y2PZEPXNNMumMi2mqosy/c8Fy0hzyIa3tHPH/AKYpn2VtJY55bbPB
i7iIPALVQti7NG0IbF1sh075WSASYx7qSFpIkMgS1EuBBQ7CRQeFkI6ctLkxIcs0ismssTSmqsbl
t0Qnc2IbHksbGHIjqy5FdxJRQu+VwYTuSa7JCQspoXcYri/hNcWT0IapJuQmnBilomZetsyA8xB1
H5IaV5BFd1yTKbbywvHXbyZvK5Wx71qZeisZbg5Wxk17iwblwKfthxHqMiJOukn0QkzyIwuXMCXF
VotCqcqtciPPn4FzeC6opG5TPKJqymDgqkKuW2kchp1JIW8WZDOYOC5E1J1RQdWp0tkBtjsE4kKm
4ekMMiTNcclbaxCipeR0bxXQvkackkZFEZgpFrG2IeyI+HpjgaFfgtLkuSiQO1OjZHUiwW0/A1ce
BjLXBZlItQyQKxsGss4SvTAzRKC8BnIk4WGIeSqSVHHrdw0sENArJUEGQH8IOZmBDYb+OfgSZyUW
iV+S3rOzGYDiwlUw8QlXBIURQ65sCU5paFTaIehjo+Qykg1vD+LkSKzKEoaISQh51jS1LKMAqdFe
Cfsa5IEQdsY0RcqMtCiIXYjYrRcCS5OCcYHGdXw8DFXgb1DbEQSgQx5CNVWW1LDEFN4XkVhNjI4t
CjorbyW6iFGvzBrENs+i4xFm0/Ax4kI09BOmEWnp6EVdfJ4J4HV2QWAlR5hpUMJxQoOy8jM1VMdK
uYQjl4HBpLRGCn0KiEMcQlaF4F1cJGBCA1abpxaNe3OB+owOEW7sHKj6IBk9k3g87E1uIU/UJeLW
9C7Sl6GkdEfSMoowT0tdjfjwR4KxGCokqZuIFjWvAUpwDrQ0MEUnkxhm9odk/oKcVCYiykPmIoM6
UrCLXipHpGZQ0TGZ9EUm2cpr3TKCaybgBeVUJkzAmjaorTXIyYyLxs2F0RY6GicD5kgV28OyajaM
fmmxpkRPoSUcyMG55Fno30QFRhuYKMGLgsHcbQuGJXxF45I5TRhTIZsBKMCTaLlPBI6+gdcZCZUz
4jrpkF51b6GkZZehWZMFMGapCUOBmec0byMJYliMapm0geJRIyolURNhku/h5IC2MmcO8GvQrFr2
iyaUCOoCGNvkeBOyyfwwpKNyiZb2MV7CWBqw+Q923YJWCnhexYTsQgc61XAi+gT1kT9gx9eSiunn
A+h+KJdIRCHZJoKrKUi3YPPTKKZfkqrhotFs8SsuXZFznFNC1b0ljsa9VUDpMve2IIKByFVaRpIs
Uc0OAVstNSmFoja88GEb8EMW03Y/kkKpcZSQlTBmSuxXkSqUngNNOO0x7tJtM1RdP43yXo75Qhyf
uZaLUtDMDtvgenEDissLPum2uzvT/geXgHWhOrrrovPgHuuOZqE8IQS2pwYcbaQxREFBw2kWXobi
zeDPpVKLYz7d0bQRAvwY18ZND489FxGjw8CG5N0aEuBhPLWJgLxB2QVPI/8AbyaEySGKRQnzTwuF
q2A6WlQkwNzgXJuHaQlHW8MU0MTPnBmSlk4+eR/C+GqxbC3GWhEcQl7YY1W1dEsRsmLpzBF0xtUW
DzUN/UeQ8jyWEE7kvzbv8MTnBFRJlI7RuRcBe18xbbCQuyPODPUkLlfoV0YvBKkoaUmt7LErYWx7
ekiKwzfEKm6KdW4NxrokGzNrJKekIYS8RfRlhww9jE0/Rl6MjZfAeEpsu5Jg7YNjkIU83gvERhTe
RNJJ538Eh4DEHjwsDF8mgGqYdSfQ7oTZ+D8otILTJdDWPI2WVwUojS3dF2mZT8G1yOlPk48Vi6LJ
8i0aEsEN8AtAhkE5nyfmi2YDQxFZRYtonjnTMo0Frefgz4TOGZudjFNITQoRp9GR7gxpzKOlulNE
ii+CHEecjKhHu0cMt+xpbYHdag2dT2ENmYqO2EhbI0AwwJgDDS2/RdmEJMYEW8MQ4cioBUzKUFJP
KbHki66ph4LaDE45nR7EUkLQhSzaFs+UImwU/vPwvT402YR5i/eNhZYOQie0dLgwIl8A1klyIvoP
eEN0MXboI8SWiN5YhV1P+H5A86qgdNoOvuOEyZphxioVfwerou0rLIH0dxKCuGeCDaz/AIRh+ER0
vI/L3RpO0ZhbGxR5Y6jBCZIiTS0PGroLWKUDmyNVoLny1w50UmKP7iWpEgnRYql8HBMnw1EhV6GR
OgKvw4Qkro6D8vzSH/TmStDDKd9DkR5NLQ5+NDHdDfHQ1LolLg2ZHnMFwzpvx/TFWnMrkhi7ynlw
gsmjbRjzS/wUoTy07obgc3o1pkMWE5bkeqNo62hvJdXMoeQGRkMLJWWZmxXNA6knUhlq7bkiKJCw
A1InwfQlKHYlpeLVowT/AKQzMJcNDGuLS4YqFktXyxxaMsMfuKMkJUa2cjyxcKT0ZkHXm5MMEPWD
quhO6cYwjyCYHQ1jrkbEjOZFBkqQprStGA00OJcqC+M1rBmKjwEp+QeRvjMtxy+hSUTmjaPI3u5M
d/ExwyNDxsTQsjUYhigxa7yptQb/AOfE3WrP4MJmMDX0JJdmbxZBrS4UMIGJXlOjR5HXodWT/wCM
bXwcbQqPZtIyxCMR3Hr3oRtCQu9bzplmJeiVQ7yMrpKZq5MidGdzsGhbRJLA9BlMdqBn0jqqf/03
CiSeRvKMeZ8o4M8/gWhIdGb6IYlQk7EUQ1iNwO50SlpDwmOmtCzqHSg4asdWfAMJ1wMACu2+WTNF
zazUsCspzIxsWnhB7UQ90GlpyUF8DJQtO18NcbQycU2TJGKc4YLTcGRBpobp6T2KaHVzBDG4aCbD
BBztqVQbTfgpkbjxS4z1KTBHksI279UbNUd35SJCQyWh6ytsmAmXI2Dv2MCmB7UtXicH4SgySPcW
YZ45OzvdkMwTm9lAtzy8MS3kGJMGJC2R7lDd3YpLIgrvAS9sMyimYcYJTkRtpgddBfVHnPGYuNQK
NJQ8t3osySIIhrI67NukUG4KNF5Q1a7YNxsgl9CCnVXseQC9HQmmIGeDe9DSjeR8EWsogrhoMjNP
iuieMj/CbCdBmxZmnIuVoGYbRRkfJhV6IZsJ8sWfV2SJ1UGwuY4QwEq0homX6a2EtFkaYtma0IJy
eBm5Ssi4+j6MQRGw9Dk7F+RGY+QQfEeMoV7I5x6+h+wrQlunUu/IJnuxMjNbCdK08HDcTExDsYY1
MhUi5F4+ktj2sRPLFtp+QuKiZshmNPaHpqwkLCkU8MetabIR8KhtWV1gq31RyxDEUhPhwyFyaq5Q
nRU0oZlEqCfzFVYHO08aKOxttG8NssMUsfAYyjTIl/iGSZfHIqmsh2y0yli66x1Dz+ZnG0PmEfVc
HBognEalo/bJlKFT4Fg1b2cg1JFi6kR7Ry7E4kfI9GOnAdHa+OSmDF2zeTJkQw6I5G64g0ODu7Jw
WtEpksvRGjgJnlFJKCQzLuUFptELL6hFd6HReRjpWSSfAhpoMYNCGV1PforzOhtS3qFUyeQZ0WWN
XobpySkwYHY3+KnuE8fxwLZyLVNsWl4b7vwOXRkrWvwz/DhPAp5zJHTQUs4I2lwxFWuZElhVCMeh
NVVfk6ViXEgz0kkzhDFIZuTi6EiYYigpkmQhGGzI80kVFEXrmNi0aMweNa4xBURyWqQfITXZHKm/
YlyHsTDiDgKqpiMeBREokamZyM8j6AyEqamJD1GmPKbKUhv6pYPQtRh1y3k0w4Ry8hTWSKBheyB5
HGokXTmY4PAh64RMXBmlNmVwhIJr/QEku+R7WAjIib3TMiY8YQdstll4RsrqhjoaMDrFqNP0RUCJ
yZmeBeE0LSlVfZvAYCMC7kFNNkNGNiRGsmMy1IBLgUncIUdQ8CZaTIptfApaxf4zi5OBGqbgRT06
YvtGLybyhdYimRjKs3o0OccCKUUg4S0fAcjLo0yIDsxqM42iaymhw9rGWLFSl2Zf/gYm8vsjTqCR
JYzBrK/shQdNK0y/hzEY7cdQ5OmdMzGnitgsCtlal0Me04bHNqOcMeCqTInGWmroUkp5MzFrgjKm
r0Q9BWtl+jSpiNp8F32G1noiTTXYq8zC8F+jFBgMsRC3FVMexNt/yPbZix7GGr2L3Q+iGglOMt8i
FUO9piMw5TOxhNqPwShNKC8sqyuhreYX5Exl0RaOvYvQ1nOkWESMVozPGRbkNumNRt5dwwSf3B8Z
M8fDwuiBWnTRWm4nq7JzSWCCYanciKxTUphWrM5uSYqj0GXQhtSBJG7oSw5ZZ067H+7XtkVcR0Ps
L241lOsQqrUmEIYJ28iQpuimVTyhfVLWtHu1HkchQFY0WH5GOhCVhmR9V/QTJmyxuEwsob4b9De9
Hy4F4ks0jD3g3ghM1UQFHd9j3E9NGkJiDV/kSFcAsJeKG+ZapjlUZQjtPY8t3V0b2QK2znhOFpi5
PZlDzMVWbSS2IoS3YdM3HsyW3Y2ysdeqMY4lcDj4efjb+NBviZM49mbDO7RuW2OUfCD8k+D5N3VQ
6o4iosKVLgTftXY/ur4yPw0hMwZDt2vscaryZ0uZGPL5H9vIqRLujK7tnI+CNU2NZNeS32IcG6xY
YzJLNp0z6To2l5DH3kXpLguFTVTL6l2OZnJPV8pjKvaDWM8oWJI09mzs7rHbELKnhGYKDZPTY1lt
3SQm/wBjHJJJZj+wvjuDKVQ9WqJSbtE7PtGVN75Y3x/GJfpE8pdmb0P2KFDc8mdi7UuuRDToEG6R
I/QWW68iIv2FLRQ0212hQlOBjzM9b0FjP7bFpwinULJXTyR1jgrmo/I3rpbbFhW12N11/RpDQ7Zy
WChd8DoEk+AQG4FCWlyuRqT2K6Mn2JxTXR7/AKD2G2uEUr2DTmmUP5FVhpcsoDV6zTIDggqyINmX
nsi0Yvn6DOl3yJeA47LueaGbd+wx1kxGfYhUaXUM+VklDfXI+s1yZlZQda6ORJWzyNSybgX2uqfp
kOx+mKkpyNQD+hml2M2ViCHoMVmXIrrPbH+TeEO1A7EQnoZkI5YKcrBcJ+GM0ewzYg4Y1gkWw5N4
iNvwGVUDS+Xgd2kJvohXW/oeCmeTTT8BW+iZazvkbSegvc7MQ7ReWRPIuvQsrzOW2OcNplES4N3N
KPhdt+RilhwJ7f2hIrQ/RMUG33ZXa49jYbYMt4/B9b9PgDkQ+xhg19j5EODeYMx/eOyTiRgCf0Ls
vJjMGnMSEtJpk9Ye38aOFEvYroYC14GBWJyWmORHYz4Ltxulsc3E9iVTTEg1S5PBlI/YhXOBAUb9
CHT9FDuxERBTPQupS9DPkay+QyCjW6L6TfKReO3pFstywWM/0JedcBiV+Ippb6FBtqG7Ikq0xsH2
TkD3Q7Gi7GMF4Ojgnn10YpH6KinypLRCZBPZKZpNSi6EaMNNGyAfOoVG/wCsTSFFDc+BoAfZ28/h
t2xsKpVQri5x2ZGZS5DJtvEIE1dNIQ5hprlCFC5YxBGWZwJmFfhyRnhZxNrY3qbbmIy7CQs6iKZV
gYrI2rSRsRIp2aHseBn0Jdm1sh0UHWR6Vqg/aj3kWUVsahP0IySmmRLjNUxVkm+ji0cLRn2P+lwc
LF9CUhiItr6hcBPYpiauh0Ty8DOAz6GOCvQ5q6+LFl5GzDRj4fw+/hbommYJW4WEr+hmMLsj/IUt
bWR7eCDp1KxA3P6OGjgZRLQ2AFfGMWIt6wNhVJCS/hmUi7C1oqxeRIkWipB4xg0mhsclc7EpVbQ1
7V4L2hD0dS4qE8eXYiiocSezJIHwJotvY5GFI0l0tpSKFIa4h+BzQRcY5sNI44LxKEJ1hCR+8IJC
XgRnkbENm50U2vwOaumXxQXgDmYW1NGwvJrcEyDnRSZM4CqxllfDkVAVjKglofkXYi+jf2xXzebB
thSURbM9yuDAU/ClrP0TL14FgkXRdFzJ71wOzL6JODs4EbDPNYsZYlsW+ClMbQvn8mIT9CuSLJPv
yE5v5I1kqJV7qDx/wRNf6Mh1ZsIl4Hni3zDD1MVGGOj/AJkPHpAwnmYnL0MBjGZ36C7KeUZJkS7A
zEfoLYd+SBgX0ClQ5BBKBLbrExNepW6PwJiKabY2Ocrqp0XNA6rcXap/hmJzZXwfoSeB4G+QGhWV
9Dax6M2OD2Idps5JIr8k9bJOdk2dnOjT8eUlsyHhtishTqTTQhvAcdQzAzTEARxcB5Vm4TJb5F9c
Uhvz5glQd8B3YNkamPwFqqW2polkxaIYZUsH395oi+yMgVs46EbS4l0Wno2Tj4Ynke9pG4iOuDYX
0V+iMVG4wI7bbjeBH28DEQ0tMr+Jg4UibFsVPYgih5QTA2YThNRFoY1GzJf6Oa5Z2wBClCqmdttH
QjlU+SQhJ3LJcGAIcIQT70kbxSySLPzDOisPq4OyS4G04MpdDepKqhC8IFMbcNdoSkqsAcCuFm8G
BJ2nLbM7WS4EpxTWy4tfBLQ2tSNjFlr0EcKUOwhGHKobUphZtl5jb9DwZrh2UJ4zoWIpVLAgJwPo
lkiTCfLHtlk+guglfmY2w4GjmDsMfpKQJm3TL/fh1+kwV8eY8lAuE1VvDMR2hMS4YSUWm4uRspYe
hh8SR/g2NaHBKzIJRjyyi9ki8ja2smgxuM3G8oyUmVQcooksGP2Q0xXrwTGq6qiKMKCE6NmKIbLE
uxPTqmYJWhtV9wS6pXsr7hClgyhOFmEGOSwUhSNs4IcdkIJNkxseBKhSgHacL7SwOLuY5HNqCRh7
WPhIUDoyJVGrKSXBgtocXf8ATwDly2iVYEY9FyZojJXPsRXEu0PLi0PWRonf1B1Yy/Q96SPgX/Oy
cmiRWwGJYlofAPYvHmBnVfwXw0WlBm5O4dTwETHNVgZk2r0LMQ8oRCZghRrZUkJaXQliYJLyhEU9
cmoiGJITXphvcNjWLA1uByohiwUmvok6RZiIpSlaLgWr5QruMiMeCL0ZMqWYMDjLF0hOAmiM1a4L
B+C60lkXXCeBOIsuFttBJtStGfalKvIJfjQ9C/RGeXwteJsJW4Uzh2SQq7VwL3DE2SMv2cC8F40G
XaFrczAySONo/sswsolIeL6EbRiT/wADHgTQ2aLGSgZIaFJ2gfXCgvoskZfg3kpCo9AydJgS9RCm
zWoYcVWAz6W8GBOBNCvYj4EyJKjdmJWxBdQQ1l2Zd0u9EQscl+KcjOiDa0FNO6bUNghVsuKn0HvH
Q7OUmTFixSwMm5jWB6jSjpgpCt+JBiw6SeB6PgF2y0chy2GWTlErZ0ZtYF0rOD3wUhI3kmubCGck
jepGDCMpaJvpEn1vLI8VF8s20sIeatycjDZFRc+DPpXsPgsjYIbCFhjTYTJBmVCy8CIWS/eZ0BU1
+Qn0LWLgppJkmES6BXIllFyE3z6IIyECjZeBzjx2Z/JL/pjZbkYE91ojfoNeLCY9Wu4MiLIq0DUn
I3Y6G0e2+SvGmjaMhC92exxssCrqTX+Ftez4CUl5U/4IpNti2gKOJT0SnYMtrLSyJ5SSVcF4Gdwn
hWNG91PoXFxP+HWHrKXsQjplHswetogvFSmPRK8p2k1keAnZFfYOgWVO3k6obTayaY1pXkZLuYix
WuxVqR21oI2xQnlaeufB5ohk0NZGw0NZNEGg3LSMbKLaOJkpj5LnwPHvoXPtJmLWc1jvaRCXpkZE
0h8lM6ZAXAdprZ0PfCUvyOy2ICSW1mRHI4DV/Jsbj+DweJkKClvgWBIS+cTeTCwiUQszoQf9B+3J
llJ+CihzSnNIVg9Mrq0Gq7gIcZt4CzjL+BCflVkwcpVk3ayRXa5GRt8n+bHLtZ8GYg464DlUk7CF
EQmwVfGTZoYzwKreDNsGVEq/Jiu0bdRkTSQhq1D8cwrMTNEahGdbeCC3yiRa1VQhIU6JKFveO6Yx
grW5R8DY/hw7ZcDDk63wJjg4PBSg6gYLRCJCHqFwXLLHoqEG9EWz2JAv8CG1ciM5QERd0xCMjkha
OAg0fQu05Ii8fGLadUlKIxER2xGPgSpFXQp6VWiIJWlR+REhiudCsOzhCPAirKiEOlyjG4iYS2a2
Tb0bPR3sgiSeBi2NhGrXI51pweGMSySwZQjk6pl6BfsiYhV9ZlJmkfULh9l8uiiFw3CQi72KrS6J
TXs/Sk1un4yZfaxOr5EMfNITI8rQ0hqEvIZI0/d5C0vqSCsM0X3KOieWkJnrORaS9tnvqjea7GE9
ERl9stiFNaFNqZUGxLdik3WR7KsIRtMka9lXkXSwmq7M7aWeBTY8FR2VwWLyLKJZFvRquB8BModJ
qxA6c3wIq2mAyS8FkMcYc+zCEJqFTdI5bWRdNoe+xOJLGB0x0D2xhMsXjE+9BYYzjgPxGsbycD0z
LDcGEUiiAq0E5Hj/AIcfAdGo8wv4KVqMNiO+Tg0P2yR1U5DYzpjXj4ZCzbcBrwyqkPosqiQbw/5G
otth41/joaq5lj3VsNklOKkIjFIbL7KvQzQzKXAtnSE8kN5l1pwQyFLz4gkUlOkslaCk8eH2M7Zq
Enoyh28iPQobOtFtLfg2Sj2bL4EbwG5l5HljRZJm7/hZufCgVUqK2FGdFeuhKCPQQKH3Y2rZxiya
CKrX2TnJI2LkbLFtnR7vCC3XGcdmEJ24IC6Q9DYyz8GI2TJgQyD2OUt+jeGybxTauC0tvIopHCGZ
wwIYzAZuuUGpMp3I+bCwNQhhrHmj08jGM4zCXGWARtgXOtHROxR+LoVzLyMaZmJcI1HG4QY3A09w
yxijoifgkqXwr9scoZJI5aqNYS9mLeh4HYyMtCrwoMZiJeh1FCOC0GORPA3BalVZEPxH1r2TzyQ0
2XoSjoz3mbNX4DaxTWzay8aZlgUIdEmykKy9C2fJ7IUcS2otseYNPcZmGYJa6MmxrSCQ7Ei+By5V
wXf8EoIcgstmMylwmAhDduILCB3IcGX0EDJ4gHtAjcIZvILRaGJdB4KCErYnrmLeqOFDEXQgKCO1
ql0ooK+nuVTYdiEW9hs/dTvCBdrglsZCS7qo2JKnIhjgIjaIKLY0KiN3sTdtIptsNCLTyYpMHPyL
oy3n8PhKeVgnhgNjwowtLl8opiYUMwLXOzIVE18tjxKqBTVFgSdCyOK54oU1yWRCO1E2acHI3SSE
h4BcewYBZWnGJConwcubs4IgPCHLLsRjUrqYronVyZc+PJp5rAZJ1douPGlF7Gsg0xhDWRCt5EMg
yjIS6ayU1MYAsC0cTJXhJjQ6WexW3wbezMwmjb6GWiA2rocsjz4thWETlpiFDLIJAUPA4UShTsUV
iq0OudnDUQ6EIomYSCSqrL7ELcWE8ZZ9iljN5hF6RqQoC88RTPLUpavFYG46Wa0MI7yQmHLN7NeZ
FBD0/TZdI0f/AET1RsxSvpyMLwZLvCbNcDElyIMYOc4mY2KHmheM6j6lYZJnyyZs9snajQZAAncD
rKNwYWmyInEwu7JsyoBH/wC8nJpAIHLjoiSzd8jBNayScZIWtsYbUeQbMngDU9KGyfz5DqljbGk3
kqiZUd8JE7D5IzKYxwjDz8ZMd+hbhqG80NjL7isicoQJOyNThJIunr2U4j3Q8va7HZtC5GOxURl4
TFXGl5Y121BiRqDwM1pHKfJVYaGJYSXlEGVvsa9mJvxQ2TKJzyZ5NFGiCN6KpxkTb/oHZVk5iMdw
MZEjCwaFVHE160reBCNQRkdshMhIfUxjsg4Zd/BJeEnMkdIvJvIiqaQsjDX/AKQgpCgFroLq5Chx
rZoMYNIMUGK0kvYpK5SZJijvTNCREJaZMovGggyPsN0QsOpoR0+hVrGHFFssEw012MtVJwPmKT7Y
ymGxbzMDVcJ2cHyXKo0f02L4GW6MlEBkaEqmaxkX6GP6hDzivGfjCxYeh7prA6y2dj0wRnMLLnCD
2KR5IyT2aRsa0r9MYm3fogstEc/A23pMhXO+x8RYWYB5IE2g5R44dFOCkYXyIbaa7FF6QgjZ6/6I
i0GICGgcexSPPNj9+g6/VGYfJiP9Sjv/AEiy7Tll4JeR2Lw1RBbiEbFdsdm9i7OSsIKr42PxT2wl
ZlOjDekuxjufilb3hMimwsNC0YkmtC0+lyyzC6ZiWQkUGMsrUTKpl9TxgdL5GVzmifppgV+ZbdGp
Au+RzT7mispN6HOW83g9eC7g9F5CPycmhMqxjxRjgUcysZE/BJCz5vEZskj5E2qXUpsFaEMcUWmD
3WOFOJDfYgediFEybfZk+3VwNkL48BmZvySl7wGJJBcPkq6acNm3I+RnsnTEn7xjBgcospyVni7G
By2jDvg2IanWpEV3+w7UyadhOJtav8MzLeqIrJZJ5oNIJEsCRKSjro0LIzBdSR7wDoyv2hTJPPxi
yQmqgI9CajLI22beKwYHyO70PLb2PLnBL6Epn9Ox63GLSyMizgtrpKSHp+MGZk6bhm4NJPkWQnls
XnmXQwNJ4lehu5RZSHXJAqhRK6Eif0xqaa2iIguEsEIsYWS2MlB9CBqJkJU6xN9yxpiJG3kuLz1j
7w/wb1jhXRBn8iWE75Pcuw/W8VsemMd6MgvQflSXllG3ewlNq0Enh9tjFrI6E5jy2JYrXsKV/LLh
m7P9DzDcFc2PZsT8KTNMm8BMmY3f/mSr8m65g7a2PDNtDusldp8i7gE+T2Nun1Bs/TQZIHRzH0CP
N4C63b68DzKiNdjsJ0N1fSHEy8mWkj2H/IbDQ2YIo0V/QtjT4So8bHn8WJ3ROekb1+ZNWfTMPQYX
/Mr5ryjK2Gi8bJYmTbyS0zZ9YWDmhjClb3okc8mwO+xK2NwfkfjgNQ2cm+WehJk2/Jh8hWbAd7ma
hibefFmdahvb8D1PQPDti9udjw22RZkuSvAi1l5a+ILh4Y3UoyAkvFH79Bxpg/A3O/QCCfobKBz+
QG5J9ivb/RMdFgacPpbHrNDGL7PhOMfswDqJrRjQno5SG4fFI94Nsz3ZTCjxWQzObJ9/EQ6t/BW3
mDDDRG+CJKxOjG+RMv6AmaZ4WMEX2Owby2fQcVhNbo6MSD0UjGZrIlMmrkCqs3TEtLkUUnPndDDP
9FpakcM9x5GfmxDjDgS6+5Ew7mPfSElee0HV+aMD/g5y+74jCeovMMrKfkQkIvCDDLN2SEja7MJX
Wjd4QhC25gafqYMuCFbTsa8F6GUasQaJ9oX6X4EkolliNO/UQNsfDIwmho8DB79CGM8DKFaZr6jL
hpzCcfwT60GXLqgs2kjF9onkcqeDHFuRaTL6CvTftGFLixfVqMWyfjBKLGWoLW1M+r6HSquHwMCl
O0hrq7ibtI54sxN8iLUKUymHjZNkzLb4Q5MDsVriG8CjQvtB+BNZvJoZNxvtNCKaJOeBplmZItqb
QTkajFZpbVjfWXj4WxV6FCh9Fu6V1sdUQNPyhSCGRmkiqR/tE0Lua1BKneiiv1V8kQ5BQhZXQ+c7
W8F2rnCMCqXoXDJwJ3nwM8psYISr5N3qlK+BVqv4TCV9DNkjT0oOStH7CtEpEOwi7ck50GDKJrig
TqC8tPGCcUm2NK3onZ25wu/WYlYRriLbIgnZIIPK2bBY/orKTXERVm1pS2WWSdihe/oie+DVaZN/
KVodjbL2goCtQTL0FvrXh9i3XXexO3QYfApPi6UfwJDdcGxrFo2miGe0LEmX7mwhciFoLTYRk96H
oNoqcGDsTQ0krayZe60VYt7opCIZyDQmB6W7FPX0+jD7mxW0cJJDhSzRaUanwdDGiEJjLDNOYSfB
LBgIFXIhZ2TN46ciZwX0ItZjET5yh7K+ofwAGcGuhSRWdD1DRZjKH8WhZx8U2OsM5NUlgVgGRz3C
rSp60XCEmxZg6ehpSo5lCpRexV4l+DzJn3BrsQxAEJ8hpVmIN/kYuuBN9jEeg8jGL+DL/wAhOp30
IaAc2svRoIbCQZkb/gaUtwnN5vBw8PoxeUL1TRii14P/ABQbts/SYAetx7Ax6NeBmJTW5YElAxgY
1jqO+RloVbXKFVpo5+Ij1zmGRCPQ0mCLmxxT+BlwFXgZWv2IrCkMVC9C4HngfFlhyE5MjbFNDWwo
o0L18nTPJ7DUh4ogHleiTHuGHoxZtJVqbEpNBASQzRTBPYyIZIckjQU7cwUKdDA0VExh6JYquRkt
JXdMXrA7ZFcCbwniiFZCeOHQgwpwPDVgJXGx+BaSIQ4Fl8F2hUp4ApunTheuQawDjShnYbu6F9Kn
k0cVEzfQSUkp0OATGQvlRPCVY2GxfGTibvoNiXVMseyWcfQpK5qYaqOULhEpR0+gn4vZCqVPRaO9
hDXITqKsFDHLIh9Gh3QmpMStFVaFZQig4M6sTIprTDlCvdVCVkJRhXY9FOuB9tZCxoRGExRUtpQs
TOBqISgjiBUhNSSVFk41JTaGyXI1kX0K6eStbRM4zQEAJwsiiQ+MWoVGbyJWjgHlehrknRpDDlLy
L2iaLQ/zhpLRKibF2KqFpwa6IkMEksp7QWGRlbrZTbQG12JoQkpVTA0a4OUr3o/JemuV2ZYTxlD3
m3Kt4Sm39Ck1V7DKw096M2GuWDuyrnQhgk4knbdaJehC0J/ZPE+9LENOzRg4iOg84ErlCFK0uRaZ
vgDPgO2gWcNCUnTfZ2J4i4GkTbjBRo31hSFmg4tUaCo0UqOHWX/RWWr69C4SV3H/AAakzTz3kRFZ
8LRJlUkgYLfe8ibPMH0enCHApHW/2FkZgZ/AiSwL38Jki9jLCn0Q6DYmbstxEezYxK9RJi0MZ9yj
m0aZ8iUWkPkUSHOvYM/PDPOCv8vjs4tXoT7DtZNuEbixgMdrngvKKSNYtk8xiYHhj3ktFBs/Fx8H
g0dJE3UagaZhPkX6itSDbJYEQLgt8zHXwGc7XAoN6C8a4MY7E8mDFFEhKWx7MwVFCBkNK0QW0duI
6IKS18uIEHg2SKh3RQe7i0Zhq1D/ALGVotD3WcERwJL7ACC2jRh2LCLsVwVcH22RHzzCjyOEDCVR
30HFpCkuGzHmYVWkjmQmIyyryLX/AAgOIVFyGrTyFuySLVCkrS9fDzaKPQg3qFj3kLreVDuGgkP/
AExNCvnBn4gphoaisUtPZ2X1Vomvf0Zih9CY13gskpdQVpjHNiuGKjK0iCrngdBt6KLwYQykMqr7
FsVRlaV5WBvn3DERuhb0kNzBPTzjIxrTCj8ZfAXW8pDh1djNWUOlayIp7saCsKWhhp9jZtVyT8GN
DoNx4ZffDIjHE6MjjI2AyoFd4sWQNnCCMCDl1CdFY2MUVPH5HrcENN+RX1dhfPj1GFtG6TgLZZ5t
MWZ3FebK2TPMipkOIpN0he44KQuT8DvChZNMJFmRUCGlUkAsbHlKls7XXcnVcC5nA1KjBoJp7RE4
5MoWcqqMmkn/AKl3IeC5ZzHDBSiE4d7wkU+zZ/5FAo9ihtlFlG4mq8GznNm0o8neQOmuyhFzNs4y
ymlTVu6JnPwW7wmlEMI9E0zLZyyMGN5+QRQnsEKbVQ9YLhvjkHS1KsuRKUac2G+53wxJj/IPNbzw
OxksmryNnEjIb7Io7AQtxsShIUJEM4Stsm2SeTyFT+mQElEEaB0fJBP/AE8ZA6Ei3UxNDOQjjsgS
1/4Fym2gzsL12NeqwXmULPmIxaUtlpZ+DCd7kG0aQzEhmOuf8zFIdXwFLKSrZvmKRfAE2oTnwLEZ
AiZ4g5zoTidZey3JvfRvJjbGte4Ilw18sh6I/ChQsmq9szPRRCrfSHlt9miGjAbg3WUcUdRGLaL4
EudMWWiq05/DFWrsYEuMD37hI0TwLKtoKrwMsnCfohTeVA2JvI0hWWRQUlBbM1CNK0V/cS79kpfK
G5gx4GNfCaGJRG/h1ayFDyRl+j/QKR6HOwUkhTbFVCnDVmKUOJ1gn7RK+iCa2EJ9EGPMhYOqyWNm
k1FMRNIYZu+BEfySFRoFAJBEiP3CJC6/Ii0uxkvqPDEQL07GSLPmK8TAhEqoVqMiGoqItDZN5kpG
ftFSbMkELREF7mITgmpjscvqfHd2U0R6zK+eMGHPkSBRNyk5e9PsRXxBIRabi4H1ZnKYuTEJDwId
jJWxPGkQpRI0LPImUhD4ZFmAdjQKG9WsDSKTXoVGxiXQplz3oQHBDIh6NDBJblDzQINLWBPbhPDF
LCFOZDwFhDaS1R9RvAI4WTBrF5LloKZNG6zuPIooiTA2vAWs2UcOzkZRPWhJ+8jjLwLpTnRmBpYY
y8ikcoabMkz4JXvJBlhSiGXsUKJMihMYwNr5GG+i7PNH03MQn2wg2+haN7CK9Ihyy2RT7wIu+BMf
TFmyGPk5NLW6abFVN9mZQUkPNJimW9sW0nY/+DHyF/Rl3kMNPbmK21EkOQhJioMoVMRI1va2yLrw
8s4BLmCz3sUmb0OUfd7NAnWHA4t9EJDr4MZExBu2HM3k+je43GJapVock/8AhDGrdVIeTZCTm/Iz
Y0nH0PjoQSNtrGfRWNBlM4r3/RE9auILnfwPe282ml6b0JtX+Agm8Rzr4xz0cnIX0cdGPATXFi56
Fg+wCrX3jZU3GUpXSQUcFMob3Fk3yowWy40P0moG2ti2K70RrGRCx3Ej/BxRrwLfvchVrmonBqis
2TyF1aS2j+UVhP8A7GAKt6/RlW/jkRj8n/B7eUWLGaVI8IJWkfttzwSRmDdTKtrQi7pFhIYh0O0u
SVD+xCmihHUEiT/0bbghtuRiY52LAW46+CAHkaEBWENAMTZqzU8IhjFosLwESEjqEzJGWgwrOdD8
LDYHifNGCPTHyY+ToMLr4YkQcGgsCUH/AGS2LulQ4ra0Yks55IblCOWrREm+Cgo2OsnaZI8N0syo
TnXBpQuBHuCI1I6Z18qJheBF8pT62LJmM+rG6WvkequIgQWqwjYR0Efs+GKBsxOYU3lijYOeC9uN
Ck1oSRYzBoUxePghs2xZyZgzAWXp7Fpog47DOGmZyswJSqGvZrp7Jy6NtybdilTolC17GRUhthbP
A4mwxye9FsuTBrcl6FxfIXbtqGpPL4G3PcIi0kJauMsjBPAnTEyBjKL7Ah0xgdlV+UOdiyMx2Q27
eoJxqnQnxPUGdVjGMIdZgre1ySY9Il0oztset38IEgj7Rk5K0h3jjwOLyZIvquomN8kfkrTH3oOC
8F3hCaxB8p2PvpkRA65qlMXkYE6GptUdVHFyCEtcG99hNMNWFEtXgrmIPy4KCcpgcRXNpaYSHtq4
CnceB4WE+RV04QRFSyGd3XYoaUP2N+JJsVd3IWHmYffhFVkSfixSlTr7EbtEQ1ZXA7n2Tf8ATaot
iNco8dTDJcHobKklQuiLhSngZe7g7tpPYat4vsYCR5oyVgHSzwEcmCyCSkuRrJxn5sWHVqojb2r5
QnEtoYGNG+3QgyKrrnJXBRUljuCVROhVRH+olMM9jaM4VmHXigkjYavZUVz8NQbmRurETGfMDij5
jRtoIZynhglTl2ErDeM0yrk8KVFhR2CxuN5CEbYIBlhYdGcN1iapvTF0tDpWHxFtk2VSOmApyPgx
TtwVZzXRAwk7XLk1PeRtObW1kZVvXSNCq7TM4UlG40L5svZjYSnwIKnbtM2WDNECx+MUyyyPmIP4
BbYVzYMnStg4UfIYn1BgfB0hhhfDuWOaF5Zn+yyGidi8MWK/QDWJh9FRLxlsmOWmfl8igjTIOfvd
8Alxk6iWrwKETKIdI3Io26G2tRNa4R0/kNvhxZg0ghPwcGXJBK+LZyPTQxrMhm2+BmsCAj6BNPhi
kyQano3rMIF56Z1CeTNE6GTE2Gs7TKAzOBktwm20NvOETauQgL5mxbaw2PYYxrJtTYkx/C3BMmxG
Ixb40XlrPY1tz4QqpPoX6t2Lb4exZlm6pA5CmS/ZmEngIulciHe7ZYwG3IWUlLT/AGJJLE4z80ht
NCzKt9PGSM2ckZ9/YniRYr6Y8NeAjrjC1T0hIB1zv2QnsPQnpNW0x+H4HCFdorzPJQf6EFibwRj2
ChiY/rN7KhudUQ8pvIs74OxrG3xkZuU4uvswgrwKL/lSja3yOCzCtG6CvUsDLm8CaoV1iJsaUKZg
iyaOxs+kNerkwlWBIyX7CVhfrR7HhJGgoKwq1ujLQheg7wIXI1RKyh7knZgjPZMp/ZrqODAiXRIf
cEk2nsefJeH2OW+06NpULkdeBwx+SVu+QrOt+RsXqyjfFWxJfsmOK+0EmbvRury7eTSMfllPToSp
rlyKZ3+TfPgLTscsQEjEHpUPDrOJDxyWYUjTDoJsP3GSWReRlWD9mbI8jrhXTEV7IfomGfCefkOU
nBFaiQ66W47beHQzzzHoU8OhzZZ5IbGbINjX3scml7Gx3o+jNBqpXmi9afk/CjsouB5LVGQ+ZE/O
RL9wR7F1NiBKPRns6tbKLW1wLPYXoe/VtkvqrQZFr1lFN3pcmoYIkOJB/I8CQNglaudiomL0N6+r
y2LGqC+iERdVTGymqXeGhUeaPQhYMz5Fp7aRmSy0y0bebSyMeQ8PMJVKoil9sUKDS0lpG0FqDwNv
bEDGqNLkVJJS6y8CrN/rI6t8ctDsi23XxYbIDTz2YZDSMZWdDSbGL9ozytJ0IFwkqKXOY2VJCUNe
wlxj6GGg7P8AskMTG95QT3em+4YQ/mPtX27gRuk4eDYsOgO6x1Gn7FzX3sQbpxR1utE27HmyPJH0
DzbcNsjcavpswMLp0c96ou6jJYzyK3H5i3/kSavSO0eTZzDrgc0b8cHNS8DNqjp0Vvxv4IMJD6C4
4FmjSdAyNE5LAStr/cUxX5CPBfk9DP8AKnAIDz8D1+wFM7ZsbNG2RjsY9HHxcR5HhrsqiR16Jr6E
qb0JMixDviINoWEHnd0xsttGMeOX2KzKnNEvDPLyLjY1l0/JdpKXZrbKOhNvYquZ4bEsn6UdDdiZ
FosKFIeB5HIzbLTXynqGSnwPisYRTpxNCdWhThvYr3dCrU8FTT1R2kBAS/Ztr7eBr38CVsFzUXkU
OttdMYcgrQehdzeCRs/6Lyr0a4QVNUE5WWJI4OqZhthtFyN2TxgXNtT+jZvAmDHYsggw2L0PivoP
oWHOm8iRp2IDQ9D5t5G8mTfK8GI7sOwyQ/swI1ORoqhk8sSmK9DiM+f4XFZd8i5GfJdV4IuaFK5X
kYmUGnWhZECv0PBRFhU2HY0p1Qb4bdsr2xmwTU6LLhit4MW/Xks0qGOd0K1vo2JuGWL2GpVXvJeO
/wBj5im6hB2odrWineh49lnOvI7bb/TONsaKAVWX/wAJ3fqJYvwKW6NFgb0JKpwWJoGngy1+ztw+
29tDHyZHx2/tg2A/A+pVeRKc9AtTSNGPoG9xnx9CHMCtf0tC2HTPtDE/RMaElYluauSW5CNF0J0K
y3dUur96DWNifA6wwZX4N9RD09DlER+3mX3EjT2FZ5XMKTKLWF4RlwUOSkcwlObQs0ryQkzuhbm8
y1Y2VHnJK9iYkqOWDV4N8rgUVysCaxfaH83WoN6hqpTOlHF/czQ1GEqi2Pst7kEnBWwmOrga2ZpI
iMOh8CLysLoTaEOhDZV+eiIFpkS1lvkYQdIjsFw0SPIILDE04iH8QeaHC0P0OaYsRcjQtrqocPob
LyMJ1izQ9b5qwSkJsqJTqhdg2Cwrxi5G/PWU2KwqKtBIWM3RRzGcdEgSbw5sVxptEcSe0QrthJOF
pMX0KgLg0YYw9B5EFxoY4rrSGEovZhVSaP8ATJuidT8EhE22giim8Ah1J8msCSx6ITivYbjzi6Ef
mEdk0TYiyULbbVwhdd2gbOPkPQyXvDAr220Omk3BqoipllTRjAhXqYjNjVkdDaIj7KbwpXgPXWaY
lIm08+EJwS9hqJQ5ltghDGYPQ83bEk6GbpiNjekwHUC4Nv4NM38NEyTwcsKRVTDCX0TwQ/8AA7xG
8s3Bz7ixix5kGI2lDq4+BL2Z5JsJ8F2SeCixkXSiyc9YOTKuTvldBMC5F00sB9dn6KuKQxrJsyla
b2bMplyJDdc+GIMuwhDitdGk0vwAaeLcUsirAxgX6vmLz+yEiYxsmrlCAlRtlFk/lVNdnGND+kSG
P9DIMLMOsIFDACBTSJYEO1ehtmR6xxRGgsCM561BElAnQPkw5wLEqHyId76Fat9xJnIa/wCA3/Vq
wYyU8D49htUpeia8DnEYn2DSt7g4qSrGJ4fRlPMxkBpeD0VMPozlJGtIXSESSJWyvQUwKsXHI6NK
CTOxCQ1OA2D9tfQi7LJ4H+xOcmMEXREtaii1CSOQKcDBIUDC5x0cXV5G3ckraUl9+FAsTMtYuzeh
/ZJPksCqeCa74g5HyFWUN9KJVuqItUDWpb8CBgIVYL6JPqAmiqjda9CItKFBrBrgoIWYEG8UPELy
ECmTXVFTJzbnk2ZW15yIUU3MEa4aMcN022HYzpxBc3lHocJhoYcpFNj5RYZFgtzZG8hxZRjlXQc0
pqF+bolSprgaJRtVeRJ6Njck1sjlG+CZK8pkZqVITmU3DCh4LCoMcwohroJ4OLqJMjlY9WkOWUfk
SUzcwM9zyLC9MuyQp6xBbQMz7pYEEruohG034PSRdA7mGpwwxeWH9GYh9Aj4GkR7Tr4u/cx18lN5
1u+hp0tsOdYkNI1ETZgdvkP2tuiAasrJMlFT/RWwqWg7wkTb4MApZIxasXBYWvAlEPkINTeN6GMV
8bJsqVYamNNLoQJvJcCvMCMyHShzEdt6IdqM2txE8kzeUMXs6BEEcInyHujBpo0VRCfkQFG0VM8D
voHBaVNGame4AjJ8B5OJsmUMMaNDuoraDA2t9zAlOBvK4MpnacCFb4S8Hf8A0aFJaDHT2qBLMwZZ
ZTRtshvpRONm5GYphvYhecZEOL33eRLW5vYhRkDbMkTVK4FSzbSzSHzSZPqGwnPRNKdGarS8lUdj
Xsa3KlrkqvMNsbMct1j3Waugnbxdi8VcwE8Q61GuIHGZL6exARMN9tmsUsE/0cHRc/D7Ps9JkK3Q
0vQ2k0Lj0O9Nvfx0mPMcVTkck8AfyLRcNhEGPAxIjaTUdaWqlHLShLb4WTBlkVTBioZQkgtTLhkj
gTLggYhgo1yPAtitEs/CPazIrBcCQT0ochISRFwZ3GFqbNQ4ZmkrQzXYCsJC1EVSnATZsrEoYhwZ
RrgrbauSR6wYpxcFOmFVOHC4BidwV0yGcLTZsEVHENDCCD/odqhjUH9AWlHnAh2mzywc3EcCkM8p
ZjAPAiEsZniEagitkSCjQ5wWC7KVXAvpL4cwWx0L8HJsPYONtmKbCKbwK9VuKb3eINFVItrN0SUw
M+oRY3K4Lcwsu01xiHU3ATRukDdofm6NiXcCe31h4cPa5J7KLyTT+yrqxSySfGD0gWvDHxdesB6x
RvpF0VXQtLkYHKJH0NevMLx0U73+TMCTwxDXw4NflcElzcRmPshrgGlCbXWT/wC6G5ifKgpLJLhr
YxZ16E8WktBSOFBpVl1PEWhT6vgJtbOOJlpIY1smMDWrN7M2e3gvd4OJRMrt7Hfw3zXgKmYxvg9M
GpHRqoatt3oyXar+DJnHLEqyrD+DdOQIlrsPrSi7GhVTPo0AQTIpy4MW51oUSvIZ1TpJYIZ1oDKW
VJNjJdKkuBq2RedTQ8KhaSwwzyLsTzBQYX9fIUTJrvJIm8hofBaxMPi5DaNQZsdZExvMzyLVYyMR
Nm8fEUWyY2JRdGbS4hwxZgQRruuSbc0CLrjEWQxisZJr6kmzQwymItUyy2rD7P0ENsN9rotRrE6o
Z67lGIhvOGuwrJ54+TDxosgm4+hlz8nMMa3KvoZv+4VO5p6HyPLTfAgqK6NdiGMf0k3EjXkdC6oh
6zjthYt/SNjtkhA7pMckpnkb5HgbZ/fIlWqi8GaxQ55qLPsUWIXAWblo1BRjr6YRhYS062XA9kF3
9UVZbMSCmsMI4KoXDMdzaK8BVuuLokblnYIUzjOULDXMi2pHA62iLoa57G2qcCmLSy4EnpEn2dBp
B2V5CqclZfeRxmxuMeWN5Mp1iDXwVQSw4GGKiFlMPMHuQhvTypXmNDujyFxSzXBqDwLRJiyKtpnY
ZWEqn9K+4Udq5QN2GzIfYY7txFo+a1iIaiFyyQyPDGoeDQyGJF8lvwb4SCmnqhlEfAtHQnzwkVTY
uNiNHIjtCA9+mJEuTlBUj6gcwhKYTQUWkPx8qwaclPfKV2SAfL4KB5dCUpiTZFJ+gfP2yNo9vRPT
QpZMoZ4FciiEnopdFfUSmC0WAk4Tj4DWZXAnlBb/AChLpMeRjOX8Lj2oIn0MQQltvDUdMUz/AAYl
3aEt00kQEFFHhGlcPhz1mdCEbTYSsGy6A4HVulRYanRp1BNbWxZT9G5jVEOjtu8iZSeVyuGy1Nq7
bFCDdmEAnME3Q+0s/Q9DkbQ1tsQnS6GDzEYcFFPzxpFPobDkLQXsEEJOmBxc8DVesihgFzxLG3EG
FFqEvSjwV0Rx0PhO8tEtckYMZ0Ut/DJK1YnBFYRbGdIk3qHZtknewophdDu5n/Cz2zof7zTBslo4
h6whQ4c5LEvE5cgXxtr7KrD/AMQrZO4uAhfb/kRU4m8jgh4UiGLEYYiRU6XI5tnlpuFKHhrAvVg/
sKerekYuXYSeo8gwtzIWObLNItTYzp4posZUnWUoYrLGjwPaYdNIvczLwJacYgnZ+Ctl9DuMbWYI
6ggm3m77FWaSg/TFq7DinmLWDpYtSsfgCSjxo58b0YiJt8jN4wtDoE0GPi+DhNIMXsDSb29+xX75
itK2wERr5N4OdI5DasiWRmekUmNmWP8A9RK947iI9CVzOv8ABwO5MSp5pmFxhIf365fISNeQczSX
LFV1AoJqz4SQ1JKVvkfQ3VWxMb2OjJhs58iaHsa2mf6Nix0JY6Zeoee8Kp7MmIV6D9+oJOzU6Fg0
XyM/KsvoSg5x5M2uztQ4HHf4MYqitRy6C+j/ACjKMk8K8EM1dcDSllvwbWVJ8EYPpIXtNVxsybfh
cs5UI+yKcr2HBUTqjelG3a5P4PRS4El9G2Yo3j4KLBFx5I5Y6VaErg+gQ3UZn1MwNctLIZOMaYql
CprQxIkQUlkx6OIMNcWi0mk8jQr0JMrTktZvIQkmYaWQn7F0KQPlNQ+SxngLQlky0YHAuB5qnpMC
0uL5EJcj8GAuGQpxIR3VMZhqmTfsFCRLkX0uuhpm4F8ZIe+oZjlF1IK4t6MzbFypl2ZKSLnNEVEv
QWc6NbsSW7o6gtidCxHvk2vRiSmYwj8j9q06ZrMFpVbE2q0NdhIYk0MxwTkHALZ7sJqEqwnggyjz
w0QSHBDmYbsSJaN+0Iv/AMkbY0FMsxdELy6y3IYTbghtphfpaGkZhsyzrkNnZcWwQXJSmTrN8Nxc
azkkboZOgpVoy2Z7Bkq4E472PqYQYnV0xTbZtMsvtPLRYd5Emq9izQqWMwTXaMhpgcOhTLk55TY1
tv0Pg/dH27f/AIJL6I94ZzEaH/4w173+iSdAuNLvZl6ehZQ3kjJh3AmVgiolkxwi/A5QsJDPTBTJ
mS0SESa2Z1zk6ZwbEUhhwNFyrI1UqqO4TZFDtKMh/wDCEK0VqIk6TUYG5eoeaMECG4lgS0zBG1Xs
Q1tG3kxZa+hBkbgIbIgJGwTJBNW9Fdu6Sb0RnqKZLI01C0s32+B27J3IbdMOGNaCQmnxQulLQS21
g2+XNGupdYokTL0zGBMFC7tph7wLXafJ0VMw6MkYPs2LKjE29M2XBJJmjyy+bol4ZKfBnSYI3mFc
j5hUG6sdA6Z7El4mYIjJpS5MwDb+xrIuBBvuF2vNrkJhMdh/ZGGgE+UZg+GtDKZil+E4VzcVBJDT
caGaK3dwKssratEcWUJ2Lz9zgrCSScHtdB7jEyJi6ymQdadlVdC05Npwirrw29di1Ja2kYVvP0Ed
Q86UiDwRGGPDLgeR+RLwmQO9ECnrN5Qys3p6M5ykqEhWRx7oW6JISqFBKq7w0hqh6xkyNSKZp35G
Z/zDfmh5HKu7vJMQO0Man+Qi3FVjZ4l5GqU/H/8ABn7JXnJNWnMTE51IoUyqwYaUGJMxDz8837C6
4mq8C5sNvLKG8FnA2hZQsp0YfHx2qFHXSjwbjDsZqK/FgUCd5XRIZS0v+mjJQzx3GGIVwvgTkb7E
iW0oqDDT3RhsqmqP2laXkn9ewJQMXU2kWBjs/KHIy4xurfw3gINZEJMmxZQRyLAlf06MLOGhC4K7
NhDefJgvDbhWMNtNPDH/AHAGc4+cjR/uTGL2NiY9lhQpLmZPAfHq9m/k1osAarZIIb7Qjo4TlvIt
VvJDSHdz6UW0F4Ywyz0ItkxFhzkUxrJpYuZhtV6ISyc8E0m4LwL7FMWJiMCZG+hmk70VRWaZAq8j
mpvoaL0PVkHrlByvENxTaFCDHho+uOw0om/ZSSUKhUqNiMkNHC8ne0mGJHQVcybp9KOV4ZlFnhPA
lJ3qV4w5GUMUQKWBpplcMX2a0rhO0yL+g1L+wznISbYYal5mzZDSE2oux16dhWmPsbTNk6UcnMUO
UCG0w3LexJb2ifvCKN2I9tIJI8+gsMnS3DYoIbneTpIxfel0PTEUZcGvbX4HCPX0KOoaUjGiovRA
hKjwZr8VE3akHd3WB6GS7FBW3zESiPtjVzcGx0D0xfJFf8tjI7Z5EjPQqwfUSlVXk5/DVOrsjvKb
JyiQ/uUWe4RNMRGJ7vJRdT+Gdc2mR1/JT4PIQsXhUbyHQZwNOBn2t2EN4M0eGLxyK7z9GZa46MFV
Imuhl9BSr2bHkCd5h9S4qTooGDXJcuQux2idiBY3kUaXg8D2r+hgDTcrZ9K4PceRrn7kNX7YtN/Y
caIKsP0hhRvyLNBYWRalK4GpLwisYofhhGoAfQLbwbj2OmjIhGPFsK/sYzmZ2Yk75Q+9KDuELkYs
WoXIrpPR7C1yKE10x5Pj0FqaUGRTdMT09g2EB/DPKH6IacuGYxNyCRLRx0WKhh7VPPId/gDG5izJ
eHB+OgkkrfAgNtcZHWTwNmgJqhuG9CZNFohJFX4FLzfImVVxOCXNniC4T7Qk7onMGKU7+FopRURw
sfQrqraTFTlNyhXQ60mJcOSvTz0LXIhshWvBTL7A8Wr6CRt8CGNBqFNjN/EN0kWMobyXHwOkRArT
NlTb6ysJqKx4OHwYI6aKnVhTR1yfR3Aocr0ZF19DipRIUWTSfBfX2YwcZgqGxJ8SHhjdGkngQt4G
mxsTGE3BNnLBi/jPThcJIecBZbEgz+sZsE41Cpv9CyE4a8YErnRtBfBGlZV9C7n8LoyVLt5Obl2J
ng8jVs+hNL/A+JUIRrPRgouqh+jPggn/AEx5u5pEYiM4X6GVt9xnjXJ5w3BSEbIbjU/RiCFdTQOj
YU0/SVq2d0dsajKPBCUNvgYR08GllImSy9GcMLj/AAPYYkttvQxDhyZQTgSfZ0FZeRFZrON/oxtW
Y3/QeEl9oxBQ0a2JeJdD2tT6ISynyh1U232hDCF9FfB0K5/WDG1fQb/syJ+C+h5ov4XpP0P1HlkN
vSHmFfRVMuBn0DtqzFTg3Dn8EtUdg9NYXEoQ9Rh40Ok0xyYVo8dD6SXSWiMcq/osKG/RLD6Dkn3F
NEnG4MLlEttYQkq1ldFfj4uDXmYymtwyX/I2wkmRW19DW4Dgywa+B0KtiZLbXowJF9FBWtqGYKXb
F9NJW4Xxs6Q9tE4SdneBNpb0Q7wCjA+miTzno+j8loZTY+0JcpPQtwDwNTsPJY0pWtCFCUW4Zhnx
B99vpjWofQ/KjPAq/bQvKhrEWhbHdtzhaNClCZG8YFNp5Be2OGKMsH6GG8bkmsRCm8LaLOPgQ5dM
gywo8ESivGC4ETl7GIrbWhFxTR1rNHt9ESrqDuccJw2ZECp0vmFnFJZSHimzlTgVIRP8WmKgJWE7
H5BNYK6JlDdnFBZyppodqUvDS35LTCDCzNstCBTdxDwK+kDeCtaIWjymjsJQuDtbXCMMXSaFRk0E
BUZPshC5C0iEStLAbKdKXLE+uakZgh9FFNkWXQph94aHPhkcay9iaL6yTOJUTXJKahgzrxt8jFgp
icMa1bAIEFdzfmx6GQ/8TMbVqqPi5l4Z7tXlEaYsTkivwGSpki8B4NhxEorVgUzmrYnDtWIU/oRo
c2lK+x2LHa8jEWrA5Z9xGTbdNDdpR4aFt7lNsbCA2BWU3wMhstI6IvsaHj4YFINf/A8UUq1kZguT
IX+mb8kDmuQ2PxNY4LiRRGnNCwNTiz4hBebSUFNVpKYDYRSZI8lITrflC13w5RroyISrPk05tUgm
BMSUyFB0yRuHBGOjQtknJkXTO7Jkp4JUic2OJY20hXc1uDuyXyLoIRs/4SjKQzSJmIKjRhAopodw
Im0g44J4HhOhOZhjTORUoRk1GRUnSQwnh0YmI2qYaLEPaRcScmHQwJMk/fobhjdoKESTBZHJpPhC
JWappphGLCMU38AGoEb6GQ1DDeeMFTEmdVco68EGcEkmR4kEqkpsgJT0tMrZt1UjFkIwp7CupOsn
PiiPKwcqGNmKxvRNPVIeOEnELfDo5nnoyigsYn2MLaLFGt6K6jbL3YIafQfqmkdofcFj2EwPgKTa
/aIzpcYGJb+zVOZIrFOEWfDgdSsD1qkYtOqdlG1hdPqD9EdJDaY8Cu+QdVPRp3noe7R4JAaGErla
LElDsuBwsxX9C8hjgUoZxCGFngclV9Eor6H9BY4+FrXQ7cFD0Zu5/AdpTRzxjoSXkYoiUbjwYHV4
wZtIZMpCEMzZIRpZ0YM9haMRvotYNN9DE4yCrGWxBibNVmSrTuhO44TwL3uFMWQewqEmgZAuR0w8
SooK80c9LHhDsV40KKRWh9R3kai7WTejWG9mLgZpQWSETSXRI80wQM2k++i+fYUEuqWQbvOtOEBY
hlVT4EKSfoXnjwmguGNlalOAv8Xkuq+Q8NDGDqYnxWENyroWg3zMpVVjdVgGWJVjlKW8F51Jozg1
UQ3GPKYclRU/pu80NGJ+Zl5JnjwFA8mO9KVofRVZ8D3SlSQ2l1L0ZlcMR4yPDtHAoDR3/Ah/gITl
TsOmZ/hU9ZMBVSuTaLzUdZqORvZZvIVOeUkXk1isK4M1UNELn+pM1uQ9fVxrYzOzcd5IohpU4O9F
VJOxcIWCCcFQ0OUmkrz5MlNOy4HgY5b2OJbGCZq31g9FDFfWL55volNroHrcBTlDHKaWYK3Rb4wN
Jto6K3ZF7NK31qF2G/4GjXAMcbXK8LyNqbIzIo6b0PLBwLIYaCP78WMuqRMaDJ4RxstaFcfkURm7
Ay9KAc0F/u5PQt/tQdC0RNKehlzok5ylsnbIPAAigQyLgtQbEc8cglNZOgc4/wBj/B4KLYxtiV+A
shFab28EL4491TY3ZgJS4NPfCFEyzno+1Iv7B4xyCvwh0zA4lsU1z0+oh4thFGw2JQlJnnFA3zIa
zyMQXsEOZ100vhiyCKzawRxlIJXQybtw0s8lhrY4tkFshdtoewxXLqoUj0WDRDVs1Q2NTC424Mu6
E8uGJQ2M8SENnpyDTWUiIW78lY5GqoXG/BVAxzbyZyOdXCfwHJSulsj7vgsTER7Eiqkxoe8fItu6
QuPiDocCvIyyi+gr0yF3Q5TML2huLTYQysY+TY5C0Kj2LCSU2KPFPo0G0LDgcAlF+zBDIV4Uhd1t
ldeDIM5Gj4PoBhXLFpFvBMYOxk/h0nAqzov2yLYKGWnnIzL0DV2QtddBSYEPdoh2NkiRKYITPoes
iVqUJajAZiwow+Ek8AqUuIJ9xVIhZJJUWBajyFyFrE4gkQ5DUUivhLbh2PeN0W8Ahd6JGJt5fxM0
OUSiE2QuJIkw7HRTO46btdk28EURP6RISp7R/ZMU6xnhr4RZSbeqkYNH+Ah5GuR9DI58Yyz6Cx/s
Y+k/hLlG8DxAlJ3FgW0T4jhkYrZi2f4DiVMANIdAqo0siwYNCG5tNrn2ZpA8IE2s/wD6GDWpwN6U
MEN1S22JCjNR9G0e1b+MgAWs210Dgxb+zleEag5Vy50GoybUp2NRJ09IUUGYMpo28vMwRSVIbtIc
Ib8eqFinAhJek0cf1jAXlJDmonodOTZTEemZOk6v0RyComeCOGJScBPD7Q3HW1sa/wBf6O3aMVeh
Je/LkufUxvWGSmXF5b/RWe03k1UNv8KTTHoZ27BHaj+FyLslyKi5ZNPwI6HAgTBiDdYxGSxYKWYQ
x6mGtCxwNLwH3n6Mh014icnSdJG67ZeCSePYnFsVM7HLzh3qHEmuSXwSGSm0Yl8qZjumPSMjANx5
EZWDKPEjI6aZKcEj2NZE0LLwSexqNM2/Sf2fsPAk/FM6jWS7Q9+fTr4K87bTMETT5+Emr6aJn/8A
EgehshMXwtCzOUZh41VZMiaOFR5vQ981oz2R4EuzgsuDNQzI3DgaK5Fewg4Hoe74aWMeIdTlFnT6
ErsSK9zRI9inO1GJ9daPMH2Mqjky/g7V29nEbGmJew11eBQ9cBZb+I29mBxjxUNk2rhjjlOB46tF
SibychQmnwXq7grDwD1/AgpOLo2BFdviBJDbzEG3qJB9DbesnqIrZRdYPMngO7d0awUoToWq0eCz
E+xYtu9ldvBVpVsYEfuiUGmqLjbLryxwJr3IoJoNVUahMJlIcDc2ISMFCwMq5HQzEEKikEZIQicu
zfhPmXBmoBwGoZjgdkG70eAuxPQaOB0dhfEYx92BBcDcyaFwYvob4AnSuBsQUF+K4JEyUwmgRlV0
bIE8EA8oGwUqonWkKExnlYyrkPMgdJ8uPAmnjWwtlJO0KmszSyLcELKrQfKOgzfOo/qeRjUAC8St
2h8r5gezHjLMDRpexuVPJkgTaMbyopplibQaE3wdCSKwUJyrkayVLQqf7bNKyKiVOh5dORPJHq5M
qCw9jw5WtmkU0LJTqEDWAmUezfYjJM3Pwmki0qt4KZ9UNrMlLJLsxsZUr/smHsf21UEGdC47RgVn
dXLGJs1rAxt8xFsyGMamWDKbAiV5trwOJ9KhZoDrHgLxzoYts1re4+cj6ZHJ0oaN3oujD1HWyY4N
7QKrgXgUWV9CMk2jbpGJK70LSZzwnoaVJPKexUUGNZ0VDKWKTGQO2J6rYzEy9nhyukvbjMlHhcRp
zRNYZ5XZRfxj3WJyI3ls9IkwWCCF3UYDXw9/JtCywR1qlgoB/HDksZ4HlV8BYZkG55+h0xT/AMoe
xsohbP8APhvBM/BQ1+ELoWL4FrGNG4ESHAstmnIj54FgsoObYJwVHKUbYhzT8B5d2XVEhKR56E5f
DKnLgczEeenklsU2M2QQ6zUG4ezaJHXw9lZoSyJsrZDSpXM+L2vQnriiOA2Ux6zgEdXuDu/B2vOU
1gYRPoS6T0Wz2EvCi+Kmy3/MZdiSGPbBZnIXyPIyKazDoArJasEqksOB+TESWEwSroWyn0JE2NWR
CLfRtIMxTdwLaKDvGULqrMGGAm4pExBwDYk1WKeQT+SZFpdpHuYjVygeKmRI+h2mWi4qwGHYZRxs
RoNIjHLRh/eRuCwKdqjsdHCvcDVT4HD2Y16kF8moyFLOSRTXIi6uApL3UW8U5IeIErCwTcmalBh2
2E54vBmS4GvCGK1zksi2Lt4i9FrWRFtWdObezGVNCYuFyIt+pbpAZYNtQl6jZIUt2+CQVTlokh3y
JNOMDrW63TJgQp12Vx2Z4EVNwfcUJN/qbFGPMqitUxV5E6lgjsjzolkCBLgLk3l+lNYKeWhTMy0S
7HjdDnQDEf0C5Oj5TpmD+BtfkHxYz+nLOzGIvOSacY8jk49j8UteRkFryJF5iYxK+1hjDW+nQ3gE
EAjDgQLMVLsXcq5AqYjEQxY14IE8lvJVxKmQJabpvHRRf9qqI5iSMUMa18DPPKoMa/BBjX0UVVch
Azpc+d/HwhKPuahCCk8Uqg2xU+BpteMsT3CdvkWr2kxkpj5dc5EBIvKuEajqPRJiPCpeLyuaSRMt
J8mR/ZplQW4l4MBODOiGM3U0Zu2X23syKMSt5ASBMK8hZyKLqLUJNeuxaCtR4DeJAhFWDCcVfuY+
YUKA1409nMsyYgIjRW4UA/O4jswFBViXWzYtsemPSdjgZVu/cJ5SL7Gv77KEBaMdU+hVLCrWxEcC
BHImyITF6Wo/InfQE7RyEvYxV26oScYqE+N0xLNq3YJ+ZHk7Nxk4tEpUmmtU8jQlSbRwyZeB6DxU
070HOpT9g8k/AF0rxqamhjZqv/8ABfBGVLY3CXHZVVyt8i9LBJ5gnU0j9UTJxBZSMeRIQu5PZPRf
2J/Yzk0LTn4hqlOF9i4GmxR8eRktpIehsLz2HcHEAmiop0vsrk4nAkGdyTFw1+gyzZLwKVtejHm+
S7Ui6Mb6R8iKDaXQpsD+yPKp+m/OlHRtlj1kBvIyjWTQrnJ5FrI1RobdKRpWXS2Pq88MaHm4g5ez
sXiOG02OLbTpCGxrIz5RbG7rTeRQ3HB18XJlQk+z9HGTCboHZEfCOjVRNPwNlTOykpvyc9p+CsJu
sjc0cfDZeLVdGkD2N34CEkdCAo7DtKWpQWQHoc19gbGkIjLOi4mljXmWBGKSJ2On2AjXlOk0Zp0x
yQeWOXDQjU4cEYNe21eGx6b1baEFHBiqkxy1Yiamt9UyLyBhbfIwV9DqKfDQiYZzQDsgFT6AYKhe
zn2VEBDsLV5awSVl7QiSV+BG35BpKdBeGMuvY1p6He9tMVLDzFqgvArXD66Puxdmbf8AgOSWj3kq
iWXwLhzQxZd0e2lYwqY5IP4BwhLD6Jdi9clFVfDKO6Mri7o7x36Gub7BdQhdi5u/VGxtiNNMbsnS
Y4xA0VDpIo6XlDM1V70PVeMT8eqlsySr7JVMJpWLtFyceNGwN3C0e44IbLLoUXzXRlyw/wA79ha1
YmMk38xIBhetGYy80b0DNDXXJ9NZvZJvp7Nuq5Q5nosOEMYJTEFp+wLzS8pj5R+mf4hhtQONwQ09
8E87yPqW9iHt2fXETG9FXnJNFnwMrR+2i31fY0wKUUuoOaNPNSFJhNi9g4ExSJ0j0BIR7EwYl0bH
p+HiM1ka6FBNngvdPchO9DEdllg8ZF0H5QacX4Q94S5hiaP5MgiI2T/Q6ICaeA95K7KOJdMibHQW
Um2Yl4GLGhHSM2JhdSk9CyFrpBe2vGzBfAaOjnuFJEMWYMG3mFdF9DbqrKE0Q4G278M+SnEE5q/a
IBMnFgSWapr5OtD3wBeVo52FN4qsSGkVW8HAVQj09SQ8/wAZo+sUTQRWjhIs3V4Y8RU5mz94FZes
PAsjd6MA9BpaRba4MxSBBu5rS4ElENWBDqNKCz6E2Q9zgZBXoL9jyWh5Q3lwb5Kc9DWS5NjQ/BeC
TqsZehBKSVi4Uf0YDFiQtHKsE4OXl8tC0pm0a6eTF8+IIhV+hV/xLkfwy32GQnS7HPrKUa3GvCOo
D/RLHm5wNiHrWRW/h4ZS0aOhLBcmjyZcyYmFyOwCuVrr4hJil9CXMITKmPCXDgszS/SEqnFhbfIm
lL2he2mS4MixvIrkg7X2MQcwotr8lKZ+h85gZyLkTCSehofBKJxo36JvEgYK5gYNfQbxl9FPIRz7
Fw0Frfij+RIfRQ2TBENBPIgpWWRT9RM2bYt2A0h35ZwPaRjI/RD/AMBnXL0K5H6FnaKzyMSKjb7H
sTa0CzcFiUc7FzxBiYpC07Wfo+xdwysOcoSmalkNO30KcuwhYoVNvY4RNAdV/AsZUJLHXRFv+BI5
WS4bkG8BQRbMYXkxapfyNBQZSE3gkUjXoUrFcyVaEZk5qCH/APBG2r6EltK8H/pA8+ZS1QbP/KHH
podnpCGhFdpBpujweIotN99CKlmeRCZ/MyENCzI9HPiuTxMCZjHKMezc5B+SnBN+BxtRPB0FSloX
btXQi5C5Ehgcl5eHkUS3cjHEa7h2LiIjgc2YoRZGBzrgyOwzWm4gwhs4JDVdrKaeqGiKS4HV5gTg
UxWmhsphgWYWbho8DUI2X8VzRPQgpOBVyUjmyW5kkQmtm0oYcerganJaLsjynbIUTriHNNK+Hwha
PLKiazGXBzsLrBAoLasyq5UjKoVOn3oHstJPolBuILRSPAzd7WhlaskJSVaFS9BNbLBlNWah1HU0
4LbIkpFQ3kUkoO18J+KYmBPXkbQWrgCCYJLag6L1MDNfn5C1kjB+fm0G7cSbRny9OC861i3e5PIy
TPc9GaFrEhhe8mEkVxtckzJMlMCEksanKNIEvobdlmGATUsCCKvJUU50NaovBu9cLkskvQMmIiMJ
FxKchkdekIm8nGqh0rC1pEbj5SMo32BkPXqwE/jjBPULwN3UlTHqzkcJncHmO5LQynpskhGDTM8j
zUrsh2eg3595lPRjwMGJLsVFrg4eTMJLIbmJ4VTW7nkZzNlcIfy6+PLMccVSGS+PjKZaLD+CX4Nn
BE5qmDwLfJPAqbIUEnKb3aaFbowJs2rKL2T0HYmtDxUsDHmMR64Eh1hB0tk2RU0Q7ChELAT2Tn6F
PZcjNoRXQr4E4NwT4aRsJNUXwWUJrHgY+WRmXuC7GiE8U5h+hRTWhwlawY+7MJhIaXsciUmioyDB
DOkOvtuzKFhGM6EDOl4PAA8zklpJkwNEhRfljS4H8rWPami8gWFMHhAbwnLNGBwkKTLLOUqNDlfR
A8sCZucCUt3uFo9DQN4MPHDxEYCQoYZ8HGM8CtOQ4uFGv4M7MDabK6F5DFqcX0H7hdD2Qx0JW14E
4E/ZASrGPAwMkh7bXAobBEgv42VorNwVflLA3Xc1kLgb8GMssaYCHwoLQ1lmiRNmi6yqs+IDi0tI
8JQm4ZE9zKHrxJscUrY3wZNZEIm32YWg86EZkYKOIwFZSLQqdF08mjVMilhWBWsbHJCZbJHkpFbn
YgQloyNSGS2XojDmGYnnLI93TUWjv48it4ilK8OhTRmpkwhhKjVdCriHITYkg0HOQ4HiXRCE6uCb
7Ka+geWGm0mKJU8k6Fekq1aNI6OGCxAq/JEacBkKW2xPPMRPLsq6LQHvdviDyI3YZXi8jkrOoF1S
SGKuRq0DQklPTWviZsBQaF4n4ovilF5FM2RV1JnoqrUrGIMSSOGSJpiS3wbcwJvwXLPvc005uUw2
PBG1BlMpPB+GZFNBl/IFybph6BgR9a2FdUVSDicfsJ6scS2Sy6RBQPjkUKjAt68jaXwuBFFdsNBU
QRwfqB1kKPdG7a6vyIHoXhfavMKlSZ2OCYh9R7vQzAPJ+R6RQahlE8CwGwRtwsQ5wvIwNe41iNL5
5Ma50MJhJ7YOYgXV4fHaT5TLAleluGc9IOLwXEJv0TRBqpQVkeF2MmpagoUmGKgQ06mYmuRBjrAv
GGrDG5jOpwqM0y0RztQKy5IxnQV1h8nEzQGLV6WESdDk/Bsb4mFloKBG8BFI7x/0gDAWm1GKW5H0
p5+VjB0s1sVwlInhmy5KXQ2SiE+KsYORvE48muHB65Ewyw4g6Y/JEcD8W2or6cISXgF3LGNGY7Os
ND7fD0M3sRWJRFR7jY4HeTLln/j4XPiMWcg0RpfGxKCVPIhvQofUJ92S3jCLhF46OWSXeSUoltgW
9SajBxwJkbFLzfKAL1dMSkW+m5C2RrI0ihgZ84cD8EKyLgRaPixbZwEJRjUSoZUMANPwK9gSvoKJ
wqXQpJ2YusQV9AxLgVTsbhf2UQiiHcYoG+CNEJvo334qF9umDhVawmPX9I8kOiUjwKhdeUIRRIXZ
0L+w19DNqIdzFfBy/ehWLoQ10xZ8/Cp21PjuGA9D3MFz38PCfRGmvhWEEp2vx/EdgBEU6+KbfD+d
dkwI2C+M0PXwI/mE1Q3mFBNtPbNRyE28RCtt4Ii7MXz/AOAsNslVuOiqljZmmhqIxlF0HyUE26Ks
Y+3hBU5/4J1h4CnsleWRxbNo0yJJmbLMdpxhijbIirYh6zdxbRFGWoWXCYeiz6eWbKuw9zCSexDD
8giegCmoTtFFdSCrdVHKyeDAtKY33g+0rRRCGqqYomtGnDM7eEtqMkV6bGaVHhGVHFl2YINzLgpg
ztlbgv8AItMN/wCIi3Ej+zfQtwN5kCnq5EajtsS5mvCggOcFY7yHVy+wre4xnOptiyGTlJxMEM/f
ARwdA3dk99pG6x/I7OidEMxdDLL1f8GTaUYvXKwaAzG6Na1cCxVzNjNB8IprknQXswqoq6VpbMYp
wzdDN12YujSDuKTm0F7W8v4KzBhIs6fI44rBlWeSEOrCcUjcbM2NbbTxUNqcFdFgBFgdFbGUOq46
lhjo3sgx1d4MXeghPvki2J5adZlcEQeF22WNzm6kKXFtBjjgrQs9xcfCf6Z2dlKXXsiX/wAwjsqh
8y85hLsvY8mxC5rp9jNMTyN9DyJQak+X0FfLHqG2N+mpgxkas8I+fkfJaYO7Qo3khCpoRswhHaiV
1cHrUyoGKxIhpbyUH1Yek4AzA6v8M0bFEmx4HJQhBgoQ34+HQf5JRbQ3KOaoew9BXnDJjR8w1Kbo
Jtpgk+CTIcXjLmlybKVtqffqJo6NLDe8/Gigpiq+ExVGx5QdRlTaykNSbWWWmwyeE3RYbEYRpS1B
seURinotpjugtzDcCj0XBeoT6BgKogprAyRnccbrofwaK7w8iMEDMNOfB0fyBDrdKML0xBYj4Q8F
pMtJpgoCGMbZSLQmAl3M0tNidXgOUdOMSFSbyhkkYHC4F3wErKhrU2xynrRzWgurtfHik2hHp5GQ
sjIsaHOVGl5CY8UZDRYDCOPgnNihGDpQNlIx5iymxRMPIhgU2WmomZrlOUjAh3catNMl3YdgHaxC
vY3nAzpskumRcpbdGbyh4Qk230NtSdkuHNtNg3WEPuRfwkI/JCzaT2iaCmeah3C6I57g2HTi8EuP
0YAJZ3kXcooz6EFptyQ6bMdDXvuEWLRCeudB1eGlhoLWQrMYhBU8uBUVc7eg+exIqZeGG5Y4LZok
79FHQ74Hvp0aFeV572bpKsFIE30TOjq2H7FViCmOyhOGNr9FU43lgcDWjI8Vr+DUww2A5PsSDkor
EpzlzFE8hnNkIZqMlTww3kn3TRwOTLwI+VcNkZrvRBqKRVqCmczoXdOOBqciYLOxyMQKtjmXttFc
dDBEnH+IrbbnoeK4TY7gtyfoe/AWU5tiVJ6DJVgYcrL8DIpwLwQh4dEKN/JgyGPCrxgSsy0kmRkh
4zI0YBWhSl7UnHkUtkTUVGxDM70lE3G+wj+jE2K/sVmYDfQs4lqaGTnjLK6WbSTf4eWjkW/ibEvo
MnPQ2SlwNi/aYbN5KSNveRr3SN6CFwJTsWx9m2Q6gtmTF0hchrdp4CDhNLOWhkeMhQORRz3yt7fB
FfXfIy/CNysGA4wbH6MLOVg8Ls2jSMpkY2bKUW4J1DSfA3Nlk3DP3Kb9GBgwmISDqOVRPbHvKlB1
4Zk0DX5I7FFMcKGVJ2JTJ5FgTPkW4WCuh/JI0eHkjilLyLTxdFDY1LPAmhYkI6JkyjGxj2YmDwmx
Yzl2hiiP0xKwbyWhf0UkXjI/izJ6aYlOFLmi8p6ZEZ4GxepZIEXoUW5ZwfDUaYgxLg6TaPAoITFo
mbtDolPjOyhIJFjdT86GVuMYV3CLqqfkw1P2OqN4yKocGTHFexPIG8uYzwYUtvglFmbAPtdDm3az
RsT9izbh/p9IWaKX2JtD4ElKBbZKMkKJNb/gvtq8E8f0aLkjZw9l+uApr3A1jKOmxsNMfYiNpRVL
12JYlKvHYxtauxJXVNKIAoo8LyOZ/ZMF32yGU/Yk8oibjgrtN8jV/sNbcjsQ0Pca4r0NG4JVk6bZ
OMvNORyoPy2KX1GxUcPDLoHdgy+jKbhLH7UtqTgzw/Iye0QaMPulmTXLFlNVwLclo2jntiUyn5Z+
V5mcWvsXicOXBkWtyL2s2GMbTVY+PwiLVJdoUlxa+RDA0h6UInzZlngxWjQkdbs4ISH72bHUxCEI
ozWMao8Ntj9J5ozQEFjio3TwpqI/Juy5HsGZhtsJbqUU0lo02Si4mMEVhy8eTYQON5iQzZKcMwtz
KY56fdL/AI2MqZKmLrDRLqSRtah//wADzpNLvo68WThLivIUZK7dCmv2HDJLJkSn0mUGqZ9jG2oy
FrqlMiKitpKDKJSkhb/0gt4zkU829ZJzGYG2d25NFQxN6W0K04XE0zbuhCdz6OrkAn5poZpXTQmJ
IzdyVnbMzIysAe7Ldeh55utvkQPaomqilEhklG9yfQ+ZHeRNia90b5lhOBHdhPCGdcmHSOvJNaZF
OSJUJ0SchcjU5XF0YLdqKEzkXF39BCglqbHJE5kaCtdo+jjIx8qrOhJGNFiVpIx78yPoxBYfbm6M
nf5omZZR0YQvxWYoWeg5zaOUxnZGVXkcRC05q6LQsf2BkO16rG5632D6GdDej+giLoaqax8jxt/u
OnI1nRdNZ80cyPIsi7jETo9G53fJy62B11L2Eti5HoemTvhiMIVI3Re2EpcfKD+GRTinHxHbyJmC
g8ZLYdpPGD8yQVHhz9RxHPaErc2u0bW/EkW7UxrKYVLhE2/qcA500KJi7Gp7t6NEl5HsZbKMvQ+4
75LHgTLM8x+hXmPoZwvhBmOhXyORiCYyhm1Wzk1cIdcXRfNmzUuiGgMsf2M4BkJl7FDzDoaeUJLf
6Cq0X0+xMq9Aglt4NreeyvgxqbGbDPLva+EAl3eB9ZNAfkU7xk2J9HgwwBxsLRJ/HEzyew1ViJ56
RJno6TeSzWvJBXRvWWjR+xsU06Zddy5H2FWVeLTmUzWsTxZ0K4baoa37wYUYxndjr+BjKtXgTUv1
EWccgKXQIHQZFZ/ZsHzM1N/imQv5NSyJYjwY+rvZl5UhfvhI/v2UAxzV5HhfbGVMjWtH2hcmvkyS
YgTgKolL2M4xfInYwi9Rn9q2PI2PHLCWO/ZfNHPG4YfwBt5u2LQjdO6UYZW/ZSxYkYK+zhbNdUdP
eRMF06z80bTLvsS6BmJ/qV3F7NxdfkG8ZvJbtjLUWUTvn8H1W37IlE1LgbSXnyPQTs2BhczHdxna
nnkmbInVl2KlZ41GQN1FPQ3sGmq8LgzYHYeQUqyYGCbMBMH5G3Bb2N7CnyRvkopCrk4St7G4Oxgb
tjdssJhto/oTt7G/IvkNbcjVI0VcLBuCGWLIsGG7ZXZaH3HIn5Dd4+NIsYMSLFbG6om5CjkxYmvw
Uw3jDE3xt7MF8I5F+R3BsqlnjRZXxeoxFmEUi6DUjkLkh2LeS4+Dfo4RqvI8Y+GxrAkJnA/ifD5f
g+kuxdaWRbNjIFDY5mkmROHSfkb4N+iolsiB2hLCrZYxBljDBLfRZmv4IotHgk0j0tpjFSuxxmDK
IOW1RK0pWMT6JvoKz+3i8EQRDSmgqQmyjToVNvjTzobJjccOHENkEuhnjIkuhayKoiMo0J2Q9LB6
4I6M5aYGjc2UYmDF0d06diBp52JuGMufDG4AplCgYiGzWOi3N6h5hOj5ZlixIFkZJphXXZgHkZom
NtDabLPZmVCi4CrZxFWDZ4FhDDdHRIoovIlfw6Qvkoyk5sQSDFoTEGJ/o8iwQ2K2WkM2jE2jQ1TQ
uDBwZ0baM2ZpticUK7vHwOc4EMT8HpkZsNlpVBo38U4qjfJcdsSLLEKxlnaaG6s0clozRtZJT4J5
E8m/Y8bFp+SsyIT6G8DNrJUs8irGJodU0ExtM5RUhsj1RiNHXkrYngYxdDj41QTMiiyVKix+BNEH
I6IjexGWxK8YOBl0dIzbyOlTIt+GUeWoN+RERDInGNk6VtlpCe9mgnDIssdRkJisaZ+DbwbjzK/k
t2IDF5Ih4l8igpDA3gbEymM58GKE0G79CDDCaQ2sko3wJUaQimyHhhkblyNHw2T6CstmTQg3y4Sz
GEtCWphB7proWFQrqEOQTtbPyoOhukalmJAlRzCCcFtFEZVhJqqw03JM6jKpSYh0wdS8CliofirC
4G74CV5LMLX+CmrEtVkKlt9Di8noY5NMzCcjKQiVNE4HI5XQxsrOdPonEw1YUcT3Oz6mJB5Mm9Bs
Tgovf/DmQ6xQPlj4Q32OrVwSykJS2cDFafocYREtguIwD7QWNllYyCyjSiIlH0VjyP8AwI/8MRhA
ipVjVHFIxwHOiKYGeBLOTDBtiwJTSCYplwZEyjwOPZkiDZO/h1gyL9EgrT2yLeS5Y0GhsUVLZo10
WvHwXArvxZkYn4G8aMrY2ZD+C0KhKGhHRPEFyCxeTJZFkWhrGsESivAxLNOvJsWEUTXLHhfBxCwi
qImCjfPxwhSEhsM0jJmpkgokcjwzQnAuTj4Jg42bBvBojIO8nR8OiF2GsF4Ecmv/AMN+BbHk0y2J
t+x4I9iYY7GZGjMOwvhqmmXD7PMeRZKRclKaiybNFjJclycjNxa0LIfwVlg3aLJcfD8oqhssRlr4
yNBLyNXDS0NSsMQxt/GmITkpsSFljfHxfsN5yWoTvw2+TFmbNaHwdGs+iSu26Ko0oU3gyiHwXJI/
BoEXp8MPRNvA7jyNX2KTHumUn+k07RDcMmaFZuH/AAQGIM1HoUtrQ0mlog3BhqWEQ2NkKrkfHOCN
DJoTIwXmhlMuD6/CZk0HzBGYoxLKEl0pt2QoJ4bpgf8A/R7TwJ1JsRBNRw88AoqRiGf1cMwtwPFF
EihjcQlKfQ9jQr1wU8qMQWleBXc4MEiE800awoyVyK9lzA3RBn2XuiwKjZ5HgUeAufgSsd0INGAs
seH7GzLY3oWR7FBg2ZwcIQjdHiN/DSOB6FYfRGRM9mEQj0ZQk2PBimASfBISULlKZdEhINYEG5Bc
eRuIePj4q0zvgbr4IXshgVohcmYO0WCifY86PYsqUMQhwOpUWyoywxfFHsYnwufBceB0PGypn0Nk
42PtCTJBwVIdbGISosDtMNeRhO6CDbxdFNhbpkvg1gw2Kn0WsmTBtlCdIkcuvh7RrIshE3gvXzKM
QsFYMMiGg3EU2xYZ+CejyLODYTwNPsWBsTE6318J8B4MI4D3suColL38T9jY3hFsHgo4klRiUefj
RIpsUjT4N+CFocN+B1aQskbxlqMymV0F+ma1jQkK0nodHgSpTEVRkNm3TmIeh/0ixKaZHrXMG5Qy
qR1a5FU3A9ORmwq0WjEAAn5gqKP0RWGOn4E5JxdoqJuHciamVzTcshbzH4TJikbjDKK6HL2Bo+TI
6SJVvBbvQv2s1oYq+eBrcx2N+nFPQNfP4EQoGUSzx5OSgcW1TAMQ0V0Pc04KTzT6UNIxDB8mRhk9
qnbQtdZSJkhuKVUyq4NKGtXg7uBeKGYTAi4IQgLT7MGRiDT9BqDAXA1SRYGnChuJRiYx8RjWS29C
hoWMs2NimJYNaGbYkWSqh6+FkaEEoiZrY3PPwjYWvgxm6JtI2NlVFh4HnJI8mXwby8DwKlSUYPAk
P4PLwRwXJvPwkpTgXYk2JBKMo3R5hLimghSdGuQkDfA1mDmG2RtcbOCUjINS0abRISkdM0yZNLRo
x8lMgLYSiYEFPwnQ3gQvnEISkB3ZYijZwXI2CjaFn4eRsaLEXBRUTyOtl0YykwLCz8cF+UqH2Jh8
mFoaolkfQ1C0keR0oya+NjUHwQ5BoaG0QRRFZsvgjr1DAJ4jMy6MHBYw3EdNER19j/JeCC71nFEt
Gpllk09hIagP0YdLGhZiTGEGaWoLHdF0TKR4K20wxJPOYGSqhPkL+E2MJSZPqs30PJtXFZlx20hG
sj/iQgyf5C2SM9h9SHowWabNNkTMTNzUIOLHZiDBl7i+suZDW8jzKXkcmSXIZIi9jVHbnIzYibOh
o5+zRDbd0ZMgqDdZEow09nuYDMgaw7HdD7G5V12KFNIakKF6Xqi3dJ80gH7GUfcxXiIZfcUU8Kww
mOv2aRSCpMvAfsFMqNcM5eGxDT6HwleDgxsM8pC+nxU4cNMakNWIJpt+De5Q4mNjQ8iQPdPhrsTy
S6Q5wPmQ4wKc/JMxMmi16NCTPBS4Nj18IOcToeWUJnBPjeIN9hxtDRCR5IcjHmh0zQkQkWyKEsDd
FnDYeKSjVwJiwjkimk7Cy3gUPePjIhBM0JMTtiedm9Bu3yEqPoRhkWRvAwjwJGZZZZoa+EGzL2Ov
SfBLizOxCxhKi4GoHgFZzlHH4L6n8ei0ZDg3Lj0c7/Bm0aFQ4ExRqVFg00vKFUI0DmGwfQuSBYzC
KMwi1kLk5ORrJzUJfpkQcC3TAfYmMcos+baLAbwNjIgxIkcljYoxuvhK0Y2V4G/iBlRujZ0PBuHI
htEWDwOCDBYya5HE58W/Av0CZcNjyrYvTU8wmKbYZg2uqIar2Z8KLENyja7RCkh8sSCrHBaF7Mzq
ky0j9FBt7B4e/JGV1+Y2r8GR4KG9Ippm3aKc32N2pWiCMznZstPDFpKfYakYGrTr0Nu1+2JYlfZl
shAVXTg9mmmcaGJTHmK8s4K12Qs/Y8lNkZuhWMvZh1DSh4hkhftDlGPyJHVohosmKaH+H/iYcpj2
PR6Lhr7EjdZE11P04Jt9sbtuBkpr0c8cEobTyUjVcfNFywe6K9GmxL3ggOC6Q/Ot7MyyMUZZX+CN
0PgZZSNr2bhfwbXBV08kKj6OZA7kYx3QZKXJk4noYHGO7xiVN94cr+ByTXwSGn4spg9Kxv4fyxOK
MD1bBgfAY5vgT0oGMHXg7wNWYkKhv/JHNXXxFQRxFBzUm7pFJ7ehzBQanOTNMgxfIeHu4OevI/2J
2bcDPA+F4aGtjViGbMzFY4HT+OwchJZ4HAZ0UGvyGpyfRVlXgUexNxGcIxiw2eBlC6ORaag2W7a2
K6eMjOjNsgwkQwbz9DXo8sy7yboqeTSrRzoTLg1GMAuqjG0JVmpQsC0X5QkUFE4GiL0xZayaIJ3V
2VOrsIHjE2hkrow2hWCEp+wZiU2E0hLsXBANbCYsJvUNLlCsD6+4kNc30IhRODsxMChW4PQirj0L
KcjAsqgtIjaT+HwjqErHgtNDd+bjAln49jYXxof6aQjEmzn5fBeRvPw6FCb4ONkpcCwhsWjFm02P
RIjY3lDoyJghr0bvPy4+LTeEzSnzhs2IaGBXcQSFGm6G8k0Wi+DLKwZ4GLC6CMiW0FqpjA0VZVmB
E9DB69DUiVQz4NzRZ/gMrJBTxlinjzxwIsLktfFmlCZTI3UwMJ32NoQcrw8j70ZzKUloYYSFJSuR
GQRSYayKl3ocIh5SRikqyQNeVroZElZNCQ3m5mOQxElULB0jQkgkwippQXYEEVUKKrf+GsKkSQak
SYzL6GTWPCOOpwZ85RiQnW4NiE0kO0tjCiUF1paJXBPoRagx5Yq2sxEKYIqmlLGDlohyRbbMQnbh
YLlOUMesTwKFXAoSDc2UdMRn1gQpWGR1EIo0W20b14ejFGl0kyijcy5FcqmeyDLHJjGs4Heknehj
pCLsIxWYlMDXSrMczXCH+B/CQtFvaKEbQ966xfz+CjKydIejJcotpYEGVMoFdi32Rmjz8ZDgDGRN
2Vk9pkmUmWFOKGemvoXS3NFGNH+JmLY26/BhUfRbPwjBWu0PJp3svd2uPhcS5VEeWVJXCBafAmIe
cwyWjP8AEcLOAbsYGM6FjyK2yuBmZtYjlTI35HRGdO5T9GNtejKm5aE1WfoZs9SshZRV+ipUdLoY
LFnBbF0yjPszlpriFuGnhHG9CXRBKNciUqkf0XFHQTyTH+R4SgvYpfQWVFEsHRLSw8CI63LDOWt/
R4gQ+S8axJWJ8bE27mC9ydJ7IycoXcPx1By68ExcyZIXHZfvLRaRoHbYSJIQF9mV+QVVG7pndZKC
QzaTKYfHV/WPUWolqYy7YtQcxiVlFISqnwHBsTyzkUlGr05+AfwOGNDsohJyRibNfFiMvhZyJYNB
05JoeCi0TJWJq5GQs/BWxQyUWNm/BDejgaNmSCWRqCGXItOPlbLg2cifwSfCTROyUuBxxUZdBowx
hmyp8Ddf0L1WNgE39IbNoKtVHNYYGHNi19ifukObWGxjl2CXDlHGfIRjaKlcF+PTRvSlacwbsTOv
jwR8F/TJYWiY8i/QMly7F4MfJsjvLKqF1JKBI55HaR4Ks1gQtwLq6psgY0hh+hjx7wK4b4SXbFhY
92fQlabhItyI9QY6XIxDiQq8xHaQWecIkfsJgZTKMHCbYjU9x4SwRZaVoU9dkAtIe01yWJJhqmBo
CE/5aDzxEWzyhEcXZJJHrYUzkC0EHM/7PLrJpuHMxHZzNGkxEzQiixs2CTwErGI6rRDdNJTRquGt
qZe6Y1ryJfaN+4ujMnKEMeILcXKR2DobKstCMqq9pD9FlHhGoghhYxTHBC+g2foRJQunRZ+ZT8LO
ANUaQN3JZ5Y8v2UVw9HqoZbdxC2ReBVTXnbG3f4jOyryh1fGhhRyDYQIuPqYY2mhLV0aGnZBdsFC
cRVlWEicL/g9PkxHarIFg2VDB6ha5IqqvtGNT6Q9QodjWxpjMFnUL8MzZoV504GzrsS7kUVBJGkk
NLYe0Oxbr4EGTlpGDTZJQZwM2UvAjPBAoPw/hTLNZT21UxyOqDQZrzRwQZoZFwBJIpjq43KNUBwj
qL0NMOu+hSrUNkiVErLqjfSReBbIZTBvJQ3ySIm6OBCQlSQeMbOxXqwAUkWWuRko4SW41wLpyMGp
krGYmbZ2XHXTOHNFYJJNIq6QKKqVp0ibM7MVGDFL8i2kNWWEUnEwSTgkS1EZp0Sg5IW6ER8bKWfh
MDa7MNjzo0PkPaORqs6MIVMVhGZMXRlMyE6jD+F7MCFUOYZHnIvihULBajeCFnxwP4IcC/Dkufm/
D2IeyiXZ5KNMuQyE22qIeGBqxbh4OB1ByUwbySPIIlWcEv5P6IY8FBOcGbZE6YKZc+SyT8C1H0az
JoUkKK4qo014fF50Qz0SIQ8iNIdOYlYvhGHjqfsJUJMD0uhusvI5x7TJh52higSztUMQV9DHuWGN
ZW1GoMNbLP6HdhPA9K8gxS9DJmBWrXAayUy3scfgo4RnsILmUXRVLaFoEuQRGV9CF+UZo23GJDe2
Ik7Ylx/UCW/oxRhubcRtVhqL8T7IlHoKrg0MiWMjgF6V7gwIskw2kObPcpCQ9BVFVcjNgG5V3sU2
RMsf2G3oVh4DU4GXhYuSMqbPMDwNWTKWSXVkRBeehgK5lMVLiC6mIoNbTn+gRweymfBe8z2FM2Kb
jojohQyAm2BK9FNjm4ljw2mKtk+QR51ije4PrORhXc/CnMlJp/CGNkE8p8LV+DkJfgxqS0Mdk2io
83JkXyrO8KbCs+QvYVP/AEdLuCwma7auR9rdmTKmZvQm/QhzLy/Bp34D27/8BUHTNmq0GhArFgVQ
+hiNtY+Di1r5pD0dMUfRy/8AgxzhS08ifrZ/01hBnmL36OIJEIJI4qMtp35FfNkdC9pWGP4s7S6Q
3LRq8mP13RzEYiDvKA1ZsJaNHQrld02IXNG+xpfXuDKjpjJ912PdC7eRUndkQ0878DayT9DoQNax
a38poZrzKzyPArc8LgabRtr8Fh16G3xx/Rgj0jLJtUXZvNWBAg08dmV2VFQg67guuHhE9tkG7IWD
Ya5FULyc+CEOcDYskaQsj/fxaxEoNDc+DwPsYR7FnRGnkoqlENeRCND3ggPIexIhko3k9Bqi0YS8
mzRhseyGjbNMZB4Qq38I5Lhivg5abE/Jjkd6MvZ5GKdixRm8TS2VHDPOsjLRCrOAh4hwobFospME
zwJRcTWhBXgVHOjEMYtBkTTRLcB8jLUQ/fxpFqGexyaHlzKnngeckUy7E0zcE4R8A4tI2KaLFwbE
OW1wQvmsyxqSB/o9tu2aoDossCfbK6s4G56EXTbUUauEG9dj+qhmDQ7PYeGz4bP0gwHRiq/heJJw
hmUeX0IZnMKsGhbo1jk7J6Vk0o0zFnkmCI0ynUZQ9oYOacQPYhyPuY3rnWRbHzR+VtF/BrJNzTRW
hhjZq1ET0MVtjB14GeUSEomiukONVzkcU55FhpaLlgybiWQeqQtmHNYolK0cuiViBBOVzCMFJDNX
DGNMN0UleI7omNBn9QZgW6PioarVXkoUoiT47MdVcjaWs5LCrVB1CuCz/cC5VGyJBIx5HyG8KEUj
hRniuskEaqG9NAoQuOR2Eewi4ewsYLpR/dpIZW9QvLTfRN59EspwhOFcmP2CYeSmZe5rE/8AQxyb
+ExYwryyA43Zi00fwiUwnPgSUwsjhN3Im0uDF1KoQ5zKKNTyFdjK3rZHr4ySEPWbyNWZyyDO2xjg
RT9FkKxLJZFFiZs0gpGICTFHughhirk0sCmarUKCJiLdul2OqPJ3B/6Yvx4KU1URvF7MC3fYQ4wu
+R0m9iZG1Kr1PJcFTzm2KtC8ENtccB6Xd2x6YPQyhSKkNqZQj4guhRhe747sYhH3+ciZikJ2xA1x
mjQJSYTkqnHsJt0VD22PEVZNKDhCaArURD+TyuoYQqDTgOujW878bycfBvItCYLmTHxZwXwmRKL4
QchZY8SpTIRWMmQRLPxF2JjbKbFsosnJyOJ/Gx7GaKcFwb+E4xunWCFg8iVF8NfGzZwUgv0Gs1n+
g8p2Y+xN8j0MS0PoutdDOy8hCc1E1gc4TrbRzZkoZCxujis6+0Jr/DFBWFTDHWBDX3hyhk5PYuya
yFpMo9GYqyEo0T4tY2aG3TgkGDyEy+imYRHvtDLXfIxOzCX0EjQiWJSzTIC8ionrDfMVonyLsuJd
Y8vNMXKbeCtF9D6gVRk1B5Q/wTmW/LHNm6vgxT6MPB5RQyeB1NX5Eq0Q3FtowSZ/R4a9gZE1p8DT
s6J0vHKJ/wBArzIfCfmDnJKPTuDJKq4R+1QeXwfkciMjobEoQxHTGNkNXYl0TmG5Fpq6tiOmn5HV
p/piswtj2Y4IvzvCE+HXwP0h+jFtgXU7PkTFkYjw7hPYl10ZGp+Bhe8+R9mzmw2kKaLmC1pj5pSb
do8GaIGTwL7tEMjSXgyHZkjXswTyFet8i1DaWqFtxM+mxDnb7ULINehYlfYXSnARVUpwyOCJDbwn
Y2bExsXJ5ZYGXBMVhFJo9GwBD3HZcoFRiadlbaJsKdpi2zqiewa0qKiqkuWYTp9jJNuxYTtrkmyn
oZeKE0sZqGZOLus5sMriIpKU8/sGg1RRZjyzBn9HOZyZuZeQ4YKzZ96HtrbSuRXs20nyRq+hMxAv
Yj2NSZCrdengvz3MfJsnozTT8IaH37LfjMeB5n9GM3yR08+qPT6BTNnszg90JdF4YvXnbDGSDXK1
4K6Ry2zwwBMZMh3pke4MfprG9vQzTYEwkJ808oMrLTf5H9nAl0OiyxtvtsaksE0Pg/Q2u4279sNT
rRswyK1kyLFHoDJsjYs1Mn2mY5v+zz5I8vqxuJOKMIjbZbIS7H1LTXZhkWqLAZcDBJLZ+CYsfYLf
HgMjRGeQHZkxfgkIDOqGzYm1wXNX5FGF0EMGtkwNOid5GPQYUQ1T0H8WfFHnA02RwnxRkrMOTg0/
jRRrBsfsQjYo+ekVH+GnmkhdE3r0QyyIyTEa2IZzuq+x88OI0VMynBlP9BcchmYNkMTolG6xZ3ut
C2pXCFZCBt69DmyNwNFNvhsmCO/MjoqCWxkhT1UU6ajFP4xaXIrIqxFbntib2cgxiR8CdA/AwJtD
FfHYj/mi3AJK7VyPxkPx1C4mWxIlbzoY7ChsUroQ/wCEcZqvoSbOyHFVC2FjEbYhzVIxMnjLE5jd
wMYzRj0YGcgKoL1/wKqh9CtW+ygS/oWt4Rey0jurS6Gun4D2t2IbeZyjIaeh6aq4RlWsHTcJ4EtY
kkcV/wAjHB6Ep5H4FqH4UZ+AmTr6K3/Ix6UCJLkr+RXb+gm5DuS6FJbMTSGign2Nx/DjZkKXjIrD
D1fBw0vBvUWvlimFkzPIcOTC42W1Qww3Q1skxgbzdOCrOPQjLe+yjGfgJXGSqwWXr4Dpox4wM7XA
zUfiNiDJNOIs9HjIk4Vdn6cBPMvvImxSvo5DC+EEhg6bQmsGJoYcRRjYugr6+AjAx23gch/YY1j+
hBZYbuoKk+JjKidwNLNVbG2GWN8p0fAVTrwPaBAvCNigi2p5MOvkiro3Idw0DVKx/hV2Nwh7Rtl9
wTFz8L0ZmPsPoZqmK+zJC9yNbTScPBaV6QQYFyM34Qkv4DL0NeEsmcbL2XoXJo/0hLGxNKtZFMWm
QxjkHMnOn9Ckky6DOKekLOZrdFr1E4cqrI5Gk26mES2U0MwhQMTdjW9TSGu/m29i2ZBdpvpDHKfs
RCNjGvT0J7J5SKBTYg1pQMD+kSwT0ltrY7kximIIsTSnyfZ8IxBDjTMJF6HrsRHkTgtDD9iwytD3
sRTkfxwOl6ZwP4YkZDUNFvytC18J+PmPsTs/ULXkYsiWiCiR2LQwxeRX18hEo30IxRtBb458CIhA
b9IPB4oCXRDkqJSe6E1GOmGF0ISK0tBYabbGfYyYkyITOsG/ZBQPJSjbphC4E1dFsxJk6/glJIhG
HY1TyxTZrY6y8kiBsWscaeQ7MQWmxuWyzTqHBrEFh2ZGEEtChFUQ6XApLCE5EmdHGVwUGnGiqUMb
YPwY2UY9yZDBVPoalASmto8l6XCEbKjEFjZmKy9IlWPw0aCL6MDoqyuBxRbXRhhWiryMjECaGBVd
gsZr4QgVJJCeTYbEnOoLtHWKKiMaDDyGMGTVVG8mqbGGhhjkVBmYEKv6OYV/h7TgwtORxYHugeyn
AU39BSxYvweBLSVVhIbv6Ht/xOWl0Z7vzBqdbfg+tTBJ4VEM1zSwJamD2PSEsUc9FihJeTIAmM6X
Dagno3ePwYtU6g9Yq+Cw/UG/rNgJ9m7b2QxRJfodna+hifboRfNpqFprgmmJ4ErD8B8EMRFlsmVO
B12t4Fm7yRnE/Qgzw+jlfkVGd8DkH2g5PIghjPI/BeKkuhqMOi8iDi9jaUZ5pDcGKlb7LbgWYQke
ytj5FXYRC5H5N6VlBbYjyG7IP0ZX0mKe/wATKdIWERtTZBZ9jrSkypKhjZPsOZJOzPYvuorEMwqN
X2rgWlrnZCRNv0KPXB/WFZ8EmRKiZEFVPYH0ZJinQiDf6CIqaNg0gNwQi78og1aia4goJKxJz5hQ
adS0mh5rCEv/ACPx3pMLIngU0ZpeAQwinhMJiTbZopy6ukXzmyS4JQM14CaLDPoM+o5DakOOQyC+
sx9QdVWNkIFw4g1lg7JVJbER3dIorrFSFQLZ9SiSmshb9m3fggJpwYPHnUdzRMC3zulBAZNsit6M
fp209Nscvd0jawcYVUsERTVKNKObpoU4CyZVLTOzJKHJTn4TIuR7NsbWjCcmh5OdfLXA2Wkzs3gm
SFUnwyxlJn4binytF8luxDEpQbznQuDHBo8QaMRRYQmrEDoLbZY+eCAMjimA/qduyUnpC8Dr+oLa
bgaYWxQ1yClMswRFWYY5izGDN2S4G4jSnI3j4HmmhqNXqhTpolJ77h5muoTYksFkFxgVJykyo95Y
HL5KDwIVtocXnsRjY/0c2tjH1eB5HnsTJ2GKoNl6hxrTDWokPlvxBJRfZ68iC7TyJBFqUMWiomTw
5+Ikp4HLiYfFV5cDb0W/RPhycSLNxgK3JUM24nzkQYL2LjgkTswlzO0VFtNCaJB2ta2P96JPXoy/
SHfuPdQ2SUhCQapWx1SDiSinRcS6FVtbDbSMkdLk1uMH2hlf4PaOeAv5m4glcL6GRKPwK8E8dFdj
OmgV1oeN+BsHbIh5Ks+KLpi0wLEH81lYHoyzDSJKJrgcsF90J9CwotfCZMPhi4CTx8tzWm/BBvax
HCnGRBLEuR4JocOmTA9peDMGRticUrQiyVY1okKbI8Q5r4zlvYNJI1D2mKm4XivRhjBk5KYJpU3R
M4W0H+WAipbyEHLeX0PLKl0wNjAl0hlM5hHbgLV7yM3yX/yQ3kVHKWYGKZbyPXrkaY2NQ7INkdHF
wNUUCtrg7F2bzJp+TUEzESsVsZZoVsDW0QrhFU57EtSeUFWI8MlDyysBGn0Jm7EhxXoyb3/kPbaD
/wCjY3bpZYpFxtWmV7N8jYsYvlvljRqaGVlcTYz1UlFcjqz7AiNFKCxZgcDnca3pxeKgk6ZRX1Sy
vIt2R0yRgIjXKEdMQoniDOsMLoWMh5fZUaOoYnVNg7G4yQzYS6EEhmiafYgahFHf5ChgWL+GSK1G
oFRpK+Q3q87DNzAUrec+NwdUsNLKC/8AJWuBHfwMZb8qY+xIG4XnZ2Hn2JQb0bm1MmN5Hn4gzgTK
P4ZILRTgwXGvi34pBD+II9CJDjacOdlzoZPDMryNZKKlCtgphlpTHX+okuEcTXBA1bNHOYSZXIhx
wCPZGHFu0TIZzgeiu2Q5h8jSs9HRq12YHYWoevhyGaPU+EQUECeBtF5H9TDJRKexUVnBlRgy5TBm
NOjFR1akz0PuMsxv1jG3vgpDwhnzDUiUfQlj0eGixWxsZgQecZNKEyc+FIpisDwbst2PdAlMZwZe
p8YdbyX5kuNvPI50XVXBNm0fmGI+QR+qOM4MWjiozifmF13FF2Qosqi5PBzCmIkeRtJJs8LByb07
wPppGNZXBEHoV94J3Ia0GOVdqNGUxJLQ4m3dYLBbNC8fGTB2feN/B0eSallDGRcEkZnyJqZ/18fy
Mp/IWx7Hm8s8jW0Zossug8mQ/uTIYt0NDlOBwFKwNn47GBd/CX5jM12r4mHZ4GR9oYxslVspvvyW
nByOwxR7eRiALqXYhRqDvPAnNhA4OQtm2hznAkJRQ0rlgfVHxYP9YId+Vv8ABq2k2OR5JIVSHeYO
HGZKxJdmFLsJHlO5l/5FEVsV3qFDanHGJRrAwvH/AAOGK02h2pryhnoVeWeBiEOSTWvw4ohPZFlK
JGbvT6HgDbVKPazPJYLDQsllQ3DKEjcsv4SKmAQEsbIUaaeGBUIlguDmgTEUq8IZlq4cfBHRybFs
0qNhKNjVmD2Ct8walMokMFy5DVOxKMz4GxaNfDUIRKdt6FCXBLzCOwSU5DmOCwm2QqJ/TNeAiunl
fZZVbRcmc2tt4bHafKF6U23LHqof4GgPCx/hxhPRDgj0FtkQRDk3GXYqQMRDbRkXD+NFFudRj1WH
4BDFbEElBQpROJqMcyFaPBGej6B/weBpCZOSDbHw2x4FKMJsTybOCEnxPimx2ePnf/4QzDT5wRYP
QxCFY3THbynk53DP0I1wxC1FUDzSOC1rjJTAVtawNVzot1sq1CpWjLlwg76sRQV34plSYk2OyWWs
FhtjWz8XC0P+G9I0YHZkbLkWAmNKT5GeeBd11ZRT2hEYZO1ClorSsccKGfng4FphrwIdaJDpZ5FX
xLVMlLQyXsPoMnNJRDUqMdWfLGrw5iG1Wt0ycn0ZuCUaMyaaZnJaLqaGCqN1jBSIsPHZjsPnnnBF
6Xodlk5QlqPgjGFeyDaCiTWBheU1sb7M7KCTevwNmK2aKLolDCXrQ2yfhDCqbCENAxk5GMUBOQN9
zP0TVFMbNIOciTalgcOXORSYrjrRSTuzYtKuB8aPLo/DCy6JvU/Z/eoKDZITLxPpMi3N1/BNfIjQ
qwLUGkuyzBfZkSDxFYPNfYi4LA96PInOfsw8OkLTV+BbpR67OyDBNGH6c0KxJpyzeJkwIfKWa9C/
0sLfuGtKQunIsEY5ujGTQTT0KwsEvHLOULim+Q4WULh0dF3ywPXJH4OCmvRG22wYFws+BHaJmr/w
arHY2JB6HY0rD8kIXYdFYaqLGR/9EqbSyiE6FDmr4CvvFAt1RueBTA6gzKJazsclwKyoXvkSxOv0
fLs9ORyG/wAjJU/oSWn6Fwp3lgqPLaMQypYHoe5YnIx2fAmhddhzPu56Kpo6mQlYnLekI5pxoka1
2IaC5k+qq3OyNMrTSMDew7G7JhjsSzBGssCiw7DjpWEwoN7/AESNCX/iFzwV0JEOSN8GMSy3mOaC
ZLjgX0YXgT36Ri7BOB6wR/2xMcRyH5tgTRbhU7NO3e0UEUp0LDnioNRia1Uz/RxUqu5n3bLkgN6D
2XgeRglaROCxU3ncGIoQQWj0MTFfP4IfaRqxC4y6+WyehHiUWI9xkWBQnAX1BNU5rj4IJ3jZG9lb
TGSPI0JGhlIQzvINfssY1rpwmqJQ9uwpwdJLSEBpMpsnQm9FluxsNFB5+NEe5gTUGvwVY8Q0FhfF
j0JYyaGWz8/C38KNgxCZMbFsaEUUe/nBt0aL2ZbE4Wj6DA+lIBjBM3A3pakvfx1GXvtCnQaJ6Pz0
KlAbuT4ZkyBgoLNUf50FrKh/owwjmx9Y2KiNiQeRpYNogwGmLehYDTE2GRrboE9nPkr/AOgz2yLr
4mmalXses4N8C9iBy/NFmZEEiBtr7yYgrIeF5MrW/ZZR18DbV4IPLoP+FPgexp2hHuP6ZEoKmt0x
cf5BNlP8HVjDh4vDJcl9sYVP0yi2MXhOkKbJk3gFNReiEf8ARnNtkhGdGtNNoradEWCS4ZZsDcIe
WT9jVO/QUNt+Fzmf+L6MTu9GuZHeljIe9QYpZyepMe8NQBjeuAgmfiGWsFtvzIyZnENkCkeCZ4Bl
KJ5H03bXY5NRxYRNiqY+iEzDuxo3lX1J7b2j6JTP90xkddR32LwfNFf+Ej4BgLafAvbPOizLfAzd
YovoGPKUTKAP2Goj+jYnqb8C/DdJk8Q+zfD8sQ2eCO9QpjfQUTXPJWv7W0baJyyaX9hZXdMNgle1
0T0/Q4XO2LuJlOmLC1+z8HWxY0LTDwDq1flnXNhEMAzkSJ1twp+8Mcj+Bk+mNkP2KlDSQ+yt2tt5
NO6RRAT35SIIg2a1yoPS2XrsVImKYvM2KdBDdKcio+lTXa7FWtsdXKZWp9Egv3D9OxWsCdCgqHOx
5G+pYT+0K8HkVfYjU1gbl/xieuuB40LYNq2XGEgJ8JGVQJ+Bshm2W1vU0V3X0KXZuRUlqSDz+Vfg
wo5JodsODLyYsMP6Lm8m13JZ8yNBT8OAezFFaGzktsFl75Lhc5Y+o5UEFiUfwpsOxnHPxLMbOTqa
HseCnr4aokZcjhGz7Hothv45OSYGjZSYNP8A/Gi6G0bJ8YIzPHxTYwDjyMsv4X3eTITk2NFRIitR
gVXyjMnIdkP0TTWLwXq/gS5lFYzYLL0SyG3NFhs0iccSlXlgc9DwPOD4Op+BqiVjgRILmGzRgLWY
lfiCNVmmpIQmiFNaKF5wUZzdH+G5pRe0LRgap34L2OF0KiVLNlA+iafhDH8O0ReM34MaSHF5oy1f
sTxEfoYXEV2KEohlI3gmmXod1DjS+4Ia0IPIIj/EJvwahdsWipgLXEmKgv5Ekt7mUwoj4XOCCipQ
a8R+idrjgfJ3TGtpsOtqv0IbBqSROGppkYYTRYK+0MSc9DzgSI8JPlmOlqiHVbfgSv8AAekt6OPT
hccCtv8AgPCYkXROxWNrPKFjXQKVIjEjKovKFgrlO5EYWjEh88mGOUQ3LBvlXk0qYhAy914RnGRe
2I/7oi4bPychmzaeHgYaENGaE+oWXlmAE5GSOJijDNl2GHs1FHcJmJ5KpcmIU8NK6FPG+RtXJjJS
XyN+no7n6Kt/Y1cYe0vwJVNBgWoj4jiRvyMMmvAfhX9Me1uNc2IatyQY5nITVBehJRzk6Q+wDPFq
iEzoFvWSFKJawojJGx4OfgrMH8L7E73hjzWCKs6T5ZgRF0iIy5BvXhQgXUKivIc5/wBSuXZMOeuv
QQsaKotHFYySSMsnNdj/AOzM0ZwntB6sfBTgSZPLEIC85vQpwG4tJfaBHFDtv+jOt9PAZeKYlocx
xWNj4tZxBvJkjF7F2GBeSHEMFMg2CwYVChDyRaLD2ItY2yhN9CZehPGRfD2aMF8VA0YnkdGTY2UE
NQtexv7N/C3BvBMkFk0UucD8lLRr418bNspcHQt5Of8A8Ujo4HE+R6G46H7MTb+BwAGKE2DwbsA3
4PM0m0VEnIluJNBtoyf4DbPLaICBIcTJ3Qu6lQZo11Fz2ll8lPWPkYsbD3yMG6UqIC2WFaRJvJUM
LYV7nBcCow4D1htvjiJESwSAWCZ3AUjGhdqISsU0GsuiaTRJCaohnBQZdPgdXW6sirAtXLIpNQmw
QZ2IW2PxqyDGcvAw650NuwZJLuIOirrngTNFQioyMkQIuuglyZHCpGDMjXRwsWUM4ioW3BF7TGxt
MaE0tpvPQuLTJlsMiiMXH4Breo+EeMajQm+DLSorOEjyuy2NIaN+xE9mZTeC4LAlckqYkNJS5pRx
ll9gM+9zB/YnjV/fhEXRqZ5O9SEhZWCIDnq2JY8LA5PWXjwYNq+B3G/ohh2kelkuEJPLaJyr6Q10
zLSoiTVfZQTu+oaLZFtUYyCSnIpgYDcaDWysjrQzVomspBl4qFyo/JpUIwnqYZEieCIQuM6giibQ
RNSRyYd7CL32gyFS+hURlmnZn4D2v2Q5KgLHV0EfiHBx1ReRahGE8JLzgckJPI1fE6GK+QPOiC1T
jLkwiRdcmSWpvGjBFInMayKzXQGB5YpmgQUrWEOSkiNJp4QTk4Yf9IqKPsZftxWjwlBkKKil61sg
nxJRYL+f9D2CtdFeehr3TagqXezVE8nci8j0S3DMIs8mvPgUrDxUuh75lZQ/+G4GQVXh9UT6hRlz
8Njdgxi4lfhUd2Hgu/q/4FSsxk4hr4SpgG8CzsdCtjXkbMWC8j4yKlDfwbMmjRTJQR4GGuDDHw0R
fgdfCfNQ2uBsWR5CMseRNQZoaZcipm/HEMEPJyJGQvRTZwUuhrPxDkXk4/8A2sc8GmFDPNsbcm2N
xHGPx8SXAIb9wWdFyzPi30OJHc8x2yKYKa3qZIiYgGwGUeZ8MENa1BbCK9lLrUMhuWroWV5OYnwj
6MjD4MeRGyXge68DdFILm1lQqD0xdmWPBI+hJwIx4BMXgK+ZGbrjGqsrguBrVgogWk3+K6wibFV8
mgj0pQasC9OsWmaPGS2FbRbo8+Qtlt5ohSRanHJEBvpmpPsTkmha+UQ7KFYGpRsc3f8ADIoqNGVP
wWs0Fax2G2J5CHvY2zqrgx24ODmC6pmMU4cCUZI6yJoa/tFneeUGPLRk6ecDlnngXUzyW2jHeMG0
Rr+SV4+w/wCEg0meeBkLyf2mHmZnRODs5Bs5upUek5SM1RjOj6B6t0JQ9tPXxDRFz8L1CkUnkrIj
oRlaCe+lKT0ifJCGznZerQpmhMUDTwNgmsCfiLLYbiSGZdmPUiTwPUugh1W2BBj2m5NmT99Bmyb5
H0ORikw2Ycoy6ZYr1nhqUCI5GSpnQ9Ar4yvwF6uYdV1Cntmcecg9S5RikN3gNE9Yb4F3NVaEa4c8
jopwE39jAKWdjf8AwOHKuX2Y+xmsnj+iEFoHERpgYcBTuToib1GLhpTGJcQ44lpbNPkMdqkU8UMS
bD2+xk68Jf4DTEElsaVcCaXsq7GjMbFstn3F0L/6Dr0OoeDdgeNENzlHR/uX/C1tyUFI0nf8FJM7
dMHDERTYbb9ETGHwIwML+np8MjZkmzTpkO/OymwzGwJWT4wQ5/8AwFsgzgvxmjf18xitLkRpjonk
WRiG8CwX5Z0NZNMjgT+Z8MWT8NYQ3ZvQSx/oqIQhMC3od21GhOMeXknGpoQuoOUDB2UjE9ZJmh0O
XlgjM5cF6YghQrzORSbw2NxgdFO9jIkuWhLfxx8K2WoSVIiKMQncDYQ8Z/8AY5k6HzBWNvvOGR3V
0OSjg1stWM5r434KakPYyzcdebUdYyN4hsMZdcD4eUKrxsxjWPI8DHtiJ6HZjokXBq1HviOY6djJ
DBFyPIagFwElLSjwmJxsZoonjJRNCVccWeytvSEYXgjfEFccw1EZTihdUCxpg+Qy0N5NsMsTYhq0
RVOhr2mjthXQyTgfXjNuDHiSh+QjglNujAonCtTg6Ce2M46WRZl5eRDxc4MRNUYzSU8tQMOwyYop
XdnToXexWBZhpJIxFLyLVYKKTvsQsQD1oOWSGeMEIpLWBXP1Gkao0VUUrbE1yl7ErNCEn2Tb2wq1
/wDqNY8tITVwyQoy0VPdII5MnIpFEuIJ4wiZlbnuw5HMbPJ8Et9UhAatBqzOoSjDtolexVC/0HXG
xumYKH4pD6FBFTDA3MoMrKuCrKvsLq/+I3AlN6L1rDLtmips1uRJq8g/ezh0MWKDVYjkIohdVJoh
vPNqZpK8vko9WIxtiUkjENYuzECaAwSTjKtSHlPGrrHk1pIhhUfB+B4ZSNE22wvAbMtFRpWi9F5o
ActLDJDImdmTTsxylVlfYwmSy4PlqYmmN262cDas003wNkk8jFM9F0LENYGZRcDUE8DD8BiNmPjR
z8NNjd+LkxyX44KTJDKXwxqHkrH/AEdG9DfwyglHj4GozASkEOkXKIYh5NC18PKESjdC+OTXwmPQ
sjXy2JV/FnxtnjXxni4hG/MKMWyNAltrdQxJ/YyuiD8si7iDbnA5KizlaX92NDgjZ+xAKaTyXeME
YtB6HBCt3URzoqQpmMHFt5fwfJ3S5H8WwyckLkWeMjTArmnUhGx+xMi+hnWBtkvvRqZ1Yg1zw9pj
GlucCiQNveY1ANR5MHpTVLDGPRAnG0xuo8CnNnY95hiyqCNc3iEd/lFCDx2PDvpMacYFRfqM5AYr
IujjdNqiEfyRQJXaZvlT7L4TN+ikVWOyBrKLlX2UTb9liZeIQyjySb9QsmkR0hK7XyRhwPX4IVat
gxqaQoGv2UzyOi/L3Ro4Rz6uYyCaN9NmTE8sfF9iUinTtIwM+mxeL0GRMUwlyb9j1KMSk20dooSm
34Kmp9Ddt5bHiIm2H0i0vAv0UuGMbezIIpTFqUSci0kN6aYzMUE2hdTuPsUVSbPKQBM/qhllx2Te
H7FNBMxU2d4Jin2M8N7O0ChtqPxsBGbRvyQSB8cqEWE0w0VdElwxbQhjbbbPorjkfK6i46HLkwvo
2he1ccUjXehSRaZbH2AJrfLZReokt1CQdJeBbX7qFM88A6X11sbTso8J8haUA74D6EkHlBzLZulj
UpycYHuKCKe8Deh+FxRkBs/w/YzfhC6cMVHi72yGLOdcD81d44GRbc0x8tt2KoXuCf2mDHwvKQdF
2WK6+hoeky3gjCcMhEsjPkbPBNjY1G0vMIe85scRc1WhSOyGPE51K8FiEHR6L3p4exFg53adjLJM
lilcMW3wyskFSfaFakn0y+CR3ez/AGOIpdA3YejbOBCnI8MifwxZJkvgsG/jQ2SGn8PRmNGrIXBT
In2THw2U5+K6Tko8srRticHwGkbOe/jSOimiwRfhVmkIuBM/w3nUHoYvhIjNnAlTPwskGqyRv/yK
aIYKWvRlku/icuguDQtC/YxB2S/YK3mAlGxwjEqR9lsT+xQ85xXSFAhng8H8KUcngy93tl4CZyb/
AA4K+EKyVmslolDbJ646ELaPTGs9gOZ8P4KMgXwxvxgQ12mR1XfYs4aVr7BbNDzwGYG7UEtvN5GY
N/Y/I23aEMG/JmNfljZDIzJ9BPOnsyFpqFpD7Lxsn4pnC55Ih4faNNMDrN9hW7RJzT8GddDbIWLA
xbJiL8WPJg0qhPA/EMhTfs9p8Ykjbkl0ZMNcUUFGSxy7IFgh9VGi/LgaMmcFGuRim7jmiq5G9CYl
hNo9A1q76F2/YjkfWNG+vCDhsnfQrAo8uirySBDEuqxyhfYyjgVcIcFghWMqYkmoYmI4YlZyYja1
DF1rQ2ajVQJzdXxo4Ui2D3KJPsRpJjO0xeEsbqhtq1hpBWygMlSO7bWMdjFzhD1ROuETG2EKUJ0J
YA8FVff0W9X6FACi10oymVeB8/gM+j6RlSL6LyE8EFZY0cGe4O0fA541lDdOcGUxuWi1XvVF2eZF
Rp0atCd/CTBQwtl3Jbw0fYQmdiFsvKLGVj86Q+7gRvBhsnIcwxQp6YGx0kbYGMMmITODmmUp4+HF
pGLvRXoe4iQR6MaZU3SNvrIYiQpZIryMmYiJZIf8HidDfRlocRg8loiZH+DkkY3SGwxa/gvZPJRM
4D2USfHgtKtfEqEQwaLQw0mjAxPsRX9CWTgwvw8iCL4RoevlCcjYtfF+G2Jw2yfF0PkQuTQnv4RC
IEoTJmCFZIJr4lVxwnFsk8/kZ8KifqchUbIv4Xt1o2IzYSFNxZVFFYMrYJMRYJXh9kRoHFhBrqfC
qbVBko0JhiZvw1kYho0ohYPAQhSeDUC+h0qefRpTO6GkWwi4pURpdlwaYoxAQ44jhGBgokksEjV5
KVKCUBvan9FHX8FO4flR5M7wW0G7BR8ceDNpnDMTngh61wGNxWVyHhtxZRtlt57GlDEdQqKLAkpN
rAxm3wKG2qT8Cc4EcG0wTHPe8IayI1Rwofgv32DxojMkQ9mdIa7QxK/wJAq+hOXz0dY+h2YUNiso
RGTMxkWkyIctZlittMZLF5A1oJuU403xB13EOxRVSmn2JKOgnGmsYQhSXPAzIJHiyFSH2jcxz89F
g9tDq1kdZH9DDDwyDTXoTHbkzCl4ElOPQ2wyxZYST8Gy9rjjBlM5FaeDeBr4ZwDx2hzSDnIQ0iQz
bUjFC0a1BnEnFomxLwxGS+nxAkY40/SUa0bOQylZphoTSk0Mx+18bgkEy2tGNzo0eeGbWxiarMpD
HMEZxMiTY2tDjceh4Fq4Ymh8Wj8DAn1B3/wObFNH+2Bk4zSLCSQkWP0RZ4rwQs9IkiYEkt7hMT6e
Rd1jgGiM0xd5wiuK9eREqpQxQiDyUZ8Lg44qk40NITt2dCCinmofVpI8guka5R1UxTYwxtG8CKmu
uQbBwEOKDPiORDLbaCh46xT7AHiScSMHCN5hkFNGpoV06NY2hEXghyYpgJPimX8UuTA9kLPgkcDw
JZ+C5GVQ8mjfAtUXfxr4rwuPjwaG85GIio8a+F0cmhieUjYjRsbPySkEUas+ETIyYIRGDRaQnzwQ
mfj7KvgeR3s4B8Xk2FWhGjNUK/SA6p6eMDHurU5eTJZkQ/IwuDoMUaKO9QIW/CIxSeRMkF0FM5Yy
La154DaLLQbSWTZr4rF8LCyPWC/CpkZVGWRLI+LqoZ4h4hMlHIYsMsKpDUBqS0GfB0UF20LTPhfI
TZLstiE9kIEQHVBCW9sr5wIqZGrKz2HMLfQy0Sl0t22xcq6IVgW9iMmRlFKDBW0nxQSsJEMUuhSp
zSipoTaQuKj4EvTWUH1ptvoWvSpljwis4EInUIBkxs0kVfGyowI7tti4j3wSThsSlv8Ao9KNdjky
RelbV4GBYNYlnjTrQkgxSvhjJWA5NOHEeRwdjPA3Rpmae1HfsTT5FZO2YM5h8qo6yIKM9smH9Bj5
K6GhSnSI4fQp/SQvp++C+eQTjaM4LTY+G4lpTKBZxR8fjEPKG0CbbQ9z8RHUZYFvUwdROWSeh+eR
WRIw9s8O1C82nhIVrTmPo18IJfoDHhZR1j1abI4fI0bD6EhE+DQiMKfAwuqssRXFWR+DCAjoOMgK
wGFFGgiqOwSTMu+jgwcHlIN0WzNeBmoxEiDoXePiYiAN4vs8gNhPbUzIVPOU0ItzWeCmYs1CEOlz
KhvlnEaQ9pU5T5Jw6SQhqL9hzyRtM3oXqCNEivWZxln5gle02RNTY8kOo7EqJxUoweXSkZIL0GEY
qmW/IQzleGUY1SbRpzbREnQiiW4PZnpkyrseGLr4hCFpNDOfjMX5Xw02zkdKbQ6vitIQYlI0WCm2
LGQ3BulNifE5G4ZNDRhGxF+NmxOIbjKkPIxLswU38tsci7IZ+UNT4pkr/wDi/EEkJ5MhmUUosmhs
sX1Cf6KY5aZMNzk2OngMBZJeDN6lHzClCAni8CP0qIUV8i1Paol3saj4gxS9H/B1BukM8G5KJQkM
GjAjlGFlkWF4KaHglot+pqFsTllsQ24dEeB+tAxNZh0YYKx2U14uSMN0bOVIy8p7rg0pcn/93BFx
RBiLFZD2SRFcExWtjAZbMLHlDkzysWpKYKblD6dkWL1yJGNvgSldFvzSo10PSm0JdUWwQ5NMVTsq
JA8sJU1/8Qy+oMbLR4glqM8kHlF8QkvlYLw7SNYERh4RiQ30xVKz0M5M6YPuC/5MYJzu4ISlwSYi
rsMZtsQA8qXa4lyRk0PJLDGf/Dkf7zxCwTMcdZoXV0QakJvontSaFqxieLEsbTNUCavD498AfSAE
LaIg2/RFOQy90yfVX+i2WlkbHm14orkq1jAwbiPYlL4ERBKKysrMK6136JYJc0TNooiJkXLGnfGF
reHUKjjyoLTSmYCzxPYzcSvHJXci+xCYyjILekQBCxUHIFtjskchmDKZC9IhpnAK018DHePI7t4u
ejY72P8A0UbMvc/wbYAjcuRwcfkVsplJIyHOmIWxTduhjksIUOwjvBVPMao4jAo+FplZ9gztsM14
LSgkvwDohdqHBYU9jbF4Qu3Jiz0hg3Mkh3ey2j+WXojlWha9nlDKkc6tnOSsW2JROdCqTGVJaopO
UxDBMs+haXTcbYngxClyJUSCVD1jJEbFBE0OQyQ6a+dM4MvhEVKjBEZBvA8MpsJyJ9DGBvB/QneB
0yNGXHy2YOBDSLwaFnJdiyYpMMgxYY/jQ0IuSoZcnA9mGfnRSLL7JDaF214OFHhYG7+PBkL6gYgS
tShpNweeuIlBCRlneDQzQVvXqDE/YPjcplTIgbhmlXPvEtFwZbHyP/UNxuR8mJWOBr8+C+Hl01GL
gL0XEQivGBIS8DCQg1DYjc1DY4TNQlExkLwxJtEWE5QW/e58EcU2yne4reIeEBKPTf0xDeWVUcUB
mrfI2rNjORrXwX+UaRGRJFQ4g0xpZINLINAo4si0ibrGtpkqHB8V0y14FbJgz6r7G3AVW6Cky0iH
hvofXMcjjZMu8QKo7Bw+RhIW7G0xIeUx0fkcEfQn7wJVaZXmyo2noiYNPBLJpplkSgjugjvDS5G1
lLpmut4Na6M6YDI49iH6mrgeEb1gnUcrJnJNPhiJqWRwwsI7IsowqvQsK6qaB/02hH2b5nx3YMze
TOVJcIZ6Hh6LMm1ZC0bJZH6wmxxlZs148iEzSQYG5PiWilzouuFh0fryAa11SNIlUswc2UfTFTR5
zMNLTzsI7VN6F5yTXJYe3sSfdbZW2xZpsaYMyoZzUyQkiuvOBDL3IgmtPoQTmPoU6HoRUbnNK+xl
FtnSuZlETOxB47Yk35MapwR/SMBdMTIFyQ0VXyMwZ1sWcQrW2JxyItl406N8IILzJUUmasKwTpXs
9ZjhdZ4J2ZQPUdusiOucqMzLwRXmK2KbJDvKKSmJSWB8Udg6Gk+Z4QlToRLEI7k2TaFe3RVnBdef
BIuzZZHrn8iPgESiCOkuB+v+pns44IYG/gzs/okM/Gn8LPhdjUf/AOIaHNH8GoTBkJicY9s0ylob
M6E4zIvAxLlCRGzNHli4FGyNCWTIwPIxyYHJP0lXwzaEh/DGmjTEbGnfhIYvlojEq7waamUQxWOT
RllN+hMzLysD2ijrQoKtOmLKjhlqc+jEle+hKn8irLJ+zML9BkeVltuyhwHRNkhOh5cjlV0jfZJv
5Brryxio2n8WmLC+Kx6Fg2xlaMpUY7u6cEZHhwJTJnhj3PsfhYwye6C/RWLC4EGkkGsWV8F95USI
eBoZkyjXbdHtbyQ8Sf3scCbaY9pS7BW1eEVbee/i7efsUKX0ni0VRyEAumDpGUz5IktEZPLyhjhX
ocmbHurmtCYf5L0+heTUHpJGyxGCKg3SMflD9tDgYx7Bz66Q1izh1FvpYXBv2Q9uM3lHwTiHT0Jo
Bq6zsWmxRzBfQ3JFPk5HD+CXdGjafHYg2XlEugxlM0uov5wqL123BzRdWFhND0OuL/gwB5Q2E15N
eRKo9imT8kJPlshnCJ01Ka7ZrOXTHD2Vg8zkV25KuUyhIkw8h0vfJVz8gur2gMbaeUVKR2LCpWnD
Mr9UXkmw5lHMswv9DUTpBLsqOmUTFrVs3B7pfkUL/QSn/cVs/RVDoisUk+TaH/oj/AYZ4eh3lfev
hGD+ftRDXh/BDjO3kJrV6XxC5hR2IlG1hhrF6MlBfBPxjfEJ11u+RRSbPv8A1NtrhkCY59j9ZbNT
wLYV3lBGPg3QJyUkLpGV3Y2OISX2NgRSSUuiql0x+mCGlY/kvcl7E2U4bDS8LNiDu3bHIlGVHYxW
h+EPvpGTQhcIY57oOVn2KMr2mKp1Rsbtb38Nvg6YxZQl9HBwLApKMTwbIJh0sEl8Cyi/Lg3Dgfg0
zbINFYlkexYohtex5EoaZrJnYmQlz8LIXXwUMo30bIZhwaMr4hsRyW8DL/8Ahu5OReSU5+X8NlDb
omHozWMoyp3BuiwYfEpJE/ZO2TgZWbwFlE5BrWorVTkjQ9SdPsrOm+y6aYXOG0uBK2uxW6okMCsd
jG8AyJMlpZEEonwNOitMvhKclWhkIVOjoftjvGMbiOYtQuaEpHZauBsmntCJWuBU8EMZxrcHtNqP
ZGHifoM3OOsv4JJqZGJbDseSM15Gx/Ea03HUkHortjAvNBzU9/GQJnDQuAy9NdEPsMD+yKpxWUmk
XpDxcT/wGPDReujDNdkEVu2/AhvGeB7bvIik+4UqtG5CGKiG6YUlVMjUW24LFtwQ54xZwYhywxvf
wMcAxeqk4JS8/MOEkTTNCzC/hUtIsoZZrkhRhCFKcEm4G0HlB6eRdKuRUzlCI4hkrmjmhLDUP3GH
byJfTIyiu6XgpYwQ7m4LGB9JCjeLCwrEIeNisEpirXaPDCBuVR8hX/GNp58i2xuVBhanjDSNaEvA
9OQbEg5e5J3DQzzH0Z5HoMRY3xCnJfY0hvHAz17xi4YkGO8GDBxdYJ6YTi9AdI6eNvJGP2DbsjnK
M0FzoaoyaZkg2uxm9Z4Shn192xIUex8j4zyJnZCamnhwKUdSwKi7a2xBLTmKNRlHI9BqZG1GsGVg
5Hl+BxoS7CWTPwpv4c7wNKlhyYMziwHgGmJqDamqbXwyxkJUg0PCnyohtIbpwaTEhUpjZt5GsEwV
TQeS1CwLGOkpClbYtnpELGzSFlk8lUOSmx7FhmDqNjwym38ILHwWBPBcjoSbGIXkZYEuSj0OlN/K
wZMg/h4KdmXgSIaeSbj5sCYtj9THUQ7vAb9IuTEmcCwl6NIQyZLC5EFSaZqAaMByK08DEA2tGhi1
BBxhdDFISvksEky0QAQMXswNmyQgc2bbPyTTkTaQsYItRhTBzQpw8DG5aYarYtmkyXJJt4CJoxZg
hiJwxuFVgM4kbbTFpLQPOdCT6UF8ycE0Si1KMpRGCTybsE6+UhearsuVWdMWpLd8j4yzDKWEabOE
x6MxfZdnx7jIMuEbBbKiEIivQv0yUGkMCmZDB0RFY5Ie9kUJ2D9hjObZlj7DwjaHROyGiaDUn8iU
mgtuDQt1rK5EstT9HHYuunJKuWFK18JCl/uMWIfPwIPREIZocLIhmvQqjgdSmg8ZLKcTLY8a34PC
BHPboZGF6OZ/BYKfoZB4g/RKZJ3hod7bb5D5dsUjLXC1H4o7RroaEjs8hLMlSQ0czScizHVxPQ3F
FZEHc2FeUeTFIVYgV/Sg3v8AmIZfVoQSr8qHnk+BxA1ioW7K7t7EmjoSiip1Csdhk84pO2pWkBzf
W1ZOUZREtJRYkh4FVE2KOOcMS4O7wILmXwSCSZIliMRGuxFdL46Gwc2PY3yV5Fm6JCbLtGXRgGZc
eExDCqkzA0IcbcF8Nfip04PBPsbxPhRjxifwao1IFhjHHwLsZNico9m/ieSqFGvhpQi+BNULGvhs
pyX4pk2JCw2GxsdHV6Jn4LCEhB4WyoeiQvRyHsgsMaY20YGjY4+Fx8Nn4TAixENJ8Ki0Ib0bfGUv
jK+H8QsG8/DHGhp8nPAguxq50JWK1eyXJJ8hqCbUGJZGxK76ELSWBzpvgzzkOfwZJ4GvnykIap/C
J6hqbo0UaWqIWIjOBMjySEz8c/CG2c5EkmIbltfAStQPGE80SLEEofovNFgXa4YQqpMHEqxk+Ocj
yWGh7Uxkh8vCjy8mKChbehbnSFOtBdqgsLU1NvodLJjDwLREmiNRXC0DkxIkOjBgC22QlHw+gJl1
GNRR2EaqaEtU1PA9yMR3JaKag0bLEgguuZUZFBKRXkrMlVNjpDdNGqcHuJFom8ilow+S9mBLGjFf
+kK38RiWki/kaFWQz2hVhLVJxExIN5/6LQxl2xyXGNoUuOmCICmAtGgQtwjMNE4hUNO0VRJVTFMm
I9EHIJPgMvKCdtTMvsdszRcfS+GjNH9coal/6Zf/AHYMkpLSZwBfi7BSy0Ns+mCcOjhGc5HncY0a
YXcLBPVvCrgrk4W0R8aiGqO9Z+hfvW4zEnqlNGZ8x7Yw6dUPXihkw0G8ZJQgh2dIqEsdidI7hKrq
ZMEaOw8VONc2iGPuNcuUaRkKb2R8jJLkwNBsL5BIGZPBBCvCWjpV9TGuoa9CyUHmPhPAaITA2gkL
wJQnwePh+RKiXz8MJPsWPhG2NEiMvjSlManyVEGNlhsTBMohRqlJR5CRDNCNihZosPhWBomTQgqo
xkbEuzgecDgwVMX4ejY06Jw5KuBhaH9CiwZHRzDTEy/B/NyLY2PL+EmzRsnx/AlTTPQmGGehL6GS
XwFXgWOxgUtdGfLTFNbQ+mhwi9FSeBzdZGNQ0ajGcGFPvpMxWlrvA9pnYQthKDATbQ1pM/DYc+Ms
paIMXI872S/uggjS5HxLHYCxDKEuSneEIbj5oa9ZzComWbjiGNXgdbyEkVu1omNpgYYx0ORdzLzO
FAKWfgrFjIuSpBe3BrNwGOXIiqtMguhoVrJl0IwtyAECMe2zBtMdSEFJgvtIQI8PY8kjSEMlrH+U
wOEUC8tjUxp1mXJ/p48Qi80yNNWGX4otRzwRhV2jbSRck24pO8A7FafoqbjKCyPoh7p3wNDEdjsr
wVKWTLCpmjZ/AtI222LkaPryNpE8HI1scu9lJ3HZoeXHVT2IZ4VjN9qNMelMboxGwJGLXY+ymnsS
iS6Qybq0+OrGoRw2aF6onpnXStdlUM8McxZuMcC2llJIND2LOTPgXg5RBv3JVroOC1xgRoF4RMmp
59DL8DbEYY3PMI1/wzjcIkU8/wDAXFbQsIbjDWRoPIFtVTEkxyNV5a6M5dk6y4alwVHq4F7WEngt
VOkKKkvsGVFjAJSJ8EhRijcIelRMsTRUa7DJ209GgrqiM4hr8bbFC86yPBKvAQmfB4Hb8NY8iJ4G
zFuxC04g2e3wuEjwMplBh6R5HTZPnkfYssjA0cF0i0qZkTNlHAmbRDA5PhfKg0NI5LktNiSNFGhM
bRQ0W5PAmUfwPItNcGzgx8N//mCwMmficfC8C+KbJP8A8Ifv4TAsMCrNIPORyE4wqeHowokFFIdE
6GeEksk+eZs5egb/AGicvdJSE5uaFAZQy2EwHmlxRdbdDGRTJMHBiVtlGbSuDakq8mxm/EexUlyI
RhTREG6HowXDZjo4xpDrF4IpOKJBl6GUeCJU1oTkKNmUylsyqtFQ1D275DmMYpVMVBzq7IzgkMza
SZOHRNBRlIRvIhJ2ZYmuxYan4K5CQeqPQ66jEnhn4ICs1CJPZU1TE7BXBGUns5SM5xpDpQXBRK5M
GMcwm7psdR7CSMK7Rt4O3Rc9Cs3oxYvmDxmt1GOBJmPTLk3yPqSluoungUmlTaLwv4b+rulg0YzN
0NOUk6KCtzjYtUL6pjGN8iRlXgKTwThmIJJyKSOjNj1sxjpPDOwmyGLZc4p5gD0Iaa9sY2nkbdm8
TOkPwBTDemw02JHIrpRcObyLKdq8jwst10OhUqBXRPsKO0ZCeyuxYV7hrSecDnBcCTkR+hoJhnu9
GC1zkY5jtsjizR8jIqxVGYAMYTbHbB7vAq3HgTzaXSjVvzR8lzGngMPMNwwex+vRRweDKVH3SJLT
02YbW20Z4bbFXGnIuhhA0PE8M4Lqz2LCk4YbFHHMLpmsklyUSV4bHr8wmKKgsZpSlA2PE6TFinho
oORk1wyJILDXUf552mUQ8NjqGpGYIcmLiiDJBnQ1PRgqW9LBiwjE/hmDhfDoPQnQ09jGVGyOsWFB
72TJoeyfDSFkUbNZESBHSpIlQ6IxPs2bMjoMWnt8KVmackfw3DLBTISHgLgbwPDYs/LV4F8HomCi
x8PI6PBMFghbIb+OBrH/AOOBu/HgWCfPIJuxCxgwwMPLEKFhhbwZGx30ZEqmGuxY774P/daIrJ46
NuhFkX2SqSex7Egruk6YggRR2V2ZoqCJyns2NbG3fjoFRvHk0XKGoPRTY2JifV6E0y+2SlhXdGjf
IXIgq9XwJrMxlIH2R0Y4f2KvqGK4vgaAy0o6GmVXgeNqdlek6Y9q9mXa+4LjfcRK/k1koJN58lT4
ERFB2JOnJlAujRI0fwMJBOMimJhnLvkzh8RqXYw7wMZ7wdnWL0IrcWKTuI4ecGDA/JVOOj9QQisy
+hwPrX8WxyF+zOOCLJ8h9QDLK3Bav2wTxy+fikrSyeRNCbto/wBBDh/7HRtn2J8/NiKehZ7QEOPK
FdJ+C3J0rM4q9jybjJ8DvRrY6BKdntsW8HliZ/EGm/AQqGGyj+IuzDYF5HyW9iVEoyo6fTP1kiGK
O0xPel7D2UvTG3+gyBceBIqF02fncPaQ+iOEJ8iVa9hC1k3so3rIvRSrP2yoORX7o0iJP2Rz/qNm
px2NViovhMcwbAmw/gjL/IG7o55MsfBGl/Bpx+ImuzNcoI+hZo70U5PQ7bryUcVjF3KXRthnv4vF
Xk2WjZGJcvwhTcdeyGwn4czQo10zhvooVxzRobGImZz8EZK/AdSwdEHshctxMe8Egwxj0MaCNDwI
OhrAhahIaa2eA8GTkUhrJtkwNYIMMk5HhQzDEayRiQWiRkJ8Mo1DDyIayLTEQayPRmHByRT40JMc
c/C5psZGeSi3waKSmnxz8Ibb+MT4I5G6LBWcix8cFtJ8tM42XAkewvYSpDQziG4uzZDFhjo2gmLS
mJFllwcAVwcppsyj9jGWYmrcgX+R6AM//Acf8Tkp2aFYh9EwojQrpA/1QzFsQgxswYw3RjQjPBIY
tqlf6IrBJeBysQknokxCM38lFtRE2HQhgmuh4IZhExCTXRNlRDupAirctZSgoC1wQ3dE70fo7mOh
TbQ0l6B0FRUOCSJqMaGgx6TkbzqcJDUqg8mqaJCAkmd6FlyO2FRx3/Auvm5HWF6+DMfxojJSeS4C
MMdMSy/wwNpcD55TDcya0g8LscqLCodBskQHiVW9OCjQobBx94sjh5EGJEgqsK0kjhxyWQeUwqJK
cBEp9tGgU0xHFzgfI3nQsKjtdDaT6BnhRHiY07wM2DL7I5Q060c+Bm7ejMvQzmTF1wXOBlf+Rxqa
FKXgSGi6B5Sq3DJELLLpmJLwVNlkyexUqEJMouG3shlWkFVXK6grbui12EWr0MspklbCiR0GfFm+
jASc+D+f4wNN9Ismm0/5LuGDoQScF8sSY1Ajy289hi77EJl3lohuKLwbgo4/uMfDm9C+7Yy2Xa3g
KsiCC62hWs2x20fiCWLIpuLmh4qrKCkMTmiVmKCaXaRhEnFiEuNwJCaIVgTgYC7t9BV1GGo/7hYU
PyHliclwYhPwwdkNV4GOtDj4aOw3CPYxtD+Cqfj/APFjI8kaNh4JFkWsaY3REIJgTGkx4fw2xhDR
ko9CRlPscESsgvdHBo0n8N5GqzEsY3gtXfxDbGeijJg2hio4+Ec4+OB/C+KhYOXBMbPY/Ia+ptWy
z6E1bYq22azxgoPaPwIhrUYFQ02mkO7ojrip0I6IohsXUzT82kSQW9yh+C38NGKk+bTwPs5Ns5Mi
nwWznZyWIZOvSHgt5GyiQ3WNcfRHsgO7+A5nMsxDNWYr6Rilwo63Ap6thaUxkDBuOwSRyQKGmLoT
G2eCqcnhGocGfVHYNFxUWFJpVURtAzRL6FnkD6j8NIy7RCOnAk7Y/IQktEOFeSh+I0JsZaI8TyyQ
F3gec7zgzngIug30J5AyirVG6UIMzeI/ixRLLwT9rwux2w1a5Y7lgu2r4Xw6c5c0ZtpGuhovVSV8
CE1uXIaGJZ6E4NRmWoIjM1wMPSQZvofbP4HfqISJ5IRCeQpTsItp6wPYQyYLwI2S9FJiyX6XPJKj
DoUZSVkyI4TBiSvUMJ/gWjDgo0D0zYs7hs7ulBfPgjjyeg+E1eDXUuBY8D+BO5pkTqf0PfEZqOfB
moRdHEE4+1EUKV+CkzJ0zAxEbXGV9lSdlZQ3RLp3k9lylKFJPJdiONS8E4J1hU1qIQKY15Od0LWq
JCgk7I8HykhvqM9DnLPGSMkhZXBYSicwO9k2h45fyKs1s4U+Z/6YZW8rYoVWRI4JyMbpoL8qSKUW
hNjZkOxbR/QIesYEmGJMzpAfXrpEq3MOSONBVBsjZCnwamhi3A3k0osBsbA1mobwNF2NDhjU+FmJ
EK8//gSIjZG2ZI2GoQhuo5DkgmXIxtjM8FMQsDFvHxGBeCmNiyjgTzDTZRIeBMcCxkbG6LZLkx9j
efgkX6FsaE5IcfGz5tZq9Dk+LgXw8evhCy/lsU8SGlj4FaVkuJGjQppj0YzNTuEU2LQ9JjYgJxI2
zJBJUZR9xB3/AEQeUcgg1xLKq5M1+BEOmUzzP/BCJ4DWmhGttDQsKFMSP4sZvgS1xPhnPzF/pDx1
WMeI/GHAwW5G1YNp1dg1BNtDL2kKII186imemibWeTQx6S7KN4mBE72ZzlDGoadDJIMKBadliH5S
o+sji6bXTMuSTgh5VsYT7C4S4IFgWnrIVCQQpoUo2dCJE+kFeHfx2SENTQq9CoMxzZryhrcjpqv7
FSZbs4MF9CGmicie3Q73qKIEiC1DLAStZJI2F+hvTVcHAiDkgetjleOAhqfkc7KTMFdtD1T45a8j
182wQpv6vRm/yMRYTwZXofhjC+BLTTf/AAXBwK0JQNsQEyKipdSCZIBiMvWLRl0Ife08EYnMsHtq
N4li1kuLKpuiQyjk2mUkHsa8cjazkSEcSh6DizKGOvYyGFq+SdaqYMF7VrkfumsCrbmhNN11JPY1
z27fh05ytDKYiHZVG2G9LrpiBc/IaexdNTyMEMtg0zgmQo2jf0NTd5LSta10I4UNPI+l4PoYIebP
sclBo+RNOTBCOVOvLFIfSRhvxs7EvoEgT+hl1whVT+AUnEVm5HYX9AOwbsU2SuE5Nl5NWysTcEnw
RvaEGzI6vIhhrEwF4lJlmhjBG/HAwY+Kf4YxkTPgaZRrRGLCUSDhCDZIdu/g/wBGz+LNfDwP4Wex
7z8a+S+Bqr4WfHIfj4k+JXoeWJOjFolEuTksQhhdmWB4GyZFhCyZbIyw2SGyf/ksjcwNCw/hsSjL
wL4JtDGI0RPIjn2Y1ij2rsVptD4Dv5CeTqnxSCXpEZc/0JlmkrxsDmuBld6CYGmGPNmcCxtqJck9
Db0qf8CYbzCziOmQmR4ZskTNviUShBzgrz5/phScUdNqjV4FexXTTQZ+RjUbHC7o0XdA8YBDk50F
GHgX7LB3QHvwEI6iRengMeUSo2RW4wOqsMU6IUZEqcAHsXLQvbyDEaVUS4gwMEomN7CE3riGorwh
Vi1GUMY/X0hPmv0qTCZVkqEvYc+EX4vWg1YH9owzFrJFSYh0OCVDVGcBjSyti2UnwEtfB0eU8GVE
CuT5Mm24oidhFuF5En2ktdm8S2UZD+DfxBi4s0zbfOToQiE4u2bBsRoHLDR1LX8HhE6MOeXI1jhZ
QbB9urkbeAyXpKqU7DYk0rzgrdhclwsulL1xNR8qdjoM6H2SzCQi98vIoTDBucLJkd1J4CyEvUKN
X0b5ZhbwNFMrojI8B0eNwxXLegtwPFFPMUMLaQ/Mng0Js/8AAVDU0xeqT3QotySSHJozPsTTebnJ
wLVkXZYdngw1voQyjy1rsSdgvAcTRGJDmVPRBGN4DG/meAxlNWG8DrleL9iHn8hQcSd+WSurpMRs
tpPQ7Wtr5G6aMxCCWQlyRroU6Rvl4JgNYqMEk7k4Jr1inyLERlZEzHbwJNnpDnbCexjBSxb2RRLy
2Du9L4V2yQ5t5+INVQj8zGHx6DMchMdzY6iUoyy2zDgaKFjkbgjeRuMQ0fwwcEwLQRirRGSMYPDG
4sFNBImPgxsppHJDbYnB5yYIadGiEEFULyP4X0G4TOzgcL4raMDbAg1n42LA8sWzYZpmzRPjBpir
Qr+htNK5nIzTqFJD4Lu0YEPN5LEs20JWnIxHSHonO2bEWFgtLF+cn+w40RRXLSdQYsH9iNi3eSMU
a7JO5iDFE1ofL+xelNjeYd34wHnJejAqL9D2LKG5TYxNsGOAFQMFSVcG/A3ZIOUy/BKrwe0OpYmq
PpDESm0PaI4hOwzkwyZCgYALWDuLCexoeSoQ9bGS8H7YRfaQaE3wLqkN5ZKRz7oy9OODC1eGLKd7
Y3+FF2YJ0vBkbhOWS1f2bEF2xK3YvJ/SEXD3/AXmti5ZmUvKM882L/7B8WA4F0XzQmzcaknJnyb2
LKgbpnEvkmYU3ELMbuzg+4Y1tVNiElowmuCLRNjizeqTR8PDH1o4gGmcqjV2ZbeA4MzZ5Lja9hbV
5Owi63BkHND6y5GvBu4GSNIhd49XrKLq8QS62jIjKUtxnUAAs52yfZLWsxd/oV54XCHjoTyCO8uz
O00khQpYdCZt/Y2cW/RUfOaHRA/JVRBQPKgnadLJLbbMMkgIdPZxxB+Z2ExJhOCdZGmfSLCPDLGT
G9hiEcHoQWf60OzLTYVG9zNqPDI/d9CqtPhezJTyobomygaFciDwOZM9uEFM+PY5gVKt1wshawcJ
DZL1q1JcCc8nOyV+5sb0M66KmLZMKWiiF1PgyW7e2xaw+BCOxNcqvQ1byEmKzLMptmcOdaQgNN5Q
5XXhoYiRA+mRuuUex4cb3wawbGLMgmFsio2TjUZkZBskcgYSEHyKmGnY5cocE+B+DY5tqKr/ACXY
1H0ymLLFuRgHhiTRMlGLf/4OmLeBoLLKPR0GocobXwgtY2YhKy5EVMCpryLXxY+y1j4+FRUJjglI
uhnTgzQbx8Fv4XAtZ+GoNfGhG0dF+Hk4+FgyHkxYwJhFCnsWBFTYQkTH58ERjbEeA8iSthME+xjK
FkWGcvsDqVw4bL8pCm8FSOAd7L0MDg8slGjOvxaMyZkIPeCOmASwJjOmPWu3g0m9MYP7BkT/AGGs
Go2tGXNv2OZDCPXsWvLAu0sroXyxZWXyXA0+RoA9DyLRBUPTGyYymLqlPo2xoecp5MY+yMFsUd/Q
ctDMRgKr6MsS02lZOwmjy8oWptPPQkosLUsEa7+LjS41OBvb7otT/gXL2qGG8PoUG2Ps7cG3T2Nt
8nWAwNBwVsaya+h9z+xPVH+/EOmQPvsW0tM772PtUz18crBsHuoRE1iinX4K2HG4VxaH6KMSJnY2
sBsDao0SNqYryWhKviKaNjFzL0Mje2I5CHUdM5xeWRrNXspfAPiDmj0dn6UEJX/AKUo9XASNPZIU
7/Q/p0vQ8GW2zkDd0hkuS34DFpo6QktMrUc/AwlObKv8wykuGJTTNdnWYyypxFWBvDMBoxFeQm4K
pIJkVZGPSItYLbQooN7Q647vBgSRwpeBoaGWZo6yBvgZozIZPIXto101xsuk/wCDGpoc5hbDnEyJ
RuaLrtIWlVbgSTzNtJDjPGFLthyaEO6JmS16wVp6dCnGJ7QompDComm+i2dKbMFQbOH0Y7buZoXJ
yKKkvAYklzgY+BGkN5G/lO0cFhRD0YL4eGbJ8SD18qDfy2QbrHrBdi7+Ezb4YviMSEWP4X8FyU7+
EwcL42zPw0I+xGQ8fG/hL9jxiK+zJCaGkrvAkaZLDlEsWNREp2i8w8XJt4wM0pkZtoJYk5s1oNtV
0JFo42TAoHmSNVTXA67gMZdbg1kKCg3At0TJRs+Phllo4G7LgJ5FrFN1jyhUJKFDCdCISot5RzA/
Or2GWxYmAl+CswQ4TRSjJa6IhYDJLooeBxj+DLSz6K4G+RS3LCEJs5UErgdEa0WhMqjrGeUVVvBo
eFNEEqbMnj9Dg1/ImNkfwXkk9hswhNnBBHJsmMp+Dw6QdlDYyMRRSXkW024FAVNNIyQMtjIvAMRH
gUqF0NNLSy2Rqe3xM00bT2YG6hfleBYcCH/WdB90xG96abEuqtGUqOBaIsbCXYXA5tJrhFQhehB4
1IPVborgky6CKFBB/BKhuDBU0EjEypElcCOattxGuhtGTVjS5XcHtlXozW0T2SqFM/6YyavEFOVQ
w89i5ZQoUhPKDDm0X4d5hSJPwh+dITjwKY2zLwKkKqkZTtiErasrE++TOIvQ6QYuhiLU5BYTXEhj
0eJML+ZgJuXBQ4iDC68wdPq4HkCnbSmh1mxwxkw3d/Apt+SHd8di9L9DStfgS6T6EnxsDIg3j2EH
wD5FeXoxQ6rApWXlgR7Z1gTuqfBajlrGjNXkiMbTlUPEqG4h9d1WbGaFzLnApGJWONBl9OWMQbC4
Qm5eUNTBb4NSMuiEopSUKomJr+CY8NBzrbU2JpsU0EObpDnPDWxOaqvJmgFkMAsdVCmLQvFRWAmT
QdW8HENxS8NZYhnUafAoyMxisZ2hXns1VSF7NqFyP4JXBM1hUxKKkfEonUMNRfB0UN3Y5+UYIsGk
LQjIwRhkeWI0xCG3x/SExk0zYeci0Z7Gqx9aEQ0L+FX38kZLwL5XJbg5H88ix8rRXB4tF8bOwzmM
GRF5pq7F0Dg+Sb6xtDJbiNJwYVYUJjBYaXAtG4Lc4hufT4Sm2kTfgS6nY3FH1MzMNkxWQWpaTFyN
/gwHuBIiejK+FmHItT9spV0oKDe5rNge8o8bIQh5Md/PLGNwPoq+EZly0+hOOkFqHe4UQuCi/wBE
Zu3wLaa0I7doY0qYK9EVmYL3aUHFYnpIXEVs5GdciOk3pp1voYYCeCYY90l8fEosdk14FJ3GMXAg
TIZoyFrcXBnEcDtLKkha1u4Y1P8ACUJXozboY4uPGBidyylyOPKXk0KJDZT6GNQYeG9HN9TyfsP8
+Ki+az4HAmkZyA+DpEgzC37YuTsY2qMc+BVytaMzAy+BQNdzBFeEIKqp1BRVxCxwgoSDG8JacFZp
fTRANPRn0ifNhztAwKmEjNNGxLp6Yq/DYyEo0ZExnNM+y0MLga4WsPAZP6AydlhEZCp0nHJjB/AM
A7WRPEFsacPjCmtMwgoKMtfAxYRBWWco83JFU4pOvixC+Iqo0JSjWScFYqlFWOQlxgYkHpohWPVh
pFHCSroYlJKfQbPwXsRlaU7OI7XgIcm8KQRPtx9jBFawdcZR5mlVN6EBmZUJuFdPwR5AYlGLZGcN
gThjx/zRCVkFSexZMV86OzvEFccTycTfNMIjMNcCwo85rganBLOCRiDYdjsTc8eT8Dz1mUZdomqN
o1kKiHsZMs3PN/DGOMGfwIuxWsCLUp5G4jYeRW1xH27Iek1T6RmM4MFMfpAwtqE3HAHnvlhcaMWN
5FufCNjrHyNRFg8iJkRCdlFob0eh7HlmhM2zbYnkeHr4c4Lgb/SaG8CexR8XI8i9F40XBIN/C50c
jMjgTEc/EGlj4nxySM9izYsfAvBVyNxoRvBw3f8ARkmhpHCzJT2GVLkWyuXo/mM0TAsHgW/fARn5
fNsojmscFoBo+2MEdNjWJS5l1Uxo/Z9mBSkULMjbZwViwmjV+TFl0vgn5IbHEN2EJRN/Q6PGqh7S
EjqG3skNtPZFEy0se2M8ETPfSJjERhiTrFjcWRkk64nJPTMflmCpE7JWdDfBDskjgrZUbBFmqscG
JvtJhNC9PpsbFR9BZK4Q1zLHkzblDiER2mMZYgypZHx8GtAad62JBB+x5SqG3lGa8EiCJxyJ7w58
hxUhrYqALcHba3kPbyGUcy0xBsqbP8T+GlYKZMDLZUuWMUBSi5Mxlkf1DBD7Y4eCU6fAQbplPgns
ZlCuiCOYGvcL/oRhzEMBG2mwMXEbgvPA1RbmVS4QtQon2NRcJCT2f8F+HiB3/CJZYagwyDUV/SC3
DKICC+9JGsfHZpGfyYl4wEyNyKjyuMxXVxJsTrGeG40jMul4Y1TRSij4bHprH9LIyazsCI25OB+m
3WTkSLCNo0VWx7xWVtceBpFaJuDxKKOnDyRuGtP8osz01R/S/wAESf8A2TyFt/4VpvIpG2QWZqt4
Q153/wAHU8rPY8wLXkdnERjIanB6MTbmji6VoQ5wDSNXgY+eLOkNyNriGeIcjDUkxIa3GEPzKiM1
/wDATlp5E7WEqczHNfgyteWEzCchu0Myhw6Vb2T1FrKIHdJf6R328vLorHmo9YNyDRBfIt8xFIIF
QxHMp56EH2NteyXTWehLOYGhzZnJTGRT4NEYDGGcIMGPqcEaU6dWKcl+Cx8Ia2OqRrAyVk8j6DII
WxponkmRpQ4GjJWLFMnRhKMg18LKeiBZORkqMSfDkwex/GOTT+UqaZx8pB5g8FE78XBkyjOcayrx
TKiZliHs4mjYls3FLGweRYSwJIXJhxFBRJo0CtMlC46qLvjmVJwPSueeBU65HGM3q3QlOgjjU0cY
rZHEZlM3W80b4DUcEMH8CZnA8DzkbpuNdaRWCmUiaFfAhVno6aNOXqllZJmygjcFYXlyXPFEmosC
obHk43NRRNApgbypiomiSEWJotMJd/FoRn+wRbiGCNJi8kJXktvUt2sMC2VH1ZBEdfg6EyiENBCb
MO4vJxEGVZaRqG0uBmxvoWCumxpwi2mZoqGUlXDJFr5LeZcEBEcvxEameRNbLK2IIpeSIQ+PQ7hD
KYHswlW00TxIED3BaKl4Ksa4kQ1VMo/7kLdO8DUjQ+x/jeNmcmXY1lNlJ8kAeWSGHCCW1iihuBgk
lRGXHyvibtHfPou+noxqxXS4C3KWR7PSE3BgaFNZKEdnAVWaelFHbTOX6hw21XJwdX/hxhTliFtI
IxSqq8n2HseEajAcWTDfErT4Es5k8ofybG0ESrX0NHb0GyTzpgAGRm5p4HSh4tiblcndl7Du6Ix5
5aIxOoJc+idpQn8MSfME407NGWE6Gq8jfaxyh5/59jlM4eStvGiQ6fQvLv0MaZ5Mp44KFOReA3TB
UotsZxxALKOkXZRiwV6FKaNUbpd2lliCiCV2eenYpvmT4nI1uSrICTvsEphKeESR14NWZHqg6JPm
Rg+bKN8wsUNkXy7FrfMu2X4nD4Up7Rj/AAJ5m6N9xVhOG6ZeIuoZ5lclYhqIWpoTWl1BcSLcEKV8
poZssGwU8AnZuXgb5h2yZJy7bSMs0y6Fl2Bevs1/5PwP8waNIyymNOsNOEJNRaZQry8Ec8B5GtY2
8D9AbpLkj+JR4GzZsZOoaGf0PRz8MozGLY/httmbk0Qdnxk38EyXJaImPBaIYMeTPI/ByhvIrR/E
z8FNfA8HlfGiX4f9F4+EQSz4/wDwzOBY+yUP4eRmfkSBJbHT6MiW30FA6Sl5GbAxRsQIjWMN72uR
Gk1S4GlYwECwu9r4G5t4CLCyC2+3XgXwtp6LBzvAx/DYZ6a+KFxRyK4FX8JZPU3rNSGL9bRC+Qhy
OlyyHD1+TMjwDkdXKGsnLwZZ18xnl13k3CPoYEhuGvgpQUoj0h0qfsbpvIS0cMGXm3wn2JjKryLE
ia/42xZ/YIXW9wZ2M760fFEeRjusgwbb1n98yGbNOhBhxh2PQsj9kLnJFdhkYyoxUynb2jA6PoUG
htGFO72YB1RAcHwLTtoBEmR2atu8CRq3toxSOmasRdoT6XY3I3yPsWKkOWxW4kxGfE8H6xaxDmD9
kv8AsJZLwxSm8Ic9FNOoXn81HlUnpjOykG9Fe8ummur2mM9RE33CKOc5HyE9Dc39oYZtVMKU9IsK
XwXReShS+yujT2Mq9jkT+G2cugzsh8BW8oWUNfKLkV4WVQ+1EQunwQ7lnKeDXJn0VqcGJR1R/J4V
Qk96iMOPGaM5XpDGuzmPBT85Gd5xW0Yt10mQRkNKq+S9cGgFaSEoXyHQKVIZaaMJiFXk+xmGT+Bs
v1E3w8t6Y7JRiQ9PwMNJ9jxnJRNj/TeUl3TPDTOejAGP8L2OzuxhMlSDwepjndpNjQi6pD4g3OVy
eiVMU3uFt4GvwYa4LaL2DzsvDQzMbD6VlGduWy4Rx2TDOroxOHSRGhZcnhCypPWi36EUE0vZWjf6
P/wWS5QXvRKMOaxRgo3sYdezV/TFwN5HKqDZ7etlH9cZz0rKPJipt/RjJFElOBLtue/gR3wPJobK
kbHs4+KJ0zPi5sHlGhgbEySMuPglWWNUnxsTuENDE8HLGzI17GoYexrJMwaqfB5whKEqwWextt/G
fjXJwLByWlhc0o8swfk5PA3xwRHGh2YEsZNuIaVpV4Qs9jJItCKi2WaF0ZME5mwEttw6m/JfYldC
GjQ6aycUmPovuYXaGsxYH11B4185JMHqGZByZILsWcMmfjcpPPwNVcuDWi6hbWsh8kg8tZJ+ZFjm
F1GfZEYsRaizMbeB12bwcOyMwpBSfcQF6slhC9KTZbcjm5RJf8yTQxavJ7nwzUpx9GVSX4ObjCH3
CYkrstGAg+hq2XFTvDWBqWGg0FnaEeYVk/gU1xGfsKZB+CoiJYglXg4KDRHOR3EX0Ntw3YJ5E+gh
6/geWbtizS9iwaQzciFxDowOWkrHIIO2NwSdJyTMnSrohmjCvoWbtu0QYKykheCL4mXSFy8KrFoM
1a5aCTWdIMbcLg/QI8t+xbewN7E/yJsjHoy81Cd8O+irImZhOCKzoP7Xh9C+BtnoGiQgqF7EbDXA
ZwJcJ+ildWhDhGOw9CU/iYt405o0z9rF82I5y3ghTLbgkLVzBBULfaGt3GJnjWS7Yz2D0M+B7Di5
Sa/SGOV6ElSJzTt+BpUpdmVP7GPC4wLUUqmFPbWE7NmcfsCHDvSG5svAottkLbpbGzd+Ddsoumv0
R6DnrbpIQhoxW2JkpDKQkK7X2Mw3wYbbZEKUbh31K48Es8GkY2sTyhPQlmsCXUtMcCWRBixNQIQl
yhRVSw9Eq9a0MV2Fehp53obYa6Ma4fIkXp5QVQmoMLBbUQpw1edQn9WEVkR7HtGzI6P5G8CB5d+R
uDZPhkDY9GC+E7G2KsbwyhMysDCWDbEPYxZOhvJPhLz8NfEQ2KC0aCyydjYk/r4uRZFjBIzCGLI9
HBMDdRS06Mshwvlj4o6RyjbAgansemEIngaLg5M3oMtpqm8hZEGuEHuWSdsECqojAB7zwZxMUTZl
VxlDCqNTRbZdj0qYwXHRQow0YtoiCHCk5p/AWz4KNDKEzSvfxLUJkbhnmmg7FEfsW/6SGsdvsR1z
5FZpThCrFCgsYOoaESEuVCiI/AJSJP0KUVSsCciYSGdBfRmVG1Zs1MGKEbJ+X4ItLCCOKPKVemJa
LvYOZDiiumXqiCv8DPDX0YC16Etw4RX1jYXXaD45yQVWhoemOV6Y5v0MBph6FhEpVFWb6EgK260s
Ilrr2YEyFSdUaRIIvqyI1SWTDONCsI4jGdslsjZd1fo3BN0Y1CYSMEl5m8L2QppZI44GsjQ6rM+h
fhuzMse2KOv0I3fI3eRlIOUfCOLnUeDDFvRieZYomz9HIwJ/BhmSZTw8six6gux9eRghE7GWJfA1
jFwKyrEigbo0QLWwtWjyoMvE14Q1PtIlERfRKduEUpJIXCShCFXmJ+wJ4I8ilMEa54eSgW0XesuE
KPS17FLLVXWjJ/IyKKpr1bMRcm/CEJmmE0MSFSlaPtF872hXKq4TQ2VR/hCTc2Ca5lWw4Ob6FDEc
QkqrKQh9wydmFz2LCzdFXtEkVvIBC96yCalj0JcwAkdOJr+jriNkTvt60iowHSEATYaZ42zeOyZH
zCPPLGMRTMQgLZw5kRHciNJll9eCIs2PACn9FJFEpRFyZZ2HrDpgYtt7ONjha2fQxtectFl0qim7
zIA28i7VsiUJmxPp4JcLHdBxugY1SPJs1eFBd0ieSFUjgnjDlieckTbFlPRiQ+GsC0ISZFa2cC2b
KPn4fgYxRRiE2OCLnBMGfiDTfJYPRt8cGlg0NNCeRZGsk8GRvA14FTbNFEjRejMEciJus4F0NSfC
YlWc+DwcFwPVOfll8mDWDXk8Hwjj8EIXt4Ggl7I4wC6m+Khrh86tmIRNGcXNGJamTmjRRsiH0a0N
WyJrbLk/UWmvvhyU3vsoYCV1/HYZMuCjRihFE+PhO9ig+jEL/wDDovhm7GwZ9Ghr2JQotthLZGt0
avSF0eB7KeKcwp0DRSk+rDuTQXSII87E1mwiJTWJ8TNvQzTxoc1bqL4UTZB6EpT2NFLqIpRpzX6c
2OMRvJdp7C+pYkcieiGomKmKzEYItTyiMQ+1E2hMM8wnpGO8NkC3/Y9L0JBVH4LvwOh4JYZVDxOW
mOiE5wJI1UH3giYxCSBe4YXy1UMkbeuRJ0VgWoaSzgdejVQwho9jGoNVoIf+o+bz/wAP1ILkaaFs
q+F8kdd/8icvCbOEUaGxzJFsDfSumJacGh62ObjMJ8DSOFEQxtBiUqbJQXUImJi/+ob4wJWaw/SL
TLA5wOddt4jQ+yLrA2jw/wBF/wDl0JYHEKVPIj3kP9Mp5RIhJyKFWG1WPX8aqN5BGYCFwMopTMzf
4Rsn644YEG9Y/wCgUKyDxRKqtR2I23AsC2tOvTNmO8901FOTmGNa2k4hmNsg1fLRjU1dS9mWby01
S0axxdDiWlvJk6LJTaGuqzk/+Lz8CsJlrjrGcavASmC2ZNwRawt8EzYwHD4hc4GsTHX3Bg2bTXIl
rCwKKYSEgZYyJinQmV37EBEWNGJ+cU1gaCakIdiH3FzUwq2RoaVmyGmWaKRSq4NoYJmQSYmx22qo
xDOugj2KoT40twWU+BilppGAeCVCYqPGD0BJDPPwN0YyYw8Iox4NsaULH8PBB4JRFRMmQshGjQQ0
bEn9iwc4HyKVTkfwmxpj/pyaRyPv40xOvI3k2M9DQg9nI9dnAsDxgpROuhoeMmhdSHKEx5NGMiYq
FhmSja+BE6F50MDVaKYlkLrRIIWmR4jiG5FluifMIe0nehzkNzbRjBiIoga6wQc/+RcXHUVovonL
SjRngdM+Rm2JRLA0Y78I3k8iycxle0Zl8IZKyBTSkoRuSi5EL8hbMO6EuHegxGtvwpXc7G5Wjrt9
0dOJsofY4jvmppNk+9pGGTwNV1WQvNoxjKF0U2DGBBy0clRszgEGnbBVc1vgVUNob0DlpnoSnCOi
5a3BFMrse7GLJvitk3yD1cEhmzNizKJiHGP2D/5Vm9lQ02cJS6CKieRgPIMImnoaRK5NT4+Icgq3
tvI5gb3Ra7bQi57DExVERUpLaGaVNMXyPyWdrbhjKUDpM0kwiG8j5Mg8JNwE/kE0sMSR3U/SwbWV
xJbYqqn6Gx3o10eTXJ5KTQxttqYiUUwoElO00Ww1wKKqaLiZF0PJotmRC1Qe+MkpLNRYHefKMsYm
/wBFiXQ30baCOlbSbEEV4IeokMTtYbtDvPkFBl4RgRsytCCbyzwLKfJmOYOAGqJ57LZv4hS9Ugjb
cySCSMnJ5l3EbBMja81DJ8Cc/RQnh0adRRlLyyiMRJ/A807qMQizULeM9nuCpLGGdpiZN4tbObhi
+oHcOT2bHKpjytPONoV2yQwjmgLFeEUwxpuxw2l+UL14F4M7rfIUsMnSX6MKiF6wLgEqFOS3tUT6
E/rFvY7kusPrv8QgrqjKHNa2XkU9OQUWKlcKt5opN4ITxlVXGBQi11Rs3KsTATG1Zt6a6tG3Haux
O7y3kNBRiYpYNzIhlhwWEuTkyZoaPJePjKOw6RaywasYQNNFoZStmmJ4OAxN0j6+CdQ8MavsWRvI
qxrY0YYFv4mGJEhlwIoLCLkvLIzYkEmckbHs4OUUpgaFkNdjyiBgK5RRG/SZe6JByhWzNKFtN1oe
WVqmCNN0S0bbKISfkx1pwN/QKikaEXGhHs0gjHYhdT8oatt5ZVmDG2yNpMtXw8G1gpCKb18OokNi
4iShvuAhB0ntlyuf6LTFqGWeY2EVqr9ExWSGNvPsO1SS6D+rzN0TFRGaaYuUPschCVm5tGn5eSJU
vZjXS2K3g02VwNciQOJdMx19FS7L2N+tbZV0d0hwcqjY0PdH/wBAYtjc9CxinDOTHohUqvDejaWY
OTUxwXldikZugYtBTmmMKW89EMr2JxEEXLM9mdH2y4UzK1whH47TfxBNYbyi2nHk/JAzHkrouKLq
iQoRaYibrfsVTbvLQj7/AGWKxb0HwghutYMSxbCByz8nKcFBpcD7ERkNs2mY2NsMnE3wN9r+Qg45
/BlauU0y9xNPqYRm+h9f4zI9R2I3qaZNme5AaG6nnaN9qKcQq62KzNnexxTkTGeg+6Jyk0IdvLJz
Y6YnEk5OdWYNUxyoeNZiKi9pxZapZkYiYldZUJrh8DALC2LVm8M0PMI/pHOmWt0hSxrsqgx02YxV
m74RQlmAJLSP2Li/syOkmaFqngMYs/Y0Zxjb6LGxyixzWugpnWhEeNkw5r3GvjZAxkxTBp13LDbI
yXiBMcGTPwuxNq4D6Pb4qyLPwXmcFKRKVjyhSW8CErwmBA3IYsGaN0TolZCyxqZZLkWYgLbduhyS
MvyJwMoLM/kVkedgwE3ayxbHENNZF9si5LYvHUkNc6zF+231RYwXb5Yw0btpkw1rNiTIl2ZTfU4f
wW1T7dlN1Irk3sQj2QRpFcSGrga04HJIMs+OTY0UZKNGvhCweX8MQuPhaNxIeUSmeR6K9fEnAmQ0
x1kz38JX4P8Aflp4HkTGwsM2XwdILBNkwL4lGaGxokpS1/GPnTE+GLkLLPPBu14Hh5MDaMGNw2MV
h8o5HbImhOnGeRR9CPjyPBvV9JwlfBZ7k2AzMZx3kx772lSl5N+0qr4CVitOR5Hk53RY+DWCzY9U
fPYwK+DAv8IOLv8AExXaCZimA8jPQVk2QfpG3y2xTVbwJVSiu1JiDaQSr9Ezqa8mRTI/hvTFuX5l
jkYvtU4leWxpYcwxejbnxTPt3kZnb/Y5SGhv9DYFdixGPoa7TYgw3kP76Ix7D2xRY7yQ0d0aY/DM
WNtbDg1RJreg8h3zRO/Y2Lf9JPD/AEMk7TRizMv4ZF7b3GTNC6EUs7C2SfXEQmpyLY/EblVNBK9i
92g2JpoWngUBuO2KEqHptAY0SEng6OXRwiVeSrBr7KhtZkXIhEiNV9mWSLyJGWk2hxk8vMw9AvmX
GBlWBatCbOKLUNrZTRV/BSzKpmepMRzr64Opr0oPm74jNGWJenseP4MliDeiFNwooZclgzR+SKRh
bWyiyk2LkY6SECn1CMqJyj9doDaOMXttF4OtsjRWtqxDXUdPoN4XzMCM2nOhhq3pCYtYo8uvInKh
cktvBGjgdrejPIjGNNGB/YY/sYYWsDaKPJg7OSDNKzEXTfuV2MMyD2HgfaxaSHeM9CRCnrBjBnKT
6Zc5Q9unhMQE9W2NJRQwcpkHashjS1eB3YBlo6WdkwzJXzBJkcVKFCFjSTqspq8jwO+ZdnGT8Wx5
IPHwb+IN5hXYlBnRz8Woy+M7GqcfLNDWR4+DfBCCeDSODNFPhkrOTFiNfFIEs2j5E2WryJSQwQWV
nA21jZseBqG1Rv4x8eCR/CNBZiDWfAq3wZVPjqyKifxV0VyZJNFkSUVI4NvNN+fowRton2m4YBiU
6xG8GS7OAvZfQ6SCGLDbpnyyzA17GqcD9Rr9PY2ZGpsbHwLELLLwV5DcHNSu2+zoa2F1e+RoOk8m
LGFmV0Neip8l2GB7wJkrJ0PMy5Fg4sBO21cljIY0SK7nCjEgfbAusk7YrSwbGknoa8V7GmVvBTRe
BCbCMLY3k34bVOin0NQBqENCfAUBBWpY+tGRCv5mbQOcn9DPOZjkXo8CYEWuE4JNGMshxr7L4R4R
rM6IddxIaosjghPwhAyGqRMmuyKl6FM0fIuqE8IXbV6MUnFyqxsc/qGNkOBnKoaoVoM7YeRkua6N
jhaZI9X4Pex6LH4Jckx8OUyg6SbQkTx+hVYx4EIrAhqrk/YxGQlC5E9S8Q5w38GzVPI30pYyJgkT
ZPRDWflof/8AAvRH8GWTtDoKlcvZSPYbRLWOxDLMRdDe75MXMLGhG1nWaDP2X+73gfZtLPMUCUrS
5MLBg9wyuOQiKsqgSFeuFkTh5yVZbKByUaDyhWNnEryJmNEfNjoyt2FzCVjKP9EdsbcWBSyL6Ear
7JjkcGsGDbgngV8XeB2ITysD+r3DE/tK3kft4ijntoZrshrtIg2kOApSOWwxsfiSqiwPGJHxpH9U
AZAXOJi1LDuTHjrlgbQPxKsCtUkT4IzTN1cIkSW22iJn2SM5rcyb2ThNhotF4aFdCTa8MYzhPoYP
OT/RaJKwWcj5tscEfRSuRrUtIweb5fgdUVskMFo38N9FolBnTfsaEhSkHgtF8ONfDHQ1DXk2yZKm
N5L8WNDeTYsLJevhsVJH2b9jNIy+EyMf9EzBjRwVwb7GWjGhnAqNGifK+MmaqI58KUcDcKS/JLTi
EKXJuLf+xyaFNjWm22cwUhwJY3JcIMNcPJDqLfAxNq8Cn6uDVngX2xiHxBpnF1Bz86Mm7yapMrGR
H8DlyWMUGopH7FwN/FbFeWR70JIZgJTYcDtXoig06EUFpUOepNMOS9qMnGyKQKtwiZGq8MIXeBWP
SByFsVrOXk/wHXSJW1bE8BipOgeDxQlht8Dd17lGnYzWy0KS0MhbNeFEEaaY0X9TMFgLC2s0vHCF
spCRdYjHNnA4umWZjkv4S84Su2EOSYW5jeqOU0ryYeMpbFuxUpcJCtTLIgtW9FfQxPAgzr2Gpx3Z
EDdTkQnNtltjCMWhNMcS8CNg6iBnsehRUWvvGXnf/BbW+xtmVCySuEHhDBHFjhxWPphsRAKVmBl4
LLY5+4f0mRrvHXFBliKP8j0tQj5F5RWzvi2E14TKFGN7Q3O600iexLKGadG3oqIp0qP/AJHQrh+B
/wDU6HxeY/8Ao/8AjdF61RTfRTFhuDZTLxv0LKe6xsEFkJgkabCRkXsaKWF5YqXNo/wGTfgXkyXo
/wAHOXKbI0NvwI2LoYrz8Nlc4byeXUfoHBYXFTGSXQDgrJ1DWJHXBWUmyJOj4oPlbJkiB+d44Qra
iyuCSCiaI7cQNZpo+xOXipknndkZIPcrCElZmQyOCexm4cfgVNcv1DeNHLFf5SwaJ1th2VxnJuRm
QV0Y3T0fgdHVtp2K0ZIQ6g4vJ4cR7wkzE6dQLs58Ix90DIl0mJCtVPW2ha8bR5NvjBOyawOqc7B1
tu2NYEeQqN/B5ZpCeR/EFofxwEI2aLGNGic/EpBdiwayjsTmBucfCXxDRvKEsjT4OwWTIeB1kFTi
HuWshkb+ilOBNj4bz8SCVZ0RE8mwnWITOxZYnOiHgPDNj6LP6ezxSsaVwkxwyGbmnkgrXmUIfCGn
SUW0fieiIaGaWg9YMSrTu1CNmxgWYwbg86QddJSND1RdiVCwTJr+pkOzQEWiTyYrNwRoV1EHHJLs
VomB+RTaokYGX1mPjIo6S34wQbPMEQ2kVovMMQy00PJsa1I2OsXIh8ETsr2SPZkWkKofhE8U+0Qz
oEEobdYYaXTOxeP1MuxuN3BJ58lp8vZ5dEoJAVI10NtDArCGUehAzphIQlxF3L2U4KShHeUp5NFa
lwqpiyYWBWaWKWJX+nFBohe+RXdZwVWw0Kc8E9JNm5g7syBp8aQ6k7ka7G0f/b4JN8iZbNjE0GtD
UQOotcwVI2dc/VHVMUMrs6MC70I3HYi7VYHMTcxysoYue1CT5pZYxTMRiQaef8Ido/0+r6JnFTXJ
WbmUyU1oxTmxlLxpn/8AZgc48JIf/Q6Jq2Xycf8AIc+ujZsy74Hv/wANGYLukYhh8Bn/AM/ZPc4w
H8JJq30jkcJGU4BLQdUlTbxQ4rQWQia1xD8TJ0bhwP7h5lf9EJE+RDazX/0093+DYPFP/m8DT/75
MvU/wWsHIiGYFRCWWwYEpsTb4KXgW5LpzbHsy7mliHmffYuSk1D0orTaIvBuiyyeCHNFG3qIuQXy
xnYbTwW1zqhxtGvQq5eV/wCip1U3y4TmvQuRnsGYTgMEyZmwoNyngbWDguDWQ1q22+hUpbh5DVO1
D7IFmUKIU3ht2JxBocjhCC5Odj18N1HJexjKg2JNP4avxyFSpwGAnjP/AOKwhMDQvY9w5Oy8fDTH
fhfHPxwTAhhDx6OYTI3M/Dj4cMGSISEg8l+xNQufi/gL/STMi4M1sj4OQ96J4vQvZAwMmvIgEjsw
hIMmhM2g/sEquQt8vsSZXQ156bIvjyvihdCjfIkp6IxwBTuRzjLG4xtcPgXA3gy0RrkeTLDPqwVv
6MiWRq4hmoHhiKDsYVDYasFuXNDkxoseMhc88Ie7pYRoGXCKuKFBqeDwMzhG8nFGA0olYuOqEw5r
VsbbGcPnIsdhZ4FJV1hAfRHYswzW65Eskhkqs19h0SGSgSxjAr3+nR0kJdQKyd0UDTRRI+iRqmaP
SYupeqZWIWu1E7knAupjUj6R2VpCSzktC8HMMIknggQfdyCSZ9Cbm8DZETymKmV5sNntdiDybpzP
B1KStIUyzlspRmAtsW4deh/6cN/J9CnjTpjRzpYRR5JbvIo5hM4FayrqIK7MwXbHWtE1giZVLyMG
hdCu8vQxl65MmSWS9iTUsHhxzgczynQmxjeUhhoo+hMQ9TUh6D/o4n9oSPI9jLGLUQnd3h+RXaLr
swyp5K4pG7oWlxhmXh6hZdlTK4gLOvBClk+fQ373CxT7UxDRlF0Tj2NkbbwOCnlRsmmZS6RqN6NZ
QHTh7ieBKdIzNmyV7+PzWDRl0F9pyzEKmJp7FkVbURK82jYxHz5KQEnlk6WizRHV23eBCcVNulWp
8Rmw/SGiqdZ4K5GDJifxYMISrDj1tD/xYlkNd6gyldq2Lhv+qN/GFeDAx4QQ00XMuxBCeBfAjtsy
j30ksUbiVUdPAdpmrMs5IE50b/zOQ7WZE6yLj82hehHHVyMIQsvz7H5bo3oSU2ueB+KuU5H5ojCF
OeeTkSlb40R4qVwh/So8r/0eSGTQyLI9s5G78OEHQk+Dxhv4bM/DJwJZ+KwLTRkEym9iaXwaG2J0
0LZaMcieRkzTFqj4CyhaLTn5FgIaMehC8/AnacGi018wa0J6LWTbRRdDbG6zKTaCAwydqHsoSwm2
QzF2hVJQzG2sNCKkYyKirLhr5BFibGY7IdLZ2Kc+SZKMbijS6wp96Ccn4jsz+I3G3BXIkG8L42zX
xWRMSit8ZHF3SmSBD8mIbMDpFZvg8EnmayhUsCP7Gv2MUloHQnhu8oUhC6ZTzsYkXYpJoOnEMkkd
MYP0MSdOkRabYfQ25vJnyeXTDg24JD6QTgLyyXNKojeb3tGLd8dZQcPAvDa3BrTr5DJME9tE1QcM
VA5USnDXD40xlbLafImY+uULEkvZiTgClQ4pEiX4KqIMZVVcsotz6Q/q1wxizVrDHpdkJ4qlZ9GL
mj0hPl41bfL2U3LXehTovkpydc0YsbJjyYnaaGui9K06HRe4GHk4MRm6LDw2ZXI7irG6Nb9QvP8A
syrS9jfI0n7GmK+Rhkk0NBxaXMHhtI3K354EFSVozEfLPXEgup4TZENXtCY0S2IR043AZNx1FCKf
27PukpZJvc2G4AbljyemJMvBSuDb7QqVU1ihwVjckdnGDsQBM0Aky4AmPXOcHlsOlRpkl+Wiw6Pq
oeo33AsRN2CwsjSdGgvop/52ltudj1ofWkcdKv0a2n2FxnvJwhZndDNe7Gw3vqoiL/uh9lkSCzkJ
hdL02WG8g8vpTKiuUxPE6F/bmStRo14LszNtjyQ+AtaJXQJ6hxk2D5ECXmfB76nRFT/ARm2hJurE
KH0pRPR7DED1TKbpm+W+y3R7rYsXIeW/goQ2r/wytf3yDmu9SsbyQV7Oyp8HgGpm5bT2Pif2JNV1
RwdLgU7XQPbC4DAaz8CwN5rLnBYNfFRIUywoz+hFHklHdCsyJI2Fk2J5GiWDV2cyDw9Hk0pwX5by
aSMQUF4LX0/g1BP6Hi/A1g5BKlyN4J0NfE7G7x8PD+DdEyOoQaIabMBvX0V7E2hTxTfA6Xx9kJsM
XaRGnr9CI2ngSYGizP0EGAYJJFgDlpMWMPQy2LbAgrzDZ36HLES+Me9GZcCGTli2NYPZKOT4Jgq7
IvRInW9jkbH4IVtvlDSTWy0QfaH4JK5CGGyU2xkCg9WW+DYgJWx+hCW3piZx9CeIN7/AmGSi2l8v
B1HV5FpVrHgZPH4hy0z2WjwiD4yNo7bGByvMN5ab6P8AqApG/gTUJXJxC1M14HhsDiL6F73s3cMS
mms0pX0Z164HNpXowJfYkcKTGH0Ol9gXsqWSWJ3OkNAk5QhcZHSZrdCtRM6YItnVKgsdwZtMf3Yp
LZvtDPKliJRLTJ+x6yefooREq9mW/wDMznB/Ym5rHJ7xQalhL4GTf/QiQisI6hn0TWhriDXLIuig
jzL5g451YwMlUbcrEZHs3wYku8oiOB+A8ryfoLCM+jcVOUw/i2EyTTG62PIfgZ5Jxn1vExHi/lz/
AJww9t33os/kTQPLVFN7Lr4QxOjdv4DoFb0SjG7wJXgihhy5Ww3ZDBbUiOfvKfTaWgIYXGLhpcGx
JtMzKtguzQ1Z2KE2R+BGUkuW2tGqH0NzUYYdojGLyQSGY3gPLa7VYbGtp6YSUwwWx6BThMydSyYx
tgWViOaGqRwj5dJmmzQxkQNjaMjpceSgrSCxFyJ7pjZkUMaHg2ciLgpoLAvI2oPQkZISwNRefj+C
GDKJfDBnKgqmQtDQnZNfFNE+DVWx4wLPZRG15G4zZaRkzDKOTaNFpolwNaP4enxovJaLQ18cBYHi
smENBwTLNWhsp3Q8R3B1GKqSFe23iEwmuYRN1rEpRTwWZX4DIOI3o7QLhFL/AKEJjZaGKpvN9XB/
EqOsHAjUez18N34ZRIFhG2JwUjwW2IjZCmTqokdhhUPsZUYS4EBXCIOqLYzTMCOVWhFUcSdMfyQr
1PISZpF9VhnjCIoEMtPsWYCqI0ZzCDCQyoacMZqfqmcVGqMVJUsk5NlMh9PRmboTUfKR/wAXB4JZ
VeBOoQqRSNRhUSFw0gbUJpncTeiOJONNcic5Vir0r5GyJnZI39zBHUg71f2SGxIaMl8OsohIqMYI
meKTxRwTK57nbLheDbZpRfSKYXlYYM/zyaLqy6Zi1WioQ3LtRBEWbBF02/4TjhUwLlHrsbENnafC
QjkLxCp4heSxlrkapKOBD4r0JljT6+MjdLgwvC7E0ZBqzn6GzawXxWTOYMXokqwVnyGpJk0xMX9j
WItUic0zgNuQY0aSQ6Imk/JPWbmCF2HT0PUYOZ8Gw1zmEElayA554BcI+AioYRMWFyTVBM0uWpwh
u/X0SfdxPsYl9mKIFxqMI5C7jVS5QyJpykLUSSRtNsdUdTAwhD8HL4ND2smkYeRw/JHe4V2OjL9I
ulsJUrK42MhVrYuOx+DRTlfcLKL6HRUXwEjGKZEcKWSjJ8A11fTHPyqUU06TtIhJDHrmXDIfRMII
zM+gKdeJkfrloQ0NwU+G4XBSwt+Nv/8ALD2fwOEK1kpkvJDH2MuBOjdEbFIZQ8k+WqUejR5ZpCGh
BiMjQnRmXtCS5NGb8IgjbgkNojEiVjP9INZJ+/Er2JVmsjyjg2hjKbLYJUYe0MQnx8ViEzwLb6Fl
YGw5HCm8FiyfsIgaGYcJBRWGTCE7ohooVojgLi8IvG8mB1op95Fw+P4mQf2Ig24uBxVsSnI3LCKT
owRwYQ2LFDVymYjVHgCfnkWunAtPL0M6/qYZEzBgXBTHW3gldKMKeD0z2gklppIcwtBSdvIQpymh
MR6DVT6Hq280TqGhSGxmx65zycertGLqLsK+CqPuOMhsYmcYE/KSKFxMNHJL6HIoQFN2KeQkyuni
qQ7aNmb6EI4RDUTcYGp5Huxzp2JCVqaZXLFVh8ikue7rwWKXJgV9JsCjxqvkxSJcI4lJGKagktL4
S46hDdoxGoJRoQk51wGUiaWSSGB9OqjA8f8ABj1VlxawaKUGlyMC4WuRlLXtmdNeS8DWMK1ZrJWT
Km3TVidbcJ4pzIR8XGjd5hJYNFVnhNRFh0RSWh7EuuRyVu4sEtlUlhD7T2zHy38GQlN2CQomAnwu
EJm5SRmthgsN5B0/bB+Vb6FQxeBpFCyzOGE/QnAiG6MxLbWiJ5TdsM3GSDmFW5EQnnLbFTd18fT4
FpY+ZNqmRQEk2mD+RCHd0/0lo1wKLjKipZTweRTTmSQxnbqQ69yM02A4mrVTqZBj3UOZJw9GF9CU
Gfwvbb4h8WP1BgbacFLmmjPUfpia/gHIK1GYgv8AVAyV+kd+sNEvIth4x8GmJxHbK2NDZFRMXQtP
JkVtWiyRQ2zRtHJgbX4THwaFg5IQy2J5LGQ/HwmXI38iy0aY8Fzk8iVGDMws6+LENkeC7+HoT2UJ
8GmPKFUNXWyIgJfDolyNwVbNEhSkyYkQfA0IaokY8iXBIPJ9CfY3INGUNGzoXTRgHq8irNmIbQac
8V9iyzeR0JObIm6Icp20b+nGu18Hr4QWlyic9B4TzJ+QTZVU7gGTGmVb4MPgtfMgsKM2fCNFb7S/
4PTXQ5/hjDHSR9jCuxzpHcfT0Ywz9cjDwcH6Hm5csz7LELBQhl5MLUaYHbejAeBeho7LJvDkGLYi
MWDorB98sGJcJjSs04HB5ARBLRoLbRNxXcFEJ8cD5ZK+jMxJ5yeyB2YhCtTcRjhHEDrxuDZjTkfu
MKDTpU2OfKGr8iEvKCWUwUFdfIxRejU6zYEKWqYXCpNxD0Yig+cweJxYY1Uuh3EkOJrawSYLsso0
G3KqJ/SXKFp87Lk2YSscBRTiX+CnLEDW/C/mxY4KA12XDQ0oo3Sws5C84gYCHaIk3GytTSayYTQh
dtRGL7TRzI8DdvORnNKJ28ClsUa8QPy5rgmfO/ZBESUX6e1C2Cmr6EIzUdvlTGZNlQSWSNVCxqXK
HRKpcCLpsrMD1+kx7FX/AAKHMs2F5ODAtWDgaSNBptibheJPtdrLBtCHq0awoQeeC1h4HFcBMusR
YHFdLk7yJwYSiZauHQ+JVNh0upY9iJzi68K1OR4Jy+AtY90E9kfyMcIycZtI5PnkFRbyS4JSrJKI
W5siSHNIPGVOzNYXEjckRcCFrdsJBoSnL6aj6HipFQPgMNMfA8GmVRqTG3IYviayVlg16C2+h9Bu
mkULjZWw8IuDAehnCFES/OnoNj+NifBYJyODRBdlyIQwGDFseh5HhFc+JgWByjiQ1RaybRSR+x42
ND2JwaiMvg1CqQszao2Pgn4EQi+KIhuBL4bpS+ZhZNjgyUZUh7+E11g/BjsNpUSJ5pgPEkzlu30Y
1pXB5HGtRz2JFp6mMPNFfSFg5KORS0VG4HgnewsydYR3WXqRaJqODlNjKIqiVixkGsZ+F4JgZgOs
VMz6FZTlPoeHY0ZI30heaSDYkFA1ORvV1YknVGy51TGoct1kfcwKWxYpzLwiN0Dl4jI60uzQ4wkl
eDtOInFscbLoyZEERkdF1CS4SGCzi8mX5THTXPkUTETxqcw69sSYOQqRKffYunKyKqoi2dcYhJ9A
FoJQ8mLe2M02yop7GFnKWxuHCLq+DXAmnLrfYsdW02WKba5pAGGJ8BABcDdx2RQPtHkI2qC+C6Hs
YXpcCmYyky6eSXYtu9KjxpjbMjy7BaTGJvPFJbBkJZqXKHUtorGCSO5MB+jFDEySFbnIxBbpByW0
Ug/8FiPMnwYXSNrKyPWdi6ZEZhcbxRNMSXTZvv4GdpX2OxiUUpbfQLkaDmEXzHg5JhlC+il5UUM6
K0+BQVv4YiqCkm0zlhzCZG0qxZZMoW6cq+AXZ0horJaMtnDHCNanTDUrCphrJeBsl5XJDR6Dbm/s
hwav0EMbest+BcYYnRW4Z8hluTVIvjZvBNQFelLJtvgcl/MDqqq80aHSvZjctIv6XG10dSPhQNza
uifYHp5t28igBN15Ht1uVlsfNUPHgssb66SK21lsu5HNWGinBXmlYXWmI/dOTn/hdjyshdE5GzGf
0RfFm7G+RKT6E+34NwODHjFWhJBxMkjt8TmQnGihy8jLoaOMnA3TklZgLKLpMQ0MX4WEZfEF7OQX
/wCDD+NjaGJQsKXAholY3CIRweTiHkdMeEPt8PAk2NTbvw/4J9DLA8zPwfYiaGqU2GrQ1SihG3j4
SwzIQ4LwR5CTGsiY8P4TNfCWKbfj42x8iwG+RS4jBLkT4FqfPBiE5I2HTtGOWjewWCbV/RQJIT3I
/qmndfYmrR80T2TtR5Vl5Qv6+UnwNSUployz/ozePwfQWso8sgyC8jODoiYtiUmPAnzOuB5c74fw
e1HkhNP2HjQPgn6A9e1s6qzPIqJ9AxIPSKulTp9GBIhiFBsj0JcmhUcAH0ZNcszzT0LeyIZibXk4
OgkxAybN2JUq6oNZNIY4nWS0uIJsSpP8xHYfJk8ziCzD/ASNM2z8piEi8CllpORImeR5slMkGMtD
mChJtuxPKXyYOj9DuEvLG28KYrRnweA+yPKNjA+aftcGLJ+xpHL7ZYT/AAzhX0xXkbyL+7x/oAOx
RcjDBfoXvlqslt0Os1BJ7FfPwWMJ8+XbyYOqMTwJy3gWtOf4FW0zzQk9COSewhk/KVyRhssPq8Us
w4JwIuV5o2ImbGVR9hsRH35HnQ9MRXb9mWIjfTF9UxqjAyaWyszYoZvpmWaZ5HDNWGa1lLwWYr8N
iarqwLo+4x19hKXzgYpL2N7/AADpt0jgEWXlCqTUBBZbbdSHs+uRJIXY/v8AyVIM7J6i8CHBnSMx
w1dCuTvcM4ibEI0GrhMUXq4QmZbZkKT0VtN2Ibm49IUyMB40S2n4YIN0zwMCrvAtc46aPrBM7jHk
SUiMVrXZoQ/wCdqmHudeh6sp6G9x+hpDezGuTApTFjSG4XkZs6poHgtLghoQ3kb4T4onIkMs0OFB
IfxBPI3gl0M+CUF8CVFjG6Nmxqs6D1D38ZLogtCZyNjSnyN5JcmkNEmDgq9mBCPAiNkJbOKhKqjW
SRjycfCHzgTxS6+G50tpgJ40Na7MA0ktFNX4K2zaIGBMjIkDOtGuCiugZFX9GhAsqZ+ivp9Hn2PZ
kwyDUzC/aND1C4aag4b5LjCMCXJgx2Ym8kiILQ1EJFR7LBlTDy0XwlLYrAklJsqc14RzQaQyCXwT
mDnQ7Ai0Ne2ZBPoLpqEhyIzVEMfARzUZBSTyIbW/g1pfQ3lJsWUL1k9eiuhNe4xRbJAWoJoeU0XY
N90xyVkXIfUV9NCvNi2kPWFB700/BRUFLyNUWL0ITgu2YIqdClIhnMFwO6ifs43PyRXB3IhWI6H+
AmqORtCVlKLYQYR2Jk/gcEHJWL6PuRmieEIIRj8kZGC6YfoRlQ24HljKLXk5uNex2pMhsyDhGpZ+
hnS+iwakLy0cuRJ1b6IoxtDdwiMi6tvoX1jCBL6rA3dA2ZBKHl5YT+voPa5O4SfREgJrlyJEmq0R
EOnMDfJJD38jRC2lUIOPSl310NmHTVejA4ZbmRSYtQqozrgSHZzvggnquhEwcQuqzTNF7MHdz1aJ
k+rUqFWCZ1sdz9cCQElMbKqwtircMVEghQlj/wBHftfGKqsyiGFgiZvz2MrE7g9JJk6X6xKxBsSu
dAvqLBeTK0VRzObnFwNpNkZGuRjsbH5iVdDfsKbkgYvBB/pJRlpjfwWCVLiO9C2RbfYgq6j333IS
1TgcNDyLwU7FyyhuofQGOFSZI3Ofgh5FwLHIoN1oyITAnOByCQ/k8s0Q+xL7G0QJRjEnBuDdnA9l
IiPsWxjWKM0vhcFuBlyIn8NGNs3j5dfCWSR/DwcDQ1kgjT2MVaQ0SFTFse9mUiZFyxMPsptY+ETI
8jB+DmmPBXT+FMBI+xvJkNREzybTsBCQvHDiFVS9iQZZ+TTEg0NJnkXwVWEhz8lVMawuxTFosokL
PsDDjKgvodLtVEfLQnjGxGZBBhkjK6f4Iei5pGL0OnyoZWYPSW7wRyU/Uf8AHHV3A9CJ8aFImyEj
K2lEJqC53pFptvCEUnVphZrjVFs7WIR04xiLHJQJmFgU2HMFjZSUqhHY0/LGu+TGhabbmBucc6J5
xfQ1in6FQCgilwEepMw4kX2V6Q4yxmjeExJlaXAp+NrRRMJ5FN3mh7wipfUKFHJCOBJ662sVJUt0
ReSwhjteQlhXe0/AsvM3TJUqFcy3aOMN+UMhWaclJHok6B7/AAiVZ2L8mhSC25QIIUb1Si7OfBND
bIKqY8ieEOolGfEiokuF0LLx/wCCzJcpDTknKJaoMqo8jsTLI3EfQRSzq0KWSSfTGyix4Ef9oqw/
Hg8xB8iGGDlGnqqHirTLPdQkDemZCw7Q36BMvYv0znoorJahCQ7sATWeUfR5fCrfKlJLmBpda7HB
yi84MnDZf1kamLcPRUkDe7FFFChBnhpvbRlxcPJk3ttESCREwPiqUmCPBMzyA7FDBN89GGnYWhSR
cHFFYDCQfl7lHK91FifQXRpRPobR5HS2cGoEu0jRYS5ZhDoQnW0gRoZNczGGUqMHEoYRlYBvoRYl
T/SKjD20RM9N35Jz6JCNeyRkfw5fAi6V/wCDf9hzHxobhtPh2J8NCkFplJkhweAv4PIyr4Wii5Kb
yLZmFKNsc/DZpCofwscHsb4GkNGN7+MGIOTMvn5NzIvgl8ZcDZpdl6HgYBwgti+DS/8Awx0fg0XH
wf6Z9FoiGqJWJNitwYzWN4R24Q9YUsyCV0Itw0/w7W2cHQyJNNhurpNmXeb4FRHp4EG0F7TwMSsD
fkkTWmMmTzsZp4mb5WxK+xksDJ8G3R340zY3CidFlGr6LH5XI0UqE/RpUxbU3wG6H3o4n1LtDDuC
yJ+0hB5DwEF5BO7Zgkd6zwSKdhNFEeA1sLgheAOmaBGIfUXle0EhZmIY9umoOSptsWlhZo/auaLI
W1FFjEZuVjsQmoW6EK23pwARZf4P0oWJpVTZOI/iHAFEwDLJ6ZhzC47EN5JeBxID5AdndSrniEKN
Mu1s2VXCRnb7FqKvsY7Lp0VfbhMgdqCGizyF40hmU9jYfWrXjxNWztyLFNPwuBWkSZ+tTNjCappB
qcWwMttuWiTBtc6Yzw7HR/8Ab0W3MYFajJON8iRw6zElzeikueMjWND66pgtuZFe47ksQ2jDuGbw
bDti881GSvhwR38Dac0aet0V2KNJbaZbBiytFZ8BgCXMXgY8eQ16/wDyHnLZB5mTWx7DXkzXe4It
vVFLT6DHJtv/AIXpa8MGPq2EiuKts1sVRWH+JjLGzhGcOUKgdf8A0Z0HwMBp7EvQ9wY5WgvXA+Dx
SV49CeHiOqBimuGou0zZhXlWASmkvJGJCPtJHsxp7yMonVgLgtvgRjmdo73JXCOGHb1HUra5BtLC
eEQ/ykvJWDHRF2BjxvTP+CEYbsIq0sn0caOfhIrTboowwG6a2bXg0N/CNvHwMSGctGiiyNCwxNDG
QQ0Ew8McGhDoY3BIqaNHtEHI3IXBufCy/hoyewg9kU8mS4yLfwt0JNcj2nwnjOio0NBO/DjFo2iY
+EYmTGskzgQepCfBaEssk+GLnRaOfgVRtR8Mh68Gw9fSk8KtzIrKGOAXW8KbGTAtjNsv/QWVvBUh
HaIS5L1oVBt3Q016bg1axRMYwZUsKhjeyHwvJnXwk0OMSHkIz9Jw3gOSS4Hg0WvWiYlo7UIWgioV
YVnfTOdzdQzP4ElGH7H4JSGsLlCV1kbi7b7G/T4UrK6G+yUhvG8hzwgZ5UjgbEMMIPLkRnA61kfA
+cxGDxxTQIQlt8E1NlFJSVElPHY1NNtcCu6z0Ibi9nMRga8CG/DAfuNVmTUGpIQRm0BQK+IJr1GW
OmAHaGhSfZf1GL3BUeGDYlKvm1MJzhmUw4uNqKik1aBCdWwOX+kpTzY0d8GqNpzYlMnSDZmxjck1
kmm4CeIwsJeSEaolsPW1YkY1pUWPxUTMlphiWkrlj7JInFkwEVdmjs7M61/OSa5SRyYb4ETTvmm1
oatHocf6EWkQUh23fQzVgzghsucS6YgZFILftbHUpNAdym7wic2eCBBlofcpcEvBNVR3EjwyJTcs
rmR1LsnGRh0NUm20kI6hNZqzBFbJJMwB6kM5UHZWqNLlj5nYYfWbRCWD14JclSB/k0+jGNSYeiXS
d0BLOJF2R5YRXgnqEf8AQjYFOrTfSyxBETohHhUSHRawzmCRPR1wA8UcrS5GKTlQKY4gq46wGJGk
Y6G4DrPY1oKMcQqXeSfBMPAEO4Vlj44Gex+cZs7G5pijyIp5h4QrQv2MrjL6LYOIwCVjTyRU/Zj4
ExuckqEbY1noTfEJCmPnMENEMsbevhkeQ9fJaGglA8GYbRRqsbd4JBLJpCJkYXQq5NC+HA9iajcE
8mjNLR4Ra/h62JwbwJaHocaLgWfjkbpomAhqaFkaG4i+CGvPxl7+DINTAdKMyJoTiSYgUapjA2tN
U4bjbEBS9BbGzxeRrUpj37lxiQe/SJj7FkF+8KE1gdhIPXwO2nwuUz3qMjc3VMwtHGxQbjGhgUpD
JryUTaGiwWDexsbjseX/ACJDwtOeBrbXwPIKeXAxd5Ucqreh8iawX3mJWLJ4+mLZZfMjD1jfA9N5
OBbwMYosGYVRY8lkpFVRjJMU3DXTGzwqmACq70P+hxXExkPHAtE8qGgI5aqJ+GvQllg8iP6ohtTh
7XRFA5ToWOR+iZVA4/aEj9UJk5HI9jGZhsKKp60LMWFZ3wJUxLsZUdfI/cOg8Nu4XAyhJtqssa3n
sURu1zYMhbqlK6HsWHmRwoEjyC1abli7dbDL4VPsyAMke2wYkTvgPiv2PTcmJinWR87wC+8LFQqn
YKKJk7YyjumQRtfghWn72GPqC6INC2R2Yiu32GPTLsZchvV+SyZU/TQmZx5UQzPgXTf25ow79R6O
oLcI9ytlxPpgZnZXbY+jSlRTIWyjekISLa6E0RskR+SL88iRbeaIU3VeRmSFyEw9uTgam75Q6vdG
0sqZI8SfAKzgM76MsGupsbHlapeFuFcDWC0sqeTgSNRrjshLo0XW3VwOGAGxNzoEnpiTFPDbPSHt
MRt/Iy8mMoVpj8GCIwhrTSW0OqXRD1KsHJe1/BCwxKgnKBSiCXhoTSdGPJr8SIHgGNC8NCmQk1KL
HwV0hdELD6NGO39m+XzFCycEz8yPXxZMD1BEGYn2LY1mnL4YZIujfByMP+EFZg0xOD3R5E8ayOsa
+FBSoxKb+E4JRDQzYYSz8f0QxkNM47Hj0KGg1RPhDKPIwiE6yCUFaWIwQljJR98ESEhfgxYRtCvR
sOiM9irWjgHjBUwsNGeZpDX4M/gFgdwiVo9KPHcSLhG1a2QLI9bMCpGAX6iFy/ZDZvZhXg5TNzb2
L4zyMovY0GeGU6ZeRr2JsWseWNwMMWBCuiFzg2FXgNpSfaHlifgXtMzsb5NEYxvqkxUvA/TivBsT
2MZAgH+gnLH9Mao5YVK+kOTR+jDvDKCNpiusbeYzTULoY2wNoRJHUxR1EZ7ehDCpFoMeG6DKB2CX
H+CKmSMeuFBFOz6EjeP0PPQYsL66SGYFYr5PMHqV8eDoQW22hq7CftHWhXehyaL4KCfg1lwQbnuC
cv8ABhRlupvQlut9oxuJ0i5a9FYeDcgkxlijlB/+HEE6Nhpj2MzpsQ7XwMrk5wa/aDBNQ6YiME21
8GKjx8n4G5oUG+zBqdj0sIxHkdMWW15CvxuhdpMZK07haJVIMraRrfwa3e9jdGJuVky14hkXlGpk
Ssr00p/yIbuTY9ZxmHPgbAW2N3bcIQxqRKD83vLGqQ3iDylzO1LgzqzlSFTG+EhEUKQl7EY3udmO
9vAymCcF4on9llTk5BiwHazqDSQ8HCGiqvIalql7T2z71AkHHGRGw/wMpSzsdmuyhM69Q18pOEPB
H2K6chXKlgPHGvmF5BKtC1YU7As85G5pO+Qx4EGwQoxoymT9GslwLTLB7ENWIn18m8DEPZRjwUev
iViG3Rvg4wX4c4H2MxXb45GWCyyNigeUa6J8X4wyhJ9/Dy+CyhiZwxMEPDtOPjfxOfhpCy8/AkPC
RyMz9fGai5MdjEjE6h4gsOxhOGzTwbSLdEOBg8oplUWg3CrYvlN8kZRuE8IKFo7ITj0NqOBEhENC
D9H2sGOJLKLpKtD7wR1i5MowTOxGjVNi8h4C5CeIyT4N9jvhycOxFGHwOdDNGUiwsbE3wEHI9DAu
DOBnRUb4Stg8pL6GjVRAEGE0i6HfM+EJQsNoRbp0KnhBjS7M9pPsjjUCi1UuTeD5GTmmcmKUOCTI
al/4nQgl1sHn0ql0Po2jAwq80RCm1gSJ5hCJFHsXZ9hLkMUhLZI4IY4hYiHXWBIqWzY23NcDI1nR
iBtMuhNDElarhhyrlyJIlRdSwIxL1FA1mmYkXoJMgsii2SFjOMtybj5gYsuwTSN4XxCaOpVhmJeu
ScTBowJHTcYN0wXTHCp/CEsF2PgWSyAS19B+C8Ec50Npe+B8eTX4QHz9DmjmUNNpkrUywVph+BAN
hdJXQZccVGIYbISdtwhrN76G9wWxkrLImYR0Y2GY1tU0h/UMTBiz+jSDqL0h3EtzSEG2pxRdGLRn
pJQt1I4rSWjVrIEsSpj+h/eYoumsaQ6NysCyO0mPbE2aEK0qTtldoE38l8shrFoxa1NQl46xoiue
Rxy8IJW6xoS18HOx3XD6GZy7OHC5s7IpHAfQsE36FM8syn0ISKZYGpWb4JTSbgNO+tHBV21EpTKp
Bm7kSMvMuLGxjYVYGioc1vfIxxMsgvzaTiC2OqMXWLbDm+riRYQrAVhGZYMF8HkcjEzRocjXxrHw
uzoOBM8l5IR8VljXwrz8INlyNQTwM0zgSoaEhyPL/wDCyxuvJKZDUI6QjG4XJtmGR6FQ7TIk2JQu
DbPA9HHwlhI0PwU5GnwtFWUmc0Tyhr4MsSityYyRCdezL0UmMSFgNITSM0y6KqINSqayLnDgeJ8P
xkMQTGN8aQwmrDSz8HfQF9mjRFg0maQkvBolLBqjOhaPkhsgZd2Mn8G6N4+LIM0yWxfF/wDA7KT0
/IcdwRNVuRTCeBsg4H6gCgDG1cC4zYousBvaMqVTWcFqm+cssvrYq7hCy1sjrmgprbbcGvckPStB
XHYvjIoCrI1OhVjkOea8kRusvooPYjv4TIGWlx8EO8HZJZhNSGppyMplILKxa7BzAIpJyzOPBj7E
QcoTjTI/g15awwJ1VjCi0iMszFLREwkIXoWI9Ix87Gw/HbgtU1wZa8vJd+hadKdQihe0JmuQypQw
vtIeoLUCGxFBbW+ULjIaoqQc3CWgOLsf6Mt4hIEUtnKXG6JrqcJEu8MUVY9cEMp+CyBrYSyWFK+O
bUTYYX4cfor+B5kaX8F4H0MpFfkarFM2mIOeCGc2YHdTKI8P9P8A53Rj5HDGX/0ifIH/ANjolM+A
3bEh4CdLHHBkdWuBw0cmKk9LLn7GxUaK5ZK/CjbCLtbez/Bf4bPFT+J/ghw1aVrZm2EBo3JspFcu
RRlVYaNbQmySuRdPcBflUmbokoUaHJ0G/Jl+BdmF8c4gnJm1FkbzUjSYknhM56YDMgV6BGszInZj
scresxgSZqE3SDwIllVs9jE5Z7Y8+qLcDxn5QKLhSPCYEyetgiaQ216Gw8DZX0OhlqIZouSYJDj4
iHJSGw2R5z8PRx6+T3S34f8A+At/BvI3kbGjC0OsS9CO7NMa/FvobLyiLJRazQTyNR1FZGxo5waH
ycDyHr0Iv78MBJog0PeBcR+fhZKYnn4e/glKKmbG02tiyLOtDpOZZ4RUHjXOTw5pQWjRjVqyY3Gb
UFs2gSrMS90WjpwUoN5ycAFAnVKM1DaENKKeS0nwlseS1o1sSISIVYHoWTkarOgn2OsoP6T/AOl0
Hm4LNBeQYxYXoRe30MZWDzPBsuCY5vYSbZYY0Uaa6H4GEgjVNOofypNdD0C2VRcjq7swRHYNUmuh
ziWKCgU7GtojotYjtAU0LWDk0GRnN0Q25Jt3paIHnqLCix5F9GEpuZgnxdHRRESwviXVEoTmKxiE
W2LB5ESxj+XAd8wCZvYLarbsZG30YewUejrCL5HSitSajMjyFFv5CZ5Ma3lERMTqCq61BDT/AOQd
lW6Q5o1lRbEjG0YejS9UV2k9DnO0FrmVliViuZkoVwLc6FaS3GKWMosrUrH6qkVwm+9wIr0KuBzg
6RlTOm0iML4LGOu0KPE9aXQS6mtu0NSeHmSdaBMPCPrWA64auoU63HkXoi0hj4GtJaXP2YFb/wCR
FcSo9zL/AAQZdaPAviE7+HIThkz7ua//AMwhrIoy+OSWVOODFsn/AOxLKXMKZJZFwk3RZDeZ9iUj
2kMC64CcDWbxgSsma3NC0tLVIh2bHZNqiVIfuINsnU9+8i2uY2Nds1XQRhSeG8jFtfxILJFYqDBv
tmwfjAxRm03pCKSmjfZkmaIRbYD20lq+/LMF1MKj+xVHgzNH6DF9PQJA0MJRK2KOqnOaQmJ2ikCe
TrQtwg98idd5aXA1dUanBrKyI2TKYnowwP4YORwwaRt/JqDWBMy5IL4JR8y/GmcmhZYxgw8CKEHw
c/BGh5G+xMZB5Zhs2WMUeTkSpg/ghLyW1fEaEsF4INZR6NjDIdCH+Dy7HX6NmAjkaz8X/RUx59iW
SZHgyhGShMCGsaz8KLszFXU0tlj/AKKl4M0S4cDJ2+A8Pb3GBl6xaqSRrA3B8BrxRDjCxbM30Gdp
AiJMIeyjkzfAr+GYM5OfIYUMpyLROizImRinxPho9/DuiHGCJihWVeIL595FjMb9H2RMRjK8PAlQ
SWM4LrUnAhsjScOJdvSwIia0LOzmClnjWx+XTsV2rnZzMPAjiaF0BtOjKqRijPsT8HEliIda05sa
afB78YZh9Pk6Wg9ReYPmg+ymitwQkR7B2BRe1IUFrRsxNW0MXT4yGuRmRbBsXReMSgeTM8JseWXs
zCZDKjXKHjVWEIURhEaa0Gi3h5UuBg6UOqAyU8uwva7dQw70pE8KsmBj5R1gEQ+x2EMaU2Ox2eXD
Jm22hcLYzREmzCGHTY2RVMPQIw3oLbK71GMMSaW1ERWpvIp6iQbXBeTD5cnsyZux3pjhPAm0Vu+D
QZsZImEQdvYt0ya1oLsF0Zfc/ezi6xciWSKiE8lzO9kZ0zWDo4n4a0E1NkYNibDPhGyO/IvBLOaN
5HZyukGNHhCXQwmPFYTxPWSiFKWYjohkpuJhbIqtooVU20Orke9DMElSZ0bxxY4Cmjxphme5lEe7
6B9haugsaclNwfVBg8mwfthAb7NkmVpUQPMlJQx5CMxzgcoqE4stkwn6zoUdoJdS14hBwjE+A9JQ
82Pc9yHA/YCWkJWLw2eHWNi4wbyY9ijwSxjyqcpgMnUhtZZugqtCF8yWrtreh1WXvtFel5S6Q1t5
JXQW6Rtz6JjpF0H0eWuY6YTw04GU89vPwYbc8Dyfr4NX/wDA3WQ1gS7MMk0afwVDfy4/GUbyJmxu
F+aL4TjFn5ToSD/ZAZeiPIUQxaGGNISsYZZoKGOsVT+DSH/+MmRPQ34EqhwNCVGhi/JGk+xZQ8K0
TrI+xVhCZYpR6JnCEsa+F6YzdFy1SxTBOZ89izj1KtCB5XUqlptZwTXOhHARdowV+cCnqbY+sJ6H
O030hCKKWh8QEwtsZQprwCofPJAwyxjyLSWmmbHgNBp2PAkiZEmI0yQrsuiGr6F4LHWk4PwnMhum
sWBV0xcd36GEzCdctQgn8IqbsOq3aKTImCexh7vLHsbwxEXXwKur+BKtPwc3uVdkNGuxtf1CSVT0
2Yoz0aw+0OIPUUYK7NSK7HF4H0Ut7G8pSJDiizwP/YEJMo9Uj/WKD7k32JF6YVpYOYK53UWxprIz
H4BZEl4OVl4GN78C15H6MmxqRaww4r0bUMWCPyRjEvJYLnkaPuiJp0g/o2+2K3ACSEFQ8lbAUL9z
Kveb8Al1YfYjSHxByn8lmR86PJmvk7mHZ8IclKZsU6QYdBDOs/IzQMXS/YuxvKbENDyZMZBCpZbe
bS8H5GL9INMTbatyD++YRrFIsfWF5yo0OMoy392IzkOHf9F1K8WTVLdPDFTmwiZPDv6E9SUu2nnI
+nEwyyc3QhfIDAOcsmRLOsSVbPB4QVaQx8pifTiryOdgqljklfbEvII+2vKZhwvoGqmbeSoS6Ohl
fYNjpgShWC3s0iacGfd2Y5Jx8jVOv7Nhj/oM1gZbQ1fh6aSIU2LJt5GLI5RMcz60WyF2QbVY0YNi
nhimmTfskQO0PsVymwRU6rgkRNrB8nNmdCtAuPJyZKE0+JPJMFKcDTehMThk/h2jZLTIs/BoOmZg
1XRKsGD4n/4v4PDAlkyY3w2aHHxyZohuaGviYvA4NWF0I0xnA10YDL+EdDj4TgaNocmw30NVkafF
b4K6RtiQTzkyFU4G+BCvJgIU3zsdceCukKaPoE8gTYgYsVoxbJjJJVjYv5Mmw1BnHP8APAaFLrde
C+aDagckIbEcLCSuYO7SprmDnR79DdLIz+LaJBpQRJDKQ2zQm/gSsyACA33aOtRkEGlTPNrZbFBJ
ToLSMljwazRKU68G8n8LeFsaFV0/zzFraz8D9eR/AIPr2XEHhKkLDd9DTL+Dabzos8jtDqSSc8FB
P6MaZOAF1Meaio8VZsbsnkqBVgpRfodUBEV65gWEnbHRL8jnsER5HjRixpykKSqlaHrQ/AuYV6G2
egY80E6gcXNmSVS8moSwMtF2I5DWFEh5GNIM+hOakoSchAU3gV5EJ0eyw19A6vEPZnDMzQaVMtdC
/SkFSfY8mVByhsZNLyU5dDsIaZ3mGknX0LchB2M4FtXhhrkbQt2bXR/15G2dCGDv0VqZeoLMuKlU
YxISsSslW8IRVhSK2F5Z0GeOafJBTuN9CNGjCKQlqWGbCGqfQy9mC2cngw2waUg51PlPCSv8obDV
9DUsWO8+yYOpn0UKy9oYexejmH4cxS8j5DfDFM/wCLgbMyAiSTlrIOLvQsDV5Qi/I4r+5K+KmiNb
4CeI3aSQuvdZfR/v+hjTe9wx9eROkXptlwxnV1uyDm+wQ0tfgtXX2LqZw+EeDu6GluZLZ3xdNiyl
1gKxSXotHYxB5GQymNqCbhSEcImcDwhMWzBm2h7FTHA8CDeBZHJwJclyPY8Mb+FJBsXxt8FS/wDw
9jozKMbDUTBKoYsWhbGNViMrwHgyEyhroeNHA2R7+CwZpcGg+Ib8j0aG8CwNjzgS8jTnyvkIfY3N
EGTL0PWByBWlXyNmjgELVdF+nAiReZFJvgwmLHC1THFmBpP0GElMcGPjKfaQo7AmSJ0Jsq4FK2SC
k6iujOHY3Hox6K+Hoy2MjaGJRcDlFLTIbTIxoTgqUyxvuuxxOPkiI9sF9CWxgx9BRzeoPt5diMTH
oXdlKyLS9GXWaDIQFVyHgxpMaHtWbEnkcDmW2CaHDvKUS4E0QVR5gyy4YLLY+A40rE9QPaVcioSf
JckkPyxJs+eBs8uIiDnAlAnANe1x5RSlRoVZMnPRm10OXYTngxUyjvZaaGhDVizSxUVeT72NpqGs
HgP3sRkt8M+0kMYLuILmWoaHuqaZjlJoyh3oS5OcDS5lzwJ+h9CMzkG2ReP1LbnuKxEuasKQyJ8f
CC2Pv4qiLfgzkUvwRWHorjL0uCUzyaPk8CQJotFalOKGY1HQj1Xlld+kGUhuaQxKtDuxCsJsXLja
K2b/AAVRt2kxFjTA5xkx7P8AgRg86Hpaa4FlpORMbY5H4OPtqTjavXNFw5eieqeo0STeCjTVYICm
xPwJZAyhryQgm9TwLFGyJQ/aFIawTXjkWMsK3MUnC/oAlQl46Fc0oQYmxKLHJdIifHIhrhSjJlQY
cgVGClwyQMtl8QXu6zZoQOHjHRSSX/wTTHZA9D7f4XhLIUJH9BH9ShCfC9g6O6ZaENxrJiLZLyb5
LoFdeTc0VrLNZQORkStJcHI602HiGHBMQpqJq4ZOuQLQ4dfZNLOsfB0Y0g8iwgdCVmWHWY3PwvJB
zS+Tp8IcX4SDwjIsG78IaNi+PhOjfwsIo5MBDz8Z+Kg0xMNiydCj0LQtmRlPjRtYGYhKGT+EmYGs
fDwqTkl/CGNZMlokIZKbeiR4PJ35O3gZA3I2E69Ba9w53UmY74+P/sRCrpbuJlLJYWVRgRIapO0L
gWlLDQl3mBeByZtz4Y7yIeTAuxMCKmEYHQoJJaefRLTsX7JC4vCNUQ2hJWQc6mbkm+iHrPmVDZsm
bwTWJphoXG4D75vgIqegXBRnAnpGHXQ2LHoM+ignXUpsRt+8GUimwxeq9I+weOjWJUZ0hhC5i8mh
eyGtBort8DrlPOhy6FPNQas15KVB5E9teI1OFZqVaCbJfdRJY74Y7aNjJ4sqyxG5Nkf+yEV5g8+T
8hxqceTKPZz4ushllLDstPlwUp+XeRkelLXQ7NYSfCyW4IfbjY/GGKKHxHA3JwpsYQSQqbueD+eN
C+2bxD+iCpCxOhaaKdBHHLBcldS+RkIXuGOJfJomOULqxK/JuNA1JhtaGlrC/ZTxMPBqchW/IZM7
QUntmUIVeLQblbYaSYlVyJrbry2L7/8AkM4NFVPhm3Fzga9tsf4MWd5i9ZhavkRrss5HhlR8m5p2
KTZ0bzQyghZrvtGefOZ0OZqIQt0VsyWOsfAayajNvtH8sbTldMDB3BBxYLnkrcLOepyaivEqoXJC
CndX2Wa3+Ac9vJLkbmTyLHtsRs9In/wdGaPMJmE5AstO5T4GbY1Gm2x2KSa5LK6oOgZansULEi03
AF1fA4DtuO7M9HH/ANGcFqJwWYPhw8Ef/UcDqYl0eHRnIVGUGx5LWOixkY/g/g2hrBTXwajL8INf
gsHsbgowQ0+BCdeR4HoUfA3j45+bg8ifw0zBI2ZOgiDwFvJS0uhPL6ORMemMLDHoswJ1DcCivZY9
DdRaMiEh/BFB4hRvI8BdDFkPQvoz/TaIy4aFgzjAmVcrkWHRkzBDyqT/ALFyheuUkIWygbTy8DnK
RaRjV0owplw8vIyPrcCK6ClbTHL5WRJep9HA4zWHEUgUFr2ZJsIIxDDWaWbGJMSHeRIVn8EIIC2I
aWrLfAlO5klAvCvEWCfgK23oc3rIpxVVZgrxCh7N+5eDh9ZGWYxei2KyvsYhbKM56/4JAMr4uRKY
eSbIzNJ1hCQjexbRa3EGpJ2nyK0cxcEoksHRU4NMY/tILbWTIBpCK3k+K5lbfI75pOBksitW35OU
YgqyCs1J4EvawsA1lVAUrG2THGO4Gs8XgadyeUE5EnKwLUi0DM6pBEsukiKEBobXh8tjxF8GdC7L
gqxINmPO+0J0TFt8GsRiC2Tr5FO0jN2sENNyvxNaFmS6LYkC60coTwRhbHHeixikmEVNTQySkmjH
Nk5BjVQkfIj0tGZtSyjWKrR9KZiQuMLdm9j2Y0iJFq3yN89FUF4HQW8jK9CVw4kIApkeGxHigCGc
LEdaMx4s1/BqQqc9Cte+HwQ2b6FqtFGLx38E2sZlNje6OAx33Gkw8jJBw0jaX+D1/dGqDwPqC6rG
gXmdCGrPDuf8EXlNvOxleXy0ZF4bCCnTwM6dQZWrObyKGzUFVR54Sy2UmbgWA1ocxJsviJ1PQuhJ
e+x1N15Doas71b7FOElbFIy9oLqbS++xTXWZcCNIZ7Dx2htwitaIXwNmQe1VaRrgAKSf3g5FRILc
tgL28tsejgqTGzeMDheRPBgyoio3x8POTI9GhPOdGYTA1WRoWhb+IeDKJIfh8muB0eV8XBkWOfie
SjWRN2cGCmw9sWX8QWg2NGSwcmh7+CxDdyYEG5RBEmyY+NCV9GxrQ1lTgmfhSjy8HuLfkcpzkbRR
pRCw2GVyOwcNayYUVj0RQ30TFhulAruPDSn5EBlOMwKpcsflyMXUj+y03sg1KJ0s0Sj/APCYwAvV
NbXgnRXSKLVY9vYhDecDpmA8jWB6xYW/CwxFHaPNWGKKKaORHM3gy4X9tzTgRFDydYtktswZGsWB
urBnuMnwJ26SBnetTaQyNptDHrjWpyXcPRxcS5D4kJRRD+iEmi5pRfcCywkyJGGmSGZuDP3CiYfg
TvWtj76g0x+Q+JYbFxY5DwkK7HBZcRZL+0Mq68s0j1dkgWssJuF4MsKy2PR4Gadi7UqRFpEvjO0S
3GNGSMp2isR0ogyp/QwYpMHFw6IGrgwR1H+J8L0LEA17ehmUbaGgTZYwfOmhjf3Dg7dVMor0VHJ7
rJM9MT3upySoupYLU3Ow+KzWRcVbekPJI/aOokuxb5oxkv4SVy8QyiKypg+3gy7Q8RGLV0O3bTQg
0I0H2ko88DGillUwTBLbyIUE5aJ9jc6nQrvd4Nwyw3yg8syvQ08J1PioXTS68jBA6Dc903KH1vZB
ichflSPgIdOWPaYno2uTJ1O20I2m/owt/Y5Oy03gaoAw35F1+kMOYC0ceSIswDtBubZ+BKoUDtMW
b9ggHLOYmMgSEHLAchDeA+BsKUJLpwfQoOx2HKD4YvC7rPK76F521mxuUrbWLaR2JQOWg4OnrGOt
4oYxt6s2y005BUp2E4F1wcih1suzPR4L+uNthXe6WngYuiyeyLXm4YcN+kcq6cGQayiQRbSVcnL6
qrA82/A2xRiy4UIRrYqY9kHooiVCyJWdDb5IWseRZfw+PhKjUY8IWfhOjWDj4XEEaKbJF8bZFgaC
FVhr44yMajUJ4RSKVJCVVKXSkGqaHDZBGLY1YtmX4NX4WUXiCEj+HJBGHciwsicdnaZxlJk8mjKx
XvkWukEihXXtoqGxOOxtRuiYdHDMI110jnHjA0HXE80y8E2TNeyiGkWpy+RCXHgyW9xBsZ8iBo8h
r4b/AEayZpsbyeTBkf8AtKFSaa9hdfdiu0JfYsHoA18jumgK6RrPKLFGHRkl4BM/uAxnu/JHK/IR
UkE1+wLYdHQmRrBrYDyNdGr6ME/pjuzfFEUyeWcqvgyMl7eJyy7La9MbpynsXkbE00ayI34CvnXI
iY1Wogr9TJ7SQjNKmL812OKkGzTNsrCENWPsIqxL0TVfYrJ9QTkzcC7B4gjhfZtB8mOv4bVMfY0u
xO8ZKVPURLk8C5UnUH5v0N0pqj2Ks0Ta/o3I5EGbSr0KJs7QsDIi4NoW1+3kToblIT8HlEBjr+Tl
sEUCxacIy1iywHpmHBaGiwUWcjpqClKmRV0uxYHtpqaGa7pjxFCKmnLzg8p9IuQlwIcVPk2Q8jnH
gfiPKkwLEsJRtmaD9o3gdUpTGxxxGuBUXjgcn8BKf2RBUVVa5HRCYo55FWrJzRNHvlX4E4+zmGNb
S2JNQyZH5VCqLI+hUpkc+iYtrX0GLDT6ITzu/YumK4CsjSx5FSv6v4LKlax1SnLB0KSdabHlYrOD
CjsKycETNpuNizCg3pB7MCn3CIpVLwJear1sN7dsTqjMN5G3C9jz8mEYDKzwQf6G3zohIWsCTHkI
ezI5oy0mRrAmcmL8YUTybcMIacE02JRZGcef/wAC0MeRtDD9lpcmREvZzBIoapCc9jVWBijYMWCx
aYaJkexvjBl/DDZDJt4HRwNfB2DgWxvBRB2mXbkSp+GINGMFOT9Bo4FyPSkovAvJblmPtBaEhmMn
8SWiGCrCpqJvBJiefwYZovQak/UNeyGHEQZoqdHVgzBTAbo1gbg7saBvhhlhqDiIkJsOB8+hNZ2L
aKhtt5Meypn0KWpi6HHYLZKui4CVa8EMQJCEmgwkWVpox0hSVbMeXtDLeAuPLYnxacoyyvqXGC/g
jRPyhlhdwaG08DdBnXxQnpQ7bFPwS5bLBcjel0xQkMevqKSsjfRNt8+kMalvwYTC2T8i2RLP+inu
MRHJDWfEXkUUi2x9VZwkc5CCa3I9zbeR8SDwES2HY7AWaFpb2zEIZE9JBrFmaC4uNwMNWuHEIR/c
h+GlbmJfUhr4+hslvEYpfwYcsV2mehSJSmMpMHQPjsmo9iE+GvocWVSLwpCJVNvhHvuHhLQaWqtv
Bqn1BONsGWEDmaG1Jd5sx5BJ2eD+toSGsMOJS6g6xH0c+vQ2cEq8D2m6jGVR5LRrLgWVIrY+zIYZ
GGBU8IoU1m+C0adPoUbKEtOMsNeBl/fkYWI4QitOei3LHJDvB4E5V1pwtDoKQjptwOldIYNcw5tQ
30XZfIT4sKdk/SiWBjfxtwdENGakN0pEKVXQ49RfQkNsk+hkzeOwomxEGDK7cM25asfMrTAQ7owP
/SxLcPRhTNTUzZ8wi2PLRjPKihA+LwMccHnIiFFbJCGtyH1RCvZGFPsF9Fh42LyCDZIG0MuBijpl
7OCPr4sGaCkHSzY2bjIX4Jk5GsbEocmxJn4Wxdlo9QXgwGroWzIwDxgsQm2yDCeSL5ZNvii5INwb
T+Jlz4HGYbDSJm/HBpGQ8I4E2Fs0NjNMmMnBnAn2dmhox2J4IFir/gsEGyVCGSyJazcNAZi5KJcD
GU9RdMQUr00crBd3hYIncXB2+IaK5gao/os3CS/DJRmqY5YggOQk6zFYT44HsetCRo3gZwLQ3Zgn
OR4eGIPbeQSUlbYtFTXY0whI+RBtLOpSOFB8a8xThXyZotZMzxj1t50zydG1q1F8FD2kA7taLATo
tAxJNpTBg28rApMUDoBps9BCbXLkSl2WMcCk2uw6iw28QOiU2TFKSkWkRTlD/pwUUxbQTWnXIrJj
cozNluJjjLKHEfOB1olHa3eVMhOlDjnYJMJhT5NGOY5MpF6bNQZCzYUrbPhmsxPPQsJaQq1ZEhBi
k1Bd3YuSVKbH2NeCJF7g0stq12IV3wTW1KX4JkZTUSeuU8lkHjRCRK060K3Gg5mMIli9oShRW2hl
lF2o2OF6ESamuxuIC2w7JDEeCoXfw8kaybi+SsvZkiTKaDbiQkUlWB/9oXhaSpjpnWuzaEpwVZYZ
odkZdYpOEvY1+xbEZvwbUH1RLZyHSpKMmyoDfwdfK1syGDlNUxZlXbSDyiMYoEa0LBGh2JS04prE
TBGngygi2a0MfDN+xiOXATEhhwIjWFfp9Sg2rGi52JhXCSEs1drFOFumDPIXDZC6+G2WOektpPyO
i6dn0HVNiNSIxy+HTKYNDCQPMQlC3ShTTA8BqebYkJNMrAiTaYGVgw2KTt02MTBRymWWED2eBMPS
4iKeRpdaRtwckJheqQ3VqaQnwBWg0MqdqSsxPJUNZDz8JFwaEbRzCcEUfInJMj2NtnQ8G3OSQwN/
DJuGviUfkYb+GUNfvw4G2iinkU2IcZtSwsHD+A6N/oQyDyhDQLCEs5G8HJcHJMHHxbjGnnJmMjux
fI0djbOBh+y1fDTZwhNtGDTHFNxsmcH6G/kTryT7rYXC6PFoSiaH/gyriTpnC2Fr6ghtx9DJuljP
AvUgwVzGabdyY59iXJmCWHyQtqOvhrBscwIdBDaiRiE8H1CY6HIbWhPHYxxTm0Mzv6M21yjq6cC0
nUUJWsUK8Ql+c7pnfbFMBWtB/wASY0o23swzoczNsQ5duTFMSoltlM5LLCLBMuoSr9KCp5vsy4lg
btC5YH8ZE9iy2tZp60qIdeEkcjG2bh2hLuStCVNsQ0x6iRTY5WI0GVSlfoYkoYewtj/g1A+PxoaA
a1MYt0YFTqjc5TI8p1WTQuI/heMpqeDx80NbZMZjqK0a1kvLHvKcmNc56IJcuUXl5VvgZQ1KVHM4
uRxJC/QGPlbAwuhsRUKxouXyLOM9jP7iMFvYTAkM/Pgtz2IElxFJDP3KBWLLHcnS5Yiax3oSxzW7
kTD4BHMegxYSVOG6hUez4IcNUgh6znDng5u7cfhQtjO6lkAX9CE0BtzwceioPOzsp/8ARgwVo81b
KHtZn+3AASaNmFr8/wDs09UJNibn9KFcD2rcnlEdB7hUhUCA6QzzqwQluLMJLXFX7CPxpQjqKsg4
JfaIh1q4Y9lmuw+F1o9kVrVOaNeentiQx3ltF0ZoIMrVPXofEua4IOKshkoRaIwNYK6iKtxP2XBz
TwhFeG+RnVqqIsZjYaMWNvy2I0cnlItiNzgSwwqWRWHwJjsEoamvRIiMavw+viipNZMPJeAsjx9m
gk0JZNnBxIJoK038uEZZJBaNoLDHsldZRiiHg5NCQm/hbOTkexoWS7FoxTTGsGlF8GoZbIMe/gyZ
G2WLyWCFKSNBqslOTXwfKP4FrBfsb6Fo/kYl+HRC8coWtmmRemNmMiRk9dCwapSQlWwhuo8sjiy9
j2lNizaGveYLztN8mKxZMdZQemhh7HT4qYfIM5jePjWexrY8jEFyJ/CiVMsioLDIhzeyFr+Uy/6K
xrtwJXK6mgMk4iQJgCWFp8i6vJDvTaZSkbmjzIyi2wUZaPiBHbDqiHaciweS2RS4CxhOWy9QFtlA
+8b4Y/TSPaGpmZCV2XyVwNIRYil4Fd9lvRc0qwR628Douyw/YF6hWUVnLTEbu8soCJYSQ2rT8ipf
QJuLoc0mnZbtKmCHtMJk9lrkTZ/CEl0VsUslgkVpFr01KJ82w2JVlOC4C6QpPDkvFnYoUCGaIH8I
FCA6eXZ/5/I+4bH9C5TJBj2Uhm3A6bY7aIfDsMxbjEL825ph1cejMTyIkiwFNENccjm+qClTyicS
OB+s8EIjW6ZLv9FIdbS0QqG3w2OCJ99HfMmhRanosi4nk2J2RWA8eXVeiunZmY7H8BApNPFkUmaP
kiFljNjIJU2qXkWo0TWjIqHoeBmpH0M2QPiDnbz6DExteE9odSRNYrezrNyD8vPYnYzPc0dMaciu
cCQdILQm3nIrX8P/ACLbKTtHZ6PwJjO+Qxh6ZHAY3U2JulhaP+sSJKbrBiTocbSFp4NMPMkNE9UJ
TeNFUUG+i1zFNsaoaniOOD6Oi8+xaUtFLs6V2rjPkemxo9II6nH2VfthJ6NBfclUaWats3dJnk2G
OGaN7A3CjegcWY6VJbCCWhGbK6oi75PgxAB0ZY3No36C07ZwvZAY0Z7F8DQYTJhgayew10IcBsuz
jRcm2WDTejKignRwYPAiGChkM2+H4EwIJnI2PQsDzo2EzkZtDkfxvRhwJj0XBhi0WFz/APhILY0N
mAw61szBKIojb2YnktOAscXw2cE9BjYyZ6GWYQHGkQWBN2XT4OKIGsl8hci/keBMSHHRs5FyQR1R
gQcyQ/KARx6nA1MlQc147NLVISpK1Cc9GuhcsNUIe9oUgys6PbMj2GDE4OvHw1X8EsGGRXYQrdAQ
xdjI3VHDKTQnOjpOBUmFG4OtNeAQ0LwKlc5mqlsUmKhfRN5G8/IsvJc8mFcLwXWHgfII+0YGr6WC
jPXZUjgQn9jQ4+YI8TIECQWUwRpl9iheOXyRtJb6Ga2cJlywgAjSH/GpnJuqYQpFfnsbnbyKbXnh
iBGrsSFfJM9pBhDgmXU4nczbJb9mJi77IclsoUm+BVia8Iiun5Q++UTKVRtthgo2kdojL8PZmVhd
yR+EyIMMWC8D10nQcX1jsq5eiLgmDFdudDOmwvhvucw0jocYjTSowRp7Zfp3kWcojiizHsCU4+Ry
UHRoxSetDOgr3syK6vQ76/cHaD6TEc/t6HjcuZ2t26GSSrwTtHx0QH5gFkB8njmIyPtIyhq/pxg0
Rdxjw63Q22hMdzJ/56ZlYb0KM5TbYYhm17+xkJfSmAniJ9jDqrTYQSD2FHkqZekdoR2l7GtTh3ht
9tmWBIhcSF5rsjrozGhnL8mPNOYJW2btiVV08HqZezJuPthib2Izq4IrCdB4CIPsG8jjCvbyJHCO
6Ld17Q21YvAqo2pdUlhjfIf5g4ThNM32P4XKOuvs3Ts72Mxl5qGg00y2seSwk/v7CezgZCWy6/XI
RuvsKOB25MlGUU4Ee3qj70EZr+DDeSY8j4FAmdDyTyKREUbot0olnJ6LBuiR4Fomfg2dDQl+HJkn
w5GsnAxOETQnQtHA8CsGJM2PY7oWh6F4G+RwZQfItH+nD7GhY2NxlwcC0/jqKHgQaMQpHjkqCdY4
VCZhlmh6HOx6NLYgc3Mjdbmx2BkzP9oe6ZeUbIIX0SorJxpuHE67EtQVlU6J6y8wZ9jGaypS5LA7
BBjZY+FqzYfM+OxcilNDiG1DLkWHsS0WfAnun0P0KQlBDHeBKmqRjnAT2Gh9SfhYmguq2jEN4vKF
r09ITlfoJlvTEPRV4H38sn4V6HW/yKK7IawfQloohI7+haE/5Pyig/wQ+RkTezdg1iDc0/Bmlh0O
zOeBTbVe0KovwVeHoXrV3DQ0n1BpGBs9BkIpsZI0vAf6MGuqXEQmqJ6MlM8CBsnA9h+CuGB2qZjR
kbBQcaLK5QsSLoext0RXKzrbMaWuB40nQ1NMEUe2UFKJ+hSspYRhWw0hVVEh0oGqW3g0GRb4yrRi
WDcmDkSOpoDVOamB/eTeWiLeMNUsqSMIciE9Id49hnNCDJsjG0W5hnW2bMU+CBbgo1lCvQ6E8wWp
W9oz3v3WXbeDoO3b9E3sMmx+ENbeSngjk5gQy3HaWZ4MNehGxSSywLS98DxO9UbnncaGLqWCVlpW
Q3MoXVmm4JJC44FK1oyQo4FxBjt+4X26XoPHvHI8V1YSg1NZRkwFDqRYhXJhr+paTQeaGOOwV8fX
RJFZuURRaD2ymDPEy8tbIy38eAuLHCTg8JhDLlBkwhNkYtyhkUpxQmyeT7NYOSnpCDTR7ENo6RCJ
lboM7K0jqGbvOCU6EsCZNcCa7OS18DI1MuRiR4fCHgQagmN5x8I9GWJPY0LKEsUTG8mWPCpvQ6zo
NcoaYYzwMSybGoaORpipkIQvAyhrI0cQ2LyYHeBowjMiwyNfLCUx8LfxsdDNDNeDPgatQqmB5W8j
SYJ0ZjDliJUajEX9BEUivRhuG43CAkTFrtWja1JBiw1Gk1t0NIapRcRUqCpISvKUEpgl9ZVEiUaM
AnZWNw5F8rUSFkNxlYjbPJDqFRSxsZXQ4gzLvksko2K54vwVSp7RmFYyhbazgrKhvbFvsD+nYOZ8
B4/oXiYq0WJUSeafEx9yQoDRPtowu2ag9Ex4Gaim6MKE8JZGxItuF9CdQw+MJYsDHmGJ2K79CxPO
Q1prZLZaK0kDEYJa/hA0JKnND8BpEjnXVROkycvKNOvoTOZkzR+VjLeckXFXwMgT2GVpxEWFyMrM
cXdrsZUKJoyl0PIwH7s8GThmdS2tFBYLfsAXCYzImxr4iQxT/gHPVZKxcHlik32K0zxvo3BFApR+
ej3IXkHNhnODPVdIWE+QtDE8sQGTmSUSfQsW6EztVo/4RIqYGXGGwAHoqaw8GQNsnYtZdjfAwbPp
CFg8cCTQnRmBW/xHn2c1yVmXIiUIWL2OUpi8jGVIlehdp05Cqs4tcm8FKkyJXCnoVCjcHPCtdIeK
+ELto4ENKy6niDkWTtLPsWZNoyMYBrDARR1kbf36IcTZEn/oyNTyEH47klPhdaLxlYJ7FMYy+h5V
MxC4lbnlmxJHHI98uP0R2S6oxGpK8mSxnkxxsD0nBflOgecLleBPK/JsfJ7tbSEOsJs9ikzx2mIy
nh4GOuVpjOcpjqL0qLicByxYp3OYO/YlLHaDZPKNTX5KEFYUMUuF8BquIWIbfXl0Y626hcXx/wAD
2Em5dCEpfKQg+GviMdjBF+zeYE2cGg3Y6SSgNQLTbY0LBPIlYFv4RL2YpM4OCs28nGxog5YykGok
UpYam/luifxsWGN8F8LBz8aJoZWi3FGMQyjYWTk9BmhlwZoqZjbFIUg1X6HoYCJ8NY8i0P4Vxkz7
GWHIngbM8fpmYHs7ETFqDdvAhNbwPeeIz2KK7+8UTqRTuhsbcy8C2mmFjUc0PU3EEpkTVJRJ4P6h
Fh4Y97KJWqH3Mija2ciD9jQWuoiZGWGGyOlGne2hOPKFveuiVuie6ahnOvwyaoCQg12HB+8XcD8G
JoMMBqnsW4J/DEoCXgW9T0pTwjJKQeh+QPLavIrYYV5UkDC2dmGIrgeE8+RTZnYU4WxSXNX1SSre
VRSk04J5BQXDk3Rll2MoEBKjehLjQx9AlFSIKg5ixliJ03WT4rGJftNjTL+Yp7e5RfzG5Wx6v+gW
xjpUhuiT6YtZpxohm1oWBOaKHqEw86GAVAsLgolzWxpRnAqj3AT6FKmP6Yo5uycPUx8RmMoMlXpM
avtPhOZJIxc/GN/CHHmU9KMX0mPVMhjzRbMXEv8A6XwEmctozJOINY7SzQxN0cZyUONpZPEA2N2g
ry5yJb4XkR2ZnSjo5MTLfZEInL8DvcNh/g1vOQxGEZLFR4wKb6YQ584JBZ6Jouy3D7bQ5qaWUINW
3G9nJiBcjBusQ6K+v/oQgcjFZ8BYqkrRmabMeuMYNCkbHjuJu0dGqemK7BjF/wBHI2uvWweQJCZq
9grdVsZISqwRNLbQ7oaxts42TB7kvDkotIiGCCVZZY3foL0NTZvbY8UjVbwb8uRPYiZP7C3PJMh3
XXiWy8DW42/WTTo+Y6Ywo4MbpkTL6tkmHvlR4l0Vo+8tuEbRYkWLWsj98bX+IuZxOxWeGfIWb5d+
hEPeiMeeaS6CEuywBjguTfwNlnxdPItwe1CiW3w0L2QaHYsI6C8kNDaNjNG3glQ04ZXgTFOPklXx
PhY2QdfC8lQ5NkgzTBHRMh7Mv58l3HmNCPBPhK/jkexlB8C4ZaxMsIFzMs8ku8jWE7NBKNTk47Gx
3ItiM02SVtRI2ORi1yLSpJIUwkWdmEs8DVrtBPGr4ajncIh16MFM+wz9IFTRbHrOgx9dHO0yLgpt
iUXkWjAXkXfwuUI6GL+m+8sf3CEPVeBkyG5Nn+WFck1WBsr+xihxGYeytWlcJiUNFkbp8iTRTZ04
gyNY2aVVOFfn/graklkd6BliUcDpsgSsK9GDlrIo6q4LUktKH7kw2zaE5jGWBQqYzo75Q7rNCNiB
t6CCiRTVjJt6Po5oLtqzY1HaUeystH88T0I1MiNSd2iLGx0mQH4hSmHst/6PRKo1qkzGI2GoXirk
McqcbwPoZ5ZEkCWpE/yFyeHoUxwBJzknMYQo3yG+mXSeQs1Fi2ikWZVCzcK5PwxTfxInzy4J1H2q
O3D6JRSUJVLmDVijOjFwduTGdzcIOokLfmbGSe5JDssy/wBPDIiJb1Lp7QVzBz5cSxVhPPLJrBME
G1W502O+wlZXYvHOzwVjGLc2FuDoFYbRagtNmjMy+wihVWhJ97lxO1FNL/gibbUbcPYIJWEQxm1g
7xx23yNdGPjlHKcZ5voKoIErbDnAtC8LKV8lnAbsmJtF+x6o1jRTIah/6GIOsM01MuNXkN0J2C5J
Xsa1bQrSNF2NRwuoTKTLHi7L5jSEcMd/wsroDU5KmKTnKL/phNL0hjpSgmkrqOhYJYaq59BCW1SO
REPb6GVpuUMpM30lwMeZRWOAzJv6FvKvIppDSfgYgVvB7Gl9igi7N4/NSFmwiI33MkPB4Gx9HM2L
+EQaZP0acptE2HUzAg2+CCiZYmeAg3pwNQTGyM5JL8bUFhwfX4HsWWjkkGbGpyN0WV6OCU2zkzSP
4SwclNiYeBZZVLEPnkapMCX4Z9CbWTIauEo8My+EuxiUg8Y+JlX4ZtERVptcfHDpYTGujFRpoMq0
EU8GhmjSjEzCyJX1kyFJXkyV7aeWV2MDu1W2DVgkTrTQtk8UQtxgwpW/i5Bsd5lIzGU0NHQ2h6PJ
wTyciaYw7iwFpU8C+1XQibcCutgwU55Yj8ymiFnHRgCjGR24DeCfKoyIpXYz8KQlvJNi+tTChcxe
xGaGwmgpq+OAyFXzRxxO44FLkCOw3higl97AlydyGBT7E1yuxGtHpsw29IGn77YQo5F3yvLIxPUN
Zoi7TXtCS8pcnVg6Zj5jsQglojGG2zDTGxGyxepyXYUE4lqjzr7KQwwts4m8jmJ5I0KW0xbi6uTF
ACDZW0xVpdMdJR9joP6BqmyGW7CnnJ5WN0OLuqTkzVU2PJmUbgo3S2NDiXQ0GL8creh3wGJoz8Jv
ZWzGqPZi7ZCQ4TCZkDeWN4nVRwLaww0XX8SfkP0Mdu7qG2Q0I8kKQcpJijKJzIldNlBH1mhhZWRA
vDDNQBZohhEO/NJx9CikqwN+yYXZFg+wf7jFgqvO0YptXPBofZBtSZZ9GUrVDTCcDdYV0Tnzoxwx
PIvfj+DUgxtkIzXaYt2hRgNr2yHjUINvpRDKljzXBJHqUmXUBtJrIERynIhTSzYa7bbE1kUUrJyN
KM1LpIRV7lb5FyqlriiExObDK7ss8imwUb0JyCAldMpRtt8lfk6zmjG0y0sHvIX7brfBT2zdGKsg
bFDdmOU8fQkgMrTtJjIMunOh8TMVDdDyYIMvkcs+gkI9WeJ8GphcnjFocOK2IDJlMkO5al0Pq1nI
4VKpXAiUYewbaN29FSdvQkrbplt7bMkO3sxMSwTO/jg+FbRpFz8TBejXsWNiNlHAsGSolyQnA1Ba
NGYL7G1RJkrok1kd7HkS7NMaGhckHgQ1RoWcE+JRJjRjYm2jTyKmZIXJsbi+F7PBmhQSrr4Ro2No
N0LK+M/DSwNIZQWjLXQnAb7FI10OYmRyqPfkS3fqQfRmwmz/ANMMz8TdCBYBDv8AY3bUV2Yae+An
1jmFv+5CTwrB2KIZRay7NFOUy/DUOBZCFi88COvroUffhN2zDRhEHSMduu2K4Q8JiheoDarWJn6S
/iFVO35YnJNl2hvG32FrY+Rt+xIYYXwMEXoMoD6mCY+wOY/6IP5yGN23VHtgVn9vnwi9twM2Colm
MeD2O9TCt+mGlZP2zbj9kFEkN5eTWgbzT/RlZO02Ms1+Q7jgorwPLeSIWUT/AHVKd/sW2bDPp56F
fb9HgWxD3kyCUZnV0LuqhEVE9saWIyOcCRuT7HTqEyehMyL0UDPSHgI+Il5g3OTAivQreKS43eej
rDmi/BipSE+EooXgK8OkOzp+kSs8BDGmpDMCWuncGyS8FPaqE7WQteQosV0hyHWlIMiBEXzI76En
bjyhg8eFRJ41w0NYl1o40uIlZQ+NPsNgZRJrk8DhqeRg5FDj/hikslUUngcouCaHLRAz7Ec0WExN
dJDn0AHFEqZExpXlI3ibzDBYS5QmaawWvw0hrh1ZGh5Rr4D7LYxoaosMZXRp5HDHB8TKMxYZLkbj
IYlsrRyGTobMpvwXI6tGQ4RkcDcMpeTFnLMmzQ7M2yZQbMsFyUXIyvkaiNIyrnHQqWDT+EiwuRo0
aFLcDWxPJe+ClHs1SDwsnnZzkRoYejU18IqMcZoXEMvhoTqG2ylPgbJGngSylwLBazBG4bXZAWYR
2lfgaMv4PT8ipQ/0v/8AB5JcidIxdYMxDMs8N0g4GklijzazkqAc4/aErkey4C48KokjZiKtzQjY
PQXGlvQ6RVXdGMk34g1B8WWDw8MdZRrIm1gdIJMpXaNWL1lEpgSyIOhK4IcyxJQeIMc8JDHy8KYi
xEgpD11QFjbaHyges7eSoU9iCkaLgQrwka+7ZRDQHViMp0Gl0WCzWMnDXPSLXrgT9zOmVYSRE+mJ
LDs3qh6lMmEBeAnjbt8nGRDcHOZKuS2WE3kSEFdmvihWspxsSKLRbCkSM8x0W1gpqwSZjA3RwtMO
GAqy34EjCjKOpCeB1kcQHSEtujjz2Wgd6INvIwLx7GNdoyWOvUC0OJwPiyNkY5ImoOGgsdB4zeB3
MnlETsDUSyWk9xYxrkvsbUlCMegUZIy6oMtYMEmz8DOKR3ZdgrYacgn6IcDQJB7u+TFmtZGePwZd
aMvTawYpJm9DFBxdiLc8IQfsJ1QEu5hiv8GwlgjRu8HhyVCEuk69aFmtMz9UZwS/Tg5C11TkmM5G
gwBntWSWyWY96zFXsv2vnAnmXBahKZa2xurvBttbgYJaThIar0QYVEgf1UXD+CDpXqoLMaaxXK5I
IK7meDaQDDqyMX8OivSDp5NuBSadaRRPThTG5gjY0Njb4W5wfwsH9GUZZO3wrTYjJSXwGxPRaKyY
+CIIcDbpmseDn8eCE0yGhMNIwNiVGRMwEuzIrKOVkmCVH8OJCVRCLgfY40aGmhPBORvMIEyCrwJP
gbyi8/FJzyJUW4NImC4G3JTAT+3xSJZ+SYLj41MsGAe6bY2x4FITMg5MdE/oswfp8H8BrsJL7LTF
wjdsU0zszidUsx45DaVWqJjuw34JT00A5D54G9rb+FlmUflCIo05FrdKjgt9RsBozS9ZfBAPGxy4
MYJyUXEXRYLYiCVISO9ifOEczaoaJ5Y8y99CastsoiCJHpFbEWaIyQvgbdjnyuaiPYDaC8GRlLfA
pmMwqHi8j8oR5M3UF+YckSaawKvc8DndujuEicqVzsQ94OszVaC6WsrkV58CoygqRkiSeNAC1HbG
SeAYFb+jI222IoiveR36EFPc62tB+7Yr4Xx57TKZmEwy3TFaAhGVNGxiTZSpv8CrzeXBRdJSzohP
Xa4qMasdGSGnK0RzU9IbF25THtZTMjEQ5fY0/wDtseDyvQmxLhoOlV6Q11+hTVgtYdD1Pxexyd8m
I6ZK3OSbR+TbEeulSg/QjBCUv0Eek1sHWdxnDIWLljhKXtcEMOybFi1jjgljDWvoYhF2o2elij6U
G/zBojurZOCPCubwiAaXR4ZZmZLSGMXY2zUxlExQIkUUbK5bhtofROoSmwL0MVuUGJ1vYTlYjfsd
chYTlGGdefySrc67CcBMKKcgxl7sFCtRWYWiTtH2VcpOfIjrG6JkqrR4m+RbFPGfBoUKhP8AhG9R
mPgxjq00eiINwnlyKicrkUhTAkPpWnCrcsk+4+B9RDlnusuDBjCY3TueCNMQP4Z34SaFijwFVgeW
NmJsr0KCKF4//DYbHwFJ8XsQyhJ8Jkw2x9HQ6cC/hybOBqkJieTT4uB4XwYokJXYkpizgWhrI8iw
wj0JjXw2LGeTT8Cwh4dF8ayL4p5LccnQTw+xrA0eAkeGP4sMB6F5CfYhw5yWLsQPD+E4xtDAQTEr
7OjHxCOrJGjh5Gr2IHvF5W0O/wBi1xdM1VHmJda5aM/8tjZOjGZVgeZNMt/tKCCEm0MshSYn6Mqe
6LCTlnOSXhCjCcjVCDgloyQvQzWRk0LiPshB2PISLQVEpUcY6sCgtonlC+mswK9oymX2FA9o4KGB
FfGAmCuSUPrJi5GBCc7xePhLEJeBrXFwFSnNEyTGTJPIhiot1igkmLFbkmInUFxtzB6QQYYdm7Fi
31RfwYLtovL4Bm6q4I8wvRIPccPgyLqFUdhILPIV/NqFCEoXgbmGJ1F254ECknAmqIn6GMEfaFVV
6PI1SvGxe9KqDfb4xU68yIQiyZ1DSH8xiVszqWwwNltE32EWnnV0abkOvNUbXY8h9Pm4N/eDGBfa
SEKqngKGRVhj7QyOfKNfo9Pn8Tsmn0xzeS/6aP8A8Qc3t/2Yf/JgxwMRB/ugWxuvYK56Y6C5Yxjh
iEnYkekDLufGNjL0lOzLHI2ZLHgDFj2th+JXKNfZ/gxWaaxDCgk4Dlbn0Y/JYyhkqTJiHdN60uPg
7HuwxyX/APUMw0qh0mbrPkeJt6QrTtgMI5SC7WixZDJHQ+Odm0jm54i5WMMa1tMxAkuTHDKLuZPe
w8g8MtDWbLaQ1BcZjMI6HszWC4v78QQjtMA7BjcNG2PZtHB8EzkSaZoJb+E4PNfDy38uQyLENJo3
keyG8DWDLfwNBR5KDF45FmDQ0XwQyYlCiNtkMIuRvkgdfC8GvJk0QOp4OSYYxYKMIucfEIYabfgS
+DWBth07U2F8ODQ6Gs+ERlonSZTMhgQvZUMS9bJnZgk9lWfETqYrbMGPGQ3lMxuaM6EPESeSaq2y
DLyKkciqjAeWkr0FIGhCLwMlMcxti4voUx0nwKoZIPIg1+FeNgKU5bEVtse30Yh4iHhiVZCD38JD
C+ewEbdF/hII50ZPaPp92FtwLsYxyooLLA9L7LK6csckhzriskywhnGMGUYTfyoy/lIu2ovDeSLv
qgza0F3qdI6GhdYLobKa2S7JaM/yZcgpcDi2hPgzow5sWW6mn6GJwsNytFyGBhCQNN4vwe6N3yzT
O7RGnA6smBnB8VH2uBVGs6xLVmAhKPA1O0m26ZFl3fhhDwsvaMbByYT4GCbSZTZABEJGlpoXpYJd
B9EqN7JDQ0WRqbOrPJPAy7V+WMagllMU7idVmaLoSzLDMK9oz+obtGaFskqwZRHNDVwZyWgbOYnX
cSQhdUnwOZfANOqPaMjgqGC80pnqWChs59mFAUaGtxgxfPndiCmyqUUeEM7EAV5MdLgWOAxWbir0
MdRYuKFsShVoQ4M1ZTYPkeAnRG0ICbCMBUeeDXGE8UccJ714KnT3JU6hdDogzIozeMuERm3tvLYo
Wafbui+TTXkRlarlFYuM9INVlK6XIXamIiQeCZrOBW2d5ORbJBFkeGOXY0VjvRhJMod1pwrQxsxH
cbgT78xjfRSfCQ/gnUZexbN/EnyKPBgiCWdGpIS4xrNGqRLWx5Y3BpkQeDZILLHob+ERBoNtnBF6
G1DkcFmDNdhi0YM3TOj7+FsUOmA0VI5xsxC0iayVNk7MND2cdDKSsZIzXkXOB7fZwNGfhh5+GSEO
xLBsTArM/MrMTJl4ROxZYH8Ho0ootiX4YQkKXDGJ/RML4TJgyGsUTWvjaFkdmxdCrRXIbFpYuz0E
Yewt9jpMmjFoYTN88OP1wssVCR4BoSMK5E2Sn5JRtdsZaWLrsMVa+Y5W1WIKDTgPPNwOpsbrLB0P
/wDANc8/EgtEmTzOElCRnRt8BSzO2RtlhogIlqMW8COwfikR52MdGot2ECVX0qZ0voxtW6k2Pw4d
jFELiiMAodSEiInUcBq7RZc5EFROiJf6F3qAnSESyu+x0bPJXaTyLdhnYAyt6mLi6etFMa6pSRuV
RPweWMW9yM1elHJKl8Njmh5JnIyeSOBZwcqjG62aQzWmRkLyKzI8h4Ft4Niwpksjle6LQ3ndivTX
I8J4m0csYhCMDo4Qi3WUR4HzHwJkmhWkm5OQQuAnJPMHOVYlxoSU6siiO8Qf31zpyNUYvVmhu6Rj
6OIjWxE4fBTz5jGyJ6IpLJOSXeAMnqUSyxZyW/MC/qBpnEY2tHsUSaSjgdNoKyEmnnQk7dFWfYmO
JcQd3Q7FlHQh/PysEzqNxbFBHa6GM5YXRVPYYJYJbti5xZgd2Twhozfl5JzxB7j8EXatA4q6eUbS
HtCU2D2KYD6BN4OFnz8h5diZ1EsIUbikmPpFd/oIMxPYZh3cmTBK7TDr50Yg6CXwggkxi0ieqwPJ
NegMvu8DX0Xg2RyLCDniG+VfAfNMpB/BiciUWzSZM4Nvi2hbMI0hOjQQ4pkxs0ZZJB4aHYYbG0hH
ouefkbSHCFRPZkaYjHxgb4Iq7GsQVnxSaGxaN04liFkyUaEkGn8HgfAeEjDRx8RSmWjAN/DyGtD2
NwN3JkzIdA0NfDTJ+mhqs7QsMeUJXk0xMNcjG4Qm8lfZXLPQraNBWXj5DThgGbcqBOib8DdsWdHc
x0M+GJMyrGNbLmb0Gqf8GwEvRXdTwX4jYs2e0QK54JrJRE18Co21B6XI3nCFbyVEx5fxWkMz2L7B
i4wy+jUo818KWJTOJEIFWKb/AFLWIMeVd0LVcf79xuK6I30INjQfFoKtGvRxKKauxWx19GVNPAnc
El1j0Rg/5GtD6+KENLA3F+xPVOCnq9oQX27oWGl7HuBjySQt08ocgfQ/zH0LiLLwJCp1Upsdomsa
0KZ9OEJQa+xAOfGRp7fgtvf0LB8hJTQ/r4VYmnodAdByVaMkZu+UK6INrZYE81IMCY44VIb6FVkY
wIqBcFmMGmMUK2pHS09CkLFhPkW+uGWDnxS1wxS0MTidwOSsaaFCUleTFihYrfZU8CzgSaojG4Tx
5O/R1FPGi28DYYC7ZTYgjeYiEPRJkeqE7Y9tCo5KuDAv1hrP1GuhwxrZixKIQDcTG6MUnjvQjsb8
CzpxjWqKy4aBGtTIXmDxBydMbVMjmEjyKymjPlCbTlwRNuG4jDRyLyLZpmxkTY2eAoKuns6Yb8NM
tCfCZatD3Bq0tsR1PbaMn2kCCDfCFdRtGPtGcMDRaTI40hrJhwTIo1j4SkOPJb8VRujGOuRbCFOj
+CQzDgWGYHrFhkZJj4agmG6JGvZUZGCFXgNRkryJDYpz8NiWRsOXkavw8+BOiVGoISrZwHo0t7Es
7+GbY8CwaMYQnSZRnIx/o9iWaPZMXsSyEqhDRYYEMfj5MsmRsaCabhIZqbuUYyLibY95O8CjJDDb
OYrLHMHaSyJroszAtNj2idZciAQITKdhbRrTErlAY7ZlCInt/CFjyLsTQSBD2KJ6OxgKkKLZkS1c
HFnDRv6aQpLyKqwrhc8CehVAiSbb0YSGdCoRUX7K0GsyMEeAVqknlBPbZPBOQ1whrBj1RfhegzaY
ZspVgku4mBFYuVrYhOk1TNDFUJxWhRamhYErsYVYvCRUv+RWsZiZL3Sf0wDzUxcrsHiCxhks+CRS
UNsiSrEnDThJiwsm25EPi1EJhdtELZJI8tExAs4mI1Qyuehu8HSCBWZ4CGzNjli3NH0LzSCmNHME
p5L6HFv6LsOPhC8U6QyoWOUOCpxMRJwf5OHpBs2km3BuXrIuJktvA+RshCPYXh43yMlLc0gZOhJc
F5gxWNC9mGQt2+PYmmi/pk6mDIWSsKiEHwiWkoPXHpT4yE3foNUiGMMHRhqsM9D8IdmbgyMSSDEm
j004N6kBpioXG3XBafdFyeFQFqQClMMtZg5eDMU5DMvScEhsOnyEDlXCDwQcyu7HsaRonsXk8EPQ
44ocawaFV/ohGw5lgSbTfki5kptOThQbr4PGzYw9ITlcrfZZiLQJ0JeeBLS1RFMUoFFCDEEzo1bw
O6c5DzJTSTCGZpMx05FVWYJkFvqECaRK/LFujUMPaJYuDYKRisybsq6GWIIw5OahoYDK2H0LL8CZ
OBMqJWNNiZb+GFeS29jCGo/mLCDKGxrIUCC2LY8hJ7OIaTBaLeRp5yONIgzwJOHIvYtnPxWBvg15
FsdWR5Q1EINUKgpfDN+C5K0934YtaGFNCUHwFhTZhnA1kzZwY+htJ/C4GqZGAjmHsai38Fg8hTPg
b4M4dCUr4H+hCuReBgcsizojj/B+zzRXVLaDkWnJUeRmUOEz+qG6kmOKPhYfkWm0jP2B6pbrHEd9
BHU2j6YlHJjWcDUSTQtjDZLn4YNC5Iua+VGLXPGTyQi+PQdfEiOCgcuNoU24GbCCNXbYnhl8eYhM
yt0kMoHMuLkm/wCDdbyKCYml51t8ErKquR5NTpnPYhWPdZZOaFUMRkoJBtYovM2xCyMGqTdAxF2L
Y5rMn9T7Fjc+RRejyIoKcla0WnpYjzg5mryV0sY+PpKVic3uRQifGDBYJNyu3Ki8qX6TQnQkyXjX
uCtIwYvOHRmmCi7P49GRVxMMitYYGv8AgULgwL5Rl1i0eC9xwyHgZDcUCWqbQY+VPaRDUWmv8Fkz
AoMW5eiFIR7IUhZ2Nk3tCKr4gwMjZgtuCqDcq1VfRvMbKshkISTZbF6jbPZCtA6XQjpyXgtEgV/R
i+lSgd5sgmaiQPO+gZDOH9Cs0rg3YpZcpmvq2Ojb+oLzpvSpVJuDkHNXi8DCZE0/JgbPq+inBLId
qjr2cs8kS3UqcL0RbzXR/wCqBWOUiQcIR+ipCQkOSQVm7Byb0hjPCqPLqD7ixTS6IkoXSCYtzhJC
zFNNyhTp43diozXIjHJCS7+h/ftUKdJRWUkWmkP34F2OkmmkFUMtjD4Es+B+xfAv0bCd/Cxi4+GL
ooPISaGq6KJX5c5+PImDiDdiWRkQax5KMBKkDwTHksFyOw0ibP8Afm9jVkM0J4zs0xNkJrPwol8H
AvoPhsTj+Gvg6YZv2TWcmw8vg4yW2D0kVJapgNMdvh+jhjCyHhFGSiwJjZX9CwoysgmCNdHCEsQ8
oJCtEvy+B9Mx8ZOWxt4nSUntOCDvUlXDHp1jrOB9GV6Dx0Qu9njoOfiqIRb5GDHlicHIshhd/HA9
CNGAtZog6SDkotHPwt31Q7ddhpDPJM1bWhtUgnlGqOpY+i2Snsf00QxdkYZFLAmmIBN9h/nLQcY3
HCusXc80jE+6H2ielgVzg53G1BqY3yJx6zDC860JDOKhiJRH7KZibFjZMOkneCNgTFFby2WDlWDX
V5iGkdp+ULZ1bD5YPZRqZrEMcSYYw6Q0haaxodtCKKoclvgyHj7eB0Da2ymrLjSZTJ04pk5rkQkp
n2xCKG3KGN1BVROwhonXOKNtivAbW8dnqig/8aq2PyuXD48yFXGOQgwlRQbLXGR2hFkdwwLneBA3
minoSXlodMjyH8YjNi9wR6aGtyhD72l/hwRNSInZ55Za00iB6uRMyhwzXMbmBjmlhFMpLVDOtFi3
ig+MjKPAm1VRG7JyekWPaCRYbaMXzo+WPD1hZ57H0ViZ5FA2wfsutwuwuA5oNnyZ2IfIM7EiEIJx
kEgSIUhaF0O6shKei0+ib1Tol4JYocCt2ORouGH5BKwUWdmKqyyfgU3LmH9F1W2jEwOpkXy4WYNr
lGInNx+BbNkdUncppyJWQ5qcITJ5MREiEuY/0T4aaRcCTPt/AdJj83gzE/QCCcBBTREjhSZ+KTe4
i8zfnYSPI3SYeBUxutEyJF2OyQq+BMFphSPgvQo5+ImMIlPmCsLIcLyNO4N+x42JHkf9NoQN4c+G
UI0vi3gWWZNDKO6Qzmjy6QSz4ET+BL9EsZJR5FaZMnMENhMez4GlolZN02cMjwRRy+yRR7Mmir4L
WOBwQuQy5wYTIqJrn4jdnwLZsfgNiOGmRzHxkHhZMx+RspHQhHBNPWyaM05MWVjBdlE2bjNuai7E
Yodp41tlSj5BSBWiMwYTeTAmrwZ4WVBMVgvwQTeRCs5S3GgVeQXCbJnMuxEO0sVD3Kv4G+9Gx0jU
NCjTvkg1k0XI1ppKJ0blGJV2JHRoQfaC+rcE2s6iVUsZUdqqSWmbCdhdwm85yPQdx2bIsZKTZQwD
UYZWSyjREnbERzm09j6bTfWRJaN8GL1B9xoneLJJigqC3AiexBqUa6YsSInI2UCvURxhrnklKJj2
8QmghCqUkGC+WYxY3uKPuE+ga9AtIKlhYYZEb0Ww3qlxNCqU2DdIjFCRYvOWNBEeItkEFcMdslvL
iEil+o+jvDwISQ4ajqSYuKVww1JBYnBrRCol1N0x19OPjehias4yYizNgrEtaERLZ0pIDxXIYjI3
ovNEBUBxzgqLnXn8ZwWI35yccDCYJEi/Cg9+c1glYu4hGvmzqi85WWC6j1gMeOA9TvkPmiR96N/4
0xj12EtIZyzjgP7FQp8sX5iYPvgRYPbmiMju1Q2xbz6F3zdHvVfQutsE0KIt1GhsQ8vgsmdN+1jY
GBmReazfcWOcmDPZdhEAaM0O9znkJ/O89uBy5Gh8iA8U8C4Nyt/FIO93pjwjvFG7d3qEUUsjbJ7F
zml6YLSNTY525WbYnnRRbvKpMhJvs/hIwVV5SFkYnOls4w0ZxJfsb5OJMi8ejmIqxdST0KymeyDH
7DPdyjQQHVXsxFaNdsq654XcJigh5aEuCLoXJkvJ1TLiDoYyOx8PieGEXREbPSGzIQbucDroRyGU
OhKfZk4fgl20jQNnJSiGjQWBE0ZBIzMtNsS4JBlMsbyN4MjZRmi15EGJRGyxmzYbr8DYdFqjD48i
TGImaUMqEx14GItNDJEnyazB+sG6e2RfFZkeWeUaSFTILEujkSclxhGTPY6rCO4yi6fQ98jB0dgT
yZFEyWYU1nRBqrtiig6fZXMfoSWScqn7MYhKeasYjF4Yqunz8LC+J6/ixXka2jSI4KokKVG2BXll
NvA7yHL2tDKRn2RnRuB9sr5LaKwmteSmRPQBhEr5MIMwrE6Qlh/iGYenJlyvYzMp7KXupsbftCxl
9DGghyyn9ZQnrLF7PfOUadqfkLI/qxKJfZi23aZhD7Rf6qDLV0bx7oKqm8lSyB9syafw2NbwAZyk
8jfwhUv2B4lB8A9MYJJ2Osd6Hhsw7rxNibS2kzEyU+zaDfoxkL4Ou/sWYicCm6SE1lemx2pCQPTx
8BLrWNDCHnZgWHGZeTFMXkor0LsGhsaylFDrJPo6n+CDqDU2J8CHgS9CDCyO1lkRqlXRNpECmEZg
dSfoapdDpQ4o/odpdLVQmLy8KDTqGfUjw8YPWJFsGstjVsEOMMwELDSZMRQadH9CSrUMWClmbFJt
bJTgSVKODXSloiZTGjPueoWS7wM1y+Fm5kUcFH4GAK6EvjXQpMRlzQtJ6HYYcxCmkq2aXvAoo1ZI
cqE8iV5Yn3yWnDNIZNQwBThjKDFWHh1GjCGHBfhZZzafaElkuxUmfUPbdyY0Kf8A4GWj0gqtqKxi
FWhKoyYWSM4PGhqIFXRjbq8FeINWd/E/jfQ2uopuGIV4UbCnKWxtPCof1U9JFOdwbTEpXUVqqrwP
LjCyWdBeEKzeS5GolZvQlLybZJWNfvwsko8tmxAxcCHnRr4bDDTWhPg02JdjZ8GkPGTDWdiWD/gx
SGUGohsoZz2f4OjYoRzUwNqDbkMo2VNvB/Bngreh4F8It+GuR6fI/wCinsQgwQPD18YNiWWxuA3p
inJyfDIsKGXISFUHNoZLlGMWcoygxAUHfYUzRLyTgZiUYiLossV6FsaQhywDQ9i62cIfSGpMWGT4
eBrklWyT5kExRKs+xCUcqI9RCy08BWwLlF/DhoWWPglhMYyigjAHtUVVyKYh5IQjJeRtBGAxliLX
BwYOwhiFLnI5xTwt8Ck1LF0NDn0VGnwIPvIgK7jDElPIWS3k7XZy/wCCYb7+sM1naLg4PJFt5OJC
snMISWnzobha6TZXSNcEFTXovgzkuJVnwYotMe6DNsGC368watv+kkF0HqQfoWdtwQ0Pt7InIL2B
xBIRH5GaA4HOlXKKbyOAUmzYwFzZw2i1Ln6O54M/FDHYyOYNxFz8eNCdpQXLgabwU0Tj3YwKq3pE
FE258IFbmHPF9DrlweRvwM8xe0cYP0LvpDA86vYbZR4FCOkM1IuWX6hVMrCnLVstoXy1mYMZd0h+
KTVyZrH0QZJ8Am2TARYS8k69OjE451gpFW67IzeMy+Rx5WGVNrwVYT00PyE5Y9MtpUaE/gMJMbwQ
SqmuTViDFfsalFNwD4mNdkiyESMWG9wm3wGFMWGkJLSEQ8+T0byzLHrgY9XKuiDkggK4yGxJzC5H
bSSvRj8nWbZJ0ZHIjPl+FJaRWoTc09DI3fqIg3gJvBiBKXSMAWZFq5jxKV6nEvA7KzQve4DSGXSJ
IVk30PEFa9DuFGybDIYt9Bt1IuuBZR2/gcdUnnXBjV0zCDpMTkTTtp97EtRqkT4Ew720iwi8BoIe
hDxAtlrbE7UMxmi11mx0Q/kU2z2L2dDLpm0pMSjG4xcj2iGNWPnBUJk4MBfowYmNcIsKrZsadISY
62ISeTLlMOrYnPJa58bFjAnVEP8AR5g9fB7HkdonksEk0JfBRDxg0Gm+fjJfB8hGNnBB/htwVESL
RTsdD+LmEJxtEFbjz6LUzj4KeE4M1HPYktyMsHcCCTOhgwcDlJey1wI2ihLNfosSrB3PlkWnlnNY
FoQRwz2uJqDFtBCbtg9uAscNBIJQ2cjCl6EpsUMfwrBNjl4Ads6jIA/O6x/pm/EFaENNGGJeDHNs
n1FEIj56ZaVVn0cVUGaNC2Yro0OQi34vIiejciJbLiJi3xaaXaXJSZOYcmNwzQFGJEaTHss8nUxQ
SCy24EstvZOis4FiSXXAvjTLs2Q+SofmsGetuiYmMfYELCTNMWJp2Kgd5EaYmZnohwXKhumtHAhz
8OfLjeRFt+g2Z3YfhQMb9rXyYc8Kjk2eJke+tu2xXAthk9cSG4nJtsm6zW+x6aEeEmJUKd8scmp0
c5uFYhV00afkdpi6/wCHkMMsJSq2J8N0Zk0z1GnSt8i3e8exSixQZGtjWq3UGAy+XgwMxwnYQr/K
Cikc8hL/AImDVb8MyHirBH+vL2IWoVpci9zE+hyc8Jiy44ZDzPHsXHb1A1lS1EgcG+HHZRit6E2c
DLdSPHYlBTCGuRt8CknDHv4AhIk8bLKoKuBsQF9TkkXRuKeoOHAcvobDhipCe6VHmI78E9GGRFQa
nfkmR3ppg0XcSfHZA57wJhHhtLyKdKTEys5YF4M/VhKMC0DaQ4k/grYLAYXg3eLBPs8qRSNg5NDi
mifUsmGZdswpiVgWUTBXCQRkXK6E6bYST0LHMWHXs0K7UMuNXGPknlaxbJKs5ZY5uf4RxscFIU3g
Dp12bbLZwhMna52YMsHy13Y6qeBuU80Q987XXCNOOybfCf8AWTSwaYhwu45CCC41RjuavIgTw8iH
klgDNpb/APAnvGNGPwJbHZROeywVYbdHUXJXAlTHsdiyuFpHBgWPZK6NjyMDTfkbwK0c7kexOC5L
BNUTTY1kYTehOMZj3UZ+hKkHsvgnwko1yPkzcCcHnI3EJo3oVG0kcjeBTZBdliHZsaeBKZGpwKeR
lEz38UZTyJOCz6+HowRXvZmw4fyEjFSli1lOjtuaBjmIN4c3CUhhewzko9vi2Oxd5CpAJrqtnIy5
CQa5MK+CX4xGTA8/J4IYQ4Q3kQkIT9Iv9YyL7EptxB51wINEh4uBZATZ7QEeOUXVZ5hJ0NxPGiwz
+PAvhhDibDYlSRU3uE6F9rYZ6MnB0Xc8kTFzDx4rBik4eG9DVGzSlV3o4GVIvTnMIv8AS3scS4fs
ic+gKVNZXDFB0e8+NAe6Ryi2HwNR0jB5s8whXeLz9DNmTwfZwNk6DYjyOB2zL0WqnwVeWk4hRWxc
sxQfA2wTdokLqODVAYSzsxDSnyJoSAfoa3lfgtaAlpUDpYuSHNsdyyinpp1cjE95PYA/glmmon7H
WmP8HTEs0W8CxVwz+cWqxcl6ZmK+bkjpw8pINN9VwP2smYh/W/wfS+X/AL8OfmZsZGpOYwPjZ5T4
iK1zwiEm1LODMS4CHFnRSbwGV4Yy6H/uL7FXA0MXHmYC2WmU/EaPv/xEY3oIBJgr6LCby5fY0WHm
eBxfLqObEQNLLtYZj7ZTsfpRf1j4rzTCEBfpCgWhTNQP5f8AgxRptCDNSUNz1SLaeC6eg4LrGHBS
piqj5NaNleBFd0IwMymawuwzOLEOSqSINskChuVR9ozkXBYe+SeqEvBwiI3HkS090htdzLbv4O2l
LQm8opja1WVtFOY8pHFIt/EapFvCX2z7fInpyhWbcSjF84FtqYG9Kjp2xS0hijsSfqtf4aVPC0QV
/wDEJeYrUpudxlrwNPaorYn+BgQlEPco3l+hs5ucjyzkY6hh8fBlYeBOmyoqHrwUbhg/B00PHw+h
rJkLBMSz4N8R8jlGTvA8M0zA8kFzNsZEmJwzNm2x5fZeDBYWqMSS2NcoeHBfODYlkSspTA3DybJT
iLKK5+FWjjHYsnJRcij+hwY6G87Ehk+kUtDt4gqKeqN5lSQJakXA5VJKJ67WMRnKqHtyhwaWuRXC
DUuT4F/7w+b0HMQb3LlX7GRuxTYstZk55R3/AIZ8ifQfyIJ2PQjQ5RYKyuRGMZQ2FWjuMy1+8Mx0
JrDJEU5HhtYY2jM0NiUGolQVexLhbLhiVEqYKnFMoI27aWBP6At2+SjbAnTJimgdSY2JjO8REyg4
7gyKNjG4aVHoYcpwbq9tj220pRWG8eRq5hqFhuiS823DA6IIb5cGWDUbogDGXs7RuRi34I8zzDAz
ushJHX2xSASB2iGvZELVorDFNs2smYH7OCLJbDwWpO0EmmOh/kUUL7ZQvOnL2IeblimKLmCu2/ty
OBw5DC6sdJK6cCPPERCaTMUwVsYxEthCqcSr4DbeEjEdV8DGa8jZc8g/1OwbtFj9FZGGZHajeN8i
s4RYSpZagiulVDggrMqeRSbFmF9mmZiVHBm+LLGjYpG2U8Ckl+Ro7csxtHjcCnH5j8N5Icvoawr+
ER5bRHVwN0R8xDZGsDD2YP5NollpyyEGVIRnTlkHo27LGokkxmw2lX5ZiuyJoQGZpvQ19mb0JCPA
tXsuHytNyI50PZJmESdyM5nnYokK6lDMw83BA1ea3rAiP8JpiImIiCuE1P8ADaM8iIlKgNOJHmPR
5wysbE0Py2a1hsUNXkMu2NSp8kQWBjuEQc9+huOLoVtmruSJuLjaEDmRgIY1DVodk7j5mgjF5wLm
aVvNscl2TQtXVZ/3CKFUnWRdluU8MQJKKzR9BBvyjfsr71FUjWGZciBp8SDsSlkZokN4SMGsWsBR
21U5LfZmtiPs6EHB4x8jMhZHteRMiDaDdFCJexxDTHJ0LY1n4RgbpVR/sTYoHyNqZPr4bjMkPphF
tjYOt1C9jEhTPXxumsGmzyC6H5/GfQp2NZTH2My0h5yZDrImcG1HUOvBrA8exUZQ6/hGFbFGNqh2
NiGWTyFgNnwfY5pfpgVozWTZFSVbg5Z+FyTey/6Juk0DtCLhemJ8xLwEPVxoldfSgnyiKR5ezZYz
U+MqoLQpTZHS45g+4QrlajhgZA2Pd1ljTWHwXC+FwMYaFEiiqjGRR6GkNIoPCZjsIb3FGOSDfVRr
iY2xV2k4EiWkMZauDdOnUzJW/Y3bcn7PQ2i9OLExW2gsvsJSkuh/YXYlbD0VyPmaHjSESJYTItEu
BTlBqZ7YnxsdjFZmfmGZK2Nb3WVFi9o/m5DOkOpUVsTyOjFdFX2pjfMTs0zUwypOe2N6qeUcI+DC
1eRSu0BKUXosNiPiiK6qs4E5P3MPDNeNjMvIYVaMfGy8PivAXQ0EqDC2jlchOX1NmGL1oz5IfHpe
RYiLSaHR1bbI23gxcmYM+IoNDzbIjQmRj3rULNWNw7BA0FlluRXyuESik6LqNhbeSMxfODdWlaY6
dbTsT0mmqJmkTwNE8EPyTKb9GiQg+9hjm+UKbqMp6OcvUrklkgrzfaLkZyyNtd+UiSrZ5knDGxGy
9N98MwrX4Rl4VoTzpC4IbcaypwPJl32HNb57HmCvhyxjT3D16YKCN0hiaztcYdFgy2Ee+AHoZ41K
/twcmsGfN4Fc7TIl+97L56TMosxVwhEMrM/6JGeWP/o34JlmcoxnTGE3JUbKNvQPZsnhm0zSaD6r
IXhgQvhJ+xmjT2KsN+R/AlcH+gmaZ10NmcsS7R9UcN+j5NBdcYoXfgzefQFXVEdcTWEF+52JcMYZ
voEjeg3kdgY6dXQLWovA2f3xNJVwFOmojIJPhhoWMU/QahpFzkcWjFFlPwJQ0R9jdKb4uELnkcMm
Baz8WWYZIwmM2yKnHgTJgxNXJuXkbHhIQM6Q0LaY2RjC6Goiw2axRY9M4Mid2Qxu/GjHqCSY8YZK
TYuPIm5DwEsjJSRDDBgScsw1ETkJbJC+DVVHOxd7wNw1RDFCtM/zlwi0WvsSzZLoY8ILtlRbt2+x
qTBKln2bZbNqyEl546Nzg3yLDSpgXwD2yYhYMY+D1CrQmtbMooQuy5HhGGRU6GJs4hmLjxoZAyYj
G02uhT7UOlpihj+hjc/UPwckQw9G+rmDygaxjpetFkx9DUozHQX0m+degovgOILUZoQq16Q5R1gZ
mUQ+AtmEiW7eiqsasaFBybP8OyKc+0EdSbZRBn4oowN+C1l+CwHIlO+6wZbN1B+/wIeWAyRvn1DR
RybZ4KLV/wBjK2X6hDoEC7h6Qng5qjYd/wD9E28N7Jz9hlsMlSYisYWA1VBzRGNNgotvdQVH0FFv
XHZJ+nwbwfQysogO9vDbIY8NY06kbkQN+ZPAoSg2nAkOUHb8kbxkqsobH4JMbtoTbMFg26RW3BTF
VduCyccBhpSuBM2wToOwWrwpKGQvchkpIE8Ef9hoV+h00skyMaosyE2tFndoQHKZhBaEyw0ZcDk6
feFwDZ0+BTV5S2NuCcxge2njyQoZcqMqLszf6kEm1y4Rc9+EN0kyjKOq6PcLDeBiUlkSq2dCWvuT
5MwfNoeqk+A3B5DOBPcSGkCxhqk6Two22ZeSbGajoc60JMU8jyzeBI2MuQrPf0FioUWQ3Xj4kwG/
waxgiwhruZYGoyecDanY2E49BhLyS6F8NRQN8/DNJpGA26JZG+CZEyJUuDLA9kE4LJpDTTp/psOj
SE8RmRliRDNVHQx8nEbL5GxRRs8picGJZJkjJh5Wvh0Mw2siwNaZDRgKCjXRMjEtw/8AA2DkWE2R
wjMDyKhcqaMbQ76GS2foS4D57YtPAtNktCUh6aJKuUYUzCgkgJs2JgxhRCsg9tC1lPwOu0Q8INn1
9BbWeQReRPRGcGMSueMYJR4bIpo0w86FSHsTIlQ1BhhmELi9G0e7uhkvIujN98HQvA2GVKY3Zj2j
aNia9Hgd67AmXRmgl9DobNgjiUwJMYCQyNOUPTrEbjqhHbC5IIfQzwlWUfpGz+GYgknMuCwzEStu
NpocRO6fghbogoM0zaYxVm9HqgOy6XGjNScFFRJ8DLC8niYMXJ0O1SZ5JkA9su8RPS4iHmGtmNgV
cuqxeoOBgRE3ykTw2kPKw44IGKPUKHwA+ZSLNDD0loneoJBMUzMDtYiL/BbNXlylVt+DWO1M6Hhb
czwYlNaLo3yEouV4IA0TTMmIyzb5SGDzHoQtEoZyX2eSjovOW0izHSynB7/yK5hzC8j4WtnLR/Lo
WLKoKKxm0hWw/IUIxmscVJOTgC7F0zoy3s6e8lcDvMKckv8AoR3gezFnqxA68muha+5kZV5oYwKx
D+Q8sFybFYXoUVl9BlkjdFm5uJj3HbGMj4eMeQ6F0VyxSxG+pVmYOUIYtMdIQM7GAlWJOvAkgsI4
KfOLLQvyAYrIml2WC/o7ALlCZi5HRk8vaFUwYSWRkWuYrQquDRnfgU3/APA0EEA+Lb8CE7Y42eIB
Bi1RTF6OBvgaWn+DMNt4Y4McOSeDBy/QVmUW9iibJmPyM1km6haYoAt8LMKoXqEC4gvjK1pTDNoN
c2nhD9mQZ62NfD5DyZRusbuCxwWWLBJbGVXyPh8MgxdioRoQhibg0QeSNsrA3lHJRqxO/HL0PpDG
Q9+Tkf8APhwINxnOdfHIVZo5+CT4olmtm2b08jQYk4MJkj8Czj45I4nwTKMsyEZk/wBJGQ8fFKUT
KyNkfJ9CBaqPIWoTmCxJ9jZ6GKTDGdE4cDKNYCPDrYp3zwEWclPh7XeNUtFvFGNulFyUDuBLugtP
LChVLdGu1rxJa2FNCqxjbZa5NpYE64NK7MWF2PPJoWTJtxpmH/TIzyhnkfJGzi3o2spgwmMhLZ70
4zIYtPJVK8jNlsRq02y6N7k+0QvSOijdi/LGmiH1Dc01pGT8NH97wstNi2s15YjA8WvYly7CJJY3
PY/wiGbdVSwYnpU2KSIlpLgXAsZ2wviZks1bplnwU/5H8lMy8P8AxGy9zZyNDGp0IPYrp8DYbGZ2
FURXyiO6XJV5PtjXyjBMWEJjRymy/anA09kTVrelyKZEZuRR546Y6Mbexv3kZH9LHgoCuGOP5R5g
ldAsCq+wQpZiG55LGLhDkjDQVVXRdCJJfAs8kU/BtR5J2ysLfhS9n/C3R7jMvyztUKHRoNJuxPbX
2EJdDTJou/tHCZwIhvYhj1d+jwLX/CCuTh7nI5AMiZKpLA177/0XDzRSW9/+Yub6b/wy2smexzZq
MT/BiLzcZW0It0IiRpe3HgryYsnPuIMCWWXBb2/+z7BP8GhVYBB5PobCMFEyO6i2ZX1MmCLrORyj
YsseQcIoy/OGiqlU4J45T8jaG0nbQVuE8TlRBeSby7bYfxOhGeINoRNzuBNldabjQzCZ7MfGwuNS
8tGzqMK+bcgsk9h5fojvJOfcRlMK0ldG/wDiJ2fAGSR0P9OOBS7R173gnXqyKkNbEZ0pZee1DJvW
W/wNmHDFQ06TORorFg6Q5wLkaG1IkJkyJkyNxG3o0GHo0zYzahuoyvh5RtQ1DXwqGzItszeBYVEm
TQSTGwyiINCXk/nwMngrTMjTIM/RU0fwXsV+xjT2MLKyJZo6ZyUWoNwmcD8i4qFVs2wJLf0bQ00m
JPQhlM0hrFM2JQ/hMUascXotFU2PBJIanImmo1Cbg3o0q4Ep+iS3kKjeAXxBGl6FEb8+RWNZeDDn
9Ci2xOoYrehW25uhnfql3xsb2rQU5cuRg+0y4vhhDdY4G8dCThlyLRmG2JmD4vpnUEHNjVCy1VEN
VaOy81m8jDWBYY1gITQc2DeRsfm1sQ6o/QytNwo8zZDvmuORdJ4pAngXKJ5UVRM0g+ay5ySNG+JO
jOa7F02amWpaY2rq4EFdsjr9pIqUwjFlg1TLyJMpmWinYcoT0YYLF8BySd2akIgG8EBUsvY0yKP2
Z/LehWnhIaa3kRLqZj2J9lKW+Iy9qTKjKC/Yx0XeHGKuZPfAoU0OLbwM4SeKHkp0EtY4BYRpYC3V
lNFim6ari0mgfQ5a7BbGt6Yh9ZPDEF6YRJGyfQH+Hsm+BsGoXDAwFjzgruof0JV4Oj/TCGflf/DS
hvs306tHejXgRW7h9GlvEVQrG47QrgNLRQ0OEKkJ8tlBEghJkbf8NHWcS7OQs+0jH2ysm+AjuXMF
oiH/AEY5tWqZiov/ANHaKv8AgjluuY6EMShV12C9e0DWjAa9Dnq0mJrNvIaFMH+mw4n+GQOeGhki
9kw6xL574TYWRNFlQY46MjTaTmJtI7PyY9myV1u8wR7S/lCz5IMNBfgKFdPIxb3+m+NQPxNMGITs
hzRHC5YorUchwaUiBM14MPc7YTwnBs49twpvozB8TPLMsCr8FACn0HfWLLXY8YB0KboNeRt80Gx1
RUJ0mZGrEBsm9G1JrNFS/DBtmQymUJkd+hMDFGG8DDk0IxZFXwJQajcfDjHeBMY1vBoVuiR+DWbg
tXSMw48leoN5+ORLZBJKPYmqJnAsHrNjyHrPIxaaYlGNVC05G89EpaNxwbKhCYPZjY3mFRE0+Op0
+CjWUx5G4wVrglHnsetCeEXHn4lQ8PBt+BpD0fYqFnsjfOBK+OXoleEL2aMTycB6MBkBWtvkViS3
HBjypEP7H8Cys6Y9CS2nZyGgnDQxFfYkU2luWoIklfrVDY0PIYbIWGlGzExBNODL0Iu4xNONiOaY
tsZ7RhdgatKZVHBUSMiBPBIlYw0ONctCBt2CKo5DycQY+Ym2aEqYW6LtTCBaY7HpxMwOZo2IVo3C
mWxMMmATCqptveBtFRyxUvTwNAIwYgE0X3O2QWoiS1USWSzZmGb8DXycfCo5EddTTszCZLQJ7TFF
YzkO1fBBrbh09nCgEBGrQaNU6SY5ut9ohAIZm4lqnRs/ZcY1wLcXpH/Bq83T4G4tdofg3oqfaRCn
FdaYg3C+qPdfY3GHW2P1Ta7yJkemI7LhTJ+6GTCouhuLCFocnFF0xxdVYRtU8oRMxCeorYOqbbod
MuwWEVEyzOBz4WJP7AGvXHY6wCohEwN4Mx9Ij052eIGRDbNKjUEh5w72ZVLRukeZ2UjU+AusRZXk
w6H2hc2xxg8qGKSVLxi5Q1dsdCGbWlFCz3lbQQUusgiaUaEVr4Qo8FLyKQouEN6Sh5hDochdloaB
j7RBbw9GTlpgMYaoc8uss1ahuPAwZ9WuBCiu8dwezG4n0Mm2E+gl3BD8QaY1PeBi2wnykKLM09L2
KkHY9T/QDhUgmGne6T+LFRmHwMFnKfYikp7Mnc31YORjdYuKYgy4VJTXkPqbVE3Yz4d21SIZLHgH
jDaE5jqW2MxNghpL9BRX/JlkPu8wb1Soya2IdRnQMxJeTgGYPRB29i/wJx0hzyJhuTIjQxH8LPxj
oa6KFv4OO2LyLfj4RhvBpCPLFhsS+fwcwnNKxUtjOA3nBtZZsLYUQexuGDIQl5KxtcCzA8BqSJk8
vHxxBMwRR/A8CMXD7JgJE+GXscxkL5kkxs/02zSCZQkLVXYtj9kg2+Lg0Mp8YHguyfo0XwWsHKGf
0PQ2Qz5ptBGmktnQNERk2ZbwisTAhyGrg2tCVln6F+ZrqCbCfwhkMnk8UYobA3kI/AgdNs8mxHQj
yPwKwwUWTTwYh5FnIq8iw8kyYC5Lr0hJV+2Po1CTI5rO1GRbwLot8GEQC1e2vIjTXzRFfZCJ0S5Y
9jsEOtJZCyG8saVp9wg54ZCoS+Qhzh2MuVemyefqZMYzlsNGlLwgyE413kK9KHlDXhLOX9NlcjbC
9bMcDkN6W+WKHsUx8LV7Zix/YncD0Ym/JXkSxPsYZ+hcz3o8r7GX5KyKI6ZHzKhmdou+T2MnMK4W
iNmXT+P1eEfUY3ux1MCrYWVgjR+mVUlhlqlD1tDVMP0qhdf1w+/MOWMkimHJkNRRMppKbpY6NyaX
2v4YxKOwaZavgU4r00On7EmjhKfQ0vRkn9h53AsB8Q/oTpkM5g0aG/WDEe5ZNMyl4VSehwKapyvQ
mTf0Gtf8mLBlRBxNmNIUlhPwZXNkWewdBDndEbJn9JxGmEEjWjtDJ58W8De1xWNE5B9EVZBS4yTX
Y+Cp0QXL0dHA2PjBPfkMNLYleBmepZEaC2Z+05oY85rIcROgSsjQd7CE474K3SWMODSmPiMLBOLN
8pD0KiuA5olwHPLOJQSBqeEM/wDgP0FitUnKlso2m8Qp+3Zopnb8CKoeUETBNeBrz4kcKN6KIKuS
kPA1Ef8AgIR5C5OKbyTlkMaqS5Fhn9DdC5Fz4O1JDkTGX7FGezbOIjy+Ml5F6I6HGvhl+h5exmmq
yrZc0Wc2j2LJ27gTFlbg6IkOMi8GxycjF+iwbuBJTOzTMsEjYylJhCdMVia7I+/hNmLDz8HSOE+m
KwhrDPxWENZZofgKp/Fhq5IKJdsii3BmmqyavIG9MYU+RJNRpcR4MOA1/B4L88f4Jx0KGUuxmqQd
uAawa6Gh4+CGqjlDb8icY1sciJZN/bswPMG5UyOgvQ4zEXWxu4mBBi1DqR9omGRwm5KTY6pepDpC
+h0xJbybyBYCU6Ih0qcBwXv8D9xgpdXUb14Gg6VgymXUTF4k7EJGSlaZvwLvoWeiw2suCcjFGJKs
3gYMPNhoyfdCLCU54ES6MPsUekmWNuojNoWc8kjQ0HgytNoRlh6LY2s9UgocjsZmITQrp0kTfLF+
IhECao1k2s0aXoXBHkeMhsMm/pDNtLyYhJt4T5IqXNcGJ1k3VQ4nLC0A4rJBSUqQsb4EFTGa0x1w
WMKbeDcjGOV6eehKVbr6KlbOW9mFJwl9CL+wZtg08jFR5HXbkY2V8QYCC20wRRXoVrBcQVj+gmNX
3kg1PBCjGuoUAz6BUnC0l2+gyl/QYHgaOMLkgFktosGNUeskxYTW6Kdah8mJU+iMRX05CQbvT2R5
z5AtfxTYPgI7VKq9FsEq4EdagkRhqSv6G9U5CpSRgyxKSjYUSmoIjIlqqqIrJBJG47JkbOVPDF9w
11IcNSM70VhBp6LBXqGEmj/g+mPZJe3YuZGU9eIJrYyxAFbB5Eq5VvCJQxWLTEiJHXQw9FQ+uQ4H
bVtIPL2BgxV/fl0K5p1rt9joIza0WfmUwXCGyLoNZHgkZ00HkPw0JGSQlTHoWIPyMlIbyQUoeCmm
L4TM0TWSD4EQSoag1k2Lc0yRGMZRsP4IJ8LY0yUgJ5MsvBcMWywlJCCz4Zgciw8jYNUh0YWU4Grk
yYFgnwcefltDuxtuiX4ZMWzk5o8tkFmR2ylw0bGW0vbFXwaU5FmngrVihmxaS6ybRjlmXBmXb+mm
Sa0y6OmEvw1UvbUJz7wdriQkrw5EuZYY3BJm1KZUbAVQNlsItM5GQbI46TyJBNvI23o8h8h5CVME
KZ5HVLFLaG9UZOFvgjLazAXKPKTRqNeQajAlGuc7JAqsDH0BpWnIlRl3gvqJpRGFzYtXeRRlhK0Q
fuNoh1i+6gWdKxVPT9ie1GmIPEqIngU5ZHcModDRANzsdwQ5FHoGTSMh5XxCoVarWLI1wEHxOCPd
Z2LUtDlYdjWc2Wg/SQp2LvbtoQSPAfgV7FoaNzIhI74hNv4GpaaZTQ1cK7WxBZPSIyaoz7OUiY/E
JMTncLYKNMel1uByDnk8Eo8p2onFOrge0iOoGCV2Ot8Nov4Umpyy1EaEYgxhhCN8EUOuQixTL5EC
MNdjJyNnDsTgMdQGLAWGFpqdrhDm4hAWt0WmYvSKgle25dKYQKnYCMafdZLkxJjyDzXqGyZuitlg
wYmmL0J5RZGu5JL0SEOmUH/6cNWFMWNG0NybYYl1YXxuE1HuFtiOW7HJiagZSgKTXN7/APujK0mY
4QJZGzrFiYyLcq6QgMmu3pUxmcQdvwjHurgU1lBEvfBPkYLJVlL+DBEhMRB5YpjkuVp7ENfLJ2Cn
hvkOyU1jY4WwKqf0i9I4FG9Z/gzD1J3yJFOFX8MxisFPNta6CK04GRwoNvkaGklnJPCb0J/+1Icp
y8hYXFWdex6MbVotxLQoEw6mRGZgg2BOzL5FSWtLAp2FsUZhssi5KCwOWcMavJctHCJljfY0IEix
8CHwW+CJ3sgkQFkZYxcLkr7JCZOBEo1BPAl2aJFex8mY2NkhcY+GbbQ0bFkN5Hx8Mq5Hg4HYT7MB
39iUYyR4YsjE2/CjV0QwOjRfwSxWPHwhIZYMm9/D/sgn2Volya+BC5plgkPsyc65FT8iIJ18iQ7K
yHumdSvr4WVUQjLYyVPJYGZil3rQoZimSFZhlxkOw+T7M6jlYNW38CYJzDeRlhT0aI3gIo2smTJ+
AncIdWXgzc8KDRAYyGBD62aEuN5O9MehU51xGN0sypSJ4FcYhG2GLBk8o5WpBKlrJmEu077NQaMp
csiTWVliXGcVieTvhoVOflUVTA4U1sztj9ELcOYaWu9HCMA8qFgGj7FC50PURthG8R4UrcBMuAse
qMbrgrw3RzM7LobfYMUoETCR4ovwzljWq8ojqIsvIjDZhOEX1YtaF4hYzHuX+kF3SOGPKShabUmf
Z9kM+gLGZhlSs+jlACJUzJGjoaMkdM5y1n9X/DT4QoXdGoXAmSB9GSlgV8CkL68wQTU8WHAyFmoI
T6SGTubvs0TdZDX0hUsWtZY09sFKDxucslfZgsZ4BMcL3ORLDXC/J/D/ANHpVVFdtYeilC/XkbI3
gtiOUo+TJaO1SmDTkmWeaKSblm0FR6C2QHtboR557i2lO3AosiKL7i9BoXlBlTbYEWjSrFJJ8we2
6vY5xLFMPSTcllmvQYXR4q2/C/uRgOkGu0cIZAPhsw7wvAfR/wCRQRbR6IxKo8CTNdWcifJ6XMsP
0VSfSQrjP+QtUyr4p0xpPTA67JFwgIRV7DksjAhGL+CLYqstDZTkq2rGAmXQ2ujTi5HRbjJSdlbZ
Slup+G+Ec1IAhW7VRsVdfA5TF28BmJcb0MTAkRMkCIT4HOezj0ZcG15HHI23sWR1XciVfwbi7Fs0
hnITSyNBhpex9DssQ2KHfgZCU8/XwmbMERBxNKGxFBULIjaGhZwNOidJ9mV6Msv4ufhgETYUyxUT
4OQwkVwYbMpodRlpcwfgP/hWYfDJMlg9z4up8KhZBB10HjMxsl2Ps2BuXe1J8mCPiEzRAUmiQTYB
8w0JSXImmyMrE8usulKD2WgojWxq2qNj3ktPRdFJcit4MbaZDw2NU3kL6DGKNWUuxP8ACQ2zjSC2
5uBgbTRkR2TFZlYIfVIpchwp4wNNyOJLGBDYVP8ADCDy2e8tFY4WB6usoery+k5HJNE8GY4rIhuU
ocGr0KVxB9k5MQXTV6QhFKLkgljGB2NNTgQsKXZB0nRhmtORxrZci9SPkaWVkyMnkZCq+KMEHEOB
h04wiSPQoHnbXIzh6ScCBKc9UZcZAr+kV3LqmYKM52Jcz1let10yYSRgnEOJRH3tyyjF3CobdBWp
n2xVKrIJPAG8VzMqIW2xfz25joz1qot97p0P4pFltq/QjHGWzAhtROFyM4M0pDArfgZyX9GjV6E1
6vot/wAQ5rNwbc4cbN1Ja8EPE5An5P2ylE/6JknKVMMFXaEflkTkSsd+TywLRr+PVHwLhEmcllae
hL3NQjtnZ4FHVVqJEZ0+xgX5Eov4nRRtQoM2NNsLVWIjyV8mzTFFGkfBqW1I9myxviVfTYq1heR8
PIvAxb5hobttvDHEYKYG8O48CkSJWsXTeaZYuyuGCZK5bFbT4FrZiJFu2PnZ8JvJDk4sl2mXfg76
AuhlJrheAydALKMxltNhOikmEEmSqrCsE6Ulwj1/5kOQx5BBBGVB6iew1hky9eC2yWjqeuRoVrjt
QwNmcQahbwd5r2Rwdl5U5GaG0aQ1fHCFaGVCJaXLxE995vai6gnAsqsI5kcCR1uJ2h6ClaFHntWy
PdFH9G1jC2SoW+u9o+B3Gz22NQNQWUzQ3k8DFHkTshQ/B3D/AE2h7G6y0kWx+Qw0M0SsnQIcBfBa
BuiZyaiX0IJyafww3RqbJX8LfJKPGyn6Kbg1bGavIvqx9ITozgLrk5GmBff4eXgWExhu0K4i5BNp
GCUSGkNGLq+DyQb5Gz6ReVJgeiUoJ7DG6YvCwSY2MWnornY8KjTA/A7yHkPAjTtRxV8DvbmKPCPy
KGwtOhmUOnMJcmHXPpjIQZWHwOxGicbctD3ReomMFeg701qDOttmL5Hpfi0MwJ8Gx04MJ44OZvYn
obNQUtNvYVjg+/hT4nEzkZyNSb3bBT/5QxyuiZh2oIIgxMIrjo+gyBXPyFwrpTAo6ttsbzOxKE92
GpCK3qVaKY4tXgU0me6IzKtj36CHjP4K1q3Qm5ncGDqgNtTZxGcPIgpzQUt2xqmiew9M78qUuY+Q
9fOS0tXm5EIolTOQi9OjzlOnkZwKcmYFuLoa3jYrgTsyeRbNPIQtWvvBn2LKSYjJ3BYaukJKRVqT
XWmJEdsdxPAe09kithMknti+61yg99mY4WNsSuGNqK5IX5LoO2UX4u2if40rg54P0RdfFQl8+Ybc
F7Qlf9A3Uy94KDi4lHFilBkd52LgK0y3Oehm3G9ijBCwvw5KQspylXQ0vvfkdcUNZWNZyh+e7AQd
3FzIqrlSJy/vBI8qxFumE4eE0Yp3ojzOCCPtIY52aXlD4nNIELRdZFJPKJDILmYxRhG+B44ex540
YutJ0w72DzZv/imDEzXVIz1bIq0P2KGun03bOa5MHjDhm3bBZZkZr/uUl7s8nfDOD9RgSzQCLI/f
LJYMc5DWnn+fEtBjTpHoew2phoqH3dkYknTAXNH2M1+jwHN6Z3k/hNNi6Knw2x90f3SjFsuWpWkQ
w1y8Myg9hnM9dj7nyo1pi6DjNNvbbo3kUYEbWDE8iZIYNwWyv7Lp2LNDShJlfBsJENGTJrJIxHah
iyJUPJsOMnRtjVdKWRtsTbMmx5Rpirwcp8V2E6LRaeDKZkYZfC61BIS6ZbA9BaZLcFYWsiyjaDqR
orCwx5Y3wMFGaYgzgb+osMWRLRnQwK+Bnsz8L9SErwLK2N2xeYLLpLcGpoSGaEsjYrI5GfhA2odM
xHFRTsGyjY+hrUoVvj0NZM4h9GQCJCtw/ZSDnOLIPsP0SQagsGGmLZVBT4Mxj8N5EHAx6EjdMy8J
aFmggKCSGnoU88kx0UeDmx0BdQ8jI9J4HGpoVkt3knOjLcFjkEmUJK3nsSVCZNBuhs0MqfSEueLw
K9y8nHhqIbEsONkoaC4kq2XWE4FuXMFp5PmE7zbXgZGjQY7HOBCbOyEM38KeioUclgst+hq+gJvh
qMXL4gIVPOYFMz9iIKvgttIUlw0WWiGkaoxLyPsmwTiQ/wAt1EFbvpCXufwSEVvgfJS4pGi15GCL
WziXsKwsEvQ8WDZOpi4scB47/Q6jVen4ObJRytMT225zkXpZG6cDU+4pRqS6HjRYZXBL0JbSonTc
sCTJ53CuphM8QxQyCLPIZyaKyWbyUJe0DgStaIIzlPJgUMdE9XBm5JGA5yxdCZD5qsfiURPsSVIy
O0S4qQQhZMYJ2tjKlajAtW8jqA2ZgT6PBhLGkNkeCXPAOLYM1kSAmSa1gSW2UGuhPTG9Gc/9Qyzj
TDY/td5PwchQdPBnI+eoUk2PfKiGpzXM+hZURaiG9vtKB/wOofj4MmPYXUXdGtj0H+hBE9E1WKwh
lbNDgSDUF+Fd8DJF8LN7FWvJY4NOYPYjayIPHsZnJj2ODLMbPsdLI1h8drBWhoaiFRqG1RoyTybG
118DNPBG0SEyZaXo0zsbmF0YuBbZ2PEK2OBSiT4T85Jkq7HYnJDKeBJDga6+Kex3jQ5DKtco+jIa
wLSXJRkssVVzsl5GnJCtMTa+i48knEUhRioSGs4vJGGPyKTSGipOCz/0E+yrGCJwfRgRsiSCxwSC
yppomMif6AgLDMU6+QrBDvYbbtG4LPswwyVlywdSKbL+CZmtFM27moWAcWGkcTemJOxnuixny5lc
iOt7kF4Z2HQizRg0K022m1oflEl4NO30J5NzoWUleBl1WiEdMxNLjQ71V6FCE5TIpWEBZRuFK5wa
JTl4Oa9afA9LNt4hSGyJ8V9FxX8FvLyfYpBS0RwcBazpVCC7oEoLNlt3V6MN5sFDWUwIscu4NORZ
gqzdMmk0YpSDCWRcZqG+kqmLG22dsuPRuSDO1X1FxaGISknQ4SOlBnmikOhWhZ3s7hGduKYQFPyz
FdOoKlWhFi/IN1DkmKxL1asjfgPGzVmo42ZogVG2cMbDTNCzfP8AwNq5gpLSFmeCisaY18GSR6EH
PteDGi8Y5HZnGXC/CsVGVFJnXbS5GugazoXLRCXkt4bwOxDkNH8WGIusbD8RSi8CnGeUVrngnJJV
WcmFOuqQUbgQk5aVGRDU2yBgWhLumyrgwqn+jvxzYbiw8707NiYoJmEgTgAKtrH4K5bINUqzLk38
NqFyrQRiKfQK0bG1yrgqxt4DHiovEeW/+FmKe6PWGc6Qsgt4TAqhdfIav5xuhAcMqyTrxGHit5Sj
u5dOBLhoqHrxDIiEniCbcFbRrwJG9EvZ2QfSMyOJAtHMctKi3URBIaGyLCD0SbCJoSp0osfHDkQj
3GksfDQjlkb7LscDyLWxvhCwoPHJwWhnwcGZnSjNvA+zZGj6D2VsSFKMmVoz7huv/A8qYCKjE1zy
LChexaWPYqmaE6JA10OqDpdCDJmmnRRFg0IymRrPwkRo16GC0JfgkSZsJdjyxvxonPJ6Ex0N5F0G
ceTaNpsaJ4Y9LsViuBDa/Zh5GHNN9h6nG0/hsZuDo1+vZIaBgtYM73l0TG0qpIho/mHMxt/g5pu6
MTyuDPexq6/hRQm9DWwlnoZJH8Hg4tUrXKcMHyLp+SrVXwIY5jZipXgvxLWGzryiagWV5W5Fi91f
hgFAuwy7xlwWRGkyDeN46JCIX7OAI4MCqO1xovsmlR+QIaV3cQ8ozBmhJRLsWryY+SzyrCI1gPfg
WHw1bfJCEEKIhBT1j8kxwXNlyI80vc/gbOTduTg9GY7vKHu7zY/hY13hnBOY9ScD2jSwEd2x4avk
NGNMP9b/AARDtsT3RuSYqxhmNyB9RHZ6huGIJyZXRPAi8DcEaUCIdsZO/QmjF3LbyIFhIbuGYBq0
2EZ8j/8AjHr/ABf8FPlwoakks6L8ao6NF9h/hG1bUT1MZE2LuUbxqDBybWzORmJeTczkiVpnCMhj
BjLminthRNsvMxwWXJBGQuakZG3KKVmroadSalCdSZSVkw/hetzJvBPIn4xFWi1T0y0WuLyODaGY
h7r6ZGo+fIi/IohbtQ6RH3Ahdc6hyraL5tLeDNATGOR6jKTY7QXG2Er7xkTG1Kp5NmZxPZY/+DwM
YlpRpHLbWBreu2xt5E9rX0WjJM0Fa2Y0NV1/2NSb/QVMYVWMMiJ6HgdoMbzlxmlQpSjVQRLuCC06
RlooKcuDh8isNQ8tDlNVmGODDGzasdKDEjvBCeCPY2SHlgw3Ro2h5ejKLdHjOxNZ7FkiTMPk2hPg
LNZMiiY+FKNrCRwXF4FQjSRxnA5yNQjQ0qJefhPIw6KMjUNDJ+CZNzo0NaKIxYV+B5kax8CeRwzg
rYkbMVWx6fwWUdELI20Tb4GFgS4Y9wkM/Rp8LRsWILefhwJRkbCgjbJ8MjyNbBj2EoGJPGUy8BsM
CYPISuMPJOdFMFE2hgnDfHIc7lCIFFulgb7pxnhAk8rg5JdZJvJs1DBjh1vfwQSDJWR9GlsVZGyP
jscms5IRd7GbA5zBMYjE4TYv3CDTcTbVaQ676YZkx7Yo5ic5R5LCdEbV7MLywOzGbxks1Y0Nm6Nv
WSmMhaOc5EmxBJb0HuqLjE/2HBhyVwfbRJxyqDEi+A/uFfFFqweQj2toybvOzgEMe24RxNb9CwwD
BqfQlGy0g9jyjezI10mBILXHo3pup0gkY7HbWPChN58skDZhqhK5IAsabMpDDmUWhMjQGY4Zi2Hw
ENx2ZCR0r6HLyPhGkkKC81aIWu0MpBvWjAuyooHsIqxOEIkW5hiE9Jk/BDIhjcMHob9HiHtiEsl0
WfB/gmXt0XCysMrHd+hi+a/wNWX3hWYX/kQtKQsRSFrBaD8PxFU3WZghkPVYmXJFnhzQ/X8guZHm
+BRawVoUDW+wqU201yJcyLGei4T4g/YK/wDBDMTAorIkqNGuBVnFsY6drgY0k9Jdkcldect+Dhyu
lCWs9NMlq1VeQeN2g7GpsKU+4EmxUEVE7Oe+55ElVL+hH87UGvBnUHLzOBfZzKMKEU7+g5sFI4Ap
PYSfkc1IIcXFU2ytNEzwPEu404uMBsOdqMi0izKiYDOn4FcarIKWbV4HKGcKOlFGP5mplrkRzNEZ
xdJdj2y1jXkbyXa5ZRzkTTRpCXNL0cViZGro8cio8n4okGp6+D2OsqbnxOw04zg2MldN5HEdtidD
V8DEkPaWodb18Bp28HhG0EzK5MnkfSHUcGxpMrSiGqLB022Jz8MLfwvoefglR2ZCU8iVkHkwwTyI
aIZ0QbyINBvIWj3E3DZvwLAucGxI9n2cmkE++Dmlk6G2Vm5gbifrsfOB4UQSQ7Vmzpqhug2Gx+vU
dwUVhaogoMAtni7GBvApNfuMMcYRi2C2G2rEh+mJ10YzCOxT6M67JkexjJElaZQ4WT+Sv2RPJDYs
KL5KzpsX0gpyMZPGPA8LPCyP6PxSPM7ETQbaEp4EJh25YKcKh1TPWchGlNk2h1DXcnDFJkMeAtZB
XQOScS6FA3OIr/TcK5/ScAM3TlJVyHx2+ogGV4QuhNe6KDzewkCDyiEGWkKqXxhhglqZAo6jFZ54
PJ5G9jWPQxwbbNuDF9+WUbgmQxyGnyJeW32PUUQlHsJiiOe2wcUTifAycjAlQvLG1zmqXTSVhnnK
QWG7OmeDqmiaVYYT0WOcsL0ZLExidir/AMPEkp6SERjzDWYNJNjFV5WTOC9Pi9vkT1GykmP6iv8A
BzWIxjTbo3G/84ElpBPwqP8AxoND4B+6UxxWDYymHBCS48GHJmavIX/j5gp16Gmjf8FkDgC3xrcI
fZctr3KOJ/J32c61r5En/jZDJNGJMSqnY/m44UL444alG87eEe4gqPky5iIYMUlgXFnL4K40YKfe
OcsUoKiyNkYel8Na+iiSfgd3JYexhFp0x6Gukq8kmkUHc9DhgtEDayU6GOC0OSS6FlhEWkP388s+
BHmpBi2tQl3E8RyGPdFB6CaJqX9ihlfY+Y3CDOEqrNFDN5GIxCiUjGUrgXkFJ9IWtsulnszsO7nh
I8y5/wCjrcG11GBNy2xjfrvMXaVlZosqlIXJHMZ0qRAlfDk8BPkOpI2wPBKiGShpwb7fIJ9DyHBD
cbFP/RtfhphogSQXXAtycCUUNaGudGxMZI1BfpjS7ElsiaP6SpizMHkMfYgkHiD4CVNQt0UvZfJE
jNpiZMPZtpD8hHDHjk2x8dDdRtPYxZGdD1TQceRKMfjZYxKI1vQ3gtQnmGmNiiG0b8CRR0sCQboW
QhYGXyLAm5yIk2O2mlhGXYosDsEE5uvIzinFwNPYGaDPZGp58iCt+2Niz7wa3kNt3JlEj7UfTyCw
e1qZLLK5BOG+xyokWQTVfI4vg6jKDhFohmxJLA6ircrpktz4H7qMXa0TYG0+xJwvGCVte0PFXBTH
9w1KWzyRxpi5tB0wzKtMlohNRUGKrkzWfwKsH0xFKa8iWX4GNKJIsrb8jSN+AmsIm9rgmRpMl7P/
AAYPJaeRejvsa8imjRkat7ZsVPTE0URSyn7Y0zRDKg63A21SGgEkm67p/wD0JDZ9nJyYfgcMBq5O
qxamho2yZzqxqnAqoTCimMh1qC3tZ9iS3kNIEuEMshNJJcCbCpD4oE0wwWorSwMZPTpOC4OxcoiU
5hkL5oNVuHgZ11alb+HG2iYqmNDiCSZp7gqE8jRq9EGlSrnJACUooUNzJZBl7Ew9y2RbBfSfofVh
sdsWxZapCShQRr2LGxsZWw0eR7pIfOC1hinIjB58GgIyDvIgcCcKeSH/AJE6HhDZHO8iWfBXcMHk
U5hLnobyPKdGUTyLGXs7Nj0vkwymNwvB1OctJ9jgU1GZ3RrlYEuuexs6KNPIt0I9fB1NHZlja4Fh
RknODLexiMHCHCuBYY8l7GTQ8qbHgLgaiLV0L2SYF2Dwy50IrSHgaJfCt9FymGsk7MCNIwxAejIS
/RvImFNBqoQ85OHwOjKfg7Dpou6Z+vhyEEaRhJoNaJgkzwKuDPK2KmODA0WBnL0JilkaGnsyZPRl
kryNMXApwMZJ8KswyXF4GQaIbjkmY38DZ72JgjvB5gG4Q7FVPYn2MbTi0KXf0JrnTUMprI1UsXQj
LH0TmKLcJuDm87oolMCTynyNnCZ8jqUF2vi2Kpb8bIHIZ8qUn4GnsWdja0Nsi8hYdHQ1dj3U4RRh
5o9lfBWXAsGhJwPHI4Ex4mUHhFOIroiVNDwqZrAqKaHtRNCYrFhCHAnLfIkcmCM2cGEG6NiCyO+j
gOUGQ2hcmA1n4yJJIQm3Q1EG8kHvBUkaVFCYvYm49mmUUTtyOeTsLfQ8A3msuKcgkbPyI5o+0zYV
+2yKhzC6OcP5sErZcjbo9BmmIYcU/AfCiqyFtjgTwh4RDtOUdEVMcA+CvkgywNsYylKEkRlkaYEv
JW8sTGRQ+4UeBdiuBUPIieRocGx4gmqZk3gbHgstjUw0bfkTkfGhYTha8k/Bo5KIXCYk5HTwUqXp
vA3FFlfBMUTxjZ5C5pg4jIUyxLgVyhWUWVkeQ2RtC3GJZRs8iBusibDgJg7N55FtfDdwRJhG/AaE
GsnNGroT7Q8khIN8jbEo7fgtjYT+z38YuaIzBRO4FFeixNbF/DlGQo8wey9HI76FGKEzbExa4YYG
ONGLyXgW4E9np8IIyRcFFkLdEqhh5HrpCgJe0Ja1Sa5Oc5hDCtgxmzBdA9G5pY6DnQ5DfZypezP1
HD72Kb9jQ6ZHG1WCT0SwYwRoZpwxUlGd8CSwazsnYadzobdYFY3kZt6wYLyI6hix7FhkguilweVj
A6iCfAv4J/C8bJH2ZY218aC6RIpMIKT4Y2ckx6GfIw60c/BSGxRaY3grpyhs+Djs0N/pLsSx2N5G
kH+Bs7G1BGCY3jGRqkejYSW6N52OlHjZKjIZ6HCGych+BlY1FQbGki7DHkSsVH0MZIxoVOWJhq+i
qdFUGncMdkTNLj0VzAsSrwYFMmujGRhg+gR8+B4fAsieMjoljOxt1gcF0N0QS2J5MvXZFzsh60YM
nPJJZWIyujE5lmzDEd8DlL0KsXymncF/B2O2husdM0sEaI1LyYnwfDRtS5MFbkpo0znwbeNDRkV4
Y7G9GuxkNGjalecYHW/BY+Dnka8icZBhgfmMjoOBQMyWx4EzbImVkZ0RgZPYsCYrhV0TI1RNM/yh
OoTfJ2DR55K2g0eRKnDAHNcmllF7wavImpkjTZoNUvw6ciR52LsbrEr38EqTi5HA0Y+zYkHy+I2S
FXY/JFwJzgTrVxDbtEs+B4hSMFsu+BoeUBD2B88rVM2I+hjHL2MKMnny6RW4M+1seh5VyUb41Ryu
aSkacKJ50DrxRXghK8j5wLA4CRvFM1D8hYJR0haYi2bbo0MY2LEp0KYbyPfwNxivyHBoHGQ7wxP9
IYucD1dGt5GmjTwbY2dNCwfJYLJ/Chm4IjQTUSG58PIX8MfDg4G6GqQh+z2NDgwEimmPZ1wNLjJ/
Q22xPvRcYMKIo/I8+Hax2RFLZuZLLGjSpk2XL+KlunBbILBpWOmCQ5kX0d/BWYGeB10KjWhrAmvh
JyPC6OXxbVOWSCUdDNeRLV6NWcCygljwcFyJpOtcFgOXqD18mHwbXoYHoc2PIyw8oJkGkQ7RqB9F
88DWIsmZRsoe2TndE8bHR5Fl8kQyvAfsTBH0NpOzKtFwQ5Hoc4LhFyaY8tZMWuTz4FkozLxwcbGw
ZPYxuot8DTFpz4Lps4NHc/CIQH7CL7MHkSjx8U0NsCE+BLsJDX6TBB+BLHRhtdmAnERlJ8jp/wDW
UZH6MsWkwa+MwVbaJzcHBHwmGcQsRmHsq+hESQ+ZoaUGoJOWwtYtsyiwcB4oq9DpUeA9ZPsSsDwr
pa/lVqzeUUzOfjbBXousXDhklU0xhrBlIClTkSknhcoV2HZskhR3wzkSCcRDqIW3MZOIAqJlOxKI
w2MAa8MtM8kvJkVFpGkaHAvIkLGDCRlkda7RaexiYZCyEolEPcHmWsTxkhyGClNFT2VcGydjGcCX
uQgm4VhIssSIyY3eBNx9jnsJ0thyH7fDTaPLQ+CpvI0o0kx4OFbWdF4DgTb9DQy0VN+Ta8kjog4Z
oPAa4lqRvR5Htiw+x7HcE8YE4O8YEwLumbG/g2PRM5MhdtP9EbwP5TJMWjyHB0NPRvYjL4MLQ30a
NjGoxOuh40J0pOeTfRDodOh57ImHtDYE/YeHkWH/ANK6OD0KMDyMBt1GuRsFzRujzhYEddJHn+je
iP6LBLNL/Roa3ga+xVyNK8EbeRrYiwt0J6PJh7NRTe3BMCex63BEkYS3noThj/o5d0YJEUeg0hMC
tgWR7VFGTi5HUsik7+HKK8CN5I6zGxvTNtiaRI6jmjE5g+xZUbngMU2oSHZiZI27E/QbBqB4NjBs
zGRsl20KzVMgkwiTZYKBuMx7Cx7E86MqFpFCVizUYIgejLWNCrC1BUeiWISjHfQxH8NNnjsStGoL
LBB4ZFwphgzG32TPxTSYwNTJKbCxSly0RueBbufMTHNezhsibvh03YaXdJ++iFzeKFZsemLsms4E
/Jt2I6tJ4h09IYkPh4GdsP3GmmNnBobuR2yVNjrwNYEsnTpC1g2po02bkycBsPJd+SGitirzdlco
UNBPPY6mNZ3k3gU+B9G0LBHSNahNmxbIWoTOBFk0NUZsSbZpjv4ItOPw7MHkgoNNpkMlUQSTOyck
LKEP2ZVCG1R4Ewd0JRMYakxRKMLVuyHgbm9mDZEnwlHuf34CprwNXIm2mRuuBu04hxjXRH9GYM2/
ZkoybbN+jajsMc4I3sqE1X8RewwnTINuujBRv7HJaGwbLpf01lDZhKLAg1kk+Ampcpl/4HvBlFgQ
uPg1c+SppLo5EFsOzBlO8CywNx7IkIThaRYKjiRMUkYavInjZdXR/C8CjwJf0bHhhmkLMwWwbF8d
NmxwzPBtCQd2OmVMthadGis5wXHkc90zgFTDZXk9DZ6wJ/Ylyjmjdq0hOcjjmjjKN1geBtpCDON4
Jn0Wsyg15N87MNjOYEeR40PKDZGUE48aMmhpMiXYb5NQbNDMRl4NFMSf0NhM+Z4MwSyxUkY43b8K
lFrImstnkeDEyI3zkyYnwcVSZ2WNRceTIWzsTUcMoWYatLs/5oG2erlEGVnUGPDGq3z0RPl0bufR
RDURBvHgP/BBHTxSuuTND8UdKv4ZETIaz8Ugr2duDbotD3gwGWF5l+g6eD0cOBc1aLUyWItZEmMo
yGnY2exXwKgq9jYtihMTPwjtvIzPCZXSMpCWzYQMrUzRf0uR+Atr4VpmypT0xnAd/wDZKfZjkbIX
DG8GQxPGimozeSuGDgoQLKMoMYLghPJs2OgtQSg69FpiXJF6ETJRG5Hgm4Hjs4CCE7R4dZPpMkra
o6kf0EqlrJ2OWDJuLA1fMHj4Em2bbXQpWRnUJPQ5EluCxjkz8pG/BDXsbFJLsVGq2PEyFN8nClnk
TQMknI6xBNDZBNUZSk8HC+tlR0UEnGVnBzjBSyzJXXJZseGh8kPFIpla5GngPZ5MEg2+cDfY9lrR
saXg7DEFG6Nk8iG2WnCp5FcYkR4i/R4wf6U2/jUCwyWD/wChMpmAjo8sxqmoyFqGTYqTw8DyNqPz
sgtFGLInVBpgu2KGROG2LYqxoeVBKMeWaapy+MDLyQlQkGGeDNFumeBJ3Y2yqnYsUeRqLYeRKDa0
N4KK7RnIqfQqjrH02Zcg6U4Jn4Cuxchukfs5LIzDtk82xd9whsU54CW6VpiVYwxMyJUidW7FO4VG
+/UxyC9ikLqEvBxCKDt4eiFqNdF7Di6GrNRJswbKmf4OPCGyM0I8nySiT5EJNjSbHgWs/CEb+OZ8
nko+g28CP7L9jaPs4KOS+K3RWjabFwU6rPZHsuZGKMBSYzFulptDbsd+hLnkTaZlyTBQm9DanZgR
ciGuTQpyIfJkLYddRDgTiPIJ5OSdqZTiFd3AijNhYdMu9CuBrJZwUbjG6/ApkJUuhRZG7omEJOGy
HnnkVhSBL8HEQkujSIwTEsibTTkbjfA2Gbz2NYlyJoKYJPJDhk8lyg2Ya2KvQ3r4UaWCMpcfnxa7
HdMk9ETXTKs+GpHUS5sEzbeTY9dGXV0XL7ZtgZeAqo1AiIdhG9DX/v4sRKWKGGwN9lrFXskNBBuC
bRbWdkjLno2MWMqUbOT8HEJJiyEGyn4KWBImbHvZYclrYoZmjj8HiJkvIsLOzbLBpjgXQhWOsxyc
jGTQsvA3RoLUhEMPYraKlCUcGYo/g26dRmDhS0yhPsSt8Cy6eRi7Ey2xrkQ8CrK38Nh7CELkjpj2
yiubkx2ZUoqNIwG8uhrgy0VqODdVEd14fQmRjPK2gtw2U49CjrkxTwh3LFEKvMqQ1vokKXkMLk7L
2rB+MDmCzl0O2jeRpCzkz5GE6qoPbBp2L9DwysKMtGQnCNhsXwLl0k5QoMZYZIuxCQTyUfANV4Ex
oTke3R/gkXaIMGYA93ZgyVWDMD/RkI1moVrXBkjhkyMF8m0TJsf8PIm2hxOnLwVvHInuuCY9EvI3
L8MoKhVhkZ4osfAssawN+SbAsBKeTWm/YyxvLExOmRpkkGAwqlDLAy1CUSvkzmc/C0Y6RCRD3grO
RnlsRBOCXODTTLnI3GDJh4Q8ssTpjA1W2Jmh7o8GWzbFbRBj9InEvsTAiNcCfp45H5GQlIRxsTaa
k5QtmR4WSqJESOseIISo84oieSpejjD9kjdZi40NRnIrfA3n4ZNjNbEc2J2ZNEvxOSIXk8hjg5V0
YJh/mHzj4Ya8mASyZKsDH/sbqpgkK3A1cm0FezKefiWEb0S60RRcM2aY+EpImM4eRum12zbA1jYm
gkd5GjipmWyhMePgyYuRXgawZs0KryLyYYmQjO6NTsNz2aGAol5GlB4Y9wRwRVMreEeDMHn4ONoW
FG8GzgpiwvjaFI+B72U0JGuRur4R5bPww0N8HCRqKMU4JMzp+EJCjsPTznj4K63MGZaVh5ICKwdO
EDMZeRi0T0SxoYzP2i8XJBibQdOoy0AdlWhKrQUp1lmJCYRNuWNjAo08iEuSNIj5FlbgWhgR7JC4
LJI6ZvyVN/AazsvQjeWI0WUayjLIxZgWhK4ZMmgtQeUhKjqE7OEh5y2ajwypuiTg0+A3wMl5HmaV
Fn4eR68mWQVo3sEqhoPZ7E/Swwj0MRta+OKYh/R1LCFp0ezISfYmSDyZMmtXx0Bbmx4ErNfIq3NC
eMjG9rskknEnkswQdh36RoLQ9GylaDUZyDGs7IbbZpDF4Lbo0kxfgw6XCFryTYUWsoadZMnrA0/+
GizkSg7hb9F+xG2rpEWRZPk0NDBJbY55C8MDasbywT2iuxsmn6LYsoklTjDzaHrWFyRuzQoxC6sm
bwdKc7GgULz2eTuS3wTeTaeSuZKGkvJgg1EP8G9QwEMNCzs+yY2Zig3HnZRqZ9nIIauRrI1Xs8Rp
tdDduCTlDGxgpImBPjQ3sNXOvg3ycjE/wURnyNBuezLgbiWE7Es/DYSzl4MN7EkvJm+D+CkgmvYu
BGUWhrYhkh7HG/gg2K8sbfnH3wJ5DcnRU14I8JGEvPwfAc2dKZRyiN8i2NGWvAlENRS/fwx3lEQ3
FbFwUQE27MnBHD4KvNH2TjQtn1xeDRWauxGJ6ph7JprdIKd3yMAm+mJHTYZYZKkngMPrKUgrsYTx
xGJiSfkc0yg6tegattiQMTHl5Z4DfZLn4UTAux4lJGAWRwh4eTDY8Qxo2sMUL4ERCqjAw9MjSoxF
aNKJGJB9HGhIqhWR2Hh4GgRsTGchkJMmYanwetC2bCRkzkcsbIQ0PIs6Og9I5DaJRsN6BE5G1oUb
HkJZghP4Tbn4JRWRkq6FI1nYla4Gs3kajAuwayYMTKsZYeR4+Egxg08uYX6E2UPGPhh5KLsVhqb+
B4I5DlwTFGY/obKky/gskeBUsMyCb77PLaGr8Hv4wZrJgdjNe3xNEh1IjYS/OzB52JRex3wI1GzM
vlgwUuRVIauXobqHg6LoqfodHXZt5JTmaJTQeHQqy5XxTpQbyNpmE4XjRYs6HvHosxRN50O4CbTy
NP0YZwJDdHEMhQNxoNhDNKjVI6K1TgaTQlZlrGjUfFgmlng0UyPLFnwcsi+RhsYeyKlJnZob6Jkh
PBGN4cyLvkqNLJsJNNig2D/Q8ckfIeoQ4WxMnkc6NJ24L/RlPI02twhpmiFkOCuRY/Aq0zkuRtHk
yY1U1y/i67LnwPERlJolfcGb0M3JQOILKZaZairJaXJsVDadWYExcOSd/wAC7M5hlUa9I0anobt6
GY0dRajX0PztUVlrhmkfOh/YU7O4eEcow5x7jgloZ9DqTJkhPNDdrQ8Cr0hJ0SjIq60WyJpgeJwe
WDC2xqn5EbyHSHmPY5JYHyEHN+BGK2VfIoE4Etsti8C1jgVvA+nhFmdjcU8CtmMQxMfDY36+BiDZ
kblymSmNkNdwqjJi+R8Q7yJxVnkVSIfqNtmfs/obobO0TcnP4L4RSVhey2PLQ2lT/wBfFyY26LTG
8TLqY1pFLWS5ktZGuENn1GNEN+UN0loyjyiqdGmRFutMSA/QhyiMImaIYf6in4RijSHKZB6V8Cby
GNXkYkmbR/Rk0YLkY3ur8GjjBu167MpVxeh3MFVpaJtxMPBlixk1yRR0VUUngeIPoRBTBGuBmceT
io6VIbQlGezwGU+ELGhD4Bc0bqhJB0K22y5GsNFTZMfwSGhbGLgaEiy/ink20PtbEq68MSwYYFzg
wg0eRGdRUKkslK8v4V9lGkaO7E1JRdhQcAsqaHl2bj2wf4NaCSrk0MbGOj+EU8i2PIy0SBOqJtiw
S2/Ck9tmF5G+BZRy+y5aamRu/DQ0OnT4PZZ6ErKvYlnQ+D7maiWHOFJX0vjPdHfCEhhLIgqYRnfH
xp+aIW1Z0JcSfRcDVxSoVOiT6JgFOC5xU32LIMSZ6GHvyLJsDhiONcjwImoQMBqopQqM9tjkJsrx
noRS8kQHYNS6YeiO/kSLd/RwwGzBga5eejdP4W1fgbd8CRYKMBZGButG55fRkAf8rEePULN2idXL
6IwJMg0b6GOxR/4Ktv5QwN/wYxiEGUdm4z7fw7a9DW6vUPEJGQabtT6JRiMIy9GQf8mdbF4Nvhy4
SOewyjyI4/4Z5vwRkOjNsX0JInl6MYAbJHbNyofwS7FVlM0Z2Ja2ORZq2FlZPwPjrTwR0X0L830M
4zwhd2OIaMOxDtXEMRr0ZINcsRF+Ai28pdd+CMCKMqnfgM4egypnbKlX5PoYGAVb0U16EL7iHoR9
h4l1TRg/dYGRaroS2r0oPjWudn12yKb8g1zLiswNq6DDB4I0crbhfl9CoiUoyQXBGlj4E5j8tD6y
l4QrBvoWuM/Bmj6oy9KynAvMhISfTRkm44Z1kkXYvcM8Fls83yU71C1uKMCe0ttoYJZND9aC2bm3
UGaOYeCrr7mYfjBYkFdGXDnMOhtYNVOw1rtcBdi6sYDz4RvYevAG2b8VEJyZ2sq0M56G4bT0O24O
kPA2IN8nHkeV8cmYl0YFrRBCd9B5kMT4b2qU0xkHDQuQ4yoON7FoeCT0PexvNEB//IZkjSE0wLDF
d6LWOpkXL+DT0PDYrYxwxMR8hWumBtHYvMbM8Ds2P9CeZwPYRyNfhhTI2kkOh5ZJCTbyZoyT4I+N
MfQTqIYyNlylwRMYCQ8BnY3Ep4ZF22eH6ZQ0TsmhMCSuyE8ifJqUvQeJs2J1dwqhPZNia4eTBBNs
PzjOWhliNJ7b/RnGTN5whyx2PQg26mBClhbNyvUbw5kejDQlsxReTEyJhyfQaXwLK0qJK6oaZcqx
wpEmS+SUeBJ3lhqOIOYsWGKzfBMwITFR+ikZtuAWW0sZIXojfAeoYV7A/wBlLgYLhe2IaUlNsrtl
9JCPtx4FJJVzLaM8XwhZ7B7RMUqbhDy6hJlqw0oKrDwQazahlhN6NONwhSx7TqMuEM7SL0TaSXIm
ddWCIp2hIPDZDfTeEjU5dmS+4w38JCEbq3BAX3loRCJdB5ztDrZB6YnVaQaI3bOsHDlNB+B9aYt6
NKF9CW0zL5dKERs9kvK9sjKZ+khfUKhwWTlsuXOktjRkyDTlbZLUl4GK7WHyVwWcBbUx4RZk2thj
KHaReWwwipUlLHSJcCPGNLeyKKyqjiGxOt0aqcuhAAfZRkzJWB0hDxplybczwoLruVIwpgqpnZwl
KTYxEtrS4Moo28witS4EhZVaxyPPuGsFErPBC2HIckR+nXgR1uRtg7gYRq84ZwsoQsGoTY+1PT+7
0pVfEgsMMRpYMHznYozXhGh5yIb0W12JLlMjBw3vAkV3iuUcWF1wWx5LlgQnZc6JsZgpLAr0t4Kj
7JrkTGMsJBPt8F+xo/owZjroJE6VBKw2sIVQuYyVmmo+RIE71sb05NIcFo2EP+TgQXHZkNNTwLsJ
3gekiyoJzhYEoqNb05vA5qTUTPY2oGSwhKuSoqpkjw2OXhFcG8J0VfDwJNJjebSlyOyCRV4Gg0RB
hQ0FLKLx+li+B7+FqybIk/nPPBliOs0xotplEZQ6qPgbKYwJbRrJGinCaPaGRKpmnnRt4FmSjehu
+yZEHIXJX+vgz0JUTrErHWPM4GS35LZBJ5NGZgaCwVCZJxCzBu0TUeDb6L0J4yy3wMGKsGLLxEyD
eA10PgZC1QfbRmBRpmVg5+Gs4M8Iw2FTbY2Ht+S6bMtTs0FPNDqhrtoNC8DfuB8XbKEmNtdC32x0
PQxLLbxBxoyYvmC67gQ7PgyW4Q0IKuwmtmC6TGP2NWRAVpiaEDyqjvFbpFNlrmiQH5jejW9Fyu6j
A5U46JO/6bGaP8BRTXgk+2DE8HQzSLxijUIzljQnFngQLG28NbEFXPkMpXohJQvZmR+WOIl0oyPF
5HtSmGLTD+3EECde+DN+8D+y9QVd94FBV8oWZxejSai5MVEaqTwNiVfTUbnB3DMp+hh3bpUQDOxR
TeSgh2AcWKkNqsOY/wDRql59hmivgXqO5C0TimrGGFEikhRRZG0oVSaDY4memHjI0uWKwF08DXlu
iZIjSs7ETPdwRU7+wQ3RGdJcciS+EeQ8+EhjWLHBJQJWFVFUrghKzz0MADJNIWRiuxJagj2Ta8MD
7M5RASezi3LsMMg+DopBKl2zIwpyfWw5e+4GKSg4PelEMXXklgbzOnBWDCmhO0tF9DU9s2xoR5nA
XfkrMR36XkXA43wzEB+8SKhRIlJNWEl1sRX5qq9DMxsQJ6a+Hse2+B9nYJHJXahhs2eAi2bTOR9r
Kt6JcHQhRdYARUKwUYlJOMjcmJt2eXxIQiXEeU3wA0FUnIgwWSHSL4DmFZY9gJkncn1vgpjCQ8DU
dUYdydpnQ+GEEmN6rlNPQuaJxIyTi4V2QPK6MjyTwJgtjUs+TwYq5NmBZZSJpHxckIuxI9jZwKn4
6Fevo5+iNrtDpmZx5FvLEMmbDX58YbHsbNMhq9Fo+TTsrXBUm8kV7NBtPBg+zQfkO2FroeGNpfEr
O2J4EsDaTGvIiZ8DRYFz4G7oSItBvBKNwbeR00OV/GS8iWIcrgaPIS1Rtpg2XB59CHUKshlLsaCe
obJn0H4wUZj6Fcoq3vBld/AmkxhTNnw6GwPRsFVvY+VyWIePBDT2cljHhTHDNZ3gV2NSUQfHZs6W
hBZvfy2TKjgjJtYxptnOzCcI4Dt+S3ROLUH1Q2RM0GrUmnsNqF7YR9Lse/oMZjNDV3vobmKERSSU
MtSKjabUbmOC0aqsVmxZYEuarK8jPl7GnVY6mx86x2KgTZVyLBG/Y4+koreA0m7WpwEFZy5GkS1F
wTtU6iRTiF5Ajq5bsh2mgG/9jJYE5EUx00pjB98YpodEguhbclhu7jtNdLGmQZvlIY1HkP7acQnm
+sLfG+Q0pDW3RvC528C6eOkThifcYndcJoTMWQGDX22J9HkmFpZCJhhl5VxfaKNJHB8aDmt9hobM
ahiw7E8iO8p3NCJavLHJmun2I7E5DY06XzR/vOyCfZMzqqlLicqrF6x4qH89vIXlc2Jiijxo8Fub
CEiQp1yJylhsNFQnfB4HGyfjbOx52XYZ4IBk7OzAB84MbuShRiXyL/dIoRva1hkY8DaMMDvkYFKT
4gn4bM9EJqThsepqGgO8FaywmiEjBnB+2qh4NOKi7eFV8FgWbcyubdlUFmZF2jqH+6eBvibbH1qe
DG+J8ZIUfNYXukZ7JbdMwemng24wES36Fz1KQS0xYVHqcB26z7MYxoUnxIPu6KbYkdFwYtaBXQmr
O74Eid3gS5FBFBxGNHKnkh2KcCTrJAtxr6Pj2pTRelcQmsXMG4Mrein29jWx9tDwweRBp9ImTt+T
J9uowTAXDE4o8PrKZ27Fc9uDNlDXUS1hweig3HLY1eOBOkqMtzohkWwlsw0Lk6hRz+EWhPD+Gk2X
IktDqQyjJCRweRisimyW8EhQxDBiywNmi4EsGiY2gsI8BJyPTFVsqQxp2OJkGWTB5NkVHgz9hueB
if8ADPRkLKHIvRikN0T/AEbxevjOS0sXwjRMmXJzWy0IexWyxUbdKln4WKib3TJ7NnAlMsmKJoNX
ZW2OihrEP9DcwPQzn/BVdvBmwSwZF5L4Epyht0bKNGYP4exwMtRmio8hafgcVuXwqc/ClkxEvsKc
r9jypi2mvwNzWzlDvB6oqqx6No/Bjlj4YnrpbwIzeKJR3iQsMA2muQ8zew47wNdDbyj2SWWSM52P
QP3DMENk4hI4ZMD3RZ7wZ6Y1YY+wqI8IbbH9CQJtLOjoiCLwNtvIqJNjywSoaaJmxUV+yto2yO0W
DDl+g4SU/g3iUPI+ho6oKVRDayYqtHM2PehKcFW8CipWMcoZka0siIWQTu/gQG46x9BOKCyKCyNK
jlGYQwZMhZaG6lDoLWTyhO3gs2PuikbHzkhOFAlQzexO1wMij8hRK7FBfgyhs5JUe3gjr4DfQWGz
E6E23gxcpDwI4tFLNmKZumW2eKeJhgdSZwU52OoVyHoTZl8Qra8GRdDF+hglPTNjuirK/DlXfQyT
rLhdGMjS0T8+DVXkqaLInQsRsas8iwoPiZIoQvM06Nct1FGsszh7EreDnaGOFG8m2hveCpk5eRFy
c6EqZhK2SYM0pXouUb2R4yZHaGRnHwe8CagzIZp5JbkyJj7KQry8CnQhqclRsPaYzeUJh0Jg4jFG
xnQSKMlE8kEecCz4TI8EIYENEk7Kg1Xo3GEuGXJv4ePgkhSsK+Q5LSipbJmkzfh5o2JUjwRke1wP
rYvJmfQ6cQ/IgyzyVs39F+Az2mCfIzTJqMlGNuRJniFdaGOVhpIdIVcDQwohGtvTZjgcdxMSPD0H
O+B7hQYgVYxYIDaLA1UPaDWJqEBJolKop5GlwUD6CH4cEAVYs5sM6HUHsUUN5GUVJSfbZCKnnY1Y
t5Y1KxjcBhOGThjkWGxWiRvXwjAptFpYFe5nrAjeQgSpuC05Ws8iVVGDUk75G9TfBhFekY9kc0Yz
VnBizThVlAe5iEmJcMmf+dbNo0yMbU4uB6TUKot/RchPJlzowqRlJM0MUMjecC3FEiYhjz9ihm40
HoxNcmVbMMQrE0PGOCsTCTWfhqYE0dmU8MZyb0SuRsKExvJnA8J4NEoOBOI5GJnLHeDYWRRYIjwP
lobuDOrg0sCvn4ZKIysvA1TEs1j7FDXItHRdEr2Es9mn4FXzgcWL8OCCIti/3Cmtn8DwoJ//ANFq
OB3Nwct4Ns8EHb6EolYZm6NNDQ8jEZdRfQxS0NzZMLkh4LiaQ38KM2ci866OrBsaIdVODZDWI9ES
8DeR+zlDyYkqO54nwtFnLwUUkMrXHA19Ez8coSQwthq6GhExTGJ5wzDohLOTim8C7HkWEPfisJFC
WJRnQh4zyN6hXyLJ5HbzkW8j/hcLoYESUHn2djLIdeRv0FiuR7bI/wDwMGYphPCGNYNuCpcujD/y
PQi4FYXLKu6YeORPDRrQXIjfgWFS2Ecg8hryLZRtzYoT7FnDQ9mTZvkTmORQ9UdW8GLx2U2rrKYP
pM5yYxUuUPplpnHo0QHf2oeq3SDRJ3BAswafAk1R1iCV05DtmxjwMz76O5Ay5YxU1HDSGag0M91R
0lLTouHB0eKG6RCljozuRWcEUJQpk+Gx8TgoVa8iALqoYAqZY8kvZk0bWmLzxPwbufo248Io8exO
AvcGtQq6HqUaFbQV7ZEgLxDJiEqMDW3IahEenIp3JB1vC7HfhX9KGa/cJcHEdtPkauWCGGm4LyK8
c9C09doupRrySVZ5QtJJJ6MJ+WnkdWOMjt3EcoRvOxm0XHoTQTiyxPOBobfow5HnexqBpyFQ3wLi
EKQ1UYZ5EzklxyUspbRhyN5o82M24SeiHsTSbcOIO8jnwUSrejIeK2WlG6sDwyOiyIn5G2vDoSDP
ss9/CTKGXpiwHivvA7aK0p1s0tngnNyNHzB0QS7E1psflgSdq0PHOTLXIWw6cD74g3kZplfexPFE
f+BUlwy2+xgWCTMjitHQoO00OeiMCzkbuORNX/gqloeYdAleWxI0YCb6Fkei1vJkmxzIaEc39Hke
Q2mKY0oWM20esiC/BNhxHgIkJt3gaDJYZYxBN0ehY2Wb0LOx34LLJqw2+HKuhp1+DdFx8jy/InnJ
4HoOw1WHhBYQ9HPoT3RNNeUPIwV5KE0h1hsZoO0yNyDjHwJkTUGjSwJZowlkv0O3pDyXCDzkz3sZ
ob9qaSC2Q9iII1gxVs+sDTCOS1TYjWUa5Gw5EbEXZiLyNLh0WINuYL8Ks4+DcFrkRPf4PKFYPo5+
wRPLRgqhnluDrlc4HaE6JoJxdciQUKeMyLdC59XInsGLhbXo9owYGnGTMVjkLa3KSEtN9juNtLox
UEh3FdOiijsIF6sWEFyKnkocnjHsVJhYJXSPAy4s8h9VZeyGOl20CuCLkUZiTYQCWOmcsuIu60Y6
sJVo7uhBwySBtRYoztIyb5N84GXSFE3nCGmnYZOvSWTx8wL9P35MK5xPcmfyiN3JN2RUuI9rWiaS
8sStrsegx9l4Jyo8ivk2+CkXikSRlu6GtBIPJGwnI3kyzOQV3YulFvIixDT2ZulfOxZUa3yL+hFS
jpeRJpKs4BRvOiOBEzEFVjqDyskEL6Cc8kWIZ5YqG6UHYqREaikS+BKN6RYl5GsV5ISlG29dlJoa
NjkQ6USG2h48FVT7HkgmkzlLYOoOBIMc7JkSaVG00SxBJYbG2sIyQzY2kxfJsyZMZEzzrA+PiVUp
PXx2LgcyMffxeRrhErQ4ngxDwEx5FaNZ8TS2JGIbzBZg9hNZHgWCFhiyH0+Ek4Eo8kqJGi5FlnA8
CqJx40N0RdkKvj4P9B9M4F4cGnkxKE0I66Pw6V6POPPQnXs2+jpRpoeTjz8MY5M1BNswnwWnn6H0
jIvQttHCiVeBODyF80mITImx5QtbHPsJ58HFEspiEoJJBQM3BY6xrSGWxeCxiq5yNJZRTSZp8WOG
ORpYIWFYfY3FPYWvkniNoG8DoUrVNU4jJB1ipjLgps0Lc+ExEFsYN64Y96LUNMjAgrOuQ+6ZGpVZ
FJMQeK5ZYWA96VexFF8lFSqGpVYu5kHbWnyYuIWXQszc1GVCiOxWPPN6FwW5kaFOQtZPQm6uw7v6
UYXg/gpTeKL6usrzONjNSU5C80cj4QWZ4GufIhWDkNf0StqxDarYRW57E7o4EjBkPoOLXkSeBCsb
D9ivA+PjILi7HpnXmE9m58HoKWhpUnkGfgjNKHgYaU2lsLWajznZgw65iDGhsSLwJB4EjRpGyILH
oXxmsjpXQl5JZRuxC+DbosiXwOEhj7Fl1mXeKaGm9EachC5GaY0ktm4JNjmxhPDEnkyGg4OBoN5O
xjEnHkfLI36HEHUNuZ0LPIuYq0JlKJM3wbvGh6PIJRGtbHTg9OxMJzPCFddDoiS3TBnHgirb4K9F
NG7iDxyPAwTkl2NYwJ0wvY49jyRtDRTgiWRqMGFLNcCv2P8Ao1n4YhzRuRNNIesYGqVJbHngQ/Ki
WDQQqJY9CeYkOmNoWVgYWjWExYNIyqOHgPA9CZMngTrxoX4YbTaIuWRIyIY6WxazcCeKR8No48iT
8BoSxjp52Yy6dqNVCbAmB2UrdDWDbJGPpF/+T6OCORM+DTfZY0MTl2N9juB4XY7CxGlOaxskpya3
svRY52JGZ6HU8Oowt+BUkmL0Bs+2NOubE/sPx0VMFCT6MprocTOgwJ2onBWa0omWClcDsTNINhXO
AkFn07GodVYVEpLcuEr8kDTTzJVt3g5yVhm89SMn9RXchSBrDyPavkR5fBTxVkQMCohoFH2jebwL
ECWTFeP2e9NF5yqCli3EaHNtEHpos2DDFbRjwLNdCy3nUXIqFXsbFwZoYEHLWjAUGxOhEFqkHZTP
8Fdt9RyOF2QjJcD0VButnBdupYi1kgWWDP4al0JVL6aNB1xhsZbK7FCf0YtadQXLLMlRIQW92lyP
w5RijioXzbIzQ+EUZXoqbKTpkS5exHPJywLUEs0pwJmMwY/t8CtgjhI4SaCQJ0cCa5wVkYVQ6PJc
ovWTNmDOTYaMo0JXBFWB8xrI9CUwfEUzliqtoVJsd9x18VsjE+xyjBig3SV9GwW/YlecDOFwsD5E
+CIhgsFzkdOItNi/RTZIwIhNN52OvsGze6NO/GZyVtjYsjNdkJjVidG75NCUE8iaGxchyPBwENx0
y5MoUxqRwjLRkGD0UOPho0xg6QoECdQklBSHRgby5PEK/QbHingSwPfYTsTOzlrbMULPQ7Gk5EMc
4Ofh5EpjY1EJ6I2yNclq8iwZKNphusUayOrTHkea6G4/BycuhLGxNKj5CTeaaJc0R2DyKXJFZG+T
llk8j5DcOaZD/QTdhs8/DjImKP0htCyxji2CZeT2MbpTaTGJ9mGvjSDV30TyJ4K/oarNBVqrn4ZE
WxGsSS9GB2IcMgmSDM4U1+8MoukbK+YU0tLwbk/RSv4jXLN9QQxSKcuyJtss6MFhCmhMCbBKWJRE
dm1S/wCmMDyClKPY4iyKKn2Ntr+CZbG98CTT+AlnGBQSo+u/oyYFlWG5olrTLIhid6FC6TVIDd7G
E/qjbdES8QwrSvQTf+xmaD7oSm3CEuauR+A1gNM5Ecok+OCkxgUexvwGNahaFC7Y+07yItK7Miiy
KpDIGXRkhbypOZYx6RuA5tE3R4DutxGqE+w2LOFJtOypDYn5D2LroccFDNi7kGVwNA3bsiIvUZVx
krKJrGgkKQeq+B+2CzEx9/oa0+uy9O1YSQrlb7F3N6fAxt4OY8iQyYNBjkka4ESGz1oazg3+F4PQ
2neiYwZIayZLT/0DRYEqmhJ4seKhTDYw9EL9Dl9jXAaUpg/AoZGZe30ZmEJ8CJbzBoZRdGhcEZDp
EUgqWBKLQ060jaCS8jZyVBTXZX9G0Gl2PyImhuNkeUPOxOp8HsDbGIyN+ii3ySYTpgiAesyQnnIs
eSDhipcDRcKW4EuzljbUaMkJ5E8rgw1kbJQfmEwhszTNOIehUMkDrgXULWhF8HeRNskWWb0X4a8/
Bx+1wdnJkNCKxDOQWoayzL0UbTNlJybHQma2JYjJG+iRdiSWzPaG0EIHZlIaNIuhi1yVtMEcD26T
Y5ogyZyNWJmMGVCzhDjIUeaWrFFgLbrPRmLkaeRFXNX4JGyydCsZM0hDdH1gxG4Mm9w39FyRIlW0
tlWludFcSFe4G9oankxi3/g1y0dOhWssbsZo1yNAe8C03ymWRjiHMd4HVUYMclgzo/wbGHlJfUGV
w0vQi1ddE0MpHAoTDVMtC87HxgcoSzQ/YbFj4ILLh+RBlzqkSRuXGiYF6cDGjhWC++mxX4iCpX0R
hU/BcGb9CGrVswxq2Q54+hhCQNtjXxFO5vQhDMNhn0EhM+kPLaaetE7M9CkzgaVhcinpgtlH2PwT
JAMCwNgykr4LhJ0KyWxRUn6FG++jV5Clvupi4Q+fI1MiNA5E12Z19lIMfRnCEHMawZVt+CuzfgrM
ydQZM5eDBZN50XNXbsi51zCgmB45TSjHdHBbtFd4NQGvwyRCy11D/OlkhNhJeSG1OHgZDGYuTGxd
jPzLAxiXhChmnfHRVxzsbOYkXIolqQRHTPwEFErknIngJeTAhlyPow9/DacwxN+DwbvdEw8jTT3g
aexwov0OCLRieWcmt6G8RGuGRryS6cY960xWybx6EuW2NRxaFhjQkOXA1U5HnaCfIwlXWWPr4WE+
WzQ5yydEQ8Pg3jJBvwQTwNDQwex4zyJueRLGy7Ow3UIZWw6Gmzkk5NuND0IKsxuaFeSTIsHN24aZ
QkXgTwN8InDHhCt6GcyUnJt9jz4NrSxVi4yVgJVnDplaJsOvgzpicEitNwoWvZyONNmbG4kgqwzt
DdOdDqawNVoeSUwNgUY5Ni+HHkjWRZMabEm6myYIlgTvv45WcDSE1BseRYyN/Y8w5Fgb7Cbkb+2Z
bNmZEqqOTLGnBRazs37FoN5aPZwxVM1HDLPsS1Ai7XCk4ts9aEBYhgMyglrQrJxLXBDBLkTWofIs
I8U+QkfKgubWYNWKtNDozD9hBVVaG1cNsZ4MOf3ZD14gyrWWWM2G8j61pB6jFEbCUHaPPHwOzVmx
FrgEteLE9hibslm3izCwHMo7xG08DszI56KNonOzqCovFJh+bXCrHazcjjDWEOqiLXwKPYWH4qLp
YJEXW3JgtlagzrWpJJM4sDQ1ODVNh9lLkXSSQgkiTyoQYy4FoKCvZRPIVi/ckbK8jmDdq0mRldiE
VLcwR5DS4QryEwROTwxoZe6pTX5MmzRjFawaFf1UTbWxTFpm4bvwQSnXFETdFswGyStGjDMdHAlW
42aLJOiPGxUjJa0I2b8ao+VNLDLRTeBtT1CqG3pIxhcDqc0x5ORKguqKli+SJ8ngtGJp5NWgChMO
2kYveR8XTRdfPI0OOJDcaKzHUh4zRACktZZ0UHgi7aM2NzDEsm+xpTHwNVfRhLLHefZmrfoz3sSj
2bbVZ4/osqbJkm8bLUNba/BcijlwLCycP9M8GvZ6INVgTgnicjefBDwNXfwWGqDlFQnUeBsYMLrM
0z0ex4ObI55MBODqRCQ5oyORsTDbrEvJlDBg2dClznBkSx5KF2ZKzIs02G1FdkexLkWhuDeabDum
inBwNaVEqiGTL2JTDaE+y1Msavk08iaeTQPkuRYY4RQvgaybCVeTyGp0N76OQnnBmoibwMcGXAjF
MHpmKjLjTwNNL7HeeR2dsaEgKsDQkZwGhPHkrIybL2P+jiseiU8jJNjZ+CTameR6EoPL2MtfYnn4
YLGROlnRVVm2S5IbwO0bxeTKNIlTI1V86GZxgMPLbgYHNjdqryEqVFYzRrdN0dVbZgxtquvjK0zT
/SnPwrbBjvk9SHMqyTFX2OSWaxr4Qz7F5EiRzTzpYU9yz4GmKeDb8nk/xKqnjAvRjx0PVHU8iNMZ
k215Fu2mhUG2Jce4ZmFlamyFzs4SMhYEe2JdMWdxBdlquBOhLsvckjJakETgE5YN1F7LSbODGA1N
mAJgHl0ajW4Mw8rTGd0XgovByh2NTWjqXCpToPabXS6FDHNH6QNXMkal7QMnbTClSckoRtQcSvsU
92h5YPwI0i2I20sDp9xkrYSLteScF01RSs+S11RI8gw3lYzFYYl8JTSwuR+XyCzr2Q9xVV1jKf6b
J09JQI0pcRELLoZy9mIVV5PwZDsfsRgJrk6HEDTcElwNZJNjA8j6IXNtbfkT48tnL1NRLI9Nhpvf
RyW0UxyJY6JfAnJFibXQ4+xsGtOWPDMMcl6IXIc3gg8qCx2QolTGERNOYGuDMoMUZCaIXtCeGKyR
BJ/RUHWuPg3BSafBDfTsWyMniF8YGzYnfY3GN1HIfYN6NtmMvob8INtexY0MmdG41i8ieey/oxbE
TzTFGWjJobOjQ5hsP4XJG0Jd4IhuCZE/v4fwO1N4cKCVGVkbG15FD+BHB/p5DTtJ0cBgICVZHliR
dEsYokxkpHJmpGJqnA3g0hqBJx1mxY0zga4GrzskDc8lGe6LB0LnocSL4ZBeSx/CUwfwE7yazsWx
WI8ZLl1ibHgjWxjsVTaQ/Gd/GQFDWcDmwWSPEMEGymBtVmz47E1bQ/OnDaEnN76DQnHRiLt3wUSy
0+BYBbAXMb0XLl6GUIalCs1uuGPUl/4HbkQiJ58h6wcBvGObUPTISgTsasNcFBlWMUCjbY2TP+y+
BJUUsXyZ2AUYNYFcjBP7Rd5E2xfZQKiUIwx7Cl/aCcTNaLlDvQyUdWiM7nwCv40mKAspjgsj8lgh
gqQNxXLFkRHeFdhAi/MGlrhWhc4S0nTb14aNmKCv7B6x7MVl38QYVG5248nrOhH4OGLt7BlL6Uxy
Fhq8kr1Ngztfh0F6aEDBu+At+WYKSaLNGfFZZ5ZuDKzYGcWEESRVwGD45I2R7apVK3A2o34SHt/g
VUt0f84ES6RMKmN1ydDJ86Y8VvIqLtvhDCuIkWdXb0Msm5yZeFUieSYvuHVCiZgvaMx67RXSjZ/8
BU1GdbeGIpeXyHOVWPSgUwFCq8kRpjqgl4HJTU1N9DN55Do4lgu6geYM2JiKIJtN1CUzFMDVssab
ZGHcQsBLngVetGUQI6/wUyKsVFUo01hiotXHXwpPuj0MiQywQzP2XY3kkENeOimCGgSvKMpcEtXk
vwSosoOXgZsTdEU01jAyQt5GuhVPB/Xxtf8ARUH6+GLKrYXjQ1RpodeBvJWJbmRvPgRjoMaOgiUJ
0yDwJsqNVnZgbw8kzkufA2rg3ITPJCxCXAjSltWhgk74OJngjaeiirJS5NkpwLIktY1TAHkTCb2e
B5YO5U/h8hHT/R8x2kZFBu04G4/Bl2PKwLGxqN2HD4Kr38E5DTSwLmyY2JTyYYLkb5TjLWqPA0zE
gpgaB9mXwJqosV+EHg2MhXZhDY+jJGVBvS7Mv/0b9jSGDbqz4PYZCNaWydhi1pbF/OTml6Hpt+h7
pXjIlqWPAyyszSrXQ1uy9IReVGXr2JhJ+SHGicUjzGDDJoc4PQkRmwF9irJ1VfY3J/oJ8CB/2Jjt
csdSUs9irbZGotOhpvQSeUJONp6YtQi6i0Vu9iN/+wqty9lwV+mPDIQhDz7NrJTeDDATKXijh1fq
OAfK2Gait7YiIm6kcOumHj8GaPY5C8tBvlAfDowkHwm39ktL7ErkyXy3sN5xgY6F4G0/YCpM8Yop
V0E0T1D1LqHuBNwx236U5K2umycVvst/8HJl6bKTLq6EZO32LOSXKbouxc0pxwdieC2Ei5j5F+Gz
ezfLYqag+R+hQ/8Apj1SIuFWykmsxibbCW7ka6+jNDDZVEtMvIzbNARSCNUkIr2ZLuXtlKamFwOb
QqMxkWk2YzS/hikoLVDr1DwvhDKfQlwlPJny6ZGWjUx2J6Fayl8A5M4FqIY32xM3xFXlzB+w22G3
ETb5HwesMdMxGmim0LIfgyMvB/REvKExOkdRgKS88DU8scZjTD1LTBZ3Pg3fRNcobj9CdecjpaHg
FzRKLY3gWpTLt0LD1RlhpSjcJUPyO1yRMntBG8nJsSuhEuRuDXoOEHU8kwRMn2FjkT2YT0PJrkRT
v4KqWMtcehKuzRwJqQ2vJgQ4jLwOiPKbxRibUw1JU1fg00gr8GaeNDvT4TwSz4rtsbNn9F+o2YC7
MfZxTmcmFrsjwjRfJj4Jk0KzJLsJqCWRWWKo5JsyDbhtrJbxkbwh7iyVyJwboxSB2CGZDzQoqltm
lOhTlNsf0r9mZQmopCvw+4hWxCvsQWDtRIyC0Z3gQ7uzfLKFE1GK7M1KJZ1XsXunQ1aBkpKMLuQw
rKv4zCB9DEvBMog8GZtxE1fUeK/wUYesMbWT/qhnqJaR6LVvPRqk4bNMR256GnjCpVkcq/BWSKxC
NMCUbEEqwTVL9C+ti0uGolkS+XgvysaZT9HPPwa0VCmyinL9I/8AERU0PcN7HkwELcJqUguGq9MS
2SdjwkoHE6/0KaagmrfkUIZbSHLI3kQWn+pEPyIr/AaNeSSGZmT8nM3RhGN+hnpFpG/IlNmPc3C/
9AlvP0KPT0LcD9CSk4KNVrwWZb6M3aFWU1BjcfgXmnc8D0GXDG1U77QgImm4HgDQsofQQ2nTufQU
krb8I5GG+ma8IzdvRmb58F03DzByw01e0Kd02mzVP6CLlehE3LtBIUm6Ia518oyqruGAa+h9hvA2
6XcHXJ+jfaPod4r4I5i7BvTLvBuReJIrNb2KYsbWx9cnHd2hxJHIQL93Jj0vAdxpZgSWD7aMOZ50
LXm2ukYDSuqtjXCeYI6x9Q3HaEesPIzeV4nJ1GmUWYdEh2/LGi2q8ws74QRy1Z4GGe66FW/wuxI1
R3YfGl8D69YKXxUL3E+h4Nj3v9Mc2N2iR45EnstFy+HBQ00XCDVDfsPKNlbKlZ2uS4yJ9GCVC4VG
fIdgnkaZiNJdjorEHlBh55wNwcJg4K09H4N5dkFkWu6SeiiSDX+7+CUeyJodoqVY9DynDgarGhtC
Tzk8nkjOg/wVjYn/AETdyTm/QtkJtjvY15FheSztRnrQuOxSj0b5FkEzqjGCbfI3gZMjxkvIl5wP
HBkmRP8A9jDnJHumpcMr6G7HPwbxn4vCvY2ZlZFR/DhQaw8/C4PcLfS5HOaZAGbEqyWjoacjzsil
yZgMyVLghFI+ohWqGIhjKEDCLjgclt5PokE0SdzGX/bAqY54HGJsyS5E/O91QZkV25E2LAijOVSq
raYu7PBqy7grmSfhEMGbRn012yZniQ+JeRMTHmxQypVnscYxy2iVWU4QpXAXqsvGhMTZ8IlXnDHD
WcCus6IciUvI1PaYQamIbwEIWMO9YHjSHiocYFoWLBKkZqENFTfwdCS+O7GFWGjapHbZ9yBIcN34
SF4i8rJtTekHzb0lswIS7bGRfghzb3WzDZIP528sFHPIJ1Gti1/Y4VFrWXIwwXNRZ67xlnHQ42Qp
W5hT6LxzSKq5uCIvEDEbSdYvMU1ZMjGDPSCKqLtlHUlcBibzSFWeR3NCokJhlBaQTm2RG8GSwUvI
uJk1oNJkX323SFRW80LcbkQ1bGMDq2VvAnNnNimb0olrmr0ISgaz2JrQtgiNnCRh1WuUJHd/A8T0
ESxmK1tn83iG8JyJDCO0cig7sjDTIpwRlHW3wIiJOA/4/C5o85lhQQLK7hLzZLgOJLoQvCZa4OPx
t4Ia6cRIUFHeaUa0uGqJFR94kEI15a5GZtXpGWnk2hiARluByTcxJlHURoiA3qX/AEMzeA2E8GxV
aXU5knoWG21AsnK3YrcrmidDSRLBUZ8GmCpY4ouBM6dG/Y8JldpUnS62uxfUQ02ZXF7aWEO5yUaE
A5SpofVc1wF7UNJoLwo6TwD8fjJglXmHktieDN40cB4mhVB8wrQruNm1nY8eTbwPCEnaiJliXgeE
NEK1zTkXSp4HhYF4GiZJh8vsgmbot9GGGcHUVRmiGkl5MqHwPEVlHmxKnMoghsbG6hyEnPIhrInh
5FhbOUZb2cZY2uD7Ha7s6BvGjQpRxHg1jgZbw6G6JPA8TGjZ2dUaxFz6Lge/AnfQ3xwa8jR7MM7M
RifgdeGiQNU3scG3g+xbG0/hSeWfwUVpCz4IxpPkek2PHstXkW8jSRoNf6EFPYymN2zjwZT0FBJU
eGPR8lcjy7HlsyYs9ixkyUb7Eo7BE9mYdExDApDMp5D18gzd8h39I0BFokTnSm+II+SRiZuhhcub
J5ZOQ/ckeUeftourAH3w/A4LdOGOJgvTMmSoTJHeGGhnaomdXsMajb2iqqhj6Bfae4gk/chyNjNp
ODyu5JZJeWPzdgXNphiY/Cs9HQE+co9DCSJ5HA+SQ3wXgVXzKF9Oi4Qo4nd/CqNrfwyo4W0HFVtd
se8gMNUXXBA7K83gTr6UHBYkSN3owdPKQaSOZBMVZhIjz5WOzbvaiwt2PIge9jTn6TM2mZCGR3gY
cqVvyPTHi0JBy7bg/tCG7+oEdo3Y7STyg8v/AFjlYdTKK4aXL0LulXCPGgorpPXLKmQuKGaDPTyM
/FpPFHQeAh3sqDLP7igr/wCoMMqrjhDnVI5FcF2wz/RaF/6wT3vQKYvUInT2locKK+GkKREmbont
PUokRrYBJxdwUWLIYTlF2+0klPXJ7E/rLGSs1jbgZY3Vo5ui7iLuTth+d+QanrpCIqqOCHdLOCES
DnBLF6DMiarTchVf2AKVq3JyL6itYujof8qCMTovkapHXYbh0+wH5nBZg1zdDONekimgCNr48qFM
EjepxRcsZGsSabyKme4EETUKVZ5GoozYDxBzdNMl1JcieAyI/kN8lCFjPjnljcqctsJSdtIMSkXP
ocpLa8GCughuV24zGRp0CH2YIbzSNPA8DvsblQz9n6ZtQofAN4eTDMDB+D8RRlsa5BJdmXgdQeUj
IWD0MliVIPZPNEMLvgmbfgxUPA8LsWciYGbbO9UayYsv2YJ9vkukcDRMZ2JpcHJwSPDEzsSd9DQN
yGmf6N4QsxdsubTBCWbtDVuDcesCQusD/B49mWhqUyeQuRZ9DRoXNE/spqeBvsdjYk15EBkNcmTy
MVmRq0qFQ1Q2+fiSNmAdg1ldCTKYj0+KltjJ/wDRipDdfBNYbLTlkrgXgLDd4KMYMNSxPQv+xlgN
1szYOnABhesxXY2I47FmlHxyZJzMGGmQkCTHZX4+nAab42MQ7THnb40mPtteRNWXQZFbPXwGIsPZ
LPeyyiE2dJckxvc5Gm1djRgR+RbDuDEIvgwxAmpRIJFrcshEtgJJ4cRdbyMnR3jLEJfwGtvzwM1+
pUOFGXWUITI44iNsqMHZjO17EFatgbwjEuN6E03q5GJntEAvQGvYlHsutDPnuGGSM5obPipjv+uB
J9A6kdA780D6zXkVHl2IEiWrMqG7WNpqJ5Q7qzE53UOBR0qdnjKZeWqiFOLYnGu5YgqK1gTGbhUH
t4saLYni5P8AT8hESj32LF6S7pdkvb4LBnawUIgEuyaJoVvg4YY0V5KMentWiSCpROiS+bbBmr4j
jyLnEV0Z8mBEKPM5JRmkmD9RPAxO7UrG1kKPkJShwbCWiFU7HbIvQtYK/R9wY8mY6eW0JXC2IZu1
l2dQJCJYlSYG+O7orAxVwiQqtcjnB8ASdER8jA3FLyID7XKScQ3W+8DVvu3FLdzWci9YZcjlsA6U
2vGZGMbzJL7nEIuqHyMU59ui5tCcJCW/C/c3ZFKnAYTgduwN4RgW5PmOS3MnslCMVxGPa9lBrjO2
D5OLxgLCscE0XoPmxoFtpyLWDabNHdGW40LqKqt3ltkjSrR8Cnlokh+WbC2RvvCIjs1VX/DjSbXZ
mzzNCNv6UaBArAOjf5B4ZnLkW+hPOywoluRTBv7LENtPz2TnbEhvDrVMFhlcu+h0wNNLDLFZqEFW
hrFK2S7g15wNZS2T9DSS2RxPJ+gnBkwZIcNdEycPcOhR6dicezN2QaA09iyr4IRvTony/gTQ4Ooc
eR1OSUTMPwVzOiGxDCFQ4iQ0o1fh0uRYY8tj6FsvFE6lyNxSieDQ5NeBcwvIU5fxN9hNe3xHPgLO
hJFaJzRThq2XoTMjocblgkli0UH4LU8iZxlHhYQktDTWEZECfBDduTko8YjWM4SHFgxDbI2YJyMC
fCGxrFg5jRYuw/oMJPxRRQetQ0ZGfYqFkGA3+sT4aOgObyWbtzgpVJrBRcYaMY7tmSa/YuC5M5lm
3k0UeV02G85Hhgl8sjySTFydwZbCbptmczJanwx1FktXvsTYnbyXOxu2Ltg832ZXBfsPE0Jgnlje
U2xvMpRLFNGUYsj1pjQq8N01geI2LdBXsZqDZVM+SusmxNcwxvobd8dnR5E80akv9LJ0VS61/g30
N6sy6GCbwpDGSwdbeSV3NLpTOGfZ3kTLD0TMNLfwMyMHdoeTwV+kEcJ5HhN+yyOS+gzoltoXsM3y
PJPyMtkQeEUsaPfA5Vy32JzL/gllVwcv/wAjU/BEhXstNHY06PgbuTs5REJW2hlJcjzCN5aGlP8A
wKr2cAofkWOfopXwKuUckTddGLRaxRvg4Gi7DbIsv+GXoS9MaTlHnAuw/oxZG89FHYKwYPsNOJrQ
2JwZMPBYZTK8HlFWyRZEv0Xo2/4NgMbcwL4Wl+0bExs0tFNiNqRcqNcJk2OIxtoujleTIRfg1nY3
UkKrYd90esw0NkiPEMPIuvicIX2DG2RglGIeDjBpNEmKWTTo0vbNIU1RPrLG2tBKiVmjTBzLQ3Wn
wPz+jrkqkG4jbJyJ5+iLkc1o7BNp/RryOxDYvwc6RH9CUYsdiNia+FCvkuWZTBCG4JQnsX4NDZsc
CUyJT7KNrzwRhhbfJKuiQWmfoy+B4eGJDt5MUg2EGJSHLLZfVVBqcQey+ovNU3kQZPkcrNwPcj2U
Lk9FRZwYbTRixeODA4u6OiV5hmqcvRFuGOKXWR48DouClc7MmudmMu5LEZW6E/OBuacIey40V7/B
nIeYxpt7FnyXjJXBQlo/CohKFfAbzUR9mGKKoQMsGYapsPcprn7NKsr4wNRox0J3Q8hX7JpXC2bM
ipg4wZd/hH9nByysNlwQaxTJRv1GhIsOiG+jBm9jfhwiH9GxBKJR5+hstZ8mFoJ1Q0wsirSHbHwu
b0W2CLrE3Y8IUSfDhRRvGxiuR79FDyujLngTvR5uBahPoa2WKL9opvbMFRSIZezJsYqorJFjNZO+
jL0IVyMmfI0jrsdu6psaU8/6RPB/QW9YOQoh7yjHAbvwVwNkPSNpnIk8kiCbw0hv8KayJhKi3Vgp
BlE2yaNrgTvWR1N7G+ChWmh2RzMqaG64EjpRvY1wFXsx+D6DqHhUiaEmhuc/QlHobz0ZvGhpJOCb
0hayOcHIjEGs45Eu3lnMJ6+DRirY97HabL9jkNtM8zw2aITQl2E3kPhHlk4+CTbJt0ddEhUG6ifR
WhciCVbwVFuoPeRdsquRxOhuspU7GK/o3pTeBOAsrI0aOh72RmcEHk1kPIT2hoO4E8CYdZm40OMG
SWCNpIkK4PyyjWvIjw4HLIN+StsTyJNJs0LWd0jWRPU2NerdF/R0XGeExRDXLFnA/VMIRX4QYgy2
hL77CNWBSTS0Q4jDeBwNYQTNqLws5yTgIRiy6OCrb/Bt7v0LKFhmsmVwJVtgT4KJYOfRtSpDTomp
5NC1kUYdNMDl2VvCMTJ/LGntgWF+HQa0KkJCNMkEcrs0wJ2NHzTR+BUqK3SV00wofYvAhRLQq1g7
CtdbXBO32O0xuOBYTgsjHhISaWjTRVHgPtCcqE7DiGPTMAk9jEMgM+xWvIyIgkzwUzyM7s4bMlgN
8BaVlaMr+htIJxjDyPhTJlaK8CEdiZyJBoHke/LN4QxSDm3RINtbCQdMy2xT/kHoSrzwjHkwMlqu
rfQ0bo2NlzUO0lYzRLk7PSG1gvwtS4HU8PgcYJIJ0XP/AASQ3torxkXgesiNZKjzRSoxUQuRS5Ia
FiTJgKsPHsqZRKR4SCD1kVaCDz0NZp5Mgk5OSZNyIdmR/wBE634HwISi+z8oeXDp8HXJgfJIK50V
IJLBYsCQJEoV/QnWxhPJh4uSRDFSeRYyzgUQ1o1ZJyNdbI1hvyeRmm3Jqkx3fKFhTijHj4LWNw4Z
PoJ2LRUhUFkNJI5OB9nKNiTbGNIeC+hh5QnUvhGWXBv0H8jdGNOxPI1TTNBsYM5Fv2J8EmSTJMEP
/ptxjNYPI3NlHHS4Ht/pX2Py8me8jsL9ib/zGOD5FvolWxVZpw3Iub2MOlJOxHLWrRs6tQ33R5cu
zjQNL5EKf57FqRvo78CywSC5PlMlVOUd5spSyS5dEZOA5sbJyclQSPdJjGSrY0OiJez1YNJcE0V8
DAx6tmSXA8QI1SzDQo4ZG2GNlyzzRZy5HwBvs0cZHjMNVFWbFnBoOyksYGsjsyYqwOJY2ZImMCbW
C3HJonBXsTaZlnZVHjgd+hzJwc6PsFj2O8sDvBWN3kT2D5IW18SLWbeTK1idMapachmqNwRNuRhv
SDWV2P8AQ7rsw0U0JjIs4W/hvhgqSbHTRy1gdLqkKIhuXyV10c7GWjV5LYQyh8iVYDavJEi5y4dt
cjy7Gn9E70JMI1MxmpsVZYszHGCdDeyJvhmTGjQnZhzgx9iRpjmBYyj+A2KlSysRCX1Sz7MWUZhO
BOSEnwLIYULsbJ20LDouRRFcLkTNNMTqTM8JDwU08dj8ZY1f/BLWYW9n6Zh6E7EI0WVbF2eJysid
ZpPkSR38ZsGKj7FkTEsvwaE2yQceRSXsk0Mp5Cxr4MMC/wAGyJaWDlUxs5Fg+X9C5ZZyRtjTF4LV
sesjLQ1wa8iD6BY1yQmq4Ycice78CcQbSyyKBLg5MVB1i3GzWxtJgTvkaEwyVeSOf8PEMqdJwYEy
fgfBpiLKx3uDejFx8LGYK3Iw1VFRjAbTAXJvgi7Ox9CzyYKMrvA1tT8GDpyZlNkMdLwOH1lBwaxE
icWaH9X0EMhE9H8AkhaZ56Ep/LYnwg1Wzt0qXA23QubCDsN+KOyk8C18eqn6VFiZHVKChkTXsxC0
Iawobxd+BM5p+B7lHls2x+fCtGTHTIMyXggJBfFp0dPI8jVceS+8dCaLglGiWjeGZ+iPBjCpm8D8
BM2YEvAkrvZomsozT/Qg1rYzFjz/ANDRQZex5Mt/DjyZScotWjka0IhLtgTMT7G40LkynJCEo+G8
HgWjU5F0YPY24V2YDeS4EvsN0wQEotyLZyY1dGvYybZCYsu9cjowBdrJ/TG8DyPf6L5Nzda0LML9
C4cyadb+h6u8DMsbFnYuIwtmmyJsTKVRia2JLX0YqtlMITqnJtZ2OpDLS1PAmN/DzkWAudFw8lxC
TRZNsoi1kXXnQ/ZP4JUU5H4Fi+R4wxCURG/ofkeGiA1VeyYfA68kSyhPi0yYKKJ4Iydi/pxGRp4y
ijWyy8iLgmfJlM2wxp8LbYyyE5o34Kk3yLY2VHImboecaEsjwjI8HZM9mmBLKGuORacl3wLIangP
oixtexomHSJpf0q1R5xE5CHDgRHQ2heiXQ8Yq/ASrY8GQaWHyKZ7Gxq6P6EqvI8DwiJByuSXZC2x
sNQL8mJ2YqHbeGNWkcQwrsbarZVowZwhbdETYZrs8uD6PLRCY2qvA3gpsMwGsEccCUEPyEfiFpZn
oYtrsuycTgiyiyvo+B8nA1jRRWcXgbnt0zKD4EWrXoiKllNGQW6ezzCbIOprBKl1vmI14IMDMM6D
rG+LD3KYt9De+R15Gq9nOBdBB3RmcCgTBkJYMg6bE4dihzZtkag+ozcePIjjBbCRDmRSzSwwvk7V
K5gS7PpGtGqVh/Bul4HkiYYvYdMesCuiSZEsbF6OTgULZ8mAdTAJeg0hn0IxXsWHxyiyJsQ0LCjf
TYmWSM2Fky8MbJuQ5cCXB0RDZ4FpZyNU8U/BBTkOwopi8obPExyNjIN5EWGGhF2djbMLJ9mbuyPT
DoTjoYz62ZMWKo8mBolF0ezIpO0T3MCX/oy+zGXgyGdmdrg00XwYE1mCryG2kXOxvlcwtLE9MrN9
E0zgTzDJoaSfZnJaHci49ErvCPJeSZCyPEZSFl1cDebNZP57LBt6aEI72V8DRc4EuhkqZNv+Dfk6
uzE2dBrk0GVwvg0ok09YPYnGTBGJGKp4Ef0NjAtbFliZyofwR344efjtow2NCpj5GBo02JRjVm/R
hyVnr4abeDOhbv4PRwkiZyPJl+SzQeeBJ7FT2IMhjYnmscbwKfJnkQbqs4cDDTawPPyZqiU5Muix
2LrgarZkuh18lL0K5NLz2XIw15NMrbGs9j70IbbFk9FfQ1PPwpNkSg68B8Qc8D8hgHl8E1jRuyIh
sD/bIZDknKh+TLoXOd6EyZ1cGqPKGKefoYxBKwY6KH9RZ6cCeOVw7n+CeryI3yKbv4iU1T0JD/gP
y2iwkHR1UW1opgJ3/hDGo3cDo0PVyNngWy+JukmOiFQ2kuifQmR5j7Z+D0n0Tk9clBNQrXyNi/g2
BSzkYqepERHRIcibuBKOncI7D6HQmCBrQY28jeTQ1MimLJd4IgzgY9Dh+fg40Joajb0XURTJ6Mgz
/gKkNzgZWRyvwivaKFWLx4GNleRhw8jXAZ4cI1kejLZ2YK6NHktQpyyvNdPYbb8kwGux+ZSWyfon
hkUjHA6m66hrBrCKZ2aos8zyLI1ofOgnBsbVcuTZpjafwTWEZcmWuIKvBhgafQy8CWdDMTXwyEro
hINR0WXPgME8jXYcS7E1Ls0cVHsCFEaD0NVojLHr6M+hJJJ2jGETJDyvgrYg0vg22YLqjGrk2UIM
lkwwohHHBkgsMWbiGUZK8oThjQ8Q22FIkbTZvRGJWRWlsQWn2L+nIWdiTo2Vi4uhOrZryLL2POhq
N4GiWigmRlPJsmR9QiZp+StKcjjeSfh5QSdm2DC/CEzkbjsYJueDN3gednSEk3ksuIO7GUM5emK7
PIpsPfgeKFRVwZRW4G7UE8VOaN+4cKZGw16I4jyJyZIfCvwsp8FbsWZ1mnzngVyVksIR+QsrofQz
CRm7wZHBZOUPEgzZS1CvtO8GbyolmAUoGhLabDinf/Mr5LBHTXArxNeBbxaQiKpMZ1X4fAkiRa8i
2p4McBzTREu0yR8nPR416IXa4F6U7wJLF+SFSO4iKIWPRlCPI0gT1ppDUmb2Kdn9EwT/AAaexef4
K60rwhzS8rLg8wqD8aFeDNpLIrBKizRUR/Q3C2vAorqCRtPuDtpl7+AjTpl2L8yWTZrAUwvmwN6w
O5FnpHqJA3dktwojexAUPZFW8iArwFLNXwWOXcGJL/CDaMvGvI/2xW2NUQyx9DhUFRGw7eYO6gua
YC+n1BQ216EPwXoyNhPiFHr6FyvPRAb20IV/geGMDze/GCCXoShREwHinYNVbruDHg+i90yPoaV4
LaEFWRokMtcjRU9srFhlonRbUNI2gpd2chCxnY3Q4JHgWvi0ZKqGsiMhnv4J/YMTweRrONGdGWzH
W7oUbyRQ8rwX1DYbQmRYeBafsUY5HtOmbE1the8EvNKXGR4fBvI38VFQytmYbCVWR5lDYrGLFoz3
BLnkawPE7IPPJsaz4Eqzt0X2wbWRL4pSK6EjLfin5Jq4LnpGVX8IfBjs18nkPISjvAl5Eob6E2sH
Dtl8iRCTkrZ7ZI97ETXnwaHdBjIw9OCGtjhofQaqNZFaPGaVIN5Wb9Eqb0aEmRvpF6M5M2ooGono
w9iw4so08CvhmoNtc0tFldjSy7kfmZMvkbxBaD9vovJi6fJDYiQbWYJJKqdBUdSGD2eTLYlNhvPZ
V0NV1PfBlCfCjU20yNsmx8bGHDI9KisroR7TD8Uz1wxhjwQei4H0kBiQ5gnkRcZPBVjuI0uhHOoM
KFuhT2VxBGkdqKI7ioedcI4DnJ15GNTO+dGoLljbzFsQvqmtK1BbwhXMdSFXKpIj9Hoe416Mudcj
PqblhWEk3Ug8OJXJiJ5wpvqSGRc00m1LBVpcWGcRTbEHtvIj6cH2MOYZF8jPCfY8KfAPDIsWEDrr
gwrwWdik0hQh45GSvHbkj6TaXIhU6XYmV4dkB6KH86G2smnEDfNcrEME8DApKWEO/NgnHIMqwM2F
al5rOa9F7FN5b9RlfFEvI03fGZNMMgF5dG1BUk0Zm57QcxdryD1dZLkz7qpIbEmLTRliPwIDoJtC
eUKipsIRUSrgYc9QVEOR0aFzLanoLA8GsK17ODUlsU7ME7gTQzdOtE2YjPoanJQwYFlQwcNuTDeu
xlrsdpMI3lkwX+BdjankeFQwuYSLIwzfAvK2bdbN6MIQmTwCt4WDwI3/AAXe/AtVl7ZZvb7E6GPA
owNJrkSvOS0Q9+yJeXQ0Trkt5X4cCxMivJfaM50PfjodZyWPg+7jwafaJtnBh7I2MT8JjZk94I+x
5MhukZtWqRBkPsSboQOYCHjlDdO6ZwIYRUnyNyQ6dicwOvQ1joai0ImQPFmfIk1yJquhwUFnk5hl
pns4GW+x6KPOSum5sydGoVEzoEkdeCV7H/R4Fr8GA1wO8rFG8/B0M2aE12LIt3oTukMJkf8Ap5RS
mVoWzsY8roQPAm3rkrkG4/BG3BHfAqkSJfLLj4JF6LcIadHlESlM2oSGjLj8Hj2N04jb6I0Rm1co
bPgmRqU8ivsRoRJEOZE1T8TTLZm5OAyZk6NvEQhXWBSScLEHQ5yK+X0qMa4ayhWVweLESC72Fpti
HSoOVtQngtcjm2qQ6XQ+50wNpMeV5tLbukNVeFrJDBa0TY92+Vgv0mlK9sCQqs8/G3IZoYWhchFD
0FNr2hYF4CXDyEut5opzrbaPqECaMnkNzJo6lo3sNCSPSyrG9mKQlFosk6OS9irGiTiop7xSm43Y
YpO18Ctcw+t1kWgTgkTrpDtInyNbjY7JBsiYHq2TYzKRVDyUbe0ObmRK0s025C/gWwaS5YRVarx8
LY5bwMd2oyyllwzCoCOZfRlfC2LkfJy0dFNKlKZ0sK62M/g4DjaOhZTb/Q6Jg2g8vrJ+g3J+xoqL
LhnC28jGtsSU8vcEV2mSjY7qzoxZjg3A0ylyP2oxcsqbHElv9I2WCNNjXZ46XIi9+RF/C0mvIoUK
YhiysBtYHZs5LjhiE2eeiNE0/ohXkjyTnJUpmmSeSpuUTohsnOx0nDEmXtiDyyLVghZeYP8AYOH0
jeYcLo58EsWkJKO7GmhJPlGVUlkxwJY7MpCeNZIWy4jGmkZ6x8KMvo2LVKIZ/DFWnYSlPE/03vRp
7g8rYp6KjM6C/YSG2VeA+FEzwH/RqxrR+UPmjT4PQPaM7KoR6IesDXkZo6cU8DSG9H9irwV4KaZF
saiZ4NPsz2PZYnJcjYxgkHORPoPKkx2afwTBcmIdxRh/BZgnOzB050aWjS8GKuGMfVOBIJKDwNTK
Eq7E4LeymqQFU4Z2Y6zdcH9MdCtvI1Xg2+EBLhPBNHgaaMmXEQ07GsnImzHAXG9iQt3ogEQeZtpm
2OEJ3vRuHditIuWJqhIbap9Diw98DauQnRqEUJpp6Q/YOycZ5VVDI1Lo5g098EvHk/yGg8NM7K7J
uEikzs2JqHS2NgxSSSS8JCHrhorqvYx5L4exrTCSjGaPtDwrrb5Hcd/o0tDyGrH8neRtUVLCJZiC
4J5IdmhNpLlyyEj0rsVtnxjHWdESGLOEkUEG5PFzRn4+J7KDWi+LHyb5RsUi8bkxgmmSmoNioecO
g9aQtZlq6F8U1R5l8Rst7W4wUrIrQBog2eRl0LXk3iwYU9NDJKl5C4osgmzQTL8+Tg0ecC0wnkMH
KTGJMBjTG9BV8EZiKvLYofAV6NBvx2ImM/gWhU3wZ2UM5OR4SEbz4WBCX5EkzYz4Eq1hHI8v5HU/
y2OUmvJYdck8YhdXUSGexBeQ/wCYgEseCuKfqcTljG2WRew1eRNLH9NPGSTAt6I2ixDb8ivwNitw
MTyjn4V/CZGJ3eMCbtZdkJ849FaedMg2+zNgSx4Eoky12J39OfA8rYuzLWJNcj3kUHjwsjbYk4Hk
bdCbbR5byJtvwJxsy1f6PL+FTJeULm5GHA3gWUeELrcFvCMF5N8nAnnQ9jwMMc9/BoxPY1Xh6+cy
7RHfAo2i0cDS8jYaZgOIWvZpdsVYHCLbQnAQY00qZZ7G2c5YmuQ00sCw7vI8MVVwJ5pIYlz38J+y
5tGrHMvLYox5YKTMseb4+FN+BcTwN6hUnoeEK0hJy/i+1NsizkkcFuJVCbKhvjBqxlum1lDTQmPG
DGBa2hq8lqY3ELK2MPfgzPA0Zij1oVyZB27Fhz+iEX2RHsQakzNltE4tkPnIzuiZeODx+ROSF+ZY
zAkhU1XmGg7BOuDcmKNZP2iKGkhDgvoZwGs5SH6ejsl9oWOhE+F9CXFG2BX/ANCjBKEtCqbn7kT7
FrwfYmXRvgYmW0ZyKLrGClnovErErFOdcBPIvIVZRlFqCmg3h8ic8pMkY9MdIyUQxxg4uHscLCfl
DK5/RO49Etb7Hm7KRMjNtibODNZg5CCxkuacd+GK6HyH9M5ivLIuxvKn20ODX5bpX3C+1/pLVTyM
s67G7v4Lvo3/APGULR1QhwRCoZX+jEWAgmo9m74bOBvl5IY78E4OlpemMXr+hncD5IhXSFpk/dGw
my5tLBsRDdklGMu+qxaaj/6lO6JZEhhhyiWCTA9IHIk3AhVOfZl4uTlbPYuc5NThyZRnvDJEq9nD
An+GjpM2wPusm/IZ2Z7JlND/AN+Jm3SGy0NtuP4JgkzPHQ3oMRteKO25gajY1S/4Pfs0oJB6Ymyx
t5+h18qj0W0J1518TeFTvJcMmlv0LGV/RbSDzCYGnowQpCnOB8OezLSCwXmGlwS9/o1k+RN4CNaZ
My70YCwdBxjIqmV2NxQ0P4cIKkN1RMmsIeJpsaxULWDNFhmVsf0+NjJkl3Xgn4aYMFsedmZeDgMS
9i5pN4MPYlTIug85M6DD9knYX9Jnf0L+iBuvKGtcHMEm1RatGXkx4KGlVkQ1/BvkeFyolkX6egNL
2GiyVot9jqGy+HvbkRwxViuwf/dExS3qhuFxuiyXMMNPi0PMKMo8hKEMESXkkg+fhlXuGeeBw7E7
Gh44HgV5wrn+DyJ9/AsbKVn6FsxEpyimsCG6RWiJBXZhtnkx9itDpYMHGKY0lsvTILRs/A7kza2O
rbQhtnALfgywbHDO0Plb4GRHyxuySwhOl2UkY1+A8ND1vJJGc5Yjk4Epoy2yWrJI3joqN0Mt6FWm
DDolYeyzB4McC48l5pt7Mt7HakzFnIpGD4MND3gW3BpC4ZkKLlGi6K5Rykd+CuyPYNtti4G69jyn
yGKyZeiEw2PamDlRvwhJtn2kVPkyNTIyQSrHwzDJtwRtR5brPIQmQFWZ5MNNNxeBKcjyQ2IIuWWd
jKcDSM4hpLSzHJpEw2Q0bkl1ogOZs8oeslHSK/Ynp5nIsZK8DkVCCja3gixnBo7g1Gf34NiwoZD0
hsjkZIeX0J5aEziChaJHm8jfFF+kTo4vI+Tkam0weacEMQvwaSEVDZL4LC+F8ZZDVpwcY0QGnnJ2
D1UJ9lCNPKLkPhmDtHmQW1dFgMeyExRb2THsXZW34P8AA30E5iiiZKn0XoNG135OWi7Ur0OSTk+x
u+DyyYMufRtWI2LQWoVIkVY6uDk2iwZNnOkdjScd0YYhYbGJBxoaokuDD2znZjseJFUMXSW+Rq9Q
UeRBvEW6V7eWexgmkyIuaZehQpaZcCSXkNWI/JX9I05wYo4ujTwy+zLFFMcCg4yI7vHgX5Bt/r4t
J8MbHY/ImTLkUIxVUxjHTtwZOaRpV2JCceCC7MEk9G3dG8WEFSLT1/T+w5CSlMwx+yKeRko7kTrg
ru6PCmXyY08iSFIjyiLAk4NvQqWCqZGlkhDCQqk+Dg7jPIXkKtvBhghs8m2MiWTTGtO/hhmZNeRX
pmGldrg2grHZNMXA/wBODuhZyEGq2KMwbeBvA2pnZ4M5VmGMSvAs/wDswhb6PYbzwKJvk084E84M
ZQlFeTcSJYIa9GHk2DXDOx6FujPY+NmhI23pi4yP9mBjeWmZGSiVbyPDUVuI06Kmn+BpehvNGhzl
1FHFRTS7MIa4kPfwJ6Leg6aSqEqfQ9iTWbS51TEKPY8kacPOLuJb4SFOMvheKYQpcj/+Meown97o
aWHDCQnYeGxX8C4cocrJzdiec4FaWzSldPZrIWVgST4Kux8P9Gu5LgR+nKo8jJODBm0T6EVhI9mx
tGGCHkRyj14FhgcTEaCy6EJdm2zSImTSyZ9kcsyuDY+zKwPUQkG6ERLJ4+OmMlNiecmbxlFtIrsv
wbFVNocuyqEjGqa8jYZmSq6wJoTajG3RKtmpdCXNEmtnsL/TkhxORZWRjeS4wWIbE9nbbMkaZ5Te
P6JzyKS4EntjZKx7KLqnGxNyx0YJiehbSKbwyVDb4v2fcsFHvAlS7FoLS7E/IlDAxKEhtitaMgae
h6lY2OxCwSJvBYQ09Frkz4yac5MnRsSSaQSNP8E9EKMtUYm9JDbJsv0G8DLMQuNE7+CssKampHA0
hOqMDyasMhvLEg2NZMEJDRaCWK2JV7N8mUY1eTSaXZxFkyw0WFU8oeEYsRC48DvocJpQyaOhPY2+
A3tf8I5UfkVSwXRVgtj/AKXob62LY68cFSq5JidlDbYzB6GoLGPNEdmS56D4PQnNZHHsjGtQTozX
Bi7TR6bLlg20r9mbhivIvA0WqDDwXB20bonsSJyIcFfRgjQ2GRGPCXC7G2eBt1BJpDr8EDbY36fA
yTE3/wCQ601vItVrJkymf0dr/wBG+hG5LZnBEbRDwv8AgvUN7omui9it3Q1okEJcjKwyByy5dkrs
fDTJstmCLpk7MTNbQ0ciBJp/4KLEkXFptmOz+CZmWhDfBrsRM68FSYlTg2pc6Flkd8FMZQeq02t4
O1E9j4xsRjDFli4MaaSCyqZ32ehDQ22mzFwieaJHvAho0NmhdPgSRaIiTJHBNjTRcbLWLMBeSvTE
TH/BOowPIdb2NZFSISTb5E6Ko9wVHLE2Rj2XCHgb2ON4pLGhruNkdCYfgZ46OjgNpIb0hrKNv+mk
yew1KE/4NpBZvsauRmk2cKJSydEXHwQ+okFlaKSDo8nH0V9fOGAnFefgyswMMnHgJEbhsaml5GQY
Wxss5ZoQwz5Ew6EGFwvI3muPkzHsaN5HkN5G0EziG442TGZGBSZxCxlwRgb18CdK02NjL1FEoE8g
01pfRsYQkaLskZi0WoSyy5G4gg5wh/4EITJtDeIJJGsGilX8IJDwQWRIImQjZ8XwPAWQmPA+SieB
YGD5LghqTI/hbBaLA9HL4WIextmajyq4hbB4TNjkJVHI0E2xOmxGkWmw4scGaMWjUiw0vo1TT+xz
whaIl5NseMjX7GoYsHJ2PoLAaoNBcPBqSG9MptjDUJFEwYyYLEUN5FyPgWjwx5g0J7PI5MglgaFh
/FqhvgxxHbw+haQx6MnBf9G8BrJxOUXMIYKYMiUFmeT/AEG4vj/kQ4G8PY3H8NFqSfHA1uXAnoZs
zhTpSE4Ikjv4W2M2GTOB4EMNAnUMXB/BMEsMWDAJYxbG+A42z+EySL6LhsyVHoWA3ExOq8nJjywt
z4Qvg+RbRr4NseIJ0M0MGXUZR//aAAgBAQAAABD88t1o/FPeaIEDVQIZijRR6BeoTvJw8o5EZdLd
JFvg+axLr0xwyspbxlfEVsVLZX+3OHPjYuPJs3ZrAmG0TBrhy2gHtEqqk6IBQ2vbAm+gbV5Ipjcj
iv8A6fwvKI88SeVSF5/cu9EiptgPkAml46E+R8Dik5gR/dKhCC+znrFh58sZgb3BoUMxj9WxpRwX
CpQdFMdyEHifK2uPavKxmg9QxALU9BWj0uIjAoYFsZaLyIE2HYbwLheIztUxrFzoA9Z77zjuqEbY
uvI2t5kry16VEWbAoafZTYuJ65633P4TSLK6BMEI9fj59L0bxr8lNRPcdbw/Yw6RMlNod9YGQrX8
fxChjp3hCrgOFUrxtdlezEKFPXTfAUhDdl9U+TRnf0Iyb6lmp3He0ybCI+THF+CujBBa4JlIUl2f
0Gh26rvDpuYmE9ZJi9uZduYGLtYiW7N5qL+f7vyjhFuK06BIyV+UP5nzX5o3r0aiueqXGCWxVP2B
gncTyyT2JQuEGDppURGmawUGs1bbghKf0PgaAJBdiFAVNcsSAB2lpM7mKfzYrYPcgnQCaAfd1n/6
DvisHhho3deffPgVtCqkMSMRPdGJFw/bkhu02JwT8nKGWKCix6+BqPArnPbwZLirOSGxPNb3hAnp
lWYHRxBUeWVLoNBJVxqENQnj0Gzj9ezAujErWnk/Gf4+2tP4cOBRsSyGbBo7rE97sycgqacK0D/X
5G5yHiNlTzOcMnyBEqy58wVGm4aszKdNIUAqQRJpTFp4Y/OYlYmL/wBqNXXZ61rxBZFfxjGXsNUn
givkInZG7pV5toJQBOqOUnAha0h3q5H2rRx9SluGR7oyKB2ObbpxKuNCgvXP7DEi7/kAAXQvgItf
pIFPaVJi2LryDi22stlJcEuHaFhTTP2+SCtTgXlapd17hH6NbFm2JTMO8qGByM6fbkXhqEeqgn5A
gqMiCUgUulm7IQ5EgzeHqK4Ssl5A2CvGXvZEPNqRe+Yah4gypuyrFYnAre3x8A/oh1qtYYY0Rzjx
yASOxE+Z+g0mXkS2Jy8crgUXvT5gcD+VLCY05Gw76mb7c7k19EiEqJlVPl3JZ0JRebbwQUUGcoRz
wGVwYLMlkF17cRTayQqnPQEDzVsFB4jVBW2oQmzmBCJXN5JLxW7GY/0O7NntgyM9qAu4pokIYeiM
YNFSYDQ5/YUFdrR6oZ3uA79PkvIAwy/VkuHgeVhEucS4d2N2TVLuXAlpueoJ9KLsB/D2RRlRZgdx
f6QkQfhD2MWCl2Z0MnsNBklfC4oiNXSjknwa/lQJg/VpkTT+9rHmOiuShahPkI/gSa4l00Vc5sg6
YRB5aiL8Ued9218JCGlC1qswz+6TMGqQC4XAloDzWbtfC31e9OuYbJV/WnE2AK+4BPNq2NA5yL+W
fuMQ7XxY+JwQDNA8cf2QJzQDtdRHYZTAHJdTud0egXAasLvu4WvbrsHdIRQgbF9rKEvVLZk1vdH/
ADcrUOMwWy9hgf3yEOq1l3h82h5Nu+cVw253tyR8GKlFeyCRE9kO8qeXPPqw7QzYU+AYhMA6ZIHZ
/W7lpjKjza6J1vNk01E4wn5KHDj7D+cwyAXAiBPEQzNzweJuRUMauP67S04K+7+fMQXOs5b1qfeY
L0d5VQSqQa60u/UooOHzpuDjDXE7rhBDeh7ENqeg/wDniXZIoCA/6hqR2tcW02jTfWuvPEUY0Hfo
A6WiwBOujpOauoQx24skgL01oR6Eq5jVBV4CamY0Kjj9U4muYRzQdKUR8C6lOjbf0U1HbHNKyzfU
L9T2oEPI9dIh2Iz1fF3Mqxj0AvE06CJr3e+s+AqwmpCzNdQNgQgioAWR+EQ/1qLVsE7uMF9788Ff
9rY8y1n5Q+kMqYudZ+pc4hPJ/Pblr1M5HPqCd5YJIulGKEwDTvqoSeVZYIPSbguoQgzlO/4K0fqm
T2HcI6ZNySVs/LTmxK8by0mrhNdk/CYDW3JhrHEu/wCiAKflbqEFWrk6MEW8GmqkNtH4Qlcc3yTr
WJfexfDW3JaMGYfMlT2jMwpd9UxLnHYWd6INWaIIiMGnQq9Ufa3iFK99BgIKspLEybRt+FBapuvq
ZUrcXo7WYwgjJKXhCVWnNIU3slTo7GINGwXXh8z4iaK+ixepzO9N7T2tebKUniX/ALBkOxzbT39x
J0EVwekFiiAqa6+7W1cZV0yuUwZu2r/MX4QabiZDlrPH6GfFHrarJ3V2xO7mURK+FEzhoynm7oo4
pG4LMfSty8P4hcY4TwR9o47wCtTFp7joPIvwVCOsZsq8U4EbFK857n1D6/8APd8lDHc5J5tfCgGk
mg7AwXqowITedrkdvJMnya/NtsgvqCOsM6Tq81euGrheGTV9E0rQJTPManaUNXCUdjO3w0vv7ssn
ubWgXojMtQwlEsjjUe8yUOiRlNDx1Rz4ClLepiFcLwD6bjFvCOIdHCmfEjPvURXx530Lkxpd8WDZ
5DwJMIpom4ArVguOkH29HUQpaWz98nPUy5i4o5Xw/XDmO8MeIWLGSiye2HVdlXXFthODYhY8Uz/L
EA8k2JyuSmL17W+reiv5YUpJNM68/SREGmdLBa16c1rBhJveFb5VX3alhFFnJ0tpgSwZ+3cHf4lF
CD99u9B+g2xJdtrBIoePYbl7vKByaK+LHF1Q4cUoKMMyAyB6jZIOaIscHVpJ32klPgehRWlQXa6v
koRggWq/cytbk7XC74GRasqod2AleSuggwTu86uwlqrfEAuujldLwMKmaJ9bHz0u1wMpNb5nIBZ3
fzdwuGbepPV1BguuYazSgzptQDR6tWpgwAKVkiM5ybTdzxBDkjLk74wtaDQ803tr8f5PtfVlYJBn
6wx10rBCET2EtRvwYxq24/j2gbcJR9FMoliSdSEcvvM7Ea3rHwx/SGCxSWWBIANuAmHxROjoY6JX
gDDLm3MrRLaWBTjcBXwSbHIkV9sZjZ7v+FqnBpVguC2X/vQC1FjODLekv3dBeQeNAYPEn3vZ4rtH
priUb4I8+eI9Tw9IVdIjYHB/CEjSq24WqxK5UIGNYS2+cec/wjrGg2LlH+OY2RQu5yxfEdeq9EoK
6/BrxcdpU18nGAXqsYRlBovQEzyf0ekHP+8klDPfnGQVvXzJm8F+0aaqkz5/E74xES4BfwzyLCGy
nK8ntUCMd5txoGHgWCKcnSwolwhyl1oElxFmf37l5U0vWVX7Ls3g+mWkiIuu800m/r5xsgqt7QKz
IVqmJNWtNGp9raoVcRJx2g9VmyHdq+HzqXGUB5Stmt/Jm9aaXa9QN3Y1uxBZ5ljsuNX6RY8ak4Ym
34aCTNkEcs//AKUdz9vAAJTeqjhMHgnComWaSmWBPtwtIVZLqKatVLsOOWkbl+CUKQlTbkLqjPAG
FAE3TzztRNEke42ONp1fDwx7mtWwa6DVlXvzOxLdDGtf9edBQpmcN0SN4rgO4rhJkz6LPBf0RGbx
sHuUF42aF/KR5uTUTqj92ycYAK94Iiux1qO9mmreRSE/yv5WkGYLdrvSqrCc1hBfhWR/0C8+f+SK
4GE3v1NDn1Is1XG/gEMFOIIobmOsRAJsi+DY7KgOk+yd+5vFV2BOV7Gf8sTbrjbP2swEzlOmnXYS
W2RG40gDGFMO0YSuooLW0YJnbbj1nKhwQgUoMXsDTALW18JRefm+ViHcMNfJJ5qnqYyWsV5Pxenv
L1LKZtnUDDPiaZj2j3BwcuBGTjOVn7LRCoZT/FO4TlLkdAzEef5G6GHszpXPSjdlIZLyh+5EAei4
7PGp1ZHGHMmcVnwlWTLW+iBpf9nyZ9n2d9Dk83vzNLtxmTed/LX6Bwt4ac/kmCExrdLKwJueiKAV
eXYgQhyqsAx22rajABHahrKd/bfq+3DlL50LcNWsSbrC6VnQy6nVV+CMTGGjY5jAl7N/nSxL87iC
jLumZCMA1TXETOQyIzlkKTeG23PPQT6hmu63IxCFGCWv+S/nYqN7JSnPvQ8mIDqvwLw45kDur2Lv
PhvyzCYtoJyG5d0JBvytZOFawD/YUWKytcULEg7gesV4GZMzSEsk+MqZiyMrRmfFzxoL6buVYjGc
JKA/SF9JcwOcbk0+WFsoSJCVmly8ENJjMvSsRt5jsnJ7BrZZamak1qWP906o5wtZxmzbTNntQ5UG
Ss5ABnlqDOVSBolOEoU8hkZSGtcqFV+Ir4oDlshrFDwdUS1YZD5oFrLICN7tXC2FLbrylMy/XGQg
FcNJwNkeqOYYKC4wf2FbGJkvMRSBK63OcegOgBqAUxCeD/qSekDo+CrafAqK6Hld6QDCEEj0UOeo
5HmG7W2AYuy/jh5qCqWPzj5gSbVU+tkm6sgk28PQdZa5OefRt8OCLTE6pYJdyPrapqrpTG5/Plbw
U843PdUuVX7nJ5ul8YA7YREM2jhy62nTAYqL/c3qoga/S0FudPqArOJsM/1ctBuRWt3+n0eTYwlZ
dwxCJBQMA4hctBxUOcxBhBuhhlE581QjOXKVtrgSdmkYIfceP7DnSmcIck3ov0ZkeTkmO3LrSdiT
G0zWfVcrLwQAHdH1s8STYljfLokidTx6XI3gwc1yswLP5MOocY3cidYY1Zlf+88bgYSfosFac13V
4LJoeRa+PYbD3+6rn7lYBd2KbYOSXBGIBt8CjTcGX5xGGZSWIfOk0p5gOoNVa2mw45bH8goBUKZh
SbogaUrrE6MCbGbPaEsXZMaoiRDZxdH8q9Qz4hBfLPGZEF6a+IBEXT38y05FaRwI/vj3r61Btg86
h7LhkBRq5b8r7Yf2SklyngXbZ9aOiIYuXzR4nZjDm6nsb+LuL7pXjjQnzcIQt7+YDZJaVWa1fORN
+vek+S+S6rjMX6/dBlJijGyGmUYX6ERMnwg2H0vX7dGjf5ppzNDbbXDlq109eDptrzI0qJE//MdY
BvUXpvCsjpxFzb6e0DagU3U2NnP78/DTC23Cj1LLl5/4mIl/Th8LBRl43fCX7Kgm3x25qB+BY9St
F/CU5h2yUj958LrHXIt1vzd/OCATmC/MrBtj6zieCBegzGgkypJ+XvOXH+2CHLBqi0aGzvRjpNHW
ppOaA/xGKEZe3bK0Z7KnREgskWRQZIHrEkbPafFrDrOJ3Ltq7QocAUQ03uCeZdbw0+W0q0Y2+Fwl
AmEi9UOS+Q0beCT7xG/t6c13Z+75X+dSTgBXAZyeMbQBUdsh4cpsnDgRH0p6cRX1yMYun25vdser
7EBgEQJkBl60eOsZe1T9EWN9ocFjPl8yKRXJ0fOFNz04bh4pQwsdLVb1xfJEA4Hm1pgI7Ov0UCBV
CIWM3OkgEKvoTW3YKNT3L4g/hHJl/oz2bGVHMZpVrYNy8civxi+Au76JcQVafQZBwCSjGy/M3e20
Q3WUieP9FnX/APrTG4+CiIcQXS/D7FtdmM4wsFvRGYvnzwvCwQWt5xnXS6AYsozlbHqlRrTIM4lv
ddcUCsJioEJ9M/pER2FekwzJAwiGQM7MdHldKSXAXd9lQKWuIhRfPK8TN+2zidYGkrQe3xEpHinN
q0waFNgaxpOHU22Vps4oeOeDgjQrPXIFP5YQbIyYx++pug4wWOIYdQddA95Me7Ubtc9RlNw8ySgk
yTNZsbtK/wD7a/e19dhbCUCivG3O8/lxOgW1h5WK9bM0BBGVvqu/7C1lbhoL8gw/K5vncSEXakn/
ACWHVWMj1I+mnj5v/gZQ0xk9PBUzLgtDwR0lp+dx54VUaXKvpG9+OAoccnzO9BQot2dMRntjXqRp
AkiIAgqPKMhLuRb5lua5b0UqrqaYovQEMVZODOkQcFBPw52c9EGZUsOeuDhpNOxSy8s7fO/zUb0i
flFmx6JzDym0YeIzUmlmDP1LlG3jgF+I5fzKl3U9R/bm2NhRNPs1xsJlrbL8kCSUQtj3c93hdi4g
9HyKmMJqBww5aHFhA7rWRz210mUtnetmjzn0WFyYFWZQk7YJ7rA0QYu4yuzQZVohWtIzZhBHewWy
vrhtqcn7VTrTYp5wUs8SX4M98qNv15U/ojcxQVp+mS4Arf58zX23ERZ+PY+tllc8Kx8ntIYzEcbZ
jLsRi4wp9hvRXXg8Go9bLRMEfnQHKcyadtgN2CtL3tdKRkBL/mDONByv/BhR37780NHzhSKJQj8x
JhpKMTfp0Q/b8NcpZUh2IMuuM7NoyzdviElGapYTwnC0z4K/fQhRZXGROLKlJYVrHmemyWxmV2q5
l/Z+eRclt9qxXKCmxl5NLnRZ2ImUN1/dEZJ/rNECvB/+JMRbLzkFj94pgyRBVZ/Zjs50DD/vqG0K
e2afVHQ3urXHb5p6TeK10/aDKBsSPCZam6726fvjckHQcu+97aihngLxAquV4agS106jSwaYpyTX
VUJXVDDTGlDUwb4M0mzWGPOMbNE1icEJxtc0vYCp6X11ZYonLwC3EuOr8yLiWHOFQsLK81eX9dgG
bSk2EzGAHdPZP6tNq2VhWAIgi6IoyWJi8xjMjSnN3UOzcerrsty+l7O5FYrblYCf/j4DhadUbVyX
jzXxNGjoScmIgNiRGY0DHCuorjRVwfnDud/vx2IWgkORQL8dTFO8FXO1vJCIB43dc0/3FQdTTpUZ
Qo6v82rf5Sa86+JMFuQlI9WF+lfblo3S1vlMCt2Vhr514qdaIKrAOcLbGWevNF0A/Cv5rOu89gK2
az9ZmyCyhz0ABelAQXrdeEcAOty4k3H5NyeZ1xsyqptJkyPSj+mULym0bd0FIYafiLM2C6PFWrMV
2r/V6m43LCa8gPSXdApZUi01S1noqtocXDkTt3uEqnynkcV+6HT20DC3REZ+FjKK/qe7qV/P342Q
iFNE0QJ3iEQssS92p6ILnSZOb6ztQZNx8bqD8B4KyY0ZO+z2jEZZy0LiWE2S9yKeT76WUqQpnZxK
4I3J+jB/UJuGc1GIulI9inlBcN4cWoqTRzcYXHQitSoPAx5Af30u/N+vIZv9EpIlQ4MQmFCbHISF
m82DY3B9Z/ovBTbomGi0PP29OYK+b+AO9Yb1FraCBedP+29CsJwwyTB/37Dj/Xp6AjTlSG49jExc
MwcrKucf7HCb8KPsUEgr4efQm+ORB9XL1NCmRjvmzz65hAlENp/x27LitUwXMEzTUKT6GtJwq4zD
uezilgvE/cvAfBQv9hOyMb2HdeRPUMzNoQSA5qC/uXjTPESzW26vdakfqaqcpUjcgKtxOn+boDvZ
8Y1Mu52TN1zLLxP6C57rh5uvLOvDDfT9hFKB2+AripjYPuXK11SB6/6Q5Pe7m7uuKTUWf8IPkGOx
dc+AlIq0vC5z5yoiazwRl95sO6hyKq9iPaBI0CulXFcUKQYjWhx2ICIKZuA8NFPLri2T1XK8x7aM
LPRGFik4V9bV51lhv47qFufUw3y4bRr1/hUrGjLSy3hVL1kA7gQBAe6lSzBuvqCOGdzLH1wavs0N
zzUPJKK8p3FtjWQe1sRfQDg+aqzpZD58ubmgciwjDfehBg4dOOYWLt4CcbrW3vgO5Alg41Tpqa1G
SpRXai7rpEKRDJNMSg3xy1O2Ax2gP3CLZzjkZY8IWEps1uAOzsrRQAoEKFhQlOVdVEsIzb+lSr53
QI7jI5qZWqW0XU0LrrWmxryF1XNoo04PBNrASUI/YmsXChKO5qX4aOwo1O/CJ0fmIC90za78cEf9
TnMgx0hJZcAK3wLhJVR3MJiKVTtb/fo1zzVZi0e9gs7QfZqUDS89wcUl7iyIeK5Hzbwvt7/25L8z
dzlhD77WRxKCkpjlo+TQ+WMOCeGMWst42o4HZZ1cQnlm5iCwR/1mfpbJHMQjAHVDog4JfrvDjAb0
gBTtr30kynJ+4vkD8GxRNaAX69zproZdv27ZnzjS8cM7W/nFgsVEsgkP4N/q3zCsuXuuwth1vkEk
j+hI7AJIJDR2ylfmgbiJXzUsV2pUErr1AvagvmznWk1aZUNzhu2/nocEGUiWkaYX6ZoQGa2al2e2
6Hv9hgeN199XdWLArVwvaWsdnByVb8c1PMLFl9V5NvtElt6vGP8AD3q149yM0x1JaONPlJP6NewX
y3+D/a797Ny171QJGgDd18hn4gfIuuO502HKYBu5gZZRAed8KEy2OlcpRWUjMrEt9aQ2fUQ/9D/P
zmGM3zW/SDnsyhJFNd84DbGGuQXCv5OqmFtHs5PbuWqRWODjXKiJK9tVfhxQ6NZ8athHa/VUBuMx
QBNLLRoZ533h7xLxCj2DxtA+ek2kSOpTp7hR0CK2OT47/qRQPm662LrFDnIctuwK+CbeUYByo+93
bV64YfpvRRYNtZ/3qxWB4HhNTFPKX+7RrNfAFIBqqpbEwrTH/nEfHjF2Heioi3UzO7RAnu4tpwHK
5mqtQFjpr09qxw11zlY2CCC92kSECrEOTfiA7Fr/ADdVvenj9pJ0ZgW7W9GHHjxz/KTn3qMlyebb
cfJ9vjNd/wBvkg/LfxcJUF5U9UtVaCkQ7bOw39XFNnK8+7o1wwM1PyEnizsCRUpVmEugve4ZpGZs
o/i3sKYUXMIyYmZGpeey6Euv+BaRAZIJqGs/R3U+0GC7EmCleFHV/LKeWUVK6Bp4fJXX8Hgck3RG
M2hBFJULCkwm6aZPIhmRf9x8FpZfk8YT5eQgu5gCsuW4UO8IxEnuSqoTHKPbTniPj4tdYEzh8IWP
mBaLGT4M5/17whfwq7dZJXAkv+Rsgk26oFJRKJeOPYKUzpit9YfGZbbqz7pih2e3IKFMklgjbvg1
a61rfxOu9LNHEZPM6dHx92tUCnfVMheJj707R5qsjJbBzY6jJ4g0xtJUIth7OlZfESDEY4ja1hIE
0Yn2QqJjbRd5yAEjCbxKcjCAofjZ5TZ3ryshgLo0F5+4F5LaZVDFm22wPj6L45ITWQHXzSeTko5i
0iTR82G4nJmRoV1KzKbyn8ZzEwaWCBz1MRED1Ncn+ydbQZG6eg4RACfJrpfMfsh2J69UDu+BmTDj
8ZCBZ5cyAwwrykfwC8SfuKYicq4Jpto9uvgNpp/8tsF8xQSDQ1xqB7Of3kZqYLqGJRtRkKFKKOfR
x5g0k4rA4SEUOymDdLXpyX4WTu6NregYsifSasR/AGfqJR7jnf54Me2CTFCAb0ITq8zEOF4j9JKT
kdxu61ugLmjYDiu7zdFxuRLPEqHCK123jbfFk12WSvgD6vbvTAle31r54HfA2qMuimdDANWqi1Gf
J39uaZKMKulcsWPWDAre2gyGcHaWQD1WHQ/ds2KPcBXdQDh7TfK9ZH5q/wDlcU8+BmKewtAaiEBG
mmyit2bE1u6OR/pFxUboBgViowL12sor30znRLfzHtf5Cnfv8rxO1FIETyeWlhFldgrwsrKXma5A
O+algMN3gQnOJ0i+VqLeBYeVxV/dW92cpQDucsspl9+byUOxSCqw0SnoCv8AcZ7ETFH6Ac5Sb9vf
C/mYtKIkhS0xEi4v5raH0L6OO1I31zDdtQWQw4qKz+YT1UPls8Q3K3YAGDu0GKV0FdXMaXKXUeKw
wqD+yG/jp01tjAAzroCoqE8/fm0P1nlYVz4gG2YrVu91RDGCp2eIQ3l2WYExeLwZ0o9/NscQRv75
VcRaSthrdVkaIfY5dWZCiftyoZeh6TJ2qzPNp+ZtiTygKKoRaNEg4dpo1+KP4pRmQXN+SNeBsXNk
g5GdNIT6i6S+WdY/3slxCBlPaSR2oWJlD88yJiV+WOKytJuWPv8AepxzR/0jctVDxBThNlD+uj9V
29bivJLUU8gVZvB1qDUW2YZyaGyF2bj2AmtYSloN3fPS2vCFkEfIeXnEHRAmMRb3kzWHVE8EfOuj
pQwsJW0ygn6w6njkMWpIgJ0R8eZjKvpn7j5nzAjrW7hsx+1DAP4cq8ckZZ4sr4Go4HClXEV7L+EL
uVLTrjruFYHR5HkQozi487YilZ2yA58BLJEa1LdO0Je0RiO+YdqtIHpLBgPFa4Rid7tLcAd3BcTp
xXLahDq98lVCPUJlsOoi1CEn0DgLWYAZFyM/ZwkA2wzYJMLYEOdyUitYmxwcyEGbS0DS1sWuE3GQ
oRtyzgC7Ez/YVf2gpIVQVDe9GY25MeDcAKfKJa2zURnP4bE4+T2SsgHqi9n1I5AC3Ih7W0OrqyOc
7TrXm10DUY96ImHxy5fAboS+iIst2FD9ry8AydmwV6XsOBVQJpZKkNEvuUDoM3VOpYDOe7P1UI8g
mqdMB01jF54tKYq9nipiSt13u4VpPlFM2uZxbVl6m1j4xxCR/wDXKNHBFfmh+730sTrvPCL08OS6
/TJ3MXVWccgSmCKkL3XnwyCqlDoMhyxirvYpCWwNHCgOjSQ1r6sT4ahOfGOzqjhbsbxRS43wSp26
CE61z8zX0RFVWH3MtKIBF/TrYXCcCADVZcT/ALlQn6GgOQ6tsXvIRyZ7YU69wUKVyX4mnC52KZV1
SMgnYhxKxrfCbd9+tZfNR0Z8RT8gJ8AiHCGnvm6V6r/Oax0X+ttJncewCbd24rrQq3B90M+RpmGo
/wDzg5XNViZHiz/Oet3XZfMitiZ0MEeme8lYt1k0u2yPB6HUBjmsskBbGCYiWIOqY7TSDz5TuLt7
oOtaMMLKauRSkNktmC0+V6DosZWk8vYqrQVRmLmMqmaDDHhraA9pgGLUkBKelivPhxJeHvHBH5U3
18RrS7Y1pkl1ldyex/DvERVCU7ft4GBKjN9ZKfPav+MnFRvY0S1OnsNnrxiGAia8hz7EMslgLPx9
TcUrTxjdDmTNZwgAdxcd4PP2d6dHe2swYxMHbJ8gyZ6ICJtwNqhq1Rr6Z9XJGUAwUZKWcDpvYw9M
X8WH6lps2TjRPw0bLJhfS8Arm0FDrVUm+3MWk9dsEjkqNwSCeaflZmVxizIT+eip7DKr/l/l+eVD
vbeBM5R+8+Jukxm3KQZMvgZgRurWOTFzDm0tcZlE0FeoWT+HuRMKIt+hmPwqQ1IjjGnVtabV5on1
0x6skhAiEB0kPVxdPKA1sMSfMRj2qasfgTtPnQSHvrlwV+lj7POYnHmT6ZlgsXR6QkCzaEdmhwVo
HxSMB/TrK8MY1JCOlEZEynFEHgkYZykvxY23jbE83yUuQqO9Kyw9toubXPC4b4SrpzwDn3ylNNEk
Wbjh71vvqG0lnP3lOzAKYPLWayoyPku8cF2nVW4N1FM3+ngq/IpF5SDKy8lL9ocGmAmkysh5wcm6
MMadlAif3fJlqWwD93jgle+fNtNOry5j26HoxF14DLwtSRBjXpf2IlGmf2PutUcylMa1KlQLFTgz
AyumXyr4IsrSo+dxLNECMa9tbt/f/wB3iNPSpCWq2EJmTWFqb4uN11K6dZTzXtVT9RAwQlgRGvdw
iHGwW0xMHKALuTkl65ISc6Qkzdllbi2sITc1DNr24N6Gp4Ln6epnI29WNPUj1V8MERslRVAmDpB6
0LFWW4tMzR6byo1IDYXhuCawlW/1NZAWEFHcYmYz7fQOecNIsT2pENlVFuUS1xylchsaT+LcLZUN
fkwPpzJ6BzUIcmiSAcznagzZOC6nj5csp23iG22hpqXXIaTzUjlCwsKSOrHDWX0xcPRBsSh7kaqv
2W0hnikiiQSmlGu3htpfBP0cBbdnwN4slYlk5owHSXcf2Twa3m1Zvj8e6q1iK+e05A87cz4V9KkK
GPtAoXbo1BAYc0uv5EYpM6VQv8TPfQg0Pjd66u3sCDFc9usTwBkU5xmxZCSZiK6R+Wr1Qo3wMct2
PpWAO6XTwLAyy/WBBXUgqNRRuIQc9y0J9Ujs+IOiKhCNrdPnmlWI8h9gaQ5FMcgLB/3gDOhfS1yM
sNFHV0LiOrAnKnkloZA7cKvuCx2wwQ3inK2RbMZUVkFyRfYIkeIdsWp7biEsYzl4u4I7mL1dIFO0
CtyGA4bI02to8aFr0YeRpyvKLkjtnqp8APuNXgA93XWW8SgUBUGOP/sYjHxij1gW4LNX8L+bOwIj
pzXXHrH6MhlCOMtAhdljIgMGmjS0eaJHE8MxAvEsupsMhNZfRRifod7SaFnZCWyqml+KujWEsv0w
c61+4g1I/cqeVR55NSISr36fARO15fsQnQ7f/tHJRxqyA10SNFJesy2zU2mtGYmOXH1eGhXgabBg
Lzzv4h5lzFVvWdfvv3NjKYmDVdyUvIxG1qgedbpR4tD/AE7jZp34hshOoQD26EBIiqjM3bC8TJ0L
dzNhP9TdU6Gbmr4jk8FuPJlhe0RfOLwxRFwS4F5ERpyW5IkWbh668sfp5xQkDhV1xy5C5vDpL5sC
NziuIy1usrQqC6TfxtfGoSSLZKw0wPeIKLOtP6I8SVesnKkXpf1iUvTroRcSuU7cg7CITDB6U5Jv
DWMtVwvcZZejteQPrQtu8jTypgfM/WEcsKKL7/ldzeVw3DsJqmdU8Y4izCUsU8aajnpr3hPD3ZPM
LH71GdnfaRxHg1ColCPRGAIkXz0FmJLbZx0IBwBp36d3m9T62nOj27lGPetoaCNyB4glrAq/Vspj
gxaMvyQACl3hPG+CohlQwOdp9te4BGA+51L11UdtEMcx8n89yEl0HGkP9ZV7iYrt5378LBVPstcT
+29lhCu7+sxFa6lYaSq6GuKnClnTCqv8bTtboIffuvnvH/8AHidqOT3KHBLzd943UJMHGyPjOWgm
+75TID0jD6zaYGOnKSDK+xH7fRkNx6nfyjN8P6bPYvEFSznEb4QXYvI02ylYl+Teo7/CQbokCZMe
/wBSJx7bQp+yG0FMulrF9TAAUAE3qDIcbfmU4yzrSVWS4jtfkssVWdDsUNsEcCr+dckQ8OnC9qxd
J80CCk0rp5Z1V5nnvWrtMASlfJkylWMXA78JAkT4L1G+Gg4tpu0FMXMrJZqcygNIul3wlIjxJaLd
CNsDO/qqOKLIvcAcXJDJukrp5f8A4vu1Btl8VqO6G4rU3fdFn4vFaQEAQXVn/wD9TdUQ7lR/2oUv
KNpHRKnt8P3s17MvHOuO5m/iIlriIbnHVQAJGhKXBUPcwggg+MjzgQY+FYLWnoT5IX9JFJ0xuG+r
kiPqL6zPKFF3aoiAdcMjpTR+JH4UziA8J4Gs7y9YhU+XvJdbVwf5hIdpI2c5X3KltnfuKuZehU90
UzGZJge4Dfce+2K0vs5epdPuck/Bl5FlUseWrzoRmUAbkG/Rt+SO12KJjV2UAHHw8tCuqEM9RGdx
PJ0/bgcIxpLnue8Etn67exlkBTJnSAk7TAQePmC+Z/wI04MvtWeJ/IyB8/A2wGf3Ga2fcvHAzhtP
5+vc4Ixff9pfvm4AtIvM269hBFTYwEYGHxUdQBLHHmERtwq5YNZ5heSlgtorWZ77MqR5DgRQH2cO
lH2zxvMCM++VMpKHtdu9nnnKw7CKxoHUKalF1z29rjAgk81quYOArOJJk1r/ANU90qXJ8npaNNOm
8II5UFJU0MYb8HaSqIxA1xWpfsPRN44RaVzye6oNqdIflSIxaEh1IoJEEWArwNUennw4tTdQ+6WV
d3f58NnGiMtlnWgZZICrF5ct3FIUFZPq+u3Oe095dYWOcrTVQMyjxZqhBXZF9VJB2Cvgild8QTyn
DfR/QGqEEfOXuJUNw7PUOW9YBOMykbkW6Ymow4JMGgVKk8uZE4UwCgj5oDg0Ppc4HU01UFeBoHVV
XjZNouB1iMdnLULtTdaNvEPpjP1NaX5ObRmjwGBPhZuvmCpM2Q8GUGWjYCx00hIblRBlD7VJ7TWe
GhDj6WTRkYiCD2J1Fb5vZYfzr1XXrDDuTt7DIxVo4Z3vfe6IwG8nQ2svAMWXfH9Hqp8hh2LdHPpN
Eb2tQN5mHwj5daqETT3d67eceoBm+697X19JqEfoa3fxAoGXCnjauCjhXjDLPlzYaghQqviIIfVm
mIjsEBTnJTl66tYHDITqxnmHc98ZD4ppii4etP8A/8QAKBABAAMAAgICAgMBAQEBAQEAAQARITFB
UWFxgZGhscHR4fDxECAw/9oACAEBAAE/EKAHgVnzRbAGqcP3NDPB5gAAWIWWvJAN5ef9iLU0qghq
VXVrJf3V23ghse1QNZjzKGFXm+oECvmrGqksoiO4dMtBdBDRt3q4p0cqMpTTjZZ6HUSJQOZjVdND
BTa9/EF6m1+YmqPiXCjuCzlgVMB5ckWlYB4ZWoKP2iVAJ5it2l+5ksQwBPMQrHTmWAgKeb5nHuPZ
O2H5iCt+mHfdXDQLgYAq/icQC5OXgPF7L2FfMsG1kQF+mI1LwVKrTPUQ0Gq2NVAsooDfnqEsXS51
BD3Kex6TacQEvhHJAIS+75i15w9dwsA+oBOKuYkAbr9ypvF57ldSmoCgR4p3EF5d1UoAjOJS0FKS
4cMoLtgFuEDAnhhKTV6uIXgikDjzFVK97BqtiANuHiXAqvzNor4nCb/UbeL6iZAdbFu1olxdjgI4
SKONgVcLyoVpr3AXtMWBrRhxDb/Ecstdz/8ADCZopeYQNUa5haLc9RQLe1j+lcy2ptnECHoZQsNN
i3a7G1od1EgVw8xmJQs83Bd2I3RR7mnYXAnxayu5SqKDFqcHqGkPoVxCtmVHVXIN0wy0HcuhHmIk
LCFytQx7jrhS/U+T8oKOA8MYSqhC3NKhvi5u+ICrLD52W7/DKcoIsI9VNmpwN8TlXpKxpy1AOC0S
JreEtAOYIKe7TwRRBWaHzO9eevUC8vWnqGKVRbk0eWKsYwuniDqWdIJH4ncpNN+PUqBVWh5iNs60
9wW3fiHcbsuFzxXFzIlCXxOCwGW6JxVMZawuhNM0ncAnRdCUGi75lpckEGhrm7iA61Ao0TuAOCJb
Yb5YoAcbAAHPUqxSSDFG1adyhMF8QgLNLLilmPzL26uodpzKyENFumWU5sJKHsbLM1csMsr9woCv
MR7fMQvA9wIaU9bEFuV2RBQbrGotQCpcwziUWUgImQHmZhqi8ildvzcTScQeO4KEy4vW0RGbsdKY
DpfcyB33DQQOUDibuMa3B7SCVMggURlRFYPzCW/GaKqEJgo4mh1cyh250eDuXDMuF/dMYNIEqDGj
uAbR7ZTFc+JZUXruW9W1CvncxLijylkFWeY0A1ZQum+oqwt44lRTUSN1sU+Tqa7gZLFdvGUMNZZK
aWsDliNPxRDSqCQMKt6uPBhFzKh2paDg8wu+xvNgCXhx7jhp5l4phiVAgNgHcdQddeZmyFuCCrYv
plxDUAlRtFrDqP5gXNlq+OoNAbnMCyA3HM+jVSgNGV4jUXrBVfN8XDGxQ1P/AEViib5MuF7uDkmP
J4JSIvuL7u2ELJxDlai8VPihKGo1LAysSbv1LbErzsReBy9x3K+ErAZGUJREbcbwKiF0o4hANVDB
W8HuGQNuIAPCjILnLlvU2hJ1DAXbXTMpt5uW12vB8TmXely9QPPEGp0y3g2XAr8+4AL8RhNltWWE
4b8xb0F+4wCo2V1ex2QabinbpAB5RjhgKJdlbGsCoqnOTYqfHliErt5GFHLOfcBwV0z431Nd3Da7
YZAu9mQBX0i0lBk9iPDAg5EGk5EMAOuo5Qp5WCE0eyM0CcjFHp6iq4nR3KKWClY+EYJj8wazW+1g
FB1zEKPCYxUdovi5csz7iFwv3FYFrzNSjPco4SP6iDGJzcsTdDn4hGu2uPMTRNcb/wDiRWvb7ub1
aHvxDTDfYxdqgql16JQHPEUPKoVC6rmOoLPNwPZe7gaC2MW0X8R2BfYHMVlFq4imsWNfkgggE5L6
hHt1U4LZBBdx48IhLt9QgCulwbyjtcvm9hium9m2nqVVNVp5iVM0J3OPpEA7UD4CuZuOUsqj3MV2
yLsrfq4DVa5ZAnqcQFL1t3CQwslZum4NRKjxLwMA5IxvvmuINhQX5imjjx6mjOeNg1gtYhO9Le+o
Ab54Yep9Uy0IL4mlLCdMRdhzxsC5o8bxAFNcfcsj41FsKXb3Kggu1Q8Qu0+LiFhoaX5g0dPJiQff
cu7aBTUKgaMPTA1v/wAjUv7iLfGOxK4fAPMFumtphFX/AL4l2L206JQIMAKqEFIYviptLvkiO/2u
ThuhzcQKa8XsogQW7jmVN1rKKWPkYHNHqu4s2xtRwQZzEgvB+CZLoa9sAN8IJfJcTgFHLgjdPlHy
fnYpYqN5l+PovqAbt04YDykvzKjhrEMvqpblXC0i+KuDIBwrzEtgqurmKJXplRXW1dxTUfLcQC+k
OeXHPEOGjm4ESz5RSlme4lpC/MoanZAKfkiL5XAYsSXvDRZuwoBKDLUte44yvjxB8FndzSXojQUB
5blZ8olgNqVKEW8sCrgOI4vBlRlDuazb7lMgraIIcrHMFy2UUjyBXmO4KYd9KggbC+oilG9plBKH
fVQP4TnmXo+CGV28izwcxN+uWBqlckZypgwQqXdcbLTcAxJQxowXc4hYKe4Vs4SYB1vmCU/lsDQc
+dh478oFwH3zNFZ9y80fmIUIJywNpHHUHUV7T4nogEtXY0WBFEEzeYkEY1vwNwAFv4YJU6zJbdu8
/UFt75lQOR4nLoGxNUNL/EKlgE5JZhbzcUznxcGa8dStLN7mIVHcAG2/MGoUju4ERNPmDdUezDpw
pxuNVoPmWiwc+IFEsvgZSWU/MAkw5kUWa2+Zzr+E9RL9A7xA619vUCAjc3QFPFM2celyo+CCg29Q
bC/DMIe0H6Uu8lB5OkxgAOYhZte+iAoKadlOs4KjABZ57hAu1LGWB3OkMy+P3AWgKha9OuAF8wHD
EDCpgAdvJgHDriEWlMY4ClgjaPzD1ioh2RbjVU04YRahlQKbN7ubNK8sA3AUSg8QyL78ykzHEL6S
F2t83Eyh8XGVfDuNQjzlSwFT3s4NE7lYBuKoAJzbKxQX3xF6B+BjaVw2CddWl9QcHk1dwrCnmACi
3JEIBydwYRo8xkKFwd0R7uIK/ECqwjHtTm8QOw8F5LU6XauXBCzqLBrYjoD3EmvSoCtbueWXiWbb
wN8QwD8k359YbCjPPE3QqMMcG0SGy6yHHAe4HiHvYBoDIB7b3EGxfzBBZrd6lOg+jxAagvzBtqNQ
g2Li4UW+GWqi3DB0T7Q1oQLxjqbXmWyiCi4SAAb0lXaObHD2UNxpZwGQVlXXuUcOe5am1ZSIjz1G
6wYPSZ8zzjeGVqhD1Ny0PmCUFdxlzYokyCr7ImGbkCjkWbkNeIwo0PUUO03cqDx67nWB4qagUqkj
QHEGd09RXK19ynQqeHqXUIL5tOYhyqfUraUrxOgs9yobwVUS0pXM0ABvbS2qwv7itlfiLCXfbceX
S+4BWt9xabcFvTlkvCvzLFbrDo0XqMPPYSvCLhRC6gIDjx4naV9SkOkWUY8xxpItm0xyq8jQLD5j
QW3BV8vUIR/mZ2D7XKlpS+WMtOPuNIQPE7geY1KQHuFtNipg01vmWMQSgb2vqeFHTO+zoiRQt7nC
Cu5sLfHU3TaoqqVxqHURtVh3v3C6hJ0Byd63E2GpZXhnBMrVtbEhvTucGzn4D7S4pUDbGusnuS48
o0cwRwiXbdpFO34hdYpC3lLm1WWu7TflPYlV0iXDFnFrPEsUN22xyLS3sz3JVtrhtKgPcPJFK1Km
ha4p2/M59bAO7+YBw1K1defc7rbgPaPOZdwAgt5i5VqngUE5VdQutd4i/KcK1TUbRVqliNPEOO4E
qPPMujwwuBbktRW2Xct+5yakoAtyNpaXN2llrY3DemTsFcy05X5iKlVPZvFy1LWRrxbgujcpohZ5
MBsxOZsRYR6qKlXlVAaK4iqVWFFXDiWm92fiAVwimqk2vtAd7VT2QpA165huxs7gXRoOIRhxznMC
Oy+A4ZcHrsisUvgh4ge2eWArBYrgo5idN07srqLo6l9tz5idR8qh5w1QXF8teiLoCy4zRp9Q4Ldb
qC3zUEpWvMa1shWU+FdQJ1vwnJrsBOIu2NXDnbDEUIoI17lmlN5m2c8dRdcKwuaxX1cXRfuAFVTr
qVqjV9S2X6g3KqCUcIFVrLhZT0x22E9wRop7izVq7hzrfqBXauLBpiGixVu+IWZpLdE8sP3O24e4
8+85AlE5KhawrrEw2oSwbbfMWdVYqhU8xMip4lVhq8yFvVrmLqFV9y1qvUDFuw9xrFr4Liem1zLe
Rlv27CutT7mVWkEYpY6stnRb6litW4vBUkt6b9y3m6ZSsL7Ihzz1sBWjfVxIAYOYvz9xbii4NXkq
AiSq9zgJVcmxAz/8W/8A8Wz/APD4/wD1iwZ7JcvZ+/mUQJRBLQX4E0HHEpOSMW//AMxGcTmC8BSW
yNHYRR1BvxLol6gUVTyIC5BI0X8QGxV7ilQqVfVsq1l8ZzHKuRog6BK8BGEY8JOURNCvxK+A8pHc
cYJaNYpXwCYXqHySsmH8AQYXT1FDSUwHR+JQ2LfEqzLjY2lhkWNjwR2vkSMdwv0Ru3DwozF8SVEI
FPAQYdK+Oo3+Vn6uSCq9/KD3Q9JlAwXAoYtwQYeTjcOs/wArI2GDkCIfJ5Qx+8UXyEfDH/8A0zJc
X/8AkLnBA/8A4t8S3/8ARZexbYMX/wDgai3/AP1stg5Fv/8AhPcv/wDahkGdypX/AOX/APilyyJO
JeS7/wDwb/8Ay+pVTPzOJdy//wBX/wDaqVK//X/9XLh5CHgJaBblnKH2RmeJTR4gpizIZYoBhiDT
tdS3BHK7igUqycOtNyBlT3KtZoF68VxH0VdnUvm/e5NLLqLQhOO2JlRDhiFQ8eiO3eDhijW4APPx
FPBQxRtfiVD2vBObTLU8XFF+xB8D78zIuPEHg3eDDrYer7iPpEyyI1u8VzARsIrDk5nyiUkEqNjc
w64uNVgfEd7zT7lBZY5MUrk3IgD5qUR0YpV4ULajUEDDpBXMYDKspGxiqPcYkOMISitqrmUBTVqW
7FcAgNbdDhlCM5sxRdlEVal2Rffo+cUdxKwgBTxNDCLL8yrbdFcS2BTQefUBMAEdk1/Pq2WZd3Xc
amGhDaHguyyuVUOEPOxGAVhXUsFmXdQrAFbXJLiKLSxRvIIDWTP5Rx1B16lzMeqKyj6dThGXTxRs
My08MZVaqgMqqPXuWNUsodRVShxWv6hyHF3qH0KNZAgfW7mS50MrlqUVKY1cpfMJUByAIw1dtLxH
5mzauIx1UuuTiErZdymPMtyKuDbos8y7x1KqKGmJ9QhrXxB5G7Dj7jpMnFN9sKOTx5jYMxcYq6cu
DzKas4iWbMhbZXEGiqxiJSXBYwC7FvhBxYcnFSlx0QI7qW6P3DSCsV9S2iKZFvwU8OZTwdInMdax
S+CR1dTzWcyqyo17VsHzgTuVcLwnBHIk2UN9QhApAfrIYVqqlfpQq8TxJ5N2zlrTRnzCZyFlfuBR
CTajsHvlzNRThVgy6WTA4gwKdHe1ESBamsYYRaK8a9wPIAKDUzUBdMvRi2PeyqQgCqI7jcDjIpcF
NyoSWmq+JT6BxWi1gcimAqqK3jzOA0FZZ7qLjIshRQQWwA5f4ggg/A/rqEby5vgrVdgAbNyKEhVV
KPO9K/yVpNilTnBLN1hwD3FDJQcH1UKkXEUzuUUKu+HiLFoT5iYWgyy8ZHJTVzv/APOSVK//ADj/
APQVijmBcrYHc3INysu5dn/5TL2OFv6gW1xKm3kbJXDkTI0qkYlf/g3wSz1K2HFdwXDLH1KlZfJN
EwKGJTXct4yNC5UUQAgXBr8RPUoJpVlEUvEVXWRIXvqB8spukqNQUX1AuVT3cLuuZW13AxyKGoY4
gUxH3BWVEacgg49zVrPicRgmW1HVxEaZxCN+IHXcRSxfHL6iI1WxpFlpbx7nbIbahah+Z8U0V4OP
csrHtGQRzxCuh8ICUUVHzDNHgej5+Inyco5fEztAR0p/qUVFKIHuLhvsdswlmA5sLEMAQMahhAUq
04lvymAcwPSAL1x4mpSgo5ndj89vMAjQaB8wCIct5rhicweAh0oj3Om5zZxCjshgcqVNtOjbhy5B
eKjJBOietmcoCKL89SvSVeIomWFcR94AIyYclVV/UHCRcAfLFI0Ab7rJmAg7IbMtFgAgc8x2pkUe
z1UpqJukDSYqcfE2EdBC3oAV4l8yCzzxMmFdNbgJrE1g755vKLQCyukNuAwvVJec+IQTaNC7gYKC
jyTaJQoe4ctBVDuXDhjEXdjhlrxD4mCI7gomhVBBlugI57ZH9pevQUo4jFDUJXJV0pt3OJa7FeIX
AGqe/c5I28P3CkR1nmcfb4W7BLWo31kCNCi+C4/FWgrqpa1d5qU3AVbasLEjgg7QG1UoduIYnuDW
eM4qXFBtFs9MRCxRPKaFVdQQiulggy8uhxCTq6OOCF/RXcuWhPn4ntazsZu0Vc4JXdeBwIBS9bIf
YGQeKvuVN0B/EWGziuYZhvR+IQgoGJrNJ0Q4mhViPBd9ywSxSon/AAS/p8wXB3HWHlVjDVL8VlMM
Qp3XMHAN4YCdfw9RuyUu4ii2izn1EB+QYB88wshPX6GIWIKONhzFCowVDlCgnB2CkiJWHcRLOpac
Gx4ebUdxrG2lFcdMp2N8EtZGXnNN4h6JmrjOCH005X8Rswy5u67gzRU45L4gXpQBiqHv7j7SIXyO
YCouXTnIQvLcd0/3Be4Lvi0CaVa2/MeDUvMf+VE9wyOQsvWM/wDR5jLAgB9PNy3EoY0mwB9M4hTV
8xEpc5xkOcCgrnqPgBIGjtDC6omQiEa1wWHlXC4fUV+zgm6hQQBnK+yUyIIrb6hXShTuyn22I6JU
cZFqIdESlo6NV7jIdFt3Riyr29o7dMLoLFcnCy/ABnGeYQQ4RV33Ah9BxlhQvuooJUXWt9weQJfj
qspxh3yQkIOrUWSmEUbvDMykqj1CFsClKkhAtvqApZv7uWnBKzXOcdy8alnB+YKYwAMUl9Lyis/7
AJYq80QDRy43s0hT4R0ZEphrFFKlI4g2ylcCKy10wqFYweaHqX8GKM19xXMhofcHI1OoomsHmXU1
eVdECsV8y8K07uJZlMSxBbSeDuHirahHqKzivicAH4j0OwKPmCqjibdSjmSn3gom7H254hVUJfUS
yhXCoETuvE0OrnkB5lENXbxBquIFM5RQq4cvEYgz3EWo7ns5iFkvqoUtg8QGhM8w1QI1Msm3IIap
Xwy+Bb1F/H0weDnn1NFqv0iJ8sgRefcUIoHUGWyBvhUYi89E5d0wA51MAzOJbN2uoOwSLohTsjxw
NCnMFexXpI301ruCCcq9hS6XvmdA1w+YbVVSyK08TDRhT0FVG1K/EAKzr5h91y3x/MO4HuI6FPUL
SBHbuAvLjxcOKCHPiPFrccUS3tZD4WMqD089xJ6lthVAmURrWN29xhslLPPibL3d2wIBml6ht6Dp
6yCnrbeQGaDgheysrzCOoI37iUOIX4qBitWlbBzYniAhfUUbKvglBhS7eCW6CHjmsBvIGRP0qPEy
hRznMtblabNh7i0BFtli2CXTHkjqzhI2BOyNp+0TUBdt+U1ZeXlr1BKdu92VeBo89wnAVbmFaAeR
3Cajdi6+JRC5HysheCgE2pfJlR6hU2V5iaAWF8sKMVKTleUfLYmgMr7gAAFx8ZLzhbdzWHAl8my2
sbWVmQK2UkOkMko52Be0Br52ELpYkBiKRrzsAYBpuFuFhB5lYLdV9yvQJQBhOIRl/MO0RFr4bipB
wI8wLfU+o/qsoJKD3C6MGV9CbjxkcstbeybmKeIjALhp2WsHV4XGJRrj+JnyNIlzkxIJYws6C94q
ottBgTbCHCBdEK0MAHvZYM6F8w5YftcKFcqvzGDjQnxKRlg3W8xnDqHxAPoiDzKOmDaAFPohAFPO
fceAFIu+CEXVh0HMIeGwsOslLAbIlB55qDCM9zavLFds8TYTYIlKeKjsk1MLruAKrVH81L1wH4I7
BD5D+ZshcHbCMaFQKN5i/K5DhlTQDhz6h3Hk0epwZOXbcgvBT5fEuecquUW0pbx5hsKYvua9jTpY
rRl9Q7jDY00JhDXAF8bkYll1J4mFOx4XK/1rAt0Ps13HaooPENLPBXuuSAtMXQRlqyvnOJYiEyV4
YBrhHtmxF9aL4qPKq1nISsDkDDTZSLYVflcWsmE4gqpn6jZBVt+obiwJXgI2YbqvbGs7T4dShbLo
9NOxGJT8E3SaLXxLKW2w9zl1hZed4iqIsieSYK2FBfMElWHsqCCNPS3DRGzkPFQuP1X7UwNaE/8A
j5lhwRB4WWctGr4uUyoADuWcQpndTCLdgeL7hbxXE+o15rK+o4VYpTxaJxcC+GRCFuLZwRR2O1n4
ikXVp8wXBeVQft6aRYrqyo3WIaef/EubhBeSXFJ8ASDlVuPEewoUajh79S4CtlFy/UNGi6nXqOKt
iUJ0RusikZREIOPqAiuXiKDQ/MBUNUiKk/EE5G3KDp/SIc7cQXZbOKQqCtNiTUpSWVwLOok83fUV
1OeAl9VayoKnAXYrYFkEorureSOHChcba7f0ltqv1BK9yroEHKHAUxTLc+JYwfctd19wWrLlxyvm
Luw4gaIhQQrKgyq76gMWv9SxX8IvgJYjzKum2Kl8X3KLrljrXqOijqWgO+poFSbBXVfEa6TYSmW+
2JVBz+pahBjNA8Iha6dzeO0zpofUdArzdww3bUyurWI2pMfzlBpd/qaysdgrMrpMzdvHxOZF1A4t
8SzYNDiWAG9xMvD5jZ5tQF1ysBVYijylAor3cJN4littWqjwnPuOAzlg744RA5/E3Qg3kqFCWhWs
JriArLHxKeGEL4HUTa7RKyhTzARMIBxqPicorU8xqCqR5ZbqgM9zGJK0/FkC6FoVLMrU1zvMoCPQ
SsHaHuIyQQr6jScNh8IqcVp4hZqhSeYlxL2QUC7qFebmElFp5zuWosFRGUD33C+FqXBX4ANsZMVV
jxG0Ilq3WIWmhXxAliVBMCQG3zA7iAs13Dl0AfiAzDwgFSAW3BL7lSftGC0fMiYjya/WTgYhzY4B
0iaww5YNnJ5gjoUSup5PH8QaJWYRCCjb2yHgQcurl2iNP3FtgKV6g0QHdvct1o49ql9LBaYU7CGc
FNw7NiqDzsutPIB3HNn9cMRAzDjNgz3lCSKQVMruEdATRzaU+Ys7RHkvn4hODiPXiHhQoteiKlrU
vhKwwNLzGUlQ+fMA/aLrXslVaKkrPmM1INHxKAlr+NgoVQCDN7lWyWOKaTqXmLTp5KgmjbfuM1ig
h7uDYC03fLqIAIu9P3HnejapVwpBdineQzFMES9m9LEdtJscMTTiULFQ05lEoosLY6+g2vWyohVS
oU06SvbVhBEG1SnoVQPFxyxm0LqhC3o8RQEQMv3OdKifSEVK5rhqBNGlp9QhDNWVCdb3LKXQ0hg5
JUymtqXy09kLq2QLFvzKAijFt3STXzHZCm+PUS6a0hzH7Ae2rg8Nl0XNOL8tTzvA4ziXaReOrMzA
KiGpHRLrqPwGW24jGnioHk4AN+YLFBaUpfqcZp3Ab8ZE7GzZwG/DDUblPcvzgX+5Q2Si+XD/ACci
lI7awiyIUQGid+TJYwbLOPlmgwl2t4gepZLttu2XhKpbi5clAL313LFuFW/U8OFpz6nOUJvZ1KCV
nP4mV6aeyBHUFuF8S4ljqm6l3l7geN34MOPVUmbaJy+4sI/ArfmYoro9kg6jK2vF3Lraz5JstBVf
xLJFOTx3LBVAC3XEOttuiu4IYJQXkiPxY04rYHoLboeJdjZD8vMJFZsNYosu1ufmB3FhBuvLFkeS
XrzA1ahNLJU3wXpS+/MrDK2uyGAU2njY/pORPDKPUClHZNziY5S1DE+rgRzjmdATf7lAtqT83/MF
u+B8bDIXUr+YNekTDe5ijaLUh6qBtOBqr8svxl0r1X/IqiogS+Y5x3LRQWssjtMNlpRNDnioJ1V9
S+VZOeyvmVU5nEAaDXmUGl+7gIN9RMLfTHDiJnZqAqVKrAt5EXjjqWGw35gqG3uUKoCHZdxQSwjr
T8S1UPuOm1oiQDXu4t6GwSt2WWSi4rgUXKLjDk3HJeihHluBwvlBrdoLrk24AKDzEtzfmWVW5zbC
iQ48RF1Ye2f7U4pviAVP2ghr9RQ2GXNy8fEUFdObmF6rshsNjXU4k1fmBXNLk7XvuFAUY7GwePIX
1aRu4d7mOsYsVsDnuD8dSmzgd3KCjDcgwOBsug8HbEqjmqmQYspla1eeY2yzPU6nh3GwK7xH9ERl
SuZq68wAESGh4hW1XYLCDTzAvXxMpgycJ15Jei+KqcdDxkFHFUwpr1w//kv+gYQeXDfUQSa4lVnP
qA8VG+4BkaUP8wjMN2h9aAr9QsSc7hal+SuR7lB2SHm4pnho9zYq83iiYDdFxWPkvOclrRwMIbRI
M1SOTzbGyBdRP9SniY2G6BlNpDzcsKCVzG07MJ45m6ltcSkm6vWWrULXNgQBbA4R8bBV6hfAOnzA
5xZscgDReYHQSveE8SuILFnxDg2tgPguF9+ooM9dnYqag8kQAJO3LKmJ3FvlsXJWetamd+mobY58
4Fcx9AnR7jgVLUj+IHuVtlxcYpbZaFSR5ORegs/PDUDRbl8y66O6/L/sRZLBEI9KdPUvotGbFfYE
lkUWUjMBXIh2qYPUWigK8Q7pMsmYhUT2zHBcAuo3CJleJuHhzyQYA84Ir2jyhLsHOyh4TlvJCAqV
p7gG0WqpDQla2XNG5ZrU2gDd5B02qbzzDWKfo9RVYu1DmWtRKEQuCtBeDLHl92UQ+QccPuZqFi+4
bxGxE5ilMC2/MobOdjwzMv8ACTkcLuP1FtBZsvqWdTu8HiOi1WI5jq7EeJT630yl+qLVsDcucS2U
gdIc2nsSoFgZGwAORFkaeBKmiLdiWJQtNQYHcDBKH8R4woF0IK1/IfmAxAaKLfKxCihrteZawtoc
RGUG1obuUDtwzGN9C0muh5BRfEoO9F2WvMaAOEOiDrkWIPUYRvlaEFgXcBmjHJyxAk7IvCjSc+kM
ztIA/wCzizDwEVWPhwkNClWmReYN7lUXp0WKfdy2ZKHgTp54i7hDSVKHiPwAsbA7W5cB14aVrBoU
8PCLwtUp48y6UHYR9QdD4I7D+37lHQFFhNaFAbXUHuHaFCIVWl8xESDDMXbH3AvF4cs3mYtgRpCE
i20phG3uRR7ZGofPMFKNitsLMNi3MSsXtqlwwdlr9onvNcMcY3dchB0B/lcUoIt3D6+ZVObztFgC
eeEpLa0ob+BlwrdlW+ZygfKxxbULXvgJru028sqJxcerBPIqEAEsLziDuW+SC7RDW1B72a4W+zZi
tUoqNW0m+oObZsgHzrH6z5BkFi7ArA6h4gdlEDCUUr2UL1GlWFOHtmjycqKhjc18QtX8Eu2+OoKv
c4srbrzDrir8MbFVx3ClPMS0O4JLgLCUvcC6CnzEqqNkLGxnAp3INXMaKNj6hjjHzChEpYAqq6qO
K9QOtfMFIzldPmDPCCQC67jYbWzB6JRoahBD1ETpNLG9ijAFhwe5UvNYUgL9+Iyl3eoimi1idJvE
Lg3qGau4I0cCqlm+GF8DXmKmZfUwCqWVIqvctGDywZbQeY9WF9xVB1kWXcIBBKeqmUrlVw8G114n
kLfUKOqlT1cFBy9EGjM9RKpi6gVypHwOXyygY3HVsjeRSdsVU6zXTYhwA9xRJakWORvQK6isHjeJ
cSo79F+IUBV3wygnAdZamrb5Yic2+I51dbzGmkV2lJrXL/8AC0c3EsWP8wNk/wAEwQoPMEkRvpl7
wQX/AJZqejT0sTGRqdYClQJZ4IVbghnBeOFdykNw0tnMfcq1/EsCeu9lQQGLLjSsFnesDwjjXPmY
QrXDX/kEi1250chNq3slCGnklkF7mxnqHEAZq2l6/ExUaYG/K7nF1jbn8z4a0AOCGnbuB97KqW+B
iySjAR48bH8wCGcAcx7hXK4mFNr2vL3D0wOEY6rnlyghgPNy24flFWah7hoJr5jFLwEvePJbWJFi
/BCxoV58QHcCr4IWSxSwvVW4VlrgUROSvt1Zw/iWQzqsI3FOIxIkxG95Epnbg4ypDF5RqBjAo6yV
UCUU1UQIq6qzO09yhuLXdm87usIHwNwO5dBWPgPunmPULlIJWg3AJuKpbNwPZATUHIbYFCuCLcwW
HqZqhqoMxRldSNtVibdp7IJrlL1f6hpUDBdV+ZarflWN3w0SVlsp0f3NWXNtf5lSsG+ZSPSqdx3K
Ti1CHS27gMNLCu5WwRQdYpV7rjliNvOZZxel4fMtFdeeIgS7KdTkZl0U7kTNpZmDXBUZnp2FyyJl
BTu509QA+zCKrC4LoBTlzY/MvRRkpWr8UiziXgSxveNZfYj7Jcifgly9MOauCNt+aYKGpQWw8Quh
O9bZFoMNLiWrBfLFD5j406tiHVUYGCj3C9MPFSnolI9sQgnKSLPECQoNR9SvA+EfxE7QeESUlFgV
puPfmPW3XdVHpVte41NqrBYfFQIw06jjW7JAFWtdNQqF3GpyKuNsuVrzfEZarzi1lYpa4LgtcPUc
g69tgt6PlWKceGdKW/DVS1cbRexVS3s0OuvxGRDpuojNi8axU8niL5RgDiIgceStR2e4bA9aXr7n
Dl4u4ih+XiKA2xlVuEP9SiBJtLy/cIrvhcY1br7g1pAcLGuwqUwZ3KWcv4h9rpHUFu2DVEXLriUQ
svu2DdNPuVBhooWUK4IFlBXFEsnT5uFGmyxsIuvct02e+niIugqL5OIj/sTvfSVIT8E2CHYhRX5w
SuVgVoPENTvti1SaQsIJVERbZEGF0kYwWuQYQX1kKLkwfMPdacy1mX4mtXqmJdPKNqnS/qWxBqLY
VzxC3hVwsDyg46X48Sjo7LNjviYb4ihmXAsuctFsKQqg5ZytPVzq41zcPFwyupx8QpK3DYrRBCbP
MVyLT3LU0p4iAAx0Atvqe0KhAlf6DAKCreJR2T0RNXHgVDJVl83K81JkyLUzHLM7/pOGtVzcASmy
9AD7lr0dKjAODmWWIjz6lF07ITf9wUWHC+ZhvKOAhUrhLvxLDOJuoEYFWzCeVljEDBDhbKVpxcj1
LFXBz66g0buDYCn5lUBcBdv5jVeHWQxzz5hTZ+RF3GkUKg/H/wCV7ePSMdYfLEVjWp8k3PK9eJX1
UZLlqag52C6TrzHaF4Owpcnt1ABvBolvAgaOWXSrQfBJXvhBOMqxUKsSHl5hHAq4qWsAXlYwNgNP
JCrQdU5+ImafKlw0pi4aVX7gO1C48zbFY5TzNAXSHMYqWkqJMISoAXhBU5qphYs4+ZUEiT27Qkts
j0XHbKBByBoKXLAGg4nLNENIgzK4rblQ+iEIuEuOuZLkz5qByC1XHqJew3Uzg2NA9cMrSmsVBUPE
uAJ2ErfCDwePiKLbfUMPJFoHzNUZWSzXHcot6hseV3L6KiX8QdKVOFdzbK11csXa+IjeLfcVenxc
5tVDEX3LgBSI6SvuUVKt7melHkgkFDu4XWaXUukRKfMTYsWBXEUtVbL07pddS5eohYq8A/UJW2v4
gcbYyLdBZYR21ZkT7slqGh8DuCAgOIggpl000/cR8PUwu6IJGnzN1c4JSPTGo5SaZFTzAJhcFbsv
3GVLIU7Y6gA1TuCzac1BYYwLwczMNCi0eBUUhkYpBLlPEsUn3B4tchzW234iOlXS6QQey8Jxvw+o
EQAoy+IJFPMUiQnZF0Kj7ZMqsWX6AUCuYwNLW/EMUX5nkZARZcI1BuvTzGhdm8RODdstYtFXMss8
r9S9FxRXfqmUBTvMHR49QHctlZFAzPLAIhlTDbj/ABBXtqTifh7hUvzxHYPQRaDHg8S2VHDfUFF8
xCtLQ7LSLR7h+tJQE5X3sxjy1DCv4j02iH8xkMqP5l+2wNWsoyQL5Wclixr3F8ZCBYr7gNWELcc1
lAYe55jwgCqBXl445l2E3DjeJYSzzGmERE67glD5ijmQac16mNXAVrbqGqjbqUDH1PHdJSt4fPUs
puyvMAK5vqYtiHmYW65otgbW+J03PmctfU4gHmWBuCCIcIOEp8TdRXjuLNFpkosOiv4lSDYCq9MK
AxZXEf2BRgxjDRWFHwQC7lMdXB4bS1Oo6J0NhLIbNq5B2XRuFjwwMfooqoMwNOAQsWjFhqvI4CX9
zXXm5Y1TLi8rjhCgY1WMiH0niC9D7Ip87ABbq6pxHcQ8Kymg04iiOXwykET5lPunWUlJVO53Sco8
wV71DUwDi+ojrXq4gNd6qAuhd+WKJariosQetwGlXsAFAi0RUMKovmG/FBVZ5HzGhHiHOysQT2Sb
QyoAJLlluGVMl7g+P+S4ZaUlwwxld89wUL1V3Au62pmIXLVXjmUNOCYKxepU7KYF2Ok58g1A0G1G
aO5YxiuYiIxlqRfywSVlayrZxMils/tRQ4DiE10PN+I16lfzKKO40Uw8wTYcuWUK0gB/hCgVLWs7
2WLC7gYC3vxL+oiLu+GEtYy2M2WX8ahMbUYT2lDuKiNsPMohwCJbfiKyGgXuAW6jiKSoFdpxUHi6
1zIoxSRriN7oIr4sckcTmaSEFxC2HEr/AJOOU8y6bbOuBcenxMVUa+ZR6KLB0KqA5e0VcnuJ7HBG
vsaz1XiJXFxT1BBNHfDZZYXjpEQF8VhAFD6RUAeVRjQ1uv5nNRKgaOTqWvqviJFm4Q2+JbJCrVWy
yqlW8VONwUAt41s47IpQHLucgyqstfwHqLvhoEqK9KuRuVD7Fq6uVpB0YoiVAcCGr2sMlEmHSEaG
vUSoly1+3cK5CTFhfh6jeofDqWn6gAZVSr6QRuZRL4y9GoisTtqWQtqKQ0btXVcxxvI1B+PUbAA7
UGiltEqWA6ZHkn5ljRT7gAsqkzdKfBcKqFiz1BOTQdQlUNjDwEM19M5uWpFoK/MofoPniZYzymMb
A9ReDEK7uHVxOIHZJbpDdLgZY8dXk7hXLLhOnvuCprY2p/CEACh0i0YsKfSJ4Ix1bYcF2QrIrdux
5YJBJquStlx5BGO5LlyeIdxCwDn3HLGLYOFRyzkL+kF+rseYOoPJ2oCHcxW4Sx6C5KBCbfTHwF6n
eTexXpW/cLRNQpLAK2OeIF9Q9+oqaxYe2XNYFRObYWAdKnCKuVueF4S9K0U4ebipKxwOY4YYHKvY
HbEp6nAdUVXE58W8RVPSpT6nmN0PNbC1TnxKqp5TOB7Qws5qICcLFoIq6jCmbLer9RI0loIIFAVe
W4phjtolchSwZyd3hMWVKRlKEG0XbqD70UfxAE0Goxj9zqCuSFzb1FDM3hkrIidFXxO9tgmkCZRw
zmFWdQVfEpG22pd1v9S/D0fgj8TZnxCamU/FAFLsrfuISNOOcuEABAt8+IvSxXK9xnUA4RVZXwgL
T8hHRD4ghd0nTAXHMAYY3FWUsJajg52ArfMrTWjJydCGJN3pRETbAevKWCq5E7iB7CgVEUHQ5Pc9
KChejAffBLOgRQzOoW9On1PEgELTBkfHySwIUaOM5jNd65MYV8DB/wC8Slq5S6WpTAK5/MvyDp4r
7h4Wmz5uBczL9ysAFlvPEvsyoOG9/iEVqr61bnJcQDq5ruC70WXBktWnpLiVMR6gcIAKpQRmqgeK
lE4JlkRb7fM6pEsY1eRFg3fUpplUEPXAeWDRWLFrZf71xieYPQKquDVwVmcxa+II0MDxDQu0vpIy
mJd1lxIT0ItNXUEFD0iX6GQoVV/MqBeAeYCYFBSxz3NMZY2IeD3Eu2BN4f8AIZdAXxIoHv8AuDwd
70sA9ZIu2uZTPOuh6iBhb898/qEGhWnNbOKlKi1tH+UgGwnkgiOjHy0fES8CVzE15E2UBGCxpnLE
lJfVwhYSgWHOTk31caOQsDWqv1OYdep6AXzcVg4yogKPG4ypaZ7nQlJKXqfKUtOuhBdLeZLgs3Vo
XtjrYNdwBa1FgkuonW3LBRs4KMlTao6Wf/KjYvfXqHZ5souYCkS2VBx1E8TDwChqoB0CtDuTniVD
ohjgJbfEfWA5+oOApY+ZyloPjiZ/kX8JYtPhbENa/ERrebr7lzBeRioAHUcxBtkoLd7XzG0VqS/N
VKfXeqOpRZKtiAiQtRi+YZWCtSpA65O5boI4eahUSswqwcBXmChu00r5jRAF2afMVYIKprqGQOgn
LU1ILvpCGveMggbfqWiONnA6Afu4zxepxWRmNUleUcoXftGdNynvIw88DycxcWmbgMoSCvMS1Ckb
34h1XoUclFJx9whHl8oQN1fn3HY7wfPE2aBfE7H5lkt2MgPzBcgPtYhWauVriVD6YkqVAVaxzBuE
c/Eo6oBhzEWbfk4g67BHCvExo9vgepYw3R5fkiAb0tR4AJfBNgEFlKG7qlGGRhu7GY6lwNTp1LWe
OjxsUyU3DpyHpCwvDb7ineSPvIrmz0fzAFUH6LgnYarARdQG3zcWTruwRrt13KBtLp/45PEqtDak
0LlUcLauTB8FS4Cjg7iYWk1ULTmKLimrLilaw5l7fEaicCY4XUR4ZHYL2h9qNg6Ip0E033BhajSw
jigDhx6nJkRMV+YmTxacov50HqDUjdHjHEJblP1DyO4KDT4l2DqMAW916hF60o8VLSofoDCUcbwS
mEH54ZVQAsPDKJRQDuFgtRp0lxvYWBXg7i+i1AQiPA4dZHLXS08FSkUv4IQmUX8R1BQueZYHO4l1
Cm8xu1/KY+o/iNoR9QAJXPMShQpNlLmXwQrLpXEoW2+sXCu0AlSbFFZbmWYMJXBdVCnkoKZC0trp
qIGbiljxFpCzSDyBxZRfmBCCNEbuJVfNwWeDeSm6ediQ9qWOXYFInA9w4CtQmZOMhY0+OIgFUKrK
Gm1JxrjdeaV/UtVZUudVS2/ECnYpb+48amunxERrZXorn9wAigxUYpUr5Y64VgH3FsFrlwFRd9w0
jvualxWXGHX5Qty4i7HMCgMwF28lOFS1UD5hS7KxFIgHOSNXA/IoCmvED4RqC86uXsjQHXzEG4ou
DwQsacdCIm++QMMWG+TELrxsQHHm5RcOeLgQHFUBNBAPVS7Y1U/zMvDxRWygK7SP2lFTQ7fceiKt
D5ThREr9wLQUG+ismm4CDVhPRQD7f9hdwQT7djeLm1VbGe5YPVkP9WKrvEq1+JFk9qVK6X6iwuFy
gnKGChKPkzZQHR4mKFQOeyLV+VnR3H1cXSrPU1qaisBvMHoFYaVWF9RiG91YMalTTWx/cFQWJSLa
NqabhKklbd+YTvBWyilfcri8GXgHV3xVTi61I6rZuKd6f3LTCtGEoeK2+n/YNgAA+L2NokFD1ANr
QfBsQ53k8GSvlcsdRlgLPw8wBt1g9yo2Ybi/NzKDxHF3NToVWioAI5CmV3BuFb5lOVXsmIU1lL1Q
e4gr5RUK0SjhpqNi9HMSiuSUQCmwAqu4MbUXL9iuYCVNniDtlsxEaO7ChFbWJ1BFhjm5dQ5eIL4E
amsPu4fheTpdzqzO7gEot4NniU8e45Lgx8MYVa8y0IBOLh5CI5pjJcXdwp4Ur99ysFvdfEBgK9mw
TSsFfMao528RuSunUsobfnvEqmoha9RO0BhU5hFaN9hIFYUj2wLR0C4EKIC1B9ThAa9+pQBvn6JY
o7h0wj1Ra9orXOYPavJTAtY2a0rMpG+VFh8xYtXZ54i09U/dMD3D6SpTqluIjQpSsT5gqwfNwYaS
0LQlBAroKuAYFQt3yVULQPPmOmjF+9hYxpoPiViW4IdbEMq8kAEAwIoDk/dFss1xfHc8TDJ2E7HB
AcHRwx+JR3I29g5FoQ/uN7incmSaJHpxDQBpaMVA5xiKqJ/MDCqfDBWVRUopTUqwKIsFryljgI8b
Bpw8wn40Tv1Ces6l58yqEFaOzjuyKubtAB6QKwPDkJXnB6zyy+WWAqcDn3ESssN6mbyMgbHcor5H
bjANFC3/AFHZECjvNlGIWzx5hSQstLT7L/cB25a8IjnFThUMj0lFPGxr2j5KPEcZqYU+4JNYRcLB
8B8TFVdZwLmMmk4fREoa5CsjjqZS8Oo8Bh25Y8XeQA/JAU3VbUaiA+E0+C5UVJbWROXAUdkACxfZ
f+TnsH0ievEjzHXsp6kP22e2+IP9ZdpJdlebWywAC1FWtvGpKloJyULh5ug7lzvl8XLn8Y8FQLtB
0auHA8UfM1gCLyNoBbHRh6JHn0/5H3jLj8QiG4LefcdimrQ3JoxYYaCmvkiYVLAg7SGL3kCpoK8x
Koz5nkLiaFXssNO+oL8BfUTQ0EAbVZxcEQ6dxFk7zFtmiPIGk0RdYV0wLZY0udTDA57+7hAVVQvy
Is26jSvmPmUOoXAGJapfS7z94eN+KNCW4Fzd0ti+LfMprTVfEU0bqnh8ysrhkbO1QaveUX1UWAVq
LOEgL5cuYrYGoPNYZAN3gm8whEINOoU29t23ObAhbVCW1UKVyqq9VEOTBP3fEBUuRlI9Sthp83BY
FZsotrHzMMdYFS67HkYE5Bp5ZZ8sU1JkJcbLZ3HgjWC5G7/yXuWNF+Y8NBVnXmB3124rxHrl/mSc
jZNrVySpoWqgzNAj36hcDQOAOY1j21TESpnUFRdtzNIUV+JjuAOam+IWpQclySo08psKIf7H+wge
CjrygSLDXsNp5j75hvQZXbUSzIotpsWMK1OWRQ55f7LBQNDktEB7Orfma/hV3F4cERrj5gGre9QN
mlXglLt11BbXJZxp6mFmvUYAOYFnMZ82cS2i3a4+orgjtPEtEWWjWGwm6vyhqoaN59yjOAKVecfM
vgaNjAQtvuFEeG08xg8Msh1cUUPEsTSp7EGTQgeKl81K8MoU2Dlb+4MRTI1U5uGadNtBuv5jcFtD
hIXiRxediGUmX4EQMjzOiUYVVmWXKEUu19zCSK3l/MZBQU262eTpdOYsBti3TIoBLuO4s9sS8wl1
PL1LtreNhKCz+JTp55iFAn3G1VwQsrw+YQvL1N2KPMsEWHuUg8EtdcfUqwlfFwHgp8R0ipRtipcU
VhXMsXv8QrZt7E4L9QLVm8y4DnuNQ/pNRqn/APDBBPUdIaclABSvHco/hv6jGWlN+oJ0d1y+44gW
Vt1Km2L3zfMDSHl4gdDNF9oSbGwp/Ec3gor7ItJLTU9y9QZyeZW6Me0yDGlNHPiXjn/QgarKZ3DB
per4gVAQfLUeCndd3Lyi8qMCwVFYpyczHZ4NcVHDovddVCSUcLcNS8Qmhdp4gEaiGcRBGf0Tngq9
cQLmlquY4dk2qw5gcnLjSMUTIQCqzxFU9hKxxN7jwTCi+fcHEtXAdHmEfcDkb4qdfDVUunYvcsUy
/R4hcYpsu16hUYN0PxB1iN0eyEMBCrUAqW6vuXC0KGClrQTiJ2xKXyRFjXAy/r5TgXZ4lqOXELwd
MOyBUcLVHmHiBZdRreNoYxAFC1cszrY1QQ1ZKYNY/BYk2iRUTmVwVrxCI6gdpWLdtIWLRzGx0qIh
cn7gKWG2DHUNQTMvbR5OkJpdT0RafQqYf6xXxKcmuUuMamTh3KqobfmCLtLVeIY+hgw0cXQSpV2M
rwRVGtqC7cnU7zXzFptjqaCmROA7tZd7e5zcHEHlGvEIaQaPMVSiKt9w+KqDMiDAPM5gegXxKJNp
UEQGB7QhrWuhK7olLtiYMsB1Nyo4DSxAHB4jddrxG45byD1aReXxFOqxUlmQaos0XxLO9k4uU9oW
TWXWV02Ra4u54eIn00VqIpnCuTbUtIbwxlLcpvgiXc7xYSlE1VdE77QfMVSuNlCY5TIst6iVaxzG
jabxGLabuUB5Zzce3V8SigBbA1pRpaEHGgjr9MskhWcBXMFEU6Hwf7CfynFUshvAN/E2wj7eoBAt
aVGiWVKnuEwrts9VAol3ES9hcBqLY9nicWdroIV6kYwrmUJAOXZoJBS/wlg+VkTuPmEaXkVd0x4r
iWuDSW/zHD3Svcc3jFDzFArvJnzLyjTz8SkrC1cktXas/aG1JYsu2Kbjby8RscE0pe+OoithYeZS
p5emD0BfqJNTWhLKcuCAotaYv1AqtFLX8CLD4UFrWQcL3IV+4MrYo9VCUNZS5hnw+4fcJJHValk7
3iUKy98wx5bA0AONiI0cWVXhcgT0ikT98Sqs89EtLBKau/5OtR5VNbOc28x4CAZ4i+OLLSmL7a7D
1F2mw8mA/bhVeFxi5onDiLFqX5iQbc9SgeL9xAGhlmlRDXXiKVYPiXBQNguL4IRPwlvpXRvzCtJg
btcXCFaYONxUHdK1wjDYtlKuNsQLot3GSptjfU3nZVuDl+AmBCJK28sNV5dY1lYibLlzFR+ECWO7
LvmNYgVdav4ldoDGx46lFtHUpcd5STwIQquwu9nPNhy2VlFQPJ4h3MvbxHdmonZb6hnm7j+p4/8A
ENkauqPaVYN4y3CVcYwwvKwUrj1ESIA5cA+TmLgGVp1f4ghRz4hvEIilj7RBVBHxjbdbUy1d+JYF
DbfMQRw7Ivx3AJTa7lLHYhNA2vMCigvUGjnqBT/MsE36hYwfaCspg55YQMOOpagrCb4RpIDCO1CO
91URixXEe3yOYgUwBXsCo0bkzo9n0uMGVgbPubU+a8ywrRsGhmSROlLi1rbBLH8RWop6YkV6aPl7
iiaXtHYTjyS3qXHqo/tGKlbHaQ4uzhOpeC86wRRjx8wSDz3LaZ57g8TeX4gEYE1D+48QTe+f3Gbo
37QcjgcgQy2KKA/uUR77DyyoaFcVFs5Szq5cWD2txRAbXma/PMQk89zvPshh6a58xyj1OyK6i1L7
gQdtkw5nfb5lvOnwl2Ck1blUoVgLUPkQ16I21VcLMI5FBNAb1qHi22VcTRs3KtMNvJ7mqzPcrwhG
Vdcw6IfuaqKTlI8IUlxVEscxvmDDcK0W33ouMAUu4fEe1sNocW7RjW+Srl7cdxdCn2mmWQXtawKF
8wKrMOpfBodQxKG4UM3V2euZenvmPjY9xSJ2Bd+YnE17m3Np1NDBxbKME51/EYWVZRWOI21MwLGC
2dyeZ8xAdlBO3uLaUVNaph4mqVfuGqOfMyGDBsK5OZpD35iXimQkIBSrgiAQcrgjaWyw5Z+uSFMX
fCnH1E5zcaqX2i7yp/mQYbR6jeOK7jSPEddUiIiuupqtDk0gYJ5a2vzLcEt2g2ULYRSJurjH7x1b
GexVRykPKv1L10wvmbGLzsWLjfJzM4woPWUwicqdjhNKUnGMpCbUbNwnRsrWwtiq1p7nKYwHR+Yl
lihuzZft0p3DIxGh6+pYxwu1yOOBQj1c730Un9zCKGN0epnY6IkVPmvuXCFGHaD2QWcqXEEQHyTm
pHupQJV3fEyDlriU4FTBbYk1s1TKTLv1BDunZFLjEEjqpjO1seoaUB74iNbplWaiO95YAPJeC5aS
WPwMCXomt/1LgLMtobXuXFKr5gPl6mG5FtQbXMIwoncYHt7Yq6AnISCPEPHnKR495kqGq3zEbsvz
cOxgMzINFZxzKaCwiWwyFH/YqCzZd38RMFPqb5CVUdSmlico+iLouSuruCEtZ2vEsWh8wmwwHmu4
hbrJaatzUIdqaFpvmALVcSrBMKeDzPIa9QDhwNlWAcZQ4isiSuU8yl8bcauzmoJ0VXEU0xgDV3z5
iAB8jIhQqLzlOmzAK+TzM9YRWHviCCkKgIK5GGmueYL0sIXKHPcYXZvUHhWdRPV61/8AnUaL9LiA
oA6HiUk2NTZ3vpnBEPbFN3vki2Nue41yt/MK2JUoOWTkdPzElH2kANrxLgUSwirpiAcQPA6iQLYc
tx9QGKu8JUorPcVDXDUQaePUpRp+ZQEC/Uu1U/EvK8IKVewi0GlajRZTY/aIdDt8QVSWcbBZ7GVn
Kng2LWQsir9dSw9GQQTe0+b8QB8TzKXqnol4dAtuBZCFqIzZ8wvyY4uouAhaH8RdergC9Jd0B1XM
Ro0lkOoibV4ha7F26fMK0p5HEbxXjqo5ApwS5ahb4nfRV4QA1gyoUgRqsOYZqB3GNWxlIjSKm8gc
0C+GGXU5vKKsA2NKK5Y8xQ7nL1Ps+4gUB6e44Fsu+OIqAveIqzjhlQBYy+bA6HmKtfyQQRdxAItj
0n2sRcEHmMA4jdKR9xCoDVyHSDyJXbHO49ncKqXnubKeJzDiX3ab0SgLszC/ZMjnWREDjJaAdTu5
yzO4TvFVt1MuOpJfmDBFL9oqT7EXuh4jWqbfEwnbmpaocwuWB+ciGjsUVeJe9PcpRbLN1UaMRBAt
Sp8iCbcjgiU8wSuSFKbpNDyvHmVjEHJY+EEyiHmqm1Lr5l1tIq6PE8jX3Gt9Wy9BweGMLlxD6rYi
AiWmq55hpdojU8s1vU1XCAnsSl3voiqx+YKlpCnLEgl14jXbRLQEX8wmtVlSztTm4+porKgKjklP
X5PFQSc1pZ6ldemlcQTY1Mlc91itbDaiOSZENUqJHUrtSckqjXoDY58nF+ZcmqhAEbSqBr1DRMYn
XmGC2V6Rva/AFv2zSqE3/I3Vrj4l5N4a3HBWYjblo0FVBNgfCEUimmAXmaRQjSmofpOWmVBtYahz
kteBKDq6jgS7vm8zaOsFNIoBHxxKyrT2+bhqx2KnPUtMp0dVOkghOIRid6HuGpJNhpMQk4AQo0YW
OWmuA9Wb7+pRB9o85jh4+YcWDVFRHKqjSzJtPwXR6lsCBVc0gKmkHNLbrzGpqfH8wQX07WhO3Cnx
ljFtgn6hk7QPb/UrPAvWMYyx7/8AepviYVHmcsZwv4TKgKnQ+4/ZnbAuh8MFpSMwideTKhcNZXNX
2mKAbKaO2TiYEcwUHXmD6Ny28jFwVRy3zLlXz1UJqtfzMDf7lCylQpqy427G92VCowdjL52KdIsr
ojFVfqIOwg2W6uBX25YAMYgL18Rul2LksLHGIprfMtfZ4gXQVfZCPMPEsrRYPcJYhSQGlq5cQ4Y8
23BDYiiGFQcZRxZLCnPuHoX7iRsCWFYW4mR5uLG/DqDZ+RLO/DYIK+Yhvj4ls3caWDOqljVcSi3m
vE3rGUK4VkUHG+SFVrSzCm+YAf5RcDDuo20EquWDePkiFVr5ioCV7hLVRbs7aqWw7cAovMSo6lmt
WeYkeOpTd/cTtpKoTTleIIrCncJgokS/PbBbSjZWHzzAU4N9wD4Vsbf5Jeroe1gDJSQuqPwYCoru
4AmQXZKBgEnLiLRhASYEx7l6mR7Mrf8A8GntJW+ZV0vlNhdyoKKGEg1IZpKQeEvI6F6gXB0HSB0U
NDtrmCsxfjmPrUCjlnEUibt8DqBrTp5h0lZ9oNRV6TDO1WXYKthqwJFNUHMuri+zUUHRQnMqPYuE
UGxmkJd8w6NL4viWky57KmSNWgSoOG2kQzKu+bm50vqEVBXJM0DyEEgi6hFRtt14mMN9sbiA4hq7
7nAt1NoCn9Ru/pmSlnctQWUZjmJDsODnZTaLsefbG6DpRxKFburYKvEx6l40ku2Vpo3SJGVTDNib
IDxH076jQN7F7Ng0C46hohVQAW+SAEvhzEApCW5g+Yn1OH1Mx7uYh6dl8cRujmIQlWOlxJUByDca
IHgZdbfwnusX3KwycjBaahbRtg7n6i69rlTiXAoaMrvxgGOgNBSUVKNMBXGzzGWUF4lR4ZeB2QMy
BZF9CqTX1CjmnHUKKFFMUSxbhawMVKE55BFQF+oyKe45ImtIZYnZkz3HjaMqsgSyBzr/AFHO89RA
K5gxRxlxRDWYcFYCOSg45THihLQRmuqe0KKqpzhVYBsHcV0yJfBiEvDHx78R8u8gg+qqlXEOgcAE
/wBim/5hPEeTUMXeKzZa6RfYMo2QC/Nx20Gvz1HR0Ku6GICK4oBxRXZvcAUVoPjJUwJypqGLS5+w
EGILYaODzANCOSU/BeggAfgxoZW0AOTm57VjLUWjHOkyoJTldzxPB5P9h6IV2UsCITk6TNXVE4Iw
O4ODcY0sZ5QkwRQAeoBgG5+WMmuI8FRKwodjCLhUBriOghZVdGROcG13Rr9SoQG1Ogh3EWSLvYqi
WBS0JRCsTt13EwqRtZ5m07kW179xJDFvUviUtUVVWtQTdxeh/wCIFQCtK2olmajTmDLKmjLzzi1r
kPbW0+O5mpOmkVcGC/GN8obWc8oYVVSqxdSjO01Xdb/MUZgYtPhKDW5TYZdfg7LtPzKK1BVS8xix
iCryaXhVUwsWV0ypQNZTRIUaq7jao1BUjyyF04DIi6PU0sHmWFpcLRS4ziKy8buoW8pb2JkQjKil
b1koGgkQXN/ETdriJSyIohSbO8aoibfwnEQ16i0Pc0NVwiRaNxUZMW4NlwTnl7gIJNJXPuOKUeoi
yqpVQvIu+YmwoGUc1eYFMtMTNOvcWoVb76gm9l3FgouKGu4mgYmy57Hm4ILtC7MYQK5GI3fMXim8
RQ0tdxNxkE1SOz0IqL7jB4MdD8okGUepQ23ZhCCVKnH7jKLfxG4W5LNRYZxLpGKHEeTE6hYVVbxL
m1tDiFDwSItv2RaSsFrAlwI8ioYctyMjwfc3DjxEvS9zEdtJQcVXuUtrq5QKO4gErYW40hikKpLJ
U44BmrIKS4At8eJyhjC1NYQSXWvMA245fcD+RHR2JcVSfEupeVPdKKnxsCeSumLn+WEnMGrO4Y0K
AfIwLNID4lVvS11ERJqp9zLCBV6j/JBSjuVzVT4IxCBAD2QXOeD5gawWj6grtqj3OOLc5ivU2zqG
AAC2oUBT+kIohFr3UWIA5ajHUNuHMYqdDWkyyoNcQVkDmMgQO4Jkt2WVfPzKF6ButlohblNlcAN1
VFQlcGzlK2iy1xAJcfAla2WnEoWLfzDlF57jXHJjFI7L2GWF61WjEqKrmufqVJDYjm5ZM/HAN0N8
lwIqMSudi4IVRUMA1eqIoCHAfMc8dGkNir5kW6BdMVLpVlXWx3QkB+IKawt+Zw5OIdZzAKCwGaAW
/mHBEoqioNTyn2VD/CICtZzVrMOZWjQ32RZEBVj8phYNjxcvNWgA5Ir4DLJXplupjj+fmKTGrhBs
U9RbomS9weJVmZwEHap5WDeoMBAB5pa6Mi3dXGtFOFirixV91KOwcb5lNUCrxDTNw31D0GJx+I1y
1lHMbBzCqBGqvmEnzdvGxVeqGayx2mtvMRjnKMEiToOWXy2piIozsgBWzdRw4dvJIWErsFMDaKLm
MOx6gJAhDxLGcYfIU/UEWPK39zfuIPxArT1XCEQWONqpbU6oLRcpjiaJE/qX/wAlDKIwiw53MaXG
2HbKTCy3iAW7muHUFwWNckRSVQOxnF4UzxOfp7dwCoEHxYBKKo5kO+fzyQh6py1TEmoso+K4mBsu
B5i1tLrqg2Lurc8PuW0LDpgAzS5rlpYAlMqAS3qmD+qJfW8zNDXDEZl0SwqyUHTyKHzFoaasdjVq
FrIAvT+zzBXFln4V9w7IIu9ROBpGiS5ge/iUIawOvUIUWwfNxBrsAPFWQuLV+NlDlBLqOZBZOfUW
6T5isaFPqDOXWdxlNcB8R4rLHyX1Ebrr+pfRVJT14lhr0x6WFhpWflFX3AO3f6lf97EMt4igl/Bq
8xOulFFp5gUADjqWkoUH1IcF2DYwkblo8PmI3AwXw3ByEI+5UAA+HHUsy1bgUOruJLenqFdAVME8
ygna+YkVnMq0MSVO9fBFDpTkXp+IoBxcbs4EFC61PrGVRyCvcDzKkDZbQi+poFUxbGEAa4l7cU1B
o6GWd16lLd34iQAfbFHixjiQsqg10uu5ZeAiANfMu7/xKtZkG708s5x3kLr7eY4sePMqlQp3LREX
4q24KFU+Y1S2pWxxtyzE5+qhUg9ykFkyUqWyBVs/MA1S4U00EdEOKGIFDsCW6bYs3WQzOUd6Oxuh
C8hUEAQIlHHzUSjQW4XDNZmrTupiOeI2c33EqGrsWKtXGr7nE/xkF0eqhfSDQFkQZRSXDha2NRNe
IWbe5Za3fMBRSuoLRTDX3Gii+pZzzzUs7LOo8BzBiBDXjqWHw6iLF42UYR/tNUAHVR0sMYKgYLGw
HI8Qe5dJs2PzEUFlxBjXJSCXdS0AVrd+Zh9VnMC7B89RrLwt9yoXLoPUSx4I+ow6itxqpgpFVAEs
1IAhUNpbMMCEdfqEGbsLzANs36VOwhgPmPl7rbyiL+aAnNS1MFuULz3LCsv6MlHsWL1XuUXbqqoQ
k8xKvgW51OoqSltM69wYsijPMtaRwXmoPtvwKl2ZEWzf3FXdVQ7A6tKDsjF9hPEC1FuZYFquzuOt
uu5gHiYkjhh3pSVbqKDu27bA319f76gDZavjYlGhVl8ZOFwthOZtQI25felaYIdVovUQd/Txis0C
n0gzocIbkvXwsq4sL0XhsytbpYL5HSK8vbDvNO5yAuFB4uGeVNq9FwDLwnMxe3trX7hJpW0dR7z8
6zI2hbV8bOOnd8EDKAEZBGMtUBSqO/cavwNvudBi2b+Y7yOlNLlv2lj7gSTgR6U0pbCWVlauOhbc
upOfMThSDeCPBE+2DdnNE0e6yMcxEPHuda1F4qXEKZ4QJDH0LO5epYNF+oHxKh4dmGhAW+Y1QaI+
YAMq2ocrUF2ysdR+NdQUvmPKhbzzLBbtZ4jsolw6ICY1yOEp0xguHw8zmTi6KapB5S3BqBYOp6s5
hm6ZnCRWdFWeu4GHkXQueM5O4PnU5Opg8Wg2J0hOeGVshKPUKwX1DkWtW+5SdiAfEVQVdHs8xiMD
ly9ENgib3dRm7mz0wBCluIxDkFUHmASgpErJaATys4RBUrrOIEkb4gXzLWlBL7KlB8aHFMN2n1qG
H1uvPiXgqAezuVGVimuYgGAWVazKR2s4mlQaYIinkgCLp2v46jqF4I9wK7NB+4yiVrXD4hZztANU
Mo2SosDwnH4x+peMtKrgvIS81X0wx46GLfMPyTYDnJ1NM+JfN7J5EhXkndcIGqruIgj5WH4QQfB6
gtV+sNVLOlHMZeqRL5YVihSbbiKKRSjadm91ScygRFHkRmEA/LmCtUL8ZEBkZz3VfzFsppbj2+Y7
FqW/cN/uoHtZhQ+LmxWVami1UcvQiKc1UR+s7JZcJf4IG8c5lHyThiyHnzCB3d2xETai34qsnCBc
A1WwUBVdwW3kiNmzyddxCp+oyu8Eeqwh7r6leDLeIhotgx7hS/QiIDxEUOoGgJfcsKpvuFj+Yhxi
WnKUAl0RQ5oQ1nJBSZScR5LywU5r1AKTRAqC3ti1GeWXYmXUsomnhgUBj6i4HEaWC84iq3VSrFRY
U17nEhAmXEAictsiKVktKKfucg0rkopTRiiv9Rs1ww5Vx5gtjibdrjTXM1ICngkHMm4mwlHJBIHA
dQZvE+FgEjso/JAbDX3C7JaVGvePUpR1KwJqzg8HTEoCx78PEFc9zTLqF2Gx18X3EcmuI/yROl+p
bwFe5qJzFzMmQ5nTXXEVjyMMg29mId+43Igi003BfeLLB268y/qFaNPAdxGmj46nowPEQCmOMC+A
L8/uMYKXbr6gOlMsjFTKX5jUDwD4rmUagOu5zabx/iUQBshtESMFw9wcgpa1aSxxYWfENjdqFh3v
2b9xCkgvks2VB8GwEK404WolSjWnhgcMix8wAoC+HiIgqqOwQnQpR4lxwKsyrEMfuAZDo2hg8TTc
Hb8SsBGyA1UDBxh+44xgr+5Q2QVfTcBAOAeaCMKtV8xsePMogHJfiUuKy8/MvVLkYGnupsJ2nMeb
6h2StW6xJqLu4Hhhwsv3AqPTS/3H+gi0JlE196meB0Osp2twSI6OYUuF1t0MjYY1yANdgVc1LRNu
tQng8xEVlABE7RuwmDBUij5VnJ+Jxmk8t2WC1E26jolq2oLYBrbzHTcJouqlZq29jQny8hb4husG
Llf/AIAUZReWgIvefzJXxwFV5ilZtskMrAdRVVbFtacly0thMRVnuOcBk8zlG7d7Lej75ZXDKE+Y
YeLryAt1sb9w/JjV+th5Y5+L8zT2VNpFUC/iC/FxTqPxByr6qN+Ba+UdtbdRnUxgtQtVlHgQQhLj
io9lB4qEKQWvUIbQFsSvbDhXaXdfcHLSiC3QYK6h+66X1GRudJ1LwinI8znqs41ERFnpSzOgb3NZ
MCPhLTDurkAtHVb3N3nERM+Y96v0k8NIrmidQwHzAJlK3WZA30AX3BtYjKCsNiGy/i2g0ayIyPAv
xDwNFDsvVUtQupduAoXUOgcdCw9urbFekhScO0LluodgPzKkqDdAhvlqGKFFLhW+0xwNWBKCwpp5
gSXZHBXEf9BKeHc7WuC19TEBQPEBv8L09wBKpo/zHgqPCXbLxNNKHK7hFbVrysgtuOg38epVEqBl
CoBJwFdkCXtDtUQjaUm9S8HSD3p6gURpSGCrSwdmqzrAIquQswAiBXEcZuu2quK9zUhBXm2DA4JY
p+5XO6ADcSGwCNwvtW2e7newCLg1UxTdNR0R217mJqBC4vJwDshVwFHdwVaqPcXgcYENsiRwTfmW
NEp/U0AWVLrfpi1YQy5WT9wQ25LtZ9ylFazuaXR8wVDpIVaxtyXuF7FtwQ4TqHId5hpvOEQU/qVD
xFKxRrssNBDqM8L6pZVtiKDCu4GunuCdgeIxvwonD/UqEKV8zCxMlAHc4A23zBu98y5oXECwpgUn
iJYWniVV3AfcscW/EdDzXcOQ7gQvLAeKGWFVKT4J4Yhdl2TwfELHx7iYNeINYnHbHCmlyqyy5bCN
FyzVNx217MUj1VEPqJDAC5dLqoiCdwCnnIFLS34l0UaRDeE3BkCgmMHw4hDbQ2o2jDuW1BfUR2qz
iFq+SDTsgA9vU0PiFgDb6jWByQ5VBRMuPlyPUUA0y+CIYjtZXPmULINJcT2eJ0LS7phGPR2GrXkN
PlGtVx6l3oy4o7oMVC71Up/8ypqs8+IaWWrtni+kK9iy3TkgxQRoag6gQVrKnPkgdi+fmPOaQ9q0
gG7S++Y0lSPlG4tnM/xUFIP5wsU1VOpcuFu23N5VS3sbcVoczkKb8IgeUUuw7LK4g06b5gpbLJxR
zcAQysF48tnf5l0J2se1CAUBo7PEHhdsTwQxSMCsPiaiXer+5cR3LQS0RF1E2g6l+0XUwFPE4r5X
xKkN6iSgXFF/UpTwDIfUa1Gx/wCkXDplUXH3unuUyqnCgsU5XqKK54Lce6m7ukeAq8PUgxmXNUSl
XHBdlNYXBQyUaG2DFMUHhfcrhVVUNkSW49xQDIBmhG2CnOwI6D6jsMXwQUUAgLESLCqW7l7aGwvm
VUxOi6gukvDBjWPcaPcrofiIknx0/E4AGg+e5YA623CBqDxEF/qBjUVSpgDgtm8Tjod8v7hPyFl9
TbFcp7i1emBRFLs91LBSNmThBcxLCXLyScQcsHPmJDLAW4E3A+eRLwrY5cSMbFUffEYCwtyI927u
2Alv2gM3DS5Ha76Smunu4iZPdxSpRcgsAOI4ghuUt2RiwFtfMtTziD+uRtQ/MBBR3R/cu5vEVzma
WiWGVRdj0+ZzPb5KqMhywUSzHdiHQ+7i0ezeYLT9Vi7E+blvJZ1cIehUWg1XAgYiXyNh5FLK7gmY
UUyNl8Bw/cVXuoxfy0z9xgnxeE52TtnoLCF0qnLtxIvcs6QZwffkhuwlKH8xcKbFsuNYXNrzEp2U
0fiAIAeaTXnX5VFiiwlU1U26iD8eQ1EQ22szyKFuoWKJVuRHXnG28kDl6sRqo7QPTgJfCi7NuIgP
geZ36MCn9ym7eR1E0dHW24/5eNUQlGoXcqKn1BLO7W/hAK3s5NVEZerat9yoGV6YJYnXhYxWiNWS
FIrvEvGmWc+oLwhiObD1xbYZr9CURsAcPuoll5BnNrVirad5T1C6ujtxLej6JngumlC9Qngj68b7
IM5g/MrGw7QuMNZ8kamc8EqlVPiCRB48NQAEsFAd1zBy7K8agwE661UNUUnTHcFsoloReTqJob3c
AOcpC5a7xKM6dwvNN5cCSfAsmqibio8FRLcsgFFsncu7pDxHxtehbBoZ8oghKPU5QPQmxB48pbpy
6sdysdt/mXd56JmlSxTJSCLr3AtKVUCa1ggvZZs0xG9sEajcq1KbQA3UDDLwEbhk8Q/B7lSC9Qug
sBLjlIv1fMLKtLr5goQ+YP8AoDN1VVIRWvcVwihT8F4lrM8EUy+K3CwLkFVGxHyPECETs7jGwOQV
K0WWZDeUUARFemNxRgq6lENdFUGvk9yP0R7OEGFFHTB12UVDUQwXDFiQPBhlO6yJlty+dStMnn1E
mnRhHyRgHbL6inRcfBBqpFZymDltPEG5L2E9O4QbcrxG44aZOHVtSUZ7cXFILXhsTd05SL21uTxD
X3TiMgJRUeJ4gWwoY18kd+Inxu4W6auvM9EPbIu2uoKGK77YVGx3HEEbxuArgyzcS6lts7BLYrcC
inmF7Q5riadp4WcB7o1GkQ8hUOvXpLnLEdcmUFVU15lgg7MtdXYdR5RfWoNdb1EKBHLeyntMVdCz
3ABTl7uJCm3pY0AIEoDL9wEGg5fM1BfTKjCL52YlfiCE18XCqzxENCj1bML09wy/hDrrKqIQLuy5
8z4EoJi+Y7iEMe5XVD+I9oeCBUT5hELx3CiSdjASE8w0hXgZRsr4DiBstq6yN4AvexjwuKS827Vi
EgApZHwNhtJaz9JYFXKGhVPMvhOSVATZbqHuZT0tQ7lhKumoUb7SELXiFHEHauw7lMryVEhJpxXM
ZhnJGGInUt0R4agihQ8uoqEsGEVBQHbBtHYVMuSce5kUDRhMAPJNqb+osqCn8hTknABEXEa2yeJl
23QVzASi0KqXgQNoeY8NL0IZPGTb6lNEC0cHInuTlVkoA5ieEdxdTXUXsG6SZ8ebTEcUjUDD8gg0
EGogCk8xVC6uAgKG0783BgoYK6i2FY6Ixzli6lARDmIhDs8xZ+I24EGQKEoXLHU7ehOzchXCPSMG
FPwZFHrylxCK96qDXriBCGo9eiFbKLEi9ISriKLe/TDEiX9wXUBhBRVDAaYLDuA3i9GwUeYt0e4S
6E8/mIFdGBgy8mj4iDe0eYpUynicyzfPqCryLzEkcJxAnTZ5ltRkAg8PXzKqFDYTtidphtRURVRK
M5gOK9XiC48lcUYAEuxlXBqve4YYehZQXGBB0zmdwovbmHSaztNaEbApW8+oCVKmXLrhIEREN6g5
ljUeR/MYANg41B/TescwcWLQWxNjFB39Q1veqgahsp4gqZWMUeY01V2mRdZOSj/MGlDxYX4hmqTH
EopQbKA9zUExg7+YAJUp5kOHdyIC8ma1C0SlKeOmVjrc9fE0IOByEmagbbxsFPyPjmMX4ovIxa5O
I1+Iz1Vx4jjANKHOwXgxQwcf7labJQsUhgoYZC9Ko1L/ADLbBzzcEc574IctUIhhU4CiALb+ZT4w
PiKlAILeGJzKLm6aZbzHR7iBKbqHjI6QjyDiZK1VNurlm9yDK9Rzq3Wf5jMQ+Ql0ajhyPV+BzvIn
UFEnMsR5g15vLjcViY45auoWFMf4hIKLWkeh/MTyjoV9wmqLlOTJt4gDyy/KWilB8ncrKVW35l1Q
HcAyPpuCjoPMqF7rom7VinpE6sWoRnZFq4pVZUy5cmFQBF2r4xScBVcd3A9vgKOS9uqoBgFCXHRU
t9sqc8QsFsddVCDYDkDsietQKdTA4qP7QU9c+4nBQJwdMDjaKDYqPd5UBPnUsGE4IvnGwe4ZI4gM
dUfB4lP3WCOIXeD8vE2aCiOGUiopVZAOCiFyw28jchqquABGDuLVf4uMUHw7A/7FoNc1etiUSXrB
QEVtQK7gEZ1NlXAXeC5enX5l98Vc1Of5moUCUUpgLFKHFncK8EX1OaYUlVK4SMOheSwoGzuABS31
ExfMqaaPMuIC/NwVR3eIDg4dT3QASvNeINZdGQGp6gbK5NhdqA+YgoNf0w4oxY9+YNYQ7wt8w7AV
QZ9R0too45tjSoAv0yAg+JXkuXidniZwmvlC0DUHatMoiWuj1GbSKLXMq/XT/GCIHkv+pVKEfecZ
JuvUZHCRbForgTDzEoafbFSCq4i0F/cKbv1AiKvFxUR4JanAO4vxnMdEMNbYMyOrUNakNlSb6ixg
TQ7ln0osOQtaBZXNo97TaoqIC7Yp6mMXApzsABgL7Ra6rviFso0AI4daLZxAd1mmlR2qocFwanis
fzDrKePlqB8BOQlYO2YMiNCYkNzMKbIx2a8H4l3tpZUdhHHDmX7WG8RYWC5mVNwyyl3XqVrTrOK4
hy5FkpZJAX5ToChQixFCsPBKwAtGbfiMlWcGS0ICzwuCwLMghbygqMhtRREK0NlkBJ14TfDbscNy
i7cNM4iGrpQNL+YB0rQ9SxzTiX8xolgo2pUKvAOolOL8mR0EAcG5GgBrkeESGcPhBXAKYdTPLoQg
otj3BMKqBLvxCW8VEUOvMsdMDErgNDzLju3BfEuZZ/JyylnYRWXWwS7NBQfScnheNiCghYEBpMsn
DeROuJ8CAVTt9XLywdB4h4MYVxHKlNDLuGGDV8UhtvNConKhHYLlDCzZZmSjy9wwAqtPxHW+eBtd
XCi2saDmAHlG6gaeYTn1DMDpNortpxahpZGDyqF24CvWo0MD6oiwg0CHBew8+bHmBiFP2ncHmqG3
4irZLTgQTJUu+G84hAXd749xTBMTuHLHx18zC1KhdS8gNPUPgSGjj5lSQCws1ih3gHBHyVN/dc/x
FNJxDV4qIs/3dXz+JTTRFWv/AJj+paAr5MsDQ05L4PcTKIvmq+ZTYCKrQ4GKyDYcJww23txeP+wQ
5VA8eYg3LwuVhUcM3PUp8bMYPQ5g3+y9+quOFriaxYeOIFyuo6DBDt7jTygDl7iL0XX8kBk7aPAy
rAAOZXtSwkUE03qAxtAeJV1vcVK5KileMlQi7lUHuGuYA8tVFJLOnPESqHL7/lGjSmljsNfBRO5u
DA051/yIP5QzJaqCQdzLSNC89w7dWy4xYDMhV0vUGlGB9y75wbXEtGRTh4S1Vi9+IDrba9ajs3WC
nggnkEAbPzUQwM2U9xtvw8vmPHg23HuLHV4qABejISWsDoz/ALKoRRq/mIqHKPmH8YMriEVANi19
QDIAnvxD0KkcNQZeqHnI+Gxg+ruI6Nlp8Tf+lBabzXmaWANuSAYS33YQChVW+YBdLDdvP/YWcfj0
iyTiKoCzuCku25plcYbnnZeDAW/h+JUSgwbwXBti0F+CIKS9jWpEBE1adQCKuA9QiEqCdP8A8RBb
Y1lPdQVCqAcxHK1vkrmMw+pTXsjvqHwHuEcuRzqF167JtLgMBye/CcfcQuDJGlrpsmNjr7Cuf3Dl
rQfCBwBCdDqMWXqecv6uc5KtBuxvTe9DG1WCX8EOTceUjPiD6jsDLVsDxDyXcFDauwjIbeO1Yx/1
rM+YY6FmA3FXXLZ+plFO1dKfEU3cc6iYwl53MDxUs6DI4hSCgUgC/UPoEJhr1FnlJ5YVC8GhVFUi
+yuWU7czINwerj6Ty5V0qFjsAT3rNsKO3mjAooKzhWoqgnXI4QaWkVL9VKYnk10Of1AEIBpxLLqF
ipsHi2v4iopu4kebfEGlOJxDapitDWF4QlvBK0BQ7HqNQurzXmJqyWm7u4mLX0PLAJIChzRsbxJZ
OytJiO2W9wSambKtLmtEvxjSZcUot+IsFlnfmIG7+iIju7PUBItzY4AnKBzH+8B25E5dNeMtSqBX
e/8AYQ2Ruw5IC4Nfcdar7iKn6YfC25yUog0iSvHmWtKBGizhc1Q1XEtFLhi8IxZ6yUKQdFdxV1eR
hFUD0yaSq3xDkKbL2pS8E4G/MbAuZrSy6wiKhY1+Zihdn3CRTQlMmWpc9kBRff8A7HfeZ8kSAK28
Nj5MNn1E9ou066uADIwdV5hG55Xm/EKqpwPJBzew9wZ3hfKEkFZYiRwIUGMI9Rg8sCVAFRLwltm0
xqoejSx7lHLaKS8jS/SLjFK+yUyNCWQTtrnzGOhp7RYd1fEqTpoSOc3kQyRiZDdajJVlAKQdqG2m
AQC3T7l50oglQBZ1A8E2ksJrxLcqR/qYTYXBwwnapv0vYkCU+4RGOW6+oC1bRXipW/BZTsnLPrmO
iKVkUxYvqJKeYHEahUCYF9n3EJG1LeiopMSEMBbsS3fmNaWK0dBLExttO4GVurhZL3ZxVRdBQtOy
omO1y+CYiPN8hCNdMMbG6D3KGKp7MIpCydGU9BQHSLo6FwelvBPicL4g91KZPYCX9EBD1ExYWXfi
JzaJcXHaA5jqH6xUDhjQEkGZy9wrzAsY2H3FPDSDu5w2BFPUJWuDDnsirq6qX/VVc7NLBx6QBWmF
MYZDbETT8pMyaAdVAZQgRVrtha0TaF4jk4qkXS4YVVVTBU3m6xIDhYU+W6mU8J0vmUIWiRhsq/lB
9MPRxW3uVDAzfNwReS+rhIvgPexjD+AhiMyeDIyEU2eiv+zuC+oPz4uYNxMtj35vKHCFBs6gVG9W
s5ioy4KeWZAQIrtL0CxnucHZ4bkQlM0HDXMUSilPEYZeA5KvTDfiEyml9BCli7R5YkXnfZVcI1jK
c6x6uvKjn6h5oFq8xiE2jx5hxMBnmWhm0W5UjZ55jEDQeLYGCsD4GEoRFP5lxoqPuNpcYJvosfJx
Azo1rxuy1Oy0OpWKNB4L2d4CHUC1UqtxgwU9pVyomBUYRH6AUFoYxQVUjfcF8I8HTB/eB8vDD7Qo
rw1/kP8AmCNt3BXpCeYcU035EKOo6KPtsuSsbV2811HAAAb8QlxcMCWqIHhn/JZTlL78/uIxhbpj
FHMwp2ywDbU84xiiu1cXiRdUATsi3Qpg9tkpi3v6l6+46fNy+IrchsRcKb4zaL687BwBankgMWlD
r1FQMUUt4OI4KuB6Im1UFrT3AS2qvGQ6uFoMojozucuICJL0/EqzQE8/L8xC3gPB2aK6FWun+wUq
2RHXUprOI4cpjqUZuJFZl5DtWAHRUArsAU7bIj2gHnjFlJQrR8P+yrvtZJzyml8W8fzB3E1cbKfD
Pi6RTagCbfmuNp/+ylw7X6lHAG5uqlA6CHVMHKtac65Ki0gfcjUbf/xGixUl+OoYgMoUGxI0PIdD
BYo97l8Vct+WD/cRa3pw3biLGgp4U1D2YeZbtAt48DuhCvI4rfHMCBr4cn8xxyhPmkSiVOoig39x
LzRs86e7ZRKtBxRf9w60TI95z+4OWTN9C8v5h7Ur0q3+kRsq0L8EBNXV9ROsEhKwuKpVaxYznqIH
c7lPDCCgqYdNy1gyyzncvSanMuHg2K+Yog0XZcZiaLerrZkdr4gULFvirng5nYwDkI+4S2FQeJRL
ilEUlcFjqW4zBxLPgSyNkXde2FabFcLZldr/AFHGolUnSy/Kyfio+XmW4WVktdueiWhCHQ9KhwtR
YPCW6TDzKNiriAPcA+HqGgdtlqr8KjE3QJsTymD8zZG78RR1puaClDfQ5D5tc74ge8M+JnOqP5id
aak8RmvJPcSxgR3jSZ3EgFHDgisWzRL7hAuAT3UJHdQVxcR02ou72IYaDXLBNe4zeI91BPKeZwiH
Rdt+ZZoEWiAxNVYfcTWynIcPMeIIa2cHFj1BwSo3uGvAPbY9jZwOmKGCOWGYa4QqhFS/1OtGujbz
EYdFDveSgi00eNgSNDlDRrRz1MfwbBzFgr0FLv1UbMxqKhWCAz3DsBND8xA9oFwVzEwrWe4rkRje
ITS8sOSOhSwkM6pdi33KoK3qJsYsGDGtjMF8yx1uH5CIqSxnPMLjbLb4igIoqOpugLIc2Kibj9xU
9m348QixsteZpYqu4PhlD3GShKP0hAwHLlqVO1RoHLZ/EoRC0OvUNaeeYDBpL9IXWoIEvceh6JSL
mJ3kZq20ckJHXK8phk1De4GRGtKUVFj91Qtm4Mh3nZdXQ3W+SZypbrljKx+WQ6SR8kSo6i/rCUo5
09ygHSDFV83Z2sx2C5kew1GviGjEE+jmB1EBgSFVSJQmZK88kv0YbKlraVDalxTVdriu8VW8mwK5
0VY7gxfRpRbD4lSIQN1y1E7GsTu+KgwtZbo6ZU8Ub9ttQ5FEV8kIlgCx3CXERPKWXuwIA/8AvMCz
i3OHY6okHcAEggTQdgF1uhVo2DyeIECcGt6/yDBQQoGl+Zehf3MLQmOfiKFNlRX7Ql/pW+9jQIWF
eVqONjBvxXUsyzOvTFRB5Ros+B6iOTTVEMrItrEoAPOrj5Rkdr7iCCMV5biOwUrdl7mhBwXsCCBQ
d8ihqlD2wq0C7ERISqAoHe4NECviIRAcl51/2NOYzkIQcwK8opyXQ5dy+Hypu9ljSbEoMOlCi9eI
1XmA/MrmhKbhXa27PKJ3eaIUwJ+FBL27iXcCNQBadXGV4x4LMmV5i9iNMb+BC6w4zGZ2rJ6yXR2b
srsQGx42CbOFjjKyNACXTdqHhDAr3KDdA65JcsAG0sbuKO9AORr/ALAhlfo0VLXqq16cxG4SeblQ
I7BS+ypfUBxLbUnLF3vDCqwh24gHzk5A4gJvlibGwKPmcoy76Uj1hgXDeMo5qUQXaFq+8iOQCyqU
RKtm1BaCTTqL+EUHbAFNq7j1LgtM6q+pdrdV1Y8RfBe3f/YamsrgZv6jY249ILYBLtrqpdA8a8OY
mZL4cbkRlVFvkeYk4tw6JL8wAXY8QM1o2mtcR4QTAcJU28D8MbbCq7EEFS5dhUzDQvqHwBEdNGxK
RpavOwhHQrqcKox5xipRh4G8lZbeHlFswqqcZUCtwHyP8grNWuFhNaKeh7lORI2VbkgI1PXFXcAS
rDb4Ajyj0dgQML7ztsSl+KsPdvUN4tbYjOGXU8vcb1QqV0A9+pzMFD4JamF4KXNmwrvxXZXT30Ks
b3ODTB4ChnJKFaW/M1k09Nn9ylVZfcpKuHmBXYU/cN9Eog5Y+VAnrRk2k9cywUvgR1ap3FRllt+o
qhFZL88hXhCd0W8+uZdAClt0MfhC29IHrUQ4jNBcA6/8xBDLVfzNDQIh3DZCuXz9zkCR9yudvk9Q
1ajYvlg0uMeyox+tBOthPqi16qW9yfSOmtnVxrZZEWpjFEEPkiZbXJHtdg2iADjFCkolHYPEaxPM
WjQ3zCmlXzE7QSlotV5lCVg+DINw23TF8OqOJZyVQS+YvpxTIRVfxEJxR+Nh5KdDRFeG1Kh24V6l
haqneoClWm7ggdqz72KkAFHiU4pvM3OKG+I4XrPZhkajlqKEgrTgQMQ5dMDgFalPEHDAtsDMPD25
MybUIzjGWM2owwhfJCC1v+dzYBZTeYPoWkJTUymFlXFUckKi3Ud0fimXFV4HirgKLwdTKQa0syHp
L0dh8pMa+ZVxiL1kshpePHqBKtyOBjTm6heJ3MtjaCRzBFFrGWwVfSPdBy0ROZ1Yjkgsbsi+wK5a
1L9H2lpO/wC/MVIuhZizKqQxrBB2uoiEU0EatLyP3G3Y8AFirrOJkrZRKuKZ80wiJT544iFAhnm+
LgeeAuI6jUeOGLn3b8ShVVo8ER2DJ6m6YumWWr+IgbkAYLADk5hEiabzLMAC6S/xKCLraA1zLVk0
vF7l90KfUUPo9CrglZVohosCPAb5uJN9q83v+xiOKbfuCbeRHmBYQCXeeIkG1tXaLH0tt7U16fIC
Nkb1vNPDBrYYjzLXHOrNO5wRVQwf0ZLrA18YgETVVUA100oggKeKKHxBlPA414sh8CC2XCvGzHgd
QyFbBHMtStp9P2TxmgR+ZvqQDokXHgs+UqAhVvUkkUQrmIbcVvtzEOU06KNdy9YgDmsljTFDeSZZ
yOy5ODm2YyjXMGFsmlVEZKKVrwRRwKgyhLEK4SsJbVFCvEatCaBLvYVyG/zCpYulI1zGRU0VcrYb
Le1PmYE14i4J2HJmbLOdqHHhNVdU3lPEaHBQMPMU9jgLihMGnScPALQFsvohqw/hxOAP7uImbeSc
REyr6XhHlMPSailnWD9ImIuGmsS5qGkUa7AOH3ACqLXipQcEm7nlnOKeVyrDtsui4OMlp1LHGrCF
Izy+OIBLLAt83CiJLFUe4Giu6xKg+3ZxU6lSVKDX1Bt6yjmC8OpXB3CxwCAmsTAAfcLqG5EGKjkA
RyGYSgL6j1aYHL2wr91Xy0f5KtFSmOY8h0SuJ1es+r7lhx4Va5gQ+45UQdsqzmLT1CrfEELmMqzO
KlD1CG4OYSjLm1vWC8kg2A2wYniVdKIgo1K8K5MspNKgKl/wcZVeJbHAuhHHka6QI2Fa6EOv0sqX
MbCLQkQu1ttxWoxl779RLLBs5xlCiIq0bLZD5JV/qag2g21kGINgvl5jFAW7txUE28oxjKTUVU5u
MqKKKYz9y+ABqnrqWt9yNWKyj1NksRdAbGvozG9WgygHapdWuovsjtSHQxpNZHMM8QhZdJemuqrq
c8Rbv6np4I3Ko1Ka5jw+tbH5qOlABvM4nIdCUsbAISYFMU3O18RIvvSWD1LLpWmjhxPejVt8QSsG
F9C5ToiOCxVwZ4ISq/UH1krg1sOubblKiXIp7P6qMi1Qtgq7j6yy0uoVjxBCUx6IKcrebinZ6gyg
HzANvMr2SpCzd36hbLlx1dbxUs2L5IiG1xHqx2Ow3mszHys0NRRfcf5YQrT4iumHLLIqgtW7utv6
lvGVUcI9tssuifcGtQdF2DgBqRAtfDlRgjbEhFFgpGxRRdRFSlVLC+YsTkKIS9+pp2vzE5OVkbFI
L4mmm31ELZT3bC5le4gKbPMKujalEcvzPsEsuiIAV1BQLtdRhQWWOSjrYFHMCv5i5u76Qgs5J5is
NivA/cFtkU8G43L0NErouAY/uMSocP8A7CB2kFpgAZUzpqvEQ898y8c4S8wpVAsWUOtepFOFaLcs
LBHusnCW1NDX4lubV2ZWDaoLZGVEaIKmWVb8EOxq7ZrOPxBaedj/ACOJouDkxL8EsLf3EV3VUH+R
wZB4HJVrVdXkKhK2dstiSoX082BFRQUraiOi88o9M3KUXHLaHhlEZyXU8cS6dJSHKIwzbmPXdQPB
LcDbZhS6bIQ4yi4VP8zWFZBXzFT7L2RcLwGlD6RbbNQPL3Ogg3qRXlVMeI7bpYQSlpzCrGqhm2QM
A4EeCZL/AJiA3evqK7AtP5Tb3ZZUvSsrEi81B5uYGFlOwW+HkYvs+SZoLwXUU1NW25a+r8R1oXwD
8waJBqPELk0+R/uWAr8vmAUTTekG0ersy/nZRvUaqs6PD/kDAa822S+yZ22m4UWNPMTjExvh6i9t
9jlE22/MGLb8GWYgcK6i86i2uxxahmNVDUeCna8M9Aasav8AxIIpPm/qWTwV4hZefKbS4m9IVkBg
PcYNRsV0hl93IxZst7pXY8FLFf8AJra1VXLZqTQzGOEMN/E7As5ljaOiqnQvlCHxPyzSTvk9eYwX
ESuH11OQVsW1wE8nlvEdhVnMQWqyCEWkJu0qyau6qEzaavKVKgNic3DBWAC8ShUzdvMLfFvmd7OB
V+Z2jzSCqF97DyuWUEizCkpt7Fqi9x0ORXMoAU2l31LBP42I0WhmvMKiXmyQwBbYmf3Ajj5CCoOH
iNqgOCD8RpWVdtylqqooLDpTTLGr7K5LaG3mClt8FibtHaliKoHIKiBC1eyHjHgWofELsOfuKKPd
pHRbUvhZXeCDNf8AY4EcNZ+JaCz2MoqEwBgfxksdQSeoHdWsyaipgM05ZcCOlJ5TIV3nCMOAD0KY
vol4JA5dl6S0Vp7tge71bGlD+YSj/a5cVbplBTiJdvE0WcwECrwVexWlDY1kZKonNzFLbl/bWsCn
0ZpC2o1b1DxFaoL/AHEFK9sTBn5RLy3wiJO3hcZsTycQcQtWrjFBS7FXEKdS0jJMr14g7U8BtQz5
QMI/NuK8QsNt5HeU6C7XrMKsFLqKF7Lu/wCpZ3kWH/Yy3q8Rzv5zHNezzBEqAOSEbRvqAQguhKfR
3kIujj2RIlW6rUhIOHQy1HXiBVq8AT5dAWxdo8jciASt5kLOnCF0yxXu4Qd3HJtcvyP2u3PE8sHu
EHN1p1AWyOTWOXE5WQQFdjko4G1iuDnJUw1XEyap7hz7qKwlmxUId9yg87KVosn/AKEFz47puyja
/iYFGYlgHC75hs7+O5RvXyXCFg9BzFQ5q1GxRWVVMWKpb4Sgu0aXVxJYU4yL6ULuoqRV4Kj2idBz
GYq+JQos5qXwKMzmYEDo5ipHWwYKqNzqBKnFbcwUW9xD4mhGxsgUc+IkHPxKAqqYSuL3klQAaia4
Jha4lrFfibgOcRVyCxCOTBqFGquzkSnSNyAnKpeHz6l2LcETpBysfsodTbCvaZBBC5ZA43T4g61t
rNlzAXbOo5FAcxZ2GqgVi3myIxYHIjhMRr5lkSmiLoKrKhY/tB99KDzDg5IuvH+Z4sPcT3FFGTDw
JTsowPFsNq9uooZF8RIA/EeMlFEF1QtwyNHPCo4b1TkoSHCnMrmVpKxi1NrxzAuwdEcm31WGAjn8
GM2U1VTZ8O8hixR14lNcMsAh5rYr5L1XmKyLbfUQTZqi6i3+7hUKlZNi2NbFRt5goWcdkpTyrBYD
s1GIFi6Jdj8qRfbOuvcJNtE6imKgZqNVB9DYogHuVIXwiFxahkJtcVqBixvHPuUZc24S1EqfUIHa
XuZKa5qwjpOQnUthKBN4vYwXjl2SlmNDuGRogK2XxaAU4PiedQjmApZVWswCZYo1OeEWlwe4bMj4
m7bLSbOItx5nOhoU4gpbciPfIXA2qsrMwOWmANAEK7jD2WU5iVBbhhdbmOovBS3RGaW2AQ4R1PxB
3whbrZ8RgU18TMwssyWm+c8d17jZ6uXmL3oaeEXQ5p4j2g5BUuhJw79ywGsdC/MPlrmNbG+wVaM+
IPW3ipzBSVtW7DZUE9wqKIMlaYNBhy0OhtEFlBAcuozUI0LqOwFRVc+pQaJ5I2lTLJaaymmrzGcA
bBrHoCqfUII567x36GUVHeebHBCzcBSRhScdEDsqUNAUH3CeYXt0wfbeYUSggF4t+MlzBfjzBbUC
6uFBNJ57jwt+JZeCPHEFxUueZhQEoM5le8GxQEc6zpOHn4lrQTnufUWgAw7uXIDzYWMLQlCgr3Hr
UVT3GzlEKlaoF8X8xt8QwrYVi4pkw4TTs/zLSbKcrl/ymzKj2BbcrzuPptxooykdQlIxiKVkuovB
RME3JSWGfhXdmadRDmbwiqOHEJQGX4/cN1mrFfEEq2uiEW9LRgqCSpdNc/EFw6GXCQOFxC5fHmXl
7bAVEUaKBV+mVZgMFXfmH+gte4AewOEKZnWvPSKBuUUm1sZdQSluxi0tVU/MRMOhXSD1Lqo0+Lv/
AJPCk6FSip9ektFoId7AnOgQlyoI5L3FKS5f3fmYWgSGhAwyMH6QFfItckHWLqz/AN4hspwRBcU0
DBqwiNfMHrciSx1nP38y+YMXVusiO/NVSRsgXlZn+xdAgFixCohoj7EcJQt/UImLbmYh9BlrbTci
+EA1XDChVUpVsMTck2ms/mVJSLOl7jigFGWd/wASgzUKu2O71hDPj9xF4Mo5B1i34HxLgt8ABsWC
30U1ArpZHmoa2dQwNx/ZEnuG64vqW7gC+YINIr4j6KQsULxFtJMfcMwSwipLlbESV242W9C+IMX4
MairruGAL8QVnJGuk4Atfx/+QLLo3c2B+CVqlvUvQAeSARDmmWo+R8VNFInnBlil8N6hXK4kPUG6
FgqVgjea6qPkqlGq+4VNJZTrzEbWpqgqvMH9oZwXEa3gU4yUcxgziXYhpw9StkVYvuGoZuMIwxR4
JRmqWDpw4iBti0eERCn2hZ2czcnKFo6mEXf8QddJQNkFVXMVdAOURCRRZDcixUDxzCIjwsyxMFlG
waLfjwj89cnmVei6jxBoLXtPc6OxjiB5lNNErcgJ0VcWJJZw4h9EIGqdwtLi05MMna1ZhsxRwsz7
i5jRWpDcObjuAQcllSqjVPJYwAVKOFwUrK08snCApfcIzYso8kACBQXBTDXBjkyZF0ErbdLxxM6K
nVQjlBuEBgp8ji5TvSNpPAYMVsdSAg1alnHxAtoTSFijimwWAKAZjBcB1eU5lzQfxLeAUNRb3NWj
mDalG+FgIwNgbOoIFXnuMrgOziFHgrDuCtgVK57qAqYYDiVhfbh/UCTbZhxEPM+8EYGB4Ew02UYw
F6bGCKOYJq4ZQIhRp8zlG5DmoteWhcvhl3U2MjkwIp+EMuir8xNUsteoYlSUV3cANCET1BcG2h+4
17SxruE0lp8s2cDRbLphBFTrlCwc6a4gph4PxGICyuayUjiWK5B4iAoGicV3GFW64ryRVWODXDAr
WoHKWHFWQlfO0xRxuqQIAHzEUgFrJw+GK3ktpCF12j4cwr3RocSEVaW+yamgkRbjfN08/UJwNDXz
BMVpwQyaCiGcrw/Ax7QLVI1G5eLlChHD4Rqkt35lR+XYDk/9UryApto1+obDuAFFgNobVXu2MVUT
1fUu0Xcq4a5hT7R1K9geGXOypEy+YOoKB6ajX0rWNTDIirp9QFgFtaoqXYS7LdytUPiJxQGNjn0m
GvVvnmOshv0QLW1gWEtiB9p5geurSGuS5zUGW3LQbcjdMOxtyxxkcVhezaUQSPY8ylkjgMNlKdDY
NtlWa2g50QlVl+yBGRMgqqlyhFJWK8E0UNMriogHTDCyAxLbctzcp6C4dLWsvV4AcFgQl8Kb+ZTq
rFqB8REoiPkEG2CFLxL+CqCOYQUUm+At4gSP1J/2CmdxNVwWVF1TmubvmXrrOO7r+o4ssidEAVvu
zn3+4YAcAc53MwCM2oBApzX1KzVsg4i6q1vJ3Fml2EtuDs5h8mxTXQ/uDcEBsGRbqFJ2BGBWzh+J
aIOh3OWHUD1AIOOYCxBnGNdQs4Z43pFNU++dlqbKVObyBbS2K7Uf5BhDNst64lhAkCtce4KRVhzG
OeG8nYPM5z8Q7yBXCti2qg/wYFlkJRQXdV4ikAVKNc7lRFAleLjQRcHtuC3rIvaUuMiBy1Egciug
HZqf2t93MSgD83Ehdb0j5rVXkMmsElWrcfBDBuXxGkUWl49TMpwj3NzEK7YaSQFwF9wgru7G6uUn
gcdayliS0cU9TE94FNWSg2pYaLlHbi6HQT9RTo3NoKdRWpbpenJj7yOUuv6nFQINdCDUu0OWzmEj
YAHglIPgx6mENuoyIMDg52FNAHiX4i0MR6DXM4AyGbx1M+cV/CESbZlP/MJlez3QQpC1oOGkTqeZ
RfCPq36XdJVJKlDh7/MD72auLL/qHVQ+q1/kSCPtEMuVfIhU7NhkUDc+5QTeVfkjSq8Cq3X5lv3b
IUFPUvbppTZNJvUICKb5lbZTEbvxDPg8wC1y4YbBk90ZJVI4+YVY0RqFC+OY0KexsPAMVvTKGBVp
33L53x7vuKD1W+2Z+nBe6l31tuo9CAweZv1u/K47qaAr1UBFoYDpJLSXjYiI0G7gV221zDUbq9x0
4V18QEv8IuVezF09QWrka/cXVY+J6kggpjg00lXinqURou+4hcV8RoUgb2qBLhqXtEv1DCFSpGj+
EvriNK6yKCWv3BQGip4goUG3Z5lx9LHr3G4DKsTWahL3A9Oyb6UjsojbX1CEqeAassEQ0ekBCCo5
A3gOSjvqVlGIjFTbqMy8M8xRaZPhEGLyF45jUdDXrY9QBDT4yIvu/e99QSdvX0lUfRPcPOstqarF
0mMLcFV3LJmoEPiXSII57iAU6LczSXEfEEAN2r6uEInyGcQ9ilLkdOFvHMJ0WXRZfTS99+IYDSgQ
4WGc2pj3Glhe4apIG/GSmCuj1MGLyK6is7sj1LENrDiEL4LqEqAp+kSm1orIKXDeZgGrfUBQaSTl
yLN/mGLpovgqCKgWrOpKYYU6rICVBVTgOVfqB6hvX8wK1TC/Uu4APvuV3PRqMeTC+OYXaWgqEGhO
SPiFGGoGWHFwRW6NQwALKSXqgsrrZYqWhGHMK1cKqw162XbiyPNwxAVaDu6mL0j/ANQamHX9I26f
qh1hd0+nEoWUafceOYC9QgtaD8QfA2pZDmbR9JnmjSNSBYj8QfQcIamFKn1LOODZbQArXEMLsAHW
1LCpAx7gdVfnolFxSsGm4eESqWgp8kXBez2f7gzyLt+ZSspc/bLxVC/i26izl+H3k5kED42bJWvn
YxAqEOeYGsA+1FxS9LaPZsHiUxAXohgCn2EruVby9y2MoJZ9QGqSg7REcnj1Ec8k7PwmYWMCQaWe
blFjKiOIadefcMqUKfK5ksAH6RNBdM83LOo4Hs8Q26toKu6igCtX8o+oW9csNipRp3GB5U2JFKON
49R+BFHW8ExlBtNlosXKIVGm12R28hsu92Fgqin4jYXUHYsOMUaHxA0k6tV8xyKqgA+ZZKgVVSEs
FRXwiRqFIfEKDVlb2rlhV1b6GzMzo1/sz4ss8X3B81VR8sFqIDaeeYi9UC18pK6uQ8lIibiiLb8o
CicNfD1NCW1z1AYKWoiHRF8ZdCQu3Jferfsv+oC9hSdf7OcZ68lcxDWvQPAy7I12U34i8kvUFAks
IQwRCvzHMbzv5YBF5x9EtQZZeR1MlAi/GbEeiw5dfEOMUccmy26euY2rGaqLsr8TFNXT9RwBUacs
4ysj9yy8LT6MsUaKXkuBfs8nFzDN4V8Iaium9NOYHGIeN5gLza5Hy1KDUEr57gA7iwDudoA+rJ1l
2KImxF8G8xgq2vdqANp06g2geaNl0DoIpd0h8oLIUgN/L/ssqAF43fuaqWyujIBwxr9wJln2Iobj
flvP6gtlnfuaCKfy2w0NbBQ/yCp3F+eJV/gHM5I1wLWpnSNnZfW/+xHjuoQI0j5I3H3gbipVlQr4
iCdt8CrM1aqi34l7pYh/EqELtu+kbz3fqrICALIY/wDrjDBwA+OIy16Lu2beI18IuQcjBRiT/kB3
sB5PmJBQJObuDgLeHBUW6WPRVJU1ILrsqzCCOU/7NAmyu1ieV4PEdOLqOGheESceoLlb8xGatnxg
aFt2FKgaGsV29DUYK3qUrVWtJcYgIKj+Iw/XB1sHrUNJcFYQBydRsRtjbg61Af7G+JsETfqFSDV6
KjSE5DsiKqMB8SiPTu3uX0eQ3yRAtBQeyCBZhXhgNYg39czYI60lPYPEIW7UrDWojwu5Qa4eKgK5
alBNW+JoKvqyEY5XhmreYF6DEnW9SyvZrmMoIjYjtKRT9zVZLvEOmALvMS0uyr8wU5WQ1dr0SlhG
Voeg9DZjMuRe+K18z5OAzsrQ0fkik7lfhj8KVXUxxrLlkKApCbyahXM2PbEriL4Q2qKKEP3UUTVU
BGLWrs8ZDBdpagkCjABhqNjiwqlK/wCwAsBdnxKkFbV8Ru2AhthRaHxBpqbR3sDuoojQyxCQGm7w
RY3Hs6jq4LPccCjkQg2itfcIsgv3DBCo06IBDLiu1xcgLbKJWGXxGIKt8IvaVysNecLYKfgxcRnA
6uK2xXP1EdsZNG2mBx4l76Fq/Fcy1lek9wz87kqB23mIiAC/UTGpWz4iJe3AZVyttOvqPEKDp1ND
lRBxLugwX3GDFFH1sZ2to5FJQx67KGYGLtyxVJe9kIm3o5NgpVyxjSAQC4TJ/wBJ5xfgYvmiVcem
VUdNRYSrrptbLuFpqJximJ5riI+L0Mm0BzHXFw6DkPsmvF0V4ib6zyHqGEXkfErcWpr1EooZ4HTB
Sg0D3BR2raiSYoDlfMO3sh/cCQ/LuEUj0PXMFInB5ldU1PdsaMSDXSEJpW1wUMvY7jfTHwGhWmIR
r0BVPFTdW/syhC1X8ztIwXkP+QhxrBW8xI031PiIQOBS3d9SvWHRbdqUdCw8jXM0E+jgruDZKACV
HKgCte2CiM18kfY9QFaasg9xNjXGwLrqIBugnkYZWC6TzUvGRgnzNBrdveTxYqB1fM1K2NB0Y8cR
2xdo5q+IxqtrU5+rb8GDvtK7EgIbIg+Li47sh7gwhai8vWSgECBR4vuUJGdn3sTFSAHMGbfRRLI2
Ni1giuVuh6qVmWl4cx1cOzxe4TCKCmS/MYsiHxcsFUiuW4bthSvyhPINtNZn6m5+rYgAAR8uychB
F9EtazQcO8sQDYouxjQgCPyrmKnCoeCFm8z1RsPaHTyQZUFYhogBqdpEoMqvxcrxFw3/AN5gN+FK
zQIghJ7NRhARnd5LvWoJV5LzsZuE2ghf22LiAaOjuPdQQ8tynMlHWEL2Kpecz9Q+bNijpRBj4KbV
cwGFtB6uOg4e4ubmF0TduAqWOEQ9JefyBqkt8kt+BiK0JF8wqwR5j3ELbadGLyqreUeJbAu4tB3C
hlfgksQjLi7clKDq7d8fmHfVq2HMzfxT62KANTyL4h6rma58PqMtJVTq4PfKHPMvzQSDkxdESArL
6qGqTF9awFLYGXsA8FEuO/qUMEByGh/TDdC1HGpd3cB5vmpgG73sxqLIR2r3DsflDf8AsalJfnbs
EMlc8cf5KrC0udkurkMNWEBHEV9YZ+oUlfHAkChPcnJYXUh/45IyGk08kLM0lykn9xry1LCzzC1D
D4KP8lPRcQTN/U6WANjxXHiUMlwF8F/xEmmRc1/8iXTQ4BvwQVIhYqAur/ZPqXsA3/MdmJRdLAuq
1nyP9jhUKujP6jqALW9u+P4mfpVboSF/ZdfqivzKB0muBE8hV6xHCjzKVS8EK2ITySy3YHqfSDma
Ky/M4Vu2GwdOjK3OvAgQ4hHWCBbfwFxVSC/h3GXLW178EMIWR9q4IM1W/QtXD6h53FGWAT7uMtIC
urqFkfazNlTQ3sGIDMdOS0LAVeTHGI3xk5AKnxcKJLQeIWOhY5JYECvWb2FfEVY1fUMLV/MugdGX
ErBKzioI7jiIEFjalNUwPMDYZ3c+18xzpKjjytCjOHqtt49xMkNjzDIcMeyZLIF+JQoFYrsU287L
mYDFwq+5jRhuzmV/9FclU1arwiTGlt0sJXtbFV/bBACjbfY5sOBbDuUALHo1Dgdx8Hx1cJcA6vqX
Mlj2gQJ0RvEvsd7YpG2zOIChpwpZcxG+S4sCiIBRZFg6j0lxQuF4LgVpBS/3BE+S42HC01jkJslG
+iXTd7s4J5HkO8iHsdXmLox2MblDokqE86O9hs0AE8wwJ0nFY2BZoErldCL1OVrHyeok4aJdZ4m1
Cw7Ni6HK3ahPWPHEYfJsR5lZ5Q2iB4dVK2GsB4huLg+XULO8Wh8jABIYp4jVUnWNUsXiDMMlTuFS
30aFVZDVlXVhAQAZTksKdB7PME6oEsIwLoKBmRASw2eS9gC6AVBgMtsS5VtABwg4+OFn3gLqomA0
VQzK7SeoKuA3RAYQx1BE7N9S6GIody7ReFb3O5yBjfuKFy1rHwKbB1AKCl6lHiwF7gASLg8/MUuH
FLdfEea0oBIICXLExUbRu9ysCiwp4igtIFcqKkC7hAL3XAzk+OL4b5hkCsBi7gKWE+JcCsKt6uZk
y3kjWdmkVTNNUZnzVCvviDWBivH5gQBMLHNfxKBaAi47zHBrqW9VsADUA9Td+UU9Q8LS7dIKHlIq
2EEuD6e5QXZV8MS2o5Pc5cIui1BwaVrwxBU9VC2Op1VrqZA1XpcPaG/AoFIbodkIsAilUc8S5odA
pyIuG5KNh5TM8BcWNWgO1SpEBUrr8R8wW79x+BVN6sC3WW5VxnErKGqupZOUJ4b4lYjjlJbHuY03
6hZQCb9yt9RMzktru1WK5Lg5uhv28wzhUdSdSsV/KlnzsXm7aSV9dy3gABM21N4cxHZml45/2OAX
VO2PmaRYk5ZKhqz4giYmlNwrhsB6lzKKv96R6jRRRz3BrvCftOztwLv3GQwCPiNV6oUyumAAAFfu
GIRC5yJ3TQfcSuQep5j5JULV8RFQJpW+oP8AGiuA8sRW5qv4RGxpgDPUWoXlFj0hDiRdI+Eq3Ila
+SW2ONmEwCOrq3MSCCjZ+ryKXOwUwYaABab5jR3JVdsayayqiQDFiUAaH9PMp1BXkhlF4rU89ypa
w8HfMefRfT+4yqzRb2cTNzK4PPFBCVka9yyvcb4LOsJ7A7cw+RsC2vqWoKUcsvka+OW5lD2VFVRq
pveu7i8BUeQdQXGnRH5jIErXhLYsoPuJ6lLY1WMNZAgXyK/7AFV1re3K2jRWP1GleDW0lj7Wn1Ks
zWL+EcgY5OIf7DqmILxF9np7jQ++Ajog2WIdgxN0rsTT3F97BRru5VESm22Nv4l/X/KpgC3MEHio
0ElwiwazbIqXguY7o4+o7S+7XT1DaSRSlXBEgvdOozXNeDe7nZBqDQn8TZOWX1AClkQ/cmhAOv4l
KS1atgjXbAOPgyw47lsPxBhNiPZzxEC1aD/E53mZuPzA0FLzOQiiWFP48wGpnpnwIWqeX3Ldd6Iz
0p/mLTs3dyyAxqY7R7ldXvoryznAoJtxhHYSvCRsIlgOVGHqwLaO54h1GxglkTEv+R7auXaHSuXa
3LUMAeE1zD98w9QW4XWw0m6GnqCNZDtWLLvLLpeppSyXhodoWA4lKWUvcvYsamlCKDanIYeIChxU
VNhR5i3tSMGHgZzAzzKF35GEHRwHonECFFNe9i1LN6uo9mjxc7cP3a/MD5YEAD9MOIcQtnzH5Bo0
qv3Gz12vEdN4B3DGQWAqcixlpa9vnmNUB4bjcC3RBGicquWMuqQTU1BF945Fi1ynzEKAhXkwGQvQ
yjDXMK0RVH+Jzk5txCK2uLiOKm66S1WxWCWQC0uInK8NXBl1NJboltAd5yWSlbYypTKVygglOrRA
m29gC5VfqWIPgSvuL3ebbGw8FNRxzwclQxuukVjfOyFggO95CQUCqWIUpYZuByXNRgVaLl64s0ua
Fmz1C97rc/NzRuPlksbj4lUxq13koJ2SVxGsGpeWgWH9ROdvV8Qu8tfMQgPngj0oH5RXW3BzzLwy
6MzgPxOdM6uop9SwS5VVexYgehuWAWi7sihqgLyKglDXIrkvRHu4eWq9vjA7nu+HuJ9ppYQc8KY2
Viu1GLacZyhioq2dR8ZNRsDtSXSittfniAXB6YgFsIXiJz7VfEDW44kXrvQfmUavZsYZbWIlMcmq
mT0p1sjUbqi1ORTiXXyvwR7rdLC6YHkhkKFg+IyIscHIvHm+4kp5rhSUx554Ddf/AIYXEjSLkHuk
1x93LNQaG9hJgU08xp01XoqDLWlPuHHXUsN5cwBMqcBRGTmVarIZ6O8WR6hONwQzzVAWpCL2l7sF
bFsyLOkPMqL5cQUgzWSgqNqdy5CRCFCMMFfEH8OteIFcBu7lam4L6Ifsp1EVudm3Eua2xYfUVLVv
dFR+muaKIg4mlNIy8p+qydmjEsQBzBoFh3UW4xVghKp5bmFmhvKRmarzwYF0TttkunVY+zQdBahy
vgRGSFW9SzQ57Ox0amlvEv6VTrmKAZgJTwDoRJ7eINLfUUaW+dUbtW6VUWBF8VfMRa9xRcuBeG6W
raOL5jEo+oeY+qcIXMeGnEVEL0XFtUu12LegLP5jRgPlOIcPiNztY3AJYb/EMvuyKLBTkKVE3W/E
vjzBFqdwnqXQIdQEotviOrvmIYwXwQeAS/Sv3K4nxNiSg+k9agkOF/TcSZO2buJpD7OYi+ujgiZs
/DsKUOjZRcVtb45hY8t9ouCFzevUT2fYRC1amMoHeY0+YgsPogwu7pj9xBK/qxgNdO7Dau9YwNap
xyjeh1exlvTiYI+Yq3T29wn6iO/+yGGgtC7PMv670wAIIV9ZKukelmJByht+IdmGVVud1JdYuFOI
oVvrmdXHiI8H9Q0JatLYy4XiIER/iBsOBf7mOoPMx+0CZVMbWu3+JdFvfUADsl/ERaI9Ii1Q7qwV
dZzF+Z+pf0q0JmrIkehUXcJGmhW2sHirgOQ7naESmDlcnOCOcV0e5eDXeB/MasfbrFGp0QiBVdOC
HFi3JlyOagGtWoIoDe6LcZKR46HrxBvsCyLR6iTjrxc2BrNqtkK+19RXWRrzKmCZewYlgu3oh2VX
gZlIZ1s1DVr7hJKPV+YVYXW9f1AZYeIdCK/+2K3o2638y3E0xSKPfEPodlHcbmU/iMdxcAbMqgE8
Uu6irhyZvacQd0WFtSq8VwcwQrlQ9whUC8ZYW+/aLjBxHp3nSMC4dpeDZU1RFfUw/tKdhuwUr7m7
SUktNAuxUQKFFUhPFLXI3c7UTq+DPzA9U4A4jo0dRv8AFtayHqr2K4naWQRoKWkcmivKDkUbSb7k
OQUs4lIF7HKWMl4UQtlPbNaux89RIUhUvbcqcxvSDkX7lqlGBOTIiypVB4jRgATucRhg5nSgITRT
sJaXinuA09gtqtqupSFK8r/9sCdA78x3C/VM0/fCfFR6vHmeOloJZITEQ+cHDwjPaPylB8aU6hQi
YFtyrBva/wCQgnwAgM3LSrJYjBdpc0oDwFXEUB+6P9AFXa/iAyg3kbMLLa6gkGsdsjFkxgo5l3xK
CcvUbmYaCGwhVlHSVUFolaTDTxMnxalqoPEUrkG5GOKBSmx8RGgGEAtkaxusSMQPKql6iBeB9xgg
elwwD1gHU53I8LUbFjxZwRBjdW/cCq89Bb1Tzpy7oh+w6N16gMdoI57hIaugyzliyA7dQAbN5LT5
tuXqBkNUwS7muDjmCMJp2e4F8rT5IZJC7Nw7Yq8iu5zAuoVSniMLmKBweGVukOBVZFGFD5hJPZXG
Jxgm2guoojwUrCWsKBSckwI1c4hWtuVteoRzvVeITNDlxfzEf42i5xV4cATc+BELllEssn0ms5FG
SPOAtFuJw3g3VMZKLIFKQG3uPEHXW+agGUPQZZedxAFRee+Ie2lRBzUJLrfJ4hRsDQpr5jYC9hE6
q4ndXoWPqMEVRfygtGAotlDAPal0F1A+IlZ7b0PEKLZyPECGdpzsO1HZGM93ydfnYxlaDwfMsuEj
M7g+o+42KE4aYz8t8SoaPMoVlYt1hYqS6FXf/wBlkOi0IT0AwIyrKs0OfUcgQces/wBnCZihvqb2
pqLFrqYwryJdrwfuITZcQtV3DK1ZeeZUuD2cwmLGheTxfmMphev5i9l0128/iAP0gC04Y95WF2Qq
oAr3LQwUIwZZ2XQrfiL1brHuIbNCRYqAcpfh8Q0HUpcdwVwaoaa+CWM/WC0sEKD4F9bDjgp4qrmD
vFFM88xWNKqHthgY2Pn6lGyKovZzc3BgvDOsog5pgS4PT/3UOxXBxrZf8OB4Xn9xipQQhfdRyI6Q
AP5gYLkraBp/U59tJ3sfkQfZAk1ng3y/zBmN3NYufzHh4rrmCt9tXGcUOxrlX9yyqksNQjiVbAwt
+ajV7DmKnub1alVA18rhTRl6tjjol9lAfZ6mf2N3YhWMY8MohLaS1cuJu6/iawDH9Ep9Qvwj/wDJ
UAsihUWjt1nlUqebAzk0SwQGwukc9yxE+LYYH2ZQcN4iVwU9nufBCBQ7bAE0AeSFBgdvsmFXXx3E
Ojb4JYc1WXR7hBEaQU8bG2vqE43KgzdFg8VeSjuavhCgocnPzOg1K0jmQYG2kosq2BTDIanc7jAs
cleYnWuA42Y4G1X1BbdPXRDMUQZcqwpkbnJaQj5vxAFK437mSefE+YWiUN2+Y0CBXuVWHzBwq1Yk
4IU8xj8KzJiZx47gTceoUBx4j8LKqLD3BiwQHEKgS7L3AEAIo4q5e7IsSAAAa8D3GmnpAG2Xb0TS
RAfL5iBCsh1COpoEvuI12qIVkBKZS0UdSukfsFTnMxiSqeJsUKg8ojzHbmV1JpDH3H0OrNgIr2JP
G262JUEZDhCCejMP3KxRHHMZkVVr1KETUK5WD8pUByQp0Nvi9GOxPB9R7bFnwni3AUqXYC2HEOgo
r+N5mZg1a5gbaFFHgmjTfIwRgBqupvERzViif3LtYObNl3DQaaWWSJCLQaMFqQr48QP/AHmGVOKh
/wAl8+bXMMBdmnUci9HCn7Rnprat+YSxdK4yM5WDR5FleACgDmMcIVQcS5JN2VAVqmEJWz3KB6ha
Yh30uUGKAs7YiQHRjPExPQ5ih1bwbAKqKombVbNe+INSRWIbbSw8wS1ToOHu4MIEtHLN3NoF/Mrn
TRnUI0NxqEaA3qFXXVSp7TyL9xtAnYnJDwQqocwTpbZ07ByLFIdQqmwd5sLWcvodbKu0soI9SocO
RC7SrsaVGWOEIR74KgcsB7zHpyXxbxVbBph8EO07h697BvKlkAXYZ/iVeWUh1DrBN2LikhoFU8RK
krtHXiDfBKArg5llABXiDAXM8+YeH5WuYLph4R3FhQL05gxa3c4V5/EyglfRL0ilss/+RS8Upo+G
PULSvKnhDlDx7QcEeFhAcw5hCk66GQvLuo8KldN+cgBnbsuP0w3VZKQDnxD1ELaPcIRq3WUUf7Cy
qGyndQlXRENyXVgG03iJWBwtA+4o5ccOpuEF2p1U9VnrLgiESHNPMQDaI4GPnWRA7g2QvB9DuGYa
xL70KLYwIpXh2i4NBeW9xiVwNta+ZzqGV1Cut4aPf5jxWqWBsWNzBPMdoDZrc1rnPKtmITLpeohA
KQGcQAEcA56RSjjJzUCuQ+76qMrn0rlmNeFchvI0ZvG/RCSiUF8uspELl5zexwTBwFRM+WD1DehE
fNfEt8yLaNQi6YSmkDaWIt1HoFW7KznnBtl3DXf1DyKqqTdPoA+5QNA+lwe4BpxwS/jqAiviP9UP
tGKaU3m40yxo82QXQ3UuvGTbuwLxkvsQFeXdjBbz5iItw7EuPlwK9QhqQocIS0g2+QF809wmEoLj
S44jaE88x64ZSlnn5jgNii7PNxhqAo/MzgkTxfEZXLparxAmzsOruIpbcvDv+QfWqWh9ozwWrH0w
WKGil2vqOLoJ7t/7H8ErGtyDpYTajK+JVVFWKjvP5lJ7Rv54/UyEFira3E/K9Dq5eG1++JdqQDwY
r6pm7X/ZQ5VF1r+dlhDKcUgSy8b18I/Ie/J+YriNIW8gfuOyAu2vCPSaifRLt6h1EL4/UswBFVd0
GfqIF1jDf3OqpgBLYHUC3wFbgAXNH77jAIKG1xf1Eq2ijsl2m0S6mExYgD+ZUFvUW8Nmv0FDRbzH
oKL7diKZecFt/wBwvC0Dwe0Lcuh4PcoTygAv6g9LsHxHuOUeLgN4Uk2G7m8TxVBQmsgFl7Rf8w6Z
S7LGCDTXMwdr6hooKJeCh6FSj1BA4L1APNHRALNJ7uBy3YSqfjY2Ati+r4ljQKhPFTdjJ7QfYULP
fEa9j2mxpAZa9RmadHxkIcpyfEpSpvOZflGlL52FnUinqIQPpAhw0BA0DWp5nPxUL8y0Cm5wEfja
6ljtUVEOV97NqfKNvKguzvqcAmS6xoR8GxDb5rKg0pBIjSoWxUATj0jhDa7PiWO/p8SiIq6wgqiy
/exm6ogt6jD5SxwnMP8A9ODKyWlV81L+q7A8J3GBE79cR10ehzLh4KWPG6ZYhuXvxxFSGltUupSK
lDCrj+SHj+IzbgdE+IMBCxguCHanyr1Cijb8zzFDHDmErSN6LfcYGWrOKMqGVQUHEIIaGwYUdccs
XMWgxyVapUQoYD8RhhSq+oJtowjBRvGnx5lAQsly8jaDsiHXl+oKIAm3m5UaD8fEcyaq1OSgUCqg
vMCsWVPjztSrMSqw7UX9vEA4qVAphcrGFuF01UaKeQv9Q2R4CbCB4XL1kVS6Cu9lfAAB4a5jGaci
n5mPpMsYdly694x1na4vuVAEQ9HzACER00plRFA/cF2sofuFqSXV56lRmRC+ogWl8JqFEiqgcU55
nZgaHdykQ3h8Tc6dtT48S1ujRfiD45MgC9t0X3HoA3C8uMtwW5QGXeL7AuU7vZzIUD6ggcZojMs8
e0aoOAwQoqvxDPuPz4jlarPC4HNHL3zBE4UQ8QDRonaCiuXj3AGmUZ6jXZFDj3EMyBrq4h2lRX8y
8wGm8Qll8zAWCvCifuGstLg8aBUB8sjYW+xh+4J1C98Q6LAZ1s3SaHzsouugMGFINJQsKOoyUpyO
WPSilXcoRWMt2JVX8zWFLCfxDJpFoZAwHqv5itXEVJdc9w1AVUqT2Ci1QImjgvZkJVifIuE9A83l
lfD7Dquo3rGA9wl2gT1Boq0HxFNUxO0sbMqB4blhJbCqyGaDFb6JYOx5GoNBRaG2QIZZ4mN8GivJ
UwANEO7RKoW3mpuUxbHIVd3wPUApcoPUNJFIKPcJiE0MjOwqikbnqA1NGOans3uBxRDyHmZaXIfH
MP2JijK87E9gHpvf3DV2i3RzBwBTTxBQVG3i7jvfNPrJYEro5ERqa08FRq0FoHq7illF4dR1Aym8
A375lOID/YNgMNbekYDlqVCUTWXSukJxNUbdy4ILV1tEDqgw6tENdgD/ADONARH5lRHBDqOilGw8
ty/BatcXZBpTQ1Sj1ksdKBVUd38zYZYXBQ00cl1AEC8BCFJAnlZShRa6S1OGreGW0QFvrTYb0JAO
IxnpAS5mwbIxFrvcOQE7qrj1CIk9a4tnL1QfDkfEGeqGUCOAdp3BsCJOsUvAyBZ2/wCROGKnYl26
qgwDz+4tLL9UhDbyDfcNxND5XIAyOnpwwUlcVu3gIHmjHuJglcr3QxcGah4C/wCSsBVoc5dRAaKW
nSyYsiN8uIvuo+CkZ6qxir2Fg6gd33OZ9RrslZLWhnLYIEXec5HrIITk4x9yzaIj9ITesg3dv9EI
LgL9j/yWgdrgs5An2QUGlzASYWcDf+Q2qCJ1uABRL2/9cMHgL9s1oaA8rZ/ke81mm0CBubMCDrIH
ZUZMWXOXTGNpNvtYEQDzzYwgxtB1qJYLvXGi/wCIwChTzbzAhf1MrcsuMae4jKqBU6IkV6PzGt0v
buKLeZasPSwhUHywLSoefiBjIs/VkS6h8uI4pw0vuU8Tz8epRqp3DyljvUHyry3iCdoLUaUKvloT
QCN1xscRTB4qdz4K4q6lSLSwxvXKt/cpc0rWZdON8+oiAXAfOxtlWcMaohFWAXiopbLPRFqTK2OH
mUDZnUetfIggUudb25wDHAEWx5OR9mwaF4h5s2WpPMe6lF2giUmwB8tjkxGgttPn2w2d83uCio5V
8xHbQc8wtQnLYX6VyvMsj5Ex1RfSNr6sfEWcLaL+Zj3ynAZUlNFdRK2Q1Rwiqhq4CdZU7bFcJXbp
qXLconzPQcAbvzFXkK47ds2AICNlsOWEij3K7F+fOzrI2dnuXQXG5s09XAIjs31GaDLE2QXpYzFE
v9xXIbE8vUvCyF5DIBypWMOggVy4gSKnZqobb1lXm5UVQEPNwkbBQp4gSSrKuAnf5opBW7gXYPtE
Dk5eiA7dx6dlRITcGChss7top2XDbI5RC2UtwzVe4A3UUYyO9V3qM/dQ+IEiChOUljoaG/kjlGy2
XLib7+I/dO0qAegLq5QRMuu6qIG1jWu445QL6l2ZQ9+pRrVBt5g8rQIB4bsjbWFm+PUWWbi7Kh3W
zRZUeAtxaga088RBsU2fUtdAceIJFXV3Dw2EBvUhXhjryGv6QIENcNvxFCKBzw3L5sjjuOlbROCz
LiIePTEMKLc/qISX4DuOlmoHhFYDAPKNzJKbbczDoAOWHw2c+5c8x0/A5+oqrBJmAy6wBCwiqthX
i9lEjodrlf6io43uGpQYrvYV1ooHcV0A9nPc5aCDqziFOopB5YHRk8KrxNfCCBdEcAu6/mVgGUHN
B3H2gApdvcPg5KysDQ5gVByoh0c9ylgbIHdxTjlUOLjV7BCx6xlDt2Kd7B+VBsvRv3cW91Dx3FEr
RS+OJovTY5fUV6bxUt5VAJ8wQPgZ81/2XUCuX2YIkQVv6maMQF454loGyArIMNUMflACqdr3BruK
2w9yq0gxz87LhQFU+JzZ1ZVvEQsLoYy9cgChTjAIAmMqdRoY36HMJQypvKvmeBbHaB/kOJSwzH9x
bFyjp7jdGyn2zUXIDBNy5yivDuFYgbHJ8ELE427YOWNg7jPEMuWUhCXDfjiFBm+gN8zMlo31KbA5
B51/2WWUtL5wKJ5Oku7xA8LjMGtOzqUN4bdty55J8FQZ5CRx3HSPuzrZShTQ5cTFmq+bsyNWET04
IvqieSjj9Q9V0Pr3A4b6g0WwsaoUrGIqlOvESCqJHxsXcIk8hcyHOqX40H5SmtaEAIjaZPPqgigW
fT3mAU0T5R4BRSo8S+f87L4lQXIWNK5oHJFgkdhU1sILfULsONvoUgIcYBdLuZzhOnEW3ZPiryXB
263yWkFBbLBVvmFl8/7Ij2CAuFcgbUUkXa4zizVLO+ZZgFl8bAWB3+4TuLHGGcxvkHzD8sCyIHTa
9XxEBwY3ZsqMIeeC1wRwAq73/kZqgngLhvKrQc1dxmMUIb3/ANgUpp62Mldg7XnCllRV12Xr9z4F
GFJVdaR1ghx5ZcrYVLxAoXtfEvItLXb3+pvdYAy2Vm38shGrsA5jSEc0Ue0Qes3ealudQT4rHe8r
LSjaF45P5gor0eOIp2tHqLesJi7kwUXTa+pa11HSuhzKfJ+YweXxdw5gvkjVg31vglQ7tp9SjIFV
cGhctmW2VKsdpDAK1Ws2VzPGvWSz+QW2pmBVemAJpoPmYco+yC39LiB4m20R/wBLnxA1w9gMpo4C
+RESiiz7jyC5auT5gS4lKIKSJRXVwEeTxAS1Cj8xCzXMW7MHmUrXy8wR1bCgoCZ3tzNw0cVHirYF
EG+Y8Cl5lgtk7lxgvLfiXqGl+kJwXLBHj9KXgFSr4yAEFoDLeVyCLJ4inVRdBq4u11sAbJ9sdGqr
a5xKGBNJ83KlZRbziPAjTb8wwM6cLiI7hSNixWURWw+tl7iF3YFRvY1bxBQAvq0vL8D38sT19hDW
gEpouUqqyl0yUubq2VBvG3cbBLet+OINptuWJA4hfJLSMsKJDSsFG1CoVG3bLYFhAteJUeFDdxkp
cK4h+AKA2v1Ljo1UpEN5xMI4lPuPoaFV/HENeVtHzDqXyrHTRtrYqy8Uja1G0bD4IEdkNpERh8C+
cS4Qa9sPtRx6qHt3aBEKeUBYRkNUkx2OjD+0YXmpelii7CJg9MON3lyBDsU8kZtDw8TRCopyEVnQ
GEAlS+CFU6Cg9wjniNs5MxLISVAy3Ua8xgvdylS8MDgAVXFEL6woPNPEEPARfMszOoMWX9EIPcEf
v5RGuGrdfEHnXVTfHNV4N5cKYha8CF4DAypuFFh5NuFNG88xqiU2gWwldVVDKNryk9QmChvhg4SH
biYSQ08IGojB6lpAHx9wCoBSPRBti2Ly0/uUDBLs7KS+wTzc5whG+BY718C0X8QNFWNaQyZBfGXC
yA31r1C4QOFMfgK1bGMTa1rqAlaYOFmldxWSWHhKv7ZHCDlGdPbyAd60s7+YvcNIlK87qUUekFKw
uLj4Lgn1AKUHTMITjLgSuQwv9tuE+VYxfEttCBUmPiWsFMvyQFYlWF8dxblViHFRBYpElSD3dlg1
dlhSgCMynvzAogrT+YS5urOcwuPVWG4BTUCqrqBRS3lw3zPGZ5NOc8wC5OwW/MGlOWGE7LFlpENt
F4Uq9I0TT1MF72jpK7FGnjCguQV5hPJh85nEE4Llsd5Fd+IGP7Mj+RYF5EDAQWzPLaedhgp8MtN8
SpSCgB+XuWVXyHEKoSMOWHRhoN+0HCDgtAyonihcRCbkXsq+YhsxKbVFeTBBGaBgWY7K7aLSxiEQ
b6iH6MEOKJiK5eV/0h0Wavh1BbFigNf9jilKhG2hQGlhUY+2NMs5iIvVbALYYsrI4Dm+554ZF8CP
QwIRj8ymLXtoWBsNWuwuPNfBXffcHepR2al40jXOorqFFY06gitsLCtVBBFUvEQzKNgzMm7EMUX7
YYCmNCiPwY4RcqQ4I72B6DBcMFUAYzYyYT6YKgiouaiv1ET8I2fSDBho8JUKe2Hsy4sgBZyKVN08
SuCaQKP+TL7226Gyq4VzJZ7tVtx+Zz4244/EOhv8TgA7dTsjRrdmnPiHZat85fOFAxG9+Vt222K7
B4uPvNPLFxXlT1JsbD/cDKp1UXzE8M0XteH5izn7toXSIDDUsolB9R85wLqkd/EqnYMJYdxcOjln
2jeUU1pHP9y9Ogo8iJLRNECV+snTa1FS4qyvTZW/3HkLnN2WrUPGFhpbvXE59n6rkbr6nV17m/0g
Tcwxo/E02rTzCBXiOgEt4I44m8eYG4E2VOzTuUICzx4mhe9EF8c4Y/AAb1JdZ7qeS8i2thDxNBs5
c8usFGjo5T5nMa6PfuBnlx5fMXLDxz8pWEHk5I7wYWy8hZZ7ti4EXgePEF2ClfNxc1tPPqU8i3Zj
GtL8RxQLCIwOe4om2DeQBZcATZV8EpXxDsL8x2muGojCvuUuUvqMVeIridy0fbQEtPmF8k0vMCra
jFli0lUsp3iCkewVCcv7gltduHJ5ECA4U5uJHenHFfuVnBeevUtqAd5gwgIIf9iMmPAyxVA7Ra6f
IyxxeeKPzLZcAXh4JakDLlrA6hvVJErQbYqMXG9bvZuLjLauGQXKtbKz1ttttzT4W0hbTUKMJVx1
0wCIwc3E9WFx/wAIMVOAgvoLo6YdZV3eEGNi+Q4RkyttYKFcByxIZ0LZF3F7QypQ1IoXiJFZ8oVF
RC/Kj9RM0eGb6rXwiyNXXSLiHspqEAorRaT4IyWQQrDsuL1rkvmMchdbHXuboj3cN0TWkcaESz2J
1j/JzHQ3h4jjZzADlxSINlZAgglFdlkIBoy5KvI8Q0HbrYSvdyP6in7rKgGOF4sumcyzY/dHIVAL
rLu4EJxVvEdoRKoY1BiNw7cBQwKNMU4Rk9rkW8UbZqyGbsXR0iO5bbaWxC2I8Mw/s1ywEu8RR2LO
0XBIqngzyHhWS+FLlgyIPBB4G3fhEB23bGZ17HYUFuGpP9nbQa3zL0oBoLhE5iVdyriUJ0+4pyLe
rOBazhKEFblvcVZqv5nPQckWgLWFtHiJr4KscZnG1/DLxzFWxxUJlfyBDYVHqO6ZZzcK1VHsIok3
VrkTvvL5mDI1ujcWRHhWyxasW8wbbdywvOzAx8x6gap5Iw6i4MPVb28ytpOeEriqC14eIXRzDylg
Kr0z9gkiqssBABde1gBIFWddxCQiuW3YbtfvsCJZydRRwGFDhNEHZYPxFQVGzdJdVYOmfxKKi0F3
AogWMa+IvpSuAjEBVlUqWNNVStwdtUtSFazJ2rK9ogyG8LQFJqstX6lpipyaEL0x2rK1yPF3Btdl
LqMDbNVuOMNMpHX0hcp2hu71cVQsu6tp8SoO9jLlYh5FgErIPfbHBDsLlrfZE2xWi8KGLOQCoxjR
2f5B2j82q4lE4wwD7lkcyzqocULuWxS28HqHa1XKIko3ZjjbwUMRF2jRKy4N1dRLB2Kp24GxEpLy
KmGzehTLoOXCe/cHUOGRq3LiIK/EXTkq2/mO3chLiJdHw/xABv8AD8Q3gDA5lTa7f5MBa9Smfe2F
Np5YqXRbXUxHXFG9780myGtGVhrcGooUerLZGwMRC0Xk4Orl2/iYdeWqbbt0j5IAWvAgpXpDtfux
giysffEWJK7/AIj/AHCl1vRDokL0uP34xLr5jwDfEGN5zkEsVO85kHKjjyEuTOFQiixYhBbrCA8z
dlut8xyFpeG//bLEgNUsVVWKUyyCghU1LwbiO8HTAxtceUOmjsLhEmrR6hCnZYCNXKrPPdTX7Yri
17icAWayF0j6lvUJHtZF/O88QHu3zHbDh5I8VFromBW4ITRKlniBDla8QpQAq1akp4yniHLV9rmF
AuzJbC+BhnNNHYcR2heqqGAjtyhOi4A5l1qkuiHv5WCu5eAO82IrYxa2U5A/4Ieo6lLFcyhUaZjd
UkQKcXxBakq/DErX8XLFK8cxqujqXC1Xf6j8E7j7t7hlaNNyk4QxSb0C94QqAtWRFCcPBh1X06lu
MbouXp1wsoWptuxDIpixG1cZHRxVRAjTXghZLTAgaSFokeqo7ov5YjKFrWW2E5WUgiLidBCRqvFT
lJoqOSjy1spM7YR+m3TCLgBqlKP3EmByVjOEPxg4+UMbIHlmMdZpL5I0pwQ66l2qz6l5X5rI7KzD
zBrCFqplTpeUOvmJ9BoyXOgkAaAwYkfaQiYAoTHG8/5jFtTlDJbXwB7hQS4psP4JiNWOhJtk/A/S
WPUW03UKUq0oYBzUKcvuITMWsEzM5CKhZMN8RLfMWr1vE4EEol8ly8SxgBxAmEStnAxcnMKxCNcw
StD0Tm46ochGUlWEXuOUqxp2I5915jamLHD7is7S7DGLwURRd3LCnJpkHkot4XqO0pE7mF44HGCp
hVowkAHISNtg/SJIQ1ITQ9UWh+9EJnMU4QWSbtWNS0fgVcEX5Zz5H5guY+mYDA3bh8QkMboPMF9u
h0jXTzxLERcK4QXeajstppiL/ce5JxU6b18xNF5AFyJURoPzOA9Oar8TOyaFcxUkNxzBcGBeR0Lq
C3sxulZfkmHfa0xyY6rUGVHVfpjQeeiFujVtcksNBWHJXUKtFQzYNSCQ8ku3UrJOoccNKudElK3+
JgnIXxH3l4cuBFxo22Kb40Dr5mLxLt4h+Dlat9xaoHAcTr4QnVwEDivBFOILQWSucEBLHuyVP6Ws
XLkn2Wpj8bVj3K9XLW2/UF6RphBSwMfqEkpVbDZE+YBoZyQAL/MPLrTUyErPZQzI1YYp5+I4Xp2O
OJ2ool8/uVoy8nIaIp4qUV5eNv8AMT5xOR6jVUXrTzELcpdLCCBVb5yUC1Fj3FnC0FAJFuwWbp6M
P2xwRf4gG1K3YJgMWgLceIBQdYX4nRARO2S0WC4NPolLsAgF1LB1QC5qAXtMvaB0oyMzCvUXK1W1
ALBqwDfmoFQh6AOxjPVacdTkWL6l1pLOzsECCLFsilVw4C/EccajNTxLkUIPHEKtAWGQdIgBwckb
csCFWQhV1rLjkEqO6xZUwS9BnOuBG1UStOIgtfmOBaCvK6uoOuFR79weG0WyizuU0IareEQg4NXU
sQllyRUaVlfHc39/aNXyPxE5uVeXMrDISnJrIBhdebS4KTyOhC5gDb3Hs0cTabL8LdqaEAIO7UHv
9StB7WGAczXn0JebKB16Hef7AkI1MpXzBqKBarh/ZKEIlUGkkpz/AOqDMIdNCPbl8aPUCWBXkpmF
bcgcrLt7U8NYAoVInEYzuAGy1UoA0A9h8c3M/wAFCrmX8jXEKa+yXTL5B42AHpFKA8kIJqwPJ/2B
xbdm04jWVAHAbUrLF6DCz/s62ALm6yWwhBYp/dR2K6TpgpQdxFCLFD5nKdOojmUOS0A6KZ6oi7Kr
xKMw4hsgG+5uoF4QMR6bWIVlpvzGtUCk36j9AengjyYEArxABVzdoPpJaTuo0KcjUOIptE5leb35
iOSNvqUwujkJp5cGSl3gV8TyF38NxVUIV6iIS7Vd0QE6S8JeUV6hd1cEtub48w9Rgi8jsF2MByMS
wPBDiUrywBW68ESg0viVANX8RTbDH1C2AAWQ8pmLJr+XNcysNBynuJZDR/MRf1P/AFyrvDc9oPdU
WJzLvjsU2crtXQyEYcQ8JTqCFntlgO3NlkBgKexvMDmLklRmFRKeZY/YquvEfMaKshkOScS7rXgL
gxSXdcEOCKukeDOgvIzO2aqVrwU8GVRJrA1NH8z0gGpppANRtUJsIzUcHDMd/VdvmU+hfijZNFw/
EG7UEgtATby5wB+huy4gEVeYs1pWH2o33wwSCkxPSOqhp/aAi+SV9Rr2eIXLHTOuyCc6XWrJxvgh
MYS2+RFSL4MqMXt4HV/MVFtAUEugXzAtVd8EakbyJKZU142ZEy4tWn3KAOkxHAeB8zIVGgKyN3Q4
FkWkJQD55iaSBWuvMMb+TyiKMvmEAaQpnio4BQ8uIteuqsIJovNxzPEoDhRHUJpO0q8OoHUuHQKE
THZw5CWaVFGN1EgEMjcs20HuEgVKU5Yq1phq3NfegT9wYC4AyDBq8eHEU0QGD8QOyNI6hSy265Ib
UvEENS3EBfy+ItsSic5xLHDFHzDXg4DupyxFJVyjtvy5iUNrdc+peoNeClDCpO+1xGBiVCqZWwAL
eLDz7i4AL8EMuUvHGZM3KhpdH/ELQ2aZXpIRwHiCkBXZBsWvJPMIGQw0gC057t2rjcRZYUWIMbtI
2BNkmnECasNJacAE5LKlA+qL8Sn8tqDQuQthG3UinHMHJN9DiK0isZ02HwJkcWMoVLc3CPlRaL3A
De3k/MCKWkDUDNlh90AXRdXLpugTz5lbMlBl3CyaurwlJA7WUeYz5o204yLlUBjhA0DFN26hAuRV
zfmcc4at28Rs0bPI9rFcoE8mcEaUK2fLCuUHaJb+ZR1NonOfPxLZVNEtu6nV9XCksHFcSs40tri+
pSi9kNRVdShzv/IQGTY+ag6G15OYgVYdgXwzVCzpw+YZErQPuEG0VDM4jBCigzjIZTRQ/wAxLRTe
Lof7HQHGh+pYCicuXG1Us/HcsABFA3nJZ4Gs9SldaD15hvXbV3eoUX9lwuczSPbiAyQtbFl1qwQh
4qAKu9/mYvk8d9xmnEXJHvNz7/8AsBoJCnubjOajBHLAuurV9wxF/Rx4iQR8Fs8y3csqHALNDuyJ
uTsOg6IltxKfCG8J3HZTpz1Kzndi76iZqlyekPVYejlE4E4gOEu9QQxIeRnaMgmICOzipq/KO9oR
PZSc+5xtrhx5R3GonCQN3mnGQklBnjCGaUAcPexAwxrch2ghnUmDTPIiJduSyF/IExMrKcl8Sz2U
jbpv5ixoRNkozJaSX6WK3v7lo6oJoV/8h9AkHKGVNtZ20D/hLn9QcooNVC+CrcipVLYea5/MvCVj
yQX2wini7+YzUqW81zBV17fZOZYzwE9XFFIiSBW1UJtdzGynn8Rxx1jLtsoUyo1paJWA7l4Gf1DW
KdeQuNWUV6pi9dQttOancrEdvcagBgWhR/keSCF1HaidjL3zg/5KQ7iVkaLIq09GCWQLTuGdm8wA
d+ohPEuEACzmKqzDmoQA0+YVXej5ltwsqyYZ4o9ENRVK1zfM7K6UNqKFvJLOiVZfUDAWyQi9O7io
NJYnXMQdzKnE6JgNwOA21lWeC8TD89rqE5IVGBR7JBlpaXXOQ0S6UPzDs7QFI/ERVWzZyXOXx3Ff
bp2JzxZHWX9MdC93YbaH+oqHzAQLonhiAP8ALKks1daNdShuDF4L6nHUA5CKSAfHMEEtcIVw3n4N
hXAr2l+Kf6yw6UtTtuV3qiN/MGxQAEs0VLvWynqdwwNRLUyVsXtUDGFVBlQ6qRaBDC2jOiXhSVsI
AWnmFogFVE19Cr4iUlhS+ozAclhLWyJRrJsUDj4zP1BCAcvUrS62EFw0e4CwqLHuUblogx0fOQTR
Cge4Hi8WOtCOcy4MWWLjCd2G+KlYzVLjKO1HD7gkdw0fiVWS0WQL904FxNWnhmOleiM5XCg8xWSK
G7lLnyYv2Yq4b1LRbYaVUEp6Me0orYeYcBgW2w7huDGUXvUuR76hwD9RUZnYRYilf9oUbMteMisW
u3xzGjjoL6lzloHhiyi7iD/IL9yoBIY7YBNHyQVoVAhGLMB5hQ0Cjx6lR94CFi4nmIkjtdsaI05D
xGSVv9S/QKuAsCTMLufEoigtKiBRYFxZRbXJAV8Fw/KOKe//ABKOlwBlJghHZuGqieEC6VAXjqCx
nR5quJTuCwB2F6bk73mEcJX6EDm5WuyZhzZ8xIoodGxogLW7ju9Q8dTvQYr1E9REO/8AzBZQ4gaC
XsuxfdkQleD2gXFWk/zCsVjXxzOjunxszwPOGmgDXxRUzZYQ3ouE6qeBsG6SkdyjRXzcty1UGwcB
A7hW3mWBQKwiocQaCpQGGAEo9iBpmlv5JZdUD6jSFfMITScPmBtaQ83F1q178QrSTKH1cd23DbsO
ytcHNQwEzU8T47V8Fy91Cg2z1LrzIKdrWDBGbTuv9h40ATjBuK/xQkW1WTgghEC0GEtTBPI2HcTq
E4Ag83xWPZgipRy+H/YwVRXBaEWaZFOMh/sFPMHSKmeWA1qLTpUe0VlvHvnuDxtH4ElUSqP1HTRx
H33MSB8nesrIh5/REy0jaXEVMUQ56yWF7ufMtqKrdqDN9RYGdUceeYCIY2fmPp4T87K+ocYfcU1o
reVyDwEFHUKbBleRMNCuW1zDfdALtWVzq4vm4ddzgT/s0ihoI7n+TkKqHjYWqX1VEHBO/YTCrIUe
syANrp5l1KyUlxqfVxKUovdxyhH7ESKwE/xHOGq0fJUeFFCmrwqfPRDWQJQ8NR7gFreNGEttijnd
h0nAGG4Or+KiFKmjVlS9RadJ8RAmoWe45oIW6JTXNRx5TRACx6igli18f/EWrCqwas5/EdpvhE8H
/wBSpNXTrCEpOuDXxBhWk/TCOaiU55Rur5Pnmoz9MGU5BJeKoizUVX1Oeek5C+5ZjKx9S14KPnIK
oLCy3wnS4w+FgL4HbetQmRbc6tBGrEccRL+9XcHXos/h/kYYRUWF7mmuU/GSzqA3b/8AqICMr4Tj
jdXwX9ylcUD+CWypRgqqWvmAMIAKOD/I6i7fUC7BQvx/yXfTNQguXDa4H8ENLCj5V/2OOTeLfH5j
E/5mKDql2+dlGrmIRTuKA7vxKL0/Ub819ypcFcT3/uWUFC/zCv0b6mZrb5lxqsvSFmmly45FmMfX
MqQFDv4RCGi38xcqKHb1CpIhSsVSUDVdQNkPgR1H2d8S5LLp5Y51NPqNQQHQ8VK+yq14qVZFLT4h
VVjbZxcdqwoxhwXvwgFSwkYzDm4g+6iLu3mXlG8XAATblgCFS8IW13AtQI8QJyGC0KJg8seBZAXP
Flx+FBjxkARVgNcwrRVTYwBpxHuOTOCHZ0DHezohdfuUO0Bocxh1GhLEdLr2MHmlBlSY0U86x0nS
q4IS1/qUnwcM5ACNy+Gvtg3BZVL7NCq6mWCxdxhWZKjy1djqOOS9viLBKyvTHaiGhzPMAFhNR52F
13R4+I0iKsPcVDTyPWRRpFPMdoS3XFXF6w8vcpiODmJyiHU25XeZLmFOG+64gmw6U+JcMqlPMoSj
yPWTeMED6gYaa6/EW7swvmIxAeYzUxgRTE2uzjYAGymueIcHRycbNacBRRc4tC342AC2qVA4LqaM
HwIiH8zjFfllZe2pUOj1E88bIY/mOOSFHxNSa2/Fy4CUAPNx4ZGHunmLOg7gHPcqjFAGWLIUyFsL
WWKGqeIwJbFe6lsjS96nbKF3G4hQQXbz9f8A4UUTKlKqV+PtuH3NOjSbs6qM1q2xnAOB8y09lTuM
xWBp8S/VpN/I/uGs3YPJah0b0ah0qfgKhQGAvXuEpAFgxyKdUXMRHBcHUc1bnxXiA1CFHMFgARu4
K3QserI8G83xAM3bnsXAIWUvK1zGRb9NLit+pVGasq3DZQFvTMyW/gAeXqEyw7D1SwS4dF+4StoU
rzL4/PQMwjWkNQUp9q1+o3hSqg6wCFigPeRJqWIO25WB/RdbCjS5w6q4NSDH2gpayCSn6jlmAlWz
Q85DVhkDoCElmuWc7Lgyix4viJDGQ4sqMtLX+PUem1rhUO6xOclCFNB+I4DCogKKg0HqdvXVXn/6
h7Uuy8LKShT5XH+xCHckWBmfEtbbFol+bhbUUcNCIFmIHX/iCBlsB5BhhlUdB3sQFMEcktiIzrem
b9tVerY73jOVaLL+wMbAg2EiIkWhwxtWHnxLgMSoO4wBl/OYjWhaFPL5hnFUDRbY0KXqvTAayR8E
YFbjMFoKd5FKLmvSvE5OfhRfHGSk/wCmV3BYHIIeH2p8ssj7Ya2bLVI5SSqDgK7w/wAijXMqVyzb
qv1AHxPlvLgM2lHkOpYJAEyElll6HqPoqvbnMqOnFpPmNIYB7ZcAKUW12VxL4D1MoEfKzRfGxqw6
nTxEF7IrPs8QlKAXpCBmj7EQY4GlSAYB3Vp5hiZV1pU3IaWUXlTKc9NgPUPBt+hC0qdAHqWPsVMB
yR6JLbgFczYyuIF88xFB3KbeI7vKT8b/ADB5J1nh3uD0cI8A/wCy9jWxXgPErBXAlrgHP1KBqEAa
IegvFYFMqNVkKvHyYFlQ5lGlSyNVRKZTnK75uqYXQtXoXrAZFBXzRtw1YCuCjYlBTROQqBeE0XKq
MruADdwz+mXeH/SCjI+RH/YP0kHu/wDZRUd2CKBdbWoefUabgeA1FwEdnitjbNN9hUGq8r61XEEO
Vans0kWUp0eqv+GDXkt3Spkbyu7u/wDZnUvRyQBc8AB4l3GZbdoS1dSj4N0SpdxpffSXoWb0s4/U
d3FE4t5goGtPOrr8k1CwDrmN5AdmAJQ/iVNjQQkcX5lOG1gxUfF+ZrVylsxAY9SovnQYi1vqFApY
wxbgqJO1sbTWv5gsHV9kGDFho+YaLg/KA7LO3nELk1NJLRoud+oIExbZD/LaTmGNn4mqEb8ll/LJ
R9Q/SL+ZQEaUjQrLsH1M5np8ZDa275lxjj3BGB9wC2JqhihcHnjYzKq+IgUOvM2c1C1vELuqBwhE
LxbainsLKotbOwov1Ah1gC5TqgNpeJDY5fe4eC2FWxHYml3cOAIqnkIHTvS1z6jU2Sy+nxLN8IMO
RRWWljw1ABLBSvToXKReFuN1E5bY5prj5hoTC1l5EMGVZozIpr0hUZhS6Y1BSAHxACD6XkgYG8bR
+DGqxSbdHzFGbatxES9KXCdSuh5lAjQ11FysKEYWUHA6mtUw29TAuwVvcSciN1rCmnvGG6eT3FVl
0PBCEcGhgzl1z74mDAnW7mBEuEG4KOHq5SUVCtl7c5eUHAY1dwW21Z0VGjmIO5SQqo6ya1OVwffl
IGw/eOiiBja4IYLC8RJrFgfUQ8OhVzAwIhXmE0KU5lIlA3ioUFTt5I/O2op0+o14sw9rh6TBupQs
vAXbKvlW38SoDbYIl+QNeIAKwteeZU8NUvVyhC+iyUiuttOfcXRg+G5AMFUN0QzROHIeEKx9kAw5
bcnqUJ7A3jIPIPwIPQ4ne7yVaqs5qKXALLYFVu8w4tgRIAaaH8Jbg0fhOGU4ckFajsctTWoyjhlW
vCvqLFpAUor9QZBVqtnA2V4C1A6gI+kxQWzEYFN18dR8IaLn1LQCDS4ymV0OY2IqffHBLQXjJXNm
jCKbY0J2wN0tlOZywwCbS0EVtg0DSZ5gX55np4iAm/YoSFBVbqqir1OGwpdj1LshiEA7lXUm6XRx
OgD1fF9QWLVUcqAaQ+6KUoAvhkp1lW48VxgwcgujjxAXdwvXyTVi6ODYXNz5GpTKpABtB3B1FEds
l6gDbNEdKsFG08fECUjYd1eY5hMKcGHItQYf7g4U+1hA/hLJUYQ0SixsRswupo9RW14XFpXqaW3B
8WsqlaFoFl1/LjUR+EUOXKn+UAzzALA3BvFILn3L1p4vOYsUF7C+/uORVPOra8Qmamo+byBy4EHC
cfMagLe8EQV5oLKYcSJCdO4AVeaAc/idgfHlx9nvrKt/2IEfTtUssQSpdBPK+TxExI090eCFiAI+
JZGOHxDTzSpZXNE2A4KFnzAicnHDHSIgvMMq1UsP2h4Viwf1G03Gog2slOncYJ8UTlrWOjuPFSDw
cNHZ8BuBU21Il8xwqp4apE95DehAt3KuviJzAmrGn+y18iW1vwy41S8suAqgA4CXuZUM1Tbl1q7b
GUvo0PLEnKLVMCshgTZC+CS0LjerR9RrCqAq3ll8d4j33xLezw3ccCVaaHqFRtLOU1nMTop1GPiN
aNIwcoiSB4yJzQKLR6hMYeLtx49Vy9wQWh3o/cQNYbPTLr6AC8eYEYwo7BAQb0VA2LUAEO6l7ZU9
0OTmVQ9XgGVGfRVoW1gWprzeUyD4pyvqPqutHRH/AAtFUyJeIDqt+buZxws5UVv1E5QZMGRzlt7a
dcw4pSuAaqImo2+bNFUFZbnIAEwdLE49S/bZF8eI6fTlhBJlDrfMYWJUuIAX+ibFbU+Zk7FwTQdx
WWuJQ/MsnoQTuNcz1QlQKOSM3Tb5idFrU0YNILHk93F6sR4+9taKPoDstOfzDeGiVWrmVbnZ5dMX
4ZsaqkEJGsDgl0hMocJvF1WjrzBt1UU4JexHwhadVj1GOhlKGcvp6lgWAFciNTpsTwxhaJYE9AkK
oVUVqEqa0V5lClLLWlHuMNHHZC0OmHkjQA3cGW99wBs+EBitYKF0mGrkfNxEXHByomOux24oxwt/
0lfiK3FCPQrCAkc2qCQwUeGSjsLEuJcFWBMjhQuIgc4AjbHgI1BukOAmsyFbRiYXzFdwcDmWRooI
WxI1rwxyxT9Rlmp4H7m/NujFdHd2sbmwNf8AxHwKFXxUbrS3svo9g8wordPcRJb2eJdH6KgdBQal
aO82yNvXzdygoLylRW15il2bs2FGoOBiBgqL/wDY5aH3+oSKOjBjkKtiCuz3LeLO2VQVODzLBBwv
tGC0W6uXTr+QmhCeEFk8zmeIg3U7zGlMpVdMryPBhsnkpeICoK9wNRRhWQsAOGxUoseeRJUstkTp
8nqK8DBDn9zeKM2cwvfM7JA8g8MRqrzgIRPo5llo6XGDMK9RW5yLg+qcKZ1JV7WmUYaniGhNhfMB
qUBXDf4iazW1wyKE7t8kYRag4MxbPfn6gjhO3UA2tXcei1J0BMjtUryjd1cr3KIq2C4wz1Joh0V0
GWQk2W5mgHcwEePT7u4GoB5nSh9IPzKUxKotcDzCyo0Aoq1E+5XoK1LZi2Q2Gh+oKXuqKa3zHMK3
Zwjcr9kJGh/cp2uqs0HuCVKAPYcU7L6gYJUfAwWgXngnYw88SxG1tYWgXB2F1NVFKMdir3m5SRUL
05qcSj3A2NupdeVNuxgHXa5hV6CI+4dNaQtn4ajhDTZZy3MGvkYqRY7OGWib2q8y89T8e4wCydmB
tD3yMVA8DdlIFvaKkULFY3wjLnELl1DKVN0Xz4j8zCNM7TcLodBsaoIBj2j0CvAEU119wLXDyme4
mQrdD/zHSosLTUMXxeG3cFwL1thd3CtIYufAXKxYHFhUVKXh7yhjZ5DuDqx0aEXRyuluHhvyrBt8
CqLUCviKBAKAZoynOPGmWhILG/iVLaYoqOVBdUQIllreAEB7DADN91NQmM0ysf0BbARExXNW6j8H
hbzM5hltSWNuviJBwR18y1hcNcWUilfDdqcJUC05v5lYtTQEohTydsF90NJm9HUJIf8AU4hh2aA4
jVvTbYv5rRqMXDzyQBorCdYeTVRU7UfL7mFpus8wQIPFNMJNM5NUiWg8q+MWLFfIRdyUeR5gAFYK
j5HkD+JemtNM+46UbdTSR6RSML7uuRGdDEmvB1NkFKJrI+4i5oaG8CiUFq2ziUI0+ssIWr1CS0cR
cHpbS6fcbakqptgFjWQm8i7eCLGkWjE8q6AI+w1ff+Smaw8SAuNb2DrIYM40FXMIFDeQCEUyWLpF
TMvDUuadz/FLkTfmIJJU8R9wLS7gCXxClrmLT8S/CICABUCEAJwEYuI3xGgi667gUQBg11ExFwaZ
HUU2juAxJlNiiT0m3Iey7gQsW5BHkKBLhQcDLqHF3azueD76Q7e4X6hEIiC19TFPaHzCxqMzuNg9
bRLm6snhvucWJYjZT7i9Wozb5HmDUhjYqx6lhRd9yh7xOCAw2PUAMKlnMui4D8zuAzyLh8UVpWyr
iPBA1q3RFlV1wfuOQccRwVt3AVfIVsldG6tDzBehGa4LpvqbqlNQrRT4NqEZvahHlXUg8E8gRwoL
rCXI255joQZbnEo1XyqX3qaqP6SajmLXtISpEbWQPdfnmMTpzZAT3XbF/wBHosl2HiKqoznC7C9w
O1LHKiWQh7JGXEhgTgRswjUA5ERSjxEai3xZnaPlAGTgAlya9QHpQujKl9gGDk2p3VHbFfb6ckaU
PeNjaQZ7itu0gyHFfZD/AJKZ579RKw0A7ucBYnRCpbIC1pqPcu/EJ3GXJL5VsfLRSrgjfLxL0Zd2
bOduFwVoBbKphoPEZLcT5gQVatiViu6csQJwy+DKUwcQiYnonx3GuwS0cQ6z2BMcBo+2Dc4ArCGS
Au0z5hQNgDz6la1A5YvUTIscDeHcRGtQogFa2lcDMoxShYsyhHo7Kd3gXblhrirA+I/KOgqgbJxh
iNbS4qU4SWr/AGlGByYs1pHSdQctoRLW93KCo0S49GnFazF5FDFM9o8P3EogsZ1NxUCjLKAB4cQs
8C5zTEVMiezxD3Sh9HxK65Vdcxy2FoSB8V+JSgDmgn3OZFqTiUj9NYvnbLUr8HSAoVtB+5d6FSTO
YUrywLPUsal1l5K2uzwGYAcvMo3MWUlZqNDtSg5NW3E2WoHgTPz6BKVl2OYEGmhrks5BS3l7+I2C
9u79xMMomimMXVQLLuK8L8c0yqK2t+ZWALo5/sCgDaawwFytCfdweBczf+zwpB4eZSdaUYYELDm/
iBqoLgPE4Ngs4S2Doti5Wonl/wDM4mBV+ovWRqC7jbsOFpHA2orE83D0lwHLHfbCgvjwS2ELad24
kMaNWpDvgYXMuDsgXqCmDw98RMFpwf8AJsMaAb8ShM0q52ZvVTZIeIg4LUNYRM6NgTgTXh+YZvvQ
hPhYr9QvfzCBxkB8whRp6kfXGUbN9w9F6K9sdxdiUyoCLyUKfUV4b6muYli6Cm0wwFWmFInPYkWD
wkW44D0PUK66zusMJ6yqojOALOSIiCgEIvppd5RcTTVINMgWA5QTTZEDj3DRjNoXS6grgo0gdgwD
avFn3A4qLBxEeWABQ9zSIxFL+oEG4Gt8sQPV0/aWY9hqn5jlRHsIGfEr6B+RCpShFK5IsJJxHoX8
wOMexwCGkC081Hl9J1XsljTQA6COBBK502GkkKvBkbnJTOAPMu0tDsDSoqFpHxsKC5AacJbiOxo3
SNZgHjkPaegpuJpCHmOX6gcdHDetfzNxi4virlo4FMpXE4Kjr4hK1OA8WS+T2gGlF+ZUTKrgW/mo
3ac+DUUAAX2sLIh962vxAmhL1jy/mAbAMTiuP7gkjw0oWQZbuovh5lzLaFK13+IGSiKApSinvYVW
m5idLZptOlQLyfcBMpC7j8RkcYzV/i4wdWDkfmJYIRUOrxDTRfhFsW15I+yn3GYsp6mTkwla3B0u
aSg8VLGcAsbmgSWkJVB1cfEQWz8xFbUAiDuINNwDwkv4mbAErDFip3SVsCQJc9XHNzS9s5gjlKGJ
ayEPGwvY0OPUNDRopBmlAs48yrkRQd3AqGAfClCC2guH0AuthlR+oS9PU0ZazuBdHhmQ5+oqBBL3
Kq+KlpX8yyS6HMHKlUlr42cICL6C+JQTUBWEdssPRLeIoDYoE4B75jdBydLBOK2wp/65XqHS67hi
jtSfqFd6UY+5SjVgcslWC5uoJmgAUyktS8cEdNvKcvmDwsUtQkdj5ThJQUdMDJLGw2LYQAe4QG2g
PUYXiwp1NXxV1LI16CZ6Eoc7x+oXE15UarNabcPgwLDiBnu16Qs1BR7Y4AjwjwgmtCrlc/plZAmS
MAMfEwnB+RAuKCCN96Vdx0kwKinyWb7QRm6bMYRABbRzDlra+Ec9Hs4i3lwBv3C0ofsuNBgcVPLW
Va7UZgHjkBWJazuFSSovbfiGGTvRE3ZwKglDG2c1B6FSEpBGufxGIcDxBfHccVpAfLK6laRxAZ2K
B3BVqq4S+JhcuFA6X1OiOCXzkXg22uSDwSryUZ2FhDwREOGtqjzzKqRofEQWuxRAbltSe5kwCi9e
oSuKB/73Ofxh2uDIgGBUAlBt8ib3aB+peIbbCifyHOojGhBKqG8akr9srSiwj0wfMiHuJVWhsc+o
EqGoyyowbUrujHCs9fzBpCOPG8wRjIQzSiWnqpSUeL5hwGnCuIvUW0afuEVG23piqi9Zw3zC82jR
8QRqFAr23CA0Cg4a4jSpNE2oMmGDj4hoctV5gagrnS5UgbO2viGkiIGVe9xIttoKlC2II6h0jtns
rYMq5SujzLaakclXcBel9WmcXAZEX0js9jMtbXUaYLi+OYQTiZyVKqNsOeEEcrIRuBtjhsv3A6Mu
XcIxHGf9lSAyiul8TGjIwUlqDqFlIseQw04NxDxG2vGZ4l9aBvVB/wBgFKu2l1wQibiPfllZkJeh
AP0KHl2FLKlMuaZ1UMq8l1IAItWoMkUBXg5nzyIOw2yugDM/7K5Vbdf+8xd5QqPbANoF+clMSkV/
KGANaFZUxKg3WykAj6XxcHwtVJ/7zMwEeRZcCQIseag00L0K2O34NyuGLdeUeLmq3WaBT1GdWrXJ
tBQk+JRjYt8txy2Y4q6IK1gnTuESUan/AL8QpNex62AlC+jvqP8Ay93iAZqde40DUHniJRJLVFMb
RbAN1/8AkIPame/+RDFabWo4R9pZchF5jQZT1WcSw04csCgYcDpAvbzNYrPk1L441DCL9rq/MqE3
T42eHMhjM7FF53mBA7AHOzfAh5piBCaU8/8AyNhBaxxVS8QgDV3f1Kyrkwr4h6roTtDm1QQ5WVHa
pnhPtIXyxTVWQFku45ifweHE3DZa86htSuEcVKerhD5/yGWKDrfMBQlScxvScJjhxDB1BYEo8RCq
fQQajuVMVUpEZJXGlFZLzcQtpSGUQRDjETgTchyQ/ZSlkq2ggvXQqdEFAFrA8EMDfYLyoEe0jX/p
EgAE89vuOKvjzQU/yMRUWy/F/cA/SwMKQ5K6jo0uaXwDahFBq4vQU/zHbhmA62Af4tumbCLZg9T+
54AdJreZWxcvWb0gITKrVF4ijIJVwsvoNqQf+EQL1sOB25k8ucAU/wAjKhseJQp9olbJW4U8ZKK7
fmCoEqLmkyp8ZyijlgvUbzWWbNnahKWnOIo0KtKGFAA/SEqj5M1EKtKPi4tqsoXx1Efd2vhlXwb6
S4fwDhuxKLVqi8Z5tl2CjXzBwun5JtxatYME8hL5XIPzGdgCPHiEEuwPiMGo5BlN32xbtSovBRBy
wKi3PbqBiAPcEXsihUv3G3HD1KU1R5llU2LQSvibUooJ8sAohQfcWSVpCCb6LPUDQUW+7h8LXEtX
7F3xFDLBJxY9iJBQW14gCFHv4hqAE0RkuxXjBG35HUIY2LgXciUQhNYo9RFCiq8mR9hoz4gtFVye
JYwBSe8hHgtkGAS9Fo+Uqbmi6YNEnHH3CYKoNuZdNchktaC0uSgHf+TgjFkqZSGv1BfimnxEKAuj
eRi8fsjvOJJRUUIVRTTdxBrV7JmcHiOuLbV8bAS4JID1XdwkaVtR+XLoePRt/ctqF2+IJUoovpuC
85CLMVCcwqtQI+NlRYoAfESALX7jjgi1GF8XzFJKVpOWNSqxbhzCUECOHqeGAW9tcQtOSB62XU8W
8SwQUwSXXsjqaFZ1UcEWcuyVgDVhXxHPAOu3YxDDtYui6ZL4Nrna4Ya3+OFRyXVS/wB1v2l6gBh1
n+QLUcn4iT0s+J8tmdTlgRYMAOVkt2G8OkBWBh9oaO03Fp0294jE4vFYnmJ0KSBa8GQs+iPmr5ig
nKLlaNCX6uLbTpvuXdJgxO6LVsO0KwnhZ4mmzneYS+pEdNQSSxdeC4lLAoTgY2e96fqcgCi/iF9A
bixmMwT1yRjJzS+5x4GrcSrkoVRyRFCsLCxaxzAjQGxyLg31ptMSbBX3Ep2FC8/EZ+g/+fqBVuyX
FK17qVBW3B6oh834jgxrX4mmg293AfTKhFz+9nKbXLxcUatknrIOVbiMBcU/cOYv+6UshUKYB7Ld
gspxs7jM5dpX1OpgVHkhIuhZ6Je6BT8XLqjbSyYJoW/uFPVjTySz9BFgtBfyEXKLDPMAdSVr6IGm
07+oRYvbjjJxwAqVTx+0WUi48/8AqisBUaPmdCUP0nLVgufBN8ysHqUPUJ9TjMi/qn/IXARxeZ1P
ivqFB0q87Eu2WCy9l/KpWAg8pYEMG3rxh/kZ4UI3xMgoBOsZ61I/EqMOA9WwtIqob6hCaq/condX
6Qryob1bhO8CPjYj8bD8onesJTd8wKsCrXHMQzSAX0BGz2iIvj1GCugfUyP/AB6CsApObljKx0er
YTcK1fv/ACMW2LsPCVuq4OKsIlVzVH5lgB3X8n+xMOgO2f8AYm23C/d1OHON/bFXBAZfMMJVNeZc
TqVfHEIpDQjOIqhfeqAFsGkbaguPuPDcz1DuZgw2hE2+05kt1XzNUHGfUsBtU78R6YvocdRay1Tz
TEMBQLYK4MZO9SI4MKKvk5/ErrB+iM6OG3/3iIsKw5UdqBuA7HwQqUii/RDpNEk6MYClMAccZVdV
Q16ub1AsPWsFmo17b39Qx6NVfhCIcks9XNvC2xRmSt0fglXMuj70mLC5OB4lY2dOLU3EaxcoSCKs
c2woNSDiooRpOJzlTMLOxhxGrUQheeYaBTmmkCGqDxsEXwmCIWNdgTFTxEY6e5aTLMJXrMBrhyGI
cRuPzZAsBlHDbDvTnjySstFSp22ZCBREB36m7KOo4L4hxKCByQ+yCr8QveIvmUKA3Zzsflg+o6Vi
wguq2vmJvDR+gjtQuL4W46VmQipHZaVUAJOmWKl8L4qJr9Vi+vDUXB2+Y41z8QBPCxqBdx4NQ0Ks
51lLwogwagKc8bHXKuKAdo5gvoa/mg+jIBzacwADdfhzGuVaB5y4A028L4mdFV39R7SuxxNslqPx
CjglP1Vp8E7fRun4hmW3DONqU3FIIX/EOSlidzhQtFRmjWBzUzyClbzLFgp4+Jgu5eNiCrVPfxKI
tNql5CviMvojRcYiCNxAJ0ZHyXbWAloCUR9LebiPdYB3eEtqHGSoBWyoiRaeYTVaH5ixArm4rQxa
iEZqMSrhwuOALXELbTYE5AqVcdSjvHmYdJtni4hoKWxT43yzsGcIl30prjYS3pBPMFRGjhYHHU/a
Ep1ylYgbzYxJV3PEaPzLYUAFtzRdltwF68x9+UQYGoDzUYZCsdFwGGIL7O4E8ENaQ5SP4sGxEALW
4yTToPUDO254LmCKIjMkKdIcA1QVesW4NOzm5QRkAKA4Oo+pQAxlacNeI/LSSFbSv90QIEqkFtC1
PUbCXaRFSNnfErEMAncWZVisM6TygAuu4aGXT8IgmoU+y5aSbp8weihT/KUhtvtKaW8fmJAOaPuF
rZET5uCr4rPm9gkXQ+oyxSAOW5V6qnyeYwQh609yx7fPjuCHI1F7eR3PBo9LcvCWgKdbFXOR67l8
PPN2r5hxGgP7lHODUHMRblHEJqlVvvmEAsCfcuIUP9p4XAd1f+S+VphOfMYduTc8EWVBYZ/crTEh
t7UXqpazxewQRaKA6NBXzBklBaPPMcDnJ2LCYw/lHExVhhwIFHh2PDBRv3GwALh5lf5UpFFzTZBL
KPy0C+AT/ITdUfFVXL6hRrrbITkLwe4p90APict7CkMUHa+SHaQqPcECGgdhkBSFonbUMwKY+7nE
ph3JLV0DouHwCw3uPbXQr4f9jwippi7jgLSH4f5KqEivQIutCY2IEkC74BGfTI26piIGmt0LpjRq
NwU2yC61y+Fcm0YFuGygNYicahR1UukAUOmVKkdUue0I9lW3vEU4hm8qNTN82vG2QhmBXPE0NrN9
wDyxWvY0wHRz2CnNVnqpyIqh2pzeqX2YUlbS7iVIE8wShU3udzUFJSW/MPzWHpSbFioOL6gqaZ6G
rAkGovZb/sGedKlvpAeIfoZmkBA2Gx3q2xnkplaKtautyMhmGhwX8xd+cV6c/uWWksFFrJR6hWBQ
aY4b9lSiYtPZN+UhHL4lnCKq8xb7047jeROXRZUCGO4OtsDKiWG21/cA5tpa54heTmusjfVNdV8R
pUFsFSiFBIQYpqVMrcPBI+RMbbT/ANcAsClg71Op0UN21TKctEBGxhd2dq7f39y16y06JbA9beI5
oUhfRkGOEY0mVv5g2mjJTXESymR0r/souRYdBAqQBt7VfzFXBk3Lt/sFm3+Ybf7iZCkl+jj8Tqgg
6dFy/wBAF1RyPfEJLekhX9yhim9mdRAGT03xn+xJlpZCj5mn/QKVX5iNx1Siq2CUDQizXMVm0Jrq
ZqsJURh0RcXpkBZtRacaxFWlh1EWUz5JyLTqLQRrthhTDlLKPuqiAl3mS0wfeUqgm4qrnNdXwkfV
aNn8SgPcB5ZYvhK9XNBUAJNxADuCZTy4y5bTkgkRdpfGS/A9D8xyNKkFeNo+pRX7msNkVVr1FCQ2
niClZkbX0zgJeiWiDW0yKN1fieZAYfE/KCgKX1B2nQvuYBTvEZ5WhcGmpbaPEX5OCiy20IX8Qauj
bfudGH1ihy7Q7csqwivb1A1leTHcugrQI32uEGFl7zgiqC5tjQAFUuMjq4osIieoC7ohqu+mKx6F
boB4gGx5XCATZrqDS4bQxxRqrMzcA2MuuEccThqAuG8wFagPmAKqUGXA6WuEjdz03BjYLGyCmhXm
Vu2Mt7YPszCyuJ+syWkBgx9yoBAG2mE8K1PLHEbMqI1ZtZURTPFlsCBoYTLqAGfs+94icj1XxAyE
cHq4CBDRd9xwgXW47Fm1BKpEtF6hhMYR3KGRTGEeMNe7iUwfqORTkK5C6bl3OPUUcjgNAekliEob
eoygNBhMCpyPELdr9XFjEaKweJ1cOLheJpTkCBeK+2IXDfY/MBQQtVMB3QnqCNKsqS4c1HBAoHkb
g5BVL6hGw0tCB7p4YRMrUly0pztCHmcgcziUFKoTO5QEzERhyAUyEd3nhQtujipVGBoPPubhsKp7
ly3ELxkygcSY0uKSj1BPy5Hovib3BgcGZpEcHZ3njxC+YEVI0JsbsAt8Qc7QQ8wHvO7sXhSc0dp0
fEwx+1i+C+JTw2izi3+YQAOC6IGYEbAeYHNCgwviLq439pSemBgsvI+IUYC19I09RQXA/LsPth9C
cRdMYIL4xOsC7HCKtOX3EK5VLCWyI9q/ZUJtkOG0l1EkAyjEviKWVXda6bikjGLuICFNHZcusSwc
IMl2pN+ZYvGxv3jKxoCumYX5t5LlpBhtxK/d5NcstNcMXjiOc9IniJMSVT1FAEbYGdwZK0FfPqBg
CrU2LR2jlhwepHnu4U+LSnmXAwCH2nLZax2vbL9wvUh11O2lK/cu3M21z7ltxUotBDm3LFxi70UB
c2pc4iQj/wDY8qt5aOWUbcklyOeYK2MQGluZfR7jkuKdLrBucN5ZoiU8cXX6jK4UF93scw1PY3xC
a+iDhqonQQGrfaImRbvlFLXjdCuIv8AEHqoVkKu1aXeUmFV55irYNeFxSIlB5Y6WOivQOw52NBb5
5nLY49QEy5S8pLm6Db7h25CapzX1LRa1U4ezzDknNV4vI6AKh5Sl5C21r8wzRY29diFyrL5iep8o
ecWeGDVb3GjJZV5iwFg1hvERVMQd0Nj0UA3G5G9WSlXDxBNzb1jd3NIt+GxWspg/hDHogK7WsWH3
uLec/iN3DyYHczowrD8QZhhC2iF+Wpk+4zg2AfoycsEew8RxlADhGEULYq778xI80rsRia7PN91c
Yq3yo3MDNnXibMaArYAUb7qahFU8MJCXesWbVj3qeOY1Pp0U64/ERaRpgcdBpu7IlTaWgZuoZbpp
cq2nxxLJGz7ACzY/3fcHxLYXstauPTeXiqc5lrYUA0WuIvsBSDVxsxV7oquPuMusmKofuNgQ3rrs
Q2DA4S2RgLF/zGCpCKpiT6bXyzBS/MGudhPD7iPanMUXF1BVzLlvJNgur9ZDyvPXqMnLEIA6hVyg
15ub2FS5NuynKQ62CzWsCTaandlrZm7GTV4Tl52M+TUfU5eTNNKCpVrYHH7l4FTaSvxAAQGcENh3
J1GaqXXX7hWCtS/cSbCOcZzzNtJ5FjjmPmLTF4Q3poZB2XXUo5V3wSh0wh0cRuaxabGoa0nI0eoi
LljbKeopsg48xWBop8kIpWuF8wzyn8wdV9yMjUV5x2Sd14g3Nw20wCksq239oLQFyYDeWs2UA4rx
QRbsU7iuz2cxolfd1D6wlLhIxGq/Z6l8YrA5RzedDR+ZeEja3Jj+N2RfhXu3xDqBOMYZbbdwIuDb
sCvF05CxUVy2AHIblb+KL5/MRKHVsDpG4sDKAG+O+YLVjQjxMWBsWNSE0heYLWDEY9QOi8h1jG8e
Ia9Hy8R/rtsxDYeYRbYpOUNUdaqNflLiFyLBpgMDkp2J1X93FK1wGWv621Ewps0GMcnzAViVhdpF
cBZLJ28XCdmyZNRs4uISJ5OYsznJ6jhK6YcAOivMITgBdpAYXocRUexbW2G10bq4yZBx4S73prJS
CNs4hmnmtu4yEW8ZYJXcimhCgd/cVoE4vmPG326uBGZw4D4lIQFbz+4XkbDxFbIeb2GlTB/IlehM
55m3aNsWtDQTxkEjCr+IzInlgo1odIerBF6jMzTWY3jiniD3Q8xGAu2F1GuL5+ZjKKQmqMRDMQch
K1ztlxcOjXYWGjvFPEOY4KGQNt9srb8we72NtSpWVecUS+y5vb2ZBmG3j3KsqHJ+8UV2q3Y1ILoj
sutDcum6AbI5VG5aCx8AV2tgoryW2xP24nMf3HXhFodIecNUnaXYAAsmR6w7u/MLzR55ZTnLa6Px
K4F5yvUdg39wsq5dhKY4cGngp2MQCtZa7ClR0Q0jxLC6msusj4LNAHDlLgwGCBqruBsDboIqvY9T
wDt6shS6oGsyLzPWww6uGRHggFgEcP8Adj0bG4TOtoNXFaB5X59XLqm17IweCNr+pe9ZyJ9MQol8
zef1yRAe6bAUiBwm4lSbTj+FoED3HADcmGNt8kYCXG/4i7/LRBPcZrWbsvDZAbcHQBLsyYYcaTcb
Utr1OwZU6+IXRBjIPbb5uVy338jDyM9INYrzxFQHpLhsRcpz8ynhx1UVJ/MKFX6ilULN1fxASnEH
uKXAG1dfMDqhfCvqXdJ6HYOeCdmX/K5TKX3V3H7VV0P8w8dh4sIC2NDh5hMbioyXKOy3wRME/MQq
IjJ6oMlMOtejAGGzvqCiZwCjH3pYSoqCUnPqOm57wi4V0bKQne09ZpnkT4GccigJcoauFDb3uGhb
F0iyzT3FwR90UwCt91xDd0LOT+J4a+7rzHmcOQ/Lc1S7kYO0vjYhRNum4b1BC67z3DXUCMalmCnE
Y+CL56hu4haayxTkPUbmpoOUEYNjdfxLQFE3Vnn8xwHCAudA0hyijC3gPuEtZQvcA3HQVjfmU7dV
F21EkrmiXz4/coLt9xUYtbfrJUgVHdyllgKcniZTz/8AgKADw+5a01RUK0wc9wyXJ2UEodkBACly
BD3dWRciuD3KJSfLucOAXVce41WrbMJ8NByjreQRCjd+IUaQeOIdLyQjfVPLiD67cx3Krg7BVRw4
bYxZA3GIJARdhOJb19yg7b1BtPmWA9zKGAmpxC6W33B2At4i1wlLgRhUDp3Fa10RgJ/iFmg5TiO5
UcusXCqPDxNC4C1zBaiIN13B11DMlALaFE23AoOJcbUNogqWTzCBUgjUvSorQQWkqiyUGlBqkoCz
axcbp2rUJ6g2WVDZNcg6PuPRcciGg9NiVZyRRaNzniLasDSU9IdH7Yd+IqTIXxzPowHEOmrzeIwh
Dbi2BOBDHtS6OJQnBaiXBHzFx8gTpl9WQVSWRYwPPqGo0j0bAafLINRjkeYXZTobcLXT2+fMraqu
3D4ZkIwAllFSKUiCwC8KvqBih9ISsZqhN5QoqXyW3zGFagkLYe/UqQ7TxxEtYPMvYqIqQ4glnnk6
O4zYCwpijGgUSvUPtKclssDTBoAIwitx/VPAmW1AcEv1sCtO3DQLduZEPSPbC5ALl18sdiGGcy4G
4FZUOTpmFigbRYlIs1cAc73FRnJRWMKTwQJzSywOmm3KCGg5Lheh37ikVgWyAC69sHXZMoCNx6Ae
4tGkteEXkXgLhQtgEtIWUFsc48QanSO+ZTRdwRGnkvJLQupRr9wsKcLCrmISlWYkQvNZRoM2F14B
fzcGiLIW34lw22HXmvmIBrQM1+pRiXoFrF2DalOPUU2r4pzvEakFmzU74h9SlY4hz6aB1KYHf0fM
4/g4LY9JE2LuDjClR/Rko3BdlKfxLeKtV4jabgQkpLk4ruXjL6FWQKEijm+ZyZajkLpBKPc7hXo2
xSC3haQTUlODIUFrg4geLQpcxJg1cB5lgsXQtgocA4z3FYdlCyozAdBtzktgPAfUAkQpC2iKMrS+
YtxjxPmbQoIF3UPCxbHBKyEDypWJaGm+zBaU4hq/Eo6pTzcbP5QL8bLoq8LHzHz7qFXbli/B02J1
oIDMrnJcCEqnXmNlccdRfoV4B0/Mo2FwHfNRSfCtftAQIAoXFDmEql+q+Y/RVlPJAiHSOAxIw2UH
+ogdKgyvMQXnWnqGIgNNOwtbJRd8RJYaj+4nIriuX9LjKqo7bT+o50W4UI0gBYxHftjTQeYHtVVE
UVJVTfiUmSJV6SnQ8HLssHPkigolz9iWErjKXee4Lo+pgh6hLlikL0LRB7h8iukSrMJtwC7xX5mF
TccG0XBQdCfNThe3Vr4g1tDMXUsbgLcREng/BFEFJ5seZdpOVm1f/I89KIjbG/lYjyQUdSx3jGda
xtrKfZ5V2OXIsdriRWFxUS8YEW0ZjHggREbR4Zq6GFVrBCNB3b55jLpRu+Ev/iUOd4YqpSMNsjiA
oqCJ5gYNbOa5Koq5+x/iObIACkIpBADbnT6lJcOhgQS6nP1MJpbemX4ikHdgtuKmqWwCu44AMQpY
Ll4UC4F2DyI8yv8A5LrYCqFa5IGhXrgT/YPCIWcd5/UFCdwFvXERiX114o+o+NegcF5BXwSLWd/c
IQJkY4bCVHwHgRw49Taxsgg7OouWF6jOamcRDNc4/UtrAX0MyRwgDJd9wKeTxBYrdbsrRC3xEsPE
v6nWFvJDpesAHJbIWoFH1DQ4XcAy6A8sHEWLelREVaEC2c/wD2wc3Tg6IlMZqnLF1bhfI+InxQfK
l4SNoKfmDbTYFi37lTDGKcMoBQpBAw8IVw1Dc6cAruanQJUK8U02yogioUiNov35mi3PMsUbOFpy
dk5mpRezm8D3FbeOIaRvY2Oe4slyq/5hoF4ZYIpt6jTg8Okm1HCcYo11opxcU6o28iMI8PQlw+F4
Q+LaDxzzKrBhkW4Uq02VsKFrsuCexWDiGiXueISy94ELvG7CVtpxSrjLohXtHpHFACMOefklhNqk
7nc2aEDWnRdJYScCjfzKhS2tOIhd3lOonSKrdqlUNCh+oepGgQc5Bte9GHcvjZbdWQs9xwjSFK4h
xdODYdes4IqwQGuHxB5SrCGudy4gIAA67gesFGtKJUi1KmH7gIPRXH8xnAWmaQWVdrlytdo9xeyU
vzL/AO8Kh4Aq+EJooLjAkFZ/EasAEKI40A6zh6il8kt/ktoW0S5CspCGSHf8xqqIui9xk2Rx7C1/
qYQO+cNS31LcwskUMfMVxm4lCScFgrEt4MlxSiqu8/2CyKbSo6AWzCHktBwjcHACADxCvbC/mMoc
odysric+o0kGbxHAFA/UsxhHIge0LVirqKNbX5yKmKFTPEQlSYpsEZcNpvYV2sZ15gn81vYFgFhn
MRAR1XctEc8Oz/5BFTSLkCRasqWYF3Xq4J+ENsOKiKBdZKaGrjwIdHiAKPogPfUDfxH6ATXghLg7
OV5L+M8YR5mcpVodsCEFseiO+oroe7nQkEbcvQol/EsE5Rh2CguUrvzHsoSv1df8iQg2cgeIKkVo
OpWSlteR/srkbcetghC23Fs4nEj1PcT0lVjblzi78wRTj3DMFCj8xPGuBT7jrzF5N8QG49IuouYF
CuBcIK3x8eY7AtQd3/ZSHbK+U6LaUFVRB57AHhLjO1pddnECgQJRzKQrJrS5r5DadVB50aOHNQdl
cr8Qsroicf8ArlGiLVqGhjQcXHjNTN0XkGkeLhj0h484Q/5N5CZwQgDVxJaRKUhDS9lVUvgo7t/8
yjtBIDhgkAFJV4Vi5KvCOvBBOGFQ7QwzsID5kNshnG6yu/8A6h3wV1XMslr/ADVGEsrVpy/UG7ck
nMCiBoNbxxGBKEul/wDYCQAcOMhdwTxwB/cCC7KVsOEVQaQnqEIdt+wgI0YJqiuZSulHvUCDoKPc
XKj8d5HlkoeK1PhEDtt/cMwXQ4yCmOsvDwxAt4vmoSdoqOYLscxmtZQ5AeoRYpgdtRCVfqB6gZmH
fLzDoMFOueIZ+9otNgInbvG/5GfCWV35l6aErgg6MwVvffzGtCQRpsBKvCO6l3DNnsPFdRtFGy8t
ziIgKy2BkJ04N5g8lLml1kYFbd+1yuEVOdi8Q/uSMbzzKfLmgabKGCxRzOFubwLuIzHgXe9ziBc8
BXiXdgLoEcYhIrYRkEpRbwZs2Lm3Kl7E5KEvl9w14yRUpaghkBQpXf8AkfmXjHrEKj2rnZpYQ6b1
CDNzEeVI71a/Ix1Anx99xSxFGuoxua+s7+eYc0USnYww6JBPK6gqYbJB9fmGLarae/8A5BOIU8VR
bxDSr87lzFXJV0eSAQrNTgdP1HC3lKpyh+IudTSxxcUcqgc0rZK91htIpHCQJadyjB/f2H+Z2kVL
zbEWy5YmU3zNp7TknKEv3E0YRLp08zPX4lVTXQ9S1zbmVNPca9W49RAkNMAHwC/UxQAAppnUVMbG
3BTGMnqEylm/FQMxW3xGuoKPFwqhZn1k5Zqx8RMyVyAGupD+40TXoF5jRRxwjrA4fuVLQV+ZsCLK
fUNKNnwGxGAcHXEqw2cAYkNpdvMuj7TRQPlc0qBI07EbRIxdrqCFWGmXf8Q1cKFTkI/iEUkFqF0J
D9zJE2PCFttYwoIr5ceoPrWxeTId2GwUhFP+R/Tyr5g6lip79zIAITzBjcx08TmGiEK9SmwzGFfM
BFShbXPcrMlrVZEJqNeUoqDCzhA04GPSZ1Ewpb8SyUS15twEdRgVATxMoExAPmBRQhUuThguJ4qn
PArX+YrMLolyaFXuU4Hk/E6BMuXhbM154lNgI+lzFEFq8S+g/PUodxct9wEmIgrzAuEtFjYJvBNo
TiM+BpsDsPJjsr+0/wBJfzbu+Y4MC9wEStwgaht5/mJmLLumNItDXwy+zsHxGCJnUUval4RCu5c2
BF6m9N7PqZfLb+IY3J34g+gz/WQy00HhGGrGn6h8qVLzGnpzSt4loZVrCvUqYuhPDA0BVAfU7TN4
e44iKl7qXSNciwKuqbFtUuH1MIDRDC34llsK4MiX+pr5du+2UoW6vRLgwLS6qq7jMCmSlEqg10QZ
zarFQWRekO1Yy8rnfo93qM1+OBAKuzb8xyAsRgUeMpUOm4dvUTMq2KfU8Whe2XycpV+onUKJSHeG
U6g7OIuxnR1AEYw8Rcg7yJM0NeN1M8hs5yH+IXVQ8qFtlGLHH4gaQ+nh9S8Gr4CoylYReya2aYQT
92NgrA6hzCcJiVe8qVJMPjO5qgKxDalH0V3FNS6/2xwuLpMl1vHzUJq1LKfUGSzNnTc84AOfmGqg
wuPbqALHYgbeLzpCClWm/Ff/ACEiGhzbxDdoC/UB6rH+YN9IMfS7/E0mlrGYJAGTDj1cJMYH72Gl
6iqpmRQr9kyVaqM45jmQMeS62VGpb+UrB6/cP9gQ2jZ7Ih9sP2DADnSyx6CwvxLqCkuS/mLWeobx
s8OTEsdFFepRzd/BohVBVLv7hYFYPo5gDAiB2RgVy9PiBsm3fWQjJEnewXHAP0SwLJNccEvKah0Y
SguoHlIAi7U9sZLgoN5MUAIjrUHhEkimxq51xKUom6bs8kYkEPHKz0EQhZQseuGUeIpTqX4nDBBA
UCXJAFy+YGecggKaAU88wT6oq+pVTvbnxHYwKRjfMaDVP3xL1T3MuHMVIplXs7itGWweQ87DYCeO
uIgQndxuPfVlzKqKEHBtiqxJ+hCEoFBxZKunhSnMIkv2g2srj4eIRY1X9UQChfgS2uQqs8VCTtSN
dbDBLH9kS15eMtkJKXwndpOmd1/c4UKF4oR/4Cs5Mahr+dl9yp3gB4LYFXtLtHcMNaD+4hmtQnOz
mdyVQeIL6EI7LJbQVD8XkuCHMPSXB4l5MjoNR89MuWFCwL4FhsB+b6+uJ0UI1Bc2PHxyy/JtJOni
FjiB9pULA1RtYV9xvd7SkuUMYQuAiRlRDuDX9xZlA+wKfmUu20oNPj2s55cnHwm3FeZSAiLZVbDd
EuNnMvixp4iKuqrKno/UDgL4hpGnpgooaPcKTm+CBbuduKTodvMCmiJ8/wDqjWwF8OJcYss7I6Ya
rfNQDXyZ6lLsiQ6GLYG7YvdQAm3TUcqOh1N3RIX1UGqKqHtlp0K1xxMFLJHcolkY8XCiugjOKi6Z
TxyUkr/sMo2Ii0ZXEFJu+oOI468wSlWvU+QjSY2ShX1NJ4nATZTxGszM4Zrtt191GdgMCiiNwKig
Z+dgEqFkTDVobYNR8QrKJZUSFdreY5m/ZtiUahr+ZTw1IHiMngIotsH9QwgHb42pyhAlsbNHEIA1
RQmoUQTT8y3JiK6ojQDbVtSxdOAuQiyLTnFKoBVj+o3NwJEhcNd62N3Kx+omNlj5PEpMjNJBVXLK
lBqX147fm4LUAVz6lLQoR/mOjEIR7qX4+LXctvIs6PzERjJ+UsIO99L1KiCCfcf/AEx6qPBrkHGc
RAgO4nKy3nY1YqFTbuKGqyz8QGNsAS7CzbOoONLr7iLUhoh6UUb/AJjwqByucgcll64iKrmVs39R
8V+Ilyyoi1VAGuHIcIBX5uPY0N3DDlf0DmWGWxa5qKy1aEoM1ortZhwmKiawFsXqBnMZ5l34oUV6
hG3ys9RLqpdfBG8pEV4l4cDTKuMywC/qEWvSp5nrUTUw6YzcN/FS3mms+24mIJWOj6iwlQaNwKbZ
dJxGlbCMOjsfUGRTI++ZoEjfiHFsAxoMJbLBRhjJxwgStwH3CLPYQhZOLzcq8bwaI1Zi1EvYocAQ
eEvYOjaV5g4lRMfcb3LvmitnhIke4KMGBpmwEXtrZDhHe7jF4HadXMLVAJaCfAYncv5TgpqrgEop
E1yVHLVOOPKPFR+AqIuMaLqIHEXC3zKJA0ZBSC2Wjw+Y4gAre9yPkAvGrqWdiXTq+J2EQXC9idXT
cvet2fEuxalL63iDVspX3GtppKg2jIDh2Ve4FeVcikDrPPP+y484n5SlgKUwOBbhfGwyKUv1lgAX
XSsD/wAgv3BFnbbVRMQMAoSGKBWvUYUtn5ITnTSYRv8AEpRuVzDtwH5ENOw3QdeJc2ncCtXY54u1
3YsSaGho14ltJdDhMM6VO/qClTQg85ONjccUw/1BWdxKGFBfuLuZ2Ltr/kdtlKcheZY8LhLMhCww
vZqcNOvCjA8AMXeMlZkJDccIXhcODvt3B9OnQWbA1EQ7tXGhQ1vClRq0g1BpHZWJXEOTFtghKNfr
nI5qBLwPb8RWXbLsuVhgewZEXC31dyNzr7l42DZNFe2NmWIPqJbuOwNuPiMAfVVDsVVHKEUoGXR6
GJFRC31jVwwRQCNjeEQkiQmfDDPKNvaNwqVQ9NgSRbEOSoIDoBwbiVqUDsvn7dEt/wBgeq1EhpxF
fqKW1dQLMdfFt9Rz5416+ajcknXVyqrrbop7hVHuT8Rv5dHTcXgvRG3qbr+8NW8/mHkoLpoHj3Hw
UKGuP/kMYsnWrGX8geY8mORhRsjTrzHgvLXKuLyTUvm8f5hanVswlu3OczCcNwSjyNAfEAMy4OCu
IurtS+aT/Idq1bavY9z3ldXWSpJAbZ33AxgSeF39Qk1By5oYxu/ltvuKvQeEWx7EVF0F/wBlSmD8
KbG4PymG1SiyvqZCEHTSiJeoG4bwfiFmAMNaTiFEBBLtdhHrY5lCv2R6ZqFgdy5XWGuJZ5+BgouM
fQzhF2+JoVYBxzA0kQtnD4g4gviX/wDMYsYQRtq5qIpoq3Z3GhA+EKAAHTzLbaLypr4JV8V/9iBs
r7QWJHnkhEWM7qolIPu5uH6a6GwnQBovqonmm6v8RWVysstjeBwr2qi6u6AvguIcid3OQGGjfi4A
vRmcAAtxCdKzYuCc9w8JOMGOIPJxiPTUdCAMr5KLQtEEm1GrVrHwCVVGK6/cYkJq+pTABN7yNIaN
MXQ6D1dQkRYt07/sSyoaRthOpWBnMCO95LRkrCcV4gI24R+ahPuLpEOfVTjBdIkfUAAeMlxkVVbc
CGsb0qtgQOQPaUgTXmU1t9suWAIPKtYFVTt9bFqtzkLuOx7AiR3eWyh2haeYCFoN9lQRGy/BhlBS
m3cGpYAPcKzSpfUcJu+XEpwPVOaiCGnBkYzysfqVLV7ImXzKXY0MS0Ildwqr2Ari0sDK8QZHXf8A
Mf8AKl6hZVGjYMlooQItAcq5lHfcFpMmoHVEqzjuHlNRe9gDq57xcrWihUAypo+O46ydml/zCJEa
13En7LtWHT48RKWZGNovRDNOAjUBPnqGEAm07R3aJT1LE3m88R1Zb28VDTFtaOt5m+7Lly5Y3dj5
hFu6s7gdCj9pG6UAs+oBO9iMZraoF8Q0qum8ZGhsXqG0LPDCJGhpPT54H4Q2w9hcs0ht/CWlvGtG
N4HANzT4XebgB6Kmq7uAoqkrsqX/ACAt34hDia25Kjw7sL76jVwmF+oz2k6FQndJiPDCV44g4Hb9
OsWsTXPMCuJfcgqDaemwyx5IAJlk96TA+I4iC0KmvEDDXvqwBoMBmx3tRXnZQ5BPBIC/FLjHoI5v
ccOnBdFwecjHEC6xAhvzCOBrfhIl09eb9zC4fVQESBF8XGtrHmC02pSwLY+4DuhF5muFXDYRnQAY
ilYugrFAXVduuZfrGUcXU5kmk9nTA0F0HEZ0lSHLHFFWHocYAXujckcoFBa7q4iHLyj1GQ1/PRW0
gq0cLechtVe3jL4KVq+YCykqeJvXShfzN3e8p6YyZAFgKtMHUtkyw+YCLa2Z/hF9AKFuQxNABuRK
NXTqUqlXTx7lEmAE5jsB1VPcPhEa8MDXtBN7zKQT7HmDnA0jyQMk1JoVzMJwq76YyUmpfBcoiWjk
ixeK8MYw06vDfMD6K6vHmCRaYOXsgNFqY4AySedmUiGxaU7z8Q+csWGqiwblr+kMNLoCDWOOM8PM
ZizTwxewAnnPPiJigGlvYIqr0qtXiOEb0vqCpYksPI5qa7ARORlAMxvkvf1CxNccXiuIP6qjifMc
V62O5SCQvb2iCggtV0VBzhiHk8XLv60KgPM5u4RuEedhzbLSxPIDxUQDmsjx4qUtdIJHb3wCkVsQ
7695D4sB4VCDf6DVQ1hXiKf1B32U8SXKnu35lRYPuksStrM8RZSpLcRlCoB2EDtNlnHcpqqNqs3j
fcqxKPBjgT0NgStY2BVfcf2zd2QvaJe/hHRyYu193HkeIci+cXBqmN8U0Ua4/E4l5Kva/wDYvuJu
xgbMfC4SF9RpyHzFjaqVYaHhJW2OHgAat5ieepYqM6HAGiGEqKHB6WavYGobeKiOzlrj4Syci4M7
bgECvUHHa/Mys+IxgK8RbsicC7/UPIeoFJazj3LGQMN1laXYAoKKXTzLCICIbFbO/M/92JVYPN9Q
iuhsCPThO4VhExViFWPiJYFJCzLWUyphKw23mXVn/uRZaAVplZABi5TmGhUAXT7nlAF+UMrDxQ17
nloRyOCyIWjqkl10y8hO+OJWpBoFrLFg78JbgricQ28DKxpzuNEOIFTD5IqHgliWb4nJveiKtcy1
it4WDRgsi4rUS7MhYDBggGVeFY68y7qpQA/E88rSo1csFY1aGnY+SjlXb+IYtKuoHWxdYAeiWtqX
RJ3mXkpOzmGkeah5I7XpB1Svh8wR6ikWxIFWnY34gU2Mr3KbDoNysWuUGXXcKKypp0KLYBHThLYa
mLGZL8NfM1AG3LpLFBsCAuRvqAqobpALPi1dxwNCUX/mNJN6t8Sy4GalSoGDuKLSuY+aPPWdafrh
NQHDtL1AaBogzzi8r4jNxZQjxNRW+2bZGlG/iNvWNsToDhplFe8LxEoXebOI8inUoAoLPMC0zK0Q
LhyDh+INQhahoD5DSFSo52TmwdfMdr3cJ27E1ruaxwMsLK7o7qXFQ4WEHMnEjFUNsvzL5LYtRX5t
jGaBQoFiDdUnX8//AIVY3EDf3ChS8PdLxDuukKqs88T+HJEArYqlDhbrcCzjgReA9IiZKg0XXuMa
yoXqDgFOpXylcLYUlxZ7XgjO1DyMuNQNYNpAo9MsE2pF+3ZEG+ugNxzYHVxt6hux7gMuCnLPUvpS
2jtMHLCrCwRI6gpX8RIUL5QyeQCb+4MNy10t93C1s8oifPEUdpXF9EVodbX3zOZqqzOuycORQ8nm
UXW7u6mVGorfmbUHSL1K2vcO1EjkQvH1HUAUZbRFy0Vm3Aq2Nm8Ny6WdyqxbTiPPfUv4stvzBQbe
Ia1hM16RO4toYF9gPEWTVaeYbCKfMuLq2Wc+IODRpRsgVdsucSxoevEzauqqp/MwWQEopsFpc+Rf
jiO6hX+4moFzRt+qjgn0AoPxD6ahVon/ACPq05uKSRjRx8xss7bYzSPGrZA1NGiOwKVLi2MKirey
1A1sPXbgy/iXawLQoiSFW7Cnn8QjxDwHdI5Fi7DjtClq9dowSu2sYF9HOB34fMqRgFv+xKNtJNRg
xOc4d30q7+YivowVlIUMy8lkK8pCL3JF0vqFKleZbVvuoHpu+0VGDmuYR7EBNmKih1xFKV9Li623
zcJDvwcw1cCxrg8w6nV1T5gUrxwSprmOWC3iAhuo1RFRsZejshU+h4SvD0kVUxbxRon4EsPuIzZ8
RSaFhdPxEoAa6YsRvoggFSrHcVVFpAQiI0l9z+0oJXZfIWPUOisGAQ7Vk2j9w3LDsS2yAO5+EpAU
y6gDeDaC56ixuEeYGa8MLqPpcZyIRMPAGQb1rW9wSOYEBT3kWiHC1jt5KYh1dVKZ0kFlUgO4AdZ0
M044DgYZrColWwdecpImm9XY4IXQVfyiVQaaRyGQrR4oUljQWWxKLqXqW59dePMWCtwV6r/7KLTb
kAnmaeWnzFLS5Ay5ZaqbxfiDxj1LgBVpZcAQqd85YJVq3TFcuyxSmw9HHmbDW9TVgzzHkbFpWo+G
E8bs4Zu7XZD1OC5A7zJrNVzUovnY6lHsMgfJ61TAtuxV1DldWp0ikVqXXENA1EIueO3pFQEwXUsG
LNGDhLhqLuKWC8O4P3CjyXONtesi19ii+WUT2LaIp0C8RoBKVjqXh5hwGMw0KuUEHLmBDSQCa17h
weLdlmg57jXoR2Aw7igLKKrGtqUATOd2UlM1hyEsSDaJkKVZwSl5F3hjF0tqWPctSwjJQzVO5vFK
4riJywBG+tB2UDgaiooTo4jW3HmuSZAA+UKVAPLHBhykJqBGqbc2G1t1B4sXRKQHeiyQ7j+ItGpd
Aymhg15lJP2hb8wLwLqH0cKr3CCZcMGxtqKcIF3jgO4ECxhCcwF0HI486zmGewq5YnGwN4Y/StqZ
xCIuvEs0aLOrHSgbxDvTIOZ0JMzCOyVVAIeip4S/ipb/AKmIBW7DsR6dAI1rQTala4zQ4zCgHJka
z2AdvUdogInH4gtgLsJyMDAEsNxrLpNA/cTzZ4OIWGgtO4tzTgl6a9ANYqFOB4uIu0DgiA1lK/ic
kSLiwhwh2V5nLJKgoWqrIUlQWtlco6qQc00DyzP8BEYTCVchsfKUpeZ2+1r5h8ApMqMKDtVLXm1a
CEOweaipfgO5ZHRLPK0RcNyBYjY0REZxU59QUXlouPWRMUcsVZS3U6jP1tQnfEOlzzu7X5hluiv0
mBAG44R6MPRngBX6g1BpK9RsK4l/Q8O5WLCgEpEY37sYKjFti7cQeuLoghKmhWsvnis8ylysBV/L
LWXgpYL2Bkb2FYwsPLeWfEbpzgOvMMIpRDPiUchTkwBNSgj1y9NkTg4iEeHxADwd2BFlpisvmEwX
g4J69ykoHPL8QYjcO43uDNEQC71mrAllXCFlKsQQ4dcwxg5bYuiAKkMXCUc/QhCrqcB7ioElCbhu
qsKSLFK80yFOHiyeinFpKhZEaPkViU7vzKEm+UQAHwG6hK6vqFICiWR26oRwVMQ3QMNjW3tB/wBz
gXDdwQ9l0w+pbu7ymVLmGwrt+bgWtlagPaR6grkbGJUWU5joRJhxB0FU0uyCOlBDiFA49q4kR10V
Zy9ZEfE/2OoekYEmXx9y98AIqHnUC+Q+79ypjyVVT7hbTEoIFdx5FGZIHwGpoYXoUyrq7iCo9Vr9
wcSkCDI7TrKlRc8xeDiWFopgaCsH5Sj8KVDYvEF25xgr11w7JQ4vRxKppKSkYghMU3DkmVLE4SLw
xpY45j9GomNcwKwqCvcaZgIpXJcQt+LgAyGNHydMPGRKHDHO5tWxWMcBEO3cNg3oJyXHZx2+5cza
Qud1GvRMR5h0u7Upqp63gDDplLgzQpDc9wZGYvKKI0mKV1cpijjdriYhVRHDFnnAAqB6GVXR1PMY
CLAYly3Os8oyCroABOPMYOUeG3/Ik5icT4mcVgiLzGJaN+vVxL1JRbz/AJHfJCgFS/8AIB8ZD+BG
xB6nMurh2gfIH/7GgSuUpuRChK+Jbn6gg5vpPr9RWaq9WoQz5XgMXXzsQ8veapyfqC58SWTr9QKa
rE1wv3GviHmi+YOzodD/APY0seCKFMtmTp3Xk8dQLTEKAmvZFiFBMCBZkQG1kGL4iu2mU8svlbTu
sjG6E8QsX81UoIxsMGAHUIrEgediwwgiZWRnY2xSa4lOwPT1LnoIhfJL6i6pzHykuivBKHlW3xG1
5vBmQWouWtZvRXycTWAl4RgO6okFxqcHEPobj8cyljUALTI5VFi67gIfImiViTw5Nje+IKAFb5gK
PwigLluTVe5VqcTM1pDgs9Q4I6ye5dh0j5QyA6ocReXoncI4OsckBcBSyJSkK8wuOKARd6aWVTt4
/lDAOZDY8wpQnB6mjYKsQ404B3BjyuuGXmetkzKxalWySiAI1BZAClLq+8gQEHCobrGJkYQQMVkV
yCR0hMuawyM5+KoJoL+YKmyqjupgQa4dxYEdpwSlBEu/MBSGIM5lePIJCiCUTxFkazYfMDAW111D
uKq7haCdTnII8hae4jwdE6lLje2F1kueWGuPwQSUfDIRY2B4jsKtq5LhAujeVdQOIuiziL3UoI4D
2K0gDN1iqECynMayrsCx2CyqVVVNTVPDkPBXATGhV5KEPMSjtQrzCEMoQoJwJgmN+kXxL0Fe5W4B
x0Rf0l1GPaw1zFWj2ndSrLAPcYgfimp7Vg/qqu6uFkdF1DboKJnzMP8Ap8QfyXVFcczm9JU8QAEe
AV1DTOx4jraFXVnENOS/RLgCmZzDtQ0fidoEScbLWAPEEgLcP8qb4mOZtQ5J5xtfBcTYINPXETwF
whvbCikvmGoy+JNoyi5hacRi2Nr7YfjZXEXNaGgoagsRgF28RNpWWR40F7JWvGljqWZomnEf6/B4
lZIGI6lsN0Lp5lnOlo52DCmwyP8ARIveMGWyrHqdxB3DGsBJY6PMfNfQIZizgNvq5dtPqcGUMIy9
S0JQMteIUecjAVWVtUyzEro6tBGkIaPUBOHm+248PiDmPPdtHc01xc6PMMVz05UyJWkYeGkUheY+
I0oQQ88xOBcFTje4gkFtq674lJwyq3vzcvmIVGqEiaurL4eJaexfiHpQkq2uKi01WA5IGZfIloaI
HHtBi7U049QBGmeyJx0Ya/8AdTMI5rhvBiO8orsPEVlI8MFwOtqvTiFDRGdwSU5Ev5QCGGbiiUoE
jOc1sDrgI8RI6AH3KjTBzrGebBIJx6AVj6YmxNVVvO9wftInl3YKw7NAPBexCdG4aytZRtNcECm6
WRqBtTB3tEEFrIefMY3Gy68OeY6lOYcH6mt/VJ+EDNmKfUevVQ19wXE2t5AU5VsUAduxGlYwYdIf
SQq6lynoi/QBJyXkrJ0AcEJKtalcEV0Vwy78wYehuQIEnK44alxmi8/Sc1N+1lzVi9zmKcFODlUo
iylXi+oMpGRMtMjAZpXGQ+sbA8Hg8xTKFHmNBXoKjpePFi8QCu60ZGqIO1dPCGKq4NI1yRn8kWVd
qri1Busu7lNDEVNMnPB8rQMJCzWc64/+RvZCgbqU6gBaF4gtSl+f+4UVwmdxQuxqPNIi6ugp7jgB
eN07Fs0Uf4IJ8gjAG+JfNgC83OUh6uAKS8xpfm1yvuJOhGFd8fcN9dvDYRtZWVYTUrhG7B8w2VTa
vuAorb8KcllxNuc3dRwXBb9X/hGCXx38RZibh2qyjNKlwRz+4RRNn9Z0e6nwQYsJdrpyW3gOvaqU
hWFZNvm+4thwsAAFKvMFCsvm5oOVaqMFrn3K9JbIAW2EuK3vucg30VDbOC7PUV09Qonip9XAPX8J
gVMI0t6WFkdwPQd5gQZQJ78xtQQQlmXR5l3PTiKUilu9R3d1hCkKT2jAIcWpmmeyWA9iIWaKkQ5W
y34R6QIn4lF5nmbHiP0yGYmy5kWHK4XR+oUHCvuBC4UxcGyjMMRAcsQ3b6gXaysd4QWNG7IIDvdf
M0oDiCE6FYJUlaLGAKoHJVArSfKYVPBzAytgHKjmEwoJyRH2XXOyMOFStFTVLFyBakBEGym5U+OE
VLLhcvbaH6h1gVuI6HiX5VsDsjeBPEFeOYy1tTd98xy7wKlNADhKvdWtZa0jUQAPKES0/EJwuoKM
Wpl5KQdyqjA6Pwgq20O/iKootnqIneFPtlBdpwfgmHAR2VfovuWrsKFRxBsK4cOISgsXdgjWwJfc
KAEH/EF40PPUUG+KtmzjniooGx2oyChqkgCr2fUUHIQPDBcq2Pax5PdwAUAGufLFg7fKMxbdKgCD
vONQrqINWijuCGFGg/EJgBSVOaXeY1Vb2/UIAI/RLqVdh4YZaa9fERAAsYlkG2rlBTxs+4TFECt8
RudWUMoQHNe4Z7Tv6ggFmxLwF2NfqALlCy8nX/ZxqSxzggZ4jsV4YoQpEfxC7WkX3K6ZifiOuFAV
ME0Bw7S11xXHqcKBJYpoo2AKctdomzRi4nUGnP1HJHc6i87U1YAXq6j636fEKGIn4qIek4S1rV7v
RMIbajl2K0l1M+bjAAN6xR8ot8twsOGvmoFJw6/MRzZ26ljNGB42XYBC07RLG13LA08+ZaDd7jZu
WC/zHeCh/iXpko8RHBrN9+4SkaHTvIpQI0HVvJwrAbxsNfKAeMyDHmfT1F3lA5TiUwQo8hY+07B4
al3SDUcq4v6fAGJoGC8wlCqxvc1ugaNJRKPOGxVbLGUIL/iA8Qi8viFWw1TfNRpa8i8qWIq6C79J
f6TbrmVQzd2QIOCP6j1K20bflnPWS/ghS9hAcdcShMBT8kFLxZgtgXH2loP+AZbTLdpcLUpS3VKN
qFW38xKXmjvYORKIq/5jDvBALXxE4zwN+Y8mxk+C4gaEYw8xM8JPqIhax9XDCkYH/AsHqBSRkHXx
AxDj+VmKdAWlsGCPj2kmOV9lrLRQEXXyhcK0LGZAzKWgo0lwagUplAlKzGgUiHyQJjnp+JX6J0bc
YbcD9QqelQ7HJQAAVBLOoFpEW0+IVtsARtDomfPxGlAlfwihSA/MyeeCs4jlXzFvrt/mpd3lK9UR
pITyC8QpcC59xALLoV4plcIZSw+YsVsvblHtq1icXeRd+YCOEBp0vYXkuHxkI8nh9S/6hxPCE3wB
9suYAz9ozkpYWgdiaKnW+aP8ioU2v+E3cVhf/uRVlAKoWz4liHgd8bAdzfD1/wBTIMR2JipYNR+Y
lAL2PiLGSlmo1f4h4NovTdH+RcoCA+YoMpaBbwlh0EGl8XB5hdz8wHLv1jKWwoNHDNu0nwefMvNB
Ap4yExXDsH/EITDLxx/yUo0bcVzjgXbV/qE9AXdXiU0CYL5ajAey2Wcb7i2rbE2CcQCrgcwC1gSs
e5cAb4oKlCNf5iCQiLaxRJY+keYCCVePF3NbwD5gI7DC92gFdWhiAMKcWRgI+o5gsHmcOLT98S+S
q4/Eu7mlTj4iiUIXlJt5ruXmIKX/AO8Tl5Yr5lhnLnuBE0/uiaMKoOJtcVxUVtB9wC1cQvXeoUtd
TU3fUAHFxBKPmBdXT7mDLiAobBDwuFtXVn4huUHvmK9W7pgxhbqE7hIge762BdWXqoEhCEjXMbau
0Hw3pv3KqWF6bK0dduiW+S0q54kC5HBxV0hMTYLLgMVrOTmNaGsIebqmkIw9BAqRSw9xbOHWxDhp
8zkPiiRizU+0Jx7uIjNHBrClCKzi3KWhF7FEFjiGlEL8okcXbY/pNi6dyJRq7ackfgr3HN8L+pgq
PH3BpAoJQtsYa9Bwe4T7B7EWhq+JZAqrSOKKChiC+rjtso6gkxLjnMCpXhD5KM9RCNch3Oy7hBAJ
tcy+6yxXmpeAXCvccW6PwVAwjgyyHvmMVrpk+4XysDzUvuuDT3GlyO3xAQSJq2VrSlfqFm01Y5gw
SYF3FwtS2fEp3jfSXAGpRt+IoFgfjJWCraiArBKyWYmz+Y6MF8gACAuscBui1YvAi9O8j9QA6E9Q
4tOX+JhUSSiW+CU/Uu2bRB0s9/mMzaMh7Ixb3GhU0Sx4lNU8sWxWnMfcWunzfqFmxZvkl1w3TUK4
PL8SoEC2F/MQXaVUw4PvnzKZaBQYgKUblZlG+cVcy1Gr7yVA4sB/MBXARuN5mHl08ShaC9QrtT9w
FryPewakUlrgngutDzMwCp8cwepbUPqLsAp+5SJoAPURZXpTwvMDYEOTtD33NeQyncSg6AaDJT1O
KviPKtu3AMY2P4gkWEPeQ4uHi3VwBWVV7R647Ty+YhvsUOCIehH7jGFiePcsCIQfhlMk1W8S0xYQ
/n9QOLEuD8R8JgnL3CQwLB6cTbUZirlle3LKuNWahB4uZNQwd1EA7dkS2/iEj/NlPiCkK94plyHI
C57gTrDX43NKCopyXL/AjrLXIZ3Mqy954gg1bl2sayRh8ykd34PjDN6dduoKxDv2uCKPtPb1Gh2r
W6yzFWpHDxGSy2VR8hiIBPGX8TYuwXqWQppTB8kXVgt1eTZAZvO5BsjfDxsWsyNd4f7AfAF6V8Rd
gK288wwFq/Nnj1zKTAA3g9XLfAWPSAkqVu2DLuFpOQKDsuBNBvfTUa5DQOtYAHcfZkGVYlfkjbUn
vDx/sY7jHx7h0oDQfEClmB5WRam3Bqlcv5j8DFU7qoG5Vy833FVYB5hV3Dr6cG3BiFaa6doIOZJz
WsjY1vEV5ltPGnsA/qU3S+AV/wAlNhkX8IRENIVcHiUW1Kq7yYsrQUiBoC8Nx/2WUZtARhAQOwAd
EtIHHwDe/MPoAdmmS75BPpH/ADYtL/LBv+HS0INFI6rXIZRABZo00srH4RkrBW4U+ZfOtOVg8QkD
lMA2CRzNr0yOXCV455gKOdWCXzc803nKDPQV48i/nYHfcA6WvXMphJKIsf8AID0512DxCVPsboG1
Gds9oL+4Gk9AaruL6bzBncfJxBay+Rj/AAsrXF4+43jMksNE/cbpvAsNP2yxhDAJQf8AZXStHgDx
LxsAWgrINHXC2bAwBgNoC5/EaLDb9xPuwzmpSUOe4LK17mC4S0FHzPcRRFju9xU4AW2+pZ5nMBkV
EIwuPKNVmNkTsgFsI/lWCjzWfuYgir42CdFB9OY1TkGx3kmsHrpxcEhBZLxLNI62MSTpaaw8MWJL
9IohhKQBr1v+xy+PGGoFarahfDCufMZucEvzDoFLMqG+VNQK9oyKaRV1aqDSqNzuFBAK5WUVVLNr
vOosaDucy8eJZsu66hVqw5ch8CnDYtBuBlxFzkQ8EPKm0zTlVSDV8UcIKtWi33Bbww5GAmQIITh2
tVgBt7/eKCp4cpdXA0pzBHMptLcC+wIOd5yLjG5Rm8waVKsABKE/EpUN9b7g0OlItXFHDCuUaolv
OkyFjyig9vZbsNaIlKr8EumjTVwJMZ5iMELV1zC5TyeqnCMrjE6EcthGgcxSqw76QZVcC4S9yepR
PqD0YOmAcLxB1A7b9wUuuW1ZUapjgiC+JdbDLqteyUrNSdlHaCwcwGJ5mcSwDKlTwCVGtCx4Vcq9
JVI7CIsL2EiNlYxWUbVnWVK0NQrLr+gh6Gh+UqUDgu4Omi6mpcAWm+kNcV08wURbqxhzC8L9QtVA
pdxMB0BlaugFgyKgUfMZmFVjQRRls3EuMAaHpB4gVLCAuprGVX0ZruorJVseYASLdmDSdAVwg0L2
uFkhFAeIBaKDvJceEAwzRAGji4N9pYI9wn3LHWUklO7rCAmWCioKqu4ZcgBaNlw/06UPqEsBc7lc
Mai2kszIFSZuwgbSgKPhge2ClWDIgny1YJVHV7DiLQrS+oFYwum5QQ00X3EJYrR2N9w7lflB8xW6
QlapyA6bBw6al+UqUgvEdlCtD6hAqFnNrCeBAtM4lKjKy4oCo83EFQ93GNGVAZA5lXCBKtEFZhAQ
eIbXZ45p5lRIoWdypLUUOuJTOpRvYlPM/wASqUjUpA7+omJK5I0sS/kiPgECX1ED3SWZ6YWAPwG7
lDQi+L/7HbqNbIOynIv8Qw0wX3rDLcu1smI/khcaIU1jzcCYgCsa6i2HfAYrogtWrJ3gYlqGJb2o
hMzNMLBIXFHFXiEV241evmH+pQu2WVapcMlJoBWNJgg1U3fjJoAItWXp8VKeRK3k8sC6RQarnMpm
sqy0nB02WumG5SUNiXipywxTftsTADplXAmiF+zcGwfLF/2ChtaEWnuNZdjs7BDrBdXv1FANk3ud
JKDtgbTawpWq1lyktBwveInexNtUj/yXvmulYnVPws/HY3KGpd1x+eI3e0mVT9waJXuJHTwnJ8Sq
xPhu07gl96XTxLLRlnq49GIG3FShWuwKKAF4hi+cKI8IBS6y7+FI8+EZGlL4EtyPa+ZygOiwlni/
Y08zkHIHxBr7VG1RFdyO+Y/MOwEseI3wUHh+Y5Yp6B1EjmywaVH1uAnubuka7/UKDALUafcEQyD3
6GZlAK9USn5pZanmE3ClVhA59SrqIWcvUW1OB9PTBQDSglLtfeO/cKwhSxedi7kC9W+TjxL3w1vk
9QGDqhnLNIXR+IVw0NPzAnJX+HIuXQMug4hChCBpOf8AYUs2Hq7laYAZF9C2hWsuKHuZwF4PmEsO
obbiVKoFlccyuGUXp8xNpwdgm2SzqOxdDDzo4K6Ie4hHTMqQLpZhi8kZvKzaRogL3aRFGrIB/Agh
cK7gsK3CofErwI6DXhjtgs5SOopKJQefL7jSJR5iUPPqLIGzZ5NEpS+vxBPSgDh7lcQrVvuDrxU9
w1IyjbtYt+YD+IjjcLv8QuFXbofrJ25oHzzGQV0Smo7TVdX3EHq1f+wmrVpyuOl1UU1R9RdN0ssb
M8xCqNc3DXFD5im99xVTlzqJviDrRIicrHwXsQVT+IKSUo8PJYcZ3Nz47g8OW7xOPAeAa95Etgrl
Gxeu6WX8jVU49XLTKXagV4cJ5jAespUTrX6sWWpY3edQeSRmuI2GeG7R7Qo00Pl7mWY55PEAAPVy
3QGD9Bg3x/8Amrg3FgOUNxrcaqOKGx+4wuq88QQSmYXHI3Bpf3LhRTtl9743LFHDe7lFEC0I65nP
KWP8VzThJuViO+0sO1h4GBWCd+Zbex5MtSDgDH6BOtMKKOGnY/uvOsUu+m/NAfF1zLEIlbL8bg3O
Lj7oLKbx61BdpZTC7DOSoJfCJFat7Y8QCwjlyIoMdiZ9RqRVpcc7bGpJE4MldB0qUwZ5I1CR6P8A
ItWTbscPKAZAAN/IjoFdpgUuvTLj6qqtq/niaZXPBL9KN3LIVwBsQAr6S8Cr2srkTZBjnuAL/BG/
UqLvJl0N5oiDyCtF+2P27C7qb6FvGUctcG8mS6UI8x7pZXRFhgRzwP8ATJqLOFhFGtDzL1Qlx598
Tmw9HmFa0DEmAKWK9kHVRwVUavI3ZxONqm7vuWAgwlUS+Be15hq6N5hkbxQLM8fcRqjNTr4nHSrP
UJqxtF36jdwcS2x4CWtL4jgND7b3FYgUlC/cIWly5jm/DCw59ir3+IoSjaPXqHZC9V/mNFHAClxj
KrEbGRV+WWlc3zAa3nmMIiiOnOlkDR07Tp8MYedmGNvb8otUk0C2uXFKK53ZL+V5qUziAui3iLgP
IAHmKquuTzEyacLn6lMo9W//AIiq0N0bcESdF7ArpyU5LVEK4R6humcFm5anelT7leQNsEE+4Pzz
hd+Y6qS4bbCGyi0USNshHJ3YZIgb4saxwsZTVPmZwXBtcVsjgSiXgCHCofPUUu+SypEHox17iiza
p1PP8wE/VZpLAG9+UFeVCMFI7y4he5V8dMcBtral+o+ua+0v5K6Yo8JcOZoXGh6iYvEiUw8Vt+Y+
7UrWe4/u8hkS2hR1DQgsGxf1GqAXhb/Us7vAeD6ifpViCyhbzR/kEjXLNy0oqIWnEV7+mXUGjuEj
4xCKyMF5+pSZzemIaBDw6j67RZfmUBRkcg32MDqTwDbiSTwSW5+QAwJz+wUIVwWJT+IkVuLlcR8G
S9B2AYQYNg8HmBjBUNcQchUlC4wy8uqtl3EJ7RhI5BA5DO4qqCrkdVh/MtAkpnn/AJCBpsKTL+4c
ADt9JT7hg6I/NHTEAIdDzN/5RwI2Cv4AidDt42TpBfLGBw/AJxilxf2ROho0YX5gQiF+fMSKd+2+
YMYdTsl4ENMxlSGr+lGkJaGJ5mDliMqGE9wVG0MvkueYJZrjwjErHTAIgwBjRFXqgI/xxEN8QaQE
xQcsUA4L7qY2GROdXFTMLgNuoNE/cujLDzLQeB6m+SNDhT+IdVrwiBYA7XiBfIpzDCArLO4iaMOm
VwolvcLWI0cv/sG5CPmbkQmi1WiQYppAlTClqHErQfO8opLHAwZNNQJh2vxGF2jFMupRXw0TDTVL
KuXNVoTEZV3wlKEMl8V3KonMbjlg0H1Gi8JQWGRVW8vEyL7QUHfcAqtrxKK43GrRx4hopqkD3PVU
Ek1x0+ZSctc1BRVgWo69K7ekpAAbVfzHXQaGoXVRLzi5ZiA8cyosnEI+S1apABRRxkbpl+IEQU0N
Ru9lKvInVJd8ofaDf0RRrbpH9R5eAN4jDnZRkUBvTsxZdIpXEBn7Zl7p2FS+sK6+HNxxWZYSW3bo
riUeQOcQ5iQ4LW4aSzjXM4N3TvZudUl6InBqoypaFdyyZF9LTmEKJtKjcQ8HMpCLpXiPXofJA0YX
YglPMTchdOS2AStgIezk5hJsad0Ubqux6loQ3RUb0aHgj0LWKO5wuF3UYDtaByyhXTCyACgFAkBV
q+YqGz5iXuUDcp0iHoF7KQRq0PcBianAhRbLlzsra6i7iCqCAtkugEcgvVpWMcA5FjDtoXRxBJuS
/mqhaoBwOfcLsHYpOePoZGfKml/IuDDL8iKDhClVPQ4GlhDnQ0aeItZXANqMNR5ZW1XzBGI5Stj1
gD5IXcii6fcFWHQwgmjxdVR6gHeaEVhtee/zAJpYEeHMVu0XQ4LhU5MUveJyYApZcHWAspwysbwA
nUTZwu9RrLU+owXihrJwPJBMtLlA1ggjYCcUdS+VPzJ41yFN/UK/Lf7GLRUpN8X3B6aNgUnHjqo/
zEaxRe5lbtSfpLm8INjeWCv/AKCVamor4eWIQVHav+Qstyst9RJprAWrGNfiWQE4SxMaXkRXsBzf
mMqRLwE/ERa4szIEgAUKwlYvAE9QGx3ZFrfEIGdoqiZvm5PUGqBCFC3iCypSjYuFyGBBeRxkFt4s
7uE9fMPD3Ac54C/4hYgojDXmLCI6q6bQFFKqgmqIq6m0pda1XNzU1Y0nqAnGOjJrxKo1SPBZQr4e
Y8tIFCR2FioqnIw5WvJB2U3aDCJZhAh1cAXZVCuXMMfQXq9wC8qHmvEJbuseqHiZdypeeXiVonsN
fU0nVbVvm4tts14X8SgxWaKrPqcHfUcyasXRtBv4nAraDiGp0RqXeElN/ccadzPDGIsAohZ/8gtb
VIRo4+JXGXuds4Yn0WRVHxC4C1vwPiFNOMYyyiVuBghAW9KhkGI10e527OoNnE9CoCdBzDEOWc5d
Q4ooWy3m4XdggsM5IaVAB7ghAF9FV3F6+IpajxCXlR6ohAsW+OY92FE483FINS7U+YBkZd3RcABk
7RrUGDF03LuG9+1dytjSC4CHkccRXWPAsyIormgKevEDBn2+jCCbsGwIEeHC4qjsYjfL6JF2WuH/
AFqGpdQKUHUYqiKHyGRADRTKrADu9RE+ziKJdTVou0CmhuK+viM2KqjJTW0CkaURooaU4l1BdElL
HmOIhSOO4q0Erdww92TqGe/6hVWo4HHZDXEKgDlMuZaQWlZSDx4BVwEbqDyXWzQcUwbY/uC3LsIX
y+JeyV5A6Yck5pormURKoYQ45CqtfiDWXQBV0R7dVHluAbstAOWvrJT8VA3FZ1HW0UThS3+ZcBMj
E2xh2EXJ3wlhRLJZPRGmBsf/AJAKCW6S6+VZDwC3YRRZ1G7FuSlhsHSXncBhhkQlt57i81StlXzF
P0UGxCCQSJoQRBsuHpRMp4/MbuoZHmrfnkxzQXo5iiuncgKx2CCoGmgbxC1RbcFRnqIG2+YAbhVq
PWsFPiUWGIoHlYIlz1EsTHmKq2w5gLvmp/QpcJyQjqCeMhUZixWKh63TSudhLlDhzHzdE8RlqBuo
fjBwqPXUbWjEhwKpnEAR2O1qQbQo8JD1crSFlhKsxlJOjiuqiwIOa5ldMpAdM0GcHmEEj4SIYhQH
LO5VnHOe4lQW4LyzH0sRqzwKuYDNALKlWhYw5hxNhaGy4VTw5Y1Kl0+5pl3/AFHKFuJ1MBp0SJ8F
qVXUWB7NOdgsSDCsgKDazXcpYBXrSXg6aWnUDohBK2sBrjIzpLth3cDmcux6HhBGT9GoNgI4qNBL
sVMgyMk0dMAAJeENpCi00gZnSKRQksXUGpPE+JmAxxHgyxB3CkAOBCRQ5VjzypqcXZFiX3HNbfAx
usXDSHobMe4GZSsqD7DyzuDEwHFRikHD5iMCa9y9gGiiVRqu+yOqLQ4CXORzj1SKEQ6Q0wrM7uKa
QXhC0ScU5JZqC0JDmPRRUahb16fEaKUDXGQe6yoPMZJo1rxGBeUgC3gQqUwMOKgoQLASCAVFuKZK
KoVxDNAdq4bjUIlUF+7ir5SUWwkPwAKlrQUW8qg7K4YJQULCpliI+pSXlznMajBjVcRLa3XhjfQV
LFgBZE3/ABLopIi1ncbru8updn4DPcrQoFNgfBFRA2D4jmtZSwcM2mSyrhFc+45Iz33x/wBhjVoV
2oMPHcNIda16jWVUNDfmH7bHtI4OXZzzAUdsMS7b+oAbeJfK4OLtdXUy0I09v+Q5uorm0d32h3AI
I6ycTnA9sONE0nFdSjg2Fjne4Ori0DJpShlAB1lQz9umu1/5Ob3Q4TxCvcBHtiIDg/MxFAeLiRDQ
xmsqZYBU17nNaAr1DgoIHB1zL8RekLvNlfL/AJOfoTmiUoPlB3DIXrbFXHqYqw5h+5914viU4sy5
yXLiSjjRvIFpWHGvLBoLReZzMCfwiDFxAtK4+rmbdYcfcCiA67zLmFMOKqyA5QVfcFJqjTIO4igc
RngUiiu41WsGd3FCOgDjZW8GtcpccGuCdKX/ADEsdtteYyC1AuX4lbJW/ZFKDUcrIISUHcYB2+wu
6hoIXL5RCYaSypVQKoZ3LHKUJ6gVLXw9EOmYeLI1SoC1XAMeujp2j/zOk9LkihgT3B7uATQm+bea
lIxF6fiMS7pxdGAwGHiPK3BWLBCICWqSN6NoXLBoleifn5iVjXeB8MYRbbYmQCsgHldRM9q7Ar4Z
WyFHBviIy68jwjOmbSIrsXApbx7jttwcv6uZoPPWkv7dyPUZqpVPdHEdQlJN6jy2xoFDxUVgQAm0
Gx6aLHUWPRe9rbh7mF6zZdlEOtcAIC9i7CUHdiLyR2PDFQAWGjXtj/LLwiz5YfUtHhrCXqIVpAiy
lTddtqWy5o1dkzwSzRaK6yCbltQp+JQ+QNVdkYwNIdti/uIS87GmU/uW10KpIZsSRtLpC7/UBylH
vYIqxHgqL/8ABwNof3ArmLPnD/IAvrnYkVWTefEBAWB0gF1X+RFLyh1PlHeXVfiM4Oeoi0y8ltYt
ceJQZg1LhyOwKQTp9VGUgCDOoseEI6fz5j+w8RPkNC+BgAm3tPORbRqIA2sRAIcfzKMw5biAp0IS
8e60kG6S3mBWsAvzHEFPp4jYgV1PmB4cQJsOZRYaIhatYjfab4g75t8E2jWy9eIXot/7gRVVEHzR
AtBTEDJ3ix8yprJXaEgeKPqGmLswZSQNdk81w1+IwAXamEkFboemAMqnUuZp4yEgxNZVEmgp7gp4
Sr/EH0kej1c7gROQP6lhra6hxClsnDNyNOD4hkACwlaCuoZTyPudoXBaC6QLJRorh3EQN0NgqdFV
F8uicGoPXcKs5eIPgVAQAmG1tw3AQFmxoR5X1D1XlzRCvELtXC+JjpS8+IxunYGBnSX+u5VuPmCP
MCURxWQQQZPPMYq2DUcpyVUM74fE+8wdxo6UX0cGAwBBkEFFSNcZLfhIPiXPd3FY7AHmVmTC0zic
BHggKUF7saksGU2qL+oZsXdZwQ44IYoR8vqGFUCnqELq6LuMAuziBmW2C9QiDbxUGtcukdxLDvxH
StRg4RB1Yg2KBzPKcBe2wD+IsUI2LGAJZdKMWqDaXFfL9R9SgOPiDQwUEDFVDviHq5b9VHsAXT31
MyXgH4l32CHzUPlBWt8yrLZtq47FUr2ADCHQ8hit8n0XADDG4oqCWEX0sr85AV2Ar3bK8HNrKqSh
H0Yzg87V8yh2UTqokYq9MiUBppCs4qGpWlYX7uXgFgo/RHLYJGBzRuvIwy5bJDJiRm4cHJ1z6hcF
p8m4adEX1cWVlQvrYIUtFPiMM9n9s3oSvO14nJovb0EKh5TUrNh5+4cXXsPKXBGzNh4l1cUWLADB
vlWXsdh/UGoLS4edYJUkvxKOcFp8wMgWCj1crREB8u5UoQs9sEIsF/cA05N1All7HuAHxZrwynrK
tX2ysARZ+zKaQAp6uAwX/pFtECbxzDPBUe0wGLt+4DgWyDgu94hNHJKPmUAKKn7Soht0PzDmUtPy
hcinPzCcASxe0uUEUZsd3nivyRTDA2xfgofMp64incP5IDXhgdd8ymaop8k1YHWpY0t9JRVDZLt5
5hFwko3CJI9r4GCA+V5VH5BSHxDd48p8JAItnqWWHudQBV6j+UF9Vgrx/wCuOonKox1MaVDcqNXC
sYfigwb4YYgSl5ojAVSH1BALmx2j4iJXWXxbHglyPeLtj+AzqhfMGWsG+/8AsaAVG97qeWgXEPPu
Ftek8UQS3OV/v7mF04KrnJpVC3+It/5QKefE4g5s9QPGIaDsNDQB78R0bkyhrEAoPZuHrpD9ZF9r
KPslmNlBA5KkUk154PMJ8AtZfuKuv+10jKK0XqxJsoIPCQUVS2a81FXu8rVHxLruoNKfE0bpb7GO
6Y2KjbmJEoKzutYTIIxZV3sBHXTkXmHDgW4Xkj2FRZnuB2ELltv8hf7GMlenrF2aEXOK32IVUpqo
Oz5YpykPYHJxYsHduxclmrk7P1KBZ1OHR/qYWxF5o4mVOptSZb9RsFrGovkYgNFe4Vam8l+mIDpp
ywtVaOS47WxLinYdy4OHmXXWhAX2xB54slVbmr5TIgA/KV8tgmJXUTguVUczbEQ0lVKm15bI+1Fo
DiGwmOw0DSufm6iUkWvxkVSt+WfMSzriT1kIlhD8Ib1CgFRvjIChZEu2QlFo7i0fNQWmdB3uJprl
lBbFWr9R0udiYGoLP3EwKhTKJr3cSxaLU6aiBjkZXQJRzFaFfDOBwkP5hsqUNfUOE2nETACD2SyF
CqY4x42JuB0+JZPZRY6Q3d2ZVClVQwQZgQ63mCMGq/UGVHgIdKrx5TgOgx6lIQUxW1pioDjHNx9Q
0JFRspgVdRPoKlcQFqYcRqUW+o/hK+xGati9iRRzN2w6jIYPYYKAOZcAUrI7mhbOqhlsovYhAU4u
FgbeKiQVA5gUotzmOV57TMBfUBxusi3W+oDCd1ZVy70EFy01yq9iKVKqJxEjhmNNa9ERXTWUepYo
RDbuK3a8yAOylcDgCUEaUV9yyuSwfUAE4XPmalWNPMQROGxHY0aT4lUUHFgcIBr4lpy3D5yCDrLB
h5ljKqYwQHhU9Rs9LFdtw7SEUYkUGgiMVE1+IcaD337mTAA+Z4S6E+JexQt6IQUAHn1LoVFSbWHQ
dbL3Pb25dUXgjbQYDvIRRWvI+5bIQAmcc4nxKvLI31EeuH9RKxNrMKTajqB4oFueohECaCW5WlZC
HWqTpl4eAn+ZVgtNJ8QQdTPFXCjlml3kWFEDvuMWbJR8whuYdgySIo85psmj4ITtEoMpQUAb7iUA
Wp7jahD9G4AIBQH1CzNKiKPVsHccWKO76mMNTHW3e/qWAVkX8G7PUEdKmTiYtB3cM0AS1+IUw2jf
mJ9Vq+O4g1YCuWIT+0E7atU4gs9I4RxKhUK/uUIipDwRnLR2DhgCFAb9Ec+Ex42d5SXxV7DRR0I5
i0F9QT2F77MBI5B5dPuCAYKfmA4RAPmLoxI5sxfRQviEopDXKLLNvd9jZfGIBDrBXg0uZfFpXuJS
u4nJ1CJWd3uA5BHKbX1CYNwZwlS81DAqeX7ZZIxC824ictS2L2Hz2K+0TTpnS7hV96k3nU5Go7Bs
qziditilnG3MKPkBb4YT0EDddf8AYjEDTwdkYwQnThh03dty31DnPSdrCbDYCeYMsqtvMuSHFoQD
+mAcVUZ6WwW77gUlqrO4w2BxquridJC+oOArRZowpwzCoRNu8u68SoWmhgBFAFfU/KVsY52K3NJB
tt4yBYRAgbXmO84C/uO6lQrxkQFCaOaiJS1LxyR1gFZxfEpuVFeV5gWBoTGHoaa4GMyXbpA8OS5l
JZpjz8wtW4oX3WfMMthLVK6liixWIXDo0OLh1LAY6nbeRWFhp7GW8NQHriCZAC9eLi/FZ6ODmW6W
xkDEvx5wnpG+Fxl4ROm9KmQjkhdjKl/RVJpaqDamUqa6hDuVBMK/iOClWO1N+Y9yoCk88yxrG1xr
uC64x2jsa32suhxV/DOdAw80eJSLBaus5YBbYH/nli2xPZD4giwbXQqBUVor9GwTmqVZ76ip0KnV
3HVBvNvphfLW5SUc/uNq7RSAVp+YEBQ1xRX5hLN6RsU2FjfLxLTwnJL4lD9BlZ8pTwRKWnlTG3z1
fUe5xEDi/LKs4tsII7L5lO4lz5KiXUxXwbMzKidZwwM1gOvKo0VZcCLAoKnRXUvvpyOBg/kUllAh
08sAqGnuAAMK3ar/ALGnvqPuYZ0A8RP7avLsrdVCKynccJLfQahjyJZswItoc9wNzm+4gDfcKbKb
YpzVbk2uvMt5RzZalVqCC5oXnqC8oiFbCXAA2BQykMNgsAGNhNtSrxLSoIfDAAPgGEL08qARmih5
g8KOLTVBanzARqgqCygGl/uESDk3wQlZ23ZbgQtrxBz0HFx8StczMBC9Eqxjdz6hwGfD2g9xA9ok
MFtDmAwBQCSh6+bgACVjRKINF1ccrhdeHMNRm1hhx14qH2gA8R+aAUxgA91CAVm08QEA8C9QImpt
7Rw457naD2ZRpKVQkIjEju5YpPmUU1APmWqj30hOBeilXeGr0iC4Swc1H2iA4sFuAAL7uLAILfmA
Ve5m2wtd7NhjWLFiFu/cIdsoDLjKpZtsQnwigu6ufDEmClwNiB1A2IRcBCYCqKhmUDSgaWDWxSy5
b4SoEaAbOfRw3pGVp0L1AnAF8jBeB7BCvQYl89RukqBfmXyKnBxCM4dHiAmD2W+YgOVWuoXw67cx
GbsvgjqilnhjLLaxpl33SLnZgVqA8xYKLloJRU2pp4IFIpQXw/2YNVS7JkE595f2QDc1xFIHXfUU
hA4vWXLDlTyTBtXVQ1SDSS8rW6nCIeoBcUDlA7HMz7+jzAGpHwMLXAPKsg47WPplY49h/KHIXgbX
1FKLz4iVRWy3CRwNQHvxH3gFlSU2SwaJt8voKxxwyN/mbRRQPfTGHmBOUZdNXzEyNnpaxyQn4A3E
Ntf4xzBpy20fj/ICPu1pH6wy3aqW1cQqp4mUw7NtLgyyJ/MDEBYJsU7XA+4RrgN9JXktQNrvX1A1
ukvEi0hXJgR0qFwKTXqKOZZ6TVnDBNOF0huO6mcC/qOxyAeNyNpiAXgvJQ7DG8cw8N0BuzxDR0qc
Wdd1g+vzLE3K7Pc3ybfEfHxKUHdcrlEJbA79Tc3mlhsrMMcIj7ggMKrm4yBcsub5jgPLHDK0iBl+
jmF2qAfzB1rwUvEYgRG+772X0YseRG6oqbhCF/y5AxAIaG4Hk55hw2oF8N0/MVsXg5sCQKpeF4eY
sJAd8ytEUdB3Gqe5w3fcPPiIhn4inNu9u7h3Yp3Pm41y9bcr4gWGR5w1+5TDsq/Ea4dOYntRA/Yc
QxdXTzE6AVSPWwGtM3iUUwCbR5m+YgWT4jL2tOAeiWQGdQOoB14qFlH5lEpFW71zFlVhxlDeDU5e
/c3TTVdB4hdkAGu4gXyL6PJDhftWbYvszfAXV/UpqjbwUnr1KV0sg1gK8NVGvPMfmClejJXxb4C7
8ymOGqoTbszmDaDp0HKmyIFvCR5ihqnDxKNWEGcp3kTRb+DUUdgNFvzEhbXdAIxpNZ04yMrsUcQW
ilKS/XxB1zEObYFam1Xs1kTLbuVkNl2M1cOaWxGcgEuiVBBmLDzzc0cBOqXNMa+RbYrXzGmK8q34
2KonJHK4g/ZqICcZzBy1Z0GvmMoaEstmx91sXm5ucEKPaXit22aHnuNm7go4iY8YWIVaBBue42Gr
0DywLiueIIFXmIspdQQQKXIqs4MWOIrTuNp88SkP6jR+oyp5QpChAmnLDKLY2NsSreILammX4TYP
N9wK9fkSrolXq78QR9sJ4IBatzNjRXBIBJR2hdsv+pZ6fIuN4rtrhNqNmuqCbXwo2ZFahHKlmUvB
gizoXj7iimlo4GXLpq4BAu9xiIVnQNgaHc0Xj4l6jmG6br1C7aQGihCVNW/EzHlBPG5a+XUziA2l
mkAKRlktOVqXAt6cWwdlFrh7lsK86XUGtpOCJmusGoRdDmKGN7d8Qu/9sTL1Uu5RUteMdEPVxuzG
luIxgPaMFOw3jsAA51dH5gT9Bqpqs0W49vvQXU2ATBMQK1tFuJU53HI2y2KpcnJicXH3G9jo3gjo
u4GESwLUuO/DHZgdWLggdEXau44r2eocACd9YPVd4G4MqyN34iYQ3FoSBHhBqUFa7uGTh8DDY6Ut
ffqcobyyc0V+0b2IoL/kCtnQEtGhG4QvNLx96W/+RYLVp4iYujwdyqLBVwQQC2ttRmiHR4jXKNmi
YSn3GTX65RwYO3uWpb3Dt1OFhiMybRN+ozFXuXUWfGyiSYj1HDo6rhAqtl33OEFFrCClvwGXMqFs
bnE3LkMe2rkUR7q25hZ1l3ByTVZFtdjQOSwqt58yk710QnxtGwnJLfsPYOBhUmCiqY5Ja9sc81iM
HRaCw7Y4Pembri+YQGtUcYdRCujX7gkG2pWWtvHmXhUKdlS6TRt5l2rsU1s77toaK6jwjewW0bZD
za002n1U76GI/mGCtP2nLAvfJKM0mkLm/Z0sW2CXXJ9SnDwEH1cvFnToxpSlrEYx7bVEh9+JbBBi
EIEGrksVWwNAICTaniO1JsE1tI4depqH60RnIUvmUsdvtCOG9vJibyGbOIRG9zMiOqtBx8Q1VTnF
IrGeLUktwIu9r735lk4e3ENN3LwIPV9CnHoy/wDP1FlGKXVOmVa7SKV+IEJPIifS4BuLacslPdZx
TVSzGkzOcRzp8uwsu7vzODDJQI8EFjdgG1gnYzVF3bfxPlTi1UaB2KfGOKRglKnRDpvBbqVU5PNM
XLh2ikVHlHRL6FzXUPxReiZAr4wFH5yPFWw4EqgIVZrn1Gzt9BTHEHKo0Yyqq512MSVz4B8RMDoe
blapOQVi145uIgVSl49QlZdP2yxtNC8ELFswf2QKK49zlWQTU5zBauWbQUNzmFN3S1xBbZY6nlYF
8pEo0ZSXVoJcQN2Ct/UdZ2KqfuEZF7C4iMl0coyELbiPubAbaKIZYBZQPmU+ZNDn7ghgmNKRlU0F
xLfuBVDYVn4mX47tHwLGHEo7nK7/AFLgl8IHcrwU4riKAJsss9y7sV1lPNxw6ynmgp01gxlWVcB+
seAzWwMsyDWOIKQXKKpEeDNnvmCHoaa8yilLAI6LJ64HmouVhX17mU/MJdxoE+kkSm5CqfMbrQAO
Z10rcQhu+hSh3nMuqOp1/EujDukuY7vOz6iOuYInfMvrYAm3GBPFDjYWe5Kr8wlFQiXgux0XGmw2
OAdwNRlByspDahoG3/JxPDto/wDMbuUHQgTOfiJDSNFTiGLK2Wg2vxAcY8xt19y3jHRemZABA3zb
KmU+45wagPMKygjTzFFFvcud6NmxrQUrEMctI7Nj3Bwb3kuSCLA4LqUFNBAJesVKYubU8IBqkcGg
c5G5AliEKg5xM5nUSTiU2Dd14YQAhxA3UbNJUQaZHSAFbcpJVsWPcVAzQcee5goKdsACymuocP7T
CxAeoC3uGEXfcBAdWG4cZULXG9wjmborZUwOxsRieY7lZwbxxDMNFYbKUOlb3KW00AuOMQxDSAc5
xOeBpSOZINeUvIt8ojm126rqZho6LKwiHhcIHIMTUp9uQhseMpMexHVdurWpdyzzFLLv3AJKevEO
004glfMbpR5q5IhC1FXuXKFaVzLbkegPiAV8Hn8p2mIvWxke/AY1+AKqXSgI8HzKRnLvpK5xcABL
UN4jiElenNSv1A48UaCbvnMuNi1XnTCLzgub+pm7CkfqJwTICrAXf1LFLQiWaloXDO70ZSoFGBVV
O74NK9IfyHAtmpN90lT2FsjrVaucon2QcHMvrVbcBABmEOL9RdFB4updAVh9zkvhCoA2xQ1jLeA4
BBwFv4QKaNpk7QYUUV4h8AJlgRoWjXJlLYGqIFC0RUNGYUrmIXK48wmAVuj+IVNKrhw9jFpHMtRx
CL0tKZBteOSZsrQq2JVYWAcQeq3eFXzDjcItq4i4yoOYDOWxfcRFfYDg8Rq3FtIfmF0MgNalB1zH
GERHdymqqrulMBVphfMII4rdsbHomsa/XoQEVhYLI3ShoU2UkBUGfuNNt29xa80ZPCKqjmZ7Ojzf
PxA4DeG9Sp0BhUTBFob9QM3QB+idPwEJUCjHlRkwKgsHEeROEC3C8Lk+CHULQVwSuw38RnXLxHc7
lDjpkSwIqwIgVRYFr++oNIta9GVyjapyxeA08AhHFuAeYDDYA6v7mpDyIfUXWjAAtavIuoBw52Gu
GsBjNn0TA3y/M100FPcN8ntB/cAhTkDPxK4gFgo24BAhqCs9wEEVgOxGwUAcM44lQWyuvvXmyEDp
I/1Sipq2apHEDJbb3EGQufupaIqQ6ohhF0KXB4BqE2K/Dzjfm4EeUInEAohSvHP0wnm5FzvGxwqq
GmzRojx1BiajjOOJiJ6+glUaUBLcKAEcLvYJVKG1DIBfrHXyKdmvhjYG4UA8Tjr34D1c4UkfJEYr
MAJTWVYVRALUa6VE7FlegtyZ1o7jpGnluuzzLlUKGmiCdWCg4OwOyCNXhFJ+IsYRQpnxOiSMs+IR
4Uoa5lGWiBqu3B9s2a4QmxHMCviMbh8pb3FAgsALY1rkENXi4gtDSvaoVKN6N9/5HBu2Q17oiQuO
OT3ApLnPHcGU2qAp8wWAA9kpA/TBAkmyCF4U7iwIosV8wi7Daudjfe5YAK62CBfjUutiWG3oqx8w
ItZjKTlj9dVVlfLLByjoHZ7gInVLAvJ0/PVa+MlTbu1G4iILgV9wbCKDio3Uyx4hqAfAOK3uHFq0
q+Hk/EqMjMVX9QmVK0KR3E9h2mV/XM4wh5w6uAxSBRE8V8XCdBUM7yb80LgJUlJm3Tn9SuxVYpvc
mf6wOQ7/AFMCBgup0ijFwgYqVUZBtbjpWi+6BaGVoMWplH+y3AwqpcMAEjyHjPmVOqZ8q/NfuV+4
TysKK6ouWN7sD0ohoX9RFwxIFar3FQPkVK+pUAAvmpY9mCFC69RzXB0x7ZMOROMS6s8R8CVDle/1
HQRS+CEKhAM1HquaA7EnqSqOd4hc0c5Ec8EbLmGQjJQC3yGRlRwsYyyAukqpqVjmLgDdQhhqA8XE
C0YsNH3CnRBZWThiNgeolJf6hCq5gtmZFIPcKu8ht8ZaruKq1aRkZkCbOHioMF7UCw1zkNhUqm67
AQFeKOBoLRUf1ooNAuA3FGyoo3BDl9QQBv8AsluAG1zFZl5ZbMVs8y7pi/KOgrxMGz4B55iBerKP
Uok0BHewQKzfUqI2LRlRXwMYWBTJgZTgORTmDdna/qMKE30lRt9qxg5eQTmFooGEpotNJ+pUk3b+
USKglOIrVJBK0CjmEQyGZ1BLic+ISnNcTIENjSXIKJZ6j7odB7iNF+HxE4rwRpPWPINijM4QzDz0
HcejT4xJk+FcSpkIYBNj554MzymtRIEtcruXANwCDLknGUwGc/EcVVMGX+UaK4x6hRZUctWWAgs7
IFF1qRBlWw4y5ZiaxjfQKETyAmdkAgAVkOgcC4cKTA3wUuDDBGio37g8oRRgnKWFbTqpRKKI41oD
y8waDXDIY8AZcvgXG2LYZnSLW6KWJJihVQroj5Go96AsgAhYt9TkZcekctAOJxGKkDG4lodQ9l6w
lLJ07IcvgPUKiLEGz/jEiAGJ8ES3dwvlDTkF8RBo4jqmGgg2qVODu9buoF4TSj6lgxWD5uDBKq+x
CpafBWQagQl6qXONtvJuakKaVMt10/UQrQRQdM4zMKMgBNbn7h8sTycZBoVfgrhlZqo232ImLt+U
sqi2/KF4l25a79E7wpuTcMm+IFUBjXFlyhZabzniUqKBb6GBgPYe+ZSa2tNYkqiJ78SnhDfxEVdB
aCHTCenuAap7G+5fzc/gYkEDXzgoOinLR/2GCLLg5eYuAIw49SpwVuRLWcWIIV9S1ouxuBmHgHXx
L49sLYPUvK9NXUNg60cvEIEKlV14h/OIKlG2XQJU6LvE7pIJPBX08/EuBE+Z91Cq12nuL5gczzEv
LeHCFcRCsVyM4FaUh9SiKgXxRMAWFBPiGJvV0DLUBwLgmKoNu7UZoLVbpG7lqA5AX2+oWs1ioJzL
RtEE9dwdnYsqtvMTIygVGxKFeq3SpjbUrp6lWBdOfEfiIAeSZu4KYQqVASjjI5rAq2APEdSudOb5
lSLGQxvmJRee5y6xVy2imkNK74l/0K193cEg0KpxsoZcICX1TVfj1HEKd6YxFRhet4/UeJaqdDLG
EHbbXcEngx3CoHcAatt/2AmBJNl85HmRo3WmwUhidLcuHbdMEe4IK06e4LznfiYpVsOh8Sy4U1XX
EIzw08bG2SQF1twKEYo7lw7GiyogivvuEUEU5JQ1OPffMMMQC652EIOaEcnUxJpPa7goDg/KJUST
mjmAYqP5JiKrsXriMOoYqeVg11ONXLOMcK5xxBHsBM7IlqSL0oTIv7AGcaTDwtPq4Ui2WLOQ/ECx
UXxu3fcoOlUuiUuLC+7I6euk1WZTzsTrYbQo/kS6PqyBv7gJxBDriAZmzdG5XcDgEWd04inc3Sh3
WHgg1P5ixgvNgUlMlnyIllcxiLggKsvmUMlpL+olRmdxtgUS7CmsevMscC3GVpbewwFArvicSpCL
8thFVQX3mS60cN0K6iOLVZx8y3imyXLWzEA4gL7N9VwfXK0PxDNUYDFbCrfllEKKKspA2JfxE/IT
EuSVxPUItW08e4ZPsPMBsKHFzLaXN1hc7KeImpPz3PJAraTqcJqyEtGIgCqLYM2OSqBbuIKUaPxA
k0Ih3K6DVf4jrRXL5hxM286lUaC2pU5VRYNILrIbgdR2RpOjSuZdCwW4+rWIMyX7dMTSLRHHPMaw
0H9Rmvj31GVxpR4hmIpnzDLgNQA0GRVydB5WUk0GhVFcRvCKuDT4g3TaUpq4chAtD1GYSzWS5nEK
YiAjCjHcQtQ1XFmjmdz5gXc8P5eIDzMbfqatdvAeI+dKjy2ZKS2uL/mEpSAnmUosZAMymZPMCBAQ
WEgRAh5OYRTmioVqtTuOU6WWkGASryDySXBraeLRYCWgR4KjFYp/UQYBXSyZ2Mt+42QxVRiqQRhK
4HqZLm0v4hZK7V4p/kWjAM4olsPyG8Yu3Hkl2QVXGLVpBTWCURaaufMUZwqn3CitL7mAvMoGQDvz
DUN3EzQByIdELPiN5MAlAXdTmFYdl56oJSUKLamalbCP5T0dSuo5yEmsH1NaAY7qBaKHGB6ca38Q
RVtqHZBUF2d8McpLbU/ECx3qINLS7uOBMX+47s4lTaw6vMTH4H8yyoG5xrL87o3ySgdqNHtupc6E
NfSBC64Mplo+yMZt4HjYDcVar+5a1o0ihdqthATm1EdQEbKcmxoF9PxFTDgfcKBQKuIRQEp8y+iN
CeEqxYsnI4A6hCqfTA8F2LOFVr6lqtNUYY3QFPcaEUuPLIBW6weOYCPUr+Y0GPre4+gI/SNfCET6
5iqbjDVhmSpacVFeVBVe0z3Ch01TGDYrc9wOBlUULeR+Ab4wr4h2FSBLcCwHxLf4AnC3iXVFD3UQ
AqfQHniWaX7R9yFJUsLL+YX1asnfxCoirzzK/TYRQULQYftMopvnYh9P+SdnAX8R9iwVWh1BYjQP
3CNwcJhs1gWv5ZEXW/4n/I4gK8HcRaWGnGkZRsjtiSoLi3ZWSwsJZ4juHbKviBFilXvf7mJhS8lO
4bC4gfEMBaNVNf3pjRq5ZjUCnbbMbvbO8lNbpfJsT/jVldNQA3WXKsNdPX/YzaByfmEBcFRYJpK8
Dda54ltqS552LKX4NqANGgt+YSl+O3qLAA2sF5hVPQN8wUE4zyWx35uYXfEBrllu+IK2xS/cAm9A
FxzsBD5IkaixvvJs+ljo1nU8JabeZvCG19wEQuhjHYIhnaVnVKH3UBbdmr6uPnbHYDlFZFl+DHfq
HYlkN9xIUXcfHEvHCENVcT7SB+UZCYV4eoWLScVrk2K7UxmRB0uUPhhAB7NpcpdHAOQZcS36GPEI
eVATXajaRzGQ1MrPuyLBsBT5/wCMMU9Pk/8AyOcCA+chWq1SyjmW9hsFoQvz0RAy4WwI+HAY3JiL
d01BvkEqoyvmcyAzxFFamKd3ADetq522P3mvkkrnra+KIGa0gvFQXHHFIGr3zHlLZp8XBAcZLyth
QDVxUnFRWNDF7ZzEpWT0EsL4o2AS56iJaHyTWeHKo1KPEEeQeLg8Da3rmPryXR3ZDqp/beIdC2l9
5DYCmW8Q3bqa8wV6Q/lKVVvzZKzlVE0hT7UrzcTbNK4nruC+ZwFVrRoXB32wU+qzzFiWaeMlxBbA
ncqlfuCnf1EiDKjQ5v4g2Xj3GzMC1JXuO0K5h6LhzQ5Dq3UnKNaMIDTfPiXIdj0LiQQWqPWtNujY
mFIAuC4XG6QfiLp1eYB0KbdLYoKphedju6e4LNi73FgNu3nZYtG0DrI7tcFvZmdVIhXNVKVJAuEu
IdqK8zAR4Ul3k7w4gRx5UsYiGoFd1av1PMtxZt8xIJaI3f1LFtM12Xsr2nmOBO2j1AJWeZr0sqvi
UEbGvYmGD7gdrwqLHDydy9y5cNrNiOeeo32AEclUewp2IjdDG0fqPjn51EMoSKR1AaKDfsh5tuEX
pHqjF8wb7cmFbqFzGAXV8wKW9s5kyiuYhD4tjuXVBFvxKYRae4QB0n6nFA8nUEiF4IibcdVuMPcy
QoiuT5qUQbtCWjjMYjINrWLSV8Y8sLd7iySq6hKkaDe5YyNmuon+tbAoF7WxG2pKIYykbp8SvgOk
JJvkliTzjGjQGoHE0A7jS1XDFlMPzGgFji+ovXfBAqZd7cR7EQu4ZmzmQU6BU6gk0UCsqcDV/UDl
rc+IlNIc8wpAxu+o0C1dEA2bW7R/sXQQ6nxWpZ+HYeoLuVYejICth1lwfUuWMd5t1bcqsNl9AGfq
VrXLI6Cxg5+aO7jA2nAeZ62E8OwYMLNisIlBXUcS2tff+QYmUd9QXRFuvmIdpZDyqLHm2KQoT8oY
XetsFVaGEfzIu+YoDyRTfXc+IB357fMfAroFXF9YafqYii6OyMfSeeslTYOSxoKWg+otVMD3EGfF
BUKZSoPZTCI1I8NtgvCODxxAsVU8WXAOwmsapbLPcMBKQzLi5HwDoq/EXsCEFWwqygW7jeiG6F/i
FicUI1GJ5Y4h8wRRB6bmAgx7vzCe8FcbOXeMe/uGbSgrB8+4MHZnyuXAEF8Vsa/J1wtylYoLSvqc
J+LKXYk5QBv5hIFAsHUGUeg0d8wIGBfey9u7UPUctIA/L3EomFhURC0XuJa/EFHYQ36C4CuJWeGW
XlqRnPgWW+rmid8hHUvRo/EgIEbnGVUYqkVsqKrzEeQmtFOPjuV/7EcD/wCI76oBXfuNG+ILPT1C
+VF9pU3TcveT/stKBQw24mUAVezD1cFPZBBGWB77jU41V2HEq0WRwFvP5m55uDy2pSpqugsqCD5a
5V0/EAwIcXj5iE9hSUPEtUek8Uyzio/qxcnKBQ/MMG2oGvc5wOHhcvQ46HD0yzEC0dTxEuFo8h4g
Y01D2eIPDpazV6ly568rL8QaYYt7S7fZS+FE6qiG8iq592OYHT7asuaCsD2V/EqulgLveYJocZ8t
9wvmaVWjSEUVdmoMo2pj1ekUvZ5Oz3HM4l0GbLxb38bd/cukyrxaJalJA1HzfqPCsLX3zOqXVC3m
Kk+ZrNiidq91HiNkKMBYQ2UroEiwyaK8mObtxyXf8QW3VjSt8+4EpVHDZz9SoIIYCw/vRXTyfqWa
sQCV3hH8o4gVtaiFU0hoaNe4IVl+5ZQPxEtvMrYoe3shTVs+ZFhbPUsIGDstKCDZcNMU13EULTN7
nWp9TMGl8MlEQEcudQQqApORe4wuAgdTFRjTwX3AYLOV8NQ8SKAm8xDnsCbudMbGkrUdnmXn2Jau
UtNXXS+vqL1hE15pH6oQR7qNMNOOkO5UHbbdR0a78ziYsVtXEqIOMNkgRAgbbTiC03xBKbx6gjRR
6mule4XFbZgGMVDbBr0ILILCPDBEcjsUQK6U4qGhQSoxqwVp4YX0tu9QZhwsmb1NiIRWE9Ss2g0p
l8haE4QFo+YCMRo8wTygURGpAHyhixaqwXhGhHM0jmWcxDlySzYnibWHI1mgq+EvevBOPqDSvgNK
lbCME50op8XKPcr0jev5B37j7owLhMpC69R41akJD11luWAjcReNlOCg2KleWUGCrfC5RHDzlJL1
IRAjm5UonVu4+Mvms1xKzmJ2zAXKVI3mwlPYItnc0w8RJCrkXAJqLqet9Q8RyBsvwzTkHPOQ7O07
USttQ3hzLOMRlYk4Rh8RlpGqoLZSDAj8MPP4oxIVutJ0BdVxDJrq0UG7HZHsvIZrR6C/cRTl/mbA
TqV2NoQMW4AuVqh59EQVc0zi7Dqx2PXOZQghLaZ5mhfCuBAdsF/MGwFcw9fOC+SXUyjsxC7xlKli
EmKaVDyMBTzEcGkfU8x8HRjsPH3wRABPPP1K+t1xFsQwp5g861a4IHYWW7mIlqvqKlQsOaJuU0rm
LRyp7+oOKVjffcLDccOXHKQ2M7CCoOreIyi8kfiABKY9KhsKsDw3k4QiB9IwkVVpZkDtsa7jDwAc
qb5hGoa4F+ZYdWATMxu9lnKNEsV74mDxXmNbR83KYBWJNiyKUaLuUwGCPUQeNpgR0lE4ZkcL0UFD
CgL2eGKyb/4pnRzB31+IKuLQNvuXKBa4+YwUVd2bvEPragxhaI1vUDCvWmVUew2xaU0LwMy0mWWR
C0X5/c3bG/Fdy3PEL65j4VElsh+QWMS0sJ5gCUEN3sJ5xQcwpdVTlDYEiny8cxFctVyvZCe5bD7b
AsIyO1O9pkUeF3mFViQqDR3hBa6hSvlUh+O5VnS0f7HFseC1cWAuQ+LuK1Totv3Ex1bHpgRn7Tgp
z8y8oF03d/uPn2p8ZGMth8yxrfbaeFQlbQeoJaXDxA0Bgto8S9PmjSBaQ6tu4leO+0r39RjXJQIL
GSsMWAuolTl3HA0x2jPiJ9wEbGGy5g6quvqN/IUFFB8xRilvz8wPxFWGm6ZYQ0V5vq7lFRrb+Zau
GXwkaSKWG/c4KcDA1HHkG7ebjzEnpD8xKy7qqXELlfLAzHE9sLO1NgNf7l4qWy2oYVwpvIQOruGV
fM1cBgthpeXqXCgzqXee5uF4GripTZ5igxPWfLK2y6ta+Zy8i7cQ7+6D/kqbpE9OaqI5XFsR+2eW
PBhFF8uHehzKkgpU0z/I2pa3zzHoRYjwzhR6C1R9xi5yrcws1nk2EiWSo3zFM2W23tEuFmtjYGLe
XwhaBCxT42c2hW9JqBwdVDg+nld+fmWhRepUBot6afzKIvTcdalqLYVvtGtynGsNW6EtJ4mX56Sy
XHP8yyjSTa47iNq5jzvcsKWcLfqWDef/AMTQeoqH7EVItE5li8NLnmnmJvCqjw6p4ltmy9tQ456y
PjksWyH0tViKHgU8/uYAPRx7iiv3OnxC8OCRQRt08t5BzI0OJuAuHMNp3XZ49wCPIe4pByOuJsWz
ayyU+Ii8SwpY9E4mB7iAoYjLmdxUOcMY+NEHkJxoqIvIeZdGrYwh0bCNEoxgyKh2cTYgeYqt7Zvc
P9EKUgyq01SFuovU+Qm3QfmOlfU8wAqW/cUaXRY4SR5dlHCdDDARupdvkUT+4es35PEaKQ8NygA4
dt/zBN4WCf8AZdZeF8MCouqBVUt8p5tf0yngvxF6V6m2DgUjKtkPb/sW0Bu7h/Q1F3ALt83sta+w
y1tG/CPXZi4+5gAvdJCS1RPErAEwbSVxhG8hCBPUvmKPYDfEZb2WsmWZFOWNAwcJVy2r8Sgb7EVN
C2bREm0que/cUcdVFCW2rd3ZV0vBykaCJgC39xAd/MvqsW0u2AqDKssFpPdsQjlssS3deIdmoMXh
4husZbbiO1hhZdNhfzBLYvAz8sAyOPkNil/Uq5eBHfFKF2z3LA2aFJBMUpQ3ENg5jdwihfOEcg97
eYrhWapl6wmgn3HYo+USpeMjwF3B5lMBcTnlejbCxy9tw4eLqmfUGcB4v7ncy9ZacZyuSnHLFGXx
PMcQmNygZ/iF+gptiBpErQSiAlrVTKDxQ3Fzp8i4arS+7lYbmiKn1Er8VQioxbjZa/8ABd3Lw36E
vzEC0PGKi9+3nmV9wz9S570Q5S7VgOWZrDrt9y3lc+CITxQOx+pwJoYa6Y5LDWO5f0hNlXK7igvR
Yr9I8UWh4nxGo2vE5vJ5lhGhHMoiNrCU+8mt9RpZOHh8SgRZWofHS1U3UaBlVlTD3MsuETYtjxKo
0qnqvEcoV3Cy+t+pZCcLy4bbJYV/M5FeYwVDfQpj9SvQOAqD1i3TAHxLm75WnqHxFyytS5EHIip8
xgsOzCm7cpkaeh2XiFWPaIl3/iOJJhS5ayZaWVidvBSXT7lvjLtSLU32YyhC13V71EbraFvuZVym
qSW/G0jv4igt+FczGxGgxmg8Bkrlqcly8PAxoUfEX6X8cx+lfQm/4uB10wOT8yrMdVR/cSC8Nmz3
HDkFP8kpHb0BR+4aSVnQ/UtYQRiPiJXyeoC3I9wGp7P+sDqZEH8kNXkUKAR5eXuJQG+4HFl15MHY
Y4jqEYVn5nKQYL+oZTZSsRhlkquLR4GvMcEFSkMXFyHESirLqf4gLXULp7WO2XogvlIeJgkAFkAH
0+NnEOB/IZHIsLA4+IwiC8A7x8xawVYShYRd1PvSdiosPIs9YpdxBe2L4v5j1CFJZ8XB/wBVCYAC
w05AiAYMtBNcQzWuv1PMgRHO7QU16j+T5LLOSMOVYHcQKIuuMu4seR8S69lOS/8AqhHJgx89yw45
IaMsQOsaaZhsDolbKq2qZwW2totpfxKPWgTpDxgkbVxB5Kmlv/krZrVPuXjqCjHYCuCvEO4+EeF7
ufqU0t3DxLo4WuEeEAJZ9kiKO1QSi9Ig4AiKALdfUtyyq/NTUHEDCK2KgjyBgFOl4JSrMlOSpyOL
9T4YKp/ceCbcRgcDIYdnpUvQU8ZB2u3LNQoURyZH4GF6VVPcO24SdK5glhIoS6KNonUVZxOSS7ie
+0XwINT+DpHKllmSvkq1U7PBWdqm6krvgxYVQL+Y+3T2GxwI+hlg5UdIP5iqvVwI6uP/AERL2XFN
sBGim7LKsXasuKYGwidkw9ssRK4OR11BQJCNT4MjuWPw5jnb5K2UMoYV1Ljrq64iEHOgsKwVKMnA
wtFQTL002AlFCjFir9AhGgPowlig4pUxno4CKZNIro8sCKjtEdUwF46l6BdcRKg8uSABIKupQKFr
RAwyjPIw8AYV9QjTh2GmoRKsDzC9GKpC7Eaa5hYpVT2Ye8c0LJcCCU2YxzJW8Rfx6JeQCWnpIteH
xGwGr0e5zjWKIxY2tnk/MerboIjl26HuH2tVYcxWyG96hpfIdMPtSmENq0WQbcAF10LgilpQ5+Yo
aWyDuF8KXImiASnDGpYeE515gQDFrRVqhCubiEdWqlACr3vEc0It5Qo3J4TT0WD8wxKKsbAGwFCu
I50ld/OzSBLfCW24niOIlVx4QqVqTDZAFcCXkgRrg7PoRBlBReq5cy+GFWN7W24weCxeMpA6wQoK
Bq648TGFbwEL3N52DejeRLjKfGYDToTHIQC2o7RfoC2BVYZjsAAcjtOaCmyw2ZIvl2jwoGZwi/pg
DxzK26BUqf7DpCNoS+EM+hK6ElW7RtVJS1f5J1BhVVzY2HjcDReQ7LnLTIKNVLnBcIopmZW9WEpv
qNeE1DcLRVDRvmGhENs4fMAFuqxnUZcLTj5nkpYF/ctr64ht+MTqYcbdXANWW+YsAQzdR1YQl9b5
gnRFFBLAnyO4FVDtVKCCNvqZLcB68s8s4+EQIQUt5iEi6fxF6O5Z7gWCr4+chuScVsWmdQVREDWa
1Fx5RdOwB5zXn5I1BA0B+oQ1m8CwMdTFJN8mEMzyIfdS0BU5bhFRbOBg/wAqil0yhSwpHErOC2DO
Iwm6g8QJtyFqovaSyU9yqERbVvUIVQBCqldwEW2kpYAsmfbF7V+kpmZkSHMMWUClQKtr2ObgwhVH
Ah7AgSy2MNG049TBd1AZCSjziK1wLdAkEA8ErgYlyKT5TDk6E3cuUltarhZS8SnIh3OImYPKLQBE
tdbH2NITtRnuTAk5Lf1LBTkpR3zLg6oGrzImM5gviVvedoWiVnyLgvzHJfVZ0Ncyvj7AAvUr1wEW
KXFEIKrsRaESaNupmsgVy3xOi7EXR8TBMEwPHEo+nIclvErZWODuQElLtAoSCUGtRz0SjQBIeYrU
FLF23/yVisuxNq4MQSSnn4iUcxR5G9yBBWpSl8TPMh1UPcK1VjxVw/cgYKSF5vGN6/3AdGX/ADMt
ebQX7/Et2ikvC6uNOPlwFNg/PRCXTx6lsMge2DPykKo9ygABcrgDV3DxUECt7+thYHYOS2IxDe//
ANUv+ILgjVlyw58i/P7uH3iMt0P+QOUJsaG8/U7DAuEOQiKmg7MMELI8FbhGwT6pXEclD5CmWX0j
7O/1EF0VrtdSGaXPbw+qmyg9Hu5dIBTm0M0YSkSzfEMzHwwKq7O42k56gC+/mVtJcHDxAIt54Jib
PJAq9PqO4eMAUC+yOxQWYV3NHB7igVrfErHYrt64iFRAxl+kPVrvBQ8SzokXxXMEMg3xCRhX+oDf
RVtMJLuKRGcYHivMFWtq8rD9HDYNOkTXcMcNr+ohAIUoqtlD5sH8wfWsbTqGKmFMGyIRjY0QFKbr
Y6q4jbkJeENhkJSvcAq7nNaVNo19R1syr4BTxvMqNNCKjQFFvdQCBax+oyACwI7grYTZrZTXUbXV
gWcQ8UPHxA4V0kDlhaVMJAMEMvwVmMQFQ0TeJXupeHLENaXXEpvZrsyXUrVY4JagchRCOWGXUagd
B5Zn41WEYmRV8Shii8ekNIB6cyzRbaK4jkxdGcCoTwgGDjG42wsVEhX0gIfQCDfCuDuWyh3PUbg1
09pTlHgIkvl69weOka4IkUoETzC0ShVIlagYajj7PSx23VTiDkK1dbK3l9WQSL1aQN2eGuIdQpCC
oAVWjwwDUDMjtUasBpfMbCtd16QEVluQU6eoXeKliYCerhrrGHjIzcU84QL9TQPLUy6GzqPrAs/i
DpCOS54hxOOYRjGf1KPxpglrArzsOGlx+pbp5SWwxwOogLK2s+Jsp0qbIfBW6B6AK8MZrgivDzDI
FW5ahQx13DyroAUwVYjlv9ThaZGpDChoeIqw0dJxFVS6ZT3jz9R2og86XFFlgMFPa3OYz4jrq4TB
lcH5oadECXNRBGbvNXuE2qawXmDqSxDiBMiFBzUGgkBt+IfChKhAkfD5ndElv4h8BZ+thAast6mA
kh3BuHWy181oJoCnmEapXUc9RdECs7h4LIvgdgc8i/ccw+nzGXTluuOYlguQbQg2PnnNdQa1l4rg
5jNiPLl9QERyK4EXBFgOGVnvI3GPGju3cuVYSHwdzRzYn/vmGwG6PX1NjFKz5lSY8U+I9aW3tQuh
paoqqJVmq+iI4OtcpMfRwGLdP7JvgwM/CI6DlvbsUk1WIts+yf8ASUxl4URBetTtRTrnUXDuTZhB
ZdQc9VFQGjBGkEaBPDLwqIUANhXqA5FNHrSN2ruNVfBKRYIv3z/MyOK4BdwV4ZPFsLUa0r8RMgaP
5E5wRaZnzHZ1oImzdFC3TYaJ5nnN/mOF0vGV6y89f6UqZanOsg4LQF2PMPrZlfxF1g3naDYwtKeI
aTuGqcmzUKnY8D+ISiF1R4cmr7BR5hiNtxyQyryiUFFE7BcsFbIHxdbGYIGTyz/Y0K28C5Q4Tb72
EFopjMjWcBfVxRhB+iAOnRFfDBlUGxYXx/2C4glXr3DmHH5yHy/gvLI9WtdDiwnHQHTvcTXDngRc
WEm7z3OZFt4ojttET7/2aDBTzPExFVxfMSmmn1wQT67aC1/8m/8ACnB95H2hgBx7bvuH3XSmjcBn
QpvjIZAvm99wZBhcur/crdSEnHP/ACCADLMgmrpuFrxCoLqcH5/MsA5CqS4Ms/EwsNBSb/sLw917
ZYHKo/TOL0LtNlYaVR9Fy4hT8eMf3OM41zCuFJs1uf1CG7J9kXP3FG1ANbIcjYQH/jcF7Rr+BjmG
3TSLF0TLullxikHt4gjsPM42Oyl2FSxSEVNBY14lA1ZLADhhexA2VWTPMS9qYiFxBpzOZXuDg1fE
C74DJUXlu31FgGu3mMYKYaw2uyt8gpn6ndQCuoBcmTt08wIr5W9XuHgcN/UNF4TIlC2l+Yg6qbdl
EIU4gtYqA4fKCnwQUC1Nst+cv8RWmqND4lpVUWO9j2tTE9S8wA7sNI8xq8e4lOXBrwIqtlNm8TVP
KxVebEBHlnVq78RACoFL+IZwPJ+YV954fcx9slS15ViwcVuGMIay4xHPT4gVA+EWGNog7LwQZvWR
qLYkZiBp38QFWmrsnEKA4jtVaQBG1KQPPERQNLpi17rVeP8A7OkyzUWpRwbWzuVAG+kc1TwlGthU
pDLPEtKWXscrYC5zfFFxRhehWpTWCtPEtovZScjpbWvuUHrCorvuASmEd4SL62PHAyrg1XTKsWFR
+ZTAumpaTojVAQBlEds/UFg44ht3OEJweYDPY7I4aioQaDuQR7F/iELml3AjArdillrBwEVS9wVX
jgviUSGcRCZLC+oIC1YdQwiKrPpCYWUdgU+6F7zCaLCxfNR1IRWJvWFut4jLYug+pbI4XzHZY3X3
D6EQv4j8PxAX+IvMB0hihNBhsBdHIQ3YrOZWaieebjANtVwwi5CK0q/tKBFFlplU8Q8RplrX4yNp
awv1NMAgpzDRF0dTOtWRJUXZDMYPPmFmbaMsgRBtp0+GLkkOXUQSOgf3OfgAb2EDCGn1BXFDi/HE
YDeh+ZtMCyEdqsdPEvjFaPHcOpC/F8wuld7wK5CM6OToj6FxLkOXPF6w4Wv23G8C5KioBL8T0pas
8EI2xbv3MGkJTFtN+JdWNQPXcbC4ivjIkBr8EwsVBee4kmph+OZfhVRD4Y6wsAIRFZX1kt9AFfgi
+CqtiXB0qI9RYSF2nmpZu2oX4gDBZBYvqnq3fcyTgelxeJVXZV8wqdLr4RBA1jbfjJU8QTwY4Vu0
8pPGoDdrexjIxYF01i3lrAeP+xcHX0rKECf/AAzEaEVjR1KqxFNRTQbs3qUqN2L7Je5y4+h/yYtc
05PFynej+iJBOEFgkO/ZDGgU+OKgddalcZ+ow1kLOCvuYxIKrefMzZUSkvqipjLIJLlWP0gsdcIC
eDQ3IPrG5RLVNPghZpK30wqOpdVOCDBQRHDIISgQPK5RbLSV5og15pXpyhEkQe05hNaqeppdt14i
sZrRUSVgz1l/zNULIOCv/kV6goL8TLJBX3DKEVvSEeI8Hd8xRRgC4ATdwfhgMgy5cwjG6DGbG0nJ
T4pgtiBuuzL4Sli6li3A1yXGs3/MMHcwUZzx+IYkwrxkOgoaOZTI4LgDGlUhSclXCEOl/hheZtVQ
KwGBa3a7inGxnqFIPOgWGlz289b/AIi1qgPtOIAzzr/sr3EUoPmIEsJ65WKWdC/FQjS1NpZlZ/wL
Y5nwzV4bSFwfYRwJYtUCuWVkwqeOZTcket/2AWZG6t7jsgPL55uVQ1pBtTAKo1PGwTyR6vn+IP2h
6hfpHffaJmuXRFK22DQ03uFDcPbZYN0AafmX4oAPBhrnJHJTcEIIEeJWQ4gev+zpVJ01OT0Qq8u7
hTQ7zHSFVXcdVXEo/J7gNC5o6PUYLXEp4JToaaR4XRy1NAnlYaVasq4C1sGpRXNcQxZwjxXUB50z
xUp8WvydSgh4M6s/2JbhA5mThYPcrI2YHUtKwBR9TsgyPzK6aG/tCXLodfEdA6BfEpNFZ5yUtAHz
BFS4Y8QfDZV+JRknE0z5JYUncB1+YM3zLDPMRd65lxQZGqwfXcBVOnR4gYQKFNPcrRlMYkubfNwW
oRKJvAVL53Iv0YcXs9YdQTVQsiRYI38S5COBcZ029I3eCJfMcEBy2VpxThtVR4x9oaC04uJizv4i
MFVXuWYDCo3VVM9yxMFHVNf5ASgHmMQrXIxKCqvwbHnAt0LBDLyCXKWh9cy4VoHzGYRXtiLV3TO8
joVM2+ZWaVLEyrqIbwgX3sQgp5g2CK5jalaqHiBjRq/Mo1baURiFs4Ii1LfhL6AaJSbCsqX65Bfi
GqI2AlQEZdAoPEIwWKozmIeI72UJnmEeCuEIIA21giG0gS8ag7LvFFu/EKm2rXiU3N2ytOYtJ6Hz
CTTQKcNZFwatkYg5XSBAAqfcRBu1rrI26W98xLQeD2jR6Ta/UtOgto8S04RtN7g5ZZR+IiwA1rqH
adqfDBnlpR2iM3C3NjBZHVjF5MXhOQsFvEFpYqcH1MVhxA6jy+mo95K3aidmEeRhXYIBpWVSBdFc
16qN8s2XiABmF4yIANKIy9gS4Mb1WUPB4itr21LmlVuwuNl4RHx0pXHCrSVJweRzBY54XPzB2QiO
6e4ardC8l1sEWCCTk8cmEeAPLCSBCA5XxNpVQ1rfEZc9KxRyqqr6qcLBW81MA6Grj1YpAD1HjVtR
83pNl7Val3KFN8RABS9YrfuYCGUQboHuNTgJ5EiL9afGR5FLXzLbw0uv5jiQgNsYOVCVvJ3M+vCe
IzNEFRNBsojaP+R6yFAdbHR2nzSyx9XC5YSIN8kQiXc4wh9Rgcl8DLHIPLqWuAjbLeYa+6kJj5hb
s13+Er57Qq/md1gHdE9o9z8KlOOiAWGG4/8Av4iGeA6UMSnOSwmbRAbdvMMBdgPfmEqfyDj4h3wB
riFAGWuyi4WlLTXNQhAPp0oP8hCAr73sGoKbjiH1Tcd4RcGQrTd5G1EQcpL5+4laoUrqO43NHxKR
/CfFQjK26BUKfnfpACC3f5/4h1eKBglfzG7yZKaQAvWUEVvnXaBqsL5aNqZ2YGXQ9w6qgW6xGjRj
jOfmBtpbRuRja4H1EUiU+ZRc8MCS3V1VF/iHFONR4cRWuQFoiMTS3MsYukU0eQOZ6U5AfdyyYCzf
qGnrPAUlohTrBcLGgAOUrI5YE4TlhO0tW2VwxjNLI34haqlN3XiHqZlPARBdbwDXcQWtBe+oNOmi
9rpla0hIqnh4lfpB7RWSxcQ2wLf9lNvIjmuoowdZ9bKSiFvqnH7hCiHAgVKyoRq2oZ3FGwVUvJCt
wV2XGt8AByMkeGmtRP8AANvxPUTEL2uxTiYSnElupWEEm2sJpKNLGFxIK9s62dsWyEUvg4j9Mh6D
k+I/6xfyHNy+K5HT4VMXpkAdwyRsPVU8vm5ZZCgZkQyczSbZctchjwMBuM3IYI2HFxXlTXWiR0ao
FoSUp91HhxLGrcBGaMummwqFmaiExUA7DDwRwCGd1Cd2dOyukvBiZOS0NjcYBx4gH4nMhQyMrSvU
r4IpAuupdWCxyUmM4qKYecqVlQ8TnwtlJVkpfNTO3Cso8nPiKXMCN3sl7IsS/R/kdCdV0iEfRUfS
IOo0LtXG7Yhly0KN1pBqkrhi1APpkW5p0PUXUJTtxANpUz5hMbbPEFQ1deIwVusiLdPDA8fqWz4l
rwxjQU8sLU68wtT9oA6U8QlaRQ0kw2m9EABCnxE6DnX7nUKEjmay1qh81YoY8gIGFEVDXWGyAckH
INq1VB1je0YitLx4maKduJi3Ldz6lMN+Amsrtv0xqJRL9p1iRbSGqUNJNgIC9UWm2RqERzU3oDhf
JCPcAkQkNF7QPIfcWFwi+pTaKua/2Uj09wv2POztzjvMpRKzcYPmAQYI28R4qqz3NnV8XKgFl88s
CgpDI2F8QyZULc7D9Xz5immnbiCOzVnJVxVIsrSbz4JSTXgi6k9tcqU/0Nv4lVvLhhw4H4VEvw5d
RioFXzMt9q74g6sznmOz0L2Xb1xLWi+If/UC1bXMdwoAD5uVkZQPiA81CGMAwDTyXxKuUFeYDN8P
rzKjdnhBpgKqv3DxyLx9QG0HC3M2IqnAl4rOKOMlxqi1OfmUc6iPmKeAK4iKo8LAzeKuWAiGWSuK
DyJDWLAkIZkSrWBYDYWXCzbuzAtVqzGXHLhFfcd7RCOEaFoUT/cdRNKXy8XEuCubsuCjpwGXuqAH
3zK6kF3KWROJfetSvu5bGFA0FZ8zlro6uYlm6nFnFkpZTUzwCv5iA2kH6vhhBhWWgMi9UbNCL9Sq
+QmLkKpKSwWEDgmN1c4+ZaSQnzFzhlEePE41NeSkvtdF+G+Ynk+BYJ/SmLMJX8RnYLA1IbxybGmm
YTcFhL4HLI1FuBPEIRUcP1c5gcJeJUb1opyAhBG1Q2i4WsiprIPUsAdfuLToivuChhdaKXxLwuks
2NiaH3uQ4i1dlHFS0jrdjidJJLV5L+hbHgEoWRgvBE6XpxVX8TYmopYF2S5qJ8KeaZRRVhTWGbUQ
pfj4jv7sNlPBCrKQ0xlf2iFOfcQXSaB84F5gAfPcDCxMapNlKNVkrxDLlU9nzBjWJcX6ild2GONJ
CzmvcEQMOFMROTFbRB3bGCvGXp2TilSLFEDfshoPa8HiM3lzaTqLpSVdpfxUVyQk8ZUHJ87ylX+4
WIKg20PuA2J4jH/oO42b06G8V+Zc2rD4n7i4FFg8N4jYiW5bVB59RPc6A0P5mFKUt3kZy+7l3nuI
QFXHI1mmfMPnbHq55dRwhAOKWKe82wUwmi88xyWki8PbDwca8n7lZL89QJyYRwHML0gXVrlrHIJ5
8y0u6QefbMcCvIu4ney/uFlTZ1ZQvLKLWKjyFjED7uLNBVuqdBcRiR1vh8QbbRTfZAr+lhSk+3hZ
jjpbePmPtUwLQvFdse4zm0teXuJ6wpVX7gDIQXnQiqmcreTozebg5xw5VxHnACJF81LLcdXEq5eB
/mbkHTTfzEiWrd+Y59lKYnmtDiHR8RQAeG6ziAPY49RM0NPQPU7SwHEROFeeYu4l3Ei5ZZsCQ6bN
WJ2WRgAO9jj7jTTcL6lJXOElsuiraIS3O1oWsVrb8t2xW79QgRVNtl1c/MwPbNEsIsW47KfECq2T
hi9AdvubMLYfcoXz0RZrzV1CSqv1EUWXu4gE70xgMKVSwzQRAGT5I0QM9R0W8b3KEDfhRSFIKUUG
FU1gkTLHtcXBd76e8WHnVg16jkqYm3zMFButQ0G7sYZHMvUx9RAB2KKF7KJjxFPVzB59Qjbq7jNX
+YvA2Ka5fSzbZYPiZUGWhF8BAS80lvuROI5tKqAdymBQOxKIe6Roh+5egdBtw7bexcVqHd8y2MeF
dSoIVQTz7jq2cEGjWXK6lpZ8FQFEPJsTBH0i8dy8fUMjriG/UvgDzfcUWr+JYq9OruZq/aUkhvqF
WQd8iX6hNOiGuqXggQpDzUR9pkiT3Gv14DmXXiY2wib5Ccj48WIxEDClkNWs89xOEW/DOaAqS558
GS2BVidCao/SUxImYJfkp7Fy3F631Gl/JNw5INBn6ERgC4HDDVC8nCo6HWkJfUgsGiiVdCCwh8bA
+nWMpSQNV3Eboty3VBQU1HhvWttJfBdoJDKqIsO8FBCKjeWqWC4OfMe5ZiQcsl7SkmiWN15lItwA
JSwVz0SoNfi4BvvQRQz+E4lMYexIJJEOS/iMAF6GGdKbekt1Kb+IzD4YXPMqh+6NfErKX8w6CeAL
BNDF4KvfiYbzkxcMuG2tb9QyohrhiaDMwVDbD/CXoSRU7JbBPoTKK4e4aZdpf8xOK90KZSRsJwik
JcHO5s3GCz8TgV1OE0HWtM5mN0fqF/04uZIjtKY49RU+YcUJYLivL2x68xgL8BpTuCJpd0HuAwLb
rLSE9CthtpMJKfeRo8YbKEsFl4XF+qAJMfMK6XsGKJxZ/iPTeS2/xLmE9FyVLLaadhK6v/ij0kWr
WJxzeFVxQB6FqWJUOZ/UuB+b6ZnISmgvXEo6nLsv3GJk6Oh7hYgmyKzzEI4LRaflG5DbpuWzOiXs
fMOgdlv+y0+iH+HJWHR8B+49PdFWu1B1Vd9qrGILLyjv5lAR19RQeZESEDgBV0HtgctGmziEyR4Q
NRYZ1ZsYaOi0BqnuKl4yDqVHcsauIjSWnmXJKcEuaeVZ5j2jBl4sFlbkUkfA4seCPBHSNHhtuDov
jalps+IrNzumpdQ31ctB8RcDVC2SLB5q5jU+P8xRLpva/wAQp9b52Lri1g7LE44bF/qJPJCJwS5Y
tILpiZD9xPb9Hct0IrrKSgJzC1GraqblRQEhYXR5jOJHhSAv8zegpwVP7iyt9vTCqQsWX83CLf8A
VEuUFSO4NXQAqrlMYWgaWXFnS8yu9V9AM07UxGj4FqCgXL6ElhCcVVnqJgXIKRiIEvPQxahiK1Kr
qIrFAFRYxZuFAVeJcqfXk+Jd3qU6IW7tL9IlM24wJrVPgv4uCFFPKL+pVvt5FHVQ+I8jxUYxFRRr
3Vy18dpiq+JuHnDbl71YrQR6vMKL4mqTp/BhfCtg/wDNgjjLF7KWAwrQl3f3xK5FQC7Gu/uEiahA
8JxVBmCrcnOejrR7yOnuEcBERYCwUC8YGi6T0/7leURwHMOABGr0/MdzVIOF7+IBQaCilUfOxonQ
GhYP3zBHAb+5h0DbnMe4qEJRKrb5gE9O5WNdwODz3EQU3PijQ9oEDVDJQwPWdT1rmNR1vmHRb3gh
TXhREp+Dntnlcr0MKDb74rmFKrHg6hXGRyTtcige4uMBDqpyF/8AI1qDtfqB+8lXXqBcHujjYK0c
CDlqCEQbeBqXBZa3XPE8qZoOCMqkYCa57jDBvuLV1caw4zzLU8qgwGoxorbOognKIUjH5iAVlwrh
3AFHmCDbG8P9lV9cQBJQtEFOhRLfSe13AFbwhxEUtzai0lqy73/kNvvNSnTbKGxJolqJfEQ8r8wQ
6PxAx0tl6qXzeNsrhGFKjCoFXBsCS3hVRR968QBADpRLeNNV3CUGfRxK5ezlykrtw2sRzYRcY01x
Gd3Y8wEvQOSKokrG/cJXcoqFCJsgzIooQ2NxE4CF6aGhN+IODn2fcqdDMjvMCo9w2JAt5IHkDquK
RhNRoFG2S3F+OyHsE5BOLiOgh+85VxsGy8CdBOfXf2hMi4BzOY88g5RK/OoJL0OS4m8vRDcrJHoD
uXWq5yUKJl3GcETmPRzKvTFh36hBC1YVB1jiB2w4FIqsjVdGBVwbWaNcTmFcUDIFUpDOUSeWR/Q9
QckKrwW9kt/UmuSNstKw4he4wpFwT7lFHEtMEazupWxFNLhCFkCsKl6kHhxC5aqndSukAcCLuA2i
B9HCOC5TUsGw4Y9bPhbHFi3SEoecKHqpWEoci4q5CiELxc8nuUlsKIQROhnMvW4jlHqGoACntKps
xRmmY5ZRHMoPlkpFM1YJV5YcGkekA8HqCiQLOSX/AGQT+W+I8Q0kTpXUIJpWEoB9AOziJh1Cwb4T
ese5uPKXLxAJKeTmDHIUArIDtea7UMjjYzKgJlbFBXUu4+4BXSrPEQQ+NOclzunyrxAAbQ9QCDtY
6iQ7T9RqQ7XIthKwKcLL2VtR4eJmaFB2zuLEbbXDc72YE8TcEHjtzbfFxy/Mr7Qttwo01CnMpOA3
0Pn1BNBPlcdeCSNcolHjuNnas3GW2j5pruzQPCyzxi00TxKPlQsqCpABVzkEwEJ6R0QAjn9xdByg
JnxAduINqLjeg7qJUKqFdTmNp5XcMAitI6uHo1QGyhyGA/Af5I3EAXZCiLdChzCUXOELLDmPS6BR
HmlcTvlUwQVLk0cEUkIdBl9IK8mcQocNKOi9iWsIWXkFJIvB3L3OIVvqLuMU7dEDtaEbu4ego8zl
MkhD6lkTxMt5QPc4W1Ul0QIwimh3iPwqh0B4hMZL7OoPwUAMr5ldgxO96kboCU9vl2M+cOuw1lNk
wCqHeQmDMWCoLFSBXC5bYkkOSYSh1AHBnEbyFKHLcHyYV8VXcomayd7VxWYgrZv1M1ij3RcIFoCP
CVBRC2Urj4lOSgHhCtSlEoVcZBUIBcFDUDz62m36lVAw38Ag3lAIUB5fxLMFxRWr5g0QY1ohzNmH
vhhmulO85Qwn0KwQqU1oVbFdW+wQX+oDUgj5dQtuEW61Aqbh2habh7PYgy7/AHHEaJ3VF00cpoPH
ZH4uBXwf6jAN8eFQtpi2qZe5XnBwfxLyYTix4GcAsjZK/wCQeIVOA1cWHBA6yfqOzcbwMJcg+fFx
kZCUNsNR0aRl2i//AJAyNQcDwiVC3GIU2fmMjiNJAs3DgGyUkYUQ+YqJX3MRd3KbXRQyvcrlIX2L
iHK2Dwws4N0uCNqKXV5I1o5/cOG8SlYLoBVRpI9+RKFAWxzj/kRrNWDn1BWgRg5VTmnq1elm0bFX
YziF9DAds5uIy+Z1kLVJaAewIhyDxeIVGv6onMUrke4TdUQa4smDDAx20PqCwvMpetgUtYKmHuWj
Rb8xFlg8qjfLvERabYpxA1F4WyrEN6goilLw05iGUDVBN2mgF4hHXOHKXsD/ABDsagPhzDL52sr2
zHTlOeWOEwckGQlD5ZdRQADum5V6gtQcRpuPcVgo6j0tC8lY7++ZTQDqql+FYHcdg+xHBNLkYmjE
tDqIAKyx7fMcnwsuodkpAnlACgo4jtq3b9RDFLRqKgqmQOCmgIYIr+5SzK4CHCtUX/XS13UILWUZ
c1PsUaD/AGW2K7PMqSPub1SqLr5l9BKxP+wSG7pniwyu41c7vgmsVa/EcOcScIwBljlfLGTFGvxK
zlNVHpDgB6hIclxdREsds3zKRc9j72GBe8fFSoIVdwmKw8RKhXPETbOg5GVg2VksxOCB6a0H+YQQ
LWedqgTs5DKNgsaJmVtMRoM3iL0uWsZxTBi2oEsn1EEIzWFcRhX18k+XjDEBdhOmAJLFxoRyCm3H
LMEBpjPqYnTBCTkVFbBYObnVw7cy/uB4B0l99gM0q1r1LQI1oiIFJn1Aa4OajMFnxLNjLyb/AOYP
i3SNdx8BzxxLMFVT1cdrop85CVFimEcrk7KkVHKcy6FrV4haXAyA1cu3qDmYFRz6hQsVT9S06ACa
EvTCVoUs4lYK2WjguWng3fRjndCL3D2LqZxNrzTYtHk3cVFC7qIamJs59Ttm3+EJRU6gzDW3tcH4
VUdOTmfNV6h8Si1/iF5wTjxUcFvrfHMoVpHWlycuGsBlvmMdaynnIPq2pefiN22inLG1MVKc35lp
GhX0gLxGLUpY5Cz+cgaoMtXkjoVP3k/DBgi9w55ZGOrRz2C4dqDPMJtF8EEQ2V4KJymWFe7I6EAU
HDCAmL5WEC3dc4xtJ8FQVNlU53WNt6M/ENI6w6nr8xgDBq/cJGw2/J/stsAur5IINg1voI3GjxP4
qI0L5OX1BIN5SgfiNTD1tvH9xQ3GnAwglpK58v6mAqLErNTmfU1tEL1cBqos+SM/J2qdXUCikKnk
c3LyUA1dIEeI1WwHVNB+0owlSPmUtoX8SlF9X3KSaF+4+GFs0A6YRVYBfEChttX1GVZjeIMhfg8W
3FYiBv3UoQLDj0TAoUi7fEq10t3kyMcAcAO4bINtl8QXxsUHdQaBw3XDGMAwo+JuX1TtLdMraEE+
cgX3Fn4jJudauNzALOgqBVLNZW/+2PncUjPOwLAwKUYYQQaABySoTT+yAILqoSxHAfwSpQFVbpD1
LG90+L3BdnSwPwQU12YStVXAlhRcdmg5xw7G28oP3HMqfqKGkfoNd+ZVNqiuvWAMaLQ+Jes0UVae
aiPfo0uG46h/RBXUt8pVS7AMv4HH1K18S6lkqdHg4YBmfeStsqcpAfeYg271EEIA6px7uBQwpn6y
GTYn7uKsnacVO5VidnIt/iMtkre2SweIPV9xp4ajAORcSxlddwIv/wAuXh2S1MCHaqx6guuIy/TG
r8hMCBS0vaenz7imspOeeYKjQI7L5/cEZij8RyYCyaFhF73mVTajK95AVQ9eZZ5mU4PMVnRLvviV
g8FRfdTsWskYXVU+Y6COs8ncwLdU/OS5JZtvwRqNX1K0oLvmY7gjVNwJauYJOC/c57+paa8TVnwk
GWmDUKShd+I7BMfMJgU8hzzA+y919Qb51r5jqAkEd3E4tdTDgDFC3DlmMq1GtK/96ln15I3mi7cU
vlAa+5QnHh8StE6ARR1bg+KuU59kErrwDHy1EB5lvZVBw+oPBRVOSx9s9FfMqdbrfFSokaOMUEo1
vGS0VK1lYxdella2n9JZqGRXbcH1rtGALaDGd2eopr4gwt0/URaOCB6dLDUEhVLa1lSoLoIx/Hxv
MqiHCtjRoFa1UajqpRyPZA7QGTt0SsXB+YPiq9c1KH7OEagASvcJUq2o7aNW+K2d2B0+RgApWoh5
gEaWSiDTlt9wSNtZ5gGBrVualLuOLxDaGtavc/8AsFlFC8y54rP3CKC8I5AoZDYqcX7hx5jqQN/O
wqBm+oZpwquA7NuHI6X6lvN5TbaN8wRdcwhKcP7pkm6WCngN2UXUDcBPRX80qJVK1c7hPCQIDbZc
OKcOSi13iIeHgHiIpmaCMHyYIAeSiGaKEs+WqfUTqqvEqgKcmC3Dm4Nq2M9VMsB4PUC11TPzCdqO
D4mYrWnxACGCvvIQS0pDERbPFxa9BS3oiqsLaD5iMogDIgJT4r3CoLKBHk7QfcqE1bOIt96BhKVl
KhC055hG2iMARYErzUFCd+epunB5ZTIWjZ8xhcGB7jrwVv1CHrQDM1G38woRBofXMRHuiOVSBGcw
OcGvmM3Jb9RwHtQvd9x8Ab28xqWKFZeVGK5d4iQFDyJwZGRqt5qLZkV/FxVrPC7hrQCAqK30VW+I
wcaqOdhiBID0KmOUFuDBJXAFOju4xNrV14+5XNiOl2DlFjX1DXNukDwRQzlqU4QQ6TqIQC3Z9k2k
7B4qXJAEp0r3DJjSXt1sVOULBy08yqwXL/77g20JDOxP8h3fHthvEsKk4AV+oTAVtVW//ZRW4Ccv
M7fgCkouDKUgabpE4JaLVKEu5s2I698TAUVDmWaC0PNQyBOS8l5GU6N6gKyrH6JLC1wtU+orThFZ
jzdTSkxTn5j9Aiou5DjYyAhMg6IP5JUJq/5ZapXDfPH8x2qaPVp/sdfcHORXk0HZrI66SPXCHQbj
vxDBbIndxDXYPFS/Q9w94QVAKbvubCp91JeWYF44/wBiiLp7RvVD4GsjCDAiiz5hWhRd5dQ/FCH4
iETAmx/uEZYoDzlRVaiN66mLnpLYCUK6vJj/ALCICz8UcwegSHbUdyQBHRUyxYFQCDGLRZFIRtRE
K6gJ6saIpPaqL4ti2hEG6QiHN0wRp/2KocthaQ2q7RtxeMYISgqAdCE0GIMhAIeM/wCShIEujkJi
TQvqIbjgFshxELqVp5Vb7ibh8tWr/Y1wbkpcHTfat0Oo7ZZBXg+YDXgHkaogez0FxY1LdQNlbvL9
Fs1R6NVRhAlPEO6sucCwvioWhkkfNEopQt8rMiV9+oj6laXyeIYKKfLMhhNLo9yl34nwQRRq1zLQ
KVO4tU46SMNN+ZSkD1U4i0DKHzMPe8S9QVQ31OrVqHM3+2HlqKAYFr34ikg8MvwGsDLinEoKeGoD
AlxpDivITmFZaBvqMpbEPO/xHqSH6YAO1t/5NPVsXXxDSWjl7qaiN2fUFVLruNLWpzNK+JdTmpRF
unUNCmxl9sARlfEEqKhOpOFoDY3CFC16jGWrd9UTRvSvqPBbnJvEKB6eYxnDt9xQtRGCKu6bhQi0
fLl/2N23XXRUICy72HyCdEgFNAOefctIBqnuWmpa3nAgHMEvnAepAsg8YVzMMB0S0G/NXhHehHej
uIuNVfPEY+APnH1dXjPABTzGsrZXiIaUi844jxPNl+4fDaKsgnJq16uWAggtYK99E51KyXvVpTcy
+i7CPRFeZT6Hk4nJ7SlJyt5Dmc/y6JEIrRWiaFbAtJa5olqo4NPmBIDZRUQSx2/E5btf1DCs0LlR
asAOJfNTp1NoBf8ALGp8KIAcHS1B8RSR478SzxstdEHBV5BdX2hbFRteNgb+ha9ys+/xK8AeYCC2
Ox21ovbDYCuVhKFsKbdLXxFUFwSxYM2N5SLwu13cYKC+2EmzXIj9qCFQAcx4tcA7mHi35YQTqd+I
514jV+40gV78SryA3cbk8N3Ouj4eJ7xlQyuxMDhIqh8xA3sT7nhUIQWmgjpf5T2+FYZi8lzK6A/U
B1sFbZnQfoSnyDi+pkwUaPm4O0BV36mmxDHmPk+x3EAaQlwA7VK5HdhbG7jku3YsvsLZT3sMkTld
bUvQ8EAQvzKPOjcqoN0UiLGGnwjmCcFm+PcER9jliQV0rEN8g0nqPmAyzkl8LB7c8p1kdNPG9ROA
LQKi6lSK+YBwbQ/THWgNTlS32YL+KnX+oeWphM0BvdRnApa6XOJ0BdVHAiEHwuo1YuCd8RfdaB4v
ibcSx42qjSo7uNTOYK8zJlzHGp0gc0WdQMoShzVS0DBeRYnldQdVE2R51Oy5RTVnPEoxsgB6qaLy
i5eIiNLw3g/cscBJp5JQx4q8VUNTfVPNQRTljjYKBAeTMyOhMhxXn4hwtHNV19zQ4ALOZaydsWX0
kVVowCpwgUEriv8AI9kWqjntjdoN3vCKyB54M/yPFEorLrx8kImpqcc5CyMGNb8xkWqoblRQylV5
XuP0UsaDxL/svy+Lh3xy5IniutBrvalBQiEFbDKNX75LyNsJQqwYbh4RlV7cd15gU3g6JEQqp4Vf
5O4D62JiNm6GGdYWPPG7DHbXZbxG7RC8t/MHqQLQ7XVw47hapa3JhvghhaJhTUfezve+P1GebD99
8xZN7P33FrRYpT9RD5W17ljiE6q1olHDBtSPMvkLyShF7DuoREyDQWI3LFRRfqWJU2kEChOj3FEu
FRb/AOqcKEnbYpnP2At1/EKZtVQsvu4hVPgGooz3SHcQ6qqGeH6jCBTePvIpYBZwdQzNIrfu4x0I
ocnVnxHRta1iPP4lQflni0v4yBh4JWCy4KW2G6efxOfEPDXqDKvtZSHNsAFe8CDvhSWsEaMTTaYN
ZPB6T9SqpQZGnmVSmCuMbDzBBKoefmHX6hlf/kJjcvmnP1LDT7GcTA7Rd6wPuoUC0t6JQ+5TXNbM
UcrGuHqPIVkFzXXRCPGsp8y9xwe5gXp5j2gAabONafMTwQPtO7y/zBSo2OxCuwqrBHOGGhx8Rl4Q
VVMODirvy+5TAGyfOwEWd09+5ZEKgBX5IaSnkbPqDCLzyQOywN8QrDQobKuVySovjjZpo3FXKSo5
YXqFzbVrSLDLyxOfIWs2BDDOYFtVs1Lp2N+MiGuiC8QG/I+ZaHGEUsjS+ioyFx4jJ2M69RQbYWMs
jYdXgYNWxscJbPGU4QDScbp9QkEVV8bAOOqF1hDcGZrn7l2Oa0FwYAQseWHxlyGF3m4DI2NikceI
jSDgWXMxViDiHNcC39wMD9EFRHnEtqngN3+JY5T2wULDgnYdKpQLKgFfJpgpQ+ZiQulc8fMFTguw
0Q4oCtQjooHjv7gBd5DKTe3DHZNO2oEXAFdwy5gtYMInaQRfGg6IRxGsN3xEpHZ5jrg5quwuK6qK
hEstVe7lLhV4RahF0ZUFmwuHxKxyB07K5B8Pv3CiWbbGfeYghxq+BuOGSUHeCbPJWYEKxTsoawcL
lIaXKxKb9oHCn5jWKPBMAfvIR479s2IaDg2VR1yEBqEsO0NL+RlGN332jO9Vh3K6WmJ1BWW5g9eI
XAHaYqe6BqWtANg6goSFK+IT4q8bI90z8xwFla+4iCmlrsHvQRruUu2GvAXsJ8gVeWBQ4tDbEL+X
jvmBSmCDSHtwAbiAj0eYRNcb8P8Acro8+BhBB8jfqBUmqjyQCWVa1h9QsRn5PCD1HwdVb5SH5ykB
MIDEuA8xy9uR4JU1INPKZu3S7b8kWmfybDJ6BqpdbBpbnT4ws8Q81FWQqhZKd1lx3V2Tl3JTIRBW
ckOwOnm5opGcMPNoLxd/zCRk58ofS5WYxebF11Ocm4I9yoq7leuq+D/8vG9+URe4J8iy/hg8hW6/
7Ejc0nPzDg0Lioe0joHk74h122xVepjChinkiKMMdPuDTl6Rz+Y4kaFuNjlgANt1n7grqOCkX+oV
RfbbGYSulPlDr9VJfDxZegQobBcHh8SxcTwkiS/HK9fTqPLLAW/cpkF0bu9lcjQKLA2RAngp39QA
xiHTxIxeXktH9QYLeaX5hJSi3Hl1EAE5GjGBFc45XzL0Bxt3A4Qdp3d8zwWGHofMD76TgTxbcT+y
VZbp9RI3219H5juNSG9+5TsLyur8xyQuNq+ZRovjx+KhXPsUU0qKZ5BPmnJkrpYt/wARxy7gWL4l
NhvmHzLVYSpTYoQhDhp3LEE4NN+Yhws1qc9pBElMqrefcp+KnAxTRl8SwaqIArT1UafwE6Y552i2
7zkqD4zstg2FV5jQ1qV0g0VmbwKi4Slu3cHXhTxcdctNnXqXPJbay/NS7sq7xCRfwgr4qKwuv3f3
G+FYWy3OpTXZ2ReAQjmnqeouoET1FhZ3ALucR8dPLVnEq7uIUWts9ooDe3+oVJoPUpl3N1vzOrwI
orqBFzenuZI1tqmC0OUX+Y2xPNu/+wTbX4cy2OrAA+YQihvmv74g6DR+2FegDokSgycdppN8r/c8
8B7JZ3HItH5hAUHk3LWb8iA2oKq5SKEQ8gDF3JeE4W93uPuobPYP5CctEvMpUWmUeoxeg1nj1Arq
fkd8xd0dL69zUJahoGGt5j/pEgs9y117fmKoquYFdNVLDi5toHxFTgbzFDp9pWS44HuACQTIBAr8
y8Dt8VHWVSS4hrdvUUKbfmOm9eI8wqtpTZj0+IYbChtsIz58NtmGlD5hFUcKBFaaHbvqMm46tTvK
CsNIfkKsbpdYMOUa4F7DyEHSu4OQjNNTtgYxfXkKLzfcCA9xurWhgpynUINt34lAVx6lAdgDLGI8
CUFfcEKzWC2+ZZPEXHHkUs1vNuHpi8PYmW6z+k8bwRE+5zrDtWvmNE2u6XmPg/AOiCVBgWiOLatv
zKL6waiOFdnJcli1VVnIs89wBQdQx/MpzQ0bMcvR0ckHvtoMrELwyMq5HY38xBaGtsPD27GJno66
/ESbKGyjjd1EqwNKlInRt4bfzEF10qD+IkXnnV/EQIPltLl18yjsEvOo3cSaI6GQgunqCeKELPqd
kJAjAQzVVBVw7TUegr2b+YrvTtWCaim8OxSlLKqmZDvb49RkG3I0/UARE7GpVB8aEKLvXMHYsu7R
/U2hTnXEDyUt5IA+AN3CSwMTh8yhg6L78R4CA2IzcHf9hrDT6lYAaxQZQm7Laj5XXcWjeRefmBTn
sfVxrS+7mnPACJy2lk2BcUycoF9vMBhHyFfEYJbktL83K4neFiA5CMFhBQZE/t3hDVq1Uvn6h1mm
E/iGAXJowRAW1YQyE8CVcc6DQsvwjO0PDiC3C7pwQEqo1GGSG3L8xGFjUB1cBeh7lGKL0eYHRbS4
OXu90+fECipdNbioRMSXUSaFq2NaQsbsPKpysLWo0IZd1GVpol4jX2NbJaBbVVCVotQuEOg6FcT/
ALXyRRyXApcZfkXTfUvtLX5zjzzLIBqrRJb5a1x/eRqwJd3SR6RlW4uCUwu9D3rH5w02s/MvwtTl
IZq4b4hMlRXVyDWAnkulo/csgKt289QFBdqoUZ0RBrIk+B7jH6WfmNg/+oj7B5GncZhjxrqFmL0N
aie/F2EuJAVKS6fPmFFuTwTh4Ls8fqWVG7BjRrcN1A8po1vvINUa6bH0qKFk2v1LA0DrUqrTd1dE
zbSygLdlC8oQuGOzUqyB0ZwYE4D9dFJqPb6SVwdbd/fuWKmkcNTIfhC1LR0IKpcBNJM5lidwHFnv
HA2F2CCnu+ZW+t8hv+ZZ03mr62OO7XUE2xo6VLUdaAivZsclU2lr1LQaLadRbZ9cj+4Wvi2SgJc6
1ZPAbM4O4beU2bFAmqD3E6VKWsYgdoxUu95zAR0asM0uEfTq8RvwTAcnH9RLWeHoY3L2uoUpFB49
wg4102hFL6TrazJuXSy0hoDwAoge/BBTAAxwGv1DRiC2bcf+ckNiE9yQvDph6uUsgUprhUlwxblQ
HXEt9W26C+433cQ0H8zEzl2Dcf4xQFB8IPLLqOfUHSyoaUhm4WnlDqM+qgLxhSg0NfmPhfgV59RO
jKw7vEN6iUKfwg3hnIgxIiU13giMJaY5hG7wvuZANlIuh5i8UN8DeY46CjCkXrLrBvxg9EaoN8/E
RqxUVKixXaKpfkqIz2gop8xomFvKuIGFC4AppNQ4+BhZcoK8oTFuFp1lW+RoiZ+4nNk+y3uYsmGu
IjWxdH9wlwDINM/ctlpDw54YOHCqQa4WXeJadHupVAHw6yWXruVT8sRQXBgo2xboeIF40HP/AOC2
mnqGiab4rxKuV2CCqgXD1Mo0cODLmoUu2lKHhrTmFJGplIBD1C1CtNjQBMpxkSAU006ucLoVRvcV
yWDOI2ENF1sozXJRx/65VbA5qOeBbojeMaU8xcAF6bcp8Oz8fEW0odEI4oaMghAXCqHUW+8TjKjg
6ihOEipsJb3C+pQN/MAq0kpek4qcScAX5gqqzDuAg7bPUHgeBFVtLRRLsnJnUcANFFnMYKpecwlh
U8NmfdAccQNejI9Qct4uZaJycobBGuKm7ZBTH3CQEO6gL0KEESXGyqHxoWqA/qUuPLiBQosGCFUA
l+GJABCOmDIW1QWAIgLL9QwIB8KJZEDZcGzFrFQBUXxW1OLIuCIrtjiDRYKqpdY0udQbm6Er3Bp0
OCHQMLD6i7xp+5T3Q1BDtgb0KuV2gXcdk7tl1iA3Krv/APNTEQj0CyHNFMqjYWoLwdSsqnghgmFM
cFB3UrwEFDqUJ7hyoEqxesCLQzJwyFAuHMKF9yp2hy52UCuFMZcVR4lBrrDpe4Jda735iWkcx1H4
zszhlgtAqjDvMMFcAqMaxLuopVrZyuClAq6CD5ISn2ow6uYiWaLlMNCqu4aQTGcseXGcxeoNGlWq
4lECVtRtAjGjewXCKuoagOVS8OBcMq4IXENYKoI8C8wUiKIIUSdkd+YEQ6VUI7VLxd/UoVxCUeiV
iErFZCUCoa4iPjQjKg/08ReGeEuHzFaZ31BWJDRdeZassNMhdSBZR35gn3S05PEowoDOopmUttUP
gPTGe0X4DRqqhRUrv+ISzklnBf8A8jINA4xyN43ospcN1dlJwIalKrdrqUmmLga0DTQxKpBqPHmZ
36I1bWepQZREQKTHn4gVF2gchxGFSgKDXxOVeKPI8ykm0thCVqKkb25UEygfm5TCA+wl6UBNi6Cl
EHpiFXYjw8zruDRyxZKxyjcJdE/IilmJEKvxGVjGgtlBTzgsi0jIBh78TukF1Mh8NOD9oEXrKC1+
YwZ5WipbCfI4jiW1YhmCkCI0RItV+IRR5t16/ccMQIPZ6+YkpLSK/PzLnLAHvmZcVGnBFGjY7TxC
GpMfnMOS2HfEOBotrqpgWA68M3+ooDl3KbZvbfJzBxHy4uWWNzUVX/YlFkB/CYgT0KL8xEpDCmWR
CNXsBOIVotXC9SpXBdKyWX1gHJfcznKvZ3B0PQe5X8Rw4tB0A9CrGQkWi9p7yD0SgQdV8xhFWrcA
JSbLcKb7ot0gTzcpzSoizxFwAsa7eo+XBH6DKXObM4f+RlorC8XBQwJsdmNIYs4YpOyKl9ZmggOS
KKVq5zLkeA4ZaKHzKXQ3t4Uxdt4ByJUAABYWo2WHYT2EPDACVQdEEdI4unjx7ibhdFupT6GB4wO5
Wnil6wwwP1zf5lkIth2vmN3KvFoQLHw1/GDSUM18xTNkUSM80UDXzevKcRFA3YWOhOoviGAajYbe
f5mKy7RxfEoWVBozm4UHJztOIHlph0f7CaiyIFi+4kUIaxpxuX0Dysu5jGIodrFpWDWtpHiFTeFF
t1a/mZmMTKdVBOuUyt5jz5LG6aD+fqPGUXGBYQvOkyI8AviCva5MBoyg/wD+jWO6ZFUT69ThcZpE
CoFU08G4AL6hXQmC3EdqaqOmOQQM74uVgKXu5eAX03WQFItjfSE4zw+Zdd5eYcGjd6hNKVy4w6cE
r1DpD8IcsbrYgeOP8hNBVOzBhpy9zojCiqlxavJmcMbZayniJRdayVFRHN67l24F34lkFy8xfwTP
qUUtWqC4xnVB4WURX7rOYbpzPlHLFB3cWcLlC1yzBWEoDbONlEA1fMoNm+Zj5DIXXC4aWIlEwKdu
XgYBHtnGOrRJSy8lLKrhzybMPLBO5aLyIYoYqKHRar1pUTUsuP2rzcC7Beg3B8SwnWEHmVFGwVzs
JLnsm3YjOCFTILBQdSN36RDV101+UqGtBA+UcCbhTliLw2togWw9zLgfwowyGgL0/EcBAr9zU/Ay
lWctzAmPZDgAPEP2gbXzcZMe6+Y7UK/CI1MDW0lR5JXDzkQSVkGNt/nMT3ZSIni4lo816QHxby9R
BFlQ4wAX/BNeodSlqmV3EsOaHEyEtX1E+LhC57lHmCicQYO1dsopHpIGhYq+Ys5Qr8QWBZVuIVZv
MaFtZDutofudnByiD7dUqAtRSZ3UJkcVxBEtagQUmty+KioDC+JiCUdeZWJqxGJo5GqscNReqlce
Wg815luO65qIu1dPzCoKNn1/2GAxwEq1sCnUoGDFZTQ1Y5EYTIhPVly5UVeanVlBmyvA9fEsRE4q
C8gGZLOIGQ7lD7R4mXIjXEcFfAlJ/mi5IsUOZaiLFsj1vzKqFBlQywlqT1FpIV6csalyFvcFnFNq
XljornJS7lLS7KtnR3BQlUcGyxBHVfMBouwJc8bTj1ECMJ4GUALKRuBDWvExhzo7jiwC1+IbKAcr
iXyJNbgIW+CVBy3jxKTS5Z1NKnHRWRwbQLlXqjE3mUwaD4CCmrNngn5UJ/EcqMUDw8S01f0ynLCg
vO3ZQkbKe2FiqKB1LFfNN0Q3Zba5jspsIL8vzEdAmU9TBMJ/KiOwIAU/ZGYYUR4MgPP66ILrR4K+
5RD9qbUU5ramn1LKAWFP/sjNF6LiEruhYosEH6RAJoCm+jj8Q6AOvaj/ACFSmEc4iLcAH5/+xq1S
yHz39y4ri+GTLfiBQ9x5dR+DmVDY1PUHaVdd0LgATf5Sh9F64GBjaKatVKPvZI7s+ZZZAoJtxFFx
fSWPcZ56O/1DzqjkwziZcZcBcBLdNmiC6bQO34r6lWmxv11KIEbqvYC4Ba08xx8pcL5riZCqpRct
InWCmQoPNRgZdK+ICAtHCvUD+BI6YygNYsxfEb1F1+Zg2Q3xq/7G+EVrKRbbr3BHqii/tgAR2c7I
ITkS+tlr8HacMMDaNbfNQVh4zhM6jSOVtcbEsRhPQLUQYOVKL+vmVNtTT7gKsHIfMYVCwq3DCsFj
/wDaW+5Fj4hmLW3iG81hRV8QXuLVfmI4DCHwsEAK5TIOirQPfEsS6NldQzjoIuI1Gl+eYjs0UPzC
mCpp3KoBYBs6jqvs58xicm7zuoNNp1vTUZVbR/UKhKj+D/YTCQaL+K8w27P6dihDyPnYfmjJzHlA
IddSoTgA8SqdDxjCDVeLOP8AsbTQD0VESl7oae7hMWJdrxL0FCeaWRLCEB4YkFa4LWjqAEyUK25I
qdAZZa2K0BN9SldxrQ8QBsLPEteFHfiNg4JhySkAXP5hA6OLAHNg5cyV2+yC8ShnkFRq7CtQUl89
XBX/AGMdwLU8zj3aHn+pVK2qx4JWUsX8RTymPDYZBjD4VANtvHMAcouQ9xcBABeqjLPd8RPTdrfq
ZHFrvqciUqbxsroU/eCa7TwfXuKpIL7hDdbHqzmWTgkYA35isLNZle2NwFeqlhtKioqx4imKpScX
EqdKQvmB+uAgImDgzsdFkOTR1KA9GNbqP1ueBQfeRzYo3LCxs6nPhLey40G2ShgC6i+Jezrf+QvB
LWKA8YiZeKlVlzQp4gKhXFNRcigHneJxcob74hh+NLOPUvFBrVXKQrlRlJYqmGsuCc8JeWX2ka3g
NYDCoWzd0xuIc8XNSF5oGlpqedg9wcJzFvCa92SrDoZ8R+V/wmrjaPmVQoZZVFQC74Oy4wDLtBwA
DeXxNEJRUFQ2Gg6WovR6sVtC1dxcrXocI4I6c8S3gnVxCiMgNvAgEB1iIQnKpmDdF3NGjUby0N8a
ygu5LQmmj5mF3qEOVCsQkaesYhwaqVNG0fiEVXd8R5VA6/EPazmUrarcjywt/KDOGz+JdLTj/EQR
q9B9wXdL/r/IOrWlQSuWoQRwl/UL5GA2yoDgscBGstbewUL+sZZpbXgQUnlH7jagq1+fUozpYqYP
FCEqUYOjyq4Z0WLHuIS8HSOB8EqJvZ9wyxWEIsUN/EEFvH52HXANJ6aj6xbDnVlpdyqqefuASh2v
3APwFE1HXPiXWBUJcFaR9EOh1R7viXBUX/UJ5bYr3DuqrlLwLNy81ptfUG6oeagByHcQVy9RxOFS
8QjtbCC+oOIS3Z35hfAtc+UAVyh6bOIR4lIFSu4ER2yGbRABKLBLT4RbpwiZMsQv2XX9Ts116iWp
a03dxhiED+kaByLAOWG5oyOByASVV1lXxFJDcpUK1msEPNShozfnsuDarpw6h5PW9DLo9Q+gNsGv
mcN8vSOxFQ6qTzEtch8y99qb9XMyIEWdpDjEKQcuf5jeVFj9wxChivglVIgzG4FUi/gciNjZ5PjD
m2P8ECwi4I1o7iUEMD4qCbAU6oxiCahKqR85gVXfi4cOeQOroO4ZkCga59whaI9+IcQhke/4yUwQ
VC84nDiKQblwymKeicXSWdbBy0pGuXCUYkA4+6hSkhW0O8qJbI2DEuWyRXyOphmq/psM9UBDKaR4
aQL6yLqFdmuQYdbb6uouiKlYuovnPDsN5LZwxUAMJKF+jccM5h3/AOuI8FSN2dmVlf0uPqBUeBuY
1wjaXmcIXK+WrmOgOHg5mzUQ8jYQYiYKsH/IWPQDq4BoDT28TbojGg/5DkjY28R+BjXJGd2pVivL
UJxUItb52XJPCnmUxMId05ct4Cs4KY2oJ2Pl1FI84O0TS8Rst5YK+5SCi/8AkPVOPklaEzDi+Q7l
DATzOCxtwARa2OldoNbYMDIFdRhy/qJgVh7E6hEyvaeIUvsE9uW4sw4grYMxBA0WrcgOdIjhfJXq
EU4tq0t/mWQAjQPUNmerUC8PiAfAr+XH1UFTWHJDnxLQkWr0BhzHi9G8af5AFIw4Hf5IJ2pF9BuN
czJMs3+Ja2/nu2KbGrnlL2arZdaO8g+dRCKOY2eyLVviY4Z8v4isVoxqUtcLtuBKd3f1MVqHhY1S
0OTzLk1eod1ZrISEUnPKkoxUtgYC/PzDQAOLhMbVtwem1sQ2KrwqeMl1aVP+wmx2eSFkKcUI0moO
33L0bW2/CNBbNAf4i4LA4eGI90xfggsR+UrVFnm41cyX85UGVEqJwpcg6gdmyjIgq1fUV6qrlGED
molTynUSGmktypm+BZ4YBs7yOnQ8DE7ZAB3s/wCkkIrVVMYlnNRPQBf8TkBu/wAR8RtfUDK9Bzds
oxxFwUgojXENoDs9v+xgcLVdRDlRE9XLt4OIhRtcTWr7XcC5HkQhoMih3vlmNyujKp52BAMBvfgL
S2W/qYP6LTgxsnA3nJzYrCKCHofUF6m55lmM0m8K+D3KPYFre2wZ0f4jGptLuywhfZ+ZQJYPcLW4
f3DfAVxPJFhRcw6tRfqEEHseIUoGE/5ELhTxzFWBFnZKA6NZ8S4LVvWQgETgivZf/SWQAVq2EtDX
ngqKVzVD3UakFXknNWUqXz24Xa3/AGPxaKH6gOEU5ZQjQ8wstjabqFvVaMaMAebldTlC5QNK1bzD
cUNi5blLxcUtwMbl1LptiyB4tnh+o8Ru0Ey5wBzKpKri47RAYLylM8QkWVNR+aTVwUoU3cPBwNYH
GN2UAG13cPMC2XMDpVqGwm0HqPgFwftfDQyvQ3cm1eZcdZe5fUDLeB9RKQq7vEeIsK14mXK6efMG
IcgE4tBtS08qZ59QG2OiV2hOGMc0LlEOIaPkgYSrHyXK+oVs5aJ7BI83b5VoN0rc+CW9nKviUhLu
x5gENR6ya+YYsuE0zeoAl4mct7JdkLWHcBLW20+pctziLku7Agi6TEzDeUSo2Lu9x8xF7VY97CGc
hsThlNu+WvU4a7BOyPsWleIpFthzSRDjdt5vCEroDbyIAYuM5lkwOvCoaua0f+8xDfVU8zhd0Df5
lkaVNF5Uu4bZRznEchvEq/cXWa8Xx4jtbHgpviJHAKHB5ucqjCOPiMVa0cvH+Q3CxTxgS4U5G7c2
HYftb1VQrpShtDOvqE7BkVeWHCIoVc2VADQBl09LKFaOjqNLjQLvZYEjEenxL1hQpL2Rqm3E5mWg
EK4gCNUWtZsK8DB75hEB5PGVKw2NROd/7KVAVl+EZkIaIoJrjUKq5oc3nJGEnttdOZ+oz4UnvBih
7Yli1dkN4LoFPMCyreIxDs1PyxUuYN1SWPhm4gx1fEVEZivmp24fcsdUiD2MOhAg7V1T7i81iob9
RcKBjSDxFMdb3RRmsAtlbIokGLIKtd+kbkV8hWEs7GlSEYjVij9SnWopo56gCwqEu1NX7lpetsRb
+O4Bca8WweJLmtav8kEC8p3CeJeiDP3OXT55XFAgIlfKFDsWsPyRV4ihX18Spmpa3VKD3F4jCCov
I7F9lxdDFbLjY9RHiNPMTb+Lml8fMDN0KXTuKrF0u+cl0AQoX81HtChrruoQTl+Tuk+YMoQLL8wG
l2nwfMSCkNG9bOn6CGe4h2o2v8o4a7hClvWPnYkHDa1ixTjArzkQOoqKgboibs9VHZKkwVBuvUZj
5699S6gLbT9oxoJQsEKq35lWra1WryXxsq0iLqlW6eI8fsOvrfmEOVsqA+lyXdpo2fVyibeoBQtu
ChGMsZWSzpTLyE5RiGgrmWS120FdcxIE+QwFzXgkvCrDbiaXwTXat/UUalruFboFL6uZLneijqCg
DddvceGaLZwsyWDgtV1dy0qVVvH1A1cFPhnonKQerGWnqlS+4zFYNGleY3D5KqYNZre+Iv65zvqc
XkSypes2uLN0e0FYIJeYFW/1OAOIbX1MZq6iaG7lgsV7lqsXfULu8mAOH1Kihu4sRBa+PE5RJr5u
VvJallQZpNi8DcoCLS4zNFBVf7C3Ztj1BsmB85zFwK9F7MF1yyNKlC+4ABtcKMmDQHmedlueINEO
yxZFe47Ddp7VDQ2PGpU4mqe4Ag+oCwy0iy8g9+UVpdFFD9y6pSxseC3iFAkFdPmLYCwsJEeLKv8A
McROm5AgKKClgXXU/wBSl0DQeYSEp7I94YQewCARHc4WuCLsHCEn7N9WxmDR5l4Zo7lmPd9Tg07R
6gYbWKohyKe1+JvoSODxLrLHMdRQOyjMjgyorPTClZVW7hy4laXb3FysaRBcW5EVXGvg1zkVYwgX
kZabMYRzTVsDL2bAOpY8QfX8TjO04t9wTimW/cSKjdwMqDNFs3w1R2HbSng58R3xXOxEo4XOEoU1
jeSgmeNqvUrgGymfvayU1RL1e4bMLXaf3DE2Ks1XdxjRA58vbDQA6Ngk2Ap6iSyE0P4g4YzVwWB8
KoWWJyotjEj4WvBgmf5Tn8ytCYq6jVm83rxAjNDXbhg3Tl8e4K5biFURQqp/cdKkcUS/zCFNgmkr
64CuBLZPcjZokOCdI+AtS7Xn5i4NFBrX5nmZAl/zMwQg7zA2WrXuibkNga/UJJWwra9Q2QMtrAGm
aSffcVKBaoDf1A8KJOQcSoixWWPUenirXMwC3evMatsIFbmWWIuu4qtdoeTxEdLLaNRR4iRjehXG
xTKrRKLCv1AVqh02X5uUpYBei4eqVamb3BZH3SyFNsWL5l5veg+ooRUG5brGGiApR7h9OwTgepbG
WIurm8tug0kN+YM5whQU+b7f3KcJFAdMT1tgfNc+5ZlCNz+UcGxg2PnmMj80UIHsaISdEOwKpPiZ
0t1w/K4QUsmYXiUthFYIEyA23vmEO6UvD4jbombAfmJmAI+H59yzcDacSuuFGqK+oyoLawV+o6YL
IYlQfVUnUXuG4WE6ow2Kq1515hK3uypXGDk36SOuRqgP5qUHLVN13BFkgMUiTC7BNJYHW18xXO2U
zu9lDAv7mcsNLM5SHF36uFhECgg9EcAOQUfiI7lR42GwhQh01X9xugD3CNM8rmK3Ai0d/wBlNEAN
RHi2I2PeI8/c7y4wv5nBKubfHcKw03PDKMB0TRm9E6Kr99RcgdNl+5Y+XDfEP2AaFQgl2jEWvi2U
ahO1E6RnYH6i1ASrmoC7Z+YBSbLBE/EsbllOkwHHIaqcyJsVKq6HX8wc2N27sYJzx3Kh8q7Sp5Op
qVWDeVYj0NDkeGXiHlLQh2eAmIL4XrlcaXvm27getgOd39xgtK4HLLi5V0JnqGPEl1hpYvgTZ5Ke
LVLrSeUuHxCgxwUL6lSMMDmFFzF7X7mrtlG/c6EHKy6UbDlNCcQNj0bdQGA28BzDphxaLfmcMtqq
4iNc75GouNealp8EvEMZaWRqcJw2Oq2GIKsDyQf/ALFtnEt4oCUBU5gVX/43KoO4p02drxFyOGNV
VZyxg1HciO6GBoW2BFFxCEeVZbvzAGA0lXsI0BbqWgk0BlFceC8QMOShWn6lVL8BEXp3VihFTXys
U+o8UDblXXLsxH66DVuNkGxsn1KIj5Of3GTD3GHWxmhOoLZdRoNu9MuPT5iSMIXm6OYcsKhcVTJh
hghQZcHrSVe3j1K5YtyPEXYbiQiw8qhQyOoJxmr7fxMU4ulggoKo0ZW+tiLUJkV4tlBx+C7+5pzW
3NAnoUhICVynI0YUgX3GUDok3L6gRfIOx4m0R5VbGfFY6hdXWi3cThO6e4dC62X9sm4U1YeY+2iU
doNYi6wlME4a5MkRi2tRkjeRNHxFisfER0poHL7glB6jpuXuOG6bnLwO4QqHsaruOQhdy5bTLU3U
oPDkXJm9LVfxGOzuD/F9HJcIHdwETcTBUR5h5j6DPVzYW3lWC8Hq0COHtF2TAbDq9JYB7FrKYMOh
uIt0O0AjpUOgtWCyWu41pZYYb5lzwnQNAUD3cOIRqTCplVPIhYALTyY+piyyZE3C9lpBIk7KTggB
lRCwWH9ZWj29wxzGnsQLfNaJ/M+RhVq4dJ0ry97LCR8Bf8w8Ai7FsqDt0E52L2VlhkXUhAslLKDl
81FgN8X/AFHBFHzd18TEeWIr74A4YbEBYoq/UTvvb+CMCKvSf3CJMW3piaVroIprgEDkXmE1cslB
ZLsxB4RCJYvUyml8gP1Nzk55v0gSdwq4sJqaKloBxzv+J2ADVx5aHIcwMReLdR0jDXD1LW0SHZjf
E1YRH1yCq/UsJ5FP2Mbb5dPcViQWHiJmic08zTUFNdSwSWTj9xUkT/0wEK7EbuPUaCGzyA6Jth1L
uBROvK2JpRwU3ESo88iMW4K8/iUW0RUYsAtUk72Bw7E7E20bgNjmxVtx147QoVAE8J4RsbwHb/iO
5tAP/EGvJ7BFEUbT1DRaHULlu9sTVYjbLmj/ADF2FfGnxLL4clxMg1hwQHYD7UZm4Nht/iIMcvAV
9zg0KU3zTOLlKQwxTOBlSXu6Er1OVo2XR+pgIba2NKWszY8QRGHML4t3iIawIOY/qMsLUCD46YIo
FQCu+5Zp1prKHUKphZLYRK35vJRGETbO38RjmCu7PcdbUQO/iCDgFn7RW2wJWRpQ04ZGVuNHDHXj
fGJxAkrQeILoQNguB0bFciOCN3zJYsijXJBmQiGsV6uHykMSg8VHdtoFhepXrqxTUQ2gAuCI70s7
+YizaUOHh1NF0UDuOLjDTCvqJsFp0AlsSihtq8ZU9AOBYekoAyn66ihwFkWBcPTmrGAGyrcxYCvJ
zcqOBrGO8lCDwICj/UyjAItepfiNzNGITkrAGlDnYwoz1GhWnYvZUAFOw8y0WOYFy4vmeDyTEAap
ib8cwjTWTWF5Al1iC4YiKC8Ip5nEkEH0Go1AsstCGXaWwh/8QjwrVwygdAkqkWcpwgnzOEHgtieY
TdBvlfHETBRAxadwVXqgtMrim4cpjF4+SRfEq0LIBR9slJkL0DVXlZH/AL2goX4gFZwsjOiUCH8R
vR5q4Uf8hOiTaa83CF6wI1vj5hCwd2W++onBue56lCv6mArYgo7lmGQwHCUWn8R725ft+JaKVfUp
Q77m+wK0RCAOJEzhvUzwWPJBopE2II2r4JUZTV4nMYK9XGpidfSHmWqTq4k1YbXjzA4SPBleSL2I
eQlYz5J/cSWpd+0WAZ0dokS7PlAuF1FcTQ5cUHxkdg4xHMZcMB6NGOvTniWDTUEpww8i49RYD9Rb
p0joj9QEN/mNzgPUSUsZqdQ5FhG0mJWm10KUjFl8VDHAFhihFQz2zIyigJdsaVNjbLDl74YeA02o
eRTtiFXXJ7uKBqRaXUWE+ASjlw0aDAgFHNBBCGWBKFrVXkOGRzIlRW7oDDdVbEHh6mo5IzGMNht2
j1kWtJzuYtx8L4eosQtqcAwUiADUbcssDuCURzI8oFwnEIBnJUQGHpKnFQ9czYIDFkdJOaEqN1Uv
iALMa3Luj5JVwZd1H4xyikZgCcpqG1NUe4LfyhRzHHodkuKFWwPKtSjjxMJ3LleWm8CONBL04lq8
YpUqPUKg+0LKHHxKiLPRzLYURYNY4Lo8mWUFgXHdRIVHVQhiaoZHQb5Du4W9BLSqInECrCFJXNXi
5XEQWuodAvNsih5IE2QGWae4YENVpCysFRmu5dSmwCqmiLfQfqb0htXqPJdacLlVi2uNwOQN03jm
CxL0g2LhtuZK7g1siyknQdgzeCSuvcAfqFxzASqox1cCAB2jiZCrL6iEMi619y59Hy+YEoB2QYVC
kCLwjVhCGh8nEr7W+MiFsDVEuwZoo4jkZYqve9j3mOm7FhRgzpcphTLg7Cu6MquZTrUX0OxMDTGv
Pc4wHLJkisDiIZulx8eZgociiPFSJzvxKK7lbldtcSKF1v1BoFXYUYZw1UtKa7iNkFSkE8KGssrI
aujxzBUGJugiqRGiF15FRtKGIVwyj8cPUeAHAlsgBddSmKVNN4jyhiIRtEB30xu2Zntjb0IKOpVd
CFcMpYLC7t3kfCdy9fxEDl1DWBheojBuGwLcQJwcflEw2BgjZYCI8QxhZDA8wZNa5XHBLx3E/aF0
0DsYg6GyyKLQg8tgFCfBXHURUFaMl4Sg+iZBRgaFFHLDawn5+JVSLKz1GIqba8v+QIaOIZ1MJIDT
txz7iGss15bNkhrRZY/8i7peIqi6i1ek1HOx4WvYVkYGuKnPhK4gFLC+IVqlj2eJQjavQj4pBVRx
ATcpV0Ra62O5lgfN4jXniG+Lt+D6hul3LqOUOYIqy6gHhacNxiCdfyIoCUUQL+eIcyyG2DVxuMAx
Cr61Os7qWoH62l9Rwm615q5x3ygqjqDj2XirpxY4e8SGXnH7jKgXk1j+xZ4QxjJOPf5R6qg+B2fi
Uc9kZUqMnINzf3FFdRTT+/iDHLRVBfEG6pW7VOHzSr5fqIyOwDPVyl9sGl+onwINnJ+Il+otiWPA
9j8Sjwslvyf4wy52gWIS5zCaX2P9ShMcNncPebV4G7uAlCIqUHkQ6PBhoP8A4g8g0vtdkGie9oFf
f3G3Hd6zxOHn4ahW88TBwna2BVx+tTTW7id/dKOXmVOnt2NlEVoVAvK647g2FPXgIIAwWBcsghKI
JqgT03VZN3zZVlcSyxsnb8IhFfRqb/iVNCC8OchKQSHqIK+2y98wAg5LvGVtUMcNHMqBGzxGCysj
YLMmOIimMbb7iah33/8AjEMTXDACxI5DR9cQBTnFQSwapo9Sh0a7TCoZn1sXqt75IGVZg58wyNMF
5by4mWC1+IBABcIzF1TCq26+XmBL6SvvyxEthJ+P+zpIUQ5WqbyM9ORgaC4q+5aYbdq5gjzwfMFq
R9OIjI8y3RxBCyFxCU1azzBXT3N4HApTPpTlXJ6YeI/EzpK8R9d/LUUaA/EIHWjXZdQfQbsOZYC7
6m2IBcBDMrYlwIoeCo1SwMRcdrOMvlsapxASnRR+JcYX3c45S8jcY9JqziK1PYVKlUBzFhd6+YVR
FeufCD1pzL2AbFLjkCeM5jRliwxOW6+IJ6AcKlDe6tSxqNoMfXLizFR1fd9TLF9bCl8B3NJUoz5j
FzfymZGN8TeoqeZeRfA+ouC3D1cLRaLQLN+KjL1LEgPEZBqsLLlsSkDm6Dy+Yqyr3/cCAtYkGEp5
p/koB4CoWzXbGL6wLEYNgqiVClK8wRVWlLzFeqgvEiAcq7PyoJd37Ki2vcLnTQTiCKPdSrdNSvEv
2QHXUF8Voni4Fmha40hXar1KSDXXCxCoK0jMXrdZECbVIfyhMKpx47mMVZSoNeB35jMqC0HVQiQt
bpouKkZSz8RjolwfUvb8gVVLOgU1jVJmfNyiIByPERwJXkhcwU8FdhqxXXcUBIdXXlHuAX5jqL5C
LRUimVTl5hQEB1EtlP8AUAtVUVGVQQnV2dIxyW4dpBUYZVVv8kZKCIk/CoUFHS8RlUOMe4yECtfU
tGSH74mrIA/EVcbk8xyDavNxhLgUUkbbbwiXyTCKaPmUcVkSHRaWJ/71EuqkL9R0UhQi5QujK6A+
ogShFZxkAmzPxMrdt8wYKwCNht0tMKiDN/MAHn5PFXCWyuvGQ274MsJkB1xDBCZzmEqIgPiIXBL5
MVNO5FpUJQL24qVKwdsFfkv1GyjDp+UxTru1+oCW6DhUdQ11L93VFrKQFafK+onpEzqWMbK/zFDP
rUtbVKnBOeCKnv8A9kpbAU+/cIjoC9a2AetvgPcoxpjXzAKleDwsFwVyr2SgANo8yxqqdmsRWNU+
L7lAFt39pcCgn41nSoGRPnHL1sIJRZV7Wb0iVI4qvyfMpoWnZ1FADJ8I6rdA+pfBP8nLGF1WnsXH
Eq/+v5ltpUVcrGIB4i5hnEGBlImodU5z1NL2facldzwNOGIXfWfGyvaJW9U1FgJWjSWwnFgxaN4n
CcD7eILbsXftjr4mcfCMEWlHi/mViIC/iXsEnmdxm8oIA/BzBT0KP5mEldFuz/syWGy7zP8AZciU
PRW9z5o1SdxkoBQWi+IozQcI85fcpubdrsefEsUok8OLm1X48VLaLgLdocwKp0BcPEDaDVQq2mYh
EsOyn2LsFXWwPQiGur4Y0ZW9qrmbajUw8VKrhyDh4hx5NVfBBfy0qllp6qr6NinYrbhfH7idgBKD
f3EJINsBxyZK1AqNtfcNDSTv9SsVQJt8bUJC2hERfmOgcCWdF/OS6tJpjYWAUAgfdSEX7EzR60VQ
Ipxu+TGJMIXa3nJyxSUdFPU1vCnzT/stiEo8pqCvCyFlOKjwsjsqj4S+18dIeH5jsqegvtjrdXji
UuubjTgL1BOmF3JktRdvvoitrrLhErK0h9yhUbbRvGcMYdm9gEkC/qWRVhlkRR0+7mUa5VDvO5QO
8+fMDQQUfcuwujlwVxB6Y4OaqLPwB6BfMuPoldHmcLIYioLZXXuF2MZ8R0ZQLfBcDFituPXCjrm1
/cRVBc31kry1dvqE0Q8xsG+oyPCiNoQWwNS6EG4tG9gc8q0llUU9MsRS4B2QKzuXR4vqWXqpf6gH
vpfE5yqo+Yjjap1F1iCThqIBuuEctTXPMfivzM/5BNcLXO9m7cu8pHxDGTJjhKiqlm0x5LdZ/D+Y
1xrVwtGm/eMgNiqlxMTdRMugmGx0DpcHQwK+E5iVito0yulw8GUTR2tZRJ4LfMNq4LdnU4TUdlUL
1hG0DGYfXLcpxDl8UsDJRY/EJZtjsQu0NvicqVweI95S3YIGtLosgRwNr4gp13weWZOlQfEIlAK4
hsAo4HzFc1zD2zKqDi42KHFXFpdoYAUsx2ALhkS7zjmK5f8ANl8SpkGDjZtfIQgNcXzARlGEjjt4
jzKJx2L/ABC3ShlRir5QVJEDfiMJRYxOU3vGxSVFbbu4AD3tfESQobtyyewVPDcGxli/qDMN0zGY
k9vcIjREr6hrUAXXCygvXb9VFg6NCXvmYJQZ1kOe4K9eoFaKVfM8io+6jUrlq6VxFCaypiRJTbAE
VgV+byXNCjXzcRwR34mk4q5XUo+WFeIKKVuvERFIp2opGG2/Mcibz0Qoa65N0uA52Y0pyiZKF7F4
qPkqKYfiauVV/ETRteXu+ZfE2aRZTPqdQMitzu9gIBgkNjBVMyxA7Xo+YQ6UDR+41663LEvIs8wb
0APqKoXgHfP+y8IErxKGL3BmXR2BQp7YPLqjYCawCo6R5YCgTD6qG/Wr5IvIyh9zXAB+k8NAJ9S5
xLceJWakfwnbFSvOTzuHviWlDyvuNpTpZyQI5UrHGxgdKGniWR2mvxLeh7tX7mgZIabFJ1Eaq7gD
FU5+IlCUBA6EkE5tPUp+ugncBAa6fCXCRaBp+YQijr3BoKIV65ldxKA3b1BgriH2wzNYo+5pRdIe
qhmCl9U8wIDmF+yABcXD3fEFQrCVmcDK2IFBQhDRdwg547lrv7iU+XxZEk5Z7VjlAq7ZyyzKK+AN
VAYGS/mBvWIO4vHXV0eoGNCKPwRp0tNtG+DZm6k4sWVZBAPYTbiWg9X1DAI3E7RiDvAWfNxPpJPz
MflJX3OFjSncweE0KqFOkHLUSnzXMwjbyS9ixArK+D+4+t0IL3ceqtBBzY4BzzKbAbEdXcfwzoef
cRAkYqb4jdqRB1aFbiUs7jKzWpjvmFYA7srolXKnU6PiH0Gq2rvzDCBSXzcqdBaoPHFwwwzWbHKR
dI3xtxUhoV2ZFmvwU5fUq7USFnuPhDgUwufEs0LBSvBLKDxFuRrF+rxLRibpVTc+xewPLGjh7HX+
osEleQcTlaXmk8zqChCByzWpQPdbAZh6MR5CUI71dTtt36gnWoZaj8wvAj3Lekzvl3a9Kr3MADTC
u/kipa3A0XR+oLUhUKb+yGXoJ9MJxZonis/mBUXt44Ri5RTF4DP5lnTV/HMKqXtFOj/stG1APNrI
JNQeNeTIaiiQ8f8AmFwOpQC8RYBetSkHyUo/cFgaYi3vhhlWzYq7ja0eYjjymVDhLhMxe78xcur5
PEUFDSc3ENso7zCMAWr1iA2XrDTVmPpna0a7xVQkBpXxXmHyKx8tlV4HBUAaC2QKg136qGx0oeUS
PbojmQ1b+5fUB5OIejBVxPdVq69QqrSKFy32C3yRjpbHlgd/k6jRarWbOB5mgLzBahnuLVM9yhe3
3F1yXGdcx0riATeY/uiXY8kZLS4floj425c8uHqiVWcr9wm2NEgIOo95zAQZXMZOYScn5e80GEMo
GF/qC9JQIQ6HUQEQ6X3ULZtMJvwZo5CyUbiOSck6DcXW2aw3SM8wdel7gKqhd1sQjBdTFQoylMHJ
w/bL4NGhxENEEpwXFSm2XSDQxdMIw2DsYJwVYXRseY/qtw2LghfCIDgUTqq3odxs9x+oHZypBMvd
R5ACxPXBHEIVSMqPZTqlhb6A6yHtzCnUFgPIu7fmBNsYY4sT2MFf86hUtVvioO2UJX7lT1bx7qEK
1rzKKG0V8bEUHBPhDomyc3HS1t0kFXmvEBCnEBZoH5jTUyX6jBBaOY9F7v5jucgDn1A4G5XdRNLF
37hNAe3eriUWEHwqHrEHv9RhChfouHo01Cz1hNcwFAq73sfAqULmmLtXVwsCpdC/BIoG5WRzYNW2
DCeN58RsK2VRvUuqfQEc00BHDSg5V9y+VstfMAj2KfEUkJ6mbv0DXHmUshrX1FimKs7dwbhrs2UQ
x5yCl0JcrUCticSwIKMKlzAGZzBYGGIJ8EKpawgI3CWxCl2PJoaUMZcC8R0NlG8klcL6vOxngUXf
nzH/ADYLhdVw8HM4KcKLpg68PMuJ0X8pQxl5FTOI+e4WkPLxUv5omdxCXvqaCASsFL9yroEBjiSx
mxYiX3EabEiRdXb+WVAhLoYuymRXhwjFG67zi4iawczxBrVropy4EF9UPMBQnb5ZdOQDnfEPlsYL
D/JfqoFXmc0AFDnUFyRhRnhdGB88AItgECnsg1KI1zkdh22pKABoKPV8x8KMDREjwRyDYpigD1Cn
moO1A9IW1dQhN80oag4AcTreZRbjP1a/8grENqpT8y4yEvamIsHA7rmNt1wwbqEgg7dQ3g3Ld7xD
bgo7a39RjLgLYvuKqtJMKefiCBTW7a+Jfhmjtyig9wqPHuZABxcc0pVYvPuZRa8xXiJ3tDseo+E1
AVuqe4EEF1KoO41BApie4oBwwaElZeWuOZ0RZpldDfUStaifcRJSWDgQNPyK6IUeNQfjKvDqrLck
dD8ni4YzOJJfN8Ktzmv7j1Iezi0JYWlCn5ZauHQjbkJu+sIFC3zUUUxZg+iV5MVFZKOUADldyY6r
BVIzf1Lz0CkXjvI4PpoD11DNnLvA8wGUnPZkd85kNmFfAKguoJQsIOFZbc4iq3uEarRWWkIo23gh
eiCoBjAtzsHhvAATKvmK0o8DhyWM8LgaZjH4DXGl+ZiAQoaqocqarKq+YcNqClZ014mBEpNrKKcO
JvsHhh8gKsFr4YqVZeC/xDHdM6B4mSVDoZ1BwqrhUe55uEBdiTobzDe+TxsTU8F+X9ReShtTjqFi
UFcBMPxOsVGxoFl/MVEoGNpZvriJN0O+7YBDMAWlY9xKAqFnb4ggBipHzM8wKjwKtNc/mJKpOjy/
EPg+ZY1HwPdtLGKIYqkFqWVBpOYrWFfMQ07lrPXuX5Mslg3zLEtK89XDYbTlY1I6kwVLNHqDqy7s
VANCbF970MVmfjaZxcOoYNvdwlmEDt5mavFbC8lQqav9x2otgyxEfA5g2Q0LXcaoQ2d4h2kiSlgN
t/LKi0WD9K9jTMbIwXhjB0vLYNV8R5Cy43ofGwx7OyeU2KDmMTkS5UWuyy1WXMC5vxRCrnIqN4jo
NBp1OhhBW/uXFExXWGuXse7lwxQFjJTagwJT+42WFuoAQ1I5TuHGXSZ+5VOotPceBDCrr3DotQyq
iCEmVT/cSGWMc5gtum30qat9NVL/ABLvOIjCHe4vC45ZsLeMgckTHENkhebgAc5NK/uN7rblN/ct
oXcJoWoVC7gdwbmvQUq24rMqgG0S39zjQvPJ+Z2AKq4cneNGa48N5KmscftGJw8KCfuHafoEr8xN
uuyRXBFW5ikQG+IAtKiBzHmPiFaUVGnk7iP8zXq14VMQLh6qVdEMLmRTroV+5pyZk9qIoKhS10ai
EtTsdXVQBCbQUAXYM5Wi5grv+ywevMSuNDLuog27IUBWuYIAEVY2fRLKDWLyytydYvWiLA59XBMN
0OxgJRt4iNHAwd/MJb7mghEst/Ms1SuR/cfYXBZGOxtjouHnQSlaluIc2suMbMqQ3UR0m6LBf5iy
ds0f3F9J8CEYBeijnIusLo9+I3YVzZX8wgKui5fCIlf5gfCrDUUkBQ4X1LRgLt6nMAwzV7+4ixEQ
tXMV1tstH/tgA0l1jwpbFyqAN3kACUK5W/MDfJLabGxXAupL1InW17nN4Ts0/qIKqNGKaEqllQFU
G0dJUkwVogPXGy26vuY0FCqb1F5FnLVIKqlmckqTiujXiYwyaL/qNTtlH05hRiA3i/UIo9dkYGRV
7NgAqsJDgdxRehBQNNbUXRXG2PzCgHqOSnzFFzUXXiNX4Hwk8zVIPfWx1YSjT7SUazCBpNhT7hHa
B2QCspf44q24Pj1A5pG0zeWHkS3Aiyuai22LCxfQFQsYHHBXbAKchYGo4aVnIfmckPzZSXRWBUu3
tqJNq1dl+VqUF/qA0Zzpf6gTF1T16I8oYImgeIxKu3RE+6jLzsHZT6vRvbgEBI9cw0BSuWfmb5ru
otptS0r6+CDCCtCLktpZ4uCvu3RinD8yL4qXwvSQ7mvCMhMII8s/curQAYNeNjESoXkoQfbz6S0d
MTa+4uc+bM5erB8zJdKG3EXCq2rvYvR5NGwQU6RF+bm8UclsfMZSXBWRhaLnht6qDn7Wlgzz9iy3
AbK48EvwV6gABg9y10LFb8SxUui6h9Rrlc7FlakLyPEONMy78olLFUhV/MGlaeJ7H4TTGJVnT36g
C1OFc4OsqkPDHCjcJdJ9RcogwHJ3TLHvmjoYjRiXaLaB2LiZJHOCp9rsKjCdhSLfkmxI4E2oBWFn
CvqULPwt6SqABvmYCHSrqAXAgXCKtl+bqVJHax34jd0g8PmW/wAZ5e8h/uckBYlWWg+Iy+c5D4lI
wR65ls7otbolIvTpx8xY4Hx3OyLBB1AL728ows2qaeGadPIlhKEhLejE3z4xPUfArR6mSS4E/PzC
3nIlMWlBveLucYbVjn5gZaSranzFJq6kOvqWoH9ZAA08JbIEbaHRFa0QmkJArDYDLpCnHXMs0qpW
jNAxOZ6kbFFcgBYF3SCmxseoloKAgVYHc2Ply46OfM3/ADGoX7Utrv1KyVZm8/EzAJeHDCxtXQls
Enzpe/bKMMN03EVuuDhi0AAy7ReBS+DRGw3PSojXmeU00ezomnUpqFWDZHgR8Zj4jJeplbiAomlh
vcL08xbXADqJackq+F1zL+MipNJGGrcJT8Q8ltWdw/oWM/uL8pifxLQWcqdS8FWjVQjmdykl7M1l
xeMqRi9HjtfymYAKxEZzajyi+Q3bpHDthpWRag9waar0xInpUc25meRu1diAqXWI26XSRRHupRBv
ko8pa3Yu1GE8dzXEpIvkwIkXKKoDG+qRQ7OKBIjSaIOTVIV72MAcxdQ65tJUeyT0GPXg7SqmoBuq
OfiCOFdaMvBc+7lhmt3Gm42rj8MO1LTeJhANKTGGx4fiP2dHg+pXhWkucVMpHrrockroG8mcUPBV
wQDGcR/OFDkRci+fmCFdGNloFYKaLjE+CJsAjolHHEDRCEi5REZKu6HmPUw1cfWQNEGe4ZgrwtrA
qlat/uXLYTUNf1EeCVblzuVN1LFmpYEejycJA4agFk9QhIh22R1yXQBHaK0AarzEhetH9KmVINW/
aLh3lBMlVgzhtvmPAaOAyOKIHiou4LfaLVLaZfEOp0eWBVLoh0bvVJMrB7f1FgR1o0ITFV5W/wDY
pNaNY1+Jc9mhZ1cQ+mi2Q7cBdHcftjo67ZSq7WcS5SGByv8AM+CID+prSYVSHjZrpWAJY8emtiuv
UUG6gUjNqf5ni+V9vzGzQtPD5gWIVZ/ECtK077+ZUipoMZEmWAhbUQNJalNSwMaut/M15FhzKIPn
QfuPKbg0yAYjLtKEcVkpU1vxLA18S6g8g5gIgHQAywUVtQftechfSasH+RSxagNiJRbGtrzFclgq
pTE97Vk4plsSldIOkpQZwPMVUltaT4lsVpXZBSSUKCjmyhVH4i+guK5uK02BGRrKD/7Kd+HLdhQ1
QwUCTwNgXUXWnwlGJdHPzMfUqqyXCw9aGkOlwQNIe49wZgsuB8QI+5pekogwF5EKTpiY/c/D+I9E
egKsLY1/CRABmryvOS3lFOY1zEe0Z+COioVss/jhyr7jucgpcxhinA6xh44jnv6lLNVUMhLFUuLj
5fIJbn5I/wB3wVZVylWAWRP3Dg4oiu5ZdeIaL2PZcCVSsnmN+kdtKhTluG66MLxz3AJbNDHYbtaQ
JtxHK1zu5Q5do0+VxNpgaQb5kyfmY9qD/qZX3sNPXHHuMWah5n3UXGJxq0g6Q1Ls8/Mb8YHWZAIk
Ac7qyBzBvNb4gXV1Q27xxACj1iAe5c0bDRp6mq7FM5hFkUNyz5lFBRjz7hLqi5RY5PcMfpSDQhPB
EtFr8Syq0wUnuXuy9LseYBZ6Fhb5mPdwMV/7YlRfL23UUuKxOXdsXeW1MepxuXQzTkFMgUBeOo0c
UEXX3FS/L3VexeV4Zdo88QzV60LfMuS0kFtOPiOHXCnPqaL0OGncHXss1yn3cNNV3A1p5qIqVqqc
bsxVx6L72c4cgZLalBsFPFGXvzMziW09ZExWYxbs+ICZNETuU5EgDPMFAzYBfifmEBOtAu7HQr28
oGh8w+tHTqufWQ9SpUwYXDBRNv3EoDKm16lFktRqldwNvjGs7bFbZhVVPuBDd9iET4MDlXC5zAFI
F6lCgJ4uNUAs71Cova7hkygomz0O4rKiSJ0nC76j0a542dleuQbGawPPceWthOGWnjWgRHinLjJh
eUWjwoo01EgU0OkWrCNlRmwoXl7LSCB5bUWh66CYy7X4gCwQl7vj1KmivcfYvqVTmBRYJAv5iOkW
xAWxsMviJBfxGIDiUnlqwu/zEcyAqVk4ZTpARYXI7lhVRdkseW8AfuX8KTCElBkDIhTg7hIFeGwn
lKFfEK4qZ4gqpeGpixa9GeJq8HpC6QakdreCRLEAahJXbKYd9vFRLC6A8BCHAK2qhgWPqF3wdDAz
tS2RO0HiOHZC2gW2OYaaU8dziCMA5hmtVsPCUANDmio3hEvCBd7b5bCQyVsV1bXiAxuvhkqLGjwT
mO1VULqlYVGTpQOCEwp00joQcBLwoYJ7gAVyQmOqlqcIAXacEqBae0pjFIQMkydiRxrM9KN2c+2b
tG76PuYpHmUKYS1CIWi4ds4E5vt/5GqFWAHEwkA5LvKEqozArlkzWRKSFtiKPzKbADEV7HhKxXaw
hSx4Hc3Cq7qF4FW0Z6hnD0RVQUrHEN5rha9RUuJ6gJzlcRyoskz1G1q4BO0qcCI0El1rX4ZYE6HF
O5xsXUMDkXTqZd1dNcRAAOUBOKdolMQLWwgj5E9xG9DE4RCqh6gQsMfmBw/Si3+ZQClu6SpYvBKK
rN9NQkaym6jMmg31GPK35S+MuWouEvAruVsKiUKIf4WB7l3wXv3WTa9vrmCiuz0YurqIduf5IJ6T
bT1zBhpt6L+ZTAr0OGu4pHIoDb6iqBvdy5xBTRcrKgemgXOCUbTli+FikdShc1tKgw3k+upgFSq8
kBYKK8BnCRLsVBtGsc1Uu/Va+VTrAbRxkU9ZscnmDuGn2Lh39A1Vyt7RI4r3N0hKlSL5pkoGNhnE
KgGwyBiCcYWViOPFSmMaBKa4ittpNc9RhX7AimabqZdypFoselQUuC46uGXtD3RKywWxyvMGRsSU
y56RVy0g8wma1cfxBKpYhEBDMdFq7ZHiU3HmVBRfEEyo862zjnhRw9xL0hw+4ROBhC1kY4mfT9xZ
hgp5f8gCq4FOkpfXc2W7jlVikstNhJXouDiVNZoV4HOJRQmhglTOwRR7iuwpOGuZuICjZnmOSnkc
3dMQc0sXqVlA+4yLYOvmDrgc6P8A5LwS5c1XAZsaVH0Tey5rllEVIHS9wk9AWzgtPuDbogaOYJ4K
BDaqcsZAql1RBSA5XOXNBhrriiMTeVFm+FgUq1s8xwWBJdaFHIPiXO3af3KH7Eb5hZlaarqU+MNy
tlzfti6zmH3QFZsSQdLwV7uUM2ty9qXlZFO4tKtY5q/Udb/qOU1FoBrCmmB4z/YSIQ90bUSx0pTk
dysY5zvKP4iQtCLXT7gkFghzQf7L78vDl/8AMEslkl+86pxZUfx3OUu6d0av2/MOlLVe15b9xlIQ
V0aThOEpSJcSZv4sR/pEjJrW7yIxrgj8fxKybjGDhyL0hDVRxUcoAWU0i0FzIvEAKMlzV5IRxgAp
KS9Ufip5PiZRkDTZ5hSquPpkQO8k9xFNvZBI7iq1yJxgaAnMFL4jfTmfKWgFalRwAQFDodZkA7Rc
KUQpgBfEoumg34iyRqDuqqVfKvl14iazSTmoXQhfiEQA6RMAAlk0BqnnkhhLaWR82HE7KjfO/wDI
UtSbfUWoVakCuACSXxIGXXAkaV1/EGTdO1zkSzLRBCKWVGorqGjz4gEWEaZ4ndwQCY7CwrZZMyCs
vfMCxXiKJFRYTwF3Tgh9kdUR6jKD1CiFmMggWK6hxogj7iCLtIhKiuYhLgT5YQtKVuXzQthxZIsE
qixfw/8AI7UUXZKDck1lQbO9twxqFWcRLBQV6hmN2OZWBGniGv0irY2diqfMY7WUp+KKuVOr4gVo
TmLihDGXkUAwzHogwAogrq5E55R3FmLuYRXZUKttqtxEFvuJAU1yEeqUqPcobdv6iMNGI1tHEBaW
s91GWVeTC6xbO3Wg8iVdkEnm1VCAPwJRiYN/cb14OJcBVDFRXNTB2YFRFOG+GXeFvEEgpFMJRSlV
wxs2uvMdOcag6SyfnxCOM4QOukrPUAt94lNzxfEY7wspUWy3Gzn27X35ikLNpT1FXL3MuhfIggAX
MOWIltVxxQqIXEBAKiWiRiDxF5XQZgQmuLllcW3CPZgyjHzN7IOWL1j1CVXgclI3AHeo5oq5VCQ4
JfxBuhOLlaMHiUHJsb7g1NRtPIyogvtXf8RjIItvJTW6wMIL70K801BIaKW2ARqsLlgUmxO3cYKn
BadPM48tUO7i1ZEx4hKwi7qauNXRnOc5OsYUxLppu6ldk1DxOPAx7b2Gv2APcsaEeGotigoDqMvY
Ua/Et3w8Q2FWwjgio0fZAA2EQ5uLe2LHqDRc/wB1BEVeZ8S5XRz0ShuagL1kTpW/ETuiEgi0Fh4a
jLQ9PqE7QFj4lhcNA6I0S6KF+JQZxJXPEtUvW642pwfKV8wvY4etg0EBf4IpL0H7qVItsBOdhuWW
0fNQP06Da2Jnlx/JDoAX6p4z8b5tiECjA+IOo2qe+WZJr+ixVELgdF/8gKDsQHQUo87B9FxemUpi
Kfmc8IZb2VAcvfUcg6PqFGWLa2Nx9jpuH9kR2rgGPLYRGk3xBBBVVzWRXXQv2xtw5W94xKm2VbuC
EtWl8RIFC19MaNdRGocNvqMxQRkMYFx5FEd05qZHYCqA/coAXVsflgE36iKeQb1zGedX1XcFWAH7
QXaGj6iGU8CXNXc+ANlqQhHIZDbUF288GSlOZl7yIBjPDdytMui36hUthYEAXmC8xWW41ecgDxSz
zOFFJZxZcr0G7OBzCJS6b9SlVoJcbCjzKxN1zd5D9BR/UdsB1qwrCXAlWc+oh1fAPs/2LzbQOUg7
AHTgcmfmWXLq4+ZRmxofMH8LGKrUhnYwiA0GV84wbNrYYTzUb9UQAFp49dbMvU53X/YAgbj6v/sZ
PIm461GjcrfbynTxOMLTX4jAthPiDwIitLXZCqtUq+3Ypu3/AClFkFcUPEA3liuoL4O6L2CqQA+T
/wBm0u+3ku4ucRQHiLYdGXZ7eYBrdHVht/RBrM2zl3/JSEUPsILR54ljwxEhRKyz6nQcieXEYlXT
K+YCDWEp05YHMTFweT3FGIVlMohABYSoORbjAns+5YryD1xxBNlajmXoZ3O5VrClvPiOwL83EFBU
WVFZoNFc6Rwm0GBJS1R0GxX3/sILEFz4gitTb03LTmbb8TLXf7g/MGx8W8fmHSwofiMTDcp5j3Xs
qtnMertz1x4lsPIlrnYk1+4WUcE6wKwuGRrmEKholQlC1s8jRKCS5jOGLYX5lB2hRL6qfxETj/sQ
N/CaxZW4dCQLUvFBpcQ43qC4nMlwYH+z/seWa2YpoTiJCs8QF7HEdqULq4UlmwTbKIvPEHat9SlT
aqT4i9uczEC1FPW6gUIpV9Q3KObD8RRaKCzFQco/iVlDhHoO7GBa6f4hCaI1HuFKjrZLHuHA5mMq
uaIFswcwrYNuVR2QPRw/MsSCc79Rrhd8xCFiMdWK3TEAjysfUcVDpENgWsRuEbKiLQjqTT0O3zCz
RxZ6gIKXwSomApZARWo7i53QjGFtotef/ZGPEi7fiCgbNsJqhoPsu3B6qK7Zbb4hP4Khwlx0wg/N
S2yyJUSogXr7j6dg0imKkhgzTjfs0ATmRei12LgyFQbhWHxCvEC6KizWUh49QBVu31LkqeYhZI2V
hJTNFMCwSgt/Nw6DSw8xmZB/KErWpvqKESrriVnxZEQOW6ZyzEoJSW0iKkqqgcaLBFUatA5gxw3O
b19wnVKUHLNJuIBGoblouktAXZbEcriijxynEukRofEADdqLgo0oKPHc3xRHLgnq7T4nA3RF0XmX
u3PR9xQGAow2NLHT7nB7lRQPEZFIND8x/Qt78S5VTXj5mN5D+Z1ErbqcAEv3EcrKXZGpHFNlJqj8
MPgh0r3CsloB9LgM10ov1EsAB4jeglCHES0U50LrzOC8NOrlLKEDPiWTkYsSsBfEu4qiNcsbQLSG
OoRXOshZdLR+Ygzv37mYokr6YuWaTw71LkGH9ytkFR9y9o48aw15gpjAhU27pZThgX0LtfmHLcW/
/e4UjRj8w52H2WpAd/BhXFxe8oE+4VERHzcWV4hM1pP35UUH+QZRVmtS+xKXz7MBaxEx1AsLLepe
LiXOmmo0tR4i07bNCsgBtLNKUAr7gjlXVRexNY93iAuOE9VLXSFt/wBSpoEB6h2gAA6Qysc76EtH
tLPfnYeqEgNS4dEp5T3cO5OYxiHlwlsmMturuv5IBAuWEdTaQ86pqv7luBb7O9S3cwXYGQhRc/d7
CCtU8BURKyoefiEjmosC+INwSBe+CUxAIOClQKGWJd8ZANwA5DU6GpRdRoD2NNnV+4NZaivEYOF6
iHW7A6BGcKqWgViB4Te/mO/4p44vmGSMD0RDaRvKPMoFLt6yPsVBUvuI5K6LPMQaqp/zA+7GMPUR
tD0Mqp4oEi+nqbfE6g4uXEzjDSkBGjsAp8so7RVta+EvpcuxSyCFKjXeHECkravxAyC2CbxXiHUo
Upae/EN2WFq+Rr6lc8io8g66lpBO7sf5h01DHh+ZdzJH2sZTQJqizWGSqAbs8X4gW/iQwyv1CrXC
lLbpeY+dQaGUXvJaHefmDEDro8AriEktSu9M+Ym6ArhH11Uq4cazbfX3ExvzMFP9wPgdwLQYRIAP
3G0viUYBuCsoK7l1aCT/ANWVypvxFIqqp2Vq7sV9MXMlxgXcIU65jFTRxBXtNtvHU4UNH4Jpwlin
TBM7bDygGFdLceo3FrKsjSF3TriE7A05itrbRyy0g7xgK6sPmXHyI31ZKuDP4yABfxrctEKlOIOR
WYwQGqxBE24I5ixFJwJdy6iBPDEgFDweIoz9xQ6yEUue4AaS4nbS0alXJxodlhqgNVzNURojQfMq
aWusR3pcHiYoge4dyOh1KAKaQATQplUgXYcqgVQ14lKKpMTLdedimkeYSwaQPPnR4hjNZIYq0Wgg
qEhEmqq4nMWWj3DBC0pRwt5l4KcKvmKULSxqoHZmUV88QaacgyscG7kvCFSXKhGBalbwM9RYzeYY
bhC0xa5D4acl6QcLnG2oAMMxca8gx6Y8C4ohTSooAAKdhNUbuiHqN/EXT2EpiVPPEK19BDLb0TzL
Sy3dEexLOTBIqH4RvwQbCiGw7HJWWiu7IFD/ALoFDX7D/ZkRz/UOgBbx5nGeL2hnQsv4jW0VsoIL
dOoVAtIhPUUSFdnO+l8SoUxfmFxRXPFRjK7TFDC9TxDgVKpxLJxqi2NQFioQri4i7PFxBI23xOqZ
5lpHvbqooh67RbwCWNXKeXyFuOg2mhlkbTky6Te1sp3YoEFOqrYq/acWQNSrsdJAKMq5vcnUABVF
42jxzU64hXVS8IOt0icM50RDS/US6QCyDgULvEPNrS9Oploti+GNGGWDxUL5IW95NuENi/mAzVO6
K8RUMXY17ghgW+1RGtO2yMPCOrgOo6A65RADtkobPKUVMHwhvSJ8osMhYkdAogcIw0DGCIww6lWQ
3Vyh0MXTHJAAfmE0Ly7lbGtexH8wK2lAbQQ6O7lw3MLl9Ss0ABaPtEFWbdiDBdrQHiNLK3uuGSjl
dTJ9fMthCoBRw1eSzmB3Bv8A+TrNW3EQJbc3hGUxec7RMgeBMj++3eUs9tQ0W6llWfFh/wCIRcWB
eXUfDhfzLi5YyK17jAaVQu4uBOuCu4aS90Txs1hMqWqjlguiuucPa0CKQQqvqXnsKyv6hA0KXu9f
xLVrqK852LV/SHbOWo6ItDhLLWCu2jP5h/cCJSuvmADDy4vLEyFeetcVFha2AU/EaLgVfRz+IEqe
YhfEyqbfgCPVYiZF6sKH1ENFFixSshktEjJVxt4WLDAEQFrm3N/Mb9brqUuiy6qAIQeGFcmy2mbT
LcRDRnYF0RRgsN/KEiCFCX274hshVjj6qUWEHkPiNDNUxhW5ex+utqmvLCHrBasW1NozOue5e+oI
lvhNR5BQeriVwJFD8w5ABLxnj1APAr0wNBFGBL72UrQ2WMhdgaE0XxKeFWLGoPErQPhNQ6Xd1Tl9
UHb+YA16lq/maugr5HUQGBs3R9xQ2B2o7h/WjClfMdKnfmuYp21rgsU5LbGD0wRpyqD0jCJure1+
Yrvzdn0e46TGUX55lV8Tz13HOqnavzyQxniimffUXwt+hfMPDWtNK+4xIKcS+WyNgubjwVaSOC+h
xCybKbPV7grFp0Ts9xEKitrTj9wyalll5ubE63p8oAI/SgjONgOoSyxglBW3EA33kWyudgLJXlFX
BsRQu5bxFRVqED0eslhNiDTQfuFbQ6YnG3icz6CA7Z5q/U2WTutysZdULS87K1Xe7HqcYldbU4He
06h9Liqun5ixKfKqlOIciy5mAqwtsp9oV4XGXlg4oK4/EP1qUr5lap2ztlGKSim/3GJJsGc60ErS
bbiitfiGisIh3Y8x14KIB5MgLDJg8QrY6MUfUCDx6hMQuLKMS1SlgQJtwljaJUfzffuPWKDkAVjg
RKdAWdQVg2VURjKHKMIBEh54ilUW9V9R3rjDdeopGKVfFTPkrpuAguADX1K6yRou35GVFe7gNydK
uVwK3W6lOAOjmBTag8syNAWcyYuvOyWKiw5TG70epY6dC9Ydkul0+ohqZtIWSV/mUmqc3pCwt8nc
8OS7Tzgg5Auqg3pB2Rcxe5grjZUDutW3L5YPXUrWYCjkoxUzwwQlvALlhSwhGi+RIHIvZsWgXKN5
LeJWrvY5WG0TmfsXANVzzFQCVd7NoIuyb4mX1D5Rw2Zz/DljdQRVyEVpTxCDlVoJqoYLn8TeXVcW
wuSq28nCb4DqDLSGCuJTaWZcRFaXTUXaqWs1MuvCIe+aaeoJXZgty9Vm6IIKk0MPDQcF8w5ZzasF
UXAiXLm1cxQAwxoy9A9WEiz3rrrxBRkZZZ88wmsJwFn7gDAeXiVktLum5weZcj9wILUMASBcV3KC
mq4v4uPLnyH1c2i3R/ieRxC19TrQ9M6jpHeTail1N6PnZb46+H8x2/6BqoczZgT9pdRm2tP8wP4N
PX8xYLW6N1NqYZqRjc0cR8xK7Ij5+Y6YVQLD6Y8XbtDpL8YYTl5lm9rVa+uNgRDHizP4hzuFNFAx
Mp6VsX1Ahs0v0+ISyyug/GSlCq3SwtoZK0KV5lTGkLG/Y39S81zgS/1HbRVtzKJ54u6lc9UWbIVQ
aa0BCmqfXEUVWIikqAb0SlxUtHPlIAb1UX4z1KLypUCRoay7rqPdFsrYz8FFAJHGllt7l4w6VAj+
Uiv9mTJw0So1BrkpiqsJV2o5ZCnaRuaRRTAxeuLdTEttns8x3ZgDljjpOUNfubO8DYaz9w9H10XE
Uw6IxoXVLTdQYXP1AfNS1ijvtlA+kHTFIR2zk+pUyHm4+5pOkz5lluK8JLcv0L+4lwqBgfARKgyW
YqsY5lvpOa3u5FRU29hA3ymk5kAhF0WrMcu8oQlQQvSGNeJRWzxaWKwNalS4BT256jQgasq4NFLg
vWU8GASN69SzKhbcHTFtLZ+YJQ+Qhz0YlJZbrqFWNbj55oLtaOMtsGpAx7ENzLAOPM7K4un4hRJ7
1IS4p4qMYtqzVA/1KZh46fENppAjjD2VhD9pRjGqBhATtAuWKEpXSeSq7ouIVKPdEGoXF/tlooSv
rOAG8jYj0134lOtPGxJaDjbFsBnfxHZvXiis/ULkHQP8pX0CwrE9So1lXeDaQ8OhPJouoc8ELCRb
BK/7BvPccSEoA5pvKF96lQPmYE2zsI1WoYblrVWm31/s2QQxphSqxC1y5Z4VoGNc9RIQtgQJaHzU
G0Z8hFJWhXaEqwEjz1PgBLy+oPuvUD5SMoAnmNbOPUrVbc0pVS9wbxHpQXyxKy7PERiPHn/8ADwP
RK9rqEE0eIIlrUvZnUs4IW1tKS+K8RKKKK24ywGEX81EXdQAg3QC6l/UtC2JDiUxiYnJ5ljo2gqp
f0bODmWAp1ekzJdfCIn2nJBs0ciCBfXwyB8pxr5jRTS4P8/DGLt8zbDPEDqPPiVReF/mW+0queIV
UTtzEsKuonKbmMvY1oEoroh4I98RdM7WiGA2nHlFi3pZECmBxNhQN9L8TFJPEPg8q9s6CAAx/UNn
Lo6ja6FqwynW1YMMDUsK7jymBwR+Jz3CwS6gpVY0aFQZCeVVKmLUpnwlaey19xy1fX9orChyIUS1
zZkF02OO4tekGHboeZg80i6jKFXiwpY0t2K5Qkp5FGErLrEoRby2yqS7c4iAwHA4hlZ1uQpVOaM5
gcwc7HShqeSe7iOLgQGrooEZpO1qX7TqcbA5NNPMHOAWXSpdWaeYvK68MVjZ4qKC7tyLOlfEC81F
uuQ7FVqqwhsc/fMvtgOsy58EcPO9Qg9MuzsoO19QVJ5DV+ZnHAApv5lqR4VHMAKtRzDAjCrXAY24
CFZKgJB7EtQWJbFXTRLbzoL5iM3DgvwyUWk7BKNE8ETMiyvJGfBctpoMOAJZwhVCBKoFAdg00Ygt
oiNOC+YB3qquolvwuzVS7zVCeZQmovXYmy/DJywBAIlMpwTijR4LGQiY8ggcW/JhKyuteGCgNWML
1NucEEBpaIO+2Y9mUCo7gzii78THLyguH+Agef1E8RwcEOtpAU52Pkb1rJXyK8VFGOVD3CG8A34g
rPy6DZ0nAdQ5bm/51wKDsXfKMml0Fb5iWmKCt58RRAwscxxdzAMPqWtbWyoBq74lQw+2NsVayc+l
XjmU6FV8E4rmuFeomY9jqDwGmWUwhZW+Nj9EUR8wFw5SemBbbVqKHogczCNDbti44hVlJmq6Dagb
hliTNUY107lKIUvAJWlTw2wAo4ex5uViGzC5d+fFONm4Wzg35h0mGAylM6cNC5eavJMq4ONrQi7y
UdgUA4Y59aoYbKgilCGMuuNYLKl7gNB3aG6uuf8AEVgpRhKbRhhx/iWONQ0w2Bz7QgcRhTW2WPhG
J6tQ4gtRFjzdTrxWcsW4gSYnWwQ6QRo/9kvXijB8wKyisXT8Q2TT1sq/zjV0QHT+1PKKEzWukrnG
yu/mCzEeAbKLVwLaRX43Fy0hJBhlygSmei+/TDFLBkwg34RcCEQGAL+owkAOsqrioDWV4h9IKOFG
PGUgjgf7GnWsDIfPrIFwhcQAOMQ+qgIdkPyBKDlrmWYCIefuUZOBQyr4qVgkQByRyRiZVPFwH3iC
31UUNYlDvj7jIQglXXLK0WNOI55ghdA3O64ixlwgK8vm5RomVyjUDiYA/wCTigtWaGAgWlCMDVyO
kqBKbgt7+Yhx9QAr/kvZ67CkuqVU5NgmLFaLz8yrNo/2WUGFsDw6gBTBKAd2PKJHXcXTCVYnYeEj
HCqEDkjxKwVI3fcTqQA2nslbExtW+4a9xiJSIspioFwonAgFqgYYsiWNd+OIgUqjpQxIdNgbcLXx
F64sS6c/Mf8AMg87CGmLoLcx6FqHfiMx6J7DuVJOdW5tyryTssar1LFfmpbtQhOoR+57EWlqt5ho
hsKNdZR3+o8gUQryl/MRTCznySlA61lamqxLqB3ClQnJn2KDro1qGhShpj6gkNs8ERCh3xOPqqje
p4xTliyt4uCepemHggYBo2Er0C6wOHVRY4SZxXVQ2kVuyUVK7VVdQnaE2HRcS6tKPxv7lSUiinEE
gFqnEORNhLfULX+omjl+pqnUUaoh35lmiHcUL16iYwfcbuLm2Gyoy1h8wlEOkN8ynCuI8FFNXCiC
EeF8xvoAqyAiFXxVw1LQPKODwqcZDxxq3uGoKVpB3yGndf8AZXEH3D9fV19y8Gg4Jqg9Iy3+dslt
vDgQhNUa5PmUQK3jiXahUgREJPDgI8AGjT+psOKA7ZSQqfojKAgHD8QNkQaYRoCzoRL46WczjbZe
yyINVFEygQQMCuogJdV+JpBKScyxCgt+o0CuprFuH97Ai06uvJCxMykORxKBQBxU8LRRZPiRuQsZ
YuI7q/h+ovoU+I0DZyoG5oL83GOI44RCpIA5IglYDR1G7yY2eQJhYPNQpHDCtElTw+Yaqj1+4Qgq
dgx1m6hSgBqAmyBXljEgcfcGIWLg9AK4JSQ3myhhXIrgJeEbulIXBKoEVyQqmJ4qELyxU2yv2j8V
tuRZRS1tJQEEoZcqnogFhzyZQsOH9x3SaAxiUECJL9cwqknZEwCt1U5ba0VFAbZPE5oz4lkimiZL
6AUFbMxB6hEosbnPiW5trS7IeJ5MbxpQB1KZBSjjYTaAXsWRTbiVxT1KFQbvfqM17U1GzZIG2sAn
eA+YAUUCBqDeV5bG5QA3fiVs2q6Z8QqCLgYwO+uukYuXDRkpeaeOGYTSQnUsgC5hwFoN1QUSxsA2
wmqWovhmUJLE9QNBTkdze7lDj3K7gK8S9Z9dKdHQdwicGyea2FYtk+BEvA5R6njxLXUucg8e6j8B
atXqY+Mj6PE1ARd+ZVTQxo4qLsYV67lRdGL6YXBZ8XNyskGnaPHUruO2OLhtDVs6WKVikOJtiDS9
LY+ZSrPMeA3AeYYFoyOekTQCJyO4i4lED3z+oBxhnR3/ACL/AEq8tly6cDK42U57VGuQXSWnDzKt
HJHkuAumAr1/2IfVdB4QzFWEesl46gUjq0YLhpsu+dT7aaWN+1CkuAWEPiYMWHTfEXqAORWhJNHF
GMsrZradd8SmgOm+qJTahU9Sp4cjF8RfdpfZnEu4s3dqSvzE2gAcQaLjFBTdsZOpWKvUBWc3QTw8
dGxqOsGo8CzgKhSnTHsjR3u9iO1YDwMwaFaOqD+Y9w1OhLgtRV1TAI2rrflkRpjpOsqL1Uda5QDE
EC2RTLgwWtsYXttY6JbEsAXV+ydgcUJu/ceBgWBvm4oESS/ldwhQA5lvuHDlSinvOoR0mEqiuowI
nzBcLFoaC2d3lniBT2iVu0fcNoXjDxLthFduzd6Uo+YauiKx05gAW1UA8RCYh9o8M5NXLJWkfgDv
YXtcEQsAlPyiVBUKi/KCQQYbfNw2FWHgR6pY4XStqLQ3QAxxbf1FJroaC81XcB2qo0i733GFcRjX
j+ZZXkr03FKS7lDp+oHN75Pu8hoFJwa95BuPhBTWkaqCc9L/ALjBCq1uhhuB0bbSG/BafLc95Eo8
NzItBfEWjdk0auoEw2NY0TYV4cQTZjjyjbn3uYlWDr+YwYO6mrRTzZOWceUhjDFPGsPLC5XUx4/k
bHbnIW8iUHrrUvFSyFm7r3U74dnxGCK3VR3LRbwcys2qOe4tKXxMWF5XqGd2cI+6iFboKgwKaD5h
iVSnEdnz6igrWKcOYFLfMG0KbmlqqvMVNnnqKq3qeZYSsIFMMEalhgfFQOACz6ZSIUt9pEOKESLN
FMUrjr7JkpaTOwNhmlADtYa4QqdFThxXixRJpEXEuUyCz8H+QkKgczME2HyjDUdH8QFocfEe4Rw1
ES1X3qEgaLXl+ZSgLheCBDBVkvN/yPkgOcIspn2YB9vCrrzcDBA6KgVuuoNAdoTmGVxGu6rBHW7u
MVVyvmCIaFsl3Qu/3MfBiYtloTy3zGqZBhRMlSpcunbOMGEeItzlLohGlCSqgv3Ec08IbkEp6RYm
FcJXUKNbUogKsYhzBUaCz3GZ0ZxzM6uAqXRFp0lbdK4qIULAivE10JbUNWmvEdFQ7ukbXzBU1C2+
3EZubqBwFp1LgqdV7GO4TyJeUEAzEGOW220idSXDwnRgUPU3SUbiG1qVk0nJGEXhH1ANuu4YrY4e
pa1e0cr7ypCr4ELZ6UeCI4CHMVHIdS3cDj5ZcRb/AMjxEvuXwA7Mo27PCWGuGd6ESCtQun3BNY5k
ujoVWo74gBVj8S9iiUthB1AcD5iIKAo3+IaHZXqp72TfO7AUcAX9bKJBVBqu5Rl6HcIAUas6luSr
MO5xypgezuOFo0SKXqK7L6MYAQcvdQa0i6xcptpUy0IL1bYRFCbzyMCkX/8AJxOrlMi0WMdQUUz1
KSAopFWCkZ9QF16f+9zGAxwZwH4qNuGwf1K/LA+IeqeV/wDeGLDna9MM/NA33CYtlX7lNBfLHc0O
D6lto0F7uaFawkDSj7hU5Y31Pg0NeLSI7OA6hpcW0PL1xEGjSqOJWKgaHzCPwofonC83lUoMo83c
GPSts+ZZ6o1b9R4oap9kSnmq+9jFQxv8sMAb6+IQi0Sn5Y/xZ/hK4AUtcs6usX9P8jNzqvjSHCtR
62dmTa+j/Yhjwv8A99y8iq6fCD/BKuE9QadUsfqV6Zr64ZgZADrYSHLa/TEVNXc36Yjg6EbrqVGp
DPwjFa0vI5gOSI7TUK/mNG7HzX/YZVw/YiUItV15gYXDuH9wT5h1nFxB1LalVH4hptgeZU4yl6eI
LRxE4I1JHcnd/wDYcwhLeOuxKaCNFK5FBZdRyX/9i2yjZeKnGlAHAfUPTQLnJTE11j8bajJAyuDz
EUZSjC65gcCE6KYyu9KHJcDmJFWuWsqOFXFoeovwHwKeb+ZTFvDyZFVcO6fRHVlPiD6h1dmqMRRj
Loau8+YY2yNdjLDQHNTuUprFvqDjqFXuo1w3X2TjMLQ2yhHlCIXG2doCFuOYwBiOC3eIrwFPUZku
lkX+gXxGMEsqavuJnyJ1fEZ+SzavnInDYeWC+B1+a/udtOjlksqaLt8s8DQTnD/Yc6J2fGEx21r6
phrW7VDTGE6VgUr658Ro22NnfZqyWyxs7AAOwh5l3ukU7FBOFOoRV4HxAFjEiMXC+IrCVYBbGq9S
2DnNREtHg/8AyIENNIhrYGlTWwO4s4tt355gIJSbgHKLLlQDRJxB8bPu7qVEXxa8xJ9rPnYNFpLW
EVg5Ew6HcBumqvUuGql9RGidajpTQK6YzCUbEsYtJcsJtNRhlv48vuM2ul9f5EKgVD4qPS5VHgmj
QD1Cprglg6yJYxSXLDH2SlVRA8L5lBsAsQPFRIznu4h9ZIYtAMJR3Hn4mbiq8wJ6qV4letUZRKoc
0bjj4Pt7+o6bQfpHW9jdqge+Zpyqre8ggNBtQ08RSesSxrdKuCFd79wVfB/UU8zjUYo4m6fZtqmc
tvjWpbf8xuTjxHY6/FXWQ+xeRUQEKO3CGERn/ZwmS/zG0e6IB5NVFFqTyd0jMWDWSofKm5YZ4DGd
6Sk6gQCLd1XM1KFfmXPdL5h47sB33c48KD9RoODqW2CYO48d4jHq7lZas6+INywTdXfM5feuxdhR
1FCcagDWoM04s5mEJvYNttpNlTZVq9R7WtuzUv8AEOYRw/UAfLQ9VDZRqxruJzC8aMr5nJSGxlTd
ZGULN8QKTgKgbOKuZpBjUSgUlK1LdhhRQID234gQnTNU01s7+ohbzAJgt51N4g8XDDRXNlp5+B3k
tArcIBVR3CAOM2JwvKo/dfNy2RpRGAhNr18Spod7HLHli74jGleEIMW8vqJ2wriCzBmV1EnwoemO
Y68LV/EuzlaPzsMWDgBznMfSrcvyYOoF74uPqbnwM5l6KFm2+P8Akc6kaPctwQAOarZSkFJ6EsYd
U1yLHiGW4K/3BSootVO/EolFtviIJnLScvmB0TDRfErHtm+P+SlhVdXGcRRLXHpj4hyHMwY5LGot
d8/Mrm0bzdSoi06+v8j3rtPmGuRbfxCoFOyLoZ3wDC/qv4gXQptv8QnNrK/EMcyI8XK1IE5g9COk
7yNWt/5iO1Ee4uldxvcuGRpe6hDQDvyx68OfqGCjeC4e01R1LgKV39bB7EbX8VEo22laNwYFib6S
HbCuC+ZnQ4nbtsQr1zvWRIIGN5mQgl58/wCxqoVWuSIrwBfLf3AhlBNHupkfFnLuK+4SL4jm9V5H
EWIvAHn5irAKPPB/ko4ebS7JRHo2O4CoaJNe2CNAufAqHRMBvkqFjshagZbGwPMoYeceBKiCbS2Y
j6lmo8apjySRV5Ju4nZ3Qf5DF0BFxpc3qCDq4szpNgtFQeGVBFh1UsbIqHMU6GS/dT2hnRfTOMEs
DN5lo980rwRiTlc/xBePDGsYl0rbL0iCoQa+Iufc6uKVZvb+Y5XFaemEwnm8AtzFr72dTRU+WG+8
gfQuduYtQqbDL7lkzS8t8S4ND7DfiFsTDRQxLQvCNztds6e5vHg7KnFwbkVE49xRih0SumW+tLXl
ohnwKW7t1cy2WhvwMdzvMjbgitS2lOxGMRDzWRwmGCm4eMDTB25LEOz9iVfhcnbMmnDUJuvPzHIV
Di+TEO+YbqWYv4mnnSeD3+YSYlPCe5SkRvkvl36jAIe8pyhD6r8xTrNto+oc1E+xG1wHlhABiKsv
RlZVTHxOQgpIq1un5iSzMQH3CdqxkHdjOA2qoBpObbKZRdhXqPryioFeeYBSYq16gtev4lrpveJa
0qLSrmnwbBDTOqjSyqOZ7H8RVa76JYWw/qUJybyOGQCcx7Lj9Rgjygr8wI0L8kr3p+teJowyHLKj
+oAlzVyqgIld4wsU70N1KNAXvFkcKa4QNlBxzmDU21wRIqUPUVBW0RYrXPEGBBatwouXDa9IRLim
HjYderk4nCpdwm6x4gRVV5ibUuuYHQgUNuLsWyFCmQyH8wFNZr28SzfvxMal+oluqRqwCqFPEKwL
DhspYLWEukHS+B6gORD6SyYHQx8SnXULACAzbzmBMUl01AT1ZXsuLhSscdTnAVxKNoaPG5EgUpru
VHuJOJU6UavqXNw6DGPyR0DS05ekW9RQ3acRlFa2sCgpyECYUVfmHaNFXxKpbHuDy2tVLsAAtlmA
CBSW0C4QC0ttJeAr4SEl7R5YOiC6cku0qXBZzL4QsncKCoT3TeNPiaoA4XE1ZWc8TmZnSMO1AFZL
nReLnRlrmAr/AINIaFXjmBDY0tglZDdjzBdCq1gzxMq4ynTzEV4HuUEB3D7QrUfk0cURSOBVg6eg
3YiZvLIeD47hkIqL2itS5jGAAeZmI8LcqPDyAw+nyDK65t2BQQUbzPtZuQuWDaISAfEBRBwYRyPT
HItHfBCgJRt91GagcbUCBVLOVLCwdsQAvjIZJNNMqzErfMTYzm1FxqLy5Z/V/cRsCk9QdwF9ZMuD
PTYyBVFysiltah8NeXo9Qc1weLFymR1rSsdZLtCabq3CRRinlhhbGweZepwjhqYjuReIRCW06SqY
B3C2mJKxGqWPuYKtJwyXG43/AGQaEbQtfiAqsN3ySrrgMZH7yGqreI7dg27ZFQms6qWtgTI6oL6h
muTqNiKcazxLy4Fp6+YvABImE4f3RmE9PkF8kCaNjW5fkBlpVyLfK3zCmmEqG/mM6JSzl+YUcNqD
xKpwUQD6TsyucYBfcIJsDV55uVLYpFBuurgvqUQ3UOBs/wCQfEcCdpiYF5G7+I05s1uxlVd3V6VM
klgg2WG6ZXZsZVYbeioMiWFo/M0cF8BNeCQfS9xjb8NjyeZ4Poc2XcCTaqjDNlgnEqo6OOva1zK3
JQXew0o1mlyGHT0LHgYJVWmsVLZdRtnZB0y0WU2WQkDkMehBXrylWFSpQrDnysXhQotqu4HTNHg+
IlGwux8oSK3POV+YqsfjlHQV3exwR4T3QQPuFcY1HaBBPULISVlg+JultUBfUIFRQeZog4v9RUau
GbY5i7a6gB59y1tsfi7i3IRqycCjpsPkAB0euIPsYtU2lebeVxUAkGi9w5JQFVQ8QwRb7g24SuUH
B6jRdKGX3LEnDDi4MtkKVb5gD5pRXz5lQN+E/PMeDxqlN+cgpjKw/WzuDVjv4Y7BPAW26+IVKBdR
9Ajrr9vP52NiVRTQ9kQlatq6MQkqhQoHFS9pXjV/UTmxtG68B1BokreQd/MOXcCIBfU3bRo5eY3o
LBd7bKdAFalH8Tg7hOCwTide2qcGL11Hxk1J5AyMqAKORXzB/OVuKbJa5R9mSgp6hfMvHQsOJcZs
ptUpdwyx5dXsfxoq7Vf5L7UOsA+ZwGnOVmUChXfyncVComigM7mLBT0P9x3IvA3S8Q+wKAqa9MUg
cKwVuwLSDAvsiq6teY14depaj4MLVbI2ekVBAiOQLKGg+5b5lWtJXUxH2WWUMr9QO/1IbqaS78Li
ttojgjhgkqWJwhNgAHIY5Z5DaYbBWC7vmCyxA6wRyzqosETAJTTdnqNo/wB5X6jModQ/eNJNUWu5
bxyEoIDEBTZxKMfHsrxFFY3kqKC0fErorKhaLxFNm4WvERVuSxWFpRqFe0dUOSj3GzoPcZz/AIlb
yr52FL4WOWoQXzKiKTs2sTIhhd2BmhGnzFDb4bNRMpRPhilwFgbjQdOLq5sCaCwvr1EzIW2VYoqy
5XLQAVblORBSw/iFoo2rgubDFEV53APP6ggVXbMFSG8KXL4s51OtpSvEuxvNL14lYzwu8m8U8PEC
G9jGKogPhhoHhQppMxYK/EcKtuwRZqydf+E4EGmpU0Nde8Iaj4u0u7uko+RtwvueYMlwIHHPuWZX
5NEqoUWBwPEuIV0Cg/EczJyMtXL0cj9LkstQTzXcsghvyhk6qpCQa6RVDdwurebyGiLMcfzEnhzG
LDsNsxLrOGlwE1dUbjxv4o3DEXrhZvr3FLcx7cmmRbvLz8PP74jQY8qMqs4MIb4fXII9gZgwKBtx
u4ECGcMQUCi8iFN3+UamWaELcRVYrGz5yEmVHi8wUNVpkuaW7uGpVsK8MqXZgUZVqTTY8S6tFlOI
GL5QjHpVNo3LanzRyGvGs8nhgFMGIkGtfGoleRZd76gRGOjsWv8AikVHd7u08Qqj/BX3CQR4XSRg
GH55ndGd7UoIvtLNHSVXH7luZtOZclY1wp6JbxVropIJh9HjBj2ps/3hMHkFxIKDYSxDSgTR8Rix
HS5bR5icwmOXbyfzOrZad/cpa+7o/GwC9wo9+4SKpen8phFFaInzM3Q6HIxVq/cTdCr8xRpqRChX
CynZDdrPqNVqOV1BYpNgaYwFzt0PE6gpzbJtWm+YgBWmldnRHuS3xEMsuLe4rWh34Q7qpr1fELk9
eCS/oWrc/EE8JEqEXe3/AMwcErB4gcW8W1+IZ0iktQBQXPmU4Dli76yURLaWCXpNyu2Bx+A/Ny2F
NDo8cRNX+tphCBWnZSDRdNC0Qbyf5iNxerIeaaXZafxKody3tIEkfIeT5IL9UCyEigzEJNCEHplO
XyQhp7pY3jYi6n3AYp/aXIKcG/FQBY61waKXSUkdAU4Vl/ECBbGxMqFJ1Ag5utNXFiq7mnZcI4jM
fUSFuunJbAcgjgpHIflOJEwMT1AANHuUDSL7l49ytkPS4+YPXoWgv1HyI029g5Y5iyHUHN8D3KaO
1oY0veFsb8ToBDevm5UqejkI7J+BTzAiew0yzyCwG79xcClDQRyTVVymkAcVhDTl56T2vqdkd7C7
qOjuRsTQRg9RAmfAKlkQY/8AmxWrZ218L5g5BUvAg+4G80ldBeIp5i1bqruDSXlLGCeuNXPp8Ro9
WoRuFhHFWu/qM3pt3wXrJMFjxcvQ9AGqap66FfcLCHZo4eYSE/lgUxFFjfOwRGsX/wAEcAa63ZAh
IoqzXzkRstNwSiSrUUu5uo73xmfEtoQQbh9SBzfMXxCh0eO4Yq8gX9JX5twBriNxoYP4YetjLN2K
TQlRuKw3geksthTmX1q3zDdYjzUoLF1FOsW648xDo19Q5/P/AOEoaC/iKLejSoEMG35mhAt1saOh
tVxLrCS5An6qiZuIBAlq7cs0UBb3jl1hCSk0AL9pd3qmjFgS7gkF2wrLJY3/AAYFqc6qy/MTw7yJ
sgdUkDL3ENHTaPA8zBYVi7yMxDwwwS4zZWdepZHiLwKhuFHkilA/Mob3UNW8Ig+ZZYwaUqFF2TOB
kMMLYSLMCeJQG1nhByD0psbImtK/ce0O4NeslbIarIjsqCeRqwjOjseYAzdnCCa1tUupR9g5vIy8
AeC4iezc5iOKzINDDaHf+wEJwFsV4BhZMojo5nFYeCoigfYjqjEJQv8ASM8T0u5Xk1HaA5wOaqEk
3pwfMz58SB/ER0UigpbwOJppFtnERtCbhFFnIiqI2lQtzY4DxSWEC26TKgkryQh+o6pGGAbQxG0C
0B3LIbI0Ydy2pAziX8z6JqNolSqun2TudFFIK8lrtbF4Qu3bam8Jz0htId0n5gcGrBqqiRK3hSJa
ody+dRSolvUQvwvOW+ywt6eiLABquI4oO1Blkb4XXkg2sOGqag7QuUFzbp0oc7sYyBqLuWXAeOEG
AVgsONlerErX8xwDWZBQR65hKuWodSgUg4gWf2K4QQQbQx2HxHA1YVQzjIYo5eXLZu4hd9p1dcBU
S2sWAncCCgwWh4IpAxWkQlSPDuJgUpOF8woxQAMCZF0WieQFfZcUaaW1RuK7my2KnqrRyeIAZRCq
s+SLG2Ng6grkgza8ShgB49JnStPCIEzNl23DFgAi4uQlwpxpINPcpBgG0lrWJxDC/wB9XnxFosrW
K8KFuSyeQergZUNll1mTAKBYKp3EvC5zgvctgcQWLM5l1S3GEqXm6gwArMgkd3JyiC60Um0gIRW8
QbLhNjv8QfWQnbd5K1aAFKiHLFcYw2NS44Qi6g2JQQoc0YzWjml3MxdCCPgFHLKlXBwPaCefTXK4
3MUeHUehKcEvlepnFQXqikYRSUQoWM1oeADAkiRtK/cS3BFi6lggWHxxEbt0sGvqVNgAC1qH6Vxa
3gJVOhK2HnqURsLpVRmntdYF2q3L1MbwPQw5jVxJ6hMoDhyiQy2cBKZkFk3zB7gADn/zFuQH/CUD
0rQCozcUtLryyWK+oZBfVURWncFMvv4eETsorT4i4F03IwmxB4UnfsiYMKVxksgHgKgCA9HyHMri
pqhLhDEMHev1E0PEgQBbHSK4QWfvEf5FPijTOEoC+mTLAqK7OZk2fAfJC86FHJYtUAaKtvj4iWgC
FIREdCAEOKYL4Lk1o9UXL3ZzOoGos/c3dp7G9QS5FDpB16lnMogseNgLVUBjcrCsmZriUUwSpqrx
nT3SBU+ZfIFCVp+4YXX8B1FJ+0hzAOihVqeblxWgWKS7rRYs2llQgaAKJNM0bxNw2Ncu2RIEeIbP
cUCArFFnomCQIKqqCBWo49ELJUDL+X4nfhUuRKzMUVYupj51DRl2Ut1XARLvTfQRn2VbKHnuBwhV
R6VKbzlkUFS2Y/M8kXoHVtF5f+R6BpGi6ikDCBYPCx0u1Bit/mFMuUB9AgGKPUUcE6H3jmGpqHap
eyMtCx38VA4gPIBeK8xBARZp7mgvbYRIisqBUBjHQDDmDgwuEXXzEsBXtl//ABE4Fh6ZS9yeCXTE
u9MIhVPiNXQ1y9QL9JqqJQVdPMAOYUeASDREKMrOZZ98yLr3XMWl1B5HHEMIQVkO5dc6ioeC/Nyn
KwleXzAUHfwjUjXJ1sqaORUzlGoVYldI6qZxplHi5Vo0NWMM/opXMvUp8StD5Sdp8wxsWH7j4Gwa
Vdk4W0evE3dVCxdRIviboWZfPJ6gON1TDvKOwISMPBgCdLVK7qVRdNyvuDXmP6XxrAOqBDdlwpRU
0d1srER5yMLGmiOWlBFOEZa6nxkZwLB9TrkOQj3Ck8KvmKE9LbM4iMA3lcI4jAsutgUByqAyF0/m
Zc3RjUWuY5BFhJlDn1KlMWXcJWYa6iAClOe4xAUMCoaOFwllFp6gxVXuGQqnSpRpQaf8lIYc8cSk
CBhcNjZCLxUniGcU8xYgbZ5ikgBXdFxRQIp9ynr2Pi4GApUhmMDykuWaFE5o/jkJfajVnqApApai
1Kd9dyr4KveQ+UCL8TFyQ8eoKs38wNa04jCAtcgd5usRA19wWUVHw/8AqgbQ6hxUCEA1CtRhzmMw
AIBGmEswqtBTyBRD44clTSVcFNjUFDwkeTBglYCuLRvqviVQDrOELtA7VK7LQXUtqavrxLmmhbcr
DoXhFFNdo2PHfENjzVCOghMa6idKUcSvYvQWAQ29dwREbgl0CbvqFbbsxUNFuS0g/Udy5ajcVV2E
6GuFTiHYKr9QF2S+IopG4cQlgXT1DrXvxAJIKgP1HAuqyK2XNEUAXd7GTA0TmPUHRJbBBpqo2QSw
EAGs37meQW33ka26AMo98S3AdhdEQCd33CUoL+JQ2F4JeOLeYaJwDQiI7ZBywK3MW7jmm3m/ESC5
Y5eZchwTvJ4yhTkg7LVMIIFCFde/3AYDYRsyFFZXEUVOZT1HS1KWc8VM8miknMGHj1ByLBcfmKZW
6Gt8RYqj3tsHpYVWGcktfcCCCaxD2/5A8hWTX3PzRWHj9S3CSKrq5QbaFXEHARFca5gCFGoOVLhG
UrFdv/2GDek8RdqAXkqIshAEspz53CltSvS6h2obj5jBKQfcxTQ7ScN9Q1pk/CC2y1ocZCYUAGWy
nVDactBAjeKa48QMdAKvDf3F1tu11sPRCXR8Esc0B6r/AORo2Q4bbqsL48z5L4/UIQvlOy6gSUsV
pL4qGNbS+a5hKAtZYHYTgUVlT+ZOA5IGRyq11xX4gKHs0EcSqemJSgCILgAAK6IOaAC0ncDaVpG0
htIHsNJA20LlaAPlfiX1hQ1XpE5cWeWwh3KWT5bjSHbE71gmK7g4yKob6ttRAfYKyAeitH8whL7S
ilhaCAa1XMMwKt/K5eS8ww1ggyYPxEMaOw03/sQHgsHWoZ72rhcwiKYI5aX1A7QVWhW4Oy61j0/5
LqRq7nEs0As4+YvQPUWLqL8bTSMbC0PFQiUz5TrIKosYfSELpqjvI3SvqBZhjbQH0QFqKehxfmBU
Ld4pIBghPB4cwOIqf3sp1X18n/rmBCMbS4PxcGhqlT1kNHgFv52VgACLb3vzL3Ad8eLIkaiIpvIm
DpaGVUcUY0h4dPG1viM5diADi31A97ghFWU3Fs8c33KAIHt7hUlqvM9eStDiVXWiUA0e5wVpuWIt
OZ6SWAIHsibA6F5Y2UItczQ0vG9lBp7XGjOVZEnM1sAUEWD7JQZYkJCLiyD+ZqEAQaSuGX/Ti3LA
qSwium04Wribbc77jqFLoIinBy+rgaNVsCMq9azDytp9VLHy274mDcSVwcxx9LSu4DpWiMa3ZBdE
qIBTkOgRe4Da8xpqv1FBsAiZ5GNBragAi2qFG8y5Eh4BRPAXGwEAd7X+xYFBAMClpNEdw09kY+rK
HzGCpbC5YbJ7mPNYH4jlVLqXAayziXKOKUHgyNBAGk+Jebw75bLmuIemArYo2A9onTxkuwCiFz2M
Wor2OJQWINQHiBaEdYDmoFDBgUzoDEBsIIUYEDX4hv47clA/JGjSm7DwtzqBE0pq4lOVQkZy1+Zb
1R6viI9NaL3sCzDWZUqAtUV3GJtcvirnBnUDn8y4MPcFqLU4Kxnw6hKSOi6vJlcenvYkgA4Sr6F8
Q8rQ6lGAy+zEvIPweYugqozG3P1DTUdEAKD6REnHuMGAipZ1CpTKzZrY93TH1rduXJ9jXTGKL9sO
O2Ecr+iARRM78xA8zn1RjCeV/uMunMsvBAiXAKlc4AQglImzCGNQgm0kv0NqUeBUvdqFrhhcHXn1
FWn2hsgf42CitmCWuF07D/EW/cCA43ZXY6bqC0DRf5hADh/xOJbCxoAua0Fn5hDYO4w3arAiMiu/
mcVg3s+ylJmNaRCGhWL8w1fJ5hDcl181OUnYRauCSiJ1xCzTRV57gSqBwPiKqkt7RZwpY+2ItYl/
iKMDXyoa6itgpDy2ZKuA4fCPOkS/mEZUl1gncpat1EEcg3fuZYtuVDUChKC+pVFzm+4QkUrT5jTB
hSEJC86+CHg77xbaEHkuc00l0xI6Uq7+IYRCyV7j/d36gVu6fqUduq3ruKoaAfxFqdfzMt4IJus5
h1AQV/NRh6vf7YQ6e097D5GrTgaYr+hWoE7xT+YcAUARMcH6sJTUnOb8QBDwPlSdBDf2ETYjScsq
cpcXitjmT8DiNVyDeDYgRaNV3jB5DljpuNFkr7iNpqsveI52KXPJv6gsw2g/BD8ooEfiGmEHgMIP
ybceyrlkXcF/E5AL18ZcpeyA8tJUgHd+Yxk6n0wNYTDyjhWWbzKZuSyeIOxG6rr62KLAPB/SCI+z
mAQHiME8XKUhUL3Ebi1OsIGhJsEq2LMUV9yvZVJsM5skCrV8xES2ldy7TwWPuGOKhJ1qkflXE2A7
uXAFC21bHUtDr3RZEFyO9qxAurh9x+ELUA86xknZmG+2D5QNePP9y0SGeeIUsSC+2PpsAu69xY2c
N87EetRA5dZHCFgOdgzAEFrjUIukB8k6H9zkPmFzjejKY9N0n7QZOicKdx5YrFwGUQaDBovx9tYQ
l9ifNwIYSy+IOmqUe2uYDbLpVRwyLbARPkISCAVXrzEjU+Jr59RoDhpVYtVDa0r/ADH9LtAvaWoR
+IDVJ19Sgzt+DPMYhHEDzV3LyUUaotA+ZwkFLRfX/Ij4FIsvxfHUd0sR0cV/EFH5V8AlxACXg6IS
Ly7W6JLQ3EbStiGYqn1XENQ+h+5V2T4Y3BoYDXxDC0G+mFFjRFV1uWi+SX8Jgm1Yx6Jp25uB6MeW
FN4nOI35cQLRG24hoadx6wYWWOK76bIQzagxHcEDqETqKqh76jZoiqRt1QAXCEfK/wBQ3exPFSio
rA8QeSBgfE4iBF+opebLzKJo2D39CVCieFV8QcwKiDCXWqWQXZ+okW59xBe3fSRRAKfMLu3A0K0g
EeHqHdqZLsviUpZcdCP1GDeRtiuOYdqSU5Bb/sZIq5DO8o9Rq0CX45g1g5jCpC3HBOdXi4k6jN9k
LaVbt8QKdtb4YxHRTb3c0PZcTmtqFzE/nNxnvAdGw9Y1y/EZ6Hbljnqo0Wdx3EsNesUFkwESlZab
wgM8dMsjWDxKya7IJqxF6ltgLtNgio14iOwO/eRFzX1LdZs4IuRXKDykPMFiGWBCybOrDiUpq2iF
Jo15FxsABrI5ub2Q+RUY9XtzTOQu+o8FbvidgeQS1IbjUe+JTcVkq6svAMfYtVfWQ39OX8w880/3
PnLYIr9VbDyyg75h2rsWXpMPEcDaPLn/AGA4DYuPUJeC3UMkU7CQ4oZvGn9x+WK7QSjqK97HUa3m
/EuA44RVvVAJngOKlzVKgMWuHhyFuL01QQWxWQsJTSkoiqGaLWiHsbyIZahbYTZkyoOA5ctCGAPE
pGY2VyfBvMXuD3OSDse415fPzG4rOUNrVMp4lhlb8xAXXpmJ+SENIIOM66QH+QWfLmXZD+r5je4v
MZb19S+EK2v9yo2rBb7gsqAJD1KXmy6bCi3uVkBLx6qZ/bOxCYPHeRWUtSl/ZMtMT1cNhW0c5Dbg
rh5ruNqbUty15IYiLGlqUlEtH9TAQsD1BSNeqpqE6oXGxyIRSzAF8HfUbzNnKIDqEEpv0/MFoKAX
ywmspnuOSrVrxcppqhu/cwMnVPqNNRZ9oik2kP4ndOmsvl20tsADdwvmblNL8Ftp+Yp9FKPphp7u
pOvqWUULcmWpGvP/AIjC21HRCtBKXWhUsTYk8Bv8RfKOxauNfKd0ELYuweSAttOfiVRGK/D38RzA
sA1+4sN2g85zLFihMxX9yn9UZKusbuLz+5ZnSGX6WCtIIG34j2RiPC495A9niAnwF1lO/iK51WUF
4gq+UDRz+pWvca2O9S9y18OYiGtVbbySkg0I3mbTsb1fz6h2ShFlLm+YANjznEvvER6bZcwWnFsC
hXiCg4rIwg8HAIHtSDyh/wAjABEoEf8AsdkTWorMvHIhbg5p2GxNrKQsN5lW0W+pOt25DbZvz0tj
TiHV4moL5WK5uZhQ8E+ZxRXmoddtT03YKrgiwQrrxKckVeUf7DeJgdke2LdPKmfxKTDg8H/sI7QV
I3nDzEJKUWg1x9RGQlmNPcSTzbWq6IH7xkF07ZwnZkWddQBbgUFTqJ6KjApf8IlC08IwiLAaNuXl
9ykA1sJxx7mXGqSkc/ESwViWtPc6j30z7YFAUWnXn4gVbgu9E/ErHgS5aimxV0Kb8eITMtIrTLSd
RtSB4GVgoRMa45jV0FToHPZzEs3jWL53uJAdpSlZz3/iW0qpjA8C7AqG8paOlRLHB0W5eZSS8GCn
nuCOADwDlNdSsJA42v2w+CUsFtbRDDCgjT7Yw9rdl1ashGgQinVNyiArCBblV7hfJRPBqjrPzAoe
TK6eWD8b7ZdJJyFpgkhfxHlUepYrR9SvCBQtejv1KBoOcjqgadEUtd6uElaOqlgI1mRFbkr5Krwl
8KlrSN+/UOOIWwN/ES1FAew5gJLsrsQWwspZd1D3nFwa08gxI14P7gLQu6eZfvBpWMixdXzcVjX9
IZDavjeYDiQuNK7g8tJ4M7CSvuMTyPUorXExY0yw30w5DDjZRVPpASUHZdqopmXiII8XF7eQDWcb
ECtKXfiCoKGHhUShJwvUqOtpHiBHpXZD0R2ruA9NFSgXiHZuXYART1Dl2ShuCxlqeLghfSC11Fun
gJWrZ1AOQGaN1xCyS1FSoOdluStD7leU5R4g95RR4ggRL4Jais0WKsQS22DVoUeo3v4vniB6JQO2
TLP3zObqqx9wPWPEt1SeE5/FXeoQiU1viJXIu8GCYItbyGKbnq4NgX0IpDBAP/dxgyXBwmxyFm7x
Avo50gUgO3m5WJwN6ISmJwYy2sr03AJbQcCPXnBAxEMKbM5I6twLctSg0dLaFS8RQorYsiqypR5K
48QCMRy4pFLuWA6S8x8mPSIXPshcVpZi4F8HYqHQJtqy5TAbpI+1PCHZaby0eC5yHlvacC1dm1Ny
eydk1DKOdY/qOVoligcUw1lbptmQst3iD/VcWQgAi52WYk4KXZSaQatMpTi67F4KFkLUA5HiFsqc
sDveQ9eSMbi6Md6dNMXNZVuEvIwm+gqICBwOK+YTRUN3/wAZjpRQ7AyeNt4YzF3AYwopXYiGhZTA
18XAEyxYsbGBXAV4jQNvURX1L1jSPT9TfQAUVHWAouR4AsRfgTg3fZCaoUlEQ8YAVlsotSNh6g3T
s05zicmMpAUzNGJeo64eKVfh3iBK80iGfMGi+AVsVz7G+PUW0LKNWrg57rR09TNEh3miG1zw1keT
Zdtc8RGgKH0MMnWmyfiP4XDr8Sj+oUFrmDy6FlfcDnxCFMW5Fj1MMjgOPylgAkTbrLlnAKHw8RQs
i2ulyoWaWFvLmWDGxT3Fy1oDr7jkPh0r7uE7uxVX0QRUSt4OyVVlC6oOTZYGHAP5JaCuKpzeNzFS
8svMEBtUIVzI1OuptoPTFZCp8h2Q8RIwh2olAcKGw9ygLcQA/JjtLhVgUrniHotRFtdZEiFaVx7h
3pYFAUoY4bkea38Rk2G2LfM7WoDaZj54gq46WUKrs8zlQGjAJ0/j4iMLCou8YkFCf2ZexN6GnzEe
MG8ONrK7lCSboJ9QVYNtv9wSyktnpURBtINT2viIkbG2Pio/HSlYr3OZgD5/VWxh3T7IU8y7XG98
QSsTYEL4mc0vJ7wXI+IGYXfmdQma2nClZZsnYXfzBsNegKO8OYHDrnmiEWwD6PmLnsE8LCHTeYxD
fWVtqXGGoNBY+rm+0IOl+Kjp3D4X9TNiQRogQy7tkV/kuL4Kw+qmjIOLsfZLixa4B/uDhEvgF38x
UrsfmF/+i2V3GwBvrYKNeVvI6UTlX2laaZxQ4LgsF3ZYRqaSxDT3Cpxtap7P9lgoLdat+e4x6H31
GDJsXt/5KiVqz14uONxAFK+omUTWpEbn5CnzLOsUrK/MFDCcMP1zYKvY9xIPKgoXGaKnFpTg1FKo
UABpZ8jEFja8bHzOIJ3zlHnBuz8RDnte19ywCLS2IqrXlV/HiABg5XIYDyC2CX+4oUF+CEvQFbB4
TxGNC5Zw8XCsaCMqAoTuZCksbih8fMAoNgIAZsE1ZbPmSkGC55WFFL8xL60ql/SdBYvxKXeRfuWC
i73LeFdfcrUBb3AaBWTPwjGOke6/yJ0VDRdTcT7SlRsqeUshUk8G5WG0wL2R6z3eJZj+Blvcudph
osYEUo8molKWjW/cTCg3brHltNbWfcLLvePNe9i2NfMYoe2NVEZajLWM01WzgL+EFj+4Yd2CoK5U
JqNkSO3iWCPsge+P3HVDAO2viCdnYN2xcvk8E+Jrq5edV2K/uWFn0KP3AFoPMyU3s5Y1s3lEhVRD
r4nEmBXfzGGZzgx4SXnn+oV8/C4MKJUxGR11tytmRi0Bw6RXuvnbltuOHO4HWPl1HDB2q/qXaIba
hIsFHNO5UC3Ao4hgg7DhPYjDLg2i1xSyyALhpo9wquV5sYpc8ndymfVBLKcIbTWMmy23LK1aQv4m
FB4suPImvXFQtbbZ8wY8QUb9tbRQQNLm5UPSHA8fMfHWHkjgULohFtlC4OPRbSWvucnzzsWITbvC
4cRhotMSorpYgOxWgHEMwi+hIgCTkYfssKg60iw9t04ZSh2nJD28QCCPB4YVRTEMeYa9yFiWQpHZ
HQIOehGilwF/RBCUG33DIwaoLPmGfwOMs+9yu4aZug5FCo4XF+LNGQK71qLcLKppYt/cMu8rPME1
jwZXxOItP4lPXcIJ+oEsiXit0BdRulsVFw1d5jRQAD/csMPq/wDNRum2sJLXnqbClMYUhD47l0Ib
q2ym62USzwlsoZPWlYJXq8thbR2XYsRUw0U1MFPWxYEUhqLGoLODlbvxGJC6W2/m4gfWJZctmVGg
vmB6xdjn+xCUp2KIP2tWI36jgMUKN/WxSMjQH7fMEPOLKfpiFym2P8xd1izc2HHCymcBVrR/cENh
yrT3ssncopzK5KpzUDdUCKeOIGWLCb+IRp3avv7nLc4l77nWvKJgK6Co/wDZ+j22Qi1w72XfxgFM
h8E7WM+Yaze4NaT0Qu/cfIQdanKSNtF+ZYTdVVxsL1aKONQ4xx1EPmita2J1ntNv5lwSFgpEoXVS
QrocQ8VekLUh4Tohe9F6DAMo1YB1PwiRkA6VcZsJZmMblnpUEBi2UV5liKPC5lA8YUPxLSGyBwY8
cY7cHTn4gohaNVppJJlXkCOVqcQhBW5gSzv7BAyeDwl7HjBty+jb+eY1wm6CLBNN4UrXOqg+JHp5
gda6PfiVJRi+cUgY8WB1xbLMRFI/zETMQLbEafBONuPnbLWm0ruDDFAV+E5YXfUI+qnSPIznyJNC
4nYJmfUocdrTTy5Naadku11pWWwoJehFR+U6hjhBLar6iBzcKvlYocQKynlUpESwlh7yDVUrxjL+
fNZt9jzAo8ii9zqWBgABUfn6j4UGc/8A5HQeKVG/NVxB9ppc1rjGUQCrhCylg5ZpSBdV9xfUyh6G
y9dajmnm4SBFWqx37llDsHn5t6m6gqz3ATm/0SdqAJpD0xr6D2HH1M6wVaxemKAFWoMv1g/ZJWWr
C8rucNtJRY/cUClgAFDzLojUlFjKB5Kjt1CiIAoOizqLSj5Id6iIpX8eYuEHEwT6iMdSfS39wNbC
+WNRviwNxmJL10S31MepINe5krGbcA88kcWAEDZjzGs+B0qPDnFks1UcUXhgXKgUFUy6r8YBO/MG
GP8A+BBgrn3APLkieY3ozuoAL5ddzBha4eGDSLwAw5ILd+JvkAT7ja5pxGDAERLN8QmpajayapIs
ErjK6KWJkLGHI9Sg3B4g+WfSFoBohKlUnBD3pIAyrjT4lFO6gHw9mAXpAVEBnLl741nCVZ6eypWe
GVDqvcw5zwTwaSrKAsuNnFbBdPUsX8TKnIR1uow2wdRvRRLAzQPHmBXOSt1PBSCAj+echkHwCiGP
uW5QOXpANC2hwI53yFsGzJ1Fj39Siw+JsKiNBDuE+ENeUoFbeCorwtKNZKoI0C271BozNHuAVVFE
GG3V1ZKEmEdopHhlEMLUxLuEFFBE/lDoXDxHKsN0EHaw0CDq0KLtLBNchwcHg0hK2QCyqRj1e1XF
zYUBphsO8ULvEo9t4Kgp1g1sQrcVb1i+AvCuEctUXlgq54hyg6PxVLLyFDhDbRrp/EwqA1Jm1oyE
GDQw1SWsHgufULQjo2c+6F8/xHnSqnhBXxRchq2OVUX7IBTsKzDDLj+UpeSqlYLp4I6tq3UJdlnU
NrbBtvdwUgowIpNwoKIAHAfLukswDTa9RSWd1WEz7gJu83qDZMVxGpGiQR19JTMmvmuKyDAF+pdx
PLF0gOBTiNKQl2EXJj2qVOD35nsKJ0i+ArgCG1iyvEoWoO0tuBWg7rkjZCFBkSLNlqo4RXyyPBdo
KbLFerhVkEqvsuUwxYSEeVAGEWrFVRsuJMyWTlcmJCaFuBIJeHanUu1riwgUtfVM33RPxAvNqNaR
Lg1GzuJok3AkoRpRR+5ivUX3zKDhLDjI9F1zO4IXCGQQtO1LMYixNeKlkVtfkzPFppBWOnOvuGka
UB1HaoUuLTF+4f4j8vMLyALAF0TSRo0Sz0Rnuzkl37goiVXR1ElAdCPtlRwN4lZAHtL8QrENjq6G
Nq3XiVcA5guYxK7mIRTQbfIfE21AxyHENcCostGkI5UWgLOZjzgvKhiOgrh4hsYLj1c4NXulEojT
AVBdAHQd4YP/AAUwMlGni8j8RAKrmYdlSwBTRTk6ldsqQIMpLVc3OK1U9obAJHEKhykwKcqUtVo0
MFKWQSjJrGsYl+iWpY2Wbzcy112ckNydlVwEIlSHKziGvy/EQn0+AuJ0Zw8xpryJVvUpCpt59zyG
xIXsSgIeFZUAqhMQF8/ExVVRs+blGzcHAIUDYUMLu/mFhWk7rZxMFU1L2MJF8/xBLXSHoIsgv5lp
bZbxUZjBKi4FMSOeV4huVFDCs6m6CsL4lpb4iwPNeJaL3021fUv2UlOM2PYNYht1j5g5mC0tW6eY
x1e3l3IRooJq8K/2CcJQdVxty3+yOPHMtgTYOdysiJnPkMjq73Ks3EB3aA6wBTLTmakFUpLU7uAD
SlO3YSkQIAISgpeRDGBZ8b7gfoETq5lH5SsrgqVIcgfFUy3944bexnAgUc/FyjiYb3a8wwHiNZ3B
AotvHfuXA0IUtz0RWiVPAgTABsAsusmHqCJv+9itsW+XR7lQ0BK5/wCZLDFm8PAPqNjCl8lpfMsj
npVu9S1pRm31LdGUKaCtIwiW5Q8jIQK4KgrHJuaQF8IYgrW3/wAVC+zQTXH+x1lLuVVDGkYvocNB
1B8ASwwbMQk02tW0z1GFkoutcLX0kGIJOFrVOwq6XHQCkdiI3uAGyzDAiuEJZkAinK7n0g1ZwDzL
Gw+HmEq6arbjayhGYHHV8fMJdgL5CCSacVBeDQeziIdQqDM7IkKvHKL/AHHIxTXHqIo0jSdQ7AmA
VElJT4JxGxRk8epcWmUHUQVNhPQ2Nq2O0BUApWe4JkvwQx80L0y/+ADG7slGvPNaZCZKk3RsvKDU
BoPPE37eCNMGJ+ibBVnmBPwxDDxOS72WaB1AHzBTIBg3Ue3mANIIJeCNkMtqqOcwWEB0RPzgW9QY
O1t7izi7eIVqtFr7VIObaUGIMjoRnFej8y3+mnJYBBiHE3gqeRLWKSGlLtsjHwZhGCqieJgC+iI7
gHUrFKoSD9Di7jbAAZEeVQgwFXzBR5vDuNOGrIRhVmysdTXuJarHBKhR1TEhZjpBDRxQEfBjq/EN
Dau/UyBALKmH6UykAV79QBi118xUFBkpeyxqJzhsuQsGEYKAK2+6jlWh3AAZxRBXYQjZsw0jgK26
DuAKgTxLyFavkmR7CbGphVpiqjoVh2xWKhbRHzllCvxBPqzGe4LsG4Vb7uaT6PtLlGWJHDuhb+Yt
VaNr1KrSKsL/AHL2bUWw4CmeONjAaASvicd1S13FKTZiTaqnDojWJsqX8S0kLSHb4lqad4JF4gRW
MFvm4Ag05gwADUpTBg3aCshKyLeCESnBhBSwac1OlDL4gAL3Fn6gJQsUnVRRTHFy2sXCviH8hYBH
RZXMG3cimDiEh2tSyJWPArLkia2L0R8Ko/jxO0gpGQKTTvYZigsnN/8AyaMlwIDcWjNveWHMOKmx
EkdND1CGsFbzceAm3dZHvAdCeLQhY+YJgpsFR6IG/MxlLlFrcghRM/KMg6EU/Mew+LloYop5K6g0
9DVQV+cqSnJoNkQQUMr3EQdkoFGZdvwf7K7OnPUYFsDT4jVcUF6gS2rt/wC+YxQWh+IRICcsbeZS
pA3xcK4qkDycTD5bVAdfcEAlNeyOhCfkbCwVaPVP/IrjQMUoUamLSqh4gNKSavZ7+IPDReY5BXZ0
PZL5agl++K8QIAsDiiWjDod3EE+9hARFmtyqpXaHSvUvmTF8/wDrjrCTe7Yf3FW35QlRh1qjjGLg
MhWXvZOWQOSJii5VVcWlqeuLeCEAFyPuNQgZccw1Z0HEMCgEqc7EPUNqkhK75SyWuqZcVmZhxkOY
FhflzZG9y20T1dceoJdO9IRoUbfZ3G0gq1TqZvGmNrMqAbFh1E/tzty/UbKhXXqMWg/MVU5AoPmO
g6xToeoDgqtVzmwGRXebO/uUxGU3psgg5J9Id6trK1xkWFEET9p3KoLOCECajT4e/UKruvivV+Jb
sqVY5yg4YgfhoRPbUCht833HzEEOL5nJy5afiCfU8hkPoZAaq7HfKyqzNqWXRItfhF66RZbhXcxu
HDU7hd7PBL5XgfEKDLVApS7/AOxgU2K0rKg5HaOJ8o1mKcPahoqU8If/AGE3NW4wjnYLKrxHdmUD
qoLadKeOoaMVAHF8sU3YXQd+9SUq/wD2S3FsUBXUOpcEX3yrJxTC/B5GCyYVdX9QCZAp68QZC6MN
LgLWpGheiA5SgEKsrmKwM9zvH7hzKVFljX1k7o7Rwa183Ek2DUWWlZAGJ5cuH/Ygjwq9w03HRhtV
Ta4l4bn9TnvYi5OAy/ibi6zCr8XDm9YWnAu6JTgFGykdLDuCCCvMezi8iFBVeY0PDcQU9z3xWAq8
1AZhOdhqgJlkCjdmeT3C3AX2FXKACvj3LDw8wUTT6HEFdCz0lYKUFzmniJzaHbx1C1iQXkiRa71C
KUlj1D2VFb7IcwTQ9zTwQBwY5dA5fqEGA1rseMFXxK2olS+YRjq4fZcGkzD9QmKbSXphVK2qw9ee
5zPcQiID0jAxW2KeIk2JfSDPBkTdLvEBVeNuK63Y6OgZ5lwlPLARwLacwQFATT5ivHDBMVZIjqSn
1BayhinaCmVUqhZ8wjiuuodJtS2h7T5g3nSrlQ5xETEHfGwHQtLX1PEOeYDuQ1COu2/m4UmxVMvW
qAhxPIEKK1Tx6ic6qHMrF+44zwVsSdhtZKYD4MBGLV5Hss5mpMrmXGVxCItfHUy1ZONLGfmHFuuk
xKIsCU1v8xS+ospRVX3Hu04wgsWKw+ZsIbscRpewKlzO0EyTwbMJAa+MjjA0TRvUaKADSS63wxDQ
unSGioCqiCF+iVAFU38zEtgPZC07hD1Dpurddy2kGFbzFGgnR5T/AJFGVZfzCO1+L56m5FqViHRd
yLvQd752WKFou+oPYBD6qMloPwi41gfxGmsoXzGVlOsvA1wZLxgLrqG+bwh0vF6V/wCZyBG0eajz
SAfmIYlBfCHQF6HmMTIOLhtoX/kVBx4eZSYdtNPuIC6KMSKu5z+9JbeC72Wo7ejmHxVw8Dxcwgvw
wDttUqichKBwS8ao2GlI49Sxk0TsnFYxPioshpxbbVQkIpJ9Xkv9g8OMjlLqz8TgEbbEQCLWcXEw
KRyKyOe/UUTnT62PiqoFxfUFVe0yrP8AstO0FbhIdlX7jEn1CqIAS/URq8HlCI0jz+oIAD/WBrHI
GoZLy3LFQQR9YRELf8ksoKS/gmXQUl+Lh7+rD9QX6OP0TEJQvuHCppy+4VvdrzkbD4x49zAA8nog
pBy/mYC6ifO1CezH5CwnBG1/McugVX3DHUDb6Yds4T6ZrPDVebi2Eo/rcdKji/iU5oAq9hi8Uc+Y
2caT9ErxsN/iohuC6GwRqsleyE9HhcAdtRX0M5VhRw3KuVIX/wC9wLFk7Bm20PRhcFyX6hzrpF7y
xK+qhe1ORWw+ZxJiDei5TYWLKqofNVoRVeu4VdWwEr4IxhkRsqKZKeyFLa6He8QAUUWHhdXK23hQ
CuCJ83Sxh6mTJlVPhFPFSrxx9x0lVB4I3NIkvjhGusvXgueDkNs8PqPfQuPhnq2ADd83EseQ5i+0
pvLiUvclONcS17Rwfk8QPVsXy2Pa+yLFrhiK0Xrt5MegK1X3HLy6C15uIPcLsVBArKTbMJfagXaw
S3A1dtl8vJHEoKClWXfEJ7UDt4cSyWXwYae4B4cr2eH/ACLuBpTgZlx+fI5Z0kZLYnqouOK1d2KV
bNhvwr1UCAae/NkJCLUHSjmDHf2xMGYUeCw/xEBCRscpVVAM2m8Q7yPsSiTeKeqlpoNIpeXb5imU
4UG+oQhhFazd9TLiM444jUABRv8AcOsIAsW5Qigmr44YMNKLTGF1wR+P+xF91zCy08dyhi0l8ig8
3bX9EqZNi6PMIOAQFVjX9SpEQieCPHB9bdFqX9yA1kCgz1fOkNo2+ajnE8PZpziWaQVF0xR1+E1V
kp4YF7C85lsAGymJpRJzTqztp4tOZ0PLEKVu7zGLQJXu9W8Gy/4lMaKUeSLGaG6TmU1FLCcV3GqI
OYNMBV3kLcydeLhUZWR9EIqSl38Qm7AVrj/1ym1XbNtAK+rjBsSD6iIFeLmLaKy64OWFlL0/MPgG
zO4BctOCE2m5Yqdy31OSkgActlVHfcLDdephB2UBwVsfIRHISNGy8leuj84EDpDxLthageN9qFho
Ae4JF5EcaDUKUr8o5OOFMWrCqj5m9TxbGjSjSJZbxK/DtZk+sijYg2ll8QXBqNU7BSSnKicQ7nmO
GgrVPMa03Oo1g3exAEqLeJSkrxsctnsg4gHJcKAKMXzLw0fwhEmkKjJGzzLdauXGwTY1K6ydswxz
fMY6vkj2p8o3AKp2CHNrtl5aqkBMjfFwuqONyzVt6jKpWuAs5/0btxqAuUeYH4ecqaePMvixcUy5
nQ5il4Cq8x22DnTDBTFSo8w/Ed7yGyLeVxfZ1UuETXfuUkUYbzGc2yx8a3UxZsg5d9S4trN0ww5k
+IdjBL2e4lFCV6iMaqCAFTYj3Cw+g+odjVj0fEMENGrgRVxaeY/uFFXxHIsrxcCHZ6S9pPQ1DSg3
o+oSkxsPiNCK7WImEBiKlsfaWaTxBhULDghUJ8Dy1Hp0L5ghG1QQnitG/EqcFrWWIEHTBY6XUWA0
tvxDt43RLTadlXvEdwUqj07Zt4LDalGjWkY4cy1W70+4GdCQ5JWKKBHxXM8gCty6j8Zyl8bkJpMV
T6mKxFb3BI03rE3h0ydvbxajYAHy6slnI8x7iYNXZyfEzyYI1ajHCrv8QToNUx5WPqCVy14u5+JB
OYrCyleXCCBTRyutmSdQI4AG+eYYlKfGapKA8uql6moT6v8AUTlCxbH9yrLjbOKIAINV36hCgRU6
XEFRLXt+YPKCoCE8sh46i14lfAd6Y1LcTmtlX6UCmUcTN4T2WefEoQSeC6u2BAdSUucy0ICoWQ2W
d6S+vWRhRRQ5ZTyqgeiWDfvUtVGulonHu4MJYjfORuFRazHu4rqYKUTiWyh4Str/ACNEtjBXXEAQ
irq8MiJ1J5vuXvoEtZz6nQBNre5iOsJr1K+W7FKJeS7dxfbC0GPQ8ksQJCxK6ieplBzhtxgxYaKd
9QwdmKPhjhqhcuPuUFxddRgTmhMYvUFsZVtDSQWomWqBIl8Qqn0FVK8VKGjZzVFIKx+40Lq3xDFS
pqoPuVRWqKuIiQbVPFT49sPYlLQzkHkYuBMg+KjnoovY3xkWqApFbwM1m4a04cPcdWStKiv1CRaC
3KHCKfuU/FbKHkGl3lF85N4zeC31KuDVBVtXz7gAgNqDvzKyy9KHglzNZZjrxC9IhZLaDn8QuCvM
38TQ8QlnqjL9S6FbDkmJ1MS+0RXiHDtRuR7IayltaB5rPcqmBUlIouURYRRXxFVob4XzfiAlIwC4
j3oGafB5Y2hcd6Oyy1tl37NlDSapb1cRKtcwXrUXMAUrjyfMtEergzxUv7UDCoWbUWZVGBQ9NcS2
NuIqHnxHAPGQbxayAjBVRqXSFGLdotuj8QOFXitt1d8wFIqXAK3/AJFlv11h+bitJPIveQh2cKWc
bOplNESFeP4j8d6XiBXJhhCY78xSAH6BG/cxEXkZ6KhMpkHzOx2rW3eeNRUw82MUaWeYQCAq4K05
8QLDt5lijGCLOk9X7iLRsrm5ZpvXiN4NrZcYdxx0d3IwAtNUde4MhBlW1rXhjwxWwy68xbZkb1sp
lwW8v/JZHXDogt5oXeZf++Tww4xnD1BN2d2P1DkxZf5hYUji+INUuDeYEoHyOKIMGIKOhfMoBAte
TtZ1GBDiIVq8uI7bvEIVtSlLVvEPvfiMExqJvGmOtT7l2W5gkWaRaDVPEAWTlUuiIYfZUEHcBqCD
ZZ3H+wgLbqD9xLu0fEIoCFDTClY8ks3JpByono9oFtQ+Fy7iywRN75eaRe1U3YSnCB3CzkAWt3FN
2nF1guzrY9mnImy0FK/zGLXPORQobAcoQTbTcEOajvECh1OAwJTul7OiW0nFs9HuncY4v2WBBcCg
29lClFgcPmNei1Hidi1CUPWm2oiy24S4g2iVZ5i5Ua4DkKKijeQwpYHrY+XAU3zC/VuljKOclBiI
kKDq5mUcZmuE65TAVKpeSNmoC7O3iCvJgrYjpiknbhVRG2gWxFY3F76BZzmFeI7jwbS6JkO1j5ln
yMOowDp9QDgAq0/MUBrQq0G1a6ezAA0ss9zXO2vqMJG+NMq6A0J8xQScCpl/vSh4+4ZceD4LgqIC
3iIjxo9Rvqa1oXAqFVjz8zgbbJTl8qlXEIUcMcJdw6givjbQKy1N7hoZcxh8zsYKrilLdBsExhHn
4iE8L6EXHgA0+WXBSU4eoJcXKKP3CsDwvn1CKginLepYfFFlhEo3VC+PmUjDD5IIMWmy48om7KKm
J7nMts9uYNhShHFaK1ucrLkdXALBA7A7h4A4tDXjmV3soG/UX7Ys8EoQCNpr7gJrOaOfzGLEcFlh
AyC1aH9wT81Nn7hKqKCgkGAzdib9JaABBUpdjR8Ny8mLu12SiBd8MVWtRGdXUTS9y6SVixtcH4j4
Cd3j6gkVAqPlE3hChu5SZuAaMyrFC1d9Mq3mrY+HEZOplv7YyZbBp+MANpTbwfqBWFo4PqP2LcWW
nmPKJkNvYWd2GWeKh34bweqjvCuA1crttRorzdwEGaMp+IXSgVxs7i53gE2EE1eioHg2bwySuwTs
f2e5jygcB8y6l3dE+Yf1BiB/EBaNMzrvIuWzbcB6I7e4G4W0ZyteQ/wKQ8vl2EYsuRc2o+u68HuN
PjaMewlzKem4v/gwF9xyWLDZ8RijO0tX3A/pOQSherkg+4wlD7GeKll/hMDuogVRqUv5qPEbwph9
Qtc7bSfEEZWqC98fLEqUDgA/mEjdx0j2kfiFC5+GxIqnjIFFZ3T4jFCtovm7rYB4cQodJHvQNnhB
ib8QGcxLYNQT5lzWeLYR+qBRyJeEWFlEPU3ohbYfudf/ADVsHuOCtk8nkcD8EvOBNL3fiJC8NhF7
SWkvhfiaWVXaVZby0X6qW0zOVHwJcxtaD52CIR7SE0Jx22jYT2tTFqz4S/yZ0TcXRBQR6v8Aioon
usVb+Y4g4ceSXpXdg2MumIyfcTt63qfDA1eOEWTYboTfNE0HvHmVKC3ab9Qie61KfmPQivFOYHAv
RWv1NFSNgES1bZ5DxZNE77RCHbFNMGQXlXF1B1O/Yld0irnyrzA6HpaI+YXwIp0X8kcnMFb7YRSB
Vopnnrjj+YK6oHBI06jxeoAWApSmVexnT5zGp4S0Bv5gqY83ovioLaXZdbK53XqIdRKNziRD4Jgq
Bd+YG8e7qK6VpNxeeJ+I3pg+OKl/wvaVByuRaWU88TSKFwVkqDkxFsJ6hwAvdSiaq76/EbfoIefm
cwDgr/ExAFnUCVO0Cw4qF7WS1irtPtF88lUkPubTLgp3zCyD75bLE5HRyw2RZYChKxvWEy5Zyosv
S7W8EsNasRUhxpx7iPKJfdAnPUb0LJ2O5okC46Q0NuGRRRB4drErXb5g013ABX5BInxKqiGURr29
wUUHesPToA58xmH5ijUBt/mLoG3Cjaq+s4abU6lxCZUUP2kvEa5HNpb3AACvQ/2HknAhdwouaBNT
Bt37o1FbaoY9HUKgxKcC0r/EwJvQwLUexZZ7gCDh0Vr6hcY2FYStCtby34jevIsyWdA4vqaaKq6u
4eIPQ2PcsOE21VwgaG2wOoXAUucHFVWpXsjUtLDFSrk9rqpdJo6NfiEIkXbaovEVV1hFgumqIwK5
2G4XuU16uFmUxtB/UFFZYIy3M9oplxf6HqBa6am0/uPDSdbUp4Khu+5STdBYHLslX+EDls9IbN8t
SolSOvMrow1GsYAsYgmVE82o+zVo8pTVpSlESIgvazxUpMqLOgBEPiJAYr5g1eR4fzDiZWQwshC+
RHSQ9QSk3l1+JZzNooR6Wv2gISjqsiOP03+Jdw+FR7aoGq/TBF61t/iGTrQ3cGMozcqXEh9P+RLq
vpr5mlheLtUaBGi6O4huvBefMzJBdJRDOulU6PiowQHVtkcM3kXPxLuFZSGGFw2UshN2Drr+lfFR
TsKuyj9wFBXLpu/4gNCbguCuS117ii8mxIPhLkHruhAm4VcBjAnbaclxadLE2/UVBdB1CcC+NxQ1
UcgyEQImmM2w1mI+SaDVu0t/mHKhLKf1Hh0WLbBC275joIMpN37as48EsWnOo9hR3US0F3Loo2tU
0vp7mEtIKqcw+Qm32glIKvFHUb0q5ZGC2uGiplx7p2jupZ1UyyyMrJlvP/yHLIQsKrE2VV2gdWpd
PEJ2oLZGiUVxe+YSBoYfxHDZKAtX6gbI8wATzii79Mp7rttRTCDylkB7bsQKfSoidPFdQJxXHZ+o
6BXdiqmVOOHUvqa5dSJlC2KYkHdFOIeHiodxGYmm9Zho1ZxNqFGf8pe8zMR91DC2WA3V7CM6gWwG
Y8AUP4lS5LtA9zergyu/ENnFhZz8S6EWykfVZRFPgQaQXHJ+IXYQEs1mYtJw1Yg0R5Bq6FNTPIW9
oGUO5mHOXzLbi8in3TEMN/g/KaZKpKPuH5ESEYwWNszw9ltw9FhIJ+uMJ4JRsqbV1vLH5pigc1cb
BYjtunmobiiCpS/EZx1dVnOXNgxVAgLjnCj2hEhrLAhWsCvsPEG/FeJ+Jb+ALW+uIqXuEtgWpdex
rsjIF+ul5BodU2p/7IqlWlbksgVVnDcoqCJWbC4QPJnQHwhX2AQTowB/A8xSZKkpWc83fqeWJYpE
VBxxp8zTGcBUeuKzmrzOGXLst5h6ytLrV3M2CzouozzDgqVSJnbB9iYC+jUTIgV4yzMXTCTLmFFK
vf3AFJsBGsllDQbavsnD3hRN9wZo6af4StAZOHsHuaDaQAFcsMotpafiLVDgujRuO0LAKFHZSyRv
QeaYS64ANTtYUD4DpL68kpJeClX4yAe6iOu/+wAop0aec+ooBVnEqrMOpR45XiA0yDxy7y4pb/Mq
5mXzAPC7lfCBWgnKxO0iXwcEQIlOZGpF9o3GwX1LSWKHCcvh6gpRFSBNp2jg8wgpjQ/lHpFlBiDV
kNwVinEMZZhNNgcHXZisHoG1vUEpdRElTJTQlENQWlQBoiFU4jkrtWMxQ0+pxn4I22+ZhfbIpa0L
gRRpqNbvqIlA/EdJe3HTFmVLsLCN8PqFC7WIFnLyQDlq54BBXfHiG7gNHsrtdGX0mmMN1xykr2ro
Or7mIgDiJOjIM49V8bKjxDUQuKpwGjLmDQDkZZUTipSi4VUNnwt9oDXVsMCgUbUVSVNpE5JCqxg5
JAEV8Ey92D33bn8QXKA5jMYeXEqJUWPc2ptyMI9CPFVFVmso7nGW5cSk4AKIKPzM4halbHBJwhe0
KYLYa+bgiANWIIcuUfxEQJTIdldg1AdRxUZt4wZAk45ITcptOdgBEKsJf0BVEqnNCUcbKYE6baht
roqA9EckPzIsU4lqdXkhSlFqRvIvSS3VnNlRciXlVC80teciEaLWyK/tQCw0oZ1vA5uUKGdF5LFA
VeQZCqwOrhuFgHIzsPohWFNiDuKIUidmL1tQpAqwKTgymFkA4JUaQtSBAneVUelJ+IqV1ourhFF8
KhSha2kFUDtZGNRxag4hLqoeNR0aQXsHRS+4iA/Dy/iVKlgLshOSC3pGVYiK1dQzU6uoTAVbnEbh
kopzEnFZyVFhyJHGCVQlhtLFIXBCm+EQDu5eH1NcJa12RUxM0ZsqXLl9EAI67wwwI4T+Z0FK0fmV
TE7Gyoa1gc2R0UqraVUUrU3djX1AoUNArYqEgUKWx37QoaYuWdwPzAUK0MNiKeJZ24yFVgc2opxW
jXFRdeOfuWv6S5lqsFBbQS42ECscIo4VZ6gHdynd8RmxuHXmLRkiO5dAGU7f7EqqCs5zSEGAgmtg
ldNthLaKAcbAISgvs4lZRdBu8wHLCtergKsXnahM7fAKi/IrRo/cJvt/utygsAAUvcYBp8wPF8AP
xNcfjUeGHCBXXWHIE0RKfwqdajcUakGQbWczwQ4Adty8x0wCFR0jZYfSVmWbpODf3BpH2z/1wF2r
TgTxKTErV0Pz3B5cEEK1MugRircQUF5CkfuPlttYdZUCFSS9lBQhRT5/yJIWlUBdfMf/AJBgaHSq
riHiqVmV1HMsO89Q+u3PgSju2SjwRkMXyBZhHLjI6XfcOE4B2V1KYQNV649EIvn+bwmAkvgHkg9V
Xf1KUF3cz0GmRMKd8y1ewy1S+AVKskHIDuljiplMd2AoBPRZGlv5I7NeYHFiwCz/ACUAtIdVUsL3
rxd8t9ShJJiuFEMOCWzhyeRQgNMcigyXQ9kbmXvFpqFnFpyK7+4rXlNF0tw81BVWm+MZQtpC15r1
E1EsV+auG6mOAPCkaKJeR93CP0u37CHoGB9uq7jJqEodtqFWSgc/ZBZDTXD0hCQHT1pOYoSA3muy
LKjF/OQOBYIb8QRzwsqqwjp7Vqwvj4hYGICzQIDQBpa6uvMN1S9gH3L64AIprxOETCDfi4Fo2QC7
uQGSVPkBgxwgWFh4+4GWr+IJjBRMu/JOicxrCeTZaym61Ku4TEO5Sm7qWmz7psytJZ2YBw5rphFE
oA3aJna/IHYnuMxLV299xPpQi7NECGFUaas7gdkfyvKIU8ksHINPD0uKqauBVgLYgoyzl/5DRWj6
l+0Bv/CBFhc1zLhNXC8yk0d9bHWgDwzmNqy7HqFtwG6lNFPXDCl1aNcFRBZYWi7VSLeNthZDYp4I
REBVwJUATpuNNrQlvLxCVR4DiO68C/uDgbb8JS4nvuO5VhXfiCaLphLoqFOm8mYS5+kEQBbM8Qcm
mRFT3NPNfEph/MUjl/MquhFwIHqKma1K8t+IAKLviUJdhhZiwbR9kpeDhrjJU4BeTPaULU9QkI6m
tNbCC00v4lUPR5ih68S/00GFqhb44yVxCHRGsiJ4ZKFnK4qsKli2ekr9SXe4cylKVFZaHO06ebgg
ubbqIPkIlBAK15lgKmEuQYsl3GGjxcHnrDmFpCdVBKuFEivZV2FuxyIQ6FddR8bbmpSdVHMRoFLr
IyblKlOE1yxJ2VfEEA+iHTQnDMYDfNEvoCYai4sNwEjdfXE4/KVxBSXd48TkQcrKJCrFELegkqIK
7sMC8U9ECqXYsdEAdV7lZTKcqO3BFWEW0APmYb8yloltbjAyQbHGAWvEOpFt8LG88AJWCziZGEwo
WdEU2jZk/sdSLU5kO/cAzc7r4ljC+RmThBCoQhds+I3ol/gSqHDF4nbH5eLpAqGo6MJolHROIbJH
NVBSI+FSoKvbgOXEo4hyi02pZXjn9kcuAmKIpdcV3KHAKDxLQNHmOA0PSGz1lQse1e5RIQKfmEkS
XRUbKoNB3E4nl2zxUzsxNdPiLwJ+OQNNkgbbuChRoPoNjdLMXcRZvdrps5lAcotUtvQL/mU6g8iL
La9lLgfTDbS4d4CK8rg00NDIoHzVVwDQuAcpHG242TbpviZPPqUt20JULnn4uLUhmzxTLqi10in1
Dvogn4V/WSqFfZ2QbNBr7mR4W3zxEv3mm+YgQjnw4ZkN6Og+0mwSLfVZEIVqVd4iam9jKWCIOq7I
0krP1iOzKxtCPuAsgHYHxNbpWek4v3h0uUwjqwRclY22g6lTDNuQHcpIjTSqhlFUy3gsi/O/8grg
hAjCaK/UuAEFMuAey5aRBECofRsQwKFfk/yJdEKrt2Mb+2LtLxYwiwWrr/Y7epAtHu4NbvhRdssX
KynfNQd1pCt9TXYaLgr1ALtghO4ZoRAapeh+4q06cuWrCiloFce44gxFuqlEx0I/exwSj0gyAOfU
uvmMo11mmrIisKLzcpzpqw6iC55CrX1GFlk127YWc4wZEb9wNM5cLyNTtqIElLLtfL3LOTqTVtyW
6aolVvmX3Nq/qpvAByDwijW0AT2EbrpBFXsMjcbT8UUSG2bNYTOQCEA042Zs9r+yyvllVhix2ikK
snMUGu8JWAm21KPEPDVRdLlF6TAg81BIdQtr4uzqHGS6y67fjiEhJ2Zhly86FFQXxUQ3qqsFb48w
x+bS5SVV5SXVE4Mb5bXH4lgDlH3wziBvlvtE6fPpGmaaj3OQUg8p1cOXeoJfmKSoCnN5B1jH7jxC
rrzfE5lMlqCZOD4g0R07D38wTqssKvWePcP7xctUK8hNbBd/iEHVQFfZiL2OGLl2Z9XBK2eWXuJK
qxdb0b5lLVGuHRa4jS3JXTqKlvaCmY7nEI8F7/UJiQ9jzKwklxo2UOkosEvv1DA9BwvyS4VmeoNG
hB3mGOshWnFx0pHRT3k6Q+oI0hsqC4PEt9fiaFmtVHSsBzH3d9niYH1eDqLRzmQ2GrCyoiPC4pkI
D49fcK2o3yFEvUqyx3cTjgnIOhjzlh+Y3V60MWYKtvEPNT2hwjuoDiyqvDYYWq6eENlLYoBlQ6uG
UQKW6Y/ZLXjSCsx/VLuaK34WFpZYXJfqUuwvuXFEXzFwpzKaDZaBhU1xjVRxX9wRuIitcpBILp6j
sqqqvmBqaXYnxAQaHCKGgQ/GS1ExWTE1p/EAryjcQgVeIUTfxL7Th9MsppvfxE3dQ2MbFc6qotIC
sjx2qUsWv+w1QcX9TQApZzzpBLydSwytZcYW5F4S3fZVf3LAduGOycPMRdrFfmVtqKfxKEpdsFJy
QTO423+Yh0oKjhWloN87D1A+AlR2AQcTFtEK8zh5VMcQKUUxDzoqVfibuaEO1zK+adoORqz+4b0p
L2EURr3FSUgPyh0vfmAIKfhDIwBYEWcEFaFh06l5LmsTR8xEXWPxGSA07RyxS0XfZLwtg5ahW2bK
vUsCu3FQp1xv74iJ0qpcdFL2L7QKevEMSUSfeQj/ADXxGIotp7jWt/qylrIsK4VC+d6lDdcktdDW
f3B2A8K4hOtLFHEYIhXS6mW0BsPbBqSFebATNC5yMovBYY15g2diqwI5JOzhORZh8xsKBLqIXHlf
zKIi8sWJIKV3NGfdzcDyhUdi1XzcxeUTe7gfT05D1QodjGN2mng9RaK1Z68xigDVPUverCmbSVFv
ERhvI+yKhpyNVKA+EfHNxxqzGvUe25BSNlbQRgN6Bq/hBLbB4214nzqL6jFqq9QisvRRwQBgdD1k
WuIHnGUFro/cbDlWbLIcG1gGNd/EvCjRTwEtIsg/UsTM14EOIov4sGSBHB9TQ8stk8QGL2URLYGo
nBxDLqa5fEPeAU9FmRfkSE82kdY1pdBQlWwFV7sMvdSvLmBptNt6WE2ahamxcBq2F6gMpSC7sCUG
iB8RbF8zzcaCdOEL8RXyKAY5fcQ3XWMio2C1oNwFDX8L/wCSuqxB5ImONgtBGqqChrH2HkpIVdUD
q6miwKHG7lCQnss7hQmOjhmSyNbrzxfqJrECi78XzAylO+i6iuACtVdSuxZPLblh2v8AlkCQ5O/d
QCE2du2oj3QqFcNSy+oCQ7jnCFWPWH+QixMh++4qzyEdWkQNnCNEYKfxwjVTLaIwoplbzYxsbJ7X
CeQS07Ldg3QHOpVAJcvwoUuFBL7D4lCFBUeajoVsOw+UbEGsAcH4m0Gb9QQcY7RizhRbKuPFyN8S
pr19UeWC5VaBbAlUKfuANqpAebYhwQLy25c21QfwhRVlgVOMP3FohGHq7r+YT45G6Ov3KEUeAHhH
ihtFdYpKlU9af3GRfNhxHx4IRu+VqpV2gXQ6/ME1wbhazqXYphoHqXNdU6X3F8DlHLicHSeCn9QD
73zcKGD3UB+Ysz2njRxDTQSlWMWxVBXgvl+5XEVDVqgyDVoRKk82fxcpgUQBPDJzMOJRZv8AEq+a
4gp5PccJUE9XTiI100Xf/ghEqVGW8h2nMbg+1fPlbWxmuocIVkgC9oZdQBVgvDXRYQNiDs+HmALg
igD8fUI9biaO9/ENylIeIw+45aAH3Z567ifcJaRzX3EsQ1t6HMOUUoF7um95irVYIabz1Ua5VX5l
MpXxAJZDwXRFHlXmVA0t49S8SCyzI0N4JZAQOPidJ0suBEV5uUTQg9cko9SRslZeiy4vRF63x4iO
TS06YIx13zVkXIAXkF3FW+e5wcFs2GJUXG9uZyKAAOPO8wVjcGCLMAPuII6S1831CMcXsAEKhnZF
yJgReCUvFvMuUUqaQsRspUEB1fJEWPRBWi5gti0yijpEctVFaaZTwlh5QUdKM8xhQhg4r3GuO4eH
zFYwdfichpWtJW0J2vph8Ra5i9yzealoTALH6KFk24ZV3Jh0Q3q48qeF9RsYd8zerwWDr+jzDKYV
FmkttLuLTmCIHtTzKMrdRzirEtjVl8AuZpUeZoELXJEOEKJQAAVzOOS8LKCewHmYkgPzN9h7aIvo
GhDey7oLahiDpLg0dNXEaEKeILEDYKfVUvMZm3DWiAaRtwRxcAgCZyX667uHxMpbDiSt2AjR8rly
A93Lyu0jCVT3AzFEF0V0viEQINkDKJTcZatP1FS0NeIREm8VKqU2VwRuwi7r1E6BFX3BQJVpuPVO
Y32salrK8xvSSu+or1Y9VcNuAApgddoUgmAaq8ie1UoP5jbXEayigzzzuReFFBXMr2VFO5zuFHYT
uo3zsbiWjTB0ODDFBXLI4BKMuPdvhGyj47X5Z2LS90NnSW5hAPA31FqM2MNXSaA8wiIgoPEHjDhf
dwWbhZKMKbDbJOr0QLxbt+oHsATOYOEpzqVnC2Dv3G2lboxfwVUMPg+c8vUGqAUruuoJQtiemS4U
WCtfKX7BAL7i4VaqVMwdQwf8lg3PY8cXHgbsHRNxm+ypRAxvfqZ8nV1C1QqGQkhoO8MVX5JVals1
ijh+JQKA8K8ysURI7vIzSmwpX3AwDWfiLYcCPdQLKaOqlRgCHhGKtq1tUUS8xmKe8lKmFX0gWlCJ
zSFiBPTmJ4Dg5RfEcmG4eDP1NYbYtZC1UNr5QriVo0vy2PGK8s18St1KrAVf3EsSgDm2qim8MXnq
FahDhX78R8EB8vULSWgYvO5SfIsWBLsQFW3BLDIJyKiKlAhksl0F/VGXbHgLxC/0FIUJcs1am/8A
qhLwQVlDzHBO1/8AHUPbcua/cWrOHM11sue/nQcxXtvcHwEFBWyk5vd5FH1BlWF5ITmbDCt7U5cF
K142V7m0KaRSndcU5xC1EYMPcq2DjAPJEqQ3Ra+CuYl8usnGb59RlTGUWp8+4haskV/cNGgoVni8
PcN6qhU+PsgCa74IdANY8AMNG1PUBDUl06EjBYADFepT3Z8Rdyu+8MvIjEYBYt35fUs9h0Z/kChs
KoNF8QQaGi3uBjYKh3y+YA0dOxX34gVT8iPHHMECFY8tibACOFDseiTG0HqK125a+IpxOoNnXu4G
EzfBPEFPy94ygj7RW/MAzhgtvLXEYiaELdYnHZo2/UPaHRTh7mhS7v2RVe+No+JSZp1I+3icv+cq
fHUrhG3zfnmK3cKOzpDiLvmCqm3fiWRKBQwqn6lr5uqWiuSu4RMFTzfEWTVCCpXiogCLLodMyKH7
/fjCY28A6qf33PBRW/5JLO9GS6eoq/BdfjdSqOmITzVkoZBulKfQQ8Fgg0N9R9hLBU0X4qILyow7
9YhD20QeWRaIB6Dtp8SruYgof8g8b3ARP/XAkCqMCgllabWzRnLIoeC5oVQxN87K1e1jR5lPyiKe
HbBRH3Es9HUpwj1KHI4o8koOS8VCqCj9wFrQUTDdgfUClgOh4mEAZREj4YTR1YyKil0O/ctQeGlv
8IhlK23jiEzLyBcdLsa8cWRHAcJiKirQRUsFs8v7j1Cc1S/zC4fQGbmKHd1DC1TgGQYLfFb8ML+l
i+fcQIE4EuM28uDKAOqcwCr31C7HgjQaEwK08SxCtuMexPJCxhvpCdj6g2w2US1rwgRZG6bVjyuE
XywibnbVH6nmWj/EzegKXLgDSHnVgduYniJDphb9ymcIstmyLaB/iWGXQs4fEWcpptl7J4ELPLto
5jTLyLDC5G1QeZZ2BdHiAQItQuYafGlBYbC8mDlVnqL27ppsJe2fDG3oRfvmGq6+yW6qYdofAW1G
rL4qZdYJ6Sr56s6+IzVZzYccDt5EURXDT7qbEx1aSHTr8eLlxYmju4YqzduOlu7dxmCTVrYCgDmH
FBofcpuYK8piXSsWkuQL08Q3UHldmXS8v4lo2mUYxyUa7M+Zwkei7L1I6U1UP7xAaSDXIpGlMTR3
LGI6jGnmMgbjuHLgtaXmTLQqE5HuAl7wLpQIPQP54gonFeCCZyFLWEhp4u4YECfc7jbo4YUaYct/
UFVnbIW0BVWkMCYUr+qh7Q8CqZepPpRddUa3YWGyrOBNFdAg8BCkLgGJc3i/io6FVYniVsckQfZt
wmf1PGWlZUckei24RXGgl4ikaGNtnm7ZfX5gPTKUa9TzciOeo4ENgXmVxCgJf1GVhKG5zSF4BcrO
IIsXVG8N0j9xo/EKyDEtxzw9Re5nAS3mdlapsNISFfddQOmwTn7Q77F2eyMGhwP9ygZ6Jb+42hVT
Gj42Ez2aGkzC2B4hpCSr5PnYMgSlrFxAmkXLWpSvztV+tgYYLoqJxq2AKszxEq0ZD1p+E4yzDJ8V
FXUUnQ+CKrxuf6h8MAU0/WcxkmFVw+WiWOXheM8GSwqWhSm5so0tQX5uUGBYVQRsbMLwZtRBs5MK
rV8IXfuF1jhwyrx/MGBlGJAGkcWrItBF1KXir7H9zxzwbv5jUSRO+R8whNwAlYQkFpYD8ywMtbBf
m4aIKxFv1NpBeqejByX26pfuILRxaCfXMUe2B/dM9i2G2/PML2ikVdZjR+Sp9ZDGgmix9xkwde5X
MNRXj4uUEQ5cix32W35uNUyw7D6l+MnCVvfzLFRtzRGHWz5z14hABrNqwZs8GtgcFjGtIrV95KiB
BqqrnYAYqDxEoq85BrF6tcPKCqbj98yvXLjvYBWHAnfuOoTt5b37iV3+v4lvgygDfrxEsHfU3qil
JfzEB5mkyLr6t57HjkrpQFoLFuIwSDK2HzHkWfEV3hoqwsoXN0+4RQL8DFchQqH6mxJltoJQtCnm
joNwmkluI5pxfmEFk0V4PMCK8x79ssjVbSqo4f60rcaCapyKPcXqCOmOQRYEE3p8L9kbQBO7qLfB
dBIupLVtRR04P6RObaD+0GWlxY+EbEvbCYTV7bHlIFrcz0wHAtSXURJYW2Y1ZNU5+IyllgbXwS/O
excwM3L3OviCUuPIDt9QOlvlLhIa1aGk8kRQDzhsoCUHbCEaf563Fx6+7B7boFfiWgeahXSB26ie
1RnaqAWr4gZTS3kiccpYot4RMx9GcLrI8pDnmEua+IJLRlL8eoIAcj42BQ3vuU+CAdsrYHYeV7ZR
WH0hUlc3eygMoZkXXsNnKLb22CuoF8+Jj1olWQ0t5OnzOQ1ROx5lwHrx7hcCs08SrRzFNhGvJRaX
qFvlw+MjIq82v5lhSnHlEybRVN/nxCWhr0+ZimBqqh+82DACoGLXMDh7yVDRVN3LJRSPcvg4QCJ8
QG9uoQvkiMenPuAhfPiNfJUEC+4A316JYJHIJjK1gwFnMeetYUh0YTxBwx3AfJYxl1bVXGR2yGcS
kK6momG1YAJUQPIcEyKVcshK1GDX7hbaNghSlcIkGDV8rjwDHAq/mOgU3tS92yqKRiqBLx/UScHK
GEgseG/coa2LzlKETkpcX1E0Ag9NlD9kuokGIqN0UOUbNUA7eSAximrrF1mXKFrfThgsqFWNPqM6
oORn4lMKzMdlmUTRGeItXpLm5K3CMKaXlrGMuDopjzEOaWxzVNNbLivOhbA516URB93VjvuOtaHZ
CIyQuiqh6glW7YOGi0qHs/HD+I9ichWsULLvLAetchcpHKuiLQKb1iHRsW9e5e25pOLiO4haGmBh
uuhkfLZyQMUJg3o9RAsRgVFlTFtMqBwOG+4cVXZbaALRbipj5QTBPUAARtv8yginQj2znUcw8m+1
iJke0EEkU6KubbK1BBd4HFYmVBdFD+JlnfkiRAEaKDHa0HM54/A1lmRNTiMggHNcRvOjW9xwW8xU
+Km4ROS2+eI1fiAyHf2CnEIRM6KioYtDlKuo0CgwS+4MZ57aP8IIRkULBFdQcwIhBiaIRoBrF9xr
+C0n6glRWIYfUusbSjmcwgol164lWVXNaH1kDVycqlj0a+kX+ou18hDCsoytwGQRbXuC8WhdcoZl
BjW3KhYaupybbWBpZT5g/wBSRPSOHCe4hGqqznH7MYJjnaiJHoBZTHZXAH+ROOK0BX6hiFi9swXx
XLYMBwdNjiuV00sByxflePcAhqdliRqLv9BkDYQopjgYxd/uFVSq+8w4OPG8kqURAM+YS8DAYwiU
20Mq+4fKADXW/MILYqkTMc9Cu49G6vgrI8KRjQw0vm7pFaKRXC/D5ZRUg86lQCa4DV/MeAuVX3H2
nyGFUqPpUuPL5C/MMWqoDlhs44DYxb02624txUoaD/MoYTnBqGhpB2DmNNDqcjn6gaaV4j4/UvLS
v+QO6TZ35+YucQEGdFCWvqPXvjFN8VO8sW5PiVWmcBlrkXFfKPptsuDLjVLLMlgHQK+k8syTh6ld
6hVEqoyV55mJ9KHB5lZSoOY9ylBjIXtGFFYco1APrjUEVNFwKlOe4q6AXBZl3/Ryn+47om6HPjI1
oCymnev3LrFQmt1Kew4Xx83CgCpOU85ALsL2UbxApY+Kq/Ech7AcHgvxM2NFEfBbGhDVVnjiBsYB
Lb8MC7tf2vmU5tUnuHWytUW/9cK3YP8AL5jDnMKvHxMSQiFnoqDCFSqd+IvQpiKO5cugAR+jDxNx
A24guWwVm6IQHe4FfmpeacDSvTqN0Vyq1v62Ueqo6QhgYaE6cdygq3olrtlQz9YuSNuKHjGQfi/E
1TC9MbX5iA1Md67cPMEVrrH8w27rB1efxNdSNGy0+QaCtIFNgjU1xKMWXBaS6P3xNFKHuNNsckTw
isSV0F4vYjZqjkPNQLxUo3wcMeDt5sTLgYEVWndVOkMYBlcTdrCKAgHo4R6tfqAC21mK3h3PlMCb
1Uuc4OQL0aEvfMwUrLrqM0XahIOAObi3NSjjeEemytxNjy5LALQbmso0NuoV131ctFMKhzkF9Tsy
GtiZUCgeCQcGnnY4hYBT8y3dQ1UruE4PU1ajsgDFgS/EIJKie0XiKwq8gDNMwgXTh2oqRhGWvHuc
AJUnNeIZiNJs2UbY+oFyUxQFw8wWLqphX4TgDmOaC+O7lcGKa4VKDhRVRzYIh5ZQ+otftKud4Spf
jwS1vVa7S5f1jgEgDeHAcwtyKDhbmGAFUGhalJXqZVCWvfEPJAH2KmCQ4SGpUxx4gzOUr7l7ArQJ
BgA8YRRBIK48wKfG0QJFo0SlVotHhmOvgOqlLxRthG9C6/MtW9g1ywIBTsImHZykysCL9QfYfZ6h
FTSqgL6eXC3MGKtqVoNqurhT3vV8yhUW48xgGG3E9BW5sr4UrWXwY1lwWpq4hlKE9Q4SQ7LaB0Sg
RSqPmIbbHPiLA2IAzZYlFFMMslXjbiElWvmNAoCQSBVqRcV4hsLtyFcYhH4IoErUAsqrRsCocVaR
+gE8RaIOnMPqWYXsKOXdncOqNVsLQscMLBwF0TKxSjKKLNNiYoq6OSOC6+1ysGPBzDCZUq4gljBd
pGwA5qcQ9UeIV2ThUCc8vBsDAL0FSg0NJoSYHxQckDByiKEqC9NMBjsVEgWam2Bo6WHMSCw9r75g
EAbuqyFrcRAgqhpRBx1NyXrXdUNjCQdouFijVRajYGtmwKWA5iFC2mCrRZV/94iCLoEMVQt4XEWK
YmcRP1wUXC6SnwuDNUtrsoyBog/EtVeKHC7/APCHTOFFM9zzfYOWoQ6uy5AWgnNwIA3iDTKRVfqB
yAcqle50z4Kl/oWydJmVsE4ljTCo+oSW2g6Q85SqGxDf0A54iUQdk5eIq7mF/lKfF4/DqOwaJfAg
KCwqL6VQ1xRBEqgg4bnQ16vMcXFUeV+Z4FAHA7hMUXf3n3BPqqpy+oyvaX8RSc4Dwf7UPN4IcVEU
Kbo34l4hSYxGoWKlLl9QBPKBx7iPzQDVbzC3lqp7qocuMLkEUFUPUV4qojmzTdO8RcKhXtcHFJpT
ZY9g2spKkCs4HMs4taswlvRxCKt5jnSiFdpbcJOaB0XuJipj0C9ICHCU+Af7jwYAXIXfMuYW0/RF
WxV5bn/yV0xuo7pf6g+kvpq1qXr0AN3VxQFFArOKhQareHMMBFToIRXS0LzAgnJ9N3/EFaXIvcvU
Cl6DEsbqgFUrHgpWnFuxPQfhAoPkYlmiFV/5ssRj9BpOU7SIvv1Lu54a229+4aq0P2Raa23oHjzc
ZkkPk9pS0jHf/slZ4xa6MT1kOrF/hR5l8VJtt0cQeBFlpvh6jb2bjy0QsdjyvP3H8rxDZOsQuQCL
SuoRwpZW28QQBADhoN/mUrjYytF17h2a2pQqzY5Yowco+AcF6D4gjwolYfKRNOlQanzH59peiY4i
f3DnwCOVNgS7YKQNLsN2Fd1Eq3S8ZxG5w2abH/CYN3hWj/sEYEqvlZ/Ex2jgB8dZAcPWWhUBkBoo
HS/ww1F0s8sThKko+f8AkPqSn0Mi1qfGV/2JAsAtWyvGiHOb/M+UIxcL/MpIJfubw8ZUBBzoAv28
QNjDSnKIG00O0EbYQxUt6GXFARonJ2h6gpQngeKgWXUIYC/H3Cl0diq1YzDtl+HiVXlrA1d0cSku
2Ewb+p7CCt7q2W3AP2gmBncsEavuKUOEIoYta7iD456iVH+Eshm3eA6DIp/ep3vEEArqONtuPusK
fBAuC7cVhAKPvqKqIbfwf5CBxF3qDVFiqeZcC0frJZ3Xh4gQgB8eILt2TZ3bFqAX9xmlVluF3YvB
QaU4nT+0tFj6lDtek1SH0iCZS9y3fJ3MdEiHgp9QGIvxES9fETIDYdvhlQA75lWCQ+JjR+QHuV0B
eka8Sr6ZVo4Cuo1kosbjhbbfKZIBiP3KjbGpQZXslmBnXgStT2j7gUYL2IBxtvllsoAw/ucjoyGX
D0l/UGwBVfE4ONXREht0eUdSLrT3Czqix5uE1jmi4LinKdQXAKy+uJZNtxrZXM1qBIWsfiW12Bj9
sa1ucwpLmy3ldhtQpn4mGdXUtoIoPUubi59QHcC62LAoMF5lKBhfgmaKMYUvBz4mMwQrzAOiocM2
p2xhyh13nYd0ZpOmFwxa25si63zFMcPBxF6oOKYo8oCXwwmGmu8IFI1ZgJa6UuTaA5SGEt1LrCNP
UdqXgf5i3AVadzI8XhjpqDS/TLDY6q97GS4LH0j1lar42LZ7D3ke3um2PDepfMoSrrKvOTpfRBJU
cbV7Ha1YZBdOeoC2KQyOvawhG4RtZFKGm8gCWwG5pwJpzOpmFOYed68OoZACtqWWKIK10AjaZyIS
tNSrIX+8jFSitwzMqhFZY2+2V6izYQrrVRg4CWMfFP4gRhqfGNCEIz/KIXdLjwRrg/cd00VfDvX5
ix5DuM5q/wDJbi2KVxzBepw2QJPKl9wDR7ucNez7qZl7iyp2X6l/4op4ohDgXb81KkWCLZBa68s6
S8D3LvaK8dwyCyteYbbhxgAV6hkB/MQgvH92HGit6I/aUonvNg0Qq+fMpRTh4mQKRzCEkgPNZKUT
hGZFnZ8Q7aSGnneYQAXQB6qAEwI9gL39yjENsPNEGh3V/iMEFGvS5R/RQ6ckvqcrGOLTC5QoJDve
JXbim5QAMrg8S4TRD3MC6lfuAArtv7hOIB+FSj2k4fcuBUl/5hdy1G+Oo48lAdpKP/8Aa4SpLEP1
EAPwRqNA8Kviiej7r5ieD+M2s0K2tzi6IWzpKRuhzOPLK9xavDSTgvl/DAeL2/cCgrWO75iflMhz
OaR6fRTedqbZqrZ7jC7RLPBcwpdgcn7g2RwdyvNR/QFuAr9xv0AdsHiA0KweAmITZ4KOYFNkuYrD
klg0iv3Hudqv2oBIDQ8cy8UWo3MhTSB1sRd+4kCtBQ82y7IUw5VwlxrQP1lzZ5oK8wtjc5F4W4qU
CLc2HMGXgHeG/qDC6UZWeIMa+myhzVyybMB24iiACrCyCo8QaKeYlkmVe3lygGiAu3/xOJrDcut/
ELxSQDcnXAIeonchwfvYRJR3rqNMEJOzY7AG0t9ofuKQeROZaBbI6NoTs2FbbMfxG/uugYtIS7Jb
JVL0eoCxSaqeDpi6/wCCmutqPd6wHMd3VKftLfpDk1SrB3jrmiP2lXAXmpkEYaVc2AkFbbSboV3D
ftc8uf3Auqq/BqJ5q1hTnRdgrW+1QuqbqMcUADq4O0qiEU8EGFFZ1TiUo2F8dIfDXuIesenWdR+J
wZxHg8V3LCC7eYK1yfJA0dyrKQHbFtGKvIaNhvpjUmuiPQuFd8YHQUXsdJYWH3HUsMToqA9KFdIY
D+KXiXpuU2oT5ByThUDQ7iJLSjXrJfJVVNYytXHuVcoRrzHGRUXguEp5Dfq4vWK7E8Pn+bIb0BPQ
3Bx0vZcjo9ks8pl5PccG/EUQdqJ2td1A10eWZasc3HLVkqWlPBFitlLN2OorBzWwYLpD1YupgjaW
CDhyJvcOmsD7GPO6/CJYR6Y7umm+JjwCvJLr+p2IVZU7MzSW6ieHuDXbSK8kKVRe+paBQG8eY1Jo
jzVSwhX3FBTXDm4lARF5UgeXRyuUanFvmJ+it+CUpujf4lyKswmi2K9zsxa68ZEsTRUbCmL4y4+j
bHu2PtXY7F2l1m6Q3YILveYlC1CZKK4+JcJSCHiF6eUae5cXldxkScPDfmEMVb8CEbFK2UQlwHCR
+loZEPXIyodZzxNAuNdlZMgSpFpc7vqc1bb0nahWn3ByW83KFnQPezHPbX1MWWxqUY5CZ27bOvhW
x1RqFYEco9QLS42SzHS7LCXUTyXspBwJ8x2V6S0Ji/MtoVq4pMK/pOHhWhlzqYHoOJ0pn8Zpkc/b
YcykMCmuLe5YuW79xArbvSJc6KKJd8rL1C74C3iMoOMfNRyO9rC76qNSQMKX8wAKMXBFwLF2f6hO
mH/MNQSUYn1E1yu6vkm0EgcDQG+46LH2R0GnDN4J8xzJImRZLs9VE5Sib6CFRULol8CnqHQaP6P8
i1kDKfJSsh1hsb0ZUCkIq1iKRJYjDwxHDOYfgXv1BphVU+o9CXLOPUJgIA+SHk13hhApmumwIJYC
noRuaXmccMSlFCkprwhsB59+IbSSjXc3FvMNyW3MEWtDUDeG9XB17oYsDfB6jYSoH4lqDDH72apU
d++YSNoicORHGgrESLAnq4ng2LDhcgX3a8r1MhE77qMoIFnfzNjCss5LjqrK1cYf5L6winxGs4x8
2sSaBEadOb+JdgHl9QcF0afGy1mpJ0Lh8IcnqPQXGuOCoGCWThOZXRnp5slaNSn2xLwwNq8plHTC
+Av/AGOVZIp53vmI1dbhx4ZZdeO74y5dEWSu/cTdXEPb1DoNeF5dQlL7XWjf4gaiKTo5lERYasu4
LFPTeD/I7apS381CV10L4W3+4PNG7gfmJMUpFKU8ynlKKboc/uH+lrV1TDMEFfI/6QaXcVxkRshc
DcFSzvJFxRBNHDeJStZXaw05zKyLC5qgjUHjnYjQ4qF33+ZbYpF83HiAIOZSPyzBHMtPGE8RCADT
u3GZLYX5t/uAPRzms446yGIvM6L5ierUl+4aCnLxm1CD0NG88eYK5Djy1GmIrxKWwvxgLzh/kAPQ
rv8A9cSFa5b35joeh/slUt16uafiUmsOPgP+y80MQWJWypstvEYjNhjSZs7eqA5P+xQ4IjtClhEi
aQl5OGj6clIkDwxzUWoZlB8zNRAjpjFigAgtSk7lOhTwJ/EuYMLFalf3BQBSwcJtSq1PVQYgCojf
i+bnDr3QfnMyb/Pl1CuQiCvdn8wOrOduE/uchLK1ht/qMJoGx+j1KHwEQvT/ACAFMPsPmFGJF5ao
9wEeGN8mERtWxbeciORSvZVFsGJVvOBn4jFxFBZfNwbV5G0eDlvqUCg+uc63eYwuvEtTivEsEICg
4eSIDeRQvH4jAOdhYB93PhGTfFUTqs9OoSA6fyRsbbePqV1vHBxEU1Z4byKwrGGUEKRldjU1JXRE
gI2N+v8AsDINlryXzDtIF8VkVXiF5HA9TDepeiV69rK019oM2SmF+qZFeJtqIlFiUV4o3PqAqtGr
auO5RqFLQzHxUQ8ENCFlncoC67CFQD7uIqK07hjwnQE8wFU0VlRaE/TLvwYZ052MUNXcAsUMos1c
S2JKURgPOw3bzbko3m2zoi7b4q4kwWcuqyEs6dSgq0vzDQNE098yxApg8yxSC4IY8rB1Fup8oKBQ
WGchSn3BGxKT4mUCatdQ0uAv7QXUx54albrKuLzavXfMrqeziI0fN6hlQu8RDOUMTI2ziXd+o+vN
eYokeQ4xnAT9O5hhXUAEFm3pYWiIFY6Y4U/ELBYuoTg3F+LiqLRr6lfOawXlmhYr39S5AAW+iOrV
HmP9CK/mBdCLH1HtrcU4lDgERL49x8Y7Jw8SrDLVmtS0tA7W/cNoALfuMHEIH3EOBiXcqDUrpzsT
gFRTtQZrQeIhWrXUQlZFUlU4koUPgdQqIa1895+4YuwXrVyvwK0RCglJftiEA1INymgH/vUM1z55
lUFQq9qUsZdX6iqlVi+DuGtIFCOuijn3EGLqj5up5XgS7CNhWP6HHNS/EbqlmDXbSbo7yst3t56/
M7fAGkOdll8lwaAtJ9S1qoAOIsAgAFLGm2iR26gHi7Q3uCm5lpoSmGQrtGMqKprqA9zRa5YvKZy1
cElr2e5j/St4ciEaFjs8x9BEu1KW1r2EAgL2IAUDQxRLprGym7ItbGQaW6RDEGk8bS4IBRLjRt4Z
zDCEOEDiUgLUx0ptyrIaMKLuqg/Z0X5Ja4AayOxRFWDxLqKxHgRmgoHEobUJWLCKX47lRinLK9GF
4J5nIrUMUcrhfA4uVNAwK2WaQOLj7h73Ta6bmXQ3bVn7ieLTeUDaiD2PEIjDB7RyqBU0X8MoiVox
zkoXzGeCUUCVRx8xGHS0TxDq3Nct/ZzCYEeGFnEL8cRVKCNJrQmSTBrwJnCaMfuLk36A+mocUvYd
pBG4DdPFRy5L6TeY9ANWt0WS8xl6z5gjboOQxijzxeVy0Sg+B3VxMVUL/b7mVI5fvkhRnged2N7l
gC1XPxAI9hOAnfEGFNg0+GW+XWqmdTaYViPJ9xGTwcQci6LcUUU2aSgDvURJpi/KG6Gayrnt839R
hUKV6FZ9wP4lQz2RCb2rezqAt8dL8o9sLoVqqPjItUeizOP4nDbgA2K6gdKrQPF38RLJavOL3cca
ypp3wR7alcd+fqAQAhpferlVgb7PlVQElmnAPMcCQngedh6XRuzfjYGKtDfi4O7+lW9sIOrV/WoO
BZ0LdtzFKgdvsGA9901YPGMtXrLIo/mEpvohDdXg6FVUX2k4Ss98QWFEUCVjJmnVG39T3UF5SyiV
5ss9bMVtxui7yXPWWnKa2tl+OheQ9MMKGwvL9RnQ1U2nzcQEWcnI+TYhAoWyn+pHh4ioNqU9BbKI
9wuCTg6deiI16Avpl/S2Nm64b6gPdQKCV1HyExyK5fmIk16DlH6g0zqAb0PJGaAAr+JXCYqXXrjY
qKGjKHzdrKs1Xgt8Qyl1wVf/AMmwo32htZE9N1U6SvE20IN3y9vBGYQRX0rJTaHVXzEqcbdv35QP
LjrVc5wgCxcEj+IytKsLVY+o9zgEQx/qLm4Vfg+cgpXdA9OIic3wnA8wKt3KY4mpTfqJVd+GGvOz
FF7c4q58pdSqcD3ORKD1BoNnJfUASF2gvC3moWBvnYyKw5qG+BfPxCmWpfuJXlKS1IFP6gkAJnLf
EP8AMFeDhpKYCvMTZUoSmR2ptRVX1BzXRZZmBq2XLKQtLN/Mycbrj7h+woORHmZFZxbVPCFkMPqP
g3FBRRppzGoWtgMzV2OKuIgBKLb9SsXsWlPhgIvKZvS/Era/EtovMpK5mmw4h9pWek+orCr3ytW+
ARQGrvZO44KvHuoY2NVvcOPIIatTwBDh2izYSwKcEDghcDh8QWyFeX6gB5kFCWLwPJDdBooOYutd
2pSDCT3KbUW6hRerl4V9rYJALKuj6QMNquioizg6IgO1lNIfMI3j3R/uNPTq6+YsYGy1bCalUpdE
3KA1X+SMl33YZ3wW4/McDjzQfiNCAo5ww3aGx2PiGoyo10lqO8t2BHjr9qIbVFHGAtri8JeFiRvt
qoolvOLe34m7o2Hj3CBRxDpNhCVfU50DArRGh3FpDOchZu90Ue49NfEefUFOPZKTTlK4/iHHraSz
oSoM1naUDqfEAhVdi4Y1vA6M5t4epxz0p4WPdqUouv1DeqaKM+CaRACvNJbvPCK/1FbCN4T0Vz7i
lQ1wJQjQDYvNLSBAiNFVUyonJ9g1GDqQ6uM1uwKIGR5XaP5gsD4o3+qiwQHFKfLCQvOl+EIsgAIu
n+woFjkJ4UDCLJJoCLVFeEd57idNy5uvM3CGnuF1j5FgnjIBIr1W3BNSXwrn1cFfRykzAkYFx+Yj
ustlwGm/ItuCG2VVw+mJFqXVNfCc+raIKzKG2n1EYDnkT5uNHNnNWPuYY5XIfqVB1ZwPuIzo0jqR
CHO2D4JR1tbgqD7pi+EvzBgWkTm0s2hxexBorYZCOQVqwqOVBRRCAy+1r57lJC01uUAWeIEOUkyi
g5US4Ll2fiHaEryETj3rtKiNM/JEjg5BZeKuRaBHZuxtI9KVw3PUreVQhn1FF1vF3AfAG6iiAriV
9oX5UXsvzs2yqS4tlyGTml/PmMlw55bfmMSK6dfEFioyrlQClnIX6iogbwUxqgOziRFc7LW/mIoW
oviP1TcKcmLCpE0RCi8sHatnLTBfgvBlOhLKK/cfoegN/EuVpiE+KiREC1bT9sIodeaicUcS37lV
T4P8iMADlVfmoNPeJHfLEaZdzGxl6i5KgndO5xZhdUCZ9m8B8+Zz2GwJpeDr7gXI4Zrxk8DeHmVK
YwyKs6fUNUucEEBONaITpT235g+BOwYjGJ0Yro9eIZNRJo0RUFVBVh9Sv1KWXzbWYSkShyNCJOgA
Ubinoq8iXVakHJjxflqLhFfbXzDlaZHHe5xIyJd/MZgiXTA+fMcN1oEHoPmFXOu2V91BTlRwjXF4
0HzL6YtXYPuA3J1VsLA5zwhsBUtjLxl/uKbav11Ba4cVBeVXAG7l11WhleZU0VYVr18/UFhuaDA6
ginnQ3qooEZOV2CVbuGdOgqwx63Z8Rr7Vc/cGoEvVMKA5u/JEw5/eFyCi3jUIVxO2rChgclFUxUT
H6nPpQNB2xKi8Lq0QKywAoqVXFO0YoShsLfuK5aAFpcETf8AF/ZHT5+a/MKy89oihgLl8I22co+O
bl7FvAoecjLHTqbiK8MJrh6jSuGIVYUtYxSAY6C99R0DXsmeIAqEv+YsN/YlYtjL7nWHgO4nBqcR
/S72jEFC3ifZf4lPisQEIYCwkMBvseYMRyAcRDJXB6LyLiwVwEICHjtMZF9IQi2pJ1F9dCKrIttH
AlMkx8uomYd9ErIBVY1y4Pc9uCdMVgm5cyG3BuMtMDKSLoyNFzIl8MZtK44lrTBuELbSdhjcu4ux
bQFMoaaeoi95vghQ0AqFJLZKHVVTCweeTqWtE9mKLFCpVRvgVcYSj7IIWQA57JiAF4awbl6V03uA
ASaBsDmeVcyrS3muS4zIXA0hfNSNgy2mhIRB6nMYxYyLdDbstJbPB54mAgQfygwqA23jxw3KuvOZ
RZK7COC8RFw67mvYlosjg1F2gNpIz0EoVkbiiVVZK+WZhUQKiVvKNEg5QiMA0A2NmQOg6joNwK4j
wK14SzygCuYVNK5J7sMycOga6lJQ2o0+4pBNVcZwNjpFSANdKlbDAtZA1ZmEIVzkDiHNA2jY0DCv
Ea+De1HOHUIaCxgimsVKbNxXmVpdHGw3T+ScRrY6nFjL5JRgDonNtRTjmZgk8RwGsssuoaWFZQ4i
fbOAMIF0OdEazWniFqkb49weEghqeuqj4N2dSmEdNhrDanKcYxg7+yIYvGiEKAmLa5+IKi5twk4I
pFCAc93iWwHxF2XAAXGO8KMVyYi8zAPa5lbAnlCZSX0RaDgwlVzs5ZA2TI6TpWdMjFtaju+4UslF
V/Ee8ml8TLYA18NnBxNKS3Daa7RYzQocx/t0awTmqoQ4jgUcHs8yhxIFuvUb0ej4VQ1aoOcJGkPJ
s4P/AJKU0CgbHHCZXlGZIb6QBcZ5qHNXfUQoxXzAS870nMiQPdTP6ODPmWwoUU6YAiBuQErN5SsF
ngosCPoKcQoARAfucoaWKslHqbbL7l7QNCfUoaNCHLGzgKD1sLM/DF1FfVicr3NeJVxr8wTA3QWF
f7CDArTNhraj3M1fO5Z6lh5ZaqOxL1sJhkA8cx8JgG/myopVZ35Q6jB8jAfGNK1lIQC1BM1guPCM
uTQ1S37hNZrWZ4/cPCZRwLsjOqmoi9ukDgLFDA5hnUFqUvmIgQCorrJSgOoKPmWOgJ6f5AHk1Su7
gDDnYKu2VomLRfqIfocOW5Y2XLV8HxAUy2xWmXkC7bsHWw8gl2DnqapA2x09RqnGVZ42VrWksO2Y
TWOF+OYfCJpyF/5FcHBVXsLC3mWXekKloKH7g0WGai8RVyc4yJCxT6nuWoDRtnuV+YlVKoJtRDaa
/wCwq1i54f8AIM1YzCC80pop3DZAW3nbHxaJstTBMwxVUDiNFGfPmVmpiW/dT6gsoMyJ+iKXWP8A
M2LpKK/fUV/roFL6KbgoQE1iAcMHZU8DGCBC7okTd4vH1LYE77KHNSBYPKQeHAshDg9S2uNF4P1s
oDWJ4HX6luk1wX+Yur4Bx4mEoSLDtgpiFCC3wRC8dCnniWQnM7XYfdSzBLwX4rtjJtONFX5mARmo
PMuT0qop1EApsLDaqGUPw0TE45loakVZR6jk3lDg6/U9uXCOd9xHFCoCq5/MWqCfcHH5l6StNIKI
ZJ5oDZ6gLg3HChS/qIj6qUJjK2ePqL3WGBFUi0FV+YMUOa1sq7Pv8QdiDMYXfvmHoCydFsG/Mtpc
Q1oCAp5eo36WsFTjcuq0fcqUzqrme5QKVvLEqpW58Q8VWaSUQeG3NHgdpECqnqUEUty0Qf8AmVwb
cxxCtFNl6qUTHVaG0NwdKKaluBTk8iAIRcSNoW5epnFwPFSkVCiHAGNlbmCqqL4iOPuX1qqB3koo
Dq3K5ji8h4cP9nJVq8w0AKYs3VORBV35mwOJVMTNjsvWM4G4ihPcAhRqzAn7gfLEcWVB9sLSqBzc
9UDwlEDexw/+uPyEZXCGpOFBUJGu3/YDsBZK9ynVrgjN51XmCAuNWkXLOeOZRwJa2prkYe7i1LZS
OoURr2jqOECuAigCLCBmTlxHwaYjLSzU0g1NHFVDXCgPcwsJzUUiaWE47FsaXRMyV2luKnU3TJUi
0xPErwTqrhtEGFQxxoFQkhXCyF1HPtLxLbVcRkFXwI0C6EOMQeI7ENuUO6izOGWGlC+Ja9R5Nght
V9pgAOkLLZRkpP06JXrXLUPZANsjpW0IdAWeEprOrhEoDqiUaBvBpaKxVa4eGaXVX6SqjQHwqArg
hdQCN+spqotuRNTRrApGyhItNy+UggghdVFQCMVxGosAeJfmgNA2DZA6yxHrL6JeVa3TmeoApJRu
BdVMh2bc5gYJ41E/XAbOWgt4TMv2Rku5Y+5oQgdIJByVWQ9cZwg8YqclBRvEtmEOOWH1hOdQLQDz
xCzoMDzHOIxTA4I7ajytc3N3Mjd1MsCP5hjT3K8wGVsAeYb4tCnr/sGBPQS1pBWYAQCBL5uJ/sqW
HCpUZ/NB5GhbauoUkB+TzFlGjQXZktYqziAIMKV5q4AzEE8pKBClvWMYAt7EXw2AecuOHNry/cYU
WPcTC+p7hMxuX5uZOtD6VL26UrCGaWjlnwgjBeAOwhh1Wgc4hiUTyRfbCarIG/8AsiPxufXNzOjr
t3TmvmJzAFZwt3UY5Kot8JBrFOP1KxVbHlIe5XRduPiEtSU880SqgXNHmClald3cpd1hApXcZkmH
SXp+4RmHduwnbF2UwvJXB0jZpnUoE0WJee4hUx46Yf4WFuNh8xeX3my4wPHuXPAMB8mArQF2ZsKy
BaAtIkGFaaPk7hikLwhe4IdSptsrj8Q9bVrXvA+4gbTha0PuVLLSXm8nFcQPmX5Jq8cIgWvwD8Qv
xg1pR4M5mY53vZXm4DLgh9Bn9RGGYF3s69rHHxDwjVAH+zXCFZl7h7tNp5plvkylBXxdR7WFb8LH
q2k4q5a0dE0UIMek12XGGlBTqoMZehq2saISQsuu35qGgMUNWFC454Dg1gNxxeyt0z4hNQlO45U6
glAKkOKKl80XzyWJ8wQCiJfKiHtAsMsDIdYhccaWfqJZHRNZ2sNWDWeH/wBUGlMVVb4JnmRq85v9
Q1AUlIvNOiV3uNJvxsY2IgfAEokOORvF+mW9ULB9PxEAqm9ivfUbJuoHPXufZyOeMiXnUPfuF4Lk
F+D+ohFNUSlL/uKPIun5cQIG/Wu3YhsXeayrCVRGgFr4goBcLunIlhe3pwzyac/5uoLVytH0cStK
WMPgBOKw8pY4IIxlB4vuoCY1BX0qEsTBAL6H6jACW5w+ZsmblgeYquwHLXXMa+eApPXvid5twDid
zha9f/MYLzQr8wNaMVMOo4thWF139LKOqnA+CFSW7zk8+ruA8K1XeAhdSI/azhb6llCGbFDZmxSq
piFBWyxHg8TReWPNfPmV7IWA7RopwnXcZ002Rqjp4agqhZO75j3Cj2T1O8w2hv8A+xAVlPbIm8ob
GETw7eGwEdMplcZHYFAtrvJewLY8bCqNlnxFKgPNmzPA/CXIl1Ttbm4x1XM91NBZMB+0HJAEiWUA
il80ZwjgditByQuBsGaYy+YFbzCyzYAPknaj8zCp+IzUavzHByrxDUp6gpdQirltfcqih6uVUvJC
lh8QKtv+pAVEEasLZxhBqeZe0L3K9wsK5DDS7IuxeEuYtcJaUEb8bKGLAV8y8QqpYpYDzK92Aae4
SDYQqqIyh3RZ1zLJOKYG6JqxSvoqepTehKOgIdEtfsfmfYAh7BKUKogJVxj1Vl5KPwrYkqhZDGaH
BL0AGAWNID8XKrzAsO5dSkXM8gjPuGTki+yiLQ0oI64wEHIBksR1YfN9QKGqErcrOYhjzlzA9/UK
ysuYennAFoVRBYxp/EekacV9w8SvEKvkn1DuGuX4i6WWJXixG/cAAahpQU36h4Rqu4AqQR4wBjAr
+5gq4H8SgMDBc1FPzK4Ls2HHDUVu0lFjcHpXzO05hiVHdSXQOm5ZdVKDeyXQwzYAgYH6mG5XuJLB
az5lAFAuFGhsr9HtBbWgAn3A3icRj0xYBOQJb2eYDfhQwZluv1cXhqB+Jwf7Hxigl83eRCxhX+St
vk8TKoKrhYjgE+SLcAILFMV6qor42d3il/mJhGsqouVLIOzgliGgB+JSS3A+pQw8d82EB+F3PFZG
rbiHuKAq34/qMpZrxAdAEB7iAGDHEHyxB7/+ETrase17F4KEPjJcnc3oLnXCPEv/ALBUDFC9UAji
D1cNEsVHR/2paGq18Xx9TnMEHeQEMVnRUQmcE7pi0laviriUO8JV8xeQqJ5KuIFezZx5IVUYq6x8
/MYHaJHPhD4GlHDhHLLwAt/8mdoF5dwMhXFVK8wu6kT+4NU+Fs/UR1EgPV3/AGzeybV4KiAlJRZc
YnoD9kcs0T9w6AAWeonmgXJ5l4aDiza/2U8hyN7i3KRz0cErzKlIp99wbIIBbKVPOMj3CgmTwdrT
uAcpkhUe7gOW4vmrR0SL2sugRni6muV2yzQIr1HYsa9uys9FF/MNJc6UUINLAHvlmSVQ43qo73a1
fxf9xSb24pHar8QWrML7pixUt78Si95ERogkUWDmrjv5cnWkMjpPi1S/qCFsCvpiSVpqXsh+Pic2
Ff4qVx0yeAPEG1WFqu8c+JzfX9hig16Hn0xTW7Kpq+JcZXNb5CBX4Jau8vuFJAB2v3BEKYWUX1FW
VdpS2fxK9waF1pf6jTFGlQZwNAF2HAcxraNsIFxe4ZKAVVHf/JeMRcH3AZL7xD2lue163XRDBAAL
7voKjdo6+cU4rrYo5r9wuFFcK2ruI/2MVhdkoDcvuYHGN6BWV/2Ms61FgI29kePGSoINRzQf9gdl
NgKKsPqErBbNeVHY+cibutVVeWUxIUhPmbZAgLVbN8TGN9KdNTSiAqqtlxaR0VLqF/0d1xSvzK3/
AIBqBp749vMZGWp+6I7lorPF4WxdvLzh/sbdXUHWUKgb+I3vhKctoyyo8A36JgafkeUIQRB9O1xn
bFba54uC2yvcZa4QUDhqbOl4nYc9xVXZscrj7Y5v5mDR7xqEq9TzBrkF0cQLRdfENW73iYHww3Dq
tpgwpuon+lxIwiiVPv8A5HKJxNgAsGVAfbVj0XNqtcr4jdLtr1EfRVPuPa2Z5jOqbL52EsQBEIt5
k9sVetBfgR2AaKeyYxoFAgpq0Img8QsdxqCIiwu28TFuS5S8nI0viFrvGNs5SiYCIXguCEO4PGS6
lShUrtJh9QQRThioq2dRcUsA8xsjnzDbgqbLAbDVagNjFYzZanUlFqpCHcG14iKSB1Ctbrr8rHSK
c+IqA2dMBNBVvpiipQHPUSCWoa1bEsbQIcR2X5mzI0VGAwfmDbPk4JSO2dRjFcDGRAOrlkRpc0MA
1cOyU23MaR1NtBYHiaJb3YDqE8MIHlWMsAgbpgSDYkULnIC2mfErNHJuUUrxzCGqXkMhB2uH9UnM
t1vjkoBYOWXUDfFxKgkrJdEFIgunKO+pShTmRrGkSgNSxiNEgICC2LItDDNw9zDHbzkt1wPcxLvA
y8wo4IZlWDZV7dMlHaTqGXnW7gYYl0/EBKOPuXNXnGFl8pejF0t8S5JTKnDgsi87HwNUEp5Xolq3
V8vewSONuJRLOIsaLaeYHKzgwtIWqviWg4VEdWruWyx36lfdiYHMXlB6YMJGDbF41rZYE6n3KnTY
RZWvUdnYK+rglRzRjJMBKVUKEnGsb3rj/JQgioe4Hrj/AFFpsEPRdwc9Sh68Qn7FKcWM7pVrGqnT
vriFispXhiMZvX1Kih2X4iwGBX6in5Ihbd+I5Gpw5lM8APxKbadfOMytS+BsyUXMwL2pyC6tQ2wF
vyf8hMcJxv5nIbVt62WDbt+X/ItHrPa6j9eJlQmKKGHd/wDYjAojXKdI2Tv5kqGqaW9HxZFoVXar
4TfaKThf/ss7VtMfaFkW2q48y9KAYTd/5HEpMAvm2WJkQXbx6JjWULh5uXJjIPtUN8B5qpFfIuZd
/wDYIBQqbTVTPW69LvuJlZBVacInIA26vmIwL1ygIpLQY0cVCzThqzLr+o3d4WtAh0idIPEuZ1ZF
B03GDu1eeYbgvy5A/wCx2aEqZFOfiJKyHNj1K1ui5V8wLPQ20fEQAyo43q4XHUjxy/3KIC0X4uFf
o1PKgYFKRXQrzcJVeHG+2GBKa7NKJumu2q1a/mIs0IIVByKQDNWUsANnN6SlQKjfDABaL9QXJ4Vx
T/ssRkuHDuzXLADZSUJwZdP+xErBD6Y66Xod3sFpYWWaHZsaoiuiscME0Vdv+xIYqfE1VoDjEA1I
CwBxHGK6KAGcbo4+uYlSLQq9cMypsHte42u2mRWstCWdVLAV8Tg6qUxquBfZELhS1WjvmXMVZh+V
Y0uRrlDGZGur4jWkIWOVnHzM8AelqUbviDznmJnTyDq/PEuvydM1nzsbVbZ+VWfqX28LGFPpNVtc
1GI3OTR7QXYVSqLv2QaEC25Xi2o5PkQapkJYIgAvQyGiYcODh7j7yLd1bDEryw0vEvOVatGMROr0
Kh7hVYqFqP8AcrLxUWNT+YUr1FSgcfUSiCElq9+JbX1o2tEFm5hCtvGUPURpE8vqXGQhA3UF+M5h
DMDN1d3HahWQlY04biklqWwXPFgIcfcWnvZQOC4gBZLjnIeRkXiB4uWmG9y7Jv3XqIsWTjBt7gOL
4DWFMFyUekSLSsNw+QlhoBzYpnVSzvgiZQWkMpjIVlN+2XRQ5cQqWpQoDiUu2tqJTb5mvz8kaBzj
Qh1KxwkOkIcC9SzCju0R8hXfEBvY3dfiUeyIYXOoqOBLaPebfLEAqFnMKjRL1JWTm9Es8MMy5LZ1
AlgfcH0OoA/RLEeCAlmhjwj4KmSAKS5iFmckR0ZV4kS7LyPpEMVnVVERVQA4YkJoqlMy4a2IuM6o
e6KEVBPR1FSnp1HdNYUJlB8sUOKFtikYDkY/MqUOJcBuWBTsJvkPVQtrbE4lLZW3RL5CrbdlpjWI
8/ETLcxfJxEKcFj3OBt09wQCWkvk7uF7Nt8IeAhvSKXXZwltpGVV+yUlguGHk42aP8jkWmO2wOxS
YrScRcGqrM1zEiWwOEqF6ujUFCauuLgBEBAXYcKuY02H7G7DOJyl6ZelC6HiWQKJQ7BVtHnyliyG
XrEIZWUJd3WlxEoAbPcoVR05jO7MoMyQKrsTxo1UoaPidWYa6h0zO+JmAIahOBeqHq47G2wRdiaC
jGWXz2ShPdWXVSiMC7rdRIfNUeIlkIUpV/EvbqtsRU5Xhe4/XVWut8sR5oNKslXGnUZKHgLS567Q
0KiNTCiDsSNXgjx7lY7KND7g9DkE3/MrbQ3TfEdKBs8hgFbLaLcvGNgLI7C2DrZbaJ7J9y64JmA/
EP6xA87KZJARVUsU9ANxNL1HBiMSFWYylk2lAn1EbyhEMq3KWNL0epQqlpXUthBl4RcmqI0y+fqM
w8nY9sVEvlbTDlkIJTvcHnSFmz3Gyiauw62hs5LnqekLQHGUHXLCWlbq21WH6ls4HclvEzARUzUi
XFv1GgIw8k63AqjeHTGWox2A9IcSo4EBS40e6g4IMt34h+VZVFr+ZdgSDRZHRrzDYFtp+Y6RiFAh
BsEYEqM7EqHC3n7lk3mrhsANOjRf3DPJpCQ/MAaLYftC+wgrooPeMMCUllp9kvy5pdviiYujkH7l
w0jaDkWylUhuviVBXRtAeJYUeUAPuABHC0WuGuo5YhbYnh6imKBB5WygypYAwgRVSNlBWfqM5bAV
BhZAsQW/MNsUAK16+InuOHA289y4lXRz7K3ADNhdbzL0lCq1fcTEA2sJYp+TmObqr8v5h3lSzWw8
RnCWsOF6+IMJfLpYKWQ4MiP0bhFjfiASZOufF3t+YbuhBm/cVzBcX0w3iUcWpzXucUUSfO3OlbCp
+EjxSqH34m+1FjgZLVWO67OILsPJ+IyhimrMLf8AzCawa6jU0paUpfD6hDcdoKKvSMAF5ppldOI6
rLa8M5S0wEvG9QiEtEofqXxHLvnuJFjlc9A9y2f0vyMnEDA3DxlEfqBYXU4uBU8o1TneTnUJ0F3U
VOuwdXzDuArmn4iVclWH9IAOwJ8DgfU51HpQfEs/L6q+biS5TyZR8DMPuPt/qahRFHj8xWgiaIJ6
YsdO/R4ltY0204lI9DgcZ3AmnKrV+rZUCaIHyVUcpDnBT8xkpBVaVjwKylX3EpbYgMhi43h7KyWW
oPxF0pbEshAWuK39xTmyKi5ekt/6g6h298Kv5jDPCrmx2CtEI3fffSTs9/VD1GNYrFKq5QJAw7o4
gPa07D8kYhGi88jxLDU4LmMI7aW0oALrSnFX4mcfC6GGJkeAcGeIBVw2IHBsQ123GwR4uKRDiVDU
vyEMsityyHJ/iXw4JnqWFB6VKEDOJWNvPBLYHPTCxuvJcHwK4WHSABofcFbb22oYVc3WVrgAWtOo
KGBQcP8AkrQe7ULglq8diKflgqU8flt5DIg0qNfmLFwYpFlzuHsKl5HShFD8zUnYB5i6gCqDUXLd
YrlzmcaBgai3dWXpl6jpEuvEEJWnEECLwCWZh7pLQ1vAOYKKj7gKte4YF/1GRZ9zHCiXL266hdj7
lo2jfMHAOPgqXCrwMpC93EgOdHFl3K80qy2KXm3Msm5CPHuVxxU+UvgtzuRLh4tnRTzWEZa6pQS4
9BDXOnxFAj94eGpaDi4lWngdIgZffPMDCFU85AVau7LKIptpXU4Wpw6sC3tw1RANmARh7tcpzL2W
EQXb83HGXqG1tzclEReFlFI4LyCUwdU3MsDzDoJeopuPAqqh4VyYUxHVmNZ7eD4n0CWLDl3vthhI
6Uiakr/4ISld57lJK2Iiabqq9HzsB3tzbA0qnsYMADOUTWh5o5l2RWKlA3mJ6f0xRe07PGtfEEsx
ajUuXxGrflVMGIDflEzeZUMlqr5uHC3W1U0oikuyClc9up0gdOYIDU+yVmn25it0jtPMqB3Atyzv
fZ+4dDXnYmZ9F0mvRyXBAht8sdPZEUQgnCoPioWUVmy5fyFVB0aagXQQxWdK8xwHSKXhv1gtb5W3
LGf7CvTsKgiKeYtzbe1jlpcKEo5Xpla6zGK14v8AMuIJ0JUzq1zbB8BUEoVwKVApYvl8QSdPykAH
oRkVHyaxKm1rgjhW0cR0ggQrFwmiltFXK6zDkiKdWnpUKk6dLn3GowpynMbSlRLUfiJbjtrNb6N2
Htc6lER2Onbq5UA7HbRmnvFrr4jQ5A+YBKPLsl++l7xat17jLoNedh1CvFOHxA2M15eYi35B1FiH
8OfzKghfZ2DVsng6hEBsPPmPM1ejsdbhXU5i7lnNkqABXxKLB1XFwlFombLmfwpyha8nUstVHiK1
j2RCbIZfUGbMvsnMDbzszxttJcrdBrmsgtEnLXHjuNTj8MZu08Mbr+r4qBQovCdQfUXzcxpqdsLN
7OwIVAh8wxSqPFxemr3GI6kSAZ8wm2F8kBsA/CWBtfNMpuniKO8ANuPMMMazYFRD0mM1rqcL4a4l
cxKcvJCnG05uM9v1kpHUQbV9QoF1fbsQNrxGwW2EJyOYV77nLC3vYIx2ACXvcsHTNw/MQ447i759
xxXZGUELEFNt7l7FtYqyhPDle4EAxi+h1KTusad71E9al6jZcOcPzCkVx0ywxqL1pdSPEosv/Ywm
PSUnP4lA/umBfbMUd7iMnZfyxhZAqqxHl9ywWr5mxLNrM52IDdEUq2ooStwVXxFOt+EvoY9RN34n
oMdW3rlRuhweYTQRiGvB1GRIC+EsOyvUUbyxbWN+WMAm3IHS7PiISVXxLxE13CnGhYTyhIeqINQj
I8hApd78viCQwDIYXQY6gQEBtSrahQRS1Q8816Qf4VKDiUIyYCMzqMqLl1aE4uPQUPHqYtODysAc
PaudIltYxa5+Z3A8RXYGtp7INENPO9qcIYao5lpHKG+ka2DCjYw72rmaRP1L6vnSBXj0VLwu+pUq
gjIop2x1aNd3CKdeYanJxFa6FqEaJ3bSYVFatSrHHiXZ0O4aEuxOJbKgFeDYolVFA8R1BRqiEdqk
8Tn7h4QogLIOZTF9kOqhQsX3FabJU535RIAVghk1xNLKoWU+I4EohYEnfUaKz6gNlUNNjjIfE+DY
ytCeYeHehZKqvIamoXquI5SVumWRSxRRyxQdicqn2zaOl83CWqpiGrwhbduy5HAROhcq4b5iBcRA
AwLszmXCFlrNolXHccB3Ai844lREUUe5SilI8kUzzBHJZ1N+Bjb+kTxV1EtbS/MElTBXWiIbGnjY
pXCKVe+mMQfiKhZwnkMeh5ivmrm88+IAW2JNRCg24wC6c3AV3dy1Dk52FlZc6S2XdmRZosmQ5uWL
l0S2t4ZcWqIgDjhgrF2MDJ9phAqiDED5R+BeI5WMe4wJDc0vd8x5SWSnCwuUbhyQWwqywMihoO/E
FCm72F15ZFWISqwL1GBQU1s8zIoM5hvuq6ZjrtliwEdrxF3gUxSxvp4itqF8Sm7hCSWsYaQsingK
iINPxKsxfM4p9RFjIPsDBsoC9loVZFaeYIphHE5SWlZXASk8iLYowHyY7wfcbQUTuX35EaXAQNNK
SxqiCgxqqrg1BCu6iFbqAjbKYo+WNS8Y+b3GyrfNxNRv0drAJkQav8RQuc+Ykpqp0XMsJvqNDuyK
vULgAcEaHl/MRAGPwKs2YNXiWYoYWeUlitB77mivmOkLhtVg1LhIVZObiOYg4i+31Hk3zF4m5gAQ
yOXzBTN5siGOIloNRsc9XMlpZHQDTArVOziUqNanjuJqcxGLIPJksLYcfHmcI4qNV1ZEQsWV7uBo
DDxKmjY9gEDnh14jYeSaMRI2RUdLjS2+Y3KNvYNK4YzXsh4MocaiCuvMEqS7IVIu+ouhzcuAtFnM
QK0pna+YGd+2Xi7OgtJbV5fEuC0Cg1Xkmjm4yvceC8eoguc//BQV9N+Ys51aQhRlnPiIpZ9iCVOq
UtFEq/XiCWgs5/5DWqqK5rGA3kB7VGcbavgXSxcjoHn3D6lh02PE8hKF5c5eYVDiLB6gzzZbxc59
JcorJXx1DgG9/EoELrzxFTigB0MIt4tcrqZuoFMh9iCpQj9y4Lu3mE3oXMfKGyE2zuCvaKO5UYoa
9eZfo34m5CvcBcQu51LvH4Zco8t5jHkLsinkF6gItX8RFqZLUhoT3DxxDUlqDXmhh4qmqcx0hvx1
cttVV7aIaLgVGUBbK8+Y9/ItysDHqpbyWoquJb1uxBdl0e+Je6lsLOHiG/kqbDjY+RgN/MwILfLA
gy3RMMnYHyhZTqE/TuUpUIeoNPgD8XK/XjqO6ZXCFWJRxOYBtOoDwVcQUI9HMVFW8VxBAUISrUqK
gwO5BcKU156h4Gyr1CcEF4lCs2YP4qacLvmXRQjqVT6lqpKllglOQi3cor7I3BxlAeziLspgsoXX
MrHiGdTQpBtRcGBaqVWrtiHSzzBC3TODUfU4DPM5IF7LDUhap7l3KBW6A8zrXBzKYF1ATZ8QS3zG
54IZHh5i8S5QAlwprPlMvoiJZzfuIIDIO3Wy2nHiKl6uU8fYjFyBoRTGMq/cVDbYAdluCiW7fMc0
nEF2lPlniOXagDrBYqrQRoCEVDGXGoIHxFK2kwt3uxNcHuKAYGRKqY9y7fHzGwLfUFH5IK+S3JRD
uuYKy/FTABgDkt8S9viAK8zYVbNqYmS1+/cb2fmo7K48Ma6fEq1p3mVTDt7LhZsrZyo3z3iaE2Wy
DJqh1ChSLwot+Z6hUAKfMS5WHmWPDGQjVeR0Mr3G1eybhE01b7gA3ucGk2Xl18xFoUtcQI6VFawE
BVy73FxivCBTpguD7m7Wj1AsnB5liR09TDQyCDzzGhyJVoolm21KUwL7nCjLImhKBg2rllFLniob
EllGoBdlMABw3FOdWV0ZFDw+o82XbkZFQYAoX4RO0uUa05GKwiRPMba58k3dl+4LhY3reS4sNO4q
KcYJa9iMLSanCpoWWRF0RXWRgaMqZbrzcNp+oAoEQXiQLxxEEwZwnzcdOdjpVEsSuHzHnYeJcLxl
VriHK66il7uwdRiKFV4Yi+bAcaTJOfzGk4RSUZAaJRLljHtVc4si80LsKwiW1owgqsuUClLcsbxF
XV01UQ2rYOTLZVdTO5fpgkClOzvYYor5RvPFeZVUqDPhrnqbkKaEJUFHFSr2BjEthuldWsQN/Nie
HAfPcGp+wv3Bt9RbORS7qo2YpKHXM14zzxFCipuupaWti/uUZKW31DSBXUQjV8tioaVWjliYTmut
S/oK3KOyqoQW3dwQiuHZH0pTTtMGTwX5mxNhQIDb4uXVAKahNQPGkwJ2NJCgKXB8wGWUDPmO6iSs
wVbfiU0OR9sW3AQTaTZ8JF5LPCuoTBBy8xvfQB9zjKc04leJVVpA3rTiH8BQVLMYW+r/AOQiryNS
tAA7zmAIhVNHyiIaN/EsTsL5IWx+I5UfEF2hsfErBUljxfcObNIzPweWNiLG6ziCUdvGABPcu4l3
jxKwAFdR1c9KJSzFNqEiLHAToeGcytQgs2J0AwcVR4iMDYCJxd31sCCradPU5tHBkdrP7lxrUFFH
4hRQ7GEVuoNl3b1AqYo4icBkQKebjRLQuk4gFWRrBISYx7iZTdRaqKtN31Gpzcz1p5QAaq5WzyiC
OiacUnmUeddJKbxd83CuvGK3LxEsuz1ALemcT9SyGrmrYhdWVOcNy6B54thenbJZXy8sAasIJJhB
4UhEqoOmnepsBu/MToF8MyOD1LIPEpHLe5ezjqNV7qNsvmFRZsY65SIabLG74jS2VcqnMYPVXbAe
IURdKx8QqTdQ7jlLx8F1K9FUlVZx4YUdDfEvhwXiaBrUVLcYhKpjsn3NWhUGwZNR4WF2DlTgov3C
A9TlTt2ITOZcMFwthZRqX0dxDF0y1SjqyVR9QUG/MS4MeYdFD6nG6I4qxE+YjrZ5IHJx5iFzCCHA
m6UpQKYBgN9SjxSdwprkQQnHqcMxC1gPHzGNLR3cQ1JhCq7a+Jgoq+5l9epYJwSxcVzz7gHCyFou
oGSr8s4DEVJfj1LlFKJrgJbGV8zQGBGV3R5JYVpzuW2SmAXBPcLbEDyY5cHybPcQo8JMyqOnFVCV
cX5jYgFX5QVfXTG3VUUTQnCqoQtkoYKjxyMoE/M8VMqeKjUDmK4NRoKfbEpXnag2eozrnxG0Rg0H
j1KUGUtSyausQolK9wA5WQiYuirAiYW5U6X1N/rmAcMWtY6OaVDzlEBorgsWkVOh5yBouPMposTG
IEeVl/h6jikZLriCNuUyG8nPcHCPQUIjVRS2IZAeS/cQWmlbfEtQyUr4g77glxnmWLf/AIdCuzNl
xtT7l1N12iBWh7jE0pJYNaeUTwB6l9QOzN+2LvY/gJL8po7xTi2CEsd9ZKnPVmEkx5EvU0x3BWo0
yUUjqmKk5FuOv8lgp5LqWtLT6Bf+R1OOfXEOPygvYFA0FeXOhm0PJNML6v8AMV2z0xXgpzPxdn/9
kGgUsrxLC0Va5nJg4ty+/wBajV0X0QIeSnZau16u1c2er6YC6qoQ8cos5g+F+ZdUy+4JYlL9kMhq
A9y4dTE++IvHoaaVC7gBhEtG2UwkrHFvqETlqGJu1Yerf9hJNdr9QqDavb/2RuFWq3VXKUPNXxGF
UF8MhUVaZkdPUrNiSmtXi5iAWa9Tc6g52BRwMtSacvBKhJLrGFg1ICxjwKUSW+6lMyrsQLKRCNNX
DwC44V3K4aBVxCNzElsKvEB/Bxww0YA+hcVCGQleIGNhbO47QX6iC9UzhfiFqV9yi2AvUHaO29zU
+uolCnwZZTlEChnAe50VRUVvzFs5fGQvY78y4VzF3C2MC8ys31AFLnRGzTvmBfGRKcJVgPPmX8C7
EKOQwHXlgNnKzqDlQlA1ltlN4lw/uCFoo4qAiyti40xFEHgsbDMlWwa+JbXEdwOo4U2oq9/cJC98
QLoV1OTfoeJTRf6nJCsl0UcET02WKPcxxl9MKcSr2+iaEsqU6HDY1AtHcAFOQC1/JLhCWy1mioBK
bH9RH3fUbRBUDysdOT5luKhi66PuXG9+Iul/iU0U1XmfxVxItWy5QZtU0RaHbIDL8RarV3HSU08S
wJhBMoyEaawY9FxhhA0GPcuGiiFMO+oCXcNBuROXGFg3CrsxALBlgDa/qCoflGFZHjhiOu4N2u+W
XtDc0gY+oIV5ijVZCIFe4rHOS9K/EeEUErNM5gLKvwwtY8QaEH3CCAb8Re9H8QaXWHZzEtcHGzgd
R91+mP8ACWvp6uKhx+JYRw8wQa2R5v4RU2V1DZpkFbvnqAp5JjdhRUG6lvUGNJ+IlI4+4GMuAFtg
mx3rzOJX4lVDrLtLUWUydmBxdEAoDfM0rsiZR1Ozz1D4WxxTmL5/qdl7Esb1DfY6gQnEsJ4jVGPK
CvcW5enTMcoQS3oJoX3BLXzGhYRbLOPcatps4QceZ3wQBB9wrCQFaRkI0eILd4nmZxCl8oq2leoc
hkY4aPFyvLaxSi904IcC+JQSMVgMdCv4jG3Z6gAIrUORq2oQbfMUkTWHzAnIqtP/AMKkug4CmM1d
X8wkoB1LCEf4RrWAOyUd8XzLUaTkiFnCs45D0JbTRKXt1GZx1dFxqioRJsHZCAORcQjVoU+72ABq
ovlEDCDskubLsDYtrKFPbOjaApfEJqOc+3+y1wCG8ynIAv8AGwoodWJXu4kW+c/qK2y3Moqvaci8
PZHmUBecuANvcsiLU3wlhk1cjeRSGi9dPqYr1zwmVxdVRFqjS3JcEUtXV8ylp8VeIs05BBVPDFdd
MtREHkYzgA51G8EPjNiZWDSDmHwXG9fiYSjumS/Oq9Bf7hD1qEOdwjTUUcgIZDldiUqBeY7hD2Pc
PAI5E/2KpHtyRqW3lwKQ31BGmTkjwDxBcGjlb9x+Imk4wqjV0aES1WjVpvSF7sqiypwV2wRHgWF/
EcHQK4tKQxhaETEolxFW23UMbExAYWLmQL9Qsyy8JHrQcAKfu4WM6hvYypbbvL1K8AKVyRulp4WJ
L7zsXRjHewQSip3kGNC7cQK45bmZYzgi0Zr1CO71HsLIrlHxOA8kcaG+paNh1AwoVtR7xJi5dQc5
NFDzUIvB4Zt1W+ZnYt8yyiQY5HqINo+pabz5iO5Qt1FVqrxKKClxEU8cTRo+pZD5RrtQ3Qq924qU
Umr9x6ZJwaz1BdbpnFF35ZaKGSsHMzE3wzjUBOg3iDLGocVWwt0tfZ1AkOHhjIKH3KkU4gW183Ku
rWkLttV4mFA/E6b91HjYBCZDal0JjC7dX6gC058xuiql3gkFU4ncFHQZegIhB3fBmDV9xLyPjZwh
SMQrnzcalqEXMT4kGJaVyGIGzLXKS0jXqdyYhpWEQn0iAsB4GXpKYXvWDbTYdHE8wacL7goAQ9xB
OXuUPqGic+IjRQgdFzbwRKr5Rku4JbRIvrZGq5XqIsBXhBZEE1WNaxvqIPZ4pgBcnFwTMEgjWXDY
8L4iLQ47mWSGrUWKW72IQCAHRxB0GvuCh8U4I9+MtJdw4iPgZsHEqLr5YwOx5ZablP2j+pjTOfmN
jS26yMEAD3CLxxHtY9QoKj4lIw5sJR6L1LEU84TCb+EVNY1mWMsVeR9jI2Ub3HR1CJ/kHl5nEDPM
BVmvxH3BDjTsRaHPklV2CqoK8wtXlCKjzC2SgB1xL2pUohpojFpzcx3X1ElbzDplyiVrBcJqLXEK
acy2tV8xbn8QxmlJVdGTTsYCc4QKsbDU4gBeS4ACqPEu2+CryXFVwUXUKzb+ZzGoVXR4ghl0xW50
6iApUL2JS3yQHCY9wLbeZZZ7qUGHPUql8FzFXEciUeZRNUSj19wBVcn2hWVu4gbFDi4bJp/iDtpH
VuCuWbjvhemMsKvsjte7qCx11MMs5SyHW8wuPnW2xLIDABq2MqFCiwUidmpa2SrVuVW5RxeQuQyh
XY5F2Iyht+blvGXIRhV7trEtRCwQ62glnHdfAqo9lPa+IktcXka8E7JZAPQkDg1O2LJudi3cBBui
GWffrlxN6Bpx8S768rFfYtp8YnJHiy9pTcWe2cyxCDLFfkWoqtYsrq90LjR5wWsQpQOJiFBxxKYg
QJglBEQofKyhXB2p1LARnzGxIsVSoCGS+XI1cbVqJ+IAQDbLFDg6pDgfBkMAukqkNaKLhXNvSjmE
hbOSmImU2hLQS5Vk9hBBi4Sh4rX8xVQOz/I/fgEXCNgL4gFTlplAcA2fqH9Zimj9SxZ2QvPRH9wd
FmfiIrUbmMu8zhS1KTyKtOZcAFxqbOUcxng/ERoyKgm6F4l2Ml9wINI8VDFUeHUucVcQssW0EOJO
QqOGHtL7uaBBq5XyipZrcyBGlqCovovyQ5vXXSMKsZeIzVTyjI4Nr2JBBh8QkhTUDU/HL4RDthUB
6iNa2xmMx9x0ccJHRyo4NlVF3EyVK8wRcx6S0lxy1DFUcbxMYI81xPNQecvuZivCVxNg+ZYUfmCi
2fATV8niHg1KCJuhwsd3xXmKbcooRVweeXk13wZqTvj0c2AAAKcSttFhS8PXmAvB5PEW7Lb2Iinv
YiKjazVS8VUUJd1xLRaPU5FZMDs2p7qHNS5VepeEHSnajYHNczlKOBGyGi0sWGBkKUpsGDowgILl
sXmV3UVJyJhb9kKhtcsA1cK5PzHVG7ICi8dxBpfaowfkJYmCRcIwG1imYn5FRVoVPECy1dV3LmHD
ULZgpVY/UpTkqiPXEFcCFhS7yErUFfHcI5o+cghKUxK4RnzX1MV/RsrTS+GHgU1zFGiyoKElZdeD
GB2oq4nm8uVlSlArVvVxOlyWKbKu1GDWHwPM6V5EWEt4wqimLxTP6XKnGKbF9RCCvQlw0gX7ZTfW
Z9ymy/M52HgDYw0IUGBVQt6vgl9OjiDsSjC2pH4+ooBR3cKoX1HF3RfDywUL0tVD1Il3A8m42iPy
X3ZXEHQedgdxSe17/bkv7gjG58TtjsPDxLC4+ol1Y+IrEB4fcUw4PFQnScdkBu+CCHJkAoAymxqd
S2naic8iImrl0UyUh5uUAV2MvCx4hbiuIAKqC8x3F1RRFsyotdWxJ/KAHRkOiKXBDBnNwSUDO4Bo
hLF3vMACvMtyFp36lAXC4WQ03HYdMDojqnZLE1ZFOAuA8bnyb/U6W1BcrD9whaD1UCGqgvW5akUH
3Be1wCkFCKL4i3jCBd85l0ksKZlNERsFFzh9S2FMTRshfenBEF8b5i8VD9wO4P3OYVE48TRyCs8Q
DSCIELCtrouW6wfRDRwilepYIhKur5gjihJVQNFFfFKCpm3A07uinMa6peCpt62K7Ly6B3F3ASBd
jIYKsXC77l209pWDaM10nAhfHiICKLeReGBrTvmUFDXzFW3r5Iqq1/ccn0EqL5YFew8x4Xdy7DmU
IdpyTMmlJ8wNRsVdw7zK/iEW68SgdNMl0qXQdQW5tpCtUv7XDdAQ1OPMrihizFkcVwsJNQr/AGgO
06OJgeDxD8Ni67jClRxVQyX6IaahnNe4/VQWORKFYLgJLnVDmcWDsAlaqcjZ16ksr6RYA8bsuI6D
iEqgaogeWrYgt02+RjyKfAwYEFCsY1gwq4EoqkStuohD2tI/aBa1BbAeI6B2ZBYcGqYxRZVtEUGe
sCilWWVDzhopkNIeAji00Sb8Q3EBv0gyLoo2cbIyc7GgoOElujpQbB7TZBIPUAHUp3YseJrRfjcv
IplJAMGrnmNCBDovYuDozqkxbJT9QoAGkUQ6QxYcTjtqgMYjfY6hdaApLv1DupCqhD4MeoR0CmkV
eI67HcoGfYQpKi6OpTwjnPEGAFtJtNYI5qH3k1XUVJYCjk8sz2qYHF+YGvVyy0CQcQpdZzsLi+hX
ZTxAF4JRqe4I0LW17ieltqIBXID8tjPaQpfEXyolV+J08348RukLYbsQ5MgSwV4pfmYInHwgFd+U
ioWDsu44VV9Q6yVhWSg6DoUfEKlq6ph6AatdPzGByKdPxMWpauojqCIiK8Nhq2rWpsJBV59RSQe1
dVkrHdBdZBmgQG7ARn4B3KJIheRex8vEHolTUO4FW3u8RNK8+JUmlVLVLSyDC7PcvwOhUTkC1Ovc
cYZysCoyNHSd7hCkVLKGV+IPW5bxhrkbWeYFlUs8KgU/q9B4ZZm1fYe4kVrjwHmUYksKaR8lOGsq
rgkLlrplBevOmmXvVEDJSYrhiQz4JZEa6HY6RQt6Ja/VHpfMJgLl5iuQmdWzVwKw4bLn1I1ddqPu
MVaionzcsm9o5F6kUgKgbEE6y5UEdtREHAjkAVix8e5ZSEEC8ZZoCixD9gGhz5l0p92+B+pdTDzN
SDVtZXcFJqArbgyuhbtkceAreeoUTOgqu4CyE6CRpXAoHwRepjUvLyFbAsNF7m2VyIEMT2wKqmFv
SMj4Jngrw+yGWBchW4+ilqjpUKFfBOgo/c+toKc2yhbKtrONmNBKKX3EoyGhdMdKYQuRR8RqanxF
AAfUbWkvzLiNWyq3XMdax9wxG3HVopIinOcShXLyQhyqAbubWNHiao6lXMq+IHmnjl4iCiGux6W8
4gW1xzABxLEumuPMxRW+ZcNmxEFyKxjUGz9oBZukorTkBPZDYqaOZYFRxKA31DFrsvAvPFREiURd
pruBLYzqYE5hZRoJfQbKt9zg6JT6dQMPBcbP0irJdOdXuXWyjyQVrXC5alAVx7iQK/wmsOxBXjQd
2WCC1gwUB9VCrfaD2XaPy5HAo1qDjIYWuhvyinC7QeOoKyqyGWUxKGdgfIgmr/BGBVMXMj6XcX0U
CRtNeNzajpRaU/mMurnfHcbVDR8p1cStFR+0jHoar5hMjuAqvtMNHFxAV4wDLlOoht+keUb8aY5Z
ce+KnWLY2PihfzC9wLDsuWGkI3kBsfmEToSBRFHNVUeAOKOxrfHo5L6gDgxcRasF8yh9oD8wOSTE
ZGxs5Aqu9sEdK388wDy1eENEK+iUxq0F+kEKgFqIaIUBfcINERT5ldRSatpVErzDggxJyf5PACLb
zCTjvBqQkAVa1GuDwUEsxCrNjSW8ghtWqql7Fh/kvwwJFKVSuYVpAqoCBTUEfQ8QNV0DABk44iZp
ydtgA9+2IgqF6XmMLYbZEoBqp7WbMrg4WSwyO2y3wgPU0LkAeIv3Kg6rlQLBPDABKm4kAqxTZ0sN
qCkKw2FURHL8whNUr6lpq4SGxCrOUTkExUY4zbqUXDh5lvWgXfUbyjSNzNqhaU76mGiUzoxCUL/U
JfykqS1gFD9w9ZVD9wTa9v8AqZ4i26YCmV4gXZeDYpAeoestoPAQv0mVmNZH4hUMUy+YbNXzEHFr
3OhB59y5EEDkYXVtFd5Hicb87K1BOjeIZoYgQuUpdjmVubj4+InaE7imHEBpPcJHZtDCB1h6RErH
QBgs7CDYXZlYu/cGgJYFdyoDJrn7m+0j9PEdmqjU5W8R4CQruc/AZBqDN7VWXEepUHwQsDYAAv3L
3mXopUUlLWiaf7HhxkwJbVsKT+CJBgoAury4l50MVRLgN0UOjCsapLFuL9QRTh2LKuQuPxKekoJ7
uYokAKJZnwowm1Ma1SryVJ1DJK3n6iF2SDOYfyUgjigsKgPCWxN8pQLCukaaLKijcYMB5YUxc5en
ABfr1GCxCjk53A9HaB3zcJgJ0wREjb6TGVs2qclQKtKF29kKWrNDXtg0UFGubcBUrcqFeNavTU1U
u6vMTkqgYeX52U1eAzmi/wCYL9qxF6jG0hy/SAHK7CEFIWAU7jZPCAB4gLeEG+X5ite6eLjTdsFH
ZWRQKUgu5xqtDQfmM6dASFjuZaHE0auA3DOnviLPSgYWS+2li/Bf9TIgCq02ZEChn+pqpi9l+/iW
2JUz6IYQwvEcsys3wPTB3UguVbPkw7gsm6oIeYuTTbx8zAEc7lb0K4jYXfEW+5YYNkDSL+SKwCpq
mlGmJQd9xwVxFNGiBloGlHMHs6gsywjZXDKGcl7BBO0BTgdRPy9xtOPcw1rqUV3SJChfuNMfzKqg
3Ku5Ev5gcIbWaPUo8E3XMaHGeIuilEZbSuqmIs5hZ6BBDvEalEI6dVLx1UBAA+2AiPM5NIEteRcx
37RXV3FOsgt4zlN5Y0Oq9S0B5uIOukqKxLv9f/ggro4xMz6XAilJ4mOwbzMk5+IkpQ4ZgSKvScrs
2nSw9tb+ovYyjcQ21IwNGwdemXExerONTBUoLbgkf9HLh6pwqX88B4lGGhW+oAklLOkQYRX9BnPt
W30I4iyK8ktFFoNfESh4aqHW7MhsJGni43eK8wbazsVBC5tqdQJdsdHj3D/IjSV13Eh6axW5iO/M
JZydv1FoGwYzhMfC41m4lOepbELFXVGAFoPZ5gO4JZPLLdPcOx8ulcl6q+Zgg6R2cXjg7ZxxBpwT
u/KpURsbeYnNov0hmyxSMboRvxcK64NOpXXPhgnssAeoy3e2lcwaMOlVACY7ACy4D4tAA4IgcH/M
pgaiFtPUoVh2+PmJlZmMSg+a48MQKh+HypHvqjgljgHEfqm41XZUMxoXZ9sHRKP6w+fOiCoLFdEU
fwnMI4YN+poslyNJT7I5NFlR3NjsYlpXYL7hrjpU89oESnco3XYipaDhBzqhYvpK+mw0NBTEq6Ec
SqVTg4XmEArU6xGa9QyWFmaZW8zhxW8kltOlFdQLpUUHzEKUrfUcTywwTDleO40NsQs3fcP1CQOo
Yu00+yLWqnXWS/pjvzLSlSo8EUCrWfUuJE6rnmGO1Fb7iihaI7wtdQAaG+CBLxchDVXXMfYquJ3f
MdWniGJydR21rdligUeLYbxsT54hcgcvLsK4bC46alu6iHOtwog1svmcnH3EJ0WwuDFk0jFVRLUC
rE0I4F21gAKX958Uqn2w/Bqn+IcnLyMdRlvMAaKbHiN3q9fsI4GBZ4Qi6/n3dywRVyc9QJIgL6xO
lOE/EUT2XCZTqKFBsIAyveniNYE2C8QFtOY9IcjTu4ukEK+hX9x7oLevLLFHD95Chtr7yUE20BfU
FReI/ipRJAnXkuWFRXv/AOzkcgucNwp4oT3eP6YyYlpPN8RE9E+kRTZafuVXWWPGMssaui63/UAL
cxppJeEzrkhS1A8rUOUUmMu5du1ovB4hkC33JvsqMeEh1XLNgyqnA7b+iJKBZDdgGzcmqVg8Q/QG
VxH51RpoYMPJAqvvA/qWRXhRzxAIbcwIgKs10/cMVOynpOOJANL5YwSw6XceIQUWVfOwNwAqqwcf
mFcKblKoZCxFhyxMKptWjwRi3VgN1GrQ3xFYysmQ0eOMboItaqojYGpVu4uFIkG2xsNEu2tYUYLG
wp/UpCKSQWRyqcK/dQgd4F2EWi0Oe7Wv2S7JSUVYMuIMwLYw/Upx1fMQniKdZUYZ9T0F+YA9tjVU
XBVt2up5cS9bScwaHAgVBbxcuA/MNeNJUb6VBCWCPNzoB5hXY2svhXM8ljUHPiBetYuBawMSiXxD
RKF9RSFZMsqiXDQYLC8QB0pHSL2KHjBdKJEqJkBwZE9LPEou/HEEgAXCn0zXLPEyUHw8TlBC9LLg
MXOlQWwZ3svfD7hSWVt/UohdXE1hnM4IAXey90fqOCwuKlouC1xLQYaeTkgsFCu6mCwyAolAvPMo
vXCCHIbcbcAau+Sc6dgiDljywMAMD5i0h0exZv6KLPenEQKWhnay/Ba9mwlxEBAhi0nxGYJOC+5W
Atyggiw/xLfWaHHYTrFyrhNZLHVuMSlDB8nzF+lpV8QLCrQS7LsYWWW5dUuqiofKIoLxLUTZbRB8
RWLfUstcIFjqLZekqHwuH9yiiGpDV54uAbNvMvYUfDeoN9jOiLYF8BHAIC+KdqNpopQZ5zGw1uQl
wU5+4ChK7+ghlyRxMjLrOTYDmli/iIIPw2MQ4qrh14NmChFlUGpH8hGLEjefU+BC6gkIJlZcb2G6
hKixWRiicFJiwtLuUe7iuJc1hlPEQaKLrB+ZXl4rcsrqM0XhLGpSfqUsiXcKPDWRYFPKmKTyYRHx
CI1Cl5G9kOepdMqHNe5g4QJUdAJZK9dFAwRH0vwOQSXfM6yZQv6pQ9RHgpGrjNAmquKwS9Sgw6PM
xLQI4KHhGHMCbRzGWnVWYB0m1EWGXwJc1UjVPVSpt8nlURdEMial+CN9qNA5MyLoSz5hMBXruoBN
FFjzCpyOhDY2s7gbHiUh2grwXBEWReOpcuAO8tShfQB6PMUoYzPHXaLuqiWAF0aXsY7mi/Jz+Z0v
MKxTXFl3DczVZwg1wuYe1XNdqlGexUGVHuhbT4irofA6+YLbBqhxLTA2t74mL1IoLMriLcFfCCwK
pR0Kg8V77He1A3MIWHeFJ/s3vGuSdsuRu/UrODV3cFqA4efcKELF9DzCOq28LiKgFnZH3h4gIK5Z
oQslt5A9ygtiqsSoZO3dymwbdGo73DSCqIYOhqz8ylDALhzkVpc8AfmMcgqit4/yAP2MBmxARzVf
MLbWjTQpc1UoWruBEvkjBoG+aTIDKIjw8wjaABeYZdGljdhE6yC9lVAL5HRVpi+pTQNXAlS4oDHe
6uUv5lgxg6fuIIBalX42OXug0fKuoJSIU5bhQNaJLs2dgZym/wCQC9rvxkrfhCTxF954ghCBZ1AN
9SqpiSZfnYds4rIopaDlLzklIpIehcUNQICo25qoK5iwtYJTjYFn4RqgXTdFsL74XtTCNPlJuW52
Fduq6aeu/UTa+oOhcPvQ+R7lBY7yRitb375qE0hwXXj4lsyPC+U8wgYYZnzFFL4ZezOxhsm5yzo1
IrXg9SnOuqyXXiHsqC5ESua5X/5EbhoWW5cEjYFc51PUtCMXVkNX1BEgi2rvaPiAxfEYC1/5CXV7
nm9iEhbAAe1+YjBQVIVzzFINCNI4Wx+c7uiVWdyhRaoJXg7li2rV0v8AaBS7YUMrYgjmALbM7/MJ
F9wMiyCpyqme/EFRcqjZUT22EBy+ZVlMpNzxLi3u5gpmS1v9RAUyFWzDtjJSkuF5TxHDtH5CNxQ2
U1/ZLU8QWLwiSlaRW2FR1t5I3XohRU5vklAp+I5aN/M4AYRhVaDuWspuODdiqrq7uWc5VS8xrXcB
SrqIl5BFc1xBEBoiG/MLsllb+ZQa59x4nK5saHnjIpTzcFO9lvaI8NPMtAS84a1OiDw3SWZKeGCC
mcshBpkV8/8ASX4S+Xc0Fu+o4BfKhCyylJgOmAjsRPPi5U0RNopwoci5zLX7fxAjQHtb+p4Quifq
WsHxA8gRuo1CDdlrgWT3zcYuqWgTdln5HEBoRSbPuO3UT05UNV7Kjw9QtXUB0eOo4oq2aG3iV2LH
hlinEHQ3F4Dq1N1dqFUdhwXDxHWjD3EGqhelRfrQG6yWCL5WNlwFtuHdjaf2wPMKJ5gxtWepiMCs
tQgrs1ADLVpwty3wo0ZAcmCBOIF5p6hmJAaKLHDnEpi37lTDbO/3LdOGiAUdlC2SUmufIkalbqSz
c7KfqA6Ay6L9TlGrX+c4kHL3jgLeeRl08Tjk40dLf0lh7Bav4hjC5cfEYvldmAgKKLHJv+ZQiri+
kXEBcvoOMeoXiiO1hzMlefFLbMooVjX9x4S3HKM2BqtfUC3ipzKGE7EfuFbq+CByl48iG2hTAEFI
fCpl9M7UNUV+4AEpwVxsXIGpTnj6YlQfPR+bjvwEV7BP94XL7Yq4YEef3BRJ/wCrjKWhKbPjYNB4
Lp+Klzg6TPOfc8x88Kr2yn3HDaWnRzLAt1qqYGAh3KCXiqPsmb3c9GRoMUU7laUUFf8AI/ByRtE3
sbLWxeDbF8IKxZ/E5dCNGr2dmouKGzlhdtxJbQ0shiDlAHqVAi/6hA5qu4fZFuQFsQKV3AESBZin
E4ixwiw0bTejeY14xKsqYGBwc9w58PDtw0iaCOPxLsRst5gZldbrPqEmNuy7Jw4WVsWwpalP1GB4
AX1MmLqp99QMfhCYDzKEuUSIU2bqUrgbWwF67CArEE/CVSkSuFjElnRowgA6NFM2C8EVEOqkm0qf
BbG4OygEYH1mLZUci6Uqq5Wg8AMCjXKTP3srlIzktS0tZLY95BoGDcDXPJEQ0eVD8x3UAgh9kXHg
Q0ncAu8bFTLLC/udXrEH4yLgE9WD8xUtaxu4rB8x3xI9x7iul2LIS4TqEWFdtj+pWVWKG/8AIffF
bsIzAUTfzEIktCp9REvyvR5lYF8vBEAh5UL+4579Q3Ag7jxvcjiJgnwe4LoVuMosWCSiXJ0KhOGr
J+rj5VGxVSVBWcKcgEq8L19xUhBRXKPGW0kgODSnY+Ch1QLDVjsESiBHYftZtTyRRZ2Ba6YVSiF9
S1K/KDD3Z5f8mEg2ypLuGWoQWbmGP1K6vpV8e4bt71KPdShQa91NJ7wGJoh67RFu9O3ZQjXwCyza
1FlELJfALWJl51pxHjxWKv4gViBuutqHTK8M4BYcsuY2y5X2Q6QpqDSln5lpQ5jOKHzB01n7hqlV
XmIgEoI8DPnbuoIUK8gm6O+DZbngKFhlSkeYnQ3g1FvknCfMVKQSVTH2yiGWCNB1LEYCu4HCnzKA
s5lz5ieMLMRZ6uN3dVKYq7iiDhUsuAfESKFS14P7iQrmDMalhwWTXIEoPlruAAOZdbSJYqvmWeXI
KlcEdeXzNBm+ZRVp8s21cfxCHFmJpeozB4uYAcSnhiFkwhVRS9wRKfZhpl6weoCXCq2NpTDIWV2a
9oBp5jUti1DaGLLMixVC3JUB9EFDYWle5agji7KsEKaES8reo5h0N0OUtgodlBOIxL5Y8RF2KFG5
5iTmvgj5KAvtYiQUG63YAK9+DFANXuALSpR4SNleA8RoOodr4Z3TCWsO1xBOGSxaRsh0GrBIqzYC
XnxAfgvIg8/kN9xKRTo5gDEr6vcRnRRGNrweYiRvRxAcK5kW16DR8xdeh0heAzYobanCJVTIXTHs
gURpSzuDehtix8eu+Mg+qKo8SovRf+ETMDgJRB38oCRT8CegkuEBEvJDFU3i/wBwruB0cT4M7czq
cw2Nywc0xRaa+bhClN0tROY6SxgUVasP6lfasWkaLUOQqLBtQKulrIuRL0lpJXfSKCB1BXQt9ko1
sBeGQjF/Weuhc6swaISMlOYVAwocEoEKZZZEQrsSRMi6CN3FORVmy5fBmgjYIqC3o29S0dXDzh1H
PBI29OmBwTL2S2CqlTxpwmyyhocS8gaqHaXiKpC6WdGHQoVVcwRPiEbiwjiEglkLFyo7btWM5U8H
MsCuqRKqROuICRX7SppY7cRZUIngV8wxCAcXbLwe4og2BTDJYV6g0ie+YF0Hbqad7Ft9wptKNWL5
IwZvv9oiVLr2iYMb0dSldOd+IwRc7JQ0c2oliILhJw6UOmALyHqYKWNGrgrKUvZeuyniXXTmprse
2HSrt8sxs4OGISJvHn7hwioCy35nMk7Zn5ifpbRq/uLKM1cHqlxYyC6Ayk5lNeymZ+lviAG+wKUP
xA8e7kE5uPiRrSoWz64PDH64G5z/AHKAUAK18xwX5mAYs12uSpgZeKBK8p9GQpLEKAvmCLLxihbM
dhk0PCSvLDee5ozI4x7JcIpdAwAalGMeQpchAR1oW+CWDIEEKuuIIzDHXmckOhUs1JwCpiUq5+YL
CEg52CAToOMiSxLwhioV1RE0q8rU2lD6JYLQwRSrm7zEUdkLFRAOIDCqoHY5zxO36h5jg6OQaI42
lwDVlqPbiNkqEEnhQr/UaBe70S1O/IqJFpMNPfA1ccpgBxBaqnFHwS0SrJPyQEqC9MCCLXrG2u68
RsNPvknQbqrXOWoMbXxMNaOVohjSPashZ9oVPqXI7Cts72UgGzgPFx2AZwHNzPqvFThEoR+5eGGY
gG3Cf0eZH3DoQJQLbcCTGwLTZiQ5aOSyF8TyO61GhDbcX4lTYuHrynLN4OTcbqYw0GqF7jlNR3Pm
n1Nzvpw4yXRVqYPecTYke6HOu5qnKb0Od+YZ1na0FuM5K1VksXezJXGTGaG0iwt/UPgcRI3UwtR7
IKDRSK23WLeZWN2EB3YaY74joSrgCbZFWfgJqMLirmmDb0EG+iUaVfqKylS5fT4itirjU9EBUOYq
KXFTrR5g5CD4lNK9wArTEquPqaK2T1YplacqBfzmMaVfCIipF58Rwm+Ir2usZeueSdSmC2R8qA/K
U1bCU6gWKQOXcP8AI16l8Tn+U4ZhWctQjhtaPETazxzmKpg8siiLaj1xAM81wD4K2GBLfc0+kttK
uYy/gD58cMCZQUImL25nARqLaUhC6PoI31oqBZaiQZ+IWdgAuti7ZUVwVU3R8xYBAyvoql/kcvNi
aYNEhpKL3hm2QrzL4wSyc7C3dqF1A60uh44GD9GwocyvQA9S1QAHu7iohAuccQva9wks6PcPsqXX
GyzVnslLljhj+eFR3cBEFC64qVQLVWS0SF2cMRcA8BzLZ7LpEQALHHxS8+wipnTUQEC4DxAkPABT
MNn2jn5iGa7ddy3kTHLcWiFyVV+ouHUoVRDCiBxzsu4JvIvKV2hkZhRd8ROmBdVCYcatqGBSz0hv
UVL1G4qLBMGgvCbVlo52FcAtwuJJlSgyiVZwnfFwOq4LhoDV5JEke8SonsUWUcQrSToIk0NcRoCg
5qJVOk4CVFca4Der8QWDYKu4IgNxjbO0Ue8O91JayKWcyiCgUtl7AjZtIUTAzy9w4jlb9QlBrUpV
ypzfZZUQ+A7hjKTiKWdGLwgBVaJFdKrhmJs/3jNKV0qNJAUNzNh0oUsVH+MAzaRmTyqfEyBRxfcs
i33BXAwRKWh+OZRlqKKdVNXKNOaWCVQmKZdPDkVuBkBUBA+ts1U/mXgqPAbLGleFQG9jWgr5iSYO
yMRgwdLy01SiFrh/QToHzKwEBULjtrV0hhooX4j+D1EwNX3Gu+rbrxL1gosDFNUTiLQEFOSaJOC5
hNeMi7UJj4ZQAQtq0rqgUDiwdXLa1yXAC3QKfKViXyajsBWVWBUVZ3/5ULo8tHULxuAnj/zFTfvc
yAz4GH9SmQBfk/5BRO0pTdQzKuAarXNgY1HRlwbQkgYwdRurkh/5mRIs1wSlQMBfowhKPGIn1DCl
cI4fcu1MHR9wd3ixqHn/ALHzu2P1Dapd57jZgQV4GYjByAAqBFF2qitBrbpSr/EOalTe75lUpcXY
PDCzEvCDxAV8FW/8QSdOaZF2AWDIplxUB2UwKZ9QLtu0dCGk7LyB/UDXxVME5UD+gCgUsCc9uKGv
uXs8f9kREOVoIj4Obr/cZuICjcpDk+g/8y/KQOAXlAYGJwq5ZfPrF8BiCNY+gYZJ1lod3FDzHgVK
RpWgr1e5S8fALhyglBTnq+492iDN8sOsVNglrqKKr8BsotSiSh7I1Y22XCY6gDa9jGMqqitEBtvP
1LYN6BLR0QQ0Rs5BlnBqCwPcJUZ0EnLFopudc7m5YVAG0wiYN7rzH9y39pBzyDfUEeoqHHhIQzdP
DOYnKgKoq+sBttI+ykmLyVsp4IADAhm28EBuBFqr4uJARXGmyyWUMDarCMgBaaPv9xHqaYlUjZTi
53EhljkUN8Tyq+IKA9dwAAYBipStyptW8Qpl9yralYcFSgOoAN/mA9V+Y5UaICl2IW6RQN4lAuop
RpEpM/cGYQXBUoHth5LiUiVKDtPlqCjEOmV8PxAMVxKm6E8M4SvzCQ1LVUyKUStGVQBrqDUXsbka
f4iIrUE5ltNl7qR0qqUfEQBct/UGXBc8Tj9t6PcNF1RkwTb4iZWl+RlV55XHIe6vSEzXJv7iUlhZ
ggfneLJbexvshFmGwIzVznYgfmU05VhL5THuLhs0lwdRLzxGqHHmHIqEB8Eq3m5c4KI6OiafiO3k
Ev6J9dbjWcLlsFY9VqomDAZUe/EBKYRp7JdFbf8AEpwbouOXqvrjTPGi6JxTl8wAtVL7hPOLnlFV
BaviXfm2gwzSlK9Nl/Vqj7mUpsCM+tJsXjKNWPy6KpjQBc9keu7lFFFRhUK5Nq/qBqw5qMRPBbDK
bFKmQl2OK7h6pE5Itpy4+U2CFlwa2+4DV1RvM1URSy7xEZ0HE6Fn9JyaQj5YzcA/WH+xlkTbyPMb
EDnhcAFonUQz4CPwxFMBBgz3Uou5ShWOFVUMZVpfD1BJHZi+jifmAD6Ui2Jo2Cwilsi7IRSQPChH
7ipUIOwcUcyCpwO1FfKObyl7oyZixLupkpVgnviaJnEHmO6eBx1xAIwVD0lgCEAmrYXQu6aJxkJS
wxP2gEfmVXg3quriABoYBk15VGpWVdG/LBlqaAS+QvKIJ3B/hj5bseeYbKEQQbvdjKl0NeYKI5A3
xAlqga9MMC0wpCrDsDlhjTub+bj7F4e0FGAwDgirjkSk5XBDYT0alp693G0R4cReY+TLUiqt0Y5M
lbk63OwvgLLqMKLrQ+YXG3qWXFi7A8EdDxfVwKy4oGXCZobO1DP3K6Quei7guo7dCb8wx7drjgf7
lQBtiGEfozsrWxcBgT9I6txLiApxTdwBVYBrT3GWtRyef1AcdDhVNvEfW2VXdwSHO3eEA8NjVAHP
m4UHY4v8w8VRU472pcEnHle4yhdzuCniBxA/tSExQup9RcudIrE/PD3/ADGkoUu8v/kR0NpwJCbL
kQdmMzDADByJAHg4gvHD9UuKkIqOjDnWy3A+CF2cRVCFyVTkbOnNvB4nDOivmB7wdtDqv3FTDGKt
sRaCdjACk+9fxDssKGgX1UOi1myWEpSmSqATVz7ipCrHHlRpgKJ8ob9do1TLwhPiupRPd+91KgRS
j5uV2Xxj+ITF9D/8gDMkGl1fxUumnAeRqErdqeipSky1sehghqIJ9kuvLlqrYbDrruXx/ig85LAM
rLOajCOg7n/BHLXYurY3+yIqAu11+IuMA1efmemCLkA6hAcv4ohlHYur4+IF60A0o8xpCtpQXxse
LaYBpxL0Q6tY8ObhAmav5oj8PTOvM1Rys+IqEcI+k3RWa9RbmsN9wkJxluB52UqED0esZy6fQyXj
XYiFBzGDeEAv1dwVZdYF3CEtYHu4L9Uh9x2DwC9XxL+iNhXLxKUgo65v/mFRlJdzkWMahhcQaALY
Cj8IFdtjdi77YqsHMFWBTHs1C5lx62/AwW7q/mdTi4Kccgae4rz1NPNkw+T/APKYHcKGufE1a0ey
DOeOIPoQp1cCIaL3HgXW5pwQaeNucmNt8wW01kG85Dxc+RPULmCwvyyh7jj6jQ0xzVRTco1jC0qf
M0iwQkmVMargn4/uDk4oTlsWfUXDdt/BsoG8c/FQbiFSRHVXqcFy0hTx9QY69K9dzJ4Aetu4YqmS
/M0o03rxDwzd29Gy2VuEcakp9VLRFYStlluIFHkTSXOIl8M1K+4BPZCm7KCIIHnxGwqJLPmCJRzF
WISiNaw4e7jSX9Q2B2v8EXAWYlUg2+JwMCvAqmWxt4M+figTRt6PFyruor+EJS3cmfbB8kGS3UHq
X+qCqDVyYMWFAXvZVC44lxnFghFby4XzKhbdxCVJU5JY4oLeOo6N1r5qWy2dZ5gew+bhlNhlRSjS
jZlQo8TOfMA6W308wkF2tLyZaHQp6nOxgDakdUXd4ggrtk+aJvmKiYQTqFCjS/lLWUrL/wCgiALG
wSrkqjHUgBH3HYjwHvghV1yMqvGmhALEgqWeoQRRP3A2JfiuJfkSXtnAlp9wxUoXf4JU/wCh+YpR
wR7hdQHz9TbZdLC2XkAJ2xJ0DVxZ6BX3A+rCk+JUVQOsoBLRN8w0hQudw2rBrKl9l0aItFVXoQYm
qq+oy21u/wAREatA+pzZtw2GrN/mVWAL9ZAbXyHwkcRyimIG4ENC5wH/APHdL8T6l6VEpfEYyLF/
EKaxxxVwolFeamJqNa5huo4uYwOd8XdwD+AH8Q5Qf63BEOiLM6VfcGytX5jkKNbIh8xWHRBIuX16
l2/E5nm44XrUADpf+JetWPHzHTsFw+GJqAVR4lMBS+E1ujxACVo7ORdWMJgrSfQSnAKR6oJyLRv4
lkwrZ7oP6gYsVoOkqqUr+IyOwL8wDq+/q4t/lFgvYpT3CZBRfdv+Q7VYIfLcVg4vJUm7V8V/kqpX
KXt0/wAgWW9OuIVkBYoqcptqbGoaF8MrCvk8RkQBq4diIrUH3KHMKpvuaNQh+Zb3BpFtYFPTKXaa
8EJ0vU8JDPaRH3FTdCGu6h+7HPXiArqv1VtRMJE8z8wJ2gUPNBn6jTvFsrKyUYiLvjuWxJbTjqX+
GFDxtygPQAmvbJUXQllHnWGqtBv7S2tH74iKKPuLcUOdgnbQ1xzD6k/6RmHoRabzOBgj0EdDS0oG
2oWgJjp5lLqAu9cIzERN0o5iIpAu0+5q+Rt+g+JaZs90WWR7HKcAZfu5XnHVsByUamkLo24iMsNr
3T4gLShDG7oO3P3Dv2HaHgiaUb27zjIY0VV8eU5Dku7CqPzKUsFtUdPuKxr1i3xXEf50a5fW4VYa
qr6lGIRQyzHCaVRTk065gporQH1Od9L11WdLM7DCrfMsbkil8Yr+I9eCi6vZZk1HJMjpyt0W8/Ep
VChS50dy0d2HNHxcoTIGKKXsau0csumJ69FUvylxOA3uhuPUtaczfc0fR1aDxsVvbgE2ZHusvmPo
YbNDN+5f1njauvcMXHHXdsHvYzlpoFTJVBMIaIq3fPFxoilTcqihz2QI4n3FWKLJbFfZCtNMYc6l
BPfMXlsctEoNss/EHynOZHBWyqpUGKbvXzBAXjHRYexMSAoVW+Y3yTxFvO4NgdxWaPxGph+Y2OYS
ls3iVXuNL4leUdBR5jfAr5lXa+oZhuqmHhD/AOQtwOo7QhK7jLK1A/I2HyQYbbXDLQypXT5lRpqh
teWJa6FAfENPymygJwIcMp6qaGb8BsalHvk9ZLCuTLlRS2C+o1gVjfqUMXTd/wAzCv7KDdRZ2NK4
6Sl9PM3DDgjVvqGDoeUl9fKJcwDli2LLudpV87ABZXxEuXUE+UbFVBN4rzFmyIUJ4F8BD75BlCF3
ipX2cbimKOKWav3cF+VC315jYIo0NvqcJoKq4ZqldAkf41TDMiq1KK2B5U9E2LSFFHGo8+6Xj3cc
zBViVxK8lnjZXo8t7I+AIrdRG36kS7gx+VeHiF6KxXmPOHQpMyGT7eLjY0HWhHBd7d8wIQOG4FNP
glKCc21FtebnABuhdxC7QucPuXgGAS2BTfVFVCWArNjQblVcMaCa4XrCNDKpZ9zDgnKlfmYARpVw
0iDyX4jM0L+Y/DgU6RsFu1IPCwRK9EXM4yWxk6+IRr9VeGnJYeUcuLwUp8PEpKoY8HxsrAzKkyYw
kDghMLdha3KH0BdAWfM5KEAdgVYCuhAWAAJKK/jxKu03pwHuFhSdWZkE34RwRwSrw2JQXHnslVgc
Aq0hiDKr8QXt1b8Epo1iUGPE1JmL68zWuBi4TJsp1FYF75ipecL5iCiuHlFcEhGW8iK0dxl3vSAG
BJVlJvPmOu7VgRb6iDUuZcik3ot8bsEUjg5GbSDVUQ0QR2HMXQopS+hKtRywSuUNF8bBCzRb1zqA
+9S9cziXuhkb4i7PEF81BwN8SjNmuhh8CyqWreZWPeHz5jd5ETg+SMtW1uS5fV3d9opC5gulSwQa
p6hOkGxejtSnbGUi/Eb3KgL4h/cq2WlaKHEagU9kHsCgmuJnmzPhvmMDlFhb7l9mWLFrqA6o3bvf
+zhWh/cpdhYsgkRLXviUChN3RdqGIm7KT1UTMoOwEDOKeInUvHxnOVt4Fa+kTMGvqdkWUwy7RWF7
y6jCmuxX6iAseYn5hWiorx9QxascbzzzEhVjyXv9RiQ3olsdqNoAp/MtaZazXDEli6FPGMN7ujb4
I+Ah4W6zA8HAt/MtDWGaGaYIdMXBPD9Q0XkCrQAm2zsILgyEsVA5z3FW98IAg10BZ18MZIwxiHre
YNSFbWpwOfecBWXKkcPRmR8xSjqfkUV/cudhFJR0LO5T7ipWiFdRqpeR8bEMYAzAjK7gI0LnEAB0
5a39THghtUFXhHvN5fcQMHNiiTVD8urKZIjkpPuHLxUUZz8xi1K0CkOnsvbpvlmtC9i94Xsf9kH7
X0wjAIAO/MrybKUWfEL+g1fww290AavxHobi1Fuf+RSwW+FQvYVscD9y8KsHmvKdEB8SwANyCbsz
ehWJ4q3mNVrbeodRicmdtd/MRHyRpD/Y5G/1iepZ+uKxXad3By25LUefmLgaxp7jWTVZ2XAiCKhD
YKnDYifjJskWu3dkJ2kAmzjkgcBsFCjyOcQDF1th8JGONohGe5Q6apoVPonK0uV1fmXRMIdp5lBx
fzDTSkyDauR/UscI8CMBlM5sQWcwNDV+Yq8pboSWupVTpcoClVLKKs6io9iDcKeYq/ERDY0CoC7D
iA0EDxGwobuY0mFy6U8+IzFe413X4ipHd6i0rU5D4mvCCiaZHDTmfSbQCg0luOvB8TAFYygQjm2n
iXNGea7hy8LKqZVVBsKFmzsN3Uz4odR6mZhsHcInXo4S6hXtG30c0kXFi7Vh2jgKV+JePg3Vv9y1
6K3W4bOZzkfEtjIlC1IT1u8eGH2bhdqM0rrojG4pjNwWJW2WA83xOFLmDws7ZYHmIGS9NK4npUTC
PynJ7lhbseoBDah4QN9XzKZwZbqD0WdxM5p9JyBaGIzfaNNqWdmIQauUtidqv9RyGfK39wgkOicX
7hFkzYv+xyekp5Ca4t2JNTLt8Qvv0ExC7xoMjtN/M/cFqEUhf5gVHQCJCutPJ8wbSqq6VfFMRjKa
I7Agk8Eav5CiviLqaa2v5nqShL4D1qxCBvhtix0OsFzRL3CZy3jaRbCrwqDCy+49I00Or38xsCnd
UuOAC2F5A4VuKslIZVdYfUYYvt4PqMHKGGRC3oAoxUM64VuUt7lrbhoI6IzEnCUuCq4uKuZaI6rs
fMLVLtwQaEE/uUaUW1dQzTHKVMdWqY0gSsOY4uKjhxrzHqWYZUeLt3biI95xiETAkdlkXirXQy4e
E8MTE8gseBlHWeYYkJq1ueZJJY8fFhpTYI0r1LcaG7Gn8wEa8y6IE8w4qRplXdbCnDgFwtelqM6I
FNkCKs+Q/UXfKtiQirK0fmC9hCwumAb/AGqFIh2A5hUwQqTFosAuJWjb22RPZyq6l+r+rD8Sm8gq
7M8xQKwjlktY/iLnVjf7R5UtaBUcAh4ew1se01gYDd2mfmG5SFW8/cBMGN2fFdS6fHF4AZ3LD+Xi
Hw6AA8evEPbJR5E6icBWG8sF+kPfDkQ2JiR7U1C1jQzI+4p0/JLoN6XREtcDMg8UwTmsLtVgRRoS
11vl4hnQFwV9Q1SQtbAc15gjRohQgitWJoIF3YjFbOLbIe5s2ll6jPiaqY8WuUA0SC85eSpaHo/u
IKU7xFWxhyD2R59xQ1rywVCed2Nd3DLTYUsECqT1FWCpZVrKm0V2Ncz4mEyECHw0lxQVgSYs1Q4P
fUwwd5TqZVi3fL9w468vMdeFCGRu4tWio0pY7hccXQKR2HaoF11DAsN/MvjwW9x4IDe1UCv4YaEN
ibHnioG31JxkWKAOFEO0CLRajtqvFV+vuFCHB5I+FEt7XqJkfk8JcmujkNWYeoj0o7CoC7MPMQUh
kQcNnjQ+WCRWXmORstvVxR+53N6Fa/IhUjPLmHSJ+Uq0B9mwO5o6AqI2861z+YMGkB6ZnF2slzLP
iLB+y3L6JaHZpLPctDbvzOQOId7nlYOjYeLjOKECLuU6mS1X3NcoSAlOpF0OYxiCYUkLNb+o7lqo
AVz7jNP0l6IKwOzQjVBPmIqvCWFdyjk5CkgRcVLqs+I2jo5ioPSJ6XGpPUpanHuAoFFV3Cyg5C+8
V2I+OXARzxNHP4hfCT7JZhxUbbXEiPEbowz4Xs3Ug+oqPJLFFjcptIpFSKBZGepZArLrzHowIKhr
DQkUnJcTsl+531HdFEcdoxyFjhbf8eYh1rGdw2qFnioTSmnHvmFx5KMUlHNNU4u52QBgrZK5ikCj
FEAFD4r9xQOpzBtUYflKhA1ZzZsVpD7i4JJVBzhSeTqQguXejCFgVLK4aysg6UAjZKqAGim8h5Ex
AujFHxL0VFXVXqLS4G2wdvWEvLjTahsqJLxEFrC8pi/w81NUNFr1MnFQ8pRSqHNqnbuYwEYAUayW
QqNHBIUjkLhcJDwHEoz4wyGMUH6QaHCxKStlXxDsYhFQW9o+eD1wTkC6qpdyNdJf5jGPOXNPc4KV
dYx0EEJRiFAghcVOIHdjzZkUIPrmaUWoCDss2EW0aWgdupioFCA7KgesZYXOQ9aKgQ2U1SNIAjGo
e1eah9uOChMqOFs4Z3mHoi2UXXyQrRrUAiZSuDYSJcEX8a5aggDbSF5VWcxKcLWFA66hwtDo6O4A
sG6Mq40pnIbEIyQQxyWiioPSEQBRyIKNbghTQS8BLJ3dbay38HiEEFdsAOO21XDOAGRKnhiqupco
MI6IQALVxUirKO4kESgP3L6I5hIEKBSEaQBFBaTdeIcK7IK7mcJwpktKZ4lYWncpKu7E/ifFlckR
IfO50WnTAgJHxzBMLmA2ISoO49YUcEVUQ8nhhEcMb8RSCQC9SrAB62XBVwV7lQWuMOGWjPqVjHUz
Fj1A2U5NF+IHJgQypXUlaKuEFTks58S8D80WOhXMu4AHPaFal884H7Q7Q0Q3W+YQC9wCWTnsi0q+
kO2z5SKi9vBxBaW4eUKjaaCSoyZrZ9wWgu8biEESnyYig1Icp4YpM7fBrIobL5uNA78QVV1Pdx8M
SAZz4gBpqMM0g9rgRr7I1fm2q48Q97pA9jerDamcJLCqo83MMnAcEbtTm2yUNaot37gzDUdjd/Ue
YEASkAluiulnj7hmGtKL8x4xFazeY8tXwJYpwGcJSnmjsPbFcb0Ed8ZEjhX8CGqacmz4SWt5iQ75
RVRurSEaPEqymlDQm5UDTZVufEYgqYNF4RQWlI43yxN3VEnXLf8AEaNgUUaF0Q1FgB3jaV3Xapb1
MINKFgL48QlqJSlWSlLz1Lba35nZMiVp7yJYqo9HqKQ0eIwo14YJ+HzDitvxLhfyS+jiPYuUhxSC
Qrz3KLb2E3eIHmfLDWHmLYnUBTq/MVWstVWThWkAc2JfTmCpaU9xrfD5mxXc13kLADSfVLXXPxKA
usEtPDN2RBprzEeVkNZjxsDXgdiRiR2gAiLf8QVC6O7iAofco4gsLdSypVhNrFkNUD8wANHzLJY5
c28QAIgzyd6i3olhw+oI7iA8y1c/UUay/ZODWvuW1hOTZBQvmNsmqdxKVzKJYoVlEu9qW1FwtyWa
2w6npRat9cwqUT7iXTf6jVPIkUVyRjd+vMtTRcuojBm8cNXu+Lg0ZeOTXMIwgS02oIZtVN1UhJCf
SU4A4r5nR4Z4q+Il4sAnxFSVPUxU9fmU+69kfZi7wzg2A1zRHVW6+G4ls6PQ4uLkCTHMp8CgeY3R
ZXURVGR+QJ6h5dRbOvMAIcuy9m7qcyFvmINnPmUWG2/EaL8RLc2aJDiWKt00eNYlTYHbjaV8B5+Y
3RboODzCeJBVIRUPlCB3IO924oBQzXmpeSVdDEFtvkSWvfLPrzDU1vTuLAufcZSCNbL/AFhbHkCj
cIi4o5WPgwz6g1D2h39i+4Km2mMCg8vcMYot+J30kX+IKOtNoiTjFDKnZ1KklRgBbMlK64YKvqjM
AAUIhAEUs/qXobUH7g3ekp6o309wwuDdxu1DsI/wDFg0irTR7rGL5ltffMLmBVHmNjbqjmPFMYQH
sjY7zKrqASEvSGOLlQ+pvNrAU5QqJeMUqdlzC41uiECpEN0mKMPC+YJk8xd98xtRdrVxtkQABHJ4
iUoCD1loBaXthhPE8zns7KnHdRsSi6g1BV9RopmqFsX+YJrYSzpb+IGJpr+0B2Z5hofIxlq9+Wvc
KyBdYaHj9QXXMXvIFkttV3MJImw0lQo2pDQqJZWNj7RBr0q7L+phe6ibys1/kgY3CAEFU0KhVJTh
NjK4vZEBlOg1C1A4qRENg4IVVUUqV7kJdWOSkdaE9+YCNoUYyrnZPRczSJKbliWdoq5YXNKOYsAk
4F1cIUENHF3HsjQH5IW0B6KdguWFSVGViPwnPASvHzLBSQ8yE1pyDUFmNbAkOG6wHDALZ4h/lhb3
TAti6rW5rBu1AnhX+wnArlaslyv0g6wF1r5YrRgsBuFolUHHzEOdapd1AJ5VSmcxQMNqtCACcYZF
PKPOzjWMSjkoI/ccEb+JY1Wg2qjP+9cNSCAB6vFxREOhv3C9f1ta+jmGrr1UPzAeOW8wCBB4gp9R
oSDstRK6Mh0VRFSbZXuVFner2g/qKc/0l3+4mrdNkVb2xGr3CYCj1zCKFMr7pid9olx5HzDtv2AV
EJTNU/SEtIpTD33LNY09X6+E3UGNG7V6j7n+ANcyx9cr+UISneCxthNQrDZ3Lm16rpmJCG+a7qsR
pQvflQNkmPnhMErMr1FICPg2dsMENiW8+5ct2Nw/cYOkRaPxKhZ+Y1FDIyW3/UGRLPMRaCkgVVzz
USwZ0xrROV1UZ2o0AaSw86y7ybGgipT7nMF4MS2qYsdJdsAqr9wYsYN6htEeI/Jk1UdarDxMPMQQ
A93AFjbgCZsq0upYPMQY7HIuorhbcIXhvE6v3F4Gl8y6n+JU4XKFv4ji13G3IaiupitjncHh1C1c
+Jp5qIpNQ1dbLrVBU0pUtr3xAanUeY8xpAwTRcVYe7i7LtrieolNWQVvZXsiKBXpLKPUZZEllXUE
AAcjBXA9e5gILXuC6RPXEAQUXLHYgVfcti1wXlaii7PwVXEMtrGNS49DRYFh7a8Tjy78p1F+oyBb
Q0R1QPTuNUo2viDEGNLfmDKFNv1UPUU+Gy4ColfENCFweGQLaFXtOZSkIwRXjzHlpgstyF2NK4jV
VVH2fmVDC4xNbiPXiHJMlPYg9hX8SkHlPOsu3C36i9yC+pcbwtXW8XLOKBWRCnLhl8u3bt8QdNti
/UsgUXcegAKvmMUJiO8P9gmHij8zyCLerltIdzHP9gQVSCD1kV5aLIqrQPsuBjQj9JeaN6QMFeL1
6hKsC0ZaPMtFwoWt6qbs3qvKPCijzsQZIotslLaBYxzFTRWEuhuqbA7G0NQZY8YwD8iH6l29FepZ
vg24OeqFdRd4KwQzAhNq0/uI4/ElBrmx9ywtZv3sLnrTaQR7LQ8RKysI0i8EDg5B5zgb5I1wBdPc
sIWmguDJ34P4iNkLdnuX4EwepT426vJQIKLtbCtZXdvPMQRtj5jxNtg6iQ8H0gKnorr1LLVf6VLk
NK0t24+4PLgfpKuRyfcY0ebhzLjxTPuUfIOvxFaA0thtVal7XD8xswKMGxA61vll4rDfC+4/4swf
cuIpr12S5iyZ5xiDcE8BJyeMcQ2wLglX1AFhR4Co885KW7ylDYtJbVPUOh4PwKuCxlVh58y0tYDh
OFDSRUUwXcVfcckVS8mpcmjrzGfCi/cOKaIX4i/dBPh/yNCoDc1WQ4iCryy7xEZZu722XKIZ0c3z
FSPEXg+GogvmpPrLigsOPyxd7LT4qE467QX8EfHuofOkUQtsPzAtLjFJxNjeEt1u+PqEKys59x01
AROoilNt/Nxy0e44cviGSrBPxsAaudsq4nLgPkJkIcldf7g9TKThH4yojiPQbEgUhjh6SU3st+iA
6DhnAITxIinwv+R7LKXEWDXmldk2exN44o+IANgA84Q68NNm5fWxRvD5y5RGuFe4PaiT4VogLKAH
4iFWQFd8f1Be3Q6lK7UjSBGL19rBZe3Y/UQIqUVq4jpCRX5RhhkMcwwuAw8sIBSPLa+o6roplX37
nSsvf/e5QcOZ9pQgiVbjY8EeF2FsL/GR0Vekvcz4Tp4tIaQ6H7QpXVJS2+PiECpDfXKF6EG8JgER
VG5cLIOtLfPiWS4gzQApOYVNB5JerVROnDGhfE+2ARb+ENaHqpbPX6gaRgttX6lhrYgA5Y78VFaw
ziW0c/ULdwYFrWPK/wByzQeIi0/ct08zIOJhPUW3qNkO5VvZxZeMKlFg8zgl1ceSt6hBD+YlRaRg
KvRipe7ZwdlKllwBYPqM80CHegPEbTzGy6hFOGWIVL5l0LkoNRAFF8hA0rnywI8xncoIJvZEBrmC
85NDzKtdjuqT4hqlBgorhgclV7iCNI1h1cq3GiFDTXyTvsCh0uaqobZV13/+Lr4F3zOJWkLuNPcY
WMgJMR5YgtXfcNSHqmaHC+Jd2C18Q1K+PJkvoKdVDzFb5R5gywBSPZL1lG03CLksOTYzsUI/EYGw
QqWjW1YSQE79woUPYxL5l7uVFuLNnKDRXzKuAruU8RUtKrfqU9i1OpVbq5yzSOlg3HTDJUt4JSzl
eIwWUR5JQ3niFNTfcoH2yEKy08QgodqEk2gpfGpT3kNeop3t0kHptjenNeI+DDDOYQLricNgw8Pm
VPBL8ISijvMP6rZnLEFDCX0URaIsHMTvrVsaBhQ+T/I64pP8QAgNVeJQ9Gi+YCpbX8TeLRVSIRAN
iLn3sMtNAS29z8OFxdAk6jgsbyMrBrtRsoLSkgOyNtijhl3VMwDTbowCVRdVDAUstnYEvuX5iziI
L90tle49sdOuq17lioVzuZNgm2ALo2P6dKS0hqKQOqIiCwIIHeTNQCGwkljLX3HOxLr4gQN2FpYm
gFsVIt2O5cExhlgLtikwGlpe9R+yrPv/AOy4ANsfmKzhqxeIave5T3FaBXO5cc305ESOYL4iYREW
PqVZ19puUt5N8TIBJr1sNkA0XZzAVi8TSr1dYUPJewcHko8EJW9dzPCTviofAF9QmdZH7gW2K362
DgYGLbIBeO4Bp208QQkYNrGEk5AZM9OKdXCKOVPso4ysbtWC7IHxUopS78ti+8u4/JaEVOYoT7OQ
gtwru+NiDKu2+IUUqqX3H4ykP2hyTUOymDwKWrxLTVWDx3KlVcN9y0nE8KgBCaWOIKWLA9xyRkiH
IJ6E79y7RyV/NsK6pGXxmy7HSBQ+7aJ+P8gMMR/MRpKvYZizFV9P8gsCX5eMi2bQp2bLSZ/qDCo4
e9nTMUeGZ9AFmHKwL6sHs8xaTjT2bDZlkQm+5TGK9Y4hTi8HZ6gKwLt0/wBQjC9udKe4RSqLG0oR
rPaoq+4XC6lL00rLWMby7u8mXNjAt9bKUj+5pjnXwHR1EbA3Qu+oqQA8CKvctrmKX8R0xQ05BuAC
gqoAVkowIFnXOQ1uAvkzKgkVM45y/wDJXtAIB4iYdrllSt0LoAT33GDtanX/AJGwHhMfbDXYUAUV
2gd4i4IXa+9vYlASdTnZ6W0c4P8AsGqJQVx8wPUCNo137jqlvk0oZHzBIMK5/iFSaQpwKfuDTyqd
e8VmsDUuVCluqvS8mp3O7UZwV5uHkqAl5+YRSuSUO8EMA4Qjsv6+43UEihp5gWlGwu6xptKR4sYL
YI5sQU9TPPiXTlsQ8ZGwljCFz9wfbuNhO4HT5gqF19RHHcsBezg4WQRupjivCOns8RLwsIADYbhk
Eg5IjLnTXzKcMilTZBIKH3GS3niFdcOrnRsyJQH3BXO5KGJc5GbxMC9qKJDiZS5A5eSU8D5Yl4q/
MuMS/ER2p1vN7jYGFeY7Q7mt2Wer9zpqKuFwHLJS0WyxNydVV+5pnESiqGJSExR2zPX/AOGl6S1c
UNrzAaLtGepk4jVDNgx7cTc2oFDyjrXnuPRBByCNkewOxBCPba8uxlFNrsczhKHDx8Q25At9yzDu
UGKcCGKbBeuxeUERC1++okwU4GK0IiDoXscEUL6qCeYV+dhCm+nDZcJ+qwLUS+p5lkeyJb9SxEo0
ocVBn1wS2qriFAqmKMqLk6YpSqgiADydwHYgjgBeyIEjCh/sBR1pCmYKKaqJJNZMc/49SoKwoiqr
ZpBsDGCsCC3NQACTlY398DwXLYYTAfCXQcrVjOZ+ynDLpQAJSMsxqxPqFTXLUQtlB7PcOzopL2EB
T5KyNopRfNm47yTsZbHiClIrqll/YnLibe7pc0+Lb8M2fxSf3O0oosIIurlBI9AsbVbUD7RnW5t/
1bzBCHM3CLF5lVy1nCFzrwsjEq2tUV8xubHjUpUjvommYHuS8FSvmOKQmJcCSCSPiLSsALUFXy4g
1cshaRWDuqtcj3Lg0no/uE8I3aAUELo/xBmwjuhfiHoAa8vqILWTDniBvgAh96KqyFCUVjwxGo2i
E/mCaYYCCyz81bOZU+QAtKOoMa7jWR67TK0LGi6gZUbf+o9PoAJwUJaiX7uG16rzN2LEcmCtB8BA
IOLAV9cwALlI8waiyuiL4isIkISwTjmGxTQPXcU1x5NscOlp2HMHm6dTCnxRpiGTTtYisCpA0sFY
ibQ3UXgjyksEjcm3poucuEEbrWBQxrS4+gC+MjgcFdIhJjL75hsSUUWfmCphVjp+I4r6UmrZYoRT
i1OF6LwPtFQOFpxsbWRz/IsoGkMCHLWl8EXqpg5fJCYHVhb+o+W9tmUNmAvih12LpCCAaB03McTV
0dcwXmKxqKs8Q221g9wXwtm6iutwa2sqNuHaC2R5CNv5Cxm7rW/ezodJC3ejYwi7CoPlRwxSdYwo
mDGQsug77lxYzbfwI6FQ+RDEeDgKJY1dxuTcKjRvEJcUpWP/AMiD3srgXfEUXZxQG8jJFiTjnETV
dhuvV3LPJurAPE4waxTPiPTfNJD4bEVrQtNw+Dhon8XzCOxawA+p2JSl1WnxLZiwbfkxKjRgMuox
3QnRGgjY0o+v7jqRrwrRKjgZgw6FRPZ83Lh3Dt91GsHMpPb5gcNzdD7+Y9VAp3jSiznuIEPZbHJP
KKbBl0KuK+GImlwme4QuC1RX9RRUJdWLvdx+BN0VBv3CFOGPuG/KLgvHUSkFSlhWwWeEFgcrEllW
ck1vfiHitqMsDUUBf1Gr2fMshSvJLMlN8RFc/Msa5lwLlx+Bl2uHPcRRXjqcV5LHnPUN6WTt6hZ5
vEV1zLRxKmsXEaKsgvNX8yr4qNqLoWJeKzuptbz5lmnI8E8yvTsFGUzokVuXImkw7h9RFosIGSgi
th+kQoKpgC/EvIbYUQteklkwFF89zgmB1HHNhBviUYdQIWS68uUGlwvi9cjKogBAuwR2HkiR8QtL
6lrzKkRxgabL8SkSHMpRB5nUFFrgr/8AKAqG+JQ9XUEgTnvuI6NK3GzkO+5g6Ryc1SuUw6XzTFEr
hZvRNmj6jq4TAXEralppyL694pCxYdKv4jC8LoGHlVuL3XzFIDj2rjYwq5BB28YvE24Of9QYrjbQ
r6lQqPJYtfcV2bpRhucKNltXN8RLCon+MA2VbfME4a+IkjENUaRBSXcLCV0+YBa2+JR8UxBawEK/
Mpb5CSvxB5gMs5lFKeLMhQ4cxVl8vUIUc0dA9E0JLzDjgNr7LdZ62WE2rOSXzBK0w4qd7bl+y+Fz
ULaw3HZnneh6iJ36otYS4fJDh+ZXNWCuNUgYbOLOYHsum9EsSBqWRgqmzsuFxPktSrrcKDLJYLxR
ElTpU/XicIj5UZGvyuCVd+JUm7imCvHXawu2rjXELHgIvMUeoFzjQdoLKfca7EDRDTRjIIO2sUIF
bQGQLYq6i1BgZ2fzcvRJ1ZuPAjw2g9Qvi9kYUObOYb/NYwXx1bUVXFdvMZSzuC3LByMSz91LrGB8
PiWCPeGj6gBbPbyD1CDkwPMKx6aXpRi3azoi8w7KVE0X1V3HlRzpBwfhEpOatLJZxDaYIl2mo7HR
mqnIg005CoFlxvPsBhGhS77/AMhYBZTLRHkucQGdQwiVcQoEvg1CGv8AYxe3HmUPhwbRfHQ6H4jR
AcBUMu0Wm+4nRBxH+Lu1cJQu3r4iEIFDlGKPFD/ZbjZVftG5beFqlPx/+GAQBucc/cqP5IZUJQOL
Zk9lAE01FkN/Etj0MFVwKUou1RtALRR1H8lWjE1bCt7D1f3VJVAzA5GbwEuSEwMYq4Tp7PEJW5NW
/wDkHRD5SN76cp/U6E8OpUBX6lYKijpAw6rmHojUewCcZDXBMXkACnuX/LXjqKG6b7ZcVxl2re5Z
wHwwAOiPP6HUCau82yhe0L5l2FRbZmX9S2kBtF1KgjcSKgIGgiAL16l3dG3m5Wy1aDzADNseIfMq
6LERp9wPem4cEbacZZAILc2ivg5YKLGoYHex3Urd+u4itQ1VZFbV81HO8PEXyPZlwAulWE5Dfovz
UCG5kwoO8irKVHVjqk4cL8QrDDQd6zmC6Gj6IoCKcnmNwuvB1F/oh1ZL9wQLnmVOC/MLWw7px5jd
dXA8tfMAno7mkcDxBB1zFWhKNcS98w7v3Bs8fEslcRNocvmAXQPuGV1UfW/cs58zoqwjE0YdSyoa
hW08wLIoWoBX9TBHPuJRRkNlwVVssivBNVx6jseYYbqIWrhAdPEOAFR1o8RFbTJrZFhoh3D8wOXN
RUtF0Q17io77hZeV4ilR3kL11xDg5YAL8y3IIepcbNFRboYjCXAAu36irIqbcQNOeJUqLoRVaS62
KBVk14EorLruPRx4l0vzKsPUdS5tqvx/+LAbVomvVHqKE1R1EeOvnxOwB6jlyDbFey2pcqD1FNWm
iMvU0GLkKmgbLPF07XH4VMoh680k6h0mm0g7LA11Ez3pyAtKeAjIki2oB0huhdkCEqq2eofbO3fO
x5IGrLV7uI9pVmS1CjNIh1aFkEgIFDtvYAUpueRBeqcQHe5Vo5h1YWy3DZxsFVapdTED0Wb+5a7w
XXwgdg3QCpRVG1ogwMnmvcBCgL+ajVagA82wa10tyiQRfSTicHg49wuyzDKGoTxB4jCxVJCAQM+X
mJJEdbKK+KJSO/hnNxaAAXfpFoih4gHARhxHDRVhWQawQJXMu9+4wUCJ3CaeR9MSUb5S7kX0QYDr
xkNOOb7luy04lXDY0ZKVJZaxyVMKEOIfrhbmxcAWCOQV0huzWwMNlqqhgUR4IFWY5MlkwMwi+ixf
U6GK09wvbHlDedQEnROk3ZFKfWAN/EFoDTWyJswr8JsAPSOAa7OEEBdCVncfYgsrmPbbBbv1Kszm
DzDPwGHmGKwia59RgfDEazi4H5JUy2DRZK2lUEIuDKe5kN0eVxA8nESFDXAiUfKQKXdGRs4VExJD
hethTGzm6lyvXWogS0vEXaPKowQAxxGIK1FnMrjgXUNgCETohij42QC16FdIJ2ArYcS7EC2nuPpQ
gzmbZbECw4qbdOCHcsh1HF+4UXZ5SVCVduSUpK9RAo/+Qg/LPdwpVsC6hVSiDEodfg31/sHK6ujz
4hytMOWfUNogqhoM7o4NG/U1kvYeDolsQ+TeJU6Y0MvmGFoAd1RKKrIs1dRWwisXYhIqI1xjDVsA
y1CHtgYvkjrZKqzDSJfJBF8ckXa98XKsbMKYV2Q5FQL1cNuCmc3Ovru0Ah4UYqP5idco35QWNRsr
dciIORCDsu9qtvqDtrTyZgVngv3EqJIHuEFwCU0Lv6hTgaV5qtnGsIcurhYoLp3GBqkCtVhDK4me
UJVTBiqWtFKF7NLoupX3D9oFZL8SlNo24BIeIdmUdCor888RSKBFKCZkKDVV+ZVRwHC4/uGYqvWR
uQPuWOXmw2/MFJMXl5P4g/raHR1HrBsLnuUlS1i6Df3UFFCsoX3+IOQd4BD1DK3BeB4iYWMU8XKE
c1zOUyLHISzyo8xaPCAtQ033Kmr5l01c0K8RtylIFb3KDzKta/M5ODcFUAJZOSGuxWjjc1thTFMZ
AB4iLyUNoCBpFjdl2jhSDawMxaN6gq7FXj9RLNKIkpwiFHEERWe2KPKYONPiMcMiqoch5lBwfcKX
Zo1XiBevzBBGVnE0VB3Esn0MsCzMga2qiUMvyRAp3KiZYwXevmA4iLRajbuyBghFapO4x4Ml4eV3
OFHJs52US8csW3nblqHcLDpawCfEGszZUOQm9RWe4IoIS3yRopx7YhztzSglLeEM+Iylr3Yl1TwY
2pq658SpFIvMCjeHnTIFBeiHDUXChMFw7HtAdAGyvBKrXcHttRvOxhYxd/EDeOWQjXQsvOwx7SRw
k8gyCQGUOoUiiDPcrwN7F1L2NQfJKOltgAht5FS3k4B5muRCduJyPAg7JdHuYVURDvI0PExOfcDh
33Ly5dE8WT4h6d5BxVLCQ893QXCRgLbOJeWIqFNTrfTCS5AH2cS2DUb8Jbo3A+fcNQt2nyq/zF2g
3h8Rm6B0lKTxV2cRMQNahXJL7mqLKa5YeBeAnVEDKqxwqwh9R6bacS9l5AWHc4WnLGbXSx2rhWxS
w2K8pQEbS2a9IpMcgETshhRku5NBSA1FVGSg+RP1OA2iS7BL4TyFDY7pPmAE6yYVLbZzOSLGOWTX
HlE+sX5HcqqgUlS1gBb/ADAgMcWQIXA1KZA624DC24MZIvI1fmCAsAh5YEuWM5uUz7GO3mMM2oyg
e/EYuqJVtEhAkPmoeQmx1BJVsv1RHdDRXwzVkdvEuYCLvnqO9Gzz1DEIhYYBa7A5haVsUjtALtfE
VWhlL0rYSi+nVxwZRpdQeoKT/qPDB7sMroiHtUaiRgEPttm7gUtQeYScppcHZYqcKu4D1RBLRqVo
ChTjvP1Gm72WEA0CLZkbMgAoL073mE34/wBErKbqvuGbw124QiT43NetDkfiLokuHzAVdHmGhyXt
LsAKCt/8wMGK8FSl6muiOO0B4Z/sHuosLflKNhCY1qYC4lOLcAxiASKWKChIVIo41Ks6DaXiWwdZ
Zy3Fr11ALVg80cy7KS1SxeBQm7N4IQd0kXEs1z5gKnTz6igrdPbFOg030ygXHR4SWBhX7f5BGFUZ
p4l+QuaAIxCKjN+5xv8Ajm4pBhYZf/2VskobfOzVISg0OpX8AIbVcRAwNXF/Nw73Agc0zjec+4+I
rwfD/wDj8FGCVWrYxgjEAUvuJ5J1Ay6hX+0ge4APGK+Khs89e/H6ik7ANc0UZQ5N9+oQcCXM8ExO
IQ0TZ/cHngvx/wBnMKSOh5mXf0Q/5MXVNG1ZcumFC8mKmTFChxDDsQ+7jMPjtQ+IrAEzmG+fxEQK
2ixu/wDZW333F0wXKlgrLNjlr/oMFBSuHjWWZcuUUok0nMwQpURy2x8Qh76lyK4dSofES4eJYXcl
1Yz4isKZpUMg74it5ArbGwuA0oPcps9HESMcgjFm6fUom3FVDhepgcwK4gL4j16+IAq25RK1eZwt
4jyDOZyIY5sZcrxDY8RrDqA07viXpVK4S55XxAErjmXczGltg2qgg3mKwyohWEsVV8xQVVVlwj9y
0TuVLbtgUvUt5v4nFwqLrbTcmRK2FLiH6i0jEWoT9wqnVfuW3lFVa9yqV0dxd5l2VBZ/UsbFpyWO
oLZRLuyoWMObj08ShvNlPDECJfWxigWnPiB0YwJj11LLTXzPCB4lTVR36gGWCkYeg2vhLYFb7ZFe
eCtdlww0uh18xoBBu/iIU0r47iSpXPjYIw8185KAOOI8rn5CJOrV+6hpE0wO5/U8y3YCefmY+H7C
alxbDa6HL7jYAJK2HYqwRE/MbXtlEqBC3mWWVfEsjgZVaqVEWGRQaO5T5Q3uEvyQids4/UcCgtAe
bR2LFEY8MUdysrJdOCTlC8yxsAHv/wARWYat/EeLdH7p4ljgkQMvj+pRpANRTa1KjM1oB3zGNakU
9RXqLZEoC1XfHpHI0KyNjC6fVwTaItOGAilfkZAEUCCnUYFlcYbGzpOJp1qoP4eqnJBHDvzUDXvv
jmVwS5gQAdlzOEb9uDzFwtF3LUCgqu52bItZBp52ArsUMR1KrIQrmlR10lPfEEoagV3cdXC4w0au
+NuzVfxCvIF/4iJiIvIIAaeoFJXR7qMVFUdQepBxYlaUg/MsQXlJRsBtGxFF/ebsRgBSahlLFLRq
xqV6XZ0FLLDG/wCUYbRkpMQsRqQx/CAwHjxZLHyNMDESw6gw3tkBPP4WwfISsQ31Fvpx+anklDzB
Tbiis1oVaUfETky/1DytHHjYMohSS2SL3UsCrpBY1bjUCFxYXy3FdQHCLIvBWFQMo7UkfnqRT8wU
6taCMfx0YBip9EZWtXzTPqUVL9xTGi3fUWLHojoWyMvuLhWU16P/AJDvwtm3A+Cb2qkpHIfo/wAh
O1Ioq4BMNKIfTEKOLQa8w1YBa7MbwdnEuAAJ2dJF4hNCyyL5HCUcXtyh6dTwU2A1CcJBbyFD54j/
ADvOmh/uU68weeZkISg6IuyXZKPhfUoQwaeblg2Xw/Euopb9R7xpH6YuVl2eq/2DLjBKT7+45Von
yoYfq5DjKmz0/wAqOikLu5AUtiyVwRdMqC1v/kJHJEq7eoiXYdtdwf6kDswPVi/t/wDkPG5T0NlF
prKfExdx8ml/uBSlQ1tuy7WtG+eCKpuCHIv+oDkE4O/8haw1PwEqRYp01yxEWBrq+0ZUrIWuYBuF
VxP7hIKXDVrj+oI5XfcDsQUCwgPHuGa464LqEF84PTUDaaNxa+PUvDLd41LBIDpScNYafWRSdyXb
fRTEvjsSwFz+YpwIFdkuKcSt2uxEtqu4BEePcDiqlrc8Ss02QV4wlh0EzdAnqJRO+YFOJUrqaNQB
g2vfiWpDTzHwuFi+Zdl+epWBhENqchzSviJQXTcAKvmuZxj2It2RaJexDulgIUeY8BVwHo7nNT8Q
FrAeoQiN4gfKWNvJFoPDzFUROD7XApwljzUGrWo5sWWAY9xyKDjvcpvLWJSzmWi3OrgE3f6imuUl
1xR3KtZSTsOrXxClKLPEputJQpxEmkpm7MFOsXJsYrXENyVQpu8iX5iKqm75nBWRYurYb3j1OBq6
6nZKq7qFPCUBa3xOLeHxDuNplvMEUR5ShQV8wdKX5QlhVewJDE7lQKXOCGlS67GZlrtQlXf4VuVh
p18JzLRppV9e51NA/uPGAZWQc8oGVqUPxClBS3jIicC23U4oLl8xDVanqOD0OO6YKQ4fKAmKMW5d
NS7C8OvMQ4tI74nwD6ITeWaF7OFcuWmFrDeTvR8kLN4qIsFxQQCiKinglCJyV5KV2yuDk5IbLdfa
5/kawWqrvIgFCmoPDU8jwyoeb5J6lSDZZ1KplKTumV9ma+4L4J1BXU03vZtMsHju/wC5zC7Hid4J
sp0WyH5l/JS9x+tS8RnefcX5AimFoG7AbOKr9xObU4dR5iy5+WVRtLuWte0yLgEeHhhAS9CoXQPE
FchwxuNnVNTkpHjEfqZkhHpcM30F8FS57bbHZDZVXzKVBoshNSBpuB1h0eJwOtWlw9pglLzNUtUz
rYFAMR8wBRrVpB4bN6MlVBPLBD0JMgxTKbGMgvHzsNZdqs1sYeFhlAb5dssIy60JbRBdItggk2lc
ENLzAv1KItcMFzJR4pgYQrt1kNpWUHuPKjAZXuDEC+agvgOw3kCBzcq0CaTu5Y/QWh8S9y9ULURT
LscR+0N1VDSMQ8iVRsVsSd6UcCMzR4CNwecIA7a2O6yMt7jMWwDhD+J+FRa6TSLl+00v1KLQKv4W
DVAvhMwnzFsDk9dcA8RwhB+lHMxitqkbg4bxzxFpKlY0gSEc0B/cyMHYmtcy4YeQ52K2tbteINVY
tUhNwQBw+ZUWK0mx3zg2i1CVC8Qeh2ANzkCtqAmNEVFIHgJ0phsfQSUQW56tPmj7itce8LlDa0aZ
BepyHKsyjkpu3S/MGq6lnBlwIiIpbVSw/EU9SLdZNDDimkOYM+RGPw4hJQztSpaYLR1tYzIVDagn
K5HaXi2U5EDGoAPUACAcuLuPnrtTjIQEKESyC6tuj8TCXbq/fE7RUWk7kWWqfPMo7lY0sZ8RheHD
Gm6NUtXmGzQ0UH1GCZAF3zOSfKkK6LYL3oA64r6l1aVvAXkJ2GChQEEkBTZvYY8UDXxHC6m105tT
XAh36JdrO6GoswU6CrUbRCpk53AF0ZxBLKqnLewjlgIU/IEq2fUCKqL1yHKWzvJ0YiqKIBCU1Bzy
w8bKquRRX6nUbUIna+4M7swPw4hqRlVkAjyXNiKBRIXdYFXfLkSjRBKtiRVRcR72eYBLvwiCjt+J
dMyNvhyKU/xGx/kWKuiWZCNBqGDzEsbw6g4fMWimIW2HRpAHQlbYFUuvmUrvWWLbV7Bp5g8PmaA2
eJyDI1yXcALSmWNXxLCjh7lhmeYqOSjSD5h31A6hHKrh/wDwHG8y1VZAC3mIchpVU+YoFZcraI00
QQTuAihuA5VPbB4HHuWpfEqqXr3Gid+kATfcfbl9RmdHmdl7Lri5Kv3OHywF80+IqHM8k5S6JRkJ
vGogFjsRLvmGjzMKduXEp8yiMl85PUReQDzHArHYkTx3BI8xSENbtLxHYJYofMQTluFglvU+u0q9
Qi0S76c2MZQbO2WkXGpao8MFyxb+o9KRQo26gYYbSs/UeLTzohlHPuPCorlBAISUmceJz9Bxrxcw
WxodQz98GvaoYJTQMdiYi1ty2deJetawhVarEXyXA6OwabP1C6mOiHmFBT1C/FKatL6iSnL4l8At
2DbQ75KFTUGhyZ+meVJyLUqTH4hz6YIQYLz84M3FnSu2YnDErssC8BwJyFp1xD9AMCKPBIQKrJYi
p5Rjhy7C2MHalCFE8k6ismyowOI6XbpLCBY4ektUqNtvNwnHSgFxQkpvUPUgpKMz5nRZLdE9tv5j
AilFIyMVrXSL2koVyWCbGqE5ixeeY3Gq1DYBooUloDc29UkIsYWuYiIxl4H7jB8tbBPcReEssKr5
RR5NLzDQl141hxfifP5inxi9T+YHMnutBgCqrhNcYynn9xUPmnKgjBW4MPEh0Ztlct4SAt0B6lRm
4oz/ADOSelqINuhosRgs5QxSnhuUTQIqF2e4GkVQlWfEVsBVLjFQWcTioKyNMAJYfwAip+0JoW1X
KgR4xqieeJmKSkXIZ2jvxA2JdRDfmcXYuA//AIfJrFHLP6jQCNK0Tc4NAV8yu6ql5RlpgVXF54wT
x6lgqOWZkECIaA2KVliuXB8kUAv5goEerENgXeNnARIpfiF1cAR/OwU6rDG/E4kbRUH5gU8IoBiv
0hq0Ev5gHhLkyAFu+GkEulyGwBW6jh+pXKDKtf7nV0QJLYe32YdHdVd0PfMEZfF/lzKtGNZ5JbqB
VK5F4cLC/wBwCIvfClQ8mg8/mCifYbhavvF0MRGHFcEA3p3C5f7zAWQgpvQC9zGiahUXtyuQqpTQ
lgb46ljNYF36lTM5lc+Zamu6Tvpl7Cqr1oha38mYhsT25gA0bDt9yk0GugvvzcQIaBLmjK0fslAH
vDU7MwqriazOVgYSbbbgq9FWrp7loFWteY3it4GvE5+3UgHWtJbSVtvNqIpuUUhzhexT8yzVEq2s
lm35XcRwpcbY3Cii9DUUp+PTmmkbZbfzOTaWID+41eextl8MbMut+qtFdSyhVH7hqnd3UBGkeV/u
U6uUKJ8se5NQvovM1zvuXtuQYt5AD1ElVw9QDZiErF6pyZapYh8SwUEtjSZb7GMelShK3UcVd34n
0IC6RSqrOJQpOYQF8kZ7JVxyVThdw6Tht6dyrBb9xDXMtWCu4nJXMXA4jVNsTYK5wQASchmvCFA5
Y7OamSteYgUlV4gAO/DFtBrxLTZVeJSaMpPEJtLMHAgKd33GuiIpyq2Uv4ibubBW+0mm3mNOcIWN
lnUu+Gy0G7AE433GhlPO+5TqpQ5yc8j1Dg/SADOfEUm5Gw0m8VktqIPTIPSiA3luRs5A9wSPMvPE
uc7ZzLZo69kBpFd1PApDuVFZ9+JfgUbE4gcwuBXj1AJtKS1AtxHKtIsh66VrFfuP50CeYoEbB1Fh
odziFTN1g8TXx6pIPLLO0ekUtER+O3eQDG2kYR0MDKcREUaucS1i2jtLGQ5U6irQW3OcDcZ9S0U9
5cxsaRlzIgvUyM1lcjVcQHuJbpLQOo9xuiFYbg4sQoLSEDhlhUYOxwgxfmiROJR8Fw0JVimR4Chz
kq2c+aWgHggKrjiDp9DWQqLIoL7jGAC8xmGIPESb6O0lylFmQJzTKhU4YuosRVONjVRQ7IxaJoqO
kNhyf2jNfcQ4KhrCJiAss0gUuq7qch4WNUwYkLpFU7n6gBAEdzuYyeiLhRcyM1wNhxqL0N+YtmSC
QSzB3REThKWA8wXvuEV4kUjR3P0gsOmgcSk4jm0AgYaSlMHBbGXEjoDoleVypIfiANZxL87y5bbP
iZmnKoDfpIw2lmzuVAbacI+7VwHVxmsYvrK0w1SVE+n8OfMeJoDbjGusPBG5+Gwl4xNKhG0g9VUb
YpLKlQcaOclnLWZr+ZuUjPMIRQv7lxpcboyCuW8QACmjmVlwEwGCey9QWn1VUUAnsYo8BdVEeil0
8L5mAIDucwaG93ArNCh+4XegRpkpdUwd3xBNLB218x8lOrKuDujZDJcUD2v6gIceiYohwf3BehdB
yVUpxGJH4C+LVUGW5Vst0AoDteYZ2KRHNSFEhkVot1BltfFRSm6upWRotBt+4zUHND+YKVX5ow52
xF2C5roAJAaKPRczSkLEhmiC1QB+5RcdBzLCG6Cx3HJavukPcXgW/uK2wtkotym6Lt/uI0BUUnEp
7gOYYlT3UyDFwJLXFOHuW1NAhubCeA2kH8SthCFQtFWwAVUytE1TqDNkkoYPE4VGuDcZQlUUNeiD
xqxKWJqQLowIzeqN+ZcN2MFYv1EREuhezu3BpifcUMI0scxV1KqnIEtuiK0PkhKETw5ZiO01gkbj
vDJbrCOgFLKN3ddRh3WAYWeYfAQFCb5jwOIoLYXFHOkRfG+YnHUGCCVVbAL+ZcbhikF1xLpd3xBA
MoLG1iA3EFtNRNyN28pQ0L+YWBVPzELnDEfZ1EjYBCednqUp69xKw4fEv0jUvCWLqYHBGcuAg3ek
wXVrLG8wCxS55tRBYizmGDn3AOtzi5+JdKM2WV5lgL5mLg9x5oVC6MOw7G/imDy8xqiZfMty4i2o
4l7d1OFRNaMjOgK+Iop15itrIVPUrddu4DgJAGjtxVuxNRPidDFV4itnn3AypRWcx8nrqYK/BGhn
M+RTAVzUgTrz1/8AizijxvcwCycXBMrRxcEtvpKKBrxUuWuHErbqrubhtWXFc6BMO4bFIQnUIkFA
OB9SmNiHi0wCkpoRerAz1Hby6xgy8C/RUsQleCB4QwRseClSihU7qGvpTsnJeBTVeossUBctxXYK
q4FTG6nxCs8xvKicyHxLsq1BsnMxd1hg4QApSObDgKB1EOBaIFHUA9idzj5PcOUQT0a/5A60txVR
H4K05qMyxc9MVMZLOpWlIvwlMSZXzObA2dwClWqEzi8VBv0NjnYUgUUWTLATYA6mQO7iSYOSQ2BB
/wDjiAKrBEGUAhx4jFAGEblYLoCO/gbDSUyg7HqAn2FU71JDj7gtCz+IWP2tkZB8JB6lN6QPeBrE
GoELtIAd4tRxLF5ID3ExBqz1KjVSoA0BiqiCruqhw8y9wKUXjiDEL8vMctC2RfEzHka7lJR7v31C
2IgnUqLxBqLxsHtHbcdQDRDqphUPhLoSpU7hThc1V+IOSg4bU3+Amrsw/Yt1OeDIkAua9a4jRNJV
73uMDpT4EdXpdvaWKVrdHNQ0GjZncbKvCjiYS7PHMoCnIevEvMGV02pQy+ZcxMKB7gKpdwWqaifm
gEf5oU8IR5QLfMduBtdrB/uJEtuRXsfuFydmRrkJN4nXXcgstEyKUVdbHYh1a6qOx/xDAKWWmG8T
FdjHxCisdniMDyARdSoeSfohjksG3Zsul30XCVIyoutlaV3uH4hVr6WKoY4ikCGmb/MY69YQRj3n
wrrP+ys8e0kejrBM2HC2cmjBacJ6ggEoStHu4NFadIjmytS1JLGhgHk6IEz4SrrblCNBXi639wEL
iEf6l4RFwb5mZLtRvB/2KQFMc7So+dXybeweBpDRUtjXkguv7iBSiKjDKgNt9y6iURV+vMbvBYNw
+KqqbV7AbCE2WVBJUSj6IijKUrbfdQXOYopv7YzTZ2F4w/SVm2Ce6KgTXDbtitQkBgHBGKattBfU
W/uk0rn9QS7c+VYF51lxF7xalFb2TFHqZoceYYjAoa9RKYAe4KJwvuFDnUbDiWF3A2m1k/oIa2IK
RQPDHrVXLdHPcsBf3F0v8RbwfcrpNP3OdFEOxxceZ35lgP1AtjI3/qKNHcbFsAabqWQ4SZWMuxH9
wBcH3LCMK6CKtav1Gr1+pRwZOs/aJGrg1bcG5zTFsbL7Sl9xuT9EHau5gv8AUpFnEuyNAC40k66Y
YeoMhgu3uZtxvuVTDkyP6hRNjbBsbx6hlpsSnZYKNRbzfyQNpteZU8t3KSyog+HzG3XUVY75i1Y5
jar6m7UXdRFSj8Sjc5aKgaMgp5hY3mWWNHSm4GFtMSEKqYVxAXzLFJgxXeVajLoLQykQsV8RAvku
Llx8Z+JdsWL3UMGIgvmURWQIpTFwA2K8RrDYfJKLFz1GUHkpuWExaE8zqQtqE1BaJdQSoNcljAPD
AkCm+r2PoBBf1AeDlgRsF4IM6Wyz7mThE0/EsIqKNxHea+aI+glXmDejZBVctn4isLUWqtm3ylfn
zF+g0wARy8ypLvqHQobLYovxCl+GYq9kXk9ws5M8Qiut9RW1arzEW4xl0MyUeH3AqDAs6oY6jjlO
IVrUrRupwY1giK1KyC4oGo2UuO8SqEfnsj4DbZBxtqXx7lArq3zbAkvYnxAay6seI7NPs89wYClk
vzUQkpXLndKRPPuAAG/4ZWVc0fEVHHpxZ/2ESmlK9RRAWgjbOnU+Jbdi7bjsLAK3KhF1c1xsGI6H
cpTnb2SnkTONlEegbDS19Qt9xpcW59Q8l3q5bDetdMAHF5nuQrZQKjcAOXf8Tf1cdcxEC9A+oLzi
iHgKbfzCal8Fn+xUYvSpvCOUyOnQBprFCrUequWTKKCExB5DuLJLURBA3kCEiaB7m64qD6Kl4XgS
fX/JVEBg45l5QFtwClHljcVcVfEsm+hO69ykECWUV8y6SeiXesZUGxsFiv3WH8wgeQn1GQMITQYK
+Y41Ys2qF5osCMZb2FMJzPWf5GRcdrV0Rypf9/ma/wB0PHMwtarziKELzZEG7QxyPA/UDCpk7sgt
2m+/UbcH6GxjQoavxL2+Fixt5y75P65tpW3XMCn1JhUWj7hRMgzcqJirHPzONOte8IiRYtEIviuz
4JcoQRfbmKZn9B/sq6MhgALjF+ILX/c5XsNXfV9zLRY1FFdzIL84DeRzOiOtrsMAgyLwajYadsqi
OSYbcdsGOxeDeu2OcitMNohavN0VDeGCDjxUqV70ezK1kglnuITtfSVXkSh2MXj7pioBE6xPMtQm
pAH3DpoUvJyE2VWLCFvf4i1xPA2LBQLQAbrf5lc9NQc+4UBoIz4ILVKR2oBhVt6RD6lw34m9TeXa
zKrov6lFqoWuYR79QS+huyaVHPKyoDj1GunYI4ghCGK8xY0mxITv1AcuVE6TncBEf7S5x1CgemRV
t48zZxcUK4inPxFh1EcKyU4JYrxFq9QQJhECmycnmong2MNrmYwjKKA5jSlXChwzJhOJWRJ+epgv
sjITPmWHTIWZ+ZyCNW7CWpkAb7j4u2olWhKi72BWtY1FpYK1nEDwz1Ar3LnowAJ28z0kYrTbjXXi
KBkb4/uX2DjxGhCETgjQEaXknBRejfPuFhUFNhgLqOCtnmX6dlFlH4ZUlIownUp7ZnC0a457lapR
EXoHpgolx7g2WXNFqWa2KtefUDYGn8RzOWCLxkwfFwC7RPEsudCNju1Nw/MBXNkAWeYoyWxVduon
DzKduSV8JRo4gEd/cLXVA4vuXDRjj1EhdRuax6iLxnEAbT1csGGHIMLOZ5JhiLVELupD63DvBYoS
WlN2tsbshf1NbZB9XC0oUmRIUDQ8PiB2jT8ZBAyWj55l6dkfqCM0sXLICkUcxg7BZ1TDQ21qXA27
8RlbC8nLwy12XfmK1zcApDe5SlnUMLhQc48zxKi+79RAqhphasIxqn8GMBqUU8WW34vYOUUTkblm
BEofUdvA8lxwaSUNs6l6hrjt1Ai2rUsyvpwzC0C8hcNTRLX1LxEHF4NxVoy9buMQKxXqWkIXfuPu
Dh8X3Gr3/JVSkXzazEjRX7iMh8PiW2gNDwTghQCnxKNOl3WzmlkHUMlSiA5vURGUGw5phIFwNiGe
KCVqPkQ4ePmW2aFP4jIKCohcPT4gJ5sM5lyF05fUPkQ0wKQblyoQ5E+ZY+UWTmN92eoFW5VGNbKf
5IEcXDcfBGqQQa47TAb0A7lASUxoqMxKeFch8K1tTYKUVcLkuiXmC4ZXaU6Af8gDtAoN4gVq+B83
GOE08+GLMe6i/wCYv0sr5CHN0dnh2JzZWCr8QlqpFN/xDtlpWyy/kX4uEOwAl/MIHZCDZvfUS15D
CsIRR1Ub2vVgb4NuBPdf7Rd1UPslLQ3t45ja0lb7KjpaVR8GObL8PmMNDfcdQBRZUFLkbinLTr8M
RaWl8i4KbQA/RNnyPSpSrLg5S+GcHwWDGUIGm6xJUwVQ92EOIhQN+4lpCq+29zN6RT3RGhCwhwnc
z76xmI5Vym9d3KQ2663oP6jH21vXqC+os024Hyr+mNgNoFu2HqJTlZ264hQioD5vYRefeAxLZLwW
w3bgfVGD5EG+4kdh8IrDyYH9RBBqOgggoQxb5ZjfBF4eIFJSLtdynNYul8wZQ05WCQa6/wBoegta
u+pU8ea0RSvzWAf9lrE5F295KBwNIb4ZtYAcbh/UE7dg6E6ErH0VLp5BRRwT041BTIUU6dzUOjvn
xKDXAujmDzE0fOzNSpfQpF2W/MAyqeJSquJH1Y+ESlUDFCP2iJRlRPL8wLdnEBE0HL4mTCLDwjZt
5j6CKU5eoWHiMgzmAFPiIGLt6iHy8TCwKOojsqKzaqWFbsHn3G6XMlJpWPgQDnZgnqDBC/cQnqog
o5hpiK2ztWRZR1E+UR5yAJcfwlWrgiFCriZRvuIFtk26NGdu1iV9xQPMWjbt4lpoychXxEAynzCs
fuCEqYngPcQGUxrtc7i3Y0HUcIGrKBmSqOD7ZYFPTE8Chgip/wAjTEhXhxFLIli9S6U8yuF0Rw1s
u25aR4TLdMiJV8+WKgPLLt2WeOO5dLdvuWB08ww2vcCse57C1yC4OfMVWAruWC8lpfctzFeXMsC6
IC7cAtlKZWeIqfcFmj/8ZJQU7FoBICS7AjRFKuIW7PR6gaKbGUoD3Evau0MwWFNjd9AuK0EJXKry
LJ55UvLcUBDm2VAtYBvkvuP0BF6xIEeKvML6F5Tmbo+kYaWdDB4pRWxJITS38wgW1PzA1Wa97goA
vyMcqWILkYhvbJsjMUcRTjvuEp/E4g/CXoXM4cGXR58xZo0RcruoJPA8Q7hHhCgv2P8AMGkVnIZy
MANwSFuKaRoUuLeoFlZF/MBcVzjewnuKnLyOoBoF8wNCqY+4FXQqdH8QS0RbfGdRwhGs5gACddiO
qmLS9VDw9tssiqXZ5ckHmuuviDO0CJMN9eElis495yCEOshkJqGOf/xLA5t4KWV+P3Ak1NiwZc6P
tKPKr0iSFj06i9dgApMPTdPxASUafGxuoAZaJBDRcjezoecjW2pZ19ymt0ByX7aVUMj3Yjv3FHGq
oZF5UFtKh+8dlKgUUNDZsdA/KiNAEaHjZcQQXaKX731ELtKnl+JR9vU0+ZQUDsDfxAUCt+IKDxQk
20s6IsLpjS2OXBC5TZPtBAvlB2VBAWrRB9cB24cQLxgVYe5VEDFSNjclryEsNCVR8wNUa2WqckaR
tFRbDfpWqgzlN8zCFX6lxAypQkyhDgkJCYxv+YRVKKG67QQRVGL75mzW6pD+KjvDxdSwdTdnNioC
GFFxIpg0SU/w+AXsDXAIAU/MelfAFtNIQzksnSLsgpLrAbE5IhqJpVZNlikANe9gX6NVSTBSGnXz
NmnZurxf5ixbVV4JT7fXFQogEeSX5jHybGAYSwvM+agqxcr8yDaavoQRwZKkJVDRc34R8b36EZ85
Wc/JFCW14fzUNyp1I/5MbRD8MUn9gctmFNpLc7kEWBq2OYOw47HGUO6vx19RB3xVdwMnka4Npa1d
uLaswckXbFVsGosA8bU+KZXKNdgXxUZCmIq6S40aux/5KvUQN15fiB7gq+FfMJpE0P7jAyB7Qaxa
EW7vvxHKTRDf7YgX4XdStpFIpb4DqNdsG30Zb2nZFuujqAS7YTtnrwQbF7xsoIvfEbV8yzED3e44
fNzgKv1AINvjYUcktaKjmV8iFjYOYpYFkTemSvqNRzKsPEQCKsibbXxHQefMFgyUAclIvEFlhnER
7mrNKgnmJTsqgPmFNMep3uXkpud+J2jnzHVVDxCI2tzLNo3EFvMNiqnyMGSdyxWWSgghXLiKjiU0
6jyM4U6iFyqc3zDaVDW76m+NJRuRUCyaukzxKKzIeoKbfxG5p9wVpUxxjUXA2FL4iFfwnL2gAAEC
uTIpdR5pbb4iNShO+y/EVGs5iC9FyzeGvB/Mr0GOJgU3KKzH1Faq+5tRzCo3nY6nKxCPmC0PEupa
VBAmepXghlq2K2PuF1dWEpSycxbExXwTRAeZXRHJeCus7SrlviXVbJ3YLURVO+PMuP5hLjL8kIV5
TkisOL6SM64plrlMe9pApqmHA4DTAmiwQp4S1W4hcQM4JVsZ0hzaIWD4pplDTHlKRng0C5O7VtpS
h2KOkFO6UHj4jwo0XEApNwuT4lRMOCx7XYWWyuS6vcQoMITRMhmag7BsbabLF39Tt4uaKpqWpWeb
hae4RzgjiHqPlMip1VsznNXaWkustXUTbQ81cJ7GtGnqMiBpuESAJhbcWKIOE5ASJHjyloCOGY48
Tca+oRXV1KyNFfhsXJMYWcjID0BxBjQxNIkgAzksdWualTDQQeGnxDOmKE09S6XnIYJjes4LgtIh
TJfFo8BRHJUa/sQQOFVaL5J1BCjDNivJazVV+0ON857sqaUVpcc1jKy5qDyAXUTYw7hbZHviXSxc
lJDTI/b8xh8srmJEyuMzzHiEsnOUHdQKTvLY+oW4LLMCzyutkRDPow+4F2GWpDaZ6YHe2kqvljpy
9rSy1f8ACa8h8m5Q88ooyzM93oQim/V7FAWWxVY+YEBH3eiCWA0tT9RlWBZZzD+g7Ig7IJbEJYRJ
yrlqp8y5NccCMU35Tk16aNeWXBwckopCPaLD4USUA97tfzBqSWNr5lKDy3Qiq/W26oiqcUNNlw0L
yVridAfHMWA3SnJuqmAInIn5uPPCunlNJeB2oqBYlNGDzoF0KocdoMtjXV7AXZYN58wA/gpP2ikq
oce6ric5xsYJzh3KkbuNYKTsYnvON9v3DlaebE1Fji9ictpau3H2pfHmKdQ9lpAFo94o791tmXrb
ky5gOmjqGjzsHn3Ez6lOZqRb5XRLAJLqoCbJTlUKmHQ/qL2IXzTmall9TQzH1EvPa4PVZo3hlROS
BxAxToBeyvknHAjORC7FjKnTmFcQKW8a5Ct9G26i1VY9BAgRWsXLvI5EuIZWUupfmUpAaxc46vmk
UPBZ4qPYbx5GXVzLS2Q6zrtI5SPxAaYTmEea8F/lC1RdoMDJB2O4Iu2q1/7mHaJMu29itrvul3Nm
otEp7ilXkv5niXS+PRKC8P7iNoniGMYtlzJBviNy+HuJNHLKRbKUKv3KGBpDAbAeK/iKacMpCa+4
XrZcXalsTqFXipk7X3FFVslgxbvMargLnmXqGEdlxs5E3n7hie4mtlEfHUbvTzk1v9om87nKSXs/
Eavj5lK52pQWDXTNNuzqFue/MW6JV5AvaOFhFRVZ5lm7yCraX3KZnPcsDF8SzXqBZ5gj0YujW9Qd
bYbK1Z5hR3fbOHa7qLgnHGzlPUaR0yigbctQfuBMReiwta6fcFMWnqW2qUAqtio1zAB3Gbp6iA5r
EvRr1/8AigFfE5BNGQETdjabVcyil2+JuoOSwvtnwQb3AKCriX0L/MNQUvMPit1BZCvMC5xr8xp4
O1KzFVDqV4aifsjRcWBG/dwsB4BAgr2hMgcCm2awSaclbMpVzASVJqBEUhs74wkUy7YVUQdvlFoC
H0mrIlNRNGugQLUDzCz2jL4g/AkC7CGqouWoz7my9kxXOoLluKgzr3As8OpxrspfiSod8AaVX65+
JQ8F7UNLra4jBS/MdoBtZU7NUL6RlgORG6kHa4gJdc2dMWNFOQ8QTQ0qeN6We48g06I9OwqobZtW
OZY4AWzi5RI8kFfbXCWiB1U4MqaJw6JzXEQ49clwdq5TUIOlYhOuQ69xV4niaLX0k5ePEstlZVS0
AhFz8yssoKNADaictyqKhIPVQlKXwEq5ArHMvxV5DZyoVb9wXlrRz8QLCKk8HETJvo8LnAp0oAQc
F+0jQ4YmMagpZZqMSzE5iEdWp3InQX1UevWlKalAId0Kj0huhL647SGVDdlG5OlYhJd1wyohW6EL
lxs71BANlWn4xlmry2iVuKvmVl9pULfFxDmFIn8QxZyhf3c4CCfaoait8QFPR4gAwrlhKtJbZZH9
kr0rIQevK+YOqPRGFVWiHURUB8nEOhcPB3HHQfuOpra9yn7cFEpKh4RCEr0pNC3ZkJWowAGOtbNA
YmzH4loopf5jtHZKbruEiIQFR8s3SBxBq3wHKjrTS1tn6i+okVUI8q8SoTe4lM4AQuY5raL/AC6h
kM31xahbPOcYEeSk7xkc1AFALNGg3Z1cKdhWb6gA0tR4hZRkDQ10Bp8MIvAsxXmCL4ui1hSmeFH9
w7ba0LEKLcEBXu81sciNwQRCBTZDm7eWGAUYe0g6T8ACupqMJWNiVFHJUahvY/cstuWFFHVgEMDY
fmchgaVlcyr0YsMQ8QD3S3uZUmCrhkGGu8bQgWOXynqCyDOR+oSPeUoquiCRMSqILINaj6WcjvuJ
xrpcHs+yJBhaIoPHzNsJt9l/EonWMFt1zARfoLYXkJyMNhV+IRbZhx7S5ZdSeI6VrYVnYdJU5VLV
vXMHuSGsuKvgIwW+YEBdiV+otrrYcAQiUu7Yg4WsCjRcGwhAEHfcqz9QI5yN0lzBu4PClwE6l1rA
UqWBo5hfnKO8EELafcR7MQd4gJoiqk24CuD5mIT8Qx0QKGu6hgQ2AY8TgOpaob9y7GlkQ+SdTX1H
YVsu66ggWiUpZazyeI3uvmVpg20tg3CaDqZR/MbnB3FyC501xsR7V9S8L0glgpmExCS7fUOSQ7IH
qNA5SnopjcvucFk5V2RrkazlxsFo8THl8RaSoaddqVLWjmG3Wjifc4epSh1C/MbRfTzFf35hjp/+
FyehgFQX3FtLVcO+7hiqtwgJebK2VmzX7nMUgvYhXyW40QjwSwzoM76hLVi0eoija50rnA89D7iB
nStS6icFisNuHLapzwxUYTuXQGgTnMJkVWk+/wDIIPzC2KLZcFOJ3Wi/OwqBUDnXUoabWdg7iWmQ
qBWxtUyK49eIG7YHUHzhpesQ2S6w2+5YpOYU1rCqcN2chu64joSJS1q+LjngDh6iNWrR4gCziK8w
sfMPqUd5iyniVqE9bYA6W5OreYeGeiQNCYrBc4ik5gjGkAeot0RZbzAEYxo3NzJhXVRqqa7g5gKv
W8yhNBbXeVON9FIiz9kc8GhjNyicjRAFhTcr8SoU8MstPB1ZUkKPuFYr4e4dCPdR+tJcA5crkrXU
DAAB1xEId0hZ7i0Db/FGpDocNwcgoJRGucWzC8v7k2b7XmJ03Hj54i/AOO2QxVyPwqCKgcPjYh68
Xyic9spwi7iX8Gywlgg+6l5WbUQXK57qO8WiihcoIby9uY7/AEvZko0EXVdrDJdCyyvUchZ4qmYt
XMckpODAcRQd6l8EXhcr85kqFDzggwlNWLhjdtTUGopZUdTsrSJKd1+rmOYV9NgDpcbBTalZnMs9
XFEjgt3fUsQaiMhVX73YJgFjSy2oNVwXKHSHRxKkiyo0NfNQrogvCBQjAChvk/EHkklThzFslFJv
zPTlG2ZZWYvL/Jnb2oOYgFsiUhbNfk14WcSzi32EQyUHG/dymnUGFY4eCsBGWD2YF44dhCpZOodO
nXQ44/MvO6QrghAnlxacf9JR0DgjIupcsBdQDTDtZ+Yv9wk1fUBANDK7isdUFRxaZPPIiMZ1YSjO
JYXkdPZL5gUEOMgU7JUs9zKKHe5fECt1E67RCk9MTuA2mcx86rwLeUjiVutmPhhUhYdYXAcw+c2q
hahQn21HexFc4x0FWK9ZFGVaoBCZFmrkKiVfeBnELXEp96m9iC3Vn/I8pVGd4nL3hNn4IWwcApZL
CgpB46qZHlTUFsINbunm2pWRoHIYFNunjRe3LXEWlUdE5LMSp3cHXaC4j22pb+TYsLgp08RLTQTp
l8naHAwFCxb+G4i3AQt3cJ56nWArudg/URcceJdi6gdFsTCdyk4HcJWxWDlDaspYAS5xzEbCo1Lz
1MC6+ITt11FTJZXZGw9VPIJQwufQSlRz2QqGByc9TBV3H81s2OBLitXXHmUKvEWWuolF1Nu4qIWm
LTVhPoyiWyi2XrAhbIhYWjUaabfuLb6dQe2VFOz4gP6pgjm8qUXceoFS96lF1ti2I3f6lGo2kpO1
BBF99Q0aZLQp3uLhqmWfKNh/CWnn6RbV3OTeToCwgBz8IHSgSxRBpRuCpXqJQ1jYxQ4D3LXX8y62
9gwtzuXYXfhAMLOOqgrCZC1Y98TdDuXBkXaEVqvJxPgEQu9qfiIpbkQBVH8xrkEVIG3zAJRfqCwD
XUYE+FdRKO7lR0EvCz1KkxAd1Rv5gL0ha8wkLXBzHqkOeIJ5B4YJDBPqCbmxX5IMY2WENxFKB5qW
6W437le76beIcGXDxKqNK/7jE9y1H0IcnhP/AGDgGxoIAQ23mVRyECrp6iIEfUufHxEqm2LdwlIQ
aFDicl7gV9IyJdNIGh1eSzFgIHCUnAmy3L1wG24RBSc87LX3RQOIUCOCjHsLFbZn2NfUGmrFxHyr
QIG+qk6TmXqx0QbQ2j4EB9ByXHrlNvcSiLNJHD0PAVyFyKRfUfkk0vmPtTD4OoPcwLv4lDzaWXH+
IuA8S/Y94LuWkPa5YEgKcV3ASulg+anhQB1EDQKRHmLIjD5jBpVWNRShE5JWzSrPJ3AsKstzlWmo
BXkXO4Nf9jplAJNVKS5WibEdOZYOtbccClIMpW4GtZdFfJGgJoWVBYGcFdRFfGh8BGltobcyrBm7
9wkhauHe5WvJY1uThNx9uIKc0W/MehS1WqibUjmg/wBx/tnKOW7SvcUIVd2QeaFfmY7nXV1KLjOF
EbAwDYsKwyog0H+GxcBf/UTQ4g+GzK03dx0oaWJY5chnqiCDBpT9QdDQT1u1AcdZr1DZFaOrvPME
6xESAKHSP3cJS9ncsMhG9xhwf/EHYAoFrISRLGxHxLNMAO9mtzd9/ESBfbfHUEwRNvYxiepTydkT
nxv4IA4t3PjYMY3UcqFs53daXvH5hKnXgfMTNdHe4q+aIJAsjIN4P2ReNt4i8AH19f5NbUlZ8M1f
XLzFNTgLiTv8x+q8yPtnQ6kaGIabFnv/ANctbU6vFDX8Qbkj0NcTc6qvdLhyCVElBa31k6zjPPP/
AGfAqE+ov5KXyMBoFxTvOX+JblZehr27m0BQ8QefiMA1t4DC4IJ8IRQdAKeFLOKSfDLjdRDyJphz
0LpV0P8AsWwrZMQXX9S6EyOVUhkXr1fEdVS0U68fqGi0AHlr/sGCpdKReP8As6+EyqncMqGezfcI
RVNXxRDI5RTsDMGllkeshd27aAvZUcXChp/Ud3blXR4/STXUNFN3zDpQHAsFrBIbR8g2g/ESkEll
nqMWWyB8zoaRHyja0HZ9tRdKwJds6iHHlmS0hID9SgOmWVMPcNBciFOmWyze8RKpKHiabCoNwbW3
FZlHcLKIleoxY2WNJhSU+opKR6lc9wNXYC0nMxSQnENDOe4kDLeowCcRFbaxiHixg2okBGKEVXmi
B5F9GBcIGVcUWxpQd8zlEXTSXFcTRUSa99SqJDDgIgSNOue5dUlnNwHXLjQMeyFo4rsjDtyp8+oW
yb6hoXT4nQ4CCMPG31G0OX2ShTKYapYQ0+UKl7iXcVZIlqS4BnT5lULpiAW9zbI3jgZbbcC+QSZz
xNKVUWgqXstvTmDhBWOu5TVNsTBK1dciJVQOTTBUbgOPMRx0bPg/iZgcl1KQm+eyalciAEpHMFdp
T9JRrS1ieZX5DtAOlHdxNiWpRBuFwl6/8gHSJsi51G4IawtIBEMB5Q4ghzm5cY4hzFIgLBaZ1kcE
C1SJmmI+/wDsqcaX8JaTjVvJcurGBB2JE2bZLwy61+CVZjyQrba2/uWPjmF13EBeDFwOWRpZVMdR
uoJFc8S29fVS73GJw28YNsv1FACpjXHufwgpxdLUFajcURuK81fEBOYIbN8y0KsdRRQ8peoUaLsJ
U5pL+sS1HmJaj3krxnIeZjS3Vw0GgX3AdsP9RY2kuQbl8wemW20WnqFYlpyVeLmMD12N15qLEKAj
zl1G2dzUslbN6xxOCCRpOWVMhqJReCrJXLKOQohqt+KhJCwgl73EVBo+495lVH9hvfUSYlAfuCWA
cYt5lgkWhtgr5i8YnlMyVihYo+51WpbzKCLbuX6WBpozABuOX5LhqCT+GWA1KHzNzL0ZxsC6lUPx
GKDfLWFYBGu44+HQ+YKHwPi4/QOLxYoqyvJHAgrZ4lE5asaYG1LbXBU43SDqlFUtZ/sBiFVJTiM/
QXIEFG+/FsJUo5X+Yvumk8tx3OFLmAUbbHakIOCzYOzye66yIc/xUX0GvLeZT9nWvVRs3Ha6u4eA
YHtqPlmvpDVm6NQHRLDMhGijH3FSlWhp/sKEKttxDNarTioQVpP4ZfO8g9RVAZV4KyX+TSPC8QSN
AH1G4CgrzWDMoOV/uI7yH2YbAiPGzzDDG2w/9ss0Z09pQnpadwkx3bnnmAMGnRmdWYwEhB8snale
m+4hVLvsNVAcl9tHpIImkXi5S+LX5YJo3nXnJduLY+TD064PRENgU5XdyuiDJzkULgw/CEg1AoD8
8R/S2wLXyEbMNgWXb+ZYvAl4M5fMv83ktxYGRXWDuCANdkofNxtRFwHqeWH4DPevQIVWkoR/YuVr
e8BcPAoa41X/AFGKM3BpYcrBGDJlES7Bz/8AIv7FbQg5ruI1iFbg+Ze+wLWXUH0u4DArZeQelYj3
Lr3IbroliUy+EPKIgHeVENFIhYus9RWogpoW5aPqW6cj/IchEFXWW79sxy1eDCxtCIA8whvzho9S
1ZotVd/bKCTtlgPBE1vhiFW/UY6cczjB9xSRQNcxzmHIZfU5In3BW8epRXKjaDGoo5lzRnGELKAZ
CBVxfbfUTvK+YUF8epgBYxenB4gIukKLpVjCFWy7x8MRYcA2DRcm8UkXfUeCyVgIq/tLHIEsU34i
xVKsEB4iAHIMHTiIMcL7mmXsdxJcIcxo06y5j1EpvqdM1iljyxE7/UKONvcp8SM0SXRTZX/SIVoX
4m+Kx4rxUc2/qA0W/coUdwbasgc9SqF2AXFPMdZpxORMefEbQWMSy5r3EEyK1ddw9ojLWYSlHD7g
I8S1J3Ea24ezZU5RKU+JYx67l8yJKtpR1EwXcrVXnMoHeKqfKYjyVzLMFXUKLbQawyHZAND4jBr4
lgLoe/EFhZvIQ6eVjgjxmJfPzBYTVlISqRdrixFwZT9cwzoaVYhsVi6bqWIBY0E/ELFJC64S0fiX
Z+ZphQOP3B8QnMALZqqeYODxpa8mxdB22V6hwavI7o24bQ7FteGMin3LmO5WhXXmDtYwvRIs274j
6Lg0Vu4ltxCt+UbwJSrhqXGcHhLgpflN3YMDTi+JpjeCWoCPJElIoq8J6S+YGpw+91FUGHjgkSsd
nzDSPOkYxKHWMxxTjGwFsxlYqWVUHjmPX0NL5lmQb1jqv5A3zFFPkLgVjgu9ibXYDj/qbBwBt3Kx
JWWLhU6gWrkuLUxANjHQ2/EscuiBhoTYDggsVlVV/MH0o6CojBd0HPqK7728M2Lhx2fuMz98mpUM
aNB/LKsS5CwLAJ1a5f4yntc36bA2ANUtcEbEuyW89x6RQWIplrT5It/LLmbXJuMQ7kA38w2QHAmf
uUkA0vLK80CytiUsTgMRPLByikg1db6g+qFKEjZTj8wsmWGxgbCy0lgrE1hfnCym/MdsBVba95LM
N8ljuyrOgLgYAgEg0SyoFGo2i3K7hyBx7OpCVQc/UWNPATDqaqii2fpFRSjAfHlIQqIs0RgC3C76
bCbpMbG+b2DAwWYsBkTyPrI4dZNvxGZsiC0XpmAJwvmPKVNoTHov0qNnywtX1LCJeTVlQ/C5zq2J
eXbPgI3FwuxX1Uvi/wBrSREtcRC1eYAbpSRH0RC2VHNe4oSm8cfUuwXAA/udyCOt5GNKdhyMFbNZ
RfxFzwl8BCXItXX/ACN7qDXr0bOLCRbdvlYOZKtB+eZSVo1CvrYDqWmBvy7Fw1bV7nPwyO/mcoMo
1SXEjKKF8vM0Jbb7QfQRLozxURIBQXSNBJlh+U+numn1BdxhQK/Uu0LatB3MF2CU6EWVAa72ZCg0
XmPL/EJbH1xUWu28uEr4SJXjxO6ta6+4o1whsLVHMdlC83a7i/Q5c3jT4joFefqcEOO2O3qdyWA3
KpUnqCfFOWArUvSpRoL5my7i8CiwJ65SklLkx6YQS4zAnDXmFGbXVXAJlA2E44hbQrXu3nYABxl6
KxuqvmUusgKs+YxxbUU8MI0aFK7cLUo2Lbj4jI9wLyeIWnVdHEQs9kba1fEDxjGojeG5UsLW4VPm
IDjnRxAaFRitd6Ru0vNwnS1ENhldxHjb8wxS/CMFDsIxklVYFbiWAcjT+4ymjyeIjeVXaVM07Khl
rniNk1EpSFyl68RDxqJWXdZzBS3gJU7Z4iMurlcvXzG6ceY0y5Q8mIEHEye4CtxXNxS1BPqVLrfJ
EgwKuLUtkeSku1/ZAGkqtqAtXEUF4QWWq2a+jzFCJqdwqawjULDZFDimIOQGxljAQhat/XUEApmr
cJRTz1Euino7gveH1CtHYD4MSwjsyrepZK/iWFRx3EJpb5m4bcvDEE7vIlVfM4X5iout9ykqFe41
pD3Lv8fEDvxzFg4rJXOyZ6hOXHMD4K9RCA5HHEax+4tqNMIAAV8ztn8RVzk5jUHAQFFj3EJoVTUx
I/QtdWVTXkrGWIrea59ykJFgvJbgeqVr1BR3OLX8xAmPYoy1WxysrA1NG8+IIYrzfIQq7CRN25t0
kpA5lrDoS1NlzGkABzTs1Q4iEe5bZjBBuXOCpRYb3qFBcfiUsX4uLh+4gWN3CyC7l41oA5g7XL6y
VzbORcfDFgryNja4YuJToXkxB+ExXzVy1lis7t2GAqK2UsK3Slwr4gCErxo1Dsfk814qAB2Wlj12
zRtGSPkRlFvFJs6y7VjSgcWkN0btxTFRwkqodxTcZWjfdZHpWtaWdJHeslI7daVGD6F8y7Z8AeIr
7+Y3Cyq5lFgJiqqLDeAf0QquhmSFvKTp+I6FVSvENGzo/mVGwdb2eOCAyb4XgF3LkNtNf8x4py+h
LIipC0Qcwfn9TmeYsxgDAGtP7hhr8q/mJq1PVRcRWVVn8Sr7XcphPWLs0QA1D2iCJfXUoNaWyXCJ
xqMl4HIdzzxokFVoOi33CHQIrBPZLGMmD5KgFVkaojXv4g+X/h1No7IucWogeIjosOYWxgDXJ7l1
bOeIjZLPbHKXvEqZ+o66U8XUzyR+mEkXAc+O4eLg6aH1G9EaLYfmO9zkrLgANlwfT5zqb6bV68Ny
qHMq46eLgB2Wkx8x0Hb05jAbs5o6jDpInlDo1gyi2qGFoLqyiMpIL3RMeqJqnxUpgxwgSIsb0PKC
38JcyJ2ptO4ivL5qbCz3KSnDdiyIq5Kl1Hng6iOyksDYZzF2QVy+5S+Lawi6N4LENlRJNoeMIWKg
0SkxbpaMEWIvQ2Hih7iHRl1S5Soo4ntiLw3nVwllGCRsVleY2IKu2I6FPdxu0F3iAmrHuuGOVYdw
NA33KrQaK/U3qS7g+IIzDjw0woE1hU4RS+Iw5y+Y16UPUMOKTuMhyqEEe+ohsN9SgU05yCRJAB2w
5q94D17l9FZpJ+DEYA6BwPc4gLVyy4Tghu4A06Rj100cJfL4PmdtWz33XogBBKhF5qOJBBvsNQeS
qrmFctwzqWk8TLGwV+YZy4FECCKOSg8sY4Cu9X3KGLACx9kq6EjcC0Of1FwL1TAEbu9QDwTJHgeJ
+bi8sXV3IG6UKtP/ALLwkZxoL/yJjsem8wOZZRWoeJHRriXqpQ15hLb9QGuKqKVsZB46iQg3AGse
p02q7huzuwitKvUUUCobFWpiyqZbLgF3WQCu7mRUBel7AGyg8S2KIFC/xFQASqVrKg8o5eLgILRU
HFWS2HCsuGqbk1rQ9sAcDYLscMFvj1cznLC7G7cq4I0ysX9Ep40ggDuU6sRq9oLBwwNVVpxHmxTV
TknHzGtDV2U+Al3Tz1k2rpjr0Tve4AN36iynYLVlIBS98yiqy7jsh3jLG7KeoY9HmWeogs4Uy4U5
6isCV/iBYXeYLCY7kdsW3lwAooMZpGphR56jFRQgRuAMOyN1w6VmwUDlgZxG/mbrq5SToBUq8gHk
QfcBIAHNcS8t6KgY7LkSimpqqYXJnInEafDI5gU01U0mcXhUOaj1kG5HApXkioLxFXy7gi6lE1ad
QnBzOT+Ut8GCfGQxQQ9pTmiFCIa+6jLjI4CIMmPHMrAISu0c+FpqXf0LJyxTP9KgBiVqsA8TnLM2
KcwjoQDALA8sdzNMYGDhV0WSljA/cIgNLfhOLCasBeoPEFZDeLiKzkFRFSLD0g+i7UCNesU1kIgF
DI1ao8FxTispyuVa7YyUrFcDmBro5yHcNbbSIhE1nmWi+OeUwXY6XxAYWaEdkuup1MrCiOHSXGxN
OSZrqqzmEuzykOkJzHHiUgYAeL8ygnSjnIFEdNPcNR1VTYFUcVM/MulLau9i7NjR3LjO0OV4qDio
pd/UKrVa2cIELdux/jiz3ARtA/cFu2Ge6iWa2uQNFEqcEt+Rsu2peMKsZRkzyNBXUYvJzaLHrmB6
0nYKaDZft8w65LDYoPGrMcbAGAVzwyu3KurhW0hS0jNYJ7mBSmeOfcQUqr7jBlwDNsspVGfMGiRF
OGV2WAytqEBcSI1dxmyqocCVsTiLFbQpO2I4nQkYUA7O4TuNosxlGMFIgmgDo5iVVOQaxaK2U9xt
EUeS4IgveCNsq0Wvdgvhy2pmM8XVbCYA7rbgSIXcOMKIbuCDksIdVaeosdqBP3BSxQf7hks4EtWD
hEkQaSgUSntwr9xF4IA4p7gTwirvlm6rtoyE2LhaDoIo4WwU+mpgSgoHbACsUO3MMbpzSMICC1Uc
XAyUJrfcoQu8lhBRVWYKV84VLhAOh+CMULreg/8AEtAMoLX5hMPxdxjoAeGWNcQop1ynuBcpou8r
TiExqXm2e40IURajzk9WTr/KDqNxA2v6suL4m6xENNhs1ADseImMOxRT4nBraOW4b2lONVcJYOlM
rzAylk9UsaHGder7hOg0o5KqN66DZnmVsifRXcv3WmmA7ZoEACjH+Ir29xJ0eibBJYct4KxlZPMO
dq5ZJ2/1K2UGj8xhtBxkFP5IRZhXi3ULwIvVVCh0ge6/qKDKtIN83HdiXcr/AKS5NnCXfFQetoDt
uonYJ5J17nByj4K0+ZU9h7mPdYm9lsN4m8gj5fP6iZu9Zh/yG22qF808QyvQnQc/q4AmhhzLSsVF
rIs3fGy4iNj3KQvfMKbRfqJhwgjyURgAvxUYUHqWFVPN7AUjzHBWEcA1EA8xDy7gS/cbdcrqOCt6
mVsrxElePifkOQLB4GBbVWbsGWoX4Yn19ROqFg0fhUWlnPiAKimHmsgKdV3CnQpAIqVbMdwBOa1h
Q0D1O9/EVYhxB1TZWyjjvKWDVeFzW/uJQbdy4vD8wt69xFWcjRo4ZTXu+o5h3hl9TQoR41LA3hAT
iXQVzK7bF358RbcJ+Ig5c9Rvtb0QbCl+YqlLOs6jRfaLS0IDMoMGFG231OBqAKNenJspXGlr4j3X
VN8sO/ovjviEBPtwoBbYeIjLZVOjxP7wBkYXU1fU7iFJidVp9zmbAlFl+C7F11NOqBik/SaZxUJh
unqdygEEDxnxMBHJk1wzT14ZaoVXiE6pQRJav1Eu2ipxVHEoIs+krBvCDv4ha2m+CTSF3iJ9oj6l
FVeGDEtBszyQKrsHT6lglqB9x2qlxByBXtOvmp8oijkx+olilus6ZxdueIIuu54qH+1hBAvbfKYV
Ki/MSGBGiAwWG93OwN7g4UXJfdwHc01MeCVC5bi5EC5QAOS79R6e6gfEL0q3KdQg8RaAZdwoMBVC
DQBFIojYRlq63CoI8eYAAWYVAHIF+JWadU4fU7KQsYGolpcM47VKrwwBcrT+GNQG9W1eyot3SHdj
DirVKMq5b6axGhbOJRfNz5VDu+lVSGTiQ02TT29RODxwPuK1l8lfdRk9IIcy9KTyx8kNHos/cZva
L/cAkoDXlscKgIN9SkRLtMZvZdCMtzRs73meK2/7QK20d8bKrJVvh1F7s9Ry4J6Q8HD9xZxSpW4n
GEsiiK5wDmN3GtpuHVQBfippRN7NkrBiF+WIQ5gdqdU3pOPxD4oFLeYAnKuBGKbiIhGLMrlvSviA
AaopdZOgmQEolwDmjiO07S32c1CCiDPFWQCyBphyXOKWw7css0deKqBDgIFpHkWUMWvuUIwXmA3L
9QiLUDnSOC0wAyv/AJMmqtnAhaxpp0CIAiQDqVqcfiou8yJGslJnz0bQkrJQeZfOG3rkhaSIHelz
gCU3kEdgkaDK388RXudoXClm4UE7RYduw+U7+YroljR2sssrX9SzfLPNs7eWdB0fMtxaL7iI0mK0
SEnlg7bdRgygKmcEKTsDnNRBni5EOY1+0OJpC/3LRXFVqX/U4nsimjy/xHMIVcVZVn8wOx2nLZQc
BqaeYdPCu1y8Fy45h3NrKdtEDBQhKetihU1hyGsCanvavPzDAglUcVkXKqfoRcd0XaGL5L87DyGI
mDc9y7DVfsKiVO2AoHAjiIoNNDX7iHaBLB5hHhKipq/dVwoWDqKtLn6H7iLOIPqHZiKDRvxBQmFd
ZDQizSdfPy+Ni95R7YvtQcF8w2fJ+qpX3qNu94/EzkpE0O75gpLKSg/tCBkiytOUrXrQzLWURcWU
VGUhEYlao8xnmsZaL1tFrd2xEGJ/DE4Ibp1Kcl+4+Rya6LOZuKvzUQK7XiJ7BiYLsuzYKN0EKjL7
IruV6gFrCbTdVL3Y3BbbEFPKKG6iedbCvWVDvtFdUgQt74lNqBPMKorhkTkXKKr+YtDU6tVLKPbm
XcVd8RkDtO7uHoNliO464/EVt7vdghORENZFrQINGxTzOmp3HMBPfkIKyuK4jfghuprhuuYhYBAf
hFBg6ePJKLUWRO5Tz+YQs3cbLDuNGqlKfDUVRew6E+CFI0byCovXMUBbxqFy9ZVMGSL4gVgR1GGC
qlFFL4BEZ6YiCjI93n8zqY3aj1yNL7Iye4KYbxLNnNP4ggcO69TVQIh83zNuyl/U0KKh7mpRD+zi
GwALbYsE8y83GC8shYwxol935hbGS6xqosD6Ze1W8wA2FIgtKKbLlDjuIJseqjYB5hQcIzYlMDKa
wsdTZU5IEW7fMyvxf6mC5Cz6laglsdnTQ9os9NN1UodaWlkc5Fl7NmN5DXddywDBbfiCdRbQsMaU
q7oxiFh6MqFE3qSmc0npv+paEwRfZF4wYOJBZEhudB8RCGLCLFjO9bzNEDeu8i4S7byoiLeCKw78
s4IWLwDYCHTCmvmYYjk/ETE20mVOWY9yqgB5UQn5sAAt/MBm0FqKYLVzSh1JbVuQOx6W7NisOBH1
IaP7liec34qMZY39zNn993EKC7v4mmJKLcpiKdBWpXDaX4IjdDxKvoRDRACF4XyATpVfWSu2jzAR
xXuhcrhZs+thByBfjYsWaIiitpfmLAH30KKOONKYVvyBI301nOxmuQPEFLhWYe4mPchv6gKbsx7h
5NYpDOeIOZM5PiIwlwHHCuRAp68RA447IWUDXxLzXMfKLYYWq9bKFC+iAHom5Mok3Thj3QVG/EMp
YbDxaIrKsHmoLtKnetRLftPiCCTscCPd6ZHI7Q5EAx41eag17f8AlCrcmnGVDVw/dIdKU74tggIq
N9BGgJWXktEFU2p3VFMzJxQc65Kwi0hbnAx1XFFR54mHMEuuxzfJLBSy41MDhIFlTlfhi+O+3f8A
8iZqLg80JAD5TA2rjxgSrrqLx0q/P/iIoFfpZ/yP4qN8ItqGs8Yf4xRfw11r/sARwjhJ5mbNkjt8
Q6VoY+3X8w1DwLo8DiaWZb5gEcK+YAniw+4hbKDXm5Sm4SL1lLDmKa9ZLBqAOVrHv0fyo6LedYcx
lB+UoipAD1ZsquIKX0n9yrdsU69Q4aE17xHDha9O5hcSqAOMj6hpr7JQpnYcgZqU+nU2eOp2wT9C
tusoZa+uW8LWEOs2cWfxOMNWrvTiLxtlDfglkJedTlZlCBmxoeGFhWKfbiFSyLvvpCvn4WAlG/iA
EkNN27UYVYd5TEahlwEvL7mroW4OGA8oUD5hDZciuPiWYRGADwS1iWhhHFP9R7CB27HxBr8mTemP
uPiDRTA83xKIjC6t0e5YWdNl29+NiO0QdlH+IKb7H/8AjMnIgUWfcNmlo/A/7Akod1FRz4YWMgWg
DAGCQQ/AkZ+thOl+fiKzWH9n6uC5oPevEYAWmUWslC/MslfljQi4x0pyxp1soo2qAQXKPh57gaLP
uPAYvDXkiG9JYrdYvtuVoHZhHRMw5gy05RwR2c1kLLDFsTlqpSwr4IgDh5h8xA+/UWjHI16KeEnD
XcAJtPlj/QiWFre5ydxATiUo8TSdwllZ8yxnfiIsEuAKFqOJxCcnEMYcuxGwpJyLV7Vyt2UQjxVf
qKFg1/EW3MvxLypiqhNgKPDLKruFLqA33Ky/xHm7l+BLYaB4XIy1rvKigB0RWQ6QDKq24ziiquNg
V5sNPmHxENcr3LxrytdN/UA1ZEc4lu0KjlkugAefUbYKEQ0whwCqVOCiPZA+BK1cuuXyWQYUVmO8
j3dXEcaLeWVUoQvLXxLMyl7hpeIYyTTfDKXGWENIOyhAhMI3wQb9xqAT2sVBxncFSzCU0Hlk3K6i
X/CFgJxF6+YzV6L7I6Xtu6lXK9/SYCO2jxUu8PQvl4l3ZuHio+GmLaKZWSNl38yv6OFxPkBdyoSg
1NyEtS/fMFdN26aQ2Ak4cLDg40LzkwpWuzM5uzMeocoKLTMiqSi88x/Abl3cN4RBa1zNeKuXGyoi
HB7jJWFXc2M/axI1KRfJxFFAWV6l8IPlyM1ku3mNMUS9Q+fYHYjCQAUoXI4WiEqliEKFfnqeZiS5
z3lWY/YGo5JxaBA6KJYDiM356tremMSoswwNByC8zkZnN7UQwo2wEMcK+YWZ1O7lrw4RWRq0FJlS
XxsyvRPD4jYsmV5fmXWFBb8xPEEBWqzYvAzobDBOvPuLCaCglmh5hjgGnCBiCLiV8GZt2wyM7jP2
hUAmnJ3jDdbUBfDWgOYvhZWyy5pf4lao57j47eDYMOxxpM1tfDZkMgN8VjKDl+nMGKazgpUp/nUk
owBovNcyvNnLiqIEBYLrnnJQ42Hoi2GBfTHVbFCUy53UoUBMeEaHHEXFPGrqArdAXkcMBZ/4iYM5
dnERcSJ69QogiKrlDUwXwT8+YtZcsy9/5KIwoX1xKzsoSxC+YEDnzbG13QKtyOxuXy9xJa+hn7hV
IssbHz9QW3cl3+IGEqp9oGFozOXA2U6FNIseYYnW6ctRVItjPcxoLD9xs5EGuIdltsEuuIwsA7HB
ty94BKkq6mBMXVLZUQtiWNdXk1+gyVXuLix4sL6lSQ5U385GIRYHB6icD4IZmK6cQ3lSl8PZcPLb
WLIsIvBX5ibxi38n6qYiFU2qa1caDGi23dwXaJUtv/kSoQWWKTmV9pItumw5ysoa3y+oDzSvLhz+
Cb07QwFcTAN76sdk07AHt1z+YjyOKNeJQAdQKCPLCEHPS/uLnMUjHj2zb8z0GxzEptKwsfuWWxcW
13KMIt9AeAPUARwVBSdzGidJrwfErI7KjaIv0CDNMFaiHjyTOkaFdPmJnPMy7YQFgfhvBkd2kUhN
/kjCdy6G3zMoqklFctTnWER+JozGyn9wAVoK0f6eYGdICP8AaYbumR7N7aiwLtn46D5m04W6AHSn
MOKVpVdNv3HyFPAoHWdRKh3ohYU3f1D05hYFcPcdNT04htn5DyrEWGRUWSsZey0nBVx6K6mRuuXH
cuHeQqexEgtgmnEaOZbbxOKtgjLhpxUCPBMjuPcIL5+kCIuZRNrzE8Gr4hY3e8RsT3OLC/MDVVRE
3B5//IF6qiNdRY8qd8E7HebBooeI8i0DTG5nk1F4ikPUTW7+YqtVOC6fMe/FdEvSUs25ItBGeYrb
1kMwqCtqziL4TqVuku+iDdlVWS9oUprieVi3OQ6miOquZdCPMCj7I9PMAOPyTolHtEcjbnIgcbN5
WrGibsoJ8rlfUum6dAzqqE5UiaIuMtXIpgYCheRK825QxVmlOOpaSX4RbUB6jUmX5EsTkAaEXPEV
wO/cvKcoUS8lfoWc24OmSGnqBiVJh/yKDB1f8j4S08iL4UNDSVaAp1LaixUaeZqRUFM5XIA6Rfc9
zwigonfENXhc2NveZQslHkig8GxFolXLgLcsSLqBg4QstfiehnNzjO4zrnu4jTHiccP8yoamavYs
KzYrO9VhGZOjV8x4y51L4oRW3SAC6dRO5ggA937gMBPVn4iJasAvnqCqfGwbFqqnh+4h8BA0q2F8
TQyoDY/c0HzrA/q6HlY8K2kG/uCCoKpyFDRbO0PkwXq/qDKUnRv8xzsGwgzPDhe0HBQyBDJKtlzU
66S5XHwy6vyGM50AbYPMrgwIpgXTYy8+3iSqt4xaSgIeghexNsdl7SjnG22BGEpojdm6jCBeG/EB
D1WJVfiKQjDe7+MhJtN64YR8SOWZFD0R4dfeQ0Q0VTPEKJM6Lr+Zxghaz4IebTbtbCtuybmPGkxA
hH3/AFeIeCGIDq55DZVysIXIHGc7H14lyMOqUr8w8JDuwwU8dsUH/u4ZyDtjoWTvIDIqrk+o+GtG
xr6ZVUOX/aJDfdSMxShOYcfEIcr5h6uOy0RaQwEKHK7csV8fUIEl0sdVGkPNaSvcMQUMXrqCOnxK
+fx5ht+d2t+bj4NUp3H3mAYbcJG8+Yvo+E0x1qXttR6gJ5QTx+YbVSPl5Y1sps0iA6ZeyPTA2LY+
oTK+GpjBnapwZFjTUfLjXWPJDGsxcHx/cVWfkoGKwtKdiqtYgc8XJ4gjaLon8xJYLQt4h04smsV0
S1GrYUH3Ai/dNtHF25TVfTLmhdFdgQ16otYNv1KNMrfgAIu4Y0f1cfIV8vMe8xAiRJ5KD/HMSkA2
rbfm4KuXTTAkXuV/uHxS/gedgYAABr5lmPKC7/UIV+CiO7sVQW+bhNrcVgtyr9e1Pmc9MKFU+pXP
nKobbJ29sXQBPaPEUho/czRWFcjdCFsVgDN3YCDoZY1GWLcj6PMJPdzQBXcBXKeUehlaO/Iv69wi
oLY/bfc4hbzc1RfzAFwoFrxYlG42kFREcGorqXuHCE+52qKtuuI9LlyYAagGPcw1DyED8Gl1EMq+
a0yxaJdtIW72BDDBs4XQAlVw7l+twti1ZW1SwAinHNAq8G/xDjdF0LhhDOi31UZc9dpUta9pYPzF
SdHN8wUMPapSfywYDgvkgoH2L/uW2z4NrgVV50cVNDp1AMDnyzPLZ0rFB2MOM0jl2uJyIN8cy4Wx
g3kOxx4h8V7jWzh4jbjILfnuGLrjsjUtfmWl0y3Ann5iuOLiFlwh4JwUajSLx7hnzOEd8w2n33LJ
jvEqQ8c7BFKlOUx0Uo9TgmfKUseZQp2KgBHF7l8D3bKbjUOolFQW5GVtO6Z/qQWuQygefEXW9OJd
gP5icri8RW3VO4Dir7uL+kq/K/MViuqg60F+ZYsO4Bre46GqgUP27l3cy+o0okzsiHJj0MEAtvmF
VXJsINazkhsHHiM0VCqnXDGqJcXVBbu5tVF54bMOIyNy7YHFsaMKzsjThAr0wwoPCL/EvzgGOYsU
zWuZcnuLS/qUK5Ciy4+4xgNjttGrrY5EtWDKi6rCtq+4ZpIon9S0kB/EoZ6lAyyHtVrLOoG3V3G1
L+CWHQkvS2/U4bX6gFGH9xsmZ5iOSGWvfUIq6/zlLVGq4v6gognHDG9iuDsMYaS/eeKyW35WRbrd
h3IlE5wkBAAaal+tEg5lfacsb5aLUlcaOAiTsCZHigy6TiZV6zKiNjA1xCO1W6SNxm2ARFqpdvCN
kAcYWwJL9j8y9Y3mZD4/nAW01z/8TYAniiDwE5SYoxyy1ac9RlKlLARrkHdQQtE2pSRRDYLZA4Dn
DNPNc1O1BzXuGIlq4TwnwS40pA+ZeLp3EVMtgHPqFNJdrn4imqM5RJVHhKoLtHmUwOrtAJ4NmhdT
s4vqKai6KglvPTGM3j9lTQtbqYBeuVHxy8VLNA0V5lq53YBINhKZX0GowelRf1HhRrg6jBYD3OVV
Fiwv/Zbrmmk30VwGTBAV8BALyMKyvEGI7LqGKiC3xC8uaTtHUBulLNEz7eB/7Dfeo9BGS45bKqNW
lbDeCvFRAlMviJ4UDKOZZAFyFMZAo9PSEqEBwhIiBj+ZcziorE5rzA3Mb/AlCWVZqkAlyLOGvMFg
nahFYIGsPJsUqLlFpXqOJTkHlmQzZT4lWbfNiNhqdoX8QeohzVsPtTikjmRbV73CLgKVfavMp1AE
vMbITR2gSIag4dPxFw6CpGLbOZKzisqzmWhTg+EH0oYkQECN0HnYRVDuowOs5yQ6CjisQsdc0Ypo
XAtGqbon+IKM04t/ERlWSOl5mRiV4HthgCxmlso58XmHYDwIsajqDu8HIiKebvplKnGZBKGdto1F
aOWG/cR15ltQHsiOpyqr0GEWdl0naOA3vn3Fgo0D+oqQhtiAqAcw6+JmN7EwyMh+5xosMdeD/cPB
G7vIzlbSb26IJFqnSR7+paieeIHiKI84REgr4NuIXWWEoXEorPmCHoiVji3qPytdFi5Bu34SxdF0
CEVxuyllvpOmOzFCIaBON7jBlqjz4hkTq5FWFRbD+Gz/AKgODVAX3z3OKICsXkgKmOuRAra3GzMq
OWzIlBnURWxC1fPcrUvNywx2XphjxNch9Qov7idGTk6PMQPm+SO3fcsNaQbQWHUoW9S6zuINMQKO
+4FA25YVWyjhs0LfqU18TIvxNW76itm1uxelkLK3ZxUoDMjt1aFDpaMCr6q4AvuKJSu6wAUq/cQC
E51bBd4+0lF8o9lINTkLHBzEFDPiUHnepzDiIq5vudvLzkpXW9Tkbp4gx31cKw1ddwSESpgVBkbb
T1E2ncXRMIoRrGIcEFC+XzAu8MQbl+IrZnUv6iBXVWs+eq/qGwLZxA2BrzDaP4S9QB21BQLnMBVK
cVEF1kLcUXnGxCuxZPUCgqcDzDlhCKNthFAEIGHKVruJSMrR+EFUnURbi8UlSkgWnRuIzqVQ2ER4
GvcAFVzOMf8AJWSTfrZd2sB44f7hbFVpUuMCUCCFfMtI8zSo1ZxFWbjQrwQmkJRdmqmAmSl6HiBN
J8QMlX6mUdZ5YZazCvDuMBgXVCoVUuRgBJFS+GJnQRqFicGgq5RK0pOhglOBtOJwETdvMJO93Wg3
zDzzVwsQDqlRh5oDkuaqU04jK8KHDCQRpKJT/Y5PcCnaY0FTlmDTASamQqBbaGfEOqKlcFWGlUqB
LdDPghIi1S91LjfTIBZFzkZpfDlL+kBRbI4HaX4QE5wP5IGd9XzDQGj+ostWrvjY0oBeQ2HSmQbc
TKMIOBb2ObhzoiqgY33onZE0tos9QkkOX3NMCWV8RYAVrlC6sbmMF6csZLO6+7qGNQAKTjNmKz5p
PojHAKmBAMdMKvJuiKaho76qcHVcwuCj14XG5NEctczNpU0rK7t1Su4wtXG9uU17m0YW904SibZR
SjxHKVpdlEHvhXjIg+iz84RvJdjVdPDBnkvYCpYw4BUI/wCBBI06Z4OwSY9po/NRoKzGlKAyKL8I
JzSjUdBFcNSqCpAxdXzD1SnYcJ5n5US1GTUa+4pYFQjmPwHQJUvBteARUpvKut4hEus5ojwqrGmU
hoNOFS+gUpVSlg28pd1ZDxcppAilC1kukUWqEfDCZKwV54gatkJtzi6/Pj6m1sMvtDqAGwZ8I4uw
36Xa/VTB1tns4lWgGHDqpbFYDhVjLWtmEfEFuUeceblOhVm4PiVgFwiBAAZWEr1wS/YLUSq+YOw+
U6llpXpL56g+ziV2QKRfRYFY3xjJVHtOPyRAZUSXfj4l1BNLAIzsdKohGtoMmBKyB6WjKfxHOqWY
ek6nB3LeBl6bDen9ZLQmuQIR1p0BYHeRbGuh1XH8zPdzOBdYaEI5Hj7XGkpzHIsAQIBvwX8xChKu
JF5glqmg56/qMtgGefJM7Lwd+4n7KBplVBCzXlX4YDQ3oCl4s6mDjVrfioACkM49iH0NkmnEsiLc
V7xAxi3EUbGjckSirwT1KjAbKGn8wo6L6jWq0X6I/JUVlP8AsAhURVvxOZB2esi8nAJbEythkSX3
XHmLURgGenuJ5YwdHylK+oANNgOxUeHKjJHsFdu+IoLgPl4JRq/Hn3FFtfew5WyVZHp3JRHI6Tmm
W/sgQWLTYmh3xEJoeorgfuOKu5fFh7jpxfiDeOJYh54JthxluzkHUqmfuC+WQKziZHlEssoioVcM
V+0CiYqVKF2Z6mx0O5cTzcRVuQzHnzMnOxlaUEAAYjpZG2CVxS5ExvMAtVwxa3KADGCI6jsUSvAJ
3C1pToI+GvMVySogbTwxYv8AcrQrwy6PfqO3xEsa+IWW3fBBW22VquTApt5D8YadCnxKlAAloihO
mNQXTc3OGJeYXC7G+IGTxArnfhBoxYPM3rMA7gL4nrAXGn/81g5viPltAgHg9+JUU6XPUVpWvceC
9ggs5FMg7yNL5gCh3Ws/DsoBUiP1GIvA8bEgDtEImjZaWWuHio5bCreQuAMviPiNTuwr8xViEfDI
Jsx+iAIodtxKRdJTKS1bTzsel1UHhpGUgKcd5Eegt+IDacXiNTehGL6i+E5bUztrxDQLp8RClEpS
E8O9QNdQELJcainXwWkCoFiRflgo2oHiJxSglyo0taM6rQCBaSoF98xHSsoG8X/MsNxJ5qop8N0X
KiY2OLZCEBdWfUDYEgXK5y5HXDKhSNr8VHDAHD4hBBktfcX1aErHI0SAuviXSS1Q87GNWat8R92V
Ud+ZQNoNV4jAKQ8KLhgNS22xT8KITXjOfmUlMu9ou7ApaPGkuc1H0ldkKaeWAwQPZCPSnzL2JlUx
HUHbdJSjV8VA6cwgoc/ErOqY/qEoDjkGo4CEL4XM8e38QrIqKwbdTVhCQ4rFGEMBvSOC0cM6/wBi
KY3wFy4ttOXYgWr/AAOJS8oiunUY0TY7bhmyNK4iUOIjsI4Dd7itgC08EU/lsKucgASLY0itfXsl
/GCsU9pXiCyqhXQaD1cwCdXdR/ObPuFyC1h+5Q6+4Qo0+4A6IkPVjGuG5cE1X8QPHMz3DOxKOsIb
wNWCPURcg3WikABLaOfcAAAFBRDRvmekLjLaH5jqPj1RF6L/ACJWBA07O4zXWHviA+Zl9o8EqV62
GIFynUFiVU4V9QBx6gypk9Z47gFigDaBu/CEN21/SVCNW8viE2nP66IhmkaayAGvIP6nUe9qeZcV
lQU3EGpL1eD9MMbj80RGxBrlbv8AECVcCbFCvxK2OgfBcBXCBLPC/FTWwimtBDVE8iP3GlaNrX6l
bgVRaaAZnBjSo4ADc1MoDxR/sTd2tsqnv4fiM4ne4JteG3xsNwwoul9ywdVL5TZ7rYLwqNfqSKlQ
vIBdkzVoxLdrA53zALbLFXg2EE4qQHn9wwmhUWX6ljG2ufSBsdTk/cFLhV/kgvQZoa+4Q0OTm8LK
ivlCRd4/cYVQAf3Dh3c4s5ngTKfMboULeBhrL1DAWv8AUShWRyWuPUc6gL43q+ZUw806qOjjNIyU
0FxqdCZg1Yb6qcH1G2PXcd4h6WcPqPllp7f+SnrNoMd/cGUwhae/VS1GFL1uFUrkfCcHoPTaIvIw
DpoqKUDLtdRl4ovcKoOpuQKmGV+pWCoPrZT5NrV9MHALkTiy6j29A+oGYVNgtf8AY26ZCM6hbna4
81AAt4yJyNuJTfMTJkKIBP4i0u84qJSCx/UF0CoDyY0SoosdOLh15OG2SumkuGUROHEVEZwsqGZQ
Qob59RALfxHF1FvFKpriFNt+4oko5zKUqjJRXqWHB6mIl7AFBnmJaXHiAAOfSAgoDzMCqHuWUrmW
vU1ebI9FRaNVAYKcqDmKuO3PUwfLxLGsqDCN3zCxYFdzYtEbE5FFzmn97I26v5hcKLKmCliKpbhu
wFhvUGl9xNdg5gllo3niB7J6llc3yy1Z5eJ5OJQWwfE5bL8P3DYZXmUu38SlyrfBKAY+ZQR0nmPQ
Ni8TUpfUOBS1vqaTteJlEBb8MrdVH5gYbMDjYwHNFOoq2opYPQW2HmBtiKa+bgJaghXiPC1z0EXr
0j3EwCfwIohUtLwv/stCLVvEOC+VRgA5J22QSwhP1HFvyjCxC6yEFMQjjyyKBVXNmImsFhXPnxKQ
pw6i37RHCJVipY3gcXHeIxedlHak8GVDld5j4WOVydk1gOL35qPnKkKlZsiEq7XL9acfiEbIouvi
DWo3rqMGFKnC3BODb+o3CgqQRXoO1caTa7F81NPIGmfmEfca27oo4htgovPEIC0UT3C1FC2TXb7t
lRgNWCs053YhcROeADicn5QTiNaS3WBheAqDeM1pOxRNt1ALgAWP3BVcAqEeglvzCJHp8yya38Mg
pLamNg8AIBaVzAsKsfe0MhwidPVZGKW1dSxgRtv3kqVCy9IIrUYjv5gAh0ta6irYQLY3FLeBto3q
G+UvZfllRrA+WwpGhp1kx8ulD1Alaqx5r/YEg/FIKQKbFSwNNfmbPzZDHFQr0uxtQbnK3Kmoq3rm
BWsEFjrhZA4e4+aqge4IQG48eiXmBN/UQDk342PSzJ42e4FCuWqgpuiVGqW8n4igAjX5gpC2HlqB
ilbj3kEVlFlGEppzkXEp2/V6XHZuLj5Ki5BZsfML5aPcp1eGbgjYwvt4IqbFCj4v/J/9xwqKKrZ+
EDCOFfFR8AvWJeyoVPwlb9a2HUBylOiMvNjHgvWNzNH9D/Ion/YHIHwEyL+iZyleiof1Fi2XsTmY
jBoAIs6iLPcIfj8aRzLXbrX+46MpHzsQSqLXklaBtmj8obfC9P8AxAaO9ovduG1+OR5c38wHDhtW
mYzQuXCBaA7i/nPw5NGIU89jH5F7rl/cdI1BSqGrEvaJPOwMIaUvGsFCXfw4XKb7/wC8LkgaaiAb
GKTvofmGE8ErpfLDmYYX6CJfkqb9RoGS2RwOZT9hsx2+Y8AjQo63/sdI5G/siDaEsW3zEL8Hkv7u
IMb61FHD4hBmIzcGfqDNElPA4CdU8EL6CBTLgWyh6fHBBy7HUjWp5iKDaLo9Rm1VI4XzKfytq4+k
aZE7cCFfxEosV5f/AKg1UYnbylrgPFnnIuoHF1dGS4AakQPB8w4IUeUq75Aj17gthuB4g6lCq6hx
lj6MVka4HhC3giPC2LYbtxsrymFdH8xoRrCk8hD6NABqXv4jbEjW1LubVXaL5hCXNKujCUe8Dr0X
GwoCrBQYxeB1KD/5UF3SPouK9QrnJ4isyoLcFypaJ5USiukXN8QLhxKoHWU6qHJ4nPTZxS7i9HUG
4Xko0LqVRRYDE3EVyDrEhDbdbLBnPMOHOYlxjUYebgle4lrnuYCqGIMe5cK6iDjI7LSmS10T6EiB
U6ybPUQbcMsFpsAsgcjHzAVVSgaHX1EoBquSXD1C8qxlO89ROm5zEvG7jal1zCuBpLgdwabzEUvX
zAJ7IrgefEK252Co8kulnD4gXN3uKuc8RVXh7lpjfiDASCge5x7XsMq+YacLuW8kBUXd/qUjh8xK
A7cSjC+ZwePBHRmHmVoqDWB5uBS1vD8xQa6D6OZntIfNvUEFCPt6jGVIIhzQW6hyjGXDIhC5BG0m
+IXX1CuY4cIAesaStkpFRyzbb3ZMonVdJvMLT07CSF8j4jc7FJLqyWvmZLa3HtdviIbx6iEN15nA
77lv3KDe56mRoUXNnFRWNVG/BLQ1I9WQ7+Tj/Ztci+WpRuB+SBAkMOB4lZdTirCG1WAvEulpaHG+
IVcRGc7JjypjbZTV13BraKhfELQoU1KlACLVQ7wRMKgAdjSgqabyFCCBcG9wupUbD4j5gPAhelsY
2vuYQXgxgoq3YEZjA0cUFKFOTs8fsEQnkeBJXeunAbA9PaCUUZkAXBKU69Sll92cRLqbxP6j0cXB
9SlnS2nAiBuaFlb0oLl+F4O9QtYF3Rd7CTsau7Fcr42oAW4gRTrSGGP6PMAoiFnB8THwvGhmAN8Z
kyQLQD5hFWcmz35Z1mfCtpyXfnl1rIV4MracTxG5PuF7NBJejNcICmt7q5VboWLRl1yL3B+4Ayqh
5+vMSXopY+YriKV2PxHoUqB6Ycp3PHsiJwsgv7i6QgXMJTNzHiMg5igSt6ggqkbI4sA3q0KbV51x
4lKlYDjbuD3xVnD1zElImnB9Qb2XQNvVynFuaHHfUMu0cCMGghEUvXcZLWEbex0/R+oQGNiJuHxV
ovYr8RWKXu4S2MFi797MZNbOC9i+gVgB6uZ2M6+Pi4RYKjYJfqb6NQHD4DxL9hBq5UBc7gGv3A1q
8V3UrQ0gJs8w14cFr/EAy4gjdSlFzlu78yrNFBbT38xdgrYTAVrNvzZzKTo5Gz9Q+ylBaSroyp0u
6iHG2G0BkfYUKJ8nAuPQHqEatNLB/Ed8HF5jJkdEAQEsmPaJgBXSwlxqQlcRAxMsr7hL8kJlOk8L
6VL28V8qW+fmVc9FK5f4ER1wsg37mjAN6R0chRt14iDP3i/MEpGhqE4Xyuf8R+Y1R2rc/cAlxAvm
pX8gTRbGrr6V4fEHboLcct+Yxwguq7COhEdpFq2lcdwdxQodwAvLqQfWxxrZevID4g6t0m3k2VIz
kKnr5iwbqFLiSmS+YFtXztDSmBtfrYcv2ApRfUBQhxo6K9Sws+1G/q4ANhLqlPLRByClPau4muie
6L4IhEpxhFThSoKjNaJde4l3Ipot2Vly8XLrsvcLWuoPJzRcSvg63ZC7ZVXRfGwe7kLp6JevEVpe
1RtwPgZOWOC2u7tlDT2FK+yAEYMz6UVkM7Uaq/7i5FjiKJfQ+zE4StrdiRq7J0c3LXeKhbahiIs+
5Z7ixTrxB33G4b+ZatbC1XmG4kEW9Zb/APJTVqwmtGnxKAGIE0MUI1KHmGg34nmjPe30xK2r6lHH
ME9mKlhb3LjOSY2cwoL0uziuk9R0U2MuWcEvS3j1FHpCmItGcREuXwPfiBjwlkeoRfUQCidzjxFU
5kunthFaLQyzMv5ibV16ii3Uex8HPcGjmpY7omrkbOoS82QLv8EpYcwa3bGjcebG4U4eotdSiIJT
kUpr9wCQ2+IlULHqOrsUclqVnhGbEOKYRDnV9RcNU8yqzQQosdYUYbF5ANMBNLLES2u46li4GAbJ
WhaLXMGWA8G4nFR3ZqpU9+eo3FVxTLBasR7ngSqXxA/gwcy+mvUOE11c25gJUQ20eYTh13CLPBB0
XQytgm8yrUJfURpYt1BTbUopbyJo0lODfESYRFOBp8zMUFW0g76jcLiBEZr5l1hb8QuD0mEE7zzM
KtyhE5ntNlzc7D9QNBufOVwR6IGg++4SXa7MphSN9aiXTXFo7YBwxMKnUA1gMDbE0HO5HULYKj+J
kEr3I9e+9R93tAkfzKRH6Co+ZbPPbKWanmwJFWcqlOk+RuS7ebWowOeW9nQxYwxrmqtw6jXhoRij
U6hRjHKlyJLCdeYFXVxNY+SKktWckhjdMCdRpKlJguDyJyxrRpglycjYqPDX5y7H+y/zBwgei7/U
1kQ6IT9zuyTcxUWrKqUSWi1/2WBQrbNg8rbwTYFeTSVZPRbIvUm2eH1M55QJORFu2j9Q4HS+IS2f
Ox5PBYM5xT4Y/X4KuOG6WN6nYkAjtS+a7VLAwR5Vt3FVBkxz3Gvwyh/MogEBXutgLAeQQODvMp4B
7opgejHgXsIEnpKzSBZ4ldcCmP0i0CpV8LKF+2oABYyogoHpZM70ZhOYNeEqMu+2JGpAhUYDLpl0
gwfH3cvHfLdfzBy6ypP3cAnn4097OZq1qothTMQVBAnLSU2WeJogjiL+5wGWmi4NzuQtXudt7Nlb
F1NLFHEYti6D/EKuk2lsGmacQEPVHbL66bZLHxLQHMDlHQ48xUgmG7GFgZoiudPSp23Ua2AWaFux
uKq26L9l7DKCFeNlhR4k/lNuQWZPqb8iyqp9RwFtVOJcxPHOIwQLe6jJEry+YMDXUxtfD7l1Bm7t
9xYw+VVrHw6+ZQTI9O3I7YvYj4I3gKiNKpit2z3L2rbqyLTa/XERJkAO/cFPZsqhfVxQ1OKWLOXt
0rCAO+OWcFr0uwGgfZxDw4aCKxg6PA8rE8pq3b0w1gVICvnzOOpMFzHKYMEsbs0iVxzHUY1caGrt
5Y7RoOKuAk2b6/1E/G0A1+I9g6UaRrptYJBqgOiXFO/cPzxqkPmBzKNo+SCUDlMz3F1yQoLxjBmF
Ui/Gyymygli/UHXkmkfKOnU80VucmN5nZKr3cYKMhhvMRay73T6ke4sfZAVVxsJcvfNSnge4gIO3
HF4gBpxE2cEaPeU5XEKShpILYWwa+p1m4uYTTbEU4EdcbLDeBLGVhFLc+JmrrxFHLGGzvUFDq/DA
lNF+ogkz1GnWEx+wwGheyw8ksL6lCo+4Ls/qMA4PMBQpC2pgDaXUVVrXZFG18SrWsdkVU08wHw3z
DYZ0G+4XQ5mOBsSn16lJKuFGMCwtlxsDoSnwz0BiLATzMW30Io34NRAIoHDAFaoTqNd1XcqPdQgp
aL8DNlbgRBOwWziFytBSVuC0Efgs8R70EJV8yBIItCX1HYPpB4PSg5hMDtVFsYbdSuEVeEWsgbmF
uyC1QsoIiinAg8Jai5SpsOD9IFCYlthTF6NmbuMcVLjbHglHCBC7i4tPLCx2uORgR+ZSPlByZVSB
hCFTQXCslNChJ2V4QjClmgqAgVhDu401Qy4Ag5WHEDPkA8XsBdYOZTqDCEJJrwIIOww+5sLxWcwp
iF1lT2ZLrmPrIHrqAjWrDmFjjkKIc0Ggsl6Y7Irba3fQlsClCqIsFloImDyYTUrvCAK70wa5BxWR
WNsZWVK7TwBHjypU8wvp8pzACi4VrEukWUQUuFPo3BwzS9CaOF6Q8R8HHuCqGXby+IS17nCPuW7a
YC4VVHcDIMjdviIbt1qsOc1VTlhQwB6itppgk0gmUXDpjHJZLGqYDmDQDri4vHPDbL+m5eCcyTlR
ZEsz5k/UDvXgLjtbwpLD49CM9FOhB46MuId5CGko0IKrIg8gCni+ZR6jwPmIqhYbkQaO7Iej33Ls
rqXCNggNYwbxFth6iNzn8xragKLIvQ2simgFtRXsG6Us7IZSOhvBC3D0V7GPQgwd8wyS4U7imvVW
RNts4oqXqdLcMQBDnIJU1ekCEfCLZcE/UjbJRfPY6GDkqohWRoLU+IvEPNQoZEjflD+IyKCALrIn
y2aZs5SDViZ01wLuuKl38RK4LhgKZ/D/AOIaQ5eahKeQRWmOHDm31KEruc5ZcADlCYo8GmwI/aia
uukGvqyOrbjF5YxeQsPkeYjRQAPiABIwNrgISx4fr+3m4KeEUlrqoQ4aC0hAwXx0B/iDpHC2APbL
KPPxCkKlQpatDwHL9QucadCoIkhi5zM79g8Dj8QeBEocLAbDsVpFdbjTv9S7d0Dm5ksmqYwKV26U
eZdshSoBhDtS7pwPmLaeGTg4JXHvBdLdQYulWj1GmCUcr8QFTGm3vxFlJbjQ1dcQWjVeBzv1A/N2
oKK/9UvFoly8b/iF2DwKqFhNoUFvPFxS81eQ3Yr0KdLf4lW31i1Sg9HmPkyw1R8V4MB935jwBFEr
t1Cm3vAHJEcSwFUDtZwPLwXKU1W2ntL3CoV21BNR6K1uCvEC6jhV05N2oKl9MhwZpNHP3BF1Nt64
SXYP4yO2QcdK2X7mz4IgpXHqIOLiuRVxtE0eyCeccpD57GulVKPLOZ4lTzC1fUK89soDzAeqWCqu
Y0oxED0RHQQKWVtS1sM3JyeK8yvX5jz8ylruEi63iChgs5ReuJSuNruKjTKiCBxxL/mQb2xQTaYB
YS4csh0o3zEUOWXKquSBEYwIT5iOGSkFlnNwoTVwBe4vAgp4nkaCD1kwuO98ZkqxV+5yPWELPHMb
WkpQFPcq+qO4thLS3NG5XhAVGsAFWsNHbewABS6jFghAwXbwThwGWz4QKqJV0SpYeA+LqMuTVDn3
NEbhuQPEfihqfxEknPZtzk8IsCUPbFnUH2JKXtLl+r4olTo+kfMIrhLD9FtQTmLB4hQUn7vMUNzv
VdMcoWAr1OJO1DHqVteYlKyX/wBUFaGdRLCVLULFIdEyb9snLgeoaOaSgcUQB8ZQO278wSYfZ2S0
ZOVGqVrSszgS75Q+BbxOa0Dw4baU7qY/lo/97nE4aLZY0iFwxGPwQyAb7yV9oxtxvcEiqs+4zb14
6gCFu7MO9AvItg8vSpjKoB9TMTgoPU2GQjxzLnzT7yD2YhMuMxyUYnNxAt7iETteZaCC0agIgexI
ccSOcl7BzAHWwAAUMItYtTnpYAhcsfWQ0cd3ucrUhuIIC/UbVdAGXK5mAvnIXlpgdSwM1I9rgv6p
/M43xpe4W9TCk7CJYYNNRtx0LXGkrbRM9bW5nKSlLHhUvSW8D1GSNLWaZPMDAWHupRgvV3WzjkbX
piQyqWoUPzZVUPQdpoSqp0LS0sNTZcCoVcCah5V9wUo4WDj/ANU2DGD5lC38wyo3WSyvnxKG6wik
pjMADUC52X82SxZSdzknQPUEKdDgxzKehwXL/cvhG/CO9FVGbELFUZRN4R/cZh0sRYb4gVbGz2RB
ROYYMMA2rxzxL+Gre0eABS7cqk2ytKSz9yiAdY77JQlHuxg+goYlAQKUeO45Bd4HqBbTHUK1LBiS
br5Rh/8AF2l0VR+C5srrv+0fYqCPjhBX/o1HEAWe7thfNbNiCKVACVOgf7BjaI8kw5KXFw1KAA6u
o3lqnmBs1mwfcNN2Q5bFqPzsi3NY7ucP8EAHE+oWhKHGcMJXTfTkQgBAtqWeIatv4EPIKeJhqkv1
AVcXHgpLyh2k4lCDARjAHtanKdfuBrAhnBdQOre3HDHWmWDi9jKuWXUBFKnATSvuWmlDhVMuaylm
nJ3Kc4LAgDfpgNTCxfjiBQUw+S7igVdXa8f5ENsAI3xcDcSgfFbDQvxBE7g90qAPq7gnajprctlm
Nq1XH1BBU6HDE9AILqFb/wC8RiC7h0vxDOLB/d7g9Kt2mutR6E+l5KD0RRsSCKElMw3Oh4S8TMVl
BYVI5jxzlxMAQ0bHMUDwtQOG+iUdtwusCnCj77gHNK0VbCvxDpQtp1tSwUAXvwX8ykmUIV9kDoBR
08wAR3X45f4jMslLW0OXOlSPgFEHIhqTxcZoFsRKfU5VUsp4akEK06ywVvmN9dkcSjULQnEdy+ZS
tfiMFbKpyXB01GkLuUQ8zgCAmnlhRvZvY3fU4VBlY5ltst6RBvIy8XhC3KomR1zcxbXPkOYYass5
KcfUsfNSgNCjmVReAhRuUeRH3z8ygFV3LJ5fUYjS131BrY3TzMLdPmWRH6luTHyeYDjptygW30VH
YqcZHVwTKicLa5VHgXkE3LdWfEAekPtOAuDmWtpGoXh5uEV4eIoKOb4lmDvLPm/EApGj3M2rauOZ
VN3vREjouQtt8Z8zAwnmUNV5EW5ar14mbxTUdtWtQ94hKDk2+lx7IIH34iVNRZYPqV4rZUZr2qJf
9Yh6LnB1r34lmDjzB+ObtjLs7gw3NcePmHbAL2ItES6H3OSDYvs2InyFT4IbhpsRd45uO5puWhcs
sd36hscBGwvNgQOTyw0w16ndiBoD7iVVTd1lh4ef7lQAGud1x/EQ/Fir5ilgROthPIiTyVFY3SBm
iqr5jL+vccxI4p+HJkgV24cOY14Rgt439JBBcQIx61LbS9wwqoPzHnfX+Iy6SiXphL3h+hOey3X1
FSF3pFPSf4SoiIVbLEH/AIlvLqq4PEPDIQTeIuRChEQj0UTXvedQxKbss9xA1BrNbEA8rjf4goRe
zuFgwdLcwR8OXygq4KhB4IPJAMcgJi9QTDSP4h+ItH0xKqiuPOwvhC19ThyItl5PgsUj1GxxflnP
2g3M1wwhWBfF7lpCBir0Y14QKeotpuluS40o4TsjAKq8/wApbpdIOIsQKov0MAcSM42EaGj3XMz7
LaM4FdDYEvyuYnPuoOKIRI3RGcyNkn3/ALKpvFrhSG7R9XGL31KXsRlkPT1NJOZ7MSsUA8xSWc9Q
XTHLlAmAp42CojZedYROaS/ZUNFQuDCKvqOo1icGngnQMifh/wBnXSv9qZTcl+iFUxTd8/AQcwS6
L2F0xY5ahCVk9M89CE6h2mKny0jQoAD4Uy/KSHR429MDJWlj0TvqPdCoKwAcZGayuvfiWo64H2nI
YK/mGx8/ypYuU5XhqAI4Mv2mQ2lRKCbXcFoKZECh0v4QaDAaK7U/qXTQprSJc7hssxteZdylCGvi
BENyu/iWJqHybAoYRJ9SxXwF+bgOlpThwhdNjHSy5QSsOcRAijsnPiOHJL8SpUPyI+Mv9hBlt5/h
iaUF6ncIlVkfgv8AmMZ4IeGC0ctH3CtCwM97Hy5jPpKHdYH7RPtTLUpQdbzD9IgxE811FbAo9rqD
VBK/a3/Uo01qNVHakkWt3/UBxuR89CZf0ezvEucICPTJde8VzzAMi2uFXdkPNevB2vMs7IR6p/yN
HaOA2patWw2gVYiZ0ZycA+Y3mILi29xBdN2L4ETuoj8HC05e4qOyO1FX8x34SUPhi6U9bAHUECkF
u65/idTuaVTD2i9Q8nfxEA0E5VVf3CGoW37jFhNQH/y4FjgUtS+4PhIS6uBiZRGgbjVLtnN6sENW
Tl3gSjuEv7m3WV3OdlkG45JjVV7nK3Fw5J2hvwloF8TAYGGhJ2/CXX1AqPFdsCBEUo18y0RVMyNR
vZbfmXhb2Rrb3BS7pl/RAtbaCXZzcoVu+JZ72yBtd7iApy9waPLjIKQRzmW9AImKsmPSWqqyJVU0
syX1V+ZTWqjdLlS67E0wfxHV3UsmuHtllK2cQduamkXbBQszQMciqb3ghQbNGVjuvM4spEo5gBRz
3AFt+aiFslvLGDF5zE466vqWLvXmCCmjLFq+58IUF/P1Oq92QvVlub8TqLHvxEl4F8xHYypoA88v
iFBTddHcRoy26g107cIRhQvAPOR6mLbH7mg15pxyEEwTIuGU4xB5zZoWAf1LcVzZDuWHSckB4PiZ
GQsxbjEbkvaQTso0+Z/PZB/5gpQrtY4xs4xpnLJYLe3NbYeJoBYQmygwqU8S2fEHDyRaIwYJFljv
mHXBXM0fOX5j3patONmbUjSMC8jbHzNRXj1C4zofEI0I9Ti13DxcN3qIHuD4lmmo4xaWvpYlKL4j
0RTCir1AK+olZjEabQV+YSHUbSWJFleYhxaJ+X/YKLky/iWwpVHIyNwg3Kji6+ILIA7+IG3Hm45f
CsjYNRSiMgGWA+WG8jSiGelxj+5XcA1Wv3CySLHVXKrsFd3kaqExpagHFE/UYt4LepVyJll3LWBs
PMcat+VDKkRaUJlcRgKU4xDwbvxKbVQ2Kq62lnmDqZ3DY9RWWCdT4aILgd0dBblPm0VUHjusG2JK
lNXY7KQVwq2ZCJ2KpgEbnZwHgJVoCu1+47KFabyCJoEhwJxlLr9x+BtVXdQ+TWD5iIS6CpRNdCoX
5j+w9ruGNvI7S5Uhg8V1EVIFeVKyLGXsXLR6eIotGspAU8RSeWdoXzcENtONqAqM9FJDgKBx5Ywy
G+53KuBAF8j2RRROWsI0FqEOfFQikgCNihjYuE5gmqi3bcH5At+V/wAyjik5uUyKypP5hs4NVVLq
eIcCubl46lCtiJCKj5OIGn3hTdws57fdGw+BooNxluA5pBQO4nMqjytcIJpU21Cc5IeCzQQBekqC
H9b/ACmGR6eRTUIEksRhDE3dd7hRTjuk7gYH7qIVIADjYGG8AVyBK6A6lZ5/liy0G9cj/IHVjSYO
TWKvZ1/8lsEr1BWKlwKSlmBr2vJ+JTercI0TRIWvIVC0OhxfGYIdABHhqslBOY0H7lUryDqvcUlw
tWc4xsBBf2QDHtvxHk5hUMuntByrtz6hULuvQuL0Fas1UHvLAVt6nsokClVC1flMO/7BdQwXZw/M
ShKA3jGt8KcL9dwLjvLsCENF8KFItW/cbhMrAo7YFZwaKu4JW4gXXbC+Sha5YsUnYURFahG9Bjfs
gICBCcDCFqiyH3C0XFYWiiZTRycfmEDWKPOym39yL2Q6Viewp0u2Ojphr9xQDQgkphSY2+fO4Qe9
abC0G2rEeD+7hzdUgVXFwECA+RWdviZnT43wX5I65wbW8LFbx5J5jZ1Lpd9S5gorgB8dykyqYJrk
ucHx4iGYTmuuGy+f6TjsPEuCOD3ChtTGii2TX0RhRxEymERFcEUWng5iSELPiAAayaqRsiAbL9MC
wPubT1GiryAZcSlmxY3dQFZKSrr5jlxzzBvNxkK8Qspe4CrH1Agu3LhXnqPBK3qA70SjKsuLfgMq
42bG69ShVayqFeY6YmPcUkHDtm3JbAT5wmjGEEK8ziRuC6HnmVlLogcMqULVxzF0vzDNVFENOYj6
qILbJkW+YhvNSgVniaULPUF0A9SwnvgZdu+enxFaIsszYWGuPcEFsuLbdZ0T5MusuHcoT3dwuEWL
EpXR1DzbHJBN3k5lqB71E5VlfuVniOS49H/YSMWq7TRlgSoihZbHLihHD5gJxiwvzB7Ks5EtAbx2
VVXdMXywumMWd4EkAHXebkFH/aBxU5aihvcwK+0CZ1EznddCTkys2L72W5NB5jqdQYOE6nXiIB53
YIcuSrfEFplEehywcpsHcTsoH1LyJ5iFFIsRhOK3K7nBU81FIvE8yooV7A+5ybkhzXcqq5QEBBEF
PK6+IFLYhNjOPXKwYd47BhhW38u4k0KByxT6BvuCIUW3nMSakCNNO8hSDMOE/WlsHhwqpn6hdLA4
gkYoLSopTxZezXR8i8+6jVsUiRKbtS/mKGzmrsYt2G3TX11LaoKIIZB8yZ5rW/1F5g1tfzK3H9YV
dF4XnzDS4bcVMSbY7JSdAB/nZVBPInCFkpsF0g8EKYf3DNOVbxhvaogvmMfKGd+7udWJJpfu4Zzn
C6HqVtqLrUhqlm2FfuHvx2FSs1t37ghWHLf9wMZTbwjvC5Sx+YDWzTk/zGPAVbX9xSC1hga5Fj9M
aCLrFfW3X1KCspm/EFweV+tRArg7VbhiWtwZOBSwmgvjoEsvHu2oCqrmNRNA6xItKRDHgg2UHBrM
658IAEJ4wXMh03jkvgHOGxBNBlhJY7CaeIKH1YU/qNA3HKz4IWtAss+BBtLSKKi0INoYxRLVcCH0
AGpPzH1pKEv8lFYFlLYeVqOh8bcBOvf9WODOG0wGEgoRT4bjpvzV/dwK9jvtlrT7pLemB2tLaKhX
SZSgMrfxD8blNq/VQiIpGuJe8LQHvzEugp3CJEhKaG5XyAAjl2sJWuP4kM4Rqi5eIJwgMvWCL+Li
3rp0PiUrztYhfrVqgL7itV8bSNqZadROilcBLmXd9/MCLOLGN56Yq4Bk1Qz4jCjcGtsBDe2IfE2H
Rw2Zxsr0ybQqFo3pw2REi5LviYjCvcNooDCvzDau68ooaON8YFaUcTUP7bkalVYc1DZo8DjfIxk+
oq36R7RL0XALHL2cz8KmMSHaQJZYU6+ZT2aVdzEeSpWX9BaHb6hIW6UaQIZ8r1fDAtA1nTOLCfBE
B1oD0v5gppYba3KJTzMV4jcxbLaojsmswJdW3WHV9xK5o8zNOxTS/qnRsAq+WwMhNLdyhwcGp+Y7
olu3N+ZmumCx4ncgUi9zjkOZR/MBMbuJ/cVFqLA8HiDRqkUbDi/sk/FwCbquqhJaz1EoOpldbKup
4m/AxCeG5Yv9QKLtmHGvctpRlpDkm2xKe/MY8V5R2c3KCaEu75IWVn3KDUY5K8xjY+4kxrEquKiq
o5uMVS3yyhXv1KVDTOAri1yD1NLz6lNWfqNuguJR8y6PWS1C2x9QuiwN5jCp74i2HV4rqAvbu4gp
VvqJRoOSlrDV1qwuFNS5CjFQVoFJUelWrIgtzuFVk4l3TJRXSS4ZbwxpiERDasJlaUSwOA7gHNlP
5g7NIBXc7uZA4i1yEKX6gLuzXGW8kMcfc7vFcy1mMhbphUBo1EQAPxFcKEeWNxdSWUFV5lyB1qeG
quDFU21lAUzBUKU6icQu9AXagawqkrUO8H0sTXj3TGTemLKZAX6ZcyXKsgddVOMWd0gLCbNuLtBR
WDCWrh6IiL+iFs3hDuYFOeI3wRwdDA7Ar3LqXd/qcIK6KjVhxA4HYKjdEq0u/qOdENWV8Qham2XD
EAug7HA/Midpt+ZdqPPg/MfPuy54050RMIqsCPRBlFwUO3DKGb41An0qgGT7NiGLJLwohWpDAi6h
tp1M3gLp3+YmHQtzmV/d8pQDr0VFhB8kUoX5CbZuCP7niWC2g04XWiLE0wpxKAs+UgqDxmSrF8zk
qAg1Dcw56IOOIFRWD0HAggRqGbtcy5fWBtCjro7sXKQFsYBCbatobq10kOhKhR1HXA2CcwDbbw6u
BTOLUcTVJ0lk8KuTMiqdE0H5V2g8gegXH7BmBCkD64i5XkpsvZHbgYeKhps7jdFj2IUcjxstAtch
El1dKwKU7qjHetMpyNDVgZKwQeT4m2UUePkgFhBAp2qpig/EvmTdHPqKHoVb+C49O+1ifmAhINcx
QSoe6/uapQvkhs2caxiMvYuvmNjQHKmCSKEy+4tFKdyoDtZzkBfEUK17m+A9pCOwcFQ0BIXPg8n3
EGAEPEm480K3qO/AMVe31KjiUp4TriCTUTkpRPs/uXusuhZ+Zeu2hbwnRiVkJXWj3yxUCztyD229
hA2klhqh5uLWbuR/iLgX75n0z5bR/oisrcJ/qjpcfWxacUaVwwoeTxFpSV5US5LXUFAEObJVBZKh
XzBQnZxDUkcOWUqUPAD379Q2rUgGeX3LhqoH5EDTYQH4lmiPs2FDIlWsm8pTKjKI+Pje7jPTcIL9
jGa6gg5A1h3D6RQo29XPRPjgKwKej+4lxjV0qKDJhLsO/Ud9BSmIilnqG9MdMp+Hq4rbHUUV79Rp
VrpxwPiM0BQ8dRF3Uhf2y5T1URZXNiQMHxD4WYxDZe1vMw1YFBb8TkXALCkUtgcB1zcVFmnjqYsR
SpstWMa0rUvAOvcoPOQgruCRXCCV8xwV+GWdxqmr2ULpPIMQaqpgCbA5Xey9LfqC3EUVhFQjVQm6
8y57luX7jVbQ8QgPyihUxU2+mUPFMbXTcuY8QkRsS2hsuCquV5lhUv6lOS2eU0u9YDiyyBBS4qpF
gpZLIRAgauNsEOBoeplRQHMGrK5hrk+5QLdxlWqq4cKnOAb67gCEW99wRuxhNl8+Y6LHuLkN2mJi
xbHXzLCjK7YpjTT+Yq1g+ItlPBExn3AxoPcujePRDga+ZSqCxgtG2J2L8TSiu4zTmAXehUURmkre
kaybW6wXf3gSl+NlfMN8hApOiuYRWRo3Sy8IlHUKTdlQFVGPj8KS7HD1GWaCFcyr4Gg7gyjM6v6n
EnEhOeJXYGDhkM17uJ1OJqEhvqAw27P5hhpb8mw9CDaXD6F4UZApNC8SXKWCxjwQbqRanUF8QAtW
MKNgpWIyqG0JK/yJBo4nIPBDjX3EzdlTeoryAl1kpZ3AJbsDgX6j0FtJiasEuDssr91LpA71UMS3
K5aOPiGNGLrkBO1BrvzL1yX22I+QU7gwHBSlx7zK+PMGUoU4EggByPcC3BxyfE4Vq2c5H9SVAAfo
lCqICupWLP6xgqLBqBwg4PiOuAIG73mDKaTM5yWBxsrkZgpK81UMryA4nRHaruOhB7qKrgNolbLX
LCuKB49wV8C7T6lUxbj2iUeoL/aFCwuJ5lUN4X8ShTUZFy4of1zA4LY1cN0HLSUE23ILUwbS8L6Q
yLUlL48w6S5coqqhx+SE0QNkeD1FIVq02D9YkYv5h4a7RNhEPDcZaVVA2H3N+tS5V2S5gYeV9QYv
hIKo4BQHULKpGvXMeogE8FzRW2ttZSqRQcxfXXxI7ANhyVjHr85oIAlXx4+4GrTRiVPStvuCJgas
azeQoiVLPmwhujGF1YGdkNy/I2ZVup+AfcyZNK4zIFgG/aJdK1H6hDy98JQUjY1EH20IqPl7d1FQ
tThhbJdamEqtFU4vcai6HJUGy8KIzFReh4/cwfNN9eGd7FQeH1A/h3gAX/MsOFX4bgGZ22F7LXaW
uWV4sB92/wATerQX5Rtzwxe3GSEOAR9z8NYNy9MbwqvUv9AMKLwPqOUQB6ZZPqYL1xCrba5u25XN
dQctQ03CPwCOog4MuIayUoWLygbaUH2hu2UgsGXx8w8CgCh9ytjbSq0yHiGtF5NwgbQVxU38JDq4
CcgUuC1jRnbVQrW5CtB3eyczWykE5RgBYBOViJQk5qeWoxyawZ5J8RzCJVekYWVo5hKpjXkA1+mN
XEVHVxNZi7LB5WO/Ctw7MgCxqhzRyzsjj5K8xtahThTmPBWC8pjNOEbX1AY0lfU7ZgVNBzsBVgE1
Vwepdx0Hiv8A5CE0UsyP0GEN6qKgimzSmu/UsekaaFJT+oJnVSazlnDSF+rgjdvqUq6iPnH8ZsvX
UK3JdXTsHDl8S1al6WfcdccJwvuoX8tOSFs4hLjRlyUhR1gM8gQ836gAu442xBa9gL/YpSYCuZQ8
2CUPPURvBDgudLMGsQuhyUTAnEQFfuJPRiqyI/JHCBQqvic/h7jxcqWHAmqtAgVjniL3yYgefMFP
HETXCELxeReAj7lJFlVAeXMam0+ZUThFLjpAQbpSVPOPc8212xucK8QV4uLXPwqaBCoxiJQc8K6i
1jSwrPDv1LhMrzCuhvIter4INus9TaP5iAA5ipC6gevzFQPLc7HTcuY33UXQ5/iGux4YNOKgHL5n
PQmuN25/+SwTjuWPl3BysO/mD31B4PBWZ47wIQwpe2bvLivMZYdXXiG4GAfMMyAgHTRL2LM55IxH
RR62A7oGmH8EcTBTVtx2OZLQ18zdApr1GFQJfmXA0xfqFOiP3cP/AJuodHC0u/kt8rhkESEGCgX5
hBUNwFY2XLwEgyywTm8sNwczG1r1CyllbjNdgi2olwtDUUi02fzBqG9vtQQisWq4SwvgjhKDbwlM
pS8zqOMCVvP9U5Q8mNv3BWTWXNxi22tyUDWavRG6HQGE4cNvJH81gimuFtmcSvWLVWESClHDsbry
bmVIoc1cR7UC18SkNoCL7h8doPmoYkUU9L7lrVyr6ZV2TY8VL5RUvnY0fmNlcS0oMpV/MVXC5PDF
SlcQbCk6b5mCZbAs4iFQyoY4yUNLyVC51Idxw8fucoIcR1iwBzeygCORX3jK9nPnsIQLdVbXcaPi
C2CeJW+jqD3pbHctSIowm+KgFN0lGRZdhkOmox2i8Cl7CIwNFS/MHIEvBbA6FQ8n/J0K4OiXYMri
t/U5LFwQv5lhNQqrqcH3+pl08BrsnKoiExfUPaxWPUXEWvTYq6MQBAEC9YS2r2HTzLkTLieokCXr
ox8QgBg2QVlBNK7iShFoLYza2Qa1ogA2mrsCL0BusS8IfqMCGhq/yRVPDVd31OIRmjWf9jWIBs49
RBkQoKMIKBJZzEtlIBynf7lYKK14JwgGFLuEtjsBC3cUP/XETIsd11HwuXir4lgNpWPsuIN5tr6h
FtYB3IIq+qcW3KMQBHOmw2sVSdWNxlN5YKW4dNoQeag99ANz3LLXuGvhgUwYxxGVZd+IZ4pkfmF4
jZZyiOmPcL3e4AKCpBWmAQDI4nN+P1KUtz3QXiy6qgfEEOxriOQtuPXEsfCf3L1BWuhcH7QyiUd3
AsKFwvmU8+u13rE/jvxK1WPycdp5Ag08dRSCkquVhmOCgy6WY9eHJUhtRmbezrQiubs/iYBbCPUf
BpBWegmawQoS7u/iUUUoxI4/5KWUHCAf3BWl4H9SoKo1Z+YC1edjlRaXGsbnYCbo3pkQ2gVLSuZV
1SgmLxvfEsNUdAwljfH2Nimq8BzbzOAlXMDwtpG91/idYkP3K3YKX4iE/aBFje4tJ/UL16ljKgpY
XA3k9RwBex7bWbFwHUaqlPqLYIP5mQRZpFrFfccAyA4Fryx4kezgiGtmYVbOBsd825Z9Esp2xwyL
riMVXfJHamdnuFWwplu5eCU62Usq3xEGlpeLEeMiHeQBq7PEN4qMgeIQXTDhviP5LBeSJZTqc0Ud
XOAb7JgK+5R2qrJaPMKG2MA8oHNG1nfmJLUrMic81EEeF6luoChzCjV34jUObmTh2jVtMyNh8R0u
7IUbNi0polg0rzLLWdTOAMqI1FhYPJcbrRDHiXD3fEcTzDg/qasZO7ge5bmqKqyKtFXlxoM8BWTh
Xc0t4usnGcVsp5/KKHGo7C4Mrg6hlg3hdRLKzL8MUBTtUAdRbofcJLaHctW24XQlfhrZSRpZXdIY
2AXXRKVRVjm/EVdwN5jCvAqKwQ85U+gN/EVHp4h0olFOI+CNf6ilEYLztSi9Cz5SALpzzywzSlT4
2M22FUuHQxtIdbXFx4zzzDq8xchyNDzdxOiNVtLzAYKJcEuNoubQ3+Yt8ncFChaHPiUVd090lliW
4h7TSpeR31Zo38oZVaVjHSVw1zUuzQCPDcWEbf0IGJYvXEXKj8LD4KRX5qWhqK7/ABFuQkP4mS6R
riq/7Bha2niPbbG95jwbrfAYE4pR5alQKM/KPcgju8jO3QHJfEA6ab9Q6+Qo457gaXvGmRTBIBJd
ONw9wbnZPqKFioWLCJEdIFYlTtCVmOQaldC0r+LlRBbv4hbti+F8Re7fK/EGYK6uCc+KCBYHF3cp
hXAtrBkrs9cwRigFfBDuM1qcQ9PJs9wMAoJnXMYySHbtjqxNtVUI/OAvizmDaaNXvIQUG9HZQSAI
dVGWdn9bBxA2d0+J5xFBL75jA7C/UXfftnHAV9R60HV4S4VIGfnmK3xyjC+YQeBk7NWO6GLcrDuK
4VGl64tOG8i0OxhoqM/tmipcusZcQRB5b3BRUC6VATqSuIIZxvamINK3gvCJpFivZA1CGih3uc12
Y40i3xUDDS6PgP6lidKfRv8AENFyZ9kBxBaJ7hDrjD4yv4lCaZ11Ue4lqngFcxBrJa8EGEpPDkYZ
QIbVlCXeJ4eYr9gjRdXAGbsQXNt4vsIl4YX4Ur+IP1n+R/swiaa5uc6wtrqNQ4ENr3B9mOhT0wwl
l3MHxOcVrr4l59U8dw3ogo9guC6rKWtXzDEAuzcdkNqqoqr51gj235LyDOjQeriIoC0u1ANAqRcu
cfzGlBaX89THaOADfDECIajwf7G5Uxgae/ECQdBy6jmk+QcTkA6Kuigi306TW8RIMDVUUYf3DvYs
uV5fuCSKi3hXP4l44XshkAmwls9CcC0mqXn9QzGWsMOJZAe9nfvakdEsC7SvLGbQXOSTA4iM3fAQ
KuUFVtQ1svcJz/EXKt42DlflmnqwF8vM02aZVm+YTlnZuxNoC/LWwHbWE4bBO2wYy014jwF+oe61
ujGj5Y9wwOVRbtylu8y29xDOCNtmxIF2itr8iI9bYIgEwn1GuPpDBIC6vxKqIsbXxAthuGix2Wvg
ZY9TVqKsrPEFOuYK78RCg09kNwZbKOI828wXv6lkaiCraY6vZKieUaMiYv1BBc5tvqNkVBE2FT5l
9hqJG/HU1a4av1EMqyM57IIfBHOWJdcxg8EsCcR9K2PruChZhwBdRSXVdQWG9oXXIyWU2XLGXnuM
HiMW33kFT45iIG8gUdkScim+K4lnlXxEWMK25UrTU4CVT0x1hRLNvTxGq8TICuI9h1mtvBFtNouO
gAomDivBEHRfiO5DJTmYFTWl8wKeRyeggrs7sKXGPEpvjPUXu1KSUuyvhFpT6ltCt7mm5Iy+9qHT
XkHdMdgMlmwKYd0+qggtBdJKFt7TzkR5ctVlsdwU4YWTCha1pi2NBorzKpBcq91K5hAjk2DhBcjG
u5aREexcKgGiaSCGG6pNlILXdivlOA0uUG4kMVS7BtwqUorjzKl2/M6RqGqHuA41MGFReQJZG6Db
+YWUFL6P8hHpRaQlZd64hT6xoS+IlC0Upb+4woBpHMH9VgzmJYfdg+oK7FtHEc9NJ4OowZzfqMAF
ePc80wVyDCERxE3g/wAimgHMeS3T1tjkaV+CXcp7inERC7y8e4W4ABZFIwXXUrKjt3DnAeHkjqiJ
UaAEUKtGldQCGD6Tic14JCql36iWq34lqeivhcrjYsOJzFEHpvjueJApHUu7JTLiEGQT38REdq7z
mLeOWnKOgENLeIXAUiY/MXEYsDKaAiPy6ggLVN3Cxpn7g+vkNrmACuieMUOSNT6i+XhRhoq1AQSx
5pXc5/7DroAeGcxGuBsL5+Y5HW+CEtcDqUv2Ct/lBTKhWcEYP4oLfMQFbiV1+ZVYVWCpw+1sF/Mv
mmNd+p9nnDmYaET49w6HYAk9fMqIwDaPFxs2XziJbgIilSxBigY6dXCRsbrK9VFb4UqjcRCbD7iP
DSpdqv8AyVLcWo5D5MUL21C/8IbYfML0ZdUbjsulhR8hCOOU7pKf9nIcvFTlOyKhH3M5mBfiaIUQ
ZTM/lACMmgNpNiHioyE8qCMH3L8lTlbz+paBElTSETypZfl+Zmwjio4/U8+zXS6wYDbBwkT+EwtK
6lddJDa/PiBd6IhdzW6Bah+4AXgCML37guWBBREcEuiyNfvAF/hKR1D0zO+JnQ5y7fmDVHUbRbTL
HCLb9SqIWRwCCwB0KXxcACIL+0z2W12rWBjIAQQD1EheWPQpz6MWFd1cCLW70uAHo8KovVzC8fqX
evwEfCp20Sgj6PuV6+V4Vb6ZQDHcGeLZaaVcMcM6igCOEPi4JEdKfAuPJqg3RvhF1t3jwq/EVYts
Wn5hNVl2eYDExsyvcKdKg1Lx6ynVL4le9ZAqqt7lu2rbsXgEIhRpax4gfbu1TsXUMF5dZ65ijvLQ
L7uUL6kpSE1BF3K8S44lNb31kfYqpV9r7jjMHuLytHVSxMB3K7DIXa29RE6MZ80ESqBnmCSnCVp5
jIBUKPiNsqfM0UY+Y3CxAFFzg15mluppX7lX5jQx33A0BFd3s8TQs4mXEsasZTaVODYG6q5VNXpL
HkTGXjxK1QUQxd2+I0NlrLNdzVWAqANzHpkUPidzj3KKoLAsaD8RLhZEUyrlBCUP1UQTpKefqGle
YxQkuCHwlgDArYYgnt3HTtfEwXdepsNDHwe+YHtnFSy+poXJDGZACDqcQchp5qL1glpWgJRqjCMK
8V5gw8dJYCVE0dqioYDFRxCQaipsStjTxAWXApsRagQUi4Vz7ly5rkRB5OyXaUxrL6lKA6n2wHa7
dQgoS8cXBoWB5IPffEqcKRis9eYpdbvJVDSbGYqMlgRWwWQ4jBIGNTmEurl6b8QNHTRZpv0JpuGB
qdTf6qBXfVKJaB4UtDRTXd8iUJbT3TFRa+eYCtIK1xAyVbDlLehRVVXEUXNnFoottbZBaLbHTio/
DhSqjeCKFBxEcELZRqBeS/iHI4YCKG4AFaZShVnct06y2xgclGjf1FvMDySgWHxLo1zhAJ4Vi4lh
C3ZwfMvwmY6yriHBeRRi7dB4SNgAZdLidhhsQL4VSgkRdlX9y1E50XdS+V3tmSn7ART9RTQxLfZY
0S4qP9dbymqB2WnrYkKzzb77gdG/BxLR8ZjxL8x6FyL+pDiPmBOnFs/iXekpX/U9U/RxCCtdI72O
C0+KloNvBl6cuFiaI+M4lsVnaWrNK75r8QW6OmWH3BI5aBlkKCUy2/EDqQukclJwfRwx6tW0eZjC
xVtQ1WmD9jVWLQAn8UCMSxtub+41ghw7hQyLtqpSD2qZlN5X5j7P46MUH7xIDyJVkXI+235l4J7o
4lm+QK2JCpVXRUYqOd2RSvj3NkCeMqIkbnTi8oBoxGjKmrLjsEqcouI1ggfce6S6KEDYWPtT9QuK
7t3UPjN4Obh7Cstgc5UEiuBLC4seemJKV9ufMV9I7c39QKJcjYnTexApYDzxHeoq6m/mPUZvYxRN
iqI/tnRAC0r+ZSLDMa/mCusVLimJ/FMqroYN0FGjLycHIF24DOae49GmqL5jlDsEEIM9bWWN1E0M
lSvgiqCuN5SkCwEo0e7lOQoKeeIytHK42WJuSSrW4PldogFO5KqD4nG7ldjMVrXCJAZza9RhLcQj
UZFpb7PqBnVto1F1QTG0OUZoH8xGOvfmEqMXDl1GuCXkhZasXw6g/wCulTQSeUj4KdAZMC54SWEB
TSBC6EVrUPcuHylm4Cmlqo+KlQY8+XqLGHC1UFfV8xIDh72Aey8tI4hR9ZB5xcNLEwUoB0i4zy6E
VoPSLBu+hceP3BcJOxqdn4iZx0JVfmc5jzp/qd7sTOxLow+zNfZ4vj44i5wljkdK+mHdmPq3cdZx
HDtTicjGF5kpvRKULmM5hLqFaOu2dIkEL6JrbAcL+I0UvZS7diND9S3FqmaF6gF2I176g7R5lteU
siaPiHBWnc8Xm4mcxeHUQLuWW/EB449wRd7ODL0VdQe8QFbcUsoaUxilWMKnWwQ6NQI5jLoBA70q
viUorzK4SUjt1ALrvTBbOAQxW2ll0rUb1fiIJW6Kg+UoFKqAvy1CmcEVOMSjexuhDk2KmNkAPaJa
WtMlAGwoaWvmUd1GmlweefEs1WENND6lIkuooWvYic5yeB8Sutuc9LuK9S1/1MAxfEQfhFPDTWfS
YoNr3L2n2IIIJdzYOjioy0t7EBXJnEQNt4Zc0o49ytDm4BidzTiDg6gVQ5xrkDgNCl5AlU1hUUTp
QstnlHrRArB65TlfuqDiGWV1zg82q8m1IvpF+jwJAzMFgodjCkbL6eo9HxlGEv4OJe3UHEWeSGnw
RqbCDWuZY5KiWvEbAPknfbucrJYr0xPZUA1sQqoFhkpJYWwKABeOvqWxRrIx2isiROrVP8lsUP5v
xNCR6irA2nlNKW8InMpfEOtIcRyU50lr5oZ7jEWrWlTjy5ThqIVxCoBRgMCDM4QQosGyBEDBqsi+
0VZRsCH1yESDOEKjJQsolOQA9TnUEvxA2CeYnWU/qVFgGj3KDlXhsvgRgy4qgeWnBKG2/CQOSPC4
S1OMGGIHQWA1F5QNajtT2EOqszgrzLapVMOHUqkL0eGUK2mOJs1cCCpkgxEDHAKADp6nLIwdDHSm
mFkCiO4kyIUIFTtncKldYloHI2WygeuoGV6gbGOoSnOxiwihK1rzBxBVlHJDp9CIsIm17lHy+duI
2UDVVCqYa8EpiI4F38QeNEECKpSaVgQqDLzYultkzgtXggqI+BcCKh/SNuhFhNljRijCQUNAoiEY
Q+wuUmsVci4XPJ+4gyNHpKQPY3U/EsGuKqLHJ3UA0SwKu5nQfgEuHf2Xi6gDlKIXQwOJRdu4QrmX
RnCcksqlAKGckQdQQDA4/cscINcrx/MdcY+MRIxvACHyvGujtwUEoLQjBGvXmU78Ba+iIANEcnQL
yy4N7QH1tw2BmjhL54lUldx1W5LsY+SXqWNisGpdrcAp5i8Qwl24PMOoTKW+X9XKWzDsa6/i4XYH
vBGRNQ4LwyiCBaw6lCaEKgRFpfEdLDycS4/B+HyiDaSoQupe7Aisq8lJwQMolWUWtIYGjxsV5hF/
qw30VOFMprR18wG/4ay/JsZAmqr+/iF0NqIIwm8lfNnLq8JKKKwIBVgdw+nkMQHlsDfT/YFWisBv
AeoLvlKjiAMGig83Gwk2KVnmPAnkJIzptKT0fzHbxaU7UdOyRCinNZEnlvkcMtxAQflBhHXS+6mU
BQ5dp8zDwYPiWqeJZZ0Sq+UVbeyphcNucYB5pLkfWWmu+IGTILU4+ZdVOPEPOpZcKhOsJyt7jZ9y
02mo742McjVtYhTcIa4vqUKJbtL+1uJVyCWC+ZU1tjqlJSAr7j4HEyN8zaxLqLA4Fg8pYKuKC0Vh
cUudfUvg9xYv6hRbthAKyUfSAe7uCxuVAsDTuMqJSw/MUAHqab1AN0URNq9nGOeWJDIgLVMovFw3
M4t2WcxziAcdz6gsdqmPJw8EIgCrEFiEKjaYEW73H2JYI2Esbsy17r4gnX3DZ0eINhat6ib/AEJs
WkgvYSPHFJzBdeIU3jMg83UeW+wwb8UuDVDR7eZY1fDl7g2LPLKTwbWGWAuK6cvEIctNqO37VFW3
LHGAQH2wloS3wuOKJYU24ppUeRLMYhwQJHV4vzNO2I7YiQtx1Lbk1QgQAkLfM2BAtq7mx7inMQhd
DUAzRg+5RgSUoLJbuDlUqkQqEUU1OILUhGj6mwEQcqYlysiN2xh8CNrFBC+YwVQyXMa3S6NikApG
VMAIDhEwsn0JdWL1CGtQSwQ32QlKpgVcaW/LBylNB4qKNhVs4HbPuVW1KeNhWUL1OIfaEgcxWwDp
1CKlULFM4vJXiiyTaLTddMsAY35d4io4LiQZQige4PQcaOc2OwrNOZjjTaqhCWlphxM7zEG3W0n5
RCdJx0lww+GRx40tZCBFRmTaF61XxGNhl0epwxrR1GhKPwRyCHLLlmNqmCI3slNxWALQdXsoNEUa
QLKgT9Mc7VNjyXCU7w3ushEazuNwELtl+ICdCy1zkG+vBcyhEFpi4Hjq4Mua+cc2HJxGr5k1xr/s
pu6AskKi44aIgkHZ9PcaJurF/EVkqoXxMLe8QCYsLOF6giGdTi/MvCnNhACkUIJCC76u/EbsfytS
iYBUn3AsqN1IqvgyMygS2ZiIFifMIDLxabBZcFwVKDZFvucj7FfFImrT/oiIFtVirxUDFB8b/kus
JQET8y1hq24d4+4EGir0stqJgC4vUNe07/mE3KUDsGNExQNwDwKsaqy46OREBpRUJXzGuLbV52NQ
HI/hKR5K/mCtu11/cN4DlavYEnlV+YB6F/cc3W0/uEta8BHqnDmW9QzgeBxyxC6AccX8RSbtlqNy
AP4V80m/zCbRBDzDGElqsDggj7Kq6LCly1G/coV0u39Sgks2G4Gflibpxa6F/dR1Eht5dRge9Oq8
/MJey/MYCShUUt2/EvxMKmVeV8w9gwBVFRDsAC6BeoVYtAPObLImYYl4CF3CvYlJlQRAByEeENCX
83uWmcE1tdQI1QuqeOIhVMNd9QuEGnuXkTWbNcptUxecyOtGgFTWxxMOyr5ZuV7geF/MAwEEwOoU
xA0BQijIlunlgdEIw3HvWcT5GNzNIZ5NzztGT2vvJbaYjKY4GoH5H4Sl417USp9ZW91kH01xwB1C
FLVp5IvqKsaHHpnNbywU3yxR60ilrdlgSDwPzFS+4CmkQW7EBZPyyyl9RFj45iEKuVZp6B3CzmxR
6ERwL8wXlPaBQXko7fDxALphqh+YqUb/ADF2mIio9FT2YRCQLl7CBAphaBwlOtcRbi8m9xHSZzAF
VtyiXKCnmCj4lyBgqpufD3LUVKClMlEzItHTLDwwQgEppAW3ucLXMXS2XeCrhzTY4CKeZyWce42C
UfMEo89ykLKXdkOrEKgiviNtyBVfUUWWbAU2o1PKcQDTQDBN3O3oZYOk9TE5RLBaCcDKNCpIqqu3
yS4LL8wKPHiKq3yci2FLEUFZew6nxhNBNyoguklrFkFIsWcgAwnQq2VWmaVCUO8XUJgsvmPcG3Hx
TCKdWR7jUiHP1sU1ahruGzvB62XydJfNEZraWEdd2JheMaHRlptKw4dhVaxt9ZG2VUKIba6EZc0s
TBMRKZ4+ZeJYCLzU0eQg5KxhIicxP7hmcxWLIgpvPUfBkCgnEEepVFrSM7RIMOIUhBTey/XZXeiB
OsHSMdQX7g8MWZ5glgdBdyqV0pXAadsST0QQLqAiFUBH5YX6b4lNyUt5PMDg7Neaji6ZOC082Ily
cQALbPBUtQulHiFLALIKIFg93xLWcaDzeSnRBVL0gM0AZzLuw0kN9UNErJjp/wBlLYoGrWo0VJB/
iFRDQvuoREzHA9x9lydpKt1owsC8XFmtw79/8jrcOfCGNog+4YEoxHgNcFH1CJ0AFeokjld/EWrx
ClrmPZp7+yDWIraQ/mUlrJrCjxfzBhojeoNVpd3COagHAucE/kXfHAuVfewVcqx2VyImBHhGkQF2
B80R7N2QktUuLHKviPcbAfpihHj+n/ZQiAzwTnAQD0kwOJZxBOUALBASYsFhcqrBXlvlnIoA+slr
roLj7gu3vlitZrBZuipwR1X0RRk2kNej8IOr1f3LnroI4Fy19UWB+EQKySnnCBoLbznCNwku3r9Q
UDXQN/cbhdh68QYA6Xhhljok0QwMWDpGUbRL7lJTERYodqm9huq2cjEsBpjUUNPgi2DQgHzHS8lT
62MAWDX8wOSwVfm6l1C7AeS4KF0OeramhYf1kJNBd/MCoYRC5RV7s2OxlFrfiMySiy7viD0HH8Mc
t3Z9+ULuDD+GHpCvuET4qxbV8RINQq/P/ZQbd4/iOylF8uSC0qWFUYw5coIc9S1zcw7kpHS+ZzIR
o+1zJ4S6DAX1iR8lEdAAaRpqLUGoL6yApD8FiK4pBNWxsfjJY6vAqiv8KioEq1LF4+ozEOG9e2sE
/DTxq6qDLpKeP/MBjwUUQALYbyQJhgPfH9y+BwNqvqbgsk0uru34lCFMqmAPUS6h2PmPVIAR5JuR
g0NNh+XhLuiqr5gpDSt12r34mHkXWoTQY87wnjxEOqiUcrz8S2dcG5ANQlqg92qXPI3yGojeaNS7
e41FTD4FoDm6NjkpyI4rjuFQWO5R1JrmsRXaxWLS/ENkGycJ214TDuwE2JbcuHCpruhzUYqh+Jcb
3GrH8QUKwXgS5YbcSNlQprOYm+GCz+Y0a6hwJ1K+MO5a/wDMI7xCc+xAFOzCvibbDZdUTSLt/UMB
0yzeiFTEIHkw6YKj0TC1WzUq7iG1bBDTnuUU+YrMvOZzz8RgaCWA49wPemVU5VwIssgwbSBFXEKP
pGlHMgqr24tUMnMWvqNVGSkruozpQ6lV10RJfGFVeEo9Y3GlW+IkayLlweoWujtTFHWVfd+oCxrf
EwHEuVv3NE+FxRabXzHjBvkglrs27q0bmK33tzAWswYpXeSz3FDt8f5BIfCFheehlXdIHeqt1lo5
ebPM0otDG3UrIAOuB7g1WIXwQIMcQ8FVUuCaHSXNBCX8ziyOs6m4dEdIKNnruMfR/hR7Jt2jegHp
iFawt+I3vAqWHRo81GF1W7jZn2BDi8Zb5JhgJWmM21TKCqmPRxJgWeoG9XcpJbbiDiwQ8DKwmxVK
S/cQzUBnp2ClXb+IxCynPEeFXhGI0rHHBS9BuqhZT1vVS0xniXiKLnLsWC9GjxkMApERKjA55lca
IaLN2e6lQWixB7WuOKL5/cLxDkhuuyVYvgrMQgl6Al+ozrycY9oERr6lXUCj52VJoAa7mRBaeZtg
lEMS6ol8XxHwA2Xnc5sIub1FDzTpKzgUyn5uA8VdE8e4mC+b8VGtAW25iQNA1GxE8Ly5UGtDY4Ai
aVU2LlEQwQ+M658e5QOuMdqJN2Db3sYnL+GBb2DMPcz6+6T0Tse5TYAt9QGwPTFOa2PVRVNL0wh1
1KRl8aFKfNwU0QBfiNqo00lEV8HRdCKLBsVB+5fOijQX5gquR9EelUfvghqESVWvP6l2dR+PEUGC
GWJKAoKCgx4AHK4ddiwWiJJSbfQSz4V/mXa7laWop0Cl7UTCU1+IALQ0x/BGuaVH+4J4/GFwj0Vu
EuinI1TwS/VRghoEpuHadOlRvyGBKcC0KQnIgOYg16rG/wAE4vBs4WtmgSUVpmx69nkZfCk81dxu
1LbIGsHmiAFiS0oq4gV3wehDAA0ua/8AEbLdqLBaE+GHwFQG1twRSr8GNzQBWre/UWBZO3Fzna4K
owjNXGlwRoClNUo/mJBDAI1XmX2XwLbPEOq/oS+IbWblzhwhwFpcXVQLmuPuIq2gKahe/wASjGyi
7yBivB1TMTtF7epzEALNChfcTWsEH4P4nCQSDmrshNFSbU8rTz9x21DT1LfzCWrLhw7gBnpCVfLB
ddAG2cD5gRWsl28Cw3tC40uNgS+potNYHcZIcFdXw8xNEuVAvMADWyqJVibz2uP9QD8rjpMY6C6S
nnuCDxu5qPS8czxeygrCakOAeItnFZTuSrsKSVT5t5j4dCCN8LHVnbcz/wCyXklXLK4Qioaiqdb1
NOSLMN0xQNuyjcPKCha4d/mA+sNeX/yAyi+/lCYYAwNUiXzB5LyL6IjMI7W5VdHuI+ZQ49CInhWR
J5JHBZGIMO4SJHR+EulpsSrKYqVcd1qWazJy26JtA8zQJaca5VFcyneHiIGETXuOlOYrRKfMBJS3
zKLvcRoNvxBKbbClLuGT8oMK69xCemAPKU7ZBXghG1GaQ9wlafM7DmdvJ6itPNPEHZ5ricaeIAVx
6mC8J4OIWLrYthex4hxHDLmaNnxLjUqFr6ia5T+Jo8y9iOQ4K3AZGohq55jowSbAKIWteYeypQJV
MqgGvmAJo+IlCmdQI1t6nQDiW0CCn7MoOthZ8tgLPruCxKFLu2W0b4l+zPmaMbYsJceaiLrnYqLS
zIqrcYcLwzhtKrm9mGFnuV8IDl4bhaBZQ7MHoVUaqaoypioEdaiBxy9lYBRLqPDllaKPmJf56gtV
pDp6nZOEL4mPEXApuGn6W764yImt2fC4SjU1YKBNZZ0gLrIjYUEJhGFNNXnmK9wEnVQ98oM+PmGQ
vKX3cOFrYFCJRIKXapveL1jbnidrbF0MFFpnmO9NQbPDACnWcufqWM4mQYt03AHOYi2pTmHloXfu
UhS8EjM6277JUKGnq6lfq9XDxCGByc4mtzJ0uDSXTXHiHk29I/ct/sVtorP2aqhD35sqc+Yt6LlZ
XNZt4ZYQyh5CbWtTiAocEKv1sppqVcETmD9kJYIG8nmICM0fWIrAaILjW3NLI/mjtUpBHmslJ3s2
CyVNuWpn7jxVTmirlPVtU8xlQLkd7K/tSgz9x2YmIf7HgskGUNY3X+wEi0RalW70LWlxsDdzb+4m
81R2Ik62p5JntDdjUpO9KDliIY2mHCRZNMcijzly/wA1gt7lE04AtkAeDKqM9Us7ighu7VEGkcck
IS8w78ZGMaiV0TmTlZ/SGxCt/wDjOcrrjtdQ4APA/EWrvFi/xDzYgzPcTeXmN9wMb3g5ECWbVjiL
CuY73KlPmg348w2miXw/UYdbKN9R2zV2E8KjpChtLVVl8Q4kH/gy3r9LMSMDYuH5l+OdK2Aj5SJj
42BCTNkXzPGgBig3uCjP5l7yKsoH7ja9tj+UQuxKHH7h4INjW/HMO96C8P2yqcCkKX63JetTpWTV
+6pBZSvQ/pJXKg+AxGgF0UOeJdFdNUdMM0IVfA8xDuOjZ/VQKXftVEWN0GhU9sfOLq+ipXgQs52U
S4BbigssBnZqEQ6JgpNhdgfr8RLrQTTbceIsRt4pIPKhYQfiodUyMUHjiXHjqt5EnQXiMBpQNH+o
7CE5U+PEQRwAcvUNHTB49MLy2BgfqIzlUKC4JVFvmbnyEbExzZ3OdOrrSiKljYFfLNAHGYWMmiIL
p/pnMVnCA1AG6Ss/iUyTb7jLYmeNxZ9TXINlKBydnTLe/uXWTQWyviKVHsyWs27j7lbBR0iJ2Qvx
oi5PDrxCgNt1K2YlFf5gmBbLteUhdiq79/EBA3XCeoRwtFyB49wGQFPhBWTly+lBnhgwBAC4HWyz
eD/Eq5i9CyOEVVRb7lqkThtPUAbaPMW0565LWyqgrfFckQLLgaNrZhrLZdUs0VcZYVkA0BYpPUG6
/SILES3K8j3EReVHiBAMHMbZN7mG3XFxRpxOA6lro6R0ypcorZ3xPtsuVbC0bp8QCyERLpXxFsJl
0vBkQ6R6Hcu0yU66ImDxEsrzDVc+4XB58Q8BKbFiKKuCvlLqrkjC9xxq6jQO0YSsjhb5iqBVRTQ1
Udo68yyAhLXH3KZGwYSPBA0AXuGua56gvqNXAe5Rdqwm9+Iwbj1NqVdmRUhybsS2Gx4HBzUFk3fq
b1X3kLlQWnL0gC+bMvmU89yhto9R+WWqunzAJeJ3Essy+Y+R4GwWQo8MfuRRDqpTwmjb/cf0eYrF
LvtlGI6wA0GFFKHRLUfylyiAdeYV0ab/ADCVvUqV2+VDLVrZVTN5LakhO6Ypr4iYpdFElNnOLXID
RHyyE8eYX2OWc4U1C6M0LL+SdYuX3mCMssD8RUvjVwSpc0fYO+hu2KI9IldAmzzUdoO8VENQibKL
mOOJcrOcjYs5O48kyGC1Clh8xws+oZa2gsGPO56yKxk7ukJrjU2K6mqYq9ovEpGYcFLCBxRYgCK5
Moli1vE24eb7i4AWm1TRZOqbfbElDS3ZNIy0gZcygBxuokPXhVSlRBqhlDa4bciAbBQPFRhrHogI
q7uRSm+XYVpraGqYaM1wMUk+r4gVlTlZvDRpXUoN1udsCAHDzMjdju5y6VrzL3CPtGixdVrIL8AH
cuCdAHEfCi9VxLCDeF6xa2ENYRWZUeQ3qu4AUEygwTuSFNmKNznyNUX0DHyHaqJxCSviMoIYFxQP
RURvg0CPjtoC0ACAfA+IIGdmXrqTFgjlxztY7UAOaliWB1aiA2T3C8uL00QBtlYyOQ+bZRGQh67g
kIwDzNssFB3LgqjBtTM2BPq4xyyUcEQ3CmBgpoDucJyg3fqLt+6YlPSqP6I8h5h+uJiAOwVEvrDx
BqFOc9wxpXzBzTrWX2vTWoDQIvG5niuqHE6HIFDYWdo4lgSZ9Rd6GjYw5O1lK39seAvFz54jh+dx
PzLlfY5Z1ALQRMgbFi5U77D8wAvFRIWVClwY54Db8w1yO1TX91F9NWHJddQ2g1s8ni4hA48uhi4t
KgLAC2YdaVnFMC7DiOlO6l8pQ5ZsYHUslJzzAZhKop1AYSqh16hw8cm/mcHLDq/ekOEqhrnalegS
uAdxAXZR/PiB0qXXH19QVSaiethggL7XMXLA5VNojt5qaOWNyX6qnXqDkbhXJKoDI4fNVcr7vBuv
cQButgbIeU44hKvfRCuHCVcqUi8H0IHpRVNmH6gKUFqolHmXKAo8ppBbYwKnC5RdcqRuCwBaj2nU
fcqtyA8xtToU5+IuEfhATX/U8GbI+yB8p5qahBzaXGbcJsCH5FoqxWCWM0S32igAWCsiiS/EoXqf
IYmr4WKFpyMgDYbU5By5UNO/CU3eKhRVNdjBPOWK+UVLbKN7hAbCo0S3cA4YxxGAjphTqNWsCobH
zFOQ9H5nBewVXWMuCJQLeyuBfuZNlhkp6xKwHHazhdKjgrnxNHxFR0yJFtUI33EqiYUHMdzmwoeN
hZzstRR8TEOJ48BpXMDGJ81LALvxKKXiKrq4IY7LXwGWC8dwF2UV+5S60+poEMioJw2UDs/UtCi6
q4nlzOoXpIOiWj6Zaf8AIiPrslbfDqDl/Ut6FSiBuxUsbW4t+50FsG1h9yrdWaZCw78pSIV+Zaqf
cEEU3P8A8LEU2FJa8WQqNUKYAKh2M5LL+ISrwqAuluplvwfiUaSy8g8gbGBtdB1BodDy+YKxwV+Z
vDBDuXjZYsy7jGmrc4lDFtodS4BtxFR4TyrCWhk5TmH9kxPEIC5VHDKV69ebisYChtHoSHqTRkeO
FZXE1EKIgGb33DWqZQM57ZVLdTwSiCNUuatImyz1DFwdVBqhlhbrLFnBrUrKVLUvLiFReROYTIDk
lwi7M0EwVOpeTNlV4liLSvXPEo5mrOMujPdwizYNr3ANqTHSozdJUGdd4EBFbLrjY4ScRSFAYaYd
xGru4+EU5EdfA2ocIAtRKuAoBsviDYoIZULUOo5QMq6sCjZgIKbU7UbOot1F7wT5S9fCcitjBQsg
Unq49mcwTA0OZkvo+CZsBu3QIz+42vBlO4OosaZH8YKOZgLHmbVegI80LXi+oa2AxJnmFis8eJf1
wI5jpKVTj8VEdHoO/qMVB4qU+qeqjlCvWRCGABzN1tga/EHxCUMfErc3yntlg8FDOMjGiFUCpXav
vNltyTocvWUYVlqocwL35VcJhLVws9RYsdo3jJmEbzqARusjHdI888UZTuHNlvwLI9ABn7lMXuYS
/iCEZXc4gY3wz5rCgVCfNhV9V/sHGPEeGHyov9GWqqFQFVFpmgQsgEt8IqVKWKiXxHVyWrSFapMO
xHWq5Eh0I7VptTg8lB3Arg3RwYOMHdTGxCHdRQAtQwxlxIoM8l3GxB5WxcM9tYk0tyioCmlOPdRV
gd1hxBSI1LeoS6nAML4lflzPNFzdAc2jqllJaoh44IamtoDz8QTDcu7TTA/gI+bihai4KNO7HMZ9
VV5+Y5OS7S/9gcRCEWL1MSwXBXUI+BZw8w+9cwTS1S7Kv9R4dQ243KlQsGPsiDewj0H4iTcA5b0P
iNTdkFoOW2FHClluZOJc2Otl2uhMWHP+Q2GDAXRfMVur8Od5+4AL05ZfX1EhVVCDfqGYwha6t/iJ
o4IcmBJsHlXwRV1QSKLPmVwisHFGCBwO5FFXVfMK4TV3AikX7eIDBlAvuMsxwUr8RCWAcEPZNPqp
/YQNQJFDZDbFwcO3c5YUIXCWY87LzzCTyKOekAffBhYYfEpapyEVvnmBiKg9MoDuAlLfUNmN96Pn
7i+Tw8RqASpTgAwtw68wWNZGrrxG5JBSSy54hlA25gG+ZlS2SqEGCsDYy7NQTuDRFDBbgB3KbvPU
Wg7jd/2mmyQS31FjzNAvxA0lXEKdxUfcAIoJe31OlOeJYEaAq/ETgVCuVsEFG9xbHzGRGoxyc5cB
+WBUWcMlBgQKiDduy13cYeks3tPE2OmcA/MvD1LKyhDrzNldyyDz4ggg2++ocBVncUW2cxAj+YKg
So2WkuZ90RQqxst+4BgRBejMZqOa1eo878czOnUQbplXV33Al2yhjfiU1osSG6SiS7gSx7qNAlHT
BeCM3cz4DxEQpgcQspgWTVz0ENr6SxVwR8DkmqFquoALW+PU1D1OCKeam0abqaQ/iC8974XBWZBP
Ub+1s8wOWGXO1fJKo9P1g0HnvmZpQK+I9lbdvJzFUFCnhHdAO5uE+UESIh6TIJXpSobKjmq8x7qF
JoEHQgX6IoaKK8bkAHUaB15hQEqM7XiCVu0lKXuwq7uWCnZp4+otA8MSB74mZQByPUQbnNP/AJ7j
yoaHxLXd4r1PLSh5nNvfOkusaoLjFqboTp4JyCeb9URLIuI1oCp8M7ADPlxEi+IcQuGwXxFbC9S9
y1vpPHUAvcix5nFm6Rn5hcpGvonl1Q4LmgGN99Swku3/AFD08r6lzKri8S9cfBBQTsyOQnGvuadp
YlA55juUQNWRGl/Ay2Xgm6LJcoDhHILbM+mPR1AeKz+5SCt3dXUGIH0SzCIqQiyCG6+JZCfa+4DA
Bs/EEoVxdd7Jy5Bfww11VbfuA/IHlzHKjuA0ynyDknwXQ6SydQ5gdmlPUFWqorsYU4tAqiYR8bHY
rsO1sgGtch66YJqAp+Rl9CoK9xEZ0FxZYp3wM4Pu38R9SQHesb4KrbfHE4HltlNTg1XYEagXjp6W
eOU/xKESxO+LlpWFpZ5gsZY3L0q481yF05v7lF4MOJ/65cXIL9EwUkLdPL5lufvezNopODpgZ5rI
3uLCguoxHA0DpDSjFcPeYRFi6NCOMiohBBGQlqHr+7FNkaXLD7U7RpHaDErxKD9+PmdE6XxHeEzg
Z+5c829zqdN2VNuRD/KAsq2IK4XUSUaviWxvOfSOlr1w2mcQfuJUkSr8pUQ0UfM2UjdbYh1rX9xu
PBDDxBfctjaxVgFfzK9U60t91FfY7bWDttFprFyPmuPiXsoCbkLdpQVA7b8wFA0DbvuBK9hwBQ0g
fTNY47xU4WpepyNbKuZSE0LDVMbIvUUg4jgHwm71Brqlyr7YZl2Xw47hzsZOEPEMQDAsKD/YPzAL
SC5x0wDVgOr1fBBUCKtKOV8ROpYFYeyNv/3XpSFU5Kfibf1pXF+ZwIZscvB69yqFsEzWZ5ZnS4p0
3F8YXIncMxYpwVtR2DGizLSDXSMWj4iIw1EKO25VFDugXX2wUAANjx2ShdhA2+GIAAUnMLE7nmyI
VcclpaJPyiMhErrY4BdzHilhsVV8+pbplFnCWrOJRWCp8RrTw+4YYc9yzoeYWIMWbfMVK8nqLRfB
EAeuYlE6hQPEQozkAiGsgtR31K3UibeGPDB9osUK+JpS5AFD1BA2BUI/MN9CXENH4jUG/qG7TXUS
u5CAyzuoq3dncpej7ljzvU0VygddReQuISyqgvUEi6IFOYixM4yFo0fM8Ao8s6GHcy60fMcHiYhv
iFIcbuY8UxEoSImm+pUI66gVB3kBC6epch4MZdl36lwsptLWqlc1KF6Y9Q0XV9S6F8koQdI98JgA
p7muywbKaqADpnbB5xREB3Ufeo1Foo3ivMrwlpBpLI5TqNgmq18Es1I8yitaagFrlSy4GjIFTy5a
myUF0VKTqrBeofZAJy0BucABgdNwAhLp1UoBc3uANTDf5gv2rfDdS+9KLe56JRdXNAARfecQ8cdb
7lB4DR3x/sRjeGBQLUA6uYo5QX3kfIIa+5aCx4CEgMd5lHPFTfBFgx1jOLiRN8eIHSxWlp6j1EBB
hfMejFRFP5QqcG8FpV5/iMEYUfzMKuHxPJHUqbv+seo1t+X54hlcEP1iVO6A+SV/ypWuvEKu2a87
A6oqOKFw1mZcSI2ZK1RGeetmEo2v1MTUVXElRijkWUhunXjJQjG59XDk/Qg9iMPMSkV4jD4xH7hA
7BVd1OQtKsRsAaPcJWisrmqmW121T6jZIUeQliIYMfzEDEgRjPgwfMdwCX7lMbC/KcwwsD62PvJy
wa1qjwXKgIcWsdhY9EHi4jALr9XFIETk+GZmKl/ccKmYJksEGaAgQEsbAnmMuWxHEcDhgMI1/jmi
shwUzY16GXf2VOIAyGqGoAwrIngZ+nEa22y/R/2M8UVWXOM3A8PxEK1AarmDQB7V5p/sGxCnY2zk
FDo+EURKtFOKIzWB5fUUiEHHuAHQbPkj65EP3Hbbj5mhuvUSUM7vonGGsPRVQKyiIPz/AMgDa/pl
iUCL9/zMCCU+SiDIoV3wcxaVsX4eoDwKseYV5CwOmcw1A7TxHJXi/wBxrvW4SRRSaX/Euzjv9sCp
gL4Ni0w8j3eSwZRDy3Ajtw9XGrAXvXBLm3Z9dxIy4EWq/wA3LXH29HjJfG4g5aiiJfHELDaF67iZ
avq5v2D7PlLaREB22icmsfEVoFGs8w/EJXhccqFsflCRNQBvco7TfoivtwtkRSbp3Am8kA6pl+pq
ceEOB/uAgjWHUV2cUv3UUG+qRtygxZ0vPzCIhbXVv5i8CB+agB0oF1sq7Ko8oP2SmXoxwvowKhyn
zBe0C2ajhdSa3xEfO5FXqUm1ReTiBSi4nisiIkajR3FaBFg2x+qIklE02W5f5gpPskpWRzJRodl8
wP2ViPuZZ0uEst2dKAQNMh4TBe9yowUQVVTjP6hCMK+Srz6mWalS1BsPfEZJEoS8v+wcm/Dz6QQK
EabtX+pQ4UFzR5jeAC9KJcBteoco7H8CtuqDDWW9AbyK8SBVY6PxAUwt7XK6f9Y15gAO1meWIzEf
PJx9wUYoEOoAR53RFCl5zDIFHmFv2QqyiAWvg6lAt5me2WKEfPmXDcJVWORoDLmKZZxFNNpORZcN
M8RwXzEHpOTUNnqZcwOFtsuwG+YgX1Godkp4EVaEuZX4m9Lw6nh1UubpqK2wmKPuIA9xfgy9U56g
WEuvMqU5ipy6jrXZi7llBcyE1mEQA5C4A31ORRnUR476g6VxDJE0wjiOpZ5UPnmIF4eZczglOYqc
+0amnyiVU0ZFB2dQ0SjYKBK/uc4r3CAuTlvxty1UOa2JetdRI55SmrzO45IqZz3KBbuUXT6IsBVS
1no4WIzLV7mIRFe35ggb1djq2YwBK5GBRf48xGy9wAiZfwl5S7cS8nPjmWK/Q9xlwYx9ymysvsYf
5Aai+5OJeqmVKPCOWfEAYGLtQxiWAz2Q6Zj/ADCs3JcGUI77j+goqWWlaH3LntVW+EB4KsXBrfQ9
vqUqlngccQpNznn5m58SCW6hAxuUWXtTVLbrmUTMmtnTKDmo1zYrxEGwtiLS011CrbZlu0oQFE+4
5A5H4h3aJXFxbA55hmQhpTfxOcFa1yIsWryQGPNoBeclP83Fg9dh9bBlgxbOqj5zC2kvcLUe1lXq
RWq24nBrroQCAKscRxADF1UrJgIUwKqSDzsDQpWRIByvtL+1G7JuJxRj4Ny9XLaK8LX8ysUlWobh
AtoWHxDpPwtK5o3gWjwslhXMOLtea/1NJFux9RfFdp4agAYdQgihw1ZQGm3EPQw0AibvIrrl2y2A
UfyCMgdis65gm7SlDio/YC2DCCunBrEUK8FEJtSePJd38zpuUyn11LjWkuf7FDW1XL+JWMqy/MZ6
KqvFepeA0r9XA6RVJKZVCaBPMTK3SvlguHMDc7U8SIW3omr2sy+cs4h2KVYohadzYxcs6vWetjxd
5A05jYJTbo1kOAhVX5YioX/UH0eYeVbFXvENShlCWnuP3bXJCpcUhVxsjVWK+CDcqmkbVt4lzrTY
g4dgyBOJo9wSFikkS0IRB08kBlqFx0pg8VjCMmiMwsTrWU3Q1GEplj0aPXMfkHkC/E50VeN/ENpj
YUag4JQzKKyAAFLVsEA8w1g7LjF5bQt+Jc8FSgH1Fa3KFhBVqjcKhhZuX/4l2b0XpBiotXyL/cXq
xUi/ibJ1W67uQSaAGIV2MRlWqi0bV4ThfFSusyN0f9js9AEG4g2XUzkB14Uw3YNLUGWt+FQqtuUY
9sB9MIO6UBthBGrkF5h1d2br3Dg4eBXx5gtSmIv4iJEnLH7S4EIF0VcOPusoxaqO9weAlp18hXsh
BG42oSKL8sU/3FZglBqi9lahp3CvEeA9EfoPMQld1QDhvnmDSCwcA6oi+lN3HH6jEAEBgcDC6TqL
1bEElpcF9SsERMwcDzEulbsXK/mJhWstL5e4AKFbaR5orwvmF3CiOJ8QlQg85WAdTvzE2N4Fx0Ik
GlngPErnIBEHVLNbiC0dCyqxKRkYETeDBb1bFGXUEl4D32xC+1JYQW6ioLfZDMczZ5Pv4iBy7V83
DrfMrg+2JTVRdbhLIpglSlyxyJYFqFXfzFpQbYw5chCXfUbqL+IlEFtdSlQ+oKo48RbSqiOmRG+G
XVIgBVV4gbhT72awUwoPC5GAbKbdQC2DfiWgdqIVypVOQF7pGcn4l28nbwxNvxMfEGlRVeKleFrH
4IMa2+TECWyhXuOICa4hS3mUR2uoizWhVkQhqqlq9QUl4Ydj57haIuixyL5Op7mpVtcioXk3lkBb
z6hoKMYNC+pQ0fxKdOc7ikJKlFgpYyt2+Jo8FSwA6+pTau+J3mooG7icrS5UKG78RK+HqU1OeobO
V5lqHjiAPTxF2d6//PTo3zAKY6YNLdMagQaV5lOhuR0ryRa6U9QNLwTGAeqialnhuD+cXqgdMN9Y
86qo7NRKGow/ladSxQVbVf3Kcn0WH5iLTVsW/mMhZu2XGGQrtCBnYp+YjYFNKgKUdBparZiNCrDJ
WrlWTf5lk976r6litvluIWc6jgviHoVKOm43cDPUIUKjfmULcONiEtfUaLt9QbceuIYzuIQ5Yo9V
2eV5BmePIP3PMRRwILQF5jlOIiJCK0beonYx/tI61tnxOvmayOmjPMSLyHSwStTL/wCkAUlTWVL/
APQ9MBawBonHXVZvyS61G3OGMgG7ePcXOWLqChNaOIbR7Lj4eJSCvA39QIL5x/UWLUbXMHP0v/Jk
1HlDP1Cxk2sbKk4og5CsaDv4lD3duylW139zpX0FTlmWvL3Dcj3pRKEBVCl+5d215z+JdrqtFCI1
VIMvmPkXP3BJBrF2mB87jgJSo+kUP5lScKQJL4MvIfxEZJWLtn7hkrnDCYPJpXmIFErBX7i5r/rA
inMs1iG5clj9QDEdikhRlrQ2AQYwpbLw+FSs+I4tx0IDRcu0SgBerSS4Jd3kmy5cHDClS6MfUbtO
8iNabTqDPyg0IsKTAbLkaVLlUbgrKiVVkKiw/AyqPyuTANK4TqF0yk6i7xIaYSVnWNVPRxESIPmq
5hgUhoBEXjXlUf3Gl8AL9oRdOAP/AGFqPZK1iu8eLwlmJvBKiQoPen+5d0WrYjSji0ktCiVQiXxI
dI1+5Q0eFwPegoWfuXB3Y/4IHGbiA+RNXA3xfcI+gQfSzKae99kjZk7ct9xtQuQUJA0rUt71imge
CieMUAJfYi3FQ7C+I+1DVeB72GVJ7BHxXyC5dW0+c+mPUMXbsonmriD6WOBChI5q1VEFbvlZuO7g
JzbS8sqJI5hZR4i9tYHiwOrgTb/FpUurBfbZVU9W6sdXeRuwvcUm+jLDgA2BIxQHYU/MKjquhH5l
H6OBSH7m2tZ4Gv3BCM+01DgVFniS3IrEhlt0qKH9zLV91NDy5giHZ0rbWZBVfYmEniBXYyIDoDUL
sb72K7XPDU5QDLtAmhMZH7jxR7sfpAE+ZTGBFLlBE9pNl3TzCKZbLyr3KYpDmFRWoXV6VC80+IoW
LqAUlVfcSGtV1Bib3xFonJUK3nOQ5eZWOA5gNNsVWSllfcukDRioi0vWXxWShl0Sw2FDWVnLZ0W1
PYMrE6SuBs7Ta+IYX3LYpzHVOoqcU+5j3NN9ID441WoeVpmSTbGWZVQV0lUqlqK4uZASg3EJziBs
ZWAR9br1OS7u+pz3KYhLtGvUFI5jhCQ8ZFuwNFWRSsSmEoEsI2FX3LXzUBQKPcq0XK2uSBKxNp5n
Faw0uWlqy6nLnMyvh6j0LvioS4rMWAm3zLpVviWbA2UG4+JiR9bGraiCyrkNDR5ldVEu5TSFfH/4
gJRCB61DiGhWgcO4iAoNfSL1A9yha+pU428SkttyAAc9yib48x5bVcXHuhORkVBCFVWT6ga6eYAL
Q0gwSS7ZAVHTYAKa+I0JQqF0C/icGxd1dREKT1jM2jbTggdDgq7gwUs7IHthqsRB4dQAgfEpbdyY
KXtMLGv1BK23xFgUTgHHcuq+ohwSvEA3FAvm5VvmCQSFUWMMEyYpcdylLu+YgAhTkOWC1ZL5ocVc
uqfiqgV8bLLqZYReifqX6FG31HS40JDiqAXbq49ktuDmVhbh98xXVQHdEP5S6RUOsgsEvuXO7LWb
cAILDtwqKjENYsKlD7SsStECspZANCV0cpuIrmOHAUyGKqnuIGqvZBxbeJwmHoB5ZUyq4btcSiZ5
VDlcq0C3F4RDii4woXAbLn5oIfzBQXTtIOaN01H0rMcllgKWaKZBnYinOww3IHUe4ShYIQbAmsbk
wU15l2lBdFENGBeEojzZa4TT7Jar+Y/d2nKwUwgV4iLVDmI+U8FwKzi8OWDNZIFr7jomsomkyi+i
lgu1RocSjJVyOYzC6tJU1w7PRcQwQbEYtQBgCCOlJVcS8duGDYGk5NwiU2ABqpYaCzmDt26mb5Xx
G2nhAQY8hMoU6YZaURrayHaS7qI1Yu/EROIDQwRxaC4ORuc6QXUKop8pMQx4siinqylxshZ2ZEyU
F2kt1BESavMYeaXuKcXSdsrlAsO5/EvKspwB4SHHAKOH1GlUScdFlHqaIYzQ2IkVdP8AYVmqKpoX
LyDMgKGXA0OUPbABHAUFYs0TlcXlbLQWR61LxRKnAsAWuV6mPV+iJ+ViFRAte6O0Yj4IMCVxbaX5
oVnCGJI64I8QTlHUoymuhLAglL0VENbrZZPgqLlUP2sJrPnA655mE6Y6E6PBO4mwzlU+oHSzDpsv
4QPJzEt0JodS5m6o52XbxKoM0PRGI46nF8fMd83ZKCymodKBQF9QkKRq21xvSF1A+YBXoANTveCV
IQUtrDIRLhRwI803bK6o6BMvJIqlbfuN0UCDauCGmbAkW1kc+hMntMgC0GtXR9xHEA0CbRexoBKf
AckAqgXHuNS+t2I6gy5bfES28SgLg3akT25LBPM+DfMLKEUXsC0I1QwGEFsYRefqexuUL/RF0wK9
hCscwtq2SlfUUMDFaXEBtchG1tQYdSyzxxDWwsQuo7iJSDBXqF8aRVG7GWBlRVfctVE+Jhi03PEB
8I0sO+pux2Uc8xBaXCtvuIaPiCXgXAiVeSq8qPSFvmJauHQvxAoi8QAd06gUqPEpiYCd8kPDgwNL
QttWn7m699RXxg4/EFa5hTCN9StlNWqilhxOzkxsUpQgUZG3zR1Up0b5lOT3FqN3tbLosHuLXhx8
wFn8SrFkWu7vieyEAV+ZQAny8ypW7OfELkM4OrHXMF5RwukD4hnE4QUjg9wyDT5mCvnhDPSmepyt
TS4jO02Xq5YR1zX5i8DyZ6lyqMnTmWwUMQZMsKUjDalqDsf+yskppoSAXkHBRA+JZjizG77Y6wbS
cTMUP3BHtAKVxER/CItC1xJYLa8vuNfB9RWWYRBd8Q5eH3FVeYyDgYgnaCIDF9mRQnBwNyMGxpir
jSxwEHMXbHEqDhoJzKagRDkuPHKrOXxLU0LuI+9KqOGcZPbTM5luYrgDSUSKz1c5MT/lxAYKgsHq
XWodrmCPAHrcjguaadVKVjOq2X/ELVQZ1F5DiZRqyu2VyXYc5Mp50SfNQ/uhTa9wt1SguWXLqLbw
uUCaNy46CsPBGyeFzmUDcUtX+QKTqz8MKw2q9sKhA5skXylt3/csEW7HMuCA0HqJh5XwRNMULXH/
AK5kuAsXjmIVivuL9gmFLigAkQu/uA84s6d/qJh8ReMh0qUbb64j4RGrKLmOtanqFCwOdbNpNysf
iL7Voo2+pdyILdzxGYgiX+YKwroG5VSkU42FnKSY8eI7vwBwHiIVYLZzk3iDDlccigsNXPNKXUC6
VpqqgvJRUnngjRrbQvwUCpSzAupYUS/cW2k5KtniXquo0zxxDbQ3uBVtFpAElXqBAqWHQEV8qs5+
5waVuVKpGmq4G6ZYqrfLO1XB6h3RqH0e46xUFgPTKz8ugEWun/8ALLM1N6n/AMRmw+g8fiAZlqNC
oV0HS/csS5yGaI7iVm6Jr8RBqMBUX2QQDCHILX8XG8c64CLDWxv5xDqSW6AwrP67O8kvM4IqqYIs
T06Vk59gfvmOHlKjhKCO9GmTx/wCO5hgYvqABy4ib5YGyl55SrX8TPjAgFgNWvkFr4j7ilUoHMZ6
QAuIdqQ0IAqgKw8PjYa9yp6oIcOIUbvDkN0TVUFIEVYD9R5iYQnYWDpZ/Us52Q0C7/TAPntqml2F
xID5VeQMMI5kGVQ18D/7HgVBVGHAzpcvck8ETm8MEeiM3hLVguiDQwbG2MAVQ2wBUFfxeRyoRoZq
DYa2zDglVBy7txclUPd85BOI7SBsU6r0zly8UiIFK6YNJerBwB7jY2r6A9AGxpyBNp/8h16KSw+W
/cO+JWEvqdHDTyW/zCFMIsC/8gEoA3p3KygwuQY0sOaqC1pHrme4zhUayMGvN9Rau7fEqGqthc7O
oJca7jop1yHspT1zLqn5QuUy5omNqiOzIKrN7Gq8QDbyNFGxL0Y4KdgtHgh7GXOATJZP3LPE5Bw3
EQWZKAaalFzUWjiWhrJajVHUq7TmLqJtfEVvlxUQ5ZTC2ZUcQGsZl3uI0vLBiVRzLA3xEFzbK6W2
PYEBuMJYcbrWC0m3Hat0iaVdPcvgV6javhhoNXUF1WDFEBa8sN8jNrhcKz3cuinDFxgUcqVbm1gX
OrgGbx4ljBey6azwQKI9cEbTeDuIpOSupTvi4LQbPUsKHXcXl1CXVbxEUoKGVFWjtlq1ZDWXKwLv
xCYgoiDkDxOKsyZqHzN4U8ENEKB17hbvTE7Bo/bGtF1ybBYYeTZe7WtbErOvUvsrOebRhZo+YU5F
74gjoo1UvOVVY1QV1supMDWS3p+YgVAgdbzF35Bv45lnizT1zAJwLk4wc4YQLQgAc5BbNiLF73KK
KfaK0/JKsLQ6gUBBX4RhUvYKzFo/CaFUg/UaOOmWsU54VjfAi/hEvRQHmHK+7oZm9RlPiAQvYPji
cWGNY7xYGpAJs46jGAFb2R9cIHxcbVSFTfWYBEWX5/8Akp2DQPmZn4tudkO8XVvgAj20q32L4lqo
7p/PUcMTjOjBQoNnE99wR1NDBsHCMl2lmcxTBfLKQWhbaUzqODkG91bKCNNmgehmxB1U3fTfxAga
0PKWwKqRbD91aDmKu9ePBKwWrkKzYAEIS1ZT9R0sGlp9RmOhf5iVDla3bubDPohEyAotfPxAmliI
cxasX9cI4AYgMLmSRge4BJXa/wA3CBcngqzYXKs+Udss8Mpq1gUQs7PoRU1APB9e5pK+Ty3MntJe
/uYbQEaJd5RT4q471Kt/bEoFgceIdM+XKuouILoqohrLNHxcNUtwoFZZfjYNjTZSKO+JoblWJFJW
pfj5hctkcYouMKi0RP8AIJoKKo/KCyVkBb9QGGNhrF3sALL5gigR9HuWqFO/Kv6hW2nYc9xWbS+E
MY2Y7Loft4gH6VdcV3LlwoX42Vog4Wm0dwWsbObIYPZ+4qvi5QtXsH2zcNNK8jsEfryrf+Yw3UeX
ETdov4Qg0IvzZFkGAKcN8xpfgF5eIywXz3SGNbSssbZd1EOUR0IBF3s/Mq3DBa1GMR3la0nyRsi1
UzNLm4JTCIcW7ErXxLqmL6ANB62S9WwvC9xvK+zl1gKtLDlcFWdwZRLHB/ZAtzVL+mKmK025f3Kd
IL6r5jpXKeLcIS5UIVl5BuNLpZMGya4Yx2Bt2cESwIG4G7GCNfpS7CnZGMV59S+YzXDEmiIsbAAX
RuMwT/bYLHxUA1Blzho7tUr4YjnQA2l/3LKxb+3+QKF0Hltgx1Y5uok5zVfPLLfHpjSxL94BGkef
mUoLkqnP/BLMwoNqTg/3qLzbHt+c/Mw/PF8I0uFq1hEQu4mvlH9lsrc6ylqtIkPDK1U/UEpOTv4g
KryjFbbPcAGiJp3N1ckW5pfMDdLXzAsar1ErizDf3GD7pj2vZg6QdgEKziWOOHUWnMV+Iq1tRP1K
j8IbXRSxFE2JOntg55il31LQ1+YUjbsSqq69RaMKGWUp3xA5NVGryJ9vcGR29l2KgC6ZZ8PfmWSm
FinHzFYXCIFGqg5Hm6hVQUSvqUd8fjuaV14mMtI2Dx6iLOupiPBsGGmywNN/EJOXPMoQ2pFIgELE
Iuq+4hXzkXd5hgUSNtGn7jQEolSg2BoSMpAojxoXALXcw6L3ULauRlliQEu9p1Bce58f5gChz3UQ
K+e4XbV9MQdUco7wyIpcrZgrFlgqPRDcB3b3DfQI8RUliHjWDE2AlOEXc+epiwCp6iB87ahKgXU7
iHG7qfr/ACW/c0eUpaXU+CMHrVXzEB8IvnuXcgtxeG6lNzRzPFQ9bK/BfEc3Z36lcAKK7jJS2zjm
UV/mHD1EBjpHfW/5llBR4is4uB2j7iinnzNw7iMSZL3P1BdjZvxn+S2iytP1LDKTyR3gsHddQJOl
LuFujbqaFotwuxb/AFDdwD0D7Rk7EDzGqFgl2VxEMl1nUo1XaKSG6PjvUA08KcXUZfWKW+IEloCO
XcOF2T8REDYj4Jw0Ay7gu1U0X1fqCuoad1AjKRYwSrCiviWfssuPcEQPYVK1hR7EQqbYGKTJStvn
iJcnFEr52VmFLDRjW1kTniABW7fnYBJAqv7i28NKqU9niOx3U8KR420opXM6obHtj4QWm0sPihp9
9wWNFTIaBp3q2UZ/ltR7pKi3lxTCgQnMU9qYcwj7UvwoiARX46gi2wduJQDMp3f/AGBIA2r2H1Cj
YNUS/JFjovm4NMXdSzXmIZrrw42MsCObojWTTnQqrnOCuDSzZcEo/wDlbKZZivLFyXIV1C9yAQg6
qiz6IA3mV8lxWpzmFAwsZEbPPaUwJrlCCYVa/Er3RTOY10XUCq1gcyVbjTyEmNbfEOFyAcWQJYug
W3GcEcXlqBR8V9v9jZJqsKHxAF1YPl4i41qrT4gFTNeb5ic1NHxbD8It9PEVEYVcKDCF0t/G2AXa
rLB5lMeTnOY2XMJei+YqENA2tI9ukGmnENEFld7Kicv/AIKgRco/xF1CtO+X+pTyuJMWUM3xe8Ai
FzEu3LEQhNxPpSdw6hE1jLjgAJTsPM5T3fQ4BOQCrgQIu8GuIS24N8NlXKH5b8sgYO3b4CMs4ZV3
wCEGUODxrF7jA+MC1nCq4bcpYOwTkrRvbf8Ase8E8jyC/wBlQqkcHWQt4ArVj61lVSywUUPM2LZL
1vMspoJRdLBhPQVYIqALawF37mtW0/hcufzfI+Q2B/dpnJex+uhUcr4icBcPV9KxNC8tWyo6tKro
rSUUKitzzWu64IvMLnT5lCJRWtJ3FB8xAULx+ZoAaylh48xpJ6tarKv9zXcV7+iKJgOQgUn4uKZg
CulcfuMWWJBrhrGPKb01xdBxMhPVlPzFh85PLCJpt4bb5uU7jGLMz/5HWCtHg9s2n8SiwljCkoyO
LUmwsbF5YrT4joJ9wwFcTCgURNW4LUuYNpieBcTvHeC0wkc4qGNaXdRELBjRuC1tRtm9ja01UoG0
Qg1ZEK8Q0KJ6hu5XpHgVxClrqXYq4aYRIIccwaWIFXUBGIEF9DcoC3PiX7xKMZoOQEIajwrkgh6Z
pOZ1CnQcxaOMdTOIXIFU5YRrwx2jydwrKg2heP3AtzBf0l7sSI6Le5VKcpenTLqDz3UMAJZRWvEs
TmCvxEQPnYYp29uNq8PEVsjQyps3AGWQbrXMx6o5qPXD5jrBRd3KBdBWCqLULo2X6IIyz1Lw4duE
oc8e4Pt4+IzQxq4UmtjaLuCpqu51mwKpuzxBqyjpgZrj9poSDbB8w/IPzVC0021Jk4VELz5l1aGm
ACBZd5GKqKSlfzM/UK6yJKOduVEq0PErSXQqDqcTA3XxxFYA2QTxirhT+42KEKiHh6iGrd9S2iov
xH+GKXzzLSy1FJ2dpLV2dQUAiGe6yI3kMtENWzsr5iyzSwCoa/rtB2KkcHA4ghegDar5IB7UDv8A
DsvL8KCgYdUFHwwXXDVIwO1Z4Cbt0x8QDKbslmVN2wOTYMgjiBnHl3r+UThSvHYEK3VqkRo7FOHx
LWC2nVvUQYnnhsmn9NC/udoIBYM3JbFQjW1o8RED50+mUa7pkuXq2YOEPYyMTYpTNFQ2ernBbocN
SmcFo5tg8G8mVNRI05JTUhFQJHd2FOJNq7cgY3XlWzZbSFgdLh3yG5Y1sMPuOIlO4ogdLG33ONs2
xjXzF0CBC4BFEHEFJ6rFEOXq4L/U5IBG87bcuIOYNuqiqxssHSb6AQ4jF6q3BvxzECqeBCfzOBuA
cPvmdkkLi3uNysYR38wXdylqU1WveDxGNpuqlEvti3bi8GL8kH8xhYvM7aWG+OogIzopYrY0gqHV
1xEQlDzQ3ohqxuU6tOxG8nopzHyU9doXAp6YgdFeiqgElVgPUB9MNmTZ6halPl6iVC3Sdpi6lrk1
MlWWNXWSkAEXtuCVDnWAX6lkqOOYxIZVyn+JSwP4AN/bCBpQ5Vq4l7RAGsO5Urc2W3LH2pcGU+L/
AKxLMbDPEGqrs6LPwS/qaGllx54MSU9S8pxXyVzcwQTu0fPMM+fQh81fNS9YId+QROuqKNPjY2ar
n8hcqYCm/hX9xSs1w3j1BRQKNf0mv09ZPlpEEWQroCTsscUL7hzaISD8wlJUI/5jIFUle/5mUwUJ
xbf9wAgQpevPcX7IipzqpUMwXtc4uJkdiN08x+KYojHJGbvTxDxEy2y7B6modOCKpPg5UPAozYfq
XiYS9a+ILSlmKty8ANOBfP3Db3eFpdbgSy2bH6ggzWjWvmL+wGKWQKhtlPl9wX9gF2n15lnNAWnl
jsRXcW8I85TpIQ2ziZquhZHfrYh1tu/XMvTquLncBDegl5fuILxaFtL6hOqcGn9k2IFX2fxDPgOC
PxsVluLPiEciDF07blGeqjJOMltETKMhCUpOaJSwf+Il1xEN1p6lpxsamtl49HcYVG86iKsmZuDl
3GtnNkUllxgafEEmZFBQ7jyuxUF48QK0LI9yiGW6ljTh5hy2yFveQHHbIcJwS1ZwTQD8T86dVxaE
qzzCoweHcCqdk5BQnMduGyyJeSjpk0ZESPUQkFqn9Q0rN+JwxrSgB/MuYGCFHbiqZF4doALJwJUv
mosV1eMqW7fmEK2vUBcwmG4vqNNtYNQS75jZrt5uBC72CF4ZSLPiMBhigDwyha66jGz54mUlV4nV
lEeztcH2ZBLFIkMTYu+RuxiKq/bKULbGxdj7lDxusnqItqn3Nx4ngKcgFwEibUa8MYdbXU0I3ncA
RrudN+nmBFc+CNwA0A+Yn6lbiWbZjvQCL7qUCVp+q83BTeFFwx34HJDjUOnaNAE7pJtAN9GOgHxv
E51T8L9wQH8sX7N68svZPVNncHmANFkEqSmHfEY28le6IKX0mJr21MBOICiuXqVAYlIJZhniGmA5
ikZL+yhlqYFNlv8AM6Qb5i4rb+YdpRwVUVtVeSuOh1RUZFXNhIcEO3XcvQTy5e6R2rcTKV5RSQDO
Gakb/aU3NeAZTgjTxUqRIoHGNqhNOnAu4JR7MsMxdlyFFdWVDDGNWlrM0A0U2GDX7VyLVzBmalfx
YRKye3ImoRxaqwIFa7h3g/L9RxajSsUWA0OwivuOS6Ydo1CSPEScV1Pf7mNdLXdS7BHOQuxaKxj4
qLUWIBs0cmbbG5G+b0OY4eQ4YhxW6xF85t4I9QehX1NnA1UFL6Th4QEKXVPMbwC8SpehQVBHxfcU
eTRXKZNrxuMvdqbRkgV04Iu1wpL2CUh5xUcAcd+YWNLVRwDRe9Pm5fFUwP1KDtxZxHddRDV7VQYI
FJwEAmSnjf7LQL5IS9RAYFcQVipyPCLgMvUr8R6lYwEouB5dfVsVDSPdcziz+IgSd3IDdFS7U45Y
XFKwfZAYPihMIuIar3CMks0ehs4+eHz/AHH28bASpr3oBxvmHC28P+I0UXDr/CbACt5N/Ev/AOnL
55i0+40uvLAAQaFOSG6hDMCLyyzURvqOUsigCrtj8f5IeSzSiF2GCuBhDnubdRvRbL8fzHVoMyUZ
Vu+mCmzbuX/UWtzZfMaQuuYOGovg9VM2ABwH4iR/qBoXxG6Ct3jHgtSEvuXbxLsBvi4WRKw/ucki
9ShXx1GNqFcvUs0Xkweth3cJmll21+adQRm2PVdeJW/Kc37jzyINt/MNJRqmBmVXBFAKo7qEBCNF
EeGxFtgbzJON+KjPl61V+yM1g3W9zl6ePER2AqwSAutxwHbDAkOlv6h5cbSA/iOTYoIJhOdEVeF8
3DCAUNRUNS4FHUUui+RiFLKg2uXFHcL9oWxecxxrbHVZXUrSJKVKoo7FKvj3LoKZ3AKobEYgSfqi
smyyHEsc/MrSOcwq9sW6jbaQXLK6iyxg6VEoE+ydZw5hXRj6g5KljEsbhUDLiljSooX2iJmviIVf
mO+SPq24ihCHKLVdMYmOy229GC8FRU4XUKnogLGhABSAjxFcOJwAtQbrrI9yLKlLlCr3zLifyQqW
RT+XmMNK5wQIF3cJgVXMQR/oRNwXb+INDh6lR9fE4NtuWvO10Sqcb5gKQsLNjsPCZEC/EQ0rT6hQ
ULIlSM7Zc54gX7MRDqpYD+pdRMUKm3NXqw5lSpmrfLLeGCappy5ZKrdZMKbQxBpteoyl41F0wWEr
OTlSg4ekZ8H0Q+G3xGTABdS1LsdmcTYI6eBcf4EKrnIqUqoacwqJgbXqIkhWKHED40Ui6QJG3ZqE
ZuHIoCxvhG7FIsSoMVrCBabzUGr8QWLsGLqLy6tecRUngg7ZFc0R2Jg4lY3uNolFDuLZNaCnzAKV
PuM1R9zmFwrkh2aoLwtRsB1b3BFV6KVLPLsRSao16hZgmhhBIVAEF5LkwdrMOCZBFsEPRmGurgca
l29IOwgsQ5l9Ue1vMuGB+hPeLSbUJma/nZUrU3gIM1HQ4hIJWukOu7sIvC7oSCg02aPyh0mNOGEG
uoGLimgloqoikCKEQvR5AjtIfcv5KDI7+54PkRro4jbJz3jBxAwYKL7+YkvLbBdSztXK5ETjutag
BVSvGETwOnMEJLb6dxvjy6u3m4OFDX5itPLXayV10gAK+LlpgQVu+4Bk9AvmBjZPFC/zOP30K2yU
0Bosp+ZSUFUQH2wQhdlh+ch34wDkBg5YNLFt6mxZ7Cq8QzSNTFdQXAhU1X3E02SzZa3boQncLApf
dRcEUqoMYgtDB7O0vuebQ4IFeBcnxCnJB71/yNNDtQDRc9xEcrCDUciivqHU/E5RKYHK5lSwp4i1
aqAwY3W5wNgPy9WnE8q46qOo1XCtfErjOanEFi/MNEnaC+fEGA95m3EqjO2yy5V2DG4hQS1b6fmK
BeVqKu521EKyqy7Qfar2hu1QPSFKUKqrh3Ei0l+pojKGQTkkeWpdlwYC9rIaqtv4lEBsRb8Rasww
NxiLSpm9oroe2ClLXbnK+Y6w7Q6Opc3wEYHlltRDtRcaMA4eUD1AluIwC3Jy/ibbvCz4QARNayAJ
boeYBJCgOiWVbuE5iXQBZpej5hliY8N+KlgqyjySy46ueUK3IfKmwxAygfoLhzVeod9x/WcC6o/7
CO152UfiG3AH5DUardGXa+408dDc/Etc7C0q/qDslDe5kjYLEr4zZNvuJgYsXT4+4G4FB7d8SoZx
wUE/ZAVBOhYG1UCLCavPLnOHwtktLuKeVldxTYDC29PEqUcCLB+IAxRlvQ8xXwaOgLVhpl3HV1TK
roUcF/8AZr4dL4ZRnQyUOkA0lspKPCYPXzHje3CmjiEHiE6FZ/8AgBDZvcV/MPJF8E1v6iFnB1LI
LbKiu4Jt2ZKW87FGgxQVVXywfUQRkdqcSteUNXVxbFZCiu/JGqxkKLyxOJlH6lAxsosKfMW+HmDy
uANOssWvdSzqclWBLFlX3BxaVzLEBGDaeph5tYw08MJBXManl+I5sC+4abUWoH2QE2o3S62IiuIA
Rc8TPtnkiAmxD0riC8KDzDttHE4CxKIKAgmwtgRgr1E1bqHRPuDehty1P6my+Y6kdiDeVHVOoDau
4+1dyguL5gbW/EXgRcq0eojfvMtL8QFy7Ujd85y5XkhKMt8EUvblJB0oN3XaWUueYipV9WSq+Uvm
MQqqgU1zxLn6oC+rdUw9xI3ndkajsA9DqNQatdlw2ZVi/URc+0YStFC8eiJihbWElQCpy5EvUHXk
jiKoreYARLHzNw8Iczgy0P4/2Xmbp7L4iFr6b6lbSbLihlKDBVXPcO6DCOW9xFpdbL0MqFyxUOhL
5Xkvmb7isFSrUKf3C4XBGea+jhhuaUpoOjTwjbAjC63mIwVcS7l0VNfwhFDuOAuORDwubjzIilPU
PbUkWEW1/wCWLh849hHdxOnTEq7qASei1r4gvLBdQDJHwYBuLfvqIrC0DnmGmsukrjY38U1XUq7N
y2OAVivCx8VBRZFUMavT7yWFHoK6RQRlabETqOLItDJlpChEvsbConQ8BEIW2xbZ3bw7luzjtqpT
IuFj1Hw74qPuLVG1F9sk8Q4OwPyMKRzmhfuENwIvYogOTWFXS8DdxYTXYXb5gRUN2qv9iv3sPdDV
UaG4dQHUqq6P1L+yYeCWevXTEDDEenZ+45ecGirsq3kd3n8Q6QaHSICoC/uJ7jRS8j/XtfaJJx0K
zAEj4BGoiLtp5jm5u9eO4CqVdoVxxAMLSid+pRgBsag4ill83bPGfSbRW/iDXUA7LlL1ojdPqEFd
wFMUxn0dzLKxFZYFjFH9RMPKwCfceobYKHESuG7NhGbVqzgY9MX6ut5lJDBuKKgB7iDOCmpcJz6t
a9riKNOhQ/MO6yXG+IZZa7LfUsWqPwjc0WAHDzLGylpSL/yB1yx2ESkwNBSFppSxHpgCtVgK9sE0
0bWfX/ZVb2EL63mJvy68QVy13VTnVwaIJx4RbOFg59pUMX9SmkivIkMcJS7GcyrmiTay7uBskpRp
bq2P6rTD5hs2WxaSnOfpOyJUVrNd0zhiHIKmc3LU14p3VwpRgTtVk43OIZnMIL1uwHFEKg0A5VxH
TOrvolXoZH1ZKOGETwBLMmGlHauU7co38KlIO4QXDLlyLdAXxLlTpefHVxOJdtA8cQ3ERKMKbUoS
mtd+LmkjFJffDDLXgA0U7jZBgeAWXJUd5fKRGJiffonC7V7lihbLJ3zOEtFOGMnI0ViPUp50RWHR
+pwAOgo8w1VCRnydxE5pWb3v9wSGNeA5D1cuYF861zfGwhLTvhJT/wALvF6wLKhd+BhpiHbfniIG
0W/1OdG62KSuMQDpMFcSkr+BMgePEAWdIHi2QLQsDfESlG7gNXOAbIF3PVS4IRgFluoBYhW72+Ig
FJbLkOFKBAHlZBRB2Glq7R4Vlg9ww9MMeZeXPmfkMeMha5TOQIoqgYtTFR9Sk80tleWJa3XiOUbL
NFo6gtKzmN22AOohds9QClNEqU7BAEUE4WVAOygKluTruC3VEsBVRRSGi5ZBqyKwuiWQquZ6h5yI
QKUitsBySzLW8Q3TUWfbmc1urLlxdsqlu+JbVLPE6jGWODOCWy+OfUw0HfUaHlLC2wgiC2S7mUdy
wNyDRpNs7i15VsahNuc+BU1U8eZXuWmleGHd0WVzFPGeYogUYap3p8zjasyotFHJeUF8GNFeLiuJ
Q0ziyWbhfumxE/ZPYkXetbE8w5tB/MMC+aEDXQgTp9JHuwT9TbuwoRowW0zNuWuYhBbT/wC8yonB
K+a/yXauQp8xt2qo3xcuOAkIoG6jtFkIVVRu3MnAnI9MsR+pYNbYKBTVdQ5bIFfFcR4ppHanA1bK
rHHPdMeHUEa45D7mUnR1T1Fx1p52pU+1Q4QMIEfreZeA3R4Z4k8xAY1qd7cDOaMO7yUzoP4I7lxL
fDcruHpHf/qhWY4nzzGMZrrxF2RzgSzrJpDutmUI9lYRYq03E5l221A3iOJubDuKLoH3AbOick6r
7AfzO8EuBt4hggCc8yw4InblAV0vrV7ClAAKYrQAzqzddbv8RP5QB1V1Lpr6AZOG9BxfEFnLArvJ
RONhnrYM2MPwwbdV11fcPLsJfiDVRcvzuzwokJ7g/wBn0ov01YeD1POzc0nmKTYCHBx3DypCacgX
AD8edlVOJEz0yxLoUOhwSxbYflKSUUPjKIzyppfmP80wdNsU21QbUvcLlvS+pTbrh6NQ2TiA9yvZ
QM7LgsBErhc5ZYfspfER3V3ZGA83VHWHw3yx0a5jOWe5U+QzsgSA5YvgNK8pR0xa5VwLTFFl6NNZ
CCbvxFSDQinu4Q9J1XzLFLSE+Zc/RKerZn7tbEtBI2xzo8lwBQmzkfMQPoPKBDoCpV9RnlOz6ivT
SpFTUc23gCd8n8Syu5DrhuEhaxC5EEfGEKLmM1EC91ZCneufwRjF0A65Y9tILrykGJw3Hkg1XdMP
LSwB+RjtxZfH4jsKVpB4j7nK5WHmdoW2F+vK6Iblqt36B/UPSrBaWpjbYJTgS/PGqIQo9/xRhiQX
hOFQGArJ+Ji/OKbKv5g+jxsvi0r9SgpsIrv/AGMJd991sVpFpXi4PQP8E2D/AASuOTDEoxd6FX+4
xgRcFPFwySKKh5uWPVUYo+bjJgBUW76ljEBVZxUqLJ2prtXK4wqbkf7HGtQHvYGYZ238/Eb5IA2q
sB3GUC7elvBg0BjPCMa/a6LzT9R1SmY2X3seJ104LrqNjwfLaupS/ajGEb6hBZpp74hOSurwPP8A
EGMlc0tQT45lwe7A21Y4g8Osb7nGAAwcm/iJ0EBxdw1yGDumV12+Klhrhe50NRtfpEYGywe/coF4
kbWczAeDBAb5mYX3F8O3UaC2kSbVfMRw6h0msAacMvRI1rc3mLfIW65g2+zuATUAKsBsqr7gM8kt
DlpmHzDYcSlmJ+ZAAtVcwcPJH1xgnSKquQ4is3jLmJycyoV3LWzGJygpBhABViGl99R5rr3DdFQu
yVVqxyGDWrhH+0xc2BFpnEQAupVN7kpesdH6lB3WOH2RtfuagyFg/kQAr7iLG87IcI3AWiWwlf5L
dcSoBcfUDtqyNIhZKVXDmmNlpu/MCG6vxDhefMpjCdxbP0IqqYKebGKjArzL8vwgU8L7g2yrVAAo
VyMCmT4I8LZ8pS2294qUlKQJytQHglqAsNv3CeXgli2j0TkNMvy3eIwwHwzgLZ3C6LIWrM/yE2vm
9pNZ+rzMbZLhlMlavUH1WJXFykopeedlUEuin1EFSo9IsEummZV1cRAPgHqz/IpKw0wwBuJ0lxIw
GF9cxY8ikYLry+YW6nPBOKD7hpBNc4lQ3JRQl3Fpq85+JoPEONwRGeLyBR4SjQMj5ai0bYOpWgHb
awZdiWrh4hUBWXU8zZ0Cyo1FIvu7hczttjRYZCAcvXcQh2jrf+wyKwLMR/LGvuFvBfT43/YXCCgN
9Q0YnAnPMYFxBfuPRA5HGQJCxFPLDHPadPUFiAhcPzD0Bh5uVieZ4OAN1HdPi2VBwoIgaw+yrEep
gi4Okc9wUJfEdHSzpFmartgJX6O9yS681NvLL04K54IKJAGjghRXKPHMpHfzkruuwQX0RY4S5+WD
NYspiThtoPwSmvSquOZViUE72U0FnUshhRruFAa3Cj4ZR7FPhYQs7ty1wVF8mCD0OR0qpd/EFVxP
KpVnRRjzCCqd08xq0twurAwHUAtrw7iMLbWj9srdmxpkxEwQcLh4vCQunLCUKUdhW+2tfNrFbmtk
aivAEBtGBFg7P7liBfvYQxVQHrEyWjc9aPh4lxzyKEV43qn3OsDTbp5hBRRzUtSir8ykD4GR7YDN
ZYnmPNlUNfglj8UN0eM4ganQCsLDt5hLaCtkBiGFIaqGSO8WMkUeD6lKACIH13Ao12sN+SJEZQBR
W/MDyGwC7tl1ArmhrjN9xKhguhx0/qKJgt8e5rQJK2S8cSpRKdRaoHVar/0hlRm6TSXvxQgcOSaZ
YEJUzw3idHGwUfmX5E1HwCEFFcoLr+IBcAixWRMSDhsfKx+t14VZxcbKAS+L8y3ha2b+Y+tdq2V4
I9U/oQrYFUC+omY6I3XnEaSCTyMQnVtt+kBsEbOWCyIjaAD56i+iKJofAnUa3sIZ0p66JkksLS1h
xeBbo5XxMwrIAnNpCrjaKOK+5RNgjQ8RFstfiAzTCQ4V+Y2jNua868y/5eQP6jwDDnEObhUQALmx
14lq9ry2OCEldXaBA5IqHzE9eINR4l2kD4hxfQcwQgCxll12L0X9LH9VFp8uwLFNwxuASfJyPTKA
Bsv/AJKUAKE/L+YrdAB5i6sVv3Pl67lFQ6Mp/uL8im8+B5ipChyvK+WKgGOY7D7luIiGNyjS3Ewz
jzFuwshs1vURd66nocTFRz1MD1KUKN4jK8iAf3EcUbjCzqFEEqvDqXaitMiDJhFY4gNKKChfM4Jl
O3EjP3E1jEO0uW/NxDrw9EDy7yMFD7nfdjuzrxGr9TbrJbp2WppK7WT1Dpv6lH2ZwC38StO0U0cx
qHHiG9M3I5LzUK58RXtZB/UbqYgBTb5IDYcErRy4FshkLN8WQ7b5gm3dXrKorY5iUMaqiU8jcbvi
G7VzBTTEFRyQWt5viCilDzsWaExeaiAv4gMqaHE5VMeJgNfiOxRN5iWsSLbbtRazR6lIscOo1XzI
qu9dw5AUIosqt2fJDb7LlSrd8RhPHMoKB1HRRnLGmwVO47ilra8Rbq3TsrXm7jBKGJm5gWLsIgYA
LjkbIulS3fzA3QFc+ooxyFLUoivG11X4nhQFYBd59wR/iBJ5EgLERKrN2dOA1BxNhLl7BXBqwqKe
s2ox3v8A2Bo1V9x2hwrljlasMj5bPiVqO5dtnzCxe/ESoyBVEzzP8EF3D6m5CFcQnFw9h/8AJdjD
HCVQptrAy1txcPs3/UBHeWL75gJZsvHMq0Dg0P7lJaK3D+YZJbGnNbUCggwDO+YNMLkV/cx5tbeo
a0NUMH5jowTS3/KayDsKqZfKlQ9yRReH9x0HFVqpdBrdXmD6IVu/uL7eKkr42O5SNPGzdKGNXcXU
Htqn8xX5e3XuIImbbfpD+Sif9QZQO2D5inM8izFR2FkSQTRtR+I3dVq4Y1b44/0h2JKC5cTQitaF
wCqe142IU6TIfqed/YuQdSWKsPslQDyqU/qLc7JzUZVkiJkFOyi0CWgTdNcS1Xru5CxIy7bPmN1p
oUz3tjvYNdJQbZGAL1ReRg/A20SAApWHEsK7lFkavgWHD8wAEudXBRcCi1vzLizbQQiGMOSvlCgD
co/3FlbRAiujf31GcSUUX47iorOQfzGC1doj4sHmF+vq5UrcbMeDXpn1BwHtBYvrZlwtaSkR48Sy
tb8DB+I1DH5pSNehvuMysj2dS5maeRfnxBiC/LT3FUFVuLMx9IfzD3UcV8epYWDYbPhMVTgKqO07
g/4S37bp4MKToNvibWNo8R8VlD/IQqMqBZ3/ABC4KqHCeJeOrY9PqITeKyjXiGDFr9s3R8GeAgQP
CHjxwQXfMe1/qNzcExdYRSBRVf7jgW3GxL7pytGHhPvuN7iqK1FnSxo7mF0iQ1WyqU+uYhWPJAxH
QnaWA9ywoDfCiP39gqFXioq/Ko/mULthYn4lZ0hGYtERH5lAE2cIfcWbFrXVYigBVKB9Rj3StrLD
pysJYj51rzcQKlhROYF3OzK+YiPRVtv5gIozEgQBaluLxq3PLH8pmOcg4+4UqjAaSAbp5SVcV7Qa
gr6lKQOFwltqytWVepUri1puVV/MN1vtQ/UElt94/mYKFKR6PFQyvA2Dnm49wDzzEU1OokHDZVC9
Rx1pxv8AfccJaeIcSGWtHuWAh4bBxtljgsMi9hHBwHJZB9tlRY9q4cGG9l5ZfMAobBKLvFC2DaiD
hv1B0eWIDSm5QxYt914nAYA3g+4Eep1+I8DnjIulq3+JX7tiFJqOTeeJci1nmLY8k7iLePUYoDUF
KxVHbuBXvYi6Zk5YvuFtgWIGtv1Holw3rkDxyMWI4fMDjQ5gRb7Zyxpr1LxXESiorEaPDAjcqc88
wFLWGQB244lzq96hqpd33HaLrzCnC4Z3dQAtmxKV33kDybYl9/MCgvR4ihVkWBbvuJFaZS003F/P
xG6W2+IGz6gtlxR1cAaJZ8WwAo09wGhdjLwJUQ28itC7RAOReC9qZXxXP/4OVnJUeW3iqlgG72gm
ei4cFjxpSHDIaEcvhjKBFuCdwcIHHJWS/Bp9EGKT3CxrcTISeQAndxBCOwcERblvbzBBIqwCJqy8
HcEagY9I7C1YKRONqUkfkJu659RKu0sVMLiY1ceQXq2WgT5gouE6grLvgiSgoYES92sipXiQuirY
0SsY2tELsuPcppczlK/Maj1wljpwn3HLCxIHRNwKUlGJTjzF5dBVw1YBokEK3WFbYKGKBT4BH4jg
dMHyrb4pQVRphDWUP2uM9RLbKhnAOeU4KDAJBjQ54wqxxryjQi5VCGlyyurR4LiOxYWulCWfxEZl
zwx9tNuDhqMjW0sSsfCLVjmNQSkNMZjFq+P3AxjpCKMgu4KRKGUlhWDlIctbY6AfMccZ5GV+eGS5
otWWE4Ihc3HiGc4h0Zw04qtEJX3SwfxOPpxAL9QVQ6fD1GsB8gcx2A2XQqLbS1AksmhFKwvbImvs
BK6h2S00F+paKs6oqNGq33EdrDYj+CUlLyojYOlldWKy0+DiW5xXhFgfOCGeSnTcNq3on5l+LKQg
u0pVdxvQZXq8lB0gmfeoJKxBfIZaSopVcpHoHqrcuDXUDmV19u6fMQ3WKWTBIIOGWlr2GW+KgAp1
QtXXC3EZw24RWWzm6d4k17qNl+tFlB5hlVV0BscsctPUycejALRJYExBEFnRBfz7qbAs6Yrnp6Y6
KAPUcbOiUkJ2AdkuVCkNsgdpri1n7jZwdLnIeCRgU1m3yiGgo+pg2W3UaWdbVbH12FKhVXwqFVuT
MVdjgLrPqOvcDhFqBVJZAZ9qgigbSYVxHyU4WVF5CzJaEsavqasWIlFUaGo1BjSs1xnMZoKZgUod
RlvhzfmBVhxtmU0yqFzU1Id6z0nBWgflm8ryFQUiou5Dro1bWXcH8G8/ZYggW2/4cymXsOS/LHS8
NTFh9g1it8XcPHHWW5WgWJWczmIHiKOzJGiYANh3TyOfd8woUC1npUJRF01ba+SECj9SxUn1LfQ0
gW8ynUXRLsK6l4ioPOL5+4gqPc1BS7Vjgg8Uj0m1d0e47ucdLjuou4TwMrhWqHIRuWFsBMV2HXiW
I7VODoLKVmXBAoRAI1MO6VFZtMHS4pf+QepgxUVD7lmlPi5o3QsFIAabrqUpmVLLYuJ2amyg3ajo
kM6jgN7zLWeCaU91AoTJgiLd1UIKvmBS4NINQAeVU3LLTfEoi8xU4G5MShncs3lfERNuRA+DiWvM
6eO5tQsLjhRtjq8LBCLw9w9ojFkFt7EYeYpYduK2LFqiGgvn9QoVRTsiotGuJ8COPnuWFltVUQAp
bEGCslFXzA4WFDnD3FfLnzCtYLiHqiUQhg6xRGhu4h3rARLP6gh0PNywjYZfjFOwyw28RbDfMpQ4
fxKdLD5lmuRw31BX1eVkobQBLiPVTQ7u5o5VlqCKUK8sirYAAEqAWcF5u4SJh0SuCrTiM2xs04uI
xhcBG/mEwPYgMIWcVApyoQ0ghGvaI6sz/GEjsCu3cbKAUpIBAA2SKVKpbJUjG+4kHfmDofxArZm9
wbGsouJbLouNwx2i7BCrIols+YNJ+IIjpfKDzMgaZGXtYEaqOWiWmNKeqAnY/Ff3GjpU6YIGnXap
4M7Spdog75gmklLhBh7YrBwgKaVF8MMAvBjOZTRpPKZSBSkDukp2LhyzQoTwQWGC0m1g8cqFYsqR
h4l9ZPGEgdhOCcLCgG0SMsGlkZsvH8kX5Sujk8kEJK7scbMsyDw0CfMIroBwprr5hBarUxcjLXPq
WSqrlTK0G1aGty76gNVZFMYrB3NmmR/uKYI3nDVxKC1fE3G70b6lPBsQPcPuKzkLr3CkCqlAL1UQ
vGm+Jyqk2QyV4qg/mJRDBYBW8w2VA6PzCIq7Mz6hi/EbB7UKBxIZrlQ4PzBzMii1V/5B8B5fbKFA
0fwmcxArFC+4KpDr4atlaJFup1CI0DbuXgeghL2xSASsXvhzNPkh2C8TIYhdHuPgMhP2pdOriEBW
5PsqYD3I/rUr33JWB4ZSZAi1+YBRzKBf1EEIPREqWJwO9uY74Abb5l8nlscTg7DlZ6jqcmry6iXC
CbMjuplcyMnqvDgj8CZZoiNFtrvwWJ3TjGvAxRolYc6qvtOxaYzf7lzKHReau0gKTXuKvi0I60rm
pSw0cTDEFDoix8BlRl8Q7EN5l+Y0LYALPQ9xIukw0f4lCAHxIIgKjoe8i+AQwCVwVFp9Ea9QD8UY
LlJ5wilIpnU0dHiEZQ4nwh0IHQbLzDUrVeoXvggAmbQDp03nzFQmAcXvAx8EN4FhBYXlB8GBHl9B
FXUrQclW0KlkQrqdGVMt/ZGPIobekqCQBJRfaZIoGqo5S8l0PIQ6fMK1+ZZ9yADC1/mW1q8kpDdc
O8B5Dti9ljgUG4LEmTvoVLfYS6Bt+ouBYT6UfuGvutzV88RJ8BssXwVLVrBcs12XdmkNy3+pb82D
D5gIhq6LO2UMJ5WdsCO/dg8w7Ed7uvULhGQ5EcvqIYfS5PdMESZUKHvYm2vELDW+4zKJ9UrcSiC7
G8wTtoHsM0eDR9o3VzoYSxoLBb2Qxg49wdRcJop11H+KLdjzLy+lNQpnLb00dbNMXRMe4yK4qCaQ
t7BBXEsaLPU0J7jWtxCydpjwagF6u4o7axqzHxNMdoioi5zCO0Kl34GJByaRBJfmAAqmAA3R4jUo
Opgur3icAcMqCvxC0dBKaXoi211zF6YeZQ0cRs24Vzz2TpFvuGumxWCFQUWMV11uOhlsC/6T72K8
mCVECN8xZSc9kNuLqBOX6hcDseVnMQCoDZZLXfE7PBMXeujuUxqjuVanTogV7N4lVBBrHfFRgE/E
MKRausapRZ4hVNzs8TCujtC4NsXGFDnnqAGuFgJZRc0BjhQC2+4ry8ZUuG6dSyO3hAhCeEN9nI8t
oHETQN3yiBXrJ5kTfUAulfzBqbgi5sL66/iIHhSCGIXfAx74AJZVy6uiJrjmK8U3E1RFDzjNEaD+
WHl1U6YloOh/96h9Nww+udqAbf8AymXoU2B75incCb4uVaq+pzDC9Mb5G4Q70g6XTxF5HEvtydSA
3dxeVuUU/SDSoZ03L0rXKgGC/iAk6hfklY2EbifA9Nu4wmlLnGw8VZ/XmHaspaVFuS2euYL0yAHi
iVTC3PTGTFRtBVgCxtq9irgrL7uUMqiVbzLoqL3YZMaD4rJWWWqGUFLEP+Iwa0VfmDqy0nVynQKK
9bK2QWro4gCJwuNepRuBHqPlK0Z77ixumhFmdwae0fLeIBpF3OguXLJRKkEsCAbrcIdNbSxvqfGa
kYtdd/5EFR4RwX0xaJDBwAOPBlmsFBOUdzHeBbPcLg9cyr9wOcx1TETvCHS50ZSxrCHqEWdjwRju
EO8cHupZQbWwd4jwABKDtb6g56tcKrj0RFI7jDkip/R4ib4PceDqOl4+YcAS5h9wvpvdYaqz6i12
EB54jgafzRAKWB/l9eIgoSW6viLhUpV6PTOgMQcXVMeWWgnGZcMhGivtFS0lENdP9kokL5B4djbD
/soCmRi1yPGk6ZsfqXd9PhgMWhPYkOKbrm1EW39wNbLD0kGXbB8wKqXoZtRRqboL+yiDiIAeZ9IU
V3Y17uCyp6+xIxtG1sUmCSr5qC3Xa6Nf8jLW+w+42oDdByXJz86TY/E8tW9zkNAoKrIwrSxwD1c5
bXpHPEPscpuPfiPVQDasvv6iubUX2iG3S6bd1jK7iBSioOhMg9eoYDPH95FIBBEVOFIIw4ULI6QG
dr6l4FA7vMZiraUbfFxLADzF7OcHRfvPcMmJZ1zVD9yg2vtiTcDj1GhUukxQjSc3rHpqFQHM14gs
z0AtIXedSkIg1pcpzGlShSi82LocAWq4puVwcLmU8X5gfnxjZhM0OcKhDVQ4KMgkw0+ceZ9XtNcQ
Zbf9lRiehfLt09mQjo1BVAX/AFN2yr0V4+pinpuDfbL2S0BT/wC4h4jezXdeV8wIkd7F9suC6Fda
/cuLxORXF9BFOoVtcXiMwJ7fnLcS3xsUrAf31FLrYvChXuUVhPTIWpBw1ncoR6scUQPgFLoT/ZXV
cPS/6iJPysVOPVwlApnWXCqAMUV3Gga0IVBraWXof7iwPMgR6OYT42U8ix+4jLRFOiyPEW7PPX7Y
2zAK0q7IDlD4JdbKAtpoYa5ZApPMWCyiJSzmYFkAziFlDcwizwSo+AuFsxOVP6naXsABy2WCrW8S
yFag+XT1C7O/JMQKqeYC14ne+cw3uohUPORE33dUwQY3PY+u5syA0eu4PgQK0ZynEAiUjqVXyXqU
oCiBHnZdssuPe4IXVBdRV8/TCuDF4jpaji/MRltVDNkvnlsSwQFzz3EFX7//ACFgvETS3MLhfPiE
r+ZyPN9QNOGNjmy9U/cXOTux6VHmOlgScCrLgJXJjVSW+pYHY+eosG87YZZEapuR1ehO4rGPqOi3
N8k526ZG6Vbzfc46LYJNmXPQRrKWwJOriC52jl9RtieBzMO3Q4Zo2m7qIGuGy1a6BETykRAuvct3
oA/k/uFgFTF0rv5XMEOtI6CUKh1NEhFBlUoxFfudnsPzKhw1CAImcTv/AMx4FX39RbQykaqbjor+
P+yxonIf+9xQyt/DsfK3T8MRxu7e3ZxtkHZKuIUV1zBJ5eIqxVRAUjteZdNlnQxXbj1MOpzYyNSS
aJi34I72FPslB2y8+YSFQI8V3+IUOiQtRKnXLxKJwVeyLBXY+1GQnVaAeIw9y18ShKBZgWcRuxEq
8xt0KXMAkuXbOe4i8sVPHEtrBfccAFHjBmqtEffKDNkr36hzVUO/P/ZcM0bp16gr9fJaL9yihCx5
2HeF2Bd+ISZIWxfzLjJrBUBYaoF91OVhXK6YcXhyGh/MpzY0PJAAHqzH3kfuEh7qVMpoH1CFpS1t
x97l3V5hRkncOwYaSV2h081CNh8hhTHMIUPAwv8AYpfVH+Qn0nYJZooW6YQ7EnF1zHchdtFYm5aP
ZrP5ImOhUz0R2alo4ZcJV2ByLlCzVH0yH5gKBQIPg8wEalTpuht9S+fy11nLG+4ZV/iAAWUXwbyT
8bqDwg8YpbjnmOzZQq9iiqAXDNW4KdYhbjj0Ev5NQetjYF4uG9jBsr5QOWFJ4M/uJiZAkt6qAi4o
Gui50BJf0QoAiNnfwHLmyBrYXsJRMUDhe2MW1R9sBwBwe24GjjX2ZffUikX4mW1yAJ6llo3jfgqV
03SX6YqFIh5xgi1LqPKd2frzYym7KHNK/wCyyHV/uXv0F9bEv7cEwI3TXTBU4AuX5uo9pBel53qw
Fy7SlfPMF0NdGpAqing6jAgvHsGpb+3r7AuXuquCHMMuO7SHnJU+LxHhSYF44BvWwkmNSfhDC7uM
C4jFbQNah2HgjSurlSworycyxt1afDoyxEiLuXhabk1lmqVlNVxcOYzWV5i0RkHFwe1Y727/AHB+
QBNv/wCI0cKkVBuJMFR5EEUsqbKZqGHAfVLHmCprb8kHrEpeqcauTaBIKj3ac3KpBrkvtexSULBr
QvslIFPmK7jhMsSta+mL9VLzh7uFHY0XSnO3YgAv2xd3UooAmvaMFO7XGbn6nArfXk3zLQVDTmrm
yy1cZeArbEi7zOfssLF238QeI6CxeKIvpNRogI6SRaEfc0yCF2TuuIkImGB8x/b5uRq7lhRDcoxV
jJbpnE9ECuri6u3ePklIwE9HuIC2K+WdMBPoA/xHJyEpQza+blt7YMoSxcHTbayN7CWtacr9SuRw
Y3ep4GEYHdvxGDEXFi9M8xc20Fr8S03mIptVdxQ0D5jOKx1NDVNUSgNb7gavPSVwKPEGxf1ACnLk
HIsYBa2vUAD0RhmFeX5hxPMF6EabjxMbdZSoRaTxKM+5yF1itbqZU7jR2fLEHxUapU9ZBXTWECcv
Es5gNJngjDrERdGeo2Y1ErcS1DUqi6J0zPMba6hqlFbB+kuy6yLVEyLZTRwEax6i1a4+o4HzN7Q6
e5emwDqX0yNLTYy/wMAFGdxCL+SIBVwq4+hommdOVKWufCIFooMX1ewTFauUoc4gRV1KVXxAq7wi
pncULEF37igm7tQtR9sKA6b5jVtDPpEVFqgZeyvUARmEIFXRzNwX5qXodcfEvYPv3KFLU7mwJTk2
C1cXiACfcqS9hdfUDvA7aXbiugwPD7le6APChXQuDBycNHVFIYic2QxHRXmWofoCZE1cItTxCI9l
vIJBaUOOxDlsfbHAU5OoaI3QeeozXV/UtbycMpG+48BXEUuVE5PHqIbG8lA3zAVs1FBHKxqXol14
DKgT7n8dIBiUDZsghLwYNCuG4ArkM2aQXweZfkulDM4hOKViVzB6oixD1zHZojYRC2c9IvMFsHrn
8RqvoWDx8wZZpPBkBEBgXToorOJaESqHmYSw0z9zU+ii01sbfNKWI7hrSkXCHiQm2PaTgHYeqhba
Wg5ihs7+4hVzbQv+Y5JsAXnxNJVtevzCltyiLjVMVSXj1MIxNHiLAA7R6iGvHNXLvfI3dzq1QK4V
vVhzS4DEbH1LfTEv7JXTWUG1zUqDsEbEgPcXjIJ4EBG/EcFhzlBKXQnB7mhGVcFcTY1dg+7gicUw
vCMI/ppUNo64UMOmVaGe4Gds2/cux21Xc5uuBfuHftS42NKArC82Oxqag+lRevlHyKh1Q64lklZN
5izgxWfDGKspq6TacKTLg6ZcMhhpEfufo8csjBN1T5l9sGKru6jmKFHUvlgouhwy/wAXeBJhwlyi
08xwxYzX6nfD0j+YHv7gFfb1FsK4K1g9cwKa/Wx+MIhv/sZIV1Ovia5XmF+olYl4r4jBspmga2Pm
iS07Mmu5Nsz5mlZNClXDzICyVXFdysB8KsX/ALGzgAbtb7lshTtfsxhtxurHxxBHiwukuzQkvjbv
+otMcKosK6Ay0Dc6lG9sYTg1Yv7yV0lhEKiU8gvnbqLp6LQz9wdr7syqDKaUeTcUpznAGf3c90li
PyStYldX9y+bYfQ6I4DUZw6G5eh8C/nevmLRrcjlbBYx9dZGJGR0n5ZxdbNt+TYOsaFf1MumcNfE
0JS33F3ss3mDdfpYtebjVMftHuMVTe9XlnHHHCQSb/AZcpRAeC4CWAhds45jXG5UHzK3TfRBKzqz
TB/ghhAAs2c5M0sFxfjYP6nC3leIRQsnHVZ1VwWdqtNR/aOycQ36HAXzGaqljfE/7Sh18R69Wmz0
JqvbhNf5KnOkA0ovjxOLa7NPvv4hTzmq3IeIukVK4HWy3TI6vxfiKCDWtMrnxCoJt/4XGpHZYxxa
k2ouXStcuzuQrBqkVs1ppr09xL/GueFy1vhpUAVhCrvQVoJUbFWr9o5V8xcbU/wERYbYZ4T9CBzo
+Io69ypbdviPNeqm1HyzyNlcRUV69wI7+bY25aRsB28QKehAN4CcQEVCxLsOohwIRWv0QocgauLU
Jvn4mHVxLOpi7sVaGAKcV3LgG09xV/suNXtFKdSw4LmxL4O1B0ZSQpgcx1xNFeI3y2dPmIBsF3eP
8zBtHEQQ5hp4TCqWkvA/cFbXII1NlRmQQdkgLapg6iyXVtHEBo5eyqg4igRs8TA+oN2Nh1zCwoFr
34iE6eKlMc8xReBw+YKYVuWwo1+5bpLi8N2BpqxC9xWObC2vBBQOpZ6mFwefcQbz0ExI1fJBa7rm
Wk/SXFtREd/So2G781E1lJ4lVj8XCFOFcRKeVAoJUK+o8Q9kZwKqWW9b0y5zYOBNi5qOomjLxd5B
lFHktstijYwH2NnsLInVn2GSwL8cx8y91mrWuAaJbUlV83ES+pZKLluX4iK5yAtLubNm4zZ4gUFM
BDWviGoeJhEvxG299Mbqox5ESOAKF/FQ2sjR1UtLuIFCq3mE3DyuR2K7OWLWj4DEzm4txETksIKI
6GqWJ8VKtxAh65GdEdFT7JZ8SiSpbhtlwcKtpgbyYemXlWWIv5hFVtwS5QJdyol8E9AEf1pnO5jC
vgJqbCumCMVo7SRFvO7SCDc8Wg2wHaMXqt2cSvCkqZ6Omq+44RHKqsbPnqEwqGXJqkuMMsEeFi0S
1b0UpQuTaeJTgPAghoStEPuUk1tIfcOJHCi8gypypG4tapbWkSgE51cOFhyWUfmPq4G2YpLO6QXJ
dlJAIaPlv7j6KDll1CclOLgVBYkhZLI8Rx2oOpUhFlOIbFdD3C+EXTuOlTdQw2bayVqoNumUMqLo
qLaOlbKjZxwSx7GAqKX0nM1hAu6RXWh/cyOigwIFT5BqNyZGDVU85hLZ47OpQAujUvMHlRCPKOIG
GigpiGiYKgOoKHYSuY8AFGtOJcCO4XLkL8HSEQqOnYRWr1EsIPUWh7CyKPHDbz8wwJTbL/UfD+x2
fErCrZfqF3r4JGP13GvUasQZXUMJRb4KeYq0tWOYKVY46gDj4cPcaGLdGtd/EborU3uEpCj2+ots
HItD6loEG6QsW9uCkFLhew9MqJjBaDr8wyUnQRIIXaFVDt1Y35iHeognb6l2wLFa/UNvIULViqAq
D2MMLPLFkfiB0c4Wh5Ip8dRatlU1P/MV5EqjV/zFz1IlYhQvSvTGve64w2QpJb4FwhCPC8sVb3CV
Ox2ld+Y2wydrD1Bsw6yIB+bgNYWPlFviOhRebMReF+WfmZoYeIEou04YCWarhlFBf4mF250H4eYQ
lVXfmDC28bmkXREFq4e6DalyvLI24Leai4RGNAVMcB2o20CpkV01hLt4yWtfPmUa/BAGBolHws2N
wceoFnQiLZXipo533LCzGgn2+YtijUGyXSzKtfiUAvfFy6BRQgbdeIgY3csKFvMbTzLy+LiFxFXO
mb4cEBaK/MsI5GD3I2iWnzLcORHHJKqghX9Q4kqVWzzHdLbijb18QUW+IUNtcEMX4RF7zFbUWsd8
qIqvwECWCxYlHdvYAiu3AWqHVrB5Jk2OqVfljegNauDsjUAMu0dgHuFhVnTGPXiUFexDa9hfw5NK
96S1kAvfBxGgdVBSmHmANJTd3EQ0RKpRPKCuYtQ0e57oscRMiwoo9oFJMiqBSdkS3hbfmPleuiJM
u2UTe2a/MQmWKfmHDwylKqNS1tGySYt4bfBEZMKTuJkRsojAdDSxgpIU44ghrU75fiBFU8PU4Aow
jNth4DUAXcp9oKMF45yMXAlHiBSW2rMiMg+ILxdKTUnE1qZ1LF1zEIZvuHwKfM1DnqZHY9ywX/E7
WvUan9RqcQhnY7HpQ7CMDQwWvEYiB2Kg3DZ9IbLpkGaOhsMoDvk5ZhvXo5lWL8EWsZeo7jQHmOyV
adOPiCSBey4GcCXcb0d/icPCESu1Ft1zL3BA2WhKqoNlPas0ZAx0L1IkNdULP9S8IBeyoWOiqKY2
JW0LFDeLMqZQNF+Y5SvFQ3QfUtr68QbEFlwPEsmiEDguW8DloBc7ELORRFF3gI5tOEF71HpmEAW5
zcWIA3Cl1sdEJgjh9wBNMZ5eD1HXoULw35i1aQBYnmEVxWCpZW2ZKZqGWpjBEFYstanDqurQjort
67llsdUqBPBbkRpxxfaXYnCkrRJF3g+lIqtLkrIcWVsNn8QkA0RyXX9y1kxTF2XhUBruN5cW3UQE
Aawf5cEbYOATZKwoAX68wVjd6MAsumkEF5HLQKAy5myGjiG6T0MW2D4y0ATB8TV0co6gRqqSuCNs
DQG5QOueOfU8DepVR9McLrzBclApCvFXLENQDAG825/EMUpb0z+Jt5tAOZQhflkrmVqHSIAOp5Ee
ku19ug/EW5gcHwH1OamUP5/Msi8qGB5ljPwRTe4HBQlmdpQY8GDzg2c0+JUEUPQt11BEw+AJQRul
rHkrB9GAQPXnmpo4ra1UQ03IN3om/GOBFZDy7UPm5nGWFc/EttYN0gEIL8DuW9UXH/r4gcYqB8i9
sbQDazl/MIRgA48kr5K3IESlamIVQYIiEEmMxzOTwlMj0SgGuIBclAqmrjUwhQsA4H3OcqWqWcQH
zxBbwwc1Q8g3hDFI64toj1X0d0weooXG8SjS7lFgcEri5gnnDzM7D8QAo8xWNuYgsAz9QJRt83Bt
Yw5vPqVrmChR2DcukW416h3btRo8VUxlu+pZbXE83HqKBsIWgGzuUnC3EURO5YNnzAJh+YbNndfo
jspwhIpZ7hxHh7l2LuW3x/cugMGdjrEI81PJfESlGmHQWrYMVab/ADKqUA+Z2Uy9cCFN16hRLjQn
uVWosMjaGXOQ2vJNMj6qKLKeJQx2NcM9k0asryTuLZvMc6kqIlKi+RKKioFiEWuxi6jACULYNqWe
I8dfEAQpROZwvmCz8I2liRdZACZdoFl8x1GqJd4tjelw6lFH8dTFeEAKbeRXpAhDmASw7AC5dQaX
cLpGnbuKK3IidXzAd6rxMyru6Y1xK48wBHiGrc+pQW05yNEqyHSMriDShQVCcmHUdNYniBbHmNXd
+oIRVDsFaLfxPkghLKt3O4peIujjn3EVLDy9RAQ08IAyj5qALP12E1gHqdQrVsCcBXI+9AfmMgEV
aEygISqracMu4AJwxeqlCV5liRW38H7i9Qttu7gftq6+Isupsa6mZz3HYqxCP1OFAHiSn1HwkdIQ
r5IXmS3bYlAO11zkI5iFRBBizTx5ruIwEtvRIgVcErT2sK7Ny945gLK1U8+j3CHbuAgxqJy9WEcA
tP8AkC2+zz1AjK4Exsj0M4us7BnEwHIDjBKalU4iJlch65gdiKSijKT5GpngAAdkpzcCWEqhQyA5
RaB3KMJwwHRb08XBGCBx4i7QF64KjGrsBJUApy6vIqVsQ3X/ANnKETnPqUOYb0XywNlgC197BwV4
e+IBynIg+zRiOPMrB5B5l0stolFdsMDnjtrllRcjPwxgNFzyb7hguNW8xnqWX75gT+ByqP2bhc1t
QiDWZXL/ABBd8wyhIBuvXJxFIkRHNH+I3hQhWvzGyRKOX8RpLh8CLOcihuZXecRFW9fKPMTTjmaa
wAAx5usQ1Mu9U5UgVRLYTZSvIQuwFA9w3q1TPqBsfWF/KHZ0SH4RW4WQpYeMlmvWe2QrO7yQGrVQ
riHwyGIW7C4iqSw8G9JQbqugeoGzZ8S0eGP4gWwLDV5+ZhdEA2/EtE+wIQopUnFxlCvcMYaj2epx
Dh1Kis20w8sHyWKjbxA2lbjgHSEAOLy/uOmqR7FzYGajauPIkRXbW54lwPxXX/EW1TgKuauGmweH
qBPSYv0HzDCkYeDzAJC1MPAZFkpKJ3/64ht7VakGqHKOR4g6HqD5S3bdKM6P7ZtjYPnbb+WIlgoC
jh4ibCcp4siVVkDyXxADHN3sF+CHLt6J9fUvMXhpEAhuLKacBL+2BQz47lQMK55ycSGoOw7jI6gH
EHfgqGKFg7+JXEoWGwf+x9khpVnH9wKQEKV03/yaAIfdGw8IheBHHVrQHuI/pTW+KoiBtRLU5f1K
30d6TfiKxM/PolxBWY8gxlq44G6CoFIuCoToFK+yBxY2zRv/AMiN0D9CDlxa/wARqgsi/cdwOe4R
FdnNEGqx8zYJR6jZ1xAot2zcqyABNIMso+YGDy1HcbuCCnXdzYEjRoL8yyx4yELcnNQAeSVFXiTF
CDiNlxspkESOsCVwSYu38QpxYbfgjRnUdwdlUIw2GhrI0rWEGlcumUnJ8RezDqGdLuLeAHuWj1Di
NvJxyF8QQ2S/cwPgl7LMTm3UbeHD+J27l1FqaVzknMKWsHyS1rLiKUV7mDbs6lh3iED5nIXVdQA2
+CaHHqDoYAIyYNhVV9wHKuJali6gVrtt3DgB6jarS5yWfCDYOrx5ibc9ELjvqpmu76i7X6lApz3C
Cku+50pmxLPD7i9D0ilUceYV2RUb7jCHJDCUs4uIlYeYWvISy2fEoDmomxXE4DzKGOYcKvichwiA
1qDkaxQ0yiUZH6QlvEdIcdxPDNjzDMxINXLl/MU04XYxd59nqWowO4LMAu7mkltyvEWhYvKwEKVT
GKzpDhiHPZXMLgVvEQmtQV8kJZxCa+I3AKLrmG/gE8ELa1rQeibGVoYCzKOS9giCi134qWFTneWW
fh8/cqDdpfrib1rjkhDAjQT5mKjqIGpb2fcAu0dfiLHWpDahG5t5qLYSpAKSxtv1Awnp24yqeog2
RUWW8QFiGFhUIpq1x3kbV06fipVzRbfmc2Piodlu4VJF6ih5OB1NPEbxeypdOvxAWMWeJmjbdPcr
QBXkhFWVn9ymalnpOUXkxqC8UQfBxGyrX8Gyl99Xa+ZcTAAHgSDhgDfZR/kwUInxcE1NH0IC4ago
yEzXqqgJ7EB1DhUDzWoOdr5BLh0N7XPBEegQZZfEEITLLt9yzzcjn3Fkhw1KBbw1+JfDLPkcxsim
oDBQKcNRc+Go0lHU4ixvlBSuR9oRjdNU8bKiXRwvwQVO2EfqNS4u5fEUZbOscXUIej4riXyattla
Yri6iwgsAUbUcDeUh7JgCUnxF0bRWDmKNtETymQ6/wDICiUc4uVguynkyGYq1dstsH8CrhsvX+Yl
UjqemYbhWEXtv9wKloEuCJQV0XGVL5SCYpS5npK2nxLaJQlWeCG2WVIPNx2HRu/UKVQTYPOxWu3f
zRctRh6niLJwSZzVTV8fwxiWhPQw4vJ9OR1rZZPewXjvXqCAmAHn/RNm/wDSglyvL8QrfRv9oWhw
HaN8SkLe6op+I4WtAR3pqVN75XhF6etjZ9zFdWp4sEl+DUKdstcNe2qN/NxcFwe/+M5KEkazOfxA
MfzVlpS/iJELB2vB6jH0AqcaTHoguGwg55gSoWCAPOx+MlPyD8xH65sU8v7gNEkVAvMBfRwZcNgF
7w+SXeNhDwxWC6gC0cIH4qLC745WKdiIa7H+oypZORqUaGNap4/c0VEfgr+5i4TilpVfhiL/AFg7
+41S+Ct8/EoqIFpa/uMMKupx5jojpoy6KlZACqKvIoMtS5aKj3pR5hXcHYnQ5p7gpzVleY/myVtd
wBt3vO8fxO0bLr7lN0bGq8MFFUs8PEsiJMWJPSidBiRbuMSqpeomO4lG+4IwOkuYyC7dSzFjEC/t
niacl7CiAVu8zwzOKnVVkK9kqQI0NLrOBpihqzYdFP3G6+aJZYXDYKPiWpdysBveIE1ssg1jBVgK
gll2MCWp7lDd9y0POwBnnzANdRCqc8RKvCG6qPUbaLkwv9zkpaoaMpTiLBZV2pwus8MYpYj4h7UG
GbeOpa1z3G9gcIreL8QpoxlnkA68xq8gt6fMSl9pQYLjPUWtY+Zxg5gnBF4iB3HxFb7vZpiGkdG8
Mpf+UVfcobxGsDjqag+UMHUZW0D5YdUseKjtFHJCngIkDzUv+Y2acTl1zFwp3KwvPiA0HEDk1FC4
qCN8y7VMUcT1EJxkaEqCrOZj2g2atZRVS3hKtHd3AI5t3XiX5Epg+kVIN7JdB4rZkNTCUlwifJ1k
0vArfEC6AuUdxNHyeo1U3sONTpeYkJ5oxYWA28TV5M34uPxQe4cqFFrEh4b3TxcuHRUfDUfSLbvu
4hIK222Co2tfhEBMtHluElvFfq5czG+WwGeHbUaacA91GhLBriJUFviXSNRdwEcMdl0MfUwxbHMc
i+eY4TBqxYaVxUqUvGH5qo9dCt8kbjSlTzGrlXxON5iUkqwlUE5MVaCchFZNiz34hTFYq72/7ObT
D+Jd3EsfcXkcD6heAhfeS0VXajLZS3rZV85j8xcT2ry4xFEFHzOJKG/Qcw1AFW4QiKnouMB8D5SU
KzbfuLVb2DcDUAnc9kKtQ23FQWaBo8eo9DTQ+o1AdCnHMdGWRAnzFLvAur2OOtAV0t9wMgIPpKed
FOVMcNwS/mE7S1N+YR91cGpVnlwPMHN3lZ9pZpgtf+CP0RHiYQFi08y+cQ78S5dXCorqAPL8Rdmm
DcjTIRBLhQEFHrZo1gqUEDg7nyeoVCkW+e5da2+QfzCJhUFCl6jQQtKvqLl5QiXtw0vicQJT6I5E
+YLQY3HHwXd3KyYMZxxcdNx2Q6yLuLO5jmKQfPmNOuEqqNhiFrod8ylcbqJxWsRr5P5I7uj/AFlw
pfDTNnNp1yEQT6PUvqvpFXDG6TOh2/FRlqEQOVuLBWjOO98S64KrutggLa5xbd34jjgQ0BLr9xge
0N7sYEi78rf9i0KVOwmsaRBXM18xm2ti6OvuNiKLOVuDSGrJfyl4yFWuB8KF8jguUZaU4nq46HSP
wZKAgMA1fj3EIbBaDouByWQvXpnYwZi91ARRVoqdRdVDfOzkVzZp23NF+VxV9xmpaKNp9R35qhDm
oqFhfJHb1sq+6VAXzC3mgb2X4yFJCvHLuuYBIW8PV57WX+qrHK+WO8YCrS9loqgGU0i5WIB9n+2E
c7Xqxhf4l3VhlkcssIkhpd5uH8nk1E2Tkk5Z+kovmAIEUridoyPTMbTV+IuiIaxtDI1DumXxLBrQ
qKen1FgxQTU5Hc7olgRmiJfoHLOpcK5bqJWhSvuW0OURo6XUpTmRWvJEPXMtpwY1VlEqa6uGk/U5
h4lD1FFj2hLAyAqmhhdl2E2q/UdL21uKiru/ELq7iKB3uBGnmN03EJyEWb5ZatL7jFl+IuELQKuy
XI38Ji3dQq68e4yFZ6h0v8zF6148R5hp6jvK65YHVUBFYrZ6iDG3BtS42mA+YqYt7yRF6bPMRpVC
OvUSht3BXiNtoULcvb4iDfjI2AupsDwZAouvmOLx5lAURryTOaRLiitQuWNL8bD7EMV7RCTy7hds
HmLgvfUc0bfEOVwi5azTs+46QCHmUXNssoVEas17gHK5dnNS41V9S5cLcIhZ5iXYGvcdxwQOxUaH
QlTlXmEg1DpehM8m8QCPmIuAWOoX0QUu9dSqrQuDZbNJCi847YChDYVQQrxBWdepcN9vLCluXVQG
l766gcHbmpxGvmpT6hVrY+YVFXfl5gZHQ8ncy4Xd7M9qPDABqk6lq+L1PFtdj4jsEpX4iXtA9Q0U
vw6ndaibT5lymLMXAcIQAGiNbR9EpNDC7L+YnUTaLbjqFFIdZ1xSkRtuXuqWDLl12WDbro0iF6LC
PNR6QuronRXeG30xN1HdTI0m+5aqXcCECmLQLHmWvr6gCle4rhoSxVmsqLZCXSuVC6+SVss0QYdT
k+gc5AlFFhu6GueIkGNEb/CovrZqADWbHxGowAmAPMK6JqKJ4h0ZAbqzuH2o52jGbSLibUud0E0z
XRKLJHuANoyojOCLj1F7S4TiItXon4tQ4+ITrhrUVCATbF+TUScTVMb97G1S4P4iOMpXi+YtKzL6
fJsSfOopnRwFqP5hDAVpX/cuFBVWf/YWLqUXfbsa+66YeptmVgOuFGBb9xKpN8KvqD20abNhurFU
JUUqB7cvmboWcB6grx74ywjuiws6wBpKM1fRJWCNWbSZVh5CBCB6P/IXdbLgr5yab5MKYIHUKP8A
U8BRsIO6cdm/1AckoLZUcbaK4D+IWWYSVYjii1BdwTifqWBgoCB+ZyVG2x8JSHE0AX8R7UvVsXq5
67SgmKHNiNTkV7Z7IbZBJSoBxB9f1p+p6wdOJcFF8lqYsyUQyAdzkoKdqO35g12AP0ZNTCy+dfLF
aLtrNa8xXfzVcdkptTQwnYG1cMog97GBVhwRlC9QKlumWDCW207GESOG9CCTkoGxqWRisBY1wbvE
HHIvmMwDyj8D0gVQmi5GGRyivCLn+Qsgvkl4llpksRird1BwiKPDs7FD+EPx42+hF5f3vIYEmA9+
oqFjucrCXnOTPTGaluS17ijZ1Tbl3GbiUgfxEIg2TcaZEz+9rcQWB1dubQ1c0QGWnQqXLt1lDfMU
qzisPmu5wruAqiFx7XAsHhHIpIHzIXly3FYt35gOzpxS/wBg+vMWL/cFBNXLfM2HPAfzC4zzQX72
GNJtAVWcqocd0QQbvu4qlnizLInlcqyUFM1rl0TgsRXQsviXVKFgtu289zhj8zSAc0r5la08nEQr
q5SW9QGmKOGggWumFgdJTfCNkD8y2jdniULTfcNEChja3axG559R7A5ETObclB0epoYWKLO5etrf
UbhXggDKL5lioLieHfiWY+CKWD4qUVphvyZbh4YIaygqA9VFyv1GbdxOyaQmwijlvEopZ8sNASq7
jtyaYLgtkJ6Hm4AtsOZtO8kFC5ezLOIabVvqb4PiWway3Jt9TCuIWy44Dweo21ZXmDty4hW78sGj
XHMXGuZVwxlEc1MFc9yy3nqcGz5rAhb5jQ9PEBY3bwRSvLLLanqG1VvUUdDcCVOe4KEMbuwPAx+i
efZBFpecxCy+eYDxtRRTMgKLzwS7gVarl2B1JTcDFQst6qWIDqNEeWcQ0EGy3CbG+Zc9yJABV9xA
F28XL1blMtYr2T/wJQ0GGEtqUjRddw4nd5juTfAmbDjuO6M8+IC3cP3Eipj1KmD6l9hg8RkVYXdz
tJiqBGnDQ3aUwHk6msbFBVSiUTplS2g4qpfSscJhOUhyNpaKg5EqIAAO5iBRcErJbS5qC12LEO42
ODQMWwmxQo7mQGncbi0UwQFB4gXU8E0l1GWuvM09xtysinRb4mHNf1KeFBnzQVyw5pQlHUdA15Ll
sDwbtSxoeemCaF4CCCugCEP0Pf6lrkS8ZLBUDhLYgdtDmZ2EKziOTiaUlR6eDGI5K6o/cuLZ2XUq
CA9lVClB3qIzWPGQtWvUZad3/KNcA9qcxAUS3CDJle5HHJKG9MPK+bIRm2NIlVFpZburJxKqoiKH
hFxheBCl4LJNVGgcFy73nSrgha1dJE3kl1xL7zdFrJSQxp5y/ivMKAVofMtuiFLf3KTsLDDluQt/
6oGIQLtdRsI0c1zHOJYyivcAmtNtBEqnFLCCEcKThjDZxWI8xdTKLaIbq2a9IoYjcJxQ+JkAfEFQ
HPEoZvQbH3/SVCDMCE2zWfFGrFNXCwXpsYGUR0xYHq9XO3p6bLFR2iHFZKKMI4udNEOkt4AVbbiL
fiuEV6OMEhlXUWt2PVcRhIu8TFQLuDYO6VC5Q2Mug8eI68qlADWt+qiXwq6bccko2Nj5LVAhdlX8
TEtsMhF8EOO2uAlAoQdsaDS74mCCwqAt80cQyk7qvMAKaCmFPiUBLGFA6uAExk/Edb2cEF4l4w+W
VcI6IzET0e4ojVUAJd+FUtD5S5fApYsXLyUs5aSLXfAFpP8ARAQIa1xBWxHjUY5iFl+bgC+AtX8y
7A+gKHuoGy9fiBX+wbLLobi6t7HU4cp8ThFc9S6XlPcFEpzwRP6p+xtjzVPCBY+tvtV6/cEIBbK4
2I3AKrIHIffULpuljj5iXHWQAvqyXiHKRI+oIDKz+fEIACU35lALA8zU5KD3GErs+AgkhFEDfNQc
IcO3Xczd4J3DHgR7gGBOZUL1AA3lTBVIAobAV2LELeOooq7qWCtuMNhb4IiFuXzlfEUiGS4FHMF5
jqLTlTT3sAVHEZFwBUFeslhEJARXQcBPI6l17pA0h8PcWKLqbo9YQshbIpUGDC+YId4lQnxLcF+4
Ij9TmbNgAI6+oHp5hbNfUVK1fuN8p5TBzCKp4m9l5b8RaCV5ZbUd4hkUalXiaAC3Wy0TzbOCcxVp
XxKlbTDCctcwBawxFbBzZQYW9RUXsoVYMR80wUitzEZcVNrubSjD4Hl1MTFVVJMnhxZFz2d+YrFf
cIvMr3lvgmNqonUd3KWtYuSgfLBe0QMdXuC3b2grmRrLqOi8fMKC1276jpCy1dvzCuXexCy/xLql
ysgrNMAqGn8y43i+SX6Y0x4QlBTeqmoLPNxIZhsoFOLxGuLYArdtwFPDvyRgo3FkbahtvnncAwmr
VFeCwsNeosF3fAuGJ4A1sdgBIJVw8SgdowEqmhyBA059TrvsuqhKmOd+pWpQVwS5gHA5CZnrA+YL
ZeUC3KSmy7CVzUuEDyrxOY2pRT+5pbT7gpC4G6OMUSmIN9SyZVxRjVx0lSngIKIfuX4WgIxYF5gu
2rliCE6o3VquKw2YRkZAU5IB9ZAK4yDZycR5zUHEC0GS4PAPSs5ggii5Txccahemel4Qq4kxF+WE
pdzg5jiEC1uj3LfUGm2xKHxpz8RIAAKeYVKoDkhMD1gX8tndoVMIEUxsy4f1OjrXER7DTXLXESXe
MWOz0GFAjpo1y0jHaCqhuhSe3l8S6KhqeNIuwlAXYN1KknhXgrxKmgx0SLwEq6ypba9oW0Ww65Eq
79y/83Q1cQaTJxwAJwAQqObr6QiYQtTxyzdBzlV8cRkw96pa4HxGilpQGs7/ADCOUURj8zgjIFF+
oIO4HSy2XiApWCpTaPH9x+FrApa8KgYCTB14ThOS7Q+YBVCBuq4eKFiFuQTxpvIEBLRXgeodXzgH
MVQI7ZxAU3YWh6jmWgRxzAeaaT8EZ4aqnLOuoSKkfPUo1QNbRfiWEBOlACCeE7fLiBVbfDvqJ3fv
ZAwFcq2OowCkQtOvgbYymrQVdkCdGI4ZojEzQhUKFK8jO78Wu4oramUD7Zg3PcUkjicvMe3LiwMr
Ylrq/wARhyOBjfjzKCd4KsP2QchiUWrDsqR8k3m4wk8V3/EFcLPwZDvUcfmCpbT0Skm7ojOK8w0W
hU97swKUoatWr7hNpB8Nq4ZgSfYnMtN50NAS5Kr7uORwaF1Wsr39KF88o9Qat6FUPGdeoa367Uo/
u4GCcAba/wDkP9JZQwl0EPp54eNlKmFFItCvqZfedljx1D5R8MgmjjGOvxErLbUqXKWX+BGmjIKY
b4rzl4+oW6AVJeepdnG2qJLR1TC4axiWX4joaOK3rIViUvYrhUqxsD6FN14iGEHI3hzBLtAHwxPa
nJAykW8ymC1xxR8kycdzlO1lrFxXgtgUxqLLTZoERa5RY60IC8IFKujzAgjZ3cwLqJbyZa2PqVG8
9xRFlHcKCW+Jqj7jr3lOlxBe1DCBG6iDpswmb3K2xBY2NBf7ZrQZ6liOl4lDeLhslQEoKfcaE5Zc
DV3GpyslBEbZcFaMMsyohInPEQBwyqjlLCVsF/KC0PEVKBMOIV6Lh0u3cFWwxRIgxpCh9RSHH8xc
VzkK088wStcQNlYxEVbZDV7uUlO5uk1bcbb1AdLzxFdaOUyocLlrQ74lk2viUJXKFphzLtiGpEb6
lM8sQL7iXEzL2drddEo8pnESAZ2uUMOSq5PUFA9zW5jstBddsNUdCJKImFu+CXIC67l2hZ15gcnk
6mF8NQApKjh6TVSlEBUVGo+orjj1AaKmnaTxLoVyK5cPmYVRymkqpXzLc25RcVbzBgO9vMVqgHXm
IG2+EtxgU1GKrKLCpUVzhAJsNV8RPI3CDBUAfMBywUZzDzYKtr1ULaThx9x2hoUPIk5Zcx8RFVUI
+WNdv2Qx3bncYpukPmG/wEX7/wCzmFYtIANY/wAbGAciUIoJfBhUAsF+p1Oco3LldSrL+pckYFxd
VpNhbcFBvDKhB5IFr0nQNMb6q+oHpXEEcyhHICMCrUH6lrAWzzsXwqB7liJt1OY50wACwcq0W28W
VsrGkybsi/Up3Y2PUfwdNjzsXVDEvqiUNC27YT5cAqr3LM2b+8ZUeSnOS4aPPCGV2Hg6izWAA74l
/Y9GiupxxFCzjlgvnJRYwibYVPMUtNFvcNkhEQtjxtwHDqoC2geXMDo4K6+4YCNhFYIG7QU18RC3
T09SxY+ITSrF8bMgHFVB8xyBZZMNHdTqa5VsWNVwOeZUEsswoBqexfEZJULd5GF29HmiVUsVIfzF
kArAp9SmDlJ2SvBzlTJjSVAm5xBAfnNK+ofvIEJ0PT4XcOEcaik2cVFA2A6oVfuCxynqcIW0O36g
OhWgKW3iWuLY1MBKphXUGNQWvcU2ocKCc/y1OSXAgFORQPBb99x2vBn4NnighXxku0MduUvnPCSs
ayknBqI7zA5uTEE5PqnW8mJjrKDUIf2UThXiCqtAcQN46HrL/uWwDAAIBKiXdHzBWsQePFQ4IQHQ
XuCQuGleX7mcKbo52ItXjctEX6ZYkcBUtSgX1yNeiA1yfaQjq1etjWG5AMrGW1SFAOvMKLznqGEm
1fkY1lQbD68EAjQ1+UqAkhevLB3OhQr3NCtBT0uUzAly6vxN9Am/iUdjXB1tgqzk2fEfsSutLovx
KkKKjp8LowCActIFhMJP8HlCZsB3/r0RihNEKPn/ABGa7gXVLy+4F7UIvyHvwQig1aouUf29TJ0b
HC+B0QnbKAdx8rvRH8zY/wCEDba44lwreS7iFraoFa3f79SpkpnBa+j1EXs1V/EpVFbrZnHgDgnI
997aD/cEm7tl12PMO0AyC3iiERYpRZtzj+ea3nhi9lIdmdcQtATpihK9KdRHQ8f3krHotY+agcsY
qXzCzgbgu7PwqDeuX9v+xXh+YVACX26dse9Aeos81Eq2hBHxArlyoYrtujogW3uxoKV5CBpC2WEd
cShTleYdgLqM3Vku7b4ZSHHtmA8xsXw9SkRTTJawC1cApjbAaPMRwZzCYKr8wDxRAOvjI1bXU4FL
eIlt5RCd8V2yhTz2Sw7tZRqvtLFDPFx7A73KvbmMHjOo3oGwErL8Jt2/iXYtTAkVBdEsIcmxWtF+
4HM6ubePPUBsteoCl7jR5FePE3QfmKKLv4lLTSAJsB6lF8PUEh4cSrWa5lxZk0QShVrCijh3PMDw
RKrcZxCzd4NgWw+YFBU5nLcRIou40BvsglYUQJOHqVqvTuMHPuHIF2yydEefMM8lZEdd9JDcdMFA
Fl69xoZxKJWNTt9QIFql7lwtNsuACju4/Cg0ejxGJ6CfBAvUKJldnUuKWK5iyznnJWlt+YxlbxFQ
ur7Yjll9SwFp7c5XMQ3Si9b/ANg3CIeKOIN3YA6iHGUKwOa+KheuYgMwtmjoiehcDWroBg9xQ21D
Mm0Cz0w9pmeYJ+lb5qYuim9zbFCNdlwFoBaeiFZWGqdx7umEPhgqDZbcqJQCoAyEGGeZ8MLo5iVL
3xC2ycQvilnnEQOtJ3ui19RpULUEQHzbz6gK8Y2qfuM6lVquUsMul7Q8qJY9y6MCod5BrQt3xzCb
kPmvMcFtTFoaMX4gibAePzLxKInniKa0rHWqA8XsvVdVXzGhbHqdRsF2KWXNmNNqpSlWunMReFD6
itpe7HtM3gsMD1L7Dq+DKHWrZfUskxwWwwqENU/UI8cAtX5jCGlBqIORF/S5nnPgQSdFEpMYtEU6
AfcrKv5VB87SjtwfOgcBfMPwRa8+WOJSqPmVLRrX0QOvA/xL3MNbR/UrXhckrBOxtD3EEAK1YR47
0F1Cp5ffJq1zigFkoS6gA7YY7fFSgYS3T3KjiMg85xCTcgGm/NQSmw3FPq+prW3RK2A8rrNoIGxI
soZdDllXUAPfhFnoYyj0EbufAgTQVVnMpFxR4uM6AWfUWqN+oFINlBiUDUMD3sOKE19cf1BphI/U
fbAV7epYbqfy2NXclP4I3CIR80inM5H4ibRaYpXfopxm5j7GYylg2O6yLwi0Kz15hoAg01KvxuGB
2hLKvmUyCXwW8sUQ4Iy6yE5wAx1HU7/94jKkSyMGgULvOZ0jN1CmtQeCLdqCWkaPdQzVh4jf3KdY
ppo4EQz1Vq8L9RuhAnDTqD72q9N7o9QfUSutlX6hAaQpVLv91OPiy4L8HxFppbA5u9i0ij57/wAh
BA0w5b5ncTA8Dg/JAb0QBFKP7ic8K8Cm2Xxcs0U8W/om8xzz+4vo9zrfEL0i2uHZrFcUWYdkR0Ro
Ae35YG9Kx2dquD1GICI2qMLFxmFWcQtqGFAwIP5eWWxujgvCh+Kg5XCteTmbhktEoNH7gEbLF/ZG
Ijjs1X+w6bOOT5h4WQcOyNqJyb1VJLMEEkNeeKiRjsLazvGeJvr464dIvLNoL6qZK3qngB+IBSQn
DfHqCicjKwwi3YRAt7hbbPEo8OcWO3gdxYaGXAjFbsa+K9wrRT7hAMKLUxmxa/USm6sZh6KldQr5
gEtu5Y4UiJtwIrkqojncNjx5hg0iuO0Q6x7IDRhAsqCmJyzVGg8QnwG5vI+5QIfmUtcuA1Z1L0fK
yIZY2rGcMOIlSEqFXnxMB7IGggTXNMfL+E4AIoFncxXhZUcXSIVrxxEIQqUDuWBsK5IhsRgJfubF
NHiU6cwJJqLtSAdSgQgD+JcsMMiUADi4oFTmUVc+41EFgIF35nqKbhUb4bEpvHU8dXUNZ1KCltbF
BqzFoGo9xV+VuI3HZFa3jLCMDxFy4IrR4gxZF1PuMKNeqhb8NwQmLzYWKeDiCwfuPDt4hwnBTNhx
cUFXJTwQS1/9gKLHUacAbtmgjRApHZTcsqVbVLCsDqbcszivYxAKnfUYm+RmYgz8kN2Qea1AXW+V
QfMM0T0HGbaGWnETcabavYzytGy4OscK9ISwK8nvmPKxTxf1MeqKLTHALZ5BsfhOKC2upccHNOTG
eVobKIkbE2gEammVVaAVhxChBgzS1A3s2CWh16lI9Irh7jGOOp0uC5ZCHNnwF8w/ixZeYrYpgR2L
nTNvOx8t3otQ+LI28PcURYYE5hRhAq1epd+AUOIo7VQeZZOBYgr1HR6VbHFTk6IL/ku4LqA/UNLw
EHa72XDnhZkuMi7aOeIab5K/CGHlAlPUvaM7ggjZkLHEGi/HDYfqhyAObmQ0LbDBs92g39zpEygf
rzOP9Cz5gCzr2D4ThXRjxbGrbqYv8EserjZyiPJXzL/ZG1hdy88C1HIFFHLHxGYFBD1Ap6p0PxCS
HQV+/mPHYgeI52L5qwULUAbIZYMWOCWz28QXxKMcrC4xGKFG5fow3p8yinZw4Mv2jkUPzKUbgoKl
RTFGb8sSRrSuHNdy/ag4EuFjxSu1WwUkHYNIM8OYKxPy4437homKu2yh1JAfxLXATXFuGYbi5ANd
QpNlJvJS+SnJ2q2Cr9TxJIKKh2UJXAOoRasfiVXxY5ngKqFfXcRHiZSHisDzsBfUWPDWEV7qnY44
djNUp9i+5RHsCIBxzAhjacD/AOJi5vLXm4ZssAWv5ioF+jUL+RXl5VKPSWNb+xl7ZUqac+4IP+Zp
c0nC4S8b2B4gFQ9X1BG8ppYnfmH1rSkr7hxL3Dre/wCy/wApRKXoBKEipAWmuvuICKMJTriF+VRq
zxcpsqUuPURMOC0A8v4gkbQfDVRvDjasIerY7mgCSfgl0SxVIx4iopUApq4J0TjPfVANfXqVvK2s
Xkf5unby/hC31/nNYA9IpeuK9XC5i0FKsezuU1qNXdfEyBjswvvkgq46XD9SlGqRAdve5Zy0Km/N
QVPBD/iL2Oe8DwHmMLwxAzYzb+2jNRv2g1m2K2HPAhpUcMDS8O6L1YNJo8A829zqgfqeK8xLkBwr
/wAYyZ102d0XxGFWsgW7P8QDJUdKPnr6mwdwD4S+zm3RXTLYvBlmoVqRjUeU9sB0qCvyQtEgUq/q
4lqiVrw9QhSjoyGx+ORO1oc5GpKUHcpFZfRMV+Jkg1ZZUbczq6PUdRKviUadYmMUxQQ2viUFpbGL
2P8AEGsn5mhXqpVtxCBpuBoOMYovpAm0X5g1RyQxqeo2evDLh1XiUXfDZqWkaCfSWTYHmDsuAHNt
xbVYsVZTUUaHvZoVujxDfEsAqo9lsICqs6j6jDmcrNUduIGzmQFo5KWElzhqFErlZhaWRnBFaM1t
URqG6YhvMHlMiLP4Sym6a4govF9QAfMRxLeT4i25pnFx9xCvttTZR1koBbCHqhpXN9QmxwlUaiVS
o3wQArjOXkQFqvRNcEzglAt+EFV8dkuCW6hWy7VS1t2wqdxrhgVa8vEBFM8x8cvSBYZxEaMQ68xt
xxhYDxsQIotXCKq9GACuGWIti3Oal/c2BsZadzceK7FNrIDXLyoguthtC9lV7JzFTXY4lwJQl/C7
jaQKraS3TClBLPc2j/AXb5gRr5/2iEk8DmOtW8BYC+GFol5PFPE05DyuffEDfzHKal93C9ziDqKd
Y4+nxF4aODo9y+AONbLlGjvJiGwlLg7VdwVQclzbgYeRalKzuDUhA8lvnxB5FSlqwFbUdQlXIY+I
0g08xhGLBwe4+O8QVHDKYE/Koe90mI3Wm+b9RMGMrjGTDyjCXuAc9yysSwKhgZ3AKqjmPPuLYCN2
V+ZTYlB1LY5LFtkRIz8hNth00MqXN0saRGWb4WQjfDbcpVje6Hu1BSBhqdqTiqc26Y8A2pGXwK+R
DwSHELK3ge7hAgutD+IDpy7OSqTdu3F/J/M/EsdA0tU4Xzm9nqGZ27PM1GJyN/Utw8bBBG8XVLQl
wtUOHcl1XD2qFREigKkiFJBbd2/MHLm8HCX291V0Si3VLdMZK0bR2PJ8w0U+SCOBwl/lF7SOawlV
YtI2CiODS1f5lv4bAUn3L2Q25sQQTqliCa88m/cXcddCbwDkAsQuATeh7VBFs6WonoGAclSKRYNL
IlgKyKjRvMW/JLSqx6e5ZFA7VLjSO6jkg08SnHNKKv5jw87bmxXAToIxcNGXlxENhggYbKKPWXBF
VT1AFm3dsIYUhhPiBndRrMYWJiEVpSRdg5WWArPFRSNNjRXMPaqjmr3MBQeU5ilQXOooFvhLuOgy
eSslFW9jiUAKvCjJu/Hm6mn4oE5YI7LxyTmB0iUYUOkziNmL2x+DVgNRXMUBObfctB7xrkrULDY1
GSg38yo9jiJRNfEUBdcnUDX45qY87yTdMhst13EGWAAN2F/hQcAW7BasVxzPQfBFBN1yXsOJNDo+
2alKXpLRQDhSFRg/qNYmWgKvia4XY6AA+Elue0b/AGixw84T5iHhcJU6UHNyxtC1HAQTiI2eq7jz
DFnO2pUZ3hTZRvls/BfmFpwtOFr8ywQBb2TgW1aq5zUrSOAJfqVUbYURFWLJe/ZL4DsLM+IX5rvT
zKtqXs6liEEKhcfEdAoa8lnLK1a+vmXI04FMFJNK7Lolzcg8ESzA2Nw81GRLwJq8RcZscR8weglF
v2QyRt0ipgXENPGIeI242LHKUE8yit0HUprrjuWU4Jk1Bt7lxvl1GynF8Sm2B538wUteYWhdDmWW
so4iUesqbFyIh4qoIR/EsOuVOGlVKra2xNPAZXmJQ1xFc4KliqxhXbc5gDH0lZeoVjiGge2M6LnI
WsqFZB5rYNpkat4isDmNRSi6EiclPUusX3HtrZdTAbQ6ZeoCL9RCf1DLZzLAv6ZREhC3+ZtyZVxQ
Dx1EUSWQX3FbODBTdUC4HY5iB0HESy2xdqvzAWr+4koZUCxXxKp5HUSVFk4lyzZwqWT9EtqLLuXb
dZEC70ELt1hR4dy/bCAd+ZTYoCyPppuNyFGMoBG3dkCgL6uFzqZpOKao4O4zRLKWXi48XOZpcuK9
WpyYwHw2qOuYYIVjgyrDlYGmTfuDZ1cpIqClcQtyolMhZALQNS5YDxUVXDyP+QIihuuWzmiTxxDt
moqGCUKAQWV9oc7Z1FCFXGr5IlCflly36lcNb+JbSxFC6uWBuwMtanBUQNtjhedxymiP5ixwVk3j
iAdM5ElV4unuLTpTgg6p8Wg4hshTxLWUhfXMZ7g7WxrWU0lRbqcXJcEC4sBCOvHTSMBxR6lQEUX2
6lhMJTpLwF2VMygt4keEdQTLlqJwmqI1Tol4fML7cpV3HN1nTuMwfcH9xiTfCVfiNSPwrqV5atJC
sidCUi0vYRWKzealJtUkNLcucRzfyqjWvEZlK9THYLQg4IGS0vQcLBBoUSGoW7CnwlfWUJGoVCKo
mGo/g2AFp6gBiXoPwSoHSOnT1GLaKKKXcI/aI12fiIQAoJSHZBYOPtEHq+V9yhkZwgkPsa+pRzTT
/wBIjcyUOYW9UXb1D5IUHC+sgoZ6DM/MW1YSIGJKMMbRWMtzMt/UvzUEtPmAAQ5a+kCOHe85j6VR
VrJd1LZG2UJhLcMIKNAWs53VPXDX7jlt2Y7q46KX8zpkRqvmUAxwEc2WcKKDUQpzGwyL+JrITXwr
mK068QaKqGbbEGr7cOQw5WlS0c4tBEevI/iOmPByjOqss2KSk0mojUDV0lMFr4hxfmHJeUVhDVHJ
g48RfZZVF+5w/wAA2psWDVH3LG1hUloD8XLFtp4m1TK5inWaOL1NEVrnBUGqApTF+JYTWevLguXw
kVAKfH4lXSqeGz/kW9LBGhCHd/mV35YDhODUAaHmWuWaAtcCAjQ8IAfTr0h8QsuHun8S5R5WBP4j
jT6cpVEuwl/qG5TAHgSoLG6lDIa1KEp3cLFUxQAO4EgKwVUVCRpmG5DAfHxE9HKthHioqJzCo2So
PzC93RTPC5tkFdNbGDvhA+V/qX1SpDQ7yUqiBW0vhilkjDqDXq73GNkFTnzhg2APgF7Hrb4K21Yk
ahBHaq7+IXOjaB1cEKvcoB7rtjRfxRgnfuUTB+tcCVBNjg8RfAdLUsHAq/tMeYYF/wAPUc6M8g9f
MomIUfb6jqxTVFDlnFoE4QrS9EsU7gLfR6A7agipgBSvL5WEVS1a8hAwpQLYu/mVhjwdFOn1AqPE
bpzeYKRKK4OX7jlKMKqHcGtEuhvm4PmiC73SBpceIaQ3qC2mYKVLLCjZ1jaAt9RABbTNJKuWSc93
Dv5GNaiiNrIECV57mWn4iiHzk0DtOwHoMTd6XkFbFepoFVF6q/MoRFnpnmKzzfcQFgUGX0SgOpaC
7iAdQrfiKoccws8HcBE15iXQKfibbAfxLofHnzGxnMZca3sZAuppxfgzE4JcxsSNrUQ+MByzwy/k
ryy2rZMl0DlRHvE4RXzKdvHzKqu1Bg/MujWGbGFfpLSt49Syl13UbI33U1LepS9uKNZF0GD4laGr
Yg1KObBclo2RDYUSpa87DJYnmFEMq4ESwniXaPysNNu7PqX8QEs55uYZZVWxIOX4lXXbwjQU4BOA
v4R2apv+Ig2E5qIri8R4iqwXMI2yFIWDgK4+YgrQy5EWOS5RgmQ91NMRvgbAPBx8E5pqUSU2kOyd
cEBe3NzNP4hUIPOS7rFCW9HL8RS2lG9HiAobeXxAMFVAO4jVqrhq1k5A4qVdrxkAvKFbGe13zAzL
ubfEE88SxI36ik4H3FNT6vcO7EC4cMAYcgcSX1rqvxHwpsgmK74UBfPejGciMWcMVcVFvgJekYng
j1lI8tuUZcKOnlhtYG88QhNox88wB0bqD1AK4tiFWsQ53uKAiAhr5jjK+DxLTVNpLGEWOQ8RUNXY
0FymDWjPBBNr4dPqPA1aLBv+ogiAMU5XUtUmmSDY1KpBc5cplJcgeY4XD0pABVjqKuqaLCj87st9
vVdvEWKUgLVwbECmJlBYJwUZLbHV4uYXtAM4QuC7/kvxLyMbv4iB+LZ5/wDXAm2BT2dSujClByoZ
/Ys+qqcldwqohpnUbqOmo/8AA56jTcrVokasbdW3AS+tGcgQszCluQBraNL+ZSDgHuqIyCyw4HiF
AUWsA1rxC9n36ulpLmxHLF/5KbfrW+CU9TtGxyu4qrlV2aaeY7ABXAM4JTrxF8FJoLYZYP0JYYYP
JlDgXYoM5Y6oqFSmWQBbTXhix6wBUVBFVy3Ll6YLZfmN5rtX+IszB6FvMLUHKKA0iwVWGNtmHIwg
H61MOPBrX3g9cBTTIP8AsaXvY+DRVg9S7Du02jA9Aa9ZzAQADxxswT0+Dyh+KiJlWk0+olB+Q3sh
LwkHyoYvEulUjC5YcaN40rxlX0w+asZdjgB05c3WUxT7PxMiS4GHwTINqVwcSj+Ci6efzKCseyzP
nKMSWBDiK4ZBhVyrQ97ABMvgLc3rFFaduFCyKNUboQXlpctnu18pxNNQOUt5cciEPQcwCoIEenmW
+ZctOEpc4wNCf9mZ1rsLVZ6mB2hWr5j6gg0F1kpNCoMBQeo1XwGi0v8AFrHKVQ+7fH0QWG2gC2n8
sJVB9OkSV24DWhON/MPRLhcLUEcCrx3OBVMQPMAF2fP/ACEeECB4H5gD0WtetQGYlTR59o7S2/Lw
nwPc0ruIB/Mz/wA4ud2+JeG7FcF154qXhgC8KHB74l97QpYdlZK6jjWlyiMDQQDUAUjGO3yuEagk
Fn3HkCGC+aktoOI+19viIyhiShug72XRQkFG6yoMq4IvcvuVUKZR5gvm9XkaPzAZolCAFe+pV6Aa
gfdk2wiftcwaRHBvP7lunIPHn+CZlB741KbKaPmpaY5zGNW+RlCguFkIF+JbAdSzpZRjhLsTINUo
OoU42fqcFCpbeMgBjfaoDe/iIqctmw4e4lrweIIvL+JsPLiITlvcrLwQQDgjQLyFXwO5wOHqpfRf
ucIZ5mUKxsO3EprTqKXkemEwb3FAP2yhGfMXnqUXbV3OQOO/MoCUCwhYp8Sg02rwRE0NDKBw+GAR
G18VGtLvqXptEEhrlbxKLAU8ZsHAbMhfzUHbniCjWSk6s/ceAPuKzezQ8wHtUAuN8xr7iY0LlAXS
9gK+2MY7RlFcb2Wy283D4XeSlJd+4gUF9hHSZGn/AGW3j8wpXlnMr2QyaK6uIPy3IzarfUvZNWXN
DdLm0U35gHLpsRiF8jAI4fEZ7GQ6TpD1eyxFX/UjwFAqJwaqfdywPxuL6iCcCr56ihyF2ueeZxa6
T8EIpM1eSYmkhBd2MfiHhtQIDBZUWB4j2coqcqpa1jE4h1V85EC7a8mQ+YNuPiNhWsHvVnhLfc5q
5AjW3LBLZYvc3lXKGrplBbGrGjm75lnrr86/+RDmfLqE8oWvFX3M0LsziXzERL2oyts53djKiU4x
S6H8kagNEK8RHzevq57gPtVSk2Fw72ASJBfGCZoYPBUcYhrywnqtUVgQDOgR8SljDl4Vn3cPVjbH
JnfX4pexGls/lYc1fwU8MHqwQ0jxBLz77eeYYqUGw5zYQB0tZRHKbR7n8ywAScAhYdvKm2I3YWHZ
K98F9m5yLrB/71OhLLv8zkieQX+Efqor24xyNWjf9krvUfK5t0Tkv4hhys3iPqbjocqC1SgLDWV1
murha0At2Wqduz+Jz5W2XdQKEhQ5olDAU1dbDceI11yy1AkNtSJ2ollfxM0WqBQ/EAflPRbQtQ8p
5WAD0mlD18x+totr0t9sVrd22we6tmr2AE4R7rg8wDpvnUETRleYgqVap84QlC0F/CJpTVxDtcUD
Vae6hq/S/wDRFa5Us5gxIJwL/MBxBcLBdpLIHlhU4+ahFOwLDdvEbcY2kIaJ3N9IFcHPUqISlzL+
fFizBgHZwLrVIrXsde8JUgMXN+IRlzCtpsYcwDjViOSztdYRgryVOuZUGh2fRDuAgQvN1nzDecxZ
h/kuq1V8vllJa26tgu7Z0E4S+CGo2iKluD0e45rBUXzxBfFUGARdbGhxCi9F/VRl1ay+/wDrCLI6
VB8cRtjrZaevUXqgS3Wkld+G33GkPT9wvPQYeagKbmuPd/5LnQglg22OrK4ruZigp93O/jr6YeSA
k8qyxYKkBFLj555nTXU4mgOheQlnR/aMolAou2iFI2QfxHDj4yAanAQSBYPFy2otmmhd/qUSGTVa
UtuxtCnIau/4gtqHZeIpbse6H/kdPKjh6iaE5Be87FxmhNlHIRhZ1y+cu4xMr84uVnFdspdacB68
PiE6C4G87FTonKW/+Rp+FoSd/PD6mLgAt52BBDkgQFFpcXBgVw8N+HsIFD6zakr+4gGAs+5s1R0x
2IzQAP5f6l6s0jid/UXcWdjjNsjCG40qC20DoPNxkDAPqGtIu4sNeZlRi75INLCtiy81G+V+0gYZ
PNB5Bsi4maPS5XPs/k2oVZ0+hV/MuOLoPBeR2m/MG1fUC63maBONfcEpRxAN31LDXNbNh5nbLhjQ
K8QARX6gBYlwhCA8sKFUwnTt5Gluupq1h8wow57g5RbuzBp3qEgpqGitNZTGpblwBSlEyXqFEop0
QEhxbVhQJKI0kHEHI8PuFLbGDajEDxcVqGiFjlzSMbDeJQsKeIq3D1U+pLVgE8n4wI9r7ilKBU5I
cxq+cJa42OvKuLhWZXHk579xKeAhSg7spGnjmpRBSvBGfbxC4OGJHiwiKptXgg26hUaiWoeS9lWN
GJPi3iIvo+IFN4g107lA2SjBksrVER2PCMCHUo+FT2RKyuDiK0SzQwDnEEEWeJaIFCNh1KhR5Y0E
XcI7EpZwiKDCQaSHsOoxPajcdkc5Wa4SogQDgHlgfhZQ1xLZFsHjahvCC9lUIzwtepfwvegepB/K
HgKSz1FV8S6LnLVvSxiCLYX7j4OCfGwMTgLpkpKX+lzFWh2JctpnxPEvUq/JEQSx3URKXnLYFX0I
xFcQXWjLA2m+oqgnPcLaS416CkvYgMu/uYSEpUaKzf1HnqCw74ZaC9BhaaD4EqWJ04hiMK/CpkBV
VTmNAoal18RWBfbeZuRrUS90+TztIPUfjrV1nxHvQGnWwlPZecOI15XRzxA5ADfJBvLD6I6eSEN5
8y8EqJZ8VBRdyeajIlukzmLjBa5ZKaUMCuYrBlidRWMVYXf3LxbnbfqZbdhb3IDWIsqRSCXlezdR
d/qWnO3hnOouvE6QhjzKC278n5gPVggFBwRCiwMugy7C3anxkqQVQVlNy3QurhjtlIePURsHwQav
HUe1HG3mU9CKalEaklcc1L5t0DSn+SrwUF+eIPS6Q28ZKZ6jhtpFQGg39TyvQiL0GzS1XEyiLB6i
EaFvWnELZdC+otJaEW7DiDpActB9y5kDSyowXUWVlXkTHuDFVxWV5gSCDHwVNgt5hZrfmo05vOMK
RKWJXEp1qtwUzDpG8UbbR2DDZnByL0quoprg8zPQ6OPPH5ihxyLoitI7WwehsQyVq/BGSAkjr3Hj
qsUD7yN1qOwPAzDkLwOE6DAOptRm4QuoAem0t2FBFw+4RQUl8lKxnpI60ruUSohfhMQPDF+iU8K1
Wz0Jduft1hrfMuKe2uIVtFd0UOoeoFXb6hralucvcIK5C1SpT1ao3buagxdVCmEftsoJSdQTzJoG
24fJBE8JBBIXYZaa2WuwJL5hDUKhFeD+JjGgV0iqfOzOUVXkFp/cH4nDNNZd+Wim1tp4iUNZZA7k
ay8FrVTGeolZ0jFwpoKrAr1DP0sRRWywcsyRDyxZWurDsN+JdFVtQ1xKIPgjyQwh5o5Nz9NJD9Rs
llKr+YVfNKKeSWWxKi03/UbxKjvjPv5lxo+ELwHiur7gMUwQc7r1NEchT5NvMMHAuAeH6hCKKBYX
s5JaLW1uXlPY1o5+ZYp4t+XmXQuguw+ZdvAux2M5nsgPJseIzjWt3zLusfrPlfMZMPB1GxpQKTxr
mIIpczr09zgtnDoof7loJg586+YSg1LORyQlCGYCmHm5xYDh5UXBR9wpv6udKgCFe4HAocEoK8Vs
BBTVKSoumYbAeIQCJwwFGq5yEXoKsr3n6gMtsIX9RwWfpJHEoLf/AKo9Y5KWreLjhfhGpc3TwRQU
6cqFnXxFVNy8r2gYDvmMWLR7ggo6nK5s5cZGiVyxgD03N2Wpx1LKvgy0qX4mhqmNbueYk7PUyO2g
XjpfMzLyPFpPcsrAdRS8HNSiLyaJQczoAo5JkPcME1vZoRdlBo15nCHRzBAOPBN+SG79HiNzh8S1
UdiX5RKSnSKnX5StXTCclHUqOiK0XiUIFU8M5AVFRy41LAepdL778Swp4goYQqrPcQRwy7l0pvhK
i8r1EQeajpeXmGV0xWKiJxORhUNSwDe6RchRlypDvm+pdFNIjD7QXe4t3heZZ4S6wLYVU7fxBBdZ
rKXpu7uIDWhfuG0sTiIjQXkiODw8ksY0l9t9slAnN9TJJCrVHYQGRmnfiI6QK0T35gLAFAQxB+bH
b7gjgAQNkcL8xTL7cvFO4u8tS/upbQItcdmqQFfUvspVsfxALU2gOPUcMKUiPLB3zyEEi/b+CZJZ
LKauKbCq7iVVdgaFFw0VpKEvSXAHFXkujmLSi1O4UbYjE2bRhudJaxr+Ig6sC6+oK6LWNdRiadti
iMN7lQRwGKynIqVfzxkz1NFtqUPlqRUdqVnGx+YtG+9VFKBhqoKp7dXT2Q4gAALQEW6sTqXVjYME
GuNBhPiHnWl1cUkSqDpekIwgEMf3FJWsbH9zUeZxT0Q3h7l/ssztEN/mIVXGRX5m3fwup6YINfzL
dcVpD+Zf9Ftsfv0pe+YZ8vgclEVSYd2XEA4dxBUarP7ghbuL0G1V43JuiwqPuICOFWVF47TRPhmO
Hq4JWiij4Q7/ADLAfEvprm1VXE7m7tT8Qgm0un3DWgzuSnYG2P6lvPmjpKOpcsIYppuLrI+TmUNa
qVp+YA9eNGwuKnqIyB38z3DA1Pee40RaVhFAUnF9VFZiWFUfURk60e43a3zwy2K9Eun1B5GBbnsj
u3sJRKnChQ1yF9BXKD5liYCeqyNwaUHXTNHIqlhTHtZVclAw8A3O+tnciUQuncSAVuht/MN7I4Vv
4jlAQGj2gubqja6hpzypv2kS5yuHlTnUJEhbl8J8xFg2tlv/ABOqpya2GrILOErKv7lNUV2snRwa
TA7ssLLImQYQHsHWF8lLzvzDz6/DlAGgWbCXDQs77Kw596Z0ustXyy01PqghvxVVviKGavgTtRDn
btYepJSOXDnClsCHytUxqLFTpQfNwqfbs9vuML4rFvmVnPV0kTz93tlswc88tiOC8qKh0cLI0ZGO
r5hU8a4yhDqU5iofND2lg7oJFGNfiWb3fKYJbZ1eOX/tjNk8AtvImRFVBhPPxG1nKZZkUQ7thKdC
ljr5hIm45CFS06v0LBPMlBEfUHco6V8NxGtlULj8wADO1b9XD0WUL0n5lRdWq1vzLoEfQCPUSQHY
21iO8Dd6v5nIFOV5ZejvUEGj1KVYeVL/ABDUliivu5YKAcONggEHNvwiA2bKagxxUR8HMrWzdrLK
dC6Krm0Rzdv7jR93Db5hoh7cJFeKaJ4i4oOoAxr0quDEZZcBjrASioseanAbr3KBoZcMFgdMfAKg
5tQPLd5liZb4JoU+3mYA2Vtymr56ng/aEvUMwbhQW+EQUZsoLba6iHjPMSt481BVL0bLm2JMNeoT
I07iXQWXcQ6fSCy89eJQDl9S5dNF2kS+S4k44mxsFBbL7mnvxDUh7lo4JYzx1KX5eJcBw1AMeZfg
reYil6PMKNivxAsrzC5LICR8Qch14iAFb5iXliUzau3ipmt21HjTVxFllc53LBH7JWKT6lgbaZ3H
EajkvaBWSitfuUCGxLvuboaIQipXZCE4DdMGHne4m1i/EVUPwgw8mNbw9S0HJcy+iUNjSxGrjuU5
rleUArRcVCb5hdHN/ce9AugYW6rmKcDT8x5M9i+yAmHKBdShSw4XsXeVsq0h0qciFnb5pXqJNGOU
+4jBx45gopOio5AHOVRa+QVUtmD9o36CpcNfALTUdCvSHZtQVayIAx45jFKm1F/iLzTzL8dMsy5Z
aipA4MJc067lxTruGoDRjMfzBThTuaIZGh48wOhcIKxiK07rEYmw3VqhtUGcVKUjwzfwygylDtpD
3UKCUwFLijFAxgob3wSm9XU3vBuiJiS6ep7uAdTLUjGruFhoXvhE/r3UJ2LOzYAQN8VA6uwhBXV1
VS3AAxrqF6z1YxlWxYwBzBhWymeNAnMUSF9SuFJfllmvT5j+W+Iug2CpwEwZkvKpCrrkY1HpqPxr
uEUxWUFc5Gig1awZ8Fxei1VVKJGX2vuachqKRKcqNGChXoLGZDg+CMlKaCQ6qVhxKreMs0IAGlik
rLhH4ubAAKGz9y4ovsIFw4wqgkL7QUh+yXBSihS5WKlIj0znEL5SCpIeQiXItUy7myDa8xac3XEJ
Dioo4cGyo8RPAMUPBQ/icjvg8IkoESEx3FHTKZkDmfBAJMay0ziW1hvAucO2X+CKznKf3LBXI2hF
CsIl+5why4jkUeEdGhINTCRGHb8y6FBiEEYWIocggPx9R6uk5ruH1hftE7AWa14iIK1Kb7jgbFwl
A5pY7b0eYUtGwW6iofW9aEPQr5uxMl/K8/UVBXR0hFBnjzA1D2imhzc4MR6WVoVSlYAxHwRXxbzs
SvEGgwDB7DOQsQSXP1CYta6iPBxDG7DuQwpLASw31Wh918RtSWjV1nxFEw2dF5F5RUqBLPEef9io
cSIurnraJyk5v4ghWTRrNMgyoeFi3ej4gosF1TsahEDzKA4S3AmgO5e6KCDliLQqiX6kpfS4xWtw
OivMLaHc7gqMbDV5YE3gNCWnonEhh/Zwcq7Zr5Sc6jGha3EgYbbTMSnjOxKwdXLCT2Of+EQckWpH
p1k5gUJu/MvdX3EW9qJQ+JpOV1HKK1B93uLaJBs/hE1pXqWQv4jVeK8yzBt5IKwYFXryTJa3mLYh
+Ucw1V/uZxVvmWa9wytl1DstwxSihp8wgX48S7BjzFbmCz3Lkpa8TYH2wVNWXYbJXFw6SoQU1AgO
/Ms0vUdK8RARLPNQFU59Q4HHqI+vCpcIlQko2+HqDnRHKhHbeeyGgK0csR1eOogPJUaAKDcjcMlN
caaXeIBTjIuETlzjMo0WoaUPmNbhXIyzt8RL2YwpT9QWsUVFEWwy7bzUWAtuAPB8RUlbOZeIwg2P
6gsXAou7YAvc4JXVlTfB8ygFxTiItLyYWU3TEBek5EuG3fmcg67h/QTsok5KjtVxo8E9JLAsq+GX
yPMGRFpt+IEG6HniGwpl5CCrK5fDCjZVdJUKB2X1EfQmKSXBQrp4gwLDmW3ZWKZ/7YtxLYYkLDgQ
x2dVsaL2p3HuK6g4oKvFRMcrkbC1XYdJrThRkMLCrfcejGZTLgK+h4fMPAXinMbcZe7+ING9HlHD
WMAr/wBzGU5qmVUMvJbYqmrnVbMnAeMmAq/KxCqtvmENIJ5lNl+WFilXLFC14lovR1OBOG/S49hx
rriErSJQqOoVZQlJcI2JTQuboycYfx/ETT03TKig5Dl8w2CMHghri9LsgTFdByQRAtqpSMAeWSkb
6eSdRNcpIXCeOSLjG0HEHoNH9IwK7OC0jEgNsGosob9XmMKoIeRN7NYBHxOmrxBfU122NFvEcDRw
cS+pkxtolkQHTLTq6HlMh4alXgl4jgOA8Soxdqd3EHBg7rItMmih+8hGLWscrMdgWr7VLwAKmzAf
RsiuquLEAWAsmuDB4P8AYSQgC1xrAwuO/lpgOt8EexUtHdbMK7IBjEs9F9XMZR1TiCJwNaHMIgVX
0tFH7jGyoFAXUCUleoYuQSW/ggK6YtKL4qGVkb06YsO4F5Nm/tIrcgTKNYgnfcivmWYWeDEA1oNI
dzfgKY33uvC+qnHwGniJKDQYdVAt5JUr18yhXiNoEBzx3GfaX0L6YsXxm71EWknZrUJtYXexw7Bw
TUp+UWAytK9DuClHcIV4rqOCxzsajSapA5biKDo39lFD1RUdggHTiDknQHRjg0ri3vI3gEJW1cyU
UUXl+I99EV9nRpzB0QwcFJmxqPwKukEQYRCtefqO4TSric8xapRxgE5fEIwG0COFS26Lrqj5lJN2
uEo7sY+cDA0qe/lccvRH7ubq+n3KxH6SH8SqZWFEQ7jAwn0Wbv6hZglll/ZDQLA77MYNmEo6SI/Y
Q1doJ+5fQW5oKsyHuFCqlfewA9wQAbabjjDcOVxFxQAFDA+5o8AcbypsiJc/H7lKNDsDxZlxByfP
EIMpkmaHXqOOO4aBKBU+EMAfFtMytYxYofdypQF0UWcFm2hv1FqC7Ve3MZ6TghcqCdAwf76jHLGy
BoXKQdkFFg0EeAcrCr6PiONrVtpzTG+ea3WNX0xRbwzQyw6A8+YWjjBLZ08xEKoZq3bfNfqIpUJr
8/MyJrVjjKIQO6sWc/iUOpHHp3BJuljx18MFA0jXF+IeQLErxleIctwWLjj6gZ1KeCDkYHE1bkYG
ATW38RRfBO51MXLi0L+ZdkR+IVe0VUa8xmhjkDNwyXpIgLxl1Kr0m6j7hyTlip6+YWmnXIqALI4j
Aioca5mAprySlyvxBhdSnLLOyUtBtjCC0tSx8xKmK9/Ep1L2UCLnUt7hBXxOkZQnZ5jB3ZFfluEb
sFA/dS91V8okjtL2JQDVwCEt4uVyVKUXxUGctegirpre4HrfcsOH4hJ5uVdOETqq7igqPep6Jfka
4gLOxCyLfcS0pfmV0O3ESgIPcOQwr0zJQoG29IUBAriC8VgylrLqLG3ngi0I0cxUK/UoRtqWkeU7
iK1d+Eezy9RaVhXfmA1Tg8SwAceYoBbGsy/UoVwtl6lqUFCwm+EJNrY4TN4vMNasrZlEsXhiJLYF
vxLc4LJrQV5lt3WZkCDkiN1vPmXBsNH8Ru4BXxh/kdsvh9QAgu60DHKUOueICoXni4tYxRwEQodD
3OttUrWFRR4nAR9g8sB4iSJT3YxWVKp8WQ7IwqxIKDQHPxKlxtT/AN9RJl4d9wEU5IvRXRHoY8xQ
hx5ZwqjpikY6uWgMPMpYC31GbYPUDHNRUx6l2wUfMv7wIvqG2YWnqBDJpfi2KlVlThMaHUA3JSl6
jZ6IYNoSvHqOg5x6CJPLtL7hNhANs5DR+V8xBo2Jecw4EYEIpp+L1EE70OtL/mGEIKMDYQeHk4Ip
AEQW81xKcSA6Nhzypb48xzz5YC4mBe1cAQypxBQJvGN4LHuL0412nzCTxp90PqmKjgfgjlrwJB2K
pYWt9SqeocAXxHQktxhwV2HO9x/Ws7443+4l81BKeoSQ0C18xtYtKj9Rnlhp4YRh5UlBHQPZjEY3
jkbNnIUCflldg6qP/mGztBo8TgUYt7Pe2HjzEa7WgTqSQLCHAarODyRKeDkoHxyd2+ozqpC/UJCj
Lo2mVX0+PP8A5ioMGHVeiEss9Vh5d+4ao0Wd5+5cPkm+F4jgYKVKrvPcfYtZOXIc2YvZrf5gaBdu
mfMDNdXuK+Muj6Jcdix4wlaO2ssldcYUckBLgUd0QVlFTUALcZ7TSqjuEO/iO4piuvmEa6St8alk
g7aa8yla05gAtA74jSqDN1WKMg3WcsWN0DzRWjiXTYMxcKH5IRu6vA3UwKN2p1xGsc98F4nfGN+E
QHKUJ82wte1UOR8QJbEL+IlYcKrXbfzUsb3N50TFYgHxk4fbfpCxCRg9QRTzL4UTiAbs4Gv/ACVP
jWYFWwyvAQydePEHbCQW1vXmHCNl5VivvWVKOQiyu4iQhbJfqLo7cHLHpv5QQ3Qm/EWC6koLcIan
c2Nu4YQDoxzxeS8EMSni5SzBunXMIQFWBZniIpTUfubTt2hYEMeSqCx6awi6gluLtX5ieAdrbi5O
nHJ0w2tifU4/6DVaibdENUZAFigKgeS+GH6IgKFOd9xuJrQwe/mdgOyDefMCfW7vhZH6yH4qc9ra
N0V9SxoSSummImSw4bVw2nHBGv0sg9la0FOH4lVvudXy+PmDw39KvkhUyVXnzXlf1NaC4cO3leIT
mhDd1vWMKNlW8E/uEABccBVWxxYSpQKd14l08WV1zH2sLCBKtBEqzIgW62Auue2aQoVLVwBSqzuM
CAHCYKCyKI7XTLLZcW3ceQ4QojDzLWLyI6BKO5UDPbLBXXqVhdMF8FLuDgaxAq6YRFI+Yj3VHmHn
mUoEDheGolrMClHxBSDRF1Y+ZWQ2mS1Wt5AAK68y4S/icSIV+IWL5250EBaXraio4P3HnFXEauqj
vo3ZVozxOARCtndy7V4QeVPUBV3BEXLdxCOiAD1CxuDLD2PHqcAtvNyr3wPMsJV8uIjgo3zFamvb
uI8u13LwIA6v3KK68EqNKzYS1XzLsAWeYTB9ktA9yzSl8xvKz4l0Aq58QDwSqhpwaiBK2LwNZem2
XGgGo2o53Y4VoYmhAsnLupXwdSgXWT5S7aFGxxG+ZYo+cD7UdRIFJyqQ8h7hhQPgiv5CDR8HcVul
dMsRThKvLE1l5TC1gs/ECEDR6hPU2jxaEpM4PC7aHuJsLJvuKt1F18IGzYJeSUivqVMoAPEabVQv
kyXW0EswHkGtOYzmCVimosFa2yVQcsWFauVChaCCYFSi1W8yw069SkeduGxXyCcyZ7lI3bURpLM4
hIH7ltrQwPcqdGg/UWRMsNgy4wK52BD5Uax3BR1OctqM0o2pKC6FmVGANoc1FijWvcoCrR3LhYT9
EH3XX9xvKoPxsUdY29mNwogvoIgUAonJEJVCd9QaIwEAdKNj5QrMoh6Rd23RsgVkIH3Ut74C5L5n
LUBXIYeR5rrbnAHuI4ApPjghDpDhqU67l0b9SjJKoCdypyrC7wtR6BisgikMWYHfpFi1y+rZSI3p
PNZLEakLx7glKOvDSoKWtQUvll8h3PMrB2q8ax+FKKsbmwO4Ki0MiW3CECTZVXm6iQjF0LmPsLsh
qIpJSX8Qe1axHj6mwWoqpsMWtC9c3/EIzA0em+YCwaC8MyLTNReDcOlkE+QhKaxRmEehNKIYSlI4
W1iZBC+U6lQuNABXPzG/YWJarESNEIUXh5Cg/qCmdQzzSEoftDfmJi/cCiqoDl3iPETR9ABBDzb6
bLxjYHpCv4lz01fhqZXFMi+xcoWu2QnR3ZB1D54tqFXMgVGYt6hACAIZVSBxBsKRD5u/6m1XheC5
lUYO9lAwKy7a4lXwAGvMVuJ/gB/NyoPik51v9QVVc46HmKYpBfV7/ccaxtP1KdFnrCP9QIdpt+Ml
wy5Vraf5MpOcj4hI8lVLeLfNR7peU8rl4+QE8wBDzDsxeRaj+mNtow3VpEACSd9ojwoHuNmex6m8
lIBuxkhKlfqFzYtxpzqxAZgV9L7PiOwPQmHojIVG4DoHxOW1laTvYdNvX6Gh8yjuS3jbM9wPBT92
VFFYAXt0X8Fw4SoqagbOPBEPfuDiiCtivTBC4WPQ9zehfzbR/cxWW1L5XIZVLM031hyTkHiiNbdx
jlFUBl7+J0fDgDjnUR6wgOMZviccWnqZiqNLd+PmE0B1NcLLgW9VFXdJxsUYEsBBEbQK/cH3bSbQ
4/cxIFrb2uicbeBtvLXx3CZELHgtxVK1aELdNQdE9a0xh6VitFX7mPPhfBq/HMV7pK4H/wAlzc1a
NvH0o3xkXQQ8hY031CCo3FagNXHU2WdVEFV0hQLl1vjmBsPcE7dQ1ZFV6lnVE2cUZBAH4Tau+pSC
uTqWtDriKPJQQiUWm7HpGMI5twi0HghQNbxRxACT6iLiwrbo8QvN6cxKHm+5YUq4GCDFq6mXaFQ2
tm5BKXsLlDLHAXx5hR1ddeo9D0R0chg0V0ljtniCv6pn0KgA05Y9x5dqKYF7PHfiIjfJG5OuowKq
EVdUIFVdtQSBymp8A7iFNZ1KO76gsruPg2FjwCUmjxLez3FKOX4miq4gTWbktppyN2meWXYDEivL
JpVlQtGjxLIUHNiYMYJYKHTDHaKhpLI9dR2k1c6wPmJacU6ilZFCO+4Sh2ZzBdGhzBNHDuw9GipR
5RhnfFTUtY+iYTWrgk0aQiIcMCCMkQNN1gsRVP6hKq14YltWHxOPAI11HAbLU8Mr1jIn8o5KpR87
4g4aiPliRtXTVobsPb6noK6/Cc2wa5uop/S6o/NwLXCwt3GtWlp425Q8oq8GS2OupBjNRVQhKHKE
dJKgjp7gzcutRC06ZLeO5Q6kcLnHCnU0OAQFMDj8h5lABciUBRMJ2QoMCPHqCvBAFOa2PmiaN1UK
45t8RwxeQuSqs+rBmh1AI5H5lRrdEyyyo5PuIYA1s1Zk1dwK9xH04goWfMallukyGm3EHRcqAlkD
TtXsGYSgI/3LU4PxCZPaEWyuSOQ2gN+FwaKiKc1ce0+AlQw7iyRLRARfmBNsKsZnewt55AwcChyl
/Mo4S0QqBGpLs/uaGq5C3UpyLNZbUITc2r8pUXTAz5cw3u2No8w8g6AI/UalrjrYXde3y5m7uJSh
jbD0FXx6liiC0CamQINuL3d3OO0y5cyp6wuoLgERArURLCghc4EsNiNdsfBgbCyK3RaILfEp0ABq
VOal0ldjGS7wPzS6HrQYhHHOC5lTc7TbPErRtGzvYtGLW5OmH2TqOpblHe4V4liq8UdZKW0wP0Qv
VSrZ8x15YAcWULwYivmYUWAF+uZb602YdThW1dYHQgeZRin5IrdNmC11KoDQYp35jBapGoDBdFeF
YSvJsqu44xTos/8AsTSaQV7IIHGgJv7mdKLkX7l8QB6Dv+JdkUKF5++I4YMdWbEoHQTwTfzHC9Ge
r5/ERG5o0t8zKk802+2X18sU1/UzhMDH5gNXQmAygKJS0nvIGu4C8CXAVrUcnBcJQ1s3d19wf1Ao
D+GMcCgpnP8ANouuBFV5HHWQIuORqDcSWFc9y1INXbhyRFfED/krnzgj8saPCbsU/wAi4NSDVpf6
jH0eQCnrJaT0bXZMeqIfvbK2uuomxAm0en1O+KQNZ9wJMHriPKGtc3sMKjw+fMo4TQXcKpjjkwW7
0acRWhq5B2/cqMXDHoZaYNGUl7fu5m5VozHNRAL5tsfJ1Kxe806+kmUlxch7bldHSV+B5Ide74GJ
HbEqnR6g6tW4oGwfUSj/AGbsQUPxy8nHgnvnJGlcRN7AbDy9ES6bigXe3ysoxoKmMeeI4JPkUC+G
XuA0Hsd4i1YoUA/+JWjj85YSHGwl+U4UVrw9SzFAelNb3OzYCpz4h4MaQ187HI5KtK6i2VW3yy76
jxRy9g8ekUPARaTruZhqV9ofFxGpjLF1dZG5gSi+18wQ53x1KLTWAtey4VJd08MEVNs6hS/J2adJ
oK7NrouWZdPFywA2rOFq3qbVoe0avLJSK36hFarsYDV27sAWUvEuI2GZnC+IgNrR46gHJwXZBGFF
HYCcGPaAu8Y6SXeM5wogdi80yiC6eoje/uBQ2t6wWE45uZOFuLCuYXVHfM+cOotQlg1s4By4TmNs
KnmMWu96gf0OZWOBEAPK/qVTDr3MyV9yoLAD/cqpTnxFlo0QtzeEaVwHMpsxO2IKrkgKBAVS4TWs
6GDaPuUeLY1adws+PMEDXpL42x1URsRDzGtCPVxrhteVhULtdThX/E4ryoVRB7IoXyQbfL3F8Ndh
LvTnmHRW7ARbey7S+Al+kLkaYkvVvDZQY88+YK0BT3Ea03TcKWCp+I1LnTiJFRvUawiI69e5R8Fe
vqaQu/UuoVnz6neq+I+5Rsp9Eh4JVJnxAVsjY6MCL0olRgTEuN3gAk9qZxfmN2zlP4R9hqWKKDgc
R5OVNcfiWOvpqEQ/MlQtvshsZvMUK8Pc5oWkHwPMJ4URDBXuDFaL7myqogG8HmjiWfbxMNrp4jRI
rtPiIohf8RhImvJfWE5TUuqQ7p2Jhd8TwvnniKYM3zAb03rfzNzs75ZeHjiPV0KuAC01Y7fxAgWC
1xb5QaSE6nhbKVP87kqyHHaGwl8nmA0XtGj3L1cOVNv1hWhG321ILbC6/lbFDnYV+ZXih6tEA/qU
GXA3kRH5jD4bSlqGXz7Fg0rzCUT6XQjoIaFkXrHNrgZHtURqALtkRXO3UD6PdxiFJzAFJpg8JVgi
xTQtEh1ipzbnxOpDaj+oG6IEdXzDNuRgVA0oDuXX5gpOctYy7saYDKiwLR1aIZoHvWLlA8rY4NKX
SUjZSriaIq6QagyrA21ZqBW9Q0vO6w/EopHlbyXYi8VF3I5VHJA7vamxgvbAR2/EUFfWRIO8IVXC
CV3HMdIPUQZb5lraZqFfrzK4SWlcwqJY0RwpfMRxvHkyG5NTVNAs4qPZ78fEMHkF0QqaKOOJcgEC
WVYHR0MiACpi4qHlbBKUF3yJS6CuKgum7OIPbUbFC1OHXkZUYwD1XEJDsBWwQySEAozkiRWl8Tq4
JZC2yz8RMjoQHhR5lu580B8xaiihCOdy8P8A0gTtwO49MQNVSaMTVq9IFD4hSndRPUg5XTrJVHFK
LWuoe9Sg/aBbtvD7nAtX1LiAvipWas4CMbA7cfEQohSSWDhdrmKC9OSsoHkQ1vh2cQQhMAaytWBW
3mXwtyCkTqYaJfRbBAB9pPxKR7Ua/udBmyyIYUEUQXwuoDKmKdmCNQXs54jIVxWqltWg9RnOH8Sh
AL9SusW3fEUH1B0ErZU4j8ReI+lFxy6idEoCK7sp1XxVzbWZaiQMF2eLg6xcsS4TcVrlvR5OdcNb
doPvBq6z3sq3oLAnxECW+BufeQPGacJ0D7ic1Scs6ycjKzEv4O+SVKnBNC7+II7qWN/zEmOB1JVa
mu1CxwPBHgg1KnkSyy5u6UViWFLviyWBRW+O4FV8cgQG1rnPlXmGBLPE4N71MAu2RIBxVtRNUaJf
c2ynkX8QWa+RG4rtkty7g3W8hVTo+YATalDSY4SAjyp3LBtDmDpfPVRU9TuIgKSg058RoUrbiWy7
PFyhOB3cbbKTiaLOoGq1apZEX3xK2Xe9R8AlCjSBFaMOGuIQ9GDBZnUqxFqqgdNoyl79kJEWvcNG
pcsrXZY4bGLQqVw0Xlxtt5yAt8KlX+RStPyItDqmccynRui0JqY8IAnbEBXJ6haDXicRIsoT5lIu
XFuhqkLHkdQ0a1C4AaLPMtSLXmW8wbL4jfGuxPP/ACNmwLl12u47B48kSFcd1AUrnqUBnVwyhyFB
hDM8VEQgj5iZXRrFHKWjG6rgHGy4cV4ZxC+A8QGqgOIfhqgPcfpTkmVFvR3wlErl8Q1Wqirs3lfI
L5YxFhwt9iV92NCXB2mr7lSGe4NRaCHMbjBnL0wZdAsybELx4howhpbS6YpgCvEEF8orht8wVZw4
gCp1jqGEotdhAwso4fqO1uXxLsT8hcPdi3q4yuDwGQzxYDz7lAGdDHFi6AzmVEVmfMOtKqwsYOFF
owxxbnDjCVanFbC8hUBsS6AdZDXkzXcaATXSVQltrlHlCWDWBHuNNcxtnPCz1cPNDwF3KFtsRv1D
6Uto6gfoUDmW26XIkEAr7i2moGv/AJEW0hgA+o6yrq5LlECCgDEKXD2406htNEdvSKPLioHqagUs
+pRr5IITxQQPTYkZG1hIjweQj7GcKRa8vMQmpjVL8QKMO4bnj6pVbMWqq24jbF8y7CyhSO2IidEI
84aGqS5wyPCSxriAQ49Q5MvTg5BFIqjYl1pAujQ2bk1dSYyEI04Cnq46dkSjTU0P2uiMdNPxKUwA
QRhNH4x/+QUAERhZcCyVrGaBZLXaBR1PSRDoCC2tsquImuBssYss2EquyYLfV9jQGdwQczSVs65O
tK9EOkUKaYiBoVvhUviTXwQZNub6GaBLBUZWorxzOZNw4R0EFqkTyPpcFLi7iP8AWOPVVrq9uOv2
YdJDA0nAMI0LJ0s6+4I4vByYkmltqnSaALh5H0iZC6RLKfcqKh6xFJFVTh9RtUroO4udTfYPmIbu
h3+JfwHNnEtKOqE3NdX3D8qR6BzcKhxOnsf8h+XKAU31Mgo2D/3cAeiXl8hR3GnaCy7gceTLoBbJ
UryQ0zWWwmM3pXyuLE9KyoFFBARLr4ItMrIcfMMR3xHLn7Ja/EAWeZSiTtcsPejRsh5vr5mlk13g
4imW04Gxy9mk6gl2LQEXEygYHHACEHLsikxawPdvuJFMLErwe2LyeFo1ZHa0BXBdRX3j4eY2WCgX
nmJXREmNyeL7eGnIYMrkA/LBEMUlLzDMpY3h6/cQpqN2Agute4DDnz7IswAX47TAqNig3bpGqZB7
oLc1LFntjpK/09FdyosDoUQwG/7FS6A1bFaLu4DR2ppfCBNNXSbAbxcWwGPcLjz4jB5Q2A5Fyw48
eYk7TuK255xDwfZEuZSKhuJwSmANSh0LuGijm7uIF7ssbaOoA/1HAXuN2hqIgrIBTnO4FnFbHvdF
8RgxdB2NRZvU01s5BACopiXawyXNhvEVsNPMZVeHSDS6t8RAoanDKxx7qcfi7yNK19wwJnI+JR1t
wOUx4lsn7I21VPqKSq2XSdELXLSK2oq5jaZ1HDFvyRFXfdTsTmFhvNMIob9pULZcVFviFapYygG7
zOm+S4maPl1BR5rdiLrx5jjRw5YLUKDbhj34jgFV68TXhw6hwrqVWcmotFGVUqafSKDvWy4q6dSz
E2pfyyxzKbg1LymBYocMsi/AEOPJoILd7R7eGooAKGhhhdr5lieA5g2ta8Qrlwr31Ap+F4s5wqqX
zBnH8wRp3G3imDQNcsVt8G2D3S9EPKCbGEDiJSpcyCkSJk9WV1KuLLxO4G+ffAsYC5C+2DoVHHmK
Ma9Q2JABXL5m0ipxAu4ITyUICgTalkIPR3ECPIYKNBcnIiUor+JUl0EuohAtRVR01G7rxEiXU3Bq
soOBTP8AIjOzQQCdQwA4u9hM8H8ZxCLnVXaZJBWe7uGXmEquslL21p9wqRCB8pX8Cg7rZc8Wn5I4
JTKNv3O9NYolywv5iYDsOSXqqgh/MaCWaL66j5mgPwl+neFGbH6ZLDYIXv0q0rYSXYrwq92FsopO
h+YZmvpCzsKYPcLOFTrVURQHOmOJUWC9RsOkFZEp7y3mHZfA+clXzWDibvqoDQvZ2kpfmpunxd3P
ASpChI3rbyDMSt8jtiAOJ+6/qZVhsdXDUBPnKfmJ3kKcIWIB9SiVeSGQdBIHCaTZ66XetHcpBp0X
nLH2osIdulOR+o6ilmU0Q1IWadQ8PJrxv+TjMVXc5c4rk7KGJgweIy3CpGYN1UZzptGcx8pUL81C
CAAYHqEFqA+4YD47jbQUG2xSbsWB3ALdlwgDvq52B3FWhYYfBswJS0wLg4pWdp2w9BbwH5iNee6q
usmFoJd4Z+4rNlZeYOtpqZvcYQ/QG3kGCnb77Y6QdNcA6MH86Aq1mfuc9r5p/BHpxsRJjuASkg6R
3jDggwPopqzuVN07+SAMeuahSGty3GClM3imLwZTKBXP5hS66jfma8joelR+oavJ0H3EGkStsmKw
oPEMwqG9PfPEYtYOUHwSoeoYRbc1g52rlwSDRHSpLx1VX6MDylvHV8xcxVUYNj/TESwIbcpBkUzR
B5O4rlXmAPiXplW/+8INigBhT+yoGq7ay3CviVl4gaFGVp3g95Uqoxso0PUThUYA6IsOqHFWr+41
wKzleHxKObKEoDggCWRsZKDQCq1crJaQVfRMyhQH/wAVGyNwjAs39yq8EAujyxg22uUu+X1LVKnw
8BNKZ+SjAM7Q0tDulFPxFG5sAiX3LavPCPpUxURtU4Njc+y0DfI+IkwUpU1t3MEbW9ikAAcBoRbf
6lCHo3RXHb5hHAwcqlL7Sj6D1iuoCTSc+qhos3Ye/wBR0wqm7OoxRVejmIauzgDcIMAlPE5LUZXV
sC1vXzG70QFBymMSENQhdVMBdbC1S3JAR0lAGUQWrtKyAAtUdivE6GQRTl5uWxur8xpFFfERLqNp
8y44mwpiBPRkLh3f6iIqviKhP1EdDYRBu7/qJSk0PHM5B9pdLUHZOAdYh0wVkpvRJdJaVlBywDvP
qDa5eVjcmXA4hQpyrJgt9EEcmqyAU1Yk5m/qYPY5g5eX5YhACuYJnDzAGaVxXcGjfFRXZxlznp+Z
Q5dqrjWWhia3c5U3u4tPolfEF1Z1BYTnCIBGzpKnYUu99wSNhXE15lF5b4olMcHbxEBYxgLt3alL
nJ4lFyBrcW4sK3KOoxKeJUo4GJb3OIhy9yoXkaJ7Y7tU2EUF3UrCKrPQLqe+FALs7kCiXTyJLVsV
2QxUF9RmzmorBjfmALc9ZAmnaeIBxqmEFfyQQgWOI7eSeiMSpauB8Qr7F3mrhE0McH4jVpzWTFBY
L6hC5LUXtt1oH+zodbA9IHhgzeI1S/cWBg4JYmXT+EEl2FuW4aOp4yMpbgeWx2bEleLKlDTb8SgV
k+IiK3bFXQ28VDsmk5lkCq7hKPMQ5ykcpwZZLZqO6rcagA6Cle//ABAt7mQvyn7glVKNGKxKE88T
I5u0YxA2QK6vEWRar8mqqIKxh7IFVNAefmGSwbV8VcIDaVWzkAMdwysQH5ihGo/JL6HTPldMEYYI
8mQ6S3Q/BL1uJ/xE0WNHlAgPYI+51LjQesH4ltTLGFwsBXEyGpmtC9/MCd4LfzHJaF5B9R2vlGWp
/sQsWUYy+pWEV0LWsOwakcQMVpRyFQW9AeWC5L3hkOaXE+ZUafg9QIcKzjZ1QF/iXYV2mC/8RVIF
mV7vr1H62QoxP8hynN8C68ToEaP/ACDJTFCq4ltSOggSyXxCPZppp5/MY2yKS1VxGFJr7r/Y4mlI
9AKqNbOt9uQP3JJo9xkb7BxLGYgD5gCgoHfzERLsfHMTK5SvCQSASrwTYaL0CaEf3HwjIOKFQyHW
BOagt8g445JctNr/AAlFnbP6iZlkKQw7csPLYneo8yl9Ky2p80Og0b3uIgEXKxS74YRb4FWpXhth
WM4g8WxGz8dxRp2WqniUIESX7sS1ieEDrkZG3FRq4WsldV3WMp9WtZmPcI6W/qlByrD7Wf5HZC08
kBaibMlbLSLthpnhbPHrdHq04LfQoVx/E8eKE4Ja3qMqIauWi1VqHVSj5jYFpVP0wTK23b4jfWgV
Zz19yzoVamqKIcGaINMESuQWh53iDIApPcWgUKpERpB/UWSiDspXiILwAihQ0qHHVRvQRDblGsJZ
vrRtBrGLMb1rVV/cBkLu6uj/AKTCltwtcqNmG1BUcl0o2G9eIuVBtOVv9wq0q0/uLvgV7/8AXKet
sSqt/wAlllIz22iAkpFeVWKyMJX5lzmyKDatj5MColIShWr580ytXT74vtJWw2yuBUL5T/5BLhv/
AH6JXqOS7lB6z4m5lm8qg+ZqixL8CP31XPPZ+IXBS3eXK49MsvhekuBHHloXLrnuUe1PiV2Xv/EE
l/AT5gKOEAbb5hd2snxcssOOFrzBYbdLTnB6jhVS3W31LsG/zukAQhs8l8xZ6fp5hdBAJaIWVlqY
sQj6WwnSZt3fE517mlX7mqoERu8iULxYsjz4INqC+JQtGfuDYNXbLr38IoZRZaFtdGXC/tNEWDGD
w9R8AVyQARa8QNjdQUMTENLBrliibp4iGvDwEKbpayEW78yx1T4mOcwQb1zE4FCLq1fzEWwpY+ml
jWglRQA4Y3NK8uYINitwBSlvzEc3VN1KabChVEahIxDa43CbBuSEOzJQ1+4Jlb5i5H7iqNzh0nzE
VR7WQUafC5bRVQUpKqFkOkSco+pyKt6juuSIVNX/ADKLzjU+Era5mDwuJdtOY9iy41Ng7qKeMZyA
ruo8qhNNTojUG/EKJAiVc4Th5gpW6cShC725W2ZxA57qALLy5YLqUMOO/wD8LDzkXtz1GlqQdCYy
rS/r5hEq02yUleeY70A+WJWxPKx7vUSPGmbteLz6jVBsj8RRoBbXTAjJEs1Y95urypD0ULtEzpQf
jYV6MBTHolbddl6E+CBCNc5GNzeCz4ZXQYA7AjzVNxzcorbKz1E9LRzYx6RduUXFGcRafCmAVsW+
ZYqdh6YIAWl33MpMGLlwFRZRTBKOqu4q0tx3CPSQVSwn27MANKrmoQ0eBIqALkYfEIRAclR1IGoR
Brild3AJWe/mZsgaWPfaVnucIzH4hVyKcZEINS0I1zGkVz5hcUloGzNirqoivmjN20IdGCluL6nE
lEPAkTtI0nKBZmBF4gMA97Vz/hTymECHa4j6LURZMbxCmwUOV7Ira7WIK+Eh3IDG1sMFIUW1WQkM
qaCtf9IK4QSypVyU1MS7gNxKclEMSS7G3xB7LqXy9ykgIAVbKhbCnnLcxSnLpB3cGcmr+yBZ10qs
YxcEkhwsLEA3i4RFgMNXEHvJbXIwqhA2m31VwgRGwUOxnUUI84cQBh7wO1A0y2WzlWC4irVk4beI
cdwYyBs44ZmvsHzsMdU9uqYc608db/cc+5BrHEC35pBbyX3DBmCtp8v+REfNdMCD1RypgDLto9f8
ndHUvrRiLGKyyKXNhmhVqq2KULzoXBSMnUPtCPDYYUt1rjyW8Vyjl+NCtuGLcFHJ1LzKB0fFwdIY
UAA7i/4dWu/3Hgb4dw1H1K4LcljaqIWuL8+pmH93hXMvb+XOrKGSraAtMI5TjQHTc3WFXrKh5tuO
pizFv9j2SEKldkFSuA0cR0rcYa8M69zbUXdXLqVvCuKV8EWyh26ggOPUJtkuouri0SFobO4YIRaF
iV+cnOncUcfMPz0woqm9ipFaUAUrf1MvsIPx/cBtVpTwCUZN09G6uPxoRbKYHfHt1a/niaCyBpDy
wiZMRKUqC/NpERDVUoaN1nnqC0XJAHhAYE3umrq1+ZwuIB4OpZDMsAkFl4f+2U9J8XJ/xMY+EDNs
KoZMVA4mPP3gR7jNGIxXhPzKGCNhrn+44vqEqbUNw7rdynjYgaSw2NIWJdCrm/5lw4hWEOnqIupD
tTgDhiVbFLYX5o9xiARHkhmgA/zBeD1KyHmbvhsqxt212f8AzCRkKBFLVfMQdjmAPSErSECPk9S0
dlAq2NspNgjHcwHHly2gvqKRKw2zHS5QD6HZHqB76VhZbupURbTuGMizZ4pvk4iQ220oHHMPzoYy
vp7yVJhL6Nz6StEBKg5I6dbrDwVf4iMEeoXmDyTh3kVC8IWsPuWWfEh2hquKmxW13KG1WceoKBzu
50dLzHLaKqCI+HEK057leDk0C6PEaC1C7gCcQ8uRFUCo92A+2IX5aqdFRXUVbFHiaLeXgjcKNw4r
pxctYdepdOZKqFHqUU4eWJbjWwEbw+ZpYlSwoWvcdK/cQF3vM4K4owrLm0vN2XYG64ZtW3OZe5TS
F1XbMMT4IYhjh7I2dPLKpABdPBUbWg8XKxrb4JQWM9waUq1eolIrGWNb4mS3T+IIFdwlCD2wBrUX
qco9GTqP3BQNPcLo45zuaK78+IqxZlppW8KjRXrL0TGtIEAiEHvuGRtHblpYGLQhzs3x56vXuPvX
yncK059xtT3LsTs5nrQkpsDxCFqJYCxcL5jYBsayoNOVEHNrFbNfcRC+1R3PBgQC8h2bfx1GyVzk
KlKK1Crp5hS0KO51LxJKThxNL24T5l9YheSclIiY1AremSsnZdMuYTdB4j6pStOfcsORpVpjoGxo
lyyu65o8ZCi6UCr/ABHPmjfMV7EbUG9MI6qqHxEGnh8EVYHHRKIF3KjTy7GRTYsFsPJVKljR6Rcc
WrIMp0cue4hsDs5jy1TQNJc2u8fEeipvu9wHs0WLb8svss81xMOSq1D8XEh8R56iegC6aPkjY0A0
KD5i3p9QfzHIi1PCC+lAJ8bGZRTkPnYI9Ka4dvYzsQDBdfcr/wCwt/mYilI5WGzsPFkUDK4FH8wZ
LiieCPjCPCvzLcUOQd/cFCp0Ql2s2vH4mYAV/wCmeXUlPt2c5Iu3FMBXB+hBexVXQkXTOiuXBAaK
b1CK8/Is1r7od8xOQVTwsMitYKRdSXRaoFOpCF+cgPEuqsMzAyLVR+oMYqy+PzBKIVoL/UrPysHy
qXNIEb2eC4JEqBtfzHKV4oUg6xMGDCpVQsWvsh22fAPyEuDJXMt/NJ99XEUA3fn9QqloClsD/wBp
bZ4FzGMT4DdhNL7lqHuE6LgEz1Kn3tvbATYr1EC7yNNyKkkpsjq04Y3PT4loaLyoKUfqJeWA0oUA
yV+o4CqA2XvmYNE51cQv8it/zFqb8l/zG6B6C3OTqjyfU1kkLeIjXntQDtUvMNWY4tkc4l3iv+x0
TCipVFXZBEmhFOj5h9LbSnmC2FV4onn0CaEQm7XtgBC97nbLjQlhUirjhtp9NdNaOYECYIHstJf1
vlik2wKZxBszxGvcDNJjxgIjIXoSKTdoOXb/ALD0Hb246BDa5LaUAwJ7iFN0LUEWPxJoHnuX9V7K
zIJUYA1xeEZ6o8kuP+rOZoLru19woN06q9VGH4tTT7Y0U9uwr+YcBPJBfuWIY2jUvmONo6j/ANi0
ocGX+5zPkW+zM4NORXOSlwsNKG76fzAyr7tr/MRrBSNHprEQVsTja5hVG8Bh654l287tf8xfBbLm
83Ei3US35i44tKuMJSVOfeEB+ELqhVXr+YFqDU19yrxHsAgvLTdWBTzVhL7d7RbfM8WyI4npGsK2
udw2nHlQZaOW3wqOeIAK8OwQ9eBAvTwxgke2rnlAaBRGXGj5TqC0Jbsj9ziDwdQEgs7uYYHzDtyE
IOM5wUEYgnPESd9lHLdoo6jAHnIRHG6TdTGJVdD/ADMADf1OXrtIwVy5OCkZHrxDWaJZq2nwSgG+
ZZ3LJxeTKiaPFeIiT8US0U4c1BGewlaNyJBG+4k0Xf6hHCvuUEUUYIKDl7lFDqeQtl+mxXPUANmE
EFJaZOwNXKVx8xdJp3ACmrFtVvbGrOfEVSLtqbDeSoRVcVEaLlcQs43JwOSdkoKafiLFl/iUF/MF
btXMa1tIVxC2F7hsS/uV8GS7BvYrydawmgOZsXk7ly1A7hnLKnAGlLuUeSsiAbbyxWgLN5cTmC8C
oejWGiXRKNPqKEjO7i2XxzksEBLZTJVR0FlvLE0HeUdAlOmAsoAjVQaAW7w5JcoGrROprdC9eo/H
eICAfMwKU3U4FtPD5g3CBzbMXOHQf7Qy2hyZ8fMUXnQjhSlXiXgoLt4QspvKCAN5eWJahWd1xNqW
eG0oZgZRzGdBEhLqMcZxC9FWA5j2qnKqI0eV3UFUtIzROZbdzoR8fEWdEKpSjuUKnRgXj9EVd+px
NFs4gbAqIobqHfFRXDOtB2RlPcoeBY5+uoYUq1hN3/bhCWUBUIWt8EaWDaxtQGa2ge4KrYoCLzJy
wMCGWlVAutMbAPxG3/Etzq7nBDL1QwuKxBFDjKOLMAl7AJYHMGE+glRkrYP7yqFUBHOJlg2dAx5X
tUJvg8cEaV7bxKhLpjC2ZReym3of0e4OarSV3KSwtVD4JWnQXSyOE3ePENcdhy8RMtOWg8TEEGkA
6StBN4lb+QtjPpV3TslgpuhEQvjQo+vMY7UMMiFYl8kVFUl5A9sVVE0HH6g9QXmRYqlXm+3r5hNK
cDsT2o4HcbB01r9zNppfJXkg6DjZTbRToQfTuU/5HiAQmXIgpGKt86WzWwVdSrptdMwP5YPmH0X1
OT/sFBiLWuCpqpxD2IMoN2V0wkDsF9RcGo5GZ+YVihPL39y4zfN/uAFVV4X+wPfZrj8xPMo9O+Y6
060vB5qYmSuR6WF3CDbQB9vcRXQ+OLmRwZrzNtF5yAQBfGdRk6AXxcGSoDpT8QdrGopVHEEClS6l
TvlUsCVkw7oOYC0x4oQX65XpOM0pW6HqKEJgK39TncAFd+Y4I7Xsc1EtHXMJHvLBZ8E5sN5IIC3T
mxgBRcnmN45XMsEdwV91ALK8F8DzKJ+gHV4S8AAHiFCVviP8yaNnFFrATQD3J6Dh9wp4S6BdYSpl
tIVREUV4NRRUV3HaBXuCNS831CYaRhUZd1LpV4pzDpa3MPAd8b8yw0gCciH6gpHJKgizmEyVeHuW
OpRrGCAeiI1+rOImPoEI5nU6CSOEZBA6XBrHHU4htNq5WW12eJlOmVv8QJeHqUd2oKDygGCkSvvY
fItXD1sGSaIWaai6vO1KYm+GLBpfKS66HzCWsXCRXfMC3UniENVSIeH3EHQ+Yj2HmEtuTADWAK2p
uyK8RF6T1UCMbsma7V4qHDBB9xCi35Q28niNF6iwGryslQi1Gq3TUsfKbD+VlinlBG2wWr3qIK/S
IUvYFJwqIhHLgiox5uXQvRKBTnmBo2XwRn4LwRkL5Oos5A7WLYIc6ZZFduOgnHcWy6fE4C7uUEuu
5bQFb8QAF7bqY4YtFaJ1KaW/cuRV25ITdVYQBmGcMgHUpUjfqAXoixu1DuqajScPKMQ2+WLadsoB
pdS9yCHmHZbJwro5mAd5GsXks807lr57hwHN4+IF1qlZxEOjalhXB5gUc2w5Iq9yWKfcqwGpa0fm
Xivi2Dis7ll0nxGt8W8hOTpcYpQW2iW2Gg4I1oF0+Jb5S1aaA6gpuvFQFjO1eIGit1lCNreMK2by
M4jaKbuIAx5JUGG89x7MYY8TlIQCKVlcSyu6BxkJGOgGW5YlNpZOoZUnM89zJdIVKLVBfaUhoo6S
lAt86h8E+ETItBGEchujCNEUG6l29+mK+4jKe0CU3Qph7iLyRuOGXKwqInWGlnKDPEuThnJB3Avi
5V3NXFAYqNqLxxGsbp6joWL7gMYTQhcVhI6DkaGt86vqGUNcAlZxIr4CIbjooSHUNiqqnHuU+Jee
cjSRMtOIJLsf5kSKwdldVLUtCFIKEKrt7gx0luw0QSfAD+kWqMq+eJys18e4AoDoqggRfD4bGsjt
MW+4HrhKnnkhebFU4K4j3DtgPpMT2BNXbDqi963MoxMA6j+uN1UtSfkluNrWcIuLnEBfA9wNRiaA
QE21DtqY6PeDU2sIsNq8v1GetCmkfEXCmD1NsbOuL4h45eCcxVckEdtj7lJsLX3UexLvuvENKavT
QwVyATAIps9FFTb1AnXZKa7GTxaw6ZAZG8RmKtbwWe6wea2ow0WFcflnVUuvBcT1RS2GwJbC46SG
rC7zguUG4VL8cQEIAdm5VTaFhkJJs1bcr4SlQnzCNlW0LuWiY5nEeohYLR9TlUQSryCxTa6r9ypB
fcbzIpUNUq/cYnbxBSJXo67nc88wqxeI1FIdMCGJUqpdA/tsoBK0A16lyWgciUUAQ6e4a2k3bxzK
2M1DhhF0MxLXGytSYJVU8SumViAPSEcxqfQGL0awB13LAgE0X6i/CcqZsEXiRIaLO3L+yFq3L6g+
YRYP1i4APLp+5jAUhV7WStM91Larb89SsdC+zOPuZYOye3iWHAwx9B7iWnWpIGBo4va35hYwBYV8
/EGOPO34qPTYixbgA73Ak6qC0Ug5ttg2tYBwl8eYVq6miiWW2ArieiVMjuuXvn5jmwW+thiR1IAU
UfuFchVVrxr6i0GYb8QGqs0FldEbbrFsBcWRoJsKOJqgQloBzGIicNrv5nLg4XHcj9sK0KD3fMpn
BDVgIqXQqvgP4iDa2XXXqYlrNIYxI8D8OZTLQKrHn8wD4oMymEEdebRV9fUB8Ey0PEXMTRaeDxFY
XYVjUblK04zi75gXj7gIDTKMPeiz5uLONTUHwxITgJjwXAxLAai/iYpFKvF3z8zEToHyrUXXRFKd
iAGtPMFIR4HEbAWkHi7PLphPksAuLSXcNMqY2puXyqrZZS+SioUzs8yie5yNZWlK7i68nUsDx4RD
2Io5tL7lnlV9RgSiJJiHKIDzfUol4eYHwTI5JZkq+Wb3HHr7lgTg5ljgeoguDwxDay+4KhWHxKG1
lckABsV+5RFHEU61UNjl3OBKtFBrUsuV4qDy9EYPNHMfz8kCFUeZSjdDxGC1FcJupR7hNw/EyJbb
uEAxbkgwNlxFeS+IkNl9XOxy9RJXiAQ3jzAYab5iAtLl5fQiFUjZnmcAW8SgbLSU4Rv3EYc8ZC1P
C4BHx6iAXnc8evM1SVXaRsWGuJeKaiigtsY95IqCi6jjml1DG1QkorO5Qt4ofmuIlVOsooVkJRSd
hDKqhVRAnJcynlEFBwcwaLSeoD3XzCtHDKIKxzM7j34l1PtqTaF8VBtH2gCHFtfE+YOKnLW0B5d4
hdqgF83OXaxTxcPKoFl8FUNS4RvURYUYv3GlWYr1LeArnxGZKxcqDCB5gV68ckN18jhAUbqONcxj
waC+ZxIEU8o7Q8oKpj1CKqYQ6wXLKKI4YCVyZArfyjw8GyoPYckJars0lHEF+LTfUZuq4PiLQEAv
zKW2rB+otK1UoARdvEOJoochwQSNJsVcEhLAhXzGlt0Mqate8dltmCHl3LtsMfNQIqaB4dlV4xbA
uGSARd53HY7B5yK75qHu7gX0UeR3L0UXPN1xCpAFHu4OIQpzb6lk3PKPkJcxt43BK+aKHjYg94Ah
KyFDPL3KYm8Dhd1A4m8Io8e4IEJQUFeJ4xIgr4lT6gcuuYvCnX3CJsoHus/qDdmR4Dq51rWqLA3W
rU8RNs0C4dBMEXdynhcD7jWfZHMYLfvo+InLiZCcGLK56SqvJ4g/2AyBhm6AfUQhqNmPMoacsN9B
B+yBOtfS7EjnThNatoX8v+S2wKLdytZtlbCVq02g53sOtGsxr9x9ixUm/wD2IJryPyTB1Cqg9EPH
gHBt6m8lxShPUpJLElTXv9YiSxX9GVt7ZL8yxXfLAoG2WvTzMOCsQY2XRShzLFtohVNfUs0pQfDm
Ahhe9FJ0g0dJz88RA0VVY5k+iOa9QuBbG86lKaC/aI+OU81b+4FYA4JXmN+8l4xjJqS+1wzcDzlH
LUGnHxUIS0oODchUsDJZLMlBILoN9DLMlJXRUivGcUp0V3HWQlUU8fxE6g6lUSiFPVDSsiz0aF0v
V9TJgGibi/dy4xzl7iMFvHQq4sBaivxCsNA4xzHjxUQac1D4NDaN5VRALlfbfuF5sQXfjz8whOkH
19wWUvQYvBzF6hfjZ7hTRrQngamp2f2iH0Nm2qr+Zzpevm4gZrrQWBEMAeDbeIwMA2nTX66PMqJQ
HPOd/mAWkZWr3UN1iWdCriqoPaK4bgoMQV5omXTcnyqEu1SvfFRsp+BDr8ynI1R5JQiMhOBCmviY
vFL+ZVvKyX437hXQYW+wf3LFv3rBK+qX3PF8x0tbna8sBg8hnIfqVBDYRR8Lcx3JfaJ/kuaWlz7j
IBmPUVWcxG7r1av/ACNCobEVt/xKQ3T6jqOfcsrB5ZHkIwWFETwL/qEIQ9xUjyeSajl3EG134jaB
s/iVIbUy45RfiGv11KFrnnIrwFk4DGxugnMuCXdCjLGKXE1pv5I2PhjcOvRKoFaQ5m9QEtTIDwFP
5gD4raIDkA8bF+3qDemPiNaW/Ue6CruWX9bcbcGL2dA1BB3xUKLqz0yx1b1UbgXfcopFlRBQypZX
NcE0a1PMszYXoxlazLyA8F+oxUgPJFpSJFdFvayDzKr3EC8nMRzPSI8mmGqvA8RQAZBYXu7Hatp4
lhfGcERIOkqJZ7JYIOsAF6HmGl0kLLHbzBNPfDLrWzJYQ25wBPZKHSXfMVgscCAG/MVT0ZAtDYRr
VVXLqjhxLHsym9O4hooO2pewoeCUqUdVs1zt4DqcPFsV8PcsdXsxHOl3EAVys+EcvdjtRLFZv5ih
KrIabu8iDB08TTyvzKparOSBTXXwyusZGNG+ooeRjgWqL3CkYgSpIxB3vMGzoOHMJgwJAYTH/MUB
bh8bFNJZxAVap87FqwRIpUvb3CFpvZ7l7SJuW8ZNkEU+N5lXg5nuiMCLOjCs0J8VMG2eJUFtciAH
JfGSpvbPSozkhVbUa0z2jWVMuIbIHmU+0V0v5Rh9gQgH+y4AiyK/EsN/VXcO9GzUPSwJR5ml+ZsR
2eCYmKK/uJ6sOZxmwKICxWV42W7zFs29xzkKgKoQKA5CvLG3ner1EAV8Dq46dwaZhQvdw2B8Xts+
IilwX22HqKG04uo9ZnE0bp9xIHmF7zIVisxGTxcwcyJTK3otgwRkLeonZ8j5cR6RvqiLXpdXLagy
R7LHPMRfiscW8woCxZ74f9mlFKjzVRZu1G2JicAP4gGsDtCC1xGufMxmLl4vWogalynyx570X7iQ
SOvKXCqg6bCHHQyyI+UNRbr/ACNqpUgyCLcd+p1Q3Kt5PxDxrORq4+WwBZzUuEhhOB4Y4kWam5S/
iG8Vfjmco8y+Nig2ut0RJ6KOoZIpYEZAhbPURcjj5zY817bDv8yxfi0Pk+5wlgX9w3lg817LZUg5
ijZdToFeOf8AYSS8cS2o7LgeHxBCbHiLFebOSq/DHAiPqYWIYQIWo2xVFO2Xu1enxUmD4X8mWBZQ
2rog0apC+WRzUmXyUh1JVScLjpUCvbCVwR+bYC3B/SGIAYfLZHuDW3qv9julva/RKqbYV801Lgqx
tZSAlNcZHvA0oCPMTGTTWjuGDCL5b5TQb7eoTysL5C/6miilwVXNwQFK9W2e5bSJQYJwjuQtFDcS
4civ+RKqSb9XeVGRLVtcYwROisx0bxEVJC3ffMB2WFV+/wC4hQCxq/EZEbhp4Q8wKTFKiN+GDRz+
cqCqS4EKtwwvxXSCdxFaRvec+oQuuZdLszvahcarFKuzI8BtDyJqS+rweSMUIoHTjn9wA0AqLQdV
4gB4HyNISfjuFvEtSYlH8PqXmCqrUx2CgjR9L19wEli6WXf2itGFeCdvx1Gu2wawcgO7Ha3t1AyL
Y2/ddbLiDGunf9FylylzLLYfXcwnWLvmPipY2gaRRRTvpx/2WfR5KB0eotnL8jF0qNu1Xgq+JyQn
cX41GguDKsFg3Gml0lx/JCbRSGdTZVHmibPtUDgo9ZrAFgoZfUoy+agKkW9QxTUeg17JdHBEDSo7
Gc8SoCnzBGt7l4rOiQWU2S1wXCjrSEF9RAW+U4DXq2KvH+4rAyFm6P3BN3a5iKCi4ahv3BQIDUtu
riqhgJUpemvUwF8dzSDljBtoqqlNoo83KSMPEoEUziPOxMlWZXTzCFEQCHbJfcbksUOHMq2jMlkn
lxKPbfEq3yHczUrsLKu3sLQ8BDGtLgo1Hmcs0fzBOjSrqWBmHmUafCmVKEWuIqzlujZeXJeIjO46
t9qIDdpTx5iFK5OZqPfBKuz11AQOCMl5DTt+pfCwPcsvE0WNiWX5CA0nEAwv4nFRzawbAL5lyQSO
fa9wFmhqpYFF+YoVEfMYjk5JSXqoFOcdxCLbOICXHmA4X4iJbOqlMAL6JqnT3KgB8iIaGmN6dL48
RFINVzE0pYOzkYFrYBduyWLZnB/E1K4l8ZXTxUYqZQ4pSPGIfMOZvQuV/TSrEgPgqxbFulZQI/EO
L8MxA7kg8+YAFp0oEWlUACEu1lqubB2CAs8dbB3h4HesdcEAeGoiOxC2E5XbZQ27+pQNMvy7PUpQ
FRECiHd2QgpcAuNAnMOOogGjUo6dltivT4gxIvivYGBmgLCpWq03YS4acjwjVSmO9tkK8xlymAKl
Ryw7bh+J0x7gpviURXUeSi3Ra5xgiRT+Yc82ANfMI/B0zctNQPAKruJ+rlUY1G3qHi4Nu6IVu9wf
xigyvqAj9V3sUIQs4w+Yb5h8T+Y+sHA1xWdRJdCFTf3ESF1/0lKJpVziaRISaNhSLyqK/MGiFiNf
4mUK6TPmDijfCG+5b50B79LAVXr2JHkMq2j5h4spQXDzbalqyWUriZAJ24EU1LhQ7UJyigL944Ax
hxXqKC0aHqWgjU6Tvl0TL8V13/EUmdwLSXdMGwAFf3CzVBh1j7gqrAZSmw11mU/u/ArE+CUWf5RW
x7SWj9wapTbO4h31H4wV9lTRdIHDRrRANpbnfxGH3XZXmFeTL68sGoWj5QVib2wj+cxQvuB9hRQG
CqvAnXhO0DxLOGz1BgbKEvpOVVqwy8+q4TM9ZaWWxO9AZDnj7PKWhYa1EzWrBp/sUJeTo0pw/EvW
UQcG1f5jw8heB2/+xmzeJdHX7idbeNRc3tVz3CKMN6KH6hvw8Q7mJFNXdVLi7qHl3/kJFRWajdf4
mvZAHgeHqFeAUWl2667qNg1No18oIpa87x/kx3wsVnhgtoCrD+oYFdTyazrzOHYllBwVxUAjNfyu
2FCxCnGtnKFBRjZdRau2LV7rmFfQpFd7KfNWN7lK5zHJNtlT7Mjb7XW5KviL1GfhL4lEb+oqDqCn
2+4CKeZj8xo3VCBizoKC7gIa6zD6ihVHh1EJQStt7Y5aLG1u4H4F3tBfNwJSTdJ59QlYEsUW6fMe
Nywwe2JgqoKWnz5l4BByF5IjOujy9fUtidXkz4qbk3AaAfEMFoOobkDU0p1bKyer9De3uoU4CZnF
eIltj81HdGatbK4lv6b92SrIXe2oN3RAmP8Am0bD8IJfEEUdA5lrCBgFVLclR5BjQR8xUpsoh9X0
RI5CeJ78w9LpNaQjC7FWx7/mazi5R8XHTT0XGBGhjwp4iPs8RF3mj7lD8YChsvlgFKNeJUeb6ldC
jpJwbdmFZ4nc4mDCXM+Ri5W0+JasVHUql0x4h5qlBQq6jR1nbieWHVVKowvYA9RpWmcRAvg8RD2i
JShhu4C2T4IUEcvmbBpTiPQFiFK/xENKC8lGmDglgOuI4BRJ4SA5t9Q5mm5Rxw6lCcwORzzC9kS+
h6gUr7MAtv8AMtBffUWHfMUHyl3xEAB724rPE5iCh0VHo2e5teMya6B8yxbGwyfpBonPMSkePiGN
pc5Hi2Oo9KyJdRz3FRrlUtbeJZdPT4hFVWgypdUdRw8KeYdW2+4r8TuJAO8QLfUR1pMWFcwQib1K
5lxq/EuROaagWeF1mQABfMFq/vibE5riFLeEoV3Mn2nKAE25qOG+WGIJXdkuEz1E2GvuKYth6j4P
OQCCpffU8YPTAVsdCI5+UBIG8QFCuvofBKVWu3b/AMivakJi6kWtpUhJsp0x5yvRIAUzhScWo0P+
JuLKBkApiwSn5iZsvlWfEOdUWcfcuS7EC/iLwDRWwkCp2wQPCvEMMaHuUYGsoUGrEZRKKfuA5UR6
hScNxE1Vaym076hTFqJAEfMSpdEOOKhqqUi2vIV+4rnuQyyp8EsQrgcjDUC12VRWrFtK5eBHoKLF
x1sIDpZ7KT7mooPKli04RVeII7DEYcFOy+wUCFAqosutwk6zuLipuVTlP9z4QFtlaMPOXCIl5pxN
88KystnalRKlh7zEd3a2M2x0llEtHysADfhZyB9FFHtXdNROePD/ANgwnh3sPHzbS4iw08WyCBH2
sxqXLu02FD4ZETqGHpbgNHjsyCCNfbY1C92dfzBKrk4WxTwPNn/Yi4a6LsV2S9EBi77ogUDRuw1K
IDT0S5L6EAWwOlYILhwdTAWeE5IdrTLGn7hGqumJCUHxDLd12/2K0Auy8+JgOO7lBCFWl9wGe+w4
l3KXUUU6KqUVBdXe/uUilPBzG5dsHHuQ8gHRLumVQuAEsSpBU4w/qHDnd1/kbsE7ogDQeC+f1FLs
HgbLxlmcK7qzrXXzHAGcFlzoIdAyUjQJlwY/SLi7C7HJ8QQFAGig7nM+g7jauG0Ylde3uZpVywII
PqIRaAcVB6iBhQ6yJ2qXy2Sgep5BPO2trE9W9XajGM8NcQQXaRJebbqpeU57TY0Xhb2V+q8VHUUb
4Ilwu/UJ2h50uOpUeaJZeAdTkKsOJwCHtFRIHFHEFRdqxIaFQxfggXFu4zE/JkUC0ji5VxFNhmsb
rgYWwaYtBo+Y6FiLO1vxLXoOAgkVq8y20UzciUQsa+Z4WV1AqW+FRNC2XUBT30whaDpWVAFEtu4A
oKV8XBU0Skmk4ncBYXWUjABwOfUewqzqv7uBSB2dSmv5DxLlRxtRYBobbblyUe+oXts+ajuDSHHi
IdA8XFTX8wB0bOKzZXxGWCnzKUDcamk4+oCFFuISut4i1cbiLdVXLmw3wQDOVwNCckAYXdrngVeY
LVh4IU4txWAE27jAt57gs3vO9wXfVjwA09RdrZLVVU68x0V45hYHL1NBj/EMBijzzUopyU8RI16R
Ts0GrIqPNXUpYr6IaNcWQunPUeQyraV7gwrVwIW7WU2HJjoKafEAB/mIfL3EybYGruURyeYuTauY
HmvHMHVghgTTeHUaj1yRE4HhlDGKFikwLW8ZLNz6iCgs5uat8xAGMsexewsq+WKHL4QcigNgNNPU
NLseNlJQt6uKOG3oSr4Sz1lFXEdjhuK6bfEWANyxeLpmxpUquXrYO6aWAUTO4QXovES1e/1LE5Nc
RFarZY852T6Igtb8RQ3bV1Gg52l+mDyEsA5ZwLFkXX40GFxO4aU1vqpWKK+IoXlUYkt4e5WnpajG
GMoVosgFFZ5LHZLA5AMwWVhjwiOCfxDRowv0h5S1iCBVtIEvJ18NIpqGz9ps4XtMmTtwMq+oTgxg
yWxd3QdQmHVylF+oiibfMwolQXIaXqNi3Ye4t+MqpRa1goKvioCC0ORE++UsU0qCu96qVVhrmF8M
OpqFqeoiK9Q1EFq68RYoONhtl3PtOpwbYQUsUXEU1fTC9laISiGqc7hactlGzblrr1xOpaniL25v
mJx56Ys5PMLIbErYjOhlpS/UreXmDCFpKl1LC6lrvFOO467/AHEKjY8EQtp+YyzyzB65iQ6lLOOD
zDDPPv6mK9INYPiDSre7nGe5QAN8yhcX3GALahV1XxMY28QNLxItKyjmN9LT4gTXbzcQVfUTf5jY
uKGmwyWFcQAk29JZ1hXEfa64yO40YqjYcSgDacj9jqMK1dxd+nRhAEA0+GKbpfXmFF1YVCl8RBVg
YR2s0MFusPIQMOZaA+Klkp29JdK34jp1fEXNXR1nBsPIIb8JEfaDFYKp4X3EBRd6IGCueIM0GLMq
UnMQiuA0l6jo1xCtPDZZLCucQRbz2EdLYasZbmbU4ZsKtFa/Eym48yuBqxrqx5YxcUjyiu1h1TYG
wXTR52JlHLzEgCPeTHjcoTpEtKLhwGkBtWvUoVoKeR5iODr34IM9pxNIWmRG3MQBicsVZ6RZ0OVC
+jmWhyhVuMXTBphIOGwLKB8TwljaoPmdDvhlFG7dsendfuJ4J7li4YWIADh1FJyHc57g5T3E55+G
Kl12jct2Al++JTyH3LeUhp6RV1GtZKGsVylNSsD3THI9MuA4KPXcUI5JrQ9mUACcrGabqpUswliz
q7gkql7LLa08ShgNcsRi0+SWFLKq5VR+4WoccQNN4cGHY0+oJjanBaSuYSkIlFH1KKObqaitxcAS
3HiLWhPEGiv4lwLUMtxfcpbXdRG1qBWy1lXExHzGRa75YbSx8wAXfhARr4PU62bG8uRlbDsIHSZn
MO3s7eodAr2dwGrd3NKc+CZrtH8xtiAG3c8Qtb4viE4xuLfNpWLnwSqaqx7IEE8LIglt3wwTFQ8V
zBwTDG7lnHbkl+UeY2k+UCaC44HD0vcV1oxpS72viUvs+GXoL2AaHXMCjTzOQHzDDVrkLdXSAtq/
cQi48worZlbOPn4iU6vGRV0y+4CyquYWsthgK0K2W8ZTWt9RQQ9M1DtN1NW5+IKhf2TYVaPMAD4j
kVa6hSVDBW+4l4/MOzYqs42GTAQHkjfkNvk7nFOFvMOWhVwFTMXa+IteIJ5lqEb/AKEfoFbQFVVD
buUp8Ic+Js+BS8DRBXxL+wZz7hhEHCMrFA14IAVCKfuG7XpLHCy5ygc5NBQOmaHbzEAYGzqdLYCn
JXuWzgRldHcRpmRDwpgOxjmAOjXUE7QPUFDb1UGnlStUS42SmvXUG+nZFJQpniAWW2+KhREKWQW3
yRrHYDWPA4llbSAw21i0pX5iCh16Sxdu5Z+vERiLwfmcSNxgwtJa5RmHHHMNDcQux0mGwDhYxTAD
zEopuoRVXfUAaqx8S0AhZ5koIq33xGr4TqLCqiVfEoCOyhLx7iphkzsNJfwgjDs6lpxiFtKu4Grw
QgKEOWBq5f1EhtxLOqAuXfcuuy1B6jFljmoounmWFUofEwq+5yCKgObWRKBhLBeDCmn4lOC2VKQT
Fu4hP1KkrZenMbWK7VE0ODljPdluTgDV9eYThytYoC7g1LHRUaK4eGAobtjQX5Sqq6jqa6tlsVe8
LEDjGN0GvTOC7UALwC4UGrOV3BhefEfakOZnII2MKuyyhEWfbmoJtfdRb6zAMU+4Fu7ErZUyHuuo
vRvMDHgDiKtHK2ch1W3Ls2HVS4C3XiLPjkiEde4dgZ1Cnpo6mamrgvQ81KBatJQpfO3E0NVleZRE
AJvTWKcqB25V1V8qTlA4sqMQ32XzE5KeJ2dufMpYLzCInBqk8wsb6ISo3qGFP1Eso1iLOB4iahdR
Ba66YsLUqokU8x2zKiqG2LpK7FHUEq4dXBRajbaYmlf/ANiUK0czlsKxJdfiKNAhcDpqbpNfcaFP
LuImKUhsUHUwvyymir7tnNn5eI8iu3cRMWrgWQaTmCwWv6E4nFcMTh3U0WVCyhTnELa8d5KFTz0w
KjSN4weIBTB8wtg5UIBS4FgWYIF2xCznxNS2L1AUvUTTz4qeNVWe42INIGXjuMtrdnEKWwcbsvmI
hQlBc/EeMprmPtMOiNtu+IK97cE5f5iaKHg5m5uNbv76hYUMrdljk24ZyEQK5hHNVBp5OJQWQdxI
ecuZvFKgY2hxcVoLajVrOniF0WFVsRUWzcSgOWWxwFT1GByhuq+YivrmoMunHTG1XjxLWgbPMALo
OyYEb4yBXfyRwCnqAHiAffqApoA/mPh4l8H7iULt8DxEoovfMbSir5lOkznZeWcRYNpfELPdT0Y7
NgvFQkpUyyLY8JbhVfTEQdwaQhqNF3BQDkANinliCS7XbLWRS3niIgMvGe9dC97xDE2sN+D/ACCN
hTwfMucORG8xDsLXFaAW15fMIXVg9wwXr7whk7BoyHBdtwzxqw5yXb1N+huCzgl/qGBh787DV3SJ
R7lRmKbFetgWA/JO887USqPfEy4Khd8wVbPC4htN9bLLn6lZy5KDC51EtnF/EpedwTg9fMqkV0LC
AA9ZEU0xLIMCFDR8QNS2giF0xObjmElEBUeWNqNO4FDnzG87JXQvtcFixUI1A2VE4hwepUKnm5Zq
zzLQVlNBr1ErjlCdFQR4zuHo0MoUFo8y9psY4B2UNGvqO1Zk6UZS1qXTfmUAqviG3ltyMccWHEyo
qlUVBTCwA0HDiciu3EoW/SeTgzJQo6e4VYMqFCrd6MbG+5akeb5lmm9VNGK/8MMKWqU7uvCUjVMn
J0ZkrS1DBVOwFdwJp3IN0HXiKxYA99yopSsaWKrlO4sNbG8dvEMgNbM+rIKiviKcOxwFiVctS8jS
IwLziJMF3x4j7Lg6g8AZsew00Up3KGVuXBe9cxOTC7l0eAfiJHCuyOlup0xXYp59QBO08+JnLSsG
K0DleYgKpXqWK1uWUHHo+IdpFHiohcFSywuvUuBHXqWrQTtijTRajhRIWoV+kqSbU5iB17XE1wQL
UaQ7WL+RxA1VO/MJBV0irxeVK68wiLwQsTtMj02s8xYlKHDAGCWH3B1DaRX0dSwvzKoNGMOF8+ZQ
lCeSLb2WVfcF6KKsIFDZXMrcuuSJReXxEECJokKV0eLUSlVhyeJjpPmoLDwRTd081Nh1CAFDqiWS
m+9QCFU8wBuVVZFIcQDuzxUabO1K2B4CDfO8fERAWeaJUwPhaiC21lRF3ioJXYEzgtf5huFP6hWG
ucjyVzFxXvxFbtX4lSmr9sUaJFAh1LBeAzRSWtZkVc8TWDjmaVmOQgiyocwV11qyNRi3aTVW1Wix
aI9KhRQ4S6YAwrIzRbErIwDbdzWhbNSlyq3GWCNi222BzATa/cqyUHMtFY1ULHK+5ecF3+ZraJb6
ihc97HAVGrA2rY7lgZ0uVCj6I6OX4lQhTAjaKZctRL409riGg4+YryruILVDykvRAGxHF3uCFovq
NrrVdVFDvnz6iWUqFWbC1qJaXvzDk5XxOHPGVOW2/wAwVC56gQBFOpRdefogz4HYkua78Q23eOUQ
RBbuogGlHuUstjBbTCSgt8QSSp1C9WMPNpXLCy/OfEsBXywbS6L25QaHOpe1x2wUgSqogCtAXdVC
LVTOaKficwzDid6t1RGoDKfMMocqVKZeMV9zhY0Bd98RAi3UonJTxfBOlaFnuDLSvbxCgEGMXLO7
5l6zbc54dD9wJ1TbvaphasC4XLoFvd9eoauY+i9lhsDipTJX08TJkBD6hAnNSQ/pxvmMZ5ao0ii0
SA59wIoUOZzCCr6ojfaRYKhy0bLviFzdZcuQ9w0baZBO+UxOTuJ0a+4YvHiLTRzkpFv3FTSa4lBX
nuASC4CsiLIpOKjEJRsFRtU4ElJTdvIBDijruYAqnmGU4hNeALtlihu+4g5v8y4aauxVtcyvJXzC
KCr7gYc75Zkothf8KijGS2zERzx77iud76I2B07jg3UFq1tD8xmLGLr4OIF9l+YglK+GC8HqWjg+
ZSjfKYdahUWyWHY9ygBvT6nAF9OIvNcuRrRUtGMQFU0wcpb5jUufXMCPmUJwPEMhVIJBZuVAY4lW
u4QhyVeRTinzKisrT7hdi18JkTnOREo0S0UoPEtZvOZw/Uc3ZgKpTywjZz4lVRkVt44ieajGla3m
5cKrYVHAuYTaLGJL0bArbvuEGlmC+hOKwOrl2q98Rqu15DQwZAAF09RY6HQwDCscyzti3sStbeJa
FCzmDstPATvW3MuckaouPUR5odLK8MrSuYAWKGoV0lrQgFBWcQ0HtrYZZxnULVl5BvKrqJoYRjl2
s4iyqK2l8wFnLyiaFkqWIxPMN0ppLPENRgD7gJyeV7hVDgKiNAoTfJKN4nKiFPCiU8RQYCoaXzNr
qvLEUo4K+SJYCbnxMJVPcbk24IrVK2PGqcqpeAc9QSLceYBvbqJIntZECLyhJcQU9Q6hSJgRCqVa
5g2l1ZKMYXym8bxHGupiQkA3d9g6mR4MFC/gX3LBXLkoaLT6ly/wxsco8xSLh7qKLBrwEsVH5TBW
2KGqKOW3XcKrNQ2EQeJ7Lf5iBsCwi5Pywwu6O0oopepvLt6hOW1DQXFUJbOUNrteI1mrU4gCqC4i
5VJ+4hoIfEVpx4gQtlxcfYfErVLbkgRtSwmrTiEjm+VlKkNppu/mWKuz+JjHLzAaeK8JDsMDVJmT
jEipits2qY8Rw3v3LUp2fiGyiA/U4PV1CL1G7OJay01stqBeVPEK8R7ChzDTfLiAVxvoih8rL+J0
hrzLYJVEUpVYFCgKzzClbluVKMmuUD5h5IPLCNgsYPSuupfAP1OIm+4u3EHa+HUV6Pymgtb3EU83
EAvC+IIKorYB+d2WVjQQUDdxdgRzmW+HiWi2uWLk3LLxsIqz1EUEs9RBA2XKt14gsDFtkTQ29ZCF
RzmHayeL4iHmQNDrUQB1exa2ufeKhRfnxOJYvmAARrzHilsik4UdQSArTmcPOl1Hp3SaHfMINt1z
DAjBWLjaN3aTepccirqH8QqmWlZH35izScB1hZ4EImcQ6PqC0syjn5lwfDacfqNXRxIMQ6VAxzwF
dxWgFcYBYUOcuCGkVX8SKMr2jKC3bRV0StlqeZnembOXqUVnGTmmnU6hK6j0p3uIJba2Ur5HEdXZ
5qolOkEpGQL42P6luF3uN0Bp3GjoFamVNTbrmKxZpyywsBpowheHxXEosOEqUArWuYs9nSy6158T
Pr5hIAV66gecvTGLtPCeLfjqZbsYh4NZycFF7Babp8QEDncBKviLyE8y6XwukQaHWkSLYB067iAE
oU4LzDBWeKdyhZ1ANb+GARwvYggC28wUcdcxtDx7uVqLsRoE3m4tt5fUWtNvREdwhgt8MNOLlMtp
F8Ndw00fcI9f4lVa5KmAsDFKHEtYzLJkLgsU3AbOfEtVzqOm+YlDlmxlA9EUjVg55hoL5igqaQtl
7IIpyQgiS3iCBbtZQkws6ljDpbks0+ne4FnVeIbXnxDWBun8zpgwz2lcREKKymFwheBAgtFc0pRX
qGwVB+YYJw4iXlsizZfSHJrHGNRFMVNjVtI3oU9Edg0p3ERwJSFLXKForIqoKf4iCFC+5wb8iM9W
k4hmbc2CxBpYLiWprBaZZnJeDU0/CQaN4eNUQwXXMYKVTc2tYO15iKIvEvtS4QW005i+hScy4KN1
UNhaHuPSC9hHz6sXqZ9QqtF6xIo9mR20N6q8xEItM7gh/CAIbmyIPwe4LstG4DlfzOWdEp8PYw7x
GdRp3i9+YXF0cxo07FiwgNXySyyzNqDVSpEovvFMxo0HqDs+s+Wc+JjXQOPMaaFp4i7whLKC2+ag
x4ImtAiLYeunxHHQ1iJG4BwyuGp0EeqIib0Oo96omOFRy6iDQfMsILrzA07vqAKRdRtUAvE0d4Kg
DrTtj0Hg4lhXSxQJZ7hLNBmxDAx8S3D8CbN9uZQVVoLlq+oyI+GI8CsMCKcIAi1wEDbLXzAvBgFs
LfCRal+iUgxXqXhp5ZFCB8BMchqIyHD1OK08RTFK6ylSUhovaJsvAr2xA1VdShrDm1NIV25lAWRG
iMCsuKMULzEnV10RK9nxMTiICTO3zOEUpsHnmGFueEg0vl1KvtRLOx6l8uG8qUHSLKHcwcR5Qpp9
XChqj1UA81G46iwuHTuIFbwz5xCCjepM29QKlbkL3WDmfRLoVtzyB48RrktZgXV/UEeVctlBGg4P
UdBuypT1KAvPqDzbvBUV59kpyC4Q0itxLLeVLPFDkYKnXjqGY4+Y4Qy7tl7DR5ls98qIwlCNgBaq
LyD30pctldQ8IfqATY0bh2RSoEG9jw9pZslHFQUDW2hEhBHiWCldfKcFO1q67jcd5xAIvUFPUvtK
cYtF9jLj4qGXLY90cMXYakuRBd3kqzSrRUFi5H+0V17QXJcrgU+492c5pWsEVwloeEousNvuM8z2
iQApnKeIggTYUV0krAp3vcoHA24ILx1HI9+on71wsCUOyK1enuBbtWQn3rzsJ51UStGLhANREQHY
yglCth5qGj9R60neEWnMVLrmAF37hVUR2EVK3VuJQVcRCK5YsKacxxC6cQGv9y9ARYA0L8ywOedm
wAwdbvlgU7ZiW1cCU+Jb+SIqoqezxKcvXMdxjzKNYr4jTP4jLGKWCmRShy8MAlra25dT3BUvU8Si
AbGtHXMHCGkoHhneaeiH8ghPEi2LZ6gbB247t5nBVruIh0cxldZkCLu0R4Ue5VELyogyivEAaW68
QKypWqjWcJRNKLu5gcnhghPbnxKaAkuUvgL3CrwCIoyjbllh/pDmrp2JsrC24AXanhgGFgaWZtwe
YwAFaagoREcMQ1hcqyKYCsoAyNInSA0TFUfuJedogzxY1KVSC7lLC8DIpcvHiKWja/ctoKW1rzLF
LovqaBodsLzS22bUcmJceiIg5ZG1QleDJdKvsiOiiqgZfyjVLu2AN8ceoq0WGsr1Ka5hqBeRYT2S
FAGKYBXVgcytDeB6GLVeD9xLViNq2LuIeSIt2Hqogu2Gsj3tcjGNJDyzc2HtWufcacWviXl2cvM5
BVRtBRPUCFR6EC1rhqVMGs9kVoaHT4g7a9TQrDqHmr5ic2rQYILitEq+IwgldZ3KD2zUBa9hDn+k
VVuwNIK6UN54iTbF7Il0a9x7XQxi1DX1GaVUl3ZXDqfkRNtKstEoqA2dT0Lb0SlOTCSqniopA0iJ
a8PA5gRFiaBEkdH5hftfjolA6L2VyfhCnt5lIHPiENEHbIppJ8T7EGC1AvxABCiu5faa4g7G9mE8
NxmqqeoWwvqGgLqCX9wjrUALWAhbYQWtle8HYr8KeJVuIWIUZXbKGtTYninA0PUUU4T+IVlmRG6a
OoJ0CHuuI8QLrWaOnqWl3flnja6Y0SfiDsqupSwOe4PsrxMrc9RinINwqvmZX3F0lJkS88wUBvYf
xdjl0ThHEsN+GFNmMR20uWXccmHr1AoMLuVQaX1L+GAIw9Qpy42PlcOIA2LSCy2/UYa0vTCyxwUv
mLjdOoN9q9spYEvGPHB3kp20RJQPyIxDlmjgNFPxOhT/AAMRA02WeYbOrFRe6zTAXuZMVI9+omcj
zGnqQBDY30tJRE4BzTmVYK6zzCYyaMfME00WoS8JqIzzi+IRO16lg3O4JenLmEVNmimTRRb4gSuw
FMOYWHFxos54Z2nxEorl8wrTF7ctBde4AIOkSjT3LrHPCw7op7nzDxAd7OoACxcNhPU3F/UHQb9V
KAnbiKtViIgCm9sFvbHiO2Ash9XjzDahXcXt6gwVZ7gYcPjqWA75lmrz6jLXfpHVNnfudU1eZGKq
xfMQS3ZR4vmIj68YxzaUEsjr0dxpLLlg0xgNt69RpmHIqNIBR3GaURQygZ8xb7dSwvkgETVvcAh+
paUSK/OxR0scnAq6PEQKZH25gSWgnZFilsiqBl9yhTsUQ9iEDHPzCWmmruHJoeZfZYjUHO4nKqSo
934gKD5uJtPbUsht41N0u/DAsu9yWQBU2Mo4Ndwy4X6gwLQ8Ts3UIgW1i2Bw4joo88EzT7D3MgtX
ElUeY8Qp5ohi37lUBqoGwIfKBQXYnEISiGhanjzCK031ELTDSHyh2baD3GHDiIgbePMLTVBuRFf3
INAH4TIXDYwEFKrIpCsa4la1ldQK067rKbVohYRNjxNaEeR8TXN08xNCxNiAoodQRcimz+47QHe5
SnkQNJFbFlLLWIUL3fcXAp3KA+11UFirHIAxgaS0UXmWmsLyuYp9wiGVZEAQXLSIF5Mi2FAXSWkW
BtQYzakAYc8xACWd1KN6s8SwFt7hlyhGLd+Y0/BksHL4iAIL8pZS+8lmoyrthRd03EDbJfJo63Eo
aIBe1xlSg+G1LBeKOYhBYvdEIxec0xC0auviNoF7YhKpFw1Gu7IK1Psxrtb5lgi3WBUOZXzKGi3L
lCRR5JVDTSVO92IWFwLl03URk5iquZBgjaq9QSp+4AeOrihxou7ImtWDzKLKfMu8a8x2DZeHF+YK
1xfMPIuohQ4BtRBY4yPaqoPJksrNiEaE7JUq6rmLhLT3BCxFhbZ48SldVEYNX5lYevUw0tD35gQF
a6j1aseY1rOOKIjIfmKQd8wSp1e5UFFQtfEdkAPESgM6yKl4SNKmeYta4ZdBM2ohN5xxAqwgmksn
ITkljik+ZU0XfhhjypHW1r1BCd7VBlKyvUbujXqJ88kFjoaouYHIXBOUQnDXbKIB+CWHkqHwayaq
mq8wVq4j0t44gAFBbYFNae5yKo4yUGrsjgj+CcmThL8sobb4IDdK+4Bt5MJ2PHiWQ84g0EoLvxAd
yB3NIqvWZAr1H0Zc4i2JXcH/AAF+IJIVi/GSjKRbBnMwR33oQUqUxZvxGILQCXEg5PVxVVQOYzsF
3a5h7VNwgGyFFbKeNYsYCARyw60+nqBiUIvmVpvZfM2BXc+4DXRlrLI4VKeGUqvebIBTo7lPr2gD
Vwy4m+VGPtd85AeGNrzCsWLZ6gCNX7jqDY9SzHIQqNkCbDOKiWEOx6lBzr1AWHB7hqvhB3jh6hV4
VzkUuE5eK7ldIyJbD5Ti6xlQqeKmURp7goCc8S3buXBoS1hVUBNCgqXN+ZdjviEdKp/EceECWU4h
cFx5nui+IOmr4g7JtdQVC4qhDTxOB8QzV4lq6UKYLztiGsgB5dRLtVuJwA+D1EV9eq5lVK+00XFs
VDkg0uqP3AIh3sFgGMctjT1BFLpvuAKIe4ANICDVvUS1c87MQ0vUKFufHEsQvzCNNJ4iGrqUl08q
gxgLCVWtvIR3UQZojltg/qFlVvBL3WoNK/Z1DWJE7i2S/JFrlfD1DDbboI5KeREFDGuYgN3KJWjq
OHrohQoioclNqUlVjkKqFK7lgo16lI1eYtTRe7Eoa7Si07lrciB2viC4NNcS1nHVwAaXWzVGt7gw
os4IFyLCMRG+JcPArglsVoXcFDexyrmsh5C7up6gVu2ALq+yHiA0UcqB2mXERFKB7bYkraIztZTY
iQ6VyQMqTuNKJOkFNLKWA2+ozpR7ZjbpzZzOQh0kvYXeHiNKsTxHQsvqUhobumKdTxF6HKDSyEQf
cAAr8kAeB3AJbb8wogpYoEB7JtV5jkOB4Z3MVOF8dWS2ws+JY15PExu+VKVrQZROdRC8uVYYPuBW
jWbcSLyc8QpY5DWI307ueVLY1kb4xagldReezqLfT6g0LlPHcpjtFqict3LtFel7LRXPcVMI4mFN
7UtOAXzAL9Kmg5ZwShPR7g0RTB5Q7YS1vKINPwu5RWFfxOFdhjKECprScyr4RoB9kDSfDFu3ByRV
K/uKrY1zKtKUVsdiHrI9zQ+IrYw5hl+RFI4DuAPlKiniqIDb6krIUVAGs6iNh9ojvZYdvhgBai/B
KkFpiLUfD1NP9kK8U8zS0/ES3d6uY1/UACtiQCo4eYitZuznFSw9CBM1fqG221xUIhy3cJZBzqAp
ArmggHz8KcygY72wKl34lq67L7lEdK6hY8iOk6l+qg8QdiurlhyXvoggmvqXC8fMpXd+2arR+IlG
WDpCh5XDYS15syTg2Znm5bUN93LkMfIQFW2PDKjvUtgC1ds4hjWy7YiXsQ3WhKhCy5lkSfZzAG1t
bDo5WozBdbsJSFKtvMt4Y1elD1vMH1dKtwduRta6hpP9rY+rDpTghIQmLu7h1gAUclyi7UleCo7Y
VV2m4ACLKAxrNlYbcDpUNu5G3sSOeLVdaN9R14VnrzCigTmUlwClfqXbfMQDTykc4cnODOLgWbTz
HAvRCmLdiJkscvmIQH3B3RvOIgrLqW3we5VLZ1UbCtRZw0PEalZceoBe5fTdO4MbBOoqbZ6hQDX4
jXdcpUdjhuQAAbvqLoCxxi4JssgUEaUOJpBjBkHBdzmfM8BscnGBqKgQmWreIaFCsIoCkQaVfiAW
sni4ZXqvEX6N2KjV2cMKrTzBNcPENDe8Tk8u4GnAwM3IgVxCVCG6gr0ypW36npGwlQBcVi7rbloe
uJuunuXGuHhi6U5bkstfUC0O4220Q7qpgolncGJyncWgv0xoXsvKR0bLlxhspVvgvJ4+TkOIEvj+
URza1jEMx6lRRj4iupaeYLpdXmfIcjMdSC5SfEPwC8SlQPhGbfyhQ4g+tO2eozZXDQ4gCG13NXyI
qbP2kKsc4jWgtjG8qvBLAOJfSLKaefERtzfULwWaj7ixr4grSPF+oK0XTU59DY6C6vhmjyO4oFLA
ovmJoGkUNjtmw2G67RKBbRXUTRFU7fRHDQc5CjTyPiCow8eCCAUg/MACtHh17lWhU/cZjz5gALQ8
SgrrtOGy3LXEe+LkOZgNiCIHzEUWxvFiIwv5mCnK0qI0q5cLLPrqPavL11GAOHUZJHNSlFj4JEK4
DlS4hxOSiulwNrDYVydzcCvmAALUWMl64Th2Sc0aZEDYvklyUfTFdlPE2i0sSgir9TjHvqAXVLhW
ewPMUKBA8Tin4S2hwMlRXayxsCvMcGoFPGvFRbWPPEMNbSWM4JzOBqjWWR1ApXhgken1LULV4RF7
o+INUN31OJVbuXoOPshojSdJLGn5dSy7VHfYn7hhDt1sYAPBqTmF9w1aVglb4rqWQsJS1LtwPAcs
6Cb5lel5U2y1inS7KU7mrlH5TAGkCOOfMCllfM0qEO5babwiAaqcrZ9Qajh7gu+bRLHhUoRZ4gAp
L7ggrY4FjUsPiZPzJzrZk7RS/iCJFkV+hGVn33OU1ZADam2r3anMOvMIbg7ULzb7liCeeIJUoTmZ
48RfL1ELrlIOrtMCFwGniCl4bGEFqualhz8ricFeUWlWBLOGx8hXUqC03dSlR05gePVeYcHjzEa8
j1MHSnxF0u66CL8oV1C6XhmY8vqdRofmFo6vcuFY5tP/ADIpatR0RoICpV1NINNy3BK5YBK4+UgH
t55lW07lxR9B3Fo6LgRyWFQaB5nxUn3FcrBQT0QSoMbM4iQU2I/cWG5CzB40fhzHitsRrb0uYMpZ
Cn6gOR3lFDG1oQaFQOhSqmYcLZaBeFeTxHWuAtouaZEoDXr3USNcQguTlVEZLK6IqKPEFjt/Ebfh
fEVTQ+IKvSu55BY+YE4Y+ILgL6nGhLybW35i4V9xDrvojHV75l4XdzMGxocl8S7DgYU2X4qVlV9S
20VlQ5fiYVuzBNH8wSOW4YVagkBdRMUquYJ6ogoVeMsuQ611NtWsurK+ajNqb0xSQuuvM7EdV4g2
k7GojiIQcOS0vDAEV4yOWHiaN3svcK6h8EwKeIqd2SUbV/ybQcVzLar9RdBVfc4DY62/XUxqMuD5
gn2hsBir2jwS4qSyrVX7iorYy1CteYDNY5bNIqTmU/FkcDhXUswV8bECftOFw+iVulN81FUOYMVu
+URRK+UaBXEC3n3DT14qIKo3xKHYIOYCdu4bYBEdOjchWFq8Sg0s5lN6COUDTm40G85IFYWpWymX
8SvuAbOwO4VeL2MlOeqlYXd+GVEvvuPaupnBHyJddKg33HFCtcwNAbMx33U0cJ5CUCgtslkF2aNQ
Ft7xEuapl1HGDrAgFQbvZggpqm4xasQgWAX3BasU6IADRTxFKBpg21AqiNz+otzU6lFqYm/MGFJ8
cxLBd1+GJ4IDpRA6F2EUtD1+pgBs09xIA14JxF14KgG+eviIVTrySwUX4mYcOSiLGoiNgBqNQqTY
+pz5XSAijwuFoD1dQBVotzOYDA9lRuCnhHgeO4QY7Yip/LKER6e5ws0Vew0G2ha6CF1sEc3OncRD
BFo2uoLs042NQXYTFD8RNlayEQEDGCRuhg2X42GQJWoioKd9VGgr3zGtrHJL8h/pAoVQuI2Fn0QC
EWdkHUXzLiNjkmpGjzcAFscxEEEvSIrTjhi7GPKQQQq3iNbbvIwE3OSriqqVf0kNoZyBi7iq5nJU
p7Z7hgNb1lyPJcDc09wDVbULLv8ABFjRT+IBZLRchDz6lyCxOfcY6WnjzNNreJSqHfcaaH3HaiZV
xgb68SgTkgHljscAqJ+IKbviNHgBBTVxoxaOanEvzLR0p8REE2ziVAQChxOPUa7l9nEaZ/cpAx7l
q+fcwnfWRWBxPUw8vEAGG3cgDsXubRk4IXVXqO3hBrsPIxqwLbxMtn/ESkrpKQDUZ7fUs2csIhYn
uNZbPJGTVDyRoC+zCp9hArgp5IA8etjIO0WHR7lkqcE90OeB7RuQL7VDRO4KPhhYtwjIVRxAVGV1
TCJ1DKI9x3BvAeBh1g4nBdxkTrxGCioaLj3eUUtIUIeh4hPn520NXNdWqiARCu5iC3hCSO1Xgrso
jNFS7nM60jyiqZ2PURJXHiikqBggQXixzKLElRCEewX5qXRfxUZeQjcxp06g4FoqinmLrqfEoUrf
iXRemHs0lALbGMnzCq2Bx7jK9fEajluo2P8AkwgobtjviCuLIviq44ZPTkWzgOoi1p1E6LXqVTRX
NxUfMoubHklDRS5cShoGEsSl6wD0lu0/cXdeBOPnJpmviEa+1kR07Wy+uE5YYoaFiijr3E4jXiaV
KO4jAvmWI2PqOLvxKL5e4gVDTE1iBdx1kpIndjFq3rxBs5hFAtFIAPqDTeEqRWdxNxo5EL2LaVcc
QYBoQUGvOdTqERcBe6qPAgnqoBw1VMu6IwsaS1br3KS8tESsWWvaKAZ8iShcvpUUDmMqJEckHGE8
SzwqvEuFBdycl6k59P6gwMdzWggYQxU52RwBy7jFV2ZVQoNUEDuqN5gKhr4i6MWDWnMQGy+fUEuN
9XEBBp8Sq0svjiHEN14giBV2LOwwwDRKbnThLGMasvxEAn5FRxKOsUYVXRssNzqomwumMFQDvNdR
DS95ajGywU8NmN8yvnJSy8BRN9Sm4KEpVVbZcEVtHEBC0wOMB5g3xfCeYuoq+EMKFPNnEAWS0vRb
3B1C/KKBLvME6vYbOEQO3zBYvRFhDKd6IoGP3ANB6HCIgUpcQCeTpfB7jQe6PMFZgw8zlefUWlLq
uGbNDjzKort6g1i07iEBnlmtYOQei+4lLAq0EA4oDuOxKRwlLW6fEWbsE4CNgaU4ypB10CcM+/EL
J/MBK8SURxKORRpT7lID1BY0wIL/AKlAb1+Ij1hFfLxiwgVhXUAKO+I5WWrzAgLHIANH5nJPfxFK
KTxKtEvYv83RMCO2WT8wyUGhZxFtvNhWJkapzPJGbirqPCLp76jSgIWoaN9xrCtXUC6OeYQfsInL
L6gWPnIqQzqquPgKnBAi2eElBwy8lT5bvpMMbDR5iix4lCxXSAGgy4ulO+oWtj8SwPLh9wAO0csV
O0qmASxU4K7ll22AqVGyl3c/EEa3unxFHpfiDS3XUS0eXhlw9Kp4gQDTTxLqcV4iQK2uCdB2tubF
ZxN2P1Fa7iuYIXlR5BGzKOJcL9Itz8AxzWvEBj+oogaXJYlRfERsaPGy1u33L62uRYwa5PHMQgxe
kW1uLhbEsrIaAUFRYpaUL3jkdAbe5jG7/EC2drqU8w7rXshC4HruK0VTuLZtjwc0vCS/E/iYmp4r
mFXecEMilOh3Ks0sq5qpXKnqUB4vZWCgLZ1DClez6lNZ0FMEgByVGttW3pChgC3TC4ekDcMEtXoh
woO8JynrQvPmChGMMlHGDU9ZESEQx5Rs+ws2pfgEWglyKoXzMV8Q1Xk48TamaxdJyEwmThqOlnow
RItWlcHmc7FiGSr++hhI00DtwcaeeErRg5slG3OcQVY53A+dO3EKpfGFANLAICTHFSCDfrIp4/it
gJiGm+IEFjSlRCtnZDYpJX3iNEgL4IuBXYRCmXgqUjC8FbHYi/ELsPoZFKUHKx+kWOACsShECrRr
YSU9CTjpvhJSY9CAUnuEtC1Q6E1KnLFbRLHuBWl6AXKG+4cwuecD5lextVEGCK8XgC7yPSch105x
CpEpdJWR0+XwNEBLE1Vdx+cVzwjItNVZUvSL0kHCo9XjhXiHJiYyli81LcQ6LluGea4lPF7cxI2a
HQQo2PPhGDOFRjUx1BsIj8VGX+Qu018tQlu6pAJ7uyJgOdEfGWohYCLfYllDgG2W012DqomN9QQq
5cAswsZ9s8+4DaGk0nzQ1ZHmhsGJSFjVTuGcwtwr1GaECh4nIlL+XiXyV09IiA2kbYXbytj/ABBF
JhZAyJUHlHi0LskHzLvyyjCH+cbpnP50FqXMIb0S6ADiwiFFi/cSmitV7GbBVqqfUNW0q+E5aHTK
fEro9ChYeY13BVoY4D3eUvR2uRNe4zvEhggygPiJ05R37T6WHI+IGfoCt8pzcEaODz8SjBXyCBhs
KaFO6httve5VsHgFWdoYELUjsdKPVuB3JTnUCEHABEsLAA8w+np2U8ks7egJdne6QHxD9lAHi/Eq
Bn27ePmK+yIsPeRIO3UcA7iZHGnPxE0FPJNhqxTlTFi/iMRKW8kTqOuweCCZRVAU34lo8ereIWqv
6iJ4nUcVeDSUKRuJaJR2Sy4/GENI2a8euYo7V1GTsJgVujImnByXjpXqVZb5RCjURsTlNJTXpq7g
AbvbLMtXHqU9Dfn1FAHO6l0t+CJeZD4HzcBUre4pYL4hauxKohyyqCq85UAxafMoi4HPqEtbJrEv
wzC3z0R4VVbkdWtR8y4ERv1PK1y2UpyJZVSBUArd4ajrjriLqNNw0hnmNCgoQD4r2dQJPNxUv2qm
VFv1HpKHiWggfPcuCnEQmF9xr5PiMCzOyI1PXMtKu04Kii24uoukeLlnQ3ZsHkjaaqpxPTmdfMOF
q3i42G2OEtq6GfMUs0RzwPRFwGdkIEMTezKlFyUtysBX9S62+Kg6NtcVK0sfLxBG7xwxaOH7liWH
xLEEV2q8QKW7+Y0+vNRQvOoYTgOHxNC1UbRzNK/og2za5Y3AWBO0LvpItkwvYu1XLz3CF9HqeQPL
Cy0aFZAJW+EFSWByACgtSl5yRuXb6ia7NwVCAGTFYqhl5SmuYpjepV0jZ70uuQQqWp6Je005Mbka
N3LrRsNjno811EabbsfDBKSqLxxAGrgfmcUTq50SrPG8hXp1ehGPA2inSXKy+FzgCSOc9wgzjXxE
zSqD1FRcGrcRjPLD1BcEWbUSGALvJdVCK7UswiEOrmZLA2vidGKX58SkqFdeYDs09w1c1MDj1LFf
MLNaqE5BYqwSLFuBxKBLfGLAxWlDkRwoBWcCLye+kwRLpjVym3CFsLdtf1ERoHYJDWPmYPLwzAwA
h4cH3HqFjDqGQgK6th9FrFOyoG2DwYO9eCESgNurMlVlwPKikFxapUtOHSzFZzSJT6gJ3UuKPcJN
N43+IgAyuI3UQItanE9wIpfofRBXmdgfETZUY52FqMU8/mNQUaMjEUWTwVcukuW5hKmj/vWV7rR+
ErBcbXEbw1uz/mG/VFb4l5CmuHtEdGKaQXAicbxzELNmqyrh324IvR0VlP1K9/ADmVhqCNlyIsYD
AXKzR917S3OzYXb5lpiLaR+dZT6FqFqfMFh0cgR4VmwgHqWiAiUNRFN7eAMBijqn5Qnd8HV9xBtH
U6WESFqFLJ9tQswCMaEZz5lllGG1+5an0ab/AFDobh1bfMr1gPg9zsiAjPoIOJTEU9TlrVqJWeQQ
BBAQBcwkAm+/wRjXigfmFS0gBwr3Ebcw4UxykHKGy/R5Ytp5tT0rYC8Egf2TYJB36V1FJWW4BcLG
CKV4eIAtu6CY2FleXZ1UdplAAWCv7hVq6GH0Ki51CuF31niHEq0KVBmwPBH0Si0WhqiqicTinA9R
edZCp+iMnhF8lvN9y7vtwD3xKbFdoov3FCOaBZe3mCbS2jOdxz8HgRL1VfOD3f8AUBYuquliwCYA
uImPLo+mbJw4LR8Rc8t0akcW6o+T1LcF4gKcZ1BhIAA06meuxX+kUGzCC2FeJaICkGr5Zf1m2lqK
BTSgtQmxNXAxsgXqAUfgUk2qdVet9K2wIg5aXV8VeRFttUUn1L2eWGB6W4al90Bfn5jIAEw27lof
eUb87h+IwYNEuqqpeXTVEhXHxAj+qK1D1dRjBd4Ch4iuXqNgXmEnSIUv1OfvA7XGB8Qawg2rXs9z
PV1BTXzA5VvU8ouv3H1OuIbVoaRFeC9QAHirqApOKuBgEXmDTxFXAkVYmzWadPEGtrnAgpyjWQvL
drIgV+YxxPuZbu4XRd3KqcL6mzmkAy0ebh4OrBAAoS25quz4lBYn7iMaHGRBMlE4jRO4cBTt2Eaa
eXjxGI7giaR7qG8V8QKjVw1Ms5iNAqnmYgjLIRglqUlEpF2cpFQQAbY3Jb7KghcF/c1eHrYwAtPV
R1H8xXS3KMZbrrgYWljbnqE+mNqyOIaVORujcBGjfc4FUCPltWZFVmh4yVXo81ENGHuWKSCwOpWv
XvIAWdviNhbX1G0CUNmohbyHULDwXYAtdioBhKYPuoEOqjPKW76+4AUC8giEQ45htd31EcNMeO0d
DAGF355jnjfMZmv1BuzxOBSuZVa29JUA1nEqWrCLe1kOSgEaPLmsldw5qDVuvCUam1yckU3CsDnc
xZa81CAl5dsdCq9EYUElm1KnJAAWr6mJUJvzLIo+CIqm9uoULVSq8R7RUVy6eZ+IGFfXxCp5OVgs
sMXQA4Ye3fUpSJrQgW8sORsFK5QVHKOI+/D5iCDTaJc2Hc8XAgL6/U2Cuhiyw4HHuLLRWDDeLQl9
S8F03r5l397/AFxGWsUI1GiJs2dQNZVN/RCMGpWbbgcCDrzUQ5SaO3xHGxoVnBFt9hbrIQVrqu4S
nNpkjl2dwJ+ge8mNKOyp+EqX/MJPp/8AFFVhORvuDBPVsQjA9EEjrNik8QC+0aoxpQ8NQS0inULb
8MfErMr8Aw2d+WDb5qVwYQqs87GTsnJDBJBLTfqDjco1Z9x5UO+2Nz003a/UfNpacfNwN86L+oEA
61QHqXxaUqqhhEeBFv1ETouDkWsotFFfUTDXKUP4hmQal3BcwJyrnOpWDggGPUpoDabZd0Fla/BD
+Xw6V9x4BubD9QR4YKzfqpXJuKcvuOeB0VfwSjrbTwEQXy0W+Lh614FLfqLwoU6qamX30+awQAEG
Fd+KgoN4O8JKdy09mAuyAyvqJQItNwJm0iq7yCf1gibn2t0QFvoCx+JRA1ViL8+I+XaFU/EPbdqX
T0R9G5dkp47l6y4BVK9xdpjFUsQqW65uHbXlHXiuYUlGjIsBf9W3D4bjTxgCI+Kjp4xsZduYAXTy
6QSUUARc7cC4PslSNLK0/mC0WUwAfuHo4xF/CdPuXq/jZaQV0YPPxAwfU1+pvQ1fB8yuEmAKNryx
NvqKm3iuYxdQ1Sk88y9yAbdTHHi1oX0//loIe5FKqfydnDaYB6zlnCjl8xvFpuf9SpiFsD2v5j84
ajUorkfKslEQXdQfMrFQrGHNxWhBy4QtvVsq+PmLiaBbGU1xBT3WzQMiJ2o2gechtcLXk+oIcl0Z
FkwAuWXVVHFo0pS6lSyFyp/lK5UlhG1uToDuhK8SyP0xCud5qcQ7pr7ech5HsAB98Q+MeGI9c3L0
JbCsLX6jIehNOutl5A5Q398xlO70cBxZ7joC7ACdt/EBjNhtnmOWcB0ZXPxFToApNL6hYt88raEc
OPAgTwc+YHX2ipeOGOWRWPDxlxRTlQBW1zL7MsGi6tpidQVg9iXCxmipauqNuCaqGDZLMuI/VBYL
jLiRPA1W9WsW+GowmOfMUdLthr34JXT0OVL5u+IBdFQEBvLxHhQNRR555iOr8nNQIU4QcyHIL6lW
syWAgzlU+4YA2pVsasKUzIwW9B1Nla8ksoSnmAGOu5ZQ9jFw3kQh7Oicw0DGsFCyLgtXmOBaNASj
bF3RxKlqu4XKl8sbZwdivqk4YWv5FltmnENF/US1tV3sJCjkAUbHiUpHJ4BXuW2F4xPNVP5gnZ4A
gYea6l68+WYvM5IFmt6IC8ErnZqlVbkmSA+aiUt5NPcGtC749Q+LlmlyjCPplnZibkAHWusVOng8
xLy87UIS9Mg0A8vEaB28wKDVhwbHEpQUfMKAQuxjywJ93EUn4Sor9IXrn3EmdR/a8yoUWu5mspXc
qSWXkRtncpy7VQ/iW9xFHJAJRu4KwFzFLH1Ei23ssEpgyCqr8PUFwHmoxzagQ6Riwu96JtWx8Tb2
23lxeQgnBLIuUBvzELaNQuCVdwgJqOYjSDnXlUbUiJdsN3RXESw0jdxs7a99TIuKtYWdmtSsll6a
pXiWIpSNpIUHipehP3MdLOXHNDSc3KeQD3DdeSMKTXAwu9urZnljIHkvO4JZiqYgAcOTJVbiy7gV
HQlJvpMD45shVKq7gDTa6JzDi7qUsUqN5XuGAqmID4XefUtcOWlEXPpYROe4Voab4DLDAUbdXASq
PQ7xKGQmWGF2q3dkRIjVQqWEGa3ki5mlbtHW9xsxCpVx1dx/qkKnlcJbREukvAi5GFBcY5XS/COv
QsZFtSAXNuLjsW74fEXx4PKodDoVa9rBzGkfzjN2inD7QFrirnf3FtbXRqAmkxwrLM0H6C2awzuF
/iEsrzvHOjumeISPtHf+ZaBccyPi5SUHYGHyEQ+wK1xsMbrL4gqYAxh5lfgKrWgkdt1coiCiAL8y
8PFNFP3KWDa1CpQueumP+FbWvmUecglP3EOZFlX6meX01fCA0DwGz4iO8FIm/myImSgE/iLII4B8
1UTNjyG/DcXMLxD6qpZ+Qrho7yLnoaKqdS2K4Ab85CaV2Noq7qKsHZwMKkVX7hkDurJH2mapmT0j
1rlhkFfsRjbGejmH+Iw2Hbde9ghmIEh9cSmBKBAr6qFmXp3XxctgJTWLhChtQOqvAuI63GxhxQwo
wAW0HxK301jiqviKt10R+MP6xaunzL4Ysgu/WTecBoP45iVgiyc/TBps3WkZWciI3M81AZi7NiJU
cCAmk35lA100D+oN/QJfCWGy0qUnXMzFzW8J2JYI39EAl0VjuVBRVSL4RFc2No+yC3FzaX1L0Rtk
NX8QZBauy+ycdjwXjynmX3ErLa85HhBlBpnuJbHUT+0qZ+nh6jPa6BT5+I2bVmtfmK4q94uVpkG3
A8TSjKrv/IfF2Hr8wnyw8tJVVxHqW7s/EIcXLuvERA+bBv5nAiXIsxCJBOmZp4XHmut3N8/cFMEp
X4QLS5a2EYqX8uJyr2xs8P1GuPU7bnWD1PvQL81GpSLbuiGL5DcnM0zA8J8QCnHkVrr3EhWUbsZU
Qp2Jf+y8LU4LTlrbhddn4lUPGTg4GYOQeR9/MYAvJ4Hg2cEUA44UQ9Q/LV7n94oATuITy2tsMry6
15JbQAKXRgc+Jzh6PL2sShn0HPHM7guQs8czUPWHk9x1culbfHcGMK2jfxUDX5UA+SNj4FWFHB8R
/wAWTuzy+5uOlpbeDZnJIfQ9Q74wbWWSLR1HCbHiNGxx2IzoYIigWg4uKiXTSgQROB7guL+yJF2f
cYeFh1Oz/wDnMU8JSpre5CrutZ6cOfMUln+yIA+oA1rivUvS3dKlJVVvNgNBco4vzNfAlhr6mYlt
tuNOtrcQl77i2aVNzx5IHh35lDatlKIldQewRO5iQx5iMdpzG8C9ERdSvBKljvYMQdYAVbx1LLo0
jf3bLoo8FQIE0X1Oh6XLsPXdSrlicxtq5GrgKyXTaiUq1xHQlL7IQq75Q73q4jQ0mwrF+biNjVHB
EnoVVRYDYlH5jwS65QwcMcTVN99wCvFJal6MtUoeoq3Snz1KRfL4jfWJFWj4DKTASNCi77lSx58y
6klnBKutDmzhN6qITVsKAxgUW9YgL7L1BR52LOrvVERFPjmWUF75gETepQT2CO2wKK4ZYVx0s62v
uUgXYl/IgDuJiqzdeCIbbzFK9P4RNppmOoFqeuJt2NxKvipQEXL1MLr0epdFGhsSA3XnfuUG2dkX
hoINcardIgFMcalecotFEeY0tznNQC0NeWICq14lhfHvzAVKuuYnc9LqMOF9QEpYJlyzvXa/1ALL
MaiOWtiq6eDqeGPHAS4XrKaxIQLFEV310bBFM0hUH3zKGzhi9/3AbUaGB5nFY5aj6gJkXx+4dVLg
VCEEDylNxTgoUtD1NRF35Q+gbUcpaUhbEGJDGpn2pxJoLr5QPvHzCzV88xeUrEci+yFDwHknQ+CJ
FIswB+YFGb4jG1+8iSrAKl26OLgLFu/ELgtclRMFBiExfNxBfOFrfE6suEi15VC3+IUDjsqLEE72
KzWMsu79uoKGjfMC8nMOFldhbAbV3dqjG0HjlC+Nl1A7KHkSzgcXXEPSVe5QdVwRY1A5yOeJ4VAU
tJ0x4rr2TCoF6s55auLgLKDKNV6lzU+YYBLzmMhgeyIGzvboR4Lr2RUHTkYZaN8kDdx6l46vzU6o
0oNFytJSdzktdbvUFpRXg5lgrX3UoYD1kOFeDiVFZQsXtg2Od4+Yo8BxBRr7qVCaruW4FxAOTOpA
TBUKeSUt5fBNGEOGuIoabYOZRwVHAtkYm7TLlA6OCIg0UyWFCKzI7QqlV78zvXUo8lBx7ilU0vJD
JAFy5U3l241XnhGrKq6lFUl8TFao5RAXI+eSI4ucbDhDyudUj3EgtOcRG68lgBsBJe7fKXZqJxNS
EvsgWU44QU2g7h55JKWsC9VCgUV2SsrfA8kaqtT+I22gcccS6AtcthMvE5liWgN2y5AuLo4OCC3R
XEsL9rhOhHz1BAu0ZoA8MmnkcuWghVuMsEzhSOUt4lSjO7LVNpMgEprYyy84sVOJZVXgrIgJodQ3
KKVECuN58ymzQu8jYQ5ZaAu76gWt7xCqptylh1uIkw8E5xfbKhAackqnmpwQASt14iRKofEYZefE
e77Ea8aHTKDgDVyxU4Y8GE3ZY03niarrzNAIqIWx1FKnpxGeEDkumEGiliuBsf1GG7U3KNtdxoBT
mdka4ItY6meBjWg0Owy5Dk9zDS0djKE19RbL+ZYcti5Esm0dOYhi8SmNXUSm6NrJSDh3NljbgpVo
dxT5Lyhs6yONLH1APaDSCCw1lQRHh6iacC8S1g6uiAAtQ0tDHX4Y3oN5M7PxCsLqoLc58RPLXpIY
2l3EAvCG6mu5SbVbk6bQuphvB2A1L8FwDt3UoAdX8QkhrYgtP4jKCW9S0SsDruaBdZU0HY6TQ10G
WQnFcwCBbeIDaGHDBACq8VESYZ+I6jtXEAQsgQVjtzYFq/mB+nzFFvDY9thhuQ0LjqBKu/EStNJC
vTOIP2QAAL3uOFW1K+Ila4gBfqLJfZiqkN+FlLRA+JVgHHiURQ+S1m+Nf4h+QwgmrgbzxEl2g7VR
KB8vmZLpPRAsb1iUKvq42pWOHuXEu8iC4tyDa0w1LuZxSrYJvCsqr8SqV9gH3EhLvXJHKIl3DMtO
AGNgFrUTIRxVrRPNoWmJ5nDKGORcYTIKpzK8bVZiw/DmaVjh29wWxRqmMV4WA28yvG6K2US7gBbG
RgZDyFZ3PQQ4iQA0ojiI1ynECtrfUFIQ8sWwA9Q/KQtAuyLeiREuIRUCmpYQu3gl/FDxLFu6igij
uEcbncDsL8EEjlXDUphnxCFHGJzAtgziLXnCNxpr8RyCvZ4l6g2OIiFF7E5EqIz4AWEFqitr8JYz
JwGwTsFcCODDwpuJqA4r2VkkbvBsYtieBlxPOh45lxkPHF1A5kHWfqGoEPXUNDdPGcy2CA2zBUre
Dz44iKXmGRTYHc4lElfEK/Pg5hXMDWVNNK5YhB9MEeTL8l29xMrbguMZW93LrYPHU5S7LQW18wiR
F9Jkg4xTvm6gOk5OZYtUPcBVBa5SUQGhiCBfqVSuPuWFGvMbUtdoc3/qlgu15gXRrrxBUBK74jCv
L3EIrTIu8X1GrR+ZVw4gPwZRYt9xsvDx1CyKrNi0beIMRZe4xW2u4402HmLQFoUHUQ6F2QQ0r6iK
19MYi9dVBpqP4iFD6IKtjgjpDDZcVRT2SiWD41Hn3cNcinFSxSHWznlpajODU8Rl8W0LHVcIKvWQ
2O++p0xyziU7Ngxm8btL7iaE28xadKxjdtuEqFDWOXuVQWauUoDzzC41+Iurs8vULCi+Ilqg8B/c
EAAhVRFBfsRhg7u/EoRq147QLAFAa7ibFFSVxHHlcBAWXXIfMVYcJpKFt4ZDBZ7rmUoQcV3ABDju
aSw9sbYHA6gKGj0sAVbziBC4eiIPTffiXrVjyw1p3iFGu3GTSH/SCR9BJS3yhKvVW26gCuKhUO51
sCDXT0jraTf1EwtCeZcCW+oBFOmBcOA8RUaciLL1cRvl1FApjLrwMYrm3mGwW91Ajh5PMNcj/MWb
Wq9TxGPEGFuiwpgxNjUKzEMvtzUEU49MLLctYp8l3UIttv8AUTBTuH8hcrA49TWXd9Q+R8XMDtS6
3yEt6Nj5EKirVE49zkrLKqbh+4CtBIbuivMWjjQypYKKvqHxdX3LBLusLjWeub8QZY2cZ3B7D5lF
a/KHpWr3zKDyvY3B1xRGVFtWcR2LJfUdAGatlFrh9HnjIZ23AAeBzA0WyJ8jkCAMVXUVBbTGXEEN
XEARDgqWLeDIFSCy+j5lIU2BpXARUWsXg8xeVSHEVC3B5jovgy4NwaoSolUvqpezwzArOshJYTm4
2R0rxGhVDFHMaDmCo02XFgEbIoaVR0ppc2cQ1OZuXSoTmceoTTQ+pXg6c3KeoToppSJopFkYdD7l
8lvrxPkAqIGsXH6EdxD5KhId3BEA7aGsKPMbSWDwwJlYVOYVtFDCio57RU9+4Q6mUjzBYKGhrZUC
XwgXIr3X7gqmIKiNSnGjuGwKbnqWml7qccq+D1K45X7TZtj/AGhhDS2nVQWM8Opr4IlgN7H8FKcx
UXXm+Y2vakc5l24oEe2EO7pwIggBdpGGI1xzL2SLKVZ9xF9DjIhtdKCZt1Lz3AazQWQgM8CjmMYu
oBbEx2NQVooNtLiGKDTTmWttt3NDsg5KoECKGLiGoq6xn3GFg3CHFl3FMxEPb+8V4SqDjHAKrZXj
RLwSuarmOCQoeTX9S2wHYzmAmURS5z0oPIUzBL6mXYr8q+pkiHPHiWIFizfRUqDLt+WS4H9DIAnh
Ky+7HMIoR0ZVutGaKj1exer2bUBD/wAeoXHqgPcsBHXWhCoOsAAgblV+5VPk+Y3Rfg6lqSEe2WAP
gnUWzh3ESqIj5VlR1VxeyaF6hcUlL9IrgaTmJ8VrzudRzlMFejU4BooglMHFwYWv3GRXRhhGysh8
HrY7DgYSzmuvEdxg8wIVgq7gsVBcoB6PE4bCtiorBbyIBRsy+psBZblnOXHEPlutjWFXVnU28ni5
jY4GeZ4rrEBpjA7jUU69Q1Bt/E1HaF4QirbF5vg7iOaHJELMGHUCbv8ACXCNNVNUpZhRrgRIStmM
EiI2ffFS7U1fc5F7+pUrtZxEI6ioS4B4cwAPJ8wQeDuXjgOdENL1XfcocBHZcOhDcWAqn5iW93DD
5Bix0vvioIXkuoqhtcD1MyhI7q7zkCAtWpZ3Ogyi8328MFRhvzLttXLfcsAUB4j7AGQrV0FdESJK
nUtA8VNVBmXFuuVFyqJQi2j4ljmI1yuu4hWvCEij4VAO7u4VEQMrZdpu8QTQJeQGILbEufROxEyO
LV9xiNWcsulVkujVQAJEF/MVFDmuIZuxYZ9nIJQzHmaKWOvUWslvUASrSCqMNJcHkMgtOC8mFo3d
Wy27ykQ6W8RoZjG/tRUol7W1Mxi+4au7uUG6teZubHiGkq1SMILXm4pl3TFfIXxFZ0MbQzp7mwuv
TEKmWyLAJCqhz5nCu9VBLFCkQGrvicEKVj6m9R8QSV+GnE1iAvXMQCKrAlGBZYeR5lbBgc1AO3XM
WjW4dL+bhNPL13Gwo5CmF0dxxmlwrt1ly1hx6lvmzxFpgVWXHLQeUWDkcp3GPB+OYJ6574lWm2vL
BEN3bsMG+YVkPNSx6PmUZEvljOltFVKA0G5UA21UJCzCs7j7ZURaIWlgDqABQNNIReY6Ri6jTk9Q
EI0PFx2WIDzLQRY8Qir1Y7ScvJR32QVwUe9QMa+WK6T1GOjiCJEUcDFoeG8lluW0e48t14Z7Moo8
8iGVUHmXVO4N2C+Y3KKvtJYor8wIZoKlr1bipBLLCmqVasYqpUoKG8nI8CzfDKffG6+Ig9MEczUF
bn14lSps/DE8nyV7jBK+YZ3DzAIKlUl7uzD7jLTAtxbgFRbqHcBHAOFp6rh+ZUF0gV9QKwMgHuXj
F3Lx5QuuAe1yqaCteo5ElBL/AJLFlVYcofDYXQfzDcgUkQI7G/DKpjBfxxGB0NL5h+kLadylgNKn
lH3WgFxqFgcD0ht3uQrTNah1mENRFttUJDGMaOoGTk7mCHAlKYQHwjikYLdSrUrHWXyaoeAOIBrO
C+Zbg7L+IJyi8PmMSFfDLj0o9UC5D4g0mkLvxFnK48xApEKVOZVPwqG2HKLb9xsVXFfwnMLcp3kZ
AboL9xqHC0n0RBAGxSFNiirQg8xmZoB+IvnRxd5NELD/ADAKFiyzxcQX842zrAmhce3Ze1h1dhFI
TMy4UCgrlgOFh7IKW2BG0FPn1DFm/cOjiu4vA1JcPUpQX4YyVaggIiVLJKLpTJckCpTfDkm1Hb4l
6q3zHIhpeooAoEW14eaiLa7kxRiIrXOhzElWg5grDm+KgpiWihQ9xAredwUDYhFHlM4WYryMTyUW
kKI5riAwJk4DPcHLUNQ6slufcDUqfBEKhUhvwQxbemVIvVVzFhsS/EFBg8watd0VAXhb4lLIIHAw
+EGUN2sJWuR4lRz1d+JZBTwjRoIlKTYuXcTDaSEhKdy0XA2tQOFXdxNNoLDxLwTdgfEYKVaPUGK6
J11L+gQUJyjzLgaFe4hpVrewWgtY5SKlBLkj6QDxTbjh2dnUbN2teYWDviED6qAHZ8XxLHVamTYu
sirht6nE4F4LiB1erqbVpdzDbjqNUWKiK5jzcwSK9wtXqNBYBVEVdtPEobVTntVMt6jNbQ2c649x
6mVoy7ad4yKaBQ8scdFefiWUU9kwK4gKW18ykjQxuMOURU2fEQqxWlJdUmXzBqFKmAmHcoOauS1I
16gsL2cHa8M0RF3EXVp6gJKt7DelBKAtUOSpQGwJRjz4mhcruIoj81M84m3KKcn8TI4MlUdHMaHF
vTLgoPHMDaqw6EaqNR2EJ6IFe1SyXg8xliwe+ICN34iFr7qWYfHxFtIL7lC25II+LuSo1VeDYFl2
eUEa8VyRaFjbAd8+GAaim5VC36QeBa2OaVXslChl10Q0JfbARbvxBC+6j6u/c5FoxTQlRnhsMNq8
42DBCxwga/hCoB3IkCc+qjdtoq42G0tTzN73BLKQuosOJZxQ8dyhbxi4CtSmMDk34jvQ7qO0LRcS
p8QjTvqXFrnPuULvjmBAL8wA+6YvatIQd0xKm12w+amqYxyNRYk3jxHCl8pM8MQhq7hS5g8wNFaw
qW1ScVN0WwbM4h3qHColWeOTzGcW8wabwZcagZXmCj8lIgtRCLXjSks1vGcS7GwgPiOvWTuqjyoe
bjGkkLUOLicbVT52Kr7eMj+1oBdx6FawDkF0+dhI6rlxZOYWoB8zt6znELaFhzxKW2yXVX6hanzH
uEBbBNf1NGYtpcXlSkJU6LCnZeEloy1NuOduZKCrvxC1HAYGgpF06ZDLqnX2xnauzpEiXYIPxAbq
n5SlCAQFzHgEtoXU1IHNIkChsIHEDiKoPnZe/wAYdQu8CPuKvmUMBYRfi4lBom5u/wCweNg/JUtc
QrjpuXFR3grSlhDIONauyCBYfmlK4XoqiGWxgot8rBXWfyJHOCNLyz3HJbKXfzCtGCn6gKaWxjsH
vVL9EXlbZ/co5zcu6tClBEBvV2MpSKIJxBztQXeOGKvy/iAxB1ZXN0zqIPEFQw0V46JbD8Ihhz/E
tgseLnZVeJctWHMvUE8/EuyX8wRX4i6XDAGs+KjMst4na9HgriJNU2EzzGALl0ovzCwt3K0oB4lR
wrqNgtVPHcGoUBVRgqefzMDNfcsD9QiUcRIK11UrBVvUvguYksQfzKQPJgzE3zxkdpfMTTUbmrVn
iIRWMUUrd2WB4qoRbN9REKrrqM3xa5LItfMtaEsbwijf5I4YcQXXaGZKAbQ1PCqFNA2+YiwxfiAY
J7hvqNwH8CwuneRBGyy/Ma4FibK7gnqDm26qFxAnGRXda4zqA2cvUYKZjUrXtZAqYpjWQogaDuIU
lK5PMRAaIiMXC4KZUoqhbceiJblMQrACygHHAjBPLz4lkUbzUKt/UQqcp1gWPQJZoRr6gwN5zXPq
B5h8MiSJz8kKwpd8VzLiddEEuhcJXKjqMuq4lVcvKuoDWNdIB1s8MaiUc3MisVs7PEnPkvYB2bvi
IgT4QCjkcS+UQ9AUBmmhog2K11KB2LYwIdiDWp3OMZbqIQvb5nsQ0k0Eo3dx1Ya+5a2BeJS+LgoB
G38RAuU6iPRd1HHoctljebsQ8XRMlKtmi27spgsODhFeacSpDbjQL51qUIivVwN3YzmZY8OzKbbX
iErn3GxawiaL4VMFcGLQdoeW64vqaHgOIJXjmXKVQuQVy3NcYvFE4LJXiXLU0wr1NvUt6IYY0l0U
LXUvF7ZGoDcGUEeCiLWuFNkcaHxKKKjXiWVZXExHVyUlN9x4MnMKDEhDfumFAtVzhMVN2nM0Ck5W
EGKXRDr0tvI8BDGX0deCWq70mUNRmTBtt9TNS3zcsa5qHV4VMVu4A0s6cyBBoF6RBnguoWi8emBF
evUug30x2POR8FK6Ira2IJxLZbkQib4QgD81ENlRfiK3YQWWhimeLKWKht4iBtB2aVae5Z/wiUFA
q2KES0bmSi1nIWEFV30QO13ySgNPEQbaasSU75lAEOx2XFpI7TJePEtbcVcHTKzljQ/6j0jVIZF5
cSw0/cMgLa3IErWT6VbnU8tX9xKwvoR8OCrmfHMcCwrfD42IlPEmESELyLb+YrSjy8q4mySA2Puo
CKOy2vqOOWLwQG1Mo4gOA2/9Q+DuKandXhiJJoNR0wmHQBSwhaF7pb3sYIE4FXPcyw7cR91AdyHI
FRCGtau/qGOnEcF8VL8RUxXzUOVaIrv0yxUkXvtBnbq1t+I2R55HxUs+aaOyIwFPnmD0xFCrHoxI
2Kq3+pbUZnz+oAQarSkTHnF5z9GXkWWaLF7E/ZcVGtbcKfeqoi4CC92QeEAGwL65j4jQ3h7Zy7g7
BwlxwWwCZ/RUEsHbPHiVyCrdkp7/AGc/iJwEpLAIvSxnS7fUobuvPmNqE8KqUhEqNLBfmbVtR2pf
dxAEPBIxU6FWKJYBb/MSsGRVwWLsWgWOLgNaeQhhUuMMpRdwPUCyLYNfXVRj+CGhXCZX4mPy4Oor
h3rFl3ffUX2PFykKqpgUtlcZEb5aNZKItrkiFBsiDexCbbNAbqFlPdQq0J6QpHF8s1GJwwNk1PMZ
H9xUKeYFi5Yxy8yihVT1EGuOBUsBWcxcBvE2IdOCPqs5uKFWvUunsti3Zy31CGovAO4IIJSNYH0x
KZQubAJSj7hY1teZotot1OA0HfUc4qcxqLqC3OaSz1AEPSWUG3rxKToW0jALfwhuFnDxN2YvMdrs
dzJHCueciV8t65l0lI4pFU079Rtrxt7Eru3ekOq0HQ8SrB9zjTwuAFwT31DFLy+YFvBxBKRbSWEP
Ds4IGXR89ywLzfE3WKeCALYFjynBdTQOYzmwVUaNVHFC7Llu4lHmX0XgikKwlmBQSw1ncaHlX5ja
tw9QVdfiGXLa2MGgXxAVDTVXAtI3fXconA7sUErTbhY2wFa6gKAfuXAyvcrAPi5fJ5Il1XD34mjt
luQG1nuMLg+pQJnuC0tlXTEFcF30RCw71EFRx1KBQ0yUI2GXm3HMwBZjYSC++YjiNGcRsLVxjU0F
UjrHiip0ilAS+CI2sDgeIF4A76lsxb8wo02Ha6jTQHdkLEtrT3ERKqziDgYuiVTBOfMVXCntITA0
J9yqJY3F54nWVD1LhcviaQ1AVFdJQA1Y8xpUWnqAWmnCApdHEyBvFy6YA8QKvL5uBQPl8x6/GogC
nvric30Sig2+oQFgUiy2IqSVxAJrErrxKFc8XAtpqsqHwNyaAADLnJS/UKEpa2qgwGy3EQq0c91z
cvSV/wAhzXkW+1S9lJZ5uWoVx4lm6GvcRsjeKnAAqFUptyoTaXBNuNXFdV5iK3jmywgvFWS4Sirf
MJW2/EqnxsqN8EswUdS1FX1ROfhjsu+HxMQjORKwI1cupdgFXmCjdXuzjTovZV8ECB5u8i0Y13At
N+ooVd5TDftqiZSr7YAr9wpC25W5GZa65yRF3FyqZljWX7xKMnA52OdV0rEtlZTXCFKA7scUR4OD
Lxgy3CIWU1oi8UMWolxHRUaw+ceSU9qOK5PMpilPCTkljyQw1RcyfXV1ccRpwNZErG1HtDq7glA1
NquCVVG/WQLQo4UvKJ7UDG63NUKXMsUI1dxU3x/M7C3mo0KVDO4ASt3yjHkJSusbw5l7jsjSle6j
1zWwab3PA0JoRMEMzMUpdKhSdzaZKfNjyVBxNfEATdrjZbN0QOtN3xkHWjUlTf0hrZWAYvqOuVMA
4m0q75qXlDfBO528Oy5yD1GgOCAwKLvqai9ZsIbs+CIRVOWuJcOfmGVXEYrtqoEfui0muyiBi0c7
FeuRxYuUJwuIwwjUQtbKHTzVG0W/UahBemUHhykLNAIlyCKZmUudy1o3/UFiGOagK1yyqDpieYsQ
DVGdQQcNx9pq8RqPaFrQpxUoWEvKIoFLYxgI/Ebire5RKqK5norrqNc1d8HcNbVHcTqC3qZU1TyR
pW7ih2CldjFol3LcLF8cxy7Y7I3IbxHO8BESAU3RbK0X5o8rxF5sJA2/MGv62yX2Y2pdIMrYsP5l
49c0D4hFpuiN5zF1spRxEbThWaJacrMSs5sljkcd9wPPqYC+XqOKqWfcb6ceIVVbTMgpbpqiPajP
Eta+mKeW1igLveGNfURBS/Cy7TlVPicFprghjxvMypb11C6WHtUrhKHLGW0KvIQt3PuDbMcLzEgb
MaYEh1K4JPTuUkhfLDFFKk+0g1DFhUQ1M/aKgJTl7IGrf/IONr6hRTSGRQNZUS8stXGsaMbhFW6k
uDhVRAt06JY8deI7W4FX4hclYa2aBunllgCwNwjSLORJsCqh8hGV3vCAYHW1KEa0SbRfC6mG3PUU
EancsX2lyhLOJaIh00PHUeY3GdRbcqOAN0bEIJqwMrTBIdv0hZ9MLupgRfXgiFnZ0y8Xb6nBa29C
Lf4VLUr4iguPEd1dmxm/VwqeznzLoIs8RkWL5iaroqqjVwXaEgCOea5hVir4liwUPNQqauZVH8Rd
FqzmtEqKkHTGiNqGMzvGZtC31BZVVbUIE7iMJb4jS6VzA0nniLgOnmWu0Kispb2pUs0LgOHqvepw
Da6mWtWPEWfgGoIVpG4OpuruOaF8VAecKS+KYDuPVxK4Hr4hRE54mXb2oCR0DGEXk/xNXBfccYgA
La8EdbdeIgeR9EI38seRsqe5T3FWcV+IAG7KmwfRAIDe1kGCvgRJNAbSA8beYYttn1KBV4VVTL2t
hUoqvMULZZwRumXc0O+aZakC3SWDXgsJ6mJstUXvmAxtech0WYdotynqBAuuyo9qDxOROTlw0cL1
BFGeIFvYoD+Uq9PPLzCIvKy+4VLbC69wBwCe2cTVdaaoNyHaLRYHUHiJta4iNoLaBzUDHQRFW0NW
KWVY4KaGfEpFaCGw7hevEBgTfyj2hYto42V+9gDRLL1AZRV1qNdRFbFiLjvzDa3qq6gAXCocxqU8
yYG4CmgQDkjdHQHECp7YupE4syI5sYAnZNWuB9KxAISimycGvqKhOwKBI1YKSM0nxxOXW4Jcu0A5
OJW4tsp1HQAsAvLi8hB9Ajel29jmDTd8STa41TGUDFOOKuEqWIA7p4gtW8JacCx6QgYY3wiYFD4P
MDMEOssppAyn8RlDfh5jW0DcrKbqEwvDMhDBFHtHHOPRzEK8F8TaoY5aTDC7ouH2HcDZTevaW3AA
vS/MBGVxlb6iB9vDBYlPUpW3ppK2+mqSWciaurlwCipXUT2GoRLlxtzmdjZpFJesNoiqiIDhfEC4
MKNU1HSafYKgWFXZTLF5sca+YKhq9QyjHs14jkDu1VfUGtUOZlGjULsgLSHBkl+AtU9okalgzPJZ
7yRkzFkoEHIPFcEENcy4QB7SGfcJXF4W8fE4DGxS/E6wAnCLYonMFQM8mU4G4scNA7hQ31KaiBEd
lf7inheqTldivXmIscx1U42WGmGxtMrYINE8vjmVld8jl3Dw0F2dxv8AMrZCCtX2qF+RsRpa6jqp
E3rzCYtSh81Ha+bnxOCKyDxQLndMQORdUiI0oupQISkclIFQ3xcebCOxVxHx/wAES0teUcxppp+I
Chjy4GkuML8xJovsy8LtYjEhVUsPv/5ESCWaH6hHlIV8QkYYYRWTYQnHvmPdI1viNNW0omv+mDXR
u0SsrhaTIPl1EYI9cRW0aHoNjpaWnuWSzyyWGKdwulg/mOghw3OZZtNeo7JYefE1AU6je7x3AWFx
TRCuYNIoj3BXbcuGp3C68j3H43Kl5dGLS9N3ISBw0EVVuniA2uq3ZZRRxyQo9Fh3pT1LhquhUW0r
qVsFlNaSgit8PUxgreZ1GPdx2oHz6lA2yuOo7Y0eCOIvq7jovLghXIAuyAxMMM5jhwPcNP2qG2Kv
liR2INikXmPTZ8E1BNPMu/XKBermJQQ1Zy3fiEdXl4qAUGj3CaFtzmWNdDx4iXTSeJwKlNmxqOyY
AsHTNisvI2dNw7ALksovOyaoVRUdpceIinCNan8wAAxHQFHmIVZncQGl8EWwrP5i6HxUICueUqzt
JWw63U8QEmL7jBpv44lDNv8AUuFml7FtYtFfEZC231GjRmwK2S9IeIxzDhiU292G8CioBaik4hTQ
1VXLQb18Raqcuo0QXRcSAsqZXPsjinwRqLzq4chz5g2HttQQU/xBIAvNwjdctxtgtPMIsYuCWPRT
YKBaL2UCtbyr4mNO3lRFbavEcO2tFjAPIiAhd3LLQVRKWF2gFyvb8QKWMATkc5Kna2uPcyVnojc7
eo8Ly3crsZsGr33BXannBlVXgZsW9LUEC8HITe0ha9M0As0yoW1QcNy3wIfUKqpRcMZLC6lWoExj
k4TfZnnmoSIB2q2/2wFENWYTB20yhVsefmCiNgodQLRX7tTebEvPM5fQgGmgaTGqjZUSwpV+VQzA
NLXeQ9uYXzCY9pb2dytkNq7Z8w6gTV6S6G6C/wAS+aFlUl5O206lWoOcZtWcE4gaMQLdrIQSrD6K
7izzpixIQh9zEOxcqhV/fVywxwb5yIvNPriKBpWCVftSKHcRie31AK4O5zC4q6YqjkNkUKI8Q3i1
Q4yIpCCLl9y2GVAhIrBXesCcss5qoUce40tKZEWqgmm+Zjq6avtaloA0Iu/nJi8shh92Qsuv1AWb
hn5XqCWe1qCQ/BCWlppb5DuXU+4NbLzkriom0LXTCEBevM4ryC1IQRLgcHexydeGi/M3pq6Oe5nB
pTXEYcgKlYuF1lV5GgHVTiKFvZqB44giVaKvqNdicogmjVy6Dt5FhWTXZekbzPIKpQUqAoWJgDAu
EuEcogeVFR/YDvxOq7NROv4lFAXKAAiL2WAV89xKChdeTuBdXRUQddDVv3ICoy0IB0rgWyp8jWyZ
Ic6DhEGpYZ/MTCgMSUFhZX8So4cGdqihZQyk4oslbdNL+lhdnqjH4jWAQDbl3twu2HH3GyFqV+e5
7kFwF/qZ3Zzn+oaAu32nRAQMl7G+oEWApWed9w2TRvSikaUq5e29itUvwxLbLw1MUwp6gK4veIRY
34AJfVRFl0XLYi9mj8RYOGUhS1taodoAuOJQ9+4DeEB0eJZrNnLIgQA5HfqIur3nqYpVuv2/2BL+
3uEIB2SGrwG2A0KNRbRfmChtNdi2ILsBFpVnLcW2YHMFQaV6xKi0peU1i/MWVpWzwjZzZ3BbKxe+
o1WYVhHdS3kuFRdWcMrXpLAIsNnCCp31LDXnj5ih5XBULa2R7Foz3LqiGFKgrWLB7K5yU0LDssXf
HEWotZxUOPMAq8wvQ1EW+TuDRQ/EwvyyBCOeJUaLvMNN3u1UtQ8o4lAGt6+Y3svsRs9h1KA39pTr
nxFB2XxG2EhnMwY21tUSh2AbRzCwBVzctUFrGC7CGCIYQFG8eosDaY2ctbtjYrFGUKQPh7iXt8XK
EeYTRytxqLZwXA3dq5vqFGtHuF0KGFoRd/qWKUTqJYzWFFD3WxGXBnEGl8Sj234gNBbeou8VcR6I
5VyggLPMIlWSiaweIaN0TuAFInCKtJhVPULYK8RFkVdxWujgkKqOPct+R6lEWHES2uL/AFKG8mhl
3fRz6l3FquXzGig8Ca3OVwHdC2URUF+iGhSr5WVIOOS75Rn5ZGi6vcCi1MRbvMWwYuoCKl1uylo3
q+oMNfctXZjaDSSy7RqODenEEXaquGh3oY6mc9QV4U8sKLSicTDlrV1EIKsHmCFN3ucS/TIkunqJ
NDVDHLTU2Ah6uIz4LpLqY8V8QoxVfHmLXZlTLGnORMFX3cuJ6Slh7WIFSqsuHyKeiCDaUxggAUvO
wcYPO+pcsC49w0QNeQgyunFmHmACIck/ocCZnPG5bC7XMIYBFzn31EZnYPR2VohQguepUlalPuLY
6AqfqAlqQNvUDci9kBouPcJ0cKpYwAPggtkAF8yihIFphLVjVp8wCFcB5S1LWXSh1WRhAlqqhnaW
Eu88SqWzLo/HMa2AZ87KM5OV0+52RsQNN1tSny1z8RbWLYL9RLMOyQ2YOGD8RWRaHZkyX68wVbU3
fmo9AGEKEUMG7FW8wUWNQm4No4Wy44tUsN4JR7HXanUXrRkBN6gIu87pmFob/PMO11le4kZYw4is
89vaXRV1cywRupdjXnZkKbwS4Ipw4+YPHpxfMQIAEqXUitCUYZdq4p4NrsyGktWvqphFi61BYouL
yQTVLPJEQm3x1UHjmHSULqBoBE5KCOq7nM6rX6tqGjKm/ETLwBcRFQH9QuANR5piCvc8dy22dp/E
DeDhSPdQ+SKRzD+fiI4odTeJRX2MZLtCbL0Lzdwob2sFxmLYNpX8x5AQ4/cr1to+NlhFAc8+otJr
SMNa239S3sHL9xx4q1v4hAsjcXKlF9DIrjbMdlQiZzy+7grGCOt6iMSN3g7muCoLreEjXBKF7dkd
rGrB33RDwgXpRUBSAtntCSUXYK18+IoZxnGvU3IcgRvaqtTsI5xQ8OQKaGCj2Yv8Eoo7j8RiFfSN
iGdVHpUhJxeIRLN0ZQRJDt4I5UYyJdsXuLCuGe5UDYeGWFWW4nFq7VdcTYpK4qIuFF8QJA3mkRwU
oIPBXEZQ6vtglUxyUot5JY9V7hLhw4ZbbdCfibpZXHmYB0PEb4x4lKy8ygXd1twHRvxKDg34iFSB
TlEKEBfED0roqYlHwTiGMVt3yp7nnnF4Sg9xdV1NFbG8lrLlFNQm2Up9sowp5JYJdGF8RUVKeYHR
wYqOjxDdU/KaQa5UagTDifkdzA5itgB6PqKSIuvMFFFGI6m1aBdrnhYRjY6qE1o3eQoa7wVKrIgs
A/cQStLqiIL78IKqr2aCr2O1SuGUov8AUuCtHuAocnNzoIL241ABpWxo5GxYAQ7fMNc1eiSpX6lx
lvUVUsRoaW7q4FHP2yjZaruVNNCcVCniWpZQ7iLDQIBVE9NQhVlS6bR8eYWOjFQvA7jbS+3xGrfN
jE08BzKuF33PDRTgjQK1MA58Td21e40a2t2BRDXKmkp93EaXsV1cVwxKHULIbdrtjCOHZA7L4IE4
zzAuHHHYUL58xorygqsqYi/mbR1dwURT5J4ocRe1jxLaSoWY1d9w+1vd9Qql7WjxBEnBER4dIbbp
lxA7Y8RjRy6lHKC+Waa1+IktYsDdNqdQAXe+uo8TbauFasB5qCpvfHqVa2XeS6cpdSAFLlZf/iWB
DZl6LK8MqzRtw4VhbSKostz4gkeqhLupdS9UUG+JUFmo8rzErNF16mG9CUB659wBY4bLFoZspS1c
GIEUW8+ogOHEaBf2hfNBiR0R74l9KXC/ewBzqU62ilAP9jYNV7Gf7PMRMBQm33KmzMAcSqGQ8o39
nHnDgZAV5+IY8FDeQKuk8/qcfctgpo+Da6lUEtDQglLXeWJdmyOHBKiMN1Qum0vt1FJKCHlfmG4X
mm+2B0SGuVOykUn/AGLRxzGnzBWyZkVcbraGnCacHvFuUTLdcENVfkRhvA7qUf626s9QOUAbO5PG
hgHfiHJkWjr49R6WAHFgun7BpjDmdiDHLpZgmG2sDd+iF/kWuuQC6yjeuxq/hAYC1yB1AOwFceYf
FABRK6lUC8eIlFeehijQMwfPMV3zV1cMcBLurlpwLQMvDZnNx/I2OPmMYqmvXEKhSwW1KhwJd3cb
kC6L9RVc1DZjfk6qwr13Eig3kq4O08oAmeZeWgCfhs5LoptF+YANu/aPGhvgxAi7bV+0HsbBPrYS
8CgPRMLhKcN8xgyWAmmu5wcipC+YYtsvLWpTgzaVdeI2qb7Rify525hFQ0kGCB09cgbYuHA4/MMD
evImUSHw+UszBiVYoIdADecQOwLdtjNwFt1eRFDG7peZAqbC112Tan23pkrWuXhztzQctJQQISqc
d/iIs+JLcvPUu9q0cz01cFeNuts6HOm1KgcyQBX5yV8MRA7vf3C6ix1hvqBseW1JbCdKAVxe+Lm5
JoVeeL5lnZbtWXwkNyvi+4nrnusVWQvAsOmGzIYgHh9QcSaU2y5bKfPlv4hURvLM9xWfzA/3N0E3
glJEtN9fHOy4hd+IMRfuEgaUu4AukmbXDVMDFeDZE2dajAQfOShAK8ogtBx6hEvHmGWWNPMYnbv9
Q7W3ixDTWc5BAumEeoAwvqAdKPiCG2OXBm0yKxtrBiDRR+mVyte4dO7KFy2TnCkyoDzbVeI2Uiin
IOGoLSS90OvEGbqcwGpw+v8A8iyMctspDhTmI51xKKjvcQQ6HL3HigbyoeSou18QzeA2/MukeUAl
88oiVvEoos+UUFRuKq4PHiBEVs44gWzSB4OxnBG3rTx1K3PPUOx/ycirGKkpabBuxv0nrxECqy6I
g9Eeom7Gt4IC7Sc3LjYfEV3wtSGcJOwWHU4i6O/ULdNuAum9kTRuvcFFr4JBgspC1mkNRHgrYdgW
YMUKB4KjcBd5cAhZEwLCDarTfTMIKLfMVqzw8zAIqo5zDtgF5FeSUWhzyTKXdeYEa18QQMcxqNq7
p5FjwvnmLCeSysst6gtpaeBlys6g0ejlwEI8s6hVvEJfJu9xAoF1A1vklhRcvLNzx3DDkt0ysQ1L
Sl1Nigc8cwzgp1Ki7gFDwMiG9tYAHBigXkTuJ3GrASnsguDhgVtxk0cLrxEil2sJNFqIDQBzN4Ac
ywWmOpc2N8sbcQqozfUOIHsD9x7IJzLD1zzLAUB4hKF1fD5ls5psLRr8Tsuk3Yup7tuASlHioiuK
9SzW16gspacXNCu0htiZHT9JonSYQU95PpEmD7lo0OmAuR4eItKldaivVlrELejfEBjQBHRLqBY9
EYqu5UuhVPuFpfNxgpbY8kRwsuNQbWOGQZRQar2AXa8QsDWiNfUJPOTSpr+cC4qMzscROnvBRU2A
XW/mOKBzZZXwtXB/EOFrjpAN0eLFv8Q7xNjzF0FkoHBhW8IdxN5XhMSKFHy2rZRaKPN7HZsvCi2A
CR4KRAXPIODoOJwzAojtoZHQAHkX+xBaL8rRKQ4NkMq6RfJfiAhvJlUpSi93yVOh7FMtFUeWzQWe
REo952vIqoj2qWLfjTBGgewVMSA3Z5dxarccFTmD5S2TvmLFR4NMrhm4KSeeghMi+5ZfseeT6Ye4
G2mEWU6G3EzpthCo5AdHqMuZm+bGeIHtaazngYQnLTkzJqgYslCCHNIjdS97jOyj1Le+9wfiOCh6
lhfxLXh6WHiBPgT/ALLstOqMShYVyx1Uea8UofiDS0eyJ0P7GQtHd7MUcUftDQ3eVJ+GX7BwXqFX
PyvceCwWWI9BQEuv0xVCHwuWNJysn5yIHK6+f1ktKg8gg/DMtHwp39zQFbKMjvJ3yyFfaHkdP3Du
LptZDAewuRoDsEBvU4RclcWDcD5wd6TADXFzrkFBvEPAtdJDqDhNcRFhXxVQFarhudlH5jhnw5iY
IBz4YOhe+8i4Dip1LUumLwU9wLdN8RIGnPMdgh4YSAhviqgBqGVUF1acHT8w6gE9ESuOZZia4igY
O6RBqA4uG40EujkKgIPfFTngXTfzFFq6eKgAdXchldJxGgGDdxKcrr2+4M54gqoj6iN3S/U3Ut6R
oTp3XUoqZZdxiAoGnmEXn45ioHPdS8Rw5jzDXid1h4pmWK65g3PMA3XfjzFiksvhjcUKrKiqHiLO
CtkVRyi5SjG4TaqABzTU7SdjCghK6mA0VhHqWsgk3zdoxWatwVDpwTFNHyeJtLDygLFvbUDnMZOI
UYHoFeI1lQdi47ERxUwN6dzSTt6ZVTg4iQEA8xWIHBxNVtN5KYZfbCA5fBKK0WyoxSy3NXVVRSi1
3ULl0uMwqmJAfkRkJ5/UYv4R09hNKyJPFTt0RCUInIR4sPKUw2rkJxMq+4tuykSbePBEWFqXgjBT
Y5YWVXHiVP8AlhYq1ushpK8oDA2XiWXTl6hfNpICppVyy6X8TUqLoG26Rhbi81mgVQ4iQxX3NdBY
uWXqnqW7gdVLAMsolbl8EFDu9EUIu9t6lB4gVKVeLYINe0sJY+DmIl1tGFSoPGykmChQtPJLygWc
yX9SjxADaE9wglbwmCZcttNib1XqLZaTpNqsOGUhBrYAwcQdwo9ShKKId8RIl23mNgiVVswG/qbI
t8RE2p8eotCLW1UNiBWLWsB9KhdDkEulm4DbuWg54KmIRfNQuVw2AitX5IKbW9QUoZXMupiBUCzi
+Kl2UrRt/wD4iwLVdZDHolpKKLR2VUYwtE+XzAAE64hNUcgu6OWcE42wPFcxi+hc7Sq6YbQbXPUV
wuqtFy+3RYFO4ohjSDI3cDgb9ypaAsHviF3FyVWRNrgBVFfTdrIT8yCUa3eJZDkSt8eoZI1Pi4qh
Srq404wTLLnXstdh7iAT6Dicgr4jKch1LA4IQTB0bcBtO2JBwt7QsF1eIcG/mkV+RhDFqNBOZh7F
qQIrjumxgQIdkCCwcwVIQqg5iJk+IWIQakPxvQi8VV+mKM06IOBvgSAYj7CBXV8iVrGdIu7qXhD4
R+2RzWEaKA8VKoJ9Jkoj5/lNeJwihmOEgFY42J+oGAm1VorLB3UpKtoBksRDiq7hgxgOoarGIJYS
qBu+7i9uuhH4Vn5hYi3FI/Ql1MEUtHGkWYG2JSgVguZfgApIOc98IC5SgLXC+Y98J9Ocmwm15p+o
eF91WVKjh6hcwMWPiXFKO0wj4HdSBcugGuE5jsGnkXFCAv7RZEZuuUN391blfJdJHGz9xVLVeAsP
iHNKjAY+Q7jbKtVp3C+qPFxZG8qtAk7wwai0+OGH4icAEDZWV+dKlissETA61OK2KB8gtLIJ4W2W
QSm9kLJV7vuNE5jDUHh+nEZYBD4ICIsAmxUrSu1cs74aQ3XzBKuq2nECpRd8VHLLYbcAPFFoIaAO
lwuHwgNX4nhklopl/Sspj8ysM10V+JUCFWbz5uLrwKoXLj1oGpF1oF3xNDI9xhB26KCMivaqH3Ko
ovA5eKh7Ui74b6YwGWUKq+YCvbg7PUvrnoqj8MoMyoi3GJUHgEfCZif5I6aFJcj8RIJm04RSq7Tk
PNwoDAu1GAXSVKgz7Dyh8zIeqOd8Iddnrs8T5PlGVDp6crGhwxUYl1uiVgF8yHRGkabTCNLL9dYv
7/XFRRZUmm5UIMEaxik+LRLQGHLqYC1XvqWQlOlNkSNDnIUS0tH+fUsLVZ2DQU/MUkUUY5rTxBRG
9cIr1QVyQaC2pKgK03IlN7fHmAd166lAR+pwu7e5ROnrIWOQ7eYYNfBiNj8QwKeFUcRXjrdbG7Vs
yIi84lAGja9RcCGbZAel+iOWrac8Sit0psEAC25iDwX0QOlEcyJYZDShp4+YaA4eOZRNZ+4q0KPM
C0l3DgF9vqLYh06nJFdZQqbWEPU58SyCvZiAUE2MUld3EEG/RKDS2DNb7X4jYBfxALgpzHuNOJVv
db1K2CJULdc+4uxvunUE0lvrqHEB+ZSD4GQ4BmrsX74gVBeWQC4WeIhViii2WyX1dIVA0+IWEp1U
7qAdRFX8SJE5ilwqxXiU0CncgSyQrCt89S3Jol0F/KCG6fxFnD1FSl35gAt04gLyOUZagtnZCoK7
iFS41AuduB2WGxnaWYkLBTkUEBt7JSxs8LmAV2YRTwddyzl4jUAWUAjfcKliO4KbHhphKaeInTKY
LETh6hVr+JfMp/qYgVyKKW2c+ZYAOO/ERo5T5v4jUAOmxlS6KXxKoFqwFGHcOQht7KyAKYuQKFq1
sUAaeYpUtXIzYU/UqvWmzzDinm5YiVDZwwjZU38IW1LTZxmyC3ZCqB0goYVHwi7VNtyvtkq5DYJT
6m8UoD1Dh2xaUCaXhxBMamy1GWirhhof+McTI+5+JlG7BqCA5CPoMCpfpGOFWJt528UFTukukrg1
LjzxqrY3FRVuZYJ9bGXGyHSoLghso2J/EHddWNBddK3C42tuy0t+pToNauBKZhMW4VhDdgZDxxFj
IMDYgFs7SVaFxVQuADtS8cFMahmKVy0H7lEbWFafqXq21cxCYuBdB97EU0UIow5Q2faD654DmUzf
yLFpJVJZzMX1wFVLUjug/wASw97XBIiKxlw+4XrXoPxAZD8mVYl5uXv1EV2cH8XCylfVkpQChfBc
PXzhZcfIKwblLoENcT4gNOwCA+5ddzQHPMb4Gg531KfTsALHjzYBZ/UeAtaPJ8QtRheAfmJrVL1+
Ag0rkAC/qWeESxVM5BGC7PqEAzHD4QX3C5ggpRytSHwSyNCMF+WLQLnXV9S/rUBhrysCyhwAhfP/
ACAAyHOojGVprfUXOVwqfuHLkCSXLOagPqNJzWGz8nErQgKBQnqIDU4xPll3SAaH6CXqbUFafOS8
YwA7931DMXsL+ob9PkKvVxt6tUpS47xwxg9NTTmw8vUIR70cIxNfgU35yJw3brJft2IbKrwd5hzT
S3J2xlquBx8v+QYg9JQK7YS8dJx6ogoDoSP7iS6tC/CiNr1dR7LUeFotzTAtRtBbHJ4iEadtfiDS
Lo6ZfTBm2+gIQc2MDvEua4QXqnERnZUkXUa36VA57Z3x8N7WKcHDQdyov4Gh5uWDZbeukJmuRA+1
gA09RV8lswwt5lOqgWxsSIfxF9pFbjj99zBECSthtRq4/wBhCUq+Mkq1Zw8a9vb/AB6g4FlNH0cV
Lf8ANO0mhXFZB2lAAAHgB7iHUIwlYP3sy/WGB6riIbwm7c+5zKdC7Vq9ywgojg+aP7lGaWAXzD84
VSvg9R4ooCPVBvgl4d9WtB7r5h5ji0D75nMaMlU5+Y8pFgV9/Usfauhb+mb8gTV8mXasO9t9cZKW
vCj+YgNs6heepcSODb+YjwPNBsWVLLyBMHt5g818SsgL26/UOFGQYC5mbOSruFTDnYEiyuXzCc9i
XkyOB7jkHoEP5iAAu38RogbqCy1pAGtbd1Bbhty1Faol6a9CApa1/MqHg69xuW0p1AKtmLI2Slug
r9zSVXk5mWGxdO5aim3cXKr4mmr8rDRy+pTzC5UpLS3qEMC/ASza7p4myhVDkUiuepo1R0QHXTxU
wLadEpXo22AHO9zToVyU5izlJUKs1tR2juXVbA3EBACwCCtu6m2VXjIkmrUVBBRYxaDR9TQWa8Ql
jZe1GraC6lgVlPuFtaeo75HKQUKjZfMyjlfuAKpXuVs7ghRv5it2Pg9QKGbjUbBRvp5gUWN3zKZH
RzLCJXRYCU3yhdRKLxUAwRfjqVNnU5JXogI2LrmCgg5XFcivOy4Nm+pRimONR8RqyXRV1nEHKtzE
Au14gtaBFoM0IpNvEBa1y5OogvY91HQur6iu7iCLaAeGeoPFRGgfQ4js3EtXXgVE0BsMKg0G08EW
qLFMPEvt+pWWEr2YWts5JwAnwiL4iqKiaxfdQhUKnM6HJzAQU3fD17mIbXVzRYfCJRRe6bndx0Nl
crGWlhz4fcspKdV1GSOjRzHsttIvWxXBAc+oCpzzCwHgPQMSm8A+pfD2u/Uqwjd2iiqE26qbOulW
EcqqjOHGW+o9KhKAC1/mG28uU7lx6lTD5auy9hNVBbiPrIxYjhb/AMih6Y5F59XBTcVUUxeIsKjo
L/uZ1WGnmKqHtPmG4AYjhvwW79y67gRQaR1pI63TU5UUgcFdVHxw4DcSSmynK8yvh1RFxAFoHGn4
gsMdKE7nT0qTVe4jEdWVUQyr8uxcPEJjFRUwdQ2QzQsrRqAKtYGhCxgpEUfMlsdilVkt9Stfta/L
1HgsuAH+ILVpcAe4/tWr+PxCvoEL/MOUX4j/APORgSrwwEv5g2hYisIeOKhb2+ILqhoP2XB1s0Xf
3xC+yGov3FwYYGUV7hFcGw1+pVSgQ5S2tlg6+9iAX4UV/UVefnIWXb4Fkt+4ccKDtlUkLYwfMZhD
WE+kE5jxn9xuQRawPuIuJ7ge4EozER+2GLMbMX1FNBzNXG3cmQemypkLVuyJ6bQWbta6l47gVAfc
CpygC/UEX/Vqz8QwVX/acR8ieSKfNTqN1hfAB3LRTLFY+5Qnl4q2+I23QbJAQ5fWfewF0sIv6gC0
F1yZG+t6W0G/NE4pu2QvxsKvtdRgBQFjRe2oDQ91gPuKh4R/MIRVVQW6tyG/ZMIUE2IUfiJYKohL
11GT9w68RsTba/0IDI1gWfjIki1WgPPxGRv6BfXMBuRs2V8sQtOgB9wC2uglviGrdosfMfluI5vN
3DI1gL9sqmPlsfiO2ahpoPbsAiGLEfmEooK1UIhYnXp3yS+6JKvbf+zAmbgs91C6qidW/RZGd0LC
rJxywIpVQfgoiyWLEo56gdoai2g861Cwa476EECtVcUF2xhSnV5usLYOOoEIb8VKjqiN4WGRPM2B
X2FwS2xIPmtlipDkVxyRqaUEGvPP9Ql8qgDzuChd8JhbssmxdxKyREgo86x4Ts3p+fuO8gY6U6gz
LADzxU7LSJWYw2n6/c0gV6Q8+MlFrQXUXpIzE5wXHLcw5kigL9fLAqll78RXLSSwpq/EOeIae5ZX
V22t7NqLF8EZnT4hWpy/UbOnYdwUFtSwhfiYRUdkRRseI2oN3uEuS27haK3vHEGzbBlR1wHagKiK
hjBfmC3duyDI4OsOJ9wCrdf1FFDvGJYrQYs12zrV3ikpy2PUBdhXzHhS2CzVrqIxw9EUouiKQXfc
KdNX34gMbD3EravBKtNM5YgCj48xClST0bFQ0l9RRehWqdSoBuAra7d3UC78F/mIPKeJVTuAtoeX
iDeOnEoHJdaRjgKaqKej0YMgsOHuoFnC8wDTWlz0RFEoJxKVyHUV0OuIRhR3YFm4cQ5SvmAy0hlG
/lI406iK1ntA3Axv1MLwXLG8ExB46ipXp3Elkae6hDjnljAGZLEIZT8MjkMO4OCXXIYJ2ZKUCEVd
Q2lL9hEtRzCGJusqgUr4ld2TKde4pnQlhhD1OJumu4HyuoCVrxcYC6pm15OKIWE28EKjwyi3kqoQ
A0AhtvBovECl3a+OJbYabySjNpqK1T1FlG8QisW+4QLqsZTx+4yDkdxnaWHPR3HRRdG3LHgvWMQt
Fc8xKCucYAkp2YVlRcOTwllG1OXqA5nuvmUC63LnA4VvR+ZwzWwV+JVcNFnn3HOoRQ2CwOZciyPH
GexEPkAidyz1ClE8Q07t0lIWbQmTwhiGhJTAhLvki+FhKGzED1BdN/qVJAfAKjSGgPMZrdviI48/
3GFPZa2Majwf1MQBzVUL3EhtFNCrzbHrbcyX8xZm85x1QSikSkYnvZmU1u/snVFIj+YJUqsx9XGb
goFT8w0BlYlfMJsLszX1cLmLKB+SH3GgTX27GxJ02wfzAhtoFn3cb/OQfI3cCZYrr/pABawFX3yz
OVwKH1s51KDGHaV3BX3LOHuAHzFbu2hoHgj6Yd6B6I1wKw6HslUg7Uzah3gd9ZBJh/6Zra52KQTc
rA8cy8a6cHPcecTb3+YmoquI5u5XrFiNvu1ima33WfdxEJXXKQM9jyGuO7lz+ozfq6gwmNtCeCmL
MbSF/wAs32doV8ruHccKVNeInTcCx/ccgGwV/cXwwWV+dmrfdBvpL6hMgEClNmNolhefc0LIFklv
4NRUCj4rG287HeIoLH26lHFs5vksbJ40HLw9Qwa0FuvU1Qceb5G47DQG1LzBrhV5+Y/oVbb9y5uO
1K+eoMoQdA+iCb0rpX1E2VTxGIXF9AuVaBEJM3fX5hoSIqYjgKDQvW1zLLxAyum0MW5xLv54H2vq
P6i+BqdafDY+agjm2oLXzDi/F1/EQ5alX+muXxeghs+YEQCln9EXUjVDX3LuMvpQbBKgDJO4OFRQ
vWOK/FwX/WjhMUdBWKq/U0boYHl9w+EpAKHnzK1F9Cl+fMUKN2B8e5czBYFhxQ1cNUUr8j14gvSE
1I8ZLbO+dp52WcRdtFu+7jUyFh0XfUupmCpYVfuBRe3yPVw0dC0CCVRtus11ieIQlFConVSpR4Xd
HnJaUSpUV5ziMMdgaLvmiHbdGci5f4h1AXb83BDRKauieKXuFskBGz3cHowhJ4+I/KgtcHhEPF0t
Xe1x3BKAo4m+qiN69BPF38R8u1fybUziipP/ACoBHO0hXjZo6JHD1OJ+MacOWPLF76zzKEY8bfUb
9pRYJT8xSAdFtc6v1BPZt0PmYwUoteccR7Q24H7VFTGUHB4fqGFJW1FT3AIN0oDecR7+7bSOO+aj
Zc88zuXDo7ruJZ2OnmBaWaeevccV2rB6Z8D7qHJVK9TVK04gNWXhGy7tenUCDvpiLul+ktQnGNSc
+YVS14EaAC3YuyxoH6VBpVCXTLZYmeoXdE7g6t3jJYAav6gALncpN7KqBY56lPGTxDHou5oEF+It
bYIyAa4eIXRo2cTAoVdEp0jvMV1PJEaXf7iKBaX7iN8kVGAeDLr8nB3Fo0B46iXcn1D7HTFUWrJa
hXNysW9TOEILGz9EWjQLllpkqb5KqqyGa4PURaWq2yCKP65iiafYIRS8uCCpzXFRSO92xtX08TXw
XmCwLRljWMXbo8TuXb6jbwKbVRYGX1UrFN7KI6D7gawRx3OBfdEAu8sj3VnqG2aZRLilX74irCN4
Y6i54hWBq42R+yAKL/MSlGrmo0HZBYuqeY0OIfuLInB62Kx+J3DRVt1HQj6qEhx2IC6s5GUUKfek
JLYb2KLKW7ECG6LrxFF0vuYr7e4tVwcHmAG+zSWtr6am447MGTAdMBBo5mgFRieYAs0epollXcoh
Ss5YKKipxBp4BzDS9QEaGGdpKeCVFStcVBLP0IuQD3BBNT3AXcA2u4mE4c1A15NXDTOmy6L+oEQI
4ryyxTg4OIC7zmoEAWXCBwbMhKRTF/7RxdXxCT5O5cx+PMpXkr3YgfQxQln5WNgXOHMQoEoeTEuB
fmVonexERe8Oqi6/NE+EbSj/AORKQNE7ilbSm3BbQvExGIPLXOQi1vqK0tXTKBYPewkbs3KSvuor
CA5V1Gi3Elkb9cyyIWd4LIjnfLMJT35hoKngiPaSkl31CqEc8JsYoss6yJcm3DByQ1GiNHdSxDZ0
bgaKeHuVaSns6iN0Omo+kOiUDQnmVpXW73AThV6yWTCe2CQNrynM5LT1Alw8TWxiDlfBxFCMepYV
XMABt8wBVekQlQJzcGHA8x1UqOPiCWv8y5BUe5dbLhCkCsZr4Svvh08zNB8jqUu9+rhxlXqI3e8q
glFzq4URoOAVHUxfiv3BPJ6lq7TsZbURrqK3fMfDRzfEt0WjjZ4IDGBBPsl1SldkWhWRi3F04phH
mdRRRj5YuJb0x0XvioJi3svbehyHwuOQjUVD0dzgLpj3H5goCB6HH3FhpA7KiYcTyZBctAveYNVX
3MYGh6hPdUnEWpai/GLyVXYA05f7gWAu745JYiL4iQQ2KqUtqKVMdtQFC8uccd5YBbsHzEsCVxUU
WqLq15hGpHnLaMvVgBXoSwCvoFwLp4qaNW2uf3LcQNXpssi3NT2SpW9eNij1G+YtFBOb5ibg8Nmw
Cixwb4iEHXCOYku3gO8RVQbWvUuuEOIcxiRVN3HANWee5xxMdCWNNvDFMzjkOog9mtAmCx6l9N41
li1YNYBFwpqCMerr1BCEp6e0obo1eEHTRbIlYg4iRoCI7KiVdHz3Ag8vhHjqJVosc1zCzf6iVH8S
6qLTLFZw1H4reiGQ+k3rgy9qHvB4NfNRsN3ceM9BEXSG5AXCh8SzbeOeiW0Qj6lkPN9IFlWmcRgC
Pe5LilHmHAOe2IpVp8VLKhfuOoYD0+Y3SWDqLfr56nmAuRETpLE1Fc9ReiB5mWt6qLVyngZQ2/IR
RY0OYWbA4CIUOFtuCcoPCJRu14ItwBXNRUTAdzCtHggI3j0zmXe8eYHrzdTEYOyC9LbxONG9Fs4J
StAnqIBp1xMlb0rmYR98wQ+OdiJShWly6Rzwx7TfviKIA+yA5G3MWSxK4gWcBd+Io10XLRFb9yx0
PiaPQy5UUFxCTpnAJrk8QKK1diQI65i0FcLOY0KVeMXFBCB4PmYyWncFtWnqo0iI3pVkFSi3zCnF
J7leYawB8i2oyFh2jzCs2ggN/EDftHUtberimKa8uDxLJX6nPEBSy61TKOuR+5SnZ0sVKcniFgv7
TIcFaTDW3uUmx2czUEsu0o5XAAFq8ZKGl4YKlueKhtXz42KQ/wARUuL6T2fqAvQF6+EwQ05vFwL2
OTxGjRZZjVu8sfidQFG/COz7/UXeUauIYHmLnAYT5EzK2o7605MjxUF5D6lLocPLNo5wJTF7BVEs
kjo6Qg15Lo2S0snpHPSIoZ0oTi9j0DwCVUBghexw1CFKm7wojMOiqHa2ICBi6TtAdRuELa8xmNfE
vjn4lqOltYAcadHMxx3FVHCA7DCoWBu/jmEtwOzmImZepaVm8nmUFtcwHgdSpoE67xUA1UD6BVwG
lN5IHk4iNpbq5Y+hpCledpI66HiLZS7GIWs6hUDjplHNCULpXcl4PPGwp0BcWgNMFeTykVdj4iAW
16lOoeo072c0gLo+RNiht+JYcUsIzadXAomKiFpYTqanUN5Yup6SzEQNKeMmwsrbjwOnLBbUh5oQ
Ry19QovfomvhrnqAzY25HLfJDKrFgVHXNxw1wjGF/MZNHxEOOvidFHy+INnUvx1Cn8zECKuECBbL
ctZ269oIkrnlhNUtdNRUVjtYjavAP7lE4rtOIqnXj5lCi6/mJ17lS8XackZeCMuindDBV7qzvqDS
0r1NBs8VFDhOYjbbpgrLTyncQKSHNvcRKNbtrGLalL6JqYPLwg1auG1B5FOXFqLw5iZdB+2GoHLE
Ss6cMCYYNI5NDxsWvBRcoDZ5E2/EC6IcbEiloFUfzKIy2qFPs1ApnklOVDattI1XMFQ0++o9CB4i
jy/KbkBLq4rwrXzHSvGO6goKiRdNZUYzBG12gQaV2RBWLCox2ujvu4KdKPJFSLzJq35Vdx5BDxCS
anTMtPYvcuLDmrC70LqvMSXHek154LiNNNcQJh64ggXDk6mA3jLJRrDu4goUK31LbW5ewhrt1LgS
77OY+CvRXcUHgqXUJ4Yyhi1qE21PqUY2tvqAcr2cN83x1LrbVQI4LpuOvET4HvuITVK8eIxO45gV
W+5Rga+Y1pXssws/iCgWe4g4cQtQ1tD6lgvrmoysc/iPNXEQXPBHV9sxkw9X3OMoH1KWqj1CQWs5
RxzUI9j7gWVULQeXiXW7rz4gNLYFLWh4lS7fohgtj2zGaXuupYKwK5mAH3CzcNtlEOvU2dQAjSk0
loxS+JUKNIBQ0w5tgcVHnGkU6WvUraLIhWQPMwJs7yNZFPxFUIY9wIBypdsNBy8+I3cqupZqbwQ7
pEXsnkD2xONd1nkOG47DXY1KLvTxARB9XUElt6S0rspiKWD2BEgBBdeDiIn8KmIcO4uNpFAdb3AU
ub5gBdKOIwW75Sy0K+CJjnXMJJYT3HUJK8RqCq9y4WntH0qcuS9yrzApuk0EoBofcut0lZHRLp5l
NAXMlFjVa4nNcTmDT1GlA2PXEUASQwB58S7Gi5kGDDj3PC98MeCqtuIWroBSU8zRO8HxNq2dBlqI
2orY0DiUV5/cfn4QqEBruU5ijj6hZXs2IFL6CWluiozl7rhm9Abfc7uZPNVEhhhzx4hWbTAv4l9B
EOY0FsA7lKBCvMfMvBVGmtg/dG0s/wBwtFi/MoIKU5zKkCK3Vsp0NL+5TTLX2d1AMcAa3DT1F7JD
SVDkdCYENjHeoL17hAus8Jep8AS2xUY2RKX88RlY9Jcqy8EEEYX4ja+D2zYGHZwwDTz+DE1PMAUL
bxOeuoGgM3h+Wci74ScBF9niUFbk/MBE14e4c3k4lY4YWEEeCOCAchLUDfctZuo8CW+YWnvuAVl1
ysawcPBFXl7itbFmtBfEp2NsJDQm7ASOBLf6RihUVacI206chwxAlFxAUCfyIIlV5lSCJdY8y+d1
h4JZ0p8OIHtH5lqi3y6lRKYNrbGLmSwuu2UgCCB5RvJZkU7SWzZ9dy4XDtxG4HmUdawdqxSt9FVA
vVXtU5HKx5Yq+KjiXsWLcXdsG5cmggxU65MGPiFVV85L2xT45ikKr5fUu7t58zQWx58QZ9FwG9v4
Qeijw1D0bffmJbYh4uMmKOHqN9Lbnl0Oc5lyUOFzVYQ8RobvxcQKDp6j4vyVOVglWtcRdJOrrk8Q
J5EyNo3V+pZBgl0n7mYD0tMVXB8PmCnS2FllbHUsWTlQN04ROhz1KFourg3QvuiU2cO1NOtTuuJZ
BHWJSWrt4IkbvQdxyUoq+w+Jgqrv36gy3mHzKI9BwdxTgpfzFZN7yxbU57I2sLV/KW1VWcP8y16I
4CuIIiy8NRhvaLVkyBRAtR0eYDYrlfEyVuqIYKQY7TdHPEodrXGpaAYZkAktGxX6esnAN+SIQsUK
o3hqJSs1xC5YDtJyJw11OxasuFUnXcru+PMKS9zlDmWtFvSRVNCrtHEDM7pgxT275qUFbMe5nVU9
3G10O2LwEbMjvOBtwbAkFxB8eYSrjhJtEcKzuUC9lQCgXmaS8+Y10QE2rU9MphkoQp/SYAiLrAhu
mljtxecSiFzmUba3z4iCCWtthB5pis578QShy4uNNsIuz3LqUauXFbaogcFdSzSUbdVcYNW0ydZb
we475WeeJhVhP3BKs26JQJu2wb6PcWz32RghaRv8AYgBGBUTZL/gibFKOImgBTxUQG0HUFKFXhAH
iN8TFuvbGSJbh6iuHK+IHrW+o9L8ZG7BLITyuO2r+CWXNHxGvC+4WYJVZNFC97giYo9k0zX9RWTG
bDxV9Ez3JweYoBcHEIohgZXbOTfg7iiL9iYeDkpDdVK2Nj4WAQ5eicl/MsUnxkpt5OxJqwLnBEpQ
XhuUObeiAF78OoAYtqLtSuqi8HLMIROXFVScGFRQJqx6uEw4Vr0sFhpoTghTYLureJ/6Eo0XW76j
YHC4K4iSGLyjiAUjRijmbCbWVLVa+YRoqseYWwTsCNlBxLFC3Q1KXmmEKgaU4BCb52Hcadp49wAW
60efMQKVzQ2KKqflUSYqKJYKsG+mCBgs+CGB6EImzKigLgxkRU7yYtU6rwwb83XMBLPCtgIcsq/U
SVAU9QBk49MR9Hc4AqHqWKkemSilDzK1YPZG2WGLhfJhZY2cQ9pvkkuPNnFTnbF3csGSxtgyyV2v
+y5m1UKC2KuMS1p+5cBS9U5iqEo7ZcF3XqOqueIqsc4ghLU8MwsVvUYxuljCAB1idy6ovBcvlwqr
nIrkVQU+WNCDRqiN+rqYdW3vxEPAMXA8+YSqsOZ0bolCrsqXHepo3jElTVoIAaF9cwF1g8wChTyj
i7TiNrUtqF1xTGptG0OlCvK5ta01Asir7hqrX0kTnbdRooK7XBZy8IhySJYNPmAVYQPDj3C4LrWU
Gtb88QHvjJktvUQWm1xLK1nEtgdMKxfiOXSd1BsBU9Q0Wt8VKQGL1hDm2/BE0sLw8QvIceob8X7T
iFJyiSoqnslwWq+I6OdDQRCAxywWy268wW6rKgVZUHqKFGnYeZofBULBaXxF5eg7gFDSyHsHTjnJ
aFtPfUooalc5DmKWZzfDAQZTnJsG+3mNRqkeWbvSIWKL8JvpQ7ctJvskQpavhHNVq9nJA5AjQBG5
EPZEYlX6hjpQ6WKOlrecwa6tTb7fMQKrPM4poq7lKRQ47gmwO63yQN1wNiHifCNU3XUFRsSubZvz
sKXyy1A67lrNULuVYA5hUULK99wdFVPwpkdDY1Wy4ct3niGa4P7lWx0bB0Fu7h6tw/MKbLXIO9g8
dMBZSjc7jO8cQKtyz7zBnInTCMBvSwVEu9iGIv4loJBeDqFHXBy0GAtLYnJy3C3lU2otnFHLxAPF
dDXEsmm0XstoLfcCDTT9Tke3qAUV8dRIqfzLREV4jKhT15ZSy1QdK4uI1VkTZ05uIUYnMVYujaYF
5ndEooWt7F0WHwSm3RIu6MvmC0u4XFaNUqE2Wiwlg+XHcrQKrzcDVbtorqCurHcIGnu4QU1bxktR
Pco3l25lraxKgroBsuBD3kJS/wBTUNpzFAEZxFLuY2L+DNAcliuSoKGhvriKShQeJsKaQ4BEFsPl
8TSCvoweRRfMY0vJgMGJdPBqKzqnmOhDY3jlIzjQ8zlbtYRMVi9PcCktPOwFV+cyG1N6twJjcehE
crZ2aZVHEJEowgF2viW0W+MixrQTEq1X2g0XV1icXK6GwRUA6ndoE4C04h2FvXT1CFrICxLu84Y8
tAVgcxeQnwcyknHzAo1p5gyvtqobqPaOl1Aq/Gw2YUPLCjQK7e3KJ2MuuIka+F+Z7UGiUC441oGM
xU3zKeEVMqK1GOKEMK0Sk7IAraUoIb+RyeYlSkleLbVsXJuyi5ctmvEM82TFfiUQOvQIUm16LjU4
ckEL2Eam1AOYtascvMGgGkrmNYRd5E7VyVK42EmoAgKJxA4rql5zAFy+Zw+YTauxfPzD2oVMXnMq
assZridf/kBBeSuE4giynvEq8DKDfb3EotHqWWKIGihO4YtbzU5uWf3Ko5PEWukOYtouIbudrzLI
nPmVJOINl3ZxB4omhPKGxDnmAqFNhFtxrCBtVpvmCtdPFRbd7QWEavi5V0i+KiNmuoOJ8D5JQ5ZU
eJlRWTRzKv0G/MWlBa/US5KczmiyKDR8QqQV1wdy0FzpOp2WPcpTlFPI56YXtQA8G/zAuXrvzGg4
wjdP5hmj4ruUNpuSlo15gTTd9kYizwsgjdtDCKIuk5IAU4fJL5D8oChXZ8wqP2jTSvtla36mw5Hs
iQA0eKlJT/EtQeXEYWrUuC674haxdtMIJ1Za2weuJxXGuIHISUWyvc14WzGKDy9x08IxrF3FBsB9
TSno8wAu7vmXhS3fuCc3hkUQp4XOIKrxFDIdTAaPEVlmF2HM8ovNRG15a5dzzxcQA5pYORw6Qe1D
3UFdrXiYtLcIEPTZ6hiddpEXBw8xPPDjEWIthaK7iyrhzEGDlYsYGCZy5FgqgfuKAQualg2OmFy6
6dwWPHJGvlc5ig9u5dBS/wCZQjiRyteIXSZ5vuCUFXieZcWtrPfUA1pSmC6UK2iUgQ9iJhn0JhlV
xKhue+pcj1TPHmF7mK1d6dQcQDxZHgLDhjQlvmCoGnT5mK98EOTH+4ABb08RRTKJQmg83OYrb4CV
Hh5L6QEt5zUseSDT4hAp5FfFsPAXPaC6YoPAuiMACG6iNiyu+ri1e4ANjqCGHXcBU4+I7W0/UHFY
/qKkbfdy5buvMDzzR4mjeuIoPN9wTZjxkHRw7lcmi7sik1orIGs57ijbuANseootW87AoFRdnURD
ancWWg8MFBtVqR8I8F5xEoLV4JzHB+GHY3eVGQ9smNFtxLHsL5lbsppkEbG7IWZ67iDajmGyC12n
mKUGHRC/UYBFyycy+I8F98zKOX8xT90BTlyuOw4LtQs9kEouXzLzgeXKeBXLCgUByypcKHklgCjx
FyBFO+4zRSeZl3vLCGLeypQVsJz7q+2CL53fmILdHohWxsHmJIYfMECqzWGhfLuVC68XL379EUiZ
6lSxfCZBA8JU3aPAEvlqA3zBnHDmLsxiQNl5uB4Cp2HfJL0Hl31LAac4kLN+Q67W1cRESjKh83fk
R0HXOQQKWBU0AF4VH7Ci6lABvkl7YDSAVb8SxKU3NGuio1J1nMcnTqorSXNyuIHpZT7l+sfIr4Dq
PyW+IC26VkNoNU3cRCgrmCKmzi5oOVlb5iEiDuWM25287dE03VH0TFLqIlavntAJuA49WFArDODz
Xcs0XZpDNAhSoJXunZy9QKE7zh74icBqqbX1KAKcrxPiEe0gWjyhkuyvsitW7U6+YJaSlDD1ROXD
A2dogCeEuD4jULtl8ssBd5lm9TqcWO9yNAN+3uGqDTAkAhXwqY6Y8E3DTvOIlHl48RiIPxDmefdZ
ODod+ZW5aOyWRXHfmO15MIe+Mi1KfUCbqR6FsRa09nqJueowofW7ZtQ+FjLt8x7C6XEPK7vBIYea
cuWBv1Lq1XzDaw3fECwbDqDbBnHuIoy+3icKWIgBJvcdLSFdxBQfJIajroj9I0tU9OpwyxHuz8y9
A38zYukpE65IaFFrmoupRl5GBlp5grkeJglOIK0CqOebiUVFnKRWq7biPgdQKPD4i3NieJSREr8R
VGjz1Aut3xUvXf8AaBHbRiqNLeOoeGkqthQVdVzKBQV3EKpKYJWN9QgU0yomo0eJXLPdRTQCIrd9
kPrg7gIgYeamGHsE3KD4yAch6rqWAbLuoSHQ5muGnKsE1T9y6VvVcsBusZV1bFaAvGQAAbaiih9c
SiW3hyJQoPiII05vuKpwOXKbtB4sjSDq/HMAJvR8TjgKXabFpYKKrtNNgg2XwsShG2K4lEBfuOER
9xWFCnGLiFdJrDkutr2Ma6buuYkJN3kNcQvL3LzsQjZ71viDFVwxff8AsTFr7gEUJdcwEQtvzABN
MSKCpG3xAJu0Wy4M5BcQUIHdRAhy1Bl32gglTiK2qJoWsbEWm/iLALXiJV7A8SwBPNVFCRBOZers
ZArQRnH6hth+iI4UVowuDAxWa7X6lro8+IXIEzh79zTXJ6C2o6OiMDRF7DSAPRBK9mC3ZaOSEVVx
biR176gA7d7EABatY4mPmPYm5a1HQCW3Gd6Xb8QVcP7iSGgyEapF5MGx9YPJXH3FebXhI1Tt5qNd
lTwzDVQOalLQkDur/EBSkH1zLwYF3Btvg4RU7OIAWrV4inV8VHAR3bgFdCML0+MAo0Q5fMLhvTcu
t54ln1mRMh+EBWFQAKvluKlVjmpfLs9pM6Qc2RAqX2iI8e4gDXpLkX6qHmIS0xvk9xVcVMaEKZfu
Igx7LzMtCreoU19QxTENvuEhYwaohUqkG+aeo3vyHmLYOVUSi+2EFjR8eZhViPF0Tg9QQWtcJVuV
K6AD7IN1r4gK28eYggovPcNXZXALdXkoFt9xYa2vqEFFeEloV0OCp1eTnzAiqvqBUtvxLZJqE71f
UaNlQG2WB7L5RALVXiGzN4+YGq4D1LtG216itRDq6mVHLlQDtfhTuAA4Xfc4i2w5jV0ucysUouo0
sa4nDwr3EK2JkoBq3fzAa1s8eIz1RKe4Ead+JihTnM1vA6OoI7duKjQ2CIIop6IYck3iE0fki0pV
1YQsjKCxrZdwS03UVsQBweI5IggnTNA0aXryXTVcFIg1PhzBg27cIS2oK4cwLlg9svUU25Eg5bmx
3REl6ojZKLQDmI0Jca5j7ZERX6lW2Ry16ik6t8JdKuOy0gAuCTBd04JdaXPKAmxN7RRx56jtTHMl
IQeYz1pdRd0JxUDc85dRyIDTtVGoVR+57d2XAcOSHCyo62ovEtUql7lab8s5gnI8bFo1FUwFokMr
w9eIym7qVqq3ioLRSg4qPW20Ut2G3zWK6jsWMyAQvpxAYn3EUDQ4iNi8+oCsJTVTaS/eDiJa5JoD
hMH3DZCiqrmFFDaqu4yIBbySjKnEaS5iD1LLyrmBFPEbTg4HcXUWduoasE7ajpEdxl7jTxNPJHaF
Jex1uB2HiNvuKHXYhY0b8zH5EaxL+Ys4ls4wU9EzKfcKZZXqWDM4QV+AvUeoqz+XmPcjb6lxcvBO
0FeSGtVoDYMsKjhR8y93h1qWJafeS2wBXdTFHXyS2s0zvWuLlFN7IDyPz6m69Dz3EBA0UlxBUW6I
Xm6vIlgtMmDVTkInINjdcHBcLDSPUGAflFBXd/zLWznmIJVoUuk/USifeXg8cuRspavqDoWjhnDC
8HQhGtWblRZgid1LNkXHi4OXT37mFaH5SyRQ2fEF0avWMmkt0CXFiDwp3KDpPynGFRsziAkWHSgq
G7euoFq+xAyAA6EuFhL8RBvfmjuJVtLXUugaXTXcuU3TuL5Au3L0lcuXLtCBAJ0q67isG/ZCQxdh
DcLL5gKrpOCE4N7nEdC78StbiUq8VOO5O5GB75qKIfIY0JNfUAhQkTjIOlmdS8xL9xLG1DJu2obu
KVfm68xdgnNpNjVv4yUo22XO69B3KoSW4sCpBeAQQnYHBFGNPiUAar1L38EKEfpUWyhz6ieR3Eds
V4KhwivcUahzkfGKhTLwZlx3CKeZ2pPmIgw13KWbfmZ0H4rmIV6INje+qliVtxKs+PJAJ0EArs12
R0FQbXdxrh0illIeSYBh2KWphFQ0NviKBCfEEVeJW77iBqryeKnLbtxGhq2tmt6boIUKWevEutqk
wAlWLLd9THi9WdxK2j4iBx/xEWtEOpba92zAtnm4Jl5iIq3GGxcrUwIN5bBUftA5Xb0Szd5Dgj0F
ldlx5GCIbSLivVjLWPkkLkBX+ICuP6lhV33AqtY1UrqIl0r0Y6COx4l1iH1K9BkQplEKX6uGX4Ph
lvJnDccCtOL4h54cMbC9eD1AlF8cE4NaZVQnI/0jRVXzBmrV3KF2lHbA4JhtZAPkp6GF2veglhVg
lmOCtBRRplQAPHoloPEBRSt2pk7a8simxZ4gBxfuBt6pBNXJDeqgm+GNAKHTNhwKruDuKnQREFta
rdRYuBsWZhz5hHkcXKWLbioVsCtcxFBNpzqUMV0zpgaZyrYHAAVdTJR3EOZcSnY4VE7X9hi33K4L
m+CU68m62Kmbbw3TOB41UdRiadoLdRHEGFv9QAz0ahDE3nKOJBziHOrs2PxDyqh/hgdg2AjhYPEa
tMcBIiBScXK7X9UFt7leV4I5r4iItVdKP1OvtK1coZnUI6iMFvCdILrXEX4jkSd0PGS30iqPcdjY
8BUoLuiEy4jjs/MSIHyxVhOw/tBK+qOSs6YPCIvJBXFxNORvIarWMo1XstULrmXG9L2kKbLPLCNS
GlL5gfLbtxVQAgTAGVLm/Lio2FcwfpKUR2OYrvjzHVqtmXssvJ1hbXURVz2C1ruI9xogwQWBg6Yo
JgVZD8Qgk4l1uD2kW0yo3rir0mk9uoYvZoo1fzBIUL7TIPNW/pFt2dlYpDp64nEtHKIpQfBRApao
Qz7jZCvBaMDK20qLW3Shg+4ubOy1YlYkHCcQwlbVwguvpfzjJTLYXEr47ILYBdrsVbDeRAmq1Dse
4G2jrHcQt07bohMPK0qCANPIC+eo+oKSErTVa4qDDitlJ83AjDynvxHjD9hIVfx5icNdLiACOCur
qpYOXfEGqstqvUCIW+WXKauom3tXkGuuaEs3TwMTEynxLI+PxBcMCr9x67VsoV4u5aOgVzXEEBP4
mFVPmOyl4lVal36mKnxkdYb7JdXyOVIlHi5bbenPxC9dFS7nAeiFBVnGQFdvZBNKr56hnFtLUb/y
KnLWs3iXbEsvmIjMR1GuPRXxBrKvfmMJRLuDhUFcRpQsl8S3B54iaFlOFyUx1czMLc89yxo3phsu
rlvRC6TOL4hpeExktKa8qmGY7uXoq+oAJA9QSKA44/cQURXsnBU8LJyUtrkjaqwalNx47lkVArkI
vxSZtzZxWx1BEdlFB3fiWWjPJLnSx7VtVUSyKniB5FdyxbZ+YvsPMGwAF7kJsOJhRVY6Pw24/Qen
ggKG7PERVJfOOIwIA0heECFKUB7SBZ5UghprnxK6TfBBEqOpRKUJkTlXHqboWX0SyocKruFFJob8
zVhbIWEccLuN1sF9S62cPEo49NlALb4jQDT1OwdElltqPM5Bs6nWt+IQodfEESlH5lqH4UkRHCnc
7wXXiBa24gPZNI6iyidLGxxSpKQaXmpRLYtGQDSi+io9ZUpIZS9cy8Dd9QCfyIyV+ImQWcKx0238
QUuPERGqV5Oo/ReoSQgfUO93i4Yg0l3cRzw4ajXKNxogzhj6OM2ItUHqo6BR5EtWxZEggnXiOY0r
vqKSlapqA6fmWgf4TcXAiBDrplrmPPBGwql3hC5ZZ1BDcXK2g0yWSyjqMjheUjtzcAQ4RK22fcR5
6+IWi5XZFENfbEGOfKZOQWcYczABHiDXRkSea2MkrrFYFKnxUS6tp1UFKuXx6moweVmivSenHz1H
XUpAto5SW1aDtZYFK7cgXuwwaSI+DqoBS4t/ULbZzLaKHxCBdDGu4hDbodfcBDa7fiON1WVO4mbw
j1Ba8RtbccIJvlsYwE17nIANlUlCadXDggqfiojFDK0PEEFLu9jsCjzX8RsCwgHKXo+IQdKB3uzs
IJo2VTEPv1GXEaR2MSltTzkCop5bjhDkovmFY+Bdv4gcEgAr9RizNnm3CHMlDkRofKc44wJQDzGx
ySvOSqvtANg14C68mbhAqNlFDN55IsrwCbUBx0iI12jrH7msKralQii8JxKA2Yv64iyWy2R9XLHA
bdl0aKzJpage4t6Hb0Q59pYbUo3Bg28hRRZgC0RUDh6xpweFcYBVyY4hqQvD5jJTTipQSk7iEdqk
kN4Gy9EvtxODDtmWlq3mG6dq2ahswEqDN8V3CdOoAHUphgbrL7yBoi6Mu+YUtsB3IXtiCqkYFNSG
cQanP8wAcVExl4a3wxwNFJY+B6lwJZRQ+ZVVMAOXEW2l0cvNxnoYARyvCFSsjLOWw5/5LhmA405x
GodSrMLb5Bz+Z1zjSYmMFcnJZa7Ho+f3Kz4cMKl6ZdndrICsEvkhgKihBrbGLsJUrVlkTjOirIML
ywIMklzweeYgBhy8v1Aaym+EvAheL3KjSreI0wpyQdX7mIcOAitovxFUlNcxlm7bGZB3y9RBz8+o
a1SfuPgO59Stw25yVj35jQdWUlqi0iHkxOJlLfjuAkJFdw1DXgEAvD/IIOC69QrD3dTjAzupqo3m
ATS831LBlf3BFqhQVXtAOC1pFChQTZdX1ywRpbpp6IXeQrfsqKKPaBahmLfcISwY4gK35ekG3ovC
Neayk8QwwPlLFATFrJRgUPU4I3+I3Yy9nJwqz1BIVkSkEfDxG8oAX7Sg3ys+GVYNHmEFi3RcYaUX
IraAvmVJtYduupa22WoZ2FW1VSxWWLKCaUK8uRN4A6Euh2iGEa5w5qNOl2ichQ2sloEQYrJ9WRuW
0DzFUwHPzL4C3p/2IBBFyw9XB1lCFVeXKmDjzG+FTBIXFpruo55oMqARtQN+oCe+5ctFv1Nlr8QT
TyeqjnG/c0CLOYVZ5YFU3QXTLfXnxFcVF7UXDnVy1dOVMocl98SgWvKZfUVXtQKPtUFbN4GVKXnm
UQonjwiFoSuIQEr+UNAs9xC2j4ihRQpSyzNjoJdXIuLEilsZGml58RQgbZZkrWrVQRrmYxHCB0HM
tkKiHf1MUprb7i8oEd+IjJblym5f4Q0GzqLac8KgLNb6mAM7EFuuOJZAUDeRkJ2M4FKBzOVV+8gk
HV3iKS6DPUUVt1BanPRBpoCfuGmwLvY0hdVERRooUC1bvieTXolq374qBZK0CvEDddcyx32rO5U3
e4M5d7kBRVySDHBvMTSvpC4JngjgKnh5hVou7YkGWv4lnVlN0E6bVMC/MT0XdIoODzXmUtcnNRpg
97Cg+U2nfkmxRqQpU4wbLQXluYbButfEcONcrKWNq9uIU4WVOhzPkmoMeMnOV+kWgtrHWlFV7ZOW
CUKUsIg1z2kIBXmNQ0eGPrxCLDrOb/UQcVvEJDiVICncWlFbc6j7KWJ2U8t5jciFvxHekpofuUH7
g7hpuUU9y1IM8o4A1vyuMqNVeq2IsX7yUFxzd3UYQLR7bBWrb1AAsFW1zZcbFUq4lFe2vmNpB8xM
N5FuNimEOl7qO5Si4VKejlp9QdbceH7lIU3XIqNpuNFW3+4rHBtX1EsI2HCcWKVkVPa7fEugqT7w
iOxEX1BCUsu+So1lSC6xgFBHyrqX9kDnu5SKIC74lpjkIwYucJwY6NU5SaVinggNFK+eIhlqKLxz
FYednxK+0IHzsBVAP1kuxRLblNT3og81FZNK/MtZFd8RCbRGDuAGtVCh2Q0nNwSsIP5jXgUek39B
qb3DKtTa4+nKUtZfAoYccSqrRJh4hsDSVcNjuBYCDZ9xY63Ff4w/AitjIBtZcGrewNDfOTj8wpAe
5xmk4b3jHzitCpzzHYzbzYf5PA+5pDpOBd4/MNyGL3VuX5pl+Irc2Xp+4TMiWtHuhg5yKR4HTHlF
FFcviAGqhLfiYWBE7qoocBUvgtiQpRW65g2Wjw+SFNUst9f5Ae5Ad5SzSAbXyjQDANfySnQlWjSL
0ztckD3CaK8qUPVQehHA6eSAEVg1xkFeNB1gmCU0qyEQ4ORORlcuY2RaCxbV9xK1xCXNGviPiiDU
gaI0H7lnq3GK2rD2cwGDatvtKcWrQm4UbgpdN1HScgqkNjYOPaAIph3CVEaeGIOGm+LllrwrzLwc
9pOiVfmCi6B9+IdKo1tQuvaCqIpm1OYi9q4D6iLSsMNlLgeoKbOUcYM045bcQAaHCd+orQtPELwh
d0jcfRDdArNAhR5JRSqs4mKSnAh9yjSWEKcJQqG3z4li1upZejxHFE6ggCp+kTfAunmIUAR99S1t
z08xKVl8qiHYU83LhbbkJEsOoIhYmtQ7SFNdk0OC8+IwhsPEpmV4gCa/aWHsnPiA2fFRGhnJ7jSn
k1GWbyyHgxyDajmIC1CjlIbK8OMIcbG4hA48kaaF86x1OxURXl6uaUKD0dRIwQKAGPHcKIweklbB
JKDmyVAEebq5YWqo24VQddwSFtcEAY4uVFm+GAgCLFsKquQiEsdOEsBxIPBkdAWZdSwqo4grOVw5
KBfN9QChvNrgi1OTIttHthVKxicfpFd2fDGqm29eJQA7rnxOMuD6gXpgcRt/ZLObO5Uq6qKStp4J
rCw6M5jXi+4II5CxlATly+4QbQwZVwtuYheS3ww5dXxDNzo3CjLv4jULJyNK3bqG1SLspsL8JULd
dSrcELUsIumqqKpblpqPiUAyLAXXnZQU2r1CL+CWRS19QqRY/wARGNV3L6PQRVyAqlqIIiReYtQV
ppBTAwHNpgtJZVywVneZQXyvmIVu3BS7w6IXI1g8xL9RroKq3KvS81BsVTXGxi03W33KQts5gRUt
M05iM4egilinw8S4G1J+I1rCTR4cBNMclnv8xC7Qef8AIafkIpQ50VC6aOLgQ3qufMsFyGMAC1TF
8xWG8LirDR5ub7KkII6HUPB4mEgRyI3dovfiVKdaCgPi4Z+gL0D8Q8wldZl+8Stb4hLtSx5O/iHn
UOi/Pcbju64YJUeUU/6iXnk4WZU3Ycp8xlPpNXW9xWV63ii+blAlAiBeRYvp+A8N8xbKd7Y7DfpD
qeUX4i9C3w3ASLwwOODdjoxS3X6lasXiWRDQNJjDUAwq1iu7mhR7JVbvoPidXcDh+WF6POCA8xod
ATY90dQtsLLwWBTvuEj/AFS7C9J3/wBkZjcTEojFAN6WV7lCQwvL6lpIBQozlJpY1MgPzC2fSw2X
8j1Le30uCH3vD4gTVqE1yW9vF+XmDlpatMgbG329oXZwp4rx5lnb84CtnqU4HHIWBti5r3M+fgtp
KhlViLPCVBdHmY+DeFZxFcIAs/MePCdW/wCIV2AHb7g19ZQx4lLROKDfEpENkeH5Zaf3EBfzOaJs
PbGNkx2piw2sgsKBowmBa4APBcHEWtOfUfv0iWrC11Xwb4upbyl0plOO0wpnZ5l1QrNWXzL/ACPJ
CLdnrZMETFofuZsUtjns2AQhgaKrIABdootyyqjuzXDDajHZord2anL6dOlOkzKB51XmLWPIoSoI
BGoem+oIlaIV4iKXy1Yv4iwaLDR/UyQael2ChkAAbzzFpPDQ/iKuLq6czVD2gZ8SnUnlmIGClsGc
MegCHijz7lHC2t8udHbDHVTAQlC+gPMEvSkvmc1qDE7QviUK3svmYkVPbEVXpVIjRazqxY0535ly
HTxKTAqF9qpKwPtNtNuISKZX5ubOzstXHR5gKjTaqBEq3dFkK8CrhjVQfB4jaQLVZ3MVyrziUsgC
4MJKIrlnPucyKuA4goXQB+IUjVDmNEdBeHEBZYD8yhROaslrBdvpLCVaUE8QKS6HfUT6vTEoMu8m
kNDiu4bRzqvUNN0HUSRTL1g5dOAP3FFUV4a4ImteWolVyXwcQChQFXUOGq6KiUabcHKe5peXS8RC
BQ9xuDnqL0NV5hu6UeCDabEF2FDX4ITVKQQAJ7lrs7UTgLZ7mUdHENFtcJZvQOQKvNuupo8PECrK
8wPK/qIUcX1AcDXuYlfoiVW6f6l9PPmYIqnCoXIPSpZWl3dVUBt7hV0LC0qiVfmHQrHzGtlB0eJd
LAnmtmRYPMyV8ygK33LCkRuFvWNgtB4lrhaZsECafUvDu4Dr06qM3HMoCm3Be1lP1LGkkG8u0uXd
PVwt4Dc906KjK2Ob1CoI4V4TFtt8ReICVl/RDFbt9TstrxU4LKEaDtEUsL9EirLB1CsOLsiOJZzU
Lq5M2AVyC5Vv8QqnL7jj49dSwFKq/UTwvV7FLQXEoDU1UqNDeJYItL2coJ7nVbWWRRdg9TGGuxYs
OjxOHyeYVFs4QiqFfcNcVe7FDsuyXrAOTjmERZUHqcCC5BYCol6rxEQrpulhb6J6gULFq6lgBaOE
WhGudhpMMIUWjmURuDIvAnwnJChCzrl2CraOYlYBhO7uEoLHqYmL34QVR7uXBazhnw/CVd2A7qOO
6H5gLjNcR0lxTE66ItDPtlMaX4m0bC6PcB7UXWQHpcZN4ueWoOR7WzQprEcCCCOTdT3ENiXmIlgX
/wA8y+wg83GFsX8EeUpwkZtX+E1KY8NeItWkNlc/MFBoeFNNziA9tIRC0ELNAeBUQEBHmyEUpzgz
a21YsIcvXxFdFeUGWwA+zf8AkwQVxSAZMOV/kxhLlGwoHEQdBKymVgZeSUEauxMjVE9AqY5hTbG6
C1F1fDzDA6gggB0L42Wp+BSX9o+bjvOPcAPyBAUBs+R+YIAfQGH1AKbfzEWJp2SitIHSF5b2Cf5A
9EvlQBsHyXHiBPBf7iTRS4t5GATkLtQjo8sN3prlJSDh1CqfsUSAS5MC/wBiDWKpp/MCpW2VOnV5
EK/cJUQ9OkFRU+cmpabaREQF+bCiwjS6kOMfdOpYt9jdRSD6HAiO8NUBOCWK8BEd4uGC2XjsK/EK
UHawPzsqVBee/wBwtK04W455D0EfzKUV9tr+WbjfVuqhKq2iJ/mWBd1yKfzBEMYUEPeKsqV+4C4V
eFK/c46lxxHpiXm3I3SvAXVfiXV/iyw/MPFvhbR/TPmrHJ+5mpPvRnACKAKr3kcSQcip/cQHK29W
WDl3LpL7LajBh4qWManBB5upRDDxWEyb831EShZtX+IIvXFDWEB248IKKAekgdZjohxqlPEpxXGs
mRffHklugD9wI0tvICrwOiUMl6+CHHSqqotFGrXzcNlHyMXRJjk4ZguQ9QTstBomp2wFahC+GkLu
VKNq5A+TdO+IBW08xgTWI3CYtfEDiIHlJb8sZSxLcbLcO7uFF8HNEWhii/Fy8rR454hXQHmORp9C
DVFW4iJ2K2yBQvZVsbPHmEls6YlAHQ8I9aPhABuC2ALanacQXQmOaj8yDS+pUcB65YgLx35EowaD
kiyYRXKTJYPDnEo0VvzExVrN69wU3Q7a5gwYLIjE15QAEid5FNu1FtpQ8y3FfEaS6L6g3v6EoBYH
PiA2EVhw9wofzLsG8NlDXL3UARrHzGBRVRvae1zgdU66ldYZYJ+IpWnk1jGqbPcWrpQOZcWtgXAt
FLMozqNKeSmoi1L2HBeRxAHYPcs5LvMcHbOoUGqGUCgty6jvuvJAvQPETfNJrdNdEaNrRR7xyxtV
UDFXVN8QCL75Jir5WQwNDCZYKqlWhccKjZ4LMyAtjfCAKLXPECvC7J3g6qF6K7yAt7ragkD2qpun
zriKLUVxioCvpBFKz4jI2I5GaHOjZQjlXjzKDgf1OAQJtkBG1B+4VPKytl3I64RVGgpqAaDzFLvB
Z8SoE57ivOOLFUU0EfBaP4ilB8rYA7eVREXfRHZQowtt2nHUSGVUVIUqmDSU/JMAAPzO4D0w4N2d
w3NPhgtN0hYXAX/xKGtgcVywGHfN9xDQoOUlCVbhB0cW7YHBpBvc4lqaCO7Lal8OniJQ5vMpfG9d
xKL/AB3HIunmAKRfNR8Bvip8H8TkkI7Ja93yqdQ24iLkP6hfN3FdSrepQYecQu28+kO4mm9selo3
PIjEL05OY9s2Fm/uAuyqipr7DuYpV8VWQplHtCNmq+I1BTepgUYqqIffRMbVFxZXkWc5AKRt4ES6
2XxL/wDSAtL+Ii20+5QGqefEABl5uZRNuyoAcXBejT1Diw3DbLGolML5lApb4yJKuOChBXl5grbX
eS0Bf2wi6Sc0qX2Vr3mYS8clkUvqOH7WQgrHuVhB4WQNBi7IjZDAZXCCBDTFpDl+YirhXM0cfaFq
1oVC9dkWwIpYeniOwXDvzOsxHJb3dRAH1CJccpshK89SkJgykvxkrQr5kUIrt8VBpSj6I8YAPmXU
14ZdhzuKyUOKrmBSlPog7H9NjYdtgsUprmo6Kg5BzACqj+pacK4zgXnGVWxHJKgOK4qZZN3SJQT6
BKA2T1Gs4Gy4tj9StJ6iLx8VF7Fe6icbUomtHzA0duvEANqnMOQeiDWxXvlmKKutIQ635TABwYRs
D7D1AgNVrIiuuf3NRtVdRgC85iIJzqXMSvnuUs9ZHTAY3Ky3xtS7X5h4lSzjiH1fcUtdnNHUVg2F
ykbNUdsGBReulmW9kuCrDupwD91xFJh8xrUv0iqBQZSRSpWLGZQoO/MANWuyANttfuUxBW1HpIbP
UasWP3MRpF5eoa0E/REYVKc+4pKKz9xvEnNc1DkCikvdsirrHi5dVyAfUBJ55+YFWpaeICLMrmF9
Gt4gFq0cYV1eGwBoKHXcSwtdHcpYFJS+4pV1Y4qUo1DxMlNHGPk9cVEmwNy6hhcNddx2joZOVW92
S8taeciECw8kpR8ktI8rK9ZKGpHqJShF8Qyth2Og9PqUArzKoW0KalLF2oiINDYgKcnVQRQnKjYL
aObiVZZwtiv5CWEjShc5RfgIHIwWWanK6gpmPFxBthTcPRDnI1RLquYitsjWog5S3CFA48RgaUEZ
eW4B0N4IXQ3kgBH5IsBaCCgHHbEWxfgiuE1Vy0PwPEsPiAvZ3KKaIPEGC6+YrUNOGD3fwnCWi8lg
KUmi7EV3Eslr7m7s7lXozgLN7UpQDnL2Tl3yKQsBAc6Qo0A9E5Oj0wEGHuAdhaaZZVn4Qnlpb2JS
6B4mQXnUXtsYdEonEKhKAqvm2bR7gAUWETYWcUxGVHUKbOV4jazR7OYoRtTdsLN2e4UXZLz1AuX0
YVcVNuMwB7iFXnfEa7SeZ0ljCQDRAArblNwMrI7c4mxrB3DTwLZa6eIptU2PUTZLi2C1ovYbJ0U6
M9AbpDKqH4giEHbY0FpcqQXwrlbAhHGsgWwb6jb2qcx4SzOLzJkBAeIKYDyXzEB0DYWr+NOorVYu
iIgrnVT5/hKROTmoHqevE0ALoyPW7PROFeisScY1FRUUd/tFVWizUBwS/RKO6cX1EVWg5hDo/EEc
moGxl9xqy8GAC2PJNADmNKrj6ibftGAQOukEShYfZCYVeR6iCD8orQ+hNs/A6lJ7HcIAb3uKneM2
Cbo1obHJRnpGG6BYRBrUoAO+JSKcd+oXeRUACcPUApPBKlaNRtqCuhd0cEt1+42mDp9wQcKshLom
gdeosThnsBlxeaLOGUsCs9RytVdHEWRqpwgX14mlK0w3Hf5Igl1pk3S8d+YjZc8ZEVeu518y97Ff
EBNnTYLR9ExB8CppdhxCFOHE4gNcxgFaghKETCzm6juCjIAN9uMRl3RgQIp+iCo93Q5jRPa4iuXQ
8FSoU2jrFF0PNTkJj3OYVtxVGXLtqYEXsg6eJajgOCoKMCrxXEBqEvniAU0OPMTQuyEEDQcTmG+m
ww6fmIuNeUQV+lwarLHMFS8P6lihbO4FIepGgUFmsCsbIQm2z1KnVVidQqp0xBPByuoMOA8sBvMQ
AKpGrlc+SYxPsD9zDCG1ELhU7IxNmCWsOiLCL0ruIIWvr1FONVfUqroOZpHjBgbgfEXgLHR3EgLH
qH0/Oom1IfhiqwscrxG7FhweIVDdplShmR6iDYFFFWbEYYA+v/zEcGnxAN6PNykA61CALA4jWw7q
ArtfX8xIhLtr4lLRrciy7R2dkBlC0cj9Q8VKnEXjiFseyw+IKWq5uD4EzO4l3wUe4+Q/iijkvLqL
D8gRUmKdhFQWGSk4ouHpUj+oVVSqcS12UNekC8w5jZtS/EZDYffZLeAtXLhDb/iNV5D+ZRwReFi0
qbWUilLmbT4SyxVv4mABX3i1O7wfECls8TCtVaag2Utd+4hgHxZxBDawMYBs0s8cxOLg2yGq3cbO
jpwEXk32Ex1Wt/DCGiuNhB6PpjZ8Av5iOI8wCBQglF1zlTRFKPEsEWW8x3za+Em4Teo73wnJSXwB
LKQ0NqHSK3weocMXeYaYGxKLhyWoC0FGCKXe2cRq/wATB7BUFF1TjOoWmkLtCgXl/URujL0wtE49
hKPnGTguCaSxqq9S6PHP4myFN4gCwunpipoEZfiVatQZULCmt86oMigrnJtdNcQpxT3QRFm9eCom
G7r8yoBV5hQt0MotZqOAS+YgLXzco3dwNA0r8QgByqhYNEvxDmoXaQFj+ZRDncsXIRFbRfUCgw7E
s2AmVOAcndShYUeKSFNC/CI2CHghh1CoECRVQccw7DhW0RBaojiwoLS3hGnFV4jNKrOLjZ17A6iq
pS9qXscnUsB11VdRsAEGMw1tcSyos+SUhLhZuiXYpYx3jPhiaq5ceBYsquBPHiI4W1YiVDhwUYtF
qs2gKey45l7u4ClwBYMlfH4RXU2c1HZL4kSjaMwmAd+ZYhQ7lRyp6Yg7XvxEDCvPuV9GJUTnDwyx
y53AK4f4iWDfKVhD+57XJBHJlgAIX1FC3yMQKNOUlkNA7kVRQV2ZGkBXJSJm1p4QiDSm1sJhXt8x
VKB+k520CZLA5+IjUL7h1RvDBtFPRLk+HRDqroFIlVt5o5l+wbozmCAU81U4U1ug8RiynjOYqJoS
mHnoX0czoV3yxmcvUKDKbl6RE8E4JWhpDzChyHEqcV9Es2FeYJc07qKIs3eJcprZlkJVu9l6yHER
FseJzKt18Q5jaqa60OiA6qHlA/mIx2LIWV09wSj6FiLXb8Ru8plZHIe4ESr6ENCFp8RBaC6rmBQq
5yRMAQYy8orrYvTxCVt11LKD8QSRTeq4jBNA5Ooos/o1nX1rsGCYe4SwdHOS61gOcg9L8iCy2F9Q
Ou3pMZZ7QS3vSPJd06Qk4Hg8QUInpFJHO4HT/Z0H3UvrKLSAqlo8nUrdXFEJWjbCZWcdwHDK0hJE
tI45A7CWg1GpUvgFOFkoDhf1LowY3aAA2vaQKW8KjpWo265WKxB9wIAd4mtNvcVmdwJDm+LgEX0l
mH5RLV481HTnJl8RPhv2lEpq+Lmjd4+OYdN542HcHZUCJGy4cGh5Zy5XxEO54lIS/wC8AM1Vu5dK
rDjhBYKpqneYbBQ8V/7xBwtaeR1CxaW4hPMOTzABLMnpLmXzYji1iW1yw6l0sgKiKBySzlR8xsQc
OTuW93l3EApgqmJdwAAWwJVkYihx+4FAsDqDsRUv1G2WuIRUFcGiFhcQyAq2K9y4gp6ixooHHuJ1
aNyKwprmLmqu5wwWn5iF2VXFw5dnFR28QvuGDG6lijiXhtOY0KaddTGXb4jfZV8VxEQ2znJUNrfB
FLLvwsiKKIQBc1xRCIm+ZnK32QaGiP3L7texyYrVp48RK4DscBrRRA0HM49J5qUVTR8Q0A9IYrG3
uAuwSxA5DjqYDSGJwHEei8LzUCwtMDSm+JovL4nangjp0fEEC12QKAQNslWs5yyNsXHGwODfHUbA
C7x3AaKKvZVFI2WrxL6fDXEaXLPNShKznJwCx3GqUM+V2V8RLGvcbBYmQQ+MqJMeo2VcupUGCWrE
izEOu4aVFdUQL2PMEIB5zlHfquZgseJdYLfMBTVcxBd3T8RLy75ZoGNcj4FFzgLfZkZUazmo2Jo8
sT1PlCasNlVKOTZyQ6nWQOXgF1x8Qj0R22LK9zbjC9CXKUS2MuIppahBH7GXaDhbrmbKw7c5FmTA
vlpqNQW1WUlqCy5xFSiOeKj2CW8C9BiBG76epjQ3qbDYvBA6pPctSVL0ytCICAOO6g73qdQRDh4u
Nst5dyWBZ5uJ58RQ4bFYFW8Y5FRxVRbQLoaNntficHwznJc7JfUdS6hG7LuEudTYuOaj/nUW0MYL
AWoIpe8zPp4iNXBRVekcbpV7hAV1BmLReS2y4KmnmEK0bzDQHMMOeLqJpip9/MdNDCH4i0i+KgMa
26jiTGcF7zzFh14l1s7hro11Bo9LG9rGI6UFcQ5HIxTipQjXq+okXYb6swgxFrbfMoqCVxUEG/CJ
COWXQqh1SDxCoPqPAsHtkBH5gpF8ksiCnnZaEO8Kic3niCiFGFicsXZ6NlADWAVdoyGi7fmGB1UG
UGjiMhO8xEFCvJFbO7htnRCSy2rjtDwQL9Y6r5CJ6lmaGO7KyOL4iGJWwdPEFoP3AefMJWEH2djf
ygKjtLibN4IBsO4SkoogoSDa+JUsBxAXHKTJa7r7lBWPPMVKM7mtdQbl5GHXiALUZQ6eJc0HhLIm
3yRF4AoTikx8xWjNwiCr2aCH4idjkrTavOy2PiKm0XFAfuYDtEa+4bUVQuNkNI8waJ54h2D1nE+Z
cJbRwRHiuYRyjxU8Fy2HAtnKnNcy2HxNJ3BT2nn7i2g+iJA62DhOJBQUetmIcW1+ILg0CZKun/lR
zgWVxE0biQrCoW8s6nLzc5GmxOLwJLgODK8uCXa3fmJ6KJzuWnmIZ4SBYCJPEcIlIQeY48jxsEK6
Muso5riKNfEyV4QQmL3NFO5AXe4IalwbwxRLudlFjzUyjpLqBtmYMEmxSxgF0VHrpUNdtjh+Ywgo
L8QqsNrOo8QMY2xuorjtRw8GLwHyTVLBMT90wNZMj1HoLPEIpAhaOBgD9xOrbl/ZLLWkpf1OAxYL
DhKFHAw8zU2r+0SgnR8QcnXSDsuhFffRlUAVUSr7iWhxcG4VcFSlfMdA7CEMQgmjxUbd7cdN8tRa
FxqtsEFbI1D4lHhiXKmg7geXUWwUbLAaoDqDfFkCuWk8EpZMgPVzTTXLICoXncqqCeKjzYMykx8x
aBORuEpePUKztmOdxLeiUOF9RtG+cTzGV04uNY9kUGiMvFZd8RCyuG5hl1qoryCAuG5xFaEH6mZM
uhi1OuIoMLNcRIWaE58NgXi609Nxrr5j5+CKvgTidLHdGDHC93ED0itX2xLHmGk8QUmFCeyf/9k=


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

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

--=-tkzN+QYEI59Tez8y2Lgk--



From xen-devel-bounces@lists.xen.org Tue Sep 04 10:54:21 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Sep 2012 10:54:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T8qlP-000845-4s; Tue, 04 Sep 2012 10:53:47 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ijc@hellion.org.uk>) id 1T8oRL-0005Uc-TT
	for xen-devel@lists.xen.org; Tue, 04 Sep 2012 08:25:09 +0000
Received: from [85.158.138.51:56309] by server-10.bemta-3.messagelabs.com id
	A1/A1-10411-6DAB5405; Tue, 04 Sep 2012 08:24:54 +0000
X-Env-Sender: ijc@hellion.org.uk
X-Msg-Ref: server-9.tower-174.messagelabs.com!1346747089!28527322!1
X-Originating-IP: [80.68.92.230]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29784 invoked from network); 4 Sep 2012 08:24:49 -0000
Received: from aaar.vm.bytemark.co.uk (HELO aaar.vm.bytemark.co.uk)
	(80.68.92.230) by server-9.tower-174.messagelabs.com with SMTP;
	4 Sep 2012 08:24:49 -0000
Received: from localhost (unknown [127.0.0.1])
	by aaar.vm.bytemark.co.uk (Postfix) with ESMTP id 2E82D14910B;
	Tue,  4 Sep 2012 08:24:44 +0000 (UTC)
Received: from aaar.vm.bytemark.co.uk ([127.0.0.1])
	by localhost (aaar.vm.bytemark.co.uk [127.0.0.1]) (amavisd-new,
	port 10024)
	with ESMTP id 4OeEDTNlJ64S; Tue,  4 Sep 2012 09:24:43 +0100 (BST)
Received: from hopkins.hellion.org.uk
	(cpc22-cmbg14-2-0-cust482.5-4.cable.virginmedia.com [86.6.25.227])
	(using TLSv1 with cipher AES256-SHA (256/256 bits))
	(No client certificate requested)
	by aaar.vm.bytemark.co.uk (Postfix) with ESMTP id 39A641418B5;
	Tue,  4 Sep 2012 09:24:36 +0100 (BST)
Received: from firewall.ctxuk.citrix.com ([62.200.22.2] helo=[10.80.2.42])
	by hopkins.hellion.org.uk with esmtpsa (SSL3.0:RSA_AES_256_CBC_SHA1:32)
	(Exim 4.72) (envelope-from <ijc@hellion.org.uk>)
	id 1T8oQx-0001U5-7m; Tue, 04 Sep 2012 09:24:34 +0100
Message-ID: <1346747064.6712.6.camel@zakaz.uk.xensource.com>
From: Ian Campbell <ijc@hellion.org.uk>
To: Joe Julian <joej@edwyse.com>, 684661@bugs.debian.org
Date: Tue, 04 Sep 2012 09:24:24 +0100
In-Reply-To: <50454404.5080503@edwyse.com>
References: <50454404.5080503@edwyse.com>
Content-Type: multipart/mixed; boundary="=-tkzN+QYEI59Tez8y2Lgk"
X-Mailer: Evolution 3.4.3-1 
Mime-Version: 1.0
X-SA-Exim-Connect-IP: 62.200.22.2
X-SA-Exim-Mail-From: ijc@hellion.org.uk
X-SA-Exim-Scanned: No (on hopkins.hellion.org.uk);
	Message bigger than SAmaxbody (256000)
X-Mailman-Approved-At: Tue, 04 Sep 2012 10:53:45 +0000
Cc: Wei Wang <wei.wang2@amd.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [Pkg-xen-devel] Bug#684661: Xen panic on 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>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--=-tkzN+QYEI59Tez8y2Lgk
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit

On Mon, 2012-09-03 at 16:57 -0700, Joe Julian wrote:
> I'm also getting the same error. I don't have anything with serial 
> ports, but hopefully this will be of some use.

Thanks.

Wei does this give any hints to this bug? This is the Xen BUG at
pci_amd_iommu.c:33 one I CCd you on before http://bugs.debian.org/684661

Joe, are you able to press Shift-PgUp to scroll up to the top part of
the trace? (I must confess I'm not sure that works for Xen, perhaps its
a Linux-ism).

Looks like you are already using the vga= option to increase the number
of lines displayed.

Ian.

-- 
Ian Campbell
Current Noise: High On Fire - Speak In Tongues

QOTD:
	How can I miss you if you won't go away?

--=-tkzN+QYEI59Tez8y2Lgk
Content-Type: image/jpeg; name="IMG_20120903_165005.jpg"
Content-Disposition: attachment; filename="IMG_20120903_165005.jpg"
Content-Transfer-Encoding: base64

/9j/4AAQSkZJRgABAQEASABIAAD/4QJgRXhpZgAATU0AKgAAAAgACAEPAAIAAAAESFRDAAEQAAIA
AAAIAAAAbgEaAAUAAAABAAAAdgEbAAUAAAABAAAAfgEoAAMAAAABAAIAAAITAAMAAAABAAEAAIdp
AAQAAAABAAAAhoglAAQAAAABAAABXgAAAABQQzM2MTAwAAAAAEgAAAABAAAASAAAAAEAC4gnAAMA
AAABAGQAAJAAAAcAAAAEMDIyMJADAAIAAAAUAAABEJAEAAIAAAAUAAABJJEBAAcAAAAEAQIDAJIK
AAUAAAABAAABOKAAAAcAAAAEMDEwMKABAAMAAAABAAEAAKACAAQAAAABAAAIUaADAAQAAAABAAAJ
rKAFAAQAAAABAAABQAAAAAAyMDEyOjA5OjAzIDE2OjUwOjA0ADIwMTI6MDk6MDMgMTY6NTA6MDQA
AAAB7AAAAGQAAgABAAIAAAAEUjk4AAACAAcAAAAEMDEwMAAAAAAACwAAAAEAAAADAgIAAAABAAIA
AAACTgAAAAACAAUAAAADAAAB6AADAAIAAAACVwAAAAAEAAUAAAADAAACAAAFAAEAAAABAAAAAAAG
AAUAAAABAAACGAAHAAUAAAADAAACIAASAAIAAAAHAAACOAAbAAcAAAALAAACQAAdAAIAAAALAAAC
TAAAAAAAAAAvAAAAAQAAADEAAAABAAAOugAAAGQAAAB6AAAAAQAAABQAAAABAAANaAAAAGQAAABT
AAAAAQAAABcAAAABAAAAMgAAAAEAAAAEAAAAAVdHUy04NAAAQVNDSUkAAABHUFMAMjAxMjowOTow
MwAA/+EHy2h0dHA6Ly9ucy5hZG9iZS5jb20veGFwLzEuMC8APD94cGFja2V0IGJlZ2luPSfvu78n
IGlkPSdXNU0wTXBDZWhpSHpyZVN6TlRjemtjOWQnPz4KPHg6eG1wbWV0YSB4bWxuczp4PSdhZG9i
ZTpuczptZXRhLyc+CjxyZGY6UkRGIHhtbG5zOnJkZj0naHR0cDovL3d3dy53My5vcmcvMTk5OS8w
Mi8yMi1yZGYtc3ludGF4LW5zIyc+CgogPHJkZjpEZXNjcmlwdGlvbiB4bWxuczpleGlmPSdodHRw
Oi8vbnMuYWRvYmUuY29tL2V4aWYvMS4wLyc+CiAgPGV4aWY6TWFrZT5IVEM8L2V4aWY6TWFrZT4K
ICA8ZXhpZjpNb2RlbD5QQzM2MTAwPC9leGlmOk1vZGVsPgogIDxleGlmOlhSZXNvbHV0aW9uPjcy
PC9leGlmOlhSZXNvbHV0aW9uPgogIDxleGlmOllSZXNvbHV0aW9uPjcyPC9leGlmOllSZXNvbHV0
aW9uPgogIDxleGlmOlJlc29sdXRpb25Vbml0PkluY2g8L2V4aWY6UmVzb2x1dGlvblVuaXQ+CiAg
PGV4aWY6WUNiQ3JQb3NpdGlvbmluZz5DZW50ZXJlZDwvZXhpZjpZQ2JDclBvc2l0aW9uaW5nPgog
IDxleGlmOklTT1NwZWVkUmF0aW5ncz4KICAgPHJkZjpTZXE+CiAgICA8cmRmOmxpPjEwMDwvcmRm
OmxpPgogICA8L3JkZjpTZXE+CiAgPC9leGlmOklTT1NwZWVkUmF0aW5ncz4KICA8ZXhpZjpFeGlm
VmVyc2lvbj5FeGlmIFZlcnNpb24gMi4yPC9leGlmOkV4aWZWZXJzaW9uPgogIDxleGlmOkRhdGVU
aW1lT3JpZ2luYWw+MjAxMjowOTowMyAxNjo1MDowNDwvZXhpZjpEYXRlVGltZU9yaWdpbmFsPgog
IDxleGlmOkRhdGVUaW1lRGlnaXRpemVkPjIwMTI6MDk6MDMgMTY6NTA6MDQ8L2V4aWY6RGF0ZVRp
bWVEaWdpdGl6ZWQ+CiAgPGV4aWY6Q29tcG9uZW50c0NvbmZpZ3VyYXRpb24+CiAgIDxyZGY6U2Vx
PgogICAgPHJkZjpsaT5ZIENiIENyIC08L3JkZjpsaT4KICAgPC9yZGY6U2VxPgogIDwvZXhpZjpD
b21wb25lbnRzQ29uZmlndXJhdGlvbj4KICA8ZXhpZjpGb2NhbExlbmd0aD40LjkgbW08L2V4aWY6
Rm9jYWxMZW5ndGg+CiAgPGV4aWY6Rmxhc2hQaXhWZXJzaW9uPkZsYXNoUGl4IFZlcnNpb24gMS4w
PC9leGlmOkZsYXNoUGl4VmVyc2lvbj4KICA8ZXhpZjpDb2xvclNwYWNlPnNSR0I8L2V4aWY6Q29s
b3JTcGFjZT4KICA8ZXhpZjpQaXhlbFhEaW1lbnNpb24+MjQ0ODwvZXhpZjpQaXhlbFhEaW1lbnNp
b24+CiAgPGV4aWY6UGl4ZWxZRGltZW5zaW9uPjMyNjQ8L2V4aWY6UGl4ZWxZRGltZW5zaW9uPgog
IDxleGlmOkdQU1ZlcnNpb25JRCAvPgogIDxleGlmOkludGVyb3BlcmFiaWxpdHlJbmRleD5OPC9l
eGlmOkludGVyb3BlcmFiaWxpdHlJbmRleD4KICA8ZXhpZjpJbnRlcm9wZXJhYmlsaXR5VmVyc2lv
bj40NywgNDksIDM3LjcwPC9leGlmOkludGVyb3BlcmFiaWxpdHlWZXJzaW9uPgogIDxleGlmOkdQ
U0xvbmdpdHVkZVJlZj5XPC9leGlmOkdQU0xvbmdpdHVkZVJlZj4KICA8ZXhpZjpHUFNMb25naXR1
ZGUgcmRmOnBhcnNlVHlwZT0nUmVzb3VyY2UnPgogIDwvZXhpZjpHUFNMb25naXR1ZGU+CiAgPGV4
aWY6R1BTQWx0aXR1ZGVSZWY+U2VhIGxldmVsPC9leGlmOkdQU0FsdGl0dWRlUmVmPgogIDxleGlm
OkdQU0FsdGl0dWRlPjgzPC9leGlmOkdQU0FsdGl0dWRlPgogIDxleGlmOkdQU1RpbWVTdGFtcD4y
Mzo1MDowNC4wMDwvZXhpZjpHUFNUaW1lU3RhbXA+CiAgPGV4aWY6R1BTTWFwRGF0dW0+V0dTLTg0
PC9leGlmOkdQU01hcERhdHVtPgogIDxleGlmOkdQU1Byb2Nlc3NpbmdNZXRob2Q+MTEgYnl0ZXMg
dW5kZWZpbmVkIGRhdGE8L2V4aWY6R1BTUHJvY2Vzc2luZ01ldGhvZD4KICA8ZXhpZjpHUFNEYXRl
U3RhbXA+MjAxMjowOTowMzwvZXhpZjpHUFNEYXRlU3RhbXA+CiAgPGV4aWY6SW50ZXJvcGVyYWJp
bGl0eUluZGV4PlI5ODwvZXhpZjpJbnRlcm9wZXJhYmlsaXR5SW5kZXg+CiAgPGV4aWY6SW50ZXJv
cGVyYWJpbGl0eVZlcnNpb24+MDEwMDwvZXhpZjpJbnRlcm9wZXJhYmlsaXR5VmVyc2lvbj4KIDwv
cmRmOkRlc2NyaXB0aW9uPgoKPC9yZGY6UkRGPgo8L3g6eG1wbWV0YT4KPD94cGFja2V0IGVuZD0n
cic/Pgr/2wBDAAMCAgMCAgMDAwMEAwMEBQgFBQQEBQoHBwYIDAoMDAsKCwsNDhIQDQ4RDgsLEBYQ
ERMUFRUVDA8XGBYUGBIUFRT/wgALCAmsCFEBAREA/8QAHAAAAAcBAQAAAAAAAAAAAAAAAAECBAUG
BwMI/9oACAEBAAAAAcGbJClGZOEgwkL58yLkpC1mYILMcCXyJSu61EYBAEAtASsgnonoEEShw6L4
GY6GpAUQMIUEqLk2Sk0qUSV9VhPRJr6pbAJSZvVq59C5GsiUnl1UhREjskjWg1kk1Nz7cy6JIA0B
aFDglJcEkSkpUEKUQMKSDSRgAgCStKgZGkuiQCBgKSZKCiSrkolICQFJUQIjJSDBo6BIBgSLVKer
wycGjoAZG05duHJJdevNShz7dlMua+YC3ThJdkEZERjn1HNYJHQ+XRSeSujdam5LT1WrknukjIL5
kZceCEGkGSx06ISsz7LS2QRJNTvslHcuRrHNRI6q5LQRdi5dS5dDIlDiTpHPoXPoAQUhY4cRzSEI
MAGQMgDHPqgKIGaSMJC0gwQAMgZhJpJQUQJSVGlIMwgwlaFoWkJWQAUCIAphnwPo7JLhJrBBJckG
3JKiWS0qLqo+CEJWA6WpPRPM1oJaEmCCkp6HxWEdCPka+SeaunbkglAzQhaUgJ5cyIAEYMwZGFAI
IiMGawDPmolICiCTBAKSAEgwSiSSgRmgwAZoMkGEgEYBAjMECMAGACAMgYAIAyAMEYBEoAgDBGDA
IgDMgAQCgCABGAYIxamTVkhYCiWDSCIhzBAAjAMwoIIiMGoKIgkKSSiIlEZpANJmlREACAJQBAyJ
REoEAZAEAYIAAEYNSQRGDIGQMEZkDIjNIURKCTUgdEkZoNaS6oPoOfQFy6p5AgZAwQBgAgZGAYBA
gYABAGCAAMAEDAIGADAAIAyABkADABEYMAEAYtzRhFk4dpIOXXfgln2b9kxpEYCTMxPykZCcAAFS
Fngo21Iq8xP1TnbIaDtbioyVmqrK5MqtZpGrXNxyoknYabEkq2WiOpPa9Ut5bKdH3iOqdulqHFkQ
BkADIyB99Jna3nvIIAVaNDpNb03jm9wtWbI0ur0vS3OZWO855FadDUHQJzMpPRKTWNP5ZZJ6hXqv
ptV46AUHNJTULYjIoRJAAgYIGRgAAGQBkAAAAAADIAwQAABggZAGRkAZAAyMAgDIyUQBkAYt/OOh
nGhkaXXW2M+ElVp/OZd/n8cgdXhN+vdWjcZXLFOa+k+unyXCDtPGsWo4bs9OBsbeBny4NpFVesrV
j2irtleht6nEu2WoVuz53z1HPbbGSLASURMsW2ZcUEaTBlOWFhHPnsPPKuuRz50hIf7FVbnEIdtZ
WqWdFcszANnUhTbtHw080eV6wOqddo2OeQpT9duFQt9GibRJ0oamzrM9V3fGiMACMAjIKIAGpABg
iMGRggCMyMGkwFIAUQAUkAGQBBSTBKBA0mDI0mZGZEZ3Js1gprYsjf6X0zLQ4uv6O8PKK/rGb1tI
vlnZQFq7VesW+0ZPNoqKUyey0a7lBO5BdSt5022iHRKOqdcSqk/1bxEzlVls9G1WmV6/xPCaJ7T7
DM0a3VS5IrM304RMxkLFJkACc7FGKg9Gioao3ynVh8qEAktsqts5w3d13qtuOqWVDHhLOqZbk12W
6ohbP2pdtEE9jSn8k1ysWbP2t5z9pokFYlP6jZLDldEJaQACAUkBRAKIEYCQtAMyJQBpNSSUEgGA
DIyIzIlESgSkqIjIAyCVGDIAAro04QNg1rIj2HnlulxVP02u27M63r2b1knGw0qJVqdM4Vib0DLW
/SIQchsdOuaIbrIHVbkdPs6Y/jKu6RdiqsysoOazzS8yi9gozfQMrVq9Buq4yTqtwp1y5VyaM4Ca
ytggAkmpxuGeRPfVsr636lRcNZO9LJMptFHu3CM6d5Oj3U6bbmzVtJPaXcWsJNcXdcsL2k3JtGd4
vnYco1qvWfPrdDZ/ab7k+tVOzqI6pnyAaTMJURgAzSDIwkAyUQBGRgwpIMiMgogCBmjohSTCDUAD
BkCAAAMAjI0dE3PkygpfTqf3uraDtdcfzGdXij87hncSjtqfBELoeawt3Ow5ZKPKVwJ1oczyrdk7
1Sedw3CfRUbW4qctJxcTa+VQtb+lxOjZUrYajWdKZR7t24rlib1/pY6xF3ZtR7lKUKrNyQYCg40q
fb1y95bG7A3VkXbtXEF0uN+q9W0RGf2uz5620iu06+OKFL3WixGix9Eus5nfW/VOuaJwz+9y+VOd
KrdHvMXUpm551Y78zplxZNs64kZpMjBqNBkFBIStJkZAwRgzIEDMAl81kZGgzBKIlAiMjUkAAJWk
lJMAAGkGLnwZQarFIo4Kfya2SKzNwsixh0hcvYmUZOwEdNykRBhKUmHk1GNZUoxzJQyZVg1kTjHE
jFJkeLBy8izdMeshyYP3TFMhxaOkcebxpzd8ePTsz5cwSkqSOnV0OLhvxcdubfmggZrcp5rVxLsh
HUuSlAjJKlJT0IloSsIUvmXZHEunFXTmOxoMFxIkmZkZdO/AdU819m478E8+gSEqJQANSCMwRKSo
GbpHFwlu4Xx4kDCTJZAyNCgEqJSQDMiAuTdpCE7fJTzfuTTybnx6HHISZyElDN1pAJACpOVghPx8
ZPda/ITFfjiSQIwRKMgoISsgAc9Yqpxt0ZAWR1U39lrcCCNBgkkdksVVhEmOikESrJbalFXuPptw
laQ6utbqXAzNJkYBgGgzM+ZLVZr3TYLQ+FBuVjzw9BrlAbqSSgFgIUQSB3U2I+ltvlaqeiHnNus1
DbaBEZo1WgwDBKUpISonSWhqJYXOaGeaXWwZ3aX6smZpCgRkDM0AgAoJMKSaVEV14M4NV9fxsq3e
zCV9YjtWG9kocOkutr0TJm5tuc8xigJPS1RpynKBs4rVi4ts4jySF8zMd5oox85imdtj6+kS+osn
HE30HYI1pMRMpl8QQIiNJ9diTWoh5EwlzTTUFLa3AWONTIRspDv3EBaMorYJRpAORtLdq5mYCs3p
efpOQ2Kn3uIaPifVa1pqVuzanmg1AiXKX3pTpawwVEuM1mCer3ZqPfGUaJF/QdBaUy7ZzTjIySZr
mNBcUmbn4DPrhN5cQcX6wwM0xklyNLvKKPc8traDUEKBKNICTUgyI+iUmaTF24Nq+/2/Kk6u7yy6
prV6lF5hTNZo9Q5nNadNZZeSq9Kv1ZroFp0iq3PpS7UcSmX70u4ZBDpSZJUR6Jd01OyNIOgWONhE
nYtWqlvFXsQaRk+4pNxyeAQkkGYEltlYpmpNInOZJVdIp7Zqdc+dbmuhwVhc0q4ZVUkpBg1DQrU6
p9mZx2fdO0Ok5Pbqhc20S8cdq3bCpdqzmkJAABix6nWYq2NYmjJdRnNUntNXtnKBdu31NuaajZKD
RiBkAo79as7fW7jX6iXWP5rlNybjnXZzp2qtyZQdgx6DSZGtKQFEZAEYBAyMyIxdeHCvyO3ZGw2W
TyO98aVoMVaaBSNcptL4r1lFkzK4FU6tJtIwdLPplVuC6bZ+kXyl3tIt2QQ/NBmaC6bA6hoGckql
VJ1lCpVP6xTbsdSsa2kRZO9DvGWVhJoBGSnG1VGm3WyVaj2JFWITWyUi98a7LdelctDig3jLKmgJ
UZKVpkrMUbjcIXObK5o/NUjttGvDaLdnKU22rqFozmnIURGRrmrfZ6jzsgyizy2cc1PtirlrjkoE
xULOmFm86qvMGRgK0C4Z09kpJ7kVqlsxCpPbs57Sz1TWfq88/wA6veXVhQIGRGokgKIlA0kogCBn
cuPCvvNbrkdorKJnow5Kj2quwmiZtAJ6ak7l6LPScHm99rlaJUlpDuL5zJVW1dKvNPorNWCVJNST
Xo87zr9idxGaW6JrKTf6LOV5jcGtNuD2kyFngM/jEpSoiM5Ta61QdPexGXT/ACrXNXbQrhVILQo+
iXWbz/vfapn0ckEZdEdLTp81ldkloXLnrmtoNdu0OrVXSOWe2m0Z7x0at0BkkGRGDl9UTUpifgs1
D+GQO81otUrWgIoNgtlFb36CpLdBkFJNUpo/enS1ggM+W5jUDverPB0y9taVZbFQ561RGfsSA6Eh
SDCTBGAo0AwkjM0XXi2gROzrLoymnvdoygJSN7dK8jkJiytmMk6r0MvlzMhLzFfKxRMfMdIJzNQT
PkSiSokqfzAiZJzERyVciC3knHc5Nuzd943rIR7blyMiURjvJJZO3TaPQEAz7vUce5tOjhsh3zbc
0pIJ6BVuvrzOK314tSBAEt0kgrmakks2vIwlRGC6LWQBc0mQJQ7ECXzJZkS+KEqAIKBdlpCkJQaT
MdFGhQI1IMxxIgRgLSAQCuajSoEDJJmE3Pm1r6Hknw68nDp1w4NSIu0UlCpRZnGkhBKSRGagqUaN
SAMjnXVa4pMKl4vmZkYIkKIBaAoWeUqzAJIyI0HzCiMGZGa0oAOXuVahL7wpVmnqUL1X+0+wgLUu
j19JdLFaavpq6DxuVLVb+dduXOGoWhc2ExmXfSH9bgNCq1CSvgZAjBmYMEgzIjMGDBEYWhSSBGRA
wYWkAwlRBKiUFINJqAMglJqMkgAzCDMzSCWCQZpMC5821fTfLDWLdBznZ0ENyhIS40CC5npD59D0
jq1SoMUEbt63capRarICNdPuFqt2VR7Il2fT8wh+/eMe94fvJ8ouW7QzIG52xlU4PrGKlWfJ0mGa
p6TLhcLPdYZ914xljOB0aXrVf1mr0LWo2pSVoibJRrxTou2xFceQQ155TJiDs3So3LPOGgVJr1u2
Z61SWelZRWbR30NpT7vkybpkiAklglEZEAADAAMAyAMgpBmkGCMyIyMAyCTUCNSARhQUhKgCMgSg
AASiBGRgjBGhSLvzb17tumewmvyebTklVLXYVUHONTg875pse0dsqvDqC5vF5xXeb3WnMS10Go51
pMrnF26xcDo8HRqintqF9zZlfCpsjaaJMv8AhC3VdOzHiU5uWewWoco501eiZLOs449tWtHOt2eK
g7G3k8wthVDT+GUXHRscabRSKBrMnkur832VTExV9EqnWfkH1ItDHlOUa55DcW+eutJrqNVxRxr8
Nn0bo8o8ptqzKozNc5kaVBJgGSkmCMjBKIlEADMiMEAoggzMjIGZKQoEFJMjAMGSSMzSkLNIWRpB
kDIjNBKBKufHhX++95tV9hseTWaSz69M7BV811WFzzgUxui8/wBErka3lX9FonNzpUnXKvs+aHoj
+h3XJG8psdfyOG4KntlyU9Yzpxde0BN0CDu1mrkLR25SO55lXtvzrroOXaX0auK5lDNWm2CjFdHW
f6LB2zMrR0od+4ZZZtWxFruGe0zR5zLNrzTSIJxQJDR8V7PbNfqsuCu3XPdBgGlGjL/IZZNbFhUz
rEByoTnW+dJueWMrflvIAJURGARmSgRqSCMgRLAMiMgDUhSFpMgYBGAoiBpAUaTMAjIyABAwpJkZ
AAJURgJWdzb8K/015nV9Sim/Xpwlqi+KjaXQqnzPQbi3EzVS4Szul0VD3UJFGYakiIsKYedhFxts
iq7QOBy2wsIO9ZI21NulCiirGwr+ftkz+257A67nlR1g3jZh3YZY07a5NZBLaK7plseReTsC67Pw
yK56TjzHaaLnuuymPaZJkxm01yYVX80ummZ/ceVURbqfYJpOdOlZ3e9IyDhsjKi3XvXavolbzlNh
qnBKiMEoiABkAFEokrIjAMyIGRGZpMEYIjUkwSkqIGRkYBLIjBJJYMjBGlQJQSQIEoEBzvbdrBc5
W3w8nBTsg5bsoTtzbSFX5oOwqJ4+dwTbsuKiwuzykJBzEhDTfHkUtGEtu2hkkqf68ZGFZTKwzmG0
ROCEYJS9nGTSZYxcnKNOHNBR3JUu7hyl+zPX43N4nihcv1hnT+ObyzeOkO8b2f8AHm6TwLq2Zd3v
BwppwdturgmaA27vOTZ4vgOqOHYmwHMjJHVJAjUFcjPmakG4ShJmrpx6d+XLsjiYI3A4dO7VTjjx
dHxdI4uFtku23Nwnm6Mmjg2i3DUJU74t1ug2cm3T3boI0kok3fi2geDmVbu2Uh2ck3b8ejdxE8iN
KzNZEfMB5YIuPsSq9ITMDwsjES7SKnhXIvmBJzkLZ+ld52GAirAmvqtEfP8AVNTsSK5Z38I8Y1pP
Mw4uLKs2l/T3lshJexViJsnGsWztVayYc3rlSrLPUld3gYq7ilQCFpJXe/P89mrhS4rQo2gtyN7o
6c6t9qzlGj1um6K8qt2FJtEpW6to0DRdGk881BBZBeLFlUIpEnqrfKWxvdDsWd2qb5ZzoasjjSU9
1lxlFtu9BhNTisv1CYp9uRW510zouiNc00mSzbUGchi2g2LI5rQKRnoLUZPGrNpgr0n340XQ4zJ+
IIgCu3NvXuVyvVIvtTtTaX48nUKmkaFRKryI0qBmQR0LTbnVqdrLHMNLd0Nzd4mZgp2urk69SzZl
rcvT7AzQ75c6FrtZyy5alnsxD3etPe0PYazZI1eVxCAd40eDzzX42h2+WrsHpsO+hpmJYunGbyEf
bbE5g56Jc9mE5TeFmjKo6gm1khZq/tOcpAWOJ4zGc0bn0tevVSi67AQjuzV2pbTR7BGI71U9MYVm
1xi415R+GvY/sNEgZJWfWrWs7Y2ZrE6BULurP73whyZ5MjpZNuyyM0+CrL++5tFbZmFlka3YM3lN
J4U24tir1hyaR1rJdhzSF0PjUZibrsfr2UctAql2GcaHyptszqjkQJabvx4V/nt8DSdcsdAK0VCZ
uSqdk2i98nagc1GCIwrtt68wmdRyeH2uk0fSpfNNLjZ3KjvdQu3OCe2NzTbC3VI0S8ZNeEU/UZCj
Zzaro6hJA+yZWq22uZVCF11q34452rLqlskfltx0TILvJOqFFX6m3yJXIx718qr3BdLteb9bTTtH
q/Su6VwrE+yne9Luzauy9NzJv20LV8RZb1n+ca3MYnYtjxWwXVFUpGmS/eq2RUby749p0bVtvymt
a5P4651PDNLi4mZtVbtbeIsLWEexuMhVv23EYHd6xk+nXbBpXc8bkLuzZZhpVtKnXDg3hp3G9Xq1
b3XIqbtrbNdxZIod7YZ/JW6TTWrGun2zNqAkiUDuvLhXk7nWKJqt5yt1ac+ski+j8j0GRyFrzMGS
kqIx22g8ks2p4xH7pQaHp03k+zU66U+foaNQx47NP2mrOoS096NdshtclRrbcKzQNbzK8JcRuf2H
Ra84ls3ozfrol7xo90yWsbFHZda9OxbWoCdZPaQw1vIW2l8Hzt1TLr1odxgXeeO9Tw9zqraxUiai
rA9z+/tqzMVTMeK7hsODtN9zWjajN4vMbjhui8FPs8VsTWn2vhziX9I0zDum849MXV1nbDXMD16A
r8loFOuD7KtOiuSIfKknZdzwJhu1JzjRL3gc1umG22yQFnpjHUIhlNQs3BinargMju+L13aoWibv
j8iV+ZU2u3uclsr02KjJnNqWkGRpvLbhA8tYkKFrEK4ZTEZJQ8XP5jqFUoPBKQYNJgx12zrkNp1P
HYvcqRnOoTuSao0m2neKKXgkZjatRqE+0b8ZONomlv8AKIfaISlahj0xoK87k7TBKufDLKjx66ld
cXebPl1P2ljkt50LHbdYusbYYlBmzp2gc6BcZilld4jjZmcTKpiTlO2e3N3nU1barW9KZZTBc+ui
6bjDLb6Lm2wyeJ23U8d6alxpNrkK/TNJgaBo7zMe9+yOb2DPqvrEYyZXjJH2jc80mbbnFltUbm+g
DMY1HS36TmsFrUXmOiz2USukUKD01dFsk3W6lokHTru/z3vcM6l9OpVS1PlmV/sFcr2lRVCvRUO4
T8DTtAg6G0BLSpF44N4JpJ3eCm61ZO8hzimDSQhZuqNUkkyUQCVH0u51Kcm6lzt0ZXLQ4q8jPM2s
sqH7voaBlpyGllwPGchEWFcAzsbeIkobnPHCzbiCczbSvNkdJiRhU2GLi5xcE/k4Up1EdJ9GjV80
jJAR7h9FolWxSIZh5G85Dg2PuxJ814PCj+CFvHzHi+Jm77Mg8aoc9mqlJb9U81dORnxPuOXY+au/
Dl2Ph37NB1IuyGiOfTq65cXJturhp078OL7lxcdW6HzJLxLLv3YqkGXB+TJ31aiSY83JMOzninu0
bpNAIxduHKCZd53g7jpJb42nBv3j38U15GRgjNBhRz03XUWSMh7B3rMjO19tZGkHPuq47sNdYWhp
BzMpWVWSFirSitSszWE2iJg7WdVk7FV29vjK01SJ211hjcoyt2WQqLm21yHuzap2WWp3a3V6AvHO
mWGxUkrrCVq696ROWemMr/B1K9O6JcJiKiLhwzeHSp9pnDOLhas7Ro1cpmjvKteOdMtj6t5zwCpj
UqBc5mu03S4PNbfc8w2IKy2/06C1dxT6ZrGdv732ymqJ73bRq1RdVGVXyzZoejQOf6i5yi623OuO
hxOe6f3yu43GgR2jRea6e/yW5Wuix2kQ+c6e8yFvrMFB37NqkSAaFKu/HhCMLfpee6BVLdEWdq1l
KxJZho9RpbUgAlYCQuW2BxB9JzhU7iKpYuscznlU+4Kq1hUyj58qhc+ddle4grIqoW7lFOHXasWo
q1Zm/BvJd8tqfKQ2riplIuqpam8XKc3MPKdq1amLV1ykYCbEJOx/dHKWgJrlGzEXJNeMzWZ1ocvn
2k560v2e53yXa9pqefbDEVOUs9dp+00yaYmqqP7dmk3HVrVbrlOg5lp8RAWfO7jZfPth57DGw2bc
J60SdN2HJLYxfxGSokt6omjRsV0fP870htSbw2j2s69zjTWtEvDdnGWdxm+msqNdeDeHtfbNNObU
e6tWsXJMLtUpmpUeu8wDNIvPBNfa7OvK9YuNNrWhVLvoCIPE7pacYYclJUCBpUd21ul3lxRLccPz
nOlJvApln6MYyy9KPdyqks+5V60OKJcxBOZE6pcetIuCYvjOKpd1VTbRQM442Lb6XeE1ib78q9bV
0e7CuPnh1m3KpdxKE6yKqpb+lOtIjmc72pV5TV53qyi5SOeT+K2rrmULy6aXrOHsd6z/ADXZZLD7
Js2K2O4lUK7eqJpFYNzcXtEtMRLCqWOiQWyeenGqx1pR2zKWnstYbvn1jl3dFzApT0FSr02gJF05
pl6b0+2pgHMo6ol+5022piBOdqDoHGm2xMezsPSjXzhTLaUTwlur6OdVexYrWFJSa+d758IJnt/H
KdG07O4XQ89e2ps/xK23TFo5BJMlESgq7azVbmqm2lcc0m10y6LqNkU1hrE5pNwVU5pwVbtPaj3Q
QDmRXUroVLt6onjNdqXdCqFipOat7Ht1GvZVWbdIrdrcUS9ca9IPSq9v7US5FBrletKvqKXbUxza
dcUO+ClWkcIaUx2R2erjPYONSq57T5/a7/mlD1qUxad3LBNNbrml56z1vKWDSW1+mXTHtfj6xYqA
113AZ3WMM2SsWLr3zRvCbnQ7XByLDH0yO81S5Q3RLexUy08a/aoZ01Kw0q0coO0QUlHHYaZaGsTY
YKchlz9Os7GPn4CZj4zN9aEvnuh5RSkmAE31tyg2OmW/NNTjJKu26vSKKPoOPaLH5lw5ERGtAUDn
te7x7aUc1K0rrM13aRk/1p9p61uTfNoOyqplt61/tLpq9sVTLS7g+Nj4VG6dqZNyETHWnhmFY4P9
YnIuEuXCmXF5T5Ceja1d+VGuLyri0xlVvaKLaperNrhF06/9qDZZ6qRN+YUHQHebyFzr07KJzXOO
XbTdOxOP3SkZhtD7Ebhq2NOtMFXuzHhA2ONyTtuFMlZGv0jToDPNbmqHUNKx65aSyqV6TB1vQGVF
v7bM6kfSy6nTKlpKM3tFtznno9bp+hdc8nrjnzXSa1Ur68zmau9Aa6NW6df3uczd4z5pocFT706z
3hpbit3CMzeKQDIC9tEwsY+vURN1exrlkw7aImqzZao0RzJSDMJCjXYLHVU2mHip9zWXlirTays4
OXfVx1PQrKwca/LyFd62GJjJ4oJ/MQHKxRsVYBBupuDa2JlBtea5GyRLGd5Q8hIwJzkawneMS7lY
TnOMY6VXFLmojhMsGEk4ijlI5rLcGD1zFuH0e5cFFx3NUhIx7SY4x77pHdHzXk8HPuSW/Xg2U7NK
+XDuTfr35F15oUaVdEI7JCjbNyV3d8m7noz7OmyHCEPEtHfViHjLlIc0Oz4MnyGJqW+j0B+GT5DD
o/4durVhySRkory0ENFrnEyEXI9HptSjn8PKRLFPNRJURAKMO7QmuT7+sd7HDxdkKNsXOvz3aDg+
aVd7TA2F7BxdoioGSlYS3dGHR6VUhycXZzzpMtL1GN5nNWyBiLg2q9hlah0t0DBXMqfO2KmFdIKu
3UUmwWKncL3C1K6uaPN22lMdAhafenmfsrquraJW6ZxSqQ0Ys4udrzU9Gq1R0nrWL2mj299U865m
czq+eXiRr1T02vZrdbXmWy8orImZlLbTl7PWcun7keTVhYmNgGOaVa8j76bXcy2TtWbN2pNxVE1j
RK9nutdc31qNc4bsTvFYlMvvOKVjtpNxyDVu2MNtpqVgeOcOigAlRXtsiIibLq2faPVrXAXCGXN0
6dyPQ4jN2hGRAGSgR3LXYXNtaGbWC21um67EdicRRo75a4Zx2o6Dml1gZSOfKzLTHWbaxRIe1x9w
oFYUNJirzjeo88+oXN9tC3MBPdapbW0TJBzBTi6zaWjTsUhXLAiCsjBXMpSu2DjDz0Y+Zqkq5YGM
bU9jhIZ1l9c4Eu47XUc/2GFq0xZq3TNspE/HdeFae2zMp6Nreu2/Kr/mmoRtWt2ZX2dxHc8Zr8zc
GWfXTU8p5bVi15iJuqZUSrzs2UwO2USu26Zz7htOQ3tl0jafZNARnejNIDs0zuw6Xku2427t/TNN
jjsde6pKVlK2sJqNEtdJuuN1IkmojvjVMHF6tb8V0jSa3nesVKN1Lmzwma0rDYdJkkAGYCtV0XJG
e451Q9iTlti07JLq7e0mraPXbJ2ZRd1kqDbYeSc0y154/tmZapAwNDnNRgbcKZm94uGfbBnOfw3O
e3aoXbnASTrnXradJuZwXSWKrW9VJtyocpRxTLwmn2frGs57pS7vyq093Zxs4pw1QIzKqeXTUNcw
qP8AQGcZvtUnhNn2bEbXbF0mBv8AneoU925t7ygW+El01S05tHa5hGpd3vaVKpycpmNE9BZbdncp
mmaJXo2wefm/obMM42qQwa47RgGivn1Qo+m2d1QLsVck4ShaxmCdywLRmVIca7WbFxg7JC8pVfZp
XrTWrdhlaJABneW6YaL1u2Yldtfp1F1jP+Og1q04dI6vhUPyNJKIyIwvSdMw8t5y2kbGePW3WcS0
xnIsHtaqu0ZRFz9outSmaNe+1LtWeMtKx19IaXjurU1/dazBVvWMti90y+hNkTu9Uq8pr0m851e3
rpF1RCOZJVPugp1sTEHK9qZdTplnXGNp1xQNC4VGzG3h5ilWqSRTrLVcl49bttGAs/Q+VUXYX+JW
LdfP2qsnEl3zZtsWOseE7sFIuORa8xqdozdOs4FYWe2cqTG2GQdUKm7zmF9rdgqmUEu+7H5x7ehM
mo+yOMRtu3edNdavCrvHSI+Ds1bledUVasKtO6ec9T6ViN12r2k6db6DZkt7JAMrJnOj4zUCIyNF
+4coeJvOpZjorOYq92q8m6y7UsXvqspY80kAolJWlem6bh6N3zbPdsGOWnWMZuks64S9adu4ks07
bfUp+KkICc45vdLdnM8JXJ9fyiS0WFr8PpmKuNzzvMm/N9rNijq/cVUm3OK2uxx1WvR0a2SFW42+
MqF8OiWuVqzK7R1JvXahWicq8PocdQL+5zun65YK5Y0ZfQeStT0zEOO5Z/mm2PsMuer4u907lV7s
zYx09H44/wBrpU5IV2k6bXqBq87n01NVyNurXPNDjIxnf4ymX1jl9aR00a85I12CnZ/rXfILboGZ
o0jhRrm/p9f0Kq1bRE55OzedWy+Z620dFBts1UeNjbU62HSL5yVF2yHzhgSAAL614xMU4uzeTrVh
XKKiuVYstXstbjuKSIAzIzJVsl6qq4QkBcE1aTnK0dp5RU6bJhLx1b7W2KdP4WLn4+LtPeK6SkPC
TEKVo7V9pLwHe0xNd4JVJWKMYTxwMjK19FjjIud6wbqXgm881ipZxAu5WG4T7OFlXkH0mYhvMcox
+7heEw7jZXlBseapOTiOM0zYyC47q+YofG3cDjz7c2S3iS6ob9kN3HfitXMuo5ju05dkH34tuSVu
nLM5Dg2eKYd3bXjI8Wz1TJcjG8pPgxedY7vIxqJRq2kVR3SRjecjwYyYjuz6LaIBGQF+ZcoqIFgc
O4uQ7yK2SYeTg5eLjeA5hRKIJWRzNshYi0JrcxMVgrXEQdpXWJSbrnC0xdesjqtPrDXWFqY1yyvq
m6s9eibi1q1jlKrMzcXC2pNNiOZ97p1p01ZKk0u8NWre5r9uFUsEhAQN0iaxce9ZviOGfWyQob66
1OrrKR0OLpN3fUu+1Gorn7vmMcYkdK5ZzdbDnXfSqnTtPOsX1FDu7+n5rzJdh1PN9Fe1asaTVs5v
9iznaWsRHWnlXLkKxjaDtmrRGOMw50u80OB1JplmlT2Sz16qdQ1XjlelTuVTF7q9L1JGSaZPZfK3
iu0PUuuRaVPZhKXOuVHUuGSadM5TP2+s43zJJkDvnHhFQk9tFGuMVYoG6wqpynWTGrovMIpKDMAg
Rqc7LNNoC2lTbaIN1JIrltTTreIhE1zq1tFWspsG0x1qFx51udHOPm1VO2JhVMLnWeM7V8tZlZNv
jsv1JzSE32Dz3ZY40BEe0tsP0fV2wJh1R19xnX4vN7vLVemyEXocjKVmwNGMzH4y72Wzeda4k7nt
lRzzZYenzdorNP22i2WIds61K2PNZ2Jruv2/KdCzPSWdRuuUae9xrb8TjdtpdypFZttjqc9VrtAW
7Mc6Ox77mOnx1UtPPtTbz2y7UW1Vm+7mj6AeW6k3qU33eZ7pZZfp7SqzLzrRtL5ZdpvCpTfV3RNI
55dp2DVpC0AHfW/KLhtC1jBrdsEbkGz1auauE4Vw2bEK63ASFEDSuY9D0i69IBzJ86ndOtDuHSHK
ZVTLp1pVnXGtZ9VLuiqlPOWMdYOlKux1WXeN4CwZDeLZkc1faflDIaJsmQwm41HNtOsWOSWzZLOW
jnXqPoc13qtmVGcOmOaHL0rZsqpW4xmcarDIsELOuWUVIcpKAK0PsFpHHtqWs4Yy37Osz255hVz2
LCLrZ10OMvOfapTnDm3Ps9t8HIu6hbMqTqOGaj3fG3m8iTpNO1ZlxVVbLneUrtHoCh3nlT7SlFft
5Ua9c6nYi6Vm4lQb+ioWJfaoXo850BNQsSl0zROWe3oqha+PWpX3lnt/wKtEEg033giJhtD1zA5z
c4XKNgpVf1Sn3nEWu2YdW26TIGRkopr0HUrmcF2lBVLb1pdrVEomhUrh0pdl7xrGwdKRdxUp1y2i
bMdNuJ1eYdt67Y8eda7mEFp0ZkjFdu2/EYPf6XmOpWfE5LcsWuz5v3yuwaqdOtKoxt0o2iZFz3bH
afucVRdvwtxrMDYezeDm+cXac3faRhVE49L3tXntt6KyahbJIYXatz886/EyT/pm/PYcYbNp7YqD
ccn1vhSLrlL7R8MnU7IjLtCzq5QFP3rHZO1Rc9nGblP75SbgxZy0TPViSkqnbYrhKQVorMhIVa1Q
jt3XbXW3r2v2WBkHlYt9e7uYKzV+SdVi5VnvIwM/hUIaSUg9AaoiIezbNntrevq1dq28lMe1zHrN
PY0w5ICTUSkmHuvzaq1aelTsfWJTNFULiupzUhEsLGVSti6zMP46EtQp1x61eQlY6HtKqXb+laeK
m647kahlzUtC2LGoDeKrk2vT2KT2x5BJ3fhGOTd1y0Maheiz9F8xSc2zK6Tu8dk+ycmVavbShX17
ndvnmGNz+vYxQOfTV9Kw5vvOd5puLrBr9qOKTWjcq1c2kdHzsZjkvttDsLyuVDTqtn+xymc2aUrc
fcY7KLxEUzX5ms0HVYHLmY63LRM+h9QhM/vUzm0joFGgNIYUK4z2dub9S4XRGNEtdkzrpodPr2ht
KLbLBnnW91ODv7CmWiyZ05vlLrLcgkA780RHQfS2OXkJK9Zg45FSs1an4KIQhKkgGkGXaTtMXG2I
63Jz1YTaIeHsLmtOrBAtbKxgpx9XOlhg2Nk4wMvI1vpPw7CwogZSRgJGZaQ9g5V2J4HN2SBY2lrX
Z59WO9lhI21dIB9IR0NPsoma7QBy9ecWKOhbMdclJWPiJrlDS3aJfSTKF7zERFc1S0jE8ZxnGyi4
py9jikDauUo59W7Lq/5p6NR35tno4l34n1Q17lwcr4G44s0BTt4zS+4tpBDTu9jSlGjN8bB0/iFy
bJpJKju8pE8plmwkO8S6fxRTEa1kzipZ1FRXMyBA7614MIMWF+pt1eSfRsmAloSSYQ3DmkwRkFEt
MrcoyBs7uqP7FXGFuY12xPKq8s9ejbcxrVgkax0tMBDXDjVLBMVJdtr8LcUVGcnaiVyga7cxT2PE
5K8xFau3WlTNlp7W9wtXuvekTVnqDO+QtSujmjTNppzG/RNOu8hQEaBSuWhRtFv0hnsrdqVBaZF5
2yNVv0GiwWnMM30SfyqT0ejVrU2ea6BP5ZK6LS6tqvDKtAtmVOtJqVJ1ZeOTupYnY9MrWea46x28
XfMOOnwuJNw+1O7Z1H6bF5fq0nj10uVHrmpNMp1KYyG23Ol1zT+GSavI5PaLdUq3p/LIdXksptFq
qtb0njk2pv8AMb+1kfPjQiQYGgNURsDJbfV5R1IRFyiVTlXmsnlrDksLy5GpBgwYXstjKr3LnVrG
bNjYE1S4cq9N9GzCcOoW5Vcme3KCsx1K1c4WQ7HX7Qqp2lUM5dHXrIvPs7aONok3NdsyavZ+LZD1
zWbGmDnm6Gr2Qq1iTDTTboyduq7Y28FGazidoln9fsDTjJRUpELlMxzcprd4qfier2GnYGScV60w
okY6XrE93q9xhubltLVO3t6rdIpu5gE6d562Wm3iL5tpKVznSmtGvWQ570te85nprKlXTg3hLS9y
7UmdMuXDjW7s5y3U2VJuKDp997ZXqvKgW8Jqt+LKtZ5Z7dOXOt2jEtAvPnOM5KSDTobbnGwNr33A
Zbc+GLa7FUvWOvfDq1vWOUxqlfMGsJM3fpGp2vvHR9iOl3gqhY+7KJs6qVdVVOactoWzdqXclVh/
Jcq7aelMti4TvJlVLf1plp7Q3Nli8dI+hqva3EVwmF1K4ipWTtFs7AqmXQ6hY+jGOsaqZdkVic7N
Ip7lW2ZTo0VNuGsRY+1KuqK5IUzIEWL0NTbkmvSrrjA2jrSblzgn7tFct3Sk29EC+dKrNvKm25MK
5isp9DYPuNRt/OFcP3VKvJUq1ZPmq7nulDv/ACptpKL5WDpn2icKZaxHsbO4zjROdGuSG0PcDzTS
kUW4JYRF155zop5/d27KKnMB0TTfMjA0mQLQWqY6Ate+4R03tGL6zV6trFMvuP1XesgpDVJpJYJR
peej63aOrOMsPWlXI6nOOm8FaFU64rq0y54V22dqRcV1x9IFWbWqm244JzIir23tTLV0h0tsUjH3
oqpW7pFJmFU25nUrE4jWc31pd0KqWJbFjP8AWl3VNWnezSKkcW3nNL/DWHq1hrG4ol64V6XpOR8b
H6Co175VuW7Krtle55fGsQ+W7qVu7UK8tIl4qTpFwXS7tHtelfo2+Ylq9Vt8YORWOiWoVu05DQV2
XeqVbo9jNQU5H8bBUrFG85ur2WObztdmI7tKVW2xLOer03CyLyqXGIjrBCyURIyFMvEIwOF0XzdH
pBAC/cER8BK7jW+lmTGWiFdyeSaZnPS6Y5B8EhJgwDPrrVvXULb0rMtIxUXZF062d6vJSjGEtC6f
aHFfczLKBtZVC0OIETzSuWxdOs7qB42VlWrimh50yc6ldGtTuaqhYpCFjrYyqd0OnWV/BRdwbU67
LpU/MwcRdWdKvHfPXWnVasX5lQb66z+es1Zrmjx2SVbk81i7Vas6W0zbQJfN395qtS03ll18sGbu
dBp9P1Dll96s2Ynp1Toeq88o0q5VWhalUaPqHXKLZecxa6bWM0aK7Xq8Z0y02t0bRHuazV7z6L0q
Ap11ks7kr5RI3RoalXOSz6QvdIi9DhqlbZOhPbvSo6+Q1Vt76jXOZrFH4GRkDvzbkwr/AEsM3y4B
/Mk04ViegZZhBt08waTAI1KfXOPiJ15WHdhgGVlZwc3IVrvY4FjY+MBKStfOxRUTYk1+Qmq6izxU
TPdK++mK/wArJHws66qzDiH9saQk67rzqcgmlibQkw6gO89As7G2hpZ3ArnIhrPtYWUf1+Ql0QEt
yhpB/ALmYppLcohqlb6YYtJXjHu3cSqQaNZFDJz3Yk94t3SWzno1DjjxdJaPOvDm6b8H/Jq7W2J8
zYmXR/3YqkGXCU5R7xxHqk2bOY5xj6QhVS8eym+UPIyUIJuNZTSISWkYBc3DcZ7pASziDhiIGCO/
NeTKvKnp5l3aSkn35tIR/FdjrjbkkjJSVEYPta52plc4CBuAqczO12xO653no+mMVpVcWfefaVSy
KqJ3CsWmSb12wqrE3IwvTlTuU7PUlnzHW6ytNc3CrQ18aU22ytatfWrS0pD0huSuukVawTERUb5G
1i/dKtLy0NHW9tnTfUKLDabQ5O7tc1gAu6aBR4DU43MtLmcrmNFo9Z1aPzDR5/KJnRqRUtZZ5XpN
lyaS0imU3XOeQ6XZcnkdHqdE13nkuj2jLOum1jGGqpLYLXl56TB5vq7rHtDsufNdDZZhrDnIr9Za
E00Rnleruclvs/S47Qm2Zal3ya+ztKY31pVbgmCmGbzzpySADToTMmNdcbozi7m14T7TpJRTzOmN
9yeq8eRkAYBmJD0B0zqWvNXo2yRGTa92ip+vSsU0tOStShbbs1KnoGyV6ZRR5DSMY1StV6fluQZc
bLEu8fiNzlMEgeYl/QLTM7tPVKB1KGzLY2vB4y7wp2HHnjOB1DT86tlXtcN0eU3pN9Ycrfyg56hV
vcMv47Ril14S1DyZM3vkJY4oSURMQr95WbVGNpKOloCY7Vi3xLWTZyVYsvWl3eOYSPGTptx65/oc
VGPO0pQ78jP7/iVH6XfcM20hOdaI2huU69zPT22faJygmtleZXq/DO9ARDMbY6yrVeebaGmBaWlx
lOr8c20WGec4zJNUYYxz5KSZDQmyGVcmPS2Hx2+yWH6T2z3S5N7kOcbvnecNeYSojIKJVi9E0TO9
geZFP6xkde3emQekRLrIrz1Z2djX71L1l+wkxH8ioOuZLoPCJc2BENQL7YIG3VjLbhfMGrvAXbfM
zpe1R+U3m/43z3DNFXplGZvo8TKOOUVdZijWSMkelbladC3zPY3T4DtY7HVuloyuk77ldwlu+a5P
xtXoWm3nnWpZ1wgrV3ol45V2TdtYW1Lo134V+Re8q7bl0i586/JOk1u4lSrlygX73tTb1zpF0w6g
9dB2imXlNFuvKC7yL6gaDyo90KuOphxn+hpz+98YJc73zrSkZzfyrXWadZhqfHONCyRlpAYMcmjE
oBkStCb8mdblPTGOQHoCRxXQ2dM0qqXbP813bPs4Y8gDMGRkqX9HZvnexyWI2jZcOg/QlDiNQp9x
gizbTWWeS1puLN5Sbj2i+BZTuGUx7rVVxjJ/lkxqNblnOfRuqYdV+B2T0LktI3aNyC+aVhfH0FlT
+5Vy0MoKnavSKnLWe/12Yz3RDq8xH9aLC6fB0yAmtlcsHdDzn0Nmd9rVkqWOcbP6Fot7awkqrpXp
97R7s1hpIdoCwPaHeI+PdG/qlncUe8RjZzykarYnVStsSFcbDUZ3vWLVhtNVcd2qMyIOyQEw2ibh
VJng1mKvZuEHa4F22EzTbkzrlxh+rNzI023cqrc4tLSReZBO3qIvOaymCcFEaDPQOHFnXe+3Cv6H
Cdplo6c5jba9X9IyGtN+PRIMjIy6T3oWg5jtUjill13HK7vtOqOssXD+L6NHbGmUvcHHPk/qlk60
Dpp1N4v5mNlGzBK3lfubbP7FbsvzJgdz3TMKJvMfjGkX/Dl7hm7DTG5S8KfB2yzWN3SDmGa6nb+E
TbGTOeiU51eOlavLavwup1yOsXPLc/4PNaulVrGmtM00KTzWXvlLrOmsMz0ObzGR0Gl1PV47L9Ds
OVu9Mo9P1thll9s2VuNOplL1Thl94tWVq1Ck5y3U7vtszjjp9RqOjDOLNbM6ToVbqt/FBm7nnzbQ
65Vrv2oUxb6PwvFfr9z6UeUtNN53WuxF7Z1e8Ljc7arQSjO+tuTSv8Zyzxj+NmpBfNtX5GL7lAcO
CSUAEkFnKXSNr9mcVd/PQTKzcK/YJGJfPeULLCuMLO5YyvCvSbutS842iZxvDT3avOpOMY2PjXpt
/EVFsUpcIqv2zpU5ibrfG1RkJZ3cVIOeENMoqnG28eL1rBznNlOdGnU+MLLsI+a5c+cgcXJcq4yR
1cz0czmeEW8dxpyUe3k+ce+6x6Xrbg9DV4pkru25vEc3S2xumodhi36cnEhGM0DtJOY3rJxzeY4x
sg+gXE1D8JnlDyz6uuJ2FaWHlATEnWHFjgWlhawsrK1jvZK+xs7evzj6pMiJREDvzXm1r3GZt8dI
w9geu+DaLRzZP6q04pIGRAjWby9d6fOWGo8LrD1m3d6dL2WqtLtEVm1u6ZJWitRd2jarbXtOe2ur
xV6YVC2yFMd2+sxF3YU63SlIguYkdHi6bcpOjvblVITR4yk3WUokhc6hD6BF0m6S1DkbrTIbRYyk
XqSoExc6XBaXF57ocpnEzeqTAafE5cy5rmdZZ5dolky1/pdLpeu8IK6cqNee9Gy4Gu96dlWo9aax
0Ck51rqKvrkZXZOR5Mp5zmeTjtqNzyCnl0mNksOXyl7r1C1hWP6XOZu6vkNnuq9sj0iXoHe5M861
RWVaJJUR1auFA0rplGiPaW7sZUPQFZho3eh46RGkENDbpZV0bZJUzUYR8HnJ92jK1RdWzSiNEED5
qCiUen6Cut2nkwKR6Vm0FXLC34c3/at2YVydJvwkO9XsyYGd5CPlO1dnygptIjZNzW7Gms5HGK2m
x965ZOcVLcusZIu61Ym7CRbuo973gJkMX7V9EvncHONW0iwkI/u9g5tnzex0pHlIZllqV6Ns1Rzr
cIGhXOcp0LsNKscFM12vWlVQnK7HbFZspuNRufWjXrFdsr9K0/H2G75tpGRQOuVh0+y70Hm1Dp4X
pOt0DSRmWlM65JO3+dacWXag1q8m/e5zp3LMdP41GVkXuYaqjLNPRT5h64zfVOWX6Uqlzznrnuie
VuZERBWhtubWudPUOY0XfrRjU/ac+ttlfZ3jG1weRMeBGAYAJe9y3OdVUrf1qFk6xrOfVT7f1qNh
cRzSeTUreurTblnFWNdRtvSry7trE2HpUbausyL9rDyWDQPT0Yzl3jKFtPSoXAqzKSDSEs3SmXA6
1Lu2sJZutLuia5KPG0JZ+tIuZ1yTdt4OzdqRdSrEtRsV59Ni1jA2/onKM038sD0fXPPunyTzNFWb
P9hzl3OWeZzmyRT+Tod8wDQJLJdHknUvVbn59vNgz7V7BluoZ7bfOtd7ahqNYu4z2/cqnP8AbrS7
+WdaHzqc05d0TRE5jpKKjNvHWdaSeYaUmjWTq5oOjnl+mFR7QXeh3vyzzQDIHoTVDavK9O57Qd9s
GVy0pRbxGTUVi+zxGPsOaQS0mSi6bjP8Z46dc11KzmwYzwqNv6VGydWkZPrqFu6VSwd2sRYlU+4K
rE04bxNh6Um5LrMz3bREng8D29Dsp7u3ibB0plwXWpZxzhp9xTbcK/K9Ewdh7Uu4iuS/ZMHY+lQt
hV6WCoie60u6cq7M0HHefTTte85D0nitG31tgmj7F5x3Ot2hXXMXup4oiMtex0SWp957U+3YXp8j
jNpkNAeZLrGC7jjMhqXCu3bKtR88VTrednhCkYqdrM31q9zhubhvI1e1il3uNjnqnFRu6KLfWUO4
fKqF4Tn2itq6+k+VPv8AyznRuVIyFsYCVJ0Nvyb13nr1voGp02zJfczppvKFp2YU1vyCSUogCXeN
X7Uyxy9dYW9tS7w4pctO16PuLOo3JzTJucr8ZcWtQtrmqSk3DQ9wbVG3dqu/noaHt/Cm3LtS8wje
mj6Y2ptxd1J9YIKFu7elXJ5T389EQV3aUu5OKdJWOAg7y2ol3fUOXs9agL+2z6+P6JI2ytVnSGGQ
Vjl02TRcG6bzmOcby3wvTdFwq2aC0g7Y2g+8nAYvedVzy4d6JG6NnsNsBZ7cHNKlp2GyrUs646sy
bFPwWUR3V3oFizN1otJruis6LarDnvW/06A0BnSLPYKB2vlPibpwp1hsFFXcqtGW1vWZqbpbm0V2
NtTeuTUnS2aTIiB6G04N4Bu/uEXJxEy6d8GcYkuDmBbc0kkAyBqNxZJCtvpuFaWNpDTTuDVOwzSf
bwsu8hek3Fx1gFek5GCXPw7Gf5Q8hJQaJ6Pi54V+TkoCLbh1aFQUlKQCbJCsJxcE/lq8udio2eOB
fyUEmei2UwcJISUGU5EsZvlFSD+EEvGNZbhDN+S5iQiSl2LCWKKeP4lb/nxeGyJyxbSC2/Zcd1eR
glm7N6pl2fxfOTaNJJxELkY5ig+r+aheU41iJh3AupyFkJSJZWTjUyJHSZcM7Lxqk4+qFimoaPtT
Sr2ztUpmZgqpKWOnWd5Qm5JIyJd/b8W9fay2gwU9WrV2luMa3jXNbs9NiOSDQYIwCX30GXo8hcat
D3lpS7dLUpxb6xCX9lTbZLUtd0rEFfOFItkzSO10rEBoDakWybonW71qt6A3o9tmaNW+SJLUG9Cu
E3R+91rVa0VpQbnM0J5eKnX9GZ0C6zeevb3T67psfn19mc3lL1SoLTovONIlswnL3Sa3q0Xk8UXf
R77Ra/q0XmOmy+UWPQKBBapF5jqMllFru+fQOsxmWajN5FaLzn8BrEflmoy+SWi8Umu6oyyfV4bH
LbuOFUIK7axo9WzDeWeE7ZJ5HO6FCy0BaKdKzWS0jrHWHeG8V3nqPaulInWttqHO4U+WbSLBlc/P
mv33ANY45/kSSIEadGbIaV1rs9wy3ZYaVg7JGOJ2Aa47rlUyxnxMjJIPoheg6txYSzbuweuK9YeE
dKN+zB/3gp/gxft3Ua/7V6xtGclwdRUg5gZ7gxkeLiIk3FfnWsZjkONntXaImOTd42eRzpxDTHBs
74P4xw5i5NvydspSN7uoqUZh5FyzFEjFS0f0dwdhj+MnmWUJsu/wdhZsZZg+i3slVrM2iZpi5h5a
QpN0bQs236wFie0G/sazaG6q9aH+b6QzqNp5yeQ0qz755/zYlvvRnPLprX8NjPReP07aE5ptVIu3
n2w6JRtARULZPtIFxLsHNJvPnLXl4tq+hY9Ga3mlW15jIWeZzafr1g8xIIEAjRW5cK609LQeR7Zp
mSs9Hz95fXVWwPS53CoziouagQMK2S/Q1nXS7j2qsq9bQtmXS7gutSMjxgbQqn2xcA8kuFdtS6hb
OtfdyPOAs3SoWbtAuZTjW53Ba0r0Ot1KFXrQuoWpcA5kudfs/Wm25VdeyPKAsval29ddfveMBa1U
q5lWpd02grO4ol4FYl6HiRW70RTLyirTL1jFWVzQr43rM05YRdhd0G/FUJ/u0ibG4oN841OxdWUX
Zned6DwqFjcFVe2B+nMSzlPV96Qi8E03YPMTz0xgtG9Dssf9HZXquTXfKbPePPNi0m0P4ukXQ+lL
u1PXkDeQ3uq2LMqls0Tl13uN+z+RgZzzIkjSEp0dqXCvNPRTfJNru9Dg7xndlfMpTCdLlsKYcAkg
DJRdNZ0KIs3WmXEq9JuUQVj6024CvyLvnBWXvTbemBfvCgLJ0qtmXAvHogLL1qFnXBO34r8xhNYH
oJUlIFX7H3qVnEO8cpg7B2qVpODfd+kFPdqjZ11+U7FBWNdStfOGkVKiJnvUbZziJLPMf52r0HV7
Y3i5Hl2jZB9T7cyjpNo5Yd5in2plGS7F/E9pmq2BozlYWcjOU/WZ+LEtHP6rN5H6CyrG2qpH0hEe
f9Y17y3JelsEpXo2Lx70fnt84QQTP0phle52qGaTVMurWt6TnlggHU/EWGrvrHR57zroezYbqjTK
80LmACXoDfm3gWWi6bn+pUa7xdgY84+m3vItVz+gt+SQkGCMLsmxSVOkrJBQN350S5SVLe2qBr94
40m2yNSc2mErt540q2SlRXaYeu3jhS7Y/rHWyw9cuxUm1SVOy6LF71ZFNtMlU+trha3eOFKt72pu
bLC1u+caHdXlPdWmBregtaFdn9If2ytVrRmmfXyRz2UuFXrWkR+RVdLvWLzS6/pkbm2kyGYzt4ok
DqELm+nSWU2C+51C6rB5pp8llM/oGcQeqwGdaZKZXN33O4nToap6SuiP7hEZJHiR1ZtmF+sOXPtE
pNZ0prn12moVczxq1gcUWLu72r2tjUJp3X7Z0aQNmZw1h4snPRrV5SZrjzrVuKAQIdL+zRygGDq0
tZWDmuz3m1bsXcZIQbPmlJAGQM1LmZiKKZYMZlUM9kIg5pnHypwzmTiUzDWPmlwLuTim06zjZftD
u5SI4TrCOlesK8mIGLak4sTqDdTEGiwR8XMrhXcrB85+PjZjtBvZWB5T8awm+cQ9kYMTsYwm+UTI
vYQ5aKay/KGbhMjLsGkuUW5fRJyrDlKN42WESO7bm8dx8qqK6v4rjJcxKnH93cW8fIgky8M6mKyw
IOrH0rEtPVRdmh4a1dKpMWCr87fDQVpdUqYtNIF5gK5detGmrbR0XuuVy8d6FPWvP06BWqzfCzfg
gkqIj0VlzRAx0hqENY6XcVTvKPRWZyk3OmQLRBERmCUnoLBp8BTNDcZ9P22kxmiwfacawFq502p8
yTcbPXroinvbFSa9pcA6t3CsTruBXPMYK1JhLGTXK4RMpqis8tlioh3uu1DSeed3KfoPe/VWp6Y0
z29zebv73Uq1prXNNEl8zY61nTHUGebaNK5nPXWjQOqxWQxSVWTZGOR6nOZNN6LSKXs0fH2RdIuf
ai5KkONW0LLtJTUOtupObb5UIvTExyeqwU7kLLdcRuk/TsQ5dLhtjnLrrN1qFvp5Zp686ur6Hh7m
vM9LFBuZNoWxyGb6Lxp1ubqiJOYzy786tbovqzXP0O1nnOTElJkY0ZryRX47V9NxvYuMlS75CdbZ
Xe2C6aMYiOZBKkmk1GvZL/WqLs0JmOrikOb1BWGt2arxlrrdYfV5xsvevOeh92KaXredyUlS+l/g
rAuvTyGZpgkXHBqqnZLi4i5RsfVtKQzvrHyLc+zSSjerqPftO3SOl2CnTCQY8ajtWMWCQkY9/HuH
sFONGUpmeTIVrev0KjbvTs/015nvTVM/ucFPUur6HGx8zXGetzGaWWGmXtAv2G7tRshkNQe5patG
wxpudTuFmybQsr1byrEdN5sUZaH+Uaw3z69FFRdvd5Pq/DOdB5xcZb++W6q2oF65RsTcXOU6rzzf
QOUK1tLjMtQbUC98a52Y+dS5mQA0Rvz5QUdu9lwTT9qz6g7FS4LVltfPNk0zz7B8UpJRAGY7+grD
ic3suS1beKvlOrWPH9W5SGZSU3XL5AsrJNOavJp69azY8e1GvMrZxjLhGPezB7XnUpE5Dp/LIINP
oSS6TSKzbOtNtDmCVLisWpdLtvSA7y3OsW3rSLgqBdv+dcnsQ3PNLy0l5BlB2ntRrwVTlqPh3Jxt
Wq+dVekMXzX0jHYDrGpec9jRM5nMdKPtmRdrzYp/O5ZhIyFB0DzTssZhGtXfFWmoaJ5z2SEjtLtO
f2zNNL8rQXff5xvYHmYafyzu8lD8LK8yjWOGZ6PwhWtpfZDrnDMdJ4wjO0yGP67yynUW9aOyvsi1
3nlWmIqDyO8/IJfIAaJwS3g4vbLxh+p6JXs807PJWz0y9YFb71gkJxSk0GAFl12m44ZJ7vjVP9B1
XKtNuOM7ZSrzHLoj295Pzf2q6wzZvYTrFgxfU2OeOr3Z1Um7dqDcqFUNU41u649U2p7tOunfWu2P
pVbII7q8XAWBdWsiYpz37V+w9KzY0Rjvp1gn+NbpQ57u/LpEyzqr2ZvGPs5yHh21/V/NLv0rhVB9
JQ2B63qXm7favbuLrOH+i44upXrZaI/hJ/vWpfFNvYYF6DpmZ60z0rAPRPm+u2X0rltyh+3neP7a
fqvGnXDi3YTXagaJxo1z6REbb2+eafzza9SVWidBY5nrPHL77MUhpo0Nl+w88m0OwZoWnVjPNgbY
bTiQpJGeiNiawcdatpo1/pN8hrTH8+WaafjenVHPGnJCFEYIlH13Sy4lMbHllR3SAyPVLLj+izC+
Uk1jpDjCZVftIqs6UB1m6nBahzp1j7xsyTVD3nRrBIUB3bMaheYuOudqNZpir8LlEVO9Jo9pl6oi
2w9Vv/Gh3OSpvW3wVT0bhn90lM9c6jC0G/NM5v0pnMtc6lWdLj8hrnJxsd8wt5teYUDeovFdXuGJ
XG7NoW0prL97V8n0i/0O29M96XPM+mn8sntcJU9Wkq1RtJzCPsOo1Bhbs7raVPtA6USdtVF4XquV
64daTLWemIuEFCWdVVlJ2rJs0PFzXavPZivnNx0dKqhn0lBHLRvF/wA4TgokgJLR+HDlCxC7J2cM
JBbxbVvHvo17ENuHNIStKkmS+k5LRBTTOOmThnslF85omcn3juUlFw8hMMHvaF5zMXynFRTt9Dd5
KPay/GElOsEUjDsiR1nJaD6TMU0nOMTISEJ3l4fhNM4uR7RDuRjec9GRswuFkJCG6zPGEk+MbKPI
FMq0Zy7eEahcnJRzaXTDyrqF6SrIphtGTSYpmtul9JspooLrIwfKaauJURbt9AdJuPqnVT60VSM5
qU4tx1GwTtM6XKsRV150m02GhubvVoK9Jodssefdr/U4DQ+Oe2615m9v1Qrmk8s0vFnyx/pFDmpf
F+CkkkElWiteSIaGf6vF2Sp2grHyYdaTas3vNYp7bgQBkhRmrpo9ypsPpETSb49z2bt1Oi9Dh6Zf
3efTdtpsRosTSb68zucuVMiNDiaRoTmgzNtpsdoETSNBcZ3ZLNTKGzJejXijwmpweeag5y+0XKq2
NzClMt8qgQJHZK7JTrOi3zjSb+5gO8s2ougN6ZoJVXNdeOianHY3AkLbtEZkmty2SWLQqNT9mjWs
t3plwVScjLm92K651fudXeWCk0Lfc6fXOqxWgQUgTKdw2uB/6TxnLeY7aRras30FUHxne9A0fjQL
+1Z8X8tn93Km3eLSSZ6kWfpVblBOhF26nTDisXKtP+9euuYbD5jqBJJJgl6DxRyhYfQ9sxjR5xzn
2lVtV6g++BXCz4dBNSIjBkYVY/QERLt+UnESDdEnCyfNrIR7/hykYqS4tZGNf828lHPefF/Fvkcn
8a/Jq/YOufF9HOcTqnNx6Nc0N1olOp2x1/OdUNjPQM5Re1qz95yp2i6fSZSAszJq7rsBau9Ve3xl
HynBzCT1M0mKgky2b48jpsGtZzT99o2ea2rNJnUMyv1fsWfV3SYLvI1TtqL3O5xtJPs8vuIbrnTi
05s32Wj3E6hcKHdUZXsDTHcuPv6Jd9JZ5nGo8cv0jnA9Jh1muqIy/S29beyb/NtQ45no7etSEm7z
nT2+YaVwqU26f0DQ05zoGbatWcGpqQRKJGj8uBQkNquv+dLX6EquQ7lWaRryXvnvnteD1NokiIwF
AXbfqnb+1Zl3TGNsHSoWzrV5l4ziLEuqWnvVJp4zibB1qVq71eaeMIuxLqVq61iYeM4ywioWnEqA
3mfSUVi+rXjDHW6ZBTfQFeo+tRTzLLzAS72DO6T9bdRE4IhzDVuxZvAapfV12Tio2bn2EqmNg5eh
4fx7bhqfmx16TxDOvSMX572LTfOm4MZ7NJyNre1Yg+0CenqBJNZJ/Qr35j3iq0Wx3l5N59ofGhX7
g6r9M06n2nyzHOvR6nUs5zfUSyvSeVdcyz3LtXTlGpNqpJyj/LNYTkup8adKyEjlWspyDXGdNsPW
SzbT05Drua36Io+KpIBSRonJPGEh9G23CrjqrPMNSoLm45jqeGvtTwqqtUkRGYAXafQFZt6a/MAo
2TcVuyCBmkoYyfasWY4GaPmwlO1dsKYaXPkwlelcsPSDlT4tJLtXZzFqLweelITF9SvuEd98xyle
h67Udapt4jomq3ThnyXOuN3tDvXBh2HajwnPpsLaNd0mk6NM5npFkrxPs3yHh32bUvM0l6Swmjek
IPz/ALJpfm/fq7bW3aiP7xlYoGg7DSnjR26ihke8QNFnLA5lqVcUVC5RfWtVvW4dz5gZdda05Oe3
xdZOyN6JpKMv0h3SlXKGoeutcm0yTzpzoFczzZI/H9Tncof6TTaFtsXjGuy+QTGoZ5Wt6hcFo6CI
EZ6M34c4eGldpi5+uWhtbWTVeTavkGgwebxvNANAWSQt3qd6q8Nf2VFu0hQ5O41aEv7Ki3eSosja
6rD39lSbrJ0KUttYhL6xpN2eUaYtNYhb7HUq8uqRK2aq5jEcZjeWOOalcMUktdzWm7dGZrrPVpIn
ygbE1zyq7UbST4US78oC/sY1lNNaNfWGbX+WzWq7FOZzeIzJ4Dm52C74i82XMaPukRjuq2rFrjdG
MPZ1VZ8+qmY6Tc6Pb1ZtK2bN5W+taLdUUi0yVVVZoasXlvRLg/plN59Xt4a1Semqau212JtHGuTE
rWOligGk5zgpN/A9ZqJbSKIx86iusgw4yHJk67R3V0z6OGsc2CCMyGit+HKIiBMySufV046t+cW7
YOmDVrxIJURpUlQkZg46QdRfR+y4yfJnKLinj2ObOm7SU7MXUnEcphkxmTiXz6KEm0i5FzDd5OI6
TMbDtkLsD6BeTMOxsTOIm3VfeTkZzleMVIdIPnNc+EvHxUn2iJZ9EN5yLjZlMHKyNedTbKKlWsFz
SqQm49hMrgpGTgRPRap1nEWRNcaIQmVmIizIrD+VqiZ9lIy5VuFIukzK0+w2Go215UKwhb+9t6Nc
Z7PJC702H0ZjQrvYMyk9CocPpsdnOgWLKpjRs/gdWisz0ex5DYNFzeG1uFzHUJzG7Po2XXNGIoQa
AZA9CRw5w8I71Nw4YSD2xN2Dum2jNrZH59H8eakrQB05rEttXLL73YaBw0us0PVCiLOmtWBcBm7X
iLnpFIunSvNbVXG1pVW7D2g5N6wy2e0DJ7FcMy0aRj8pr6JTZnGf2G1VCK0KKoeiuc6tVkpbHQYO
laQrNLvOUcr3XqjpKM2vsznzy6VuraXxzfQn1IuPUqVemONVlCrts8TkuxvsitV6oVa2OI6dnlUs
DmkZL2YyG5WbP7vyrsm/qNF9CZFbZmkUmCEPP79IeXfRTiJtVOn/AC+27bFoHfP9EjIqRTK0q1u6
PeoRMjFWKrTLmp3WAcSVWuNZdSlUt1Wl5GmXWHYWarWKvS0hQL/QtP8ANtJRzBgjToqOKIWEtfoP
IJ7R3GYafXo/RW6sMTq2J01qQIiMIWfS+7nVM62ePoFotFKr2uVaZbv4mpWvtU5CKhdas9FnIuWV
DzdEZ3utwlwkHdetGUWe9Yvdrjkukw1gxfPuGw6Alz1h5vnGSzY27xxCzBQ82zQOneInEwdgbtHA
cwk4ut2dtGyaFw03I0u4M4OazTGeXTbdXyuub/nGfbRzyu06RlWkVu0ZlDaTWJx1V32jqo8zz6P6
He8L3jLLJMUfPtZtWLabcOfm/wBN5dW9XjbH5GZOvTsfMvO1D0dWX6U3qk48XRdGVlunop871603
QizTSW9Os6O9RvJZxo7ej3VqVeuqM+0PMtHifPFSJSAkho3JHKHhbn6EwA/SbbC9si8z2ThYMHqX
oXEqE1TzIwkwoump7Tjdc9A0zJdqlsRsmvY/bJ7pWoyx0bT6q0mLLO02Zi5F7UrNn0wzz26T9FnL
BboYprFC13LtQYSOM5/w3C8x1oXTrf2qE7IxDGzppd07UqyvILjPpp92VS7W5ry5rjVbqqg3rpVn
8uyrdrVUbcKpOUDCuPXc9R8zSfpLB6B6agfPu0aR5w3qAtWdT1Yi9kwaR0efn6T14y3eiXrzJ6Eo
NRltN5y0vm/SzWPzP6RxPM7HoekeR2z303Ezj5dEv7vJNUaVSdc9KHovbJtaYUm2H2oeiOse16Op
NuQ6pF7cZHrzKg3loVauj/Hdbzu3rx/K0qQkENF58Ew8HZvRGUOdeLNdIqKbrleo5FF7PidJaIQZ
EYI1Lv25YzUvR1IyjXp/FJfase0AOpFVPZaBQo6LmNdrz2t25EDM8m1V63CpwNVtWoOIuTydWsUC
7VS449nbfWtI4PO8NMpj5Hl04d3UHKHGSTc+a3sNJ9YmVbEEPop93hpfjy7NJKNcS9CvkW3dZdlD
fvteoeZZf0lgtC9N1vANs0Lzlv1dtbZdQeW7OeeXarqtOkebR43h853mrVSesbOZY1/Ddrv3nz0V
kORa5eKViZONU0/nmGlus7mLfWKbrjDJNYe5ZPX+hVLZYvHtflcXs2kZzT9yrmQbHJYra9JzKr7f
Wcj2h/ht50PJuuvwXn6vpJISaNJ5s0xEL31SYbGuXsKWJ5noGf2Vtm0ZzRzIwoAgrR9WzGvbPXsq
1qXyKb1DMl6CcVPpjm8tF5XJ63XZR7Xoq219/YObKS5RVYuNd5WrnU5q11brLxWX1TlK6/M0J/cq
tBaFHUe9PqFMW2mRmgw1I0Dtn9is1J4X6BpuiJzu22KgLv8AValpjTOL3M5/b5yIoWjw2WRHPvrd
ryJ9qucU7aIXK9Onclttuj2U+irSryoUfQ7DT7WmhSNgz+ftrCq2zjT7Lx4U27Oa3a6vXrvypbEd
XNsZQk33r7mZg+U00jJHvDOJWKQ/aNnyo/q5ZB235OzaL7sujlvxd8W/Xs3U5YMuZJBkD0JDTnGQ
iJWWJSXcgvnwj+zDoUU2ShABqSZKNzNOYpzLRfKV4MX/AFYS7iMdO2sYvkyOf4OJKKj5fjHO3zSV
6tWL5s1lTZ9nTNpLs66xSc1MwR2CMjbByhJSQglTsKzsbSHlXUA4sEE3sUbFT6q/ITFfTZIRhYuV
dmZOuTUxFQdgYVvkSn9sjoGx961I2CrcLTHixx0LZjqMWkHYJmEt/OmS03Rud1rdgme1cl3VZsfY
synLjU7xwr+bEqZ0+Jz7RZbKrFoGcxuqQOe6dM43bNCzKM16v5nrcri9u0bLIzZK1lmxSeJXjQcl
4a/U802TvhKdvqcRquQZ8gJJaQrROLZMRBr1efjJphMTQ5dqtK0d9I5dDtkJMEYIKU/3R7lFputD
gtWiMz1N3A2Q6/Ldo/KmXJvc9aolxTHxNshs00d9TNELpGuD5u3USvrHvuiMmqHKb2iQoc5Za1D3
xlRL64othnqsxu8ZTL+qg2ubp/O5xVP0A8/ukpTXdnhavoHLPL4+qFu4PKfa+OMVBB6HtUFkm1dM
ludxodd2WCetJWsP5KlZg7h5Te5Sl2MoWa51uleiMLmX9qjo9NhjK9pvm+3bbmGgYtWKUTrepmTq
dthUT9Zs8PynqtZ4B1OUO9xsLbKzO1+RsGcaEwq12gX0HNSmbaQ3omhxDdoz46zltvzPMqykkkZg
aJz4oiIKV9JZox2p7lt7bQN+kDx6j7nkudM+RAIUCUFW/wBE1LO9e5UCSvtHrWzVF47LjRrS9gJC
PgdNt1CnISeEBPUC2yWKuLTdKA7vdNq+kNKZdnEjB2vHsubaxpzSZXAWPnDyiuTCXVXbKmBnuTbh
JdK1ZhWrGI1Uguu2dVQtvOEkHHOBsbunXFtXJzOMS4Otu1jF470Flefb1E5LfdDxvVYOzY1z0mm3
LhCTd35U+V7Ic0y4YT6AxbMbftOYs9YLzvpd+oujWjHNEr2fZEmT9T1m09W8JbnGZ6Y2pFuJvDWx
xmemt89uwaRlnc5ppnCh3bhGcbA4zrR29Eu3KvvHMy5q8/RrH5nrCEGkAtI48Siq9MeocVrnpCZw
fUl5dqrS35JlPorM8uj+Q5qIzIwu8+hMtz/0DFYrp17xI92y11dODKCmqHqNaipe0WapyUNMu6rY
s553rC3ut1Cl3bRMtkLNQbNJZ/JWa+ZBlLfX9Oibb1pltcVaUlY6EtpUq496ZPyUOws/OlXfvRrS
7gEWHnUrn1oN37VV9LNa1bxSbmdVmM/wzh23TT/Mst6SwGi+m6rge5aF5u9C1C6UKdoLjVvOc7fr
PYqo16y/WjXLzR6SyTN/SNJy2Yv2hYXvuA7VBaF5tO33/wAoCQ9R1e2oOs22RyTWmFDu7cq5bZTJ
9TY59f2iIefm8i1SPo+hRbRlLzeY6M2oGixDRdazD0JBXTEdq84UZBkkkjSOPEouBdekKrBbJzqV
mi+Nnza80+j7TlGeMUoSZqIgF2f0bluc+hI3GND0PEeW+5fIWljNrq7S312Hqvbc4KRrFqasn+cT
9xxmft2OWlxpGcXisV7VaxEVO0X7Kc446PrvLu4j3/AuzV+1J2wec+bli95cJBj2Pi8j33NjLsF9
Wrxi76ws4yTOVK1Q6++R5k3dbjpHmyY9FYNSvStXwXcLx5036IsbXpXXE/S2WSbDo9Tf9q9MdKVX
9zpuLeh8MTrTqKz3ZPNG5Tb7P7h0q3n5LnUdXi8o2Fzjl0u2ZxOswWU7I6xO83/J4zaKblu0vMLv
2gY822am5ftHXEr/AHzGF63SM82ppivfeY+Dt0HgzRASQC9DQ15x0Ci73uEmYazyblu3odlglPs6
jOCORqBJUlS7hrtJpet8ssvlry89QqVd0ntDzfVrETLPOeesRbh/C1m7RVP0GZo0VYc6u1ya57aY
aL1HrGVy1VzPobk81Ky0VV7q1e0BtQ7tL58+u1SgtEjKFfZHPJq30hjoMJS9EVnVmtNA5aHVqpo3
HPLjP0C1zkLTLzFZ1GJ7abYsykb/AEWu6rD55oUjnFktEa0nuVfknFRrN7k63YuNMl39Msk4zpk/
X+N0Fa5Slekp1ixluddiwp5OMGUquHeOI8SDXg+SycdmCunLm56NXqWvbuw6PUMnq2DlwzaPlxnZ
20e9Y2L5GkjIj0Xk34sIDlJ2Hk6Yy7lzzbx4Q16w7RHEBRJIyWpxLzcJysDKKnVQb6UjJN1HHKM4
PkOCbBydybKFnOEA6nIqZ6cGMvwrzJLi1vm/JzxrkGgP7UyhrF0rkjN13nZ4dxMR8dYOVVbHyVYF
crCzrU+ut2d9BKm2FU7WaqubXBV0jd3FhTuJHaLLT0XiCq95VSbHZKPH3iG43ZNTsr+ruLHH0i9s
aDeJrOJW90mF0uMz3RJjLLBfs8qNqv8AlGjpyRslTzXpbHbZo2ZwOz13Kdjl6BpK84vMrUcUQS7Z
uGP6m9qdT16lVbXizXQulbeyxedLTvHma9az5o3vqrzPGEkwEHoqOHOPrydbutPvdZtLh1yUxbwV
fvOVVJnyWRERkYW49ASubPNEqVG2BlkuqysDPcWC1dMmjebK6bHRbMkoG0M8wv8ANZvoyJOE6u8w
qZ2LUzk2zKYynNGxarp1ao2utcq0qWzSR0CGmGTqCeymX0tcZaN0hDcO6zPdKhOPFRneZx65aT51
umiUzK1ROqXvjj1CKd3h7HR1nTULidRtSoTP9/yqDus0JatTruo22pTJ1K4Mo6YYP4WXcVW4RLSb
hJnEdzs+J6Rh2fNTVbvUGfZzsnGjFrma0H0lmdjTGvs3mrxk1wiaXvF4w3VMf2Bnmup4xCa/Rqxd
rRYci2bz7oWmeTdg1Dyv6WyHWPLVXCFpJI0bmhMZXuvqKl5/6EnMwmJym2+2IzfGN2p2QR/AEQIz
JSp701V8502SzdxqOfVXa6vwscc4ze0yUVKsq3oFwpEvBzvavzNReWzEG9svWdSNrgZzpTK5bLlm
3PU8uy5k49E2rLl7DmlT22sZvp0xR9CrlgyaUtkBL8K3cb5XeUdNrjeLPOL8zoNu0mrW2e89aJM4
tYdBotwj53O8M56Nv9K0AqRbe8M3nutEu+E7fneLavqDaZr8o5r9ma1+RlWtXuznMNNa02xumUFc
XOZ6XW5yTodsqWe4urpqHpPzdU/UVMwDe795Mu/o7zPc7+2qdW0XHfQeSO5+9TWTX2n2p1neg4df
KvlWvzOF3K4arUWl08mzfpPy/wCls10XyjBJIiBDRkcubGuK9X5xnHoa+YhYbFmN7VY6Zhu8QGKx
3JAIAGYFi9NUHKtve4hcNaxev+h8/jdFiXcBJZ/p0NVZ202muPa3ZXVZmqZXNTxLhr9Rb3Kn2m7R
dQpum0em7JE5VWuHb0TZcDs+24hW/RtAyHepHI9mgLLSZKmWCwZROXO1k0r1idRPIQjfL42967XZ
G6YTdH+D7lPR/GMms+wrnoXoWl30Ue2OIVvPLo1z827zT8hs2wzis60pzkGsca3Iv01S4u8w0xpU
7Iaa7a3WZaXjlh1fPnVStXlNXa7enfKsV6fzjGtvvvk67+m/Ju3K42OTxGQ2TBXFSmvSmVaFjW1x
dE0CJYUeb0fFXeeXzVk169+WrrunnnfsP2fynXkgEkFo3HmllXefoKQoWyx/E3sZM1BweX7Jn2Xs
OfNKjSE9DXMemqLku3SeHWzWsZgPQ1EidGi5hzXm8ywhanFbwxeQc40UqiSF/wAlLQcd2AR8g/g6
r1ueKdtyySgMEufQlhwS3bHidd9C0bJN4kcg2aGn+jCFcylVr1I3OcaRcvFP+TezVBo07W3IUb1j
V4dYnvDcVqeVjefcrLvPdiynhUbd1pVqcVqmbfB021SsRORgkIyToVzRmmhPs5sNqqNe0phl+oP8
luFvzzJNa17MrqjMcZT11PccErvo6m4V6Dm/Nd/2TB32r86NozFnXbPHYRbtnzW4OKLW9azuetvO
t2ptXIO65ivQYyn3mTp/WfqWRcgCCQNFDXmxr/Ke0qCslTuDuSbsK8jtDzlCjW/NJKMkGoKnNWjM
/wBFkM5mrpS4fSIin32ThpJ3xhZhNDjNL58ZeNqdua066WGtViyUi+WJNdl+tLY2Kgi/1KrcCcan
PZlOXqiQmmw9A0d/m9xsUWcuivynWl1LSZGFsjKj2ZxWrv0ZQ0/FUCR0KrynXPLhIt6lb4ijtU97
Pa6kwvUBA2pVSmp6nSFm416x8azYXFady0PCWJhCTbmuu5iC4T0dGzKoV6/hkSq2L3hDtQt+/jFS
jNlKJjHbyNOWZcHXeN7uY/lMtGr7rF9pGLEuxayHWFdScOJuOjZ0Qk44hoBKUqJIVonPi3aV/hI3
JrJwU88eiObMHMVJVpjwQgjIGQUvtc3NckJ+vNLXGQNo7VeXmK6izxsLYU1+SlYEWaLhLQmsTclW
V2aDh7hxrc7IVeKsrmu2+CrLdSZW9x9atLynyljqXK5xXaXZxVl5U+CQQuffnY+FNsbio3B/BdJm
Nh7VxprDQ6rC3qqP7dwzyDR1vVspDXQISmaJ0zm32TPl6JVqtpXHNL/O5jK32kQGpxGc6TL5TZNA
zuK1eCzLWHuRXG95hYLvHZbpjjDYAdtB1epZ5tJYrp9vyF1q1NoG0Nsa1S0Y1NaVSaLtbbE9gn8V
s+jUam7FxxbY5TFbrdqLXtUb41sr7G9Tiprym1QlRESdGHPixrvDWdPznUatZ2c6zN9X22Y6jnee
x/NAMEoIProesrp1qd13rOs63bzptodVt1Ms4G2IqVpcVuRlmEJaedWtHatTD6Jj7Kmq2ntR65s8
RDzGb520SWuanX8+13hlOmS+bvNCh5VhKVjrOZtVlwVo3KJ5lKQEmurvXruD7WRkpdOoXoTOIDec
VtruSy/GRad/HNu8d1uxpgLGyT0DiFnkV+1xSJGLlIp06hLFBLm63YG0ZNRMtGLm6fbXGfX6H6sq
954VM+pKPeo1spxL5zoXbNNNi4Z+4ks20dxlGtxNTsa3ed6f1x7YWFDuCjoukd8X2ppmejcoyvT2
GaboHkJiEJWRI0Uk84+v8PTrbGN/0LMojRaG/wBJOneetYc4VENyCQoBCj9BWA5Y6xaXNPsveIRM
c63ZnFPs7qB6SvCEsbio2btAvJJrD2PpULV3rcq9Yxkq2tMQI+m5tUeavQl8x/vs2V1rbK7lup2H
MtMiJvJJWwQ881g7hc4JpwlOscxLMdAr1K0Z20nJ+HYXzLs89FZFcn8nk2LJ0b0HRND6UG4uIHlY
RRNA7Zroaay6m2tUva8x03lTZ6QYQFsc5rpaaBcekUysq890aMibDGN+Ed5d62P1hnWhN4JzLHRd
EPNdEa1yVeim3/pl2nNKjYepVLQF5Xp7aj3ANa9dl5TqzbPr5zhmLjzxp2veOWAUgEE6MXAmda4e
n22L7fq2WRGh5tOTC1eetVkcHheJEZAgB19AWJM0KzZnFQs/WJ4zXOt2jvTrU4gOstzrtoc0y096
8+k2kJZ+lPtTirTEhHRUzB2XomtSmcZAzVvN+wGW3nFaX6VpeJ7rY8b2esXCsdaXM2jHZe3XJy0r
djfRjXvGwNDv0jnVWsmyyrZNFx/1DmF3i7BQMHGiegKfeRSraca3me1Ku/TP720hHb9VYtTrOdDa
1meBwM8/z3QG1QuDUomVkaHeXmP6sxYJrPnhU76gpt+rhueEtUbE4qF1gRJQdkrEm/qturneZqVv
r5T9csNXk5ajXeKgrhX38XJymfXxnUJeK0DyA1I0kEnooboZ15psmlZlr1fnoiyQriMq9ux3Wanl
EWnmlQIEXRejau4rs32juMxzgbB0r8x1jlSXOEnl1+b6RvSQ4RM+mCmzinjxozmeUJPFXcx2CyM+
DrPcjYdt7uODz205BT/QdVx7bJ3GdfaSvbnDImq9V8+3CdYE9rs0Iu3Vhdgh2+f2WegrfyrNY2ip
k8c5TkvKf3WZrTG6R9G0Tpm92mKJ1utfpumN8w0iTzGcu1IrepxmW6s9yO4XLNo3V63mmwLxm/3L
KbjZmWP6y1wqCU6v+tZ5TNhj8h0+xY/IalntV1qLy/RJ/IZnSM1idShc40WVyiwaHmsbp9YpehuM
1nbvnHDRqtVb2uhaBJ0ilIBcwpA0ZLbjwgGT7So+brFo6yqY1hBy8BO1WKb8CT0IEk1q7XuUq7yw
wUfbmdWs7+pSU/Wm1sj61aXNRlJ+vNrZG16z96nLzVUO3Q0Fa01Ofl6hD3Wah5rnS641636eo7i7
1qv3xnSrhK0mXs0fzlyr0i5q1dukhDz7OqTjuvWlw0J03rdgj69aUNuc+1g7Azp8Tz7zdhrfO0w8
RYFQElI19c7Btp1pGyruv95eF5TTBjJ9IV+6jDlI9vK8Ix88iHMlHc5TjXUGpzLtmUh3hXUnEiXb
cZbnDT3SAZIC5KUhrIdc7T9XkJ5owneleh7hBQFs7Usx2vDymVnmEkYItHRw4ca6yktKj52qWrrM
8ozlAzFUsdVhG3JBmAkyM12i8wFcvran2iXpi7nAS0hEN57jSYVJKvZKn2tStB0vpc6dYZ6Pq1sh
6ZwIkgdrdaqDX0FeLbVWV8iKle10ayz1KXdq9WtAb0e4SNFkbnVO9n4Uu096Vc38bIO+mZTVpz6D
1esy09Gw9ub5bU0OtNuOfttLgKHpi8zu1kznro9QqWqtM+051UWV/otY1yHzDVZHJrfd85jdYr2Z
7GeP6HbMuXp1WgtK5ZTlQO0+g22BbZP41IbBRMs9FREdNuaRceNdwju0d7dpWOadFR/Sw0/q7s1e
kOkPnG417zdtOk+RJpNh9A0Kz+R+fMwCSvQ0ckNa601TZMm1iLnq7c4Q7TVuuH6jA5DFcEgAEQMd
d7uFPrWsQmZ7FzzO42SJmoOXgeNlzeHKv2na4BwzmId6ujS1+xqakLTF9s9oNidQBzcFD6/peEZ/
ysu7um5OnMNLdoOVDPt06x0j3g5Y45+S+7KUjnBQMbNTFbY6PkejdcviN7oMc9v/ABhpbLcSF19C
RrxPGSiZFu2moKT7wc/GJfVSCtFo71G0s4mdjnsNJzFDupU25MOHF9J0G+Hn2gR8W7qXnYdNa9B4
ZVfS+VZ7szvIZLdcJ02Hs+X07ZatNyUCx1N/kl8h5ObxnZfKmhX7zyveapOXbzladc75BriKRoNS
eeR0pNBGk9EPkTSttfQFz896tuNDzvYqTE651ifN9tveA1tuhJAyMASHprtjlu0jIo3dqBnu0Izz
U4p/mFleMp9lBW61wqGch3jeXClatj1Z0W+ybOqxlmjK49v1Urt9seBZu10HeYC5OKZY5KBb2VvU
bsuj293V3c2wrV3RRLumFkHLCNcZZfKjm2nXHONxpOb6xb8xyfYL1xZyGQ4sjTfQdG0RVAubqvN7
LypWgdM20IqlJU+h7BLyOaadzo1rdxMVaO+daOM9vCoFNgTRdCPNtAiuCqB5+V02rcvJch6k8/5r
6gjfNmx7L5S9EQ1oza11On+kPKFk0K12zOpODtctkesY/csGrHorhhW3XHzN6uz2+QEjWE23I9e8
bISASTLRC5mzrjXdNBwPUdfq2eafQO1tr1u88XK7YBXmqUggZGFd/RrvELnqeKRPorNsv3zlnWv1
S4QwpFpf5s6m78s6pZncYljme05VWpvYZGtdphrkj6/y/OP5zeI5s0v27RNocVaceRAl01i09KrY
+9fevm8PYhVLZ2o1iko9m7bVWiNd2yKn+m84h9YRUs4lN060KzZzhPLRvQNYtp1O1cGfJ65rNm6U
y5sop/UqVb9FTSrywgbJG9mXaUqdnTWrfBOA3la1OHXrU1gpGpeeF9te3byJK+qPO9A9Nx3mvZNl
8qei61dGT/O5u6ZFNYXpm95jZovnKcGNupU1he9Y1nHo+xeXPUMJY6fNsa5o9VT5ZJAIjSWinwJj
ANLpu+faHWbjDW6HPlnOkYzp1bymL4IMkhSTJTn0a6w6+aRjkdvNBzDdiyzWUd3nJq2fsKdne5Sr
ZfeuTp0Z/olR5PJLg4DaQjYub6LZve+WZezl9vnYVla2NZuR1CwSNdK0RdavDWl297TpKxQnaVOo
2PtX7zDtsz1TET9BUijbFxh1SPRhLFjmbFMbVa6Iw0uvUDUxlV8seYOtJo9T1iMz7U3FE4X/ADmF
1ys5lrbvHrrdMs56tSaLrrXJNEteS99PoTfSWOO1YONYuGMP9Vzuo66wyfSbFlM5do+BtyK07lKf
Tb1YqXbioL+y0i2veFGsVcYXkqNZpFjH2NrVrEuqQyCCQEloptuXCCj+1x7yEPMd5M2LevzEPK16
Oa8ySQNSAA4uMhXnc7CsLO2r0++rsjNtOMuqDdd67C2WTZy3KtyLyAl5towmG8JMOIB9IxLWXRHy
qIast1TFshoy0ca7OSNWd2OutrTFwVlXWZOYrR2iFbWdvWZOQgZ14wr81BosvKuz3ZgJuGa2FrVW
aektMwQno6NnUQ8m9r/WYiOM2zj5Z3X+8nDpnI6MnChpN9B9JeMaTjeFmX9cczsC0k5Goci6zM7W
BaIyFs3aqS89Uzt8JC2zrTZ2xUdV5rcFdxRLXYs9caDT67obWgXiczaVv+f1q+orGqdM3pSSSCBJ
0ccOPGCjH2sMp2t2oTyGB1Gy57dajU2nJKTMiIGfS0afCUPSuudWi00Vto0C9k2UfNlRqvx5ddLc
N7HzpVpcVC0yUc+7rz99bqPWNUgKjqNVO5JodIYr0y41aMv8bSr/ANaFZLHTW97r9U0LjRLpK0GT
uFWhNDjaFobzPbFaKQ10Cu0/Sueb3uaz6RvFPb3Q8oz8SWuW+jR+mwed6sMvvs/mz/QKdWNVjcy0
2Vyyy3Oiwmqw2Ya93ye92XOVaPWqDr7fJ9Ok86k7vV8R32WxrJ1S2/2esVzS22V65zzO9SMBFXhG
Y6nyzy/84flYumc6Zwz/AEVjF9nErQ7r1z/RYaPl4ew4T6ToVI1akWfyWEGgIUNDHJHCvx2hb3ju
iT0jQdIrZ3iBcefbpM4dX2qEGZkQUS90v1Xp+vQeaa2VBl7jCzsHPVRhcafFHVrRrsZxZzLdIjYC
bl69H6JnNx70CD2ur1LaM3k3clTsPi7RviZFLaQa9hyds3iWkk0Ls1eM3XSLmOLV80ctur2HlCip
lmaub2IlHNYsObo0zLsNToPoarWo65ZW7fm7eU+1vKFeOEJJqXAWJ5nWi86RcOTaPnXmd6KrNdF4
V55KCkaF2yjUsK3rIsmqar56fybXGue3brHV+6usk2BpmWjFBN7O5yrXeWUabyrfWecZpqvPKtQb
VGdddKHpAyvU/LuyFRd1haz5iJJJXzM9AVzRxr0breyeerL6RruNbpVKTsfXt5vXsWD0xpxASZKB
LceibTiU1suR1L0DUcm2OcyTWGUlmc6tpaYJlbLE2jkPe7aM7UK21Cg6TZqNrcFnWiWuo4/vFWkJ
xxTMPiLx6Dr1wfU2bmYaLtiKVdu9FtElWV2FjVrsdEuzmnTMrEQ9x50S/dc+uL6tCxs6ffjzm+YF
L6vlGJ8tR9CUPRl59dnNc52RvSr/ANMx0kqnLyUdA3Feb6WjPrl2h2dlFC0Y8y0VNZczjWn39eXa
fg+6+fMjLpf/AE9lWrt89uamERanmS662zDSeUJwsjrI9i55NqTSqyMu8y/Vix/YWVFs/YqBqDnD
9t8pbSUTbKLf/IppIEghopc0coCM0zc8MumuNMq1ehqumd6Zg8jp+DUxujmaTMEFdt0uOISG549S
PR9PyHYrFk2zVK4tW1Qlp7OeCtGnm9enHrRo4Kv1OA2nP8+9E12pakcLje9wjxL+CwaIt3oCPsK4
aR68eD/tX51UBOBh0cHEzXSuz5RMiSGsj2r08uAn23DoO8LLuK5P5lH6znGF8dA9BQc+mFsMUrsz
koh46hLBFIl4OVacJaFlmLefqc8uBn44+reZqU49pltaxkkXfFvSPnnIi7WP0YpnB2h1mWlrzO8v
K5H3bhmOsJybSJChdr7BZptHDF9ZmMlmNFpueblGYbtsthtx0PMqR6K55fpkdmeGFzAAI9DTz5t4
WKlNxZT8LZOVsZshl+m5VfYHMItujkojBAld98sWNyetZnUtxr+S6/OZHoktw6v+UPJJqWaa1Zoq
ROpTb2vXHiyzy/ZzA7jG53p/aPrWic6/OChZZHutZvlZr+hMKNfXVAsFlp7O9Q1R0Plm14nM/d3e
rVjSo7PdFeZrY7dQW2kVujalxzC8WPMn+hURF74ZBSA81i85o21CpUTWuGVaDYMskdHz6v6pB5xp
rvLLTdczaahVKRp5ZhdLPl7rR6JXtMiKHdZnOJW85/1vdFoxn1tdqo3K9VmAuQps3PU87ZW2Fn4V
mWlqt2scC3nG0NKOYF5JwqZJoxfd4x32jur7m0d8YhoSUmkgvQByb84OLXPSyuPV3J9miYSRinkX
HtUoQDNIMldJ6diG881ipdxCPpKHKb4spXtD9n8NHzfWOllwXeWiHMszhJRvFTj2uPpdgxnxByve
sxXIO7PyiZR/A9ZuHa2FqwsjOFmu0AzeMSmuzCe4QT+Sr8jKxfSS4wK5qtFPxsP15yFlbVaPLrMz
sEixxcRYRBSslWXFig2NnZV+yOqtJTlXK0xNftiatYZeoOLRAxN1Z1i7OKtE2+rv7eyoEWOstoEP
UL68zix3POuOlV1za4ioaJzyuDUtd/nKrqDTKLjZse0uzVuuaYyxB5tuR6RN06SjcUvGw88bz8uZ
pIAaGrlxRAxL3Yej+Nl3Fi5tu9LsuZXKJzqK5oQEmAaVudct1SY32Gp1/wCufWmdqXO6QdXvpUW2
TVK63GuV3QOFEusjRJez1qLvEfS772o9gnqem6w1UvpZpRWgs23tst0mbzKVvtLrurxqn5Qcn3o2
bKavNvdw9iOpWF5TJ+RJapfJLFbstp++0vHHZbLaFZRlgmNysVSbX6Houmoza+ylCkrhWq5pDDOt
MXnNwm6kyvsZn+o8M60LvUHlmjKdpTWhWrs2oO/eb7fJW7EcjHfX90pmNel6zjW0SGbtNjqNuznR
c25Xeg0F/V7R6KiImJsreWqUjSmmwt850PImHobJNWwvbs9vPmjXXjRHmJXI0mhQ0NKeaa/E270d
kc5qvXMNMgWWj8BgyNUw2itUoBAEZqt3oOJmusTJ8+SOryHlusHLm06dFxcx1g5g416ZsZDvCTXS
HlC4c33SGlesHMG061jC4MazuNFpu1QObaXKZq+02jWyMmqFFXiAR2rFh01pClKOGsV1y+4y2ZHs
uaahC5bYtcoMdZ4iwMZzLcIPSvQtIvy6FdhAd5cqXe+2Z6QioWB5HwdscZjqAzS/qgE2JNE0Jxk2
qcqbN07N9syqK9I+c6Zrdy8311Tv0jffL9p9Fed6n6ho2Eeg7P5x9Cs7B5nu1uoex526vD5lV5yS
hXdYs3nrd8jkNGt1Em57GNjqU1QNCa1qzll/n8+ZECIaEpCeUDEXj0bgnP07zwnaojN9k42HA6j6
Fw7OWJcwDQYUd49BV23ualLyUZHWJVTtT6lWOSgeU9zq9rcUq0v612m2tctnWmWx9TZuXiIyzlTL
g8pNjk64mMwGuI2nbMJh/SGb5D6GGAanpmD6yUrQn0e00HNet1s/WDQ9fs4SToszlNe3JnmXoqkU
XZnlctrFp2jpXLsIPUfQVG0RWfXfrXk2NtTr2vNdK50yekomHty850ks5vfSA5WJFG0Htl2nN6hM
QknmGYOvV/n6027DahHG737QfIV69QeQ2nq3IMh9CWLzj62wTeKS/wARv+h+WLDM6dZWGd36R5Uy
6IySu1KY9Lcoqx5pq3nX0Nm9gnOFHeRnmsISSkhegmlDaDjLJ6PzN5qvfOtBq3O45ZqWQN9TxehM
UpIiURmq07+yk+jDuXfh1cxkj0jJLigw6jnnVhI8+PZHZk7cRUkpi9R0b9HMa97R7zmldUw+ILW9
swyD9H5xkXonngOo6hhevRlh6N6ZIWnPoyn61eY2MkeiG/STpMZTtzwWB9N0WqbHxirBTmltiZvM
cNRdfQPA+XeQrE65q9m5RT1a6/OvqPczptp6xjacVQr/ANs2vXepSU1H1LQBWr5Vo+o7rntmZ98K
yk33pi2eTNO3zzFEepsxwr01J+aPQrvrHWAUe4M6FivpKfol3LENVmMc3KNdYlrlQpe0Qtbt7mkx
uqweb6m3wagkgkqSD0Dpz484WHXrFl5IOYsJsOebX2g2WPz2Ib8jIgRmF9tK0GpwehsKHepTPpi4
U+L0CKpF8c0KdtFOaX+Cp+gnn9rsNE7XWs1zQm1EucpRJO3VKI0GLo9+c5jUW41DSMxi9fqmea8r
HdEuGUWO4tGNh5QL11Us11Gy1uzNqDZZGoaATfMr1mPTXq5RNQ4NDnoCLuDLLK2jvfblnvHRarVt
FaZ9d5fP310p8RoUDUL2qiWCz0MXetQN1b0y0yVLe2uoMblF8LQ3husi25uWdUjR3tKq3KytbOei
Y6dTEybhmpw3YOeTQ5BBvGzJ2jg8JmHTcOUNHKmiO62rtlHcUkQQaS0U0ceETCiXsfJRSLtxw5Rf
dj04RLbhzBpIwYUJO1R8fPlBSkhCKnYtlYOEFKvoKWkmEPPNYad7wLmcgeFjj4ayHXpOSgOs9DRt
obRNi7V+utx3uLityEzX0WiKhrOlpPcoaZ7VqE5BM/MMLDzrj2QgJaWjez5NT62CtQQXbZyPjbFx
o8Jz6St9jKtcXtFnbFSzukM6m4yKtbXP4pCX164HamNBvfKj6M8r1jc8smuFkypeuZu8u2U269x2
KQw6WnYanm+yuMS0e+Y132GjTdlg6hqLTDqsg5HaFxGkNcV1eSw7aJWrRt645tq3PMdC7VbCdssu
H72081wqQhJAxoISnjEQXfbpmOmeD6xIbyVVls3k5TJa805kCIjMKcbVdISuX9pSLu7pMzYIGOtr
OnXbtUZ50cTYI2s3U6TaJSqO7BEwdwRTbc8qExMQbC2NY+bOr4xDc7jvScm0qcy+V0Ok1LXo9fZ1
X+stSs2XGP8AeXcBPLr0z1qj5/INOFpyS0WnLc/d89WkbG1Q9yTGeXXX9wpeX79F4vsMtlEpqVOt
lWstLO35DV+tdvW+U+Zrtvqdg51MSMtE13XfPG7w+RtvRWSaNmWYem6ToGA5KHHoLTc9oHo/PMr9
BV/NbrbqnomMbJjsHtWUOe2eaFs9Kk870pkqvOspsmj4h233Gq3tNEqV6stP2GKgoWz5fhIIiCUl
o5cj4wsNM+psth9+fZDoTerahIHiNG3nIsvj+JKQASjOw+l67bekE/d8Iid61azuKxLumLMUKw3V
3VZ93EolkwFk7VKyOq6+k20JZF1WzOqrNO2zCLwCvp1rec1p+51rL9VmchsGpZZem0rQIa7wsquu
T1+bwRvnzWvSeQXs8jndkzPWa3RNRd07M75qLeLk8jwlDz0dfvP0rvuHU/0lRsZ3qUxvdICyeb79
Y63oUBXtHk6y9ZzzSCdwGW7ZitI2q3ZX6FxWs7tMZtp1Qi7EiY805mJH1JPeUdQ3jy609RZRivqD
p529Owlh8z7NVU6Pks7rJRTNrZYpry55pqHm9ptWo+c9bp+ObZY8L9MPijK1YstwMuQSDI9AVzCI
WDmfVuP1P0zNYFqYzHXIi65Blfo/KMnY8kJABGo5/wBOVy5Oay8lW0BZu9MtruozUlGRfXKLRoUl
UrE+heE/yq1rdUyzyFWdzTWvWpVNtz6mTb+MYMfP9cTrG94fUfS9GxP0HIeeNH17A9Z4T1Y61bnp
mOd7lb5KGZvpVnCTFZ4ZRH73S849KUurbpUYLLrNtwqM1m+BIcehr95Zt/o7zLB+pctxX0q8wv0z
ler0SSyDUHvn+y2/RmstkmslW3bWSyGmzfoPy449UeatEuLym6Fhe888R1/AsmS69KTvk7UPR3jv
v6y8+5t6cb4n6qwXeq3DZvocxhMlXt6fyWTazFqbLseCyvCF9CQkdnlj0bC5XJdo0KpPZzBssTyU
kJNOiKSjlEwjj0tGVvV01+0R7ax5doFGrmp5HnrLnzCVEZGuS9EPHTB52ipNDV4gcHXWKlOcbHqt
bZPeNkDj5ImnZXRhIHFyxMHakcHykOWLDBoLlrG44vU/R1IxzfHeA6Nq+F6aqWcirrsFThsw1zSI
APIt+qOtVUbZ7seFQvpan0baatHOettaNn+QYyHfou6+Y7hv/nquenc1xX0wrCPQDCUVyVCzcRnm
ZeoOSejvKtL5VLT4eFy/WvL2geicMbbO0rNpVDtZ7n5oqxyvpl95e1zXPNp+jMmyf0uywHe5yunY
zzW8qx2j+hRVb7F4hsAzXambOs3CDj7eisWhvXcP26VxzU6xkjdKSBEBoiufDlHwPO36FFyMRZ5J
62ZU6chuwosbxLkQMwRL6WTSYer3rrRbHN08XSvV6786XaJen2Obiaxb2FQt0jR5Wz1NldYWt3Tv
RrHP0o7lX6/fGlburinUhki8X6nwWjxNJvrvO7NZ6I5ubaMnVwq5CsU662GvWDlTJaWrNseRlOsN
TToEbUbpJ1J1PQsZamNBjuTm9SFGmbJUOFti67cE1OwysN3kOUDM8a2djacpSMiJxs1mERrR5Dvp
WK4SvJq6cQ/SQjIjmvtJuYtcjG85PixkOjGT6xy3zSNeOY3u9i+0nHtZrnEOpKNcvmajgw8k4Vop
LifiIBCSSRJM9DVy5co2C5zV2jZSIsLt3x4RHTg361hhz5pBoUAQU5vMnU3Vmr8bdI2s2t1UJicq
/G3w0Bck1Sdlqou2QUHd2lRtj2oSllrEddoisXZVMsE5Tl3GuUxsXfQ5SjzFpqTG9wtUvgaWDhAz
3Wq0zgld3ns9lLtTbLMUZ5b6nF3+Hpug9M/tc/RV3urVvSY3MYYO9EudA5aRWaXqXLMr/PZlK6HQ
69rMBnGrusmut0y49TplE2Rpkul2LIbFo+b1/Zq7lWzOsY0C8ZIjYaLhDdPbTNtoGW+h2Xn3brRh
dh13P7b2aVy5dPPd/wBNyydlPPek6/VMo3tHnC3bnUZPnI1O3+Qi23V8+wHu21zXI3zBXSQRpCRo
oTzRFwJbnbalocS/fOWsk250qv37J6GzQkgaSBqXYvRnHLr5YKI00iv0DXG2VafJ5y/u9XqetxWY
aq4zK1WmmQmp1/PdYRlmiTmcuNCqdO1yLzPUnuW2q30LGINN19CoynTJvK5fRaPUNiiXKJGtsbJW
887Qz7dXWCatesvuRxEj1a8ZIQs8K9Y27NyrpGSSsbyBN59Hx/Xpyfw8qqFsMUJKGlmRSERKNWs9
WZrpX7JGG7jpmuSsrR7ozgLKx7Rz6Vz+9FQb/wCas5D30/O5Xw3nHKR6YzDNdy50/XMd2Dzi83Dz
1v8AV4XXsFr/AKMyXWW9YdwL+cyPb871fJNfyvBvTzDI9WmoG1ZhpWFY2EAJNB6GpKExtd6+uKFm
3pC149PWTOb9ae+WYb6IouNRvFBJM0GZ9NF9EZzQt5hMm0q15G41/M6lulUzHW5TILDqWSwm60XO
Nr54/e79jw2rNKNusFkur2LFZ3X8fr++UfLtv64fQGB6v6Eyqk7/AF/GNmsWF2PYcZvj5/ncTdK7
c4+Esdv5Uy6ua1IV66Iol8VSbQ/gmlna02/Jz6/Lp8vn3ncap6HoeiHQLt3rfWfj63chnmjFSbLI
QjG0tqRoKs6vy6w7mmFeuB53o6KTaXcI2sfOiaGecX/zVlypr1Gvyluuv+SJn0/gWa+qq9jHp+i3
XA9lwmqer89pXorML+5zbR+dUkatIyHlS6Xjbcj0Rjl+kV3JfVdERac00TAMl5p5gzQrQyIFFV8e
t6Zl/ou5Y7Mzud36Os9Swj0PTMZjGyTQpJmFKuvpLJM59J1/E9aueEyO649SfR1JyLbpfC7PsuJw
fonOMl9D8MN0bSsKG+5JnnpGtYhtlmwGybbiFa9I55j3opHn6tcxo3ozGc89O1PCd7sPnW77dgWq
tp9oilJ03EhNXyz5TMaJXnURaE0+5Cp2XpE85nnWrYdKuaKzNZZg5ah6Epl5Ok3XhDvHSa/ZHFEv
nCqWpu14SXeoW9VGv0bFSiesFOPaNeGlatcT34HLU+0nULv5Yo/SQ9QcvLm0bb4+m/V3mqj+p6vl
3pzHNhj6EjOfQeYVb0NlGoQTKy0S1PcP03r5XvWm2/O9hi8m1Kr476jyKeaWseXqwlKDBJXoQHJE
ZBI3O50TUoSXN6ze0l9xo+k5lnjHmXMHyNZrO/egMwzz0JC4pr1oxGW2jKqT6FqWQbXKYjbtTx2J
3ajZXvKMO0+94mvbsupG9QONbLYMKtWtY5Bb7Rcn3sYLV0nqG55PSvQdcxPcpvz7oGqYhdLC5OQh
20nFQuOa3pHn2Q3fN7FIZ5O2qpQWjRWf6crLb5P5y7v1OqupReCVfnObrbsxVptRomws8d1iaxyz
6DmcLsVZyfbemHada8ffazm1K2+LxbYJnC7xo2PR+10rLdvRiOn27GHevZhknNUz6BjsK1+34LPa
7lVT3SAybYJ6lS841zfQ6rnOvyGexGlZ5BajD0HV+WS6FYM0f6BE57o0PQdAkKpC3qmVbmQ5pBkn
Rknw5s6/xktBYS1etDmQQwim3Vm6qzHhy5mCSslF0nL7EQNs60uem6ou1Q0HbeNVsMrVHFlrrG0M
a3a3VSlJ+tt7TEQlqFRsMvUe9khIu3MqzZnVPiEFP3CHhLaip2WSqTmxwLW0phZ3vBiYgK/ZZCsO
5+A6S1YVZYBjZmMFYe1bkpit8LFDs7Azrrc1Ss3FNJvjDzHSJdSUS6k4jnNMYTsng4k2vd+yjpbh
HzaouWDWGlVwT+Tr6UHMycdWOR9ZGwQXGdZxU07rMlOwE08iETzSnISpzZ42Rmour3OPrV8XV7cv
hnlpkc/lb3TLvncRM6BSaZzCAlJgtEMceLKB4WDSYWyVW49ZImDJkISdokQ35pIJJaVGqe1JlULk
+pEpa6pH3qJqN6XRrLYKci5Qdbv3Ck2+VpT221aHvkdTLy7olisFMReIKr6DxpFtlaDR2qbvpsbT
dA65/aLDRl3it1/QmVFvUhn85bKU00CvVLSOGfXeaz+Qu9OhNMg6Lpas3uNlzeubVnMDskXjNUR0
vm51jKttVi+jXbIOmwUuxPYyFtvPFKP0bWj0DU5yX4ZtqkXm+sqhbQxe+dN4cefJL0H5vp/Z56S6
9/MFSDrd9czLPPRtbwP0f08/6doFJutXmYNNr8ywhR+i+isy0Kp3DNtA5ZffuTrtUdT8p+mYvB0+
ofPG+4blPpLtL+TqyEgiBp0RaEJYV5vvl0zPX+K2ViiZOaja9kGuUTJ43mgERGAO3oOyP4mSDGQa
dQHcTILYSXBHfg7ZdnTB9y5u2rrnzeMXAbyDZfVq649OrR7xh8Hrbj0dMSLZyni8ad+rF9zT2bu2
ynca+Wxft1HxfRzp3BzfFlKNV8ejyvO6BsWS2J/KZVgROvQ+m5fWt/znM/QdeyvUJ2jadm+i4avY
MotXKhavb6Rbc90ZrVZ6nZrs1XzK07ZiHoDH6BsGgeftMeVrQKBonk+iLlvV3DENA1Pz7y9KYhn3
par0bc6LbPLGr3Cm6FwoGrvc7vdYtsdS7VmtJ3zE872XRsf9IecYje7N5l9A9su1XKNU8r58lBkh
RHoiSImFe4epmeKbvq2SNNNzGbvrynedNsbYRDcEkQBkpSvVzSclY6EtXSi2+RpVhk4RlZedRt7y
jWiQrPedZ1m5daLcJGlzUtDRtnKnXJ1R7JK1btYGVXlvOdOkPUrSySsA1tTen3Y6NcHdXfTUXC27
jTLwdMs7yAE+zrVxTS7qKlYH0OzsjeoWfzn6Cz278pPPfNyZH0tdPK1+3zzhC+nsvxH1EWE+k61Z
cY03KL1KZRYNUf1+Vqly51uTqrmFwG5eh8KHo/zDp9qn870ivxdrznR/KFF6THq2veaPQGmePbp6
h8s1j1lnNM9E5LrGX2vzz6IouWWrR79WrZgu8NKDcKtZcVzi9egvJ0z6u8db67ufm/0TnOnoxjZf
KFEQkAiItFNXImNdb+lX+ObzcabX7vRbIXN7gW1xWGxDdAACiJavT3SVc8o2Y71exuK3Md2fCTOB
nu9cm+kX3ciIm+9csDityndpwlFwE44rc32i+z1EQvz7Un/pbrOLZ85BUJPnW7CIl/15sJNcDYyg
J/ixcdRHSvSAsHCHnmaTDqEd4Z6Gpr1zMY1iKXnoy8eVLx6M8xQ3qvIcY9QHiPpbM9QaVSDuDaiQ
VL9OMbDnOmVlcpDzma8GumeQNL9J+XtbsM3Q7rmUrfKBoXkmmdZv1dXfNHoTR/IN59MeX6z6vz7N
/SNMs0jSptmtpklP9X1az1qzZJq7GsX2vxGea34/2L0f5bueonkWw86vU9WzrzW2SkjCTTohjmhj
BNb7tNL0Cm3fjPtG0FBTlA0bNKE0bpMwFJMHfdk5UC7y1CkbdVoDQY+kXx3QLDYqc1vURTtBLP7j
NUVzc63Xb82oN8fZ7O2ymMb5D0rR055cp/NcxYL0TXY7PNGeZlbLXnhaHVafqTPMtJkstsV4z1jp
1XoOsc8p0KyZVL6NnVf1mvZxrS8hv1syGd1eHyzS4DFIwPd4ncFu+o4g13LPcy31hj2uztVlpVFD
uhY5GbpBNrZVM51WuM9DKmVucyvRb3l/PRIuFs7qgy9kqmYEuW1KHzvRHuZWS3UOP0OEp96kKrNv
WtXtDOivbfGIl4GFtEOqbRCNXMHMvYgTDPi9KJRIQ7JISlRED0Mw35NoFo5tpyMTL95A2Ddg8i5C
AYceT10jvH8gEqXMdY1w+ZIlWLWxFCyUpAcH7BtP8op6uPcO2BSDdk+DRx3ZG9ZNpLkyfKZdHTBo
ku8gGjjoz6O2aH3Fu7Q1cdmXRy1Jxz5OU8OvXgjvzR1Lj0Pka+PRaUL5I5g+6UdAlZclGAZpUaVc
zILSRpM0qIkmlJq59CUQJIQkkrMyJQQsiCuXQwkGRpJRKAIwQIEgySokqUAQIiQgJIJMEWihXHk3
rzSw7RV7tSL9wsXFomsylCveeU5nz1mYR2yxtx5qU24pU6dc+bvgrcOOS6DbsgrPApfW6dVkm3V2
bKd8+DlTTpLQzFJoM0kFGkERGowaDBg0LIzSkx0SCIzIEoEZkRl05ktIJRkkIUQMEFpBhIMlAiWR
pI1pQpRJUlXMwQCFKSAQPn0IIWg0giWRJABKIwCIwhSkhREZpMBJAgZJJSVEZAkmlAUklJPQ1JSl
nXme36Ni+02FtTNHqru9x8R5+1TlhcJx0zd5DOmjmAS/TmtabzOtyFW4XOrZ3uU3gtq2LDKSzdbF
tGc1KxuaZMT1CsE9FR9tLN2WiZTUkEQVzWQIGSiSYJQLmsGSiUkjUSTMlBJmkGQClc0LBLQYMGkJ
6c1EYIjMBBqVx6EYCTStKkkZggCUgAgDIA0qQACM0kQIAiMAGgwYBEDI0LIEZ8zBpIGRpCkAgDJB
kARAwnQ1r5BnXWXoG4YHp280Cj7JnzHSe7XzfoVs891zjL+rp3KdIZRLR1I5ZkLHTtko7az3WJ8+
6ZaMIndpxKhNF6VvuaQuxRtfmbhTZSoRF/skfl+W2ekwaAoISsBZIWRJUEg0mYBAzJJrIEo0kYME
RKURKNC0J6ElKwCBkRpMJUCBp6kgwokmFIJYIAlJC0hJJAC0qIICkdEEoAJIgkjBpNKiIGhZGCCQ
DSCIAyCiJJmQIyBERgkko0loZr5I5V5lsGrYrrtq4UnQKZLP6XecA1JeGwXDR93fV+cpMe+mpHPM
ejdM2XPRoZ9cJ0azYLYdnxnN2Asvo+Dr+nZM01l5GvKjDXlddpUDo+WU5JGEmk1ElaTBJCgQBGCM
BIWfNRqSaVAgRpNR8zUaVJNAAMAlJMJIwCMKUaefQAJUEmQSDUkGCIjCkGCBGgGYSRrHMwlBAghS
eiVJBBJgBSUgwZEaSMjIySoghRAyCTNBkCMaIR8U8IJjK7TE2ml30WLjGsqRcqFes/pzTnpFpiLI
5ka5ESrqoUBtMbLJ1jpLozy5zWUTehZ1n7cddcnYi00Gnam9ZJm42EtSM9qM5Xow0klZhSUdBy6p
6JCUhClDkDJfVKSMBJr6I5Ah0AIjSsySaVJJKgtSASenMJUB16ISkEZn1RzSoIMuiB07J4pCui+a
unDiQU4RyQZE5Xx7cm/MiIkGAZpLolJpWkgZAAkgEZGogkJBgjCDIAzBEY0EDly5wUf1tD3uwle7
82qISXhH8RHNTLsOg6FyBHYJirx71xxnntccz0E0srKCsHRlNiLlnEBBEOM1Pxs6quOZCvxFuiYC
VstcnetSmpmsS8+1jp5NUj2jCZvEdR2nPrbbXVIu31OHJSrjZc+heZS97p8MAAZpUXMFyBOtDsue
VvipSU8jHW76BlUHyJSB11FlnCgkwgKOz67A5KxKX2yVqPS3QmGRfaU16axmrkTnQ9IxPZlYHAJQ
okpUojJCiURGSTIwCCCUkLSaFkEhJgAgCMJNRJPQlkhDeDj7FvFWulbuEfb2PCWps5kGj1LL4vgk
yMjSskj04+xepXq2UfaV5RfLJng0qp0nW2w6uYXq+r+ZcGHXbbFXpjtByLumQmwZhmW03HOLjTaP
r8fm+wd5DkfSlNYLMZz0Cw87QCJP01ZckrWt4syetojctB800ZuvQtyxCPmmiZDizk27E2/Gpcjs
3qleQV/tBSDiKo3ASm47J5p7Oa+8qlsq3o6h5Zejqtoe1Gp3+F3qWkclqEfbJ6Xuz3NtM8uUnUNJ
uEFyyuoW7h6EVnNu40vzOEEaSURBaDJINSUmZERkAEgECMgREZGYCSUCAMhoZhJcK8x1jZMJ0LXY
3MNdqbDVCj/Odnvnn2qt+ZAgCMwXqyOw+y61UoXeM7om4Q+W6RYspda7mduEjUape4yROEf3/rX+
3SR41qazPXM45ae9rsvQC0SmV7R2E2wjZyqUa/5zlfoOa821/lc/UsBhFy1vFdMl2tbvjzzFQOa9
i3DE9VcLePEM5AovhFwfm/iel+mMzY6cwjJt9WvMdefbRtLvN9IEI+xHcvNvoOiOLpBMtBVTsu3q
kW6v2CuTfbChs2HaRZ7J5nmNir9liJSEs9Lsk8iuhVf8lKBIVzMyMgAZJBGEkRgkrIjSADSCNAWk
zSQAAAMtEBJHCBjtY2bArR6Gr2UbXR4TTYuw+c5nUvPVTa80EFERkoeqGeG63Z8icegchz70jV8S
2yx4JZ9pxDSFTEMcDCajmDO126xwrU5vnW5nDdpp7W62qMTD2ZdKtjumWfL67stZyPb6nh/oKc82
V1Fm9VUzz5e/RPnnaBYusBKeaKFyPTPSGQ69luqduPRSOLlnFwHmRmu7eqMUs1orllkKJn2YtZH1
YLHVLHQXV5y7TfLXo6tSzHHdavmbwNe9A5poVetmV6Z1w7c8Xr9OvHonMbv5z0XSoNxWtWwmjajq
tMe9KX5mMiSpAMAEZGSkgJIkqQEmoiQauaiBpBkZAEYSojBHoKiSnhBx1v8AQGcXeXk6nfaw5ksw
07D9AXiVe480gGSkBY9OSmKQ+0cantmUZ56MrWLbRYcJtGwYxe30l3610p+uxWW3rXITr0Z9XNcq
GyV/ELXtdefNXLuHlOkZIZo+tmcWMsZcehWXnGERcfTdO8/abu+E6Jysht3OH09XPQN0yO/pfisW
B/Bt5Vw0gMQQu0egcgZ62itXHOPPstJONith027cs5lLvkec+nqxXNM4Z/oyM1wyehdI3Cn1i4cu
lv4QlD0zNO+d0Sw+hZTE9co9t86bdomDbA080RqOZkZmSQlSwkLSSuQ5kRoSogQJSQCUSVJM0gGE
mADGhErnx4wsb00KVewsy+nzjm9OtNQtFVrDfigiASZKM7/cqbUpC5NLTXq1fedFt0pSJG0Vlpch
FTLiK4P4mmWC2QkwuqdJ2qPLY3oj23Qs04rL+UhOVijYGxxdWsEHDy15hKa35yd4ZVKbstZdLfMH
ze33t1X8y71t3MxvOPdOWvFwtLrXZ5Ge0yFj59UZIR3Df7InOM3atpEoZb6I6ybfhMOIPqUcbhj1
dszI+jhzGoU1PmhfdKnUlCt+3NPVu8k4BoSjczjSH5qLtKlESMlCTfGvNyQDIgaTSZAAgQAM0gGA
QBjQgrlx4w8aq8P3cfK9pfq0RX5qpWSBrHDlyIgELMj63y30qrqm427TNKdXKtQd9jqbeXsPYRAT
LmvU1mOVvt8FaO1XcTtQgNDgKNZb0ysPSIi7DVntjatH2WwVkYQFl1WLyWNQfdY6dEd9cd4/EIkd
GueWVrkalEQVyVyQ3LrYNnquacC590c+yBJbdVMsINeZm4JSloLTdi89Vgudv1bA2vRLTmhVy9B+
cIUj59+bVfV56AvGR4426F3LQPRHmXO09p7QtwhfN9fLpY/StNwX0Pb/AD/6DbeZqFzBKQaVA0hJ
LSFJIGAQBKNIAGiErkG8LFz3omn2WQl69fIfnaq1JYbeOuK1xqlBEa+QMdPSNoxKm6Tcc72xWX3S
y0Flp9YoewsOhOouHmeWdpjG+4WWqSXPr05xlR1/Oct2y4ZvynrG24Lfwc5Ez+QZxqyMnjvQ0l5s
rfKa08oC5lBRe+L8v1rm52694ZcZSGmu8eiXbw3LvTqGhVs9IZjXNEb0O6dqFcpKApHorMazprLJ
6WLTrkQpxNcc413RfN94eZftlpwo9BisNqZdNg2rzjq8pHVrRWOGSeqUbf8ALdQz2mXGr6PxzDeK
754o2hb9L0G8QEJGdLvaM+jtRYVtnJVLzCgIANBgA0kDASZGDSZAjNIWNCI0DnAxGgeicJeejeGI
bdBUzX+6fPTXasCojRPNJpWhRBfpGZwez6rQIf0RnuY7y2xfSLzibnccnnbH3p1buUBbmkVKW55W
pLhIrqdixfXagNEeYxTdgcWeqW6tcLfW7NG5TSdtq+JbpbvM9b5aZ6BlKfdjjWUvF+Yatzd+gtDy
vYYCw9wkKHOBlcXxfmLV6jzy19ZSBsb7JtJbO/OfofP7Mqm55nHXVvQ9VTxsD9j1kcU1x/jz3R/O
PoiQ4+dMnS4070t5W9BdhJO2uOaZZKNdaPeMf2nOZSyx+d6tV++A+iMf2St2vLdIlfN27TEJE2d/
Xo6TovmFAIlBJGk0KIGREZgjABAjBAaCownjCRN49GYn39CFjOv02H06haPg/PYMGo7FCSCFAGY9
G2LB7fpOf1P0llmS+kmOGafoGCut/wAYvbno/OnReoZbDPbZpMO3YWvlXZbEdmgM+t2p47MTea7H
DWDET2mCtbWtZtqmeZVvlm8zVk/R+jPK7Y4+STBq8z1rirdNazbS6HpIjZE2fbtESGP4dzVNeq6P
bIaxyjRzmGhNZDzN6QpNmiaHVaH1070LBsWNnfnBz9PspZnDbXnd+pUdktLWeoej/Mm7QHn31NWI
vOFaPl/pWCcU7UaotrBQW21mRbYnlXp2dlcf2RPn7OvVcb5i33U8r0B35xyhCSBgkkYIAEAADBAj
ABkQPQjCSbRUTIb+2dvJDjbYvm8yTVMkufHHoFunmCACFrPddFyTOdLutQ12gZbvTfDtVuWJSOzZ
Y6u/RvMsWnflGZHZ9grkoqtd56kxGvR+KSW05bLcsl1e7Uuv6IxqGtpzmTgsmsG7RWAQ5a9qRset
btJk2zXkbDQ7nk2kvIKQol960ixt5xvU6w64NtopTLRWNDvzOs6weSZl6BqkJpTDL5Ts4tTWPtFu
zem3xhVrixr1A2eCY3qFo9oEVzvWY6FB47e9GicQjObrRbtk2jUK+1i/R+Yal1z0Z6uZ1SmK7NHV
K1uOzDTZHM73C51zNBAuvNJkCABqSgKAIAwAkGBoYPny4xkOJu0cllJyLlo2gJWHkIyE4cuINKiB
LI523Q9eRPlLJg5WQg+8nF8JhEdYekRJOI+Nctol3YGEo6guMzCtp5US+koxt3g3c/GsJZuwsXWA
5MWDy1Naw2Q5mu7M3zJupxq9sVS8tZ8uim3aZ5x3I+jzpKay/Z5HV+Su3FKyuno3N8MTJxjcFoWr
vqhjsZI+lefnDtYV1OHPpOWGsw3I9D0R3Qc8sDNtYq9XeHNBmSkgALSkzSSUgdEmkERoNZklPIiB
EogAkiMlESiACVEQNSQRgtET15o4RMN00ezcguYniarqVioFni8/juHMAiCkqSvTdLz3P+10r2hW
nP8AnpFSqWqMsz0aYgrD1r0o/gswjePHRtFqttXWelmplK1yvdrW6r6Gmc6RYGWaafDwmjimQ0HR
7Jt/Hz/BIkdmTkk7s+S11fPk6Pga2TDkcv6Ho+adOitj54z0ctk9EcXHRssuko3a2PbsJozx1ZPQ
3fIc3jX/AG7DabonLMKlbpstipeHwnaU9Fq8n6jveY2Cz1jzLA8QEKIgZGRoUlaUg0ggoiBklRAI
NINIIERggFBJEtBmRAGAQAM9ACxz4w8NMem6hw0x7RdBiGN7bd8N5aVidCZJIJSYBl13fRsKqmuW
bMd0a5rcrPnrbVqRSdohOrpPKjWR/UXcVH6/P1SSYTgr0lQdQp2aDXJ7pmNJe3C15zr1eZWAour2
DLM/3m7eYq2nTvQzPzrN7PkOiSEdD2xvWLE5zXIWZ2/0lm3S5HX9IaYhqUlXFT0bDWcQ7R7Wbe/h
5G1Zjg+4TXC5wE9BQ75VmY9UvM7wzfLbOZzo1Ti5zEtif4b6Jd064ZnpnkeiIAQaSMEoElSDIyUk
BJgIUEqMJJKkmk0ggRgGQABAAwkBREZADQyBnxiYOe9V4rX/AE3JYJs/LK9lVK4ZQ/SGFZxHcAaE
rBA+m7aFgFi1fM676UpOMb1I4JfNXwht6EyzveUw9csVI0ysxVhuEjXJFjL9adacI1eJwfT73H3u
AaVW1Zfnvo5LK5cIDDN1ZYFsWg+Y6ui0en4fz9YfR2Sa50UEM6bf6zS8FaHYfVNB56VzqFmh6Ptb
GA7SEAzvVRnuMnmmjxU3lOu+aufoZ7XpqFe1zQcl1ONj5CNf1TjP5fvVCvmNbVn3mre7xh2r3ODs
WbaV5Do6DNBgiCkAgARBJmCQakgGCASDJIIGREYIwCAMECMAGQAAMaEQNHKLhZL1Nn8RuDvMdErb
C/5dqOQwmyYrnbLmhJkZJ6BW3ahhkbskfmfoij45uMtgt01/Co30VlkzYuM+uktL9SIGtzu3Qi4e
0cYh7jmxNcS3KpwurV64nToOh7X0jZJLCk3rIKbv1l8yVlDz1DM5HE+i8u0qHsJV2vM9SwPMWyyn
fUVOgdL5UybsVXuVIZ2tt5t2rRPMuqaC5zjQlNMQ9A1rz3Y+w3QqHa5CsWysd3Ll5EM/Nrz0rI1f
jZuWHbXM+da96pqLqxU/y5H8yUhSTSSkmCIGlKjIJSogpIBESiNIBAiMAJUkyUQBKSQM0mAAAnQw
vnzRGwpareI2Wh7JYFtkZne8/sjXLodvzIINSFEs9M2DPcvlNbregV7LNee5DcrxlaNao0JpXaDs
amDCXicpmtVrUw5pre50htpScuttcr+rSNenXTGn3ddQsXTP5qs0Od16JyKLSvQ9CzvtpFJmKrbG
FoZ1+3ZpF6dKt6Zba3X7EqudbpT7TJ1CdbZnfZfMO+gMuu6wuCVDRmuecCc39xT7XAzrOxwMHeGd
Ti4ldmstMstWsUXbypba6wMJZKRGK5pM0KSCAAI0GRGACBEaiCQCIEaVAgklEARqQZpMgYIjAAAI
xoJhPPmwgkS9iQ5aybt4hvFuI/ryhm3DiYIjIwspW2MoJo+N/YIRnZW0HPdoGSmoiT7xbiQj67xT
xc2ljLvIdrNxcDYFFOIaOnHCmMk22a619lZISGZsn9350hhyLt0MI6KPpc5Kjx1wsNWtLhrRYLpc
LwVZsjiHsHOHb2OMz+wN6g0Fs2xWF14JSZpB9tCuWeU7gTnSbVlNSU+0K7ZvSORzOv1/M9ZmshqX
LiQCAQUkc1JBggCSZAwQUkyAIgEmQNKiCVECASoyBAAEYBkACNd+UkI4sYItdusBaIywy/Ti8rkh
n7uSyauN+KTIgFEBqm1Zllj3T6doV0zyO1WtZ9sDbJ9PnIGc5seT1GSxTdjqupU208GvGartB1+v
8bjTmVrU9xCORrMpYc/fXbNeDLL+u+zPmqr8ZC3uotx3Zc5iN1684RQ9r0rzccpEVFs79PzLuHZT
b1znld1qFsOb6DDYTQeXS8ejfOvV+mDsbWBZWrl6KYt8ZrcxG+l+OL47d9S0qI7YzV53TLTgkzuE
ND+V2RJIiCQEggZAkqUREELIAiBkDSQIzQsgQIyASDANJkDACTMgRgHoAMJ5xsC69XUqnb3O5Xc+
9Q0WTPI8x9BZBlTDkg0pWSiWNf2LBoLZneW78wyq+3LJhsma0ze6qxtjM8uujtpLRcXostVpqHsQ
pdsyvRIqMslNqVc1K5NJqKx7nuGeaM2wxev0/Gdk03zJUT2TbOlWlHUTA32qwepwWKS20Ytsjuu+
b6xI+oZxznEHqlL0CAhp7vNnHus087c+mp+hfPmvWThGP3OE3PQaTeqhbq3IIxb0HmGBWz0NE26n
XGpzSW0vFc5ODfeNmIQRKQAlIBAwkAGRGDSASVGgGk0mYSoBJGCCVGRAGRpMgZAGQBkehoUEoj4D
v66zjPfRlwwvQZPKdZj7Tl+Qek8myWM58yIEFguus7RgjnZM5ovpKCwvZrf5+ntzxKr+k89Z6HGS
EMnPdhpNTslvt0M4r1vXULNiGhdcrk9CRTtIzPYWEFlmvQWNejovzk539pg2uab5hqZ+kNFrFa0O
OsHI2lB0blQ67smW6zUIHD4OR9WRU0h7ldOlLRp3nOa3oQchQfOSTu/qLz1q/fL9hYWXzbpN7zzT
Kbasw13Nce9SYZTfSGZ1r0RRLpke055NwUzZY+vvPH7QglJgiCULUgiMjJXNQIzSRJMjUkEkwCMw
REFEQMAiBGSkmDIGlSQZaNyUEIj4E/SHWoa8mLmmzOy5ndqZWdTyDPWHNBEojSnqrUN2yHOdOt+b
7RC4br9vwac23Gqv6Oz+K0RtLvqsiaio3NePoavO2zxq9j8011xQJWwVxhYcZ3PgzzHaMlofpmL8
+6vPYe39BS/maslt2ssKXeoazp4ppmmt8amNQx/VGdexni426ydWEwyh+r6IzzU4WQotzp+bdG9x
3nG9Ib+a9y0Pv5frcmx364ZDeYeczfcMgjHOJSW/XrHr1AW2t3rnh+nTHm6iklAIyI0GhRJWEpMw
CSEKBpSogZAiM0mZJAURAjBhJkDIAEYAMiBloQWhHBtXudh1GKl6tdn73ixqkpE9U0hm3boBkQB9
EWXUIShtdAa2dvQ7dMUeQt1SjLxGVy6vIGXdtIWYYUx1dI147gI6zQLa2qhJldS5O63YrDG1yeh2
V15VGai4N3d2tOZE/ubutumLrm55s7CVdmJGvyciy1GyjPqizi5FEc+kIntIRakOLlp3aDxpEL3b
s5TYta885jIcHEhCc2vfi4ZFy5r7dOK+Ljn14N3HJqEBBoMJNIQtIMgaVEQIjPmSiCQYABEQNREA
ZEDIAgRgAAgYMgRgaCDPlwbQHCYvUbNRM88dm3jks+biosOHE+ZAKSajndLiaSxmkSt4rcHeG1Mu
j+ky9nhJx1BOJWNo0SlMxosLYn0FF22ApV7DK9sKrQ+HMadN5nfO1T0bvU6uxrkpsPTG4Hku3bLR
M6Qhukn+4T1I0gqjOv67lUZ0m9kjshrnGd26WhZh6VfsDXJs87Ses3LMMyaPvQF054XC73k1oueW
Y+xHMJNKVEYANKSJJgkpSRpAIxzMAwSTIlJIyNBklZGkEskGklKJIBgiUCNIAUSTBAyMEZGWiIWk
cWcBw2y/0TU4iS7ybWTJvTahpWSZ2x4EkEpIUFaT6FybLZzWKPe7lRYjVqzn2ws8r0+Yg52Hkquq
w5Zwbw+r6VTLJAznBPLOtUiIa5ZlVO8rCwO5WHF9pj6rfYvnVXuT1bcdB8z01vJa5ueaVuWr2aRP
N96XsOPb5x6pod685TrXT5l3U6W0lOFus2Yx+5itS2e4Tqem2aqz2e1a06DA5lU9X0+lXKn2TyfW
kEYQokqCT5qBEkkmklJQZJUQSRGoiIjCQZBK0oABmAgAySDANIWkiMzQoiAAMiMAAgFJ0IwCJjX+
Hq6EyP0RfckfXrMLral0DAvSVCxOKbkk0GAOpaT6Bwiv7jFZh6A64doOkYke65TRfQdbqWoNBlt4
hp53EIvT6uzMbLrqNqx+2v6hcWqLY5iIuxN/O+szlP05vC4PsSsF0jXvMdMLWN3fVay1ua820Ti5
9JWjFfRJ8hl+pZPqkY44uYqSkMUc6Zg1Z9EoeTHbMofWqff69P0y8VSqWGzx8p1rFprVg8j1tBAE
RkRGREZDmQPmZJMJBECCFAiBmlICuZhR8wACIKCFIUZEZAAAAEACABkQMAEZA9BCiLm0gOfp/jj+
/X3MF2zOr3FT8BhnomiYlFcSIINSTUeg+icRru3wOUb2vAtG1LAOvobHc59O06vafWrozr1H1uo0
R1M65FvqToSalZ8Xu05jTjQb8ilNL1Fu/Peq2auWaCl8a1+kYzseoeYqcXoPSu8ROZ5oPmel8u3o
+z436AhJtLB7gGpVO2vpWg3d/lupZnHQ28+a91jLBHSODD0HDuKhpdHo/XVpCOeU63QXfybH8lJM
JM0hIIkgiSY5qIiIGhRERBJgiMEAkJMGkEDMgREogCUggowgGAQMgACABgjACdCMzRxbwHHVNYoe
lVm0HNNjpDgUzRclojHiaQRK5rUq6+jaJjktsNS0AsK0vQcPd7ZldJ9A1qhayptNM1xztplLHfK7
K9YmAulbpGuvqLPSVdm+9d7SXKhaU9pFqXRHDTH3m+H5/rqdC2wV6df1egujjNPe0PRafMSdwjfM
UNwtG4QdUtDWUtHSCyjTMO0PT4+kVagvNbuWUX6qXKv3xhnmjMapzueL1Xpz4KC1kElyQOQCTQZk
k0pUk0ggEgkqIiMwkySkGQBGaQZAyMgRGDCQACMEAZAEZAwZAFoSFlz5NoVo8uxPYqddyCGMbzW1
XAMePJJkQIGo3lzRW2cv2evYfvJRvCX5xMv3ipSRinD5rDqTFLsXJw9Yxku0jpJ2yfuY0SbThIph
GnNMrIwjTkw62cV5lyW/nI1kp1r9gPPM6bmtSXWyuMWjCJJqIuhhPSf5wsryigSkpcSFtiK3wD2y
PqjHI6Sdvgavw6WW3iLi7DSa/wA0GhKeiQSTNJoWk0BIBGgyMjIiQRmlREARggAEmCMABKgCIyAA
AMgAZAwQ0IjSni3gmdj1mFtdRuveUJmzjhXrNnVdZckkEGAozsG7weVxtzbSenVmj6u2zPQ5vM5q
+Vyw9odEvwyyu8OFq2as2V5FQV4rWbaa5gNHh65ZXrJ8pxlmcJktsmMyZcs8db5L+dqrwXoOxYfD
OeEVyHeWNu67Mpf0Li1NkGsO2D2Q4veimXL0pn1E9A5tmEn0i2Et03S91vD68q8borIsY63vWbfX
8GgT227LSl/RvOMQgBJAGlIIAA0Ek0mRoIKSEGaQaQgzBKIkgKCVEAEgwSiBEDAABAgZkCBjQkKA
4toJruehZJtMjyg7pWpWwtK3h+20rGojlzQaSNRLVcfTuP5feNVzq73PO43X6RRNugcx1d5X7bWr
JmfW9UN+1rmo2yty9cthVmdzy7oqd6zAavXLJkkJuFSfEmyQrjOLzneWaftHmajcV7dquIafN13D
6wV63TlRb89pVY2/E7tbILBamra7hBXPrIVfJvQOad9Yqud66vOKRuNA1en3KCiZTo5i1+ZNrvst
n+gQEdJ4rVvRz2Qo9z8hV1KTSkwEmEpJaQaCAIlIJIBJMEQIySolJBGlQCVJCkpUpAMGkjCVkRmk
gZGAAWgGZklpANfSc1gu07DmsJruYP7u5rfnTc2uBQjZKFJC0ka7h6cxSqbzXMm36cwC57DhEf6H
y7MvRUdmuyxb7PLhQr5yp8rfJSIk4Ge7Vaw5LJ3DI7RYp2Sr8zhuls5exsycQj/zlrNh863nbfMl
I4K17fsi17ONI82Z723fWF5Pq0J1wv0PkusZRWqJCK9GaM3b94Gv416YpWRep8gs93gKW706m3Co
XHJNdr8BbY1NOvWJeh6ZdMc2iq+XPRMnm23Uy2+P4EkGEgESgXNRAlpIcwaUGEpSApBGZABJkCNI
MEDBAGEBQIyBAGRGYIlECMHfVhSCaQTTeL5iW4W2Fq95oto4Rsvg+213D4nlyBhBmCXafUuS5vql
jy3SLN5/tO0YTD+lMpy70jE0XXKveVVWAu8NUoOJ9CsJKoXdjGy2OXi25P3tNyFRtWR6xh+izMCm
0dazStNxvP8AdtE8y0nivZN7ybTa9Y/NVY7ejLK/y/T+EDjPo3ML1EtsWqx7frArM5n3nia9UU7C
PUHaEna/Scn0ahb5aomsXY8+0c6DZ/Ocb6LtkBX7b2wPa6Nl3pGUzHz1wQRqSkAkqIElCjCkESUI
MkkRAiLoREaVECI0GAFEkyMAGkyMJUDJIABggaTA0BKlo4toVpP7tW7nRL/0sHKLgoScpd0y2ss+
fMiBGXRC5r0HEZHG6w1sslj9rvmWcdapFH19rm2mTEDLPOVYn0Zkz1yEeS1dql/rNd0mRp025qcr
OVyk3egyOgJzufmM6s0ZSpLUeGXRPPpodyzm1ztbsVnELEsXm60jDk3imubRETN66V2ptIeyV6ky
t7iaXbZeqXJNFiOfSXt9SmoiVjJUoDrFlJ2eqTMPLxEhHR0/LUtqlB918TU2QD7d+bRBuHC2wNhx
SEECJIUkzSCUaUkpJKIEZEsjIjI0gwCIwZAgRmQIwL8sEjjyh49xZHL+Nle7/oz5M3EY7gmfHigG
glkFJdW3vXmfZ0mzcIac7wT6XgSsTJxIseEmiuxaR1tKXckyiJxvVpWairOuOTLMo+b4spGixM3a
qk0OK76BI51BIJJqBur1oCM1rK7tp+b0BJI6aPxg5TnC1ouhmpQSV/lc4s76h8F8+SFdOqiBHYbj
l/FYLmSufV1qlvyujcy73jTMOulxwBkuRver57k7ZWraqKtXNDxrM+XJJhISAYSYBGEAAAEZGAEg
AjANJgEYBAAAAEDv5g+ZN4SOtm6Ve9VS5t7U0bOqw8zPSc6zmPbJNXIGFGJv1HVcXj9OPjr9ZznY
eeTabO5fKaLXLAyXEdpTLaymKvW2VawNHETYYvL9OeUfUKJEaMxewXGxR85iFF2+/edrRK5TD7no
HmmjN0AKCzlfStXym29a1JyFXmHzCA9FUnMLrwotfTMXiuWpTtrSdy7496FYYFZZqrUBn0t2h8oC
QeV/YLF51lJVm2gpOMZXBvv9dd5TT7M13WU8zehz8dNbdtl3q9syCoP5xndLt1pVl8eQvAlpIgky
AAIwaQSVpBEsECBgyBEZGCABBSDAAIwWgpUaTb19jtOv4JrWlRGd63Sj0FMJ5z1l35/rzdBGRGSg
c/6uyLM9SvOTaFfsk47bl9J3+rZTszqh6VB2DG5m1wFqja5okxXpeEsSqlY6C/smeaRU2ehRkpjM
rqFVuMVlDzXfPFf3Nrhdy3vzPROCQSjI7N6dq6L4mrWCWzS5P+OF7hTXtqh8gzAtR9AULQWEhz89
a53x7fo7K9xEL5YhpD1HZxUrcxiCmvPW6Sq05bfaZP2unXCt2Cuz8Guyl52seq+R570bW9BqVuoF
3beWbRv9G0WqWfxXBclguSlJIjBGQACUqNIABGRkAZEDBAAlJBmkBRJMlHfjSsg2gmW26155v+81
HOtoztvoDXp5z06w+dq+2QQSRhRKnfV2T57vUTj+uX/z3K79hdV9L53jnopeVbZVrdV3uZaVyzKT
t95ZPqVeetWnsyRo+H97po50S7ZFEbREWWPhcx3rA6Tuzvz1fN28zUPiYV1CVu/U8VKNXliSefWz
lO+b9zr09DZPF1I9R9BoKALFKfv835m9NtK3p2cRWJtZH1dGVuH2Wq9qvdsY1mOx/wBAUq7UBvf8
51uoz+f65lWXX/YPLmg6n523zOsq9YUS+4ruNY8vemqvm/pXP7j4tjuZgkkAkwCIKIglaUrCQADJ
BmDSAYJKiMlJMiWQBAxfgOpc2kRH6HvWXaW7kqnfqpJFQNAw3Wa9i8S35giUaTAlvWlOxyQ2CoTl
7wCU3fFql6PoGQeguuTbC0nXMIahHUKi+j27tjJVefRlOjWzPZSV6d2b2tPZyi6LzzzvpOYNLBhU
d6As3myo8nlhdLWk1ehoeCvK6lbCp1ylalhfoyuQWicMWg3E7sPWBkefmZt6d7ea9W1DNr68oeXS
HTSbmyx/Vql0z/d6baIbz5s+kP8AFcdWvdrjimrUW7+eNS1LGtWf0iuYk41bYMmskHa8p0GlZptm
h+c6GkiAIiMiSZpIgFEkKIlEAhRhIBGCBmSVKQDSAoEQBnfiJaOXKIjnGmupSsWhzNKiWEBN1iyU
WIa8kIMyUQLr2095Q4a0SDuTqDq0VllbWNZtfWr2GXi+77lCyXKsNLjzKWiYKwx8XZe8U/cQXeYi
2k60hJHlCTb2LZtIvraCrsenQNsegzaZJU+DCWRFSrx/6OrfneJe8OT1N81x5BYxGtS7x3JwbNXV
u6KS3mb45XQ2zckc1nzWTvcNCa+Y4JRun/SOlodoY6SyoJuOsvI8I+QZQjfmFcCSRJIBJAAEAaCN
REZBJkSiJQI0AzSYIjNJgjAIyMEBoKOqSb8ouLc6B2lISf6TiWhQMrVLDVYNs35mkEojButXfZ/B
ST3jovGjXKZokra6izv8U7mouOsfHP6whL/Um7uwRlVuUdn1otFS0bnAOJ2O7yZ57mrd3qstkL1z
Tu21z2GVLku37Pk1a6I4dSQS0WrZMe7R8BGpQ6cDosuUp6HxiJ27Hqr3Jlw59H7hPJHR/u+YUXor
mbbq3cONT2qs4JXW7q0egqOi/eb6cUxc93LB6HysPo92jNdYgvNtPRzCTTzBGRERElZBJgEpKiSR
mlSSMjNCiBpUaQQANJKIyBgENASoKS2h4u3ej6Dc+s/Wb9BnYa86wfT4XGoVokkpMBaFPvXFSxbl
sjSI2isZztcXlWpyOZzd/rFpq1nqEXes5jBX9A1Suy9atDfkuh3N/nOn5dGa9XLXTaXrNKhOjTYs
xza4X3M8503b/Nmecuuobfg1xskJWr5BQ1tdZ5Lazgl8sdVxmHcbTyczzt9QoTfsE0q+ZrVtK4Y5
nInvQEvV3Ui1a6VSKHe3tWfZvp2KbRT9WhbHEV1LO9zlQtWeZ5QJX0RMs2b+Br1kuVEvqKNbMgwP
kgJBIIEaSSpAUEgjSDBkg1AgRGCNBmEmpIBKBAEZkQM0g78sgaeEPFal6C88Wb0LE49uNSq+uEz8
32vSvOVXZAkpBKAN/wCt85ybZp3GdI1TCkegMmz30VW8Y2+ax7Ym0jkFu48rlU+F8kop2xlOldlq
LEabkd/U4nmTzEZ2951qb2s2eFjcN0q7eeJ70F5roPEtY9DYzsdIu1cs7fNtPj65R9rxvZckY5PD
PPVj5wxm4KvZJ6awR5t+DaxYOGM4wrWt54wQ6zuSazi0P6FqUm8y3Vc51KEdxkrRLy5xnWJOLlKL
d/PuwVeUsXGM43rE9koGgprU1jmBc0kpKUkRoAIjCTBJWlJkokmAkwakkkzAJSAYI0rIyIyNJkZK
voHRBt4iK0j0RhNj3RnkWyZ0i/0W+eeLhd/PdVbJSRAjUFO/W9Hx/WrFl01sPn9r6SxbPvTtQxTb
bHj+3UjR2cZQL13yg+ezdJLPdETX5vMT1DFE2PVTznQMj1PJ5+9uoCXptvxLXc/xzUNs8z0Rt003
0hkmq0TQEsneX6qwqlB3nINazDnkER19PWsVa1YVlVs9O4lWPSVTl2EFnOf9NM3TPec+Vqw7aomo
6f5xkN2q9k8t6xnev2N5menjCaD6mjbLSbvBU7z1tWtHnN9f0e/Ui8Uyfc+XqHzNCCSkwRJBEAaT
JJgglRgkmaSMKIiAMySZkQMJWkzQYIlBV9HPoSeMVETfoGPsEdYG1xiS45jpmN6ZTMwieSQSQYMl
d/UB4rW9idFoGInt+WUvfa5jW3v8d06X4uXXaqy6szpm9tEy8dQNEh871aw0OYmao6nYjKtSzN3p
3Kv2GRonPlli9yc4ZAJLT9Uym32OqsrPx4a/TMPn9Aym6TlVbWFaktq7dc3o9x03OKfrKK3oDCv3
R41bdKC6bzmb3KYgbdmbbbr1FeV2BzOlVdahwq+rwgsdYYU9v30RpW7RXpxFhrVQ0io1AubdHNJE
SiQAQIzSSTNKyIiMiBkZEoECMgRgAiABgAwkA0nfjM0cucbDKsdhVw7OpTux4xD+LewbFtyQaUg+
iSUdmloSL6P1S/OMlFRjuQjkSvBMs3bPii48uRS79pKFGPzhFy7KTeNGku3YyK4mScRzvtwrrFkL
PI1iG5JUjoSuiz7bFrmVZNHoNI66VKlT6OjrarrU5eXhaKzQ6s6rJq/Oh0u41SJvkdnsYa1nbdrs
3nSlkklG+0XrnkWg3N0k+tg55vT0vrzZ8zgkdJrR6pU9KVk8RxQCMyTzMEADSQIEYUSTMJIyJREZ
KIgZEsiIAwRGaDBhN+WFjjxjIbtscs6YyT2y8mbmk2fM7vVaBHt+YQpIMyUv0VJ47V7JZq9snPK9
HnstnNCoEFrkDIPOcPNrzmh82szu8a7k+dTvEdl9wuGb6xB1mzSSG0hxZTLXm7Zu81TmMXumgec6
E2IgFH2k55URvFp85G/ikykT1c9KxGl127Zsb2CAlPMlTPQfQsVTtXaVbMvQWJ6C46+c6cU7OOoS
Z9E+al9uVYmHV815GcZpEy0z6AhoSK0bFcXvGj6jHweOV+f2R/g951bnlHnvikEYCUKIJCVpJaUG
FJBGAEGCAMAGCIAyBEYNKkgyIzK/A1AcoiFtXp/K5bVXOZ6fWW1+bH56sl0wKqNeKVIAMKHb1rWs
Tl9pq8XttAoW81TM9h65faL5n1/rNwy6K1SkTXOpXq4wUjXrUddk6n3tuXannkTq0NYRFPTYF0wm
8XfFNWhsWs/onzjnjQIWYU+9D3eGxO+aNjm096kxvFGeW7lgGaI6axveP7DjezeYaQ69RyzusXDh
mWW+p8Q27zrUolkrZNrRQ6luHnfc3R4VsaeEnx7KbQ1oexXljR9o8zOfQ0fOVuxxhHIphXRHA+SU
oBpASEgyBGQIyBEDSAoiJRAgZAAEZKIlJIjIyMlEAL8ZKSvhGQly9T4Fw9LDCN1gc82VjK+eC23z
xTmHJJc1qSswv1pV8U3CTxa7bZg8B6Uy7KfSUbguzXPC9uibJQLLRJa3ZO+0Se496zZnEE7qVK2n
DZGwaE4qtm6QT2r0DTXucazg9D2bQvN856L83542CiUrpL+qqFn8FqWk0XSquxt/SEgbTnOW1gj1
jesi17Idg8vUyQ9T9XkJasEzG0+oMS2vBmdUri9D9GVcsT9L+Zty4WzDdZbNX6IkX3ztLaNIebvU
Hn2H9F4252On2XO9mxjTsr1J9WVVny0XMyJCkmlIJRAyQogAAgwC6IUkgAYQZgGEGoJIAyMjSZLv
R9EqTxjYayenc77az0znR6b2t2R6thNhuuCVZoSCBAGOh+q2mIyGvVWP2zDKz6YzDKPSEbhesX3E
Norl2XGQEq9qELmnoKX71y1QLmRyOb07MHcpaecHY2TOTzqP0rN3Nv8AOV22DEaPt+o+Z6Nw6ybt
RLd+g3PHF9HveWajERtkJq3kfMsNJdOerbBjOscWHnjn39CUO5urLgOU6p6BxSZ0Jr5zadrnu/HJ
IjeME0KPvHmRu2svoBOT6vXW/nr05LedPSflPYqxjVh9J2LD9cp9uhbYjCdv5+U6sRJBIMwQBJBk
EktISFJAMjBEYAI0koiURLJIURggkGQF+CwXLmxg1ancOXE5uwHG8c8vWc3mmUyOQEJIgozNWxWP
MaxZrbwuGfMNLqtQ09lnl8lc/sNmj+U0VZmF0uv6MnhOxFStjOq3aTrruUrxTsbFWZpWLKwqsg+q
9h41brfkUmP5XDbpLoSuFFrEXVbO+q1h71iTdK6FWdW07tVchTXpORjt1tfPNsdd9O8I1fykOqws
tfvK+U7huUdXDJ4o4PmHEoRA2zB3wbmxctSN2bbtwcc3DXi5Z8EkEpCAtIIICiBBSSIBRJIyMyIl
AGkEZGRkASTMAjIyMjvq0qTy4tYET9iV2Q+fqQiHkIZ5HQrfggBIAJS+lqsNbhOjznaJKrP7HWE2
uFhbjz4z3CInFVWtcyVd37ezNaxYjpjq2Vu5OyhptnymlVKo6JApuVJrvWuFq1jySrcXFh6pkb1S
q2yMiIm5lPajnmmucYbaFbcbjS58kLeuubdPQFyJHbrpGr0TK2p3LeovCaccjpmm55k7E13jZse0
Gx4vnDNAQCBJMjSCMIUhJEQQREaTAIiBkQSAZkZEaQZpAURESgkGEgKIjASoiMjAvphR8+cfAOfQ
EzHWVu5srblK1Sdx+288cgG3BRoMlGhXX0xNYXWdDuFC3LhkmoTOWzeg0Ku7JXJaOlYJlY6XResT
P7rEuGE5Eyrah2S2YvcmmhU+Iv8AHU+7V/jfqTaGnGjWXLKRp22ec864PtKn69dNMxyoXhvByzml
UprKb9oWM2y3ZhnGsTuDai5odAZdtTu8PEzbyDJxT69rVR3+tWrOajOW+baQvnO8bFZqfcM3qVgh
dinM7uNXkPKkPyCTNBBJAllzSYSEKIkpBEYAIABAJRBJmCNBglDmakg0kolEQMEAQI1AkgyF+IdA
SI2AmvW+RQvomSxPVWVH1h2WCwO64HQ2nFISZKIGPVDfBrpreXq3rKaR6Gp2Sbg6xK/6Ljenpmck
Veqff4iEukzGL4yZwriAqesee61t0ri+n6HjDDZqxeVMXlasnnq6XTBevpPznnPC5+kyqfPRsX0V
UnF2JhV/OkZJ73oeD3PRF45ap/I9yjsxxdvO+raexPQuLqDlMkndLqdprdmoV6joOwtI3H96z3U6
xac40evwN9VDu4WQ8hxRISZoSaQEg+ZkkyJJguYBkQMECBEAaFAkmFJAASZAlklQIgCUkEpCjMIM
A034GDBRkHJ+ucnqnpKVw/Vomia7TdAwyv7xglBZcgSQCM1j1CeDapa8rX6BxCl+maBj+/OMC0jV
MI2+o3iFfZbY7piDmb0GSd0S7vK/3rdG3DBH2zef+MxuOYX+oZXatqj5Gt2HANX54Fa/RXnPOG07
vdxplR3HKtIqVsgbhCxfmyP6avuGWT1ge5ZL3TCdcs+ZYi1n/VOYs3umN3sW+yalbjke5wNmynYq
/WrZzhZ/Gad6grFmy/X6r5+l/SFFt0C28rNgggSAQSklERpSZJSYCSCiSRpMiJaEmaTBAGEksiBE
ogCBkZEsJJRoBgEZEDvazATzj4bp6Hk4DQGBWWNXJY7qWTWCXxKutUpCQZGZn6Ns+M07YJmrbJjl
Q9F0bH9+XhOm6HiGkSj3i55x0g1qGUb1KsX/AHzy6dMg0e85nX7ziOr28YzrGZZzZPRFNb3XLDsm
JM99s/nip8rNvUzRcx3VlE3RrR9ohseZO+cTsEM6i5PNNIlcj1t3mHF90tM9X4jXKll2kRdRyfme
i6pmdghbPRdALPnebL0LTMpu9Xt2WS+s5vL2DC4rny5JCCSAggkyNKQtCQCIjI+aiIwRGCIyJSCA
M0qIjSZGAkwS0mkEogQIwaQYF9Jak8+LSD52C8tXDGYlHbFvXZSGlIWDb8EGSUmDUsrPYIGF6WDn
MxjOZ5Q8x2hnzxiczxaP+kOlcVxmXnCU4Q7xcU9fNz7teUoiPfJimPZcimISnkU09g4/kFuEd7A2
iEnsGxYNCai5jMjrqXFncRUx0g4hrYdcno6mMG+maJh+dvJSAiAuUsUXAJ5yFocxUnWoRJd3ltjq
zwTK3Dqwh56q1/ghBJ6cgkkmkEaVJBGRBAUkiBpUkEDJREaFJNIAUkAA0AwFGkiIKBEYSDAA0BPP
tzLk0g+d00CLlYqyyXfiVZlarKs6PGtkEoiBEpStQv2c0h3aYjSJfNZ280WN0yvUjVebSxtK9aBS
c84JcbBIx1ua0q6Ky2R0rNtTTXVWVtD2fhn+bcZfcahkk7Zc+YbdfcFz5uuQkOEx6Kz3I3KubzhH
dujWObia9Oc6lo/LOsPYuNd1rLdBsbbENLmsS3HjRMQdnvd1rWHQitR0zrDWnF8nZObro+iRuEVp
rqutsXcVP07zjB8UEYQRpIkmRECANJoNICVpMiBpMiBLSYSAYSk1BCkkpJkDACTJQIBJqSDO9A+h
8kM4FXpVxT9hRC2BMdaeLjH2GjYlRmfMj5kSjMu3om2+f4rW5/MPQUDl2u9c2n7zncXsdLs1etNU
pmlVyKe1qw6lFdYKzCORDKueQ6znlb1yHsfaH7RzRxUb/wB8ngdZq2Syvpbz9mbaw+gZKo5L6Vpc
XpPHN7w6znQ5Co4RDl39RtXDbvz82Nbr6Yin1esPXzrpNirlq83yT7dc81ujXmvxUzjr7WYizpx/
K9P151T7ZGs+mb5xvlilc80PyhS+SSSkySZJBoSZoAJSACCSUkJUQUkGkAEAAk1c1pNINJgjM0Eo
yAIlAiMjI74noSiTHwK/YGf5x6Nt2G6DPZBq7uQx7M/SOJ5kw4JCQYIKX6Hs3n++6Xi7r0Tkubek
IDDd0nvPF917B9NkZLOpUqvrGZp0ST58mck4juEdle84pPSVxdxUqGyJBTSqTrpXnywa/wCeOXpr
z7mPHUPQmGsaj6aptyk4yBufXJ9QrEBg0epz6eaPmTjh5w46F6LjX9WlMDpPoKxV6yec5nTdLot1
pl2yHZKn5rtmwnY4Z9l+p4PvNbtGY6fw8qbPesV9C55oPkmooHIEQASSSIECIySojBEkERmSVpJS
DACTCApKiBggEGFAESiBAES0gKIhfCUoJSwgj9WxOeb9LZ3YW9e0TN9BzWlbriOcNE8lclgGFK9A
XPB++vVmm+i8azj0xWcS2q0efLbt2B7JAW9ac6sVny5vStduIq1u5MndDh9qyZDnUOdUtZQzt7zp
EdeXvbFNYy/JdU3TzpmnLR/QtILIfS1Nmkte809zvRsqxBDoOPTTKMs/fPsTXd9+w3cohXmGN9Lz
WR7C1q2G6Ln3oGyRdauR0u1SFIva4o/PlX3XR46iaGeK37jhHpCw0Tzmx4jmSQggZEgAGRJIEZKI
II0KNJGlYIBJkRkApIAIAECWgyBkZEpKgQIwZX0jMuaW8Dx0TXK1bandX7pDXNbnSZlGVQ3AEkgE
KB9NX0/Lc9tGl1nTc+o+2wWVa+8x653nJp+58IyyqrLx/Sc+1iRhrI0zi7nnmhWGq9ZmusLTH1e6
opludUeem6kyOkI059mkJzdabMVOD0Sux9tY1a3M0TNVh9qnuebt4+uXdrw117wzOj2JXGidLydR
s0nTGC0v7VVZivTDayop9kd1fvE81Wuuybfq0VwYTEzVW5N2iOaSIgREkEtPNSSUk0mkjSQBpMGa
TBEQMGkgaQojIBJgERggFBJGZGlSVXg1oXz48oNtKWVblu/cukcGaeA4RTbhyMEQJRK6yM+1iOLo
5WXiOM7HsJ9ELKvW8mqLeuIiD4pXOTTKeKvyLyriwxdgfNqdCmt5d4SNuzHvLRlQ5xHK82bPqzyK
R0lWf3ZlT0FyWqa1Gk1W56hT8xjj4oKR1HRM+ezEFlUYTnQ+fPTizuP1LP4rT4rIYzo/2B3ktbXI
a3ZqzkUU6mNf447ElJbFYKxTtPpeRRvMkBKSBkkglZJJRBJAgAk0maVpSDNJkRmQMiSZmkwEEsiS
oGRgiUQAIKvRLAHJpDNtK16mX6oXXpKtVRR1PlL5NXGrcySSkLT0PZNYyHOJzSqJr09lM9oNAr+x
1TONpapkUwrpxA5R0j3O9PI2UXXrPwz19pGQ61WaXQpBrG7JpeJzmmVmwVyfzeZyunartXn/AC7n
0tPpOGwL0RneeW9NXsfRl6GpWMD0xl2d3Vvn8Dy7a5uuN7HQr15npS9W3FpQdRi4rG/R2Ha1TpTD
ZFzctI4VzPoO8a9nmh+Yq5sl0e9qjRoa865mukNK9ZfNWbcwhACDSCI0mkgYIiNIAAQDMjBGSTIj
IjUgGSiQZgiUARkAAZBBqSZKvYJRhLGE5eplY/6DsdGOz0m5zpZlknoTJctikEgkqIKX023SvPB7
ZEUD0dSss20sgv8AeMd67Xk9v6y9DqOtU248q5OXBkzKTXHNE0LXce1OAgozUGNO05WYWuRxzT+1
hwS1WbEW3p3Bcs5Tno+z1fDvRVD6aJHZpqb7HNa7U3FPSec2+zjBcq5npPojGNnxnZ/MdIeeoZN3
W7Ywxeqeo8Q27ztRrR6FXGyjfn1fZtM2SW82aFckOxHSrvJLPYpkVay+dcm5JSQSgwkGgyHNYSSy
IEkwCCkkZGRBJgwkwkEoA0mSQZkDSYMIUaSM0gXxRGoksoTj6s44pvehZO9u2TaCU/QsV9I5bkEb
zSQUQI1r2zS/PFx0/J4H0tmeTejGeCa/fPOth3nA9V5SsbKUOP17CCuttnGtenZaMY8Mg9A4nHy2
zcldsnkNJzCbmPO3C/7Z55ut1899PTmCZXy0X0bCsvPnpap0bZCibM5y3SYyU85eis8v0VXstp6V
aR6CxvZsj1rzBU3PqFpLxlr85Z/bPUWGbXjshSNY4crVxhHF6870jQ9vok/5q32UeU2z2bzPXtO2
DnTbz5hzzmRcwSFAkGgGSSWkEDIAEkjAABEaVAEQJIUkzAMERBSSUCBkRmkjILK8mYNIbQLXetAz
LZ43u2loubocxE0XXcWobTmSAAk1KPYtfxajarZ863fOsj9Es8H129+fJ/dMIvctL8X0GuQhGWKa
5f4fpL0mxv8AH7Bq9B6yEjHvO2KMPROWXHt58vOm06p6dh9Y3HS/ONE52j0V3isZ9EU+G0JdDvnC
i3qVoGYei8663hnhQdNrnqmLafK1DKXitZzq4SFlw7MdQ27Fz2Gued+PKe30sq06rSjO95FZMZir
RvUdQb/W3R3bDz23L8U58+aSBERkQQDSZGkjNKVEZESiCVERKQYMgaSACkkDJQ5rIJURqQQUAAQI
r2C6ny5N4hnJ6pxlKxbHMnzja/0aIKpM+XEkpCyMKOy3evVc7gzscPCW/jV7C7rEhN187LziZhcO
t3X4uyvI6a4V+S6wUu9bc5NiykEx/aTjXCYl68h+SY1Ey/gmHLo8HPi+bpdFyeuGiVNFdmye6dS0
vrWMvh2KZJOyz55lmXE1EtJBREQU5lTj2SzlXrWE5G6lFRDMKm3TVs9jYdvxJISRc1EAk0pIGQBp
BkQMgaAZhJgkqVzCkEZgERpCwkGQAASZKNJKIJvagoI5NolhN6Wym63aesgTRk25R0hTIzhxJSQS
Vkpdn06s0JM81s1zpbW/1uuaI1od6k4O1lWLE5rOfskONAttbvHCmWSRzfjqOf3+Q7VuxNGVh5RD
vrCOpmKzZ1R47Zr7imetyMiMlOX3ZOpP8kbdiC0MmyJDaWMJueJ0Lv6Nx6hu+DPiTh905pcI5kji
pxa97XidKaz/AKHU384Q0xd9pa4bTms76ORwqmkU/wA71zmXI0ISoHzBAgDSREoECCTIgYBhKiSF
ERKSpKiIAJMBIUQMgAQMiMAIvSwaiS2g2eybXlGsMJiDtcNIvo+tZrquU51H8kkkua1Erpq26YNS
bzpmTbi6y+y3fP4fYqXn+4wD7g4j6hbCoUlCHt6Y3hJdFR8W00DEjabjnda1qGzTRpDMbzPSNLvm
SW6oZPMel8MylmRGFH00fX29T1jjh2jS1fXKNMTqitY3eGw70LEUikb9hNqvUVhFWVe91XRLU7ip
GnS+Ia+5fT3FxFwE1bqZePMK9+ew7tMbFc8t2GRsefaJ5tzDikuZBASakEtJkSkGkK5mQQoAyBGE
LSaSIwtBkYIwRAEZAEoiMwhQSDMJvRKNYDevs/S1z877RqVBgNVzSUvHSmeffQlSxSIRzSSTJQNW
ubP51d7jmdZ9JU3Ft+e+fdR0jAX+9YpZbmqlRN0zjY6HwuU0Il6tw2iu2J+gcRpO5JxTSNQzuA1z
FrVc8NttqvmAK23BYL1FhmVNEBSzHTbNTicp16Oouz51oMSqb8/5pysHpunZb6UjF+fvSOJ2m81P
CIDrvtwxJzusLaFUyUxbejh33CORd/Nh3bVMG2LNLu+61ectPmvWzxT01Sbv5pzLmgcyNINBGCB8
yUEkDIyIjSFEQABEQUARkAkzJSUgLSaDNJqSokgAyBleyI+hDjAsvQmkYDs2gVep6DnFtbgYTvdN
xOO4pPkoEalHq+24A32SvZt6Mo2ObrK4Deti88q9HYXoofSrnLX+kY22h75pkdBzMkybxeY+gchr
W/8AndzK61RLRBUTfc15Z1fNLwnX6riVy9GYFlrcd+yi7L03UZ7DNEn4C21Kyw009850g3Xpl5n+
qUqf8/elsklLdJ+a6r12nR6hE6MXdUX28yXJjN7AvOtA6ZpVdVcnnWN7bpvfMNNFSvtBmmUvz8nw
ZElBERmlIBJCkA0maAZECSZhJqSaSMBXIzJRJUQNAUSkhJkogCMKSACNN8IBSUN4hldN9qN9od75
WJm0q8fI06+ZFUW3NBJWgz6EegbrnGUzOyUnV6hkW6niOl3nE32zZQWjdqzbThUStTyXU7jVbQMw
tsplN9udUod7yq333lk13r7DVukBF2TPuU3mTbW7Dj9fQ91qbMd0Nzjsvlr7QbjK1DY5rFutvOsV
W01ezVB5C6FSnFthnV56Q0PxqfpKt4e+foz9j0eXpMHMQsqJTPZ2sBd4jW0ixmpHpEUe80SEQnmE
AIUQNBElRAlEg0qMgSTIlEDBBJoJYIKSQMgCBkDVzCkgwEmACMJO7mOhJ484uNc3Bw6bSHR2po2b
G1OKacOQSRpJSwt9OCH49+jqUY8pRvHyfeM7yDN/2jnL2OiWxiSmWUr1izkIVnONJGQ6RT1TSWNh
VbB2eu2lUZM+VpsdVrfGR0F6YMqvVuYQRdekluUZj9kfHCMtDpFVbrLr1c3OtPpbnGV5Ni1ik5/P
aRUaS3Xf7q2iLDyq+Z8HM/ptWoDbnd9F6QELbc0qTTkhISgjSgyCDIiUgAERpMAiMJJQCQDCSBgE
Rgi6czIyBEsgYCSUCBkRGBeVJ6ESeMPHWXdYa21C4cbLwZpgHVFu+YVNnwSSEqHRB9rtvufZL00W
AuugZ5Fa7UKBs7DJtXkoSztoOWXFY5x5o2y21G4t69YnGeMdfyHQONjg+MkaUtMU3iNs1dpVfvOZ
VHUtow3KmnWw2Bubs41w6rsI362ybj2c/wAY904rV+3DBcubdLZYYyd3HGs+t6YZ67r0NbGO/m7x
qsvtjkc3mb/ldQoUnq2gHKY9U13SVl7QqEX5ggUFzCEAwgBKTSlQSCBgJCVElQCTBAEaTCVEZJUC
BkQSowglGZJIzSXRJAlGV3NRdErbQsdsu9efdWvDTPNQp7m6cq/5+2WKwqI5ISRAuiOitF9CefK5
r1nxvfWuWXi4ZN32LKqxv+eyEucblupx3WTgD0jlCd+8g1gZTN9exjP7HvWHyWt0nKdxjel2rk7W
61nWkWHGIT1Pi+Qt530vKQU49TXZznm2Js7T6WOuT0q2r88KZdXWDZVzn/T3WDh9GyqTtfaDszWs
1DYqBf6fcKvKOKvaGELbI2kZTt0jYa3Zq1OdfPsd6Ig7dUbX5HrvFKkL4khQSkkmQSEkpSSAQo0k
YCDMIMEZkRggQIwCBpUgyMGEmQBgERpMJvBrJYVwg2G47d5qve6VbOtnzfhoKGnnTYuvnyH58ySa
QOiV6D6H8+r2/MaL6Sg8K2u1edbxtHnnj6OxmdubJHOLpG6YqxvlpnIXidgawElhPoXIKV6HzPM7
Rs1dbWrMdpi4jNX+y4S62LzvF+psVyNu93y61i7q61Sxxdb8/NZLf7TUr7To7jdCloCdwzLOb3dr
3SM49G4npden2dvq/TNdnynWqFf8X3CnYi41d1ktt0WvdcF9PUu+47skR5g9Bc8r9F5/efH8Okkq
SSUkXMgAQQQURGCBJWQCTSDCFhJAwaSMyAUgjI0mEKCgRAjSakhJgxd1EoyU2iI7T/QeRaJMuKbo
NInOVKvGE7LTsbjUpQaSCyPpe/RORZvpd1y/aYTDNmuHnq17f59Zek8ge21y4k6c/l6r1xO8bTVX
chAP5XOIva6HnO3efrpb7FlNwg6HvBxTV5MZDqGKZ/sezeeM64T/AKAsUe+ptyq2gN8Vpy5zYper
yD+OpNpc857lldF7SOzzFbwb0V1pWic8q2XjjeRScbr+tZdNNbJVNELMtI7UdWAo0va8+4SEvlt7
rOT7noOBZmXFANQLilHNSQlREkAgFEkyI0ktBkYSARggZoURAGkwQIyUREojSDSRkoiBndwFKHDl
Fxj3XHUrUrM6mlQ8TCylesNAh+XNKQRBZhU3pkVQ+N5Y2uOp1370ixzVN72qvx1u6Qk70h0yMBW7
NMw02VVkJCsWB+yhZSFcWThU5Bkwta0c5WHZFB8bI/rsehUtIx/ePkNW1vAeOwuobF2Mehw0SpfL
pwuG1Oo3FIDjx6rTIJvfoDBctQFdXHDk3cdXxsuHLq/ekgkMWSej8mPHiTl2zZkfaQEQzTzSaTIi
MiMIMJB81GlSSBgAKQrmZkCBESgRmkGSkmhRpBAyJQSYUV2AUsuXCMjXV/kXEXMdJRHBEJI1ydqc
U3bnyCjSoDpKaQ1o7ST6PbxX4O9MqjcndJsFkrtm7VyVkoCjMCXab7VrqdSd2KhQ+pU21TZ16xN6
BS+c5sbgJ7jMGlSj9W0HJ8/bB73NBdLNI1a069jdPdb5kdR7BPRLZoOvbqouiE9UdtlqtRfQ7ZPV
M7s+IwCutj3fpiFT4WH0hzNC+uCZy/tO2SWHUVsLf6ByDLVnaPQB+eaDw5hIIEgwYQoERkRpIAGa
TCVJMjIlkRBC0mARBKlFzUYBhIBAyMFdlBZAkRMTbvTlFtKp+s3uBXNV1ziGp1PH41uXFQSFLIXT
07kWWy+zUW6XegwOy0qgbnXcp2xDCXiu9cczuPyMfHbvMVWV4uXkSygtLx/rGbJVKhptGj30U46a
pm1Z3TJLhTcskvS+NZE2ldteMKlfYKsaVxqm3U2iwe94PaZnnX701yGl8rdr8jVJGxQMJeYyF1ms
YdrnXN9Af12yXPJca1jtPT/FUDW5Ogye7YDD+lfO1U3m2JhZGCqdkpu5YvXtlqsjON4ny62QCQZA
glaSIKSCMgEmEqMiAIEYBAjNIIAKSCWEBKjIAgCMyIyuxgKM0w8RqHprzjP75GZBttSq2tiN836H
bvOMG2SSDQsLAuvpfBa3vMJlPopOEanfMBntvw+v+is7jtPawmeatmmpQUdPWZdbnOTlNflsI3zL
Mr166Yjqy69rIpeMb1TMh3jr5/tm74dT/VGPZC2uXp8yqFwZwXSlQ+3x7TGPQeD6TLyylc8PyhFq
9PQnSdTH16xVrL98zCs7w4yXTIjhRdg82yO/HEO+EX1t3m9h6LxOielKbje/9Yi8MEQuieeM99XZ
PZtCTU5RNe8s8SSQCCMERjmowQIBJhJGtKOqDJIMiUhYQSjNJGRGCIAKSADPmoAlXU0l3IkRMTo3
p3BZjc2OSbDm/W70m7+ctFsfnaE4BHNYSo1Hb/T2FVrao7KdyVgel6f51lvQeAV705lEjc4K2dcy
abBj8Rzs2u1/i0tzOBkcQ9BZvn/ozC7XeMzulizqL7ab5olvSHnGsb91wKS9O4rkfG3+oIiaKIkI
VnUeGyUuXwr0jiF2e2fpUIfO6UVg9QY/T/SGXu+VvkvPe9sOEw6zrRcxxG9+h6bhd+j5jTlZ9e5P
HOep+ULN6h8nbHLeaNP2/hSLVM5fRPRlGtDKz5XoJ4djKCBGgjIJJRINSQEgwkyMlJMgRAjSoAkg
KABHzWAlSQSkgA0gKSZ3dJhQ584+Hm/QqH7Sab3OK5cMx0fHdXzPPo9A5kYSYPrYfS1Oxh1tNV0B
GEaxdcHsOxYrEegc3rWt9oC1tmkfLxOI3rVKRbF5rO2jH7PplcyjU8b06396ZOustbWjHpvVMel9
DyCJ1+64vUkzWwUS+xU1yrN3b0+309zXtRzaS4WOGt7Ol3By57Z3StPnaiLXEZbdLPQdCjW83U8/
carG5utDrSG9VsNcma1Zc0lNDzC201u40R7RLpS7eytLWrWuNpVva5olBJABpI0kSkGCBAEEdOZk
oEZGCIgZkRLQZAEAYSojIiUkjMJCkKXc1pMxz4M4bpZ53szdd5BTXhHdWnWHZcUo5gjAA6OZ/tFs
3HVxINubvm3d92HV3xddmnRy1iuSSdyie7lih/Gs36ES4iXq4JqDQjsJeZrvFvzmLBDQXBPRSzIG
gKc2+sMDQlanV1JM2UdVLXVWNkkaZY5qhxwkLbKUmIJLy6xSrjwpVlVQ4rglKCPn0BBIIEaEmSkj
mAkIBcwsgEpIyBGQBAERhK0hKiJSVBIMEAgzIGkwZEZoM0GRg0KCFFdzMKJPNjCO9msfDk7f2Hmy
cUmzZlfKNR2LdJJM0gy6zXoeFxyOvIc65UKLtENl+svMjvVyqNx4wMq4jscYcUadqFCv7euyM3QK
ttOYylpd0m95rl63jDi/bNd0t+K3XOKvp2y47kbUWB12YSKGbztFWzbPOvCUj4aS76VqvDH6kxe6
zpfmxfoSB89bTdPMUJatB07nQs5hJG47hjV+5TldsXPKMZZoSEoWlACkJMBICVJI0kSk8wSVpJIU
EAGkECWhSFERggDBIUADQoJMjCFECBhIUAkjBAgCUV3NaVkERsHavWeSOdb75fp1baXzjy873O0+
eYFuSAgzCOirD6rxPP71reP6RasxGv5fW93z7Ot8g4+0wcnkV0na/YIOI1jvVZdjOlTbRmOr5fn9
p2Xo1z6F01NAkrrQIjY+fnfSpvG696nyrGm0t6KnG9E0qKp+hFmxahhG3JrWTbtDWFjLNSVnPHZ/
P+2SkTSdG5+YpTf2ruPfoZxmRehcuvkm85xvOE8z8OJqQgyNA5mRnzBlyWpIQaSMkpCTCSUkAyCU
maDNJqIgEmCNIBg0hRAkmkKQagSQYIGQAIwaV3QGYBIj4W3+ucDj/RisP22BoWvRkt5xntV821tt
yIAjBH2n/VGLVD0BTss3mc876FrvnR16Iw6n+k6HAa/W5KtTWR7zlsHeLdM159FWVFVsXnrf88y6
5bK/huE+xweT2J5BSkZJ+bZT0FgVR9UZRjTfv6d72eP7dch2Ctss23zGdn85CR3CvyTGVot7eea5
D0b58tN3kO1esOEbdkk1oUP2g9I8+0v07neg0a9SUCK95v5cyMggESUkkzSYSQAIglJGSDBGgwoi
QRhK0GhQSZkSkmRhKVEYIjIyJSCNSFGEEZkRAzSFJB9LmDI1ISwhJv1ZTWWr86ToNKkJ/IdZwS9y
+AQnEi5gyBqOb9WZnlN20vM75YvPt22bzwPRuJUn0zQoPUoeek8/krDT15FJeiqdK8CW7q+f7zUo
Z7dI0u/F3X+dnbNnXJxiew5Pl2lb3huUN+vqC0to7u5zHSoCGh9jxnVWUX51ssBoWzx+faCnP7Jo
OZYn6Mko+WVWs/y2zehHeQ6tWXNS2KBibL0xfXuXm6tlz5qBJPmXMJSSgggZIWXNaFJVzCVINIBK
QEmYCQZGkgk1IURGSVkAQABGaSWglAgCMiM0qJBkFHdkqAHImcH00a9suJzc2qOY0u3Ui5UOtMgk
iSogow819OcR107T/XPbPYaG5vFKYXyGr12c1yfeRsXMxFLnbXBTPWqd5mozk40iLCwgLUirzbuq
yhceTlEb0ryLTJ1WN5PPUffAoOT4MXXRl3kYF29g2Cl9pZn24vAtTNvMFHdELUZODZ8mPY+oOQ4R
6+JvVtGfMOHHBjx5EEoCOiVczSSySRkkHzCTMINBkZBK0kELNAAMjIlBJkCM0gAzIiABA0kZAjMA
kqI1XQyBnyQ1hCt1rbOW0nIp5CCk4CRg4hnxA5gwDCnd9d06NcPe1xZVy2OKjMT1RdXCAmJCBXNR
lJYIVMX+vWpxW+NrpsDf4TnfOEdZ2dQ6WigVXiXJY62KAj9E0LPs9aOtK0TNaCEi46FjdhteWxvI
nXVajMWja8loRd9H06hZowVsV8KrWJWf5dyb8A/uexwWOQaLbuHehZI2PRtZo2KxDYElKkBSSIiM
iBAJAJBAwRoIwRKQogkEaTNKyJRJBEogpJJUtIIgRmCNIIEFAiCiF0USwEpZQb30ZMV67tednjhM
V6Zw26oxmBbIB8lI6EFyvq2l4wnXmjXZqXnm61/Jdu55JpVggLNV5mut7jiPVvEbXdKRZ4WTcR/K
kazmNrbzj+My5GvQ/LM5aLirWzr+r03MJX0dluNMinfSeXxtj75/oNqxneHWB0Ln2vWkV1dm5Z/d
tTxCj6tUN6p9vz2p2GMrG2xWc6pFsJap5RKbrPQFirFVK22Cq2enS0BolIv3nXMeREXNaSUSTBEE
gkgyIkGgzSlRJUCNBmOZmRGADIyQSiMEQWkiAWkgCMwRBKyBkQCkXU1pM1IYwU16/wArp3omWw3V
+ed632X57b7f5zqTRHMEpACukp6wyTNNon8V1+6YLYdqwyK9EZbm/oqv0nYozljeu0+3COXd11Wy
snp1S0YJtNGb3Gxc2DbtKwNiHRrxkEYA23bHs69TZrizI7J6dzWXvC8tk7ngW0vfOtaJzvmkRnCd
TE93mJXTQKlaaxZ860mseddZu+CbIeeb1yg8H3emXrhJUm8H51vVxsy+Ue/rFp88ZaSEGkiNSUqQ
SiIIBEEmgkhSQaASkpUfMyBGpICxzBA0hSQRgJCiMAiBKCQZEZEZpUkrwCCgZMIOQ9iZ1SPQsnju
kV2uajnmk4KnafOdO4IIgkGFKkvV+Y5ttHbJdC0XzpO7/wCd470zjOdek6tWthzvSWdPp225pTXc
xtNZe1PQuVQtXnveKhjr30RSKVpF2a12yuc1RodQiM50K3+e+PqPL8SarkPVtAb3/tni9E80bLaM
yyxpM+pGDto+N1CTGNUzccd3+t2LNNgq+Cejsjd6pmNstOTyFto2L+ku0/lOt8fPS9hdWDJZa1xt
l8pV7mlKua+aVERA1K5mgkEaEpAQo0pIyNBmOagCIKQZmEoBgyMglQSoEkKIwhRpIjNAUAkKK7GR
LJJM4NW5X6p3CAm59uDyLU8ivcRkMZxQSVJMlLDz061xGM2ZpL23AbXr2F8PQGUZ/wCiaxmmzuoS
y8VV6abYhLbxntr75/1vWT99ai8002BpOo98wn7RkuiTlYbW6PzDQ8XgdZ0fGaNxFm3ikw8xK59e
5nEJrWM/6Som0tuVQsUZcYmp0Tn1u+h5ld6Vds20bOrDfVVSUkaYWfFJ6jUuzeRjranLNLlKdXdN
zyrqbhuEuC4o5n16cuwLmfJHFCSIIMESTABGkAGlK0KQZktKDBAzLmazSkwpJkCIyMECIzSRg03c
goxxRwg0zFuQrm+fdWqIt3Gu4hjw5JQlRGSjLvYnUSx6OXrnlwdhv16tunY+rpmbzjE8UpcSR9nT
Nu/ZsXpcpBy2em07dSYO0pclGxDblKzDKC4F0Wa1A+aegKW0hw3oJqgEJRyCntxrba0Oqi35mjqc
k/r67hW2tz60hgrj2V3s07S4pK7VZY8pUqVVOTq32CgRXPm/vUcxvSKLYJDN4TnzAJJpASDUlICQ
Zkk0mAFklBgyBGCJQIEEhZoIGaQREsAgRKuSgajQTODGi6xV7VVbg8cciqk3n9ki83jmYJC0BRKN
16AkMXg7NPwm0ROXa6vKr9acrf6ZU7SIlco0x+ERyvmzZ7f+UDyt1Co+10ktC4t5muwd2aOowO+j
aXzJWfVXStmyvHWincyfGRDBTlm5dNVdOUd6Hp2VSyYKP59Lj6M85Rnos8EecmnXu12xGFPPSvm6
S9FM8HqzpoJKW3vlRszhpja4fQa3XrzmGI2TRdVa1fJIR3aPQWVTcjJQ1iaZ954apIJSFpBIWkGO
ZgjIyNXNREpKTBLSAACBkaTQsIUARGCIKIEZHcjMlkYZwa/VXLNt0fUae6QV2cqw6P1zAqazSlJK
IyAf+rqJkNj2vPnOvZnW92zih77V8w13rWb5Tbhj0noNCtsXVdfkKbYq/aOlEu2UahR5RU/JReZ1
6u6TfMUuGqYVBejMQtU/j9T9RZ9ijR56InF1u8N6tYulZtnetv5GKw/eaKWiMsQztPbVdv8AO2l6
JXmdr41mxFVLk186WHd/Od71jC9UzXSM9nrhU7dCTCI7jhG6R3n+9b157jfRDOarVgati86+kqLN
W9w1bxY8mMiJIBBINPRJJWkwglEE9EA0maUglKIEDI0J6EREZpWkAkkogoiCk3MzCiM2kAv19Wsk
3+6YleZnJtXaWPEqj6Bwags+BL5l0SFB36uo2T7w2xnUdU85SnoTAq76UzLLfQ7PMt1qljz66Y1s
1RqVsu01W5qt2w6VdPOe113KbLr8TRrp1zbZ/PsZfthwbX6Ris/6SxXOPU2fYk1nfV9XmELgqnrt
Tt/KnwVxiKrlPpWsWSsZnFQJi2+oMF3eqOZaBiq9qsHXZ2Oxnr6g84zO3eZ/ROcaPn9isVJudblK
pq+DaExx3h6Vxmo+ictj9uplozTcvOuc+nKdaqzabBERJ+TeZBBAjIyIAc1pBktAAIGkyBBSCUZE
tAAIgQMEZGRpBpJQIjMrl0Ih0STWCT6UsOY7ZxinvFtZ8p0XMWmn4LUOPJJpNJmanHqWHxeY1umK
13zx39FYRVPTWYZX6Ja5rttSuTij97BX2WdRvpyozkPItuzPIN3iseuWjZ/NTMDC2vBdl7W/BN88
8170bneQXf0TjmPNpv0+84RD4s61io2F3EwV0q/nd16krLO28sXqCkXve8Q1bmhq/VlenxFU7alk
EJ6Cwef1XzbrNnkcYzBwPRUtjOuVOenGch5x9C+bdCi8anPRdjxDXKNccs3JhSr0eCbG/wDLlVJJ
IBJMEEmtJkgyMESkgjAI0qJKyJIMAJMEaDWk0kCM0rIiMjSq5hJjojjxhm1l1uLla1bJJ43j6dYq
rYq9UGI5pNKOiQfTrqM3nELZ5pzMUGQudNYaBWK5oTOnXSUrM49a16cZ0aTusBMuapzsNUf2RFfs
ENB3IVPq5grFMQcDPVfrLVrnZpasxKH/AKFs8fgMm2hnfBrMKhZlrDnYGrGbFl1jrB4UUS66HzeM
23Y26nbCQfx6TaazfpbzZXeYcGTzoTcuQe82zZHV4GXHiEGlHbkkc+ZkgyJCVGk0qSAaTSYSAY5K
NSSIyAIGSkkARkZkDSDIgCIwSkgJvCULUrkjjCtZ6+NZeEsHR3x4xbiK7Na614cyBpAMH3uk/UIb
rJIt3ao2GXqDyz1fhdIl7KxPCwsKRFL5yGiQVikq/E3Kr1e68IfRuURZ29afy8LJPhmVTR0sETH3
TSKLnjY7ts2fZtdtGx+C6c0dDktKzGN1yPznUbtk9Qbo5IDjuSe/MzRw6k91u75TQmp2vvBR3JHF
PWa1O75dnTUaxpXDE6eT7bbNiuesSTzIGCSEoAQDQrmtKSAMwSkAlEkyBgkkpCyJaCMjAAQYJQBE
pJKSRgGkgSrkFGsc1NoRvs2wZpqEJON5ePkm681aXDGKoz5GhKwZBXX026wqJ06w0Xeq9lG5scn0
yYzKW0Os2uoWesxV+xXnyg9X0zPrvVp7m3Vm+xUPvKOpljlR6/R7tSKrs2LG2r+w1DKn/o/PsRYl
L+ks9z3adH8+2vrVpZ5EXa7YnnvomiZ56ci6XEQMzl7LvrNpgVPusYzmcx7aTXdvp9jotQtkNbeF
IvQyWq6Tqtgod0otJuVTZ7rjVwaxOq02e8sRKUpJC0BKTIgSQkyCVoBpQtR8jANBKASYJSQAZEAg
1EErSEqB8lESiJQIGlIF0MlhSDbQvD09M4TuugZh0vOX3qw98ly/0LjmZMuYQDBpJbn01F4lo+kY
lcdpwqO9E5HRPRNUxbfXGSbZHPcO06LfzcQ1v/SqWhg5cU+4YHqsRVL/AGE2TCKeSUr500uadcIr
JRvWYZf6fpGGx65r1HRO19f0a9qptqiHVRvPnit+lqlmnpLMnE/BTvmxhY/UuSLmbU+7065+e9gt
FOtFdnqLpOeWiV5MoKgV2X2bL9grdhznUM9zLd8e57g8z62xTryfGpJBERBASDQRAEtJ8zB8zMJS
a0pNKgRoWQIAJUlSSAMJCjIjI0EYBAwDQSyuaVJNaVN4Nt6VtmFbhd6GytWcaLWLTScx3/Hcxap5
giUDT0celG+IaZccnkd386sfTmG0b0xRsh3CTyrecs1qDiM81+tZs7f7dXp3NdT50W9eediZ4ie/
wWf3O3ee73q2Mbr5w3am1CBuml+d4709QcOYk99WVK0cbTUZLO2WzVCyZTruY5b6Lr2M+n8klbhH
OfODKx+nsakZG3PhA2jzqnT8v9AV11WdNoNlp/KytKt30Dzb09K1p9VNMpMvGQ9q52LM79EQfm1P
NCOakkgxzMjIkhKiBI6IMgCSYBgjSRggRgEYBESiABpBGRAEakoWtCkoURXYEDMuaIVhom503QKH
eDl+HCgzcBzsGMV5HNKVEFGSl+gLZiVW02yQ+pYVz9A5DSPRVLx7e+2L7HIRkwbuqT6MWbeg6dYH
VLi9FzeG2jhlOjNc31J7mM7asij9SxTRL/xyPTcXr2napj2ethO+gqlFXxlU76eT6JT5/Mdir+a7
fXqRr1CgNptNZofU5lzULJo2Y0TQY+j1NK9As+V6bRL3X7nGUnReFKhq4V3uWYaTRL5ykU0q6Rdc
ez2Sty4JXx48i5mlR8zSfMwELJIMiIjIzCkJUQNJAGpBGAAQBAjIgAogEmRGCWgEZ3AKJXTghERH
yFw6OmMi4cc+Md0bE3j2zdKDJSQYV0lpRlHk77vQxddmfVzxT3UHnNq94seHE1SHVbxu0ecOUgTV
8TOHQs5J5CcFSD6Jakvg6nGkEjiCLqS+qO6+szE8m5rQvpIdLVrDTHrP1550xc7w9wKO5de9jmKg
x5DvbY2EscvT2BTFspsEOnaXudcrbcpG89YSxqiIa00vjdqnT2iEBJpNSSHNKiMJSsgRBKyMElSF
pNRJBoM0mFEhQSSiNAMIWAQIlESVAjuYBH0SjjDMrXuUBaqndETzRswYx8bM5ZBtUIIGSQtfTX9F
x+lTVyqmydcm0Wy5VM6JnUTr9ZlHrKLsPLJKufKybtQ7wqNrt/qXKzdGs1Xc2ozpv032OxIK2C14
C11Gh1HQdtzrEo4IWlY695p600u7YMzeNF91K3mjZJGofS3N8mRa8Oy4TrIWDeE5tnMa9ue54pQf
TC8Mhek3vmDZuxf6Npso2w6C6aPYrAmORYuCI8P1+ZafzSSTURGgERpURpMgCCTSZpM0AAyBGRGZ
AwklJCFGkwaTI0qSSgREAm7AgayDeHZbjs2Ba5cYuoaDTJu08qDj+6ZnlcdyIgaC6Ebn0JL4K526
CqvoHN6LvtNzfY+GX3e30PR6JfsZ469mtyaUfWpqm2mn3HrQL7kDHXo/rmjDUXlOj9Vq9C0+qRGv
UrIL1bMfp3pqp4UwIkmal6Hv/Cl3t5gdu0ehSlkFRv8AWvN0Si37/HFLzMZDzi8VutlhbJGSSYxn
k3oXH4v0JjzvUk5np7THc62qyWPO9EqTiS87aFp2aZL6H52vPtEGe37zDnnEgkGCPmpJhJLIJNBr
5koJIEAoJNJKMglSVBIAIJBpWQBpBKSFkXI1JVcgSjJZcoZhvGt+cdJ2qgVnWMsnZ2RqOF+hc9yG
PLkEqQpQV09Bznn/AFe54dO+gcAhPSeV5j6LhsL3Cy4hvlTuGX6FjGmJzWx6HNVyw0q7dKTdMyvW
KtZ3RLD1gYm4wTMWRrnGl8s8zH0dlGW+nKpgzPmayLsdx3zjk12s2M72cVXLRQ859J5RmUMHHoDS
8R2mjRgsspmtylqvZYNxB6f5zqfp3K6Z6c84axJVSubjSZSuSuFeo8103B99z7DnezsW89ivpnLN
PVlWreU6QgII1ISpBmlaULJKkGpJAyQZg0GDSRmEggQBpAIKSSgZEEmRgjQAZkdwNCj6JQiIj9R3
fLNIcvazb6rPV9o5yvaMmzVsSEKCVBSe293DDGWxsqfv+D1b05k+Y+jYnC9mt+HbxUL3yr/GT4RF
GpPqKAsNVtEG6V2atWSLLzeVB1Z2zV81d53qXPIb3TsbtHo7L8PaBw+Uaz0LVZ/I+GwVCzt+bOS8
0RPpawYXSus1v8NzsTLlUZ2wYbW+q/RDzHNdrPWo7LW803PCJLUk41uPCl9vOiNr1XLZrlaKdeV4
PfInGN60TCJLZMnwJCUhIIyNIWlJGkJMyMiSFAEZJUAgKBGSTNJKSZkDIiMAgSgk0GSVkDTdELIz
LkiNjXWoO5KsWdzJiIiOSmzmksOXEiACgE9rxa6jWJG5tLPSud2rlc0GMqF66UyyzUG7lOdbneNK
VeIx1J1RhbKvNyR1ieFYsTmpTYS1eco2fZV2UrXGdnqvF8e2+WpZmVYzVvWk2OFdLNymBbv3Fu2T
rFYdDueDqPJLhmakdyD0G2Pmjo0XI82C1cXPRsgcO/JXR4ce3boWSSLkEhJJBEZkS0ABKQFkk0hC
iBmEGCLoREFBJhJpBpMjCDAILIgkloAVzUm7ERmaeaYuOeaJIPoWZcSPNq2jO8PIVOPb8UhRJWCP
rZrzW6iqU42eap7+zVTjd69B3Zsiwx8Na29Gg0L7aHHzE1DVi9V6n2uRoWgvqDYLTRF3+mzfDPb3
cW+eRsNH3DTqTm7Tl36qSOt31DIa4/2jKIBTnYumNRrdPft0Kx3zKm5BKzGpV6lc1PtWveUUVry6
EOmxSuDRrqY1i9ZFQGvPorlomyIx3L26EqQCIkhJERoUklEQIyUQSY5mCUlR8lJUACI1ERpSYIwa
TSlaQaTBkAkwDQAaLkYNRJVyioy9+j83vfWXq95ge8zDRuUajm+bx/FABGlRjrtmpYDVr7pGT79G
5Rqz7MbBfM/gdnqlopdxqkJoWTxS67o+uUO60e5xfN5mGu1ui6myZWKFXJwcnHSeM60xzavbNW8o
Hour4NGpCVGar16byykHt2BWKbTYrPnWY1znM7E7qGqy+DubpSZaXVCbLVfPshpla3Sk2ij022Ve
/VOm+iYzzFx0/U56g3Gl024UzRKnT5DXKl59b8yMjQEg0pCUBY5rIAgQIyBkQBkkEFkaULIJNSVc
y6EAgwCMAiWkgAADQSkGq4JWQWhfOIi9a9C+cbZvNezLZ6JHacus+etlj8MYc0JBAyNR7boXnO27
PivX0Vj1D9H03GfQSsB1u84VtXGYwm99Yy816O0lVXsUe+cU+2YpcJGJt3Cfb121lTLjTbWxhOzr
MaXvlDyL0pX8AZAzSZ9LZ6ni4XKfQ2B7tXnNUvXXFclRpW9V2gWyz+edlvdWhbkjItizHK/Rdqpl
nrNjoOl5xH6g38wajdvNWj63mGwVay53qOWlpfDy1fdaz7AGxEkKIhy68wCQtIIBSQaTSQAJKjAS
Rg0GQCTIwokgyBg0kCUkEDJREZEaDBkq2l0SsGkoiL0f0lh1n1+LzjT80n5OvT+B7RAYnH8Vc1KQ
CC17Ppvnae1ahVb0rhlI9MZ/kW+uMC0vUfP/AKMyrWYA8r0jpjsmjbYiz5BsnCiX7AtCmK9aW0uq
rWnpR71TpibzGm7HT4PVPPVe9P1nz+yJfU1l0tvp6iSWJ+l8M2+trrtglMjydFx1625Z00WkaXW+
9Ysvmlj6ugcui9TzD0TW+9d0zPrZDWXzXrloyzVvMr30rXjg9GoVph7Rkrq60LAeSTQaFhJGhSQC
AJJGokpUkwCJKjIGCMAJAIEYUlIMAglRoUEkZAKQtABBSSCrcFhKiLgxiZDdn0pWrYi1MWUbULVn
2jY/VW6CCQRg1q1DYsozK4ahTNkySi+i6Vj3oTlguv2/CdQsrEpfrTbH2yGreiq67mKvSdVoVT23
rkl2eYnpVtxSwaXkszpkFTtA44/qON1vQdcyjNkLudl6joc9IUhUPqmaarZoeoV2arcqbuW55Sz1
2jzT0wrG2mi2zHYs+mg2vL9Iz2+wVlbVHREVqlQYvNvy3Rs80Gt2ljXL0zypglJGhRJMglSULCUq
CSMGgJMyJYSk1HzC+SjIiJZoJSTBAJ6IANKkpMwCUlKkKIyJIuiAowfJEbE97HNLR1cOejfg06sz
jmPJBBAIKCy7L6cDAWS0ksLSoJMERKNBqUklABCwgzMlFx7Dn1SgggdeZpPn1SnvqkwAEVzPCQpE
n6Am8mzBIvNjFfoBrQjqlKglSUqBq5moiURpWggOaiUSiSACSYPipJJMERkaARKCAEhaDIyIwSTM
gRhJAGSuZkoySZklRJCiBEakmRGCAJSCJRBIuCkqUQVzjoaX3R+vjKi0xzd3UJjMdDzaktOKSMc1
mZg0mowlRhIWtKjNKeiQa0GAaVmSehJI0qIyBGDSDAIAIJSAYWlSAakqAMlpHVBAGfIF0Mgrmsgk
wCMiMKQDB809UAJURkQSoJMJIiIJUaDBJUgwkEpBpJaTNCkkDIyMlJIjBpCVJCTUaTIJR1CTCAFJ
UkyMiBkQIGCtyjBpUBFxF09T4fJbSMg1+osNN5xHnbTHmCRjY0AlpNKgAnshRpMzSa0qMAlEZAKA
IlpWASVINSFAEol8jMGRcugIjSDMjIlAEvn1R1AQQNRHzBgzMySS0kpA6JIjBmgErmFEkGaUmlZG
gwhaEKIjIiM0mkElSOhEQI0qAIEAkzM0EQMjIjBBJmaQRAyBmgJURdUJJRIMyM0BQt4I1IWBGwtx
9WYZx9ENcc2akQelQU55y0aw+fIrlyAQtJglAuh8ws0qAUkLNI6ICkLMAjUgwCCiIJMKIlAJNJKU
kjNKDBmpASoGkwZhSTMBKkmZIUpCiBqAQaQZmkBHRBmkc181hJpBKCi5l0SEAlJSCMAgRGCAQogl
QAJSQkwAOfQEg1JBLQAQABEtKeiApBkakAkmDBGRoMEm5AGQNKWULK+kG/C1KhrrWJDrl2mYbrdN
ydnzQEkYBp6JLoAFElRA1EsyBAAyBmDIJUAYJREAfJa1ISDSaeiAo0EAYIjIwDSZhZAzIAECI1c1
ALBpASF8zUkkdCI0rSkBKkmk0qBJSoiUfMyAANIJINXNSSUhSVI6JJaSNAIzBpIBIWhSQCBGCI0q
IwSiCVICTMwkAwkjBXJKySouaGsGu12wN+knIrY8ISUhZOpsEcSSFoIGZgwAYSs0hYSoEOiTSsJM
1EEglBKjIwlQQozCFJAIyStXIwFoMAgaFgyMlEoEZ8yUZhIUkKSZBSQlRGSuZmEAwEGEqBAlBJhP
MKIAAc1EDSAYBEaSIwhYIEYIjIAyASRgEZGkunMzIjJK0mRmg0gEoAiCiCQBbyUAZEllC9NDvMa6
azUmbJFZm6ZaqbXmvFKSBkDMGE9EmAaVkSyMwRkApSFkACUrkZA1A0koBJmgGkGskmCMkmAYM0GF
JMyBLSSyNI6ICTUSyCUmSiAIGYQpANJK5qBKQlRKIkqSAlSVERKShSkEZGZJMiSaiBBZEQCTJIBq
QRggAQUriFKSQI0qIGRoURGAQIEDJSbegKNQCWUJLeoIKG09xTbxAC4RXTA792w2I4JJKkBRkZpC
lEhagkGpI6ICiLoQSZg0EsyAIGaQFAEZAAiJQIGkBRBaQDSpJpClEkLMgCABGrmsAIURLBI6JIgD
JK0kkBKgQBpStK+RA0qNBpUCIBJdEq5ksIMGkGQMglIUaSUkyBAAEDJRJSoc+hAgoAgEmQIlIWhQ
Mgm2qMJ6JJTKDmvW+TVL0XJ4hrjHOdh4vPOM3qHnKC4IQoAyUYSoAGDCQZgjACjIEaeqAZ8+hAGE
kpSQARjmtSQDSS0GCUhQUSTUlXNaTMEFkCBkYBEsjNJpMKCSAIyBAECSYJAAUkiUEkpIM0kaTIwO
ZglEaU9OZmlSDMBBmkEYBGSkAJMyAIjBBKgDSZ8zMyASaFoMERg0gW1aVcuqiS1gX/qWvVvaE0S8
VBxass1PBrdaMAh+SEhQUEhQAIGSlIWAZGRggpXNQUaTNAURkpCyBAlAjBAlJUlBqIlGhZGCSoAj
IyI1KSZpJXLoYIAlERGagkjNJBKiHTiCSkEpCVgczBKBAyBhIIjMJBIWaVAJQoGRKSRKQZglIMJI
lBCzSQIz5dUhKgQIgZmgGlQSRkokmYTblIHQHzJrBJverQErFWSa6MW1Cu2f3vPqm358wtaQoGRp
6ElRg0kFJ7JIKBKSRmojNIBGSVgzSQNCyR1SSTUAkAKIwDSDANIUkKCFGFJBLIEaTBpA68wZEoJM
Ek0qShBkgwRAzSRAlERoMGS0ElRkRAEtJAAEZABBmkLQYSS+ZGoERkASTBmQSaQFERGCNXMlBIAU
STI7WFAF05k2gTn7XydNZXp24c49xGOI2L58kGroCWYCkKIAwtJKAUAkdTSSkmZAGCIzSoESkko0
l05rCFhCkhQSAYBKUSTNJggAlZrQrmsjM0GXRBoUpANR80rJKj5qJHJPLitaTJJkQAJIMAzSk0KB
AlICwgzIglQSRkQJRAGQQogZEAaTSXVBkpANIUQSZEaTMjIjQoiBhVoWogZKJnBd9p0SkX+HlJPl
zlK3L4/dI3JI3iuXPqaenJfZufbh1QoI68h3b9e3BRpWSgfTmXTmtXHqfDqk18HHJR8ui0GRdU8n
HJQT24L6N3B8eyefZIVz7cld2/boxfJ4u+B9uXVA6cV9G7kNnnPm54mvj15rcRzvpXK+3QojQoIU
RKSogkGR8lBSFkEAwDBBJkCMJBpUEGQSAEqIGCBKCVFzUFJBAwZESgQIJUQIzJIUDs5molAlNILv
6rgcy36045dXdC06QV59bbL57rPCd3eThOkwxi7GmpW/tSbf3p1jdwDuUZxNjKq23tSLl3plq6wb
mTZR08KvbO9GunWl2ztASTyPZzyata+1IuneiXFzV5h7Gt5hFfs/aj3brRbr0qs+7hVy3CAtHWlX
LvRrr0p9md153KMYmynTbl2oV47Uu1dq7ISUawsXOr24YJjvBC0kFEgGpJBKkgyMgCBhCkgKIBJL
SaCMyQoloMIMBINKiBGlZINaFEQBpMAlJBkD5ggaTUgyAO2gJWDCedfX6iaZhu1lym1tqrotI0XD
+Gx+eqvxuXoGfrhWSLhLmyq115U25dajYX9d6z0VGWtjWLpwqFxVVLG5gHEzFR9lZ123t6nc+dUs
3euSEnDNrGyrdza1G68qjb11eZewnOfZV+3N6heeNNuyKlZXMB2lWkHaEUu8Ci3/AJUm4Krsg94Q
VlOk3g890blRL3yrE4pqwmXFIunbzrnpFyWREvksgZGklJBGSTClIIJMwAQIyUQ5qSZAwEGZERpC
kGYI0qSRhaDQQUkjURkaFBISFoAMjQdrMzIzQnnBcdP2Ol3ynXB4vmrLNKym6R+RseXW6ch24d+f
N6z79WMhwZyrA3THutu/ZdXMY9DSUbcXjF0GbrhwkGPZTCRZ8JKN6uI6RbcX0epxHyTdtIxndzHv
ubR8yJ0zc8W8kwW5jXxMnjZXVr1RzfsldmDo2Ug1T3bdD4uW5rbdVtXHBHZiaQaSQoyJQI0kaiQs
IJaQaApIUSQYSZAEaSUQBGkwSVBIXy6JNKVkRkpCyIiMGEglGSSIlkoIUQAFoUtCjJCEQzWTtPfs
2fOHXFqx7te0Yz4oVI9eLYjSAOi+IQpBKNRr5AyJTvsanHEI58uADro35o5giNJglEaTIjNBkFIJ
QCkAAwaVA0mkEskqIzIlBIWgjANBrSQPn1SDQgGQCQDCTQFGglAEEgzCTSlaQXRIMkrJAIlJCkAy
NJGoIMjJC0qIyIL5gEF8zNJgAJBBRpMiWSQRGVsCgAakcoHlddlq9vqNxXJM+MBI0ybi8/jisu1C
qZo3QDWi/wAjmfM+PEj79eiTLnxTLbG8gLqiuv8APdCxqI42jZq7l8ctjz5GXNaufZKTBGlZJIAE
ojNCjSZpNZEaQaVGRGQVzNRGAR81mSOg5mQMkrQfPoSQSTSCUAARmEkAZJCiIzQFJ6cwAFINIMiM
gkuiCMJBLSCUkyUkyCTQsIBmEmAaUmogAQIwkgF2kAzURqbQKN+u2N7XYqcJquXCYTisLrGIVLjM
+lY7tmtgqMjIln2qNs+0AUGnIc6nNwvZ1xziEG3WnPJDXq9OjH9d821hz6VYWLIOtjwllyHRJBKw
pKkBSQZEYBKNAMjSAa0KBEZpUkjSAYMjBKJCkqIyCDAM+SwRBIMJCFhCySFkRkRGQBpNPTksBIMg
EqJRJSAoIBpCwk0qSRkDQsIMjIGkwRkRGQIzSZoJQBEaFBVrSXQgtKm8Hw9C27D9a1fH5C25foPK
2Y1S99wultJX03B55frjWYywSOOXZ9BWzO4OicbV6SzfRIPvMYXQE+gl4lMejqnU9VxzY/NdZdeo
oez5DQDrrdJGvmSjSC6JStC18zSYSZGnoRJClHzMzSAaQCBklYSlZkkKSSlDmZpCTCiSkA0GRBaC
WkGY5qIyUg0rJJoURpWk0mYSRAwgyUZERKIAiNJmRBaQZBJhKggwRpLokgaVBCiCkpMjK1mSgXRB
8YVprWwZnqMe+j5GOnc7uVIjtGxCriX9J5zR95ZLrVklsfuFgrNmosbnXGzehqHoFXcWfCs/Rrt0
r3XTMKjN7oOgeaYBfoLtacGkrZhLQJILR0R05gAlAyNRJMkpUQSDUk1hJrCSNJEk0pWkGpAWk0GF
EZGEmQJC1cyWRJUkglQIEZGvmDPmaVAyQOiQZIUQJRJIGZGRkCJaEqCQYI0ksiUlRElQAQDNJKSA
YIESgkjMgLQowSyJHGKZPdK6Pq9ZnbzmxgJKIlYitNimtHhKjcZHhFdntXtjqnXdzRYDk5v83Vxy
lKLCG70aUrlpptZ0CYq1J4JldIq9PNbIh0Ilkok8zQtQACVJMyBGhBLLokwtfVRGlunilaQYCSWC
Br5GlQVzJSUrSAoi5qUgEDNKVpAMAkmCMkLJSB0SglJNSUmZEYCj5mEmRkCM0mkABJKBA1JA5qNC
VoUYIgCAAIwAkGLUAsiMITDMpbSjlICe6P8Am2j+bPkKrw4SF1g7FT2pISS+SJu7qintan4WyMae
04GpfWTfQLRRH26IJKrA9qbVIPssyUq3PKQxSLBYqTzB9eYJRBKeKUrUtBjvf7HB8bRF5zENlBJg
EDUjmazSZEauZqJIAMgSFGkkqSZJMyMwkwSkGCIJBqIgDSZEZGpCiNAM0KSpJEoIUQJZAiMEpJJU
kGZJUQIJABqJCiMjSQO1hKlkaTRCMtR3PI9PW+gbTDSkkwz6D0DH6i1sm/xktjjtmycLrUdyvHoe
Gd9co1eKYJxeuIeWnk222PxuE4OLJIc20o0r+yM8hYc3VnfxEx1aRu5SXnODR02Sbxye7x8rw49u
nDk0c1RgJC5dq1w2TMdOjdYola2TzrQW5JBmRpUCJQJKiUBy6JANKQaAoiMAiNIABLSklkRGACAC
kpUlSQDQQUSiWgEaFoUaDSSiBBRGk0hfJSSUDIBJGZhIQpaAlfNQCU9CtZ8+hF0CURDDZtg8+3/b
83gNRzabt8nluT71l+bs+237Nk1gleNank5XnDef9OcUvMh2NeRjOa+m7bn2yrXY7A6vxmfQ7hyl
gxyHZo/DI0Svoe05xqKYWv2+J82whON/mc82GDkLJzipYmhUO3+ZIM9l1Gq0OhXfP7Jukn5/125e
a6VxSYABEYQZgjQFgGlRJCFECBA0AEDBA0qQpIMyMkktICiJJpMyBEtKkAlkRLIgtKDSZGRgySaF
LQQIjJZJBkAYQoJC+ZGDIyQsrUlZGowlMNGatt+PXK+R9UuVIt0G8jM03HKM7bvfQVwrU3UI3lfm
lMx9vP8Apas24ZLrbem3nzzTE79Zp7z7qsXl1T4OvSnC5pxSuQuxyeAR69G25VSu9esiaTM+cIlK
9lvVLuNc0PrBT3Wq2fnRLh5i5y+lTeOJiNtxqe7egMPhPRvm6hoQSjQpIABgJBGoySkdCSpJJAIj
SDHMwAokqQrn0IGgzSZKCVICQoGkjBkEgyBkYCTIA+ZLQoyANKDBBYSSkF0SZEAQBKQZkZEZHZjW
RLBcyi4mU2LvK1C8FYuUTXz5t5HMInnObRn2js5plS7byqWdouG8NKdYHtZgL5HZHXy0zR+ebu9N
y/MuTz0hZ6QysDPENq74i56WDSG7OQot3YvU5PyLjq03k+p9qjMU29KzjRIOZRjN36VnXXOM1W01
zbJuoKtkHh0fzUCABqQvl0JII1ElRAEYIkGkkpM0kRA1EDSSiMgEkakGhQNBgjJRJBLStCkGZBBm
ZEpBpBpURAECUQSahzMlAgaFEvkFEkyJQJPQk2kzQpYSXKOiXlrkT4OezwN+TPoz6xPDkSXKz59S
SpSEhZ9EmQQZhHbmFJMcukp6PgcPYcljl0vt6VGZTH9EAADWLEmpZrz6JJfPrwWpJDmZmCC0Go0L
PkaiJKgkALIIC0kS0p6mgjJCyCkJ5FzBEkGkzBgiBEFAEASApRJMiURkSiUkiIjCgEmSuakGRGDI
0koglYBAGSEmFER81KSZEAYIgZC0mlRH0SfOLjLHv8DYWM/H2qJJ7XeFQumW1Vtyeu3Keg59EhRG
gdeSunI1clKIuXcuffivsog3AXzPpzHVJESyQtST5LI1pMwSuXQkdEGR8+hAKNClIMk9QkAGAS1N
+po6khQ5dzSRGtKuK0x0XxC+YStCkKJSQCMABIUEmCBAAGlaS6JSRA1c1mkgCACVES+YBmEEaiIl
IUQQACNQBEYSZEQUQIWsyJK1g0R0NovozA53c4DOtWpR6WKPh201XJGS9ZvnSqWoVS1dqxNuYVxI
NI2eKs2brTraupWjrWZl5FlJcYaw9KhbetMt3WoWjpByDxoxmelUs7uk3HvR7b1rE64iykTgbF3p
VxcUe6rpNxOAk3TRjM9qnbnFBvgot7RUrUIrpJpr9m7Ue79870E6PdF1mZ7sms4dStzjz3mnEjIk
dUGEGCCxzWCAIAxzUYCDIGrmFJAMAgRqQCMjCVoQsJBGoiBpJSkKQlSFpCkmQSpJGZpASFptCiSo
1mgRsPePSeJyu1Q+c6bnkvMtOmIbPWMjZONv1ThT70VKt7yoTktWV2WEirjHVm6cahcV1CzPKpLS
8Bzs0TA3NlVLtyqNwXT7I+rTyah2Fnjq/cmtVuCKnautYl5CAOwRMRbmNXuvCpXEqjZnNafy8K0t
EbX7fwqF34VG3rqc8+rTyai4i2Nabe+VHvvKlXLrUZ11Dc51vWLgnzfniQkgZKCQaTBLQZEpCkgA
wZJCVJUYSkgtKiMjJSCNXPogyNAUEkYIlnyBmaQhaSWkIMyMEaSWlSDB8rYSiMzCFRsLI7pIOGE7
xskfyZVWy5/pWR1PiLN3fxzzrHSbdvItx2bOeZOWa3sTIlGzDZnKszcNHHNL2Me9YiW5MJdpwk47
sGsgzW+h3/SKlGrSZjDdRzzm1kWHfvGv+cfMxqZKLcdY2UZ8ZOKc9YyTZIkozq8hpRuylGAdMXTZ
DxkUhF91x7/i0fwiAAlSQR81AAlAkKMA0pWRoAQDCj5qNJBYSADIERkAAARgjJIBGCBpMGCIjBEh
RkZKJHRIJCwqyqBBQCebOFVPTxp6OuvXhx5KbFHN+RJIzI0rBpILIGCBKMyIjIGCUZEE9uZglGhZ
K5LMgpJkSiNIAUhCzBAEnoQIEoiMEZKIJLoEmAaFg0hC0GAkGFBKVER81jmZKNJoUfMKI0mkzNAM
0kZJM0qBAlJIzIlESTWlKiSZLIjBEaUKNKiJSTJKgAaQEmASTMyUSAABaTSolEoJjod7rtmYLdOJ
1ux61uUo1vzuvceCTA6AgZEsjJKjACTIGRkDBg0qSDBqQnokAwZEaVLCQSkmYSRGRhJkSiBmkyIE
ojAASZLIyMA0nzUaQo+ZhClEaQRGk0giWAhZoNSAaQZhBmQIESFkFGgAwQXzMIWhYIgQCVIMKNAU
RpIyUgJWRGlZErmZhBpWSSURkpB2k0dEKJYEfCWP0/mHHYO+WaXXOGkMYbB9VYY0w4pUZkQUaTNH
XmZAKSD5rUgwaFBfM1AlGRABSTNJmQMAkqNXNZIUpJEpCkGrmSjA68jIBJgyMzJIAM0gGpBAKSYJ
CiMjAAMkKQFEgKIyMgaQpaCSSiMgRjn0SCMwkwRGQIzCADBgEkzIjAQZq5glc1gJMGRBIMgDSAZJ
NQ52oEZLC0GzgJ71LlUJv6ci1msV7R42Q8/aXIYZG8kKUpICeqAaR05EOiQCANK+ayWApANK0mST
UaDMzUhRBJgwQASpIABABBkZmREZoWQJaVJJYSFEkzIGDSQAAASRqBEDASS+ZAzJSTSDABGgGZ81
pSZhJmaDSYWgjBpStISaiM+ZmgzBERhaAaUmFJIgZoWCPkZqJK0GgGCtANZGAlHGAdeg3UPdOcVb
azIu820bFdWqWXMiMjJQQo0kolkkgFISS0rAQtKiUakmRmgKPmDM09CT1SSTJSVEXQuZpMgRECUk
GCIzCTAJRgJUYJSUgyWfJRkYCQEEowYBERpASRqAMlIIyNRJIGRgiMAIJRkpCkgyIyNBhRBJgEpC
kGRkpKiIySoJBggCNXPogyQOhJQaVKI7EsdCSo+aW8EiwXTko30qpq1hZiGkqqxSk+60p5n0BcjJ
STNIJBGo18VdOaSNx1QhXM0AyMIIzWtKgRIWoBCwtXJKEkEmkGokkSiJQI0rIAlAwkwDJKVgJMyU
RBKgFJQojACSSsEYJRAIM0glpNJmSFmk0pWCSYMlBAMJWhSTCQYAIiUREsEQSAaVAiM0kZGkyMjI
0EojIysqyWRKUhTSDRdNBhpSNnXym3OAlqhYalEN12+48KbCFL3CpQ/EAKJdjho3ig5W0VLgCRyN
zc+9Tl+tZHILSXFJr6dAoySSiNKiNzco2tcefJCDIA0giBKAAUlRAKSYSa+agQWhRJCepJNIJQIg
o0GDSEkoJWklAHyUhZAyBgIMGkzBpSDI0mlYQSyIyNBmAAREZAAjBEZpCiStABKIjIySoGRGCLna
FGD59TQfKvufRJ1fU0120xRXCIXh1/bY5HHquxR1Fr5K2jNs9kX8XylWj3Z8jzmP59tLveQP+0TB
NE3r0TWsZ0uDoqF9ZDpXITh1scuz4TTeKmeMRNdIt31j3noXPM1kI6tsSQDWhICTIzCVA0LIgAoA
iUkwADIkrANASZKABAlGEkpPNRpAMEZGSyIEoJNIMiBkRmSeiCUk0hPQkqIjVzCjQaVkSFGRGAk0
dAklEQBGQSpIMgFBJlZi6Dmo1JHGvvvTdWz7ebJiGoc851zm9872O/8An6IGib5zqdxY0y6N4C01
ea6wsvVNJyfII7j22e+5JscexwSNVre1YBVt+rcpDWKRsLbOcSj530fwjbJItovm1aWFMNaI2Hmp
7PLLyr+HRnAlKQlY5EDASDIzMgCNKwYSpKiMESSMlpJSTSolINSDBEaVpNIUlQQZkYSolESDIlJU
RmRkQIGRhBGFEQMGk0mlSTQZgGhRAkmogSQDIzSRGaFGRAgBZ1JAWhSkcIFfoN7R9i5Vmy17pacv
07D7lOYdEL0DbIqTKgstMgrMrM9NVl+lY/rWZ55Aceuoa/hG8Vaw+cYU77vnnWvb+1dc558nOq5n
rd3sFyg9Cz1hoOeUzW46WZXOnXDgxqDC2VXI5DjBzL6rv7BUG5EAEqMEYMgFJJRpMgkzMgkKIECM
zIjAUSUqQFkkwYMIIzAIBaARnzUQBKSZKQZLSlSTSDIlAEZoStCiNJgEkKMIJQIjSoJUkyAASFJM
gEnaErIwCSnjDNbBp8ZLQdkl3UfypFyo96z6v8OmhXKI62DrRbjJU2Yl68Vhjco0ecxqtBWu3jId
Kr0vjUaeo6fi9a3xll2uNKHqXTMM1RK7hLwCbFGQFza0y9qy7QqvMSSIp3MVbHdrolB19vlOgWvE
+CTBkRmQUQSlajJK0GsjSQMiBpJZGEKIi6ERkZJBGpJkoiMgRkoiNJGACCevMwEkowk0qCUmZpMy
SDCuI6EpCkmQJRclmRGpBEYUgyBkZJMjIyVzs5pWAD5IRCs3siolL5rPj0SfMwZmhQQrpyCxw7gE
rkpCwEDqkiMAkdyQfXknqgGDNJdD4dSR0CB25maSNXMz59S5qCB0IAlpNJkZ8zSfQgRmSVEpJqIc
1mgjMGgwEhQAQsiAUkyMjSZGQAAUgBJhINaQkEsiAJSF81EZEokqIgAQUhZGkyNBggaQYQoAjI0m
EEsEpJBFpACyII5Jg2j98paVGklJSpCwErSRqCVEAYBoNJpJZF0MyQvmpCjBpMGELIBKwDT0MhzW
EKIwEhQSAkGlQCkGgwsglRGaAsjQoGEgGFJMiILQApBrQQUhRGQUkyQoEAXTmYUkgCNPQAggyAIK
SCUQBKSAkzVzI1JIzT05GaDSsyQpSDPmo0gjIgDR1QlaQCCSOzkYNJq4FyiI99IH0JJmEmRhaSM0
GFpASlajSrmai5l0SYMzIgAC6IMlJURgyIlJUCUAYIJWpAIjSaVEYCuS0gJUlaDBmQIwQUZoBrSv
mZEZpI0mDIwAlQSskg1pLn05mQWkAEFJIyCiCkGD5rQFoBgBJoMyMiURqQpINBkARkDBBKwRpIAE
vmZAlBBmS+ZkR2RKlJNR8OaIdg4lVGDCkmRGlREoGQCwhKgSwtBBK0mQSFKQZLSs0q5rSC6BJpBm
kAlkS+awAZEpJpIyBGACMjJQQZg0kaiNK0mFJStCzQpC0mlRA0GDSDJSTBAjB81GklGgzIgnolRo
CVGSQojIyAASrmFc1gkKMGQSDBKSlPVBmZGlAHVBGSFoUpJp5moAgQXyXztA5L6IC0tiiY5xJqCy
NfMzJRGRmg1pJC09EBZGlaQRgESj5mZAzBdE8+nNQNKkmRqBAwai5rSsjSZpIunNJKMkKBhIWDSO
iUo6klRKSsgELJQCARmhQXz6JQaTJSjQASVmZJAQDStJmOawoJSnoakAGOXQkrSZlzUkzShQNQBG
EGEktC0ERrUnkOhggSTIiANBdEBRoJRJP//EADcQAAEEAQMDAwMDBAMBAQABBQMBAgQFAAYREhAT
FCAhMRUjQRYiJDAyMzQHJTVAF0JDRFBgRf/aAAgBAQABBQJz1avcVc7qpnc3znviKuKq5yxN8ROi
b4qZ+ePvxzhvn9ub79eWc83xMVcTbonztiLnxjcXFXbp+N832xHZyxG+3Hp2844qZwzhm2bZx3zb
EzbfFbm3tttnHdNsVNs23zj7bZtnFMVubLm2bZx3xUxrcVMcufPVExW9Ns36e2Im+bYubZti5tip
0di5vm+cs5b5y90XFduub41cT3xcRc+cXo34RMc3N8+Om/Vrt8b7psmImIvvip79ETF2xube6r0+
c/Hxm2Ln4RfdfjF9ujUxUxvRcTouOXEXP/4r7Ynz84qeye+bbYmOTNs3zbquLiO9t8Vc36cs5Zv0
54nvm+Kub9ffN836Jm+2cuidOWb9N83z56b9N83zfbEXFzlm+J0391zfN8/G+b9N85Zvm+3TfN9s
33xc3z5z4zfN8XN+v4X3Tqi5yzfpvm/o5Zvidd/dM+cXo/PhN+jcb7Iq7435XN8Vfdq4q79G4q5v
jlxufGKub9N8a7N/bfN83zl0auIuK7HL775v7fHVq41c9uiO2xHcunLN+i5vt03zltiLm+b4nRy4
mfjOXujsRfd3T8b+y41cVcXP7c3z5xFzfpvm+IvsuIvuq5viO36b5y2zl0cu+Lm6Zy6b5vnLN83x
HYjs5Zviu9ueK7OWNdunPbHP91XfOWK/N85Zv7NXGE9+4mc85Y12c854js5Yrt8R/vyxxPfliP2x
SZzxr8V+dzEfnNNnPTOeITfO5tncxCJnP37nvz9+eKTHO3xH+/cTZSJtz90ImKXfELiF3zuJupd1
Qud5M7m+c/fuYpfZXpnLOaYrs5pnJM5ZzzlnPOSZzzlviu9kcmcvZX53MR6bd3O57c854rkzl78s
55umI/OSYrkznnNM5JnLOWcvbuZzTN855y9vjOSYjs5Zz3zlnLOaLm6ZyzlnL33zliuznnLN8R+c
85ZvncxdsR2K7N83xXZyzfN83znm+b+26Jm+Ltm+b+/LN83zfbOWKuKvRVxOm+ETHdN8Y7GvxzsR
+dzO5nNM7mc0xSe6E3xX7Lzx7854pPbnm+c85e3PEf7c87iJncxH53MQmdzFfvjnZzTHE2xCe3JM
54j/AHaTbO9nczuJiGTFOmd1M7yZ30272d1ud5MUud3O+md7376Yhts7+2d/O9tiHTFKmyHTfvZ3
s76Z3/bv55DcUvv387yLilTFNnexDpiSM8hM8jO/nfxT55GeSmeUi4snPIzycWRnfTPJzycU++Kb
O5ndzurndzu53M7md1c7ud3O8ud9c72d7O/iGzyFzyFzyFXO8ud3O8ud1c7ud1c7y4hlzyM8jO/n
krnke3fXfynJnkLnkrnfzv7Z5Gd/PIXFOueQueQueQud5c7655C531XO8qZ31xTrneXO8ud9c765
3lxDqmd5c7q53VzvLneXO8ud5c7y53VzurneXO6ud1c7q53lzurneXO67Oa5zXOa5yXN85Zvm+b5
yzfN83zdc3zfN83679N+m+b5v03zfN+m+b5vm+clzfN83zfN83zfOS5uvTfN83zfN85Lm/TfN83z
dc3zfN83zfOWcs3zfN+m+clzdc3zfOWb5vm+cs3XOWb5yzlnJc3zkubrm+clzkuclzkubrjvfHfL
l2xxMQmd7bO8q53c7y53lxDrneXFMud5c7q53l37y53FxSrnNc5rnJc5ZyzkuclznnLOWc1zmuc1
xSLv3FzlnLN+nLN1zkuc1zmudxVzuLnNc5LnJcRVzdc5rnJc5rm65yzfEcuclzkubrm65vnuubrm
65uub9d+m/o3zfonp+eu3/18V/pbdUTfOPXZeu2bbdNsVqp14L14rnFU6bZwXptiDcuK3bojVXFa
qdUG5cVqpm2dp+K1UxBudnjkxY5Eztu37D9uwTFC9M4quIAi4o3J/wD7A7FTC+2L84wSvV0N7MZF
cTHxlbg46kzw13bVkXEqX4SucxEriKj4qtxlc9+Fj9vAwHmwsNR4qbZx9ts26bdNs2zjiM5ZFrHG
xaR+HrXCR49s2xUXptm2bZHiOO5KJyNkwHCVoeTotK4jZVQoceJUWDXrIV9EqMkRFEseKpnNov2z
K5Q52F3h0ylbJpu0hgKxYNY6QrqBUZKhOE4UVxXgouTJtOoUcFd4FO47TUSMa6Evej6d5D/TzEx+
nGsbKjdolfWLIUmn/wBkqEoHKm2bYjcrqhZCJp5mSqPi08dROhxu89tCjhTInYJX1ayFWhajZ1as
d0eI4zo+n0Uc2n7bfHXnX0neYahag5URQO/+AIu6+tpBqz6EFUsaPgwo+25GquK1U9CJvlZWqdfo
QUZZ1HZUERSkr6ASCn0bUGSI4Zamm7uGoBObYVro74Fesh7aMDW2tL28HFc8tVTCVkukYopERREq
qvuOJUAdlnV+O6HBUxI9SBjLKlbw8Z3crKpjWyKcD2ToCgJWVndctUBW21PwWNAcUsGrjsHZ0glH
IiqF9bC8gkerAjLilaxlfW90oq+Kg7WoYmafjCe9wIQsHHhGWwrwieyDDGxBV7lk1kd44VY3uqkI
eFgxpLLOD4pNs2//ANP26bdNvRt6dsVM44ZPZcCPmtZVtRtr2hspo7HNtIntT16ZNYIZo4xOC54U
JNYPtx4rHR7Cr/dCis8W1FtIrDDak6D3WnDwdttitXNsaNVxIr1x0R6YglXPGfiQnbAFwLHlCjhb
dCeSVHQ4JbNnwoCyXyq9QYqZtm2DZyfWwUEN1kxCTIqHZCrdyFM2E1itmNNW/wAgAWwRjsUMSwhI
7K6vRjSWLROPHSYCLWbmKZkFgpDZmS69O7HAkUbbXmSfE7yV9ejUkWXi5v5wm1yLIVyQWRp6SlnR
UE9LxBgS/M8zSK+NYbulVQeEYlgrX2TkKoq5xcWmfiwnAJCa0UWTYyWHiPUsazYncgRCq6PySNLD
3poQpED9V3PMjIUdZARuS7F0d4HecEdajpUoiQgwp6yHW0PZCt9/6MWtfIcmnHbGpnBQFepnLSv5
LQORigdDL9c2ZDfJkllSGtjS1R5KeEw628JomKm3WI3maNFQMY9iRJPFsqHBgN7tnJfHSplOmDkQ
WukSG+IGFPMsmxjNWPXxGijzZpWyIy+YAEFnkWhVjsp5JHpYQWd1w/FAOxM6RIA08athNRlqcjS1
z3Sg+ExZdi5Y4ayUZS2kRvEMdAxzSTJIGzyYkGG3uW5yMymMQrL+KiZp4SoS2Y9GCt3lZXgakefI
J3oC+TDsCugSnzSyMo2vYS7N+x9oZ+QxOIbuI2HXvR47OCQ0iqa4ArviUkKjCaPL08jWyYygd/8A
av8A8G39bbr89duu3p29W2bdPzm3rd7Zv7F+F+a0aPOREZEnO7h66Q5pBAbJCVqRhyzKSXAbyjSY
vv5aoSvf/HXtlxw0GK3TYsd6tJGTuQ7VEQvRqe9XWI9vYCLDiGRgQsab6cxc8YSJZQ+yoeRSRa5r
cM7tRZf+anlMjutpzTqvv1hpufb/AK9I6847P4sNNnWQu6etZweVE8iyTcMYHEkhEUIf9N4Ny1/+
rGT79qPmSvD2zS27kmN3jjjYqbRoqbCmB7p6waNY1E8q12ckQHbLbt+29FV1ZAVyyJiRwCehpEJE
7N0iMWA3yTuRsILbsTlmkGRsBVWOsZjnezR+MsiQ1GwmDMhQP9rGT7x2RkTHN/jQE4hkC5Gq04NZ
/uWjeWRgIM1t7hKn9ESbrWgQceReOjkbcsOyPL4zXNa0I5zSGuhMVIEFx1GxkQdhYd1z15LEnkiO
kz3yEXrC9jM28LtjVY3+nDT7k5GqatRrTG9pFi3kMbGdyYnKLFT+GVrVNX7JHi+0qwRquiIzyJyf
clpuBqDz5iwU+xI4uPW7JiJ/Ks0Rcjo3v2Hsz4jIg8h+0KAmzrBUbKq+Pk6gTbNPlZytytYJXbyo
H+i/i2RWJ/Gv/eTWwnGV7hwQzZinJHCpnxIqRRzrFedUNeEu1HGLCKkwc+C4kiLH7ImCRR6iG1pl
67ddv/h/Ho29G3XbNsTPnPz6NvTtm2bdNuidNv6Hx02xfjpt02/obdPz0XPwmKnR/QzfZ3zV/wCW
R7w5C7vhovOvYohT07gyiVsitdtGlzUa7tqQ8X2hec4J2H7obn/OJPuQF/iW3+Zegk/fV+0S0c5D
tlkYgXuIdjv4b5vA9jYNkIPkxY1gZSuZ3Ys5OJQRnSVNBcDF+ekRPvDdvAUyjLGXeHCXiSyN2lrS
ciHd96wXcEYyuJI27QF/jGN2zwfaLHenlWjla6vfzJLcndOu8dhlUq+0aI5FFOIrDV6rwR38q192
w3ueS0f9mMzuS3sSPFmSFeRjl5Vu7oVwqqWn9pFo37BUcr2ALvC/0rDn3q73ixmp3rnfK7/Tke04
7kJHRxEM9+0aARFHYq5hKnl22vRsu23Iler3vtCIkc+Li9Uz85tgP74P+hat3IyGR6RmKOUb/WLJ
JHOOSSaSPGSOKwlEMUkAmz2cVp69JS2lYkZqpsvSGqdwT2kgkCZJAHIKHCkN7luJz1qGOY852+VO
+9FiRid2YVrRRTp402ORJED7USLKYsuzE4raobmlnSE5lJ3Y7YhO6R6CjVsxrh2UcndqmKIbZLfN
s298NbGewllKbxGZCxXwyd8b0jxa2Uzu20V0h1UJQreSUJmnWKknUDVUe+xaySwkObBe+REckWPb
kaYtA1FDfkVHK73o/wB8i3Xg0rlUtM9FiXEYjz0W4RK9qzbkbuzTkVBagYqlcm39TbFTNs29W/T8
9Uzf+nt026p0/Ho2zbqvRc+Om3vtt0/PXbF6b+r5xPUnq+c3xcX4L8L8wScSDlIePYROK00fk+ZM
SMyNL8jJ8fYkJnGPJgqY3hMAwK/x5xP5VY7eHcu2PAi9xz5TYoZxkKRc+MZ81chOxKg9946tEYwC
eYjf49mPi8SbvDCaUQavgQx0FFmk5lqTMC61lsVF6hJxWDYo8aRmK6ZNbFHFtdjuRktreMYZ7TkW
NMbKayOwOWNltkCy9ljjIsuWyKMNptIYRJjftxmTLLm+JYd5rYzEWwsO22FZqxWsHISTJbGH9TXv
RZTZjEGKPllY83wHp35klviHXdYY+4WA3iG3Gm8M3YM0jZgkrGNWbwFlbOR43wBkcrxxBRrD+SYb
ZTAlaPLPbK+fyzgJqWM/INg4LxduS2XMZGY6c7vQprJKPVkdtlPUiudvm+6dPnEz85tjF4rU2COD
4YjYfsxxQyCNKe5iitWJ3IDkYdhRlEkUDXSlC0U1E7sGw8N82zWXi9Wu2yqtey7vgVLGemBlvESF
PEccqaMbDynKSstUVCygjZOsFK+HPWO8c2OcVjZIxEluGWBaCI2TNGNsqY57q2z4K6WBW2M/m6NL
UJgWQDin2aIjpDlJWWzVw9iJGS5ikdXWKx3pYAc2zsUc4clRvhXAXhnWY2sKbuFqLAAxzJ8cw5fu
WvmrEIC2jFFaWSEa8iqtPajjDtpSSHL7rWyvGNPtByREX91VZ+OqXEF2GswNatk5JAbyOUTrQQn2
VhHljJ/d1/HXb0L1/PT59Ce3RfSv9BOvx6Uz4xPR89E9G2J89N+m3pXr+eu/T8r1X0Jip6Nsf0L7
ovy122RJ6hdLsmHHCsmxssLBZSwrHx8JaoUjbwbWpfAw1y0uJccRlkKQgLbsjkSPIfFskitlzlk4
q75vi5v7xZrgZ+oUTCXncQE5RkdqFVSTMdJXfZYtq8GfqR+SbV8lquxHrivV2fPoGZR427KxhpTj
5ywFmUGHsimTffAynhV1yZyPMr1aZWKy3ONCS3nzf3FPJHwlkUuK/wBxSFGrrmSqFM4io/BWRgoa
a82csFLIFSWZit7iuxpeKvnFeiu3xhFGqW0pqEnGMm64KecKLay9nySFxsh48+qykR085EQqoqTj
55RN3SXvxpHNxZp8UivXntg5pWI8735yxhnMxZZVxzt83xeqdF6b9GlVuNmFx0ojsaVyZ5ZceRXL
yxp3tzyi4sgi4ruWbdN9s33zjidEI9Ec9d998R+2d52KqriKqYhHYq5viPVMUrnZy3zlnNc575y2
RH4r985ZyXOWcs5bY1ypjnb4i5y3xXYuJvnumKufCb452Iu+cV2VVzffN8V2b9OS589EXN85b5vi
vzlirv0X1J0Ru+KB6Yrds2zsvXFE5OiDc7PHemKmyom+eM/HNc3r8/0l9e+Lnx0X5z5zbEauJHIq
OArMT5YJXY8Stz8tE5+eO/Hic3r8dFz59Hz6U9a9PjonXbpvjkxfbC4/Exg1dniOYjQOIrwPZghq
9z4rm42C9cWufjoBExIT34WOrMFEeVCgUSjjqXCRlZit68s+cAFSq+uc1hGcVVejlxM3zfF67ZGh
OOr6lzWvArHBApHNqXKh4aizb3jVylQtYokcNWrGiOMq1DuB4yiV3t13xeu+b+rf0Imcds3xV6w6
9x1fS7NkxHCcGO4rx027Zdb2s7S8odSpUkVHFhAKxYUFx1+i/tlwVCq+2b4jsXN836r1g1qyc+ht
2mwVC5Uzb0Kipm+2cs3xvutfXLIctIxGzK5RZGiuK8FC1WTqXg1QLzr6buoajTaXEdHWBXukq2jY
rLCpUKkTivRM39/z036fGbYqYmbb5tiJm+Iirjmq3p89Gt3Wur+676QLhZVKicCI4hIlSNo59MxW
EiuaWqq0VXVISZZ1yxVrq5xlZVBayzpeDSsUbt839G+fGb+2Lm3VG5tnxiYMTiY+O8fTfo1N8ra7
uKyJHclrUJkeE574teITZFYCQM0B4y1tZsixIxMtaxwlrq/uqKNHYyzp2uEYSjd/QXGpnFc49FTO
O2KnQUdxsLHeHFzbrtnBUxEyFCUqx4ghNk1oJUd0BwywK1GNWHEk5PqnAkV9Y1AKaCNx6sUqPLAs
YvTb339/UnXb1bY70L6FTo9NuhP7CfI28nVddulp2hipBte6xg+1VX+9k0YchMYQRniaRyDVkSKw
jLCr3yshIg7lnAta9iKeG0wpcftr0RPdEyrYvM0dqhmM+/4jnJ4ZMeJzMRMi1ayGyYvYxc/CZCB3
zR4yRWDlsO+fXplfXbYaYwKnjNksi1nIr+MRBObMbLrtjR4bY4vMY4k2Ciskj4vXqub+3T4z8DE4
ijrHqhat7cUKtUVc8iLUvRDRXiXbIFZ3xT4fYzbHYmQI/eMMDYog2rSnnw2vbXV6MbKnLHcxjZgR
1v8AIM7whxJ3lLYV27wRUjB+p/yJMRDhmg7blzb2xfRt0Ym60oW+KaX2C2hmnyPUkOn0B20mtcBF
b709a2Wy1gJHR3z0hC7hWRUjgbaL3yx2mjVlc1uT5Sx3Q3pME6uYsmTtDBXWLzksYSESJCQAZFk8
cho0lRrMKDIvq/GInuCM4zmUH7FpXOdLq/GSFTLIRdNZMp1jpx/dQRBSHXMNgkcnFekNvI0UCCin
mlbKRiSYsGGxS20hwcpjOOkuG3vSGeKCFLJ5c6K0oYcRoo0+UVpYrvKi3sZAm67dfz8Z85FjqZ8e
hY5hNNi2m1jozq2l7zU02FyWFF2WObxdQtG4t3HE0Cpm2JkZNywwtbEluP5EL78KFFZ5Vu5zEpHv
aSYBvclM7EaOU6SZQ0JDr47WxLFTPPXqpY18JAm9aZtkGIp3xaRjxv08FW2FS6O+uqGkxKGO/LGg
aJjmKx1A4aF1KEKI7qJnN1fUIRFoQOyfQIMdFHRFuXPYtJyV0mMnkWze0GC4iGmiaoYKo+DPqyPm
RF7Ma8VHTV6J6k674vTbr+XehOu3Venzjk9yp7E/vhtRxgsayNaE5GgSOD4zElCIFADtjqQ9R7xp
UX9xpajfVLuFVa9ey1jb9uzhOXKv7ka6TYit6JkGG474kNgGyP8AX7PdmBhiaLiHLaOxM+FrLAQA
2MlDEXrSf7Ng37MQHB8luwAInimCr5MJv2YzUQ9sxXErR9s0ln3Zjf44o/7yJvCmf5fz136b9Eyi
r0ex42tzsNIkmGxhxDGITpgHOs+09r/Z8O2bGbOneQvWn/253vHFGTkVv8SGn8eSBHmqkRoWJ/Ks
2cshx2jPOT3Km8bxf3MT+PZp9939D5yGid6tROzdo3jGVFLFVvZLYKx02SMzDf3QbJYmTJ/k473V
c+crP9g3vH7Ld2t/iwU3bNGj5FSzbHJ/LtWIrY7EQkpPttT+K8LXOhp/DuE+67+gmadF3n2B1iJX
J3Q20jaTCe18eQaQB0i1a8J/7ost8Zx55DovuufmD/sIm0NEY/I3+jCb92y4eTWtTunX79qmwwoN
Mk/68RN4L+HkV/8Ar6h/2F9a++JlXKaA3LvxnkmRnTLdhnU8wRhzRSmOJcKIchyPIBXtUkgz0d0T
IfuWKn8Hvs71d7xIjf5lq9GPr9nyJiL3LBd48YzXNJ+6JC/1TFY2VWf4tR/uNn56L0ROiLmndnkv
HqIY7Eo3lue+lRNZIHMrz8jWRo2SH9x42vdhCF26JkJN5MJrfDc2PyKaOwdere/bFQJK7i85/wDJ
cezIhGPjzE+zDH245b7syWuSVFthdmWvVfSno9vR8+pOm3v1+ejs99y/D/7q/wDzg94Nkn3wJu+q
GoxzP3jsA8C1H+GwmIJxUWQer9o8qcoDRJXkCvvdR/5Kf/XvP8rujPdaKO1QTZCpK91iFJ2pkaUh
huiouWKl32948F5kkR1Cq79aX2kz3fbAbuEOv2AL/GkG4SIK/YjuRD2rtlrzdwkv3dJ/fHEZe4T2
iz1+8uL1ROm2bY1N1odkDPs2xF+vte2TLfIWFMcrXRWnyxjuGrk2dBrHSklwuy5cTETKj2lSl5AA
R6le/wDjQ3Isea57ZFWuw2uTybX+2te55Zr0arnIsYxS+Q39sW027q5v0XNun4xMYvvSb+JeIqqx
FV0GSWM0bmScs6/ZHN45WVnlpPgJGxfZcTK1djc0fEQZVPy4xq8zeNsx6FquTGOK3ybPcoYQyKea
VrWsIj40thmyYy9qJbO5FX1J0TNLL+69TklS1Ww7gfOTEGeEsWeOWtrWNJhW8HUtck99vWpFRfbr
Dd2zBKkiIaKbyAv7UaDKb3reM8r6ZjhLJmMSTPTyAxIxGmlyUaCvlNfGmQDLJh/x4twVCkXrx9CJ
iJkSH5DhDkVqRZCTB2dUgyx60o2xLArlta4ZgmGo3UUccg91BGMa+3WO/gStkNNGl1b3nARIkWHY
s821grNbUgWJkyeNHvekuOCpcGTLlNCCsmsfGsK5xCxf4YLgyFMvo+fQnzptyIa7C4zQ1RVcemUO
CpCsFDmy2utYyTByGdotCwb330ISCdui4nzXrtJB+6vkwSvkfSXqKnmtAW1rnzh1g/BZIsmI+TtP
jQ698csywYmRXISFMglWwhr2od37y/z6FxP6Sejb0fnovTfFxcL8P91iLsSBOaSNZxeS1MfuHLKS
LHh2Pk5Zx+WVQ+0Owh9944DQjhqiNtnbko37ivn/ALoEfvOYVsMNnJ75OjPZaWQiMlR+RWERQyI7
Ulsh8EjsVuWzWI3lutWYfbtCtc9esOR2ShltltDFYN1hZozIFnjozDLIkNiDFaffbxmNYNkUc603
dBneSwcRjH2Vg0KHIryfn4zfpvm3VvzSzUakiMknGV4hJIUbJDIwyjDH7GWrx8CO/fV2bYrLGYh3
L841fYB+06tsWyU7IWOn2XHIVpwc1oj5KlNis+qO78WSyYxe1GbYWXdJBsuWdgWWNl2kOXuuf136
/npCHzNX7CDeMQmCegzxexJCyMwa2R2tGdUe6ts0iZPsElY73XoInB1VZo7OQWpY2WyQ7FwSDOKQ
OZOGBpJ73Fr7Bp2kOEST7FSOrbdWk7wnpZ2KNQxVeq+/p3zbp+aiWsZ7CsMgmo0Nw/hKr5wDD/jJ
k+cxjJD0c6BYLCfNsllI752zfEXKq0WMvmhVljaI9oJrglgWoZA508Y0NKVz6q59zTwcJ89TOg2K
xiBsgEFa2KYYquXPjpv6oMxYhg3kcwH2UVqWtp3XVV6NjFtIL8n2o+2cvNY8l8dxbIphu6fnfIE9
0Z472M8VhaKTGmVr4F8xjJtyJzHmcR9fa+M4l7Gck2c47okxwCA1BHcKfaoVCE5L6ET0w5SxyR9S
xu07UEPafZuNlVqFIrf1FBXJ12MgyvV7xHIFxpxTpi9Bv4LWXXj5+ooatl3TCs8he7A1I0Q5t0My
PLyfW3HiLI1CEuSJjiErLpIqfqOCuTLoT2nL3XbdUXovRfWmbejfquJ126fjHYuEXZH/AN7XbLDm
KF5bVhRxJ6RlsLRspIUvx1PcNM8V4wafXw4a9Y/BXPbWXK774lp47Zszylhz0jZKs1Ox3v0+MTIs
twF+v/tbdLyPY910e6UTV1Lkye+R07rs339G+yxpjgY69I5pjOK4Z1Y4d08bZM50hUeqZGtXx8Pb
FMnNVUMlwVdeme0p3Ge7ptm2fPo983wJlFjLuQ1H3Uh+OkK5Q2xgYuoJi4eYQ+L875v1ToIzhqto
ZWkKr8Qm2Dsjjwskhs3wUwgMfZHIiv3VhVYv1Q/F5nEVXY70fn0MXjjbA7UfNKROW+ClkDn1E+Ek
kfjlzfbN9/RtjHq3Ellx73LnLGHI3HmeTFXGGczPKIqKq5v7+URqOer8d0VM2xeqdNsqCC7pYIyY
MyRI9kZCk5KipIIiuM52OXFTN1xN16cVTG5yVFRX5zXFXPfOaonz0R7kxXZ85+5Mc5VRV6fOLm3R
cT0b7Kr85b5viLiuxcT0JnxiZyxXYmb+/LN85Y1dsV2I7fN83zf17ehF2znirnLOeb4ub4vp5Z3M
55yzfFf0T2xXdN9s5+7n4rvR+V+EX3/Pq2zbonRUz4xc+c/KYvVM/GO6ET2J/dg0V2eG5GtErnOi
PbgxK5VhubjIL3p9Pdi1rmYkF7sLGcJRRXGwsZwsEBxsJCeJHJ7r1jQ3yMNGUSghuMpobgYvsvzi
++L60xM36CiPI17FYu+b+jfN98iQHSEkVKhaRnFc36tTdfBdwezguJ036cum/VeiZ+F9s3zfE+YV
Y6Qj6XbJEftv67rn46L6tvWi4q5vi9Nt8475BgulPTT7UbOrFAogKR8Wk3FKqOLHi4ur6tTY+iTj
NiOA+FBdKeyhbxn07w5BpFI1KQW0mkRGR6tSFZRhaj6BhGz65YzuPv0RN8rqt0l0qiaEMOG4pwxl
AwsXvNsK5Y61tap3LRs42FWsd9VVeSqU0ZMPSDcOJT/y1owsxKUKrZ0rQjEDmWJTJwm0aIOrr2Ff
Y0bY4zM4vix++SJTiRv0yOrrSj4Nr61xCMphOHZUvbwjODkarlULmepPRvm/RMX0L6/x0TPz85+N
/wCl+V9H5679NsX079Px6d+u2Lnznx6U9sX526fHRfRt6N+ie3Vem3oVPfbCpuhE92/NVW9zLBog
jqWo886EjhV9d++cBg21CDOI6jE5e2QUGI1y2FUjkq4DUW8AgVrisYQ8ZsgUyH2l+OiJ70KtbljA
7i1tegUveDc8VxFSvJj47mqkdzsSE9VdDezHM2zbqKK4mfTibPiuZkSE4z41e1kexhq17me4oDn4
+ARmK1UwcR5cbWP2dCcLKGR++2GnYfFcVTR3Dzbboib5W1yke+vb4s6IrVZEcZG1pM+lkRCAVigg
PNj6sjUeJWKCKpl+lEwlYRidh3MdWR+LTkRDR3CxUxM3yOnM0GOjInmN7tgNDlLWPxKUqtNEeHI8
Eh1+hmchqx4UBXENj6orG/STK0oFE5U91xE3wda96CqSEU1OQaNjuc8VM96PoXsx0NyEWpfxDRlL
kmrcDARVkPZp4itXTxR4aIoHaaAijnyfFfYSmFFUC5TJbewLz2vFIbzlVwUbCLO8c1qRhs00Dnlk
d0NHWAzNCxFjTJEhJMNO5FNLZFkntXlWoUu145r8BRukY/TKpkuqdGytr3SXwIzIzLFP41GxvduU
IjKR5+7YCY/Gxkjx2WZPNkRmmitnfTnumllvgbjDYWHZlyr50hKYxHGuVTx6wKvmS27RhW3BYR+c
2YDvCsaVRYEropnXBZbYDZCHl7KGJDa0c2aVkiL/AC4V3FQJ6QTCmt68LBEbxd/T3xevzi+r5z4T
07+r5z49X4zfpvn4679UxcTF6r/Q39C/0E9KYuJ0Xrv03xPbN9/S9fdcJ/ab+6Ozm+uEnhX5HeRF
NwfBekkax2hbdyVcSi9mTI3JZJljLSk7jCOauDC1uXyZy4uo17or1qNVydEX3qpKsPEa045KoEZk
WVNi1jGjSIzLCvTaDGGVqxRAcSGwzLKP2nqnSKzuEgwxdn7Q1sAjeyueFjhORQ2hBbMVCyIQW9sk
NDCmwkYaDAYILpMVjpaCeOpGjJc0HeGOC0DLVzOTvnGfNVMCjXEb2baUJ2UxGOd4g0zYT1tYSDdW
sRGNjNIlvBaN1VAa0RJYAKQ8cwocFpZDYyDagUdl3CaxCJ+7bNsrBcpEZiJGuU7TokxGmGBhB9wf
ObCY9IsJgBFtAscoGSRV8VjXGCJcQAntvITQq9NlXGLxWkcyUM3bjonCQIUMTJb+IRtnses0o2Og
MbIA6QyMWTGZIitd4MkdyxEJcI5JJ0MWja1BXTW9sr/eh4ZJ28ewJxLCcjjQURQXfDO5u/T/AA43
G3aUi96s38Uih5J/gst1kVlbtkqWkYcMnmSTJ4Yf1BsSXYMlCqAsQCg+5LDzBCC5kuQ5iMAonvnN
c0kj/U7TM2/hyguNMgVyCbZWXaQ5lK6HFdIfFjJDHZWakyhK3vSFakezVqmpveVNKsccc7bBlzX+
OWtkjCWNNAVZzN2RE/ivRjj1n+rqFPvhK8Di2pyse7dfTv8A0tun4TNsX1fGfPoX+rt026bdN823
zbp8dN8Xpvi9N844qbYmbdE6b4ufj1p6Nuqenbptm2J03z4zfH4uP/tL/dF/y1n+ndpuVm+9IFzA
yf3ttQqj6D3bYS0BkxzpRaNvEdjKUBoEzvsv12Y/50/+0eocVcXETK4XdNXj7Ipo+8MAe1NeqMEt
mFrptqx7KJ/Ml07ZtT+6LfbdxyYqZGVWOrZ6ub4jDOnjMJQvckqIn8KxG5xaiHyMVWQ2xJDSjsk3
mon8Gd/n7p+NLy8pHJ27JFeKYFyOdi4mVbl8iR/pSxOVaxrmyZK/xfqCxz+UlgZBtihhTWmy9T2r
f9O4RUOPvJmnuXKdLSNi3zUydYukNf8AOJkZytJEcroNw9e7H9yxV/6+VKcKT9X77h/uiSkVZUH/
AFYn+SU9e9EduTUibtImLiZpfL5VQYrVwGNkkKWLO3YSM07J8cgXUX+rZJtMTdIiuY2aEsbYp43G
c5iu0wrlFqBy8Xr70bl8iduseWu5gqvdrd/DvVd3V+dLuXL9VawftJjf6c9X+XXqq17YDTSpxvDE
Vp5z6yO8Mqy/dFMN5DrBK1ke2MBsC7kHLIIvjUpe5Jvd+1QI9T2LmopH92M0Bu+96MiRYaELbS3R
U8M05ZEV0ddNgaXL4qiYR6rlMi+VO/1ZKKj6P/ZtUV0fT7VR90PvOkVRBpVCIw879oYJmvjzIxvL
hL48W9J3JFSBsg9rTsCB7ffpt12xf6q4mL1Xpv036J/UX1fPTbPjN+v4zb07dE6/PXbp8Yqe3RfQ
nRPjombehOv49O3RcdhML/dHds+rnNUFlF7qV8feQ4iRARLZDHsg821Au1llG7+R65rWwkaNb9fe
hdl+5NooO8SNtDFbze+qr0bmnYqKSxneKyusvKacaCMR/kBWo3fJgtYGheiGvXJ2qdyeJfuRxXdI
nuSNCa8QhOE6c1qjVyJJr5KEjPht3ERkeTK2lMh/ZSe37gJCFjvrEIQsAYg1YW9+afgCrleUy6Y1
iu+ekAvbLGOkiOeMNjIQmOlGRqishIMteXtnQzJQY7WRHWTUMODKTY9eOQ5YIgCiymBkmG2SjKwY
3W7RDx/zm2VgUKaNxYC5A3lXAR5g7IC4Ds8Tu2WvmIUDq4ZHvK0Aq6W1XWctrCVctqkvjI5pugk5
LRjYJts1pBSE2fUvGhFiBNg2tiNuisJlB/ryYjXrMltCCW/mXlnLBLydTNQQbhGPGduxKEI0yQRj
xWgmsfXDY8sNzWAvODnI3ctG0Ym2isIE7eBqqxY+O6GEikkNihrZ7XmMIUjBxwCyyMET48wcgTog
Uy0KMYyO3dRIzkSQN42ymxJnIUoSMHHy1sEdlfbpiGFllZ5STWIAvjmxvYA29Ub36cmsA69ltKir
70D2NUs0Lg26N7tVIQMjzAlR0gMdJVlvJiTI5wKsZiWtmm0KycAg54TCtLREQhHPyMd0d57xZLSO
3Xp8Z8+hPTt6tvX+fjN98T0fP9HbNsT+htm2bdV+M36rn4xcX0b4ubYv9Dbp+PTt6V9sT0J1dirj
sL8tXI8pRu+tMUQZ6MPOuWnSJK7Di3bSNjXgxsdfhXH6garQ3PB86f5KwrPxcmWXk5DmJHdLuVM1
zuWL1gWfiLKs1l5DsfEWXbrJyLedhv6k3yXarKSHP8TJdqsrI9u4DJctZLl982xi8ViXD42LqRdp
Nu+Xiu941g+Nj74jmeS7kO8eFr7chHSLUh0jWj4y/qYzckW75SRrN8TDWxJGAsHxVlz3ysd1a7ZY
1oSPhrkp8BPcBf1BIXJEpxl5e4LYsfCWpiZ9XPwHNeJ6Xx8NbmNiHcjw3hgo+9kOQslxcdm3QB1C
v1qRh5rzIKQ4K/W5GHmkkIm+R5rwYl7IbhLMpcZPeJTTHFwc4ocLNIZF982xPZQ2JhI61kOa8ivV
r1a4VpIHjrY7ka9xy1LO3HtzEZh5ZFxffFzbbEXbA2BhoSwMRHu3UMt4c+qn2NIcTGEVq/UTohZR
Ct5KmDmmZizzPRz1VwjvEqWJ0x84hMYdzF+oHxLIuElvJg5bxZ9SNhJDyZvgzuGqTjbOO5+Nlla3
zScXmV+ctsSW/HkV2DkEGiSi55b8eVXYhFbjjK7OW+CIrcbJJhCq9UXZWmemd52KTEIqZ3nYpnOT
liGXFe7N84dFTOOcMVqpm2bbdeK7bLnFVxROzg7FY7psrs4qiL026oNccNU9HziDVcUDkzbbGjc7
EjPXHBczNs7DlRQvTNvSwD3YoXt6INXL4xEzbEbvniEVHjVnRgHOQgXsRG754pFxY5Ezjtg4zn46
EVMUasxrc8UjkUSt6NA8mPE9qMbyzxXYkQi4+K8abY2O5+OjvZ0azlixSJjmq1em2NjuXHhcPPnG
t5YkUi54hNlTZWAc9FjExw3Mxrd1UDscxW/0Nsf74vw74L/djEVyshOVqCVXvhubiCVXJAeiMgOJ
i1Tkz6Y/ZILnYWE9mCiuepIbhYMKkUsF7Mc1Wrm3Tf35Y1c5Zyzlm/XfoEClc2oJseE4eNaqqCtc
XJFY4WEHssSE42OpXIho7hYESkcOpe5JNcosjVrjKlMuSKpzEDEc8jaZy46nVEkRVErkzbrGiOOp
ahwxijOIQVIuzqXJcJY6xYTjr9FXjJiOEu26w610hJdasfHIqK1OSxqd5GSK9RlDQq9n6fTclBsh
IbmmBSKRsqpUSdh3ONSOcn0FFyVVqHItJ3mza1Y2fHTfN+gQuK4FBySbTqHO3ssCnU7DUXBsiOoX
w4T5LvoSI00VYTotw5uOC6YyfUq1IdU86pp9mxKNqNfWv74NOpxWgY1J9UoFVNs36BEpVjUG7JlJ
wQonNJXVDj4WibxlwnBdCgulObp9nCxqHAyDXvkEZp0LUfQCywr3R3Lm+b5v0TBMUroFEhmStPog
pMVwX1tWspf0+zjZVjoyxIrjkj0LONhSqNpBqxesYCmfComcJlA1GEj9ktZU99H0LFZaVzoZa6Es
p4aJnbtKXsoMHMtdSIrJdCx441KqnHUgY0tIIjZdMoSw6YY2JVxlS1o+I4dYpygpxIO1okYjYbnG
r6ZjWnohFCyCoZgamMgvDibyaUDgyY3bk1VQj2lqAmS0grDLtm2bZDj94kWpGIc+oCUJhKIvQAVK
tbWNRv0wBcsKt0ctZUp2uMRuSKoUkP0x3kwa4ImSqgMgM+K6KVU26xQ919fVsEI1bHMOfE8WTTVf
fxsOLteVKAWqieU8dcGK2xpxmCwX8itq2tGSDFkMFSbS/EjwmB8GWlvRtGWDXgANh697rClHIDCr
VeYUMEZtjTDkR2wFWTX1o4zCV8WWhq1Yk+LHi+Gw9fzPXxzAlB42NXWIjfBiSyW8DwS0lZ5T/GiC
bqGoaNqM9uC4maf8d+ahrAjBxyph+S7xo0IIvAkttdPJygVrAhaSucSxpRGixK1ylDBjDSzpBGjn
E4ROm2bbehyLitx6exk/c3KeuWQsoAgDh8HTZcNhAxa1yyZIGCBUcCpM7YcG4ZWRI7HSJ9Yjm1ld
xJdRmjbCXgTsskhsYPac5Nl/HVOqLm+b4nRM07AQrCOYDLMTXMrgoeV2GxhEcM4pifyKqG1kVSs5
3PFuUMXuukcY+TGMMyJFaEEi0aIzBocDGjBINcsHlfJ8zLsKJjYLi59MJhYbxZFiqd9TXNEliNPH
pozXmnl8JIEryn2kJCZEgtjj+oDUs+Ej2Aio6VWx2DHqBqLisVz6mq5KKO1grZEHKZcMZFbfbka7
vAFAQkk8lIiCc2wCyvakqX/HDFsnlNPjo6NSE55cRFMkqG4Sr6NNgQhZRPDZJmDLH7aOlRwoOP5r
OVrwc6gjIo5crsFsyseymH3ZB/47XTRmHXBb27KY8BqwiyWTuEUsi6VqVco0olwjGiHWEkr+nS5J
qSR0oq9OMyX4aRCpOZIqmrMViQxRrTyDWVc0jIMBscMm0UROCTQueyCU9w4uVJCvS84PaCjfJR2m
HJkuqfGyHAdKd+mn5JrCRs0/EQ5bEiV4quwdLyxq2OeGKkaOyzd5kqOkqPVV7WZaTXRSQH+cO/iI
B7k60oVWRLH2oo7bZJi9+VUB2iSpxIcu3mMlN0xH/dcEJFG60aaPBEr5zx/xB2ihdWFYc2oBGVun
0kdy6J2WrbkK2I2T5B9lBAiNaG1mlGeC/wAqMGuY6bbE8UFRJI917FaNFvX8IjzGkMVEiGGpZ8EX
GDJnHr5lnMbYPiUIjNl6baxJAFAWijKpZw1WKK2dFd4XnnHpsGx9LtyBA8eVPZ48auMZh540eODs
+JLrC+VX/Zhw47CzbwrwZQFLmq46IJ2J8omVQFcdof4T5p6+TZm+pSKACsHecwGk2/mRqKMvK7G5
wRXRo+RhKewjB2gyZRYEusnJLNexllAqYBIi35UcAE2QZkaqJ30Xtw68DHNuO6siiRys8VnlXe4g
VTiMfqESJHFYSEbAjKaUJ6AryhUtrCDtCszmrrGfM+oD03H7bdQiJwbbLMDXUSPT9Pgdlhp1BD08
i858ZJKWunljN08RGLfx/LDSV5ALarxcFENCHWlbP/trq+M1xbghmSaTd+amjtE7Fzf0bZ84uPT2
N/cxN3afGix9QmXkAvB1WTyB+MxmXsnimnvd08HdWURYeUpUK5xG4wTcvk+1urV04XuMv2IiF+dv
Tv6UXFwbeTtPD4Ctx/tPKdvp8PIslnIEwqgJH+9LhDRse2TtPkSFPmnx7Mtx/bSU4Z4RO5GNXNcV
qduPZPc4tdBJIVVbEG83nygRBgD5MZVs2jKlTXNY1N2vlj5x65FGWWFDtiRmCyYu5D/6bYiOKqfx
JrlDJoZbzrep+yrjIc6BQTIyKrbwHJXIvKtrVIppKRg1hO62wB3T0w+06xL2CeQyQMEMTX2CfxqD
/NKIxuTa9sgU2N2Xr0T3XTg2olmNrgyidt9O1HyGjRQXH2ytd3S0jEaK6anExnKtAjcmNRRS39k1
GZXDlBG4kZiDbfPXesr1kOVzIgpMxZJ40VAgfciE88sBg0bURlgBClqRdpxf9qyZuOPFa18lv8cP
vFPFa8tciNjXabyKusyRJZEGE3my3D8MP18fclzRmFVgd3ws3yzhNUGmw8JVozuZAE1smwT90lP4
rQMVyJtFrk2ZOY1xqlERNTM/eTEz86dI1SyXbBtSffribHr9vG1AVm6k99NlR7blU7Mon76IrUMR
yJGtytcfTjXby5Iw5EKMj9QDc3IEhAkizo5kltVRQfaFI7bpdbt2Af79wqZBYxDX/wC4I4/eNXVz
Yo7W04ZBlJ5kVyKC+kNctfGU5YUVwxtYit1IBoj6clNaWWRGR7MiFPp8LVBeSyxSxdRETIklks9x
7MAo3pLTcEAKgjmuwjOPaXFq2dqRbua19ZxWXqj/AFne3WjkIw3c2i3MpsgoDqIlKfvA1JLaPOS7
6clZdHQQpRe5IqZKikhJyhXUppjadj9x1jP+mig2yWOalj8Ehn8V8TU6GWQPvxK1uwJx2tn1Sp3V
/wBq+cgWQntI3Ujf48IHkviwWwQXFnyWBMc2SA3OHqCcj5DH8H6ek91l9N8cNYiLPExEhcY+55MZ
BVSIku7MoR1BFlR7iP4MuJqdwWwb/wAvLRnPAs8aGLUXdPIH34FYnHLArBya9GrL1T/dn59G+Lsm
Lj/g39wv8lB/q6gbsrU/dQBc1hl3ZdR1R2nd0Wwk9jJ7/LyiYrFtDqF1bP72Xn+In92m981Gn7C/
K+/9PfBrsunTK4V4VWoVd30RnMky3cY096vLHeoy1xFJEvSqr1+dOmc5Lp6tYz9x4LUbFnTzMkQn
d2KWv78lBthjsJZJTqhijPO/1Dovd7525CvGxWRbgJiSC7R65zSHtiqBKqUQxZbE5lX+P5C97faH
ZL/I0z/dfb7RJniP/UYnpXzEOK9PtkJvfk9vsRrKY4pKEmwrR6iWmcq5euxJZBZUyDFkTXp41H7m
vlVrK5VfGvmIh3pnzjfnTT3dy3VUBK93QHKkkblWFbEVSIv7tNOVQXzl2c791A9zZFmvEEhVcaia
3x7kzmkonuIOxhpJkKJIY58xxnBjFa9F/hWSfeEM/HT5eIrXk0lOq4UzfJn/ALww3PceUREFFVHR
5riMkwP2xHw2y5c1/hDMQ051ZFeGRYbOjna5xRwzjSritSN5ysly15xaIqMl3SOIyqaXvWB2opXI
aJwKhu4jYtedrm2o3+TTNUQtRlQik+cTKHfybD/WlqvdCn3ahVSDf/5/nNLIqF1Hu0Bf7qprvII3
lAsN2m0rttqRjnM0yi875vcG+nI1lWIjDGXaLXSGkDYRCJLrm+PFBLYthcR3ShU8crD6hkNUNIzn
It/tRZBXPJCRXHhbpAvGObI0xsp7pHoKpX7Opmu79GJfJsG/xJI1YTTv+vqOMQxI1IU2Qh/TZE5E
mgr64wDzpTGsiKjok+GV0yt/ZAiT2MnXMFZjKiO6Fmo5bCtd874mVQlWS1i+JYtckgQ1etENWB1S
N/dT3fp8D+WoBqoHorSVoVecDdoFqN7Jel3fu1BGfIDSxiBW+4na/TbnhhVhQSFejIdTYty5qHFP
D/hi+qDSbaASyj1tc6Kl9YNeOhbsS59ohCc8rhKQ8Ru0PUIlSeJFeumhdpdUBc4VS9EnMVC1z687
5DqJ/Zov2n1AJxgUjOw3UP3SCriuyshqBsqwG83sWvBBK2ejuFdXWDPJuqd0osHaM2+lNlLyz56p
i5vjsXHrhvlnzRT2NbZRvKYGN/LD/GiJccjz2eQKmFxyzB32x6zZIuwjXzv2URN33S8gRh948ESR
GXlh3cd79Pn0bb5suJ8589Py1N806Ltjuh8myG8XUQNzSk5hshoMsQXcLXIiR7sO6vT92nxIxtuz
mxydo9dJR8c9YhisVsYEIzCPmg8hI9MxqnCOI/m2SD6S175sYYgnXYlIDm823jRSNiyJQ2ykhQ0j
LaTeCwbBDt8MfOwntEwbfMk1cNsfJ8VDtsI6BdHarjVjWiFdsR2V69uZKMnjTHfcq7HsYiMlte5k
RlpO8h0KrEdoYgoaWNh+2gKjVlx2yc5tjCt5PdM7omacE0bbHi4U4exKcKEMPj410JqOEPmWnRgR
3DGPYRvF+nwtyYrHisBo0tHORrDRRyVC1sVGS2OlmYw4xVkcb7FgRChSmnC+ujGWWMIhhn+PIGQU
ph5A47JNg7uV9i2SxeyPLK0yrttl+y7J05oG00xrnyRCOgo0YS2BRR1jSxyBLCj72RQMZU2LXikd
jkk5ijlE8WTBsByWFkCC2xsVI+ruEXO6BcsrPbK+zfHLHkDMyZMaBkuY47nriY35084bMkHG8Vsx
veriDbIjSBsBf8Hqn7X0hxDDZGEYUzbu0DmcvKH2rripqOw8QinBJH3hR8n2v3IFmI41dHXLOyaN
kOzcEobIJQ2lq1rfMd3aq4GQcuyGxs+a45KqWgJFtaCMAzuS1BWDMKzjoO+MM+V0x0SQK5jyAfVB
gJczASRUcwAFPbxSMtHMcWptliKy2iEQtvGEljP75ai77DjXUfhOnuM+pvWgb9WgOyZbAaMst3cr
NQC7dheDcOTIcRy9PzTThRX/AKiicLmUOQ6IVAkh6jhsFb3MWYNF2JT3MaK2VqSIVk57SGqZo4hW
6lh5dTAzMgTViFj6liuEXUEHjZWrpT6vUbI7F1NDyffNkDBMcI0TUwkDY3SGb3l51WoWRlmalCRJ
UhxnwZnivm6jHNC/5rZTYj26qh7XM8E5oHoItfqeMEE+/iyWNdxJV6iZExdUQyNn3jDMrrBIpP1T
FK2RqGO5j5fOTE1FEGKTqAJGklOeSt1AyPi6khZNvGHGOW5hYmphNDY3LSse7ku3T89F6P8AnH4f
5T2yMdWOHdsQSTW981+14gyuJXXbXCh3TQNXUA8fqIXFtz9yfaeSsKZ42TbfymxZKAJJu+4x71eq
/wBD89d8H+18S/WKKTqBZDXk5vg2XhY7U7nNlS1lPAfskTUbmtl3D5Sb7uiXaxENfvM0p+bo1k6P
jdSvRJF0Q2RbJ0Zf1QTF1GVUkWj5GR7kkZP1GTJVo+RiryWHYvh47URXYSe57xX5RtdqEzkNNcbB
SXje6+LwPLcZQyXBcmoD7LqEqpJmOkYIvbcO/ONprZ50ZIVjnWxiNI5VVrlTAWxAJIsyyG8/eNcG
jYa6OVCGcRQTHgX68duGuTFQj1di9EXbI9mSOn1w70NIUrgyXBcl5I2kzXnxHqjg25hIW2KRHv5O
jzix1ddSHIc7iYKQ4asuzNR9wd6Nmva9LoyYt2dcJaFKgpxA59ZNhbIpcUqqoZ5AYWxIZFfvgZLw
qtsZyPJyVH8VS1K1pJTyYGU4SpaHz6qdMLPeXBTyDz6odcJKeXByXCX6kbPPemEMpMDJeHFsCPRX
qqoXjjbAuz5CvXng5RBtJLc/HO9AjOEqziLhCq5UdxXyi46S9yOXfBncxFmPXHu54x6szySbOc5c
RcaVzc773Y5+695yZ3CLjjOXFdncxSb5y3xrts5rtz3z4zuOx3viZu5uc1VFX3TP3Yiu3VFxOWxO
aYirictleubquNG92cXpjl90XNldiuVuIiuztExWETFVd16sb79h+ORUxPdUA92OY4efOMG52Ojv
bi+yom+JGJhWq12NC96OGQfRg1djwkTF+Gt3xsUmzt+W/u0BH44D2ZvjBOfjoxWZ7pjU5L4r9iNV
vQcUhEeIg8+cExX46ORmKu2N5OVscitfyauNCR2PC9Mc5cY5caN7sc1zMb+7FAXHbp61XN8f/d8Y
7JHzg2quMgEexYzmv8B3Ht7P+nuVooTyZ9KfiVS54DuRYLhIGOpFNBcxox8nkr3o17OOLvnx6d8+
Ou/VMhw3Hx1O9ELHUSijqVR1D1bIgOEqMVXx6ohmnqXCaQez4cJx1WkdseG4ajjq9wah7myq5wM7
bldFq3HQ1Q5iFG5josN0h30R3GRDcJRhV7g0znNkVSgxR7LCrXyMLSq1pgKNYsZ5nNpXubKguAqD
VXgp3PbJqlFhBq3IVa4+OpF4yIyjdGiuO5lG/aZXODiMVXRqVSNk07hMIJWLCrHyXfQlRJUJwlAB
xniofaZWOFhGKzFxekCA+Vn0JEbKgOC8QFIQFBuybUOCnaVFhU6nQ1HwaeOolhQHSHJp9EZNrnAw
QXEdGoebJlR22vYrVr6hZDCUScZcV8d0KCSW9NPtRJlW4OMCryRKHmyXSdtDBUboFQsjCafajZkN
8d0OG6S4enGI2wqHBxoXOWFRdxkjT7WtPFUL6+oWVi6fZxn1yxXRYTpLw6dHxsqVQ4gVcSvoWlbI
0+zYkR4zV9E17PokZcm6f4MrqbynpRxUQ+n2PHNhOiu/OfORwqZ0KiYo5+n0awguJaun7+E0+N7b
GudFfXQXSniox9u1pPHaMKvJXUje1KoWqyNTq+QOoANj6QRMl0zhnjUwmD+kxnJaUXba9nF3x1gw
Vkvj6fYkeZX8ZkCoawaVsfazoU7cGAppAacSDtaJvbIJWkqahTrYUo2BisR00FUBI/ixNz04XDSu
V00NeIQroQ2trI3feGvCEQxAct9SoJIEJ0h8OkYgb+GkY9PW9/FjRQJ4QJeXdb4heg2clqqvuuHE
itHcUScIkBxSwq4MdkyoBKFJrnxzVdQjWeFENlvSuA+qqe+oocUTbajaQcWE4hodaOMM9bGlBl1p
I8itqUa3xoZcvKbsvq6pTYyNGCyzpRmBFrnPPBrhRhPr48sU2qJGkVlTxb2ob0vaLsEqqtTqKNFA
K1pAyYgK5zpEGuHHEsGLNZNq3xJFZT8ESPELl7SdstZVuOoo8YDLeiEePDguIWDAFHQlfElMta58
GREApH1dM1rNTQRiHU1ylVRRIgbd0dzfUnR2K3fHZIxEymr1lPIAcaPza+w8ZpIzatVkvisDFrFG
80lgxNC8T8GFjpMysa9kOs7Z7iI0ccLu0QDByRWdf28c3ZXdVXoidV9FfF8gsWE2KFDCK6yrEctb
VcUfICLJMNphR6j+QvCGxnCYyZU/diwmxhpJErrCvRW1tTshTiDhYzZQAVXOVxbDYAop6T6z98CA
2MJZg0LYQEI2sqm8imZFVzGTRJVK6SwDYgQSmHdaVnJa6tbHEs0bSTojTirav98kzYaN4zBnqVdL
ZFZEEGWw7rCu5ZXVvZwk1kch4jZgoVQiySqyK0RGzWSqjkYMNsQLJo3lsq5CjqapoWmmsjOeFs0F
rD7L3pt0hA8iREhNixhWLFJNgodlZUtGsmS2K5jWzgpUI6a9qQhRZrZi2lSjlg17Y4lsmjkSYbZA
66qa18qQkZAK2aM1SjpTmJDDEnIYlpVtK2BBbHESwQZiRkkir6hjTSz+K2GVJ7JdS1x+w2HHj2KF
PY1zSsrqtI7JNh45O02WCPUsSTKJ4bK+Yk5JtW15hgSGIdvylToLTsraxoGTbLw3jRk0AadqTJSp
EDW2HmJNgsQij7cXz5Pl8OcTzWwyksynfWq7s372Oc75xEyiArzyW9iOy39pad2XUh/hyZjo8i5l
MkN0sDd1mV8Zp7JsiPXiUk54u1F+sdp1V2zkummRlCply6egkfdq5lc0xCWJ2sAOq80rdLByXpvt
JGr3rIrIDYrN0eGc5B25G7wxRZ3lr/p18JuWksgzVb/Lj3UVsWXRTxdu2X+MVyhljvS9qJ3TyR/s
hQIzH5eClPcWvktyNKfDIS4NLyqhqzLuwTsU8sYTAM04dV+59LOb29R1xJS6fjvi5qhzHiz8wk3k
V8ZrYktx3TYe54UGGNsy9cUTaBxFdYRWKWeztxoBD+ZLC0satA1kSyeV86uVSxYkQaTr5XDFROKw
liBjiTBoKPDcdZhwtLDgBY2PcKZ0yq3LHDFZ5993Gioe8x9tHa4xm9uHG7qzHohYdeFrRXSGfKpU
XssisSw1ByGKi7gltgDcUo+MGH5Hkkaha6tC3tXHedMqNyCDGZ52oOQ2UqkZmp4qEZW1SBSGZrna
pZybVAb4lzClSZMmqMDF3339CZ8ZvjsTHe2SfluaVCiB1EVWDa9WOo5HdakZuXkngyj9yzY/dZKa
sNKiR3COejUGFqrc/wCE/wDdp8yuW7EnbkeznYqehc36ridNOInlWTPsRAuSRIanaAiePKCriwWb
R4zE71sPnlULtukNRxprP44I6oZ7P48ZPszI6lNXM4iCxEkW4u7lVG7BZTUVxv8AWWOvNreUWIzi
ywCpDVQuDOCd+1Zu2FG7RpLf2qn8QkTkUDP48Zmy2Qe6SpH2sen8qz9xRYvbkSGIgWbdmRG7xISb
R4bEQ1oJHkrA9px2/dmt3jijcDOT+PFT7MsCEPXJsHUCfdInv+aNNph/9dkROf8A/bRE4jnh7xKl
nFiN/k2Y+TYMdAy56btd/rLF+4Bv8eG391gFHlqQ9vHt3k2bUcyNH4yJXuJqfxixdyRPaJD/AMli
PmSoF2yGT+RPbuEMdrSl/wAIP9aQBCFr2bRY/wDsWg0etYFBlmN+7MYjo7IrWuVNwRv8EoDSHqkT
sjT+XajR7YQWjPbvVoY1swo2OERyojg2A1JKrK1AtsLBI7ZslTOdn5Z86cc3uTNuxZv+9XE/kQVT
xdRETfury02rVS44oKQTYlAVFMVyePcub39OteiSTNHkdzCrqBr1Ssru9ivZCFMsVOetjokWfekh
mHftOOucAsoo2PbHFwFaQkfLFuEH1COpJCbggJtFl8POqkRrNULsWhd9+y/0ZSbFhgUr6+AkcVha
qLKN38ewtARCx1DPZeV3YLUVXtOlsiCmzHSHDf8Auo1/h6oRfI06B3bsrQcF1bNHOXUoVa3PzB/2
Yaf9chmebX+0SF/6F2RBvr3N8mw/yWXsCEQb48j/AFYHtBJJH9Qrdkjxf9++Kg2wSDIayTZ9j+2N
AMx4nL/DgfuiyJLBWNZ8R/8A0NQF7DIRWldZO3dM9oMCWJ+N9q+D7hmSWCtKvZXMT+dqAiDyGYZ2
WX90pNoUCSJ79tq6v/wypLR2VWiKQO3m6iIgWQntOO9K0eR5kUsSK0PK7QeVmzIs3UiwZEciWAb6
K2JKxem/T8Y/o7JGN+dLr9vUjeSKmy6djvXN043cffKVfvzzdgUuV5aUglGW1Iow1Nj3Mt/8B/cm
nmqwl5+0Uj+92L0367ehOmnU2NOX7MU3I5/8Af8AXkyEGaAq+OD/AC2b+OV5eb5C/clLuAUrkdV/
jRV+zPN2S1rvtieiHtSozK+R3Xyn+5feL5C90a/xojk2sZCAJVv5Jz/kWf8AZBP3Sy3bNRd4xDbG
ju/jxXfutSdpah/PHOTvTl3DEOryyNuyJUWPKO5h4C8o8VU71w/tpVvV+F/vlr9gZ1cV/tHA5O3Y
G7BK1329QqnMvSndtLK7lHQ7lkNXaPGVFbZvUJapf2I9Ek2jt217nvNKcnFXfxXlc2RHciRYb03t
HKx1Q9cI9EPZfuHAI4hJSp2xvRY0krkPD/ZDiPTu3DnMWlc5XHenkTf3BjEe+RIciR4yo6NOc4Zq
1f4wHtSTbo5G1CucSWRO5J/dFB3HEe5Gx4b0cGwUjJVQitjCM3zbfdw6vkSRdmaoSkcjq3vmMjuM
WNXoUs+V4aPBInEkRngVc2xM09/t2HtFnKvejb9yq/0NRb9786U3Qmo1cgX786bfypH+nZuVJOl1
+3qXdE0xumWQmmc6MkKNLIaY9KcjXVqfxLwDnSh1BSM7pIRY1xKV1cR5Iksr/qMr/UjsJ5qqiQ6y
S1w7eCR0usb2QajKkg9JHK09kiuhzAkQ1AiOPat7Ecr1eWhX+JqMBCG06xQikiZKmzxrGA+LJnEm
0L4rQRCFdTCUcTU4CPkabciC1HGId+mAuA7VT28F+UyK/tmqpjJEOXUlWaAqRIsK0H59zAWY2oju
h5Ps2IQ7mz40KqLHkzpwxBqZ4zR7CleWaB6RI8W0F9Qu6/6nGqoawm2VszkpknRYdI+PMlTmRxVN
gwo7WoceUF6Qo8e2Glhaw0tA1de6E2ytR9xshs6LHpFjzJU9gAVFkMiW1OsqVGckELLhnn2kb6pH
qq18EVrbi5hkNmw4lKseXMnMigqbMRmXNI6VLivSAEFuPzLWJ9VjVMB8MGop7DMH+12nRORNSsVz
al6EhXUIxbCtXti1MvKXi9fjq7PjHfEj5b/dp+cgcms8wZY3GTXtSOAlxxNIRDirQcTzw9wUaq9x
jQBLh38emJtJs3p46ohC1wPHHe2SLj13VfR8Zv6vzXyfGLGmNmjDCaF9naNEyutUeMkNh3mkNhiD
cp3/AGmDENkRs+3RCwpqSxsgDYaxntjpCt05Ejsl4U7Yg0t/voRs0Yo44jbC2a1YdikgbIg+c+c0
A4Fv+8gBysc9kMb7fYwpKTRsjjj5Y2iItdaIVnijcWVMYBsW32kcWzWq9sNki2+9FmsljZFEFbC1
RiV1sjs8URXSZjYow3G0hismj+1GZNttnwrBsoaAGNZ9mg2QLb9zhDNkiS2Kyymd978/IDdl9VZJ
JGgAo6dPQKV1urScBSEkSGRmPuOJY0oc0XEQUsbP3rrVCJ2QLk6cgRxbbtm+3JYU7AMk2ju9Dmtm
C4jBljae1Xabo5onLOntAKJcds7CBljMYcdsq0Vx4VkyQxWhHllZccq7bZVQRMlzmxmCtnNkgmCl
teUQG2NoryVlm2QP7LUtLThlXbKLGFAVJs9gGMtHJIhzxSQlOILLSyUq1QBFRBhHlla9vKSY10cw
wGVgwCbqHtK53zjfnTqjTJMgbx3I2oWr4+RGO1gdQcC4zZp6MwgjtCjLHl7ITTzho58obg3iNUlF
ZeIvfFIb3ggwlonkecEzE7CLYTQoGpt2tc4scmS5YhMsJHeLWPRhwTwsHdSWK6BcMM15Y2Wdo1go
tm6OePaBMK1tWsb5HKTXyo3ZdaR9rp4DDq5KRS2VwIwSu+5U2/i59ShlQlnGY0FttO+swyolnCbl
xchICjmxwPHdQ25MsoRmgtkiSPrcFWuuorMtZ3kuXomVdm+GVmoYxA2lt31aZWkgahF2514JzDSe
6Wru/FcbU8VyT5zpToM90VwtTxnBs7jvoh3I+u1IMDZ1+J7DSVe6rt1h4TUkd2T5yySxZroxganj
uj2d130adeVZqJsVJupBlGWS57q24dDcbVEUjZlgskkaY4JY+qQtBY3XkNUy71eo2xUmamEVhZCv
JXW6w1PqqOds6wWSWLLULwarC0Fld+SxDqi1epEjZL1GMjDyHEcB+xK7U4ACmajjyh1914Ku1XCe
6VqQJklyXGd13xer8VcX4kpnwscyidGvEEw05Cm+vJ2PL++O9QYY1yMTl1GPHX4+K3X75tz32xZX
YfLu0MwJeBX3n2jGUqri9PjN/WnyuNVUyHZOjY/UykZJkKZwZKjUOoFEyXaOkYhdsiXDo+SL1To8
nJY05wHP1BuM8xxnDO5jg3zxNk2bpKK9ciW74qG1AQ7Xl7ix5ShX9QP4yJrzYwytUF08KSrUklFe
u8ayfGwt4UzXmV7gyXDey/I1smc4+dxUWPckC09sQ6OIqrFnPjq/UBHsNIUijMrHDvDDbJnOPiFX
eLbPBki5KTHlV+R5jwYt6R7DyXExhlaorsgmSbJ50e/fHLvnx0jSnAX62RWyJalxpOKguChSRYuP
ndyNYEBjrsr0JIUjhSVEqXJUQ01xV7i5GtyAYazcXHE3WPNeDH3JXI+QrsaVWuZbka08xxl5e4LE
oULZEKjyKuBmPC51yVUIdSK0uzm25BtNLeXO5gJ5AISzIVryb4KS4S/WDLhDqVeXFzLIw0JNeXFX
3BNJHV1oR7Xl5YCYSPiWxtiHUrgziAT6sZMW2O/CyHEx3yuIuBkPDn1M+FO4uI7ZWWBW4WU8uKvu
KWQeOnkdjn74MzmL5ZseRX4juOeYRueW/PIdv5ZM8smOkPXO6qK2S9uKZy45++NfjTvxTOXOa53C
45y7b+6OfjiLnLGZzXOauxGuz92Kjt+eNftnczub4mbERVftiOzjiv8AdFXFERcc16Y7F6JjFztv
XHNc3N8Yxz8UJkR3yxvLEjk2fui40T1R4SMQY1diRCpjo5UTZd2xyqniGTHNcmDRVXxTLj2K1cbG
K9HhKPGMUmJBLiwz4+MRiYIBCIUBGYq4j1TOe+MYpFdDKxrlVqriYKMR+FCRmfOMikfhBEFm/ujd
1bEIqK1zFYJ788M2FCVmcvT+ehOi+6SE98burgQXGwkVRq2te5phdpWQHPYKC56/SXri1K59Ncji
VpGI0Cq99c5re1+76a/gQDmYvt6fzv0+cX0hb3MBUEe2VVPBjmKjokB50JTua04FE6KBx1SmeuSo
ShVrN3AqXkSRVuEgILzvbRrsWmVqLEcjg0jyNWiXJdcoMVOOLm+b4FjiObTF7b4zkLHpXEb9DVMl
VjhKCMpnto3cZla6PnFUyHCcdZVS4LAAUxm6fdt+nVXD03aQFC4zf0+uLp72mQvHX4zfADU5AaeV
6fp3C6e7QzA7T4VUSW0lE5jJMZwlVM+ekKA+S/8AT+yTK9wMGJxHBoeQ5VQoWvYrFr6l0lCUXFsq
K6O6FBfJc3T+zZta8GNa5z4tDzZLpFY0wVG6tqnycJQ7Mlw3BWHDfIe3T6cZ9UoMYJXOiUHNkqi7
YyDUbq6rfJx1A3abBfHdDhvkvZp5nCfT9hOyqvhUPcZIoeLZAFE+uqVlY/TguM+sdFdEiukEBp1i
snUahagndyv0/wB0crTzOMqMoCIirlXR+TllTeGyLFU5Y9CJrLSEwGO33XrFAsh0KgZ252nthlAo
y1dP3sfp0b0s698MlfAdKeGhFwtaJY7QhUr4FGzjM0+nCFTOedtNHYi0gTZKpXCkRKQbGfSQLltS
dobkVq79NshQXSHh083xZVfxmwqZowsrQuW2okQcCscYoacfauNPIjHBVhKim762lKMcavFzmMqB
DH4kfebEjoOS1EJi++JkPbuxawR4t/BSLIr4DpL4tCxoL2IkSXTVffY8McCfTo8xLis8N6dEyCHv
liVQgDmVMeVHkR+xJpahFYtdFO68rfBJTQElubBjhZdUo3AhB7x4dSMIZNbHkgg0v8gniREGKJLb
PpmikiiR4ohSK6Q66pmdmnqFK5BxhDuqNpBQa0hTRoIojT1seYAEHwZzgxAxxS68j59eBYwI/dnV
9YyOFYkScOyguhSuK5wXK14xSAxY0mJqGMkeemJmmnAc+4rgoCsr3ySRoIYrDQo00FlXugnjpsSh
SNLBqKE1i1dUjYxJ1eCQavjzI1lEWHK6bejfH584vtkjNvepg+SQcEcUU4rHSoYRkiyKruSGRGCj
xiMWaVjGDEYTndtimJAa8X0nhLmxGtiv+3Lr3DkjtKvjhh8XdPnrt09sXPxt0/NABClcNkYcpGGE
QO8yDCQcdz2OW5YxrtPQke05GAW3YNR1IfImPC2OMpBSB1cJjUmzGxVh7S2SIwxGNYhjshT0lut4
7UF4zjvSmfhq0g8YFz301QjMLHa0I4qEsjtSOEE9DSLCIjhV9YgkfLYJ5ozZQpMPjKp4YmtuQN7F
OxEsJLkGIt0jFJcI90K0F2ZN+wRYJEkgvh/dbTmei0pWZDH4kn6uNBDuWkOVqOizA859fGQcbyWI
+64uV6e6ZED3jQYSRA/URtLNgocdbUta6VIbEazjNESoRZfBIoY0tsglpVoVK+vSMMtgwRZERJIo
NO1pJJ0iNjFbYCk07XSUEkQQJrTFtK1CDrK5oAmsmxylAksUSpb5EgqRGxT+eyZUNccUdIgQ2LSG
sICGHWVrQsk2SRSdlJYQVDfKkP8ABbCm+eljUtIUMRIoR2e8mdCbIFW1TBtnTvEcJEmAHUN8+TtC
DWz1m5eVreNTUq8kETBN1Em8Wkr29u0mviNmSjSFd1RfegHyOdnYB9Va9sxENLqgIkKRYujSLiSy
Q3S8b91qV0Vp7MciNWB7liZnajMtcrXDK++7zM088r8uyoDH3quHVskEJZyGMAGp8siaXCqS9M9p
kSueQ1dXsiM3R4DKn1eYxSRYsaWOSbh4lfFa1tnMIyRAcsqLfRmxpdHNF2rjbxK1v/YyGK+LMr5n
fMCUJa6r8zE01HyTpdmxYbwHraRDJFjeKDWLf5FBPEFwjNkx9UJ/M029PF1HVlll0/GfFTVrmvTb
FxM0/GV5pzF8VluWvMb+dNqwKODcvLXzLKzSyBpaIo81GNyx23z+FREUk0wt4a2BK01NLbIPewHT
G0MFYLtUH2FGlSpyV9U4J5ap2YYGpCnd98+B96HDAxlhqFxUZp9CNLq1qMA2xO9tPFcpJcpGRKeN
3J7B/wAQ0k9bJYBbeWCji8C6ejObbVbq6ZR7eFPpxWC2NY6DIrq1Tkr6oYGW3+rpUaKuouaDoWvY
7VwEUFXTc0gwRxn6k/a+sIha6woivnxEUETUbkdPxfR+cd0XbJS4nzpUW6Xq9sTnLzopXLGgaqXB
kCKqcrpZR9wMkPYbWTPIkOJwGNrCrYN+zN9j0Jd5FkNFiSm/vVPUq9fjN+jfddMg2yeL7cuUoFr0
78uO3+Lb/YKYyyX0YkaO5H+2TLc7NOgTlLZzBLMsctHIUjZURpnRBIBt2928SKWU+KBkQdlZd8kC
vYIBJAGOlNCQVbXMI7h28XdQ8HMnFZ3QghsESUv7A/68qPyfCTYFz9uRR2Lilt1VY1a7ty+6wo3V
4XrOp0G0nIT66A+YQTkhBExs+QkVBt7COy6gIJF5K+nq3IkyWgwx9j2Edn2Lr7JpUhSYvSo/3Nt4
joiOIP8A1orcsAIYtUHtY5n357N2QwduRLT9n/8AQLDaQ8VNo8ZE5WYEe+oD2lIz705n2gx+MiR+
4Qm7R5MVCEhN2jxERS2Y+TqoSCfIT7s5N44YjWmK3+MBv2ZkdCErm8YwG/yLNvcdWg4HmJ++Un8Z
I7UJt/Hhp/HlhQhatmwWJ/Ks28m14UGaxYj2gjMQQB/vtg8hVDO3HmK1HrXjlMua/wAYi4mN/u0y
9qrM4oK1cjD1pv5UNUWNqBzd+8vd025Fbcq3sSScXade1xTqnYtyo2VpxrslmYPIj2PzUTHq2tq1
K96shglWPlSq6M1sSbdkhSGXzTCqewaQfgTBs4imw0WY5ewJk+O8kxm4K/2jSODpdZt2tUp/K09/
mt/9dpuxMDqUHbHaxTPnV7JMajiNZHI393JGoaGOTNlvbXR62QsmNqz/ADA/y1H/AJ+p/wDeoAKg
LG3FXOrJY5+aoCoX9dOTUGaY/jHtpLTngH7JoJ0LF1NLbya7ZdNzEMK/k+MJ7t36el9uRIftGtpT
ZJ9NReSW1v8AS2VVj9RXVQNmV1h4T6/UPnPsI/IcRu1b5Yw2kBNosL9067MgUrSMNK1m7+JT1/lF
4DrgWdosh9DKUU5xV8a7meWfSacs1U9RCi28iK6ZaPslqPaCkx4rixijlBrobWQvNc+wvPaHpVM1
AZohwCtMe2Chy2CeFC07JdIJqH954IEDXytSmBYCVJUS+AkWwXNui9Nujvbo74k/CJmkl2bqFNwE
b+/T0Z3cG5Gsugd1lS3+UZ/CNNl99tRHcOROcrQVdnuWY7mGw/zULFbIsF/jTP8AK7Pzvm/Xb1J7
Lpk69y0erQTnq8teZRnjvV0a+K5xUdxdpsziC1CRzGld+7T0hUkzl2jTSK4+nht8e4mEjrUHfIFZ
RO+WPDbDHZz98jhepxonh2ntIaaTlfa+Lg7sRHMKjwOIj5kxe0GJYkJLO3cAP8U2T2iwV3Fd+5KH
dsq0/wBZznMIk6WNsGzOSTIRHxZId5kKG0Ma3mqmab+J0lAYtw3ezsFK2pB5E0jEjx7Ka4roZlbI
iOc+LfEd3Xri5+ar2mN2dFUzkOL2jxlTazeo3VROWK9vesV+zXFUpJTv2Iu4JBXDPFXaNGeiutlV
q1CqRSO2JYe4ob3ENKcjQhcix5LnNPA/bFjEb37fllS5XZKe1CS15AC4ikI9Ejxno4M1zmHrl4xg
Easm4VUFUvVTSiN5yF5gG4iyCORsaGRrxWDSMkVa9sCHb5dtu4dXzcS7OjW/Xu3lJaeYS4LwFUP3
i6hM9pqFVWPqdvu5OiZp3l5diqpFsH7kiovcqf8AQ1GrkMnvmkeW+pt+wVfek/2pafxLBVQ+lnJ2
dSo7bS/PLEPfe4PiBnFlzS/SCCWD/pXYCOlJSEI1hz1z4t1JV0IjnxDGf9QsfuRoQy+cZyePXSWv
DaQCrLr2+PF1EXyZNBFI0tu1XRVjP8p1AR4YEQ4pe6JDr3J2L3zFmCjSzDqNxSL8LzxqNVSLqoTu
7CilM6qYrYGpYxXS9POTxdTQiyjacG6OzVrke1V6JmngO7thv4cwajPDEpS1g1ZA1QBfMam7tLAV
jtUjeWMnzRAc6TIavgz2qKRpcqcdSwSS2acjPiuvWpIyVpd7WVNYeKewNwj09gyRGnUjiS+8OBHg
XI1s7et+piqon05upp7ZLdJt9tVewFVXZRx3OlcOUOxE4EnSxWpmpoJJMeDQOItpWfTj1CI6DIhE
+ryio0NeVCQPGeK0tG+TX0Fh4Uu0r0tA1sb6eE1kMxrVvkRKBFjvvw7vryIWusKsr7iH9qFqV6Fs
l67eh+2fj8yfhFyimeO45WzWT4ahPUBQIJ1wgTMIkqNHidqUZvKOKtRSdtoXWBEWNALxnGInhyF5
y6uJwZa2SDGYnJy/0Pn0JmmB7LYIjwz2dstWLuyo6Ike+D78eT6APaFdsQjJScX6cFyLJ2eCzFsW
glI1kuKkvIgmw2tkNfIkM7jB1SKWRCEFIklpQnrWGISGIIp6oj6tndPHa3xzq0MtzkOEFawRJspo
wQrVHufFGZ0iU2OOQfzJNVCaNZTWlHIhDGYcAZRBrRsLNkNZH587AB08S0ejjUcrsOkMZLaKsCJb
RrGpSPRJtiZjo8tU5VYu7IjOa2PfsbzJi5+QG7b6e0QrewPlNsEC2Hcfe4ilseccdki34mjTWTRo
0IMsbVEystebVGJVlz2gZGt9pDXDkscRkds61XuQpzZYlYEWWVpxSpteSfaekuagGx7btyxnHIG4
rANm2iuNBsmyWL2mZYWfbSrt9sR4CpNmNAMdu5kmPLHKY8owJZWrnurLRslu4EyyteKVdqo3NKEq
S5jY7PqislQ545YyHENLWz7yo7k6hKIbbEjHCq7BjMe0J8QrIrbqb3nu66bcNmSpIiAuGN7lRw70
aQxkfUXEmIqd2iKxg7UrCBnMRhtNuYjzSWKK6Rqk0/ZJFxTsMjTCjY62Ty/LGZvMLFsZYkDUWqNx
xhuyXOEIM+QhS1BWtKCwH27WU3uwrZhxqQDcs7ViDh2bo5o1mIwbW2bxHI3NAlgQT7KORtuYLMrL
xjhunRlyyuGIyquu0v1GK/DW4BjS2ck8dzHMFboQCXlgCWDT86OJG3UNuTbaEVsW4bDkfW4L8PeR
BpZzllOXonzR2keJhNRw3sujikHrJKRii1LEGy7tATWMdxfV6giR48/UEM4jrualtgwiP1XDey4k
glFr7J0R4tVRHMLqeKxZVm4p4WqBNG7U8NctbrymwrB8YotVx+zZ3Pl4wqtdXaoYFszUjTsOZSPq
7VIGXF+2eLfbKa2SA79YgVtvNZPdXz3xCj1cLtH1YBzbCesw1VqhsQT9YgVLG9WW2ru1grK1QGTg
NUdscyYh5NdqbxUmakYdiHVCwNVtjjkaka90nUg5IKu+dWqutI6rL1Gww5Be4vzi4nROm2ETN8cu
SffNsERWLX3ShSbYpKcG/wCwA0vvGjXfYGK64v8A1KzE1GPYl/zdJvUIMMjgR97uFC/e+vdsB5bj
udir6Pn0KuJ1TK638FCaoUiSZPkuhyPHI3UytSdarLxj+L42oVjNlX7jo9/NYNj4eO1K4jZUpx1i
y3R3M1EqNLfvc0Vi5j26kcjU1M7JF446RbV8Vf1Q7D3ZJGPdusWWsd6ajfwkWrpOAu3gz9RquSrN
58GdzFHeuEkmxU+DP23h1C8Y01GRuSbJTpGuCAz9Rvdku1edGSFa5LojRkkKVwyqxwNQFE12oCES
XMU6hkKFS27yDc9XZGkqBzNQERsqzdJx3uq9EXAyHBVL8nbkTnHVCLkW2eBJFo4qPKqrFsXx1W8I
TDHV7hSXDcy8I1h5zzZ3V3jWzwIa3cZHm5YCc8GOunvQ8hSuYdRuDclRsiwcXO4u8azfHwtuQyOJ
ycGa6MrrwioeUpVaZWqO3KJsmep05+8axfGQluQrSF3wMlw3/Vy8SSHFVC8VZbFG01i8+KTdQT3x
cfakK15VdnLI9gUDX25noyW5jvrMjclsUmFJzxem+RpjwY63O5ClUmMerVSzM1DTnFzl7jnFCj7E
r0c7lgTPEq2JtnnV+NfxVLAuLOIud9Vd5hm55pdlkuciHVF8wmPlPXFXfBuVuIciJ33LncVM7z8U
iqm7t2ue1XPdnPGOcq83Zy5KjH591VXdMbyXGtPjuSZxc7EYbdRkxyqmbpivzuZy3XtkXHJwxXdP
zg2udnjmTFxqY2IVWkG5nRgXEV0cjEcnuNivV0Q2Pa5MRF3bFK/HheLoKO8uPinHi+2NYr18E6oZ
ijVExkMr0KF4k+cGB5EdCO1NsENz1WDI2e1zVxsMz2lCUWfKgjvfhIZm4u+CY57vp5+JGPEqIq42
CZ+FjkEmAjuKhYR0xVVMY1XqsEyIVrhrv6E9D8VMVMke3Rqb5FgvLh4SgUda4rZEdRKCA8zG1zlc
yldn0d2ErnMV9S/bxlR61T+28XB7K1z2HjqNXp6F6p7euJEcdWUb1STXuCqBVXR6Z72yKlwkINWr
DrnSEdRuY2THUSxoqnelI7aXAUOIJVdFqHEaancxCjViw698jPob9pEVwcABxnjo1ckqtcDFGqrD
pnlSRSuGhgqNYUB8lVof2yYbgqILikFQKqSqpwMeJWrCqHHaamUbThVjocJ8l30D9sqAoMYBxHx6
JXNmVLhY8TmugVL5CFo1aw0Vw1h0rjNTT6JkmkUTYtY85GaewtGiJKhuC5U6jRXLCo+8yXSKNCDV
joNW+Vj9PcWyobwLHA6Q8VB9ubVujojV5Q6RTNkUasQFYUxx6dYqEoGNSTWkY+Lp7m39PiydTdpI
0FxyC06zjPqXBRAuc+Fp/uNk0PBo4DnSBabBx/TwOUvT4xjKFWngUnfabT7OMyIsd9dWvlOTTwuN
lWOjZ8Zv7b5DhPkPBp4bUn0Xab4y9yBQoVsnTrHMdAUUqNp4RRWld4ub5vldXulvJp5jI8oPaL02
yLGU74dANo52nU4kjKMtXSIdDafE5tjXLEJW1qynjoxcLWj7GAApSwKNnbnaeR44FG9TpVRxISkC
VJFMopMWjYJiVsciW9AoWvTi7N9823yvrnSXsoGsilrf50SoYIKV4XJbUHEdfWqZ4akaDuKHZnZX
nTUaly2p2jBUBQsn6SMY/HBk6OJ7KunaueMEeFpwyh1dS1s08SOBoYsY2aiqhBjuTbOW2J+7KysU
7o0EIW2tGOQOXHdGIvt0ELuOqKZNvDibXtFwWsq3FcCICOOxpBSQpWP79bVMjsWHGlNtKV8c9RUY
0MVuX1EiMrat5yAiAiMnVgZsb6SRkmuqxxmpHhycuqUsc1NS75/FGy+0+wjKyrecgYseIyVXAs4z
qsg5dbVCii/jSFuaZwSU9RuiOiDS9o2nDX1TykCAEMZYMewikqiBmV9YyMMTIko9zRujmpafljlj
jbf0LCBqKh5yDjgh5IgAs4bqt45cKsHDE1sWWW4pXAPS1Hsj4yN1JRNKx7OD83xc267Y9ejsk/GV
kTyDxa1kcF0YfcqBsIGxq1eSDBaITisbO7bOyKQNzyNG4iQmvDIqeMpYjUiz28ZtYQZWWdYjkki4
OXoqf0gM7hausQIlljG6bCaccGo5EfwiNY0c0RqnlKjw2RBpIYZ1lV7pWVSCa+UIL5UNJQYVQjiv
cyG1ijlsk1O8oENsQDZA3usq7dtbVIPCSRhU8ZsoUapR0hyMisGRsps6r5GjQWxQtljcS1ru4yrq
2sQ0hgXOC2WAdRzmKxsNgijmZY1W5IUBsQaSx850BCMrKlrcMdoM7TZgvo6PlqJsMcc7JS2FejXD
mMEJLdHHcJCxxEZFfJtmjWsMk1l9GRqlbsq585Sh7svsoITpTHNnjR0mpiNbGeZjCXXByaaiI9Tu
bHyc5hgwwISwQKCCspj0rwNUlifxkrD+StgNgHPseI4ln3jzI6Ej19YwLSzEAV4GyhR6hnkmd4rI
pmzW2EZIRVuWNHFt+7IkbdgwudjGjoOOs5u9urSP05G3DKk9h9oVhBgoySnfpU2xqZ0daSvawEuZ
4rgNSaFKhPMPtDFXzfNW5go1tG5Sxrqq8hsuA+K6vr1lPq4LI7JiIsa3bxkL0TNPg5yZbOwFLBrm
y296ZVxkZCPM8Y12dsjNLRVfliZ0RJloM4KoCvsJA+1FHbJyruBsvFkI7Tylfl0VgnGvFUdUpyOt
pDWgFRJOJ+koyZM0r22Q615D1kFsRr1RwXK1LaxbzjQQTRyZStdGr4jWhspxRnhr5US3E2HYU8tn
bu0Txadv/ZTmq+MarsEe5JMd9K9r4NxAlPlVjHCiXk9Yc09uSW3Toysffr3gV+n2vRdPxVyy072W
UcVrYt4U3k0znFBq2M0J8/NOxHS+w0MJhJL53HvQayM1FvyF79Cr3tWINZl0nZDSLIY+zjNXBCay
EVsl1gH7sCtA3vag7nLTqPTDhZ5F4ijFTodpbQLXoAaNgGbILPjfcra0TEl6g7qrptjmLIjtce8Y
rQU7DjLNE1zIo2sr5Yjms4n766CBnmaiQm2mxvGSUJqnuW7BqmFaSeJvCIJrK6SEprSMncrYAm+Z
qPuEzTwnjJIA3vX27RUzCMWwGxyRmolY+MR9qH7tZqFrW2/rf747FyTn50uz7tp9qPLVVPRS1Rww
NKlk/sBCRxbQSbxZMZB5GnK6YEnECKwrpTOIrVNpFUR3mGZvDsl2M7p85v8A0apP5rGp4h4iuPHZ
/GiIm9mNxHVA+3jhp5Fin2ogFZJOn2mpsCXHV5YibBjs4usx9x1SPg4zOMian2AAVsgrdwCb9mZH
7r68fEIGJ3bQXcWsEoiHYjiSE+w0HE6t5AAz7c6N3H1reIWNRDWTOaVwe0SWzdxW/YWLsdqbxo6c
WTwdx1SzgJG/fs28210ftSLRv2mN5SokMCY79oLNXeTBjDK2GNoW6gdhvlffET302JvMjE7FmZQk
i/fk17G9i9REU51JlAJEHaMaoJR1Y+jajpD2J4tm7slojuK+UNhMjMRi6gX7UB3IsQI0dK37Ub/B
Ijo4sBuwAt+9Ys5LWiQZL9NwOa4r6qu7CTpyDDXK0sobUSNcu4FQndkUjUUN4iduIRTyEjoAa2QW
vlHGUVY3+LMjo8tUzgIafyLQaOyBHRki7TeNp7/CeS1C2VY2SOmr2CY4TUeZm8e+jcCr0YvvplW8
pm3btS8T1hUWVDVFj6hc3fvbl065O1cuTsyjKj9OERz5Kp2Lcmx9Ob8JRGsWG9jl1KJ21VXc8K9k
MUiwWZMgR0HGn3joh2Xw5AKnsEMTg/GM4glRUdPc7tBHOjmfNYvag+0MvbdIr/8AW1Qn8vTDlce9
/wBaMfxpTNSR3NBZxjksq0ZwU8dQx5VmCO6MRsqPqQSjkVNYshXqOAJlis2exjRg+FkHEo6xqePO
IjbGq+NYN2Njcpf9s/8AoxjD7g/aHX/FiRBz6lUVzv8AcvXINkIzCssvhE2gR5TFkxvavr/Ylwdg
JVQ5CzS/7N69Bhr5LJAZ/wDaJu8CPLZ5cRNq6uT+RcyWRjVRWlmH9j3j+Aq+UyRFm/4wp/1Y7Fjb
CL/oVv8AvX0lsZ9ORppMlPuXr+DayW2RFm/2BT/qQzmJZRP9CB/tXUlI5KkyGnSf8t6vbZVymyIM
3ZUAn/VBnCS1D7VuoV5W/o26vzfpK6aWd960948tqoSjjuKaMvaHaj7owi4WA3bRpc1XLBjObLIv
GPFse3KKTuR7ld5NUxfJX/TtP87sXp8+nbNuiZW/7YX7xSyuB4z/AOPGciLZk7S1ROalX785324s
jmeS77Il5Blm4Eif4I67Os39tKt6ucZfvSl+yEyvOT/CB32Jx+2aD7iCuxLZ/BKwvdQyojzr9hpV
8rfYEdycbQygdXLyGxfvWS7JXE7jpKpuX3D3F8hnsCOuWROD6x24+Sdye77dcRSPs3IoDie0sacd
rwrzh2YV7rJMiO6ikukCv2pxMn7tvdM0+ZUmyFVI1o5XFCRWlqXq+HqIi7qv7tKmVcuCcAyn7kpy
PSS538S2IvkaZbyHcnUGUUp0jL4fNrophEq55nSiNRQhVO3Ne4ciEuwQETyLbfhVqrn3707VLH7x
5jfHDYSlI6rIvlCVVi3RF7vL306RyxdQuVEpvaZL/wBaexzzhjS1SoInh2ivHIqd2x2Gakq13eKs
5OLdFa4ND/gtvaYic4RbLwixL1ClK/8AjXkjmV+bY1M02q+VYL/GnP3PE379f/paic7u/OaTVeGp
N+y5V5UHLzJvtGn79/TLU8TU7X5phqoywAkkpQJDjyTSJ5A1BAviqnh3ISvkNpFeMUwtYSPeSSvi
vcSH3XfU7NvOPVhI2ZMVEjwDNeCyhF8yJ9iJqEnkydPRSCLdscSM2G9Tk069g6uIdkkzto9eqOjX
8UxJ1Q3tQtWfuNpgaeNqkijylf8Ayz/uhOjz1O+uKwVFPa4F3VPlHrk8GPqeWkgi9Kw3ZPHltmRE
o3jnklNjx6izG517TOnHrRfThPthJNsRJaRqusWHlraDGkGayTFdQuZNJLZCi1VwJ5rirWwWsF9N
FIuBeVNalrErqrwXW1sIWVdgyTHJQKOYWUyHEq7oayrqo+o5Xh+mBk3YvIPxtYlfTeAW2uRiypsW
SopqBHTDSm18SsuxLOuKlLRteFKwEq6H5J3MtokCnSvJa3QgJTWjJUU1F/JlSWV0esvBvlW1R9Tb
BZ9OFIvROlSHstolfU/Ty2l2MWVFiyREJQtSVNlMrotkZJMjqnX2x/x8KuSM/NPK8YjJTZgLaL2n
0UdBjsbVIzospJIDRk8safxvpqPM4DAq8iLEcVPqISp4dq5Fk00LZLKybFDJP3ir0X3xP6H5jk7Z
Ku0aUaw2vfKmtihi2/3lRsxrEbCZKukQ0aUksYYrArZWaCSvtkeixGFJKlNjDj3O5v2zRtRkRsu1
+7FntlDZHYNbCzQSQLXlixmHU8psVjbj7zHtmDaJkZsy04vgz2yWNjDY+wnoFsC12c8TJKEkNiid
b7HCdkwbWjipPteL4Fmhm9kaOnWKBbCufuuEOVhDsitNcbGjyGzBtCOLlhYJkMLJIvpAEI4zQgE9
kg5awLsiMFEbeyUchPdy9NPgYj3va+PcDRCwhdyVXOYwF+1r0VPu6fYwTLJGODMZsSgC1ScmOBcs
b3NPzEGp2CkNjCFEWwmt5jAEgxwYwiT5bWCg2qI5ey/JMtoGDtuEoR2SmEIwGW9j3V0+dGFtpDFD
IdyfSsYhxGH2NRI3lEYimqCCGG64EYM3jyY81hg+NHVZ3bYKutUGTvBIkiY0DPq6+VEmsktIYQ22
1n3c05MZ2DKFXTJ7BBsJHdLQuGhFlj7N61vJ3Rq++nCNHkmSNw7lre7TqxJAJTGg1BxI0SbGpDsY
K1OwgZiI0umntw0prhXSN7unbRAYsoZs77AIlo1Z75LC43ttWyljYKqtmua4giZNmCEKxKhZFGRE
kCnDQdnKaw8K1bIEpAsy1t29uBbuCYNmN4re5aiCk8pESWNrSWAXpbSR8q66GUPlgy2uGoylue21
bGI/JNuEQrOWsp9DbjjAv7BkskcrgkrdQMcJ1rDYllfNUMWc6LIi6gjvDbXiEGUnJfyqe7PbKu5W
Iq6liOZaW6yXRZjgkh6mCorO/QjFOqvp9QpHSVqIDmy5SyCV1o6IR+qI3C1tvNcCQ4ToOqBsDYag
Qw1Mqvqr/wALJGqREbKmKd0GwdFeurAOFZWz5Tgn7b4Oq2AHY6i8obzKrqq+WvWRqphmyZTpD4dg
6I9NXjcCztnTHDMo3wdU+MKw1F5Qu4vKqvXV7j6saVJUtxnw574rv1g1wrK0dNcM3B1fq4kUU7Uj
prFJu+rvXV6ytVtM2TIUroVg+I5dXo8FjavmvcuLie/p9sfi474kf2r8sdssG3WIk+3ZNSHdpGbO
nLKfCufFb9a5v/UzUz9SNXDXvdc6/wDtd5VkfXlYEhu4UN344pc58p7l6L0Xrtm2LidUXI8l4VZq
FzGyLB8lVKqLFvHxklXb5COKu8SzfHwuonkQ0xTODJcNwtRKNJVoSTndXeLdPjZJvHHRxlcsae6M
q6he5kiY4yjO5jg37hJJs3GTurvGuHxsNeqdCmVyx5zgO/UL1bJmuMrDK1wL14Ek2rjI4u6xbZ8b
DXalQx1IoJbgObfv4ypqmxp1Yse7eJJFq4yONvkW1fHx968jSyHPdHtnRs/Uy4W5UzRT3DczULmt
JqFzkkTFOrnb4ufGRLF0ZU1ETjKl+RgjqFwb97Wyrd0hFf7xbkkZH37zIYykdFnPjKmoycZc1ZGC
O8TxX5GMW9c7JUtxnRbokfP1E9ck2TzJ3tlFdvayVYPOiF94lq+NhLghkebnkeSoHmtiHa5++R5L
o6pqEqZLnukI0nF0e7KJp7ohmuNusWyIDE1AVMkWZD4rsDclEwli8yKTdY9i8CFtylx5VdkSxJFz
6+TJFkQ+OfvgZbo7kvJG0iW4yuXfomRpr4+fWDqhZClcIyjd9Wk4eaQ+b4OwMFrrOQ9HP3UEh4MW
zOqPO5+DM5ipZSW59QO5EkP5LPMmfUzY+aR+NO5F8wyYSU9ycuWMI5ipKLjpDn40j8cc+zirnJc5
kwhlVE+WdxEcYmOMrsa5c3euKRUxHLmzkVznJi++IMhEcx7M3xiOfnaM3FcuN98WOXYnJuL1bghu
djo5G4u6Ym7sSLIc17Xj6DjmKj45xou+CY56ugSGITkzGJyxIRnNKJ4c29xxSEwkUwsXBBcTHVx2
Nfu1WN3X6fIehY5QJ84CGUqEgHFnwoRKRVrJDWlRzMaiqraw5GGjFD0HCMbCV5xp8KILjYtbIRCM
INzGKqtrTOQwCBxPfAwSFw0A4kX3wFcQqfST5IiEB0+ei+knRckf2r7435hQnHyVXLHbFrVkNkwX
AyJAdIT6arHso1dn0ZcLUuZi1C8SxFC4dQ8jDxVE6PWqVsiC4WObi9fz139UWO4zhUiubKrVDijc
r4lQ8zTUzhNMBzFhV75C/QlRsqEocCBxXio3qkuqeFVEu8KoeZpqVRtOFwlhwHyVSkVEmQXCwUdx
HBpHOZLqVBijcjoNS4yFonNaeK4SxILpD/oW6Sq1wMYFXvj0Tnjl1DgtIFzVg1DpCGoeDZEVROhw
3yXpQ/tl1jhKgVe+LQOeyTTqFCiUawKp8rCUKtZKjOCsOI6Q9NPftm1igxBOesOhcQcmkUSHCo1V
OsSK6U8enURs2pUOdtecOic9sqj4tkAUbq2qfLx2nmtbNgvjuiRXyHj0+nCfUODnadyhUPeGeh4M
khcHK6odLz9Pt2mQXx3RIbpRG6dY1k6mcJiCVSQaBCsk0KNbIiuCSup3y8dp4aMn1jgLFhkkvBp4
aMsKTsogHc4NApWn0+xGS4bgPixnyHh063tWMTxiQobpbg6dDxsKPtt8de7W0HNkiga5syE6MSqp
3TM/T4ONnUrFyHDWUWJQBa2yoFY0wnCXo1FXKqodJxKAKjtqVwHQ4D5BItAFjLHTiKxYrkLVUacT
UASJZ1roJqqrWQqUoFS5pFAsGE+S+JTDYOx06jhuhvaeqpEehqIBWWtW+EWpqe+raYfG5oe1kSue
UkKnGIdhQMeEkN7D09Lyx9KN6XFOSMarq1Mo6sTR3dAnGJAcY0GoYIc2gGYM2G+KWpqXyH/Q2JGs
AdqRVVCmcKuC1lzQo5kSuIQ1dVDAOXTAkCl1RI8mopuKJXxzZfUbgrU06mUUIAR21GMoZAXRydAB
UrqakaieLEfl9Q9vKenUzhR48dltSMkxY9YV0iBXDijdCiyx2dOWLLpqVqNcOK5dQ0WU1Q8zmR40
ZljTgnwxVT0lQq0MZjQxZrbakJGkU9Nxb/EXNRUDX5T1LjOaIERk2rFYRBVBPNhQBw2NHFlrc0T4
simpkGxSxkzUNH3h1NO8j29iA2XABZQ2VBPOhQWQgsbHnOu6N8UtRU8B96PmoKRCsp6d5XJ2IjZl
eGzggpXtmRYY4Q2JHsMn0PhzYCAjRR30M8mdWjnwZgvHlerlj/dVbjvmQnsvzBB3z19Y2ODUEgSM
0/wcGyru8lZXIBtg9g5AGMcF0gbCncwiR4rSCsqhHPjQ2oC+ajD00ka5OrUKObG7T1TF9adF6MTd
9NUtax0kQFPGbKFGp+UlWMijG5ktJ9TyJDgMih8sbn2Nej2VtSiYU4wY8DZgh1G8rgyIMZhycn1S
K+HAbGF5bN51e0jK2pa1TGZGXtslh+jcpaibDYE7JWWVZyWvrmxR+WxHzoSHHV06NcYrQY1jZo31
HKZ47YggSWSFsqtHZArGxhPksY+TCbIFXVCKUpEj4xGzRmpkfKbGbEEKQwzrSpRyVtY2OIkpo3SY
bZIoNO1DFckfAcJjbqAgnEbsq4FnN1RWtCB0xgHHjNkgh0yeQdyRWge2aybTI84IqRRMlteSwrkK
2vqmRmllNA58ZskMemTyDuSMyKZJbZlO15hRUjCbNa4thXIZlbVtAw8xsZ7hJKCOnZ5RtojYh2zE
n1DSvBESOIc5qlnV7TirapgUlyUjKg0lhHUM8ou0UcOUkvLuubwoABYjRp2tRs/kUNe1oZUtIeC2
mCbUs8syJDFBmJKyxrWEUENAhbZfyZcNsgNdVtYs+X4eR1bLDqGAgnqm3SuH3pESEgI62bmyDR2y
Y8CraJZ8hYuQneWwlWxZkljYgK2wWS+0r2FZHhtAElm5st4Ukxa6saJ9pJWIlaTyxlrGLNksSLFr
LAhyWUFp2Q4bQR5NgVktrEkRINc1prY7ozKYrpI5dc18iSxIsevmldKsYzTCgRGhBLllSTHTyoMO
tZ5VydQJRleVuqIrUHpqcNo3ORwbBu9rWR2jh2Uk/kwN5MGNXM865O6MKgeR2WMRj3mGgosUx/Mm
AQkWtitFHuHndMq3KaLrCK0M1Uzb3oxo+VKGgYsd0hZ5hoWHVx2sj3qldIqOT4o4jPqV85ww0KGG
63jte57EFBF5BLFWIWDWR2iZedx8uj34eOz6hqDdAUQyx3WoWq/gjYLBnfYNRCQK4LWrqEZSyaFr
kZ2WrN1AqtDSiKF1oJqrxRtYMB32A05V1YJvc1AMhj0AlFjhtSXqJHdiiivjLajarmtRsIEQz54/
eurRtV1/GLJPRDcNnaa2TqJrnCpY74zdUoiRK5CyMi6ceKSQiRa6zehJ2fnfqvRffFxUyR8OzTqb
zjJtCs1V56ST2zxmtKKb9gMsrizq5OUWVH91mq2XCftG5tI57eIr/wDzRCK2SH90W7bsd6f1I/8A
nrtvCmAV5q9vEIWp3bJiuyrEo3yBo4klv2Bx9pKt3jx27DsI/ddWs2ExiIWzH3Erh8CyGorip/H8
bYyNRY4GIiWEfuGrR8Bo371mzk2uD2iyWY7/AAFDuUabx4zUTJ4eZKtvBOKd6xbyZDj9s8hvJFT7
JYu5AJsGOxG5YB5Oqh9vFRO9OHuOODtypHuxrfsyY/Ikdv2IrUQliLm6rH21vWbikt/dkJP5MNP4
0uN3HxG/ZA37lgLuLVi7akb++U37IwbHe1FCFE7M0HJ8BP44k+5ZjR+VgkEQyfvlN+02Psdzd44m
7CmAR5IDfsjb92xEj0rQ9oh0/fJbuFAbFVN48ZPtTA8yVrNgjb96yb+2ABGmuk+xFkujmhkV8W9T
nJpm7QpwUIepYjRNb/Ism8kgARppScsIm0dQpyan2IiJwmiRxKwew9TJvj/lMpU/mOT+J228xt/j
xE/bORHGp2psqfyrNEUcUTWnnbcf/wC2VjFID/Xip72LWqar2THf7Np/iiMZ3Jv9u38XixSR/aNF
T99rxWRVoiPKn37NPsRUHym/4wJ/H+240JP4kT/YtEb3atG9/VSfxKh38oX+pOX/ALmD/wCcR7Fk
1/7Y0X/cuFbvVoxZUxPef+yPGINzSr9iJ/qnMxJ9Z/g1k7+R8Y350/8A7M3/AF40kZMVf4kD/XlH
GyxrFTti/wDQvyNYKARpTWPssn2hQZTHERU8CvT7c+WwFlUKj3p7ztQm7DIB2SMsv7i/+fCntccS
f9fXJ7WstsewqX9wv/8AeajJ2B1stsoVn7uX3roFgx8sCf8AW1v99tLbGn1JEMb/APudRk7QayWy
SK2/vc3+BX2LHyRJ/wBdXZbT2w7CsIhSf/3OoTIAFZKZMjarXeHGKWItZqSVIkmG2TWTdmyl6Knp
cnt//JfmQmfOafdxnlXeBZsXyKqM4h4Te0KezvClx1FLr/2RrCcrSCjOLJjp/GdYqCaI3dBqBv3o
g1dJjf6t89PJevXb26/j0R12JVu5Q5pe2SEu4hKncs38MqS95x14lN7gaRfJ32BHduywL2n1ruTE
cndsHcW1pu647k5E/wAPed5LV+xHX2sSKx9a/caPTu2C7MrDK8p1xV3AUypKF7BA9N7R/DK127Oa
d2d/jgHUhTKnFP8AFIPxkgXYIFTlakVmVblejnfemqqjhvV5CuTtjciilEc08RftCcnK0erErXc8
vVRBSv7l+IXseC5HQ5hHMNDXYAnJztHqNKxyvUr05yF3DGI5xyuRAhcnbnv4HhO2CIidy1d9ut3U
kgiIQ67xxuVTuciBA/cc5XJIrkVoxkTv2qqja3dxDlajiu5AZ3FM5dgRnorJ6PSTW7tAMid+2RVH
XclLcvTxxIr5den8G9/2qUrVh2HJsmrXgJhG+Tao5zKxz1kSzNHj38wKwnf5o0EIzXss2vQ1XuwG
pCo/Hp0qHoyS16EhuERD9xBx4MhrstRk71Ojgi8pvlWSd0Ncx/kzzo1rStICQAySWOQcWBJa5bYb
1dUNUQySmpLnp3w14S+TYSWtaEyGjSY0hJIydqJDlMcS5jvKtKx4mSJjWyZ38gMCKZp7GWwbIR0L
HlQDNkx3ePDgzWLKuor5aUo3AzU8pCCp4RlM1i+BYRnjn1MxpYU6rKsmK/xYcSxYs64hOnCpIz4u
TrJjHlK2XGjU5QyZc1oA1Ngw4LSodIkxV8GLqiS2VJxFypkpHKpmzooKR8eXLmjjR6SzYYNtTulH
iubBAK3H9UsYyWIKuudBy2txMUMps2OPTzgzZk5kOPS2zDZZ0iTZENWVwkuRpZz4v1UFZV+Bl1cs
YsKc2bEbp/ty5k9sKPS3DHLc0iWRIqtrg/XGedMG22BX1SV+XN2xmVlgOXFTT3YlzrBlfHpb1jyW
dM2e+Ora4H18fmyhMuYcCrStbcXjWOq7Bk2K2hbGlTrNkGNS3rSvt6dtgQXGujfXhrNlhZcRIVb9
NS2sxyjJpkMqJC0+WLMMdBV0/wB5eL8+l3RcP8OXZa83YkQbFkmPbQ0206JNrSySIyssvJFYx2uN
E/aCRCQp3RWBGAidi1NtOqzJ42oCp3aSEm8uwbEFPkpIM5fVtnxi+gS7PprZNlAw6lktisHcp3ml
bMGIY4jZ9sncgWCSGpGYj7GyaBldcfucJkrCyGxWLdNSQMzZgxjHFZPteDoFmh2oAfKdPQDIdyik
exkxCGbFG+4RDBlMlMaIUbLCz2WvtEKnYGr5k9oWRLhO9xZKa8jY7D2yMJFmtljawQMnWbWZXWrT
Z2BKsua0LAXGxU7c1jiMjtl22xYk5swbWDj5Ps2jSutkLjhiIsia0LRXKJIYQctrnsjttrFH4V26
74J/B1NbbtUYiYeW0LWXO0rusljUjAtm2vF8GxZIZxENZ1kjG1txyVUCTJEtAMZb8ZA5DJQ1cwSW
Nr++BZJJHsJqz7Jom1tvyf8AbJhpaAYlxxkikMkseUY0srVGurrNpmIossLFBtrLbiRHifkiW2ON
bhGSI8xkljnjYlvZ9zKkYdo5RoK1YImVth2HtKJ6SpjI7FuXMlxZ45LXnGxLa23yqtUM3uhVLC1R
ja647ZhSxvZKsGRmWM9Tve7oF6sdT3KPakkSpZ2vBtfcOGUEwZmzZwwDJbO8ittWSGFlCay1t3Ey
pusbIG5LS1QaQ7VwSxZzDDmWLADPZvdIqrjvMJNY1lpa919Tc9tWzB8be445FtHCLDtGnZNtGAaa
xeQ1Tdc8LYjay0tFM+rtlArbMTx29w3A2DwmrrgRg2NwwQ5MxTmpZo2iSzAjbaVHcOFZuiGHdieG
4ue4wE1wy1l+NRTr0TQSZbimprvsKW/j8bSzWS+vsliEBfx+xcXyHYUnJcTGLxypuvEUmp4bksbV
ZToU50c0fVAOzbXzZDO+7eq1G0CTdTCcORKcV9XbOhq/VsZUtLJZpIstQPh6tEyPZ33lN7yq6s1C
sNJWqWlZJlOM+ss3QlfrAb22VkswseUoXw9WtAGz1AswSlVVq9RugZL1UhWlkOKsGxfEc/WHMdhZ
LNIGQoiQtYLHDY6gWa1S5WaiLW5K1b5DSlc98KxfCV2sXvFPsFmlCdRPi6uJGDPvnTR933rdRFr8
k6qJIYU6vJW6oNXo7XBFyw1C+aJ7uS+rjjsdi4f4d8tdtkGxfGWVeocddb+Hk+z8zIVmsXH3alf+
pGtazUrW4bUPcxt8rGHkqcoL5YzJctZT4lusNJdg+Tjl6L0Tr8rti9fjEwBlE6PqFwmybR8rO5xW
LbKBDX7jNeZXuiznx3O1K9GSZjpCjMo1BfKFsi3dKTl7xrR8bC3rioUivWPMcBU1CRGyJzpCoVWL
Gvnx2ybdx8cZd41m6PhL1SIaSpFDLcFzL5yNkT3HxCq18e5cFsi4UuOKq5GsXx1ffOc00lSuEdRO
Zfv4SLFZCIVdwXJIyEuHFQhlcsaweDH36vaeSpVFJULg3qoyXZKVEMqZFuXx8Ndd1pTK9V6csjyH
DUN+5jT2LjJ3dli3L42FvFLj5HJ0aaoXLfudh5biuZIVigvSDbJtHHTu+8e3fGQl28yEOr1BMcF3
156oeYp1YdWKK6Ixp7R58eXfIlq+Nhbt5EJJ7mBlvE7687Y01xlaVUUN44TJNm8+KTlkW1dEwl64
rSlVVi2b42JqAyYW+KViyPcN2UKHtXyUcT3i2RI2FuCPRxVdg5CjX62fYslxFQnuO5MBsme+Rj3Y
7Pw3BF4KlyfDSXExr1xlmUTHzXmRX4GUUK/UjuapFdjDKNfqp9iSHExCe6TjCR0x5EV2COQeOmmc
jn7qxyo7zS4QzyKi4hiMRxXvzljHvTO8bHvVcTdcXvKj3u2R3ujCOxXFbirurea47vMxxHYnJy9g
yI/dub40BXo5hR584MT34sY7cVV3YiuVYh1QjXMxfnbE6CC8iOgyG472cxquXwjq0rFH0DEMRCgM
PN1XBCIXH18luORUxoldja2SqEEUWJvyFAMfDQZAM3wMd5sJVSmI9ijexnJW1Ul7ZEUsbG4GtMdD
V8gGfkEd5lWpkI0o1ErRK9WVB3NkRigxMBVlkoetkAzdd48Rx8JTSG4QaiIIPcVtKZ7JcQkVBCUi
spZDmrTHa0oXCcKpKbPoR8lQyxsX+g7F6GT2f/ciZBhOOpqjtshwFkZLrXR0iQlkOWqcNQUnNPoW
+FpODUpHLkqA4KxKhTjmQljuiV6yElVjgI5qp1+PR7Z8epPfIFYshH0KjZKjKJ0WK6S5tD+2XXKH
O0rnxaZxGyqdRIRnBYNYsnH0fBHwXIUFE5yLRZMrXByFUuKn0JNpVKrGlEo3Yjs3xn7lhUrpI5tc
sdYVU46JQ4el7bSxXI+HRuIyTTKNpwqx0aO4xPoGwzRVEWJQ9xq6ebhKRrGpVq8zdP46hYmSa5zH
xaDmz9PDbkqn7WRKNCpNqPFR/wC1yrlbWvluk0fYYZnB3TbGJutfRuM01AiNkxVC6BXvluTTzWsm
1ygwAXFKDTrdpdIomOErVrqXvoWhTZtY90genhbLp8O06peJ0OgarVoI6ZMo+20rO27nnPN8AJxS
RtO8hTa7tmhafRzUoo202iRiDgPJJDp4aNnUXbZErnyDx6CK1i0cVcnUrxugafZx+hxMn0KMbX0n
fX6HDahaALknwFjvgCYUgqCMYNvASK6JGWQSPpxigtIXikq6XysSoisw9CEqWMBYj16NT3qqfyHf
RAcbelWPlfXvkljUY2MsqDmLwyJJqqNOEikE5tnWuhFqadxlSoG5lxQdpYFc4xIlOxg7OhYQfgPQ
9TS8EPSCK20qXQi09V38bVh7d3ScMr650gkSnYMVhQseFa8jJFVStah6kR0t6d0N1RU93PpTGtvK
HZkKteU0GrYAU+kHIAStIKTT1CMaasEZtzTEjGqKjuq2vEjbrT7XNgVjjHh1YhDm1A5Q5VUQEmpp
mDasMJsuqNwH0lMpFHEAxl3QsOKSBwH79IkdZBKinYFOzEKt9Rdp1JT9zEZGC24pRnFDqHvkRYIY
gzRI84M6mJGm1FM0LESMZ9/Q+9LT9zNo0dttUDlx4lQR02NCDCE4EWeCxoyR5NVTtANCxCP1DQe9
LT91HPiwmWlUKfGh0pFmxowoI08ayDbUbgS6upaBjZUYhNR0PNKOmUjEOCEywrRWUWHRv8uPHHXi
a6PYhsqN8edW1bIg0nRym1HSNItJTY6SGHlnWjsY1HToh7Gcymj11sO1beVIOYZQIYIepwyz2leK
fEK3tkTovynod7Z+NvY2O/ujM7hqeq7Q7uUIAtOObvZQWyGVtYgEuSsDlarCR5EhojlON4oImPbZ
VDTJXwkEzUYkRaeWwSnhJLFZROy56bZt6U9Hx0TIrO4WuhtFEcZnK8aiZpiGhBnI2PlsgyBqQIew
UDQiORhGWI95NVCaOI87GuHHGWVK2jigzUknnxGq1sxgWMtmEM8bHAsY/KQ2jI9CUj2YSI5i01Mp
FhRmDFdx0cWIBGAmT0EQTGnjjq0WS/jHQatlNua7tZQwhJhgp2Jw/wDsYTNo82xQDyXCOymYw6Tj
JGZXHbKbOjsE/wA5jUiWCHkzI7XAptt7SH3WT4DmPjB5mpo42jtBJ2J6bGd84mVg+7NjR+3GeZqZ
c7KtBFTxzFaNbfg4WnY/I5vtMkyGFA4KEmxY6Mjukt3hga4k53YZAP33WImtxZ6MHBn+Y+YNqgNA
dLks0qVUPQOAniv7tNUIDAgb2poG/UUGgweaqSij7gItaxHyTJGVrElCKJsOSa2aPKszjJauaJG2
LBNhz3SynRO3CE3t2kp8d9UqyAakAjX1dS8xIIOINSsTu6eaNMExqg1IxO7Qhb4dqYoS1b3GDqUb
Uxye+VYULIiw0CB1i5Jh4rShra1o8nyvFdCVJQ31bHSzNSMGvnOkPsa9pkjw0AAk945igQ8evrWs
dayXRcrn+YEla1ZsvaMGtmPK+0htIKLEbHjlnPSWoUPFrq5gyXEh4EqSLKCaua+XMTxQ1UsryWkN
pRxIbQxpkwzZjG+TFgQWtNeHeHKMrzslQmPlTW+NHrJBkk2UVpGQo7RRJsiQs6P9+FXwRpJvilG3
TznvbOhsU1g3sR68shJNgBrg14Wihz3ndMgp3oWqwtFOXG/GmxIsiwZ2QViHSXMjtICvjtFCs2nJ
OgIpYcWOz6hqDuMHpxpBvsAMUk1vajwhnSVIEj4tcFqRLURjTapquiRQM+pajV/DT4nhfZibynt4
Q6+MfzTNRYVcNFiW4HybCoRfGCNv1DULXKLT8dwCWTW9yWiNhw4ZFmPbvAqxo2LcQyGsqZvEEcaf
UdTMeoaCIsRbViK+anGJXQ3pJInKDXMTxLmI+VZ1DdgJMHGtrSv+qx6enWvzWO/06IIhsq6tsQd1
eIGOV3N/4X0b9HYvQyY7+6qRFmxkRId+5fIrJChkVj0kAlIgWXshSyKT/BLAjsnyVjnqH7g8hrnc
Ua3Um27HbPqFV8bUjeLyN6r8ehei9aYfORFanYunKHCyfIWgGjAWzE7cyYqLpoX3Ds3j2h1AsJfK
lw2/Yuft5UzXKYre4KNEYIti5eydCENW13YZYWCAZTxvMwvCOneYVFhtLLDHQY46LlqL3hLuI8ca
kYmw4vzYD5Oqx8Fu2pwgT1FJ5q+LYLxnwJbFDIEMymqGPZUhUTpIWESIJg8u1XtxNnPghGjpW/Zq
Pch1TjLr0MyVGWIfT1ipX2P+CwT7ruunmN7g0Txrgvaf3vIPStRBXP7Wnkudmm2IrJrU7E+SoSVC
oQ4WJ4t09Quopb5BJSNVIrGNy63QMSIWWSPHZFDOseLauKnbkFYFVOB4o0ZhTNCjUAn7LMG0oe3Z
cjebk+1ET9k4KOJVt+3qNNkqKvlj3JGHa2alWBDfLLHC2Myzte2lTbsVO+hch/22cRDmGFsZsQiP
FqZER9dLcAlcVXRNR/5tN/tiSn7KDbt6m35k+fzSf7b1/juE3uDT+NFT9k9qPNUtRBN/27L4hMak
ib8L/gc1ivCnGLC+LFiPkVKJx/8A7iz/AMcFrEPNbu3b+P8Ab5A9osPLLgsqrRqI7/ZtP8ULh3Jy
fsZ/rq4fOKm0SH/fZqiS6rbkRP5Nq7iGK4bnz/cQ/eG14+9C/wBWE379q9rC1KtU0pORbRdgwSse
kz3DGT+F3mNlQNvG1iv8/Gpml03Pbrs2FJYVkj/DF/0ny2DnVrkWLD/9C7P4+VpmmPO93WS8Y8Ga
M7T+0WF/qSJzA2VY7cMT/wBLUR0ipWHbJNY/Nh7RKyewjSJ/Dr0/iSrBkW3qlRQR/ey1GXsCrJTJ
RbNP3zE/i1dmwmO/0a1d4k+yZFt6teQ4i/8AZaokdkFTKbNfa+7p/wDq1No0zie0GB/pz7BsS7ql
3Hqgjg2QNRTBD05YyJaapGp41XVpEFcXTAtkFcVy4vrXF6G/tf8ANT7TIjkdCvR7yYMdxZNWPsBl
bFZeRlG+iT+PZzFG48V8l1WxWhsJqxZMCV5AdSe+MGriVH7Y2ol+4THdV6J6kyAZRGhu3iX5V332
fpYziAvXOaKQqqTTp3eXJf8Ax7YqvNHMoTV71dGvyLyoGo6TOXtCrZpTSpo0eGHWox1hK8dh2nlO
06m0e+byGxxmqCWQLhagFtXzGyGWjt8B7AsJj2HhqpAh2Y6yerUqlVUvHIrIvvOH/q226FjyJDEb
ZyUdCcpAAEjXWxHCHSSHGy5GjxvCQTquyK6Qb90WqdtIsFVGwl7gdQjRHacZtJn+4bJv3HpsuJlO
VWzEJvGuyO5tfs/Tz1fFvSq1hne+lDLvZOVorB6qWtMqSwvV0a/KvPTCfttHqIVJMIZ9jHQyR4SA
ZPmoPHRDFfUptF1DvkVktMFPJGIK+EXIJ0IOY9Fkq3aOsonmp/gjETLDn3q7cY5UdsozheKKXJLL
I2rJ3IMFAAspiphq2STN3xyR5st7qlz2RUVCGtkVoql2wNUJuSMxVLW7pA1E1ymoWp4OoHla6jVz
4mp0TCdKZ6Mlq5CxiBKsjuIMEGSjm2I3qSqRRR0lNSXY/eHXDI2RPktYjSo8Ro5fJ7nbjQZTXpbD
I4tS1QCWW3y7FvfBXx3skWEpGoM6ECWEbyGlQUSumNetxGeV1W1wBvmtSfO/kxq2KVh7OWjEiyWl
DIrS+U1/jxq+e15LiK+QtSxYoj2DGyZieZGrq4gD2MxGMgzGlAerKshpEixa2ya49zCWYtUFYbJd
m1hjq2bFgVLop7Ge0Q6qYw8WXUEdJaRsKLqOSkmTiZRSkjHKVtgCLTrHPPsGRx09kyRHsKRZMlpE
gxYlwz6jbQUsg1cJa4c+4a0jTNsIsWj8WXYWY4waO0ZJFYUXlye6yvjw71i2VnBZaR6+Cla21u2I
8cxljHBQpHlWlqyGOjuGmDY0bJZXkbWxot8z6nNiNtIsCC2uZa3zFLDnssI4aJkWXZXI4YqW7aRt
jSimFcdtdHjX6JZS4zLYMKCytHcX6KSFPHZRo9EOHMtLhkYVHcIVlhSjlHPLSvjTSfVpgdLvI2LH
StEto2dKlg5x2abeQs/TwfFJ+0noXq7F2XN9sN8E+Yhe0WotkIK1jNe2jEnenzEhR6m48oloBDJW
IjBzIzTPSOMYYZUTNQlTnQnTsakMm1PHQzySWxAWk3yHq7Fz8+jbf0plUDuyITkSNeDRXP8Acmn2
tDHt+LhTdkfpoSIQqtUNwxvOCHvSoLmtDeIi5UyOzJcRskIIoxElTGtwJGuGeM0z/DExkaQwL5Am
ScHBCNtujWYNO6SkawMeyVqpEko5hoYzOQzQDNaIKQ17JguQwMtrHuZUw2OxnHs2kYbkgiGRH1wV
cwjADHYJ3jjGdkdg42TpbdxAGZg4McRJUtrQ1UhqHOjCIhWBZakQ56uMAWGVj2W4Bph/Z3SgExxR
lZ2L3g8gWI6TVKIYrng4MjZH6dawLJb2PHat2NSib3gkZ2L9GvfQyUEUjhGZHQAVPMbzQjFE6MBx
DDEjIExmHaAiuGJEtdkfXcXmgnYwNiZjXx5bCBc0POTMawca24HQg35IltCOusWmMYjHtYwOSe0x
WHH2ntC50jt9ljQ+cBokaeWwA4dwjpBJQyoGWNmXJGEbUNGzI0piCs1YVtTOaJhCMJnktEy9nIVz
16AJ23VF0j2d9jstLVB5XXLhEBMaQc2xaBjrh6Sq+2aYZZbGstrVSvrLvlnkJta3HDINu4BY09ph
zrNgGOtH+TWW6Gaacxg7O2eV9Vdqi+aza2uNshWagLDsmnFPtWga+yI49TdIRprIQxWlqp31Vy4T
0sWcbi53yNYPEavt2FBZ3TGjJPep6e7TC3QmDsbR0glTbujPHciUdvddzATXiNXXw1BYXouBJbnk
prtBYa/C0VnZLKJXWqwns1JFUN1eLJQr1e5VxuMdxWnvliYXUweM+wfLJAsHQiD1PHUVteOlqw6t
dX6mYBlhqVj2PkuK6qunw3m1aByTp7pZYk10cgNWNQVpdrNxpFTKzU/iMnamQzSSFISuuX16v1gh
UnT3SixZjo5R6wVkaxunTWNJtlfqYkLJmp1ktIXm6utnwnG1k8qSprpBASlCUGsCijzrsk7OeV2p
TQssNTPmNUiuyvsyV+F1eYzZMpZBQyHALG1hIAKyuCWCR5SgeLWskI52pzzRgmkA5mtJaM/W8lFl
6ukSGkdu7N+qJ02xyY7Fwv8AaT53yFOcB5NQq4USesd865dLSHOWLhb5xlBqFwh/qZ+F1C8iMvXi
yXLWU+HbOhpMmuluiWCxEmWzpSOdv0X07erfIchQOHqV7WyLd0vOXF8e/fHaW+dIacnN0OwWLn6k
I5JMxZOBN47x6gIjJFs47eezo14QGLqJ2Fs3lUF68SJqR64XUDnJ9QfzHqF4kfqFSJKlKVRv4uj3
z4uGvXGaO1cxzdRvbhLxxUJIV749w6OhrxStKdXOi3Do2N1GuFu+61li4b26hVULeq9EnOQgdROG
12oFc2TYuNkW6fHz9RYe1cdAznicmpFahL1So6WqkBeqBv6ic5JVt32k91XpElLHVupV2l2Pk41y
tfGv3BSTerIQj1e+Jaui5+pHPSVL7zo8pQOZqN7UmWvlow6jdHvnCYuonLhLNxHD1CQbf1CR+FvX
vRlg8ZE1E5VkXpCIY6kURe24WoXsbIt3SEjXBI2JqQ2HtnnTvryBdkC09o4zQTHCd+oTMX9SFw1u
+RjL8o2rqE6q+8KTEmPYVdQGyRZENiG4qO6OJn1cpHyLIhmxrEkbEvz467M/GT3Mel9Ia19yUiFJ
yxcToAqsd9XOuFkPJiO9x2RxoacQuOeuBmFFj7Q5MI9y4wrm59TlcXyXlVN92SZI2lkFejV3xjit
x0uTs9yrjCcc80uPM5+I7EO/HPKue6qxhlxfJVHIqYzk5eMhmOKuI/E5rj1fiMcTEhSFzxZSY8JW
4EJC54UnCDINGRTEz6dLXPBlNx43jzlndxXcsExz8dAko0jHj6LiYmAjlNj66SPN/dgnEX6VK2KI
gsai4GuknQ8I8duAilPj6qU1HsVjo4lIv0iUqSAkArd1UVWc+SK08bPfeNCIfDUkoeEYo3gApXfR
JCskRSx8anuGnNJSTUHionusaC+VhaKQxr2Kx4I7iubQmcyXCLDVjFVQ0xjtlVB4ybe8WC+UpqE4
kcNWPjgcd6afM8cmCWKrGKro9IWQ2XUHjMRN8i1xJWG0/IHh2KJ3xiYvX4XN8fitz5wvwX5RMiRX
Ge+lVoo0LummVKhHEid8jqVRtj0vcRaLfC0WyDplfkyqeHINYp2zq3x0gw/IyVTqNCjVMXF9G2b+
lM2wA1IsSjV7ZFN22mjuY6vqFPhNPcWyoDh5FhOO5mn/ANkypUGLHVXQ6JXMk0vBhQKN8GrdJVaJ
EbLhKFY8Uh3hof2TKlRYoXI6DRvIyRSoNh4yjWBVEkr9DRqTK9QrHivkPFQ/tl1HZxQu5wqJSMPQ
oNkiKolrqt8rF083abWuBkeM6QUFAiNm0/ax4XI6HRKRhaNGtlxlC6uqyTHfQGok2tcHAxHmILT7
OEyl7bXge10CjUrTUSMbMiOCq79PnIkV0kgdPNaObTdpHhdzgUClGega1kqI4K1tQ6Y79PiRs6rU
ORIjpJQafYjJtJxaQDmvrqLuNNQojZUR0d9bVPlPWjHxn1jo+Roj5LwafG0c6m7bHx3dyvoUc09A
NGy4bwPq6t0pUpB8bOsfHyHDfKKDT4mtn0XFPHd3q+j5NPRD4TYboq1dO6Tn0USMsalwFgw3yix6
EI22NHxYoHNLW0aKM9GNWzoL4xKyoU6/Rgqy1p3ByHBfINHpBDZZUSK2QFwnqvRMr4nkEh0rGCsN
PscMwFZIqaRHMNTCey1rfFfUVvkq2oE1l3R9tkGKpzQqdoWT6JhR1lHuTwmCQlQOQNaFrJgKwYWe
Ix+XtE0OO9lR2csYxzlqKZZD5FCiRI9XysQVqAE2M0uXtAmU9PyVK8SJeaf3wMVSGptO+2oq1gA6
WiJIMaI0ScssBDflbTtYNeHcm1A5EemgCZhxCAoQsOmrITQD6CZ3HUtNuklAR2Xj2FevRMgRfKfV
1DIze3GkLd0XYdR0u7EbFGl1TNlCrKh5CijBgjPDBZRZFK8Muuq2RhBWKYt7RKxaOl2RTxg5c07J
YqylISSwQYTHABPiyaN7JtfWsiBGaPILfafTlQ0nBj5ceNlzTjnR62jc+S1ooA2tDZxZ1A4U2DXN
giBOjyJF9Q7rSUvBhLAMdLOrHYxKuhc6YrhV7Bdm3iTaAg50OvbXhHZBln1BQK51HUdkRbQMdLms
HPi1Wn3+QpxVrWOHdRZGnnNnghsqwx7QUuRqSg2b6NvQuL75xwiboRP3CbzfSVKIO2kDihpit8iT
GbIFXU3jktCMAOlK04ZhEGvkscKvG1+Tq5CpXVyAzUgdmVx0AVgmTQ3MDsYRNsXpvn4zbNvRv003
WodpnNiNjuZOFJqEWQGK2KIcphX2Ncjm1tWgWllNC8sZskMOn++TjFaJ7JmSadHHDDZFEyQ15LCu
QjK+qQDCyWhc+OkoMena6STaO2ORsnJtQ1xww2xRMkjV9hXoQddUtCwp0ErgMkgDUNWWRGxxge2S
s+pR5gwkiiSQnOwgIQdZUtA0khI6qJJQWUzHSCsSOgSNkZYVSFdGhJGF5Le5NgIUdfVtDhDIB3bb
LC2nTyXsQDAFbIW5rkRkhnFVxibuoatrBGMgcaJsoLadvkv2A2MdktbCrR6x4bACSQiPlQWlZXVT
Y6nMkfGMbLAyoassjEjtjHbKWfVtLkeE2OJJLUNMgNK2DVtEskyAxokkh+kMWQ9iR2RDtlZOrGld
HhIEXltQ0qG0w4Fa0ayj+HgmpKGlS3ySMSOyJIbJydWsIoIiBEs3iaREQg4NW0WS5Hi4BElC+lMW
UViRRw5PkrYV7S4CIgApM++eMhxQK1o8nyfFyMnli1HDaPHdET30zGVxpTFAEk9OJB+TMgR+MSTM
7LrkyHdpaHsGyI6Os6xY8NBE7k+YLtBWxTesVpR3QpSuqUJ2LaQOKd16pm1KF2uTN8WHp5hnLpyC
mT9Mo1Kmoe8ldHbFSWqOjVnH6vagIaPTQZgJVijXNDFaGOWQXzGiSREOjY9pTS2vzVv3I2jf7rYD
jxjUU5MiiNFmAVHQz0p3zhJ2oc63fEkFmnsH6eE6OHVRELlTWjfGlaeCcbaxYdpBitZBtqU04szT
xoyOaqOxM0mBHyLf7Q6Zp0LZgaRsQSCgSRnLPiJygQI7GyNQteTNOBcF0sLfKtf2AqQlaexGnajj
RIEmOUk+u/dAgBb52pBvI3TQHAJMCnfuGcA1cQgizm7hhsT6bKhklWNf/o17EWx1IB526djLGLYM
RTXTfs1UF4CS2J2YbNqyXXPk3Fcn8CvTey1EBTOoIyxZE1iONdM5BqIDgLMb9uK1G1h61ZFvBTeu
rv8A0dRRVkO09G8STKanPUDOYqOvWKO428X89F6J1fi+2b4X4L/fG/2Klv8AG1Q5e5HMo30ZkMEj
UEzUJua6Y/wShI/LY3i5QEV4iS0RR7KmpG7De7Z2m15A1Km7S4vVM/Pr0n/o2Iu66nH2Ue3c0xu4
gR+MoicmMZ9qaHm6G37Ak/dYi55Us4OIm5JXuFgNpLk3ExE4Tgo9YabBE3908fLK1nbI9u7jp9to
dpKp9kafsnB5LBbsEbP3zx7pAZxKVvuZPsoFGnVu4hN/bPD7wG8QiT988W+QB7FInuVv2lB/I23A
FicZouWVzfto37k4e+QR8S2zdwTG/ccnuNP31H+rNHutezZiM/fPFulcHtlkJyV7fsOFsVjeUeOz
J4t1q27M4p3LFntCEjSmZhW/YUX3mpvHAmTxI59Wz9vD7tgNMhMRpzom72p4zhp32N3jxWZPYjn1
jfbj9+yZ+2CxEMduFbtHeNO4xP48ZqcJrUUlSzcaJ9+yb7QG7SZbf2kT+LwTuN/wQ0+3PY1xKdPs
6nTCN2XbB/OlV5ZYf61rJXvUxecqJt42pCINWyFWRp524tRPRg5R93aX/dk9U8OyP/K09v40wzGP
jOao9SjcU1RUcEkymQxtlrOnjAgYsjULgSFuBFHSGEqPe0jnNTxhgT6jJegQQpwzEsWKuf8A9qjh
7x0/jX7tpOjl5rqf/WpLFIBl1PFcyDYRp2Wtai5Gao4xLuMyWqd2LbM4zqSo/bY2DK8MblayI0VY
wYvFW3g0ZYxXbQDX4WzUA2VFvY6Am7Y3NI/5rt/bj18lhWTl+2L/AEGTmNkw/wDUr/8ANeSWxZFQ
XvyJSbyLpeMetmtOKd/iB/5v1BrJ0D/Tg+8zUUlsJ9HISRKmL9+/f2wVdg2UOav2YvvWfU2htK9f
4Va7ex1HJ8NaSS2VKnbd28cjA1FgyUCUv2oi/wDVus0BbwP9Ou/9DUk3wyU0hJMmY/7t4Ttxqaeh
48x37Iv7qx1oke9h+0CvciztSzPCdSyEkyJS7v1G/sBo7Hy4t0qLE/8A5KvX56bdHe+O6E/tL8x1
2PTERYmpAKQgg8i1EfsBKRHpfxds00nEVrJcHDhdMWlEoh3ZlDlNYeSHUfuNWq/NOtUYdSuTgRcd
6d/UmaTKiRLN3HKhVcjyIhJK7hjEc6WRdhjfuycRWPif4BETlZP4JVOc5CPRCGduIJHLMe7iMZEc
ywerHwl+yMic7F68arljyIjzLyENXOmOXYQnpxsHuR8T2E16bzl/bWKrsK9EUjtwtV3mKuwQEREs
nLyhL9tjkR9g79tcq4R6Jj3chc3pO58Qgem1k53KD7D5ohJ67srt1WzenYnO/evyL5pCIseyVUfA
9m91vcsV3bA3XDPTFduBeSy2v4RwFTLLfuV37GoVO7YKqsgNdud6Ijno+MiP77XcARipk9F7ld+x
veTv2fu2A1eckqIqv5AaxyHaTgCKdN7BHdytVWN8hvkWCqRkFioSWdqY4ncjqN/daVGBjHauT2O7
1b9lnkt8mxXusgNVDTTo3O4jwKN/kIRGBhyGqyxG9SVv2BakMi4T5xvzpZr2ltd/Hst/Jq2uWVCR
3h6m5d0fu7S43NBqZju27dXaXE9DWaKsOduk2hcng6kjHISjRzYZwIeTKAseOeHKsTAp/CK5ecWw
qJRpX6f4CHYGgLVWcyUYiu8aA9yWNwJ0mPRwJEU1gZrBBkoUBK0vkvO2PGshusJWlIJoa6kikPFg
VauNK0mqtoauRBNYHbwG9roxKQ62gnduLaqj7iqanh6pK5JGkHoj7RjzR6fmAN8FyzIpELBk0B1s
oy9mLqJ3cnb+6fOnZrYkg7m2IIFMsMlxbNC2psWSosikaaWWWyFGq7tPKs6xtikGP9NDLvGJKcVl
pGhUzYj7m5YFKW0bLjSKVhJJ5rK+NV6ga+XYVw7RI0dKwU6/RJXfHbRodOyIW4vGxko7hsgRqYZJ
EycytBVah/mzYQrQUZjKwU/UDVkAlMto0amDCNc36Rm0N02QOVThIWfZNro1dqXaZKrxWoxNHVBl
3/8AJBOHbRwVQopbjUHYyiukkiPTBeWzs2wI8DUb2yjwh2g+Y6uPJ1A4skEptzGDXigPvtQYvyvX
4z8qvRybYvQi+xU92L+6iukak4bTDrxt8+RKbHjV933ZU/gYNS1osnDabBhGMcWQ3uakMis0udGh
1EdOFSNDl8gcQVvZeS9y47pt6duu2NynsvGwRRzBK9sZsu62LBsmyWNYJmWVmg0rbnkvEZslzWhG
244nEccxivHHZMt9iwbNp0RBDywtO2kC35P+0XJE1oGJb7FDJZKG4jANmW2xYFk07WINuWFj20g3
PJ/2zZImNC36zsWNMbKHzZHbOteC11o06bDbk2f20iXH3eQy4eW0SPt9ix5Q5QlewDZtpxyttEKi
qNqzbBBth3H3UeEqGltG0txseNMZJGr2BS1s90kP5OVcY7bKW47S8xlQ0tg2kuPvxprJTHEYPLG0
4LXWzSpzYmTrFBpDufvd0RULLaJDW6tkRpzJLHEY1LG14pWWqFZ3GJk2w7bYNxsVhmEQ8xoWkuPv
x5zJLHGY3LG1yrtkK1SDywskC2Fco0jTseh5iBaa4Xvw7FkkbzNRtna8sqrdDp3mbWNkgkr7jg8U
ppMlzWx2vt3eXCsWSWOOxG2VrzWqt0I3vNVLK0aJlfdKEjJTXpMsGCZaTlkkfm+MXZ2mi8WS5nMF
3s4tG7aQCcqA1C9HpG28iol9oV1K5hkInPTRla2VORw7lyPPp+24MWSpMJPbHZCt0fOJM7jRnRMt
bIYxQLhpGuko7LKzEERy8y6dkI0j7ZiikWnbnx7JhRrNE3Lq4QqVVy4Tm2ouN3cuKlQZqSI1mEKS
LcD2ybVoZkS7AYLrSMLLa5U2Vl8PgtxD3sdRCQbj9yTAvxhjXMpJRa6asUsbUcd4DX4xvsrwMkVZ
qMYc/UUDLLUg+3JP3n/lME/itTf+Lh9UhcybOdINX2T4b11WBR2lu6Y4R+BIGqmgZYal8hilVXVl
/wCAsjVrSslS3SHwrB8VyaxRorG2dNcwysfB1WSMOw1G6Uxxlc6uuywXH1gQrTyXmJEmOjvbrEzQ
2NqSe9hFasHVB4Q5upCzWdz3r7csFxdYSCIc6lfFlPjvTV8lgZ1m+crCqjompZcNk2+POZyyDbHg
OPqqUVHk5vjyXx3fq6a0cywJMe0uzoupJkNsy9kTcV+QrY8Jx9UTDYUnJU+V9blxflfbCr+0vymR
zKJzL6Q0TZz2ST3RTMAdQufeHe2NeFHi6jNj74zmityMWXPfJWNOfFyTZEkZHlrHyTbmkYqqqr75
+Vzf+kx+2RLYsfC3JZDXP948xws+vm4yJTzYMyicK4MNsixIXFIqrHtCgx9yUrXl5uDLcJ6XhuJ5
TiqwytcG6KHJFiQydz3jWRBYS5I/CF5uDMeFUvy8DTnGxpVY8F4QWSbR5kV6qsWyJHx9wUmFO5+R
5bgr9eIjTznHxDK1wLsgWntXHxSLkexeDHXb34WSr3CmOEqX5EZInvPjT7ODcFGh7Z5muKqrHtXx
8ddvNhzq9XLvi58YN/DIt0UKGtiHRxd1jWLwY6/IVDSHEUEpw3NviIyROcdUJs6NeKBDXDpCOMq5
HsiRcfdFKj5LnOFLcNW3puMic8zu9ssa5MJp7Up2uKqrGsiRcfdlIhZCvUMtwnN1Cfiaa8q93bAX
RgJItCGRS5FsCRcfdSCo8yucOU4bkupHA0t5cQmyitzhQ9mSQ3urkacWPi253I8qq4ZnMd9Yl7Fk
vIvPbGW8gLCTzGxSbqvRMjTTAT6rLwp1I4ZnCVtlKw0oj8R2DmSmNNMlOzfdY8gjMdMmOaQj1wZF
3SVLxZB8bIczGnlPxxZaY+QTGvLi+ZjnOzZXKMEhMcQ7M7vLGeQXHNkixSe4mvIrostGv5tc3dyj
hynIVpR5ywUQx8fGOJFIu7GvJi10tqE3Y5qclbVSCoaKUONwcKRIQtXKAz4UblcqV0giFa4OL79U
wQXFX6FK4GE8Dm7rgKg8lsmtkxUb75GhPkYWjkix26OCFxVSgkKw8Msd8SsJKz9MyslVMiJkWK6V
jdOHVptPSRMI1wlR2K7N8bkWvJLybTnhNiQnSsTTBsLpk40IBRFh05JmSNNGGxWKiwqUspP0sbaX
RGiJEgPlO/ShHIfTBgt8d/dBpshWu0ubJleSE6HRFlJ+lC5YUJobERd4sN8h5dOFZH4L3YFKSVkj
TBx4Yasf0X0fno/3z8E+Dru7IUZxnCo/t+HvMNQ8Qihq6StLsyNT88dRN2dSN4sqOTptMomwq3vO
sKjsNhxu+QtNsyRGUbnJti9E9um3rTBDV7q6h7jZFIjElRFG+uq3SHfQ04Ta1RYCE4pI9AnGdUcE
JHcj6+lc9hqZEbKiKJ1dUrJclAxqT69RYCI4xQUCcZtPwQkRzX19JzYSia1kqAonV1W6WRtGxGTK
1RKKG4pI9C1Em1HFpY7mOrqRSjPSN4S4DgrX1b5T20I0bPq+04MN5jgoGNbMo0a0kZzX11D3GGo2
IOZCULq2rfLVtCzafWqJAwnFMCgY1kylRqGjOaStoUIwtGxGTq9Qq5my5tkWI+Q8GnxjZOpkahIj
0LX0SPaSjHtPgOA+sqHy3pQgRLCo7WR4JDnjUImtm0ibFiuaStoUVDUY+M+vWM6sp3SXJSBRtlTq
HIkB8k0WjGJs2l/aSI9hK2k3YamYrJ1c6O+ppnHeyoFtZU6hyFXumFj0YRMn0bVa6C9DV1IiMNTM
cOwrXAfU0ymX6QLja1CiyvrllEj1Axjn0TXNfCI2TW0bWMPUjIywrXxiVFN3HLVjVtpSKzK+sfJL
HqhjHYUbSDlRVjvXoISvdUUvLErWcbqh45WVZDkj1bBNsqNhmLWF8mtp2jHIqRmZaVL4z6al3X6a
xUuaHKyocV8etYMdlRDOIdURJFZVJHaesGZLWmJHPUU37FgsVLyg/bUVTzuBAaBlnSikiZUFSXW1
jY7DV4ztt6R8Y1LSoiLCFve0CPynp3vIGEIA7CmFLElMRJdfWMjsJDCdlxRujHpqTZqAEmXtC0za
ekUzxRQxmz6gE4H0R7ZkCsHEDbyo7Bm/eWjqVmPjUrAxtWxWxpm/RMbmm61D4doI+agrBGj0UbyJ
CRBQgvCGeCXD8ezpqpg43cjvJquvZFdpStSTkgoISW1eKWyDWsjw/wBQRWyzxGTINZHDGPLvY0TI
J2T2aqgNERtfIfi1khMcNWLXQHSn0tMMDdWiRIul6xixri/bUZUzEtkt6NpZQY7K0UK2DOLfUSBP
V2II0RNUlJKKxJMKtWJElz9U+FlTMW0SwFGgS5t6GCyqvT2OXsKO9sC2iAgh1NIPLMxsmDKgqttQ
07QZLE1kWsq/LsX8KkFZcjsH6rokj5+ExcTFX0Li5+CfBk92/wB2nqxHMs3siAizEdZCa2TFBSoy
XPIkYFHMQ7pz+20U39sHiZ8qG0o4lb2SXw0UMU3iyoRmSwXlegsMmznf0E6flPnTlekkhOMMcWQ2
Y6fVNe+PDSMNZzWvmw2mbAq2jyQdI6ia2aFKlrpRUbGZGkNlOnViEfGgtjC8xrSS4TThr6xo8kSU
Ao0bLF9Ka+UVqR2R5KHJPrUJkWE2KHykY+TDQ44NW0anIgFEjZY/pLXyyNQLI8lsh1jWo9Y0NsYb
pTWPkw2nFXVbRJIMkfB8ZYfpLVkqxAMDIack6saRY8NscSyUY6TDaUUGraNxnIBRI2YN1Q18lw+y
IB2nJb1/7JQ+D1zbNO1rWxzEQOD2ljdVtU7hIBkcyGfNrUI6NCaAanRhJERphw61g3GIkdQIkpi1
jVkvYgGgOkh8+tQuAhoEXko0kiI0woNa0KySoDA8ZQXVjFkEH47Ipu+s2uaTAQ0CFZXAp4iGHCrW
jWQTs4FEONa1qyCj7DIp++6dXtJgYiBD5vE54rShgwGsSbJ8XI+0kX01vkmb444UnyFmwEfgonaF
5zklFjtKGFXtYk6R42Rf5A9SREY13SnF3pIYqBB5qpILH7oYMBrVnmcEkLaUJtcjpUzaMOukOO6f
DQmMjIACzSeU+P3QQIDGJZncEsL+SJK9vm2H8cdRIId06E12NjoKOkkvnOB3Y9dCRqWpntfX7nAk
FizbVPHDRvK9bGI16NA0EVpjeeoENGrIjUS8UnkVW5gtht8+45ABRuNvZRWuagOzFRSundpCQ6uM
xmXqFJIpkVY/iMWdaRVdGPpbuZZVZIDqGyFGWFJ8iNrT3mdEyOzmTTEXtC1IBeL7t/Y0xDRxbYCE
ivnkqjxWefYV8fhC1B3IUiXYLZZpWJ2B6qhoUcK0d3Ipe7EfQDfLV3jwbGS91hU1RJGOIKtANVvJ
LYUeuE08GS27pRmWmqUiRxmJ3dVAcSJpkqsFcUzbFayKkDHE7sjUQuQaWuWEmpvaHEE6S6opkiju
bpkYZCLKl12n2nDXxkg5qyX3zVVY6UQIR14L+8WU+HFcd9ZVthsvb5scdJUdxHuUZDo50HT4XMka
lF3gVNf4AdYptA67Z+V6u+FXoVPaR8tT301/papX9jlVrtNye6xWIg9SHVU0t7Nlt3S2egB6bO4r
Cy+1kd7Stv0+2b/JpP8AeHUDdwSE/c759K9Uzbdc0Ym4LEaPytFxkk/uKn2iR/5G32gonGeL3rU4
gan3JrOeQQ8JBk3UifZKH+QifaGntOCjsrU4han75rN8hC4yn4Rv2zB+81NghT9s4aLla3ZjW/cm
t5NhD4yCJvjm7hML7w03CJuyThouVzOLEb++czdIY+JyN3xW7iMNO8z9wgNTLBnvWJxbx/fOZu2I
LgewbuCyHsVzdsYm7qJv8SaNFysZs1WbEsGftjM4lIn7VanYKP7wU3EJqK+eNN61OKKn75qJwisR
DERNnN+w8ad4KfYjN/dPH+6sYjW7fdsm7pEbsWS39jm/xiC5GF/gjJus9E7lWzNtj2aIjYTE7stn
7CN/jPG3vCbvHiN/bPa1S1aJx2Tv2jU4wGIh5fwbbxla3uDT+NDbuOe1vOqb9vVSb45vvmn/APcK
n8dUahGJ/Ght2DYIimqNlENP5VsibV/HyJqZI/11ViEYiJHhL9mwVqGqdlANP5dr7JXK1Tzv2tOn
8dFZ3Gp/Hg+w56p5VQvIKf71sv7a17HSrBP2SPaIN7Eexf41en2rFyJLp3cgN97G8XZlYVpJE937
DL/FEdqOF/q1v9liVBT6d6EH/wD9C7meHHqbhtkuooLXw4ntJpP9LWPvJ+M/OR39l2mJXdDq6X44
Xk5O0xOfyuCdqFOkrJkVUlQzIBlfC1ROc6U1/B+lZDii1hMeCNUN704IEDC/Uch1oje7WgpVPYlK
KtHbWj5pNIN2zVe3hRDEFiXUh5IeqozYlbbRpz76UwIqEbCM1TbGhE02d8tj2okvUz1YClsPOHqL
7sWmpUAG4uGRmHUx3NATA2UqNmnSOksva9JsqMFlYK4uXy3CikOSpp2xxXV0gkIIxHU2q3Qcg6q8
05jfwqaZ5MjVD1ZEpZbpkbWC9yD1/G3o2xfn4wq4b3X86WMnjakF3WKFVfRQ+wJZKKl3E7jdNtVu
WJFQao6blJG8bLp3BlDYKXLv3jnTcumhKIOoSJ25C/udi9V9SfKJmkCowU9f2VXJSHIiK5yOC9z1
l77BE9NrRVyuRWgQiI+Y79lXz7hnomK/mIiEWZvwEMiLlkqtSv8AYXdRHzF5MreXMhETOe4yq9Zv
9oxPTLLdG1/sHupzl+465F7hHomc0UZOSym/sYEib2n9tfu0fdTnL9xV+/N70TEfyGRHrMa7gKMV
OVpuuQEVje8iPmO5DhNdynFTx7N25Hrg/wC6gOnZsuSpX/tY4yc5q82Qmu5mKmzSIoXNf5I3owUY
ydyfu5YH7EedvcnO5jhovI504oVHgVju+x6DBFOnOejnPgfbTyG96e7uMhtXlIOiN7yEjqxySBl4
BiyE3shue+t+01ZDe9YfdZCY5Hy5DVTvISO8T1M0vaBClIuT2OeSu+yzyG+RY/eZCE5hpklrcUyF
D47u93u2GHLRWzxq4tevjs1MZHqTEylejJPe78ZYr+64/ajwJiOZYge8lenjiZNb5c5PIZXAcM8+
ajV8juBJAe4pJKCjwJjXDso7jvgfxY457fNmp5Q6yK+MexnI1yH7ofpz0MaS0Ia2waQNnCdIJB/i
x22LfOmN8sVbCWIa0sWjRklJIFq3+TIlJHDVWTCMtK900sZfCCO0b9QmtSwBV1vgPtLNosFMbJB9
HVJUmW2MGotWESyrvOJFRIEaLYNLY3cbz4tDSEriagkN8OrqXSS1YOzF1PSvkFkh7L0xMjs7r9NR
0CLV8NZINlGul4u624+/FsQuiyaWP3pUJvCHquGrZUdnN+mo6AbrGN5MapegJkaQ00RdOsSf30BB
qFEVLqnWeWHp8I0Gg66fbAZZRomlxAzUEQEcQXcn6XgoNNQR0lRtPzGDS6oWWha0P01tpc9maCQO
3jBgigZJvGnnCRCVy6W5yX00ccesDEfIm6WGYsEf07I0xkubawfOHC0uONkyEAL2N51zdMp331cZ
saczsT9KQFM87P4pjEorCKQdvG8Qdc3UN6spc39G/VfbN/f5x+H+d80/beM7myUBzGNsByGihfW1
WwLIYeNWtaEktWkaEQhIyQxhL+Q3s6ZkcXXUpihhIhZYyjjit7bvuI73VcX1fHoTKqcsV0OwZLGr
xgSxt+Lq22QyfaywtEC2Jd/dYUZ2yZbQMJcuQ0SaySNXjAywtVR9fao/EcPJ9ijGxrj7rCjkNkS2
BaS3+7CnskscRgksLXhldbo9UeLJ1jwbFuvvNMI7TS2Cae52LCsGSWqUYksLTg6utkevMWTLBBJH
uuMlhhnYeY0bT2+xIdgyQNxWDSdacMrbdCZzZkueg0BcI2QKQwrTSkE2RcbEh2TJLFKxiWlpwbIJ
zcuJ7LS23YUMhhmGlNGkm3+7CsWSBqVrcsLVGLV26Pb32cJc9BNjXG0gchhWnltG01v96JYNkMeZ
rcsLVG5V26K3ut2m2SBbDutislMI08xo2yLhUPDsmShqdESytcqrhHJ3mZPskE2HdqM7ZTSNkzmA
Ga4XvwbNkkayGtSwtv31VshM8hFSxtEElfdqI7JbS5LntCx1w/vwrNsphJKMSytubqq554khNrO2
QbYFyoiBmtKydYNjts5qyXuxFwBVG6ouuaIfLW4/bXXLhEBNQrZ9o0DVtSIersklDPYNEOytnSCV
l1vnlt2trvfK+2cIgJ7His7doUSxJ5FbbNOOVYsCGytXnLT3S46yY1Le57i19o6MWPaDIO0u2Nb5
r0NVXTHil3YxhsLBZJKi4UGOuY7WW1ysjIFm+KSJeAcK2vUcjZj2krL4aMl6hCwc2f3y1FwsfP1H
E42dw6W6HPdGNF1GBA2moe82JZOAcGpovaXUsVmW9x5mU9xGiM/VsXJupohGzjd8n4yKXtEhasAA
djqkUtj3I4tRqFkBDazG9LCUks9XY+ARNbN43F19RbFKoCxNXOCOdqp8lnc3JXamLAx2uHuybqB8
tldqQte39alx+uSqki5fKNH1dJAMmspDmWFk6c9ruKwtUyITDawkEYK0IE36ymYfVkozXyHFfBup
MB0rUsuSjZCoQOq5oB/q+euP1XOI1lgYZP1fPahdTzToCwMAn6qn7fqqcuSL2UZBalmAD+qZ+xdR
zStIRXvh2R4T3almKw8t8l0e0kxFPfTDNevJVzbr89d8+MX36Pw/92Derci25woswji/WJDh953d
baSO2K1MDPrkrFu5C59RkKsmwNKQElY+GspB0EdwnPtTlY5cd1X46J6V6NXbIlgSPi3Mg2Ge5yhk
qBUupPGRJIbEercFbGDhrEp0VV3DYPFjriQ9pCuJgzuG5lvJahZRDZyVFHaHChLKSfHOduGc8OfX
CvaaSpVHKUWCvDtQ8whsaTZQWhxYSzKXCP8A3BnODn1syoeQpFZIcxw7kzUkTnnzmu4bMwsLZlKj
iOVQzSBz6xIVpyvJgzuGo7yQxp55DZ3FRY9uUOEtynR5FcsecQOOuTuachC45cVc3wb+Cxrc4MNa
mMjyquR5pA4t1Ic0p3EcKU4bm3Z2skTySM7nFY9uYOGszGRxd8jzyAV10Z6FO57hyXDeO7kIkma8
uITAWpw4azIdHGXcE4gHOuDvQxVc5h3MVl5J4nlvLncXI9ocLT2Jj4plyPMLHV9tKIjzq5RSFY5t
xJch5LyK167jsJIkNNOTFKqrHlmBj7KU5CFVyiK5qpYTFaaQ9yteu4p8saHlHKjn74vRPZRFVi+X
Ldhe7iP2wcmTsRZL0VcCcjVV0xyE5YMi41ZbsM0qKNr3K0E9uFHJRGcnOZDlLjok1qF5NVpds8h2
OfnPBI9yvhymo1qvc2tlOx1XPahGPE4QnnV9VKYhGuHiOwUQxsNHOHARCysbp+c7P0/OyRXnjYCr
OfF07MXDQDx8BTyZDf03Lx+m5jEMEkdWbkxlNIM0oSR3hivkY7TstrJIXxnb++2+J7Y1Mi1BZmSK
KUHF9nRYb5Ck02drTgfHIMLiqLTxTtm1Z4eN3VYlQSZkjTx46cP3xYDpCu00XjKikikAJ5Hh02U7
J9OaC1Gq7INEWW2TpswWPHwWDXPkuJpV/bmRiQSx47jkBpZ8hllSlgo1qudX0D5WS9LnE0jFG6DW
EmK7ST+E+CWDIjR3HeDSpCttac0DGsVxK/TxJjZmlzBY4TmOrqokxTaOejZ8F8AsSG+UQOknGFaU
Ra9omKVYOmnyWTtJkCwrFGq/0He+O6OyR8/ORAOK+LRfZlw2jktpUcE8FWyRUnIUWoR5HUbWolOx
U+kfdlUezI1b3jy6XshDH5y/ozXClwlC5zdvVt0/OJ0+MRcrYSzChomoywqEFiA5FhUf25lOiMmA
7S1NSpkWmbwnwOwsGEsowqNrWz6vt5Bo+SfSBpkio/bGqFIVtMFjXVDFSwr+0rk2XN891Wop3ylm
0qBFBqVkEbTDa11MxyWFUoMq6TuI6kH259cocZHc8kHT32LOB42U1Shx/RxNx9cBMkQUeSNRDYxa
sK5Op1a2BRIrfpYm5Jp0VkakUpWU4Ro6qY/Eo0cdtMFjUrBKs2nawU0PB64mQ4bpRIlEIbZdOnCT
CcMlbSbo6nHwsaxQLW06yFHTD2sqjhgoLzSItKwbJtO1WHgOG+rpUUZKhitsaxQuqad0lyVI8sqb
ikWsIc0anGNk2mRzTQnsNWUjWMJUsIllWOAtPTd3PpY9rGlRuQq15jR6tgxzqlCMNXlbJraZBsPV
MKy0q/Hyur3SSxqFqAuYXYfV1zpTo1YwbJ9O0jHVhPJq6ZomGrBkSyqXBfT02Or2uba0nHKuqfIK
GuYMdhTNKyZDdFI7omVULySR6lAin04jCPC7UuoqERh4CPbc1yRXUNU0mOgoNLyoZ26aH5B49agB
zaoRR1dGiYoVHj4DTDWpGKYKOg2NjIbL+mG0at2X3xUwQe66ioeSz6lBxKuqQ07w0jMGxJC3tI1y
U9I0LewNcvqJrxQIDjyKiia0OrISAHpAYyJI7A2xO3JW6gNRkUMcIWHjPJMrWFFVCCIEiVGE6GMU
lmrojQlo6dTui1IxR9SREWzqadscPcApNQUTZIijUb2+2bZSVnmEDFHAENRTWXWn+Eqpp2xwslgc
W/pGyw0FDhjhhJKhDsI0fTytsRiZXCjGDYMutO8ZdXVNhhbZifIu6ZJYqOkyTZCr2yIo7GNE085s
5WsrAwJ4rMV7pv8AlV1YyBHS7G6XeUiTg6foe0k+4FWuUA7WLE07xsHuZUhr7VloO703vLgVyQI7
NQCJNuahk+PRULQMn3o695BstIkLTrUspJh1IKm1bagudOosyNASvBG1CM8y8pUsQUlG2MGxvmV5
XAbZw63TqDnzZbKgVVZttBavpPG6r6dsXHJm2OT2kpiJmmK9DZMVsIBp3fnV5UkRnUyEkSGpHBVT
O7OkuVogy1aseQ0x1jNIJlW1km0FtGM7sy6Wa2Wy4rEQcpvF6/0U6om+aRioseS/sZOkiKCsB3bX
toMJZbMs2IQ1THRkM8jtLbPaRmmIqcZH2cIdhsCxrRSDkaViI8B5LIryWm6wHL2rpiPwNE4+Lp32
mVKhyqp1O+BEaJLQSdupAiMnvUSV73FHJiNMRQoFg5PItlAa8FdGGM0NrXC1KNEHp/2jzyuYhJp0
yqMso5W8RxSPcc4muawSIyQV7DMTuCAFo1nuViVqq9s7+OpbhrWVlksg81U7Fov3XY1M01Xt7JnI
HI20lhqprzuCgWBP3CTq9CsjQkAIh+298ZDBiVjWEkL2Mir5IiVjVkPD2GRi9wkyvQjY8NAjfI7b
yR0OKLXoxx3djI20ljq1vkEH2WRZHdfNr0IgIaBESRwI+MhhxK9rXS3dhYyJIa6uTvlYgBxD94lv
BRQ0ydgkbioNTMRDUUNEBLL2XQ/5LPp6eTIakccM3dWdC3wcZBBWUqSSRUKKFXI3J5XBfERJItSR
OOO+canvpaHuSePtBPYI1BC8ydGicYs2X462clJTtNw+Ma1coHWVg1wtMwtzzw8IpLHbKt7SRrOI
Uh64TmR7ia2OdlkawWpGoEuDIXIVGxieADLKhGZtJRqqw2JHyzTnDovtzbaN5gaGrdCLOXk4jO1F
A4vmlAhIbXjh21LNaYWtF3FX2ZK9H2EifmmYixl1BORoI9ieeSFRjYaU7sxrC4kjlRxEsSVqeJEn
BS2lgheCKIXuBs46rcSh9uFHjF89wkfDt2duftjU3zRQUcmoGqo6GO6Oa0AjllD4QY0N6yu3vBqh
tQdxFdKn0rFQAGJ9U1IzllJCWGW2YmSU4wo1WvlIz/r6hidu4hLMsaMXbCBn/ZalD5DaOH4ZbduS
m/wYdb97besqU2i2ld5llRDQQxNT6pqUPeSor0gut9ucpONdX1jUPt/1lU3aNYVqTLOmHwEBn/Z6
mAhh1EBK5bln75yfwKyqGN5P/Mrf9KZXMl2lUPiKG3/s9SgQ46mIkQ2ufau9G/Rc36LnyrviViZo
z/W1I3cBM0xK3cJqKPUBFQen/wBksiJ27P8AYzT5nlOWR22RJDC5cLuCf/n0mu57b90Wan339dv6
Ivd2mkTs2SJ2ZxlQunHJ3nInauX9t0EnekV+ygu9kQshVfp1E7Vjt2jSHCmQd+yfgjk/x3THEdV1
SDSRJQDYpvNmEYgW/UA9yWo5OQRNYwX98wfIcJP3ydlSMqK3/wDqSG/sYNPKkf4LEzo56g6ljahT
cdPMQTDGTPGQiMhdiSv+Jm3M6bMB/abjzb/YWZ2jvlNK2Hl7/YOO6UWBDbEDPn8GTS8iL85pr3iz
2plYmOT90tv2ozU7703YjdwSWIpIqfZjs+5YMTesbxxzfuT2JwAxO6VPtIn8c7NzRkTsR2pzsERH
VTdlcn3bBicIjU75f7OP8c7U7sb/AF4zP3WDf31KImOT71iiI2E1ENaJ/HdJcKbVEV0XUv8AfQe8
ec1FJToiNRqeRa7bQdu/MT2Mn8ZUb3hp/Fhe456J3afZR6oTCJ+7B/OlHI5LNyeJcG2PQFR0qIqe
PqQqMcI25tPOTx9Ska1hzbv0oRqttHt8KabnMo+SRp8kQjRX8g3sN55FXWtjss7FsRldIWdYlZ2I
svUZo8l96AqU0pPHafuklJ/FiC5TbU7IwqiwFMfMF9yV7RmFa0pPaHbu2sNKf62sf8LEzT1ShMny
GVorOyfKJX2DYhKy9FIfMDziSR87SpqmhBe3XjZpyxahfqQjJCVqhsHN8+cu0OPPapd/4t372K43
NGL+3UZO22mMhpNm/Ji/wYk9qmVdodXsobOwSJaU5UUIF3tNUP7A6eR5RrZ6ZLX+BAsOclXbQqdU
UVnP8S5pX8wBen1PVT1HHopXlPuHpk3/AEKuc9x3P4wap24LaY+JcUrt2Ae36pqsjxBpJrpi25Uy
Yv8A19VOK6Q4ifTqon8O2mmhXVQ7+NEKn1XV5CMj0El8rLYyc7Fd4dHMOpTERtfWvT6fayTx7usf
tFgO/wC11a4iRtPnfJzXBP8Art/ZV9CdNsdi9Hrkj5zRh+IbxndCeMrCafhdlPLazLQKHHTx1HOk
79lyEkOq4XjGs/aPT2K+VOdyi2H+xpkCidalRsaY7cjui4no/HoRds0Wruza79qYv3dPud9QIv2L
nfuMVWvqVXw77fYvzpNzlZa78H7+fE/17RS9+N/rLDaUh/sskMNLfTwnRTzPcUmK98jx5EfA3agy
puEmllP3DBXLRVRlK96se5GuM7mKIx3lSSI0VpyMajGqRrsavQcYr1c2ULKLuqNyJ3JX+KK4qzH+
7G7duyUqGiruC6XZ4yS1Wo7jA3JUUdANCkmfZFZSnPeR2+L002dEDPRXpBTghJCI6S7uCijVpCGR
rByEcE4nLJC/tijyPuWCc8gp2sJJTuSn90UcateY/EYzcgPY7yBE7YY8lO5YNV6wPtK6UiFmO7oo
YnNeeSiI2TyEQSqQZu0CNMTnOYpHwPs46U3vTV7w4gVY+1l/Y8ckiZUjcyPqGKQuUJuIJY1e+v8A
sN81qSpn32QxKMs2Ztnkd0PjO7yn7UeBMRzJ4nFLXL4wdSHQjn/3bYzNIhJztWL4dsjmSqUDyyYz
FSJqgT0eBikLp0ThR9Uhc5rv7tJxn9y3C5Yktrg2NO9Fh3teSSSpEsaN2Eky50dRh+imkmj1jYUg
38iNK01IJMNRsjiWaeK+gPKlEl7+HVuUUu9jLNDpysfXPtJbRYyU2QD6ZxmWcxoo/i/VJWn4XiB1
PWLOSVCdXn01x8PWT1Ra5vdf9ADJBXaX8KTMOg4olR92JUSDfE/mtIqZWfePUs7UO8Tx5kexbOjC
p2Nk2tsOIGeXvSN8bmnLZIjpCDshQYra1tneIpYNiydHZUiHItrhsdlFdI/JdcGfkiSyviR9Rf8A
YkUdkKNGHXpZ33I1dbMnASsEw9xeJDHp+8RVlV4JuS5rK2LH1Go7LkOxAIAa0dvqFxD1Vy2xj/Tx
iJcagSMmn9QfvLADLybPbWhDqIg7ELx2oHDFXMs9QEKapumTQ+CEZbm78XKC/VjiwBS22loOtjRt
RFZOjPFaif2q4FnfvknqLptiJYQgFur9Rv05eua58QUllvaMghiX5xzIrgWg5hB1ke8t3WL+q+p3
zi/B+lPYrEJHntlgtGtbIgyWMj2FyrZsaawgI6sbJMdqjA0bcdMYw1rOZ41NIRljLmMWHv350QjA
At7hX49/uq4vX5zb1tTddPPYAU47CCsfYmnOLSeSxRXeyvhtR8mDJYgbgjXskL9yheMIZh2uHN/Z
Kq7JjhPQZcJMaNkKc1cM9hEEgx5IOwRBS2GHwYj7B7OMtf36bcwCFksUQZqCOpWFxpWCSfZo3K+2
aVnea1tjaIxK5WlJEM1g5r2vZHIMZlaJyMM0LT2aMcGawwkc1qyZ7Wth2LX49zHKSa1jZUhppEVr
OJZKDbaWPcWhltClpMRRzH7vdi4ntlTaLHfGmsOwspBtmW/7622acZTtTLC1QaV1ynJJDHJLsEG0
FwrTgnMOwstBtl2y92BatMNxkTLC34ZV3Xv32vyfYoFsa3VpgzWGYeWgkk3C92BZtOJx0ZlnbZWX
W+d9u0+zaJkW4cw4JrTskzUC2TdcSV1o043yeKW9srspSK7I8xWMsSq9BWPiHFMQzZU9ANJbv8iB
aNOw0vg2xtnOyou+WJJTLS34JAuXxzBnoVk2zZHbPmqd7nb584z2XTshWMmTu6K5VrzafLscVg1A
3shH5BVGmrZrRCupzSCOqd+gkoMcyzY8NoRCGo7nZnkjeh7ZgBV1yiy1shFaycAeWVsNqwLgZgun
x0y0vh9shFc/T84AEkX8dw3XTRSxXMZzfrEUaW1wshae67T36gjIlrbOlOpZYQFBfxBNk6hiES2k
Nkvqb5kaPeWqT3xSqB8HUgeLtSQsstReQ0Mjtn/VYmgnG8k2+VUxsQotYAYy3vWTm1l14Cv1aJ7b
KyfLcuJiLgiKmQNSuhtmapWS0x1e+st3wHE1fzbLnOkvjS3BILVpBjsbok3EL+6BqQ9e2Zqg8tqm
VXxbIkRztXmI2VKWUQJ3CUWqpYBTbcs1EdusTUEqCkrUMqW1X+8WaSNi6omlSQdTEEZw1ZqWcAc2
0NMRHKuRbiXByRey5aK/9wZbwY/UUx6FO4zxlVuDu5oRyZxpKIuygspEbD2kiQm/uGQ8WPuZT0K9
SvGRWY20ksaeWSTiYycaPhbI5Ud7r+fWvy5Ns3xfiR74uMVd4s6QHCyzFVlhIa0j3vI2fIY1k06Z
9Rlrn1GXjpR9yyzkRj3Mc6dJVvdcjvMk8Skc5Vxf6Hz1TEXAWJx59SlvQr3vUEl4VS2lrhpBS4j1
Y4FlJw06QTHqvIM8gs+pS3ocxC4OSQSjuJOFsjvxLAg8HcyVx1rI2JYEdg7Iw1+tS1Q08xMcquUB
jCX6vJTHznvcO3OzH3EpUPJcXAyXsX6pI4nO4uDlOErLiTj7iRj573uBbyW4+1kbFmPcoLYws+tS
HYaxITBznjwdzJVC2kh6Okqjg25xIWzkkQr91FIePHTZBENy3VerVyPYmDjrSSZpCryFNeFfrEly
GIR+MNwwVtIa08gxk7i8o9mYGEsJJmkI7ePIKzPqcxyGK9yiK5F8+YNpznKncVMDZlBhrQxkUqrg
JjwqtrJNh3uXBOcmebM4mcd+clRY8uU3DS5D8cRcjkkIjpk9UNzyOY7MZPnIhbGWmKRSOCWU1p5E
pc3VVB5TccSaqFc7k0itxsySTDd/Ecu4lm5IU6NV3uufGJgZRG4iTjIYRmYIisUTpZsNElpm6tcE
p3Y6DMehWOGrHuxkeYVJEcw8jBKbPpU/YsKWHG81eOrnPR1VOHhUKJe5uvdXFevQIHlx9ZKE0Y3P
UdFKKhKCWJCheFY8R51Jp+UPCjeJW77xqwslJMIkTI1aSYn6bkZ+lZOHqTRcjUhpbf0rJTJVeWJk
StJMxdLyMkackAZsrVRds5ZGC6S9dMH4S45YZHe/oG1VyLQklNmadPFHsqZBq3S8LpMvGSB8QkaO
6Q5ml3GZY1Bq/BjVyw9POltl6ZJHZx2WBUul4bSHFsqISGWJEdIcPSndHZUpK/Gic90LTj5Q52ly
xxcVR1dTkl4fRy8JcEkMkGE+UQek0eO2oS1+BCpHV+l3SWWGlnBa4LmOq6MkvC6MRUsID4EiBXPl
kHpDkO50+WtSOBTug6W8gdlpRwQIFyOq9PkmNPo32nQXwZNXVumEbpJqivKMlelBQ/U22Okewxfb
HLvievbo/wB8+cXJKL0ix3FfWUn2rWCkdYdM0g7CvUR4VJzEysYh/ojOKVLFwtQndLRN7TqtUlEp
EQBwbSYtU0gLCrUOEZwVff8AoJ036MTktPSqVv0dnCfWKNYFY6QUNKxqT6ZUTwXOLBpGMHIqGqyZ
Acx9XR9zPo4+NhVqzIVUskg6UbGzqnZvgPcSFSNGKRUpwmQXMfU0vPFqWcbGr7eQax8gw6gaJOqf
Z0J6lh0jWMkVCOZMr1GSrpOWfSh8LGsUeQat0goacbEnVXt9PI80GmaMUmqarJsBw1qqP2dVMVs+
q7eQKl0ggqkaZOqNk+mvIaFSMEORUNVs+vUb6ij/AGOqmK2yq+GFFwXb3xuUdN3WfSW8LWrQK1dd
5ZRVA2jsKtvDxN5FfTsGKTUteyfD7JKenR6Oq0Vh6VCFDUsCPxGvyfTNc2vphBZ4jEWTVIQdjF8c
i7579IMR8slfRIwVrVI0ldToJnYTJVShBtpVdMBWsG2XVNIxtNtKDFYNqA7uWNGxyQK0YGJH3dMq
WlGyhV8mPBQbJ1W0rItIvlMg9hjYndy3p2tYGI4pqai4su6vtjrqhZBwxEEOfUtMOyguiP608FJJ
I9b2hzq0ZWFhcJtVUo0RoLHNva9scunqxDtfBRiXVWJ46OF3jirUCOXXjOyqomswgUC5YDTDSrEG
d4zWNEBps1DUs7KifugTLjmObkeM4y0NEu1pUtDGpqtCSTxRxkAwUnLumR6VdM2OLgLL2kR7Kuv8
iRV0bGA1fDaJNIwmGDYNBFxbSFivHOkeCKLGFNikPPq2mBT1LGCl2ESMcMdkmPqWv7MxKmW9Fq5T
ErCNFKrmDPH1jXk8lU6J8tzT9R5akaOsEHhNFZ6eRJkGvbXgFZCknvaFp2UVIjGSbMUV82EyxjVm
nGtmyCiqQwpA7UVrptvmxK9tdHi3I5Eq8o2yWUdG0YpVuOKWRDZaRa7Tfbmz5LKkFbKZahs9Ot84
cJtdHhXw5Ey9o2yx0dK2OCwu2QykiMtYdVp1Gy5sxlUOolttw2unWJOWI2tjV+oGy5t5RNmipqds
eLN1C2NJNFZZQqrTzWTbSxHUDqJn1cM+iYk+QFtUCtvvMl3tIyW2orGxYcvUCx5hogrGFUsfX29k
HvRLGhNExU9/j1bdVxUxclr00pE8ghWNixrWf5EmhmtMGRVNO97UihZO7lq5VUXkEG9kxCyAjR4j
VqOPLBwi2qcJlDYd5bKE0gLAXAz02/oonWjj+TObHSOBk370yIwrYVe0LTyey8SJKEKtb5En7LYZ
vIWTWtKXsdgLZn3pUVphQ4DQDPIULxNSQINa1p5S9lsI/lOkV7SE7XZH5a92TEaUUOA0LTn7Thoh
whrmoeR9psQvfWTXtebsIEbJH3JMZDDiQGiYc3aUY0kCDWo0p/tJEN5GSq9pCdhBCZI+7KiNKyLD
aJhjdlzGJJEGvRpZH2Uhv8jJVc0pex2Rtk/dmREIC0jdsq9AMV5qeNsCUXs5bmQrNNxt2yWdhsyS
1zIAe9YCj8QSJSMyeiFk00T7UsnYcErCkOz7Ufu92WxO06wGHIkoslzyoo5MDypA6KO1pqUPE9K7
vVNU2MyENNrgaLIjMRQmQ3dGnIAIqKSY7sZD/kstGJGVLZH5WqRqWclrWBs2LgfIIRG/x48blk0n
YdC/lD8dozy2qoq4B2yLeMjgQadBvr2dvNRN5spYewbB6jyEnkj1LERuKnRibrpOF++ePtx5VkiJ
FZ5s6HFRIk6X4r7CQkoumoaDi3DljvsLPm3S0Rqnsg8IxLPtuqydwFpA754A+1EurDxDDkHsSVov
EbayElPg03aY6PyS0pBGHR0PtGZ462yK+HSbiPcQmTR0Na2I+bs4slnaiRmkSXLEjoQpI4VnSTUk
A1uvtpEjWxruOGbhNMhVKqCSumn+/FjUoBS57+0GtJuydUBkyowvHhlg/Upg6rsjWu7iXtMkWTp9
P4k8IzEvtOqzNtlxmaRYnj6lH3VoYqxzWI0Qtqm8GvhKMspqLEr0/hza1JU+oGjIsJv/AGGpY/kp
QxPEkWifetm7wayv7WSW/wASuTavlVaSrSnYg4cFN7LU0bynUUXxpNmn3blu8WvgIHJifw4Cf9UW
Ckmzp2okKuT/ALbUcZp3UkRIcu22716n8atgMCyZ/qwk2qHwWHtatP8Ar6z2ttQxmSHUoEBNnt+9
ftRR1UMYgT0+1G/8ZkEciygf+aNP+9nyvEjj7dzE1DTrXFT+gvt0VMXJXTRa/vt/9aV7H04VWEif
vHeKrWQEVLZu3YsHtRlYR7rNDKMMSc0j57kdHuU+/p1f+wkp/Gt/85MVM+P6KZpP/wBUqfY7aeYq
chjT9s4abQU2C3+6c3daxqI9f7jp9tzE8rb7Y0/ZPaiJCTYA095rEyt2R7k3cb/G9qeSn+NjU4zm
ptEb9oSbOnImV/yqfuM37aonlN/xs/tnIiZD9hDTd05iZWptj/75CfZRqeT/AP02J+2a1N4KcWCT
d1ixEyuRMftvIT7LGp5L0/jXqbEJ0rFRJNN/hvPiVJVr9Ou5jsl+zZmURKEvI43J4t29RuiSN5FR
7Cv3e1QRz5Cv3EL/ACT/APXZXLJOITQjsbDg2mZ5Ap5mxUZbBMouHeE8bWQn8suGfdiJxGV6d5n+
KIn77FEV9Tsi34u5lbVoHClQLLSz7qxDo0sAjFxP8MJPax27lR8W8jxiCsxnZXvY4ll/jjnYNsQ3
Mty37NWn2bBPuVCbi1V749vHo350m9rm2j2+JcSPv6eK1p4r/wCHqeQjSRifyNPkaotUlRMOTmXS
Z2Py2KiRJkjuzaRjuxPngjlik7se4r3SpcGA2IO0tUitpSeVMlfYhSb40eWt+E+VU5rQDP3CTv3R
q4aklW0xkRlNYtnLKH92xT+GI6d+Z/q2/tY6WT+HrT3yruHV7U1g3KWd9UyTDTvSV8SDDvPIlzw7
irRcB2F66PMgu8iHACiSriSOOg7oA0ubVkpaJNoUiU5lrbR2rEns4TU9sZmktuxqYvYJRn7xrJyO
Nar/AAKyepllORI1YqOiTJ/i2Fa/+JBenn6rK+MtBI75bEid64/0KqW8qy3okatc10CVNLHta0nG
FXkb9S1cQkdNNnccliRvdu3bw6OUUyziNbHrnI6umSix7qtfwhVxWpZ6wIUTdOGIc1oVO9eL3IdE
eQ580zexAIj6mQ+SG7gr26+uMiWOrkP29Ove5Zh072ot3xNPKdWWBm8IbudSqyxX0de3XxV7t3qX
dIGk0XNeL/H2xem+b7Zv1VcXp85JxfnSR0GacvkR7CMoy6agbN8tsfJaJKH4qis+K+KdhCnjQO0c
3+sCcQdqR/MNx/sadiqsqWVGRrUnI71916behE9vRp0qBsu6hQtERZ7yIwYTNelix78ifaCyQ3nM
/e2sG5mFOjXqVCC7LllOKjGCOipYCcRQfbC2SiOmLzbWCcNCnRrlL3RMC9ZjjIjRnR2TxuIoPtiZ
JbymLzbXDUTXnRHKXuDQT1kqRGtHIR2TROIoF7Y2yUR0xVe2vYrGkOjVeXuCEBySu5xYKSi5NY4j
gP7bGSkR01ylbAGomkkoiuL3BCC5sgp0aG7fyK/pH3UtHv4961yNk/5NLI5GWnLs2SL3KFrlnJv4
t6ju4FFU9KjuxqFjttPLtIk/uFHEZkwqooRRcmtI1FqHPynH2G3IHGQVIRqnRYbgagIq00lxUtXq
j470WPNiHdJiftjBlIhZzFK6GvYQq98jovFkyGeUSRRNTGUTFSLSyASAfsiR5KI6aHuugr4zdQSe
eCpZEjKWA6CtvN2G69O1aCUaRlwruxVyuLZYlM+GvjC1FKR2E+ca330mByPt2cotsJRSKGM4smOx
UiamjO5Q28jadAo4+qwOexGry0jGVmW4FWFJaoLGnOjoNtWeaSuZ40UQ2yJdnF+2Kgc94K9sM53o
eMfTqEkyqpoBOkkCXTXcOae3lDqX+Oa5iJYjoq36dlnOaMjZiSQjr0Ge5s2hBHittJNFESNH1HXt
m5WVnbLK06AzaWA2vSXNakmQ9sqHEpBR5VlNQQa2YxwJ1IKTLjqkSNAsWulXsVlkkLTow5bgHGPS
EasI8AazLiWjIU53OXjFzT1146GQdi0farRTtRtfKgz2WEccEMd95qBAJSXqPwsCPKWzs2Vkev1E
qS1cOwG1Q1gZuoVfMrrRtgFIQgPvNQdtaG7/AGvhALlrbsgR67UL2Sm9uyCV46wE2/IaZVWjbISx
gxnXmonctP6gwkURUurlkAVfflZJA8VkGRIHVhmXhpEynt0sAlCGMtzfue7T19wxQMcy+u0htrrs
gJYChsRT54a6Oa4KeVTXDJ4jqGO67vSnXTl9wwqA7Oob1A5pqXtJmPBJax4K5dS2vnkxfTv6N8Xb
JGLkCU6M+tuGmFecESmljaC7tX86yyRwVON0hJje2x4+UmYxjzWLPF8j/tVsmLFsTISXXFGINvbY
UqvcvyuLm/8ARAVRPp7j2SYPjY2uyQrpWEDPEZJti1jXW7kNBtGkGWYxjZ9o7lW3G+JKZ27Cy4JD
ula8M4RkmT0Y1bd/eg2jDMLMaxJ1ps6uuEVfLG5s+z4ZDulQgJwjJMsGsR9wrTQrJhmGlNa2fau5
Vlzviy2cJ9mjMi3CoYM5hWy56Daty9Dw7NhmGltZlhbu51tujkWSzjPsuGQrhe6KawuS56Caty7v
QrNhhlltGk62/dXW6ORZLVSxs+DZh1I93v0rlRJNXMRo7eR3GSf3EpJaMZMloQds799CZAqyaihu
35XPRkmvmbCtz9xgJfjyY1ikkavVqmsUYkOya9pSc1cVqNZZNDI8jvNe/ZLmQNcjGRpqqbwZZylI
yBao5qn5YaegWPt+EqPYNOyVYNC2NcbyPN7o0flgdqDgzhFTntkuyQI2XPCTGnNOOdZNA2RYd80D
3YSW0LLa1cbGm/fRy+A7CwR4m2fYkAsGkZYW7RNnTFO5eg/ZdPSmMHMsWEHbER5NPGahWWomhu5j
SLBeg5NbZBEK5sRqMpE71FPCwUy3A8NgdpCUt2jRJZRXJMuhBDXXzO+tzGIjbeKPLG+Yj4N+AonX
MRMs79qte/m6is48cZtSRijbedmQzUcNcfqGMxLG3WS+nu+wpdUR+3Y2TpS0llGh4zVcVrTaoivR
tyopLNVRHIXVkZGSLYhDwtVMEN2ro+1jerLStv8Aw8/VwNpup0lNjWjwGbrJqYXV7XJLsXSCwNWO
iBLrT2srp83FXfomDIrFh6qNEFN1CWc3uLvBuSQFNqs52HluM6PLcB36ultHNtCTMYZUdG1HJhsl
3x5bee+Q7I8RxdSzDNNIcVwZDx4mppjGSpxJSo/AXkiKki5kSs39wTCxVffySI8ykcwqsxl3LRsm
UWQ5jtsFZSIzS2Jzt5e45JQq6zkvRz+TmOVM+oyeJDvfnLlgphAoWWQ2NXGFczHTzOxSb4Mjs8mS
1CFeXGcs80+yzTLjncs/K+hOv5d7Yv8Ac72yQuO+U9silKxDFORBGkJhFIqjKZMR5sYabnemY551
Vxjri8t0JIVr91VppOz1Iqri++L136J0/O3Xf3EZWKOZKXCNK7FVWOZKO3HOkPa7duDkkbnflvwn
PdplG5sw7kf3nIm+7HymY58h2PRdw95uKSWuF5riGcNWWJkwkpxMQipg5pWY4xy47dFC4653pitJ
z3Y9zVZIlKhnEXE5K4JpQ8ISUTH7pgXSGop5jkLyXBd3ELNwymdikVqinnTCmkGa9VaoZZWL5Upz
SvVVD3kxp5jkP33YT5d0Y5W5GnysIeUrSPXePMMzElTHNkEeqikOEo5c1zZJDqiP2WNLl4U8tyPd
s6PLOmd+cqSJZN2TzNxp5zkfPkjx0pz1FLmqjpEtuGKr8E1Xq3zRYSebYckuMJOchzyM7m6g8veQ
knO6rFCeSTH+axDyzYIpd2pN2Oc6KhN3ADMVDNksxz3co6Si4YEzgTfI1eaQv0yc1T+ZHzm56hgT
StkhkBx69EzlglduOvnSGyYJxYxVTARJEjC1UoeK1w3AaQuLSTH4eOQDxI52BpZR2yK6RGWNBfJx
umzuQ9LIAghKZ4tPyCIWgljw4Sx3c87uyKTfpGiOk5IpTBECOp3C0wV6F0udiGjkA+LXklY/S5Ea
cLo5GNVVj0pJCTIT4WQahZqfpZcXS26Tax8HEeqZzxVxFyJXklLK08+KzfZ0GsdLUulV7bq8opEX
TneaulG7WdIWFi+3TbAhUroumvIZP0ySKLivKvpVlIbR6K2TFfDJAgLMVmkmEFa0xKxYwXGdE0yk
hllpbsDQao6toVlIfR6cZcMsQ1dVllk/SA3CuKIta+LGfJWHpbvDtNKqELRO3q9POlIfRzXNlwnw
5FVVvnPTSIu1eUD658SG6Q6HpLmO10l2RKBWkqNOLJSXpBvGfCdCNT07pjl0qxRXtESsJBgukkia
UG8dxpXsRmRXqao013GH0gJ7ZUAkU9NSLLVdLBUV/Svrj0OnxzR6i0uyFG36r6/yT3xU2xUyTn5C
LuPp6Xk23hMAOnrWyA3FV28qKfcJK9jCjqm8FgD5Hq03+jI4cqmUZhU7exbRuyaugtKOxqVahxcF
VMXNvfbp8dUTpv02yABZB4lO0YplUnGcDtlqqZHDfVs7dpAQWUlZ5bmVLESzrEY0UXvy4dQwY5lU
1WQKfkqQRsRa1pWkpfvMrhDY2Ex+WdX22mF+9RuztuzZcqKd0l5KVrQMq+9LZWDGxITCZY1Gza6l
Rzkrx7WNT7VtQ3EijTFrmkatOiyWQhDRISGyZT+8WnaNiRmJkyp3HNj9p1JGaTJFX9mxj8H0tKpE
l1CME+H3JcKqYIXjIuTKlO3Pjdp69K6G6YaLUDAM1a0jZ9WrH1NMjGrXtVLGo2yupFIVkBqJNqmv
aymcSREqmBbIrmvSdTr3aulaASwmubaVOzaqjXGwm7TqlHNj0riSI0BoWSa5pWTqh3frahoRrC5J
bU2+VNJxVITdrCnR7IdGrpIoDBMk1zSskUrnSK+pYAT4aPbbUm6U9Kg2pCYqWdM0rYFEqmFDa1sm
taVhqJ/lQqxoAuhNe2bQo80OraIHY3fKq0IEFF/JHEaxs2sYcdpXLFf03yih+QQVajBT4Y3idB7c
6sq2oI8VnG+goN+na1pBuhtGl9AYQVBA8iUle0Q5cRhWVdOmxWiCTw2lE2vYKUqAa2MBhV1JWscN
kE5MdVSUwscgchwnSloqJGJd1jAxqSra80xgIaV/Ym5cU7SLAq0iBY4ZF1DSNKylgIWRBqBNjaxA
0K6ViMWNcyI0Bf1DAXLWwFLUdLKOhKOWJOKotbXvkvoaUY01HDYyN2+7O09WtZHkGY2Q6EKRKlIy
DDgXYppr2ua6FJTgffGe66dpkLkyQOqHGVtgGTp9Eshx0rI8S2HOJqCgbISlp2x48i5YyVMgMsId
Jp9Gnsp7KhIZG2IpOnmfUHRmVsWBcJPLqCjadtPUsjwT3zRy5cFk+HSUDRmuLRlOysK22jyaBn1C
QNtXEq7nzTX1Gw2VdWyNDLfcZsuEyzhUdEwci6s/peVRkswGohNnz0bVxKS5dPJfUjDur4DIkBdQ
vWfOgssINNSDG69uVrFpzfUo/wBEEyfbkSqj0Fw+at5TCK8MRsWALUBjWUyG2dXab5APqGCs0Fpp
ssFu2yqnVOu/Vcd8uyUnttmnQeRNaBseLeT1ITTc9MJBSYzx0ijnzd7COvKMbmMjpyOPCRrmSIDC
ufF7YNQD+5TWKtMeO0gLiOgiE9sX+hv0TEzSkbuznj4iNOQeTG+VLhB4x5UjsLbSWmZpiNxiy/s5
PmNeylF3bF4+I5M1GZBVrhz2v2r90j2REFi23JaxCNbZFa9gafuqtMNMl1DWtr6hZBYMZsfJDEQE
diNknZ9uC0ncMNr8QCMY83AhBNeKVISI4Uskp4l7Y58xonfVO46uV7GlMzkio4SoXye3yj2UFTya
mrSIpm/x7IaJMpitdk7j44+P1Ibdw8C+SREWPeDRHkTZUzSkRO1I+ykQncyRAa9yx+2NhV7xoqFC
CFxbIL2nAYhhjgoj5X2cgu72Fgo4j4/aEMv3jxEKIULgyQRWPAJDBFA2fMRRJCXuoWC1SlB2Rxzb
mkxEIwcPiw5VYUYUOKNBRHzlUWQV77XQE70kHYHFKriy4SOayGgxEMrDJHQwI0BN57lE6u+83wU7
80fZFBKriyo3HGDRYz4q9/htHiR0dlkRRvgp5ANTx0a12bY1M0lFa1Z7O3HmWaMyFtLmxgfxrCb4
xJUpJsnTsZEBdO8d9hZ91NJx0QtqPtxy2XF1WTmCyrhyDQx9qJc2LoxY3fsnwGpBFPkJNPDqO0NY
65Z1gTDoqLiMDOw67YpIlIiifcRmSUpIQ4qSf3y7FvbhwROGexCnhRrBsKxqJffj62/yaXOiRLcY
Ziu08AjJdS6HIpq9qR1qe4O8qljyqGnYMAnOaa+GpIcOIo7WnCiRdTp2iVVxyluOkuNBrhCPqBu1
fLT+VgE3fpVn8XUMbyZFDH7GSW/zr5qeJWwEjrZIixwptXJAQsuE3/r6tv37+L5EqkEgSS0RZeoE
/i18JoUs9ljg9qkcFhJUFv8A1tR/sX0ZsuVQAQUiW3+bqRqOj18VoR3H+Jn/AI4YQnSIP/mUzf5F
yFkidRiQUySn8rUrU7ddEYAVz/Z8U0WGB0qN/wCTS+5LcA5E2mZwlE95upEaqV8cYR3P+Qzf+phR
wuOP/wAeiT+bf2KwGiEy4i6hrFrZS/0Fxc+cXJPwuaVdtaSPeHbJ/KpVc2TXf47Vf2GYv1CD/gnE
bxVVWyC/tgFZJ3jFQke/T7lb7Ttt4uoG/dIm2L0XF6L6fjEzSZGop/YdyTZ9cbjKhORY147CE+5p
4jXgs3J27Ai93ThG906p2rt+y6eRyx5JG5Fc0jLhjlyqqUHkgyBY+c48sYkaCVatikJaikMrHCax
rm8vZ4u1/LIuzQFa4j27L/8A05PHyG/4rKGsk0WI2KOZNQTTGfLLV1SAaY6CZKs9yQLpOApTCPTb
sNiIqtcgilfyBd/5tNncsk7t43BfqQF2B3GqQifZu/cj0xPnSX+vMyvROT/dTbdn9qymf4Rf2T0T
lX+zB7c7PZMrm7OcnvKTYQ03kJ/han2pe3cgp9of91ovFa35d/fOT7cfbvu/wp/ikInegp9mP7Ps
9kWr2RXf5rFftxV+8f8AxL/ql270fbx4vzZ7dymxf81t7Dg7d+b/AGM/YB0sKSHe8aCmzZ/uWn9w
6rx/RnzpIzXNtSJ4ltI3laeOiSY7/wCNqeQjTxC8JOnzIodVSEY0hOZdJSEel0dEiGL3p1KNWR7K
0HFNEXvxLOs8qVGhtiDt7XjmnuRZdj9uCa5OCX9dcbK6zH2I0lpDWSt8apGhDX9j4KUM7zkkD4yr
T/SiyEfOsnfwpn/p6c/09aru+utJMRi6qksyjlLPFY17SnWMKLHrZLCj1i5AkgajioGssxSj3RWt
iLK5WlKVXRNaSn95hVRQX0kOUNjJlFvnotdMX+UnvkdNiaYI1IepDrFkURFeM5GrOvV5waeS+QSy
MjQRntdXLKMOfGejYVSZqm1OQgD0TlVJJWum6gVTQaMhiZaGa0EV6Pq2lOKyARA1tLJZ3dULIHJo
Xu2PJas/UG5IdAsgiXMhO2AqEqxJLFaAf2q6llMSRqhkhsugc5qFlM8/U+54mnkkqy5ls4hI01VC
BLHZ9xBV1LJY5dSAkebSKo2pLZ9R1SN8qNp4chGXUwbXc0NV1kSWGyIdoa3TjucnWLFdH079uPr5
28rqvv13zfNsVOi5J+F+dPnQNl3kPEt4XEmnYXJ6ymxR99stllE4zYbf484JHmbXcHImwZ8hwLCK
XnG1D7Ep4KkkkK0Ue7NzKT36/n17dNJtd5p91FcN2MNikkV7eMW9YuF9s0mNWxLVNxTU/fppirOJ
uobxNnadInh2wHFZTDUEcrUM97ODJICSHtq+yRHbhsYTik+jqxr5j4i1lySRIQq9lj9jSl5CgR3s
OR6IjTI9rwq4/e4sExCZLarcfXPkrBq2tM8PFp4hZBJdV2mpCIV1TVmEbvo1oCo7JI17yLuG7Gvd
0/BeMxRcgdhRz09wuiEWYiogL5diP9s/Ol5aMbJ+82MPsYeZsrZHdCOMqFfIRg401HpIF3CBJ2Ws
nJ3Zf3mxm9jDzkR6n7wmB4kJLRjI0xCjOHmQZuyMM/70xFOsb7CmnbPKbvCCHg883tsize4woeRR
n7QwTkU01vfyJ9hTWCNKQvfGEPbdLncWx5iECSPuTye0KJPRzpbO+6K7x0WxRJUkiSBxx9p8qamd
3ugLV7yu4gYsSci5KF3nRn+KPUM1Hufti/Av3ZpKNxy2ajotsFRy9Px+5IC1PH1PG/dBGhzafEgw
aqjoRvFWl0kBBrcsa+Mdnj2VVJRYlpUjmmi7R4sbgc9mFCDj0jVUUVsSQd7ZEYmngkk2dekcDi9o
ulmIr7Pg+LVEbHJagFPyniDgjsbJrJDJiSQihDCW+tmtZXx2TpNSJkeNqCACY6tr0E6TTRD5VAHD
GawTzjlZJjQFbEzVAxTRI5Rk0oxrVtnsLEZCRlzWKwcXV0dkhI7eRa+kCUMOGCC3Ut8i4R3J+DXZ
aK77SOQc1ppIq4Bb9fMhTmzwIMEPL6/5EpLzvsdHE5be6bEFT3rxm5DntkzhVoC6iK+ZWz2WAHrH
iZd6hcZ9De9xHDEi3t+gEp7pwCR3snCs7McAK3hVm1VoOcIpQxm3N8+QSgvvZXAy/wBRdpai6fHk
AlAmCuLoNfG+rFfKqLcMsciXHjJc3L5h9P3/AAw8iMzL6/3WpuHwzgsI08NzdjhgHPI2TUXgJQpd
nFAyytnzzUWoUGhbGEmahvFM/Ss8UVJlnXy3HtoUUdzYOsZHp+cXq7HfLlw6Y5MCRRvprvLOQMoK
OwGNl5acspbXiI80ZSAsBtF5YnLJsGIjbZvas5POVEt2pHupSFJUShCDa2v7DHUiuX+j89Ez86dl
DAn1Maitio9at7RyYdkxBW8phUIn36meMTJs5hBWC/dojtj4tgztXL0I+ntPHxs8ZWvmIxg7VGkb
YjIxpWJkqYzaLbM3U7XJLmNRtgbm+kMgXDsW9uVN4EDZtM3yERJtnxbCuOD22AyNn2XFtdbJs+Q0
ud9jUSexjvOY5jZDMnSBuZDO1rmmRGT7Pt5XXPFzpiEalm1MsSo81dIbsk5EZNM1Hw7Rqt77VyVY
oxtlKQz39Icx0d9ZcNKw81rEn2yqtZdZ5zFbPteOQrZRmHZsM2ZZIJrrZ3fhXDTMPPaJJ1srnVd5
7OmMVtjZ5X3DgvHYNOydaoNqWz2miXDTskz2ibKtXEfV3m7Xz2IllcK5ay5UJGWDCJYW6MwVo9h4
ds07Zdm0bZVo55Ku6RWvsGI2ytletbcKNyWAnNs7f2iWrwkiWw5DZ1s0TS2T3ErbpHsLaDY2XcOe
WtvGFZ5YFyfcjYMNu8cuNbgIKxu2sbMkqd+Lg12WjsQgHKvQPZZyGFfRyhx3JfgQd1YMkLCIgjxL
2KEdvdAO0hOR6a4jgFK1HGeydI7zqm+SM1NRwVSVqQStr9QME92p4mJqaGmT9RIU0TU4UG/VEVqW
WofJzn++pvhRBm1hHKNl24Zv1aDCauC5ky0fIysvfCU+rGvZMmvkvqrxte0etBo02rWmQVw4B2az
TDauR7X2b3Gj6teFhNTO7szUjpguf74WqSxBG1iUjQWrxnTWhkSfemsFC7tvBqyUFkjVUgzDmUzl
Toi7YIrmLH1LMislXhpedxd41tIhYfUMw7Xk5uAcgsXUU7Y8p0lwyKmMu5cdkizLJRHe450iNhbq
SVHEV7hlczFuZaoQ7zK1ypjbCUFpZpCo1cFJKJH2Uh+EXkonuTHSj48iqrHbYkgzMecjsa/GOfjp
JsVd1a1XY6QZEV7n41c+7jyPXEVcb3NnEJirtjX59x2OXbGY7vKjnuxy7+r46/h2LjvfD4T5yOjl
xwjbBGXCCI3BCI7PHMmDjyNvFkbkjH27BtiDcmIIytINyK0RXoQRGI5Oi9E9W+L1GRWYFso2EjGT
H7sULzvXxjuwwVarCETBhklQsZ7MR7h4J0g2PimREG7dgJWKOS1CdxqiSS5EDLwvfbiyHtXzipj5
ZHY5/LGPXcXkKhHETBDkLiAlbSBGTG8kUUeUqFYRuLIIxQyTmx/kDRDGI4QZap2JbcMGS3GDO9Uj
ylw0cuDjHeqRZmeJLwozMwQZOdmZhu+3BMkGVsaa1Dik4XdMVesQJyY6NKa0vJFE15FZGmIh2lTG
clcGLL2kAkMx67LEjnLhIstjS8kWMx5neDLahkIis5ucGDK2kBMPPfIsWQbCxZbEdyasYBjOWBLG
0yOZgWuI8NbLVJEcwVRV3jVkkySK6SHHcmrFhnk4SqlMaYbhYAbzuZTS+EmMUCsRXOBUSDNkV5wI
9dlh1pZOGp5A2ka5rotSaRn6fk5KqjRkYxXPDQHM2TWFjY5Nl6ga8rg0JTNmVBY+Na7lFqSS8kae
INCCcFY0F8pf02ThKgljKFjj5H004jZtGeJkKsdKxNL5J068DQQSvIzTW6E0xxSVEJEdzzn0294V
W+VknTzo4okF0hwdNMXDaXbkuAWKSBSulIfSrUbJiPiPANSui6d8htjXOhEr6Fsxq6ZExyaWEqSq
J4SRtNjex2lQKkqgJGLF0sMo00yBql0mNWzQeGepgsmuPpMfbg1HelfpQDE/TMbLGgCBr0Vrk+Ey
HEdJdE0u1RWumFGNoHISr086SyVpIT2Sob4JaqofNVdKj7d1RFgPgwnySxtL/at9L9oLAPeWq033
2StKDUc2G+HKp6Z0ty6VFte0rq0ldXOmPi6YZ2rnS6CCOIR5qnTXNkvSw3CnQHwi01A6QpNMB4ag
oFr31NY6W6Np0SBu9MNaEEMhDVGmmdqXpYD2S68sWRR6f7im0/HezUNC+uNUU75bw6eAMV9ptvYi
QCHNWUAmMnaajyA2MAlfIixXnfSaXa5usKdkIdHSOmY2oiCDqcMYOL6N8Trvnzi/CpiptknHYJOb
6Sm3SyjMEGijpIy4qk2papXMmw2BfEgscN8QaPkQGcAVLVba03HINSnYvYaAylAMrbCq5MlRlC56
f0Pn0JkQfdPXVLRBlQGObaxkA6gquY/BZxtoCDSmgeWcdc1iWFc3g6N3JcGpaIUivYrItS15nxWC
RkRpmyapO4OKIbBha9bCsRBygK0nikx0cmcF3paVZBFqWoAlahZYoDBMaBrnT6tFZApGoRIjcnVS
OZIgr3aelaNtrV9tlTHap+0NrRiQjplaioKIISINFwta17Y8Ng0cxMBC7iSa1vcaJjUFGaRZtVyW
NXtEzte8msRw7WJ23OTbpWwHTTRK1scb4LSNs6ffKqmbHH4bVSwqOSV1H91kNjUlViEZ9CUkuPXt
A0kNHpPqFc6tqWx2eI1UsqfdKmkQapFbkyqQjAUP8gcNg2kgtI2XR8jV9W2OLxGubaU3dyppGhxI
yJk+raVkWh/kDiNG0sFpWS6LlJg1rQD8Rr0taRCJUUrY7Ow3LCpaYdfQo0zYjRpIgtKx+n+UuLBb
HF4rSNnUiPJFrUYFRsaSRWo8Meib5KR2iSTAaYd1W+O/oib5puJ3ypAa0c0DFYsP+fX1qNCcTES9
itV+na7cJo7BZdgGQOmoPcKsIYRShsc2tqWMHKJGARsRpo6REDJLKjjWG0cluo4bXjDRyZOfpqYx
DwSx8ra10p9HSsE2/hsFD09XorrY0euyrIOe21qWkKCAkIIjjkO1FTNOKhgteSHXj8bWY2sJp+aI
cOfqEAn08lk0VuJjTnuBRwVlqk81lFa0Y7cMcQ9SskSQqj4epBKSdpyGQJCh/h0zUdc3EpYsN2qz
5YaiJMRy8lTBM5O0zTJxtbRKzIfGwAtCNLGUjKqPU2jbLL2jYVIVeyJD+u7zpNe2ZDoqcY3XNqtc
6DtYR20rUsrJyVkektnWa31MwqxYA4sFl64ljLgMlwKKpGLLu0fELW7WEcdKNtncm+mx9O2ZZyXl
OMhGRmxYMe7O+ymQWTa+hrBiZf2xY0mpd9QihqBNs747q6NpmwNLZd1YnGfHSNBrrWQW0nQWzIFN
BYONe2Mlk2AqzIkOrC2y1FLfAFpqWeSzWNe16UNCkYUAzUXWSd19TCY2v1IKZJPKqZEdq/Pr2xcX
p+JKZ+asaEmww9mPfylXKKd2DiEkwfiJGZqCYvcqvePME7lJsu0ysJyZIAw+Di8B6lTZIEtYxgN7
8a/jcHkbi+hfQnVM0/H7s5GbBmzOys8nluqAcIk16gydOaXNLRuOSmqNkyeiJAH3rRBfamTfHdWS
GmZNC57a1jhjsSoNPqikdVsexZslvANW06/TRtyVWIrYlOhZEWM0CKieO4e0sjNxgE5JJURWoD9h
3KNzGd0E4TQmpTtIlv8AuYWR4p3X/tRKVzpcj7ZJ/wB4DXvI3ZBTpvjqtm+Q+rc4QrSUjU+pOO+A
1whllN5jIhBPB99rN4+oGbOKnTSQUcKS3gkInJ54jXqsbgNXKhlChQhhoiTVUeQ07omQkR8wfbSC
7k48NOb4/ATSKkh8dChHERrZjlG+I1DBFCTnPZ2krX88NDapCx+2EBF8gsZpBBiI1kx6tLHH3ghh
N52TVZlY7uI+G1Syg9kUV69+RGR7WRkYKQ9UMMKFjx4bcs925V/dZ4be9YD7YoDl702OiI1v2SRG
99U2jRAo5LTfnWt7sfVAEa1ybLg28l0kFEy0FwjT7PtLU7SZQRJ4lpM8UjpSS5dABvj6gesd02z7
2aWA1q3AuID2ijLWEV8aZFGQsdnCJeziiNWwyS1ErYQiyPqMsVUwQlYzlYRhFbR07GsCnbJdjUkO
kTtraRkPlWBokenKdbJtErw8T26J9Pi2zoc2mlqWNrZPuiI5uVcAkt8JEgg1PboZ1HHeVtfGaF2o
yK2LyeWRR06o6bPZDjQ4H1M4GgiIZ/KHVSEDcSTeQBaxjsv9PINpE90TInufTibQ7aMh5tINGI//
ANPUDOQqmG2OS1aigIn/AF8eGxSgT+BUJvllHZIsaVqNxW/9pqRNx1kZkcltsoy/+bFjC5N/8ymT
7Vixj7Oj2TB+9pqVG7VwWCLcp7Sm7VsEY3qn/l0yIoJbRvs6RvFo03tNSublcNjD3Se9hskCAguL
/wDzan/SP2XWlP7jh+9vqQjWOrkYkq+cxr2oLswIzRG1BEGZ9SvCBP1TGj2HijnRdSQErrTF9f49
k6LknH/NP7WAP9S+Re/DRVkUm6AnryHdMXu0y7xpp2Myf92RX/tjvsOyYEtCi1Jie5q//V1Fhcd0
2xfn0bZt0TNOGaM6PTtXj/cJe3Jpyo+NcvRWy3/v0xKaRJ5E7VsT7lFJRshHIgL16LmmUVRyTINI
J2HbZiV7a+qQayDIJp5jjyIg9gWc50VUue8yukiTEO1cF+4R2cpL3cBjkjdIe3fGf45qoro67Dvv
2ppdV2sV3DYp9yhgeWVo0jssbHjg5H34E8aqxEcK8RyPqa1NpBOw2XIdNJXVyAYc/abNnu5wrvtt
BYhO9jkUGof7y+67ZpD2BL+IHu5cJ/hXZZAf8I1yeqcq/wDtb/dZLs2B/cRd1P8A4U2dIZ/hH7sn
L92v/wAbP7rN2VqbOJtyl/4Qe5//AOiz/FL9zwP8Iv77Vfeq9nP/AMlgv2Ivud/+PdPHkqimjL/G
Aqb2v+WoxXJ3rTbhA/2Jibo1OAn2Ykkf5I0NOLLFfu1C/wAfVKouP6NzSRkXLc3GJbn7h9OHQZgk
/iamk8nwn9o1DI5A1dJ2Z3O4TSUrmy8kcIvc71lUARkazt1BIhr34c2r8iY0TIQbWxKddMAeyVbf
sgPmHHYrZy1yFeAaytsQyC2ZGpGpmo/NSWZIGaelvmjI1GzbRd41cfuz7kjUgE3Sz097wtbr++Iz
meirmDjantFi4MJZxGNsKxdNWB5hr0bVgU0VJFiYTYcK1snSpmnRN8a7e9s93vBmIV9nJ+pRWaUk
lkF1G1qQCL95uRHbH04ZEi3qkFLpN2RvJb9U1BuaLp1SlJaym8HFaSADyksWlQUOnkty/adkylVQ
hSUi2mo0dIiae77320tiNUrSV8MEhkspkDCpJjO3qCJIdZVG8eMCaxbbU7HTI2nxGa65nsTHnbIg
18CUCcaQ0MGjmsUN1XyH2dUvixY1gP6tqeM+xj6ejSI+XVmxFMRsuBV1Z48yZMYGHQ2AzRLmnkmt
oT/DiV1mFbjU8B1qKhjviN1pYtKEc2Tmk+4rdTq/zK56Oq7mAYuoq93CBrN3O7z59G3XfZF9ui5I
X2VPeCTtSq6waYFzC5uoonck95sMYZ7ZSXMRCNqU2BYx3Gd9NRoo37RagN230xu5F1Cv7auD5RBl
QEe8kdxxMX0p6kyhEr5qJ9u9Z+7bmSkbwhXLf2S/8mkAqmTW/Zs27EpBc7D/APo3rNl00VGx7EKy
G0sVYrSKj39r9smK4xH1SCWO9OFlDU6rUINkh7oq11pKPIjkXsvfxOV3cECErJhCoxrJfNTAV5O7
wZbv77tPwlAyWLkO3iK12lWIgrB3AckiukRq1pGCo1acf2hXbkUte1Ozdn4N0+3vFUKIw0FTknVj
WMbVOM6to2xnvkoMV8fm8i+++abmdlrnodkcfYw85GYGZ3hdr7rpXbHHsEc6QPuqI3ZT6hsUzu+0
DUBkifwxktDDQXF5JiMZGsEfhxd14zdljLJO6de8gPsrJskY5JSGEwKMcedwZDsEI0okcZsjsDBY
op5P3kju7GSLJGmdISQIQ0G6XP4Mi2CGE8SOe6Z2Qw7JrnyUQ6xy+Oj7VqSXSEkiAxAumWKI5khC
xywBPkKdo48WybzPsZzDpGFfT0IQnu78j910sNrctuLo1wHjI08JqnY5iRtTARywGc5FFwYDVDGG
TtcD6UG0WXDhkAZiRrGslp4syICQYJWx4sIoyEs2jkJFpwY1rYsg0hsiOtTFU9nGQUd70ebSjUE6
0Kx8WrlNFliwU3K3tQhWN0wMoM5JYBjEHNRXTe3URUOStcMILyMOUqjbGsa2YwcLVZkKXT/aeVI7
CDhRhxX6htWMjaXL/LtZrfp53fztO2LXBmohXtnIoSjj/UfHQoYcYcV2prdnZJ7vT2wTtloL1RKJ
7DMs7ccALL4vnQJjZwTyRQWWt645qO68prnCFl9qPbKS8cF4jDMO3vWRQjtyJJrLUcwcyyBDFY3Z
Jciiv+bXSY7c1BqBSvo7l0UoZ8cgLu+YBgbQw5VTchlDnXQIwJ9oWZJ0/qDbCW0MSagv3yyU1z4T
wXMQse+1G1BAnEGeo1BHIywv4wgSrEso+n9SIBpr+G1bm6LNNTXDq8w9SwCAvdSIUcaY4JqrVMUg
7XU0do5Mt8kleZgZVXqevDHuNRQpDKPVQorHajrdrLVEZsWVIJKPt/Q+cd0X4N7o72VrtlqrZY7p
FuOQGrsEAa1uGlHT2nYyRbCLkS3G0a2gVyTcCRg7tjEuJiSHVdu0Qrew7+U8xgRzrpOEmSpVVcXP
x0+ei5v6aOUkZ7LkXatJgzrHIg5dfbjayxsRFZJ2UlNYsjskWg3jsyNe6nlNjOZcCVlpIGZK+f45
RXDCotiNqLcIhA3A3NScFXSbEXEFyg3/AFMREkWAkbZSu46qkIA0W3Zwm2DOUe5aqeePJdqjWhtn
NOG4a9k62RGim7ngWI0atoNzbUjHpVWHitmWjSDMT7lVbtG1JwnJJtGtbNmd98O4RGW05pmVU1Ir
wWw3s80OS54lbFlt7jZYkbY2zUSTJ7iu+U+QnUTqq8/aW0HxnWakWtuVCqWonssLfI9q4Zo10MqT
bVjGvs396uvW7HtRtbOtFe+uuFGqWonMsbXlkW3cJ4LoZGTrZEati9siBdteORbiY2bZqUlZecE+
rAVthbK50K3UBQXUd47G5aqMnuYaFeMcyXciRkmycQtZeomPuo+1nauK6stnR3tuozm2VvzyPYOE
SJeDUc28HxLNc8lXfoxDX4GslWjjPr71qD+uRcsL4asZaOaaJqELx2V816SDqV35xjtsqLwEUcjU
8YrbCUh1qLEUN36sj8LS1ZKdCkeOePqmOEdnqEMpjibnr9RCiikaqERkuT5Dq7USxc/VwNpep0M2
FqXxXLq8eLrITclX6yDR9V9hrtXjXLC7WWrV/dA1QsQBNYd5jLp4is1nth9WKVkiashYN8WBknVZ
DMkSnHfXX564f60kbG1XIM0h1cRmo5AWSJTj4IzhKLVMoLH6vmbSZ5JmRJZYjz6gkSGq7m6JYGiO
dqKWrWXUkSHnlkPHqKaFr9SzXpImkk4vRMY9W4y3liZInGk4jlTATDiw9nIfiu3UR3Mx06Ts5znK
j9sSTIRCHITE3xClFhJBnIi43uY+RJ4ueq4j1TFkkTHEV2ctsY925EI5E3xoibOHJbiqu4/fOwfZ
26Yxu6+OVcIAw098ZGM5PEMuETg4QXkx8Q+xI5BYi+4RKXCwj5ts5g1cqxybJ8gjkPn00y4eM+Pi
9Pj0L6HY7Fw/w/pGEpFbXE4DjPe4sB4UGBxH/Tyogqx5M+kvTH1b2olcR+HiODgYZDZJiOFgYrzY
WucLHt4quLi9fjFz39TV2yLFLJVaojGlCo3Da8zmVZVQ8NzMTlyDXHMh6942uarFjxTHxasrEWK7
kKqMqfSCYaM8WBryFxKwuxoZRo/kzO+5M77tnP5YiruCvkPQ4yDwMA5UbVFTJEIjM7blcGsK5JEB
zMfuxY4yyHrDOFiNI9zacj0+ikwtMQaMriuc2oPsavKiFG5mdxUzmu0cLjuDTHVPpBlQtSRuMpik
X6GXFoyIkuIocXqAbyqGkO5siA8OcV3jVUgzDVRBoQbhrFgGkq+mKxDAeJQBKdzKMqslVzxZGqDG
b+nyZIqXiSPXEkKPT5MNSvYh47gqhFTO6uK/fGOVFi1h5KSax0dIlYSVjdNuah6RzEeB6Pj0RTpI
o3hTsP7kegeVF037Sql0fIdKWUn6XREkUbgtIxROBHJJf+n3NFIC4CxYxJCs08rmzKwsbOa53VXO
W+AA87had5Nl0rwtIxWOz5xqKqwal8jHaaa5k6tJEyFDdIcPTaKlhSkj4wTnEhaeaVkrTbWNMBwn
19O6ThNNMUc2ufEUQlI6HQuIyyrlh5XwXSlFp0OxNNi2PTEEaLpxjkdpuOuWOn3gyBRqZG6dj5M0
3sNsF6niadY5k/TSMZ2HtfW0anabTI1bYQXQy1lS6S52nBqO3onQmwIiyliaaZws9N9sY4zlLXaf
UrT6YC5k2C+CaqpnzHO06Pjc0z4eJvlZUvmukaVayO+GrZdZpxz2WVMIQzp2yr75t0ANSOp9NqUc
rTQntsIDq89FSrNx2nWMZqCi8LKqAswkbS6DFcadY4AgL5FNprmKXp4JhxdOu8xunhgH9EA5LbT3
akV2nRtF9JDve6bb4ysVj1TPjNuWVNS+aQWlxshzKn/uINAIAvCiOy+000gKOlccgqiKMWotNtUO
n6fvkWBBjCbWxJeWem+NnEqosULB15lvtNMIOm0+xoXfTWFlUgJcWxhLAnabaHyDU8U0W3joC205
p90l8uhC2F4/fuKqhDGjrNqkkTqQU6HZRVhS8X1ouLm2Obth0/aT5am60NNzbNjjEGmYx8mfWtKK
np1Qk+KNjKyMwrDhaNzwDUcOuY5tnRorKip4D1BCRjaPhkmtaUdpA7L3t6L6fjqnULOZqysYIBIz
FbcRUHmnK1CtWINjbSE1GVsLyJwoLRsmwmOZPj/ya2taMBYzHNHVNcd0domiE02S6pqqMYgtG1hH
zIDFHYRlQjYBXY+CVmKFUylplM4dW1Aza1HSBQmjHwYr5NcjhxadEK2OxMlVzSsm1jkLS1DBMsqx
EFCE1k1vDgJGPLJgtUbQDHmzVx0Bjx2sTi/6eQmLVFamnwIMqIzgEbXvNBbsjWNR3DkkNHhvo6Dw
qe/x00xXcmJEaiWcRvCuhpIlihbMlxW8ZsVHSq2AjAkit2uo7UTTteii8RrUPBa8jIWw0CPnIrUc
EImAz9iqkFrxXUNExKmQ9VpZLcLGcNaapdIJXVbeF3WImQK9GjINjHNgIUTqZrjpEQTXRGnaetaI
4+LWRmDK6fBY1I6IxqEDydBa8NrWq49HToPD1TPF1BH4SNNwebHxmCbaiRWOqiHM/T8huOiOE6gq
/ZRsDhobTDva3tPVMTKuN5B4FagAN4OdYVSGHUUiCV/ALjQkkMFRp5KgSINrGyWz6ZryxK5I0dhG
EW2qkIKrgI2TWwR9nWAEHmnOKALaCHlY9k5pq5rpB2MixYk9smTYQWOZDhsCGVZ9mS2O08WPUNfK
nHZXNCNstsmja+YsVsGPGlMl5b06GytqmgjvsG+RJrkkRaikYx1hN+n4FiTBrRp9QNtWggTEn5c0
yFyHXNhxEteUybXJKhhpXOsqWsZGbaNR0KrrUkWlin08FpOsZinY5HJn5RMoo/clw46ChFtUHK1E
Rs2RpeGjY19O8GRdWApELRcTdbfkGH9bY8NcHyLmPH7de+2UEuqKI0nVbDlBpgchmapltiDXVT5A
qGLJc+6sBgiQKB04v6SCiTdIjQVbTEPKqq9lcxCIcH9mobRvch09XJFMnq1IlXCaOJay5S2MBvlw
rm0JS2rzyr0lPFWuFqjUOziXs2xTT9S6Oy1txgysM11ZMpZBrqvEo66+iOnaiqNNNHiiQMC2VE1F
p3UMfecbnDgq1uooq86t9AVbgS9mu1IRpbrb3XPnNvUvR2SPgvzG9zVEdGRdRnVqQZix5Ne9Jg/C
aJmoJSsZpt3KLNArlmS1jDoy8xGVhEDGaxNSM9u8sc1M7vxNRhRGl9scnp/OJm3VPmoD3pgB7hnn
8fJs5JGUAO3DsPtJOs800DnIKPYU+eosDtNnRhbhnnWOtPOQ2SRdxlfH7KzicWEnPeWsiKNZclGt
jwWyHeExMPARRiqu5IjRUEg/8UofGU1nMaRuMlf7GBTjM3ZkVOQ7RrRPo5iFWxdyBNd2ZKXD9qMB
O7IlIg5c9zS14HmUh+21oEmkHWezqfm2fD8JVtSLlKEiOkSthzLdwX13fmkGbthvSoql+VwTO4/T
gUYCyb2kmWGafEikcFPGnzuw4HGZNrwo4NsfxyTpCS30IEay1TsMBZcigTuBcBEkO/17CeQB4IHk
XyOyzg2aXw+DXR/Y1cwpK+uRjYbEG28GqpXN3FMAncht2CISOdZs4pVbuy8Z2UjlPMfED47bSyQb
AWRClhiYR42/x2wkMeLFQCn/AHR76L/I0yFqDvftsnWiuyogqdraXk24pkYtFH+xabq+rZyBqoaN
xflPnS40dJINEiDYqSnCTsRhIg7Jq96tZvGCFvduG5RsXkYLVJYMRkeKNUmTxtWKs/wbCkl96NrH
3yJIeNawRSDq2INsh+0s4+caIBGSLd2w4jleA0dO9uiR67+y6F3D0rOA3MTzrj/WqwI2TOaiic3a
L2E8gTU8auYiNtwoWZTjRoeP/YXjeQakKCNYJ9k3+kELe+jf4dUASEXblLHyi04EZNtUb2hRxyM1
PRtaFvRvzpdoe6NUWJqmQ1kivVhZFDwQOsSjYiPV59JPDteq1sOfIQh9LuF3kenhapltWTpJheNx
Jjwx1EoUpdZxnuHQUSmyRIFWgNZus7GojNHAutTSq+yFq0Bo9FIDIkyEQ+RhoMM2E11mZ6Q4kG+i
TDWgFICu/wDL7o/qVR/q30J869q6wcQWotRNjPGx849BRIJLi2HWx5M8ss1VqjwUDrQZjRz+RAg1
zD2VlP8AFmMVVqrn/wBnS3/on9qutF5N9ED48BNYuLaED5lXeCQFp/RX3xcVcP8A2k91j/tNULvF
1O3BDV5NPCUQpDuQdQBdmmv9adJQeWarJykarYs6csZ1dPQzNRruhU5uoPaBqNN0kf3O6b+pMRPf
pTnQEmKT7F+VExzuJdNye9FtyJwnO5P0tJ3LJf8AYuCpzrJHYlxn/ZvSojdMN7jpD+Da+Whyzh82
RKxGOkmQLJsp5X1w9otrIcBGXBHZDsGYyaxUjKjmTG8pX9gvLb5W3JjPZk52RPYd7/bppV78v3Ba
79ykgpJOguwOyncUrIDiquwW2E1yrRN/YUiDb5+2XBEeynhpINw7LLSw4ZF/myokVABsJvYbPmdx
XLvi4J3B+mTo+PbH/ZYl3JpiTyeQm0a9LyfVSO3JgF/j6hNndUZNOGR47w37IS9ywjoo46zW+Q77
kZ1bzO5qBbZTHuygZ+23coRpdyGFHY7rGsG8K43cy22ekNqo2wnNEaETuiD+19m/Ktf33I/IyNAQ
DZkvstnrIkKERhvgXaI8Lu5G8lI5Az2EIxyKHUT0YXTB+YtSH4jjN8mfAh9sMN6I++Y1W07k7Niv
3KhdgaqIi49PdE99MO2kkcixuX8h5E8cBWqCwdxfWrtEAVqltVyjd9wpU7s1yEjhcvm2BUbEtf8A
f04n8XWSZEgEOg5c+tbp2QSWEomulWr1BDp7I0mdOYjhMYjI8+wkMsI6c4kJ7US8IrX0XJIrpLVn
Wrucamc8k2fIaxncR0cryed3O1Grjpxu1e01NuyIklqzrhe4Gg7jzWUlqNcdr4bWn88x+zEJqd8C
RVakNONMIrIVOfeZq7m+No9hWv1Xt4Sr74zNPsc6ULfwNQ8/qURquLplitj6+avJi7ZowStXVTXO
gLvz06JzpLWr9NvmK2x0a5EDraM6ULScd8ZL5iSCEi+JXyAzLSQ3TPiuqS8q6/qZEm2FpdzxGUld
Kq58uTLgKqwEc5lzdt79fp2sPGkWZ2si01gwkObSmfaDkMgQakDJ0rU6SGhrtLmmZDoGQJNmJY8V
lJNsZNrpPxY8KvLNbT6eMMxZra2FRS2lNeRXEsAP/wCtuIr2W+nKp4pMhv8A1sOuNAtxFQlUCiki
ukMgay+IhbbN+nsnqdm/Q39pPka/u07atUNpF8kddDRZvNIwI9uhjWgkMGjH2x2Ie7g69qMgogk1
G79mmDK6JfP3bXRfMfHc2JFvZ6EUq4vo29G2J1rAKeXF/wBe+H+0i7u02JBQ7Zm4pqcX6TD96QvI
dwP7leJSzAKnYvR/t00btZIb3UrovjkeRFcjU4yY/dISsYjYjkaywipIaOqGEc5OwsOWckivf9iS
7iZH9wXi/wAhxUYxk5FUoULnd7TLST31ooaAcUaOFdR030vszJj0QUonKbAEiAlA542uY1sPYGSv
3t8bbLTkjdNuThYvRGWJVcTT231DuN7F2XZ5X4vQLebtPMQUe24uFZpxJpYCNUiose7T99SHuSq9
UQGoWouIPmahRoxXXFw4j0DPjmR8dYo+807WjDwfk4TVxsAe0REA+Y1shv04TFsw9tByS+RQO4tt
jNXIElOE2OMpIxWhF9Ta2Q97Tox6AxJbCmVBdl8URSyoLEaKCioyuAx7ZDRAvZi8qFyuIIzfFvhI
U2neARXzmkZGXx7WNJa4AitYWzkNeKBYNY9yoXFkpHZeWKHI/wCcqZfiFiWTZIkY3lYWqCZV3LCo
7iVSzWxRAvkbK7rTtYVkRs2+RkqPPSSJiNRby5Rg64flmrHMEG7Rp0r4oEx0drkgObEGa1ak4kny
AxQsCW2tBjZEsUMMgEeU89kePGvUSQjkM2TPHDC7UKpNizUmC7o47bi9VX1V35TE4JlxfdplLffu
YrSNsLccITNQP8qDLbLESWKIy0v3PPTXCTGK8Ysvr/8AapVI/TAtskzkfHbYsBNM7yWi4Qs1PfNM
xf7t8b86WYPmtmLxdUKx5qpjPIr5wIodSywHENqKbTh48YdtZgOGyVCS9LkjBV93HQGpzhMWiuvG
VbGHJR1tGjMJqFppn6ghECK0rhrb6kjqKk1KLPrFfvO1SEQJsl0s+nZkWKVmqoYxW12Fx4WqIpAO
v61iXupvIFTXL4T01XB7N9qF05dP6kDBaTVsF2N1dAbknVQiFdrOC9P1fAHl5q8MyPpy/jV6l1lC
2vbx9ianv3VzpWs4RGA1mMRrS7HMl1utABiLr4HC31WKaGm1h4TP1zFy51h5YXOV71X1bddk2X53
9i+7SfKfNfPdFezUInCDZtDMl37XiiWChmP1Aztxb4TMdqALsfqESNDfMTLW1bJSntvFHZWzZCVc
xIySrxrmyJKlc73zb0r0Xpv0TKyV4xouoxNZY2opOKqd+vuxhSXdCI2eZCLU2bIrf1CBR2E0ZkgS
kjFj6iDxsLQUhAy/HOC/bt9bj7HukR4NQM2+tAXC3guLLrZ7L0KoW5C5thO7zoJuweJfMak23YTI
15xxLoC5LuBualm5hY2oWcZd01yeYvfg3A2J9fArbCwCVsKb4zi3THjefc1feNYn1sC466AiGukQ
gLwSo64BxsbJDZW2KRUlXbCDkF5OhSPGMO/Gg7GUh3P9+oXcCV10wLZN4ArJxUKSrsmgxdQA7dnN
GdYEhAEj6ijjHZ24JLe7xkV16ITZV4AjDyti1+oUGn16KqSL4eQ9QMbjr+M7F1BFaki8b3I+ogbE
vI2WNv3cGXiSvvhhbKvxFbGu+wrNRRXJI1CDY9kqlhaiaNJeoROaK2VkgOpw8P1LEyXqMT2Rb9AL
+pou0vUQ3tkyXGfW2SQ3D1WHhPuGGfD1IKO2dqUR2Hk8312oOww2phOx+pWPa6evej6qYxk/UPk4
Qiuevvm+I7K+4dDxdXorJVi+QoJbwmZqxWDm3JJLvIXeLqR0UczUrpSFkOe6vuXw8dqkjmyZjjLW
3RYGfrEyYXVhDIy0eMzdXSEQ2qiFa+e9zgapkCYurpK5KtHylhXciE39VydpN6SXjS7ODqKXHHJu
DSs7i7xLWRCw+oJRmPN3FjyngIS/no0sh5lGRzHNuZjGyZxpGMcqKGdIBhrKSdFXdwjPHi2c1UMV
z1G1VwZZAUWxl7eQ9zkly8fOlNwhVKubYi+43uxXzFaVz92rjFk8SrIxMZ3VQjJOyruolXFDKdj0
c1W/KRjkaRJA8V/PBCIXCRZDEVcY1SYsAyoRjxKnuoq8pWmCUCpgYzzYSDJHi++DZyc6rkcXsezG
fKVhJDTQyxcR2+BgPkYarkBTfABcZVpZGxRvC9jd3JTnIhoJo+bZGrjS0PUSAptusetOdFoT5Nrz
RW4mL1X0ri4uE+CfORxKTA0j1H4aoUlMqCSIqm+iuRkemVV+hPbi0ztvornLIqngbFrnSHSqpwEj
xVkOLVuE0olRVTFxcXpvi4nVOn4GzksSmeRpahw8KFRuhVz5KupXoyRD7WAiOORlEu0iuUOdlVfF
pHEQ9O4WHCo3Qq18lrqZw2SI7hZHikkPHSORJMJ487a8gUjyJIqFFhQuTIVS86Po1ahozxZHiuku
bRK1siC4WIJz3RqNVbIrHCaQTmrDqXHa+l7bZAHhyJAfKd9C4tlQFFjIzjPBRO2k1jgo4b+UKneR
D02ySY7g57qsKmJIbMqew0MN5ij097TISBUjfdei5EjkkOBp/ZsuqUadh3KHRdxp6Tg2QBRLAplk
4tAjWTILo6xIb5Th6dTaVUPZkOhc9v6famHpeGApnSXj0+NELRNakyI6Ou+2c135LiJu6DSOkNl1
KgSFVPPiUQsLRM2LBewsTT6EbJoUYj4JO9G08zitCHJdKo1hUKlalCDaRp9iZHo3kePT0djSUIsn
1yxciD7xAUIiMs6vx1jxXGfG021WWNf4jq6o8pEoQI01GxzbCvfFfm2DYrlrKXvY7T4OFjUEj5Ar
nSFDQD4WOnuLRQyKaFQM4S9OiVkmC+MWspO8haEfCyqiRHV1Y6S4NCPjaUaiyHCcUkPT7eM7TrOJ
obxmq6JStkafG5lnUviPqqh0jPoDVS5oljpCgPO+LQtQdnp1jmNgE8isoeTZVAJ7LKrJEPUUrj59
CaiXNC+OtbWPlEjUDWDs9PtcMMAnlVlB9uXQDKOfVPiSKShcVzqNnG6oXR3UWnlkI6nQeSKMZhGp
HDmVunUaKbRDIy1rXwC9Bj55TUjjubTCCy606wooFSU0iuoBjFOpAlFIqCx5dJp1vEtSJW3tAsc1
JQqdfpMcI7/TzCBrqchzQqSPHDOpQSgmpyhmU2nxja+uiuy/oXxzUNDzxYURjdRadYUdPRvkmi1k
aIKdTAmR/oRmzKehBEG6JEkLqDTroptP6e3Z2og01Hpxp20tI85BxIteOdUhsIaUL0nVdUGAJRRZ
mXmm3xpVHp9AsV0RM1Lp5sgdBQuM5PEgssasNnCi0BPPhQQ1gf41iKfp3w7OOyPBig1FDky7WoFY
V0sXak5tn5xei9Vxc2wyYT52zTlR3mygsjhjEE6zfFYaLGo/5soDBBqlYdZTGDxvBzYccb3TqdCD
rqnsvvIiNZWvaI6RmSh3NX2VImLi589VxPb0b4macq0lL2WCR8dh2yqXmWLAbFE1oiJYVSPytqUA
n7EWVAaVkSlTvdpo8fGYdsin5nBDaAXaGRLGpRzYFWkdqI1Ml16EZCpU7naaPHxWSGkpucgMVscf
aa/J9VzyvrEjMRGZMgIQcKobz4NZhIjTtWmR52RkCztNLk2nR7ode2MNGMydWI9sCmYJUajVPCaY
Y6ZPIaBAp2WlS5rOCV1Kpi11a1B3UFvGtqWhQ7Ua21azCt/c7rpaDzEkdBpYia5kSL3Z0eGjRymD
4T43KTVQuIiiYiXYE20/B3H2GjaYLXkHETgvDukhteHigXd8e7BMIO5h8nM08U2P029qSK54Mpqb
mtZWs4XcBjMr4TVZI7YnBjNOJapqnWO0CIBshsmB2isKMbIhBmfOjMRolYPByxEesdjgxoTFdOVk
fK/hMbqKBxynr39+rhscHU8dGpp2KxViwh9jU4WtLQwm9mwK2MsIbZIdURUbjsTKSN5J4degQMOx
5ZtahR1lOjUOZkd6xEkCj0zfKM1sNoUbNyZTIUooTYkcMphyWNXyZW1DRCNNYExYKHFApmMPPKlf
gdpzTUqPmKBsIEaX5jrOqR2QaxkcJLDjJLCSRHrKdrSWUnwVjMSaJ1Qj50pjYMevl+ctpVITIsBs
aN9SV8yRXoaPT1TB5aT3RyRGebHFTtSbakSCKokunLZVLXvSK2JDBZvfKlQWkDUMYMdwyY6XVD/i
jiMPO1Abw2UZ3Ss1hAaMDMT5rQ96XTQGhiWM07Z8ISS4kGvYkvU5nxWUBCHbPrWNlT2+JX1Eo5D2
cFhQ1kVo4s2TIdYxA+VBroA0k6sOUOac5lZPgDSZbL40CifJ7ltDY4MCO0VdIfJLaxRJIr6iExJO
rHl5ab58ZUZjZ+oGrHh6dbIa64iscyOJoKwo5JrWOxD1lPHZ39WNMc2mhuahY7Unao3ZF02A0XLs
Tc4oOpjRpJLViISrqBt21JGLOnafYrBsE36lqtrlj6YikhM1yiDragUqyHA0s6GeadsWsmOQkvF+
NuiZ8dNum+Ln4Lhf7kzSw0WJqR6oFDKEtBL8oCRWIzUEnts0o9XDlB7jZpfGzT0pSsIduwRsdmoR
+0n9hdLHU0G+EiskM2c75X0r0XNs2z8aTGn06azfKzdR9pFNJZs0G6TiMRUUSIOYisULdwhEnGaz
KpVc1BI4koeyRt/LeNHY4KIOU1WlY3cQgpwnMXatTcTApzlj9om/kOEjseLYZuTTMbyGICI2c1Uy
CnIQwpymj9oO/NRIrjC2GqOSS1iPEwCcZreOQU5DGBOU8W2QPd02Mh8BDQeQ0RmWwt8hBRWzwJkm
s7rbGF2lemy/GCZzdpoSNDZM4BnzlY6iRCGQaeLaSnAfHOkuTUi3DcvUGSZynfp5iIy3b22BsHeT
DXmEwkQqe0W1IXu10N6NcbssEqTCrEaxvaZsaG0pYMJqJF2al6PcdY37c4SKSI3YYmo59ozbKlFV
b5nFkQJ5DwjQTbe17TQPPMJAh9lkuf4w6q3aRZRe4tOFGJcxu6SNAaJICNaPVeU1l47q2R3ouqfc
mn3bgsQbrBbwj6qX3d00s3+UVE8QQ9pTxp2AsRoLIfI1Y3+HHHs+4ZyyjZs8jE71k1OxFHxmyGfb
RNo8wf3Yo/4sVqZdD7hKFqKNRp5tqn2a0SNnTW7jf/rvEjTBanYhN+1bsR8mkanjcU866TcVSNrZ
M1P2HTaGxjUkIn8aD7AsWNdIqETsDT+XfM3SmRrSTfdZ3+nFGxhyJ/CqmLtMkRRmjO5xoDFSXqLi
pKhG89bf6rP7WZTf7tZ/omViSav/AF4Cfy9RcVkU6tVZ/wDtXP8AoQXj3ne0KJ/ovINsqtX+LW/7
WoXtZMpXNcWf/uah/bBgGYTLP/WB/wCWOWJJUD/zaj/YvDMBPo3IU8r/ANHUxO3GrZY5LbdfstTe
qjWIlkw/arp/9i5nMi2NC9ClfstjqsqBj1swctt3/a//AMmBZjIcXtU0q8h2liyLbUb+5g//AFNX
HSKGnmNmrrr99XAlngtpNTTbGdYCbIq5afyeu2fjr+dsX5VML/aT5auaUIngakYrwKJVfpiKscPd
RR6gi8k0v7ZON2mynLMzT4VCK1O4KU1p5DL5d2zU+9pFnCFfL+yS797/AJ67f0NIuRKqY/jlOv2e
SIaQ7dsdf55F9lf9ucu6iX7IXoiTX+1X7Da/7kp3tEd/Mc7HE3HLdyMNUQQiftsF9q1dgseiPlv/
AGwV/kueiK5+4zLvIYuwxEThYL7QP8bCJvNd+2vVeXNEcV6KNXbzGuRBMIitsHe8NdmDKmT37pX5
LMg8+qMTK6Q0mWfxFXZlhN4PjfeHfR2op2/cX5H7P0qdXRrQuwrYivJpg6ofufxL8261x1ZLqifY
1Cb2e9UJpoyuBcl4hiu7llG/aAs5UlD+6B8BHFInYbOKWRlEFR5cewfKkpIbOKNYtwLhWSmmy2cn
bhNThYznBLAJ3QiVrCWy5Wps6zah8FC4NnyuOFgHkkq6vtjlE8ds8MiW5XHhEi30py0kl7mEc0hb
FO0Goeu2q0XaExyyaVNoupmOcWjGiR7yWUS0xHGjapGm7lxq5pciMkPKjow+XkEN2wgkNcKeju5X
u7cSNKapbReWUu6ONJakia9Cx4rXebOkNYwZ0UM1rlMEnbixJSOW5VVfRoogLLb5liTugq2v86fL
RieQ14TiesjvduPAmt7d2j3EqPsQ0mos61d3w0gieVPlI3FkIWL45fMPIQEevmIrLQRClrl8eICa
iy7reQLT4CgWdOb3TnQ0YEQ3nTJaR49WRHhvIBjWNPuKGKU1sm9Y+blEB8dms57XC/CL71bkZKq5
zfHnVZTzAlSFDr7Nin1CBbHKWMsMM21E+fLMk2FV1BYx7q0YCPWWDXxpFK803yGwolXbiebUFf8A
Vsp4/gAlXQlsphEsoVNTLAW8uRADWWTDw10+qz5E1kCHRXg3ku6z6s+vZ9KjkvxLZzuNtCqaT6Zl
9qEIcq7RkuGmnNp0+zFWw9P34zrb07bV0Xanj/qUTrSejbqPV1DaxuoNSsGSvsmT4g9OijzLa5ZX
RtN6hYZljRDsDtktqARNWDNbTQMuIkCvZVDt7oM+U/TMd8Sr0y+BLsZbItbJdzkL8+rfouKuf24X
4Mnv+dMW6DDI2lhWKjbKO9oYqXv82Y9CiqAJHdNahGgiMZkXiJ10dO1pc+y3BkUUYXlS4nGIC7sU
VCu3c75xc39C9N8TEzTln2M5NksTjGZIt2jMCayQxo2jWXYIzIlohs7LSOPKQLA3De6jmyE3SO01
qgiBltksYxg8l2CCyHZNPnba5x5XaaO4b3N2yG82gaa1aJ4ZTZDGo0eSrFA5DtEkJxbuaX2mx7hr
iPVp0UyCa+2awg5DZDEVBZJsu2sWxQ7e23eRLQbY1s16u4mx5kE36s1pWHSQxF7OWdkjWkkqQtE9
BjsCtc2JKTJQmFVhkE28kI7D/wB6/I05P04jQhsSI4Vp+0umhtG7ut7F61FWqEj5VeZEFfua7Fbz
PQq0bLcrXAQqAnwJbXgINilbKRjI8hjlmcHYgG4AiAKcrTM7DN7UKMYjuUigK0LbWQiigTE4ykaV
4ZLQjNcIOT5LZDe8gcbZtfK8hvaUbXkIFqZFKzty0QhHxmduTHH5MWOiJ5KRWju0dKLKQoosposv
Td5tREa10E7WBueJVqpzGtlL3sBISMHUU5CKT3VMrpfjFrrRsoTHNatrdIxlRec07iOWdaNjMj6h
2kjlJJYaW2Kybf7SYFmkwSFaNt1fq1Ki88hG8d7a6aBldfu74zIYcuyHGYW+f5kCxbLESQyKO4v3
OfT3ffa17Uy3vkYyovnMKIrSMsrkcdn197ZUGxZMHJnsiCs7xxDUlykhvljE27v+WU164LwyR8bj
UDBsjXJRyYNmOUOfcMiil3BCmpL1pWutAAFb37zloL1r2PLGcsq8HFA+4KthCuo5xWeohgFYWL5h
OjH7ZTXixnJfRWtvtSLIZBsXxywNQRnitdUiYwkx5ZFLqMbEkamjtHbWr5xqm8dDVNUxeN7qBZqQ
pyxCQdUx0DaapQg/JcQlRqdsXJmsY6Dn2JJxqq8Wvx2sYvbu7x1gsSasYkLWQWR7bVHlBaZeVTqv
wUma2ERsiWSSequXVyl12NW21y+xNElOjFja47Me31MSwChFRarVb4DZusu+18hxH1dw+uwuvVK2
xsiWJokx0UgNdlCG31CSxa0my1urT16T9YGmDQy9yv1jJgNX/kE6ZbajNZt9vUnxm2fh2O+N9sfh
/lMjlcJ0TUSsG+z5SF1D9pJq+T+otxxtQ8M/VLVxdSIifX9nTbnyUg2Dor5V53mxZnYKW+/YeUpl
cvu736fOJ6ds26sJwdCvnCafUfeQ0lxFh2jo+fqJOEme42AmujuBqXgku2WRimex0S9UTDag76Hl
q90K1IDP1FuyXPedY890dQai4tl3KnTyHbxrxWIe+7uSJPcdCt3AxdStVsuwWRkSe6OodRbNl2zz
4ktWPi6g7WHvO6hpLnOh3ChRdQo9suc8zotm8Kj1EnCXaONjJjgui6hcxsm87yEmO5Q71wMJqHmy
XNUqtNxdBvUBhNSsexL1RvbqcWG1CwiS5biq5c/LHcXV962NhNTIVs2V3319n4uM1M3hY2iS0iye
wQGp2iZOvUktUmxYWoWxUNqdh2yZXcJCvnRsTVI1SRqNH5H1Col/VY8/VI1STeKQkbU6NR+p0ck6
3WTjTLyg6gWO02pUKg7pwVHqpvE2o1Kh5ryPh3z4+SNSdzGWL2GFqpWt/VCphtSuJgtTOGn6qcmP
1Y5yPtHd5mrSDbM1AWWjZT0dH1MYLCahK9xb152Q7okPP1XIw2pivQdsQT01TI2PqY5WypDjKvyv
tiKuQ7AkZXakmcDzHnUMh43Dv5jWSrM0h/c/dHt5cdJFvIO1xOeRZx4mPu5z0NIeRQGexfq89Gnl
mLjHuTAWk0TT2Ek+clVYxpocJNsCNI528chGq6dPYhCkfjXLjJc3aSeQ7EXAkktwx5iorlXI7iJj
iWGPe5VHvjGz+JVMiou6ibJVDJLb0E178dHl7Pc7kPliR5qoZDDUTFeqVsrHwZnF6Kxy9Exm+4oJ
TNkQJEdGLgorpGFqZAk48FE1SL9HlPQwCAVuDrCSmmrZEfAAUrvoMhcJSyBIjPuCpzma7T8hElxn
xlRcVNs36AAp1JRHYIUdXEFQlI1+mpPGRCJFdEhvkufps+0iO6OSHAJKz9MSVWRp44kgVRZi/paQ
jv0rIydSmgpGE4pA6cLIbY08mFjcg0757ZmmjR2fC7rnuuCGr1jacNIYmkJDss6g0HF/obLnynwm
bYT4N85GEpXQ6N3bkQeEhtF9k0NzZAqPYQKjliUOyfRN8WkVXyKJWMjVqmNJp1EIcTmf6MvblRFE
rk6L/Q36J8/msrXTHNoU4zq7sYMLiFj0P7JlSo0IHg+BTPMw1LwHMjqHK6tfLIlDxSVWK1YtF+36
K3JdSrMh0qkxKViYamRGy4yiVd0zlnLGtV619E4rJtZ2Mh0qmRKQbUkUuyEgO7sag/ZIpkYkmOo1
gV7phHUKBHKjK19fRq9n0djck0+yLXPcYNEjGToaBwvzyxXKmct+nviOzfKyvSRh6NGMmx+0q9Gt
96ujdIT6ExGz6xRrBqnSnDoBo2ZTcEbBI80PTzWtk0jWpJgua6toOTS0jeM6sUS1tQslzaNnGfUc
Ei1rikj0LGNmU6IhYD+5BokVp6ROM6teNaukUqfR28J1QrVr6buJ9KG1DU6ObIqn96HRo1smma5h
KlzTRKcbWOq2LkmiR2RKUbUWsGivpmuZawOw+pp1I19InC1rPGyCPukiU6OFaVXAlbTDaz6e3JlI
1zYNB9xaxGNJTtI22rljPX5wIlK+po+SLTtVttS9vKupcZwqZGtsqNFaKre8sKk4MmUjXMl1RAmq
6PdpaZFZaUyhyqpu85tMjWW1Ei5CqSFNFo+A51E17BU6pMjVDGD+nb5cULeNNQOdn0bi24o/2VlQ
Q5AUbWCsaJpGfSCeTWUDWjlU7HMs6VwJNJp/mj6pES8ofano3SFHSsCO2o2GFGpyrJrqBgwy6dhG
zqJ4ZVLp5Ea+rZx1BQKNKWicbPpIRjuqBkgNBQK4kivBCxkIUlNVUjYrMXG/NPCWUaDQABHlQBEb
OgrHs9PUI3sNEC3NTVrAO0xT+Vh4AIiXtSM8ejg+VKj1AYsaXFDKFR6dGhLCRBrsigBPZIoGDsnv
gQhRJcWe7VlMNY447it+nnx4XDWNGcd+nNOZPrgNh6eqWybGxfHp49ZZRrTNUUTXtoqJsOP58Yht
SadZMDp0AYgpepowZEZB2Iq9I9dY3Gp4sAVFeCts10JErtHVrT5N4VYZgAWcRQfztKmMB96JPCGN
SvbTSH4+mkMTSsJppM3asi1OrXWh9QVozQCf5Ou+3pT5XFTbNsJhvnbNK1iSUONsUEma1bOHwkRn
UvclSBNCKvO0syXs0Yzt3j9spyV7CABToM9tFRoXP8abXlZLFdVacJAuL3N2zfpt6FTr8dEzS0Hj
CJxHlpwe2iid2WrODZZBuY4CEsY0btBI5qZdMaqUERGRH7MztsMdw0YwclqypAWvY4jQq2a1Xua3
t2sLuEZROfjqLikmCo3UtL718FnC1iJzjx0aMxEG/ttIJtY3uvag8aNJCW1X70sNgkkRG+NYjayX
FlNRo5rFM4CFEGrbyOPtpZu5Z4rikDp1z2rp5EyTV9vI9QpMTT/7ZVYocFGUz9P16hyRGb2L0fEj
k6UcPyzx4qCCzg506sQjItYgWq5oVJDbIHHqUYRwuxgxMkNNUtUyReywL2EdOq0JketQbeTRuNBa
YcaqQavRI+NAyUP6UndWOgWiVp8l1SK4EHtMQrO5Ir0e2JBaiTXdtYrGlE6uRSkGkZoOMps+IgHe
awSQJXddN4IxLETGtuuRwvR8e7GhZVNBTtSzNHlw9CJV1SoSqA3sajRoSRp42jBOMQqiaQEWKNMt
DPE6v+8DVIWtxcT3ygjd80eI0EUUxHmlVyFFAq0E2TL8cjQJJDGqk789yQ2QX+akmrR5nASJGjTe
+awrGuZCrmgGecrJCxGnjQatGvt5Ph5B/mDtGMrzJcLKbRpIeazE1zQw2xoyWTvKJBQwK2saNLaW
6OSA3y47apvm2j/FDTyHynT61r87LYkKPOKs2TCaaPU17QMtJhByoYvJiRqxiS9QkdHZQPeZsyuY
ppTPGgQJJ1k2ENpAV0NoY86SbzYQfIiQGoM+qIjpS6fiLGFrkv2PxjfnSUbkSazaJJt1gGC/6jZ1
Qe3EvZJYEizs/qWaSicA6p5MZJv1UGkYXIlkz+Ctq+BI07K7g9RVH1ItNE8UGsrN4pEdJVplPWjr
g3dt58iq0wEMfxIKOt6aOaNpzTvF3d8VZjecHTbuxY3sRbKJSU305bk/3Zaca6DXE80jEfVSimWy
oqFxlm2I6mPY2xJ82Ow9i/T8D6czWVyM49IVvZBqON5UD6qeDJoqBSujNixV1C7aBpWiabCRo8Qb
IoZmGr0rJ0tiTwQNOCr3alneNCd+534z4xfn0b4vUjd0N8pmhkRa+/3QZl2fpWWrmBG3hqAvbbp9
yrNe1HhsE7WUEpSn8pGMjkYVb1Ps2acT6NerktGfZnpxK/Nv6XxkRncNRNRIlsnBs+Y5H6aYmSmb
As5CjWpehpImo4Vu9Rr5HfNTtTx7b9rYk1yWCfuGgWoeR/inIQpq+B2WypPabXp5akY0achOR0Rh
pAQo1sF2yWjNljN/bIEivamw4370nj9qxFRLduzamcqTlNyBd7c4RFU8FiK5rf2RmouTxJs+uQyR
qhrZDwIJvcDliNr0rYfsCCJzbqrRErKdBrFYiPl7eNff3vTPzpFNzqxFCJv8lrE4dtEZOH92Gn2x
jTeyb+2sTbO2iumM/ZGbtI4JxcNO3KZ/Iip9kbEyyb71jfZBpysGftrWr3CNRcM1Oy5v8tjd44E2
yez3iN2GJP32jN21TdiahZuyJXq8oWtjst7bjiOfMJU1XbaSZ44fLbIsKhvGPqVe0tc1008eG0A4
JGuZq3+2r9zQANajvaPDyyEjsgpxDqv3RyfuRNl0kieQbbxWsRstU+0Nv2rBm5K5v8QDdn27d3UT
f3PankWSfxobESdJT7f/APRlNahAJ/Gif227EcWi/wBbWKftoFjdqreHnNRXqT/X2ahm/wCvC/w2
jW9+mVPCZ/t3SJtScfKlf3z0/ih4tkv/ANWGn2ZvFC1XvEj/AOe+27tA9HrKTc9n7Q4jmpJlJ/Gj
/wCvIKxh6124IgF8q/swwMppjZw9dR1aD5btjfnSk7ks4qMiXszyp1BL8aTWv7kXWtl/IjEUC6Zl
94Wtp3iRO53yaUnuflsfswZkjzLHS8Nowak1C+tNSH84eqKpZM2tqhwA6jvF207u6dJTatNKKO0H
qeXtRamiCDHuoUuQdyMj1LRTLLVVgSti6Wti2OXIW8pv/nV1l3HEdwq6qh782fZR6iPbTJNqXZW5
pamZ2NVXSVLSyXHLoeQ9wtaHeCorP5FjVhaleEziXmpfas0cidu+1GGoRmtRuyJZfVDanJ4cDSVj
KlF1CJjoC5t6l9s3xE26b9CLshvnNDGRIVx90UwXEulYPaYOS1rbkPeZTBUVkcisBIe+QSmieNIs
VVoqWyVx7Uvcj2n+xpECjW2enYsF3K7F9+m39EbuC6YK4ldbvXty37v0eZziS3r2Lci86wysmDVU
DeEVMI9Ufp8iug3D141X3bR/7WNkPWcVOYhwWo6Q/tNlNLJWhF2gWX9iNN3GySx1FfjalTNbIZYk
RVFt2553jfHdyEJzWJOXkkBdmXBU4ViK6z4/x7gDnOHAIzIUg45AfcQV4pbSXMbWkV4xsbys/dhm
l70Zj+5HFxZEKiOtf3pFYmzt0MRd498mzn4qbLpMiDMhOQQ/5e8jWNkI5srdxo5ODByW72LuaQP2
55KNdJLzZGRUI47WtSQjhm3WQEiMEKU3LHdywHcGeUnOe/kOH+1xZLUx5keJEXvtMjRBejkuSG5V
L3OC0qNJZP5tr/2usFSRgoWzLB5FdJqHOyojfzhAQUfUE1yLXOc6XTb+JqxSKmleOWKfxKddm6kC
pVZT5Ajzgyxf6gOHHUHfc6j5eNqpUwi+7V99Ll4SHH5Rxid35EhBgjzGvDPG4j4hOzEjT0Ulm7vL
TMUKGnokmUfux4QHpMnzUY0cxHjkx3kP5CBjQZ7Vbatcd1Uixo92RJhnae5M0tBNGPPO0TPLR4fE
I+XJktACunteKzA+U+D/ABIYbFqyrF/lMpo7o759kxpyS0PHBBekuwnNBHr7FqsnQXSjBIkKFCtW
OPcD87KWL4A5dsNZppCSosCrcCVc2w44YFi0gTVTpMryGwo9POaXNWQVn5pyL4kfXcpjxontjPnS
cfd9im8G4iuiWFIzuSatvCHrOG50iOncdpUPAWtovlh4KJ+j42XLecA8VYVppuW1I2oaf6lLphpC
A0gpdnegU0Wt0sqvl1A656SEkwF0kj50uhBHhSFa0+lYiq6cn8GjeldYX8P6tGoqr6XmqLlgcr7c
djEHTAjmt75kfKLi+NdaZdZS4Omo4I2qoYoNnph+0PXzucsbVe7Sdc6KPVMbzK+L/DtKOcw8B1co
J9k7z4WnJjIUm9oPrSRKAEBZFhDhTZw0twV+nPpTtVW448T89V6r03z8LnLC++F+fjNP2vhPDKbN
BaCYkqERgo8298eSkxpgx2tbJI9rxDA1jmvYM1lKaoKWRtaz5TVjOTvWURRxg21mnGQ/m564vRfS
uJi4mAbzLRuaGNau3FP/AGO0wnjod6du4aikphI+UM6KO62XEbyl1D2sj2bkUYDeLYx5jTC7LUKa
VsgJDXIdrX4oWcQmQKve0zeyxiWrG7NRHHpStECaZMjTEVDMaTHSEGwlsgyCkNO0pUEllYo51Yxj
SDOissGororBub440e+RwaGzbzOrTIw3ab9SRr3SmmbwRMfwE+LNa5iH4vkyUcyNMaikOmeYijvF
5KT2VfmuleMWstWHF3EyZZIHIF20jkO0iHnIFrL1EOKa07XyeCS7tBEg2jZA1MiZYW3aStuUJndR
2S7FAtjX330lsNhpaBQ97xkRLJsgbjI1LK4Qa1l0wze63J1ogUq7hCtO9C42X2GSLztGBPZJY+S0
KMt0fKbMaouO5JzGIKMdo7F9iiw7k/M1M5HGrZXaDfmR+U07xpnmoYYJ3afZzN8hvGdqCVFlWiBH
XXbH5IVTYk3xA39mh3r7rkOUoHU902SNJDGNtr3KW+VuCkMI20uUC2NfvZIiz2SRzbUccc27e6RV
XDZTHTxhHb3qkylvsbNC1tzfbMrLp4TRrARh2l20SQbpVmiPHIxs4Ed17fo9KS95qlmAbbi+UuVN
y+MUNlHUdxqBqNFbGaauuxSB2F8IQp1mQx6S/a1r76MIVxdvkrUXjor230RiXWo+5kWxcA0DUkV4
bLUzEYWweU1NqNg2n1NGaC1t3S31F0sNR6rhbXN95WUl74Tv1RBJkjVUUbLi1fYk6D23pNRx4Qz6
0ikZcTEmmpbRle9muAMFeXw7HIR/FJE1sEI7bWIZo3k7pqfVLa8cjXTDMsZvmEqL59dn65G1svWv
ebB1GSLIXXyo1Neqi2upiWLKzV5IY36+Xa01KWxai/uq9UErEJr4z2kuiEkj14cQya5M9s6wJNLX
3Bq9T62kFaeY4poer5cIX69lNwmuJZUmzXzZULU8uAKfPNYmG9WOiapmQQl1fNOnNXmgXciA42q5
hsFqScBjbI3fXWE5GF1ZPenkOUoNSzYo36rnObPsj2Lt839KYvT46O98X2R39pm+/wCRuyDbmjIe
yKZRW52sLIeZwLgzGsuDMVuopG36iPjrg3ItwZ7RSSBM+3ORiSHNKlsbhJO8jnOXF9/6g3cXRr4g
EW8NISU9SLGtHxsTUJiNkyiGwEpwHD1AVrJFkaQnJWEDdkBhLkx0MRyrFtTBRt8dUPamIgrowsZq
ErsdekXCWhHPFfkZj9RPekqwcVVKqOjXhQ4W+KVo7MjMHemw9yZ6FkuV4LUosfcHKhSqr4loUeJq
A7cPdFKg7IzVbenRC3Jy42aUbhahI3H3pnoacRXBvShT9QmXJFmQmR7cwc+vGfi3Rdvqz0cy7kuZ
9WO3Jc958f0RdsiTiAVt4fhImkMozuG+PcympJsylRSryi2Zw4W4kEaUr3rHsCBVbuU9siSV6ikk
G4NzLRsucc2IVyOiWskaSrSSXHmVViz5AlJcS1YY6kUByMc22moyTLKXI0woMFeTeMm5lkQh3PdG
nyQ4WymPaksgiAvZey3M9uSLuU5rTuV6S5rhnaVVCZwXBuLDJUyUREK5r4trMTCyp2EszvwE+QzE
s7HjJsJJVAY6K2ZZq0sqxehnvV2JiLkZx8UlkrTOJuFyqrVsNpDpGNXdQ+ZtI8tEV3vH72EbN4vV
24mkdiAn7GUqKzdVZGlvaYEpmNVUyMKURSxZzULy3AMj8dXzNjDeNWoq4kGWRh4pg41eWBhmOhay
QNE9ljgeVSU8pEIN4VENSY2lORkiIWNjUVVDVFOkmpkAT3RY8J8jCUJ9niULwRlIv0A72S4hImN9
8jwXHUunzo0g3CIvv0bkaM42fpkipLhkhujtc9wtPklJOpyQ2jYqrEqSTEPpoo2uEo3xILpKu0uR
WyYZIjwieVwdNkMyfSmgoNrnrFonykk6aKBnF7Xwa0krHaTKrZcQkE0WK47waXc9lnUGr0E3uLB0
8SS2dpg0diIvKvpiTFLo57WzYz4RYUJ8p7NIuKK3pCV+RhrIJB0oSWOw0mWKFBryq9Pll5J0W9Ml
xHwz1laSc9dF7iuKclY8f71rNPlnpe6bfVsrojpr42jHEE/RHte0ZKtdv6a+67Y5MkfORgKV9TQc
hWdegXQ6XmKfXKF8Si3AOmTmlGjWpTMdhKT7paD7f0l3lmouAHxeMwdOnan1jhY9myr1X+lT1yzi
jo2oljT9tPFUkmJp/iOVSojZsXtPqKRSsdSIjLKu7OVNd5r2UicZlPkKiRGLUsTJFLsyNT8l+lMw
tQjm2EJQq5rt+Lkx2CGpHVVD9qfUcErabuYlUNuGp+bT1Du9DpEGORUJxLVqpY9SxjG1rXYel949
MNqfTm7rTIrLSAoMqabm11QnCyr+1kUfORCqEeK1re0kavdJLFoEaK0gdpamn7mJVtaj6jm2yrez
hW7KuNGpHVFIjk+kN42FTwyBSKUoqlqJMp/2/SHvkQ6Zg2HqU2m1buVbQtYz6SnCzqVblbSq9zal
qNn1HsGmeU8apaNkqo3Q9Q/vQaVGsLUoqWVSrFqqPPpScbKm/bApFI8dQiNnVG7PozvJhU6MbJqd
2zaZe5WUaNxalHMs6bbKqkVyjqERJ9Mjki0jlkRqdGMl1CObJpnNkVtIjGFquTbOkci1NJ7JV/tt
KVHJVVfFyQPZ1R3G3lYkdV9lyNG776mk/atZ+21ouTaejV7hVCI2xpmkbHoyLLiU7WMmVKObKo3J
JrKJrGFqm8LikXKWi5IlQza2o0Iyuo3POCmYNk6oa5H0rvMrqNghmq2cLijVr6SgTitWNEuKHuhp
KFxXDqgDZY07Djj6fe2bEpRxxHrBvbY0Csl0+n2ja+ABUu6DmlDp9X4sGOxLSnQwazTrlkiqwQwn
rRyGzNOr5dXQsiicCOXL7T3JaDTv7HDiotxSNmAfAUMrTtIxoZAgMXVkAaMTpDjqc1HQtAJ5oqlu
aRsoWntNblI6NCbIgDmgHppUsQQg1gWEDPy8045TU9K2IBJ8d57yhbKDp7TX3JM6PCQ9eOwjx9M8
bNzRVEeMUNmy50z/ACq6qHAiiuQypOoKDyhac040aTLwEJ8yAOzi1mmOE2XIHRAgyh3ArLS//YxY
LKqNE1CKdK1Fp1JQKGhYAEzUAYsidAHaxaTS6Cl2NmOhDXnHdxZGl2ts3BZTxqvUArGRqDTrT5T0
44cOTqlo51pWstIVbSo21q4oowtfrxqdDR2OFqSQSsgaZt5k5utIovATF6rm3t6Pjovy9Mke7s0p
C8o7hNiguZ6vJQy2ygGqkkvILxQDm8rN3vH76jeKS0sgUdjxEqk8mbG4RrZOzMoZ7ZSWcFCBsI/Z
KRMX4/pJmjov8Mq9lZ8hhG1cdCWqs4jlSWolg1pzwIyMAYyCy1I0qabiI2Ob7WKdhDcftuI5DuRF
FIO0CtnOK4b0QVkFJDm0SbOo25Mq+K01LxyBHTa3EiZEEnGVyaoE5DbCa55m9nAOQ+ToyDxbBgsr
pDyqcrdn2bBO+s9yQF6dm6b3H1sb7MkiCy0Kwja6rVxKwSNZfCTjUbCfCY1Q6gGmVI29uUjmZE92
3om8ZafvVM09H8iWCLwEMv3DwkOwFdwQz+yoxIcQqtEednjpGckhC1vIni9pgjIpZEBCoGv7TSn7
T1jpIECt2WQqRsj7ShrWJ3CB7DIh0M6TWo9RwkCzyeJiRGnHHreGTC+OoWeUNtYnckp4w4Z/Jw9a
ik8VI4xzNzyITSsjVyDSRKURmgSSEFWiPnm8VIL/ADGvq2uKYSRgwJbilk16PwUJADJNcyQSMh4s
me2CRkgkjKtqrG1Xxwnz85pqN3ZLY6R4kea50mRCaQUOvaBs2W4ZY4kkxgVze7bkUKVL3SkfXNdI
lsSNGgSHkkz4DXNBGbGFJlPSakZpY0KC0eXR3tfVp5IG1zFl269mNSPeU06C1+OEkeKM5lnFitfH
rIjQMtyl8msZ3oYYLUlXzlYzT3NyS4bXFlN8eDA7qzJkdrgwgNCKcpnToQkJEhxWoTUznudQtdxk
RWeXbqooFON/kzwI8QxNHGMMpLKMNFiS4yku60faiajI+GWytnT+iZppu8lze3CFFc+e0aOiVYka
l7GfJnUYuAO236jqVFcDTsJYb7NiZKTjAh1v8t3vBqGograEsmxox9qMFn/ZarCp2afhpDLaInOz
T+BAre2Y6fwqxNok6u8qzpm8YkJP+w1VG8p9BDbENaJ967TlCq69kZZf+rX+1eWsaezq28YNan87
VMNk2RRR2xTz/wDb1G1CRaquHDbaf4Qf+QOrGaxh+9ZfkUd9o2UWQL/kD/zdFOMiTWBOKBHhMzXh
TpFTpvi9E675vip7YqY7dMk+7s0L7Esv9ewT7+mJatPD9w3z+LIL1dbC2WPZcUSrO91qknshj2DC
ustli3ntI0oq/VJafx7j/MTHZt13zfN/SNN36ZVqgs9kHZnc12m3opHtTxbkisWAXlIgbKC5XbDS
Nzafc1RWe3BTv+oR1+0/j3SN+1OjvkHhQUjMlykE2qd5bzbBalmLdVGc0dG8Ib8tGfthpxSSrdwt
3HH+ZyJtXNy0buyPWcy/tC2ytEZhCvkFqKzssPJ7TXzWml1Wyju/bITfLMyMgWQit4339vluBJrD
qob73Sl3RkrjtFROF98S/wDJ+dKf7jP9fZPKCn20RONin3ICbDEiZZonCsTPblJT9gmfymp+1yJw
nM3PE/xDTLViK2sbs1Nt56JwgN+9thUTtEb/ACY/+FnxZoiurE/azblaf21Ldnv/AL5W3ZEieUn+
H/8Apz28iwU/jiy2RFylbtn/APUsf8UFNpRfgv8AikNTvM/0tRO+/WSQKOE5FBqtq4T2VM0gn8o/
+qm3mO/wj/xWG3Ov/wBQW29ttz0/tsv+ey/14Dk+oyf7FT7UvbvCVPHi+7LhUQ1GvKGn+3b/AOOk
cnnSfiR/r91ElOX7MX/FZkRhahd4If8APdqiLQkQhZC/dsP9SGZPLlORAg9wyjowsBd40Vf3XhGi
k0Be60ip5lw7jEqpKGmzF2jov8c0tGSQL/DlTHgu60ndh64sn93ffPnG5pn/AGjf6YpzfJZ+2LWu
RWXMxI0ykfzCj0+pajJ2x0knyTWhERsr91fCse5Kc5Gw6pyKK1sViWNKu8aMRPqOqz+OPT0hZJLM
iNNZrvX1U95zSnoyHWva+HNmujWtSu0WCZPP1gckV+nSukEsjJ5N2v8AApphJTrEiDiwHItcWaYF
vX/sgVr08zV5Sgmade4rppEWbqvmtfp48mUy4LxYD91VGPLFbgXs1l2/uXWiGcQf8hburtBJtH13
u2p0O1zQa5XanTp+PUnxnzn5dkhM299GSEDJlO7obSM4RtLwE4jmNCk5UkjSMorX38SV3DHiwezM
k+0WPPcyzkG5Q7v/ADaXhqyXPM1I9u5FKTFzfF6rm3oTG5ork2HZbqyx/wAmmVd55VXs3jlR43O8
mDu2Pd78JC++leXg2fJRx/a1bsoT8/Jav2mRkdkn7aSIj5eUsfxsnpyY+ue4pBEi4zUCgyjsfLZY
F3SO5FbYo9Vg79pp2tWW7kkL7aHchsSPs2XyXJNbu2vjf9kwaIC5k8cG5zpNXugrzdG6dX7xUR4o
X7Vuk5D8V5pNUzYVzHVyVns2xa9yVvJrbxycZnsVV/dpoyAmgLyC0a9/yEYNkxrsmNV5AE7bWTm8
pq91kNe1jpqNc8/dGJqtK6WjUHLR7ZDVcYRkYMU9qunblyG7tY6e1r5Be6OI1RuLMRmJK7g1YqmS
QgxgnNfk5qkdDJ2WfUE7s13eHCTsqee1rnyUKEQlQxpaDECcj2HEryiOgQAsWqScqmyv/joSwa00
o3eHECoyzLBGIyYhglAryllIOLJiJMe+h/dSj7EXVZUdj/nfbNNSUFI8nuxwxXd+dOaIUSwQgpUZ
ZBGSEixotq1xJ38jKxnhNPatZKNI8gEOH2pFpZtEgLBDDfDUx5ExsePX2bXsnh8x8TaDHS5Gk6WT
yhVkXwlsbcbHtneTHZW8pFlYsCKrtmGZKhea9DMgRIt6N0qf/NbXR0rmTrsbJiSklxolagj3VyMA
621aca1ySZEicyBGrb1j3zgpY5EG2rAbUQ0sHHSbGrq5kF97fjDldbMlA+ljMeytxwYsMq2VnXt4
RNaQkK9fbG/OVM3xDwLZtgBtUHv3l6yCHT2oGnw0EU9ZEsVTGBqhr7FXMsWRwAq0uNUfyqy0SfGZ
Vx2F1FqJIo9P6g5Y+vDMWwsxVUWDqZyzv2WY2+PUjsdVOJMrLZlkBIUeK7U2p+2mnNQdxroACrdX
jKuLUakIktiDsxmkBqgztSGNPq7RlmPx40LNQ6pc8mm9Q82rFBmoNRtgAo9RHBJF2bEVhZBqo36j
OefUWQ7UJVBDS+1KWYTTuoke0jIqJqTUqxl05DHPLXxI8DLYEWeGPLDR2ZkjW0UESHWs1nqRshnx
6d/UvR3tkj2X8wJixTVN0koFzwIymlsGC3t3DWutGkj9wSmbKaoUVu5ZTGlkWDVD5CMtn2DVj2L0
NLgmGMVra+0k/cc5cXov9BMEn7qA7AAnSEUVmiK/TxGixZbVFcq0i1rW+XDmN7VuZpGyNu9SyGDD
OMjxyHdiVW2rCBcrHqeajGxbNitIRpc/YjXy2BI2YwybtalkcaNe7kemlsGyVNa5oLFrcUzSo6T2
mSrntki2TDNLLaxGWyeQCchBuc3lJINWIZgLFs9HBt5HJ1c9Ek181GjtjNKyJMSLJj2TTNbMQazp
KFHG4o+JJRjZ5WlZHntC7vtMnkdtLewRckO5OVMAZQupbrkzy2K2wtkGkG9chQzmHbNsWhZ9ac00
K2adh5jRtn3So+tu0I10pqNsbrjlbe/uZPG9s62aJorxyHi2bJDJU9BNl3bu/XXKFYWY1jLG7XKq
9V2JMZwsrjg2vvHsMGyGds+1aBi3ZEPAuGyByLBg2WF0976q+5M85iNuLrfKm8Vjh2I3JaXjRpHu
nMPDtRyBTrgYhybp5D1V40jS2ghjtLpxVp75WKlkLjbXmUtyzPJjPw9qOMK5tPKVy7rgCuE6kvdm
uuQNbb3KnyouXxnhu46tttQJtFs3CkQb4JBWeomIyRaEKao1AxGSNRR2itLd0p9PeeKv6kjo21vv
JSDZOjlj6kjdqy1KwqLOcsit1KNBzdUB4TrJ0k1Lf+LhNVxuFleOlOrbN8Ig9XRUHa6k8nBynsNA
1SNg7HVaFHIlqctRqLwmn1gJ4Z9m+Y+stXQVTWQeNrevmZGlPCSJrFgA2GqvKR5HEdV6nfXpM1n3
RzJbpRKy1dAc7XG7LG3JOdT2q1Lv185rLfUK2mfnozduVtyWue/W5CMmWL5ZI8pwXD1nICKxvyz8
GRUdC1NIgtmaqPMYpFI6BaSIBCaumEaeU4zxSCCxNYTWDm2pbBWuXeNqCXCZM1BKlN5+8S0PDebU
s17Xk7pBSHjd+pLBGSpZZjmPwV1MiNlW0iUnJdwTTRsLezi45Vc4RHMz61LRpjEO9irg7GRHQ84s
hGuwMownPsZRER2MeRuPnytiPeRzHPHn1SRj7GQ/EI5zvMO1HzTJhXc1VM+fQvp29sX2xfiQvRuR
iGbhTyCNDIkJhlKqxznTENKY4cuZiyJmFLKVVLJ4OcTn5EjtuI7khpXEqkXHdF9K+jfExFyNMOzP
JlkQ6vVRnIxRypuxnFXObmOBJl4Ux3NfvkeSdMU8tzSveuCklZg5M3Y0k2yTiiwM6Y9CTpTELKKq
gmSd1kzNjmI/E3coWy2ISZIaiTS7glylwsmTsUj1yOWRiulcHFIxwrCRu2XMVDzJGKdzlH5bkOEu
fuYsY0pcM6WrXq9HR5R83mYeVIbjJR1cMs/YkuWiFlkRwJE1cMaaiHO96vXN/ZMEVzVjvnvacElc
3Vix3zXYQUt6Ga8axzyFXhNchgvTGEI1QtnEQ0UqYKIZzhxpqIeHJzsFVwIkxmEBLXDicNWySDX6
ibZxnOxhXMUJZZkNDM1ooz3qOvm7GrpeFE9ixYkkmEiTGtKx/KLXmKi1szDV5m4GpMXPpEtuOppO
SIjg5HFIIq1cpWHjvCokI7GVsoqS4hBdPJK3FIr8jRXyMZTS1aamOjZIVE78riZFhlOv0U/GRGfH
wIXlcyjK5JdcYGMarnBqCHw9KYOKxWLFriScfQla00d4nRYjz5+n3qyVCfHwYVe4VE4rZVMWM1o1
yLVOkoXT7xtKFw3RYL5Cu045UmRCRXxwOMo9P9xs6nJGaNqqsejdIafTjwNcNzSQqx8nH6ZXaVEf
EfFiOkK3S/JlhUkhZHH3Vj6d77ZunHhaADzPj6cUzHaWTJ9MWFgAOMsfTJDNsoToT66qLLz9LJxL
pL2mw3RSdYkZ53RtLqVljpt0VGM/fXaffIbL0n+yRHfFLWVBZrnaQ3Za1T6wsKI+W8GkVUdrpp0R
lVQmlt/SOyS9JbMgU5pJ26P3aXRrVZbVb643TliIrlpdPmn5c6RSICkpST3N0grWn0g16WNU+DKp
dMFlZI0axGTa4sOXTaVdIF+jmsy20lwDS6fLMcmjGcZOjhkbaQHV8mmh+bJZo1pItvTLCn1OkUID
9JAy80l2Y9HpgUsGpdMMr4u+6UVMs9wdJR2jLpiMuamoHVZ/nNv6CZ+NvZccntI982yOLukqKP8A
ZbQEGCprGEHc1atbUUyLHJWM7gKhnb+msVxqpu/0JrmSqNWyEp29mzhdmRCrWPFZU6tQ4O256epe
iYvvm3QQ3FJT0aNZ9LYrbGm2yrpe6RlaNuTqhFalS5549SMbJFU17ZlU5H1tKjB/TWObY1PFKuk5
YysbtNp/2x6hSGFVtY2RVNc09S5Swado2OrWOZY1Gy1VPviV7dptQm0Ol5yB1g2pJqkc0tQ5xYlS
wQyVaK2xqF3qaNBM+mtVLCo9q+j5GZXMyXUIrUpnPkgq2CaetRyS6dVfXUrQjWuRW2NR7VlGiKyu
aqTar2j0qkOGtY1JNWj22db2lK3iuJlLCSVIjVTeM2ra1kuEnkVlSiCNWI1txE4ZR1KKz6UnG0rk
ZlVWoY0erTjMq0yLUoiLCRuEqOTB1jBP8dmNrEK25rkZjoZOXgGXHxXjyDDWUSmoft21Og2V1SmE
gIxG1aFHKpEIWLVNYw1WitkUze7GisRjIbXuk1KMyPCYiPjMRzalrxXsLtkpKhO2Wqag7qG1ErQq
smtp2kDqKuQCNikKv0iTja0g30FSjmSIQg4lcwwdRVyCRc23yuirJNVUaDH4Ily2pO62nodsSEFu
TqlpGRtP/wAoVcEDJFcwiTdPo6TW07QDdECRtvRc8paLg3sR0ywqUMOp0/8Af8YEdsmvYZq6d5yo
laOEB4BSGW9D3H09I0AlSO9bajQ7KPTmyv8AHDkqubIFG04nnJFBXidHFNSx08jpFdVMhA7keVl7
QtKOi0+0QiyIrST6lkqPVaaRJZnArhLHZLb9GFEnkuwRBVs8do/UMIfY01UIQ4YwxM1mxPN06+PF
DK1SJCQ0SYDW7BjInxg/nSEBsgspzYUWVIDJACK0t1BjJFhushHfqTgeVpaC0UeztGxjan7RYeia
5r0tJPgxnyhTG1Edg49nfzQWcBiS4Z7GFVWFhq4z3UZSnZrhonNiaXLIY7R5Mn0xq/KGhWU6ugMh
B1Uv/VaQCNY2sLCXEdpoxpArOsEedPVlTCo751ifUNYNmA1iFsetnWFjLe5jK+i4FzWMmWGbpxxH
h/5AEiSafTxz5WgeCPYon6jInCuqy2D7aQjfpWlXqsvUFb9Th2+my1QdD8VFrVhliaOFJYL/AJBV
v05MXqvqRfb36OT2kZt76ZD5Fi0KCj3k3k/TU9HZ4TZaPjpEFNm7T4vvHOrwvWwR0mFso5MBpXHj
I0GoGfvoLJ3flx0eG6B2yvT3d6l6p00wBJFiokEIcl3kmjo8YYiDZKL2lE3vCBBTlKTtZBf5CLCa
QxQ9pgTbnkR0e1sRBjMZRPaxCjBARMlbiyG7yGeCilkA4NjGVxTxUIviIMbyqx/ZQogwERJK9nIq
94bYCK+SHtNim7jywkK50btjQ6tOQCGEKCjGSH9pwG99g69N5Te0kInex8Fr3ljoJgzr3yRkMjYK
DYYiiIxqGGGA1MlfZyGvdS+it2mj4vX3VPnSMXhjg9sM2ftgkSTYwY32bGZ2FsCtluo46cJ7/HSw
nNJmng5IZ2BmsEU0NyPHLYqEj/4rWb4r40oktYpVEydtKcCpRqOr0yXWo51VTtGkMPaZbs5x6tm7
bEKqtc3iPxmvfPTsirDKZ1wDtsdZueStG9Mn2CDCbUXBYZTzTQy9mNZOSRMqBI2PcyVivmy/NdVU
3HIQ+0HU4+bqrT+4/wBPuXJlF20qR8R2sXuLVj4RtWOxV90+dJhQkl4+1EAQnmGAjxR47RMsSEbI
hs5xARWI68RyZR8nsJFY49gnCLVdzy5gWvZ20YGR3POaJHR4sdrGXvJxadOcVgGeTdb9jT4nNJJj
tcslvGLHCRs4o0UMUTRjtWELKrWfwo4WoTULXFTTou2hRN8myTaFVAcObNYjgsajQyIzlnR27RYj
ERNRAdJJRM4A1r+xtRWEsMjRBVINR6gU60d9IA+uMsmPrdVWVFGR+UVFslnZiq41taOsTYmATcmk
InZZas5wrGwJHJpaN3zbchajMsOXXbzptUPtRNYNY1FmFlk0pHaEdyxHQWT3jmUb3PiSIEV0hi8Y
l40pbagoER1tbhq49HvdTJbmVMWNrONNJZOjTEqIgwRBjf3r2P5NdpkRQ5aNhplb2tmd1bbUSI6J
WxmR81Su1VS077BYkQVWDUOp3Sl01qTxmPtKqQ+E8L2XFV9StZD2UgK+WssVuMptTg+zCj2tWWVc
Me+s0ajmkvLFa4T4w7eFQ1hYE65sYddGq50Wdn/IUYvZT36bdd/UuJjslYmaT/8AVKu8e6b/ACKR
XtmVbvtW/wDik7+dAXYFiZqN/ctoIqjEK2RSlIjo+ol2Wl/9cv8Agv8A/ITF9W3oTNIe1sT+1dvO
ft2v/wClYInCK77Md2TcqUxNu7K24j28539rtu3O2RY6bDBtwnKm1Sn2Wf5Je20Xbyl+SL9uT/mE
n2hbcLDbauT7Q195qptX7KZP7pC/sdt5jf8ACn9lnkH+we2Tviubtjf7pO3Eaby2p+13+Oam54rU
7Y9ss9u3XJ7X39k//IuJ86SO16Ff/FvjcXUEjc8EiePqJ6Jg5XCVQParL4qcJxV7mlzNeywenjzH
7z6xqtFNkMY8Co8NhCWQWPEbHHPmoFtTyMSUnYAbULgmZZsO6FKYjYpu5k1OQK4aothJGFYJWmGJ
uz7Ff21fsS5TuBiVezznbFHbWRDvhAUx6yuQY7axSK2NPV86pJ3I2rJTW5p2Okl5BJEDXSO+lwiP
kwmI2PJmdt55zCDq2/ttrJkVaw6SgarFxxflu2aQX+RIVPEG9FmkcnbGv7LAic4P+qFU5W7+K6fd
uNXJ37BfsVxkWxkrsxy/aklRZDHfYjuRWXBkG+lX+ExyeRcO4soTd2SdyI6Uv8YZuU0zthRnIo7M
3bJXLvCARFJdv4O049SIQieTZO/h1kju2Ex/AKO3FLN/JAv8aGRHt1BJ7BqByrG1BG86VFhMrI15
dvlEPAkMWq3WXT/6OtROdM01Q9xlrYsqgTnSrh8iGSKq4mC9s0S96rqJ6sgKRSG0w5WzHLtD1EYi
2teqtkaeVXQf+QjParM0Urs1i5zK2gVXzK7/AELUpvrtSv8ABZTsl2t1NSmAUMm7LpWG+AfUycqy
NFIdxK6VBSLrSYEenbuTZP1Ad0ev0s7nF18hFkaVarY5ytZZ6kY6RXaaHIXL4jDR62rZDhagtZc+
T+litA6ORhotcU5aRvixY5kNaawarw0ftDk/s1FP96zTscqWclUSr0h7m1ixz4tInCDBei23/IMd
0mNosKiB/wAjPRYGKub+jb0J7Y7N8d8SulAdI9kE6Hj3kNeWmoCK/wAxsVvktlinxN5MX2jTAPKX
weL1/wBabJUNgA+8TUTkXKKF9+RJRoLoiEcT5XF9829O+fPXTx0jWTDd8TY6988hEYKcjmyBqVWv
7I485vKQvcSGzxmrMa0jpHdaICoc0pGoKahEOHuuQ3bYKem8n7qRf44/NRr3yO60Au2QsxG4OYhU
cFXEWRwGGwTJP3sju7LPPax5i95kcXaV81GL5SFYgvuvlcGinI/JLO84ZeyxliiOOTutj/Zx09GP
WShWjHxKSXwwc5CIUXcJ3+2wVh+6R99Au7LbuYnCY/k/G/Okgq3Ce8a+bu+lCrpkLbs6ib+7s9yR
RNRg7xv256fd0sLtisv3Ak/ssawyOBYR+8aGqCEjGkdMDsNa9CuhR0jvlbECSqYQsyH2WusjCJpy
SRWWD+Iq8yZaAQy1vGOMli1jzvQ7I7UDhpTSkaJiCnxfIfIqWtFXhQVgx7WwdRGVxqsfeNTIjY2q
GNcmmHoN0siGFV7DW0cjix5CePMB3SPjOClTIRB28ZslavjFj6rlo5M/On5iRZIpjZIQxUQtlbNC
Ktt2yRviNOQ01sOPDvWvKdElZH4VzJGoBNmJK8sMaKwD7e7YLIVsyYJsJpC2FqyMCpvmSMMFstfI
HAAPUY/NI/yhxQsr22eoWMkRbBJgBRBtfcXjQjp71klHQmyHyrBkCNB1K18kiJLRvaqxzdTsZPjz
Wz48eOOKt/qJGJU3jZwkhCIS1umQw0mo0I5wkm5IlBrAU9ik+bNF348TTzO7fQQBj6fpH7xh9sF1
WoUlIrUiWtR5zwU0YQda9tubZ8ZGapCaVieMy6RCRLQCAm6SrlcpHIkfVkZgzafi+TIrGoCNrEA5
CRx9w2mI6Rg6gVhondbBsKO3ZIjkqQkLIshV8WgsRndPhgnLHjRIrbW4jRJjZAbCKyFEh5qy8AwA
PcmmGxgAt5Uc0ajuxAkSxwZqpYxa9ltqUh7GlvQygyreLFGy/wDLtAW0NYzUq0JKuIDI9QWFNshO
rQZqHU444dP6hdCkEtYEyLH1BDjn1DZxWPrNSQpYEmU7M1LqtjIukbmPEU97VHSXqSHGjVOrXpYO
vakwvr9aDNUX62sheu/Vem+fGJi9FXD4uDerHUV7xyxnCMGosBhbbWqPbTXHAL7ITiR7QfDzwcpV
oJmOuG9qwlI+SC6YoLaYh3QJwhBsbjdJEhSq9ei+hfSmMJxWjvVZjbYKtn26LkS4URAW43JNtR7O
s3sPBu2OYa0FwsLVXPqrtUT6oJWWVqitgXDhPDbick61a1Pqrxmh3TCMk2o2pMtHOfWXe7VtB8LC
05ZAuVE8NqJ7J9siIG3IMsS6GRsq2YxJNs7uV121WvtB8LG1V61t128bbCVllctTIty4JY9yIjZl
wxiEtnoWBeMcwtsPadbcnVl7s36sFW2VtySDduE8FwNzZ1w1rfqzhnhXbHpKthtbZWKlV798XG/N
HZMEi3AVDcyWkWplIIkW4Eg7icMuANxlVloMY7K1ERksyKentGMSRcDIOzkIr6i77bfqIH4e4Exs
XUCIRboBES1jDyXeDR8a9EVrrONlncM4qfctRbjC2TqEJBgv2CKl3HI0t4EaT7hzyV2omcZWoQo1
l05ZINRg7X1yNvM1FHUK2CJOXUgPGspfkkqpLY5YupY4RW90CSyNPdGkRtSBeF2pQCJKvhGbC1M0
eLqSHk7UontgaiWO5uqIbkk6mj8LOwdKevwmMfstNqBYmE1eHt2Nq6XkC0fDezV4kbY6h8rAynjJ
E1U0I7DVDTtIZTFrNSLCbJ1ax45c98h1bcLAc7WbFbPuVmLGlvjkBrFGDsdSLNxpFR1fqp8MUvVr
5WFkd8lbeFrnm1or2TLJ8t0Wa+I/9blRtjePm4IvbfF1YaMObqYstvcV74F8euyVqwhhFlvOsSaS
Gq6zOjJdkSdgTKJwdVygjl3hpmQbc0BzdZyRo/WkpVlagkTchahlwh/rOYmE1TKkNDqSWHF1ZNbh
NVzHJMmFlu398Y7gsW9lAYbUEsiPMpHxLA0fC6hn5JlPlOAZws+vTGNlWcmRg3bYC2kDaSzluzdd
xSTBb9UlYSbIfgJBWYthLx1jJTHGcRWzzMRbE+PIpMa7BmMNFlHXGvdnelcSlkbNXGMfiuLjX8Va
p1xUkphFNgxK7FZIxWuTG++JHkLjo5Gp3F3QZCIgZCY9XJjHricnYQT241d8SKV6FY8ePd6V9X4V
ei5Jxfn8xwOIroZ2iFGI/DRyibGCUuLAeijrzqngGx9eRqfTzbHC4eCgmchwuYoYj34aOQeOR2Li
4vTbpv0TqnSKBxVHXHVpIzxqqLzDXSFaWEQeFYu8eCZ7XwTsaRjkyOAhnJXGRDxyMxrXK8dcdzTQ
iixzXZHhGIhIJmtex6LHrTPb9MNh4Tx42O97x1Btjw3jxzXco9ad7SQCCwrHNyNDJIT6cYbThezI
4XmIypMiHjEZnae50eqO5pq8jEMxW5FrCnR9WRiHE5josIkh30cnGTFePBCeQgaY3E8J4cbEeV46
UitWlc1JUNw8cz36MVyrGqTkaaocxpBOEsSvLJx9K9GyYjhZHilkuZSP4ya5zEYN7nR6Mj2yKlzE
DUlK5tHshadWIkApCBolwlL7SobwqrlTO6uK7N/eFWklYeocFgK0hXD0+mxKLbJMB7Vi0ji4SiRq
FhvY+LQdxP083Y1GrcBp3ln6dYmO003aXXLGWFVulYun02lV6gVfZd8a1XLCpHHRNPsyRQIzI9UQ
rmadZhtOtRJ0NYzl6JkWO47gad/ZNo+wnZ/fBoVIw2n0Y2VGcAlfTulYTTacZ1a6IsGE6Uo9M+06
kUGQaFxm/pweS9PIxsKlfIf+m2bH00PhOhuhuz36BYr1r9PPktsaPxkrKEkrE0y3JWm04Or3slxN
NcxzNNI1rK5/fh6Zd2l00xcmacULoml1MP8AS+yn0knbsYfhyKqgJKQ+l29u0rnwTVcV8ooNKd4V
5VJXkqKIkxS6W7Y7OO2Kal04+Xn6VyVpVnC0gOgSts2xqZUwHTXg0lsK6012mRwKQ9VpRxBT9KjQ
UqK6Eej02+ahtKNaK+qVrzU9Utgo9JcA3emO3lLpRSiXTA0yx0s1waPTKnkfpYI0NpcTm3lStdIX
NtkRMDHcVaHSvfbqrToo0XTOm/KYShhgQ2mY8gU2jKCxpdLjQU7TMZ4z0pQWVTpyM0H0qu5XulWO
jaf0uNUdV1gVk6biyQ1+l1ZYfR66KH6TAlMs9KPSwhUMIEccOsI7UWl2rHCNxT6b0v3M1NQxh11J
SEnPgUcKMy207GmRLSAWvP0Xrt6G++b9HdJaYqe4B9wlDSJtaRxsFQxxmbZ1CEZS1HEcyMMbocFi
jfGGj5ERitDUoVltQZGqUQF7E7OU4hkHOqEeyfEUDnt/qBH3CUlMg2MjsyfVI9sCj3K2INuSa5pU
JSK6TGr2BG+EwjbGn/fXVDQNSKzafVIra+l2ekdiZKrWFaOi5SRQmDYSCMiGqU8hghsQTGEfNrEc
2LTNY5sZmS6xpGRqXco4bGYWA0rZFLyNGrWAH4Y3JYU6LlfUJHRsVi5Oqkc2FTbPbFY3D1yFYtF3
DAgsEx0Jj0nU3cdCq2hGkVmWFSipXUqDUcRiZKq2kbCqEY4kRo0DEYVtzWI1Jgu2/NvfT0Lyjxa5
OEyC1BzoiLKrK5GiNBGjLaMiZQ137UgMRtrFa1tPAQxgV7UZOgM2iVybGCMapXsKx0NoCfbbkeKM
7buCiItU8zlonph69wsrKl0h9RTsaO1rBoCsrm4YIg4GIOQyTTcjBrmha+IIqS6prXhaMbQeOV8q
CzgLstQkyMjo0QJhagit79HVp2ixgoy6iouMoyGz9OEYga1wZELgEQ5sZSEr2GFDqWtyc4MbI0Uc
sGpoKDxfdVTBp76Ur0OqxRAHaMG5seE0tlCgMjgn9h7LQLTH0/WtHHldhmXoxuZpOtaVhUEBspgi
vjQxxwns2pKLBYQAVFEcbUTGujMZKiaiio4odNd1rtM/tkVZIz6GiUz4cRkMWpxorqOGwMayu3xp
MYTZUVlG002UdlYMXCyZNgChyX6jZGFTWRbA1z2wMdqcEccbVhpkvlzi2YEPc1URseLLsWctSPYb
NP15mkhNcwGoYnl2cKvZDi3VxN7rQlNNoo4xQ76ynAlVm8iJrxrWk6MzRsJrks5LogJVuKRDpQpI
tXMSPG+topbF6TrKkAg4Ntb+FI1PPHKDouGjA3kt8MTLlk1kdE8ST5/1iO3+BM1M2tlmtJlzJqWr
FjapRLWTF0W5RF0Q1rbTT74JNOac2aFGDZrD/Q01x+n6rhyjTqEbxxfFHItNRynQomlpkiQmqo6R
Y36ukyQ6dqDuJc2jK+FH1hLV3gzrCRUDUEPUGoDVlw+bN1ASir/po9V6iVCH1DOsW6aoXR2akuWR
Y+mtOfuAQQE1P/42kYjOxq6TIE3TDi9j/kiMwLOu/VeqLtiZ+cXJPvjsp2o+xjBQYNQSXIShnePK
isSYwsVscd9J/dVLyjzAK1ZM9W5Wk3EUbDJ2ERmpWe1dMWNIa3uR9QhTc+L7dPz/AEKJiPs2jRgj
EeM/DkEEZvbnbsyB9wAorVfLHwyARXmKBHkKFGjc9zZKj5BZHRBzdx5ETuBBFTJouOV7ldlizi3y
HEfXBVCv+O0nblchvAzmEEVu1gxWJWuUjUjI4kkPFI7tzuAhFfHawZnOaYbOYRRGolgijyD+9g4r
VWaHg2A5XOWO17yx+I0crZCCQg2xWsZN3G+InMYxoizg7thMVuXf9lh/ldifOlI/aVA7RrSaoVjm
SXLrQ/YuDKBZE5JRKEScbT7Q59jvmnh5JZsCXZdo9aTujnx93Rk2FdyXMfDaQ7gv8dhzJJIGtTis
Fq5JgMV1bWtbgWINk9vKPWbZYxueVw+DERHEsG7DrOSluh7B3knPXw+0lpZ9gRLmS8lZDNKKA/ix
p5WyJtUzhG1CRYywiLYljUw0Z9IDlzVtA0RSrJr4f7v7I8QnPLKJ3VgN7IdWP9nt26ATd+kI6DbZ
JvFsrV436aH3jKm7buY6GerL58mvbwiaocoFJPdJkaYD2o94n8SPZOWZEf3oz67aVIdwjWjTmmUl
MrG2ViyEKoEtqeSOLDEOTElYSK054MYccLffL4XMdQ5VjTK5jyD+2CBl6BDuoRowGsG7hoKR8jNh
1MXUWoVOSOJ0h9BQcMtrkcGPUvbYWIP8WripFNSQH2jwgFVAjmSQOd73L0TiaNDeWdRN4UiPSNOF
E5R3I0OtufkZtkLj39LoJAXSsSBNmq6RpDsIpduGppDPN0+8SyYO3i64khEsMv3NNuE6LqQohQIB
FkWtc1zIb7GubKNuSBIrCnt6akHBFqnUvji0fHSS/UNgSsgV+uCkz6vEsCRmsZHFHQb72O08HTsd
RAttQQq6RCOyUCCJR2Oo1ag6tGeRrP3qdNacVyTpoamLbXRrSRXSfEkQdaRO2B/nQ7enee8qaYUE
Gp9T+O0IiTJGn9P9hLm9BURI1g+dcVc+GkICRiEuGsdX6f4ol7LHGl070LL/AOTV/Z6t8/OfOfnj
774uScX+6pXawE7+PqJv3IQnEl0qdsM39wb0Tu7TO/jTpTWsnMcV0H9sY1r45o0pDC1J7oFN5Uf/
AFtRrhflU9G2fj0be1F7Wu+45bvvJ/iE5O3Yu/bVu/ihciPmuysd/Jc7Z51/YRUWXv8Aba5O3Yu9
oSp2AvTJzvasXdbVf2KXsFqbNpTr+5qbIOa9OUfbtAem1i72rPZg3Jzlv9on+zy9yKnA67yRL9sb
042L/wBsBfthImTX/tr/AO5F9zvThvvNaqIzmissF5OhrsMae883abAkoTLoe7bL2KvynsukZPJ6
m/iX0lFdTn7cytN9nUR9kUqtkacNuO7NsKxMrjaVlcklk/jWJOc+qZxFYT0C6GTvCm1/dKyKgGWU
xyJSjc4kv7ceXOkMlDs35DtxNbBmMOsn/DAYmWc3x8rJHkDYiNdPf+ys/wA9m3uCi1qNWfK7DbBs
iS6uid2TXQUGG9tOxkOW586nJ3ImqZDlTSWylI9BtJbjYW0sO+xwSsPXXMhDD+9HjhRiXlgSKtOd
ZMfVw0ajugXbLo07iJdEUcGzIpJWlpD2nV32NTyHukVJFFIqXqSFrOS5ME9UJpMriA1MRWxqRe9Z
jRGRDWEj6m5vONGpUNJtJSVwpKntCaUAsduqGq6NGDKR4JMmCQOs0TKuw+oCvC8QwNvGu5Uhs+Bu
6FGc1MvnPRdPc/HuReZKFCZXxbqdIllkUZhj0nEQ8iVtDh31k+RNoVXzIntG1pzWVodP2X+/YpF/
6+Y3/t5i/wASAM6XhNkBD27WpGmdaUm/g692cdVzfBpmi2qiatR308aKzNJsVTTf9S45jtalFWXU
Jxga9Y/yh++aOYrAa4Yr4emE2ktXeCteZb4H7INZXDcfVEw0YcbTUiYunIf02Rq0LpFdWackyMst
PkrmBu5XHSbykHqjueLp928DVVeU9vQjUUP6iMdxqGItpF0/WvgpaygTSvCkODJrrC4nn0SowxNI
98P6dNFnViKKDDiCNY6sWSwFXpA810LTQ66XZiUEIdFNtZdno7xow5Lxt0aAmaqG4lXpO3GwWpaF
1wSrElULXFyKxL61zfPziri4rt8k++OTIz+3IqrFskNzDQzdORPvGmeKyHatltt4qFyrRGhmxe69
8NrRgcjBagfxWrkfxNQk9qaB3HkkoMVzLQykXF+VTF6b9ds26b5AN2JldPZIAsfuPLKRjA2jFUzE
PjVSOxbNrC91JDBDQGSLBonCmodOx+88rg2NaMLhWIVe6gGNtWtKpUkNZsDJUtrl8Jpmwq1AHIZB
tHYtdhBoVXSUEwVo3mRySEGqBR9o1hGyUOxrEFh7BBZHsWnRWIriy0G0FsxznbHXudlv1ZrCeQh2
t2BkizQTgz2mTgiOkT0CyNbNMrmtIvfQTY1m1z5iodsPYWXMpFZYORxXdNKC7LuTfGvmpyqA7yq9
ydnUOy5w5yqLZjbpUcKwbuTTIkC2W9PHs3I2VUy0UUwSGdHK0LBHY90vZzGQUcrRpGIQiEE6G1ST
4iNbJe9pdNrwScROxXykTLBjT5De2OyVcNERshJTB8QYW1a+QJ7VCeN3DS61rBB4isWykbCvzI4t
OzmeocjQam4rmnTtjSXyEMDwUeSTGEJQwRkYyvRhSTWABCtGEycJJKxTNhg1RYI/HLiYFu79KsSO
y5VPFt0RD6TD+95EWNqVrXOoQ96RWuRsbVXEmR2I6ZpxnZDqFzXgiEbDsoc1smO6D96ZZDEOtmMe
GwheWoq8IwiniiSZKJMaKvFHzUJozBwRd+TQs8eNfFa0dXYNIMtehXyLBkGOPUbWWACsljmWgoQ6
W282xNwOKNWAYTUDooo+l5LGWdvaMSFOXlO0tHaQopQ0DqpGPzS1v46SCDOOHZBCtlNGMsKyDLjJ
GiiJd6hFGFp++HJYUEQ6ybcNfGv7L6nLzfILW97T0iJGBdz4pYtjxfM0o+GFsi3hODqcwiG0x47D
xreCIOrJ0UuVnbSRS2dfGj39xBNHZK7M6n1PFMFZ9SjrXVQAioNRxGxiXFUZf1LWx2z9VtbZC1FX
GEuoayPmpNSusFgvaI1NqGvjgttTwTjpNVDARdTVT8l6whCAS4LJsKnWEcTLLWwe1W3SBm/rWv4J
rGsRbLW8Ysei1ekZV1rWKtlrMXj0GsBRldreC/P17BHkvWYymfr6Fia9gpl5roMqOFfem1nHiima
9jmH9SX6lA14wYL3WazY73b5v1Xrt1/OOXfF3zf2ke6OxF2Wpt3QSPvglDX2rQEn3jStqrbxHl1A
xyxtQiHn6hA7JF+JWN1EPaysEl5AvEEKzsfJWBatjtm3qEQ0hz1cvo+c26J136J7ZVWz4hA6mDxm
Xffxs1wixdQtRsq+QjZE5731992mk1GzjPsXSMgW747maia1s257yBsHBLH1I3aVftK18t3OFqBG
NNqFiskWTnEhahaxv6hjrky9RyMtXjMLUrGtl3aGRZb0fD1EjcNqFjmypznur7tQtXUQ+M61U6wr
R0V4tSD4zrvvIOY4ZImpGsyVqBHtkTnvfX36hQmpR8ZtmshYFs6PiamGrJ1x38jz3xixtSjY2XqB
pUBavEeNqMeE1GHaxuvIwjubndKm3SLn6qCrLK0ZKyDL8UkfVARssrscpGG4ng6kGBsvUojNlm7r
628ZDR+rAvHOneUtfdrGxmpg7SNSjc0Go+05urROz9VByXqLvZF1QjM/VUdcsL/vo4y867UDYyE1
YwzG37hlHq0XE2qxvbKsXHfC1CsVD6p7rfqb0OHVyDaurmZJ1Z3WusFU/wCpl7MuUp1hS1jEj6w4
Nn6jWW1kxzCRNVuE12ruTZt2SSsPUZILf1o7aZqZ0nItuaKRurytSVqohWSpT5DlxfbBv4LB1JIi
sPq2QZkqU+S6vuTQEXVshzJtmWa6HNfDezVcpGzbs81GEVjwajlBSVqaUdpJCvLFvJEZn6qlLkm8
kSFi6gkx2rqeZs/VMri61IYiajltwmo5jkNKed41c1R38sKGu5J2x7KUFfrs9WyLaUZN13DZywoe
xknwEsgHfW52Pu57cLYyDoBz2KQkxzV33Acgs8+e7DFOTGEVFHJlrjiyhq6WUijkSEx0mfs8ziOG
R6L3Jy4aRIXHdNsZ7YIxN3glkxzXCc1y79uUZCRjswRMZ3noaJK23Vqs5Lj4Mlc4PEowPIn02SqE
AQWDY42fT5eHgymoiq3G7lxa2Ts5jx4IDyY6tkIjk4uYiqqVR3sMB8fGt3UUEx2mrzR28vdnJ6/S
5D2ljEj5HhFkZ9GlLkitNFyLCfLSTVHCnsnQQ1Iv0aURJEV8Vfx0G1XYylkGbMryw2u6/Pr26flf
bOOSMdm2RIymelIohx4D5BZFMoWRYKySOplYgaRz0+huTCUStRlI52S6x4ciVDzNmwFj5Dr1ktlV
jxoQasVyenfFXE6r1Y3ksGkUjT0zmNkgUKwq18vEpFa2XBUSx47zFHRuVsqseHO0qki0r3NkVCja
cCjdAqnyWupFRkqG4WQ4DpT2UP7ZdaosHHc4kWjdxk1DhocSsdBp1Ox9JxZJhuEsKudJVtFsyZXK
FARHSCx6DZJlS4aOju5wqDkw1LxSVGcJ1dUPkp9C2ZNgKFIcF0twtPNa2ZU9rEiq8sWhTjKpuKGj
qwlfRq9pKJEbOhKDINUsvGUDWsn1nZwrVZ0/IhKV8Cg9pFJs2XDULq+kU+fQEaybWKHIFasl4tPp
xm1HbQMRxixdPJtKo+CRaHniUDNiUbUT6IryCoWIjqRvGfXdlpG7O26NRXZV0bpKSqLtMkgUZK+s
dLd+nkYKVXK0kCh3YWkTtza1wnV1GpsWhbwn1HaSFVvO8VAiMnUXFG1pFNC09+yXRo1JVc4ZKyiV
7TULUZYVThrXVDpCs0+xGWNJ28jVbzFi0H7J9EiJNjOjvzbfBD7i0+n1LjtPtay0pFFlbTOkkHpx
GtsqH2i1hCFg6Z+1PoP2nrCDkVOnVK2Rp39lnTLHdS0iyVdp3iy1olZlbUvlEBphWis6D9rKwvk1
mmtxzdPIjJ9S+Oel06p8JpzgO6pXR1qqN0hw9M8R3FBs2FVFPJg6W2DY6dTgaqIKRT6X5Nlae4tt
6Z8Y1Jp1ZGLppqNu9PKjaimJLNG0u1gbXTiOYCoL5NRpZiCm6bZxsKR8eZRaZ7mF02Nrb7T6iyko
XS3M00MQ73TbSCOB8cvRuaeo1mP/AE2AQ7/TzVFU1r5cuu0xHCCxoo5BSK5Y1lQaYGo5FJGa3U1S
kJ+mqBJmLRRQtudONK6q01GBHeGu7tnp4Z42n9NhAph1kfPpAZQtSVS183TenUI1auGPNR0TXZQa
YGMdqWtissnskTdO6cU+eFBjjvdODlRqmgMaXEqoteGXXxp8W8pn1kjSdN5i+JEhhuqAMoVJRBjg
kXtWCZKqo9jCoWxocq9rwOgKNyO+M0hSNOwyxIbdXUgTRgxiEZ4J8WO5i6b053FdIjVwrKpHbw7e
vdXyN/QvT8dU6bb4qbYffZ+MbuunqVOFhwEKkKJ0uVCaZtdSoItg1gkq2MIyQjGPL2lFChsI2ypU
Iyvq+A7+KjUpDjapoLTCuYHYUrcTFTETNv6G2UUbyrAMRohSGjVtzHbvTV6DjKNjW2o2PzTFej87
LR5ZDYrIcFDWQozWCktZwnRkfJr4aDjkQbWW4WuZp2CnY7LWJZDY5tNDQk1kdjEmtGrSxkJPhwkY
EzRo23E1co69EAomDbZiG5mn4KPe2OxiWDRqyPEaWwBCawcpo+FmBry1cFGiINjGXA2qzT8BOHZY
Ntk1ipVQ0LNDEaxJyDVpIrSzYMJEFIaNG24WuWlgNQTgsG22GxzZzf3bZtmmo3elRISIKYguE4CP
kVMFO1IQbG3LWq3T9eisUTBNtWsVKeMh5IojRMloN+RIjOMlzAKALJA5QmBJ57B5CewzLqI1UbSK
Ry6damSqdWZUUjiPqq5gR2wGuikr1lTqWoaJHhYoiVyFnNjNjiGQUrJlMhXRa1oG+QzlLrEKyFUI
LCyRx1dCbLEGjRDFRkJg+3YMkUiPKyIyKEMpkl02oQmQqtI7HTmDNJr2yBQ6VrSTJLYTkC2cLU9c
gsVPfNOwklGjwmxYw7BpizapCtralkZJFkkYz4bZIYlMiGmykr2x3JYjJRtfJIxsONDsPOfPqWly
FAZCD9YXyZNew4qyoZGyfYrEMJjZ0cVKzyrA6QAVc36m2ZTtIXtNhRYdusqVYVrTMrq1kNku3cKX
4zZUaDUjCa6nugpXG+oAJTMdMmPSHEpbJ9g+wqxnSOBsMDbcnnniMkBrK5kbLuzJHkQ/5cUVUNJd
zJWJHoZRJiTKwZiPRIkOBaHLNnQmHHWwWxR2NodlnFG2XF1oBI0roFm66PBwj3pngFL1Gj4+kQON
Mm7+M/ULorwk+o3EAfaiWtiWvmXlolqTS4O1D1KQsZkK7bMc77kQNEZtsd3bhStRyRTa6FIuJDCM
qId1P+tXFBH7EHVjzRi1Nqlo47No03TEiYf6AWFMqBNHCuGyZFvWN3hQgsbL1h3lHpgbwC16Fvja
NgqCPqgLzV0TUJGnrJTCwC6Wee2ii7UeF73x2tIy70wEoHVxWTNMQfGh6whEkABbyLRlJpiOGN9L
ruVzpoLwUg0ZG1PXksJ9EitH/wAk/tm/HT4xflfRtiZvi9ZGP+Qf5KsaeNqR7kbFOoJdQXy2KFrG
X5800vKLLjo7LE6gbRn5B7zFxuamZtjiKIlYvOJqJicDtxW7Yvr/AAiZtm2aUD99Bco9obs4wvly
qse4Lb7WTJrlNpsaMHYj4ssZzmZp13dO4SePaSFDkQvlSYAkeG3coVPJUpKAadq0ZwZYz1Gun0Tl
JEiAtZLhZVk78qKPePbEUSrJ756Qe47b7aTpyo/Tg04zR8Q2ktwsol7phiRY1udQ5FP5MmrHyDcO
UeSJndJp9qcLRvBllOcN2ntnOIxPGuJKhdVl78mENPHuiKFVk+RJo2Io7hO2yznuRTk5rjU3zSom
o4TP4t2dwVhSUkyqpnEF87s4eb3D6db+219o9lYKN+mmcsO37FjKcKRTm5DmgR+RW8GXqvV1bXOX
Fe2MNsrzJA4bGDIaNucTCurYzERmyJLbzjw4Le8NrWJghIkqc3cdSPhJ2wibsUfGaifty0CjnwU2
j5aD5jpG8W7ZKbyDXh4WGO/tmATyBpsNE2y5FzdTp/D1j/aqY350f/sSU3AEKDnOxMsgp3Y3+smW
wULlJ/rfme3nHqRoOe73x/8AjeJGS8b8W4kV9am0JPm1G0jKJqMxU95abx4IhssnfCZMEzuh/wAL
MtxtI+k/1P8A+pZIix6dGMmk+Cf4kYxkr/8AiP8AstmsU1d/pt/yXCIraTjuT+6Z/qxe22Sb+wX9
srgkiDt4+vf3SukEvYLpqUyTG1PLZGrZEjyJGjbBpFkkQAL6wbKm6ZnNBJjO7gNdWaOkVx+weilJ
Ki61sEiV+nwpLnMb4cQOrGyZs0XehQ9PLLtRNBUxNR6hfONVyPEl08jyoevLVYgtFf5Jh/GBV6uf
ZTLGIwwq/wD1S2QhWlevKLF2WTqacKCSlM2QT/kB/GNo6wfIi6wsHV1R5DjOqtSyYGQdZzDyY5O5
Hq/e51ERRVmmzrKha5CkE+lZTzwf+QLQtfF0i3eya5Bxn6rqWGPq2IVlO7mC2tmwLyjf3B/8kO3t
lxeu+J13z4z8dPxIx+D9n1BOUTUI1ekcCkl0QPFGRyOZqCIr00uv8WfJUeTBPlJTM2DZzXRHVM/y
A6hXliiUhKj9sPUC7tOv7if1NMSFZYdxWxr4q7pIcGRUF/jXhV4SHry0kdSRbUqq2zJuTS51815F
8a9eqrDM4cyC9Wx74i7Hf9zTJlfFtSLwsV3LpKQ5zpRV7F0VVfUGUc2MT+NfEVEeVWkoSr49yVeE
9VV2kzueKwKvauiKrtNnd5yFVI96VVyIVw5VYRUDeEXjLfxLpkyrHtyr27R3J2kTuc4hV8a9J++o
K5s+GR3j6geq4pVbI0+Ve1eFXhZP3IvT86TK7y2OXxNQvdvXvcObUvXtaie7YrlQ+mSOVl0R3YtH
q4ukyuVJD18W0IrptTt2rWQQS1z3EFJgoZ6xvHZOcQy00JQkk/6thGOSSiyAZG1G2OlTbjmrJdxC
a6bELX6jHJK13JnkIkmYTcdduhHnaxXkRR/udK7qNGyQ16T93lhrxjtktV1k/dtRyYjpLWklk+zA
R3lmOgs7yOYdrySUIjABktI215Eyr+1G1fK5NVf2tXNHERkghuccDCunSToJgZDSMsGvIQLu3Gjz
GkW2VzspWOFFWYxJE9/IFQIiS5cxoMUyPCscpJpzoEceWwrLYZTvgt7EQU9jjWyKZtCAgWGnNZIk
EQkWuiFSfOlNjijy2lZLimLKQjY8eHPYVLsL5OVAVixVsR+bYfyI1DCKA8+ewGd9po7Kwr58uUyK
CtnskCt4RZZYf8SHFthklW4lkjooT4Y5lsIcsxEkxYNSQUy1sBRA189kgc6oLJmMKyDE1XNSVM6B
/eukQ9uNrOOsiG1qjdosCqWzTnCs46x5unRKSVDbwi62iO8yE3uG0yHtQ9dxHSo2lF7Ug7kNEh0Z
BWcgiCiVARtDqiBKsD1+i9g2tP4dlRC7MH/kCESS/R5WoWd/IhU2nyw5dtKbEhUN0OUGTptsybIm
Bp4VNqcJ5trVsum18NlPH1bdpbStIwljh1tDdNqnM7L6rTxLBlLpDwy29wKoiaUlebJuIrpkGkiO
rRazkfUp2mobosbXtc+cHTUhkaej/JgM0S7zJlLEhxNMajaVZtCGwkTJwqGHqC4W6n9FT1b4nxi/
GO98P8OxM07eI9kxjTjrYqNsSSkAGDe92RYcSjqRtjNmsaZeyxo4hGjZqEvIem5KeJdnRzaWO0xF
ktAO4sUIpX4rt+u/rTPnNLhTyEIihvGI7Iwu7Nq3taC52cyU3YmnUaEM96Ky2aiE0wNrSK9OxeJl
aLnMhEb2brZzTpvIo9hCsnIo7RuztNsQaGe1QXTU50wf5QDJ2LpUc1BoWXTkRgbZyOZYf5NPMQI5
r2qC59nacGjCDM3sXmy5XMR0uuM1A3Tke2Q3eRQvaIdoVrg2jPu6bRAop2qC9am9Iz+VFO1A3zkf
g2NfKqCo0VwRHss/8jvnNs0yiDVkhvjXzt8qmNWXWSGNFfPR7XI1ZdCRo22xWvHa/wCTTvETSyW+
PbqiSKWyYozq06DlIFgbFivOZpWDjs3O9kZ7JzCjUTVfYdpjJj0cbTioJs2U3x7x/wBzTeyPHKYk
efO8eRDshyRvkjE221BwdVXbTp3Rty3vO0Om1ArlYYZMn27IrI+o3eXFmslskz2RmzdROSVWW7Jg
3SRx2W+oMptQoXGnHtb3yMbVagVCilCO2yuGR2W9osx6rifMGW6MSkvGSRLLCJl3qLZKLUPJUlhT
LfUKDZXahIyRHsgnZY3TI7TajL51VciliPaBjiutQOIWg1D3G/UY423upMo9QECUVjG43Wo2jZHv
jJMgXUeSGw1EIAp94YsyjvhmYW5jABd6hfJdRag7OMuYrEv9TbpV3pIxoV3FMG51OxjH2xll1Gpg
lFP1JHEC0vHzD6f1F28XUUQYr7UayHUl4+EQOpYfbvdUNfkSyKKXW6pjPBa6rAgpNoWRJotUsC2R
q2GwN5dvsX0N46Cqavho3UOq1lNd89K8rQSK3VsCMG51fEkhOTuzKLU0OGOXraGo7yxbYG09cBrn
pruIwepNQhs0qpaQzRNdQQhu9ZxpwI0lRyKvW7AidryJtcaxWWlVrocWKv8AyFHwv/IgtjaieawF
/wAhBEy51o2wHClOiEgf8geOB/8AyKN7bzUxLdKyyJXP/wD0L7d1fltnAO4Lq/XJYobbWR7EUQqx
jQ/+QixwS9fllMOVZB6nV8iqaX/kQzm2tm+2NVXRqpXf8iScla9lGaKeVkwH/IEsIbLWkuwGBeGV
+sZlc13/ACHOy21LLtwxZSxCC1zNCG4vJNurl67+tF9vz+Fzf2L8E/uTI5nBeDUr1Glu9smRfPKM
FgQB3ahe9gdRPZn6n3x+pHuaO9K3Jlm46V9uSHku1JJSHZOjIe5eVhCK9y4qdFX1fPVMr7B8PA6p
Jwl2r5KNkdl8XUjhpJu3nacqvdDvHgwmonlbLkqXIlk6IjNTEc2VYPNgZKgKDUrmJKuXyEcZecS+
eDCXrztlHUqw7R0VE1GR7Zk1xljzHRnC1GRGS7VxkQytJE1EQOSLwhkOZSOi3L4ufqApWy5SnWLY
OiKzUheEuxfIQMhQvBqArEkXJDNIRVJEuyAwl6UzZR3EyJaEi4zUJnpLmENkaW4Dg6iMxsu1MZql
4Ph3xhpIuzmbJepHO91XEXIdi+NgtRSXsmz3yMDIcB8fUZxpLuJB2qRecW+OBC3korZJXPdEtjRs
S/lESXKMfAT3xlBqGZxPdynIO4KNw9RynY69lbSLgxcBdShZ9cmuSXPOZN13iTZkdpb6ZxPJfIWH
IkBxbqcxJNkYyxbCSxSWc4iHe9XR5JRK2zsFZKKUqje5uBsZzWyzyS4m+8WbKHkmTLejlcqxTyB4
+bPe2R3NxHeNR2U17Jamcg3OTI55+0p81+PRc36IvuA7x53p8lsiOVEY5yYGTOVDxpLsXkxwJErC
AnvxzHtWOUrVeydIQkcrFBGK7PGnqh4R2KKO8mJFnbHhS0z3RUlEHjpBX9BvXGjkHQkQgcBFIXFr
ZioWtONGoqKKDIKhoUgKDRSY2tkEb9IlOR8QrCNq5Lm/RZmEppI2qxWOFCMbC1EkaORRuCx5nEo5
DkOF4HITZFeuJ+7I0Nx8/T51yTTyQI5qoub7Y33wMdSubp0z0lQixHMbvgKQklkumNEaz3yNUukq
bTsgeOYrCAiPkL+mzq00EkQsekJLb+lypk2nJDyHXvmJ+mDcZOnzgYu7HZ85tg8g0RZiT60sB8Gp
NNb+kz5M08eKxgXvWPpmRKZPoTwGRxOM8GlynY/R8hyHqCxjg0acgv0dIyRpCQEbxKM9dQGmLK0j
JG0jHCJWxHziP0UdwvpBWTk0ad4LSE+uNkGA+YRmiikDcUhq1P6Hx6HY5PbDYT5TK+I6Q9lAjQsr
uUo1JxEKsc+WSjRrI9HzV1AjcWhTgGg3yfRqxtZS99thUdhK+D5CyKTiOXEULl9sX+pXV75Txaea
iTaJMWucpYFAiDPRpwmVyidWUilxaROM6qcPIFU6SQdE1MmUqtxK9zjxKJEZIov2ya1wyV1F7Po0
4TKpRZXUyyFZRtRs6nViR6x5TAo2tSXS+xqx/dg0SNYWkTjPq1HlbSdxPoicbCpVmQah5jDpk4y6
ZUb9Le88Wiaxsil/bLrHMdX0P7XUicbCqVmVdK4uDp28Z1PtkWnc84KRvGXSpsWpcpINE1jC0icb
Cq7WEFwVelRULJUVI3abTftbTveeFRta2VS/tmVDudfRbMJSfssqhzcrKJXYOkTjPptsi0qkLHpG
8ZtP+19Q554NEjWHpf2zKdWvrKH9rqT9llTq1KyiV7h0iI2fS7YCleSRFoURsyl4pJqFUlZQI1hq
PZljTO5VVB7/AEP7dlTbJAo1IQNCiNsaXGUblPC0+iDmUX7JdMqFqtP/ALDUOzLanVuV1Upzw9MN
QGoK1IyU1U6Wsega0dlR7JZV7ozn/O2I3KKr8x8fTrGjtqZrEFB3n1mnGdiyo2tZaQEFJ0/p9CMN
QMaK9rmiTTtL5at0+JG2VKxy12nBsC6qjo6fQorKujGjnV0RiGo2EFqCsSMXxSOcsYjc2VFrKp0o
tbpwQAakp2Dyk08NscsKEN0ujYUINNKWxBSRgDsKJj0i6e4T2Q68IhRIcpZdGNCDhQgjb9OeWXVx
1jyoHduKmiBHjzqwDhajgNjSNMDB3Q1sdRasjoGQ2IV6eAfaDCcU9NSCjxyy60RpFSGXH1LD8KV0
G3fNJ0bXoSNEHmoq4RQ6arPMljhR4kawhx5IUrUS3pqkcWNJbGLmqq8YT6TpBsFJ8Ziz6UUswooa
+JG1JCmSrSoFIjUgYsFhtVwklNjjnxNTV3ZsW08pcfUSGoglR2n9PPlPhwBQhawiDLMqoA4sU+s2
CsXgZPhwNNNW0lTwUglGG5igqI9RaTtTxqyLR6ifb5fRQDxmo4goMTXT509Sd2I8CStT1cNkWI25
jyya1iDBMoBygHiGeYOoJZImpa2S6RH1zVyJNi2M/wAzT+n2RgztUir5FjXCtot5XrWT/UmL0To7
2xehvgnzmlatrg2RGxxRp6fU2MQ4I9PxNYK0A6SUkjJzs8tvGs4GSVCYZkGsQGahjoxsGQkM0drZ
YbyuRqHZxc7ovo/PRejMoKtooxCoFWibJEyoa4xWJHQBGyckVbSkbDSONh285UNpGRaxomkKgHqB
DiBUpzKiRkCrZSPqWlM6KkdgTtI6ZXoXAVyAYpmjcWM0441UjcMqR8GiSWfSkcUgUC0BWlWRWoR7
IKBYkhqFPDaZoKxBNIRI69lpxiqU5FYkZI7myUfWIQqxUA0UhHvkV7TIGvQLHyUCR0ZshgKpGKZU
jYLjJZ9Ja4hA+O0MhD5bQW8LMPAi5CF3ZNRA7YiHQCoJshgqpOR0SK2O9JSEqke9YiRxildx8iuQ
2CgIFr5nZK6K2SMFW0eSpHiYLaYNtO1CGakZkWQkvDVTSPSI2Oxk7mY9e2Q2PXNAh5nYJ2ElDBVt
Ys03ipGd5o1qWKQg0jChTfKIetaRRQ2AZ9Q4ySw2GZHrmBywnrFeNqSgDq2NJOJ4o68/msJVjeQj
EjghT3HPawmuDU9oUhiordXN3fpyAxsa3lujLCVJYNWwmiR3QTN3aMiJwlvUQbC4arKQXk2at4sn
2yCc4qT5VeFBRLewWG+zsGyX6UjdqDaHWMEVq2Sdy8h+GVbQy8Y8/UPjGgpJsytM2FElx/rMtmlU
Gwunka2VRtcalpWQh5qFqq+KqeNLrHlnM/aGMNvHUJitWoVxIeqC/TkjzZdvlFA+mi1NqFgcfqWW
dmnIZySLA7QRa1nmW6p7Wdq+tlP5XxKbTYY42Jtl3AWdcQtMxxAXT8fJtI2M+K/lHl6fcacxEjxt
XH78zpAA6SbTcZY8PU3JkabqAhWaKgOGs8amiS7wtdmnoxbCwY3iy/OSpltOS7mU4PHhasATt1F+
siSRPJjw9M+LMuJKR4Kyjnm6e06uW90Koi0lX9ZkSR1lY1o4E1h9NDPZRITIIQFUqatGvk1xULCJ
pZpJ7/4sWof3Gaor1sZdDHSKL/khVTKWmJOJGCGoi6r1S6cQSPeml9PvatzcCqoWmo31GwG3tt1a
z6ZIq4Ui/lRIgKoQCNK3U3vqilT+I+RGkSbfTnasK79sGVTsm29U3aLrd2996vx6V6Hwqe+aV/dW
aiTcZHK0mmZanZ8JqMq7aVXcMhrHNtF7aaZKqx3TGMUZWkTUWyssf79Le9bftTjK/udip6/zv0Rd
nVf+nNH9urb/ABo/zPGjsqB/e2+7KT7aj2m7bM2Tt2TMit+yFqcZ7EVKdn7WJ9yWm6RxJ5ipthUT
tTRJ3gtTsiROFkxFZWM2CH+6a1FSuZ/IRP3yGpxKP+cxPt7fbsm7ZDT7YkTLBiKyqb+1ifvlN3QL
E8tMf/ZOYnkxk+2z+20YijrGIjRpk1vJtePYlsiIG5Tcjsq/ewrf8VixO5BT7SfFoiKKqZx6HTcc
Vn8lMX4mNTy46bCy2aipXN2Zk9EUVUxEdhf7BMTz0+MsWt7kVNg5aNR46j/DknZR1rUSZjvgo2pL
TpbIi5C/1ssURw6ZNmYf/FCa1LKf/qSnq21p3K6Dqvfu0HtBtmtXKpNoetF/Y7EyMuxNJHYUVi9B
w7eUhZWkTsaRV2zVktGn08dopEReUbWkpjciG+9p87Tw9RGayBUKsmxA3tRvrQFmSW846Ub5c8Ih
1QL6/cQmkxIodRTXwgQNXlZkC3BImCnAIiKi5dNaoYYu0CVqIYZqfcFHTiy3I0Zad3KDqqOsxaWk
ZXA1JqBgEkmMcum6pZphRg1sTUmpHGJpKwcw6rs3VtisidpCtF2LmYsZIjuYIaIt69yMRbuAx8+7
jyRxhoIErVZR2TNpEXWAkFN3xMglcA2nJLpETXU50Sva7uP0VPIVLY6xoE6Y+ZN0vMIGax24tY2R
JFnXHcE9GZx4H/INiSOLRoWmNNd4sOn1HLmTrISFh0mmkdIvbmNTgmPk3UjSzOEP/kn/AA10yZHS
BqMsOZ/+gQnZBmtnh1BLaw0dvCIW7mLqCOvch1ypmqJpIVhRvcQWpa76tYCiipYuodQluiyK88ZN
FQWSnWBEqa61uH20jTRXtsYyqsTUxnmuNEJ/E1eRyLVf6eov3aqpv9Qrl/Usz/WrPeCaxlx76vXt
wtauRdQf0d8TF6LhsL/dmkpDfp9yPujfF5SaaMkULZrFy7jIZumRKLLNysRY75GUYe0y7L2809Yu
kMvX8kOLuyNPj8aFemRWyl/c/pvnzm3TbfNum2Jn5pZLXw5iK9sFeyAUvi6YXmleije6SiFLI5s7
bllEMiMZKRzJqKRYxOAgzETJruSVu4U8tGkkFQjYzVQ5JKNXzEIwrVeVpuAhS02m7vSEqiGyYjXy
S82QWKN7paMe+V3GcFcfvowbJjXtmopXR39sY5rd5j1I2EnaTzEY40jusANyGdKRmJMQjJA1KZhe
2Nk5Mm/dSGvZa2ejVkm7jIjFG+2kJ27YqPI5fevdwk1UppBy2OKSOTtiZYN5TV7zIX2sdPaxSyO4
OM1zSkmIPGzEIwo3PkNkdsIrBr8mo42Q17LPPbzmP7o69nZUtg0blk90YhuSQSY0bRzWkSSJSmGZ
BBHYsc6fuZIH2GOsmNJIN3R14VCQ85ol8ppWdh7pBZbQjBYNMk0TjuA9AAHaDcWd99tcPxmGtBjK
Y/dDBjuZJuJrWRhAWVY1rO3D1JG5uo5aNDPE46xVbEjausUJj+gPddEj4MuU3g2Yu1L0iBVklT7W
pwL5NONSSoCcYes4/dWM1XE0uzhE1MPnG079myUiPjtqv+zK5GDiCYjL8BJKxdLbDqGtjZqCP5Y6
7SaOS5heFkGZKMai5eBe/McqOBJqnFsd0ECJdjIWdC89Rca6LDlssZ9g1XxomlUlSLvT7AA0OnAt
+/jXyl2maWjOcZ/+PVUP+dpKaPxbeP31iuRkcStFcS08uGDSPORKrBVrYxkKA+n3Esu42LF1VIST
NxPbK4SyJGngKGHrSJ5cbtKM+jYJA5bD7sC1i+HN0pAIQyJxFrKB25NNGdLkU4VDC1xX+U3SMxkc
5P58Sv0z4B7awHHj1/7olnpX6lNFpyKAFbLECRf0P1psPTMWCzWJYgX08R8uXUxVjRNSi4mrZSS4
n6T/AJ8qUOuhUuq0dYvhAs2z7KPSQ9MWa2su1rfqUas0oCDmsIsQNVoJyNzV52sph/GjKvvuYzgL
WVY2EfRt2Ib7KA2xZAlNEmqK9op9GRr4BqgKy9VXo4EXSmp1VViAc3VmqB1gpMgkov8ATXFXoVcL
8pmn7hYTmSmSI6tY2z81jIyXKtsCTGGDAewT5BmkxO2xgJjBLcTGvZpua0Q7WcjmVnF8hZrQjt7T
vOM/lm+KuLm3Xbp+c26Ud0oFDMEXJdgMLTXytkQ7RkhhZYmssbnitVdpJa2UPjY2zRsrr9e4OYN+
TLJgkbeuYaLYMOw81g0sLri6uuWGGs0bWWVxxytvebxTBubOtGDaC9VsiPYjK2TYsY2RduaaDbMO
J8xjWWVztlXfd5Gyxq2xtUY2DfcXxp4yNmWjRNdeuHJh2jDNPPYNk+8VH1l407FnM4WlzxbWX6uU
c8StsbhGDBfuYaNaMe2VaMG2TfOYWvu2GG+xE1tvdcsMZXvVca/bKO7USxrIZG2Fy0TW3zkkQrcZ
myrQY2zr53erb5pmOsGIO2v9sqdQ+4rITmWt40aQr9zDRbYZG2FywTPr5PLr7sZWSbYQ2WV65xae
+5NdajaK21BlRfOa8VsFzbW/RjYt8UciFdDM2fesE2TekWTU3zTMk3Ihis75xH0uoeOfWBNHcahy
ovHxyRrsD22uoGtRl0Rsqv1AIg7G/EMc25eU1LqNvA98Bobm9dIWimx2jj3sUY7S1imGl14kmJqM
BWXGpGK2XLfJJ0jvRj6O8jRxWepYhAWZ2yC6dtAQ0fqqKob2yEclBLHELH1VFGPUN4CSsI7WS6zV
MMI7nU8aULzu1Mq9XiQK6qh5Z6taq1msgoFdXw34/WgOK6pRksesorkPrSMg7q7dYOrJKQzRNaxR
suNWhlsq9ZJGxddRMtNZtkNj25WTIeuBhDcax81KLUf01U1+Hb/9CDl1q9LFtDfrUFtNYeYFXciU
epVrEd/yEzt3F59QdVXL60i683YLXBBLO1M6SaJrt4Al/wCQ90ttSFsVqdYlrhL/AMiuy01kaaxV
V78RcgzXQyi/5BMBlhrg9gJpFaeu1pIrwn/5ClGbOnPnlqtRGqsf/wAhy+NtentcgzXQnD1/NC2x
1fLnjAZRkiazlw2O/wCQJjksL+RZOia1nRRO1/YYXXVgVo7mS2Qmt7FrZOs7AzSldIJFlujObrGw
EyZqWbMHBvpUBrtZWCpNvpc4bC8HC1RMjil2smwyJYlhO/Vk9MXVljk66lzxxphIuTrmXNa12RJ5
Iau1BOXJE4kxw5Lhr9fncUtpTTmsTylFbSQs+tzEyRLLLVC8cdcSkYaQ+Q53Xbpv6UTEx3smL74T
CfOD91iypTWFOZXeXJVjiP7g5MpWDmym4k+YuOnS1zyZPIxzvwRSscY53tGQjHPkSHNLvuubdAhU
2Piq3BRlJj4bmY9u2cc2zbomN/bgLU4sfZlLjiK5Q2BAYtuZ6EkK9WSHhc23MjSTHlxr/cB5mFId
cc5d4xpLcKaVxK5245DwKtsfZ8pX40qooZkpWGkkXFf7isTCR9kV+OKrsDMIHFtDOR0hX407hqlo
dEfLeTN15DsDDx80pM7qqo5hQ46yM9HEV2CkKFfqZ8dIe/EerXNsitwk0j87i4KeUePsCuxScsFI
eLFtD48yvxVxVxuNercHOMxHzSkxXrjJph4s8r8c/lg5BBZ9QNs8ryYhXNxtiVEJIcTOW2MmkG10
wrs7iqrJJGYswrkcRVVhXNzzipjyqTGkVmNmFbj5D3Zz2xssjMWUR+dzGyXpiyyLiuzuq3PLLjiu
dncXEkEbjpDn5y9+6u/ddnLO6qZ3lzliFcmJJJikXOed52OIq+hF2zuYpN83xHrnPN8R2Oeq5uuI
7N85ZvjXZv78uOc985ZyzniquK7py2xXb5vivxHbJyxFzlnznLOWK/N8Ven5Ry5vm+cts5Zy2zfO
e2c98+c5b5viqq9dunPN83zlm+/TfbOWb5vnLOW+Iucs3zfOXtyzfN8V2b79N83zfOWcs55yzfpy
xXZvm+b4uJ7Zvirm+csRc3zfOS5v05Yq4q9V/oou2L74uKmET2N8/iqg+UQFK0cc8Daa2naoS1Lk
nJStYGLVtcV9M1jWVDXtFSte+bp77VdR/es6hGjgRE8p9M1wrKrUKlHxzbppitYeLZ037KSk5NtK
xrEPFXueI5McBUxI6rniuxYzkxzFTNs3xFXGCV2JGds4SpjRq7EjOxw1bkdv3qesYUdrVI1JIuD6
GG07Z1Q1B2YOyZ2Lm+QISyTMpEbHsq/tq4G6+MqqsRyYolTEjuXPFeiKFUxoVfnhv2WK9iINXOSC
52LDI3HDVMDHUznVThsKFR9N836b574q5vnLpv6FTfpvnLOXXbpvm+K7PnFXpv1+Om+J758dPxm+
J039PLbN9+irnLEX2TbfN839CZ8dN1xFzf1J7Zv61XqnVVz5z46qub4mb4uJm/Tl03zfrv6N8+Vz
fp8+jfFz4xVxVxM2z4/oKub9d+m2b4vp3z56Jirm+b5v03zboq+/Lpvm/Tf174ub+2+b5vnLFxf6
e/RUzbPjCLhvnNGRGvjWLuwI09fLqJDZUdtS1SWTvHHSyu7KlIrh+S6PlRMQpHNRyDgsG+7EnZlE
WLKopSWAbuGnGWzYr02XbNKWPA44zZbUhNjDtXcyDpOafQG5MouOCokciUaNyRQorLGB2HObtn5r
IayzR9PoNPojVyyqO02sqEe1tA1WWNL2kOztrpIqvg26btnexdHEXvy/3Au04lenQA0cSjgsaQcN
vZu4SZGrEe4VA3Fom8J1PwfDqEVCafRw51SoyQKJO0lOzJlQ1GwqBHvZQJsfT+zbOs7K0A2+SYA1
Zasajl9O/TboubYvoVubZt0Trv026r1TN836bYme+b5v/RTpv036L1236Jm2bdN/QvX56p13/ori
YuJi+/p+M33xffqnt6tt82xc2/qr6N/Vt6k67+jf+ivTfN83/p79FxOi9Fz89F9G/wDQ/Den5XCN
2aX53zQ3+hdp+w7f36Sc/Ya7t1ByXNNe0txGtHbFa5dN74eZ4+RZ7ZGXP+tarsbRvvEuf7LD/MTp
V8/OolXsS/8AANqkshCawbjNQliVnCqIhmzl7SsRCh1BHREM3FzRAWnJK/Yx132zyJqScgRuDIab
5dRW8bYaNLo33gWifsn+5dILtMlJ/Huk/e9ccuDcrF09aq+YyUqR7qW52UMtXy2qjRfUGNQ/GQ+M
HggNnCso7e8ASNDZ2SxlW5adKpqPQpEE181qtuiNVBPeyU88jtzHPVXZt6Fz8pi9EXF6bdE9Cejb
Exc2xOiehOm22b5t/RX3xMXrtm/pTPz03xPfr8Yvviehf6O2be6JjvT+VTETPzi9dvQvo/HVU9Px
n5/PTfouJ03zf0r1T0b4vp29C/KpielfQv8AQ/PT8+rf1Jn49Hzi9NtsTFxVxVwnu02bZo2YgRTd
pAp8NWyqWO2NGZaNYs1qSR1cZRT5qKoGQnGfVRUAS5/xUMt3k2huQJo+9OoY/hguZacJhEUrvn5z
SUFCmHISK1ti2Sxw2tkkN9k6mcWY0nb02vEdo/dIhE7N+v7D+yrmiCIMsr7jCVClkMr+1IHt2wGV
j7B/Nlwz7mlB9mJaj/ZZs4l0kHY50/j3bP3F+VTfETKJ3bso5UKGfBR6VkDsTHN/j25CBdp+epzO
ds2IdUyc7cgSIo7GD5Ckq+2ytdwbOc96dsqNtBvylRr5RAMUdq1Ee5Pf0q3oiZt0/P4RfSiYidV/
o7Zt1XEzb0fn1L0T+nt7/HXbPxt026fObev59e2bYufOfCdNs29W39JfnbNsXETPyuLnHNs29G2c
fZU9Cp60z89d/Si9d/6X46fhPR+fSi+jfqn9JfjFTFx/wb5yHNfEJX3oyxrGYPvgt2ePLtV8qPdM
cCNaA5fVwub9RA3Pq4mFsrhrx1Vi2PNm3DHDjSm+etyIYrO277iv3Xppe0ZEBPumKlRcpHJLvBNW
LeiK1bCNllbC41Fv2sn27HNi3jO1bWTToV267b5WTFgyIt6IrfqcbJt0xFg3qK19wJuGuBkZOmDI
SrtRibLuAkHZnaV1LPGBFuxKK0nDLhPddt82yORRlrL5vbNeCVgrhncS9YorWewqRpixTxNQCIz6
6FiyrpjkjX7M+sR3JLuhNbG1CjXjugkae3CjbK07uCkuCVbsitkHUquxG74rdsXpxxUzjnDFTbNt
84ritxEzhnHOOdtc7a5xX0o1c2XNs2z56bZ29849Fzj6NsRm+cM2xfQ1m+cc29O2Jm2bdNs29unz
i4mI3fO2ucVTNs+c2zbFT3VOm3TbOOdtdttsVM+PRt0Qe+OYqYubdds+OiZ8Z841u+cMVu2bYvTb
EEqr2lxR40arigciKzp+VxG74g/ZW+ys6bZtiY1nLHCVqcfdAOXHM2VcVP6y9Pjpv6V9G/RM36b+
hf6C4n9LbonpXo/3aboxF3iQCvwwXjUUAvAwlaseCZzWQX7/AEuRt9MOmPrzKr4B2MbEeQjq0omd
lVIleZGmEo1cmL0R6tzuuzuZ5DtmmXPKemeS52dxc7ztkKqYr1dkOrJJY6kc1smMolR72KwpHZxe
qbOyLXmMhawjGlErFixCSXfSCtaeO4agjvkOFSl2kwCDzsq5waQj0PUPYgKoj3JRvx1QVieARSMp
SLjqZ20mvePHNVi83LivdtvyyFCIfC1L2NHWuK8dCRcfSvah4L2LGqHmR1E9GyYKixsdxHhonKKT
XODj2ZCr3yVfRuawkFyPjUTnNk1HbYWPssGodIQlIo2yInbdDpnFxlAuGoVagqZ5HM09uhKDikmu
cx3052EjKPFbssOCp1Dp7m2fSqFDB4uVM2xreWV1O+Ti6eVrJlYoMiw1kFWi4jlROyu2y8ffjiJ7
1lP5OH09wZMi9l6p0RMhxO+9tBxZPidh3HOOImcMUe2I3NsRmI3OOKzOObZtm23QbOa1mnXSWl0z
2x2VcoFVmKzOGcN8czFTp79E91p6lZik0tsGzh+M9WZwziucd84YqLg2brUabdIHeUvhs23zhnDO
GcFziuKm3TjjWLldWPlvjaMVBWml+2kmM4JFHiDyFDWQWt0crwO0eiZaaX7SU+kVkJ+j8n6QRorK
GsM6N90ZywEF5FpdIrIZK0ijGXFQSCZUxEzjjBcso9NksCT9JNBDbWPJPq9Ho8NjpFvC0rnwZGL/
AE/j0758/wBD874ubYmLierf1b4nqT+jv0VPbbH/AAf5ynhrMPCq2hj2wxIaBBGQFhTcyhrGDjgj
j8h0EaCYAS42EN5y0jXjHR8J0+ra0LxMDYgiDKG3qNskh4OVOi9UzfN+u+L0o4DPDniYNtq9irwV
60tKpXS6hrRghdywiVrGClRRI22hfuqKtowOiDQdtDZtp2uRWNhsa20iM2rYKGnBgtRJkYa5ErGN
aYYw4yIMo3wBsJuNiRxDMlvBbxfWOVfoxcNAePIVcpyUlK1jbGsY0MKubuQTAtCAchkmnaQga5ok
WMN6WtV7VVSiEDVs7OoIaDyPBdJPRUrWJKrB9llUhJTYTRDtSsTIkLypMKtQY7HgxEF5VhX17Wie
omEdAYUQKlrcktFGQMcchlnWta8Va17bKo9pMRQuqZgwPqVFIZfRGIOwb9x2/SCLuyaWsa0RxBa2
8YxU04HkY8dqRrQXM7Kd7kbp9y5IpnixsJyk0zEyZFY6PfD4ndn5YmabBucgWeLeN+9Gpnnz9N74
WgUeAoXkxdOOx2nnNRlE97/029rV04THUj+TqFzUFSvKsyoWOjm7Z84iZUR+7Lq4bY0aXIHwuANO
6Pppz2u0zthaVyPHp53Ful3LkyhUKHFwf8YmRgKR+loBROcnJuoIqmsI+mHkYul1yTREYq6af2kg
Ksn9NPQSQnMm0SoKJrAnJK+tfLUWk3bP0vxQtM4ZYulXkY7SWyWVE6KgQq98XTDzjlVKxJGm6lke
PZW3096Iywj3WnuciZp5RDr9PmlZGhtqCn1cMYaCZNmGsXMQEdrWinz5iWAk5C1wLtyhAUi0mmXn
SFp8I5Uw7a+JSXDrRL2nZJC7Saqz6CbynaQcIFNpwkiTCiMhBmf6em6xhJF7YLXRKOe+xDrKrG2M
1d03zbNum2bf0F6L0+P6S9FzbNv6qYmL/Q+M+eq9PnNs29ie2SFXlmhxI9877QLOQ50nTFj3mChs
elmqRxwJCltuHMEsbor6ub3JzV9uCcrFu8W5bsfSUxx8tgp2rNvE7sXF6b5v6vnPjNP/ALq+7cvC
Sv7qWr8hwgtjDt7No26fb3ZqA/jWUlwVQ/lyKsHMFo5QZMm9x+nAbCsmKFtnY8M06zkUweMewnKF
1ZJ7wZkbupEF2w251FkZhZRQfx2GkpIIKvaqLGEiy4LH5XVaDyIxBpMTkGEnvNjdxsAHZYxGq6Yz
ZkDkprMKdpJyR5cWT3AX373U9a1uRRINCJyZEj7kkB5CkVPcyuq+0ZAog5lZ3npWeOeCz7J4W52/
bF5zUWXtIyELti1MmzK24RH9psodzVozDi7ZNKf4r/8AwT/8q9NPg7kmAzjGviKFLSzV2aZ7ZUkR
E8aUjB2FdXDILwRNdLqGPZFoEQsSMwCSF2j6g/zv9lxnzpRRvwsVvjzIfesa6qGMJPEYQtWMrY8A
QG9gePiiegq0Q3KEedgWzqsSknVwuxTwRvbqeCMTCp9xMT50wFCHH7D1Sd0Z2nY/1F5UBFHELGn5
YwhgyHHEondpuXEIfj27GskfkbN3aYoe9jGjjNX+2LAbLtE2anzkiELuSI41jxQouoDgZ2ZxvHua
p7TRdaBTt6QrGNj2NoOsHG1FEsQRIgpk1v7G75qKKLw6Wi78oAkAG9qWkyvbxhW0dpH16bQ7axSF
JaAE4bY4II9SXLZJ6DTyyCK8NTFutTOkyabVADBZJryEbmtWKadpzTjirIOGoj0NitlMtGI+NUCY
KRcP7UOktWWgkgR0dqO8bDdSAakLZdyM7g6YSBddDaVtM1rW63X/AKtv9nTbF6bZt129S+peqelc
Tpvnz/S39v66p03xccm2HT3+M0I7Y9h+4FmzaRpaM9CRXbCumKRleNRWrS8I1nL7rqcKssJRVEGu
uO6ae9PFu1+/o9qtNaL9m3/zuz8r1267dUxfjTS/9fdpu2Q37tEcfblpzHZx3NdpuRxmoZUjX5si
SOxKqSr2L437ZBdiaXkd2NbSPt2ZuTtLSlI+Qb7F0Xc1QziCxm9hK83eBMh994oaAbOl8cp+4sx6
cQWEgwzNsibxLliJX2TDvO5O1GRN7CV2m1slTDH8y37Ngr92zf8AalLvYVyfx7r2dBtxCyBajO5X
fsjvRX2EnsirZXkYwTUeZ/bGGweSV2GkRrODZc9zJAnd2NcGWK8V+bnVyFMLUheTIFe+VIgJ2A38
wfGQ7uE0q3YV8n2bP2L+d8pDKOVVPUkXVJl2kLydpBV7y/6t4ipMo/8AXnvVsofuPbCFVJkr/Vv0
XvvzbGM99KIqS/8A+2L/AOqL/BJRy2Yf8OEJwRruTcc7igS93pL/ANamarQ6rbuKQ37u2ImUBHNl
g9w6wc9z9E/6t4iuiaRGo8u/9Sv/ANTU058QsnV6EDLN3ypkf/LpxqJW2fLyP/6VUm06XI8YP6lk
veKwKWQZdwxa56XM0qCj2z+/bUCbVusGqotLL/1urRKYFfUzFzTAHAPKMscC6hnkLbTZhw0uoTQj
RZjJAL/Umz6g6Gg3LTPNAarIupn+ZLqR9qBYpyiQNPc7doGQo9waZZSZOmCCEwJO/SVUrymuQIEr
PqtieQCoi3+oCWRdDyGNS1a4sWginEXUkpg4ej4RAuzWFa8742oZURul7mXOPJVWAoJiKfUEYkoV
BFLFDr2wGOKxNm9PnPj+ntm3o26belcTFxc/G/RFzf17/wDwbenfHe+H6acneHKSU2QG8h7ZRBQA
ZdykTEleSBkVPP8AZ0dIKKYQWhkzyNWPAN/3Uo6LGsUQs+oieEO2sEYOwP3SuzfF9e/X8aYKn06x
EhW2MTtrCsHwC1ti2ayxjNK2ni9uya5FBfMRchh70usVOxeNRyHZ9/TbEBGs0Rw7MfF+lR9tTKig
u2fvppjXgmDQ6Rdo4hyWOdI4vY2A17mx2Ri99rxlgsISZCY1s/7ZNMt7eHLuCLIRqy0Q7YTWxmSL
RonsmtktajB5a2bWshgSQaBsgrmM17bAKBJplvF3dTsClow0h7TshsbHx1mxjnS2mYIDWELPaJBW
DStLHQhnSWhDPekosGrY1fJbEHY2HlmrhsEOytWRxz7B0h1TE8laVjQj1FLb2Z5OZelALkese1Aa
mc1+SfYulRozFM3sX23epJrWhlzGvkjntaEVoMikM1CmmscC6H3n/SiPz6IbFqyMzTUdBk7ze1YH
aKZX2DSx1iteU1iMLA2Y3ssblrFgWI3x2ThOWxthiyntGlZItxhXzGSRBlsA6/kNMw1c8xfoZFz6
IRMoa3tHARqi1W5r3aVtWgR5GSmx2igtsLIcssMjOxq16Owidw0epIZG0BEVtKVq0M5Y45L2Oxti
N4W2bIc3vCljDGjxVvrcAM0/qNk0KyYwWaj1N7VX8mdXEEKNqYrCg01eDG8ix5mKsWGJdRhj2TJs
eWNoosZ+p7qO0aFVCM1BLAx0p536d1E+I8VlEI2/1OOMLT8sUvLbVDYI6XVArICTowJqWUQzWErh
vvrmKkOidAkFHOromaj1XvlXqEQIWo9RPsio7K6e+G+m1NHlCn6kjRR/XksrFt/FhxA60c+faXUA
8ac9pJulbKvjjNqCv4TbtAWFXqmGePc6wjBj2U8tnIxeq4iYrc4Zti4no2zb3zbOGbb4qZt7u6/n
F/8A8B85+cVM5Y/4Pi+2NdstTf8AjNm2zJCR9QtEyys1k5B1GgRN1CxHD1QLj+phoptRIpT33cGy
copi6i5hWd/LTUCdudYPPj3584vXbpv6E+fzlXqLxGrqlhGT7Dv45fevsCQSv1GhGRrvtPHq1isn
23kpGkeMaNqdBpLvvKaQq9+HqJI6G1MhmS5KnWBc+Jn6tRzZ1islINs+LgtTt4k1LzRl+Qb2apTb
9UZL1C4uA1Mo8/Vg1yXqBxWlOpVg3Xh5+quY3XyteLUvs/UXtLsSHWHdEj47UqqyVOJIWFc+Jg9W
+0nU/ebMmqd0G48XG6qVzH3xVKDUj0R+onvSTZGe+NqN4c/VC5LuiFyJelDjdUPXJV6V+CsCiKzU
z2JKv3GTy3NM3URGskz3yFX3yFYPiKHVRuE26LJwrt3dIc10UgtYFG2ZqFZbXk5ugXL4KLq8nGZa
OlrGvCxmuuDFe68kIxl0cL36qM/P1IdVrHJOQMEKp4Qt7GM0bSWjoJf1dJyRbFlOjXx4efq6TkrU
J5GDv5AmnsiSFDeyY7U1BIw1uaRke2LFw1yY2C1FJChNRynui3JZJIMeO5rY8XCRo21sdIbnaklI
km1NKwUh4VbqKUxHajlvz6mZSJqSYxJFtIlJCVvfrhwkGjYS45IO1zJHHV97IXPq0nc08x3CupIk
dfSlwsh5lFKeDHXEpyPe4jhGUapcSm4SxkGxh3MVlhLXCLYEa5Xjc2ykjx1nLdjnOKqN3zsO2X9q
tfiTjNQhXEVpnsxx3kVJJB55RlXy5S4qTlQhjbskEZj5RlxXbrzVcXpy2xDkTHHe7GOxndOqVcjj
IYQTkzuKmKdy4i4r1xd3KMCkz6OfgYKhcvT5xExg1dgqk5EPXljYrcRMVMTGt3yPXkkZJrSxk2wU
Z5cLTmYztfuBVFkJJqjxsI31flev5/q7f016J1XHJjske2bY1v7q6odISbWeMyJSqYcyuWPkKmU4
/on7x6d/b9CwtHs52nlRj61/fWjd2yxVYYNKqjnV5AY5u2L13zf1775+KWm8oT9Oo1s6D2Fd7KIK
lclW5qOCqPg0PdYSh4jmwVAtfUeTjdP7Mm1aiyNAWSUGnk4SqXstWKqlhUCqyRR8Wx6NSPbQN2dQ
N4lpnd4dC3j9BZtOpuzhRcV44u+bKuVNO6QptPcWCpeZx0KbOo04zKlzcg0Sq19Aitn1ShwEJxSx
tO7jsarsI5nF1VUOkudp3YQKROTdPt2bp1FydRcEi0Kuz9P/ALJtMo1r6FXJ+nkRDUGyR6Lk+XQc
Bz4XZewakeGoc5sqvcHFYuVUJC5EoEe20oUCyUHtv6I3EGuINc474gVztLijVMAPmSqou8y0ouwK
aPtuzfbI08sfKWRLnZKCYAps+R3Ccir2lTEEudpVzsrnBc7arnZXOyucFzhii93Jt03xr1bkSYdX
VlUY0a97sZrjEKna3xQuTOHv2lXFCucMQW+LHXO2o8jGLvU0TjRdRAWE3mQqpHcuOC7HJt123RAq
qdpc7LsQW+IBVxwVTEZ76brRSHLp8HZ1FGSNIbHV2PjqiozKSofNNK0yyNCsQcJrRb4gfd4FTHey
IuLjMooySpD9PxQxb4bRTuyudhccBWo0Suzx344Lm4rcazFC5MixnSCUGmGNY+oiubqTTHssZ7F4
+/jLsgVVViuzx3MzSixXSR10VwtYQ0BMVuccYPlkWqKZNP6XeU466HDDa0QZYLOofClEjq3GAV6r
Gc3KqofOJT0AIMfX0MQq+DEdJzTWmBxmXEED6+h0+s+YCviVseVWxLKNqWkdVk9P56b/ANff+qmK
m3RUxUx6bZJ98+Mp43mTIUBsUF6djGUb2EBOqfJSJXpGjlMxkoTG9nvja/kN52wxOGakRZR4KMBb
t7EyokDlCtKxHinxO0QjcXOPTb079fhukhtfXWJGiHbTO6qD7j6Wl45JhMQfaYayiRUaCQ9qMuGs
c2jgokd/AbbRzFTTURCYgmBSyINUiRWmsQxkGKYRnGCBismvQKQdpA5Y2CVbEYsrjtKlkNioWo7p
F0/kqmVja6meUlPWtEksDXAhxWq+TsBsAnkIWvaVyREA1h2FdZQGvHBhsGcA2oLUg2pkCsWUanrW
hwo0eMspsYxtRME2nsFlJIA0uJDaJqSmucWvaTAxWhbKlK0zBoUQkQcgwkKy6qFVyA8OVXoIg7Gs
QjbCvcFYk18J2nJvkivWfYsU+45OlfEWS+Lp7myVp1WpGpVKYelVc39LOybQKJINM8pKeN2A3beU
KzT77l6BZzXTcZRNt0/jGiukS4WmN0XTSJh9P+8XSiuZ+knbytMKxIWllJj9I4TSqtYLTaudMoOy
gNN8h3Fd4qr8/GJ75Tx++Wpa9kbVDFympHTMZpZBtkabTjIpeJoOmubJemOA/oqukh0zya3S3HLL
T3bSDBV0ypEQMfVw3LlJQOnK3SXFsjTPBtzW+J1pq/zSF0p2AVumu+Sz0942V+muYmaR95el+IyU
r0l0envFz86iB3rKu0sijk6VbwkUvanUVUkFhBoYeoaloS6f0ystn6VBtN0qzt3dasIvRM0pWJJS
TFL4k6JzuYelGqIWkAsyx0q3hT6T75k0tGaknSolZf1LoJ9P0Kz3TdKDHF0/XdmyN9oMAkt9nKG0
oQ6cEd83Sakkg0gEEaJppkyc3TMRjS6YjubMpvptpF/1bWiFObf0JITxJyyjoXTSR6iPAi1yMcDV
LZBpVOjkiWtbFlTrXSwygoNGNblxSR2uo6YdcFpEeuuAOkVultNtjg5oi2qK6u0oPhF1gI8gOmo7
4wP+SGt+mb+lMXrtiYvp2/8AlVcRer8kYuaN97SQ3+LdL9/Tk5RGhI0grNyCASRztYreQLIKMSPL
X6iEmwWkY/DpuHUCbE0o9W2Mxv8AFu/8zk93Yq9U67e/RM/Ginf9Xcf2zf8AJRVqHzgkcdtZqmUf
3ZMUaeNcP7SpI78ujanauk7eTpiqXTbERtk1EFbTOC6dVCE4J41wdQ5QnUgZI2uSE1GNulVchQXE
Vu0dj5nkyARmoMssI3yDCekGOxMAqNUqbjitVDSRo5sRrW4P++Q3dsYX8uc1OzNmOjyayQpAagyn
jsbgdkz5zUQeL66vdJLDjpEGyyR0hf3iaP8AlvXiN1ojV7rDEHtwev8AO39jhbJS7rETIE90E8J6
Sg3cFqNmDRhNJf4r3/Xs0+8uInvpuG5XV4uDCBaZsOK1k3N8mREkti1jQYx7Vy5/0bT/ADO6AXiu
kpTTss2IsSpiNJYLtGDEuUlSXBa5ejk5IicU6NYjVuRooYbE8fWLERdkzbETKSR48msfzh6uanLT
0RoYdzaurm18hZkOfW92VFCoWfOXP8KfAXlDfNVkycJCxpRvEuK1/dhayai5pqMwVfe2r6wcTWKH
j39kEz1X3amaLb/Lkf4qD51MvGLpU7jxLKS6MMD+6BlaJppUpIuNXJUB024ixfGHmtf4+aQtTTMm
lUEWTYSJtzWMQde5zW4ssI81jLYd6/CY3NJncySX/HfO4W+nHqSBc2f00IrqMSPXuR0V5WCT6jFT
NQ2EWZNpgwxCdtxTxmWcheIY0wb5cn2j1FsRlqvsusLN0KPpj/SkSAx2JcwUbe2gZ06In8WLZELa
ahhjNAo9PunTIUMFPG1BqfzJtJ/5tzPHFmVhELG1tJeGZSHfIhTDKCJB1BzuP1NWuSLJDKbqKUGJ
X1era0sOLaRJrjvaMFCRhWajsWV5KWQknP8Akv8A8xPjovoXEzf/AOtfn0OySnTSD0bbEJzjXcdU
kacr+7IhPaEdhscMmL2rGO7aNZSXvWNEck4v7YgrVQTyH5RdQe5NLx3NmyyJ4t2qd0ny7F/o7Yq/
t0T/AOXbN3bPYrSUFmMauXyGWtcuVfMNmFy+PqEjtiPc11A5fFvHrxmO3fpAjngs3r27bdS6Xe5L
Dm7x756qShanjWpXtbSke4B4yFd4qBZOeR7oEN7Je20e1A95O1Ja0V06IlPfJMM8n2Y70c+ze5B1
DnuRHtYsgv7I/LvzjJ2Jyd6ZTt+zeBXZl06C+o1D5chCfb1EZVWgjIrLYvaFWy/+yGfcI2vdIkmR
gLQr1NXMlvNFJwjtMj5hvcMJFRNQ7cK6q7xgNbDFe3LcVHSDaVAoxXv+tZr953tg/wC/TAWIwhe3
jXckCn81y8UCfmXF/tiIqGuP9K0YrSqzfFZiNXNGBXaenKLUfanS/wB0eqiPZPXoaQjX9JBeDRO5
DyyYpAR04i1gHnjmbZwzjlYPeVVM4QNXD3WjdvB1HFdJypF2YG6cpRHDYJ3Jmox8pNb/AKRIrnT5
r0ZFm/yLqqTjX6uHyTTzv+t1NFdKZF0mr2XVU2Jnbxo9s0g5BypHuKqjqBdSN5xtIt4RrGOskYG9
sLCtJloFSvT2HAYjbSXy7EHfxtaiUzdDv4yJI+8I2nUimguRYl/GkyCD01JeG+h+ORGb5284ZpSI
5ZL/AHTUEB7rTTwlFX6xAposc5RSqIiPrdTV0icsXSZFDqWGlc/TV4kAttrOM6JQ2/C0HJZYRYdA
gJl9ajhxtN1SkkElCG+/r/qIdOqggaoqy2YoOj92Ta1kCxir/Gj1jhWtw9niwAx66Jq7VqnNGXtm
0vfikAsaNlq/mKohn31JYgYOsipIDZR9T0PiLFY+Y/S8RYkHW0RZlYre2bRNcQK2I1LCobdKs1hV
CuWhAGoj641Ky4Nm3o3z5xfQv/xbdd/Uq+2/s7Fw+LkCYsOVU27ZQbYbStoUaAVlbdhtVaeVGO1h
Dx3p2Xgar38WEkTW9iVIT6os1vj3D+7IrRsCK0tUGObK7z3Lvi5v6Fz5zbpv0+U0bLRlfJ2KO4jt
THFUb6K+5rJIwjYgGpMAdvau1a/ANR82nK1grgrXNsPc2nuMcc+QxR3HzpxEY7yGNj3fFyUNoiMV
zZDWFZFaO0Z3FlsIxox8pRBR1DYNe1zGvWV22NtjNe7Tmwmums7A7BjCrKYZBnHHSyvEDkG4ZJZ5
omNtbpONcrT5BkiGy0MIrbZGo/TrmDcyePsXpmkyknsYO3sWvZ5TgyqW8acfnjay6vEayte2VgGh
ElhcNEyrtuUoNkJwn2QxJa2zTGhyxhHb3n7ZMlxn0qMIStkijMvLYbxzS8iO98auy6cu2jxbFjmM
uh8WWg0LNvWIOvv2vMe/axI18wqLbDGSfaNOORAWU/8ATzsTTq4em7GUMoURJduFY77ZsadFuRGF
9QjhWVqNiE/ULFAbUX8oeoB9luohcLXUacq7UQ0A/UyNP9aEUYtQDZltIbOVmn+efpnfH6c45Dji
hzId1FaDUlsCS2h1C0efWIhUl6gBGGPVn836/GMwWpAjdZWLJRoHtDkyxRW32qGqlVKRJ8PUMNor
+7jyko9RpHKmoYJWytUQxikdy6IPSu7U0psoql0BwNSiEMuqwiJY6ljzRaXT+OUzQMt9XBE2q1a4
ckurYrmj1iHjK1OMUsGsYpBN1kEMi61ICWOvsnRJETW0fs3Gs2EbRatWJn63h7WOtwvEGtlXh2aN
VU/Ra5N0r2GVFyOne/XsNGzNQskzI2uY42XOtASxEMpTUeqiVqt/5Bjo2x/5AE4NlZlspHLdPyx/
FaPVb6x0j/kQaCl3p5s0Gv2Ro0rUR5csOv8AaPH1aWPOZ/yQxqSv+R+TH3Z5E2J/yK0IS/8AJbcs
NVyJ0iz1caWHGuyFYviED/yKUILvVsm4Sm1QSmS51ka2bS6okU2Xmsi3A4UlYpY//Ix44LD/AJCk
TBIXctVraRWjP/yVJcyTaFmSoX/IEqvBc61l2oc+cX1Ln56L6UxMXr89F9a+tM44uLvjskYq+6ZB
lGivLankNi2kmMkme86Q7E0bPrR+Tb6U3Pr8nC3El2LbnchpD3lS1k8CyXucO1kbSJRCY9cXovti
dfnNuu3TbIUw8XGXMxWypJSY/wCWuUajuJHFtgUbgXsrCy5EjHK8bwXUpmPnyZLSo9MDZGBn1aSR
Dd12DlFi4K3mOQpDmQfcG4U+W3H2EpyLKkNeyxmIiWMxckTZJEbYHDiX8nDWpjo8qqsWWYONsJnF
8g71DLmIiy5bkkd12AeZrlPMVDdzByzR1DZTXIWxlK1ELIUcaSzO5YIh1kLgVOilbIcj2rvHCZuN
fNcwwT4hCgcOZNIh/IVBNLyC6fxIs5UL3Gr5MjYxHri7rkfubhbO2kjlYRvvn5YqooDynY9xx55x
90kmMqRDIhyHbg5BR46bIdgJpUdV2MbgltDxbaJlvYAe00wm6zZDsUzt/LKmLYScWQVysOXARCmw
wDx87pMUjlxDkzuK7BJIdhY52pUTEjFjaiiNb+p4aYfUsF7bae05O6/O4Ryo9c770RSvf05uxFVu
UPF0iJMC4GqpjD4ZeT2ou464zmnC4Wb5zVOlDdMrsi6oaRr9RuYljq8Tm2Eryi7rkNE79POihj3d
nHfGloiyI8N8hU00V2O06VElQ3RXu+ds47rHgEOq6cLwmVr42flcbsmU+o31w42rZEjD6kmxxWGu
SSRkc6WaNp8kls+sdCyLXOlq3SpEbOrHxcXdFcu+cs3zfN0zfN/bdM5Li++b9EXN0zl77+/LFXdN
85dd9s5ZvnLpvm+b5viriLnPbOWb5vuquxf6CdN//o26p8J7rip7beyph8cmMbydTUynydUoIdZU
oZLSn7TKim7w30zUICiR7VpG8j0fumn0cybSKIrKBOxZQewaJUteOxplYhgqxXdPzm3T89d/bEzS
1b5gXUbWMtISCwqfujRXHelGrRngqN1RR7ifQt4Wlb2cpanyXMo04WdTwSDXKeUGibtPpmtaeCqy
a6jRByKRqMBRo4jaZrE+kNc09InMNSxMbVsdljTojZUJWO8dcdHVMYFXupKNSuLp/iEdMjpA6do2
pVsflhS7rX0XFPoyI20qNkBVqU9fp1OzcVCBSsrWqn0wLUDUDek+kTItGiJYwhiasZCng1Q2sbXB
cs6mb23VSvk12nU7V3TpHbTVHcxtQJjPpIyNs6ZGqGj3bYUyswgXDdTCYR9dWiK23qGDDOHxK7Ey
OFSvptOq8VvTdpkgKsWijJIkfS2JGuQIMyRnOVYD8dCe3EjOxtefZ0E+yRn4sImfTS7EjOHjum+Q
B9wtTWCWLqCM0SNjPfngkdn04iIGG5xKLTvId7T9lpgLuOA8mfSSY+A8WNhEdn00q46uK3GQ3rn0
4iJ9NJx8J6q6E9uMgvfiBMDEfP4OiyzYSvI3KSndKO6hEyLfwFGZzFa4cZxcWARiUVSs8kGrBBCa
KGUzUGn9sWrejVjKitgE2aOVn0yY9PpZGZpimGMUuRGhMAkaeDVtWwKfORYqyHx9NkVaWiHBFyjv
W5oUKM9Q9HlhuEoq8hUiVjiyKSpFAj3wmLAcNXS9N6bfLICKKMLWEJCuoKEcIDpsfu3NE2UC0jeJ
JX0pm+b75v0Vc33xFxem+b5yzf1b5v8A0N83zfN+m/TfFxfSn9P8f19+idV3xUw6Y73WpD5FhDhJ
Fj3thxbpue3ksJJbQ1/iCtJvbLXu3jySPGQs5O7F2UUmAyQqx07WohbOobPmWTEQgLyKgnPZti/P
Vfb1Nz8aDT+BZE4MtpTnlCHvlp6lBNlOGFhXpKn18fYEuX2ctJbSppmN9iU/x0sZzVzTokIYjeyO
wnptG2lWEaPxBMl8crDsMydvwq0cqWD2hx1uqurCFXLEzeCVnfX6G3JlG3aBR/drIaAwvuOO1O9M
R3Csa/d8dpHvCg2MluWRLio8LUHHkRHtcHUi7tHfeHn1w0olQRyB2aVxRog7KOYrnRCxSNuH5VNO
r50po44pw1lQitIDUe3ZodnpZDe4VYx7R37kGyusxmU8RDstqvhj1fHXSJ3PDd/6dt/ndif3UMBp
MhjQce1A0se5G0ZNOxeSujv8WVE70+Dp0fa/ToVWXptnCHptHvSgCiH08NzW0TUMLTrMdp8fG9pu
yhx8XbYntlEFDya6KrA6lAqLT1DTsZp9mFoG8RU7BHjsQYLETSxnwkkzIWnQiEtKBcn0LWZDomPa
yjjtSbQsVkKkGRw6ACYajCrI2nmdy3pmBHA0+NQS61gpwKQbhpSAydRNRtRFCHpqiOPOw6VI01p9
iitKFna0lE8dJ/LxqBhBunDYQLqYRxi0o3yLOrAEVTRCaz6dHyTTBM2rTgGzrUsWQYvhx9bk+1Ch
vkO07p1oWFeAch/9oYhW2pPdooUaQ+RpdDv+kRIcSfZtr7LT1z9UZfrtXadp/PnRozIo8uY/ekr7
N8ByWCp+3WHtYqu/oX56b7dduq5v0+Om/Xfr8YmL036Iub4n9DbF9Cevb0L/APH85tie3VVyRip7
0K/9q3/W1B/mrHKObTu5Anu2j2bneXVL9mwVnbkEVZsMnCM2xYr9901H803/AKy/6mo/7y4vodiZ
v036fGfjQXvBtv7bP/Y03FY9XtQQ7iW/erKiTa9yJHviImFkbyNOkaorl7e1Ym/fpYrHJMIix7su
ztPyGLIjkTxr8qMXTu6iORo2QTMJlsJX5Cq9lI9sYbpzjzYokQFja+K51sM7YBxrgTtVV90GLY0h
6MZDkse5E+4Tbi3j50j/AF7oqskURFUOoP7JQ1JIoafZDkSGOosO+QxUE0UgUpbKta5sOl2I9WxB
3NkQive5hdOL9nUH+PT41TJchoBwZTTt1EPcbFK2XTucQd60aNsNu5o5PsXX+lb/AOZelXZvjEqD
qaLqGUQQpriFdpSS5JDP3AIm1sH/AA8k36OcjEdNC1Fn87D8OuWjJqCzGZsheRdsT5qiOHKq3q+D
rD+3RhVfk13CPAKpo2pnqBaYjiwNSyCCBpRjyS1x80I1s7UXZoX9yNZS/ECuoRuDQye/NkP7QQ6i
ZvAlpLW5TeNE/wBbUq7TIHvDMRzbOUn8arlP+tE/a2/bIPOonCiyK4oigOVgh05xmPNJ2hUp0OS5
fwg6VkPOzbLuUR1kJNgyrWLCx2oYu1a7uR720dWCqJjp0PVsbvs03p5Iwbq4HWho7J9lalXZrJvd
sDewoUsn1z86vkFFCajkXQyLxvvetoLxtRLHrKE9QGbIFaymje7+11ivnOXZurSc7FcXqvXb0b9N
826bdV9W+LiYvqRcX/4d/wCsv9JM/GLiph8d81ROFhGktNGvonczT8LuygHSIzy2SWXMPd1Z/r2D
XkJ9N9xJxi2Ul0eVEkcompXe1HDVZJJKNjX5ke8i47Pj+j+fnNBLtDsmcx2sZUJX2awSxJjJQp8B
CN8VR2Fd/gv2KrTJ+7S7VbDuGfbsG8X6RH28mp9i6RUJRjVbIKfxdQMVU00VPFsEUjKUSiaRGle4
KMZLjkO9lX2jB/wWcFTudT8WypB69aGzkSJDHq6OIuxZ33B1cdRvLKaJz5jStHHVDTZaDBM3mHpB
8BXYOTCx+1OqUagtQFXbTR0TJf3R1kPtFI5q40TeNhGId5aPZkir3NRg7QbgHcFTbCyzZ32VQOwl
8dqsq6xHELIZDDd3SmWOJ0ommYfYHdOTxLV33V6Rnoh6CSnYnQ0lJcQWiTTEdfMEmw5DONoB6eOa
a1JCORWoRq5bx3yESnexkOLxnL8ak5NKQxCYgnKvYdnYXKmOqyq1nbh6qY1zdHu4OtHo2LTu3i6v
MmadmNdElwkl5HCyDMIvMS0jzlnVbIqUgezE1C3eJJ3bI0YBWJMTeJcchSdHzm9maPvBjbdvULOc
iD/prHRx7OS0ESqnsS7YRJDLGrF2rleyej1M2tbb6rSa3Stz4TkVk8QI4q9lxapLPUxR18YdlHI+
4iNaSGdpw2OnvOO6kiwwVEoats63z2wo3hRjmDKm2l8GDFtrQlkemn+Easth2YWV4REvL8UYWn65
rcNcRgFsY7J0QtSkmdR1X00U2P5Me9rEhPpY/mS4EdY0TU7eOUl22xYlcJpNSamFWRpUtZxl6Ivo
3zf+in/zLidNt+m+L136L/R2/wDjRfbfFxcP8O+UVUXT15+6XMGUVPKGFbO1Z26K4w8wRHxLAbGO
kBe+VPC1PqzOFvNR5Yds3xb2ah8qpIxBs7tu0qSpldi/00zSlg2Gx1qErLeSFcO7d1TavgF+riMP
yQLKiW4WitrIZEcVPIqrMIR2NuIjLErSvpp4QMPdCcG3lsNlJJEFR3QkFb2LH5VW/ikFbCK36sIS
fqFneZeje1LULVnXYuMfUIXYltHyddB42E3vvo5ow4l+LtFvGDKK9ERFuQsSyve5lbf+/wBeF27K
8UuVU8SZE1AILZd6IzbGajzwr5jA2Vqkha6csI0XUInN+vBbkjUmxY2qBcf1HHyXqUTxhuBPLF1K
ADZOpBGH+oGBKHUcdUJqUKNn33kEBfBEK0vVkY8qvypmsivhakAFltqZshJR+85V6NXbKfUCxc/V
4uza3nlOpbkcLP1kJBSr5jz/AKqZ2F1C7yG6sY4IdV8CM1dHVsvVolZF1Q1pf1qFB21qk11ZA8ks
XTqKiacbhqBrGE4VsmNrMQmWupRzsqLjwHS9UIZkXVHYZaXPnZV3L4GfrRvbl6gMYsLWHZYuuB7T
dTLJfD1mkdljq5k5hSd0tdqrwmytcocc6Z5ToNm+E9NcJwbrRWuS4damiN4xLm3+lsttTEmKE7hk
hazfEHY60fLQpXHeuJgyqN1fq4kEc3WhJTY1mSPLNq0hRRrM4ZMjV5CjhapPDcmvi7TtZHmpAuTQ
Tj14ZiS9cSDsFfSRHmWRZq74122VtseCpNZzHMkTjSTB1bKjiPYmlGFqyUAbbmQ6QLXEwOSNeyld
YXUizyId8Zzdazwsn6qmzmxLQ0N5NazlZLnFmu39/wD5d+if/Hvv/wD4HbqqYvtm+H+HfKZHY4i+
PJRohm5mEZEGAiuWIfGRZS54svCRJPFIsniYBEcOOfjIYRrgBkKhgEbj/bFxcXpti/0IYHHcOqPt
IjFZhE2z5wbTpjueRgyCL9NOrZEV48AJ7nDqjqh4D2J2nI4FfJc0lWVqPGrHRoRi46sKjfAfzFTH
VFpy7Hr3pgqsrmpTmVJFaVmEa5i91zcUz9sBGcZzak3F0InMVI92LSl2PWvHga9x8bRv4SK94U7a
8otSUySK0gci1bjr+nXZ9CVFdSuc5unnYmnn5Io3MbIi9pzk3VOTlh0jpDf0ztn6cdtMq1BkesdI
VmnntZLr3Azw3LhY7mYqbZFjrIdH073GyNOdlkgPaevTb34752s44rd07aYmbZtvjWc1r6Vx0k6d
7LJAO05N966hWVh9N9kYjvrDh1q8afrh+G1u56TrJ0xVai4xuy1tQSZjNKcUNppOJKR/eBpb2dpZ
uy6eVCC0g5zX6WazJdE0LImm1kKzSjWpL05wbJgKF8KgfIbOp1A0jOOb4i5Sz2RDQ9VCcliF1iO1
i9l/Fc45w6cPZG5tm3vtvjGK9afTj5uP0fwHZ06x1Vu2LnDBD5up9MPn4fR3bHb1qxV3xGcsZH3y
n00+cr9FoxtvSOi45rkzbOPvBhPlEr9FK4V5p9sHBhUhafSDpbJWjUEK3qXRH/l39L8+jfN+m/pX
p8/1PnNv6KdPjPnpt1X/AODf1r89Py5N8cm2H+HpjE3XT9LzyZAYwVLHYQk2qa4dNT7OlwRsWBXD
I0sEbHyYAu2GnY9lpQbZEpk7F9AaFtMAT2T6hHtsIXZeRvRcT1bYmfn86KiNkI6AIYrhRsw/u+DX
ukPFRNYKzgdjKOpRBOgsaO3iM20/WoZzK8aJZQxokSAhp0atYjLCGLjLhIsmsqmtGeELtx6xjyLE
GFkcQz5KrG7jGNiB7RXz4DOE+v8AufTCY+teiMhucSiovd1WJApWNWT4QwsCgTrNqWuyJStDigDx
sKtHMFUbyq+rEwF9BYxlFEY5khAgZIsI6ZElhI9JMUbYsqPIJYRWKCwgqQv0V7kbUuEWueEbD2sU
agQZhahjMblJVt4vCJrLUY941cNUsadNpcDtOq5Q4hKKSGU23A1Ytu37ubb5GApHBoSEaunyIj6p
6KykIqNoH4epeHI1a8+fp56oWudFdpZ45DZ8VsgNxVOa54+27Skhh8niR8W1HylxaMhs/TT8mUzw
YZitVcis5l07AYGJYWKQWxSpKjyRBjlNfiAldM84ShZ3Xu4tn6maN77fz3wwoAEq47MhzGmGeg8m
bGijiCtKtkkdzV+O5yYuD+dPg5na9PCv2uJKj0DyDHpgrlkadcNoaZ5S/pZ7WJpp7snVaxchQHSV
fpwgmU1V3p0aMyCAFqORJtaxkoJdOOR0ioeN7NMEeEEDtT4AGx4ciwGF2qSixg12qKR890bSzArH
jshBFdDLLs61koJNMv5yqRwnxtLFeLT1EKOltNWHGsZ06yzSlK05yvZCjVVwlkupaoZYkhOB1XPn
qqdF9v6n59C5tn5/+hOi4q//AFJ1RMfhfh/zDTeVWRUGDUMpwkqZ3ZkwWpLY2GwTL+Vxyhcr40+O
7JE9RNrSdwDmo9GtRuanHtldMdHmCYhQaiCjVNi4vq36JidNBfFj7BtyKpoUZZRquraAc6Y2Owhv
qEqnEigtCLHyfYdx+mAcRWDe0OzsNs08ndMUOwLKaosiF8yZCFvHtDqDKWf38kj7rKyN2VtS9tpC
mkkrIqhbOnoiRq/v46AEaSoQtodU1SRI6Bxfhv7ZUgXcHBh9ortt3p+xyObNIPlHmy0hmqpiSAX6
7iojo1swaSGGpGvSXAfDzyTyXafr/GbPkIrYlWx6fTwZNrB8LQpIrq2EWYWKqRY9pKSTJq28Ytw/
tBtLRXZTXrhPjubMHcVScZoey/RfuG294ds3Y7samaWqENgoIRIsULknQRDdGrhKzwwcrGpY4dZX
ojmxBI25qWOBpNnA2T69sht1V9l2j/Ykv/WjwvKso8IUZnbYuW1eJ0e4F2zKmQ/YunTd2FKitkoF
iDHqp796ejdII5468ALxDT0OIjS1YTulVHjZBs2KPxwlN0mBcYYWqwesgp21xcHsmaUkjaVGNVt9
tHsKTtyIquQbTAZIZArxhWTIYzGCYxuo3tLM01RpEw4mnHEgeLbP92gioGyKuw4E0Mo30qOpLWUO
HEqpIZ9qn9usSIFSSiSVpqR84lfXiqo7LhkqzJ/aGGMU8i/srrQZjvrI732M1ldFpC+RDOglatdE
ksr65IJ5rUfHqY7ASbxdq2V7Sts26L0TF9O/9bfovT46/nomL6N//k/H9Lb+jvi4mKmGTH5GXaVX
P5QtTN/bHY50jT7HDCVNx6gjKpNOf4LCYg22KKbKr9sY9sscscyGHqZ26gTnOiL/ABtSe7Te+L6N
9826fGb9W5oF37p/+G4T72nHsa/mijuAkcoirGk0xv49+bdkl693SkrvitjfatTbl0lK5mKf+PfF
XlUyFHOhl2j6ikft00zk2VI7Iqud5DrAHdyNVoNZ0pI7HFIaXDRPHvDkZiWptoFwxqRrcZCNdybu
1Ty5HZHAsO+Xb9z12aQm8xzv4987d+mt+1fN+2GYYDlu5DMpJXmDu47eFNAaZ5uMUCWDj2cVf48q
zHHWTeI8UlfNm1Fe0Ib+w7CDnO86lIr42pSqwU1yuLAgvlEpYqxB3s8bRyiocmjG7Bs/9O4XY7vl
M0d/gMZAMfqAaOnWKyCQF3jFftYOTkjAtHjSI51h/p6a/bMkqrQxHK8OrWIxukG/flf69Pulm5eK
SdQsCSfdOkBs3OIXIXsakaja/UEosdtQ9xIEyuSWbiyGC2lnnv8ApkmOqfUGs07IkvmSkRY1lLOG
ZTyZ5zp8Iu+WlsOrZDkpMj6yX7bk3VGYie+m2/zGJsmqhr5WmP8AztQEcOIPVjmZVEUsGexXTnfF
6bx7LTuoUlrLlsiBgagSfcmX7cJpX2c4qCi0QnmuM1iF5w1Y3xp0f/BrvmpKOqWeWvgCq4+qNV9p
NHS/5xv8cQch9lMKgotQF8m43zVgVOHTqcK7V7SPj6bY4dcpGo+yRzo1AGQ1+pJDQ10l3OT6lxMT
0b9U9a+rfPn0fhOi9fjrt03/APt29XxifC9HYX4J8jXZ9HasPGt4/fHUQ08tZCRmQrpJJLYKHbTM
7I7CP3XrARBRHNYDUT9spJP8XUL92U8Hu4slAAvZqEc/3x2b9Pz1+em/XQbtiyFQormFu9znxS0d
62S042GHNr0dIp9kDeNRUlpxJpYfYBabKK1YjCaTB2yP28e9GnKpF3pcJU8e/Yjm6ckoJTqh218Z
IyulM7nNqsLC8gxqxoEjyGdqXGbIUtY1jLZrGLQoqyYz/wCK4yNMUiHZDjNA6bZNj4C2bJawbVWx
smgH/vlpw9odoNHiHCa5/wBMYRteJkNt7YN4adktVlzLb2QzEDZwZzSALCbIJKhCENpWstY0xjYm
o5KPfXi70ym28fUKtcOSznLpIjBMsbVkYVlZulPrI/kvoIzY7LiSxkWzJzKvTSdk1jCubKYytjsy
0cMRa+YxIz5rHT32AhsFZiLjTsYSbLY6PTlQctVaRqmFHZqa2aZ+lGtDkgjWBbMbGsgy2SRfTw87
l0Zg5ER8gn0guwKszH0k3gI4Ry87wYg41qM5CI0jAQQiyyJFEoBRjtDFDGfcXAgx6mMyc6FEBEbb
6gHHbU2YyQ9V2DSrQTRNr9US/LxlMV2fQzY6kMmaVitGVCsVL9Rml03AUW/IzwpZESZpu6Y4LVGX
F+NUb+ZFnviPkailyBw5roxaLUA5I3zACFdaj78mrPGhRz6zYKZJmx5UaF47rQckLmawKEq6QnhA
y/1bsB5XGfDlujP09qRhxusowx32qPIkU8mLEjTNZ9qW61izIdbfiiyFlQZTSWcKGK91WpJlLqYE
sEzUESKLUmozWUnF6L026p6dv6Px1Tqnp29C9V9O/p2zbpv02/8AqTFxV26F+CfOV1gSG5uowyBA
uGhkTL9ph19qsSUTUo3ZH1KIefqUDlPqQb2t1G1EtLHzEgahQA7K28nIF2OMyfeuKhTK9XL0X+ht
0/NPZfTTB1aNWzr3yMMTk5hFE+PqTYT7n7kXVgwpN1H5TTF5lhajZFw2qEksmyu/lbcthJ+rmvZM
sllLCneC8erkaOZdeUgZb4xY2qeKP1O1UffEUotVcU/VWSdUOM0WoSBVmrm7SdT9xJExx3QrLxcF
q3i0948qh1I9jf1Jukq3fIyLYkiObqZVbMsSSMh2boSh1YrMLqzuJ9berxamIxC6ke5Js4psiWz4
WS710nHl3WFqAsVE1e92Sr4khEkOaVl+bhIkkkZHO6MQGpjjSVdGkI9zu4y+KJsmyJIxzt8hyyRH
B1PJYkq8PKaVyuXPjI0t8Z0fVUliE1PJKkiYcz2X5xNW5P3H6gkPaC/kAx+qJJMXU0riK5ko9mqJ
zcLeTTtIryujWMyKjr6a9CyCkdHupoUXUNiqNlnlFrosfikeKmPjxuNrK8TG385cNcTiY2ykgd+q
ZrU/VE5cNbyJSxrSaNPrFlsc0mQsaRJj4+ysn4Vkk2DlywoRJMjGklhylK16hWFt3IC5ZGh9qVKe
wizbFWmNJcrLmWFC2cs/SMw++mGyVNmqQIh0ZyVK972uA4eBcZmOdYPR6EY5ZsjZCP384yI2YRqr
ay8IchFbIczHOV+fGI7GyHjzzpDsQi4ssvFHrv5JUa0jmKs+SmPknNiLtiSXsx8gpOiYuJm/Tf0b
+vb0L89V/wDk367e2fOb/wD279PnouKmF+C/LchxnlclM7tCrlJILTOGwEDvmdRqNseiUmfp/jjq
DZo6JXJLqXiyJUOM2bWKHIVYslkmoexDBUblxcX0b9fz89NsrIflnBpr9k6m7GGHxdx3UFe9zSxH
DysrFlY2gV7Z1QocDBcdwNO8kmUnbTxV70Oh5tPQcWzISidX0ffb+nNmPpncw0Ht9ARclUvbyLRb
p+n0yTQ8ElRuy5WrnBc294MB0l4tNr2zVGxI2nv2/p5uTKPgkSmcR7NOI5s+lUKOiqpK7TynbPof
HbW0vfVNM8WPoWplhXIJDC/d2t84LjG7uqqRJDZmn+yM0ZfIq9OuOlhQ9hsOp754+mtmOoE2sqPt
4yoeXJNUQOEEqZVxPILX6fY9thpxADnx+09fbPnGplTC8l8bTXIV3WeKrm+6iXHMXOO2fGb75Eb3
C0un0KyfQsECHUtOYOnQtY/To1yZp5ULD0y1GLQD3saDgyW48V/nzMSbLXK6vNZPiaZGMdjp9rUs
ICge5mdtVyBAU5K7TI2iWhEuTNPbZE04JrHUIcdQg4C00jzfp+OiG0+NzbytdEVTnRWPkkUcGQbK
TS6KwmnwcLmhUWFjKiqxUyOBXrRUQfFZEEHDHRrdSE3dp+G2QcVFG4ajrOyWh0w1RFoo7mXdD2sO
ztP39Xxi4mLm3p3xVzfN9/SufGbf1t/Ttnx12/8AkX07dfn0b+lP6S+r8fnFz8bb4X4f8p86ap+b
ZjBgFWmGtg6Kw4YNLwlTxsAynUZ0loMbnGE8UEA3jm1YzsgVTRD1FFRqUUkTcfDbJFd1vaUjNsXF
9H5z5zbPjNumh2o+e9rRgup/Fxn9x9TWOO4VcMYrljBJpuAiRX9sTbNzHpp+KhpCMYDLJ7No8dpr
ONGaIU14+NkjSFqoaMCcg2tiMYYp9gjhH75JkZjcfNFHyHY+SWWxqglwPIImn1dh6BWIypc4tHTI
LOKbEitfMI1BCiyVMY8NpcDXMDizGNJLhIYS1zRS69jWx9QNTxdOom006hFKszI6QckpY9C46fph
USZROGgKx7zUMRwh2Dd4gBNdMgI1se8RPCoAtc6WRwgVpXmy6G1I8B4S5MrmmHZ1aiUEh8IulrR8
xti3eJcf5X4nyAKldp+nKxzE4s1QLkWHppx0/SyNyfp/ttmRuy92JgXcH6TkKaLcv4QaaW76l+G8
uStRcevEcS0KazOxHBuAK6ZW6Yccc+l8Z2na9keNPmrEyOTyY9pTNO+VQbJB0087nwW1jiaoVEoP
KM6xlsiiNrZrFhXMyfN+Go5HZdNO4cBr2RNaKjWjCrloNN99WVARyF/YyFZGPOlxmyBG037l0495
Q6V8ccBOMXUAZBglgWGz4BnmpNN9tqeyTY6Sbd/2xwLCQWxngaaLesRs9enx0X+ivTfp+MXpv7b/
ANXfPz/STp858en56J609Xz0Tpv1Tovo39S/1Pz1TF+C4TpppieDqReLWlcM1BK8lm2ajk7JpVd4
8mO1yWJliM0+XnG7jd81MmHcoiU684upG/tNjvX8ej86HXaxlpvGu/8ALWxvKkV8FscVrPSO3v8A
lS9PsRoLlvFtjOVC6ZamT2J49vLUead+4ZrU7F0ZQrCKkiXWNRI947tLSS1JIVO4OKMbC2zvtpEI
c8WIkUdjZ7LWxEcyXIBFQksZGQgje8PFqYUe0pW7jCwbTKvvkoHGc1Pt3pnBfpyW44b33BUTWx1J
YCK1sUUhB0je6ELAtydGaRsSpYxRq1MnrtEsTvjStMSiFjXn+pQOdzJtxArMvUVYvlPgyqab54re
vb27ESMJor9rJ/8AqXf+d3uqZpmq8lRCZDEi8kng785EQIxXaHmTY7Sgvw8DPTPjB+66O9o97/o1
Hta/jF35F/xVwnJbl/sZBSRNC3ths47Sgr02iWKN7cL/AFreb4WRCMmx/YbdQ2qnNp3TiudLksrw
XlyWaWBEWQalpWQg3V02G2icQsWTLFEYErTD1hHcXNOaeUqlIKvj11v59s/+0Ks+oEXYVVbqWY1u
66gsvp8er1axoU1ZDdgnBmhSoCkiQdIwhP7g3f8AtP8A7QvGtjJXaNf/APqddui9dvSqZt139G2L
12z89NsVPQvr2zb0Jnx0+M339Ke3TfOXo/GJ/RX0L6tv6ydd836b9VXCruhflM0wbeBqBncYgFea
gi+KJCNXL+JzzSqcRWUlRZJG+UzT4u2C4mLEdTz/ADAaiduihU5qh3CNqJ6bGXHdFzb0/PROmiv/
AET+8W+GvOsmNhSYsxsgNlC7rZkd4C6Yc50W7e7hNRXE0aRzx2D3IK3cvkaYI/6mj18XUD13iuck
urevjagc7jpfZcluVoqohHSJQkJgoDWZZFc3PCMQtaziC9Er0bCktQdgWBkPU/ePGL3QuNykSl2D
AcV0zdExSJsfmSV3O2C/L3X6ZGrRXI+YFiGUzocpqadaRGY93FsmzN3GSjvMFftC38mw/wBS2ApT
aXCrA241JFoR8FtOSxaEZGZcqnhx63zZkGIOAC/u0RpSOkl0fGcxJ/8AqXi/yFxuaNIignoqhjps
I/8AvE9xQoTmz5DuIL8iOkvaucMa330iNUBdN5wacC/VsiSlLJxU3QMFgikXYU+2JDn116MkW+1N
slHYsLGsgElJEF48a9L5xqsHjwTJ9odUhbRjEEOzhyrGRI0r2BUMZB2pHcGXx3PsqF6OrtQwnTUr
BdiFYxkmySmDXR9Saied2k5jYszmkgMOveGVaS2xounoKul7qiajgrLHE020iG00rXVofHhckV1i
FTx47eIJ5vGtUI2SGDUeNMubAcSJPP5M5f6G+bdF6fGb5v036Kub/wBPb+lv69unxm+L/UT46L03
zf8A+Lb+qufHRMXFwnwX5zTV4gEM5hggjI2wWUgY8S9VZ0giSGVSNjultQ+dgYhRZbBN1FIR4tMT
EZFvZbe3RBQjizmRhW1p5Dirvi9d+m3r0mXsWSSGkFbgGRJiI19RdOgkDLZIDYDEYtKRoWXB2OZZ
L9zTe0Zk2QxwbtzOWm0a17ZQ/Hu3sflWznOrpLGCu5A35WT2xZaSmnQSjA49wxChsGEY5BPJIfGa
OPasxxBnw5I4WXM1j1o+Ljw5wmAlWQxnZYtK0RQhdZ3bGJA1Eh3jnhRLW8RGQjJMfWnFHZMliePz
AMKJwnoyWGKkvUaNIC1YdiFjpljaBFlfeMMxbIYnS7ZhB9wRpNdLAEcmwC4TLYcczbAR2JYhA26v
WlysliCO31D+yXMed9O4bj1UsEZltei7FkfukXppy5SI4dwMw2Xw0ydeNaSHehKxLKMxbfUScPpR
LB36adi6WXCVCRXU1oCMOzuwPj1U4ApJ9RBaCvvmNPN1O1mQNRhMgjMM22J24Vs5XSPLOPHGeRam
4dCJA1IEg7fVLUbS2zFNYaqaIdVq5pV+vx0ki1JCen1+CzLXVEXx663ayzmarE6NYS/JlUGo0i4z
UkNWzNVxxMHq1EfcahdLart1CdRLRaoSMkjWEVgp+oXTZUfVMeNHJq0jpj9WgJHrtVjjmZq+HtL1
pEYMWqnpNbrGM9jdZgY+61ECWlFqzxMka4ioK5vS2Jdt84KmcccmJie+cd8aPHMzhm2cFxUxMVN8
3z5zfp+OiYvr/HTf0/leu3p44mb9FxP6G/Ren536benb/wC7b26L8uxcJ8FXFwSrvFupLGLYF7jr
iSRiSXDMl1I4hvZKYmopeP1BJcjbg7cmTiHyLYnjJIsCnyNZFhYayMfDPVei4q+yL606b4AjxvjX
E9uSJ8o2FVVz8x7OSBHzyPUV1KZn1CVIaZrnKKxPHz6tLK03dfg5hYqit5rsI6QbEc8BBW0zCHky
EcJzXAlTG55k5UMU6qGbMTPOm4aXNciyTDcl3NTHW0kmPM56ie8bhS52xXmJgHS253p2G778Qb+Y
/N4laZyIR4VDNnPx0mdn3TuaGcifztjRjOwQZSYjJuGjyFwUOQipFlrjoctEKJ4nPmyWZ58nFMR+
R2yn46LMRDNJiPK3CI9UVVwY1coIU1Wnr5jUKNWYqYq4i4HvKqQJLkN3GLzI3FkGyLJUZ4F9CQbd
TQm47VEFUuLgB8eR3JXEcu65u7OS5ursAj+VJZlhgttQsIKYbvE2Vc26cl35e+64vwmI1dvdOm+I
irkamefJNa6OnH3j1rzrIhuFitzbOO3RFXOCY3I0JTKLThXNl0zo2PGqZwzt4MarkShLLw2nHhbJ
jdhyrnDfEHtkWvfIc3SxuM2ofGx7eOccRuV9QWbiaSPxTShVybp98VsKnJLc/SpmMn1z4yqm2Ln5
zbpv6Nuu3Tf0fjb0J1X+jv8A19s36Lnx0/PoXqvReq/1NvVtm/t+cXovvj/gye/zlbDdJeCjRofp
u819EihbUqs1aJEFEpEepKBGZ9CTgKiR2TdPK1tXSdxLOm7TayC2Q6TR7MnV6iVzOOO6bdFz85v6
aSP5dgCgThZ1oxtmsaxw2K9YVM4g5lU4OUdV5SioG8bGoRiQ69SzYtCm0+ma1DQdpFbRfsPRo1ln
AQK0tJ3G/QmoMlIjiAoURv0oe8ykRUiUjWolaLeVTsVlnB7TljOx0Z2dtd6qofJJG02xoJdQ1DRa
NqN+mC3mUqcYdFyIyjY0djTJxLWr3qbTzVFa07AipqpD42oA1p4wW4SOMr4lIzj9ODuWlauR6UTE
JEjMz6WF7L6AglWC9+fT3ZArHGLWUDBjPUiVtvTbLDpOWTqLg2TFUS1TGuPTRQlbY1YnR7gKDKvT
5zTUNkkkmAMce0GnfZEc9fpZcfCcxHM2zjiomwhcsbXEXHV5GY2MrsbXvXEqiKj4jx5Ug7kqPBC2
HfNa0rIriqlUbYlYZmEZwzbbOO+CjucroBEaOOr1SvLn00mfSyOwteQORRqpaOGFImp2sE6BAdJP
WUQo0bUlWoldGXmKpIRHUhcLDcLEZurK4rkZDd3NP0DADVw0W1qGyhT6d7DFgPHga4hspdOvkHjx
hQhPYGWzUdJ2sK394I7iuBpwnCkoBxGKcTXWlQyWKxpCNKWueNAVzzJpTtQkmXsWC2sth2orWH5o
aurHWjSWGQ6+oWFFPB4x8X07ejbNuidd+nx1Xrv6Pzm+b+hcTF9Hz0+P/j2/rbf19s458Y/4KufC
6OrkKCwckUbbJGz4BElhHTNQtmqRx0M5ZDp/LZJysbUmQrSMQrY8NkfNQCRBhnLXSK1WzgX8FESQ
3Zzk9O3Tb06R/wDY5bR7+UqKVVISlqFJjQMjCuLBu+loydmURY+Wdgm1APuySs7QrCeiIBUlWMYH
AE6dwyeZJD6SOnYmSnR8hzWlkH37UJhvKmcRjlWvB9e+RIMczWBJD817KBNpFGxGtpEcarrGx0yS
1PLen2QCN5TmorWia3JksgjoJDDnMYA9ZJYUFz/p6fdss3dRSoUhXVoCjkIn2Rxi+WX9orS9cJ8C
RJmyY/248iH58hmnxNQlANUgU7QEk/sDWkIV1qBHx4ls0UngyWO4p8kCUD9GFeqzf9W9T7zs/Lfn
S8L2lxFWMeF3p9bpsTBLTAyy0+3t2UTxyO6UMNDvi0o+3OoBvHCqmrIFQiVv0QKJcUiDZRxGuOKP
sG8ifyqPT40AtYBEsKwSCuANGZ2NzSdOyVlvTMaCgpGkIemCiDpguRKyM1LekYookUaWUALRh1ZG
Qa6aGBB5f9vxqSpbYyWV0YaOggdmoqZomUtK+TJSnjNDJp/GnsTiyfHKspPZHxY5iy9OsPkemjxg
1yDR1gNxY9KB8fL9u8AYFkStN6cQbJZwgxMmwSvnJ8duKU0zTzJCgqYsQGpJjQmixJFoWirPpkTz
hulmTcVbBdHs5ibxL5P+y267Zv0TqnTbrti5t0VM29C5t0Xpt7+jf0b+pem/9H5/o/PoX077/wDw
N6r87+7sJhs/GiNvpuoU/Yb3fpM7nNzUZHIukncsK5vG2ImaVe5QnmNBgjNM3UH+CwT7mlV2h6i+
JX9z8X0bYnpT3zS3tcP/ANbUCfvrgoaXCAwIbiQ/Yj/5GmiNUVuREFayFV2lTtekl6ePeSP3afOz
yIxE7GoD8VjyGjl0708e+KiMpXvLMR6MCCax0ie1SCHVKSS1jYY7Wze51KJHCtpzorW37CNrpjCO
ZMYqNXdJLNzboxjLFj5K/u6WDmocC/b1MuaUVVHcp/FBZpBI3VA3JXTRWGLBbz/talmN0o/7wTYv
dm1FW0I7u1SMlI7uBVdsdNC3AymmUyogq17VWy9oVgjnSdNIZW3CjaC0IjiaKyZ/rXn+d3Rvzowz
+4X/ABQ287VfYQJpn2j05M1F/nXBN3dpWoRWp+1EwzlHbs/tiFc6XbJvBhEVtoFdxXP/AK8dNgap
mGBKbfyHMsDOkEVMY3bNEe0Qg0I2PHQGWbuMOCu8S3tPp5pmqBvjOlKadULvXaz/ALKcxPND7h1a
hCn0iLsxCFaJjtQQ0W+uxyGaetIvHf2tLGP3k90nTf5DffLCW9ltHZ3HXJXBh6TcrgzDdgdQZZCX
y/wdOae45Y2Qq4ArklrbJ8SZzvIZk+S76zGYhXXpXjgPY9ZOmKsYo+orT6bE0fMdNsZC8QwJzpNj
Ndwh3buVp1T3REzbNsT3zbqvo+ev42zbNum3Tf07+rfPjqnTfNv6/wCcT+r+P6Kej26Ivtm+Jm+P
wufOaKmIyDaM7wzwVSZSR2xwpZD5Wo0OzT8dQGs+XFsIh3UsfsNv3bN0xMeQeoH7sUCnk0zfFi6g
lJxO/wB3YuL6N/R+c0z7XHzGvYquzuPhFp7tsocmO07Lau7btKMUca6b+yxbsXSLFaaU3eNdMXuU
o1dOA3lG1Cz37alNR/698z9mnV7cozuQYcNWzSOTiILNrQRSr9EXaBsFlsDyM+h+0wToSQ7OWSVW
vc6OYm0khOQY8FyTSFQA2WLC4+MskpDNjAtD+aXTMRRCsBd2M+r7hFomObR1ixcIdg1cRrmCr3LM
kEQIGmR9swqMiaiPuTTslvbsWPktZSGVAyEhFU/lDiRPGy/tWDDU1/mFdIFAj3t53VEx0oula7x8
nPRsW8f996++N93aMjbPen7WbAtGGQgY1Xxmy5DY4Ll/ekrHXBx3I/TshvYOzuPR3tJRPqrP7BgQ
ZL6YwMSoF5NmibJesayfAlNKGwqGzylowRY9qxvd8V7sSM5F0jIQA9s2y5OnbjN4R9Xja5p02LTx
1NIrx9qHqwaPFFckWfWy2yo0iGIrYBwxzy46SwRNNgAuowAjMjzfHkP1vuBbVxJtFfDnCWEJxbW5
FXhpI7ZppVlHiq9wZ0Uc9KeWN454eIoASXQ7KynW4a8N5eEsy18nxy0l+yaLxBqW4vBV4qGM2U+b
cRYePcGwiagjNjH02RpKzXchqjpLL6eWstRWgGRgxc1VqhgREI45OqJm2bZtm2JjkzbNt82zb0J0
2zbpxzbovVc+c2xc2xfRtv6F67f0k9O3Xbp8+jbqmbZ+fV8/0d/fo7HLi4fEyssSQi19qKVFlHF5
rLUbY5LZfPbajeGLNE1z7EJUSfHG0dsNj7e1Y9mn7BAJbWzHtqTD70m5GMdjZOkkeuK70b+n8dKc
6Rp8W7C5lnPDxnGaQgZBI76zULCgnWQnOrLeOFJ90Mo7CQhX0dgGOwt+J4raYhlopAwODqAKCtrR
pciFGOZBvQBZZXQytbOcGVE1EAjPrYGZM1Hu+NqQey6gDvI1IPgPUjWkZqCKuH1GJG2dosh1ZLYA
0TUwhMmX6K+LqQTmfqICJY6i7jYl26MUWqBsZY6hU+QZ7BFi6mjAQmqwlYTUCDMHU4FR2qQok3UT
nvh6pHt+qQollqZSsjWLhSXama4U6T5Lqy7dBUWrQbH1aNWTbh5y1+qkjtk6yYRk2xJIfC1IMDLL
UKy2ver8r5fhlh6vjibY6vbKbKOpXO6JlTqYcAbtfR3DnXimPA1kgWu14DaTqZbJ9fTNM1NOixdP
jTDE+m4XWQ0RNZ8crZ62E5E2S7vkgZa3JZq1dz9Oxv8AyCjWWOo1nLV6pLBYmv0RJWrXS8qaryGj
0+JUdp8KZMjNr8PrEgV/XZtv1MVZAdfuEy01W+wxV5Og2DoRA6+KBLDVxbBvcVzq/UR4CSNZnOz6
tISQDXRgIbXskiT7Etg7f3cuI7bIVmSE9NcyeEy1PNfD1TIhjmXB574mp5MNky1NOdD1NJhMm6rl
zWxphI5ZVnInJwXFXbIdgSG79aTUbKsDzCRtRyojJdkaY6NqSVGZNszTnxdRS4Q5llIsHIqpkOyk
Q1kamsCtO4piZtm2I3O3tnb3TjnbxQqmK3bNum2NZvnYdih2zboiYg+SNAuOjOTO3iC3xY7sIxU9
S9d+i+hfSq+pc39e/o39W/T8Zv8A/ByxMX3xcVcXF+JGb4NqqsWIfYgiorYp+28T0cOEdWChyVXw
ZaYkKTt4R+RYZkRkZ5HFhmGjY7iPdCMxCDciuxcXN82zbqvv126DZ3FjUx1QlYcTTDUa4wSvxRva
0bHvcGoM5D1xGZ2lR4Kwj0LUPZhAKxY1cQuLSmaw0N4sBBcZzKN+xa8g8DUEJiUT1Q1SQWDqnlVt
C7D0z24cDmYrETqIavUFE8rTVjo+Bo3Hz9OKmGo3AxILnEFp5XJIp3Ca+OqOh1bz4SjcFoa55nj0
0qtXTm2GpO3gKFTYmmF2PQqJB0ryObpp2xNPqNBUbnuJpxWNmxOw7jkKA+Qv6aVo5kXsubEeTHwH
sRzVascSlfC04p2n0z2hzo/Ze7omKuJnzidBEUb4mrZYsgWVhNbPuJkNJ9yaTior3I1d6O0DCX9Y
xmCubkc1xE3VGrnFVzjg2rvWafWW2zp0h4C/mQ8/WdnjtY2e0jUU6Uj3q5Wrv0RmbeyM9kZviMXO
G+NZ70lC6yy0oPEa4f76qjfPfZU3hY9u2IzfOyq45u2Km2b585tiN3zjnHFHiMXOGV1U+aSXplYQ
jD2Lx91ZnDOGK3EbiszhiMwYVe6k0os1hdIMYO2pnx3PHsvDO3vjA+9Lp8lgQ+jBjBZxvGl0OlyW
C2WkWR4sxnCRtjW74KMr8pdNvmvZowDG3emFjYWOrXcMRuaX02yzxNHRNv0dETLrSgwBodI+Yr9G
RkHqDTxIb3psq+vbqn9BMVM/GL/SX+sn9Pb0/j8YubYqY/D/ACvzTQfLJDqGBBOjjbKj1rHR5NHz
k/SmMDDiDUxa0TWMhhcga4ZSyaNjxwaLia1qmjFAE1s76cMo7ep7eGHxc7F6/jPjp+cTPzTM7tpF
rgtZcqMTbF6EIECmdWUP2rCsYJmna1JCirxCbZRWbAgIWxiVY2Mnxh8bCInk1NSxojxRoy4jtRKC
qRWeCFrCwWFMKvEEaOC4smsa5rABj55kfk+I0oreJ+5tS9+PpyNR8NzVpKRXuj14QisYDFkxYIgi
74VOeA0rI9G1pOEcKSoDTDl1PGTT1owitYzFi0YGvK9WgHMuQteOUyYaJGGILpwnSCw2EY3sxHPv
Qo4Y2yBjGJkowkIO6q3dzxPvadrGMaRjXjvm8ZFRDEo5tSjmWFconRJCQT6etQy8mMR0e9T77unv
nzi4mb5vm+Qmq91CnAGpvfAQnyXB02Xi7Tj0SRVKN0XTSmQmmFG19cqFZQPc1mmnuyXQqFGAVC0L
eEfVSquQq58nB6WIqH00rGzoTgKvt0hRlkOXTRGCSuVZH6ZejGabVyM0qR2StMOAwsbtF0mN8cGq
nLxrK50otPAbBi31ckyPLr+0SDpMshn6NcmWWn1j4ZnB22NT3rqUs5RaMJtI0i4bR6eeUi6Weufp
F3F1E/vUFSleOxiLJBY1Khlg0s9zBaMIRJulnAyNpYpstqjw8rdLllDtaZYOVNW+xyRpUkYWnKxJ
E7ZsYMG6SXLta5ksJ9Kuw1ITvD0gRAQNPukSoUJkCPI4oyQxjtQV7QsjWmywrJd7FrOWVFO+aUWl
mBBDhshilX7gWJQMlCmaTU8i008sXK/RxZAo8x2ln2evXymaPlSpQJY0MNrGxY8DUBJdjbQRzIlu
Ps2Lne3Xbptm2bdN/Rvnz6Ns3xfQvRPVv/T29f4/qJ032zfCe6HXPldDR2vDafZDNlKsjTk/yQNi
DTLcqADSSHFsTDUgpCuiOoZ3kkzZMuE/i2C9uRpSS6ZEvY6IyY37jvlcVMTF9f5pF/7US7xtQPVM
27pKOlTY72RR29osh+kwcRWLOIrSwVmUDe9KcL7FpNWPkV6zZkEX8a1MsdZE1ZJ6AewLXcTYlnvN
T7wRQeMuYu0edIK41ZWKqy5yRAwo/nvWAEDDCErfp7DGhxGhZk5v8lqcxNgNbLX2TLMb3Gjt+1ek
8V+n7Pyh2n+nTGRhilGUZasZlDVeNIGn2vAYkgq8RWDyGkwIDMC1GC5L9RyZEadtrXrGfQW71kKv
29Qf5a21fBJWzWThW9Wjh2gEC7Ri/uk/697/AJ39E6fObZtm3SoOMcin4Pi6qEjU01VsRkiQGGwJ
RTWW1eiEr46ME5jXpaxxw5tcIbwOIIb5kJkgJ+3CsqxWviatGiJpevYKLNshV7FuIksWoCsfj/lq
Zo0DSSpA0IGLUI2we1OEIjCtcRBtI1hx3zmRpWm5DJMXULEWHU3A4BoMpsqPb2TIEen2ubJE4Jlu
Jj4VsrfKTIo+RNPwmRoObb4YrI9mvtkeYkl1sNoR0dqlmKdN8UE+982ZSyPIgmO0Df2lGFGsHrJq
c6RvCs1dG8l9DTMrWFGhhwa5IVqX3HFAMc+QvGPVXKTCeIHuX1slZGoEYSDm26apjpDl6GOQpLL/
AEbBn/YU1O+cSsqxVgLLULVmM/sOELzM+Prfh2zwDkZNlMrYd1eEu5enNOOlkGMNZGiX/wBVuDf4
4wgMNK/1bt29svX46b4i/wDzb+vfrv6t/Qv9Xbonvm3tm2Ox/wAHxuaBcnZuU3BNZsbSscmJ8agC
pQ0KKOxIXtis5ffdpoKifYSVjNrbRJmXC/xrFdz6PTjHvnftnf5n/K/0PjomU3tZx/8AV1E32hcW
Sq4zOzajcVk0DhO0jL74bQ2wbd/MmmJa99xv41+XkStlLHlwSfx9SH3xTuCbTp+5HvJH26j79i13
Zjts3PmlZzAyq3PKMkMU45JLtPM2BeqqMSZKZkS1UKi1IF2RjocctyKTfgH6gRbBn7mfGWJ93xXb
h1MVHZpFP22abxZClCf6hPa2hnHkKrUz8PsDLYp+4VoB3eFOlgLAepI5ERJ7/YcIjnpqFiePQMX6
jt9vUAl7saC45dP1Phtu7QYw2EnyCaQGqLJ/wXv+cnz02xG7Zxzjm2I3IzeJ9PJ/A1U3cWnl/h6l
argaeZxgq1HKR/aYN/cZqpvIlP8A6MsaumvXZl27nNoU41mrGch0G307VQVOCPVSiZZQDBxzfdG5
ov8AbMX52Td/+Om/svnObCdqyQFsiW6aTRyfwtQN5QHIqSNP/wDmX8F08ena50CUR3Bp7+c6RaGs
SClsVD8Mjboap/8ANurI8BGWNtJFFUy2ZPimdvI1Au1dopftWYHSYh9PPiZp5vCt1QrmxAaklplW
7lX6rjuMSsYo4GtZCxm6W1E+QtlZihxaC9dOtDpzDWQztm2shseFpmC901CbM1fXOltHfzKtundR
T7KQ5eCakeU1joiO4brBvOGOkNMtqusHWg1ZqtI7aI+1hHK0oZFdLLY82gGsV1reR17KaghrNgSo
LoknTLEbA19LJHgaJlMjyjfdDWVcsdhayWRoNgVDz1679Nuu/p29O/pTrtnv6Nuvx1TouJ02/qfP
9DbE9sRd8TEXHOxy74dM3zSdi2I9x2zA2sDY9MJsWPJv0jFLISUGHFQc2SiPjhrUcSIJsc1wZHD0
8ZUnW5kUCh8mwrmJDFe2jdpBOSv98VcX56Lie+L6EyqdxsopGuDcQ+9liFAEp7tYjxGbLZbQEe3T
Efxm2fFR3DEa/S4k7qq3xb0W7qoHdlV7mpHvmI7FZ3JWnthCuuLkhkSHZskoQIoKJIkzGBYCQx7J
kZJD/pQmjiyRhWUjZOJVha267Y0gj7sqnc1oJpmodstrxjiM78ueyOMF+hiD7Zln2Y4YCSvqMmhj
sjJK4qF4A9wcEZEhxQxll3A46isWnY0Au9KsAgGJ4parAEqrKDFCy0Q1gw4yD7wANu7Jp30MRoTb
ptetEuU0QQ1srtkcVpZulkrxJIk6fijiJYzxCjXJ+6d/yuBCpMFSlen0QmJRkz6ITPoRMWjKjYVa
rZFU5rIuoZA+zR2w0wislJ5IYQl1QPy0mjKNliBuXsxhsqf9Fdky5uhR44C/ULSuKNsbUckbgaev
GY7tykJIixBXUhswjKMr8/TxsqoRaw4LUDxpaxVy1vQiFUGGke7kDSHZqneh/uJRFCKJczAtiTyo
knTF+1jFs47WWOqACmw7YEoW8QS6gv4/AdMeY5NMG3bp0w301ksVnkRTJKtosIP1thraTex0jafu
QsPqe6AsfTV8sAjbiI5tzqKK7K6xiePqCwimhmL/ACdMahbwbKjG6a/kJsGUSOpbGQfIkl8Z+n9T
NeORfQwjstQrZWES5gxob9bEWxNqCHJiWpGFk6RsosVHXcEaTbCI+1iW1aMa3cDJN5BjTdQa05gV
znuCVWrp3VDoTv1JX8NS6uWVmnLmHEh32uPuVurwSI2qrGPJk6b1TGBE1pfhs3AO4C6Z1e0LTaur
Rj1Nqc10bbZP6Hxi9U6r/U32xF9Cdds3/pbdF+U9KYnq3z49Cp7b4/Dri/IXq1abUnjsn3TZGA1K
1BTrBZRI+pmiEDUw0VNXCdn6sDi6k3fM1B3WwrHxDy9Rd5kWw7By6k7jJUt5nOXFxcX536LiLi+h
MEqjLD1fwSTqhDsln8h2Vt8WBknUHl5F1QoENqrvMlSO/ldcugN/WHJkuwdKWJYOgEHrB20u6dLT
vOYaPqt4ck6hJKQhFeSLqA0dP1O9cNdkModSGEn6sIuO1U9yfWStI3VxGYTVLzJKmuPkaS6OUOqD
sSRellYC+kAz9TSVSRbGPjTPaUV9KYkqwPIwMssYg9SymtTVMlUNbGO4N7NCjr+a5JUw0jI1tMBn
1+ftJspUjI8qVFVt7OyRaTD405gl/Uk0WE1JLLj5pXvDfThIuoLJMk3Ek6Mt5YcLOLKxVwLnsdHt
7FjTWM46FVVVV9802wJVC2MjU8Tb+JnOGmc4i4d0VG3cpqP+tTRqS3lmxpyMI2+njQlzMK1XO5ht
Jjc781chEkSpVdskTUcvthnySkc0rmK20mMR9jJIoyvG76pNRX2EsiacPHbgZ8BE+pwMsLGEop89
7iNbKdhUMjmypLc5Sj48atXfbElSExZZ3puqq0jmK6Ydyc1xsg+yyZOQ38TwL2vYP9R1mF1JWcbu
2jneiyn4RpeKOVuOeR6I5yZ+5y753jYrt17xNuT3YP8AupKaKUIKqMFba3HXhtLEtjIzbE3xOWBh
GPj4b46IB5XfS5DhmivEiZu7ZHPXBNXcUApcLWSGI8aiXjnHfGtyPDefPoh3Y6sMJHDVVDVEVJVa
UeO3THrvn9ucs7i4uImL6d/6SerfNv6add+q4n/xJ/SVMdh8+VAnJ1fSuMkqq7Cx6VSilV7gPjUf
dGyk/e3Tv7U097u0/wDcNQ8WCrHOMei4sZDVZP0JeEqC8Sub7u9sXpt6d+qLgk5vrtP9xkmg7TZs
fsu2wENxsfXPGkWIpjxtPbpMo1GhIytNB0/3ENp7g2dB7K1tKshF05xHPq+xkCuWQ4Gnf2y6ThkO
gV6fQGpkqh2yNRq5zdPt2Pp9u1hX9hXDzguccjRHSH12mO4yfSdnIOne4n6dRuSqJNmUyuNH01+y
dQ8UPBVjqigdJSXpxACh1fkSA6ZYjH0o2ZKrxpkLTvdxaJjcPRZF04jsdQjHn0EbkuqtAYQTuXaV
MBF7jqnTSvZPqBRmT2N7kOpdJyVRqJpo6idAB5EirpWK2Xp8aBtonZM75xquRaZh5pfovbi2ilER
HyFz+SuOWQmcXvzx1x0dUxA52d87OKxcooPlSJFIIUWUT6fJTVU0WSbidNQwX472xfhEwYnOzs7Y
0SuzxnKnjPbnYc9XhVMrY/elRqITYl8FojVte6UcemmAhXEPsE7O+JEdixnNwg+OL8JiJvgwuXFh
P3cBzM8XfEhKuLCcmRIjiEq9NDHG1HX+K5QriAdskZy547kzxXZ2ffxX7cOONC5yINW5puslSFEJ
Bst6dssdlVLGe6MqY0XJfFc3KenfPJX0oYgNV1w2s03pxqDlthRxagKAhMRFyLCLJyr04Qx4dVHh
Cl1QJbLyjWO/xXZ2ferrvINU0wYIHyoAyzaoEodfpXlOHEjgZa0YpYryrdAKvRF6b4nq26p0T0fj
ovp/H9LfPnF/+hPVvn5z5x2SOmnoflyY9e2HGupQ1dTuGUMul8hw4TY0YUkfnK1jQDls7gHDNJdG
G5raZrZM+K1seQZsWxrnsmMuqr9soXB702xcVM2zbrvm2/ogr/NgNagL2ejGzSd50GE6QSsqGiFb
oMLNMRfILxSMywMNzWCYe0jR0CGbJYrbN7SEpoiICVJa1LYzFbpmI1RFIgGuKwshiIIKzSOmEC1Q
mnsiO+tGklGjXAtANkvFp9XYTTq4eoUb6OjRuMajG2Y0UwG9sL5ZlmdpHjHBGx0ub4rkYkkdjXtY
ep7bQzv9Wm/bLM5WjmzpvciGkGlRk4xznk+an9s++SErtUyJMiA9xI2oNjGjaf7qSdN8G1NQiSUY
gh2/lmfLgFYtHPDxfHZIFb0+2OY+MTSdnIOU3+HUCfeX2zbG5paG5CmE/wAOzjufNqtLKVq6ZYzJ
unUa2JT8zA0yxW2enVEyupO5jdKo7HaYajbeoWNmnYKoSWFzok+MpJlXpVFGumxJlrQo1kuPweuD
bu6h00kkVzReLlHprvsJppGvTTDXZ+mgIl1RdjKCv5ymDXs3cVzpun6xkfNvbUsEaNpKDz3M07FY
h9OBcy8qViPf8omVdes01fpUMcX0CLllptqZF06JQi00BqTNNDcyophMexnNt/CYYFVUillbpkGL
p+JxJphFkztNhFFqapJVpP06AcZa9Sz67TIGxbul8Y1SJA1966RyhK50SbVimSJ+mG8KrSQxpZ0b
EkVlayuE1ytS8B3isbwZe0Ei1LL0m+G2RGUJK2rJMJU0QYAIqCR9z3ViaeQrYtnGFISRpkLw1+kU
78urj16Dej2H028tj8NGu7dTCkndXcvE/wCQ0Rmf/wAVxU9C/wBLfpv/AFN/Tv6fj/7NuiL0T2xe
jsPn50Gm8ud/p2Sr5elpfEjFRWWz+3Fryq+4GnINoJBLTSnPseSIjXtfk/8A1LpNj6NJvl01O3Zp
98mb4vXfovVM/MT9syB/r6j9mNTmSiqmtDPkpGHYzXldpViI2aiLHuZaiXTjkKcW3ZvZHZdBJ35t
Xt4+oHIPCyVJI09xaO1VEjjludYw15gVBNPJXkGdDeaRWVbY7bS0bHbSD8nJZ2QxtuAnQDxnMBzG
sRd0nM5ZHT7ZHCYbfk1MtBouRP8AFqZ3HNLSiPSw/wBaLMbGlsuhEYJ4ZSuq03E3gMhxNK9eQrsS
vkafo8nTWQAxSlspkUPaYqckCNB2C+2d0Eh9lVscGcLxpGnJxJSWUVnZuEahtGruUn+HUHsZ+b9N
IzXd1fdqsQtuNOAlvDLPcxCMjVqtN8ZJYj49TJd55P2sgSVks1OJqxtLzH+SX+wDELcL+xthqo8O
bN1QOQKcXuk294/s/T3/AJk6GkrIgOwGyMonJjrYY5F/ZgdHpZpEsm+6atcrJWl7eSaYvtl9PkFk
0IkFW7omOkCYmrbMRVX5T50QNqzFxTDblpZAHFojeRDtZD46D90spZI1qz3brGbJ7ulCkbMd7YO+
H5QrEMk83/T03/7Uv3i03jeSxWplk4LI0JUWHZSxx8huR0XU8t8U9cV0uPNcsMcC63u0tIbsCRir
PcNET3w2qe1YOYhmWNW6RaU9OyuDqnU7IA9IucSDYyWxmVclshuqCqGBpac+XAezt5YTSz7sQ0GM
2qHMs/7mtbxS0sRwjwSd6N/yM9OKfGLiZt/S+enz0XEzbFzbPx6tsRP6u3X8f0Pn1L6NvR8Zv7L0
X2RckZ+dFF7c2Q7nGtozmyNL137mPa1lgxDRwxezc8toswxDmq4bgzrBdo1VaO82c/eFcfuPpSOo
W3B0UVj7mJi9F/oNyMv8qtXeLqASua7lHNS3DTjki8hlnAUeaN5I+x3SPc797T/NLMSr4moVXkPl
36ffx9Q77SN+ek1d2LvfhAdxtmL/AB3oRZ7E/jCgtV1oRRNfXFkuoo3jMu2qRn0d5HOAavxmpzsd
TSnSgTiKhEf9k4SOsBftD5LMnI86xk7QNRSkK/S0dyLMbyjy61Xn+grxoYBAG32zfDxnksR/sDPI
19lARGxtVyXK7S3FByCqzGLu1P8Adle4KmC4UqcRGRGw1sJsOGKtBqC/44UyyC6SgPYY3+HULvvu
xflM0gJXSvw5natxvR4m1zlsf7Ua9H59zyDf4a0fC1em6Q4/jt1SdrY+kROfNd75w8e65oQczT75
siVpocYFgHgXtLgxrvpwqLA6Wj+5K+F1a0gjlOZ66bjqWaicc1jG+7pcqDn8kI2VRiVKxzfFuoRp
o4+mFQd9CbHf2+WIFc0gTsyy/vG7TJTns6QcUGmV/gX7+OB/x3J2/WIpULHl045eQa7ha/Oamjqy
boySjJR290NXTLBmS/8AUsjuZa12sYwIl1e/U5OnLoR40ytZNe4g4IHb6gsW8IQOTJwtR1vjOgid
JkVMdYtfeM9hPQg3aec6weRAsrxD31XqltePuvOTSV6yMkuIOwFGiCrxW9i24lVcEddBFPFMdaVy
RJYSIUTtNOdYlegQ1WowypM2qHOeQgqyNqq8S6l/HRem/wDRX175v1XPdM9+nx6vn0fHo+Onz139
C9U6/HVf6e3VVxVw+fGVc5YJqm4ZNDdDYo6YgwBuLpQZAs0PG/YsjyG9hgh81ksGefYtUMGSjbeX
YNWLIf5FlFIKNHurvlhzK/HLi+vbouJgncD1Ng1Y9jwIy3UfIUp8V1FesnCszC40LmCSZPG8F2Vj
l07x5jsGIC9kjflXxdMrpwwjupg3I53KXSnYBlpYiIw8tBTK61aYKEEjpl6xjYNyxzSTAlX6hGYN
btjDNnsM108AGXNowixXM8ursQxg2VwzIN0wrUng3sL9rRgv3MkxrgXG01EnCPN8mXWzgxkJcAcy
ZbMCSLaRnNbaAGlpqXbIGoWEYlqBuWWo0Qf1DnPHqEbY1vP8p9Jb+G5t8FzE1MNcl6hQZIuogEb9
djiS71J5Dam3ABttqbk2TKdIfAIwciruoQGWWpx9qxld8yr0T2XTtzGhJ+rYrh2l61ZVXqwPD9UQ
Uy01gjkqdWphdUxkx2rY5GUknyrFcs9RBhZcXT5hKK8jwmv1pB7dlfdyRW6wCMS6yhJlnqzzEg0a
zcTSTM/SjMaVaZSa6YPCf8gB7cTVrFkJruHwvL1s93zlJbBrl/XcVg7rUTbFY0h8Z9drYccNnrpk
htXqokYrNfRUSXrsbxwY5b4w9JMciaRYiFomwMZq1kDHa/jJlxqklhlPqn6YGx1Qs4ya47ceZYOl
mqtY/Tkl/wDITCsr9WrEO7/kcG1tdpaErVMwsG2mjHEO8472cyHBmH8iQv7sbkOwfFfH/wCQfHHb
aqkWuU2ovpLbbVUmxSq1QWuHb6lW0yDJ8Qof+QkAy01w6wbXa0LCb/8Aou6WetJFijdSHBEO90oq
s2wRlC6Brc0EVnrmTPZVWr6w03WMiYGvtpFY+brQ80NZrCRWov8AyQZuWes5NmyId0UotfyIwrnU
su7RGccVu+dtccm2bf1tvSnTf+gqZ8epOq+jfPz1/H/x/HResj3x2M+YUiQHCTZBEDNmMQ8kh8FO
kjaOwltc20nZ9TnLj50xznypao172kdKlqzuvR6yZbmmVyufjk916/HX8+hMikl7OPP2Or1xUwbn
szyZDkHJOzGHnEQsc233BOGWY/CAkvxWPEozylztSyIUL24wp8YyYTCxn7BjFxsaYiFjyMah0xke
YuPjTEwoyNxxzJnkmxXOXERVUMc78fGOzGwyExlZKw1cfFjKiirjkwleViOEqKKOZ6/Tj8fFe5Q0
pVz6OXCVRG4yse97aMuFpyMxsB7lHQvXHUpGY6vdyDSFej9POx1Q9HD08VyJp4uEoSDwsNUc6Mrc
Vipg2csi0D5CO00VjZMVQq9OvsubImfGe2bJibJm2+IJN+CZpeUCM1s1hmXte56yR8F48s7Kb8ds
4ZwTAu7ZIus/Hb/+hNTF/wCREyy1I6wx+3JU6VtKs3G6PejJdU6OSFpwkln6S2ybQOAw7FYq7YmN
ZyyDSEm5KqlirREkMwTrHg89i3LW9mtSNCfbnZop7m2VMsHIdc6W4WjXok3TTgtkhUBOiZxxqZRy
hQzQ9QwcNM2j6jsDyzq3OPsiZxzhviMwQFdlbpSRKHO0m6OyVDUDuObY1uNYqrV6cLY5O0w+EkDS
ZpjV0Q7HaHIiXFUsBd8buuNEq5U6aPPw+jyiFOrnxXqme+IzfIVe6S8WiCdm4onV2AjOI+t0YWWO
w0cSMyZEdHIvpT07etP6af19sT59C/8Awr8/jEzb3VMcmSUxcjCUhKaj5sn1bQjqKlDCtaftpV0n
MK1KNeKhaovozdy0re6unOQ3UatmkoUbHkw+M6PVMeG0plGhRcVeno2zbPjpv6Gp+6lo2ujzqwIW
WjGI7bK2qdKwtD22Q6/vTIdC1Gz6pjUmQ+Mipo0UcqpY0drCRmUdKhW/RhsFaVrUyorPJMGjY1ku
rYroVE1EfCExx6pr2BqBo/xQBb9OYZt1XdrHRHKroBMdGc3K2sfILW0IhBtqtrMraRiDfGCx5qtC
MbQqskFSILJdawjbCq4PoqJFbLrA9iBDaSaKEELJJYwnHIMz62pG0ZkAxz61hmgpBDeYceO1sQUh
raQfdUAI42NDJxaoPLnEjtBKjSSzIw3AZWtKWZSN4T4DhOh8QmopMU+HjDcG/YjCPT1J0a3BRXlx
tIdcJTEYisUBNLvEZtuFroU4fKQGnKfP08VEPWPDgK4hl+gF2PXOAoakpsSkMriUZWNKFw8X52wf
zpGSMr3Ls3i2bbsG2OMd0A8yZFYcF0LtSHfKJlBRPnliQRQxWlSyWyqGlfLwMlpnaihjdF01OaCb
8rqU3kTKKnHXxLO+BVr5seeDUCtYbpCrSS8/T5kz9NHyVXuj5QRucohUSFc/yZw6GQrGadkEyRRl
Ax4VY+LUmk5IqCRk0tRtk4c44IAHFYBv6DdS0JmNZVFI99EaOyj0++aeDDZHbqBqLApr6K2DK10M
ciGfyo//ACCu2IzfKmjfNyHpVGmEMUCPAuAWTr6kbKC7ThkV9aRCg02fbT9IOIK8vPpDLi2lXGaU
oWEybMFWRoU0VrH1fRMAxyepeqf0Ns2/r7+tMXr+cX+nt/RXp+N/ZF91xckIuy5pwHkTwxGx4t9Y
OV2m7JFXwWSm+OyMGXPX6jGfyiyHlEUVhzlN/tdGY58lv8e8+3I07Y+S+yiIsezFwMT2x3XfFX0p
0Y77lJ/qahM5jZBVc6rrHSiQYTIQrq0YiaZHyklFwDPsOKBf5dhCDtGsZzgrMl+WSiDsCwM6PllY
7rpaP+yYqiY+x/mBL3QGikdK27YLazcN0Jp5rxOSFHOv1AwaBrWGrAokiqR76ipaBqZZt3yMu4TV
73yWpxYiJlu4jWw0VQ3jWhdS2ozpJX+PWrxnPXkKXS954ajxZEX/AAHruclP2tR2+T4flJGD2Auk
Na6ZxkjrIiRh2j1HDmTpJj6WrCCJbzGxowr1Y02JKZLZa1PNs+OoC6RT+W//ABX6fdfi/PXfEzbA
j7r9N0Y2R3hjDyWED2Xg2Mfolfa0/wBGtrvPsgwgx2KAa5dVg+xSQGbeKLa9q2MHSRgmE2MFmHhD
O3UUZoDOzfBr76K/3jf4qj/3C/46v/3if26gXaQq5HbyfpuO2PWTmGIMCOaG0EiWK/OzA5qm9E0O
n1VbFuTve7ZmrV5ShW8mMyQZ53KmMzSBhIvjibgiiMupasaA0lIEM7xoo7NWR7WuUUmGQwImSIg5
Y5NK6RPpaxIMe4rEli09H8aNYxUmiqYqRBWMhsZjWR7CNFqI8cl5LArocRkMOWsdTwpcdRH03p1T
uKYVdH1LbpbzaOifNLBgirAQ7ZthYy2dyNU1TIEma7hFrZwLESUkXyLewFXx4LucOVBjSsk6djFH
TxFhjuYjZoqiI2GPWvtVdF9s36b/ANHbNui/0dv6q5v1T1bddvTvm/8AQTonVccvubF+dJu2uHf6
N63aRS9xsqBv4s/fxS8ktYK7RrSQzaJutt3O3Gj2bDEN/g1D/m0p/vT/APUuv9gny/NvV8+hE/dQ
u3h6ib+1/uSjCNgLIruFkj1JpWS1SGKnjXpd30cpAyob0WPqQ2R5CRZNIVCRtQnRopRfuaWmNKKz
Kg45H+RZ1ze3Hl2o2SP80eVWLIkCjMgBuLVSLppvMduVwRfXjALCtmmMK1GjI5kMyXtwA3gOZcIK
UF3dHlmVrR17+YNTbbaZd96X/rSZbocsepiIlXdJLMsdrka3iku27coTu4NG7Za2HgsgSfKDfvWO
5NUPFlDZLYCvHbQaevSXKK5sKPe27jEGjiv0xWmblnIEGPbSWlNpJF8pf8eoV+8/PnNs44iZxXEb
m2Vyfyaz/S1bz5CmzkZM7z10SuWn+jpf/ae9BtJqWKx57BbBAR2xxjOwuX3vX6S37VqVQwk1eMLL
iz896pm2Jmik/lm/xVSbXZf8de1Uuyf2agX+Ttkb+6i/8uxtQ1bIcps2Pa/7n51LbTBnIchnadT+
e32ywTjcjX9uqYb3yIWmXnZaQvEXbGtzSibTyfFK1UJqVf8Ar9N7rPdmomq2x05/5l5/lH8WNqlV
b1FolkC6u2VbNNzfOjW5HjDSqR0bVRESJpUZWVxntXLjux7AP/IfBtFdfWRW8tY0GA9bC4igaAOu
bspJNDRumEiQw1cfV2rle7/j8qI+dv41GWSaXcmQNdpARll82ePqsJC2Nd/o6tef6lW7+A1yK/UD
isj0PdUGvzIOr/C9Ns3/AKW/q3zbEXF9C9E9fz/ST07dduu3T8enfPjEX3z84uOw+OzT5UBZRpaH
jXcPkumoe+PmsiMbMHKFOh7zYqfw5UZ5Tigdo8hU8PvqO2Uu8O/XeRp+H2H2cxrAWhkKd7sXr84q
e3pbiLstC/8AiXcdSNnR1FlVdLFeI7JQrWvR6aajqOZIT+LeC/fVB7s+H/q6gFyxre7I0+3YF+Pd
ktmz9KB7YrdvITm+PaRJDXRjwlLJGqBjR3DflqJx0Fp9XNhjZDdP2kNZQdxbSCyGxXkcfTbVbHsX
e8eS1Rmr+9J5tjAbdMc9wkmLzHBFcWHmSNNV/Fxm8hSqxrzsqmKldUIA0iUyMgprCISv78lXtjiD
ZCMthGSdkUSRQ3s1JR4FE0uRRBrQ6ku0e3SZ07d7KZ405/3dNViGJImArQXd4p3haso2mKxAvkFQ
Ib4yOO52b4xquwcMj8Svfn09+fTirn00uRoRQnp5iePLhjmvdAiRw3pGd7R4UCCdskWrmMiT1KyS
EVPFa6caNGLHnDkCC8IVtCjJHoQIEFqrfDtWsUggueqVZlz6WVM8B7M0bFQKk9mFljiXAJjJIhwB
BPb2ookaV3LGT9JNgqwzH0ZUbA1hPG7NOSWfSykYed8ZqtGKbfdNHxUcXffNUEQMnT2pEkjfFjyH
TpoYEazK60lpVGVEqTZp6E8M53zswKatvROHo0DO5vmrGsbI0tNY+tv7AfmNmiSPqKUhpcPUMmvb
Mu5FllHfEgPiTgTwzbOPXCi2f160NOj10Ss1YGebUwwFAzi6TptgRwbVGOhRSsj3DJwPH1JJSVZa
TsY4IWrNXKVU+ay0fXlpL8VkEsmPEDa6m+rWUMsWvgt1wF1lYviy4lDfxyNNEiSXSJ8auA/WLiXN
faRrQFndxamPfXxr0+/T5/o7YuJm/p29C5t1X29P59SdV67+pVzfpvm+b4q/0tum+KvWR8Lg3K11
Df8AZybagMKotxR0uLhDspbloBOtwmIC9A0aXMZFlXwkca+Y4RJ+8/8AUI+zMmIeaC9AANpbukKU
m6qirm3VfTv1/NPqYEcR9SRTMs53kq9cqLt0J8rUAZDa+8DGxdVAeOzsvLysmjhkFq4HbtLpJGRz
tFJi6rBGZP1IyUhz8iV+pAxGyNVhkMmTO+Sv1EkVE1VFdkrUaFbD1Q2On6ujLi6xEjTajVSi1gFi
F1eDjPuXS8BJ7Z4ur2R2StUtlJE1P2MTVosl6l7+eeRpgasUbZuonyWilOGaPq1sfF1u16StRd9Y
+rHCxdY8smXhZWQ9RFhJ+sUyTqR8hIlweK9ur1TJOqXEaliRDD1crGydSkk4YjzZAtiQMl3RpeHR
XZCvywhTLk0vF3yOVQEj6tOJsrVMmQw5nGcqZtlDCSaWPUha1KuPn0uPn0oGfSo+ErQMSxnOrs/X
ExmStUypaKVxCRtUTYiF1jOO184rig1bNjtfrWeRJViacsXUEuGhNTTzudfTXIPU9iN0jUdiZHEc
V+nK8ThjgR254sfa5CIQXXcmA92rrMiHmGkLF1FOiNXWNo5G2JrA9PDA0HiRsdGjbXc7xEkTiynB
t5kdrb2exztR2KoaWWT0BPPFz9SWCIeWeUoSlErLezVppEuSunxxWRUSBn8DBCjuP+dTHlDkmeQi
inSI2Ou7B2OKU6hmSAI50o7nzZiNfuucc292YOdKFhCSpOI40fHFkysRhY+GlSiZuqL9UksR1hLJ
ndVuPsJStTPIKxuKuI7bGSyhwk+SVGkVuPmyHtR646dJcgjkEv1KYmFmSCo122ecZiEMU2b9F9/6
O/Vf6C/0tv6e3oROiJ6Px6k6J0TrtiLidF+HdDfDvluQ4jpKuqHhaCuU+SK5QNDXvkYlQRqtonvx
KIiYSnexFpycXwyI9tK7gaK4bm1LnpIhPEjmqnRf6KZ+cg1D5TV04rWSYax8VMGPuYkNW52VV8Wi
cdhKDssPHUboVQ6RjtPuayZBdHWNBcfGadVzJdSocDEV5AUDipIo1FkancXG6b3w1ArMbUuc8WnN
2v05k2uWPj2fu7e+cFTGMV7q+idISTRKBsSkcfGab2aXT/DCVbkJE084jZOnu22REcJ0KsfKc7TP
BiV2542mObP00jcJpvi0en1I9umEahdP8cjadcV36WRqJphHZaUvjICIpiQtLPeO0qfFWtoHS8dp
ftssahQ4KucRxqgokKJUwAub6zT7CDPpdGBs4XZe5vQJyR1HfWDU+u2WJfWKrFsrKU9sGe0EudYC
eWScy9vfFHiDzgu/bXHN6fj+7K+A6SR2mFjxCxNj02nmEZc0DAAkB4E75hO0/Dl2L7apJEDLKXuK
3fOGcM4dG+2NkSUxJElcU0rPuuXtqudrO1nazhitzbGs3xA7uoNNunO/TsVEudO9lDgMJ+5c5F3p
ZU1hIbZHZsqVsxlrWujPXEbg4j35QaaWQv6fibXmnuwkiMrX9rbEHurRrvTUT7AgtNRBiuqztyqP
S42BkafjPFeUboxCNVFXN839W3uub7epV9vnE9G+fHqXp89F9G3o36b9dsXr+XZv69un4/8Ag+On
49f46/jFw+E9ljM7hKKjRB2QxBDp5gSJZVaFFT0/aHMGERIUMThkaBhCgE9WVwlZOofutqmoC5Cg
jVfaIO0qUe2fGUJHpi+lOnz6N80xGG6FZvFHFZykK7tqRaSkUizKoUYUKK2VZxIQgimNE5toJqnp
61rAyEFxu2DVmnK5qsc0TG2rGZRQWmkNAKOyU0RHw4I2MmTRCI2M2QJ7BRnnvQsyEjZY7uO1MSne
VfoLkw9Y4a1NJ33w4jIYrkSOHXRWjFOs+0dgmmElSxTFKOENGtlttaxEdQQxiYdOYmmbGsf1MCOO
v1K2wmE/sLajhL+o3STBYhBHshQcmatRrquT5cbUY0elJSILpbxPImxY7YgWWDDFnwGkFCaBpDwW
GFa1HBVR0YunL0siQv7mahT7z/nI4e66u0wQzV0qm0yg7OaepERSMR476q7WQqR857NIcUPphEaO
gc5/6Y3z9L7NsqdY2Pbtm/vCj98mnKdgcKzusva9Iz9JSHHBPB5MeXptcmQHAfpaM4ItSo5Y44jp
MyHo37T9JNRLWk8XCt2xfkTFetHpZ81P0exMnaXQLYGnEOqaR3eTSbUZG0wpT2emkiNg6U7wLmsS
E+LCdJKPRqJGSq7U+KBsePItiinPG0zDafSQSw088C1+kNw01WyI+wkuix6maSaLU0Njozm8n0NC
+cT6EAYhjaJrrYyWJRNK0ul0kun6aeMkTRydlune5NhQRwQq9FjsiNPdyCdoNPYHkybuMw0Cw/bL
Vf6y5vm+b5v0X+gv9fb0L/Q/G2Ln4/8Am2/ob9V9s23xcPj/AO6p2WfDYg4uoSuQtJNdHl17mnC9
EYO4lK6XVe4J0XjhZ6slxncgYvxqRPuaeO5lkViOiXzfvOxUxU6L6PxidNt00r/oag/sL7uoqlTY
jWQgXNspHaYHyP20WPcSVjZDIsuXXtRI12/xnFlOlH08PjHuf2jsLBVfpcSIk1u4Js9RHrDd8EiE
1SNVGAulIr6emc98iWOuBDctodYwYovLjFwohmLAijCJF3yxHzFC/wAR4wlemyMb8WoO6KuajQ6i
dwbp+zMSQZf49z/lix1kP09T9hLm2bHE2R502sjCZjV/ZqFquJTUyyyorK2LHkNsJfs3oQe8hybo
GO0ckv8AiuDuDKorby0n1zSCuQtYXS3+4nsLUf8Anevv85p7trJhnH2SS/eysGDSjvhyjOXi26tk
lyaKMgIlpbpXLEMkuOXiKb/akWUkrNSxm+PJ/v2yvnOgG0zefUHFf2h39ysgmi/9cxUCMb+43Vgk
AbSsxZQrv/z6Qghz2FQrHTCDzUdmMjTuVzsqR85cIKAiXGpHVh36pEcGnLDypBydoMOR5QOPvdf6
kP8A1dYpufT1UxrcsojEOnxKUKOT3x1ysWy7feyxmeDG07MfNHK48a3htqT2r6KjJOKAAa2NJ1B5
dm7CuD3fyG5UNog+6t1ZJWw9MTGymbZ//SaxrbGTsgYDxulWn/n2P+3tnz029Px1Xpv/AEFxMXpt
/R39Sr6kxcVfQubehfWqdF/pKnpX1behvtm++b473w2P+axeM6ERHxdSCXnWRlkS6kfZjnbyDcRl
ZIqF/jWk/i1RKaSDdsN1uoJrCoQWpXfuohr573IkC+9ylXN8X0/PRvx10iv8C/Tdpm8X6fsg9uWx
ZDbOA5q6cM9k5CKkO/IqkhneGXVPVY2oyKuEIrSaYO58e/I7tyv7tIHeRlm9WxpKq6wrmowFtKO0
0JeYC1qHPIVsEEwh5z9ORHR0t/eOUB2nCSVGe3VrA5TWbbBliTgGNt2raQZJUJVUHJMsyqrapHdr
UZ0zTjHeaVP41yFe5peK0iy3eNFtJLjSI9SQqBiygmhIqR71WrOqAtFH1TMcxYd0SAoNZEeSIVTR
5Ujty1MijjDK+ZMOgI8tizptHStiDvLxkYc6YsoulY7/ACdv2ajX7r8/NeBxS1jigCJrZDLyqajN
NtQU837hSaN3dr/aLqKO6QWtGook4m9q73SujuCupSI2HJ/cXjvnDNFuQZ5De4Gdp9W5pUCiHcrt
CgLvE1kv79EjcgLZnOAGA4s+IpYg2ohhamqBjadv7kblUm0qO5HA1DVlmyWaQ7YNOR0j2MlikBAC
seNzTlZiU0eMnGPrAa86q7kxpX16OkaTfklWUOWySEtUQ0wpWxxAirbWo3dpbaL5MPTxGwlngdJB
VwnQgXJWyiRwirI2qdUuM6iOgJYJTJQ/or3z5cpkUNbBWwsWvUa30BZsKUsisLRS58uW32R8pYly
ZqSo9RUugF1PZhg173d4ip7/AB6Pnpv1Venz1T1L139CdPx616KmJ/8ALvn5X36b9ExfUi+6+jf0
L129G+Li/C4bCf3Ry9o1HdskCso6SB0UdrDTrFIo6q88tLMKGdWrwFKitMZ8YYm+S1A2pUSwhSk8
XURUc6kiI1LO3ZHBYSvII9cXF67+hOm2L8aTko2HPa2Q24jsFgZCxy014kxs4YyDpwIkzus8W+4r
lWHuyq4rRx71w35tzk0KtAG6IN7J+3c0wNI7LCSJ4rMjGSaqzaQJAjMpZ4YgYFm0qSVHIwEeINr5
4I5XHSS1I0ceXMwDG/5Taf4xRWswfbg2rSMcNhVPaCjCXUW0mLLGbJtyKMKTZLNmUoGRsdKHteKL
bTkto3W9u3tlkfyqiXGkBa0OS7kUYU6x786BajHF1DPSQR65SMaQ8WcJA3tmiOqb5shFtY4R3uoV
LmnCCblrqVoQz7F8t0TipaRARmzLoIBXE1Dld75tlJPSEaFZRTCSxABL3UYiNg2ixZkC9EQVrqQL
RVGpRlz6nGKkrUII46ywWyt1+ZloGGlvavtCi0yV2fpZ+P0u9qBOtNIhaiAQVvqcHCouowxX2oQl
bX6ljjjXNmk2TRW0OKCw1DDQEe+SNLjaihFG/UNeFtzqT6oYGmSGb+kHZ+mXgyFbJBz9Q12WerI7
WaTO+bOVdksNSRIbRasf9QZqqEVjdYxmkvryPMYpV35vXG+zqG/dDf8ArGAjbnVDp5KTUUSvj22s
nHNA1mBY9leNJLqtXgaC01pHQVbdODPuNWPmIqbY16plFqR0FV1vBay71IS0LVariQYlnqo0mRF1
qJsa8s2WB9N2wKwv63rdr/UgLEtFq1IgpmvIYxWc4tpKVuIzHJ616L139G/oVM39H56b/wBPfN+m
/tm3Tb+j+c29S4vo+ev46/P9bfExVx3Qqbtf8/mBKfEImpSFCC5eB8i7JJSHYkhr+oj7h1Sdqfqs
uG1ER+LqEzkNLcUjb2QNhpinc29MMcie+Tj993Zvt6NsVPXAs5MRv6omK2TKefHYGQ8D1vZJWx7Y
8bG6knOQ8k58FILFe3Uc5qGsZMpv7muHezhI60nSml5vwFrKAi3c8yEUr8DIPHVttZbFmzDIKfIH
jbeyxbSxVDyZDlbcTB46+nOR8p5lRyooZs5MdMmvaw0hqslWSYYs4uPa7cRpTcK2WXHNc1w5ktqN
kz9nlO/BxzLjo8t+OgFxBHYrBz9iAl7dl2MiyVR8A2xYzm5+5mJJkIjXmLgoMhVMyWPH7rm724vc
fnHbET3jxJD0dVy1Q0ZWL8YvRvNudwme64JiqoqqS5poJQYqLm70z92+kxtDhJY2M1CZpTVFgCG8
Gra5jf1nXJkzV0AjLOwSWT8Jg2qqxqYx0Np8oWsjuc5unjkRdOlbh4qgV7c4ImVM1sI0bWMJjU1W
LgXWcdUlBLbL+lT7EoiR80w4UIala9l1SPe98ftrFpCS8XTJWpIrnxsVPfbEbkeK4+Jpg6tk1r42
OFsqt2TZMjx3GUemTExdNGYn0knJNMnVkuC6Kq9OO+MTAxVI8OnJBWTKUgccPhm2cETIde+U9mlZ
L0/SZ8kaeNHQNa8xF0vJRsyvfGxzdui9U9C9F+fWubehcX0Kn9BUzbpvtm3r/PXb1pi/0V9G39Tf
PjFzbq5OhMKnuzKuudIc6gRgodX3DTaLtjrq1TkJR9vItD3GrRI1TUCbD0/uk6mcF0Wi5js63xnw
ahDMn06iQwVZiptjuif0Uygp/METTzBstYTQK5PeNFcZyUj0R8Ties09zZJoWsZZV/juqKTyEdp9
rRWdX28qqzynh03xZY1CMaCD3ZMHTn7JtK1mQtP9xXUjBIalZxbR8jDoxia6oE5tpVdtHh3XxXbd
nZAxnEdT6a7rLKkaAdVQ93HUoh4amY5pqX78DTrWMnU7VyyrFG6kollEJp8bA+A0tjEpQDEaABiy
wCYlbSMPhKwA8JUNI0WneRUq44WLWCNl1U9rCQ3OcsJ6ZWREcaBVC7OoKxB4aPwWrqUmZJ081g5c
NROjsTvU0UHF9aJRX0dBlf8AP5RN8FFc/ErX7PhuGlIMZJMGCHsanhsC/tcnNryPxa4jc+8JWlsH
4SLIXHAVF8Fzk+mOwkHt49uKmN9srVYkimAHxb/gyFpmrYbCePHaFI8tmp6tgkN87e4mcl05phJG
Oqozg2tR4xKMYfFIVrGkihktuhrAladcwoLVzWwYFettYRoQYAGzoRSakgMYMg9ysryq1IjlLp+h
HHDyGi21MyWKXVkYR8RzcFAIRdNVwhlk2kKEkGdHshWEUUco9uGq65yEMHjiNwYldkKgIYdDpxrM
eYUfJ9cOcO0pngMWCQaDhEK7SQmRTyrONDZW3se2dZh8mJU0w4aeWJS3lCySOxj9kqpi9Nuq5v1V
MX0b/wBH59Kf09/SmL8qvp9//m+PX+dvSie6dF6EwvyBN3abqkaC4mpFHSzUSR2Elih06RVuJiRc
pz90U072PfYJxiqjhyoLJOBjNGzUw+OU1tup4aHDdRO0QiYvRc/Hr5e2i/8AQvJTxtnyXkfHAsh9
LTIxtkcEYUNPKtooeEebO45ZnbJfRx2oCXL7OWs1r26VjfamGdHSzntVNPs70gn2BTbFMgEY4do+
S58Rq9iysWQ1fbSZjqlrxAuCtO+Np7uItCxEmVCNylovdjEG20TePAREFZMO80disC0LOdnIcAVc
R0kN5GY1lLLCxHLsMf8A6rF3DZQpByeBIGSv/wBeyilMYDOAkXfLMDzirwuAC3F31j6eG1q0IdrK
l8fKv/VlxGyW29OrMrrJa8oDjmDtKjlkyMoSaac7zhryFqRNyE+cq4flHr9NCCF9MJuWtSxrP8U2
ocqwdXJ+7Tun0ktSojohaYL0m1CMmwKcaCk0YisSob5gqUL2JUx0S5o2NFNEg3riYP8Au0x/5uqV
2i6YTav1V7xNLf8Am6p/1D/O2achpMmMGgRskndKkhacVA3tpIjtksVzY4tUT0lTNFf6uof/ADtH
IisvCKOuHPNCkTdQEnNpKR8ojKqOyPIqFj2LfZsqMVZqfDYoHlnacZJWNUR4gb6YkeTVU62I6yvb
XA1GTYUb2jnjsksvqLx3OFsTTmm1M4qhhRwOQgbuE6XIie0UqAWZY0Q5aVtEGCPVUkEQgWyLF2mq
da5kmcMRV9sHXkZZv926l/8AQX074ubdNsX+gv8AX/Po36belOu+fnfN+n56r136/lcRPSvVc+fS
nz6V6J19t3YX4IvuBfu0n+tqZPYBFZIoDqQXwmoXuV+nF3jze327Uru7Vu/jrOGj0XfNU++V/wDv
A/1NR+zy/Lm4v9L8aJd/19//AGyvYmmoLXpJf2A2p3vNp1w/IjqnY1EbisEqJLqHIsfUREZhDq6R
pszHCt3tSNZlcptKSB7yHIgLgyrIo2v7U2UACgL3RXENxnVFS2MO5t0CyhVZh5L1ix3ajch2WopE
iLJEwIioTJiIoITeLJ88UbAF74mptlhx7VYRrh6h/wBeiX/sV/15pvEmg1SNGRb+PKN4rCsCLtMn
2QoahJ3RNZxWZMbCHBmNmD4pviyhtddWI1HUrvFNJ7RZMdDCuhcTaZSVzlIxka8M1x9M+80SbD1L
/ldnxmj2IpzfsDMupMSVKvnymDdzlVH+lqz2LUN2gkMwKPt4rcENLSYiNExMvnKy0jrvHsLjwplv
qMRI0w3eKuImDzS//m6s/wBXTP8A5uq/9XS6bV2rP9My/vRPfRy/9g75+oxlM7+2j/utJjoEW01P
Klqi83aK/wBXUP8A5+j1+3fJvA8V5ZRKZ8RtFZQhpy+3aW0Xvt/tl2KJMT5ly3jtozGkW/K8UFsc
hDRLawgJp2wNYxtQsRQxl3jskP8AqtmNCQafT6yZZTArY1pqF9pYV/vCtbDxTRF5RdTyFZPrtyx7
Z/jxJqPJL0hVjcK4sUq4VHZPsrYnwy0c+eT2ZqR/Kwd1diJi+tcRevx/RT5XNs26b5t/R/H9HbNv
UvXb0Jm/9Bc267dPj1L03xPlVz5x2GT2Jg/Z1DLR8W9j99tbC5TK5jYgmTBly/h9xmnW8A3Ck3bW
vI2CzthuZTgHq5Klj6lVNqiG58hCoGLqIyPKRfdVxUzf39W3RPjRH/n3bO4ybHcx9XdeG8J2yhWd
cjsro7h2kf3h6iReSNV5qFv8fUDFyS392jxduLet3HPaqE0kP7k5P4lo3hKqDJ2biMshaxnajtGw
xLLdsdtOWatbXJBJOdzC+ldINJpkiMJYygu0oYxR2ar2IRk7VtDWUWELsR/qQu5K/lpBjeELUVm0
i6fgu8tW/ts67uHDRsVsGj7MxzkCMckZEtIbpZ47OyBsob1tg+WKrirGjrKYj5S8wtoTHJYwEiJT
LvGNH7p5ZkBH8ZbOdGECqjag1Crsc5Tl01VL3v7W6iKilcub5pM6Nkd5DhdptJUm0qRQ44g87CAz
tw9UtRcppTVj2sD6i4GnBgHXkaAktiHaNURLYCGsRt4D1gBr1IPZWhcq+M/PGdkeKriUQexW6jaj
oWmpjEj2MJJw6+GkKPqyxZx7KvVIzkXSwnR58kiCDBKi35iI0dQLtiumo6vntRhRN5LpSP2YFwxH
waq4SukjeOyBHoo4CaplBGIEvsSCa6+wyxc+bSX45oVgBee4uBVwaCIkos20ixFKoZ8SHDjimnoY
5kgwGwB6ntBbwXdyH4re/aTQhG+fHr4uoNSEtzAXtu03qVpGPhikraWoaoFOxt5JnWUeuZHlgso+
qK9Ir9GlR8PWkho4lZL8QtLessxNgiGTU2qw1oDFdIIrc2XNtsXPjqq+vb+tvi4nTfr+Pj1bepc2
zbqvXb+tv6/jovqTo7EXHfH45YT9yF+WrlBdPjuScI4IRhsmzrZjQVds7vSLAJGwJrAoSSIrzzgj
Ey2ajL2ahVq7Ro41/NadtMQQQW183hKkqVV98X29HzidFxOqZpO1ZFAW0AZlxKY/H/NRcOiKW2jv
FBkhWUK+C0NzZtLkJzWzIF5HAO3uBGR7tz1VxFiDsb8Jhzz90lFYRooz6iAUVrMbIdU3yDRt3Dfk
rUjGir9SMGv6kikxupo4sn6lR5I+poqp+pIo8ttReUnc5Fq9QRYjZupgnZE1GjHN1LDVJeqRqMlq
byYGqAtbP1YwrXTFJIh6iiR0/WUZzbDUgnrE1aFifqyJtYao7yQNTePjNYw8maxGRsfUZAHDrONx
kaxC5r78/fj6yBxfrSOjbG+fPWu1c2Ix2to6pY6mfLyvvmwGz9TrJQxnFUT+0WDrAAWy9boYcyW6
S5U6AkOjlg60SK1dfBXJ+ojT0r5/gmDr5omWeqPqOV+oTQFZr5rcl63UyCu5ApLdb7NTWj0X9XOU
jNevYOxvi2OQYzpR4NCPtN0+LC0IUS1RsEo9dGjJP1gWeyFalglHr+QNsjXUiQ2mivuJQaAG36fB
hqwcJLfURm5HklAYuqpTmi1vLjpL1nLlsKRTkERRvjaymxWSdYTZjFe4pIOoJlc0msp5UlyCzHo1
c7eKxUyLMLEd+srDhJlyZbw6nnRAyrA098bUcyIxbWUSSPWk9jTawsTNLJIQ8bV8+G12t7NyGsZM
o57GTMTtZxXByCheHV9kNkyxk2Lod3Kgjm2EqyWLbTa5JtrLsMh3UuAky1lWSs9sjTTxHP1RZlaf
uSH9vO3vjhqmOTovpXN/QmfnFX0fn+nv02xPQvoTNvSub+nf1bYnq39S4np3zbpt0T5z4z4xejv7
Sp7/AJjsVyjjSeKNKrnRTogxPcqxZOCiynYkOXjocrEiSVwoCtxkQr8KAo1ZHKTDRiNxyYuL0TPn
pv1Tpvie+R4anxtKfYkN4MdnHdWhXZWKmR4Di59IK1Dx3CwEJx1HSF2PDePGxuTg0pCYereJFBus
emIZHUjx4yvc/B0C7Oo1Zjq5eQqBSY7Tzkw9a6Pjxe7hpsnw1OWRqxZGOoXBYKscRzNNK7H0CsQ0
FzHxqMknC6eUOHjqNQw+8rdOvex9b2iRtOvMjtL4TTysbLj9peGbbYiYCH3ljaaI4c6B4z48J0h4
NLuVkqlUKw9POk5+l+OStPdpr4TuT657UILirGclr6FZDf0rsyygLGI5OoA9x1ZplTNtKHw2OF+6
q046ayzqUiYrc44rc2xExB75AgLJJG0pyHbVviuER4CQLqzM4EWwIO2n2MF0uaeU7OKpit6JkOdI
iOpZFjPxKqXwtizAkrtLElD/AEkxFsdMdlkoPbXE91YPKbTRJqWdG6KtNT+WQekgcX6THlxRrEyn
qfNOzSAVZeVKQXVFGSxI3R40bYaV7YpkdQP25LwyPGeYlZpHkGdpVGinQHAeqb4g8BGUzqrSPcF+
kw5a6W7Q5gFA9vy0fvDrnSXwdHt7VlpVGDmQ3BercRmRIanJW6PR4v0hHyz0r2WQKJ8yQLRoGjvd
M+I2SLtuXF/qrm2/Rf6u/pTqmfPp36b+vboub4vVc32/oJ1VP6W3o+M29l+HYX5TKCoWQ5atggAj
jdYyKpixoFM7zJFUwY66uGXD1oRYSAJWRqhj0tKFFbWUiIzUVe0CU4BObOqUIOdB7D3t2xc4+jbP
jPnqiZtmj4TJQjwRAHdHYquZydX1rpD0080YZUVvl09MxoZEMSMu4rWt0/UoVjoQWMtog0ShrkkF
ZXhAyyjMVsSCh50KrEEU2MNcgVA+UtY8VrI7JQyVwxkdJhRmRO1My7gNY1a95H/RiYWuePINa8xa
ilHEFaRmeNT1rGpOlAiYII5Qz0iFkDjBhCeMUlLio4Jp6pa7HAGrDCRbaKNogWNyAD5t+F7SIswj
KIjkPTvCg4rnO07RI1m2alGjJmlq5io5WtbIaI5ADaAS3IyzTRWFGKGFZJ61jxWdW4T9lEWlvxOI
39zNTsRDP+cRu+VcUqmqwqKLqZu8RGdyXSp24upt+UWE6SQeln7E005GkrVQkbTTysLptwkrnur5
Ud28e/qlkrNgOA6okLElQn92Jq9vEsKqLNKzSBFQ+mFG2bEWO53RibZpGeTvL+3Ed515twaLUBiW
RmI8d61GSXJjEzTNF5qtQcUcuIyaMQSVdj+YxiFLqJrVhafsHhnfK3xCTbSsgshRb3VP0w0a9FLi
3RWkkVOnXWeTtPvhJpKrG/J0xsEFbP8APHe1DDZI0w5rItIWRIi0Hgm+G/U7F1q5vJuo28ZoI7nk
p9LdwVZTiiOt7NKwFbN+oRbujGckrS7gshafLLLBofp8oi7NjWFkS3e3m2NDHFyyvfBlqNkwGrYb
Ycl+bdNuiZv619/Uub9Pz0X1L0TonTb17f0vx/R29KYuJ1Xqvq2xOvzm2O+C+yp86RjM8bUZXBZH
nOBJqCpLE2MNi6lmdlumCK8M+O4qS5ixR1Ju/H+cREbmqU2SJLfHkwWpIj6kCjFMm2Ozf0behOif
OhP9W7/xWCqha2GssldVsiDubhApXfyrCEPaLbHdGdKlrOJp8XAFwqgyxtFI/S8fbLFq9m0s3MzT
rFLJKzcVrYLHylm90VlA8rIIkAC+lEasSIawJEAOsjSZq2UmJTiEMjI/KbEG/KerYFqZObyjVq/s
nQWyFjjQIme+WYlNHpw9oF4n8Wpu3+YjtxmXa3BJYoJFeI75VG3jX17WGBEY1k+tGUVRVMfKRvFM
1HE5HoRIGHY+0V1t2Z0WyacMaKxD5cGdHnUtw2U2ZW98dzEQL6D/ANAHuLU/+Yie+V8RZJKWmHAj
Me1+ak/0a44wza3i6Jq4bWu0xGEJCFaNhJAlGX7ljDAgxOY0iXMZoLKH/qOVrsuqlrx9vtT67/R1
anM+n4TYkHNuWarYNkhy4i4maPX/ALIv9sH/AN4n9sT3vn/Gof8Aa3yP+5+nGolXOhJOGAKAFb/7
mHmgipqfU6SMof8Aebk3/wB0fxqpf5KPKmUtX5pqyE2FHnw2yxUkdIw5g2mbWtaxttI8UNfNZZRw
RWR81NqVIr6rUoJIRT4RX/i+E49jp7TbRpa2oqqPRylmxJw2Fyua1obqf9OSHKZYxRRmRk1LqrtS
KzVMeQEFjBOTpNjiIQH+PXa/zndN8367elfSvoXE9K+pM+MXp+fV79V9Xx0367+hUxc+M36pnz6d
/wCh79N8+PRvhfg3ymaRfvD1Q1VYjOT9MiexmakA9y6U9gTJXYbZEWXlA1Wgn2axCRJSSh6qX2H7
yan/AF9TO2aZfTv6fjonzob/AFrr/FY+5dLlEPDv7obaG7lUyVhz4Bf42pJG+eQoT6dkd6PqE/7J
L9yaWmuMO2N249oRVJpaW7vlIrYt8Xc2ngtaC6syxmVBlkgsYHkPiw2Vwbiyed2nwOZIme0SYUoZ
TJ0nnH1SATau3BYLJdwBA27d7YFi5VmceMmTj9odQRSM1AVGRqhd7NntHuUI2SKTYbQbGb5Y05BH
EGNzpLGEL/iJdNrDR9YgMUb+4PVUrZ+mDPLHu3K2FMVeYJssS0MmwkSiP7Q7d/kS9N0PHLSzFCDa
zkkl081XTwN4i1Ov3nfOaTTeSReIKjlx1J7xNtpNMm1fq1vLKB0kRQSmlSXB7rKeAgZEqR4zBu5t
1E3+fCX+IrHfVJm3iH/fZQE4wtVsXyKxd4NtbGgK20spTLphXFVN8441uaQH/PL7shtVl6/+2HEJ
9bIuzL56OlccCzZ2nv8Ay9QW5aodVLdOhW6bzM1Sx/k5p1ivmN9sskUVzHIjxagqCyJNdpRGRpko
1IbTty+fH1HqH6cLSdisoVowjwU8YscOqpPEGmYDolecvdbqGteKW2AY2acoSJLOVBDqqtsmTcXA
aeNZWxraTpOU0kG6EYgqmMSNF1YVD5p+I6HXmVSJfVLwTA15TZpiiIOTJM0AocpksNpAlnsAp2Aa
ymNk2C58+jff0fPoXEXPlM29e3VfQuJ/VXFXN/6KZt77dd+q+rf1r69839+m+2EX2P8AKLmlbZow
zUSYMNfxsYpGxYw9QtLJsEbJFRiQC2gu9g6xGjhOaFup3orNNyf4+pS8m1EPyC+U2EC7npIe9d8d
/QReidNDFRgpuxx20HtqhnxyUl82SyWBpmeFtZQdmxb8aLnHuSNPIggXqc0ltTuaVB2mW/FwrfZp
NLA2MdzfG1A1N9PWKdiUBJeRO3DCCewpZioYcWoEql7EArpKSBtrQvNZtBEFNchDaRjtipYlb48G
wamSQMlKMwYoJOpEFLFJZLa+THgiublZhqSuRheTVSyYBr4gRPGOEJhZdkGMGDdskteYbSmmjcK+
c1V0/HQ8gRWIK/c05aFrY0a5OxI9g5O7TVTVSKONCbfaiajaIaS5My8FCBbW6zCC/eXT9c2Ph5ow
Dv5jTyHe+JlJPSFIh2bZIG2AQLcTWEBFYyVYQijbG1LLZ26KdFI1rBqsizFFZH1IHzlmDMMduFVv
pTXkq5onxnHEzNQahCwFPwlTgyRKHU80bk09qEJx8wSMmWkWIGc91tJZpqQ7E0ydMJQkFmlUHFe6
dHa2xthxrCtuQygd2IxbzUoo4WVMmzJ+l5GfpqS3KqS2BD1dcMkO07bgHAW0jGnrZxGpqmaIx0TN
JvAMq2kTbVE8RD6f1MoXNtYT23GqYsSPOnusDNmHEjzFMtdZkhEq9QgkBs9TxYga60bNsZuq40WP
S6ydIkX9nElR9PnhINbqujjvtUPmnBqoUSstbI1rJaq5V2hIJq/U0QobfV0aMGisxkn2ur40cFFr
FXu1HcwJQNN2VcOI/UNaFmo9TEtTaeviVpG6nr+3qnWSHYqKqrnx12xOm3RPQubdd826L0Xoq/1V
6/jbETr8+j5zfombbdPzv1Tr+PV+On5zb+hvm2IvVej8N0iHeB8XVDGMdeI45tTo4IZ/blLqpvCP
qwYc/V4lwurWq1NTtallarNHAvvBHPuVmpX3n09k2+dNaUiuxUxfRvie+J6UyqtH1it1oqpNtlmK
Rd8ARQkZqkjBBuXiOmsStbLvSTcaRRmDq8ocl6kLNQjuSx9THjMJqs0hpjeSsO6NXtXV8hzZUx8h
Y80sVwtVS0SRqKQdgLiRGVuq5jUXVcxUkXJ5WM1LMjJ+sZvGRbyJS8t1jX0yO12o55msnyAvbqSw
Gh7ydIQiuJkezlxsPaTD45zuYb6cFqaksVw1xMk5HspoM+u2ioWTMkYEkiJi2diREnzkaVTGULZU
dUs7NMMeWVw7Ce1CybE6OGTBzJgUdMszIQRsFIPHw8o58VvFG75HlTW48tk9pWPz4zfExk+SHHWM
lyvnSX40rmq2zmNwksxMYV7M86WmOkSCY1Vxp5OcJDcc8ir5J0Ty5O3uuIqpiSZCY55CYjnNcsk+
Kcr803PgRxMvatEW/rUy1vIRBGjSiEKM7HOxivRzI0s2NAoD1t9VCAmp6jF1VU5f3sWTj38s5Lnv
siuXOC57pi5s/ET3XE55xzbbptjGYOvPIx1SUSEFtjhpvjRryHWkk4tEfYlcUKPHxXEbjWKuMqCl
x9U8KPHnDNsYL9460p8+hSMJXEFiBV7vohnIetdHx3ti9Fz4/pb9V9C4mb9Vzbb179FxOqf1Pn07
e/X56/nNum/RMX0r0XPjoubZt15Yi+zkxW472af5+chR+66Jp/kMtXwkLQcgtrl8hNP/AGo9FyV+
nEbi6e/a2h3yZRqJsOmUyTahY6Qq7yllUSjQ8fhm2O6fnomL6EXEymgLNIPTOw7GrQCPZ7sGqqKr
e9poqiWqp3Scdpv7c+t7GV9Y6U4emv2WFL2sjQlOaLpzkkyiQeOi/frtOuMyTp5BtDRKQrNOI1hK
FvEtIvdjacRG/p9i5ZUvaaQXFVEqZxXBjXKfT75uS9OJHDApHSjJpto2Eom5OplGWu0yr2SdPtYy
wreytdVOlmHpVohSq3jMr9Ns7b6QbXO0+Lg3T/dkLRCG19Ex6A01uT6CFrWUgnZYUbUSLptjWOpR
Jk+h/bWaaYgn0wm5L0+jhLTqsg+n+DJcRRKNn7qaoZwSjCrL6IgCuzbEzfPn0JjE5Y0CuxI7sQK8
tPacSVl/VIDDDVFQKriRnLjozkxIzt/Gdixnpj2KmOTEwQO6unNLDcPUVQwBaOIJ0plcDjqGF2pL
47mrDF3JNbUx2QtRDaMyC5q2C7Z8Fw1ViJi41MRN8FFe7FgFxwHIjYzlzxH46K5MSM7HAVMWO7O3
7oBXZ46plJTvsDw6sEMMitjyh3dKsYhIjkxAZW17pEiDUhhBWRA71hUBkhtA+MZGb5FrCysp9NvO
WPCBDFOqwzRW9K6OR0ZzcUarlZBUkmHCiwYw7KuOW0pwyA02nEV/aANLygZKFaQliP2xei9Fxc39
S9ds2zbrt/Q39W2fGb+n46Jm+LidF9X5xMX0J0X0fj07+n8575t1RdsXoqbq/D/O3vo+p8lskTIA
Cz2ksIvCRGbQ/wAqajIwKeSw5JzkEwcxnbg9siSIjJDIVYkXNShRg6me2KRgWyw3tf2VKnHF67+h
OqZ8ZoVN3TzdgFxYKYqtUi01M4yuighhsHpJmUkRBx5UxEy7Ox49LxU7cyR2Ms5bFbpuMhTnd4zJ
0xitiDbJtQD8ePKnMys7b8uJhhNquRgWLxxXH1I9VoyGkJekYjY9G6Rn6bRqS6bg2no3GLEitiBn
JvFqRo1luY7Ereax3w2ELLN4keDL85LuA3s0XZAqZdv7U79X8Bw72ZOltXiKz1CyI9LGwmErkeke
0tkr3zNSSZC6ZfILEt57IY5GpiGXT4ZK5LnDErSIo+1IJP23w0xsGeF45Q7ao5pLjKF9JKKkwH+L
VP8AnInv029LE5Zp2gWwc3TgGtNp9nAdIjZUUSBBOjtMGdCR82v0wIAloAZP06m0Oga4Y9Oibk3T
rHjtYnjkdiJmmKpC5HEmWYGFjrsyzH/ikVY5BLmhQQ6ev7k0ItgalAo5OntOsIL6LHyfQiUNtGaA
vvjG5p6lWyOGiijG6kAuS6UbJf0AJBjogMbO08x2DoI6AgUrC2V3SAZE7CmPp3T7e3d0bGi0lH7M
S37ix6VpGiso7D5J0+Ewa/SqIWXABAc0iGGPT/8APX3TUDf59VUEnGgVQa8MNRubeiKcNM0jYdjH
Gc8zTwjBrNLtGTUMMFeJk6fYP0/p9kJlxcDhZHT7NrGkHsAboPXOzJruu+bdPnNtunx029KYub9F
6/PROq9d/X+c/Hp26fjp+fQufHoTrv8A0F/oL6UxF36kTdD/ACnvmgf9HUn+F5F56XldzpqUqtbp
b3w7Ee23Xss0yZzwPOweNcjs1L/hOqo/Ty8o+pm7JIx3y7rvnz0Tp858Yi++h02Jaf61p7HooflF
ABsEN5YEetaiGl12yR9RvQOOkOJK07xaC7VGgsJLu7pbhk3bxrmSqE00rHlRUc3UB+BNNOe4cztI
2IVvbvRuJlPSKV0yaOujxpS2U8bUjRZGomDkmswFytcJg2vR2FbyHXps6UYQWxytIxqe8pqOFV8W
5cf6cMjm2wF3DqP/ACxo6yC0VI2OO+u0jMLK70mBZQhshmaYOqBLlFTLMKYo62NbWjp5tPaf9rOy
ZXhm3BCyoGqBIOJqGIYrc1Eu8igmn7hAtWPfPZ3qP/fj/wCHVHtKL8ridNs2zbOON9l0zbh2eRxB
ypBQBnW5Blojvk1+pZZYsbTCLKmmXiOpspMixkJ9mnepI1nIeDGfGp0RspUz3yunSAPq3KSv1bIM
JIaP80X+JkznYWnvXhMo7IHuHVjuE+gvhmSQJTJaHkRBWJiSHbe40XfQ7U7F4RwoEXUEiG990aaa
D/pEK761ifNX/wCpdf8AnUb47ZsMgnhlmCIVKYZx2EhIrKqUktmpSqGFpyc+ZCMNok1LPkSpsDVR
4A6vWEifJf7NNVutbSvrxVodT6qRq6X/APLtJzYKVUjyo2rjKENBKfLrZTUjpZrIt7aioWQWah1E
yqDEeaXZB9wzrdoJMdeQ9cOR1gq4vTbp+eiL1TE9H46/ObZtiYq/1fnqvXfr+P6CdF9+qerfp8+n
fr8dN/T8dG9N83x3wf5zQchEiXid8R4vCVpuEgmqViLdx0OzTwlE+zIoxKMkzKWN47NQEcJunrFZ
I9Su/YwanLSJ2AamM1WFdvjsX36/n07dNEL96xTlGtY7kLUWroDos1k0NnW88fHeKTSb+NqPluZP
36QRUjahReM7dCaP5I6238a1b93TyL57d/Dvmu72mHJ2NQI4rNOicMEmOkkhUSLGkRjTi1lSsOQV
f4tjWvkyPoCgYW5lQV0xay5pZbuIK1+478TpKUwVDGfLYN8t/eZVxXAzUE5oxVkVxLIbe2y+hueT
TwtrBy9sF2blJrqhJGG0+m9WHsRNVyW76fRPH1YdWppwCSJLvtjkVMieaVpxsYP0nyn0em1CabMZ
ECfezm09UKsjag1CgmyJLpJtP1ZCSht4Jqp+8h67qvviJtiN5Z2lztLjRLnbwYuTqKnTcbSiVRoZ
uoxsEbTUhvhzq9J2Bisr5hdihralY82eZARdPv5xpMbyMVyDZqKQhpPDGj9gN4lpDNfBlVw5pJdc
1k9ibNhmR93cO4V0ISyLdjeDNWRUdJp6VvbAIoSmGwgb3iknhiM45oyQ0TJ8bygQtJiES9gChOgf
6Sw0WXJOkYYDNMyLE7Eu1Z3Idg3sFoNUjqxah1Olsmk70UNDBHYx40YdeC2sG3EuDEZWxAzwSnao
qEYlZp3z0qNPDr1urgdeKoGIETVeruOM/wAml9QDE2XCFZCa0VdGkS01HZhGOviR5oLBpKtka0Xf
F0qhpsmojDjU94KThqcJpNtbgpYtrZLayuu+bdN//iXNui++fj+pt6E9O2bdNvQvXbr+E/qberf2
6IvTfZVXHLh/nKG3WA+HYsmgsGDSZHmDBDkXT0sEnsfHr3sQsg7To3shYGexFv56EHpuYgx31gwg
qJiFJKtRRA2Vksh71xV6b5tm3Rc2674maVkpGkJNGcF04SYVfuVlw+EQViKTHe8Rp8CwEEN1NY7H
qjpdNJFGFb2QyNmv5l08YIBTLYTwXElCv025g3/WAIG5msKtFc9hzJwCo+4FEDGv0fIW5AVobSMJ
bTUI0WHdiMxLOMPLnULHpLkdx2n7CNDZLv4xRR79oysuYj0PqMQGTrorz12oxqyZqpvbm2DpRKqy
hAb+p4W1pdRiJXz2x5krVInBmye+Wl1B2Gs1HAdkrVYBjsrJZj6zUoogbe3SctLYJXvZq+I9rNWw
GLa6sGcdddwwIuroomW16+wyksgV62Wre808l53tXZ9XqSFEZJ1xHcKwsFmPXpFAsksDTI1Z+mGJ
n6WbiaWHv+lBYumBtxxfo+frmI3JOuxOZYWD5pKi+dX4uvBduZqOTJkQtcDANP8AkKPtYamLZv02
JR102WkIFvqwkvKyi8tG6WHn6WHltUDiigajWpeTX24g6jeKWX/kFHii6nfGl2WsnzxU9ytW9v8A
yIiNttSrZrVapNWon/IeyT9aHnNpaVZuM0qJM/Sw8mV30rP16sXCf8hke1J0i3nxGduJe3j6htvq
CTaLW6qPWDk63OdF1oZRyjvkm4741vuJXMdC1hJrxTtXS7FlbYFrizdTy5w6+zPVEsNWyprK7Vsi
sYb/AJDluYaxNYHdfynx3D3dwxCKNYmtpUAdjqyZatq7ctQ6dqWZZMrrc9U+Tq6ZJxmvZw0//QJu
TNcz5Yos40Q3/wCgz2CtLc9w/FTPj0bYvTb17dN8+M+V/wDg/PrTp85t6k6fKJi+jf07b5+ei+vb
pt029HxifLvfovwfoH+6KaWxrySMR0xzf3q5CS1a0kxcQlhnOe7N5S4Tv7CQ2G8jGKbZ7ZKo9rsV
MVOm39FFwKOfjYUxcIA7Mf8AKe2blzk/BMOXEgSVaSO4aoMrsHBkPQ0J487a8mQTEwkAjMc12Bhm
Kv0oyZ4bubKYj8WmKiPhObgaw78WmLhq9wcczfNs90zbfBRPIz6MRrfEe5R0RXItC9uGhOGoqwkh
VoHMw0VRKgeTg0RCsNA8d0emJIz9NvxNPkRC1ZEezTj3IunnNxKcjnJpp6t/Tb0SVRqBixOT4umy
HYajdFyPp0sjP0u5uO084eSYnbIsJ6Y8apiN3dCpHzMXSruE6vWK5ydIUx8EwddEGia+Iufr465+
vz4mvpC4/XUlcn3x5+O984YqY5Ns5b5+UTEbkJ7RHgangRwW+poskZ3cnxdUzYjF1zY5+ubLJeoZ
ljkCC6WUWjt2WUDxXu9s+emyrnFcRMaPksPTjzDkR1C6LqGbBams7TF1na7zNQ2E1OKuxU2ypnCh
HZrqE1l3qQdlmyvWvqyzCM0ZlpSPhuKLivDEblHp5bLF0W3Z2kGpj9O7nboxNnaORcstOeGMv96J
uqMyvrHyiC0V+y106+FhRcVVmIzKKlW0emiGtz9FouWWlFhMrNPusiP0Psy0qXQ3Ebtir6dsXpv6
fxi9duu/9Lf07ehcT07ehfQqYvVejvfPjN+qen59O3XfPz1TomfOJn46KzHJh8XKmH5RK6h4AsYQ
xFiUzSR5tQrZQaNOxGq2OO+lYjWVLFxtIxz52nW9qupN329K0IqiJ3CHpmOZZ1qhc9m2Li+lPfE6
LiL00vESbKDSjGC8QIkMn740dTPiae5Ds4LYuUFJ3WuqhMZcV7GJR13lvSnEJlpXM4w4HfmQqYQR
z68fE0LaVU0bEDLrhokamYUxIYIzBxhyWyKdqEGCLHGFoJK21U1o5MZe6lc9cJBe3ARXPdQafYxk
2CLxqmpYUp2xogwgFLZPpOboVUGKIsYBkt6fjlDTeSZsQLW28djLCA6JHjlt6/uMEJ7FiAEc9vAj
5GaGYJsOOF8m1iRm18qPNy/C3whbJLqwM8W3AzuxxoIVhdRYr5uoIjmVw22JyVLXhsqxQr2+BKi8
iMwPEgtUMRhye6u+WpvkKrLLVunS4emIBI1KWSj6Eo8dQlawdSQjvoZM/T5UbJhqJX+2fljOWQaM
0tE0yREk074+RKZ0tU0qZMPQmC0NMQ2Noiq9+nSsaWK4a6bjFa5PbNWftmP+VwSK7IFEedjdKmTJ
NGSMlNROkFYFjA3tO4ZBQnmeHSp3IXS5R4ymIR36eINf0yXJdW+K5sdXOHpkyhbAVJVPWMr4xLgA
5MyEycI9C4j5VU+O6Pp0skenQeNHtZ76+O7WU7bTdkexmyjeOA2sZzX2Wp5kxO2qujQ3HfC0o7sV
NWOEOfdhgHKAc4Fjp1zjzaQsTIOnzzG05008Wx1zHjs01dyLhk0Hkgjxxwgxb4Mqdd1jJsayZ2Tu
zf0e/VfUvp39G2J6dv6G/VcRPTv6vz0X0b+/TbN/UnX59Cerb0IvTf3zbEx6ZI6aGiNNljtHhzJz
nyaGekgawhOdYkSNGp5bjTJDVeIhnxcpZqSiYg2tW9bvGeV0aRQH82PqSK1jZP8Acvyvr/HRM0Uv
86UqpBuHO8gQ1O+iotssJ7IApElZ8miFxi2pHRnTrTvP0rH2FacmjsbXbNNC7kmS37FjZqDK1Vm2
AR7Bs5roi0U/vstIqym08TxxX0twU7smc+krkhCuLPvOrqFrhkrQjybAZtTUjVeiI3JCcg1f7Mso
Xlsr46RgfLpu6x6Yb0y1YjocC+ZHkDdzbqb2Os+SuUtUWXLcRkOPb2pCyIFUpsggbHj6mkPZg0NO
XT1b9Oh38xCJUUTBtaiNS4XZ4So8cytbIdK0+3tmQlYalumyxyq5JQ7iF47qr91hE/19WJ/JKnSr
jeVIqYUcMV6x0yeOOuQYwwAVjVwgmlaOKBkvxwsRgwGbqavaBDp+7KSKkqTDCEUd0gHO2YJ7a6EO
FHwwWlZAaB5SNCFjO1IFI0+h54xCiiTNXr/MevSoAh5VcIYoppjBEtDh7dTdQ0Nv9vU13H20vXsQ
E6zBWMiyhz48kQos3ttyPLGd+oYLHR6Sjad6MRBz6lBS09kkVzFe34BYgbNk14JCleKFHp7gEkpV
jnZ9LiEQMRtRPU4HtSuikXUNCjAjhuIegoWxR3N0KvZGcro86EMxwewi2Y4llIhimo1BQAanvGWc
impnTi18BlaD64yTaF/xxYAgyZPvGuV/7F3RM26qnv8AHRMVei+jfPn+jt1T0bYmL1Tqnq2675tu
ub+rb3/oJ1T0Lnz0+Ou3oTrtm/V65I6f8fL+23TlDmN4l0ywnLL9jngov2zXP7Y7aX3800xROny/
EbAntmNvF/jTPcmk/aNqf+2Su7nfO/oXouJ026aM9rGV719wn3tPMa86FRobgBXOAZYsukP3I+pJ
H7Sk+5pWZ3h3ZeEeequJpab++SXhFujdw9DL7EqOTkDUsrcmlQ8ktJ/iDppyzW3ETu5VVDYrLm24
ZWdw1iicYtpJKOWt0d6QdQgEyHbRpZHrsyv4vdcWLoAqaW6YHbJRO2OrP3ZNuu0EXvbRP8GqE+/X
R/KlV0RkOPqK1cr0aUpBXNhFSlkPkxdVNRGaYrmZdzfDjUpfOnnXthqiOIHUi7DFY2SLCurB0oSc
w6hRENp2jIc8qSOCC8smHPUoqzo3tH1b/sE6RXkAWhsCFF22nyfAKj4/+B7+Kou6Kv8A3cn/AF6Z
qti6udsEnyrPeH3hGpZpOygmSMnQSDMz+yx1IkEr76VJBpp6vmWq7QKn/Qy6c5AD/s1cn8tW5xwD
XoShkyAiY4UrL2oc4dO3t2jl9rSmLKkULO1XauGrxaearKy5dtMblSxzZWoHca+n1WRj/Ib2J2p1
kzxPQg5HkvsEXghBum3YHoFdRhceHFpylcepmBzSbCMh6jYpQFo5QG6PjmFMtU5QKWjaF2oNRiqB
hmln2FeRCwrhJXmR2KwN0izrqCnjsvRulQZkZ0YmkwNZC1fNLEhaTMgrCR+4NaGU6xnP7cKyMhpu
3vm3p26qnRc/HTb1bdPyvXbr8+n59Kf/AAbdNvQnqTomLiYqdE6L1XPnNs9uiZtm+L05Y7JHTR1g
kcjpLZUe3gbHoI6AFJu2RyFO2UGHFQU6V7xgVivJFjtjv1ARFBpqQqOvCo4Ix+TKqheGDUVm0mFX
dV+eqYvo3zf3+M0g7jYvXnEt4C7uIoX0l33EOJkkVhB4G0+3txtRj7jZCfd0iDtsu2cx2De0XSkZ
e9MTeNdD7ZqUPdmRk2iaiDmlpbRhnt8xKiKkQbpgySTuRwRUqGMSAOErZTSBJUNkGl1oosaxc3u6
RiIhpSoga2S0SzgpOSvAyGCfftinHLbNYIYYbdQXrSLTQO8Znsy7jDItWqDtCSmMhXJ+cqijheMl
WwmRkFCj6ntWmXTJmpE1XNYVunpbY8vymyARihA22MIjYcYB2MqRNNNnDigCiWs502PWRLu+fJJv
yfp2mRmOIwLNTzUkSV6VBBJIgBCQMYKAy2sQiEGaJsadfjQsWeNY0aWki5VMe8cQepLZJpW1Rn59
INlZBWOaMwBRhE2O27uI8cVZajmDdAGQlpLiRI+nJ4yTr+yE2FSTBrCXUAWyyPGVjLKOuak2kF+j
ySL9DO3IVcSOauNHKEIBhy+uI0WNGsmjsKu1FOBY2EaGGk1IAp3jFJaWQCCI9ullc/COcMKaq1IM
jUM4arqGw4jM5Daf1LuvlARuo9VbJpt0ePFt9ZjhkjXQZsIVtFjWKviSmd+LDFP1cB1lGmRZcdix
I+Wupgd+11UONGmyCTpLHKmae1E+K5ljFe3Uuq2RxaWMDa+1gKBlVqIM+Pqx0fu6Tswtg62thSEj
ndHdpzVDCNfaQxs1ZqktgvH2RMcnVM2xW5xzbFzfpt0TFX+ntt0RenxidE6pi4npROu/p3/pbdfz
i5t6V6r7+n5zbPjN89s3zfboq4nvnxjl6H9+kcrhkqtSIMc69HJSPqdggT7PyixdTDCMOpANI3Vs
Z2fq2PsupWK6fqBkltbZpCWdqPvtgTxxTS9Ud1kmS4yuXFxcRfV+MTPnKuasE4tbD4T9QsltKu7m
EVj4eqVjCfdoSQHWjAtm6o85rybkh6sSKyTqzyGyT+QtffLXtfrDuNmTvKWvtPBxus12mXKzViy3
w3i1g8aE1e8jWXhRlbrErc/WhMmaiLMSLqY0Nq64JkvURZiuer1gX54LF1bIeiW5WlHq6UzC6okG
SQchsh3cmDkjUcuS0r3vdG1LKiMTWc5MkakmTGjOQZCXU0jXIQro0g0FzNV2DckagnyUMryPBcyY
aGnlkKie8a9nAa64sHPNZTpCAnzoufqO0yROnS8FLkQlPaSpGOVXYm+RrqdHR91ZnaVSPcqbdE3w
FvNj4mo7NcNOknX6tMaNsgilbaTUzRkd6kM7gK9nyHGoBhc8HiOTeFk4sRo5todh/qVkTDKd6jlG
Bn1afhJMg+DKQOEkSD42WcTe6Tf6hM2SXIbmn3jIccytYn1CsTJdlW8LKxd3nzpmPKQ2bYwpgYpz
Fxm6Yhpi4qyFzS0PnJXNVqqSXJuu2cM2xEXGpIcjmqzO4TERd+RMYmNHJJhY8pMVitTuEzuGXGsV
+DiGfn04zsdXFTEgF28CRn0wiYUbh5t77rgx42KQuLAKPHs2xcduubY1m+JFe/CxnMzbNsRm2IzG
Q3vR1eViFZxVyYqdd+qpn4T+ouJi4mL0+PRt6FXov9X36fn+mqYnTbfrv0X07dPzi5+VTDdI7ebq
+peZsmo7DYtKp2Sa5Y7w0ila2j/f+m02TTiZ9CVHmolRga1XvkUjmDBD5ldSbDkxXCc9u2OzbouJ
1/PRPbN8hBU5I2nFIyZSeM0zeLms3wMN78fCczIVespWaa3ZPqXR8BFUr4unFekykUOeMqlg6eUy
SaDtoaL2n11M6ThNO8GrUO74dOqrH6fTjKqXMWLp5X4unmLk6k7LTC4r284riNysqCTHv0x2QjqV
LJDpVEY/TqJk+qUOVmnHSkLplo2WFa4ORoDjFi6T2DZ1/jmq9M95j9OMZn6bRUfQKSQ3TTRsfQN2
tavxscH37K71less0bSo2D/TzOT9Ns4xtMsRH6fG1f06xW2NXtJLRKwZ4iiXb91NQ82D06PhfQEi
nJ84mMGq52Vzs7oo1xBrnbXId9KhNLq6eRpSkkuoqtst6aeBwuYSiM4bshR/IkQdOhHCuY7Rk4bq
glxQqmdrPHVcWOuPbtn5zbfGC3zxVxY+2drfFBiDxQ4gHORQq3GCV+UOmmvFf1/iEBLkQs/UVm5C
kkS1UfsglVPHdnZVMrYCyzO04MEGyDwOrcaFVztKmVNUScWDRAihmUoJA7esdFc4O2dpcpovfmjq
owW+LCV5a6O9kesjtG+PCRfp8ZyatjsinRfcEZx1h0ZDEq6AMQMqojyhXdK6KQgdlUecFymqnTCR
KKNHBrKGKCVBK7Ow7Fjuyop3T3V9FHhBnUkeWK8pnxCu9lVcXpt0+MVd+i5t1X0fPpRf6m/RP6W3
Rem/9Lbpv6Pz6ExUz46rm/Vem2+Obh+mn4fkya2pZGjX01nKkUTg2FJ5To8FsaOyQNZuzEC2SLmP
tGMSKMjB0rWSbWKxIgSsjSojmSxXlQjGnbs5/t0XF6ben4zfNLoj7NnEcW+tE5EVFyrr3SXwaQQQ
X3bR2l4De1JMwDbUg1ZpmIhjGVsZthIE5sADZFoMbY8aZKE9s1Gmm1UZI8aXNZkBgzEspjogqmS6
clgIYsPqUcVlPaGsi26DYD6W6YVNNqiSaJwUg1LpBqqtbXiL7iphN7tnLJGFUSCygSoLZK7NiAi2
STnWsBvYooYhE+c1MvCcHVw44P1XLlyornPBYXIYJH6nlSi1aFWLqJ7ZBYmlnEY/THskZac0nWez
aC3nWE05ECOdrBAZE1LOmTWftbKsggsh9mSK2p0XJcfsvqrOS2RFdyj6t/2yJ0hRVlGgaQagXaSR
XTtM9oMOlU5x6WYqWenfHSupHWBx6VYNhNNJsGI+BPYu7ZdF5BrakWKlLBcWUxj/AB7aK51hB020
gxaURuS9MJ24GmnyTJpoCIbTI+NxXeI9/wA5S13mFTS7HommQNba6e7GVmlW9r9OxssdNNQVNpny
MbpyOiS9OM7dRQ7mENNreAySB0ZHzYWnRNDL00IjG06/UG6XE5jNNR2stNODDlPVsiDKLYWpKsYm
tGpn6f073x3en2R2aTjIKNcEKyNSEM+PawUlrL0wxQ12lXEPbVbascjVM4rdL1xzTpD+AZmrpgJE
AEm2nRh9oGspDZEyHEWQ6h04OMEIQDlWhHjiaecfa4jNOA+lQvFE0s8suz01HFD09exa04JCSA68
TmfTVcyWVmnIiNu9LjaLSEdBR79xkhabUyRNaCasF/vi5tn56L79N/6KelfSv9Fc3/qJ1/HRPVv6
tsX+ht0X26bdV+JHumaHTlKP7Qbf/Z01MVjmO5MtC9qHXk52Q05AsxtBlLLc6WrkRGvR6Wn+nZ/5
9JPVwdRp9qUmzydV6Ji4nX5zbbNL/wDou94F77Ghx/JPU1jYoby1c1EKppNA1rIt6iIObLc8ulRI
xliieLbynoTTTdyuRHDuzqF1L9+ZF28fUhOy7Tcl+HG1zYKDZl/u5IFSso7GiqQS7R1jNrojAR5t
4AJpE8JGU4BNTkiud7tgsUUqQjFbFcPj785CchV42DPY/wCk+SVJ8Jyujao/zIzuE07p9NrSzZAH
IM6yk0VGkUd5dNjD06PzpHTUBBdmND82TVVbKwGor3i1qvlyNP0LIYr26bEHPlrIJQWxRPaBDA1E
JiPrP96J/q6t/wBsnvn503/6Ke6YqbpX17xycmN5RKALWBvLElcGPrD9rbFkywZ/YGYhpN4xHV1b
NeGxCvIepHqyfpk75ESzlviDavJghtb0cVjM1XMYYq4ie9LJeCUH3Aa1aKbInAI7bZFc1uSp4I4q
i4CfJTSvZOsTxB/XJSSoZFJF1bYSRPoat9jKCLsDT41E9Y9lCcr4c22SJLtraMkDTVvImWhf2Cup
cmRK00ATpEVo2jktG4dS4bmTStEladp01Kd8aLp+xWwhlGoW6ntTzJdBWfUpEeMKvj6q1O+QSsje
TKqKkdcDVOpkisjALONQ6fZCZqLUQ6cOi5JJiWBUCGtmMlH1E/hW6Ts3zQKzZNaXBzSIyfeqf/O1
ym8vTdIxgeTGLJRFj6ZXcdtISKlVLbLdrd21ars/PVE67Zt6Px1/G3Xf+hv1/PRMX17Z8dF9K9Nv
V+Ovx6l9W+fGJ0/CYnU6Ztmiydue56PgXcdWn05B5Obsxk8SHjhAoLZF4xZx3mLUwVEexdwjU9sr
pNk7eFY/ukaXAomahMihmL+9VxfUnX85pt21mnvCvhKpYEzwT19m2YKzr+6kuO4BNKuV8bUjncZG
/d0a52XSr49jvz0y97ppd/Cu+Xeguc2XX/6upeSv0nt2rxy9rTTXplgHv5HjNhhszyJ5oVMQcgft
FuIrynbSF2fdSqzKHUUmdMevEdYZSPvkUgNMjcyO8zRrJJyHWRipKuZLQRWsWRNhN4RtSRnPLWCT
6lHag4+o5LnStK1rVbaGeKP9GkTnUtf9PdOK8UdrrQ77aMcY9IMa4lqXtQbI3I2mGoSY5e2C+M4h
QAccmnqBkMV7ethjnz3Sn0sN5ZcdnbBrB38ojs3zTq/z2r9skxEf+E2z7y2En/Xp14D1DFdLHE0m
r1StZHnNTjlY7/tLz/za1vetWJxbq0PA+kl/hagfswP+FHI7L6MeSkTTReF5ESM/jnHbKiOpZ428
B6sE4Z6Qr/qHNHsl0kmXKkaaQUepoUHkdTjLJA2QG0a0U6rKhIUymbNLVgZBkWInGjRmKOPqGN3Z
8ZnajaxjciE35aQL2pxE7jJWnhKy02hG03qUEEGo9TNsM0jcCAybEbYBgw2V0e8sGWsmrgJXQvJb
KzUdN2i6I2SXdP7dbMJyl6YXeeVdh3j+5ZaSqxLH1JqgNPGNLLMkaRvBwjSAssotZVsrWakthy30
VX9NAKwAYuqqLKalfNWEHx4up6l8wtIVpIE+A59idvMNXZMqJs+AO0j19cOtDrvUoZi7e3o39Px0
29W+b589U9e+IvTf17f1Pz0X+hvjuqf0Ns33xF9Kri4dM/NVO8KRU3bZQrgDDConjEO8u1EtZZd8
So18nup2GxxteSSNp7Ge1Y1Uft2FhPZ4oU8mwCUUGNeXTjkITkq/Kpm39KjIg58eW18e3EPhL/vr
rJ8F8GxZMBb9pSUpWxQXUgbxzdu7ptqRx2UthA2z2vJpYbW4+wGobwrXOomdyVHnCGG/lDIlHaNh
vbJHJRhxQ0dfISd9REQQyR2PsraONkG8ZITvA3tLyOIU6T3yaXeIKGuAKMd2wUls4J0+qx4Y7bUD
ilqL5hhH1CEArW5dLfRkisY25hoyzsoz2BlsHZl1GFsWzP5R9PXcaNHW7hFxt9BGyZqoaSQagiHb
+oYMdt/qFs12nLQcF15qYR2GL3FoZjYcqZqoKxZcnvPoJUcBbDV7EBNsCSyt9301rXRhF1hCaK4s
/NevzlVKbElF1kDxE1K8ks2s4/jwNYiG4+sYaNXWUUgo2qmjkj1hXq2VrqGwcPVQVln1zEUFXqZg
JFxqxssdFcR4JP15X8bu/FZLSaoDVitdTtnlbrcDYkLWCjkM1zByZrkSsjxS30pmkmORNJtwNYyo
eXW0SPlzqJlqojOj5WaybFD+vouW2sCzkqNVuhJ/+gRcsNc94ZjkOSm1U6syV/yCxRsvZXlM18FB
t11saRrFhTs/5DA1t1q36mjl5ZGO6OSDrjwwWutCz2O5PXhviD44EjgvrtbOhhs9bFmsqLb6Ue01
wSYGn1EarLa6zWwFS3rqc1vrl9kDnusCf4JZP/Ib5EckhxDw9WkgRpcp84rfbBl7a1WuH1Y7L/kM
swFfbPgybD/kI8oFfdSIJ5+vyTo1LrB9O3/9QyT/AMkEkDg6rPBkm/5JIQcP/kKTGZZXT7SXV69N
Whttey7MOLm2bbejZc2/p7dV9H56/nb+h8//AA75t6E6/CqmL6fz8dfz0/H46L8L8Lh/dFxqe8A5
wqSZNe0c6XwKUz1HKlMa2bNaqWNk3PqNkuOlzNyHluxHkRzzy1RpCMcSTMXCvc5XepExU9G+JgVV
rhmnY50xcLvuuMOZmdwq4w8jEbMKhAkTEIZuNSWVroxkT97cZ5b8dGPx4vZjEkuxIUhcWOqYOJId
joUpEeEjcGA5M8CXhIxho5HJiuLm64ibq0auVtedydhyKKtMTPpJcLDcPGQiEz6QZELFcNe3uoqs
pcPXuj4OO8mNozPx1OUeGh7PFVPNhaZwke3gqtztpm22K3EGiYjcVMiVj5KvoXjaSPxd4bsUapnH
ItUSY5mlyIkuvWKrm7dUYmbZxxW74jM45x3xQpnbzbBRu4/9Om7UiOolxRIucMXNkxG4MKvWLpgh
xStPuithXhqlP/0GSmf/AKJIybrOTOG0L5hG6VN2ZUXsvROS11KWwdMoHQRvHxdW0r5+H0u+MKUJ
RPXEaq4MSuyv06aakjSpAMlQ3BxWYuIm+MDzWHpg8oU2sdCfBqCTXt0gXY+lSCYWIoyQ9LllsmaW
LHZIjuE5ybf0Ezfpv0XN+u/TfN9sR+b5v15Zvm/XbNvRvidPzm/XbPznz/V39K/0/wA4nVOqdNvT
ti/G+b+heqr6N+u/X2x2G9sd75FH3HUdE4iWVQ2PHqKlpW3FN221NL3RkqWNKOhY4f0Vu5qRvNdO
o4K0atlmokZE8X+eynY4VrU9lxGbYv8ATblYPvS4Gn29m2hAjtmJ+9g1csCjcdtlV+IOgqvLc2iG
JlpVNa2FC78qJp8Yh2NSxGuiby6rTzezNqhcbOL2C0VEhUPUiaxaRCyB0wQDSFHNk+kTIVTHEPx4
7nWNO3tTYvEvhPdjoj24wO66d075DiVQUBEqUkzfAjxxMigkZZ06ZV0TAjLCA9LWn2SsqXS5Uepj
xw6khtEagrQsCWRXsVsEMhh6FTThwIsIN5LDuRnJw4TzYtWTCRHMxsRSKlSXCw3Dxov3aZAEorKM
NYUeAkuW+kb2bGsUC8OLqSzgBSO0bhaqEgpBOnHkoK4hmDqzOwlWUbGRVeo6g64WtINBQnlc6qIm
LSm4miqJdOAQkuxUfhWPuaNWGkr9BOmHrSBRW5FrSysLXPDml6JpULIHFQwWTBW9Oo5B6oglFXvk
EJUkC7TFMMAijTt3fvJpaYlgWtrxxmajanhPHu7SzXtHNTlDtP8AZ2yppyz1iaZ/lfbgx48sU5l/
ToiFpConhucR9IYLNMU7ZBWMTt6vRFk0URsaFa3n0wkY3lxn0YyzzHHBAGQKwDqanSOhF919G2b9
N8dm+flev46L1/Oe/VfRvt6N8T4Xoq5+fVt03zfpv69/6C+hMX3/AKi5+Ou+/pXEzf36/ObZtn56
rifCfO/v+cXD4uadB37CvisBE1FYPcXTtn+7xmShNEyKKTYK+xiu5RpDiCLHsu5KT3RwGOfLbvGs
1UU3T9gsnLmG10eW1GEdi+nf0KmJlF/6MZf4Ooiv767kfT0ynVzhVUe4svNNpUHENqRwm2NxmlQ9
00z9oJ9r2kq18uwaNUjWFgsZSH+ozKwXbiWkh0Z9RZNOWxG4wqSC8BbiT4wpFrKkuoKl/O5sWMZX
0vm46lEPJdWPjW0felCEyOx39lZ9qRYxllAqIHhtds5xvYNZ3vKnDR0aJaBrjRyocWq/8wrOXkOo
fJWMLsR2bKs6OskBtPpjNPq6THpo8ZhIEd2XEIbWUVaJzFqwql/UIFtDQ+YSPFHFbP8A9KRKfGl0
t0yaOZWpKHbQPFfCT+ZXf6Wrv9h3SuaN8mqrguD4MUOSqoZRQIIvNZBC1LKqGUNRGB3kro7cSLGK
mpapAZptkZ7pEdrozoflWEKsBCA6TA5XQgKKLAWVKqakUGLc1DSrUM7cC1hrKLAH2o0xwEPIrQyx
waoENup5oGFotSyCylTJYPLta6EyBFTflcgUsWmoGlVEaxJy/wASxbvKpaZ9kWLGDWR4Ng2fJsBd
+NVw0hvsHMZHGkaaAFJHCbUU2LEjQNQSo5IRXSImsF2kUBe7XHgMlq1nbaxd3Wcby2VMZIo9WrtB
Vei4nXbqqdV6b9OPq36r136fjqvTfovXbF9W3RfQno29P4zfpv8A0d/Rv6NvVv0/Hp339HzifOfP
T49Cri5I3VF+dLrwtQf6WoU4zKhHNPB38Wbv4r0VlnB/1bSWzaEjvqPc7caJbNkElL/Guv8AY0p/
dc/6tjt334ub4ufhOm+L0T53ymX/ALKJ7wtRJ92uEhple4YI92pi49yjLpeW0obw3bjzn8iaTltR
00qCjXJO6XTktojjJyDqCRzLWSkjy6wvei6pl8c0yPulmnSIKqtknGuI/cFU0e5LWzHAC05pk6vb
xi3s2QOQuoSuZUXIWDFZxzvyM1pJk+X4YKe0Wxzj7lXiOLKa+bOXjEmr/PrP9LVafdGjmEDqWUFY
JlPGRNstJ614aac+wDwRFsV4wnT5EM8csu1PChDhgEdhsvf9avC0MVkhz7Ww/wBKwT79FUSJcrk2
DF1DYjOaD/uVybQ9X/7D83xmaX/8+635t9mx4TAvWUNpz/69Vv8AVz+wqF3IWqvaNphqfUTf46pN
rg3+Od3GSifUiip7oNa6FLbMBeXYK8VKbvwLmU6NlWrnQtWG2kUyL4E532bIJEkadT/sHZOOsOzF
r4TWUt2y4Zaye1Gh+8XuOdezf9OLVktJ8OGGrjal1Spn6Gd+2xI4UahOWTmoSIyv0i0nbVU21OEr
5gGL3qz2r9Wt/k1KIlfqqQYUirVVgIqcrkhBCpO46NrQyDgu91xU9K4q/wBDdc98TFxPR+c2zbFT
pvnv60xExeipm3T8+hfQvp/O3o32zf1r6NsXqvTbNsXN/Rvi5+N/QvynX8b+lMX3XExc/OGXF+aQ
3ZsINi0ka9goRunIfvJnMgjDYMlinQ95cRP4kqEp5Aq5sZ0h6JCjmc22eXevtk5y6GF2W3tm1gJh
ORHdV9G3v1TKldrCG/8Ai3cJSOkNcElFe8FdwlCtq/tZpEXbDft5snN4H0kBe7ZN5RbgfbLp8Xcm
NTjDvw7OiD5yahnCLqQXPNLnQT57kkjpK1YxZkhncT9oDVD5klaNsZoDtQc6r80v6fHHDbtawmmo
vdmv9hwCoGTYIkoVNA8NtlbtgvFPbOFFgDjkv7sYxwIKz5McfaBeQ0O6HVi2LQtKoWtixgWoyksA
+ayriJDjlthMknckoIdPjc+QkeDIbJYYUJo4yWz2PFCmNeFjRslTSsdHNCSZYRfGqYeodRqdzn81
0/Sd3GIgxarlNLJeu+fGNXNLf+cUDTLMmDhigW45iK0aSTSRuBFe1lxYTBii6cM3s6tnj7WjoqqU
v7RmOOJbRpaTAtpA9y8JCjx5Z0eeLrCTBFMsy2T9PaiUSjaKWKztw1gaj/uZtjcxqwdfcBsmajjs
30/TIEfFc1BCGxr0Qh9NxUiwbXZIlPZCkCKggEJIGUFYaPATUmqnmd75U3Ba4ldYisQSZceuCS3W
+svIjVkSDq4E6TqEYyx9N1jJOMZwZbRhFFS2wVZIgBmKWQGCGRq7/t4M0VkCxtY9WG5uz3B9s44q
Zt7qmbdePRfSnTf1p0/Kpi/0Pz0T1bYvv/URPR+PR+f6H5/obdN+m3qXouJ02/ofGIq475XoXH/L
F2dS3axFPqSMUVbeBjZaXqTkqrpkMa6iAVwtVRkZ+pojVPqgT3ydSjUTLFGyyaoGoHTGvlpqgAQW
Nk+U5zt+vx02zb3T1RDdo0TWABDmapjGHJL3HI7Za3UvhsnagbNWDq0MRkzV4pDJJu+tVqEVcw2t
mEbOm+Y+rtm1zl1q3jOt/OdCl+KceuGCbO1D9QwUp4Sg1e0KP1sxyOviOkC1r28TXDcmawdKbF1K
+Jia6RuTdXPloWQplrbx9Y1dbEVr7wrjB1kRmE1qV7Zc8kvIN0avQurZBhnlEOsHUZq0bddSUyTr
CTIbGvjxHM1pLRJWp5MlATZEY49WzGIbVcw7XzDKQGrZgUdrGcRsqceWoNSyoLC6qmmfI1NOkMi3
8uHh9WTj5+qZ/ANzKjllX8yY1VVcXIWoJ8JhNVWZGyCmM5egR8104Hs1txJJHBZ2Ew7oljIgqXUt
iZjL6eiJPkNMS6myWhsZcZpph5ORrSZBauo7UiGkEK4N5Pi4up7N7TTpEvNt+rVVisu540NLPJUE
2RFwpzzHALKi4WRJMrbiePPrtjhrCXJwe7lZNnMQsuYRBmPFx9lOK1ljMYjDSFakZ2eI9c8d2w3S
BYRZRs4vCppMl6NVw1JLkGQcuRHT6nNxZUp+C7g1aWwchUlPRybY2WdmEIQ2IzfEjrjob9nA44rN
s2zbGB5Z4jseFW45mK3F9O+fn0ridFzfOPTfpvnz0XE9s36bdffomLiYvRPRt6F9G+fPVOm/pTou
J8YmJ1X26JipiL/V+OnziJ6N836fjN8VN+hfh/yz5gRHnz6GqMj1SlWVUOjpDr1mI6i4YPT/ADT9
Pe76JzM+hOVr65zCfQ1cwsTgQdGhGyoTguezbHJtjs36LiL6W9As5OiUKyGm092myQ9pypgwKTPC
exseM4z4+nHOSZSvBiAXuRqF58kUKhaYHF0GjdJUmm1E2TDULodY6S79OORhqlzHxtOOJi6c2yXS
uFkOhdIz9O7ZLoVGw4FGqtzbOOQITpDmaYc0RKxWmj6XVzF021Em06gSDSvlK7TSCbPq1CrIqvfA
0oQo7Wq8N1fSOnOTSnBpdO8Wx9MvKX9KtRH6cRMsK0YEqtOEl4XTaMZYVbgq4ey9tcVmcM7ft2/Y
UVSO+glaw8ZRLx96aj8lg9KjVt7WpEeRqdI0jsFia2OzITZNsK9iIF7me6Dzt5wyip/qJ7XT4okc
o07tTSvsjXNEkEBx7Y/omNTdO3viCzt4g9s7edvbKSs8swtPR+GoITYkhye/HEFvlBptZqrp+Ntd
UXZw4FYvHGs5O0xQjOBaKNslJGyw0+N0oGnY42fQ4yrfUfjI8P7vG3xQ8cXETfBRnkynoizCx6GM
Advp9jhy4TgK4WIPKSpWeaPp6MAa00R2Xun0CwoOLvGXGA3Wi066W4dFFYy+04jWyo6ieuOzb0bd
Uxeq+nf0bZt0XN8239S9N/R8dN+m+Ln4T0J0Tr8Zvv8A0V9K5t0TF6fPo+PV8enfE6/Ob+6dPx0V
MImO+YjO6bT1KnbtzChi0+8ZHTq9sllVSoBLMghPgNG4JjBacihIoYou3JpGvMsEbY1sxoZ9ZIEY
dpUNKycLtlf8u+en42zb0pkD/bqgDbHv7RgMlF7z40RZDqbT7e3fDCFmla9DOL24rLF4iMq4yGsR
BHFBMMIrZDELY1cNoI0mQJ2XaM56ehNYGRLYzBiHIkSSJEj1tm+cafGHwW5DBHDv3zJE4I/GlQVl
SGacLh6Jw0ZWucWhpUhDX9yQY7X2E2S6MCpnlnLNhNkNixmQQhtWySWNc0gqqvZ5aL7arT7tCBoo
1vZmirAI80VE2yykvixzXtkuQWGtJSNZDjwrPz3Wte18ePp8kp36XdkvT6ibCoiSn/pJyZI01wbC
YOBMC0UkVtTe0gChdXXEmM+ARSw9X/5ifK432WuA4x6vmyPqRjlk11CslGaUerjaX/bOgrGLpWM8
CX/dfGiV75RqaAyFGsoflguYrQPJ841N8oqZZrmaTbtZ6f8AFSm015jSaTYqfpLiOwqnRy0enSNR
qft1b/tw4TpJW6SRkYNbxniE0AktjumGE0rE0531n0DgkiaS4R33jtP5Nvp1o+hYRlZqC4SrcbUM
y3fQV5oMbUkxrmQdKbi/S4Ey6052EkhVj62sJMLA08CJHggZHBcTpADRCKeLMpkkzbTTPYbWaUU7
K6uZVTLFjnw9OwJEY1qxXwomlken6YjZO000KxAtBGtJsxtgxO4PVgWhlu+VTfptvitxOnziJn4X
ovp+Oq9Ns+M3xc2xExen5zbPxvn56fOJi/KZ7dU9v6S9FxPVvi5t7Kmb5v6VxOu+bdV6b79d+u2b
YnTfonT8rn5X523wuE+afbzqhqeLqZfu1chRSqsqFjPXiy2kKSbUf4J0ZqIsx7Z8V3KOhGuV39mo
PaTp0jkmTG/9fbp/Jf8AK9F674nTbExMrv8Abql/iak/uYzmWgpERlvZNiCmy3SC6XCjEtGco1rN
e1+lx8nnbyDcSXBdRtWTKCidq+J4xI5HSpVWiNh6hVApTzXulOZ3QxQhAW5VVAOuWVLr64VaC4vO
6alr2Mj2NzGgOLPjyBVEUJSqvvjBqGwI1rkjNENV35ETdkeMwMo/+CfNKCVUlcWHq32Wlvmtb3Yx
1ErVYaUOPhJsUyMiAk5FrkjHOnIUIbAyXs7jRsQTMktYo4UdkcWP246lVnfpLp0Ygwtlg1JFaF8d
dpVX/o6wT75flc/NRNdCNWG78PV/tI0pPdMybJ8WPEOsiPqwTRn0lOfJW3/84VqWskaesiWcW5nO
gRZ8x8170xE9gMV7tLVZgx8s2I+DS/6L3cnYaAM8qXJSGIb+bNVfvsqGqaFu24p0UY5K4R4BkXI9
6opzQ91b2z+mxpBiS5GmaBu1taDqo55Jr6XRUDIA7+/ZWj01yn2T0z2TLaWEUAUR9pOqaplaHUeq
WAdUqrq6YUISRFR0a+s3102EXzY80vghmX8k1jG14Bg6jUAblypvntsr2JkqdHEMS8hyZYhvF7t1
ou013yvX5zbNs2xMRM26fhffGpm3VenHqvReidF6/GfPT89d8+fWmL6E6r0+c+MXPzv0Xp+d9uu2
bZ8Zv6Pzm23o3z8ev56KvT56b4vTfoq4b4J7OrHcZ1KVHRdTx1KtZE7sirB48d+zmXUPgel/17eY
5rwQ3kkA/bEJa+NYBN3Y2ol/ladEvlS3p4Fw7+Q/5XN9v6KZDXjJqP8AV1INXYNezJqLhkgVjD8h
k6G8DtJFe5l4qpFnqvc0uR/lynKkK2VymqyOSZCVfD1E5yka53c0+qrF1W52aXXc1k5Ui03fWdOZ
zDX17IqXdgQpB1JiEr04x9RhUxR00hcS1kVCVurpEuU1d2xC9ywuN/C0wwqPc9GYYiduOMxJ887Q
RpiqeXTsVkLVIXEcYTuUasOZamOsaBf/APYGNROa3S0dwQuI1qyibhqIxklHktAvL9s6yse8rZ5G
Q13jXU2aMzW2Jw2QF7+mdNt2uLcdYG0tiTSVsVxzwGKOFrBfvEXrCRVPVM4V+rxbu0X/AJLxdq6p
/wBHWLvv6IGqutG84Fm3gfRxE8W2gunjtqLxhmZs7gq5Wj4y4W3iB762M9OUOoThCMdonRSd0XL3
twLIAFvAWrAL5NNZFDKkaiiDijuXSbSNMZKD9Fe+wnzGQ49LXOsLFCqzLyD5kaTGWLMrNvp+sDKs
zRUUZHzXPSPG0yeYeLTMq5J91F9Bmy5U/TLRBqawVcDVGqe0xr+ZNP2YTwrSodYEGg4UaU79Q3AG
JEBJGk+PcVboR4mnCyUoKX6W2fbCjnJ7jfpuVJmSNNtiBqbEMwMuh8qYaQKAC8s0tLBevHNum3sv
Rem3TbNtuu3uqZxxfbPnPz6Nun5/OfPRPQ7ETpt6Vzbb1L0XF6fK7b+nbp+M2zbptvn42xPQq++K
vRc398Xrt6Ez8+pc/O+ETCYEnbfp7UPJknjJFVoMcqztexHprpTZNewqQCoEBBNOUxBhak9vYnyE
fZxpzWxbZ/kTakI447y99pB+653v6d/XGXY9NNTxrMIyNsURpo8wkQlTbtljvEF2tNjSOOzljeG1
Vqm0qFGrImD8e6I1xaACEkBmiaHUJGKsFiFlVZhx41/JERKmekKSOc2YMLQRln3zVOG0E8SDjK+X
NhiDDvWEeqAKs6zixA2dgkkmmGi7i2UftluRgmMsQSWMmRoiXmoe5lLqBDI+6ixxXt+6YtAkdzQ2
cVo7GdFIyK6KabFkQQpcamRo6q+4GFZQStddQog7jULpBKjUI3skamjBFNvyHl1uogEClxXjy51U
Nw6jVDHIlzWvyx1RGaGNPDIsZ2qwR49haknOzTs6tAJ2qq4Y724+oFd1pjAFIj6rrWi1FfRZaaau
g177vVopYqzVsWOC5ufqMmi1FWwAzdY1rg2U1sk1LerAxus4LW2+pDWxYmmHEZ+kl2/TDwoC6Sry
TrSG1q61ikDB1rECO21SSQSp1kGJHLrNzpn66gKMOvw9y+1GCfnznb903RaXUD65Xa8itHa3si0P
C1hFgRZmp5UuYHXcdkefaeXJg66BEi2dq6zPp/ULaZf/ANAg5/8AoEJUtdarLyDrwYRO/wCQYu1p
q808kvV5JEdUc53DIU98B4P+QwDDeauLcNodTjpR3Wr5FqtPrL6cKz1MlgWJrqPFBM1/3hPmGJLr
9dpEAv8AyRHy51ee3bWWZqx7f+RG8L69k3bkFxRRrijXovTbEZ7dvOPHFTETNsa3OOcc47p2s7OK
PO3jh5xxU6b9Ns26J89d+q5t0RcX+onVfUnT46pi9N+u3tm2bZtm2cc/H9NEz89OXsnXf0E+CfLc
jPc1zZ01zBypAlLJlvwJjjXypvJs+eifUrFMfNnPx8ma9qvJyWTN4uITl5cxzSOIqqmKnpVOi+j5
xi4CRL2cee5Cq7fEeRidwz8bJkJiFmlx4jJiEMzGFmPx4TNz7jMQ8xcSNJditeNe4d2dmQTFA5uM
ZJzxZePjlGrENniylwgZHFeaKryovdeufOMR2MgyH46K5qigGfn0w2EiPHnjOfjawyoaM4WcHbii
lLhYDhYwKvxlMZyfSipnhOV/0Qi4tK/H1r2YlOYrG0hMfTvajatxXfQSbvqXCwdUSTjdPlTPoL95
MFY+KDbFYuIzbI0Fx8TTZVw9c+Mj098XGpii90aiZxxGbYo0xW7Yo0fnbTfhnDO0iZAl/Tzg192m
/wD6LhP+Rd0sbV1o+DTkmpLqvCwjPZWZxx3tm2e3QI1e4enDqA8dQuRN8hUJZaSqEkVhR8F29uGK
3EbnHEbgISmdJqXxcVv7hD5vHpkxBSoqx1GFXrC06eSyXp00YZwq1ytzb22xG5wxo/eDRlnYfShg
jkRFC57VTExrd8r6Q03G6RNkvTRYyRNNnmp+jJCY7RZuNhTur3OTPnGBVy11Eadj9GnCOXCcFysx
WZt7jHvlfpg89llSPrcg1j5rhaJPsfRpxtk16gWv00eekzR0iMyVFcB6/LsXquL1T0/j8Ztti+n5
z4zfqvRP6Hz0T0fHTfOO/Reu/Rc36b7ej8elc26fHVOnynRUzbfFT2InsX5G3daWoU6rRNYGLBae
VMo0aGtqFeU1K0SQ6NHtfSIxxKRnENA0iWNCoyRKHmO3goE9dWMIO0pOKGAo3PxV6fjqi9FxOgm7
uoqBpQ2NUOO2wRvd4b5AqHycl0axw1kLzDRNPMYOyp28VhfyqzTzezNpxo2dD7RqLT/cHIpRNbbw
EDmn6TzF+hiYOVTp3ItCIYkgxnOn0ica2jEjXwoqOl0rHjsYnZL4rlx0VyZ2lTKGjfNIymjjY+q7
9iKpjR2MixDraUzUbTUCcX14HJbUuRaxTy4NJHiB1NCaDNOUjS4YUQDWQo8hgKYIykHHGws6uTGL
EmyeEMAwFgSSSoQyBhwYkIKzK5xC1giMiwo8QZ7KtY8YwkHdV6GsHadagbCsUCuHstFOgBZGYAod
VgaIxPnETBAeVW1Rth1xCY6I5rm1BXI6qImeG5yrXkZn0kqoSKo8j1pDYtLIx8B48+llcg6kr0LW
EEjGKjtNiGKDqlzHF7Kvc2okOR9MZMOBWKqbLtn50+NCTSkG2DbO3kRRr3KBd4eomo6vWKsgiUUj
H0x2IKsIV30g3J9GdEHXvV+nqdsUOp4HkBlRHAdTD5zO+wUK4cpJmnInlzv2hYZwZQLCueYhoLwY
CpMdhoLwrFhvkOJTmjpSVHnSQhFXR408NgmoKNFaemMmeIvIVMZjq2bCr4LdaJIl8fIFEs4UTLDW
44pq+b58XXeyY1m+V1USaQOkXiLGjCrgQ7cFg/UFC0wyURsWC5CfQJPHTdJ5ckAWAHrxOQtIwxjg
3966kHT2TrSFY0o5c7cNXErbUNwLVNC1GHXYi9d+qdd8+eiYuJ13z5xei9FTrt6l9Xx1T1/jp84n
VM2zb1/nPnovT8+jb2+cXE9sdhv7SZH936XgMSPqaa8Da2y8eRDXzRCgDE7UFgoloiqQViwncLYd
t0N/cCQLS40aNTUzNjU1k7vljoWFdA7cgmL8585tm/Tb0x1+7Qf6+qSE3IvJ1XVukkhxB1oNQW6H
dpWPu+duwEy17WVK+VY8FbFm2ax87/nTK8XbjWcx0V9jYeY7ToO3EtSvAsG1aeTJ3LFrq0o51iXs
xp9zJc6lrDyS2c8cOPBrXWhv0+NrZFMNEDSKeZEishCTAfas5olPHpqt0MhdnZ/ayOp/OMxHhZYB
rZcKUk0Grl/bQSmJEtYf1B1fG8SNljH8mObTPueCWtw9lMNmj6kgn3E1IkZbGZOkVdBxOV3AVvan
aSvgHs5AmtiRr+1/n0l4yWOZXNlitq/xnD9zUv8A5+sf8pflcjicZ2ntPhjxTwQOeWujx4tTTjOf
xAIj64D2srI4pf0mNukKM/JunkOYNfHjsWMFcsawKJFgR3hZEANLKsEWO0Y22NeEPjarjtYTS9Kw
iGdEit3iSA6hAMRnO98b7rpLxObozHDtA/y9P6fYMbODXai/fX0VSIMftswkYZWwARgTnRY7MGke
SORHjVsuFKEVllNjxB3E1kqTpU0YZ+yxyXzO3N0ZE2V4/a2mPgyqcDEg6tE0culjCHX6pjok3TlI
kbLKC2SDT8B0GdYC70SqrUr5No5GQo7o06OKgjjk6isIlfCDCfZSqOgHXj1PqVlcJznyy0VC+WUb
RV0TVFyy3nVlS+aWrqh1gRXDJtpObyi1tUOBKs38INdLj2MZtDHbKvrWJUQAXUgEmilEmQNe/Gji
PdCmQQTGxwDjiG9zpluJDxaWtHWm1X7VBvci+r89V6fGbdPnqnTbNvSif0Ns26J6HJ6V9P49H46K
npXpt6vz6U6F+CfMf2Lpl28XVackFv3NNuIos1CN6P04v2bCU0TJu5pNXukd1x25AiIRNTu3LVIq
Th+9de/5iLjk6J1X07YH/Jp1f4+p092t3NRsCAN28pGHa5rtLTWLlgRBxbOR3ZOm5bAn7n2NQn5F
qZLY8uAXvR9VTE5iMgpVBJQ8fUUjgOmb35e/ixI182RMsBdyNApfJlTJgquPOnEmno2cY2ppZwFH
qR4m0lwPZLOORyLvhGtNZyj+MGtu1nnVu6u9mvmN8wv+O2X+Zp//AM/VibpHsywDj1oVMqpiz4l7
ZPr0XV8tMoLd9smoI7Vi0dWk2ZIIyBEt7UswsCSeESu1JMLI25hswd6fS1rIMXU90rHmer301ceX
JjM8KLqeyEUoFV0il/8AP1kvEhfZcqP9+P8A4ISq64tvavqP9Gdax67P1XGdg57plsX+zT67phSt
CMmrobHWl8swNCqrXajnOhPla4E+KWQsg2nU/wCq1h86cXer1qm44pp7WzWSXrwzjnzmnm/zlxWc
rpERracriSr/AP0oC7RLPUYKoiareZtJJNKvZ/8Ap6d/0taf4tL/APmaqC47ZNYSPlSi+c341Eip
N0gUiTpH7QzFc+xqV3rtVp/Oqf8AztTyfDsqLUSW62lilfHoLz6xY2TnNh0Ek0w+onoyr0e0nL9v
Z1EAp7OhphwQ6k1Clc0lTLmujxO1KrY7Y8TXFuUhaarfOJWVg6wGrtV7t0I5WSrHl4lNJkyp14RB
1WkBlWZ+3s62jELPYP8AdptP+s15/bpZNqzXJHtbpnf6X3E8q+V6QdOkkHfrIqBpuXJcRM+MRc+e
n59K9dsT0pi9FxM+M+eier8L6N/6m3Rf6C9NsROi/PXbrvm/T8b5vj8LvyF7P0vbDaC0CkpkSFtN
iEbDix7och9uBshtEziy4EpXhquLIuzGXhOMyoL9nUmzn0cTuElS2xItxJQxHLvjs2z4xcTF67dR
J+/ThE8e/i+Qs0Pjvqbl0VwjMmCt6xNtKR1Qtom8a1HwNp8Pcmqm0O9FxJXj7surYrIupI/J3DuG
02PhG1ILuNoydqeczTxoNYrJk07RjjI1orOtJOkM040TIJWBbbQVmuBptrR3I2DJTx+9LAnELF7F
hKVJIKmqWKa0sGQWxrRkwcerZ3ru4HEBHA+0NWA8eJdw/JbIrldIg6WR2birIvktt5RKVpGVNb4D
dUWDRB0aTNRnayIHiSbDqQqAGn0ZJlyGxQeWhboZWsi6gPzk18RZZ6qECoiai1NzUh1KtDSrMJFD
2I+sJLSmeu6/GVpUFKrJ7JMcERAlt/aupZ7HDnVbbFw6mJBCh2Ou5clg42mjcslWoYpX8ZscGno4
3Xvj5XB7UPVA2KA6pzgR1lmrAdmDqljVjaatBdiZXJPxK2LABqCUEx2wyvzwC46C9E0jX9ySuW7x
RLSvnMnxxoGEWzVhYtPZhkCk04phDMh10epsQnvrmUMEDTEhpIOtZrc0lci7DmjdmqrWGi6RieRM
zV6DGXRkNMfx43z2BsNN24pEc9eGW8bEYzXD/vwrWVWum382ySrtHVhKe4FahNIjV4Zd66+smvi1
MODrEMuZbjAQUQrSRi1cQ5f44RzpjHXMOUJIOppHlWGjJYI7NU6ueViey19gWIekvxWIiyYsIVnq
Vbmxhuh1VcHXQzWlx4suDpmJFmSY7QRxWMaJMZTX0eLLlx4czGlh10e31m89tT30ezBOt4VTEv8A
Uci9lLi9PwidF6L/AEfxm+flMXqmfnbPhenz60xU6bf0UzbNs26b9dvSvzm3TfFxM/CdU6Ji+3Tf
bHLjlwvSsmkhkj6oj9v6yPypepxyBQrJIpyamCTI2p4sdP1TE3kaqCrW6pGFJ9n5b4upWRgWFn5Z
YGoY8INleOnKR3LPyq9Pz039TF96zVAoQzawjFHPmeU7l71106DkzVDJzIGowwWm1sMjZ1h5j6m4
ZWI7W4VbPuEn5Xy2QiprhjGWOo0n4I3aLF1myOydqxJieQ9pI2q/HamuWZN1CWUYGslC1NcsXJOt
1MOPqN4CJrrbJWsnmbIkukOrLL6eT9dvYknURZJAazKBHa4KRJlmaZkK1fAxdZnIyVNLKWuvH1TW
a9kohdbSJDA3Zo501xKRJd/Jn4E5YxR6wljQus5ZElSzSlg2xqxJNyawVzVVYV9LgN/WVguTbibO
Ub3CKTVEx4yncZ0WcSASRqWfLaqq5cg3kquGusLIiSDmkud85GGhS09c6JGhtkc9Qy2AgpZFjlTV
lo1DX1lMRpzRylvZx2x7SXDSRPkyyC1LZR0fqu2fnnyXkZqOzYki0nzMVPcJHBL+pLJuSLObKQBi
R3JqGzahbKwlM03BjlK2HB28KBliKAEBLA0Uq39muGklOobSXFwtnMkZ9SmOYGYaLn12yRTWUuQg
yPDj50o6DmyANIYpnDe8WLaTNt3EcB5hK6XYYVSuVJZwp9Umrm6vdTaYeYMSheF1nZhqQXNmS2lb
dRnMHCSDmxjntVSmKjROwjj55cluebKx0iQ/GMdn8pW9hzcdzTHJjW4iY1CJjmnJjh8MI8j8+McU
zs5vHnkyN3STuzkqYkk2ziEfnxncfjlc5E+dt8XPz0VPWnv036bbYub9Nuu+2LidV6pi9N/R8ovo
Xov9LbqnX8589Nts39Hzi9Nun5/GfjNsf7Ib5yCBxcBQc2uquJyUa9plerypRKjA0PPHafx+n14t
oVfkqqeDI1O4yTK7xVBWKdsyrfHRzNsd7Z89F9+qpm/oTG++V1M6U0mmnMbLidhy/I2K9fBciNBu
6Jp9xmyaFwmvj7PhUpJCG08omnjKF0OrWXn6Z4slVzgLFg+S4emndqTTuDkSheZP01tkqkcFItK4
7l0yqZJ08rWyY6iXh78M4+8eM4r4mlXqGXWKE0LTL3tXTeTqRQ5DqXyiJpdw2T6hQ546q6s0wSUl
rTeE2DVvmkHpNWsJpvjjNOOKZmkUY12l+OWFOkdtdpN5mrpVGZK08qZB0jux2lUTP0n+2zg+MZ7M
7eDD3HMpDcDxeznHZaajfOQWkmObe1XhPe33XEXZarU8iFlTNmWLNTjJ3Vb70tN52F0uxkeeBBP4
YglxR521xB529siwnSnv0r4kCWHg5rffT+mkkDv6psJePvQaY8tpNNB7dvWuiPehM2JisXZfbq1m
dpVxRrnbXGi3TtZ2lzt4o8VmIntx2UYFetFpfusfQRuFzRujPKBWqo87e2RtQWEMX6ts3ZMPJsFV
udpyY5m2cd+g28lFBI5aTTCERdPRON5ROiuIH9zhZ21zTWnklt+iQRIfT8Yo7urWGbhyzt+8aK4x
KTS42ikaeiEFd0ToRCs4YuL74746/Gb+j8b5vv6Vzb0p6VxcT+hvm3X49O2KmJ7dF9um+beleiYv
pXPxt609KZ+c+c/O2fGbYvx+cd7oX3xvzpap7+SRBr445TJNgwTDhDR/y7FBxA0xhmywKMDe+NzI
YROSdVMkNg1rAt1PHRFpJo25Jr2yxWsHxikTPxm3RM3z5xOm/Ri++lhNUF7Yshtny/JcEHcdR0PP
LaLGiApovkTGgHFjyyCI0oWvs66GyPEkyBvy6Rim07AGKPJkjat+8fa0rAa5sk7I6E7UkrWtixx3
TyzZUYbgNsY1YxmqXyJHba+LaRfJkt08RUJQubjoCoTT2n0GmEjNNbSCrHj1lwedLnRkOKtr2wmf
WWKebAbIHDq0fYDRrGas/wAOlgNYC5sSwmVEkkuIjURZx3Rox9Q2XKukGsppF7QodpMkWBkRGTNW
Bi4LVk2XNb/bYRXz536WdxNpvtsitFXyguBKBcU+7ZEVQur7mVBWpO6RC1n/AHG9s5YnvkKOpTUv
dDF1Ox7jDApn6dpZETHe7ZUJ0uaDRyoN+k1RDUL2mXSznMFpFeM3TrxOoaVIuHF3g31UkXAx3GPR
jLHjaoGTuwR85cIXZiS7TwzShLfybXTnhDqKNbI9xptIIDM4r8YxN8p9Juki/R7MstL9plfpZTBH
pD7kjSjWCrdL99bOg8UjNIooLCIgCVlY6caVpNoAUsBr7QqoIVdZSSzZ8Zp4/wCl+8wtAVJSaQaO
PB075pWaRjtyTpQXbjaffIlt0eHYmkBKltWLDVo980/p50xxKqKBHr2xV9hMfZzANPHZpdshhtOv
8oej2sCTUhqdY4p2oZsULYMS7ltuLaPo6Og7DSQmh0xBak6eZwImnpMskm+AwlbM/wAuL8L1/PqX
0b5+ETptm3T2z89ffE6bbYvRcTouJ6F6bdVzf0Knr/OJ6Fzfpt7dFT1r609sXE9CYuP9sNjfnRf7
o2qf8aPVr9OS+63NUn99Le7Jkdpm20hY2URFeFTMR2atTZ0R20qu/dE1Mn3zY7ExfVt1EnvpVfs6
qTH+7tO0/eWZJZWgsZ5JBNKB95DUcC4kqF9D/IlBanZvTeM+GrpM6tRrYmotgqUzzl08NBxLpqdi
JMf58fc0YcQI5Fi5fFPGfIl01KyGK+vEbmn4LXss7MFa1tpHlir4oZMt37UySNQzlTdgRxxELvn4
dFaySn9ltIJGl6cK8sDViKo6K88dVlRpKRu2gjSGAwk6IRrY0SSsyF9PWPchMKIaI58j/XsG9yXp
3T6Cy6umQ20gUaC5v/pKpqIEsFxKHILUXD68kNG2EXUsFsdRr9yi/wDN1kuzzL7r8plbOWFIp5Ky
4GsP8mlqVrUlTUjlf/ZQAa6RnFcuZzIhI7lIBtg51lYoni0t0eZOlGWPHu7mRONGkOAelkOl1+sk
3SiKIcwZEKPWMtjE0X/g1J712j/jUn/myP3O296UaEnCYjB2GqZkafN1dHNH0lPLOZayXxYsUilj
NaiZqD/Oz3ZYsQ9tUVgogiNY5vjhjW0j/EEovKlLtFo7xTyvHcualtnw8pmIyB7JimG3IZBHdqSw
PABW60KFLq4S2fp3Tr5Tykj1EOuviXd2b+wRwONJ/wBeku3LYdrlmq7l8ANRSksTRIYqyPqbUr5z
tM0jpjxjaBqZW/tvbFyMiRJgjTLz/wAqV/m475tm3p+eq4mfOfPVevznvm/Xf1qvtidfjEXF9s+e
i9PynT56p7Ivo/Hp26b9duiL1+Ou+Jnt0/Po3z5zbombdPjN+r8NjfnRRmpH1A3vjWK7ydOQuyzu
t31BE7qabYo23BnCGsYk5acXay7mOjEqJvkC1Uu6whqSRBd2ompXopCO3Veu/VfQ3E+dJO5B1Qzf
CDVj6O7TjJD5Y7OscJ2lyP8AKluXwLZy9+pKrZkXfw9Qq5TBI5pqLdYuqXOV5FVHaQc9wtSqvapf
/Re7jAEpfqxf9avrGtdf2LmY2rkSVpB9qPqgamVlVIKqSZNKsbWUp5YxFKB5VdazVVI1IMq2BHox
O81zCDkGnHegAWru/K02NWQNTDc9kgKtcOtKbNOxXRa/Ub/JeWiexmkIrguvno2AWOSQfS1ORkq1
kICJVcZNsVeyC2kONYUa/wAHVEd8gsXTBZKT65I5NOab8hbKxBUxrW4fYFhgeUlKJQ12s1/eVfdc
TBJutAxWVerRK9+n3b11gNz7In9lGnafcEMOPGiW811hXlikif6wnb6gtV412mS/9nNGposnTKjD
ID2z6fGrKzVwleyG1VmRG8Iurgr5GiXorLwLjwtOQnxGaj/807fudtco2cJ7F+1PoDS5aaR8aPpJ
nbfax3SokUXajiOhXXEZxzt/a3UIXMlactfEm22qIbYlDZqy27jZseuo1izr2yHCi6YqndxT7ZqO
sWTlU5HQdR18qbIiaVKoqQaRk1HCfOHA0byammBDnGPGp4modQEuz6enNhzByBzwQaDxZ19ZigRN
NVDlMshjH6kqVnNoQNDA1FEmTkr9HMGGritgFvIhJbY6cRPP9NvDNHZw6ijbXE1ffAhQvdc2xei5
t036IvRem+b9FxfRvi5v0T+mvVcTF6b9Pj07erf1qmJ03z4zf3+evxm/T4/p/hOie2Lm2KnRckZ+
aG6dEWNMbNFJaNk5s9keEy7d9QfKYQFYqMdL2kY1BAFHntauo5SGShmo0OpZjSpRR2uy1uWRhTpj
jvd7r8dF6fjFz8dExM0rLaME9rJDLhjGPGZwn01/3MnvA8On46ISTMG4F24bi6fChZDJQ2A1AQbl
rhISZXSBAjagkBcm3I9C4cMFxKAQQZKRp0GybLCwIGEtr8Y0g2wnCekUxCSogAx74feUgJOFsIUE
d3ZskkoWDLKBYRmBn2wgyY9mGSMZocd17qJqsp7/ALittYoR3mpFPlEgpD40+GIU2bEINSRpNlFL
XhS11OAI4V7wlAsIRGJaQIrdQajSWtS6vYB+oIUMNvqB859HLZGl2epgeLJk96RRajQaJcVz8nas
iRY6WY5882qo0OHZWr7Ars01KrwsXU1aEeobpJ5nYvSqeEcqNqqrCDUGpoUplBqdoMLqutRgdaQy
j/VLRzR6rrHtJrOsAOy1I6ylg1jDjw4WpAjsrfV4JceHZEhSoetYSButbtOOFKRkyPrOrAG81dCm
Bp7GPGlN1xWI2+1HHsspbQsEw9ThVIkpJY9SG3AzSpSN/R78TShYyg1Iyqauva1MuNb+YPQzXqKV
JbGFZa3YjKrUh4Rya+gqyPrwSZd3TbR3D2Qe2I9WrSarWvyT/wAhA4GtzS7FNegBF+vy3zn65E+P
VatfXkT/AJCi7TdfoQMDUEiGf/8ARI2xf+RBPZE1Udk65tzXDuONfxWm1U+oeX/khjmSLU8yWLXz
RRHXEw01uvESNA162KH/APSA7v8A+SBNx+qpBrH/APRE4i16Uci61F9byk1SWoSX/wAguMGQ58g3
DOGKxc7edrFZip029e3RV9K/PRc+c22xU9G3T46rm2b9UzbF6Ln52z8b9Uxcau2Lnx0+fQvwnTbp
tvm3XfFzf26/lOu2fHXfomfnPwvR37UNi4DIx5jGK+Rv3JStVXo9pprsQ83PIskxxrBc7kvYqHVR
kkNQrirjCyUx7Trjvlcd0X36p8fPTfqmAIdM/nrhu7i41zm42QZ2IYzMYWYTHANic2OaaW5XRjri
o5mI6TnjyH48TmY15sQMkiujvbjBGxI8zHxzJjEOuNjStnglJj+Tc7hc+4ubYjVXAxpD08cjcZGM
9fp8jCRHsTtquJWmIj4bhYgnPxtWdUWsKiDguc5Kc2fSTYeI4KK3FZ07e6gryFx9e8TXjzgiYjds
DCeZSVBWI8PDokbOHHNvcUN0jG0JFSVXOjNVNsXoi5wRc4ozFXdEY3Nkz8dlMaJNuPu2O1yvqXjE
QfHFRc7aKvDOGdlExG7YjN8jVvlPPCdGdpvw2EHOqR5ZathxApqOQ2e3/kYzc/8A0Y2P/wCQpBGT
Zb570HgGIjqS4rYUWx1FXkjTT946++cds4YNiqsOmLNU+mygYaMonObis6NHzWNp2RIHMrnxF2yD
TlmpI0ucDZEftOVvujfeFAfLc/SMpg5UN0Zdtl3zb2azfI8Eh3C0hKc2wqnw1Ue2cfdU94kN0h49
Gyno7R8hqDpDPP8AouUqJos+TtMHhNi1L5hV0TKaybXOiLHrnnezRUp47GlJDx7dsVMXr+d836b9
E+dsX29K9d8/Hx029Pzm3o/OL036J/8AEvVPUnRU3TqvX36bZt0+c+MTquOTfJHyib5VQFkPrdP8
Rz4rGyQUjHRyU6+YOkRI8OqYR5KRjWtqRuQdIjyWen9mVlHyy8q0AlRBafJ1Mjhy4Sx3OTZXfPRe
qdPz0amaaqElNlUogsumDa7b3hV6ncunlGEUXuS6zTrUDOphqydE7Eil08hWSKUTW28BIzqGl8vH
UoWMu61AtpKvzCsogCHOqG5X0DGhWFE5S6Rrh1lGNXFiQx4SoYUNtB7JPHdnjuxwlynqSTjRaKPH
FZ1iedEpARg+PCe6ypmdqo073i/TYzUsqVFynohI4yV4M+mgkMh0gRlMKKJhJdY3LqSAuMA4i+E/
Hx1YgGIj6SFHfG1LDGMBmbuSCR2eM5i6bHEKlrBGsOdFVCQoSyjj00wYbKqUDlFs7T8qDHbC8aQH
Vsdg3m+VX3zbF6csb79Gs3yPAKVPpZsdFcxdN0KHfeQGLEkgc1zIryu+lGwkNw8FXlLiVxVVawzc
jQnFJR0w4cTU1cvkyB8VVvtxRuMar8+mm4+OvL6aVGsr3vVKc2GrSiRKt5sZTkc4lQdiKFUUUVx1
fWlE2kp/OkCEGtjjOGwHf0vbwtYbPEernVZWt01SeUUIkYPWKbS68SSJMCK2HF74ZGX4RtnDpJD1
WjkNyklLWzUXfNQ1pVOYCszhtkeOpSRtKkcCmpBwRmt44ZNnVsnjkUxUKWC8Tx1JjZppIte+01rH
hrS27rePKUFdMstXQoAaHUy3j7QXfh1laOuGG9jnnXVK2aylo2QRyb2PGl2VYOzDdRPCMufGb5vi
KmLidfnqvv0/H9HbN8/PT46b5virvm+b9F6Kv9Pfqq58dN8+Oi+/VU9C9Px+MTNvbNs+Om/oVfR+
PnHeynzfbNGRmkbbO8eKaa7yqGX5I/BHyupHixaKQpXT2q8RZSxGU0tJSKm6DC0eaob+2HNfGLW/
yganjoJxU919sXr+eiZ8Z89EzRy7i1Ry7J3qqwoDpJKmpZADf3aNSiZ35as4xZlmsZUP9QnQB8It
lMfGJOnecSgDwi25Xx32VqkjNJxla20c4Ym26LJY/uRfpZVnmXtRbK5kNLVwJVoY8hlbEDGW4lj0
0FjD0gkQ9L3JVdXMrgpktvG2M3vx6+mWPNkKnbExGNMsl1i1qOHcWJwGq6g1rIMYdZEp53mpcQlm
jJpn3FQuWTG05GAxaaMuXVI1gqTT3k5Hjsij1N/qUdeI6tp4/G4pWjHpL2luaj0tKZj2zIz4JqS9
7mSoTZg7euWO5E/fpv8A83WXyf56rm+bYmNX303UeedkCLHGoIRckwoo5UAkdw5LxNZfSgklaaDD
eLwwKl7UsC2njRDhZXRgqWAA7Io4UCSNWvbdy4gI80yFMubZQuj+U2FGlR4mmxCPe+MMVbVhiR+0
zJteKQKnDFc14IkVHxQSg3Ff2ZmnKNAZbVzZMfTUN0R9oHyItLX+A+0UbY7BxZ0eNp4IZGppkOBD
qtQy4hIJnSYusf8Ac0rCSTLzUhPpcrTNak3PZMVrXJd17IUxi/YIwcod/Rdh6RXPNp/TjQstrYUJ
o/7ZNMwxh/2wpsfy51EGY9oo1XF1BYDs5NBp6GeNFiDhj1w570h1qyDUNOlaGbcCWcZPtxqQUeS/
GZJphyjxv8WsV/7BfQrc/Hx6V+NsVOip61TN/Qqdd9/Xt6k6/HXfE+MXPxnLNvV+em+L7+hMTp8+
j87ej8J75+ej/fJGbZoZ/wBu994shi97TLTK7NSDIRNO7tfKMgWW8hJCac/YljYrEdCmpKZqpfto
u5aH2BqxfcuL74qdF9uiL7fKonRqZtt00h/j1R/jkfOmhCYOzK54Z7XoXTcpgjIX+NqCR3ZFTKbH
l15u9G1RN3JGOgJNDJSQDVEngwi/d0vYpIHeG7UMa96wgs7UMmpOE5/8iI2pWZOVQ1Ee4siTiaXZ
tH1OYgmR9Rlitqb1hDJcwy4x7SNseLpj17IY+oXyZpWcm/iXPYI4l+2+rWxsiPDURba4fYEg28mr
YmspaZRWL7MSBahHvQbXX8Fintw2BNkACokOkLqVOUejqBx47ZIlLa/+fpj/AH7IqhiVhVkRdXBa
J0KIWTKrgOgwtV2ICkY/9+nP/N1l8mXdevzm3smbZx/dUWhYL4ksc4BqztjuGSmk0V/ZqP8A8+PW
vJIgQRwYkaeGWTUX/naOTL4zgV4daMigkWS2FjWf6Gq47pM2REePFTOOM9s0Y4hIy7IkvuPu2L+y
Zq2PDKfVZTA0g9xS6i9q+r94F5NSBd0moB3OWdi2sDp63S3lWplBG09LNNfqd6NrNHdxRrx21Gwp
JYW7Fqv/AD9ZJ/IpnvbNYu7dSvcSXpFd627um0wg6yNISZPkz7AX+Onc76nft5V+nqFB5qDULKUc
OWWdahXcMiXJ8sfs0vM94JEQWsGPJDBWlKj4UyLmkHOfB1q9GA0TEGsbVNm+ug6ZkK+zk/4oJ5ZZ
soiCBFf3AyZEts6OnAOqzoSzXonRV6r136e/X46L6N836Lm+fGKu/XbFXE989vRti9Ns+Om/9Beq
4vxi4nXj7Ztm+bb9Nuu/Xfovp+c26Nzj7rm+b4bE9l0lYNjPJKScGxg8JFGJIwDagayQciTAVwO1
Ksm9wMSpTIrGCfqV6KPTMjmzUpE4wIvkmjvSDGv56SHEdi58dPz85t0T0Invo5/2b0flMsoSxlgW
D4pq+zHLHaVrStpYqsn7bQb4KsJBGr5NYztxNTC2cxvcLpsXCLqQHcwqfc0eDgy8H3QjXsW0eU18
P6UrppiNixK/tqO3gEnli6Za1kBw4hLeJ9QyJpf9t/GCHIcfuSKsKggzU42DzNOCHTKOdZTGxAwr
tkxralhy21oKvFUPaQFvWvschaXBHYSmB3z6faRKiB4ASWgmTJaeXGj6UGr5QI1abyWnDXBbEbbo
hWQZbHiBEQM2wchYtHsKzlg8kEULYUa/mJYzqOtBVxtR6pwplK+jp3WL6+L4kXWcpvcKvuuJjBK7
GxH7JGdniuzxn54zm5p2OBVdTtOMAlCPWE4G+kLUYceEcxt1IhQFhzGTAxwBr32yNkRdOwfFBbi7
kKfxQgCdt+n7QcqKaOFrdQzwPMkMjs8ImVlQ88kaxaeDA1PHsC3QwhWuningdp8BC2poNdE0dJaW
TqmawUOnejq7V05hbCtvJFTljqKXbJTW5Kp9bOFaxymi1QC27tR2fOLTwq3V8ewPqKOBwNO07JuD
Gg2W9eGQ2ghjkWe6Jmr0ECTpO9EJJcIE7BxoVeO3vI0y3jkY+OOOCOSzv4xZd9qgNYGbMLYSGEc1
dOap5J/G31Pq9gU0xGjCj3GsQw5ALCJawodnDrrGRGhTcEkSvFrDUTLU2ipYWRde2IlHHkqB+mdU
tlM8iGHNT6vJOJpnVLgZ5MLfVmse013J7/nrtn5zbFxE/o/OfPRM+cX26bb9Fzlt0TF6fGL0TovX
b0JjsRMXPnp+Pnrtm3oTPzvi9N98TqubYvXbfNvRtn4RM36Iub9PlVw6bZ+QPVjqrU/jMlagbLcm
qGtEWepJAtT9pkfVDI7v1gB+P1iJzU1M1HWN55iVt4lck+/+oJXXDK9bDUzpzTFV2L74uKuL0+MR
d+iJm2fnEXKi9Ssa7XIlydb+fjl94U98Mj9X8xQL9sRy67YqWFx57q+ckN6a6TjY6gWegD9k4db+
Oybq50xqk5Eh6s8JknWbpDHy3EfC1GSG1Nc7ZO1MWdkbVz4jU127Z+ujEb9eMh2a7eFJGuSnZJnE
lLAn+AZmupDEmajPPyNqw8Rq64kIk25NYLDlkhl/WMrjKsDTFi6pkQWfr6UzHa4mlat1J8gWtZzM
Nq+cZHziuIDVk2O12tJ78lzTTCRdSy4YyalmSHm1FMOOJdyoOSdUT5DXaml8I9tIilbrGyaknUth
LaGUUEiRqawOjnuI7K+6lViLrCzVsiWeUrl6BRHFp9OxkjpRREz6LCxaWHn0aHn0WHvbx48ETtS2
QXF1LaFa8jjOGR4XpqGyRsg5pOBuJsNprywk4txOKwV1YiQ1xZnRyruvzGnniYW5nSGaXhxZLmRK
1E8asyd4MUNhYllPE54XFmyjoGdKiN+u2WxJZ5KjkmjI+XJPjJ8tjXOcRdsRMVdsZOOBHSpB0E5w
nd+QfGDcPCnkla2QcKLYTMWZKJgjlErp8xcQj34jnNVsqVjzSX4qdtyTZLcWbJcjFdujXvVAY8ap
ibtxZEjOHv3jYuIR+Na5caklccyQmKzjivImK53TuO2UxXYnsnJc7pFzbpvi9Ns239Hznx1T4Xou
J8YvTbqub+jb17Ztm+flM+MXp8434VOn5+M+c329H56J1/HVEzb0fnr+d+i9N8/CdFzfbovR2SOk
YfN1fTOM2VT+PkejUzJVe4JY9K4rW037/wBOeyUCYtF+6VQqNsarcZZlKoGxoCyVPRqJpgKxVTbF
zb0b5vvm+b9Nt8TK6u8xyaW4pYVniI5MYxXKyve7FjOasCifJwunFGkmIoXQKl8lXaaVGzICx1jV
7pL2aYXtz6l0bAxVK6Lpp72zKJwch0L5K/pnZZWn3DQFM8xGaYVGm045rZkNY7lb79vbOOCApHV2
lzSRT6pYjq/TRJTP0qqZMoFCwVY+QYOk3tDY0qx0fHVFqtOlnLZUHhsaBzy1mliSWS9NKJkiE4K1
OnCzsLpXttnVigdWUhZxnaS7bZ1OonwNL99tvp9IQni96TTTpyO0i3H6Y4tt65Irx05nsPEUK8fe
jo3WJGaQYuX9L4GPb03zy5KZ50pc8uTnlyc8yTjZUjKOlNbKukxsDYxUAZW7LEieWUOkBii2cdoC
cM44MSq6n0y0gLugFGiSR8VVvTfEV+NY/ZGE4qN+VtO+wLa6aZAhHHwcrM7eKPO1nZ9uziMyk0r5
rb2tZAM9Ezjvnb2wQlctHpZDsdp2MjLmmdHeQStztck4bYjcRnLO1tggq9aDS6HZfUMeNCP87e42
b4KG9VotLNe19BF7d7ROiOeDjnDOHv287fLFHxzTVD9SclFXxm/RYR01FSrBc/5dnxm/RVz8rn4X
pvtir03xfXv6dun5xPXvnxif1FxFxffoq5v1+c+PV+ei+hM326/OL6/nr89UTfPj0OyR74n92noX
kHh17Yca4tELIqDjKCTSqZ6RWRIsSYx8s7kaAMxuR1YYx4gzNjVKAJqIKNDXTWRTCa2aO+ruxhW7
Yvz136fGfnqnzo1jVbbykiBtLF0t3HktLSrIdKhRocZjUkWNfFbHhyZjMu0G8un4TRx5UxqP1Co3
D0nCarZcpsfLgwnh0xDSQaSZsURzhPkILI8eVeFSYgUNHSfGrHn1aQxYW5o18xpZItOPc12nnpki
ucImndP88ROLbcLS2fsGOG6lFmSRNeGsrGRslXTQSSxGzRPq0JZRRsADUv8AqacrElnnzG10aBOb
aMl0jTF2ZXxYVv5759S06QITIAGXvclS4DTjozuflpE8yPYVD466f9q7UM6VFwtzbqjJpVlwpEeb
Gt6drklxlC+HZyYS6dkEkwNY4bFxM26b7Zv0avvpuSUUz5HJ06+QWyp1i5RwClkmSQsSxa5T1WlT
TGm0n2U/Sbgi0u529rGWXFk6WVBz4fYIubZAhvlGjaM+27R7USTp93k0lSlcydE8oN5WtgvpNOLY
NTRo0S1o1iFrtLLIEzR/N0nSLBBrNNuOaMFAhuqVs1s0LBGqKt848rSDI4KKA0tkd3jx6qxkmmWU
VsiN+le6N9CTyf0Y1oK+kbMlt0hHalzplIral4Y8mvsY0tNSqq1h0/c1u+af086ar6uLGdId2QVM
6aSysozDxW6UYYT9PP8AK/Rgmxq+nZNnM0jFal3plIzIl7Kp1eyyv107BfXw9dnRon/O/u5c9tt8
36Ozfp+F6fHRcXN8336flcTPz8ev8riYufHpXNtvSufGb++b4q4i9fj0bdPx03z567dF67dV67b9
Vxeu3TfoufjN+nxm+L75J9s/Oi1/ky/9CwX+TpuVxeNeQ70vCNULvO4o8Fs5oGUEhyvKdoUGVpU1
D/rHXiTTbtxaqT9pF93YuKuJnz1+eidE/dmjV+1qNP45/wC6grPMIrRVsW4tHyiaeYhZAURQagJ4
7oDvJm1qNbG1I5AKshTSNPtYONf8Wx5ssj10oNg0skasORKcybVPcaIaPH773/xrSO48ui0+0CXl
42KLTkfziWU8daIGoQS0YkedN4dobEVEthbHD7gRsRhpG7hi9mSozO9F/wAOpCvDK0kchg6o/wBP
SHuyzChx1jGsXJKI4MMYxSVxf7ewMR3/AOOgX7siQ2MkiKycIFgCqwlzWHxkSLNHf1iQ3QLMlcar
elnG1PBZGaq7O0v/AOfrP4L7Y7367bdNs2xEyg/3m/2RZ/kyNSBb4dDPLGlJ+5pmoW3CxBAgTHzZ
l4ZwK7SDlcSbKSFHjF8gGqxoOYRf3J75pawBFL3lMLy5cbLfUa89JW0izS4lEiQ5kmRPkadqTRou
2yalYi12k5RJC2ExIMWBOZKj2WoXxLGuK48LVlvKAaOLypVPXR4gS7PTsx49tL/145w+XNXaHQXi
yJXb2zVNwSKmmqMitYiMSx2WDYf7OhduWo//ADCN5F07p50l8yXGpIVNdEubyX/gjywkkT/aHp63
I6Zx99XXL4+aboPtsRg8npvBm/7lXrRIEeotfq0fWcNrHF+M36pm/RMd0T439KJ61z4RExVxc+fX
8p6N+iddunHoubepeiridN/bN+q+2J0/Gfjfp+VTf1L6tunxi4nT8r0XJCZ+dJSEHLMVCQbaGrC6
dgbuU4wpYtbIDDjKCwOqthlYaUSth9hb1zu1RWbiZqBeUZ7HFJp4fZFqgzVwjt3O+fnF9uie+KmL
02xOiNzRy/s1A3lFmicx1Hc+I5CpOFbVOy1vIM+Hv4WoUXvjcvd09v4uquTnP/a7SfLtao5ds26O
0duq3vvDZ+2zr3J4Vi0zrGL/AKUWuYaVezyRwpXyJ66djLFzUzeY2VBjvUUinxNYTmuqJD5MO1O7
6gR38UIC/WHqjBiksc2xZILJF9iLfmSRJ0cJzI+pGKSJph6RktnPILT8coxmnMHIlk7keoinSxnT
GRsSUwgmxJRLGdIbFjaaKhS37XPjQU4RbevWxlyKB7M02Fwa7WRffT2nlmmnTY9JFubolkYInHfp
sSirtZu2wzv3Oz8bb4jM4ZxzguIxc0+Fz7BU4j0+u87Uy7VtIndnImzSiUFw124aeK4J9RLtWaPY
qZqJ3GBV/wCjq5f5rm/ua3fKWmJYGEyVVsC/ywanrEit0OVvK0iumxi6dbAwa/ZqmGbJvmd2v0cF
7c1AFx66WsiO+M5e9SvR1dY6eW0k3tUOrzTtt4U241hC8OgteFn3WWEasolizdRWwoMTStO9r1kN
R+oalZDqhyLBeA31ycm8SZCIs7SVaWElzHdKgU+m3LLmzo1JEu78t4fTs9tfMYcdnFrdPNgzdR3A
oUXS9M9j3SxIXUdQsl1KRH15YRVupqbxKvTjJcmx0grc0/BfBh/8gy2Daq9V6fHVfQnX46Li9N+u
3T8dEX0fGfHRUxOnzifPReqev3674ub9NsToufjPx+OqpiftXE9s36fKfn8Zt6V6bdd+idfxvm+H
90XIUt8UtJetlDt3Bc2mmiBGtrdylr7JjowSjLIfLY4Y3AErrESGuLJrxUcloiXVkN4KprXnlWYI
QbGxdJI92/VcXETpvm/TfEz86VkoFTyRyWX3Yaiv2WnvHRyElgNHhsC+xHZAZH1FIC/K0aFmV80E
cF/KA9o9nyqSTHhgurCOQcgiKXTJI8QdjaRiBsJTGzaa+bIEixFdaaiBEj01yLtGkQ5CjsIMUb9R
BbMSfFlt+oQYLL+6bMJW8STIFnEjx7m6itdAvY5gtm1zFu9UDRldqJzDxrqI1t/q1C5TGDJkw7Sv
ijk3NeUdjcCZLq9RRnBs9XxY4pluYsik1KJRydWQo4ba8fONR6gQbv1TBCK71Ms9+lLkEJHalq35
aayhiDT6u+6mpKp2SdY18YR7j6nYfq+DAh2t6SwNy3XTc2BFxNX1gmah1Eyye9d1xjd8raAs1rdI
FXP0gXP0ibE0iVM/SZcrITaZ07XEJgqLVAIR9R6uDYM01cxK1369rMs71tnLp5phRIdgKaupXoyv
rdW19eK+1eKyyDriNGidmTqSSmizKn6JLgquRSYmu4QEf/yDAY241Ga4dWWz60jP+QobWXmsC2eU
+umRAzP+QBKhtfAICBr2HFDL/wCQ4pQTJfllY7bKPVv0tZH/ACOLtzrM9mdV9+KYj9so9Wuqskf8
kDUZLc0iZ/8AobGw23srzSa/R0aq1i+AY/8AyOwrI/8AyDwEmpFSy/8A0kOy/wDJYExdeuWZbXJr
km+cspNVkqHSP+SVeN9oUk13/Ij/AB23Mny1/wCQn+LVauNWmP8A8lEKyN/yHIAFmqJH1D/9NXY3
/JZijlyizT/lfbPnoufPRfRt0+MVcT3xPbFzffPnpt0+Vz5z8Zt1/CZ89Px6V9l36L85ti9N/QuJ
6vjN/V+Oir0T0pi/09sTPfNl2+Oi/G2LhsVMH8x4xH4sOQjRxjvwgXiwUY7sSNIRUhTc8WXninx8
Q48YMi4QEhERj1xYp9ntVFemL1Xp+Ou3VpHInkHzvPVPnN9l7hc7hM7xlzm7O5neLvyIuI7bO6TO
692Kvuj3JnceuKq5yVMUhMbu3HKq5+7PfOW2fuzZy5vtiO9nfO67om+LvnLbF984JsnThn9uIuey
5xbirvnsudtu+L8IxMb7Y73zii4qIi5wTPbE+OKbqnRWo7ODM9ts3wbuDoOvEhB//Sxon/6Wxc//
AEtqZ/8Apbc//SstNbvs2PdyV22b5857bxJaxZFXqeJKEuoKuK3UeqktMc7nn4T2yp1eepEv/JMn
P/0mRtZ6zlWTHP5P/O/tidPnomLm3TfFTfEREzfbpv7b9FXN1z56J13zfNvfb3z8r+3rv777Y7Pl
N+m+2b9d839s39sXE6L7elU9CdPhEzbPjHYnp29ui5vm2fOLiLi+/Venzip0267b4vt6dunzm2Kn
RMVMVMRM+c/HoTNs2z8Z84mL0+eu3T46qno26IuLidF+NsNn5gxu8WjouTbkIIwqWCN7LaoRVq6d
ODoYkOOqEokhBV76wakNRscIVJxk2VSMcWCBrpf0wTw21YoFe3bFTPjF9CpifHxm/X4zfN+m/VF9
W+fnN+m+b9N8+MReu+b9N836fHo+c+M5Kub5v036fGKuIuLirirnLpv6d8/Ce/RMVPVv1Rc3Xpv7
9PhN8THM3xGNTE2b6d+iZtiZviYvzvn4zfpvidfjF+V6Lm/tn4+M+c3zbOXsruiZviLv0X3XN+m+
KvTbF98XPwmL0/Ho/Kriri5vm+bZv0VOu/TfF+E3xPRtiehVzbFxPbN0xPV+V+c29uir03xPRv03
9C9N/b8/nbquIvp+Ou/T56b9Uz89N8+MVcTrvi++flcP8b++m9iS4zOxAvTuU+n568hBYYUnjHit
kuJZATnDOJ8ZYFh35KfHabvcJvEkuUcrT0l0lupo7e2f5d132xc5dPxm+b9Fx2J139CdU6b7L/QX
N9sX3z8dN+n4xM3zfpv77YvpX1fn8/leruidF67bdfjFzfN899k+F+Ez858rtnwqZvi+jf1J03xF
3x2b4mLnviYrds/Pxi+/p+M39t/b8dV6LiLnHPjE90/HVMXE6fGb+3T5z8/jN/SufPTbN/V+c/O3
t09+vzm2bdfnNs26bbpm/Tbpt7ri9EzbovVei9VzbPyub4vuvRE6r8J0/OfhOq579dvfp8dNvU71
7+x/j86bXhNC7/r7wSpKqI7nHhD7cazGpANGorKK/hEs5/NauO4R5hVHGrLnuutl3hzl+9plNk1G
5FFI/ufn4Vei4idd+iZ7Z+V6L6ETpv7b5v7/AB1TouJm/oXNum/TbPzi+jfrvie+Lm+b585t029H
yu+fPoXExPQmb4uJm/VV3z4xFxcVcRdk33z4zfPzir0/PReie6riej5xM+em/Tfp8pvm+JiZ+d+i
rn4/G/RXYmfjNs/O+OXE+Pn0b9N8/OLm++IuJi9FT1r60xfb0L0+OiZvnziJm3vm3VFzfdc/HXZe
q9PlPjp+Oqenf26bdF6p8+jb+h8Z+c2xfn56qufjr89Nuq9Fw2L7LXyvGk1N02WC0ioRmnI3vaXH
hMg2fmjlhRspip4qQEIZzGBdYyG+JVk/nWEhHRHDQ02tjeJG1BcMLhn79F6I7br+PSvp/K5vi9fj
quben46fKL098TN8367+3RVzdOvxidNum3T8+/VfQvziZ858dE/op0VcRcXqvtm3RcT2Tp8Zvn5z
87dN8TN+n/8AH0b4nyvzvnz0XPjp+eu+b4mLiYvoTpvielUz2z8er4zbPxt6F6fHVfjFz46Lib+v
bN9s39+n5z4xfV85+fnNum2b5vn5XPyufOInX8YiYvXfp8/0Fz8dPj1fnETFTNuu3T5z5xMX0b4q
+5ccv7mJ+6vmFhuJqeSdgL4sVJNqaZkW4NCRmoj8k1eZEbq+QuE1GZ7j35jsFOeF5r8x2imrGKbU
UgzDkUjlTo7qnr+c26bdNs26pi9N+i+n8r132XfE9P5xV6NT1fGJ0VMReiJi5+N+i4i4vo3XqiYv
RMXpv6EzbqibZv79Pz0RcXp+Vzfr8Z85tm3o/C9ETPjEXPxviZt033xem/VU998XN+nx1+MVeiKu
fnpv12zb0qvVeq9FXpvm/TfdOi4mb9fnr84iZt7dE6/Ce/T4zf1b5vm+L79F+E6r0TN8XG9N83zf
oubZ8eheidF6fnb1fGL0+M+c2zbonziYmfn84vt02zbCpit9xN5LVVbj4Wj7YYFT5K2VKoUrKnyF
NTINwtPqrVoVw1Dxb+n9w/SXNkPofspG/kJRK4UyvUDns2VffoqZ8dPf0be/52z4xeiYub+hcT+1
MXNvb468cTFz4xXcs26r7Y30/PT8Zvi4nt6d+qejf0b9N+m3RFxc32xM29+m2+bdUz4z36Ji+2b7
4i+lPj339+nznxm/RP3J198/PVfQub9VzfZP/wCSpm2L8Lnzm23RVxffE+VXN9+idN8+fRvm/X56
bb9U67584uIm+Lnx1/Ob4qYnTfPz1Tp+Ns+Oqb+jbF6ImL029Cr1+E9W/p/Gb5v1T4Trv0/G3VM3
9fxm+fGfOfHRei7r0+PQ5MKns/2WtZ3D6fr2jDqG1Vi6fs0a50TzBw69IaWFlxmwDK4B5ZByPPQr
xtRQkrGuJLjo2LML40upsEltua5O3JbxI70bYmO9lzbbr8epeiJ02TNuiZ+eu+J6PxidEz8pipi4
nXfPjPnpvm/Tbpt0TN/R+dsTNsVM26b7dfyqZ8JiLum/9H8u9Pz0+Onxm+fGJ0/Ob4vTbF+fT85v
7/n56Lipnxm/T467elev4zlm++JiZ+VT+h8YvTbpvnwiLv0X0b9UX2/PTbPjptm2b+rfqub+nfov
XbqubdF+MRMXpv02z8589d/6W3qXNs+MRdvR+VTouInTfPn0l+H+7qj9kumdvF1L7Fr1e2RTEUka
W/hHmb+VUe4LF40SO93njNwix7JhnS1/i2/+bTP+W5/1JnsV2L1+c2919+i4nymL12xOnt0Tpv74
uNz89W4uIu3RExUz4z8Ynx+VzbNsX56belE6beyddsXPjN+vx6PdU26bdETqiZ+ds26L8dds29m5
t6ds2xPZMVOvxifObYuI3bPzv6fnPjq73RE9l6bZ+MXPxi4vtm26dFXExfVv13xF6fj1fHRF6+2J
irnymfHRUxc+Ou3VevyvoTNuiejbpvm3o/C4mLm3r267589Ez8dV+PwnRM2z875858Jm3q29CZ8d
Nuu2bYufjfN/Yi+z/ZYRe3IopzfDu4fkJVxd5IzsgASxHKZaxN31ibRZ4ilOCu7OO/0mSHhslLyh
WbVWZp+IoluZbWRpr+RHdF9Hxm+6u6J12zbFT3z46J1THelfSnXbonT8p7KmKmb/ANH32z85v6Ns
26J0+F675ti4qYnti4mKnt0TF6bdfz0+c26b+jbfET2VN8TPzi5t79PnPzn4z87dNui+nbNum69P
jNs/H4+Exen5zbFXE9+m2bZ+fjou+bZt6U9a5v029Hxnz029vQmfObbdVzfqvt0T26be3RcToufP
o/Po3xVz8dE6fGIub4i5vm+fjPlExPTvie+L0+P6O/TfNvbf26b7K75TDLj/AO5Pmkt3wnuvohgV
9mGPJtr0UhtPbtAprqNIeG9hsb9Wgrkq+BhdQgaHzE8x+oAJGJKaSWy8iRY9laPlOe5VxffFXonX
bNum2bZtm3tm2bZx6bdNsVNs2xUzbPzm3TfNt8/PVUxN845xxPlfnbETNs4++bdfnE6bZt12xUxE
xUzivT8rnwufnNs26L0+cXEzbrt0/Oe+cV6bdFTETNuit3xOm3v8Ztm3RExUxEzb32zbNs226bZt
m2fObdETFTPzt02zbptn52xfZE+FTNun4x3T56bZttm/Rfbpt136b+jfPnPjN+irif0PnPjoq9d8
3zfPwi4qZ7Zy9G/T8dV6r02xM+M+UTomb+/Tf1fjNs39/wAZ+MT42zfFXPjovRUzbPjPyvt03677
Zv04L6k+cX3XbC/D/wC9qZEiqTB0a7fTuT31LgsbCcZfo7kaOiV2LQri0SpiUrsfCe1zahXNJFVr
2VTyIcDhqreipipiNzbfNsc3ETptm2bZwzh0X2zjnHNsRM45wXOOIzpxzjnH24Zx2RG5xzjitzji
piMzji5x2zbNs2zbFbiNzjnDOOcc2xUxM23zjm2cd8VvsiZx3zj7cc44rfZG5x9kbnH345tnHOGc
FzhnHOGImcc7eccRmcc4Ztm2ccVucM2xW4iZxzhnDFHm2bZt77Zx90btnHETEbiszhiMXOGcMVmd
tUzguI3HMzhnFc4Zx9+OI3OPuo8UeccUecN04ZwxW74rdk226L/QTFTqu+fj8bdN1zbqvxi4ubYv
Tbf0b7ejbp8dNvbonRE9K9FxMXfN+v522TNum22L7pt7Z8Zvnz0+c2zbPj074ufObe/X3TPn07ej
5zbbPnF6p6N8VMRM+PU5Fx6KuP8AkCcnadp+8sxkeACscKRKlQmGDApuBLJgANrhAIySscZXsCrY
teFwptIndFWsZGtBsFNrvHKG2qEcyQPg922LiM5qOve5qV7lV1e4SMgOJnhvaq170QcNz1WE9qtr
3qniP5rAImMr3kx0JUf9OeiNgkcroThYkB7sSG9VfCeNrILyZ4r0cte9GsjOfixHNz6eTj4jlV0B
6YyA92OiKipDeiNhver4T2Y2A9+JDdu+A5mMguLnhu38AjUbDc/HwHJja5yt8RVcte9uMr3vx0Vy
O+mlxkF71fBcPEr3qiQnK59e8SNr3vxYL91ritayIr8dAe3ErycfCc5X17xoyvI/Fhuaq1xWoOA8
6ugvYrawi54L3PJXPCg60r0dBe1XVhmoKveVXwHCX6UVUbAe9z6sgkZWmfiwnI99UZqBrTkwsEg1
bUmc1lc96krCDwdWczfBJyfUmGgqwplJXvGv0c/AcAhHPqSDRlScjfBejyU5hIGpKfH1rmOSmM5g
qshXnqiAwVMYo0rHucemLHQNOY2PqiMetIdGhrCHU1MYSsopL2JWkc8lGYOBpZB8LWPG/wChHawd
KY6mqCRsbRHe1tMZ7z0Zo6ApTHa6oIhTaekCbFpiysLSlCv6dkuYKoKZ5qE0fBadkGbOguirti5t
0TPz1TNs2xF9/SvT46Kufnp+On429ts/OfHr3Req9N/Vt026bdE9+juu3o+em3u30b589fnExevz
1/PT5xMTNsVM+c2z8b4voXE+E6+3o/HR3xvtnzhcL8xf82l0Tx9UKqZDkdo9KZpxuY1rbqS5ZFD+
8c6IiqaW5kmuLyj90ZMKidq/T71A9zTymIsKzaiSXpm2VsbumgVAnhZptnK3qmJlfTs4fp1rnWNO
wY6ymYirp1hFk0gwhi1CKdaBhGJQiAJalCS20QyMFp0bMn1TXSI1GNwhabGx1tUNyvpR9tNNjV1l
TjYOrpWY7To3rMphBjwalrjO0+MifQwBClSj5aUYntDp8Asn1KEkx6UTgi06BjreqbvXUw1GmnQ9
y1qmIKrpmIj9PBI6ZVBFGrqdvdfRCJn0eOILKhHTPowSMBRxo7ZtV3JMeoCoQ0UYS29Yj3QKkaBb
RRkfbVjFHVU4mo6jjPdMrQtj1tQjSvo45UdVgFHDUbylqAlYKpjAbMqu9NHVBcENPGjLdVinJCqh
IJlJGa63r0IOoq2CH9FjOfPgDWPU1CCI+ojlx0ELARqd3mOrAFayvjhbIqCFmsrguECrjxMt6x8k
0KAMcZlQATrmC6Q2pr2xw/RwPLYQ+7HqahYqvqQnwsZjQwqV4Zb68J0ZFFHaanK+ekQZWCgDiJa1
JZcmJEawA6oYFua8k9tZB8UH0oXOzirJj09U+vVa4Uhxh/ZgUpIsp0MczFAkVi0ZFn9hpmpEbEbY
0xpsoAPssgsjZb1pLFa2IsMCV42vs4j5wKitfWtWvGdZQVcKtpiQD+G2Tjm9tNU1jwqRd1x2Lie2
Kub4nTf+p+V6fhFTF9G/vnx6l6JidPnqmbdPyq584vo5YnRV6r7Yi9N8VfQvTbPjNs2z8dfnrv12
9P53zfFz8b7Z+V6IvX8enbNvbbE6fjP/AORF9i/3AVEfpQ6LG1EHvMjx+R6OP4wiFa9t3DXlQrsK
2nOGrIzpBIf7Y5bRY1gGT34moPc9Exe9JftEtHbyHLie2Uc2OAlVME8fmhyxs4wsq7IB080KZMnx
2trreNJP5QskTgtYO3iOkJJHxJMCjTXMVho0hjxeWHJ9xDjvgSxnEskSZY2kYGVc8UhiyBNybYBE
yutgSnqUbckTBMZHuoxZPdYiElCa197FbJGdjmeSLabfRoxIkppxeQJMsLgEVtbYDljUw0ybZBjM
rLkVg5xhtw84QmxL8Mo/eY1pJY2sXUQfKaVvBZQsm6iDGLFkocXlCywvxQG1th5ofJFvPtxwh1V1
9Rx0gTckz2AHB1H553GGPCTRsb+qOcvvjY3zBKkvVPjyI0hCh8wRMstRNr8rpyzQLODvZXaQB1Fy
Sza6aBmS7JsUdXqItmYkwAcJOY0QdTmkTFkiE3zRkbI1OUUsUhEC2yCfLPUr4D4Et8iN9TC99tdr
XDp7ItiNbaOMk+x8INTfSLMkmzjxMNNRBRNSSps0lgCMxs0ZxyNTyWz0kNCIFmKWlrqQ0E8OU50U
NxHlFu70tUynnGnR3X0Tv21g6CGgt5Vo6RdRYbzzv49TqCZZzJdtFrsSxbLjLqOYSzLMFCDGtQWL
LfUMmHMjye1DjX8aeW+uy1qU0opov6khvkXdk+ADTdlIsmy9QwoJpcvjEobmXbS597Dq0ZYDlxtT
2pZR9+nx126NX3XE9K5v0+ET0L7584mfn87e/wDU39+v56JiZt126fGb+6Nz4xE9uu/vtm2fnbFz
8Z8Zv0Xrvv0+V6fHReiJ/R29C5+PR8ejfOW/T59Dl998f/YX+5F2XT2oFi5zbMjiGwdhJnoCNX3L
3yJrmFHVt7ApMXvOJ2wDFJRobGQnnQpKJCti96ZTRGhZeX6I0pVK7FwRVCT9Wl7QdRSAumahLNQW
pSxxpqI/KRqYh2RNRrBQuopBiLqwrhRr1YzpOpzysHqozBpeuaUuqzSGA1UaM0t4+QV+rTKOPqY0
d0rURZmD1aYLE1JKYWTqg01kTU5ITH6jkFI/VZShiaiJCyRqeVJVurpIhDviDPJ1XKlNj6pkR0Jd
FMcmqpJBxtQyIqyrw0xWapkiE3UEgT5GpzzhR9USIY3X8hxDaqkGHE1EaCkjUUuU5mqZaDFdFAWX
qeZKQGqpcVi3RnyD6ulHHG1HKirKvpEx/wCsJaBj30kJJWpZk3A6plxh/WpTjyNVTDDi6kkwUk3s
yWVNVzWDBeSIxZ2oZtikbU0yK36xJSTI1TPksiaglwUkXMiY92qbBQx7iUEkm9mTcHqadHCltJ7x
tSz5DY2oJcLJFtJmF/Ulh2gWsiI+TdzJuC1BNjDZZyUNI1DPktjW8uEw1lJkEdqKweONZyY5JNvL
m4y+nx2NnHYaRfWEloLibFYacaST63P4AsDxXSbKVNQd3PjM+oSO5IuJ01sa0lQmkmnkPdeTnsFO
kRnyJ0qXjbicJjZZWlPbTZTBWUyM0sk8krraarBTTx1LLkSsZZTAjSSUZDT5MloZx4ze8QhCWMpz
QyDAUkkxl8+VxY97HOlyCY2WcTFe5z3TpL2sklChDPPiy5CJzVXLnuifPVM236b5+eSej8dE+Num
2J0XPjpvm+b9Vz56bYvoXOOfhPZVzfb0fnrvm+fn/wDlvi5+On4679U6fPr367en46/hffEzbquf
n0r1XN83z2xcT29C589FTbHfBvnAt5YAsxre8Zq96WqMcRHIaZg5tliWFmmPmTn4sqW7HuKrkkTc
eQiObNm4VSuz3TFzbdGJzxsN654j0R4VRNsTOO3TbNsRMRiriiVM45tn5xV2xFxV6bb5x6e6Zt6E
xo+Wdhc7eNCq54ztnCVudlcUedtcVNuiL0YJXY4LkxzcVMXN9um2+J7Lnz6Num6rir7ouL0RcVc+
fWmb4nuvwq5tiJtm/Tfpt758Zv03xXe/zm/V2Intt13z56Ljc/O+fnff0p7r84ntir029vx8qq4v
p/PtnwuL8dPjrtv0X59SLi5v036J0TFTovtie/Xb0belPQ3F6fnFzbPlei9Fz4xfj0O6KuflEz5x
Exc26bYuKnXbN9s3z59S/GLnziJvm39D8ehem2bYq+hPfNscmOwv9zW7rU16ndEo0GEsRqz3UjUj
AqldJJTtGGDSoTC0iDx1OzjGo2kyyo+3kGh7o7aEgD1tQj2WVRxyQLtqqdKeF5BounUcwlExq2tN
22lArX9pUxWYglXOyqZ29sVmUVP5WXNSyOx4tl7S4oMcm2OxOjWb5w2zt5w2zt75wxzdujfmFCfJ
JXaT4jJQixtF98GmBKwunRsyRQbEk6baCLGrvJlSNNDBDmA7RHZ85U1JJxQaTYEdpQo1JUdQu7av
x0MjEVuL03xcTfN/bN8Renvm+Ln4xOnxi9fyvXb2xFxei+jfNunyq5vn5/K7pidE9G+2LidE6J74
uy5vt63e2b++Km+fGb5+Oi++fGbe3znynTbfontnz0XN83xOq+lPboqdN8TF9/Qmfnbrv/S+M/PR
PbF6qub5+Oq9Pxnz1T26/HRfb0L7onRcT4z5xFRcVc/uzbr8+j5zf0b7dE6/j59C+6+nbqnX3zfH
+2H/ALg/3aSitel6ZQDZMc2VUn8wTK1jX30zssoCq9LQb3uJYePlQRCMNHYZGR0EzUifdqrFzTOj
oeHcCRp3Nz4ysI4Z6dyrE4v8y4ezxodWsp66cVWzqrsOhUalGzTu75en9mHiKM9HGIwN8wqDiQnS
iC0yrBv08m1pW+Njm5tgRKQlXppxBu00iZLoe2kbTyvYPTPJ83T/AAZLjdp6+2N+dHwBuXUc18UM
DUKiUtu2VKiuV0KEwnmSyNR9j/oVn/oWX/nWf+Z2Rm8i6ahMBEtJ5/LiD8uPqSO0RdMV4ZZdRRY4
Yx/nonR3xt6V6fPX5z4Vc26bYnRPbPzv6dum+6/jo7Ez8/K5vnJcXPzv7dGrti+65+d98TonTbN+
S9Pz122z3xMX2Xqq5ti4qrnx13zfFXqvq390x2L0+Ou++fOe3RM398RcX46b5vn5zffqmb+2/Tb0
fPRVz56Jn56fj49G22bdPj1flMcvTbFXbE98/Ob7JiJt6Ns+Ov56Jnvm/oT2x3z0XqnT85t606b4
vw/+03yNdl0gv7NRN5Mcxe5pphMVf234XZp72ydKaNs7+Qal3YI1qoJUaU07dTf313tJj/6F77SC
Ln5grtIpF/i2l2CI+dcPsHU8AyBjfOpI7Rj0+VTLbHdGbC/kR79qClaalvPmpv8ADpcLeWoJZogg
6n4ZaXg5uEX3/NCJpJaqoa8NzJPPMNPBpSqYt1JfFyMxJETUDEad2NzR/wDj1X+5hGclrQOYaB7Q
bLUwISw7l1jPsP8Azq13/ZWH/nWn+Vci+x6H/SmvEM1Wu4NVf7AJUkOS1nkx2Lm2+b+j5xPjPnF6
ri4nx6Num3RPfF6bdN9+i4ntn5RM9uipnzidNs2zbr+Pxt6Uz3xfbN+i9F6cvb85v032zbr+Px0T
3z8Jnz12xeu/T85+cTpv6NsTptifObdfx8dPbPlc+c+On46KmJ0XPyvT89EzbNtvR+U+VxvXbbp8
dPz+eu3T4xM+MXouKmb5vi58Yvt039Px6FxUz5zbbq75TqvRc26/jr84mLn4X4Mnum6ZpW1ZHw7k
mDkQkZKr0SLHbfI+TNZ5IqZvB1mPvpGrmDZDc1i6gLsekP8AY1M7d1LD7r5M1sKNZy0MRVzffK9v
ORT/ALIuohe9c5Gyo5kWNERwjXbvIDp1eL796cKlyeLqVf5GlRbJqBndDp0jRluk8tgNPd19zVsh
teib5QP4zFKjocetXzphkHA08TcuoXor4D08LUbk8h7sa7ZdM2jApYs84dfpvmSwjMDIjJwg6hBw
JQPRso5ULBhVrmzrUqCgWDuRFwTuJKK4G6PNrFnFR7aqJeWKST6TjhM7USx2Ryr75v7Yrds3z5z8
7dV67Zt75t6Px0/GbYqbelEzfPnonoRubYvRPfF+V+VzfEXr+fQvxm3X56KnXlnzn5/O/vv0Toqd
ExP7c3xPj0b++fOL0+c2xU9CdV9e3RfhMTpt1X2679duqZ7dVTp85v12679F6fOL036L03xen56q
mIvXf26bdNsTNvSnT5X0fHVM23xc3RfR+ExcT0b45fY3t0juVj6/VBITD3SyS/qpVF5itP8Aq16i
DqxkdF1oN2P1cwjWar7WS7RZz4molhjm2i2DoepEgCnW5JquXfF6V85sQgdbha2w1Eyenc2fX6lS
IhtZDJj9VDeOJqBsQk3U3mZH1iyOGXZ+WSBrAEEcnWQZIw3DwHBrOOjSa1ErbC0JNcrd84YEjgug
6rbEb+uAbWGpXTUrtRJWpN1QksjNaNFHnWSzHdI5XhWBq8cVpNcscwWomtkLr6Pxtr5tlgJKhJC1
oOOP9eRkSx1OSwx5Vcq9Ic58R4dbtAKw1KWxV71co5Zo2PmyDK5d8b0TFzbqqZwxU2z8qnROn5X3
zbpxzbNum2ybdFxExfSmfnozEbiM3TtbJwzhij2zb3di9E/tzbNuqpidF9sXPx75v03zfPwie69f
xt13VOn5+MRc2x2b+v46fHVc3zbF9uqe+be+/XbEXN823z49HLfPznxn59CYnRc/G2fGbf1Nt8+P
Tt1VOu3RcTqnz12674nzm+J0TPjF6b9PnFxVzfqvTb1J09836L8q3fD/ADkSO57oNH3WSazsKCi5
CNAUZhUnIQaXm5aBGp9BTZKPk+ZSvDkOpU+WFf4uRa3v5OqXix41aqptn5jA7zv0+vYZCV5PoCtA
cPbejds4++2bZtnHFTbpBhrJePTvJHad2wlO8byUL2BbEUjyURBhDWvMRunHIkmmcFpmKxcX523z
bOONbgIT5L5lY+Jjm7Z8L8YmfnjvnHOG2I3Ns2yDVEnum0joLSN4YvvnxiJviJnDOO2OamKzEbsi
D3yDp8kxszTrogii2V3t047rX1hJ5JmmyQhvHs/hnHEHnDFZnb9u379vfFZ7I3OGcc2zbptuqMxE
3xWZxxG74xi71elZNgP9EFak/Tj4TazTx7Bf0MTJulnRhSY/ac/N+i4i5y9+idETNvbPz858dd8+
em+fPTbpvt6Ez5xcX5X526b58rm2fGJ8/jpv1TPjN/boi8cX567dNsRdsXE9G3Xb29G/T84nz036
bZvm2+fn8dHYn9BOie2L8/HReqL1ROu+berbPnPyvTfPjFz8b4qZ+cX3zbp8Zvvi9d/bp8dfjPnP
jJGNb76chd972Mro8yy7suuktkx31HMkp7YQKuepiWBlG0dh+2A5piTILTJDrkBmpx7JUWaDx0Zk
wNxG7B3pt0piNDJjvbMjAo1bJtysjRVg+UZaJcPTOYgqt71WlfyfSu4mA4TiY3KCd2DRTfxRS/Jk
SYbEJYia2FWNb584KOi1VU0I5uoxikPkBkitETvu+dsCBTODQke01QQDY0JxH6dpmhFqCuUrpkdQ
uf8AGCTngqgrmhpiOw9Q8WCrnmclAVUNTEAihVHaZL4wdSSkLhk3xcRcYnLIlIY7HUBWI6G5HCoT
Eb9FK156kgsbGVX6dabbUjd4kv8Aa93QfuukiLFHqCa44nj5ui0BzMXThkx1U9jm6cOrVoDPeakK
DA6ekGR1AVFPRFA0VGeS19WRpCaeOEZg9tcT5DHcVQaYklY/S0luS4DoywIazZDtGjjxAoGNONri
JHj12pZ9hLmgGsZNTxasCaunzJAWd+HqBGpKJn43xy79fxnx0b033zbPzvi4q43ombdd+ifHX4zf
Ez85v6fjrtm2fGJ0+en4+cTqvT36b9Pz6fjN/fr+c/Pq29O2b5+cX39HziLi/Pt1XquNxenyufjP
npvi5v0/PX59W/oX0bZ+E9s367ejfE9uu3TbFyQuN/u0ev7rhv8AFkb9zTshWqJdx6hK5coV+5Ja
xR2r+3lA9cNYoN4TNKmqPfAr96p94upP85cX5Gv7tMTVen9qX5VMSlrxoF6ha48djxRO135IRRhx
xsnM1FEQJCfOVP8AtwG84TBDEaU9XGsfeDX+1gb/AF0/1ZFWsuV9GOwc8SjI75yiYnej8XJMrGEC
GVHrJVVNZMHeWwYLbOW2UR+bZWPYORVIycExgRCSa9pwVFWMA5l/FjGkSo8kMp40nadMGU3VcdqD
Pti5si5B/wA9Ty8d0ZhWSYLBWrGtYNBiRbSCwoaWhamDlhU2ov8ASmf3qmJg1RHaZmjkJqYTfH07
XNky7CYOqj1ty21eavGyRvtjeDcnRGFQf2x/s3lxmSRwQtHGa1v1m7YngT/8m3vtmjqwZyXFqlSC
Jq0M5NRzopMhWHhyJeuZEkJHK9aEMRx4Rqtq3HcWEwLfNhnqGYVyviXbFbJd0/OIvVMd6vz0/Cb9
ExcTPlfj0JiJ0VM+PQuIno26b5+VXfEzfEz46fCYub4q9N/Tv74nRem2Jm++Lm2fHRV6qnRMX56f
HVE9G+KvXfptv03zfr858dPzt6vnp8Z+N8/OKvVP7t/V8Z7dNs/K9fjomL0XOWIub9N+u/suScT5
0pKaM0oiSAWMRWFoAI3EtGMfPY2SOrCopdnv2QwyyVrhdgmoCKNtHMeRNTL+yGBSmr3diLqMyEM9
2b5GZzfQRGgClmNVtI7TZXF7QLG4ljkOsZx2VL3eXcf6tCv29VbK8nzlSn8iBukCKj/OnKiLPdyh
QwuSwORGx2S0UDpxgSO53YN57HdjPnSMYbW2E9wTKXlCuN0laYIna1EBZZJtW4CPbsuB+dLf4bNi
+f8A2RYr0UF6J7jso5JhyYzgO0burdVJuOQ393HEbsulIzCSbWW+HGrJLpAJu62pV/iIb3kf4BO/
jV3L6jqJOUWa1e7xzhifOjf3O1K3ePpNfvao94mlxOQ0pfuS3bAaVVfM9hb/AGVNszf+PCdvHa1f
rVz7wZ6fdgVxZ5bDT5oDNFO3zVf7wipZU586gdAbAiJLlP0jHjQ5gP5TdMm7NPAIOdN9oJKMk7BV
T40uEnGHqR28x/zi4i9Px+c3zbfPjpvm+2fC9fyuJ1/H5Vc33z56bZti9PnNs236KuL0Xpv6NvZF
Tpt0Xr+Nts+fTv03zfNsXN822zfb0J0Xqq5vvm3RfbEz8fObZvm+6r036r7YnviJm3Rc/HxiLiYv
vn49Hz6/yub9PlcT5Xp8Zv7ehV6/j8dd8/PT8Insqb5758Lv7qub585IzbIpngdTaiZtZToxMg2c
MMWVZIsiJeRkBGsYjTLZwis+owxtHcCQtzZDkJR2YQpeWQ5GUhYw8s75vakSXGx3vnxlcRjDLdR2
Q22zvqDriO2NBuxkc50QmS7aNGFX2DfMtrgTw09qIIr6xZKc5d+lAjFMKxjILyYwHWepWqaHaDlh
Z4onXV+1rau+/e48VWkvgsbZyUkFXEftlBd9lCSI7kHahemoThetDcIFEsIbW31wOUpF5Kntgf7t
K/4JTQNdcajEIVTfMMnKC5bG9hw4x5XmyaKTFggtrOEURgrJM2kOufRT5WDPWkZYR5A/rMYRZNnE
Us3UEYcaPqFDyp+oY7Y1bfhM0ttBjZJuYpY0gHmmSjNn0M2ErSAzT0uFABZ3cF4YV0yNKZbwZA23
FbBQmqBy7Cz1PG7EHUKFlztURHtPqqGyIupe7INqmIKFVanEuGvK4WfqeEWNcTAyZOk7eLATU+o4
85tNe+CRt/VHb+qKqEPUGoXWz4st0QsnWUyUKLOcCVX6phmEmoaYWXmtGHZSaoE1n6ipky41tHaC
TKdKLnvm2ceqpjfZPz8Jt7r88ffETfFbm22fOImKmJnHPjNt8VPfb22z4xOi9Ns2xc3zfovR2fOL
1T2xcTFxPjrviZ84idd/dVxUz8J85tti4vp399vb46O9sam+bbdN/f8APrX2zfoq7Ji5viLi4iZ+
E6bYmKub79EXqvznzm3Tf39+m/VPRtv13983xfjpv0T43xeiY7ovwmfHTfPnEx2KnQ3xgMj1zj46
rWO0dU8qFidrBVT34lTu5KNyZ9Ffjql2PrXCakBTK+vJHRIanUkB8drmZtjs+cY3ZdsTfFbvnHZU
VzcX36bdPznBVzZW575uuO98TdM91zZcXffdem2+cffb244qbqnwvNcRFTN1XoiZEF3TUyshx9Q8
CIf2e7lmzlxrdujm+6N96S0iQMTV1Vi6srMm6sgkDKeh38ds4e22yb+zWY5uIzbGsRHVWo6+vCmt
K7Ha2rcuNTAsBE+4qDTNts4I7OGbeyMRqrnbTdW4mKNFzjyzjtnBFxE9lYiojOOLnbbnbRcT2xyZ
xxExRoucE32xW74oUxGo3NsTFxG5tvm22be64jVXFbnDOOObnHbFau7G5x3zt7Zw2zhipjUzbOPt
xzbbNt845tnDOGK3bETFZipm2ImfGb74vX4z8ehc339adfjNsXExcT2z89PlV9Hz6lzff0fHXbqv
t03z26bZ8Z89Ez46fOLn4zbFxM3zfpvt0T0uT0fnfPnp+VxUxUzb2xE9W3T8ZvnwiJtm3VHYmfjH
ZIT22yqi98tZTtGG6KDenjhdHnVKELHrhhAFsZZJo8cQmeOTGRBEPNpmOZCp2sNqCGwY6nxlcaAO
QG0geM8ibZtm2+MA4meERqNgkXPHVVWE9uJDc7FjKjnRHIjIjn4+IrcbDcuJEdu+K5mNiudixl3W
I9rGR3ExYqtXwn52Fdiw3JiQ3ORYy54rkxIrlx0dyZ4ztkF7rGc1EjuXOyqudFc1Ejudix3JjAET
O5L3cknPHcTPHVVWK5iIBX4sdW54rlxAqq9lcSIrlcBUXxlbnYcqrHVF8Z+dhVVYzm54znYoVzxn
Z47sWPnjLnj8nOArM8d2dhUxY67NiudnYVM8ZyIgFXOw7dI64oN18VzE7CqiR1xYr8SK5cWM5meM
5c8dcUCoviuxAY6KRuJFcuLFXEiOXPGcqujubnhOeiAVVWM5MSKq54yoviO2SG5cWG5qpDfjY3u+
K5mNiOVPFc3FiEbjYr346I9q+C9UbGVcWE/Gw3qnjOTFhExsMj8WG7dIBVxIZFV0MjFSAVyJBe5X
QXsxkF70WG5qrWm2ZBeTFgvZn00qo2E973V5WYtYV6FiuDm/RPnN+u2KmJ0/Pznx6Fz8YnoX5xOm
3tnzi58Z89PjN/R+EX0fPTb0b+j36/PRPXt6V9O6Zt75v75+VXp7en8bdPnr+E6Jnxm3Tf0bdEXb
p8Yq7omfGbbK7pI+PhdL7eQf9kKyevk6en8SxxMOy6IgBV5OUsjO7Hns8MVNKUpVO1rRtG7NTJ+z
dWE0+7uR9TsRXG+ca33oathGrp1CoSiGAQKRFlrQNKxunGiGWoR0odEwox6ZazJ1Q3vRaJjmM0x+
60qG5Ao2KP8ATHIlpSjCKspWrj9MoRZVEMEeDTo4jtOIRH6eZHAymQkv9PNKMWmGhYep5Sh0DHjD
pZqLZ1DecKgZ22aXTnbUzBJW0bHDXS/Mk+kYAVdSNc8mmELhtPijRodOhJJNNNM1NNjAF1Oj5Sae
YUcbSwg5NqN5EahG4INKDa+2qEatdRDcJNKscS1phiHWUrFQmlmFfMpAR41ZSt7xtMNPn6djxwMp
0dMfpxhRh00AA5NQhZgtPicGLpYInWlW3vwqMLwD0sLu3dUNjaqkGoXaVEUtlTgACqpmOcbTAzON
Rx40SJU9ySfTgzsFp+PFASoQ836CIg4umowMsqxpJkelC8ANMRmEu61vOspg9hNMAU11WhGKlpht
aXTITEnVccEOpqGKY+nQHz6RGix49YhLA1IGQOPQxYzJdZ3Z7KeOSPD09Eiuu6zvSIFSDxA6cjsL
fwUVtNVDaH9NxyGtoIki0FWgHHoI53nrwBiVtSqTZFNHktZWRo4XVjy2L6sEkcWmjREsap8maCvC
+NHo40R17Wukuq68bIrKKK013B7oKKsSMx1JGKSdFYkWmp3RTHpo8pz4g40fUEErSEzbfp89Px1T
r74q9ExM/K9d/R89VXpvnxnz0T53xeidFz8IuLn4ROi/0vdPR8rnxn5+F+fSvrXNsVPfPz+f6CLn
xm/X36fj59C+/Tb2zbpvvm+ybp0+cTN98+MkL+386dJxlK/uwriMrTUcLuEjlaAdkJJA4wlDNIbh
HkyHylrI/YfcFcFlNZqbNRu3Gm/eof2C1M5FwnzvgCIhKOyhuwc0aNkzY/BlzAWQCULtlmg4ntoD
DQpQXCdLCmTbSAF9dMAUayhJk+whjyrsI0jHSBtyfPiDbX2UM5O8PaVLjoyPaQSmacfE8oKM+rQO
+A43MdJCjZFpXjLDkDINTjTJ9lAAtfMjnGphpk+fDDldPjHzm1MmSo42wbaFIMr2pkiSFgxW0B8h
hGq0hxI0txXjOAjXjUzESZcV8csGQOQJSMTLC1gxcrZwJbFe1uTZ0YDa61iS3q9rclTACZEuoRz7
oiFkCGz69A77Hoo1OPaReQgljmaUSmGmTryHCdAmDmC7w0WxtI0NKuyFOxSsbk2wDGZXXsaeVz2s
yRMGJgdRRzSebWo+UNGl1LEHICVCC8gapM1LHilhyklBU4ssb8FflbZNsGKcaLYWwoLKm8ba4p2C
yVYDjMr9RssZDjDHhZTGDbqdpJKGa1iyxKknVCAkAPzCkkT8sdS+A6BMdMD5YXutdQfTB1FoS1H5
oRrYWfgjqL8ls90oQskS+yGFqo1hMIYYGrJaonarMs1DdsbZ4zMsNVFgyYsh5ADsQyX2+oi1a1U4
s8P1SOpbm4JVBpbeRaMLaRQvsJz4wKfUMu2PIswQcNM3jaouTTDLm/p/O+fjPzv79Ns2z4XbPlcX
Pjom/TbZM3Tr7dflfjr+Mb7ejb1J79F6L6d+qdN+m/vv79UxUxOu3XbfomL7Lmy7qnROmy9d8+ev
429uidPx0T4xc2z4xfbFz8Z+d8Vc3XN98kfGQ5job6TUCSh2wE7dJxGy1tXCJXTvICgecx7VcMcJ
Gq4qNNdSEWLQm2kXclOxVxu8cskdcG1sfKI9d1XN9sgX7q9DalOdzNXG7Qr50YsnVJ5SB1YQDFv1
dINrAp2RtWmirI1Kskn6wIggamMB8vUzpiC1Y6OL9TGaSTqx8xkLU6wGk1Sd5H6weccTUiQXn1Uc
7mawI0QdSII8rVx5KA1aQTXX3dkl1kR442rSxklaldNIzWpGiFqkwnztTunpG1e6GL9UmUx9Xuli
han+njJqsxiO1mV4od/4JJOrJEtW6zewbNQcZUrWZ5LY2tCxcLqJ0mQ/WplFF1WeKszUb56i1uQE
cWqpLSTdWkmsiasfAE7VMo5i6xMUcLUxICyNVypbv1mZgA6hJHNK1lKm4DWJozfrzySpGtZRhw9W
yIWStRHnl/WklI8fVEkL5+qT2TRazPGAzUUnvy9XSZga/VR69h9SS5RX6xmKKFqQteSZquZMUWsp
QAtvjCkzdYzZg4mrJcIRb2RJkl1pNkBialkwXzdRSLFyazmjALUEoR52qZk1sbV02CN97LkHNq+c
UVfqSXWLM1DNnEbq6eMUS8kQiztTTZ7I2qZsNn1uUsqXq6wlsi6imQMPey5xn6vsnhiXMqCSbqGb
Y4DVc+IJtrI8mXqewmhi6inV4z20qSVdV2Sig3MutJLups/A6nsoghWhxHm6hsLFsa9m17HW0kx5
GprI7IlvKr3SrabNd+pLFomWJwFk3k2YgLubFEs05DGvrEzY9xMhZJnypz/rtggle4i5+Ovx029X
xi5vm2/T4xVzfrv6OPVU6KmJm3VF9vx0/Cp02zfqq9d+m3Tbbqnwq5v1Xptnt029Ht1367+3z03T
PbPjFXfNuidN826fGfPXffo70b5t0Tr+c/O/T3z8u3zbFwyboqYzI7CYnlbc5Lsd3saSRs0kxmNk
2Lc8yyVO9L3IWSuNKVFcaQ5EOcWOkSnY752xfbPlfjpviYuIuflc+OvzidN+i574nyub+2+6JiL0
X3z4zfdM32zffEXFXfp+Vz8cl23998XN8/Ho36brir775y6e+b474/CLiJvnx0+c+em/XdUzffN8
5Z+d+m+b5vnyiLm+b7Y1ds/O2flVzl0V23RFzfN8X2zfPhd9s33xHbdN/bbNvZufj89FXN+i9Pjo
q5v0VN8/GfObYiZ75tm2Lie/pT5+Oi4idfyqb9Pjpti+3oXr8deWfGfly58+lU9H5XEzbNui9F+d
8336/K4q9Nuq+j8fOLiYvz029Hz6Nts36bbZvnx1XFXE+Oi/HT5xU9vjNuu/o9+m3o/G+2fPTbDY
vzHF3H0tL3MsK8cePUVrTpZ1CNWspubSVjEMylZw+ks3NUN5SKJEEGmXv2dM0MWDD8gsikRRz69Y
7np7774ub58p0TqnVOvz6VzfEzbN8Rff0L74nt0Trvm+fPo/G3RfbNt+m3TbbF9vQnvnz0T0758Z
y6Lnzm+cs/GL023xUXE9l91xE6f/AMlzbpt0+M36Ji+/VF91xVxW5tjVxd82xM3z8riNTdd833RO
nvnx0XN+nz022zbN+n4z8fnHLm/Vfjp8Yq+++fHT85vi4nt0Vc2z46fnp8/0NvQvVV9K4nVV2z5z
8Z+Ns36fn8/K79Fz49G+3X85vi+rfqufKJn5xfnpv74qYi7Z+d+idfnrvi9fxv0T2xfhE9uvznxi
dJHwuU7UdIrQNHDvpL+/T2bu6EDZSFCkIJZLizgryiE5hWNZJIOxzVEkJFfdM4xyEeA1DJdLbqOM
1oS++O9uqelF5Zv1T5z49HvnxnLFxFz36fn4zfNt8+Om2fn4xM+E+MXN/bffFxvTfN8cvTfbPfb3
xMXqq9ds+Oq75v033xfhPbFfsiLt0Xd2e64vtidFX332TffN9+m/RMXpv777oubezl2VV6KvT56b
qmJnLr74rts3zfE6Lm+bZ+cXFXfoi7Z+MXPxi9FzfN832679Fz8dFTfPjPjovviehF3/AKG+/Ren
xm+bYntnziZ+dunyu/RcRPRvnz6Uz56/jfomfn56/HX8r0XNs2xfZdvbp89Px0+cXp+dun4Trv6N
sTPj0/novzib58ej4TffPfOPo39jf2v+ah+0qtX+FfhVT1oXd+qRwQ2m5mKNwZsV3GJYTmuStC5J
EkyjDWW/cW5XnGlL97S/tmpPeObZMcmLi/O+/XbomIm/Rc+cRM299vf8KmfjF+ETE9unzm22b79E
6b9Pzv7dNsXF6b+hUzbptn4xMTNsROn5675+MVMRM+M26KnT8JirtnziZ+fz8dN83xOv4zfN833z
fNs/OJi4i4vtn92bbejbqvRfZeObZv0ROi+2bdNuidflVz5Xf9ye+ImL7dN82z8b5unT4xXZ8pv0
5Zt7bdPjE6b579F+V6L6Nt+i+2J79d+iN6bdN/ZOirm3RPfHdEz87bYmfn+gvVvyqL05YnRffPjP
x89U9Hzm2fHpTptuvHrvip6F6bYmfOfn5zbPno5N+jl3xM+M3z8fGb5vthP7X/MQ3ZLR3TJILKOh
WUkbkeys/DZCsvKyeD7wl4xXVzSH7TAZOInh1pUSVYFTwlH3JNWLxQ31o0uEdurlzfPjNt829vj0
J02zfPxi5tipm2ImL026bbdduvzi+nbNs23T074mKmIu2flcT46fjPz09s+M/Gbb9NsVMamKnvti
Z8ehem+cs+c+MT4X2z56L1TF6b4vt12z8J0Xr+eq7dFzfpvt13zfFX0I3PyvX8Z8Yq75viJm/X4T
0onT5z4xFz56b9V9s3/pp1XFxcR2b7Z+Onxm/t029CLm3T56/nN8/Pxnzm22fjPxi9Ez49C5+em3
v6FxOnznx13z5z5zbquL0cmfjN9s/Pxnzm3T8p1X3z3Xp89HY/4J8p75EklBiaplPBHuixVk3RZ+
RbgsTG6iNybrI7UTWRlwmpSlU2ojGaKc+MU+pTSGisFAY+pzSmFM4qr7L02xjd87eKPNtunFc2zj
m26be+fjE3zbET22zj032zfPnNs4e/TbNsX0NbvnDpt77Zx6cc26LnvjsXp74mccT2zbfETPzip0
2zboufObZxzjvnD2VvTbPyvyubdPjNum/t+N83zfPjF6Kub+ydfyufj8qm2b+2L8L7Z+NsTqmLiJ
n4zfpt0/PTfEz39G3T84no+ei9fn0fOben4x2J136b9PjExc39C4mLm2Li9Vz89d83z5zbPdF26J
i4mJ6Nvb0/jPxi4no3xFz8575858dPjPnrt0+c26J1/Hq29/xt036fnN/bEdi+yIv7fnNvZ/9r8Y
3ktZXuPn0RWR4lcp5E+nUI4NapnHp1agdP7tWi2U1Fs36CqjdWOQi0a9jxfu/Q1UUqEoHPbtm+Nb
yWuqvJVunka11DkyG4Lu2udrZYkTvu/Tn7JsPx3bbZw3ztrnHOOcds4Y0KvWJTEKw8dWPdm2bYmR
YjpLpFC6MJ7OKo3OObYrcRN+jGbrCoSSRyaIgmEFwdX1BJr59W6Kit2Xjn5azOOcVxcXomI3EbnH
OOcc45xzhnDOGKmcPZW7ZwxGYjcEJSLF02YrJ9a6Hjx5wzbNs+MXqmb++L026bdPjptm3XfN+u/o
229G+Jie3Tbrvm2L79FXN83TPnNsTZeirtm3smL02zfpvsqrn4b7Z8+n2zfPjNunLFzl0XN1zfou
fPVVxPfr8LiZvm+/TfN8X26fGfOLm/X49H4+V9CdFxFxcT175v03zbPnpumfOImb+r8r0/Hx0/G+
L0/K5+Pzy3z5zbrv039Hvt+Oi/Lffqi45ML7uis5E05XM7N1YOA2osUEdWeaOPX+KlhZKw1fIeUB
phWG85H5HGhQlq0UssXGLIMsabWT0mpeVqIM7eKr8sXZdNWBMkSHiiwSPlN1BFRXNo1exaFch862
RCesiPc1ileSE5jo1M6Ri0G2SKh4sjVLzr9AXD1DhNranukBXtDDtq/ZxmcXOzfG5pxyMJcTEJH7
LpBFpScUonvZIr3R8I3bFxvzRxGyDftgwyyBSGzmp5VAdI0e/P3sBBfKdKrnxVi1r5KkrCAcyiK9
q0RNpNe4Cvb0Y3IdSWTiafNsaqIHA15Dv+gFwtK8TWQ3GcygPhaMzcbDd3WUJ34+gO1v00ncdTlb
jaI+x4DgrWjI2RT91wdVj+6GvJMX6BITJNOUCPZxxffN/b8bZtm2L0RPSuL03zbN1Tp85uno/Gcu
iJ7qmbZ8LnwmfhPbp75t7/GfK4vt6N+m+b589OWb5+c+cTpvtirm/v8AjHYnTf0ovXbFX3z4z36p
1Tr+d+m+Jn56IvX5TF+fQvT8fGb9ETNs/Po/HTfPxv0/KZvn56r6Pjpt6PnF9s/H536fn874ufjf
ptnv/Q+M+enuuNz5T5zkqYTfC+zoC/e08v8AG1J/dHc7v0RHEZOL9meqpLqlTxpZBtQHJZkeQo40
W0Qjpz+QLV+0jTq/fu/eNL/vX3xibZpxfu8WECxrAsaBTzCIgmNXllwEaLUv4xiyGSHyalOQQjhx
EuxmNIgtKCthDjxzXgRyCAbKjCtRQjgkIsW7umKh3cnOzbB+2aalhelyJniQTMjygCZIA2WJ0i9r
mLHkJxVU3xiZpcDEdJajol2dzCxpOx6IoZg9UCax2mADUWpgpvpqONwS1bJE4oWCGMSFXUsMYhm+
V+asLTSaxseLHNasGScSOZlJXCjxnr+6TAGQFNViatpqCPXESyjzA1FYE82ytQ1WQJbbhspo4EtI
43AiTWTC3dSirX1YqoEGa2ZmoU7sys8eJHLbq19nLiFBM27n42zbExUzfE+UToqZtv0TFz3xev59
uu+b9d/bE6/jfPZcXPjF6/j8r7dN8/OfC9Nt/R+evxn49G/T8dPfETptm2be22J0/Kpn4Rem3Tf0
L6Uz89PnOO3RV45v7J8elFxcTfNt8VM/PX46bY7Nun/8UxffNs+Ovzm2+InX4Xptt6kz467+teu3
XfE9CZ+Pxie3ROirjsKnvHL2yaatB9i0AkhsKJ/KGRsKKGxbJS3iI9apNothHeU46/stRyeIkh4p
yk3hWKc5mn43F97Ka0Ul+7uWJ7rpxF70t+wak6mxyoyTZzCsH5tmRZCH3q1/hoxzZ8sqNGciPiAj
PbNe/aOAn8eSB7rGOu0OSTazjlRYE6qfILYxlivXPnGZpdqoa3TeL7pOrV/gCX/srx28Wd/k+Mau
ac5LImf6VoxWFav7tJ/49SNzTMhrY92FZK0I/FCI6On3NmaKJt/andbvn4RffBI5X1R5MYYJMeYk
ypQb4BUZBs9QWAysn2kxKZ/2NTMc88elNJXTIvEbqj7i6VRWDu1/nNX/AK2ld/Onu+/dryiae/a3
VDVcapdKAwMoM1bqiaVDi7boNNIn5OqiQFyDVlsCTqMsJrm+8WC+W6Vp08QJG8V3xPj84vT56Ji4
mbZ+dum+b9Nt0z5xvx+UTp74qp0Tpv0XNt822zbN+qpibLm39FfQno3z4zfqq4ufjbETpvt6ds+c
X4TbPnN+n5zfG9Ns2z4zf3z567dU6fjpvm/Tboubr6PnoufHRfnbrtnvtviZtm+O6fOL126L039K
e3VcVM3zfN+i5t09+i/HRcTF9sT3z4TF+Fw392+Vk58V4tWQ0CO7D5U3UYJQa+3ZEIXUsY6A1VXs
T9S1u8nVMNyfqiKgXWTVkO1TE8fzBulC1LBiAsbNZJHE36NXKGwhxcnakhPBWX0WNkjUgnnBfV5W
fXKsSWV6kolXqKCMDrmtTLLUaPdX6iivZ9TrEyy1OFUrdSgXEsqt+WOo4whPsN5NTqGPtJ1JCAGz
npNJvt0Z/dp2VCjJLu4JGTpQlmQdQQwwwW4PNuNQRSRpBub1X3bmmZESOp7qC8d3KAY0RW96qsYE
QFvaQSijWaxZEG6hnHcalAIcDUbhyhWcGUNLOsi5qDUCTnEfuuQJKRTV15EkhbMrRrbapjo2p1IE
qeZWb2mpYcUNTqRj3rOqzLK1FBgAiamR0hthWykffVlcyRepMnE1LDZDprsA5NlqmN3I19CkAdfw
hLZXsHhA1FDOJtpUDy71aDtkkKctBeQYEHUV0GwL8rpa4hVo9SajjWOOd76WsY0A+oNTxJEcr+4u
3tiZtn9vo/P4z46L1RN+i/Ge6dfnqvoX4/HXfpv1Xo3p8+v49C++J8ehPT85viejb2+ExMX4b8fK
fGInTb323Tbpvm+b475T3xMX1fHTb3Xpt03zfomKufHT4zfqmbY5eu/TbNvZc36/HTfqnvnyvVPQ
nVfQi+r3XExd+q4iZ84uLi77G+cEuNxXb4mI7p8Yi4q79Fz5z8dN+m2fnjtnFMRPbim+yYnsitbv
xTN1TFRCL2m7oqJitRc4Jnx04tzZqZvm/VWtdiCRM+M4NzZq4jERV989sTFai4rG4i7JvvnBHY1i
NxF2xWouNTj04oucW4q9Ez3xzUdnaamIqJjv3YrExv7EcnPO01Ea1NlTfO03OOIu2cG7q1FxG8M2
R2cUTODd9m7INuJsnRWI5URERfbFajl/txcc1HZ7Jnv0REzboufGbdd+m/Rfj8InTfEXN9sT3zfp
ti/O+fj4z8cc/O/X8YmJunTfp+c9s26fnomKub7r8YielM/G++L7YnTfonv1X1Iu+fP9H85viLnz
03xei++K3fPjqub7Z85+N9un46fGfnqucvbN8/PrVffE9C/OfKqnT4Xp+entnxi++Ji++bYuJ8be
nfPwmb7enbPjF98X2w3zgvlPfp+ExFz5xM9+n5zfExE6qu2J75+c/KLviO6e2++KvvvibbbJiuzf
FXEX2+Om65viL1T4z4zZNkxcRcVc/OfObcfSnyqdN/bfr79FTdcXpvnzipnxnz13xPfF9s3zli+/
TfExVzfbN+n5T3z5xc29k2xPfPnE+N899/n0b4uJn5XPZc+PQnxiLti+/Xfptm2be3znxnz0Vevz
m+y4vVM44vRPTttm/v6PhOiLm++b9PjF+Pjoi4mL1T36J8J79FTfPbPnExem+flem3VOnzn56/CZ
tn4zb0/PT5xc326bdF6bZttm+J0Vc+Om/wDRXEz8rv0+c2z2xOi9PwmL139O/TbovRfhV6Pw3v0F
m+2fGNd0TE6fOKmcuqdFX2Rc23xM39C9Fzbrt7JipvidNun4X0Iufn8758IjtsXPhMX0b4vRPZNs
/K/2/j0pn5xU6b9PjNvT8Z8pt0XFxG+y5tvi9d8TPnN/b877J0/G+fOfHVent0Xp84jcX36bdfj0
qvVPlffojvbbp+E982zbPjPx0b89E+OqrnxifP5zbFTpt7/hN8Vem2bb4vVOnz0XEXF6fGL1XNsV
MTF9P46pnx0/O+LiL029CfGe3r+F9Hz0VMTovRU9e+Jm+L0X4z8L0Trt139uW/Tbp+d8/Oy5vm/u
vTfZE98d7Ynvi4f3VcF/cmb5vnz0TFXrt7YufObdd9s3909067dF98Xfrt7L79N+iY7Num3t1+MT
Pnono3xF6fjbdPy5d8983xF36J7dUXPn+h8Z858p+eiZv039Cr0/Pz0XNts36+/ROnyift6b4ucc
+cRM22TPfPx02z3xPbHZ89UXonum+/XfpuufjNsd8/Cr85vv02z4z46J/b8+lffovv6Num/RU2z8
r8J6Pj0/lei9FxuLipm+fnouIvROi5vi5t7ImL85+M9s36be+3TbHb7dNuu+3T8b4uJ8bbJ0+ev4
+M33V2Nx3zt12z8pn5z4xOi+2fGL7589PnptiZt0Xf0r84mfn8p8L8fGLhuglxq5+cTr+FzfN8/P
zjffPyufhM/PoX53z8p84mL8NTE+f/5bdF+On4b/AGp0+Eb74uL1/CYnX4xV9s/Ofn0/jonTbbov
T8YvwvT8/j1JifO3tn56quyJ75+fx0XE+f8A+XVOiY7N/Unwub74np/O/Tbqny7+5V6r8/hPn4z8
u9um+Ji+2L8r8dfz+eien56OX0Ljei/DfQmLn5xPQvw336Oxvx0/K9PxiZ+ev49CZvir6Pxv0RMd
7Jm3t8Z+Vz8Zv79FXF6fGLie+fnPzi9Pz0TPwnRPR+F6fl3y753z/8QAQhAAAgIBAwMDAgMHAwQC
AQALAAECESEDEjEQIkETUWEycSAjgQQwM0JScpFAYKEUUGKCNLFwJEPBU2Nz0eGDkoD/2gAIAQEA
Bj8C/eor/QUY/wB4L99f+1vn/T8/6Cv+zV+8z+D5/wBm8/8Aa+f9t4/7Nkxj91n/AEXP4Of+24//
AOE+OvHXj8HHXjrwZXXhmen0syYR9LPoZwy9rPoZ9LOD6H/g4f8AuWkZRhGVRgqjjpbRajgyXWDg
tK/3vBlHH7ikjg4KL9zgo461RbOMHAm+nBwWVQkkcHBVFtUjCFE30ZVDaQ4nBaRX4La6Wl0ycZNp
njoyqLZhG03SQ6Rx/oUi5cmEi4oa6ZX4co8LBhCVFyqxuKybaLlX6mEkY46fy2XGjYvcb1Ev1G40
NULcsDSSHQvYW+jdDJtS8ic0v1G40ewnJUUnG0XHgqj8xIvTKEU9puhk47bNro3Q4EtZZM7TscT9
Rbq4KuJaf/A7WEzbPbElsp45R8f7jo3zRSkr9h7ufYuKLkuSOPJbNpgWC0jKyj4NpuSH+HES3E4P
pOBbhYs27P1LoaKM/gSFNmykbhtrybaQ8FeDdRspIcqFLk2UsDZwVjpx5N3sVSr3NyLNvsXyZXRx
4PUrgUboUauJb8mF5L8jjLg7T6Tgi2rFJcm2LSRKWpzQ6FKI1Ln3EixR/lZdDmkbIjZwXwxxkN/u
1Rlj8lV1uuDtTixSlqOrKeWOipFr8EEKaKV7UW1kn8FQKmu4T+TCO76JG73RuXsL0/5TuXgbrJ2+
fYenPPyL7jr2FSxeUJvyOXsKMF+o9/KIoqKyOM+BOrLXsJx4TNz5Jm2CFp6g2LGLG4Oj0tR54PUH
txQ9/hDlp4O9/wCBN8WSafk2sTtkF5NT3NyiNS9hIUvJcSv9wQv3MeUW/AqYjBV/PRs2Ni6NIYi2
OvwbmdzReKKxlllKhm2xPz0Ytw1Fr8ERUSfyfYmRKEfoJi+xgk6JIYhEfuKvYsiS/wCB2PqnXJfu
um5jiW/fpISfg3OODb6ZuVGS5UPaP2OBtCE/gXuIkhk4+OmSLH+6QprLHH019zKimYyiMv1HCkOj
Kx0pY6boZMql+CP3IkvgRqC3Mewh0hXuL7dHZKiYrI7RWRfwbhfYkNSJ7SJkhXREr56agkzBYo/z
WNMQvlk08+TUH7UJmcSHnBg3M2xHPwVKNkpQVEURjuofDwJR/wBwIX2JfcSQlIdGffo0bl79HbwW
MXR9V05MZIt+5fsZGouyxIt+Rnb+GLESjRnkmvcs3CMewlQvYaGZGbkJi+4jZWbFYzgbeBDF8DPg
x7DFR/5IfT9DCFdostSaHuyx4I10XsLbwKJFE0WkSc/YTsuJ3L93H79bohYv7RyXNm2fktrwbYcG
5ooyOvwKyNew/wClsSZNWXAuZFWbY8kfCTEvg2p2XDyPdyNFx9xSmjnyVH2K/lFEkhzgS3ctHPA9
nJ33j3GRSfgxxZRLJvhz4LmbbOPJ2iYoqWb4Ny4vwSUnyPaPHjrRKuOk0Nxi6GpexH3Py/fwSUvY
v/b76JWOZu8ESi+i6/HR0X0v8G0bMiS8FDo9hMs2jMjUa/CtM3NocUO+BPBZ9ing3G2JtbNw4xyb
uuDazebUVJ8lmGbjLG26GlwKyOfAyKKG6LKvJdHszY2Wx0x5N3I9O6LXJskzebY8HOGbuRxjybrK
kz2Glx+6Rsfkt1/kfBfg2qS6RbI3JL9TO1/qO6JUWc/5/CoamYincWhqGDcnk7mv1Oyr+C7NuoXB
xaHTwK322Kdpew4x/wCDfYo6lWdrRyVLKLTX2KTwX4FJvPsVD/KLsUdRjcal0z9InviVF0bkyptX
7lQ/yWz6oxkh96LXAmnRmVSKh0lGTrBjjopEtryWVJ9o+7I/TZGZU5d52vA9r7vb/cPwbVyK8Lor
FOr6ZWSkNPDL8G0szG1+P+EdsaN8svyYicV04tH8JFVt/cYK2lvp2qzuXS0U0ZMFRoz07GVJ9LRt
tUZ6dkju6dplmTBl46WuTE8HfK+lQkZ1DuZ2ujEzvlZZidItyydzswfXgz0qMqO5307XRmd/vMM+
uR9TMOj62Zd9Prl/k/iSPrbX4uOuJNHN9OTlvr9T/wA9eTL689efx89cJmf9Hx/obrBnpiJx0xGz
6TPTg4/1uI2W104Pbpg+kyv+zcUUjJQvk468GUWjJgz+Kjj95hHA0UjjpRkvpwWV/qeD5OChX0o3
NHBwfHRmf3fGDCH+7zwYoZRbWS0iqLkjticHB9P+qyhcIxwVRcqL0zZR3/8AJS22PArWCm42boZK
f+i7TuX4bawbZUmN6eUU4n5mCXpZZtouaNuN3wbku1ltYKmKekNfu+Px9p3KvxZ695KWms+CmvJv
muDbtQlFYZvas9N4n7E5aa4R6b5/7Bn8ClNYMOnRcvJhG+S6J1Zt4fV0jKHSKLivxLA8DSLSPpMr
pf4VEujabkjcxJoujKOBpGPctmz3HKh/usGUXtKODgz03Nfhovg9M3UbqKXBfJ8GMDjLkVIs2G6v
3ixkqX0naXVF0cdNzrBePwRQnVYK/lHKsslKiocmf16bliipJ0z79ElxY5V4H+6pItmOD3M9MdKm
0jtr8CT6JLi8lk8cFRXIoy8EfuWuUW+GZXg3lQ9+R7lwNL90lQt3JhFUbpfSYzIckNCjqeR19f4I
kGuRU+1EnLJJCURRl5E2vI6XMTfZpyfsTdZHGLpElLNRMfukd1I/lMI70j+Ub06ZTFvrnyS2V+n4
EiNrk5iSlCsexUl/KR2EYTeCLr+Yfp4wb7/U0m1naSh/5HqRXk1E/YtcV/2OGLyJxGhZoz0UfHLK
N3k2FlDrpjk7vb8KwK6MD+5x0bhx0kpVdeTFV8fhdeUIi/jo/ZD+3SlxZ9xfcX2NwyX7rczEa6X4
LaK2mFXSpXx+FH6CkuRdLJfHTaxNCrpuPsh/ulu4MewxXwXGmZ08HBgqnX4YC+UfbpIyS9iLMirp
ZNj+w/3eD1PJtfFi2tNnHaSg3yOi4Hd+CJF/BNvnpqEVIqJD7kkRrkX2Eam79CdeR/ulvVxsvTf2
Lcrgf+SEo4lXBenqYNmvG5e45R8icHUjvd/giR9yaaRqVwT+xHcQoj7WX8FYsgvgmU0ar8fu4/cl
txTH3OSKcaIwk1F1yb9Kcv8AI9PU039yzt5K1G/wQI3gv1lF/ccXqpoe32NNvyyMokfuOXwVHk0v
7BT+T0tlk5JUOPP+vx1YukhfcVldMdNw0XeC/jr90P8ABfkSXHXP+B7Snx1r8CP0EvIkSHEfSzAv
uR+xt+ej/dL7HFnbBr7Cq0Vqclo5fS+fxKvYUa8iGY4JbumMkXWL89dkY8+SmNr92/jg9ikbZr9T
3G49LfBxX4IsXuNeCP2Je4pRVv2G58sWTt5E2u1dFRUeJFN+B/u8FFeWb7bj7G2UTdHFFFNHj8EW
QS9js+lvJTJ+4pQ5Rc/Jpr5JbfYSfC8lfAvkco20TUn4HX7qlyJpOcB74bccG7CPV02bNXTr5HNc
oaIqT8jcGrvj8CIx3ZE1aVjixpvwRcROXg58lRfgu3t9iKfhDheWbok0/KHXH7qP9xKkO1g4I6ul
hs2a0MDnwxxIqau2ScPqTqvwQZFr3G6ayXbJ6c3mqI7fBCUvHJFX5JbfaiSkaULzVFL3NyWDUT+C
TXn/ALGs0Ubj4R8jjZZXTgkho/Q/Xp+n4VE3m0ubE0dxfR3zRj8FlG42m1m7Bz4L8FmPBURQbzRu
tGwb/dbTPB7Huc5+Onz0d+xa/BYoydG5M2o2vhm7kwzcZeRspcChI31n3Kjkv90kJcFl+Be5cSvP
TJf4VCbN2DbFnOBNvJ2sUkypsfH6FJ4FCf0lpJm2LL/dccibrPuPaWstFTSsuLSY1yMTRn8KTeBT
uO72HGGDdZ3UqHsaf2L+TZqYXuzDVmHQvY3PUUWVpu1+7Uheo1u9jdGSR2/SKGu+1IxIa05WNicH
TNs/wxaeEZn30drwbhrVl9hrSkWxKT7bOx5ORNeDvvedjx+7UkxLWTc/LHsiOnQoa1uNH8O37jjp
4LYnB1R3yv8ADGOpmB9A/TW03DjrK/Yfp4LFv7o3wXBbWWRjPMb4MwZL0sWW/wDsizwU33Fj2cdE
vBk4sqhlnx0yilx+HBWy6L249j2KkV6eT26UnRl/hwbdpb6basz0x1wzbRuf7vBSeDMsFnYco7n+
4uOCt2C30qLwdzvp2OjulfTDK9SjL/d4K9Q757ulRlR/EO6V/uOT62Zd9MTaRl30w6PrM9K3sz+7
2ze0xL/A1fHuNmD6pHL/ABcdcfj89MHH+xef+0Prgtooz0swcF0dplFJdMGfw4KMIz+/tIr9zdfi
ouv9JZj/AFtJfc46Ui5IuKKZbWDCGJI4yWlg3TWDMTsRtM5+w9iOOldcrBaiY8CtlDfgtrtKoaoc
msHGTsRtfBmKZ4JSj4NoryScKv4Ns+SUkhoSFvSKSibkZWBYVlxRTMGV/uxSawVxWBtnai2jODgq
h0SMIpowJS4fk7fw1VsuK5O4wjgujg+npx+HjplC9jgeOnBx0wj6Tg2uPBxkboyvwRbRdDdGEVWT
K6cHBTMHBwVRwfSZX4IIUjZLC9zs6XtZVGEcYODCMousGfwXRwXRtrpdG3aXRfTaiy30boX9JZxg
7SpcmPcsqXB8jbQmlizOS0VFurHu5JJrBWk2Xqs7cyE+C1KzgTrBTqxlM/LGtXgovwbeYSN75ZKP
+Co2j8x+BSiv0PY5bRNLyjcJxXg2aiz8lrFjj8FpYL9jbGG37Cbtr2M+xa5Kj4HuXJL3IqQ2h/7q
QmvA4/yiFZddPbBZV4NxTLWOu1j/AAciYyrwZRVI3JFeTuO38CQqOUhtG3ij4H3KzjAnQ8Cj7sUp
RNu5WNrLGvcx7HchqPVEY/zdJJPIoyN1G3orVHBdG+imjHI8Xnq2kPrErwOiO/Ns3UbWccl0baLr
BVcFbSqoeOtiVZMxVDa4ZmrL2/4GnH/JuSQmkbWi1EaSsr0ZWfwpWVt2oxw+m28HyO/YdC3dPkyd
pIpe5nkrG4lt4KfLFKY0ju4sdLgpwpWZqhSVV0r4GlxZ3n5ZG+CP2HLihEoo3SKiWykWxxRtfJni
jHTd7FPNl0L1OBU8kWuKEzVtZ6TLhyNS/wB1x+5L7dMLJByZXRdEU+Be3SxCP1/AkIYrE37H1lJn
6j+4/t+C/JU3Ru8j2vBGxjoyZO0h9+kn8lfyjsVj2Mz+CKI17DwRFL3Q74F7CbXgxjpQ9p2nd5Z7
n0OzhofVbRe5kj9z5okyMOCz9ekjD6X+Fv3NpvXJt1MMuJbdxP0IiJbjmKOYse0V+BvrL7DZEvr8
dI/cQ6vo5c0Uj2FuVDr2GqLeEbRRw0bvgm2dvJ34sW73KRteU3kivgeqkbYps3pVZnkWMmPbomP5
iO+ekqGRiXVke1lfBFDcfI9xJo2y4LjX+60bLHIVnsjYXRfTI0n0iMplspZ/BuZSZTeRarF9i3wW
ooXtZL3P0F1V8CfBzgfuWbRvHTk2WRmbbGZpEmuDDNr/AApkcjdotcIq8DoRRijk2WXeTlFJnJlD
2yT/AAK3RVobsTsrwNoTKs3UOI7OS2yueqRFjGVIwUYK+DczbY31V8C8D6bvI8+B0R3G3wWuioZa
9zbJ5HI22SzRmn9zhClHwK84N21FGBSxaHXFcDrFik6yWkkc8FTf2E+1lRKmzmMvuY20dtGTHS3t
b+SrVUdrszwfXEbjOP6EZLgztivkuLgUn4FnAm9qY46Z3Oy4lNU/92IqbyOSGky+RRsr+YyNIv8A
l/BwbYY/Dwex7nsZz9zMLKWD3HijaX+Cq3I/ho4rpjJWyjcbdqkXW0Soxk+gziztW4yqLid34cFS
LRRb6VHJbNl4NyyzhHcWVE5Ll+C0VZ3MtHJ3Pp2swzuZ2syXFnc8/gqMinO+mClPBmQrEdsjulf4
ajM7p307XRyWy0Y1CpSvpiVGZdO2VM+spyMMxqYPrO5nbKj62d0r6YdH8RmXYqm6PrZnp9bMmJtH
1s+p9MOjLvp7H1P/AD1+pnnpyfU7M9PJn8XHXj8HHTg+ln09ODh/i4OPw4Rw+mEfS0cdLSMxr8WE
cdb24OOlqJnphGYvp9J9DKMKz6DK6YiZVdO1WZiyjjBiGC3FlFJHdGuv04/DwZXX6S3HpwfSZVdL
rH7uvw3tKo4KRdHBwcDSOCkdyKRx/oMHBkrpddOC6MlI4/Dto4H+LCLaNq68dLH0460lZuoUH5E6
PBZs8lywYKLZ46X+NJIsuum6WEXEoxwVRdCiotlyRhHFI8D2oUEi5mBuvwcCci4o20KUkWl0qhYy
YVG2rO7kx/8AX7ikXNDahwVRwdsUPGBKjMcjcUU1T/BRc45G4o2ibWCopDXg+DKSLibS5obhVo2s
74xO1ISrBc0mziMS4nGBWolw++DZWROaRNxaTXg2y+kTlXFlVExyOApOJikx2vwJHeN6ZKPt1wJy
wVaPptCnJFdtjcKHCuDv/wCST08s2tV+BIjOatMlt5Rtaqy68WbJKpDnDjpWojdork9PyRnJYHCK
7imvq4L1cH5eWXHC8ilPho2pps3aaJRa4dFaiFPSXJ6VZIy1FwS2LKRFSXa8mnJx9zZjd7G6McEt
PxZua4PSSqXyf+NkfZijqRzxZ6mksJWWcdJb43S/5NV6caah0XtZL/qFtpn5asT0lWLNOc12s9P+
Yc9P3olFx+hm2ayeporl8DTVfvYyawP+UfkTSzQ7WDPT26bawx0juQzJhD/fptZKcUXhFeELBLij
ajdRt89E2jgXGSzZsLaHxfyUo39jMdqGy6ODKFgV8jVDk/LH22fTXS6PTwN0beDFFlClJFCYuLMQ
XJurklNorBgQ9qsUZQotmz2HSM/h7kfCKIrxYn8Eoy8DoiU+OixgteDJaFGJ3l+T8tm6caiOzGF4
6ZyKclZS/wAdOODih6deeS65Lr9RRWcn6DtFQ5PzXgaS7i+D6rPcpHODg4LR6c/qfv04qkbP5Pcu
vA3VjjAyff8ABwPYvBs1OTsXk4yd38MVJcGVizdAmmu6vJaQnHnaS09RX9yTxRH0v+D84Ul9RtjB
icrSIJ/0m9LyKMF5HvXgqhUv8GyY5rDNlcCkm2mae7mj7SEq7rJy/kI/YTO1G0slXO09KeCU6wzu
WS4G2SxZPaXJ8mfYSXuOS4bJqQ3RBafkWnqeWLUrz+CNGkjVd9smKS5Hf9JCcfBtf1l15NSj0pN9
pGaEnzZqS/lbNN85JJeWcYNWnUvAtP1LS4I6hFPDNZ/8myLeTZN3tgQlXknsxkuTvcas/wCaKFD1
Oz2Iz+TZLncNrK3GovOCWpFs04+UaT8EZQdVKzU0pXKTwrIb8JnKJT0s0Sv+ocX5SN+nn4Q4yw9x
rJZsldjftE0TdtwmbX/WftDr+WxLTfKojHUzUTTkuX+6fV/CspcdFeS6MERntZZTLRJ9M+4/36Gx
xsvyzPsPPImV8FrBTLLNvJRua4HXsMuXB/SbeUbpYK3q/Y3QLKXHR/c7i0JCFP2FgbXNlSJH2O0y
WUKUkbWOXSi/kq7Ny+o/QnfuZNyQ1+BEhpFyEWhWKhscbwLp28H3O5Jj2mRSlwVwKPMWJ0Sg1wcZ
GZHX3In6EWX8DJ8dKo3T5H8Cziz5ocXE7UsjpYsyX5JL5IqXFio/Uj9iyJqDUiVfYX4K/mH9hqIr
LQ/c+CC8lMwLceyo7R1kitR0L03fTuEll+4mvYY93JMXsJPgjtPkqJFyRsgyLkrtikuLGvNiUUIa
eRtFOJJv2O3CM+wlpy2n50tyIuH6kvYhR94izg9OUf1JyWCuXRC/cg4iXi/wKLVmm0hxSqhOrLqq
ibGvqXSmjUdWSkQwn9zfXmqNu2tpDNZN0o7hdmw1ZFkdP0lf2Ivhs1/ggpGo1/Qaf3NRvg0ao114
o2jb8ZyPY8EfaTHLzZPRrh8ifsacGsCwvYfzk0vHJf8A1Eb9rNvqxbuzWrjeTlfEUJauajZpasHh
m2Wnu82ylpqP6DXwaM/dcHo7F9xyWLka39jNPeyTjxtNH97J/AsdFJlHwZLYq6YdDyS6R+R/v6KX
SujEfoV0S8DSF9zcjteCV+xS46NJ9nRfK6f+JtkxJPLL+B1xZ2Dsj79HDrn3JFi9y0UL2L+CvBT9
i0W+mGRuTcT9Bv5MGfwuuGYGQZdj6Zzj8D+xnyz7I7WdwlXSo5+xGTjWRfYk17lpMSlzQqLlhEbM
FU+3pSHS54O7kbeaP0LisMhuVZJP4NqTN0uDcenX6j+xUh7BSl0wbF7kbJUbo8Et/k/T8CwNr2GR
+4yS6L2LXnpFpC/sHZ+gqRlUfJu5FcHFEL/pHEc48MluEhbGbtR+aKXNivyyW3FD3ECPvY8UrFfu
fl2s+Ce5+C67ekv7SVkl/wCJ+Wt3yZwJT8slt8mb2IUb8ED6XVkr5JIjsIuTNq9/wJpGl8Jkrjty
YH/aRdWl048mpQ75I0Qj5snuNNfJ2ZyLeqyTjfIpJeLItxIWftGm3y8D1IfUW3zE084se3y+R7/B
qad5kT9xv/8AhoZGvccfknKuSjSshXh2W/ajRS+SeGu437makZcqRq7fZCU/6K/4NKvYusMbf3Nt
8o0Us0mOVYvkjf8AWa6vlbTdH2IOWFsaIbf5f3qhfgtCgXwbCyxouiusvcoRKN2/38cjfTcV8dF9
yr8DZQmMj9xo3WNX4HwUcl7kLPgttDqh0bjbZXz0vyOnkUWb20bE+idobtDoivcqxu7Ej9BiTYm2
jDRQnM7RxRkyNDr8EW8MatNDM+CrwOhIST673yZHRsszkx20PJ7l1Xydoslvk7cFfykXd4HtwXZU
mdptR6cpFuhqLLk+TuKoUl4FbN2wrhm1v9Delkau8G+DryLc0/uNrBtT/U9OfCE6/UcYsr+Vs3Om
OnyO/wAFuhq1wWhbjmP+RtVnopWkPuQ6FxZ9UcL3O3gqQrcePJcJR/QteGVLbExLTNqd4Oe27It7
b+SoG+8m3UklSO2S/Q+BNk1GXSO/HyJb19y00yLXFnfNRZhqSZJxknL4K1ZqJJepeBuOTufay5TR
cJJ/BfsRjqvtvkuGpZyRhrT7T6iS0pDnF0zbrvuoktN/b8MfUePcxKy9M3S4FmnWUPZzRZJaiz4N
ryxyisMi9RWrPNF6f/IpJ8CWom5eTtTRcZVFm3VtqsH0Djp4FPcVrq5s26eEWRjq24IrTVNlsk35
NqVdtGC3k+lr3Q9kdr9xS9hKWm96K2EtvkUdVb0lRnTHHSwOU1utl+mz8pUyM3lIUZ6Gfc/Ljswb
ryJaqbiP8rJKOnhCl8jjrRe4rS7R/uH0fVMa1HmsG9PAtPybmKCeTu5M5O2zdZz09hyNun2jbdv9
8mbdllbKGy0tx9BdV0S9Pgpw29KS3M+mi+n0HFF8lbTCM46cde1WcG4rwcFvk3I2103R5OD6TJZw
O8G5G0t9KKeF0qJnjp2spZO4t/g7Snx0uLo5O4spcDT4LOxlblRk7XRVnJuvJyclSO1n1GXjphnc
+lxdFXnpg27zMrO2VH1n1nc7MSo+vB3Ssw8n1YHkyYlgpyx05P4mC307Z0Zd/h7XR/EZl30xqNHc
2+mJNFbn0w6PrZl30+qR9bPk5aPqMvpy7OenJ568Pr5/B8GD6X/gwjKfT6W+uIszB/468dfoZ9D/
ABXtZnp2wsyq6YMxfTB9JT6Yi/0PprpjJmFLre0yq6dsbMqumD6GZ6Wosz0wZXTBlPr9JTx0wjPX
Cv4Mqul0ziv3L/FdFUXRVCZg4OCqLaKLo2l0V+4X48I46Ujg4KLLPk461046cF0UYLQyvJbOOt0V
RSXTKEqE3jr8Dft0qKLfSvJbRcensi10pFv8XwY5ODai2zBtLkYRXT5OCkrLkYOBSkqR2qzIqyj/
AMjjAox5N0y4qyi5YR2DTRRdZMLBSyxPUwXFFGVgwjgVIW9ZLgsG1cieqsD2LBso3aitn00y4xob
ku2J9J+VHge78CRco2boRHHyJyVnaslVQjugi4UKJc42NxQ4tcFSgmdsaEkuWd8VMxBWb40kNfg4
NzVmxI7kiqjZujT+w4VW0SltN+m7+xt8ici8YiODwrISbi7RS9OzFMlFLts2ypM7HH9BWK6/U7du
74N8UcDteColi3yS+5UKY64v8CtG1ru+Tdprwbdp+Z5RL0+RRrl0XNGy8jnBYZGTWDbPk3aSNrWU
L1MJons9vBs2m6aNtZN+muyzc1g26hu0o/JsojLUJ7F4HCsFzR6fMpEp6S7RSaHHU5FLQxJ5FptZ
ZGWpx7E9iykbNrRc14sUXHLHqaS7LotrCY4TQtTRXuxQcabIy1F8E9kc0ODQl7m6UbaZOWmq7jc1
hMktWPDPyfqv98nWDMaEuYmDgyiceFE9j3PucEjCLZSXgeP320VmxcjpYE2sm1otI4wcIdUYRdGy
u5jkkbmja0htKxqsGUSSrAklyXRsqmWuTfJZKpMbSOO3o44MLkvybaVm6huSKwYoS8CwbENpF+Ta
3yXRJyXDPgYseSz0zcjc1kzRuSH1jAVfqeng3Icq5K9j7jxgwOBg+RQ8sbG2ijjkWMFrB6ZZaVG0
bJS25vnqsC8Hpn36JVZuHKihp/YWD2Fpv6X5OLLoSSsjL3RJ0extmsrBGVD280KNMTlzRqR+mitI
b1Xmiks/g4wYRt1Fki4rlnGRqX0iSWaI2sCcfBNOrRdEa/ps9PU+pk5C9JWz87/kTHpwFJyZXmi3
iLOS4ZQ4tG54O3gz7ktnO3BunuUbIX7E9XzdmyP+SSkvBGRHuV+xL+0lJCg0Re6RBWaskP0o9rO5
Nlx5Rta5N7bJw+DvdDcenztE9MipkPi+sERn5sw+xPgnvz4JLaR9IhCYnX8x2Ye09RvBp7l/KTaX
0yHGLpcmpuzgXaiPpyrJtnxORJuObFtx2HqSk6TNByV+TWxWcDhB0mTjPNRNOo88laTqmVqeZGp2
mm15gepb7WaTas/aMecHp6bpMlGeagaLUfJJQbjUjvlakzU7UaNYbgzc5fSzScs2z9pwbIvDROEs
7YGhhcmr6Xa9x3v6mauO68MtrxZCPuz43mpjOCWzOmy2m0V+9X2MFo2s3DS8DKLTPkplokulH6fv
smMYE2yLGyRnNIf3K6Ix7G4QxlGBroul/PSXSi0UixDHLyV1a6foKfRjb9xol9yh+xEoTEMd+Db+
Cz9BMQx2V7dKYq89KN3Lvoy34GkIoi0IobGMSY0R6JpUIZL3JEhX0X3P0EyIyV+CQymJLyN+wo8P
5L7LEvBOvfgUpcmC/wAFYskS2i3Z6M9yI7JbeDIv7S19Q37mXR2Pd9jApSXSKvHBGRtirQ/UpfA3
7leChT82Pd7G3dbIVwSGpGpXTA/faP7iRuaybIMkzbq3ZiNqhbI/UKU0VHkyI1H8DNy/pEpxsTgq
LfD466ZH7mpFk/uS+xDdxZpuJ/7Cf/idv12aX9pOv6iUXV0a1ES37mlsH9yD/wDAnD+azR+xrfci
pUaz90aftY78ujR2kvc0v7TWha3bjR/U/aH7MhGf6mu1xsNH7mrJ+5obP1NRmj/Ya8ccmgvuftZp
qWD9pkvpcDR+5qyf9RoODs1ZM0/zVdEXCalkipNK5n7Qej6ak2am6KxBvgioLElf72Ium54KGyi/
Bj/Bn3JSQleR/KH0/T99QvsURQyj9Bl9fsbPPt0kL7jb9ujfRdHERIz5L8dLPsLo4jsZaFfS+iJF
VgbY7HJdEWVXkXS6MmOsF02NdGX4LeDkwK0IwbaHYy1wNsWS4+xE56ONPJTJKy4m9kTHsJVwyPTC
tD3DLiJv6RfcVCT9xFWSaVpj34dF3g3Q8Cl4JIdcie6WPcp80S1GvsUN+PBUvwL3Jf2khffpLpDo
xUf+vT9C1fAnLgivcctvBtUXRGfsJebHUW8m7gw6K3WJy+o2y+mySj/QU4NL3NO/6ScL8nqw/wAE
92Dt5LccDrnaiW6O0yam0bk/JP8AQ3Qg5FSVdvkgn4Py42zuTRuzVC2qyafsLbG4+41/4l6cWyCm
qfyQS56xl7ENNPNm9XtY4SZLK4ISjykRc3/kj3ZsajK7jRm6ILdlIcE8uR60b22STL3cI06++C5/
ysec2VHPbRedpGDfBqQv6mPWXBK/MTT7hP5tDlLwySvIoRd7YG6qshBv6TWjf1vB60fA7fMTSp4v
JcP5mPd/K+TUjF3IUU/p0xXlNkdN/wArZrbX9bJakHQ7f8lGk1wmLZ/M7J78bHZqaaeWUpNWaW5/
zCr/APeWa1fBcIWvc1U8P0yDXFfu30UbLRGPixSNvIyWDavYtoo+aJLwP+0SLZsT8fvtwkvCN+Db
5Q1J8im6wfB8Hx0wKNnqYs22NMUnR4L6XaKiKJvdFJmROTXS179NyKQot5N7ZVmeBO10tFWOSaNp
teLFNuxpMz9JbayPbgwKLZuKRTfJcqZj8G5ci0zd5GkS3cPg78naYLbLibUbGzf/ADG1My8MTlke
0Ve5l/BgcUxabZuxY0mWyO47cCrCTEmWsMpM9OTL5GkxS8FyyXHtO1+TbJ0X5GkzZKVlvuHsZvbF
uyXHA0XJJsxBRZtiNPLLlGx9qR2efwXWR58DcTuKwkN+TPBGVfqPKHQuLOVwPbVlSFu2/qWtq+xH
4Zlo3flmNvHg2SLuA6cP0G0R3Fbo8m+LVplSklSrJe6DIxjK/sXeLyJykosS03z7Ck/BGXqRRW+L
HskrM+5NKadrpUn2sv1ENwnZGbeLM6qZ/Fv9CcNKalaK1X4P4qSP4tkmvosX5n+TctVWP2/ApXhe
BXLvoezg3J0xrVlVKkVpys3C9V9ln5d2e6FngS1b3n5T7fktM26+cYoktJ8lnc24vkuKaY3eCMle
CtRd3kShhF2VrXPGCUdJONobZlui1F7hu8MUr4Ns493llQtI5oUdSLmiS004tqhtl8lrT2yJO+1i
kvAoamncvcUY4osUdWLcKJLSuNobeRSfg2y0+++RJQyNU3HddFvQK0obMGf3yWo8EZx4PTvKHMcX
yW+OnsWUslo2q+DcbUslv9/zgcfTp+5bZaNrhZWUizKtFJNGTDMIvptcelnuVtLMG2jLLPca46Yy
cUNtlo27S7LRXJnBZgrbRktG1r9euH0tnaU49a5/FaKM9KvB7dO1lV0tdM9NvPXsZldLQlZksqLw
ZfXBbMFWZfTDKfS4ujMjLz0pPBl9Lg6Myvo3GVGZFtlRkfUfVR3O/wAHbKit+C5OzB/EdHNr36Up
ujM+mHR/FZl30+tn1vp9UrPqkfW2cn1v/Jlt9cNnLZ5/Q5lXXyZ68Ppwz6WZX4cGYvpwfR0wrMab
MwaM/hxGzNrphWfQ11vYzPPTEWzKaXT6TMGcHbGz6TKMH0YM9O2NmUzBiJiBmLXTCs7otfgwfQyn
17VZ3RpdMKzMeuI2VJUYR9JbWP3/AAUbulorpwVRbRt8l0UXRn9/QqRnpwcdKR7dK6X04MFUW4nB
x+GkrLZt8ls4OCl0qumEWKC6e58m7gy0XX4FE5o5yN8jiey6U1+D46cFRVlyMFG6SpDoyYRfk4FG
jc8HaUy2qRa7h2VFGeS6KrInqDcENMtx7S4rJxgqKsz9RcUbfInqLkfpo2tGV2nZBnFIpHeOUUbP
Jc0XCGSmcFyWBtKhRLnGzsx+GkXKNs3QRtfInOO5GIUd3AsFPTyborBtXJc42XBIafB3aSbKhppf
JXhsuSs+hM3wVfhVG7avYekuDdKKL2xX6m+H/BwLEbN0K/Q2NZE2YVUh6b8EW0niyq00fyIx+Bbj
djgwIbnz7G1G5oSk4L7lR/4G/wAG2hb1yiXp8j0ze1hGz+YtLFkcciWpg9TTTs2PwRlNYaJbMm2r
F63aVo91m5LyfmduDZHufwRlprnIpS+kUZrg36K8WKMkR9SP1Im9NZ4NRai7UQf/AI2emsv4Nyh4
bJafyQ1JRs1Yx+qMR6b+/W9RXZLbDiCGoraq6uM43SLUa/Ls4FLUjyT2R7vBJNUrE3wQWzlkPTVN
zo9SSvax6MoZRquMKqI9N/f9xx+GPsW1ggocXk/4FgyenSrkuijAsFnBYopZHJP9/lHA2Rj7s3UO
NIwKTRTRdq6PgVowjg+k4LdGUv0PoaR+g9scHBwbaFKSHglfCOBQ2fqX5N1GVY5UKPuJeRllpDWw
4wcIpR5NxUVycHApS8M8Cio9pfuUWOJjrGPT03Vsbo3NGTi7OMHFIcDgsUHVs4NzXTC/QWBVg2YH
jkxHNclM3V4JOsdOKF2mFR6djlRdfqKPvg/QbcTBVfoRx5L4Hp+BtoTowXyXtMDjLEvYtIcpryKl
Q/c3UVBNv7HfBr5/DVD2m2f6o7F5FimSjP8Ah+BJLlC3IUo8fBK6ZcV2nas7Rx1V3EmkhPSVryfn
KhSXgenp4kb5yf2KpPtHJ8Myxy01ZUoltD2mffJqenzWDu3bfcgn7Dn8jhAlvWUjHgisN0T+xL7k
UudhKnLb9z8xyr7i3RszCmP04nptEXJDj4EytR7cEpR4Pgl/aXpM26nKiKvb8G4jX9B6U32Xybo+
5Je9HqxlVcENP+ZGna4ZL03TselqXxtHNeTTh7RJQk+2Ujd8EUuCP3HtdO/AovUcrwWacX/SOUcd
w4J/lmruzVI+lZRp+k6yQhN3bNSSWd3Jt9R8UKdEVL+hocl5bIQ9rNW32zYtSsUL1NqfyPbKJHHb
uNX9DMkpDjnbeJEcYZylIfxpGla8iWnKqZown5lk1Kj3eobtTCI7Gsexo/8A8yya92iWrFPk1t/N
Fx42/u30iSrFFii2XQ6HJ+RDaKF9i/IxmHwfNEv31+5+g43YpPo3fBH7kSxxss/QaQjJgw6M8C8C
04/YTaKlJDpm+hV0kxX7dEMdlCkja8V0tnI8cjaXRSf0lfBu5o46WkbUxasyrot8dO0z1gL7G7zZ
RIplIsotC6bvPv0fR0LopH6DJDRJdMEfufoRaXkXR2hj6UL7n6CkR+wxj+OuDJ4MMYzKT+59KQ6/
Bwh/Ybi8i3CQ0Z4Isd+xUeD2P0McjfNnfKi4tP7CpeRTaLtEY3jghJcjjtTQ7kkyTfIlH2oojJfV
Z3YwbVO2Rr26S3cmpQzPuan6EpezEpT8FciajVksZTMDsjtiQaJylyOJD7kvkok/grVjZu01Sou7
9vwbdvg3f+J2qiPm2TksEtKsiNOG3uvkysDNrVkZe8R4zFl3/KRezdZHt2Wep7vghKKun5NvpKBp
SvO2xr3kThNpGrXEnZ+hC/6smjKHFkvmZGuLM8p5HFfT4IR/U05+9jXGw0CG113EWpbl7MitTnca
32RKH8qXBo71dKyckqcZmtpeIsT/AP4RpEW/Mj9mlHwTvjeTcP8A91Zoyl7GjHxuHKPiRL9m28Pk
175JaceF+9z7k6GbmUNj+GRfwSii2J/Bsb8jY66V8Eq/fbfBfuhtka9y/ga/lLIkuleBfYdi+x2F
z5NtcnA4wINryfp07foEpOhZ6UdvsbWKQ/sJVdmfbr90OhEYz46KPhsTocV0ydt9M+C1gavBDo1+
CBgkvkyMtFvC6Nrk4oXTjDY76Ki3gRj2EL7dGh2PJcRMX3Mewl5sQ/t07hm5eBNqkK/cx7ChtfJD
7FIuriPd5OTs5Qm1SHTNvkpcn3HZUXQ9zyjHlfgXsT+wxV0f36JMVcdEf+hb9y/gW1eBb/8AkhH5
LS4NqhULIz9jTXkxFtX7G62ik6ZHyRk+WbXxZPb/AEobem1kh8RNvyerBv7EtzyPaW4+TUpZJJxc
bN0bkRjLTf3NNfBqZ8n5ONM79SUSEZytkdis1N2JEnQtkbHGXJKahcb5NRPmi4RtHetvb+HdRKv6
Bpka9ycX8Dl/L002+DBnk3eCK87CdryV/wCJp7c0ae8Wmvc3RjTG5oi/aBHS8ti1qxZJN0h5xRpV
4yiDeKeSWms5NP8AuNXxnnopGjH7mpf8zNKN5SNPZ72R9RLJBr6d5rfoS1Urg1yaP9pqU+ZmvNrt
fDJ7fGlRHT1MbUadOvNicn/Dkai87hqP/wC6o04yxg/ZZ/JS/rJaiXbuP2i/gco+37t9Ij25MIUh
xTye+BkYl0L3P0PiznwNCl5NpJ+/77cV8EkL46N2JEST6LU6MjF+xyc2umGW8/JdrA4l2eChXx03
WJG+1ZtNrwKbrHVSsq/BuckJ9pfsUX4s58DKZ9WC7KwPwvc58DoV8ISsb/BaFB8m/wAsaHfDFuZ2
tGPcyzHJtFCXJvGW32icmjtZh+RWzHI1YoSeTc8saRulwy3k7cCp8PIrZcSrNkmW1Y6ZuvB3OxtY
O1+RRk6pHz7m1Pg2yZbyzD/Q9S8CbyXHtJJdIuu73HZKDfwZhuHS2j/BbjbJFx/wd/PgSwi1RXgj
weC/Bwmx8fT02Mztf3LVIhnB/KfyMeI8Cg2i+wliI34FYlujg3xauynKK8ZMzgbYO8Cz23kTc0mb
YMuTsg/UXHBXqo3Qmm7Ns5KFF+pFiUJWVN8szqontmpYI6vFEd2pT9ioyVMltnumSjqz2UsFesVv
X3H3dkmfxT8vUt/hrWxjDNu7wbtLg3SKt17D2CFGVqaZtySawmR9ZPb7opXwKWktpaYlJO0XBPcb
lKldla9uZ9DPy3gUoijOD3HbhFpjhqwcsYZKOnHaWyPbuSZOC8u+kd0dyRXpMU4qqN1kVqaV0dml
QpXi7onGendn8FEdi27SO7ugnbFWnTRrQnG1Lg9WHb8IcdSG/BKEI7dxuvJKGrp7rHKGntkRg9LM
Y0Q7d0E8o/gE1pw2bkZ/fVJ4LXuSh5ZvKo3NYPj2MRotKjbfg3Hp+Tez09r3f1Gf3/Fo+guqLNqg
NbaEbdtlbCzCs27C2XZ9NmIjnZW0rZg9kWjMT26Wjgt9MKii7K5OSxR2lV09zg//AKFm2hsTK22Z
il0tCXS0VRlU/wANo2vwc9NrdrrhlFlp0VyW+uH0W19Mlop8dcZM9cnPSvBlmR7WbW+i2yo5HbOR
R3GX07WNN9aTwU5Fpn1ndMdv8Ha6K3Ft2XF5PrO6XTtnRTmz3O2W1lb2dxgxNmZM+T+Iz65GZtl3
TM6jPqb6/XKjLPP6HMzkwYuzPXyul7ZH0yH2tGD6JGU/1MKz+FI+iRW1r9Pw/wANszGn+GuS3ps4
6WoWjujXSoqzMGumD6MGelxhZ3KunajuiZMI+h0U+lxVluNdO1WZhjpSMQtFSVdLSO6OOnaZ0+lI
vbgqSrphHdGunaZh0ovYd37/AIFeC66XRto4OBY5Lo21k3UUX/oFRiJlFCZx04LoqhJLrRdFlHwN
89FFH0nBQnXX4LXTakWzjpu8deMGafRRot8nBRZaKNzPBaQ17GXgtGfwUjdIuPA0Xwe7Mm1Itjxg
o3SwYNiWDuefk7ciSjYnqKn8nJaRSVlvn2MLBtFLU8lwPTMmDco5NpepwPah2cdpiOS6x+BUjuj3
FwWCvJu1InZGqFCSMRyOuvGDEO4kvwUhOcUzdpxo2ic47io6aszwVQl6aN0Uq+DauS5w3FwSRLeu
Cnoqzs01EUcK2XKKkUtKNm6NV8FfgWDhDgd0U/uV6cTfHCOMCTin8m+CujbWRSmSaQ4vwy6iYWm6
MRh+huaxZXYiVVwbJtc+TmB/L+hKcP8AHXArQovb9mbtNZKfWkbpo2vn2JT0lgzHgqeBS08tnptZ
sTmsjjFW0jCwKU1g2+fYlraP0mY0kVqIfpxuT8mx+4nqIcEr9y4rtYpyiKD54PV0v5UPcsI70S9K
Pc8I9Lbg3ThdGxRWDelhkNSSwxQlH4JT0YVsRtkuBb4eCXpwVywjZWL5PzFwLSUUjfBWmQlJLIoN
V4Ja2nHOnHI93jIt8VmI/Thy6Q9OvNF6kcoWlsXuRlGPbIhqSineMihKMfY9bRht2pXQ4vx+9SMo
2IrmkdqwZXCIw8MuiXwLAsckZUO0fBt8jkl++ihSaNj5LSLkjKwXFYKrBwbEkbqN75KlyOSLa4Mp
DpISrk4NlZZaQpNG10Wh2jgaSEq5Ezb5NyN7WTKLrkysI4wNJCxyYRtocqHJrJkuhYwjgcVRuo8f
YjHbj3LHHBxZxRf4I2sCdEjHlmDa8DaHLyZQ/wD6KoTocXgbRwZjRvZnIobcCLSNrLq8Dm19un/7
D1K6bfk/QXtZF14JR4owcUxKsPyP+YtOkZmO3uQpVkpDfKHKjA4tG/yvJn2LMiFayP7fhWLQ9q4R
U+fYjs9xOsjUsIX2LlEjLwSQ5JYO3+k2an1exJrk/JVj9f2Iy9jbpcm6eETTSeC5XFH1Njlp5SNr
WBdM+GTWn+h+Ze2xJ+xuoitNOrJbuiVptmoyf3HGPO0k/F3yQ9WT22Y5HLTtx9iSnyKWnk28IuTb
VjS5YnqRsr08m7TiSflChpD3+Ii29VZBrzE3+IvBByWXyftGOBQ03SZs1M1EhjNmp6fPgucsSHa8
Gk0s0WpdsWd6t2a+PBtg6sWnP2IPb5NT08Mc5S+ojj+UhXJ9T2wY3LPdRq4xsNOOm6TwQ05vi2Rl
WdxrR0+3B6k5vOCFr+UX9x2yexOye7OaJdv8pp+nKvg04T49hdqu+TUUcPaeo5fFmnhfQhS/8yXc
9m60au7OUieElsZoRg3+hpachOs7jU2YltPVbeeTStf/AKshX9ZOpPD3E7/rP2jaqV/vb8lR9iTe
clWXRgv5wUOSNjI9GSIU6M8kvwV+5h03fI10w6KGykJkRsbKL6Z6psQ8DNvwP7lDE+iYhoZT8DKJ
Eein89H9hm3qz9Bq8CxkdHIt/cVBUP8AAn5P0HtIuXBgtcm1kaJDijcxfI2hex3KztVDO8xGmIyN
lfA+nsSfsVkU5G2xv56NxwQb4svjAyMH7nFFOWR1X36fI146U+BVgl8kja+S+DwYf6D+xf4ZMe3B
FMSGL2FXFdHtfbZXkf2JV9RfOOSpNIbjk3IUmsdFH+UjL3OLR3SjGyUusWvcblhFR1NzMewidk6G
z4s1fYlP5O6ZUWxPblqz4R+ZZJ6f0mWJ+D2ocf5ER/tLKkalFSNSuK/AjS/tNRebNM1iCkTcfMTT
+5qWaewl9jS+xqrFn6mr9jSUvc3R42s0/uas34NLbVn6ETWg2hr3ka39ppb/AOo3R4cWQ+5rSf8A
KiMU1ZD+xC/uNTTbXsTfvIn/AGGnu/qIOJH+41J+EhRXK8Gn/wDy0JL+s1ISdeET+Zmr7emz9nv3
NOa4aI/3GrN8JGzymaf/APLRGv6zVi342j/vNd/P77/1GX4Eh0JfJZKIpNcsRJX5NwyLFZL97pjF
H3H0svnpfwURJFH6GRsvpZXyJDEujHJFkeiQulljLXSPSjI0UX0vkv5H9jdEjHnJ8se1WY4FKXP4
Ujd8DsVe59vwMbIUI+BFxY93N9N6IKTtEWxnwzJIuJueCZkb9h5ERJff8ERv4MIW/EDa+TGUx7uW
cjceSMmMkackR/qJLwRj0f4PgmvglZCvci3yPor9hfPT7k/7SSZL7Etqb+x3e3khHkusrwOO2UUs
EZt8Gl9iVab5N9uL9hxTFWSDfLKlx4NTaO4UrP8A1Ir/AIN2nw2UyWzlMTcayalK/gcZ4s3abcjM
MEL5UR/c7YNwsmnjgZb8RMPBbFXOwlulJK8ULUlqSZKF5Zvhd/A97/l8lJp9VJkYp29p6vdTIxbq
jVi3yzfDx7HdjHkh3D253Du8Ernn2NNJ3g9TNN2bZSqjUt88G6PJByxSo0435NTblTwOz9CEFyes
vpbtmxusmpnnBBpcIjJ4ohFc7idfzEyK9lRHTvN2f9RxbscGaj8basg14Rpyf8uCEVzuyaiXE8E7
En/TRpaX812LVUv5rJ6bfyan9NUQp1tRpyf8uCMEre7LJ1xLtNW87iK57aNPS+bP+o8uVmpCT9mi
eov5v3L/AAMpZqOSxVyJWfImUbhe48nxY7GhSY4EpfvVI2+WKToopl+C1RgovybSn5N8qx1+5yYF
E3Ys2lM3Mw+mWdr6bbNxVlNibplGPfp2io2t5N/kqzkTlwYZ+vR00bbLbRu8rJV8G3HSo4Q/wb3y
JWNojf0lX0rwLOSWejnIQ6FC8nedpl4FfdZuUaYkmbJPk3PI8l3gtswOI9xIZchD2iTElj3GRa4s
gm7wXsMNL4HBuslvJh/ob7pCd2NrA4Ip80W47iuBsyrP0JNfgT22/ckNrn2FuViXFD4vpHCQ7Vjo
ukx8ZRaHCfNYPpTY+ImmO6PpgPjgjFl7oGVF/YlKPBFe7FFyjj5ISTV34MyXNZL3wGk/AtzwJ3Hi
xqH/AAb5MjepDgzOJu02m7GptQ8F+tE2wd4Ix1JeS3rKyWydknyShOe3tHtdotOjbqz8UfxTbpST
Iyi6V2z8zUqRt0p2Z/B3PB2ye4e3gUr4K1W915K0nZu/mIx1t21D9O8otnODzZjEfYTT4Nuou73N
mm2XeSMJXKJUY065HbLvAo7cpGH2iY46um5P3HHT7cl3khuuaRcdLYxt5LQovSqVVZ7ITTHHUhuH
CPb9iyON0V4MQpls3IUHod1cl/y+wmicJaW+/JKMY7C28kMboxdmNNJ+43ZgUHpdyVWbnjxX+gqK
r7leaE+KO4sxHB9JizZTN/k9Ojczbtbfj4HKX7+0Vtsu+n07j6aLPc+l0Wyzjcx3gs90exd9K20Z
6U1fSxeel2WiqfTkrk9ui8lHJg2uJyWmU8nsX0qqLF7GOOlplNHH4VSsqi2WjiimunFlbRswUWy4
umVKJwXZWZI46J+SuTnphnsZLRTwZ5LRVfoZwWhJKx3gsxko7sdNp3PPTtKfR7GcmZdLg8nwW/wd
stpmZbLXJ9Z3SvpSlgqUjJ2Sof5mC27MH10Z1LFK8o/iZMzaZ3SO10fU2Zm30xZ9Uv1OTF/ofVMy
+n83XG79DO5ffrncl1+mTMqunbHcd0GumI2Z03RlV0UvTbXud0a/D2qzOm+lGIWipqn07I2d0elR
yz+HRTVGDEcGU107VZnTfTBewqSp9LjHHud8a+emImYuumFbL2lSVPpcVZ3RrotiszHHSoo+mzbN
UIuMR7o107Ud0WUWjg7o1+/4LotDs4NrMrBhdOCqNxk4M/v0kZowUX1x1pF9KL8HC6KutGTBRbWD
BRx1pFvpQmz36UkX02rkuRgovhHv0qsdOCooUpvJcclfgSijnJaFHyJzLRTLaqJh2xlJCzkwiksi
ergexWUy5YiY8dNqFa7huKNvkvUOxDTLawYyy6wUkd6yNxWDaKWqsF6Y7Eoo7o93uNeBKIt0e4uC
NlZN2qrG9NcFNM3NdpiOS0sFJHfpq/cvTVG18/gTksFelktLAo0d2mpMctJKA4VkU5xTO2FFCbWC
vSQ56f0+xVUd0E2XGv0PTp2XNJjpRicWmW8FbF9zfprBVHdFSHKFI9NrJcv+Su0tLtE2VKMWj1NJ
cG2hXX6jcav4JRaE2sFUrHFe5GTKx/gvR9jZJZM0vuTqtxs29pumhRckPU01j/7IuSFGTX6l6azR
tms9aRumj03keporAnJFSwb9NZ5PTksic1ROleORL+Rm/UQoe5LU0Vgtm3UVFacec2em15oi9RGp
FJOonbHDN814FBpW8D1tFVRclwVOItkV3G2lV0RlOPHJKMVwi4rteRak19SFp7VfBLW0YpfYbksL
wbZwXuflRVtnpV5IucFaJrGInYvkhOS+pChtim8E9bSjhew5aiSUSmor7nbBXLNig/pbpEXKK7Wa
kaWEKsabVmhq9krR6K0+9lpLc5VZqQ/pdfvYxRbRKKxIjHDdHahWiNeZFjTiI4LSH9ikVLktLwP9
7Fc5N9FOJ2pDb4Eq4Gl4El5LoUK5HNI3uIk0i0cYOCqFjlmEbaQ5G5o20jCOMCpG1Uccm42tIckj
e1kSowJVjpsVGEJ+Smbkhza8nwOkK1jotPFseBOsmSxuuDI6Q2Pol7idZKdFjk1wZ4HRFVizCPT8
l0cCTLocmj7DE6OKPTrI3RdCUhMc9p8dFgwqHp0cF0V03beOjXFDa5Ppz0a9yMq8HGC+Tft6U8HB
dVR6d4LobUaRhbq8FvyN11jETrwKFdvuW1YxpeDPsKVCrkkpe/kzETojFLt4s45NR0diyZXjyJ0N
rDRWrz4O4ToSiuw3Vyajoezk71k08eR1yh7l2sz7CdFQ+nyW0TwNQFpz5FqCV8CYo+LIzojGCxZJ
y54JOjs5Fp6nlkX8ktvsb/5TTvzGxyXKZs0/p5J+ouMHasdcojtx2j1Lwmae5Xg1WlVM2acqHGed
qIS2nZgrUl9TJYs09qpuJvcnUWQvLNalwzZFun4Ns87Ymlhck1p4kdz+p5J4NKvMWOW51F4Ibst8
n7RSIwhJ5HCedsDTx5NVQ7Xfg3yb7/cla8Gh9mbtz2xZb/qP2jH8pBJv9DZLxB4NLC+o1oww7Nzk
7nyTx4NH+0lNt7YyE3/UftWOImmoSaXwShJ/TBmjj+Y/aFDDsTk/rZrvztR6cZSr2IarvAr8TNaX
Kb/c4/Ai17Et3uIj9hid8SGMWmX0lXsfqaaWLY79h/vdP7i/tG7P0L6MRQn0aXscsr46MYun6iXS
74KGUYI9E/nrfS+li6X+NO+t/JQ+jGPpp/cT8V0rx1aF0UhDGV0yfHVS8kRmRof4F9hP2IjHY10o
vySNq8ikfqUO/wDHXI66foKWLF9hjKH1iaf9p+oiQ7JkeioYvsN+zEjUFZKiA0+CNdIolfhkTUFu
JbfYiSI0P7ESe7lMxxZMW47SP6irg0vsyH3NMkpE/Zsl9iG73I7SP3H9j5IfYl9xqWcGrRXz+BP2
RJKuTT+xrfMjZLmjVaIFv3NKvDJGn/aakcXuNM/aCCk182aslxtNP7kpfJpOJNml/aa8G82aZ+0U
aW50aslw4Gj/AHGrN+5pV4J/Y0V/4mvp3m6RFfJ+0/2mlu+7JzXDgzS/uNeT9zS2+Ksn9jR/tNeP
zSI/3H7V/YaF8LLNTUXD02aP9x+0SfG40HDmLyftX2Rui6bI6Wq+1+xHcuZGqlxu/dvpERIVCJUJ
fI/sOJHU+SXwUfoYIP2YyX72P3P/AFKP0GMYuldH9uifSyxdNvR9LYyx4EYFGse5kof4GLoomejo
TfTHt0QyvBnpjpQ+kPuVfgWPI76Wi+mMjXyLpH5Zno5It9a8iHQkvI7GXHIn0wba8kUOjHA9xyPb
0ki/bHTjyNeS1wPd56dvJclUV0wbfkjfsSotK0S3eTHWLZCv6Rx92aa+CZuhmPsS3iydpcsJDEvg
57WyFmqjfHPwS3+SA6FeFFkmRryjt4bI2TVm6Hgcp81waeSVHcqjHglfsQ+S4/RJ5FFmpkUtPlew
pTeSMPJGSh2+5BedrFqSjheSCvItSN03kqTJ58C2fVybtRu/k01f8xKn4HKVuHgp+EVfkWtC/wBC
Sf8AyNxluXW5YKg77UOWdrIxb4RKF5cj1Y8klJ+CFvt9zavOTdLwNX5yVHxE9TLUvAoSdbTVjf1M
9Xb3D39vbRpO+1Ca4kNvNMmlyQhHmMcnqe+TZJ8Gov6mb1Rb/po0/ZM995OuFka8s04fzRjk9aPl
2bJPhmt/54R6l8eSLf8ATRp44Y/abGvHJJcuiGljdGAtaPvwbeaZq2tu/CN/sqINv+VxNJJdsXlm
GvzHZJeFkloydJo0tjT1KN7ukacX4katcX+9jIhBPuN5fk5M+RS9n0TfAngmiNe4/scimyRKa/ep
myy3XTnD6OjDyKJvsqzLNzowyr6dtdNvubyrMis+wzkuLKs2s3sqzPBlowzk5MHJsbpm+02PIjJ2
mGVfTky+TfZyc4Ms7eBrqmKDN7HkjnAr8nZhFWJWWuTkcX7m6WR5OcCvNjax0UX4LXJVji3yWzkT
8CbydmCimWjkavkt5OTd4FY3HtocLwXKKbK4H22z02y3kdCkvp9i+bG12lRFGUqwXQ0mNNl8jzVj
9uqkmbZuqOEbUza3gvkwzf7CvL9hywqNqeCMJvwcDhB8Dd4bN3KMPkU1L6WJSyxy7eBpS7RRk8Ft
ocIPg3XyXaHlbhSvhihN5+R5i/sYeBW8Ce5cDhBjknyd068HZX6Ft4sV6iSK9VD705GJfli748Dj
B/4N1jWpOnQ1CVs3bhR1ZUmy46mTDpCfCRHdqbZUbdOdqvw1KXa3k7ZSOcEZJ1R3vv8AJt0uC4s2
61tVSJR0m7fuW3Zy68mFkbu4sTToUNaL3WL03SL8i33KKRJacXGy2Pl2V6T+42n2+xFrwbdTT3O+
TbB7c9I7luSVDUdNxbVDbdlx8len4G+I+xGSfBslp7nZSjsyfJD+aC8DUY0+LG75G4+SvSXA5cJ+
BT9inp7/ALlJbekajvUcUVs22W2cKaqqZnRRKH03k+f32BR206oV+DjAjIo1R9NnFEks2b2OPuKT
ON2P9BZtqz26e5VUXdlpm1wLeOlMfsXZ8FVQ89KcenJXJ7dcdMMprPSynwUZZg4ouy0Uc9Pc9umO
CqLstG15fX3X4rTKeev9SK46YMou8FplHt0//YPG0stM+kbZhiT6/wBXwexdiaeOnJaNvLOenubS
zHSizBl9O1nJyJxdFFyZyKKeDuf4cFbi5Mwzamd076Xpy2sacrMlo5dFyeX0qMnXsdzbfTsKbZks
+qbLfTt3fod1/r07b/Q5l0wfzGb6dkW/sVK/16dqZmMkZZhH0S/Qz07Ytnfa6dqsv02ZMCfpP7nd
Gvw9qtlvTMmC/StFSjtft0/LjuO+FdO1F+lgqSowXGNo747en5aLkr6dpmBtliXS48FTXTsO5X0p
IusFS5MFpHeq6dqPotdO04s2yw0UjciLmsNlJFobaKkqZhH0nev3+Cx4syhpIVoujg4Lrpuod/6L
jBfSkLHSkK10aLrHTaZXRm6jwWNP8GMm546XXTBSRcjHTai6NopM5VF4NsDuMO2VQpSfPg5RjgyY
wV0+DdWSvwUhSmWs9OMHGS6FGKtnesjcVgo3TR2o2V+p38+52naheoq6XBFF9UkrsTku42RN00Zj
kbhHAoI7o9xcVRsS4O+Fs/Lg0WlgvVRW1jlpKkJ6kceUfwz8qFDsqQq0h7VSEkbpRtmFg3SjZT0c
j9PS2j/AnJYNvpKxuKKqju0037jlppIem0JzimdsFEquTdJY+Snpq/cc4HBmCfyNwpM9NoTlFP7j
xGP2MZi/IpSVIr019xy0kU1wVSHs+o2OPkTl/wAmVGP2LgriKTVFVEcof8G2jxke36vg9Nw+wpTw
zLi/sJxXaJyWDbaHOH/BTXBmojUabFBRw2Jywzbijdpq0KU0bXKvuOemuEbZc9aQpakTZyz1dKPJ
Gc42KDwbtOOauxxnEW5bcDUFfybUu1suaFp8/B6ulgUpI2zVC2QX02enJYI7o1g1NsU/AlGttm+c
bPSUFfyetBVb8CnJeSpxWBShFJ7bPTkseBOaRqKMV7CUVi8m6STxZHRcVb8D19KNJvwb5LKeTY4q
/c7UrqxacuPki3RqrbF+BpfSXJXasjpVFWPW0o/U8HqtfSyUGo4O1RwrILU5ZucE4qVUJemoqWOD
V1XUEmQn+XK44HpLSSrzRC0oXbslH2f7xij7ilWRqhKXljpGUPAqXgracDwPBVdEpcGF4H++ivcW
DbQ3EUmZ4LVZ9iK8CdEuBRj5ZdG1pDZdDjRwVikbFG/kf2KiuTKo+kqhSmikR+5hG3bZdDdYKGkN
pFy+plUQXycDWyz6cG9DwcG5o9xQ20N0NMeDg2sSijjwP8EFREaPkTooZKVeS2hpeRLlWJ0NcUN1
ls4GqFL2MswsDJqPB9XTYlk3SWR/CICFHYz7jlWT3Pgviylk3ONIyfVZ9FLpuRUNNy+xclTI/Ip/
TRT9j4MxTY6LFJfB2RuI96rBjqrFKvAtP+T3Lq7HjyVEt+xurJa5HGayZRx4FD+Qv3JOioeDPNEX
Rgany2NNCx4Eo24ilXJqTryNaayd/KiQO0a1F5HYqXghX0p5NzXJqMcdJZFGf1JEH5s7Se7KY7Xg
i17ENn0p5Mo1XRJafJGGp7Gn/cPauDfL6X4M/wBImlkSjwPd9Rjrb9yW3GCWq5foRv8ApHJLyRUf
pWSW/LRx4IrSeWRhqPlidZs7cdpLWcn7Glf9JqNLh4Eoy7TU3O9qI9qEtNtEYzf1SHjyR2Ye0lrS
nZot5wa7r+YpOWxrg1VLwjTJbMGmrdSfBqYRp15gS1t0sPBoXnB+1UvJ2t17GpF+Imj9yahjuNJN
vukauPJprz6ZKbvtkaH2P2n+4w3TNaL/AJYGlGbrBX8rdohu8M13/wDxCMYuQpvFcs9PT7pJjf7x
ml5yS9z9SLTI+5ZSf3P0LIq8F/BRfRe9mc9v79X4P0HKJtkRoZKNl+X0lTI7vB8Ublyja+Tu9i10
2wvkUp/UNWepJHND7kxewq6bn4ZkyY6MYyMPBYmbbOLO2NG3wmd2SoDMsTSz0ZkbobNvlEvsP8Ge
ej2kVI+B0ONirno/Y3SWTI3E9jKO1EvcXNCS5Ntl1yZdGMs30jkZFrlMR9Kvox9FRvme1DjyhXe3
ptixxk8nBxRG89HXsP2Elwbn0yUWjHFdUR/tE/kRIfuOhdMdP0L8kfsSJbiddM8EaGfoSb8Mj7Go
UyW0j0jXT9Ce76rEagtxJx9jTJWRUcEkRr2NS1lF+DVI7l5Lj7Gn9yRDB+giaki//L8D+5NkaqyP
2KJKVcGq/Fj+xGUvcg4kX8ifwOK+qzSX/iT+5sfNGu/cX2Iyfuacoj+5H4iamnedxo/Y1v7jbN+D
Xl7oiX7s0XDw8k2Q+IGvpfzbjR+x+0v5IQmzXl7xNId+ZH7M48Jo1vuQftpmtpfzORoL/wAT9p/u
FCXB+0Pw4kHF52i01PC4NJ6380qNaC86g5TWUrJ6Ok+9qzdJU3+8fTTGWRS8C6Wlli/tEkKRXmhP
wLOei+4v7f38a9xP4Giy3xY6HZtEST9xNEF/4jXgyY9jbLhnyObGolyTI4oaR22y5lSkKS4ZXSKX
uZ6NosZH7lDZhMWC37DO3k7vcwOSQoNY6T+46MjodeR/YePwQS6NM9iNjGND+w75NOvfpNdG0NSX
kowjYuTe7rno6suN18i3iSl0/UsUfkVjRa4Mmc9NmmLfm2Koj04LvN7PZnbdieq+7p2l9I0vJHBa
R80PZa+Ud/sfp1iRr+krxZH7Eq9xziPcIe03T4Rn3MexS+myCfsTr3N2nkm2I7RSl46V8Dz2NkE/
Bq/c3aX1D3EIlIvU4i8DEvgtN7G8kU2apu0+Tv5ryaaHFZv2G5XSZJtkV5o3Qva3kima2S4c8m6X
Jpq+WSSd3jA272krZBKVti1I8N5EpOsjad11z7k9uU8F/wApTl4FG82Q1YryOLwO3hIivixbvBFc
9xKn4olq+GRUnwh6fG6Xk9ZcklLGBO+2iF/dC+GNJ3kqPtRv9xJv6USg8OcsHr43FPFojP8AlSIZ
VPJ4qLJaf8xWFtjRvVZIwq6wT05Y9SR6zqz7xIz4ihK8PJakux2akI83yNJ/THaepGlfJGPND0pO
t8rHr8uz+6NHaQlk/tyasKVJi2rnTovURppVupskvn96mbPMhyJfA88GopPC46IXRn6kTBufBz4M
fvofBtGUhRHbGeo+jZFCV8LpIX2NyEr6ZPBsizL6OiiMbOclNncVdkM4FbO1jgRkyhs8GSkbbMuz
tVHIm82b/JRJ/PSiC8Fx6Nr8CnLwUOiKfFiSx0oX9Q/sOhTmYG0KF0Z7kNxjRyJpm6UbfuWuBxs7
o2dq2DzZTEvgTX+RIvZ0cW+WW8mDPT+GhPHJgtwHWB9qZ/DiOmK3SPdDjwOz6FI4SJdqNln0qQ8J
GH1sUZvgWKGosabxJ2KXNjrAtQV5Y5YRV4Kkd3g2xY+7tbN2B06N9iTeRyxZiWGbZM7mhxg+Gc8v
Ju3LnyY8inupoSbRdrix1LBtlxR9ceCUIMuy5aijmsna02b3IUZS4yS7k8Dd4O544P4y4JRhI3Jl
6s6dm3TnuY5N+SMdSdRHtnZz2lp4F+ZtaX/J+XPtM9cEVqN7LOx5L3YNyf6Ebvgex9hzkrWt+w1p
YLYt2YXkxGmW5YFKL4FGcLZi0uklqx3YpMaiqscmJruzwKtNxZKTeGb0+CEHp8f8nsIyt2KJRjHb
ZfJfOeD+FTHJvnwKa5QtP0VP5ZxsS6cbk1Q8KF4wW8s/L97Keml8jk2b48ihKNpCvFexujhkdOlg
acUrHKPkVxXFHESqpDfv++WTZst+5J+5JVyYPpybdhmBSiXRuaoVcI+DA1x+/tFUUyyikizBhGVR
uRhGS06PcwunDZlFUbiqsqmi2Wcbjg5ODijcc2cUWcWcFMtH02VRuspo46e6OLPYTXTC/U3clPo1
X4Eba6WU0VXT3K2nsWj6D2LKasrYWJVwfSU8G5PycGY0i2JlGeDHcVsPYs2vPTcmcLqks0cUUz1F
yKjuMFCkUzBgqWC0YkVu/CmmVvM9KUsHc76draKbZkwfU5Hemn89Khuo776dl/oU4z6/WzL6ds2v
sd+59OyMh7vUa6UjKlRnp22/sZ3L7narMabR/Dkd8GjtjZ/DlR3waOyG4/htH8JncmvwUi46Vo7l
t/D2xst6eDODtL2YKnGulwRepHp2GUhplLk3KJU1XTtWDu46dqM8Di/BguPBWov16do7XTtRdjUs
NFJG5MqfkowW+OlR/wAj/mHGWGikhTR3rpaQ5SXaunajHJtfP79UWbPYscUJ104Lro6RdHHS/wB/
SE2jCHgyi1X6HBS6e5VFsso+OtIzyYKN0ztXT2j04NsTJhG2sm6SMHBlUi+TCNisysj2oryKWoi4
nAnXacHwbUK+TCKoUtRUdqOPwKMRWrLiiqFLURcVkeC2qRiI2kbIo7l3DcUbayXqFxRwJv6SlEws
FJHfHuMI21kUtVFwiNUd6pHBaRtSO+FsuCo9PyXqqx7Y0cG6a7TaoFrgpLB36abJbUentdilqI7I
JG2i58G301fuNxRVY8i3QjJ+5enGhp/gSM6aZao9MjKS3H0KI2hM2vTR6kGq9hQMxUhtUmO1wynp
Rf6D7UhJukzEVL9D+HH/AAS1IPj8KcoiVK6JQ5yLCOIm6HgTmjbSN+ln9DZWRNxybqoz7l4Pqicq
X2N3Bt3xHhOycXLa4n8SK/U+pS+wtvPWhOaKUttLydr3fg2oT1I0OC7mjfGPIpyVo2vDHPSjQ4yW
UzujtaJJJPcKK4sucT06t0eppxFqTQoVTN0IpUhxl4FaSG4JPdg2r6Gy5RPTpOs0erprkjqTFCUV
fFDlGKVIamuBWlxyOqduvsbV9O43SS/U9HbG1kjq6fLzQtSQtPbD2G6VqI4zWasWFwSSUe90Usad
mUsZPTxfJDU0V3SyR1ZrPBsdXxQ5xrdGHA4zV4sSlSswlU3RcV2bqG2vpybMYyLV0+Wtz/esSFOh
qkSb5bKSHJrJ4whOujxRjJwVQ6IrxZhcjr99GbESaFg4Nnks3Vkosk2vPRqlg4MI2DdCfkpljbXD
6OKSI4MGz+YbN1ZKZY5tccdKI4xZhG04LrJksT25RRQsGFRsLo3VnpZbXTakXXVG6svPSzdXSS9h
YMI2nFjddE/ctxuujSODCoUPc9xuij7l7ejQsHFHp+S6sb25Z7ljlXSQrRxQtP38jvI8GFZZddGm
q+D6TCqjZ46N0dsdx+g8fgtrB2lSIbObyRxkalg2rLoi5KsHBRvrtsk4m18m9cj9DwP1eaLfCFDR
5L1XySh/M2b9WNoxpjnowO5eRYP0M+5WjLbI/PdqySfI38GH2Lkhf8xfFyIq7P0ZH7m2Mtr9x1ru
vuRWrbIJf0nqRni/cgpeCfp/zFXV+x3P+UjFZZBy0YsdaSTIweYshS5izOrUfYb3bkV1T/8AIm4n
qTeJMdrwKvYtS7V4O7LNXBthKiGnJtqvJB15J7cew9WT5wRdeEWkc45+xPd3MnjwQhBtZ8ENKTwQ
/uJRjjA9Rt5NK1/KcfzG7ODUTyzjwQhCTjnx5NPTkL+4pf0olrO8ml/YS/vHK37mt8Uf+rNLa+Ga
UD/2Gv8AwolqtvJo/wBiP/cnqL7mvfKaP/U0696NHS4+D/2JwXmCJajzuP8A/AP90+un9z/06J/J
nksojfTtfJFlMvpaIMftf76DGjb0Qn0ZYvt1fSiLF0bKH0YihdWJdWLourK6sXRPox/gZ+hLpH7i
/t6V1b9xdF0dj60YF0T6Mb8ldGY67ukjP4V+FjXVdGWL7DGOiX4Pt0kovgViORNkfahu/Bhl3kZ2
vJwd09o6zgWxcm6aGj/xZj+mzZsrIr1KHOsmEfoXFZFudHZLcNn/AKksZsj9n0j9hfYi5PbG+Tu1
BelLcOkZ8RFpZ9QjXDNnuKdHs2qFeSC3krd4IV4Zo/2s9Fwt+5bSqRKK6r+41LNKKrHIxGpptrnz
01CG7+o3/Bp/clLwkQjFi+wvuT028k/uS+xpSk/JDUXFEP7icvZEYrlGn/af+xqQl9kakvdj/tNO
b43EJx4I/wBxKftFHp/zp5NP+0l/eTg/OEa3y0P+1mjh/UaeouCP9xqS9onpeVk0v7Ef+5OEoun2
o1/uP4gzQe27lZpa1YZD+81J1e2KHpbWnHJ//gH+9g/Yf9huF9xWUOSRFMdHBFe3VmEQsfx++imS
aLfTA+joWPPVmemCq6r7mTkbRnrVPqqXkz1bYvw/qZOTHRGDbTro0KvcV9MGSXuPoj9CNe5no66I
x0oaI+xb6Oi30wSxjoy0W+j2lvrJVgpkqLSs7umC2IpdK8kjcsolfnpg3SM9FGse4rHRuhkdj/B8
WSJWQoXuZFRn2L+DJ8WatGfcfuXpw3ZGp84KqzsVv2PzIuKIy5oxzsotQ7fc3uTUvZjhGRHyvY/9
TvNunyXqQqmNjj/4m5fRZC3ihelnIlqKsCUI7nRs/aI+Tf8As6F6kKyN/I/7Ra9dppp+EzTfyQKs
ipe5Wk+6zUjqPuZvX08mmv8AxFqxlcbsgpDkusE35PfcSl/KTjuyjThf8uSGv5Rtlg1M88Hj7mXd
LkglnI64eCTXBJfBDT88i1kknY08E5eOEK2qQnaNOP8ALuyS7lTxRKUWkvYrl1RDReHyLXxuJRJT
a7WqI7mmqsXtHyRjHxI5WcEnDF/Btit0uCOjJpO7I6/83uSX6ktR4xSI33YE08QI1W1S5H/5Yobj
237ihp02lRDQbXuyP7Q/q5uicU73ZHOXDVURl9SSIu/pfkjWIqV2dztydUSccKj04NPG1jr99sbz
VDv2sknVGPYkm8Jifv0yeCkSozzZKnk7uLLXgaXH76KFb5MMwU3RuuxpMpikzDF7WW2YwYNrZv8A
Jhjst5MPorZjBybW6N1nJTYnaZg5EYOSmzd5OSrLeeiyc5KWCryKLZeB5OS3kxgVPyZ6NJ/gUX9j
c8mMC9jLMYOTa2X5GrGmJ89McIuzGCkxRk+jGm+TdyMT+Tm7MYKTFGRgaRT8l2mXYmn5OR+DbFmy
WK6YO54bPcs3/wAovcb4ZtTNsnk4/UpM2t4bL5HQ/wAFpKh4G/KI+4l5O4X3EvDR4qjAmqpEq8kn
5FBvJyh3JH1YZiSLc4/5MNcj7ksH8SP+RxdSY2J71EreuPcTu0hXNLHkv1oslCLKnLDHeouaNkHw
zvlttn8dGdWhShLfFeSO/Vpl+tbHGDK1J1SP4wo6OpbFqS5RprfTvI2neSM74Iqcnu8i2PHklsl3
G3Vk9tUfU7+StGTG27/Alq3KKJbMYLbs3XgxHwYfaJp8G3Ug5scYRcS2R3JyivB2QobbLibZR8UX
4E14NktNS+RpLb8ItkWkmo+GJekrHKTN0eRaexYVG5rb8FocaUrHF4vpFwf05orbEbvk3RYtPDSV
Fy6OMHhjUnzz0i9GVbfBU2iT9zdpumbN1qqFKcrZZWlPD8D9Tz0UtKdUU5D+f39pjio8+R6tdzFF
qi0RiofScUfQitpbH7Hady5LRTVGf362spqumGbWjJyUsndjpjJxRZcWbWv8FywWmVyZOTtyU00X
5MGxxMlorlnt0W0+mjLOSttnsWmVyj26YKao5LQltstracmO4zgyYZwc/gtFfUcbemGZiOyzbVll
2Ve49ulr/B4SMs7WVXBbOTadyromjN9Lizbtot9NqVoz07P8FSRktYK5Lnz0qDO7p2f4Kl03Lkrw
d3JZti20d9r8NabaNsnIzllxdM/mZ3tv79EoSeDvb/Xp2MxuM8mHTOzezvlI7Xk7ZSf2M70Zk39z
sszvO6Ur+elxhL9Du3xXycnZu/QzGXTtLUXRUsGOS1puR+Ymvv0vTjZ3abVdKjkv0rRU47ZGDdCF
xO6FLotisucNpko3KG5FSW1/hwb40VqKn0uFHesLp2l8lPlFI3R8lTRjBe7A3JWjtR9dG76ipqn+
HtTJOWUjBe4vLNkuTGDFsa8ieVfRurSGorgu2XHJ6e13dG6qL5KmnkXKs5bHKsLptSFqZHDyhYas
vLGpL97npVFv2PTRuHp0fJVGelUcHBZXszgr99SFKZhDxg4x04NpnDMZKoUpf4MIqhY7ejNsTu5O
0qsm6SO0ZddvR4FFIW9ZO2PRS1Fg7enGD5MI2xQr5LUTabtRHah4LqonBhG1IW5ZO1G2jfqI7V+F
KCsjvjbO2NI20btSOTticHcu0xHuG0jZWDujk7Ym2sm7VjbHticYN0l2GIZLSoqsGY2y4o21my9W
KZiJwbprtK2Jm5I208MVwtnaqNnkUpoxGn03ai7SvTG4o4NuxMbSoWntwxOUU38j7EmYVoUplbEO
URblSEtiZ2qmU+tIUpFbF/g3afJ3KqZW1MbSQoJCb5+R9qX6FxjgUpo+lV9jdpnciqX+B/1HpuJf
kd8n5awKUynRv0uROcKElgdLuHDbhGcMak7Liu0Upr9Tbd+Bz0sMe5YsWa+48ZPSrAm1tHasuC7T
fOJt3Y9j1dOFM7leRK9o+23zZ6dYPzI065JL1blXA6E+UO45O3j8KdX5Ixaq8EtSMVcUST4TO6CR
9KyLTX0Ni1NiZ6TWVli1NOu7OCLl7WJSjzguO1UiEtq4PQ25HLasmrHsde5Xp7vkvZUaumiEly/Y
7NO0Z0zKoXbgT8mqqG/O2xJ6ak3xgTcEsWaTiv5sn2NTSVdnJHVql9To05x1IvxTPTjoppurRLfi
3Rr6e9JpefJ+WozIblytxpakns3SJPRrUrhD36WxDnqfyxNFx1U/DQtNaa9O+UP1MXLJq6Wl3R3c
kXOJBLi2azfHqUN3tUXRr07SVWPU01iKt/v1Oj9D1HjxRH7D1KGiTXvRwdyRdFDwPA8cngbr985P
o17Cxyewo+5wbqz0v3La46baEYRtL8m+qZRdG5rgVGw4MG0uhzrpZxhHsbfYjgwJe42bqz0v3Lo4
NhwYVG0+45VnrdcdNhdDXWMqzXSy66bROjCorpddb28Fm2hYMI2l8nGeifubqz0oVowqQojZx1vb
0cXyZRdC06w/I8WcI7VZZdZPkqSo4L4oUK7H5LLSO1WJj8dUvkv4K/kNxuo2wH9i6MG2f1CteS68
FfyCZuoqHgtouvB2o2avNn6jr2P/AOGJm6vJthjJclx07V4Nup7mfcljwSldxE2vA5peRRhhWS38
0cHbzRGGpmzK5Y69hyvtRG/YdLybYOsk1LwqIYEoy2jfqZM8e4lLkcj9fwJe5+gpRlTWR6E8yvkc
/dkkbd26K4IS+Taetpv4YoP7GnXsR8bcnpSd/chH/wAT1qoUVwT2S2tm7VuRzWCLrtTo7+0/L1FI
7Y7BSrlCilg1dvJKH/jRG0JL2If3Gtp+6IyazI1P7EKMbN01fmycdN5E5PLZckv/ALKj4izT0+KE
/wCUuqVGzSf5fDKgbpZfJLS0pdzZLVaTlVs2wVEH5yNy/m1bP2jT4TZpNcTayftX9qX7/T+xgtCs
sklyP79G48jb8GSyRIlfgzz++l79J+wukJfPVi6yF0h9+rbEmPpJ+BdF731f4JUIZH7lFDF1YhiP
t0f4G/c/Ql0RH7dEuti6L79X+NdGMX7h/hvohPpL8GRi6J9GPpNdUfoL79GTsx0VirkX3P0P1F9h
ktw66IpeBH6EfuL7dJ2OhkbIxjh9P/U+bF9h/cdkmMX2IpeBfcf9pVZsX2Je9krJyQkKTVlR01HN
Em6yRXjcI+b/AAbl4I44iP5Q5Dj44JEvuaaXuKflnpPgUlyQi/ES4+UK8og4f0j0L7eBSfk1HXbZ
ntr2HhuPwR/uNYvSZ+dbRp6cruBH0ryyTn4ZqyS/lsitLU2EXqu3ss0/7jW1FmjTWxx2mrBZuFEZ
yXg9OC7mqwbnFlxg7NsdVw+D8x32GglHhibSweno2lFig4NWRm/6bPS08yarBv1LaJpwvG3I4enF
foRn7xZp4UanR+0TSt7qNJNfRR+1q6wv38InaURfubSTGWjgaGyvYfyh17jsmvj99NMtZJNkeix1
whWPJaJN8CMCrgz1VjLRLcIwRXgz0bQmzkwS+4hi6uhX0tDvo+vyYFfTBno66JkV8GC30wdwjHTI
zAm+mDOBdPdMoZaM9LQm+DPRlDE0XLnqr8CKP1KGhtDs+elsVlI+LKHRKUTJP36xF/aL+kS6N6Yy
vJjkUp4MlfAv6ORZ8GC9MaHnwLbybtQpvyOP/iJ/ypn6Fp8sc9Pka4GrQjfL35My8m27wKX8nsVd
YOfJu03mySZV+CMS5ZIrd/MNLKo9RfT7CV1g+rmRvX1Ek8HP6ijGVWhNz3ZNpuus2KD9yWpGapO6
Gn1UfDMcbTDHF+BP3ZONkovJBkI2etH6RL3Iu+UdssoV+MEEn/KPXUnfJGDNaXJa1HGjue40o7lT
dkocxl7GSW2S4EiLfNmovk1tNvuS2ouV3E5/lo0trwnbYs3u8E2u3yeisp+TRSXhj1ZbvsVtd+5+
0abq0XGPBTx20QUX/MThXLO5NjcY1JI0EudrHqPORRcPPk14R+lMjq+ZKiEfZMg3iDe4in3OWWjU
cY7F9VEtNSuL5/fq/BzyiPyKViheBt+SRtvo6JZ8E2+LP0M/SY7cDiv33wZZaMMUWzeslJmRWx0y
vBlnaYNrZu5Hk5E2zHTLMdEpG7yPJkTux0UjukYOTbJm7ycnODdd9KsqTMGGbZMs5PqF5H05MDQ3
1pifPTt9zLPYpCjJljyc8l3ZyLOLOem2LyKEi76ZdWKV2WJrhGXnptTFCT4LHTGnxIUhu6FK8I5y
XwUmbZyPgdGX9ZayWKXGRO7Y2ykzbN5PgqLybX9LZfP4bNs3npsiypPFiaZh8o3p5OfF5G2+Dtlg
Sm8jbaqzbDg2/wAgpb1TNsXlnq7v0FmmlmzdvTf3OcG3Ul5qy/Ui0bYMXd23wJ+pH35NsHlo37nY
lOe2kPbNSY/Y2TlSvkcvWTKTwRrgW7UqXI1py8G68+5WtOqQ/SnuY5PJU5dtl+pmzEsEZbsLwR3y
d+RwhLtaPUsSnJ3RcW7Ki8H5qz8FRtDVNstdU+TatN8eCUYw8eRsalC2zaof5HL3Iy27qfB/CopR
2oUkrojF6dUqwSXpJeC1gfapqqP4aX6FcfYkoxUkzOmjGlX6C1X9S4FDDoaqJukJmxZTNvg3xdNu
zO2zI5N3ZenKqO6RvWGKCn2x4OUbXMepCVSeWfVZTkboam1p2fxD+IU9Tkjp+p2o+sp6g5PlkZaU
9teD+J/yXqy3MT0p1Q92p8NF/v8ABSV4oUpfUbOF8m/ybfBdWzg+kusneduCpcFo2+F/oMMpoyYZ
Ucnd07TODJ2lHcWivB3Lp2ncj5MMpsstG3lGV0xk4LMMrwWy0yqsz05szFmTtK2FyMM2qF/J34fT
t7jMWumLPoZb/DUcncqHZ2G1xr5LZhlV0+Ttyd+Olx59jKMlopK0dxyVHJ3c9LhyVJYMstM2v6S3
0pWzvvp2M4wZZaOWzu6VCz8xdPyrv4KnfS4fUfzf4MvJZUN1fY/Nv8Ko7d0kPff69Oy39jvUulac
mmZUnH5M4Pkxukd6o7VZhOvY7oMwXCLPpl/kqXJyfU+va3ftZulC0UXDTLengqSplRW4/hdpU8Pp
2Rs/MjR+WrPos/h0fmwo7F/kvbZ3xo3QWDJdYKnyUi4I2TWSom7wbZ8/hxgt8FeTBadm2caZg3Jt
FyzHpy4l3uRXBRuUmOElkpG62i2tyMCu0ParKlhmI4LRs1IsSSPZl7W0URdPI5Zoafg4wblY4aiE
o5svMRSeUYF2sbS4Rtksj7cFxuxwl/yJJWXtoTp0JLyRtcok4fyq2U8P9/SE5IjH3N1Cil5LK6cF
UYibGi6NhjLOP3/auBDaRsrJFtZMDNzOB4wUuDPJhG6SMmEcYR8nbkf4bku04L/lOB0fLL1EOkcC
jHLZ3q5DN0ldmUcG2MRb1ZiOS0hSmilEvaZXaZgPbEysH0FKJ9I+qUVgVxyYRVG6aMQLSN0lgrad
qPToXbkdRKo3anJiIzc8R+StpaRVV7iW2x4NijZuksn0pDdWj1JlbUNxRXgXamYQoRiXKKbPpSLS
wVWBdoxPwfTY6ibNuBN5OEi4xtClNG2kOUEd6qNijSr7DpDvj8CTFSH4Z6fgUqyVJItcCk+TY+Bz
jQ015MYHgVI22Pdk+nBUXgatP7Dmlko4fSkKUokseDUxaFnaUpqX2LUclyibefg9TTVM2uk7MrwY
9heoX6m0qOpvE6MrYyo6tstx3FNeaP4lHb3RJbV5IvwfTkUILyKco2jYqv2PUjFWSi/HVM7or7kt
tSXApRwb5Rweljd7HqJZfsKT5RtaiiqXF4Nn8vJlL9Seyn4FOD2ryjez0VW49VfWzdLwKM0jHtZt
5jeBf8mqof2m5IUl7C/Z8WepVyZKclmLNs+fY91tsSa7ZMzijVr+03QXaRlVYF+z2vk9RK3Jk5NX
KDNj+r2F/NUbI2vqFb20av32r5HKNRiuSMorLjZ6SluXlinWZvknKr2Pkenfd7Ge7bCyEWlnwLd2
rgmnGnJ7UjV14LsUq/fqTXk+xGfEUyKRvoZP2stKzuVD6bkjPsOQom6hr985tZLPkvwhOhqWDtI9
uaKGXXnokYPpwK/Y9iodzE5YsdF//Z4OBOSwhJLpwdqsuSFaswLT9yy5r7dJEDtjZfpjc47WYGpR
rqkkZXTCO5G45yPtx7n6EuqlWX0yXXTYcGEUX8F1l9M8l102s4MISLG6z0+5uro4vx0whIstLJjP
S66OL6UvOT9CiLo2ovyXRjkqXJwXRt8F1ycFQLY3X4IyaLiNPki0QpD3DhyZWaLF8uhz8NkmsG1v
KIyrI3CVfA9+aJS23RHZcEXNm33ZucN5XoIco1H4FJrIlRP7ErRFb/TwfxHPIo15JUSk32sz4id+
F7na7VEvsfl+1G0jKRH3Hp6kqjxgWpGTs+0TbCVLkTlbyUxx5pi7TgjJrFjr2RLX3PIr8QNReOsV
XgqPsaabbXsxOvI69ierb5IX7Gp9xJXRqxfgiKCIfL4GL+0nrfJCzWRXsasX7EBwNONZbGQr+k1N
WuHyaJ+0/wBwn5NePjYaX3JR+TTrNskzSr+k1tXH1Giftf3FdXRrx9omj9yUJYVmjGNPPg1DQX/8
M1tVZ7j9m+zP2v8AuQt3NH7SvCiaJLc67j9nS4bP2j/+Z+/X3JMwRj7FkqJdHXJJewun6EzV9j7I
n+9Qq8DKTL8tmRtCchfYdG3wUukf/oTZkwVEU5rPSuYo+w4tlR8lLr8J9MdVXJR24yIZGL6cGFz+
DPXPBjPRm1Crk5H1h0XViH0fRi6foWLovuPrXVsXRDH+J/YqLrNGeaL9mL7D/CvwTGfBL8CGNRYr
ZRyW+BfYefHSLvPsMcU/JH+ke51kltymYOCVeDLtEq8GzwJb7dEZL3FZIk4iep7C9Ii/kf2FHy2S
/sH7kr9hr46KTQ/G057CMnHcrIwjCmP+w2CnXix6cefgctSdP5F+bEwRzlsl8Uenfklf9BP46xfw
QkQZFe7JfYejfdYvsS+5teLwTfuIWoab8Wc+T3wamlTVSNP7Gt8sqn3KjVk8WiJuim79jSltrIyN
eIGpouLXcaX2Nde7I9ra+DUk8XE08m+C3WzSm47UmSyadZqBq6Li13WaMfaz9r/uEow3QNaUsXE0
i9NbrkaUpx2tM1H8kGvGlwaujOLSbuz9nj8H7T/cXGLceDXlLmSRpfYvT53H7PPUVZ4NVXl6v7+m
/JJIoU6NpZqe1n6FDLXsOHt0mSk/JT9h/vpNskOyC8DYzBC/bq2x0Rv3P0I7XixX7FtGCSinXuPd
0e0u8GTauT9Oj2neX0k/HR7c5I37DOzBmVl6jvpgfNCvpHbdWdx2nY2J6juQyUvdjoeeuCCMGTno
2xDE1x1wW+n6GSIx+xR8ioz1yIwMaGjBnpgtn6HbG1YtyykPAl8FrpXv03SMlfBf8ohjcB37FX+C
6wV5JEHDjyJeaL+TajPsOvbomTSFfuIvT9ypEjs5aL1e4jKqJ+9HqfVAtw7jbCbUfYuWpZKnmiW4
qD8C3OyH3JQTuz1P5R5rtLUqKbvA0pbcChJ38k/0NRC8iThGDrJvWqn8WTT/AKC/BCv6Bo5oitzI
3I9fdeSefZEtaNW/BKN52UOfVJ+wlfgtO0hJPhkleOB6yas234FBum2LUlV2PKwNvEa5IqXcqO10
jbHxLJV/B6q+o2Kp+D05utzsWrLPsOpL7HqyqiF92MjcXtS9zbp1V8jjKXd9Jv21IWnFqx6Wo8yl
bPVlHdfDOfB6rwuCP82Mktq21kcNN9l8m2b8bUKeza/c9LTlcrPQ1JYnK2ettu+GUnTa4FrylheB
Z3UrZqS+mioz7LNmo8/ShPaoj0tN/SLS1Z3btnrYybYyzJHqynmqQuMK3ZOa7ducDV9l/vH1S8Ft
22QkvEj5oSTwPc/5Td79LMGHyiUmYY/ZstG2L/0DQze/cobRG+BfYddKXRT9mU5F1ZRl9bQl5PpK
4JUX/M+lP3Pcxg5KkxtFDlISGbZYPEjGDk5OOjybsPohPamexSMvyOh/gQnYykypPokmKLLRyW3j
oylwdz6UmRjNlodM5Eyy14MvJkpMUJvAmuGYZbfJgdjfsLORs2ReGY5KY/Bt8CcT5FK+Gc5G2NJ4
FHUeejUWdz7X4N1j9xu/wJqVUfWv8jf8xW6ivUj/AJGt1lvAvzFlEmpp49xNcCl6iVe7Heqv8lrw
R026LetH/I0pEnKVJozrIv1Ykdst2R7tTZ4P4yY4Qalfnpc9TYxr1iTT7RbtasFx1rMPgUNSVRvk
lWpZ9QvW+n3P4pnUySceLwOEpVInt4IteD82T3Xkw3ZKOnLFUKbFFX9G039N0laFUHV8WVGO0W7M
bs7Y5Mv8LUo7hxjHbY/kT+qKd0YhUi2KSYtNw4M46Uqd+41JJIbE4OqyUbpFxdC01LCO7p+XLn3H
vfS4Spo2ymbnllxwzZDUx7C9Rljelq0VPUtFlwlRtetaNzy/cxhmyOu68I/Nlurp+VqNWVPU6Jwl
TM6rHJ8s7XRXqOvYXqO66dmq0ipTtf6HsPzCovDN0uSk8F3k5PJubyVJ4LXJt/lL8lKWDPP7/wDL
M3R3HaUd5aNsZIyy3ydsqMcFzO1lLg7jDOemWdrPc7+i9MqRuvJUTJ3HaVVo7jDPc4LeGbY8dMnY
zyZO19O7gsqOTvLO0qS/F2M7jJgo3SLspZO/g5OxncZLhZWzBcjB2p0XNV07ZHdLpcZUVubRkxZ/
NR33+pyfl2fmWZL0rKlFtHfhn5V/oZUl+h3N10/LcnE74tHyXp7kdyZ3KjDNsW2XNdPy09vyfmt3
+HtlRiUqPzVTMHY22XqRPYqMpFtOjvR23+hiMnH7n5kaPyzydyl/k229xaujNn5jz05fWkXXaUuT
cqLo26n1FRRdZKkqfTs5+T8zk7Dk+s7y49v3L3qzvFtxZ/ERu5KkqfVKzepJpmybz+GjMto5J7qM
8nkuMjbPkSSL3tFtXHp3YJOD3UV59jjBcJOzZNfqUkX59hXFtCSO5EpR4RtkqZ9DaLjdjjPx5Eox
tFyWRNJuL9yjdKBKemuDa+TMcHbHI4TVCSXJbj/kUquLKR3RJzgvp8G1/UW44KilbJacuPc4wXix
Sr5IuVUxyS4ju/0OC3ErjJe0SrAm0bWs+C6OBYMRIqsG6hQWMl1keP3+6XHR4OCuRtI2UJzidsSq
N01gwh4FjtOLY6RsrItyyYRwbpoxEtIX9NnGTCFGKyJyVsxGiqN00YicCtdpiJhG2KIuStmEYRvm
j6TCMqoiW0dI2xWTKuRhIwjdqZZ9Jhfh9SZ9KMGeClEbo2IT22zgwb5H0ooXbZt2r/A6PeR9COPw
pJXEWMij7nFsrah4KS7RKh4M/SdsV/grYv8ABwLbyfTf6D7f+Bf0o2xRwd3BhGRujahbo5LaN0l2
+xGC4H7/AIVZ7Idq2bKw2JpFSLiiLaKfA5xjTQ01wxPgaaPpK3UO+4bcDEq/U5sc4pKRUU3+h/Cl
/gzgpCc1ZJ+xO1gWdqO2e8vbkTmr+Slk9SMcm1umZSsljg3P2O+W0/jIgtN74m6SoenGdy9jMVwK
4i0pupsco5XB2ItaeDOmRjJZs7Y4N8IdqZnn8EZNFNLHkxxIjJcWRnQ9JVceTcl3VYpNEYSq26RK
80hpoe6tqRcf5vApqOLybuB6X9IpJZeTfXBDSdW3RqP6qRTWPBTwil/M+BT24suttD0rtR8kJqOX
kU3HgWlzJk3zSKdMV4RXmT4PU2qtxdVix6f8kfJpyrnNm+uJUf8ATxuU7r7E3V0khx7W3kh4vCXu
R9RZm+D1EklfBfGLJRrsXk0XhY3WKdLEqF+zxV91P4NV1aqlZ+0aUZYFXnSonJq1d/6B346e6Q1f
wJ0exCKLHeEbUZIyS46WR0pDf76MfAqFp+7G6MIwW/YcqMDsi6MGwZx0tjnXSmcGEKHTjq5+ejsW
Om3phdMjlXVY6KPTCMFl10dkXXHRR8F0S6wS9xfYySotrktDRwWOyO3kWPBngs7TPAmPuyXVRHY8
XE7oHbpkUo4bF2iI48mDHFncMwV5HJ8G3Sds/Md2WVB5E9xkeDB89OzkfqS3RMI31liOCx7T9B/g
UmWsEo+xGXsKvYySjeDbzjnptN/uyVEovwQL31kp5J0skUm0kK8i017m5QT+6K9OK/Q9pCdWJUTi
ayoiptrHgW139zTg15JUTfuS99qHuG17Eyvgp+w9tm2X0t4JxfFnqRuz4oiiOpJdyZUfc7lwylJL
7lcmnrQVZIMcXmx6umjPX/1Ni8kY/wDBpr5KR6nuxP46b/MSUWTFEgqoh7WYPUfJF/8AiSPUf8pq
xP0FH58kIoj/AHCXwerh2af9pJ/JKTq0jXR/6kYt1k0YRqvg/wDYiv8AwR6kWrNL+wl/eTk+UrNf
7o/9SCn/AFYNKEeBf3Ff+KHqwy2zR/sP/cm/5o5Nf+6j9pZF+PTtiwu9jkr2t/v9U/8AUkKPgyOi
LL6c46NdJCvo/wB6hEesmL7dZi6Q6sXTJJoXSPRjF0Y2hdI/jfy+iEL8LMdEfbo+sWxP4HXSNDQ8
iQ0OmJyYvsSPjpz03y+m+D2JJMizKNqwbrTMroqRwcr8CGkW1no0mK2R710mxmDd4Qu+jtmpdOLF
7FjRI/Qdfgj7+xklGJtm/sfAqIuXFia4ol70XeLIpfVY7KXuQb+kqb7h7OD36NDlL3J7PA4yl2ix
4oi00hO8EjVE5rCR+WqNNv3JUQj8k/sfcn+hOx1DdaO7Sz8ie1JEMeTdzkentqj3pFkdPYqfkt+T
UO6W0tau5mnCMryQNvhkn8Uaq6v32kJeE0Kfg0/uWhQpquT9BIcGnc3gbfJP7EJxjuVpsjN8EPuX
HOD05RakuSK/8Rq+eBw2YeLJN+SXtRpz04783g09Sa2kf7i45aR6U4tUaf8AabV7jioPbLFmpeLL
/wDE05aUdzvcaWpqraR/vJShlqI9LUjwaf8AaY8zJVG4ydGqn5ZP+w0n+z/Ve40dXVxKiGeZGs4f
Woqh6eqqXg0/iBFe8xtL8qTyTT8yP2qUcqyVf/uTRvjaaH9z/fzFX9JKzdLnk22XzZF+OjiRl09P
wxjPUY1Y6/ewYqN38vWoi3DMEt2PYWeifjpyJRIpnJgluFkwbvC6cnb7iv26YHfW6x0aO0XTB3dd
3jo0Kuro7url4KH1h9yN+w2MtjHYq6x2+5G+aGT3e5j2L8CRhFRRunbFEdG5tovc3Qo0JyVCJEXH
3HuKLX4HGuwyiorInbqypckkY6VfJujhHe8jybVWBOfBgavgwMkr/BFjQ2J+EKPmjd8iR+hJxKfJ
B/JJe/A/hkDEksm32J8FQdYLnLeRdUSjeWeo5Jj7Va8lKeDdLVfJNbqNSLd15ErrAlv3Gnmsjj7n
qmpG/BucqROO6yS3USjiUUc7ZGJ2kjSibPklqKTyS+xD7ENXdmLEtxrZyim6wfXu+WQSrLsh72er
5NS64Jy9+ri/ODudow8UQS4Tyyr58EpxwPTjl0RhfCI6k8PmytydE3LiWEZ7kOnRBp9sWbW8vwPU
qvklCDvBCEnwLVnF3zY1F59hzk63FvvjVFx7aIPd2JmyTuTfBv8ApZ6WlK/FkdGb7UR1JR+bNmnL
Psb5S+o3YlSHK9tClu/Li7FCX1yfkulEenpzxwLS1H2oU6i088np6Ty+BylK9xuuOEuWPbVp+GRn
u7U+CMNVrfJ+RtSh/k9PSltXDYtLUvZBVkjP1NPjcPT05Vfsaj1ZU5Plm162nTivJFw1YVwsnpr6
YP8Af3EqUvA6SP0FsI7mKRQ3Qq6KQ8i+5a8DjFlv97a5EpjkikzLLwOmY4FbycnazbJ5NxhitnOR
nOBWzBhlS4O0wZOcnJzgW4wdjKmy0YZngtM5P/ESb6VEqTLRhlSZaGz4M8nJ2sqTLQ0hvqmxGD9S
KXgaQz5ZRY5P3MdPgVPwWZZyWO3k5FtZ3DUBCdlpm0sdujcngx05wYaLbJO1gq6Zz/yNbhvdhl7k
civixS3r/I3uTaKi+kZbkj60c4Ypb0ik8jbf4E/US+B/mR/ySKnLZk2+qjmy5cWV6vgk1qJ4NyFL
1Kor10SpkdPUko/JnWH6eomT3zqzOtk/iEdkrLnPbngxqDjpvlZLHve2S4K9Qm77Wyt43CRz9iEN
R9vJ2/UPJ+dG8Yo7bX6mVZKcX2yZlf8AJt007Iz3cEVqQuR/Doex4Z3d0UqP4RUO0c1m3lHdo5Ht
hQpc0Rhsuj+CvvQ/5UX1T9jZt3ZsprajInDwbeC2XE2YqqO8tG2M8FN9FLSlTRUp4LeTtZs3v25L
1HufSoajRWpO49N0JUzM2X79NvrOlg/Me7pWnquK9jvm30vTntZUtRmTBXqySO+W9+/SlNod6jku
lptNex/El9r641Wl7M73Z28m16rKeo6/0PYfmSsqEqO92drMPJmbPqMys226L8lbsGeTteDv/f4K
i7idzvp2SLk7XTtdFN4O4wUpM77MHbZ3vp2HudyMMrdgz07ZGbfTtuJTkdxg5O9mDB3nyXB0d7wW
zsOXR39KizKfTsf6HdZkuB5O/wDDWm2fmMs7Gzls7uTB22fmZPk7Lo77PkrTbMt0dzbZ2yow3R3s
5Khe07mzJ2q2eVH4Kkzsuzyj8xnJ+Xe075M+SoTZ5KlKjsbLyVNnyXptpH5lv56flWd0nRRcI2XC
4x9h+pbPk3J1E/M7vn8Pa8m5Pt+53mDsb/UtmcG3TbTNzyVJFRdG67O6N/JUTDL/AODasMtSPqRU
vw0rNz4XsbS/US+5cZo2zVMpY+TE8myXJgxg7snNH1UYmjLtfho37mUcMuM3fsem4lybiYmy7bX4
KRct0WOencivItydM7GzZqKn4MK0ZtM4ez/6KiuS9SJKemuDa8MVxs7Y5JQnGvkVLB3RqQsXDyJQ
E5wJT04vBTXd7EXKFo/LVEoSX2MLB9O1iaXbyyKj5LnBMlqaaFF/VwJzSZhJfY2SX2PgqlZ7x8/B
2n5lWSno1us2ebE5/rY9iW6rJQkvOC3x8nMbOxdnuNucLr3NXVjXZGy/9Aki2jghJqztVEXJHgui
qI0cCxgvaJLGTw6G6K/fKCFaMIrzZukfSMUvBVFnpxFasbo3NGYmEiuEcWfSXQ6OGe3ROWInBXhH
BiKG6FKaK2mFZunycIxEziJhIxFHBlG3ai0jgWLY8ZY0uRTmjg9KhYNtIbofVJLAltycGFybtRZO
KLUTdNYKoeDbWBYPBSRclk4G4o3z5KHSO5dtiVHAlHyzKKLijfJFDwdy7RJRoeClwJVkpjcVkUpr
PTETu8MikqH2iS+kWB2hNYVipUcotxsvwUVtH+BHsVX6ij4bE6Mqy4oUtvjo2lkqi+DbSOKNsp7R
urRJ7EfUona9yO1UxqMLP4R3x2iSFaJPwakq8ne9qPy3uSFjlik0jt5R6lZo2T8D9/cca8lteD8z
CMX+p+XwboRwXKOCqyLFoi2iVIcF/WKVGzCaIPyKW20hwjCs0Tl+hqR9n1Umh7liIvKasi9uJCks
EorFYN23uWbN9ViyOi+WSbW6yVx4Zt/4F8rKIz2LJu4GrwuDdS4FqNU15I6HNvLG6tMmnHhnn4RG
8tq2RlSyzdxRK+P5TdSTq7I6m1cEdCOY3TJSavwTVJ0VH9EiCa7uXYp0sslitpPcnt/lFaWERml4
IaUE9u7uHNr6ma1fyqxKKy+DTWos7bdkZfzSkTxew1HL6XiJbw4o0tVfzIjpKDWmnk3tfXI14J49
SjWhH+akbuV7f6DaJ/A9Oxad/SKz7EIr3PkvwacDPRl+xHTfDG/37lVro9xDb7kfsZHQrWbLRRKX
gTQ1ITR2i3FmyDyXqOyjfJdMIv8AlFFLpIwS3GeiXz0Ylp8eRJ9NsfqZep0wL+kZsj5Fg+RN8CQq
JCo/8TPI+t1l9HYsHAo9OOOmTjo7LrpQnRddH9jgpIyXXSiLLoS+RnBgpnHSmIuhIujgpFPnq4sT
OD+I+RFjoz7EsfgjLyWSiQbP0NpOPgSXsNrCFEUvdnsSj5NNlvmz7EtvLE5/SuijHKsuODJxkT2i
jRJGpES1FeCWxVg0ojS9x/LNQ1YuN3wyyf3JfoNSjuTKjpix+WyD9Tkl/NghS+pib5ojFD+5Ld/U
Q97JSWJXyQ9R1kUfqVlqCi2yf3NX79I/ck/sbfkkvg0+kH89Mf0k5vNCRrEY/JXwaf3Gvg05RoX2
P0NTUfh9Ncgpe5tXCiaX9xKPg0mvNH/qQNTU/ms/U/aPsaal7m1cbTT/ALjUT4NJw8n/AKmiaup/
Oj/2P2v+w0o6mckkvpUDS/uNXdwaOxVY/sfs32Zrz/miaf3Nf/8Amk5+xFtWtm5iVVvz+9fRe1C+
xItCslQpvGT9OkH46bWP7DNL79K/fRjx0dC3kX8Drqx0xLyfoMTeT2O0qjfNZMENPw3z0UWhqhdM
j9ujSYukF89ElxeSqH7le4nJZ6YNti7l0cqz1tDjYj4InI2S6w+5L8H26SKP06P8FkR9H1S6foWI
fRj6ossQ/c+ekvx5Nt5YqGNdJ/gj7jsmkKMj4F8ik8qy0S96N5CKXcZEl/UQbdpm2SzZa4Z9mZwO
EMs7s5JOOGSTk5RXgzBpe5BrUihd6YzUaZe3cOXFGkx1/URijUPuM1Bx04brO7T/AMm6XNEFQpS7
UvYlsdqjd7EYubUlEXpvcW+Bbf6iLfNiin/MYeRQjqC3SuJNXwzU+/SP3JZ9jdTavwOUvYhk7cvJ
FONDsrzsHp+m6b5FeDWyLUgtyT8G+eMGn9yXp8kYzX0lfAo+dpLTaxJ2md3JruyM9HhPJ6ksYNL7
k3DLYlrcxZz4IR/8Sca/Kkyvk/ac/BGegrUWb9TD2mjG/wCY1vS+rwJa/wDL4G3hUaML/lZqbsac
5Ci/c/a2muKNOeivpHKTy4Ggty+r3NX0fqbEv2j+Vk25KjRSy9jNRzk/Sk+CEX4bwas1w9U1ks5R
O/8A90fs39n719IN8CSHM3sirGQkuLP0ElwQk+bKIU+WfddIz9hq/wB/fjpZCvciv/EYx2MZd46M
0xqIlLnpgohL5KMG58lEY0fI7MDbF0UvYoswOUuDjjpS+npUBTlJtIromUNG9iLfD6KfgyNLrGLf
kdfgcihqxdKvpk56WJDyX4K/AjkvrZQ1ZgyZfSxZOeS+j7uqV9LKsojLd5spnJyP7D/BF2SVkiLK
vwXd/Alxk58E+/NYKfJF2NWKXizSRvumnZtvCJNspPk3N2/ki0SizemcLBSbQpSk+SSvyTV4O72H
tfg0rZzaY9ZE43yb5rP2KXBO+R5wd8O5exJLGCCtCRNLhmo//s2exC0bPktK4mmWnUk7Not+lbZc
FtonoRl8l+/RC0263MuXdF+SWx4oWpfaiEbt1bN6Wx8k4QePc2ydYo3NceSoO2VN/XI31uiyWduB
at9sfBGPnljdbPI9PTfb7npzfikKThb9z0tJ5FGUr3PJ6lJp+5jtdeD1b4IQlVrLtkpUli8EoRfa
enqYXCtid6bJaOhLu90c/W8nq74L2tlp5eO0Ws5N1wiMNWST+SVSi8fynbLbH2HDUkq4Vl+pF0PS
0nXyLPbJ5Z6j1YJt8CWm1J8YPX3NshDW1FFryzUrVTdWqHudR9hx1n28G6OtFktLSlhP6kQWrPa9
1salrKmT9LWy4ukb5fy4/fpoUZ+C8Z8EUdkhKcjLR9SN1oVNEskJJ8M58HJyuCkzL/fL3OUPJc8n
I6Yv6RKzEkMV/wCTlF3YovhH1I5Q7Zzku0clM3Wh2YM1Zdo3WJWi9yHkyy0zDEmzlHK6cn1IeTwi
9y/yUmZZu3I22KXJhpH1I3qSNrZdofcN9bQk2fUilI2yZ9SHFMy8F2OmbrEmzk7WbZPJe5FRkbW8
G60OmbtwrZdlqVUbZsvcjang7ng3bkdsjduFcjEkYZsnMvcjtYlJ4L9RDjBlykW5bTDsu/IlOQ++
y92DbOdH8VWVGdjlfay5T2yGoSLvqhbp7ZFPVG48HexL1Tte4T8WJLV+41GVs3C3SqaK32Nx9yMd
aXajMpWNaMifqHc7MNkXp3SPzOS1GxrT+hlsqce4caY5J3Fs/huhqEdp9QvUdpLA1CO3BcnZJS01
O1yfwx1po3J2rtozo/8AA1GO0U9zvwRhLTTryKaVDjKCTu7NwoJJ5srbX2FrR5RxtZUsG9coUYyV
IcZOr8lvPz+C1hijvSijufRvSlTeCpTstlwlTK9V0XKV9K09Rr4Z+ZPd0vS1Nhtnq2fJ2uvkr/qG
0XJ2cmNVqJme7p2zcSnOUkWYK9aVHc7MHbKSXwd83L79O1tM7pv9SzBzP9TLvp2uSRTv9eloy30o
w2f/ANenbbMt/wChwZsqN2dx24M22fVI+pmXgxdHcdrwZwdkmjvd/v8AB2ywd3TE3+hcm+nbLJmT
Mnsds2d2SkYmzls8nbJ0Zm2d0mc0YkZk+mD+Y7mdln1M7mylyYk0jubZiR2ydlucik2Yk0VubPqZ
2l7n/kuVnYjEmvucs7rZ22fU/wDJ3M7NyMzbO78P5aZls7io2ZZ39FVpHdJvpenZmXSocl7mdzKX
Jak1+o/Ud9LhaO6VlSZ2WfU69imVHLOaQ9+V79LhKi3KzOD8s7pMqXJUOS9+DvbZSRe5xO57jJcb
XyXu3L7lPDLWD+IzOTb/ADF7q/Ud5/DtifUXyUZbSO2RUuSlg5s7kJItvJa7kZ4P4qRcZX9jY1kt
yLUnIpp1+Jzu6KpmZNHY7ZtksCcrouEnfyVIpFytHwW7/QpmEyolzTv3MMikrh5s3U8nDZujE2C3
JtG6MWPScbyZ02cYG4cjXWkj83T58jnpKja8SLlC0Ptp0OM1SMK7Klp9xvivyvIklgvU07PU0lk2
bXYnOG5D2pJ0bJRFg7oJMuC7BYwd8UzforuNleaYpTSl9yeFhGxp/AnLBlRsbh9AsYO6j1NM9PY7
sW5q/kn9LaQ4yjUfBep2pnhm6Efy78EG122ZabIz0V3cmzZnyJ6mHXsamxU0sDhNCUSD1Pc9TTVN
yITmqRt1Wk/c0/8Ap5qV81/oEhSksF0jPuS2oucciLorpwNpEbXgZFY+5aQ7/fRh7kcHCHQtSS5H
gbR/4ro5EdJeRY6W1hM4GfBhFRHIo4OKKFKawYj4NrWDgodI3zRgtI2r3E2uRkt5jk8dOMmDKKrp
wW0YVdOBUirG+SWOqX8olRRhci3K304N00UcCx2iSRwYXJldG0jdOOT2HgyuxCVHBwcGcjpbS2rf
T6TP0ixRwL28n09HjIsZ6fSW0JMdKzdWPYSrB7ix5Fg27ujnWSmcFx/AsHdgaFFcNkW14KRcURbX
J8jx3lezoTeCvBxybZOi48EmU/JcRo7EfSjviLGCOCTS5NSXix70XFeCKrkTpUPZisEpbcpHcsoU
ayTr+oy1eBrZuY5qNCdqJDHqfERR9PZfgch7pJ0uBKGng3e8WRUVyxPFEr52EkKUY2Y/ZsDi9Pb1
S9yMpI285ok1nAntWS17Fe7E6XI5VlHo12LyKVLJK4WkzZC+aol/afcuK4XgrUVSbLpDltzXI9Pa
9kfIm1yTainXuenpLI7X8oqWWdseF4K1YtbnizdXDFJf0jg4flRZGUlyajSxFj0tGL+6HvXEfIvk
7Y3tNuuv4khtrgg1/SW49kHVGm5rDyazgq2M9LSwnmybmuIUQSjzyz8tcYK1v55eTUlFd90b5q3z
ZHSifs8H51CTiuGS0oY0juuS/wBBpr5OOD01wR0z3volH3I/Y3Ihpv3F0f2GJeGf+pf77Tl4iYGK
K5bIxrNdGicvcs2sjLwYGmKuWOh7hs2JG/UdjHNo4MI4wJJV0vpkSMGMFG7oyX3NtOxz1Hh8dHBC
d9LNsbyRc2XZs04/qXN2zPRPcMdY62+b6NMWOiXRjozk4MDs46V4E+rv26YMnHT4E66Iz0wZ6YKL
LF9zPTBT6YKL6frZEchpHcS6og+jVkZMT+BijzfJQ2iC9hOvJg2v3ogy3HPuYJKDyxS1XuPbAoLK
8ifBXqKRtcM+4uLFFDXyasfke+G4kktuDT9jHuIk/Nmpp1yxS/Q1Peztk0KU7ZL7ElF+BLbaoi9m
35JV7kop8sU5CUnWKFqyX2IxlGn7kv7CVkT6Y/oPViqrrp/cX3O7+qyVcCI/KIKNCH9ic/Ni+xP7
j38LJJLgiJGmoe/T9DUn/O2QNf7nezVriiB3cGkoe5Ih9jVmudxpH7R9ypq8Wa9cUaX3Hv4s0VDh
MkaX9pqTxv3Gh9j9p/uKnV1Z+0/00Q+w93Fn7MtPiyW6q3eRR3xjcRSU1J/Bo3KmnZqP/wAj/p3o
re8bjWk4qqonpL96+mi/kn0hXNkbMGfch9h2Q9rF9hJ9GyH9xH+0f75RGOnkUnwiEhmCvbpgUJc9
H7ikzI9vTfPkwQinixGDOBC6Y6bfIhiXyfoSZLPk/QkKUuClwNIcmRTZg/UU2uj04lvk5O3KEpsX
fkwPqkP8TK6v8KGV+4iMof4bLEPq/wAF9XZtrPuKihof2J1+CMRkkhJ5P0MEX7FpVgn710gms30r
xuIChtvJfuX7MyqHp6OT8xZslXuavp6jk/6RerDbEjepUqFsluLZOXmxuJKUvY0+nHBJfI38kfua
v9xBEZON2KEfODFOTHtW1Pkj6rbzWRv5Jv8A8hSrKPSvCkJ+bEl9O4l//LNT05bZFubkvgh6m7ny
feyf36af3I/LHKKtN1glKXSOzLoTnh2JEkuaNSEo/l3aZtfsS+ZG/Syrocp9F6X1UReqqaYiUV/S
TjP6bsjF+EambuQtXSfYNyfKEryhPS+ojLX5syzav6Cak70m8EYvwa2buR6+i+01HN5aIdywrPyX
TeSEv2jmLJdyyxRjmoEt7eyTNOG5dqNXa/qkf9TpS7TU3PmJHvWIkVp8/Vg0/VfdCXJLTjLuc/Ao
R15Gj6jt0fs226sl/cLUhDss/aL+Cf2/et9IS+SrHKi2uH0dPpH7GDPJ+hh+SP2GL4Yl8D/fRft0
ZXuyCGMm356Mg/ESukU+bGkNS9+mCrwRlWSulvn2HWCEVx0yUjf46VYn46bVmzuro2fqMp8NmERl
wkyiH3P0HRKUsmDLwYR7IU27/X8KgOunPTd0kr6UVfXkq7NxyPJY8lX1yzmyzngqxyGhrd1WelnJ
Sdm6yrK3C6LJ8FizkQp3wUSW4saHT/BB2SyWi2LP8o3HkR+hIUSPgaE77WzTFJxvIlwTbK8F1kj7
jg/cc9lSJSjWPHSDaNvyaiXG4e+Nktq24It8URzaeT1ElFk4J5vk9SUL+RL54J3G0zTUeLNH9RNe
5HfLaLdHcmJqG3I435G/eRL7kpf+RCC5vg3NeSaWcUKU+2SI/l3Fq+BPZtRsUuCT930shpzfanYt
RxUkyUYPa64HrN34OU9qzZurb9iovtUsGyT7pOi5pfc9PRltfBGM3aFN7X5yOMGlJ+w9XdcmZce1
eRvFr+llpvZF8C09Vq2zfugenouo+5FN3EjP1IW/DHDTdt+xv3W35PzJxi4ryT2Si6HPf2p4iLT1
5Un5N3qxNul2xXn3I2+0U/VSkbdGVtqrPUU7b9z83US2xJ+nqb5DnJ/ZHp/tEu2XLLhq2NLGmR/o
Xgj37ZGzRluTVM3KVP3GtabU4rBqLQnclwOcnlmnPUW6C5RGrjL2s7PqSwyGlryey7ZuX+TUj+zy
dtY+5LU1Hcn+64/DZHc8D8WT9rKjLI02cmZUXvHUkz6jDvJGN8D8i3SoqErL/fW8M+sdPIm+BJyG
lLolZ9aHTszg+ofej4sy0j60cmXk+pGJJ9OUcjG2JORakJWXuHmzdeDLMM3SZ9SsrePusp+48lij
Ivej6jJUpHa7GfUfWPNlNn8RFRefwKjbJlqSO1lTZbkjamcmZj2yss2ydFqaZiRUmfWrHtZbeDLO
xm7dgSkx7ZWclSkX6g6Zzgt6mSoSs3Ji9SQ9sjdZtm6O2Q0ngW54P4lSGoSFkW+VHZIu2bdRj2yL
TwKM5cHJWnI3pi38m2EvwWJSw/crcYPzDbbOw3PJXA1H/wCzcKL08ryY5P1FGVtJH8MrTW0lui5b
j+HZ/DZGce2hKcL+T+Gh0/0Nx6exOnyVt/4N0eLtn8NP9B7YIyzGVwVs2/YtjjDuiytiGqX6G/yK
F8FlxYlzFFY+w3PlinpumsjjN4bsbE9OVMpyb/UdSpNkpOWZeTap2kq5MyLm8/gwzE+3g/MnfTsm
0VObZfudknF/BT1Z0Zt/cwdupJ/B339307N1/wDid8p/bpcUZc6M89MTaMyb6Y5M7jgwjKbM4ZRi
Lo7r/XpiEjuUq6XGDkj6WZVHbFtn0HdHb0wrMxpFGDOm+narH2HcnH93n8fwUuS5IqPJ3I8nkwv8
mDJcDJ28F1/oMNmV0qJ5MmOS8syunblFvJR5PPS1ZyzlnJ9R9T6YNy4NshexmTfSlyXmuvaXJm1X
I4PJbO0+pmWzPWo5Pqpfc5ZkvwfVL8W2GWfV/wA9bbpexzfRNMt8jsqB9Vv5ODPb9j+J/wAnJjB9
bPqbM/gwbvB3WzHaj+KWjbWRNy2HLkbaO6W0/iP/ACYtnd2n8T/k7W2Z5KjY25SGjCszJ2Y46c9K
hkTk3Z25RT60K1g4yP2KRm7G43KJtrJeoqPy4m2hOSdGLs4wUi5JnwfBnB2oUawXqRbMJlw4O+GD
MLG9OND02hb4DlpcmyWJFzjgxGimsHwU4ZN8F2mELfpjlpI2NZLcdyHUNptlHAmuCpadSN8V2nyL
A7hUkuR6SRucbQ+zbQ1+BI3OKkhx2pD05cCZTgh6kMw9hULdUvI3DD+D0q7j1HWCSaVj03wdyiyl
FClBbY2KTknZlQPU01tkOL5X4IqnQ9y59z0YfSXPH3KXpyFOCp83R+ZHtvkq7FLRWeRetGmLdOP6
lKpfY3K1p3R39vvZUHGTRpvTWXkjqTjwem2lP2NWUYcInoshHWvdKQ5pWnKjUguPBCc42rIrb7kt
CPG405yh/g9D/wDW+zNWcYK+ET0XzH/QKUkP+U1NzvODC8DckLwX0YqH2kbRIUXXyYyPH76Mfdkc
dG0hTayzI6Q4+IkcDIxXliwcF9GfBSSKtDY0kfSZj0Up8GFwhL5Fg2jwbmiuB0jalyxYTZZNMRtt
HBRVljpGIsyiT1P06fUmIrCOUMf4FJq+nBL2TIjIx92LHSQpVyZFg4Kss2pI5GyqO2OC3HB3I3S+
kSrphFMteDc1lCMZFKjuaOT3K4KvI2VFCtDZj3E6Mj4H6aODbLkTrJ3mOC11oiOK5OB48iTH5Re0
ydqE9ubLocVyW4jUlwzKNRLwb9y7eUfRuG9u37kC9t0bPScbGPCeCMFo8vki35HKvJtatF8qiPbg
UkUuS9o3WUj0jKu8l15NnPgk45wJ7TtxaF8suvJuSyiWm/pOLxZKNdvIrRqe5qyaxZ+XH+XwPtcY
ex3rP4OLowv5D0dS05PkSjl7qOM4LeYISVW0QbXkUoYZqXiUcZJzSwzCp7SenqYt4Zu/+iv2Z1Ki
Hr22b1XF0bdLT2N+w9TVnJ3k2t+Ceo4XGTszAk4R4Q4bMRE32tDlHKJ2PZzRPUk+X78mmn/SOaRD
T012J2anqLNG3SeKIJ4SZFvNEYaUu+/8HpyeWqs3y5Zp6bxKqEveQ9aK/LuzUUiairFJ0bV/Uasp
K0pW0R046e2SIanvZNvjczSS8uz187bscZf1I/aXHi/38F8i+w0afs2IuiVEGWNEGUYJI3RZBsk/
30PZCr2GOPkivJY4ser4kWNEH7GPbpP3vpLo9OKs9TU+oZvZwjgyu1CpdL6bvH4dxzx0lOJtPW1J
On4KKjkWpqWijdyfT/wcHajYj1NR89GlkU5dqGh9VH3IRGSTN3uX8DiRneF0aIwIIsrpYzao3bFO
ZyXz1rb+oqVFdM/g7TJa5KeInycjV9vgUtuRjbESRngSLQ4oUng+pSOBfYkdxOhrqvsX7iv2E6JG
SWBIp+COCVH3NT7El4Y38GoJRk4ik1uQ8eCHsIuqHR+griRo1P7iSJIj9hIivIvuT/tN3yL+0/Un
9+n6GmiKRp/cn9i35ZL+w3SVi2k/sTZlpOitynfsS1Yqn+CO6VTP/QkovKIPVlWcDUXZJt5uqMy7
bNPY/J3OlkbjxYtz7j42ktODyLzY/WdEPSdo/TBGUl+jH/LghGXdC8xE1g9KP0eT81tahJ0uLElR
t8G9fVZu1c+44aSysZNPPgZNSVtI1vuYVpCbol+z6L/ML5n5PU1Fk5S+w5z1Ny8EVNborwQhDR+o
1JVRqy81ZpaUcbiL+T9p+48/yml/azUT43M0po/6b0Us1Y3xcvBrQXh/v4P5IV/QfcrnIrMMbIjY
6Ie5b4E7J9NP7fv18si/gYp+xuGMWn5XRoSf8zF9hkpfPSa9ikOclnp2vBH7Doy8GRZ6Loo/g/QZ
M/QY5SzRgqz1J56bYW2RvpVjHJrjo0mJFV4KsfVS9iIyRXsL7EkRh7jJCfNEGMaXCFI2mDfLo46f
+RbuTtKzKPshNqj6jkRaEnz+BFGENLkbFLbwRhKPx0y6Et58DZBjXwNcqxeCtxZRL2FGRMfX7IiK
/Yo1BWTEyTZAlRHHBNPkUumpguOBJcI36vNEC4+Bxl9N9HX9JpxV1Zpt80T/ALiUoq/sNzF9iNG5
raL7k/7SENrq+RX/AEiz5Jyirs7hvwQcOaFLUw2zSV+TU96Eq7F5Jf2HpwhujzZtenRNpW6RqX9y
tO/o8EfUTX3F70x/fraJ/wD8sd8EEvfpOl56afsUvYaaqmWh/wBhq2q3cMW7naLZyQU1RpxFKC7k
SWpH8u8Gnq7alyRiOcI2vA3OLjKilqNEfzW0hXyT38N4JRjzRNzXLI3/AEkYJ8sX7RD6WTjN7X8k
9X3WDb+zrlUxPXV+4rXLH6OX4JT1EnFj1NlbY2zsX6EdSUeCUZOsmrP/AMT9nnFdq5NOHkm5f/rH
gerXKohHyoMnq6n0O3ZoV5THrtfl7twov+o15Lhv9+it3gbSGn4ZH7GyxldMiyTrkjZI+zIx9h/v
tOvDF9ulCiMkerxfRsh8EV8dJRfv01JXyV0rx0USjix1gUN+BWxOyhS6VZfT015JP36MlfuMiv8A
yEUfIkcl30/UdDMlj/Al7kV5GSN8vJyNil0ZsIIYxI3FdK6UZPkbQo+o6I3JseTksaPq6YKbMDtZ
ODPAn6eRr4Gk8icptlH6ij0s5u11lC6MjXA6fVMtMsqzbfcZGrJRvkXktYIV7lpm/wAjV3g3uO4q
qJXEe159ivTX+CSqsEVuK5Rv21k58nbnApbFgSumem3zIU6uLHT8G8jm8G76WKMM0za/qeKLlE2w
dkYakqIykrTySjHHwOfh4ou7o3fQ0La+HgjFvvk+C5JFab+C3k374+7JRVZNRWrWCKco8e5u3IUI
eMfg3PUjF85Gt8PprkaUlJr2IucqNvqxf2JS3KViT+myEvWj9mV60cIlKIvU1Nshx9VcFwe6uGVJ
44M/tETs1UQ3Pakypa6ouOsiXpzjPBs1p7Ui/WTZJaU7Y5sj67ad5ZtjO0actF8SyVrzqRcHk9PS
n2szK0Lue6jZpP8AL8jWp7Ui2jtwQa4UuSqv9T6cmrp6d90aEtXSVV9Q9scj2OtNjzaZWy3R3Q7K
wjS1dPTS2Za9xQnobZeSvSsnHT0tl/zChrw3xUaR/BJQ0Y7Gxt5f735644Ns5Ep3SYkpEp3yL4My
oyx9x9WCSi7NrdDpmcFQf7/cVKeR7WJ/NlORW47RJvg+odMszIxI3LgW5mJFpnJe45OcHdM7WUjc
U2jDKbPqHtlk3Xg7pD2s3Wd0j6sjrkdYsq7ZuEpSOTkVHfND7ik8FFbizeU5mH+CL9hbmfUSrgSe
CvUO1jYk5nbKxTFbofeboe4t/BdnazvkZ1Ct2TdBlakh1JjUXYmZlk+o+rBbbGoTN1lajOxm98CT
Z8lQeStR4Pk7Hks7uDydotxSNyZUztVM2vk3xdCU8s7LQ2/wJ+x9OTk3ReRJq6wXwizbJbjbHBfk
Xlew0ofqdzs7I2Z09v2Ko3x5uzKspqhS3ZQo+x7EnJ8jUJYMf/Rll3kUU8I/Meej9KWGbZ8FsUof
UuCnJ0XJmOTbvdcHe+l6c2kfmN0XZcG7M3+p3GMnZuXwjulJI+p37nbqTZ3TlXyO+fwYbT+DEp0V
qN7un5bkz8xv9enY3+h3KddKR/NRUrX36dlnfaR7lRyZjS6UjEGd2H0uMbO+DXz07VbMw7elG5ae
DK2/fpcI2d8a6dsS9nSo8l00bZ8iNyWDMaXRbDjBRiLo4s7o4/0NJF0bPJdHprkvpl2cdMjWcGUN
LJx+/oTfBz03Lgt5XRRS6PBQm+lHt89Ul0p8G1FvHXcyzJSPfpSRuPfpeV0+Dh7ejwKKyZbG0UXK
zHXc8Lptjyd/Jj8KUVZbeR0ikKTtGBovNdaR8mLL1D6jtR3GTt/EpuzFly6PbE2UXNWdqFDyxPUt
mLOxG6aPpO2JUuDMWdsTikJH05HRSyXKNjpUbmrR3af/AAdsKM8fguUT+HTLisHBmBcFRtryJzjZ
2Qo20JtWfQWlcRYwVLTHKBVC3Qse2NM2UJtWZhR2q4kW0ZiiWppxFhi36amNxW1/B6dFuJ9FMqm4
kW0U4I36R9J3QTG4qmj03Etx/wAji4JG2u0i2jMBammu3yJ0Zgn8ku09PbcS3/gcdmRqu33/AAJy
iJYZugqaNko8CtpP2Y6jbNtXF8Clq9rKpM36a7S9SODbcWb9OPcinHHkW50/ZjqNs9NJtNieqtvy
Uu89TTWG8inqRwbfPyb9OPBmOPYqSp+bHsjl+UPS8WXqRocYLdXJ6mlDnwR1NWFihWeD1NNVt9ju
jwz8xUztim5cHpJVFMUtWFklBLB+WvqFOcbQtJRW9ktfTjXsOU1x4NupFL5KhBd2bPTa7LwQ3wiz
V2JSSVCf06XLbITT08x5P+nhBOXuxOkpSfJqw/pl/oFNo9sD8kaRvawccDa649zgljyPBJP3O1WN
of72OrJdpFGCiqNr5MI3NZMjaQ5NYF7GBKhJIryYLrJkwjfNZ6YOMI20UcF1kyNqJvaM9OMCVFHB
SRRwbqyZ6XRVYKG6NzXaJUNUXtz7mTtX4VNnch0PHAnQxR+TjoxOjIiyiyhLpSXTwYQpTQsY6cGR
texbj0wXR3dLRzRtrJZZ9NmENUb2u04JUW1bFjkcfkX2K2WbttEvfqlRurg2UcHFCiNob2nBhCx5
N1Dh5OMCtEdOvqG/BJ7fJhH6ELQnwbX7nBdeD0/An7l15HGPgchY8CaWaEpLyccjdZRLTf0i+wnX
IoQ9xyrnBJ0diztILUXcQtcscqyiUGrj4LrhESPoy7LyR9VW7ySklwdmHRH1FkvzV9YR8EXXKNOG
n9HkW5ZJtIktLEhLV5SIYsTSyScpboyl/gbawN1jaKMHUV4O/knS8jWkKOr7EMeTt8Dc5Ykzc14H
L/xO19sTuNWlVDhpOrdEYarvBprauRrTw6wb9STe5luPgUl7G/f2xdlyy/c1lXBGGnJpNi09R7qj
5NNVyya0u1+C5yve8knXg0pJZcR6rm9sHgi2ryftLrgjGN7fZEoSztgaKryamnpvY7u0RU23vlmz
9pkucCjvcoLHItZqsUad+LNWa4cv9BpP3Q6NyIouiVE/uWS9hN+5TMDG14ZFy5sY/wB7p9JX79a8
C6J/PV9ODA0LpF/PWQuskLovl9XQr6YGIwIz1z7dMD+5lHHS+lH0jx1SElwWh2buW2Ifsbn4P0MC
i2R9i0OL/wAHyWMrT5FLUzI56ex4FjHSkWZOPw2i3J7ejVna+0V8jycnBx04wYJiQpDfmxfbrL8H
3Qn7i+3RsRPpIiMXyMX2N3syBqfcpkiL6LpL7CfyR/tH9ydjof2IG1eCH3J/YT8s/wDUj9yd8IVc
WahFP2FXg0iR8s1Psd3AlLUqfsdhqkVLg7PB/wD4+sSP9rJtrgUvBqC3HaaYiKgqEP8AtJ3yX4NU
ip+WXE0/ubiChQvsfoa0X9V9Nc01OuTdHijS+45PhI0tjT4uj9CH2NeF96Yj9pNOM/JKa9jR+45P
2NHZngkaP9pr6X8240z9r+5DTng1p+HE0PuT1XxdGhKHCZ+0L5E9F15Nmp/TZpWvc1kuNz/evrpM
mUJ+5RIkvnpJDi+bGzkZJGSQ/wB7D7jY/v8AiivkX26PrZMXSH36yoQ+mpYukfv1Yur+/Vda6uuu
WXfR9MrwP8CGMp+OjQl7j+wz9SF8jMloUa6XRkqCwZMDik2vdi3mZ0xNO+tVdmemOlF0OMVk3TeB
YyV5LvajtYoenJv3E58mR7TJMVe5/wCpx5F70VE7vYlX4K80R+BX7GCVeTJqCaJN4IEvcT9hiXwb
VlNkLJ58lwyPcIxybn7lX5Gv/Eglxdkb/pP1Jy0s2OyX2IbeUbp4bZBX5NSPwR9kV/4kRvT/AJmK
zVYtnO0vV+o0lfklHyOTfb4JRvwQ+TTnDwyG/mzVdn5X1UP1MOhRvOzqpPCIK/5COpBvbeUQUnRq
vcuS9N0x+o80aUd6sUI5Y3O9tkouXBSd3EWrHjyhKTo1HGebobi6+w3qPKRCN/J6fKZn6bGnLK8G
1O1tHr3h+BRlLajVcZZbpCmnta8j3exCN8eTbzuH5ybXbl7EYJ/yj1/fIoTdGs+HJ0i/byNy/pNJ
fyp/UVypGHaQ9P6p34FCL+mFD1vMiMJOvg1IYjLUlgeu+USbr6SL21pwI7mnGWTFJRNTQlKvchtq
XbZLWp08GnuklUZGrJcOX7rH4tPTf8pjyKL/AJhfAtK+Rkvno8ZJIZqqzklH55KGrG/3sdNvBdmM
GTk3WclWXz02t9eejl5Zycm7pVnJXBycloyzkvpts910qznpyVZuHk5L6VfV5MPlkVd9GhdGPoiM
RjN75YiQpv8Al6PBRFewxMRuooycHBXT6UXYlwRH0uihZ567b6XQn04Hg/8A2C/LS+aL4Kvq/Jui
rsqqHhFWPFmSWeTHSLOcls2p5NknkTZJXQ74bNyyj2ItPgWcschqLNuo6lRbHFPgcZcNinyh06Ny
8Ec5rJu4ZWmzbN9zwW6ZUJGyb7bsjJ5TyNQdYN92WnVLg3WrFtfDIwnKpN8sc24s2wlzgUNSVxFL
fF4slGHI5bvq5LckvFM5T+xu3cPBHT1JU+WxvfF4LhhEYTmouMTc9aJSmpUzfGX5d5N8tVKV8HZL
cx3dfgqcsMuOqPT05eeRSvzYnq6m2Vm3Tnu+T1XLJs/aJ0ksEtk7wSbkJSl2CcW0OEZdopJ8Oxeq
+7yNaUxycnk2a9uNUhrRTuhyk+SsuPkx9X3NsZ9limpCWou7y/c26MqG7K1Y740NacXBtEtSbtsV
ZR9Kj8Dlu7fYU48o2T0+7+o2Qb0/lHJUo74/JKMI+nao3SdyO3Kuz+HQ5ybo3x5I6UtO2iMV2pf8
nyNV6ka4ZOFenuVYN3LJRxJPg+hIqTx8f6G4umKMrf2FOqo25PV4ZWWzKPpf+DCsbyjyOvPRsrJf
75O+BbmUWZ4Kz0tGWzFl+RWdqY2fBt29OaO6x1gUvJljoszIrN9MMplLguypMpJl2ZZjk5wfBTsp
F2Z3MxZdncztZyWZKL5R3HbaOeqO4wixXwjh9NxTRSVG4SfJVf8ABuRnJmNMqPJk+ncfQblhFOLb
PorpZUosrK+5fg+h2YhRYk+4ra4jmKO0+j/gqqKpn8Ir0mLV/wCCvTK2NfYUuGVt3G5Jm1xo7O4z
pNH0ZNy/wZ0rK20W/wAFw5K2NL5HZ28lbW6L1LT6VpZPzLRnk/Lz8FOLozydrMJs/NxIxyVDc0fm
3+vT8i6ZU02d/Pydl7jmVfYueOnbuaPzL6flSH6ltGS4XZlSSO7kxyXFuj8y+n5cpfofmXt6dt/o
fTLb9+mDct1fc/McsmC4xs7kypY/D2nfDHv0qN2fTaKfJRaK1FTMFwR3Rx8lIyrPpsceGi1k4Kmq
/DRvrA4eUXRfgqaKSL5/Q2TVM7Uf/wBi1kaS80fUzkbn4NqW4tKvguUO2+iSN+ft+CkrOGjh/wCD
vg690V/oElkU9oo+5uayRhXJbRVdMI2nA41wWbDC/wBB8HBwbVk7lkdI2ilJYMdE19PW5LpwNyiV
RhD/AAUhSkjguSwcFxRtSyLerMRHgrwXWShTmcGEUkZML9yryYiPrg3zWPY+geBYMxyNxjQoJcmV
bMRKSN01+h2xODuVI+hGEbRXFWOo0baLmrZiJhG6SPoMKhSaP4Q6gVETkrZ9IlQt0UzEC0qO6KP4
eC/TSK4LkfSNxEmfQJJUjiyvTQ+yulOCPooxx1pCckfQhyihbo0fSNxjkpoWCtuRJLFibicDlFCb
TPpwjdFZK24Fg+nJtksC2lNJjajTLmVQ5QWTuQqQ6WTZRxTGnE7V2EXNFco36aoTaEsMfbTXsbK4
LeGNVZ28NkZaiork9TTVe4pSj2lR/wADajlcFa0eGfVX3MPcj1K2+fwJVaLfbIcUlKz048SYpakf
A4xVnqxVMU5R5yUSnFZQ4viLE5RJRrDHujujZ+Z2+BuGURe39Bdu3BWkhzrjg7Y2z+Gd0aFtVicl
/klUcJGq/wDyN04UkuReknn3G4LPgjOSv7i0FFWepFd7fJ3OEnHFHpbFL3ok9v8AKR0+3LvI5bIz
+xFw0kk/g1qSSsU5PN0Nutq8kFuWVZracVhSGpaXZVJk/f0hpK3Z9J9Bq+rzAcorEY2T03p7Irhi
b8QciX3/ANBHUaEaeFRgU64MonH2FS8GSVdJYOPA37lKPCNyQ1++hL3HaGSb8HA7NP2sRRKiDrlG
RHB6fSikr6YMma/Qqjfqf4MI46LHTdWemB/JGKq+i6KPTdXR0jauTPXPTgpEdxdEqXXOdosCicGI
lPo3tyZ6XtODacHBtLSPpMl0XtOCqODg2F0cFbTKLSMo4LaPczCi0ZeRRSstrwJLyyxxo9zdWLMo
vwhbXYuzAm0NpHajvWaJmeiLo2F1ycG1cDdEu0qPNC3EcF+w9OS6XXgUFwXXJKVeSoDb9j1JrjkX
oywL1ZJqyqy2SxlI2/yideLN1YsqGMjbXOCTrgW1U6FGaI2vqZJ1wShXZ7l1whY5IqHFlyWWybrg
cYYwL1PCNPHLs7VlMmnmMmSbR+hFR4XgW7lmovkahJx+w03u7fJKP/j+BeMk65J+q+3iJpzrCNIc
4yqN5Q0spi/tN8HTo9KV+ob3y2TRLT1JXF8G67yLxTsaPy5OMk+UU3aISbp+bF+y6Xd7sUpvb+g4
epFv2OxK35E5cigl8Gp9ialjLNlckL5QtMx/ST15N8i/tNdQk45oWtrrd8ku6scHrxlSXFCg22Qk
1hMf7PF3OUv8ELJL3Zqfs8Zb7W09aaFGqmTf/gb2tzlkjekJRhV+5KUF9ckOPCcaHJbbYlTzpjf+
gX9xIb8kIsWCVGoKx0TXyKzAmNmrkf2JfvYRfuQSHXS+b6MUn46OjbIivA6NhkvyMUY3ybpcnJv6
cotcC6WZ/AxDFpjLMvAn+DgbrpV5O1EdxwOkb2si6PrqC+3RDI/fqxdWR6L8TH9xdF0ZfV9HRuke
w4pjXlilLuZKNi6Skh3lWJtFRJm1iyY6c10nXVfc/Qj8i+3RiJiskQ6R+Rn6F+bIfYn9yR8k18Hf
KmiPpys/Ul/aR+WL+0X3NS/AiZAkkaX3NQj8j+xEm37kfuapGyVGkMUfJI/9STfuJk5eLJPUiXDC
oleXVi67Wldk5eCcPEWRW3cn7kGLTS5LXJ/6klV9pv8AcUXXJKXuU/p3UJrBsjG+6hyeBRh/UXPt
ayS0tF3flEnqXufuSa/pNeUJvcmKOou1eS5T7hbJbmScuKJbVhMctJ5og9bLbN5u9oktLzZFe6NX
WkuZcFPsfwb6b01wJVkcmrpWKEcakuKHqSfcyFu90jWlpy2Sj5P2Zzy3yXWbNeLeEzU/sNP+0Xra
e68IvS0f8HdDa7NZw7Wo4NX1dRzo7lxpD/0Dj7SGUeo+TbfSaEONE/kx7EtO+BP4GarflH6Ev3t+
xCbGNtk146M04ry+jLIMZnnpFeOm6ujxgpjJOJczukhSjwxdFXuZ6NCsYn0ZaIxrBno6Fu6Mko2K
Mvwquj6zvyL7dEMXXAr6OjIjH4MGejrosmOrOwW/mumDJRdGyKHOV2UzcNRIUZJ0fJUetwbsjulc
CN8mB+kLf7EuqRt+BPwc+BZO0p8mpnyWibniyGRo3vhHJ+gq4sj9h58ktg9+GSjydnYL1HeRX7k1
8EWvpQrf8pHPkk9PyypGpkjXhG+ZpR3eSa5s3/yklfghTvAnF4vgjbyma3cuR7fYe/2NOO5Gz3ZL
WbtNk1Z2u+0WpH/AoydUakr/AJiW1krfg1I3mvwRfGSaNW8qT5I2af2I6i8MSL+CSXO02PwQ+5JG
XalKyOfIp7niRK+mzTlWPB3Scm35FqdqHFexqamVuY9zXbkns+kUqJL4HFvkpJ8EF7CSdlJ84oep
HtbyaWgmpN4VG6uRSk5bL4J7l4o0Y6Wck37RNKuSMF9UsI07jVM1NL35Em6WmyCi7bZLX/rZrRjn
FEtGXMEaba4yLt4Iaek++U8k4rug8EnHNjjL6vTpL/Q7Hw2bm+SH9O4wyKvDdHN4N3uUXQ301L4F
npcRqxv97GPuR010Zfl9LN0v5ejIx8EYrwM3CN/4MIro8IYovyRiizkT6VYuiihSq2UWZLUelX1y
+jwbivwWUPqmJN+DA8lWWclWLI+nPTDyJSZZyUy0ciSeBZ6UpFNlnJz0eTkWRuzbZVn3G7G/Bzx0
+TJJj/pYtuSryZOykWVZW6+jQ0uqaFGb7hyGosUdQ3WhqLOcMUrMMUovhiTl9xvcios9PV/Qb3Jk
oweTudxsT3pMpUSlqZRF+rHg3R1E2OKfAoa0uXyOS1EbYSwd0u0jL1FdWxqDPU3c8nfOpcFQmmbl
Lgjp68vmzt1FkqLwVJ4eBbdTwShpywb0/Ni9WdTbK0pJkp7u7wRh+0P6US2ang+rBUncWXCTv5Jb
JYIx1W3G8n/9WS9N069xtu1+Dbqafd4aKLXvYnOG5CqNUflqjfSk/ZiXo7aVYJRUe9jkbdTST/8A
Irbg3f4I43RXgzpZGlHbY9RqzMb/AEO2G02rFG2a3Ufw6/QSXYZK5R9OD1k8iWz4ODc3+hFwfBt8
i1JZkjZuwcjqR6833E4QliS8nqavImvBtU7j8nJKb5ZGenP6fBTkOMdSk8ktXf3yF3/8iuX/ACPU
8t2bdOeDOp/yJ6sr28fvff8ACoq5Itql8lIuf1I27WZRmDK2nBVDmvqYotfqb/5jbTMv98n0+mkZ
6VyZjgtFIyqRuMZPoLZ/UZgz+k4s+mjhl3+nSjksSSsqulNM+l/cuzBW3BfkwrODKPc+hlUyylk+
mi91HFn8M8o9zETuVHbyfScHd+DtK9Nju0WsFKJ3LaWYVo+llyEoFemzuO0pQO5UWYjbO9V07MlO
PaWy4PJTjg7sHaytmDJkrTK1FRfkpZRjTNsngb/mKUcHeXB0xKKbXufmcewzbC6N20qR+XZ9LaH6
mC9Pkwx7md/P4PynTPdH5nJjk7Hg/OMH5Vn5t10/Kwzubo7jt5PqckfmpmDsnJHe3LpenOjunaMn
Zyc2vuZwI7eD8wwdg5SyU+Sol2VJUzBaZ3rpcMDlLuXTtRdmyXJgvwd/HSky4/4Ns1T/AAbaZaZU
1XS+C0m108xNy/8AoaKpmLNs0UlZfH3G2sdOKN0Smq+5W1l2z09VZFtW4txN3MRbfJe1jmvA7wz6
O33LirZs1ELarFJwaL24NqG3EnqR8eDb5PotGO1j058lQVik4OzKe1mBPZglqfyoSgrs3bC6FccP
/Q0jfJH6itH0iclyVRwcCVH05Iw2l1kjp+5ayN1+/wCMI4G9otNckXJZMRKN00YiMT/lODCFcTg+
nA3JYMxMR/Cl5N0lkwjdJH0GIm1IW5ZMRFEWFZiJwZWT6S1E4FOaPpGbS9o3RSViwcUb5r9D6UfS
PHWlyKWojgdIuS7ClHA3RSXaLtyfSYRclk4G4ouSODgyu0SSHgSSFaOC4xN0lZwOkLcsCVDwJJCx
k4MItrJwOkXJGIjwNNdou0faJJYbFg4wXBCclkpLBe3J3xFXA8DaXVUKTicDaWTuj5KofaU1hC8M
4sVLAm0cG+KFKUTwSqJTWELhFUbawzuVGKkboKhSnHBSav2Liqkd0bEm0iS2/qbax7HdSO2pJicV
huhSnHHuVCSlRaj8m5xFFYkS2xGnbpn5i2yRhKRHauWKWpHDH6eTdFUzfKO5L3NixL+kfbZ6H+CM
tSF4GoDnFKMkusYoWrJWvZnpQilI3bcvNlS5vyRhKMY+CW1Jqhquw/MiuOT8us4E4YzkU5JOvcek
q3I3JZ5LmqZHTko+xKkmh87TvUaWTsSSkRcV5I6j/wANEtFVcTfGOXmy2qZDRdXLBJ0mqGtuFwdz
qKMVUxT29rdUKdVglpR/lFKMe7kU6/UhoN9zdEprOCSlG/JzRHjv5QtTaqb4N/0e5qw/pWH7mnKK
2+WyOpt+xD9ki7bdP4Jzq/CNTScopRfDZ2pKRqfMhOUcuXJqz/Z/rXCG9d3bNeTisQ/0O726UuEy
/gXbgo9NCZlG04FJLpvRGHlDY/3ybXz0o4sTGmQUfMhUvBkdEcdFEwJJdagtwr5KSM9MCnNZOCkj
BgyX1sryXNUusY6cbyS3EYr3EZGLUYlRIryZ9hir2ODuJdc+Cyjg4K6cdKZx029ODacHHW66OJwc
G3wXRdGOnBgqRwXRtLos2os4KRUjgwsm2RdF0JeLN1ZNtW2XGVHe7JYMdKH9jayxNFLizc+SToSj
g7vBEdIcHwx4MLwQrgjayXXkqPgbkjPsLaKM80xP3ZKvCPhix/KKSO1/TI7+Wyb9hKPlC35o08E9
vgk28NkrWTHsKSeEQ3Go68myA1L2IYOzkVvDfA38j2qu03rFYFuy9pp1G0aaN0ZUryvclfD65Xk1
K/pRPVbfODPsN/JtX0pkovJwKK9iCkQx5JUamt/Uz7RGLykOI2KK/mRBVRp+99Ja3NvAvt03umok
kT+wokIRNN/KGjf7kfsf5J6jrA6NX4RCEsZFpx8RNP8AuHB8EJxzu8i/tNP7GrrOt0T9TXcXVM0X
qT3Wal+5p7VcNw/+olsz5P8A9Gkmr8GvGMcbcv8A0Or0kenfkQ6FI+3RrwJ9H0fs0foP96kJR+kY
6Yv6n0dCciP2HRTeLFXBghGPNivrS4EMcvHSUeJCeDBX4n13SRjBViS5Yptdw8i+OjGuUhY6MhXu
K/KGK+iGPpIiOhDF1Yuti6R/BXW/wUP8K/Aunz+4XRP5P0EvkjckmdmSd9UfoQP0ESIEumoR6Lo/
sRfncR/t6Svp+hEmiH3J/Y069z9CJqtkDVNOyZpkiKRMX2JLzfBA1Pubn7EmQEzt4WB/cf8AaLT/
AJmxf2sht4ISFD3f4M+5qf2npfzLkz/SfqO/OBtkiL+BYwaefJKvYeio7drP0KNjj9WLHJkyM6ui
M/5TT+5Jo9LY47WK/Yx8np1iY2/JqfY056cd3chakotYNNf+RJwyxacobWhe9EfsS01C1PyWzW+U
aM9JblYpzXKNL+41PS+tEI60Nuw/Q0l7xNbSp+nKXIvuftDjlNmhfJOv6jR/vNbbzYr8yP2v7f6H
Ut0KvYnJ5R6j+5tMEZeDBtFKuekdO8FdFqNc9H++djGL2KGaW1/zEP7R9I3yMjZghXuZN1GDyhxf
STRe44bN1Nffr2memDJXTah7uSKfgRtIU82Q/tGarfuYENka/qI/bokYYtw+rsiOQkNCfSjBnrbE
cl+OnJgyVZg7jk5N3R5MGSrMGemGbjkavnpkqzBk5MM3HJh9Nt1gurE4y2lXdE6H1pZwbjD8Cp2Y
9zayaUjB3EbkfDPVs5MSvBF+wk3VIpSvIxxkNblwJG7wQW6qkSp8nqWVfgjUrOfJtbyjVW7JXsi3
5RprcYfJLVsknI7XxEUvIk39JNJ8yHu8kl7ozIhG78j1F/VZ6e6nfBLbLxR6j5RTfEWhatdppm9c
p/gTa8j2PEnVHrPEjbz28IhHdtZepxzZJKSdEr+l4Qv5lRcWacVVKWWUpXu8D1vpkOEHcmsURjJ7
WjdqRvyOKmnXgnKSpS4M90R124IV9EWRj/V4HqfSPS05brFpTdNIU9WF+RrSdy8RHLVdeo+Dc1cR
tPaRlfZF3SFFu2/BKdV5J6ehLHuLR1H9KwLUlFe5LS0W914RN603JzYp1vXGRtPa+MC/aHLti8RI
xnJOTy0yU1SpXglDR1Hs9xaOrLEVSFPdH3Hofs7d34Jz19VQnOXDI7dWFL5KetBrzk0tGLWxd2BP
U1o7J+D8rVj25o1f2XTe6Uuf3Xt+F9NyZ3MdURWODsfBHc/ButWVaGxFEJ3gqyOcWJR5KTL/AHyj
a+4xsUniTORly8CW5YGJeLFFMw0ep7CTYmjkWT3OUcnJyh8MX9IlZyZZdnJhi3M5RV9LsfcKV4Oe
m5n6D7h+zZhnOTkx05Ks5ORqy+m5FSZd4HUjueC7PqLvAlZd0dshJs3WVFlSZycl3guxuxNPFiTZ
usag8lTeTcVFlSeDkdPIpbsCt5G7O1m2bybrX+RxiyMZysvcios3OXaxNyQ6lk3KZWo8mJIqMqNs
2Xu/5JKLwbdX/J9aHU0NXjraZGOrIbjJMajIqUriXvSY1Fm+xb5JMqErLTFHWkYmv0PqwbZvtG4y
Q4xlg3JkdzqXllacz1LyfmvJWnIu8EVrO4eR7ZV+pWRvcxf1V7jUHhkZ7uBLW+q+TbpS/wCRybI+
p3RSqjs7Wc4Fl7fJjt+xLa8MUlLKIwnG5LyNadxLcipx3KqR2ujc3Ys2rujbspmXgTS3L2ZVOP2O
Kr8MZQzXhlVX2NzlZcXTNko3ih5E/JtTuJtyi3yKWlOq8FOVIuUrZcXRtu1VFz46bYSbibZyW0Ze
nqbSt6HKXJcZOLNvq2jdrPc+n5epI/M1G/jpenNop67fwW+TDa+xS1mkbpz3PpUNeSK1Jt/fpenq
Si0d+q/06XF0fxZG6Tt+7LTcfsfxpGdWX+S3JyfuVDUlXtZmepku/wBX+6vo/wAX5R+ZZUODvkVB
4LcrMXR9T/wZO6R8nNHOTtl2nf8Av1seD4MsqLyc4O5mHRh4O7p2Hc3R3HYZ4KZ2nwexbkVE5O4+
TtwvkqUumDMjuydnBl49j2Ki+mWYyzDwd7vp2t0dxnkqEmZdI5wJRPqpex3PB9QtrdHezP4O10fV
cS5yvp+XPBcnfStNnc2zJ2cnLQ91tnYYnSO6VlIuMqO+doyYlR/EwZMOioajPzG2YMTr9TunuMl6
ctp3alo+TGCvUdHdk9jGrJIuUr6dk3H7GZ7vuZO10y/U3fcyezP4jr7nNmDGo9pb1G/1M/gxgxNn
eVEvcNvK6c0Wm2U+T2LUhqRRdsprBR5L5RkzZayU1RhY9yx7lgwi+BvwUcNFq5G18nDotXFlTKSN
1Oy/CElkuUXkbj/g2JZR3pmFk/8AESWS5J2UxbY7rMxZcY5NslX4Kii5adG+N/Y2+S3p2vce3tZt
ngxDcj6KkZXYzbHLL1NPJvghN6do/hscoqmh6e22nVC3abs/h0VXZ+DAu09TbsxycWhPbk+lWzZt
tfBckjhWek8pvtYm6kjKiiWpp1ge5IT7TbFJzNvCHFtRS/qP5OMi/Z4LL9hObXHk5gx6mkld0h7p
RlWP1NXWW3tXgsjLhFynEpZkyTX0Ln9++iSN00OlwRsbiiMpIzwcFULA+0X3PpIquWYyYQ1+9SWT
dJclUOkXJFUNpCjWBGEbUuS5LPRtRFKeOjpHGBYODbR3c9MI3yj0ui3HAkhm2hYz0wi5q/ucGEbp
LBSWDgS248kVRwccnGTgdI3Sj0dIyu1CSicHH4M5SFUaHgUF5F2nBwJtWcDwbmj6SqPpKPczGzCL
UR4O2DZ9NIyjCwRwcHB7DoWBLacCfsfSUXRwjJfwUkK0Y/wPAoiJHbE+g7oibWDLRccjdcddtWXR
Vqz6S2ingeLR8HeqOzInXkuSGoZHihScTb5H24H24sUZ4HtyjjB3rB+Xmy68m5rgcFyfTyK0KE+e
CTStD7cH5iPylyRlGNWxSkkSjBdywfTwb5LgWlSTH23uH20kzbOKG4LFG99l5ZFOMZfIkoJJsfux
74/zC01FUiMf5d2TT1I6sXfg9NaalK+UPUkqRqbPf8ELXInXGDUkqdDpdvJj+mx6eN98Gmo+ZCml
VGyeB4VuNohuQvZ4P6i4kdGCvT8l6i5K1O2T+lxNv7G90Td+0ew46a7zd/8AsP5hblaIyccCSj3e
5IvarRX7M5LPg3a+XRDGbN9VXNGotSLSf0nrbE6yjbDT2Sqv1PUc2oWd/JqySRpx/Z3OMb/lPzea
8mjGCp2Qkk4+9G2bt/J9kJxWdhq+o5enZHf7E849Qnpf1cl8xP2dfFjX7O3GV+DS9aTlnyay87v9
Cov2FWMEoLB6b/lOOkIry+lkIdEyR8pi0ZPyPH75RYvsR066cdLZdGEM46KAr6cY6N0Y6XRgcWLB
hFdL63XSmcdFD8GS6MGTgwbWLHXPTBTHj8Db/mN3wUyMvHRpiS9yK6NeTPuWin1djYq7UZKODhFU
dq/G9p3G49OCYpNsdmMikm1Gx7nmhL5OBm2PJuaz7lDj7ixk8FtWbUeRr4JdcryY9hLwxWvBhGOE
zu8knRUR7skcHabZe5wS2qsEH4Ip+xxke3wXLJLBFI2y8ELXk1NuDc3hjtXgjSFTxFkbJus2bYus
EreUjTwOh2+WPBj2PUbwQXwS97HCxktuMeCO5zf3ZuqpRJaUHYtK7TZCb5KXmQowbj9jfqd33Jxi
9rG379Uvc05eCXwShpy7W8xPVcot8tWV7xJ7GlNeUQ3tc+Tb8+Dc2j05z7bqyNNPGKJbvBs0u5Xw
K+2kb5asd68H5eaNrzfApzVGP6awerqPdbqN+Dfsi65wba9LNCUpxn9hUvBueIkojg+Pc/8A0meT
8n6aI7+LM8GkoLyanuRx23/kUv4bXuPQ0JVX86Hp68qvyXPU3M/J4NNtbqZu+kc34PyZJJLNieus
bSenov8AMI+kVLnebht57RRUljhF/tcSEv2dUmSnv/LU+P8AQr7FDO39TPsYIX/Ufp00peCymyTG
aJIv9/p9WL7dGSfz1Qui+/WQushdI/fqxdZ/cXRC/C/wSI9ILrIQx9c8o/QZtfv0kK3yR6MsaIr5
6LcOjKtHFDplz5Ny5Ns49vubjHR9Kkdpn8G5ofgqGUKNCdDjZukYJG5830ojfuRo+rBV2WdyN0fJ
Kx9P1P0IDESXlkCR+hMXRdH9iEfNkH/49JsRIi/BJ+DT+5M017D+xEkvLeCBqCfwajNMf3El4GP7
EYebIP8A8SX3G/0G2el4ZbS4HpaP2HORDDNMhX9RGUkU/ai0+35Knj8GnfA6xyTlL3HXkb8+mTUn
g069zPuV/wCfTT+x2YdMTkQr2IJSlRGx6klaQ9uWuEb23FexBT/qJV8m3ZP/AAb1MUN11jIvV4bJ
OBJs063Pu8Dv2NL7jjpfUQWvzFj0rFKknVj/AGXRjL039TPUX/0PTrKIQcJVY7xgjXg06zkkTb9i
S/8A4ZrOUKViv+gv/wAyO1X3GpZ/6kNkd1OzQTW0l77v9DCT89HI3tcnsN8kGvfpSIPzYyFPljv2
GR1fYa/fKT4E0zf7FFX156MuzB6jOTk+OlWYKOejl0qzcUbbMFHJgbOTDN5RV9asx+BzFkqxS6fV
1Y+tvB+nRPwhkhVzZp/bo0RH9iH36J2c9bfSjcx0bFIj6jyPJyX0yzBYo2WU7ouivk+Ris/QmU+b
6UIqzl/5OX+pV9K9kTL6K2YeD1DkVSFIqyS3eT3H9iPfQs8nq8H1HbKze/BV8CgpZs7spjimNbue
Bexv4ILd9LMP6h6rGr8CSfCE5L5HFPCJwv8AmL5jwY9iPsiKTvyPUpKXNm2L8kqdPijfJZRtT4FB
v+Y3SjakSjGXgcxJG7Uh+okttslqONw3YIRrg3zSdZILFl0nG7Mx2yJRgluvrGPuablVfc24fk7e
H4FqWn+pLK+miU7W9EXaj92bG1aY22qfAoN1nk05Nxyvc2tpxSJbFcUKMZcRPWco2Vdfqast6yzv
1I0P6GR2uP6EN+rFR+5cZabR6WjXqfBFN0nyQkteLHD1Ysnob1FNierqxJenqxlSFqaLraKOrJRa
Xkk4zg0s45JTnOtLwiClrr6T1FrK/kpakcL2NWWtNx3T5LjqxNmg1JvGBT1p2vcjKeuvcj+zet9b
5Q9TSmpau7wOOtq7aVFw1Y7j0v2eXqSeMeDTWtPa7yytTVRrf9Pq76jde5PX1sQaqKI+tqJuuGJ6
WrsJaa/hRfPv/ob8oUZvgrcmJXwNJm2TPqyVuSPqFUkPuNOafDOfBh3kSWKRUXZn97aFHU5ORqLO
54MsxIu+0Vs+qjtZU3Z9WRqMhKTwZHtZuvArMMtFS5LsdMqcjMqHtZcngyzDLTO5l2VFlTkclJmZ
dtmZGJG5CtmGdrKm8nI1FlN4OTDN27DFZiQ84/BHc0it6LTsyVuHmzc+Bd6Pqsv5Fboa9RG6MkVO
VFvUids7Ms7po/iRZcWjM6P4sRqOTcRuVFepE+rHud2ojt1UzD8lajo7Jpm5vtK9RIv1IlRnFi1O
EUp5G1wXIr1TtlZvi8C3zpmNTHuXGeSpujLHGE7PzH2/czK39xrTnn2Lu+tm2Uit2TtlgVcFN5Go
ywbtwlNlQZubybZ8FRbLvAs9vscNMxI3JitcKh7W0XeTbJ2NR3IcpeRNd0fYrhlvg3xu/g7osdSa
sUvKNnKMKi3lnY7XA1RchSg6rJUvqfke5mPAocpcHfKi9N9LO9myM243xZyPezteDk+S9V/P4NsZ
vb7FN2i3yflz2/B9Zeo7ZcHRS1XZ+ZKUvuWVHUx7H1t/ct8n5ba+x9cz8ybaOzUcPsV6sz+NP/J3
vd9ylqOj+NL/ACZz9+j2Tkv7Wd85L9T/APaYnM7pyr56XHcvsVLdXyYMSkfz/c/Mv/Jgw5HcmUuT
y18GdOX3Pd/J23fwfRIzh9MRs7otdLVs7lKP3/d8fuFR3Pt9jts7jtwVmzFmW/0PJ5MnOP8ARdv/
AAdzZkpcnJmyi42jutjtFI4MlLk89bjuRlsplmbM2VEzJnkwX0yXEttjsqN2XudndkpF7mZ6X4PL
+5kwc9NqRdnlmD6qPqf4aQrk6Z5fS90qPqfSo2jLbMm2JcpPp8HkxZtRlsw3+K8pHufBlsxZVFtH
BtLlZyztO5H/AOwtHweaPI/HXHJukeRySyZWDKLijP4Kid0clxRtfJco2WoFSE9tn0nwVHg7oZHs
RulApwLjHJ9Ni3aeTshRVY/DvcLQmo0Xt3IzpDqNC0i5QsbjGmem1kTlp3ZnTLgv0M6f/BT0v+C/
Tr9BR92XttGYUyv5Soq0X6X/AAUl5F2ly00io+5urd8C/KJdtM2Sv8FLB3wvA5QxXsenTuzfLj5J
YVnpy58EXhfcyootLtE0juSZvguDe6/U/lG1HuHHUdNPydzizwyWOz8FRVsUpqveyU4pX4ojKb5K
nqxQ9lOvJHThG4yZeo6fsyVU6Fpbe1ilOS+zNq1FKXsbtJdz4o/O7WhRepFMk9NbqQ/Vi9rFv1Nq
XuVpS32Jxh+TdMvV7X8lQmpMU9KPyPTis8G7Wiv0NTUjHKjSFj8sXqxpknox3SeEShqKs8/6FIjK
aK4SG8cjpD3RE2WVgRwYRx4GxfYwh/vVHyxTmjgbSLcRKjCsWMCx0VItx6NpG6SsqjCLrAlRgtrB
go4NzWTgbSLawfTQ6RVCVFUYXJlZOC0i5I4owj4EttHBwcFGEW1ZnBhH09W6H1t+BWeCMPdix1Tr
npKiT+TJiumeuWjFDpGDjom4iwWjgyXE4PYwW0dzopO2WjOCrX6nubV7iwVwx10+qyO76RG3k3I3
NH0m5EscfgTqxXEe3gVcMVxO3EjHN0KTRJNFYN1fJmKPh4HjFEdP0+Td8Wbk1digo7n8Dk1TZNQW
V4NztMw2ZQpNFR58kMcog0uUR046W63XBGU1ySnXBjhFpLgjLUVfIlpTX6HfF7b8jbrkltmsIUYL
t9y35gaS5RClTaHpvDbJpZawRklRHd9TFp/+ZdZWSenowe00/XjSs05RWWacND6HLJF6qzY6X834
IXHwRlEnNpZdUak4q42S2KqQ9PUfHuaO2sM03XcOM+LpEo3nHArj/KRnDjyXh28o7cdp2Tfpi387
bJQ2J3ncR9GW2G62h+s8/I9DRpyuxb9Kn9jMTsjYtTVj+otOLwiBH3I+jKW3d4Z+Y7YvgvT+qhLW
XL5Y/wBo0+2VXYobUm1VxPW1JNtlN1JIlpwjiUrizT15N8j3l6Ev5eGRi3S8kZM9P9nn+Zf+D0n/
ADKsHqO5SfuLR/8A1jjtSPWnFOUs5FprtZrf4I9ixES/Z243zRo6Wq7aVmi4xzKXP+h0Iv3KRtvD
Ixf0ifgbRXyL7G+yEfnpTGkSIK8N0X8DfH73Ri+DBD2b6WOjcMwST8MXSKvkXRvrgdljS4FK2Kzg
XV7TJwYHEXRIz0bXTgdDvpg2ivour6MfW/cT+Bl+3RigQLQ0+jaEn79L6PaXLg9ii6XSqFgpDK6e
3TA0xtcjgp4E5c+41Y9kqQtTVyUJX0tcUJci3HJuQ9PeJtH6fgn+CJKicD1CvglnAvuRRafybXln
/qWiMfY/QjJj/tIwjLF8G7U/5HGJ6j4E9RV8j9NkY1eRUs9Iz9heKRGW6PIqNX7lP2HX2PnYJzRX
81Wh6cfIly2RnJUVf8tC1G6r3NP7DcZcCc8xZwqoU48H/uU+B/mJyN0V8kVJVt4E56m2XsLZleB3
9N9Y732+RenK8E3J/Ya05dpz3E93FE9PTeUR9b6m+SG36R+9f8i9XMReld7cjc3kfoypWL1PY2X+
Z7EvTx2koPuTN04riz0v2fuk1RCeorm8serpfUkR/wCpbp80JRznyRUaWPccrts7nSR9Vx8EdPVh
cm6HLS7UPc7wQ3cEFCl9iS9yOpP/AJLpWvYuUuxcWz1NsZ17mnD0VveOCezt3LBtS3Y7hS/p/qH+
z/s/8b4Zl7tR8s9TUR43cdpDW/adSofJpv1oJm+GqtRmpHUe1PySUHcVE0lOSW6Xk3R+naaFcX/o
dH+4bE/Y09pG/bp+pH4RIjJe5j+kSbL+CRo1/Ufp++/Z/v00v7usiI+mqR6Q6sQ+kvv0fnIoeRdF
9+rXW0SF0j1a6s/Xq2IZH79X0Y+u32ESRXuMkbvkg/cfSv0JfYgv/LpVWfoe/StNXI7zHsdspV/S
d8TMqMSslZj8NlG6ilyXbS9hKXuXQ0mKQh0vFH6lvgrd0erDLIwlAjfR7BOXLNT8ER15HeMm2xy/
8SvD8kNvuRbJm7yPd7CS4qyUpeTt/pshG3s9jP8ASeo0Uv8Agumo+zJRfNCr2Oy4EdTUlv2lNU/Y
3VVCh7mm/dGko2o7vBp3yT/uG9PlIe7kjpfBdeD09NSS4N7luRUudw9vglp7sIi0aXvtIf0i/tI0
Q+4n43mrXsatyltHf9JE09t7N3ghfNj/AL/wL+07fZmeT9TWr+k1lLzwadGlZdXUujv+kx/Sd3J/
6Ep12kU/6SWu6eT0/wBng2/gc9TdnkjpyJQh9TiyKcMHqRlKIq1bRepLdghsZH3NOcI3HcZK3eBR
0+SL1W7XuLQvd9h+muFgnvxpf0EZbKZJuOfBDasWZwyep5HD9lWZIUtem3yZjy8EvR5XA9TWz8D1
ElcVZUZtL7ilJvkntJ6ep26kVtog09jh5Fv9jT0dGW70/q/0OnL2kc/oM3T8MdDp2fIo/HX9C0+G
Qf8A4jZvfHJ+hJJ/vdPU9hd2WbvYqyt3Sir5MDfllyZh2bzkpS6VZtsx0pl0buOlWWVZW7rVnJZd
mGbjkrd0wbbOen1FXZuMyMMs5Ntj89GPru9xfYZv9h/YkJGmvbpj3In6EZezOfHT2OSkW0exQ20X
wUpNIWc9K6exz03EY3yYMo3URS6PokSskvkq7wZRn/7O3IntK4Kuz3M4JJPn8EWyhv5N/wAjf/iM
TIxeKJfLNnyV7ornB7WPa8VRHUNt+KEc4M0TjurwbbXHke9KioPJHd7lPFo3f0oST4Qp3H/IlfA4
bu2TuxSbWfce1+PBbklXuVvVG5yhIe2iWdtz8ksr6jUmJuai/kXeu1D4ZtljwL8yL7T0t67SEnJO
3Z/FVSZ6q1Yk4JrgSeoo7Y+Tc9eNlxkqTG0+xPqt/wBPki/WWV/gl+csIb0+C3qbJLw/JJeuu4a0
2p55F68trv6iMfXWBuMvUbF630GP2jwOtTfjA9TTxGxx1tRabfBu9ZORs09RNfB+Zq02XOeSo6lC
lpPdB4F6mp4L09RI9LT+n3RFzjuh/SL+V+cm1PPjJs1m1C8FySb+WT9B58Kz/qG9meCtZ5XDJrQe
fayWtq9ykxbvb3LWmiUNJU/exR/ao3C+S9is1F+zYlWMjf7RHLRb0VL7sxpV9jScIYUrZnS/yfwo
mpDT0syVITfvY1PQSn4aNnodvnJP9ph2pu9qHH9o0bnfPweloQcHf1fA/wB++sbfaZdk/llJkrfJ
bZmRmRSK3GMEYylwqGj2KiP993ZifVkaib0xW8naWJTdGGjHBlmZIwzdZ3Sz8lRN24Sm6MM3Xgps
5yVFm7wVKR2s3bhJumNJl2VKRzkfSnI7ZG9MqTO1lpiU2fUWmd0sFN59ykzdudHdIqA5XyU5HOR7
X+BKWCtx2plsScqHtdm8zKik7NyO8qy1wJNndZ2WXJ4PLPKLizutnGfuVFsti3G3P6m5WZi7Gknf
uXboUZXIqKkj1HLgrJ9MiluPV8mxRbLNyyV6b/Q+n/JuWBRkrPpf6j5iU+5H0f4RWYjcc2fSNbWX
LrYklaK2Fy5K0+D6RuZcOTEGzvTN3kSWaHGUWbnyVpu0VR3Y+Cosyn+h3YN9iruKao7n+haK7vuV
N4OyRhFSlRfkqLbRU7LhLazte84a+TvmNw+oy5SXydx2OmVGUj822Y5KjqSLlKR3zcj8vUa+C5Tm
d05P7nZJotS1a+BrVlL8PbNr7F3KS+53KmXbX2L05SkvuXq307G2d8GyngpNr7HEpWbZR2nbG/sc
SO+LKUTh/Yzp2cUUr/QuN/qbZxqR28luLKkqft03qJ3xp+/Tsid0a6YLjp/qfmRydqP4RunDajsM
wpdaXJ9GDbPHT46JH0dv2O+NL3/0D6pIvyOBwONcHHTN9OOm7pu6Z/fJItrpTMLHv12oyM2ibLrp
u/l6ZKSODCNh7F103yXXjHTg2ozyYNonKOTtRRu4RddK8H0jxgUEdyODabpLLPpG/Bx2n0jpV+Da
sibiYRRukrPpGfB9JwbUW4jqJe0+k7YUfTg+g+k46cdU5R/Q+mihH0FIuStn0mDuPoMI4PoG1HJt
otxyfSYjZcon8MtLCFaP4ZiJtPpMRK60i2fQbolUfTY9qHBxFgrbRs22W0ZiWl2kbiU4DcFRTVC7
bH25PT2l0ZgdscCckZiqN8F90Rvg8MlJRVo21j2E6R9Jtr7CnJU/kykXGPb5IuSpFfUOWmsm1wI8
EqjlHpbMlvD+RramUo9j8iepg8SN+nEuUcHMSbgsrybNTlfgTksMpNE9iyh6bjiLpivtfsOO2/lC
0UsN4Qp6ir5HWaPUgv0Iy1VaNqYnCPk3aicWenGVz9h7YLix+taV8ii9SmPYk0dqxJ1RGWpC/sKH
EvZlwWfBGf7Rp2vcUL2+7Y3o/Sb5K1yKLVM3QXBsnhRf+T86FP3JelFfcb//AFbYpOnZ3QSFtpeR
SlFSF+z7N2ozUa013eDU/ZnpRuPBqy9JWkStVkZp6r2ybV5Iwlpxi3jJPUgktkbE4xtH0NHdFoWr
Jf5GpqEaEowi21uJRl9Pj/RKckZNTxk4JTceeiZwMQ6Qu0lgjCfgtIbr99pw8CKow0LBVDolOrz1
fsiOBkEuGyKo4RJqiLrJkZqS9hYHRGPhiVdHQseDI/clKvJkYlRHAyP3FgpjoTrkyMn5oWBkULBT
NvuRwZJUNL8EW0NeSKOCmiW0jgyh0N0W0UulbTjpRlDrPTg7UKU1k4G6ycYQsDjtRwK0bduTg4PT
pH0n0m2kbki6F2jaQseS64NlI4LaPTZuQ5URVG5IbrjqsFtcI9M4MoWmbvccttHabmJ0X7HptHBx
lIel/KLBurJtj75HN8scmsI7eaFv8I08XbHS4JaLySwYRGCWBN8septzZ2YY5aizRF1wWvBtn7nH
LHt8IcFdCtZo3VkUIf1G6a5JTrg7MOj81cEMeSW1fSakX9DZK1mhUQ09PghvXIqWXL8F/wDiRnDw
bZOtT5JT/qmatc0akNd1iokZ80jRj8GX+UxR003chsjq6fjwRjdTXI68xNTVcpNN+SV+IGrp6M+y
PBHU1rpHe/pFHTVxUuT7i1tJ8Lgjj72Tjp4dYNSc5TlbNNyj2WadKrFGM2oREp9xq9qwKGi+eSOn
OTljyRpd0yMvg/Lw7H+z/tHMfJp07dcI/wCoqVEdP2R+0fclGf0sc9FW35Qv2eS7pMg/ZUjT1NF7
ZQyav7C86jxKRHfGlRt5Zv0o+Sa9sEVH34JQlnbGj9nj/wCP7vj8Wn7bkQ+YIw6IU+WIeCSNMbGi
LfsU2YJicZVTNO/MCX75anyWMUXwskfsOhR8FLyWho9Tyyxkb8H6Do23yRXgwMvzIx7DFJiY6Nku
CJgrqzf/ADMsZnx0dGy8WRXgwMtcsv4Gb+jyJPwyJgkvwKvIhivno6FAiWSTEx/Yoz1ajybtR2+j
iuBORVmDgpEhuvJS6S6PoxdbI9ETXRrqxS+SP26NiNT7df1JIh89XqebNP7dM+xL79K+Rx6S+xCX
u+s5EBkdxqJCJEdqH03+bIV7DO72654sko46T+xB/wAzP0ETcvBAkRUjUoh9zU+xBLkkIb83Rp0Q
X/l1U3HcdkdtIluVurPUSpWKLgk7o1JvKRqRj/KxRlBNGm/dHpxVPiyEsP7lqO2qNrQ9R/Uf1bVZ
PQjpJbXV0S/ts1u3dCx5Se0cNL6fIpryzdVHpRjb4P8A2NTV52k9P09qT5NzWUaaNXTb7xP5NU0Z
auE3yb4O1RpNcohCfsSnD6vklqTdylllQn/khpyqn7C1H5Rr/wBxqSjhkN+aRoz0u2fujTjPPbZp
x0v58fY1G8uskZP6VEkoq5ryRjBPJqNeWQ05xbwas/c0v7f9DD7mn77BiS9yI8kmiCGh0Rv2N3gU
mTZsXuad+Ikv30NNcPrGcfci/eIyxNjJWen46w+WfoPpBvo2ySl0ZBLh9GKXmyD+Bjsz0Yo+OjIP
5o/QZuXuachjJL2F9hkV7jGWvc0xkvwbRDIV5Y/sMUvNkLGSs/Ub+CN+5gW3g7utRuh37lL2Lg6O
6dlTs7SY7eBRSsUhmC2cmBMTZgpCXsUYHu8lWOsm5mS0RxhMi37HI9pUsGp1W73H7l12ouxMqPDZ
C/CJK/J+WNTwzbfg7T1JoWfJJx9iD/kRbfgVM/L8kVPFGpGxbPYm9TlkI2S2+Te/p9yVyqRafCIb
PpvghvdYJZ8j9P7DUzbuxQlElLV9yK3K7JOP2FNfQhuTykQp2xODw2JamKNWO5YKj7F6hpQ3jUf5
iWpnaS3SqQmpXiyE4ydJ3RHe6pFJ3T60iX2Kjy4myXKINqu41Uau/wDmfIpLg0V8HreERQxqLrB3
YdmpXlUamq+Gx3/SerFVKQtPTntgd9S+5pwgrTfgz5FKH8uS7S7iaj5NScrqUiUpM2J8Edfdk75L
BrY54O6mjNLAv2bQy/JFvxE2RHB8oT2uvsb53fyOMqJatfVM1NKPLNmpjBo6GnUpX4Faf01kjt8K
zU9R14Iwj3boE9Vxkot3QptqLWckv2dvM54PXkuHhk25pLaett2wWEv9FsbylRz4Jt/ocj07PuKP
t1omQySoepL3OaGln98tV+HjoyKIr2Qz7s29Gz1Hy+khN+BfYdEYryyMTB8ifl9Gb3WOjIx+SK9h
n6iR8jYtR89GX/SfoOiK92RXhdGY8lDPUfjg5HQosh8GB/gUvcoZufg/QYl4I/Axi+R/Y3ezOenJ
yYPByiix20UuCNHI8m4WeDdZyWhbX5KcjdeRqLNk2bh0zntE7HTFtyhWy9xUZZFHUdM3McVI75YE
91sauhrx13J0KM5Dl5KjIrUkbrGos75drZGTfJ2ui02kLdKqOxiUJChqy/UcrtjUXZWo+3wRk52+
SWx0b91QfJunLPsdskjdGeBQ1Z8IeyabNsJHp6krvyXGSsnGMsm6Uv0Iucu7kqDxR6u9n50qpUjs
dFxm9qfgjp/tEu2+RuE8myEsGZ4IvdwiS0pcnq7z86XdZ+TqW/Yeo24kYftD7UsD9Oasrd2G2Uri
WsMlp6bZfnqpyW5LwJbduM5GopX9x6nCFHUglP4HHbz8i2pVd4I+ppKS9xdn/JL0YIUpRUkV6e34
HCEVuHq3mz09WNv3Z/CiflLHFENOenxyfwjGlQtdU4L+Ur0hxjp7WzdDm7FDU0raP4I4K4xN2myp
Q2v7HLjDyvcUoYaNkkpfoPTj2HqR+vmxab002vJKOxfqiU55bZWxTjVFenX6HqSk/wC0XpOlzR9K
T9khxSP+p3/mENNq2iWnexNUfI4RalaPAtPUlUU7wKcHU15Fp3aRH1XiP+hfS0ypRZu8FJZ+Tf5Y
uXRweTB5+5TNqHeCvBXgz++xlFJMytpuiUr6WJUU4s4P/EpJtDtG5FJMymi/PTyjJXj3KyZMG3bI
+lm+slJO/g4ZYkk2Vsf6mTB9DODcikmzMWixKslOLMmMmISO5GCqdGYin5MI+hov8Hafw2zuW1+x
a5NqhuPoZv8AJiNn0Fs/LyfTbL1OTtMQMxLyfTZmH/HRKGWfRkqeOi2LtKcUdx+WfTS9zvZ+Wyp8
Hcfl/wDBVP8AU7zGGVG2fmY6VBYO8zyflSaKbZ3na6fuYbO9mOT8tn5hn8FwltMakmi9TJ2uvsVC
Ta+T825dK05tFt7vudyo7JuJe50dyyPZaPrk/sd5StfJ26kqN03uM4O2bX2Z3T3ffpyVGUmXNUdh
W50XMo7Gzv46XAt2bZR/4O2KOR3FFPk7LO7uRTO03WVLH4Kj5PYt9xn8FWWjvX6nuWkbpLHwYPpZ
aWBweKMKy/8A9hsnycNdN0ro7UzJaz+g08P8FHDR38HbFr7ozf8Agbq/0Kiu72OGhypsSim2/Be1
pnD/AMENKUG3L2FPbJFVL/A2k1+g9OX1ItRefY3USjJU0zbGNm/a+L4P+n2ZNyv/AAenNU+lQVil
tl9y5xde/wC9x+KqLcadGyi6FChPaZRlGEcDwNuPBhDtGI/v0khLbZwbaLcTETg3SRwN0ZWCtpwb
aFccn0lG6SODgTax8n0jqJVYF2mEbaFuWTETCFKSPpHSMrCPpHjBtSI+5wYiKU1k4HSN01gwh4OM
CVHBto+k4HUfwXJYMI4KrAlRwUhWsn0mEXNHA8HcjET6SkhYOB7UJy5PpHguSPpHg4wLtPpMRPpy
fSdqo7on04HSyK1g+kfacYsWDg4wK0cDcUULhOiXwRlQsFbR+34FgSSodqj0kJtUzgVe4pTQ2qZh
ZE5K0Yx8DVZO7DKWorMKx7122V6iG1UkOsGIn00UxRorVXcxxj7CepHNG3f3FxzZiOLoSl2sdK0P
2I3h14PypOQt0VTZ3JYNkXbJtQppHpx+kXqQtsbjQ5Rx4FHVhfyR7eULbjJ2xs/hig1TE9SCdoWk
13MuC5Fir/Bva3Je5tcFGyTx8DT8SoSlprHklVVVnpL6XkW6EZNolGNJ8EZabqV0LUa3Je56e2MZ
Gk8c2Z04y254J6Gnoq06JXXBl6chaENFOXwW4qO4itLO4vZaPoNsuRTlDBsjFP3bRoxqrZFpJtr2
P+kejn3LccyROVUkd1YLSXcrHLVns3P/AAJxnHUZ3ae2/gX7RKouJGS1FOoj0tPT/LXmhzf9Nk1J
du4hLT5o19KeJQx9zSWl9UvqIPQXa3kUprbL2I+k6beWXLxSI6kI74LBD9nS72/IpyX6oh+zbrk3
VE776jglov8AcX+4fSOpJZawZwZ+kjXlHqbT7G5e/TJZwNViyWDbL6bN3uNpfvoyrNWZLN1dGiqO
DYcF10bN1dbo4NpwcFHBdGTg3UcG04OD0zg4OOm6jjpdHBsODg2e/TjpwXR9ihuh9IQfln2K6XRf
TjptODgWmWX1ui0UXXT0zjptRbLMFsstDhLr6fg4LNqLkjcxbR7i6HtR6chySGnSdiomkKVeBKPg
3zyT60Jv2sc14JqX1fJu8FLwjbqPBCuNxpjXCJqOfBdZFNGkrzY2vYU98qJ/ERaKRGVyjEW53RKK
+m+Twz6YijFZbIyat9IPxRp17EdTOGRXsjclmzbp8Fzy2T1NPmrIw3V9i5Pn3EovMeBw5sWpI1Lf
8o5pWjb8UPdmK8MWzMd2RTaqQkQguLI7r3+TD/4PUXjyQ+ER1WpJFeIRIryusYRHapuhasXVKrI6
EuY4FOa82TS55NXTbtM9fbh8EY+yonqJ8fysh7J2xJ4bFq6cnF+5HT1H3J0NL+ZE9bb9Ts1H7mst
OUsy8C1dVbneWbFLuWKP+p/aIJr/AOj86oL5H6C3YIzS48C2qnWTMaNHUSs0/tR/1D2n9qNWVZsh
C/0JQXsae3m1kjKbbj7MblFLaPR0n+X/AFCjG5fApvlmybzRL9pk0nOWE2Rj7E9fTnUpS8Mjq62Y
/wD2R9SEfubofSR+4/uf9NJJz5NH9qgvql4Ees33RyNfJqr2/wBF+z/YkL4FfjpM/UyS2kLMlxP0
JmmmSH+8j9zT/sJMX2H01esBdLF9ujP16yI9I/frIQxk/v1iR6L79ZF9ZEekOrF0Y/uP7D6afSCH
0YujJC6RF+4Y+qfyL8OSVdGRfn8EOlMnXSQqNQW10Rsl9xErIk/t1idvNGo5ElF+SMXzY34JbeX4
O/Nmk17D/wDHBGcs5O1UOMvJadLwR3ZpWelS3E69je8ns6PT082OTWaE4OsWNa0W7ISl2oxqJfcw
7FfJEho7OfIn7or5Hu9hfc9JLNCnKNOhxg/8D1NVCfKLSqlkejpSz5HBo3fFjglTfLN+3wRjHyaU
ny0L+4bk6Q162T0tLut8ir2sj+zKPb7iv+aJCusZRfke7xQ4xV4s3vl5Iacnas1Jx54NXf4dI7Xi
iMv/ABsek/p5IOPuJy5Fpw4LkruROUMbSenKXYpe5qJqzU1mkrfBKP0usbR60rcPESS+xH9D8iTr
iiE/2qEpx82fw8/c9SCpGlo7bfuRr+mz0vVez+kg35RrJf1GnKOn6ieCUpKrNLT5ijc9vHklo/sq
rT4bRepHA5S53UPUSvYOUvpTwmQab/Qg/O0/aIyk5KLwjR/sP2eMcWyAv7j9TUyK/Yj7Gppx03KD
wW/c1mnz/otGPmhih5ZD7FEmSj/5GB2fqNo58kiUebZCL8Eh/vF9zTz/ACjSEn7DswSb8iMCl4XS
rKRTKMHd0wOQutFWOhJ9MDfXcIqykZKsddMmByYuift0opGSrHQ2x/YfSEn79EZFGzBk5MDbOeil
0eTBko7TJyOjcZ6L2MlWdpko7TexZMCl4M9MCscbO0dijZ2nqMaT5N6+m+SCGxQswJSZNJ9UZ9h/
ck/6hN8WTX/ibvYgzR+xqfcUfI/sL7DUiVf00LV8jv2FJcm2LaN3P3Jw4o2/+JeffJjD9xJa0uTu
bbvyR+BU+IkNTNRFf8sT07W6y15Kk+By8DjElqard/8AkeLEvKY1fJr/ANwp1hkv7SOqvHJJX7F+
xBf0xNOXzY1H+b2JSluSkzElSZjNRI6214O5pbYip3XWMYq/I7VPA1/4nor6iEpxo1Ij9pMU6uLK
9o0PWqmiO3NMUWs2bqZsnKpbhqOdxPVr6nZNbu5mk17C1dTKWasqtpqaSkZWDvhT+B6Wg7kRVJqO
TbVNkdd8REo/00P9pxbHvlVKjVg32uR6k+4nTppHrS8npSwjKjI1XtSlVWcrMzXz46R19yuXCs22
uB6/bv1H4IaU+1Rjyac21255I/s+5epfFmn+17425kanF59yX7TujvZtv8zbhEdHXdQWcsWq9l82
PQ0JfmvKolq6kt05eX/ooxlLBubIvAqZFbuxnP4HlcjyTUnlseScpNYZysDS/fR05MXcj6i08CyX
Fna8mXkbtDpm2b5ZdjqRz2iycnazMsnI9sjZNl7kOnZTeBZHTLTFkvcjtZU8MvcOmVKWC7OS7wR7
i9yO1mWXuGos2zlkvcdsjueGcjplpkbkfUNKQ30wKEmfUOmbnLtFk5o7XixWzcVFm2bLse1ndLBl
mJF7u0W6WTD/AOTtkbZsu0NRYlNl7kPYxylPAnuQ6f8Ag3JvaJSZhq/uVFihqMvdH/JKMZHfK0Xu
Q1GRvTI73k7ZL9C4yqitSR2zjZtjKheo1GQovUTob9VWdsrVibktw9rolJytPqmR7+4271+h2v8A
UXqSr2H3xtk9mbL1eBLcq8WdklL7CnLixL4Gk/8Ak9SDpG3V+r5OI7vuUpkU2se5nYVFxHNPDeS5
U/uNRpfY2p9vuKRSS+w1HD+BrV8nCK0mz1rEpeBrTfOBuT3GYpn0UbYKjdLKFBEpe5UlaqitpLat
ticXg8k8NxkLUgtrqiEZY2qjh/4Htk4myT3Ixf8AgqI5N2356744Zxb+w4Hq33cihbdDjtaX2N2o
L038FL/6H6knkUtN0zau42ylRvT7japPBV/4RepNkdNalpcHJTketv7xL1Ebd/Jv1HczdF0ylP8A
5HDUngrT1H+pXqmzU1O32E1hi046lo/P1XKPsRejqODXsfxXX3P4tmzV1e3mhPTltY462s5R9ihP
Tm4tH8dierLcztdFLXaPW9aXqIXqz3G2Gq0vuV6z/wAl62o5VwYFH1pNfLN2o90vd/6Sk+0Tb7ip
F+TF0YyZs4wXbO6zsO+xuHJU2zP4MI4KMr9xW4zLp2szKj3Li6PqMvp2vB39Ox2jusydjMyMswYl
SO6XSkzMr6dsinKzLLUit2DMrOTEzMunZKjMunafWZZuTyYkZfTE2jMjkxJozPBn8GMH8RndKyzt
nR3ajOTtlR/EZlnJW90ZlfTtm0Zm2WYlRmbZkwfxJFtmGfxJGZX0+pozNvph19jM31xqSX6mXfT6
nRl9OWfV156YZ9bOWWYk0c3+5564x+P268f7tXkjgjH3MIjFLFnA40cF0PB9JO0PBNPwYOPwKTVt
j2obkh4GqOOvBx+LjrwcEL9y6GMjwcFfgUSNRODg4OOmEcdfpOCjg4ODakXX/wCSFq+bMC1X/KyP
yb6yNGp7GPYpj+5THKizfH3ybhj6x0Hjo6NsctltH0nBwZRiP4NqQrR9I3QrR9I3Q0uSFjJGpHwv
wxI0ujOMl0fSceTgvaUkJ7cn0jwbmj6T6R0jV3GF4O3/API6+4yRG/p8CJGtYrHtJ/3dK89JD+4y
f36x9PkjfNEhqQul/gk+uq/YscJYKXkTK6S+CK+RkjUMD62aek+ejHFljiYF0X36fBXV5JD9PycH
d/8Akfa35L9xY5ZE22M1H4Yq9h2TXHTUg3ddJRXJQyVdVrNYuujVm4x05Y78Msf2Jddb56W1gh7I
x1ZFPnoyU/6hD/BBiS6OXv0uLJbzHRMrphFDSZyNtk958JD/APyOpQf6CTebyQd3THTRGUXiz6jc
pGZoxMfecmo2/qPqHJ19zkw/wS0pe9mJEk2brOcF7rO15JqTrJ9RVjSfW/D5FukXuHseSpSyJ7j6
hV75EcmGJXlG3cS2/gUhRbpo9y7KsfuKcf1MzOS7sSui95hpj3PHuZZz+g9vBuRtZb/f8f7i4/0H
Bn/Y1xtGf+S/Bku+07cHLOWyvJl4NqwZtm3yfBn8GMHL6VuMNo+uX+TMrOTk5ZyXRx0w6K3M8nyW
2zyexi6+C8sydpe6XSvJbODjpgryeenBgyznp2tlvP3ODlnk4LaODgSSOOuEXRtoVnHS6rpVF0cF
0ZRlGInHTK6Iujgr8Cfg4GUXX4rPpGvwUi2v9Gm4n01+84tG7Z/x+Dj8PqVcRtfu0lwRckpWOo5H
FquqjQpOsn0pjqFG54+5xFjqGRxeOuFbN0sfcfah47Pw/TtRJ4lXklpQWExSk/0ZW2/sSi12+H/s
Sl4MoXi2foKo+TjwbPIn0o4PpxRx4M8C8m5If71GlS8DO3pumsGIkYeCODg7ayzgyNoU65M0OieP
pFg4ODJZdGS6HRx0yiqwLBaODJg4OKKRwJy5s4yOkbfArQ68DdHA0kcYQsdIrwJig1kwjgyjg9hO
h0jJUxDwOusI+BYKaJJDb4sspe/W6EkhbokscIf4LaxYsFJHBwcdOC9pVHBeSqLo7R/ggvBDGWOL
5Go5LZwVRwXT6V1SSI2qRJeKIQii5ROCkrN1eD0qybqIwSyRg0754NRpEdqMxOBRrkTcWfQy6EvL
8ClKJGHhuharSZFJX7m5r6h7UWkfRghKccclaL7r4N+qvy2PdVkdqpUQjpt7bIbuWskK/qEbpx7f
c2+EOSVUsUbZx/VjdckrjVHpKOPc3asKdXYsXAUIfqa32NfVlzY5QVS+D82P8o514v8A2JqGPYd+
DbLk3NGOiRyTQi6ySGakJ5o/Ql+9X3ND7Eh2W1g9hrk9R5EMUfk/QY4kYlopsc/MizJfRDotvt6b
eS2iijjo+q6YJ3xZfwRXGaL9j7nHRotodDwPBQ8EZV0UulWc9Mcnpy56PHTTGyXVMiWvYeSA69hK
XkTwUy45NziY5NT7D/Ao+Rr2QoiuJtfJ2n02z+GitiG6s+iP+CvTjX2LrBKSXA3JcDpeCX362/BB
fA3E3y4LcFtJenHCI6lYsU9qZUlFfoTmkuCl0QpyWBQVIf2NzyolJUjKRB7eWai2L6Sqwai2pdpF
pVHyKaVEscoWq1wb9ReLG6SxgXmKyKMcJdHJqpMlqqNwTpMjppLBHUSxdmmiUmaZUkmnSFPb2kpR
jSSPR0+V7eBTkr+5/S6KhPCeWbdWdUqFUrkIhFZe4jOUSl24JangpjjDwbvkcWst8G70luIaPO7F
MjNU5P26Sj7n7QvmiMZcMkoD/tf+xNVdJG75EmMz5IlEm/KE17Hptj+Ro1WfoP8AfaH2JGfcpD2j
sjo9JEPl0feJIvyQn0kbXzE/QS+Rfbp+nTgcVySc/PS4/wCBbotGWYYzH4Zffpp/3DL9jMkYlZfR
1yZLGxxrBG0YFEbZJxIpQsW72P0FPKEpEh0aNjH1ivcRJdPix/2kX8kfsQoj0rwT+w/b8CR87SJH
+0j7EPt1vq/jpMlYv7SX36qjT+xJX5P0KRrWhfc0zcuEPTt2OfSP3FXuQrg/9TUHOr+BqGizTlq4
yTr2Fq1g1X8C2kT9D/BUf6S1cYjU3bJTStolGGm/8D9XB6N9t8kJuSTkR0Y/S5UaeT8rzghGWGen
DL3eDTi+ScfclKVu5eR7Y/Sh6MIvYbpR2slpQtOIpS+kjuf0xIzfCZ4wShCfZ7kVuS7Socm7VFC8
s9SaqPRasOUz04an0kVqTtXTNRr2P2mE5f5Num6lQ/W5rk2Ka+n/AGE+jt1Yqd4L+T9DLwXyeoUW
+nJQhL3F8o5G7/faP2JEhVmN8CzlnA9Tx1j7JkV8DNpGBgZuf8x+hu9jnx0rpge5Foovo6l2lt5f
Sr6JHJyWNWLUZXR+BSbyz9CulnJybxZOTcNWNITcT2PTTFgdPI8m55EuCiXWMn4KJUz9SMhu/Bfm
xfYiIo3DQ6MI+nHv0UmXa44FP2FkWpjB8l2VZG34Pqoask75OcGHybTHsNxRwcHcske5YXuS+TZZ
VollEdJSRGO5do/ZkqLSx0uhaU8G+0SzngbeMC71RvtMuGJJijqSoc1THGDybpur9yOn6kcD2yTJ
aDlWR3PA6nFka9iPfyrNyabJQSN/k2wlg3TeRRm+3wRe9N1ZJQkS19bUW/2Z2SV14G9aVY8mnL1F
XJ/FSXyblONklHUUp+5q6mrSkds8mzSlefBe78y+Bwg6h56XF0fm6lSqkdmomP1P4KkS9KePBJSk
/R4sm1LNUi9N9gnN7dTwST1r9xT0J43WL1Z9/lj9HUtnqTePCf8AsXZqce525KfJ7IUW6MlHJfBS
dnrJlewtR8I2rH+gjCT4K89dyeDDplsrwY4N3grcYZvM4KTLYkzaP2KV0ZOx0ZTPJizB+YcOztZb
FZWS1Zw2VnpXJw4suxWrMJorJYsGE2dpmLOBO6KlFtn0tHNFPJTg0YiNvJTixpWbvJtot9OxWVsZ
mLS/BuRVGSxJHH+Czb/9CdMqsG738FSK8ClJ89PqH5Py8FLkuXJXKKo5pFcnczbDgv8A/adzOxnc
zDLsUdTyXuTR9R9WRuEjDR3yE4SqjmzlI37slRPzGQ3cWQ7lx7n1H1I/Ln/gxqYPrpFyl/g7dT/J
9Zc3bOyVFergtstFepg7puvuYdP3O3UkZnJI7vqMazP48v0O5uX3MF11qOrJI7pOX3MScX8HdNv7
nbLafxWylrNFx1JNFTk39ztk4/Yzqz/yX+HE6+x3Sb+5g29zL2FTb6cn1Pph0ZdmC9hT/FaVn5ka
/FUI2d8a6dqsUnGoso7Ily08e/8A2/g9hPopUcHk4FGixRLFFl1/oFNo+kfSjg2ibiYicF0YQ3Rt
o+kdI2ibMIdrBmJ9IklgzE4ML8KdF7TjgyjETCLaMxMI20ZifTRRxaPoMo+kxAeC2j6SoxMxPoPp
o+k+k4opF0cdFZ9I3t/c8dEhdo+0a6rZKjM8D7hreZ/0CiptHqPUbHt1JKjunfTj9woxnJfqLVc5
Tb92SqTVfJmTl9zCOPw3+CumRb+Sl9VewkvLOOqxZdd3knHx0+l/iqXA/wCwUYcdc9ODMX14IRiv
JHU1Y2jbFZ+5ugu73JJrjHS6OMn0s+l/4I6evC/kivSVMioR+/4MQwLcr+5BShGL/wDsnsiqolGs
HsYMqiO1YI74Kc649j1IQ2tojFLcxamrH9DV/KiqRKTvbuPzIwx/MS9KKdjlXb/21afgWPA0R+xh
FNVgjD3ZdIa2kUcEZJHBCdeSKXJdD/faToY0JIU5Ib8GnCP+SOOCh1yLHgoY5NeTgZ8CddLODgs+
S6GXWDgwjKwLA8cHGTCMo4ODaWZI0lwSodrF4FjgaHddLf8Az0uj0xOjgUUi2ihpjdCuOBVTMIeD
BG/I8EvwcGEONcF7D6DgTrhmUP3J9UKkcDSLcbPoopRPoPpPoPos+g+g+k+mjdtHj8H2EqwTF24P
oPoEq5F2jew2UfT/AMGYD7KFp+zNtE93AsH0ozA+/XaNuHCJUuBLbyJuFtm7ajETZV5IasufbppR
+SLe3ixuKi/sLT4TLxY4PyPGZG6WF7ngdJS+xxj8ClGdNZaJ9+ayRhJ4Zhp4zZbcb9jtSf2H6i2x
T5Of+B7aZxXuRvFslVSonCSxuJ7cbVg1JSfZfBqKXFEpqnfJHZHyRlLEvNjX0pP6kVd/odrz9jTl
wjR/tJS8+w5L6ekZOOC3X0+TfFLk09PSb234Kk7fyJTeyXJWnG3XgX/Uxl9yENPubIuu4deCMI5b
I6moqdCia6XsalrJDT0G8+xsm3iPk3Ur9/8Atv6C+wzZYpF+TTXz0tEYkbMMn9j9Rw8dH+9ZpkiQ
ptdHGLN75vpLIot4EYNtirpQpeT9B5EZ6OjdI9jYi2isdPBSJH6mTHWR+hGv6jPt0RjpIzxYmbU/
wVYmKiXt0rklg2OWD9B4MGkMl1usGYm1oljz14ycFIkT6ojaJGp9zjgenSMxXWnkpY64RF+bI/Jq
fgj8kJDRGf8AMdvIpvyJwiUz3N0fc05eWel44NS/CIbfJCb5Y/0FJLPB2c1Y1rS7n4JbHfVf3Gp9
jWE/NDcvGCMokJP+ZHqVbI45EyFeGJXfSU4LPJGM/pJzXKHGcrinwaNKsHdJR+5b1Yk1Dlv8FJ4J
/wBrIVhmeSxPf3NcCa4s75qJfrI2X2ylyL/p2h7vp8kPRlbbyTfwRivBq/Y1tHO2+i048yJt/Vgv
Wnsif/IVEIaMty9zR/tHoSdwJNxyOVdt0kKUuyvJp/s2lPG7NEPuL1POC17mm9N1K0b58mrqLmKJ
z/aHUVL/AAX/ANRXwbtCW5fBv1vGUQ/M2V7laGopsnKf01k1XD6bNFzVonKP00R/7ar9ikWb/BTM
Gm/ktG0hN8PB9haT8sb6b2V5/fM0fuSJY8ijdT6WQivpfJgYtv1WQb5oYyxjK/l6fqR+w9ot3PVx
gjc+naZeDvKVl+66PaLd0wN+OkKytw/t0ymKKNxIgzHsT3MX2Nxnk7GRbn2HcMx7Gem6S89HFHvZ
p9H0RFiosl0kujJfcZL3/AiZK/clXkk/HWKv8CfSiCNWiusPuaYpfYivJ2kIvkryLZyRZ/7GmR1P
5TVfwQUc0zSRf2IoqPtRukrGl1V+5OvY1L8lfBOJFLwQj7IwyD9j/wBR2Pbhkdztk6FF+5KHuS13
T8mnR+VLarFKWrLJJeV+BOsMkvg02vfgz5Mf0kNOWrLnJCneT8mUo/Y3S1X+pJLlYs0/Vk6vJKOn
JW34Jauq3UpFwf1j17/Qnp//AKySJftM8bsijPUSky+V4J6bebNsHJL4O9uNe5CMZI0f7T1v5TZJ
1uZKTrGR6Gg6i/8AgU1mskNB1GXLIyl72PdJVHJuUX6ad2ipTSisjjpT3biWrFbbyenpt2/BlVhC
gv8AJ6T8OhTlH5s1or2J/s+tzN4E55iiVyqNHo6P0R5f/bY6q5Ir4yPGRDcfBFt5YpexRdEXRRov
5GrIJPlifk5/fxh/NfRsuLo9Kb7jmxz9mcjK8CVoZtXD8iicodCl56Nii30o5OS3RuTRSZbHwPaQ
f/Iu5cFWc30wzMjnI0iE5clbh5MMUnh2VusdPJHNYHk3xZ3PJusai7YpT6NRkT3PyZkcihfJusqL
G2zuORpMfWMJumbtxW4b3IwyWT6j60cjW5f5MdOKMiyNKXJuvDFckXeRLdgb3IjnFi7kcq/cdSv7
CtlbsH1IabRUXdl7T6Tg7/0EpT4OyRtk+0uU0dkkfV2s5GtypEKads0vsXqOhxg7+EPW1fIoy1Ek
dskNTxCzvaJR05RsqKqPufTZ9BvSqjZqc+7OySrySjavhGpI3S4JR0n/AMj9T6GzmP8AklBtMWpp
u/At7XB2tOHsYfcerfkipVaWStF8o/Pz9zx/ka0/q+CWq+6B/D/4P4bG3FxHDUifTn7nraaxYlOK
HCMMj1XhsSeYr3MpWSUOX7HqTfb4X4FGXdH5Gks14I60n2LhEYOGYxohrRm4xj4I6c1bSo3xxp3d
FTgrJKC5P+onJ44RGM4bml7GNL/gU1iF39zZG4vbtvrvg8ijPlKuDansg+RpZTNsV6aqhbe5I9PZ
sjVEdSLyiMXDdSHp7aTHOWW3Zt+tDS06/Q/6hvbKz0q3L3PTtxX/AG+4Swd2Cl3IyJQ46Y4Mp9Mi
l5RTRb+oqjuf7/8ALuvYpxO/HS1ybXk3J5MI7sG5GMmS5FRyUXI7WY4LkXG0z2PJadHa76VPgxMo
y+n5bMl7qZh307z8vp3HZItZ+x3YLL03tPqO87G/sdxkvT5Ks78nbKjDZepk7eTkyzPJW+kdzvp2
OmdsqO/8GCoajotzZ9ZTlZcLiVLUbO2bR3TtC3SwLfIxJHMSWxnZKj+Ky2zt1JRP4rLcslbnRgre
0fxJGWYlR8nbOVfc+uR+a7XyZaOY/qPuivsN6Ricv8mZykcmJs7pSfT6pV9z6mLe/wDJFb0tqHtl
jpg3W6O59MNnuLdHdeDs0i3puvsOGzJa46QvixR9SrQ4x1UOiooyum1/gW2Nl0cfg21cWdkHL7I3
z0mkS09n+Ub3yy9mPcyqO2Nl0Z4/f5/2I+lFyWDgyhuMRSaOD6SqFg+kXaXQlXLOC0jK/fb2rycD
6VRwUJtF0OlwKTRwM2ezPpHQtMjjpwcF118Dx+Ckdys+nBVYMrpwZWTgdIqi66KzlHgwjMTgSXFk
W0UhujbQm0Mtozgxk46YRwZqxDfKJJcdaXkTaH2jEmJ0YODgzHBg7dxmTKyfSfSZX4IoWM1ZI4Pp
PpKo3zQ6XTCPoPoPpPpMo+k4PpZVHHTt5PqdHfJs4I9ptSV0YXTCstxwRwVsju8s7Uvuhzo4Koum
bYTl+h3OUkZjR6s1Zu1YxSN8IdrLXtdllRyJyVWRcl3+w4dt+w3FY5HUTuMRFCskXsW//wChvauT
Wjz3G6a7T04QW35KiqcqIzlHu8I9KTW77D2r5Y4/7U0dP3YvFDgqsWm3ldHjBGuWz9C/Bpplo9ik
vA6wxfs8vqLo+/779Rkr4FFcico5HZpqKwmKvY2skjT9+jJz92XXSD8ITQ49O07ujjp5Ln03UcHB
biLBL7FebO07umD02XR+pHaYKf2Iw0/8i389HtHTwb+RQjaZvmzJzkjtF9iJ2uhb+SymsmENpHa9
rIOTvo+sZkaG2SoU10UGJyPB20y9vTtoqsmaMUPFfhXtQ93AqVngxRlIjFcEr8GyPFi3cn/9jcsx
PFHyPbkdcnd/wdvI91KhNK8m50mzY6SsvFHJvWULa1u6OScSWz9DfrI7ODUtZGo4bNaM3dC9Rdtj
cKaN8l2nb7Hqakbvg/hnaqZKH9LK8i0xr/xEooWpqx/Q04RSsl9hTlK0+CXtR8rkXFXZ3JY8n5LU
5XeCnGnyP7k582xQgq9+mm/Fof2FqN2rGviiP+1ND7jEJoV80OiF+5+g8mjXG7pteOksml9x/v39
+khSl5MD9hbuXwfoNkW322RP0HTO3NDGkbL77EOmJ+DJ2mDdJdIw/lLPgtMT6t/Jk7er6Kvcj5x0
SXuJ1fR/cbY1g4NzXTbAT82Q+3SPsZO0bIrS9xb/AGP0HRpjH1hFcNkbNsBuaPT8IX9vSH2/Bl0f
XZFLz0cZEuCX36wryQskV7EmuRSfInDDZGUuSoewnq5d89KlPI4RZJm4eVY64JT9hxk1ZqNeCP3N
L7CrncaRBLhmr9iMLwT+EzmTh7Fa6wflPA3qOomv6T7SzXkh/cmpO0hGnD+Tcaf9qPzdSn7HY9zP
U8tlx5oWrP6jHMokZ6q/QfcljwOcn23gm/ghD+g1P7WSjFtro46XO0ueZ+WL7EvuS38WJeX8i1I/
SzR03zuJP4IaVeeST+CK/wBn3+HRfszBaFJ+OjSLXufobfBpy82NGnt8yyfoMhqVj3Npzf76a+ej
F/QKneB0jTXyfoSGaafPRk2/5jAyEl46wXkwJvpgohKiijCyVF/5LlK4l+R/cx05MG8oxnIvt0g/
dj+w6Zz5Ght+5TMG3wZRSXkX2LEijJRvfv0aizgiNEuum/kWfBY8G7wRXwKXuRfsRVlnKKhJr7Fy
my/Yf2G4yo+tvpwfSRII/Qf3JLyJeRV4FCzIiW18j3N0UuSujgpNW/cuXsav2JOMhxlLLQkRivAn
/wCRp/YWr5RqW8tHPDN0eGb/ACbVzY02bYt8FTfJh4H492R/Z9P/AAPNe5tjPuFqP+XJHbmkKbQn
9Mh6SknK+ChQ4oUW7UUdr+DdJvYuEKQs98h6td3uelHmeLI/tOosvhkYSnl+Tes2bIdruqY0+eCU
CUqryexDT5IanlHpt9/0o9Rx7iai1JtUPVl5/wBqWsEdPVlTOTmsmJZJKbzZW4rekW5oVSKsi0/5
irKT8nK4HGD/AH8oN8s+tD8sdChf5Ze4u/1K3DzYn4sj3qjkwRqRSkPaZdSK3DKlhGZGGfUZki7i
zFFbsl7k2OqGJPFFWXZlo7Wh7WVqujtaY1Fne8ldpyiMo+Gc5HRz2HdI7ZIWRd5e+JhxZ3yr2K3x
Y8xo5wZmdskfB9SO19PzPPkVTQ6lZf4K1JYP4iHT5Ep8m3fEjqRfDKTyKXhFKQ3KWDMzskXI27kS
2leD6T6Dg3+CrHTTY/YpSKsaT5E/A1bsTg+BLUvBaTRi6KY4qzcJPx7G1F1QmuDNtlrcacVF/qaS
+B4tkopOP3FO+73FBt0bYWOcnnqmbXdFR/yf9Q3bNqTsetuf9o9Nxu/cbzT9jG5m2pfqPUU22fzM
7Yslqt8rgzKl7dU4M21aFqTf6C01lJUhak5ceBQXclhC1uJIo26blKNeT814N0cM5/5Ns5G6EslL
/wCzdqu3/tZKPJ3SZ2t2d9s7G4/Yy5X9z6pH1MzJv9T6mdyd+5cXKjuO1s7v3/byfVI7rfz17JUj
uZ2SlR7mUVC0zMmZRUcM+qX+elcCab6V5Luj6pGUYs5Lt9Pql/kq30weRLkvJy+uelF5Msuizgqj
B5OOtWW8l5R5ODBnJRaRx0o4G8lfuOPwUcG7bnruo3KJaX6Fbf8Ag+mX+Dbsz8o4oyjB8H0H0ZFF
RLcT6DbGJbhZmBe2i3HB/DHUCngujj8Fzz9xRw/g31yP9zgo+kvafT+Ci6x8l7Fj2OPwLFGEmNxR
x1UYoU5efBxkairN88L5G1FfoPH+2EKTXSf36S3LyX1xTOC0j6fBLAla4HSHj99rSeTIxiwceD5I
trNHA6Rva8mUMa8IVodEUvLFg4LrpSRweCuTgpI+k4NtCckbUsnBkaiYRwV5G6OBWh0iNovajwmZ
VHKO2mN0Pajgha4Z3YEltZe1FHBVJD46OojO9EayyUqJdaStlpHBVHHTKOOl1wLBLGR4F8EY1knj
gcUjjHXPRJ8CnRxZHU28m9ngc9tfoJ0rG/Y2+k/8CjtrJBLyrFpqNi3LlHHamKEUjER4/Ap15HjK
iQivLE6Lp0XQ4qJlM+kydqG2jY15NkfHLHor6iTrurg4KUTfKNEIfJpxiqtWz05cvBq0+i7bRDGT
bHhZbJaCiTddyQ+0whTlGkz1JK68DlH6/FHfFxiXNU/JdVGI47cktRLk1Irw/wDa+kn7ir+mzGBL
3ZY6HFOmQ99o5Ir56U8lJYJohG8PwN/A/wB9rH6DKSwJ1kZH2sX9o2bfJGLLRkc/cx7Dsg/6X1/X
o/uM2rBZs8m5maPcuurx0bXVZP0M8Ea6RGN7RuDo9O2Jm03yPpG4oaiyM5ZM+wkmJ+5uHG8mzUyv
c+43XSJIl1jJ+StiZ/DRYmV5G0jgrYmSlFYHH26PA8H6mr9huhRUFZ9CJSraY6RYsUqO4UY8Iaj/
AMCnPKKWK8H1YR9aow0z1IrgUZOmhTu31qDpkU+RtLLX4Nkolfys05eNxv2rB4ijKT+T1K7rFCat
yNu1ULS01mbFOcfklFpZPuySNNkn8E9NrvWBScbrwdyVexf8qeBfYU06dZO/Nke20eE/LI6MPDJL
4NOS5kyb+B6Ml3IUpQ48FukvCHP3Z+bSj8l6dfcdDTNTbjBP7ms/n/ameui//Ij/AGdIpc+5FSJF
vhEPsSRa9z9Cm8CkSNOS8SL+B/vv2iPSRTfdZ2lkXVqxf2kjd5RGXkZI2e3RkY+JH2GbvN9Jfeuj
lQ0jT/pvp2sqUXXudwkpFj6S8dV0a9zT+3SksGYMi35Gb6GRheCJVjSFHwJ0NI3XyzIkvYbElwR3
DVjETJdYfY3S4KQvuIoowhryTNRfJJrktja5aK+TV+wxs2qI8NFvpH2shQvSISn9QpMxwhw0rLj9
R/EIx1G2jVv2H6Tf6Edwr9ulzVkdVKr8H/qN9UR+xHH83RbT0s+xCT5NKiX2NPUXKYtOfnFj1JNO
vBVUo4JUXJdsfJqSfsPU/ksY1HHaacTS/tQ643CdXE8J1lj0dF5fBv1JXJyyydexldkTVl8HqJdh
P5PhG32EtNtYKlk2tpSOz6ic9byNN5Zqv5/2vF+zEr8V0d/yswOF8Fe4l8GPPSvgwyN/0k/cjMqx
pfvtc/QcjfB1JHpze2S5T6Rr3Ip+w6NvuJDGb/cryNkZf09GjZeb6P7lX1Umir6XRURTbfXkvpiR
uKsv5EvbrwLxRKmRGrLfBGmb2PuQl0dC+OnzRGPyXgpYJZwfAuESjuRLrBN8FFyaI0/Jll2Jt9G9
yGkyX3OVRyjanyKcvJJtrg5/UWVk3SaHso7Y2fSK4ihLBlpordhEluKtMt02Ryv0PqN6JRT+49R+
5uwhqEhOUhpeCKlIahnwfTg4LaG5uqZu3L/JyqsUE0NbluMEdGTo3RakP7dN0Hk2Sl2i1IvIoasq
fuOe5UQ0IvEv+DEk3ttkdPwxO7dWLdKsia1I19ztkn5Jb3tpM26cs8DnN7pM3RIw15UOSmvchpab
7XhkZRkr25tkIwfZeRNyVvOR6Mpdsmd0018j26ix4IvSl/g/OlUqobjO2hwhKtLz/tlU+082SdVE
qLJyk/qI+Tk5spFcHIoyxQ14FHijtyv37fiR7j29FOLqSNs8MU/qK/4O0UvYSdxZiXRKuChjdWir
MG+Ik1k8o3J2ja7s4ZSbHf0nA1FlnwVk3RZ3Jnk5wNptnDRlujjcj6WjKkbo8FbGfRRkSSbR5Vll
fUfQYTN/8xtpncXHkrYZizfwymrMvHS9Pk/hts+lmetxZTWClpm6eDbyKSKaMO0cFG6Lqytt/YzH
aXLLOxOUUVtZclTKjk4Pz+0WUZo+R7JZO1WjOEXGRhmWjMitOVmT8yz8m0eS55NqbSLlcjtbSL/a
JZ+S3KJhoeyUUytGdfKPrZepKyo6tH5mra6Xpya+xGWtN17dNR+3S0jJem2mZnKi23ZS1mi3K37l
eo6+5abv3P4zLnqOX6nbJxMyvr2ycfsU9eTRyV6kkvhlt2zatWSX3LUnfuY1pf5O7WnX36dknE7t
WUl/trtL4NnsWbK6ZODg8lm6r6JmEZ/fbTg463XTHBbiXRtFg4NvkTaOOl0YQlRlHB9JwcZOPwqk
XtNu0zE+k+k4PpMFH0j7RYPpOB9MdEjg+k9Ohdtje2ho+k+kuunHTaKqG6Q1+BCdDx+NRE6Q5Kun
dRij6ROVIqhySGo6somNZ2Z1mJSbkhbqTO1Dx1iqE3yUqFSwLcYHXI7VJM5/4O2mOm4mNaf+T+PP
/IrnJilqrHyVEdIooihTmjtwOpomrK1D7koQWbojqa+BpD7R/wC7H1U6+Tg1LMIlNx56Jn0nCTLq
x7YiUlRLBsl4OPA3X77VtXguhpDE2heB1yQdcoaoZqP2ZldOMCx0hXmQsDVUNjpDwZ6UuCzCODg2
0K0VWDjg4vA04nBwenVDdFsW2i/NEB0h9jo27as7on0l0dq4Z3omOTXDFsG/JF/I3E7lRuO1odDd
G6PJFyRMl9+qoUiK9ikuTc4n0Dx+BPyZ9h/ccfF9HfBlWSfsj02+2zUT4opI3SVn04N9Z8CpWKUl
z4McGIn04La4PT0dzkerrPt9juJQhKRHbe0V810XouiCm7kS96KWRTmsEVjA/hEtKS7CSayXSZtU
RSayRRWhLbgzqsUJtybI6ku0XwQjLix0sRWEPTnfpmqmvBJLC/3fpP8A8SRGSdUyPnpJI0/uMlRF
+6Oej+xax3Cv+gl++1BfYZtOBoSm8MXwWir6NjVm75P0JZFfjo6J+1mTDHR5MmxMTaMmGhMx0xwZ
MC6Q6NxIbj9BJ+DLMF0VFdODdRtRMcoshvfPRfcd8FRrpcXi8ojgbGRNQfWMmuRKv1LRGzCqkPRo
njP4FYl8dGhdZ/Y4J/Zjk/DIRXCQ5PlEDuIkGLUpNDpUlk9OC5Fra3BjFIcYPt9ykRlJd7HFPuPU
n5L1XSFOH0sl7C1NRdpjtS8G2LtDIbeSb+B/s8uR0ljk+WrNurV9FOMU4M9Sr9kb3wiMvcX3GRUO
TV+xNfH+7smj/aNo2+bI+PJyNkV7MZLBFP2HLwiLJG35IX/RRL99NCXx07+JeTtYxVimQ3cjJWO+
jsr+UwMg1zZ+iJEr5sdE93uUWbYcicvc/QZ2ypHfkjDNm4aME7eBWckWi2NIgx1yPb2n8RsXqO+j
ZUYsju4ESJFELGK/cajydzb+4/cvwJ/SxpHuI1B9dNlIQiX2JM1H8FdcFv2H1nH26NG9ZkTb9jsl
USL1Hk2QdRIpsitNkYy8cihDPg04El7oyjbFYRsvtLq2KD9yb9kadyxZH4ZjhGnBkIeFyeEkPT05
CbfI3HyPVk/sTz3Mf7TLgkl/NyX8UbvqPpao04Pkq8+xtRpr2RDUfFj2vEiWu5c+DUTl3NGpqeP9
3x05OqwjLy0ZEPTbwuldGYNT7Gnkk0bpeWcjp4/fNvgQ7kkOiEHmInfIlasS4GOheBj25FL5K3IZ
9uDLGON1bORsWTk3Mw8m1Mz0agbm1aKsvcfUmOR2s2ydF2NRY3ISeBrkpnK6Kng+pUW1ZccH1Fs5
OclWNJ2JcH1mDanyeBxjIbbK1HXycolCL5G+q05Fpp/qVaFJPyZmhtSTZsj/AMG9xycdO7ESt6oa
jLBvcu6x5V/cm3LyKpJfYW6SN2m7RP5Gzt1GXN2xXLtF3x/UcYyX6EtTVnmzslwP1pf5Iz3r9DOo
kfxEOEJo9aT7LJRU42zd4FGbx8ly1I2PZOJJ7jbCWBstcijrO/udupDcRz+XeSozrHAmpPb7ii5r
gq1tO6cWS9OUdx6jf5bO6UUOnaOyVz5K1n/k7ZLcNf8A6v8A+/8AeCNtWvc9RfUU1SN6fcUYTZlH
DZ5+x3YK0+DuRUP8GbX79ODpnwd6M9Ox4N3kw7R3I7ioSwV4LkdjoouaN0XtZiZkvyds8HJ3Wn7n
a7PJl4N257j61R3z6djpn1YO+7O2To5Z32dt38H1No77LTo7JtozqUcts7ZOvkps7m2dk5L4P4kk
d73HZaMykfU6Lt37mNVmdZmZNnZOR/Emd3JjUki5Nv79MHbqSo7psz+Dt1Zx+zN2+RUpyZ2zlH9T
+NOvuRc25R82JOSR/EifxIj9OVnbNozqzf6nLRmcn+pyZk2Km0LcpP5GrH7fg5a+xzf3MP8AB9TO
X0pF5o46dql9ypfi46YVlyTRwfHTHS/TODg4OOlRRckcfg7FZbi/8H0v/BckyoQb+xbi0Z/3HgVr
Iopdpe0UaFg4PpG9p9OS9pmI6Q7V5HtX7+OmXt6Oul0ZRbWD6R4HCuDgdIUa5YnRwNibR9JSR9J4
swjjpwYOOq9jKV+wo0cFGImYmUOkKNG6WBySwJmTCKSE3go4M0Vdvo6RwcCVCcjBwWzCODve37i4
f2JSS4GvwZFVcEkun0mV04ODg+lmUcHBwZRTMeEYRhWfSZiV1wrPporbk4PpPoMxEhXHLJ7UKlhi
U13se1eTgxE4MrpaiRhWWyOtqL7I2vbfsNwWfYaSMowmJSWBRilS/mKxJe6HNLD4GvYSSFKccCnq
Rz4RscoqXsPbHPkagjKMRY1q9sq5LnqWOelgiqt2YXf7ktJS3S8olOKwkOPn/cUJvyMU/wCUjRv8
lDvwztJKRZTMF+6H/Q2RfNjwP96iyuicke1GxcMjaPgZPU8MTXt0g1lLktDizaubP0PgkjtJOXBY
1AU5cHd0yumFgWOvaZfaZMIilw2ZG3gSiMX3HtY36kjvdiS9i92Bv2HFClbihbh+UZMUW0PaPcOX
kejP9L6N10vd5NQl+CLi+R/CNvyKU8FDcUNV1yJtUNwySi/DFeDA5UPKs2+6K+Ramp5P6fuPKHWO
u+WcFxQ96whNcFv/AIK9MlOPB6c8EWuCTbIPt3fPS5NJ0bv5F5MaaP4aN8eGZXaLTrjyabrFkF7I
U92LEOLredtFPL9zV9M2wdNmrGbs+xNRXkWrqojBxV3hCFrbpbd3Aj05VvbO2khpx4WZFaE6k348
CT1JTVm3yyOjF2/JNeaNzd7smt9if+3310/hkj4I30nRL7mSezkW73MlxESNEmP97DqlzQq9h0Rc
uLyRa46SoVeOSQ4o2yfdYhieo8PAvsfoTafk7iovpfSo+5fwPad2GW8Cz0iy2OC5QukPuJkzTz0a
Z9RaNyPsemuSX2NgpNDjFm7zRk+o7SVlRJnZ9VkfVPkdH6mr9iX4KvCZP+0nZjxEacsEl8Eq6JM3
yK6duE2R+xqRbwSHFOsmn9hL5NL7H5cqipDXpuR3Ra6v+0pkq8kmaf2I5pE1cRSi/Jp2f+pHvaRp
f2olFW1ZJNUbpvbH3K32LbwiEG9sz/8AaaWmpXOxP3IaX/kIj6b5kRU+NuSez3ZquTyzcasvkr3Z
62svI3J00sIg7/LTI/Yjp/8AkI0tl85Fu4q6JrTxbaG9R22z1qt+Bvy0etN8yJv2EqdRNZ/Bqf7e
f4Ixv+YYoVhsizb5Gya8bjtJN8DXyOh7n5P0JR+SC9iX77TK6bocmeelohEYycvDP0JM05+IljIx
+SP9ozU3FIlISZZtgW0UcFsuEqZCO7HwZ6UhzFZgUirJRWRX4Ght+5hHBljp8j1PA79j7Cfwciz4
K05NfYuTYotle42OKZ6rQ6qxxjI9+mpfkf4Lflkl8EnZ+h6lYJSk6xgdHArXkUfgi74LIEfsSl5Z
KF5N3iyK9kKf/kRXlGfLG8WS2nDOBRfldVop9zeTTXwfoNJsj8M04iv+kgvCZCuUhyn/AJNSG9Ub
OUOU0OpJJC1Ebc8UR1/CIxbysIWo420S7u4X7VqfpZWpL/BLbK4jgvpLX0s/oiR/Z19KHX8h2y7L
FIUJPu4R6m25D7u7gX7Vq+WfmO80OnjwYxtYqfklC+FRFr7iz3+SWpVf+TPQ0stjnJd3+4lJS7fY
j3K/kg74ZiSIvdgzMvejM0ckql5PqHb8jzZKUnTvyUmc4/faepLhH8RDaakNrApQlQoajSaP6kLb
PA8pjojb7itw6H6kqdm1THVM3z+kxqIeUz1I8WLdOi4zixZO6dF3Eq0PdLBfqIqM4yHRc+DbuRcW
d0qO3UQ1GVnc+xmJ0xpSG9V0jt1EYnFCcXgy6O3VLjKxb3TPropS3HqSKUiypZgZZUNQ3WJaqf3N
unqMtvBX0OhqMzPIpNbl7HmMiotlv8CjKDteUbc/Y36Tp+4o6nK8n8xs021fubp5s8HCMGypbja9
wpJOhIcc/oc0vY4srbKy4xZWot/2K9KSNsdys36uWcI+k3wPTjutFSjM9SnRShL/AAfR9zcKaybd
kilHb9zc+TFyK2NC1b48FenbNuxn5jx7fg3QZt2/qXqPt9jbFYRunKl7C04q0jdLtNqe5G3hHqwf
eP1HV+3XdDlG2Ju1ZXmz09P6S9WV+TbAb1XZs0pKvkvWl+nS9KRt4Ru1Jbn+54/Fx+Lg468f7L7J
OK+CpFqzu5Lt0YnI+qR9UmeTuyYwXJ2ikZt/cz++oxJmWzOfwJJtfY5ZkoxZlFGGy7ZkxZeTjr7n
ByzFlM460jye/SlaLzZVF7elGIl7Slg+lnDRiJwcM8nB9JwcF7SuH0qi9pR2qz6a6Ujc0XtGv3Kk
uUJbd5e1JHB3de/DMyX3HsyX+Hc42YVFaUsL3MbTwfmUN+f3SL210+kljj9+oxi2JyRJfukqE9TC
9x7KZx+FduBuLUmkemuROWI+5KcKdEoe3XgzHBW5MbjEfWMpY8nu/scm+FM3avar5Kg1fyWolf7I
XkVkI4tssjUcWLHg2FmKGqHtyydo4JqVJ+xgbS/faMXwWMwhFyR7G5ryZHhG3wiI+CEV/MxNopDF
KS6bcFtGxcl0ZNqplpDpHBwVQm0JbbdCikJtHpo4N1G2h0iPsbmrJzrgla8l1hDVm2LF25PSrJwP
chRXk3e5t25GvguiMfkUpJMkmlVH6idqRwPBuatC2rK8GpfhEv3UfuRxmiWCki2i8lNFtFqJtos4
ZaQo15IKvBLAlFGUzgeOu2Ks3SRsNzRdGINl7Wbaz0x7D+5FJd7G6z5Nop06PpZwyuqUUd0cl7Sk
hJRZTgzYo+aN0l3+B6b+rlHp+4m1dl7cH0m6rQ8HqVcR7vB2Ky5rKNk1wyoqoRRLRr7EnXcN7cEd
NR5FOUeSMUrjZs01nyye3+g/N+kjHSrZ5o1q4Nb79EoryZit4oaar3I6EY3HgUZ8NEpQji/A6jwO
dYJKXEUbf2SLTaL/AGlt4FCXlj2rtirJ6Lh+Xwau5d6WGammuI/7IcvKZg3P+VkU+WXWemrkS+B/
BL+7px0c4/UiL1PqskS/e6IxiQptHsNeOCKN0Smz1H5PmhpkX4ixDyemL7G5DjYjd02ps3z5Gjc/
JkxEToWOkZCN3WDusisk6sqiRO/c5RwmKUUJC1PJI2p0RcsiS68ZPUS4NjQ38DYv6BeRyoZ+pqfY
l+6ip8ClEv4N81fkuaSRuStEJRjaLopqxSku0U6v7ihtSbJdvdRHcsSIyiL/AMkerSfsbtZ0jdHP
3O2kuq3K8k40RlKNpseFRJxVVgtukd1OPuboq8m6KrAmyUJxvJp60OGSlNXuQntqO42xwl46akpV
fuOMfHSP3IzS7peeu2PnHSUY8x5FrpcMbUdrgx68+6vYbjCl7kZ8G6bpF4lEWzETjyjSrFmzjdQp
Km6Nsspj/wDLuJXwLb7Waj9kT0JfUsG/08o+X4PWiu6T6V7mpP2dI7puS9jVNZi7XtOE51l+xD9l
0c2Q+yNz+vcRPQl9EmJygpXknq4io8DfGjf/APsKUo8H9MFzL3Fp6edOEqsmRlGtz9jW/tNb/ZGr
9z9CZF+BGDVE/gaRq/ctDjeV0mhX7jJ/vdHoyG/CFtp4GZ8CdUxoZ6RfmhoglxJn2JMWp5IfJRKx
NC06Pub2jA+aIXzR2s8yG9VV9xVNCaIx6bPAn0ihEj9Rknpl0fmLycdNn8pn2G4cohH3YnLno/sd
3SZX/iSEkuWKX/A43THRXyav9o/3UGukft0jXsZMqzcKRFkTTfgm/gS+SH3NMihRSvtOxy00d8t3
Vf3dZfY1X8icRwlD4N0hv46Z8ywRXyKMfYSnySl7D09LRqj83BJy5fTT+5on5ENzHLbtRH1n38kv
sftIzVHpx5bJSmiKFt5ohovF4NJvkjtV5RpJm9c0R09d0mOcZpy8Dlqy80TS8ktSb/LRqW8sn+0f
yXY1X6l+PBs05cCjqZgyTXhFTtx9hNxaNVIdLG4WKn5fsP8AZ/2Z/mnq60t0nyzTlF2qRHZKocic
nSiiM9PMYsjjdUaJR8IUJKlY39jbpy22iCk6uVk9j3blholLUb9JM1nOSVrFmtqR+lv/AGRKEnW5
nNkfl9FG+ejl7iRbJdNZWLJNCJK7H+90H8jGULTm+33LWSVCTGNin7nI3Ym/5R37EhR8EMjHnkSv
wepaErT6ZZdo2KsdL3RsaVCXsU3TouyrPUsxI22XJopSQ14F4Gm0ZkjlF7kfUjBvbMSNyknYnaPq
4JZ4PqXB9QtOLN08Wy7VEvc3T55KTQ+7BGN5E32k1vttGPwXR9JwcHBwRU8ZFDgrnB6e7uRkrwj0
93Pjpt4oW0iWySjLPky8EYWlRXOORablXhl8oeEhw0k39jg4wKfgTnPbI/imyEuTbuV8jjuTGoux
J+5HTtKyUd6ZjORaU3hm/wBQjKJHuyzf22OEVufB6ko1ZwxSrgWjr9qMyi/7h5jXshNKoe/uTlGW
ao1t8qT8ihCeasqeE2X6lHp8kY+rGI9Naqb9y14Foar2pHMZfddJQ/QTg6KnqNo3QdMUNeXCN3qq
T9hRUvylydskqiKMP4PuZ1FF7fPuflfTfJ+bSdYLeui41NXyLbOOmf8AyEyM9KROGg8vijfqSc5v
yy0bNWXZ8m710l7Ho/s2Y/At7UNTzZ6X7JLdT8FftEkp/Jf7O9zvk9PXaTNmjLcuC4uiOl+1S7ST
9a2lwOMXWkvbz/sm1hihrePPuRrNM25FK+HZsbyWzJ/+wbTtFJkp57ikx6klus2xtGX++jNcoqUH
Z9Mkzd02/VAxaEnArIyvTtG3ay80OSjafKK9NnsKa8Cj6eTho3G3a2fw2eUfS3R/CK2tG9ZK2H07
Tk3x5PowcUVyfwTKcTfGVFbbR3KkboGYn8M4akVtszA7k6EoO0fSjMWj8ttn0FbaN3EjFMp0br7j
bF2cUd1GJX8FzfS4SqXuUnaO/Bnnr3tJrwxfSjhH8p/KfyGNrZ2OmvY7dU/M1LN8JUylqlS1jfff
7lR1Tfvl9yCnO17EIrkqEqfwO9RstYZjXZ36u5G6MnFs7f2hndrNl6s9s/kzqQcj+JFD260StLUZ
cZzO+Um/kpa8j+NOSM9O3Xmv1Klqzf6lsuLor1p/5L5Z26so/qV/1E/8kJaknJfJFT1Yqkfx4o/j
RPyHf2O3Um/1PzNSb+L6ZnJ/qYk0XKTk/npjWlXsW22zGpJL4Z3TlL7siRnJ5ZuirZLPePUm+3wv
wYbR/NIzgxf2Powdzf26Yk19jMpdO3eZcjLbL6/Q2fS0ZjSKMQf+DuTX+0KN2TjJdWVWC6OD6TCP
pPpNpe02F0O/3yQm0fSZ6YRxRtouh4Nom45PpGXRwM4LaMIyhYLSMo4/EkkW4lJGYnBwbdpe0wiq
Fiz6R4M0ZKSL24Pk+kyq68dcCk4ncjtODjooixkckkx0utqTj9ivXnV+4pW/vY61Zr9T+NP/ACfx
9T/J/Gn/AJMtt/jpjaS4LhyVFHcu0tr8fk+qSP5zlkY+CPF0VEiqwPCepRSXTg+l/hwj6WU0cHlF
1gjFR8ilP6peCkuWcH0tHDODjHTjphHFMT9SUYIUbv5HJcpcDVH09OBLa2bNinKssvTjTaI6msv/
AO4/UjCA/Rldvr2wbEpJlOMZPy2YjFP3RJ7Tg+RRawRuClNr/AtOXp734odQUX/9jlNUkxR9OGPL
JOEUpVwh2qX+yV+Kq4FgSj7ngVROBadZL2oraVRW1G+sDdEpNdotvsNpD/e6C/8AIWOEPHTg7kPg
nNrzgzEZprwJ1hDEl5ZdG1oZF0U0JFxNmzHuJswxRUce6LljBsifSfTQlQpNCSwiHydoo1gVouhR
LFgqHJM1PuSaHtiL1VREil9BkeSMdN7kyMp8m1F0fSU1wVBVQ0uDczY1Ux0N0XF00VqStWT/ALSX
XJv8Mr2NvubpLBwi9o00cIbS/U7hPbR9JdUb/ca9kKPuKc1X36OlQ+iN8zj/AAOclg4VCukYr/A3
WB+yNnwR3e5GdZLHJLI5PEPJQ9tGVXVQQvV+v46b19KFhfc7ufg/LyW+bJSuqPUccjurQt1UUk0J
NKm+Sb0/A9J8J0TenWEenFcCc8SYtsbjZpJeckVouoo03L6qHupOjsSdG7XXzRDT0/cSS7xpeTQ9
iEfZF73s9kfS/wBSmRpYFvivU/8Ao1fTNuj9THHVd0afqfY/Lrcxy1o9t+RamnjPDIyWU0R/aN3a
umDTjoS2x8kN7uQ8fV/s/Vv2I/YmOF+RNdGKy0aiZbMOyY2ah+hL97ov/wAj/wBUSFHyxSopDEMa
FN82L7Dpi3Po2VL6RF+SlwhWLix0eXk3SNsRajzZ9JzQ/gxjpF+RWLi+qkIlToe6V5JGpeD6kYcW
XESErW4dFeRTn/k2/BuiriZ5KfBPo1F2xySLh2uyMZxpkpMe0f3J/wBpL8EdPlD+xTIr2QtHb2lP
yOfC6aifsPT/AJUSfsSb8Cfmhaf8qZqfZm1+5/ahRf8ADZ9Za46L7i+4rRtNKvL6PTlwJWVF0m+C
L+ByXO4jpudw4ofwbXJ7b49yFLky0vuZ1Y/5J7c+OtvpnUiv1JxU1Js3Gm4OrZH7GnGEtq3EPlIe
npy7bEm/IyenqdqXAoabs1fsav3NX7Gp6jip35L5Xih+rKKfizSriiUZc0aTXFEZabymjRk/qmaj
eXFG/XfZFl/9RH9RTT3Q90Lc83gRH9mWld+TbJWmvJHThG4vkja76/wejoy3Tl7E5SdyeSMp8E3H
gTTp5O93tQrYtJtx0149yEFwkL9ljp3EXyiip+URkh/7P1F7lfBKT4N4k3XSPsWbcjl7oVexLSfg
v3Gh7vPSX73R/uE/eKJCmvBGK7WMbNW+PBj2GRr6S+kGudwv7SQyF8jFfuYIZYkzczbBG52RT5MF
q0blP/IobdxclRFdE7dEbOTt4O42ryS+5JD9mYsft0s3+BX4RGPyKiVM035oW0VkmSRJvizUbP8A
xst1gcYvpfhs1P7R/guvJXwWxP4N9Y6YZz2exP7FDQ17m28pG7/yJCl7ja8ovbaE3FWNdVDz10dN
crp2T2ZO/VckKQl7H6ifs7LXDQ9Tlij7G3Tk4/Yb1Ju68s7eOnBn3JKPlcjnPUdfctO8DS8GkjTf
wQf/AJGnJO+0cn9QtvCGSlua2ewt8rz5JRX8xPXl5Nb7Fp0kQjqS7o+4nCfapWR0ZOpLyRlI7u2E
RvTzpxZBbtkYeR1P1E/JfDYoepLk04P7mlqPwRcc4P8AqLVG6TpIf7RaTY9HRd6rHqar3TlyelP6
Xg5Tj4ZjC8s/6XS/lwRXF8scI6u+SxQv2nwRlB2qP+pscpYUUS/ZpS7l5Iy1PBbxCPgfp400/wDP
+z96Pq8F3QvsXF8ENzFM2jmzFFWSdiyRS4E72v2HFfvtN+0iGfA3Lg7DfDk2yxJIabX6G5cH6D28
m582bR1yZa/USbXBIX9LZHKHkWohd6FN1/k2mZGaPpVlLBbkmZhFlR4IbuCnKLNyrB9SL7fvZtVF
S+ls3WmxqP8AwXrOkKpxY6kv1Z/LRe5FxlE7RbpUy98WOMaIaj4KjNDzgUZfT7l+orK3oTTwZ1UY
1Im2Ev8ABbklLyVGV/YtkXqfT5Ft1khxhONP2G/wR3y2aiMakb9xamnK2hb9Tay1rxsa0537Ufny
2s7ddN+xt9XJuXv0cVKpGOBb+2a8mNVbj1NJ9yEtWW1/JjUHDRnvPU1H9XTwfVhHMWOmlIepq/5M
8j25b6XqL/Bxb9xuN/ApxdMUdV5HHQs3a0rRnn5GtPk3zlUeaZweDfHn4FDVz8H0Djp2kzZKxSjl
L3Nmbqkj1H2+xt1DZpQkm/JPU1Fucj+DklthtT8ielyRjLRcqN04bCdyqTJahfS4sUZwlIah2RY4
7d1lRvTjVWbXbQkoUqqxT5o2y09z+xsWnSO7dJex/B/4NkI0j0kvmx6k3uk+iaPT2uZ6cYOHyep9
U/PyelCGz5N6m5O7PT9P9Rp3KzOh/wAG1XBe5vg3fkUdrlQ4yb04Mr/aH5Lo/MPy5Y9j8wqGUctH
uunsdztG5YkZdoviRV2Z/fIXpzZmeDu6XGTizunaOzU2n12dx2y2nbqsuds+SoajLcjJUZyMydHc
dspJfB/Ekd0myoykX6kj+JKvYzJmNSX+T+LIzK+i2Skdzb+52No+uRlt9O2TR3f5KO2c/wDJmUja
22WrPqkZs8n1SLuTOC6ZwVReUi8lZZZmy6Pk463n9Dlsp/gyY/BgycdIz3rd7D2O2xyaGZOOvBGS
8CU9C69j+Az+A6MaWxFl+elpG7azbyzdWPsfQWkV+D6ce59Iloq18mEj6SUJaT+5x3F7ShRhGy3E
uhp/iUtXgSU02epCL4sqb2w9vx4WTdJYPpK/CqTLkjfXaeDFErXH4E44G2rodx/AoxRGc3yd2Cjd
wi6Gn/syjc0WJ0NpEW0cF0cFH0lVg3baIQ6NpDv96kabrwPdH/A9vTjBZsXgVpH0igvLFg+kbSE2
cIdHxZmikkXRWLPpMnMS4xHSODjosCc1kpeRORttGEcYPkwjg3aiJOKqkTsrYvuV2m2LTv2N0kKO
E+m6RlKJaNzWD6Ul7nbktmXE2wpku2qG6wdqHgT1PpFGE7JLasIf7rtVnBbQnw0dvsSdcEki0jg7
kdsTgyjCK2l0Z65NPS25JeyQor3NsVUYoWgl3e5NOKtIkkusWl2ihCK+9HbFJoWnOPPHSUY328m+
qfkcWvPT0or6nyab2/mNf4K1MyG8VVlR5b69qsWDKGn4Iy22huv5KEkKWw+nBmJVHbC0dywerPhZ
N0u3Tj4Ruj3Q+S9PNjbRsjG2XONEXJYI6OnheZD81IjCctriR0dHT3Nvkhq1Vkkun04IJox2wiss
nDT8OiU4LPsPGDalbFKUGkxajSfsjjdJ8FThsiz1Z+Fk3y7YriJuStex6sOKv/ZkYmEel/KKHsJy
HXghBe/TcxJiN9ZJr4N3k9OXMS6JfvY/c0/iJLI7FgTqhxSyTl7nb4Q9xBrwxe40xQXuLHg+OnHm
zciKZgi7xZkaiJu0d78FLgtxHSFtQpNdNNmCMhLp2YFu5E/BtTJ/Y1PufdDbZGWSIpvqsiiUzbY/
kk0PTTPU1OSSfLHb7GzA2kND+5L+0f7lRXLFqaiz7HcoQ+46r9DsF9iY/wCm6FGME68s+iI9RIwi
tiN6WGduUjGnErakx/gj9zV/tZ/7Gp/az/2J/Zj6JC2+Rei6kQU8z8n7PNcvo5Yj8npwdn6kfsaf
tZD7C+44xyjdPnr6f8zwfw1gagk65wb155PTmu68MnHxRDGCE1FPwRjJKN8YKcVxgWnHmzbtTnIl
Ue9Lg1IezoWmycF7kJz4sTSTi/Yc0t0iP7PS3yYoQVYz0nHysjScueBakl285E5OoR4JLT+jdz7k
bieFSyxwh9McE4vyXFVeTUkTiorcsNHq1b9ipJW8JGlLi0J66X3Y/Tw/BOD8YI6c+Bwgfox/7LgM
dnZ55IWTohfv0oi/BGRs8k/t0mL7D/ex+5p/2khX7l4sagZNn8yG/gdMUZ8yE/YlRGTzG8irhoY5
CaGiKTrJbyRhWWyxYwWxwgK1mztdEo6nHwZwhLci0xdI6dCfRpiZXwS+5IlJZs+mRscRYKI6W0T6
LApm5MpwbLcNoxTfA2lSQ42e4m29nySTaTJDH/aP9zp/cgPa2vsbYpz+4/VVdJkn8jlLhG1ZYopV
FiSQ9ruhk0/YlKPNkoS1KY64/BD7mp/axfc1P7WJ/JqfZj6R+5p/c3av+COtDEZH7N0cYatR9i5y
tiImn7biD+C4q8nqSuKRnrH7k/sa9n+ej+xFi+5oEPsb9u68HqQ7JIlKVSnROfF5FLTVslLVVNij
5oe/zwLZ4R6zvt8CjLS3NYHPZsaNSdbm8G+ar4IQgqVC/Z4twh7idYPGOZEv2T9kl+vsKMncnZLb
9RJ6saisWajfknqV+XfJta7rNG72bjR+xpKE5RhfCNK+fkcVyhS0VckSlrLa2VfgX+yb6abZtTsc
hTaKY68kJL3Gj4Iy6Qp1uGiMfdm9nI2n+9X3NL+0kZIwm+0i07LolIX2GyP/AI9GbPkivZEiiKGQ
k/LKshL2ZktFRNzRt4MFtf5HimKMdWSf3Em7wRKFMy+BwTz0ybIvyW/ckiytpuLky0eoW3hGBFWj
ZETdfqcr9CUYshbHBSHJilOv1Kj7eBpMoUpe5OT9h/g4wfSz6WfQfSRltNrLlwPuW4pNW+KO7E6J
7iauslXyOcqsjU0sl7h5yzapJjXEn4JxkSpeSkmz6WfQzMWRkyTlxRfCE9yyep/MTW5W0ScIuUS9
ouxkYSe1r3KTusIgnKiHmMDd4JviPSOpOucl3g9SONrsUNR0KUkpNElaWMI/Ki5QifQfSablGhjl
iC8npab+BTl4ybrVE5prb4EpSSZpRu9pv3q1C6MFaR+cRin28Cbcc+GW2vhH5j/KT8ie5UuEODqK
ukyWoqz5Nv8AJYlBpSZqRclfPJzjyLU9RYhZ25SJN8qI/wBn/Zn9/gvl+WKcWJTklNLySnugks4F
+zwl+QnljlGS20n9x6NL0zduTajaZ/0spVKPkU57ZP7lvUjUf5Ux6mi2tK8ltxvzFjm5xlXEUzfO
T9L+WP8Asy06Nmq6KtMSciShIitTUz8l7q+SvVRe9Nipqj6iGpeEVvVkJP6UUpq/kw8fv4RnKh7Z
5OelajuB2yO593uV6g0pWhy1DbvMPBHUllCqW07Z8iaYk8Mre7N27gS1bOWNQlgSkZcrGozYpp7l
7HcjtbR9VoU6sS2uJi7KknL5PoZUG0b06KnGX3Go2vuKb7hL02vsV3FwuLKnFsr0WVUkJSjuP4Uj
ti0XzZnTdjqMj1ayU9IqEWjuKjG0fSzIobbSKzFdFOPJXp5P4br7m6XX4QltOKOPwflG3aexvbtm
2OUbJJUepdSKVSo4R+axLTdpe4nhHKMNMqfnyXLkUrjJ+x3bUfyDravk2/s8uCnNG7UlbK09RUit
8SK15YZFflv5P5DHpj9OSX2Y3qOzbDUqI/zeSvWPzZ7un5M9p/FL1dTdZem6ZS1Gfn6jfwRtwv5P
q0znTFLTlG17dJ7dV7F4Lk7Z+VNwK9fBc57itLUcfg3SuTNvqtIy7f4K09ZxRWpqPUiXB7Wd+pKS
9i9NOLPzNR17GCoaziipftEmi7ybf+olRd5KhqOP2Mu+vZqOJUteTXtZh0bXrz2+xdlevOvay4Tc
Wf8AyJf5PzNaUv16VDVlD7M/M1ZT+7/2M/3FF564RWS1Z9TM2zCZtaLrHS66Z/fKS8l7WcV04MI2
ixZwVQnR9PTCLcR4Ko4Hg+kvacFUfSfTn8NUJ7Tg4ModRKozE4Koqi3EcEuDMTguiqs8GEZRmKMR
RwUkbnEovbhn0jwYRfRIt0Wkh9b0puDP4v6n8T9T+KbVqm+Ws7or1h+o7/dKKLnHuNpclk3IdC2a
jiLfrS2/c3R1JL9Rr1Zy/U9/xY1pJH/yJ/5P/kTf6ndJy+/TP40hSmqgUvtwOUOPA0tSUPsz+LP/
ACfxp/5FHSuWeWL133MdZkSxhdcI3an0lJM3RVp+xRkx0j24IxrPuLSist0RnrrngagsjxwV/uKM
fcUpLwZr7D+49qydyM4LKoVGURaWLHjwR9rElTG0iv32m68D8MZSQnJFyKWEhXEwQSXLLcSuCXuR
bVlbaGSlz3GYlLybqFBRrJuLdG1RybqGjjpwJtYFGKz7ixyJ0Q09nLLrktoXhFo4N38xNP2JuXAk
lFmzYOx1RGPp2n5Qm1yNOjbFJm+qIpcs9TUXRKsCUVWMj0/I3XBT7ZGMjwKS5QtNxQ/lD60kbqMo
7Ub5ocPglIW1GV/k4KoxE4OOqSFqSVscX5JSXJLc7wbFyOSRTQvcVcGyrFKfL8H0oeKrqjc8L3Z4
HKMR71lGYdpiKNlUXRv28kscEYpcik13PJCLXkhpx9si04w/L9zbJWmS7fJ2wN+oqfsSe36eDfBX
Ik9RVJC1KyMtrtIxxz7CjFUjZtfpcDjJWhyXuJRj5ocpqpGxRwj04c+WQSXke9XWSUquvBOGqnXK
sm2sryakf9xaHnJL7HIo3g3PJJpVggvk/Q3mnD5Ivo+kIX2vI5D/AH2gS6KTWOjjFi1CvglkjfgR
LJs+RfBu4NorJMhG/PRSZj2HTYpzyUnTN/KstoajNWUKlXRfHRSkY6pCa5ocZeCT+CRt5FNqiSsy
8C4ZgkJtYEmbruKZS6RkMb82T+zE4OnYoP6uCTGojP8A1H17nle4tq2/Y+kukenGFfI2+EPTjFrJ
aXJTjuFqbavwKFcn2JYqjfQ+m9LcvY2+ntJT/pJpQof2HKXCFLwyUo82NSWVEl9yUpOpJm5ZwPdG
ooa3Z9i+kF4NKEeKsemtO1fJnUSHH55Jz/pQtSqL8i+5pfYa92Rk1bGzS1PkR/5bhHoy4bFUd/nJ
PU8o1dSQt/Bq7P6j/JFtYKitsUsv3NPQ0nhPPSC/m3dHov6WYSdZySn/ADGpqTkvUfv0fvZa52jv
gezmjVNX7/7cf4tD+4/QsiUySIP5P/UaNLUrz0UG+Td8DZGRX7/RJdFGOHWejFp/yl/p0hs8s/Qk
blymQ3eRrx0aeaMEL4cj9CO2VLcdxZhGE9o1L36S9Js36ls2zsuIvuIjseLFu5OSo5O5UbfJqDX/
AIjLfuS24GrwblZBb5VZC+SvmjA4LgwtxGHpN26IT4sivA2jc8Im35wVEWpLklFMbL9yvgl9+q2Y
a8kfUz03cDv3JpeUepJMiiNIjF8kKGajfkS/UlXX9ScV5HqTJ2P7ml9iZOT9iaQ0sZ5NuZmVyeol
zwV0gzSa/pRLbG1Z6mpz7EkuDUiuWhQfJV5NqNNfBJ/JGL1WtP2N+5btv/JBPU/LTsi4vNZFK/y+
Rzk6UUepH6Fmy4/YkvPJPRm6ZUeRxk7nLkh+zQd+5ttJLln/AE/7PKvehSln5YpQd4PVlN7ESnN1
jB67+i+R15wNR5RKMNRxaI3qNr4I3zR+Y8MqLxLhk9Scrb4RKMppSZOb/md/7ihP2ZSf6DG/kwx5
EV8dIjiaX9xzyhJe56g4+Rv99p5yMeTfF5IwniRmkbvF8lWPJ9j9CWRQ92R3YOTArx8jyRlHhMSv
InIpMuyrO5lRl0uSY1py/QS92K+lJikxryU3hsUpZQ1puiMbE2ss+q/glgkuMjVil4T4Ftwy9o1w
/uQleLGPPROVY9yMW+EXHk2vlYOBqDI6k9sn7M2wwNsjv4ZGSnFkqdtr3Jde+O6LF3L9T64v9Taq
/wAj1H9DE3JceRxGt2yi5Tjf3Htoxwunc7fsbNLJcuWfSWZzGxXqxuvJ6dxf2P4ipijCXahL1It1
5E7tXk2ergkoaybY8KUJeWJS1YxMa6kejopOxSly+ilHlHp60qL/AOoVjjpTUierJY8dJJailqDl
f5XuZ1Iocd8XHwdk98vgbPrlXtfRRm+33MyyVpfQKLnT82L0X2pm3UnUvk9T9nfkUdeSscdDk/6j
Wlduxw03z5PnpFaksFtqyov8uyMG6aE9G9iYo60u5Dlp4t5FLV4s+p2btD6vcUP2l4H6X1j1dV3H
xH/cm+D/AENrjQ5JWZHsVouilpmdP9Tga2m7yjbsZb5NtGf39aeUbdhclXRShhlS4HsdFYaLkjfB
1IrDL1Is38MqMt33O7gyioTwvc28nefly2mJNo7zsn+hzZyi5umY1CnrWdzss7NTHsfmM7J0z+Id
8jJUJyL1JM+So6rP4jK1J2XptxMt0ZKhJx+x/Ekd8m0ZWTt1Jpexbts4MOjGtM7tSUi4Wju1Zf5M
uzEmvsd0nL79MH5c5/5MzkZ/B26ko/Zn8Wf+Tm+nZeT8xt/cw6P4s/8AJbnJ/qR1LTHLcNpjeuse
59R9R2vJcODlnuUrLy0WUkXTR5ZUl13Thuj7CXp3I3LQe0cfTHLTg0vczGVluJlq2iW17seCUqKL
jFnBTX4NsU2XJFMyV0qMbE9rPpHHafSNPx14ODCuQm1RkrpwVpIzH/g+j/guSNsI2ZiZX+330WMM
uiUWuGblEa2iwfSVtL2n0mEW10vbZx+/U6ModZ6JUcEYVyJuJ9JYnRxk4ODMR4NlCe0fafSZiYic
GTtQ3Q66cCSVm6Sr7l0bmhFqJVCbSHjplDrLR6fsLcrfThDnLCPB2oyqR/8A1MUN0YRwVPBlD2o4
E2sFxQ8CUsIjU4yGks0PFfg4PpZlFaj2+xF1ZKjB9Lo+k/Lm4sxqSZerbKP4f/B9GDMfwQ9T6fcU
4JSG2lZLV1I2lkvUUYRN2nUom6K5XWsi1NaFaYtPZUTdsx8HYuC5uo/JmKz5Hmo3VI7W5UvJNzO1
diZtUVS5Y9NU2ucCnHG7I0jcoOiEKy2LV1Y7m+Db237EnBVLySSg2kd0aO2Fl6sbo75RX2N+jmPy
jR1NvY3kVJUPZC1Zx0pG9rAtbVjj2EpOMPCHjufA1GN0K4lQi2Q9aNP5N2pqKvgktC+33JRq2b5R
T1Hk9Pet/sSnBcZaJR4/2+l7sjJ81Y0Pfy2YRwWhH0iss4SZtoYtKX2Gx/vtP7kkiVmBSkhrh/BC
XMS0PcbV7nHg2skQtZPgZKVcsx4MmBek6yd/IzbocCetybYluPTCFKSFFKkhGBbHgSlybqyXATmW
enFp/JJ/A2L7DcZyRFym2r6JxbqxJ89KgVJ3IjBK2d/LMCksJZEZWRtIWnJdvRtIfgXe6I/Yl9+q
QnOtzRwPghXuR6erq4ij6TtVC0+BWsD28m32Fux9jER6iWBrqukei+3SP26wXyR04qoxwOHp1p/1
E014NWPsbZcFyxGKKj+pP7DNSVZJVzZKabdyybc8eSLaI6W3hfUQddtka4o9W3yL7Eoyatvg7KHH
4zIcP2bV737Hqa05T+5siqNGPuzS/tHGascku33K8i1dVVEppRjRCS4aFLc1GGaRpX7Elq1b4OxJ
PiinU5UVo6i3+Eja9WUvg9SWJNENO7m2M9bc+5k/sP8A23X4If3Gn/Z0g17n6DPiyP2Hu5IbOLM+
xtfSRp/cf7/T+5IkRlPyVH2LlZl99i9iSTF6sse4q9h0W3ixbXaH7jp4FTtrkk37CUX5O8y6Zg4E
5DjAnLUO0nDUWF5ErwUmYHfTueS10e4pC+xIf9pvKcxaak9zE6KFGfLFIs3yN8eC+lOSNi6Rh7ks
ZopYybX3R9x7quhn2I/Yl1znJOvEcDudx9ilCRC/6iJEjRc5KJjUt+w5v6RLhdIqOLkaX2FBuomy
Mo59hv8ADHpEZE+OkfbcM9Fayep/SS+xr/c9WK3Mca2jk/JP7dNVeSiUEvJCeovqI6e+tT2K/WzT
0FLdqtkfsQ0f/IRFwd2+D8zCpOiSh5bJajTlqS5FGHHySlr/AFI0ZvlM0vsS0r7PY1FLxknqz+iy
32QXCIwi/wApSNH7Eof1YNJ+6I7H3Jn7P6nlZNV6X2RqT1HbbPVkt1IlqvnwetqfTeE/BL7ENDa+
TU/tY0v9vx+5pq/5em2S46UmOhL2Q1EUpIf2Ite5b9hkZezGmY/esh9xkhRk+wstEF4Q+iiR/tJD
Ip8jGSfufoQf/kL7FrmzPsXyVp8m6d2ZwOKHhl24SKhrMT1p7mYMiaXnpts2pnczZF/Bu8M2/Bwf
TkU9uDuwkYkJr3Ip+ClLIkijbeRqDyzdLUk19yvPz0jL2JyZXhSPaVDUclvLZGfB8JEutMdeUObp
/cpQ8CUfc00Rl7Cic4HJu5DjwRW7AlawRkvcgvZEs56cH0s+loiq8kEZ5o2WbWemhaad0qOD6WQc
li7NST9jd8kpX4Jy8yZOyWcvJQ35ZJM23W5nwb9tsrFoWrzk2KE7qj/qJckYt54QtbbckPNzY/2r
W5fCYlqyttks4ZKLpJYyYQ4Q4NLRjO3Zotex638x6cprdITtYjZKEJVpeRP2I6GrhIjOUd3lMbk1
uXgl+1a2F4Reo+PCG4vto3R4WWySXsKN52inEjGWNTgertqXuS0tNqepLBLUn9Uv9wbJywfUmTaa
aKU/BJOWCK3H1Ityj/kxJI+oxnIrkvpHtE5SXA46bo5/fem5JUfxYjUa/ToozlcS1OLJTnNR9jat
SDQ62ic8R9/YpakR1KMhPxYvzUYnFja8i3T2y8lPUijDvJs1XtR/HSNsNRSO+eTOomdurHaXGaaF
v1aZcNdDSdikxd21/JjVTZWo8F+oVp6lnqJn5ktsioalinJ2rFna0fUi9KeStRsxJ2NQngrWkZkb
dKbY5zzAy2mVpyYpx+kqaY1FtMxLBtmpI4lfuOOm3XyL1I7pf1D2WW2RnzQk9On8G2KkbuqlF0yt
TSlM7dGSY9rcYjm16htWjIxFr7mU9SJ/AmVDTnA9Xe3/AOJ3aLZ/DlRuWl2lLTY/y9tiiK42zgfa
KWmqopaP+CthLUT3X4K9EcPTa+R6us99f8F7dqODfHwPSR6y+o7YY9zEDbJUbnyJrlCUY3RtlGhy
l9Rtj3Iqjdqu/wAClps2Ujdqy/QWlDa4o3az4dmyNOItZzz7FIrg9TUdy8G2DVHKFrak8rwVqyxx
Rx0uDpmyMopDf7RPd9jZoyVD9ef6FaLx8jevP9B+jL9D/wDSNS/jpu03Uja9Sj1NR7pe/wDuHBic
qKTdo7m2dtn1tn8SR/EkZnI+uR3WXFyX2O52Yckd1/v8H1yRm39/wZO2y6syjFlmSki6Znr5Ko4Z
dG3aXlHk4OPwUol7aRSL2nBQu0+kopKzc1X2Fp0XtPpMRKMmOlJG5xHE2ot5OD6T6S9pVF0cFFtY
L2jX4EkW1bPpo+Tc1hIx+NIvbY8G6LpnpxmtvuX6uRx9RMb1ZW/xfkz2ivXwf/Jz7Hpeserr+fc+
lG6MaHj8ClKNQJPbSMo7nTMUN1RtawZr9RrihduBYRcUSVdVCKyb9ZbX8lwp/Ykmuu1cinq49rPB
uhFfoPHTgSihS1cP5Lhn7DVddq5FPVxfueDdBWvg27LRTasuEcfBTX+3MilR3ew4xI0vBLHaJui8
HJeC8FxQk0SI20XFD/fbmeCUUl0WDc0R045tm6SO2h0Rk0UMbecnyMcfYTeDBckZ/wAFxSO4q6O3
KGdvBwZQsYE5xTkNqNM3TVitV9jcuGLBlceR7MjdG+dNI27UkJEaXgp2UrR2nBbKoWpqr9Cqx7Gp
7C1WrM4RtwJRVYPQWm79xqiSf1XwYobSE/Yho+lTF7Mf4IOEdwt0akRZGvcWPBLBhclvptosuja1
yab90OcR4F7SZpSJfJSViwPtOPwQ0nxZJ+2RRmV4ihfs9dhOL4oa675/SuRQVacEZz7MjpriT6ai
nHbGPApPlGxfS5CI6f8ALZCMV3NZYtLT96sk5S4iVD7irjk//qerNJ7T1H+g5VTRBwVWxySPThHg
i9ReaKXCWCOlX5RJeKFHwJRVinqfT8knSecG/buk+Bau2r5RHZizftNqVZohvXmiVeFg9KX8ElHw
zsXd7kNFRvOWJTXbLI4rm/8AbiNMls8C1Ob5FfsWokkiF8lopsT+OmCZGv5mJv8ApMe/76S+Svgk
L2FKRsgxN+9iXuSzg9NeRfY3Lg2LnpuWKKs3vyNeyGiPkyJEtmBXbiXav2NkePInI2x2srCN7XSS
Gi2KKGOKKZuFo7KXubvgTZHOaL5LUSmvJwSpFy4RS46NvyyvJJ+wtzwKneD1Nuem+PgSbyN7fHSJ
p/Yl9+qiiLlFObX+DtYv1PzFcSMo+SL9zc0pXwW+BvbyKoWvYj20ypLAvuaX2Nj59hzSwR+5pCRG
SXfLz0p5RPbxf4Ifcn9mI1PsyH3J/Znz0X3ItKmKLdUKCzR+ze/Rueok/Y9HSX2+CBEj8sh9j9Tb
CbivZHffIowVWOMuTVivDojGfBq7eNxDU+Tcs+43CG3c+RaOnHe0xerJRZ+Xqwc+kYxyxa2sv/7m
6TSfiI9Z+WR38DUeLNPUqxTw4vlHbDZ5I6Ojmn/gXryUZlaWpB6nXUlJrdZCuCX9z/27pE9ol5I7
uk5EBjUSK+DPApIkQ/uP/Ql++lR+hIVtKXsztL5QlV7y/YkKa8EH/UNexaI2SiSPT8I3eaP1Itex
LYuBOXNG1G6socYWStPLH9iT05O/Yg5x7UbZam0fpT3Emy0flilPnoyVlFi/tN0Tt4IQnwyN+UN1
kUPJP7DUvcjCnbIyXDGl4O7ODA2z8rUoj6k24kpPwhqORas1SGm80OummvgmuuR/2k2/cRXyQF9h
+YWbXydrHOeZIUtu6xPixP8A8jS+xf8AKat8UfqaP2IvxZplaWj6j9x9m1He/wAEH8k/sxX7k/sR
lWLNR/DH0RH7kfSpyfuR1Z/UfstdJXKX+ekGiP2Iyf8AUack/CO1DnqK3Rei1dl68lfga0ZLfRL1
Zd0sn5f1Il6vMvBHSjmT8D3fVMUapUak39KOxP8AQhOVonNulRL9p1FascpNJ1hex6k3+XeEbLzg
Xo8o26jubyQ0IZlxgjGXL8EvFxo1ZlwiR1pePclqSdJC1IOyL05VBsipP6FljhGnm3/tLj90yELy
vB9yi/YenfA/kS9jHk7uSieTTtk6IyHbrA/b99JN89G8G6D4FCf1dIFP2GyMfciSKQjlFC1Hgqxt
MirzQ7PqP1NqY5SkkYaKN0mdkoswW/ORx3G1Oy5FXwJX2+4ndobjL9D04+XRHUmjDVG6R2tUxTaH
Uso5s3yHtY6FP2I5SSNi5kzY8MpmBSkk7NzVMenpvB6uplWbI9tHOBL3I6mGObkOn1tuk2LO7Bsq
j9BRTqnZCN1SP0FBYl5FKNFzHBPLLw/1GrWPkTtLJGO9f5NznH7j04SN+pJRazkh3xVL3OUbbpL3
Lbj+rJJpVXga/Z42rMnBbN8pJOy3rR/yerhq6Itziv1N/qQv7j09N238ktav06fAtPUHGGfAoymv
8m96saj4ZfrwJyhJSvwuic5xi4u8l/8AUQ/yS1NOac/CQtPVl/k3etAl6ctzY5tbc4Py9Rw+xerq
Ob+SO14PzZ1Ifp6m6Z637TPbG/J2Ti5jX7Q6g3/MV6sbfsSerqpP2ZjXgRhoutG8sjGLj6iHqaja
h/LDpFpuhPV1VCY/Q1N8mf8AUftk6fsz8ianN+xX7VLF+Tt1U5+yPzppTfuY1Y/ZHpaUtuj5aO6X
Zxkt66j8H/T/ALFP/wBhyb3N8v8A26nCVMqV2LU9jYj1W7RtVnHSk6PI8kYU8eUPkS2W15K3NL2/
ftqO6z+C7G9tdFOP1I2S07+R6qV2V6Z9DiRn5RXolbKLNu269hx9LpthHcvkr06LkmXplPSK9Not
ZP4aP4Zc1RUe5H0xO+uijDKRtnGkb4vLMUzuSR3G3Tl+h+YiyoyVfJiv0K1GflT/AE6fmM/KltO5
tlb2d7yfldpV2bp8+52zZ3TwdxWnqNIp6jY5aiyfly2nfqN9a0tVndNsuXP4Py9XavYt6zsp6zot
S7vcx+0SPzNaUv1OyTi/dH/yJGdebMN37levNL7m71Zlz1JS+526s4/qf/In/kuUnJ+7MNo/j6n+
TvnKf3Zak4v4P4+p/kzrSf3ZetPZMxq2zu1KHHS1N1+xenuhH4O/Wn/k5v7nbOUfsy4znX3F6tv3
sinPbXhn8RH8VDX7PNstsxJx+zPql97Prn/k56/xJV9zOen1y/yZbf4exSwXNX8melHLOyMjKbO+
P4e2Mi5RaMmOlnbBs+h/qfTRtq2fw5GYUV/tp9Ujd/wKNG6j06Lopqzg4OB1E4H04H++kvCOKHx1
uii6ssYvYyWkUhNo4NnkTlEwcGVXSksHcq6OkNfgui6GkjuRiJhClJHA8CilZmrNnuJyVFUYqxqs
I+m2YiZ6cYO1cndRSo4FOdK/BwNpEo+DiyqEhN07P/Il+74ZwcHqaipL3MLBwcH0s4ODET6a/Aj1
tVNfD8kmo8+xUqTR9PJJRVuzMaFAha+R15Z9NmNP/g7oY9/w4jZ9LOD6WfSzg+lnBddMIymLarib
dqk/LZt2pfKOOWcdIqsCW3dKsnp3D1PYl27WkbenYipLCNiiq8uR9KT8UcGYtHBHdHBb2/LkelBx
lL7EnGKjJI9TVWPcUNsF4SZKWlGn7Iaf+3Yyf+TK8EL4I0j1awZOPJ9Nse5FqJVIzTG17ChJeeS/
cb/falmPYkqMC7Rp4ZGMeLLXsbWqJVyQdFMZKbXkxwO3R7ioaZujkrTFLURbxRs0nbL1VRS5Lrno
8CtYFCK+5Musn5Qnqcm5oco+PBksw05dFqf0s2xcrIpSdX5E5e2Rpcv2Fsk1AXqZkNeTbpNo3a7O
7Js0d1+B6v7RK0+BQw2y0J7u2yiSklUjFDaRwRhvdGn9if3/AHV12lJIdRFhURjFUPcroUILliep
9TOC1wcIzTY9iGuq1GlIWn9KSJOS4IbfMjT/ALUSnLlnqLj4Oco2e41y7oWrqcHA2iSXC6r/APaR
httryUKmsvAuIlPJu0+BRf1k4P6U7Y5wXkkoK80b9dClpLBK1UhR0+WzUWo7p4NPf7nZ9TJS1VSv
yQ1I0sm6OU/Y9dvtu6JfY+RR2uvcppNrmRJ6SVWRhpS22Vqu5LBp+pSwJadXyOetGlfAtSElB80e
ktR+m8EdWaufiyOjalqTwaf2PUjqNRg+DTvLocEq7v8Absfez9CyEejivY/UyS2Ed3J3Oi1k/Q/U
0/sS/fap+hIycZoavArdUKiVEVP6WUsl+TntsWU7J2OMWKd918HwNRdETvaRUM/YlYpSQ4qrKbuK
OOEenOFfIqaZhowSRJeD81pHZwMdkoxGRSk6IP4JFIWpJZ8EoJinP6Rd9CccokxSawjGPYcY9xHW
1UUsM3rxwJa09rIxhLdJiJNEdNRcl7ly52jQjT+xP90oLsmuTsdDtNlwuLFLUdyF6Tqzdq92eWak
vZGzU1N0b4NT7Er9zS2OreSP2JofRLT1XGPsaUp5l7ihCe2PwaTkaf8AaiWj4RqHa67jSf8A4ob9
pHp8NYO2VfYa2ucaLlFx+Os35SG4OmS3t6lmnUNlPk0bzghC+32665L7mr6str3C9KSnFEnrSUYG
o9J3GyMpcGrJe5GSdcknP+UTT8XRVuMYijTmLTeh2+5P7CSWDGHXdL2P+m/ZsyFeWRlI3+7NNxdO
iEpc8Dcc1GyS3dkf5SOpOPf4Q4x79Z4o09fXu749jS/tRLR8yZpv3Q/fd/tfH4q8jr2NpGXsfUrL
GvkwO1yJDaFY/sV5sjfsT/faqMexJm11tMOxtIgl7n/qMr3NOL9x9JX0Ymj5osgS25Fft0ewd8G5
j+xwb26aNsZ2fnVtJUZKiKza3kqBJyNidkZrgjH2JPwShLJ9olc2y5I7EJFL7Fr2KT4Rcvce3FLA
9zbiy9vgqiE2sIlnNcDjEU5YkOEH/gtsjqEY+xOvf8PH4KFOrYl4KZjwKNkb4RFJUSS8ktZmo3i0
S+5DxtY5PiKJV1j9yEU8m6ZpwWMkV7I1n7s1LMfTdkI+yFnMmR43f1HdK4kt6uNDSr9Ou2X8yNg5
zzm6IuNfUaX2Fr3k3yYpRNTU9yUf1J/LHCfsbdPjg9GXnBX8r8m1YiuWR/ZdLhYsUbSXljjpz3NY
J60eeByfgU/PsOO78yWD/qJUnPyf9L+y/U8McpO5PyehPyK8rwz+mET0tP8AhxwKLajCPk/LnvvF
C1f5Zuhj19We77kpwhtlCPJ/07dT08WLWku5D1NRq0sRHrVtj4X+3VG+1sTu7NN/J2sjT7TMsl2i
ujpjSdnPkl3WxzfuOMXkef307fJW+P8AkdVYxc7PYtyXAkmlXlm3dG69x8WQzhsXfG/uPKY/YjLf
H7Wcx/ydtDnOSi78m1Tj/klVHpydGdWH+R7ZQf2G5SrJ/ERalA7HEzqJF+rCzYqf2LIt6m1+zGo6
sbKcse5nWR2aiYpxkR9SSi/kahNMtvyL8zbI/ixsezVUmObeDbHURviKGv4P4qK0tRMu8FSlRzZc
3izu1EfxDbpzx8H5l7vc/L1Gh08M/N+ocdKVlyEyKlcJIktN5HL36qKFu56cHBwcUe6RUoNyGtG4
lydiUn2lJNS9xakHVMS1tOTO3Ro2xtJlvyeo1u+DZpRcVwepqpv7n0n0jpUymnOPwbYact3uetqw
9SJshotOqJazhafg2RjL9RzcPUTK/wCnMae35KknqI/+MVp6fpoerrRc5MzBWfQjfpLKHB6Lm1yV
HQ2kN7dc0aUXzR2aXqMe5vTXwbXH1V7mNLaOD0d2KtjnLrceTY4bvk2KOwepH8x/J6aWxfc3Rbl7
qzZ6Sijb6e4aWhT9xaureOELQWIryNvLfL6XF015FDZvNr/Lib9FG3+HH4N2l3L2I1GtpUtOz+Ch
w2qMWS1VK5N2Vt4N+u3/AG/7UX7utObjEzJ2fW6PkxLBiVGZn1mZtHfk7G19jvdn5cnE752Z/fVF
tHbqS/yd8m+vbOS/Uy2Y1Z/5MylJfJk7dSSMymZMNr7Cpz/yd1sw6PrlX3LcmbaL7i7Z5R5o5kZt
9Pql/nqq5N1FJWXk8vp2l104L2sUXyYRe3ptqy2izakZ6bmiqL8GUXRwNlF10owXQ4vx19SGWU9C
2Y/Zj+AfwT+CZ0DugoLpj8cXP6bFpvV48GyEi4ihHNHCOEVq4RRe1ko+34V0SJaklhK+laU8fJ9c
T60VqyVfHVT1Y3Eqro/LRkSjG0ZWR9uF+C+MWeLPkjpR8maM/wDA2hr26pKOC3yPBx1SPq/SzlI3
rj4HjA9vP3Mx/wBv56e4m1givN8G6iKisFtG2jwe46O3JLHkuiSfuduR4/fSiy3RtVWM2+S2qPcU
pFYGxOsWZqx0ONC3DoUF5E5GKZdGXR25MozNFQe44Goo+lnBVHqaqwSqNUOUl2nd2lx4O1C3LJ2j
dG6S7UbFBURT4stijdNlqKaZv1OCro3x+kuWDukn9hvSyOVZOLRGW2vuaOOWRUVRtnyPbdjnjHg4
Rx0jpyjtm8EaXazU+C+vYse/Sy0ultHBVZLHj8G5LtPJlHbA/wD7DdHBtos4FWnuj7iNSuL/AAbo
xqPuZTPchJ8HpJdlUSn4NsVkVp2WbUqZ5Z7jTRSFq8JkYEdq/Mkj0H9XuVLnlEq8Mpo3rEScXyep
DT3v2P8A4xKWrHb7E9RLc14JJfs9JfBslp7Rv3FGK58m+cc1gjLb+YQ0p5lL/gSl9LJqHgyvBuSr
Fla2I+T/APRq1JEnrw2+x6fuVBbYrLJfs6X2kTk13xQ9Nf7glL2HtVC1L4ZFe5bWR1g1PuYHbH9+
lpU+jcX5IN+SWBr97JER91owKcom2PKF9yLPgcEI3I2jn7mPA1J5Ial2kJEtzFfV7OaFG+fY9SR6
UOT1J1krDPCPUa4NqwTQ49NvSSXI97skyOhsz7ojL3JP5Nq1KiRnJbkhW62oahOlYp61yIxiPa9t
FOTkd31M9GDt8Hq6se5lLg0BOy6sbUDdDFCTeS66afwaX2NX26qKI1BbvNlNL9OkVBLJmMX+hUoo
enVSLcF9y4rci1w+qXt4IR04JYNnn7FRRHbFbny+jUkSglkcpQSSLUU4MVYghRilCKEa336wjdfc
jGEUvejZJWfSuCP7PG/UNh6KTc+B/tMoqTlwKWs2r4SFqQzB+5B7fq4Poj/gnCHMeT1Es+Rak8fB
iK2LFGnqrixfYeq6vcInoNd5c158eRulCC8Gt3KKKlq6dfc8S+xF/wAk/J/G06fyOpRl9iWrprB6
cVbI6mqrfsxaad6ksUjTk+WjUnPkgvFEtOaXdg7ld+UNpbIR5JaenGlHmRHbE2qvlkP2XRylyT+x
ozTW5s1v7Wan+4NUZJfJGuOio1F5LfsSSP1LOc9JGmTH+9kIfsdzSfyVpjbYpuO5EfZjPkTqihi0
6yvI5e6GLTq7FIZBksWXVH3N+ojZD/gi58H/AKlxnLHgUfTsqUoxNunqqbGSmjtVm5qujJ+xIgyB
L7igKlmss2oTirEqtG7U5F8nqSVnyxynkk14Q9xBrk7OBacyN+USFqZ04L/k7vYaiaZpfY1Pv1Ut
J9wvVTiWhNSdWQ+34NT7Dv3If29VLS+oXrKiyDt7bI/ZD01oub92Pb+zbUzUcuTUIdIbfch9kan3
6x2OpEfX4rkv6i4TcUyK9mN/A5r6RR+TTcU20vBG8ZP2YR+0tn6i0vTTV1Z6m7tq6Ifs8Y1BSuyE
vdEYRXbdlvwsl6fKfgznFD235Zt05OLF+ZJk1Pd/7GnCOJPGBy9SdEvUlJ/cmh6+ork+ENbr1SGt
ry88exotext0l2TfJpxf1JZEtPOTR3cxiaij73gpm9c8G3SdblyKUpW2+WT2+VgW/wDhwNeX/ias
vFl/7flFuhV7F/JfsKPv0lL3K+Bt9P0JZ8n6EkvcXhIaTH+9+BIbOx1Qoaj7ixVw2RvwiRQujRv4
sr4JMjL2K+CTIZH8mWkbeaGk+RyckKXabUW2N3AdG/jcSsavpW5I2pnI5bkenAjqyFXCJSkz4Pqz
R8CluW48FbkhqLFb8G2LGpOrPubE8i3cHa0xTrgk9y3eENvME8m2Hgai8GfJHUmjc2lFE66r1voF
teD4Nu/usi2+EKKlluiMmy179Lk9kTZpu3xRe2j6RPVj2mGVuVCW63ZiXBvltY06T/8AEm4/SOCf
JFbvnB6XuXiSH3cGObMRMxFPU07Q40kx7ZRX6k4Slb+D1niBHuH6jTfsT0o4V+RXKLR3SSS8Igo/
ysX2HKTjA9HSfwXHBt9bt4PVvv8AcWlqPPyb3OKPQ/Z3l+T1NTUjKcvPkjDRznLN0nHu9yS7ZbvY
+qFfc/iRr4ZDTUbjHyLuhXOTt1dNfqQ/Z4Z7itP6tvg9bUbb8fHRQ1ZYFL1Yr7ktH9me6T8oevra
kXqP3Nmg90/cfqSSlXkfpTjJ/A4amooccnpaU92KItOmhaOvKiUvXg6zSP8Ap/2eXp6fmv8AcKcX
Rt1pHazbZGW7CZTZvfJmR2sbGouxtspEpzzZthhF/vvUq68CT05FQi10uPa/c2yi5i1HHHszatJo
pJoU/YS9LPwVsZZWzeV6UkOxtQ3H8Nj7dpuj/gr0LKWjVj1KbszolegVt2lVvP4B9OxHuKEYbkbf
SPUWPgr0ivT2lyFHTW5FOG03S5FFJSSO2BUo0jfH6ja12lsuDKoprBbbNsODvZfk2wlaN3k2z4K0
5dvscn5r/wAH5b23yfmSx1qGqfVgvU5/BWnq0V/1Bepq2bVq4FOTuRsjq9r8Hqaz7ubJvjBJes1D
2N+tPu+TunE/ixG46sCXo6tI7ddtF6s3Jn5eq4GP2mR+ZrSkdk3F/BWpqykioa0olvUbl7lf9RKi
/WmX+1a3cs9x3a8bP40R7daNlfs+q4p+x/Hl/k/Mm5v56dmrOK9rO/Vc/udrcfsdv7RP/JWpq6j/
AFI6ksqy/BKS1ZKPwy/wY5P4uq/1M8mJyj9mc2Y1JJe1nOfc7Z6lHdLUr79Mas18Wfxp/wCTltn0
yZ/DZ9J9L/Q//WIvZL9TmUS+WYk19mfJ2bv0O6L/AF6ctfY+uX+euItncq/D2wsuUGv9sUcHBlWU
0XRVHB9JwXtNtcF0bS1Er99tMouh9OC3gpIvacFLJlHBt8l0PtKLo4KSLkjBVCk4nBiI1+BVEtxy
OCidyODgtx6PAopZN045FFe9G6cTgvabIxO6J9I304KoVpWfSYqzvpGEPiz00iyuilONnCTJL90o
wykbWrLkhNn/AJElGUl+p9Uv8i02K6t5JV1468fh8nl/qcdOGcdODgwhaurw/DJY8j9KdFeqy9aT
l0wcdIxrkmlTnWRx/BFRVoSkt0vJUY7ZHHnpwRT4EvTTpclXDd/TY16dfJHs3v3Kk9OL9rP4aolG
K/m6VFCi48i3q5VwOOxRfuPtxZXTgjSs2yhvfljUFgwfSy6EttoSnBSl/wDRUIpS9x2qK/2tXg3S
Xg2KhVzQntMrNGysl7VQ+2um2hyrBhEtyxZ28Dkl++UWjdtQ4pDFg3SwOEK+6ISaNtIlwSk1/Nwf
Sh8HwRpeB8Gml7mEOLSN2GdsbHvjRbwbdN7ju06iZqxuKxZwcFUcd5P7Ep1mz8vLHPVWRWh7VSXg
cKHOjfNdL8KRtUs/JGOm7hZBy+pjd1I2fs9sjLX/AIjNmmrZukjg31grTeRKf0EpvwOC+r4Ixjbg
2R3c1kfqLEnh+xaHJIyaenHU7b4NJvmifVRRGU6i37nii45+xtatI4X6lpY+DZBC4H2kadRk+CD+
CU3my6pCmlwOHHsJGY9zLkkNxSHa7I8srA9tFdfcVJRRWL+xcVgU9es8dHKCslqan8O+j2pD3RtJ
4Nqwooc2j0483wQ3xSflj9Pk9GuD+WIk8/oKUPpQtTb3EX78jnSVnajfrKkhS042q8EpVUitH6mT
Wt9UWaeFfA9iTn8EpaiqCxk9XTpfI9OL7eLFrzlJv5NSfsjU0dF9iFOcp3Zpwf8AKsjUX/MRjFci
nrRy1gl6a7oofp/UzVhrO6yQuuRuNNkrXYvclONKkOE/sqFOH0SP8EVqfTfR6mllIk67qNug6nIe
nru3EWpWaeS/f/azs/QnkqTItcMkzcyK+B7WTXyWy07JEjLP0H+9XRm0UpRyOECKk+WfIpDVkG6d
5JP2KTwKb9xrxRLazdKXBCie3kXLyd9DUK/Q+KFccGasjpx+kvarNjhkvA5Y6NEo/wAp3ukVptNf
HRoaXNkxKOo4q+DTb5Jm3yR1dRYNq5qhxiLU1o9w4Qy/g9XUy+tfzeRqK8mcanlj048EVzbI6uor
m8ocIvPkciOnK5J+ROXLVjUcGmaX2NXqhfbo0/JqTuobuOmqvglNKmyL0vqY1+0Nxl8EJQzkh9kT
0l/KTvwbIukab90WubG5kHDlsi/dFJV0zOK/Uls6x2OrNJ+8Uej4XJp6V79z6d0lH7sk3qRePDHC
NVYvRntNurBv5Pyn6cbNKbfdKOR6enPbG6IN2q/mFC7S8s+TdDDbNFvmiOlwvLZOtRNscd/5N1Rq
O3hOiSnqtx9j82SjT8iUZJx/8SW9pQ+TV9N2t3gg5ZRqyjxuITg6kbpcxN0nfmh6duOn7EVWLNse
I8yH+zaD2Q4bIw5I472v8D/Z9F/mMz3zfJHU1I9/9JSd6r9jW1dTMpCcvc1Ng2ubJac87PJF3dn/
AE0Lhp/Bp/c0hJC15/4FHck/azV9tpqmlKXBquHHwL7Mr/ab6u+jkJsivYa5F7F/A40xyfkVEtO7
pn3JL5Mn6D/e6Yxm58MVSGz5INjQydtmPYYsuvY+aGae336PIvuNReTubefIojaWaHGntI6kmV8H
absmxbZEYThUST+Ce73NsW7+B7r/AFMuh7BznwOL5ZGS9yFkhRkiNYSRyLUmt2BrTVyZulZQ3p/W
fxMD9XU3Mzl2TZLJcsl8VDBLNkYrLYtXVXd7Eo6bz8GWQaVmnH2RqV56oj9ir6YPq/K/pNT7EoPk
hGJu1I2jTjBVkS9jXJr3I0iC9kTn8j+xor5IfYwJaM3D7Dlrark69yjHTTSIR9kieom02/BBy1JS
r3ZuXsNrVlTLk3P9TdHEn5NsvpJRkvBGsd3BpfBKcms8I1NP6Rwi9r90acZZaRBryzSj7I3J19ip
SlKvdl/JJe45un7koxfdfglDXm/1Nn7PLHwPR1Hlm2zYnjzIj+x6Dtrk9P8AyylqqfjBPWX2Gvk1
WTEyb8bTGWerNJ0S2vfrPCoetrT3Sfj2Nk+BZ7WrQ0nbfLI/sOg90/LQ7xJktOGpulHwS1o+xHOV
k09PyiGtHhEUnlPg0/2hcGovdGro63EnRtbw1hm2OF5kf9JoZ24cl/tdT8IXd+hdpCZ2PyZl4E0K
JvZ2nJqS92JbvBL2LbqVcFR4/fQfyVfJJvkwLb9PkVsUY/VZGxt+SVEZNrPyP2O09RyXI18e49pl
pV7lWsfJJLkWnJ/qd2pH/JdxOaifXFfqbnsZ2pX8H1JG64P7scYxj+g2LUc47vZjqS/yVwju1If5
HtcGboMT1JbWY2srcKUtRbvk/jKxtakWLU9zZGas3WKOpqJP5M60SlrKjtkth366Q9mtFjUa/Ql6
s9tjhp6imvgbFKbqJthqIch+u9rXDNulPcW2WR3S9OZ2aqlIbi+q1JcG3T1ckXJ/lo2w1M+w/Wm0
i9PU7ju1Gn8D7vy/c79TJ+TPJPV/aP0ZL05dxPU1LVvkrTbZv/aF3XhnncS9K8+WbNXDXkjKEu1M
2W1NIctS/TO7LK0E7L1HUOTg+ij1HGypwyNwjRui8la0W/gxoscdC4Ia17l7Feg2bNDTcbHOb3Mr
VuUeMDjpaTU/c9aUrX9JtnpNsb2S2PghJaHHNlPQdlaejt+SzdDkUNXSc2bNCD0y5Pc+u5co2aml
v+TZpactND1px9Vt27PT0dOUDdJvUjyenDR2v3kb2t2bPRhptL3HZvS/Q9OGi+NuT1X9RPRWm3u8
o9TUdv8A+uuyUXqj09DQenfk9eXe7uQ9LT0XC/I9bc5tu2h6K/Z9rfMmNS0/UcvJ/wDFHGP7Lget
yv6Sl+ylT0nKR67WyndI9OWn6g9KEPSXue7/ANsXpPad7wVpvB+YVpvBh5MTZ9Rl5O52i4vazubl
EuLqR3ybiZ/fY5O2cjvk2uvZqSiZm2dutM+uTXydxUdSSP4szvO2Tj9ilqy+x3tsw2mUtWf+S5uT
+5T5MTml9zOpN/FmXI7ZT/yfxJ/5MykzDcfsfxZ/5OW/u+mG/wBC3KZt5MbkjLkUztuzutmUeTG5
GW/1MKzg+CnExB0eSunH4u2JbWCkXt69qMocWq/BeOnBx046cHBwKo5FOXlX04OF14OCkrFOmkWr
NkYbqK/6dH/x0OPoqNlqNtnqO/sZ6VFf8Gb6e2De4s2/gunRup4KfP4KWWb2nXtRtl4KijyOW14N
jXd7G6nRuyU/96KIm1aHwmLA9qyRbRVHgrBwcG3bg3UemL3G6H+9hD3N1Id8/A6Ei2mXQn7masdD
hWExN0OqFpoU5UOqK92bpcHhipYO5oajTODukk/kqMom4aRwZXRT1V282NRXCHjtszj5OypGEKWo
s+xSqxtIcKwhQUM+5g36+Ct9G5cMjFLBlYXLHHSlfTti2cGUUkfTjpwLtylk1HtSor28H0+B4MkY
StahGUYraydL8G5RdFKJbiVWS9h3Ro2xVs+nJwV5R3Kx1BcYJfc7Vjpcl0/LWDuPW1VhC3NQXhI/
+mbVHLM8GyCtm2aP+olG5ezOeUSS9xdvaLShiuX7j80zPNi3ae3HJrX7El07Y49yEWqSzZjt04nZ
3L2ZvgsM3eDYlbN04+LFLUXHkdYrhIr3ZGS+qXkUPSeoyOo40pr6WS1Gqibn2wXsXHuj7CkuHkf+
84x+C0sk9P8AwKD5XInLyPauCME8dG/BsYjc49xP4HOLpm18o3V4Jr2f73S+5JmHjopNYPFjVYI4
Ny4HHyOXuxuPgalyb0KPmiW4glwR+R39I/uVElKQmvqNv/0erqNtHpJ5N8+DhDdDxgUIKkS+xqL3
ZtGUydc0SWo7VkvgaaqbZGa4YxacdWl7CnqyshBeBvybLofuJVgrl+46lEbE8O+lo3ai/LXk26ao
1fsOUMOym8/JaQ/k0/uaRPrBamI2duYHG2/cdck4y+qz6bHKMeCv/wBYZhZ25FKK5yKpVqexqR9k
bFxZGK01aWWbN0d3si4rFG2PvkUdlyZvgiCNN+Iij8kPV+oW2vufSpT/AKhR0vqRDQlHD8jXwemv
1IQgqdZFtdSJx9sn/Uav03wKMUo/Brf2kxYpWUqjX1SNZQ4iOHuzUS9i9T6bOxdrHNrf7IcZKpfB
WniN4Rp6kvqlyX8kfguQorhEiMPBqxX9RH9R/wC84n6FicfJCydEb5IlG4UiUH4NT7Gp0j9if73S
+410inj7lRXcN3gt5O1UivI/cUFyuSbfkf3FB83g3/BJGVdi+CRuTxZdWTSg456b5jhD/gi5fTZE
7J0kzY4t/It7SZUdRX7dJSX8pvq2NuO0sbZsRqEfuQJCnFdyIxloeeSM303KO5jnNZLo1Gibi3LI
o6kUoiSWfLHsd0Q+5CMfJKF4Xg1SXuQem3BLkW54iv8AI1Fmm/k0yf4f2evcj9ic6uUnyei33mp/
aP7mp9jU+5ATXuan9rM+5qf2sb073N8i9Sb9M262nud8i1IYXsyUWt8yMjtTf2IOaps01B9yNL1+
Wa2z+mkTc3fyRJfY9TbwJS0G68j1IQcNvuSnWXg0nVWjb4RrfYdLt8lRwlzIf7P+zYS5fsTvLa5N
0VbNbU1IuPjI15ZqylezwRr9S5ZgRpeTROMYNKiMYTlBfBpbnb+RryRlBbiU9RVbwRT9v96aUmbb
HMTYr8H3ITXv0rwKxklY7Nq8ifBtvhEn7/vdF/I/kbMOj09SX6sxkbSI2YGbvcropfJRJkF8iJMd
+5SG372LTZ2+xnIp4wbbPg3zSOzBDUsf2NS3yzaiRV/c55PVxZ6cGQ1PBCK8ItnKZ4Em6SQ1fk2l
e56docE8M3SZBKcTDu0SW7LIpvjJHI9ZurJK7NkcxXJW7NEowdIzyQ1ZxI+EkalP8Fi3K6HKUs+x
iVs9aX+SdO7Qq4NR7uUSzybE+ELX5iSv2FO9qMZtG+aK3RjL2HsfbYtKOnuSFLU7cnozdJEZSqXk
fct/t7H/AFGvnSsy068Dl49io9tkNRpbuekpYs2XSboSxuZLcLTU1cT1pV9x7ZblJGtKTSt+D0P2
f6fPRbfpE7j7Dc3GKX8qFCE/yk/8nsl/yS0lSp0TmtvHJv3RpCiqpG+bVoX7PuVoUp1IuU0ox8F6
d+n5N3bnwbpSXwkSc3Wl4+f96IUdR9vuVHufyZlWSov9TbqSO6VI27i94qZtTPVZ6cXkjOXBs05Z
+S7/AH0ZewoyUioJ7vccvfpt1rkdl7fk27GhqMXZvFFwbkvKK2yNw92nu+T6ZfYeGepKO74NvpTO
2Mor5FKODv0nI7dJo9XLS8Hdpy+xjRZtUZI705n/AMcpQcEZKUN5T0meqo0V6Flejt+xbsxcjatK
huYoxgpxMaJXo18jkluvwfwCvTf6D1I58mNOynBo9TybVCythc24/YjGC3r5FKkmjZKj8uR/Khx7
aHq6clufgqTSM9FHRlhe5TaN2pz1SXIk/J+VLbIfqzPy5m16qP4p6vqd/ubNTU7T8rUaH609zZX7
Pq7Y/wBJnVwbpzcmfl6tI/8AkF62rvf4LRUNfB+bquZWlqbEP1Z7z8qTgjdq6jk/kqOu0kf/ACWf
m6zn0qOpKKK1NaTQ/Q1HBlS/aGylrv2K9R55PpkYizKK0tSUPhFaspTidnZ9jbLWlKPsbotxl7o2
z15OJWlquJ/8mRn9on/kuEmpe6Ma03+p+bqza9rOCoasoL7n5mpLU+76fS39j6WZX4cRb+xlf7sV
G5opLrwfSfSYRwbWjdtNjLor98kW0XtK6YMm1F0fBtLo4KLrBwZMIuiqFKj6Tgs4HtRT/BhFyibE
jc0cHBhYMI4NpuknRVCpWhGEZWDx0dcm7b2nA8fjpCl8HHRTksF7UOlXWM1yhQWjbHqa0diH+Fe3
kuKwYKj7kaX7zwKySXuY6rUn2w+Sv/2Fwj+B6upwcUZRprT4Ylyzn/A9SKw/xXFWJOPb7ij9Q56S
4Q7XVRXuKLy/cpD1ILA4+S+icsL3K238ktTRWBp+P91QiRbWBw8ly9x7VaMxKoxFG3YKkfTdkZRW
LGqyskZVgSihz2jj+HP7jR+5e3hDio0xsVIuePuNKt3wbpGYIbwT+5HtTwPhEYr3PpQ00hV7inS4
NjSPGBtR48Di9Lai3g2x2uhQjp3H3G3gagjuRwbUsi1NRd/gZJtZTHKKtj9SG2jjJUF9x6dIlIvU
XamKuOlx5NujG0RnPlmDdpq5FbcC9T9R7VUYo2USlWRvbgzEeDaomYje0/Pjg7fI2kZRGGnLt9jT
k+Sf4I7c5FFLwbWXKz6XQ3tNrVF0XVIqrzkVRqTHF8oaX4OO04S+43WBzniPuzscWeHIUNuWxaup
2Cftg1fuUkXS3VZHTksWR04/TFDW38u6ocZKx9uGzbGPmjdNd/senBbvgSjKWmn7EPVe6fuJ1ckj
0dO9P5Pz5uepP3I/s+m09Q3a9Jv3MUbofTXgoSivJU131n4K0+GRhofdkJzWX4JVHBcEvd0epq0k
/cUMZNSMHUmT1NacpL5Jx8m/Wq2eP8EZwVxTzRpwiqF6X8KD4IOa+pZRKMff/dWnZS9un1YF7kn7
Ij7X03kYrgiyk8kvt0cb7REv3un9x/2jEvcjOSx7myHgy+WRsbNifaKb8kl8DUGb5Ea4JbeSKk/J
FI3+R2LcPbVlLgdLBumsnpQeLN8lubNupH/BuVI9TDXXHlndwNQaf26SR9zU+xWlPbki5cjZ6b7f
ud2rD/ItnB+ZKinqx/U7XF/Y3Ikn5NsRxfkUY4XR+pwdn82b6Pf9PyP0yMHbsjJ8SHgh9zTJfgUo
5+CE+DcVJLCJansR1H5Gz05cJGoT9POcoc9TD8G6H1McpdcC1HOoe3TVvwrIfcvpHVmrrwb39kiL
8MnD3kRn2t8m7zZpzwpX0il9bkM9CbxJ4OFjyP8ArkOc+ZeD/qdX6fYcnSfhDbbq8IU5xub4THGL
vUeDfr973dMtL9TVucXfhM7FcBcOfv7H/S6Eu98s0m+Sbmk3Rp1xQnF4NOfG/wByc3/KS1FNra/p
FDU0m5Ia04OLRk+TOpFfqO9SMm/CZFmqpJbmyD+CS/8AL/dWi/kWfBcelElaFJH6G1JtkdRokKMn
9Q5fHTcxXyS/e6f3P/QeCMnwhRj2r2LQxXK2YHYop9tjflonZBRde4mMW3Dsz7EydmOSe6TaKN9Z
HpwTI6jXkih0vI3Fujao2Q0/SoTJ2Srkk5tyz5MsdOxN/STcvJ25yRsdFCqU6NOEnbHpweDmQ9xl
0Pa8k9TU4IqTzIsrS4+BS19TBA2fs7qA3qalL5NsnukL9o1lj+ljjHEv/oe52iLSvJpJ80S62I0r
8jl46T+5AonPxRqIa8le6IwRfD66dmlXsT3S/J8I1IrloUfZmTcvcojGPKdkF7InqfJFT1nsJTWo
t9EZ6k+xMUou8EdWUvylnknOcqdYH+1SX5SY0mlZjlYFF+9GhXsSg322Sny45J+n9bHq/tLu35Ia
kapsmly0SvWlsvybt7l+op0k65HofsuZPlnqT7pXdkNPf3IUlKvcSk9sILkrQzBPJCNpKC5JR3KW
7ybWvqYp+GOTXczT0VP8xvJOvKwxy9SW1nq7t2xXyRhCVzgskdbd28s36j2wiicofSnz/upNeCMG
9r9uk/hjUHmhqbPcotiSqySs0n8kleKI0zfJ7Rwgxt/vdN/Il8DlLA9vBug/0Emz/wAhSf3OR7eB
akmjaS2m7GH5FFew6yyMXgSbRL3JWK5L/Jutf5IRjKsmWr+5vk4v9R7do4btpulKL/UaqL+w6N85
JNPyX6i/yYfJ3TiNxlD9GNaTr7G3Ve37l3G/uSUGKerqJS9mKPqxx7DfqQZL1NRJClGcBx0f+BrW
V2+WK9SI9s0y9Nn50tr+S4yi2LVTbSYvU1Npu9WNmzS2y+xWtL0y5aqbHHSlGRv13sh7mzRmpY8D
3Ponqz2T82duspNIlKLu/wACev8ASvJGPrcDWlPdY/WltPT0p39hRlPNG+L8m1y2vyOMdR2xyhx7
kYyf5ZmfcLT0foeBOTts4LVo268sF6MnuHul+hTwOWi8G3VeRTTfpeTN7iW76PA1obn08vpFaj3Q
MK5lyf5XsLTjBp1n7kdWM3HTXhi09WL3L/k9SKrNmxwdx/8As9Qe6NxZ/Dkfw5EV+zrbRGGvByn5
O3RbI+mq0k+BaOnuVKhtu2+X03RIxnouU0hw0U9LT4Klpbn/AFGzRfo6fuOGspamKIuGjSXuR0/+
m4XgcNDScJPyevKbcjZrabmz/wCPI2af5On8Fwbryd37P3DW7Zo+xhf7rTg6ZW64mHR3u0XpOmW5
GJHLO4q8GeTEsFy5KU20d/7+tObR3zbR3dPy5uH2LnqSkyo6son1ykXM7NTaV60jvtnbJx+xUdWR
c25HsUtaf+TMpv7syVpzkkfxpluUrO3Un/k/izO6cjEmjGtP/Jmbl930xJr7H8SdFNs7XJGZTf6m
ciq/0P5q+enLOzcy5ORhG65UcG3aWrPJwfSeS6KVs4dH0lbTKPpKZdde2B9Jtf4b6We3Xg4XWqFq
7d1eD/4h/wDFY1/0g3KG1M7F2o7o/h460haj8jvpuUcFyK6Z/Cko3+h3Kule4prCfwU8dLp/4LaG
vx9qf+C2v+CvwLbEtp/4N1Y+x2LCPJfcNS/BUItEpVJlNfhuMajR34+5tgmW0y8lSQtkRyawimq/
2Cv9C+t0ZW0lFZRxmiSaxYseDg4R4HgxEdrwKPuzuwOSX75EZOuB3Q9vHXc10W5Ie1HpkZyoeDav
Jul/yYpjkJs8WJRLmVGSZhG6biit0RtLA0jg4KFjt9zaln3NkeDPjyNQluG0eprfoUqG0haaQk43
ItHq6n08nfWmi4ZRuasucYxj7j/NRsUk17i3OKRt05KUvYdQSZep9Xk9OM1v9jgztv3ZtlKO74E4
wTixaUUfScdIrWe3UIzhFOL8saivwdsbZmI6i6NtW/YT2n0m1I+nBiJUjti2vc+kSayXRiJbRVC7
VcvI6RhWLso+kp/gimrHhUo0kTpEcWfwvTaLfgqKtnBbjgqKK25Lo21k9TUipSfCN2ms1RTIvlov
FKNUN8IjEqPbGPsSuSaqyXpRtFTRuisHcsnYrY3OJtfFlR7YrmRJQe5cND1YLkvZgSrkhKUajzYr
1IqVW/c9HQ0N6urEtSPK4fgnovV2NSFp6Ol62eSOtWy/A35o9xRhGzTUo8lRwlzI1NPTeY4+5LW0
0l8Dajg2Vk37RbuEbIdsYmn9hald2OSLWn6reRa8obPg02opLllvthH/AJJOGVdOI9eH0sa9v+24
/wCzL7kJNXg2xKedzLkWjbDArzgTTwRjJ+SzuVlI+zPTeRyaHXH72K+SP9pibWeixg3SwyUYF0XH
wPcbvBS5SJbyMkR+SV8Ciiy1wUVDyiUnJ0ORshRHV1JMcLzQ5tY5PCHQo0KEMe/SY4LySlMSaux1
4Q7faySfsTnPm8C1Ii+BL4ER07vpsLpm7TbibZ6n+D19Sx5qTJaa1MEdWd7ib9kSjHUojzLuyRi3
iCPVhKpG3UeTCOBe6ZAl0wVHkjq6sb1JeBQjy/BLbGq8mrr6ix4K9ND7aNsnUvYuSujtyRpdjeWK
MNPHyfw0b+EJruRS00ScY00bdR1GyL03uiRa8ktfWjcfB+bs018kpaVS+UYx+Beo/wAz2JQ24o2L
3PW147r4EsKK5SJVjOBas4KU5cH0R/wOLilZraTV6nB6ktNKh7IxlEUtRdjzZv0u7THLX+l+D8r6
PkitWPdZt2qmUuB6zKv6kS04S+pkJOKbnl2VFVbIdiuXNjjpxqz1JxvyShtW7kmpc8koe468xG5c
WhqEVXDHqOpLwhrUSUmqSQ5d1NilKN6ngejpO9ZjlqSbkxPwJOW2EOWSjpX6ceSKSYuN65l7C0NJ
2ocs1I+5GceWasjbBRwqaPV5X9I/WiuKUUS1dCWyMuELU1XczS+ESUlij8/heRQ0vo+CSapJGx8N
ko6f8ysl9yT/ANpw+5D7EmhVzZ3e3S37i+w0Qa4s/QWnLyWj9SDGP97H7kf7Ri+4nhyGocD38iUV
kk/cmbH9V4N79hoW5XYn4Q0iOpLK9jCpM2+yHT2ifO1D0lCmNjlLg2qk6OcdH6U9pU47mbtSov5F
+bH/AD0peCWpV14HDZtQhkYx5J/YfsIX2NyuS9hL0BasltLgrZnRG5x2m6i39BcVUY8Il7WerpLc
yGlOCpmfMT0482RaX5kuWPQh4Mu2R9K0L1ZW1yxqDsi/kgN9dI0v7TWNSiJ+dJr7H5cJSZCWV9yf
9pq9HOX0xNqjKZshpyhH5I37mk19Kyx6cbUjffLNM0/sR+5DF4FH9mk9pf7Q7f4Is/Qz/UKuEj9p
3C+ZGl/abJ6cpy+BvR/ZHXuzdqqs2a/2Jfc0/t004xVtxLkiCXvkj9iyMd3bfBqtezLlmmaRf2NE
jqVdVg2LS9NryerqV9iWps2x4RJwVyvgnPUg4RiqyS+5qTd7GiP9Qt2YOQtVx75Zoejpd2tLA/2i
StyNOEl5NNRX1ZP+lg9kU6wRUVcT/wAqy/Yl+y/sTt+WLfK5NmptVyPzIbYRNZjn/wDq7vo27cLw
cCNPB84NJQnKC/8AEVtv7ih5aPy1crslqa8do3LCL/2kxP2Id1jK9jJS46L4O03SH9iG1+R2/HRS
JRbG0/3sfuQ+wyhRk8e4vI5I+5QyMvZlfA5MgZ9jcKPyIf2GjavKHPwJN8i2l+LLcVZsvgdI3SSH
COCGXhmmvgnNm2JKZlmHyLWwTgn3CkvcjHp6cSO9mXhEnuVXwzCRL5PTvPkfybbybJOot8iScZf+
QtQlKTSxhEafkjJuqQ6Irk5SlV5Hp6TaXwXMjOSdcohBcJDpj6Qk/cjT4JanlmqzZeS5Kx2lHHJG
OnTr2Jy3Lg1F7sUJSRtWVI3ThZHR0mt7xtNOK/UuXNFIjFcpmnCi5ewtHd3Cvgk9qXySjoZfB9DP
oZbixakvpTLFqN9qZcHwqJylJR3l3cUR01PuRv1FY96jCNF6T/Ls1rkraPqXIoJ3twei+WbpbXR6
ejnUHqyaqy7Q2mm7PXlKPwrHuaSfOR7GnnwR0Lpm6VNm1cLgeTdoSpla+pj2QpReBZW6v8kpOUYR
XhC0Iy9PQTrPk+qNRWaJ6dKMLpM9TdC4+bNN748e56k9rl9yvy1BeBOH0qRpTepGlH3G4Zyd9Jpc
j/Z/2R7U+WN2237kZwdUKE5Lf7tkpucIpZwL9nhNQ/ZvIpb4VtvD5Hpba01g9R6kF22rZJamrFZv
ItOGpCvufm6sP8mp+xOSa3Umfm6kJf8AsOtWKhFXyLU/Y8QhiytSUVNLO7yT1d8Go/yxY224/s6+
mHWv9pKUXjyVKVs9VpKPwbYMbk8MSWUKNmWbYsy7ZvRt/mE/A6+v5G0zP76MZcmIZ9zd077lE2Qi
0Lt7vcrMmbqo7o2fQzCwb5R3IrZKjtToWpV/AktNm1Qkmb4uhKWm5Udug18ilG6Tszptl+jTHFQk
hzfcivQNsIOJbN23cV6bFNR2FPR3FLQouVr4LWfg2LSobmVCG8/gjj6Q9Xbcn4Z/BMx2G+Msn8O/
sbVAbn58H5eTuwWJQ7vucYO/H2FP+ZHpvguTs36X1G2dFvnoo6MsfI4t4L1JZ6xhxb5FtnyP1p7o
+ESg3mQ5aMqP4ioqc+09SMts/c2S1cH5OrVilqauVk2w1cGdY3y1G5rJ/wDIPzddyXsWzdF0yo/t
DR+drOSN2nPbIx+0OvgrU/aHtN+tqKLX9Xk/iwP4kP8AJOS1IPHuS/6XU2o/+Uy9Wbm/k/J1HFHf
+0SNkv2iW32L0puLMftLK1Ndyj7G7Te1/BU9duPsbdLVcC9TUc38lwk4v3RX/USN05OUvcvSm4s/
jTovUm5v5PytRwKlrsy7YtW3CRctWX+RynJbvER6rxH2/B+XqOC+Cp605Iw6fud+rOS9jt5+Cnra
n2spftE1+p/8if8Akp68/wDJ8m31NXaZTspScfwdkpQ+xnVnJfPSnqz2+1mGVLWm17Wdk3H7H8ef
+TOvOvuYk0/czrTf6ndqzr7mDE3H7HdOT+7/ANrJF0KImkbGsl0cZMxOCqODg9ul8L9+qRdFPrdY
Kouum0WDCopmEXWRm2i2iqOMHBhHB9BdFfgSRvcRQo3tH09KjGy3E4KNzjg4oSirsW6Ns4NqieLO
DGX7HqSVL2Z9J2o3T/5OD2JL260jc40Z6bpR7TMUjjqmbK3m56eyJ3zePHRSq4jaq0uBrz+NQjyx
ymvzPcoQ9WdfFlcdPW1X+X7DquDFr7H8Wf8Ak/iz/wAmZSf6/wCgpIWrrYj7DSRwcddsNTC9z+MX
+0T3fj+k362IFJUWl8nHT5N+px5O7t/uY9nPgca46pJWLU1/PERpQ2usD7cL/cUXXJnkUnVCUV4N
9GVwYiqMxRwblEdLJlDpCW1X8jdD/eoj2oaURs4E2sFY3D9iPYuB8IjFC7VfuNMSjWX4N22zbSG4
1ZGbVlOKoSO1LCPS9PHuW0NJxb+RQ09O/sbtRVgcdPmy2jg2i1taP26NNYQ5JXt4Q9OUNsPcfuY+
t+R6VZG68WPd9CYow+lcC+xvX1Ufkq2epqqpF0S1IK5D/LwR/wCoQ6/lWD0pL8uxuuDaqc0Qhp/S
2RcuaySjBGYnAvWjcSPp+w3FGSMNKVJsjObuX4Y7VmxRUB7ioK2RnqPbHmiX2Y4wVyFu5+TCsqsH
bF2LdHJSQtScc/JKD4kN3kUYckYuI3PyRXyaUKrFmyax7lQXbZdYNtXFeTekV1WrqKo+L8mKO3kb
kqHuS2LgbilfwS9RYj5IquRTaW6rHEUFG7N0UntWaFCX2JNLEVhG3Uj+XJ4Jpq5JYZu28kdOMbbN
063Lkf8AQnycr/BJwpyPT28CuSs8DxgxkUmu33NJV5JNL6VhFai/Km8E4yV4FPCsWnXk3OvUQ/2f
RV5yKepKSjzSIwlLtgsyZ6ek7iR3+3A5aKtko6i4ZqakfqXBqR/aPplk1JSWV5J/7h0vcf2MOskV
z0lARkUY+5nmirz0kQ+4/t++Rpk+m5q0OMfA5Sl+hGT8kl8DjBm6fhkUuKJbWR3ZIqI5LkipPNny
Wzm0hbi7Vj2jVWxamoh6em6PVmtx+ZD/AAWqS+TfhxXgSj03L+YqQ9kluFXRS8n6D9ObiLe9z9xV
7HpPtryLdqx/yVpO4ne6RXrRK05qTPWjkqeoon5U05s1fsSUVkj+060e7whwT7mPV5lIr0953SjB
teR7K/QSzKLN74ZKuSP3IH6fgjPyR1Jcn3P+o1VfsacGrcyf2NXVa7l1g4tOXk05e6Jfs9dq8k5e
Yj0JfQT1OdvBNTwkR1I8ojOf1EPsfnfoRmuGjZ/OkS+x+pq/bo+kIyVxIRWIpGxUtFfBjc9Sie99
q4N+n9VmnN/VJZH4P2Yj/aLTurfLFKLUp/BSzfJpKLTk+SZoQj9Rqv2Q/wBm1Mu6Q5bVjz5PQ0+Z
YZpvy8mWl9y3qQX6mrqaaXNWR9CW2T8jX7W3N+5+Wti4yKc8RXuObqOnH/kXjQT7UT+xoRj9Zq/2
j/ZZ5XCN2LXwelpLvl5LdycuZHhVzMf7N+yy2afDkKe5xrmQo7//APZiNZIlJ8EFp7ePBqk/v/uH
TyOhx92KTPqVkmhfBg7kJCfyKxka4sz7fv4MkZ9zYuzw+jwbXwmN+aJWQS8s+aJCp07FZMvyRtvg
x7GTHsfVKjPsPUkss9LTXwbp2bSSSMOUV7Ixn7kIenVuiE3hsp/SalcktzlyWxtMj/SmSk/CMGSN
ex8iqUyMZ/ULRg88YLtkt1/r0ko3RvlcUibfkleckq/ljgpvyJD2o3STQopC1dbtivBSqLXEV4H3
PaR2q8kFLka+PwL7mnfki/YXuaVfST+xqxYvQdSY92pJL7kPV1HJt+TR+xqVxZrkr9zUhHLY9SaN
q5TIX5INeERXuzRX/iTn4NT3qjbHkm5qrGPpFkX/AOI2je1k1orwjZDMrNOHlImk+DQlH+UX2G+C
D1deW35eCS0dVSmz19abd+5LY8SJftE3f9OSUHJepPFH/V6ixeDZvVvwR1V7kK8C9HUlFeyL1dS5
fc1dBeCCh7F69MhpUvcubUNOP/I1bjoLhLyRlLglLTdxeB67lcfCJxnL8yeFE/6zU+4tNzSnL+UW
os/AmlTfItL9ne3TPz2t7NXQtcGn6baceaNNPwj1Z4hJjUZXCQ58zJfs27drS8IbfLz/ALhjp/ye
4vJDN2c5KvtZmSG/k+Brycjpkc+BqLsUpYXubISTwN3f76ORttHYxOLNmo8luSsc20rZtUvA9rLx
j3NqkmOn3CyRjav7ku7Jtvli3NDcpoep/KRW5Ub7V/cWnF5uhbpf8lylH/JKto4xdFylH/I12tj2
rAt8lGvcivVjj5N0Wmzu1Ir9RzWpG/ubNPBsm6+WW5Rb+GSjpOkb9eah8MUFrRR/GizukowQn6kB
x0ZZ9xy1VuUmLdqRJOOojbD6SMp6y3P/AIO2UZEkn2m+cqNsJxN4oasttFz1VI/LnFv2FLWlt075
Ix05xlgtvt6X+0T2T+Tt1k64Rui+38EHr/wyMPX4K0dTc6NmtLZpryb1rpyQ/U1dtlwl+W2LfrD9
Odv2Iy//AFakVv7kh6+o+x+TZoyPVXnkj6s+4el+ys9XX703kjDdJUbNK2z1P2hXHwLuY1o/8lRu
SfhFPRk2eooOK9mLQWZvwJu2cSPUTlF+5s/anfg4ZLS/ZsJmvOfnyPVmsL2Jaf7NBqXFsc9ae6Mn
bPpyS9W2mP0ouK+TJgs/OTlBH5Om1MX7Rr9yv6T09PS2ySrB/wBQ52vY9OWk99VZKWrFvS8I/gtk
oaGk4yfklrakt6k7aM/s8iXpaEt3hj/aNVN+yQ9zah/T0wd1zh7H5X7O1L3PX1nftEjpQ/Z2pKNY
9z/qZTr/AMRab0W5JcjhqaG53eD/AOLIx+yux/tSW2P9JX/TdxKc9NvTf8pUdN6aRU4erGqJQ0f2
fZJqrJampJzk/wDj/ce3T1Go+x38+59bkjypGZWiozZ/EkZ1D6qO92VCTR33ZUJtL2PzHf7/APL1
HEzqyPzM9O10ynqSO3Ukj+LJouZcZuP2MasqLm3Iq3FmNaf+S5OUj2Z26s1+pmU5fqeTsnNGdWZc
rde5jUl/k/iT/wAndKVfc+pn8Wf+Tu1JMydrO2c3+plsqLkcyO6ylZ/NRmylZ5M7hra7L7rPJk5Z
5/z08mFJ/c7o7RnHTEbLaM9L569qs4ZTTX4eDjpwcdODjpxkUpLD68deDgyioQuX2NrVNG/9plsm
ngv1U2VoyUpVj4H+0yW/2iV/0qP/AIyGv+lRu1Fn2OBbuDZ621v3JRjrWyTSqP4e1F0ZX4OLLimO
M+V07IP/AAbqdFPrsjyX/wDsNsufw1FFtf8ABTX4FGNillfobnb/AEPSismUziRuldfYcIJnkpoS
ijc0+BqUf9uKhOSIwXllmFg3NHgvB4ZhYLihWi0hOXA9qsp/vot0Zo/LfTBuo2IUpUNJIUKyb5Hh
libKxY5IWCnVnbQpTo22rLQ9+K9z64jcVY0jg46JRXabX3S9z04C381k2qa3exaPU1O2CKHtQ563
aU9RJm6HBJyVnfGMUOtRWVp0/sOkfSZRHdwbktyFKKowXtZlCjFXPyS2xoeBaZxk46L15VOz1NKK
kjC/d/SfSVQtTVj2LNH5cP0MqioR3H8M7lkwsFKNstwaRtSx7kHqRvUf/BJwjgqRy+lJWKW2kJVl
m5wpHbHcfw2d0aLUWfQXtwcHarLlCkRj88lKoxXMvce3uR6iWHwXtdFVk3OFClNUl5O2oQj4Jfcj
H5NOEFlq2x6bmvZpklp+XgvZSL2EU43n2E/DRKW3t6qKWWeq4tEZtbtT5Foyn3seO7kltW6mVJUy
4x7fcf8A1D2uOVZWjH12PUcPTZp60qjGXJv05evP+k2vR9P5JQ+TCW98v2Jfs0Zdy82OcVUkRnJJ
z9iGg3cny/YxW9/ze5KL9/8AbcW0duDe/BFMvybUfqYMl+5R2qhi9m+C37DpfvoDqTRlioWpNfox
6emkb/dlLmh7iMvkS4bHfAoidFp9pt8m43RI6T5Mc0LUt0P4RKEfpFKUnVijJ5odLB4PD+xGCWBY
7/L6WSS8o3u6HfkSXBd1CxJ+xthKkKerdc5EnxFYJT9yMc4G+4UKKl3M4Ny4PU1VtgKEFSF9jdNr
njo5x4GinwPajdHDXAtLV+ryNoZ9mI/T90nq40/cUVpravI9rj+gpaj2orQkpJc0NzxD5Pyqf2Ly
5H8NHqJYKhmsscvT/wAjSil8oktWWyV4E1mPgl60ktTwidcX1S18Lwxenwx6mpleEhaUUlqy8Eb0
05vLs+iP+CtqVZHpqO6S5Jak4KK92Yiqlw0T0orPgWrrR4WENRhUjVU/qNi8s1I/Anq/RZ+XFZ8j
1J1NeEOM0lN+EbYfS2Q1Jcy5JfDFJ4zk+w56cuR/tP7T+Z9z6VX2KcV/g0dSHk0/7USg6l/+wc0u
0UFHc2R1deN+yFoX+bPCS8EH7qyeu/qUiC+CelNLfJ4s3Yj+hJuKWmuW/I/+nWzTvwb56kZM2aWE
R06ajXJFQW75Lf1s0/2TT7pXlmovgh+1/wA0mMRq/tL5gzT+w0vf/baP0Jfcj0bjwUZGlyRPYXuS
+whfYfv++0xjZGU2m6wVp+w91ijVts3v2K9juW6yMiSXBGbyhUqVDS9jcJKNJle5Dw2JnorT/Use
O1M4W4cU3tMruoqE9uCmnN+5u1lt+5/FRcXaNOH83kb/AKUPQ2VXkz0UfNkX8HHZHkxSSGot0bIR
szom/UVfBurJuk6ivJXq2yOhp5iylxFGru9yC9xTlG9RnpRl3+xqj+5OceUbpcipCjpWn7o/Ol3e
WbdPoj9P3UVmUG+Du8+43oOmP1Zbok/t0Saw/JDTjGKdZZOGndw56anyhyjzZslF2iGo+LNEmkry
dyrrZJz+lIRGU/cj8oen6Upsl6P7M1fk1pS5F9zR+x6so70vBUdNwaPVma2pW1Pg3RVu/Brak4uK
+TPk1HL6BVz5JuWURNImR2yayQfurGnk/wACm9P1W/B+X+xpmlLWh6avCNL+1Gum3WR+56+ssvhD
WJalYS8ENbWlndwaL/8AFHoRhhyIX/TkXpP6WQUn3VkitO6rIlpRszOcPZIe+Tk//I03/wCJ6m3K
Oz6po9TVdyZq/wBpDQem1CLNSb4Rpy8NGpowi9kpGnfiOSe1/wC26brpa8s3ex6Sosl7Cr2LmUiW
ckWybIlvA6/fR+5S6Lu7SrtjaPt0ciH3FfsOXgSEyQ0REvJH4KXLFqUZ9hyj5McDc+Rws7S9RIcY
kYpvk04nqN4KXlHqjkykxarHG+7gclyzb/KZ5KtY8HaimenuWDbHhm6TNPa4p+49r5JXJZIvwiMU
7olrt0SjZqeyZLT9xQckkj0oZPUk1v5z4PR0f+Byly+S0u33I6ZtTHX4MI+k4ZhMyqPz8SI7HVex
Unx5ZKMWm/g2yefYSktyNNblGV+C4O/BNuVbjbuVEn5kNS4JqJB+UyEFLKRPVltv+pjhovd4wXsZ
9DIqS7fZiyopLj3HBYV0LX4oT05cKj1JpM7tqpYSNVx+h8EYbk22aUtyo1Nr+DdoijrcEVDi8l2m
OTcYR9l5PSjJLRjxZ3SUUlmvJKEaSukT1LjwepKcaRGCapEp6kkPvjti/cWVX3HtkpSfsPQlzwL1
JRaXyN9kV5bIaf7Oq2vLNKpxfavJLUU4pvnJpfs0XuW7n3HDS/iVij19V3ITTpoWjrP4VnqbtO/6
rP8Apf2Wf5ksOR689WEtR+7I6Oj3O8yLcoq8U2amlUZeE0XKcP0Y9urGMfuR0NH6Y+SWm9RRaXk0
9PTmpuvApReeRaP7TLu92Sn6umn7pj/Zv2V+npLmXuejrvdHhWLU9XSv3sl+y/sn1f1jnOe6T/c3
/sbn9x8fgTR+amxbFUbs9ONnqGxJluDbZwylFobyYOLKSwW4O/c23S/f07/Q/hOy6roppvb7GyGm
0b3p2yvSbHijfKO74Nq0pFVX3I6lXXg2+k19ilFxXuKZt9P/AAbfTavyzd5Mx3n8B2fS4oS9Ns/+
O7KWmz1Kv4K9Bm1abi2XJnqVuZjSwfTsFH093yfwR3cUb4tv4Nq0zdP/AARjGNpH8IrZtR6yefY+
hMrZhm9/UJJXR9Ju1JMUdNWkKT8Gx4R+XlFYSNj49x6kXlmBxkj1ovv+TY2qLbz02/s7x8lbk/sb
9Z2+sU3tvyRc5RbZ9UT+W/ufVExKB9UTdpyju8UVo6uDbLXwXqPc/k3QdSKjrl6897Nuhq7Y+wt+
vwbJa2Ds12VPXk4jlLl9H6M9jNs/2mW1+EbtfUSa9zOpp/5P4kP/APYctPVhfwxr1Xs9jdpy2SK1
dZyRt0dZxP8A5LPztRyPydT0/sL1tVyNsf2iSj7Hc7fv+DbpajgvgrU1pSj7G6D2v4K1NaUl7F6e
JfBWpqyPy9VxP/kzO79ok0Nw1HFs/wDkS/yP1Jub92drcX7o/wDkTM683EdYKWvNL7n/AMib/Uvc
79x7m5P5OOlrD9z+PP8AyW8y9zGrJfFlvLMakkvhmG79yvVmZ1Js4O2bh9juk5P56YbT+CvVn/ko
9j+LP/Jz/tVfuFaOC6FGi6Ko+k+kxE3bT6S9tFFqJT/eowfRkyq63RRwfSUy0Xtz0pGY5OClktnA
sFbS6NtH0jpGfw79r/Uo3Uzg4NkUzvjbMIo3KOPcujakb5LBwNUbq7TgeCortOMnsd0S66b3iPyY
o4KibnHBnpf8pwqKX4Ma81+p/wDImf8AyJ/5P/kT/wAn/wAif+T/AORqf5FLU1ZOH3HxhDj0UPJF
yre1ZS6o3TayXD8OG19j65f5PrkZlJ/cjpxXJGlnyz46cfi9SeIfJKKWL/AkLU1u2Jjn7GFg4/FU
csjq662x9vceppqnY+uIHqa+I+xSjRhY5/GnL6eTuSj8yZ2U1/kvbjn/ALE/9h+5va8G1YimbaVi
ltHaGkuC9qO6KFwNOI3WDC8CTWbwz3G6/fRbQ2ojvonJYMtHb9IntVji0hbHeS68G1o7eSM2jbVE
vctl0qMnavk9NaNq+TdPlok21fszbo6akbtVUbII3UcFC1dRdiFFYS4RBNYO1YjHCPTlGoWNND1K
/MbPR/5L9zZikRhp/SI9SS7S0qS4RYsYsexVCJsqjHJtiqflj0a80N1nknBu0jauUcCRGP7N7ZHk
jL9q7l5FtVL2Lijg/JntN2q7mfp+6UVLsfg+8ScpJjxgU4LCHjKRJT9ze+2JaWTfPk1YSdpHpx5s
lKja11jpwWRPUrc/DMUxQivgVruHpm03S+nwzwYWODfL6h70qRKUak/gba+kjprCiS1P1ZKKfAox
WGSkqk0jZJZsnKK+iOEKOpmGoalrKWGbpC0oR5HKVbkrJaMaw8lWv8G6HchP9owr/wAEf+nluUPB
P3bGXQpzj2e7NGMY8vyTa/lWB+r/AA5s1NyylyKeMi01HyOUmvU5HpXHank+r/g3w7oktPRyjfKT
S9kOGo238mnBPur8Hz/26/8Aui+xP7lNkX7oSRIjfsS2Fs7i4sXSBL9/+nRYsaWHRJZSNzrBFLii
WyWRKTFtJNOpCUpYbKTVikzkTu2ye4ioyuF8GeBNyW5EtnsONXYtTU4+R6elg9XVyX6afwfTGBSr
BtgqXgyQ1VyR3exe9b/YwIlORAb03tZ3y3fcQxJjUax0lF8MSj0f2E/LZL+01S58F+56WrLaju1V
IvSzEYmm5RbN7+kb89Y/b91Ej9jU01xE3+T04vlmfMTa+LIRjwomop8Q4JOPLNax6rIzf8xqV1Xq
LvvDHLTfcSlrd0UL0U1qR4J+s+Bz03UvcT1HvtkZ6mr2y4j0vyicZu4pYJar8cCnKcbq2OH7LOlJ
5NKc33Pklo6UtmnwQ3yq3yQenOMp/BXPuaUdNre34NW+KNCEOTWfwS/Z5280OW1X7n/TaT2yY/2j
U1pRT/5K3W/k1v7T4Jv3Q/uS+5u1FtgbpVGMeF7nqP8Ahp9qNW/Y/Z4Qrcma/wBiX7PPKukN1+p/
0ulab8i/aNSclf8AybVJX7N5Nf8AtJvwmen6G/5PV2bBat5lHz/uPnrFJ+DdXk3iTkYyP5FXNDj4
EYxgo/QpEbHkfj98l8HFC02q/wDI9xtCXufI7I7X5MksnyRsr46cspEb9xMg1J1Yr9iWrNccHp6M
clzRtYkvYwjeuRQXnAp6n1GjD+VDf/ibrf2M+Eci2fTZFy/lVkto9wqKng/JeSb1XbFp3kex5HPU
dxIqTpse15oi3LsslKTrFGpJeSCjl2aafsSdYO1EVJUylyLUn26a9yktuMD724+x25kd2CP2/dQp
Fe0TXP8AJFLkr/xoi5eXgi1/Sa8peWP7mtLwL5Zpmp1VfTfIlBPUXyfmR58D1EiWeRaUfc9VkWv6
TWeo20/ccUaspLA4x9xw9acK8WRlJ3k0/gnKf0XgeaIy1tWWz5ZqR/Z9S5s9bXm37WyXpu1MevPx
9JLTb/Nn/KP9s1fLwem5re/B6yy7IV4PVt+nZrfKJRfJOWoqtYJacPqNut4d5O9qKisRJbv4Kfav
cjKRJ6b7Zktd59iehe7W1MbUL9r1P8HpPUjvl/KLXjnJpryj1s7LNZLyjW9Vq1kX/Tr/AIHCa7iG
nfdVf9oz/wB9UockVKWT605exd7cC2SO/UVm9TjS+RR3I3bo2Ykj6k3Q035KUs0ZaX3K0pqTG7/f
O2Z1I/5HslbGRhPg3SmjfGSUTYpr/JLZJORFN0vkUVqR49yXenLxQk323yJepHd9x3O/sP7m56kf
tZ/EVfc3w4QouSgbnqwv7jhCSk/g79SK/U7taP8AkdTh/kqGEd+tH/I2pacmNQ+kj6ktsfdkdN6s
cG9SUmLfqpL2Ny1IuQ9PSr7m2T7X5LepFscNHC+C/wBp1Ni+So6yor1rE9CdpeCL1pqMvZm3RnGT
fseqtRplftE1E7NSM2blPFihrSpe7MakbJKD7T87Up+x3a6Nv7PNSbRs18QXkuWpGx+jqRkyMtV1
o3k9PR1E5R4JNvtLL/acSO3UTPy3ZfW67T6WeTycM4Z6mpHjJOMP4jwamprut/B6Wi8Vyb/2hd3g
5dn/AOi/y8Clrwf6EvTTW3mzJ6bxLyKGh9KFBruSHqRTjA8nEj1N7UfKNmsnuQ9kcjy1pilF48oS
cbkVoPZBeDZ+1RcpC9CDWcm307kbHo0ShHRdslPolrXKCH6Gn3EtXVfnCMl9EtVepBcIktPR2zfD
F+0a8t7T+k9LS0HCaVI/6h6l/wDibPSbnVWOWot0f6RrT0Gpe5s1dFzH+0yhcW72n/xmf/GPWWj2
+Im7UbUP6eq3L1Iew1pfs22T8i/aNSTk74PSh+z121Z/1EtSV+x6XoW1GrPUcXOH9Jt0/wBmpmyW
l6j+SX7V9Kf8iP8A42SUYfs+1tcj1dWbk34f+5k9O4y90d02/uVHUkkVJtnbKSPra+xjVkfxJX7m
ZyszKUvuYk0XKTaKi2n7ouUpP9/iTR/Gl/k7pOX36/xZV9zE5L9T+NOvuZk5fcw6P4sv8ndqyl+v
TGpL/Jmbf69Pqf8AkzNv9Tk5aP4kv8n1N/cw3/k/iT/yfVL/ACcmJyX6mZyf69eWv1OWeT6n/k56
cv8Az1u3/k89M9cl9K/Bkx146XXXJx+BMWnL9muvKP8A4rP/AIzP/jM/+Kz/AOKzZHQ2fJfn8HBD
UiuGfnyWm+KG46iHp6WNP8C046SnH3Mfs0T/AOOhw9NQiW/x4/Hj9/f+90hNox9QmzsRckVwWNWu
mCqwcZHFtI7cjx/t7yf/AN/+28/9rv8A2KjA02bL4E2rJNYOcFEpDj7CLrpcRKQ6H/8Ak7n/ALbF
DQ2R2kEV0sa8jl7sUl7G2T4PuNfIhj/7t8//AJFhP2ElLDHKrL9unNkXWbNo2+BJCRNkc4okvk9R
4RKEX/8AiCv9u7oP/wBTa4OjCO9UjsRvlA/h2fwzdt/5NvH6m5cm14HqKO5s2bWh3z/+Ba/7ln/s
N/8AZV22fTR9JaRwVtL2H0l7S9pt24L2jhRdf6yv9RX/AHn4/ccfuef9/wAF7m6spGxce5T+ro20
JIb8meBJ8ixg3odIlqLwU3Zuol/t/wB/9Tz/APgOH3P/AF6JoyTrkTfv0fuX4Exx4ZqEui+xO/fp
x/2Sv9h8/wCn5/1uP+1V/wB0gznNDZRngwKa8MZSlUSMpcjQ4p9rK+B/JY03TG/9w15/02P9ze/+
vVytDudzHJzqL9xrTkfmzpCjvpe5tWsi/VtnbOyt9yPUbwbd1s3N4NsZqUvg+rt/0XPTP+++f92P
ruoovJgyjB5PJgpm6imWimv98O/36s+3+1s/6Tn9w+iE6HuWRyfFlQS4O5CTRwKO0wcG5Kx3Evw2
dnd8m5IlH260cFUWzCK2m6jCOC6KODCK8l0YiZLopI7jCwVtZuaMI4LrBRlH0lUcYODKLoqsmUYR
VFuJhdLrBVHBhFUXRhWcF0VWTKMI4LcaKoyi9rKSMxMRwbayXtZUVkyi6wbVFsuSLUCqyXKNGImY
s3bKRSWS5I+jHubatl7TGmbXHJbiVGNszGjdGGPc27XZclX6HbGynHJucKibYxtndGi1DBt22/gu
UcHbFs2tZLembY6bfyLcuRTUe02xVvguaLjG17m2sm5w2rkqEbO43KPabErkXNHbp4NldxcoUjsi
d65N+2omyMbZc0XGODZWTdKNIeyIlKOWblCv0NsPq4O7/wCjco4+xtlz/va+kRYGJ3SF5G6o+BDm
bF0q8kvsMUb7fY/Ql1iJLLLdIqKM5ZeCqO7m+DwjGRuXBwkO8v4PZGEZaElhX03NocYo9y20iond
li4R25Lmjwh+WZxE4pGcsSSpWJVXybmyoROMm5v/AIKgjKyJtr/B2RLnHJ7foSUVbG2sWcKJSVsV
RpCtUW1bKhDBTj+pulk/Kgd0BNlacD8yJ3f/AENQhkc5x/QpqhpQ/UUtnahJqsF+nufyRWnCoplO
Jv2NlaWmVKGTc438FaWmkxucMmYscdPTr2JT1IYKcf8AA4x0hTen2IUdhjRV+7OyHYiMJQN/o2/k
XpQ+44z06b5N/pWxw04JPgfqQz7ib07JacdNRxjBKc9PDfsU9OzbHSUUepsuBtemjs0lH5FOMe0j
pvTXtRvWnGxLTS+TZOETf6abHpwitxL1IrPk3S00yWmopYpD1ZxTNsoqkenGKUfg9drt9jbKKa9j
tjGK+Deq2WLTlFew5wgl8kdtUuRaTSPU9OO73PTVfLJKWUzdOEbHpR/Qeo6aO+MX9xwjXGD1tTC6
4/cr/u1f9uef3EX8iHQo+RSY0mWhdFqUMp3TJMf+S/kol1/Ni2zclUT6rLnH9TdpcH1ltbkVoozN
Iz3o2JPcW5KJ9W77G3Y1ITtRPrv7H5kC49q+T+IrLnGy9NUjOpGzK3H5cTM4r9T+s2Q03uMyUfuX
e5fB6ezuLbUfuYmmKL0rkxS+g/iL9DuhvLgtq+T+JH/I3KO9D9PT2L3O7Uiv1G/qNmnpV8luaj+p
uvcemtDPuKTko/ctTT+woPR3tiniC+T+In9jOnvN7j6ZXqxscnHefw/TRT1Y/axy+oWnHQ2r3O7U
jH9TcnvPRjo38m6epGH3ZcZbiOlHS32R1JNQfOTGqpfYX5am3werOPpfc2+sm/ZDlGO4cp6XpxXk
2vWj9hzit1G30tun/Ud+tFfqb49yPRhpJpOmxOepGH3HKEt9C0I6KlZHU1JKDazZ2am/7ChDTUm+
LFq66Wk/k9OGqpS+ByUbHPWh6aPT/wCo7vZD1FHdXud2ko6fuhR1P2iMb8G+HcPShpx9NcyN2pqq
Jv03vR/02lpxl8kZ6s4wdZsfo6u9L2FpQUckdX9oahIelpa+5+UXCKy8Wep+0VGz/p/+o/M9iU40
68jlq7fSXsKE9fu9ketDOLtkoLb6aeS9bV2WetpT3+1n/TabiLU19VRrkb0tTel7kNHTnFW/JHV/
aNRbuXQ9PT1roj6c4rcx6v7TqR//AKH/AE61XKRLV09RKh6utqx2e1i0J635j8I9XT1EsXljUtaK
hF5F62tW7wj1NHU543MlpS1PUiuK/Bf+830WjJ0vc3L2Kb/wdjXA4yfk9xFtdJCZyjHBvljyenp8
Dl1UlmvAtNaSh9jc1uKnHajbDT/wbmr+Cth2afd7m/8A4NmyvkclDe37nmNeDb6d/J6u3dL2ZSjs
GvT3/LFqyj+jFBQ2r4G/rfyZhtrwenDS2/Y3yW74Nvp7TatLPujfn7Gz0y46W5/JntNnpL7nq7FO
XybfT9P5TKUdwtWUVjwbFHYl7H/7z7nfg9NacUvdDn9Tfg2yjtRshprije5foenspe5cIKRub25u
kbKPUSuRT7ClFSFrNdyFp1tHXd9y9Q9FRpD1Ltv3Ns6jE26fHB6rnn2PTdbStNYFOUq+D01W0erG
txWpPb9hRjn5Fr2nM2SaS+CSg7v3FPVeVk9JSSib1O5/Jt1ZYXselpyW09X1O7/g9PUmtnwVpSwb
9TVafOD0vU7Rz051N8srV1bR6enq9vB6z1O/3Nmpq9vsitDVaXyLU1dTdJGz1qiPU09ZqZWtq7kb
NPWcYHq+q3qe7Ns9e4+xWjrbTfr6jnM2f9Q9g56Oo4zfkS1tZy+xs09eonqqff7lan7Q9vsbdDXc
Eb9TU3T9zY9d7DdparhJ+RetrvUo2Q/aGo+x6nqP1P6hw1f2iUosrR13BCnrarlO7THD/qJbX4G9
LVcJe5+dqy1Puenp/tEow4o3x1Wp/wBRWrrSa9jbo6z017DnOcpu+Tb/ANRPabtLWcGXqa0p/c2r
9okom5aj9T+oqetKa+TZDWlFfB6kpuc/dlPXlt9h+lqODF6uo9R/JUdecV7GW3+6v8b/ANRf/YL/
AO1+/wCH5NsJy2nLUvc75NotYZamzGqzM2Zk2UpszyUtTtRcnbGlqPb7Hc7/AA8fu8/6PKx14/c4
/wBJ7fv+f/xWi3j7ihyX5NrQjlGa6cYO1DdcFG6VIbjx+CkcIrBaQ0cfii3wYH+4z+4SRvlGsHg+
BO0VaF24Nw9M3Yuhrqko4Zmkdq6Ui3Gv+++377kr/cdfu1+/RFjSFMVs3eRxXImy02bZssyNIv2F
F5TNxJLqtrrJfwW3g/Q3bT6TKN1f5PpHg2Hai5YEkuRNwOEh9UkbnFn0lpF7S9haQ0+sZyzeStPt
ZWrz8mktPjyJ+aHvbasivNkh/cf2H0ijdWTbD6UPesjN02Oq3GP+5XfV/uH+DP8Aq3/3HH7uv3mf
+yxHR8kbGOQkfImj9Cmy+kT5ox1j9+jtCjDgUnOkVKakWuSpPAtjoluzgtYZHe7G+SL+S9J19z/9
Jdv4NsY/8dVuIuOMD0pPsN9ZKnnJFRfLN0uSXWP2GV5IXjJEaSp+5u8D+w/Yf9pLppv56Scukvuf
/o8qN37RJv8A7jf7vH41/wDgdRk8mBfLNw4WX462zAmnmyzAmhqTz7D6x9j9By8CspMbb8mPYp+/
SWfB+ouji/DKRe3/ACYr8G34HqFfBfuyP36Pqk2foXJY9zShDmyn7Dn02p3g3Vgp87SXSL9mKEZW
Jq3k734wOi9XI8R3fA//AMS1/wBk3LkqcPUfuLVr9D0tv6nqx5PTUNpXo2Z0L/Q7dKh9ls3tUbdj
+5csG1aXd/UOT/ApShvRt/6docVDadvJWrFzPy4OJtUafyOThKV+xw0jYoS3G9/8ij6Lv3Gowp+5
vXHkW7SbZ+XpOLG5eeu5clamm5sxoOJULSO5WRw6PTjB/ccvfqnF0bdXTcxrT0ZJnq60XNlPTf2O
KXsbos2amk5mNGisqPgvrceBR9OVofMF89PytRwL1NTd/sjH/csf9zz/AK5XESrBu2lUXKJVGYmI
nBwcHBwcGetClRto30V5/dfSfSJG6vAom6ikLDsuv3FJGf3ijGJ3Kv3XHS6dG9/hUYG6S4/1HqVt
ieS8s7Y1H3Ld39xvL+DP+kv9xf7tf71ieG0RlP6bNkRS2lDXg7Ud1X7HCOD6eihJJFpDjXXu4NsT
dtwbX4RuXDEcdbop9VDYpX5N+1Di4pCx5OPBLHkWPB6s0ekoL7lyY660i8l0VQ5Sy/A6RXWvInRm
JxgqKMo9+mVX6D/Bg3bS6NtCe2ilEtxFStiU4bY9H+BTlp/8H0NRO1Wzc4YODbRuqikjuLUcG1cl
yRuUWkj06uRvadD60lbFKuT4KfItJcm/mW22L1V+WmLT/Zk7WEhKX0EnNcI9KHKEtL6GyHq5bVsk
l+G/wZ/eL/WL95j/ALdf/cERG/gd+4kJkkihbjswISZaGR+/R/gUKfSvFm6UbK9EbpD01HuN8o2Y
VGOsSJymxYxZ+gyP26akkhpSdDTd9e7TcvsJLS2focDWrByzg7FSGpx3Mc4qr6p6mYiShtikLS9P
uN1G+Ubkem9PJbnGK9hNfQiKWmPH4I9u/wCER/I2x+SnFJkY0JKKSotQjY5bUetqrnhHowXHR9V7
EYLTowqwbpcJm5aar2NvpbfuQlV5PZGFFX7G9xyJRwvg3VG/c7khRSVDwnknih9LN81fkUtm5ex+
Yo6S+StFqUvLR6sY3R6cYbbVG6Ts3ftMtpH0mnIfp8PkrXeLyyMYTi2hvR8rBPdz/ruf9r3+6x/o
Of3sVfkpdFL2NljY0dpcijchbhkTI89UKdHp2XEf2KhBNGY0d31dX1gfoP7iMewmR+EUuTbGOGzu
+ol13Un9yMIRsvy0X4sv4HS5LfVH6EMeSN+3Se1Wbs0U+SIqGuqc15L0lkuf1F/In8Ec+R/Y/Qm3
79JfggIr5KRZpjNPPkZ+hyX8CY34smSNumv1N0uD9ClnBUYUjdLkWldZN2G0j0tPuYpz9rI3F4NT
+0csxXwQUYurNNP+k/8Av/S1/okNfP8AtLP/AGJSizbqT2/c7J7n7m16tTFKMuCnqpslqT1kr4M/
tCO3WQ36iSKjK0d2pR2vcbtbVS+GOGjLHwW31i5cCjHVjurhF+pUBfmKUvgcXOMEbv8AqIDjDbMc
pSSyOMZpuvB3asV9x7ZX1uc1BL3Ni1419x6nrw/yYlaTO/VjD7s3evD/ACbNKVmyf+Wb3rRwNb8D
a46qD7fuKcteH+Rr1YqP3PypWKDx9zfPVhIagsD6If2N+pJKRs03bQlKexfJulrQf6jWm4tl3hsX
50W/Yb9S2PZ5ODCLlH/B+dqpfDNmnNbfcUvVVsSWqpY8EV9EE+RJaibo2z1FH7m6OopyZ36qJPSV
x9+nDE5qkK5q2O9S6Ht4lK7F6uujdCSE96WmhbNRTdCc3sghRhqIr1FuIx407NvqptI/Ml6cB6kd
VSmfm66v+kctHES9dpP5PT0pJ/YSfbH3PzddNjenONj24gepFZPT20vuLWq/uJftM1D4Ny1I2el+
yZXuV+1SwfWvuOH7I9zHOf8A3LP+o5/2rZT6V05ZWTyfJl30zf4cPryz6pf5OX+Dnr5Pql/k+uX+
enLOWcnJ9cv8/i5f+Tl/5PJ9VI+pv9fwQj8iV9zXA5udP7jMNn1P/JzfS1Jr9Tlv7l/tMdzOGv0P
P+Bx0o2/lG5Xk8/g5fW+TZKHd5Ppf+Dhr9Bw0tOvk89fJ5/BwcdMrpwcHBnrwcfi4/7Kvw5/3ukb
pLBt019zvVy8CaXkzEaccm7aYQsGEd0TtVUfmXuMI4/BgyX4KLo46cdeDg4MFeS5I4OC6KSODjpw
YXS6K8mUXRwzg4OC0nH5O3WkXqakmXRRlGFfTjBSVmY0cWVWTKMRbKo4MIyjBwcUcHBwUolHBwcG
EU+ThnBnBxgryZMK+nFIwZVH0nBwfS+nGDjccH0ujjJlUbkmUZi19zCZR9LOLMrPsfTgrlmYtfcx
Fv7I+lmYNGIt/ocUXtf3MJv7H0s+h/4ODMWOtOT6fw2l7lKDbMxL9NpFKLsppo7YtlNZL2Uvk7Y2
d0aL2OvsNKNndBxRjTlXvR3f7IX/AHJV7Es8G2TFJoaXRFpncZLQx0d2cH2/BumxVEdm5yqJ2xHK
eBex2qx3gSjg/qLpJFROUy6SRSyy5cipGf8AguVL4O1Dbo9onbGxuVG1YXuUu4uSSFGJ/Uy2kjbD
LO76i+EYXgbmKke7HuxEwv8AI+MHtGztQ3Kr9hKGF7iSVsuVI2acSnyXKkioHcrYuFEW2NsbmvIq
qI/5n9jioi20h7u6VC2xqBUUXOV/Aowjg+nu9zfqNV7G3SWTuXcbpUkflxPzInKSO1bn9jujgxUB
/wA8kZhULO1bTu7mJQ09sEJbawb5vc/ZGzR08WK4VL3N85Y9kKOlp5Z+Zp9wm32/Y7NO2OWrp5Pb
9CSUN/3HKWl2XwUkoWPt3yIv06gJbNuKNzj6jIw09PsTz8iThTPUl3+aoUNDR59itTS7n5PUeUvB
t0tBbuMEvW0c/In9KXihx09FNoc9XSxZVbPOCUY6dv5PUel2CXp+n9h9m+/LLjpVBCjLSrFHqenu
+4o6OjUfg2amjUvJ6rju+DZ+z6CbfsSjq6OX7ik4foOOlox3ccDlq6V58oXbVexJaeity4Hq6kdi
f+6l+LP4a/An4PmhuiLNrY2fcx4R6dYI2Np0U+iS5Mjz1W7gjp6cZbjLo7rZ6avcfVtHb3L4Nvdf
sKu1H139jvUi9PEfdn1p/Y/MsvR4MzRepcj8qz60jv7l8G3Tvd7GZJDuW5fBszvFnaPvTXwd1pna
6XyfWj8zcXpYj7s+tH5qb+T8o+uP+S59xWjdmZRX3Zcnuj8GzT+ou1H7juVr4NjvexSXaj6l+glN
Pcy4KkfUi9ZP7l6C2w+TMkXqrdQ/Rj+pmcV+pc+9fBs0oPcZaX3Lfcvg9OOl+YKWEh9yZslpdwpL
tR/Ei/sz83Tv9Dfpx2RK9SN/cctSG6vJ+XDavczOK/Uua3ocdHS215LlNR/U3PvR6Wn+z93uJuSj
92OV7l8Hpf8ATtzFP6fuOpqVex6b/Z3KX2FqbfTT8M/iRb9kXPR3m5afpL5KerG/uOUoepR2aD0l
8oqWpFfDZureenpfs9f+VHdqRj92bl3npQ/Z7ldG6UlD7sbjNSPR9DdMjqTrSO3VjP7MUfR3Xwep
qQ9IpasW/ZMcvS3xs3vS9OPubfWhu9rySmob1FWzGhth7lS1YL7s9SC3j0dP9nVJ02XqakYfdm/T
e/2H+zx/Z1uQp6rWk/Nsb09T1UvYjo+hFt8C1datJtWenp6yn8I7dHdF+56urFafsel66lP2Q9SE
FOKN+ppqEPg9OWut/seppLdi2bPRjGPkXq6vpuR6ui93sShq/wAvCX/ds/6vP+tx+7UoChN97xRv
dIb9hJMe4uNYNpbRFIa8jXTiznuHnH4MacZ/Jf0np+kvub/RU2ZWz7G1ae75Ytb07fszatL0/wC0
d6fqX7ik9LbXij0o6O1e5ua9T4Klp7fsbI6Ff+Rvpy/8Ta9FQ+w1HRTfub5X9kbFo18s3LRTYnW1
exsekvuPU9Fz/Q7I+minDe/kWs9O6/lZs09L018GYPVl8ilLTrb/ACnp6f7PSN8oufwVs2fY2Q0M
/wBR6knKv6T01p7cVZS0FJ+4pNNfB6fofqPU9FakhUths9G/lnrT0dz/AKTbGHpx+Bp6W/7i156K
x4NmnpemvguV6rLnp7a8D04fs9fKHOScm/5TZ6WxG2Ogm/6je7S/pPT9FRN0dCM2Z7Een6O75Y9b
0VJv3Etnpx+Db6e/7n/US0+7+k9OOnsM6XqP5FKcEorwelHSUfsPUcN/wxRlpqCPShpJfJ60m3/4
np+moIqGlFv3N8m41/LZ6Xpqvcc46e6TMrb+p6S07/8AI/6japansbH2fY2KPqfIteaW5eD09qil
5Q5RW9v3E9VUl4R6MYJR/qPW+p/0tmzUSUPg2aaTR6s33HpukiXox+r3FKcttex6cdqXyPWi9+oy
ptr7G3Sr9T/qJSW82NpR+BvTdnq60rkuBaKaUaoeppzufyL158ex6elJKI9d6jlqs9PU1e34Nuhq
YYtTU1W2naPT9TsqsD1NCfe/LPz9Zv7Hp6WrceMj11P833HHW1u3zRs/ZtRxgLW1NRy1Eem9aoey
L0NXPybtbWcvYWkteoI9WOo/V/qNutrb4+x6ejrOET1tTWctReRwl+1PYP8A6fW2Wb9fXlJnpx/a
HGHFHdLc/wDtd/8Aa+f9Zj9wnBuMvdH5k5Sifl6kkfmOyoTa+xjVkY1JH8Rl72pH5k3JHY3FnfJy
PyZ7WXqycv3mP9Nf7/n/ALPz+/v/AFnJj/XV1X/cq/1d/uX1Vn1K/Yy0hbcoyik0cxKbiJKjCKos
ow7+3+h5/wBrfH7muOq//AF/ukmJx5KFp9GYeEJDl4FG7a6bkNEtmMijL2Gy/wB1X/Y8/wCq+PwX
+Ov31Ff6Bf63H+mf72/+98/vfnpEiSYqFuGomeBMcEbn7mPY5NxMQzH+q+TP+xuf9Xz+6z/3Ln8a
/wC28/hrpz+J9E+aIwT/AMm5ZLswUIUTdQqH9hr5P0Gjc8Dgn+PP+1r/ANBX+hr/ALpn/ZL6KUHw
ek9JbfcckuT8yO1j2x3G96dmdFH8Ev0lg2y09qPUjC/gqUNh6qV/DNmzYXf+0q/Fz+NdOf8A8I2/
3apF7BraXtODgv08n0F7DdtKoctptouqOMfg+mz6KMIfVJI3bcjVfuMDlQ17fhSSNz/ccWbnF0Wi
mjETP+n+PwUbs19jP4l/q764/f3+LH+g9/8AUYM/99v/AE8V7m5+DZEzyZN1G2LLbyf+Il03JDQ5
r/Aoy5JSr8EdPwXHkfqHYsl5PJHt/Vjk+STUSmuvAjycCswiUkvwpvlMcVk4OOmV+CO7FEVCKqvY
e6kNrgaeJNGCoo7kYRT5LODP4LUemUdsbPpLdm2MW39jJ7I2eS6o4Ko4OCmhbIbh+qqwS+D8tY+x
9JbX/bcf9i5/2rj9/E/TonFi3YQ0jPLfSXubrFIpsdDXSQ31iVN7R7HuO5YFWkpH0KP6CfmyxxwX
Ru2J4PTWlRu+BycVI9P0Mm+kej6Fv3N9E9OOmvwIUfSz7j2xpi3x3CnsVex6MdNInPz+BTlJH6DW
nqdopanckKtLaYWB9ieDCqi9ndRFtUvYSjBH0JEpYvrGMpKJUYxm65Nno/rRlpSFPapSK9LH2MpI
nqNKWTY9C38De6On8MepicCvRTLUNiI9ikLVcU/ND01pKPgSSzJnqaiTfyPYqSNsnUWVpxUnXJte
lGK9x7ppTHXH+kv/AE3P4+f/AMApsXcNlEfBybzI1GTSLfPSlKlZl+BikSW7kfVdHuyKj8qVFbxP
Wleeifg5KRdeSP2KHLwJP2GJfBKVOimX1QzPuRH9x+w+vkr/AMSQj9BjbfKLRcvYVPBegrZtUKP/
ANI46pQsXqJ7Giks/J6iQvca0lgvUVRHb8HarL7khxbyvctdIoX2JX7mn9xpew7xguOS5xew27c/
Jvis/BXI3prBUv8Anoo6Z39FGCtnqTW1fb/Sr8D68/jz/vvn96mnj2Nupcpj1KcYmyDdlzboq2KO
6RalJlQkyoztinfbZ6a1HdDnLMWbdGTc6N278G7W1HGXsbdPV3Mfq620UtOfaVq/tFM/L1ouQs4N
uprqLNy/aMn5Mk0f/pGvHS+Dcv2lGzQmmbdbVWmi1+0pmzQnvZ6nJWvqx0yT09WM37Mc656Y6Xqf
tCTP/lRoU9KVxFCeulL2JTlqqMTbDVTk/wAEZa+soP2H/wDpMaH6UtyI7nUbIr/qY7iTWupyO2Tc
C9XWipexs0JKX2M8PyyL1P2mN+xujrRs2xrb1UnHf8MrWnp6dcI3L9oh+hs0pX8kY6s1pR+S3rxY
46M1OXwVqyjpR9zdL9ojIa0Zxl8Dcqin5Ll+0RY9msm/YWo3UUxR9dN1wSnrauxWL05+oz8/XUX7
CjpftEa8lrWjqzK1tSOmWv2hHp/s7Ur/AJi2SjPUUXR+S8dH62pT+TbpZS89N+vNR+Wenpanqv8A
qMf634/2Jz/pl/3jB8nH4M/uOOvB9P69ODgwdx//AHPk4/Dx0z05/BfTH4Mnn8Hkwf8A9Pwefxcv
/Jgycvpnrngx/wDZ7/fpfTH4OOmMdODHTJjrhfvvb/Q/H7z4Mf8AYq/7cvwc/j9v9bj8L/cX/wB7
y/3OP+1X1x/2Vfh5/wCx8/7k5/7hx++z+8z+9+P32Of3rM/78z+6yc/9ys5/0HH6/wDZPj8T/cv9
4xe/+1fj/sr/ANOv9I/3i/7C/wDRr/QP/bq6L/Uv9yvwf//EACkQAAMAAgICAwEBAQADAQEBAQAB
ESExQVFhcRCBkaGxwdHh8CDxMGD/2gAIAQEAAT8hcHcoamxoqFv0xNyHYOM0hVptSeR7Q7shwZE2
PENFe7JfKE0DGQecDqWWN6ujBspZK2M2xmWhtjL0M9YK3l2Z0U9BW3oc0LRchtRO3ZnNRDrkhJOD
SajQq0xT4OAVIUN2GZqYNELDJVqwRoizqWh/cX7CRB0kKzDNEmm9Y+GSzJQfQYt8mTeDBoQuDIIX
EY4sIbnAsi5gg1cjSRCdHUEvtDdaMqDTj9EiJ21k3I4MBLVgohfJlzSEsIbQTDcVyx8XiBZE+SKY
3A0ILLLXobjgqzg2PZYSOMJw0bla0XFkplLkb/BPvRRjRgDCyyqfQEuRTYsbgktMUr0dgiylyJFk
xVJWbTg0MeQma4GXQ3zMzyNcC9jWZTdNkMIowceRDYY9YlG3RkuBuibQ0n2UaJBkkFgblyJGSmLb
yPT6L30PhBuxoWpsTZSzsQ/scojAN0JtxjZZLfBlkryZmAeLR+IqSiha0i/DIbJ/DSjcRhjbWs3k
wY1m8maybLofdEo3xChuZtFGiqUWfx7NlCiJoda+Ca0cPAkXk4m0G/gU4KJ5GbRiaD9ZxgVwYRZl
rgkbo0Flv4tkwHWO0fRhvaLDo3XkenCK7HWTcr7MG6KhvLmWLRlMbrgbN3gTBmbLyUgzd6LSfQxk
PlleQlaOmPdFdol8IypkC4jBNSYFtqCzknnRnyHBCpjR6MfYWPI4KGc/RONrNdC0HPsVpDmehi3o
sziLh8VyO0XKEw2hzAjlD4JxBx/B6RaOFDSvJw4sDuixXAmm7sapBU0NfEPwN0+xk18L0Pk2LiFY
Im+xQN5I3gkJJuQn0JWE8lB+DGm+yXyUMTLuRvBvByTg9hK8EW8CxEtnYnFRq3s7CXz9Dw2RR6Hr
1IOXxsRC4FinwKvjrkRwLTlGkfZif0CS4MYuVFBHIWEsOcHGh2bujdYExSDk6Yrfww5Y1mxonnZx
y070SIbeB1p6EPAS3yIfYq5Y1TEuwTyLlwJ2KTOShuoVO3HxztKbHcyJMqZMqJOSOp5ROSeRfI7O
B2qNX4CSOA8CHzgQ1OAxdOGJz0U8Qcv8JCRXIrJbOU4JYYGJQ3rolFaNa8kP0RBp2YXMMSLmE8iI
mGrpOCHgiRDkBJmxiSyMJPREWci2hK9iZsw5E7kUuSTtKFGNE9/E+BigWZGRDG4lMdKWECqckM0r
yNN9E7MikS8jQ3kklkaK5HqNeQ+VMccCG10RhE0SvLEMjsi7Gs2RyMEMSS10xrBQglg/Ix2/hi4S
4cESGNQ8cYRDMa0bukNeBwF0ZpzWYdow8sg9jLQ3nsghclQWHhfHs2UcolN8GgaxK5ITzkssGC2a
XRMLJCW6XwiWWia8/Ykh3DWslumHOyMrg98CVtkdvx8KOxPZhkW6LDZEJXI+w7lKBq9mh9YTyEn2
M0eRTFMzJzUWy07BNEpKrTK1SCVp0SrnA9dGgbOTUJDq9jWOWIZyY1gMBqmNe4UexLyGlrZRRiZr
qEie8fGa5Ed5ORBeSk6G9ZcY0DR8iRLyJ2nkSNCA0ehSwJE/Irfv4HLYkT1R+Ylnlmzk3f8A+AQs
2HKFUXgSGwwFmhtCOxKKDQG4btmCfHYySNiX6WV2N38FvyLUf+QPFDANqJ+wnG0fk4uBlmEj4Ekb
lsgoYiDItQSmcH5zBgqim/gv2+NJM+GNjH3nn+B9olnnG8855iPJryYdllsbdsgNylOpljajd8id
F9jZljd8ldnmKK7PYovkrKKyuys9iuyuyvv4UUUrsvsrsrsbOSyixu+Suy+yvgbkVldlyFrkrsrs
8hRfJa5L7LfI3KUtclFdldllFFllt7K+xOufgbuS+y3yUX2WVaVbTzFSUrsbUoUJS78EuSxu5Eg8
gvipRs2fHZRqYnYbGfwr0ZoTIOh2KSGTM5n4DHu//AxuEyK+j8PgooqkuTQhYMiATLkbtjeDdsrG
zZ5hI5FIjmjS2ec+/wCNlVgSK/g81F3lstiYoyMkDzF85JMsUKSMxQtDb2VlMdXgq7MsrSwVlLkr
4ZjrM8/PgNfFdP5mB1fCVf8A/nz/AP4z9Gjj/wDK/wDwhO+ME+GvEqNs+PiCdwSb+E7eEN9lPi8Y
NuyIJUw2iQgm6Z/Q9hT4TPSbGnkQTPSNA4x8qfGhZm3F8JNmgd9DDCMVOLJkga00bhZT/wARsPxI
Rm9C4S9Fv/CbdX0JzDM0Atur6JP/APnF89koIrWxYHvwmzJkYQqMHU9odNLYY9qzKanXG7BQp2Bz
MHRVtDWgWYZZZu1BvAphN8JDPRKzFZNTyHsISgqho4gGu8QzQkzJiUK5gXjJLec5ILgOwBYdegqY
atBLjjnFwPaa0Jich0oVgkbUDSVCqp7LLifoYVwEO4kxnoc8BaBWR7sUOiFJZHmWBjZrOrbglcGt
MeWmvBcopWQxaLaocAD5GBooY+BKiTFFpfYpiNXgeFBa1oNzwixoWxEYGtk2sMQBNhLaotzyDhjL
OUIxMq8Dqg1Plqf/ALkIT4gkMS8iZlDu0dCmqJeBvSGlRxp8JX4a8Qn6PJASXkdlZyLxOuEEVJwo
yWNmyGSJBkTLhjxF8BUqwJa4Pw5aUxBvRlQzQECy9Spo4cin2Cc28l2uE8wwZucwvkWZiTwObJwP
MFBhFTEIFrIwMPImsVdmjXtgyGiY8JBxLI6uT4aQ7sohdSxRRYja5WSkEr64G3cJsY0KtvYta73R
CBbqhPePpkexekL7UdjA4+w2bgNDIlrDFOt8lbGya5dofCZURBr+PIvgtcE//wBZ/wD5z/8Ac+Zi
k+YT5hL8Qn/4nw18Qan/AOn/APqE+Z8QmPmCZ/DifCwJ8Q0IQRMlFmRG+Suouej2Qzo45FZwkOdl
SvkQ6YVQnTAb9RH+vDbuGNxTSmsTpXc9Bfa9hFZR/wCisaxScaHwGAxM/RpFR5weRbgDZpO/RBLI
yWZEJhPRdkaXAjvtyIFxqYjnKQA1KE3DUyyYuwxLQjZDxScJZ6NcqC5U+CLIrwcFl4EOX4UyrwKc
rnQ6qrszwVKKmuLhCc3MoiryJGkldRH5oTRSNjlvkQJnb5FiMrktiN4CWLZUifLDEcPQxis5WZGd
NNCoWaYjbkOSGFYEiGoOK/8ABl9GRRZkiJPKNgBcDN5BPG4LssEMSPloTM8D2jkwRIqVXbZsf32V
FlhCFSXOBTHMRJ7LKOFByIsVvF6FQeCDkGbOGQWzkmCVicXY3qsplGWoyizPRdRCJvYcCgMwRppW
ORz84MtYmy+EmQym1gsEvhLjsVcmJqWdnyJemwq6JVRpwPwIPQZF+WRRWbeBomuxnKMf3KLyB3cZ
8jHvJwI9g8bJLDgGZ9F4GkTAwru0NB/MC0VixC1GccRP+BYJEiiyVe4QGh5M4bfwbf8AwIjreAxh
YzoiebdLQ4yG1BVtaxRshZfHQ+2jkh/d08DApKpCYijWIO1tjSLlBmhrVNKP2H+O62T0DFCS0WjL
lb7G5HETtNXCuDUlFrOuYWbXJHKp8sbYOdMb2UGcE+ZDXw/QkQeINeTgSpIQidI4SkmxKrHw0ciw
LkagvhKNRmC/HA5Ph5Eps36GYQ3HoWx7Y+eRbJkmRrJM5Gh7FhEvgehVURokF+jkWzVi5PscCPoW
Kh/CY6JkWEWEGwsi8FRdPQSxk50cMTrJk+jBlHdsjE34IhwEKUnwDqOMoMPBBitJ8mHo0JeihzM8
EVNjZPOGUehmw1wM7wLDycgNIWKbHlDZSEICjwr2PSQ2hKasCMfCHMAWwlH2LlTvNKsMInwZs8mO
3l9DNT0ZLMjURyKp7Ml7Qdy+iYjJ5fYQ3MZwNYuUZdsSsuRCJoIg5ux5TA3JIKc5Ux7SJR3sR16U
Gslx7kHhRCvwxKfgVUtBPQCU8GQ6EyeRHNBd00EksmsXVLFErEEV8rBCNs2BWhKBoQyM7YsxVaTF
BbI79exQgqVbciZVwLf4Lo0xV3xZNwGt76EdgmJtJguhmvUEe4RB57Rk0Zmx4HeCREwJG3SX47Vk
TqkrULFvQZ1MR0iRwSCwStUhxYdjWmiLyuTMONjWYCfZwhJi8BkXIbLrJUj1szM2GRXhjers9kpC
3BXiyY0MfG7bdjsOmYj6QiuOZweqM2L8S1hYxPw876cQLkslN7KIUlDW6NPo6CsPBzI4oiqVQQpb
PtWSk2F/2Em2sYY03a0zD8sxDO8klHjTHSOlY9VwKj0IQDjKE9i7PtYBlgmfIRh+vQ06zJ/ZEeDE
EehoqghLsKK8ozBiwinDI4OVwieAllMVB3Jf2ZeTOHgM5WFRMnJho2JNjV+DJ5GcHHY0L53wMWBI
mPJJwb0QJRn/AEeGQuVDplrBJs2ILYq+CZNqPAW9CX6NR2GWyEx4ppGGcjyQ42LkNiDRkx/hZwPs
dkI6JFj0b4GJiGb9CBLgeFg7DVgzn6EP0JLQ1gdEbGFGjemCNqFIE4EHJkLexbeMCvETNImPNNPx
DM3w0yGMjWdSA6pwXKzgWBydjPmN2v6NFZnRc2ajufnA6nkwU8ckPFn4qYP3CHNLOhza0JdM1yMn
1ojAXYyrOJ88FQArJe6OXJ4IKLH4eHpkpqLG2o0I0XlnSHKyKkCnovQ1cD/KZFMHyJaLkdQLy7pn
MvEstsqrpBT4RMTDHVNmOfgOCNdD2iY9PQVE9IeEaMhky2Zn4BqVs+B1RkKlcLZTS46KrgYBuOWC
UK5DOk4OmbMLEELI6NR9hS24Nx1Mt4cBhTvotGyaZCWNcjqyEnYmP0Bhsg1GRkScHwZBbewgeAgC
1/wS+cnZZFZl+WoibDLb46EZ4ejVRJj9nZH0IpYNjwWobQlWiaCxcCwEvqEpZtDXNImDQXHaC1iO
BFaEh1QbYGqIkbZyjfsB1A47zEHhr8wt4ElpilG5UCDSI0CMdQRq5OtDqPzoxqJbgyGfQY2UvZYi
S4DsClME8b5Ma3kIW1WK7cIRgJMkVKkz2K3lDy63f/Q1TmNiDxXBKlUsHd3ng3ydPJWfchFewFEV
Y2hPB3Bplxu1sQqs86EkpG68CaxzwKTzMsRpcNIZbhoVKWsrSRwUoeKBMpAKEKORpthlhTmOfo5A
q9lCEtQk5ynS3MxDgzwEwJdWZHTDLZzsGBPgqYh4KGkL40PeRei5yNnJtCY8iyhFUVopaPYmLGCs
po8CWDQbrFoSxZ8PQTMdFSLToZWocGljZMWCwMsXwmBM6NXFGrRwsfFHkwxB9BUW9GAlWcM7Fkbf
yE+GSXZp6FSKEMWcGEbHjg8j/RhxRviCVQlfpkIlehL4Q9kg0MwWCOzOzQiWguz0MS1N4SJnNQwd
5LLLsjKO1yLR9sIW2M2ISxcwZnkWQ/RdPhcDW2MhbK8pCmu0HIirY9K5gxrkToeWUZr7GyaoGmER
d5ikq9ZGtdhEmxHC1gQrWCg3AiPQlvCvIp2nybuktxRKDFzgY957EhwOIXeCk9aGLcdDPWkkIstt
vsqJRgqJM5olVwKYMDeYos01bRrCxuByKi6OHO7Q8tNVcDZNyIS7Mg8pK9iHNojdAKW72YkDxGRE
W7sihhdDGKuVWDHYZG6Lp2Ik0llfGZSOFFnJGWU7nomlhwO6iN616ogsE0RvNeBARobkOiLbQqML
QpyJd02tQYE2JE8E8mGGITuIWMrofmoP7NT2x8AuNCbTMViDfhB32Ui+mik8xyZP0BqFrUNHJOWy
96LVF6GsYTtF4ia5FozuAmkmYSgyzSj5dFxpmg9bORyjnTQ51fZ0J0MMtXJO74JMStxnIqN9rfkP
WDyHkcYNLy2OzA6+EJdBtkigM+Q8P/yI1lsnwRZbYw5zyoM/Aet9cDKuczQ/UnRnvIUbS4rgpBdd
h0GdFiTy2O8xccD608PgUkzjtlozmhymXgTsj2TWKpXAwvTzoNQzCYnNsEaexIq3TGTPwEsi0VXN
/pi+sTBmDMsbuUz0MhQ47WRc5A+g3HX2Jkf2Do3oUBxJisx4HIbsfq3KQ2jwzobrPInkWHkeX8Iy
JIWxCiqQw0yQg5IhLIjFG6HoTo0LefjLpE7EsEEs6NPKHnWhcjcc+Mwi5IWYE8/BtjJZGuDm8DVN
B4EEskbwTOBhNGTJcIqdk/R/Bsffwl4Fi9CjHPhxgbosIJicDZhehfB5M4Gn0YL4Gj1oS/CRkqO8
GYuEb7ooqFh7TgwQfJjWkOhSfHAmyVIlglF5aGVloWRx0NiGdFn5YGN8ODIbOiO6ibpoMI7RXVHr
SFCPQ/xolzj/AIPYm0P0mu+RIRT0kPDZd4jq1ayNSefwxnbL0f8AzRKxw3DbnkuBpzZpagnUTm+U
T9dSmHZ4omWmJ4r3Y1qHpjdrcmxL6HNHPKGdtSzDzgeR1XhEDZNF1kTwMc6ZTsZiGFa1GqQWcHYr
dUvgUrID7RsN7djbbCYqpgvpUk4EAZiWV8WED2M5L8GcuzO3CkO/SagMkRiaj+g2B5GxQ0rPfA4s
s/IzTWNuZUFDapdQY17i7MGLl0f0ZgJ4O7kQvSMGeYNmU3Yvs6l9izLBnfdRx4DPH2OqJSUAkf8A
kGmfOMzG2OSNbPsF0FZYRobdwTSh9MYyZvLG4c2G/TBPuMe2jTo8I6+HoL4mi4TGAU2tHvkk7X6Y
GJsDg25f9G8itku/0vv4dJpGnv4T3oV77SH1Bh+Ct3DJM+RhjIJ2lExsdIFBLtpzwRaiH9gp8jHv
Iwm00JK2NsLAnoSkzyD7lFBSijRjoTCx8JH0dEEEs+CmQQZfIa2EEjEjmZJbEoxyCIPxIy+DhU5t
JQ1gplkY+/hKJlpoudfEFUVST4aHkSxkRkJmkoWGK3RwjToQYKJqGiC8/A3xRu19iZD7AaOX4Ilh
9kOy0XnkTwJDQq30PRqsQhleSZTHUYEwY6KuR7GongSrFwNcDdG6eQnD+mCLER0fYLWjR3XBkxTE
pbHSsSBYaR9kS2NkawFM04wL6v4K61F4PDBhNRkaQ65NCrF+BF+C3ROehLcoTbiuiGR4QbO6KPGu
hN+jkKWUU3ehszoJEr0K+Pjxmw5gLYgoeS6DeQtzWTD32x5gkZg657LkRFSTFuGyGw2CvZX2QW/o
bbZmbKc5wJT4LCHb4HgYxhxRHAnVTbEqwj6twNS0JqtGDFRruLXKGnAXgjGOaYlghYeQ8lXBjgVh
rg7DI3GzM7G1gQol2iQ36R6DUYAiQ9ODhFqwskyLS7NgZJ8HYoL0ZGM76HcLCEtFVSOjk3VnRtlE
hFryKNgHm8xJ4CxhRyiqWcDJw09lGgwflgqqRoyMs5wQZ8fwMPRU3iH+BFlCePhrAzsHqeAUjNyx
haqBStKKsT5E7ZzDJ3IvylNdi3M2IuxNK1ZRzQsz4C5EYzyRHUNsCG0NxlEG/YRNzZHBSPtDvzHl
BswaYCAPojoWWMaJD0GLGGSkmCK4FVxOizSWXKPQcZmZbycBBBu6IbUjA7ljkh/XIrKppvC0P6aa
8D4fxGL0cqm3R/Cw/wDyDBZNsgimTGGcdGkX4mewhwTQuqyYEQqJ8TF+eME039jfdgoKCEbKa4GK
VjJqXiROTyQ6miUVg16HI0LPxOoGsjwznRcG2PQ2JDgkeTJGR4RLwVJ5Q2KGNmCiWdiV9kOxhwSd
LiEFCGfBoLljkRJ8bMV/C5rOkECCBmv+R57HCa4Zg6QVIXQXzWB5wvijkMlgW19BS5l1s3gDH3gb
JjQh1DoWS51bySfY/wAwFlB4L5TMwEJ2N4yWqrkezXCEo9Pi1Us7MFJyOsqoYbSjzhC8WCar4RE0
1cFPUmKupF2pJbQlCTyEpHFJ8qtL8aENyIx4WWLgqxHBKZa1BVoVFy7JNKZ4iQL0s9FeafEwTgnk
vORFbSMGZcFTwIQ+eYJTqIUbV2kRbbJtw3miinDaMJU1RLdtegpO5I7hNFbDOTFMxsaq6w9MfF2V
EPWhIIPAkdH/AArfJ7KPobOeiiwXJ3tYneF4ZyqjfkODQwzB4G2xBcR5aQsCSGuxfesWJYCMU6xT
KMHmMyqpwMT1oJOF2OwjBwdIibF+JdHDBlpCl28DHwpvAk3fwmMieYbrNoc+y5c/DP8AwFJhiIss
ckUjjFR3kCYllFSNq8ZHRo8ZMWLbHnkX8mY4XELCRa4ceBWiVauijqXIV9L/AORziejDSWNrgUjk
NvSV6IVwoKxN8PQjvdQtolh6OhwY6KEmS4bF/TkzTI4NECyEwlFE8JNtMe5Qvrdf8ISOzNcdBJax
iDXiyjJ5URj6s8DOUJjAUn5EVTIbxDrUJN04qX5YS6Gz+DJPQzlGhAyaBSbC8C5as8j6YHgzQynE
wh4iCyx4eijdQ3OBo9iQTCQStMs+0c80Iep6RJxJcldVJ1BirV0MG5OCvUSBvnkJnWhctlG84xoL
XZmCdvIwFmmzvQTNm3bXAzWZVob2yErx6i1O8BOSqNcm8BC0t/BBLThZHWPxEN4HnMHsdwKvLOCK
cC0QmPRaMhVjcwSp0IkcjeRbNBvwOv4ZbE85EyV9olv4LMBBfoSLy4noa0zBiSBX3bGd6wK0+YY/
CZFPqaFNu9CWl+eCgkoh+KxLoM3kgnGtmYyjLBCEa7MADFSrOYHNfsxOf7G7Ua6MIq0h/oNC7osn
A+cFweh1+TB4ZBjn9FRvAbpLy/iEknY4y03kWyG/2CElrYZ/AMWLNPMCcu6NhtLI2moLDMuBOtiL
g/4KaK9kZAs1Ck63iQq5K4GiyfszFDQiJjxHEXJHax4Y38WbIbfAkcUfxsFeRoSnfKQ4N+MXq8DT
XIuMCN5xRulQhKa42NFqboqUDoDIbiEzs/rFIP0XHwz9Owvz0I540by+RAwC4GhMVdETCfgdJ/IW
5HKDM9mx8jr7ha2OFzVVEJPWC81Exl1YjrROI/gDoQbkUdfcPuMDOxu66FpqD7L4JVE50afYh5Zz
Cwx8i1KSc+CP0eMkhpEvkxpFoYDktLgv/d4IAng6sjJs0pX/ANMcF7/Cc0JQZL1ydp4iLlWKo7Pd
Msu2injSMDMhdrEHnbMkGCe9ispdMKn4gwdxowYpg3g4YljZOx4ECxHpmGxJiysDdNPKQwt14MmO
qzZjI+m4PMJtyJ8iywNoI00Pdm5b+Dz8FTXKZR3ZwWh5kcIaiJW/+Q83qP8AnYQXAsw8SO8JWx62
EiyvNYHhKtckvrBExp4RORsNUWMGRYuymyQy4FwJo+9CM8B5G6qSSb4P1T0EmgfYTUo666c4XBoz
5vyNFSEvoRg8mAlk8mZdYHDpMplTpYpui8hjXBx9bsjgEtIqUsQ0eA/0kpOr2Nw1nCRl/tS0xGRs
nI9Exs9iEYnENVayZEdhI2cUoS6HOThzJj0byaZPoYNC7ZJnY3F56IxmnBlR+4l4j8kF1jrpTOWP
hWWHs4tkfAzJunEnA0L6EpP4U+elSg4GLkzsM1NborhrsqruEFSVx2M5B2UTcJvIr6MW7DSPkqzu
slG2KDDnApCuBWEGdpY7ZfBaORDJjo31yOtwz0hELmIlHum42MbvJCXh0ldOTJ2MS0uNRzD0Gn2+
DV8vJjsyeDNG8n4GEYPwbjoaHQagZLXobal4DASDsZAT9jUF7QzZkPDCUbg6HCEj8GhRkeKi0tNG
VKoVBvKWhQclUlbA7mH2Z5seu+DgcSF2Co21NiW7WRbKDJG1qscYuc/CZ6MRadilE/sPV+Mlm2xW
52gfa32EzY9CrUmEryvQZTL0XtO/Yh6vIUxAlcGxKJ6xjgsxEcHrx2Qu3lBxFVNo/wBIwHwfwHjb
IzU9iAjkHV+Crc9DMjjfglxci1QrpXcj4LkVHjgqlWMZMsCElxNkto2m+ODEWYYkEmc76jDlrCb5
LqeSDW9RUUfsa4kXELYuSVCHXDGQriIsv+AIDDf8HDvYV5L/AMpyMw+hLNW9kWJBmBYmCcw9Mclk
R1wO5hgxkmqKiQ2RHCxDTfwWfj4qMgrhiBUzikT2HSKoXgXOqpVCP0uCbGEWBQLIacUUC0bFhCnf
IryOnguEKbQz+EaVdi3eFtdGZarkWEstBsuUoYMllVhDYEsEJP3wvsnK8N+CWv2DnyCQtZpFh2Ei
NeRrkwQ7+4Cx5DHC7PFJRfDzElyVUSOVCZJaRrhZTEvsMcsvqgjC2JdjCgYXI6ea6JID4Msri7Yx
vGYcmO7Y7ALgnxTkdNNfYXh6LZgJiZSyUu7fByw7DJuvYeRCnmEbZghRp2iLgpRPk2yTEPDPQ0aZ
ORjIsM5qG9jgTkNPBhHuPHaPnY2Wh2wnPsFFXvELqLHZgWkSok0shPSf0wu72Io5RhIioChOpJi6
GNsSjM2RFtUS3OSwe0EPayuxusTXJgwtnahH6FG45JgTryMSY4YJqPWHkaVWhVUVyGBan9iT38SK
iQs+EGpZ7Iq8YEbd9lx+w5JJA6dLyPajvA1NkMmfY1IAytRjSjTaHve9GXllDVb0aJwb/BYGQ88U
WUOVZ2lcUb1L2KNxPQnJRLsTmkbL6Ds62vhS3AqWSXYduQajVNgYhceTq6cjlD2KzfAxLuAXLLnY
OqgQyYFJKXQ1ImOofQncITiUIY1C4+xrkw0hveSxsiWxPgeBIUymSaRnnYmaTyLTZRjRVZyiaUh8
ZhoxiiFpMQQRkZMEnfBhMyCcNIaWDCkz7KOEKHM8iojRZJCWCKGP9E5C6yM+pjFD91AxMR8UtY1D
a2dbMjPPJc9j9FEkO4toWwhZNNwMtSAqIaHDhKilnI1Pj7JS69WNfyL6qT4KdHXumdIRw4+Fq5+R
UHMqPusIkjV78mVWQnRdiK09UhaSdQVZveJw8D83yQqtlVoXToehkZf6KjWzYyQ2/hpoXvS2i8jl
GhvaF0YRq3XAkasJD65Wa7rPLjIxh02oVo9EXgYEefEJ9OS9jmUEAbvdJMogyC285LDrH5z5LwOL
ei78LgZVK0I6dMr5Iz9gzOP4ei4GFhc6E85yxZfQzEmnwLV3foG1NZmGj1nQ0BGFHySPICXWnA1b
GXCGqH3bNsTONCVIHHkVnAoV2xW5A154/Y0A8SboW2Bj6nzciMhlMK06Wa8J4Y5JrphbGF5ctUdU
oodHya+BOGkNGByI9aJnRPhsjaideoUqTMuBrBpUpinJz4NhrBtj6IThliR/EbH2aTA2F2ZN6jZS
8K7FFXQehtm8CaQjrcwV+6iyG8QXYn6NKweKgcl7VtHKyLkvuBmE4Smh2mqJrZnaMmWxCUHLiryR
BWu+RTaX1pF3h0Jx5JKitwb7jNkhYcAc3J9GqnplsYFt2QSliM2S8DQ2KsaU8Pyx2nyUrP0tGC5H
A2d0R3wd/hIhIIapgxUx1WMNCdiuIDKzyxOk/wBmAcn4H24y2Ns6HKiGbKL4EpgfnShu2DslsTIJ
YbEbUERMMoJzgx4SOoXVn2IolRPBtHAg9wo2TQ7NoyMN4MpBm2ZhoU2wlBTLLQ8xaxZOfAvoLcMv
KF1FIcX3Bw8PJ9ZASQDFgyLW8DXps6bTCZLBINHij6u37ErMRmD4NDMEjRokouREUbhvkUJ/YHp0
bCeNOiZW030ZgzzSjXXtmQZKkNvDRwNDumoPIFZwLADWzVHzOjGaY2LdV+xs55Mx/oZcsyGBTypn
jLLZyPQbaMDwN4+FG2mmJtsXufBjIK6MWDNUejwbFEJWzkzAUNaGMd5+DTY2bcK+FybGCxF02N+B
j0YLmjj9/K5E2jaM5MH2+xQNFB5mZg4McngWMC2JkhvjJT52PIv6KYRt5DdjBujd+SanKZjZGzJL
8CiYMMT7Gkx5FyiNjZhoeA8YE+h4GOCX2EzogsGAiI0YGGl7F8F1m8jgbh2JZGk5k2y6ZKdixMOa
TsNEi7Lhai6/8DeX0P3w5JAqVKXZQqnxiiR5GrISvBlMwWZ10NrLK5+IXW38S7NjZL4Jwaez/Rp0
l2RTBkPKOzY9WDw3A5MisronMseGxJiVkWdFsgxbNfBZ9miUitIK+2h8WoZS+Lb+jQrWynBsaDau
hLJtgk4MtE5DDWMyLhFhTSIKmUMcmoM4+RZy2ZGqxIeTAxRHJsf34Thulyaz8HSN0aHFECBduVHc
oyNLRtU6K/QQ52Qo4GLVrBWjSjUEQ27I9/PQubBX/di7afCH1vSHeNMWmq7QQh9DZ0HkXI6Emj7/
AMBEDEzzmlFfxcs4s6uxRVRs5apmypzR/HAYoGjmSRa+gwwahRlptpMW/wDrzF2VEKZVDlzlirFT
PkVQCIFG6KgfRLMDaY2mBRA+9CpangQ8AwkshVYS6GORCMSsTV6NvyNvRHgaHjBRlIWCNOmXswkK
IxcEwLrRx0/g9CUGrz8SRobOBB1lUvL4RfBUi/HBPHw1WQZRsiYMY+TE4ymvkdPISrRZ9FVNi2eQ
4aGMCuclFj4UcDpwLR7ZqIPLVEoLk0bvwMn8aX2L7DWRc4NM2hN1D5D0SKsetDyR57Eyo2LZTfgk
To8BaJyVdE25Ll6KBkiWfsfvzwaSkI/75NA4MW6JeMNQrF2+hUgI8+wmksFzBzZnaXDGyNCrpu6F
uqa4Y99wPM2zCxRtaMXwiLDQS2+mUQ2GHUJJwJrTHhJC3LDXysl4GozejVuNmCa+hOm5LyYX3PQM
HmoQ/CCW0zY4jjRAzl6jONhSdB6ZOKKOBBHedoa6EP7hIa0MJSi0kbSkhjoRCMOQF1MJJtCWqvRc
J4OSCMQT+5djsDoptZH2NUNtXwaEHlxijqY6Gp1pWQlzaxFppP8ADUZxRzX5E3ULHe4/3oe5mc6D
qMSiGIbFsQq+4wPEcqREKy6M1TrFVBdds8ipFkKLsV5To68WzK1bE3COad2NTqNz6GpM0VkqxC54
sQ230mLU0q4Ix7nQm14U0S7MVjTbcGtngwLM30yUcvUILlyXDL7UQ5NlNcEMnTQwlvkRNJlM0lFk
fBSrRFeFXQqKbsZicD762hWfoNobxpm2mSFRFaIK6ekyXEwsS5yFLJuqcHPDyyIVbm0HyJ8cC+nZ
5HgBQiz/AMmHBrgXVv8AkIdhNwcsJoU3uhiC9D0ZAxVzFf6Kv2TH0SdWF+6T1+iHtJJLpk02xDQ3
YOhTmIT3FGuRaG8FF0X7OM7G0KJ6N4LorY1ORvNL9hqJ1ZNi0JwexhewpwVP2RCHK+PY0Muh9NiD
8I3obnk2zRQ8fB5K5PQTGqJ/CjuRFyeAuRG8C3keSBKkGXCHcFOCuEZySFuxkaVNjy9FNvQ1HoWE
yH4+Eodmvh0NCZXJoTAo6PKFMENsPIhKJ8k0N0j+Aj+KqR9zEVceiMwZMZPy0bGVQZoEdcPDJZNh
C6nf4X9U/hxJgG97XZjPyN3mKhgYMrwVIoYF4LQ6UbhBoh+s24Yi4GI4UK6FH3FJj2XSZvQ/uGt4
Qt2IQ+EtBZiZSzgkrd8r4Qbq03Ipk15iE3dIOEpGM4RjJXAg7MBZSDI3itaHUrsgozw1MclGiiE8
18WB0nvOTUgSHpQUJvA3OiyQxzLfHQ+OKGSoRuVLhCokNaHzMXkYz4sBCJGKap5QwxYJ8MBTLngs
GyEVYxQI8AWlRp6pPafCKyEEbhzTM9MYVLEFIJ6Qma9h5QlwcoPk9aMxKdiVIeBPaSJkanRuPA66
XOg1SnwGqB0UaJorbX0NClfJjxt8cmELtBuXsNCk1Ly2dakRQTWYO3CjNa7kW8oMgxjj7EstdDo2
5gNrPUmYzjvBhMV5Ekf0MHMZLLdiNbiLaKyMmIYtifYyqQarmDZJyNYZQlGRulljcPAWVp86Qr6Q
WxV/gWNkTrfYkOQXfzLFVGTYOVlRikW8ismPdEsck9FBX43aOtKnGQ7Bq3saHuFe8yK1sY9IU/Bj
yOHQtyYP+isw0vQtk+iGNGWQ7hZ2Yp0YuU1UkNs1zgW3xGc6ezPMbozaJkvg0GhSFvA3kmDwNT4X
weVDWhkXRrC1a+EjTHoosYI58LI04OCmOhLJOyHA1IyDjQ1BK+R5CTo+BjQoORfArTOIIRi+nywH
rE4dPkGrMBuK/CYtyOnr4JBuITx8RvJyPKFoycJCuYEhi4FOd/Bp5hOTnwN8D0Z6R5aGyvRI27DB
NIyyPQVtrBobEY+434h0+KIWIqJTMnAyI7ke6PIut6TGyRa214g8FvwcaQZVmzELjt0WIz0bHRSP
jYtcnI/oJj4XpjKOhWTwPSDwIgzqKhvTYxreniYhgS3uYGbFCRRiAoxDEovI2ypeRhB6sQebbyIQ
ZhszS7ejDeEVyYY7ByxZLjiCuhZDkQSdlc0X8Y0QLoZXZiNjyPrBENjXkYUby5CSZBbDyFszfIl1
mtMSQe0GWG3Yxun2YL2RGBmZR7ETHkL9ULhCppI8BlTWfY1sPRkWlHcMeHUYfoJrZQokXcV9hcGs
PRQWPNji+pGj1YKa+mYOCHM5RsF6LMSM4jOp8JiWhMeszp6EuCFmjTC7qHFmmUzFZqBkq25TZcNF
xxXFGlri/ok8IwGXsYmCCKNyxt0k56ovgbHPL0IZYrgZrYaRgPIx1FchRStfI9DKye2LubbSZmG3
ENQuggQwsJjg0mENIxoNitDJp6hk0jOCCNNeRu1RBFeToZjNyhFRYCoTIhjdCEqZlJ/Bim/ecClz
hMYnDwuDLxO5KJRVPIhF0sG9dGOEuS7pdBaeDGw6UEfk5f4OZqKNKoQg21Byom9FiYryQupClrWz
ImNn0JXw0cWLSOE6NQy4XBJ/YkbMEPvQzSmkI0N8CVRseytjuDYnhi0Wi2N4omPgnkezstCow8Oi
EiEZ7+IvZwIg8i1Da2Op/LEM0ufjjyPQjfHwboWRt/FG1rPZkQ8EzSPgUPJWzyHs/wBGoIRsUMlJ
0wcIWEJGEOB+oZMGP4tP4wfkcMT4L8bRjaTOeywWpDeBZcmBpCyhClvImVgarI1Y0Hkc2RYEpURG
CuTY4aGSlOxBzk6Ubq+aMb3MYTJZGuDWbMBf0LUisRPQhdyKZiiNvZiQs3JoK0hrMpwcUgqV4xEW
FA3WFz8da71nIyzcxHteLCixkVtjE+lhiAmrDec+w/8ARjij6HW21ErKvEKmGRlhG52Lzlh0X1Qc
jzSyf3FQLIUmFnYnk69jdJ9C5fFyI/tCLjUJmPYxOWmmB1IsG1lY8CHWGskiwpv0I4UWCj/UM1p5
IgS4Zr3ItSnbJpguCafx2RjyJ0ZVNUEIBIhpDrK9BP64qmYLc4ih07UXpPA722xCarJkIGRGvQZJ
j0xflBZMPwKluvoUotFy7YnTRXwPNqMpJq+iFbkwoqskg0E82xv3/R+bX2QXMQyJMvsYDRRmhzSz
EZGYYsnTLNSjo2dAjhZThD6ZNwuDX6Ku6sVt3J0OalnlkaRLwK1p5MS4pH+qJmEdt2Ix0vkRk8Ue
zDsxheRddB1htnaYkIyehZUN+FwsuzGrUVmplxLddl2UtBDIxk67Q8IK98F1aXkO+mxaTEJvSzgk
XmWIya5INco9FALLrNmiE8ClaGJ2LlmDsX0E5EryjELjnY1w+mTcxioXeRgclg8iKD22cnKqjriu
ehDmZpmlYqbRseEJYI20JPZTkmTb40LQlHk2yEViqGqxJiTIxL4MhzIrkU4GxD2hNQqRyQ5nw1WK
r8ENE5KhJ2/G1fjNU1FGH8NZF4Cwqdob4EqxItFtCEKFgwx3gTNnZHYpLsTcQ3kTJUPMPZDuPI8e
QiGno56GjNDwJYo1eBZxII0hwGuRHIx2/iU8Oik1gz8iySGR2NuF7P8ARmrWlTY1Wjw8b9EtFk05
QwrZMfPYjPvgR48UxnKkTuVexgeaexpoi4Y123sQl0J+CNXaXCM67XY6jwowbynQ+XHhBrWBwoPz
HfCMdvRmXMj8jMibWihjUX8MoWgirL+JrpCbMfDG58n+QUft3mi23NJB5gmfmGgRJKbERoJOSHTN
BrCsOmMi8MQ11p6HLiK0qCyUgcCzOwQaDdNjUcLrBHeROqWBKk/oexj9lLow3ZAnWCdF9Mp4Mq5M
VIOeFY9tnoWmChIcxEcTDumyDLhjIqK/TP8AtIZmMVi8HBK9lzb0XkDa6NcN/Gg3IfQfNyY410P0
RlLaJzaCGBCQq/ZRJuPAjbknwV0ZrIG2V+AjMpcJ8DMoR9xuZ4D/ALGNK2aWQSps9G/m6fYFsm6I
a69jk28lQzuIlcUVP7K56fhjRt8GM80/DEDVRPlryZ4/cIGme5TRZPd9CsYjmJ2JxZNDS1d4ptlF
ZeBPo6pvVHAjKbd9k6m/7NqxxWs+mK8sdjDRt+jhZ/NjI3fsy1NUhdUdt5byMYqw6a5TLZv7GZH9
my5EXE6XTIHm2x058I3pY7G0TPv8K0mYkyjYtOQ0+hqD4Au9BuRDenP/AOQc5l7Emtm4mg9JeYNm
C+DXYscDEjO9I2DL3886INsP0I61fReyHmV+jDP6hsX9joWVJm3B9z0PZGheBQ6sWNt1Oz2YgqNG
nDdWh7QVBNGGSErwbceEQSX0OeJElTQTbF6HalkT5BuW+h80xPyVfkptrE2X2FuG62MLH0PbsJKr
fyhvh9j+AIyfAh1Ni908iRzkY8SyZT7DMlBNQe8CoX4bIxdBl+K2VGmaIswkh8GsmPNRNRt7FhOI
I4LcqDWPIkSGh+CxIfHRXgTZD6NGbzAuxrQgpK/CSV5UyLaCLsKIJ0ZeV8Yaq09D5DRkHgQ5RX/g
TIK68SYZm6wMXEKQYo9QbXBHI2Sh4ltLcjNrwQyVjSPAauJBZC1OMSA2PKIPAb9hZSQnSiAwyrUK
xLAhtFHL6P0QawY2+iPag5C37JkkYgKzNLhHc/4bmJvljNKOjRckIeIiOTRjLCE4XiOT55+IvrGZ
eIbEVRsPBS7H3zHvRKJEiWXAvsrookwUx8wSXqPhnEcjt4wPx6KGpIOsNwcmY9lG1GLZOsRtNCmJ
CNVvZZRS1CUk9hIG/Q922dUQJbCfQ2MNzUnsQy/jY0P4meLPRJQk2twnGTfQjLQo8FP0NkUmZvo2
rnge8HKBGhEWaNj/AIZMrmGQGMaZwqM5q2Q6LwIZm/oNdWBfkXCDtLgsryLGWZMSdfA5TbRorkHO
h/aekIy/sVV5vIth6Q3iGocZMMUF0O7gsC3KcwPpWbogE/IjufZxYOKC4/wPpYnJh5TeB0GyE+Vt
jfOBBhTUhbWhujZ+UXynfBZoaRAWcRkKec4JF4nsTX/mEBKBYnGqs5FRpx3GlWTwxyBseB8ZLB1X
JzcrgsKvY2pOiVgSp20YIzZyQYzSxuDRE/A9K2HjezYsJKJXjtnPWOBsaamIhXZPA8q47qFf0lwh
MU2ahgdYQdOuBIeJ3A9aQxPJ5UIgcUnUdH7ECKqmwwR0IT59ByU1yPn22IV7oy30cPxbC9BVnsnb
IJPGG02xG49JJ0kOadpwcuqEOiFuPI6DM4eVvsjWdPGRFrTOqIfkRMGWP2pVD1UmsuzLkmoxTVKh
K/oRkPTZZju3NDbzPgV0ugwpgpwqNGPFgyUbYVH6hExMqD9sUcFclMAvPFPBfpxIIUmRtDiHlIn8
iPcNEfmGf5Fjcy8HR6z8HYqmLCI9mxuxcgobyVDmEQTZlkH8M2MYU8lH00U+ERmduBpPPB2V0Nlr
NkIcrAbWktbGZuRfirRwlHklkUvy2LBbnI92QaDXPfwnKONjFLh34NtDFN50fRsVyMqMvCUeEWC4
MIKn9FeLqmmOmRV7bwWhG/Ro6oWsjyJQBVInZgbwIVZxNEjX2M5Zu02GJDdBdZ7lodoab8CCDnun
wgjlSo0kS8kLoJBAqTgLelUPzZ/A1WFaJPXcjU4xHU9oq0y5L6jXgbNUl6IJl0eIShLRiD7FQsHB
JSi2fYm5FGDxGEO2RpaZeIn4KepkrOS0Kmpy1wJyE3Lope9fCWzwI7GTDEsCQ0OmRWRQGJms5gk2
rwoTxeBihLl5FYPei+LMFqnbg8txubF37CImg4Jq2MuhYRgAvM0PsVQajhnKYWNoVfKTqAhzkDXn
JhZx4GZAtnkjTcj6pl8dCUojZ8mO4OBTydF2IJ2DAmew0jCH4Q7zVGFx3awOEywW3gDIVREaMpLc
wbtPAX2xXbHKrMNI5mxheychA0xiDSDhoJLmG8iNE5HY9v78EJkq9oYWQ3RPLqyhGFlKui20lQxH
EEsoUtkxmINK/sW9OWHSQ6eBur4DplTi8FCjf2MH7xHULSMu/twE3AtGpVFySE+sseB9SAy1d30E
MlVE8rUg49dj/hqxIQ+Q+KY1MFNbHI3DKMFPY30INKm03tinknSF00JKNM53o7cDZhXYvI7wSGgW
f3BJqNNK0R5vkqX2VjK6nRg/DNJJ5QjNaJ3IueW4HaBpqzhD2cQRIrGkmjWAUXgqF0YGbP4BHZp4
2MVWBBlxoUeRlE9ycvwZIoUYwAzAyqOx0Pgd0YkSZ1OPa1m+6fIqnNQwN5P4KU04CXdush6DWjUS
aZeuGTpRHLozPZcj9iJfwU5x06M/Pt42VDBsSdXleQ8/JMs2hCX0YItCcQYQvRRWjzrBj6wXkjXU
bjOzYusiXno5xHUOlZMKlFpRi1C7vLGOl5D2+R5FUorZRDGVJWj/ALqmK5xRiaNQ/A+hYmfRipn2
UlFx2PRU8TngghFcCGul/wCGg3huD20MtN8oq8PM8Df7DFU0BrLKc8wRPKUTny12Ezg4+Dw8iZIA
scWpTHRjjMCF3wNBi2iQbBHEkYFpxBU0+WJTfYoSsYYO1dDsYLLF8IfmUMjmuA34jrPIsQ3Cxnk9
C47LfBn7ODAU1okrvAmbrZsQm3hpFx/QKQuAU+nAVuuxZg33OPIxWBJi1+AlyFhm0vYy3KYjUMJj
YE3cXZMe2CUwyQ2HDvyJaPwZ4xHshtQs7wIkrujppDXMW60GfuPctfZA+xKjTGE2wl0qLZhPBQdg
xvKY0tqphYmMZuI9qC8DBsKYkOYOReRUiecFLTjYmsE1ZbEQ+xhBnYTZxDQtlFgwUizYslwOvfLG
IxzJi6MMGzhLAmRg2hVRhJwYYoxlB59h3bW1oe5NOgjWxNEFiOSVpjgQR6UxcXYyDJMlspuiNE6M
pMsS5QwJWyxRFbwyxhpaovAbCp+RmC6gQXEeCicuAq9AaT5DTijZafku0nsIBNJ9Dlgk2kSsEMST
mOjFnAlW7uBcJBudYI4lzEcG5GBCucE0XgIz6E9dzRSS6YlLunDpweHrDFbgmuGwlUZadNLwLZem
UdJ0I4+lG4Z9CvaY1W34GGD6CLRqIveLkWezZVbLLHFrnoTyd9kobWzn4l92dF+6WcsfBIcpGAuT
wyByRUtF1OGTmgilLWC4M7hktqUxrs2SBISrcxgRjGQ9bgIZ0M5egnWcKoSQZEosGpB2NEQ2x2aJ
tWNpRn2RUzka7NW1yfIyboYU1Nc7MP0Kj1yZw2Iars0lRaGt0GyPtVOwq8XpD5HIxWwsCcEmazWT
QMNwoKNkktPBGyLQaysOC8CcrYcGsjgnGOESRiifDIGLJbfZRbIwSoKbQ8pKcSSjGpHMaMEWdjGI
iUKXu1swHiRUdcGMgqOHo8oEajs21YMazySv6Jqb5aFQxogi8l8GF7kMbLSilB61tC7a1SXFZx6E
0uTbDkekwQz8dhJ5+gVSRgecVWBHo/5CQTu9sGLCjiIL58gW/QQjlJr/AISfNFRp/mYCHClLAx0u
ix+OoaNi7x6Hqu1/1jWSB/0wmLYnn4/d0bI3GHizBIMoNuUZ9Q54ZMEaEOR8Fa6w6E84Fq0085tS
JqcmzSi1ThgaeI2zIiVMiMsNOfIPkxhNWDa6MNIucmyZJkezE0U/Xw6k2hkyIc29iAjwMry0XIeK
fJQPDQZOI0oaF5DsMFcvmdNkRcE35LRfQtoxeTPVIix7SoTVG15Hqp/xFWm7giS9Bp3FBwRsFYWG
IKugZ3wF07yZtpMmIQXTTvRWUqz22M40EJbYr+4SJBA08GRGSPa2yStEsaIe1eePQiplwOXQSed3
ItPYiabOxuPOBrLaCrh2Fbu0RO82YFp7OQ2yYB9DBVNhoZtPsVxuJwZOrZW3Ry8BPTeBliNxjm5s
OG9D+BtRuQHLa5EIiYqxJq+xhcLWYClEuhqWylQJHWfWngbwEME8lA5wx3y1eBBtTZ2K0aGzdROe
TZYoq5g3Or2VnafI+j5EBQwhbiiHqmD03gyNvmNtB6Epj+xwgzqRbDmpW8xqZp7GwtzRtDhbhZWx
48iDzGvwJ19DRcWk0J9rG0OztxIh3Vsxh57GTGhhEYvsP5z8kg9jqXSFR3gd4mEbTZinbZ7ACPYo
B9D6LeB0Unk3fNlpIsqC6022IWlnQekr8ubPqLguhpDyUg+J2kH08xPPBUy1hCjg0+DVGoJ9FSRG
rFxAT/8AhGD+whQJc0lZ4y7bGnCVNE0JhbBzanI/4qsbZzGByw1tYIbajp2ZHqiYWRX5j2rHILtq
k4Hi9DJJjCoYid2aPJd4Y0eFLA0bnA8KqVUKHNp88CLPDUVsJkNn48TyFhibWwXsgs2KR8hhGFl9
CYBatHdODeJ+CRwoe6aZ5EiRJnYtM+o1rNWOhxMj9mIgyfuDo0UcM1llKJGPyMbfCDrFqoW7tjFK
9Tmhp03xSJ0IPu5IeWpyDGp8j3ySDHm5YleDZZFN9DYDWCNbX6HCJA5HLKQa9ZvA9mGnGm8iPgBF
itbVO8DcadMO7RlBElIlqQUDNMK76A8j59NCFMf/AENmlB7M86lrLW1C+BdtVa/rHLY3kbfQ1mmw
ubCuhavI03sZOjEPU4IqJrK8krJglo17JxI/0UisN5fQps26ZCvMaty2IcyiycQi75TpNbwuRfhi
kucja01yLdNDz8Dw/hGNTInjRlpJl1RsT5ImaJfQpmypcYwhKZotzLpK8xS04DD2xK4x+XBiFrRs
viVhbWvjVWWrilJhEU3ocwrs3L8KiM9kWbOF8SO8gpQrS0J7S0RlyYG/vgMOslfa8hDCAziPyJOd
SUzIIs05wMjYS9lSp+TtCFHY1kTIQpcrGyc7uRI04oijNdnB90YO+R6DvSOGfoUmF4MgciVPXgVx
kWBagasmcC1j1F2CP3iBUrxRSfmY+DQ5yUU11TPiko7x5Kq8iPkj2mWh1YCI04j8lYib/R3UJwYl
GpEYRjrlCghtZE80SfBE3Ye1k8ic7bgZRW2E0/qOTyTF6DiCpuD77GOvxohxKxOl2S8/GijRkIWL
Xka09YbmG/DJwpoiQ+mOO90Y5HRDJLyMpwNmka1OUWgH+CTb+BvZjYzC0jHk0Wn5aFpg0MVf5hPg
jeQkjSnxQoidMj0NoHzRDMFtUdeSeoSCnXyKihrHIqsFWbKpJS0hDOqXZTjXA2tx5sbYtsQdW1s3
5LjcDNe5JiLUcMTVqbD9aA/qXt5FxLxMq9mD4sxWaSa0mY9UnNEjtIPjccoYrYfY/eJNCHGVhdmW
7Ey6Sii9Jh+8kxBvWNMUMleGY97ZaNBBIP8AhuG85INo8GOLDeowQvOW+xSbOCxN7YFNVPkxigzo
xtR06QoIb7V85K9qZ9FlXBIkJjN8hrbyNaxPPwa8KyFDw2iMBXyJwZtoglf1E2IYnY5tcwY/1cJM
JmITS9P0RqT0ujKL3kNlK7j4TQUraWGhqEGfQAUyqvLK2rS1G6/Jf5r+Gf6NUe8dJDk8PsYmEoND
a+zZLAtc0uvIiKRdqQVIG1uuWWNLlNrsRsO3eCbPprLKRpTdEjCKRkjRfDt2jF+S4N/Mmla9MVqp
uR8m63HyS7oH1PyITfvEx9iXkw0NuR9bY7KLY2pUXI8OvnlDNbJtejJHt02pciyKpgWOB78YZB2I
0wHrQdvRbNjaehUQMYKc8FB7+Z0wlXCOSOA28I8GIT0ZBNBYWQ163zSxLhCSNmEpnZcociPY86OT
CWxaNGEh5ZRRLK6HnCGX8CRjvM5WYzSXIxpY4ITFej83B9pRd1whhR9i3e6esMY1JLQyvZBjbXRp
HAm7PJOHtYJKpTGh+CjHoTcb6G1Vz6LqdRnNjFPCFkSJ9iNy3sX5bTomZXhnFoWm6GaYawXDfxoL
xn2Qrx9jypPQ9C74EVJMYpGv7OWNF19JYHJmRoS5X7Pw4lbu+zMyg1Jl/ouG2qJuPIkP9JLdRjSt
nb4oIR8eSilPwHNsXqCf6YxYPiifnPJJdm+iDeI20N7LNf8AulbZ0G1fImtjLpkIscv9v4jY/wDh
n/tI9NGNiRWAoal/o8iFUYiA+ymdTMcWT9EB768szGwq8alFlcF5g4f3Nx0yjX3KGMZCSMNmgUcg
4gpifLHtY24tDLCM5HtsvRjK8OxhZTmTT03KI437FM9jxS6MdlSzyQrkfs2+ezMJ5Fb+kfcAfwkx
JVwmUmdO2UVjTMy5TNaP2KcnsO+zHw9MePj9jdlCSi9QVWTfdFMY55G9ifaR2o/ajBk0tDjHHnJm
In9D0aSkymvZcIUldHyCm0yAfrI3s00HNkfBVn3C8ti/TYM5xBday5SMVx0bfZvoLB+iH2nV7FaE
gt14RidCnCrFpTV6Fta16FIaguxI2OcIjI18cQHlb6IwF3r4MojYhwvMExPZfPwMR3OyGILBngHI
65YnnI6wGzeweQ8DHiMlZpdDq9vYyQSaBzA2Nma9RTn3QytJkbBCfQLsfYNeyaLNXCrVIbqmCr2L
rN6HYaMQilTCwuHBt1G9mhfg55EFoYMG++Bin+IjfAgocuIchm6Y7kT8HA8iK/gjodw+hrJC4Z/c
kQ4wcSCSwR/rGyOYSRUXg8b9D5LHU9YZm4+gJkaLYw2xZEtoQ9xJFotJUJQwnkh+SQP/AKjZhgTy
JU3JbZBl2HxNRkuFw8OhomBggWIiIwmPkJI2WllLsekyWCS2hluhSC+GOn0YUE6MLZDkTRcFkkay
E38BV0Gxg3TkTG1kbQ4MMqg0SVDwgVFm2b8GYIm0sDGTIxTaghghGtfBRIyfRScFlUEPeOCXQ6pr
IlWhTg4i2ScF1V8oa1Zl8DVxY7HGTIw+GiwwrQOmiFZFbG4m2soZ5bXY6pZJww+So9RakTiThYLP
QtPQW7zJ+NjXNdDknTQzG1CWB0iGBJM4IA7TBVfQftp4MlFaIyMm7LtDOyZHQwwZWNA+yKKrkUWV
9WirqdETeAjB0hza9lpWRxXQKuuLoZlU3TNcmdCdMKnyZKzyhmwNsTf4xnffImHHiJ+BCGtcjIQ4
wQumFIcfOBu9BYEFNxRaSZrbRjredDZLyg9EaeSTxlocmwCASwyemn32aOLeBAVsl5XsVzX/AAwJ
tiwB7NNVwJeaCiwwvo8o2Z4A5jtHW5JXSXAvrJDguyWjso9ITm9VyP8AsGS3lNBy3pHR9AVSurYK
AogphtE2SKmEYOHZmfIFY1feKVuT0jHgQIftqG94vG4hdsWDPV2EWF8Is3YtEFKsjWUn2Rw/IlN5
KKU0g00zzpF5uDyhLRgkMf8A2EJaloPLjqmZiVPJiqdi0WxYxORlbUEE6RLI8Fk8HKZIOYxQcAZb
HKPztB07gPJU3+BndOGKUa2NxUbYj5H3FyTsQ4TRroVnLGKjkmIolTROXH9DGbvwR0SiR9RGslhm
r45IA0mK2n/JvHVeC1VkFIgsYvjWyDdEZZYIiZrUMVjEw89Ge2tuiTGYTbG+mJDV4yRl0XHPJA+k
J0thdkQrBaUSNOMcBbxcCM1fLeht2NExkWzKZrEGJmGekJnWTYFicNsoo1WKBg5FhIabJRg5NJVZ
BPGmN1E5SwPZVuJsRzAh0qxiy3oy5XJ1MQteSPkV6OT8mSwHyZgxRC/CC7LghyLMFs8RqMthHgg7
ZHciWD7sB4ZQv8mDlJdMlllFOoxELgXJioYuxvOBLhoV0jybPU6wK92HKTQRAhUsWInpESFlppg1
QrcMFvOCKo0alBB/wBdYiQmTpJsposHDEUX9QpqwMdgW1R1cHlYIjUkO1DLwZ3q6xhJVPA1Qumha
QqJVT7CgllB5XhcHC0ESSgRaSgqHBjEKS8moK+BpRtcIzkuTat7IPZWIf8AUQtwcw9jWSObDbs7g
9ouBnUbb8KAkkLyWMFoxGPkkkSrJhowkJbmC2O3KQf1fw5Lp4k4GdpMBcbNkO4KFaw9+0YO3kWaa
WX2IGreDd3FGAUClawsIbcZeIIrmxMCWO32PVY2K7SyLdJJrNO/CPwJ/tgiqTPDB9HIx0y5R9nDY
rcie46v7CZYLTGN128rpDgZyZMyGR7ipDmyag0a7zgTM5lBtwduNEJ2cMXrsnImNtfPwYDqp5Ccx
7wR+xRtUM0UXHYjTcqLyFlglVipjFXEEA9hy6XIrvDa8CaYOdnCu6Jhch2rDk1E8UpB4OB+k7ecD
BG7EwNdMTlrfsZ2yLp3YXAylX9sUx2Lg+nqYS8nRPvBoaY3AhRLPAURXAJiJJ3rIy0SqMdVtZ0Ns
CkUZXFGFJzqYaFN/aHZVs15pRRiJDFa1RqmWaxqtWnaJNUMPkUV4t0Q2xgj5HhnXP2Z9WZhY5ilX
ZqISMpJdZKS+3obM8JUdU1bEAlHQS+FE02K4p2DstyFdkwMZFQtMridDCXl0Z7N7dDLviCLWvhGd
xicDAhmVPAWmhEKlIT2Kl2poQOcMTwnYlSmjOAAkSpY4ZI8RO4idzVvY5IVfYVu+96oi7HM3k3Sd
2ISo2Jsjsxt9JF2R20bCVP8ADI7QjLG3mZhioCbgo8s0Ja/ZPkWtGuRLPJX6Oltpn0JwymyOhTK/
SnhF47G2C2k+Czzb+R7iGM6o7jXyPkh9zDxHQkKiUi5PSJRTCGjUBJOcC8gzI0NtGn8S7wRqDrVE
FsrshBXGKuzBrkpSC6sUloW91EJyuCLwVKd8B3Xtu0dm4iNLDwmhU75i5tGKWRb4g0eFpdTx7FWw
ryNE3RRkqM13kTo0OBdifkyfxyn4P+yKdoV2UW3U0JJ4cwOxZrLiyBoA7nY2dwYixSHE+Ql1c8lP
+pn+IOCtQus7iFQnJlNSfRK4TLAq6LiuCfvKEUe9UUhK40SSeEPpba5QsU9nBVJHYXUU4L7IBsyN
lpCmpdnoEfYhEYwK8YgW3sUHtQWpLgkDGg/xh52DToqSXJ0u9d0md1SXLnZjHnAnpwQRRcTGBTZQ
g1MbEWcitewQ67pNKuBXCbEpbC5dpgWtStoY3cHzJj9C1eUF5+RSn1FtPsTsj0FJiZwZOtZp0DIc
FNUVULjJnx5ohd3RFyqsCLw1i84FajLcEP7RLk84ERW8C1/gau5hkLbQrmRRktHCOJhNpYbuDNzH
wIVNKrkVF0JPKNSJVos5aghqQka2zzqmQTniOVELKFcwdSiAPnDeluBqjZjH1NPQ1WPkXYaLR9kg
KlekSoghaS8jdrGeBHMrRw14MS6nodJjjkz9lwM1ZLLgfgljBuvYgSlcl+lvAW1glyccRAaiwK3t
KCrmDfkkHAzdC088mJKu+AiXRx/BWGiX8EsR2uDXuKo/Kkcq0oNrVLZ9SovwZzb/AAw8J9mLhGD7
Xhzh6K99Ksx3NqDo10M5YZYFoz0gSUYWzi8kndsZ6gQ68DlM5ejOZzJk5M7KY+AoqPpUkwYirqnp
2g1RPY6HA4hxjRCRf/Mnui/4NiimRl3BF2VGhxsxWOjhpfZh2lyY4Yaq0Wkz/wCZq/AtJU+eS9tJ
0v0+mOJo7sVK3AI8DyCXWmBfY7ZTTVgztmIm3hJiTMZp2IqhCgJ1a26HyE+Bm1oxTisMxITTSgTO
2UvCYq5G8SNpBP5T9HXrtTcUJD7E6jqSFVNLBAwkk99DlfOokkaDurPPYybbUj+zQoHWiQNgo4gG
q8klxnJT+GMGWvjz0Ivv4kLNxC2WcZGNx5ITexDNwNkyiTwKauiMPh0GjnlRsWZgz7Ah71g+hyTH
CezIS0FjdmXImBIcCdNymgs0WGT9Zg8jvApv2LvTMycp6N4+BsNsR3uxprzkOlm5FO1VNXrsQlbw
yPMwLYrSVhDRN5FQFoaoS9A2HF+SwkRrQilzgdLmUQZ70MzPA8i8M8hNkbmJwGqcxuDlBcGoi4kx
qdPwdUcFq3YxmoY7JEya20sikJlQQlvIzVeITTozq/6IIjmigbk6QElvQ626ZZUypsffERGSWEnw
dIN5ZJ3zQzWSYiolGIYabEJazgvYs7JqbiFJRNh+Q1tuKlB0Mz1OArkTU3hiHyDpRpmkjxBLPXWd
uhxV1TEDeSm7skYka7o8ngYVtC6dCGZtSQ72EJqsGxMT0mV15Zl7MVZSgzJWUiKT4yPqYzlDFrNp
CyT2PNHBb7QzFpQOnM6hK9V0Fq3MDJ8VQaG5CCNtAqbM8hXipcVnMQeTlUbIytBCHlWw2xnarWJC
Et8IPCcoyNhY2eRUG89hun0WnwgjdPtHZKvTG28BKViEBpN0VFMXynRaVLDQdrcMQ3ulkK6tn0L1
GspTe+hSIi/RJRvkcpSk52fz4SnOiNwouINdd0LVV1gR1tsRXAs+xeYx0YtB4jaHg/QcpLih2a3w
IpslXRY2hKLkY4WeGQVYIMF6XBzlGiCwwngrkYU/WGVg4SGtpl8CIbcDwhlltkurJkSO9liu44H8
1uw6L1EFpRmWuBmVSeA84wrZacyYtk4thZF5p4Jjoy1wInpubJCTwRZF0YEzzARDTCSmEYcMYK6R
7UUMEP8AgDIimY/eVIQXTkfRtPb8wpqjCQSNtDj/ALeB1XJ2Tlw0JrkuIfy8tFkzHGcEk630JRnN
wzd7/EO+jBmcBGuzIkdyEqhwTsZkZwn/AAwbYRdtECwy1aM+3lrhC3PSGSSxPxRnLwXQ32OwQDFh
SZwpQjZVmo08bodPNjR6YAZfSmmy16giYz2Nb+h9I2kCcz0N9AgrigFMFRf022x1wImBZDPsxY6x
sZ/QY3Ctc8sRtbr4mNXFNiodnCDNPH6J1mYI3AS4jYmYiazgMuZPBEW1BIdvAlULKJnQ8EhrHum2
iRkrJaLgIXFM8aOhZag1kSg/2HwHEgbPZ9MUZmyN8KAx5WEwa17FtlYeWpEZwzwbSIfqGf5kLgwx
o7CybXC1kUsmKXDad7GmCLgYdn+F8qijMoaNTolLS+RQ4c4zB4jSi4Fry2GZI0sQftivJS2USSWY
oUc1XCHxyHtUg6NRYFZGnopqrGjICbMz2YFluAaAZ4QmFINc8GFeBwHligpXomwi5IY03suuwXee
3IhUDpj7a0PdHg2dZcRqNQYRq80q7V8sfkmLaXhy0NM8XgYkyU0MrlkmAhuWJPsi/wCpssOYz+Pi
w8tgV4Sy4KYSwOPfCyMcYg8hUoQzKcC+m06ZabsfgkHVIm8Uej17K/UMxsh7Gg+IIhI2WBFWKMk3
a+MlXvmXLnlodchZh7ahJwWIzCTHYg+kGm0FPOEpgmhG8SG5B8DFB1oVh4Ynhan60bpY48jwVDLJ
Q+YylN5G192JwFh0zvgiRYwQd0fHxAYanfIrwhxR9VXNMBkxEhLyOnTdEaZCKnJkmFTGUbLekWp1
UyXSsmqIqu8xluGojhaqUbOgOqOypw6C81b5Z3FzGX9RaYUkJJjyieSR6mmKHThjzNATS9wxWBWm
shc3aQb0nYiC0py/U3Jfm5lD7vYhktayF20QdykSDLa7LFMxX4Qp4wngQgvcOBYfRVwYYwiL8GKd
ZXyIYmio6uK6Hou4+hUubSegzXC8Dc6m2JRDwT90jAxQpleWTDRuEe7ERcZkQ5Gun0eQ2jl7bl4H
BsvkPbuSqjOUVwPW74QfaDzI3tmcK4L2HJ4vPZTt9jeMnGi9JJ8MfBnxyMAjPApMtbZXMTBYYmqQ
oyEadSGY1j+2Gw50RGpoXJqCHMllEL7zq9hOahxTVP5oUmKizyUb6Kj3q3yX6o3lUq2iTOjPXwdD
fGuhnhe4ylWs+BsRwRIFGeBAWKdex1mRs8m0M98GkxDHnNt3kRcOvgRMV4Gdm2TZY55GtlnAnTqc
CEOvBBjXIUngYLTThg6k4l2Y6EeRx7Abth5ZSJvMj3ds6NYbb8CWCb8ZFssUusUdKoopVqHRHJop
K/hG+zZU40fONFrGGnBMj4EsQeHBmp8FX4hvU3YQ3oIPlngRWQtQ3ZfReQMdI4yPTqNHJsbRm2Jz
0D5ZGo3NDs1z2JTM6BlmF7Ko2KmMOKOiMk/I+puic2NWnseNgpIyIS/Y4CaPoYydFa0eyExey5Ki
kw2MXY4yQVENiJJsbEj+3wdc8S0exjO22LOxCziLuX878m1EeCeSqnzzTLGTKU2YJPRnGxAaeUJ8
+5/4kNcoLRehMbGKwVuBg2wyieTaDyYie/sW3RusSXA53nLbGVt/RauRTTaY7NoUGlcfZfy6OtR/
/AjWL7LNb7EBjwQgU5bM4/0SOjyjKz5jIvwMmLDTaMmVvY9to+zQVD5iY82bxeBmbH4Zy2I2yHSk
K8obXZsifYLX3ZjbP42QdrJFdUc9Y0yYYbOuBvsuxqaVOW+eDnyDq0HKSMQ6rG8CWqoPQmVaeiao
J5N83YZt8mGRMwwbvRkV0unP2i3bJsvZo9sMnrauIxvVy9Nmy3kSuT2Ez/zG6Q6bM8mNFlGszpss
o4TeL5TMc/cZhtCS/wD7Rrdv2JwxIUHsvDY2bN7n0mJbeztlA07b6EseLwLU1MpYEf8A9DdZrf38
Du4MzET5RqQY2G6VVL0QwU8Du0QWl7RhfKQ2ab6FyaMBreBbrXgcYQ4Y2YqVOsMygKUPDGDigY9Z
yTLXgrvKFh5wYdJuiq2i++oPGbCU2J2aRc5ER6UmbXsN0mU1CwYF1k6MYlZDWr2O7X5KN4ZXsyT9
PhQZ9mO+KYSstnB6nwDarGBmjI1GaZ5DLRCPWMU/6E7LoIp3hEYfoa5mysatmZa7DrexvB9FMYNi
vnXw2vA38fK5G45yKlEIMu0I7di8ic2Oi1yLqnkcVWUKRtY6g7qkYVkfzpE+Azu0Ez7jswxaQyZG
sGCdjxEjTEbG0mM6Ila6OCoWxjQhyIvlGh/hOLZdaFwJCCQisx+BMNM0F0UHMPtGPL9EYtdm6Qrk
XmGd1sIrQgxj4Hu0Khksr9Laon5EGo3MHpayExWApI3wPWT2Oz0JdIrfPAjeRDXa0JyYesRWVbJu
3R6E8KKe9pwJFIOeguaOWBrga1aQ/gXbl6K39SFwfJ0irwQzlB6bTUYk05wYuHSHtCR25yJ0XmPJ
vo8IFqhYNU7L4RbJgq6dK0dfY7KfRApHoi2NCEM2+jK7WBcBtuEpLYc2sNi2ZT8TEWEyJ8iEigXw
31K6RCOtWhK3Gz9IBdTREc7sUajkOFBRuXJDjJDX2LlwwBPwHTnsX2DuH6wEanYwzCS0x0AlKMF5
n6ySODVlKkM1HdIbaJUMytF1BiqnpDjLXQnaeVaWi9Bs5joTA8IyOYyOCLiZGrOReOsZFYMT6IEC
rEbI2wTLCiMhstjAqlz8KqS2Zlj7LF0hD9R5xoW0gIS1P2EmEpfQmrs9QaUyB0JhpDQntCYt5yLK
C2TFMwo9hqx7Id2z8isiXTEwpcjM2l5FkujsVrmssY6BAf20ODU2RwSopUX+2Bobs8fY2Nt0caY/
7qkzSkwLB9El5N9cXhEtC8iCSxREiSpZIxMnLQnR0qevsx4fseSzIJeTbOx4+M8GPjpoaOnxsXE0
4J+oN+BKZqnILblYow8kxiSrsw0Cuv6NYivgblkps8S2iL+QkQX6ElJOWy+2VU4LiMLyitEvYw6y
08CyW6aE4JhWYvGtBlBrLQqEbTg3k9mMxyyyIU8GbRHnbqL0adDJDJcYuirTQqisfTFhcTCTyi2U
sGAhCS8j/wCSPow0ThfFLYsnIV7Ot4kxknkW4iE3FMjnJrgAcqUI93ExDjmVrLplJUx2diYCxpEv
0cfCDSfspqeihLr7D4LYrTDSPMyDl0smQRjZm4FQzIks1ehrSpNDpuMhdwYo3b5iFhmDGV4FosPZ
guUIdFSZeZzOwi0MBpj0XAbzRRGos7Rh9kNJQWcjIkehWi7pnQjpq21swBa0Yn8AjRkJ4HzRobLf
BMA2SuVwICiLs1iQd0OcE9UaGkySCRwa2MnBx4MiECnOJomOK5GwlSjOWFLeCFyrbYuRJ+RFpZCG
AXnslwUMz00R5KkYvpvNhJKCCK8HmkJZGKBJIYcOiJmjPzHMHPoQy9AoJZYwVBbV0KaqDJpT6FuX
GqgNXj1XBmMHMisySQwDVMLcIeM012ZWCHsMkzHGWxYaS10T+AE8njge8y4wJShJEZpUCBwbEkaR
C6EVmqJb5PowZGls4SShneWKO9rv4eJJaHtw4wNx2mSrCWhydJ5g1NkEpwXIIzstwtyPYS5ZjwcZ
0JasHRUElEl4CG+VbH0skkuUPllMLzcdozWPhGB6aEMZE9BXYoI6rAy00j2X61YJB3ZOS3MiFTS1
Yxt5RLQybxc0hEi0B91U3mmkpoxMJZC1d8BHH7sGjxyKZH4F10uTkgPo04zaVFsFrkLTEGrA3J7B
ea2+xLAWW42hxuORjrWexFdUZN+08YKeiViMs4VkRe1sxS5QWDyKC8qWw0M0+QxcjLhCK0t+BONQ
pfUEFKyxoa4iXoVpJf0FQuuEIsZK2FhU3uJok0ugnJqPaHfgiyU8BR2/roth4FL+SNwpdG846nR9
qFlrMxGORM8BdRitLk+GUf8AOSYYZaHQaRlpRPJlCVLIus5iaeZRg8wjPWikW5RQQXKMAVDSMGkL
f7A2I3d7HDwHXU5D5as3sZZwZPFmOvKWzRpREO5KPk2OeBdTVmVfb0I2ayFp8GewnkpSfRgeYkgn
scBSCjhwaMbsQ0gB8k2vRmQqH6Iy1WuyC55/Rk4X8BoOHIzRYgY9yuB+kH1lg1huxAUEeTYokfg2
iksC/RDq2LFZCLeoZcMqURvKIh8H9COLyz2M51+uh1DqsmT6XJM7OOVrgvkTB0/yyTdqrDOa1JgR
MUr/AKYOOEgyDPBeRLsb+nw8sG1f+mLssoKVCKFtmTgUas20YlzwJUBZ4YHH1tggvAnEoP2cMyka
h8jHLaTHfRHZBaGQK5CfuHUS4LJg2MuTBEceTfwTfRXBPYJVKFN+0LUp0cIEJUdpYGmPhoUv9kKE
10yWOkSOTYtN2hopuhhPr4p55iK7Ept3loajeGcjG3byM0ruGRj00M5GsRCg6N/4OCi3eRyjAhEK
2Rmy0Isay0UvYW/wG6wN6owpYrop6LsaW2mh7JWxMLOTAp4sYuChgdyQYgyRCosCdp5G3IlGcaPd
rB+fsGY0IxSz01Dab4g9ZHfgS6+dDSUVRajbJpPLIhqMXWIeLey7p4Ep5uRWnSEl90OTpOxtMuQU
tqmYe0S/J0RdrIt140Tr6ESatCg8GHFvkRxkHGUVMO9Ieez0Va0IXCCUnkQ9R92EOG08USosuQV0
YIyeMi/KfAnugQ4uBiY3czkd2Ee+F+aqMWzAi2lwLUny8iQ4y9jbrkwqMGLoYt9vSFpbQyJt4DNP
KSLhcUWP45FxWROPst+GImH6KuyyhdBXE2KDZHEJZI6hLAVbZm2cx1VTbyZfgvqf28GN6KLsHuhp
1gZyP+B0uUVInND/ADggmHLDZlKUTZcPYgjGk1tLZAxgMMNorNm4QkpsUZEV2FKt/VwN7ERK7cHN
3Q7hZPLBWXUEmYdX1ehGt+LYq/FsZrSAc77EU/HYxkRcCmo9M1epPRwlrQkY1oWulkK31CAvgZip
twO36Lw1fwPkbFXIbp6MwhJrOdD20JpmZrBEApMGMjZ7exDTzCQy4BZaHTWS8SldGxKykWwmsQeM
EJSxm/4MldaqE4/ZEjHnsT6D0DlNchr2my4iAMoHurYZyBTPIp3NAR5U49Yj2dDe04aJKn/E5ASP
Y0bRLeLgfA0j5HHBWxBzixE1kjnIlWa4GRnMsOQcBS72CbJFiz6oOq7suxLf1HJj6IhaTUjGfCpa
OTjO2dBYcrxLHYpM8k+yQY2kj495IRO9zwgCQliNRbHEkkv6aiL4YZJD9EwLD4Rv4KqYvgbobKJg
2dCOSt6IoGsiUQWeR0TAxJfgOemw3ZNJdklZYkGGX7hyPUTNAXr02IqsF8WEZg/hi9GD6NswxDX0
YKJ7wawJlFZaCco5eF0d0NBZ8E+Jhyk2ijiCQzLsR7DXuWX52hnWHl8CLGz0QNDiQ/0V33ode9hx
IFbGsMTWy5UjwTd5EK98FRwlkwyOU9g02lwLbZwJZcBz9kbgoPCh0KNOfYj48iFhg0xCJ+jdY2ZY
rgUoKk6Jdou7I9S8MXt6nL3oe1lsU1exEyRLgSwIY+SpfSHv6TMOWoJZccmIbCVJZfQaFERciToo
5Uh+Qmr7H7EKrqHyJbHtisGUQdYGC7wcWxtVzRld8jYiOxedzk23vgYYajyvhY/JO1Eu70Qs+d5I
VI2JGZ84HjdeRDvaEnYsOscvQkG8wz1Q+ROMY3RzkWN+iWW645HUEzLM4ZClh2MF4hcNhxYRZmYw
hyd6SmNSaEbYHdZfDH1JwTqmrGBsHoazDcHfyQit1pGXhWxSdeYZWIlMfQeg/vCHZ3RvyxG0u7FR
tzD/AAU1QnsByaOC0tCuqXgUsfckDGH0Mv8ASMoY2+AtZVh/wK3z4+BWK+AtzEV8ibL2sg+DnKjK
uWEM/notuhSiadpzDFp5pGS0xDLCXAhNS3k+jOHpTGxGsSO2QxHQzhZbLt73CzaT2NexLH0NrQ22
UGxK4RBC5YpzyhIrIsxXq5H5wOEJlh4u2LDCdx7EElpgfxSWaMxiW5F4SlgZUwEnA0yxVGgiWhpz
FoxIafGiBvXzcSDbBiHORfpZUFERt7DvDc+R6kYRkezzq2UmWnYnItMEw1cwsPK9nlDdfwyr6USH
Gtm1Jb8ATgwCk4LpaipN0ktv8mo4Up3w8k1vkJivIWY5VVYnbv8A6FpTynwG4pWVGNmnCME7Yx5B
/wCCQbW3C/UqXg6uK9n2kh/uqIpz6/0VCKiT7Nyqn2HMEH9ia5G1mTKsRn8fIIS7J7NucMBAuLWj
0S5Nv7KU2mvQ7a2onRvT1R0lTTI0UG+y0wXw34+KUc0Q1gno9xUyTQtBuZyagOxChusgrTyxNxo8
IjHk6KrCyK5CDm+FwY9Ai5ouJ8jT8jtPRv0X5EX+SL29HJFUfmfGiXkXnBS0afQk8iJM4RHejbJM
b6Fmkp3KJp6EYO1EVVLAhJI2Nu6eRVbLgEMSKA5nRgm1oSsmsjYlRnmqQkxewQU2sZFSQsCe/wBg
sUsJo0lqF/8A4HlJO4NKpVPZ1ofJYjSUEd06KY2hpyGjICwVBk4NCbgOUaEbtcDaVRJZOBdAqUbD
5Fu0noN95PQKNvoJD9MWh22NqaUNqIn5HJMPDHq3TDCYoSZ5UzsQ/gMqKiJus3fBkhUPXsGozkNF
YsgrjkHpDdA3JKIqBcD1zULiGIKG37MwR50i8glM02IBP6IcjDeC5GuQomCUxIKWIIW5XcQlySiP
acJLLsH0ccHakLTVXFH1slQ8OdC6lFIdIfNFMUQPOfIpXBGL9HM/vIovIzBTaVIQOGhGMEraQKfd
oP6+WfbcGXnQiNaPQ+HPgcJeAxgq7N85nZMn2i5TM2cST05M6r2J8YaFQOmNN6Fomci2JThrFG3Y
k9tB5NpwdjAuHCMzlb7FuCh6pr6YxLPD2xgRrIau4z0Rxxtke40n0ZUw+RHa4KNZcemaczhz6J+T
OtK6px2YNGjBdsb535gnqtCWcsFVrfIi4q4nRdGmTA+6DkM5H4Y4wHFHB3An9FyLulGstGsi7M4X
KuBwye2QHrgPEkjxs0C+siO/DBKk5TEbWdQVjt4JoxgRtImHzwLNB30Rsdj2hX9qP34FOGehrV1F
T0qnRLlE/I9tMmoNbeURnAsIfBjZvd4PY7J1Z5+CfeDJiueVmIta3zSx4THW5ZOixJnnFE58sIoC
jLDK+lCTGNU5zsvKsTY+4Uk/ZIMjvgrro6cIdHSLWeaJYoTN8DEnjCVFneqjd5GMq4cmG19jEfgh
6HRq5G9toxyUIhHOCN2iHIhqswWCPEpiW6LE4Lkss9mJPXwP7Sz6DsuOTglMHXIl3Lh9CHTAnYgm
cb9ilOok5BEyMEQI4XgcLwfQ+7jr8jSUFORKMJ/Mh5KhlgtLe/Zr7zY17esSrRgn2aFwZfJGSFim
UpLsdUqU4xIsV1n7vCGdgki2qj0XHZqQTUDBlNkhmf8AQt7ITkycMctHp0WvJ9jH3UmdzOwODZ+h
q9fFTexPHyWqh8EDNCeS0YiqVEKkY++g3szYoULliwRjD4dF1E8Dv8XX2TKCJjojxieiEI+gtprG
MD0oeOhkHbb/AARW+4nwiCSfsI0uaT00WvEeCq28DgS6rgOIRiiOtI/1OFxqrzRZ2bKn+2J/8HkJ
CLGmI22TGi8i1ajg1pXsbkwhXWQpmt7H5TV7FheUWOi0TCTtFaeUxOLeIZllmGYFEjXgBySDY9IW
WxnPDwKrkIPDhWjzDdHKU9yK2AWtlnTKBkyZCpiyw2Ccbx5Y5cm8j2r/AKNfwHlvRQN9FARiU72N
2zc/ona2eR1Sy9D3PgUXXDgT7KN7CnBRV3yZy5LWQtBBg3lqjS3GItw1C0gdRQzj655G1eciZqF4
pHliYY4g50YiuDGJ5oZJnaVqN3Brh/Y19gaiUNtj2vbRUlnV0N2IrwdjPW90Tyi8kZEgxSlBdj7r
GVXYik0htk2/I6zRI0xocv7EsyP+JG7JT7H7L4yyTNwNMV8n7Ma0vLJvJFaZFN4aCq/bLqmHc7zk
zZmJmXI8Ywgnsx5ovU39MSqmvcZ23/RhJHfRKl+ZkH7SGS0rbJODtIrqITNYxIweYM5bvobNvbCx
XMEM/oTFJUp2kf6qQ5vsdpA1ES0XoZMZcpCuZZeGWZVIkayRLIiU3wh8wxDMnshPTcqKYrT6HEFl
Q2s3NLnGjlx8Czh7QjaJDfT0JSyTrH5ItVmEMMzSrtDbENR0OrevAbpxqMiUzYlsG6Yk24i4TNpr
sIEOF6N3Lysjo2nvpiQi0adoZFDGCSE1xeT9kROvAmNK3oY5l5GsexVTfRuInlE9gxo8lg7CpIg4
XR2US/Rl+PEh815HNjJlRCIkNGvHGrs5WI2XHbg0aCyZJPKevhRI/wACO+2xNVE+1BiaH5JR4cGz
gWRrPwLbPYlnBeB3EEo4RBUWYOi/Ax46d7eBpcYIiFgg84RlDdEFEcRfqFLkxPwMxsvpDbGh8mot
tG+pErIOHiIQA6xMwbHzXAw3yQoLxSdIipoQXPIk6KPVQhNMUJV8FyBLTWWVpNcCttY3Jpojl7S1
uNjtpLAqDNvoSFToJcBajNKCkl5GBf0MrJ1CKiJ9ivbDpgCq4TdEs5nY+prMeRDV8cC0itjUYfZt
D4IbjaHqWp2ZtKGRxiCXV2ytCT65H0sRFjIn0rVHOcmAlOUhZYLDg3aRVMbwhHKiMjqXwhrGsdF9
IccEldeQYniCiiy9ClDIxtjgR2xnI1lb8wjGXtD3Um8DVJGW34CGTnMFWkSFYHEbPceukG47gqRb
ELSiS8hZpZh3NPco0KLzqHXI5apKcmympJSiSFplNiMrFnCMsfwCYyRCsRiaDXmi7pI/Jxe7BCRe
mMKTkRyTYT8ngoimlKZyBMhKxo8i8JmuUMnRIJa1C805ZN3HrI3UJp9COvQZOmO5HGZlRXbgbVwx
o+zNg4gCLXN8mC4TYrupyhFEinLW6IvG8PkZxg3NiXCK2bxJInsR0TSFuroElbAk8j4Sw42Y7cZo
50OhiM+LMHG2NVIbFi04Flp7Q5xd4RDVFU+BZcDw1DA3cFKsgYKdokNKoYBZGKVWSnNXQmJkcIY8
l/ibJFCrhiUVW0poX6iJ5+wrS0yhRbbzEKdilcCpWCIPoMuUZMEjiOj9+BjbGKJnJtjnAk4EFOFS
hJgGuRpWRsr2OSVgYv8AO9EinKMhOU8HEI4KKTNyLMp5QT+XwzxYoRdMIRJVzsdczNkRGmrrH/vQ
Y7XCgRmltqMSGXCQHTHI3BO579zEEj9iI7MUyJJTyMBDdgUHFLXRBTDaMqlxt6N/Ic+CZEwzs4G9
ZIvJj1yPZDZtoa6EkybXSMwsz9FXKNKkbH/CZZh0tEPtjW624MrRh5WPBB4gQxJbkNMcBFaTSElW
oT3AR3wMkEQvXgLG7sx1B7kxYz/TkI28GsciFn2NYH6JC+BLBgG1mUDsXEZaIsLFFfjBlEnAY102
DI/wLmFgzbBcPqJyFy0THOwuFauEOkdYUOoowrOhyvBsi3iL6ICX7gkRNiglJyMKk8XBrETENS/Y
pXjZEsGrwSxlGDUEuXnoxtbaMNvdFBEFJfViHKjQsVKCVVg+RBaKl0aWdcP8+DPN6jtJFgqqkY0Z
8nWxRSRY0LipCe/0EhKloLTLOdCnKYI4rbFaJ4ItkDYhbFmhMJU2NnBRIU9WFBD9oU44LoTPVHgD
9GyFMXr9hrJpuUJj4J4QliPGoQUVdkX63sTyEhjF9xCgtJp1CXUgz0wYsy1TAo3lsXIPMMQKoYo2
n9BOrA8SQJ6LVs2ZVLRKjf8AJWomnmIVSqFRcuBVmtDQ7rlkQqwIQ5n8A5F9CyDtIzYjkYjmDlew
g5s//wBG000bXXOdEd4CY5HFR+VTJ7He6kfI/wAH1LjsfEqEonyEwlmkLekLMidYrGNvIybEOiQt
e2LxMPQaSGHixO6l6GsG2mKjzjFES1BzhvyXp4P7EH0Xlh3PLlD9hKIdGRDSmRkFTwJz31FIgsFB
zHRyXOhVv0BKKwQk/KMCSgo+AMVcpLAsHkNzBTHEupk0U6ZiUKNJbyNxUXBQiCOHQ9jVJ2Ku2n0M
SobE2M+FNKj0XXisHFCVEhVqCJT5GKDqpUVlTngnF+UIIRdoIdkNyoeBaxVhEnWI3aQ7k2hrIlqJ
XoPC1srEGkscJUA6sOtKuBqvFKMyn6HKl7BmiTAY7mQtNH/BKMzZObMwXMhkP8G1SphBHRuMZXlj
tfgmumqYh44fwYmyVQyHoo7ZSXJhDrYTkfJfRF1zOCtjmIUzRD6J+YsjWKlKejOc5CIzwIkkpVIt
BMPTkS5DyUiVOL0TLGsgaBVDJ9K8j9BSUFRqQHa5GaEFSqmkciwiQy2UcSlGr0JAi01yHut4bafY
xPwcbJFqI17hUhzNkA24ZFEfNFuPO1BHsaiEAhWiFlH+nJwxOC+EeRkx7ghVdHpgW75ozMKLiK5F
Xi4FCHgW5YYZZXjAY7zg0kZVVdLB9E1htCklpmTYjNLl0K5kMgBMPs1kWQ46GRYLkYoNoWTNEXeq
KQlgQLbYs5lJbYlaWBzwBkv3o9oDW+HBxwEu2RaJZRZnI/pSCGoP8ZpmboTkS9lFS20PieGIZYi6
yhd7ohrcBDtHgZnS1kEZpeUOSd0z7emISHQzpDrVDgSyx2S0jBqqYGuUehgmW+AvNkXgfCmQ5hJm
R1PBTrsyGw+9t5Rb/eM0sFDSN5GT+xi6dEEGz+RMQV+BjvQh8DLeDNOmDQhOTP3MJZzyYAVH4P8A
SMKxVrzsNeudUzyE+PwPxsJpETtzhsRmntIIvgSOthyknnBX5BTwGHbwSaSrODuz+ib029E0JuYH
TAPaq9BEb/CytxDDcEIQlwQQVNZM2SVF81hEjkjjpNNvTG2s4Qzvh2KV/T4vnQYacsDKF2PXiOXT
SZXUuSYrPDtCI4iM12KqRpP4vJBCHreRq+oLZa1tI9iJ+TDOsZg3s0wP4AIcFEcgRjs4a5I8BSC7
KS6fgg004Y+0NHCrB6INbyvA1+7noqOef+mB9QipY5JobKDJRGU6/AuLl9CwTH3OsJfBsPMoedgt
b3SC45JXEcNI5NofTTs5D3zwgipmlfAlNH5E6V5BjquUyuj1hm24lkVHifAhMe2R5cUuCiOSEUUq
MaerL2VIn0LcapkrLK5JyssIQLpibWzbImfwZCwunjPukxMP6xcy52SqyLBgzQeGmTHKprQ9r/8A
ITy1ZtmuCYOSjT7CT1XeRsl0vQidtM4A1/4FqRlh/j/wainusRulwI4aovxX/g0GSUC9N5BC+2oj
Qsg6kqkwucBSGzSin6FTQwkmn00/o2WWUn6MPqacE2fT/ToZf4OGVq04M3UM+c3/AAX+pV8mHhPz
JT/+xGey7+ju6zkZJK6/6cY2/wCCwjWY18SPLniLRpuF7EU/V/6KUaFiIaNmiIlaVGLHpg2ZI8Cf
rgXS/wDzEs1mjQ1SPgojyeehjryph2kLb6OQoUdB1RrGqEPR1EyPQciJ2Z8iY+KaMosQ3BpDZs3b
s9B5RDSRtk/OxTy1gt3Ip5yLbqMAVrJei7E5WCJ4BePlPYryicrgd5THjXkJemxfjmr5QlZsxEzg
sKyNp0ISbmDVaw3kere2hbZK9mSdzJAxLx2RlN0nOLsjwRFYbPH3oQqP4Qe25yI5uh1dP6K1XOCM
4U0jNH8dXZkCjgkbkpqkPkMIb6DYh3sfNxC2Ks1UD2UClM8hFOQoz7M4YLGK28EgxRyyOXUGQbSi
DJYTH2xvl4bGM3kvwsnxcjnTcZiWFkV0Y65GavcAt8Rm6l0djfNpEG1LLgupJtkwWNXDZP8A+mMh
t3gW0tE46bplaQhryjgvmE2JLSi839HKzmSedi0MFaEG9GOaaGjfHYqfbkd06p7XY4K4C67iXCNq
YOAchoaQcgOoWlppmaZgbTtrP6VjCounYZ2TQ8Fbbg3jtUlVhdfDNmXZPStSjp1mGO/rDM7hkVGe
EM7eKJ1jZQo8CM7gyynjOUOiyzkVJ0/wSxfdN04wwGCTxojy0rwGFngRXsChpRVKhhppro3GxqIR
9Pfj4wAiw2lMiNWbDCfaouuk4ItLhDJYiLBibekv4Jx2GbnjP0Zz81bG1LqIjQNGIO1hJhJ+IVrY
mNyXFI7BEiD2eMpY0THUCqB6gi6FgHUamWkbTll3c1g7cl04LCJWNknm6JGjAwtOGgdvKEItCceB
OgQVIRI7o0ZWrg3YjYly8C8mVF5NsU2m2IW8N0QGAO33OXofaMduSwQraIjsmTfYXIyaRAtoqLDX
AmgZrNk4tldZIb5wVFb08mNvN5fgbF6ZTKEzn0RUmwBLV5wGqTXsQDJ6szLKa2hWxupC15ReESy0
HezKaGgboTFI1OjQMNTKibTkxDiNaTLMtQ0mpJgOJhm3Fvzy8CwEULjuU3SwsQ8CfMqjpCKpIYJ4
ROYEqyL+L/AZZpPtFikwFkHH+I00NTRcjyNBvBbsgS+Ql7YkrQuKO6FtY2LwhAmV59D4hsqxVdnF
5Em5YSSw6KKmzSSfPxadGyUEJTnAQUJKURR1URK3gc9jaGGxyZogpcGb4LhiOaMzTbKOjkKbvgyQ
6TQ8WpOxZEhmk3Y2wJZwQOOTLlxyx/tVkzx+HPLBZFjwHkasqJdi1bWbkue0WOJjoWqaMcBqpDZd
M0yUJa2G+RCeoiU0I7szkr0x9kshJC5p1oVdk5HC1X/CNqWcJvA9lG4SyJIk7JhOyuirZKCaGmL2
QFYtBkWhLfhoo9cxhlgiJWDfUuBAznOB7EP6D3sSiskQ16Dc32Hucp9I0oOGLJMdsd+CrYk4eA7u
iNWAtTkrIpwg6Tony9h9uBZqFOg6j0JRuEXeg5SoRmV6LfHyS0qHBmKoV/FOaySG3MbZTiW7Egtl
gZyEXEHciS6oyBRSPz+mduNCGu3o33fDGIPeIOvSOmmO0VTXlhiRuhWtIokFeapzs7cjWJUFiEwV
GiUsRvxYEVeFZQ/iIQrdcGZNlh+UehSSfgkGpEO+xAavF8DicvCEcpcw5IWF5GNKYIpFOVqF8agY
SMtMgC+BcxApdyqLpY2xFIwf0IJ6raU5BZyU16GWXY1dMy6WLyFPtWy6mB65M4YspPVr1Rra+IjD
KNcCaNVbr4F+AumzXwexhoYc9pYKxKBmvIbkpWQ+pNZKNa5mIkvXjBSMYk34GagYH6Q2W4YNRn+s
RKyIqQ2r49h9I0JiOvA9DJ9hdD2kEgvEeF+AgQ3Yci5KETmHdSpBStG32LSw6iUVNjIx/Zj8SND2
Nq2+R5EAzfeDMniVvQXkWzNMxLnVE3m54MT6vYz003KGreX2LFUwbN1UWl+BMUaVp8jmvM5E8VWD
A9lyGfafhqF2Iobl5M5AyYb2Cj+r+CKZJBXyLfE0xy16dwzz6lFXyOh7ouxBLatdiyAeLFwVu/CG
CV/c7LfLVGiOPNhn0uJN8DUDJ0NjvzyXmvaexwi68DAyiCl32dIRCKBVEyHbmncCE+GPwb0i1F6j
sU9bhPkSKNOwMxdYgPPwJxqAhrZiDIR9lYEnxL7ITyNqNz8DfYwxGLjyOirSajnQ0TMToXR8CnAt
9rfYpCppcGrqVrpHLcfAspT/ANHUSlwObXN8lC9hZezz0PbzHsBEHMOdfA2MbMMEInkXAco0MEXB
MEn4Fljx0fs4KdEuhmjaYuKk1lk8mvobtljVO+g04vAdKZ4Yhq9EdaeR1CH5Iww0KlhlpyWcMfGZ
tlQm2LHD2y63Ehpj6+0wNXHgvLYt/iQiwhhyFcGZ6oUN+hMaiFCT8hvqfkZSmJOOjKEKcWjZM6r2
MmMBDJ8nujLtBrOqzTVpcFYb7FeZ3Zd5F2n5D6nU3yMszok0Y2jNsfQ4N6fxNhOhseoPX+g3EafQ
p70IKdDDZTdZKpFWoXpvY6m2KU2GFJmGI2e0ZFpD3diRpbclceWnNgps19OybePTFnuLw6IzuuSq
TKcDMrkQ7L2xxS/oc2WRMblDwiH5KOTCTnfRnEvoyqUMrZMGRyIx/wBHcGJMo6pizS8M/wDOBV3z
RZXPTp+dBQyK1fQibUr0PMusd4tWmJ2GyfnQpeQVzyKmOzOzZLTsdh3DSK2J/wBhhcLHTO338PGK
xvVF/wDsFWaao2l0ZyVqfDmuT1K43h0OWz5mwb2Ye/RGRZ/JrSyjbDCLghZGtPtio2suUKud4jKn
DHUxzXhCTr+0JK2f2bDKOkvI3hj9sTXhZZJLh2iEd+xmu4+BwFeSF2OYGnhv0PScRqwtqtryx94T
+i005wobA8BmydMg0XQp/bN00Yp99DSvsBNvg6KfGyAPOhptf0MXI2VekMt3wJujuCpzgTCWRPsS
ah3EE2n5KiwvidmSR4CitHvIjMp0xrwX1+5jlnfA6wJ1Qq/dsyc0YdaNuTnAl28o9UzRZFk8Nqhd
cm7Ynp1bE9kKRtnzBzR0sX1NmBUhxl8iuj/LPstHehWxNZQ+opUqBkbCSS2MVRnE65NAvtmVUgmf
JEytG3Y2CnbG3TkaR2EskyQyU5EO8jMRrQ5tFPQyGj4HWCnAhrqfJCJockhjrIjopuA11B++Xg54
UwktWwc0bNZMvxogxasH9+KH/CP0WFrBtExosNm3gyoF4DNpIYQFhlh8QYMZGNTRjTEtgq9+h81B
UULbSejAFg1YvGG7Q7unlES0MBMM0WsYPGiXrItYJ+RE4pdFn4dzhl+DkwqJUJ78wobN1mLWNswF
VDSiYpBpPsSzTeB2SUSFXA7HqzTfQxNaQvo9DSC8MaWl8IY2QuX6kNUjLoZU1gXkd9hSty9CNtYF
KW+hBRNxBhZkMzIeNTNODnqZYpN0yNsREZG24KtpPKouW6hl4D7ZJkj6CvJsX7FdmTU3ApbwITcp
rCQmzQtxHohs8bRIp/UzcU0o8prBJmOxwYBiS9nmnIIF6/GD+kUcZHY9fZ0TM+uaGdICz7hnZh1s
eJmFdRt4IsG0OSK/QjUmSpTOSi3YVdBkqIJuqNwo4GsxUJqYLkQlEonR9CiBdjJfbdDrTvdYM1vA
rdjYk2c0Q6KFzThyNjVHkMgu7TFBFXcZ97qCWbONiAuYsdVVmIvl9R1bWspjWlvMDA6cb2j7KJC2
yMCBIuYRMGyjFug5HqR7Qc9jNCR4qxaNUQbZrDSHJX9hm6cC5otOF8Tlj7s9CQhiZVYIFFeA6wjm
0IVYS24YyByhVUnFwhRZ5ybA+hLb1QiyVwxiC/AkLsZPDRBMeIllwr3HkYFtqng0Ctm7CZgaz+gW
U2ykKL2MNhmsld1aSHNxHEXjsZ0aOwdZEf6Q+hAyUoCuROrla5NuG0asLyKefyyMVqBTwX9Mqati
DU34MZxTmM663VsTTeGRXe4myK1E+jWw2LmXzhNd4H4+FtQuGuGXvMZEybWQoaHEM+Ksf4IECeND
MgoZHtNeRnCa0EGmmgQty28EUugLntUyJ2U7CJwxT0FlhdBaGCl5pjNITxfgq8EbYqdt1SxBWm01
n4FrPboaeNCCECckGSAwlsVmAywvJVjh1DddAY5YozQK3A+YrB9GMk1bTyKM+C8D/wCCZcFznWFI
PI7PJyLMG58H0Gp8iZPR7hgWKFbFBWwTRgnsR6f/AIAffI30cPQgFVhCRLCSNJQgKTyZoohzehDN
ZQaUYTwKHkjHsk+tmMVaxSAnI8DcOB5eDnI9isuexPjEng7LHNVILOcsTnlZqErGDkNRA41GiXNs
mAGEYEXoLlfhbuIpl2Rgs8iH3BwNBioOWqObEChVSFELL2blFoWIZlHSwMRTjnkaSwR1sbaEkjH9
CaLYJUKzcL1p4TF8MLg559yi6pB1UQX5QeCMsLxB1VXJUeR+BYVI6O5Tg40mSGsMCdJpQQw+hJdj
QoRJEIIEI3PsxE/KrhiK1HNKJsYGaKaQky+YO3cB7ddpjOuKzCiyJ72wcoIh1opIZKchockjFSG5
zfA5tS+xUa3DEpqCdzkT7rAX6moxtrjuhBeAxYXY5oBohe4QglhKiaaqFWsrESXwQypTpnEa5OHF
aIUJ9jbaTHJM3mlIyi82MWrgLXMQxZWDQ4j0ECpnlseaLiiGrzEljsZxo0EXTFqjbpLRdKSaKedy
hfYnCQPAj2MzU3oyVHBg7jKdCQjTTEShvRnCsFCPlDyQprNnH5Cpkux1pKW6JhbrEEPa3Z02o+hr
LAm54hIYBXD0JRwHJLdCpaNP0LpzHFOaaRv65RCadgpJBgCMw+JFhck4q0MOtHGPzdWSM2GK5fEm
9RtjejFaHtPYJdz1MgtV0Fy2opamEFvzLP4KOhRXCFUcRQ7hTrEQSu3g2Ktp8i081i32xXTKsx0J
TEScwg53NUUeRRIeOXINiss6mNKy27rOQhnAEUQCfJK9jbwqgV8TZpkMkNxJMEc010MpnNaRkANm
Whhr4t0WbSUIqJnYzp8akKdG4fs5YHMpjRWb0SHEtK35IWbPRFgOhJ3Rho1OtyFeebEP/MYCNj7L
ZI6h+c3DlTKYnDd60KQOSTHaNmRMdKucx/0MAzNLVCVpwf0WKUKqZDkUvI3/AMl20bsiHvEY2E9h
6MITcaHH3En2M+NFTFE6WGfQx1jJFsFtZeic9vP0OKMr0MHDjkMCPlcGor4D8+6uBvSoyTthB/Qo
URwb5FYJvksCZ6/QgDVFDcxCMMVuYN/QxghsFtiGOTYJnyKp/wDsieQTsZDWYG6xPA/8MMoVH2OP
aRBKD6QuyL+csJbbwYxtUX2ARLuHQVtJf2SKkGiC+amiZ8GU8Fa2JrGCkdIQ61OgQupDHvMkWZFm
jl5gt3y9niplGTGB6PsUtPIhEHjw7f5Du2skUsJj7tD7gtwtlKa1lBilnkcUlwPyXh2YkK1Ces1o
6QkIfBk2kNRYtMVFihqDsp4HIf3BWMss/PhZXFPY4Jx5LbvbMS84HTiGOgxn5eR6oYBPgZoQkLmi
E6SM+zBS3RdEN2YQxRYVE4GSAMszpKarQW5vujo3RYEJui510O84JePkzPKOMEOfmD1tlbfoYq8I
zzCJh8DyuT0jBwL15QhJo9i6M1CSPG3smpwtCn/Yk6JZ74FyodaHcTCPQESXAuovQmxpCFEKZOcD
HeW4bdZawV7sX7lqDIvDzpGXCmRkviQOcWEmhGAlK06JsyRKdlDyFeQZ8icvoK9aRT4hbE1ye+Qs
Yg4AgOzuq5H4DEPHoXnsIT6Yl+Q8ToyuXQzYRpTmg+EDDhFGeRJvgTn4oIEcoZYKKqxRIltpD5DK
1Fol1Ek0VH42KQ5+8UlNaGGwLJbj/CiRt2gFZ4uKaVsU3l0PK8cMRR6SD0tsNGDKXEbOKPLEpLAk
yygPXzCYXlqaEwRLgqneAsHhkQkonbKr6UeY/wD1FoJKwx63lC6vyLoKEyb7Q8c0lDnLWhh3z8A1
JWzPse0kRoIWlYwMcajRPj02QZbCxBreSDvJGggb4GEJychDHWAxzcqi/eYkh20LXPChSY/Ipikh
lmicqag6y8bExT9cUhzWn8FjcMNousMw7iSD0F82voRxpkS/fPPqhzvWR9ev/Ap10X/WybDVDRgt
vMDf6n8Ll8DnXF/o/ioJfsR9OEjaxhUMoyFJ9vOBUZFaDP6N/BhIuRun0S6MtjoS+bHpJjA3R4ps
2StpkhM9impJZYtRuRGXrgQJSi2BZs5fgQnXZDHxRaXGwyyd3ZRujyKErkHl+kQS+jEd/DC1DvIo
18KXBcGT6eFRutByuz2bryNq5MkswouLsUhc0dYNiSnlFInsM9zGaTBRLydUvospxjmQfZZJYG1S
Qr6Dx5vLImLAwgxjMQn3gmQWYhiF4sw1aHJM0wxTeDVo+6zgV7TUfIll4GTaMamuWIZpg5QSsFkT
2LU0qwS7nJkHHwggxk8EH8B98lQHQ3hMeLrH1CUZLxHRawEMmzJWYOGNvIwrFp1F5EEbIL4B0bgI
OxlFXgaQsvAVd3kcqDd4HURExCzySms4MfvLPgWF4EXOBJGB4yiqrsa00uhnhNLyXbcJ2zmB2KeQ
l45gTzfgh7utj6GxO3kNTZMyLsWBF55SojInkGpZxtCYcHsOK9ELNNvjAz3Ae3wS7RHTjsHsU28i
J8+RJv04HyYgiGy2ITyeijxeQ6fhEZM7E4bQKWVnA4HUTGxHnYWT20WdRMB/dXBxoqyNcu9G0ymF
q7EGyGRKumIdspZKkWyJceA6OCwjbHO51iDqiSbGq0jFBtol1vNwk91tm3QzReDiMIju6EW02N2r
fAw5pl2XJr/geCaiPkrZuBuhD3za/QkIq4LKbV2G+ivD9CKuwx5FoHePoPu0CNpkx2OO9DyU5ERE
pFaOMGiPsNYmxohW5oWB0KDviKLFwmH9eKFQ4OeghpawqEck8obrEUXXRUM0FoZjUzeCDF8pwfJC
Gpq450SQXKmtPNBfy6GhQ75ZpYmgvZsAz22ufJW2R74FbaeIYZNcGkysDLi4RsE2lS3mCoeVkOYy
dh/GqkJsjd4K6jx0oVWtMieZ7E82w3SdURqaQ8wf2xi3vOyYnGP8w2xOmGIKY3mY2YJBu8ydGCwV
nWOKpvYojWUwFPyQJ5DVz2a8HTTQx8yzaM5uB/RLQY64OuKi3cANjbAoYLep23cDYrjcI+052RBT
fUS9sMvo0dDcNmh5eEVm2TnGBUnl+yWwhhccQpkS1FFJy15Gk5xHkRQS/mFCSYpVdohQFoy4gn4B
mvAjbk4PsNRcumSODNxdFEYHExtr0aKjYTjsbmC0QbxBXUMURtlBYbhnYyxpJIQ7AVG2slCpGIj7
jIvPI7SryPmQQ2WB4S6HiYyWYYvKdFA5G/rpj3XYVjehadipSrG8JBnnQ1oaIxQJ5Ntt6FNNIYCV
5omD+hfdl+RYBo5AjLFJ3JsfkuI99mDq8Clt1eTDiAmx8khgENoLueL2MrajGxQkiE8lMBE0oI6t
jp0IKgKkt3BzSSQkXBVmqMfqSQytSsyRXOLIppjGqYmcfBDXOK+9jgQL6ZjX6qDeKS5scFwE7jhR
jwNMlGEITe0cTJA3FRmEYW6OwSjQ+fPI9LktmM6uRvMJtDLFWOyt6sfBD4KBMTIOaILNLIhqu6TK
04KDv5Ylwv2WCQSK6PI/HTvw9DHRkefQ95UmoE6Qqfw2V8KxC8VqNMD7qzzQlu62RKlkMduzaXpF
yZQZKs0WmHydPRTUr5H2khoongn38CXJLE0KdBZGZl3UQxLGhmyTrdE3DzZbSbXA4qvpBO9lsLNR
MQcNIZUTaDQ2nYsjW0NV7IuU0Vl8pQ0TFAhiWx0dx0qUY9jNt5NGJRZOcRWCNMYzwyzkmrNLJFXZ
LDO6ORixkHBrN5aG/BrBTYo5S9nWQYxZqZsgs5LlOiNsyQ7TeQv4DkKHRIzarODQ8XCImC5HG1bx
kwFjDELe8+REhCJLsW3tsyicdSbGJfKPwJwG3DJaTjHIjb24PvTkPujVRQ4x2Z1DcZk9FSGKakeX
BjAd50PstzljOBhE7sKo6NmbI6JzEcR8kBd2GqpSCbndyE+iTTuhc7VjIXSekOoNj5g9Ry3/AAxV
zt0LzESIgTKObm32NFNDZVMHL0ug6DXJjutxU3JQlxEzngZm3kfI2A5LdkGNde5SPlWLhXCLWhPW
2BtbxEVXMrWxhcbLoa23c+SAcRgahWLAoNG7rl/HSuasE6hk73QgzrORLbRzuW4sFNq9j9kpQw5J
gxsRLDDvQkawt6cEOTZtBjmxBIb4EsYNfLL4vVvZs+Kgsm+iiyKPsd/AHbuvIkLhMpVYszaU9n+p
Mh2KZmywQNieESpWkFEu3kxm2BnXUMY8nQZlso2K/ASFZzfg+hERyMtmbktbKelE7pwTOfYwP8Cx
+pi5Myq4K1PRHl80XywL7HZNnsQ39h4Ns9sUWm8eTU3OGZ7UhZageNbLcteTMck6NwhUdf8ADK2U
UCtr7CDLaIAxuowjeSo4tGLHHZLtGK2xf1IrrCxRgSaGZyLa09jnU67LJujlNm0Je17K1gIjJnZl
Z3IkkxtaLfFBj0nl8D63ke5KkzASomTW+FLpNpFVuiMo0CVpshjK6yneDxqPmj7auC0CfaObUSrT
Qt0S6d6CyoWB0vuu87GhaaoZe8uwVXIz1TlMUR1D2wLsJoHmpu+EMZtTHd1yXZWcqF02jLIyUiIF
nHuFFHW+s6HFMNoqDyJmoziM0eX4Y4MneqNt3HyxZTJzn4DcQcLgIp7eTd15HUWRmvMj7kPgjeDL
p6tEKkxj2JkTsHuNu0fsQVMscDV0tlC2C87jI+Nhq2NLEeB5wnI8yLU1yX9JEh43Hsb5Gc55FnP7
GSkWOzkoqrNevhBPdRBHoS+B0kZR57HcMlHRhdXrkVaZaDHZHtm8dHI6KSdeMIQmXsxJs9sQeVXw
EVJ0nX4KkvZnaGJsDfBkJ+Qypd8iawsUnZcinaGOWfRqml2YhIzmtlCiCTdHEDxl+BRkQVDboiEp
vj3keyFSKsG51RSPN7MvB3Q/THsybIOB/uwREmRFcnkXYDwNmYhaxHaNXDHzAcD1pbZNyrsa4HlF
UouRnJu0VqZ8AT8/0jKiIKaXLF676G8eguiWrzTKOJbKZ1GkVlHQuhk7khm+b6JmcRBDBRBobEJU
T8FaLXCR6SgVXjJ1ZM4UWjYWfhoWD+G2RFq+jyGokhWdFrJZ+FCgdgcUxLA4ziAZcSFlVsZ/sjRo
H6DEKTIeKouzenpm8EECLDHTBVTRMfF6EFtDfYmOxamcEqJgQrx5L+q5GRUjSs9HGam2QftzCIHY
NTZyzHsj2mIcuMZdfggQ8iG/0JvCV7KDaXgXtDJJyIAvw4lBYI8l/Qjn9BLzSEVGJTvC6y19lRxP
BdxsRPrRcZeiKaFBNeCq2pgPeh2MXaFOHpR1RpDgRciEkkF79FCDXmDFUmmehoJF6Ho3h2Ll6+jU
4FyB/AixPC07+Ie7kTDo1n4NiViM8P8ADMVlyOqZuHzRobkOHwDOjHGQ2FyNBsjKH16T0Ju7MiuK
eRGaE5yP0JixvAxmV2hLE2/oqY06HNbENKMzJD8zNwKpbqkJDy4kJtT5NoPpBnKUKzc5N9hYndoZ
95koe8KuBNwIj3NiTpeBpGGaUxaBgrT+hz/UIxORJ/MZ8HKz08BXDIhYL0VFJnhEqURcCRQB1J/0
I6YM2SFIWWP72QSF9mxhhVpIUqeYqoEVAXorpvcGfBVjWmk6FWjvEQnIoE5bGihuq+hOTlWM+/SR
42ikcuU4sC2QNaQqzE2MVtwN7AZREfCvsNexOhEeTaMSHo9uDsReEGNzgmuhRSvgNui4FWKkkc+x
JcRo37aC0zz/AAnHlvVoxYbdCn28hcnsQxLoIKgXeYXP8hfdU4YoGzKaDfv9C03hw0XhGmi4ySim
/YhG3bcoZ7wuEXgkAvSEsTpV2Q7ibCWRcK7RCgkFbJ4eB6wF4PWlqPLQBkCXGOB/1bCpNYgXdfeh
0X7MbWGhQ3pdDU5YnoTgj0aZmuUPHiyAVbC3wEPpium3YIMIkmxToNoK/wDDwMR6S0YnVGmCttn8
jklnma3IS08z8mOP0DWmcwjI0hKEwISkMJoO0VwFxpUtbYwotxNBFibWsi7MSXM0VHwrmiS6bCFY
CSlWokIa6a8E0l8iOrm2kLwyzIksIxbEleMNt/GkqmSvDTpyKoHRBec9tiEHuIyGDHk0UXsPYhr2
btNGMBrLlEIfZV0ZOHJEOwG7w9D2BoeY0YmpocqOzYqZ12jSCuDHV0Uma6E1tUMUXMELppiMpULY
1mfIPcExWm8HoSs0QYbx8Hp1tkYKRRViVFz2PoPoWQqn0aIvYUJGgaJVNkAMIREwFogLULEzZ87M
T3JMCeACWTBHcJejBgEy4+A5GkN9OxmpWoJstEZ6EiiIoUXEEYlE0P8ALRFWazCH1uGhk64E+Ekh
fKfGBGSCVZZMXxdHgGYhLjKHtbyLSXsHpCzseHBdGZT5EdBpZHuUiRaiu/hAw/XcM5QY1ZkteLkk
U7H2wwEH/Ao2TeBPAhxLCwa5WCrNtCCmyyWZQdjU3NoS2weAi4gNoXgbKI1HTCNUsOaACHy2Kwti
jRAnNTSWMiv03wAqfF7EVz3kansurrZwXLKfwbgkD1FFoeCmh7THG4LU2pBJVVszlY8GrqlSQJXy
xGmX+mRK4ZXREYSnidge2tnr2qPYnpFQLtBxlFyJpLNUp/JZDDmVBJXXI+VhyzTyrBZbFf4OZBpB
6TexIY1oqR7JaFoldloxab6GwWWBRkReSumZaHNrVwbCbMQf4DQwPddB9SnobXhBlFQrskwjeVui
qrOUEseimbMiC1ylwLX4AlA8Q53FOVMY3QpYn0MaDqCQkljY+pzRfCaPA+CsRRLoYiMiMXgIJTtP
+CKrRvyLEFtxtu+iY+wtJNDczeF0OL3RK3LAleYTwVTM3Pg+SHktm3ynRrNZgZsyDg9aUnAkxcH/
AATE2HbOHcFvzJCC1lcNBkG9NbQm8yQZqy5WkiSbRGQ1gM3jPY4RhUe0wvDjYy95Vg4C9pqWgsCP
+CEPIX4sWHlPRGdahVjnUdFnG8D3LyNUYpfYTApwL6Im0hCCprREkUSYExFmIPMq5pvgcZMikZ58
DEoRdC9LV7QoVlR8nWWWiyzNrRKqSa8CFnlozfXDkw9UPUbJr6MaQOswStZMNZf2PfZszRbD7GBr
iI8WxJ9GdrwVk1jIXKq0z/pGU+QZFnMMjl4TxLoSfTRgiybKdJmIcvIkwwtnJpUfw3fIkZX0YW26
LoHE14DgPsNy3vQh0V0UrLMb06EnAtQXV5RaPQTGrLDbGUNUUCIltcjEk8hyAHA51CQ1hm8mHYXY
8cYMudfCZFhmRwKNHnkiApFCGrka/oxDI2JrhNDT3tGWJaFuoKQnnA1mC9esmK4QFVumQ2JbNFq2
XAdE5ZhOIZLG8iMk42LQl6MFR130UKnuPwLCEi5i+SYFnODG0UGNYQ2mdowWsMr3kzbQmLCotXUE
02c+IUBJR7FFk0PugYGlPRHMZBILIthEIuT4FbTr02RYl0bqH6ZhgqFXkT+Xg4/wMvuFH+RFWNCr
Fla74Jo5jAS5YkzAVqJwDmxZnJ4FSl5MsPmCbX0RlqZ6JEGGwQ08E4NEGvI4xryh0aehnXLlMShE
WWQF5FaXIg5PjSu9E8YEuJ+j2q4h2EEESu5mkV+9CVeCtuhgMz/TLvYc6S91JmCNQENYYFO6YmqJ
QoZmjxEZrwyaiQtJESbCVUkkb2UWEOJyeRSzPTFvZVo0W4RRaQzUbWBlXkyF4lcCtvmoU4F/g8eU
I7VMC34C0/sVujQmIRbrDYtPlnAieHaMXQaH5xCUeKGuGURWhy7iDWPaJgORLdEIPlj6OY1yJqiM
DNHBr9nfgHjFIMkubFzq3TLYNlXFcrpmMMQIFa2J6BCchE1FIt7Ci0TEOJm6LU3DE7UVy6SmpNm4
KUNQmY9Mnkyx9FV0Kt9VkGSt8ENvCL+F4eRqoYrSwmLPiVjTiRJnQMEO4xJX8FdsZaGsupdeRbOu
wiGyDeqxeCkbHTqLlEMOFZhCxaNMWZQlKtBcy5NOqtH7M4cDV82PMw1n6ORTSayhP/p2OmnhUosC
N2wQVzZgVuCESzU8nGhA6R8MsOuj9GKWAs92xltqg55Lwbf3HJuoyBqMVYxVCML02LdR/wDuNWDM
r2psu0cu2NISluv9GyLoapSybeSLIlIJlKmoNPrqTfk3H4BQmFXB7OCHobnNh9ngNBLdKJMejZWJ
W6aZNmIIqiGr8mZOUXI5wIJw2RTLwUOcDXmMKA5EiTW49/HrZTg5MZCbtZWiCbyLs7CmjvsatjQT
nBm/DD2NBzHHw9i0yqfFl7tBvhJ0YUijlKg0qbsHJtcjCK8KD7rqCksIeAFQejyOwA8PRQenoYxa
BUTVZCYK26cyJoesVlQaq6dDmxr0Sa+cuttvvghtJocLdDEfeIrrgxYrEQXi4XFZn4nENjMezSrC
FPumRYPReTdCued5FlOxj6Jujy8S3r3QcHsuCNdGD2FVGK8HUvQcjikQzsY8GIyGKWBVHn4MEnfk
ZjWUjeRUkPY5YzQ5OIPotm/MEJYoIV1sJjZ4EENb2ZnXsYSUDto2jkoLW3rOS9MuxQvCWC8vUxDP
NUNZ0nkZ0Xcig1qUUXtuCYrjaN6cfBkzkiH3iImVti0Y4E5JhwZZLC8EsNLOyPoDJk0sjds20oWe
oTxJxERIjPZehJPvJvL6HvbqDHYxwdHEX9ANDDSf8Iz6GUEkHjKpNjyq4GDYlkYFwNyMzEJC4zUV
Fh4M3uahiSW/B4lCzxeRWxvSZIzQ53AhoIycrvRljKyLj1A8YnQwHa0IKby0Ok86g7rDaY6ZmRcT
NLS8LLyM6rR5E5VtRlJy8maKDuEOblvaH3gHoJttGJu46uUwTHN2ibq3DKOViHBTZh5Gq2Lc8gfj
oL0KUrIq7TZrPQ5oyRalJumPHSRXLaTAbsDp2k38OfiGBhyNXgj6ouRIRJ4+hSj1COxXNiqFNjHo
jVE0PMgB+l9YzHhENp9sGMIs49o1YxsEpYgerZFvxFI9uIwm1eOkwjkXtVEgrBRi9oXBhM2asV0m
5kH04lwFkBa/Y7uuLoeVSnEjGwRDM8tkYTZOezS0to4BmfTMUWhSnTyCYsryZl9g/wBwhkY3CI/P
RK6NTl1Me41IDeJBYpGFgxpGhOqbW0FOanYqBWosvG1Exfn85CNcxODI08Z3ontcpaRPCp5bhbfs
N1mlJV2HBFm2u2iwEVxTorZxkPZDEL8FhshUHhkzeDa7kp3o8DszPXIxeqWS+cyLNDyZdBo2OAXZ
lRag/wDp7KBwfItRmm24HH3iD2TIlbjJeFlozzYT/Sw1LOxwdcmTXsdBqHH/AETiyKsWKiMxKqJl
pYGYssSXI4Ic9pURIgwbs0lrN7WsiiXLEXcLLIKaSs9iMiJuGQboXYKm/YxBov2weOQV0C9oGLSf
ky6vok9sCl6dsa3hwH/6guNOamM66BZcmSJEKSRgVI6zCOmEjJIySigqvbA8uxCFDLMYE6F7wWJZ
JggTC4JAmi5K1EOk9h7Tex/R4glr2jHK2eicb4JhEqciXQ01USE0Mw4f027cjjpFrVyYkuR/csso
eRVh/wBQl0PIm1wKsJYJeeR72ePhAG88DdgR/wAMwO6JpkW6mIVCfcdYxyPOQSIRMXRbCwJHQ5Tr
mjXzaezA3BHSU6JsBZW0GVspYRjSaOIl9iM6wTkYVckTLb7YsiJBpy93sSGvwJsLBJhDjYxvD+Bz
oLgRaJvsyrybWR0vRzVKD8mmIJnUH2qTyweEQFBVE8jUK8kkrSISVJ5CuvDzPiEgSTASkNChNYhU
namMy8NF9c7tMR2sKsbsSQs4zyWfbEc+xPBmuB1F5/wRQcaH+cliMe8CspClw5li1kuqhabaWGb+
avkIqpbjIe2ybRrZnOu0UuJXRoZLYI81UVoTE824Nqi3wieGiF4t5L62gQ2dKoysx4JV6yasfSZe
InGdaOgeCsg0jgtaitTMJ9eWMWhoOMlyQtglLwbxCttjYqaeBtbauBUYSqRFydC9hiSn5DQ2+BF2
PU2yhw3ZGNu4Q9sbXrqUoi0gqlpZ55EBlKQrE65HHrS8C77vTHRu3RA4dZcHMc2VEdVJn63Izwpc
ibUKZHuHPIyC3yUGCm6DkMsVDhTrY4Ed2mXWaFBqpBdVvm1kZfV1GNTL7FEkwUgxrlpDWvW8skOC
ryNO02kO35XwHA9I6CSbu4Xr1PYnfsVtJdw4FC4IvK/9Cc9NFJ0Ly+Q0pHw2JjMVgypJvky0V7Bu
obEkdMT7F6hY4MZV2orsVMOjprowSk055FKElVOSIPZc/E18YPLMNGXAjrCGacUMdibAjrkb8le7
UsUksyZtG30haypRzgRMiXPI1Ot9IaWVR+6XoRMJwKdKF5duRMizgdh+qNBjXxo6WCVE2xaHV5Mw
5OjFG55ilexc0mCnDpFso0YDmtyL7TnAofhHbI01WTGuyAW0ryQKUngMJzfoW26pkmn4A5yLwkaI
ITptpls9yHbKclUD0oiQsH+ERjS2TejCL9n+GByoWV9BCU/ZW3slSPQzay8DWq32Z+Toz2iJgI0I
evhUiGi9DGpkFPoG2XiHFrAejyQjbvnkf8DgrjpC8qmI4MY35GzfBYI538aS3si+0I+pyaeIeWce
U5sqhzG1T4E7KZt+GOcmk3ghLjMqjhsTYfaRM28cCxO9csaV/gh9dIYubTFvkueyJ8ghuGe4EfKL
F7I9qPx3PA1k68wmXgOCoY8ebH5PC9m5rqkiuE/c9ITOuNnS8WlQyQZM80o3cQaRnpmJaJ9MclsR
StIegGh/fhiV3VIaKMWtsFFw4QdFwZUc7rqHq0bCnZkxLRvHpYb1sarh9bw3v4DzvJdodiNQtWDJ
argzL+jUfkJD42nlIM1rJZCdD/TyKXyhe3n/ALG8ckyuDdpjG3CLtjOszyPTtyKz0bDPS4bQ8Dkz
vtJQmEBuE17E/wASN5v1g7ir5HWjMWU+Aq4rOg8dH8GWbdHKgI2wU+dRv0hPJ+2Mfr8htfpJq1eT
e55FnkrhwYw2hflgIzyIJkuklZorYya0lLEJPJjcq14Mcp1yrRJOLMZjlXLFW4YRMvsspF0n8CEN
1tCXptdic2zMBBdUewhcVPBMEyc4Myn5CCY9hRXIaTB2aH/4Q5qip5Z0ORrSyxHrHwZWNLibEbNi
NG0Bi3An2iEOiZLFWLmn0OC6u3NCbAX8KvDQ0pS1gT/ykZrWXgzxDuTpwgkjAk5VUYCRl9DGROTF
cUvbegy+8PIbv4JVDS6EH+lDUcnR1IhWmQ3AshYIXF5X8LSqvYrKxMYGpGh0ErH0lXQ3JLg/4YxH
rD4Fe6tFuy5GU2I2+KR9aHutGAmTFMsydjA2PQtjrYvwSUZZOteywxWWTJ7+5jGsoW+gqozTEbSp
agVlptwQrofEq/A7Z0VMQYMsroZ8CyppdlEKjB5xFl+HrA8uj5NYKOeQUlJMdOBJmnkxufkZWLyj
F6CXN7LLNvoZE2Q2ybBBWVJDBsEVPk0KmxshwUIM5OJGLszfTwNWng/kEKPLoetpBSTa4VC1tl56
hi3ahlAB9amNiwgibGoLRCYr2xAWTkczBRSVr0b72iUD8EW7kJTXlNr2D1hB1YceWJb0CeeOYcnD
iJy8vgfEsD6tHoUh5nIqFhwCrUuSA0sMuPEigvRC3XwMnD6F5wXJXeTYtHUsYPQgNzycTEYzAeCL
Im1fQtK9LorVt2kOqTvJiI4yYc2cjwmIKmw56Emi58i2JdQ8NFYKJarBiovouGz30LKCkqKLQjuI
iO7ItOOgyrPOBP2iGBp1EaGLNCI7K20MC1azgeskiQZuMcEvKSOOXCHSKjJ17K+AaHI7lC7HnKFy
+EtCcywVrZEMHhP4QlGJS/tBOxiS0mlaSLhpmGVUbNbyQaVG6DkzFKWo0MseOUV1+aQrXtbYRjH8
mXFdwi4mahLYuQTjTdjayYN2CitDFGnlojOv2jnG8HH6hWtDZr2uGxsN3Robao6N3HkXdsENTZ4F
jaefA3Fr9HoTbNVsthkIZBhvD2NBOsRjF5fHw2EApB1dFObY0SlMyuFCzEL8ZUFlYFSEVyVpDDRv
byISbMCUs2hqw3mIkTnsQz6zHY36LD7CYmrYl5NDhMa1GR6bTG5WkphzS5uD5V18oT1hwnI6sLeO
zuAILZGr6CD0Y4MgU0VGuok4hiYRWCIMuBC0p1vNQ5SGngllicqSaiMddDBTG9SzJJwWVCZaToZm
g0UtEjTr0wJSpFYMylVgS5UcSJKgYLbOtMKaF2SYbwPiZ0S6H6D6Aozgs0bHzWB6eqMGkPKaeyDr
F5ZWyUayUVI4DsXbrv4ryK4PVlKOaxd8mN+gTaeMQRkkPPIIGZEPAqhI4FShBpijWsWzBCzyh6N8
kWKMuBDy5KsqjFg8BsJ4yZMwN4JEVtmQtik6p0JBpRdiUlFgW2j2aaUQgSkzGNVvoTvIKzPshiWV
ROnLAiKLHBF8CYEC0mJLhELjJJtmaKrhD6Z2s+AabjkonWA0iU0J3DE0KXuKUTBhNULCsw5sstjO
lQgiLk9EFmKJcDcq4+PAuOWB1XVrGZ5uFHPFSwTlYZbK/JBlF0MGqykLtYt5NWEJI2Wx3yVF1M2T
MEp5KjJZ4N3UuGaokkPaiig4LsrS6Nkit1wUnxKZXq0IMW7PA4qeIkKCkpOWLaEvBEJUbcH9tKRO
CvmDfKwhZMrgM0zQu0sIixjAyS5sScWDUrLQZakE2WvmDei2eQ7lHNGNLCHDcNcD4gtUkEuaw0QV
izomfgltILjLeWhWTnwaVoepJMQzE6MNSBTRY6CXEw4ZKk3bBvU8GC06tGo0+MCnFJwIplfoT1o2
+SswA1My60uZ9mDeXakYyo6FVm6aHERzTHItFkF3ItF+lSH9DGh0Bf4hcmg1BaO3KSG8wgtvJXI+
vGrMl3c0GqeFoy3FWT2UYOKGVEhiknAP/avDJrzYXwcRjDSdCmNv1gbynkacs4FYjwxincV5VZzO
SpjNy/jyK62lFEVSsj7jDs18ybLs+4RJVTwImzWAxU3HZlGLhwXTCfonCctvAnmVxWZ3TCG/zqs3
GTFMbRkObc32L2qUgvaMWrbqOikeBi5AawmtRRGQNbcGFBMjsLaI45mhil0hXIawz6I1SjZEB1ZU
HPUteRwS6sEppXhzkS2DOBmKUjzT6DqjYMsUid1E6xedNcGEnhLSrNQpV/gxGOGHunDcZgC4f6bi
mmUNSOzFIIeJEajsPdpVnWS3gJpZHpRvieBqEUg/RtWxnCmD/pF8F/yPcjtli+jFcnt+msaozgon
bdIZRrP/AJBlOTjgZ6pVuMoX6foxLhzSHC3BluQkie5f2LJHJCARpH5/9Fa2pIrOib6UUV+P+mmE
Baum6Ijf/dDXtpoxfi60NBrJ9GujAUhTLOiRobtrhGMInpcCqvMGVtFDtUcxG0jX2Q/yYKt4DxYq
pTP6KukLD0MayRjGDuP060CirA1fhMjxoPZtjwN0V4MpiXYn24/jq63YlFX2YBuExcopKghQ4Q18
VkFMLp42UPA9nyIVjRpiHvAkiT44Gg2SuCROEtGs0N7t2La5N8JYSFRS7JdFANcagp15Li4+Gpbi
5ztluiDW3nQhu7PC4JzLGOZ8icyP4iabUooejQOC7gafxVK0cOhUTWgpL4TOAS9AyUllIhTX/BXr
HRKaOkmLnqC3iWVxaIQRUuGKqGIXRwd8leJD1pWSy3gRmIk7FkrhwcLAl1ZBcScF1syYKeTGkR62
KShH0o2tr7+ElhQXgIaWL0LnbAn2EdprDoiCgL5i/ACk66NViVPBicZQp+BF0vkVOQwr6Fi96E16
H3J+llb+K4sSmGssku1jAhEvAdWjo2QzJEy9DiW1qldU2EDJsPhRbSHWVNG8iDdVImy2YM7XaUe0
hLByvPITOhGQ0G5sxAqVF5NtvpgRUnCaLlyiDjNVrol46poCVGyhHSdcjlgyd/X9GqFyO2vscyNF
NNhKQn78mf8Ab/DV4ogbbGWjVeB+j2fa0PXSmuRYA6OZ6LXlMcttvETc8sogKmCJFHybGZSTTxDF
yt1kaCBkHYh9d0ryPp4Y5BeZye5uNYlDHCmRlGAuhxOmWdMUEr+9kP7yosNNiVJNtCoGUusZD+hP
hxj4npKVg7CTlWEmOqXY+hYmUqvBz5mfoh1tRdHX/hi42C6bxLwPFDa93R2JXCSIZ6b/AAQmOl0c
T3ks68P9HseP8Atrlh+hg/EpPn/yEQ1J9w6XlA6lf/pmROTupeTOvHIh5pU/0R0vr0IbqPpGLWAw
FdtkzPS7hszHDXDPMI/0kDvpdZMOim/RZcNP9Gq2fA+hdu2TQ1ZWIG5234JyMX4JWPL4fmK1ngby
JWTJHnwmIS20KsYo+df+w93gkxqDFvO1IYiZtHbL4Eytg9YBkk9Mciuuwwe2hgwS+iE6vbJf18J8
TI3n4JDZXRZL2chk0yTfxCPT7FfJnuhYE8PAtdfAlJuBfpmnwGwb3DllsfGWCNGx5K+2DLxoV5Rw
SeYLBWMfkCfwAWZVWs8iCmxdUzClORMG9FWPLQpWNPgWjwFcWOtoaociwonFljcZI1eRgV4F0SsY
gmmBoYq7bgcb97GlMTnHIKrRJF7HkHloXQuxlsHB3aOc+o2MeGZxsiUuzMNm8onW69USlidG1hgl
tyM5UdmU1OxDYWpZCuKNCqGM5K2jKLlkZ8RDmskUVz4NSqxRWwwrQ8MXFnL5YiqG03k6BBHdv8BF
cEFR2C5IZVqe+BSwZQ2ck6JeDGxLYc31E1DSQgtyJUXshqNZFl+BBJ0bSrOEZwlgDMnKF1DUwb8u
iml0Z4K6PCgSDJvQ+Ky2NjONDBLloaMy6MYQgvkEmXSJ6F/oh63SrSwUF1nKJhM3Q4f/ANh2ObkP
2FFXbdBGZJRCP64YEIYwUFZpFTaFayNiTIk5yX2NEEj4UMrumaIeswV0ZNHfV4VxK8iUuUTUsvf2
RTx030lwxVNo9jmeREGq4Flc29PwLKCOJlPEXlq16IghsF6Exfhri8kIVducCTjgmmaxngQXh+Qv
ikX8rZ5ntbNjjLXNoEYBsW+BCVhsLpy6aE9OIENWVRUttoUBxADuMcwZmwlVePikMAjVZC4To7Ku
DaXCwG7aYZ6J3cq2PnwzfQ2WVcH6IlckkUrXhBwWlsyIECm3yOh7YM9E2xmiINN9lOaWKmI1lEpM
TwkPyOsaoi8BEVrGRjeVmbI/mRjutPCcopwsCsWEiTmMzn+I7GhscbKJ9CqIS8KyICFoMNJnIByd
wLaTcQespX+4dTwlbi7FNEyR4HtawW2MlptlDkawkThC3YSomuadmaETItNBKiBiSUMipbqWmNAQ
5ROBRR7YH1waPKRnRmtRizywdOCiT4aosCixGMrGC27BvYmsFn6JIx3yGwq1OaBS2R1DQ32kyUwe
ox2hrAWJVbwYZk0xxWEQrRFRONXwKafE4cPIbnKQOkzgi7Kz+HwOR1klJ5EmOHYWxdIyV+FDdIaS
w/wSR3KvYqK4bEbVGfJZIKY/mFDCfKGqCiHrc8mIO1walw7MM1FNBPyYw72QhiBaT4eNjUmJtjqX
OYpPnJKsoXYlKWXsWkPYqwol6QXhC1kSNjnUhkrDJTGnS4mSEc6CKqr2VPB9hL1GBLtgxJpy54GO
M6cpVNPAxx9CyAh09scpZvk/gwRi98C2+lkfqwITAshIqt8GPOL4sbDHUppSE4OiWoX3HtsEJW62
bMXyINUEQRU89LJM4VckWMC04w/I8XYDbIhJdUF9ld4HqkyFMqZxSsjQqmRS1j6NKTCO7WIyLCFm
EFqo3ASPCCdzBm0aWTaQfFX4L1i5MRFwRmgcDgUW0bG4moQ9HyBIZSc8lai9j8no5iT2BNVKQw2k
LJxZwPaptwXwkKlzL7MCqLnkV1pBvC1Ry05RVRC+I4ZQoyfAkFIbyiO83eDS08kVSJDijoczCYdG
BbbRO+uQ59Mlehb7ALvSm8D2G3VoUzoUMuFRiEdpZZkGj7Q8WfTGDBQSF52l5M7XMFRdg8iOXmHK
SqS5XTudHMSbpoBecClpElXK2O+vWQnbM7lObRcMyVwXo4MMD5InLJUxcce3o2d6ML8NIXITtLka
CJa6GjROPyNEaVtLGrMkfFexSDOUJWWjVrRD4QpgmSYn0XRPVnAiM57MaG3PEGDUJKFNN+oajnRl
GN/DBjEtYZqg8RiAtnteR0c6DDW+DlZC9Ga66GDSqZojfocplvseW5ZLChgWSpUNIu9/BRRRqk5p
jhTTG4RqQ+Xnkbc66DZB20ekahNhnmFgTtXgp/LFHkfsHHUmQsMynTX4vobJzYxC3vX2Y0jQxXLd
jpM6voSYuGNQogLlauKWCwxYDkbFj2W3Ymi7VML9biDXO2rZ7IMjvLwDGylIMXu06OFG5hAr+Q9P
YxS71CBItK59l0+VfwbEhpbLmDx9jVMmLRxDVSjTgZ0vgi5CFgW4t8GiByiRDJaUI2zE8SW7F7VK
9tnCwcvkfYZFhDWRSNb4FV4F5EbQx4EOG7Q8PkPRdPgmSE9jTK9fDcMiHvwJzQxsCXKa4M4ztFGb
b3SHiE39wc3EtEyEzA9iF/0ZtoumryZk32Gtd5+FBuY15D8hhYgEuBaIifKZfcR9C4E4De6w0N8r
ij1CrmlfNFVZJqegZrt5Htu/olTJLGWL428qObRlAmosrp2Na74G2Q/3mE7ryGnWzbfqi/7ajg9h
zZIXb+4ho+w26ZMQlh6Y+Rb4TG1sSMjXFEmyxKxgbbItjZFD2TIxpX6MzeXhj6WmXXVmNjAo3lMc
z/0gznkgyIWpteKPggpASC+o+dHCbV2Y14a3kcs2SzyE5/FGNzZS7JkPiO+SUYKpsZM61kn1S9Dc
27RHYqEJdNY9N+i8rkqQ3mkE2B+7kZ3IYx0+RgblMj/Vh8Bt09GZgzw70PI6Zl02GJ+H7HN7vIiV
jSpt/oVj0J2Y6pyK3HkaLQ4hvJL9e0mN+h9DhbZ2LjyNQbWH5BPngxttYGs6SJCdJ5aiD2HSu39R
Ghq9DSveVEUbPEQ5J7g8nJ3cDLOuDpOTPoK8xYwS2WrpDxcHWTP9Q4oyyxLSS5CD6JhvDpveyRJG
9hX9u5RRrt9kQlZ6EAaApcMSZfoQDFppl2yLaN6pixchibgcwvijB3gxANmPLRURarky9m5MOETy
V9hECVfA+Lg/9cGbZNMTL2T2bYmyRv4ZH/2T+hQ4NfM0JVX6MY2TIXHRYVGRoj0SGVcGLcDFi5uR
trJ0wJoTljJYKVyRPJohBvmuDANo+DEeEakZ2TzQrYvWf0RRt4IVTqbH7AogWSPlITm8cvGxh00j
kFvgLNG4/A//ACGB+PsyKik10ZjeDWxZ7qiKu3AUTy8poVET0o8ahLgU2oiv731DMa8Cw27yiNWd
5HZrPGjD0CrSp+XJwQ0NOEhscdhuGmb+FTyeD7InpkwwGgyLaUOxZsKZFiyMRFTN2CGrcQU9V9CC
Ql9CDNJMrpoMsD2rhsa9l5KUzBB9Vfod2RYJB5Eh028jFJeRqITKM6nOpknb8FuGrCCY3k8D1mm+
mjVtCCrIgjfAVmmAip9DAnR/xIPtB2PJyM8VforpgVkeyW8PXYtkVI/JAYvAY6RfAjoXj8iInpQz
sg6s22N4FPgH5TPR+CQI4KyFhnDKir2g11UherHCqfPA6fmMT5biIeYNTy+i+YI5/nKFYj7HzShM
pzljg0CrjBn+gQNjtDIbPEPBqDpmZ5exYWVcDW/qCfbvAsoHWaY4fUXIFAWByN1bpCgj+QkxZXd6
PArq9OIRlIfgyr+BbU64EWBuCa0dspRNiGtdzBcc36iFmzaETPcUMSmOEwpgQGXYHPBaw/AgyLJg
WS48jW/oEz5CwLfodgGSJtEMGE/ATS2axtiom6XNQttdkQTbiLQjXmDkxC3UzaRLtqPU8bj5MPb7
ID+ktjMy+Uzyvba2ODRLEQ7p8DcCWBGRkqSS8NDt1qShuBhpJEzpAh0n2inEs4QmjzkXKnzjAqng
Ygvzn0YDn6GzTT2GP+yRZ40xb/QGYlpZBzY3/BFxXp8bCxkqCoUENSruIyF7YS5NjDGmP4VLNQln
eQ8sahdaBlxFwNGe56JcW+hocIE8sHc+IFoq9CBJhdFUVr/SxJBG0zDQx54UuhbpGg9MhrS4RF0o
IhdkyRYDyCUcnHlCY2aiGAAw3o6aRKvgQGU0xUISuPBxmz+SUXvQ/auAS6EjyJ0uIOS09BlO1SWU
Qianj7NW8FDuZGxN0UmBt0AbqJ0ED1SEUN2F+j8DCmdyvsw7MVg3GeUHSfFw0jAKgBcaqNqdwgrZ
7J97+RaX2ZhZpE0T94SxoxXa70cZTGE/moSnBtihduLs1oYQ7TD2JnAsIRmXYsoVMRw0Q8spjQ2V
HSC7M9DmlWJ4Gqnk3MMcMvRWx40TFRxSsnoZfkmysoYStBaeFKloj4iF4DOJHmC2eBSQqgMybW6E
ojB63R0YasYGzK+iCF2XHkrORtsag2wlmaaOJm0noarE9CGlSBGpKusD0QmQ4kuahDSa/AYyU0Iq
DHQ2Ab4MJfwU6sWzlIkUbpNkYEkiiwJUCpjA3gsZXTN0eBjqey0QiKIQ19LRxCUWhPWsDYKuhFi0
GVjbQYMHjgyihk3AkykvAecRjA1INEFB9pbeRXwRDwdV4G6bGMGcKKLgPcs4OAGonOo0RlIc1bMx
BMGWTODHJuGB1sTdYGuDMOySklCQ+r4EMqvJiiY6HhWWhMlbR7YKMq9IeYqg7VYtYF3BQhHCFLDL
yxYUhh5ZZYSwboTMo0h4cWSgq7wLXwkPHUVSeXzJVa2RcbUTXLMndkLzXDClB9iGTVGoZCzNrKCX
A5zpqn0W82LroxhqJDxignw9s14g0E75HpkqQytL5DmzBI8hKfELqlCuyg6ZL+ik9IKY6bhGiY1N
Ks1xGckq0e9cGG19aELignAaNIQjkJDd4NoUamhTmJSwZORqCpRtWFZ4RVBu4sN0r+hT1WAu+VBj
Spj6hN6GVgJkczKSBKnW4LG0JQTI0EplIFevLC8ikbVDlDLzguyNOv0N3qyMMrBUWscHL0EeNTA/
YOBoLaMT2Co4Js6ZJpNaS/QQw2xBmtwbRCue/gu1YYj7VFbmZPIlwuKQhM9B2bayHfyES1sUG1mZ
wRPUZtvdyeBiJOpAciQ5Z1slYXArvnsRCmED61LofB5NCycuWbVAqMpmLu7wJGIq7Y4dCLRHOdNr
QbNwNIg1UUtZ74psxltu6dF9w1BnDvQhTCHPdC8C6iDxCKJbaYmKMGC00lfoyQwley82oJVtkWs1
uF2iB2m0sxPUR/CZNvtQsvsmFMuxlI14Qpmwey0zcwRchuuk2utTIBjlySlry3wMa4HWxDdSSq4H
X6rOWFBSJwMoE1UblZI5o6xMv4SC4Uhi4v4RKQyPbwiZtk+ODINQtb8kiN2Yw/Xi0JIKoKehkmOT
R1UciA/IMz0xnNGlcomdIgwZBEIbgTuKup6N9lTwWJCJdvJP+iJhtoPWwcFhsw+DDMn6GQaZkRFo
qm6FmGncSro0MzsztcaMYmxoYphGdU+gEOW2F4PBcSZMguhcy5ZVFusC2RWWyTfE4JZKck+MI0LS
gjPYG/sdR9CnVjHQlqZzETJd0JWEH9FH0ilwZgmkyhTx8Bg3ZlFvJ+i4Six42jiwJzC06+KCpscH
QhP1/QxHgRtsesyf0ItmMKjJXgSmArCF3XwgpsDlmtCkloUgiPgS1x4EOwsD9N2iz6SDGJkW2NxC
1K4EifyK61BVOini0aRm/AR2TU7WhYr+P0IEtJioUJar0UJssxPISLwuEOFFEI4ycDg1ySW+hLd6
LjplynSK/wCQsP4RCgmGsCfvMCbgr3EqdxRUylWCTCJNkJUwdQFupvQqeHEKRe5KIgK0awPCaLM6
F7g4nYi23kT34IL6PewlKKRmYMLeWhGK6FPpSJMJ5gkf+EEumXxEE6aaMw2RhkR1LwZv0Q+giScD
LSiCdQhNyuD7Sn7BDlo77Q9gwD/BBTsJV0yDs3D3ghQU/U7vuhD2gtlqCEjQURB1+SFeTkdDKVlB
6KyX8Hx/R6ij1cGfqzl7EAJNkYF/A17RM6G+5yKeEwx52aIWlRpJIRIKTwZvX2CJOxiNPpIrfQ3+
CNvUv9CdCzsZy2hKOOfsc0HZjPMhB8G1H/C48B6PZjAbGTthm+RmgnRIv/QRt0HRSmaqIKjtlYhX
gJVK7IFNOYy7AVGRwLKUfcdXtbx/BGmU7YjFnNMOAjyPjNBUWdVkFFFYDNlbyc3WPoXaUbKWMGlz
glLE2nIJSfgh5XeUJ4Cuj+7bI8UEmVvPmPr3DErNDxs4xa6oMjGzSwxxbyyiSFeRrr4YA5jvTZK8
BDWRVQTSVWKJTowkcHKv0gYtBKFWYW4IaN/B4Zx8QYC8ikzrgduwKr/gzdmDG7dwn6rui/4gz2dK
waq1yaPYGTTZ7Gr5xqJzAtbPoYnWQZK6IlSVptidA4h6DdFLCKIdbGJ2DeRmhd5YxyV4GcqMgGlS
zMwh0SCaInP0LRRepzr2hyYsdQu+XBRDkze/YhlECNqJcgiJNMcEtPoR8kbUP8IO+ZvZu+Rq+qIQ
m1E8THbHUH4Xgg0E2bJjVU15G8CVExEKQ2Fsw6dYzYW0PA+cNkOCsbWdiRVi0kLGHIIl2Nwmgi3v
R57Dz7+EeMJ7EZuYZ25LMb0mh9FrI5jaUrAIrXyNzuBltEKVelBj2HH21wRWwyqi+3KxESTO2Uuc
E7SCUeINaQrq2C4bYyhPJMNz8S0bcl3BgbUNdGJfRCQzk2BGIs2MJWSnOy0gg5yZc2OzEJHpKjhG
aU0uQujrZktVUWTs3nMJJn0E1vPSNB1ozRpoS+oeF5qLfXEEy3MonDD4G9qCE502KeR6MUnVD7no
7RTZ6HpXkUgnTJsYgoqNYfCmbonPocq5JdvR1WYo0QvlKN4Y3Py2QzfC2LIirAzhfE5zXnoxYIrb
PLhF3uYLGZMxD6gPaeXHKFoOluji1F5FIJ1+B1Y7yGOkwHxEpdC17jMGMkFSxrFaUu3gRhDmaUo8
tm+mNjrm1pYE4Sj31AJxmbLrkYDEWBQFmarfZx2VTFUagdmAKkozMcRnmsmyQVyR5N0TiZAN4UIh
mWLYXDcA5peFyLOBvDwuMikODXIbbTEysrkTNdj2y5J0uvIzO4TDqSNdmtrUK6W7DKNMBtilLkU5
qn1oSmxtJ7LvAXK5J7Ms0ZUMO9iq7ieKhsPtaLYzaVwxfIryKDzVFthCZNqSJyVJNl6EzriHAtMr
unKNOEMY0q+plNdQixJvLcCbv9zUcEkIeA1wiVqaJv4KXJNMgmm3gT8/R+fkBSvnT7H0rd1Hwb9p
KYuGyD8jYlK1Ay4zGDbqnhqOQgXiCbnowLRNvBybXZzggseSqG42cjBjejVWsRGZaujfaMiKMJhL
WF5MpM8u7HvLKCvTw8mHmibUEgylJHyCmGNgjGXW1HJb3RF/ZyWheKilFROSwtHgTbFWx5D10JMd
Qzgm5yYhQK1iMBTJE+mKuRMsbAOfV5YxUPkwReCZOuLKgUDQXLWxct4VU7cikQmjeAro/DHNPGhn
PnsYku9FPr2dqtMblgcTvISshXNPsYbzISDyGfm1diikItnV7McqogbLLYO9vjt1PAI7J4DPHINm
5GMFn+klc09GpKexZ1afkcR5AwMxtMOhOQXytJi3YMzQRR+x/fHkOqdEt3hF4rDkenfwnDVLZs5Q
nNJOxqdSBj7E3AneRdQKdxGO2A0NaEnrAM+S9GsigoYLfI+cmkR0ZFb4LbzGroXhMBitFmacHKTw
MmUoRTyjwY/k8TPImsxcFcnQv8aaIHCE5FELZuB1Z4Dv+wKEgmljyf1VFk18DhiTZosqvUY0eR5x
4/wKh2DFxEN0jsRs0RknwHajoi3NjLEFJQ81xtDJlxO7MiCJi4+yJXCSyJeKp7MyNo269haF0dVV
4IY/UxvgqYqtRlAZIZMFWD/BGyUiRsymbQUme13oko0VjylDDQuycYMDN+QeIDoPTWZ0nWZsDIyJ
yXY10KThV6zdEQGVYcBa8AsbT90TCbn5+PAUxunwTE2IqYiTycKGGeIUtVdY7152LMU9vgvJ+gEQ
t8g17oVYTJc6Q2R9zhHCK/0RzlCtCcBOggx2q4pEYyjNeRfA8mWNzOoYE5YxiEZk0mUzae3yKcrF
NBZLqoXAgImoYmVbgaF10T31GuB9p5YWBJJtGJiWbcmAj0Qj8mbFpG0TEgW1GxiU2g7tx0TJ2RwI
tcQWq3R2bP2JkaeeRkSLxQzaco8RwzeuULRafVFrHzR3/wBcWavYfdcD7EhWiEE2OjloGRYvBpV1
ykXVV2ixDwZDUeJkupbKXYoNNf2I6CSsrL/RE7Jp1zblmem67VHRnGPJkB05ZfFPpsUMJO7eBoFd
aPwtmk7Iy/1gVpPTY+vxCgak1kWobd2afBYKhIcCweg0w7bodwqf/wBm5cj2h1lGN+wIaxFeBqdf
Qk7bjKaFxDaKmNn+WYLJ9icuDws6o4Ng4XFBrTnoXnTWBF221splwPoxEwNYGhse4bYrTLQlgamP
hpHocHapWSEY0j8kPlyOE7GhYqptjwYvbGPYa8J0Ok6ogMjHVf0bYQsOxWyf9NTTwWW9hv0Gsngr
TITIyXL7CpZfYyieTW4FrvsxjZ3klYWZevp8UEOZo/0AGj1RtJkqQXgZw2lL2b7TNGnOSpifgWG5
PwWY8heh+AhP+miNVwSlQZHcmrsSMPbKymOVuzMKhqmmcIPYzJqjWg8yfqmEJ5DwzJQwYrPa4Ygy
mhvjdChq2fDHhIWO23kSWNoJ5q+hoezKxyjOAeBu3gxqdCn7VH1PB5Fio9utC+5XQ+AoMJo4A00N
G0zYZXaOEcL+zW7FN5CIeTFGPM+yuMoiIpBobMSx4LdCxpyuRguuxtfqDX3zUOrdRnd6GMQl2wzN
j8jzQdfEiUyrsbSGhm+Pgux4+ybNjlIbIiMN5CiplcIapu2NW2UFvCLXs2AyaPwZao36F+Lcornt
5JZ7eBAtX+DPqu3wI6k9ieKn09jxZedDAMLtA3f+Qs7SiOucBX5ubdEqTtJbs7pcTyFrwkzsOqbe
8k8jqXhM2BF+8S5F8sWJUGgRCb4vsQZPJZFRF2AY+ZC2qVapb0bCKRdBgIpP7XJFJIPlFscIXJwa
UpFuxg+Jz0QvqF7g0Vhk8G0Lar2YMko1tI8CjDEdt9CPLqqQqcFyij8Di2Do2ZsnGb+/DIk+mMxp
PAhItJn7iGRzkbRH3YxMnpD3ZCrwNieFkEzyNxpy2ELj7g9A/RY193Zl0XCcLIhYoJbgzII7jaGI
P5CS4c65IoGvwSZTYKYmeiDqua0LSSvoYjUmqsD72zQywKTa0MTs4E/vDlEy5vInUbspQyqhmAei
G+9ujFZTAELw2mYso8IonFoa4JIXydBsx1D1NyIlY8bIuQlotYjlyvoSJbQp2Uxj4jrOVpFISt/D
TEvI3LJ+iMAVbINajUdiTRCaJcjVv6iHxYI5hDSozkrbgm4LkfQjMkVrBoZck9g2qKwlYKaS7Iy5
NIXiTbE5qdGhBeJclx5udDWMBEOAiNF9DOeAl5IsdP4Vdm+3MhmWG3geEvsO4g6RHkQiCWfjyeIU
M8YvAnJwQDnqGcSvB0NjJOhaT4ULsgTlpoWq+tFK0iQueNDx8fgQvNi/JTIwGEM8YXRcE34Hqr2N
6Rjge3g8CUkP6FeChNWBx2ZEqfZ/dAvll6IyQQ2hURWRbWnLHWxiCtVwWngDzQQ4wI/l1EVdW/Ix
G1IcqXll9RxnAwloyercExS6jelIbSsFNYFlh+ikmvRocTEcGmWyEIjPgbiogLNuCQVAkzU4HukY
fZb94sJfBZVhvAmaJmovUqLhFYde2IrQ7QyqacIa79QdvEEhli2GL4yNKilJphyhgKXhFPBRkJPa
aHkjS43hF+UzlFCkvBij9HjEPQpjQbarOEI5dsCciWBCWaiWU5wUiek8gaE80U/nYH3niHy+iMUI
GZoRdJAlPA8FkSldyQcQnUZBtTgwXLsVII5KDbiMTEryWkTbXRPY8DVschGWZePImXikEDsVDx7C
uRezCRjClez9vSLLyD1HahjkuQjTuWBlaaDp0y2S8CXLGxavBLl3sWH5HgTFeZI3+FTEG+Rks/Ih
oehtnEGH1XaNCy4yXBG5SsGCTJZduSIbqG0p5fhydGV2ldQSVVKFAjHJDEPN9E1GmckbSLn0I9rO
oMlNJlYE2Mxon2J8BZk/QIC0doQAjuh+UmdgpoTcsaE6Uv6axvCN68vlwnlrFkGpIs5kjAVAatSi
EYN4diWmOnDGLtGiumfc4EdUZcwXS3Wxqcnw5nVBpXDMulAptkuLZRiabhdoU+BFldky9rFjY28r
oiC2/Dnjihkdaw7Ec1l58Cirk4ONi0myezMXQQHg2bIWMiI0w83DFfS5+gySRpijE6Das232y8rb
XLY5GSn+yDwmOUJk0kzHmZGlDQXwsbHnfwfBufZjyI8jPXMGRC1A5CRniWOmX9LDPsnRRdfQxykk
hMcaQQaaWGFdbwQBLfBny2hi9wTgfgl6xdGAGEOOxqiTFabnwzaILQsUXw8HS5KNGUAfJLC0iZbz
F25wQaSFkyJbEVJa8IvKI10qIjmcDbN7CVeMIpkdeRhhExoeBgpLkdTcsdiWcDSGtjs19CCkglS2
j6ELmg8tQl1HcUnUcOZwO2V8QE1ET0YMgl0sB4VZHNRuhMSlaMNIRPzgcGFS0fHZESOToyy3BFAT
wI9SyYeh4H8JWLBhiQz5n4NHaQ2Ia8CsE6rmWEfeeCMlFM4q0kxHkjYuusTEOKRE1sJCtUzzBUUF
OiN57MWJ+g4qvI4UYFXXJ6FJ0c8CsK0VcArOM+DSReDGuG4McLQmGTmG6lWuCFUH6LfQvEoQT0ET
GGaAJDVKqbjHeKoPXmDCJ6CspWzQ3jBpGSJNYHdy4oqclQX2A+StiOYpdHYAq8JTP3POjGAZI9Ba
q9DSyIwbmPegJ21oJ2xb9HWBZFfmDRl8MYddFUPamDtcExXfqxSUnNn8WLGUJISjJoK9pbEpc4Bd
FuJDOQMeBD+UCFplMC26Xct+9madSxCUXoiS27ltiCdaBiWrNYohvRrScleYYPlkvOJhOFmd/YhS
TRzy6KfbBM7MR4vRcIemlbWPidtGrF8e2jB3AxErecYLOXeRD3kZJDh0HUYmwWhC+A/ROWy3g1g0
2BJQ2ldDXPBNl3LR/REfRZ+tIJxUEXwzqXwqgySON/guOas4HECwZLYo1NVDCZdiHUrRmyxkP52u
I3IokNej/ogFFtvaH005MZUsiU7SeyYpp6GEsUS6c8uBVxiciNHOCSapoBlmZ/Ipazcj23Sbts/J
ZPNZGiXEzuE04aDyeOBF3hhTwyW4xcEdhNxK0yT/AELf5onCzBSmU89C5S1i8SyGOdslCNWER7Yp
aTwHKpkxvwEvkDAZ5I0Q3TSOAyL9EXfsfWmnlEOLTkmEcDdg0N4Sw2+L5M26J5F6N5khoxV9NeTz
lUcdGnwOa8so9Qi4EIrLe2IJ6GTrQPA8DZ5ga21isXECT3DK9NDejCftCxsZl8CLwJjjZwJ+CEZp
mAeMkNMQuPA3YSGVdf7B6g5viuhLfp4pS8LA4oY/s9iVOJZEV5uCgT5FMrUZNExL1QcLVsQMrkdk
moMBEWrQzgU2IE+0hPhUSsHkVV9D0zXgC5uzUKXgybqXDVNi7hDb9jHy8Yp01wblkZw1G+BO6mRu
qvLGSyXBwYmMB4TtWMFK0R08OhwuBq8a6byyFvIVHgUu02L2FtEILr/hA3onAndC/SFUsxiPTPTD
7WXR4FBRzFsi7LI/IgrmwpPliXh4LukLk0gp6BgvFEJbKETgR8WhRDTeBb3Qati4XDJh4+DQ2uzT
iYOklH2yJMFRhdNQTDyCPOqHmAmhhTD8irju04IivokXsRDXAqo6Y1fZBUy2Qj8M5+TYssaiaq4G
GejSQYAnds3LS2Os5E11ZosU7bHBg8i9G4noRzByHKuZ/wCGQ7/YiJra06VwSs8Ak5dNIW20S5oo
HWGCkZhc8i2kjRQ1ZwZnYf6E03TCHNJEn0LbOIihsrGC2mLRSD2MbGtB9LEDxgjOlCGORWRx0Yse
UM6Tz0N8TVkoTpoh6zfU5GSvwNBzlkobJmvRjimSC1zHWGFCItvyIHj7MnppMbT4EwDSUYdW6uhL
JpuiqvApPwZLAqNwp1SwLRldnJZQfQJkUFmuShCt7sk7llUa4NGeNLIhpPCVOdsrK9lx9zMVRlBc
NaYmSEy0Qs2MrQZbup/RIIWVJ6FSwT9GaSJNoba3kl+aGcBHkQl5YE6raL/FtUfaVk1FTGpnocKj
EaBSHBNlN41j082ak+eUoVuy0QySzFOVC2OXHt3peylyFNNFoeFv9myrA4uPGOG8pv8ATGVlohOS
SiIfiGAENTfJk81ri6EWEqvAQYG0/BpjHhjQdZRRkmJzRTGPJLxI84FJ4wYMSW7FMgkLeRjTOBXP
TAfTiFyZPcHvyNnlyDltrRcb3MCOXFOMaYxTQW/5N2M0+DWTk7+CWPhP4e6Y00NN8jYTmBlcG8DS
L2zBz8wdldi/nuYF0HdoO07kY8rRZ/JG43XJE+gjfvNFxybEYGLjTC+NsOZDyJozUJlHlm6eBvMS
RIhEgQ1ndOSUGD+CkGZXRfE8tjDkSAw0OxsZ4HelwZsYX5UXL2NyB5HcobNMcFyceGIAtEiluSkO
7ELHLYuJBehfj2atBlwIZSQWOSKhsm5yL/zMihshingIomJdC85kWAiUxWnkKYnuC8Ux78m2OgUU
d5JiXA6qolDwJkeHgn+wljbhWjHcxmMFTwzSPMKbHODxGhT1kmNrhi8aOWKiI22YG/yJJWjtTgjY
YZviBKW7IwYkNAeS7W6i8vKO4A9LuEKlUwOmJC9iaEpWUqEvmDP7KJQb4FqmhKVqIULplOBWmG1K
sRJeHyMyFG2+BHWDGtQYUc5ChyOGNJob3PiI3D2nBXhNpw5SHg0OUr6FXeR3RbkRhpIqlk47A3Tv
oJovFjpJORwKzZPJKFd5oyqjkXnVPTFRMYFjq9iFA3JL+G3BBT3gJAIiQnVsnAtpRaXZoi+WNcrg
yVZOVIkKYdHNZkCbPFGq7vBBQpl2W+rdA17qdpsopRbD8y7NG1bjLaQ9ik6Nu1keiJcfZKkadB5S
bQ5mSBTspmTN8DIolA8yNSR/87Rb5vVJs6DtQKIalwUNvCZY8uJSfQnMGWBiXTwGQlzKiA8XAvBP
YHFk0oMUU+2ZUkiPQppNV4IK2rTQ4dAJGhkeh8mKRcG8J4KggKt2CRTZjnldkQxYM5ijwOaUySh8
SluUmJT+GjlqqUZbF0dHcxGGC1qDsvvjuStoYEpm6sekIb7wIDUdCQzCkGY0aMxlCO6aQyS5scma
2VVjrq3ae2Uq0086Gxlz7ICnVtO5E9TFl5FN9rBdDzbZrS3IqZYcg+TNqSo5oZMlQSJPik2MG6tZ
H4Nm7w0N8Fcb6I0txI1wIMO0obep/Ege0ewrK8Qa2lu0ZkynYwqRyDAYr+i1s/4NaSo0VwKGg8TJ
SmKbbGyN0WB+XyaMQ5wRwTx5HpT02TKiqz5OY0FS3FEf2B51sxmSO9esQyaSwN0GMeHYlanyxwSf
BbDVIJWVIQoeRHXMTZCjaZhyIniXkaHorTQsNpex58PYRmUXcORjmluFxRILboYAUFBJEyWvQ4in
Y5XbiCa8t4JZSQmlGWFPkpPuMWB2aSiMssaL9L7NyI5psTWQOWElC3upbQj4EGeSC4zZzAYT7KNG
BaMn8MqEO2RUpniJCG8EZuo0hLhopkfgdY1Xki6rYzyHB3zQgNRuDUsMsbXYoLJoV3g5qFNVXYn9
tF9wj63g/IhDuBvZituwvJXiL7gkYMddovgKWdYKMSQ2zKEmERum4NxoyC5o/AcU2ci2LdijEKtT
tlQVwZ6wH1PJjirgfnfQURX/AJCQhQ88WjHJuRDRY/R+5FUd9DismERFz5Fk3mtDPUkXMTscVDE8
hL2tGglLTRmpn8sWmczd09Mi7yNi+b/JoUdllB3gViu4bEDc56Ce+tsMQvmu2x5wfIRZeOHsphDN
0KEq6pgThqKbYZCMsGZv6hgBkFS3c7GRNOkyNDsRZuyxk/3qBzE3Qk62q8GTMWlgLfMQixosY6M1
E1weiIX9DOmNsVHfQjW6MDqbLsahKpykfgJagQ9KsPzKFdV+DKt+L8EdWytEdEoKJZ3Jip5hdmT9
c3QyUa8j1PsSLIxD1ZIArSSZUjbYwG8BZkswMa9ZpvBYzfghwF8MJRS/yTHZUaW6Q8fVMel7ZnWg
yz7aHLIZWi5FmYQnsfsiN8DOktJAtIJqUc88mX+QoJqM3sdX+QqHyilSmmcg68y4psRugKO9FSGY
edmUg8TDoR/tGi5RMsn2IwmNyaEpdF4NDyIHxhq8D6w09p5pHD8HDBeVPgPaLdjfI/tRjXXVD1cv
jwbV4N8LDSY6su2mxsjFt8cGUNjahv4zaEjykOPAnAzNmbEkgiW014KbJmRzBk+wc3Dh3E7oXOXs
ktsvRy4FGZwkVq12M1XoLglUTMR0Gr4i0eBafw3kuRj0KJDRwjBjlBSlt4HzMGJ5sgnjEsurvJjs
ivI0LpIjBIbGmBAWAOq1DSEYsgjGVOEVv6M1NmGzXRs7PJ5SN7/ZUSC1r/ZpZWEhHoZQGE9lQ3LB
DXLJRtH7FgX7DJ3TTloVSSXvwJLOZoUj6gZh2+Bkb5IIK7H6FL1XY2uQ1T8IKPBbJ48iZQa2z0Nc
zyMd0/BrI7IU0WNDeRyynCXX0SyOaOSUy6/RHTMXR5JGu0yEzG5hUYF5HAYRhhRzzRZtfI0SGngd
U3kvi1gNiRfgFOvcbpKxkypr2NbTIoNgDpDC1WPrR+EJKqPqsaM/9gWK0ME6rtoUSH0UPkf55H1J
Idnh4qKLqGKAEsR7NFQ3WzDgcJCHEc0zfYXCfQNKh7Yrkt5HqeZeRNQdi5sJ80zj2cZ/gVDPkPY3
gp7Dwx7vUyGdjPeQ7MhNPwULDmidtN+xNVtyOqjfTPVbtkbBj8Tr4Y8ApRv1hgtn4YmUrXWTdb2H
aRHRbMGjcmXGEp2KyNz2SWP2GOcGX7J69mJ78iWMBGTHVMRX1k0SKZmDBxe0+Msay7MTrmLn6CxS
9svwf8G1VJ9mBWvwW19I02n4DWKljCHH6iG+kfqmcIvQDjRBsTzYosUh8MNwzseCgz3HgQkMUibr
4FGiMcjRKNxLHoRFET6MgH0iO5w8jqDoi5NaRLafpzIlpKssUeA/IiXJTHwrjbhkmvQ1jzj/APwa
87iBIopz5OH9UzhaQrm3gUqpwqG06NOVxpjBZDoYwT67LpNchRVcoTH1zTFOVjwQmKtlnJB7RJdE
CReGZfYEHCzhG4TiZYemyxC84UDQsXBtu10PtLFJXWmPIbVY7Qg7Ea+qSTyJheUTDG/DkSWSTqi9
SnwXApMgrJ95avQ9NXTg5hKjs4G/JwcEKHtmCtZHhdLoqXsko0xbSFUquqI6KmiFZuF0KtlYjLDI
AJnwEjG/DBKvojNecDTML9ZH/Io+e5PRHLjA4YM+AfxOyqnJN4MtCz38IPEGoSVZIcgVCSRPAxLR
PYvwmIqBrUasUAr3gbScgYq+0QlOkJwbxgVykexUX4i5KCmRjYzThxjkkxfp+UWlEazwBLSJsPad
9iLv+ZlaGIssGVJY/GQxVL7KzkG7aHPQyS5TZlSzLpicTFnBhGscImOSFkq6TGNJB96CsiPnkQJj
At78kd3WxUfnGYvsaFxZm4IpdOyaS+x7N4ENZcQ/D4SrA6TvSg24KmKMTSvwObO8EJdTnsWQwQnW
m1jTI3wMilYL0el2SbmYwRmBeBcVfwV8QuULQfoRQk/KEluciaGiSp6HhtUt6LCSwIjWxxgr08FW
5ydfZIMqWCc2noG97vhDParHQkQIKQj7wYF/ghbtILtqS5FzTKMnz9C69+Bk4BpNFjgOBpp/AnoJ
dNDXy8ISw2sIalSXoajSLPgWWXvR55w3iNSBpdGahHgJ5icD8i+ozprDY0MVEElj0LTEEwew9UAl
CcGLMzlCybgnIz/QFhMARdMAsKSMVlbfIjcRNvDF6P3G9wbLlU1vpiTyWaYxn9yYIePJcbfHwQYx
K1GLCHnk2kOSVsJgZVapjDK1mMSlmBsREzw4eoCCY3Juji2Uxi6GOigKjDUPoIvDehGnqmalJMVQ
tli1YONr4QQdKE+o/MCTgxBgpYFSU5I0xlyIzNdhiPjTjT4O05SlHnCDU2kibTNFBazkAySiraB5
5YrDjy1CfX2iKrJgbvUXCYecwVvGLRjDHI05u0SmyWGCkeegrJuqwEfoRWiT5IVdClPu2PZwASDB
CRuTsEBiSuRZybgokiaDOZkTcFG/oGTw5RvgJTZxSdCYYplHO7lzoz+nILrZjfgQlGKfYrpq2W62
r7Mivc7C7N7AhYLfwJzRjfBP6Z4nPlIOQvAc3xNJj+YxIsFxImyXhuydeaLs3Xh3NjAr53QeVUI7
gOgJElOhim9f2YMbN0h9oRy3RfCcIbfDXkTPZCHmZMFYgM14kVXoc+5O+xs8mkg053jBCGOzI9ps
UNdCnqkIqTg2cFEOwTNWi6MLMIAzBDFML4jabJkayQ5G2QW/gkVFmCX6tEIKJYnA+9Y+BYrkp7fk
Z4x3lrJZEHWFoWBKGIS4mOiCvhtiyir5FCJgwrBtBURAvAnTIVAXbjaJdCJElTZZzL8GBpVk9NSu
ecEwKsLA+rggtNGFzXoUFKKGF2Y3tq01Ix0UkssoUrg6+TZOHgVaaxYNjg7oaqKKGq4pqayJK0DX
B2bc0Pm6/AS3XoaVMuhpiXBZ1US3L18BVpsglqtoT84Q9EN5soc6VtRsTEG9eTKDT9EA3gU2x4EL
nDF4CRtNG8nBOcrF3FxTIIVmso/0QeGBH8gOZD3gYd6NCPIIYtGvDT0VFXsIziCIpkZCWzNnIyQ2
wpmJyS6DRegOOGEIfYryMu43PopgtEMy5DGLdCQU0Ggb5HpNOw+EMZ2AQ/x7BLUhXOxGJVFSyT2L
WRK29sV0JNw0yWhDcJ10aWZLDXkzdtfZAyTvJcXNwSZHGBIxaYL7hIy58nsBhkKZNYNF5FtNK8mP
s60GsZXZW00SECOjnI6z9j6NguId7DIVvClsojKiHLIdkXniE+XQzvHsU8dWEkxFcjRk9hUjov15
5H20BOpxh0ZJUkE/iLVeYrVmoWBtUZ7CAQr1xCaVhPgY/wAGBm3UH8s6oXxioX9rCFJE0K+NHGkS
HmCqFlozTLsbvWDWGjDJQnpoRt8TyPI3JsxsFlqYQnj6Gxk0sBIGUv8AgjJLORZbLOzIQhSYlweY
movJ0QaK+9ZbWFSz9FMMm2mIb24EVbrhbCbTl7IGk6F1GTkqs4CVRJeBb8q/6eVV/wAEzVsbgnLZ
ssV2tVk87kkaE5GhEpC8KMIy/X+ldHAPLBmxpfgL8gOAT3BDPxC04yOggv0ceXgsrx/0umFL+DGK
XBt+omb7cpHBn5ML6ijFMwochKENJaEtIQvp2xt0uSjWfhIa+MKHnSIM1k0Km+jCZJX2KnOm1Ecj
5YjnIhDTMFmGDUryYoYOxgsaf0SHcDDvTGGHshqV+CNcwTiM3CBRdm/mxjcZS3x8XWbUK/cOqtow
BJ/RXHkSqhNTsTm1CCd4P3CGce3WODZh5sT1YIZgdYE0ZRDQups+RNHwMU6FnvdFL1iRjwET0F0I
9woroSzyIkoqv0UO2xUj0ICZ0XZAq0FMsVeRKkqh6HyxLfRgZyMkeiBPkxYiHiHXgVkjC+WbFhhR
N3mh07iUbqsF1NI6p5EksCgtVsVc+MDMk+DN8uhVFhwnK2pucKDLgrfYzWKrJEexBaSSRCuFi45b
R0qG5uDjH/NBC2eBTRLAtpwU8aSJNUnjZFou1wOCEkD9vReru7MvaSODXAsIV2m0DaWmS53CfUYj
0cIYp9kYxGt9sqfQDJpekZEvuKxIwvEqmKSixBE2ISOK+y5qlMUahFHgGuIW3nORDYy7AuX0aQgn
KsOz0OBoI8wapGjQ4gBx8pBHJH/kUmVSCmsm0OClLaLVpJrsTSt8QY2NtpjoXioUO6qg8V5ZE+xD
4fFHyzrshmzCGMmnmOF5SOBUqXUBktMEc28iFfhTh6Yh3QJlyEyxYJomiPQJ0Lb0U+z2Lk4f8Gup
5ULzvAv4JReGn/gjteVs7QYwOR3DWSOfQjmQXoyt8mfLh9ZGfWEoUu1ajJ2bklPAYHeQhujAaN0p
mvrS49FiZ4jJi6X/AASR5jNM+QiDuM+TLHoNPKQLoiZqXsZyrK4KvKWi9C26uw7L4Cl26FbXNAnB
WKCi6WqVgzRhYQF2n+l3GaSXoYbXyKK8cDcyV4Ms8DginzOjJG2Y88i06MPFkbZeH+jMEdJfQx2m
+WxRTesxeTVuaLBZx0jkChotT01fQplFsL/tkOyTD/o+pWj0Onoyj2OKulCkb3McRUDJYaE7klwS
2QU5giLBIux276MNQy+DMjJ8W6URc6M9DWExsZtswYdTcbhIZNoPRMXDHSwxmRESBcqBIbwKJWjF
kvJg3gzlnyMYbxDKZOGOxoMoIbGZjAw8/B4EhsQGaQtCehlMJob+9E+MVGOmYNCTrh5lZu0aQpm2
x3foVSxWOvxJJ0iWuyUexmSDEts74SJfajLhgLG9fDhLKKnfiGlaXAXkDpRsoIMqUPA0BrwL1Zrm
cbnIpqwkDQgeRLPcNo5GNiuwzoTbwJxsYH8BrBuDpT4OkrybPGBBjVO4h4O0Zu0LWk+Byt2ZCEup
jZZpipEswbjeoonI0plmd2ciMxcIe2CanMZ6M7OSg8tCe2CtfAVdOCOB/wCDCw1l8sc7oTG8A6Zz
G92eRHVi2W0eXrwJqpdmVxfRbYYw+LkWy21gcxhdjeMpD+jVEkGAngY6qUGU2bTI36lwvITtXVyN
5hti0PbHX5mMe0MR/QMwt+VkWGx7FRgVaiCZ5VnB+uGeNBhYi3uC1KGbjyyylkxJkg6GmzREog1K
r/gpB2Fuszgiqo+42KtLg4Z5DSmBzAahMNSLIa5XBzW5ydELRp9h/VOzCXrYaLb229iMo1jhBxIQ
12nDehvYiyV/T+TXIojeISKrwnRf+oA3cppwTVyKl00KGqaD7gbQHiLPnAmmZLZfsq2OgITPkYrh
aFpYgyXFljsz3kiocycgim8cvoQNxl/Cias9marJCEpGX1pMrjBCzdZFQNZCMhxtPoX21eCtoS8k
qdTCM6EyShIzBRKSvZWlk8GBHGBMZcxljPLpBXSaKgm1sxGLiTJQcZGlOglvCUZEpUnExVDMbM2T
QmNdtiI7YUjjdP7GLjwDCV6YsDYwxxBGQ34+CTIWdMSUZVMeUS7KJPBldCbr5XexSS9w8tJkg5sO
+ODV4rbFVSnDHHdQl2Zd4o3BkXdpneSBT47uXyyV2K4sGiRa/gZMZ0nGZqUo1kHc/DE4LOpBd1NX
Ia2cpBpbjAZ72DkZLuCqmcoij9CfyjyCtGrXo3PCAWttY+zFQpPhi32OijSmB8ofcaKPhjxiDu5F
Oh4IbSCOiVlJlZDrLz4F3VpdiixxkZhuU/JXihYSad8iTiq7IYteIZ6wxpvgbZbHLkHb8BYYP5XJ
c4EhrBRDyKGtoTecXkdkpTnkQyGjHeNzYo1QgkGfLWyGfsWCFTfRSrCG+L2KYKAxN9izAkzkJLW2
2iPz+R7rAyfKdcWmK62Z2RNMMtxWCCwY5AiSwm2VKdsCDoVuTKCFjQ59yF5C8jZoPKu2zOiFPWBS
n7FhZszsLVoFtQ2I6QvDRmFX7CmmT9x4DFIJBL0wJYsjcMYJZNGgyrhItVhLIun2IBJIcjqMNM8C
E8W2VlqmZ0s8HrpJi1bYLbeMCltPJ5F6ioWEUELmkg7KUEEuFoZU5RbyGmYZp9l9V8ssWkYkJQmC
0txitcfJZQptIarJvItNqx5rjIDa9Bw/SohOCexLWR2KcE7FSpPaDGJhcMdkDuya6OWNkVvwxzLY
UQkbV9B/Fjh0avBY55OiYm6bHRYuFSw1maMkdw2OGg7KeB2x1jNTeYPm2tszq+GWLkTUawbEXIRM
pb6PIipjRH+B+l4GoEnsVtaJMfsDyhjKbTtJhDNmDF5FxB0hFiET+iWlCjuOSROsTXNHYdtsb4LH
FAQ60y5/6A0K7b/CAaq+CCzPC5HtvtltTSdZMQ4n3MfZO6U2Z+x4NrJXsF5aGg42p9j0u6rwPe7+
DkgM0WF86hlS7bZTjN3RZRRIPWLiCpPO/I0r2uCrGdQRyg4mfCNF3kNCr8xDlMwCZ3kUhTRyYPAs
XkhGVE2/8M9FXgpbUdUnwprJWoOL6y24x3ieSGRe3yIuxC1uK0TD7eRs+8nn4wmeulHPIYzV0xxV
Sn0fD6O2sMl9cpMUNh3DY+IXG1ZUehXqfVGHnsU42vRpEIzwUlXDGpgfmjujAFe1RO8mKTCNRlgS
9j7BhWa8opgFTLI7b2CmwPl3uOCZPZDBvJKz8Tbkcx+4Hu28s/8A4B+5gE3LXI95NB8MvJnbXiim
o8DJmmIgn4T4tpYGrI/02J9GI1BqKaQWqd6KViPhiGvsXFHkUR6Xg5oy0sDpQXO/4Z+hEA6f0kkb
DcEQpteWISxf6HptWOsjZFfD+CWDAb+HISG8iBVoV0ejQtdikZFqpCr7ODMbIaeEtT6C58ilbJ9W
JC0O3srGwoVp7RknvxDFLAq1TXIuy46YzrkNRPgBtVGFpOTvRwEZknsyXiYHTDSPfGU4ydUr0Z1z
Y+1b4FGTno5hCsIjUEmxp0iqL+xkdV/RMvoNFRp9nmJLqXSGOZPdMqotUb4DoS9jI2yUTb9Ezium
iyoI9jQ0PE1s1CR/wkZZsTYDfCE5pTnGh2efbs2fRQbR60Ule4+mhHHFiT/ZDnNsNaQlAE1FXKsn
gTvt0X0yFTuI30gra95obu3TLLxDL30sh2v9lVbohWrzOGdVLzyPG2MalMLfqNGPTaE9iRnr2zOe
jzsi7TxBSbf2NjSfkZJMI3AlYkcp8jOPD8Ey55QlXYEH2Qgy9lpPAZsRDKlciwVF6eKCPNoKOm0N
kTm+l4FGY7C+r9mMaMR6XkxY0trgxFXkZoIWp8+WPEYxudvgak9NJNwbsS1oRKz/AEenykJzdOhD
/QL7Z8cn6ZY/iO0Qlqy8CM2q0kE1NkLsFXU4PqceTsCKxz4Qi5xyxOWjKJn9RtHjuFbSEnMIxmkL
GNhCuShwC0mE+hpsxpoTAyCHfxSF8vZwRxqKvJhQaaD3oVNCIusXfg4MR1wxJwxNro87oQ63Pf0P
PmjkXOkHxrw0ihpybCnRwFxm9woy3qMCo7Q/HozZXmyKAngLSrCWN8RwLAuGkSIzsso8bgjI6J7M
1UmOx3QlDpF/Y/NvKbFjLzo9TWGX2atXKI52EKqFsdN5hNciItsCvk3TBupYK5KuYFm1rprZeEst
FwsKTBOVS5aHmH4t7GKWgkuRKl6mkYTOvpN3EZomD/wEFWWoIxunof1VYH2iZ9GVUQabG22B50My
RRevnkrElyIZHMJqiD2HbgzisNurSLETVGcAzdOyL7QfWM9FdM0OyJKlaKIdbzxItmNbHToBQBki
jIHj8Gnn4eGB6Mw5DyOGbNkZnOxGpbatKbQLxI0IS1xzoeZIYEokMcYVwhCMc1S+hy0YWyUbzoQB
FBb/AOEmU0e97GBTXQdbFaI/ZhUlMNDkhBEmnaCvBUj/ANDEVTS6KM9ohYmEQS6EKcvRpheDCkIO
xKPUEGFL0NTQkYAhyIVntChpT0iqzP0I7yHaLmCncEu32HuB7E4Fh1oijwEqu0UCXXQyTZ5Ep1Fi
OrQx8U6BvBWpWTM5GaNCHclEJdsjnF4YFowalOkxHRUlxBiqcdFqhHsS6/SGtTThELDbPtDD6oH5
ELlVjUlByZ3oZMC6CKxjoasGJLnyCZtEPnHQ1GDYI0aLolGbGICwELoeWTgyJyeTgtZwTdfBio4C
w7n8NQx0NWzsWGra3PkwJCguobmyBllWxCYPsRCGIM2H5R743kuFvFHxRtC6nfQtIp2PMPZ1nRqM
7FgLuVFVxB2dW0IDykYHcXQrCBw+ZngYlG3g4QnIurloTTUcF9EuA/5XYmtX2FRFm8EgQl9YnvAp
XxC2R2IcWnjgywTFESrN9IiDXTVfidjRVognPAXYG+XOKxdqHRQf7KTJITowQ6EqpHahsUkThRBE
slFQ8WtJljg08yJH/wAwwQsexCVbZyhgV+g3bsk7Q1NwQyU2mhvSTZafgMWrzFUOzwBiWmro+K2X
A8TqDPzjTwISHwGihX5OkUGWqKCEZluwLkWGah3qZvsK+DCGCrIHDq2H0SGMI+TJ4vyNcSpLuKTD
owW3hpiVGBtnIH1FbaJaFRFv4QYtGOhcnYl0TS08lFkmIGJR3AfZvBStebkepESYBxMjIeqv0VCA
dYX0SWc14Ks1eAPBYRCVIfWNFUzbXoQfemMnAXWhIbLZngg1IZiF0jnoVaqQqDkbXocsEtOYJDpK
DQ01JuEJNeFHRBMR4W8CaErvQ/atP2iEc6MooFH3CQnhh6g6qmhwOxGIsGuStGUWL5JT0Tahuhmv
IxQhlSW4VgsanIUr6DPKSM30WziYLn8h3rLI7FtcioM0i0RiC5pIzEKumG1Q0fyDxIccJZMmDL4y
NjZpD0aRRvgwMjQAU+yS+USO4rdRWLgW1MLojlsI3RQ0PANDywxpieNA10DPJRBnidgFDqKXQ2MD
JcfJcpdCGYTeBdMfhQgtusX+mLxnlsKnMse25lFoREg4NIfH3Bla4KJhDk/IKaMzLGR0UD7ohyMY
1k0VeZgj9GO61wLyNsvoUey5FpsDkwaFStIVnbQWh7XIh9cw4mA2II38gkypkWOHgU6JyOp5oza4
HSnQnOWinTUMkkYUrhobPgWYuB7JnXgwk/DIQb4zmUFMTRCklhUYjWQqS5mMJmFTJjDWzNTgbeTi
KaqKdCIaDca4GVJB6cTVsjcijFn4pMyEDCCapzeKDGhLFmgO3BqlkyYJirVjY4LDBOa5MHkFtF91
yK3j0Lwqw+9khI35HwLYNoGgtiY8DNzysC8NZotI0vEuM5k2EbC+PorGxaFUdPPZ5bxcmjY5o8MI
fM3yZwbMFdLK7GNSxGmHQLXSXJw7BpEBWWRJNMp9DEmmN0JVInBhzcxcIZAxVY2I2Mh1TrTA+spa
mWzWkicVHgLuqUFzvGJXMYCJCnI4Ip9i+mk9CcZpp8C6onkLKKgxCCWYgTG5g76oi6vQnSiGkbYJ
ycBEXwJxkb7Hi0jaEy6j/DcoyLsVV0EXdBamyt/Ih1aK2ucmF4doouW0Y8XNQhUZDSkj4pkgv36F
OMl+VI2NC7GqM7htaHZTUEQm8B7CuiGNc5JruIwlJaDHPocim3niNhxz+Dk7Wi8iJpeUE/IthNNJ
8LRdjmDwGPKriTs4Bl/w3Wsm4jD6P8GveTZyg/wTBv8A+wbI7CvoZXn7S/0SE9rbpiYMng5PX/DA
cEom6GFeXY5oWWFK64FWmMjpw5wBF4EZMHHkbjHn4e/hosDfhsZoehVLR42CegK+JC1tcTGceCQ7
F4IdyxQ631Ai2UhXeWCQ0zJxIchTUhpDLxn2CWMyDGwkvhszhj2cl+GJqtaQyf6LJhFbPDYrQXKR
je7TeaVHUFuDBrAJNSnkQkIcTzRh2gsnXHksGTFMZPAwlp3IxVISRyAtzotRyKPDInuE1rZlcIbC
WAvP0IYU7iNI+RZDq/ReatBLkouqJKm1gIqcjfkkhuRUiEyqdkgY3wmNVdn2UBRT2LaVWxFUsEE+
jfQ07SFg0vQhEoGYRSb7ErIyS5ZgtiQb4FpBlAqbfAxLbYqaFYJlZFfeY5sOhDeOkOmotHg1d5Mx
40ZlDESRVItWwtU7M/SL9yyOZ8CPrETAjNJc1TFhmRwKnsxdfSHQGh5H3TLwUyMERLkjERZtiIhD
VdFMekF1srCEb2hlwqbD4l1Bk2vQmfhp8TK+40ZoYex3GW8C0/EDYXJo3/dBGwpIvIN8I3XOWYC2
2PYosiewYXRlIeDOUwjmVJ5cis0xWRsps6FptnyE0S6Hsw0OQLkhV6Gspsm3ipjjW1s0xXWKZx1g
xxaNtCWHsa7TDRvYpLbjiMXfgP8Ac0WDfI9EvQ0onyEye2I1vWs2mCj3KofbWahNXBzspOlUbGzl
MfbktmPhtvoxMbQb3DshPiFwRGslg/8AlAQyfCxKQsH0FDsHlSxf0WZGVTQyupoOIMon7K+ysQgT
3G55kd70Y2ODHPdB5E/OrIg9aDwly5TCG8G0NjOQVhaNDFOMNQQE0Y7HOC4LXC4MStigU6W2/EkJ
QiX4JvwSr+Cpu5P+D3I6xFu//AcOwZOsOCRmGyyxJXoxrivj8DBLiGHKjV+hKORRVO2jr6E8cexC
O4XyVK7eDPyir5KTnBNNwfJwqWOhIZpll1w1HWcPsdush0KauCIYpjh8IyOFNchiQ8DCP7Hj4ehy
ZNHoxyZIZR3AtifQtywIWjD0YMMDgMj1TE5iLmHkJWtB4gNDFCD8rou2TFZGOOQ8fAQ5r0PQ4XI2
Hso2cEwaguzIQ0pIy/A5nBChvVj3HIYQWkTyU7vseFmcT3aMJllacGXOMZ1JyFhFeiuHmzLEnDWI
OK6GXK0FqTopU56HbmggI3gRm1csegNXDO4INezw+MKTG00GhNayxLhkiC+EHqhq1pDl7Al+MjhT
fA51GUzAng1jGEePgmAK2TNgYstwqpmpkpSyKs39hjWwuAdHpix7EHg7lSTIm9iEKVGqdTZBGJnX
BVdCmq8CSQTY+rPk8wIWgtObgzHCpdkhMdsDGhZCcKIUFyvaYnO2xEFWBL+7ExsSQhuU6W+FEMqY
FhrI/wBgyVWhFXKL33BBCdZFoiMmEOvkiDcSF/GGI2Cb9DFpkiE0xLLEp2ISzuKGyU5hWSsRNJLZ
KJe8G+SQT0FnbUSbnxJU5ZkvIigcoV7FNcNPbMqRZr+DUi4mxUuGTJeXsT1ICRvM2u3kcFXlvA7d
fzH0krEVsQMnJYKtyyOk6Tj40ErFJtjeMN5HWV9NDe1BNmN50mMfnGyiyErrWihqo+Ao2tJtjuxI
V1DA6hXkTmA+b7DFtbJjAd5VNE7RpjJEp2BnkIstZuKbU5YueyD/ADjxGHLkGvDNor1chWoGKZYy
8DZYiENt3SLK+AMEfeiyk29C13Vli+AT6hQwZBI5Eklcb2MocEVzSA6cxkIoNWBWdoQwBvgJGoqj
GBqUfhCYx1qOnJqhvm4l5GnzEWJM4tix2wriGUJxoGts2p0P4JVxGZsmWx0Sp0ZC81rFR8FmyAJe
qA4urmx+ZBGK6RzRUER5fhDOm0q7ZkztxEUfUHgG8I2QStuW22P91lkZlpx5mAyOsZzjbGi7y1tJ
wLBs7HMwjIoeLNpzwMabFbPbbNsaHskMbLa6MgtaZ9Eh+UetEkbDXIIWssYwQdyLJDRQ34F/CklF
+L8Vm2SF8LZv8OCDnb+kmbwLsxO1d+SSPFyyYhpp8+xmCMahtFuaXjEM6lNJj+pORcYXNGarYJ8r
JDbQhJiPPAoLJ22LrOfQxZC7GoPDM0j+OSroRjgNY+CXsXRpVkbBb12PhI/TEhGGmK2MmqSIaKXa
zItLQ6K3nIhsTT8pmTFbkMos0HSP2FNn6EUUDHP2GkjJMvMNGv7CmSJoSqNEHs2EwX9C/wB3Y8tQ
lcY3wTADwxfsVjcDOD4JI0S5ZX0I8aMunfZsLex2ysm+UQf/AFMYWxVVyk0b6CU2GMvvwQqHsltm
N+4T0NV9iRHF2WBRdi0pgeBV9mJxRWWZeRYyKTsCfl8svqY4Y9iinoYrErcvsqAf3t9mOCZmjPBL
wJHp+R1bV+maSeRDyZgfrptIg1qydoXsW2U3MVFWlNIYeTQoto2iXlvlsi7E9Kj0JDYekJu1xRG0
izhlY3YqlprsdLGW7Wu6KSS9jdVi7HpMiNiVDFA/Yrru0K9vcIpN0PCX5Iabp5LJMLOWP9JhwKC4
NmSDBZ3cgwrOUV2H3opcCOuZdDeWJULcQ2PBMZU2n0MZtC7ZZ2hqUSg2TTtDDYamPgWYdMYZfydZ
yNhnG7HereBLxuqM2peGKzEYV9MphtPWeR2V9GUWqvLG27LfkW07d5zCkHleR1twmR15FI8Klm8D
yKzcjElF+hLdaej2OFUmtjJv6N8DkmTE8jitQ/I8QBJMgo0QE/WDfQ7QvZzS5E7DfIW4pTRJIonk
0D+FOFyP+LQM37OkMnwfwwicN5zWPkjYS7oxAwGLbOQiMsrFPIyB/dT/AF8TzEcAQWQEw1IQvOvD
+Lixn4HZdWox9jLHmBZHqq8tFrmfI1w2p0TcOw27MaJxVoMZkYG3WH9a6zHBewM4Dsy6hiivHOCV
ffbGy8lso7Q27cTGESZv6G0kX5FVV2Wf6N2vszDAmb0bapyi+Rjy4yFNrhERRdB5sdjk12Ks+IaF
2n0HlhiNDofev7wObsa/+BvDL0hzJO3XYZ2J5N6R2V5DXfA9m3kmEbHskJVRYG3jJPBdIPVf4Jmj
qTNdJfAk1on5LyhvPHl5GdIKq7bffxcms/EehLBC8MScEe2x2HP2Z4xG/Yy6GyeGT8Ig2pvuOQ9f
JoxDtNmINzgxGsFhCH7tr0KFR9GJbT9iY9XoiHV0JqZk2B3kCY3bwOYrGmGxuSl0PDdhPNTJ9Uy1
D2NnOhKhfgrwHSFfGF0SyZhbr9szjH2PbLyK5skWNLrop185JLdEIZrH0gGuG+BWgMXzGR6xDqN9
qMg2XkqIfgwYvImPokK6/QzYHlo0x8BFZD8iE2QjiToWzZ8sfRmEWSJkXsQfePw+DBre0VHgxRZu
c0VseCj+E3ojtxltJyqLPsLi2fEK1rU0hgxiknRpz9miW+KY2DYisvFMimvsR6p3yUy0vQr163ls
fqN+ReStD/meBdR5sbb2Jqr84Guq83gfYHkiV9j9gA7dcdn0aDDKuMn3gAxCXJb5emIKk8CYKhhM
PJQNP2O6jYYNcRwQAGTBkrwBrTI8jnLBkOAGxoOA/raHCDBO2ZmsBYV65IWn4MYLVxghA2PvY5lO
aXAmoKGxlQ2TE+yo8uFiqOBvbfQnphREQ+UNmN5cmYqg/pzykYl+gppgs6I0TtB8qs4Hx91yHKbk
0T2VeCq++9Ewi6bMnnK8nZfxFrG8IcpZSYvjp2Rm64bEFt9jG4sAKckEPgNMIqHzTdibSjW6rEEV
do6KK/YZdfZl2fbF1Da6YppG6FEy9woDHkMRHYimx4HFlMeyHELN6KybFGYaRB0cgfI3QwcouTrC
zsEgsvNiK4vJBjRFwSHkyYVDbHmmXSaMsSib5F7H4M1CRScGQvgXA3Em7QlpkFhlVGHgwkXnGhyE
Tuk41WR+cj00iuYvwMy+Ibbbj/8AIo8vMRXPInV0iFDIwL7NkNplcD28T2MXJ8PRLWAkQglNfAzq
+okZ/Appy22kjAokPBU3MsyfI17+MWMrQVUTF4VDJA8YaHtF4hc7wmo0KwWTQVHZfyH+eZsPhVKF
tjAkuHBbNbYpZ0Q7aJYyWNrnA+7CrCFFm/oFK/Br4Yz+FgjsSSQ7insg0Uk09+CW/J3i2MtvQe4C
u0QbkpeD9iAvWlEL0I0I7JJj2KWSTin/ADgO7EPNJ4HlymwtyH0LgQ4HuDV+J+jQzgTWBFSJsbvx
lqrDKdsa1wdEkCcEpRygrFUtcsyLuEOzJskTLZLUt9D1gcOiCIgf0X0JpjbJMRhyeMIG+hwRFFRB
WUk5MpE8iShOhGTloU0lnlGF0MLIJNnRPESGiwmo2EkW+RdwipJpiQz9vi5FcwyWnyMHA9umCyJV
rAtlIRRhXVEYscCYpCSZ2Y6WuRo7JnAxKGMafCZJO2WQyvZjhNjWknghiIlyKFEvApsHjbwRZJDl
EEoNGmfRGgxvUMnZNhdaW5uDlpbFcZkRGzpXpBgZYLPBswLOqg/RG4Y5bPImYX0cUCqorXg3vux3
JBrw9iUzS1UmhKJPQe8G5CBSeWArpIkhzomOVE0H3CXjGR5wGCrOGLqSgskpOhSlwb7ERQ30gbO4
TWEQlQr4KDGV0YuZdCHBQYImS6rnQ1H8MGMZJ4YpNRJSyhSQC7gDQ1ZCQCafBkEjc+GYjdB+Emoo
IBoaoX0NWxMOCBXswQ3lpmBL7wILc5YZILnbIRzl6NReBtW3TwNMC+hq2xSMuadHshpY00GmnwMc
SVaHLRp8j/8AEyhIomahgNnfJM5SMUQXIUEJ6DS9QlGIRD4FyUS0yQCu2UJJTSZs2Z0UGLazBE5T
f/Air3cE90lRoQMyIjfBJBGLMlJkUTv2Ul49Idbw9Ibw+uFRv4cntohtXjmSCmmEbEnEqE5KGiyd
jXtBJjkqmzQlCpSaaM5q3RyWvJG3SNgqtlYKLhqrZPsT3F4wRoHXyGlnD3owuRrMFASaFiro24Yt
lzbgqSL8DfRc9D5ua5EfF4RT2y6eQxvWV1FBk3aFKJ2lgZYUL5vkTM34EEthNFEBsJjw6EdWecGL
MR4L43A3whKzPGBF+Xf2VzTFRWKjGC44Na6KXfokwaGM0522cilkbtEKS3cb6EXPGMozGHfLYRVV
k/SBBpkE5Z3p5ZeJBdU7P78N4F2PIsfGz6DOYP75HhNjXsMzXR4HYcZhJUkg7yJm8jmjlyqKzYO6
kkkJdDHb3Zp4IPcFWVON7ReWGLkWgukrvNBKm1XAtya5GKmI2PLORmITpDbI10JGx2qZE4QxRic7
wIL1ZBnNJHcppk4ojCGjARlYLZDwL4gckAuBoWL1tkiGdecJ9jNktLoUQ84MwR5ShGsX4HeZnSNB
agMMu0KuWGNx4wPbZpdjgZoq2gu8jhnCzBthXoT400iMLEK5PdQZGYxUWzZkEyrpF8iy/wCldDs3
LhT0LhoXVvpj7gQ1m2UqgI2A6tDmi0TF3KiAmZmRYVkKkQ/uAzHkKpDhpTL1lmJPh1aVmaGWJllX
kT2VcGUwojEhGBlllj20tGAYVNgKF9ds0soayzPgBVkuDDPkOQg/uEU7E1TKQxoYXFoZDLIgOZEV
Tgjs8MWYyMyLgh2FwLBMlDxpiNa4lQbjI+CKWH1f8ENNqMr9SC02mrTn41Fw64BE2LgavKOcMp34
pdFkU5/eC1RDYNiUs1JxuJvZZkNRjCin4YHoii8e3kQLaiE9B2duQpTuMEx3f1F30XA1MmZfghVP
6wYS5Glq2oK1XmyorC4Q1IA0MIuRbKtzB7whl3K/Rg17E/TgQTycO8dDEbyYKzyJaOaU4HZ7wJpq
jH9KK9KxomXb5EY4mL704iFmjppuwjTD0Es+VUO3ga7NwTJiFx2cRDwEENIX00LmjdeRaqj2MO3G
CorW3KDEyQ8Q/wCsB0TYoJ2fURRglF4wlPSvBZez8OUCq5GPK04G1EmNKNNQsCJrsQx1IZeUhqDX
jZ7nPAs9LPNBMUom17Fo0hDYDZgkCvAgEqcF9FRV6ExxhWoUjoiBNPxt3R4JPpAS/aSfBbQqmaMn
bsKvqGJ2RhMS4EYnyY+UTfO+xNKUtGV7/oIpASPB56GDCRgf2JxkSC2+doOLisarJJ4Vq5GLkQ0U
omUi4DyRCVOornYR4mUaQh8jezSKDoppCO9S6ugirf2LrX+xZpLcXAO+1oXHhs+qCJLYNhdBPvQx
fsPt7MhoVIaBHJwLImHls0IPLhtikNQ4gFb5PwXjNVpmses3I1JtIOY9GRfORhmbwVJjj9jg8Y0t
57Go1GFJUii3U3wOuBxItiMbMKZPsS1LQha5Zjgy+gV0kQOjMAUjIwUIF0KQdc4LPbNMPu9ib3ui
NI8GliCqeRnZcikNbgxvqQb5gVsmI6UiuPli4i9xTeg+0dDQmK95JAjrVHHwpmGaPGIzrlk2Ipy9
kYFTo+rHcMgo6FPMyVh0MinCFUNa2JVSEHb8DqYy8NC30UquoOimMq+yCjX6m1M3REmeB059CKzs
j6B1z5Iewnro6kTG2BkkPkG4GhSxn1TYORkkEwMYjaVRDpbYiVOnkqKuZ3AmRUTkg0huZBDyQXtj
dURa0Y0yjIsx7OAwkqG8exbz7tFtJMzI5VlMJKD0Hpt9FIbeO0YqEGRleRZd1NBiJ7T+hY8kvHAx
fcJUqpXViF5rLdKhnkMlg3w4HJSLLJFVXlpCqSrJGck2P+isb8QcacGIlrvsZ1i5MgsqsfhaYtfY
8TjZVGVxyujMeJsrXD/THdTeSRojhne29Tgf4YcsSrsBvAqOIgyay2yPd4JC+JSVIUGdrRNicKwC
SWf5kQj9CGhlWwxmyCpnIzU6vAzyhTzKIfCiq7MFE6yQ2p2lZ9nYh0LraIjE3nnRgfVRUEXuBXuc
zksYGIq85kjZQ0hFeWtj0avSLd5BMtLlcQ9CvQltUmuRngqJSpwDQXBKC5tIGWVJux/OeTE4tMf4
cuLyUflbeRKBm0GrKo+RapcKUtU9WuiaC5OCEb8xUU1ZRyWDepwOuGBK5HgROoybI0uBikVtYj+j
yOTEONCFpNFbE4nJjbGkOn7B9sew5EUanllIaTzwlR3j7b7hatyZ7JI9z9jkrhnqCNPcKIl6IWGW
j6Hslq+EI/iZi7GmfiG4zppCB7IejqIqQKQ3uYTEahqBHakkJeWKmmPLESVzgNs5YZGN3f6Fi5ny
mrTUC0PJk3ifBl2NVoa4EHBNIWxPJt/BNhONuDk7kqH0HDEUg+w0BTp5Is0XBW+RyvyEvQPY/GRo
XYc5hk5a2IHDGqJdohNCHcHa2kYJksCsLZceRkSyy7wY5vgybbevgBobbkQfQthcazo1fcYGMz8Y
c6GNbOjysIaB0LEdmgYMsUfYQXMfA6HnEhsZ0F5Ysp6gPzoKDgyYM13UU+ZMMa0JdGVbkv7EvGlm
jk1IEIK4EojtJTFc7D1EmR6PrwlW6i8T2PExebURUpMi+0QWEJz0E5ItRVgTxbdC1+RsyZaxySCy
IzHkVPAbkXgsgTQ4JwvxSaMRmuBI41kQmpDIwieBOGjlpRbMQ/TtHQ3oRvgsu8JGpsRZ6F60piQb
2pRuJqxLkWkeUhpFKmJfexCnMC4on0NQkCaC6RoZdB0NRD1J8cCk0H9DAtHpkYZV2hPoVROzew5D
xnIl/Yk63+DGU0hM3C0uji5ZEloLtqynLbFwoqM1OwpL9oxhkgglZ7MEBPbH6rawWpwQkIWtCKI1
CQ1ipTY+cBgMmsHW+xq0akjPOnCVpLYSzseTHCSh7VDQdGZs3TBwLZsWRRURPbrApboMXa4/ZZ7M
q+B5Fcq/zJODE5kKyE220NCjYBg8HsWals1DBNMY+RO5IZDdhiNS1VlhAjVCOcODL5QOTkdHWOSm
7qy/047xKKcRqB3/AKxD/anbYZThbBU5vQbh+QL6Qad+SpjEE1KZkgyyrekJdPVqGFiUaMhSXXeR
jWKrYseBbtD0JqzkbcDfFWOY2t0xtjztmcCFshdSfRCQrOMlvWSOA/Hkdzyx39q0Oj3qAtrtBjTn
FeRwYKpGGPsGZJMSjpC0ktxRxaU9J7Q4KN7N89V5E7CYT0ZbnDboXXOk4Y9BlIzkVDEpfshZSdTC
hrEssMzBjD2Pvmu2aJinyY50+ZkRcGht0mRtwWfjkiEug9vgfIzc4HoQ40ayLMhrmSL65op/Vqad
3skYtGLJbUs7MjDyZ6qwIAGJ6IKgmJKNyWvIQbKGt9C7Y0EOYYg1Fb8Kuic/GxIohMI8S9GQEocp
TgUONAMw7VRgIUhGcRtCDi4yFPH7HOmDNpcbQa4Ku0rXY0r9RUNXksJp4HTKYkTaPs7l6oiQiVnQ
2gLHYk6GORtU9sb6iJk4txDWDoYYpjL/ABZZxHpUVcXRsdGReB+Qz6FsfOBypZjq8p0mQ2xRhHSI
/QtdYTojKpJRMYp0LKxMT6t6FkaVfQqmuGxGCldswJGOyBrbobZusQJGGE0jIL+9i/1BMfsKNfOh
URVCHdvoUm+dlMLkIBTvQxl+xhU/ZjI0ex71CVSW8o0LRMfhimwLXKP63eSIN4EVcxWMi9rkpFhS
VjeRu4pwQ2N9C43l8icki0Jehh3dEUlYIJMhLY0SYXkUzb7MmP0xeb4tcDVIv6AzE7jya8G+xB1R
tDqqnbRMfSHRZzlmIyuB4ZdCmWy8pmXv2xbcVeciYZpVkdcrwPzbHQ8lq6CCYBpXDpse8I3RKi+h
N6iZYycOiSqELXVl0tGm+Q9XXQ+n0Xsb0jpc8C7rCyIBEJC232Vtfs9+B0abJHMhpwhawnktixxV
5hgcT4DkmkdOcAUhzkn+Dx2C7Grmp+QqEm1MYMnHRXcxYEzVJGKCvSESLZFEiPMGMSpMhNrB1Mnx
ElHd5TMXhK8kWRiUKh43ksKRnCHc8ylwx/IsdnQTNAmstOPJJ1uFaN44HDNZ2yjQ2TXyJ1GDwcXe
haTGihvgitzcPj4xbED6Yth+jywYfsAb80sWn7oe6uM/Yt2a4SzXJJXtDNN9i75pntbMB9KxhK9h
So/wTTx1NoPliZqK2zT9FIreUZpX2bjjMwq6KixOynhfRKl+yL5kYxSZWofKKRrz4IjSjOxIYNr9
0xuYbpowTFpEVWr0hMm9HyQdaNhMuiSyOGN6MNbTERBW/FcEadPZgPXZc2r4OGztGHOxVPfwbN/G
QyiT4GfkQmNaI3iNkWWI8VF2bqThDw1ioFfJOF6GZj5HlSb2xvZ+lwUjMbCDoMsIhPR/oj3ojmfg
L6ajoNFfGiNE8Cw+SHglEaLsPJkILRr+xkqhOVEdx/vAjYRIZhYZIfkzIQ1LsdWv8DKT2FoLLcEh
tMvbIqul02zEqwZYn2YBr+xyJnZYSTSZGg2L2M2MRs+jPxN5Y2baPJOBNgPIh3EScwWW+gV3K+xM
HZEO/aHtqPUYp5jgTG3VFfDZmwP0f9AJD/FlU0l5LuQ+Udw2WCo/oD/UKIeXTM8OjBMXhlxl+R66
tFoeSNZFZDaWjZXgLXbjk01W9QtOLeSGQ7HoUkUJU06MBYc5OymfgMOXpOi6doE5J/wHzJrybZTs
Ul8mR2f0GPuY4w2O4zlkheXJTGxctAy3uNFI0d4GfK1/TL1eR426Ck6fZazJtwWHm8HG+rYTtq3y
JFQxrnbDpgeSEUXb5QTxz7YwnHYoKRl6lAsq1Oxqw28HMbA38URc2IZo4LZfYh72FnwiBYZfIurR
yZgrxEWv0K7ZBhyOIKivQhZIfm0b2bHYxKH7NPQ5piiKtKOF4KUTOBI6e2Gms36EByvkRBCifeQk
0bSCQ7HBTfARhf0ZQKehxbOYLZgccXKhSvFvYik9aEZ5fWGGM+yUlkRct7K5Ne3DgA4kGR1I5Bd9
8QxFskUiV4YgGsIOj6Bbj2LU/Blwl6IkUGw5M1cHk/R1exNC0+rgQ8CiwZrI/DMYx0K60Z/FeKN4
YfaIXXpuGSkzhv2JapdjAW62FjpeS3Zoeh+o8GiBUVSnJ3YVUSk5XI7Z3odYWGpwQc7W4JMMD0pl
dSHDKkYzQ1XFFTBBle0ScahYaNDw3BAlSTbUzGs8NU6TKCrZETyKbJ4NRl+6L9jWXW0loQCsXiJ0
tDc5DpujcbFrkSgvbbcEy79Foxp22uzNf6fYrU8C9sv1jKT4OGha4+HnjYfcTkvkISHLzyeMifG3
koXVnkMSJQVy/FIfdlmRPBkiDRH8TJ9HGzVjrZubErbJsHq5Zrk3olySkZEBIh9BP6XBR4iyKqys
gIhjYeBGIp6JLTnQpZb+huxYQuMSu0MmNdD9QiCGmbHHkzR5Y0bCVJWaC2JDkXQP7dpNton2kKpn
QmvwIiEHUjQl4oikmRYGQkcJ4ByzpWoiGlMWppGoJIdqmnBdwuwh4DkRUo3pEEFSzEmyYk4PBiGm
hCX4JNcCOrdBWThEHHI/FVHhLeCOySE0tCBlQFs2K2McLWBYOmVlEKyeSCfgOWiT8iwiLxR5hYRM
ArYPaGF/gj9FBM0sENgcJjboh7QNHc+x+KSDUzgeEE8+BGRr2zK0kU8JsVUuIhaDkhjyTFRCIzPB
s5TGiS7GpVscCMOmk9didNI7G8DOqWcHCAKBNPoSiNwcLY9DJ95oQ5HgjThkArooTzBeBu8WvRMQ
heGTD9wIdzuhQPCHlINxCNYMciGkNKSeisRCLF1pC2pSG5q9FzmfgUkytoR1cvoWnxFiIzg5BfIe
coRttPwWtrAl8WF8SDdFKXK/nxMljkmRRqTEpwoDc3dPMFwaxsaKWAvkuypKJMGmTNoJUouDRWcY
y0OVNl7mgx6dCNBQKQBE1m8Cy4loXqdi9H/YhtCK6KBJoiSvEqK8GGhZUzZN3hYICSXMIe0SRRT1
bZeBfkUPIiQTNkq1gdNVYOafYoAr3v8AkWyTC4fF0swNZwa0Fwr3KGX+BmKHPg4I9PyOrapblNm2
3RJ4YvRCkjSB13WMBCLuAyP0RrgYs5cjV6IwaRPJ4EnUfwHwJkijcJgOkNnIxdmGaz3RuAJwWPEr
XP4JLhgoTHyl4g5QngeSGrk89h0YUs1o7JcKeELZBhdDsnhJ4P5lFDWVz0SiZsowlMEd+oN8opR5
OmkSeKKquBqJcnwLaGbwjk5V34LpGJHNcqeBm7y3lD02/kXnq2hDXSBCyqyypGxFQijyGdgyCkc1
DTkKNlrvhS7RvLMIYT2gT3HW3AhJpWNAvYbetiE8in2L4yyysLN+BjYcc/Eh5K+zE8jfonUMmhOB
gGTZbQmazLFT08MV3mHKFSG6SEKbpIPeb4HvQatyie5RUJfjJLaWMjXaGIeJd+HCackGNZEhnPwa
5ZkOBeCR/B5cpsVI44HOxEcvhCw1NC3QIpB9W2ZVwaDzuPiRwjGCPpSLBZN1XksNDqbGX1fwVjeB
3Vs7cy+xvgX/AO4BPwXgwdeCZJ+aTQfBDjuKwe0cJSfRhqNMfE0uAjFpofiHDP8ApaZYeoehhsTT
4E+R4onKwJyKExeqix49FtwG6yPQ3ttZJCsL4+IU12S6Ze4M6KDZGxctifLpsrlgRk6wOD7YSTmH
cIJtBGv0iFcFUb/pxVWDEPYrMTdgxNlZgZi/UKDWNgurfI8FwoTIlCbGoijpup8UVXyCeB2AODX0
MgmWiS+aUFrAz1cjXcBnTkXPIJMy7Fpf6GlPIzlWMkl7ZPixoSxXd/DCwuUJStLTRAcUQqUjSogb
rsRtE7bFI4GqO2NQhVWVVPTCTtTAmZg9wh8mZrMjEWGE+omGILtRDI8jbU9PB2bSLthzjpoUd1TF
TTYg8WkhKzK0YA0kNYeUzDwg6VX0ykg3ORatvIk3HQr12HPbT4Kjkd0KReOo9SLTkOO5RLcE8CVj
GbYhe2x+mv4wgqnxk7RKTNZCIN4CzmG4IBlJ/wDuy46DjNOEVBAeoZ4IxPvCqK6FWN1CoCDrNzI8
fbgQt4CsKLkbSaxrGSVb2GXAvSEjfhwWxwlqStNFrpbHMUkYiBMuxkUhLItyAyU6uIOua+jQ34hB
geTZokpmNo674GlBc3oba8EHuyUoxlWNNjY8xaOTB49hXlsSnY4SEo0LyyWy3qqwoyJ2eZqHmKlg
icjTyK6zm4LbVWyZFkwNEUBorBU/JyO2NK9gKMm7hoaUzIpKumiCnbDwPmDXkI0C9owxtVQsNU+o
53KbCjqTyzQhKmi0NEu92OTvKuBqnl5sv+gynknESb0K+Rj+lo3eHwP0DWX9FuW1WvwZF1BtjOB6
LSMWxo+ip4ETdfCHBuycg7ZiZM4VDL4aCinQUt+i3LIXZ2uh1fUYhZwJ2Wlx0Uous2MyCHuLmlyd
ivP2LnoRWlobI1yId/DWT2XA1RvDwJMo3ES76ie+SW8qJTsm9n1sxrsQq9AuV4HFtitmLxd2+NWd
J/BX8C4+B58LMKGDiCkn5ZQjuMf2KIY/wbEPKmjlLq4EOeSunEMwbGqGheQXZ2yEZwGh/wBEO0/g
8SISl8eBCUkhUTwELayNhYQ4qYxhDnzGSawUjY1bJYpUJRiJIoETL3ORPRVcBTkyg6zJWZM7tyGr
M4YrOtCJm1nRmu2FpLkoQbHNvsZRdIVO7HRPJ8Y15RWCMKIKzLNEuE7SGUYhDVoc5g+1GkbXXBop
/wC6JkS+xbV2Iu5Q8aEZeq0KusJoRPrRD0IXRRLS/bHhwQjgMiTHQhTtNWhY9PTGRVljBXUAgCN+
GVjdnLEwdzoTE1DG1HlkejIs0iOM/s1M2bzKiT+WEVhFMjeHngQ3LFZ0BHjosJMVCN5EFsFpGOuV
YtrDgz3yabOC2kei2umODeD0/KYOGRmnlVaLXGNeDMpNMvA2NvMsD+iEmmN18pgt/gWRvb2OXHbA
+m45kmbFjYHfCTATWR8BDm+RwbROQQzeRPWjsMpP7CRrwf8A2PFK0wVXwlFm0UY/OeAVccAPHliK
JPRDkEXzFZWYENEnBTu58Cwma8PmjoECiVwEXXTi/vEFzk2SWMCJbDFp3htnQaGzhOHGjdnP0Y6a
7CImusGRjsqYouq19ihkdaCosBsjCLCK6KbTykJUPiHZUrwmaMAQw3GOINUCSgpOQ07W7sUfJslK
86x+NjIJaaiLHAhslhnJf05fgji2yrofE7ZSKKhJsY7bWH/O9AZmr2MXEUherpf4Gkh03rwTCuT4
FiVeKRGleCcfkxA3kVuJCH3DcKitRDtYCbjf6Iqb/QstK0CiOaplj2Upc+h4wnlMyRclYck8jZkT
kcPD4f0zfOeiqTGJnTotwqRCLApTNNyCcFEgyJb9kIy2Z9iOQdUGuLgVaFrIiwWBY8sXkGBSwOkC
wFInjoS24Pml2MtwKCNojHRMIzNEzYXIxUl8pUIbO5HP7uD0OawUCG1vFNph/BR9aJqE351skT1A
uuahLu7NnOyoUmFakO8R4tFKLBwPjPDIxow5bFwIVVUcl1bWSyjvSGpIK6+K+QO8jSV0KqV9BpDA
XgRWtn9IMiXAx06nAnKm4iaHs7N5CN15GeOTbdt+R2M4XwCtOBBUgjYWy9DVrso8jGhHYIOvpCoq
0JYQwYbFfqhaW0ZpwiOvGRNOUMW22y6ZrJhG+xxXDY5mmWedEmy5vFLNYGMEcEGaio0vYriRG0i9
Ij/YChlgV1zUZgyxi8YwYporwJTbqY6baCRQ6eZQcFUKFKh+cVwhLEjkrzIWa0zw0xsYo0zviexe
acYhSh3RwWh3FRIqZGCwTiJTaXJthPCo6TyG0egj8iGrHJVcq5MHVWqZulTw6gkriclFvW+TVwaK
HG5WIYLCwcKHkU70xvaJBHLYGujyS5fAlE01qDqFI+Jem45GLCtDAJhiUurumArZVIwtRkJLiUk1
TH4JofUM7o5FXFMa10MwVSDqXKaK9rbofTubEMbqQW4U5ghybagxs2TdNIqr0boaocodcA1qkFUP
rTagpW78iJKBtwJcdNj0++qyOjqto1afIhuQZBULYqiNhcsZhIuw2RH2NwrpiG3l0WTGcZFHjdJh
xFTfsmmGj4DaAqahbbo02MzvahI9c3gXrbNA2si32R5yQB3uoRqbkaULUOapbcCO3McobG7xIMJe
94g83Uqje7wNxhokjgKYHmd0oIq9Tzge3zhLQnWTA6NQBMsk1yeRmU3lXgeIU6ey080b6MsEcIs1
snnknan2HYziMbpN+2Nb9iZShqN+AhtTpi+4dUyzJzNvA4VRp5HQJhik6FRltsR3oS1eD9HzPaHD
FWNn2AhnSsOozIlEynsmOgoZT24/ZZpyprSGp1dbZkhrZyPIsDTZgYLrBmMhtBxhlsfwi29OTgUX
9A9yNrEFEUfBEiyaKytR2DKZnCF2GdiQUY0aHd8SGhUYzCXQ2J9rR/cHdtjQeRMjXTFssNBL4WCD
x8bOCTFeSMiDITOhUCBN9jjl8DvexKnD9GySuqbMizPOvIgqzjqqj3uyZPf2F5CLuHSNZ9seZDzp
fsyaCnQn0Yz4H2E1/ghl57Fel7OyfAvRJcDStU+hIAVTcDJGitiz1eRSgoYr8mXzewqpLWDO6sWj
ytPAnl9saa/uj5/2Nx+RBA/BWLWswxXE3RnRK0LdVpiWLsQVrwqNTwdj0MZnTbZjh+xr3vNG4+Y8
ZhGSVjSGJ0RpQm6SRvmDBmeWJbGEID1hbNtHJyyEdigsmJ+DOU7wNdH2Q3k6qMsPQf1JByOx1MCW
AO60xdUvYn0zfkTBii+VZkT9mZnsV/7B1UB2Yz/qmQeKxV6hBovAn6exIoTLhji7b9lbn0G1Thd3
ZROmLbJ9oYt3kRhDuDLTa1WZr7o/PkS5t2ISSdvsRazOD3sGSjh+CMY8RWuA7rFlLBouDdyJUwVH
RMoYAb1qigt1cidtMPoQ0pe0MDOs6O0Xul2tU4Fs1+BjgrDTNBHkGV9+YXy+AmYEt/TIgm0IIz0M
n+pYjapr0YuvEqWcWq+2H0mxkrcikfRResHApbyJ6oRoc4ruOzozdptgrYd11sz00pMeAlYtR6Nx
N9swI80clyPkb5rG1V5HSmuiQmhlTJy9ukPiq5DEdeGgeI+R+vmO56Y4OqZ5ORZVkwszDCn5ENh5
DlhOCWQeHgtvloW3nZg1WKf7w3yeRp0afAl0wbUO6Ds3OLwP9R5g1a39iTTqi2Z0oyyNPlUjrolN
JdkGoUWHAhhmfgrsUlLs6TkZvKquBqEy3iIlJt19jlJ/ikK8l8Ur+wh3OnNz/pWLS6HlOh7ziAno
E3QuQSyz8GyMw5O2LPAkk3ooni6E/eRJ+cRnYew9N8ODUrE22NUTyYEHSsi6Kms7Haxvx8dGeOit
OSIcqgWdfkUkvURnCKBLnqNaY+MPKGn/AODH5+hoSX6IoRdDKDVF14D+3WOjQ4PT+DZMTgWAzZsc
jT4MnkayIMWnInhp+BbaUGTBNAakQHM8QfSd5XBGt/BwlezGlnoVRG9YENRakUawHafJpExOYjN1
iBovoNiIdfAqfUhn1aOWuSIMehl5ehzAvLbztHMmXIpucFXGxHZNPpo1QOuBOeD7RTiYyj/RLLmU
RUsR5Fw03yQ/cRZBpaQ/tfgWkIPQ0aZYWiRLYlIbOYNcuj7XhT63ZKxEJrJwMIfUKJTc9Gerfgtx
EPuXQ1Ba+jkSIscQntJ2RgFq1TUWJepPLhkXWNKCsprwXWvS5JK299mNGknwQ3+CvumUaG+H6SDc
Ogk2xUKUzgzXZvWC6yhYjOF5Eir/AIN7xCKSyYhngNZg2on4HRs9Dok09mMbehY8RAdoRFd3BpO8
nRs/VKKqi54twWwn8ENUCO7yoh5qD0DOengROJ4HePYa2MJSSo5VQvI009FDl+rEetBJJt+ik8vg
Ss2hgRvY8tblIaN4+Ac0yUPuCx9BHLs4ggiF5a2LFbFoyLqwNuThyjArxITmyvR6C5oa0h+zJLxL
RZWdMUFIpQnCQtnumjXQcobhjiCyz1Dk3eGhqqeskTHmDyHe0N31VaN6lcoWMkkJslrbF+lqoim0
2uUaEfgeIQIS0dvhezYi7FYS/osxZ4JcHMWrkRzDcEPSFjaRO6HV4EJC9iH1YT6GkcH4NDGSWzCk
7g/GscuOMcjg/O5WB8AhkZ1Uh+Wl7jqDBdWlRS7Hp5PtCJ3NgobxGsjV5QkaXehn89pEH174MKoE
Nro+glc4XCF7gx4Geeqhb10mxl+aYcOCxyhMwvwCvQ8i0F/zmT8C33t7EuUTA8ijyJJpM+CbomwT
2P7vF2GdyUIQs9buDmkLLo4ZEYoAy5Gjmlac4ZRwWbSWF5F1pV+RdqIkJCOnIWhE7PgZo62EKijk
uILMqsQYUDlowP00tiNbrhDbaENCxtuApz5eGyGupi+HAl9Dk8BK5nzSV8iKqEJQ6bJVLZnk8lNm
tnZONJEHpY0oaVGh1eDcIJpQnhROCjK0XJjAxRexayIpy8CWZDmEkdVGiGibR7Kvwaok5IQ18GtE
bKkzJmQ2gIqkkNkp8CMfb2KqINAF/wDwF9T6Em0MLCD+79DTSRBilCdI5cEdUl4Iaw4kjYr/AHIM
psOz4DvIHEohqwMNgzOBBSEJdKlRbYyEdMngSbUC4h+ZsFwYcJmWY30L4k9GeiR7eOXhcouuVjy0
GvnXRh5NehgaSaGnblgXURegmyJM1xFXY8ig6C0ht4LSjB9WhA5L0NTVCPRxBtQhqtnXjsxUorhH
H6wGkKUxxhhadEuIQDlGG+MIVt72x4DBLbSEcBGO1sYYONJGKutj73C1uDmrK6sNyhcMw1H12P8A
pI4ITo0CxSgwwPGgqgP9U0KNURzizN1TRmTjg17Ho8NKLXfAiNYORuhUmiXohoEZmIm9hh9pEhDT
XRNEaQpUruTIdHAli3KMjSDgq+qKhlWEL9cC1DDYjKGmc/A6OlG15p8iY4DHrLcFFJqDUhTwK+D8
GLh2XlfoLkFDhUehF2ji6HpFwaFMpRHVW+MIiiMQzMy6JIuOiqrQU/dghU9loacEoSjZyJO+jD+F
vOwmCsWxlTVWiUoKDJuBWrSZQdeEpoVQRr2PSVZMSsWMymDkteBO/NgSrq2UUGpJEVOzHChtf0Ro
UY0MhUngVVIkSqUedCpiBjKRZiuXt5GmiLsiy+xZlZ0GqzsShLnGxmKT2zbCsdmEh3kT4qaOO2SY
k27PeDBNm1no1RKNNYYKAuBXNg2GD5CKL2f4KBSaog+VpOcG07WBHcwxa3Rwqs9ViWq29BYlG6EF
teeMZmqb5FclH4GzjLpbK/BN6OX6HYwZhnVMyFdB/wCRJ2WURGUzwJWbewwgqMg7MLY6qYqS2OhH
th04wIaIo7LIcYY8CSAmU5yVFjl/gsQ3YaeRLSLQ0a7yyHQKUymJnqON0JwDPdbsENTQ12KC8wno
VJ17DifnpvUDQvI1+B+RMUbgmL8NxoeQ2NDlZnkWrOfIirAme2PMltFY/wBmuMdEN3cHOqUjQxm9
ldHQ5coiNxIiuFzaLJL0jvHGzKN2/MULRNKYeTEbkyLI9kz8E/lQT4FKlVb9jaS4OaIFklwalQXO
PClGMFQjvMEO9C+CG6aKF5yNtCpiXAEFql2hOHszb0I1DAOhlgw1RPDBtlSHNqisaIdaCLc4MBRV
cB7HIbZwk4/WKoIMpbjYkchNouB1NYGwDLTkyNUV0ggaohNhUhZ5JL1TLTMRYKDUD/iEa5FtVrEL
cBPOC+bA6EqjWGeZmRXZaiEOocN4wslzMi5S4CNqZVJ2BC6GvlRoHgTZjVjiqrk20IqllJwuml7D
2XpgwOaOiPpC3yPbiMcjpCng6hz5yQPoyV8l/EyVW7GKT6PpiM9bw0Kcy5UlhxhmQxXI4gS0Q1Nv
JpVCSf2Mm0Woxj5V3gf3CE49aI57FrAhi5ZoxM+RKyi3gs1FlrAbsyEkyhYZynGffCG5llCXEEZF
wz7aIpWnwLT2+AlqEzjEYUJD6OM5FFm0eAlBLoIqq4otOW0xenkSYOo+rKFPUT5z9xii0wIrP3dQ
ow5Cr8hfXgY/LRFrtBERA9bRZ+5Ge4F88UUBKvYRo8YEByNMV4jidTghC7TLZ3RXBXeRE1Wi9iPg
QhINbMmQvIJhK/ZtPQqa21gh9tQiFMVVHX8E+9ojJlZGVhqsIzjFk+3+D1jOej2RM3F2Q8apk1sU
4HsiyXwSE6iOqwbN6DcCx5C8Z9mT1yY6zaUZ+ywRiOzxFi4oEYdDC/MSWoYL1FTcH8pW42aWC6Y6
nxcah1BojwLoWUzK5Srggimv/mB+GFbKO8ktgQRcP2L0wEx4eX/4D1j/AEVKlTSpNYGzZRxKxCYv
sbgjY+TExaP4SwG8b2WxZPCHrvA6TZz8PZzWCOLPA6TkbdSciyniDH1RNTWA23EGKc8QSzgaANZU
wbtahzSy6NjvS2bMKx7yJkbNFMORKkJyXwZEmLTiosrrEf2CzXzQ1TuIKuitPUiKKJpcwaRUgbya
0Rz4tEJ1RPcUYLjaFQWRqc0IjwIxY9eIZqZaEO1ke2aMyALZzgevMBNTAXM+HaceC/kTXI02RCJk
eIzwQ2ghbwYXZicmMGfkcM7edZFrfgTESvsXrSx7FqQrxUOUptwZPA4UsiaGsQZoaxDsGkhuEFwq
NWalIJvxTD0OTTinIunsskJg2yNaSs4MrtdC9oPpgQ+8oaWp0zIdOZ9tmEXkpjxxwLrKwMBZ6G5U
TiGeh2W8aK7T0hTV0GZSVHmZVN5I8CMrVFvWVvQ1WT8D6AE0IYx7FyGNWngpLR6R5qEWBDEMdsen
hoVHImdvRvogJqcGMDTu8Rn6CFW0+S4V3sKdI5KI5LK5TwLKYFGRMNaIKJdYGtzQwrYX/gyATZIq
uy7ENdUgTDjyaXIoJTCqCIh7czrwTjpGVWpqVVSLb0hCVlQ3PFCRsM/gUT42tiLQcu1czc4QtThB
1UJ7SZgDAMxywefzRCdgzW+B5Z5gzTtnmFPQyvGnyUhhQyHjgYXrJsVn3hRZuQoxPxDaI8P8GRdG
xCmHHWjL8FUXcZZbYJBr7uiyI8GxOISGN0MaGtocGnGhcyE1kTRzxwxu2VJSDggLWpTOWbDhxjH2
zoVGQbEFG1bsNPNNOihDaSGOwZRoYOeaPUr8BbRSNexv4t/BwTFDtfvs72B3sw5I0cKM99TiXNlN
E4d5NmC7is0Wz1rlboSNrGJZpraNkoS6kz62DsqRywqs69BGQnI2JGXKYRWaqHmblFaroy0IHJUK
8i0rLfRh3NJ2MRosRhXzA6lE3UEbp5fkVjBbrYy2yqEC0229ikVkUl2KIhAXesTYneE0/sSoMY9j
kIPBPRyNAp/9G3kPmKKVDcZyVP0lEVoxD2uPsnyTYzKmxxSJsGZtaFuBtyNTLY5m4EMKjGuZQS14
p9iGmJkT7IVyzLoxBhZDeRaE6smSMHgI2NkTh6aRAhkeIEKnNE0v6MEm90Xh3tzBor+g7K6KP9Bj
fJRjhly9FbaOUeRijKJIXJch0GWtFnOBykmYaDco8CMe7hqIaPBTMaBFSTJblYpteBkioIroSCcS
E91TYlKGV5gXZyYqEO84WIznwFSnybXgRnsFE64EGJ9qWZ00+pkw1jqp4Gk8q0hVhJGybGVF2YXS
R7cMJeG2SvcHg0XWmzQmq5hizBzdMI4usCR1SmyZ3exFggEqyFJXyLu5FLK09/DzMHTFQ6ngI2uT
u46cX0NiovBfalFPwoQhVsXi/RuhkedMCIcryEhdpkNYG7NNjaqU0PTJvYnghVYkc2ZHnRoYnDae
BajCrmo6Ed4z2TEqY7jwLTURok5yCG2gtEUESyQW+FvQ96REf9RDOBhOxiV45F2rCkGhSGZHgskc
VIhh5yIQkDLupgVga5NNB9ivOSV1wD4SooSfBMlf0PhExTe4QcabtpSKexZZiwZSfHexyrBaUfnm
ymfTIhWgbD1qiNlkw10LN7w8DBkpyMmkFMtWIIaMGTHyROUyvOxRiUmwBpxO6ZeJwMlYFivkSrWd
JocNIxGPAzTBCd8Iwwx5Yyo5oyzZiH6qwXLndTFJkMTsz4dVi1S4VIZWg2hrSmjPhJIamr4GAzVy
eYKMwIdG/wCh1U0omKgLoEMlZPJTG5DjUaa9BLZh4a6EdiG/ksFwV8joKo/k2ibE3U7pvxaoMG3I
8jYerrUy0mmvoawba7yT0J0NjZF8PZ5QxMcrMvkNXSCnGyUZQTXQ0LDyDeT56G7CbdOiGWdEqME8
4Y5C/szJU9UR8hcORkI49TxHOSQm68qKVk3UbKSm+yQ8IkmvI2+5mkOTz9sa1nnFSTSzrGxYdVS6
LUw1kWzqys07MAGUs8DLCQuDyL4qUBpX22sdVJlDWh0sReNmJRLA3wHtfF+Hr0chzPilP+jQ6jgb
o9WxMkVSgnehosVIHpnDyborZIeCQl7Ntx+GqzOCbXgyDJ4KqSy7Gqm9eR0sxjVNjKw4Dq72WGCm
aPISPXxRuj+CLwLKGJ2T6C4YkhOc7IPbPBhq9GZr0+4LXhpMvGZ4IdHoTvmJvnsVi1FkUIZS5FEt
7HkHlCs1UumVuK8HLC7FlbPQlONy6KbfjYjIaoyp2PkWLgMVGpbTcNVF5ZuJsSOBQ9xImH4QtiCm
9kdMs8eSUsVGHQ3NsW2M3yXGNELy9kAqF0LepGxaIVVIX3A2W0MT1YpVQzwm2SDJwiZQ0+qNa9Rj
03SGtjyVNdOitV+Ee4trycjbNDcfwGSJX4umN3WB/dpb7MM2XIEWYN8tUOwh/OCJ0QRbx0XW3oUE
/wCBMdDn42ExX2QsyoQXmhChLTSGlExiFNvwMC392h1TE70ZD5voSoOOEOVpRxB+XX0hwGvlCyMw
hh36EJnL3sa/Nc4HxEJ4sJLxz5FiTxyjaFW1wJZUPkSn690/nKLhLr2YtYujAA5rZzCM5nQetn0G
J2vifAWg1eRRLMP48DHsIMDZ7F1uE59NhD0hjgpVmixRBrX9Bk7BN1hpr9yjDeXDEZwYnaR95Lex
wZ9xhqOkOqKFmjN4AlFdiuZp+BmVOxurtgU0Nnul2MCqJ0VF6JOL2jkWyJZHkJGPKNiE1BxeA0xw
/ZDP4hin8GOFM+aa7ZZSdFG8vd7Lnf6N/wDZBRHHyFBO/ZR458YFL0DKVJ0b2SOfgYzUMw8kPqK6
Y3QsI8NjtAjTvyyia+oYnyjBidj9axtrujJyq3ocJU8iy72LQzxQ8sUW5Uu2E7ezdR0pXL8BrZys
k0pHxwVk4MjTyQ3yITCRnMCdFZFWYttuxHE9DOywl/CYjm9DwwvKF9aSh/H7qS9CyjnsNvuYHgvI
hyn+A5bP6M2q8BIynCGV6OSES4RUJXhlqFVUzEiYoeZcpwksI7RPqeCpT+8DHMQytFxIEjwJmlFn
gSe0cC0NX4LgZNg1U0Y5EViO/YhbFMvkKcjYGQ3YdiyOcGvyWh71gNzr3TevwQ5JX5KdU0twzVvs
Y4z6Hu2ZC/4jtiHaPHwzBTXzgbH8H4Hfp8EWJvwE88/QxHokJaXTkJo6R0Uog2jkgzYitHRq01Co
nIW1x00Rt2GEwziV/C1lB3CV55IUF5he/wAhOSH1BMl4G3PIgZG9Dk6bWyQ/waC0pno/5hHlzQpM
sY5t/s04SFRMloqJqs8IURLwQYy9Drmlc6Mq7bKH+Q8NMcFCPgo/cTp7FbLkas+SE1BhqjWi2Ykj
OCJ8NEA1HFSr5HLN4C/zEbwrL6EtrZtjjNeYNbDZMVzy4EsVfQ9tMIDgdieDPosOZs6XKKAu0Hho
cIQRHt4FX2RDuKvoaFg4FL6bEuEmhieIPYXpiXJo32MpS+hNFc9C6PkQ9pL+ClYNjiFaqC+iFRvR
lifcI1Kw56DhGLLbQlIv0VkkGwoI2huQT3GuEMsY8+hDcN00Q7XaGEEmbWaJ/sjXnkjEcEhrOhIQ
f2FG1Ni8oiyXhDyYlM8r46hXhyX2b8od2kUIvsREr8Eo/wCTLlWNB0zD8AneL6Q4uyRi2410OCwb
pDxiiJllcozNQHYwzokojo1Y2PZEPXNNMumMi2mqosy/c8Fy0hzyIa3tHPH/AKYpn2VtJY55bbPB
i7iIPALVQti7NG0IbF1sh075WSASYx7qSFpIkMgS1EuBBQ7CRQeFkI6ctLkxIcs0ismssTSmqsbl
t0Qnc2IbHksbGHIjqy5FdxJRQu+VwYTuSa7JCQspoXcYri/hNcWT0IapJuQmnBilomZetsyA8xB1
H5IaV5BFd1yTKbbywvHXbyZvK5Wx71qZeisZbg5Wxk17iwblwKfthxHqMiJOukn0QkzyIwuXMCXF
VotCqcqtciPPn4FzeC6opG5TPKJqymDgqkKuW2kchp1JIW8WZDOYOC5E1J1RQdWp0tkBtjsE4kKm
4ekMMiTNcclbaxCipeR0bxXQvkackkZFEZgpFrG2IeyI+HpjgaFfgtLkuSiQO1OjZHUiwW0/A1ce
BjLXBZlItQyQKxsGss4SvTAzRKC8BnIk4WGIeSqSVHHrdw0sENArJUEGQH8IOZmBDYb+OfgSZyUW
iV+S3rOzGYDiwlUw8QlXBIURQ65sCU5paFTaIehjo+Qykg1vD+LkSKzKEoaISQh51jS1LKMAqdFe
Cfsa5IEQdsY0RcqMtCiIXYjYrRcCS5OCcYHGdXw8DFXgb1DbEQSgQx5CNVWW1LDEFN4XkVhNjI4t
CjorbyW6iFGvzBrENs+i4xFm0/Ax4kI09BOmEWnp6EVdfJ4J4HV2QWAlR5hpUMJxQoOy8jM1VMdK
uYQjl4HBpLRGCn0KiEMcQlaF4F1cJGBCA1abpxaNe3OB+owOEW7sHKj6IBk9k3g87E1uIU/UJeLW
9C7Sl6GkdEfSMoowT0tdjfjwR4KxGCokqZuIFjWvAUpwDrQ0MEUnkxhm9odk/oKcVCYiykPmIoM6
UrCLXipHpGZQ0TGZ9EUm2cpr3TKCaybgBeVUJkzAmjaorTXIyYyLxs2F0RY6GicD5kgV28OyajaM
fmmxpkRPoSUcyMG55Fno30QFRhuYKMGLgsHcbQuGJXxF45I5TRhTIZsBKMCTaLlPBI6+gdcZCZUz
4jrpkF51b6GkZZehWZMFMGapCUOBmec0byMJYliMapm0geJRIyolURNhku/h5IC2MmcO8GvQrFr2
iyaUCOoCGNvkeBOyyfwwpKNyiZb2MV7CWBqw+Q923YJWCnhexYTsQgc61XAi+gT1kT9gx9eSiunn
A+h+KJdIRCHZJoKrKUi3YPPTKKZfkqrhotFs8SsuXZFznFNC1b0ljsa9VUDpMve2IIKByFVaRpIs
Uc0OAVstNSmFoja88GEb8EMW03Y/kkKpcZSQlTBmSuxXkSqUngNNOO0x7tJtM1RdP43yXo75Qhyf
uZaLUtDMDtvgenEDissLPum2uzvT/geXgHWhOrrrovPgHuuOZqE8IQS2pwYcbaQxREFBw2kWXobi
zeDPpVKLYz7d0bQRAvwY18ZND489FxGjw8CG5N0aEuBhPLWJgLxB2QVPI/8AbyaEySGKRQnzTwuF
q2A6WlQkwNzgXJuHaQlHW8MU0MTPnBmSlk4+eR/C+GqxbC3GWhEcQl7YY1W1dEsRsmLpzBF0xtUW
DzUN/UeQ8jyWEE7kvzbv8MTnBFRJlI7RuRcBe18xbbCQuyPODPUkLlfoV0YvBKkoaUmt7LErYWx7
ekiKwzfEKm6KdW4NxrokGzNrJKekIYS8RfRlhww9jE0/Rl6MjZfAeEpsu5Jg7YNjkIU83gvERhTe
RNJJ538Eh4DEHjwsDF8mgGqYdSfQ7oTZ+D8otILTJdDWPI2WVwUojS3dF2mZT8G1yOlPk48Vi6LJ
8i0aEsEN8AtAhkE5nyfmi2YDQxFZRYtonjnTMo0Frefgz4TOGZudjFNITQoRp9GR7gxpzKOlulNE
ii+CHEecjKhHu0cMt+xpbYHdag2dT2ENmYqO2EhbI0AwwJgDDS2/RdmEJMYEW8MQ4cioBUzKUFJP
KbHki66ph4LaDE45nR7EUkLQhSzaFs+UImwU/vPwvT402YR5i/eNhZYOQie0dLgwIl8A1klyIvoP
eEN0MXboI8SWiN5YhV1P+H5A86qgdNoOvuOEyZphxioVfwerou0rLIH0dxKCuGeCDaz/AIRh+ER0
vI/L3RpO0ZhbGxR5Y6jBCZIiTS0PGroLWKUDmyNVoLny1w50UmKP7iWpEgnRYql8HBMnw1EhV6GR
OgKvw4Qkro6D8vzSH/TmStDDKd9DkR5NLQ5+NDHdDfHQ1LolLg2ZHnMFwzpvx/TFWnMrkhi7ynlw
gsmjbRjzS/wUoTy07obgc3o1pkMWE5bkeqNo62hvJdXMoeQGRkMLJWWZmxXNA6knUhlq7bkiKJCw
A1InwfQlKHYlpeLVowT/AKQzMJcNDGuLS4YqFktXyxxaMsMfuKMkJUa2cjyxcKT0ZkHXm5MMEPWD
quhO6cYwjyCYHQ1jrkbEjOZFBkqQprStGA00OJcqC+M1rBmKjwEp+QeRvjMtxy+hSUTmjaPI3u5M
d/ExwyNDxsTQsjUYhigxa7yptQb/AOfE3WrP4MJmMDX0JJdmbxZBrS4UMIGJXlOjR5HXodWT/wCM
bXwcbQqPZtIyxCMR3Hr3oRtCQu9bzplmJeiVQ7yMrpKZq5MidGdzsGhbRJLA9BlMdqBn0jqqf/03
CiSeRvKMeZ8o4M8/gWhIdGb6IYlQk7EUQ1iNwO50SlpDwmOmtCzqHSg4asdWfAMJ1wMACu2+WTNF
zazUsCspzIxsWnhB7UQ90GlpyUF8DJQtO18NcbQycU2TJGKc4YLTcGRBpobp6T2KaHVzBDG4aCbD
BBztqVQbTfgpkbjxS4z1KTBHksI279UbNUd35SJCQyWh6ytsmAmXI2Dv2MCmB7UtXicH4SgySPcW
YZ45OzvdkMwTm9lAtzy8MS3kGJMGJC2R7lDd3YpLIgrvAS9sMyimYcYJTkRtpgddBfVHnPGYuNQK
NJQ8t3osySIIhrI67NukUG4KNF5Q1a7YNxsgl9CCnVXseQC9HQmmIGeDe9DSjeR8EWsogrhoMjNP
iuieMj/CbCdBmxZmnIuVoGYbRRkfJhV6IZsJ8sWfV2SJ1UGwuY4QwEq0homX6a2EtFkaYtma0IJy
eBm5Ssi4+j6MQRGw9Dk7F+RGY+QQfEeMoV7I5x6+h+wrQlunUu/IJnuxMjNbCdK08HDcTExDsYY1
MhUi5F4+ktj2sRPLFtp+QuKiZshmNPaHpqwkLCkU8MetabIR8KhtWV1gq31RyxDEUhPhwyFyaq5Q
nRU0oZlEqCfzFVYHO08aKOxttG8NssMUsfAYyjTIl/iGSZfHIqmsh2y0yli66x1Dz+ZnG0PmEfVc
HBognEalo/bJlKFT4Fg1b2cg1JFi6kR7Ry7E4kfI9GOnAdHa+OSmDF2zeTJkQw6I5G64g0ODu7Jw
WtEpksvRGjgJnlFJKCQzLuUFptELL6hFd6HReRjpWSSfAhpoMYNCGV1PforzOhtS3qFUyeQZ0WWN
XobpySkwYHY3+KnuE8fxwLZyLVNsWl4b7vwOXRkrWvwz/DhPAp5zJHTQUs4I2lwxFWuZElhVCMeh
NVVfk6ViXEgz0kkzhDFIZuTi6EiYYigpkmQhGGzI80kVFEXrmNi0aMweNa4xBURyWqQfITXZHKm/
YlyHsTDiDgKqpiMeBREokamZyM8j6AyEqamJD1GmPKbKUhv6pYPQtRh1y3k0w4Ry8hTWSKBheyB5
HGokXTmY4PAh64RMXBmlNmVwhIJr/QEku+R7WAjIib3TMiY8YQdstll4RsrqhjoaMDrFqNP0RUCJ
yZmeBeE0LSlVfZvAYCMC7kFNNkNGNiRGsmMy1IBLgUncIUdQ8CZaTIptfApaxf4zi5OBGqbgRT06
YvtGLybyhdYimRjKs3o0OccCKUUg4S0fAcjLo0yIDsxqM42iaymhw9rGWLFSl2Zf/gYm8vsjTqCR
JYzBrK/shQdNK0y/hzEY7cdQ5OmdMzGnitgsCtlal0Me04bHNqOcMeCqTInGWmroUkp5MzFrgjKm
r0Q9BWtl+jSpiNp8F32G1noiTTXYq8zC8F+jFBgMsRC3FVMexNt/yPbZix7GGr2L3Q+iGglOMt8i
FUO9piMw5TOxhNqPwShNKC8sqyuhreYX5Exl0RaOvYvQ1nOkWESMVozPGRbkNumNRt5dwwSf3B8Z
M8fDwuiBWnTRWm4nq7JzSWCCYanciKxTUphWrM5uSYqj0GXQhtSBJG7oSw5ZZ067H+7XtkVcR0Ps
L241lOsQqrUmEIYJ28iQpuimVTyhfVLWtHu1HkchQFY0WH5GOhCVhmR9V/QTJmyxuEwsob4b9De9
Hy4F4ks0jD3g3ghM1UQFHd9j3E9NGkJiDV/kSFcAsJeKG+ZapjlUZQjtPY8t3V0b2QK2znhOFpi5
PZlDzMVWbSS2IoS3YdM3HsyW3Y2ysdeqMY4lcDj4efjb+NBviZM49mbDO7RuW2OUfCD8k+D5N3VQ
6o4iosKVLgTftXY/ur4yPw0hMwZDt2vscaryZ0uZGPL5H9vIqRLujK7tnI+CNU2NZNeS32IcG6xY
YzJLNp0z6To2l5DH3kXpLguFTVTL6l2OZnJPV8pjKvaDWM8oWJI09mzs7rHbELKnhGYKDZPTY1lt
3SQm/wBjHJJJZj+wvjuDKVQ9WqJSbtE7PtGVN75Y3x/GJfpE8pdmb0P2KFDc8mdi7UuuRDToEG6R
I/QWW68iIv2FLRQ0212hQlOBjzM9b0FjP7bFpwinULJXTyR1jgrmo/I3rpbbFhW12N11/RpDQ7Zy
WChd8DoEk+AQG4FCWlyuRqT2K6Mn2JxTXR7/AKD2G2uEUr2DTmmUP5FVhpcsoDV6zTIDggqyINmX
nsi0Yvn6DOl3yJeA47LueaGbd+wx1kxGfYhUaXUM+VklDfXI+s1yZlZQda6ORJWzyNSybgX2uqfp
kOx+mKkpyNQD+hml2M2ViCHoMVmXIrrPbH+TeEO1A7EQnoZkI5YKcrBcJ+GM0ewzYg4Y1gkWw5N4
iNvwGVUDS+Xgd2kJvohXW/oeCmeTTT8BW+iZazvkbSegvc7MQ7ReWRPIuvQsrzOW2OcNplES4N3N
KPhdt+RilhwJ7f2hIrQ/RMUG33ZXa49jYbYMt4/B9b9PgDkQ+xhg19j5EODeYMx/eOyTiRgCf0Ls
vJjMGnMSEtJpk9Ye38aOFEvYroYC14GBWJyWmORHYz4Ltxulsc3E9iVTTEg1S5PBlI/YhXOBAUb9
CHT9FDuxERBTPQupS9DPkay+QyCjW6L6TfKReO3pFstywWM/0JedcBiV+Ippb6FBtqG7Ikq0xsH2
TkD3Q7Gi7GMF4Ojgnn10YpH6KinypLRCZBPZKZpNSi6EaMNNGyAfOoVG/wCsTSFFDc+BoAfZ28/h
t2xsKpVQri5x2ZGZS5DJtvEIE1dNIQ5hprlCFC5YxBGWZwJmFfhyRnhZxNrY3qbbmIy7CQs6iKZV
gYrI2rSRsRIp2aHseBn0Jdm1sh0UHWR6Vqg/aj3kWUVsahP0IySmmRLjNUxVkm+ji0cLRn2P+lwc
LF9CUhiItr6hcBPYpiauh0Ty8DOAz6GOCvQ5q6+LFl5GzDRj4fw+/hbommYJW4WEr+hmMLsj/IUt
bWR7eCDp1KxA3P6OGjgZRLQ2AFfGMWIt6wNhVJCS/hmUi7C1oqxeRIkWipB4xg0mhsclc7EpVbQ1
7V4L2hD0dS4qE8eXYiiocSezJIHwJotvY5GFI0l0tpSKFIa4h+BzQRcY5sNI44LxKEJ1hCR+8IJC
XgRnkbENm50U2vwOaumXxQXgDmYW1NGwvJrcEyDnRSZM4CqxllfDkVAVjKglofkXYi+jf2xXzebB
thSURbM9yuDAU/ClrP0TL14FgkXRdFzJ71wOzL6JODs4EbDPNYsZYlsW+ClMbQvn8mIT9CuSLJPv
yE5v5I1kqJV7qDx/wRNf6Mh1ZsIl4Hni3zDD1MVGGOj/AJkPHpAwnmYnL0MBjGZ36C7KeUZJkS7A
zEfoLYd+SBgX0ClQ5BBKBLbrExNepW6PwJiKabY2Ocrqp0XNA6rcXap/hmJzZXwfoSeB4G+QGhWV
9Dax6M2OD2Idps5JIr8k9bJOdk2dnOjT8eUlsyHhtishTqTTQhvAcdQzAzTEARxcB5Vm4TJb5F9c
Uhvz5glQd8B3YNkamPwFqqW2polkxaIYZUsH395oi+yMgVs46EbS4l0Wno2Tj4Ynke9pG4iOuDYX
0V+iMVG4wI7bbjeBH28DEQ0tMr+Jg4UibFsVPYgih5QTA2YThNRFoY1GzJf6Oa5Z2wBClCqmdttH
QjlU+SQhJ3LJcGAIcIQT70kbxSySLPzDOisPq4OyS4G04MpdDepKqhC8IFMbcNdoSkqsAcCuFm8G
BJ2nLbM7WS4EpxTWy4tfBLQ2tSNjFlr0EcKUOwhGHKobUphZtl5jb9DwZrh2UJ4zoWIpVLAgJwPo
lkiTCfLHtlk+guglfmY2w4GjmDsMfpKQJm3TL/fh1+kwV8eY8lAuE1VvDMR2hMS4YSUWm4uRspYe
hh8SR/g2NaHBKzIJRjyyi9ki8ja2smgxuM3G8oyUmVQcooksGP2Q0xXrwTGq6qiKMKCE6NmKIbLE
uxPTqmYJWhtV9wS6pXsr7hClgyhOFmEGOSwUhSNs4IcdkIJNkxseBKhSgHacL7SwOLuY5HNqCRh7
WPhIUDoyJVGrKSXBgtocXf8ATwDly2iVYEY9FyZojJXPsRXEu0PLi0PWRonf1B1Yy/Q96SPgX/Oy
cmiRWwGJYlofAPYvHmBnVfwXw0WlBm5O4dTwETHNVgZk2r0LMQ8oRCZghRrZUkJaXQliYJLyhEU9
cmoiGJITXphvcNjWLA1uByohiwUmvok6RZiIpSlaLgWr5QruMiMeCL0ZMqWYMDjLF0hOAmiM1a4L
B+C60lkXXCeBOIsuFttBJtStGfalKvIJfjQ9C/RGeXwteJsJW4Uzh2SQq7VwL3DE2SMv2cC8F40G
XaFrczAySONo/sswsolIeL6EbRiT/wADHgTQ2aLGSgZIaFJ2gfXCgvoskZfg3kpCo9AydJgS9RCm
zWoYcVWAz6W8GBOBNCvYj4EyJKjdmJWxBdQQ1l2Zd0u9EQscl+KcjOiDa0FNO6bUNghVsuKn0HvH
Q7OUmTFixSwMm5jWB6jSjpgpCt+JBiw6SeB6PgF2y0chy2GWTlErZ0ZtYF0rOD3wUhI3kmubCGck
jepGDCMpaJvpEn1vLI8VF8s20sIeatycjDZFRc+DPpXsPgsjYIbCFhjTYTJBmVCy8CIWS/eZ0BU1
+Qn0LWLgppJkmES6BXIllFyE3z6IIyECjZeBzjx2Z/JL/pjZbkYE91ojfoNeLCY9Wu4MiLIq0DUn
I3Y6G0e2+SvGmjaMhC92exxssCrqTX+Ftez4CUl5U/4IpNti2gKOJT0SnYMtrLSyJ5SSVcF4Gdwn
hWNG91PoXFxP+HWHrKXsQjplHswetogvFSmPRK8p2k1keAnZFfYOgWVO3k6obTayaY1pXkZLuYix
WuxVqR21oI2xQnlaeufB5ohk0NZGw0NZNEGg3LSMbKLaOJkpj5LnwPHvoXPtJmLWc1jvaRCXpkZE
0h8lM6ZAXAdprZ0PfCUvyOy2ICSW1mRHI4DV/Jsbj+DweJkKClvgWBIS+cTeTCwiUQszoQf9B+3J
llJ+CihzSnNIVg9Mrq0Gq7gIcZt4CzjL+BCflVkwcpVk3ayRXa5GRt8n+bHLtZ8GYg464DlUk7CF
EQmwVfGTZoYzwKreDNsGVEq/Jiu0bdRkTSQhq1D8cwrMTNEahGdbeCC3yiRa1VQhIU6JKFveO6Yx
grW5R8DY/hw7ZcDDk63wJjg4PBSg6gYLRCJCHqFwXLLHoqEG9EWz2JAv8CG1ciM5QERd0xCMjkha
OAg0fQu05Ii8fGLadUlKIxER2xGPgSpFXQp6VWiIJWlR+REhiudCsOzhCPAirKiEOlyjG4iYS2a2
Tb0bPR3sgiSeBi2NhGrXI51pweGMSySwZQjk6pl6BfsiYhV9ZlJmkfULh9l8uiiFw3CQi72KrS6J
TXs/Sk1un4yZfaxOr5EMfNITI8rQ0hqEvIZI0/d5C0vqSCsM0X3KOieWkJnrORaS9tnvqjea7GE9
ERl9stiFNaFNqZUGxLdik3WR7KsIRtMka9lXkXSwmq7M7aWeBTY8FR2VwWLyLKJZFvRquB8BModJ
qxA6c3wIq2mAyS8FkMcYc+zCEJqFTdI5bWRdNoe+xOJLGB0x0D2xhMsXjE+9BYYzjgPxGsbycD0z
LDcGEUiiAq0E5Hj/AIcfAdGo8wv4KVqMNiO+Tg0P2yR1U5DYzpjXj4ZCzbcBrwyqkPosqiQbw/5G
otth41/joaq5lj3VsNklOKkIjFIbL7KvQzQzKXAtnSE8kN5l1pwQyFLz4gkUlOkslaCk8eH2M7Zq
Enoyh28iPQobOtFtLfg2Sj2bL4EbwG5l5HljRZJm7/hZufCgVUqK2FGdFeuhKCPQQKH3Y2rZxiya
CKrX2TnJI2LkbLFtnR7vCC3XGcdmEJ24IC6Q9DYyz8GI2TJgQyD2OUt+jeGybxTauC0tvIopHCGZ
wwIYzAZuuUGpMp3I+bCwNQhhrHmj08jGM4zCXGWARtgXOtHROxR+LoVzLyMaZmJcI1HG4QY3A09w
yxijoifgkqXwr9scoZJI5aqNYS9mLeh4HYyMtCrwoMZiJeh1FCOC0GORPA3BalVZEPxH1r2TzyQ0
2XoSjoz3mbNX4DaxTWzay8aZlgUIdEmykKy9C2fJ7IUcS2otseYNPcZmGYJa6MmxrSCQ7Ei+By5V
wXf8EoIcgstmMylwmAhDduILCB3IcGX0EDJ4gHtAjcIZvILRaGJdB4KCErYnrmLeqOFDEXQgKCO1
ql0ooK+nuVTYdiEW9hs/dTvCBdrglsZCS7qo2JKnIhjgIjaIKLY0KiN3sTdtIptsNCLTyYpMHPyL
oy3n8PhKeVgnhgNjwowtLl8opiYUMwLXOzIVE18tjxKqBTVFgSdCyOK54oU1yWRCO1E2acHI3SSE
h4BcewYBZWnGJConwcubs4IgPCHLLsRjUrqYronVyZc+PJp5rAZJ1douPGlF7Gsg0xhDWRCt5EMg
yjIS6ayU1MYAsC0cTJXhJjQ6WexW3wbezMwmjb6GWiA2rocsjz4thWETlpiFDLIJAUPA4UShTsUV
iq0OudnDUQ6EIomYSCSqrL7ELcWE8ZZ9iljN5hF6RqQoC88RTPLUpavFYG46Wa0MI7yQmHLN7NeZ
FBD0/TZdI0f/AET1RsxSvpyMLwZLvCbNcDElyIMYOc4mY2KHmheM6j6lYZJnyyZs9snajQZAAncD
rKNwYWmyInEwu7JsyoBH/wC8nJpAIHLjoiSzd8jBNayScZIWtsYbUeQbMngDU9KGyfz5DqljbGk3
kqiZUd8JE7D5IzKYxwjDz8ZMd+hbhqG80NjL7isicoQJOyNThJIunr2U4j3Q8va7HZtC5GOxURl4
TFXGl5Y121BiRqDwM1pHKfJVYaGJYSXlEGVvsa9mJvxQ2TKJzyZ5NFGiCN6KpxkTb/oHZVk5iMdw
MZEjCwaFVHE160reBCNQRkdshMhIfUxjsg4Zd/BJeEnMkdIvJvIiqaQsjDX/AKQgpCgFroLq5Chx
rZoMYNIMUGK0kvYpK5SZJijvTNCREJaZMovGggyPsN0QsOpoR0+hVrGHFFssEw012MtVJwPmKT7Y
ymGxbzMDVcJ2cHyXKo0f02L4GW6MlEBkaEqmaxkX6GP6hDzivGfjCxYeh7prA6y2dj0wRnMLLnCD
2KR5IyT2aRsa0r9MYm3fogstEc/A23pMhXO+x8RYWYB5IE2g5R44dFOCkYXyIbaa7FF6QgjZ6/6I
i0GICGgcexSPPNj9+g6/VGYfJiP9Sjv/AEiy7Tll4JeR2Lw1RBbiEbFdsdm9i7OSsIKr42PxT2wl
ZlOjDekuxjufilb3hMimwsNC0YkmtC0+lyyzC6ZiWQkUGMsrUTKpl9TxgdL5GVzmifppgV+ZbdGp
Au+RzT7mispN6HOW83g9eC7g9F5CPycmhMqxjxRjgUcysZE/BJCz5vEZskj5E2qXUpsFaEMcUWmD
3WOFOJDfYgediFEybfZk+3VwNkL48BmZvySl7wGJJBcPkq6acNm3I+RnsnTEn7xjBgcospyVni7G
By2jDvg2IanWpEV3+w7UyadhOJtav8MzLeqIrJZJ5oNIJEsCRKSjro0LIzBdSR7wDoyv2hTJPPxi
yQmqgI9CajLI22beKwYHyO70PLb2PLnBL6Epn9Ox63GLSyMizgtrpKSHp+MGZk6bhm4NJPkWQnls
XnmXQwNJ4lehu5RZSHXJAqhRK6Eif0xqaa2iIguEsEIsYWS2MlB9CBqJkJU6xN9yxpiJG3kuLz1j
7w/wb1jhXRBn8iWE75Pcuw/W8VsemMd6MgvQflSXllG3ewlNq0Enh9tjFrI6E5jy2JYrXsKV/LLh
m7P9DzDcFc2PZsT8KTNMm8BMmY3f/mSr8m65g7a2PDNtDusldp8i7gE+T2Nun1Bs/TQZIHRzH0CP
N4C63b68DzKiNdjsJ0N1fSHEy8mWkj2H/IbDQ2YIo0V/QtjT4So8bHn8WJ3ROekb1+ZNWfTMPQYX
/Mr5ryjK2Gi8bJYmTbyS0zZ9YWDmhjClb3okc8mwO+xK2NwfkfjgNQ2cm+WehJk2/Jh8hWbAd7ma
hibefFmdahvb8D1PQPDti9udjw22RZkuSvAi1l5a+ILh4Y3UoyAkvFH79Bxpg/A3O/QCCfobKBz+
QG5J9ivb/RMdFgacPpbHrNDGL7PhOMfswDqJrRjQno5SG4fFI94Nsz3ZTCjxWQzObJ9/EQ6t/BW3
mDDDRG+CJKxOjG+RMv6AmaZ4WMEX2Owby2fQcVhNbo6MSD0UjGZrIlMmrkCqs3TEtLkUUnPndDDP
9FpakcM9x5GfmxDjDgS6+5Ew7mPfSElee0HV+aMD/g5y+74jCeovMMrKfkQkIvCDDLN2SEja7MJX
Wjd4QhC25gafqYMuCFbTsa8F6GUasQaJ9oX6X4EkolliNO/UQNsfDIwmho8DB79CGM8DKFaZr6jL
hpzCcfwT60GXLqgs2kjF9onkcqeDHFuRaTL6CvTftGFLixfVqMWyfjBKLGWoLW1M+r6HSquHwMCl
O0hrq7ibtI54sxN8iLUKUymHjZNkzLb4Q5MDsVriG8CjQvtB+BNZvJoZNxvtNCKaJOeBplmZItqb
QTkajFZpbVjfWXj4WxV6FCh9Fu6V1sdUQNPyhSCGRmkiqR/tE0Lua1BKneiiv1V8kQ5BQhZXQ+c7
W8F2rnCMCqXoXDJwJ3nwM8psYISr5N3qlK+BVqv4TCV9DNkjT0oOStH7CtEpEOwi7ck50GDKJrig
TqC8tPGCcUm2NK3onZ25wu/WYlYRriLbIgnZIIPK2bBY/orKTXERVm1pS2WWSdihe/oie+DVaZN/
KVodjbL2goCtQTL0FvrXh9i3XXexO3QYfApPi6UfwJDdcGxrFo2miGe0LEmX7mwhciFoLTYRk96H
oNoqcGDsTQ0krayZe60VYt7opCIZyDQmB6W7FPX0+jD7mxW0cJJDhSzRaUanwdDGiEJjLDNOYSfB
LBgIFXIhZ2TN46ciZwX0ItZjET5yh7K+ofwAGcGuhSRWdD1DRZjKH8WhZx8U2OsM5NUlgVgGRz3C
rSp60XCEmxZg6ehpSo5lCpRexV4l+DzJn3BrsQxAEJ8hpVmIN/kYuuBN9jEeg8jGL+DL/wAhOp30
IaAc2svRoIbCQZkb/gaUtwnN5vBw8PoxeUL1TRii14P/ABQbts/SYAetx7Ax6NeBmJTW5YElAxgY
1jqO+RloVbXKFVpo5+Ij1zmGRCPQ0mCLmxxT+BlwFXgZWv2IrCkMVC9C4HngfFlhyE5MjbFNDWwo
o0L18nTPJ7DUh4ogHleiTHuGHoxZtJVqbEpNBASQzRTBPYyIZIckjQU7cwUKdDA0VExh6JYquRkt
JXdMXrA7ZFcCbwniiFZCeOHQgwpwPDVgJXGx+BaSIQ4Fl8F2hUp4ApunTheuQawDjShnYbu6F9Kn
k0cVEzfQSUkp0OATGQvlRPCVY2GxfGTibvoNiXVMseyWcfQpK5qYaqOULhEpR0+gn4vZCqVPRaO9
hDXITqKsFDHLIh9Gh3QmpMStFVaFZQig4M6sTIprTDlCvdVCVkJRhXY9FOuB9tZCxoRGExRUtpQs
TOBqISgjiBUhNSSVFk41JTaGyXI1kX0K6eStbRM4zQEAJwsiiQ+MWoVGbyJWjgHlehrknRpDDlLy
L2iaLQ/zhpLRKibF2KqFpwa6IkMEksp7QWGRlbrZTbQG12JoQkpVTA0a4OUr3o/JemuV2ZYTxlD3
m3Kt4Sm39Ck1V7DKw096M2GuWDuyrnQhgk4knbdaJehC0J/ZPE+9LENOzRg4iOg84ErlCFK0uRaZ
vgDPgO2gWcNCUnTfZ2J4i4GkTbjBRo31hSFmg4tUaCo0UqOHWX/RWWr69C4SV3H/AAakzTz3kRFZ
8LRJlUkgYLfe8ibPMH0enCHApHW/2FkZgZ/AiSwL38Jki9jLCn0Q6DYmbstxEezYxK9RJi0MZ9yj
m0aZ8iUWkPkUSHOvYM/PDPOCv8vjs4tXoT7DtZNuEbixgMdrngvKKSNYtk8xiYHhj3ktFBs/Fx8H
g0dJE3UagaZhPkX6itSDbJYEQLgt8zHXwGc7XAoN6C8a4MY7E8mDFFEhKWx7MwVFCBkNK0QW0duI
6IKS18uIEHg2SKh3RQe7i0Zhq1D/ALGVotD3WcERwJL7ACC2jRh2LCLsVwVcH22RHzzCjyOEDCVR
30HFpCkuGzHmYVWkjmQmIyyryLX/AAgOIVFyGrTyFuySLVCkrS9fDzaKPQg3qFj3kLreVDuGgkP/
AExNCvnBn4gphoaisUtPZ2X1Vomvf0Zih9CY13gskpdQVpjHNiuGKjK0iCrngdBt6KLwYQykMqr7
FsVRlaV5WBvn3DERuhb0kNzBPTzjIxrTCj8ZfAXW8pDh1djNWUOlayIp7saCsKWhhp9jZtVyT8GN
DoNx4ZffDIjHE6MjjI2AyoFd4sWQNnCCMCDl1CdFY2MUVPH5HrcENN+RX1dhfPj1GFtG6TgLZZ5t
MWZ3FebK2TPMipkOIpN0he44KQuT8DvChZNMJFmRUCGlUkAsbHlKls7XXcnVcC5nA1KjBoJp7RE4
5MoWcqqMmkn/AKl3IeC5ZzHDBSiE4d7wkU+zZ/5FAo9ihtlFlG4mq8GznNm0o8neQOmuyhFzNs4y
ymlTVu6JnPwW7wmlEMI9E0zLZyyMGN5+QRQnsEKbVQ9YLhvjkHS1KsuRKUac2G+53wxJj/IPNbzw
OxksmryNnEjIb7Io7AQtxsShIUJEM4Stsm2SeTyFT+mQElEEaB0fJBP/AE8ZA6Ei3UxNDOQjjsgS
1/4Fym2gzsL12NeqwXmULPmIxaUtlpZ+DCd7kG0aQzEhmOuf8zFIdXwFLKSrZvmKRfAE2oTnwLEZ
AiZ4g5zoTidZey3JvfRvJjbGte4Ilw18sh6I/ChQsmq9szPRRCrfSHlt9miGjAbg3WUcUdRGLaL4
EudMWWiq05/DFWrsYEuMD37hI0TwLKtoKrwMsnCfohTeVA2JvI0hWWRQUlBbM1CNK0V/cS79kpfK
G5gx4GNfCaGJRG/h1ayFDyRl+j/QKR6HOwUkhTbFVCnDVmKUOJ1gn7RK+iCa2EJ9EGPMhYOqyWNm
k1FMRNIYZu+BEfySFRoFAJBEiP3CJC6/Ii0uxkvqPDEQL07GSLPmK8TAhEqoVqMiGoqItDZN5kpG
ftFSbMkELREF7mITgmpjscvqfHd2U0R6zK+eMGHPkSBRNyk5e9PsRXxBIRabi4H1ZnKYuTEJDwId
jJWxPGkQpRI0LPImUhD4ZFmAdjQKG9WsDSKTXoVGxiXQplz3oQHBDIh6NDBJblDzQINLWBPbhPDF
LCFOZDwFhDaS1R9RvAI4WTBrF5LloKZNG6zuPIooiTA2vAWs2UcOzkZRPWhJ+8jjLwLpTnRmBpYY
y8ikcoabMkz4JXvJBlhSiGXsUKJMihMYwNr5GG+i7PNH03MQn2wg2+haN7CK9Ihyy2RT7wIu+BMf
TFmyGPk5NLW6abFVN9mZQUkPNJimW9sW0nY/+DHyF/Rl3kMNPbmK21EkOQhJioMoVMRI1va2yLrw
8s4BLmCz3sUmb0OUfd7NAnWHA4t9EJDr4MZExBu2HM3k+je43GJapVock/8AhDGrdVIeTZCTm/Iz
Y0nH0PjoQSNtrGfRWNBlM4r3/RE9auILnfwPe282ml6b0JtX+Agm8Rzr4xz0cnIX0cdGPATXFi56
Fg+wCrX3jZU3GUpXSQUcFMob3Fk3yowWy40P0moG2ti2K70RrGRCx3Ej/BxRrwLfvchVrmonBqis
2TyF1aS2j+UVhP8A7GAKt6/RlW/jkRj8n/B7eUWLGaVI8IJWkfttzwSRmDdTKtrQi7pFhIYh0O0u
SVD+xCmihHUEiT/0bbghtuRiY52LAW46+CAHkaEBWENAMTZqzU8IhjFosLwESEjqEzJGWgwrOdD8
LDYHifNGCPTHyY+ToMLr4YkQcGgsCUH/AGS2LulQ4ra0Yks55IblCOWrREm+Cgo2OsnaZI8N0syo
TnXBpQuBHuCI1I6Z18qJheBF8pT62LJmM+rG6WvkequIgQWqwjYR0Efs+GKBsxOYU3lijYOeC9uN
Ck1oSRYzBoUxePghs2xZyZgzAWXp7Fpog47DOGmZyswJSqGvZrp7Jy6NtybdilTolC17GRUhthbP
A4mwxye9FsuTBrcl6FxfIXbtqGpPL4G3PcIi0kJauMsjBPAnTEyBjKL7Ah0xgdlV+UOdiyMx2Q27
eoJxqnQnxPUGdVjGMIdZgre1ySY9Il0oztset38IEgj7Rk5K0h3jjwOLyZIvquomN8kfkrTH3oOC
8F3hCaxB8p2PvpkRA65qlMXkYE6GptUdVHFyCEtcG99hNMNWFEtXgrmIPy4KCcpgcRXNpaYSHtq4
CnceB4WE+RV04QRFSyGd3XYoaUP2N+JJsVd3IWHmYffhFVkSfixSlTr7EbtEQ1ZXA7n2Tf8ATaot
iNco8dTDJcHobKklQuiLhSngZe7g7tpPYat4vsYCR5oyVgHSzwEcmCyCSkuRrJxn5sWHVqojb2r5
QnEtoYGNG+3QgyKrrnJXBRUljuCVROhVRH+olMM9jaM4VmHXigkjYavZUVz8NQbmRurETGfMDij5
jRtoIZynhglTl2ErDeM0yrk8KVFhR2CxuN5CEbYIBlhYdGcN1iapvTF0tDpWHxFtk2VSOmApyPgx
TtwVZzXRAwk7XLk1PeRtObW1kZVvXSNCq7TM4UlG40L5svZjYSnwIKnbtM2WDNECx+MUyyyPmIP4
BbYVzYMnStg4UfIYn1BgfB0hhhfDuWOaF5Zn+yyGidi8MWK/QDWJh9FRLxlsmOWmfl8igjTIOfvd
8Alxk6iWrwKETKIdI3Io26G2tRNa4R0/kNvhxZg0ghPwcGXJBK+LZyPTQxrMhm2+BmsCAj6BNPhi
kyQano3rMIF56Z1CeTNE6GTE2Gs7TKAzOBktwm20NvOETauQgL5mxbaw2PYYxrJtTYkx/C3BMmxG
Ixb40XlrPY1tz4QqpPoX6t2Lb4exZlm6pA5CmS/ZmEngIulciHe7ZYwG3IWUlLT/AGJJLE4z80ht
NCzKt9PGSM2ckZ9/YniRYr6Y8NeAjrjC1T0hIB1zv2QnsPQnpNW0x+H4HCFdorzPJQf6EFibwRj2
ChiY/rN7KhudUQ8pvIs74OxrG3xkZuU4uvswgrwKL/lSja3yOCzCtG6CvUsDLm8CaoV1iJsaUKZg
iyaOxs+kNerkwlWBIyX7CVhfrR7HhJGgoKwq1ujLQheg7wIXI1RKyh7knZgjPZMp/ZrqODAiXRIf
cEk2nsefJeH2OW+06NpULkdeBwx+SVu+QrOt+RsXqyjfFWxJfsmOK+0EmbvRury7eTSMfllPToSp
rlyKZ3+TfPgLTscsQEjEHpUPDrOJDxyWYUjTDoJsP3GSWReRlWD9mbI8jrhXTEV7IfomGfCefkOU
nBFaiQ66W47beHQzzzHoU8OhzZZ5IbGbINjX3scml7Gx3o+jNBqpXmi9afk/CjsouB5LVGQ+ZE/O
RL9wR7F1NiBKPRns6tbKLW1wLPYXoe/VtkvqrQZFr1lFN3pcmoYIkOJB/I8CQNglaudiomL0N6+r
y2LGqC+iERdVTGymqXeGhUeaPQhYMz5Fp7aRmSy0y0bebSyMeQ8PMJVKoil9sUKDS0lpG0FqDwNv
bEDGqNLkVJJS6y8CrN/rI6t8ctDsi23XxYbIDTz2YZDSMZWdDSbGL9ozytJ0IFwkqKXOY2VJCUNe
wlxj6GGg7P8AskMTG95QT3em+4YQ/mPtX27gRuk4eDYsOgO6x1Gn7FzX3sQbpxR1utE27HmyPJH0
DzbcNsjcavpswMLp0c96ou6jJYzyK3H5i3/kSavSO0eTZzDrgc0b8cHNS8DNqjp0Vvxv4IMJD6C4
4FmjSdAyNE5LAStr/cUxX5CPBfk9DP8AKnAIDz8D1+wFM7ZsbNG2RjsY9HHxcR5HhrsqiR16Jr6E
qb0JMixDviINoWEHnd0xsttGMeOX2KzKnNEvDPLyLjY1l0/JdpKXZrbKOhNvYquZ4bEsn6UdDdiZ
FosKFIeB5HIzbLTXynqGSnwPisYRTpxNCdWhThvYr3dCrU8FTT1R2kBAS/Ztr7eBr38CVsFzUXkU
OttdMYcgrQehdzeCRs/6Lyr0a4QVNUE5WWJI4OqZhthtFyN2TxgXNtT+jZvAmDHYsggw2L0PivoP
oWHOm8iRp2IDQ9D5t5G8mTfK8GI7sOwyQ/swI1ORoqhk8sSmK9DiM+f4XFZd8i5GfJdV4IuaFK5X
kYmUGnWhZECv0PBRFhU2HY0p1Qb4bdsr2xmwTU6LLhit4MW/Xks0qGOd0K1vo2JuGWL2GpVXvJeO
/wBj5im6hB2odrWineh49lnOvI7bb/TONsaKAVWX/wAJ3fqJYvwKW6NFgb0JKpwWJoGngy1+ztw+
29tDHyZHx2/tg2A/A+pVeRKc9AtTSNGPoG9xnx9CHMCtf0tC2HTPtDE/RMaElYluauSW5CNF0J0K
y3dUur96DWNifA6wwZX4N9RD09DlER+3mX3EjT2FZ5XMKTKLWF4RlwUOSkcwlObQs0ryQkzuhbm8
y1Y2VHnJK9iYkqOWDV4N8rgUVysCaxfaH83WoN6hqpTOlHF/czQ1GEqi2Pst7kEnBWwmOrga2ZpI
iMOh8CLysLoTaEOhDZV+eiIFpkS1lvkYQdIjsFw0SPIILDE04iH8QeaHC0P0OaYsRcjQtrqocPob
LyMJ1izQ9b5qwSkJsqJTqhdg2Cwrxi5G/PWU2KwqKtBIWM3RRzGcdEgSbw5sVxptEcSe0QrthJOF
pMX0KgLg0YYw9B5EFxoY4rrSGEovZhVSaP8ATJuidT8EhE22giim8Ah1J8msCSx6ITivYbjzi6Ef
mEdk0TYiyULbbVwhdd2gbOPkPQyXvDAr220Omk3BqoipllTRjAhXqYjNjVkdDaIj7KbwpXgPXWaY
lIm08+EJwS9hqJQ5ltghDGYPQ83bEk6GbpiNjekwHUC4Nv4NM38NEyTwcsKRVTDCX0TwQ/8AA7xG
8s3Bz7ixix5kGI2lDq4+BL2Z5JsJ8F2SeCixkXSiyc9YOTKuTvldBMC5F00sB9dn6KuKQxrJsyla
b2bMplyJDdc+GIMuwhDitdGk0vwAaeLcUsirAxgX6vmLz+yEiYxsmrlCAlRtlFk/lVNdnGND+kSG
P9DIMLMOsIFDACBTSJYEO1ehtmR6xxRGgsCM561BElAnQPkw5wLEqHyId76Fat9xJnIa/wCA3/Vq
wYyU8D49htUpeia8DnEYn2DSt7g4qSrGJ4fRlPMxkBpeD0VMPozlJGtIXSESSJWyvQUwKsXHI6NK
CTOxCQ1OA2D9tfQi7LJ4H+xOcmMEXREtaii1CSOQKcDBIUDC5x0cXV5G3ckraUl9+FAsTMtYuzeh
/ZJPksCqeCa74g5HyFWUN9KJVuqItUDWpb8CBgIVYL6JPqAmiqjda9CItKFBrBrgoIWYEG8UPELy
ECmTXVFTJzbnk2ZW15yIUU3MEa4aMcN022HYzpxBc3lHocJhoYcpFNj5RYZFgtzZG8hxZRjlXQc0
pqF+bolSprgaJRtVeRJ6Njck1sjlG+CZK8pkZqVITmU3DCh4LCoMcwohroJ4OLqJMjlY9WkOWUfk
SUzcwM9zyLC9MuyQp6xBbQMz7pYEEruohG034PSRdA7mGpwwxeWH9GYh9Aj4GkR7Tr4u/cx18lN5
1u+hp0tsOdYkNI1ETZgdvkP2tuiAasrJMlFT/RWwqWg7wkTb4MApZIxasXBYWvAlEPkINTeN6GMV
8bJsqVYamNNLoQJvJcCvMCMyHShzEdt6IdqM2txE8kzeUMXs6BEEcInyHujBpo0VRCfkQFG0VM8D
voHBaVNGame4AjJ8B5OJsmUMMaNDuoraDA2t9zAlOBvK4MpnacCFb4S8Hf8A0aFJaDHT2qBLMwZZ
ZTRtshvpRONm5GYphvYhecZEOL33eRLW5vYhRkDbMkTVK4FSzbSzSHzSZPqGwnPRNKdGarS8lUdj
Xsa3KlrkqvMNsbMct1j3Waugnbxdi8VcwE8Q61GuIHGZL6exARMN9tmsUsE/0cHRc/D7Ps9JkK3Q
0vQ2k0Lj0O9Nvfx0mPMcVTkck8AfyLRcNhEGPAxIjaTUdaWqlHLShLb4WTBlkVTBioZQkgtTLhkj
gTLggYhgo1yPAtitEs/CPazIrBcCQT0ochISRFwZ3GFqbNQ4ZmkrQzXYCsJC1EVSnATZsrEoYhwZ
RrgrbauSR6wYpxcFOmFVOHC4BidwV0yGcLTZsEVHENDCCD/odqhjUH9AWlHnAh2mzywc3EcCkM8p
ZjAPAiEsZniEagitkSCjQ5wWC7KVXAvpL4cwWx0L8HJsPYONtmKbCKbwK9VuKb3eINFVItrN0SUw
M+oRY3K4Lcwsu01xiHU3ATRukDdofm6NiXcCe31h4cPa5J7KLyTT+yrqxSySfGD0gWvDHxdesB6x
RvpF0VXQtLkYHKJH0NevMLx0U73+TMCTwxDXw4NflcElzcRmPshrgGlCbXWT/wC6G5ifKgpLJLhr
YxZ16E8WktBSOFBpVl1PEWhT6vgJtbOOJlpIY1smMDWrN7M2e3gvd4OJRMrt7Hfw3zXgKmYxvg9M
GpHRqoatt3oyXar+DJnHLEqyrD+DdOQIlrsPrSi7GhVTPo0AQTIpy4MW51oUSvIZ1TpJYIZ1oDKW
VJNjJdKkuBq2RedTQ8KhaSwwzyLsTzBQYX9fIUTJrvJIm8hofBaxMPi5DaNQZsdZExvMzyLVYyMR
Nm8fEUWyY2JRdGbS4hwxZgQRruuSbc0CLrjEWQxisZJr6kmzQwymItUyy2rD7P0ENsN9rotRrE6o
Z67lGIhvOGuwrJ54+TDxosgm4+hlz8nMMa3KvoZv+4VO5p6HyPLTfAgqK6NdiGMf0k3EjXkdC6oh
6zjthYt/SNjtkhA7pMckpnkb5HgbZ/fIlWqi8GaxQ55qLPsUWIXAWblo1BRjr6YRhYS062XA9kF3
9UVZbMSCmsMI4KoXDMdzaK8BVuuLokblnYIUzjOULDXMi2pHA62iLoa57G2qcCmLSy4EnpEn2dBp
B2V5CqclZfeRxmxuMeWN5Mp1iDXwVQSw4GGKiFlMPMHuQhvTypXmNDujyFxSzXBqDwLRJiyKtpnY
ZWEqn9K+4Udq5QN2GzIfYY7txFo+a1iIaiFyyQyPDGoeDQyGJF8lvwb4SCmnqhlEfAtHQnzwkVTY
uNiNHIjtCA9+mJEuTlBUj6gcwhKYTQUWkPx8qwaclPfKV2SAfL4KB5dCUpiTZFJ+gfP2yNo9vRPT
QpZMoZ4FciiEnopdFfUSmC0WAk4Tj4DWZXAnlBb/AChLpMeRjOX8Lj2oIn0MQQltvDUdMUz/AAYl
3aEt00kQEFFHhGlcPhz1mdCEbTYSsGy6A4HVulRYanRp1BNbWxZT9G5jVEOjtu8iZSeVyuGy1Nq7
bFCDdmEAnME3Q+0s/Q9DkbQ1tsQnS6GDzEYcFFPzxpFPobDkLQXsEEJOmBxc8DVesihgFzxLG3EG
FFqEvSjwV0Rx0PhO8tEtckYMZ0Ut/DJK1YnBFYRbGdIk3qHZtknewophdDu5n/Cz2zof7zTBslo4
h6whQ4c5LEvE5cgXxtr7KrD/AMQrZO4uAhfb/kRU4m8jgh4UiGLEYYiRU6XI5tnlpuFKHhrAvVg/
sKerekYuXYSeo8gwtzIWObLNItTYzp4posZUnWUoYrLGjwPaYdNIvczLwJacYgnZ+Ctl9DuMbWYI
6ggm3m77FWaSg/TFq7DinmLWDpYtSsfgCSjxo58b0YiJt8jN4wtDoE0GPi+DhNIMXsDSb29+xX75
itK2wERr5N4OdI5DasiWRmekUmNmWP8A9RK947iI9CVzOv8ABwO5MSp5pmFxhIf365fISNeQczSX
LFV1AoJqz4SQ1JKVvkfQ3VWxMb2OjJhs58iaHsa2mf6Nix0JY6Zeoee8Kp7MmIV6D9+oJOzU6Fg0
XyM/KsvoSg5x5M2uztQ4HHf4MYqitRy6C+j/ACjKMk8K8EM1dcDSllvwbWVJ8EYPpIXtNVxsybfh
cs5UI+yKcr2HBUTqjelG3a5P4PRS4El9G2Yo3j4KLBFx5I5Y6VaErg+gQ3UZn1MwNctLIZOMaYql
CprQxIkQUlkx6OIMNcWi0mk8jQr0JMrTktZvIQkmYaWQn7F0KQPlNQ+SxngLQlky0YHAuB5qnpMC
0uL5EJcj8GAuGQpxIR3VMZhqmTfsFCRLkX0uuhpm4F8ZIe+oZjlF1IK4t6MzbFypl2ZKSLnNEVEv
QWc6NbsSW7o6gtidCxHvk2vRiSmYwj8j9q06ZrMFpVbE2q0NdhIYk0MxwTkHALZ7sJqEqwnggyjz
w0QSHBDmYbsSJaN+0Iv/AMkbY0FMsxdELy6y3IYTbghtphfpaGkZhsyzrkNnZcWwQXJSmTrN8Nxc
azkkboZOgpVoy2Z7Bkq4E472PqYQYnV0xTbZtMsvtPLRYd5Emq9izQqWMwTXaMhpgcOhTLk55TY1
tv0Pg/dH27f/AIJL6I94ZzEaH/4w173+iSdAuNLvZl6ehZQ3kjJh3AmVgiolkxwi/A5QsJDPTBTJ
mS0SESa2Z1zk6ZwbEUhhwNFyrI1UqqO4TZFDtKMh/wDCEK0VqIk6TUYG5eoeaMECG4lgS0zBG1Xs
Q1tG3kxZa+hBkbgIbIgJGwTJBNW9Fdu6Sb0RnqKZLI01C0s32+B27J3IbdMOGNaCQmnxQulLQS21
g2+XNGupdYokTL0zGBMFC7tph7wLXafJ0VMw6MkYPs2LKjE29M2XBJJmjyy+bol4ZKfBnSYI3mFc
j5hUG6sdA6Z7El4mYIjJpS5MwDb+xrIuBBvuF2vNrkJhMdh/ZGGgE+UZg+GtDKZil+E4VzcVBJDT
caGaK3dwKssratEcWUJ2Lz9zgrCSScHtdB7jEyJi6ymQdadlVdC05Npwirrw29di1Ja2kYVvP0Ed
Q86UiDwRGGPDLgeR+RLwmQO9ECnrN5Qys3p6M5ykqEhWRx7oW6JISqFBKq7w0hqh6xkyNSKZp35G
Z/zDfmh5HKu7vJMQO0Man+Qi3FVjZ4l5GqU/H/8ABn7JXnJNWnMTE51IoUyqwYaUGJMxDz8837C6
4mq8C5sNvLKG8FnA2hZQsp0YfHx2qFHXSjwbjDsZqK/FgUCd5XRIZS0v+mjJQzx3GGIVwvgTkb7E
iW0oqDDT3RhsqmqP2laXkn9ewJQMXU2kWBjs/KHIy4xurfw3gINZEJMmxZQRyLAlf06MLOGhC4K7
NhDefJgvDbhWMNtNPDH/AHAGc4+cjR/uTGL2NiY9lhQpLmZPAfHq9m/k1osAarZIIb7Qjo4TlvIt
VvJDSHdz6UW0F4Ywyz0ItkxFhzkUxrJpYuZhtV6ISyc8E0m4LwL7FMWJiMCZG+hmk70VRWaZAq8j
mpvoaL0PVkHrlByvENxTaFCDHho+uOw0om/ZSSUKhUqNiMkNHC8ne0mGJHQVcybp9KOV4ZlFnhPA
lJ3qV4w5GUMUQKWBpplcMX2a0rhO0yL+g1L+wznISbYYal5mzZDSE2oux16dhWmPsbTNk6UcnMUO
UCG0w3LexJb2ifvCKN2I9tIJI8+gsMnS3DYoIbneTpIxfel0PTEUZcGvbX4HCPX0KOoaUjGiovRA
hKjwZr8VE3akHd3WB6GS7FBW3zESiPtjVzcGx0D0xfJFf8tjI7Z5EjPQqwfUSlVXk5/DVOrsjvKb
JyiQ/uUWe4RNMRGJ7vJRdT+Gdc2mR1/JT4PIQsXhUbyHQZwNOBn2t2EN4M0eGLxyK7z9GZa46MFV
Imuhl9BSr2bHkCd5h9S4qTooGDXJcuQux2idiBY3kUaXg8D2r+hgDTcrZ9K4PceRrn7kNX7YtN/Y
caIKsP0hhRvyLNBYWRalK4GpLwisYofhhGoAfQLbwbj2OmjIhGPFsK/sYzmZ2Yk75Q+9KDuELkYs
WoXIrpPR7C1yKE10x5Pj0FqaUGRTdMT09g2EB/DPKH6IacuGYxNyCRLRx0WKhh7VPPId/gDG5izJ
eHB+OgkkrfAgNtcZHWTwNmgJqhuG9CZNFohJFX4FLzfImVVxOCXNniC4T7Qk7onMGKU7+FopRURw
sfQrqraTFTlNyhXQ60mJcOSvTz0LXIhshWvBTL7A8Wr6CRt8CGNBqFNjN/EN0kWMobyXHwOkRArT
NlTb6ysJqKx4OHwYI6aKnVhTR1yfR3Aocr0ZF19DipRIUWTSfBfX2YwcZgqGxJ8SHhjdGkngQt4G
mxsTGE3BNnLBi/jPThcJIecBZbEgz+sZsE41Cpv9CyE4a8YErnRtBfBGlZV9C7n8LoyVLt5Obl2J
ng8jVs+hNL/A+JUIRrPRgouqh+jPggn/AEx5u5pEYiM4X6GVt9xnjXJ5w3BSEbIbjU/RiCFdTQOj
YU0/SVq2d0dsajKPBCUNvgYR08GllImSy9GcMLj/AAPYYkttvQxDhyZQTgSfZ0FZeRFZrON/oxtW
Y3/QeEl9oxBQ0a2JeJdD2tT6ISynyh1U232hDCF9FfB0K5/WDG1fQb/syJ+C+h5ov4XpP0P1HlkN
vSHmFfRVMuBn0DtqzFTg3Dn8EtUdg9NYXEoQ9Rh40Ok0xyYVo8dD6SXSWiMcq/osKG/RLD6Dkn3F
NEnG4MLlEttYQkq1ldFfj4uDXmYymtwyX/I2wkmRW19DW4Dgywa+B0KtiZLbXowJF9FBWtqGYKXb
F9NJW4Xxs6Q9tE4SdneBNpb0Q7wCjA+miTzno+j8loZTY+0JcpPQtwDwNTsPJY0pWtCFCUW4Zhnx
B99vpjWofQ/KjPAq/bQvKhrEWhbHdtzhaNClCZG8YFNp5Be2OGKMsH6GG8bkmsRCm8LaLOPgQ5dM
gywo8ESivGC4ETl7GIrbWhFxTR1rNHt9ESrqDuccJw2ZECp0vmFnFJZSHimzlTgVIRP8WmKgJWE7
H5BNYK6JlDdnFBZyppodqUvDS35LTCDCzNstCBTdxDwK+kDeCtaIWjymjsJQuDtbXCMMXSaFRk0E
BUZPshC5C0iEStLAbKdKXLE+uakZgh9FFNkWXQph94aHPhkcay9iaL6yTOJUTXJKahgzrxt8jFgp
icMa1bAIEFdzfmx6GQ/8TMbVqqPi5l4Z7tXlEaYsTkivwGSpki8B4NhxEorVgUzmrYnDtWIU/oRo
c2lK+x2LHa8jEWrA5Z9xGTbdNDdpR4aFt7lNsbCA2BWU3wMhstI6IvsaHj4YFINf/A8UUq1kZguT
IX+mb8kDmuQ2PxNY4LiRRGnNCwNTiz4hBebSUFNVpKYDYRSZI8lITrflC13w5RroyISrPk05tUgm
BMSUyFB0yRuHBGOjQtknJkXTO7Jkp4JUic2OJY20hXc1uDuyXyLoIRs/4SjKQzSJmIKjRhAopodw
Im0g44J4HhOhOZhjTORUoRk1GRUnSQwnh0YmI2qYaLEPaRcScmHQwJMk/fobhjdoKESTBZHJpPhC
JWappphGLCMU38AGoEb6GQ1DDeeMFTEmdVco68EGcEkmR4kEqkpsgJT0tMrZt1UjFkIwp7CupOsn
PiiPKwcqGNmKxvRNPVIeOEnELfDo5nnoyigsYn2MLaLFGt6K6jbL3YIafQfqmkdofcFj2EwPgKTa
/aIzpcYGJb+zVOZIrFOEWfDgdSsD1qkYtOqdlG1hdPqD9EdJDaY8Cu+QdVPRp3noe7R4JAaGErla
LElDsuBwsxX9C8hjgUoZxCGFngclV9Eor6H9BY4+FrXQ7cFD0Zu5/AdpTRzxjoSXkYoiUbjwYHV4
wZtIZMpCEMzZIRpZ0YM9haMRvotYNN9DE4yCrGWxBibNVmSrTuhO44TwL3uFMWQewqEmgZAuR0w8
SooK80c9LHhDsV40KKRWh9R3kai7WTejWG9mLgZpQWSETSXRI80wQM2k++i+fYUEuqWQbvOtOEBY
hlVT4EKSfoXnjwmguGNlalOAv8Xkuq+Q8NDGDqYnxWENyroWg3zMpVVjdVgGWJVjlKW8F51Jozg1
UQ3GPKYclRU/pu80NGJ+Zl5JnjwFA8mO9KVofRVZ8D3SlSQ2l1L0ZlcMR4yPDtHAoDR3/Ah/gITl
TsOmZ/hU9ZMBVSuTaLzUdZqORvZZvIVOeUkXk1isK4M1UNELn+pM1uQ9fVxrYzOzcd5IohpU4O9F
VJOxcIWCCcFQ0OUmkrz5MlNOy4HgY5b2OJbGCZq31g9FDFfWL55volNroHrcBTlDHKaWYK3Rb4wN
Jto6K3ZF7NK31qF2G/4GjXAMcbXK8LyNqbIzIo6b0PLBwLIYaCP78WMuqRMaDJ4RxstaFcfkURm7
Ay9KAc0F/u5PQt/tQdC0RNKehlzok5ylsnbIPAAigQyLgtQbEc8cglNZOgc4/wBj/B4KLYxtiV+A
shFab28EL4491TY3ZgJS4NPfCFEyzno+1Iv7B4xyCvwh0zA4lsU1z0+oh4thFGw2JQlJnnFA3zIa
zyMQXsEOZ100vhiyCKzawRxlIJXQybtw0s8lhrY4tkFshdtoewxXLqoUj0WDRDVs1Q2NTC424Mu6
E8uGJQ2M8SENnpyDTWUiIW78lY5GqoXG/BVAxzbyZyOdXCfwHJSulsj7vgsTER7Eiqkxoe8fItu6
QuPiDocCvIyyi+gr0yF3Q5TML2huLTYQysY+TY5C0Kj2LCSU2KPFPo0G0LDgcAlF+zBDIV4Uhd1t
ldeDIM5Gj4PoBhXLFpFvBMYOxk/h0nAqzov2yLYKGWnnIzL0DV2QtddBSYEPdoh2NkiRKYITPoes
iVqUJajAZiwow+Ek8AqUuIJ9xVIhZJJUWBajyFyFrE4gkQ5DUUivhLbh2PeN0W8Ahd6JGJt5fxM0
OUSiE2QuJIkw7HRTO46btdk28EURP6RISp7R/ZMU6xnhr4RZSbeqkYNH+Ah5GuR9DI58Yyz6Cx/s
Y+k/hLlG8DxAlJ3FgW0T4jhkYrZi2f4DiVMANIdAqo0siwYNCG5tNrn2ZpA8IE2s/wD6GDWpwN6U
MEN1S22JCjNR9G0e1b+MgAWs210Dgxb+zleEag5Vy50GoybUp2NRJ09IUUGYMpo28vMwRSVIbtIc
Ib8eqFinAhJek0cf1jAXlJDmonodOTZTEemZOk6v0RyComeCOGJScBPD7Q3HW1sa/wBf6O3aMVeh
Je/LkufUxvWGSmXF5b/RWe03k1UNv8KTTHoZ27BHaj+FyLslyKi5ZNPwI6HAgTBiDdYxGSxYKWYQ
x6mGtCxwNLwH3n6Mh014icnSdJG67ZeCSePYnFsVM7HLzh3qHEmuSXwSGSm0Yl8qZjumPSMjANx5
EZWDKPEjI6aZKcEj2NZE0LLwSexqNM2/Sf2fsPAk/FM6jWS7Q9+fTr4K87bTMETT5+Emr6aJn/8A
EgehshMXwtCzOUZh41VZMiaOFR5vQ981oz2R4EuzgsuDNQzI3DgaK5Fewg4Hoe74aWMeIdTlFnT6
ErsSK9zRI9inO1GJ9daPMH2Mqjky/g7V29nEbGmJew11eBQ9cBZb+I29mBxjxUNk2rhjjlOB46tF
SibychQmnwXq7grDwD1/AgpOLo2BFdviBJDbzEG3qJB9DbesnqIrZRdYPMngO7d0awUoToWq0eCz
E+xYtu9ldvBVpVsYEfuiUGmqLjbLryxwJr3IoJoNVUahMJlIcDc2ISMFCwMq5HQzEEKikEZIQicu
zfhPmXBmoBwGoZjgdkG70eAuxPQaOB0dhfEYx92BBcDcyaFwYvob4AnSuBsQUF+K4JEyUwmgRlV0
bIE8EA8oGwUqonWkKExnlYyrkPMgdJ8uPAmnjWwtlJO0KmszSyLcELKrQfKOgzfOo/qeRjUAC8St
2h8r5gezHjLMDRpexuVPJkgTaMbyopplibQaE3wdCSKwUJyrkayVLQqf7bNKyKiVOh5dORPJHq5M
qCw9jw5WtmkU0LJTqEDWAmUezfYjJM3Pwmki0qt4KZ9UNrMlLJLsxsZUr/smHsf21UEGdC47RgVn
dXLGJs1rAxt8xFsyGMamWDKbAiV5trwOJ9KhZoDrHgLxzoYts1re4+cj6ZHJ0oaN3oujD1HWyY4N
7QKrgXgUWV9CMk2jbpGJK70LSZzwnoaVJPKexUUGNZ0VDKWKTGQO2J6rYzEy9nhyukvbjMlHhcRp
zRNYZ5XZRfxj3WJyI3ls9IkwWCCF3UYDXw9/JtCywR1qlgoB/HDksZ4HlV8BYZkG55+h0xT/AMoe
xsohbP8APhvBM/BQ1+ELoWL4FrGNG4ESHAstmnIj54FgsoObYJwVHKUbYhzT8B5d2XVEhKR56E5f
DKnLgczEeenklsU2M2QQ6zUG4ezaJHXw9lZoSyJsrZDSpXM+L2vQnriiOA2Ux6zgEdXuDu/B2vOU
1gYRPoS6T0Wz2EvCi+Kmy3/MZdiSGPbBZnIXyPIyKazDoArJasEqksOB+TESWEwSroWyn0JE2NWR
CLfRtIMxTdwLaKDvGULqrMGGAm4pExBwDYk1WKeQT+SZFpdpHuYjVygeKmRI+h2mWi4qwGHYZRxs
RoNIjHLRh/eRuCwKdqjsdHCvcDVT4HD2Y16kF8moyFLOSRTXIi6uApL3UW8U5IeIErCwTcmalBh2
2E54vBmS4GvCGK1zksi2Lt4i9FrWRFtWdObezGVNCYuFyIt+pbpAZYNtQl6jZIUt2+CQVTlokh3y
JNOMDrW63TJgQp12Vx2Z4EVNwfcUJN/qbFGPMqitUxV5E6lgjsjzolkCBLgLk3l+lNYKeWhTMy0S
7HjdDnQDEf0C5Oj5TpmD+BtfkHxYz+nLOzGIvOSacY8jk49j8UteRkFryJF5iYxK+1hjDW+nQ3gE
EAjDgQLMVLsXcq5AqYjEQxY14IE8lvJVxKmQJabpvHRRf9qqI5iSMUMa18DPPKoMa/BBjX0UVVch
Azpc+d/HwhKPuahCCk8Uqg2xU+BpteMsT3CdvkWr2kxkpj5dc5EBIvKuEajqPRJiPCpeLyuaSRMt
J8mR/ZplQW4l4MBODOiGM3U0Zu2X23syKMSt5ASBMK8hZyKLqLUJNeuxaCtR4DeJAhFWDCcVfuY+
YUKA1409nMsyYgIjRW4UA/O4jswFBViXWzYtsemPSdjgZVu/cJ5SL7Gv77KEBaMdU+hVLCrWxEcC
BHImyITF6Wo/InfQE7RyEvYxV26oScYqE+N0xLNq3YJ+ZHk7Nxk4tEpUmmtU8jQlSbRwyZeB6DxU
070HOpT9g8k/AF0rxqamhjZqv/8ABfBGVLY3CXHZVVyt8i9LBJ5gnU0j9UTJxBZSMeRIQu5PZPRf
2J/Yzk0LTn4hqlOF9i4GmxR8eRktpIehsLz2HcHEAmiop0vsrk4nAkGdyTFw1+gyzZLwKVtejHm+
S7Ui6Mb6R8iKDaXQpsD+yPKp+m/OlHRtlj1kBvIyjWTQrnJ5FrI1RobdKRpWXS2Pq88MaHm4g5ez
sXiOG02OLbTpCGxrIz5RbG7rTeRQ3HB18XJlQk+z9HGTCboHZEfCOjVRNPwNlTOykpvyc9p+CsJu
sjc0cfDZeLVdGkD2N34CEkdCAo7DtKWpQWQHoc19gbGkIjLOi4mljXmWBGKSJ2On2AjXlOk0Zp0x
yQeWOXDQjU4cEYNe21eGx6b1baEFHBiqkxy1Yiamt9UyLyBhbfIwV9DqKfDQiYZzQDsgFT6AYKhe
zn2VEBDsLV5awSVl7QiSV+BG35BpKdBeGMuvY1p6He9tMVLDzFqgvArXD66Puxdmbf8AgOSWj3kq
iWXwLhzQxZd0e2lYwqY5IP4BwhLD6Jdi9clFVfDKO6Mri7o7x36Gub7BdQhdi5u/VGxtiNNMbsnS
Y4xA0VDpIo6XlDM1V70PVeMT8eqlsySr7JVMJpWLtFyceNGwN3C0e44IbLLoUXzXRlyw/wA79ha1
YmMk38xIBhetGYy80b0DNDXXJ9NZvZJvp7Nuq5Q5nosOEMYJTEFp+wLzS8pj5R+mf4hhtQONwQ09
8E87yPqW9iHt2fXETG9FXnJNFnwMrR+2i31fY0wKUUuoOaNPNSFJhNi9g4ExSJ0j0BIR7EwYl0bH
p+HiM1ka6FBNngvdPchO9DEdllg8ZF0H5QacX4Q94S5hiaP5MgiI2T/Q6ICaeA95K7KOJdMibHQW
Um2Yl4GLGhHSM2JhdSk9CyFrpBe2vGzBfAaOjnuFJEMWYMG3mFdF9DbqrKE0Q4G278M+SnEE5q/a
IBMnFgSWapr5OtD3wBeVo52FN4qsSGkVW8HAVQj09SQ8/wAZo+sUTQRWjhIs3V4Y8RU5mz94FZes
PAsjd6MA9BpaRba4MxSBBu5rS4ElENWBDqNKCz6E2Q9zgZBXoL9jyWh5Q3lwb5Kc9DWS5NjQ/BeC
TqsZehBKSVi4Uf0YDFiQtHKsE4OXl8tC0pm0a6eTF8+IIhV+hV/xLkfwy32GQnS7HPrKUa3GvCOo
D/RLHm5wNiHrWRW/h4ZS0aOhLBcmjyZcyYmFyOwCuVrr4hJil9CXMITKmPCXDgszS/SEqnFhbfIm
lL2he2mS4MixvIrkg7X2MQcwotr8lKZ+h85gZyLkTCSehofBKJxo36JvEgYK5gYNfQbxl9FPIRz7
Fw0Frfij+RIfRQ2TBENBPIgpWWRT9RM2bYt2A0h35ZwPaRjI/RD/AMBnXL0K5H6FnaKzyMSKjb7H
sTa0CzcFiUc7FzxBiYpC07Wfo+xdwysOcoSmalkNO30KcuwhYoVNvY4RNAdV/AsZUJLHXRFv+BI5
WS4bkG8BQRbMYXkxapfyNBQZSE3gkUjXoUrFcyVaEZk5qCH/APBG2r6EltK8H/pA8+ZS1QbP/KHH
podnpCGhFdpBpujweIotN99CKlmeRCZ/MyENCzI9HPiuTxMCZjHKMezc5B+SnBN+BxtRPB0FSloX
btXQi5C5Ehgcl5eHkUS3cjHEa7h2LiIjgc2YoRZGBzrgyOwzWm4gwhs4JDVdrKaeqGiKS4HV5gTg
UxWmhsphgWYWbho8DUI2X8VzRPQgpOBVyUjmyW5kkQmtm0oYcerganJaLsjynbIUTriHNNK+Hwha
PLKiazGXBzsLrBAoLasyq5UjKoVOn3oHstJPolBuILRSPAzd7WhlaskJSVaFS9BNbLBlNWah1HU0
4LbIkpFQ3kUkoO18J+KYmBPXkbQWrgCCYJLag6L1MDNfn5C1kjB+fm0G7cSbRny9OC861i3e5PIy
TPc9GaFrEhhe8mEkVxtckzJMlMCEksanKNIEvobdlmGATUsCCKvJUU50NaovBu9cLkskvQMmIiMJ
FxKchkdekIm8nGqh0rC1pEbj5SMo32BkPXqwE/jjBPULwN3UlTHqzkcJncHmO5LQynpskhGDTM8j
zUrsh2eg3595lPRjwMGJLsVFrg4eTMJLIbmJ4VTW7nkZzNlcIfy6+PLMccVSGS+PjKZaLD+CX4Nn
BE5qmDwLfJPAqbIUEnKb3aaFbowJs2rKL2T0HYmtDxUsDHmMR64Eh1hB0tk2RU0Q7ChELAT2Tn6F
PZcjNoRXQr4E4NwT4aRsJNUXwWUJrHgY+WRmXuC7GiE8U5h+hRTWhwlawY+7MJhIaXsciUmioyDB
DOkOvtuzKFhGM6EDOl4PAA8zklpJkwNEhRfljS4H8rWPami8gWFMHhAbwnLNGBwkKTLLOUqNDlfR
A8sCZucCUt3uFo9DQN4MPHDxEYCQoYZ8HGM8CtOQ4uFGv4M7MDabK6F5DFqcX0H7hdD2Qx0JW14E
4E/ZASrGPAwMkh7bXAobBEgv42VorNwVflLA3Xc1kLgb8GMssaYCHwoLQ1lmiRNmi6yqs+IDi0tI
8JQm4ZE9zKHrxJscUrY3wZNZEIm32YWg86EZkYKOIwFZSLQqdF08mjVMilhWBWsbHJCZbJHkpFbn
YgQloyNSGS2XojDmGYnnLI93TUWjv48it4ilK8OhTRmpkwhhKjVdCriHITYkg0HOQ4HiXRCE6uCb
7Ka+geWGm0mKJU8k6Fekq1aNI6OGCxAq/JEacBkKW2xPPMRPLsq6LQHvdviDyI3YZXi8jkrOoF1S
SGKuRq0DQklPTWviZsBQaF4n4ovilF5FM2RV1JnoqrUrGIMSSOGSJpiS3wbcwJvwXLPvc005uUw2
PBG1BlMpPB+GZFNBl/IFybph6BgR9a2FdUVSDicfsJ6scS2Sy6RBQPjkUKjAt68jaXwuBFFdsNBU
QRwfqB1kKPdG7a6vyIHoXhfavMKlSZ2OCYh9R7vQzAPJ+R6RQahlE8CwGwRtwsQ5wvIwNe41iNL5
5Ma50MJhJ7YOYgXV4fHaT5TLAleluGc9IOLwXEJv0TRBqpQVkeF2MmpagoUmGKgQ06mYmuRBjrAv
GGrDG5jOpwqM0y0RztQKy5IxnQV1h8nEzQGLV6WESdDk/Bsb4mFloKBG8BFI7x/0gDAWm1GKW5H0
p5+VjB0s1sVwlInhmy5KXQ2SiE+KsYORvE48muHB65Ewyw4g6Y/JEcD8W2or6cISXgF3LGNGY7Os
ND7fD0M3sRWJRFR7jY4HeTLln/j4XPiMWcg0RpfGxKCVPIhvQofUJ92S3jCLhF46OWSXeSUoltgW
9SajBxwJkbFLzfKAL1dMSkW+m5C2RrI0ihgZ84cD8EKyLgRaPixbZwEJRjUSoZUMANPwK9gSvoKJ
wqXQpJ2YusQV9AxLgVTsbhf2UQiiHcYoG+CNEJvo334qF9umDhVawmPX9I8kOiUjwKhdeUIRRIXZ
0L+w19DNqIdzFfBy/ehWLoQ10xZ8/Cp21PjuGA9D3MFz38PCfRGmvhWEEp2vx/EdgBEU6+KbfD+d
dkwI2C+M0PXwI/mE1Q3mFBNtPbNRyE28RCtt4Ii7MXz/AOAsNslVuOiqljZmmhqIxlF0HyUE26Ks
Y+3hBU5/4J1h4CnsleWRxbNo0yJJmbLMdpxhijbIirYh6zdxbRFGWoWXCYeiz6eWbKuw9zCSexDD
8giegCmoTtFFdSCrdVHKyeDAtKY33g+0rRRCGqqYomtGnDM7eEtqMkV6bGaVHhGVHFl2YINzLgpg
ztlbgv8AItMN/wCIi3Ej+zfQtwN5kCnq5EajtsS5mvCggOcFY7yHVy+wre4xnOptiyGTlJxMEM/f
ARwdA3dk99pG6x/I7OidEMxdDLL1f8GTaUYvXKwaAzG6Na1cCxVzNjNB8IprknQXswqoq6VpbMYp
wzdDN12YujSDuKTm0F7W8v4KzBhIs6fI44rBlWeSEOrCcUjcbM2NbbTxUNqcFdFgBFgdFbGUOq46
lhjo3sgx1d4MXeghPvki2J5adZlcEQeF22WNzm6kKXFtBjjgrQs9xcfCf6Z2dlKXXsiX/wAwjsqh
8y85hLsvY8mxC5rp9jNMTyN9DyJQak+X0FfLHqG2N+mpgxkas8I+fkfJaYO7Qo3khCpoRswhHaiV
1cHrUyoGKxIhpbyUH1Yek4AzA6v8M0bFEmx4HJQhBgoQ34+HQf5JRbQ3KOaoew9BXnDJjR8w1Kbo
Jtpgk+CTIcXjLmlybKVtqffqJo6NLDe8/Gigpiq+ExVGx5QdRlTaykNSbWWWmwyeE3RYbEYRpS1B
seURinotpjugtzDcCj0XBeoT6BgKogprAyRnccbrofwaK7w8iMEDMNOfB0fyBDrdKML0xBYj4Q8F
pMtJpgoCGMbZSLQmAl3M0tNidXgOUdOMSFSbyhkkYHC4F3wErKhrU2xynrRzWgurtfHik2hHp5GQ
sjIsaHOVGl5CY8UZDRYDCOPgnNihGDpQNlIx5iymxRMPIhgU2WmomZrlOUjAh3catNMl3YdgHaxC
vY3nAzpskumRcpbdGbyh4Qk230NtSdkuHNtNg3WEPuRfwkI/JCzaT2iaCmeah3C6I57g2HTi8EuP
0YAJZ3kXcooz6EFptyQ6bMdDXvuEWLRCeudB1eGlhoLWQrMYhBU8uBUVc7eg+exIqZeGG5Y4LZok
79FHQ74Hvp0aFeV572bpKsFIE30TOjq2H7FViCmOyhOGNr9FU43lgcDWjI8Vr+DUww2A5PsSDkor
EpzlzFE8hnNkIZqMlTww3kn3TRwOTLwI+VcNkZrvRBqKRVqCmczoXdOOBqciYLOxyMQKtjmXttFc
dDBEnH+IrbbnoeK4TY7gtyfoe/AWU5tiVJ6DJVgYcrL8DIpwLwQh4dEKN/JgyGPCrxgSsy0kmRkh
4zI0YBWhSl7UnHkUtkTUVGxDM70lE3G+wj+jE2K/sVmYDfQs4lqaGTnjLK6WbSTf4eWjkW/ibEvo
MnPQ2SlwNi/aYbN5KSNveRr3SN6CFwJTsWx9m2Q6gtmTF0hchrdp4CDhNLOWhkeMhQORRz3yt7fB
FfXfIy/CNysGA4wbH6MLOVg8Ls2jSMpkY2bKUW4J1DSfA3Nlk3DP3Kb9GBgwmISDqOVRPbHvKlB1
4Zk0DX5I7FFMcKGVJ2JTJ5FgTPkW4WCuh/JI0eHkjilLyLTxdFDY1LPAmhYkI6JkyjGxj2YmDwmx
Yzl2hiiP0xKwbyWhf0UkXjI/izJ6aYlOFLmi8p6ZEZ4GxepZIEXoUW5ZwfDUaYgxLg6TaPAoITFo
mbtDolPjOyhIJFjdT86GVuMYV3CLqqfkw1P2OqN4yKocGTHFexPIG8uYzwYUtvglFmbAPtdDm3az
RsT9izbh/p9IWaKX2JtD4ElKBbZKMkKJNb/gvtq8E8f0aLkjZw9l+uApr3A1jKOmxsNMfYiNpRVL
12JYlKvHYxtauxJXVNKIAoo8LyOZ/ZMF32yGU/Yk8oibjgrtN8jV/sNbcjsQ0Pca4r0NG4JVk6bZ
OMvNORyoPy2KX1GxUcPDLoHdgy+jKbhLH7UtqTgzw/Iye0QaMPulmTXLFlNVwLclo2jntiUyn5Z+
V5mcWvsXicOXBkWtyL2s2GMbTVY+PwiLVJdoUlxa+RDA0h6UInzZlngxWjQkdbs4ISH72bHUxCEI
ozWMao8Ntj9J5ozQEFjio3TwpqI/Juy5HsGZhtsJbqUU0lo02Si4mMEVhy8eTYQON5iQzZKcMwtz
KY56fdL/AI2MqZKmLrDRLqSRtah//wADzpNLvo68WThLivIUZK7dCmv2HDJLJkSn0mUGqZ9jG2oy
FrqlMiKitpKDKJSkhb/0gt4zkU829ZJzGYG2d25NFQxN6W0K04XE0zbuhCdz6OrkAn5poZpXTQmJ
IzdyVnbMzIysAe7Ldeh55utvkQPaomqilEhklG9yfQ+ZHeRNia90b5lhOBHdhPCGdcmHSOvJNaZF
OSJUJ0SchcjU5XF0YLdqKEzkXF39BCglqbHJE5kaCtdo+jjIx8qrOhJGNFiVpIx78yPoxBYfbm6M
nf5omZZR0YQvxWYoWeg5zaOUxnZGVXkcRC05q6LQsf2BkO16rG5632D6GdDej+giLoaqax8jxt/u
OnI1nRdNZ80cyPIsi7jETo9G53fJy62B11L2Eti5HoemTvhiMIVI3Re2EpcfKD+GRTinHxHbyJmC
g8ZLYdpPGD8yQVHhz9RxHPaErc2u0bW/EkW7UxrKYVLhE2/qcA500KJi7Gp7t6NEl5HsZbKMvQ+4
75LHgTLM8x+hXmPoZwvhBmOhXyORiCYyhm1Wzk1cIdcXRfNmzUuiGgMsf2M4BkJl7FDzDoaeUJLf
6Cq0X0+xMq9Aglt4NreeyvgxqbGbDPLva+EAl3eB9ZNAfkU7xk2J9HgwwBxsLRJ/HEzyew1ViJ56
RJno6TeSzWvJBXRvWWjR+xsU06Zddy5H2FWVeLTmUzWsTxZ0K4baoa37wYUYxndjr+BjKtXgTUv1
EWccgKXQIHQZFZ/ZsHzM1N/imQv5NSyJYjwY+rvZl5UhfvhI/v2UAxzV5HhfbGVMjWtH2hcmvkyS
YgTgKolL2M4xfInYwi9Rn9q2PI2PHLCWO/ZfNHPG4YfwBt5u2LQjdO6UYZW/ZSxYkYK+zhbNdUdP
eRMF06z80bTLvsS6BmJ/qV3F7NxdfkG8ZvJbtjLUWUTvn8H1W37IlE1LgbSXnyPQTs2BhczHdxna
nnkmbInVl2KlZ41GQN1FPQ3sGmq8LgzYHYeQUqyYGCbMBMH5G3Bb2N7CnyRvkopCrk4St7G4Oxgb
tjdssJhto/oTt7G/IvkNbcjVI0VcLBuCGWLIsGG7ZXZaH3HIn5Dd4+NIsYMSLFbG6om5CjkxYmvw
Uw3jDE3xt7MF8I5F+R3BsqlnjRZXxeoxFmEUi6DUjkLkh2LeS4+Dfo4RqvI8Y+GxrAkJnA/ifD5f
g+kuxdaWRbNjIFDY5mkmROHSfkb4N+iolsiB2hLCrZYxBljDBLfRZmv4IotHgk0j0tpjFSuxxmDK
IOW1RK0pWMT6JvoKz+3i8EQRDSmgqQmyjToVNvjTzobJjccOHENkEuhnjIkuhayKoiMo0J2Q9LB6
4I6M5aYGjc2UYmDF0d06diBp52JuGMufDG4AplCgYiGzWOi3N6h5hOj5ZlixIFkZJphXXZgHkZom
NtDabLPZmVCi4CrZxFWDZ4FhDDdHRIoovIlfw6Qvkoyk5sQSDFoTEGJ/o8iwQ2K2WkM2jE2jQ1TQ
uDBwZ0baM2ZpticUK7vHwOc4EMT8HpkZsNlpVBo38U4qjfJcdsSLLEKxlnaaG6s0clozRtZJT4J5
E8m/Y8bFp+SsyIT6G8DNrJUs8irGJodU0ExtM5RUhsj1RiNHXkrYngYxdDj41QTMiiyVKix+BNEH
I6IjexGWxK8YOBl0dIzbyOlTIt+GUeWoN+RERDInGNk6VtlpCe9mgnDIssdRkJisaZ+DbwbjzK/k
t2IDF5Ih4l8igpDA3gbEymM58GKE0G79CDDCaQ2sko3wJUaQimyHhhkblyNHw2T6CstmTQg3y4Sz
GEtCWphB7proWFQrqEOQTtbPyoOhukalmJAlRzCCcFtFEZVhJqqw03JM6jKpSYh0wdS8CliofirC
4G74CV5LMLX+CmrEtVkKlt9Di8noY5NMzCcjKQiVNE4HI5XQxsrOdPonEw1YUcT3Oz6mJB5Mm9Bs
Tgovf/DmQ6xQPlj4Q32OrVwSykJS2cDFafocYREtguIwD7QWNllYyCyjSiIlH0VjyP8AwI/8MRhA
ipVjVHFIxwHOiKYGeBLOTDBtiwJTSCYplwZEyjwOPZkiDZO/h1gyL9EgrT2yLeS5Y0GhsUVLZo10
WvHwXArvxZkYn4G8aMrY2ZD+C0KhKGhHRPEFyCxeTJZFkWhrGsESivAxLNOvJsWEUTXLHhfBxCwi
qImCjfPxwhSEhsM0jJmpkgokcjwzQnAuTj4Jg42bBvBojIO8nR8OiF2GsF4Ecmv/AMN+BbHk0y2J
t+x4I9iYY7GZGjMOwvhqmmXD7PMeRZKRclKaiybNFjJclycjNxa0LIfwVlg3aLJcfD8oqhssRlr4
yNBLyNXDS0NSsMQxt/GmITkpsSFljfHxfsN5yWoTvw2+TFmbNaHwdGs+iSu26Ko0oU3gyiHwXJI/
BoEXp8MPRNvA7jyNX2KTHumUn+k07RDcMmaFZuH/AAQGIM1HoUtrQ0mlog3BhqWEQ2NkKrkfHOCN
DJoTIwXmhlMuD6/CZk0HzBGYoxLKEl0pt2QoJ4bpgf8A/R7TwJ1JsRBNRw88AoqRiGf1cMwtwPFF
EihjcQlKfQ9jQr1wU8qMQWleBXc4MEiE800awoyVyK9lzA3RBn2XuiwKjZ5HgUeAufgSsd0INGAs
seH7GzLY3oWR7FBg2ZwcIQjdHiN/DSOB6FYfRGRM9mEQj0ZQk2PBimASfBISULlKZdEhINYEG5Bc
eRuIePj4q0zvgbr4IXshgVohcmYO0WCifY86PYsqUMQhwOpUWyoywxfFHsYnwufBceB0PGypn0Nk
42PtCTJBwVIdbGISosDtMNeRhO6CDbxdFNhbpkvg1gw2Kn0WsmTBtlCdIkcuvh7RrIshE3gvXzKM
QsFYMMiGg3EU2xYZ+CejyLODYTwNPsWBsTE6318J8B4MI4D3suColL38T9jY3hFsHgo4klRiUefj
RIpsUjT4N+CFocN+B1aQskbxlqMymV0F+ma1jQkK0nodHgSpTEVRkNm3TmIeh/0ixKaZHrXMG5Qy
qR1a5FU3A9ORmwq0WjEAAn5gqKP0RWGOn4E5JxdoqJuHciamVzTcshbzH4TJikbjDKK6HL2Bo+TI
6SJVvBbvQv2s1oYq+eBrcx2N+nFPQNfP4EQoGUSzx5OSgcW1TAMQ0V0Pc04KTzT6UNIxDB8mRhk9
qnbQtdZSJkhuKVUyq4NKGtXg7uBeKGYTAi4IQgLT7MGRiDT9BqDAXA1SRYGnChuJRiYx8RjWS29C
hoWMs2NimJYNaGbYkWSqh6+FkaEEoiZrY3PPwjYWvgxm6JtI2NlVFh4HnJI8mXwby8DwKlSUYPAk
P4PLwRwXJvPwkpTgXYk2JBKMo3R5hLimghSdGuQkDfA1mDmG2RtcbOCUjINS0abRISkdM0yZNLRo
x8lMgLYSiYEFPwnQ3gQvnEISkB3ZYijZwXI2CjaFn4eRsaLEXBRUTyOtl0YykwLCz8cF+UqH2Jh8
mFoaolkfQ1C0keR0oya+NjUHwQ5BoaG0QRRFZsvgjr1DAJ4jMy6MHBYw3EdNER19j/JeCC71nFEt
Gpllk09hIagP0YdLGhZiTGEGaWoLHdF0TKR4K20wxJPOYGSqhPkL+E2MJSZPqs30PJtXFZlx20hG
sj/iQgyf5C2SM9h9SHowWabNNkTMTNzUIOLHZiDBl7i+suZDW8jzKXkcmSXIZIi9jVHbnIzYibOh
o5+zRDbd0ZMgqDdZEow09nuYDMgaw7HdD7G5V12KFNIakKF6Xqi3dJ80gH7GUfcxXiIZfcUU8Kww
mOv2aRSCpMvAfsFMqNcM5eGxDT6HwleDgxsM8pC+nxU4cNMakNWIJpt+De5Q4mNjQ8iQPdPhrsTy
S6Q5wPmQ4wKc/JMxMmi16NCTPBS4Nj18IOcToeWUJnBPjeIN9hxtDRCR5IcjHmh0zQkQkWyKEsDd
FnDYeKSjVwJiwjkimk7Cy3gUPePjIhBM0JMTtiedm9Bu3yEqPoRhkWRvAwjwJGZZZZoa+EGzL2Ov
SfBLizOxCxhKi4GoHgFZzlHH4L6n8ei0ZDg3Lj0c7/Bm0aFQ4ExRqVFg00vKFUI0DmGwfQuSBYzC
KMwi1kLk5ORrJzUJfpkQcC3TAfYmMcos+baLAbwNjIgxIkcljYoxuvhK0Y2V4G/iBlRujZ0PBuHI
htEWDwOCDBYya5HE58W/Av0CZcNjyrYvTU8wmKbYZg2uqIar2Z8KLENyja7RCkh8sSCrHBaF7Mzq
ky0j9FBt7B4e/JGV1+Y2r8GR4KG9Ippm3aKc32N2pWiCMznZstPDFpKfYakYGrTr0Nu1+2JYlfZl
shAVXTg9mmmcaGJTHmK8s4K12Qs/Y8lNkZuhWMvZh1DSh4hkhftDlGPyJHVohosmKaH+H/iYcpj2
PR6Lhr7EjdZE11P04Jt9sbtuBkpr0c8cEobTyUjVcfNFywe6K9GmxL3ggOC6Q/Ot7MyyMUZZX+CN
0PgZZSNr2bhfwbXBV08kKj6OZA7kYx3QZKXJk4noYHGO7xiVN94cr+ByTXwSGn4spg9Kxv4fyxOK
MD1bBgfAY5vgT0oGMHXg7wNWYkKhv/JHNXXxFQRxFBzUm7pFJ7ehzBQanOTNMgxfIeHu4OevI/2J
2bcDPA+F4aGtjViGbMzFY4HT+OwchJZ4HAZ0UGvyGpyfRVlXgUexNxGcIxiw2eBlC6ORaag2W7a2
K6eMjOjNsgwkQwbz9DXo8sy7yboqeTSrRzoTLg1GMAuqjG0JVmpQsC0X5QkUFE4GiL0xZayaIJ3V
2VOrsIHjE2hkrow2hWCEp+wZiU2E0hLsXBANbCYsJvUNLlCsD6+4kNc30IhRODsxMChW4PQirj0L
KcjAsqgtIjaT+HwjqErHgtNDd+bjAln49jYXxof6aQjEmzn5fBeRvPw6FCb4ONkpcCwhsWjFm02P
RIjY3lDoyJghr0bvPy4+LTeEzSnzhs2IaGBXcQSFGm6G8k0Wi+DLKwZ4GLC6CMiW0FqpjA0VZVmB
E9DB69DUiVQz4NzRZ/gMrJBTxlinjzxwIsLktfFmlCZTI3UwMJ32NoQcrw8j70ZzKUloYYSFJSuR
GQRSYayKl3ocIh5SRikqyQNeVroZElZNCQ3m5mOQxElULB0jQkgkwippQXYEEVUKKrf+GsKkSQak
SYzL6GTWPCOOpwZ85RiQnW4NiE0kO0tjCiUF1paJXBPoRagx5Yq2sxEKYIqmlLGDlohyRbbMQnbh
YLlOUMesTwKFXAoSDc2UdMRn1gQpWGR1EIo0W20b14ejFGl0kyijcy5FcqmeyDLHJjGs4Heknehj
pCLsIxWYlMDXSrMczXCH+B/CQtFvaKEbQ966xfz+CjKydIejJcotpYEGVMoFdi32Rmjz8ZDgDGRN
2Vk9pkmUmWFOKGemvoXS3NFGNH+JmLY26/BhUfRbPwjBWu0PJp3svd2uPhcS5VEeWVJXCBafAmIe
cwyWjP8AEcLOAbsYGM6FjyK2yuBmZtYjlTI35HRGdO5T9GNtejKm5aE1WfoZs9SshZRV+ipUdLoY
LFnBbF0yjPszlpriFuGnhHG9CXRBKNciUqkf0XFHQTyTH+R4SgvYpfQWVFEsHRLSw8CI63LDOWt/
R4gQ+S8axJWJ8bE27mC9ydJ7IycoXcPx1By68ExcyZIXHZfvLRaRoHbYSJIQF9mV+QVVG7pndZKC
QzaTKYfHV/WPUWolqYy7YtQcxiVlFISqnwHBsTyzkUlGr05+AfwOGNDsohJyRibNfFiMvhZyJYNB
05JoeCi0TJWJq5GQs/BWxQyUWNm/BDejgaNmSCWRqCGXItOPlbLg2cifwSfCTROyUuBxxUZdBowx
hmyp8Ddf0L1WNgE39IbNoKtVHNYYGHNi19ifukObWGxjl2CXDlHGfIRjaKlcF+PTRvSlacwbsTOv
jwR8F/TJYWiY8i/QMly7F4MfJsjvLKqF1JKBI55HaR4Ks1gQtwLq6psgY0hh+hjx7wK4b4SXbFhY
92fQlabhItyI9QY6XIxDiQq8xHaQWecIkfsJgZTKMHCbYjU9x4SwRZaVoU9dkAtIe01yWJJhqmBo
CE/5aDzxEWzyhEcXZJJHrYUzkC0EHM/7PLrJpuHMxHZzNGkxEzQiixs2CTwErGI6rRDdNJTRquGt
qZe6Y1ryJfaN+4ujMnKEMeILcXKR2DobKstCMqq9pD9FlHhGoghhYxTHBC+g2foRJQunRZ+ZT8LO
ANUaQN3JZ5Y8v2UVw9HqoZbdxC2ReBVTXnbG3f4jOyryh1fGhhRyDYQIuPqYY2mhLV0aGnZBdsFC
cRVlWEicL/g9PkxHarIFg2VDB6ha5IqqvtGNT6Q9QodjWxpjMFnUL8MzZoV504GzrsS7kUVBJGkk
NLYe0Oxbr4EGTlpGDTZJQZwM2UvAjPBAoPw/hTLNZT21UxyOqDQZrzRwQZoZFwBJIpjq43KNUBwj
qL0NMOu+hSrUNkiVErLqjfSReBbIZTBvJQ3ySIm6OBCQlSQeMbOxXqwAUkWWuRko4SW41wLpyMGp
krGYmbZ2XHXTOHNFYJJNIq6QKKqVp0ibM7MVGDFL8i2kNWWEUnEwSTgkS1EZp0Sg5IW6ER8bKWfh
MDa7MNjzo0PkPaORqs6MIVMVhGZMXRlMyE6jD+F7MCFUOYZHnIvihULBajeCFnxwP4IcC/Dkufm/
D2IeyiXZ5KNMuQyE22qIeGBqxbh4OB1ByUwbySPIIlWcEv5P6IY8FBOcGbZE6YKZc+SyT8C1H0az
JoUkKK4qo014fF50Qz0SIQ8iNIdOYlYvhGHjqfsJUJMD0uhusvI5x7TJh52higSztUMQV9DHuWGN
ZW1GoMNbLP6HdhPA9K8gxS9DJmBWrXAayUy3scfgo4RnsILmUXRVLaFoEuQRGV9CF+UZo23GJDe2
Ik7Ylx/UCW/oxRhubcRtVhqL8T7IlHoKrg0MiWMjgF6V7gwIskw2kObPcpCQ9BVFVcjNgG5V3sU2
RMsf2G3oVh4DU4GXhYuSMqbPMDwNWTKWSXVkRBeehgK5lMVLiC6mIoNbTn+gRweymfBe8z2FM2Kb
jojohQyAm2BK9FNjm4ljw2mKtk+QR51ije4PrORhXc/CnMlJp/CGNkE8p8LV+DkJfgxqS0Mdk2io
83JkXyrO8KbCs+QvYVP/AEdLuCwma7auR9rdmTKmZvQm/QhzLy/Bp34D27/8BUHTNmq0GhArFgVQ
+hiNtY+Di1r5pD0dMUfRy/8AgxzhS08ifrZ/01hBnmL36OIJEIJI4qMtp35FfNkdC9pWGP4s7S6Q
3LRq8mP13RzEYiDvKA1ZsJaNHQrld02IXNG+xpfXuDKjpjJ912PdC7eRUndkQ0878DayT9DoQNax
a38poZrzKzyPArc8LgabRtr8Fh16G3xx/Rgj0jLJtUXZvNWBAg08dmV2VFQg67guuHhE9tkG7IWD
Ya5FULyc+CEOcDYskaQsj/fxaxEoNDc+DwPsYR7FnRGnkoqlENeRCND3ggPIexIhko3k9Bqi0YS8
mzRhseyGjbNMZB4Qq38I5Lhivg5abE/Jjkd6MvZ5GKdixRm8TS2VHDPOsjLRCrOAh4hwobFospME
zwJRcTWhBXgVHOjEMYtBkTTRLcB8jLUQ/fxpFqGexyaHlzKnngeckUy7E0zcE4R8A4tI2KaLFwbE
OW1wQvmsyxqSB/o9tu2aoDossCfbK6s4G56EXTbUUauEG9dj+qhmDQ7PYeGz4bP0gwHRiq/heJJw
hmUeX0IZnMKsGhbo1jk7J6Vk0o0zFnkmCI0ynUZQ9oYOacQPYhyPuY3rnWRbHzR+VtF/BrJNzTRW
hhjZq1ET0MVtjB14GeUSEomiukONVzkcU55FhpaLlgybiWQeqQtmHNYolK0cuiViBBOVzCMFJDNX
DGNMN0UleI7omNBn9QZgW6PioarVXkoUoiT47MdVcjaWs5LCrVB1CuCz/cC5VGyJBIx5HyG8KEUj
hRniuskEaqG9NAoQuOR2Eewi4ewsYLpR/dpIZW9QvLTfRN59EspwhOFcmP2CYeSmZe5rE/8AQxyb
+ExYwryyA43Zi00fwiUwnPgSUwsjhN3Im0uDF1KoQ5zKKNTyFdjK3rZHr4ySEPWbyNWZyyDO2xjg
RT9FkKxLJZFFiZs0gpGICTFHughhirk0sCmarUKCJiLdul2OqPJ3B/6Yvx4KU1URvF7MC3fYQ4wu
+R0m9iZG1Kr1PJcFTzm2KtC8ENtccB6Xd2x6YPQyhSKkNqZQj4guhRhe747sYhH3+ciZikJ2xA1x
mjQJSYTkqnHsJt0VD22PEVZNKDhCaArURD+TyuoYQqDTgOujW878bycfBvItCYLmTHxZwXwmRKL4
QchZY8SpTIRWMmQRLPxF2JjbKbFsosnJyOJ/Gx7GaKcFwb+E4xunWCFg8iVF8NfGzZwUgv0Gs1n+
g8p2Y+xN8j0MS0PoutdDOy8hCc1E1gc4TrbRzZkoZCxujis6+0Jr/DFBWFTDHWBDX3hyhk5PYuya
yFpMo9GYqyEo0T4tY2aG3TgkGDyEy+imYRHvtDLXfIxOzCX0EjQiWJSzTIC8ionrDfMVonyLsuJd
Y8vNMXKbeCtF9D6gVRk1B5Q/wTmW/LHNm6vgxT6MPB5RQyeB1NX5Eq0Q3FtowSZ/R4a9gZE1p8DT
s6J0vHKJ/wBArzIfCfmDnJKPTuDJKq4R+1QeXwfkciMjobEoQxHTGNkNXYl0TmG5Fpq6tiOmn5HV
p/piswtj2Y4IvzvCE+HXwP0h+jFtgXU7PkTFkYjw7hPYl10ZGp+Bhe8+R9mzmw2kKaLmC1pj5pSb
do8GaIGTwL7tEMjSXgyHZkjXswTyFet8i1DaWqFtxM+mxDnb7ULINehYlfYXSnARVUpwyOCJDbwn
Y2bExsXJ5ZYGXBMVhFJo9GwBD3HZcoFRiadlbaJsKdpi2zqiewa0qKiqkuWYTp9jJNuxYTtrkmyn
oZeKE0sZqGZOLus5sMriIpKU8/sGg1RRZjyzBn9HOZyZuZeQ4YKzZ96HtrbSuRXs20nyRq+hMxAv
Yj2NSZCrdengvz3MfJsnozTT8IaH37LfjMeB5n9GM3yR08+qPT6BTNnszg90JdF4YvXnbDGSDXK1
4K6Ry2zwwBMZMh3pke4MfprG9vQzTYEwkJ808oMrLTf5H9nAl0OiyxtvtsaksE0Pg/Q2u4279sNT
rRswyK1kyLFHoDJsjYs1Mn2mY5v+zz5I8vqxuJOKMIjbZbIS7H1LTXZhkWqLAZcDBJLZ+CYsfYLf
HgMjRGeQHZkxfgkIDOqGzYm1wXNX5FGF0EMGtkwNOid5GPQYUQ1T0H8WfFHnA02RwnxRkrMOTg0/
jRRrBsfsQjYo+ekVH+GnmkhdE3r0QyyIyTEa2IZzuq+x88OI0VMynBlP9BcchmYNkMTolG6xZ3ut
C2pXCFZCBt69DmyNwNFNvhsmCO/MjoqCWxkhT1UU6ajFP4xaXIrIqxFbntib2cgxiR8CdA/AwJtD
FfHYj/mi3AJK7VyPxkPx1C4mWxIlbzoY7ChsUroQ/wCEcZqvoSbOyHFVC2FjEbYhzVIxMnjLE5jd
wMYzRj0YGcgKoL1/wKqh9CtW+ygS/oWt4Rey0jurS6Gun4D2t2IbeZyjIaeh6aq4RlWsHTcJ4EtY
kkcV/wAjHB6Ep5H4FqH4UZ+AmTr6K3/Ix6UCJLkr+RXb+gm5DuS6FJbMTSGign2Nx/DjZkKXjIrD
D1fBw0vBvUWvlimFkzPIcOTC42W1Qww3Q1skxgbzdOCrOPQjLe+yjGfgJXGSqwWXr4Dpox4wM7XA
zUfiNiDJNOIs9HjIk4Vdn6cBPMvvImxSvo5DC+EEhg6bQmsGJoYcRRjYugr6+AjAx23gch/YY1j+
hBZYbuoKk+JjKidwNLNVbG2GWN8p0fAVTrwPaBAvCNigi2p5MOvkiro3Idw0DVKx/hV2Nwh7Rtl9
wTFz8L0ZmPsPoZqmK+zJC9yNbTScPBaV6QQYFyM34Qkv4DL0NeEsmcbL2XoXJo/0hLGxNKtZFMWm
QxjkHMnOn9Ckky6DOKekLOZrdFr1E4cqrI5Gk26mES2U0MwhQMTdjW9TSGu/m29i2ZBdpvpDHKfs
RCNjGvT0J7J5SKBTYg1pQMD+kSwT0ltrY7kximIIsTSnyfZ8IxBDjTMJF6HrsRHkTgtDD9iwytD3
sRTkfxwOl6ZwP4YkZDUNFvytC18J+PmPsTs/ULXkYsiWiCiR2LQwxeRX18hEo30IxRtBb458CIhA
b9IPB4oCXRDkqJSe6E1GOmGF0ISK0tBYabbGfYyYkyITOsG/ZBQPJSjbphC4E1dFsxJk6/glJIhG
HY1TyxTZrY6y8kiBsWscaeQ7MQWmxuWyzTqHBrEFh2ZGEEtChFUQ6XApLCE5EmdHGVwUGnGiqUMb
YPwY2UY9yZDBVPoalASmto8l6XCEbKjEFjZmKy9IlWPw0aCL6MDoqyuBxRbXRhhWiryMjECaGBVd
gsZr4QgVJJCeTYbEnOoLtHWKKiMaDDyGMGTVVG8mqbGGhhjkVBmYEKv6OYV/h7TgwtORxYHugeyn
AU39BSxYvweBLSVVhIbv6Ht/xOWl0Z7vzBqdbfg+tTBJ4VEM1zSwJamD2PSEsUc9FihJeTIAmM6X
Dagno3ePwYtU6g9Yq+Cw/UG/rNgJ9m7b2QxRJfodna+hifboRfNpqFprgmmJ4ErD8B8EMRFlsmVO
B12t4Fm7yRnE/Qgzw+jlfkVGd8DkH2g5PIghjPI/BeKkuhqMOi8iDi9jaUZ5pDcGKlb7LbgWYQke
ytj5FXYRC5H5N6VlBbYjyG7IP0ZX0mKe/wATKdIWERtTZBZ9jrSkypKhjZPsOZJOzPYvuorEMwqN
X2rgWlrnZCRNv0KPXB/WFZ8EmRKiZEFVPYH0ZJinQiDf6CIqaNg0gNwQi78og1aia4goJKxJz5hQ
adS0mh5rCEv/ACPx3pMLIngU0ZpeAQwinhMJiTbZopy6ukXzmyS4JQM14CaLDPoM+o5DakOOQyC+
sx9QdVWNkIFw4g1lg7JVJbER3dIorrFSFQLZ9SiSmshb9m3fggJpwYPHnUdzRMC3zulBAZNsit6M
fp209Nscvd0jawcYVUsERTVKNKObpoU4CyZVLTOzJKHJTn4TIuR7NsbWjCcmh5OdfLXA2Wkzs3gm
SFUnwyxlJn4binytF8luxDEpQbznQuDHBo8QaMRRYQmrEDoLbZY+eCAMjimA/qduyUnpC8Dr+oLa
bgaYWxQ1yClMswRFWYY5izGDN2S4G4jSnI3j4HmmhqNXqhTpolJ77h5muoTYksFkFxgVJykyo95Y
HL5KDwIVtocXnsRjY/0c2tjH1eB5HnsTJ2GKoNl6hxrTDWokPlvxBJRfZ68iC7TyJBFqUMWiomTw
5+Ikp4HLiYfFV5cDb0W/RPhycSLNxgK3JUM24nzkQYL2LjgkTswlzO0VFtNCaJB2ta2P96JPXoy/
SHfuPdQ2SUhCQapWx1SDiSinRcS6FVtbDbSMkdLk1uMH2hlf4PaOeAv5m4glcL6GRKPwK8E8dFdj
OmgV1oeN+BsHbIh5Ks+KLpi0wLEH81lYHoyzDSJKJrgcsF90J9CwotfCZMPhi4CTx8tzWm/BBvax
HCnGRBLEuR4JocOmTA9peDMGRticUrQiyVY1okKbI8Q5r4zlvYNJI1D2mKm4XivRhjBk5KYJpU3R
M4W0H+WAipbyEHLeX0PLKl0wNjAl0hlM5hHbgLV7yM3yX/yQ3kVHKWYGKZbyPXrkaY2NQ7INkdHF
wNUUCtrg7F2bzJp+TUEzESsVsZZoVsDW0QrhFU57EtSeUFWI8MlDyysBGn0Jm7EhxXoyb3/kPbaD
/wCjY3bpZYpFxtWmV7N8jYsYvlvljRqaGVlcTYz1UlFcjqz7AiNFKCxZgcDnca3pxeKgk6ZRX1Sy
vIt2R0yRgIjXKEdMQoniDOsMLoWMh5fZUaOoYnVNg7G4yQzYS6EEhmiafYgahFHf5ChgWL+GSK1G
oFRpK+Q3q87DNzAUrec+NwdUsNLKC/8AJWuBHfwMZb8qY+xIG4XnZ2Hn2JQb0bm1MmN5Hn4gzgTK
P4ZILRTgwXGvi34pBD+II9CJDjacOdlzoZPDMryNZKKlCtgphlpTHX+okuEcTXBA1bNHOYSZXIhx
wCPZGHFu0TIZzgeiu2Q5h8jSs9HRq12YHYWoevhyGaPU+EQUECeBtF5H9TDJRKexUVnBlRgy5TBm
NOjFR1akz0PuMsxv1jG3vgpDwhnzDUiUfQlj0eGixWxsZgQecZNKEyc+FIpisDwbst2PdAlMZwZe
p8YdbyX5kuNvPI50XVXBNm0fmGI+QR+qOM4MWjiozifmF13FF2Qosqi5PBzCmIkeRtJJs8LByb07
wPppGNZXBEHoV94J3Ia0GOVdqNGUxJLQ4m3dYLBbNC8fGTB2feN/B0eSallDGRcEkZnyJqZ/18fy
Mp/IWx7Hm8s8jW0Zossug8mQ/uTIYt0NDlOBwFKwNn47GBd/CX5jM12r4mHZ4GR9oYxslVspvvyW
nByOwxR7eRiALqXYhRqDvPAnNhA4OQtm2hznAkJRQ0rlgfVHxYP9YId+Vv8ABq2k2OR5JIVSHeYO
HGZKxJdmFLsJHlO5l/5FEVsV3qFDanHGJRrAwvH/AAOGK02h2pryhnoVeWeBiEOSTWvw4ohPZFlK
JGbvT6HgDbVKPazPJYLDQsllQ3DKEjcsv4SKmAQEsbIUaaeGBUIlguDmgTEUq8IZlq4cfBHRybFs
0qNhKNjVmD2Ct8walMokMFy5DVOxKMz4GxaNfDUIRKdt6FCXBLzCOwSU5DmOCwm2QqJ/TNeAiunl
fZZVbRcmc2tt4bHafKF6U23LHqof4GgPCx/hxhPRDgj0FtkQRDk3GXYqQMRDbRkXD+NFFudRj1WH
4BDFbEElBQpROJqMcyFaPBGej6B/weBpCZOSDbHw2x4FKMJsTybOCEnxPimx2ePnf/4QzDT5wRYP
QxCFY3THbynk53DP0I1wxC1FUDzSOC1rjJTAVtawNVzot1sq1CpWjLlwg76sRQV34plSYk2OyWWs
FhtjWz8XC0P+G9I0YHZkbLkWAmNKT5GeeBd11ZRT2hEYZO1ClorSsccKGfng4FphrwIdaJDpZ5FX
xLVMlLQyXsPoMnNJRDUqMdWfLGrw5iG1Wt0ycn0ZuCUaMyaaZnJaLqaGCqN1jBSIsPHZjsPnnnBF
6Xodlk5QlqPgjGFeyDaCiTWBheU1sb7M7KCTevwNmK2aKLolDCXrQ2yfhDCqbCENAxk5GMUBOQN9
zP0TVFMbNIOciTalgcOXORSYrjrRSTuzYtKuB8aPLo/DCy6JvU/Z/eoKDZITLxPpMi3N1/BNfIjQ
qwLUGkuyzBfZkSDxFYPNfYi4LA96PInOfsw8OkLTV+BbpR67OyDBNGH6c0KxJpyzeJkwIfKWa9C/
0sLfuGtKQunIsEY5ujGTQTT0KwsEvHLOULim+Q4WULh0dF3ywPXJH4OCmvRG22wYFws+BHaJmr/w
arHY2JB6HY0rD8kIXYdFYaqLGR/9EqbSyiE6FDmr4CvvFAt1RueBTA6gzKJazsclwKyoXvkSxOv0
fLs9ORyG/wAjJU/oSWn6Fwp3lgqPLaMQypYHoe5YnIx2fAmhddhzPu56Kpo6mQlYnLekI5pxoka1
2IaC5k+qq3OyNMrTSMDew7G7JhjsSzBGssCiw7DjpWEwoN7/AESNCX/iFzwV0JEOSN8GMSy3mOaC
ZLjgX0YXgT36Ri7BOB6wR/2xMcRyH5tgTRbhU7NO3e0UEUp0LDnioNRia1Uz/RxUqu5n3bLkgN6D
2XgeRglaROCxU3ncGIoQQWj0MTFfP4IfaRqxC4y6+WyehHiUWI9xkWBQnAX1BNU5rj4IJ3jZG9lb
TGSPI0JGhlIQzvINfssY1rpwmqJQ9uwpwdJLSEBpMpsnQm9FluxsNFB5+NEe5gTUGvwVY8Q0FhfF
j0JYyaGWz8/C38KNgxCZMbFsaEUUe/nBt0aL2ZbE4Wj6DA+lIBjBM3A3pakvfx1GXvtCnQaJ6Pz0
KlAbuT4ZkyBgoLNUf50FrKh/owwjmx9Y2KiNiQeRpYNogwGmLehYDTE2GRrboE9nPkr/AOgz2yLr
4mmalXses4N8C9iBy/NFmZEEiBtr7yYgrIeF5MrW/ZZR18DbV4IPLoP+FPgexp2hHuP6ZEoKmt0x
cf5BNlP8HVjDh4vDJcl9sYVP0yi2MXhOkKbJk3gFNReiEf8ARnNtkhGdGtNNoradEWCS4ZZsDcIe
WT9jVO/QUNt+Fzmf+L6MTu9GuZHeljIe9QYpZyepMe8NQBjeuAgmfiGWsFtvzIyZnENkCkeCZ4Bl
KJ5H03bXY5NRxYRNiqY+iEzDuxo3lX1J7b2j6JTP90xkddR32LwfNFf+Ej4BgLafAvbPOizLfAzd
YovoGPKUTKAP2Goj+jYnqb8C/DdJk8Q+zfD8sQ2eCO9QpjfQUTXPJWv7W0baJyyaX9hZXdMNgle1
0T0/Q4XO2LuJlOmLC1+z8HWxY0LTDwDq1flnXNhEMAzkSJ1twp+8Mcj+Bk+mNkP2KlDSQ+yt2tt5
NO6RRAT35SIIg2a1yoPS2XrsVImKYvM2KdBDdKcio+lTXa7FWtsdXKZWp9Egv3D9OxWsCdCgqHOx
5G+pYT+0K8HkVfYjU1gbl/xieuuB40LYNq2XGEgJ8JGVQJ+Bshm2W1vU0V3X0KXZuRUlqSDz+Vfg
wo5JodsODLyYsMP6Lm8m13JZ8yNBT8OAezFFaGzktsFl75Lhc5Y+o5UEFiUfwpsOxnHPxLMbOTqa
HseCnr4aokZcjhGz7Hothv45OSYGjZSYNP8A/Gi6G0bJ8YIzPHxTYwDjyMsv4X3eTITk2NFRIitR
gVXyjMnIdkP0TTWLwXq/gS5lFYzYLL0SyG3NFhs0iccSlXlgc9DwPOD4Op+BqiVjgRILmGzRgLWY
lfiCNVmmpIQmiFNaKF5wUZzdH+G5pRe0LRgap34L2OF0KiVLNlA+iafhDH8O0ReM34MaSHF5oy1f
sTxEfoYXEV2KEohlI3gmmXod1DjS+4Ia0IPIIj/EJvwahdsWipgLXEmKgv5Ekt7mUwoj4XOCCipQ
a8R+idrjgfJ3TGtpsOtqv0IbBqSROGppkYYTRYK+0MSc9DzgSI8JPlmOlqiHVbfgSv8AAekt6OPT
hccCtv8AgPCYkXROxWNrPKFjXQKVIjEjKovKFgrlO5EYWjEh88mGOUQ3LBvlXk0qYhAy914RnGRe
2I/7oi4bPychmzaeHgYaENGaE+oWXlmAE5GSOJijDNl2GHs1FHcJmJ5KpcmIU8NK6FPG+RtXJjJS
XyN+no7n6Kt/Y1cYe0vwJVNBgWoj4jiRvyMMmvAfhX9Me1uNc2IatyQY5nITVBehJRzk6Q+wDPFq
iEzoFvWSFKJawojJGx4OfgrMH8L7E73hjzWCKs6T5ZgRF0iIy5BvXhQgXUKivIc5/wBSuXZMOeuv
QQsaKotHFYySSMsnNdj/AOzM0ZwntB6sfBTgSZPLEIC85vQpwG4tJfaBHFDtv+jOt9PAZeKYlocx
xWNj4tZxBvJkjF7F2GBeSHEMFMg2CwYVChDyRaLD2ItY2yhN9CZehPGRfD2aMF8VA0YnkdGTY2UE
NQtexv7N/C3BvBMkFk0UucD8lLRr418bNspcHQt5Of8A8Ujo4HE+R6G46H7MTb+BwAGKE2DwbsA3
4PM0m0VEnIluJNBtoyf4DbPLaICBIcTJ3Qu6lQZo11Fz2ll8lPWPkYsbD3yMG6UqIC2WFaRJvJUM
LYV7nBcCow4D1htvjiJESwSAWCZ3AUjGhdqISsU0GsuiaTRJCaohnBQZdPgdXW6sirAtXLIpNQmw
QZ2IW2PxqyDGcvAw650NuwZJLuIOirrngTNFQioyMkQIuuglyZHCpGDMjXRwsWUM4ioW3BF7TGxt
MaE0tpvPQuLTJlsMiiMXH4Breo+EeMajQm+DLSorOEjyuy2NIaN+xE9mZTeC4LAlckqYkNJS5pRx
ll9gM+9zB/YnjV/fhEXRqZ5O9SEhZWCIDnq2JY8LA5PWXjwYNq+B3G/ohh2kelkuEJPLaJyr6Q10
zLSoiTVfZQTu+oaLZFtUYyCSnIpgYDcaDWysjrQzVomspBl4qFyo/JpUIwnqYZEieCIQuM6giibQ
RNSRyYd7CL32gyFS+hURlmnZn4D2v2Q5KgLHV0EfiHBx1ReRahGE8JLzgckJPI1fE6GK+QPOiC1T
jLkwiRdcmSWpvGjBFInMayKzXQGB5YpmgQUrWEOSkiNJp4QTk4Yf9IqKPsZftxWjwlBkKKil61sg
nxJRYL+f9D2CtdFeehr3TagqXezVE8nci8j0S3DMIs8mvPgUrDxUuh75lZQ/+G4GQVXh9UT6hRlz
8Njdgxi4lfhUd2Hgu/q/4FSsxk4hr4SpgG8CzsdCtjXkbMWC8j4yKlDfwbMmjRTJQR4GGuDDHw0R
fgdfCfNQ2uBsWR5CMseRNQZoaZcipm/HEMEPJyJGQvRTZwUuhrPxDkXk4/8A2sc8GmFDPNsbcm2N
xHGPx8SXAIb9wWdFyzPi30OJHc8x2yKYKa3qZIiYgGwGUeZ8MENa1BbCK9lLrUMhuWroWV5OYnwj
6MjD4MeRGyXge68DdFILm1lQqD0xdmWPBI+hJwIx4BMXgK+ZGbrjGqsrguBrVgogWk3+K6wibFV8
mgj0pQasC9OsWmaPGS2FbRbo8+Qtlt5ohSRanHJEBvpmpPsTkmha+UQ7KFYGpRsc3f8ADIoqNGVP
wWs0Fax2G2J5CHvY2zqrgx24ODmC6pmMU4cCUZI6yJoa/tFneeUGPLRk6ecDlnngXUzyW2jHeMG0
Rr+SV4+w/wCEg0meeBkLyf2mHmZnRODs5Bs5upUek5SM1RjOj6B6t0JQ9tPXxDRFz8L1CkUnkrIj
oRlaCe+lKT0ifJCGznZerQpmhMUDTwNgmsCfiLLYbiSGZdmPUiTwPUugh1W2BBj2m5NmT99Bmyb5
H0ORikw2Ycoy6ZYr1nhqUCI5GSpnQ9Ar4yvwF6uYdV1Cntmcecg9S5RikN3gNE9Yb4F3NVaEa4c8
jopwE39jAKWdjf8AwOHKuX2Y+xmsnj+iEFoHERpgYcBTuToib1GLhpTGJcQ44lpbNPkMdqkU8UMS
bD2+xk68Jf4DTEElsaVcCaXsq7GjMbFstn3F0L/6Dr0OoeDdgeNENzlHR/uX/C1tyUFI0nf8FJM7
dMHDERTYbb9ETGHwIwML+np8MjZkmzTpkO/OymwzGwJWT4wQ5/8AwFsgzgvxmjf18xitLkRpjonk
WRiG8CwX5Z0NZNMjgT+Z8MWT8NYQ3ZvQSx/oqIQhMC3od21GhOMeXknGpoQuoOUDB2UjE9ZJmh0O
XlgjM5cF6YghQrzORSbw2NxgdFO9jIkuWhLfxx8K2WoSVIiKMQncDYQ8Z/8AY5k6HzBWNvvOGR3V
0OSjg1stWM5r434KakPYyzcdebUdYyN4hsMZdcD4eUKrxsxjWPI8DHtiJ6HZjokXBq1HviOY6djJ
DBFyPIagFwElLSjwmJxsZoonjJRNCVccWeytvSEYXgjfEFccw1EZTihdUCxpg+Qy0N5NsMsTYhq0
RVOhr2mjthXQyTgfXjNuDHiSh+QjglNujAonCtTg6Ce2M46WRZl5eRDxc4MRNUYzSU8tQMOwyYop
XdnToXexWBZhpJIxFLyLVYKKTvsQsQD1oOWSGeMEIpLWBXP1Gkao0VUUrbE1yl7ErNCEn2Tb2wq1
/wDqNY8tITVwyQoy0VPdII5MnIpFEuIJ4wiZlbnuw5HMbPJ8Et9UhAatBqzOoSjDtolexVC/0HXG
xumYKH4pD6FBFTDA3MoMrKuCrKvsLq/+I3AlN6L1rDLtmips1uRJq8g/ezh0MWKDVYjkIohdVJoh
vPNqZpK8vko9WIxtiUkjENYuzECaAwSTjKtSHlPGrrHk1pIhhUfB+B4ZSNE22wvAbMtFRpWi9F5o
ActLDJDImdmTTsxylVlfYwmSy4PlqYmmN262cDas003wNkk8jFM9F0LENYGZRcDUE8DD8BiNmPjR
z8NNjd+LkxyX44KTJDKXwxqHkrH/AEdG9DfwyglHj4GozASkEOkXKIYh5NC18PKESjdC+OTXwmPQ
sjXy2JV/FnxtnjXxni4hG/MKMWyNAltrdQxJ/YyuiD8si7iDbnA5KizlaX92NDgjZ+xAKaTyXeME
YtB6HBCt3URzoqQpmMHFt5fwfJ3S5H8WwyckLkWeMjTArmnUhGx+xMi+hnWBtkvvRqZ1Yg1zw9pj
GlucCiQNveY1ANR5MHpTVLDGPRAnG0xuo8CnNnY95hiyqCNc3iEd/lFCDx2PDvpMacYFRfqM5AYr
IujjdNqiEfyRQJXaZvlT7L4TN+ikVWOyBrKLlX2UTb9liZeIQyjySb9QsmkR0hK7XyRhwPX4IVat
gxqaQoGv2UzyOi/L3Ro4Rz6uYyCaN9NmTE8sfF9iUinTtIwM+mxeL0GRMUwlyb9j1KMSk20dooSm
34Kmp9Ddt5bHiIm2H0i0vAv0UuGMbezIIpTFqUSci0kN6aYzMUE2hdTuPsUVSbPKQBM/qhllx2Te
H7FNBMxU2d4Jin2M8N7O0ChtqPxsBGbRvyQSB8cqEWE0w0VdElwxbQhjbbbPorjkfK6i46HLkwvo
2he1ccUjXehSRaZbH2AJrfLZReokt1CQdJeBbX7qFM88A6X11sbTso8J8haUA74D6EkHlBzLZulj
UpycYHuKCKe8Deh+FxRkBs/w/YzfhC6cMVHi72yGLOdcD81d44GRbc0x8tt2KoXuCf2mDHwvKQdF
2WK6+hoeky3gjCcMhEsjPkbPBNjY1G0vMIe85scRc1WhSOyGPE51K8FiEHR6L3p4exFg53adjLJM
lilcMW3wyskFSfaFakn0y+CR3ez/AGOIpdA3YejbOBCnI8MifwxZJkvgsG/jQ2SGn8PRmNGrIXBT
In2THw2U5+K6Tko8srRticHwGkbOe/jSOimiwRfhVmkIuBM/w3nUHoYvhIjNnAlTPwskGqyRv/yK
aIYKWvRlku/icuguDQtC/YxB2S/YK3mAlGxwjEqR9lsT+xQ85xXSFAhng8H8KUcngy93tl4CZyb/
AA4K+EKyVmslolDbJ646ELaPTGs9gOZ8P4KMgXwxvxgQ12mR1XfYs4aVr7BbNDzwGYG7UEtvN5GY
N/Y/I23aEMG/JmNfljZDIzJ9BPOnsyFpqFpD7Lxsn4pnC55Ih4faNNMDrN9hW7RJzT8GddDbIWLA
xbJiL8WPJg0qhPA/EMhTfs9p8Ykjbkl0ZMNcUUFGSxy7IFgh9VGi/LgaMmcFGuRim7jmiq5G9CYl
hNo9A1q76F2/YjkfWNG+vCDhsnfQrAo8uirySBDEuqxyhfYyjgVcIcFghWMqYkmoYmI4YlZyYja1
DF1rQ2ajVQJzdXxo4Ui2D3KJPsRpJjO0xeEsbqhtq1hpBWygMlSO7bWMdjFzhD1ROuETG2EKUJ0J
YA8FVff0W9X6FACi10oymVeB8/gM+j6RlSL6LyE8EFZY0cGe4O0fA541lDdOcGUxuWi1XvVF2eZF
Rp0atCd/CTBQwtl3Jbw0fYQmdiFsvKLGVj86Q+7gRvBhsnIcwxQp6YGx0kbYGMMmITODmmUp4+HF
pGLvRXoe4iQR6MaZU3SNvrIYiQpZIryMmYiJZIf8HidDfRlocRg8loiZH+DkkY3SGwxa/gvZPJRM
4D2USfHgtKtfEqEQwaLQw0mjAxPsRX9CWTgwvw8iCL4RoevlCcjYtfF+G2Jw2yfF0PkQuTQnv4RC
IEoTJmCFZIJr4lVxwnFsk8/kZ8KifqchUbIv4Xt1o2IzYSFNxZVFFYMrYJMRYJXh9kRoHFhBrqfC
qbVBko0JhiZvw1kYho0ohYPAQhSeDUC+h0qefRpTO6GkWwi4pURpdlwaYoxAQ44jhGBgokksEjV5
KVKCUBvan9FHX8FO4flR5M7wW0G7BR8ceDNpnDMTngh61wGNxWVyHhtxZRtlt57GlDEdQqKLAkpN
rAxm3wKG2qT8Cc4EcG0wTHPe8IayI1Rwofgv32DxojMkQ9mdIa7QxK/wJAq+hOXz0dY+h2YUNiso
RGTMxkWkyIctZlittMZLF5A1oJuU403xB13EOxRVSmn2JKOgnGmsYQhSXPAzIJHiyFSH2jcxz89F
g9tDq1kdZH9DDDwyDTXoTHbkzCl4ElOPQ2wyxZYST8Gy9rjjBlM5FaeDeBr4ZwDx2hzSDnIQ0iQz
bUjFC0a1BnEnFomxLwxGS+nxAkY40/SUa0bOQylZphoTSk0Mx+18bgkEy2tGNzo0eeGbWxiarMpD
HMEZxMiTY2tDjceh4Fq4Ymh8Wj8DAn1B3/wObFNH+2Bk4zSLCSQkWP0RZ4rwQs9IkiYEkt7hMT6e
Rd1jgGiM0xd5wiuK9eREqpQxQiDyUZ8Lg44qk40NITt2dCCinmofVpI8guka5R1UxTYwxtG8CKmu
uQbBwEOKDPiORDLbaCh46xT7AHiScSMHCN5hkFNGpoV06NY2hEXghyYpgJPimX8UuTA9kLPgkcDw
JZ+C5GVQ8mjfAtUXfxr4rwuPjwaG85GIio8a+F0cmhieUjYjRsbPySkEUas+ETIyYIRGDRaQnzwQ
mfj7KvgeR3s4B8Xk2FWhGjNUK/SA6p6eMDHurU5eTJZkQ/IwuDoMUaKO9QIW/CIxSeRMkF0FM5Yy
La154DaLLQbSWTZr4rF8LCyPWC/CpkZVGWRLI+LqoZ4h4hMlHIYsMsKpDUBqS0GfB0UF20LTPhfI
TZLstiE9kIEQHVBCW9sr5wIqZGrKz2HMLfQy0Sl0t22xcq6IVgW9iMmRlFKDBW0nxQSsJEMUuhSp
zSipoTaQuKj4EvTWUH1ptvoWvSpljwis4EInUIBkxs0kVfGyowI7tti4j3wSThsSlv8Ao9KNdjky
RelbV4GBYNYlnjTrQkgxSvhjJWA5NOHEeRwdjPA3Rpmae1HfsTT5FZO2YM5h8qo6yIKM9smH9Bj5
K6GhSnSI4fQp/SQvp++C+eQTjaM4LTY+G4lpTKBZxR8fjEPKG0CbbQ9z8RHUZYFvUwdROWSeh+eR
WRIw9s8O1C82nhIVrTmPo18IJfoDHhZR1j1abI4fI0bD6EhE+DQiMKfAwuqssRXFWR+DCAjoOMgK
wGFFGgiqOwSTMu+jgwcHlIN0WzNeBmoxEiDoXePiYiAN4vs8gNhPbUzIVPOU0ItzWeCmYs1CEOlz
KhvlnEaQ9pU5T5Jw6SQhqL9hzyRtM3oXqCNEivWZxln5gle02RNTY8kOo7EqJxUoweXSkZIL0GEY
qmW/IQzleGUY1SbRpzbREnQiiW4PZnpkyrseGLr4hCFpNDOfjMX5Xw02zkdKbQ6vitIQYlI0WCm2
LGQ3BulNifE5G4ZNDRhGxF+NmxOIbjKkPIxLswU38tsci7IZ+UNT4pkr/wDi/EEkJ5MhmUUosmhs
sX1Cf6KY5aZMNzk2OngMBZJeDN6lHzClCAni8CP0qIUV8i1Paol3saj4gxS9H/B1BukM8G5KJQkM
GjAjlGFlkWF4KaHglot+pqFsTllsQ24dEeB+tAxNZh0YYKx2U14uSMN0bOVIy8p7rg0pcn/93BFx
RBiLFZD2SRFcExWtjAZbMLHlDkzysWpKYKblD6dkWL1yJGNvgSldFvzSo10PSm0JdUWwQ5NMVTsq
JA8sJU1/8Qy+oMbLR4glqM8kHlF8QkvlYLw7SNYERh4RiQ30xVKz0M5M6YPuC/5MYJzu4ISlwSYi
rsMZtsQA8qXa4lyRk0PJLDGf/Dkf7zxCwTMcdZoXV0QakJvontSaFqxieLEsbTNUCavD498AfSAE
LaIg2/RFOQy90yfVX+i2WlkbHm14orkq1jAwbiPYlL4ERBKKysrMK6136JYJc0TNooiJkXLGnfGF
reHUKjjyoLTSmYCzxPYzcSvHJXci+xCYyjILekQBCxUHIFtjskchmDKZC9IhpnAK018DHePI7t4u
ejY72P8A0UbMvc/wbYAjcuRwcfkVsplJIyHOmIWxTduhjksIUOwjvBVPMao4jAo+FplZ9gztsM14
LSgkvwDohdqHBYU9jbF4Qu3Jiz0hg3Mkh3ey2j+WXojlWha9nlDKkc6tnOSsW2JROdCqTGVJaopO
UxDBMs+haXTcbYngxClyJUSCVD1jJEbFBE0OQyQ6a+dM4MvhEVKjBEZBvA8MpsJyJ9DGBvB/QneB
0yNGXHy2YOBDSLwaFnJdiyYpMMgxYY/jQ0IuSoZcnA9mGfnRSLL7JDaF214OFHhYG7+PBkL6gYgS
tShpNweeuIlBCRlneDQzQVvXqDE/YPjcplTIgbhmlXPvEtFwZbHyP/UNxuR8mJWOBr8+C+Hl01GL
gL0XEQivGBIS8DCQg1DYjc1DY4TNQlExkLwxJtEWE5QW/e58EcU2yne4reIeEBKPTf0xDeWVUcUB
mrfI2rNjORrXwX+UaRGRJFQ4g0xpZINLINAo4si0ibrGtpkqHB8V0y14FbJgz6r7G3AVW6Cky0iH
hvofXMcjjZMu8QKo7Bw+RhIW7G0xIeUx0fkcEfQn7wJVaZXmyo2noiYNPBLJpplkSgjugjvDS5G1
lLpmut4Na6M6YDI49iH6mrgeEb1gnUcrJnJNPhiJqWRwwsI7IsowqvQsK6qaB/02hH2b5nx3YMze
TOVJcIZ6Hh6LMm1ZC0bJZH6wmxxlZs148iEzSQYG5PiWilzouuFh0fryAa11SNIlUswc2UfTFTR5
zMNLTzsI7VN6F5yTXJYe3sSfdbZW2xZpsaYMyoZzUyQkiuvOBDL3IgmtPoQTmPoU6HoRUbnNK+xl
FtnSuZlETOxB47Yk35MapwR/SMBdMTIFyQ0VXyMwZ1sWcQrW2JxyItl406N8IILzJUUmasKwTpXs
9ZjhdZ4J2ZQPUdusiOucqMzLwRXmK2KbJDvKKSmJSWB8Udg6Gk+Z4QlToRLEI7k2TaFe3RVnBdef
BIuzZZHrn8iPgESiCOkuB+v+pns44IYG/gzs/okM/Gn8LPhdjUf/AOIaHNH8GoTBkJicY9s0ylob
M6E4zIvAxLlCRGzNHli4FGyNCWTIwPIxyYHJP0lXwzaEh/DGmjTEbGnfhIYvlojEq7waamUQxWOT
RllN+hMzLysD2ijrQoKtOmLKjhlqc+jEle+hKn8irLJ+zML9BkeVltuyhwHRNkhOh5cjlV0jfZJv
5Brryxio2n8WmLC+Kx6Fg2xlaMpUY7u6cEZHhwJTJnhj3PsfhYwye6C/RWLC4EGkkGsWV8F95USI
eBoZkyjXbdHtbyQ8Sf3scCbaY9pS7BW1eEVbee/i7efsUKX0ni0VRyEAumDpGUz5IktEZPLyhjhX
ocmbHurmtCYf5L0+heTUHpJGyxGCKg3SMflD9tDgYx7Bz66Q1izh1FvpYXBv2Q9uM3lHwTiHT0Jo
Bq6zsWmxRzBfQ3JFPk5HD+CXdGjafHYg2XlEugxlM0uov5wqL123BzRdWFhND0OuL/gwB5Q2E15N
eRKo9imT8kJPlshnCJ01Ka7ZrOXTHD2Vg8zkV25KuUyhIkw8h0vfJVz8gur2gMbaeUVKR2LCpWnD
Mr9UXkmw5lHMswv9DUTpBLsqOmUTFrVs3B7pfkUL/QSn/cVs/RVDoisUk+TaH/oj/AYZ4eh3lfev
hGD+ftRDXh/BDjO3kJrV6XxC5hR2IlG1hhrF6MlBfBPxjfEJ11u+RRSbPv8A1NtrhkCY59j9ZbNT
wLYV3lBGPg3QJyUkLpGV3Y2OISX2NgRSSUuiql0x+mCGlY/kvcl7E2U4bDS8LNiDu3bHIlGVHYxW
h+EPvpGTQhcIY57oOVn2KMr2mKp1Rsbtb38Nvg6YxZQl9HBwLApKMTwbIJh0sEl8Cyi/Lg3Dgfg0
zbINFYlkexYohtex5EoaZrJnYmQlz8LIXXwUMo30bIZhwaMr4hsRyW8DL/8Ahu5OReSU5+X8NlDb
omHozWMoyp3BuiwYfEpJE/ZO2TgZWbwFlE5BrWorVTkjQ9SdPsrOm+y6aYXOG0uBK2uxW6okMCsd
jG8AyJMlpZEEonwNOitMvhKclWhkIVOjoftjvGMbiOYtQuaEpHZauBsmntCJWuBU8EMZxrcHtNqP
ZGHifoM3OOsv4JJqZGJbDseSM15Gx/Ea03HUkHortjAvNBzU9/GQJnDQuAy9NdEPsMD+yKpxWUmk
XpDxcT/wGPDReujDNdkEVu2/AhvGeB7bvIik+4UqtG5CGKiG6YUlVMjUW24LFtwQ54xZwYhywxvf
wMcAxeqk4JS8/MOEkTTNCzC/hUtIsoZZrkhRhCFKcEm4G0HlB6eRdKuRUzlCI4hkrmjmhLDUP3GH
byJfTIyiu6XgpYwQ7m4LGB9JCjeLCwrEIeNisEpirXaPDCBuVR8hX/GNp58i2xuVBhanjDSNaEvA
9OQbEg5e5J3DQzzH0Z5HoMRY3xCnJfY0hvHAz17xi4YkGO8GDBxdYJ6YTi9AdI6eNvJGP2DbsjnK
M0FzoaoyaZkg2uxm9Z4Shn192xIUex8j4zyJnZCamnhwKUdSwKi7a2xBLTmKNRlHI9BqZG1GsGVg
5Hl+BxoS7CWTPwpv4c7wNKlhyYMziwHgGmJqDamqbXwyxkJUg0PCnyohtIbpwaTEhUpjZt5GsEwV
TQeS1CwLGOkpClbYtnpELGzSFlk8lUOSmx7FhmDqNjwym38ILHwWBPBcjoSbGIXkZYEuSj0OlN/K
wZMg/h4KdmXgSIaeSbj5sCYtj9THUQ7vAb9IuTEmcCwl6NIQyZLC5EFSaZqAaMByK08DEA2tGhi1
BBxhdDFISvksEky0QAQMXswNmyQgc2bbPyTTkTaQsYItRhTBzQpw8DG5aYarYtmkyXJJt4CJoxZg
hiJwxuFVgM4kbbTFpLQPOdCT6UF8ycE0Si1KMpRGCTybsE6+UhearsuVWdMWpLd8j4yzDKWEabOE
x6MxfZdnx7jIMuEbBbKiEIivQv0yUGkMCmZDB0RFY5Ie9kUJ2D9hjObZlj7DwjaHROyGiaDUn8iU
mgtuDQt1rK5EstT9HHYuunJKuWFK18JCl/uMWIfPwIPREIZocLIhmvQqjgdSmg8ZLKcTLY8a34PC
BHPboZGF6OZ/BYKfoZB4g/RKZJ3hod7bb5D5dsUjLXC1H4o7RroaEjs8hLMlSQ0czScizHVxPQ3F
FZEHc2FeUeTFIVYgV/Sg3v8AmIZfVoQSr8qHnk+BxA1ioW7K7t7EmjoSiip1Csdhk84pO2pWkBzf
W1ZOUZREtJRYkh4FVE2KOOcMS4O7wILmXwSCSZIliMRGuxFdL46Gwc2PY3yV5Fm6JCbLtGXRgGZc
eExDCqkzA0IcbcF8Nfip04PBPsbxPhRjxifwao1IFhjHHwLsZNico9m/ieSqFGvhpQi+BNULGvhs
pyX4pk2JCw2GxsdHV6Jn4LCEhB4WyoeiQvRyHsgsMaY20YGjY4+Fx8Nn4TAixENJ8Ki0Ib0bfGUv
jK+H8QsG8/DHGhp8nPAguxq50JWK1eyXJJ8hqCbUGJZGxK76ELSWBzpvgzzkOfwZJ4GvnykIap/C
J6hqbo0UaWqIWIjOBMjySEz8c/CG2c5EkmIbltfAStQPGE80SLEEofovNFgXa4YQqpMHEqxk+Ocj
yWGh7Uxkh8vCjy8mKChbehbnSFOtBdqgsLU1NvodLJjDwLREmiNRXC0DkxIkOjBgC22QlHw+gJl1
GNRR2EaqaEtU1PA9yMR3JaKag0bLEgguuZUZFBKRXkrMlVNjpDdNGqcHuJFom8ilow+S9mBLGjFf
+kK38RiWki/kaFWQz2hVhLVJxExIN5/6LQxl2xyXGNoUuOmCICmAtGgQtwjMNE4hUNO0VRJVTFMm
I9EHIJPgMvKCdtTMvsdszRcfS+GjNH9coal/6Zf/AHYMkpLSZwBfi7BSy0Ns+mCcOjhGc5HncY0a
YXcLBPVvCrgrk4W0R8aiGqO9Z+hfvW4zEnqlNGZ8x7Yw6dUPXihkw0G8ZJQgh2dIqEsdidI7hKrq
ZMEaOw8VONc2iGPuNcuUaRkKb2R8jJLkwNBsL5BIGZPBBCvCWjpV9TGuoa9CyUHmPhPAaITA2gkL
wJQnwePh+RKiXz8MJPsWPhG2NEiMvjSlManyVEGNlhsTBMohRqlJR5CRDNCNihZosPhWBomTQgqo
xkbEuzgecDgwVMX4ejY06Jw5KuBhaH9CiwZHRzDTEy/B/NyLY2PL+EmzRsnx/AlTTPQmGGehL6GS
XwFXgWOxgUtdGfLTFNbQ+mhwi9FSeBzdZGNQ0ajGcGFPvpMxWlrvA9pnYQthKDATbQ1pM/DYc+Ms
paIMXI872S/uggjS5HxLHYCxDKEuSneEIbj5oa9ZzComWbjiGNXgdbyEkVu1omNpgYYx0ORdzLzO
FAKWfgrFjIuSpBe3BrNwGOXIiqtMguhoVrJl0IwtyAECMe2zBtMdSEFJgvtIQI8PY8kjSEMlrH+U
wOEUC8tjUxp1mXJ/p48Qi80yNNWGX4otRzwRhV2jbSRck24pO8A7FafoqbjKCyPoh7p3wNDEdjsr
wVKWTLCpmjZ/AtI222LkaPryNpE8HI1scu9lJ3HZoeXHVT2IZ4VjN9qNMelMboxGwJGLXY+ymnsS
iS6Qybq0+OrGoRw2aF6onpnXStdlUM8McxZuMcC2llJIND2LOTPgXg5RBv3JVroOC1xgRoF4RMmp
59DL8DbEYY3PMI1/wzjcIkU8/wDAXFbQsIbjDWRoPIFtVTEkxyNV5a6M5dk6y4alwVHq4F7WEngt
VOkKKkvsGVFjAJSJ8EhRijcIelRMsTRUa7DJ209GgrqiM4hr8bbFC86yPBKvAQmfB4Hb8NY8iJ4G
zFuxC04g2e3wuEjwMplBh6R5HTZPnkfYssjA0cF0i0qZkTNlHAmbRDA5PhfKg0NI5LktNiSNFGhM
bRQ0W5PAmUfwPItNcGzgx8N//mCwMmficfC8C+KbJP8A8Ifv4TAsMCrNIPORyE4wqeHowokFFIdE
6GeEksk+eZs5egb/AGicvdJSE5uaFAZQy2EwHmlxRdbdDGRTJMHBiVtlGbSuDakq8mxm/EexUlyI
RhTREG6HowXDZjo4xpDrF4IpOKJBl6GUeCJU1oTkKNmUylsyqtFQ1D275DmMYpVMVBzq7IzgkMza
SZOHRNBRlIRvIhJ2ZYmuxYan4K5CQeqPQ66jEnhn4ICs1CJPZU1TE7BXBGUns5SM5xpDpQXBRK5M
GMcwm7psdR7CSMK7Rt4O3Rc9Cs3oxYvmDxmt1GOBJmPTLk3yPqSluoungUmlTaLwv4b+rulg0YzN
0NOUk6KCtzjYtUL6pjGN8iRlXgKTwThmIJJyKSOjNj1sxjpPDOwmyGLZc4p5gD0Iaa9sY2nkbdm8
TOkPwBTDemw02JHIrpRcObyLKdq8jwst10OhUqBXRPsKO0ZCeyuxYV7hrSecDnBcCTkR+hoJhnu9
GC1zkY5jtsjizR8jIqxVGYAMYTbHbB7vAq3HgTzaXSjVvzR8lzGngMPMNwwex+vRRweDKVH3SJLT
02YbW20Z4bbFXGnIuhhA0PE8M4Lqz2LCk4YbFHHMLpmsklyUSV4bHr8wmKKgsZpSlA2PE6TFinho
oORk1wyJILDXUf552mUQ8NjqGpGYIcmLiiDJBnQ1PRgqW9LBiwjE/hmDhfDoPQnQ09jGVGyOsWFB
72TJoeyfDSFkUbNZESBHSpIlQ6IxPs2bMjoMWnt8KVmackfw3DLBTISHgLgbwPDYs/LV4F8HomCi
x8PI6PBMFghbIb+OBrH/AOOBu/HgWCfPIJuxCxgwwMPLEKFhhbwZGx30ZEqmGuxY774P/daIrJ46
NuhFkX2SqSex7Egruk6YggRR2V2ZoqCJyns2NbG3fjoFRvHk0XKGoPRTY2JifV6E0y+2SlhXdGjf
IXIgq9XwJrMxlIH2R0Y4f2KvqGK4vgaAy0o6GmVXgeNqdlek6Y9q9mXa+4LjfcRK/k1koJN58lT4
ERFB2JOnJlAujRI0fwMJBOMimJhnLvkzh8RqXYw7wMZ7wdnWL0IrcWKTuI4ecGDA/JVOOj9QQisy
+hwPrX8WxyF+zOOCLJ8h9QDLK3Bav2wTxy+fikrSyeRNCbto/wBBDh/7HRtn2J8/NiKehZ7QEOPK
FdJ+C3J0rM4q9jybjJ8DvRrY6BKdntsW8HliZ/EGm/AQqGGyj+IuzDYF5HyW9iVEoyo6fTP1kiGK
O0xPel7D2UvTG3+gyBceBIqF02fncPaQ+iOEJ8iVa9hC1k3so3rIvRSrP2yoORX7o0iJP2Rz/qNm
px2NViovhMcwbAmw/gjL/IG7o55MsfBGl/Bpx+ImuzNcoI+hZo70U5PQ7bryUcVjF3KXRthnv4vF
Xk2WjZGJcvwhTcdeyGwn4czQo10zhvooVxzRobGImZz8EZK/AdSwdEHshctxMe8Egwxj0MaCNDwI
OhrAhahIaa2eA8GTkUhrJtkwNYIMMk5HhQzDEayRiQWiRkJ8Mo1DDyIayLTEQayPRmHByRT40JMc
c/C5psZGeSi3waKSmnxz8Ibb+MT4I5G6LBWcix8cFtJ8tM42XAkewvYSpDQziG4uzZDFhjo2gmLS
mJFllwcAVwcppsyj9jGWYmrcgX+R6AM//Acf8Tkp2aFYh9EwojQrpA/1QzFsQgxswYw3RjQjPBIY
tqlf6IrBJeBysQknokxCM38lFtRE2HQhgmuh4IZhExCTXRNlRDupAirctZSgoC1wQ3dE70fo7mOh
TbQ0l6B0FRUOCSJqMaGgx6TkbzqcJDUqg8mqaJCAkmd6FlyO2FRx3/Auvm5HWF6+DMfxojJSeS4C
MMdMSy/wwNpcD55TDcya0g8LscqLCodBskQHiVW9OCjQobBx94sjh5EGJEgqsK0kjhxyWQeUwqJK
cBEp9tGgU0xHFzgfI3nQsKjtdDaT6BnhRHiY07wM2DL7I5Q060c+Bm7ejMvQzmTF1wXOBlf+Rxqa
FKXgSGi6B5Sq3DJELLLpmJLwVNlkyexUqEJMouG3shlWkFVXK6grbui12EWr0MspklbCiR0GfFm+
jASc+D+f4wNN9Ismm0/5LuGDoQScF8sSY1Ajy289hi77EJl3lohuKLwbgo4/uMfDm9C+7Yy2Xa3g
KsiCC62hWs2x20fiCWLIpuLmh4qrKCkMTmiVmKCaXaRhEnFiEuNwJCaIVgTgYC7t9BV1GGo/7hYU
PyHliclwYhPwwdkNV4GOtDj4aOw3CPYxtD+Cqfj/APFjI8kaNh4JFkWsaY3REIJgTGkx4fw2xhDR
ko9CRlPscESsgvdHBo0n8N5GqzEsY3gtXfxDbGeijJg2hio4+Ec4+OB/C+KhYOXBMbPY/Ia+ptWy
z6E1bYq22azxgoPaPwIhrUYFQ02mkO7ojrip0I6IohsXUzT82kSQW9yh+C38NGKk+bTwPs5Ns5Mi
nwWznZyWIZOvSHgt5GyiQ3WNcfRHsgO7+A5nMsxDNWYr6Rilwo63Ap6thaUxkDBuOwSRyQKGmLoT
G2eCqcnhGocGfVHYNFxUWFJpVURtAzRL6FnkD6j8NIy7RCOnAk7Y/IQktEOFeSh+I0JsZaI8TyyQ
F3gec7zgzngIug30J5AyirVG6UIMzeI/ixRLLwT9rwux2w1a5Y7lgu2r4Xw6c5c0ZtpGuhovVSV8
CE1uXIaGJZ6E4NRmWoIjM1wMPSQZvofbP4HfqISJ5IRCeQpTsItp6wPYQyYLwI2S9FJiyX6XPJKj
DoUZSVkyI4TBiSvUMJ/gWjDgo0D0zYs7hs7ulBfPgjjyeg+E1eDXUuBY8D+BO5pkTqf0PfEZqOfB
moRdHEE4+1EUKV+CkzJ0zAxEbXGV9lSdlZQ3RLp3k9lylKFJPJdiONS8E4J1hU1qIQKY15Od0LWq
JCgk7I8HykhvqM9DnLPGSMkhZXBYSicwO9k2h45fyKs1s4U+Z/6YZW8rYoVWRI4JyMbpoL8qSKUW
hNjZkOxbR/QIesYEmGJMzpAfXrpEq3MOSONBVBsjZCnwamhi3A3k0osBsbA1mobwNF2NDhjU+FmJ
EK8//gSIjZG2ZI2GoQhuo5DkgmXIxtjM8FMQsDFvHxGBeCmNiyjgTzDTZRIeBMcCxkbG6LZLkx9j
efgkX6FsaE5IcfGz5tZq9Dk+LgXw8evhCy/lsU8SGlj4FaVkuJGjQppj0YzNTuEU2LQ9JjYgJxI2
zJBJUZR9xB3/AEQeUcgg1xLKq5M1+BEOmUzzP/BCJ4DWmhGttDQsKFMSP4sZvgS1xPhnPzF/pDx1
WMeI/GHAwW5G1YNp1dg1BNtDL2kKII186imemibWeTQx6S7KN4mBE72ZzlDGoadDJIMKBadliH5S
o+sji6bXTMuSTgh5VsYT7C4S4IFgWnrIVCQQpoUo2dCJE+kFeHfx2SENTQq9CoMxzZryhrcjpqv7
FSZbs4MF9CGmicie3Q73qKIEiC1DLAStZJI2F+hvTVcHAiDkgetjleOAhqfkc7KTMFdtD1T45a8j
182wQpv6vRm/yMRYTwZXofhjC+BLTTf/AAXBwK0JQNsQEyKipdSCZIBiMvWLRl0Ife08EYnMsHtq
N4li1kuLKpuiQyjk2mUkHsa8cjazkSEcSh6DizKGOvYyGFq+SdaqYMF7VrkfumsCrbmhNN11JPY1
z27fh05ytDKYiHZVG2G9LrpiBc/IaexdNTyMEMtg0zgmQo2jf0NTd5LSta10I4UNPI+l4PoYIebP
sclBo+RNOTBCOVOvLFIfSRhvxs7EvoEgT+hl1whVT+AUnEVm5HYX9AOwbsU2SuE5Nl5NWysTcEnw
RvaEGzI6vIhhrEwF4lJlmhjBG/HAwY+Kf4YxkTPgaZRrRGLCUSDhCDZIdu/g/wBGz+LNfDwP4Wex
7z8a+S+Bqr4WfHIfj4k+JXoeWJOjFolEuTksQhhdmWB4GyZFhCyZbIyw2SGyf/ksjcwNCw/hsSjL
wL4JtDGI0RPIjn2Y1ij2rsVptD4Dv5CeTqnxSCXpEZc/0JlmkrxsDmuBld6CYGmGPNmcCxtqJck9
Db0qf8CYbzCziOmQmR4ZskTNviUShBzgrz5/phScUdNqjV4FexXTTQZ+RjUbHC7o0XdA8YBDk50F
GHgX7LB3QHvwEI6iRengMeUSo2RW4wOqsMU6IUZEqcAHsXLQvbyDEaVUS4gwMEomN7CE3riGorwh
Vi1GUMY/X0hPmv0qTCZVkqEvYc+EX4vWg1YH9owzFrJFSYh0OCVDVGcBjSyti2UnwEtfB0eU8GVE
CuT5Mm24oidhFuF5En2ktdm8S2UZD+DfxBi4s0zbfOToQiE4u2bBsRoHLDR1LX8HhE6MOeXI1jhZ
QbB9urkbeAyXpKqU7DYk0rzgrdhclwsulL1xNR8qdjoM6H2SzCQi98vIoTDBucLJkd1J4CyEvUKN
X0b5ZhbwNFMrojI8B0eNwxXLegtwPFFPMUMLaQ/Mng0Js/8AAVDU0xeqT3QotySSHJozPsTTebnJ
wLVkXZYdngw1voQyjy1rsSdgvAcTRGJDmVPRBGN4DG/meAxlNWG8DrleL9iHn8hQcSd+WSurpMRs
tpPQ7Wtr5G6aMxCCWQlyRroU6Rvl4JgNYqMEk7k4Jr1inyLERlZEzHbwJNnpDnbCexjBSxb2RRLy
2Du9L4V2yQ5t5+INVQj8zGHx6DMchMdzY6iUoyy2zDgaKFjkbgjeRuMQ0fwwcEwLQRirRGSMYPDG
4sFNBImPgxsppHJDbYnB5yYIadGiEEFULyP4X0G4TOzgcL4raMDbAg1n42LA8sWzYZpmzRPjBpir
Qr+htNK5nIzTqFJD4Lu0YEPN5LEs20JWnIxHSHonO2bEWFgtLF+cn+w40RRXLSdQYsH9iNi3eSMU
a7JO5iDFE1ofL+xelNjeYd34wHnJejAqL9D2LKG5TYxNsGOAFQMFSVcG/A3ZIOUy/BKrwe0OpYmq
PpDESm0PaI4hOwzkwyZCgYALWDuLCexoeSoQ9bGS8H7YRfaQaE3wLqkN5ZKRz7oy9OODC1eGLKd7
Y3+FF2YJ0vBkbhOWS1f2bEF2xK3YvJ/SEXD3/AXmti5ZmUvKM882L/7B8WA4F0XzQmzcaknJnyb2
LKgbpnEvkmYU3ELMbuzg+4Y1tVNiElowmuCLRNjizeqTR8PDH1o4gGmcqjV2ZbeA4MzZ5Lja9hbV
5Owi63BkHND6y5GvBu4GSNIhd49XrKLq8QS62jIjKUtxnUAAs52yfZLWsxd/oV54XCHjoTyCO8uz
O00khQpYdCZt/Y2cW/RUfOaHRA/JVRBQPKgnadLJLbbMMkgIdPZxxB+Z2ExJhOCdZGmfSLCPDLGT
G9hiEcHoQWf60OzLTYVG9zNqPDI/d9CqtPhezJTyobomygaFciDwOZM9uEFM+PY5gVKt1wshawcJ
DZL1q1JcCc8nOyV+5sb0M66KmLZMKWiiF1PgyW7e2xaw+BCOxNcqvQ1byEmKzLMptmcOdaQgNN5Q
5XXhoYiRA+mRuuUex4cb3wawbGLMgmFsio2TjUZkZBskcgYSEHyKmGnY5cocE+B+DY5tqKr/ACXY
1H0ymLLFuRgHhiTRMlGLf/4OmLeBoLLKPR0GocobXwgtY2YhKy5EVMCpryLXxY+y1j4+FRUJjglI
uhnTgzQbx8Fv4XAtZ+GoNfGhG0dF+Hk4+FgyHkxYwJhFCnsWBFTYQkTH58ERjbEeA8iSthME+xjK
FkWGcvsDqVw4bL8pCm8FSOAd7L0MDg8slGjOvxaMyZkIPeCOmASwJjOmPWu3g0m9MYP7BkT/AGGs
Go2tGXNv2OZDCPXsWvLAu0sroXyxZWXyXA0+RoA9DyLRBUPTGyYymLqlPo2xoecp5MY+yMFsUd/Q
ctDMRgKr6MsS02lZOwmjy8oWptPPQkosLUsEa7+LjS41OBvb7otT/gXL2qGG8PoUG2Ps7cG3T2Nt
8nWAwNBwVsaya+h9z+xPVH+/EOmQPvsW0tM772PtUz18crBsHuoRE1iinX4K2HG4VxaH6KMSJnY2
sBsDao0SNqYryWhKviKaNjFzL0Mje2I5CHUdM5xeWRrNXspfAPiDmj0dn6UEJX/AKUo9XASNPZIU
7/Q/p0vQ8GW2zkDd0hkuS34DFpo6QktMrUc/AwlObKv8wykuGJTTNdnWYyypxFWBvDMBoxFeQm4K
pIJkVZGPSItYLbQooN7Q647vBgSRwpeBoaGWZo6yBvgZozIZPIXto101xsuk/wCDGpoc5hbDnEyJ
RuaLrtIWlVbgSTzNtJDjPGFLthyaEO6JmS16wVp6dCnGJ7QompDComm+i2dKbMFQbOH0Y7buZoXJ
yKKkvAYklzgY+BGkN5G/lO0cFhRD0YL4eGbJ8SD18qDfy2QbrHrBdi7+Ezb4YviMSEWP4X8FyU7+
EwcL42zPw0I+xGQ8fG/hL9jxiK+zJCaGkrvAkaZLDlEsWNREp2i8w8XJt4wM0pkZtoJYk5s1oNtV
0JFo42TAoHmSNVTXA67gMZdbg1kKCg3At0TJRs+Phllo4G7LgJ5FrFN1jyhUJKFDCdCISot5RzA/
Or2GWxYmAl+CswQ4TRSjJa6IhYDJLooeBxj+DLSz6K4G+RS3LCEJs5UErgdEa0WhMqjrGeUVVvBo
eFNEEqbMnj9Dg1/ImNkfwXkk9hswhNnBBHJsmMp+Dw6QdlDYyMRRSXkW024FAVNNIyQMtjIvAMRH
gUqF0NNLSy2Rqe3xM00bT2YG6hfleBYcCH/WdB90xG96abEuqtGUqOBaIsbCXYXA5tJrhFQhehB4
1IPVborgky6CKFBB/BKhuDBU0EjEypElcCOattxGuhtGTVjS5XcHtlXozW0T2SqFM/6YyavEFOVQ
w89i5ZQoUhPKDDm0X4d5hSJPwh+dITjwKY2zLwKkKqkZTtiErasrE++TOIvQ6QYuhiLU5BYTXEhj
0eJML+ZgJuXBQ4iDC68wdPq4HkCnbSmh1mxwxkw3d/Apt+SHd8di9L9DStfgS6T6EnxsDIg3j2EH
wD5FeXoxQ6rApWXlgR7Z1gTuqfBajlrGjNXkiMbTlUPEqG4h9d1WbGaFzLnApGJWONBl9OWMQbC4
Qm5eUNTBb4NSMuiEopSUKomJr+CY8NBzrbU2JpsU0EObpDnPDWxOaqvJmgFkMAsdVCmLQvFRWAmT
QdW8HENxS8NZYhnUafAoyMxisZ2hXns1VSF7NqFyP4JXBM1hUxKKkfEonUMNRfB0UN3Y5+UYIsGk
LQjIwRhkeWI0xCG3x/SExk0zYeci0Z7Gqx9aEQ0L+FX38kZLwL5XJbg5H88ix8rRXB4tF8bOwzmM
GRF5pq7F0Dg+Sb6xtDJbiNJwYVYUJjBYaXAtG4Lc4hufT4Sm2kTfgS6nY3FH1MzMNkxWQWpaTFyN
/gwHuBIiejK+FmHItT9spV0oKDe5rNge8o8bIQh5Md/PLGNwPoq+EZly0+hOOkFqHe4UQuCi/wBE
Zu3wLaa0I7doY0qYK9EVmYL3aUHFYnpIXEVs5GdciOk3pp1voYYCeCYY90l8fEosdk14FJ3GMXAg
TIZoyFrcXBnEcDtLKkha1u4Y1P8ACUJXozboY4uPGBidyylyOPKXk0KJDZT6GNQYeG9HN9TyfsP8
+Ki+az4HAmkZyA+DpEgzC37YuTsY2qMc+BVytaMzAy+BQNdzBFeEIKqp1BRVxCxwgoSDG8JacFZp
fTRANPRn0ifNhztAwKmEjNNGxLp6Yq/DYyEo0ZExnNM+y0MLga4WsPAZP6AydlhEZCp0nHJjB/AM
A7WRPEFsacPjCmtMwgoKMtfAxYRBWWco83JFU4pOvixC+Iqo0JSjWScFYqlFWOQlxgYkHpohWPVh
pFHCSroYlJKfQbPwXsRlaU7OI7XgIcm8KQRPtx9jBFawdcZR5mlVN6EBmZUJuFdPwR5AYlGLZGcN
gThjx/zRCVkFSexZMV86OzvEFccTycTfNMIjMNcCwo85rganBLOCRiDYdjsTc8eT8Dz1mUZdomqN
o1kKiHsZMs3PN/DGOMGfwIuxWsCLUp5G4jYeRW1xH27Iek1T6RmM4MFMfpAwtqE3HAHnvlhcaMWN
5FufCNjrHyNRFg8iJkRCdlFob0eh7HlmhM2zbYnkeHr4c4Lgb/SaG8CexR8XI8i9F40XBIN/C50c
jMjgTEc/EGlj4nxySM9izYsfAvBVyNxoRvBw3f8ARkmhpHCzJT2GVLkWyuXo/mM0TAsHgW/fARn5
fNsojmscFoBo+2MEdNjWJS5l1Uxo/Z9mBSkULMjbZwViwmjV+TFl0vgn5IbHEN2EJRN/Q6PGqh7S
EjqG3skNtPZFEy0se2M8ETPfSJjERhiTrFjcWRkk64nJPTMflmCpE7JWdDfBDskjgrZUbBFmqscG
JvtJhNC9PpsbFR9BZK4Q1zLHkzblDiER2mMZYgypZHx8GtAad62JBB+x5SqG3lGa8EiCJxyJ7w58
hxUhrYqALcHba3kPbyGUcy0xBsqbP8T+GlYKZMDLZUuWMUBSi5Mxlkf1DBD7Y4eCU6fAQbplPgns
ZlCuiCOYGvcL/oRhzEMBG2mwMXEbgvPA1RbmVS4QtQon2NRcJCT2f8F+HiB3/CJZYagwyDUV/SC3
DKICC+9JGsfHZpGfyYl4wEyNyKjyuMxXVxJsTrGeG40jMul4Y1TRSij4bHprH9LIyazsCI25OB+m
3WTkSLCNo0VWx7xWVtceBpFaJuDxKKOnDyRuGtP8osz01R/S/wAESf8A2TyFt/4VpvIpG2QWZqt4
Q153/wAHU8rPY8wLXkdnERjIanB6MTbmji6VoQ5wDSNXgY+eLOkNyNriGeIcjDUkxIa3GEPzKiM1
/wDATlp5E7WEqczHNfgyteWEzCchu0Myhw6Vb2T1FrKIHdJf6R328vLorHmo9YNyDRBfIt8xFIIF
QxHMp56EH2NteyXTWehLOYGhzZnJTGRT4NEYDGGcIMGPqcEaU6dWKcl+Cx8Ia2OqRrAyVk8j6DII
WxponkmRpQ4GjJWLFMnRhKMg18LKeiBZORkqMSfDkwex/GOTT+UqaZx8pB5g8FE78XBkyjOcayrx
TKiZliHs4mjYls3FLGweRYSwJIXJhxFBRJo0CtMlC46qLvjmVJwPSueeBU65HGM3q3QlOgjjU0cY
rZHEZlM3W80b4DUcEMH8CZnA8DzkbpuNdaRWCmUiaFfAhVno6aNOXqllZJmygjcFYXlyXPFEmosC
obHk43NRRNApgbypiomiSEWJotMJd/FoRn+wRbiGCNJi8kJXktvUt2sMC2VH1ZBEdfg6EyiENBCb
MO4vJxEGVZaRqG0uBmxvoWCumxpwi2mZoqGUlXDJFr5LeZcEBEcvxEameRNbLK2IIpeSIQ+PQ7hD
KYHswlW00TxIED3BaKl4Ksa4kQ1VMo/7kLdO8DUjQ+x/jeNmcmXY1lNlJ8kAeWSGHCCW1iihuBgk
lRGXHyvibtHfPou+noxqxXS4C3KWR7PSE3BgaFNZKEdnAVWaelFHbTOX6hw21XJwdX/hxhTliFtI
IxSqq8n2HseEajAcWTDfErT4Es5k8ofybG0ESrX0NHb0GyTzpgAGRm5p4HSh4tiblcndl7Du6Ix5
5aIxOoJc+idpQn8MSfME407NGWE6Gq8jfaxyh5/59jlM4eStvGiQ6fQvLv0MaZ5Mp44KFOReA3TB
UotsZxxALKOkXZRiwV6FKaNUbpd2lliCiCV2eenYpvmT4nI1uSrICTvsEphKeESR14NWZHqg6JPm
Rg+bKN8wsUNkXy7FrfMu2X4nD4Up7Rj/AAJ5m6N9xVhOG6ZeIuoZ5lclYhqIWpoTWl1BcSLcEKV8
poZssGwU8AnZuXgb5h2yZJy7bSMs0y6Fl2Bevs1/5PwP8waNIyymNOsNOEJNRaZQry8Ec8B5GtY2
8D9AbpLkj+JR4GzZsZOoaGf0PRz8MozGLY/httmbk0Qdnxk38EyXJaImPBaIYMeTPI/ByhvIrR/E
z8FNfA8HlfGiX4f9F4+EQSz4/wDwzOBY+yUP4eRmfkSBJbHT6MiW30FA6Sl5GbAxRsQIjWMN72uR
Gk1S4GlYwECwu9r4G5t4CLCyC2+3XgXwtp6LBzvAx/DYZ6a+KFxRyK4FX8JZPU3rNSGL9bRC+Qhy
OlyyHD1+TMjwDkdXKGsnLwZZ18xnl13k3CPoYEhuGvgpQUoj0h0qfsbpvIS0cMGXm3wn2JjKryLE
ia/42xZ/YIXW9wZ2M760fFEeRjusgwbb1n98yGbNOhBhxh2PQsj9kLnJFdhkYyoxUynb2jA6PoUG
htGFO72YB1RAcHwLTtoBEmR2atu8CRq3toxSOmasRdoT6XY3I3yPsWKkOWxW4kxGfE8H6xaxDmD9
kv8AsJZLwxSm8Ic9FNOoXn81HlUnpjOykG9Fe8ummur2mM9RE33CKOc5HyE9Dc39oYZtVMKU9IsK
XwXReShS+yujT2Mq9jkT+G2cugzsh8BW8oWUNfKLkV4WVQ+1EQunwQ7lnKeDXJn0VqcGJR1R/J4V
Qk96iMOPGaM5XpDGuzmPBT85Gd5xW0Yt10mQRkNKq+S9cGgFaSEoXyHQKVIZaaMJiFXk+xmGT+Bs
v1E3w8t6Y7JRiQ9PwMNJ9jxnJRNj/TeUl3TPDTOejAGP8L2OzuxhMlSDwepjndpNjQi6pD4g3OVy
eiVMU3uFt4GvwYa4LaL2DzsvDQzMbD6VlGduWy4Rx2TDOroxOHSRGhZcnhCypPWi36EUE0vZWjf6
P/wWS5QXvRKMOaxRgo3sYdezV/TFwN5HKqDZ7etlH9cZz0rKPJipt/RjJFElOBLtue/gR3wPJobK
kbHs4+KJ0zPi5sHlGhgbEySMuPglWWNUnxsTuENDE8HLGzI17GoYexrJMwaqfB5whKEqwWextt/G
fjXJwLByWlhc0o8swfk5PA3xwRHGh2YEsZNuIaVpV4Qs9jJItCKi2WaF0ZME5mwEttw6m/JfYldC
GjQ6aycUmPovuYXaGsxYH11B4185JMHqGZByZILsWcMmfjcpPPwNVcuDWi6hbWsh8kg8tZJ+ZFjm
F1GfZEYsRaizMbeB12bwcOyMwpBSfcQF6slhC9KTZbcjm5RJf8yTQxavJ7nwzUpx9GVSX4ObjCH3
CYkrstGAg+hq2XFTvDWBqWGg0FnaEeYVk/gU1xGfsKZB+CoiJYglXg4KDRHOR3EX0Ntw3YJ5E+gh
6/geWbtizS9iwaQzciFxDowOWkrHIIO2NwSdJyTMnSrohmjCvoWbtu0QYKykheCL4mXSFy8KrFoM
1a5aCTWdIMbcLg/QI8t+xbewN7E/yJsjHoy81Cd8O+irImZhOCKzoP7Xh9C+BtnoGiQgqF7EbDXA
ZwJcJ+ildWhDhGOw9CU/iYt405o0z9rF82I5y3ghTLbgkLVzBBULfaGt3GJnjWS7Yz2D0M+B7Di5
Sa/SGOV6ElSJzTt+BpUpdmVP7GPC4wLUUqmFPbWE7NmcfsCHDvSG5svAottkLbpbGzd+Ddsoumv0
R6DnrbpIQhoxW2JkpDKQkK7X2Mw3wYbbZEKUbh31K48Es8GkY2sTyhPQlmsCXUtMcCWRBixNQIQl
yhRVSw9Eq9a0MV2Fehp53obYa6Ma4fIkXp5QVQmoMLBbUQpw1edQn9WEVkR7HtGzI6P5G8CB5d+R
uDZPhkDY9GC+E7G2KsbwyhMysDCWDbEPYxZOhvJPhLz8NfEQ2KC0aCyydjYk/r4uRZFjBIzCGLI9
HBMDdRS06Mshwvlj4o6RyjbAgansemEIngaLg5M3oMtpqm8hZEGuEHuWSdsECqojAB7zwZxMUTZl
VxlDCqNTRbZdj0qYwXHRQow0YtoiCHCk5p/AWz4KNDKEzSvfxLUJkbhnmmg7FEfsW/6SGsdvsR1z
5FZpThCrFCgsYOoaESEuVCiI/AJSJP0KUVSsCciYSGdBfRmVG1Zs1MGKEbJ+X4ItLCCOKPKVemJa
LvYOZDiiumXqiCv8DPDX0YC16Etw4RX1jYXXaD45yQVWhoemOV6Y5v0MBph6FhEpVFWb6EgK260s
Ilrr2YEyFSdUaRIIvqyI1SWTDONCsI4jGdslsjZd1fo3BN0Y1CYSMEl5m8L2QppZI44GsjQ6rM+h
fhuzMse2KOv0I3fI3eRlIOUfCOLnUeDDFvRieZYomz9HIwJ/BhmSZTw8six6gux9eRghE7GWJfA1
jFwKyrEigbo0QLWwtWjyoMvE14Q1PtIlERfRKduEUpJIXCShCFXmJ+wJ4I8ilMEa54eSgW0XesuE
KPS17FLLVXWjJ/IyKKpr1bMRcm/CEJmmE0MSFSlaPtF872hXKq4TQ2VR/hCTc2Ca5lWw4Ob6FDEc
QkqrKQh9wydmFz2LCzdFXtEkVvIBC96yCalj0JcwAkdOJr+jriNkTvt60iowHSEATYaZ42zeOyZH
zCPPLGMRTMQgLZw5kRHciNJll9eCIs2PACn9FJFEpRFyZZ2HrDpgYtt7ONjha2fQxtectFl0qim7
zIA28i7VsiUJmxPp4JcLHdBxugY1SPJs1eFBd0ieSFUjgnjDlieckTbFlPRiQ+GsC0ISZFa2cC2b
KPn4fgYxRRiE2OCLnBMGfiDTfJYPRt8cGlg0NNCeRZGsk8GRvA14FTbNFEjRejMEciJus4F0NSfC
YlWc+DwcFwPVOfll8mDWDXk8Hwjj8EIXt4Ggl7I4wC6m+Khrh86tmIRNGcXNGJamTmjRRsiH0a0N
WyJrbLk/UWmvvhyU3vsoYCV1/HYZMuCjRihFE+PhO9ig+jEL/wDDovhm7GwZ9Ghr2JQotthLZGt0
avSF0eB7KeKcwp0DRSk+rDuTQXSII87E1mwiJTWJ8TNvQzTxoc1bqL4UTZB6EpT2NFLqIpRpzX6c
2OMRvJdp7C+pYkcieiGomKmKzEYItTyiMQ+1E2hMM8wnpGO8NkC3/Y9L0JBVH4LvwOh4JYZVDxOW
mOiE5wJI1UH3giYxCSBe4YXy1UMkbeuRJ0VgWoaSzgdejVQwho9jGoNVoIf+o+bz/wAP1ILkaaFs
q+F8kdd/8icvCbOEUaGxzJFsDfSumJacGh62ObjMJ8DSOFEQxtBiUqbJQXUImJi/+ob4wJWaw/SL
TLA5wOddt4jQ+yLrA2jw/wBF/wDl0JYHEKVPIj3kP9Mp5RIhJyKFWG1WPX8aqN5BGYCFwMopTMzf
4Rsn644YEG9Y/wCgUKyDxRKqtR2I23AsC2tOvTNmO8901FOTmGNa2k4hmNsg1fLRjU1dS9mWby01
S0axxdDiWlvJk6LJTaGuqzk/+Lz8CsJlrjrGcavASmC2ZNwRawt8EzYwHD4hc4GsTHX3Bg2bTXIl
rCwKKYSEgZYyJinQmV37EBEWNGJ+cU1gaCakIdiH3FzUwq2RoaVmyGmWaKRSq4NoYJmQSYmx22qo
xDOugj2KoT40twWU+BilppGAeCVCYqPGD0BJDPPwN0YyYw8Iox4NsaULH8PBB4JRFRMmQshGjQQ0
bEn9iwc4HyKVTkfwmxpj/pyaRyPv40xOvI3k2M9DQg9nI9dnAsDxgpROuhoeMmhdSHKEx5NGMiYq
FhmSja+BE6F50MDVaKYlkLrRIIWmR4jiG5FluifMIe0nehzkNzbRjBiIoga6wQc/+RcXHUVovonL
SjRngdM+Rm2JRLA0Y78I3k8iycxle0Zl8IZKyBTSkoRuSi5EL8hbMO6EuHegxGtvwpXc7G5Wjrt9
0dOJsofY4jvmppNk+9pGGTwNV1WQvNoxjKF0U2DGBBy0clRszgEGnbBVc1vgVUNob0DlpnoSnCOi
5a3BFMrse7GLJvitk3yD1cEhmzNizKJiHGP2D/5Vm9lQ02cJS6CKieRgPIMImnoaRK5NT4+Icgq3
tvI5gb3Ra7bQi57DExVERUpLaGaVNMXyPyWdrbhjKUDpM0kwiG8j5Mg8JNwE/kE0sMSR3U/SwbWV
xJbYqqn6Gx3o10eTXJ5KTQxttqYiUUwoElO00Ww1wKKqaLiZF0PJotmRC1Qe+MkpLNRYHefKMsYm
/wBFiXQ30baCOlbSbEEV4IeokMTtYbtDvPkFBl4RgRsytCCbyzwLKfJmOYOAGqJ57LZv4hS9Ugjb
cySCSMnJ5l3EbBMja81DJ8Cc/RQnh0adRRlLyyiMRJ/A807qMQizULeM9nuCpLGGdpiZN4tbObhi
+oHcOT2bHKpjytPONoV2yQwjmgLFeEUwxpuxw2l+UL14F4M7rfIUsMnSX6MKiF6wLgEqFOS3tUT6
E/rFvY7kusPrv8QgrqjKHNa2XkU9OQUWKlcKt5opN4ITxlVXGBQi11Rs3KsTATG1Zt6a6tG3Haux
O7y3kNBRiYpYNzIhlhwWEuTkyZoaPJePjKOw6RaywasYQNNFoZStmmJ4OAxN0j6+CdQ8MavsWRvI
qxrY0YYFv4mGJEhlwIoLCLkvLIzYkEmckbHs4OUUpgaFkNdjyiBgK5RRG/SZe6JByhWzNKFtN1oe
WVqmCNN0S0bbKISfkx1pwN/QKikaEXGhHs0gjHYhdT8oatt5ZVmDG2yNpMtXw8G1gpCKb18OokNi
4iShvuAhB0ntlyuf6LTFqGWeY2EVqr9ExWSGNvPsO1SS6D+rzN0TFRGaaYuUPschCVm5tGn5eSJU
vZjXS2K3g02VwNciQOJdMx19FS7L2N+tbZV0d0hwcqjY0PdH/wBAYtjc9CxinDOTHohUqvDejaWY
OTUxwXldikZugYtBTmmMKW89EMr2JxEEXLM9mdH2y4UzK1whH47TfxBNYbyi2nHk/JAzHkrouKLq
iQoRaYibrfsVTbvLQj7/AGWKxb0HwghutYMSxbCByz8nKcFBpcD7ERkNs2mY2NsMnE3wN9r+Qg45
/BlauU0y9xNPqYRm+h9f4zI9R2I3qaZNme5AaG6nnaN9qKcQq62KzNnexxTkTGeg+6Jyk0IdvLJz
Y6YnEk5OdWYNUxyoeNZiKi9pxZapZkYiYldZUJrh8DALC2LVm8M0PMI/pHOmWt0hSxrsqgx02YxV
m74RQlmAJLSP2Li/syOkmaFqngMYs/Y0Zxjb6LGxyixzWugpnWhEeNkw5r3GvjZAxkxTBp13LDbI
yXiBMcGTPwuxNq4D6Pb4qyLPwXmcFKRKVjyhSW8CErwmBA3IYsGaN0TolZCyxqZZLkWYgLbduhyS
MvyJwMoLM/kVkedgwE3ayxbHENNZF9si5LYvHUkNc6zF+231RYwXb5Yw0btpkw1rNiTIl2ZTfU4f
wW1T7dlN1Irk3sQj2QRpFcSGrga04HJIMs+OTY0UZKNGvhCweX8MQuPhaNxIeUSmeR6K9fEnAmQ0
x1kz38JX4P8Aflp4HkTGwsM2XwdILBNkwL4lGaGxokpS1/GPnTE+GLkLLPPBu14Hh5MDaMGNw2MV
h8o5HbImhOnGeRR9CPjyPBvV9JwlfBZ7k2AzMZx3kx772lSl5N+0qr4CVitOR5Hk53RY+DWCzY9U
fPYwK+DAv8IOLv8AExXaCZimA8jPQVk2QfpG3y2xTVbwJVSiu1JiDaQSr9Ezqa8mRTI/hvTFuX5l
jkYvtU4leWxpYcwxejbnxTPt3kZnb/Y5SGhv9DYFdixGPoa7TYgw3kP76Ix7D2xRY7yQ0d0aY/DM
WNtbDg1RJreg8h3zRO/Y2Lf9JPD/AEMk7TRizMv4ZF7b3GTNC6EUs7C2SfXEQmpyLY/EblVNBK9i
92g2JpoWngUBuO2KEqHptAY0SEng6OXRwiVeSrBr7KhtZkXIhEiNV9mWSLyJGWk2hxk8vMw9AvmX
GBlWBatCbOKLUNrZTRV/BSzKpmepMRzr64Opr0oPm74jNGWJenseP4MliDeiFNwooZclgzR+SKRh
bWyiyk2LkY6SECn1CMqJyj9doDaOMXttF4OtsjRWtqxDXUdPoN4XzMCM2nOhhq3pCYtYo8uvInKh
cktvBGjgdrejPIjGNNGB/YY/sYYWsDaKPJg7OSDNKzEXTfuV2MMyD2HgfaxaSHeM9CRCnrBjBnKT
6Zc5Q9unhMQE9W2NJRQwcpkHashjS1eB3YBlo6WdkwzJXzBJkcVKFCFjSTqspq8jwO+ZdnGT8Wx5
IPHwb+IN5hXYlBnRz8Woy+M7GqcfLNDWR4+DfBCCeDSODNFPhkrOTFiNfFIEs2j5E2WryJSQwQWV
nA21jZseBqG1Rv4x8eCR/CNBZiDWfAq3wZVPjqyKifxV0VyZJNFkSUVI4NvNN+fowRton2m4YBiU
6xG8GS7OAvZfQ6SCGLDbpnyyzA17GqcD9Rr9PY2ZGpsbHwLELLLwV5DcHNSu2+zoa2F1e+RoOk8m
LGFmV0Neip8l2GB7wJkrJ0PMy5Fg4sBO21cljIY0SK7nCjEgfbAusk7YrSwbGknoa8V7GmVvBTRe
BCbCMLY3k34bVOin0NQBqENCfAUBBWpY+tGRCv5mbQOcn9DPOZjkXo8CYEWuE4JNGMshxr7L4R4R
rM6IddxIaosjghPwhAyGqRMmuyKl6FM0fIuqE8IXbV6MUnFyqxsc/qGNkOBnKoaoVoM7YeRkua6N
jhaZI9X4Pex6LH4Jckx8OUyg6SbQkTx+hVYx4EIrAhqrk/YxGQlC5E9S8Q5w38GzVPI30pYyJgkT
ZPRDWflof/8AAvRH8GWTtDoKlcvZSPYbRLWOxDLMRdDe75MXMLGhG1nWaDP2X+73gfZtLPMUCUrS
5MLBg9wyuOQiKsqgSFeuFkTh5yVZbKByUaDyhWNnEryJmNEfNjoyt2FzCVjKP9EdsbcWBSyL6Ear
7JjkcGsGDbgngV8XeB2ITysD+r3DE/tK3kft4ijntoZrshrtIg2kOApSOWwxsfiSqiwPGJHxpH9U
AZAXOJi1LDuTHjrlgbQPxKsCtUkT4IzTN1cIkSW22iJn2SM5rcyb2ThNhotF4aFdCTa8MYzhPoYP
OT/RaJKwWcj5tscEfRSuRrUtIweb5fgdUVskMFo38N9FolBnTfsaEhSkHgtF8ONfDHQ1DXk2yZKm
N5L8WNDeTYsLJevhsVJH2b9jNIy+EyMf9EzBjRwVwb7GWjGhnAqNGifK+MmaqI58KUcDcKS/JLTi
EKXJuLf+xyaFNjWm22cwUhwJY3JcIMNcPJDqLfAxNq8Cn6uDVngX2xiHxBpnF1Bz86Mm7yapMrGR
H8DlyWMUGopH7FwN/FbFeWR70JIZgJTYcDtXoig06EUFpUOepNMOS9qMnGyKQKtwiZGq8MIXeBWP
SByFsVrOXk/wHXSJW1bE8BipOgeDxQlht8Dd17lGnYzWy0KS0MhbNeFEEaaY0X9TMFgLC2s0vHCF
spCRdYjHNnA4umWZjkv4S84Su2EOSYW5jeqOU0ryYeMpbFuxUpcJCtTLIgtW9FfQxPAgzr2Gpx3Z
EDdTkQnNtltjCMWhNMcS8CNg6iBnsehRUWvvGXnf/BbW+xtmVCySuEHhDBHFjhxWPphsRAKVmBl4
LLY5+4f0mRrvHXFBliKP8j0tQj5F5RWzvi2E14TKFGN7Q3O600iexLKGadG3oqIp0qP/AJHQrh+B
/wDU6HxeY/8Ao/8AjdF61RTfRTFhuDZTLxv0LKe6xsEFkJgkabCRkXsaKWF5YqXNo/wGTfgXkyXo
/wAHOXKbI0NvwI2LoYrz8Nlc4byeXUfoHBYXFTGSXQDgrJ1DWJHXBWUmyJOj4oPlbJkiB+d44Qra
iyuCSCiaI7cQNZpo+xOXipknndkZIPcrCElZmQyOCexm4cfgVNcv1DeNHLFf5SwaJ1th2VxnJuRm
QV0Y3T0fgdHVtp2K0ZIQ6g4vJ4cR7wkzE6dQLs58Ix90DIl0mJCtVPW2ha8bR5NvjBOyawOqc7B1
tu2NYEeQqN/B5ZpCeR/EFofxwEI2aLGNGic/EpBdiwayjsTmBucfCXxDRvKEsjT4OwWTIeB1kFTi
HuWshkb+ilOBNj4bz8SCVZ0RE8mwnWITOxZYnOiHgPDNj6LP6ezxSsaVwkxwyGbmnkgrXmUIfCGn
SUW0fieiIaGaWg9YMSrTu1CNmxgWYwbg86QddJSND1RdiVCwTJr+pkOzQEWiTyYrNwRoV1EHHJLs
VomB+RTaokYGX1mPjIo6S34wQbPMEQ2kVovMMQy00PJsa1I2OsXIh8ETsr2SPZkWkKofhE8U+0Qz
oEEobdYYaXTOxeP1MuxuN3BJ58lp8vZ5dEoJAVI10NtDArCGUehAzphIQlxF3L2U4KShHeUp5NFa
lwqpiyYWBWaWKWJX+nFBohe+RXdZwVWw0Kc8E9JNm5g7syBp8aQ6k7ka7G0f/b4JN8iZbNjE0GtD
UQOotcwVI2dc/VHVMUMrs6MC70I3HYi7VYHMTcxysoYue1CT5pZYxTMRiQaef8Ido/0+r6JnFTXJ
WbmUyU1oxTmxlLxpn/8AZgc48JIf/Q6Jq2Xycf8AIc+ujZsy74Hv/wANGYLukYhh8Bn/AM/ZPc4w
H8JJq30jkcJGU4BLQdUlTbxQ4rQWQia1xD8TJ0bhwP7h5lf9EJE+RDazX/0093+DYPFP/m8DT/75
MvU/wWsHIiGYFRCWWwYEpsTb4KXgW5LpzbHsy7mliHmffYuSk1D0orTaIvBuiyyeCHNFG3qIuQXy
xnYbTwW1zqhxtGvQq5eV/wCip1U3y4TmvQuRnsGYTgMEyZmwoNyngbWDguDWQ1q22+hUpbh5DVO1
D7IFmUKIU3ht2JxBocjhCC5Odj18N1HJexjKg2JNP4avxyFSpwGAnjP/AOKwhMDQvY9w5Oy8fDTH
fhfHPxwTAhhDx6OYTI3M/Dj4cMGSISEg8l+xNQufi/gL/STMi4M1sj4OQ96J4vQvZAwMmvIgEjsw
hIMmhM2g/sEquQt8vsSZXQ156bIvjyvihdCjfIkp6IxwBTuRzjLG4xtcPgXA3gy0RrkeTLDPqwVv
6MiWRq4hmoHhiKDsYVDYasFuXNDkxoseMhc88Ie7pYRoGXCKuKFBqeDwMzhG8nFGA0olYuOqEw5r
VsbbGcPnIsdhZ4FJV1hAfRHYswzW65Eskhkqs19h0SGSgSxjAr3+nR0kJdQKyd0UDTRRI+iRqmaP
SYupeqZWIWu1E7knAupjUj6R2VpCSzktC8HMMIknggQfdyCSZ9Cbm8DZETymKmV5sNntdiDybpzP
B1KStIUyzlspRmAtsW4deh/6cN/J9CnjTpjRzpYRR5JbvIo5hM4FayrqIK7MwXbHWtE1giZVLyMG
hdCu8vQxl65MmSWS9iTUsHhxzgczynQmxjeUhhoo+hMQ9TUh6D/o4n9oSPI9jLGLUQnd3h+RXaLr
swyp5K4pG7oWlxhmXh6hZdlTK4gLOvBClk+fQ373CxT7UxDRlF0Tj2NkbbwOCnlRsmmZS6RqN6NZ
QHTh7ieBKdIzNmyV7+PzWDRl0F9pyzEKmJp7FkVbURK82jYxHz5KQEnlk6WizRHV23eBCcVNulWp
8Rmw/SGiqdZ4K5GDJifxYMISrDj1tD/xYlkNd6gyldq2Lhv+qN/GFeDAx4QQ00XMuxBCeBfAjtsy
j30ksUbiVUdPAdpmrMs5IE50b/zOQ7WZE6yLj82hehHHVyMIQsvz7H5bo3oSU2ueB+KuU5H5ojCF
OeeTkSlb40R4qVwh/So8r/0eSGTQyLI9s5G78OEHQk+Dxhv4bM/DJwJZ+KwLTRkEym9iaXwaG2J0
0LZaMcieRkzTFqj4CyhaLTn5FgIaMehC8/AnacGi018wa0J6LWTbRRdDbG6zKTaCAwydqHsoSwm2
QzF2hVJQzG2sNCKkYyKirLhr5BFibGY7IdLZ2Kc+SZKMbijS6wp96Ccn4jsz+I3G3BXIkG8L42zX
xWRMSit8ZHF3SmSBD8mIbMDpFZvg8EnmayhUsCP7Gv2MUloHQnhu8oUhC6ZTzsYkXYpJoOnEMkkd
MYP0MSdOkRabYfQ25vJnyeXTDg24JD6QTgLyyXNKojeb3tGLd8dZQcPAvDa3BrTr5DJME9tE1QcM
VA5USnDXD40xlbLafImY+uULEkvZiTgClQ4pEiX4KqIMZVVcsotz6Q/q1wxizVrDHpdkJ4qlZ9GL
mj0hPl41bfL2U3LXehTovkpydc0YsbJjyYnaaGui9K06HRe4GHk4MRm6LDw2ZXI7irG6Nb9QvP8A
syrS9jfI0n7GmK+Rhkk0NBxaXMHhtI3K354EFSVozEfLPXEgup4TZENXtCY0S2IR043AZNx1FCKf
27PukpZJvc2G4AbljyemJMvBSuDb7QqVU1ihwVjckdnGDsQBM0Aky4AmPXOcHlsOlRpkl+Wiw6Pq
oeo33AsRN2CwsjSdGgvop/52ltudj1ofWkcdKv0a2n2FxnvJwhZndDNe7Gw3vqoiL/uh9lkSCzkJ
hdL02WG8g8vpTKiuUxPE6F/bmStRo14LszNtjyQ+AtaJXQJ6hxk2D5ECXmfB76nRFT/ARm2hJurE
KH0pRPR7DED1TKbpm+W+y3R7rYsXIeW/goQ2r/wytf3yDmu9SsbyQV7Oyp8HgGpm5bT2Pif2JNV1
RwdLgU7XQPbC4DAaz8CwN5rLnBYNfFRIUywoz+hFHklHdCsyJI2Fk2J5GiWDV2cyDw9Hk0pwX5by
aSMQUF4LX0/g1BP6Hi/A1g5BKlyN4J0NfE7G7x8PD+DdEyOoQaIabMBvX0V7E2hTxTfA6Xx9kJsM
XaRGnr9CI2ngSYGizP0EGAYJJFgDlpMWMPQy2LbAgrzDZ36HLES+Me9GZcCGTli2NYPZKOT4Jgq7
IvRInW9jkbH4IVtvlDSTWy0QfaH4JK5CGGyU2xkCg9WW+DYgJWx+hCW3piZx9CeIN7/AmGSi2l8v
B1HV5FpVrHgZPH4hy0z2WjwiD4yNo7bGByvMN5ab6P8AqApG/gTUJXJxC1M14HhsDiL6F73s3cMS
mms0pX0Z164HNpXowJfYkcKTGH0Ol9gXsqWSWJ3OkNAk5QhcZHSZrdCtRM6YItnVKgsdwZtMf3Yp
LZvtDPKliJRLTJ+x6yefooREq9mW/wDMznB/Ym5rHJ7xQalhL4GTf/QiQisI6hn0TWhriDXLIuig
jzL5g451YwMlUbcrEZHs3wYku8oiOB+A8ryfoLCM+jcVOUw/i2EyTTG62PIfgZ5Jxn1vExHi/lz/
AJww9t33os/kTQPLVFN7Lr4QxOjdv4DoFb0SjG7wJXgihhy5Ww3ZDBbUiOfvKfTaWgIYXGLhpcGx
JtMzKtguzQ1Z2KE2R+BGUkuW2tGqH0NzUYYdojGLyQSGY3gPLa7VYbGtp6YSUwwWx6BThMydSyYx
tgWViOaGqRwj5dJmmzQxkQNjaMjpceSgrSCxFyJ7pjZkUMaHg2ciLgpoLAvI2oPQkZISwNRefj+C
GDKJfDBnKgqmQtDQnZNfFNE+DVWx4wLPZRG15G4zZaRkzDKOTaNFpolwNaP4enxovJaLQ18cBYHi
smENBwTLNWhsp3Q8R3B1GKqSFe23iEwmuYRN1rEpRTwWZX4DIOI3o7QLhFL/AKEJjZaGKpvN9XB/
EqOsHAjUez18N34ZRIFhG2JwUjwW2IjZCmTqokdhhUPsZUYS4EBXCIOqLYzTMCOVWhFUcSdMfyQr
1PISZpF9VhnjCIoEMtPsWYCqI0ZzCDCQyoacMZqfqmcVGqMVJUsk5NlMh9PRmboTUfKR/wAXB4JZ
VeBOoQqRSNRhUSFw0gbUJpncTeiOJONNcic5Vir0r5GyJnZI39zBHUg71f2SGxIaMl8OsohIqMYI
meKTxRwTK57nbLheDbZpRfSKYXlYYM/zyaLqy6Zi1WioQ3LtRBEWbBF02/4TjhUwLlHrsbENnafC
QjkLxCp4heSxlrkapKOBD4r0JljT6+MjdLgwvC7E0ZBqzn6GzawXxWTOYMXokqwVnyGpJk0xMX9j
WItUic0zgNuQY0aSQ6Imk/JPWbmCF2HT0PUYOZ8Gw1zmEElayA554BcI+AioYRMWFyTVBM0uWpwh
u/X0SfdxPsYl9mKIFxqMI5C7jVS5QyJpykLUSSRtNsdUdTAwhD8HL4ND2smkYeRw/JHe4V2OjL9I
ulsJUrK42MhVrYuOx+DRTlfcLKL6HRUXwEjGKZEcKWSjJ8A11fTHPyqUU06TtIhJDHrmXDIfRMII
zM+gKdeJkfrloQ0NwU+G4XBSwt+Nv/8ALD2fwOEK1kpkvJDH2MuBOjdEbFIZQ8k+WqUejR5ZpCGh
BiMjQnRmXtCS5NGb8IgjbgkNojEiVjP9INZJ+/Er2JVmsjyjg2hjKbLYJUYe0MQnx8ViEzwLb6Fl
YGw5HCm8FiyfsIgaGYcJBRWGTCE7ohooVojgLi8IvG8mB1op95Fw+P4mQf2Ig24uBxVsSnI3LCKT
owRwYQ2LFDVymYjVHgCfnkWunAtPL0M6/qYZEzBgXBTHW3gldKMKeD0z2gklppIcwtBSdvIQpymh
MR6DVT6Hq280TqGhSGxmx65zycertGLqLsK+CqPuOMhsYmcYE/KSKFxMNHJL6HIoQFN2KeQkyuni
qQ7aNmb6EI4RDUTcYGp5Huxzp2JCVqaZXLFVh8ikue7rwWKXJgV9JsCjxqvkxSJcI4lJGKagktL4
S46hDdoxGoJRoQk51wGUiaWSSGB9OqjA8f8ABj1VlxawaKUGlyMC4WuRlLXtmdNeS8DWMK1ZrJWT
Km3TVidbcJ4pzIR8XGjd5hJYNFVnhNRFh0RSWh7EuuRyVu4sEtlUlhD7T2zHy38GQlN2CQomAnwu
EJm5SRmthgsN5B0/bB+Vb6FQxeBpFCyzOGE/QnAiG6MxLbWiJ5TdsM3GSDmFW5EQnnLbFTd18fT4
FpY+ZNqmRQEk2mD+RCHd0/0lo1wKLjKipZTweRTTmSQxnbqQ69yM02A4mrVTqZBj3UOZJw9GF9CU
Gfwvbb4h8WP1BgbacFLmmjPUfpia/gHIK1GYgv8AVAyV+kd+sNEvIth4x8GmJxHbK2NDZFRMXQtP
JkVtWiyRQ2zRtHJgbX4THwaFg5IQy2J5LGQ/HwmXI38iy0aY8Fzk8iVGDMws6+LENkeC7+HoT2UJ
8GmPKFUNXWyIgJfDolyNwVbNEhSkyYkQfA0IaokY8iXBIPJ9CfY3INGUNGzoXTRgHq8irNmIbQac
8V9iyzeR0JObIm6Icp20b+nGu18Hr4QWlyic9B4TzJ+QTZVU7gGTGmVb4MPgtfMgsKM2fCNFb7S/
4PTXQ5/hjDHSR9jCuxzpHcfT0Ywz9cjDwcH6Hm5csz7LELBQhl5MLUaYHbejAeBeho7LJvDkGLYi
MWDorB98sGJcJjSs04HB5ARBLRoLbRNxXcFEJ8cD5ZK+jMxJ5yeyB2YhCtTcRjhHEDrxuDZjTkfu
MKDTpU2OfKGr8iEvKCWUwUFdfIxRejU6zYEKWqYXCpNxD0Yig+cweJxYY1Uuh3EkOJrawSYLsso0
G3KqJ/SXKFp87Lk2YSscBRTiX+CnLEDW/C/mxY4KA12XDQ0oo3Sws5C84gYCHaIk3GytTSayYTQh
dtRGL7TRzI8DdvORnNKJ28ClsUa8QPy5rgmfO/ZBESUX6e1C2Cmr6EIzUdvlTGZNlQSWSNVCxqXK
HRKpcCLpsrMD1+kx7FX/AAKHMs2F5ODAtWDgaSNBptibheJPtdrLBtCHq0awoQeeC1h4HFcBMusR
YHFdLk7yJwYSiZauHQ+JVNh0upY9iJzi68K1OR4Jy+AtY90E9kfyMcIycZtI5PnkFRbyS4JSrJKI
W5siSHNIPGVOzNYXEjckRcCFrdsJBoSnL6aj6HipFQPgMNMfA8GmVRqTG3IYviayVlg16C2+h9Bu
mkULjZWw8IuDAehnCFES/OnoNj+NifBYJyODRBdlyIQwGDFseh5HhFc+JgWByjiQ1RaybRSR+x42
ND2JwaiMvg1CqQszao2Pgn4EQi+KIhuBL4bpS+ZhZNjgyUZUh7+E11g/BjsNpUSJ5pgPEkzlu30Y
1pXB5HGtRz2JFp6mMPNFfSFg5KORS0VG4HgnewsydYR3WXqRaJqODlNjKIqiVixkGsZ+F4JgZgOs
VMz6FZTlPoeHY0ZI30heaSDYkFA1ORvV1YknVGy51TGoct1kfcwKWxYpzLwiN0Dl4jI60uzQ4wkl
eDtOInFscbLoyZEERkdF1CS4SGCzi8mX5THTXPkUTETxqcw69sSYOQqRKffYunKyKqoi2dcYhJ9A
FoJQ8mLe2M02yop7GFnKWxuHCLq+DXAmnLrfYsdW02WKba5pAGGJ8BABcDdx2RQPtHkI2qC+C6Hs
YXpcCmYyky6eSXYtu9KjxpjbMjy7BaTGJvPFJbBkJZqXKHUtorGCSO5MB+jFDEySFbnIxBbpByW0
Ug/8FiPMnwYXSNrKyPWdi6ZEZhcbxRNMSXTZvv4GdpX2OxiUUpbfQLkaDmEXzHg5JhlC+il5UUM6
K0+BQVv4YiqCkm0zlhzCZG0qxZZMoW6cq+AXZ0horJaMtnDHCNanTDUrCphrJeBsl5XJDR6Dbm/s
hwav0EMbest+BcYYnRW4Z8hluTVIvjZvBNQFelLJtvgcl/MDqqq80aHSvZjctIv6XG10dSPhQNza
uifYHp5t28igBN15Ht1uVlsfNUPHgssb66SK21lsu5HNWGinBXmlYXWmI/dOTn/hdjyshdE5GzGf
0RfFm7G+RKT6E+34NwODHjFWhJBxMkjt8TmQnGihy8jLoaOMnA3TklZgLKLpMQ0MX4WEZfEF7OQX
/wCDD+NjaGJQsKXAholY3CIRweTiHkdMeEPt8PAk2NTbvw/4J9DLA8zPwfYiaGqU2GrQ1SihG3j4
SwzIQ4LwR5CTGsiY8P4TNfCWKbfj42x8iwG+RS4jBLkT4FqfPBiE5I2HTtGOWjewWCbV/RQJIT3I
/qmndfYmrR80T2TtR5Vl5Qv6+UnwNSUployz/ozePwfQWso8sgyC8jODoiYtiUmPAnzOuB5c74fw
e1HkhNP2HjQPgn6A9e1s6qzPIqJ9AxIPSKulTp9GBIhiFBsj0JcmhUcAH0ZNcszzT0LeyIZibXk4
OgkxAybN2JUq6oNZNIY4nWS0uIJsSpP8xHYfJk8ziCzD/ASNM2z8piEi8CllpORImeR5slMkGMtD
mChJtuxPKXyYOj9DuEvLG28KYrRnweA+yPKNjA+aftcGLJ+xpHL7ZYT/AAzhX0xXkbyL+7x/oAOx
RcjDBfoXvlqslt0Os1BJ7FfPwWMJ8+XbyYOqMTwJy3gWtOf4FW0zzQk9COSewhk/KVyRhssPq8Us
w4JwIuV5o2ImbGVR9hsRH35HnQ9MRXb9mWIjfTF9UxqjAyaWyszYoZvpmWaZ5HDNWGa1lLwWYr8N
iarqwLo+4x19hKXzgYpL2N7/AADpt0jgEWXlCqTUBBZbbdSHs+uRJIXY/v8AyVIM7J6i8CHBnSMx
w1dCuTvcM4ibEI0GrhMUXq4QmZbZkKT0VtN2Ibm49IUyMB40S2n4YIN0zwMCrvAtc46aPrBM7jHk
SUiMVrXZoQ/wCdqmHudeh6sp6G9x+hpDezGuTApTFjSG4XkZs6poHgtLghoQ3kb4T4onIkMs0OFB
IfxBPI3gl0M+CUF8CVFjG6Nmxqs6D1D38ZLogtCZyNjSnyN5JcmkNEmDgq9mBCPAiNkJbOKhKqjW
SRjycfCHzgTxS6+G50tpgJ40Na7MA0ktFNX4K2zaIGBMjIkDOtGuCiugZFX9GhAsqZ+ivp9Hn2PZ
kwyDUzC/aND1C4aag4b5LjCMCXJgx2Ym8kiILQ1EJFR7LBlTDy0XwlLYrAklJsqc14RzQaQyCXwT
mDnQ7Ai0Ne2ZBPoLpqEhyIzVEMfARzUZBSTyIbW/g1pfQ3lJsWUL1k9eiuhNe4xRbJAWoJoeU0XY
N90xyVkXIfUV9NCvNi2kPWFB700/BRUFLyNUWL0ITgu2YIqdClIhnMFwO6ifs43PyRXB3IhWI6H+
AmqORtCVlKLYQYR2Jk/gcEHJWL6PuRmieEIIRj8kZGC6YfoRlQ24HljKLXk5uNex2pMhsyDhGpZ+
hnS+iwakLy0cuRJ1b6IoxtDdwiMi6tvoX1jCBL6rA3dA2ZBKHl5YT+voPa5O4SfREgJrlyJEmq0R
EOnMDfJJD38jRC2lUIOPSl310NmHTVejA4ZbmRSYtQqozrgSHZzvggnquhEwcQuqzTNF7MHdz1aJ
k+rUqFWCZ1sdz9cCQElMbKqwtircMVEghQlj/wBHftfGKqsyiGFgiZvz2MrE7g9JJk6X6xKxBsSu
dAvqLBeTK0VRzObnFwNpNkZGuRjsbH5iVdDfsKbkgYvBB/pJRlpjfwWCVLiO9C2RbfYgq6j333IS
1TgcNDyLwU7FyyhuofQGOFSZI3Ofgh5FwLHIoN1oyITAnOByCQ/k8s0Q+xL7G0QJRjEnBuDdnA9l
IiPsWxjWKM0vhcFuBlyIn8NGNs3j5dfCWSR/DwcDQ1kgjT2MVaQ0SFTFse9mUiZFyxMPsptY+ETI
8jB+DmmPBXT+FMBI+xvJkNREzybTsBCQvHDiFVS9iQZZ+TTEg0NJnkXwVWEhz8lVMawuxTFosokL
PsDDjKgvodLtVEfLQnjGxGZBBhkjK6f4Iei5pGL0OnyoZWYPSW7wRyU/Uf8AHHV3A9CJ8aFImyEj
K2lEJqC53pFptvCEUnVphZrjVFs7WIR04xiLHJQJmFgU2HMFjZSUqhHY0/LGu+TGhabbmBucc6J5
xfQ1in6FQCgilwEepMw4kX2V6Q4yxmjeExJlaXAp+NrRRMJ5FN3mh7wipfUKFHJCOBJ662sVJUt0
ReSwhjteQlhXe0/AsvM3TJUqFcy3aOMN+UMhWaclJHok6B7/AAiVZ2L8mhSC25QIIUb1Si7OfBND
bIKqY8ieEOolGfEiokuF0LLx/wCCzJcpDTknKJaoMqo8jsTLI3EfQRSzq0KWSSfTGyix4Ef9oqw/
Hg8xB8iGGDlGnqqHirTLPdQkDemZCw7Q36BMvYv0znoorJahCQ7sATWeUfR5fCrfKlJLmBpda7HB
yi84MnDZf1kamLcPRUkDe7FFFChBnhpvbRlxcPJk3ttESCREwPiqUmCPBMzyA7FDBN89GGnYWhSR
cHFFYDCQfl7lHK91FifQXRpRPobR5HS2cGoEu0jRYS5ZhDoQnW0gRoZNczGGUqMHEoYRlYBvoRYl
T/SKjD20RM9N35Jz6JCNeyRkfw5fAi6V/wCDf9hzHxobhtPh2J8NCkFplJkhweAv4PIyr4Wii5Kb
yLZmFKNsc/DZpCofwscHsb4GkNGN7+MGIOTMvn5NzIvgl8ZcDZpdl6HgYBwgti+DS/8Awx0fg0XH
wf6Z9FoiGqJWJNitwYzWN4R24Q9YUsyCV0Itw0/w7W2cHQyJNNhurpNmXeb4FRHp4EG0F7TwMSsD
fkkTWmMmTzsZp4mb5WxK+xksDJ8G3R340zY3CidFlGr6LH5XI0UqE/RpUxbU3wG6H3o4n1LtDDuC
yJ+0hB5DwEF5BO7Zgkd6zwSKdhNFEeA1sLgheAOmaBGIfUXle0EhZmIY9umoOSptsWlhZo/auaLI
W1FFjEZuVjsQmoW6EK23pwARZf4P0oWJpVTZOI/iHAFEwDLJ6ZhzC47EN5JeBxID5AdndSrniEKN
Mu1s2VXCRnb7FqKvsY7Lp0VfbhMgdqCGizyF40hmU9jYfWrXjxNWztyLFNPwuBWkSZ+tTNjCappB
qcWwMttuWiTBtc6Yzw7HR/8Ab0W3MYFajJON8iRw6zElzeikueMjWND66pgtuZFe47ksQ2jDuGbw
bDti881GSvhwR38Dac0aet0V2KNJbaZbBiytFZ8BgCXMXgY8eQ16/wDyHnLZB5mTWx7DXkzXe4It
vVFLT6DHJtv/AIXpa8MGPq2EiuKts1sVRWH+JjLGzhGcOUKgdf8A0Z0HwMBp7EvQ9wY5WgvXA+Dx
SV49CeHiOqBimuGou0zZhXlWASmkvJGJCPtJHsxp7yMonVgLgtvgRjmdo73JXCOGHb1HUra5BtLC
eEQ/ykvJWDHRF2BjxvTP+CEYbsIq0sn0caOfhIrTboowwG6a2bXg0N/CNvHwMSGctGiiyNCwxNDG
QQ0Ew8McGhDoY3BIqaNHtEHI3IXBufCy/hoyewg9kU8mS4yLfwt0JNcj2nwnjOio0NBO/DjFo2iY
+EYmTGskzgQepCfBaEssk+GLnRaOfgVRtR8Mh68Gw9fSk8KtzIrKGOAXW8KbGTAtjNsv/QWVvBUh
HaIS5L1oVBt3Q016bg1axRMYwZUsKhjeyHwvJnXwk0OMSHkIz9Jw3gOSS4Hg0WvWiYlo7UIWgioV
YVnfTOdzdQzP4ElGH7H4JSGsLlCV1kbi7b7G/T4UrK6G+yUhvG8hzwgZ5UjgbEMMIPLkRnA61kfA
+cxGDxxTQIQlt8E1NlFJSVElPHY1NNtcCu6z0Ibi9nMRga8CG/DAfuNVmTUGpIQRm0BQK+IJr1GW
OmAHaGhSfZf1GL3BUeGDYlKvm1MJzhmUw4uNqKik1aBCdWwOX+kpTzY0d8GqNpzYlMnSDZmxjck1
kmm4CeIwsJeSEaolsPW1YkY1pUWPxUTMlphiWkrlj7JInFkwEVdmjs7M61/OSa5SRyYb4ETTvmm1
oatHocf6EWkQUh23fQzVgzghsucS6YgZFILftbHUpNAdym7wic2eCBBlofcpcEvBNVR3EjwyJTcs
rmR1LsnGRh0NUm20kI6hNZqzBFbJJMwB6kM5UHZWqNLlj5nYYfWbRCWD14JclSB/k0+jGNSYeiXS
d0BLOJF2R5YRXgnqEf8AQjYFOrTfSyxBETohHhUSHRawzmCRPR1wA8UcrS5GKTlQKY4gq46wGJGk
Y6G4DrPY1oKMcQqXeSfBMPAEO4Vlj44Gex+cZs7G5pijyIp5h4QrQv2MrjL6LYOIwCVjTyRU/Zj4
ExuckqEbY1noTfEJCmPnMENEMsbevhkeQ9fJaGglA8GYbRRqsbd4JBLJpCJkYXQq5NC+HA9iajcE
8mjNLR4Ra/h62JwbwJaHocaLgWfjkbpomAhqaFkaG4i+CGvPxl7+DINTAdKMyJoTiSYgUapjA2tN
U4bjbEBS9BbGzxeRrUpj37lxiQe/SJj7FkF+8KE1gdhIPXwO2nwuUz3qMjc3VMwtHGxQbjGhgUpD
JryUTaGiwWDexsbjseX/ACJDwtOeBrbXwPIKeXAxd5Ucqreh8iawX3mJWLJ4+mLZZfMjD1jfA9N5
OBbwMYosGYVRY8lkpFVRjJMU3DXTGzwqmACq70P+hxXExkPHAtE8qGgI5aqJ+GvQllg8iP6ohtTh
7XRFA5ToWOR+iZVA4/aEj9UJk5HI9jGZhsKKp60LMWFZ3wJUxLsZUdfI/cOg8Nu4XAyhJtqssa3n
sURu1zYMhbqlK6HsWHmRwoEjyC1abli7dbDL4VPsyAMke2wYkTvgPiv2PTcmJinWR87wC+8LFQqn
YKKJk7YyjumQRtfghWn72GPqC6INC2R2Yiu32GPTLsZchvV+SyZU/TQmZx5UQzPgXTf25ow79R6O
oLcI9ytlxPpgZnZXbY+jSlRTIWyjekISLa6E0RskR+SL88iRbeaIU3VeRmSFyEw9uTgam75Q6vdG
0sqZI8SfAKzgM76MsGupsbHlapeFuFcDWC0sqeTgSNRrjshLo0XW3VwOGAGxNzoEnpiTFPDbPSHt
MRt/Iy8mMoVpj8GCIwhrTSW0OqXRD1KsHJe1/BCwxKgnKBSiCXhoTSdGPJr8SIHgGNC8NCmQk1KL
HwV0hdELD6NGO39m+XzFCycEz8yPXxZMD1BEGYn2LY1mnL4YZIujfByMP+EFZg0xOD3R5E8ayOsa
+FBSoxKb+E4JRDQzYYSz8f0QxkNM47Hj0KGg1RPhDKPIwiE6yCUFaWIwQljJR98ESEhfgxYRtCvR
sOiM9irWjgHjBUwsNGeZpDX4M/gFgdwiVo9KPHcSLhG1a2QLI9bMCpGAX6iFy/ZDZvZhXg5TNzb2
L4zyMovY0GeGU6ZeRr2JsWseWNwMMWBCuiFzg2FXgNpSfaHlifgXtMzsb5NEYxvqkxUvA/TivBsT
2MZAgH+gnLH9Mao5YVK+kOTR+jDvDKCNpiusbeYzTULoY2wNoRJHUxR1EZ7ehDCpFoMeG6DKB2CX
H+CKmSMeuFBFOz6EjeP0PPQYsL66SGYFYr5PMHqV8eDoQW22hq7CftHWhXehyaL4KCfg1lwQbnuC
cv8ABhRlupvQlut9oxuJ0i5a9FYeDcgkxlijlB/+HEE6Nhpj2MzpsQ7XwMrk5wa/aDBNQ6YiME21
8GKjx8n4G5oUG+zBqdj0sIxHkdMWW15CvxuhdpMZK07haJVIMraRrfwa3e9jdGJuVky14hkXlGpk
Ssr00p/yIbuTY9ZxmHPgbAW2N3bcIQxqRKD83vLGqQ3iDylzO1LgzqzlSFTG+EhEUKQl7EY3udmO
9vAymCcF4on9llTk5BiwHazqDSQ8HCGiqvIalql7T2z71AkHHGRGw/wMpSzsdmuyhM69Q18pOEPB
H2K6chXKlgPHGvmF5BKtC1YU7As85G5pO+Qx4EGwQoxoymT9GslwLTLB7ENWIn18m8DEPZRjwUev
iViG3Rvg4wX4c4H2MxXb45GWCyyNigeUa6J8X4wyhJ9/Dy+CyhiZwxMEPDtOPjfxOfhpCy8/AkPC
RyMz9fGai5MdjEjE6h4gsOxhOGzTwbSLdEOBg8oplUWg3CrYvlN8kZRuE8IKFo7ITj0NqOBEhENC
D9H2sGOJLKLpKtD7wR1i5MowTOxGjVNi8h4C5CeIyT4N9jvhycOxFGHwOdDNGUiwsbE3wEHI9DAu
DOBnRUb4Stg8pL6GjVRAEGE0i6HfM+EJQsNoRbp0KnhBjS7M9pPsjjUCi1UuTeD5GTmmcmKUOCTI
al/4nQgl1sHn0ql0Po2jAwq80RCm1gSJ5hCJFHsXZ9hLkMUhLZI4IY4hYiHXWBIqWzY23NcDI1nR
iBtMuhNDElarhhyrlyJIlRdSwIxL1FA1mmYkXoJMgsii2SFjOMtybj5gYsuwTSN4XxCaOpVhmJeu
ScTBowJHTcYN0wXTHCp/CEsF2PgWSyAS19B+C8Ec50Npe+B8eTX4QHz9DmjmUNNpkrUywVph+BAN
hdJXQZccVGIYbISdtwhrN76G9wWxkrLImYR0Y2GY1tU0h/UMTBiz+jSDqL0h3EtzSEG2pxRdGLRn
pJQt1I4rSWjVrIEsSpj+h/eYoumsaQ6NysCyO0mPbE2aEK0qTtldoE38l8shrFoxa1NQl46xoiue
Rxy8IJW6xoS18HOx3XD6GZy7OHC5s7IpHAfQsE36FM8syn0ISKZYGpWb4JTSbgNO+tHBV21EpTKp
Bm7kSMvMuLGxjYVYGioc1vfIxxMsgvzaTiC2OqMXWLbDm+riRYQrAVhGZYMF8HkcjEzRocjXxrHw
uzoOBM8l5IR8VljXwrz8INlyNQTwM0zgSoaEhyPL/wDCyxuvJKZDUI6QjG4XJtmGR6FQ7TIk2JQu
DbPA9HHwlhI0PwU5GnwtFWUmc0Tyhr4MsSityYyRCdezL0UmMSFgNITSM0y6KqINSqayLnDgeJ8P
xkMQTGN8aQwmrDSz8HfQF9mjRFg0maQkvBolLBqjOhaPkhsgZd2Mn8G6N4+LIM0yWxfF/wDA7KT0
/IcdwRNVuRTCeBsg4H6gCgDG1cC4zYousBvaMqVTWcFqm+cssvrYq7hCy1sjrmgprbbcGvckPStB
XHYvjIoCrI1OhVjkOea8kRusvooPYjv4TIGWlx8EO8HZJZhNSGppyMplILKxa7BzAIpJyzOPBj7E
QcoTjTI/g15awwJ1VjCi0iMszFLREwkIXoWI9Ix87Gw/HbgtU1wZa8vJd+hadKdQihe0JmuQypQw
vtIeoLUCGxFBbW+ULjIaoqQc3CWgOLsf6Mt4hIEUtnKXG6JrqcJEu8MUVY9cEMp+CyBrYSyWFK+O
bUTYYX4cfor+B5kaX8F4H0MpFfkarFM2mIOeCGc2YHdTKI8P9P8A53Rj5HDGX/0ifIH/ANjolM+A
3bEh4CdLHHBkdWuBw0cmKk9LLn7GxUaK5ZK/CjbCLtbez/Bf4bPFT+J/ghw1aVrZm2EBo3JspFcu
RRlVYaNbQmySuRdPcBflUmbokoUaHJ0G/Jl+BdmF8c4gnJm1FkbzUjSYknhM56YDMgV6BGszInZj
scresxgSZqE3SDwIllVs9jE5Z7Y8+qLcDxn5QKLhSPCYEyetgiaQ216Gw8DZX0OhlqIZouSYJDj4
iHJSGw2R5z8PRx6+T3S34f8A+At/BvI3kbGjC0OsS9CO7NMa/FvobLyiLJRazQTyNR1FZGxo5waH
ycDyHr0Iv78MBJog0PeBcR+fhZKYnn4e/glKKmbG02tiyLOtDpOZZ4RUHjXOTw5pQWjRjVqyY3Gb
UFs2gSrMS90WjpwUoN5ycAFAnVKM1DaENKKeS0nwlseS1o1sSISIVYHoWTkarOgn2OsoP6T/AOl0
Hm4LNBeQYxYXoRe30MZWDzPBsuCY5vYSbZYY0Uaa6H4GEgjVNOofypNdD0C2VRcjq7swRHYNUmuh
ziWKCgU7GtojotYjtAU0LWDk0GRnN0Q25Jt3paIHnqLCix5F9GEpuZgnxdHRRESwviXVEoTmKxiE
W2LB5ESxj+XAd8wCZvYLarbsZG30YewUejrCL5HSitSajMjyFFv5CZ5Ma3lERMTqCq61BDT/AOQd
lW6Q5o1lRbEjG0YejS9UV2k9DnO0FrmVliViuZkoVwLc6FaS3GKWMosrUrH6qkVwm+9wIr0KuBzg
6RlTOm0iML4LGOu0KPE9aXQS6mtu0NSeHmSdaBMPCPrWA64auoU63HkXoi0hj4GtJaXP2YFb/wCR
FcSo9zL/AAQZdaPAviE7+HIThkz7ua//AMwhrIoy+OSWVOODFsn/AOxLKXMKZJZFwk3RZDeZ9iUj
2kMC64CcDWbxgSsma3NC0tLVIh2bHZNqiVIfuINsnU9+8i2uY2Nds1XQRhSeG8jFtfxILJFYqDBv
tmwfjAxRm03pCKSmjfZkmaIRbYD20lq+/LMF1MKj+xVHgzNH6DF9PQJA0MJRK2KOqnOaQmJ2ikCe
TrQtwg98idd5aXA1dUanBrKyI2TKYnowwP4YORwwaRt/JqDWBMy5IL4JR8y/GmcmhZYxgw8CKEHw
c/BGh5G+xMZB5Zhs2WMUeTkSpg/ghLyW1fEaEsF4INZR6NjDIdCH+Dy7HX6NmAjkaz8X/RUx59iW
SZHgyhGShMCGsaz8KLszFXU0tlj/AKKl4M0S4cDJ2+A8Pb3GBl6xaqSRrA3B8BrxRDjCxbM30Gdp
AiJMIeyjkzfAr+GYM5OfIYUMpyLROizImRinxPho9/DuiHGCJihWVeIL595FjMb9H2RMRjK8PAlQ
SWM4LrUnAhsjScOJdvSwIia0LOzmClnjWx+XTsV2rnZzMPAjiaF0BtOjKqRijPsT8HEliIda05sa
afB78YZh9Pk6Wg9ReYPmg+ymitwQkR7B2BRe1IUFrRsxNW0MXT4yGuRmRbBsXReMSgeTM8JseWXs
zCZDKjXKHjVWEIURhEaa0Gi3h5UuBg6UOqAyU8uwva7dQw70pE8KsmBj5R1gEQ+x2EMaU2Ox2eXD
Jm22hcLYzREmzCGHTY2RVMPQIw3oLbK71GMMSaW1ERWpvIp6iQbXBeTD5cnsyZux3pjhPAm0Vu+D
QZsZImEQdvYt0ya1oLsF0Zfc/ezi6xciWSKiE8lzO9kZ0zWDo4n4a0E1NkYNibDPhGyO/IvBLOaN
5HZyukGNHhCXQwmPFYTxPWSiFKWYjohkpuJhbIqtooVU20Orke9DMElSZ0bxxY4Cmjxphme5lEe7
6B9haugsaclNwfVBg8mwfthAb7NkmVpUQPMlJQx5CMxzgcoqE4stkwn6zoUdoJdS14hBwjE+A9JQ
82Pc9yHA/YCWkJWLw2eHWNi4wbyY9ijwSxjyqcpgMnUhtZZugqtCF8yWrtreh1WXvtFel5S6Q1t5
JXQW6Rtz6JjpF0H0eWuY6YTw04GU89vPwYbc8Dyfr4NX/wDA3WQ1gS7MMk0afwVDfy4/GUbyJmxu
F+aL4TjFn5ToSD/ZAZeiPIUQxaGGNISsYZZoKGOsVT+DSH/+MmRPQ34EqhwNCVGhi/JGk+xZQ8K0
TrI+xVhCZYpR6JnCEsa+F6YzdFy1SxTBOZ89izj1KtCB5XUqlptZwTXOhHARdowV+cCnqbY+sJ6H
O030hCKKWh8QEwtsZQprwCofPJAwyxjyLSWmmbHgNBp2PAkiZEmI0yQrsuiGr6F4LHWk4PwnMhum
sWBV0xcd36GEzCdctQgn8IqbsOq3aKTImCexh7vLHsbwxEXXwKur+BKtPwc3uVdkNGuxtf1CSVT0
2Yoz0aw+0OIPUUYK7NSK7HF4H0Ut7G8pSJDiizwP/YEJMo9Uj/WKD7k32JF6YVpYOYK53UWxprIz
H4BZEl4OVl4GN78C15H6MmxqRaww4r0bUMWCPyRjEvJYLnkaPuiJp0g/o2+2K3ACSEFQ8lbAUL9z
Kveb8Al1YfYjSHxByn8lmR86PJmvk7mHZ8IclKZsU6QYdBDOs/IzQMXS/YuxvKbENDyZMZBCpZbe
bS8H5GL9INMTbatyD++YRrFIsfWF5yo0OMoy392IzkOHf9F1K8WTVLdPDFTmwiZPDv6E9SUu2nnI
+nEwyyc3QhfIDAOcsmRLOsSVbPB4QVaQx8pifTiryOdgqljklfbEvII+2vKZhwvoGqmbeSoS6Ohl
fYNjpgShWC3s0iacGfd2Y5Jx8jVOv7Nhj/oM1gZbQ1fh6aSIU2LJt5GLI5RMcz60WyF2QbVY0YNi
nhimmTfskQO0PsVymwRU6rgkRNrB8nNmdCtAuPJyZKE0+JPJMFKcDTehMThk/h2jZLTIs/BoOmZg
1XRKsGD4n/4v4PDAlkyY3w2aHHxyZohuaGviYvA4NWF0I0xnA10YDL+EdDj4TgaNocmw30NVkafF
b4K6RtiQTzkyFU4G+BCvJgIU3zsdceCukKaPoE8gTYgYsVoxbJjJJVjYv5Mmw1BnHP8APAaFLrde
C+aDagckIbEcLCSuYO7SprmDnR79DdLIz+LaJBpQRJDKQ2zQm/gSsyACA33aOtRkEGlTPNrZbFBJ
ToLSMljwazRKU68G8n8LeFsaFV0/zzFraz8D9eR/AIPr2XEHhKkLDd9DTL+Dabzos8jtDqSSc8FB
P6MaZOAF1Meaio8VZsbsnkqBVgpRfodUBEV65gWEnbHRL8jnsER5HjRixpykKSqlaHrQ/AuYV6G2
egY80E6gcXNmSVS8moSwMtF2I5DWFEh5GNIM+hOakoSchAU3gV5EJ0eyw19A6vEPZnDMzQaVMtdC
/SkFSfY8mVByhsZNLyU5dDsIaZ3mGknX0LchB2M4FtXhhrkbQt2bXR/15G2dCGDv0VqZeoLMuKlU
YxISsSslW8IRVhSK2F5Z0GeOafJBTuN9CNGjCKQlqWGbCGqfQy9mC2cngw2waUg51PlPCSv8obDV
9DUsWO8+yYOpn0UKy9oYexejmH4cxS8j5DfDFM/wCLgbMyAiSTlrIOLvQsDV5Qi/I4r+5K+KmiNb
4CeI3aSQuvdZfR/v+hjTe9wx9eROkXptlwxnV1uyDm+wQ0tfgtXX2LqZw+EeDu6GluZLZ3xdNiyl
1gKxSXotHYxB5GQymNqCbhSEcImcDwhMWzBm2h7FTHA8CDeBZHJwJclyPY8Mb+FJBsXxt8FS/wDw
9jozKMbDUTBKoYsWhbGNViMrwHgyEyhroeNHA2R7+CwZpcGg+Ib8j0aG8CwNjzgS8jTnyvkIfY3N
EGTL0PWByBWlXyNmjgELVdF+nAiReZFJvgwmLHC1THFmBpP0GElMcGPjKfaQo7AmSJ0Jsq4FK2SC
k6iujOHY3Hox6K+Hoy2MjaGJRcDlFLTIbTIxoTgqUyxvuuxxOPkiI9sF9CWxgx9BRzeoPt5diMTH
oXdlKyLS9GXWaDIQFVyHgxpMaHtWbEnkcDmW2CaHDvKUS4E0QVR5gyy4YLLY+A40rE9QPaVcioSf
JckkPyxJs+eBs8uIiDnAlAnANe1x5RSlRoVZMnPRm10OXYTngxUyjvZaaGhDVizSxUVeT72NpqGs
HgP3sRkt8M+0kMYLuILmWoaHuqaZjlJoyh3oS5OcDS5lzwJ+h9CMzkG2ReP1LbnuKxEuasKQyJ8f
CC2Pv4qiLfgzkUvwRWHorjL0uCUzyaPk8CQJotFalOKGY1HQj1Xlld+kGUhuaQxKtDuxCsJsXLja
K2b/AAVRt2kxFjTA5xkx7P8AgRg86Hpaa4FlpORMbY5H4OPtqTjavXNFw5eieqeo0STeCjTVYICm
xPwJZAyhryQgm9TwLFGyJQ/aFIawTXjkWMsK3MUnC/oAlQl46Fc0oQYmxKLHJdIifHIhrhSjJlQY
cgVGClwyQMtl8QXu6zZoQOHjHRSSX/wTTHZA9D7f4XhLIUJH9BH9ShCfC9g6O6ZaENxrJiLZLyb5
LoFdeTc0VrLNZQORkStJcHI602HiGHBMQpqJq4ZOuQLQ4dfZNLOsfB0Y0g8iwgdCVmWHWY3PwvJB
zS+Tp8IcX4SDwjIsG78IaNi+PhOjfwsIo5MBDz8Z+Kg0xMNiydCj0LQtmRlPjRtYGYhKGT+EmYGs
fDwqTkl/CGNZMlokIZKbeiR4PJ35O3gZA3I2E69Ba9w53UmY74+P/sRCrpbuJlLJYWVRgRIapO0L
gWlLDQl3mBeByZtz4Y7yIeTAuxMCKmEYHQoJJaefRLTsX7JC4vCNUQ2hJWQc6mbkm+iHrPmVDZsm
bwTWJphoXG4D75vgIqegXBRnAnpGHXQ2LHoM+ignXUpsRt+8GUimwxeq9I+weOjWJUZ0hhC5i8mh
eyGtBort8DrlPOhy6FPNQas15KVB5E9teI1OFZqVaCbJfdRJY74Y7aNjJ4sqyxG5Nkf+yEV5g8+T
8hxqceTKPZz4ushllLDstPlwUp+XeRkelLXQ7NYSfCyW4IfbjY/GGKKHxHA3JwpsYQSQqbueD+eN
C+2bxD+iCpCxOhaaKdBHHLBcldS+RkIXuGOJfJomOULqxK/JuNA1JhtaGlrC/ZTxMPBqchW/IZM7
QUntmUIVeLQblbYaSYlVyJrbry2L7/8AkM4NFVPhm3Fzga9tsf4MWd5i9ZhavkRrss5HhlR8m5p2
KTZ0bzQyghZrvtGefOZ0OZqIQt0VsyWOsfAayajNvtH8sbTldMDB3BBxYLnkrcLOepyaivEqoXJC
CndX2Wa3+Ac9vJLkbmTyLHtsRs9In/wdGaPMJmE5AstO5T4GbY1Gm2x2KSa5LK6oOgZansULEi03
AF1fA4DtuO7M9HH/ANGcFqJwWYPhw8Ef/UcDqYl0eHRnIVGUGx5LWOixkY/g/g2hrBTXwajL8INf
gsHsbgowQ0+BCdeR4HoUfA3j45+bg8ifw0zBI2ZOgiDwFvJS0uhPL6ORMemMLDHoswJ1DcCivZY9
DdRaMiEh/BFB4hRvI8BdDFkPQvoz/TaIy4aFgzjAmVcrkWHRkzBDyqT/ALFyheuUkIWygbTy8DnK
RaRjV0owplw8vIyPrcCK6ClbTHL5WRJep9HA4zWHEUgUFr2ZJsIIxDDWaWbGJMSHeRIVn8EIIC2I
aWrLfAlO5klAvCvEWCfgK23oc3rIpxVVZgrxCh7N+5eDh9ZGWYxei2KyvsYhbKM56/4JAMr4uRKY
eSbIzNJ1hCQjexbRa3EGpJ2nyK0cxcEoksHRU4NMY/tILbWTIBpCK3k+K5lbfI75pOBksitW35OU
YgqyCs1J4EvawsA1lVAUrG2THGO4Gs8XgadyeUE5EnKwLUi0DM6pBEsukiKEBobXh8tjxF8GdC7L
gqxINmPO+0J0TFt8GsRiC2Tr5FO0jN2sENNyvxNaFmS6LYkC60coTwRhbHHeixikmEVNTQySkmjH
Nk5BjVQkfIj0tGZtSyjWKrR9KZiQuMLdm9j2Y0iJFq3yN89FUF4HQW8jK9CVw4kIApkeGxHigCGc
LEdaMx4s1/BqQqc9Cte+HwQ2b6FqtFGLx38E2sZlNje6OAx33Gkw8jJBw0jaX+D1/dGqDwPqC6rG
gXmdCGrPDuf8EXlNvOxleXy0ZF4bCCnTwM6dQZWrObyKGzUFVR54Sy2UmbgWA1ocxJsviJ1PQuhJ
e+x1N15Doas71b7FOElbFIy9oLqbS++xTXWZcCNIZ7Dx2htwitaIXwNmQe1VaRrgAKSf3g5FRILc
tgL28tsejgqTGzeMDheRPBgyoio3x8POTI9GhPOdGYTA1WRoWhb+IeDKJIfh8muB0eV8XBkWOfie
SjWRN2cGCmw9sWX8QWg2NGSwcmh7+CxDdyYEG5RBEmyY+NCV9GxrQ1lTgmfhSjy8HuLfkcpzkbRR
pRCw2GVyOwcNayYUVj0RQ30TFhulAruPDSn5EBlOMwKpcsflyMXUj+y03sg1KJ0s0Sj/APCYwAvV
NbXgnRXSKLVY9vYhDecDpmA8jWB6xYW/CwxFHaPNWGKKKaORHM3gy4X9tzTgRFDydYtktswZGsWB
urBnuMnwJ26SBnetTaQyNptDHrjWpyXcPRxcS5D4kJRRD+iEmi5pRfcCywkyJGGmSGZuDP3CiYfg
TvWtj76g0x+Q+JYbFxY5DwkK7HBZcRZL+0Mq68s0j1dkgWssJuF4MsKy2PR4Gadi7UqRFpEvjO0S
3GNGSMp2isR0ogyp/QwYpMHFw6IGrgwR1H+J8L0LEA17ehmUbaGgTZYwfOmhjf3Dg7dVMor0VHJ7
rJM9MT3upySoupYLU3Ow+KzWRcVbekPJI/aOokuxb5oxkv4SVy8QyiKypg+3gy7Q8RGLV0O3bTQg
0I0H2ko88DGillUwTBLbyIUE5aJ9jc6nQrvd4Nwyw3yg8syvQ08J1PioXTS68jBA6Dc903KH1vZB
ichflSPgIdOWPaYno2uTJ1O20I2m/owt/Y5Oy03gaoAw35F1+kMOYC0ceSIswDtBubZ+BKoUDtMW
b9ggHLOYmMgSEHLAchDeA+BsKUJLpwfQoOx2HKD4YvC7rPK76F521mxuUrbWLaR2JQOWg4OnrGOt
4oYxt6s2y005BUp2E4F1wcih1suzPR4L+uNthXe6WngYuiyeyLXm4YcN+kcq6cGQayiQRbSVcnL6
qrA82/A2xRiy4UIRrYqY9kHooiVCyJWdDb5IWseRZfw+PhKjUY8IWfhOjWDj4XEEaKbJF8bZFgaC
FVhr44yMajUJ4RSKVJCVVKXSkGqaHDZBGLY1YtmX4NX4WUXiCEj+HJBGHciwsicdnaZxlJk8mjKx
XvkWukEihXXtoqGxOOxtRuiYdHDMI110jnHjA0HXE80y8E2TNeyiGkWpy+RCXHgyW9xBsZ8iBo8h
r4b/AEayZpsbyeTBkf8AtKFSaa9hdfdiu0JfYsHoA18jumgK6RrPKLFGHRkl4BM/uAxnu/JHK/IR
UkE1+wLYdHQmRrBrYDyNdGr6ME/pjuzfFEUyeWcqvgyMl7eJyy7La9MbpynsXkbE00ayI34CvnXI
iY1Wogr9TJ7SQjNKmL812OKkGzTNsrCENWPsIqxL0TVfYrJ9QTkzcC7B4gjhfZtB8mOv4bVMfY0u
xO8ZKVPURLk8C5UnUH5v0N0pqj2Ks0Ta/o3I5EGbSr0KJs7QsDIi4NoW1+3kToblIT8HlEBjr+Tl
sEUCxacIy1iywHpmHBaGiwUWcjpqClKmRV0uxYHtpqaGa7pjxFCKmnLzg8p9IuQlwIcVPk2Q8jnH
gfiPKkwLEsJRtmaD9o3gdUpTGxxxGuBUXjgcn8BKf2RBUVVa5HRCYo55FWrJzRNHvlX4E4+zmGNb
S2JNQyZH5VCqLI+hUpkc+iYtrX0GLDT6ITzu/YumK4CsjSx5FSv6v4LKlax1SnLB0KSdabHlYrOD
CjsKycETNpuNizCg3pB7MCn3CIpVLwJear1sN7dsTqjMN5G3C9jz8mEYDKzwQf6G3zohIWsCTHkI
ezI5oy0mRrAmcmL8YUTybcMIacE02JRZGcef/wAC0MeRtDD9lpcmREvZzBIoapCc9jVWBijYMWCx
aYaJkexvjBl/DDZDJt4HRwNfB2DgWxvBRB2mXbkSp+GINGMFOT9Bo4FyPSkovAvJblmPtBaEhmMn
8SWiGCrCpqJvBJiefwYZovQak/UNeyGHEQZoqdHVgzBTAbo1gbg7saBvhhlhqDiIkJsOB8+hNZ2L
aKhtt5Meypn0KWpi6HHYLZKui4CVa8EMQJCEmgwkWVpox0hSVbMeXtDLeAuPLYnxacoyyvqXGC/g
jRPyhlhdwaG08DdBnXxQnpQ7bFPwS5bLBcjel0xQkMevqKSsjfRNt8+kMalvwYTC2T8i2RLP+inu
MRHJDWfEXkUUi2x9VZwkc5CCa3I9zbeR8SDwES2HY7AWaFpb2zEIZE9JBrFmaC4uNwMNWuHEIR/c
h+GlbmJfUhr4+hslvEYpfwYcsV2mehSJSmMpMHQPjsmo9iE+GvocWVSLwpCJVNvhHvuHhLQaWqtv
Bqn1BONsGWEDmaG1Jd5sx5BJ2eD+toSGsMOJS6g6xH0c+vQ2cEq8D2m6jGVR5LRrLgWVIrY+zIYZ
GGBU8IoU1m+C0adPoUbKEtOMsNeBl/fkYWI4QitOei3LHJDvB4E5V1pwtDoKQjptwOldIYNcw5tQ
30XZfIT4sKdk/SiWBjfxtwdENGakN0pEKVXQ49RfQkNsk+hkzeOwomxEGDK7cM25asfMrTAQ7owP
/SxLcPRhTNTUzZ8wi2PLRjPKihA+LwMccHnIiFFbJCGtyH1RCvZGFPsF9Fh42LyCDZIG0MuBijpl
7OCPr4sGaCkHSzY2bjIX4Jk5GsbEocmxJn4Wxdlo9QXgwGroWzIwDxgsQm2yDCeSL5ZNvii5INwb
T+Jlz4HGYbDSJm/HBpGQ8I4E2Fs0NjNMmMnBnAn2dmhox2J4IFir/gsEGyVCGSyJazcNAZi5KJcD
GU9RdMQUr00crBd3hYIncXB2+IaK5gao/os3CS/DJRmqY5YggOQk6zFYT44HsetCRo3gZwLQ3Zgn
OR4eGIPbeQSUlbYtFTXY0whI+RBtLOpSOFB8a8xThXyZotZMzxj1t50zydG1q1F8FD2kA7taLATo
tAxJNpTBg28rApMUDoBps9BCbXLkSl2WMcCk2uw6iw28QOiU2TFKSkWkRTlD/pwUUxbQTWnXIrJj
cozNluJjjLKHEfOB1olHa3eVMhOlDjnYJMJhT5NGOY5MpF6bNQZCzYUrbPhmsxPPQsJaQq1ZEhBi
k1Bd3YuSVKbH2NeCJF7g0stq12IV3wTW1KX4JkZTUSeuU8lkHjRCRK060K3Gg5mMIli9oShRW2hl
lF2o2OF6ESamuxuIC2w7JDEeCoXfw8kaybi+SsvZkiTKaDbiQkUlWB/9oXhaSpjpnWuzaEpwVZYZ
odkZdYpOEvY1+xbEZvwbUH1RLZyHSpKMmyoDfwdfK1syGDlNUxZlXbSDyiMYoEa0LBGh2JS04prE
TBGngygi2a0MfDN+xiOXATEhhwIjWFfp9Sg2rGi52JhXCSEs1drFOFumDPIXDZC6+G2WOektpPyO
i6dn0HVNiNSIxy+HTKYNDCQPMQlC3ShTTA8BqebYkJNMrAiTaYGVgw2KTt02MTBRymWWED2eBMPS
4iKeRpdaRtwckJheqQ3VqaQnwBWg0MqdqSsxPJUNZDz8JFwaEbRzCcEUfInJMj2NtnQ8G3OSQwN/
DJuGviUfkYb+GUNfvw4G2iinkU2IcZtSwsHD+A6N/oQyDyhDQLCEs5G8HJcHJMHHxbjGnnJmMjux
fI0djbOBh+y1fDTZwhNtGDTHFNxsmcH6G/kTryT7rYXC6PFoSiaH/gyriTpnC2Fr6ghtx9DJuljP
AvUgwVzGabdyY59iXJmCWHyQtqOvhrBscwIdBDaiRiE8H1CY6HIbWhPHYxxTm0Mzv6M21yjq6cC0
nUUJWsUK8Ql+c7pnfbFMBWtB/wASY0o23swzoczNsQ5duTFMSoltlM5LLCLBMuoSr9KCp5vsy4lg
btC5YH8ZE9iy2tZp60qIdeEkcjG2bh2hLuStCVNsQ0x6iRTY5WI0GVSlfoYkoYewtj/g1A+PxoaA
a1MYt0YFTqjc5TI8p1WTQuI/heMpqeDx80NbZMZjqK0a1kvLHvKcmNc56IJcuUXl5VvgZQ1KVHM4
uRxJC/QGPlbAwuhsRUKxouXyLOM9jP7iMFvYTAkM/Pgtz2IElxFJDP3KBWLLHcnS5Yiax3oSxzW7
kTD4BHMegxYSVOG6hUez4IcNUgh6znDng5u7cfhQtjO6lkAX9CE0BtzwceioPOzsp/8ARgwVo81b
KHtZn+3AASaNmFr8/wDs09UJNibn9KFcD2rcnlEdB7hUhUCA6QzzqwQluLMJLXFX7CPxpQjqKsg4
JfaIh1q4Y9lmuw+F1o9kVrVOaNeentiQx3ltF0ZoIMrVPXofEua4IOKshkoRaIwNYK6iKtxP2XBz
TwhFeG+RnVqqIsZjYaMWNvy2I0cnlItiNzgSwwqWRWHwJjsEoamvRIiMavw+viipNZMPJeAsjx9m
gk0JZNnBxIJoK038uEZZJBaNoLDHsldZRiiHg5NCQm/hbOTkexoWS7FoxTTGsGlF8GoZbIMe/gyZ
G2WLyWCFKSNBqslOTXwfKP4FrBfsb6Fo/kYl+HRC8coWtmmRemNmMiRk9dCwapSQlWwhuo8sjiy9
j2lNizaGveYLztN8mKxZMdZQemhh7HT4qYfIM5jePjWexrY8jEFyJ/CiVMsioLDIhzeyFr+Uy/6K
xrtwJXK6mgMk4iQJgCWFp8i6vJDvTaZSkbmjzIyi2wUZaPiBHbDqiHaciweS2RS4CxhOWy9QFtlA
+8b4Y/TSPaGpmZCV2XyVwNIRYil4Fd9lvRc0qwR628Douyw/YF6hWUVnLTEbu8soCJYSQ2rT8ipf
QJuLoc0mnZbtKmCHtMJk9lrkTZ/CEl0VsUslgkVpFr01KJ82w2JVlOC4C6QpPDkvFnYoUCGaIH8I
FCA6eXZ/5/I+4bH9C5TJBj2Uhm3A6bY7aIfDsMxbjEL825ph1cejMTyIkiwFNENccjm+qClTyicS
OB+s8EIjW6ZLv9FIdbS0QqG3w2OCJ99HfMmhRanosi4nk2J2RWA8eXVeiunZmY7H8BApNPFkUmaP
kiFljNjIJU2qXkWo0TWjIqHoeBmpH0M2QPiDnbz6DExteE9odSRNYrezrNyD8vPYnYzPc0dMaciu
cCQdILQm3nIrX8P/ACLbKTtHZ6PwJjO+Qxh6ZHAY3U2JulhaP+sSJKbrBiTocbSFp4NMPMkNE9UJ
TeNFUUG+i1zFNsaoaniOOD6Oi8+xaUtFLs6V2rjPkemxo9II6nH2VfthJ6NBfclUaWats3dJnk2G
OGaN7A3CjegcWY6VJbCCWhGbK6oi75PgxAB0ZY3No36C07ZwvZAY0Z7F8DQYTJhgayew10IcBsuz
jRcm2WDTejKignRwYPAiGChkM2+H4EwIJnI2PQsDzo2EzkZtDkfxvRhwJj0XBhi0WFz/APhILY0N
mAw61szBKIojb2YnktOAscXw2cE9BjYyZ6GWYQHGkQWBN2XT4OKIGsl8hci/keBMSHHRs5FyQR1R
gQcyQ/KARx6nA1MlQc147NLVISpK1Cc9GuhcsNUIe9oUgys6PbMj2GDE4OvHw1X8EsGGRXYQrdAQ
xdjI3VHDKTQnOjpOBUmFG4OtNeAQ0LwKlc5mqlsUmKhfRN5G8/IsvJc8mFcLwXWHgfII+0YGr6WC
jPXZUjgQn9jQ4+YI8TIECQWUwRpl9iheOXyRtJb6Ga2cJlywgAjSH/GpnJuqYQpFfnsbnbyKbXnh
iBGrsSFfJM9pBhDgmXU4nczbJb9mJi77IclsoUm+BVia8Iiun5Q++UTKVRtthgo2kdojL8PZmVhd
yR+EyIMMWC8D10nQcX1jsq5eiLgmDFdudDOmwvhvucw0jocYjTSowRp7Zfp3kWcojiizHsCU4+Ry
UHRoxSetDOgr3syK6vQ76/cHaD6TEc/t6HjcuZ2t26GSSrwTtHx0QH5gFkB8njmIyPtIyhq/pxg0
Rdxjw63Q22hMdzJ/56ZlYb0KM5TbYYhm17+xkJfSmAniJ9jDqrTYQSD2FHkqZekdoR2l7GtTh3ht
9tmWBIhcSF5rsjrozGhnL8mPNOYJW2btiVV08HqZezJuPthib2Izq4IrCdB4CIPsG8jjCvbyJHCO
6Ld17Q21YvAqo2pdUlhjfIf5g4ThNM32P4XKOuvs3Ts72Mxl5qGg00y2seSwk/v7CezgZCWy6/XI
RuvsKOB25MlGUU4Ee3qj70EZr+DDeSY8j4FAmdDyTyKREUbot0olnJ6LBuiR4Fomfg2dDQl+HJkn
w5GsnAxOETQnQtHA8CsGJM2PY7oWh6F4G+RwZQfItH+nD7GhY2NxlwcC0/jqKHgQaMQpHjkqCdY4
VCZhlmh6HOx6NLYgc3Mjdbmx2BkzP9oe6ZeUbIIX0SorJxpuHE67EtQVlU6J6y8wZ9jGaypS5LA7
BBjZY+FqzYfM+OxcilNDiG1DLkWHsS0WfAnun0P0KQlBDHeBKmqRjnAT2Gh9SfhYmguq2jEN4vKF
r09ITlfoJlvTEPRV4H38sn4V6HW/yKK7IawfQloohI7+haE/5Pyig/wQ+RkTezdg1iDc0/Bmlh0O
zOeBTbVe0KovwVeHoXrV3DQ0n1BpGBs9BkIpsZI0vAf6MGuqXEQmqJ6MlM8CBsnA9h+CuGB2qZjR
kbBQcaLK5QsSLoext0RXKzrbMaWuB40nQ1NMEUe2UFKJ+hSspYRhWw0hVVEh0oGqW3g0GRb4yrRi
WDcmDkSOpoDVOamB/eTeWiLeMNUsqSMIciE9Id49hnNCDJsjG0W5hnW2bMU+CBbgo1lCvQ6E8wWp
W9oz3v3WXbeDoO3b9E3sMmx+ENbeSngjk5gQy3HaWZ4MNehGxSSywLS98DxO9UbnncaGLqWCVlpW
Q3MoXVmm4JJC44FK1oyQo4FxBjt+4X26XoPHvHI8V1YSg1NZRkwFDqRYhXJhr+paTQeaGOOwV8fX
RJFZuURRaD2ymDPEy8tbIy38eAuLHCTg8JhDLlBkwhNkYtyhkUpxQmyeT7NYOSnpCDTR7ENo6RCJ
lboM7K0jqGbvOCU6EsCZNcCa7OS18DI1MuRiR4fCHgQagmN5x8I9GWJPY0LKEsUTG8mWPCpvQ6zo
NcoaYYzwMSybGoaORpipkIQvAyhrI0cQ2LyYHeBowjMiwyNfLCUx8LfxsdDNDNeDPgatQqmB5W8j
SYJ0ZjDliJUajEX9BEUivRhuG43CAkTFrtWja1JBiw1Gk1t0NIapRcRUqCpISvKUEpgl9ZVEiUaM
AnZWNw5F8rUSFkNxlYjbPJDqFRSxsZXQ4gzLvksko2K54vwVSp7RmFYyhbazgrKhvbFvsD+nYOZ8
B4/oXiYq0WJUSeafEx9yQoDRPtowu2ag9Ex4Gaim6MKE8JZGxItuF9CdQw+MJYsDHmGJ2K79CxPO
Q1prZLZaK0kDEYJa/hA0JKnND8BpEjnXVROkycvKNOvoTOZkzR+VjLeckXFXwMgT2GVpxEWFyMrM
cXdrsZUKJoyl0PIwH7s8GThmdS2tFBYLfsAXCYzImxr4iQxT/gHPVZKxcHlik32K0zxvo3BFApR+
ej3IXkHNhnODPVdIWE+QtDE8sQGTmSUSfQsW6EztVo/4RIqYGXGGwAHoqaw8GQNsnYtZdjfAwbPp
CFg8cCTQnRmBW/xHn2c1yVmXIiUIWL2OUpi8jGVIlehdp05Cqs4tcm8FKkyJXCnoVCjcHPCtdIeK
+ELto4ENKy6niDkWTtLPsWZNoyMYBrDARR1kbf36IcTZEn/oyNTyEH47klPhdaLxlYJ7FMYy+h5V
MxC4lbnlmxJHHI98uP0R2S6oxGpK8mSxnkxxsD0nBflOgecLleBPK/JsfJ7tbSEOsJs9ikzx2mIy
nh4GOuVpjOcpjqL0qLicByxYp3OYO/YlLHaDZPKNTX5KEFYUMUuF8BquIWIbfXl0Y626hcXx/wAD
2Em5dCEpfKQg+GviMdjBF+zeYE2cGg3Y6SSgNQLTbY0LBPIlYFv4RL2YpM4OCs28nGxog5YykGok
UpYam/luifxsWGN8F8LBz8aJoZWi3FGMQyjYWTk9BmhlwZoqZjbFIUg1X6HoYCJ8NY8i0P4Vxkz7
GWHIngbM8fpmYHs7ETFqDdvAhNbwPeeIz2KK7+8UTqRTuhsbcy8C2mmFjUc0PU3EEpkTVJRJ4P6h
Fh4Y97KJWqH3Mija2ciD9jQWuoiZGWGGyOlGne2hOPKFveuiVuie6ahnOvwyaoCQg12HB+8XcD8G
JoMMBqnsW4J/DEoCXgW9T0pTwjJKQeh+QPLavIrYYV5UkDC2dmGIrgeE8+RTZnYU4WxSXNX1SSre
VRSk04J5BQXDk3Rll2MoEBKjehLjQx9AlFSIKg5ixliJ03WT4rGJftNjTL+Yp7e5RfzG5Wx6v+gW
xjpUhuiT6YtZpxohm1oWBOaKHqEw86GAVAsLgolzWxpRnAqj3AT6FKmP6Yo5uycPUx8RmMoMlXpM
avtPhOZJIxc/GN/CHHmU9KMX0mPVMhjzRbMXEv8A6XwEmctozJOINY7SzQxN0cZyUONpZPEA2N2g
ry5yJb4XkR2ZnSjo5MTLfZEInL8DvcNh/g1vOQxGEZLFR4wKb6YQ584JBZ6Jouy3D7bQ5qaWUINW
3G9nJiBcjBusQ6K+v/oQgcjFZ8BYqkrRmabMeuMYNCkbHjuJu0dGqemK7BjF/wBHI2uvWweQJCZq
9grdVsZISqwRNLbQ7oaxts42TB7kvDkotIiGCCVZZY3foL0NTZvbY8UjVbwb8uRPYiZP7C3PJMh3
XXiWy8DW42/WTTo+Y6Ywo4MbpkTL6tkmHvlR4l0Vo+8tuEbRYkWLWsj98bX+IuZxOxWeGfIWb5d+
hEPeiMeeaS6CEuywBjguTfwNlnxdPItwe1CiW3w0L2QaHYsI6C8kNDaNjNG3glQ04ZXgTFOPklXx
PhY2QdfC8lQ5NkgzTBHRMh7Mv58l3HmNCPBPhK/jkexlB8C4ZaxMsIFzMs8ku8jWE7NBKNTk47Gx
3ItiM02SVtRI2ORi1yLSpJIUwkWdmEs8DVrtBPGr4ajncIh16MFM+wz9IFTRbHrOgx9dHO0yLgpt
iUXkWjAXkXfwuUI6GL+m+8sf3CEPVeBkyG5Nn+WFck1WBsr+xihxGYeytWlcJiUNFkbp8iTRTZ04
gyNY2aVVOFfn/graklkd6BliUcDpsgSsK9GDlrIo6q4LUktKH7kw2zaE5jGWBQqYzo75Q7rNCNiB
t6CCiRTVjJt6Po5oLtqzY1HaUeystH88T0I1MiNSd2iLGx0mQH4hSmHst/6PRKo1qkzGI2GoXirk
McqcbwPoZ5ZEkCWpE/yFyeHoUxwBJzknMYQo3yG+mXSeQs1Fi2ikWZVCzcK5PwxTfxInzy4J1H2q
O3D6JRSUJVLmDVijOjFwduTGdzcIOokLfmbGSe5JDssy/wBPDIiJb1Lp7QVzBz5cSxVhPPLJrBME
G1W502O+wlZXYvHOzwVjGLc2FuDoFYbRagtNmjMy+wihVWhJ97lxO1FNL/gibbUbcPYIJWEQxm1g
7xx23yNdGPjlHKcZ5voKoIErbDnAtC8LKV8lnAbsmJtF+x6o1jRTIah/6GIOsM01MuNXkN0J2C5J
Xsa1bQrSNF2NRwuoTKTLHi7L5jSEcMd/wsroDU5KmKTnKL/phNL0hjpSgmkrqOhYJYaq59BCW1SO
REPb6GVpuUMpM30lwMeZRWOAzJv6FvKvIppDSfgYgVvB7Gl9igi7N4/NSFmwiI33MkPB4Gx9HM2L
+EQaZP0acptE2HUzAg2+CCiZYmeAg3pwNQTGyM5JL8bUFhwfX4HsWWjkkGbGpyN0WV6OCU2zkzSP
4SwclNiYeBZZVLEPnkapMCX4Z9CbWTIauEo8My+EuxiUg8Y+JlX4ZtERVptcfHDpYTGujFRpoMq0
EU8GhmjSjEzCyJX1kyFJXkyV7aeWV2MDu1W2DVgkTrTQtk8UQtxgwpW/i5Bsd5lIzGU0NHQ2h6PJ
wTyciaYw7iwFpU8C+1XQibcCutgwU55Yj8ymiFnHRgCjGR24DeCfKoyIpXYz8KQlvJNi+tTChcxe
xGaGwmgpq+OAyFXzRxxO44FLkCOw3higl97AlydyGBT7E1yuxGtHpsw29IGn77YQo5F3yvLIxPUN
Zoi7TXtCS8pcnVg6Zj5jsQglojGG2zDTGxGyxepyXYUE4lqjzr7KQwwts4m8jmJ5I0KW0xbi6uTF
ACDZW0xVpdMdJR9joP6BqmyGW7CnnJ5WN0OLuqTkzVU2PJmUbgo3S2NDiXQ0GL8creh3wGJoz8Jv
ZWzGqPZi7ZCQ4TCZkDeWN4nVRwLaww0XX8SfkP0Mdu7qG2Q0I8kKQcpJijKJzIldNlBH1mhhZWRA
vDDNQBZohhEO/NJx9CikqwN+yYXZFg+wf7jFgqvO0YptXPBofZBtSZZ9GUrVDTCcDdYV0Tnzoxwx
PIvfj+DUgxtkIzXaYt2hRgNr2yHjUINvpRDKljzXBJHqUmXUBtJrIERynIhTSzYa7bbE1kUUrJyN
KM1LpIRV7lb5FyqlriiExObDK7ss8imwUb0JyCAldMpRtt8lfk6zmjG0y0sHvIX7brfBT2zdGKsg
bFDdmOU8fQkgMrTtJjIMunOh8TMVDdDyYIMvkcs+gkI9WeJ8GphcnjFocOK2IDJlMkO5al0Pq1nI
4VKpXAiUYewbaN29FSdvQkrbplt7bMkO3sxMSwTO/jg+FbRpFz8TBejXsWNiNlHAsGSolyQnA1Ba
NGYL7G1RJkrok1kd7HkS7NMaGhckHgQ1RoWcE+JRJjRjYm2jTyKmZIXJsbi+F7PBmhQSrr4Ro2No
N0LK+M/DSwNIZQWjLXQnAb7FI10OYmRyqPfkS3fqQfRmwmz/ANMMz8TdCBYBDv8AY3bUV2Yae+An
1jmFv+5CTwrB2KIZRay7NFOUy/DUOBZCFi88COvroUffhN2zDRhEHSMduu2K4Q8JiheoDarWJn6S
/iFVO35YnJNl2hvG32FrY+Rt+xIYYXwMEXoMoD6mCY+wOY/6IP5yGN23VHtgVn9vnwi9twM2Colm
MeD2O9TCt+mGlZP2zbj9kFEkN5eTWgbzT/RlZO02Ms1+Q7jgorwPLeSIWUT/AHVKd/sW2bDPp56F
fb9HgWxD3kyCUZnV0LuqhEVE9saWIyOcCRuT7HTqEyehMyL0UDPSHgI+Il5g3OTAivQreKS43eej
rDmi/BipSE+EooXgK8OkOzp+kSs8BDGmpDMCWuncGyS8FPaqE7WQteQosV0hyHWlIMiBEXzI76En
bjyhg8eFRJ41w0NYl1o40uIlZQ+NPsNgZRJrk8DhqeRg5FDj/hikslUUngcouCaHLRAz7Ec0WExN
dJDn0AHFEqZExpXlI3ibzDBYS5QmaawWvw0hrh1ZGh5Rr4D7LYxoaosMZXRp5HDHB8TKMxYZLkbj
IYlsrRyGTobMpvwXI6tGQ4RkcDcMpeTFnLMmzQ7M2yZQbMsFyUXIyvkaiNIyrnHQqWDT+EiwuRo0
aFLcDWxPJe+ClHs1SDwsnnZzkRoYejU18IqMcZoXEMvhoTqG2ylPgbJGngSylwLBazBG4bXZAWYR
2lfgaMv4PT8ipQ/0v/8AB5JcidIxdYMxDMs8N0g4GklijzazkqAc4/aErkey4C48KokjZiKtzQjY
PQXGlvQ6RVXdGMk34g1B8WWDw8MdZRrIm1gdIJMpXaNWL1lEpgSyIOhK4IcyxJQeIMc8JDHy8KYi
xEgpD11QFjbaHyges7eSoU9iCkaLgQrwka+7ZRDQHViMp0Gl0WCzWMnDXPSLXrgT9zOmVYSRE+mJ
LDs3qh6lMmEBeAnjbt8nGRDcHOZKuS2WE3kSEFdmvihWspxsSKLRbCkSM8x0W1gpqwSZjA3RwtMO
GAqy34EjCjKOpCeB1kcQHSEtujjz2Wgd6INvIwLx7GNdoyWOvUC0OJwPiyNkY5ImoOGgsdB4zeB3
MnlETsDUSyWk9xYxrkvsbUlCMegUZIy6oMtYMEmz8DOKR3ZdgrYacgn6IcDQJB7u+TFmtZGePwZd
aMvTawYpJm9DFBxdiLc8IQfsJ1QEu5hiv8GwlgjRu8HhyVCEuk69aFmtMz9UZwS/Tg5C11TkmM5G
gwBntWSWyWY96zFXsv2vnAnmXBahKZa2xurvBttbgYJaThIar0QYVEgf1UXD+CDpXqoLMaaxXK5I
IK7meDaQDDqyMX8OivSDp5NuBSadaRRPThTG5gjY0Njb4W5wfwsH9GUZZO3wrTYjJSXwGxPRaKyY
+CIIcDbpmseDn8eCE0yGhMNIwNiVGRMwEuzIrKOVkmCVH8OJCVRCLgfY40aGmhPBORvMIEyCrwJP
gbyi8/FJzyJUW4NImC4G3JTAT+3xSJZ+SYLj41MsGAe6bY2x4FITMg5MdE/oswfp8H8BrsJL7LTF
wjdsU0zszidUsx45DaVWqJjuw34JT00A5D54G9rb+FlmUflCIo05FrdKjgt9RsBozS9ZfBAPGxy4
MYJyUXEXRYLYiCVISO9ifOEczaoaJ5Y8y99CastsoiCJHpFbEWaIyQvgbdjnyuaiPYDaC8GRlLfA
pmMwqHi8j8oR5M3UF+YckSaawKvc8DndujuEicqVzsQ94OszVaC6WsrkV58CoygqRkiSeNAC1HbG
SeAYFb+jI222IoiveR36EFPc62tB+7Yr4Xx57TKZmEwy3TFaAhGVNGxiTZSpv8CrzeXBRdJSzohP
Xa4qMasdGSGnK0RzU9IbF25THtZTMjEQ5fY0/wDtseDyvQmxLhoOlV6Q11+hTVgtYdD1Pxexyd8m
I6ZK3OSbR+TbEeulSg/QjBCUv0Eek1sHWdxnDIWLljhKXtcEMOybFi1jjgljDWvoYhF2o2elij6U
G/zBojurZOCPCubwiAaXR4ZZmZLSGMXY2zUxlExQIkUUbK5bhtofROoSmwL0MVuUGJ1vYTlYjfsd
chYTlGGdefySrc67CcBMKKcgxl7sFCtRWYWiTtH2VcpOfIjrG6JkqrR4m+RbFPGfBoUKhP8AhG9R
mPgxjq00eiINwnlyKicrkUhTAkPpWnCrcsk+4+B9RDlnusuDBjCY3TueCNMQP4Z34SaFijwFVgeW
NmJsr0KCKF4//DYbHwFJ8XsQyhJ8Jkw2x9HQ6cC/hybOBqkJieTT4uB4XwYokJXYkpizgWhrI8iw
wj0JjXw2LGeTT8Cwh4dF8ayL4p5LccnQTw+xrA0eAkeGP4sMB6F5CfYhw5yWLsQPD+E4xtDAQTEr
7OjHxCOrJGjh5Gr2IHvF5W0O/wBi1xdM1VHmJda5aM/8tjZOjGZVgeZNMt/tKCCEm0MshSYn6Mqe
6LCTlnOSXhCjCcjVCDgloyQvQzWRk0LiPshB2PISLQVEpUcY6sCgtonlC+mswK9oymX2FA9o4KGB
FfGAmCuSUPrJi5GBCc7xePhLEJeBrXFwFSnNEyTGTJPIhiot1igkmLFbkmInUFxtzB6QQYYdm7Fi
31RfwYLtovL4Bm6q4I8wvRIPccPgyLqFUdhILPIV/NqFCEoXgbmGJ1F254ECknAmqIn6GMEfaFVV
6PI1SvGxe9KqDfb4xU68yIQiyZ1DSH8xiVszqWwwNltE32EWnnV0abkOvNUbXY8h9Pm4N/eDGBfa
SEKqngKGRVhj7QyOfKNfo9Pn8Tsmn0xzeS/6aP8A8Qc3t/2Yf/JgxwMRB/ugWxuvYK56Y6C5Yxjh
iEnYkekDLufGNjL0lOzLHI2ZLHgDFj2th+JXKNfZ/gxWaaxDCgk4Dlbn0Y/JYyhkqTJiHdN60uPg
7HuwxyX/APUMw0qh0mbrPkeJt6QrTtgMI5SC7WixZDJHQ+Odm0jm54i5WMMa1tMxAkuTHDKLuZPe
w8g8MtDWbLaQ1BcZjMI6HszWC4v78QQjtMA7BjcNG2PZtHB8EzkSaZoJb+E4PNfDy38uQyLENJo3
keyG8DWDLfwNBR5KDF45FmDQ0XwQyYlCiNtkMIuRvkgdfC8GvJk0QOp4OSYYxYKMIucfEIYabfgS
+DWBth07U2F8ODQ6Gs+ERlonSZTMhgQvZUMS9bJnZgk9lWfETqYrbMGPGQ3lMxuaM6EPESeSaq2y
DLyKkciqjAeWkr0FIGhCLwMlMcxti4voUx0nwKoZIPIg1+FeNgKU5bEVtse30Yh4iHhiVZCD38JD
C+ewEbdF/hII50ZPaPp92FtwLsYxyooLLA9L7LK6csckhzriskywhnGMGUYTfyoy/lIu2ovDeSLv
qgza0F3qdI6GhdYLobKa2S7JaM/yZcgpcDi2hPgzow5sWW6mn6GJwsNytFyGBhCQNN4vwe6N3yzT
O7RGnA6smBnB8VH2uBVGs6xLVmAhKPA1O0m26ZFl3fhhDwsvaMbByYT4GCbSZTZABEJGlpoXpYJd
B9EqN7JDQ0WRqbOrPJPAy7V+WMagllMU7idVmaLoSzLDMK9oz+obtGaFskqwZRHNDVwZyWgbOYnX
cSQhdUnwOZfANOqPaMjgqGC80pnqWChs59mFAUaGtxgxfPndiCmyqUUeEM7EAV5MdLgWOAxWbir0
MdRYuKFsShVoQ4M1ZTYPkeAnRG0ICbCMBUeeDXGE8UccJ714KnT3JU6hdDogzIozeMuERm3tvLYo
Wafbui+TTXkRlarlFYuM9INVlK6XIXamIiQeCZrOBW2d5ORbJBFkeGOXY0VjvRhJMod1pwrQxsxH
cbgT78xjfRSfCQ/gnUZexbN/EnyKPBgiCWdGpIS4xrNGqRLWx5Y3BpkQeDZILLHob+ERBoNtnBF6
G1DkcFmDNdhi0YM3TOj7+FsUOmA0VI5xsxC0iayVNk7MND2cdDKSsZIzXkXOB7fZwNGfhh5+GSEO
xLBsTArM/MrMTJl4ROxZYH8Ho0ootiX4YQkKXDGJ/RML4TJgyGsUTWvjaFkdmxdCrRXIbFpYuz0E
Yewt9jpMmjFoYTN88OP1wssVCR4BoSMK5E2Sn5JRtdsZaWLrsMVa+Y5W1WIKDTgPPNwOpsbrLB0P
/wDANc8/EgtEmTzOElCRnRt8BSzO2RtlhogIlqMW8COwfikR52MdGot2ECVX0qZ0voxtW6k2Pw4d
jFELiiMAodSEiInUcBq7RZc5EFROiJf6F3qAnSESyu+x0bPJXaTyLdhnYAyt6mLi6etFMa6pSRuV
RPweWMW9yM1elHJKl8Njmh5JnIyeSOBZwcqjG62aQzWmRkLyKzI8h4Ft4Niwpksjle6LQ3ndivTX
I8J4m0csYhCMDo4Qi3WUR4HzHwJkmhWkm5OQQuAnJPMHOVYlxoSU6siiO8Qf31zpyNUYvVmhu6Rj
6OIjWxE4fBTz5jGyJ6IpLJOSXeAMnqUSyxZyW/MC/qBpnEY2tHsUSaSjgdNoKyEmnnQk7dFWfYmO
JcQd3Q7FlHQh/PysEzqNxbFBHa6GM5YXRVPYYJYJbti5xZgd2Twhozfl5JzxB7j8EXatA4q6eUbS
HtCU2D2KYD6BN4OFnz8h5diZ1EsIUbikmPpFd/oIMxPYZh3cmTBK7TDr50Yg6CXwggkxi0ieqwPJ
NegMvu8DX0Xg2RyLCDniG+VfAfNMpB/BiciUWzSZM4Nvi2hbMI0hOjQQ4pkxs0ZZJB4aHYYbG0hH
ouefkbSHCFRPZkaYjHxgb4Iq7GsQVnxSaGxaN04liFkyUaEkGn8HgfAeEjDRx8RSmWjAN/DyGtD2
NwN3JkzIdA0NfDTJ+mhqs7QsMeUJXk0xMNcjG4Qm8lfZXLPQraNBWXj5DThgGbcqBOib8DdsWdHc
x0M+GJMyrGNbLmb0Gqf8GwEvRXdTwX4jYs2e0QK54JrJRE18Co21B6XI3nCFbyVEx5fxWkMz2L7B
i4wy+jUo818KWJTOJEIFWKb/AFLWIMeVd0LVcf79xuK6I30INjQfFoKtGvRxKKauxWx19GVNPAnc
El1j0Rg/5GtD6+KENLA3F+xPVOCnq9oQX27oWGl7HuBjySQt08ocgfQ/zH0LiLLwJCp1Upsdomsa
0KZ9OEJQa+xAOfGRp7fgtvf0LB8hJTQ/r4VYmnodAdByVaMkZu+UK6INrZYE81IMCY44VIb6FVkY
wIqBcFmMGmMUK2pHS09CkLFhPkW+uGWDnxS1wxS0MTidwOSsaaFCUleTFihYrfZU8CzgSaojG4Tx
5O/R1FPGi28DYYC7ZTYgjeYiEPRJkeqE7Y9tCo5KuDAv1hrP1GuhwxrZixKIQDcTG6MUnjvQjsb8
CzpxjWqKy4aBGtTIXmDxBydMbVMjmEjyKymjPlCbTlwRNuG4jDRyLyLZpmxkTY2eAoKuns6Yb8NM
tCfCZatD3Bq0tsR1PbaMn2kCCDfCFdRtGPtGcMDRaTI40hrJhwTIo1j4SkOPJb8VRujGOuRbCFOj
+CQzDgWGYHrFhkZJj4agmG6JGvZUZGCFXgNRkryJDYpz8NiWRsOXkavw8+BOiVGoISrZwHo0t7Es
7+GbY8CwaMYQnSZRnIx/o9iWaPZMXsSyEqhDRYYEMfj5MsmRsaCabhIZqbuUYyLibY95O8CjJDDb
OYrLHMHaSyJroszAtNj2idZciAQITKdhbRrTErlAY7ZlCInt/CFjyLsTQSBD2KJ6OxgKkKLZkS1c
HFnDRv6aQpLyKqwrhc8CehVAiSbb0YSGdCoRUX7K0GsyMEeAVqknlBPbZPBOQ1whrBj1RfhegzaY
ZspVgku4mBFYuVrYhOk1TNDFUJxWhRamhYErsYVYvCRUv+RWsZiZL3Sf0wDzUxcrsHiCxhks+CRS
UNsiSrEnDThJiwsm25EPi1EJhdtELZJI8tExAs4mI1Qyuehu8HSCBWZ4CGzNjli3NH0LzSCmNHME
p5L6HFv6LsOPhC8U6QyoWOUOCpxMRJwf5OHpBs2km3BuXrIuJktvA+RshCPYXh43yMlLc0gZOhJc
F5gxWNC9mGQt2+PYmmi/pk6mDIWSsKiEHwiWkoPXHpT4yE3foNUiGMMHRhqsM9D8IdmbgyMSSDEm
j004N6kBpioXG3XBafdFyeFQFqQClMMtZg5eDMU5DMvScEhsOnyEDlXCDwQcyu7HsaRonsXk8EPQ
44ocawaFV/ohGw5lgSbTfki5kptOThQbr4PGzYw9ITlcrfZZiLQJ0JeeBLS1RFMUoFFCDEEzo1bw
O6c5DzJTSTCGZpMx05FVWYJkFvqECaRK/LFujUMPaJYuDYKRisybsq6GWIIw5OahoYDK2H0LL8CZ
OBMqJWNNiZb+GFeS29jCGo/mLCDKGxrIUCC2LY8hJ7OIaTBaLeRp5yONIgzwJOHIvYtnPxWBvg15
FsdWR5Q1EINUKgpfDN+C5K0934YtaGFNCUHwFhTZhnA1kzZwY+htJ/C4GqZGAjmHsai38Fg8hTPg
b4M4dCUr4H+hCuReBgcsizojj/B+zzRXVLaDkWnJUeRmUOEz+qG6kmOKPhYfkWm0jP2B6pbrHEd9
BHU2j6YlHJjWcDUSTQtjDZLn4YNC5Iua+VGLXPGTyQi+PQdfEiOCgcuNoU24GbCCNXbYnhl8eYhM
yt0kMoHMuLkm/wCDdbyKCYml51t8ErKquR5NTpnPYhWPdZZOaFUMRkoJBtYovM2xCyMGqTdAxF2L
Y5rMn9T7Fjc+RRejyIoKcla0WnpYjzg5mryV0sY+PpKVic3uRQifGDBYJNyu3Ki8qX6TQnQkyXjX
uCtIwYvOHRmmCi7P49GRVxMMitYYGv8AgULgwL5Rl1i0eC9xwyHgZDcUCWqbQY+VPaRDUWmv8Fkz
AoMW5eiFIR7IUhZ2Nk3tCKr4gwMjZgtuCqDcq1VfRvMbKshkISTZbF6jbPZCtA6XQjpyXgtEgV/R
i+lSgd5sgmaiQPO+gZDOH9Cs0rg3YpZcpmvq2Ojb+oLzpvSpVJuDkHNXi8DCZE0/JgbPq+inBLId
qjr2cs8kS3UqcL0RbzXR/wCqBWOUiQcIR+ipCQkOSQVm7Byb0hjPCqPLqD7ixTS6IkoXSCYtzhJC
zFNNyhTp43diozXIjHJCS7+h/ftUKdJRWUkWmkP34F2OkmmkFUMtjD4Es+B+xfAv0bCd/Cxi4+GL
ooPISaGq6KJX5c5+PImDiDdiWRkQax5KMBKkDwTHksFyOw0ibP8Afm9jVkM0J4zs0xNkJrPwol8H
AvoPhsTj+Gvg6YZv2TWcmw8vg4yW2D0kVJapgNMdvh+jhjCyHhFGSiwJjZX9CwoysgmCNdHCEsQ8
oJCtEvy+B9Mx8ZOWxt4nSUntOCDvUlXDHp1jrOB9GV6Dx0Qu9njoOfiqIRb5GDHlicHIshhd/HA9
CNGAtZog6SDkotHPwt31Q7ddhpDPJM1bWhtUgnlGqOpY+i2Snsf00QxdkYZFLAmmIBN9h/nLQcY3
HCusXc80jE+6H2ielgVzg53G1BqY3yJx6zDC860JDOKhiJRH7KZibFjZMOkneCNgTFFby2WDlWDX
V5iGkdp+ULZ1bD5YPZRqZrEMcSYYw6Q0haaxodtCKKoclvgyHj7eB0Da2ymrLjSZTJ04pk5rkQkp
n2xCKG3KGN1BVROwhonXOKNtivAbW8dnqig/8aq2PyuXD48yFXGOQgwlRQbLXGR2hFkdwwLneBA3
minoSXlodMjyH8YjNi9wR6aGtyhD72l/hwRNSInZ55Za00iB6uRMyhwzXMbmBjmlhFMpLVDOtFi3
ig+MjKPAm1VRG7JyekWPaCRYbaMXzo+WPD1hZ57H0ViZ5FA2wfsutwuwuA5oNnyZ2IfIM7EiEIJx
kEgSIUhaF0O6shKei0+ib1Tol4JYocCt2ORouGH5BKwUWdmKqyyfgU3LmH9F1W2jEwOpkXy4WYNr
lGInNx+BbNkdUncppyJWQ5qcITJ5MREiEuY/0T4aaRcCTPt/AdJj83gzE/QCCcBBTREjhSZ+KTe4
i8zfnYSPI3SYeBUxutEyJF2OyQq+BMFphSPgvQo5+ImMIlPmCsLIcLyNO4N+x42JHkf9NoQN4c+G
UI0vi3gWWZNDKO6Qzmjy6QSz4ET+BL9EsZJR5FaZMnMENhMez4GlolZN02cMjwRRy+yRR7Mmir4L
WOBwQuQy5wYTIqJrn4jdnwLZsfgNiOGmRzHxkHhZMx+RspHQhHBNPWyaM05MWVjBdlE2bjNuai7E
Yodp41tlSj5BSBWiMwYTeTAmrwZ4WVBMVgvwQTeRCs5S3GgVeQXCbJnMuxEO0sVD3Kv4G+9Gx0jU
NCjTvkg1k0XI1ppKJ0blGJV2JHRoQfaC+rcE2s6iVUsZUdqqSWmbCdhdwm85yPQdx2bIsZKTZQwD
UYZWSyjREnbERzm09j6bTfWRJaN8GL1B9xoneLJJigqC3AiexBqUa6YsSInI2UCvURxhrnklKJj2
8QmghCqUkGC+WYxY3uKPuE+ga9AtIKlhYYZEb0Ww3qlxNCqU2DdIjFCRYvOWNBEeItkEFcMdslvL
iEil+o+jvDwISQ4ajqSYuKVww1JBYnBrRCol1N0x19OPjehias4yYizNgrEtaERLZ0pIDxXIYjI3
ovNEBUBxzgqLnXn8ZwWI35yccDCYJEi/Cg9+c1glYu4hGvmzqi85WWC6j1gMeOA9TvkPmiR96N/4
0xj12EtIZyzjgP7FQp8sX5iYPvgRYPbmiMju1Q2xbz6F3zdHvVfQutsE0KIt1GhsQ8vgsmdN+1jY
GBmReazfcWOcmDPZdhEAaM0O9znkJ/O89uBy5Gh8iA8U8C4Nyt/FIO93pjwjvFG7d3qEUUsjbJ7F
zml6YLSNTY525WbYnnRRbvKpMhJvs/hIwVV5SFkYnOls4w0ZxJfsb5OJMi8ejmIqxdST0KymeyDH
7DPdyjQQHVXsxFaNdsq654XcJigh5aEuCLoXJkvJ1TLiDoYyOx8PieGEXREbPSGzIQbucDroRyGU
OhKfZk4fgl20jQNnJSiGjQWBE0ZBIzMtNsS4JBlMsbyN4MjZRmi15EGJRGyxmzYbr8DYdFqjD48i
TGImaUMqEx14GItNDJEnyazB+sG6e2RfFZkeWeUaSFTILEujkSclxhGTPY6rCO4yi6fQ98jB0dgT
yZFEyWYU1nRBqrtiig6fZXMfoSWScqn7MYhKeasYjF4Yqunz8LC+J6/ixXka2jSI4KokKVG2BXll
NvA7yHL2tDKRn2RnRuB9sr5LaKwmteSmRPQBhEr5MIMwrE6Qlh/iGYenJlyvYzMp7KXupsbftCxl
9DGghyyn9ZQnrLF7PfOUadqfkLI/qxKJfZi23aZhD7Rf6qDLV0bx7oKqm8lSyB9syafw2NbwAZyk
8jfwhUv2B4lB8A9MYJJ2Osd6Hhsw7rxNibS2kzEyU+zaDfoxkL4Ou/sWYicCm6SE1lemx2pCQPTx
8BLrWNDCHnZgWHGZeTFMXkor0LsGhsaylFDrJPo6n+CDqDU2J8CHgS9CDCyO1lkRqlXRNpECmEZg
dSfoapdDpQ4o/odpdLVQmLy8KDTqGfUjw8YPWJFsGstjVsEOMMwELDSZMRQadH9CSrUMWClmbFJt
bJTgSVKODXSloiZTGjPueoWS7wM1y+Fm5kUcFH4GAK6EvjXQpMRlzQtJ6HYYcxCmkq2aXvAoo1ZI
cqE8iV5Yn3yWnDNIZNQwBThjKDFWHh1GjCGHBfhZZzafaElkuxUmfUPbdyY0Kf8A4GWj0gqtqKxi
FWhKoyYWSM4PGhqIFXRjbq8FeINWd/E/jfQ2uopuGIV4UbCnKWxtPCof1U9JFOdwbTEpXUVqqrwP
LjCyWdBeEKzeS5GolZvQlLybZJWNfvwsko8tmxAxcCHnRr4bDDTWhPg02JdjZ8GkPGTDWdiWD/gx
SGUGohsoZz2f4OjYoRzUwNqDbkMo2VNvB/Bngreh4F8It+GuR6fI/wCinsQgwQPD18YNiWWxuA3p
inJyfDIsKGXISFUHNoZLlGMWcoygxAUHfYUzRLyTgZiUYiLossV6FsaQhywDQ9i62cIfSGpMWGT4
eBrklWyT5kExRKs+xCUcqI9RCy08BWwLlF/DhoWWPglhMYyigjAHtUVVyKYh5IQjJeRtBGAxliLX
BwYOwhiFLnI5xTwt8Ck1LF0NDn0VGnwIPvIgK7jDElPIWS3k7XZy/wCCYb7+sM1naLg4PJFt5OJC
snMISWnzobha6TZXSNcEFTXovgzkuJVnwYotMe6DNsGC368watv+kkF0HqQfoWdtwQ0Pt7InIL2B
xBIRH5GaA4HOlXKKbyOAUmzYwFzZw2i1Ln6O54M/FDHYyOYNxFz8eNCdpQXLgabwU0Tj3YwKq3pE
FE258IFbmHPF9DrlweRvwM8xe0cYP0LvpDA86vYbZR4FCOkM1IuWX6hVMrCnLVstoXy1mYMZd0h+
KTVyZrH0QZJ8Am2TARYS8k69OjE451gpFW67IzeMy+Rx5WGVNrwVYT00PyE5Y9MtpUaE/gMJMbwQ
SqmuTViDFfsalFNwD4mNdkiyESMWG9wm3wGFMWGkJLSEQ8+T0byzLHrgY9XKuiDkggK4yGxJzC5H
bSSvRj8nWbZJ0ZHIjPl+FJaRWoTc09DI3fqIg3gJvBiBKXSMAWZFq5jxKV6nEvA7KzQve4DSGXSJ
IVk30PEFa9DuFGybDIYt9Bt1IuuBZR2/gcdUnnXBjV0zCDpMTkTTtp97EtRqkT4Ew720iwi8BoIe
hDxAtlrbE7UMxmi11mx0Q/kU2z2L2dDLpm0pMSjG4xcj2iGNWPnBUJk4MBfowYmNcIsKrZsadISY
62ISeTLlMOrYnPJa58bFjAnVEP8AR5g9fB7HkdonksEk0JfBRDxg0Gm+fjJfB8hGNnBB/htwVESL
RTsdD+LmEJxtEFbjz6LUzj4KeE4M1HPYktyMsHcCCTOhgwcDlJey1wI2ihLNfosSrB3PlkWnlnNY
FoQRwz2uJqDFtBCbtg9uAscNBIJQ2cjCl6EpsUMfwrBNjl4Ads6jIA/O6x/pm/EFaENNGGJeDHNs
n1FEIj56ZaVVn0cVUGaNC2Yro0OQi34vIiejciJbLiJi3xaaXaXJSZOYcmNwzQFGJEaTHss8nUxQ
SCy24EstvZOis4FiSXXAvjTLs2Q+SofmsGetuiYmMfYELCTNMWJp2Kgd5EaYmZnohwXKhumtHAhz
8OfLjeRFt+g2Z3YfhQMb9rXyYc8Kjk2eJke+tu2xXAthk9cSG4nJtsm6zW+x6aEeEmJUKd8scmp0
c5uFYhV00afkdpi6/wCHkMMsJSq2J8N0Zk0z1GnSt8i3e8exSixQZGtjWq3UGAy+XgwMxwnYQr/K
Cikc8hL/AImDVb8MyHirBH+vL2IWoVpci9zE+hyc8Jiy44ZDzPHsXHb1A1lS1EgcG+HHZRit6E2c
DLdSPHYlBTCGuRt8CknDHv4AhIk8bLKoKuBsQF9TkkXRuKeoOHAcvobDhipCe6VHmI78E9GGRFQa
nfkmR3ppg0XcSfHZA57wJhHhtLyKdKTEys5YF4M/VhKMC0DaQ4k/grYLAYXg3eLBPs8qRSNg5NDi
mifUsmGZdswpiVgWUTBXCQRkXK6E6bYST0LHMWHXs0K7UMuNXGPknlaxbJKs5ZY5uf4RxscFIU3g
Dp12bbLZwhMna52YMsHy13Y6qeBuU80Q987XXCNOOybfCf8AWTSwaYhwu45CCC41RjuavIgTw8iH
klgDNpb/APAnvGNGPwJbHZROeywVYbdHUXJXAlTHsdiyuFpHBgWPZK6NjyMDTfkbwK0c7kexOC5L
BNUTTY1kYTehOMZj3UZ+hKkHsvgnwko1yPkzcCcHnI3EJo3oVG0kcjeBTZBdliHZsaeBKZGpwKeR
lEz38UZTyJOCz6+HowRXvZmw4fyEjFSli1lOjtuaBjmIN4c3CUhhewzko9vi2Oxd5CpAJrqtnIy5
CQa5MK+CX4xGTA8/J4IYQ4Q3kQkIT9Iv9YyL7EptxB51wINEh4uBZATZ7QEeOUXVZ5hJ0NxPGiwz
+PAvhhDibDYlSRU3uE6F9rYZ6MnB0Xc8kTFzDx4rBik4eG9DVGzSlV3o4GVIvTnMIv8AS3scS4fs
ic+gKVNZXDFB0e8+NAe6Ryi2HwNR0jB5s8whXeLz9DNmTwfZwNk6DYjyOB2zL0WqnwVeWk4hRWxc
sxQfA2wTdokLqODVAYSzsxDSnyJoSAfoa3lfgtaAlpUDpYuSHNsdyyinpp1cjE95PYA/glmmon7H
WmP8HTEs0W8CxVwz+cWqxcl6ZmK+bkjpw8pINN9VwP2smYh/W/wfS+X/AL8OfmZsZGpOYwPjZ5T4
iK1zwiEm1LODMS4CHFnRSbwGV4Yy6H/uL7FXA0MXHmYC2WmU/EaPv/xEY3oIBJgr6LCby5fY0WHm
eBxfLqObEQNLLtYZj7ZTsfpRf1j4rzTCEBfpCgWhTNQP5f8AgxRptCDNSUNz1SLaeC6eg4LrGHBS
piqj5NaNleBFd0IwMymawuwzOLEOSqSINskChuVR9ozkXBYe+SeqEvBwiI3HkS090htdzLbv4O2l
LQm8opja1WVtFOY8pHFIt/EapFvCX2z7fInpyhWbcSjF84FtqYG9Kjp2xS0hijsSfqtf4aVPC0QV
/wDEJeYrUpudxlrwNPaorYn+BgQlEPco3l+hs5ucjyzkY6hh8fBlYeBOmyoqHrwUbhg/B00PHw+h
rJkLBMSz4N8R8jlGTvA8M0zA8kFzNsZEmJwzNm2x5fZeDBYWqMSS2NcoeHBfODYlkSspTA3DybJT
iLKK5+FWjjHYsnJRcij+hwY6G87Ehk+kUtDt4gqKeqN5lSQJakXA5VJKJ67WMRnKqHtyhwaWuRXC
DUuT4F/7w+b0HMQb3LlX7GRuxTYstZk55R3/AIZ8ifQfyIJ2PQjQ5RYKyuRGMZQ2FWjuMy1+8Mx0
JrDJEU5HhtYY2jM0NiUGolQVexLhbLhiVEqYKnFMoI27aWBP6At2+SjbAnTJimgdSY2JjO8REyg4
7gyKNjG4aVHoYcpwbq9tj220pRWG8eRq5hqFhuiS823DA6IIb5cGWDUbogDGXs7RuRi34I8zzDAz
ushJHX2xSASB2iGvZELVorDFNs2smYH7OCLJbDwWpO0EmmOh/kUUL7ZQvOnL2IeblimKLmCu2/ty
OBw5DC6sdJK6cCPPERCaTMUwVsYxEthCqcSr4DbeEjEdV8DGa8jZc8g/1OwbtFj9FZGGZHajeN8i
s4RYSpZagiulVDggrMqeRSbFmF9mmZiVHBm+LLGjYpG2U8Ckl+Ro7csxtHjcCnH5j8N5Icvoawr+
ER5bRHVwN0R8xDZGsDD2YP5NollpyyEGVIRnTlkHo27LGokkxmw2lX5ZiuyJoQGZpvQ19mb0JCPA
tXsuHytNyI50PZJmESdyM5nnYokK6lDMw83BA1ea3rAiP8JpiImIiCuE1P8ADaM8iIlKgNOJHmPR
5wysbE0Py2a1hsUNXkMu2NSp8kQWBjuEQc9+huOLoVtmruSJuLjaEDmRgIY1DVodk7j5mgjF5wLm
aVvNscl2TQtXVZ/3CKFUnWRdluU8MQJKKzR9BBvyjfsr71FUjWGZciBp8SDsSlkZokN4SMGsWsBR
21U5LfZmtiPs6EHB4x8jMhZHteRMiDaDdFCJexxDTHJ0LY1n4RgbpVR/sTYoHyNqZPr4bjMkPphF
tjYOt1C9jEhTPXxumsGmzyC6H5/GfQp2NZTH2My0h5yZDrImcG1HUOvBrA8exUZQ6/hGFbFGNqh2
NiGWTyFgNnwfY5pfpgVozWTZFSVbg5Z+FyTey/6Juk0DtCLhemJ8xLwEPVxoldfSgnyiKR5ezZYz
U+MqoLQpTZHS45g+4QrlajhgZA2Pd1ljTWHwXC+FwMYaFEiiqjGRR6GkNIoPCZjsIb3FGOSDfVRr
iY2xV2k4EiWkMZauDdOnUzJW/Y3bcn7PQ2i9OLExW2gsvsJSkuh/YXYlbD0VyPmaHjSESJYTItEu
BTlBqZ7YnxsdjFZmfmGZK2Nb3WVFi9o/m5DOkOpUVsTyOjFdFX2pjfMTs0zUwypOe2N6qeUcI+DC
1eRSu0BKUXosNiPiiK6qs4E5P3MPDNeNjMvIYVaMfGy8PivAXQ0EqDC2jlchOX1NmGL1oz5IfHpe
RYiLSaHR1bbI23gxcmYM+IoNDzbIjQmRj3rULNWNw7BA0FlluRXyuESik6LqNhbeSMxfODdWlaY6
dbTsT0mmqJmkTwNE8EPyTKb9GiQg+9hjm+UKbqMp6OcvUrklkgrzfaLkZyyNtd+UiSrZ5knDGxGy
9N98MwrX4Rl4VoTzpC4IbcaypwPJl32HNb57HmCvhyxjT3D16YKCN0hiaztcYdFgy2Ee+AHoZ41K
/twcmsGfN4Fc7TIl+97L56TMosxVwhEMrM/6JGeWP/o34JlmcoxnTGE3JUbKNvQPZsnhm0zSaD6r
IXhgQvhJ+xmjT2KsN+R/AlcH+gmaZ10NmcsS7R9UcN+j5NBdcYoXfgzefQFXVEdcTWEF+52JcMYZ
voEjeg3kdgY6dXQLWovA2f3xNJVwFOmojIJPhhoWMU/QahpFzkcWjFFlPwJQ0R9jdKb4uELnkcMm
Baz8WWYZIwmM2yKnHgTJgxNXJuXkbHhIQM6Q0LaY2RjC6Goiw2axRY9M4Mid2Qxu/GjHqCSY8YZK
TYuPIm5DwEsjJSRDDBgScsw1ETkJbJC+DVVHOxd7wNw1RDFCtM/zlwi0WvsSzZLoY8ILtlRbt2+x
qTBKln2bZbNqyEl546Nzg3yLDSpgXwD2yYhYMY+D1CrQmtbMooQuy5HhGGRU6GJs4hmLjxoZAyYj
G02uhT7UOlpihj+hjc/UPwckQw9G+rmDygaxjpetFkx9DUozHQX0m+degovgOILUZoQq16Q5R1gZ
mUQ+AtmEiW7eiqsasaFBybP8OyKc+0EdSbZRBn4oowN+C1l+CwHIlO+6wZbN1B+/wIeWAyRvn1DR
RybZ4KLV/wBjK2X6hDoEC7h6Qng5qjYd/wD9E28N7Jz9hlsMlSYisYWA1VBzRGNNgotvdQVH0FFv
XHZJ+nwbwfQysogO9vDbIY8NY06kbkQN+ZPAoSg2nAkOUHb8kbxkqsobH4JMbtoTbMFg26RW3BTF
VduCyccBhpSuBM2wToOwWrwpKGQvchkpIE8Ef9hoV+h00skyMaosyE2tFndoQHKZhBaEyw0ZcDk6
feFwDZ0+BTV5S2NuCcxge2njyQoZcqMqLszf6kEm1y4Rc9+EN0kyjKOq6PcLDeBiUlkSq2dCWvuT
5MwfNoeqk+A3B5DOBPcSGkCxhqk6Two22ZeSbGajoc60JMU8jyzeBI2MuQrPf0FioUWQ3Xj4kwG/
waxgiwhruZYGoyecDanY2E49BhLyS6F8NRQN8/DNJpGA26JZG+CZEyJUuDLA9kE4LJpDTTp/psOj
SE8RmRliRDNVHQx8nEbL5GxRRs8picGJZJkjJh5Wvh0Mw2siwNaZDRgKCjXRMjEtw/8AA2DkWE2R
wjMDyKhcqaMbQ76GS2foS4D57YtPAtNktCUh6aJKuUYUzCgkgJs2JgxhRCsg9tC1lPwOu0Q8INn1
9BbWeQReRPRGcGMSueMYJR4bIpo0w86FSHsTIlQ1BhhmELi9G0e7uhkvIujN98HQvA2GVKY3Zj2j
aNia9Hgd67AmXRmgl9DobNgjiUwJMYCQyNOUPTrEbjqhHbC5IIfQzwlWUfpGz+GYgknMuCwzEStu
NpocRO6fghbogoM0zaYxVm9HqgOy6XGjNScFFRJ8DLC8niYMXJ0O1SZ5JkA9su8RPS4iHmGtmNgV
cuqxeoOBgRE3ykTw2kPKw44IGKPUKHwA+ZSLNDD0loneoJBMUzMDtYiL/BbNXlylVt+DWO1M6Hhb
czwYlNaLo3yEouV4IA0TTMmIyzb5SGDzHoQtEoZyX2eSjovOW0izHSynB7/yK5hzC8j4WtnLR/Lo
WLKoKKxm0hWw/IUIxmscVJOTgC7F0zoy3s6e8lcDvMKckv8AoR3gezFnqxA68muha+5kZV5oYwKx
D+Q8sFybFYXoUVl9BlkjdFm5uJj3HbGMj4eMeQ6F0VyxSxG+pVmYOUIYtMdIQM7GAlWJOvAkgsI4
KfOLLQvyAYrIml2WC/o7ALlCZi5HRk8vaFUwYSWRkWuYrQquDRnfgU3/APA0EEA+Lb8CE7Y42eIB
Bi1RTF6OBvgaWn+DMNt4Y4McOSeDBy/QVmUW9iibJmPyM1km6haYoAt8LMKoXqEC4gvjK1pTDNoN
c2nhD9mQZ62NfD5DyZRusbuCxwWWLBJbGVXyPh8MgxdioRoQhibg0QeSNsrA3lHJRqxO/HL0PpDG
Q9+Tkf8APhwINxnOdfHIVZo5+CT4olmtm2b08jQYk4MJkj8Czj45I4nwTKMsyEZk/wBJGQ8fFKUT
KyNkfJ9CBaqPIWoTmCxJ9jZ6GKTDGdE4cDKNYCPDrYp3zwEWclPh7XeNUtFvFGNulFyUDuBLugtP
LChVLdGu1rxJa2FNCqxjbZa5NpYE64NK7MWF2PPJoWTJtxpmH/TIzyhnkfJGzi3o2spgwmMhLZ70
4zIYtPJVK8jNlsRq02y6N7k+0QvSOijdi/LGmiH1Dc01pGT8NH97wstNi2s15YjA8WvYly7CJJY3
PY/wiGbdVSwYnpU2KSIlpLgXAsZ2wviZks1bplnwU/5H8lMy8P8AxGy9zZyNDGp0IPYrp8DYbGZ2
FURXyiO6XJV5PtjXyjBMWEJjRymy/anA09kTVrelyKZEZuRR546Y6Mbexv3kZH9LHgoCuGOP5R5g
ldAsCq+wQpZiG55LGLhDkjDQVVXRdCJJfAs8kU/BtR5J2ysLfhS9n/C3R7jMvyztUKHRoNJuxPbX
2EJdDTJou/tHCZwIhvYhj1d+jwLX/CCuTh7nI5AMiZKpLA177/0XDzRSW9/+Yub6b/wy2smexzZq
MT/BiLzcZW0It0IiRpe3HgryYsnPuIMCWWXBb2/+z7BP8GhVYBB5PobCMFEyO6i2ZX1MmCLrORyj
YsseQcIoy/OGiqlU4J45T8jaG0nbQVuE8TlRBeSby7bYfxOhGeINoRNzuBNldabjQzCZ7MfGwuNS
8tGzqMK+bcgsk9h5fojvJOfcRlMK0ldG/wDiJ2fAGSR0P9OOBS7R173gnXqyKkNbEZ0pZee1DJvW
W/wNmHDFQ06TORorFg6Q5wLkaG1IkJkyJkyNxG3o0GHo0zYzahuoyvh5RtQ1DXwqGzItszeBYVEm
TQSTGwyiINCXk/nwMngrTMjTIM/RU0fwXsV+xjT2MLKyJZo6ZyUWoNwmcD8i4qFVs2wJLf0bQ00m
JPQhlM0hrFM2JQ/hMUascXotFU2PBJIanImmo1Cbg3o0q4Ep+iS3kKjeAXxBGl6FEb8+RWNZeDDn
9Ci2xOoYrehW25uhnfql3xsb2rQU5cuRg+0y4vhhDdY4G8dCThlyLRmG2JmD4vpnUEHNjVCy1VEN
VaOy81m8jDWBYY1gITQc2DeRsfm1sQ6o/QytNwo8zZDvmuORdJ4pAngXKJ5UVRM0g+ay5ySNG+JO
jOa7F02amWpaY2rq4EFdsjr9pIqUwjFlg1TLyJMpmWinYcoT0YYLF8BySd2akIgG8EBUsvY0yKP2
Z/LehWnhIaa3kRLqZj2J9lKW+Iy9qTKjKC/Yx0XeHGKuZPfAoU0OLbwM4SeKHkp0EtY4BYRpYC3V
lNFim6ari0mgfQ5a7BbGt6Yh9ZPDEF6YRJGyfQH+Hsm+BsGoXDAwFjzgruof0JV4Oj/TCGflf/DS
hvs306tHejXgRW7h9GlvEVQrG47QrgNLRQ0OEKkJ8tlBEghJkbf8NHWcS7OQs+0jH2ysm+AjuXMF
oiH/AEY5tWqZiov/ANHaKv8AgjluuY6EMShV12C9e0DWjAa9Dnq0mJrNvIaFMH+mw4n+GQOeGhki
9kw6xL574TYWRNFlQY46MjTaTmJtI7PyY9myV1u8wR7S/lCz5IMNBfgKFdPIxb3+m+NQPxNMGITs
hzRHC5YorUchwaUiBM14MPc7YTwnBs49twpvozB8TPLMsCr8FACn0HfWLLXY8YB0KboNeRt80Gx1
RUJ0mZGrEBsm9G1JrNFS/DBtmQymUJkd+hMDFGG8DDk0IxZFXwJQajcfDjHeBMY1vBoVuiR+DWbg
tXSMw48leoN5+ORLZBJKPYmqJnAsHrNjyHrPIxaaYlGNVC05G89EpaNxwbKhCYPZjY3mFRE0+Op0
+CjWUx5G4wVrglHnsetCeEXHn4lQ8PBt+BpD0fYqFnsjfOBK+OXoleEL2aMTycB6MBkBWtvkViS3
HBjypEP7H8Cys6Y9CS2nZyGgnDQxFfYkU2luWoIklfrVDY0PIYbIWGlGzExBNODL0Iu4xNONiOaY
tsZ7RhdgatKZVHBUSMiBPBIlYw0ONctCBt2CKo5DycQY+Ym2aEqYW6LtTCBaY7HpxMwOZo2IVo3C
mWxMMmATCqptveBtFRyxUvTwNAIwYgE0X3O2QWoiS1USWSzZmGb8DXycfCo5EddTTszCZLQJ7TFF
YzkO1fBBrbh09nCgEBGrQaNU6SY5ut9ohAIZm4lqnRs/ZcY1wLcXpH/Bq83T4G4tdofg3oqfaRCn
FdaYg3C+qPdfY3GHW2P1Ta7yJkemI7LhTJ+6GTCouhuLCFocnFF0xxdVYRtU8oRMxCeorYOqbbod
MuwWEVEyzOBz4WJP7AGvXHY6wCohEwN4Mx9Ij052eIGRDbNKjUEh5w72ZVLRukeZ2UjU+AusRZXk
w6H2hc2xxg8qGKSVLxi5Q1dsdCGbWlFCz3lbQQUusgiaUaEVr4Qo8FLyKQouEN6Sh5hDochdloaB
j7RBbw9GTlpgMYaoc8uss1ahuPAwZ9WuBCiu8dwezG4n0Mm2E+gl3BD8QaY1PeBi2wnykKLM09L2
KkHY9T/QDhUgmGne6T+LFRmHwMFnKfYikp7Mnc31YORjdYuKYgy4VJTXkPqbVE3Yz4d21SIZLHgH
jDaE5jqW2MxNghpL9BRX/JlkPu8wb1Soya2IdRnQMxJeTgGYPRB29i/wJx0hzyJhuTIjQxH8LPxj
oa6KFv4OO2LyLfj4RhvBpCPLFhsS+fwcwnNKxUtjOA3nBtZZsLYUQexuGDIQl5KxtcCzA8BqSJk8
vHxxBMwRR/A8CMXD7JgJE+GXscxkL5kkxs/02zSCZQkLVXYtj9kg2+Lg0Mp8YHguyfo0XwWsHKGf
0PQ2Qz5ptBGmktnQNERk2ZbwisTAhyGrg2tCVln6F+ZrqCbCfwhkMnk8UYobA3kI/AgdNs8mxHQj
yPwKwwUWTTwYh5FnIq8iw8kyYC5Lr0hJV+2Po1CTI5rO1GRbwLot8GEQC1e2vIjTXzRFfZCJ0S5Y
9jsEOtJZCyG8saVp9wg54ZCoS+Qhzh2MuVemyefqZMYzlsNGlLwgyE413kK9KHlDXhLOX9NlcjbC
9bMcDkN6W+WKHsUx8LV7Zix/YncD0Ym/JXkSxPsYZ+hcz3o8r7GX5KyKI6ZHzKhmdou+T2MnMK4W
iNmXT+P1eEfUY3ux1MCrYWVgjR+mVUlhlqlD1tDVMP0qhdf1w+/MOWMkimHJkNRRMppKbpY6NyaX
2v4YxKOwaZavgU4r00On7EmjhKfQ0vRkn9h53AsB8Q/oTpkM5g0aG/WDEe5ZNMyl4VSehwKapyvQ
mTf0Gtf8mLBlRBxNmNIUlhPwZXNkWewdBDndEbJn9JxGmEEjWjtDJ58W8De1xWNE5B9EVZBS4yTX
Y+Cp0QXL0dHA2PjBPfkMNLYleBmepZEaC2Z+05oY85rIcROgSsjQd7CE474K3SWMODSmPiMLBOLN
8pD0KiuA5olwHPLOJQSBqeEM/wDgP0FitUnKlso2m8Qp+3Zopnb8CKoeUETBNeBrz4kcKN6KIKuS
kPA1Ef8AgIR5C5OKbyTlkMaqS5Fhn9DdC5Fz4O1JDkTGX7FGezbOIjy+Ml5F6I6HGvhl+h5exmmq
yrZc0Wc2j2LJ27gTFlbg6IkOMi8GxycjF+iwbuBJTOzTMsEjYylJhCdMVia7I+/hNmLDz8HSOE+m
KwhrDPxWENZZofgKp/Fhq5IKJdsii3BmmqyavIG9MYU+RJNRpcR4MOA1/B4L88f4Jx0KGUuxmqQd
uAawa6Gh4+CGqjlDb8icY1sciJZN/bswPMG5UyOgvQ4zEXWxu4mBBi1DqR9omGRwm5KTY6pepDpC
+h0xJbybyBYCU6Ih0qcBwXv8D9xgpdXUb14Gg6VgymXUTF4k7EJGSlaZvwLvoWeiw2suCcjFGJKs
3gYMPNhoyfdCLCU54ES6MPsUekmWNuojNoWc8kjQ0HgytNoRlh6LY2s9UgocjsZmITQrp0kTfLF+
IhECao1k2s0aXoXBHkeMhsMm/pDNtLyYhJt4T5IqXNcGJ1k3VQ4nLC0A4rJBSUqQsb4EFTGa0x1w
WMKbeDcjGOV6eehKVbr6KlbOW9mFJwl9CL+wZtg08jFR5HXbkY2V8QYCC20wRRXoVrBcQVj+gmNX
3kg1PBCjGuoUAz6BUnC0l2+gyl/QYHgaOMLkgFktosGNUeskxYTW6Kdah8mJU+iMRX05CQbvT2R5
z5AtfxTYPgI7VKq9FsEq4EdagkRhqSv6G9U5CpSRgyxKSjYUSmoIjIlqqqIrJBJG47JkbOVPDF9w
11IcNSM70VhBp6LBXqGEmj/g+mPZJe3YuZGU9eIJrYyxAFbB5Eq5VvCJQxWLTEiJHXQw9FQ+uQ4H
bVtIPL2BgxV/fl0K5p1rt9joIza0WfmUwXCGyLoNZHgkZ00HkPw0JGSQlTHoWIPyMlIbyQUoeCmm
L4TM0TWSD4EQSoag1k2Lc0yRGMZRsP4IJ8LY0yUgJ5MsvBcMWywlJCCz4Zgciw8jYNUh0YWU4Grk
yYFgnwcefltDuxtuiX4ZMWzk5o8tkFmR2ylw0bGW0vbFXwaU5FmngrVihmxaS6ybRjlmXBmXb+mm
Sa0y6OmEvw1UvbUJz7wdriQkrw5EuZYY3BJm1KZUbAVQNlsItM5GQbI46TyJBNvI23o8h8h5CVME
KZ5HVLFLaG9UZOFvgjLazAXKPKTRqNeQajAlGuc7JAqsDH0BpWnIlRl3gvqJpRGFzYtXeRRlhK0Q
fuNoh1i+6gWdKxVPT9ie1GmIPEqIngU5ZHcModDRANzsdwQ5FHoGTSMh5XxCoVarWLI1wEHxOCPd
Z2LUtDlYdjWc2Wg/SQp2LvbtoQSPAfgV7FoaNzIhI74hNv4GpaaZTQ1cK7WxBZPSIyaoz7OUiY/E
JMTncLYKNMel1uByDnk8Eo8p2onFOrge0iOoGCV2Ot8Nov4Umpyy1EaEYgxhhCN8EUOuQixTL5EC
MNdjJyNnDsTgMdQGLAWGFpqdrhDm4hAWt0WmYvSKgle25dKYQKnYCMafdZLkxJjyDzXqGyZuitlg
wYmmL0J5RZGu5JL0SEOmUH/6cNWFMWNG0NybYYl1YXxuE1HuFtiOW7HJiagZSgKTXN7/APujK0mY
4QJZGzrFiYyLcq6QgMmu3pUxmcQdvwjHurgU1lBEvfBPkYLJVlL+DBEhMRB5YpjkuVp7ENfLJ2Cn
hvkOyU1jY4WwKqf0i9I4FG9Z/gzD1J3yJFOFX8MxisFPNta6CK04GRwoNvkaGklnJPCb0J/+1Icp
y8hYXFWdex6MbVotxLQoEw6mRGZgg2BOzL5FSWtLAp2FsUZhssi5KCwOWcMavJctHCJljfY0IEix
8CHwW+CJ3sgkQFkZYxcLkr7JCZOBEo1BPAl2aJFex8mY2NkhcY+GbbQ0bFkN5Hx8Mq5Hg4HYT7MB
39iUYyR4YsjE2/CjV0QwOjRfwSxWPHwhIZYMm9/D/sgn2Volya+BC5plgkPsyc65FT8iIJ18iQ7K
yHumdSvr4WVUQjLYyVPJYGZil3rQoZimSFZhlxkOw+T7M6jlYNW38CYJzDeRlhT0aI3gIo2smTJ+
AncIdWXgzc8KDRAYyGBD62aEuN5O9MehU51xGN0sypSJ4FcYhG2GLBk8o5WpBKlrJmEu077NQaMp
csiTWVliXGcVieTvhoVOflUVTA4U1sztj9ELcOYaWu9HCMA8qFgGj7FC50PURthG8R4UrcBMuAse
qMbrgrw3RzM7LobfYMUoETCR4ovwzljWq8ojqIsvIjDZhOEX1YtaF4hYzHuX+kF3SOGPKShabUmf
Z9kM+gLGZhlSs+jlACJUzJGjoaMkdM5y1n9X/DT4QoXdGoXAmSB9GSlgV8CkL68wQTU8WHAyFmoI
T6SGTubvs0TdZDX0hUsWtZY09sFKDxucslfZgsZ4BMcL3ORLDXC/J/D/ANHpVVFdtYeilC/XkbI3
gtiOUo+TJaO1SmDTkmWeaKSblm0FR6C2QHtboR557i2lO3AosiKL7i9BoXlBlTbYEWjSrFJJ8we2
6vY5xLFMPSTcllmvQYXR4q2/C/uRgOkGu0cIZAPhsw7wvAfR/wCRQRbR6IxKo8CTNdWcifJ6XMsP
0VSfSQrjP+QtUyr4p0xpPTA67JFwgIRV7DksjAhGL+CLYqstDZTkq2rGAmXQ2ujTi5HRbjJSdlbZ
Slup+G+Ec1IAhW7VRsVdfA5TF28BmJcb0MTAkRMkCIT4HOezj0ZcG15HHI23sWR1XciVfwbi7Fs0
hnITSyNBhpex9DssQ2KHfgZCU8/XwmbMERBxNKGxFBULIjaGhZwNOidJ9mV6Msv4ufhgETYUyxUT
4OQwkVwYbMpodRlpcwfgP/hWYfDJMlg9z4up8KhZBB10HjMxsl2Ps2BuXe1J8mCPiEzRAUmiQTYB
8w0JSXImmyMrE8usulKD2WgojWxq2qNj3ktPRdFJcit4MbaZDw2NU3kL6DGKNWUuxP8ACQ2zjSC2
5uBgbTRkR2TFZlYIfVIpchwp4wNNyOJLGBDYVP8ADCDy2e8tFY4WB6usoery+k5HJNE8GY4rIhuU
ocGr0KVxB9k5MQXTV6QhFKLkgljGB2NNTgQsKXZB0nRhmtORxrZci9SPkaWVkyMnkZCq+KMEHEOB
h04wiSPQoHnbXIzh6ScCBKc9UZcZAr+kV3LqmYKM52Jcz1let10yYSRgnEOJRH3tyyjF3CobdBWp
n2xVKrIJPAG8VzMqIW2xfz25joz1qot97p0P4pFltq/QjHGWzAhtROFyM4M0pDArfgZyX9GjV6E1
6vot/wAQ5rNwbc4cbN1Ja8EPE5An5P2ylE/6JknKVMMFXaEflkTkSsd+TywLRr+PVHwLhEmcllae
hL3NQjtnZ4FHVVqJEZ0+xgX5Eov4nRRtQoM2NNsLVWIjyV8mzTFFGkfBqW1I9myxviVfTYq1heR8
PIvAxb5hobttvDHEYKYG8O48CkSJWsXTeaZYuyuGCZK5bFbT4FrZiJFu2PnZ8JvJDk4sl2mXfg76
AuhlJrheAydALKMxltNhOikmEEmSqrCsE6Ulwj1/5kOQx5BBBGVB6iew1hky9eC2yWjqeuRoVrjt
QwNmcQahbwd5r2Rwdl5U5GaG0aQ1fHCFaGVCJaXLxE995vai6gnAsqsI5kcCR1uJ2h6ClaFHntWy
PdFH9G1jC2SoW+u9o+B3Gz22NQNQWUzQ3k8DFHkTshQ/B3D/AE2h7G6y0kWx+Qw0M0SsnQIcBfBa
BuiZyaiX0IJyafww3RqbJX8LfJKPGyn6Kbg1bGavIvqx9ITozgLrk5GmBff4eXgWExhu0K4i5BNp
GCUSGkNGLq+DyQb5Gz6ReVJgeiUoJ7DG6YvCwSY2MWnornY8KjTA/A7yHkPAjTtRxV8DvbmKPCPy
KGwtOhmUOnMJcmHXPpjIQZWHwOxGicbctD3ReomMFeg701qDOttmL5Hpfi0MwJ8Gx04MJ44OZvYn
obNQUtNvYVjg+/hT4nEzkZyNSb3bBT/5QxyuiZh2oIIgxMIrjo+gyBXPyFwrpTAo6ttsbzOxKE92
GpCK3qVaKY4tXgU0me6IzKtj36CHjP4K1q3Qm5ncGDqgNtTZxGcPIgpzQUt2xqmiew9M78qUuY+Q
9fOS0tXm5EIolTOQi9OjzlOnkZwKcmYFuLoa3jYrgTsyeRbNPIQtWvvBn2LKSYjJ3BYaukJKRVqT
XWmJEdsdxPAe09kithMknti+61yg99mY4WNsSuGNqK5IX5LoO2UX4u2if40rg54P0RdfFQl8+Ybc
F7Qlf9A3Uy94KDi4lHFilBkd52LgK0y3Oehm3G9ijBCwvw5KQspylXQ0vvfkdcUNZWNZyh+e7AQd
3FzIqrlSJy/vBI8qxFumE4eE0Yp3ojzOCCPtIY52aXlD4nNIELRdZFJPKJDILmYxRhG+B44ex540
YutJ0w72DzZv/imDEzXVIz1bIq0P2KGun03bOa5MHjDhm3bBZZkZr/uUl7s8nfDOD9RgSzQCLI/f
LJYMc5DWnn+fEtBjTpHoew2phoqH3dkYknTAXNH2M1+jwHN6Z3k/hNNi6Knw2x90f3SjFsuWpWkQ
w1y8Myg9hnM9dj7nyo1pi6DjNNvbbo3kUYEbWDE8iZIYNwWyv7Lp2LNDShJlfBsJENGTJrJIxHah
iyJUPJsOMnRtjVdKWRtsTbMmx5Rpirwcp8V2E6LRaeDKZkYZfC61BIS6ZbA9BaZLcFYWsiyjaDqR
orCwx5Y3wMFGaYgzgb+osMWRLRnQwK+Bnsz8L9SErwLK2N2xeYLLpLcGpoSGaEsjYrI5GfhA2odM
xHFRTsGyjY+hrUoVvj0NZM4h9GQCJCtw/ZSDnOLIPsP0SQagsGGmLZVBT4Mxj8N5EHAx6EjdMy8J
aFmggKCSGnoU88kx0UeDmx0BdQ8jI9J4HGpoVkt3knOjLcFjkEmUJK3nsSVCZNBuhs0MqfSEueLw
K9y8nHhqIbEsONkoaC4kq2XWE4FuXMFp5PmE7zbXgZGjQY7HOBCbOyEM38KeioUclgst+hq+gJvh
qMXL4gIVPOYFMz9iIKvgttIUlw0WWiGkaoxLyPsmwTiQ/wAt1EFbvpCXufwSEVvgfJS4pGi15GCL
WziXsKwsEvQ8WDZOpi4scB47/Q6jVen4ObJRytMT225zkXpZG6cDU+4pRqS6HjRYZXBL0JbSonTc
sCTJ53CuphM8QxQyCLPIZyaKyWbyUJe0DgStaIIzlPJgUMdE9XBm5JGA5yxdCZD5qsfiURPsSVIy
O0S4qQQhZMYJ2tjKlajAtW8jqA2ZgT6PBhLGkNkeCXPAOLYM1kSAmSa1gSW2UGuhPTG9Gc/9Qyzj
TDY/td5PwchQdPBnI+eoUk2PfKiGpzXM+hZURaiG9vtKB/wOofj4MmPYXUXdGtj0H+hBE9E1WKwh
lbNDgSDUF+Fd8DJF8LN7FWvJY4NOYPYjayIPHsZnJj2ODLMbPsdLI1h8drBWhoaiFRqG1RoyTybG
118DNPBG0SEyZaXo0zsbmF0YuBbZ2PEK2OBSiT4T85Jkq7HYnJDKeBJDga6+Kex3jQ5DKtco+jIa
wLSXJRkssVVzsl5GnJCtMTa+i48knEUhRioSGs4vJGGPyKTSGipOCz/0E+yrGCJwfRgRsiSCxwSC
yppomMif6AgLDMU6+QrBDvYbbtG4LPswwyVlywdSKbL+CZmtFM27moWAcWGkcTemJOxnuixny5lc
iOt7kF4Z2HQizRg0K022m1oflEl4NO30J5NzoWUleBl1WiEdMxNLjQ71V6FCE5TIpWEBZRuFK5wa
JTl4Oa9afA9LNt4hSGyJ8V9FxX8FvLyfYpBS0RwcBazpVCC7oEoLNlt3V6MN5sFDWUwIscu4NORZ
gqzdMmk0YpSDCWRcZqG+kqmLG22dsuPRuSDO1X1FxaGISknQ4SOlBnmikOhWhZ3s7hGduKYQFPyz
FdOoKlWhFi/IN1DkmKxL1asjfgPGzVmo42ZogVG2cMbDTNCzfP8AwNq5gpLSFmeCisaY18GSR6EH
PteDGi8Y5HZnGXC/CsVGVFJnXbS5GugazoXLRCXkt4bwOxDkNH8WGIusbD8RSi8CnGeUVrngnJJV
WcmFOuqQUbgQk5aVGRDU2yBgWhLumyrgwqn+jvxzYbiw8707NiYoJmEgTgAKtrH4K5bINUqzLk38
NqFyrQRiKfQK0bG1yrgqxt4DHiovEeW/+FmKe6PWGc6Qsgt4TAqhdfIav5xuhAcMqyTrxGHit5Sj
u5dOBLhoqHrxDIiEniCbcFbRrwJG9EvZ2QfSMyOJAtHMctKi3URBIaGyLCD0SbCJoSp0osfHDkQj
3GksfDQjlkb7LscDyLWxvhCwoPHJwWhnwcGZnSjNvA+zZGj6D2VsSFKMmVoz7huv/A8qYCKjE1zy
LChexaWPYqmaE6JA10OqDpdCDJmmnRRFg0IymRrPwkRo16GC0JfgkSZsJdjyxvxonPJ6Ex0N5F0G
ceTaNpsaJ4Y9LsViuBDa/Zh5GHNN9h6nG0/hsZuDo1+vZIaBgtYM73l0TG0qpIho/mHMxt/g5pu6
MTyuDPexq6/hRQm9DWwlnoZJH8Hg4tUrXKcMHyLp+SrVXwIY5jZipXgvxLWGzryiagWV5W5Fi91f
hgFAuwy7xlwWRGkyDeN46JCIX7OAI4MCqO1xovsmlR+QIaV3cQ8ozBmhJRLsWryY+SzyrCI1gPfg
WHw1bfJCEEKIhBT1j8kxwXNlyI80vc/gbOTduTg9GY7vKHu7zY/hY13hnBOY9ScD2jSwEd2x4avk
NGNMP9b/AARDtsT3RuSYqxhmNyB9RHZ6huGIJyZXRPAi8DcEaUCIdsZO/QmjF3LbyIFhIbuGYBq0
2EZ8j/8AjHr/ABf8FPlwoakks6L8ao6NF9h/hG1bUT1MZE2LuUbxqDBybWzORmJeTczkiVpnCMhj
BjLminthRNsvMxwWXJBGQuakZG3KKVmroadSalCdSZSVkw/hetzJvBPIn4xFWi1T0y0WuLyODaGY
h7r6ZGo+fIi/IohbtQ6RH3Ahdc6hyraL5tLeDNATGOR6jKTY7QXG2Er7xkTG1Kp5NmZxPZY/+DwM
YlpRpHLbWBreu2xt5E9rX0WjJM0Fa2Y0NV1/2NSb/QVMYVWMMiJ6HgdoMbzlxmlQpSjVQRLuCC06
RlooKcuDh8isNQ8tDlNVmGODDGzasdKDEjvBCeCPY2SHlgw3Ro2h5ejKLdHjOxNZ7FkiTMPk2hPg
LNZMiiY+FKNrCRwXF4FQjSRxnA5yNQjQ0qJefhPIw6KMjUNDJ+CZNzo0NaKIxYV+B5kax8CeRwzg
rYkbMVWx6fwWUdELI20Tb4GFgS4Y9wkM/Rp8LRsWILefhwJRkbCgjbJ8MjyNbBj2EoGJPGUy8BsM
CYPISuMPJOdFMFE2hgnDfHIc7lCIFFulgb7pxnhAk8rg5JdZJvJs1DBjh1vfwQSDJWR9GlsVZGyP
jscms5IRd7GbA5zBMYjE4TYv3CDTcTbVaQ676YZkx7Yo5ic5R5LCdEbV7MLywOzGbxks1Y0Nm6Nv
WSmMhaOc5EmxBJb0HuqLjE/2HBhyVwfbRJxyqDEi+A/uFfFFqweQj2toybvOzgEMe24RxNb9CwwD
BqfQlGy0g9jyjezI10mBILXHo3pup0gkY7HbWPChN58skDZhqhK5IAsabMpDDmUWhMjQGY4Zi2Hw
ENx2ZCR0r6HLyPhGkkKC81aIWu0MpBvWjAuyooHsIqxOEIkW5hiE9Jk/BDIhjcMHob9HiHtiEsl0
WfB/gmXt0XCysMrHd+hi+a/wNWX3hWYX/kQtKQsRSFrBaD8PxFU3WZghkPVYmXJFnhzQ/X8guZHm
+BRawVoUDW+wqU201yJcyLGei4T4g/YK/wDBDMTAorIkqNGuBVnFsY6drgY0k9Jdkcldect+Dhyu
lCWs9NMlq1VeQeN2g7GpsKU+4EmxUEVE7Oe+55ElVL+hH87UGvBnUHLzOBfZzKMKEU7+g5sFI4Ap
PYSfkc1IIcXFU2ytNEzwPEu404uMBsOdqMi0izKiYDOn4FcarIKWbV4HKGcKOlFGP5mplrkRzNEZ
xdJdj2y1jXkbyXa5ZRzkTTRpCXNL0cViZGro8cio8n4okGp6+D2OsqbnxOw04zg2MldN5HEdtidD
V8DEkPaWodb18Bp28HhG0EzK5MnkfSHUcGxpMrSiGqLB022Jz8MLfwvoefglR2ZCU8iVkHkwwTyI
aIZ0QbyINBvIWj3E3DZvwLAucGxI9n2cmkE++Dmlk6G2Vm5gbifrsfOB4UQSQ7Vmzpqhug2Gx+vU
dwUVhaogoMAtni7GBvApNfuMMcYRi2C2G2rEh+mJ10YzCOxT6M67JkexjJElaZQ4WT+Sv2RPJDYs
KL5KzpsX0gpyMZPGPA8LPCyP6PxSPM7ETQbaEp4EJh25YKcKh1TPWchGlNk2h1DXcnDFJkMeAtZB
XQOScS6FA3OIr/TcK5/ScAM3TlJVyHx2+ogGV4QuhNe6KDzewkCDyiEGWkKqXxhhglqZAo6jFZ54
PJ5G9jWPQxwbbNuDF9+WUbgmQxyGnyJeW32PUUQlHsJiiOe2wcUTifAycjAlQvLG1zmqXTSVhnnK
QWG7OmeDqmiaVYYT0WOcsL0ZLExidir/AMPEkp6SERjzDWYNJNjFV5WTOC9Pi9vkT1GykmP6iv8A
BzWIxjTbo3G/84ElpBPwqP8AxoND4B+6UxxWDYymHBCS48GHJmavIX/j5gp16Gmjf8FkDgC3xrcI
fZctr3KOJ/J32c61r5En/jZDJNGJMSqnY/m44UL444alG87eEe4gqPky5iIYMUlgXFnL4K40YKfe
OcsUoKiyNkYel8Na+iiSfgd3JYexhFp0x6Gukq8kmkUHc9DhgtEDayU6GOC0OSS6FlhEWkP388s+
BHmpBi2tQl3E8RyGPdFB6CaJqX9ihlfY+Y3CDOEqrNFDN5GIxCiUjGUrgXkFJ9IWtsulnszsO7nh
I8y5/wCjrcG11GBNy2xjfrvMXaVlZosqlIXJHMZ0qRAlfDk8BPkOpI2wPBKiGShpwb7fIJ9DyHBD
cbFP/RtfhphogSQXXAtycCUUNaGudGxMZI1BfpjS7ElsiaP6SpizMHkMfYgkHiD4CVNQt0UvZfJE
jNpiZMPZtpD8hHDHjk2x8dDdRtPYxZGdD1TQceRKMfjZYxKI1vQ3gtQnmGmNiiG0b8CRR0sCQboW
QhYGXyLAm5yIk2O2mlhGXYosDsEE5uvIzinFwNPYGaDPZGp58iCt+2Niz7wa3kNt3JlEj7UfTyCw
e1qZLLK5BOG+xyokWQTVfI4vg6jKDhFohmxJLA6ircrpktz4H7qMXa0TYG0+xJwvGCVte0PFXBTH
9w1KWzyRxpi5tB0wzKtMlohNRUGKrkzWfwKsH0xFKa8iWX4GNKJIsrb8jSN+AmsIm9rgmRpMl7P/
AAYPJaeRejvsa8imjRkat7ZsVPTE0URSyn7Y0zRDKg63A21SGgEkm67p/wD0JDZ9nJyYfgcMBq5O
qxamho2yZzqxqnAqoTCimMh1qC3tZ9iS3kNIEuEMshNJJcCbCpD4oE0wwWorSwMZPTpOC4OxcoiU
5hkL5oNVuHgZ11alb+HG2iYqmNDiCSZp7gqE8jRq9EGlSrnJACUooUNzJZBl7Ew9y2RbBfSfofVh
sdsWxZapCShQRr2LGxsZWw0eR7pIfOC1hinIjB58GgIyDvIgcCcKeSH/AJE6HhDZHO8iWfBXcMHk
U5hLnobyPKdGUTyLGXs7Nj0vkwymNwvB1OctJ9jgU1GZ3RrlYEuuexs6KNPIt0I9fB1NHZlja4Fh
RknODLexiMHCHCuBYY8l7GTQ8qbHgLgaiLV0L2SYF2Dwy50IrSHgaJfCt9FymGsk7MCNIwxAejIS
/RvImFNBqoQ85OHwOjKfg7Dpou6Z+vhyEEaRhJoNaJgkzwKuDPK2KmODA0WBnL0JilkaGnsyZPRl
kryNMXApwMZJ8KswyXF4GQaIbjkmY38DZ72JgjvB5gG4Q7FVPYn2MbTi0KXf0JrnTUMprI1UsXQj
LH0TmKLcJuDm87oolMCTynyNnCZ8jqUF2vi2Kpb8bIHIZ8qUn4GnsWdja0Nsi8hYdHQ1dj3U4RRh
5o9lfBWXAsGhJwPHI4Ex4mUHhFOIroiVNDwqZrAqKaHtRNCYrFhCHAnLfIkcmCM2cGEG6NiCyO+j
gOUGQ2hcmA1n4yJJIQm3Q1EG8kHvBUkaVFCYvYm49mmUUTtyOeTsLfQ8A3msuKcgkbPyI5o+0zYV
+2yKhzC6OcP5sErZcjbo9BmmIYcU/AfCiqyFtjgTwh4RDtOUdEVMcA+CvkgywNsYylKEkRlkaYEv
JW8sTGRQ+4UeBdiuBUPIieRocGx4gmqZk3gbHgstjUw0bfkTkfGhYTha8k/Bo5KIXCYk5HTwUqXp
vA3FFlfBMUTxjZ5C5pg4jIUyxLgVyhWUWVkeQ2RtC3GJZRs8iBusibDgJg7N55FtfDdwRJhG/AaE
GsnNGroT7Q8khIN8jbEo7fgtjYT+z38YuaIzBRO4FFeixNbF/DlGQo8wey9HI76FGKEzbExa4YYG
ONGLyXgW4E9np8IIyRcFFkLdEqhh5HrpCgJe0Ja1Sa5Oc5hDCtgxmzBdA9G5pY6DnQ5DfZypezP1
HD72Kb9jQ6ZHG1WCT0SwYwRoZpwxUlGd8CSwazsnYadzobdYFY3kZt6wYLyI6hix7FhkguilweVj
A6iCfAv4J/C8bJH2ZY218aC6RIpMIKT4Y2ckx6GfIw60c/BSGxRaY3grpyhs+Djs0N/pLsSx2N5G
kH+Bs7G1BGCY3jGRqkejYSW6N52OlHjZKjIZ6HCGych+BlY1FQbGki7DHkSsVH0MZIxoVOWJhq+i
qdFUGncMdkTNLj0VzAsSrwYFMmujGRhg+gR8+B4fAsieMjoljOxt1gcF0N0QS2J5MvXZFzsh60YM
nPJJZWIyujE5lmzDEd8DlL0KsXymncF/B2O2husdM0sEaI1LyYnwfDRtS5MFbkpo0znwbeNDRkV4
Y7G9GuxkNGjalecYHW/BY+Dnka8icZBhgfmMjoOBQMyWx4EzbImVkZ0RgZPYsCYrhV0TI1RNM/yh
OoTfJ2DR55K2g0eRKnDAHNcmllF7wavImpkjTZoNUvw6ciR52LsbrEr38EqTi5HA0Y+zYkHy+I2S
FXY/JFwJzgTrVxDbtEs+B4hSMFsu+BoeUBD2B88rVM2I+hjHL2MKMnny6RW4M+1seh5VyUb41Ryu
aSkacKJ50DrxRXghK8j5wLA4CRvFM1D8hYJR0haYi2bbo0MY2LEp0KYbyPfwNxivyHBoHGQ7wxP9
IYucD1dGt5GmjTwbY2dNCwfJYLJ/Chm4IjQTUSG58PIX8MfDg4G6GqQh+z2NDgwEimmPZ1wNLjJ/
Q22xPvRcYMKIo/I8+Hax2RFLZuZLLGjSpk2XL+KlunBbILBpWOmCQ5kX0d/BWYGeB10KjWhrAmvh
JyPC6OXxbVOWSCUdDNeRLV6NWcCygljwcFyJpOtcFgOXqD18mHwbXoYHoc2PIyw8oJkGkQ7RqB9F
88DWIsmZRsoe2TndE8bHR5Fl8kQyvAfsTBH0NpOzKtFwQ5Hoc4LhFyaY8tZMWuTz4FkozLxwcbGw
ZPYxuot8DTFpz4Lps4NHc/CIQH7CL7MHkSjx8U0NsCE+BLsJDX6TBB+BLHRhtdmAnERlJ8jp/wDW
UZH6MsWkwa+MwVbaJzcHBHwmGcQsRmHsq+hESQ+ZoaUGoJOWwtYtsyiwcB4oq9DpUeA9ZPsSsDwr
pa/lVqzeUUzOfjbBXousXDhklU0xhrBlIClTkSknhcoV2HZskhR3wzkSCcRDqIW3MZOIAqJlOxKI
w2MAa8MtM8kvJkVFpGkaHAvIkLGDCRlkda7RaexiYZCyEolEPcHmWsTxkhyGClNFT2VcGydjGcCX
uQgm4VhIssSIyY3eBNx9jnsJ0thyH7fDTaPLQ+CpvI0o0kx4OFbWdF4DgTb9DQy0VN+Ta8kjog4Z
oPAa4lqRvR5Htiw+x7HcE8YE4O8YEwLumbG/g2PRM5MhdtP9EbwP5TJMWjyHB0NPRvYjL4MLQ30a
NjGoxOuh40J0pOeTfRDodOh57ImHtDYE/YeHkWH/ANK6OD0KMDyMBt1GuRsFzRujzhYEddJHn+je
iP6LBLNL/Roa3ga+xVyNK8EbeRrYiwt0J6PJh7NRTe3BMCex63BEkYS3noThj/o5d0YJEUeg0hMC
tgWR7VFGTi5HUsik7+HKK8CN5I6zGxvTNtiaRI6jmjE5g+xZUbngMU2oSHZiZI27E/QbBqB4NjBs
zGRsl20KzVMgkwiTZYKBuMx7Cx7E86MqFpFCVizUYIgejLWNCrC1BUeiWISjHfQxH8NNnjsStGoL
LBB4ZFwphgzG32TPxTSYwNTJKbCxSly0RueBbufMTHNezhsibvh03YaXdJ++iFzeKFZsemLsms4E
/Jt2I6tJ4h09IYkPh4GdsP3GmmNnBobuR2yVNjrwNYEsnTpC1g2po02bkycBsPJd+SGitirzdlco
UNBPPY6mNZ3k3gU+B9G0LBHSNahNmxbIWoTOBFk0NUZsSbZpjv4ItOPw7MHkgoNNpkMlUQSTOyck
LKEP2ZVCG1R4Ewd0JRMYakxRKMLVuyHgbm9mDZEnwlHuf34CprwNXIm2mRuuBu04hxjXRH9GYM2/
ZkoybbN+jajsMc4I3sqE1X8RewwnTINuujBRv7HJaGwbLpf01lDZhKLAg1kk+Ampcpl/4HvBlFgQ
uPg1c+SppLo5EFsOzBlO8CywNx7IkIThaRYKjiRMUkYavInjZdXR/C8CjwJf0bHhhmkLMwWwbF8d
NmxwzPBtCQd2OmVMthadGis5wXHkc90zgFTDZXk9DZ6wJ/Ylyjmjdq0hOcjjmjjKN1geBtpCDON4
Jn0Wsyg15N87MNjOYEeR40PKDZGUE48aMmhpMiXYb5NQbNDMRl4NFMSf0NhM+Z4MwSyxUkY43b8K
lFrImstnkeDEyI3zkyYnwcVSZ2WNRceTIWzsTUcMoWYatLs/5oG2erlEGVnUGPDGq3z0RPl0bufR
RDURBvHgP/BBHTxSuuTND8UdKv4ZETIaz8Ugr2duDbotD3gwGWF5l+g6eD0cOBc1aLUyWItZEmMo
yGnY2exXwKgq9jYtihMTPwjtvIzPCZXSMpCWzYQMrUzRf0uR+Atr4VpmypT0xnAd/wDZKfZjkbIX
DG8GQxPGimozeSuGDgoQLKMoMYLghPJs2OgtQSg69FpiXJF6ETJRG5Hgm4Hjs4CCE7R4dZPpMkra
o6kf0EqlrJ2OWDJuLA1fMHj4Em2bbXQpWRnUJPQ5EluCxjkz8pG/BDXsbFJLsVGq2PEyFN8nClnk
TQMknI6xBNDZBNUZSk8HC+tlR0UEnGVnBzjBSyzJXXJZseGh8kPFIpla5GngPZ5MEg2+cDfY9lrR
saXg7DEFG6Nk8iG2WnCp5FcYkR4i/R4wf6U2/jUCwyWD/wChMpmAjo8sxqmoyFqGTYqTw8DyNqPz
sgtFGLInVBpgu2KGROG2LYqxoeVBKMeWaapy+MDLyQlQkGGeDNFumeBJ3Y2yqnYsUeRqLYeRKDa0
N4KK7RnIqfQqjrH02Zcg6U4Jn4Cuxchukfs5LIzDtk82xd9whsU54CW6VpiVYwxMyJUidW7FO4VG
+/UxyC9ikLqEvBxCKDt4eiFqNdF7Di6GrNRJswbKmf4OPCGyM0I8nySiT5EJNjSbHgWs/CEb+OZ8
nko+g28CP7L9jaPs4KOS+K3RWjabFwU6rPZHsuZGKMBSYzFulptDbsd+hLnkTaZlyTBQm9DanZgR
ciGuTQpyIfJkLYddRDgTiPIJ5OSdqZTiFd3AijNhYdMu9CuBrJZwUbjG6/ApkJUuhRZG7omEJOGy
HnnkVhSBL8HEQkujSIwTEsibTTkbjfA2Gbz2NYlyJoKYJPJDhk8lyg2Ya2KvQ3r4UaWCMpcfnxa7
HdMk9ETXTKs+GpHUS5sEzbeTY9dGXV0XL7ZtgZeAqo1AiIdhG9DX/v4sRKWKGGwN9lrFXskNBBuC
bRbWdkjLno2MWMqUbOT8HEJJiyEGyn4KWBImbHvZYclrYoZmjj8HiJkvIsLOzbLBpjgXQhWOsxyc
jGTQsvA3RoLUhEMPYraKlCUcGYo/g26dRmDhS0yhPsSt8Cy6eRi7Ey2xrkQ8CrK38Nh7CELkjpj2
yiubkx2ZUoqNIwG8uhrgy0VqODdVEd14fQmRjPK2gtw2U49CjrkxTwh3LFEKvMqQ1vokKXkMLk7L
2rB+MDmCzl0O2jeRpCzkz5GE6qoPbBp2L9DwysKMtGQnCNhsXwLl0k5QoMZYZIuxCQTyUfANV4Ex
oTke3R/gkXaIMGYA93ZgyVWDMD/RkI1moVrXBkjhkyMF8m0TJsf8PIm2hxOnLwVvHInuuCY9EvI3
L8MoKhVhkZ4osfAssawN+SbAsBKeTWm/YyxvLExOmRpkkGAwqlDLAy1CUSvkzmc/C0Y6RCRD3grO
RnlsRBOCXODTTLnI3GDJh4Q8ssTpjA1W2Jmh7o8GWzbFbRBj9InEvsTAiNcCfp45H5GQlIRxsTaa
k5QtmR4WSqJESOseIISo84oieSpejjD9kjdZi40NRnIrfA3n4ZNjNbEc2J2ZNEvxOSIXk8hjg5V0
YJh/mHzj4Ya8mASyZKsDH/sbqpgkK3A1cm0FezKefiWEb0S60RRcM2aY+EpImM4eRum12zbA1jYm
gkd5GjipmWyhMePgyYuRXgawZs0KryLyYYmQjO6NTsNz2aGAol5GlB4Y9wRwRVMreEeDMHn4ONoW
FG8GzgpiwvjaFI+B72U0JGuRur4R5bPww0N8HCRqKMU4JMzp+EJCjsPTznj4K63MGZaVh5ICKwdO
EDMZeRi0T0SxoYzP2i8XJBibQdOoy0AdlWhKrQUp1lmJCYRNuWNjAo08iEuSNIj5FlbgWhgR7JC4
LJI6ZvyVN/AazsvQjeWI0WUayjLIxZgWhK4ZMmgtQeUhKjqE7OEh5y2ajwypuiTg0+A3wMl5HmaV
Fn4eR68mWQVo3sEqhoPZ7E/Swwj0MRta+OKYh/R1LCFp0ezISfYmSDyZMmtXx0Bbmx4ErNfIq3NC
eMjG9rskknEnkswQdh36RoLQ9GylaDUZyDGs7IbbZpDF4Lbo0kxfgw6XCFryTYUWsoadZMnrA0/+
GizkSg7hb9F+xG2rpEWRZPk0NDBJbY55C8MDasbywT2iuxsmn6LYsoklTjDzaHrWFyRuzQoxC6sm
bwdKc7GgULz2eTuS3wTeTaeSuZKGkvJgg1EP8G9QwEMNCzs+yY2Zig3HnZRqZ9nIIauRrI1Xs8Rp
tdDduCTlDGxgpImBPjQ3sNXOvg3ycjE/wURnyNBuezLgbiWE7Es/DYSzl4MN7EkvJm+D+CkgmvYu
BGUWhrYhkh7HG/gg2K8sbfnH3wJ5DcnRU14I8JGEvPwfAc2dKZRyiN8i2NGWvAlENRS/fwx3lEQ3
FbFwUQE27MnBHD4KvNH2TjQtn1xeDRWauxGJ6ph7JprdIKd3yMAm+mJHTYZYZKkngMPrKUgrsYTx
xGJiSfkc0yg6tegattiQMTHl5Z4DfZLn4UTAux4lJGAWRwh4eTDY8Qxo2sMUL4ERCqjAw9MjSoxF
aNKJGJB9HGhIqhWR2Hh4GgRsTGchkJMmYanwetC2bCRkzkcsbIQ0PIs6Og9I5DaJRsN6BE5G1oUb
HkJZghP4Tbn4JRWRkq6FI1nYla4Gs3kajAuwayYMTKsZYeR4+Egxg08uYX6E2UPGPhh5KLsVhqb+
B4I5DlwTFGY/obKky/gskeBUsMyCb77PLaGr8Hv4wZrJgdjNe3xNEh1IjYS/OzB52JRex3wI1GzM
vlgwUuRVIauXobqHg6LoqfodHXZt5JTmaJTQeHQqy5XxTpQbyNpmE4XjRYs6HvHosxRN50O4CbTy
NP0YZwJDdHEMhQNxoNhDNKjVI6K1TgaTQlZlrGjUfFgmlng0UyPLFnwcsi+RhsYeyKlJnZob6Jkh
PBGN4cyLvkqNLJsJNNig2D/Q8ckfIeoQ4WxMnkc6NJ24L/RlPI02twhpmiFkOCuRY/Aq0zkuRtHk
yY1U1y/i67LnwPERlJolfcGb0M3JQOILKZaZairJaXJsVDadWYExcOSd/wAC7M5hlUa9I0anobt6
GY0dRajX0PztUVlrhmkfOh/YU7O4eEcow5x7jgloZ9DqTJkhPNDdrQ8Cr0hJ0SjIq60WyJpgeJwe
WDC2xqn5EbyHSHmPY5JYHyEHN+BGK2VfIoE4Etsti8C1jgVvA+nhFmdjcU8CtmMQxMfDY36+BiDZ
kblymSmNkNdwqjJi+R8Q7yJxVnkVSIfqNtmfs/obobO0TcnP4L4RSVhey2PLQ2lT/wBfFyY26LTG
8TLqY1pFLWS5ktZGuENn1GNEN+UN0loyjyiqdGmRFutMSA/QhyiMImaIYf6in4RijSHKZB6V8Cby
GNXkYkmbR/Rk0YLkY3ur8GjjBu167MpVxeh3MFVpaJtxMPBlixk1yRR0VUUngeIPoRBTBGuBmceT
io6VIbQlGezwGU+ELGhD4Bc0bqhJB0K22y5GsNFTZMfwSGhbGLgaEiy/ink20PtbEq68MSwYYFzg
wg0eRGdRUKkslK8v4V9lGkaO7E1JRdhQcAsqaHl2bj2wf4NaCSrk0MbGOj+EU8i2PIy0SBOqJtiw
S2/Ck9tmF5G+BZRy+y5aamRu/DQ0OnT4PZZ6ErKvYlnQ+D7maiWHOFJX0vjPdHfCEhhLIgqYRnfH
xp+aIW1Z0JcSfRcDVxSoVOiT6JgFOC5xU32LIMSZ6GHvyLJsDhiONcjwImoQMBqopQqM9tjkJsrx
noRS8kQHYNS6YeiO/kSLd/RwwGzBga5eejdP4W1fgbd8CRYKMBZGButG55fRkAf8rEePULN2idXL
6IwJMg0b6GOxR/4Ktv5QwN/wYxiEGUdm4z7fw7a9DW6vUPEJGQabtT6JRiMIy9GQf8mdbF4Nvhy4
SOewyjyI4/4Z5vwRkOjNsX0JInl6MYAbJHbNyofwS7FVlM0Z2Ja2ORZq2FlZPwPjrTwR0X0L830M
4zwhd2OIaMOxDtXEMRr0ZINcsRF+Ai28pdd+CMCKMqnfgM4egypnbKlX5PoYGAVb0U16EL7iHoR9
h4l1TRg/dYGRaroS2r0oPjWudn12yKb8g1zLiswNq6DDB4I0crbhfl9CoiUoyQXBGlj4E5j8tD6y
l4QrBvoWuM/Bmj6oy9KynAvMhISfTRkm44Z1kkXYvcM8Fls83yU71C1uKMCe0ttoYJZND9aC2bm3
UGaOYeCrr7mYfjBYkFdGXDnMOhtYNVOw1rtcBdi6sYDz4RvYevAG2b8VEJyZ2sq0M56G4bT0O24O
kPA2IN8nHkeV8cmYl0YFrRBCd9B5kMT4b2qU0xkHDQuQ4yoON7FoeCT0PexvNEB//IZkjSE0wLDF
d6LWOpkXL+DT0PDYrYxwxMR8hWumBtHYvMbM8Ds2P9CeZwPYRyNfhhTI2kkOh5ZJCTbyZoyT4I+N
MfQTqIYyNlylwRMYCQ8BnY3Ep4ZF22eH6ZQ0TsmhMCSuyE8ifJqUvQeJs2J1dwqhPZNia4eTBBNs
PzjOWhliNJ7b/RnGTN5whyx2PQg26mBClhbNyvUbw5kejDQlsxReTEyJhyfQaXwLK0qJK6oaZcqx
wpEmS+SUeBJ3lhqOIOYsWGKzfBMwITFR+ikZtuAWW0sZIXojfAeoYV7A/wBlLgYLhe2IaUlNsrtl
9JCPtx4FJJVzLaM8XwhZ7B7RMUqbhDy6hJlqw0oKrDwQazahlhN6NONwhSx7TqMuEM7SL0TaSXIm
ddWCIp2hIPDZDfTeEjU5dmS+4w38JCEbq3BAX3loRCJdB5ztDrZB6YnVaQaI3bOsHDlNB+B9aYt6
NKF9CW0zL5dKERs9kvK9sjKZ+khfUKhwWTlsuXOktjRkyDTlbZLUl4GK7WHyVwWcBbUx4RZk2thj
KHaReWwwipUlLHSJcCPGNLeyKKyqjiGxOt0aqcuhAAfZRkzJWB0hDxplybczwoLruVIwpgqpnZwl
KTYxEtrS4Moo28witS4EhZVaxyPPuGsFErPBC2HIckR+nXgR1uRtg7gYRq84ZwsoQsGoTY+1PT+7
0pVfEgsMMRpYMHznYozXhGh5yIb0W12JLlMjBw3vAkV3iuUcWF1wWx5LlgQnZc6JsZgpLAr0t4Kj
7JrkTGMsJBPt8F+xo/owZjroJE6VBKw2sIVQuYyVmmo+RIE71sb05NIcFo2EP+TgQXHZkNNTwLsJ
3gekiyoJzhYEoqNb05vA5qTUTPY2oGSwhKuSoqpkjw2OXhFcG8J0VfDwJNJjebSlyOyCRV4Gg0RB
hQ0FLKLx+li+B7+FqybIk/nPPBliOs0xotplEZQ6qPgbKYwJbRrJGinCaPaGRKpmnnRt4FmSjehu
+yZEHIXJX+vgz0JUTrErHWPM4GS35LZBJ5NGZgaCwVCZJxCzBu0TUeDb6L0J4yy3wMGKsGLLxEyD
eA10PgZC1QfbRmBRpmVg5+Gs4M8Iw2FTbY2Ht+S6bMtTs0FPNDqhrtoNC8DfuB8XbKEmNtdC32x0
PQxLLbxBxoyYvmC67gQ7PgyW4Q0IKuwmtmC6TGP2NWRAVpiaEDyqjvFbpFNlrmiQH5jejW9Fyu6j
A5U46JO/6bGaP8BRTXgk+2DE8HQzSLxijUIzljQnFngQLG28NbEFXPkMpXohJQvZmR+WOIl0oyPF
5HtSmGLTD+3EECde+DN+8D+y9QVd94FBV8oWZxejSai5MVEaqTwNiVfTUbnB3DMp+hh3bpUQDOxR
TeSgh2AcWKkNqsOY/wDRql59hmivgXqO5C0TimrGGFEikhRRZG0oVSaDY4memHjI0uWKwF08DXlu
iZIjSs7ETPdwRU7+wQ3RGdJcciS+EeQ8+EhjWLHBJQJWFVFUrghKzz0MADJNIWRiuxJagj2Ta8MD
7M5RASezi3LsMMg+DopBKl2zIwpyfWw5e+4GKSg4PelEMXXklgbzOnBWDCmhO0tF9DU9s2xoR5nA
XfkrMR36XkXA43wzEB+8SKhRIlJNWEl1sRX5qq9DMxsQJ6a+Hse2+B9nYJHJXahhs2eAi2bTOR9r
Kt6JcHQhRdYARUKwUYlJOMjcmJt2eXxIQiXEeU3wA0FUnIgwWSHSL4DmFZY9gJkncn1vgpjCQ8DU
dUYdydpnQ+GEEmN6rlNPQuaJxIyTi4V2QPK6MjyTwJgtjUs+TwYq5NmBZZSJpHxckIuxI9jZwKn4
6Fevo5+iNrtDpmZx5FvLEMmbDX58YbHsbNMhq9Fo+TTsrXBUm8kV7NBtPBg+zQfkO2FroeGNpfEr
O2J4EsDaTGvIiZ8DRYFz4G7oSItBvBKNwbeR00OV/GS8iWIcrgaPIS1Rtpg2XB59CHUKshlLsaCe
obJn0H4wUZj6Fcoq3vBld/AmkxhTNnw6GwPRsFVvY+VyWIePBDT2cljHhTHDNZ3gV2NSUQfHZs6W
hBZvfy2TKjgjJtYxptnOzCcI4Dt+S3ROLUH1Q2RM0GrUmnsNqF7YR9Lse/oMZjNDV3vobmKERSSU
MtSKjabUbmOC0aqsVmxZYEuarK8jPl7GnVY6mx86x2KgTZVyLBG/Y4+koreA0m7WpwEFZy5GkS1F
wTtU6iRTiF5Ajq5bsh2mgG/9jJYE5EUx00pjB98YpodEguhbclhu7jtNdLGmQZvlIY1HkP7acQnm
+sLfG+Q0pDW3RvC528C6eOkThifcYndcJoTMWQGDX22J9HkmFpZCJhhl5VxfaKNJHB8aDmt9hobM
ahiw7E8iO8p3NCJavLHJmun2I7E5DY06XzR/vOyCfZMzqqlLicqrF6x4qH89vIXlc2Jiijxo8Fub
CEiQp1yJylhsNFQnfB4HGyfjbOx52XYZ4IBk7OzAB84MbuShRiXyL/dIoRva1hkY8DaMMDvkYFKT
4gn4bM9EJqThsepqGgO8FaywmiEjBnB+2qh4NOKi7eFV8FgWbcyubdlUFmZF2jqH+6eBvibbH1qe
DG+J8ZIUfNYXukZ7JbdMwemng24wES36Fz1KQS0xYVHqcB26z7MYxoUnxIPu6KbYkdFwYtaBXQmr
O74Eid3gS5FBFBxGNHKnkh2KcCTrJAtxr6Pj2pTRelcQmsXMG4Mrein29jWx9tDwweRBp9ImTt+T
J9uowTAXDE4o8PrKZ27Fc9uDNlDXUS1hweig3HLY1eOBOkqMtzohkWwlsw0Lk6hRz+EWhPD+Gk2X
IktDqQyjJCRweRisimyW8EhQxDBiywNmi4EsGiY2gsI8BJyPTFVsqQxp2OJkGWTB5NkVHgz9hueB
if8ADPRkLKHIvRikN0T/AEbxevjOS0sXwjRMmXJzWy0IexWyxUbdKln4WKib3TJ7NnAlMsmKJoNX
ZW2OihrEP9DcwPQzn/BVdvBmwSwZF5L4Epyht0bKNGYP4exwMtRmio8hafgcVuXwqc/ClkxEvsKc
r9jypi2mvwNzWzlDvB6oqqx6No/Bjlj4YnrpbwIzeKJR3iQsMA2muQ8zew47wNdDbyj2SWWSM52P
QP3DMENk4hI4ZMD3RZ7wZ6Y1YY+wqI8IbbH9CQJtLOjoiCLwNtvIqJNjywSoaaJmxUV+yto2yO0W
DDl+g4SU/g3iUPI+ho6oKVRDayYqtHM2PehKcFW8CipWMcoZka0siIWQTu/gQG46x9BOKCyKCyNK
jlGYQwZMhZaG6lDoLWTyhO3gs2PuikbHzkhOFAlQzexO1wMij8hRK7FBfgyhs5JUe3gjr4DfQWGz
E6E23gxcpDwI4tFLNmKZumW2eKeJhgdSZwU52OoVyHoTZl8Qra8GRdDF+hglPTNjuirK/DlXfQyT
rLhdGMjS0T8+DVXkqaLInQsRsas8iwoPiZIoQvM06Nct1FGsszh7EreDnaGOFG8m2hveCpk5eRFy
c6EqZhK2SYM0pXouUb2R4yZHaGRnHwe8CagzIZp5JbkyJj7KQry8CnQhqclRsPaYzeUJh0Jg4jFG
xnQSKMlE8kEecCz4TI8EIYENEk7Kg1Xo3GEuGXJv4ePgkhSsK+Q5LSipbJmkzfh5o2JUjwRke1wP
rYvJmfQ6cQ/IgyzyVs39F+Az2mCfIzTJqMlGNuRJniFdaGOVhpIdIVcDQwohGtvTZjgcdxMSPD0H
O+B7hQYgVYxYIDaLA1UPaDWJqEBJolKop5GlwUD6CH4cEAVYs5sM6HUHsUUN5GUVJSfbZCKnnY1Y
t5Y1KxjcBhOGThjkWGxWiRvXwjAptFpYFe5nrAjeQgSpuC05Ws8iVVGDUk75G9TfBhFekY9kc0Yz
VnBizThVlAe5iEmJcMmf+dbNo0yMbU4uB6TUKot/RchPJlzowqRlJM0MUMjecC3FEiYhjz9ihm40
HoxNcmVbMMQrE0PGOCsTCTWfhqYE0dmU8MZyb0SuRsKExvJnA8J4NEoOBOI5GJnLHeDYWRRYIjwP
lobuDOrg0sCvn4ZKIysvA1TEs1j7FDXItHRdEr2Es9mn4FXzgcWL8OCCIti/3Cmtn8DwoJ//ANFq
OB3Nwct4Ns8EHb6EolYZm6NNDQ8jEZdRfQxS0NzZMLkh4LiaQ38KM2ci866OrBsaIdVODZDWI9ES
8DeR+zlDyYkqO54nwtFnLwUUkMrXHA19Ez8coSQwthq6GhExTGJ5wzDohLOTim8C7HkWEPfisJFC
WJRnQh4zyN6hXyLJ5HbzkW8j/hcLoYESUHn2djLIdeRv0FiuR7bI/wDwMGYphPCGNYNuCpcujD/y
PQi4FYXLKu6YeORPDRrQXIjfgWFS2Ecg8hryLZRtzYoT7FnDQ9mTZvkTmORQ9UdW8GLx2U2rrKYP
pM5yYxUuUPplpnHo0QHf2oeq3SDRJ3BAswafAk1R1iCV05DtmxjwMz76O5Ay5YxU1HDSGag0M91R
0lLTouHB0eKG6RCljozuRWcEUJQpk+Gx8TgoVa8iALqoYAqZY8kvZk0bWmLzxPwbufo248Io8exO
AvcGtQq6HqUaFbQV7ZEgLxDJiEqMDW3IahEenIp3JB1vC7HfhX9KGa/cJcHEdtPkauWCGGm4LyK8
c9C09doupRrySVZ5QtJJJ6MJ+WnkdWOMjt3EcoRvOxm0XHoTQTiyxPOBobfow5HnexqBpyFQ3wLi
EKQ1UYZ5EzklxyUspbRhyN5o82M24SeiHsTSbcOIO8jnwUSrejIeK2WlG6sDwyOiyIn5G2vDoSDP
ss9/CTKGXpiwHivvA7aK0p1s0tngnNyNHzB0QS7E1psflgSdq0PHOTLXIWw6cD74g3kZplfexPFE
f+BUlwy2+xgWCTMjitHQoO00OeiMCzkbuORNX/gqloeYdAleWxI0YCb6Fkei1vJkmxzIaEc39Hke
Q2mKY0oWM20esiC/BNhxHgIkJt3gaDJYZYxBN0ehY2Wb0LOx34LLJqw2+HKuhp1+DdFx8jy/InnJ
4HoOw1WHhBYQ9HPoT3RNNeUPIwV5KE0h1hsZoO0yNyDjHwJkTUGjSwJZowlkv0O3pDyXCDzkz3sZ
ob9qaSC2Q9iII1gxVs+sDTCOS1TYjWUa5Gw5EbEXZiLyNLh0WINuYL8Ks4+DcFrkRPf4PKFYPo5+
wRPLRgqhnluDrlc4HaE6JoJxdciQUKeMyLdC59XInsGLhbXo9owYGnGTMVjkLa3KSEtN9juNtLox
UEh3FdOiijsIF6sWEFyKnkocnjHsVJhYJXSPAy4s8h9VZeyGOl20CuCLkUZiTYQCWOmcsuIu60Y6
sJVo7uhBwySBtRYoztIyb5N84GXSFE3nCGmnYZOvSWTx8wL9P35MK5xPcmfyiN3JN2RUuI9rWiaS
8sStrsegx9l4Jyo8ivk2+CkXikSRlu6GtBIPJGwnI3kyzOQV3YulFvIixDT2ZulfOxZUa3yL+hFS
jpeRJpKs4BRvOiOBEzEFVjqDyskEL6Cc8kWIZ5YqG6UHYqREaikS+BKN6RYl5GsV5ISlG29dlJoa
NjkQ6USG2h48FVT7HkgmkzlLYOoOBIMc7JkSaVG00SxBJYbG2sIyQzY2kxfJsyZMZEzzrA+PiVUp
PXx2LgcyMffxeRrhErQ4ngxDwEx5FaNZ8TS2JGIbzBZg9hNZHgWCFhiyH0+Ek4Eo8kqJGi5FlnA8
CqJx40N0RdkKvj4P9B9M4F4cGnkxKE0I66Pw6V6POPPQnXs2+jpRpoeTjz8MY5M1BNswnwWnn6H0
jIvQttHCiVeBODyF80mITImx5QtbHPsJ58HFEspiEoJJBQM3BY6xrSGWxeCxiq5yNJZRTSZp8WOG
ORpYIWFYfY3FPYWvkniNoG8DoUrVNU4jJB1ipjLgps0Lc+ExEFsYN64Y96LUNMjAgrOuQ+6ZGpVZ
FJMQeK5ZYWA96VexFF8lFSqGpVYu5kHbWnyYuIWXQszc1GVCiOxWPPN6FwW5kaFOQtZPQm6uw7v6
UYXg/gpTeKL6usrzONjNSU5C80cj4QWZ4GufIhWDkNf0StqxDarYRW57E7o4EjBkPoOLXkSeBCsb
D9ivA+PjILi7HpnXmE9m58HoKWhpUnkGfgjNKHgYaU2lsLWajznZgw65iDGhsSLwJB4EjRpGyILH
oXxmsjpXQl5JZRuxC+DbosiXwOEhj7Fl1mXeKaGm9EachC5GaY0ktm4JNjmxhPDEnkyGg4OBoN5O
xjEnHkfLI36HEHUNuZ0LPIuYq0JlKJM3wbvGh6PIJRGtbHTg9OxMJzPCFddDoiS3TBnHgirb4K9F
NG7iDxyPAwTkl2NYwJ0wvY49jyRtDRTgiWRqMGFLNcCv2P8Ao1n4YhzRuRNNIesYGqVJbHngQ/Ki
WDQQqJY9CeYkOmNoWVgYWjWExYNIyqOHgPA9CZMngTrxoX4YbTaIuWRIyIY6WxazcCeKR8No48iT
8BoSxjp52Yy6dqNVCbAmB2UrdDWDbJGPpF/+T6OCORM+DTfZY0MTl2N9juB4XY7CxGlOaxskpya3
svRY52JGZ6HU8Oowt+BUkmL0Bs+2NOubE/sPx0VMFCT6MprocTOgwJ2onBWa0omWClcDsTNINhXO
AkFn07GodVYVEpLcuEr8kDTTzJVt3g5yVhm89SMn9RXchSBrDyPavkR5fBTxVkQMCohoFH2jebwL
ECWTFeP2e9NF5yqCli3EaHNtEHpos2DDFbRjwLNdCy3nUXIqFXsbFwZoYEHLWjAUGxOhEFqkHZTP
8Fdt9RyOF2QjJcD0VButnBdupYi1kgWWDP4al0JVL6aNB1xhsZbK7FCf0YtadQXLLMlRIQW92lyP
w5RijioXzbIzQ+EUZXoqbKTpkS5exHPJywLUEs0pwJmMwY/t8CtgjhI4SaCQJ0cCa5wVkYVQ6PJc
ovWTNmDOTYaMo0JXBFWB8xrI9CUwfEUzliqtoVJsd9x18VsjE+xyjBig3SV9GwW/YlecDOFwsD5E
+CIhgsFzkdOItNi/RTZIwIhNN52OvsGze6NO/GZyVtjYsjNdkJjVidG75NCUE8iaGxchyPBwENx0
y5MoUxqRwjLRkGD0UOPho0xg6QoECdQklBSHRgby5PEK/QbHingSwPfYTsTOzlrbMULPQ7Gk5EMc
4Ofh5EpjY1EJ6I2yNclq8iwZKNphusUayOrTHkea6G4/BycuhLGxNKj5CTeaaJc0R2DyKXJFZG+T
llk8j5DcOaZD/QTdhs8/DjImKP0htCyxji2CZeT2MbpTaTGJ9mGvjSDV30TyJ4K/oarNBVqrn4ZE
WxGsSS9GB2IcMgmSDM4U1+8MoukbK+YU0tLwbk/RSv4jXLN9QQxSKcuyJtss6MFhCmhMCbBKWJRE
dm1S/wCmMDyClKPY4iyKKn2Ntr+CZbG98CTT+AlnGBQSo+u/oyYFlWG5olrTLIhid6FC6TVIDd7G
E/qjbdES8QwrSvQTf+xmaD7oSm3CEuauR+A1gNM5Ecok+OCkxgUexvwGNahaFC7Y+07yItK7Miiy
KpDIGXRkhbypOZYx6RuA5tE3R4DutxGqE+w2LOFJtOypDYn5D2LroccFDNi7kGVwNA3bsiIvUZVx
krKJrGgkKQeq+B+2CzEx9/oa0+uy9O1YSQrlb7F3N6fAxt4OY8iQyYNBjkka4ESGz1oazg3+F4PQ
2neiYwZIayZLT/0DRYEqmhJ4seKhTDYw9EL9Dl9jXAaUpg/AoZGZe30ZmEJ8CJbzBoZRdGhcEZDp
EUgqWBKLQ060jaCS8jZyVBTXZX9G0Gl2PyImhuNkeUPOxOp8HsDbGIyN+ii3ySYTpgiAesyQnnIs
eSDhipcDRcKW4EuzljbUaMkJ5E8rgw1kbJQfmEwhszTNOIehUMkDrgXULWhF8HeRNskWWb0X4a8/
Bx+1wdnJkNCKxDOQWoayzL0UbTNlJybHQma2JYjJG+iRdiSWzPaG0EIHZlIaNIuhi1yVtMEcD26T
Y5ogyZyNWJmMGVCzhDjIUeaWrFFgLbrPRmLkaeRFXNX4JGyydCsZM0hDdH1gxG4Mm9w39FyRIlW0
tlWludFcSFe4G9oankxi3/g1y0dOhWssbsZo1yNAe8C03ymWRjiHMd4HVUYMclgzo/wbGHlJfUGV
w0vQi1ddE0MpHAoTDVMtC87HxgcoSzQ/YbFj4ILLh+RBlzqkSRuXGiYF6cDGjhWC++mxX4iCpX0R
hU/BcGb9CGrVswxq2Q54+hhCQNtjXxFO5vQhDMNhn0EhM+kPLaaetE7M9CkzgaVhcinpgtlH2PwT
JAMCwNgykr4LhJ0KyWxRUn6FG++jV5Clvupi4Q+fI1MiNA5E12Z19lIMfRnCEHMawZVt+CuzfgrM
ydQZM5eDBZN50XNXbsi51zCgmB45TSjHdHBbtFd4NQGvwyRCy11D/OlkhNhJeSG1OHgZDGYuTGxd
jPzLAxiXhChmnfHRVxzsbOYkXIolqQRHTPwEFErknIngJeTAhlyPow9/DacwxN+DwbvdEw8jTT3g
aexwov0OCLRieWcmt6G8RGuGRryS6cY960xWybx6EuW2NRxaFhjQkOXA1U5HnaCfIwlXWWPr4WE+
WzQ5yydEQ8Pg3jJBvwQTwNDQwex4zyJueRLGy7Ow3UIZWw6Gmzkk5NuND0IKsxuaFeSTIsHN24aZ
QkXgTwN8InDHhCt6GcyUnJt9jz4NrSxVi4yVgJVnDplaJsOvgzpicEitNwoWvZyONNmbG4kgqwzt
DdOdDqawNVoeSUwNgUY5Ni+HHkjWRZMabEm6myYIlgTvv45WcDSE1BseRYyN/Y8w5Fgb7Cbkb+2Z
bNmZEqqOTLGnBRazs37FoN5aPZwxVM1HDLPsS1Ai7XCk4ts9aEBYhgMyglrQrJxLXBDBLkTWofIs
I8U+QkfKgubWYNWKtNDozD9hBVVaG1cNsZ4MOf3ZD14gyrWWWM2G8j61pB6jFEbCUHaPPHwOzVmx
FrgEteLE9hibslm3izCwHMo7xG08DszI56KNonOzqCovFJh+bXCrHazcjjDWEOqiLXwKPYWH4qLp
YJEXW3JgtlagzrWpJJM4sDQ1ODVNh9lLkXSSQgkiTyoQYy4FoKCvZRPIVi/ckbK8jmDdq0mRldiE
VLcwR5DS4QryEwROTwxoZe6pTX5MmzRjFawaFf1UTbWxTFpm4bvwQSnXFETdFswGyStGjDMdHAlW
42aLJOiPGxUjJa0I2b8ao+VNLDLRTeBtT1CqG3pIxhcDqc0x5ORKguqKli+SJ8ngtGJp5NWgChMO
2kYveR8XTRdfPI0OOJDcaKzHUh4zRACktZZ0UHgi7aM2NzDEsm+xpTHwNVfRhLLHefZmrfoz3sSj
2bbVZ4/osqbJkm8bLUNba/BcijlwLCycP9M8GvZ6INVgTgnicjefBDwNXfwWGqDlFQnUeBsYMLrM
0z0ex4ObI55MBODqRCQ5oyORsTDbrEvJlDBg2dClznBkSx5KF2ZKzIs02G1FdkexLkWhuDeabDum
inBwNaVEqiGTL2JTDaE+y1Msavk08iaeTQPkuRYY4RQvgaybCVeTyGp0N76OQnnBmoibwMcGXAjF
MHpmKjLjTwNNL7HeeR2dsaEgKsDQkZwGhPHkrIybL2P+jiseiU8jJNjZ+CTameR6EoPL2MtfYnn4
YLGROlnRVVm2S5IbwO0bxeTKNIlTI1V86GZxgMPLbgYHNjdqryEqVFYzRrdN0dVbZgxtquvjK0zT
/SnPwrbBjvk9SHMqyTFX2OSWaxr4Qz7F5EiRzTzpYU9yz4GmKeDb8nk/xKqnjAvRjx0PVHU8iNMZ
k215Fu2mhUG2Jce4ZmFlamyFzs4SMhYEe2JdMWdxBdlquBOhLsvckjJakETgE5YN1F7LSbODGA1N
mAJgHl0ajW4Mw8rTGd0XgovByh2NTWjqXCpToPabXS6FDHNH6QNXMkal7QMnbTClSckoRtQcSvsU
92h5YPwI0i2I20sDp9xkrYSLteScF01RSs+S11RI8gw3lYzFYYl8JTSwuR+XyCzr2Q9xVV1jKf6b
J09JQI0pcRELLoZy9mIVV5PwZDsfsRgJrk6HEDTcElwNZJNjA8j6IXNtbfkT48tnL1NRLI9Nhpvf
RyW0UxyJY6JfAnJFibXQ4+xsGtOWPDMMcl6IXIc3gg8qCx2QolTGERNOYGuDMoMUZCaIXtCeGKyR
BJ/RUHWuPg3BSafBDfTsWyMniF8YGzYnfY3GN1HIfYN6NtmMvob8INtexY0MmdG41i8ieey/oxbE
TzTFGWjJobOjQ5hsP4XJG0Jd4IhuCZE/v4fwO1N4cKCVGVkbG15FD+BHB/p5DTtJ0cBgICVZHliR
dEsYokxkpHJmpGJqnA3g0hqBJx1mxY0zga4GrzskDc8lGe6LB0LnocSL4ZBeSx/CUwfwE7yazsWx
WI8ZLl1ibHgjWxjsVTaQ/Gd/GQFDWcDmwWSPEMEGymBtVmz47E1bQ/OnDaEnN76DQnHRiLt3wUSy
0+BYBbAXMb0XLl6GUIalCs1uuGPUl/4HbkQiJ58h6wcBvGObUPTISgTsasNcFBlWMUCjbY2TP+y+
BJUUsXyZ2AUYNYFcjBP7Rd5E2xfZQKiUIwx7Cl/aCcTNaLlDvQyUdWiM7nwCv40mKAspjgsj8lgh
gqQNxXLFkRHeFdhAi/MGlrhWhc4S0nTb14aNmKCv7B6x7MVl38QYVG5248nrOhH4OGLt7BlL6Uxy
Fhq8kr1Ngztfh0F6aEDBu+At+WYKSaLNGfFZZ5ZuDKzYGcWEESRVwGD45I2R7apVK3A2o34SHt/g
VUt0f84ES6RMKmN1ydDJ86Y8VvIqLtvhDCuIkWdXb0Msm5yZeFUieSYvuHVCiZgvaMx67RXSjZ/8
BU1GdbeGIpeXyHOVWPSgUwFCq8kRpjqgl4HJTU1N9DN55Do4lgu6geYM2JiKIJtN1CUzFMDVssab
ZGHcQsBLngVetGUQI6/wUyKsVFUo01hiotXHXwpPuj0MiQywQzP2XY3kkENeOimCGgSvKMpcEtXk
vwSosoOXgZsTdEU01jAyQt5GuhVPB/Xxtf8ARUH6+GLKrYXjQ1RpodeBvJWJbmRvPgRjoMaOgiUJ
0yDwJsqNVnZgbw8kzkufA2rg3ITPJCxCXAjSltWhgk74OJngjaeiirJS5NkpwLIktY1TAHkTCb2e
B5YO5U/h8hHT/R8x2kZFBu04G4/Bl2PKwLGxqN2HD4Kr38E5DTSwLmyY2JTyYYLkb5TjLWqPA0zE
gpgaB9mXwJqosV+EHg2MhXZhDY+jJGVBvS7Mv/0b9jSGDbqz4PYZCNaWydhi1pbF/OTml6Hpt+h7
pXjIlqWPAyyszSrXQ1uy9IReVGXr2JhJ+SHGicUjzGDDJoc4PQkRmwF9irJ1VfY3J/oJ8CB/2Jjt
csdSUs9irbZGotOhpvQSeUJONp6YtQi6i0Vu9iN/+wqty9lwV+mPDIQhDz7NrJTeDDATKXijh1fq
OAfK2Gait7YiIm6kcOumHj8GaPY5C8tBvlAfDowkHwm39ktL7ErkyXy3sN5xgY6F4G0/YCpM8Yop
V0E0T1D1LqHuBNwx236U5K2umycVvst/8HJl6bKTLq6EZO32LOSXKbouxc0pxwdieC2Ei5j5F+Gz
ezfLYqag+R+hQ/8Apj1SIuFWykmsxibbCW7ka6+jNDDZVEtMvIzbNARSCNUkIr2ZLuXtlKamFwOb
QqMxkWk2YzS/hikoLVDr1DwvhDKfQlwlPJny6ZGWjUx2J6Fayl8A5M4FqIY32xM3xFXlzB+w22G3
ETb5HwesMdMxGmim0LIfgyMvB/REvKExOkdRgKS88DU8scZjTD1LTBZ3Pg3fRNcobj9CdecjpaHg
FzRKLY3gWpTLt0LD1RlhpSjcJUPyO1yRMntBG8nJsSuhEuRuDXoOEHU8kwRMn2FjkT2YT0PJrkRT
v4KqWMtcehKuzRwJqQ2vJgQ4jLwOiPKbxRibUw1JU1fg00gr8GaeNDvT4TwSz4rtsbNn9F+o2YC7
MfZxTmcmFrsjwjRfJj4Jk0KzJLsJqCWRWWKo5JsyDbhtrJbxkbwh7iyVyJwboxSB2CGZDzQoqltm
lOhTlNsf0r9mZQmopCvw+4hWxCvsQWDtRIyC0Z3gQ7uzfLKFE1GK7M1KJZ1XsXunQ1aBkpKMLuQw
rKv4zCB9DEvBMog8GZtxE1fUeK/wUYesMbWT/qhnqJaR6LVvPRqk4bNMR256GnjCpVkcq/BWSKxC
NMCUbEEqwTVL9C+ti0uGolkS+XgvysaZT9HPPwa0VCmyinL9I/8AERU0PcN7HkwELcJqUguGq9MS
2SdjwkoHE6/0KaagmrfkUIZbSHLI3kQWn+pEPyIr/AaNeSSGZmT8nM3RhGN+hnpFpG/IlNmPc3C/
9AlvP0KPT0LcD9CSk4KNVrwWZb6M3aFWU1BjcfgXmnc8D0GXDG1U77QgImm4HgDQsofQQ2nTufQU
krb8I5GG+ma8IzdvRmb58F03DzByw01e0Kd02mzVP6CLlehE3LtBIUm6Ia518oyqruGAa+h9hvA2
6XcHXJ+jfaPod4r4I5i7BvTLvBuReJIrNb2KYsbWx9cnHd2hxJHIQL93Jj0vAdxpZgSWD7aMOZ50
LXm2ukYDSuqtjXCeYI6x9Q3HaEesPIzeV4nJ1GmUWYdEh2/LGi2q8ws74QRy1Z4GGe66FW/wuxI1
R3YfGl8D69YKXxUL3E+h4Nj3v9Mc2N2iR45EnstFy+HBQ00XCDVDfsPKNlbKlZ2uS4yJ9GCVC4VG
fIdgnkaZiNJdjorEHlBh55wNwcJg4K09H4N5dkFkWu6SeiiSDX+7+CUeyJodoqVY9DynDgarGhtC
Tzk8nkjOg/wVjYn/AETdyTm/QtkJtjvY15FheSztRnrQuOxSj0b5FkEzqjGCbfI3gZMjxkvIl5wP
HBkmRP8A9jDnJHumpcMr6G7HPwbxn4vCvY2ZlZFR/DhQaw8/C4PcLfS5HOaZAGbEqyWjoacjzsil
yZgMyVLghFI+ohWqGIhjKEDCLjgclt5PokE0SdzGX/bAqY54HGJsyS5E/O91QZkV25E2LAijOVSq
raYu7PBqy7grmSfhEMGbRn012yZniQ+JeRMTHmxQypVnscYxy2iVWU4QpXAXqsvGhMTZ8IlXnDHD
WcCus6IciUvI1PaYQamIbwEIWMO9YHjSHiocYFoWLBKkZqENFTfwdCS+O7GFWGjapHbZ9yBIcN34
SF4i8rJtTekHzb0lswIS7bGRfghzb3WzDZIP528sFHPIJ1Gti1/Y4VFrWXIwwXNRZ67xlnHQ42Qp
W5hT6LxzSKq5uCIvEDEbSdYvMU1ZMjGDPSCKqLtlHUlcBibzSFWeR3NCokJhlBaQTm2RG8GSwUvI
uJk1oNJkX323SFRW80LcbkQ1bGMDq2VvAnNnNimb0olrmr0ISgaz2JrQtgiNnCRh1WuUJHd/A8T0
ESxmK1tn83iG8JyJDCO0cig7sjDTIpwRlHW3wIiJOA/4/C5o85lhQQLK7hLzZLgOJLoQvCZa4OPx
t4Ia6cRIUFHeaUa0uGqJFR94kEI15a5GZtXpGWnk2hiARluByTcxJlHURoiA3qX/AEMzeA2E8GxV
aXU5knoWG21AsnK3YrcrmidDSRLBUZ8GmCpY4ouBM6dG/Y8JldpUnS62uxfUQ02ZXF7aWEO5yUaE
A5SpofVc1wF7UNJoLwo6TwD8fjJglXmHktieDN40cB4mhVB8wrQruNm1nY8eTbwPCEnaiJliXgeE
NEK1zTkXSp4HhYF4GiZJh8vsgmbot9GGGcHUVRmiGkl5MqHwPEVlHmxKnMoghsbG6hyEnPIhrInh
5FhbOUZb2cZY2uD7Ha7s6BvGjQpRxHg1jgZbw6G6JPA8TGjZ2dUaxFz6Lge/AnfQ3xwa8jR7MM7M
RifgdeGiQNU3scG3g+xbG0/hSeWfwUVpCz4IxpPkek2PHstXkW8jSRoNf6EFPYymN2zjwZT0FBJU
eGPR8lcjy7HlsyYs9ixkyUb7Eo7BE9mYdExDApDMp5D18gzd8h39I0BFokTnSm+II+SRiZuhhcub
J5ZOQ/ckeUeftourAH3w/A4LdOGOJgvTMmSoTJHeGGhnaomdXsMajb2iqqhj6Bfae4gk/chyNjNp
ODyu5JZJeWPzdgXNphiY/Cs9HQE+co9DCSJ5HA+SQ3wXgVXzKF9Oi4Qo4nd/CqNrfwyo4W0HFVtd
se8gMNUXXBA7K83gTr6UHBYkSN3owdPKQaSOZBMVZhIjz5WOzbvaiwt2PIge9jTn6TM2mZCGR3gY
cqVvyPTHi0JBy7bg/tCG7+oEdo3Y7STyg8v/AFjlYdTKK4aXL0LulXCPGgorpPXLKmQuKGaDPTyM
/FpPFHQeAh3sqDLP7igr/wCoMMqrjhDnVI5FcF2wz/RaF/6wT3vQKYvUInT2locKK+GkKREmbont
PUokRrYBJxdwUWLIYTlF2+0klPXJ7E/rLGSs1jbgZY3Vo5ui7iLuTth+d+QanrpCIqqOCHdLOCES
DnBLF6DMiarTchVf2AKVq3JyL6itYujof8qCMTovkapHXYbh0+wH5nBZg1zdDONekimgCNr48qFM
EjepxRcsZGsSabyKme4EETUKVZ5GoozYDxBzdNMl1JcieAyI/kN8lCFjPjnljcqctsJSdtIMSkXP
ocpLa8GCughuV24zGRp0CH2YIbzSNPA8DvsblQz9n6ZtQofAN4eTDMDB+D8RRlsa5BJdmXgdQeUj
IWD0MliVIPZPNEMLvgmbfgxUPA8LsWciYGbbO9UayYsv2YJ9vkukcDRMZ2JpcHJwSPDEzsSd9DQN
yGmf6N4QsxdsubTBCWbtDVuDcesCQusD/B49mWhqUyeQuRZ9DRoXNE/spqeBvsdjYk15EBkNcmTy
MVmRq0qFQ1Q2+fiSNmAdg1ldCTKYj0+KltjJ/wDRipDdfBNYbLTlkrgXgLDd4KMYMNSxPQv+xlgN
1szYOnABhesxXY2I47FmlHxyZJzMGGmQkCTHZX4+nAab42MQ7THnb40mPtteRNWXQZFbPXwGIsPZ
LPeyyiE2dJckxvc5Gm1djRgR+RbDuDEIvgwxAmpRIJFrcshEtgJJ4cRdbyMnR3jLEJfwGtvzwM1+
pUOFGXWUITI44iNsqMHZjO17EFatgbwjEuN6E03q5GJntEAvQGvYlHsutDPnuGGSM5obPipjv+uB
J9A6kdA780D6zXkVHl2IEiWrMqG7WNpqJ5Q7qzE53UOBR0qdnjKZeWqiFOLYnGu5YgqK1gTGbhUH
t4saLYni5P8AT8hESj32LF6S7pdkvb4LBnawUIgEuyaJoVvg4YY0V5KMentWiSCpROiS+bbBmr4j
jyLnEV0Z8mBEKPM5JRmkmD9RPAxO7UrG1kKPkJShwbCWiFU7HbIvQtYK/R9wY8mY6eW0JXC2IZu1
l2dQJCJYlSYG+O7orAxVwiQqtcjnB8ASdER8jA3FLyID7XKScQ3W+8DVvu3FLdzWci9YZcjlsA6U
2vGZGMbzJL7nEIuqHyMU59ui5tCcJCW/C/c3ZFKnAYTgduwN4RgW5PmOS3MnslCMVxGPa9lBrjO2
D5OLxgLCscE0XoPmxoFtpyLWDabNHdGW40LqKqt3ltkjSrR8Cnlokh+WbC2RvvCIjs1VX/DjSbXZ
mzzNCNv6UaBArAOjf5B4ZnLkW+hPOywoluRTBv7LENtPz2TnbEhvDrVMFhlcu+h0wNNLDLFZqEFW
hrFK2S7g15wNZS2T9DSS2RxPJ+gnBkwZIcNdEycPcOhR6dicezN2QaA09iyr4IRvTony/gTQ4Ooc
eR1OSUTMPwVzOiGxDCFQ4iQ0o1fh0uRYY8tj6FsvFE6lyNxSieDQ5NeBcwvIU5fxN9hNe3xHPgLO
hJFaJzRThq2XoTMjocblgkli0UH4LU8iZxlHhYQktDTWEZECfBDduTko8YjWM4SHFgxDbI2YJyMC
fCGxrFg5jRYuw/oMJPxRRQetQ0ZGfYqFkGA3+sT4aOgObyWbtzgpVJrBRcYaMY7tmSa/YuC5M5lm
3k0UeV02G85Hhgl8sjySTFydwZbCbptmczJanwx1FktXvsTYnbyXOxu2Ltg832ZXBfsPE0Jgnlje
U2xvMpRLFNGUYsj1pjQq8N01geI2LdBXsZqDZVM+SusmxNcwxvobd8dnR5E80akv9LJ0VS61/g30
N6sy6GCbwpDGSwdbeSV3NLpTOGfZ3kTLD0TMNLfwMyMHdoeTwV+kEcJ5HhN+yyOS+gzoltoXsM3y
PJPyMtkQeEUsaPfA5Vy32JzL/gllVwcv/wAjU/BEhXstNHY06PgbuTs5REJW2hlJcjzCN5aGlP8A
wKr2cAofkWOfopXwKuUckTddGLRaxRvg4Gi7DbIsv+GXoS9MaTlHnAuw/oxZG89FHYKwYPsNOJrQ
2JwZMPBYZTK8HlFWyRZEv0Xo2/4NgMbcwL4Wl+0bExs0tFNiNqRcqNcJk2OIxtoujleTIRfg1nY3
UkKrYd90esw0NkiPEMPIuvicIX2DG2RglGIeDjBpNEmKWTTo0vbNIU1RPrLG2tBKiVmjTBzLQ3Wn
wPz+jrkqkG4jbJyJ5+iLkc1o7BNp/RryOxDYvwc6RH9CUYsdiNia+FCvkuWZTBCG4JQnsX4NDZsc
CUyJT7KNrzwRhhbfJKuiQWmfoy+B4eGJDt5MUg2EGJSHLLZfVVBqcQey+ovNU3kQZPkcrNwPcj2U
Lk9FRZwYbTRixeODA4u6OiV5hmqcvRFuGOKXWR48DouClc7MmudmMu5LEZW6E/OBuacIey40V7/B
nIeYxpt7FnyXjJXBQlo/CohKFfAbzUR9mGKKoQMsGYapsPcprn7NKsr4wNRox0J3Q8hX7JpXC2bM
ipg4wZd/hH9nByysNlwQaxTJRv1GhIsOiG+jBm9jfhwiH9GxBKJR5+hstZ8mFoJ1Q0wsirSHbHwu
b0W2CLrE3Y8IUSfDhRRvGxiuR79FDyujLngTvR5uBahPoa2WKL9opvbMFRSIZezJsYqorJFjNZO+
jL0IVyMmfI0jrsdu6psaU8/6RPB/QW9YOQoh7yjHAbvwVwNkPSNpnIk8kiCbw0hv8KayJhKi3Vgp
BlE2yaNrgTvWR1N7G+ChWmh2RzMqaG64EjpRvY1wFXsx+D6DqHhUiaEmhuc/QlHobz0ZvGhpJOCb
0hayOcHIjEGs45Eu3lnMJ6+DRirY97HabL9jkNtM8zw2aITQl2E3kPhHlk4+CTbJt0ddEhUG6ifR
WhciCVbwVFuoPeRdsquRxOhuspU7GK/o3pTeBOAsrI0aOh72RmcEHk1kPIT2hoO4E8CYdZm40OMG
SWCNpIkK4PyyjWvIjw4HLIN+StsTyJNJs0LWd0jWRPU2NerdF/R0XGeExRDXLFnA/VMIRX4QYgy2
hL77CNWBSTS0Q4jDeBwNYQTNqLws5yTgIRiy6OCrb/Bt7v0LKFhmsmVwJVtgT4KJYOfRtSpDTomp
5NC1kUYdNMDl2VvCMTJ/LGntgWF+HQa0KkJCNMkEcrs0wJ2NHzTR+BUqK3SV00wofYvAhRLQq1g7
CtdbXBO32O0xuOBYTgsjHhISaWjTRVHgPtCcqE7DiGPTMAk9jEMgM+xWvIyIgkzwUzyM7s4bMlgN
8BaVlaMr+htIJxjDyPhTJlaK8CEdiZyJBoHke/LN4QxSDm3RINtbCQdMy2xT/kHoSrzwjHkwMlqu
rfQ0bo2NlzUO0lYzRLk7PSG1gvwtS4HU8PgcYJIJ0XP/AASQ3torxkXgesiNZKjzRSoxUQuRS5Ia
FiTJgKsPHsqZRKR4SCD1kVaCDz0NZp5Mgk5OSZNyIdmR/wBE634HwISi+z8oeXDp8HXJgfJIK50V
IJLBYsCQJEoV/QnWxhPJh4uSRDFSeRYyzgUQ1o1ZJyNdbI1hvyeRmm3Jqkx3fKFhTijHj4LWNw4Z
PoJ2LRUhUFkNJI5OB9nKNiTbGNIeC+hh5QnUvhGWXBv0H8jdGNOxPI1TTNBsYM5Fv2J8EmSTJMEP
/ptxjNYPI3NlHHS4Ht/pX2Py8me8jsL9ib/zGOD5FvolWxVZpw3Iub2MOlJOxHLWrRs6tQ33R5cu
zjQNL5EKf57FqRvo78CywSC5PlMlVOUd5spSyS5dEZOA5sbJyclQSPdJjGSrY0OiJez1YNJcE0V8
DAx6tmSXA8QI1SzDQo4ZG2GNlyzzRZy5HwBvs0cZHjMNVFWbFnBoOyksYGsjsyYqwOJY2ZImMCbW
C3HJonBXsTaZlnZVHjgd+hzJwc6PsFj2O8sDvBWN3kT2D5IW18SLWbeTK1idMapachmqNwRNuRhv
SDWV2P8AQ7rsw0U0JjIs4W/hvhgqSbHTRy1gdLqkKIhuXyV10c7GWjV5LYQyh8iVYDavJEi5y4dt
cjy7Gn9E70JMI1MxmpsVZYszHGCdDeyJvhmTGjQnZhzgx9iRpjmBYyj+A2KlSysRCX1Sz7MWUZhO
BOSEnwLIYULsbJ20LDouRRFcLkTNNMTqTM8JDwU08dj8ZY1f/BLWYW9n6Zh6E7EI0WVbF2eJysid
ZpPkSR38ZsGKj7FkTEsvwaE2yQceRSXsk0Mp5Cxr4MMC/wAGyJaWDlUxs5Fg+X9C5ZZyRtjTF4LV
sesjLQ1wa8iD6BY1yQmq4Ycice78CcQbSyyKBLg5MVB1i3GzWxtJgTvkaEwyVeSOf8PEMqdJwYEy
fgfBpiLKx3uDejFx8LGYK3Iw1VFRjAbTAXJvgi7Ox9CzyYKMrvA1tT8GDpyZlNkMdLwOH1lBwaxE
icWaH9X0EMhE9H8AkhaZ56Ep/LYnwg1Wzt0qXA23QubCDsN+KOyk8C18eqn6VFiZHVKChkTXsxC0
Iawobxd+BM5p+B7lHls2x+fCtGTHTIMyXggJBfFp0dPI8jVceS+8dCaLglGiWjeGZ+iPBjCpm8D8
BM2YEvAkrvZomsozT/Qg1rYzFjz/ANDRQZex5Mt/DjyZScotWjka0IhLtgTMT7G40LkynJCEo+G8
HgWjU5F0YPY24V2YDeS4EvsN0wQEotyLZyY1dGvYybZCYsu9cjowBdrJ/TG8DyPf6L5Nzda0LML9
C4cyadb+h6u8DMsbFnYuIwtmmyJsTKVRia2JLX0YqtlMITqnJtZ2OpDLS1PAmN/DzkWAudFw8lxC
TRZNsoi1kXXnQ/ZP4JUU5H4Fi+R4wxCURG/ofkeGiA1VeyYfA68kSyhPi0yYKKJ4Iydi/pxGRp4y
ijWyy8iLgmfJlM2wxp8LbYyyE5o34Kk3yLY2VHImboecaEsjwjI8HZM9mmBLKGuORacl3wLIangP
oixtexomHSJpf0q1R5xE5CHDgRHQ2heiXQ8Yq/ASrY8GQaWHyKZ7Gxq6P6EqvI8DwiJByuSXZC2x
sNQL8mJ2YqHbeGNWkcQwrsbarZVowZwhbdETYZrs8uD6PLRCY2qvA3gpsMwGsEccCUEPyEfiFpZn
oYtrsuycTgiyiyvo+B8nA1jRRWcXgbnt0zKD4EWrXoiKllNGQW6ezzCbIOprBKl1vmI14IMDMM6D
rG+LD3KYt9De+R15Gq9nOBdBB3RmcCgTBkJYMg6bE4dihzZtkag+ozcePIjjBbCRDmRSzSwwvk7V
K5gS7PpGtGqVh/Bul4HkiYYvYdMesCuiSZEsbF6OTgULZ8mAdTAJeg0hn0IxXsWHxyiyJsQ0LCjf
TYmWSM2Fky8MbJuQ5cCXB0RDZ4FpZyNU8U/BBTkOwopi8obPExyNjIN5EWGGhF2djbMLJ9mbuyPT
DoTjoYz62ZMWKo8mBolF0ezIpO0T3MCX/oy+zGXgyGdmdrg00XwYE1mCryG2kXOxvlcwtLE9MrN9
E0zgTzDJoaSfZnJaHci49ErvCPJeSZCyPEZSFl1cDebNZP57LBt6aEI72V8DRc4EuhkqZNv+Dfk6
uzE2dBrk0GVwvg0ok09YPYnGTBGJGKp4Ef0NjAtbFliZyofwR344efjtow2NCpj5GBo02JRjVm/R
hyVnr4abeDOhbv4PRwkiZyPJl+SzQeeBJ7FT2IMhjYnmscbwKfJnkQbqs4cDDTawPPyZqiU5Muix
2LrgarZkuh18lL0K5NLz2XIw15NMrbGs9j70IbbFk9FfQ1PPwpNkSg68B8Qc8D8hgHl8E1jRuyIh
sD/bIZDknKh+TLoXOd6EyZ1cGqPKGKefoYxBKwY6KH9RZ6cCeOVw7n+CeryI3yKbv4iU1T0JD/gP
y2iwkHR1UW1opgJ3/hDGo3cDo0PVyNngWy+JukmOiFQ2kuifQmR5j7Z+D0n0Tk9clBNQrXyNi/g2
BSzkYqepERHRIcibuBKOncI7D6HQmCBrQY28jeTQ1MimLJd4IgzgY9Dh+fg40Joajb0XURTJ6Mgz
/gKkNzgZWRyvwivaKFWLx4GNleRhw8jXAZ4cI1kejLZ2YK6NHktQpyyvNdPYbb8kwGux+ZSWyfon
hkUjHA6m66hrBrCKZ2aos8zyLI1ofOgnBsbVcuTZpjafwTWEZcmWuIKvBhgafQy8CWdDMTXwyEro
hINR0WXPgME8jXYcS7E1Ls0cVHsCFEaD0NVojLHr6M+hJJJ2jGETJDyvgrYg0vg22YLqjGrk2UIM
lkwwohHHBkgsMWbiGUZK8oThjQ8Q22FIkbTZvRGJWRWlsQWn2L+nIWdiTo2Vi4uhOrZryLL2POhq
N4GiWigmRlPJsmR9QiZp+StKcjjeSfh5QSdm2DC/CEzkbjsYJueDN3gednSEk3ksuIO7GUM5emK7
PIpsPfgeKFRVwZRW4G7UE8VOaN+4cKZGw16I4jyJyZIfCvwsp8FbsWZ1mnzngVyVksIR+QsrofQz
CRm7wZHBZOUPEgzZS1CvtO8GbyolmAUoGhLabDinf/Mr5LBHTXArxNeBbxaQiKpMZ1X4fAkiRa8i
2p4McBzTREu0yR8nPR416IXa4F6U7wJLF+SFSO4iKIWPRlCPI0gT1ppDUmb2Kdn9EwT/AAaexef4
K60rwhzS8rLg8wqD8aFeDNpLIrBKizRUR/Q3C2vAorqCRtPuDtpl7+AjTpl2L8yWTZrAUwvmwN6w
O5FnpHqJA3dktwojexAUPZFW8iArwFLNXwWOXcGJL/CDaMvGvI/2xW2NUQyx9DhUFRGw7eYO6gua
YC+n1BQ216EPwXoyNhPiFHr6FyvPRAb20IV/geGMDze/GCCXoShREwHinYNVbruDHg+i90yPoaV4
LaEFWRokMtcjRU9srFhlonRbUNI2gpd2chCxnY3Q4JHgWvi0ZKqGsiMhnv4J/YMTweRrONGdGWzH
W7oUbyRQ8rwX1DYbQmRYeBafsUY5HtOmbE1the8EvNKXGR4fBvI38VFQytmYbCVWR5lDYrGLFoz3
BLnkawPE7IPPJsaz4Eqzt0X2wbWRL4pSK6EjLfin5Jq4LnpGVX8IfBjs18nkPISjvAl5Eob6E2sH
Dtl8iRCTkrZ7ZI97ETXnwaHdBjIw9OCGtjhofQaqNZFaPGaVIN5Wb9Eqb0aEmRvpF6M5M2ooGono
w9iw4so08CvhmoNtc0tFldjSy7kfmZMvkbxBaD9vovJi6fJDYiQbWYJJKqdBUdSGD2eTLYlNhvPZ
V0NV1PfBlCfCjU20yNsmx8bGHDI9KisroR7TD8Uz1wxhjwQei4H0kBiQ5gnkRcZPBVjuI0uhHOoM
KFuhT2VxBGkdqKI7ioedcI4DnJ15GNTO+dGoLljbzFsQvqmtK1BbwhXMdSFXKpIj9Hoe416Mudcj
PqblhWEk3Ug8OJXJiJ5wpvqSGRc00m1LBVpcWGcRTbEHtvIj6cH2MOYZF8jPCfY8KfAPDIsWEDrr
gwrwWdik0hQh45GSvHbkj6TaXIhU6XYmV4dkB6KH86G2smnEDfNcrEME8DApKWEO/NgnHIMqwM2F
al5rOa9F7FN5b9RlfFEvI03fGZNMMgF5dG1BUk0Zm57QcxdryD1dZLkz7qpIbEmLTRliPwIDoJtC
eUKipsIRUSrgYc9QVEOR0aFzLanoLA8GsK17ODUlsU7ME7gTQzdOtE2YjPoanJQwYFlQwcNuTDeu
xlrsdpMI3lkwX+BdjankeFQwuYSLIwzfAvK2bdbN6MIQmTwCt4WDwI3/AAXe/AtVl7ZZvb7E6GPA
owNJrkSvOS0Q9+yJeXQ0Trkt5X4cCxMivJfaM50PfjodZyWPg+7jwafaJtnBh7I2MT8JjZk94I+x
5MhukZtWqRBkPsSboQOYCHjlDdO6ZwIYRUnyNyQ6dicwOvQ1joai0ImQPFmfIk1yJquhwUFnk5hl
pns4GW+x6KPOSum5sydGoVEzoEkdeCV7H/R4Fr8GA1wO8rFG8/B0M2aE12LIt3oTukMJkf8Ap5RS
mVoWzsY8roQPAm3rkrkG4/BG3BHfAqkSJfLLj4JF6LcIadHlESlM2oSGjLj8Hj2N04jb6I0Rm1co
bPgmRqU8ivsRoRJEOZE1T8TTLZm5OAyZk6NvEQhXWBSScLEHQ5yK+X0qMa4ayhWVweLESC72Fpti
HSoOVtQngtcjm2qQ6XQ+50wNpMeV5tLbukNVeFrJDBa0TY92+Vgv0mlK9sCQqs8/G3IZoYWhchFD
0FNr2hYF4CXDyEut5opzrbaPqECaMnkNzJo6lo3sNCSPSyrG9mKQlFosk6OS9irGiTiop7xSm43Y
YpO18Ctcw+t1kWgTgkTrpDtInyNbjY7JBsiYHq2TYzKRVDyUbe0ObmRK0s025C/gWwaS5YRVarx8
LY5bwMd2oyyllwzCoCOZfRlfC2LkfJy0dFNKlKZ0sK62M/g4DjaOhZTb/Q6Jg2g8vrJ+g3J+xoqL
LhnC28jGtsSU8vcEV2mSjY7qzoxZjg3A0ylyP2oxcsqbHElv9I2WCNNjXZ46XIi9+RF/C0mvIoUK
YhiysBtYHZs5LjhiE2eeiNE0/ohXkjyTnJUpmmSeSpuUTohsnOx0nDEmXtiDyyLVghZeYP8AYOH0
jeYcLo58EsWkJKO7GmhJPlGVUlkxwJY7MpCeNZIWy4jGmkZ6x8KMvo2LVKIZ/DFWnYSlPE/03vRp
7g8rYp6KjM6C/YSG2VeA+FEzwH/RqxrR+UPmjT4PQPaM7KoR6IesDXkZo6cU8DSG9H9irwV4KaZF
saiZ4NPsz2PZYnJcjYxgkHORPoPKkx2afwTBcmIdxRh/BZgnOzB050aWjS8GKuGMfVOBIJKDwNTK
Eq7E4LeymqQFU4Z2Y6zdcH9MdCtvI1Xg2+EBLhPBNHgaaMmXEQ07GsnImzHAXG9iQt3ogEQeZtpm
2OEJ3vRuHditIuWJqhIbap9Diw98DauQnRqEUJpp6Q/YOycZ5VVDI1Lo5g098EvHk/yGg8NM7K7J
uEikzs2JqHS2NgxSSSS8JCHrhorqvYx5L4exrTCSjGaPtDwrrb5Hcd/o0tDyGrH8neRtUVLCJZiC
4J5IdmhNpLlyyEj0rsVtnxjHWdESGLOEkUEG5PFzRn4+J7KDWi+LHyb5RsUi8bkxgmmSmoNioecO
g9aQtZlq6F8U1R5l8Rst7W4wUrIrQBog2eRl0LXk3iwYU9NDJKl5C4osgmzQTL8+Tg0ecC0wnkMH
KTGJMBjTG9BV8EZiKvLYofAV6NBvx2ImM/gWhU3wZ2UM5OR4SEbz4WBCX5EkzYz4Eq1hHI8v5HU/
y2OUmvJYdck8YhdXUSGexBeQ/wCYgEseCuKfqcTljG2WRew1eRNLH9NPGSTAt6I2ixDb8ivwNitw
MTyjn4V/CZGJ3eMCbtZdkJ849FaedMg2+zNgSx4Eoky12J39OfA8rYuzLWJNcj3kUHjwsjbYk4Hk
bdCbbR5byJtvwJxsy1f6PL+FTJeULm5GHA3gWUeELrcFvCMF5N8nAnnQ9jwMMc9/BoxPY1Xh6+cy
7RHfAo2i0cDS8jYaZgOIWvZpdsVYHCLbQnAQY00qZZ7G2c5YmuQ00sCw7vI8MVVwJ5pIYlz38J+y
5tGrHMvLYox5YKTMseb4+FN+BcTwN6hUnoeEK0hJy/i+1NsizkkcFuJVCbKhvjBqxlum1lDTQmPG
DGBa2hq8lqY3ELK2MPfgzPA0Zij1oVyZB27Fhz+iEX2RHsQakzNltE4tkPnIzuiZeODx+ROSF+ZY
zAkhU1XmGg7BOuDcmKNZP2iKGkhDgvoZwGs5SH6ejsl9oWOhE+F9CXFG2BX/ANCjBKEtCqbn7kT7
FrwfYmXRvgYmW0ZyKLrGClnovErErFOdcBPIvIVZRlFqCmg3h8ic8pMkY9MdIyUQxxg4uHscLCfl
DK5/RO49Etb7Hm7KRMjNtibODNZg5CCxkuacd+GK6HyH9M5ivLIuxvKn20ODX5bpX3C+1/pLVTyM
s67G7v4Lvo3/APGULR1QhwRCoZX+jEWAgmo9m74bOBvl5IY78E4OlpemMXr+hncD5IhXSFpk/dGw
my5tLBsRDdklGMu+qxaaj/6lO6JZEhhhyiWCTA9IHIk3AhVOfZl4uTlbPYuc5NThyZRnvDJEq9nD
An+GjpM2wPusm/IZ2Z7JlND/AN+Jm3SGy0NtuP4JgkzPHQ3oMRteKO25gajY1S/4Pfs0oJB6Ymyx
t5+h18qj0W0J1518TeFTvJcMmlv0LGV/RbSDzCYGnowQpCnOB8OezLSCwXmGlwS9/o1k+RN4CNaZ
My70YCwdBxjIqmV2NxQ0P4cIKkN1RMmsIeJpsaxULWDNFhmVsf0+NjJkl3Xgn4aYMFsedmZeDgMS
9i5pN4MPYlTIug85M6DD9knYX9Jnf0L+iBuvKGtcHMEm1RatGXkx4KGlVkQ1/BvkeFyolkX6egNL
2GiyVot9jqGy+HvbkRwxViuwf/dExS3qhuFxuiyXMMNPi0PMKMo8hKEMESXkkg+fhlXuGeeBw7E7
Gh44HgV5wrn+DyJ9/AsbKVn6FsxEpyimsCG6RWiJBXZhtnkx9itDpYMHGKY0lsvTILRs/A7kza2O
rbQhtnALfgywbHDO0Plb4GRHyxuySwhOl2UkY1+A8ND1vJJGc5Yjk4Epoy2yWrJI3joqN0Mt6FWm
DDolYeyzB4McC48l5pt7Mt7HakzFnIpGD4MND3gW3BpC4ZkKLlGi6K5Rykd+CuyPYNtti4G69jyn
yGKyZeiEw2PamDlRvwhJtn2kVPkyNTIyQSrHwzDJtwRtR5brPIQmQFWZ5MNNNxeBKcjyQ2IIuWWd
jKcDSM4hpLSzHJpEw2Q0bkl1ogOZs8oeslHSK/Ynp5nIsZK8DkVCCja3gixnBo7g1Gf34NiwoZD0
hsjkZIeX0J5aEziChaJHm8jfFF+kTo4vI+Tkam0weacEMQvwaSEVDZL4LC+F8ZZDVpwcY0QGnnJ2
D1UJ9lCNPKLkPhmDtHmQW1dFgMeyExRb2THsXZW34P8AA30E5iiiZKn0XoNG135OWi7Ur0OSTk+x
u+DyyYMufRtWI2LQWoVIkVY6uDk2iwZNnOkdjScd0YYhYbGJBxoaokuDD2znZjseJFUMXSW+Rq9Q
UeRBvEW6V7eWexgmkyIuaZehQpaZcCSXkNWI/JX9I05wYo4ujTwy+zLFFMcCg4yI7vHgX5Bt/r4t
J8MbHY/ImTLkUIxVUxjHTtwZOaRpV2JCceCC7MEk9G3dG8WEFSLT1/T+w5CSlMwx+yKeRko7kTrg
ru6PCmXyY08iSFIjyiLAk4NvQqWCqZGlkhDCQqk+Dg7jPIXkKtvBhghs8m2MiWTTGtO/hhmZNeRX
pmGldrg2grHZNMXA/wBODuhZyEGq2KMwbeBvA2pnZ4M5VmGMSvAs/wDswhb6PYbzwKJvk084E84M
ZQlFeTcSJYIa9GHk2DXDOx6FujPY+NmhI23pi4yP9mBjeWmZGSiVbyPDUVuI06Kmn+BpehvNGhzl
1FHFRTS7MIa4kPfwJ6Leg6aSqEqfQ9iTWbS51TEKPY8kacPOLuJb4SFOMvheKYQpcj/+Meown97o
aWHDCQnYeGxX8C4cocrJzdiec4FaWzSldPZrIWVgST4Kux8P9Gu5LgR+nKo8jJODBm0T6EVhI9mx
tGGCHkRyj14FhgcTEaCy6EJdm2zSImTSyZ9kcsyuDY+zKwPUQkG6ERLJ4+OmMlNiecmbxlFtIrsv
wbFVNocuyqEjGqa8jYZmSq6wJoTajG3RKtmpdCXNEmtnsL/TkhxORZWRjeS4wWIbE9nbbMkaZ5Te
P6JzyKS4EntjZKx7KLqnGxNyx0YJiehbSKbwyVDb4v2fcsFHvAlS7FoLS7E/IlDAxKEhtitaMgae
h6lY2OxCwSJvBYQ09Frkz4yac5MnRsSSaQSNP8E9EKMtUYm9JDbJsv0G8DLMQuNE7+CssKampHA0
hOqMDyasMhvLEg2NZMEJDRaCWK2JV7N8mUY1eTSaXZxFkyw0WFU8oeEYsRC48DvocJpQyaOhPY2+
A3tf8I5UfkVSwXRVgtj/AKXob62LY68cFSq5JidlDbYzB6GoLGPNEdmS56D4PQnNZHHsjGtQTozX
Bi7TR6bLlg20r9mbhivIvA0WqDDwXB20bonsSJyIcFfRgjQ2GRGPCXC7G2eBt1BJpDr8EDbY36fA
yTE3/wCQ601vItVrJkymf0dr/wBG+hG5LZnBEbRDwv8AgvUN7omui9it3Q1okEJcjKwyByy5dkrs
fDTJstmCLpk7MTNbQ0ciBJp/4KLEkXFptmOz+CZmWhDfBrsRM68FSYlTg2pc6Flkd8FMZQeq02t4
O1E9j4xsRjDFli4MaaSCyqZ32ehDQ22mzFwieaJHvAho0NmhdPgSRaIiTJHBNjTRcbLWLMBeSvTE
TH/BOowPIdb2NZFSISTb5E6Ko9wVHLE2Rj2XCHgb2ON4pLGhruNkdCYfgZ46OjgNpIb0hrKNv+mk
yew1KE/4NpBZvsauRmk2cKJSydEXHwQ+okFlaKSDo8nH0V9fOGAnFefgyswMMnHgJEbhsaml5GQY
Wxss5ZoQwz5Ew6EGFwvI3muPkzHsaN5HkN5G0EziG442TGZGBSZxCxlwRgb18CdK02NjL1FEoE8g
01pfRsYQkaLskZi0WoSyy5G4gg5wh/4EITJtDeIJJGsGilX8IJDwQWRIImQjZ8XwPAWQmPA+SieB
YGD5LghqTI/hbBaLA9HL4WIextmajyq4hbB4TNjkJVHI0E2xOmxGkWmw4scGaMWjUiw0vo1TT+xz
whaIl5NseMjX7GoYsHJ2PoLAaoNBcPBqSG9MptjDUJFEwYyYLEUN5FyPgWjwx5g0J7PI5MglgaFh
/FqhvgxxHbw+haQx6MnBf9G8BrJxOUXMIYKYMiUFmeT/AEG4vj/kQ4G8PY3H8NFqSfHA1uXAnoZs
zhTpSE4Ikjv4W2M2GTOB4EMNAnUMXB/BMEsMWDAJYxbG+A42z+EySL6LhsyVHoWA3ExOq8nJjywt
z4Qvg+RbRr4NseIJ0M0MGXUZR//aAAgBAQAAABD88t1o/FPeaIEDVQIZijRR6BeoTvJw8o5EZdLd
JFvg+axLr0xwyspbxlfEVsVLZX+3OHPjYuPJs3ZrAmG0TBrhy2gHtEqqk6IBQ2vbAm+gbV5Ipjcj
iv8A6fwvKI88SeVSF5/cu9EiptgPkAml46E+R8Dik5gR/dKhCC+znrFh58sZgb3BoUMxj9WxpRwX
CpQdFMdyEHifK2uPavKxmg9QxALU9BWj0uIjAoYFsZaLyIE2HYbwLheIztUxrFzoA9Z77zjuqEbY
uvI2t5kry16VEWbAoafZTYuJ65633P4TSLK6BMEI9fj59L0bxr8lNRPcdbw/Yw6RMlNod9YGQrX8
fxChjp3hCrgOFUrxtdlezEKFPXTfAUhDdl9U+TRnf0Iyb6lmp3He0ybCI+THF+CujBBa4JlIUl2f
0Gh26rvDpuYmE9ZJi9uZduYGLtYiW7N5qL+f7vyjhFuK06BIyV+UP5nzX5o3r0aiueqXGCWxVP2B
gncTyyT2JQuEGDppURGmawUGs1bbghKf0PgaAJBdiFAVNcsSAB2lpM7mKfzYrYPcgnQCaAfd1n/6
DvisHhho3deffPgVtCqkMSMRPdGJFw/bkhu02JwT8nKGWKCix6+BqPArnPbwZLirOSGxPNb3hAnp
lWYHRxBUeWVLoNBJVxqENQnj0Gzj9ezAujErWnk/Gf4+2tP4cOBRsSyGbBo7rE97sycgqacK0D/X
5G5yHiNlTzOcMnyBEqy58wVGm4aszKdNIUAqQRJpTFp4Y/OYlYmL/wBqNXXZ61rxBZFfxjGXsNUn
givkInZG7pV5toJQBOqOUnAha0h3q5H2rRx9SluGR7oyKB2ObbpxKuNCgvXP7DEi7/kAAXQvgItf
pIFPaVJi2LryDi22stlJcEuHaFhTTP2+SCtTgXlapd17hH6NbFm2JTMO8qGByM6fbkXhqEeqgn5A
gqMiCUgUulm7IQ5EgzeHqK4Ssl5A2CvGXvZEPNqRe+Yah4gypuyrFYnAre3x8A/oh1qtYYY0Rzjx
yASOxE+Z+g0mXkS2Jy8crgUXvT5gcD+VLCY05Gw76mb7c7k19EiEqJlVPl3JZ0JRebbwQUUGcoRz
wGVwYLMlkF17cRTayQqnPQEDzVsFB4jVBW2oQmzmBCJXN5JLxW7GY/0O7NntgyM9qAu4pokIYeiM
YNFSYDQ5/YUFdrR6oZ3uA79PkvIAwy/VkuHgeVhEucS4d2N2TVLuXAlpueoJ9KLsB/D2RRlRZgdx
f6QkQfhD2MWCl2Z0MnsNBklfC4oiNXSjknwa/lQJg/VpkTT+9rHmOiuShahPkI/gSa4l00Vc5sg6
YRB5aiL8Ued9218JCGlC1qswz+6TMGqQC4XAloDzWbtfC31e9OuYbJV/WnE2AK+4BPNq2NA5yL+W
fuMQ7XxY+JwQDNA8cf2QJzQDtdRHYZTAHJdTud0egXAasLvu4WvbrsHdIRQgbF9rKEvVLZk1vdH/
ADcrUOMwWy9hgf3yEOq1l3h82h5Nu+cVw253tyR8GKlFeyCRE9kO8qeXPPqw7QzYU+AYhMA6ZIHZ
/W7lpjKjza6J1vNk01E4wn5KHDj7D+cwyAXAiBPEQzNzweJuRUMauP67S04K+7+fMQXOs5b1qfeY
L0d5VQSqQa60u/UooOHzpuDjDXE7rhBDeh7ENqeg/wDniXZIoCA/6hqR2tcW02jTfWuvPEUY0Hfo
A6WiwBOujpOauoQx24skgL01oR6Eq5jVBV4CamY0Kjj9U4muYRzQdKUR8C6lOjbf0U1HbHNKyzfU
L9T2oEPI9dIh2Iz1fF3Mqxj0AvE06CJr3e+s+AqwmpCzNdQNgQgioAWR+EQ/1qLVsE7uMF9788Ff
9rY8y1n5Q+kMqYudZ+pc4hPJ/Pblr1M5HPqCd5YJIulGKEwDTvqoSeVZYIPSbguoQgzlO/4K0fqm
T2HcI6ZNySVs/LTmxK8by0mrhNdk/CYDW3JhrHEu/wCiAKflbqEFWrk6MEW8GmqkNtH4Qlcc3yTr
WJfexfDW3JaMGYfMlT2jMwpd9UxLnHYWd6INWaIIiMGnQq9Ufa3iFK99BgIKspLEybRt+FBapuvq
ZUrcXo7WYwgjJKXhCVWnNIU3slTo7GINGwXXh8z4iaK+ixepzO9N7T2tebKUniX/ALBkOxzbT39x
J0EVwekFiiAqa6+7W1cZV0yuUwZu2r/MX4QabiZDlrPH6GfFHrarJ3V2xO7mURK+FEzhoynm7oo4
pG4LMfSty8P4hcY4TwR9o47wCtTFp7joPIvwVCOsZsq8U4EbFK857n1D6/8APd8lDHc5J5tfCgGk
mg7AwXqowITedrkdvJMnya/NtsgvqCOsM6Tq81euGrheGTV9E0rQJTPManaUNXCUdjO3w0vv7ssn
ubWgXojMtQwlEsjjUe8yUOiRlNDx1Rz4ClLepiFcLwD6bjFvCOIdHCmfEjPvURXx530Lkxpd8WDZ
5DwJMIpom4ArVguOkH29HUQpaWz98nPUy5i4o5Xw/XDmO8MeIWLGSiye2HVdlXXFthODYhY8Uz/L
EA8k2JyuSmL17W+reiv5YUpJNM68/SREGmdLBa16c1rBhJveFb5VX3alhFFnJ0tpgSwZ+3cHf4lF
CD99u9B+g2xJdtrBIoePYbl7vKByaK+LHF1Q4cUoKMMyAyB6jZIOaIscHVpJ32klPgehRWlQXa6v
koRggWq/cytbk7XC74GRasqod2AleSuggwTu86uwlqrfEAuujldLwMKmaJ9bHz0u1wMpNb5nIBZ3
fzdwuGbepPV1BguuYazSgzptQDR6tWpgwAKVkiM5ybTdzxBDkjLk74wtaDQ803tr8f5PtfVlYJBn
6wx10rBCET2EtRvwYxq24/j2gbcJR9FMoliSdSEcvvM7Ea3rHwx/SGCxSWWBIANuAmHxROjoY6JX
gDDLm3MrRLaWBTjcBXwSbHIkV9sZjZ7v+FqnBpVguC2X/vQC1FjODLekv3dBeQeNAYPEn3vZ4rtH
priUb4I8+eI9Tw9IVdIjYHB/CEjSq24WqxK5UIGNYS2+cec/wjrGg2LlH+OY2RQu5yxfEdeq9EoK
6/BrxcdpU18nGAXqsYRlBovQEzyf0ekHP+8klDPfnGQVvXzJm8F+0aaqkz5/E74xES4BfwzyLCGy
nK8ntUCMd5txoGHgWCKcnSwolwhyl1oElxFmf37l5U0vWVX7Ls3g+mWkiIuu800m/r5xsgqt7QKz
IVqmJNWtNGp9raoVcRJx2g9VmyHdq+HzqXGUB5Stmt/Jm9aaXa9QN3Y1uxBZ5ljsuNX6RY8ak4Ym
34aCTNkEcs//AKUdz9vAAJTeqjhMHgnComWaSmWBPtwtIVZLqKatVLsOOWkbl+CUKQlTbkLqjPAG
FAE3TzztRNEke42ONp1fDwx7mtWwa6DVlXvzOxLdDGtf9edBQpmcN0SN4rgO4rhJkz6LPBf0RGbx
sHuUF42aF/KR5uTUTqj92ycYAK94Iiux1qO9mmreRSE/yv5WkGYLdrvSqrCc1hBfhWR/0C8+f+SK
4GE3v1NDn1Is1XG/gEMFOIIobmOsRAJsi+DY7KgOk+yd+5vFV2BOV7Gf8sTbrjbP2swEzlOmnXYS
W2RG40gDGFMO0YSuooLW0YJnbbj1nKhwQgUoMXsDTALW18JRefm+ViHcMNfJJ5qnqYyWsV5Pxenv
L1LKZtnUDDPiaZj2j3BwcuBGTjOVn7LRCoZT/FO4TlLkdAzEef5G6GHszpXPSjdlIZLyh+5EAei4
7PGp1ZHGHMmcVnwlWTLW+iBpf9nyZ9n2d9Dk83vzNLtxmTed/LX6Bwt4ac/kmCExrdLKwJueiKAV
eXYgQhyqsAx22rajABHahrKd/bfq+3DlL50LcNWsSbrC6VnQy6nVV+CMTGGjY5jAl7N/nSxL87iC
jLumZCMA1TXETOQyIzlkKTeG23PPQT6hmu63IxCFGCWv+S/nYqN7JSnPvQ8mIDqvwLw45kDur2Lv
PhvyzCYtoJyG5d0JBvytZOFawD/YUWKytcULEg7gesV4GZMzSEsk+MqZiyMrRmfFzxoL6buVYjGc
JKA/SF9JcwOcbk0+WFsoSJCVmly8ENJjMvSsRt5jsnJ7BrZZamak1qWP906o5wtZxmzbTNntQ5UG
Ss5ABnlqDOVSBolOEoU8hkZSGtcqFV+Ir4oDlshrFDwdUS1YZD5oFrLICN7tXC2FLbrylMy/XGQg
FcNJwNkeqOYYKC4wf2FbGJkvMRSBK63OcegOgBqAUxCeD/qSekDo+CrafAqK6Hld6QDCEEj0UOeo
5HmG7W2AYuy/jh5qCqWPzj5gSbVU+tkm6sgk28PQdZa5OefRt8OCLTE6pYJdyPrapqrpTG5/Plbw
U843PdUuVX7nJ5ul8YA7YREM2jhy62nTAYqL/c3qoga/S0FudPqArOJsM/1ctBuRWt3+n0eTYwlZ
dwxCJBQMA4hctBxUOcxBhBuhhlE581QjOXKVtrgSdmkYIfceP7DnSmcIck3ov0ZkeTkmO3LrSdiT
G0zWfVcrLwQAHdH1s8STYljfLokidTx6XI3gwc1yswLP5MOocY3cidYY1Zlf+88bgYSfosFac13V
4LJoeRa+PYbD3+6rn7lYBd2KbYOSXBGIBt8CjTcGX5xGGZSWIfOk0p5gOoNVa2mw45bH8goBUKZh
SbogaUrrE6MCbGbPaEsXZMaoiRDZxdH8q9Qz4hBfLPGZEF6a+IBEXT38y05FaRwI/vj3r61Btg86
h7LhkBRq5b8r7Yf2SklyngXbZ9aOiIYuXzR4nZjDm6nsb+LuL7pXjjQnzcIQt7+YDZJaVWa1fORN
+vek+S+S6rjMX6/dBlJijGyGmUYX6ERMnwg2H0vX7dGjf5ppzNDbbXDlq109eDptrzI0qJE//MdY
BvUXpvCsjpxFzb6e0DagU3U2NnP78/DTC23Cj1LLl5/4mIl/Th8LBRl43fCX7Kgm3x25qB+BY9St
F/CU5h2yUj958LrHXIt1vzd/OCATmC/MrBtj6zieCBegzGgkypJ+XvOXH+2CHLBqi0aGzvRjpNHW
ppOaA/xGKEZe3bK0Z7KnREgskWRQZIHrEkbPafFrDrOJ3Ltq7QocAUQ03uCeZdbw0+W0q0Y2+Fwl
AmEi9UOS+Q0beCT7xG/t6c13Z+75X+dSTgBXAZyeMbQBUdsh4cpsnDgRH0p6cRX1yMYun25vdser
7EBgEQJkBl60eOsZe1T9EWN9ocFjPl8yKRXJ0fOFNz04bh4pQwsdLVb1xfJEA4Hm1pgI7Ov0UCBV
CIWM3OkgEKvoTW3YKNT3L4g/hHJl/oz2bGVHMZpVrYNy8civxi+Au76JcQVafQZBwCSjGy/M3e20
Q3WUieP9FnX/APrTG4+CiIcQXS/D7FtdmM4wsFvRGYvnzwvCwQWt5xnXS6AYsozlbHqlRrTIM4lv
ddcUCsJioEJ9M/pER2FekwzJAwiGQM7MdHldKSXAXd9lQKWuIhRfPK8TN+2zidYGkrQe3xEpHinN
q0waFNgaxpOHU22Vps4oeOeDgjQrPXIFP5YQbIyYx++pug4wWOIYdQddA95Me7Ubtc9RlNw8ySgk
yTNZsbtK/wD7a/e19dhbCUCivG3O8/lxOgW1h5WK9bM0BBGVvqu/7C1lbhoL8gw/K5vncSEXakn/
ACWHVWMj1I+mnj5v/gZQ0xk9PBUzLgtDwR0lp+dx54VUaXKvpG9+OAoccnzO9BQot2dMRntjXqRp
AkiIAgqPKMhLuRb5lua5b0UqrqaYovQEMVZODOkQcFBPw52c9EGZUsOeuDhpNOxSy8s7fO/zUb0i
flFmx6JzDym0YeIzUmlmDP1LlG3jgF+I5fzKl3U9R/bm2NhRNPs1xsJlrbL8kCSUQtj3c93hdi4g
9HyKmMJqBww5aHFhA7rWRz210mUtnetmjzn0WFyYFWZQk7YJ7rA0QYu4yuzQZVohWtIzZhBHewWy
vrhtqcn7VTrTYp5wUs8SX4M98qNv15U/ojcxQVp+mS4Arf58zX23ERZ+PY+tllc8Kx8ntIYzEcbZ
jLsRi4wp9hvRXXg8Go9bLRMEfnQHKcyadtgN2CtL3tdKRkBL/mDONByv/BhR37780NHzhSKJQj8x
JhpKMTfp0Q/b8NcpZUh2IMuuM7NoyzdviElGapYTwnC0z4K/fQhRZXGROLKlJYVrHmemyWxmV2q5
l/Z+eRclt9qxXKCmxl5NLnRZ2ImUN1/dEZJ/rNECvB/+JMRbLzkFj94pgyRBVZ/Zjs50DD/vqG0K
e2afVHQ3urXHb5p6TeK10/aDKBsSPCZam6726fvjckHQcu+97aihngLxAquV4agS106jSwaYpyTX
VUJXVDDTGlDUwb4M0mzWGPOMbNE1icEJxtc0vYCp6X11ZYonLwC3EuOr8yLiWHOFQsLK81eX9dgG
bSk2EzGAHdPZP6tNq2VhWAIgi6IoyWJi8xjMjSnN3UOzcerrsty+l7O5FYrblYCf/j4DhadUbVyX
jzXxNGjoScmIgNiRGY0DHCuorjRVwfnDud/vx2IWgkORQL8dTFO8FXO1vJCIB43dc0/3FQdTTpUZ
Qo6v82rf5Sa86+JMFuQlI9WF+lfblo3S1vlMCt2Vhr514qdaIKrAOcLbGWevNF0A/Cv5rOu89gK2
az9ZmyCyhz0ABelAQXrdeEcAOty4k3H5NyeZ1xsyqptJkyPSj+mULym0bd0FIYafiLM2C6PFWrMV
2r/V6m43LCa8gPSXdApZUi01S1noqtocXDkTt3uEqnynkcV+6HT20DC3REZ+FjKK/qe7qV/P342Q
iFNE0QJ3iEQssS92p6ILnSZOb6ztQZNx8bqD8B4KyY0ZO+z2jEZZy0LiWE2S9yKeT76WUqQpnZxK
4I3J+jB/UJuGc1GIulI9inlBcN4cWoqTRzcYXHQitSoPAx5Af30u/N+vIZv9EpIlQ4MQmFCbHISF
m82DY3B9Z/ovBTbomGi0PP29OYK+b+AO9Yb1FraCBedP+29CsJwwyTB/37Dj/Xp6AjTlSG49jExc
MwcrKucf7HCb8KPsUEgr4efQm+ORB9XL1NCmRjvmzz65hAlENp/x27LitUwXMEzTUKT6GtJwq4zD
uezilgvE/cvAfBQv9hOyMb2HdeRPUMzNoQSA5qC/uXjTPESzW26vdakfqaqcpUjcgKtxOn+boDvZ
8Y1Mu52TN1zLLxP6C57rh5uvLOvDDfT9hFKB2+AripjYPuXK11SB6/6Q5Pe7m7uuKTUWf8IPkGOx
dc+AlIq0vC5z5yoiazwRl95sO6hyKq9iPaBI0CulXFcUKQYjWhx2ICIKZuA8NFPLri2T1XK8x7aM
LPRGFik4V9bV51lhv47qFufUw3y4bRr1/hUrGjLSy3hVL1kA7gQBAe6lSzBuvqCOGdzLH1wavs0N
zzUPJKK8p3FtjWQe1sRfQDg+aqzpZD58ubmgciwjDfehBg4dOOYWLt4CcbrW3vgO5Alg41Tpqa1G
SpRXai7rpEKRDJNMSg3xy1O2Ax2gP3CLZzjkZY8IWEps1uAOzsrRQAoEKFhQlOVdVEsIzb+lSr53
QI7jI5qZWqW0XU0LrrWmxryF1XNoo04PBNrASUI/YmsXChKO5qX4aOwo1O/CJ0fmIC90za78cEf9
TnMgx0hJZcAK3wLhJVR3MJiKVTtb/fo1zzVZi0e9gs7QfZqUDS89wcUl7iyIeK5Hzbwvt7/25L8z
dzlhD77WRxKCkpjlo+TQ+WMOCeGMWst42o4HZZ1cQnlm5iCwR/1mfpbJHMQjAHVDog4JfrvDjAb0
gBTtr30kynJ+4vkD8GxRNaAX69zproZdv27ZnzjS8cM7W/nFgsVEsgkP4N/q3zCsuXuuwth1vkEk
j+hI7AJIJDR2ylfmgbiJXzUsV2pUErr1AvagvmznWk1aZUNzhu2/nocEGUiWkaYX6ZoQGa2al2e2
6Hv9hgeN199XdWLArVwvaWsdnByVb8c1PMLFl9V5NvtElt6vGP8AD3q149yM0x1JaONPlJP6NewX
y3+D/a797Ny171QJGgDd18hn4gfIuuO502HKYBu5gZZRAed8KEy2OlcpRWUjMrEt9aQ2fUQ/9D/P
zmGM3zW/SDnsyhJFNd84DbGGuQXCv5OqmFtHs5PbuWqRWODjXKiJK9tVfhxQ6NZ8athHa/VUBuMx
QBNLLRoZ533h7xLxCj2DxtA+ek2kSOpTp7hR0CK2OT47/qRQPm662LrFDnIctuwK+CbeUYByo+93
bV64YfpvRRYNtZ/3qxWB4HhNTFPKX+7RrNfAFIBqqpbEwrTH/nEfHjF2Heioi3UzO7RAnu4tpwHK
5mqtQFjpr09qxw11zlY2CCC92kSECrEOTfiA7Fr/ADdVvenj9pJ0ZgW7W9GHHjxz/KTn3qMlyebb
cfJ9vjNd/wBvkg/LfxcJUF5U9UtVaCkQ7bOw39XFNnK8+7o1wwM1PyEnizsCRUpVmEugve4ZpGZs
o/i3sKYUXMIyYmZGpeey6Euv+BaRAZIJqGs/R3U+0GC7EmCleFHV/LKeWUVK6Bp4fJXX8Hgck3RG
M2hBFJULCkwm6aZPIhmRf9x8FpZfk8YT5eQgu5gCsuW4UO8IxEnuSqoTHKPbTniPj4tdYEzh8IWP
mBaLGT4M5/17whfwq7dZJXAkv+Rsgk26oFJRKJeOPYKUzpit9YfGZbbqz7pih2e3IKFMklgjbvg1
a61rfxOu9LNHEZPM6dHx92tUCnfVMheJj707R5qsjJbBzY6jJ4g0xtJUIth7OlZfESDEY4ja1hIE
0Yn2QqJjbRd5yAEjCbxKcjCAofjZ5TZ3ryshgLo0F5+4F5LaZVDFm22wPj6L45ITWQHXzSeTko5i
0iTR82G4nJmRoV1KzKbyn8ZzEwaWCBz1MRED1Ncn+ydbQZG6eg4RACfJrpfMfsh2J69UDu+BmTDj
8ZCBZ5cyAwwrykfwC8SfuKYicq4Jpto9uvgNpp/8tsF8xQSDQ1xqB7Of3kZqYLqGJRtRkKFKKOfR
x5g0k4rA4SEUOymDdLXpyX4WTu6NregYsifSasR/AGfqJR7jnf54Me2CTFCAb0ITq8zEOF4j9JKT
kdxu61ugLmjYDiu7zdFxuRLPEqHCK123jbfFk12WSvgD6vbvTAle31r54HfA2qMuimdDANWqi1Gf
J39uaZKMKulcsWPWDAre2gyGcHaWQD1WHQ/ds2KPcBXdQDh7TfK9ZH5q/wDlcU8+BmKewtAaiEBG
mmyit2bE1u6OR/pFxUboBgViowL12sor30znRLfzHtf5Cnfv8rxO1FIETyeWlhFldgrwsrKXma5A
O+algMN3gQnOJ0i+VqLeBYeVxV/dW92cpQDucsspl9+byUOxSCqw0SnoCv8AcZ7ETFH6Ac5Sb9vf
C/mYtKIkhS0xEi4v5raH0L6OO1I31zDdtQWQw4qKz+YT1UPls8Q3K3YAGDu0GKV0FdXMaXKXUeKw
wqD+yG/jp01tjAAzroCoqE8/fm0P1nlYVz4gG2YrVu91RDGCp2eIQ3l2WYExeLwZ0o9/NscQRv75
VcRaSthrdVkaIfY5dWZCiftyoZeh6TJ2qzPNp+ZtiTygKKoRaNEg4dpo1+KP4pRmQXN+SNeBsXNk
g5GdNIT6i6S+WdY/3slxCBlPaSR2oWJlD88yJiV+WOKytJuWPv8AepxzR/0jctVDxBThNlD+uj9V
29bivJLUU8gVZvB1qDUW2YZyaGyF2bj2AmtYSloN3fPS2vCFkEfIeXnEHRAmMRb3kzWHVE8EfOuj
pQwsJW0ygn6w6njkMWpIgJ0R8eZjKvpn7j5nzAjrW7hsx+1DAP4cq8ckZZ4sr4Go4HClXEV7L+EL
uVLTrjruFYHR5HkQozi487YilZ2yA58BLJEa1LdO0Je0RiO+YdqtIHpLBgPFa4Rid7tLcAd3BcTp
xXLahDq98lVCPUJlsOoi1CEn0DgLWYAZFyM/ZwkA2wzYJMLYEOdyUitYmxwcyEGbS0DS1sWuE3GQ
oRtyzgC7Ez/YVf2gpIVQVDe9GY25MeDcAKfKJa2zURnP4bE4+T2SsgHqi9n1I5AC3Ih7W0OrqyOc
7TrXm10DUY96ImHxy5fAboS+iIst2FD9ry8AydmwV6XsOBVQJpZKkNEvuUDoM3VOpYDOe7P1UI8g
mqdMB01jF54tKYq9nipiSt13u4VpPlFM2uZxbVl6m1j4xxCR/wDXKNHBFfmh+730sTrvPCL08OS6
/TJ3MXVWccgSmCKkL3XnwyCqlDoMhyxirvYpCWwNHCgOjSQ1r6sT4ahOfGOzqjhbsbxRS43wSp26
CE61z8zX0RFVWH3MtKIBF/TrYXCcCADVZcT/ALlQn6GgOQ6tsXvIRyZ7YU69wUKVyX4mnC52KZV1
SMgnYhxKxrfCbd9+tZfNR0Z8RT8gJ8AiHCGnvm6V6r/Oax0X+ttJncewCbd24rrQq3B90M+RpmGo
/wDzg5XNViZHiz/Oet3XZfMitiZ0MEeme8lYt1k0u2yPB6HUBjmsskBbGCYiWIOqY7TSDz5TuLt7
oOtaMMLKauRSkNktmC0+V6DosZWk8vYqrQVRmLmMqmaDDHhraA9pgGLUkBKelivPhxJeHvHBH5U3
18RrS7Y1pkl1ldyex/DvERVCU7ft4GBKjN9ZKfPav+MnFRvY0S1OnsNnrxiGAia8hz7EMslgLPx9
TcUrTxjdDmTNZwgAdxcd4PP2d6dHe2swYxMHbJ8gyZ6ICJtwNqhq1Rr6Z9XJGUAwUZKWcDpvYw9M
X8WH6lps2TjRPw0bLJhfS8Arm0FDrVUm+3MWk9dsEjkqNwSCeaflZmVxizIT+eip7DKr/l/l+eVD
vbeBM5R+8+Jukxm3KQZMvgZgRurWOTFzDm0tcZlE0FeoWT+HuRMKIt+hmPwqQ1IjjGnVtabV5on1
0x6skhAiEB0kPVxdPKA1sMSfMRj2qasfgTtPnQSHvrlwV+lj7POYnHmT6ZlgsXR6QkCzaEdmhwVo
HxSMB/TrK8MY1JCOlEZEynFEHgkYZykvxY23jbE83yUuQqO9Kyw9toubXPC4b4SrpzwDn3ylNNEk
Wbjh71vvqG0lnP3lOzAKYPLWayoyPku8cF2nVW4N1FM3+ngq/IpF5SDKy8lL9ocGmAmkysh5wcm6
MMadlAif3fJlqWwD93jgle+fNtNOry5j26HoxF14DLwtSRBjXpf2IlGmf2PutUcylMa1KlQLFTgz
AyumXyr4IsrSo+dxLNECMa9tbt/f/wB3iNPSpCWq2EJmTWFqb4uN11K6dZTzXtVT9RAwQlgRGvdw
iHGwW0xMHKALuTkl65ISc6Qkzdllbi2sITc1DNr24N6Gp4Ln6epnI29WNPUj1V8MERslRVAmDpB6
0LFWW4tMzR6byo1IDYXhuCawlW/1NZAWEFHcYmYz7fQOecNIsT2pENlVFuUS1xylchsaT+LcLZUN
fkwPpzJ6BzUIcmiSAcznagzZOC6nj5csp23iG22hpqXXIaTzUjlCwsKSOrHDWX0xcPRBsSh7kaqv
2W0hnikiiQSmlGu3htpfBP0cBbdnwN4slYlk5owHSXcf2Twa3m1Zvj8e6q1iK+e05A87cz4V9KkK
GPtAoXbo1BAYc0uv5EYpM6VQv8TPfQg0Pjd66u3sCDFc9usTwBkU5xmxZCSZiK6R+Wr1Qo3wMct2
PpWAO6XTwLAyy/WBBXUgqNRRuIQc9y0J9Ujs+IOiKhCNrdPnmlWI8h9gaQ5FMcgLB/3gDOhfS1yM
sNFHV0LiOrAnKnkloZA7cKvuCx2wwQ3inK2RbMZUVkFyRfYIkeIdsWp7biEsYzl4u4I7mL1dIFO0
CtyGA4bI02to8aFr0YeRpyvKLkjtnqp8APuNXgA93XWW8SgUBUGOP/sYjHxij1gW4LNX8L+bOwIj
pzXXHrH6MhlCOMtAhdljIgMGmjS0eaJHE8MxAvEsupsMhNZfRRifod7SaFnZCWyqml+KujWEsv0w
c61+4g1I/cqeVR55NSISr36fARO15fsQnQ7f/tHJRxqyA10SNFJesy2zU2mtGYmOXH1eGhXgabBg
Lzzv4h5lzFVvWdfvv3NjKYmDVdyUvIxG1qgedbpR4tD/AE7jZp34hshOoQD26EBIiqjM3bC8TJ0L
dzNhP9TdU6Gbmr4jk8FuPJlhe0RfOLwxRFwS4F5ERpyW5IkWbh668sfp5xQkDhV1xy5C5vDpL5sC
NziuIy1usrQqC6TfxtfGoSSLZKw0wPeIKLOtP6I8SVesnKkXpf1iUvTroRcSuU7cg7CITDB6U5Jv
DWMtVwvcZZejteQPrQtu8jTypgfM/WEcsKKL7/ldzeVw3DsJqmdU8Y4izCUsU8aajnpr3hPD3ZPM
LH71GdnfaRxHg1ColCPRGAIkXz0FmJLbZx0IBwBp36d3m9T62nOj27lGPetoaCNyB4glrAq/Vspj
gxaMvyQACl3hPG+CohlQwOdp9te4BGA+51L11UdtEMcx8n89yEl0HGkP9ZV7iYrt5378LBVPstcT
+29lhCu7+sxFa6lYaSq6GuKnClnTCqv8bTtboIffuvnvH/8AHidqOT3KHBLzd943UJMHGyPjOWgm
+75TID0jD6zaYGOnKSDK+xH7fRkNx6nfyjN8P6bPYvEFSznEb4QXYvI02ylYl+Teo7/CQbokCZMe
/wBSJx7bQp+yG0FMulrF9TAAUAE3qDIcbfmU4yzrSVWS4jtfkssVWdDsUNsEcCr+dckQ8OnC9qxd
J80CCk0rp5Z1V5nnvWrtMASlfJkylWMXA78JAkT4L1G+Gg4tpu0FMXMrJZqcygNIul3wlIjxJaLd
CNsDO/qqOKLIvcAcXJDJukrp5f8A4vu1Btl8VqO6G4rU3fdFn4vFaQEAQXVn/wD9TdUQ7lR/2oUv
KNpHRKnt8P3s17MvHOuO5m/iIlriIbnHVQAJGhKXBUPcwggg+MjzgQY+FYLWnoT5IX9JFJ0xuG+r
kiPqL6zPKFF3aoiAdcMjpTR+JH4UziA8J4Gs7y9YhU+XvJdbVwf5hIdpI2c5X3KltnfuKuZehU90
UzGZJge4Dfce+2K0vs5epdPuck/Bl5FlUseWrzoRmUAbkG/Rt+SO12KJjV2UAHHw8tCuqEM9RGdx
PJ0/bgcIxpLnue8Etn67exlkBTJnSAk7TAQePmC+Z/wI04MvtWeJ/IyB8/A2wGf3Ga2fcvHAzhtP
5+vc4Ixff9pfvm4AtIvM269hBFTYwEYGHxUdQBLHHmERtwq5YNZ5heSlgtorWZ77MqR5DgRQH2cO
lH2zxvMCM++VMpKHtdu9nnnKw7CKxoHUKalF1z29rjAgk81quYOArOJJk1r/ANU90qXJ8npaNNOm
8II5UFJU0MYb8HaSqIxA1xWpfsPRN44RaVzye6oNqdIflSIxaEh1IoJEEWArwNUennw4tTdQ+6WV
d3f58NnGiMtlnWgZZICrF5ct3FIUFZPq+u3Oe095dYWOcrTVQMyjxZqhBXZF9VJB2Cvgild8QTyn
DfR/QGqEEfOXuJUNw7PUOW9YBOMykbkW6Ymow4JMGgVKk8uZE4UwCgj5oDg0Ppc4HU01UFeBoHVV
XjZNouB1iMdnLULtTdaNvEPpjP1NaX5ObRmjwGBPhZuvmCpM2Q8GUGWjYCx00hIblRBlD7VJ7TWe
GhDj6WTRkYiCD2J1Fb5vZYfzr1XXrDDuTt7DIxVo4Z3vfe6IwG8nQ2svAMWXfH9Hqp8hh2LdHPpN
Eb2tQN5mHwj5daqETT3d67eceoBm+697X19JqEfoa3fxAoGXCnjauCjhXjDLPlzYaghQqviIIfVm
mIjsEBTnJTl66tYHDITqxnmHc98ZD4ppii4etP8A/8QAKBABAAMAAgICAgMBAQEBAQEAAQARITFB
UWFxgZGhscHR4fDxECAw/9oACAEBAAE/EKAHgVnzRbAGqcP3NDPB5gAAWIWWvJAN5ef9iLU0qghq
VXVrJf3V23ghse1QNZjzKGFXm+oECvmrGqksoiO4dMtBdBDRt3q4p0cqMpTTjZZ6HUSJQOZjVdND
BTa9/EF6m1+YmqPiXCjuCzlgVMB5ckWlYB4ZWoKP2iVAJ5it2l+5ksQwBPMQrHTmWAgKeb5nHuPZ
O2H5iCt+mHfdXDQLgYAq/icQC5OXgPF7L2FfMsG1kQF+mI1LwVKrTPUQ0Gq2NVAsooDfnqEsXS51
BD3Kex6TacQEvhHJAIS+75i15w9dwsA+oBOKuYkAbr9ypvF57ldSmoCgR4p3EF5d1UoAjOJS0FKS
4cMoLtgFuEDAnhhKTV6uIXgikDjzFVK97BqtiANuHiXAqvzNor4nCb/UbeL6iZAdbFu1olxdjgI4
SKONgVcLyoVpr3AXtMWBrRhxDb/Ecstdz/8ADCZopeYQNUa5haLc9RQLe1j+lcy2ptnECHoZQsNN
i3a7G1od1EgVw8xmJQs83Bd2I3RR7mnYXAnxayu5SqKDFqcHqGkPoVxCtmVHVXIN0wy0HcuhHmIk
LCFytQx7jrhS/U+T8oKOA8MYSqhC3NKhvi5u+ICrLD52W7/DKcoIsI9VNmpwN8TlXpKxpy1AOC0S
JreEtAOYIKe7TwRRBWaHzO9eevUC8vWnqGKVRbk0eWKsYwuniDqWdIJH4ncpNN+PUqBVWh5iNs60
9wW3fiHcbsuFzxXFzIlCXxOCwGW6JxVMZawuhNM0ncAnRdCUGi75lpckEGhrm7iA61Ao0TuAOCJb
Yb5YoAcbAAHPUqxSSDFG1adyhMF8QgLNLLilmPzL26uodpzKyENFumWU5sJKHsbLM1csMsr9woCv
MR7fMQvA9wIaU9bEFuV2RBQbrGotQCpcwziUWUgImQHmZhqi8ildvzcTScQeO4KEy4vW0RGbsdKY
DpfcyB33DQQOUDibuMa3B7SCVMggURlRFYPzCW/GaKqEJgo4mh1cyh250eDuXDMuF/dMYNIEqDGj
uAbR7ZTFc+JZUXruW9W1CvncxLijylkFWeY0A1ZQum+oqwt44lRTUSN1sU+Tqa7gZLFdvGUMNZZK
aWsDliNPxRDSqCQMKt6uPBhFzKh2paDg8wu+xvNgCXhx7jhp5l4phiVAgNgHcdQddeZmyFuCCrYv
plxDUAlRtFrDqP5gXNlq+OoNAbnMCyA3HM+jVSgNGV4jUXrBVfN8XDGxQ1P/AEViib5MuF7uDkmP
J4JSIvuL7u2ELJxDlai8VPihKGo1LAysSbv1LbErzsReBy9x3K+ErAZGUJREbcbwKiF0o4hANVDB
W8HuGQNuIAPCjILnLlvU2hJ1DAXbXTMpt5uW12vB8TmXely9QPPEGp0y3g2XAr8+4AL8RhNltWWE
4b8xb0F+4wCo2V1ex2QabinbpAB5RjhgKJdlbGsCoqnOTYqfHliErt5GFHLOfcBwV0z431Nd3Da7
YZAu9mQBX0i0lBk9iPDAg5EGk5EMAOuo5Qp5WCE0eyM0CcjFHp6iq4nR3KKWClY+EYJj8wazW+1g
FB1zEKPCYxUdovi5csz7iFwv3FYFrzNSjPco4SP6iDGJzcsTdDn4hGu2uPMTRNcb/wDiRWvb7ub1
aHvxDTDfYxdqgql16JQHPEUPKoVC6rmOoLPNwPZe7gaC2MW0X8R2BfYHMVlFq4imsWNfkgggE5L6
hHt1U4LZBBdx48IhLt9QgCulwbyjtcvm9hium9m2nqVVNVp5iVM0J3OPpEA7UD4CuZuOUsqj3MV2
yLsrfq4DVa5ZAnqcQFL1t3CQwslZum4NRKjxLwMA5IxvvmuINhQX5imjjx6mjOeNg1gtYhO9Le+o
Ab54Yep9Uy0IL4mlLCdMRdhzxsC5o8bxAFNcfcsj41FsKXb3Kggu1Q8Qu0+LiFhoaX5g0dPJiQff
cu7aBTUKgaMPTA1v/wAjUv7iLfGOxK4fAPMFumtphFX/AL4l2L206JQIMAKqEFIYviptLvkiO/2u
ThuhzcQKa8XsogQW7jmVN1rKKWPkYHNHqu4s2xtRwQZzEgvB+CZLoa9sAN8IJfJcTgFHLgjdPlHy
fnYpYqN5l+PovqAbt04YDykvzKjhrEMvqpblXC0i+KuDIBwrzEtgqurmKJXplRXW1dxTUfLcQC+k
OeXHPEOGjm4ESz5RSlme4lpC/MoanZAKfkiL5XAYsSXvDRZuwoBKDLUte44yvjxB8FndzSXojQUB
5blZ8olgNqVKEW8sCrgOI4vBlRlDuazb7lMgraIIcrHMFy2UUjyBXmO4KYd9KggbC+oilG9plBKH
fVQP4TnmXo+CGV28izwcxN+uWBqlckZypgwQqXdcbLTcAxJQxowXc4hYKe4Vs4SYB1vmCU/lsDQc
+dh478oFwH3zNFZ9y80fmIUIJywNpHHUHUV7T4nogEtXY0WBFEEzeYkEY1vwNwAFv4YJU6zJbdu8
/UFt75lQOR4nLoGxNUNL/EKlgE5JZhbzcUznxcGa8dStLN7mIVHcAG2/MGoUju4ERNPmDdUezDpw
pxuNVoPmWiwc+IFEsvgZSWU/MAkw5kUWa2+Zzr+E9RL9A7xA619vUCAjc3QFPFM2celyo+CCg29Q
bC/DMIe0H6Uu8lB5OkxgAOYhZte+iAoKadlOs4KjABZ57hAu1LGWB3OkMy+P3AWgKha9OuAF8wHD
EDCpgAdvJgHDriEWlMY4ClgjaPzD1ioh2RbjVU04YRahlQKbN7ubNK8sA3AUSg8QyL78ykzHEL6S
F2t83Eyh8XGVfDuNQjzlSwFT3s4NE7lYBuKoAJzbKxQX3xF6B+BjaVw2CddWl9QcHk1dwrCnmACi
3JEIBydwYRo8xkKFwd0R7uIK/ECqwjHtTm8QOw8F5LU6XauXBCzqLBrYjoD3EmvSoCtbueWXiWbb
wN8QwD8k359YbCjPPE3QqMMcG0SGy6yHHAe4HiHvYBoDIB7b3EGxfzBBZrd6lOg+jxAagvzBtqNQ
g2Li4UW+GWqi3DB0T7Q1oQLxjqbXmWyiCi4SAAb0lXaObHD2UNxpZwGQVlXXuUcOe5am1ZSIjz1G
6wYPSZ8zzjeGVqhD1Ny0PmCUFdxlzYokyCr7ImGbkCjkWbkNeIwo0PUUO03cqDx67nWB4qagUqkj
QHEGd09RXK19ynQqeHqXUIL5tOYhyqfUraUrxOgs9yobwVUS0pXM0ABvbS2qwv7itlfiLCXfbceX
S+4BWt9xabcFvTlkvCvzLFbrDo0XqMPPYSvCLhRC6gIDjx4naV9SkOkWUY8xxpItm0xyq8jQLD5j
QW3BV8vUIR/mZ2D7XKlpS+WMtOPuNIQPE7geY1KQHuFtNipg01vmWMQSgb2vqeFHTO+zoiRQt7nC
Cu5sLfHU3TaoqqVxqHURtVh3v3C6hJ0Byd63E2GpZXhnBMrVtbEhvTucGzn4D7S4pUDbGusnuS48
o0cwRwiXbdpFO34hdYpC3lLm1WWu7TflPYlV0iXDFnFrPEsUN22xyLS3sz3JVtrhtKgPcPJFK1Km
ha4p2/M59bAO7+YBw1K1defc7rbgPaPOZdwAgt5i5VqngUE5VdQutd4i/KcK1TUbRVqliNPEOO4E
qPPMujwwuBbktRW2Xct+5yakoAtyNpaXN2llrY3DemTsFcy05X5iKlVPZvFy1LWRrxbgujcpohZ5
MBsxOZsRYR6qKlXlVAaK4iqVWFFXDiWm92fiAVwimqk2vtAd7VT2QpA165huxs7gXRoOIRhxznMC
Oy+A4ZcHrsisUvgh4ge2eWArBYrgo5idN07srqLo6l9tz5idR8qh5w1QXF8teiLoCy4zRp9Q4Ldb
qC3zUEpWvMa1shWU+FdQJ1vwnJrsBOIu2NXDnbDEUIoI17lmlN5m2c8dRdcKwuaxX1cXRfuAFVTr
qVqjV9S2X6g3KqCUcIFVrLhZT0x22E9wRop7izVq7hzrfqBXauLBpiGixVu+IWZpLdE8sP3O24e4
8+85AlE5KhawrrEw2oSwbbfMWdVYqhU8xMip4lVhq8yFvVrmLqFV9y1qvUDFuw9xrFr4Liem1zLe
Rlv27CutT7mVWkEYpY6stnRb6litW4vBUkt6b9y3m6ZSsL7Ihzz1sBWjfVxIAYOYvz9xbii4NXkq
AiSq9zgJVcmxAz/8W/8A8Wz/APD4/wD1iwZ7JcvZ+/mUQJRBLQX4E0HHEpOSMW//AMxGcTmC8BSW
yNHYRR1BvxLol6gUVTyIC5BI0X8QGxV7ilQqVfVsq1l8ZzHKuRog6BK8BGEY8JOURNCvxK+A8pHc
cYJaNYpXwCYXqHySsmH8AQYXT1FDSUwHR+JQ2LfEqzLjY2lhkWNjwR2vkSMdwv0Ru3DwozF8SVEI
FPAQYdK+Oo3+Vn6uSCq9/KD3Q9JlAwXAoYtwQYeTjcOs/wArI2GDkCIfJ5Qx+8UXyEfDH/8A0zJc
X/8AkLnBA/8A4t8S3/8ARZexbYMX/wDgai3/AP1stg5Fv/8AhPcv/wDahkGdypX/AOX/APilyyJO
JeS7/wDwb/8Ay+pVTPzOJdy//wBX/wDaqVK//X/9XLh5CHgJaBblnKH2RmeJTR4gpizIZYoBhiDT
tdS3BHK7igUqycOtNyBlT3KtZoF68VxH0VdnUvm/e5NLLqLQhOO2JlRDhiFQ8eiO3eDhijW4APPx
FPBQxRtfiVD2vBObTLU8XFF+xB8D78zIuPEHg3eDDrYer7iPpEyyI1u8VzARsIrDk5nyiUkEqNjc
w64uNVgfEd7zT7lBZY5MUrk3IgD5qUR0YpV4ULajUEDDpBXMYDKspGxiqPcYkOMISitqrmUBTVqW
7FcAgNbdDhlCM5sxRdlEVal2Rffo+cUdxKwgBTxNDCLL8yrbdFcS2BTQefUBMAEdk1/Pq2WZd3Xc
amGhDaHguyyuVUOEPOxGAVhXUsFmXdQrAFbXJLiKLSxRvIIDWTP5Rx1B16lzMeqKyj6dThGXTxRs
My08MZVaqgMqqPXuWNUsodRVShxWv6hyHF3qH0KNZAgfW7mS50MrlqUVKY1cpfMJUByAIw1dtLxH
5mzauIx1UuuTiErZdymPMtyKuDbos8y7x1KqKGmJ9QhrXxB5G7Dj7jpMnFN9sKOTx5jYMxcYq6cu
DzKas4iWbMhbZXEGiqxiJSXBYwC7FvhBxYcnFSlx0QI7qW6P3DSCsV9S2iKZFvwU8OZTwdInMdax
S+CR1dTzWcyqyo17VsHzgTuVcLwnBHIk2UN9QhApAfrIYVqqlfpQq8TxJ5N2zlrTRnzCZyFlfuBR
CTajsHvlzNRThVgy6WTA4gwKdHe1ESBamsYYRaK8a9wPIAKDUzUBdMvRi2PeyqQgCqI7jcDjIpcF
NyoSWmq+JT6BxWi1gcimAqqK3jzOA0FZZ7qLjIshRQQWwA5f4ggg/A/rqEby5vgrVdgAbNyKEhVV
KPO9K/yVpNilTnBLN1hwD3FDJQcH1UKkXEUzuUUKu+HiLFoT5iYWgyy8ZHJTVzv/APOSVK//ADj/
APQVijmBcrYHc3INysu5dn/5TL2OFv6gW1xKm3kbJXDkTI0qkYlf/g3wSz1K2HFdwXDLH1KlZfJN
EwKGJTXct4yNC5UUQAgXBr8RPUoJpVlEUvEVXWRIXvqB8spukqNQUX1AuVT3cLuuZW13AxyKGoY4
gUxH3BWVEacgg49zVrPicRgmW1HVxEaZxCN+IHXcRSxfHL6iI1WxpFlpbx7nbIbahah+Z8U0V4OP
csrHtGQRzxCuh8ICUUVHzDNHgej5+Inyco5fEztAR0p/qUVFKIHuLhvsdswlmA5sLEMAQMahhAUq
04lvymAcwPSAL1x4mpSgo5ndj89vMAjQaB8wCIct5rhicweAh0oj3Om5zZxCjshgcqVNtOjbhy5B
eKjJBOietmcoCKL89SvSVeIomWFcR94AIyYclVV/UHCRcAfLFI0Ab7rJmAg7IbMtFgAgc8x2pkUe
z1UpqJukDSYqcfE2EdBC3oAV4l8yCzzxMmFdNbgJrE1g755vKLQCyukNuAwvVJec+IQTaNC7gYKC
jyTaJQoe4ctBVDuXDhjEXdjhlrxD4mCI7gomhVBBlugI57ZH9pevQUo4jFDUJXJV0pt3OJa7FeIX
AGqe/c5I28P3CkR1nmcfb4W7BLWo31kCNCi+C4/FWgrqpa1d5qU3AVbasLEjgg7QG1UoduIYnuDW
eM4qXFBtFs9MRCxRPKaFVdQQiulggy8uhxCTq6OOCF/RXcuWhPn4ntazsZu0Vc4JXdeBwIBS9bIf
YGQeKvuVN0B/EWGziuYZhvR+IQgoGJrNJ0Q4mhViPBd9ywSxSon/AAS/p8wXB3HWHlVjDVL8VlMM
Qp3XMHAN4YCdfw9RuyUu4ii2izn1EB+QYB88wshPX6GIWIKONhzFCowVDlCgnB2CkiJWHcRLOpac
Gx4ebUdxrG2lFcdMp2N8EtZGXnNN4h6JmrjOCH005X8Rswy5u67gzRU45L4gXpQBiqHv7j7SIXyO
YCouXTnIQvLcd0/3Be4Lvi0CaVa2/MeDUvMf+VE9wyOQsvWM/wDR5jLAgB9PNy3EoY0mwB9M4hTV
8xEpc5xkOcCgrnqPgBIGjtDC6omQiEa1wWHlXC4fUV+zgm6hQQBnK+yUyIIrb6hXShTuyn22I6JU
cZFqIdESlo6NV7jIdFt3Riyr29o7dMLoLFcnCy/ABnGeYQQ4RV33Ah9BxlhQvuooJUXWt9weQJfj
qspxh3yQkIOrUWSmEUbvDMykqj1CFsClKkhAtvqApZv7uWnBKzXOcdy8alnB+YKYwAMUl9Lyis/7
AJYq80QDRy43s0hT4R0ZEphrFFKlI4g2ylcCKy10wqFYweaHqX8GKM19xXMhofcHI1OoomsHmXU1
eVdECsV8y8K07uJZlMSxBbSeDuHirahHqKzivicAH4j0OwKPmCqjibdSjmSn3gom7H254hVUJfUS
yhXCoETuvE0OrnkB5lENXbxBquIFM5RQq4cvEYgz3EWo7ns5iFkvqoUtg8QGhM8w1QI1Msm3IIap
Xwy+Bb1F/H0weDnn1NFqv0iJ8sgRefcUIoHUGWyBvhUYi89E5d0wA51MAzOJbN2uoOwSLohTsjxw
NCnMFexXpI301ruCCcq9hS6XvmdA1w+YbVVSyK08TDRhT0FVG1K/EAKzr5h91y3x/MO4HuI6FPUL
SBHbuAvLjxcOKCHPiPFrccUS3tZD4WMqD089xJ6lthVAmURrWN29xhslLPPibL3d2wIBml6ht6Dp
6yCnrbeQGaDgheysrzCOoI37iUOIX4qBitWlbBzYniAhfUUbKvglBhS7eCW6CHjmsBvIGRP0qPEy
hRznMtblabNh7i0BFtli2CXTHkjqzhI2BOyNp+0TUBdt+U1ZeXlr1BKdu92VeBo89wnAVbmFaAeR
3Cajdi6+JRC5HysheCgE2pfJlR6hU2V5iaAWF8sKMVKTleUfLYmgMr7gAAFx8ZLzhbdzWHAl8my2
sbWVmQK2UkOkMko52Be0Br52ELpYkBiKRrzsAYBpuFuFhB5lYLdV9yvQJQBhOIRl/MO0RFr4bipB
wI8wLfU+o/qsoJKD3C6MGV9CbjxkcstbeybmKeIjALhp2WsHV4XGJRrj+JnyNIlzkxIJYws6C94q
ottBgTbCHCBdEK0MAHvZYM6F8w5YftcKFcqvzGDjQnxKRlg3W8xnDqHxAPoiDzKOmDaAFPohAFPO
fceAFIu+CEXVh0HMIeGwsOslLAbIlB55qDCM9zavLFds8TYTYIlKeKjsk1MLruAKrVH81L1wH4I7
BD5D+ZshcHbCMaFQKN5i/K5DhlTQDhz6h3Hk0epwZOXbcgvBT5fEuecquUW0pbx5hsKYvua9jTpY
rRl9Q7jDY00JhDXAF8bkYll1J4mFOx4XK/1rAt0Ps13HaooPENLPBXuuSAtMXQRlqyvnOJYiEyV4
YBrhHtmxF9aL4qPKq1nISsDkDDTZSLYVflcWsmE4gqpn6jZBVt+obiwJXgI2YbqvbGs7T4dShbLo
9NOxGJT8E3SaLXxLKW2w9zl1hZed4iqIsieSYK2FBfMElWHsqCCNPS3DRGzkPFQuP1X7UwNaE/8A
j5lhwRB4WWctGr4uUyoADuWcQpndTCLdgeL7hbxXE+o15rK+o4VYpTxaJxcC+GRCFuLZwRR2O1n4
ikXVp8wXBeVQft6aRYrqyo3WIaef/EubhBeSXFJ8ASDlVuPEewoUajh79S4CtlFy/UNGi6nXqOKt
iUJ0RusikZREIOPqAiuXiKDQ/MBUNUiKk/EE5G3KDp/SIc7cQXZbOKQqCtNiTUpSWVwLOok83fUV
1OeAl9VayoKnAXYrYFkEorureSOHChcba7f0ltqv1BK9yroEHKHAUxTLc+JYwfctd19wWrLlxyvm
Luw4gaIhQQrKgyq76gMWv9SxX8IvgJYjzKum2Kl8X3KLrljrXqOijqWgO+poFSbBXVfEa6TYSmW+
2JVBz+pahBjNA8Iha6dzeO0zpofUdArzdww3bUyurWI2pMfzlBpd/qaysdgrMrpMzdvHxOZF1A4t
8SzYNDiWAG9xMvD5jZ5tQF1ysBVYijylAor3cJN4littWqjwnPuOAzlg744RA5/E3Qg3kqFCWhWs
JriArLHxKeGEL4HUTa7RKyhTzARMIBxqPicorU8xqCqR5ZbqgM9zGJK0/FkC6FoVLMrU1zvMoCPQ
SsHaHuIyQQr6jScNh8IqcVp4hZqhSeYlxL2QUC7qFebmElFp5zuWosFRGUD33C+FqXBX4ANsZMVV
jxG0Ilq3WIWmhXxAliVBMCQG3zA7iAs13Dl0AfiAzDwgFSAW3BL7lSftGC0fMiYjya/WTgYhzY4B
0iaww5YNnJ5gjoUSup5PH8QaJWYRCCjb2yHgQcurl2iNP3FtgKV6g0QHdvct1o49ql9LBaYU7CGc
FNw7NiqDzsutPIB3HNn9cMRAzDjNgz3lCSKQVMruEdATRzaU+Ys7RHkvn4hODiPXiHhQoteiKlrU
vhKwwNLzGUlQ+fMA/aLrXslVaKkrPmM1INHxKAlr+NgoVQCDN7lWyWOKaTqXmLTp5KgmjbfuM1ig
h7uDYC03fLqIAIu9P3HnejapVwpBdineQzFMES9m9LEdtJscMTTiULFQ05lEoosLY6+g2vWyohVS
oU06SvbVhBEG1SnoVQPFxyxm0LqhC3o8RQEQMv3OdKifSEVK5rhqBNGlp9QhDNWVCdb3LKXQ0hg5
JUymtqXy09kLq2QLFvzKAijFt3STXzHZCm+PUS6a0hzH7Ae2rg8Nl0XNOL8tTzvA4ziXaReOrMzA
KiGpHRLrqPwGW24jGnioHk4AN+YLFBaUpfqcZp3Ab8ZE7GzZwG/DDUblPcvzgX+5Q2Si+XD/ACci
lI7awiyIUQGid+TJYwbLOPlmgwl2t4gepZLttu2XhKpbi5clAL313LFuFW/U8OFpz6nOUJvZ1KCV
nP4mV6aeyBHUFuF8S4ljqm6l3l7geN34MOPVUmbaJy+4sI/ArfmYoro9kg6jK2vF3Lraz5JstBVf
xLJFOTx3LBVAC3XEOttuiu4IYJQXkiPxY04rYHoLboeJdjZD8vMJFZsNYosu1ufmB3FhBuvLFkeS
XrzA1ahNLJU3wXpS+/MrDK2uyGAU2njY/pORPDKPUClHZNziY5S1DE+rgRzjmdATf7lAtqT83/MF
u+B8bDIXUr+YNekTDe5ijaLUh6qBtOBqr8svxl0r1X/IqiogS+Y5x3LRQWssjtMNlpRNDnioJ1V9
S+VZOeyvmVU5nEAaDXmUGl+7gIN9RMLfTHDiJnZqAqVKrAt5EXjjqWGw35gqG3uUKoCHZdxQSwjr
T8S1UPuOm1oiQDXu4t6GwSt2WWSi4rgUXKLjDk3HJeihHluBwvlBrdoLrk24AKDzEtzfmWVW5zbC
iQ48RF1Ye2f7U4pviAVP2ghr9RQ2GXNy8fEUFdObmF6rshsNjXU4k1fmBXNLk7XvuFAUY7GwePIX
1aRu4d7mOsYsVsDnuD8dSmzgd3KCjDcgwOBsug8HbEqjmqmQYspla1eeY2yzPU6nh3GwK7xH9ERl
SuZq68wAESGh4hW1XYLCDTzAvXxMpgycJ15Jei+KqcdDxkFHFUwpr1w//kv+gYQeXDfUQSa4lVnP
qA8VG+4BkaUP8wjMN2h9aAr9QsSc7hal+SuR7lB2SHm4pnho9zYq83iiYDdFxWPkvOclrRwMIbRI
M1SOTzbGyBdRP9SniY2G6BlNpDzcsKCVzG07MJ45m6ltcSkm6vWWrULXNgQBbA4R8bBV6hfAOnzA
5xZscgDReYHQSveE8SuILFnxDg2tgPguF9+ooM9dnYqag8kQAJO3LKmJ3FvlsXJWetamd+mobY58
4Fcx9AnR7jgVLUj+IHuVtlxcYpbZaFSR5ORegs/PDUDRbl8y66O6/L/sRZLBEI9KdPUvotGbFfYE
lkUWUjMBXIh2qYPUWigK8Q7pMsmYhUT2zHBcAuo3CJleJuHhzyQYA84Ir2jyhLsHOyh4TlvJCAqV
p7gG0WqpDQla2XNG5ZrU2gDd5B02qbzzDWKfo9RVYu1DmWtRKEQuCtBeDLHl92UQ+QccPuZqFi+4
bxGxE5ilMC2/MobOdjwzMv8ACTkcLuP1FtBZsvqWdTu8HiOi1WI5jq7EeJT630yl+qLVsDcucS2U
gdIc2nsSoFgZGwAORFkaeBKmiLdiWJQtNQYHcDBKH8R4woF0IK1/IfmAxAaKLfKxCihrteZawtoc
RGUG1obuUDtwzGN9C0muh5BRfEoO9F2WvMaAOEOiDrkWIPUYRvlaEFgXcBmjHJyxAk7IvCjSc+kM
ztIA/wCzizDwEVWPhwkNClWmReYN7lUXp0WKfdy2ZKHgTp54i7hDSVKHiPwAsbA7W5cB14aVrBoU
8PCLwtUp48y6UHYR9QdD4I7D+37lHQFFhNaFAbXUHuHaFCIVWl8xESDDMXbH3AvF4cs3mYtgRpCE
i20phG3uRR7ZGofPMFKNitsLMNi3MSsXtqlwwdlr9onvNcMcY3dchB0B/lcUoIt3D6+ZVObztFgC
eeEpLa0ob+BlwrdlW+ZygfKxxbULXvgJru028sqJxcerBPIqEAEsLziDuW+SC7RDW1B72a4W+zZi
tUoqNW0m+oObZsgHzrH6z5BkFi7ArA6h4gdlEDCUUr2UL1GlWFOHtmjycqKhjc18QtX8Eu2+OoKv
c4srbrzDrir8MbFVx3ClPMS0O4JLgLCUvcC6CnzEqqNkLGxnAp3INXMaKNj6hjjHzChEpYAqq6qO
K9QOtfMFIzldPmDPCCQC67jYbWzB6JRoahBD1ETpNLG9ijAFhwe5UvNYUgL9+Iyl3eoimi1idJvE
Lg3qGau4I0cCqlm+GF8DXmKmZfUwCqWVIqvctGDywZbQeY9WF9xVB1kWXcIBBKeqmUrlVw8G114n
kLfUKOqlT1cFBy9EGjM9RKpi6gVypHwOXyygY3HVsjeRSdsVU6zXTYhwA9xRJakWORvQK6isHjeJ
cSo79F+IUBV3wygnAdZamrb5Yic2+I51dbzGmkV2lJrXL/8AC0c3EsWP8wNk/wAEwQoPMEkRvpl7
wQX/AJZqejT0sTGRqdYClQJZ4IVbghnBeOFdykNw0tnMfcq1/EsCeu9lQQGLLjSsFnesDwjjXPmY
QrXDX/kEi1250chNq3slCGnklkF7mxnqHEAZq2l6/ExUaYG/K7nF1jbn8z4a0AOCGnbuB97KqW+B
iySjAR48bH8wCGcAcx7hXK4mFNr2vL3D0wOEY6rnlyghgPNy24flFWah7hoJr5jFLwEvePJbWJFi
/BCxoV58QHcCr4IWSxSwvVW4VlrgUROSvt1Zw/iWQzqsI3FOIxIkxG95Epnbg4ypDF5RqBjAo6yV
UCUU1UQIq6qzO09yhuLXdm87usIHwNwO5dBWPgPunmPULlIJWg3AJuKpbNwPZATUHIbYFCuCLcwW
HqZqhqoMxRldSNtVibdp7IJrlL1f6hpUDBdV+ZarflWN3w0SVlsp0f3NWXNtf5lSsG+ZSPSqdx3K
Ti1CHS27gMNLCu5WwRQdYpV7rjliNvOZZxel4fMtFdeeIgS7KdTkZl0U7kTNpZmDXBUZnp2FyyJl
BTu509QA+zCKrC4LoBTlzY/MvRRkpWr8UiziXgSxveNZfYj7Jcifgly9MOauCNt+aYKGpQWw8Quh
O9bZFoMNLiWrBfLFD5j406tiHVUYGCj3C9MPFSnolI9sQgnKSLPECQoNR9SvA+EfxE7QeESUlFgV
puPfmPW3XdVHpVte41NqrBYfFQIw06jjW7JAFWtdNQqF3GpyKuNsuVrzfEZarzi1lYpa4LgtcPUc
g69tgt6PlWKceGdKW/DVS1cbRexVS3s0OuvxGRDpuojNi8axU8niL5RgDiIgceStR2e4bA9aXr7n
Dl4u4ih+XiKA2xlVuEP9SiBJtLy/cIrvhcY1br7g1pAcLGuwqUwZ3KWcv4h9rpHUFu2DVEXLriUQ
svu2DdNPuVBhooWUK4IFlBXFEsnT5uFGmyxsIuvct02e+niIugqL5OIj/sTvfSVIT8E2CHYhRX5w
SuVgVoPENTvti1SaQsIJVERbZEGF0kYwWuQYQX1kKLkwfMPdacy1mX4mtXqmJdPKNqnS/qWxBqLY
VzxC3hVwsDyg46X48Sjo7LNjviYb4ihmXAsuctFsKQqg5ZytPVzq41zcPFwyupx8QpK3DYrRBCbP
MVyLT3LU0p4iAAx0Atvqe0KhAlf6DAKCreJR2T0RNXHgVDJVl83K81JkyLUzHLM7/pOGtVzcASmy
9AD7lr0dKjAODmWWIjz6lF07ITf9wUWHC+ZhvKOAhUrhLvxLDOJuoEYFWzCeVljEDBDhbKVpxcj1
LFXBz66g0buDYCn5lUBcBdv5jVeHWQxzz5hTZ+RF3GkUKg/H/wCV7ePSMdYfLEVjWp8k3PK9eJX1
UZLlqag52C6TrzHaF4Owpcnt1ABvBolvAgaOWXSrQfBJXvhBOMqxUKsSHl5hHAq4qWsAXlYwNgNP
JCrQdU5+ImafKlw0pi4aVX7gO1C48zbFY5TzNAXSHMYqWkqJMISoAXhBU5qphYs4+ZUEiT27Qkts
j0XHbKBByBoKXLAGg4nLNENIgzK4rblQ+iEIuEuOuZLkz5qByC1XHqJew3Uzg2NA9cMrSmsVBUPE
uAJ2ErfCDwePiKLbfUMPJFoHzNUZWSzXHcot6hseV3L6KiX8QdKVOFdzbK11csXa+IjeLfcVenxc
5tVDEX3LgBSI6SvuUVKt7melHkgkFDu4XWaXUukRKfMTYsWBXEUtVbL07pddS5eohYq8A/UJW2v4
gcbYyLdBZYR21ZkT7slqGh8DuCAgOIggpl000/cR8PUwu6IJGnzN1c4JSPTGo5SaZFTzAJhcFbsv
3GVLIU7Y6gA1TuCzac1BYYwLwczMNCi0eBUUhkYpBLlPEsUn3B4tchzW234iOlXS6QQey8Jxvw+o
EQAoy+IJFPMUiQnZF0Kj7ZMqsWX6AUCuYwNLW/EMUX5nkZARZcI1BuvTzGhdm8RODdstYtFXMss8
r9S9FxRXfqmUBTvMHR49QHctlZFAzPLAIhlTDbj/ABBXtqTifh7hUvzxHYPQRaDHg8S2VHDfUFF8
xCtLQ7LSLR7h+tJQE5X3sxjy1DCv4j02iH8xkMqP5l+2wNWsoyQL5Wclixr3F8ZCBYr7gNWELcc1
lAYe55jwgCqBXl445l2E3DjeJYSzzGmERE67glD5ijmQac16mNXAVrbqGqjbqUDH1PHdJSt4fPUs
puyvMAK5vqYtiHmYW65otgbW+J03PmctfU4gHmWBuCCIcIOEp8TdRXjuLNFpkosOiv4lSDYCq9MK
AxZXEf2BRgxjDRWFHwQC7lMdXB4bS1Oo6J0NhLIbNq5B2XRuFjwwMfooqoMwNOAQsWjFhqvI4CX9
zXXm5Y1TLi8rjhCgY1WMiH0niC9D7Ip87ABbq6pxHcQ8Kymg04iiOXwykET5lPunWUlJVO53Sco8
wV71DUwDi+ojrXq4gNd6qAuhd+WKJariosQetwGlXsAFAi0RUMKovmG/FBVZ5HzGhHiHOysQT2Sb
QyoAJLlluGVMl7g+P+S4ZaUlwwxld89wUL1V3Au62pmIXLVXjmUNOCYKxepU7KYF2Ok58g1A0G1G
aO5YxiuYiIxlqRfywSVlayrZxMils/tRQ4DiE10PN+I16lfzKKO40Uw8wTYcuWUK0gB/hCgVLWs7
2WLC7gYC3vxL+oiLu+GEtYy2M2WX8ahMbUYT2lDuKiNsPMohwCJbfiKyGgXuAW6jiKSoFdpxUHi6
1zIoxSRriN7oIr4sckcTmaSEFxC2HEr/AJOOU8y6bbOuBcenxMVUa+ZR6KLB0KqA5e0VcnuJ7HBG
vsaz1XiJXFxT1BBNHfDZZYXjpEQF8VhAFD6RUAeVRjQ1uv5nNRKgaOTqWvqviJFm4Q2+JbJCrVWy
yqlW8VONwUAt41s47IpQHLucgyqstfwHqLvhoEqK9KuRuVD7Fq6uVpB0YoiVAcCGr2sMlEmHSEaG
vUSoly1+3cK5CTFhfh6jeofDqWn6gAZVSr6QRuZRL4y9GoisTtqWQtqKQ0btXVcxxvI1B+PUbAA7
UGiltEqWA6ZHkn5ljRT7gAsqkzdKfBcKqFiz1BOTQdQlUNjDwEM19M5uWpFoK/MofoPniZYzymMb
A9ReDEK7uHVxOIHZJbpDdLgZY8dXk7hXLLhOnvuCprY2p/CEACh0i0YsKfSJ4Ix1bYcF2QrIrdux
5YJBJquStlx5BGO5LlyeIdxCwDn3HLGLYOFRyzkL+kF+rseYOoPJ2oCHcxW4Sx6C5KBCbfTHwF6n
eTexXpW/cLRNQpLAK2OeIF9Q9+oqaxYe2XNYFRObYWAdKnCKuVueF4S9K0U4ebipKxwOY4YYHKvY
HbEp6nAdUVXE58W8RVPSpT6nmN0PNbC1TnxKqp5TOB7Qws5qICcLFoIq6jCmbLer9RI0loIIFAVe
W4phjtolchSwZyd3hMWVKRlKEG0XbqD70UfxAE0Goxj9zqCuSFzb1FDM3hkrIidFXxO9tgmkCZRw
zmFWdQVfEpG22pd1v9S/D0fgj8TZnxCamU/FAFLsrfuISNOOcuEABAt8+IvSxXK9xnUA4RVZXwgL
T8hHRD4ghd0nTAXHMAYY3FWUsJajg52ArfMrTWjJydCGJN3pRETbAevKWCq5E7iB7CgVEUHQ5Pc9
KChejAffBLOgRQzOoW9On1PEgELTBkfHySwIUaOM5jNd65MYV8DB/wC8Slq5S6WpTAK5/MvyDp4r
7h4Wmz5uBczL9ysAFlvPEvsyoOG9/iEVqr61bnJcQDq5ruC70WXBktWnpLiVMR6gcIAKpQRmqgeK
lE4JlkRb7fM6pEsY1eRFg3fUpplUEPXAeWDRWLFrZf71xieYPQKquDVwVmcxa+II0MDxDQu0vpIy
mJd1lxIT0ItNXUEFD0iX6GQoVV/MqBeAeYCYFBSxz3NMZY2IeD3Eu2BN4f8AIZdAXxIoHv8AuDwd
70sA9ZIu2uZTPOuh6iBhb898/qEGhWnNbOKlKi1tH+UgGwnkgiOjHy0fES8CVzE15E2UBGCxpnLE
lJfVwhYSgWHOTk31caOQsDWqv1OYdep6AXzcVg4yogKPG4ypaZ7nQlJKXqfKUtOuhBdLeZLgs3Vo
XtjrYNdwBa1FgkuonW3LBRs4KMlTao6Wf/KjYvfXqHZ5souYCkS2VBx1E8TDwChqoB0CtDuTniVD
ohjgJbfEfWA5+oOApY+ZyloPjiZ/kX8JYtPhbENa/ERrebr7lzBeRioAHUcxBtkoLd7XzG0VqS/N
VKfXeqOpRZKtiAiQtRi+YZWCtSpA65O5boI4eahUSswqwcBXmChu00r5jRAF2afMVYIKprqGQOgn
LU1ILvpCGveMggbfqWiONnA6Afu4zxepxWRmNUleUcoXftGdNynvIw88DycxcWmbgMoSCvMS1Ckb
34h1XoUclFJx9whHl8oQN1fn3HY7wfPE2aBfE7H5lkt2MgPzBcgPtYhWauVriVD6YkqVAVaxzBuE
c/Eo6oBhzEWbfk4g67BHCvExo9vgepYw3R5fkiAb0tR4AJfBNgEFlKG7qlGGRhu7GY6lwNTp1LWe
OjxsUyU3DpyHpCwvDb7ineSPvIrmz0fzAFUH6LgnYarARdQG3zcWTruwRrt13KBtLp/45PEqtDak
0LlUcLauTB8FS4Cjg7iYWk1ULTmKLimrLilaw5l7fEaicCY4XUR4ZHYL2h9qNg6Ip0E033BhajSw
jigDhx6nJkRMV+YmTxacov50HqDUjdHjHEJblP1DyO4KDT4l2DqMAW916hF60o8VLSofoDCUcbwS
mEH54ZVQAsPDKJRQDuFgtRp0lxvYWBXg7i+i1AQiPA4dZHLXS08FSkUv4IQmUX8R1BQueZYHO4l1
Cm8xu1/KY+o/iNoR9QAJXPMShQpNlLmXwQrLpXEoW2+sXCu0AlSbFFZbmWYMJXBdVCnkoKZC0trp
qIGbiljxFpCzSDyBxZRfmBCCNEbuJVfNwWeDeSm6ediQ9qWOXYFInA9w4CtQmZOMhY0+OIgFUKrK
Gm1JxrjdeaV/UtVZUudVS2/ECnYpb+48amunxERrZXorn9wAigxUYpUr5Y64VgH3FsFrlwFRd9w0
jvualxWXGHX5Qty4i7HMCgMwF28lOFS1UD5hS7KxFIgHOSNXA/IoCmvED4RqC86uXsjQHXzEG4ou
DwQsacdCIm++QMMWG+TELrxsQHHm5RcOeLgQHFUBNBAPVS7Y1U/zMvDxRWygK7SP2lFTQ7fceiKt
D5ThREr9wLQUG+ismm4CDVhPRQD7f9hdwQT7djeLm1VbGe5YPVkP9WKrvEq1+JFk9qVK6X6iwuFy
gnKGChKPkzZQHR4mKFQOeyLV+VnR3H1cXSrPU1qaisBvMHoFYaVWF9RiG91YMalTTWx/cFQWJSLa
NqabhKklbd+YTvBWyilfcri8GXgHV3xVTi61I6rZuKd6f3LTCtGEoeK2+n/YNgAA+L2NokFD1ANr
QfBsQ53k8GSvlcsdRlgLPw8wBt1g9yo2Ybi/NzKDxHF3NToVWioAI5CmV3BuFb5lOVXsmIU1lL1Q
e4gr5RUK0SjhpqNi9HMSiuSUQCmwAqu4MbUXL9iuYCVNniDtlsxEaO7ChFbWJ1BFhjm5dQ5eIL4E
amsPu4fheTpdzqzO7gEot4NniU8e45Lgx8MYVa8y0IBOLh5CI5pjJcXdwp4Ur99ysFvdfEBgK9mw
TSsFfMao528RuSunUsobfnvEqmoha9RO0BhU5hFaN9hIFYUj2wLR0C4EKIC1B9ThAa9+pQBvn6JY
o7h0wj1Ra9orXOYPavJTAtY2a0rMpG+VFh8xYtXZ54i09U/dMD3D6SpTqluIjQpSsT5gqwfNwYaS
0LQlBAroKuAYFQt3yVULQPPmOmjF+9hYxpoPiViW4IdbEMq8kAEAwIoDk/dFss1xfHc8TDJ2E7HB
AcHRwx+JR3I29g5FoQ/uN7incmSaJHpxDQBpaMVA5xiKqJ/MDCqfDBWVRUopTUqwKIsFryljgI8b
Bpw8wn40Tv1Ces6l58yqEFaOzjuyKubtAB6QKwPDkJXnB6zyy+WWAqcDn3ESssN6mbyMgbHcor5H
bjANFC3/AFHZECjvNlGIWzx5hSQstLT7L/cB25a8IjnFThUMj0lFPGxr2j5KPEcZqYU+4JNYRcLB
8B8TFVdZwLmMmk4fREoa5CsjjqZS8Oo8Bh25Y8XeQA/JAU3VbUaiA+E0+C5UVJbWROXAUdkACxfZ
f+TnsH0ievEjzHXsp6kP22e2+IP9ZdpJdlebWywAC1FWtvGpKloJyULh5ug7lzvl8XLn8Y8FQLtB
0auHA8UfM1gCLyNoBbHRh6JHn0/5H3jLj8QiG4LefcdimrQ3JoxYYaCmvkiYVLAg7SGL3kCpoK8x
Koz5nkLiaFXssNO+oL8BfUTQ0EAbVZxcEQ6dxFk7zFtmiPIGk0RdYV0wLZY0udTDA57+7hAVVQvy
Is26jSvmPmUOoXAGJapfS7z94eN+KNCW4Fzd0ti+LfMprTVfEU0bqnh8ysrhkbO1QaveUX1UWAVq
LOEgL5cuYrYGoPNYZAN3gm8whEINOoU29t23ObAhbVCW1UKVyqq9VEOTBP3fEBUuRlI9Sthp83BY
FZsotrHzMMdYFS67HkYE5Bp5ZZ8sU1JkJcbLZ3HgjWC5G7/yXuWNF+Y8NBVnXmB3124rxHrl/mSc
jZNrVySpoWqgzNAj36hcDQOAOY1j21TESpnUFRdtzNIUV+JjuAOam+IWpQclySo08psKIf7H+wge
CjrygSLDXsNp5j75hvQZXbUSzIotpsWMK1OWRQ55f7LBQNDktEB7Orfma/hV3F4cERrj5gGre9QN
mlXglLt11BbXJZxp6mFmvUYAOYFnMZ82cS2i3a4+orgjtPEtEWWjWGwm6vyhqoaN59yjOAKVecfM
vgaNjAQtvuFEeG08xg8Msh1cUUPEsTSp7EGTQgeKl81K8MoU2Dlb+4MRTI1U5uGadNtBuv5jcFtD
hIXiRxediGUmX4EQMjzOiUYVVmWXKEUu19zCSK3l/MZBQU262eTpdOYsBti3TIoBLuO4s9sS8wl1
PL1LtreNhKCz+JTp55iFAn3G1VwQsrw+YQvL1N2KPMsEWHuUg8EtdcfUqwlfFwHgp8R0ipRtipcU
VhXMsXv8QrZt7E4L9QLVm8y4DnuNQ/pNRqn/APDBBPUdIaclABSvHco/hv6jGWlN+oJ0d1y+44gW
Vt1Km2L3zfMDSHl4gdDNF9oSbGwp/Ec3gor7ItJLTU9y9QZyeZW6Me0yDGlNHPiXjn/QgarKZ3DB
per4gVAQfLUeCndd3Lyi8qMCwVFYpyczHZ4NcVHDovddVCSUcLcNS8Qmhdp4gEaiGcRBGf0Tngq9
cQLmlquY4dk2qw5gcnLjSMUTIQCqzxFU9hKxxN7jwTCi+fcHEtXAdHmEfcDkb4qdfDVUunYvcsUy
/R4hcYpsu16hUYN0PxB1iN0eyEMBCrUAqW6vuXC0KGClrQTiJ2xKXyRFjXAy/r5TgXZ4lqOXELwd
MOyBUcLVHmHiBZdRreNoYxAFC1cszrY1QQ1ZKYNY/BYk2iRUTmVwVrxCI6gdpWLdtIWLRzGx0qIh
cn7gKWG2DHUNQTMvbR5OkJpdT0RafQqYf6xXxKcmuUuMamTh3KqobfmCLtLVeIY+hgw0cXQSpV2M
rwRVGtqC7cnU7zXzFptjqaCmROA7tZd7e5zcHEHlGvEIaQaPMVSiKt9w+KqDMiDAPM5gegXxKJNp
UEQGB7QhrWuhK7olLtiYMsB1Nyo4DSxAHB4jddrxG45byD1aReXxFOqxUlmQaos0XxLO9k4uU9oW
TWXWV02Ra4u54eIn00VqIpnCuTbUtIbwxlLcpvgiXc7xYSlE1VdE77QfMVSuNlCY5TIst6iVaxzG
jabxGLabuUB5Zzce3V8SigBbA1pRpaEHGgjr9MskhWcBXMFEU6Hwf7CfynFUshvAN/E2wj7eoBAt
aVGiWVKnuEwrts9VAol3ES9hcBqLY9nicWdroIV6kYwrmUJAOXZoJBS/wlg+VkTuPmEaXkVd0x4r
iWuDSW/zHD3Svcc3jFDzFArvJnzLyjTz8SkrC1cktXas/aG1JYsu2Kbjby8RscE0pe+OoithYeZS
p5emD0BfqJNTWhLKcuCAotaYv1AqtFLX8CLD4UFrWQcL3IV+4MrYo9VCUNZS5hnw+4fcJJHValk7
3iUKy98wx5bA0AONiI0cWVXhcgT0ikT98Sqs89EtLBKau/5OtR5VNbOc28x4CAZ4i+OLLSmL7a7D
1F2mw8mA/bhVeFxi5onDiLFqX5iQbc9SgeL9xAGhlmlRDXXiKVYPiXBQNguL4IRPwlvpXRvzCtJg
btcXCFaYONxUHdK1wjDYtlKuNsQLot3GSptjfU3nZVuDl+AmBCJK28sNV5dY1lYibLlzFR+ECWO7
LvmNYgVdav4ldoDGx46lFtHUpcd5STwIQquwu9nPNhy2VlFQPJ4h3MvbxHdmonZb6hnm7j+p4/8A
ENkauqPaVYN4y3CVcYwwvKwUrj1ESIA5cA+TmLgGVp1f4ghRz4hvEIilj7RBVBHxjbdbUy1d+JYF
DbfMQRw7Ivx3AJTa7lLHYhNA2vMCigvUGjnqBT/MsE36hYwfaCspg55YQMOOpagrCb4RpIDCO1CO
91URixXEe3yOYgUwBXsCo0bkzo9n0uMGVgbPubU+a8ywrRsGhmSROlLi1rbBLH8RWop6YkV6aPl7
iiaXtHYTjyS3qXHqo/tGKlbHaQ4uzhOpeC86wRRjx8wSDz3LaZ57g8TeX4gEYE1D+48QTe+f3Gbo
37QcjgcgQy2KKA/uUR77DyyoaFcVFs5Szq5cWD2txRAbXma/PMQk89zvPshh6a58xyj1OyK6i1L7
gQdtkw5nfb5lvOnwl2Ck1blUoVgLUPkQ16I21VcLMI5FBNAb1qHi22VcTRs3KtMNvJ7mqzPcrwhG
Vdcw6IfuaqKTlI8IUlxVEscxvmDDcK0W33ouMAUu4fEe1sNocW7RjW+Srl7cdxdCn2mmWQXtawKF
8wKrMOpfBodQxKG4UM3V2euZenvmPjY9xSJ2Bd+YnE17m3Np1NDBxbKME51/EYWVZRWOI21MwLGC
2dyeZ8xAdlBO3uLaUVNaph4mqVfuGqOfMyGDBsK5OZpD35iXimQkIBSrgiAQcrgjaWyw5Z+uSFMX
fCnH1E5zcaqX2i7yp/mQYbR6jeOK7jSPEddUiIiuupqtDk0gYJ5a2vzLcEt2g2ULYRSJurjH7x1b
GexVRykPKv1L10wvmbGLzsWLjfJzM4woPWUwicqdjhNKUnGMpCbUbNwnRsrWwtiq1p7nKYwHR+Yl
lihuzZft0p3DIxGh6+pYxwu1yOOBQj1c730Un9zCKGN0epnY6IkVPmvuXCFGHaD2QWcqXEEQHyTm
pHupQJV3fEyDlriU4FTBbYk1s1TKTLv1BDunZFLjEEjqpjO1seoaUB74iNbplWaiO95YAPJeC5aS
WPwMCXomt/1LgLMtobXuXFKr5gPl6mG5FtQbXMIwoncYHt7Yq6AnISCPEPHnKR495kqGq3zEbsvz
cOxgMzINFZxzKaCwiWwyFH/YqCzZd38RMFPqb5CVUdSmlico+iLouSuruCEtZ2vEsWh8wmwwHmu4
hbrJaatzUIdqaFpvmALVcSrBMKeDzPIa9QDhwNlWAcZQ4isiSuU8yl8bcauzmoJ0VXEU0xgDV3z5
iAB8jIhQqLzlOmzAK+TzM9YRWHviCCkKgIK5GGmueYL0sIXKHPcYXZvUHhWdRPV61/8AnUaL9LiA
oA6HiUk2NTZ3vpnBEPbFN3vki2Nue41yt/MK2JUoOWTkdPzElH2kANrxLgUSwirpiAcQPA6iQLYc
tx9QGKu8JUorPcVDXDUQaePUpRp+ZQEC/Uu1U/EvK8IKVewi0GlajRZTY/aIdDt8QVSWcbBZ7GVn
Kng2LWQsir9dSw9GQQTe0+b8QB8TzKXqnol4dAtuBZCFqIzZ8wvyY4uouAhaH8RdergC9Jd0B1XM
Ro0lkOoibV4ha7F26fMK0p5HEbxXjqo5ApwS5ahb4nfRV4QA1gyoUgRqsOYZqB3GNWxlIjSKm8gc
0C+GGXU5vKKsA2NKK5Y8xQ7nL1Ps+4gUB6e44Fsu+OIqAveIqzjhlQBYy+bA6HmKtfyQQRdxAItj
0n2sRcEHmMA4jdKR9xCoDVyHSDyJXbHO49ncKqXnubKeJzDiX3ab0SgLszC/ZMjnWREDjJaAdTu5
yzO4TvFVt1MuOpJfmDBFL9oqT7EXuh4jWqbfEwnbmpaocwuWB+ciGjsUVeJe9PcpRbLN1UaMRBAt
Sp8iCbcjgiU8wSuSFKbpNDyvHmVjEHJY+EEyiHmqm1Lr5l1tIq6PE8jX3Gt9Wy9BweGMLlxD6rYi
AiWmq55hpdojU8s1vU1XCAnsSl3voiqx+YKlpCnLEgl14jXbRLQEX8wmtVlSztTm4+porKgKjklP
X5PFQSc1pZ6ldemlcQTY1Mlc91itbDaiOSZENUqJHUrtSckqjXoDY58nF+ZcmqhAEbSqBr1DRMYn
XmGC2V6Rva/AFv2zSqE3/I3Vrj4l5N4a3HBWYjblo0FVBNgfCEUimmAXmaRQjSmofpOWmVBtYahz
kteBKDq6jgS7vm8zaOsFNIoBHxxKyrT2+bhqx2KnPUtMp0dVOkghOIRid6HuGpJNhpMQk4AQo0YW
OWmuA9Wb7+pRB9o85jh4+YcWDVFRHKqjSzJtPwXR6lsCBVc0gKmkHNLbrzGpqfH8wQX07WhO3Cnx
ljFtgn6hk7QPb/UrPAvWMYyx7/8AepviYVHmcsZwv4TKgKnQ+4/ZnbAuh8MFpSMwideTKhcNZXNX
2mKAbKaO2TiYEcwUHXmD6Ny28jFwVRy3zLlXz1UJqtfzMDf7lCylQpqy427G92VCowdjL52KdIsr
ojFVfqIOwg2W6uBX25YAMYgL18Rul2LksLHGIprfMtfZ4gXQVfZCPMPEsrRYPcJYhSQGlq5cQ4Y8
23BDYiiGFQcZRxZLCnPuHoX7iRsCWFYW4mR5uLG/DqDZ+RLO/DYIK+Yhvj4ls3caWDOqljVcSi3m
vE3rGUK4VkUHG+SFVrSzCm+YAf5RcDDuo20EquWDePkiFVr5ioCV7hLVRbs7aqWw7cAovMSo6lmt
WeYkeOpTd/cTtpKoTTleIIrCncJgokS/PbBbSjZWHzzAU4N9wD4Vsbf5Jeroe1gDJSQuqPwYCoru
4AmQXZKBgEnLiLRhASYEx7l6mR7Mrf8A8GntJW+ZV0vlNhdyoKKGEg1IZpKQeEvI6F6gXB0HSB0U
NDtrmCsxfjmPrUCjlnEUibt8DqBrTp5h0lZ9oNRV6TDO1WXYKthqwJFNUHMuri+zUUHRQnMqPYuE
UGxmkJd8w6NL4viWky57KmSNWgSoOG2kQzKu+bm50vqEVBXJM0DyEEgi6hFRtt14mMN9sbiA4hq7
7nAt1NoCn9Ru/pmSlnctQWUZjmJDsODnZTaLsefbG6DpRxKFburYKvEx6l40ku2Vpo3SJGVTDNib
IDxH076jQN7F7Ng0C46hohVQAW+SAEvhzEApCW5g+Yn1OH1Mx7uYh6dl8cRujmIQlWOlxJUByDca
IHgZdbfwnusX3KwycjBaahbRtg7n6i69rlTiXAoaMrvxgGOgNBSUVKNMBXGzzGWUF4lR4ZeB2QMy
BZF9CqTX1CjmnHUKKFFMUSxbhawMVKE55BFQF+oyKe45ImtIZYnZkz3HjaMqsgSyBzr/AFHO89RA
K5gxRxlxRDWYcFYCOSg45THihLQRmuqe0KKqpzhVYBsHcV0yJfBiEvDHx78R8u8gg+qqlXEOgcAE
/wBim/5hPEeTUMXeKzZa6RfYMo2QC/Nx20Gvz1HR0Ku6GICK4oBxRXZvcAUVoPjJUwJypqGLS5+w
EGILYaODzANCOSU/BeggAfgxoZW0AOTm57VjLUWjHOkyoJTldzxPB5P9h6IV2UsCITk6TNXVE4Iw
O4ODcY0sZ5QkwRQAeoBgG5+WMmuI8FRKwodjCLhUBriOghZVdGROcG13Rr9SoQG1Ogh3EWSLvYqi
WBS0JRCsTt13EwqRtZ5m07kW179xJDFvUviUtUVVWtQTdxeh/wCIFQCtK2olmajTmDLKmjLzzi1r
kPbW0+O5mpOmkVcGC/GN8obWc8oYVVSqxdSjO01Xdb/MUZgYtPhKDW5TYZdfg7LtPzKK1BVS8xix
iCryaXhVUwsWV0ypQNZTRIUaq7jao1BUjyyF04DIi6PU0sHmWFpcLRS4ziKy8buoW8pb2JkQjKil
b1koGgkQXN/ETdriJSyIohSbO8aoibfwnEQ16i0Pc0NVwiRaNxUZMW4NlwTnl7gIJNJXPuOKUeoi
yqpVQvIu+YmwoGUc1eYFMtMTNOvcWoVb76gm9l3FgouKGu4mgYmy57Hm4ILtC7MYQK5GI3fMXim8
RQ0tdxNxkE1SOz0IqL7jB4MdD8okGUepQ23ZhCCVKnH7jKLfxG4W5LNRYZxLpGKHEeTE6hYVVbxL
m1tDiFDwSItv2RaSsFrAlwI8ioYctyMjwfc3DjxEvS9zEdtJQcVXuUtrq5QKO4gErYW40hikKpLJ
U44BmrIKS4At8eJyhjC1NYQSXWvMA245fcD+RHR2JcVSfEupeVPdKKnxsCeSumLn+WEnMGrO4Y0K
AfIwLNID4lVvS11ERJqp9zLCBV6j/JBSjuVzVT4IxCBAD2QXOeD5gawWj6grtqj3OOLc5ivU2zqG
AAC2oUBT+kIohFr3UWIA5ajHUNuHMYqdDWkyyoNcQVkDmMgQO4Jkt2WVfPzKF6ButlohblNlcAN1
VFQlcGzlK2iy1xAJcfAla2WnEoWLfzDlF57jXHJjFI7L2GWF61WjEqKrmufqVJDYjm5ZM/HAN0N8
lwIqMSudi4IVRUMA1eqIoCHAfMc8dGkNir5kW6BdMVLpVlXWx3QkB+IKawt+Zw5OIdZzAKCwGaAW
/mHBEoqioNTyn2VD/CICtZzVrMOZWjQ32RZEBVj8phYNjxcvNWgA5Ir4DLJXplupjj+fmKTGrhBs
U9RbomS9weJVmZwEHap5WDeoMBAB5pa6Mi3dXGtFOFirixV91KOwcb5lNUCrxDTNw31D0GJx+I1y
1lHMbBzCqBGqvmEnzdvGxVeqGayx2mtvMRjnKMEiToOWXy2piIozsgBWzdRw4dvJIWErsFMDaKLm
MOx6gJAhDxLGcYfIU/UEWPK39zfuIPxArT1XCEQWONqpbU6oLRcpjiaJE/qX/wAlDKIwiw53MaXG
2HbKTCy3iAW7muHUFwWNckRSVQOxnF4UzxOfp7dwCoEHxYBKKo5kO+fzyQh6py1TEmoso+K4mBsu
B5i1tLrqg2Lurc8PuW0LDpgAzS5rlpYAlMqAS3qmD+qJfW8zNDXDEZl0SwqyUHTyKHzFoaasdjVq
FrIAvT+zzBXFln4V9w7IIu9ROBpGiS5ge/iUIawOvUIUWwfNxBrsAPFWQuLV+NlDlBLqOZBZOfUW
6T5isaFPqDOXWdxlNcB8R4rLHyX1Ebrr+pfRVJT14lhr0x6WFhpWflFX3AO3f6lf97EMt4igl/Bq
8xOulFFp5gUADjqWkoUH1IcF2DYwkblo8PmI3AwXw3ByEI+5UAA+HHUsy1bgUOruJLenqFdAVME8
ygna+YkVnMq0MSVO9fBFDpTkXp+IoBxcbs4EFC61PrGVRyCvcDzKkDZbQi+poFUxbGEAa4l7cU1B
o6GWd16lLd34iQAfbFHixjiQsqg10uu5ZeAiANfMu7/xKtZkG708s5x3kLr7eY4sePMqlQp3LREX
4q24KFU+Y1S2pWxxtyzE5+qhUg9ykFkyUqWyBVs/MA1S4U00EdEOKGIFDsCW6bYs3WQzOUd6Oxuh
C8hUEAQIlHHzUSjQW4XDNZmrTupiOeI2c33EqGrsWKtXGr7nE/xkF0eqhfSDQFkQZRSXDha2NRNe
IWbe5Za3fMBRSuoLRTDX3Gii+pZzzzUs7LOo8BzBiBDXjqWHw6iLF42UYR/tNUAHVR0sMYKgYLGw
HI8Qe5dJs2PzEUFlxBjXJSCXdS0AVrd+Zh9VnMC7B89RrLwt9yoXLoPUSx4I+ow6itxqpgpFVAEs
1IAhUNpbMMCEdfqEGbsLzANs36VOwhgPmPl7rbyiL+aAnNS1MFuULz3LCsv6MlHsWL1XuUXbqqoQ
k8xKvgW51OoqSltM69wYsijPMtaRwXmoPtvwKl2ZEWzf3FXdVQ7A6tKDsjF9hPEC1FuZYFquzuOt
uu5gHiYkjhh3pSVbqKDu27bA319f76gDZavjYlGhVl8ZOFwthOZtQI25felaYIdVovUQd/Txis0C
n0gzocIbkvXwsq4sL0XhsytbpYL5HSK8vbDvNO5yAuFB4uGeVNq9FwDLwnMxe3trX7hJpW0dR7z8
6zI2hbV8bOOnd8EDKAEZBGMtUBSqO/cavwNvudBi2b+Y7yOlNLlv2lj7gSTgR6U0pbCWVlauOhbc
upOfMThSDeCPBE+2DdnNE0e6yMcxEPHuda1F4qXEKZ4QJDH0LO5epYNF+oHxKh4dmGhAW+Y1QaI+
YAMq2ocrUF2ysdR+NdQUvmPKhbzzLBbtZ4jsolw6ICY1yOEp0xguHw8zmTi6KapB5S3BqBYOp6s5
hm6ZnCRWdFWeu4GHkXQueM5O4PnU5Opg8Wg2J0hOeGVshKPUKwX1DkWtW+5SdiAfEVQVdHs8xiMD
ly9ENgib3dRm7mz0wBCluIxDkFUHmASgpErJaATys4RBUrrOIEkb4gXzLWlBL7KlB8aHFMN2n1qG
H1uvPiXgqAezuVGVimuYgGAWVazKR2s4mlQaYIinkgCLp2v46jqF4I9wK7NB+4yiVrXD4hZztANU
Mo2SosDwnH4x+peMtKrgvIS81X0wx46GLfMPyTYDnJ1NM+JfN7J5EhXkndcIGqruIgj5WH4QQfB6
gtV+sNVLOlHMZeqRL5YVihSbbiKKRSjadm91ScygRFHkRmEA/LmCtUL8ZEBkZz3VfzFsppbj2+Y7
FqW/cN/uoHtZhQ+LmxWVami1UcvQiKc1UR+s7JZcJf4IG8c5lHyThiyHnzCB3d2xETai34qsnCBc
A1WwUBVdwW3kiNmzyddxCp+oyu8Eeqwh7r6leDLeIhotgx7hS/QiIDxEUOoGgJfcsKpvuFj+Yhxi
WnKUAl0RQ5oQ1nJBSZScR5LywU5r1AKTRAqC3ti1GeWXYmXUsomnhgUBj6i4HEaWC84iq3VSrFRY
U17nEhAmXEAictsiKVktKKfucg0rkopTRiiv9Rs1ww5Vx5gtjibdrjTXM1ICngkHMm4mwlHJBIHA
dQZvE+FgEjso/JAbDX3C7JaVGvePUpR1KwJqzg8HTEoCx78PEFc9zTLqF2Gx18X3EcmuI/yROl+p
bwFe5qJzFzMmQ5nTXXEVjyMMg29mId+43Igi003BfeLLB268y/qFaNPAdxGmj46nowPEQCmOMC+A
L8/uMYKXbr6gOlMsjFTKX5jUDwD4rmUagOu5zabx/iUQBshtESMFw9wcgpa1aSxxYWfENjdqFh3v
2b9xCkgvks2VB8GwEK404WolSjWnhgcMix8wAoC+HiIgqqOwQnQpR4lxwKsyrEMfuAZDo2hg8TTc
Hb8SsBGyA1UDBxh+44xgr+5Q2QVfTcBAOAeaCMKtV8xsePMogHJfiUuKy8/MvVLkYGnupsJ2nMeb
6h2StW6xJqLu4Hhhwsv3AqPTS/3H+gi0JlE196meB0Osp2twSI6OYUuF1t0MjYY1yANdgVc1LRNu
tQng8xEVlABE7RuwmDBUij5VnJ+Jxmk8t2WC1E26jolq2oLYBrbzHTcJouqlZq29jQny8hb4husG
Llf/AIAUZReWgIvefzJXxwFV5ilZtskMrAdRVVbFtacly0thMRVnuOcBk8zlG7d7Lej75ZXDKE+Y
YeLryAt1sb9w/JjV+th5Y5+L8zT2VNpFUC/iC/FxTqPxByr6qN+Ba+UdtbdRnUxgtQtVlHgQQhLj
io9lB4qEKQWvUIbQFsSvbDhXaXdfcHLSiC3QYK6h+66X1GRudJ1LwinI8znqs41ERFnpSzOgb3NZ
MCPhLTDurkAtHVb3N3nERM+Y96v0k8NIrmidQwHzAJlK3WZA30AX3BtYjKCsNiGy/i2g0ayIyPAv
xDwNFDsvVUtQupduAoXUOgcdCw9urbFekhScO0LluodgPzKkqDdAhvlqGKFFLhW+0xwNWBKCwpp5
gSXZHBXEf9BKeHc7WuC19TEBQPEBv8L09wBKpo/zHgqPCXbLxNNKHK7hFbVrysgtuOg38epVEqBl
CoBJwFdkCXtDtUQjaUm9S8HSD3p6gURpSGCrSwdmqzrAIquQswAiBXEcZuu2quK9zUhBXm2DA4JY
p+5XO6ADcSGwCNwvtW2e7newCLg1UxTdNR0R217mJqBC4vJwDshVwFHdwVaqPcXgcYENsiRwTfmW
NEp/U0AWVLrfpi1YQy5WT9wQ25LtZ9ylFazuaXR8wVDpIVaxtyXuF7FtwQ4TqHId5hpvOEQU/qVD
xFKxRrssNBDqM8L6pZVtiKDCu4GunuCdgeIxvwonD/UqEKV8zCxMlAHc4A23zBu98y5oXECwpgUn
iJYWniVV3AfcscW/EdDzXcOQ7gQvLAeKGWFVKT4J4Yhdl2TwfELHx7iYNeINYnHbHCmlyqyy5bCN
FyzVNx217MUj1VEPqJDAC5dLqoiCdwCnnIFLS34l0UaRDeE3BkCgmMHw4hDbQ2o2jDuW1BfUR2qz
iFq+SDTsgA9vU0PiFgDb6jWByQ5VBRMuPlyPUUA0y+CIYjtZXPmULINJcT2eJ0LS7phGPR2GrXkN
PlGtVx6l3oy4o7oMVC71Up/8ypqs8+IaWWrtni+kK9iy3TkgxQRoag6gQVrKnPkgdi+fmPOaQ9q0
gG7S++Y0lSPlG4tnM/xUFIP5wsU1VOpcuFu23N5VS3sbcVoczkKb8IgeUUuw7LK4g06b5gpbLJxR
zcAQysF48tnf5l0J2se1CAUBo7PEHhdsTwQxSMCsPiaiXer+5cR3LQS0RF1E2g6l+0XUwFPE4r5X
xKkN6iSgXFF/UpTwDIfUa1Gx/wCkXDplUXH3unuUyqnCgsU5XqKK54Lce6m7ukeAq8PUgxmXNUSl
XHBdlNYXBQyUaG2DFMUHhfcrhVVUNkSW49xQDIBmhG2CnOwI6D6jsMXwQUUAgLESLCqW7l7aGwvm
VUxOi6gukvDBjWPcaPcrofiIknx0/E4AGg+e5YA623CBqDxEF/qBjUVSpgDgtm8Tjod8v7hPyFl9
TbFcp7i1emBRFLs91LBSNmThBcxLCXLyScQcsHPmJDLAW4E3A+eRLwrY5cSMbFUffEYCwtyI927u
2Alv2gM3DS5Ha76Smunu4iZPdxSpRcgsAOI4ghuUt2RiwFtfMtTziD+uRtQ/MBBR3R/cu5vEVzma
WiWGVRdj0+ZzPb5KqMhywUSzHdiHQ+7i0ezeYLT9Vi7E+blvJZ1cIehUWg1XAgYiXyNh5FLK7gmY
UUyNl8Bw/cVXuoxfy0z9xgnxeE52TtnoLCF0qnLtxIvcs6QZwffkhuwlKH8xcKbFsuNYXNrzEp2U
0fiAIAeaTXnX5VFiiwlU1U26iD8eQ1EQ22szyKFuoWKJVuRHXnG28kDl6sRqo7QPTgJfCi7NuIgP
geZ36MCn9ym7eR1E0dHW24/5eNUQlGoXcqKn1BLO7W/hAK3s5NVEZerat9yoGV6YJYnXhYxWiNWS
FIrvEvGmWc+oLwhiObD1xbYZr9CURsAcPuoll5BnNrVirad5T1C6ujtxLej6JngumlC9Qngj68b7
IM5g/MrGw7QuMNZ8kamc8EqlVPiCRB48NQAEsFAd1zBy7K8agwE661UNUUnTHcFsoloReTqJob3c
AOcpC5a7xKM6dwvNN5cCSfAsmqibio8FRLcsgFFsncu7pDxHxtehbBoZ8oghKPU5QPQmxB48pbpy
6sdysdt/mXd56JmlSxTJSCLr3AtKVUCa1ggvZZs0xG9sEajcq1KbQA3UDDLwEbhk8Q/B7lSC9Qug
sBLjlIv1fMLKtLr5goQ+YP8AoDN1VVIRWvcVwihT8F4lrM8EUy+K3CwLkFVGxHyPECETs7jGwOQV
K0WWZDeUUARFemNxRgq6lENdFUGvk9yP0R7OEGFFHTB12UVDUQwXDFiQPBhlO6yJlty+dStMnn1E
mnRhHyRgHbL6inRcfBBqpFZymDltPEG5L2E9O4QbcrxG44aZOHVtSUZ7cXFILXhsTd05SL21uTxD
X3TiMgJRUeJ4gWwoY18kd+Inxu4W6auvM9EPbIu2uoKGK77YVGx3HEEbxuArgyzcS6lts7BLYrcC
inmF7Q5riadp4WcB7o1GkQ8hUOvXpLnLEdcmUFVU15lgg7MtdXYdR5RfWoNdb1EKBHLeyntMVdCz
3ABTl7uJCm3pY0AIEoDL9wEGg5fM1BfTKjCL52YlfiCE18XCqzxENCj1bML09wy/hDrrKqIQLuy5
8z4EoJi+Y7iEMe5XVD+I9oeCBUT5hELx3CiSdjASE8w0hXgZRsr4DiBstq6yN4AvexjwuKS827Vi
EgApZHwNhtJaz9JYFXKGhVPMvhOSVATZbqHuZT0tQ7lhKumoUb7SELXiFHEHauw7lMryVEhJpxXM
ZhnJGGInUt0R4agihQ8uoqEsGEVBQHbBtHYVMuSce5kUDRhMAPJNqb+osqCn8hTknABEXEa2yeJl
23QVzASi0KqXgQNoeY8NL0IZPGTb6lNEC0cHInuTlVkoA5ieEdxdTXUXsG6SZ8ebTEcUjUDD8gg0
EGogCk8xVC6uAgKG0783BgoYK6i2FY6Ixzli6lARDmIhDs8xZ+I24EGQKEoXLHU7ehOzchXCPSMG
FPwZFHrylxCK96qDXriBCGo9eiFbKLEi9ISriKLe/TDEiX9wXUBhBRVDAaYLDuA3i9GwUeYt0e4S
6E8/mIFdGBgy8mj4iDe0eYpUynicyzfPqCryLzEkcJxAnTZ5ltRkAg8PXzKqFDYTtidphtRURVRK
M5gOK9XiC48lcUYAEuxlXBqve4YYehZQXGBB0zmdwovbmHSaztNaEbApW8+oCVKmXLrhIEREN6g5
ljUeR/MYANg41B/TescwcWLQWxNjFB39Q1veqgahsp4gqZWMUeY01V2mRdZOSj/MGlDxYX4hmqTH
EopQbKA9zUExg7+YAJUp5kOHdyIC8ma1C0SlKeOmVjrc9fE0IOByEmagbbxsFPyPjmMX4ovIxa5O
I1+Iz1Vx4jjANKHOwXgxQwcf7labJQsUhgoYZC9Ko1L/ADLbBzzcEc574IctUIhhU4CiALb+ZT4w
PiKlAILeGJzKLm6aZbzHR7iBKbqHjI6QjyDiZK1VNurlm9yDK9Rzq3Wf5jMQ+Ql0ajhyPV+BzvIn
UFEnMsR5g15vLjcViY45auoWFMf4hIKLWkeh/MTyjoV9wmqLlOTJt4gDyy/KWilB8ncrKVW35l1Q
HcAyPpuCjoPMqF7rom7VinpE6sWoRnZFq4pVZUy5cmFQBF2r4xScBVcd3A9vgKOS9uqoBgFCXHRU
t9sqc8QsFsddVCDYDkDsietQKdTA4qP7QU9c+4nBQJwdMDjaKDYqPd5UBPnUsGE4IvnGwe4ZI4gM
dUfB4lP3WCOIXeD8vE2aCiOGUiopVZAOCiFyw28jchqquABGDuLVf4uMUHw7A/7FoNc1etiUSXrB
QEVtQK7gEZ1NlXAXeC5enX5l98Vc1Of5moUCUUpgLFKHFncK8EX1OaYUlVK4SMOheSwoGzuABS31
ExfMqaaPMuIC/NwVR3eIDg4dT3QASvNeINZdGQGp6gbK5NhdqA+YgoNf0w4oxY9+YNYQ7wt8w7AV
QZ9R0too45tjSoAv0yAg+JXkuXidniZwmvlC0DUHatMoiWuj1GbSKLXMq/XT/GCIHkv+pVKEfecZ
JuvUZHCRbForgTDzEoafbFSCq4i0F/cKbv1AiKvFxUR4JanAO4vxnMdEMNbYMyOrUNakNlSb6ixg
TQ7ln0osOQtaBZXNo97TaoqIC7Yp6mMXApzsABgL7Ra6rviFso0AI4daLZxAd1mmlR2qocFwanis
fzDrKePlqB8BOQlYO2YMiNCYkNzMKbIx2a8H4l3tpZUdhHHDmX7WG8RYWC5mVNwyyl3XqVrTrOK4
hy5FkpZJAX5ToChQixFCsPBKwAtGbfiMlWcGS0ICzwuCwLMghbygqMhtRREK0NlkBJ14TfDbscNy
i7cNM4iGrpQNL+YB0rQ9SxzTiX8xolgo2pUKvAOolOL8mR0EAcG5GgBrkeESGcPhBXAKYdTPLoQg
otj3BMKqBLvxCW8VEUOvMsdMDErgNDzLju3BfEuZZ/JyylnYRWXWwS7NBQfScnheNiCghYEBpMsn
DeROuJ8CAVTt9XLywdB4h4MYVxHKlNDLuGGDV8UhtvNConKhHYLlDCzZZmSjy9wwAqtPxHW+eBtd
XCi2saDmAHlG6gaeYTn1DMDpNortpxahpZGDyqF24CvWo0MD6oiwg0CHBew8+bHmBiFP2ncHmqG3
4irZLTgQTJUu+G84hAXd749xTBMTuHLHx18zC1KhdS8gNPUPgSGjj5lSQCws1ih3gHBHyVN/dc/x
FNJxDV4qIs/3dXz+JTTRFWv/AJj+paAr5MsDQ05L4PcTKIvmq+ZTYCKrQ4GKyDYcJww23txeP+wQ
5VA8eYg3LwuVhUcM3PUp8bMYPQ5g3+y9+quOFriaxYeOIFyuo6DBDt7jTygDl7iL0XX8kBk7aPAy
rAAOZXtSwkUE03qAxtAeJV1vcVK5KileMlQi7lUHuGuYA8tVFJLOnPESqHL7/lGjSmljsNfBRO5u
DA051/yIP5QzJaqCQdzLSNC89w7dWy4xYDMhV0vUGlGB9y75wbXEtGRTh4S1Vi9+IDrba9ajs3WC
nggnkEAbPzUQwM2U9xtvw8vmPHg23HuLHV4qABejISWsDoz/ALKoRRq/mIqHKPmH8YMriEVANi19
QDIAnvxD0KkcNQZeqHnI+Gxg+ruI6Nlp8Tf+lBabzXmaWANuSAYS33YQChVW+YBdLDdvP/YWcfj0
iyTiKoCzuCku25plcYbnnZeDAW/h+JUSgwbwXBti0F+CIKS9jWpEBE1adQCKuA9QiEqCdP8A8RBb
Y1lPdQVCqAcxHK1vkrmMw+pTXsjvqHwHuEcuRzqF167JtLgMBye/CcfcQuDJGlrpsmNjr7Cuf3Dl
rQfCBwBCdDqMWXqecv6uc5KtBuxvTe9DG1WCX8EOTceUjPiD6jsDLVsDxDyXcFDauwjIbeO1Yx/1
rM+YY6FmA3FXXLZ+plFO1dKfEU3cc6iYwl53MDxUs6DI4hSCgUgC/UPoEJhr1FnlJ5YVC8GhVFUi
+yuWU7czINwerj6Ty5V0qFjsAT3rNsKO3mjAooKzhWoqgnXI4QaWkVL9VKYnk10Of1AEIBpxLLqF
ipsHi2v4iopu4kebfEGlOJxDapitDWF4QlvBK0BQ7HqNQurzXmJqyWm7u4mLX0PLAJIChzRsbxJZ
OytJiO2W9wSambKtLmtEvxjSZcUot+IsFlnfmIG7+iIju7PUBItzY4AnKBzH+8B25E5dNeMtSqBX
e/8AYQ2Ruw5IC4Nfcdar7iKn6YfC25yUog0iSvHmWtKBGizhc1Q1XEtFLhi8IxZ6yUKQdFdxV1eR
hFUD0yaSq3xDkKbL2pS8E4G/MbAuZrSy6wiKhY1+Zihdn3CRTQlMmWpc9kBRff8A7HfeZ8kSAK28
Nj5MNn1E9ou066uADIwdV5hG55Xm/EKqpwPJBzew9wZ3hfKEkFZYiRwIUGMI9Rg8sCVAFRLwltm0
xqoejSx7lHLaKS8jS/SLjFK+yUyNCWQTtrnzGOhp7RYd1fEqTpoSOc3kQyRiZDdajJVlAKQdqG2m
AQC3T7l50oglQBZ1A8E2ksJrxLcqR/qYTYXBwwnapv0vYkCU+4RGOW6+oC1bRXipW/BZTsnLPrmO
iKVkUxYvqJKeYHEahUCYF9n3EJG1LeiopMSEMBbsS3fmNaWK0dBLExttO4GVurhZL3ZxVRdBQtOy
omO1y+CYiPN8hCNdMMbG6D3KGKp7MIpCydGU9BQHSLo6FwelvBPicL4g91KZPYCX9EBD1ExYWXfi
JzaJcXHaA5jqH6xUDhjQEkGZy9wrzAsY2H3FPDSDu5w2BFPUJWuDDnsirq6qX/VVc7NLBx6QBWmF
MYZDbETT8pMyaAdVAZQgRVrtha0TaF4jk4qkXS4YVVVTBU3m6xIDhYU+W6mU8J0vmUIWiRhsq/lB
9MPRxW3uVDAzfNwReS+rhIvgPexjD+AhiMyeDIyEU2eiv+zuC+oPz4uYNxMtj35vKHCFBs6gVG9W
s5ioy4KeWZAQIrtL0CxnucHZ4bkQlM0HDXMUSilPEYZeA5KvTDfiEyml9BCli7R5YkXnfZVcI1jK
c6x6uvKjn6h5oFq8xiE2jx5hxMBnmWhm0W5UjZ55jEDQeLYGCsD4GEoRFP5lxoqPuNpcYJvosfJx
Azo1rxuy1Oy0OpWKNB4L2d4CHUC1UqtxgwU9pVyomBUYRH6AUFoYxQVUjfcF8I8HTB/eB8vDD7Qo
rw1/kP8AmCNt3BXpCeYcU035EKOo6KPtsuSsbV2811HAAAb8QlxcMCWqIHhn/JZTlL78/uIxhbpj
FHMwp2ywDbU84xiiu1cXiRdUATsi3Qpg9tkpi3v6l6+46fNy+IrchsRcKb4zaL687BwBankgMWlD
r1FQMUUt4OI4KuB6Im1UFrT3AS2qvGQ6uFoMojozucuICJL0/EqzQE8/L8xC3gPB2aK6FWun+wUq
2RHXUprOI4cpjqUZuJFZl5DtWAHRUArsAU7bIj2gHnjFlJQrR8P+yrvtZJzyml8W8fzB3E1cbKfD
Pi6RTagCbfmuNp/+ylw7X6lHAG5uqlA6CHVMHKtac65Ki0gfcjUbf/xGixUl+OoYgMoUGxI0PIdD
BYo97l8Vct+WD/cRa3pw3biLGgp4U1D2YeZbtAt48DuhCvI4rfHMCBr4cn8xxyhPmkSiVOoig39x
LzRs86e7ZRKtBxRf9w60TI95z+4OWTN9C8v5h7Ur0q3+kRsq0L8EBNXV9ROsEhKwuKpVaxYznqIH
c7lPDCCgqYdNy1gyyzncvSanMuHg2K+Yog0XZcZiaLerrZkdr4gULFvirng5nYwDkI+4S2FQeJRL
ilEUlcFjqW4zBxLPgSyNkXde2FabFcLZldr/AFHGolUnSy/Kyfio+XmW4WVktdueiWhCHQ9KhwtR
YPCW6TDzKNiriAPcA+HqGgdtlqr8KjE3QJsTymD8zZG78RR1puaClDfQ5D5tc74ge8M+JnOqP5id
aak8RmvJPcSxgR3jSZ3EgFHDgisWzRL7hAuAT3UJHdQVxcR02ou72IYaDXLBNe4zeI91BPKeZwiH
Rdt+ZZoEWiAxNVYfcTWynIcPMeIIa2cHFj1BwSo3uGvAPbY9jZwOmKGCOWGYa4QqhFS/1OtGujbz
EYdFDveSgi00eNgSNDlDRrRz1MfwbBzFgr0FLv1UbMxqKhWCAz3DsBND8xA9oFwVzEwrWe4rkRje
ITS8sOSOhSwkM6pdi33KoK3qJsYsGDGtjMF8yx1uH5CIqSxnPMLjbLb4igIoqOpugLIc2Kibj9xU
9m348QixsteZpYqu4PhlD3GShKP0hAwHLlqVO1RoHLZ/EoRC0OvUNaeeYDBpL9IXWoIEvceh6JSL
mJ3kZq20ckJHXK8phk1De4GRGtKUVFj91Qtm4Mh3nZdXQ3W+SZypbrljKx+WQ6SR8kSo6i/rCUo5
09ygHSDFV83Z2sx2C5kew1GviGjEE+jmB1EBgSFVSJQmZK88kv0YbKlraVDalxTVdriu8VW8mwK5
0VY7gxfRpRbD4lSIQN1y1E7GsTu+KgwtZbo6ZU8Ub9ttQ5FEV8kIlgCx3CXERPKWXuwIA/8AvMCz
i3OHY6okHcAEggTQdgF1uhVo2DyeIECcGt6/yDBQQoGl+Zehf3MLQmOfiKFNlRX7Ql/pW+9jQIWF
eVqONjBvxXUsyzOvTFRB5Ros+B6iOTTVEMrItrEoAPOrj5Rkdr7iCCMV5biOwUrdl7mhBwXsCCBQ
d8ihqlD2wq0C7ERISqAoHe4NECviIRAcl51/2NOYzkIQcwK8opyXQ5dy+Hypu9ljSbEoMOlCi9eI
1XmA/MrmhKbhXa27PKJ3eaIUwJ+FBL27iXcCNQBadXGV4x4LMmV5i9iNMb+BC6w4zGZ2rJ6yXR2b
srsQGx42CbOFjjKyNACXTdqHhDAr3KDdA65JcsAG0sbuKO9AORr/ALAhlfo0VLXqq16cxG4SeblQ
I7BS+ypfUBxLbUnLF3vDCqwh24gHzk5A4gJvlibGwKPmcoy76Uj1hgXDeMo5qUQXaFq+8iOQCyqU
RKtm1BaCTTqL+EUHbAFNq7j1LgtM6q+pdrdV1Y8RfBe3f/YamsrgZv6jY249ILYBLtrqpdA8a8OY
mZL4cbkRlVFvkeYk4tw6JL8wAXY8QM1o2mtcR4QTAcJU28D8MbbCq7EEFS5dhUzDQvqHwBEdNGxK
RpavOwhHQrqcKox5xipRh4G8lZbeHlFswqqcZUCtwHyP8grNWuFhNaKeh7lORI2VbkgI1PXFXcAS
rDb4Ajyj0dgQML7ztsSl+KsPdvUN4tbYjOGXU8vcb1QqV0A9+pzMFD4JamF4KXNmwrvxXZXT30Ks
b3ODTB4ChnJKFaW/M1k09Nn9ylVZfcpKuHmBXYU/cN9Eog5Y+VAnrRk2k9cywUvgR1ap3FRllt+o
qhFZL88hXhCd0W8+uZdAClt0MfhC29IHrUQ4jNBcA6/8xBDLVfzNDQIh3DZCuXz9zkCR9yudvk9Q
1ajYvlg0uMeyox+tBOthPqi16qW9yfSOmtnVxrZZEWpjFEEPkiZbXJHtdg2iADjFCkolHYPEaxPM
WjQ3zCmlXzE7QSlotV5lCVg+DINw23TF8OqOJZyVQS+YvpxTIRVfxEJxR+Nh5KdDRFeG1Kh24V6l
haqneoClWm7ggdqz72KkAFHiU4pvM3OKG+I4XrPZhkajlqKEgrTgQMQ5dMDgFalPEHDAtsDMPD25
MybUIzjGWM2owwhfJCC1v+dzYBZTeYPoWkJTUymFlXFUckKi3Ud0fimXFV4HirgKLwdTKQa0syHp
L0dh8pMa+ZVxiL1kshpePHqBKtyOBjTm6heJ3MtjaCRzBFFrGWwVfSPdBy0ROZ1Yjkgsbsi+wK5a
1L9H2lpO/wC/MVIuhZizKqQxrBB2uoiEU0EatLyP3G3Y8AFirrOJkrZRKuKZ80wiJT544iFAhnm+
LgeeAuI6jUeOGLn3b8ShVVo8ER2DJ6m6YumWWr+IgbkAYLADk5hEiabzLMAC6S/xKCLraA1zLVk0
vF7l90KfUUPo9CrglZVohosCPAb5uJN9q83v+xiOKbfuCbeRHmBYQCXeeIkG1tXaLH0tt7U16fIC
Nkb1vNPDBrYYjzLXHOrNO5wRVQwf0ZLrA18YgETVVUA100oggKeKKHxBlPA414sh8CC2XCvGzHgd
QyFbBHMtStp9P2TxmgR+ZvqQDokXHgs+UqAhVvUkkUQrmIbcVvtzEOU06KNdy9YgDmsljTFDeSZZ
yOy5ODm2YyjXMGFsmlVEZKKVrwRRwKgyhLEK4SsJbVFCvEatCaBLvYVyG/zCpYulI1zGRU0VcrYb
Le1PmYE14i4J2HJmbLOdqHHhNVdU3lPEaHBQMPMU9jgLihMGnScPALQFsvohqw/hxOAP7uImbeSc
REyr6XhHlMPSailnWD9ImIuGmsS5qGkUa7AOH3ACqLXipQcEm7nlnOKeVyrDtsui4OMlp1LHGrCF
Izy+OIBLLAt83CiJLFUe4Giu6xKg+3ZxU6lSVKDX1Bt6yjmC8OpXB3CxwCAmsTAAfcLqG5EGKjkA
RyGYSgL6j1aYHL2wr91Xy0f5KtFSmOY8h0SuJ1es+r7lhx4Va5gQ+45UQdsqzmLT1CrfEELmMqzO
KlD1CG4OYSjLm1vWC8kg2A2wYniVdKIgo1K8K5MspNKgKl/wcZVeJbHAuhHHka6QI2Fa6EOv0sqX
MbCLQkQu1ttxWoxl779RLLBs5xlCiIq0bLZD5JV/qag2g21kGINgvl5jFAW7txUE28oxjKTUVU5u
MqKKKYz9y+ABqnrqWt9yNWKyj1NksRdAbGvozG9WgygHapdWuovsjtSHQxpNZHMM8QhZdJemuqrq
c8Rbv6np4I3Ko1Ka5jw+tbH5qOlABvM4nIdCUsbAISYFMU3O18RIvvSWD1LLpWmjhxPejVt8QSsG
F9C5ToiOCxVwZ4ISq/UH1krg1sOubblKiXIp7P6qMi1Qtgq7j6yy0uoVjxBCUx6IKcrebinZ6gyg
HzANvMr2SpCzd36hbLlx1dbxUs2L5IiG1xHqx2Ow3mszHys0NRRfcf5YQrT4iumHLLIqgtW7utv6
lvGVUcI9tssuifcGtQdF2DgBqRAtfDlRgjbEhFFgpGxRRdRFSlVLC+YsTkKIS9+pp2vzE5OVkbFI
L4mmm31ELZT3bC5le4gKbPMKujalEcvzPsEsuiIAV1BQLtdRhQWWOSjrYFHMCv5i5u76Qgs5J5is
NivA/cFtkU8G43L0NErouAY/uMSocP8A7CB2kFpgAZUzpqvEQ898y8c4S8wpVAsWUOtepFOFaLcs
LBHusnCW1NDX4lubV2ZWDaoLZGVEaIKmWVb8EOxq7ZrOPxBaedj/ACOJouDkxL8EsLf3EV3VUH+R
wZB4HJVrVdXkKhK2dstiSoX082BFRQUraiOi88o9M3KUXHLaHhlEZyXU8cS6dJSHKIwzbmPXdQPB
LcDbZhS6bIQ4yi4VP8zWFZBXzFT7L2RcLwGlD6RbbNQPL3Ogg3qRXlVMeI7bpYQSlpzCrGqhm2QM
A4EeCZL/AJiA3evqK7AtP5Tb3ZZUvSsrEi81B5uYGFlOwW+HkYvs+SZoLwXUU1NW25a+r8R1oXwD
8waJBqPELk0+R/uWAr8vmAUTTekG0ersy/nZRvUaqs6PD/kDAa822S+yZ22m4UWNPMTjExvh6i9t
9jlE22/MGLb8GWYgcK6i86i2uxxahmNVDUeCna8M9Aasav8AxIIpPm/qWTwV4hZefKbS4m9IVkBg
PcYNRsV0hl93IxZst7pXY8FLFf8AJra1VXLZqTQzGOEMN/E7As5ljaOiqnQvlCHxPyzSTvk9eYwX
ESuH11OQVsW1wE8nlvEdhVnMQWqyCEWkJu0qyau6qEzaavKVKgNic3DBWAC8ShUzdvMLfFvmd7OB
V+Z2jzSCqF97DyuWUEizCkpt7Fqi9x0ORXMoAU2l31LBP42I0WhmvMKiXmyQwBbYmf3Ajj5CCoOH
iNqgOCD8RpWVdtylqqooLDpTTLGr7K5LaG3mClt8FibtHaliKoHIKiBC1eyHjHgWofELsOfuKKPd
pHRbUvhZXeCDNf8AY4EcNZ+JaCz2MoqEwBgfxksdQSeoHdWsyaipgM05ZcCOlJ5TIV3nCMOAD0KY
vol4JA5dl6S0Vp7tge71bGlD+YSj/a5cVbplBTiJdvE0WcwECrwVexWlDY1kZKonNzFLbl/bWsCn
0ZpC2o1b1DxFaoL/AHEFK9sTBn5RLy3wiJO3hcZsTycQcQtWrjFBS7FXEKdS0jJMr14g7U8BtQz5
QMI/NuK8QsNt5HeU6C7XrMKsFLqKF7Lu/wCpZ3kWH/Yy3q8Rzv5zHNezzBEqAOSEbRvqAQguhKfR
3kIujj2RIlW6rUhIOHQy1HXiBVq8AT5dAWxdo8jciASt5kLOnCF0yxXu4Qd3HJtcvyP2u3PE8sHu
EHN1p1AWyOTWOXE5WQQFdjko4G1iuDnJUw1XEyap7hz7qKwlmxUId9yg87KVosn/AKEFz47puyja
/iYFGYlgHC75hs7+O5RvXyXCFg9BzFQ5q1GxRWVVMWKpb4Sgu0aXVxJYU4yL6ULuoqRV4Kj2idBz
GYq+JQos5qXwKMzmYEDo5ipHWwYKqNzqBKnFbcwUW9xD4mhGxsgUc+IkHPxKAqqYSuL3klQAaia4
Jha4lrFfibgOcRVyCxCOTBqFGquzkSnSNyAnKpeHz6l2LcETpBysfsodTbCvaZBBC5ZA43T4g61t
rNlzAXbOo5FAcxZ2GqgVi3myIxYHIjhMRr5lkSmiLoKrKhY/tB99KDzDg5IuvH+Z4sPcT3FFGTDw
JTsowPFsNq9uooZF8RIA/EeMlFEF1QtwyNHPCo4b1TkoSHCnMrmVpKxi1NrxzAuwdEcm31WGAjn8
GM2U1VTZ8O8hixR14lNcMsAh5rYr5L1XmKyLbfUQTZqi6i3+7hUKlZNi2NbFRt5goWcdkpTyrBYD
s1GIFi6Jdj8qRfbOuvcJNtE6imKgZqNVB9DYogHuVIXwiFxahkJtcVqBixvHPuUZc24S1EqfUIHa
XuZKa5qwjpOQnUthKBN4vYwXjl2SlmNDuGRogK2XxaAU4PiedQjmApZVWswCZYo1OeEWlwe4bMj4
m7bLSbOItx5nOhoU4gpbciPfIXA2qsrMwOWmANAEK7jD2WU5iVBbhhdbmOovBS3RGaW2AQ4R1PxB
3whbrZ8RgU18TMwssyWm+c8d17jZ6uXmL3oaeEXQ5p4j2g5BUuhJw79ywGsdC/MPlrmNbG+wVaM+
IPW3ipzBSVtW7DZUE9wqKIMlaYNBhy0OhtEFlBAcuozUI0LqOwFRVc+pQaJ5I2lTLJaaymmrzGcA
bBrHoCqfUII567x36GUVHeebHBCzcBSRhScdEDsqUNAUH3CeYXt0wfbeYUSggF4t+MlzBfjzBbUC
6uFBNJ57jwt+JZeCPHEFxUueZhQEoM5le8GxQEc6zpOHn4lrQTnufUWgAw7uXIDzYWMLQlCgr3Hr
UVT3GzlEKlaoF8X8xt8QwrYVi4pkw4TTs/zLSbKcrl/ymzKj2BbcrzuPptxooykdQlIxiKVkuovB
RME3JSWGfhXdmadRDmbwiqOHEJQGX4/cN1mrFfEEq2uiEW9LRgqCSpdNc/EFw6GXCQOFxC5fHmXl
7bAVEUaKBV+mVZgMFXfmH+gte4AewOEKZnWvPSKBuUUm1sZdQSluxi0tVU/MRMOhXSD1Lqo0+Lv/
AJPCk6FSip9ektFoId7AnOgQlyoI5L3FKS5f3fmYWgSGhAwyMH6QFfItckHWLqz/AN4hspwRBcU0
DBqwiNfMHrciSx1nP38y+YMXVusiO/NVSRsgXlZn+xdAgFixCohoj7EcJQt/UImLbmYh9BlrbTci
+EA1XDChVUpVsMTck2ms/mVJSLOl7jigFGWd/wASgzUKu2O71hDPj9xF4Mo5B1i34HxLgt8ABsWC
30U1ArpZHmoa2dQwNx/ZEnuG64vqW7gC+YINIr4j6KQsULxFtJMfcMwSwipLlbESV242W9C+IMX4
MairruGAL8QVnJGuk4Atfx/+QLLo3c2B+CVqlvUvQAeSARDmmWo+R8VNFInnBlil8N6hXK4kPUG6
FgqVgjea6qPkqlGq+4VNJZTrzEbWpqgqvMH9oZwXEa3gU4yUcxgziXYhpw9StkVYvuGoZuMIwxR4
JRmqWDpw4iBti0eERCn2hZ2czcnKFo6mEXf8QddJQNkFVXMVdAOURCRRZDcixUDxzCIjwsyxMFlG
waLfjwj89cnmVei6jxBoLXtPc6OxjiB5lNNErcgJ0VcWJJZw4h9EIGqdwtLi05MMna1ZhsxRwsz7
i5jRWpDcObjuAQcllSqjVPJYwAVKOFwUrK08snCApfcIzYso8kACBQXBTDXBjkyZF0ErbdLxxM6K
nVQjlBuEBgp8ji5TvSNpPAYMVsdSAg1alnHxAtoTSFijimwWAKAZjBcB1eU5lzQfxLeAUNRb3NWj
mDalG+FgIwNgbOoIFXnuMrgOziFHgrDuCtgVK57qAqYYDiVhfbh/UCTbZhxEPM+8EYGB4Ew02UYw
F6bGCKOYJq4ZQIhRp8zlG5DmoteWhcvhl3U2MjkwIp+EMuir8xNUsteoYlSUV3cANCET1BcG2h+4
17SxruE0lp8s2cDRbLphBFTrlCwc6a4gph4PxGICyuayUjiWK5B4iAoGicV3GFW64ryRVWODXDAr
WoHKWHFWQlfO0xRxuqQIAHzEUgFrJw+GK3ktpCF12j4cwr3RocSEVaW+yamgkRbjfN08/UJwNDXz
BMVpwQyaCiGcrw/Ax7QLVI1G5eLlChHD4Rqkt35lR+XYDk/9UryApto1+obDuAFFgNobVXu2MVUT
1fUu0Xcq4a5hT7R1K9geGXOypEy+YOoKB6ajX0rWNTDIirp9QFgFtaoqXYS7LdytUPiJxQGNjn0m
GvVvnmOshv0QLW1gWEtiB9p5geurSGuS5zUGW3LQbcjdMOxtyxxkcVhezaUQSPY8ylkjgMNlKdDY
NtlWa2g50QlVl+yBGRMgqqlyhFJWK8E0UNMriogHTDCyAxLbctzcp6C4dLWsvV4AcFgQl8Kb+ZTq
rFqB8REoiPkEG2CFLxL+CqCOYQUUm+At4gSP1J/2CmdxNVwWVF1TmubvmXrrOO7r+o4ssidEAVvu
zn3+4YAcAc53MwCM2oBApzX1KzVsg4i6q1vJ3Fml2EtuDs5h8mxTXQ/uDcEBsGRbqFJ2BGBWzh+J
aIOh3OWHUD1AIOOYCxBnGNdQs4Z43pFNU++dlqbKVObyBbS2K7Uf5BhDNst64lhAkCtce4KRVhzG
OeG8nYPM5z8Q7yBXCti2qg/wYFlkJRQXdV4ikAVKNc7lRFAleLjQRcHtuC3rIvaUuMiBy1Egciug
HZqf2t93MSgD83Ehdb0j5rVXkMmsElWrcfBDBuXxGkUWl49TMpwj3NzEK7YaSQFwF9wgru7G6uUn
gcdayliS0cU9TE94FNWSg2pYaLlHbi6HQT9RTo3NoKdRWpbpenJj7yOUuv6nFQINdCDUu0OWzmEj
YAHglIPgx6mENuoyIMDg52FNAHiX4i0MR6DXM4AyGbx1M+cV/CESbZlP/MJlez3QQpC1oOGkTqeZ
RfCPq36XdJVJKlDh7/MD72auLL/qHVQ+q1/kSCPtEMuVfIhU7NhkUDc+5QTeVfkjSq8Cq3X5lv3b
IUFPUvbppTZNJvUICKb5lbZTEbvxDPg8wC1y4YbBk90ZJVI4+YVY0RqFC+OY0KexsPAMVvTKGBVp
33L53x7vuKD1W+2Z+nBe6l31tuo9CAweZv1u/K47qaAr1UBFoYDpJLSXjYiI0G7gV221zDUbq9x0
4V18QEv8IuVezF09QWrka/cXVY+J6kggpjg00lXinqURou+4hcV8RoUgb2qBLhqXtEv1DCFSpGj+
EvriNK6yKCWv3BQGip4goUG3Z5lx9LHr3G4DKsTWahL3A9Oyb6UjsojbX1CEqeAassEQ0ekBCCo5
A3gOSjvqVlGIjFTbqMy8M8xRaZPhEGLyF45jUdDXrY9QBDT4yIvu/e99QSdvX0lUfRPcPOstqarF
0mMLcFV3LJmoEPiXSII57iAU6LczSXEfEEAN2r6uEInyGcQ9ilLkdOFvHMJ0WXRZfTS99+IYDSgQ
4WGc2pj3Glhe4apIG/GSmCuj1MGLyK6is7sj1LENrDiEL4LqEqAp+kSm1orIKXDeZgGrfUBQaSTl
yLN/mGLpovgqCKgWrOpKYYU6rICVBVTgOVfqB6hvX8wK1TC/Uu4APvuV3PRqMeTC+OYXaWgqEGhO
SPiFGGoGWHFwRW6NQwALKSXqgsrrZYqWhGHMK1cKqw162XbiyPNwxAVaDu6mL0j/ANQamHX9I26f
qh1hd0+nEoWUafceOYC9QgtaD8QfA2pZDmbR9JnmjSNSBYj8QfQcIamFKn1LOODZbQArXEMLsAHW
1LCpAx7gdVfnolFxSsGm4eESqWgp8kXBez2f7gzyLt+ZSspc/bLxVC/i26izl+H3k5kED42bJWvn
YxAqEOeYGsA+1FxS9LaPZsHiUxAXohgCn2EruVby9y2MoJZ9QGqSg7REcnj1Ec8k7PwmYWMCQaWe
blFjKiOIadefcMqUKfK5ksAH6RNBdM83LOo4Hs8Q26toKu6igCtX8o+oW9csNipRp3GB5U2JFKON
49R+BFHW8ExlBtNlosXKIVGm12R28hsu92Fgqin4jYXUHYsOMUaHxA0k6tV8xyKqgA+ZZKgVVSEs
FRXwiRqFIfEKDVlb2rlhV1b6GzMzo1/sz4ss8X3B81VR8sFqIDaeeYi9UC18pK6uQ8lIibiiLb8o
CicNfD1NCW1z1AYKWoiHRF8ZdCQu3Jferfsv+oC9hSdf7OcZ68lcxDWvQPAy7I12U34i8kvUFAks
IQwRCvzHMbzv5YBF5x9EtQZZeR1MlAi/GbEeiw5dfEOMUccmy26euY2rGaqLsr8TFNXT9RwBUacs
4ysj9yy8LT6MsUaKXkuBfs8nFzDN4V8Iaium9NOYHGIeN5gLza5Hy1KDUEr57gA7iwDudoA+rJ1l
2KImxF8G8xgq2vdqANp06g2geaNl0DoIpd0h8oLIUgN/L/ssqAF43fuaqWyujIBwxr9wJln2Iobj
flvP6gtlnfuaCKfy2w0NbBQ/yCp3F+eJV/gHM5I1wLWpnSNnZfW/+xHjuoQI0j5I3H3gbipVlQr4
iCdt8CrM1aqi34l7pYh/EqELtu+kbz3fqrICALIY/wDrjDBwA+OIy16Lu2beI18IuQcjBRiT/kB3
sB5PmJBQJObuDgLeHBUW6WPRVJU1ILrsqzCCOU/7NAmyu1ieV4PEdOLqOGheESceoLlb8xGatnxg
aFt2FKgaGsV29DUYK3qUrVWtJcYgIKj+Iw/XB1sHrUNJcFYQBydRsRtjbg61Af7G+JsETfqFSDV6
KjSE5DsiKqMB8SiPTu3uX0eQ3yRAtBQeyCBZhXhgNYg39czYI60lPYPEIW7UrDWojwu5Qa4eKgK5
alBNW+JoKvqyEY5XhmreYF6DEnW9SyvZrmMoIjYjtKRT9zVZLvEOmALvMS0uyr8wU5WQ1dr0SlhG
Voeg9DZjMuRe+K18z5OAzsrQ0fkik7lfhj8KVXUxxrLlkKApCbyahXM2PbEriL4Q2qKKEP3UUTVU
BGLWrs8ZDBdpagkCjABhqNjiwqlK/wCwAsBdnxKkFbV8Ru2AhthRaHxBpqbR3sDuoojQyxCQGm7w
RY3Hs6jq4LPccCjkQg2itfcIsgv3DBCo06IBDLiu1xcgLbKJWGXxGIKt8IvaVysNecLYKfgxcRnA
6uK2xXP1EdsZNG2mBx4l76Fq/Fcy1lek9wz87kqB23mIiAC/UTGpWz4iJe3AZVyttOvqPEKDp1ND
lRBxLugwX3GDFFH1sZ2to5FJQx67KGYGLtyxVJe9kIm3o5NgpVyxjSAQC4TJ/wBJ5xfgYvmiVcem
VUdNRYSrrptbLuFpqJximJ5riI+L0Mm0BzHXFw6DkPsmvF0V4ib6zyHqGEXkfErcWpr1EooZ4HTB
Sg0D3BR2raiSYoDlfMO3sh/cCQ/LuEUj0PXMFInB5ldU1PdsaMSDXSEJpW1wUMvY7jfTHwGhWmIR
r0BVPFTdW/syhC1X8ztIwXkP+QhxrBW8xI031PiIQOBS3d9SvWHRbdqUdCw8jXM0E+jgruDZKACV
HKgCte2CiM18kfY9QFaasg9xNjXGwLrqIBugnkYZWC6TzUvGRgnzNBrdveTxYqB1fM1K2NB0Y8cR
2xdo5q+IxqtrU5+rb8GDvtK7EgIbIg+Li47sh7gwhai8vWSgECBR4vuUJGdn3sTFSAHMGbfRRLI2
Ni1giuVuh6qVmWl4cx1cOzxe4TCKCmS/MYsiHxcsFUiuW4bthSvyhPINtNZn6m5+rYgAAR8uychB
F9EtazQcO8sQDYouxjQgCPyrmKnCoeCFm8z1RsPaHTyQZUFYhogBqdpEoMqvxcrxFw3/AN5gN+FK
zQIghJ7NRhARnd5LvWoJV5LzsZuE2ghf22LiAaOjuPdQQ8tynMlHWEL2Kpecz9Q+bNijpRBj4KbV
cwGFtB6uOg4e4ubmF0TduAqWOEQ9JefyBqkt8kt+BiK0JF8wqwR5j3ELbadGLyqreUeJbAu4tB3C
hlfgksQjLi7clKDq7d8fmHfVq2HMzfxT62KANTyL4h6rma58PqMtJVTq4PfKHPMvzQSDkxdESArL
6qGqTF9awFLYGXsA8FEuO/qUMEByGh/TDdC1HGpd3cB5vmpgG73sxqLIR2r3DsflDf8AsalJfnbs
EMlc8cf5KrC0udkurkMNWEBHEV9YZ+oUlfHAkChPcnJYXUh/45IyGk08kLM0lykn9xry1LCzzC1D
D4KP8lPRcQTN/U6WANjxXHiUMlwF8F/xEmmRc1/8iXTQ4BvwQVIhYqAur/ZPqXsA3/MdmJRdLAuq
1nyP9jhUKujP6jqALW9u+P4mfpVboSF/ZdfqivzKB0muBE8hV6xHCjzKVS8EK2ITySy3YHqfSDma
Ky/M4Vu2GwdOjK3OvAgQ4hHWCBbfwFxVSC/h3GXLW178EMIWR9q4IM1W/QtXD6h53FGWAT7uMtIC
urqFkfazNlTQ3sGIDMdOS0LAVeTHGI3xk5AKnxcKJLQeIWOhY5JYECvWb2FfEVY1fUMLV/MugdGX
ErBKzioI7jiIEFjalNUwPMDYZ3c+18xzpKjjytCjOHqtt49xMkNjzDIcMeyZLIF+JQoFYrsU287L
mYDFwq+5jRhuzmV/9FclU1arwiTGlt0sJXtbFV/bBACjbfY5sOBbDuUALHo1Dgdx8Hx1cJcA6vqX
Mlj2gQJ0RvEvsd7YpG2zOIChpwpZcxG+S4sCiIBRZFg6j0lxQuF4LgVpBS/3BE+S42HC01jkJslG
+iXTd7s4J5HkO8iHsdXmLox2MblDokqE86O9hs0AE8wwJ0nFY2BZoErldCL1OVrHyeok4aJdZ4m1
Cw7Ni6HK3ahPWPHEYfJsR5lZ5Q2iB4dVK2GsB4huLg+XULO8Wh8jABIYp4jVUnWNUsXiDMMlTuFS
30aFVZDVlXVhAQAZTksKdB7PME6oEsIwLoKBmRASw2eS9gC6AVBgMtsS5VtABwg4+OFn3gLqomA0
VQzK7SeoKuA3RAYQx1BE7N9S6GIody7ReFb3O5yBjfuKFy1rHwKbB1AKCl6lHiwF7gASLg8/MUuH
FLdfEea0oBIICXLExUbRu9ysCiwp4igtIFcqKkC7hAL3XAzk+OL4b5hkCsBi7gKWE+JcCsKt6uZk
y3kjWdmkVTNNUZnzVCvviDWBivH5gQBMLHNfxKBaAi47zHBrqW9VsADUA9Td+UU9Q8LS7dIKHlIq
2EEuD6e5QXZV8MS2o5Pc5cIui1BwaVrwxBU9VC2Op1VrqZA1XpcPaG/AoFIbodkIsAilUc8S5odA
pyIuG5KNh5TM8BcWNWgO1SpEBUrr8R8wW79x+BVN6sC3WW5VxnErKGqupZOUJ4b4lYjjlJbHuY03
6hZQCb9yt9RMzktru1WK5Lg5uhv28wzhUdSdSsV/KlnzsXm7aSV9dy3gABM21N4cxHZml45/2OAX
VO2PmaRYk5ZKhqz4giYmlNwrhsB6lzKKv96R6jRRRz3BrvCftOztwLv3GQwCPiNV6oUyumAAAFfu
GIRC5yJ3TQfcSuQep5j5JULV8RFQJpW+oP8AGiuA8sRW5qv4RGxpgDPUWoXlFj0hDiRdI+Eq3Ila
+SW2ONmEwCOrq3MSCCjZ+ryKXOwUwYaABab5jR3JVdsayayqiQDFiUAaH9PMp1BXkhlF4rU89ypa
w8HfMefRfT+4yqzRb2cTNzK4PPFBCVka9yyvcb4LOsJ7A7cw+RsC2vqWoKUcsvka+OW5lD2VFVRq
pveu7i8BUeQdQXGnRH5jIErXhLYsoPuJ6lLY1WMNZAgXyK/7AFV1re3K2jRWP1GleDW0lj7Wn1Ks
zWL+EcgY5OIf7DqmILxF9np7jQ++Ajog2WIdgxN0rsTT3F97BRru5VESm22Nv4l/X/KpgC3MEHio
0ElwiwazbIqXguY7o4+o7S+7XT1DaSRSlXBEgvdOozXNeDe7nZBqDQn8TZOWX1AClkQ/cmhAOv4l
KS1atgjXbAOPgyw47lsPxBhNiPZzxEC1aD/E53mZuPzA0FLzOQiiWFP48wGpnpnwIWqeX3Ldd6Iz
0p/mLTs3dyyAxqY7R7ldXvoryznAoJtxhHYSvCRsIlgOVGHqwLaO54h1GxglkTEv+R7auXaHSuXa
3LUMAeE1zD98w9QW4XWw0m6GnqCNZDtWLLvLLpeppSyXhodoWA4lKWUvcvYsamlCKDanIYeIChxU
VNhR5i3tSMGHgZzAzzKF35GEHRwHonECFFNe9i1LN6uo9mjxc7cP3a/MD5YEAD9MOIcQtnzH5Bo0
qv3Gz12vEdN4B3DGQWAqcixlpa9vnmNUB4bjcC3RBGicquWMuqQTU1BF945Fi1ynzEKAhXkwGQvQ
yjDXMK0RVH+Jzk5txCK2uLiOKm66S1WxWCWQC0uInK8NXBl1NJboltAd5yWSlbYypTKVygglOrRA
m29gC5VfqWIPgSvuL3ebbGw8FNRxzwclQxuukVjfOyFggO95CQUCqWIUpYZuByXNRgVaLl64s0ua
Fmz1C97rc/NzRuPlksbj4lUxq13koJ2SVxGsGpeWgWH9ROdvV8Qu8tfMQgPngj0oH5RXW3BzzLwy
6MzgPxOdM6uop9SwS5VVexYgehuWAWi7sihqgLyKglDXIrkvRHu4eWq9vjA7nu+HuJ9ppYQc8KY2
Viu1GLacZyhioq2dR8ZNRsDtSXSittfniAXB6YgFsIXiJz7VfEDW44kXrvQfmUavZsYZbWIlMcmq
mT0p1sjUbqi1ORTiXXyvwR7rdLC6YHkhkKFg+IyIscHIvHm+4kp5rhSUx554Ddf/AIYXEjSLkHuk
1x93LNQaG9hJgU08xp01XoqDLWlPuHHXUsN5cwBMqcBRGTmVarIZ6O8WR6hONwQzzVAWpCL2l7sF
bFsyLOkPMqL5cQUgzWSgqNqdy5CRCFCMMFfEH8OteIFcBu7lam4L6Ifsp1EVudm3Eua2xYfUVLVv
dFR+muaKIg4mlNIy8p+qydmjEsQBzBoFh3UW4xVghKp5bmFmhvKRmarzwYF0TttkunVY+zQdBahy
vgRGSFW9SzQ57Ox0amlvEv6VTrmKAZgJTwDoRJ7eINLfUUaW+dUbtW6VUWBF8VfMRa9xRcuBeG6W
raOL5jEo+oeY+qcIXMeGnEVEL0XFtUu12LegLP5jRgPlOIcPiNztY3AJYb/EMvuyKLBTkKVE3W/E
vjzBFqdwnqXQIdQEotviOrvmIYwXwQeAS/Sv3K4nxNiSg+k9agkOF/TcSZO2buJpD7OYi+ujgiZs
/DsKUOjZRcVtb45hY8t9ouCFzevUT2fYRC1amMoHeY0+YgsPogwu7pj9xBK/qxgNdO7Dau9YwNap
xyjeh1exlvTiYI+Yq3T29wn6iO/+yGGgtC7PMv670wAIIV9ZKukelmJByht+IdmGVVud1JdYuFOI
oVvrmdXHiI8H9Q0JatLYy4XiIER/iBsOBf7mOoPMx+0CZVMbWu3+JdFvfUADsl/ERaI9Ii1Q7qwV
dZzF+Z+pf0q0JmrIkehUXcJGmhW2sHirgOQ7naESmDlcnOCOcV0e5eDXeB/MasfbrFGp0QiBVdOC
HFi3JlyOagGtWoIoDe6LcZKR46HrxBvsCyLR6iTjrxc2BrNqtkK+19RXWRrzKmCZewYlgu3oh2VX
gZlIZ1s1DVr7hJKPV+YVYXW9f1AZYeIdCK/+2K3o2638y3E0xSKPfEPodlHcbmU/iMdxcAbMqgE8
Uu6irhyZvacQd0WFtSq8VwcwQrlQ9whUC8ZYW+/aLjBxHp3nSMC4dpeDZU1RFfUw/tKdhuwUr7m7
SUktNAuxUQKFFUhPFLXI3c7UTq+DPzA9U4A4jo0dRv8AFtayHqr2K4naWQRoKWkcmivKDkUbSb7k
OQUs4lIF7HKWMl4UQtlPbNaux89RIUhUvbcqcxvSDkX7lqlGBOTIiypVB4jRgATucRhg5nSgITRT
sJaXinuA09gtqtqupSFK8r/9sCdA78x3C/VM0/fCfFR6vHmeOloJZITEQ+cHDwjPaPylB8aU6hQi
YFtyrBva/wCQgnwAgM3LSrJYjBdpc0oDwFXEUB+6P9AFXa/iAyg3kbMLLa6gkGsdsjFkxgo5l3xK
CcvUbmYaCGwhVlHSVUFolaTDTxMnxalqoPEUrkG5GOKBSmx8RGgGEAtkaxusSMQPKql6iBeB9xgg
elwwD1gHU53I8LUbFjxZwRBjdW/cCq89Bb1Tzpy7oh+w6N16gMdoI57hIaugyzliyA7dQAbN5LT5
tuXqBkNUwS7muDjmCMJp2e4F8rT5IZJC7Nw7Yq8iu5zAuoVSniMLmKBweGVukOBVZFGFD5hJPZXG
Jxgm2guoojwUrCWsKBSckwI1c4hWtuVteoRzvVeITNDlxfzEf42i5xV4cATc+BELllEssn0ms5FG
SPOAtFuJw3g3VMZKLIFKQG3uPEHXW+agGUPQZZedxAFRee+Ie2lRBzUJLrfJ4hRsDQpr5jYC9hE6
q4ndXoWPqMEVRfygtGAotlDAPal0F1A+IlZ7b0PEKLZyPECGdpzsO1HZGM93ydfnYxlaDwfMsuEj
M7g+o+42KE4aYz8t8SoaPMoVlYt1hYqS6FXf/wBlkOi0IT0AwIyrKs0OfUcgQces/wBnCZihvqb2
pqLFrqYwryJdrwfuITZcQtV3DK1ZeeZUuD2cwmLGheTxfmMphev5i9l0128/iAP0gC04Y95WF2Qq
oAr3LQwUIwZZ2XQrfiL1brHuIbNCRYqAcpfh8Q0HUpcdwVwaoaa+CWM/WC0sEKD4F9bDjgp4qrmD
vFFM88xWNKqHthgY2Pn6lGyKovZzc3BgvDOsog5pgS4PT/3UOxXBxrZf8OB4Xn9xipQQhfdRyI6Q
AP5gYLkraBp/U59tJ3sfkQfZAk1ng3y/zBmN3NYufzHh4rrmCt9tXGcUOxrlX9yyqksNQjiVbAwt
+ajV7DmKnub1alVA18rhTRl6tjjol9lAfZ6mf2N3YhWMY8MohLaS1cuJu6/iawDH9Ep9Qvwj/wDJ
UAsihUWjt1nlUqebAzk0SwQGwukc9yxE+LYYH2ZQcN4iVwU9nufBCBQ7bAE0AeSFBgdvsmFXXx3E
Ojb4JYc1WXR7hBEaQU8bG2vqE43KgzdFg8VeSjuavhCgocnPzOg1K0jmQYG2kosq2BTDIanc7jAs
cleYnWuA42Y4G1X1BbdPXRDMUQZcqwpkbnJaQj5vxAFK437mSefE+YWiUN2+Y0CBXuVWHzBwq1Yk
4IU8xj8KzJiZx47gTceoUBx4j8LKqLD3BiwQHEKgS7L3AEAIo4q5e7IsSAAAa8D3GmnpAG2Xb0TS
RAfL5iBCsh1COpoEvuI12qIVkBKZS0UdSukfsFTnMxiSqeJsUKg8ojzHbmV1JpDH3H0OrNgIr2JP
G262JUEZDhCCejMP3KxRHHMZkVVr1KETUK5WD8pUByQp0Nvi9GOxPB9R7bFnwni3AUqXYC2HEOgo
r+N5mZg1a5gbaFFHgmjTfIwRgBqupvERzViif3LtYObNl3DQaaWWSJCLQaMFqQr48QP/AHmGVOKh
/wAl8+bXMMBdmnUci9HCn7Rnprat+YSxdK4yM5WDR5FleACgDmMcIVQcS5JN2VAVqmEJWz3KB6ha
Yh30uUGKAs7YiQHRjPExPQ5ih1bwbAKqKombVbNe+INSRWIbbSw8wS1ToOHu4MIEtHLN3NoF/Mrn
TRnUI0NxqEaA3qFXXVSp7TyL9xtAnYnJDwQqocwTpbZ07ByLFIdQqmwd5sLWcvodbKu0soI9SocO
RC7SrsaVGWOEIR74KgcsB7zHpyXxbxVbBph8EO07h697BvKlkAXYZ/iVeWUh1DrBN2LikhoFU8RK
krtHXiDfBKArg5llABXiDAXM8+YeH5WuYLph4R3FhQL05gxa3c4V5/EyglfRL0ilss/+RS8Upo+G
PULSvKnhDlDx7QcEeFhAcw5hCk66GQvLuo8KldN+cgBnbsuP0w3VZKQDnxD1ELaPcIRq3WUUf7Cy
qGyndQlXRENyXVgG03iJWBwtA+4o5ccOpuEF2p1U9VnrLgiESHNPMQDaI4GPnWRA7g2QvB9DuGYa
xL70KLYwIpXh2i4NBeW9xiVwNta+ZzqGV1Cut4aPf5jxWqWBsWNzBPMdoDZrc1rnPKtmITLpeohA
KQGcQAEcA56RSjjJzUCuQ+76qMrn0rlmNeFchvI0ZvG/RCSiUF8uspELl5zexwTBwFRM+WD1DehE
fNfEt8yLaNQi6YSmkDaWIt1HoFW7KznnBtl3DXf1DyKqqTdPoA+5QNA+lwe4BpxwS/jqAiviP9UP
tGKaU3m40yxo82QXQ3UuvGTbuwLxkvsQFeXdjBbz5iItw7EuPlwK9QhqQocIS0g2+QF809wmEoLj
S44jaE88x64ZSlnn5jgNii7PNxhqAo/MzgkTxfEZXLparxAmzsOruIpbcvDv+QfWqWh9ozwWrH0w
WKGil2vqOLoJ7t/7H8ErGtyDpYTajK+JVVFWKjvP5lJ7Rv54/UyEFira3E/K9Dq5eG1++JdqQDwY
r6pm7X/ZQ5VF1r+dlhDKcUgSy8b18I/Ie/J+YriNIW8gfuOyAu2vCPSaifRLt6h1EL4/UswBFVd0
GfqIF1jDf3OqpgBLYHUC3wFbgAXNH77jAIKG1xf1Eq2ijsl2m0S6mExYgD+ZUFvUW8Nmv0FDRbzH
oKL7diKZecFt/wBwvC0Dwe0Lcuh4PcoTygAv6g9LsHxHuOUeLgN4Uk2G7m8TxVBQmsgFl7Rf8w6Z
S7LGCDTXMwdr6hooKJeCh6FSj1BA4L1APNHRALNJ7uBy3YSqfjY2Ati+r4ljQKhPFTdjJ7QfYULP
fEa9j2mxpAZa9RmadHxkIcpyfEpSpvOZflGlL52FnUinqIQPpAhw0BA0DWp5nPxUL8y0Cm5wEfja
6ljtUVEOV97NqfKNvKguzvqcAmS6xoR8GxDb5rKg0pBIjSoWxUATj0jhDa7PiWO/p8SiIq6wgqiy
/exm6ogt6jD5SxwnMP8A9ODKyWlV81L+q7A8J3GBE79cR10ehzLh4KWPG6ZYhuXvxxFSGltUupSK
lDCrj+SHj+IzbgdE+IMBCxguCHanyr1Cijb8zzFDHDmErSN6LfcYGWrOKMqGVQUHEIIaGwYUdccs
XMWgxyVapUQoYD8RhhSq+oJtowjBRvGnx5lAQsly8jaDsiHXl+oKIAm3m5UaD8fEcyaq1OSgUCqg
vMCsWVPjztSrMSqw7UX9vEA4qVAphcrGFuF01UaKeQv9Q2R4CbCB4XL1kVS6Cu9lfAAB4a5jGaci
n5mPpMsYdly694x1na4vuVAEQ9HzACER00plRFA/cF2sofuFqSXV56lRmRC+ogWl8JqFEiqgcU55
nZgaHdykQ3h8Tc6dtT48S1ujRfiD45MgC9t0X3HoA3C8uMtwW5QGXeL7AuU7vZzIUD6ggcZojMs8
e0aoOAwQoqvxDPuPz4jlarPC4HNHL3zBE4UQ8QDRonaCiuXj3AGmUZ6jXZFDj3EMyBrq4h2lRX8y
8wGm8Qll8zAWCvCifuGstLg8aBUB8sjYW+xh+4J1C98Q6LAZ1s3SaHzsouugMGFINJQsKOoyUpyO
WPSilXcoRWMt2JVX8zWFLCfxDJpFoZAwHqv5itXEVJdc9w1AVUqT2Ci1QImjgvZkJVifIuE9A83l
lfD7Dquo3rGA9wl2gT1Boq0HxFNUxO0sbMqB4blhJbCqyGaDFb6JYOx5GoNBRaG2QIZZ4mN8GivJ
UwANEO7RKoW3mpuUxbHIVd3wPUApcoPUNJFIKPcJiE0MjOwqikbnqA1NGOans3uBxRDyHmZaXIfH
MP2JijK87E9gHpvf3DV2i3RzBwBTTxBQVG3i7jvfNPrJYEro5ERqa08FRq0FoHq7illF4dR1Aym8
A375lOID/YNgMNbekYDlqVCUTWXSukJxNUbdy4ILV1tEDqgw6tENdgD/ADONARH5lRHBDqOilGw8
ty/BatcXZBpTQ1Sj1ksdKBVUd38zYZYXBQ00cl1AEC8BCFJAnlZShRa6S1OGreGW0QFvrTYb0JAO
IxnpAS5mwbIxFrvcOQE7qrj1CIk9a4tnL1QfDkfEGeqGUCOAdp3BsCJOsUvAyBZ2/wCROGKnYl26
qgwDz+4tLL9UhDbyDfcNxND5XIAyOnpwwUlcVu3gIHmjHuJglcr3QxcGah4C/wCSsBVoc5dRAaKW
nSyYsiN8uIvuo+CkZ6qxir2Fg6gd33OZ9RrslZLWhnLYIEXec5HrIITk4x9yzaIj9ITesg3dv9EI
LgL9j/yWgdrgs5An2QUGlzASYWcDf+Q2qCJ1uABRL2/9cMHgL9s1oaA8rZ/ke81mm0CBubMCDrIH
ZUZMWXOXTGNpNvtYEQDzzYwgxtB1qJYLvXGi/wCIwChTzbzAhf1MrcsuMae4jKqBU6IkV6PzGt0v
buKLeZasPSwhUHywLSoefiBjIs/VkS6h8uI4pw0vuU8Tz8epRqp3DyljvUHyry3iCdoLUaUKvloT
QCN1xscRTB4qdz4K4q6lSLSwxvXKt/cpc0rWZdON8+oiAXAfOxtlWcMaohFWAXiopbLPRFqTK2OH
mUDZnUetfIggUudb25wDHAEWx5OR9mwaF4h5s2WpPMe6lF2giUmwB8tjkxGgttPn2w2d83uCio5V
8xHbQc8wtQnLYX6VyvMsj5Ex1RfSNr6sfEWcLaL+Zj3ynAZUlNFdRK2Q1Rwiqhq4CdZU7bFcJXbp
qXLconzPQcAbvzFXkK47ds2AICNlsOWEij3K7F+fOzrI2dnuXQXG5s09XAIjs31GaDLE2QXpYzFE
v9xXIbE8vUvCyF5DIBypWMOggVy4gSKnZqobb1lXm5UVQEPNwkbBQp4gSSrKuAnf5opBW7gXYPtE
Dk5eiA7dx6dlRITcGChss7top2XDbI5RC2UtwzVe4A3UUYyO9V3qM/dQ+IEiChOUljoaG/kjlGy2
XLib7+I/dO0qAegLq5QRMuu6qIG1jWu445QL6l2ZQ9+pRrVBt5g8rQIB4bsjbWFm+PUWWbi7Kh3W
zRZUeAtxaga088RBsU2fUtdAceIJFXV3Dw2EBvUhXhjryGv6QIENcNvxFCKBzw3L5sjjuOlbROCz
LiIePTEMKLc/qISX4DuOlmoHhFYDAPKNzJKbbczDoAOWHw2c+5c8x0/A5+oqrBJmAy6wBCwiqthX
i9lEjodrlf6io43uGpQYrvYV1ooHcV0A9nPc5aCDqziFOopB5YHRk8KrxNfCCBdEcAu6/mVgGUHN
B3H2gApdvcPg5KysDQ5gVByoh0c9ylgbIHdxTjlUOLjV7BCx6xlDt2Kd7B+VBsvRv3cW91Dx3FEr
RS+OJovTY5fUV6bxUt5VAJ8wQPgZ81/2XUCuX2YIkQVv6maMQF454loGyArIMNUMflACqdr3BruK
2w9yq0gxz87LhQFU+JzZ1ZVvEQsLoYy9cgChTjAIAmMqdRoY36HMJQypvKvmeBbHaB/kOJSwzH9x
bFyjp7jdGyn2zUXIDBNy5yivDuFYgbHJ8ELE427YOWNg7jPEMuWUhCXDfjiFBm+gN8zMlo31KbA5
B51/2WWUtL5wKJ5Oku7xA8LjMGtOzqUN4bdty55J8FQZ5CRx3HSPuzrZShTQ5cTFmq+bsyNWET04
IvqieSjj9Q9V0Pr3A4b6g0WwsaoUrGIqlOvESCqJHxsXcIk8hcyHOqX40H5SmtaEAIjaZPPqgigW
fT3mAU0T5R4BRSo8S+f87L4lQXIWNK5oHJFgkdhU1sILfULsONvoUgIcYBdLuZzhOnEW3ZPiryXB
263yWkFBbLBVvmFl8/7Ij2CAuFcgbUUkXa4zizVLO+ZZgFl8bAWB3+4TuLHGGcxvkHzD8sCyIHTa
9XxEBwY3ZsqMIeeC1wRwAq73/kZqgngLhvKrQc1dxmMUIb3/ANgUpp62Mldg7XnCllRV12Xr9z4F
GFJVdaR1ghx5ZcrYVLxAoXtfEvItLXb3+pvdYAy2Vm38shGrsA5jSEc0Ue0Qes3ealudQT4rHe8r
LSjaF45P5gor0eOIp2tHqLesJi7kwUXTa+pa11HSuhzKfJ+YweXxdw5gvkjVg31vglQ7tp9SjIFV
cGhctmW2VKsdpDAK1Ws2VzPGvWSz+QW2pmBVemAJpoPmYco+yC39LiB4m20R/wBLnxA1w9gMpo4C
+RESiiz7jyC5auT5gS4lKIKSJRXVwEeTxAS1Cj8xCzXMW7MHmUrXy8wR1bCgoCZ3tzNw0cVHirYF
EG+Y8Cl5lgtk7lxgvLfiXqGl+kJwXLBHj9KXgFSr4yAEFoDLeVyCLJ4inVRdBq4u11sAbJ9sdGqr
a5xKGBNJ83KlZRbziPAjTb8wwM6cLiI7hSNixWURWw+tl7iF3YFRvY1bxBQAvq0vL8D38sT19hDW
gEpouUqqyl0yUubq2VBvG3cbBLet+OINptuWJA4hfJLSMsKJDSsFG1CoVG3bLYFhAteJUeFDdxkp
cK4h+AKA2v1Ljo1UpEN5xMI4lPuPoaFV/HENeVtHzDqXyrHTRtrYqy8Uja1G0bD4IEdkNpERh8C+
cS4Qa9sPtRx6qHt3aBEKeUBYRkNUkx2OjD+0YXmpelii7CJg9MON3lyBDsU8kZtDw8TRCopyEVnQ
GEAlS+CFU6Cg9wjniNs5MxLISVAy3Ua8xgvdylS8MDgAVXFEL6woPNPEEPARfMszOoMWX9EIPcEf
v5RGuGrdfEHnXVTfHNV4N5cKYha8CF4DAypuFFh5NuFNG88xqiU2gWwldVVDKNryk9QmChvhg4SH
biYSQ08IGojB6lpAHx9wCoBSPRBti2Ly0/uUDBLs7KS+wTzc5whG+BY718C0X8QNFWNaQyZBfGXC
yA31r1C4QOFMfgK1bGMTa1rqAlaYOFmldxWSWHhKv7ZHCDlGdPbyAd60s7+YvcNIlK87qUUekFKw
uLj4Lgn1AKUHTMITjLgSuQwv9tuE+VYxfEttCBUmPiWsFMvyQFYlWF8dxblViHFRBYpElSD3dlg1
dlhSgCMynvzAogrT+YS5urOcwuPVWG4BTUCqrqBRS3lw3zPGZ5NOc8wC5OwW/MGlOWGE7LFlpENt
F4Uq9I0TT1MF72jpK7FGnjCguQV5hPJh85nEE4Llsd5Fd+IGP7Mj+RYF5EDAQWzPLaedhgp8MtN8
SpSCgB+XuWVXyHEKoSMOWHRhoN+0HCDgtAyonihcRCbkXsq+YhsxKbVFeTBBGaBgWY7K7aLSxiEQ
b6iH6MEOKJiK5eV/0h0Wavh1BbFigNf9jilKhG2hQGlhUY+2NMs5iIvVbALYYsrI4Dm+554ZF8CP
QwIRj8ymLXtoWBsNWuwuPNfBXffcHepR2al40jXOorqFFY06gitsLCtVBBFUvEQzKNgzMm7EMUX7
YYCmNCiPwY4RcqQ4I72B6DBcMFUAYzYyYT6YKgiouaiv1ET8I2fSDBho8JUKe2Hsy4sgBZyKVN08
SuCaQKP+TL7226Gyq4VzJZ7tVtx+Zz4244/EOhv8TgA7dTsjRrdmnPiHZat85fOFAxG9+Vt222K7
B4uPvNPLFxXlT1JsbD/cDKp1UXzE8M0XteH5izn7toXSIDDUsolB9R85wLqkd/EqnYMJYdxcOjln
2jeUU1pHP9y9Ogo8iJLRNECV+snTa1FS4qyvTZW/3HkLnN2WrUPGFhpbvXE59n6rkbr6nV17m/0g
Tcwxo/E02rTzCBXiOgEt4I44m8eYG4E2VOzTuUICzx4mhe9EF8c4Y/AAb1JdZ7qeS8i2thDxNBs5
c8usFGjo5T5nMa6PfuBnlx5fMXLDxz8pWEHk5I7wYWy8hZZ7ti4EXgePEF2ClfNxc1tPPqU8i3Zj
GtL8RxQLCIwOe4om2DeQBZcATZV8EpXxDsL8x2muGojCvuUuUvqMVeIridy0fbQEtPmF8k0vMCra
jFli0lUsp3iCkewVCcv7gltduHJ5ECA4U5uJHenHFfuVnBeevUtqAd5gwgIIf9iMmPAyxVA7Ra6f
IyxxeeKPzLZcAXh4JakDLlrA6hvVJErQbYqMXG9bvZuLjLauGQXKtbKz1ttttzT4W0hbTUKMJVx1
0wCIwc3E9WFx/wAIMVOAgvoLo6YdZV3eEGNi+Q4RkyttYKFcByxIZ0LZF3F7QypQ1IoXiJFZ8oVF
RC/Kj9RM0eGb6rXwiyNXXSLiHspqEAorRaT4IyWQQrDsuL1rkvmMchdbHXuboj3cN0TWkcaESz2J
1j/JzHQ3h4jjZzADlxSINlZAgglFdlkIBoy5KvI8Q0HbrYSvdyP6in7rKgGOF4sumcyzY/dHIVAL
rLu4EJxVvEdoRKoY1BiNw7cBQwKNMU4Rk9rkW8UbZqyGbsXR0iO5bbaWxC2I8Mw/s1ywEu8RR2LO
0XBIqngzyHhWS+FLlgyIPBB4G3fhEB23bGZ17HYUFuGpP9nbQa3zL0oBoLhE5iVdyriUJ0+4pyLe
rOBazhKEFblvcVZqv5nPQckWgLWFtHiJr4KscZnG1/DLxzFWxxUJlfyBDYVHqO6ZZzcK1VHsIok3
VrkTvvL5mDI1ujcWRHhWyxasW8wbbdywvOzAx8x6gap5Iw6i4MPVb28ytpOeEriqC14eIXRzDylg
Kr0z9gkiqssBABde1gBIFWddxCQiuW3YbtfvsCJZydRRwGFDhNEHZYPxFQVGzdJdVYOmfxKKi0F3
AogWMa+IvpSuAjEBVlUqWNNVStwdtUtSFazJ2rK9ogyG8LQFJqstX6lpipyaEL0x2rK1yPF3Btdl
LqMDbNVuOMNMpHX0hcp2hu71cVQsu6tp8SoO9jLlYh5FgErIPfbHBDsLlrfZE2xWi8KGLOQCoxjR
2f5B2j82q4lE4wwD7lkcyzqocULuWxS28HqHa1XKIko3ZjjbwUMRF2jRKy4N1dRLB2Kp24GxEpLy
KmGzehTLoOXCe/cHUOGRq3LiIK/EXTkq2/mO3chLiJdHw/xABv8AD8Q3gDA5lTa7f5MBa9Smfe2F
Np5YqXRbXUxHXFG9780myGtGVhrcGooUerLZGwMRC0Xk4Orl2/iYdeWqbbt0j5IAWvAgpXpDtfux
giysffEWJK7/AIj/AHCl1vRDokL0uP34xLr5jwDfEGN5zkEsVO85kHKjjyEuTOFQiixYhBbrCA8z
dlut8xyFpeG//bLEgNUsVVWKUyyCghU1LwbiO8HTAxtceUOmjsLhEmrR6hCnZYCNXKrPPdTX7Yri
17icAWayF0j6lvUJHtZF/O88QHu3zHbDh5I8VFromBW4ITRKlniBDla8QpQAq1akp4yniHLV9rmF
AuzJbC+BhnNNHYcR2heqqGAjtyhOi4A5l1qkuiHv5WCu5eAO82IrYxa2U5A/4Ieo6lLFcyhUaZjd
UkQKcXxBakq/DErX8XLFK8cxqujqXC1Xf6j8E7j7t7hlaNNyk4QxSb0C94QqAtWRFCcPBh1X06lu
MbouXp1wsoWptuxDIpixG1cZHRxVRAjTXghZLTAgaSFokeqo7ov5YjKFrWW2E5WUgiLidBCRqvFT
lJoqOSjy1spM7YR+m3TCLgBqlKP3EmByVjOEPxg4+UMbIHlmMdZpL5I0pwQ66l2qz6l5X5rI7KzD
zBrCFqplTpeUOvmJ9BoyXOgkAaAwYkfaQiYAoTHG8/5jFtTlDJbXwB7hQS4psP4JiNWOhJtk/A/S
WPUW03UKUq0oYBzUKcvuITMWsEzM5CKhZMN8RLfMWr1vE4EEol8ly8SxgBxAmEStnAxcnMKxCNcw
StD0Tm46ochGUlWEXuOUqxp2I5915jamLHD7is7S7DGLwURRd3LCnJpkHkot4XqO0pE7mF44HGCp
hVowkAHISNtg/SJIQ1ITQ9UWh+9EJnMU4QWSbtWNS0fgVcEX5Zz5H5guY+mYDA3bh8QkMboPMF9u
h0jXTzxLERcK4QXeajstppiL/ce5JxU6b18xNF5AFyJURoPzOA9Oar8TOyaFcxUkNxzBcGBeR0Lq
C3sxulZfkmHfa0xyY6rUGVHVfpjQeeiFujVtcksNBWHJXUKtFQzYNSCQ8ku3UrJOoccNKudElK3+
JgnIXxH3l4cuBFxo22Kb40Dr5mLxLt4h+Dlat9xaoHAcTr4QnVwEDivBFOILQWSucEBLHuyVP6Ws
XLkn2Wpj8bVj3K9XLW2/UF6RphBSwMfqEkpVbDZE+YBoZyQAL/MPLrTUyErPZQzI1YYp5+I4Xp2O
OJ2ool8/uVoy8nIaIp4qUV5eNv8AMT5xOR6jVUXrTzELcpdLCCBVb5yUC1Fj3FnC0FAJFuwWbp6M
P2xwRf4gG1K3YJgMWgLceIBQdYX4nRARO2S0WC4NPolLsAgF1LB1QC5qAXtMvaB0oyMzCvUXK1W1
ALBqwDfmoFQh6AOxjPVacdTkWL6l1pLOzsECCLFsilVw4C/EccajNTxLkUIPHEKtAWGQdIgBwckb
csCFWQhV1rLjkEqO6xZUwS9BnOuBG1UStOIgtfmOBaCvK6uoOuFR79weG0WyizuU0IareEQg4NXU
sQllyRUaVlfHc39/aNXyPxE5uVeXMrDISnJrIBhdebS4KTyOhC5gDb3Hs0cTabL8LdqaEAIO7UHv
9StB7WGAczXn0JebKB16Hef7AkI1MpXzBqKBarh/ZKEIlUGkkpz/AOqDMIdNCPbl8aPUCWBXkpmF
bcgcrLt7U8NYAoVInEYzuAGy1UoA0A9h8c3M/wAFCrmX8jXEKa+yXTL5B42AHpFKA8kIJqwPJ/2B
xbdm04jWVAHAbUrLF6DCz/s62ALm6yWwhBYp/dR2K6TpgpQdxFCLFD5nKdOojmUOS0A6KZ6oi7Kr
xKMw4hsgG+5uoF4QMR6bWIVlpvzGtUCk36j9AengjyYEArxABVzdoPpJaTuo0KcjUOIptE5leb35
iOSNvqUwujkJp5cGSl3gV8TyF38NxVUIV6iIS7Vd0QE6S8JeUV6hd1cEtub48w9Rgi8jsF2MByMS
wPBDiUrywBW68ESg0viVANX8RTbDH1C2AAWQ8pmLJr+XNcysNBynuJZDR/MRf1P/AFyrvDc9oPdU
WJzLvjsU2crtXQyEYcQ8JTqCFntlgO3NlkBgKexvMDmLklRmFRKeZY/YquvEfMaKshkOScS7rXgL
gxSXdcEOCKukeDOgvIzO2aqVrwU8GVRJrA1NH8z0gGpppANRtUJsIzUcHDMd/VdvmU+hfijZNFw/
EG7UEgtATby5wB+huy4gEVeYs1pWH2o33wwSCkxPSOqhp/aAi+SV9Rr2eIXLHTOuyCc6XWrJxvgh
MYS2+RFSL4MqMXt4HV/MVFtAUEugXzAtVd8EakbyJKZU142ZEy4tWn3KAOkxHAeB8zIVGgKyN3Q4
FkWkJQD55iaSBWuvMMb+TyiKMvmEAaQpnio4BQ8uIteuqsIJovNxzPEoDhRHUJpO0q8OoHUuHQKE
THZw5CWaVFGN1EgEMjcs20HuEgVKU5Yq1phq3NfegT9wYC4AyDBq8eHEU0QGD8QOyNI6hSy265Ib
UvEENS3EBfy+ItsSic5xLHDFHzDXg4DupyxFJVyjtvy5iUNrdc+peoNeClDCpO+1xGBiVCqZWwAL
eLDz7i4AL8EMuUvHGZM3KhpdH/ELQ2aZXpIRwHiCkBXZBsWvJPMIGQw0gC057t2rjcRZYUWIMbtI
2BNkmnECasNJacAE5LKlA+qL8Sn8tqDQuQthG3UinHMHJN9DiK0isZ02HwJkcWMoVLc3CPlRaL3A
De3k/MCKWkDUDNlh90AXRdXLpugTz5lbMlBl3CyaurwlJA7WUeYz5o204yLlUBjhA0DFN26hAuRV
zfmcc4at28Rs0bPI9rFcoE8mcEaUK2fLCuUHaJb+ZR1NonOfPxLZVNEtu6nV9XCksHFcSs40tri+
pSi9kNRVdShzv/IQGTY+ag6G15OYgVYdgXwzVCzpw+YZErQPuEG0VDM4jBCigzjIZTRQ/wAxLRTe
Lof7HQHGh+pYCicuXG1Us/HcsABFA3nJZ4Gs9SldaD15hvXbV3eoUX9lwuczSPbiAyQtbFl1qwQh
4qAKu9/mYvk8d9xmnEXJHvNz7/8AsBoJCnubjOajBHLAuurV9wxF/Rx4iQR8Fs8y3csqHALNDuyJ
uTsOg6IltxKfCG8J3HZTpz1Kzndi76iZqlyekPVYejlE4E4gOEu9QQxIeRnaMgmICOzipq/KO9oR
PZSc+5xtrhx5R3GonCQN3mnGQklBnjCGaUAcPexAwxrch2ghnUmDTPIiJduSyF/IExMrKcl8Sz2U
jbpv5ixoRNkozJaSX6WK3v7lo6oJoV/8h9AkHKGVNtZ20D/hLn9QcooNVC+CrcipVLYea5/MvCVj
yQX2wini7+YzUqW81zBV17fZOZYzwE9XFFIiSBW1UJtdzGynn8Rxx1jLtsoUyo1paJWA7l4Gf1DW
KdeQuNWUV6pi9dQttOancrEdvcagBgWhR/keSCF1HaidjL3zg/5KQ7iVkaLIq09GCWQLTuGdm8wA
d+ohPEuEACzmKqzDmoQA0+YVXej5ltwsqyYZ4o9ENRVK1zfM7K6UNqKFvJLOiVZfUDAWyQi9O7io
NJYnXMQdzKnE6JgNwOA21lWeC8TD89rqE5IVGBR7JBlpaXXOQ0S6UPzDs7QFI/ERVWzZyXOXx3Ff
bp2JzxZHWX9MdC93YbaH+oqHzAQLonhiAP8ALKks1daNdShuDF4L6nHUA5CKSAfHMEEtcIVw3n4N
hXAr2l+Kf6yw6UtTtuV3qiN/MGxQAEs0VLvWynqdwwNRLUyVsXtUDGFVBlQ6qRaBDC2jOiXhSVsI
AWnmFogFVE19Cr4iUlhS+ozAclhLWyJRrJsUDj4zP1BCAcvUrS62EFw0e4CwqLHuUblogx0fOQTR
Cge4Hi8WOtCOcy4MWWLjCd2G+KlYzVLjKO1HD7gkdw0fiVWS0WQL904FxNWnhmOleiM5XCg8xWSK
G7lLnyYv2Yq4b1LRbYaVUEp6Me0orYeYcBgW2w7huDGUXvUuR76hwD9RUZnYRYilf9oUbMteMisW
u3xzGjjoL6lzloHhiyi7iD/IL9yoBIY7YBNHyQVoVAhGLMB5hQ0Cjx6lR94CFi4nmIkjtdsaI05D
xGSVv9S/QKuAsCTMLufEoigtKiBRYFxZRbXJAV8Fw/KOKe//ABKOlwBlJghHZuGqieEC6VAXjqCx
nR5quJTuCwB2F6bk73mEcJX6EDm5WuyZhzZ8xIoodGxogLW7ju9Q8dTvQYr1E9REO/8AzBZQ4gaC
XsuxfdkQleD2gXFWk/zCsVjXxzOjunxszwPOGmgDXxRUzZYQ3ouE6qeBsG6SkdyjRXzcty1UGwcB
A7hW3mWBQKwiocQaCpQGGAEo9iBpmlv5JZdUD6jSFfMITScPmBtaQ83F1q178QrSTKH1cd23DbsO
ytcHNQwEzU8T47V8Fy91Cg2z1LrzIKdrWDBGbTuv9h40ATjBuK/xQkW1WTgghEC0GEtTBPI2HcTq
E4Ag83xWPZgipRy+H/YwVRXBaEWaZFOMh/sFPMHSKmeWA1qLTpUe0VlvHvnuDxtH4ElUSqP1HTRx
H33MSB8nesrIh5/REy0jaXEVMUQ56yWF7ufMtqKrdqDN9RYGdUceeYCIY2fmPp4T87K+ocYfcU1o
reVyDwEFHUKbBleRMNCuW1zDfdALtWVzq4vm4ddzgT/s0ihoI7n+TkKqHjYWqX1VEHBO/YTCrIUe
syANrp5l1KyUlxqfVxKUovdxyhH7ESKwE/xHOGq0fJUeFFCmrwqfPRDWQJQ8NR7gFreNGEttijnd
h0nAGG4Or+KiFKmjVlS9RadJ8RAmoWe45oIW6JTXNRx5TRACx6igli18f/EWrCqwas5/EdpvhE8H
/wBSpNXTrCEpOuDXxBhWk/TCOaiU55Rur5Pnmoz9MGU5BJeKoizUVX1Oeek5C+5ZjKx9S14KPnIK
oLCy3wnS4w+FgL4HbetQmRbc6tBGrEccRL+9XcHXos/h/kYYRUWF7mmuU/GSzqA3b/8AqICMr4Tj
jdXwX9ylcUD+CWypRgqqWvmAMIAKOD/I6i7fUC7BQvx/yXfTNQguXDa4H8ENLCj5V/2OOTeLfH5j
E/5mKDql2+dlGrmIRTuKA7vxKL0/Ub819ypcFcT3/uWUFC/zCv0b6mZrb5lxqsvSFmmly45FmMfX
MqQFDv4RCGi38xcqKHb1CpIhSsVSUDVdQNkPgR1H2d8S5LLp5Y51NPqNQQHQ8VK+yq14qVZFLT4h
VVjbZxcdqwoxhwXvwgFSwkYzDm4g+6iLu3mXlG8XAATblgCFS8IW13AtQI8QJyGC0KJg8seBZAXP
Flx+FBjxkARVgNcwrRVTYwBpxHuOTOCHZ0DHezohdfuUO0Bocxh1GhLEdLr2MHmlBlSY0U86x0nS
q4IS1/qUnwcM5ACNy+Gvtg3BZVL7NCq6mWCxdxhWZKjy1djqOOS9viLBKyvTHaiGhzPMAFhNR52F
13R4+I0iKsPcVDTyPWRRpFPMdoS3XFXF6w8vcpiODmJyiHU25XeZLmFOG+64gmw6U+JcMqlPMoSj
yPWTeMED6gYaa6/EW7swvmIxAeYzUxgRTE2uzjYAGymueIcHRycbNacBRRc4tC342AC2qVA4LqaM
HwIiH8zjFfllZe2pUOj1E88bIY/mOOSFHxNSa2/Fy4CUAPNx4ZGHunmLOg7gHPcqjFAGWLIUyFsL
WWKGqeIwJbFe6lsjS96nbKF3G4hQQXbz9f8A4UUTKlKqV+PtuH3NOjSbs6qM1q2xnAOB8y09lTuM
xWBp8S/VpN/I/uGs3YPJah0b0ah0qfgKhQGAvXuEpAFgxyKdUXMRHBcHUc1bnxXiA1CFHMFgARu4
K3QserI8G83xAM3bnsXAIWUvK1zGRb9NLit+pVGasq3DZQFvTMyW/gAeXqEyw7D1SwS4dF+4StoU
rzL4/PQMwjWkNQUp9q1+o3hSqg6wCFigPeRJqWIO25WB/RdbCjS5w6q4NSDH2gpayCSn6jlmAlWz
Q85DVhkDoCElmuWc7Lgyix4viJDGQ4sqMtLX+PUem1rhUO6xOclCFNB+I4DCogKKg0HqdvXVXn/6
h7Uuy8LKShT5XH+xCHckWBmfEtbbFol+bhbUUcNCIFmIHX/iCBlsB5BhhlUdB3sQFMEcktiIzrem
b9tVerY73jOVaLL+wMbAg2EiIkWhwxtWHnxLgMSoO4wBl/OYjWhaFPL5hnFUDRbY0KXqvTAayR8E
YFbjMFoKd5FKLmvSvE5OfhRfHGSk/wCmV3BYHIIeH2p8ssj7Ya2bLVI5SSqDgK7w/wAijXMqVyzb
qv1AHxPlvLgM2lHkOpYJAEyElll6HqPoqvbnMqOnFpPmNIYB7ZcAKUW12VxL4D1MoEfKzRfGxqw6
nTxEF7IrPs8QlKAXpCBmj7EQY4GlSAYB3Vp5hiZV1pU3IaWUXlTKc9NgPUPBt+hC0qdAHqWPsVMB
yR6JLbgFczYyuIF88xFB3KbeI7vKT8b/ADB5J1nh3uD0cI8A/wCy9jWxXgPErBXAlrgHP1KBqEAa
IegvFYFMqNVkKvHyYFlQ5lGlSyNVRKZTnK75uqYXQtXoXrAZFBXzRtw1YCuCjYlBTROQqBeE0XKq
MruADdwz+mXeH/SCjI+RH/YP0kHu/wDZRUd2CKBdbWoefUabgeA1FwEdnitjbNN9hUGq8r61XEEO
Vans0kWUp0eqv+GDXkt3Spkbyu7u/wDZnUvRyQBc8AB4l3GZbdoS1dSj4N0SpdxpffSXoWb0s4/U
d3FE4t5goGtPOrr8k1CwDrmN5AdmAJQ/iVNjQQkcX5lOG1gxUfF+ZrVylsxAY9SovnQYi1vqFApY
wxbgqJO1sbTWv5gsHV9kGDFho+YaLg/KA7LO3nELk1NJLRoud+oIExbZD/LaTmGNn4mqEb8ll/LJ
R9Q/SL+ZQEaUjQrLsH1M5np8ZDa275lxjj3BGB9wC2JqhihcHnjYzKq+IgUOvM2c1C1vELuqBwhE
LxbainsLKotbOwov1Ah1gC5TqgNpeJDY5fe4eC2FWxHYml3cOAIqnkIHTvS1z6jU2Sy+nxLN8IMO
RRWWljw1ABLBSvToXKReFuN1E5bY5prj5hoTC1l5EMGVZozIpr0hUZhS6Y1BSAHxACD6XkgYG8bR
+DGqxSbdHzFGbatxES9KXCdSuh5lAjQ11FysKEYWUHA6mtUw29TAuwVvcSciN1rCmnvGG6eT3FVl
0PBCEcGhgzl1z74mDAnW7mBEuEG4KOHq5SUVCtl7c5eUHAY1dwW21Z0VGjmIO5SQqo6ya1OVwffl
IGw/eOiiBja4IYLC8RJrFgfUQ8OhVzAwIhXmE0KU5lIlA3ioUFTt5I/O2op0+o14sw9rh6TBupQs
vAXbKvlW38SoDbYIl+QNeIAKwteeZU8NUvVyhC+iyUiuttOfcXRg+G5AMFUN0QzROHIeEKx9kAw5
bcnqUJ7A3jIPIPwIPQ4ne7yVaqs5qKXALLYFVu8w4tgRIAaaH8Jbg0fhOGU4ckFajsctTWoyjhlW
vCvqLFpAUor9QZBVqtnA2V4C1A6gI+kxQWzEYFN18dR8IaLn1LQCDS4ymV0OY2IqffHBLQXjJXNm
jCKbY0J2wN0tlOZywwCbS0EVtg0DSZ5gX55np4iAm/YoSFBVbqqir1OGwpdj1LshiEA7lXUm6XRx
OgD1fF9QWLVUcqAaQ+6KUoAvhkp1lW48VxgwcgujjxAXdwvXyTVi6ODYXNz5GpTKpABtB3B1FEds
l6gDbNEdKsFG08fECUjYd1eY5hMKcGHItQYf7g4U+1hA/hLJUYQ0SixsRswupo9RW14XFpXqaW3B
8WsqlaFoFl1/LjUR+EUOXKn+UAzzALA3BvFILn3L1p4vOYsUF7C+/uORVPOra8Qmamo+byBy4EHC
cfMagLe8EQV5oLKYcSJCdO4AVeaAc/idgfHlx9nvrKt/2IEfTtUssQSpdBPK+TxExI090eCFiAI+
JZGOHxDTzSpZXNE2A4KFnzAicnHDHSIgvMMq1UsP2h4Viwf1G03Gog2slOncYJ8UTlrWOjuPFSDw
cNHZ8BuBU21Il8xwqp4apE95DehAt3KuviJzAmrGn+y18iW1vwy41S8suAqgA4CXuZUM1Tbl1q7b
GUvo0PLEnKLVMCshgTZC+CS0LjerR9RrCqAq3ll8d4j33xLezw3ccCVaaHqFRtLOU1nMTop1GPiN
aNIwcoiSB4yJzQKLR6hMYeLtx49Vy9wQWh3o/cQNYbPTLr6AC8eYEYwo7BAQb0VA2LUAEO6l7ZU9
0OTmVQ9XgGVGfRVoW1gWprzeUyD4pyvqPqutHRH/AAtFUyJeIDqt+buZxws5UVv1E5QZMGRzlt7a
dcw4pSuAaqImo2+bNFUFZbnIAEwdLE49S/bZF8eI6fTlhBJlDrfMYWJUuIAX+ibFbU+Zk7FwTQdx
WWuJQ/MsnoQTuNcz1QlQKOSM3Tb5idFrU0YNILHk93F6sR4+9taKPoDstOfzDeGiVWrmVbnZ5dMX
4ZsaqkEJGsDgl0hMocJvF1WjrzBt1UU4JexHwhadVj1GOhlKGcvp6lgWAFciNTpsTwxhaJYE9AkK
oVUVqEqa0V5lClLLWlHuMNHHZC0OmHkjQA3cGW99wBs+EBitYKF0mGrkfNxEXHByomOux24oxwt/
0lfiK3FCPQrCAkc2qCQwUeGSjsLEuJcFWBMjhQuIgc4AjbHgI1BukOAmsyFbRiYXzFdwcDmWRooI
WxI1rwxyxT9Rlmp4H7m/NujFdHd2sbmwNf8AxHwKFXxUbrS3svo9g8wordPcRJb2eJdH6KgdBQal
aO82yNvXzdygoLylRW15il2bs2FGoOBiBgqL/wDY5aH3+oSKOjBjkKtiCuz3LeLO2VQVODzLBBwv
tGC0W6uXTr+QmhCeEFk8zmeIg3U7zGlMpVdMryPBhsnkpeICoK9wNRRhWQsAOGxUoseeRJUstkTp
8nqK8DBDn9zeKM2cwvfM7JA8g8MRqrzgIRPo5llo6XGDMK9RW5yLg+qcKZ1JV7WmUYaniGhNhfMB
qUBXDf4iazW1wyKE7t8kYRag4MxbPfn6gjhO3UA2tXcei1J0BMjtUryjd1cr3KIq2C4wz1Joh0V0
GWQk2W5mgHcwEePT7u4GoB5nSh9IPzKUxKotcDzCyo0Aoq1E+5XoK1LZi2Q2Gh+oKXuqKa3zHMK3
Zwjcr9kJGh/cp2uqs0HuCVKAPYcU7L6gYJUfAwWgXngnYw88SxG1tYWgXB2F1NVFKMdir3m5SRUL
05qcSj3A2NupdeVNuxgHXa5hV6CI+4dNaQtn4ajhDTZZy3MGvkYqRY7OGWib2q8y89T8e4wCydmB
tD3yMVA8DdlIFvaKkULFY3wjLnELl1DKVN0Xz4j8zCNM7TcLodBsaoIBj2j0CvAEU119wLXDyme4
mQrdD/zHSosLTUMXxeG3cFwL1thd3CtIYufAXKxYHFhUVKXh7yhjZ5DuDqx0aEXRyuluHhvyrBt8
CqLUCviKBAKAZoynOPGmWhILG/iVLaYoqOVBdUQIllreAEB7DADN91NQmM0ysf0BbARExXNW6j8H
hbzM5hltSWNuviJBwR18y1hcNcWUilfDdqcJUC05v5lYtTQEohTydsF90NJm9HUJIf8AU4hh2aA4
jVvTbYv5rRqMXDzyQBorCdYeTVRU7UfL7mFpus8wQIPFNMJNM5NUiWg8q+MWLFfIRdyUeR5gAFYK
j5HkD+JemtNM+46UbdTSR6RSML7uuRGdDEmvB1NkFKJrI+4i5oaG8CiUFq2ziUI0+ssIWr1CS0cR
cHpbS6fcbakqptgFjWQm8i7eCLGkWjE8q6AI+w1ff+Smaw8SAuNb2DrIYM40FXMIFDeQCEUyWLpF
TMvDUuadz/FLkTfmIJJU8R9wLS7gCXxClrmLT8S/CICABUCEAJwEYuI3xGgi667gUQBg11ExFwaZ
HUU2juAxJlNiiT0m3Iey7gQsW5BHkKBLhQcDLqHF3azueD76Q7e4X6hEIiC19TFPaHzCxqMzuNg9
bRLm6snhvucWJYjZT7i9Wozb5HmDUhjYqx6lhRd9yh7xOCAw2PUAMKlnMui4D8zuAzyLh8UVpWyr
iPBA1q3RFlV1wfuOQccRwVt3AVfIVsldG6tDzBehGa4LpvqbqlNQrRT4NqEZvahHlXUg8E8gRwoL
rCXI255joQZbnEo1XyqX3qaqP6SajmLXtISpEbWQPdfnmMTpzZAT3XbF/wBHosl2HiKqoznC7C9w
O1LHKiWQh7JGXEhgTgRswjUA5ERSjxEai3xZnaPlAGTgAlya9QHpQujKl9gGDk2p3VHbFfb6ckaU
PeNjaQZ7itu0gyHFfZD/AJKZ579RKw0A7ucBYnRCpbIC1pqPcu/EJ3GXJL5VsfLRSrgjfLxL0Zd2
bOduFwVoBbKphoPEZLcT5gQVatiViu6csQJwy+DKUwcQiYnonx3GuwS0cQ6z2BMcBo+2Dc4ArCGS
Au0z5hQNgDz6la1A5YvUTIscDeHcRGtQogFa2lcDMoxShYsyhHo7Kd3gXblhrirA+I/KOgqgbJxh
iNbS4qU4SWr/AGlGByYs1pHSdQctoRLW93KCo0S49GnFazF5FDFM9o8P3EogsZ1NxUCjLKAB4cQs
8C5zTEVMiezxD3Sh9HxK65Vdcxy2FoSB8V+JSgDmgn3OZFqTiUj9NYvnbLUr8HSAoVtB+5d6FSTO
YUrywLPUsal1l5K2uzwGYAcvMo3MWUlZqNDtSg5NW3E2WoHgTPz6BKVl2OYEGmhrks5BS3l7+I2C
9u79xMMomimMXVQLLuK8L8c0yqK2t+ZWALo5/sCgDaawwFytCfdweBczf+zwpB4eZSdaUYYELDm/
iBqoLgPE4Ngs4S2Doti5Wonl/wDM4mBV+ovWRqC7jbsOFpHA2orE83D0lwHLHfbCgvjwS2ELad24
kMaNWpDvgYXMuDsgXqCmDw98RMFpwf8AJsMaAb8ShM0q52ZvVTZIeIg4LUNYRM6NgTgTXh+YZvvQ
hPhYr9QvfzCBxkB8whRp6kfXGUbN9w9F6K9sdxdiUyoCLyUKfUV4b6muYli6Cm0wwFWmFInPYkWD
wkW44D0PUK66zusMJ6yqojOALOSIiCgEIvppd5RcTTVINMgWA5QTTZEDj3DRjNoXS6grgo0gdgwD
avFn3A4qLBxEeWABQ9zSIxFL+oEG4Gt8sQPV0/aWY9hqn5jlRHsIGfEr6B+RCpShFK5IsJJxHoX8
wOMexwCGkC081Hl9J1XsljTQA6COBBK502GkkKvBkbnJTOAPMu0tDsDSoqFpHxsKC5AacJbiOxo3
SNZgHjkPaegpuJpCHmOX6gcdHDetfzNxi4virlo4FMpXE4Kjr4hK1OA8WS+T2gGlF+ZUTKrgW/mo
3ac+DUUAAX2sLIh962vxAmhL1jy/mAbAMTiuP7gkjw0oWQZbuovh5lzLaFK13+IGSiKApSinvYVW
m5idLZptOlQLyfcBMpC7j8RkcYzV/i4wdWDkfmJYIRUOrxDTRfhFsW15I+yn3GYsp6mTkwla3B0u
aSg8VLGcAsbmgSWkJVB1cfEQWz8xFbUAiDuINNwDwkv4mbAErDFip3SVsCQJc9XHNzS9s5gjlKGJ
ayEPGwvY0OPUNDRopBmlAs48yrkRQd3AqGAfClCC2guH0AuthlR+oS9PU0ZazuBdHhmQ5+oqBBL3
Kq+KlpX8yyS6HMHKlUlr42cICL6C+JQTUBWEdssPRLeIoDYoE4B75jdBydLBOK2wp/65XqHS67hi
jtSfqFd6UY+5SjVgcslWC5uoJmgAUyktS8cEdNvKcvmDwsUtQkdj5ThJQUdMDJLGw2LYQAe4QG2g
PUYXiwp1NXxV1LI16CZ6Eoc7x+oXE15UarNabcPgwLDiBnu16Qs1BR7Y4AjwjwgmtCrlc/plZAmS
MAMfEwnB+RAuKCCN96Vdx0kwKinyWb7QRm6bMYRABbRzDlra+Ec9Hs4i3lwBv3C0ofsuNBgcVPLW
Va7UZgHjkBWJazuFSSovbfiGGTvRE3ZwKglDG2c1B6FSEpBGufxGIcDxBfHccVpAfLK6laRxAZ2K
B3BVqq4S+JhcuFA6X1OiOCXzkXg22uSDwSryUZ2FhDwREOGtqjzzKqRofEQWuxRAbltSe5kwCi9e
oSuKB/73Ofxh2uDIgGBUAlBt8ib3aB+peIbbCifyHOojGhBKqG8akr9srSiwj0wfMiHuJVWhsc+o
EqGoyyowbUrujHCs9fzBpCOPG8wRjIQzSiWnqpSUeL5hwGnCuIvUW0afuEVG23piqi9Zw3zC82jR
8QRqFAr23CA0Cg4a4jSpNE2oMmGDj4hoctV5gagrnS5UgbO2viGkiIGVe9xIttoKlC2II6h0jtns
rYMq5SujzLaakclXcBel9WmcXAZEX0js9jMtbXUaYLi+OYQTiZyVKqNsOeEEcrIRuBtjhsv3A6Mu
XcIxHGf9lSAyiul8TGjIwUlqDqFlIseQw04NxDxG2vGZ4l9aBvVB/wBgFKu2l1wQibiPfllZkJeh
AP0KHl2FLKlMuaZ1UMq8l1IAItWoMkUBXg5nzyIOw2yugDM/7K5Vbdf+8xd5QqPbANoF+clMSkV/
KGANaFZUxKg3WykAj6XxcHwtVJ/7zMwEeRZcCQIseag00L0K2O34NyuGLdeUeLmq3WaBT1GdWrXJ
tBQk+JRjYt8txy2Y4q6IK1gnTuESUan/AL8QpNex62AlC+jvqP8Ay93iAZqde40DUHniJRJLVFMb
RbAN1/8AkIPame/+RDFabWo4R9pZchF5jQZT1WcSw04csCgYcDpAvbzNYrPk1L441DCL9rq/MqE3
T42eHMhjM7FF53mBA7AHOzfAh5piBCaU8/8AyNhBaxxVS8QgDV3f1Kyrkwr4h6roTtDm1QQ5WVHa
pnhPtIXyxTVWQFku45ifweHE3DZa86htSuEcVKerhD5/yGWKDrfMBQlScxvScJjhxDB1BYEo8RCq
fQQajuVMVUpEZJXGlFZLzcQtpSGUQRDjETgTchyQ/ZSlkq2ggvXQqdEFAFrA8EMDfYLyoEe0jX/p
EgAE89vuOKvjzQU/yMRUWy/F/cA/SwMKQ5K6jo0uaXwDahFBq4vQU/zHbhmA62Af4tumbCLZg9T+
54AdJreZWxcvWb0gITKrVF4ijIJVwsvoNqQf+EQL1sOB25k8ucAU/wAjKhseJQp9olbJW4U8ZKK7
fmCoEqLmkyp8ZyijlgvUbzWWbNnahKWnOIo0KtKGFAA/SEqj5M1EKtKPi4tqsoXx1Efd2vhlXwb6
S4fwDhuxKLVqi8Z5tl2CjXzBwun5JtxatYME8hL5XIPzGdgCPHiEEuwPiMGo5BlN32xbtSovBRBy
wKi3PbqBiAPcEXsihUv3G3HD1KU1R5llU2LQSvibUooJ8sAohQfcWSVpCCb6LPUDQUW+7h8LXEtX
7F3xFDLBJxY9iJBQW14gCFHv4hqAE0RkuxXjBG35HUIY2LgXciUQhNYo9RFCiq8mR9hoz4gtFVye
JYwBSe8hHgtkGAS9Fo+Uqbmi6YNEnHH3CYKoNuZdNchktaC0uSgHf+TgjFkqZSGv1BfimnxEKAuj
eRi8fsjvOJJRUUIVRTTdxBrV7JmcHiOuLbV8bAS4JID1XdwkaVtR+XLoePRt/ctqF2+IJUoovpuC
85CLMVCcwqtQI+NlRYoAfESALX7jjgi1GF8XzFJKVpOWNSqxbhzCUECOHqeGAW9tcQtOSB62XU8W
8SwQUwSXXsjqaFZ1UcEWcuyVgDVhXxHPAOu3YxDDtYui6ZL4Nrna4Ya3+OFRyXVS/wB1v2l6gBh1
n+QLUcn4iT0s+J8tmdTlgRYMAOVkt2G8OkBWBh9oaO03Fp0294jE4vFYnmJ0KSBa8GQs+iPmr5ig
nKLlaNCX6uLbTpvuXdJgxO6LVsO0KwnhZ4mmzneYS+pEdNQSSxdeC4lLAoTgY2e96fqcgCi/iF9A
bixmMwT1yRjJzS+5x4GrcSrkoVRyRFCsLCxaxzAjQGxyLg31ptMSbBX3Ep2FC8/EZ+g/+fqBVuyX
FK17qVBW3B6oh834jgxrX4mmg293AfTKhFz+9nKbXLxcUatknrIOVbiMBcU/cOYv+6UshUKYB7Ld
gspxs7jM5dpX1OpgVHkhIuhZ6Je6BT8XLqjbSyYJoW/uFPVjTySz9BFgtBfyEXKLDPMAdSVr6IGm
07+oRYvbjjJxwAqVTx+0WUi48/8AqisBUaPmdCUP0nLVgufBN8ysHqUPUJ9TjMi/qn/IXARxeZ1P
ivqFB0q87Eu2WCy9l/KpWAg8pYEMG3rxh/kZ4UI3xMgoBOsZ61I/EqMOA9WwtIqob6hCaq/condX
6Qryob1bhO8CPjYj8bD8onesJTd8wKsCrXHMQzSAX0BGz2iIvj1GCugfUyP/AB6CsApObljKx0er
YTcK1fv/ACMW2LsPCVuq4OKsIlVzVH5lgB3X8n+xMOgO2f8AYm23C/d1OHON/bFXBAZfMMJVNeZc
TqVfHEIpDQjOIqhfeqAFsGkbaguPuPDcz1DuZgw2hE2+05kt1XzNUHGfUsBtU78R6YvocdRay1Tz
TEMBQLYK4MZO9SI4MKKvk5/ErrB+iM6OG3/3iIsKw5UdqBuA7HwQqUii/RDpNEk6MYClMAccZVdV
Q16ub1AsPWsFmo17b39Qx6NVfhCIcks9XNvC2xRmSt0fglXMuj70mLC5OB4lY2dOLU3EaxcoSCKs
c2woNSDiooRpOJzlTMLOxhxGrUQheeYaBTmmkCGqDxsEXwmCIWNdgTFTxEY6e5aTLMJXrMBrhyGI
cRuPzZAsBlHDbDvTnjySstFSp22ZCBREB36m7KOo4L4hxKCByQ+yCr8QveIvmUKA3Zzsflg+o6Vi
wguq2vmJvDR+gjtQuL4W46VmQipHZaVUAJOmWKl8L4qJr9Vi+vDUXB2+Y41z8QBPCxqBdx4NQ0Ks
51lLwogwagKc8bHXKuKAdo5gvoa/mg+jIBzacwADdfhzGuVaB5y4A028L4mdFV39R7SuxxNslqPx
CjglP1Vp8E7fRun4hmW3DONqU3FIIX/EOSlidzhQtFRmjWBzUzyClbzLFgp4+Jgu5eNiCrVPfxKI
tNql5CviMvojRcYiCNxAJ0ZHyXbWAloCUR9LebiPdYB3eEtqHGSoBWyoiRaeYTVaH5ixArm4rQxa
iEZqMSrhwuOALXELbTYE5AqVcdSjvHmYdJtni4hoKWxT43yzsGcIl30prjYS3pBPMFRGjhYHHU/a
Ep1ylYgbzYxJV3PEaPzLYUAFtzRdltwF68x9+UQYGoDzUYZCsdFwGGIL7O4E8ENaQ5SP4sGxEALW
4yTToPUDO254LmCKIjMkKdIcA1QVesW4NOzm5QRkAKA4Oo+pQAxlacNeI/LSSFbSv90QIEqkFtC1
PUbCXaRFSNnfErEMAncWZVisM6TygAuu4aGXT8IgmoU+y5aSbp8weihT/KUhtvtKaW8fmJAOaPuF
rZET5uCr4rPm9gkXQ+oyxSAOW5V6qnyeYwQh609yx7fPjuCHI1F7eR3PBo9LcvCWgKdbFXOR67l8
PPN2r5hxGgP7lHODUHMRblHEJqlVvvmEAsCfcuIUP9p4XAd1f+S+VphOfMYduTc8EWVBYZ/crTEh
t7UXqpazxewQRaKA6NBXzBklBaPPMcDnJ2LCYw/lHExVhhwIFHh2PDBRv3GwALh5lf5UpFFzTZBL
KPy0C+AT/ITdUfFVXL6hRrrbITkLwe4p90APict7CkMUHa+SHaQqPcECGgdhkBSFonbUMwKY+7nE
ph3JLV0DouHwCw3uPbXQr4f9jwippi7jgLSH4f5KqEivQIutCY2IEkC74BGfTI26piIGmt0LpjRq
NwU2yC61y+Fcm0YFuGygNYicahR1UukAUOmVKkdUue0I9lW3vEU4hm8qNTN82vG2QhmBXPE0NrN9
wDyxWvY0wHRz2CnNVnqpyIqh2pzeqX2YUlbS7iVIE8wShU3udzUFJSW/MPzWHpSbFioOL6gqaZ6G
rAkGovZb/sGedKlvpAeIfoZmkBA2Gx3q2xnkplaKtautyMhmGhwX8xd+cV6c/uWWksFFrJR6hWBQ
aY4b9lSiYtPZN+UhHL4lnCKq8xb7047jeROXRZUCGO4OtsDKiWG21/cA5tpa54heTmusjfVNdV8R
pUFsFSiFBIQYpqVMrcPBI+RMbbT/ANcAsClg71Op0UN21TKctEBGxhd2dq7f39y16y06JbA9beI5
oUhfRkGOEY0mVv5g2mjJTXESymR0r/souRYdBAqQBt7VfzFXBk3Lt/sFm3+Ybf7iZCkl+jj8Tqgg
6dFy/wBAF1RyPfEJLekhX9yhim9mdRAGT03xn+xJlpZCj5mn/QKVX5iNx1Siq2CUDQizXMVm0Jrq
ZqsJURh0RcXpkBZtRacaxFWlh1EWUz5JyLTqLQRrthhTDlLKPuqiAl3mS0wfeUqgm4qrnNdXwkfV
aNn8SgPcB5ZYvhK9XNBUAJNxADuCZTy4y5bTkgkRdpfGS/A9D8xyNKkFeNo+pRX7msNkVVr1FCQ2
niClZkbX0zgJeiWiDW0yKN1fieZAYfE/KCgKX1B2nQvuYBTvEZ5WhcGmpbaPEX5OCiy20IX8Qauj
bfudGH1ihy7Q7csqwivb1A1leTHcugrQI32uEGFl7zgiqC5tjQAFUuMjq4osIieoC7ohqu+mKx6F
boB4gGx5XCATZrqDS4bQxxRqrMzcA2MuuEccThqAuG8wFagPmAKqUGXA6WuEjdz03BjYLGyCmhXm
Vu2Mt7YPszCyuJ+syWkBgx9yoBAG2mE8K1PLHEbMqI1ZtZURTPFlsCBoYTLqAGfs+94icj1XxAyE
cHq4CBDRd9xwgXW47Fm1BKpEtF6hhMYR3KGRTGEeMNe7iUwfqORTkK5C6bl3OPUUcjgNAekliEob
eoygNBhMCpyPELdr9XFjEaKweJ1cOLheJpTkCBeK+2IXDfY/MBQQtVMB3QnqCNKsqS4c1HBAoHkb
g5BVL6hGw0tCB7p4YRMrUly0pztCHmcgcziUFKoTO5QEzERhyAUyEd3nhQtujipVGBoPPubhsKp7
ly3ELxkygcSY0uKSj1BPy5Hovib3BgcGZpEcHZ3njxC+YEVI0JsbsAt8Qc7QQ8wHvO7sXhSc0dp0
fEwx+1i+C+JTw2izi3+YQAOC6IGYEbAeYHNCgwviLq439pSemBgsvI+IUYC19I09RQXA/LsPth9C
cRdMYIL4xOsC7HCKtOX3EK5VLCWyI9q/ZUJtkOG0l1EkAyjEviKWVXda6bikjGLuICFNHZcusSwc
IMl2pN+ZYvGxv3jKxoCumYX5t5LlpBhtxK/d5NcstNcMXjiOc9IniJMSVT1FAEbYGdwZK0FfPqBg
CrU2LR2jlhwepHnu4U+LSnmXAwCH2nLZax2vbL9wvUh11O2lK/cu3M21z7ltxUotBDm3LFxi70UB
c2pc4iQj/wDY8qt5aOWUbcklyOeYK2MQGluZfR7jkuKdLrBucN5ZoiU8cXX6jK4UF93scw1PY3xC
a+iDhqonQQGrfaImRbvlFLXjdCuIv8AEHqoVkKu1aXeUmFV55irYNeFxSIlB5Y6WOivQOw52NBb5
5nLY49QEy5S8pLm6Db7h25CapzX1LRa1U4ezzDknNV4vI6AKh5Sl5C21r8wzRY29diFyrL5iep8o
ecWeGDVb3GjJZV5iwFg1hvERVMQd0Nj0UA3G5G9WSlXDxBNzb1jd3NIt+GxWspg/hDHogK7WsWH3
uLec/iN3DyYHczowrD8QZhhC2iF+Wpk+4zg2AfoycsEew8RxlADhGEULYq778xI80rsRia7PN91c
Yq3yo3MDNnXibMaArYAUb7qahFU8MJCXesWbVj3qeOY1Pp0U64/ERaRpgcdBpu7IlTaWgZuoZbpp
cq2nxxLJGz7ACzY/3fcHxLYXstauPTeXiqc5lrYUA0WuIvsBSDVxsxV7oquPuMusmKofuNgQ3rrs
Q2DA4S2RgLF/zGCpCKpiT6bXyzBS/MGudhPD7iPanMUXF1BVzLlvJNgur9ZDyvPXqMnLEIA6hVyg
15ub2FS5NuynKQ62CzWsCTaandlrZm7GTV4Tl52M+TUfU5eTNNKCpVrYHH7l4FTaSvxAAQGcENh3
J1GaqXXX7hWCtS/cSbCOcZzzNtJ5FjjmPmLTF4Q3poZB2XXUo5V3wSh0wh0cRuaxabGoa0nI0eoi
LljbKeopsg48xWBop8kIpWuF8wzyn8wdV9yMjUV5x2Sd14g3Nw20wCksq239oLQFyYDeWs2UA4rx
QRbsU7iuz2cxolfd1D6wlLhIxGq/Z6l8YrA5RzedDR+ZeEja3Jj+N2RfhXu3xDqBOMYZbbdwIuDb
sCvF05CxUVy2AHIblb+KL5/MRKHVsDpG4sDKAG+O+YLVjQjxMWBsWNSE0heYLWDEY9QOi8h1jG8e
Ia9Hy8R/rtsxDYeYRbYpOUNUdaqNflLiFyLBpgMDkp2J1X93FK1wGWv621Ewps0GMcnzAViVhdpF
cBZLJ28XCdmyZNRs4uISJ5OYsznJ6jhK6YcAOivMITgBdpAYXocRUexbW2G10bq4yZBx4S73prJS
CNs4hmnmtu4yEW8ZYJXcimhCgd/cVoE4vmPG326uBGZw4D4lIQFbz+4XkbDxFbIeb2GlTB/IlehM
55m3aNsWtDQTxkEjCr+IzInlgo1odIerBF6jMzTWY3jiniD3Q8xGAu2F1GuL5+ZjKKQmqMRDMQch
K1ztlxcOjXYWGjvFPEOY4KGQNt9srb8we72NtSpWVecUS+y5vb2ZBmG3j3KsqHJ+8UV2q3Y1ILoj
sutDcum6AbI5VG5aCx8AV2tgoryW2xP24nMf3HXhFodIecNUnaXYAAsmR6w7u/MLzR55ZTnLa6Px
K4F5yvUdg39wsq5dhKY4cGngp2MQCtZa7ClR0Q0jxLC6msusj4LNAHDlLgwGCBqruBsDboIqvY9T
wDt6shS6oGsyLzPWww6uGRHggFgEcP8Adj0bG4TOtoNXFaB5X59XLqm17IweCNr+pe9ZyJ9MQol8
zef1yRAe6bAUiBwm4lSbTj+FoED3HADcmGNt8kYCXG/4i7/LRBPcZrWbsvDZAbcHQBLsyYYcaTcb
Utr1OwZU6+IXRBjIPbb5uVy338jDyM9INYrzxFQHpLhsRcpz8ynhx1UVJ/MKFX6ilULN1fxASnEH
uKXAG1dfMDqhfCvqXdJ6HYOeCdmX/K5TKX3V3H7VV0P8w8dh4sIC2NDh5hMbioyXKOy3wRME/MQq
IjJ6oMlMOtejAGGzvqCiZwCjH3pYSoqCUnPqOm57wi4V0bKQne09ZpnkT4GccigJcoauFDb3uGhb
F0iyzT3FwR90UwCt91xDd0LOT+J4a+7rzHmcOQ/Lc1S7kYO0vjYhRNum4b1BC67z3DXUCMalmCnE
Y+CL56hu4haayxTkPUbmpoOUEYNjdfxLQFE3Vnn8xwHCAudA0hyijC3gPuEtZQvcA3HQVjfmU7dV
F21EkrmiXz4/coLt9xUYtbfrJUgVHdyllgKcniZTz/8AgKADw+5a01RUK0wc9wyXJ2UEodkBACly
BD3dWRciuD3KJSfLucOAXVce41WrbMJ8NByjreQRCjd+IUaQeOIdLyQjfVPLiD67cx3Krg7BVRw4
bYxZA3GIJARdhOJb19yg7b1BtPmWA9zKGAmpxC6W33B2At4i1wlLgRhUDp3Fa10RgJ/iFmg5TiO5
UcusXCqPDxNC4C1zBaiIN13B11DMlALaFE23AoOJcbUNogqWTzCBUgjUvSorQQWkqiyUGlBqkoCz
axcbp2rUJ6g2WVDZNcg6PuPRcciGg9NiVZyRRaNzniLasDSU9IdH7Yd+IqTIXxzPowHEOmrzeIwh
Dbi2BOBDHtS6OJQnBaiXBHzFx8gTpl9WQVSWRYwPPqGo0j0bAafLINRjkeYXZTobcLXT2+fMraqu
3D4ZkIwAllFSKUiCwC8KvqBih9ISsZqhN5QoqXyW3zGFagkLYe/UqQ7TxxEtYPMvYqIqQ4glnnk6
O4zYCwpijGgUSvUPtKclssDTBoAIwitx/VPAmW1AcEv1sCtO3DQLduZEPSPbC5ALl18sdiGGcy4G
4FZUOTpmFigbRYlIs1cAc73FRnJRWMKTwQJzSywOmm3KCGg5Lheh37ikVgWyAC69sHXZMoCNx6Ae
4tGkteEXkXgLhQtgEtIWUFsc48QanSO+ZTRdwRGnkvJLQupRr9wsKcLCrmISlWYkQvNZRoM2F14B
fzcGiLIW34lw22HXmvmIBrQM1+pRiXoFrF2DalOPUU2r4pzvEakFmzU74h9SlY4hz6aB1KYHf0fM
4/g4LY9JE2LuDjClR/Rko3BdlKfxLeKtV4jabgQkpLk4ruXjL6FWQKEijm+ZyZajkLpBKPc7hXo2
xSC3haQTUlODIUFrg4geLQpcxJg1cB5lgsXQtgocA4z3FYdlCyozAdBtzktgPAfUAkQpC2iKMrS+
YtxjxPmbQoIF3UPCxbHBKyEDypWJaGm+zBaU4hq/Eo6pTzcbP5QL8bLoq8LHzHz7qFXbli/B02J1
oIDMrnJcCEqnXmNlccdRfoV4B0/Mo2FwHfNRSfCtftAQIAoXFDmEql+q+Y/RVlPJAiHSOAxIw2UH
+ogdKgyvMQXnWnqGIgNNOwtbJRd8RJYaj+4nIriuX9LjKqo7bT+o50W4UI0gBYxHftjTQeYHtVVE
UVJVTfiUmSJV6SnQ8HLssHPkigolz9iWErjKXee4Lo+pgh6hLlikL0LRB7h8iukSrMJtwC7xX5mF
TccG0XBQdCfNThe3Vr4g1tDMXUsbgLcREng/BFEFJ5seZdpOVm1f/I89KIjbG/lYjyQUdSx3jGda
xtrKfZ5V2OXIsdriRWFxUS8YEW0ZjHggREbR4Zq6GFVrBCNB3b55jLpRu+Ev/iUOd4YqpSMNsjiA
oqCJ5gYNbOa5Koq5+x/iObIACkIpBADbnT6lJcOhgQS6nP1MJpbemX4ikHdgtuKmqWwCu44AMQpY
Ll4UC4F2DyI8yv8A5LrYCqFa5IGhXrgT/YPCIWcd5/UFCdwFvXERiX114o+o+NegcF5BXwSLWd/c
IQJkY4bCVHwHgRw49Taxsgg7OouWF6jOamcRDNc4/UtrAX0MyRwgDJd9wKeTxBYrdbsrRC3xEsPE
v6nWFvJDpesAHJbIWoFH1DQ4XcAy6A8sHEWLelREVaEC2c/wD2wc3Tg6IlMZqnLF1bhfI+InxQfK
l4SNoKfmDbTYFi37lTDGKcMoBQpBAw8IVw1Dc6cAruanQJUK8U02yogioUiNov35mi3PMsUbOFpy
dk5mpRezm8D3FbeOIaRvY2Oe4slyq/5hoF4ZYIpt6jTg8Okm1HCcYo11opxcU6o28iMI8PQlw+F4
Q+LaDxzzKrBhkW4Uq02VsKFrsuCexWDiGiXueISy94ELvG7CVtpxSrjLohXtHpHFACMOefklhNqk
7nc2aEDWnRdJYScCjfzKhS2tOIhd3lOonSKrdqlUNCh+oepGgQc5Bte9GHcvjZbdWQs9xwjSFK4h
xdODYdes4IqwQGuHxB5SrCGudy4gIAA67gesFGtKJUi1KmH7gIPRXH8xnAWmaQWVdrlytdo9xeyU
vzL/AO8Kh4Aq+EJooLjAkFZ/EasAEKI40A6zh6il8kt/ktoW0S5CspCGSHf8xqqIui9xk2Rx7C1/
qYQO+cNS31LcwskUMfMVxm4lCScFgrEt4MlxSiqu8/2CyKbSo6AWzCHktBwjcHACADxCvbC/mMoc
odysric+o0kGbxHAFA/UsxhHIge0LVirqKNbX5yKmKFTPEQlSYpsEZcNpvYV2sZ15gn81vYFgFhn
MRAR1XctEc8Oz/5BFTSLkCRasqWYF3Xq4J+ENsOKiKBdZKaGrjwIdHiAKPogPfUDfxH6ATXghLg7
OV5L+M8YR5mcpVodsCEFseiO+oroe7nQkEbcvQol/EsE5Rh2CguUrvzHsoSv1df8iQg2cgeIKkVo
OpWSlteR/srkbcetghC23Fs4nEj1PcT0lVjblzi78wRTj3DMFCj8xPGuBT7jrzF5N8QG49IuouYF
CuBcIK3x8eY7AtQd3/ZSHbK+U6LaUFVRB57AHhLjO1pddnECgQJRzKQrJrS5r5DadVB50aOHNQdl
cr8Qsroicf8ArlGiLVqGhjQcXHjNTN0XkGkeLhj0h484Q/5N5CZwQgDVxJaRKUhDS9lVUvgo7t/8
yjtBIDhgkAFJV4Vi5KvCOvBBOGFQ7QwzsID5kNshnG6yu/8A6h3wV1XMslr/ADVGEsrVpy/UG7ck
nMCiBoNbxxGBKEul/wDYCQAcOMhdwTxwB/cCC7KVsOEVQaQnqEIdt+wgI0YJqiuZSulHvUCDoKPc
XKj8d5HlkoeK1PhEDtt/cMwXQ4yCmOsvDwxAt4vmoSdoqOYLscxmtZQ5AeoRYpgdtRCVfqB6gZmH
fLzDoMFOueIZ+9otNgInbvG/5GfCWV35l6aErgg6MwVvffzGtCQRpsBKvCO6l3DNnsPFdRtFGy8t
ziIgKy2BkJ04N5g8lLml1kYFbd+1yuEVOdi8Q/uSMbzzKfLmgabKGCxRzOFubwLuIzHgXe9ziBc8
BXiXdgLoEcYhIrYRkEpRbwZs2Lm3Kl7E5KEvl9w14yRUpaghkBQpXf8AkfmXjHrEKj2rnZpYQ6b1
CDNzEeVI71a/Ix1Anx99xSxFGuoxua+s7+eYc0USnYww6JBPK6gqYbJB9fmGLarae/8A5BOIU8VR
bxDSr87lzFXJV0eSAQrNTgdP1HC3lKpyh+IudTSxxcUcqgc0rZK91htIpHCQJadyjB/f2H+Z2kVL
zbEWy5YmU3zNp7TknKEv3E0YRLp08zPX4lVTXQ9S1zbmVNPca9W49RAkNMAHwC/UxQAAppnUVMbG
3BTGMnqEylm/FQMxW3xGuoKPFwqhZn1k5Zqx8RMyVyAGupD+40TXoF5jRRxwjrA4fuVLQV+ZsCLK
fUNKNnwGxGAcHXEqw2cAYkNpdvMuj7TRQPlc0qBI07EbRIxdrqCFWGmXf8Q1cKFTkI/iEUkFqF0J
D9zJE2PCFttYwoIr5ceoPrWxeTId2GwUhFP+R/Tyr5g6lip79zIAITzBjcx08TmGiEK9SmwzGFfM
BFShbXPcrMlrVZEJqNeUoqDCzhA04GPSZ1Ewpb8SyUS15twEdRgVATxMoExAPmBRQhUuThguJ4qn
PArX+YrMLolyaFXuU4Hk/E6BMuXhbM154lNgI+lzFEFq8S+g/PUodxct9wEmIgrzAuEtFjYJvBNo
TiM+BpsDsPJjsr+0/wBJfzbu+Y4MC9wEStwgaht5/mJmLLumNItDXwy+zsHxGCJnUUval4RCu5c2
BF6m9N7PqZfLb+IY3J34g+gz/WQy00HhGGrGn6h8qVLzGnpzSt4loZVrCvUqYuhPDA0BVAfU7TN4
e44iKl7qXSNciwKuqbFtUuH1MIDRDC34llsK4MiX+pr5du+2UoW6vRLgwLS6qq7jMCmSlEqg10QZ
zarFQWRekO1Yy8rnfo93qM1+OBAKuzb8xyAsRgUeMpUOm4dvUTMq2KfU8Whe2XycpV+onUKJSHeG
U6g7OIuxnR1AEYw8Rcg7yJM0NeN1M8hs5yH+IXVQ8qFtlGLHH4gaQ+nh9S8Gr4CoylYReya2aYQT
92NgrA6hzCcJiVe8qVJMPjO5qgKxDalH0V3FNS6/2xwuLpMl1vHzUJq1LKfUGSzNnTc84AOfmGqg
wuPbqALHYgbeLzpCClWm/Ff/ACEiGhzbxDdoC/UB6rH+YN9IMfS7/E0mlrGYJAGTDj1cJMYH72Gl
6iqpmRQr9kyVaqM45jmQMeS62VGpb+UrB6/cP9gQ2jZ7Ih9sP2DADnSyx6CwvxLqCkuS/mLWeobx
s8OTEsdFFepRzd/BohVBVLv7hYFYPo5gDAiB2RgVy9PiBsm3fWQjJEnewXHAP0SwLJNccEvKah0Y
SguoHlIAi7U9sZLgoN5MUAIjrUHhEkimxq51xKUom6bs8kYkEPHKz0EQhZQseuGUeIpTqX4nDBBA
UCXJAFy+YGecggKaAU88wT6oq+pVTvbnxHYwKRjfMaDVP3xL1T3MuHMVIplXs7itGWweQ87DYCeO
uIgQndxuPfVlzKqKEHBtiqxJ+hCEoFBxZKunhSnMIkv2g2srj4eIRY1X9UQChfgS2uQqs8VCTtSN
dbDBLH9kS15eMtkJKXwndpOmd1/c4UKF4oR/4Cs5Mahr+dl9yp3gB4LYFXtLtHcMNaD+4hmtQnOz
mdyVQeIL6EI7LJbQVD8XkuCHMPSXB4l5MjoNR89MuWFCwL4FhsB+b6+uJ0UI1Bc2PHxyy/JtJOni
FjiB9pULA1RtYV9xvd7SkuUMYQuAiRlRDuDX9xZlA+wKfmUu20oNPj2s55cnHwm3FeZSAiLZVbDd
EuNnMvixp4iKuqrKno/UDgL4hpGnpgooaPcKTm+CBbuduKTodvMCmiJ8/wDqjWwF8OJcYss7I6Ya
rfNQDXyZ6lLsiQ6GLYG7YvdQAm3TUcqOh1N3RIX1UGqKqHtlp0K1xxMFLJHcolkY8XCiugjOKi6Z
TxyUkr/sMo2Ii0ZXEFJu+oOI468wSlWvU+QjSY2ShX1NJ4nATZTxGszM4Zrtt191GdgMCiiNwKig
Z+dgEqFkTDVobYNR8QrKJZUSFdreY5m/ZtiUahr+ZTw1IHiMngIotsH9QwgHb42pyhAlsbNHEIA1
RQmoUQTT8y3JiK6ojQDbVtSxdOAuQiyLTnFKoBVj+o3NwJEhcNd62N3Kx+omNlj5PEpMjNJBVXLK
lBqX147fm4LUAVz6lLQoR/mOjEIR7qX4+LXctvIs6PzERjJ+UsIO99L1KiCCfcf/AEx6qPBrkHGc
RAgO4nKy3nY1YqFTbuKGqyz8QGNsAS7CzbOoONLr7iLUhoh6UUb/AJjwqByucgcll64iKrmVs39R
8V+Ilyyoi1VAGuHIcIBX5uPY0N3DDlf0DmWGWxa5qKy1aEoM1ortZhwmKiawFsXqBnMZ5l34oUV6
hG3ys9RLqpdfBG8pEV4l4cDTKuMywC/qEWvSp5nrUTUw6YzcN/FS3mms+24mIJWOj6iwlQaNwKbZ
dJxGlbCMOjsfUGRTI++ZoEjfiHFsAxoMJbLBRhjJxwgStwH3CLPYQhZOLzcq8bwaI1Zi1EvYocAQ
eEvYOjaV5g4lRMfcb3LvmitnhIke4KMGBpmwEXtrZDhHe7jF4HadXMLVAJaCfAYncv5TgpqrgEop
E1yVHLVOOPKPFR+AqIuMaLqIHEXC3zKJA0ZBSC2Wjw+Y4gAre9yPkAvGrqWdiXTq+J2EQXC9idXT
cvet2fEuxalL63iDVspX3GtppKg2jIDh2Ve4FeVcikDrPPP+y484n5SlgKUwOBbhfGwyKUv1lgAX
XSsD/wAgv3BFnbbVRMQMAoSGKBWvUYUtn5ITnTSYRv8AEpRuVzDtwH5ENOw3QdeJc2ncCtXY54u1
3YsSaGho14ltJdDhMM6VO/qClTQg85ONjccUw/1BWdxKGFBfuLuZ2Ltr/kdtlKcheZY8LhLMhCww
vZqcNOvCjA8AMXeMlZkJDccIXhcODvt3B9OnQWbA1EQ7tXGhQ1vClRq0g1BpHZWJXEOTFtghKNfr
nI5qBLwPb8RWXbLsuVhgewZEXC31dyNzr7l42DZNFe2NmWIPqJbuOwNuPiMAfVVDsVVHKEUoGXR6
GJFRC31jVwwRQCNjeEQkiQmfDDPKNvaNwqVQ9NgSRbEOSoIDoBwbiVqUDsvn7dEt/wBgeq1EhpxF
fqKW1dQLMdfFt9Rz5416+ajcknXVyqrrbop7hVHuT8Rv5dHTcXgvRG3qbr+8NW8/mHkoLpoHj3Hw
UKGuP/kMYsnWrGX8geY8mORhRsjTrzHgvLXKuLyTUvm8f5hanVswlu3OczCcNwSjyNAfEAMy4OCu
IurtS+aT/Idq1bavY9z3ldXWSpJAbZ33AxgSeF39Qk1By5oYxu/ltvuKvQeEWx7EVF0F/wBlSmD8
KbG4PymG1SiyvqZCEHTSiJeoG4bwfiFmAMNaTiFEBBLtdhHrY5lCv2R6ZqFgdy5XWGuJZ5+BgouM
fQzhF2+JoVYBxzA0kQtnD4g4gviX/wDMYsYQRtq5qIpoq3Z3GhA+EKAAHTzLbaLypr4JV8V/9iBs
r7QWJHnkhEWM7qolIPu5uH6a6GwnQBovqonmm6v8RWVysstjeBwr2qi6u6AvguIcid3OQGGjfi4A
vRmcAAtxCdKzYuCc9w8JOMGOIPJxiPTUdCAMr5KLQtEEm1GrVrHwCVVGK6/cYkJq+pTABN7yNIaN
MXQ6D1dQkRYt07/sSyoaRthOpWBnMCO95LRkrCcV4gI24R+ahPuLpEOfVTjBdIkfUAAeMlxkVVbc
CGsb0qtgQOQPaUgTXmU1t9suWAIPKtYFVTt9bFqtzkLuOx7AiR3eWyh2haeYCFoN9lQRGy/BhlBS
m3cGpYAPcKzSpfUcJu+XEpwPVOaiCGnBkYzysfqVLV7ImXzKXY0MS0Ildwqr2Ari0sDK8QZHXf8A
Mf8AKl6hZVGjYMlooQItAcq5lHfcFpMmoHVEqzjuHlNRe9gDq57xcrWihUAypo+O46ydml/zCJEa
13En7LtWHT48RKWZGNovRDNOAjUBPnqGEAm07R3aJT1LE3m88R1Zb28VDTFtaOt5m+7Lly5Y3dj5
hFu6s7gdCj9pG6UAs+oBO9iMZraoF8Q0qum8ZGhsXqG0LPDCJGhpPT54H4Q2w9hcs0ht/CWlvGtG
N4HANzT4XebgB6Kmq7uAoqkrsqX/ACAt34hDia25Kjw7sL76jVwmF+oz2k6FQndJiPDCV44g4Hb9
OsWsTXPMCuJfcgqDaemwyx5IAJlk96TA+I4iC0KmvEDDXvqwBoMBmx3tRXnZQ5BPBIC/FLjHoI5v
ccOnBdFwecjHEC6xAhvzCOBrfhIl09eb9zC4fVQESBF8XGtrHmC02pSwLY+4DuhF5muFXDYRnQAY
ilYugrFAXVduuZfrGUcXU5kmk9nTA0F0HEZ0lSHLHFFWHocYAXujckcoFBa7q4iHLyj1GQ1/PRW0
gq0cLechtVe3jL4KVq+YCykqeJvXShfzN3e8p6YyZAFgKtMHUtkyw+YCLa2Z/hF9AKFuQxNABuRK
NXTqUqlXTx7lEmAE5jsB1VPcPhEa8MDXtBN7zKQT7HmDnA0jyQMk1JoVzMJwq76YyUmpfBcoiWjk
ixeK8MYw06vDfMD6K6vHmCRaYOXsgNFqY4AySedmUiGxaU7z8Q+csWGqiwblr+kMNLoCDWOOM8PM
ZizTwxewAnnPPiJigGlvYIqr0qtXiOEb0vqCpYksPI5qa7ARORlAMxvkvf1CxNccXiuIP6qjifMc
V62O5SCQvb2iCggtV0VBzhiHk8XLv60KgPM5u4RuEedhzbLSxPIDxUQDmsjx4qUtdIJHb3wCkVsQ
7695D4sB4VCDf6DVQ1hXiKf1B32U8SXKnu35lRYPuksStrM8RZSpLcRlCoB2EDtNlnHcpqqNqs3j
fcqxKPBjgT0NgStY2BVfcf2zd2QvaJe/hHRyYu193HkeIci+cXBqmN8U0Ua4/E4l5Kva/wDYvuJu
xgbMfC4SF9RpyHzFjaqVYaHhJW2OHgAat5ieepYqM6HAGiGEqKHB6WavYGobeKiOzlrj4Syci4M7
bgECvUHHa/Mys+IxgK8RbsicC7/UPIeoFJazj3LGQMN1laXYAoKKXTzLCICIbFbO/M/92JVYPN9Q
iuhsCPThO4VhExViFWPiJYFJCzLWUyphKw23mXVn/uRZaAVplZABi5TmGhUAXT7nlAF+UMrDxQ17
nloRyOCyIWjqkl10y8hO+OJWpBoFrLFg78JbgricQ28DKxpzuNEOIFTD5IqHgliWb4nJveiKtcy1
it4WDRgsi4rUS7MhYDBggGVeFY68y7qpQA/E88rSo1csFY1aGnY+SjlXb+IYtKuoHWxdYAeiWtqX
RJ3mXkpOzmGkeah5I7XpB1Svh8wR6ikWxIFWnY34gU2Mr3KbDoNysWuUGXXcKKypp0KLYBHThLYa
mLGZL8NfM1AG3LpLFBsCAuRvqAqobpALPi1dxwNCUX/mNJN6t8Sy4GalSoGDuKLSuY+aPPWdafrh
NQHDtL1AaBogzzi8r4jNxZQjxNRW+2bZGlG/iNvWNsToDhplFe8LxEoXebOI8inUoAoLPMC0zK0Q
LhyDh+INQhahoD5DSFSo52TmwdfMdr3cJ27E1ruaxwMsLK7o7qXFQ4WEHMnEjFUNsvzL5LYtRX5t
jGaBQoFiDdUnX8//AIVY3EDf3ChS8PdLxDuukKqs88T+HJEArYqlDhbrcCzjgReA9IiZKg0XXuMa
yoXqDgFOpXylcLYUlxZ7XgjO1DyMuNQNYNpAo9MsE2pF+3ZEG+ugNxzYHVxt6hux7gMuCnLPUvpS
2jtMHLCrCwRI6gpX8RIUL5QyeQCb+4MNy10t93C1s8oifPEUdpXF9EVodbX3zOZqqzOuycORQ8nm
UXW7u6mVGorfmbUHSL1K2vcO1EjkQvH1HUAUZbRFy0Vm3Aq2Nm8Ny6WdyqxbTiPPfUv4stvzBQbe
Ia1hM16RO4toYF9gPEWTVaeYbCKfMuLq2Wc+IODRpRsgVdsucSxoevEzauqqp/MwWQEopsFpc+Rf
jiO6hX+4moFzRt+qjgn0AoPxD6ahVon/ACPq05uKSRjRx8xss7bYzSPGrZA1NGiOwKVLi2MKirey
1A1sPXbgy/iXawLQoiSFW7Cnn8QjxDwHdI5Fi7DjtClq9dowSu2sYF9HOB34fMqRgFv+xKNtJNRg
xOc4d30q7+YivowVlIUMy8lkK8pCL3JF0vqFKleZbVvuoHpu+0VGDmuYR7EBNmKih1xFKV9Li623
zcJDvwcw1cCxrg8w6nV1T5gUrxwSprmOWC3iAhuo1RFRsZejshU+h4SvD0kVUxbxRon4EsPuIzZ8
RSaFhdPxEoAa6YsRvoggFSrHcVVFpAQiI0l9z+0oJXZfIWPUOisGAQ7Vk2j9w3LDsS2yAO5+EpAU
y6gDeDaC56ixuEeYGa8MLqPpcZyIRMPAGQb1rW9wSOYEBT3kWiHC1jt5KYh1dVKZ0kFlUgO4AdZ0
M044DgYZrColWwdecpImm9XY4IXQVfyiVQaaRyGQrR4oUljQWWxKLqXqW59dePMWCtwV6r/7KLTb
kAnmaeWnzFLS5Ay5ZaqbxfiDxj1LgBVpZcAQqd85YJVq3TFcuyxSmw9HHmbDW9TVgzzHkbFpWo+G
E8bs4Zu7XZD1OC5A7zJrNVzUovnY6lHsMgfJ61TAtuxV1DldWp0ikVqXXENA1EIueO3pFQEwXUsG
LNGDhLhqLuKWC8O4P3CjyXONtesi19ii+WUT2LaIp0C8RoBKVjqXh5hwGMw0KuUEHLmBDSQCa17h
weLdlmg57jXoR2Aw7igLKKrGtqUATOd2UlM1hyEsSDaJkKVZwSl5F3hjF0tqWPctSwjJQzVO5vFK
4riJywBG+tB2UDgaiooTo4jW3HmuSZAA+UKVAPLHBhykJqBGqbc2G1t1B4sXRKQHeiyQ7j+ItGpd
Aymhg15lJP2hb8wLwLqH0cKr3CCZcMGxtqKcIF3jgO4ECxhCcwF0HI486zmGewq5YnGwN4Y/StqZ
xCIuvEs0aLOrHSgbxDvTIOZ0JMzCOyVVAIeip4S/ipb/AKmIBW7DsR6dAI1rQTala4zQ4zCgHJka
z2AdvUdogInH4gtgLsJyMDAEsNxrLpNA/cTzZ4OIWGgtO4tzTgl6a9ANYqFOB4uIu0DgiA1lK/ic
kSLiwhwh2V5nLJKgoWqrIUlQWtlco6qQc00DyzP8BEYTCVchsfKUpeZ2+1r5h8ApMqMKDtVLXm1a
CEOweaipfgO5ZHRLPK0RcNyBYjY0REZxU59QUXlouPWRMUcsVZS3U6jP1tQnfEOlzzu7X5hluiv0
mBAG44R6MPRngBX6g1BpK9RsK4l/Q8O5WLCgEpEY37sYKjFti7cQeuLoghKmhWsvnis8ylysBV/L
LWXgpYL2Bkb2FYwsPLeWfEbpzgOvMMIpRDPiUchTkwBNSgj1y9NkTg4iEeHxADwd2BFlpisvmEwX
g4J69ykoHPL8QYjcO43uDNEQC71mrAllXCFlKsQQ4dcwxg5bYuiAKkMXCUc/QhCrqcB7ioElCbhu
qsKSLFK80yFOHiyeinFpKhZEaPkViU7vzKEm+UQAHwG6hK6vqFICiWR26oRwVMQ3QMNjW3tB/wBz
gXDdwQ9l0w+pbu7ymVLmGwrt+bgWtlagPaR6grkbGJUWU5joRJhxB0FU0uyCOlBDiFA49q4kR10V
Zy9ZEfE/2OoekYEmXx9y98AIqHnUC+Q+79ypjyVVT7hbTEoIFdx5FGZIHwGpoYXoUyrq7iCo9Vr9
wcSkCDI7TrKlRc8xeDiWFopgaCsH5Sj8KVDYvEF25xgr11w7JQ4vRxKppKSkYghMU3DkmVLE4SLw
xpY45j9GomNcwKwqCvcaZgIpXJcQt+LgAyGNHydMPGRKHDHO5tWxWMcBEO3cNg3oJyXHZx2+5cza
Qud1GvRMR5h0u7Upqp63gDDplLgzQpDc9wZGYvKKI0mKV1cpijjdriYhVRHDFnnAAqB6GVXR1PMY
CLAYly3Os8oyCroABOPMYOUeG3/Ik5icT4mcVgiLzGJaN+vVxL1JRbz/AJHfJCgFS/8AIB8ZD+BG
xB6nMurh2gfIH/7GgSuUpuRChK+Jbn6gg5vpPr9RWaq9WoQz5XgMXXzsQ8veapyfqC58SWTr9QKa
rE1wv3GviHmi+YOzodD/APY0seCKFMtmTp3Xk8dQLTEKAmvZFiFBMCBZkQG1kGL4iu2mU8svlbTu
sjG6E8QsX81UoIxsMGAHUIrEgediwwgiZWRnY2xSa4lOwPT1LnoIhfJL6i6pzHykuivBKHlW3xG1
5vBmQWouWtZvRXycTWAl4RgO6okFxqcHEPobj8cyljUALTI5VFi67gIfImiViTw5Nje+IKAFb5gK
PwigLluTVe5VqcTM1pDgs9Q4I6ye5dh0j5QyA6ocReXoncI4OsckBcBSyJSkK8wuOKARd6aWVTt4
/lDAOZDY8wpQnB6mjYKsQ404B3BjyuuGXmetkzKxalWySiAI1BZAClLq+8gQEHCobrGJkYQQMVkV
yCR0hMuawyM5+KoJoL+YKmyqjupgQa4dxYEdpwSlBEu/MBSGIM5lePIJCiCUTxFkazYfMDAW111D
uKq7haCdTnII8hae4jwdE6lLje2F1kueWGuPwQSUfDIRY2B4jsKtq5LhAujeVdQOIuiziL3UoI4D
2K0gDN1iqECynMayrsCx2CyqVVVNTVPDkPBXATGhV5KEPMSjtQrzCEMoQoJwJgmN+kXxL0Fe5W4B
x0Rf0l1GPaw1zFWj2ndSrLAPcYgfimp7Vg/qqu6uFkdF1DboKJnzMP8Ap8QfyXVFcczm9JU8QAEe
AV1DTOx4jraFXVnENOS/RLgCmZzDtQ0fidoEScbLWAPEEgLcP8qb4mOZtQ5J5xtfBcTYINPXETwF
whvbCikvmGoy+JNoyi5hacRi2Nr7YfjZXEXNaGgoagsRgF28RNpWWR40F7JWvGljqWZomnEf6/B4
lZIGI6lsN0Lp5lnOlo52DCmwyP8ARIveMGWyrHqdxB3DGsBJY6PMfNfQIZizgNvq5dtPqcGUMIy9
S0JQMteIUecjAVWVtUyzEro6tBGkIaPUBOHm+248PiDmPPdtHc01xc6PMMVz05UyJWkYeGkUheY+
I0oQQ88xOBcFTje4gkFtq674lJwyq3vzcvmIVGqEiaurL4eJaexfiHpQkq2uKi01WA5IGZfIloaI
HHtBi7U049QBGmeyJx0Ya/8AdTMI5rhvBiO8orsPEVlI8MFwOtqvTiFDRGdwSU5Ev5QCGGbiiUoE
jOc1sDrgI8RI6AH3KjTBzrGebBIJx6AVj6YmxNVVvO9wftInl3YKw7NAPBexCdG4aytZRtNcECm6
WRqBtTB3tEEFrIefMY3Gy68OeY6lOYcH6mt/VJ+EDNmKfUevVQ19wXE2t5AU5VsUAduxGlYwYdIf
SQq6lynoi/QBJyXkrJ0AcEJKtalcEV0Vwy78wYehuQIEnK44alxmi8/Sc1N+1lzVi9zmKcFODlUo
iylXi+oMpGRMtMjAZpXGQ+sbA8Hg8xTKFHmNBXoKjpePFi8QCu60ZGqIO1dPCGKq4NI1yRn8kWVd
qri1Busu7lNDEVNMnPB8rQMJCzWc64/+RvZCgbqU6gBaF4gtSl+f+4UVwmdxQuxqPNIi6ugp7jgB
eN07Fs0Uf4IJ8gjAG+JfNgC83OUh6uAKS8xpfm1yvuJOhGFd8fcN9dvDYRtZWVYTUrhG7B8w2VTa
vuAorb8KcllxNuc3dRwXBb9X/hGCXx38RZibh2qyjNKlwRz+4RRNn9Z0e6nwQYsJdrpyW3gOvaqU
hWFZNvm+4thwsAAFKvMFCsvm5oOVaqMFrn3K9JbIAW2EuK3vucg30VDbOC7PUV09Qonip9XAPX8J
gVMI0t6WFkdwPQd5gQZQJ78xtQQQlmXR5l3PTiKUilu9R3d1hCkKT2jAIcWpmmeyWA9iIWaKkQ5W
y34R6QIn4lF5nmbHiP0yGYmy5kWHK4XR+oUHCvuBC4UxcGyjMMRAcsQ3b6gXaysd4QWNG7IIDvdf
M0oDiCE6FYJUlaLGAKoHJVArSfKYVPBzAytgHKjmEwoJyRH2XXOyMOFStFTVLFyBakBEGym5U+OE
VLLhcvbaH6h1gVuI6HiX5VsDsjeBPEFeOYy1tTd98xy7wKlNADhKvdWtZa0jUQAPKES0/EJwuoKM
Wpl5KQdyqjA6Pwgq20O/iKootnqIneFPtlBdpwfgmHAR2VfovuWrsKFRxBsK4cOISgsXdgjWwJfc
KAEH/EF40PPUUG+KtmzjniooGx2oyChqkgCr2fUUHIQPDBcq2Pax5PdwAUAGufLFg7fKMxbdKgCD
vONQrqINWijuCGFGg/EJgBSVOaXeY1Vb2/UIAI/RLqVdh4YZaa9fERAAsYlkG2rlBTxs+4TFECt8
RudWUMoQHNe4Z7Tv6ggFmxLwF2NfqALlCy8nX/ZxqSxzggZ4jsV4YoQpEfxC7WkX3K6ZifiOuFAV
ME0Bw7S11xXHqcKBJYpoo2AKctdomzRi4nUGnP1HJHc6i87U1YAXq6j636fEKGIn4qIek4S1rV7v
RMIbajl2K0l1M+bjAAN6xR8ot8twsOGvmoFJw6/MRzZ26ljNGB42XYBC07RLG13LA08+ZaDd7jZu
WC/zHeCh/iXpko8RHBrN9+4SkaHTvIpQI0HVvJwrAbxsNfKAeMyDHmfT1F3lA5TiUwQo8hY+07B4
al3SDUcq4v6fAGJoGC8wlCqxvc1ugaNJRKPOGxVbLGUIL/iA8Qi8viFWw1TfNRpa8i8qWIq6C79J
f6TbrmVQzd2QIOCP6j1K20bflnPWS/ghS9hAcdcShMBT8kFLxZgtgXH2loP+AZbTLdpcLUpS3VKN
qFW38xKXmjvYORKIq/5jDvBALXxE4zwN+Y8mxk+C4gaEYw8xM8JPqIhax9XDCkYH/AsHqBSRkHXx
AxDj+VmKdAWlsGCPj2kmOV9lrLRQEXXyhcK0LGZAzKWgo0lwagUplAlKzGgUiHyQJjnp+JX6J0bc
YbcD9QqelQ7HJQAAVBLOoFpEW0+IVtsARtDomfPxGlAlfwihSA/MyeeCs4jlXzFvrt/mpd3lK9UR
pITyC8QpcC59xALLoV4plcIZSw+YsVsvblHtq1icXeRd+YCOEBp0vYXkuHxkI8nh9S/6hxPCE3wB
9suYAz9ozkpYWgdiaKnW+aP8ioU2v+E3cVhf/uRVlAKoWz4liHgd8bAdzfD1/wBTIMR2JipYNR+Y
lAL2PiLGSlmo1f4h4NovTdH+RcoCA+YoMpaBbwlh0EGl8XB5hdz8wHLv1jKWwoNHDNu0nwefMvNB
Ap4yExXDsH/EITDLxx/yUo0bcVzjgXbV/qE9AXdXiU0CYL5ajAey2Wcb7i2rbE2CcQCrgcwC1gSs
e5cAb4oKlCNf5iCQiLaxRJY+keYCCVePF3NbwD5gI7DC92gFdWhiAMKcWRgI+o5gsHmcOLT98S+S
q4/Eu7mlTj4iiUIXlJt5ruXmIKX/AO8Tl5Yr5lhnLnuBE0/uiaMKoOJtcVxUVtB9wC1cQvXeoUtd
TU3fUAHFxBKPmBdXT7mDLiAobBDwuFtXVn4huUHvmK9W7pgxhbqE7hIge762BdWXqoEhCEjXMbau
0Hw3pv3KqWF6bK0dduiW+S0q54kC5HBxV0hMTYLLgMVrOTmNaGsIebqmkIw9BAqRSw9xbOHWxDhp
8zkPiiRizU+0Jx7uIjNHBrClCKzi3KWhF7FEFjiGlEL8okcXbY/pNi6dyJRq7ackfgr3HN8L+pgq
PH3BpAoJQtsYa9Bwe4T7B7EWhq+JZAqrSOKKChiC+rjtso6gkxLjnMCpXhD5KM9RCNch3Oy7hBAJ
tcy+6yxXmpeAXCvccW6PwVAwjgyyHvmMVrpk+4XysDzUvuuDT3GlyO3xAQSJq2VrSlfqFm01Y5gw
SYF3FwtS2fEp3jfSXAGpRt+IoFgfjJWCraiArBKyWYmz+Y6MF8gACAuscBui1YvAi9O8j9QA6E9Q
4tOX+JhUSSiW+CU/Uu2bRB0s9/mMzaMh7Ixb3GhU0Sx4lNU8sWxWnMfcWunzfqFmxZvkl1w3TUK4
PL8SoEC2F/MQXaVUw4PvnzKZaBQYgKUblZlG+cVcy1Gr7yVA4sB/MBXARuN5mHl08ShaC9QrtT9w
FryPewakUlrgngutDzMwCp8cwepbUPqLsAp+5SJoAPURZXpTwvMDYEOTtD33NeQyncSg6AaDJT1O
KviPKtu3AMY2P4gkWEPeQ4uHi3VwBWVV7R647Ty+YhvsUOCIehH7jGFiePcsCIQfhlMk1W8S0xYQ
/n9QOLEuD8R8JgnL3CQwLB6cTbUZirlle3LKuNWahB4uZNQwd1EA7dkS2/iEj/NlPiCkK94plyHI
C57gTrDX43NKCopyXL/AjrLXIZ3Mqy954gg1bl2sayRh8ykd34PjDN6dduoKxDv2uCKPtPb1Gh2r
W6yzFWpHDxGSy2VR8hiIBPGX8TYuwXqWQppTB8kXVgt1eTZAZvO5BsjfDxsWsyNd4f7AfAF6V8Rd
gK288wwFq/Nnj1zKTAA3g9XLfAWPSAkqVu2DLuFpOQKDsuBNBvfTUa5DQOtYAHcfZkGVYlfkjbUn
vDx/sY7jHx7h0oDQfEClmB5WRam3Bqlcv5j8DFU7qoG5Vy833FVYB5hV3Dr6cG3BiFaa6doIOZJz
WsjY1vEV5ltPGnsA/qU3S+AV/wAlNhkX8IRENIVcHiUW1Kq7yYsrQUiBoC8Nx/2WUZtARhAQOwAd
EtIHHwDe/MPoAdmmS75BPpH/ADYtL/LBv+HS0INFI6rXIZRABZo00srH4RkrBW4U+ZfOtOVg8QkD
lMA2CRzNr0yOXCV455gKOdWCXzc803nKDPQV48i/nYHfcA6WvXMphJKIsf8AID0512DxCVPsboG1
Gds9oL+4Gk9AaruL6bzBncfJxBay+Rj/AAsrXF4+43jMksNE/cbpvAsNP2yxhDAJQf8AZXStHgDx
LxsAWgrINHXC2bAwBgNoC5/EaLDb9xPuwzmpSUOe4LK17mC4S0FHzPcRRFju9xU4AW2+pZ5nMBkV
EIwuPKNVmNkTsgFsI/lWCjzWfuYgir42CdFB9OY1TkGx3kmsHrpxcEhBZLxLNI62MSTpaaw8MWJL
9IohhKQBr1v+xy+PGGoFarahfDCufMZucEvzDoFLMqG+VNQK9oyKaRV1aqDSqNzuFBAK5WUVVLNr
vOosaDucy8eJZsu66hVqw5ch8CnDYtBuBlxFzkQ8EPKm0zTlVSDV8UcIKtWi33Bbww5GAmQIITh2
tVgBt7/eKCp4cpdXA0pzBHMptLcC+wIOd5yLjG5Rm8waVKsABKE/EpUN9b7g0OlItXFHDCuUaolv
OkyFjyig9vZbsNaIlKr8EumjTVwJMZ5iMELV1zC5TyeqnCMrjE6EcthGgcxSqw76QZVcC4S9yepR
PqD0YOmAcLxB1A7b9wUuuW1ZUapjgiC+JdbDLqteyUrNSdlHaCwcwGJ5mcSwDKlTwCVGtCx4Vcq9
JVI7CIsL2EiNlYxWUbVnWVK0NQrLr+gh6Gh+UqUDgu4Omi6mpcAWm+kNcV08wURbqxhzC8L9QtVA
pdxMB0BlaugFgyKgUfMZmFVjQRRls3EuMAaHpB4gVLCAuprGVX0ZruorJVseYASLdmDSdAVwg0L2
uFkhFAeIBaKDvJceEAwzRAGji4N9pYI9wn3LHWUklO7rCAmWCioKqu4ZcgBaNlw/06UPqEsBc7lc
Mai2kszIFSZuwgbSgKPhge2ClWDIgny1YJVHV7DiLQrS+oFYwum5QQ00X3EJYrR2N9w7lflB8xW6
QlapyA6bBw6al+UqUgvEdlCtD6hAqFnNrCeBAtM4lKjKy4oCo83EFQ93GNGVAZA5lXCBKtEFZhAQ
eIbXZ45p5lRIoWdypLUUOuJTOpRvYlPM/wASqUjUpA7+omJK5I0sS/kiPgECX1ED3SWZ6YWAPwG7
lDQi+L/7HbqNbIOynIv8Qw0wX3rDLcu1smI/khcaIU1jzcCYgCsa6i2HfAYrogtWrJ3gYlqGJb2o
hMzNMLBIXFHFXiEV241evmH+pQu2WVapcMlJoBWNJgg1U3fjJoAItWXp8VKeRK3k8sC6RQarnMpm
sqy0nB02WumG5SUNiXipywxTftsTADplXAmiF+zcGwfLF/2ChtaEWnuNZdjs7BDrBdXv1FANk3ud
JKDtgbTawpWq1lyktBwveInexNtUj/yXvmulYnVPws/HY3KGpd1x+eI3e0mVT9waJXuJHTwnJ8Sq
xPhu07gl96XTxLLRlnq49GIG3FShWuwKKAF4hi+cKI8IBS6y7+FI8+EZGlL4EtyPa+ZygOiwlni/
Y08zkHIHxBr7VG1RFdyO+Y/MOwEseI3wUHh+Y5Yp6B1EjmywaVH1uAnubuka7/UKDALUafcEQyD3
6GZlAK9USn5pZanmE3ClVhA59SrqIWcvUW1OB9PTBQDSglLtfeO/cKwhSxedi7kC9W+TjxL3w1vk
9QGDqhnLNIXR+IVw0NPzAnJX+HIuXQMug4hChCBpOf8AYUs2Hq7laYAZF9C2hWsuKHuZwF4PmEsO
obbiVKoFlccyuGUXp8xNpwdgm2SzqOxdDDzo4K6Ie4hHTMqQLpZhi8kZvKzaRogL3aRFGrIB/Agh
cK7gsK3CofErwI6DXhjtgs5SOopKJQefL7jSJR5iUPPqLIGzZ5NEpS+vxBPSgDh7lcQrVvuDrxU9
w1IyjbtYt+YD+IjjcLv8QuFXbofrJ25oHzzGQV0Smo7TVdX3EHq1f+wmrVpyuOl1UU1R9RdN0ssb
M8xCqNc3DXFD5im99xVTlzqJviDrRIicrHwXsQVT+IKSUo8PJYcZ3Nz47g8OW7xOPAeAa95Etgrl
Gxeu6WX8jVU49XLTKXagV4cJ5jAespUTrX6sWWpY3edQeSRmuI2GeG7R7Qo00Pl7mWY55PEAAPVy
3QGD9Bg3x/8Amrg3FgOUNxrcaqOKGx+4wuq88QQSmYXHI3Bpf3LhRTtl9743LFHDe7lFEC0I65nP
KWP8VzThJuViO+0sO1h4GBWCd+Zbex5MtSDgDH6BOtMKKOGnY/uvOsUu+m/NAfF1zLEIlbL8bg3O
Lj7oLKbx61BdpZTC7DOSoJfCJFat7Y8QCwjlyIoMdiZ9RqRVpcc7bGpJE4MldB0qUwZ5I1CR6P8A
ItWTbscPKAZAAN/IjoFdpgUuvTLj6qqtq/niaZXPBL9KN3LIVwBsQAr6S8Cr2srkTZBjnuAL/BG/
UqLvJl0N5oiDyCtF+2P27C7qb6FvGUctcG8mS6UI8x7pZXRFhgRzwP8ATJqLOFhFGtDzL1Qlx598
Tmw9HmFa0DEmAKWK9kHVRwVUavI3ZxONqm7vuWAgwlUS+Be15hq6N5hkbxQLM8fcRqjNTr4nHSrP
UJqxtF36jdwcS2x4CWtL4jgND7b3FYgUlC/cIWly5jm/DCw59ir3+IoSjaPXqHZC9V/mNFHAClxj
KrEbGRV+WWlc3zAa3nmMIiiOnOlkDR07Tp8MYedmGNvb8otUk0C2uXFKK53ZL+V5qUziAui3iLgP
IAHmKquuTzEyacLn6lMo9W//AIiq0N0bcESdF7ArpyU5LVEK4R6humcFm5anelT7leQNsEE+4Pzz
hd+Y6qS4bbCGyi0USNshHJ3YZIgb4saxwsZTVPmZwXBtcVsjgSiXgCHCofPUUu+SypEHox17iiza
p1PP8wE/VZpLAG9+UFeVCMFI7y4he5V8dMcBtral+o+ua+0v5K6Yo8JcOZoXGh6iYvEiUw8Vt+Y+
7UrWe4/u8hkS2hR1DQgsGxf1GqAXhb/Us7vAeD6ifpViCyhbzR/kEjXLNy0oqIWnEV7+mXUGjuEj
4xCKyMF5+pSZzemIaBDw6j67RZfmUBRkcg32MDqTwDbiSTwSW5+QAwJz+wUIVwWJT+IkVuLlcR8G
S9B2AYQYNg8HmBjBUNcQchUlC4wy8uqtl3EJ7RhI5BA5DO4qqCrkdVh/MtAkpnn/AJCBpsKTL+4c
ADt9JT7hg6I/NHTEAIdDzN/5RwI2Cv4AidDt42TpBfLGBw/AJxilxf2ROho0YX5gQiF+fMSKd+2+
YMYdTsl4ENMxlSGr+lGkJaGJ5mDliMqGE9wVG0MvkueYJZrjwjErHTAIgwBjRFXqgI/xxEN8QaQE
xQcsUA4L7qY2GROdXFTMLgNuoNE/cujLDzLQeB6m+SNDhT+IdVrwiBYA7XiBfIpzDCArLO4iaMOm
VwolvcLWI0cv/sG5CPmbkQmi1WiQYppAlTClqHErQfO8opLHAwZNNQJh2vxGF2jFMupRXw0TDTVL
KuXNVoTEZV3wlKEMl8V3KonMbjlg0H1Gi8JQWGRVW8vEyL7QUHfcAqtrxKK43GrRx4hopqkD3PVU
Ek1x0+ZSctc1BRVgWo69K7ekpAAbVfzHXQaGoXVRLzi5ZiA8cyosnEI+S1apABRRxkbpl+IEQU0N
Ru9lKvInVJd8ofaDf0RRrbpH9R5eAN4jDnZRkUBvTsxZdIpXEBn7Zl7p2FS+sK6+HNxxWZYSW3bo
riUeQOcQ5iQ4LW4aSzjXM4N3TvZudUl6InBqoypaFdyyZF9LTmEKJtKjcQ8HMpCLpXiPXofJA0YX
YglPMTchdOS2AStgIezk5hJsad0Ubqux6loQ3RUb0aHgj0LWKO5wuF3UYDtaByyhXTCyACgFAkBV
q+YqGz5iXuUDcp0iHoF7KQRq0PcBianAhRbLlzsra6i7iCqCAtkugEcgvVpWMcA5FjDtoXRxBJuS
/mqhaoBwOfcLsHYpOePoZGfKml/IuDDL8iKDhClVPQ4GlhDnQ0aeItZXANqMNR5ZW1XzBGI5Stj1
gD5IXcii6fcFWHQwgmjxdVR6gHeaEVhtee/zAJpYEeHMVu0XQ4LhU5MUveJyYApZcHWAspwysbwA
nUTZwu9RrLU+owXihrJwPJBMtLlA1ggjYCcUdS+VPzJ41yFN/UK/Lf7GLRUpN8X3B6aNgUnHjqo/
zEaxRe5lbtSfpLm8INjeWCv/AKCVamor4eWIQVHav+Qstyst9RJprAWrGNfiWQE4SxMaXkRXsBzf
mMqRLwE/ERa4szIEgAUKwlYvAE9QGx3ZFrfEIGdoqiZvm5PUGqBCFC3iCypSjYuFyGBBeRxkFt4s
7uE9fMPD3Ac54C/4hYgojDXmLCI6q6bQFFKqgmqIq6m0pda1XNzU1Y0nqAnGOjJrxKo1SPBZQr4e
Y8tIFCR2FioqnIw5WvJB2U3aDCJZhAh1cAXZVCuXMMfQXq9wC8qHmvEJbuseqHiZdypeeXiVonsN
fU0nVbVvm4tts14X8SgxWaKrPqcHfUcyasXRtBv4nAraDiGp0RqXeElN/ccadzPDGIsAohZ/8gtb
VIRo4+JXGXuds4Yn0WRVHxC4C1vwPiFNOMYyyiVuBghAW9KhkGI10e527OoNnE9CoCdBzDEOWc5d
Q4ooWy3m4XdggsM5IaVAB7ghAF9FV3F6+IpajxCXlR6ohAsW+OY92FE483FINS7U+YBkZd3RcABk
7RrUGDF03LuG9+1dytjSC4CHkccRXWPAsyIormgKevEDBn2+jCCbsGwIEeHC4qjsYjfL6JF2WuH/
AFqGpdQKUHUYqiKHyGRADRTKrADu9RE+ziKJdTVou0CmhuK+viM2KqjJTW0CkaURooaU4l1BdElL
HmOIhSOO4q0Erdww92TqGe/6hVWo4HHZDXEKgDlMuZaQWlZSDx4BVwEbqDyXWzQcUwbY/uC3LsIX
y+JeyV5A6Yck5pormURKoYQ45CqtfiDWXQBV0R7dVHluAbstAOWvrJT8VA3FZ1HW0UThS3+ZcBMj
E2xh2EXJ3wlhRLJZPRGmBsf/AJAKCW6S6+VZDwC3YRRZ1G7FuSlhsHSXncBhhkQlt57i81StlXzF
P0UGxCCQSJoQRBsuHpRMp4/MbuoZHmrfnkxzQXo5iiuncgKx2CCoGmgbxC1RbcFRnqIG2+YAbhVq
PWsFPiUWGIoHlYIlz1EsTHmKq2w5gLvmp/QpcJyQjqCeMhUZixWKh63TSudhLlDhzHzdE8RlqBuo
fjBwqPXUbWjEhwKpnEAR2O1qQbQo8JD1crSFlhKsxlJOjiuqiwIOa5ldMpAdM0GcHmEEj4SIYhQH
LO5VnHOe4lQW4LyzH0sRqzwKuYDNALKlWhYw5hxNhaGy4VTw5Y1Kl0+5pl3/AFHKFuJ1MBp0SJ8F
qVXUWB7NOdgsSDCsgKDazXcpYBXrSXg6aWnUDohBK2sBrjIzpLth3cDmcux6HhBGT9GoNgI4qNBL
sVMgyMk0dMAAJeENpCi00gZnSKRQksXUGpPE+JmAxxHgyxB3CkAOBCRQ5VjzypqcXZFiX3HNbfAx
usXDSHobMe4GZSsqD7DyzuDEwHFRikHD5iMCa9y9gGiiVRqu+yOqLQ4CXORzj1SKEQ6Q0wrM7uKa
QXhC0ScU5JZqC0JDmPRRUahb16fEaKUDXGQe6yoPMZJo1rxGBeUgC3gQqUwMOKgoQLASCAVFuKZK
KoVxDNAdq4bjUIlUF+7ir5SUWwkPwAKlrQUW8qg7K4YJQULCpliI+pSXlznMajBjVcRLa3XhjfQV
LFgBZE3/ABLopIi1ncbru8updn4DPcrQoFNgfBFRA2D4jmtZSwcM2mSyrhFc+45Iz33x/wBhjVoV
2oMPHcNIda16jWVUNDfmH7bHtI4OXZzzAUdsMS7b+oAbeJfK4OLtdXUy0I09v+Q5uorm0d32h3AI
I6ycTnA9sONE0nFdSjg2Fjne4Ori0DJpShlAB1lQz9umu1/5Ob3Q4TxCvcBHtiIDg/MxFAeLiRDQ
xmsqZYBU17nNaAr1DgoIHB1zL8RekLvNlfL/AJOfoTmiUoPlB3DIXrbFXHqYqw5h+5914viU4sy5
yXLiSjjRvIFpWHGvLBoLReZzMCfwiDFxAtK4+rmbdYcfcCiA67zLmFMOKqyA5QVfcFJqjTIO4igc
RngUiiu41WsGd3FCOgDjZW8GtcpccGuCdKX/ADEsdtteYyC1AuX4lbJW/ZFKDUcrIISUHcYB2+wu
6hoIXL5RCYaSypVQKoZ3LHKUJ6gVLXw9EOmYeLI1SoC1XAMeujp2j/zOk9LkihgT3B7uATQm+bea
lIxF6fiMS7pxdGAwGHiPK3BWLBCICWqSN6NoXLBoleifn5iVjXeB8MYRbbYmQCsgHldRM9q7Ar4Z
WyFHBviIy68jwjOmbSIrsXApbx7jttwcv6uZoPPWkv7dyPUZqpVPdHEdQlJN6jy2xoFDxUVgQAm0
Gx6aLHUWPRe9rbh7mF6zZdlEOtcAIC9i7CUHdiLyR2PDFQAWGjXtj/LLwiz5YfUtHhrCXqIVpAiy
lTddtqWy5o1dkzwSzRaK6yCbltQp+JQ+QNVdkYwNIdti/uIS87GmU/uW10KpIZsSRtLpC7/UBylH
vYIqxHgqL/8ABwNof3ArmLPnD/IAvrnYkVWTefEBAWB0gF1X+RFLyh1PlHeXVfiM4Oeoi0y8ltYt
ceJQZg1LhyOwKQTp9VGUgCDOoseEI6fz5j+w8RPkNC+BgAm3tPORbRqIA2sRAIcfzKMw5biAp0IS
8e60kG6S3mBWsAvzHEFPp4jYgV1PmB4cQJsOZRYaIhatYjfab4g75t8E2jWy9eIXot/7gRVVEHzR
AtBTEDJ3ix8yprJXaEgeKPqGmLswZSQNdk81w1+IwAXamEkFboemAMqnUuZp4yEgxNZVEmgp7gp4
Sr/EH0kej1c7gROQP6lhra6hxClsnDNyNOD4hkACwlaCuoZTyPudoXBaC6QLJRorh3EQN0NgqdFV
F8uicGoPXcKs5eIPgVAQAmG1tw3AQFmxoR5X1D1XlzRCvELtXC+JjpS8+IxunYGBnSX+u5VuPmCP
MCURxWQQQZPPMYq2DUcpyVUM74fE+8wdxo6UX0cGAwBBkEFFSNcZLfhIPiXPd3FY7AHmVmTC0zic
BHggKUF7saksGU2qL+oZsXdZwQ44IYoR8vqGFUCnqELq6LuMAuziBmW2C9QiDbxUGtcukdxLDvxH
StRg4RB1Yg2KBzPKcBe2wD+IsUI2LGAJZdKMWqDaXFfL9R9SgOPiDQwUEDFVDviHq5b9VHsAXT31
MyXgH4l32CHzUPlBWt8yrLZtq47FUr2ADCHQ8hit8n0XADDG4oqCWEX0sr85AV2Ar3bK8HNrKqSh
H0Yzg87V8yh2UTqokYq9MiUBppCs4qGpWlYX7uXgFgo/RHLYJGBzRuvIwy5bJDJiRm4cHJ1z6hcF
p8m4adEX1cWVlQvrYIUtFPiMM9n9s3oSvO14nJovb0EKh5TUrNh5+4cXXsPKXBGzNh4l1cUWLADB
vlWXsdh/UGoLS4edYJUkvxKOcFp8wMgWCj1crREB8u5UoQs9sEIsF/cA05N1All7HuAHxZrwynrK
tX2ysARZ+zKaQAp6uAwX/pFtECbxzDPBUe0wGLt+4DgWyDgu94hNHJKPmUAKKn7Soht0PzDmUtPy
hcinPzCcASxe0uUEUZsd3nivyRTDA2xfgofMp64incP5IDXhgdd8ymaop8k1YHWpY0t9JRVDZLt5
5hFwko3CJI9r4GCA+V5VH5BSHxDd48p8JAItnqWWHudQBV6j+UF9Vgrx/wCuOonKox1MaVDcqNXC
sYfigwb4YYgSl5ojAVSH1BALmx2j4iJXWXxbHglyPeLtj+AzqhfMGWsG+/8AsaAVG97qeWgXEPPu
Ftek8UQS3OV/v7mF04KrnJpVC3+It/5QKefE4g5s9QPGIaDsNDQB78R0bkyhrEAoPZuHrpD9ZF9r
KPslmNlBA5KkUk154PMJ8AtZfuKuv+10jKK0XqxJsoIPCQUVS2a81FXu8rVHxLruoNKfE0bpb7GO
6Y2KjbmJEoKzutYTIIxZV3sBHXTkXmHDgW4Xkj2FRZnuB2ELltv8hf7GMlenrF2aEXOK32IVUpqo
Oz5YpykPYHJxYsHduxclmrk7P1KBZ1OHR/qYWxF5o4mVOptSZb9RsFrGovkYgNFe4Vam8l+mIDpp
ywtVaOS47WxLinYdy4OHmXXWhAX2xB54slVbmr5TIgA/KV8tgmJXUTguVUczbEQ0lVKm15bI+1Fo
DiGwmOw0DSufm6iUkWvxkVSt+WfMSzriT1kIlhD8Ib1CgFRvjIChZEu2QlFo7i0fNQWmdB3uJprl
lBbFWr9R0udiYGoLP3EwKhTKJr3cSxaLU6aiBjkZXQJRzFaFfDOBwkP5hsqUNfUOE2nETACD2SyF
CqY4x42JuB0+JZPZRY6Q3d2ZVClVQwQZgQ63mCMGq/UGVHgIdKrx5TgOgx6lIQUxW1pioDjHNx9Q
0JFRspgVdRPoKlcQFqYcRqUW+o/hK+xGati9iRRzN2w6jIYPYYKAOZcAUrI7mhbOqhlsovYhAU4u
FgbeKiQVA5gUotzmOV57TMBfUBxusi3W+oDCd1ZVy70EFy01yq9iKVKqJxEjhmNNa9ERXTWUepYo
RDbuK3a8yAOylcDgCUEaUV9yyuSwfUAE4XPmalWNPMQROGxHY0aT4lUUHFgcIBr4lpy3D5yCDrLB
h5ljKqYwQHhU9Rs9LFdtw7SEUYkUGgiMVE1+IcaD337mTAA+Z4S6E+JexQt6IQUAHn1LoVFSbWHQ
dbL3Pb25dUXgjbQYDvIRRWvI+5bIQAmcc4nxKvLI31EeuH9RKxNrMKTajqB4oFueohECaCW5WlZC
HWqTpl4eAn+ZVgtNJ8QQdTPFXCjlml3kWFEDvuMWbJR8whuYdgySIo85psmj4ITtEoMpQUAb7iUA
Wp7jahD9G4AIBQH1CzNKiKPVsHccWKO76mMNTHW3e/qWAVkX8G7PUEdKmTiYtB3cM0AS1+IUw2jf
mJ9Vq+O4g1YCuWIT+0E7atU4gs9I4RxKhUK/uUIipDwRnLR2DhgCFAb9Ec+Ex42d5SXxV7DRR0I5
i0F9QT2F77MBI5B5dPuCAYKfmA4RAPmLoxI5sxfRQviEopDXKLLNvd9jZfGIBDrBXg0uZfFpXuJS
u4nJ1CJWd3uA5BHKbX1CYNwZwlS81DAqeX7ZZIxC824ictS2L2Hz2K+0TTpnS7hV96k3nU5Go7Bs
qziditilnG3MKPkBb4YT0EDddf8AYjEDTwdkYwQnThh03dty31DnPSdrCbDYCeYMsqtvMuSHFoQD
+mAcVUZ6WwW77gUlqrO4w2BxquridJC+oOArRZowpwzCoRNu8u68SoWmhgBFAFfU/KVsY52K3NJB
tt4yBYRAgbXmO84C/uO6lQrxkQFCaOaiJS1LxyR1gFZxfEpuVFeV5gWBoTGHoaa4GMyXbpA8OS5l
JZpjz8wtW4oX3WfMMthLVK6liixWIXDo0OLh1LAY6nbeRWFhp7GW8NQHriCZAC9eLi/FZ6ODmW6W
xkDEvx5wnpG+Fxl4ROm9KmQjkhdjKl/RVJpaqDamUqa6hDuVBMK/iOClWO1N+Y9yoCk88yxrG1xr
uC64x2jsa32suhxV/DOdAw80eJSLBaus5YBbYH/nli2xPZD4giwbXQqBUVor9GwTmqVZ76ip0KnV
3HVBvNvphfLW5SUc/uNq7RSAVp+YEBQ1xRX5hLN6RsU2FjfLxLTwnJL4lD9BlZ8pTwRKWnlTG3z1
fUe5xEDi/LKs4tsII7L5lO4lz5KiXUxXwbMzKidZwwM1gOvKo0VZcCLAoKnRXUvvpyOBg/kUllAh
08sAqGnuAAMK3ar/ALGnvqPuYZ0A8RP7avLsrdVCKynccJLfQahjyJZswItoc9wNzm+4gDfcKbKb
YpzVbk2uvMt5RzZalVqCC5oXnqC8oiFbCXAA2BQykMNgsAGNhNtSrxLSoIfDAAPgGEL08qARmih5
g8KOLTVBanzARqgqCygGl/uESDk3wQlZ23ZbgQtrxBz0HFx8StczMBC9Eqxjdz6hwGfD2g9xA9ok
MFtDmAwBQCSh6+bgACVjRKINF1ccrhdeHMNRm1hhx14qH2gA8R+aAUxgA91CAVm08QEA8C9QImpt
7Rw457naD2ZRpKVQkIjEju5YpPmUU1APmWqj30hOBeilXeGr0iC4Swc1H2iA4sFuAAL7uLAILfmA
Ve5m2wtd7NhjWLFiFu/cIdsoDLjKpZtsQnwigu6ufDEmClwNiB1A2IRcBCYCqKhmUDSgaWDWxSy5
b4SoEaAbOfRw3pGVp0L1AnAF8jBeB7BCvQYl89RukqBfmXyKnBxCM4dHiAmD2W+YgOVWuoXw67cx
GbsvgjqilnhjLLaxpl33SLnZgVqA8xYKLloJRU2pp4IFIpQXw/2YNVS7JkE595f2QDc1xFIHXfUU
hA4vWXLDlTyTBtXVQ1SDSS8rW6nCIeoBcUDlA7HMz7+jzAGpHwMLXAPKsg47WPplY49h/KHIXgbX
1FKLz4iVRWy3CRwNQHvxH3gFlSU2SwaJt8voKxxwyN/mbRRQPfTGHmBOUZdNXzEyNnpaxyQn4A3E
Ntf4xzBpy20fj/ICPu1pH6wy3aqW1cQqp4mUw7NtLgyyJ/MDEBYJsU7XA+4RrgN9JXktQNrvX1A1
ukvEi0hXJgR0qFwKTXqKOZZ6TVnDBNOF0huO6mcC/qOxyAeNyNpiAXgvJQ7DG8cw8N0BuzxDR0qc
Wdd1g+vzLE3K7Pc3ybfEfHxKUHdcrlEJbA79Tc3mlhsrMMcIj7ggMKrm4yBcsub5jgPLHDK0iBl+
jmF2qAfzB1rwUvEYgRG+772X0YseRG6oqbhCF/y5AxAIaG4Hk55hw2oF8N0/MVsXg5sCQKpeF4eY
sJAd8ytEUdB3Gqe5w3fcPPiIhn4inNu9u7h3Yp3Pm41y9bcr4gWGR5w1+5TDsq/Ea4dOYntRA/Yc
QxdXTzE6AVSPWwGtM3iUUwCbR5m+YgWT4jL2tOAeiWQGdQOoB14qFlH5lEpFW71zFlVhxlDeDU5e
/c3TTVdB4hdkAGu4gXyL6PJDhftWbYvszfAXV/UpqjbwUnr1KV0sg1gK8NVGvPMfmClejJXxb4C7
8ymOGqoTbszmDaDp0HKmyIFvCR5ihqnDxKNWEGcp3kTRb+DUUdgNFvzEhbXdAIxpNZ04yMrsUcQW
ilKS/XxB1zEObYFam1Xs1kTLbuVkNl2M1cOaWxGcgEuiVBBmLDzzc0cBOqXNMa+RbYrXzGmK8q34
2KonJHK4g/ZqICcZzBy1Z0GvmMoaEstmx91sXm5ucEKPaXit22aHnuNm7go4iY8YWIVaBBue42Gr
0DywLiueIIFXmIspdQQQKXIqs4MWOIrTuNp88SkP6jR+oyp5QpChAmnLDKLY2NsSreILammX4TYP
N9wK9fkSrolXq78QR9sJ4IBatzNjRXBIBJR2hdsv+pZ6fIuN4rtrhNqNmuqCbXwo2ZFahHKlmUvB
gizoXj7iimlo4GXLpq4BAu9xiIVnQNgaHc0Xj4l6jmG6br1C7aQGihCVNW/EzHlBPG5a+XUziA2l
mkAKRlktOVqXAt6cWwdlFrh7lsK86XUGtpOCJmusGoRdDmKGN7d8Qu/9sTL1Uu5RUteMdEPVxuzG
luIxgPaMFOw3jsAA51dH5gT9Bqpqs0W49vvQXU2ATBMQK1tFuJU53HI2y2KpcnJicXH3G9jo3gjo
u4GESwLUuO/DHZgdWLggdEXau44r2eocACd9YPVd4G4MqyN34iYQ3FoSBHhBqUFa7uGTh8DDY6Ut
ffqcobyyc0V+0b2IoL/kCtnQEtGhG4QvNLx96W/+RYLVp4iYujwdyqLBVwQQC2ttRmiHR4jXKNmi
YSn3GTX65RwYO3uWpb3Dt1OFhiMybRN+ozFXuXUWfGyiSYj1HDo6rhAqtl33OEFFrCClvwGXMqFs
bnE3LkMe2rkUR7q25hZ1l3ByTVZFtdjQOSwqt58yk710QnxtGwnJLfsPYOBhUmCiqY5Ja9sc81iM
HRaCw7Y4Pembri+YQGtUcYdRCujX7gkG2pWWtvHmXhUKdlS6TRt5l2rsU1s77toaK6jwjewW0bZD
za002n1U76GI/mGCtP2nLAvfJKM0mkLm/Z0sW2CXXJ9SnDwEH1cvFnToxpSlrEYx7bVEh9+JbBBi
EIEGrksVWwNAICTaniO1JsE1tI4depqH60RnIUvmUsdvtCOG9vJibyGbOIRG9zMiOqtBx8Q1VTnF
IrGeLUktwIu9r735lk4e3ENN3LwIPV9CnHoy/wDP1FlGKXVOmVa7SKV+IEJPIifS4BuLacslPdZx
TVSzGkzOcRzp8uwsu7vzODDJQI8EFjdgG1gnYzVF3bfxPlTi1UaB2KfGOKRglKnRDpvBbqVU5PNM
XLh2ikVHlHRL6FzXUPxReiZAr4wFH5yPFWw4EqgIVZrn1Gzt9BTHEHKo0Yyqq512MSVz4B8RMDoe
blapOQVi145uIgVSl49QlZdP2yxtNC8ELFswf2QKK49zlWQTU5zBauWbQUNzmFN3S1xBbZY6nlYF
8pEo0ZSXVoJcQN2Ct/UdZ2KqfuEZF7C4iMl0coyELbiPubAbaKIZYBZQPmU+ZNDn7ghgmNKRlU0F
xLfuBVDYVn4mX47tHwLGHEo7nK7/AFLgl8IHcrwU4riKAJsss9y7sV1lPNxw6ynmgp01gxlWVcB+
seAzWwMsyDWOIKQXKKpEeDNnvmCHoaa8yilLAI6LJ64HmouVhX17mU/MJdxoE+kkSm5CqfMbrQAO
Z10rcQhu+hSh3nMuqOp1/EujDukuY7vOz6iOuYInfMvrYAm3GBPFDjYWe5Kr8wlFQiXgux0XGmw2
OAdwNRlByspDahoG3/JxPDto/wDMbuUHQgTOfiJDSNFTiGLK2Wg2vxAcY8xt19y3jHRemZABA3zb
KmU+45wagPMKygjTzFFFvcud6NmxrQUrEMctI7Nj3Bwb3kuSCLA4LqUFNBAJesVKYubU8IBqkcGg
c5G5AliEKg5xM5nUSTiU2Dd14YQAhxA3UbNJUQaZHSAFbcpJVsWPcVAzQcee5goKdsACymuocP7T
CxAeoC3uGEXfcBAdWG4cZULXG9wjmborZUwOxsRieY7lZwbxxDMNFYbKUOlb3KW00AuOMQxDSAc5
xOeBpSOZINeUvIt8ojm126rqZho6LKwiHhcIHIMTUp9uQhseMpMexHVdurWpdyzzFLLv3AJKevEO
004glfMbpR5q5IhC1FXuXKFaVzLbkegPiAV8Hn8p2mIvWxke/AY1+AKqXSgI8HzKRnLvpK5xcABL
UN4jiElenNSv1A48UaCbvnMuNi1XnTCLzgub+pm7CkfqJwTICrAXf1LFLQiWaloXDO70ZSoFGBVV
O74NK9IfyHAtmpN90lT2FsjrVaucon2QcHMvrVbcBABmEOL9RdFB4updAVh9zkvhCoA2xQ1jLeA4
BBwFv4QKaNpk7QYUUV4h8AJlgRoWjXJlLYGqIFC0RUNGYUrmIXK48wmAVuj+IVNKrhw9jFpHMtRx
CL0tKZBteOSZsrQq2JVYWAcQeq3eFXzDjcItq4i4yoOYDOWxfcRFfYDg8Rq3FtIfmF0MgNalB1zH
GERHdymqqrulMBVphfMII4rdsbHomsa/XoQEVhYLI3ShoU2UkBUGfuNNt29xa80ZPCKqjmZ7Ojzf
PxA4DeG9Sp0BhUTBFob9QM3QB+idPwEJUCjHlRkwKgsHEeROEC3C8Lk+CHULQVwSuw38RnXLxHc7
lDjpkSwIqwIgVRYFr++oNIta9GVyjapyxeA08AhHFuAeYDDYA6v7mpDyIfUXWjAAtavIuoBw52Gu
GsBjNn0TA3y/M100FPcN8ntB/cAhTkDPxK4gFgo24BAhqCs9wEEVgOxGwUAcM44lQWyuvvXmyEDp
I/1Sipq2apHEDJbb3EGQufupaIqQ6ohhF0KXB4BqE2K/Dzjfm4EeUInEAohSvHP0wnm5FzvGxwqq
GmzRojx1BiajjOOJiJ6+glUaUBLcKAEcLvYJVKG1DIBfrHXyKdmvhjYG4UA8Tjr34D1c4UkfJEYr
MAJTWVYVRALUa6VE7FlegtyZ1o7jpGnluuzzLlUKGmiCdWCg4OwOyCNXhFJ+IsYRQpnxOiSMs+IR
4Uoa5lGWiBqu3B9s2a4QmxHMCviMbh8pb3FAgsALY1rkENXi4gtDSvaoVKN6N9/5HBu2Q17oiQuO
OT3ApLnPHcGU2qAp8wWAA9kpA/TBAkmyCF4U7iwIosV8wi7Daudjfe5YAK62CBfjUutiWG3oqx8w
ItZjKTlj9dVVlfLLByjoHZ7gInVLAvJ0/PVa+MlTbu1G4iILgV9wbCKDio3Uyx4hqAfAOK3uHFq0
q+Hk/EqMjMVX9QmVK0KR3E9h2mV/XM4wh5w6uAxSBRE8V8XCdBUM7yb80LgJUlJm3Tn9SuxVYpvc
mf6wOQ7/AFMCBgup0ijFwgYqVUZBtbjpWi+6BaGVoMWplH+y3AwqpcMAEjyHjPmVOqZ8q/NfuV+4
TysKK6ouWN7sD0ohoX9RFwxIFar3FQPkVK+pUAAvmpY9mCFC69RzXB0x7ZMOROMS6s8R8CVDle/1
HQRS+CEKhAM1HquaA7EnqSqOd4hc0c5Ec8EbLmGQjJQC3yGRlRwsYyyAukqpqVjmLgDdQhhqA8XE
C0YsNH3CnRBZWThiNgeolJf6hCq5gtmZFIPcKu8ht8ZaruKq1aRkZkCbOHioMF7UCw1zkNhUqm67
AQFeKOBoLRUf1ooNAuA3FGyoo3BDl9QQBv8AsluAG1zFZl5ZbMVs8y7pi/KOgrxMGz4B55iBerKP
Uok0BHewQKzfUqI2LRlRXwMYWBTJgZTgORTmDdna/qMKE30lRt9qxg5eQTmFooGEpotNJ+pUk3b+
USKglOIrVJBK0CjmEQyGZ1BLic+ISnNcTIENjSXIKJZ6j7odB7iNF+HxE4rwRpPWPINijM4QzDz0
HcejT4xJk+FcSpkIYBNj554MzymtRIEtcruXANwCDLknGUwGc/EcVVMGX+UaK4x6hRZUctWWAgs7
IFF1qRBlWw4y5ZiaxjfQKETyAmdkAgAVkOgcC4cKTA3wUuDDBGio37g8oRRgnKWFbTqpRKKI41oD
y8waDXDIY8AZcvgXG2LYZnSLW6KWJJihVQroj5Go96AsgAhYt9TkZcekctAOJxGKkDG4lodQ9l6w
lLJ07IcvgPUKiLEGz/jEiAGJ8ES3dwvlDTkF8RBo4jqmGgg2qVODu9buoF4TSj6lgxWD5uDBKq+x
CpafBWQagQl6qXONtvJuakKaVMt10/UQrQRQdM4zMKMgBNbn7h8sTycZBoVfgrhlZqo232ImLt+U
sqi2/KF4l25a79E7wpuTcMm+IFUBjXFlyhZabzniUqKBb6GBgPYe+ZSa2tNYkqiJ78SnhDfxEVdB
aCHTCenuAap7G+5fzc/gYkEDXzgoOinLR/2GCLLg5eYuAIw49SpwVuRLWcWIIV9S1ouxuBmHgHXx
L49sLYPUvK9NXUNg60cvEIEKlV14h/OIKlG2XQJU6LvE7pIJPBX08/EuBE+Z91Cq12nuL5gczzEv
LeHCFcRCsVyM4FaUh9SiKgXxRMAWFBPiGJvV0DLUBwLgmKoNu7UZoLVbpG7lqA5AX2+oWs1ioJzL
RtEE9dwdnYsqtvMTIygVGxKFeq3SpjbUrp6lWBdOfEfiIAeSZu4KYQqVASjjI5rAq2APEdSudOb5
lSLGQxvmJRee5y6xVy2imkNK74l/0K193cEg0KpxsoZcICX1TVfj1HEKd6YxFRhet4/UeJaqdDLG
EHbbXcEngx3CoHcAatt/2AmBJNl85HmRo3WmwUhidLcuHbdMEe4IK06e4LznfiYpVsOh8Sy4U1XX
EIzw08bG2SQF1twKEYo7lw7GiyogivvuEUEU5JQ1OPffMMMQC652EIOaEcnUxJpPa7goDg/KJUST
mjmAYqP5JiKrsXriMOoYqeVg11ONXLOMcK5xxBHsBM7IlqSL0oTIv7AGcaTDwtPq4Ui2WLOQ/ECx
UXxu3fcoOlUuiUuLC+7I6euk1WZTzsTrYbQo/kS6PqyBv7gJxBDriAZmzdG5XcDgEWd04inc3Sh3
WHgg1P5ixgvNgUlMlnyIllcxiLggKsvmUMlpL+olRmdxtgUS7CmsevMscC3GVpbewwFArvicSpCL
8thFVQX3mS60cN0K6iOLVZx8y3imyXLWzEA4gL7N9VwfXK0PxDNUYDFbCrfllEKKKspA2JfxE/IT
EuSVxPUItW08e4ZPsPMBsKHFzLaXN1hc7KeImpPz3PJAraTqcJqyEtGIgCqLYM2OSqBbuIKUaPxA
k0Ih3K6DVf4jrRXL5hxM286lUaC2pU5VRYNILrIbgdR2RpOjSuZdCwW4+rWIMyX7dMTSLRHHPMaw
0H9Rmvj31GVxpR4hmIpnzDLgNQA0GRVydB5WUk0GhVFcRvCKuDT4g3TaUpq4chAtD1GYSzWS5nEK
YiAjCjHcQtQ1XFmjmdz5gXc8P5eIDzMbfqatdvAeI+dKjy2ZKS2uL/mEpSAnmUosZAMymZPMCBAQ
WEgRAh5OYRTmioVqtTuOU6WWkGASryDySXBraeLRYCWgR4KjFYp/UQYBXSyZ2Mt+42QxVRiqQRhK
4HqZLm0v4hZK7V4p/kWjAM4olsPyG8Yu3Hkl2QVXGLVpBTWCURaaufMUZwqn3CitL7mAvMoGQDvz
DUN3EzQByIdELPiN5MAlAXdTmFYdl56oJSUKLamalbCP5T0dSuo5yEmsH1NaAY7qBaKHGB6ca38Q
RVtqHZBUF2d8McpLbU/ECx3qINLS7uOBMX+47s4lTaw6vMTH4H8yyoG5xrL87o3ySgdqNHtupc6E
NfSBC64Mplo+yMZt4HjYDcVar+5a1o0ihdqthATm1EdQEbKcmxoF9PxFTDgfcKBQKuIRQEp8y+iN
CeEqxYsnI4A6hCqfTA8F2LOFVr6lqtNUYY3QFPcaEUuPLIBW6weOYCPUr+Y0GPre4+gI/SNfCET6
5iqbjDVhmSpacVFeVBVe0z3Ch01TGDYrc9wOBlUULeR+Ab4wr4h2FSBLcCwHxLf4AnC3iXVFD3UQ
AqfQHniWaX7R9yFJUsLL+YX1asnfxCoirzzK/TYRQULQYftMopvnYh9P+SdnAX8R9iwVWh1BYjQP
3CNwcJhs1gWv5ZEXW/4n/I4gK8HcRaWGnGkZRsjtiSoLi3ZWSwsJZ4juHbKviBFilXvf7mJhS8lO
4bC4gfEMBaNVNf3pjRq5ZjUCnbbMbvbO8lNbpfJsT/jVldNQA3WXKsNdPX/YzaByfmEBcFRYJpK8
Dda54ltqS552LKX4NqANGgt+YSl+O3qLAA2sF5hVPQN8wUE4zyWx35uYXfEBrllu+IK2xS/cAm9A
FxzsBD5IkaixvvJs+ljo1nU8JabeZvCG19wEQuhjHYIhnaVnVKH3UBbdmr6uPnbHYDlFZFl+DHfq
HYlkN9xIUXcfHEvHCENVcT7SB+UZCYV4eoWLScVrk2K7UxmRB0uUPhhAB7NpcpdHAOQZcS36GPEI
eVATXajaRzGQ1MrPuyLBsBT5/wCMMU9Pk/8AyOcCA+chWq1SyjmW9hsFoQvz0RAy4WwI+HAY3JiL
d01BvkEqoyvmcyAzxFFamKd3ADetq522P3mvkkrnra+KIGa0gvFQXHHFIGr3zHlLZp8XBAcZLyth
QDVxUnFRWNDF7ZzEpWT0EsL4o2AS56iJaHyTWeHKo1KPEEeQeLg8Da3rmPryXR3ZDqp/beIdC2l9
5DYCmW8Q3bqa8wV6Q/lKVVvzZKzlVE0hT7UrzcTbNK4nruC+ZwFVrRoXB32wU+qzzFiWaeMlxBbA
ncqlfuCnf1EiDKjQ5v4g2Xj3GzMC1JXuO0K5h6LhzQ5Dq3UnKNaMIDTfPiXIdj0LiQQWqPWtNujY
mFIAuC4XG6QfiLp1eYB0KbdLYoKphedju6e4LNi73FgNu3nZYtG0DrI7tcFvZmdVIhXNVKVJAuEu
IdqK8zAR4Ul3k7w4gRx5UsYiGoFd1av1PMtxZt8xIJaI3f1LFtM12Xsr2nmOBO2j1AJWeZr0sqvi
UEbGvYmGD7gdrwqLHDydy9y5cNrNiOeeo32AEclUewp2IjdDG0fqPjn51EMoSKR1AaKDfsh5tuEX
pHqjF8wb7cmFbqFzGAXV8wKW9s5kyiuYhD4tjuXVBFvxKYRae4QB0n6nFA8nUEiF4IibcdVuMPcy
QoiuT5qUQbtCWjjMYjINrWLSV8Y8sLd7iySq6hKkaDe5YyNmuon+tbAoF7WxG2pKIYykbp8SvgOk
JJvkliTzjGjQGoHE0A7jS1XDFlMPzGgFji+ovXfBAqZd7cR7EQu4ZmzmQU6BU6gk0UCsqcDV/UDl
rc+IlNIc8wpAxu+o0C1dEA2bW7R/sXQQ6nxWpZ+HYeoLuVYejICth1lwfUuWMd5t1bcqsNl9AGfq
VrXLI6Cxg5+aO7jA2nAeZ62E8OwYMLNisIlBXUcS2tff+QYmUd9QXRFuvmIdpZDyqLHm2KQoT8oY
XetsFVaGEfzIu+YoDyRTfXc+IB357fMfAroFXF9YafqYii6OyMfSeeslTYOSxoKWg+otVMD3EGfF
BUKZSoPZTCI1I8NtgvCODxxAsVU8WXAOwmsapbLPcMBKQzLi5HwDoq/EXsCEFWwqygW7jeiG6F/i
FicUI1GJ5Y4h8wRRB6bmAgx7vzCe8FcbOXeMe/uGbSgrB8+4MHZnyuXAEF8Vsa/J1wtylYoLSvqc
J+LKXYk5QBv5hIFAsHUGUeg0d8wIGBfey9u7UPUctIA/L3EomFhURC0XuJa/EFHYQ36C4CuJWeGW
XlqRnPgWW+rmid8hHUvRo/EgIEbnGVUYqkVsqKrzEeQmtFOPjuV/7EcD/wCI76oBXfuNG+ILPT1C
+VF9pU3TcveT/stKBQw24mUAVezD1cFPZBBGWB77jU41V2HEq0WRwFvP5m55uDy2pSpqugsqCD5a
5V0/EAwIcXj5iE9hSUPEtUek8Uyzio/qxcnKBQ/MMG2oGvc5wOHhcvQ46HD0yzEC0dTxEuFo8h4g
Y01D2eIPDpazV6ly568rL8QaYYt7S7fZS+FE6qiG8iq592OYHT7asuaCsD2V/EqulgLveYJocZ8t
9wvmaVWjSEUVdmoMo2pj1ekUvZ5Oz3HM4l0GbLxb38bd/cukyrxaJalJA1HzfqPCsLX3zOqXVC3m
Kk+ZrNiidq91HiNkKMBYQ2UroEiwyaK8mObtxyXf8QW3VjSt8+4EpVHDZz9SoIIYCw/vRXTyfqWa
sQCV3hH8o4gVtaiFU0hoaNe4IVl+5ZQPxEtvMrYoe3shTVs+ZFhbPUsIGDstKCDZcNMU13EULTN7
nWp9TMGl8MlEQEcudQQqApORe4wuAgdTFRjTwX3AYLOV8NQ8SKAm8xDnsCbudMbGkrUdnmXn2Jau
UtNXXS+vqL1hE15pH6oQR7qNMNOOkO5UHbbdR0a78ziYsVtXEqIOMNkgRAgbbTiC03xBKbx6gjRR
6mule4XFbZgGMVDbBr0ILILCPDBEcjsUQK6U4qGhQSoxqwVp4YX0tu9QZhwsmb1NiIRWE9Ss2g0p
l8haE4QFo+YCMRo8wTygURGpAHyhixaqwXhGhHM0jmWcxDlySzYnibWHI1mgq+EvevBOPqDSvgNK
lbCME50op8XKPcr0jev5B37j7owLhMpC69R41akJD11luWAjcReNlOCg2KleWUGCrfC5RHDzlJL1
IRAjm5UonVu4+Mvms1xKzmJ2zAXKVI3mwlPYItnc0w8RJCrkXAJqLqet9Q8RyBsvwzTkHPOQ7O07
USttQ3hzLOMRlYk4Rh8RlpGqoLZSDAj8MPP4oxIVutJ0BdVxDJrq0UG7HZHsvIZrR6C/cRTl/mbA
TqV2NoQMW4AuVqh59EQVc0zi7Dqx2PXOZQghLaZ5mhfCuBAdsF/MGwFcw9fOC+SXUyjsxC7xlKli
EmKaVDyMBTzEcGkfU8x8HRjsPH3wRABPPP1K+t1xFsQwp5g861a4IHYWW7mIlqvqKlQsOaJuU0rm
LRyp7+oOKVjffcLDccOXHKQ2M7CCoOreIyi8kfiABKY9KhsKsDw3k4QiB9IwkVVpZkDtsa7jDwAc
qb5hGoa4F+ZYdWATMxu9lnKNEsV74mDxXmNbR83KYBWJNiyKUaLuUwGCPUQeNpgR0lE4ZkcL0UFD
CgL2eGKyb/4pnRzB31+IKuLQNvuXKBa4+YwUVd2bvEPragxhaI1vUDCvWmVUew2xaU0LwMy0mWWR
C0X5/c3bG/Fdy3PEL65j4VElsh+QWMS0sJ5gCUEN3sJ5xQcwpdVTlDYEiny8cxFctVyvZCe5bD7b
AsIyO1O9pkUeF3mFViQqDR3hBa6hSvlUh+O5VnS0f7HFseC1cWAuQ+LuK1Totv3Ex1bHpgRn7Tgp
z8y8oF03d/uPn2p8ZGMth8yxrfbaeFQlbQeoJaXDxA0Bgto8S9PmjSBaQ6tu4leO+0r39RjXJQIL
GSsMWAuolTl3HA0x2jPiJ9wEbGGy5g6quvqN/IUFFB8xRilvz8wPxFWGm6ZYQ0V5vq7lFRrb+Zau
GXwkaSKWG/c4KcDA1HHkG7ebjzEnpD8xKy7qqXELlfLAzHE9sLO1NgNf7l4qWy2oYVwpvIQOruGV
fM1cBgthpeXqXCgzqXee5uF4GripTZ5igxPWfLK2y6ta+Zy8i7cQ7+6D/kqbpE9OaqI5XFsR+2eW
PBhFF8uHehzKkgpU0z/I2pa3zzHoRYjwzhR6C1R9xi5yrcws1nk2EiWSo3zFM2W23tEuFmtjYGLe
XwhaBCxT42c2hW9JqBwdVDg+nld+fmWhRepUBot6afzKIvTcdalqLYVvtGtynGsNW6EtJ4mX56Sy
XHP8yyjSTa47iNq5jzvcsKWcLfqWDef/AMTQeoqH7EVItE5li8NLnmnmJvCqjw6p4ltmy9tQ456y
PjksWyH0tViKHgU8/uYAPRx7iiv3OnxC8OCRQRt08t5BzI0OJuAuHMNp3XZ49wCPIe4pByOuJsWz
ayyU+Ii8SwpY9E4mB7iAoYjLmdxUOcMY+NEHkJxoqIvIeZdGrYwh0bCNEoxgyKh2cTYgeYqt7Zvc
P9EKUgyq01SFuovU+Qm3QfmOlfU8wAqW/cUaXRY4SR5dlHCdDDARupdvkUT+4es35PEaKQ8NygA4
dt/zBN4WCf8AZdZeF8MCouqBVUt8p5tf0yngvxF6V6m2DgUjKtkPb/sW0Bu7h/Q1F3ALt83sta+w
y1tG/CPXZi4+5gAvdJCS1RPErAEwbSVxhG8hCBPUvmKPYDfEZb2WsmWZFOWNAwcJVy2r8Sgb7EVN
C2bREm0que/cUcdVFCW2rd3ZV0vBykaCJgC39xAd/MvqsW0u2AqDKssFpPdsQjlssS3deIdmoMXh
4husZbbiO1hhZdNhfzBLYvAz8sAyOPkNil/Uq5eBHfFKF2z3LA2aFJBMUpQ3ENg5jdwihfOEcg97
eYrhWapl6wmgn3HYo+USpeMjwF3B5lMBcTnlejbCxy9tw4eLqmfUGcB4v7ncy9ZacZyuSnHLFGXx
PMcQmNygZ/iF+gptiBpErQSiAlrVTKDxQ3Fzp8i4arS+7lYbmiKn1Er8VQioxbjZa/8ABd3Lw36E
vzEC0PGKi9+3nmV9wz9S570Q5S7VgOWZrDrt9y3lc+CITxQOx+pwJoYa6Y5LDWO5f0hNlXK7igvR
Yr9I8UWh4nxGo2vE5vJ5lhGhHMoiNrCU+8mt9RpZOHh8SgRZWofHS1U3UaBlVlTD3MsuETYtjxKo
0qnqvEcoV3Cy+t+pZCcLy4bbJYV/M5FeYwVDfQpj9SvQOAqD1i3TAHxLm75WnqHxFyytS5EHIip8
xgsOzCm7cpkaeh2XiFWPaIl3/iOJJhS5ayZaWVidvBSXT7lvjLtSLU32YyhC13V71EbraFvuZVym
qSW/G0jv4igt+FczGxGgxmg8Bkrlqcly8PAxoUfEX6X8cx+lfQm/4uB10wOT8yrMdVR/cSC8Nmz3
HDkFP8kpHb0BR+4aSVnQ/UtYQRiPiJXyeoC3I9wGp7P+sDqZEH8kNXkUKAR5eXuJQG+4HFl15MHY
Y4jqEYVn5nKQYL+oZTZSsRhlkquLR4GvMcEFSkMXFyHESirLqf4gLXULp7WO2XogvlIeJgkAFkAH
0+NnEOB/IZHIsLA4+IwiC8A7x8xawVYShYRd1PvSdiosPIs9YpdxBe2L4v5j1CFJZ8XB/wBVCYAC
w05AiAYMtBNcQzWuv1PMgRHO7QU16j+T5LLOSMOVYHcQKIuuMu4seR8S69lOS/8AqhHJgx89yw45
IaMsQOsaaZhsDolbKq2qZwW2totpfxKPWgTpDxgkbVxB5Kmlv/krZrVPuXjqCjHYCuCvEO4+EeF7
ufqU0t3DxLo4WuEeEAJZ9kiKO1QSi9Ig4AiKALdfUtyyq/NTUHEDCK2KgjyBgFOl4JSrMlOSpyOL
9T4YKp/ceCbcRgcDIYdnpUvQU8ZB2u3LNQoURyZH4GF6VVPcO24SdK5glhIoS6KNonUVZxOSS7ie
+0XwINT+DpHKllmSvkq1U7PBWdqm6krvgxYVQL+Y+3T2GxwI+hlg5UdIP5iqvVwI6uP/AERL2XFN
sBGim7LKsXasuKYGwidkw9ssRK4OR11BQJCNT4MjuWPw5jnb5K2UMoYV1Ljrq64iEHOgsKwVKMnA
wtFQTL002AlFCjFir9AhGgPowlig4pUxno4CKZNIro8sCKjtEdUwF46l6BdcRKg8uSABIKupQKFr
RAwyjPIw8AYV9QjTh2GmoRKsDzC9GKpC7Eaa5hYpVT2Ye8c0LJcCCU2YxzJW8Rfx6JeQCWnpIteH
xGwGr0e5zjWKIxY2tnk/MerboIjl26HuH2tVYcxWyG96hpfIdMPtSmENq0WQbcAF10LgilpQ5+Yo
aWyDuF8KXImiASnDGpYeE515gQDFrRVqhCubiEdWqlACr3vEc0It5Qo3J4TT0WD8wxKKsbAGwFCu
I50ld/OzSBLfCW24niOIlVx4QqVqTDZAFcCXkgRrg7PoRBlBReq5cy+GFWN7W24weCxeMpA6wQoK
Bq648TGFbwEL3N52DejeRLjKfGYDToTHIQC2o7RfoC2BVYZjsAAcjtOaCmyw2ZIvl2jwoGZwi/pg
DxzK26BUqf7DpCNoS+EM+hK6ElW7RtVJS1f5J1BhVVzY2HjcDReQ7LnLTIKNVLnBcIopmZW9WEpv
qNeE1DcLRVDRvmGhENs4fMAFuqxnUZcLTj5nkpYF/ctr64ht+MTqYcbdXANWW+YsAQzdR1YQl9b5
gnRFFBLAnyO4FVDtVKCCNvqZLcB68s8s4+EQIQUt5iEi6fxF6O5Z7gWCr4+chuScVsWmdQVREDWa
1Fx5RdOwB5zXn5I1BA0B+oQ1m8CwMdTFJN8mEMzyIfdS0BU5bhFRbOBg/wAqil0yhSwpHErOC2DO
Iwm6g8QJtyFqovaSyU9yqERbVvUIVQBCqldwEW2kpYAsmfbF7V+kpmZkSHMMWUClQKtr2ObgwhVH
Ah7AgSy2MNG049TBd1AZCSjziK1wLdAkEA8ErgYlyKT5TDk6E3cuUltarhZS8SnIh3OImYPKLQBE
tdbH2NITtRnuTAk5Lf1LBTkpR3zLg6oGrzImM5gviVvedoWiVnyLgvzHJfVZ0Ncyvj7AAvUr1wEW
KXFEIKrsRaESaNupmsgVy3xOi7EXR8TBMEwPHEo+nIclvErZWODuQElLtAoSCUGtRz0SjQBIeYrU
FLF23/yVisuxNq4MQSSnn4iUcxR5G9yBBWpSl8TPMh1UPcK1VjxVw/cgYKSF5vGN6/3AdGX/ADMt
ebQX7/Et2ikvC6uNOPlwFNg/PRCXTx6lsMge2DPykKo9ygABcrgDV3DxUECt7+thYHYOS2IxDe//
ANUv+ILgjVlyw58i/P7uH3iMt0P+QOUJsaG8/U7DAuEOQiKmg7MMELI8FbhGwT6pXEclD5CmWX0j
7O/1EF0VrtdSGaXPbw+qmyg9Hu5dIBTm0M0YSkSzfEMzHwwKq7O42k56gC+/mVtJcHDxAIt54Jib
PJAq9PqO4eMAUC+yOxQWYV3NHB7igVrfErHYrt64iFRAxl+kPVrvBQ8SzokXxXMEMg3xCRhX+oDf
RVtMJLuKRGcYHivMFWtq8rD9HDYNOkTXcMcNr+ohAIUoqtlD5sH8wfWsbTqGKmFMGyIRjY0QFKbr
Y6q4jbkJeENhkJSvcAq7nNaVNo19R1syr4BTxvMqNNCKjQFFvdQCBax+oyACwI7grYTZrZTXUbXV
gWcQ8UPHxA4V0kDlhaVMJAMEMvwVmMQFQ0TeJXupeHLENaXXEpvZrsyXUrVY4JagchRCOWGXUagd
B5Zn41WEYmRV8Shii8ekNIB6cyzRbaK4jkxdGcCoTwgGDjG42wsVEhX0gIfQCDfCuDuWyh3PUbg1
09pTlHgIkvl69weOka4IkUoETzC0ShVIlagYajj7PSx23VTiDkK1dbK3l9WQSL1aQN2eGuIdQpCC
oAVWjwwDUDMjtUasBpfMbCtd16QEVluQU6eoXeKliYCerhrrGHjIzcU84QL9TQPLUy6GzqPrAs/i
DpCOS54hxOOYRjGf1KPxpglrArzsOGlx+pbp5SWwxwOogLK2s+Jsp0qbIfBW6B6AK8MZrgivDzDI
FW5ahQx13DyroAUwVYjlv9ThaZGpDChoeIqw0dJxFVS6ZT3jz9R2og86XFFlgMFPa3OYz4jrq4TB
lcH5oadECXNRBGbvNXuE2qawXmDqSxDiBMiFBzUGgkBt+IfChKhAkfD5ndElv4h8BZ+thAast6mA
kh3BuHWy181oJoCnmEapXUc9RdECs7h4LIvgdgc8i/ccw+nzGXTluuOYlguQbQg2PnnNdQa1l4rg
5jNiPLl9QERyK4EXBFgOGVnvI3GPGju3cuVYSHwdzRzYn/vmGwG6PX1NjFKz5lSY8U+I9aW3tQuh
paoqqJVmq+iI4OtcpMfRwGLdP7JvgwM/CI6DlvbsUk1WIts+yf8ASUxl4URBetTtRTrnUXDuTZhB
ZdQc9VFQGjBGkEaBPDLwqIUANhXqA5FNHrSN2ruNVfBKRYIv3z/MyOK4BdwV4ZPFsLUa0r8RMgaP
5E5wRaZnzHZ1oImzdFC3TYaJ5nnN/mOF0vGV6y89f6UqZanOsg4LQF2PMPrZlfxF1g3naDYwtKeI
aTuGqcmzUKnY8D+ISiF1R4cmr7BR5hiNtxyQyryiUFFE7BcsFbIHxdbGYIGTyz/Y0K28C5Q4Tb72
EFopjMjWcBfVxRhB+iAOnRFfDBlUGxYXx/2C4glXr3DmHH5yHy/gvLI9WtdDiwnHQHTvcTXDngRc
WEm7z3OZFt4ojttET7/2aDBTzPExFVxfMSmmn1wQT67aC1/8m/8ACnB95H2hgBx7bvuH3XSmjcBn
QpvjIZAvm99wZBhcur/crdSEnHP/ACCADLMgmrpuFrxCoLqcH5/MsA5CqS4Ms/EwsNBSb/sLw917
ZYHKo/TOL0LtNlYaVR9Fy4hT8eMf3OM41zCuFJs1uf1CG7J9kXP3FG1ANbIcjYQH/jcF7Rr+BjmG
3TSLF0TLullxikHt4gjsPM42Oyl2FSxSEVNBY14lA1ZLADhhexA2VWTPMS9qYiFxBpzOZXuDg1fE
C74DJUXlu31FgGu3mMYKYaw2uyt8gpn6ndQCuoBcmTt08wIr5W9XuHgcN/UNF4TIlC2l+Yg6qbdl
EIU4gtYqA4fKCnwQUC1Nst+cv8RWmqND4lpVUWO9j2tTE9S8wA7sNI8xq8e4lOXBrwIqtlNm8TVP
KxVebEBHlnVq78RACoFL+IZwPJ+YV954fcx9slS15ViwcVuGMIay4xHPT4gVA+EWGNog7LwQZvWR
qLYkZiBp38QFWmrsnEKA4jtVaQBG1KQPPERQNLpi17rVeP8A7OkyzUWpRwbWzuVAG+kc1TwlGthU
pDLPEtKWXscrYC5zfFFxRhehWpTWCtPEtovZScjpbWvuUHrCorvuASmEd4SL62PHAyrg1XTKsWFR
+ZTAumpaTojVAQBlEds/UFg44ht3OEJweYDPY7I4aioQaDuQR7F/iELml3AjArdillrBwEVS9wVX
jgviUSGcRCZLC+oIC1YdQwiKrPpCYWUdgU+6F7zCaLCxfNR1IRWJvWFut4jLYug+pbI4XzHZY3X3
D6EQv4j8PxAX+IvMB0hihNBhsBdHIQ3YrOZWaieebjANtVwwi5CK0q/tKBFFlplU8Q8RplrX4yNp
awv1NMAgpzDRF0dTOtWRJUXZDMYPPmFmbaMsgRBtp0+GLkkOXUQSOgf3OfgAb2EDCGn1BXFDi/HE
YDeh+ZtMCyEdqsdPEvjFaPHcOpC/F8wuld7wK5CM6OToj6FxLkOXPF6w4Wv23G8C5KioBL8T0pas
8EI2xbv3MGkJTFtN+JdWNQPXcbC4ivjIkBr8EwsVBee4kmph+OZfhVRD4Y6wsAIRFZX1kt9AFfgi
+CqtiXB0qI9RYSF2nmpZu2oX4gDBZBYvqnq3fcyTgelxeJVXZV8wqdLr4RBA1jbfjJU8QTwY4Vu0
8pPGoDdrexjIxYF01i3lrAeP+xcHX0rKECf/AAzEaEVjR1KqxFNRTQbs3qUqN2L7Je5y4+h/yYtc
05PFynej+iJBOEFgkO/ZDGgU+OKgddalcZ+ow1kLOCvuYxIKrefMzZUSkvqipjLIJLlWP0gsdcIC
eDQ3IPrG5RLVNPghZpK30wqOpdVOCDBQRHDIISgQPK5RbLSV5og15pXpyhEkQe05hNaqeppdt14i
sZrRUSVgz1l/zNULIOCv/kV6goL8TLJBX3DKEVvSEeI8Hd8xRRgC4ATdwfhgMgy5cwjG6DGbG0nJ
T4pgtiBuuzL4Sli6li3A1yXGs3/MMHcwUZzx+IYkwrxkOgoaOZTI4LgDGlUhSclXCEOl/hheZtVQ
KwGBa3a7inGxnqFIPOgWGlz289b/AIi1qgPtOIAzzr/sr3EUoPmIEsJ65WKWdC/FQjS1NpZlZ/wL
Y5nwzV4bSFwfYRwJYtUCuWVkwqeOZTcket/2AWZG6t7jsgPL55uVQ1pBtTAKo1PGwTyR6vn+IP2h
6hfpHffaJmuXRFK22DQ03uFDcPbZYN0AafmX4oAPBhrnJHJTcEIIEeJWQ4gev+zpVJ01OT0Qq8u7
hTQ7zHSFVXcdVXEo/J7gNC5o6PUYLXEp4JToaaR4XRy1NAnlYaVasq4C1sGpRXNcQxZwjxXUB50z
xUp8WvydSgh4M6s/2JbhA5mThYPcrI2YHUtKwBR9TsgyPzK6aG/tCXLodfEdA6BfEpNFZ5yUtAHz
BFS4Y8QfDZV+JRknE0z5JYUncB1+YM3zLDPMRd65lxQZGqwfXcBVOnR4gYQKFNPcrRlMYkubfNwW
oRKJvAVL53Iv0YcXs9YdQTVQsiRYI38S5COBcZ029I3eCJfMcEBy2VpxThtVR4x9oaC04uJizv4i
MFVXuWYDCo3VVM9yxMFHVNf5ASgHmMQrXIxKCqvwbHnAt0LBDLyCXKWh9cy4VoHzGYRXtiLV3TO8
joVM2+ZWaVLEyrqIbwgX3sQgp5g2CK5jalaqHiBjRq/Mo1baURiFs4Ii1LfhL6AaJSbCsqX65Bfi
GqI2AlQEZdAoPEIwWKozmIeI72UJnmEeCuEIIA21giG0gS8ag7LvFFu/EKm2rXiU3N2ytOYtJ6Hz
CTTQKcNZFwatkYg5XSBAAqfcRBu1rrI26W98xLQeD2jR6Ta/UtOgto8S04RtN7g5ZZR+IiwA1rqH
adqfDBnlpR2iM3C3NjBZHVjF5MXhOQsFvEFpYqcH1MVhxA6jy+mo95K3aidmEeRhXYIBpWVSBdFc
16qN8s2XiABmF4yIANKIy9gS4Mb1WUPB4itr21LmlVuwuNl4RHx0pXHCrSVJweRzBY54XPzB2QiO
6e4ardC8l1sEWCCTk8cmEeAPLCSBCA5XxNpVQ1rfEZc9KxRyqqr6qcLBW81MA6Grj1YpAD1HjVtR
83pNl7Val3KFN8RABS9YrfuYCGUQboHuNTgJ5EiL9afGR5FLXzLbw0uv5jiQgNsYOVCVvJ3M+vCe
IzNEFRNBsojaP+R6yFAdbHR2nzSyx9XC5YSIN8kQiXc4wh9Rgcl8DLHIPLqWuAjbLeYa+6kJj5hb
s13+Er57Qq/md1gHdE9o9z8KlOOiAWGG4/8Av4iGeA6UMSnOSwmbRAbdvMMBdgPfmEqfyDj4h3wB
riFAGWuyi4WlLTXNQhAPp0oP8hCAr73sGoKbjiH1Tcd4RcGQrTd5G1EQcpL5+4laoUrqO43NHxKR
/CfFQjK26BUKfnfpACC3f5/4h1eKBglfzG7yZKaQAvWUEVvnXaBqsL5aNqZ2YGXQ9w6qgW6xGjRj
jOfmBtpbRuRja4H1EUiU+ZRc8MCS3V1VF/iHFONR4cRWuQFoiMTS3MsYukU0eQOZ6U5AfdyyYCzf
qGnrPAUlohTrBcLGgAOUrI5YE4TlhO0tW2VwxjNLI34haqlN3XiHqZlPARBdbwDXcQWtBe+oNOmi
9rpla0hIqnh4lfpB7RWSxcQ2wLf9lNvIjmuoowdZ9bKSiFvqnH7hCiHAgVKyoRq2oZ3FGwVUvJCt
wV2XGt8AByMkeGmtRP8AANvxPUTEL2uxTiYSnElupWEEm2sJpKNLGFxIK9s62dsWyEUvg4j9Mh6D
k+I/6xfyHNy+K5HT4VMXpkAdwyRsPVU8vm5ZZCgZkQyczSbZctchjwMBuM3IYI2HFxXlTXWiR0ao
FoSUp91HhxLGrcBGaMummwqFmaiExUA7DDwRwCGd1Cd2dOyukvBiZOS0NjcYBx4gH4nMhQyMrSvU
r4IpAuupdWCxyUmM4qKYecqVlQ8TnwtlJVkpfNTO3Cso8nPiKXMCN3sl7IsS/R/kdCdV0iEfRUfS
IOo0LtXG7Yhly0KN1pBqkrhi1APpkW5p0PUXUJTtxANpUz5hMbbPEFQ1deIwVusiLdPDA8fqWz4l
rwxjQU8sLU68wtT9oA6U8QlaRQ0kw2m9EABCnxE6DnX7nUKEjmay1qh81YoY8gIGFEVDXWGyAckH
INq1VB1je0YitLx4maKduJi3Ldz6lMN+Amsrtv0xqJRL9p1iRbSGqUNJNgIC9UWm2RqERzU3oDhf
JCPcAkQkNF7QPIfcWFwi+pTaKua/2Uj09wv2POztzjvMpRKzcYPmAQYI28R4qqz3NnV8XKgFl88s
CgpDI2F8QyZULc7D9Xz5immnbiCOzVnJVxVIsrSbz4JSTXgi6k9tcqU/0Nv4lVvLhhw4H4VEvw5d
RioFXzMt9q74g6sznmOz0L2Xb1xLWi+If/UC1bXMdwoAD5uVkZQPiA81CGMAwDTyXxKuUFeYDN8P
rzKjdnhBpgKqv3DxyLx9QG0HC3M2IqnAl4rOKOMlxqi1OfmUc6iPmKeAK4iKo8LAzeKuWAiGWSuK
DyJDWLAkIZkSrWBYDYWXCzbuzAtVqzGXHLhFfcd7RCOEaFoUT/cdRNKXy8XEuCubsuCjpwGXuqAH
3zK6kF3KWROJfetSvu5bGFA0FZ8zlro6uYlm6nFnFkpZTUzwCv5iA2kH6vhhBhWWgMi9UbNCL9Sq
+QmLkKpKSwWEDgmN1c4+ZaSQnzFzhlEePE41NeSkvtdF+G+Ynk+BYJ/SmLMJX8RnYLA1IbxybGmm
YTcFhL4HLI1FuBPEIRUcP1c5gcJeJUb1opyAhBG1Q2i4WsiprIPUsAdfuLToivuChhdaKXxLwuks
2NiaH3uQ4i1dlHFS0jrdjidJJLV5L+hbHgEoWRgvBE6XpxVX8TYmopYF2S5qJ8KeaZRRVhTWGbUQ
pfj4jv7sNlPBCrKQ0xlf2iFOfcQXSaB84F5gAfPcDCxMapNlKNVkrxDLlU9nzBjWJcX6ild2GONJ
CzmvcEQMOFMROTFbRB3bGCvGXp2TilSLFEDfshoPa8HiM3lzaTqLpSVdpfxUVyQk8ZUHJ87ylX+4
WIKg20PuA2J4jH/oO42b06G8V+Zc2rD4n7i4FFg8N4jYiW5bVB59RPc6A0P5mFKUt3kZy+7l3nuI
QFXHI1mmfMPnbHq55dRwhAOKWKe82wUwmi88xyWki8PbDwca8n7lZL89QJyYRwHML0gXVrlrHIJ5
8y0u6QefbMcCvIu4ney/uFlTZ1ZQvLKLWKjyFjED7uLNBVuqdBcRiR1vh8QbbRTfZAr+lhSk+3hZ
jjpbePmPtUwLQvFdse4zm0teXuJ6wpVX7gDIQXnQiqmcreTozebg5xw5VxHnACJF81LLcdXEq5eB
/mbkHTTfzEiWrd+Y59lKYnmtDiHR8RQAeG6ziAPY49RM0NPQPU7SwHEROFeeYu4l3Ei5ZZsCQ6bN
WJ2WRgAO9jj7jTTcL6lJXOElsuiraIS3O1oWsVrb8t2xW79QgRVNtl1c/MwPbNEsIsW47KfECq2T
hi9AdvubMLYfcoXz0RZrzV1CSqv1EUWXu4gE70xgMKVSwzQRAGT5I0QM9R0W8b3KEDfhRSFIKUUG
FU1gkTLHtcXBd76e8WHnVg16jkqYm3zMFButQ0G7sYZHMvUx9RAB2KKF7KJjxFPVzB59Qjbq7jNX
+YvA2Ka5fSzbZYPiZUGWhF8BAS80lvuROI5tKqAdymBQOxKIe6Roh+5egdBtw7bexcVqHd8y2MeF
dSoIVQTz7jq2cEGjWXK6lpZ8FQFEPJsTBH0i8dy8fUMjriG/UvgDzfcUWr+JYq9OruZq/aUkhvqF
WQd8iX6hNOiGuqXggQpDzUR9pkiT3Gv14DmXXiY2wib5Ccj48WIxEDClkNWs89xOEW/DOaAqS558
GS2BVidCao/SUxImYJfkp7Fy3F631Gl/JNw5INBn6ERgC4HDDVC8nCo6HWkJfUgsGiiVdCCwh8bA
+nWMpSQNV3Eboty3VBQU1HhvWttJfBdoJDKqIsO8FBCKjeWqWC4OfMe5ZiQcsl7SkmiWN15lItwA
JSwVz0SoNfi4BvvQRQz+E4lMYexIJJEOS/iMAF6GGdKbekt1Kb+IzD4YXPMqh+6NfErKX8w6CeAL
BNDF4KvfiYbzkxcMuG2tb9QyohrhiaDMwVDbD/CXoSRU7JbBPoTKK4e4aZdpf8xOK90KZSRsJwik
JcHO5s3GCz8TgV1OE0HWtM5mN0fqF/04uZIjtKY49RU+YcUJYLivL2x68xgL8BpTuCJpd0HuAwLb
rLSE9CthtpMJKfeRo8YbKEsFl4XF+qAJMfMK6XsGKJxZ/iPTeS2/xLmE9FyVLLaadhK6v/ij0kWr
WJxzeFVxQB6FqWJUOZ/UuB+b6ZnISmgvXEo6nLsv3GJk6Oh7hYgmyKzzEI4LRaflG5DbpuWzOiXs
fMOgdlv+y0+iH+HJWHR8B+49PdFWu1B1Vd9qrGILLyjv5lAR19RQeZESEDgBV0HtgctGmziEyR4Q
NRYZ1ZsYaOi0BqnuKl4yDqVHcsauIjSWnmXJKcEuaeVZ5j2jBl4sFlbkUkfA4seCPBHSNHhtuDov
jalps+IrNzumpdQ31ctB8RcDVC2SLB5q5jU+P8xRLpva/wAQp9b52Lri1g7LE44bF/qJPJCJwS5Y
tILpiZD9xPb9Hct0IrrKSgJzC1GraqblRQEhYXR5jOJHhSAv8zegpwVP7iyt9vTCqQsWX83CLf8A
VEuUFSO4NXQAqrlMYWgaWXFnS8yu9V9AM07UxGj4FqCgXL6ElhCcVVnqJgXIKRiIEvPQxahiK1Kr
qIrFAFRYxZuFAVeJcqfXk+Jd3qU6IW7tL9IlM24wJrVPgv4uCFFPKL+pVvt5FHVQ+I8jxUYxFRRr
3Vy18dpiq+JuHnDbl71YrQR6vMKL4mqTp/BhfCtg/wDNgjjLF7KWAwrQl3f3xK5FQC7Gu/uEiahA
8JxVBmCrcnOejrR7yOnuEcBERYCwUC8YGi6T0/7leURwHMOABGr0/MdzVIOF7+IBQaCilUfOxonQ
GhYP3zBHAb+5h0DbnMe4qEJRKrb5gE9O5WNdwODz3EQU3PijQ9oEDVDJQwPWdT1rmNR1vmHRb3gh
TXhREp+Dntnlcr0MKDb74rmFKrHg6hXGRyTtcige4uMBDqpyF/8AI1qDtfqB+8lXXqBcHujjYK0c
CDlqCEQbeBqXBZa3XPE8qZoOCMqkYCa57jDBvuLV1caw4zzLU8qgwGoxorbOognKIUjH5iAVlwrh
3AFHmCDbG8P9lV9cQBJQtEFOhRLfSe13AFbwhxEUtzai0lqy73/kNvvNSnTbKGxJolqJfEQ8r8wQ
6PxAx0tl6qXzeNsrhGFKjCoFXBsCS3hVRR968QBADpRLeNNV3CUGfRxK5ezlykrtw2sRzYRcY01x
Gd3Y8wEvQOSKokrG/cJXcoqFCJsgzIooQ2NxE4CF6aGhN+IODn2fcqdDMjvMCo9w2JAt5IHkDquK
RhNRoFG2S3F+OyHsE5BOLiOgh+85VxsGy8CdBOfXf2hMi4BzOY88g5RK/OoJL0OS4m8vRDcrJHoD
uXWq5yUKJl3GcETmPRzKvTFh36hBC1YVB1jiB2w4FIqsjVdGBVwbWaNcTmFcUDIFUpDOUSeWR/Q9
QckKrwW9kt/UmuSNstKw4he4wpFwT7lFHEtMEazupWxFNLhCFkCsKl6kHhxC5aqndSukAcCLuA2i
B9HCOC5TUsGw4Y9bPhbHFi3SEoecKHqpWEoci4q5CiELxc8nuUlsKIQROhnMvW4jlHqGoACntKps
xRmmY5ZRHMoPlkpFM1YJV5YcGkekA8HqCiQLOSX/AGQT+W+I8Q0kTpXUIJpWEoB9AOziJh1Cwb4T
ese5uPKXLxAJKeTmDHIUArIDtea7UMjjYzKgJlbFBXUu4+4BXSrPEQQ+NOclzunyrxAAbQ9QCDtY
6iQ7T9RqQ7XIthKwKcLL2VtR4eJmaFB2zuLEbbXDc72YE8TcEHjtzbfFxy/Mr7Qttwo01CnMpOA3
0Pn1BNBPlcdeCSNcolHjuNnas3GW2j5pruzQPCyzxi00TxKPlQsqCpABVzkEwEJ6R0QAjn9xdByg
JnxAduINqLjeg7qJUKqFdTmNp5XcMAitI6uHo1QGyhyGA/Af5I3EAXZCiLdChzCUXOELLDmPS6BR
HmlcTvlUwQVLk0cEUkIdBl9IK8mcQocNKOi9iWsIWXkFJIvB3L3OIVvqLuMU7dEDtaEbu4ego8zl
MkhD6lkTxMt5QPc4W1Ul0QIwimh3iPwqh0B4hMZL7OoPwUAMr5ldgxO96kboCU9vl2M+cOuw1lNk
wCqHeQmDMWCoLFSBXC5bYkkOSYSh1AHBnEbyFKHLcHyYV8VXcomayd7VxWYgrZv1M1ij3RcIFoCP
CVBRC2Urj4lOSgHhCtSlEoVcZBUIBcFDUDz62m36lVAw38Ag3lAIUB5fxLMFxRWr5g0QY1ohzNmH
vhhmulO85Qwn0KwQqU1oVbFdW+wQX+oDUgj5dQtuEW61Aqbh2habh7PYgy7/AHHEaJ3VF00cpoPH
ZH4uBXwf6jAN8eFQtpi2qZe5XnBwfxLyYTix4GcAsjZK/wCQeIVOA1cWHBA6yfqOzcbwMJcg+fFx
kZCUNsNR0aRl2i//AJAyNQcDwiVC3GIU2fmMjiNJAs3DgGyUkYUQ+YqJX3MRd3KbXRQyvcrlIX2L
iHK2Dwws4N0uCNqKXV5I1o5/cOG8SlYLoBVRpI9+RKFAWxzj/kRrNWDn1BWgRg5VTmnq1elm0bFX
YziF9DAds5uIy+Z1kLVJaAewIhyDxeIVGv6onMUrke4TdUQa4smDDAx20PqCwvMpetgUtYKmHuWj
Rb8xFlg8qjfLvERabYpxA1F4WyrEN6goilLw05iGUDVBN2mgF4hHXOHKXsD/ABDsagPhzDL52sr2
zHTlOeWOEwckGQlD5ZdRQADum5V6gtQcRpuPcVgo6j0tC8lY7++ZTQDqql+FYHcdg+xHBNLkYmjE
tDqIAKyx7fMcnwsuodkpAnlACgo4jtq3b9RDFLRqKgqmQOCmgIYIr+5SzK4CHCtUX/XS13UILWUZ
c1PsUaD/AGW2K7PMqSPub1SqLr5l9BKxP+wSG7pniwyu41c7vgmsVa/EcOcScIwBljlfLGTFGvxK
zlNVHpDgB6hIclxdREsds3zKRc9j72GBe8fFSoIVdwmKw8RKhXPETbOg5GVg2VksxOCB6a0H+YQQ
LWedqgTs5DKNgsaJmVtMRoM3iL0uWsZxTBi2oEsn1EEIzWFcRhX18k+XjDEBdhOmAJLFxoRyCm3H
LMEBpjPqYnTBCTkVFbBYObnVw7cy/uB4B0l99gM0q1r1LQI1oiIFJn1Aa4OajMFnxLNjLyb/AOYP
i3SNdx8BzxxLMFVT1cdrop85CVFimEcrk7KkVHKcy6FrV4haXAyA1cu3qDmYFRz6hQsVT9S06ACa
EvTCVoUs4lYK2WjguWng3fRjndCL3D2LqZxNrzTYtHk3cVFC7qIamJs59Ttm3+EJRU6gzDW3tcH4
VUdOTmfNV6h8Si1/iF5wTjxUcFvrfHMoVpHWlycuGsBlvmMdaynnIPq2pefiN22inLG1MVKc35lp
GhX0gLxGLUpY5Cz+cgaoMtXkjoVP3k/DBgi9w55ZGOrRz2C4dqDPMJtF8EEQ2V4KJymWFe7I6EAU
HDCAmL5WEC3dc4xtJ8FQVNlU53WNt6M/ENI6w6nr8xgDBq/cJGw2/J/stsAur5IINg1voI3GjxP4
qI0L5OX1BIN5SgfiNTD1tvH9xQ3GnAwglpK58v6mAqLErNTmfU1tEL1cBqos+SM/J2qdXUCikKnk
c3LyUA1dIEeI1WwHVNB+0owlSPmUtoX8SlF9X3KSaF+4+GFs0A6YRVYBfEChttX1GVZjeIMhfg8W
3FYiBv3UoQLDj0TAoUi7fEq10t3kyMcAcAO4bINtl8QXxsUHdQaBw3XDGMAwo+JuX1TtLdMraEE+
cgX3Fn4jJudauNzALOgqBVLNZW/+2PncUjPOwLAwKUYYQQaABySoTT+yAILqoSxHAfwSpQFVbpD1
LG90+L3BdnSwPwQU12YStVXAlhRcdmg5xw7G28oP3HMqfqKGkfoNd+ZVNqiuvWAMaLQ+Jes0UVae
aiPfo0uG46h/RBXUt8pVS7AMv4HH1K18S6lkqdHg4YBmfeStsqcpAfeYg271EEIA6px7uBQwpn6y
GTYn7uKsnacVO5VidnIt/iMtkre2SweIPV9xp4ajAORcSxlddwIv/wAuXh2S1MCHaqx6guuIy/TG
r8hMCBS0vaenz7imspOeeYKjQI7L5/cEZij8RyYCyaFhF73mVTajK95AVQ9eZZ5mU4PMVnRLvviV
g8FRfdTsWskYXVU+Y6COs8ncwLdU/OS5JZtvwRqNX1K0oLvmY7gjVNwJauYJOC/c57+paa8TVnwk
GWmDUKShd+I7BMfMJgU8hzzA+y919Qb51r5jqAkEd3E4tdTDgDFC3DlmMq1GtK/96ln15I3mi7cU
vlAa+5QnHh8StE6ARR1bg+KuU59kErrwDHy1EB5lvZVBw+oPBRVOSx9s9FfMqdbrfFSokaOMUEo1
vGS0VK1lYxdella2n9JZqGRXbcH1rtGALaDGd2eopr4gwt0/URaOCB6dLDUEhVLa1lSoLoIx/Hxv
MqiHCtjRoFa1UajqpRyPZA7QGTt0SsXB+YPiq9c1KH7OEagASvcJUq2o7aNW+K2d2B0+RgApWoh5
gEaWSiDTlt9wSNtZ5gGBrVualLuOLxDaGtavc/8AsFlFC8y54rP3CKC8I5AoZDYqcX7hx5jqQN/O
wqBm+oZpwquA7NuHI6X6lvN5TbaN8wRdcwhKcP7pkm6WCngN2UXUDcBPRX80qJVK1c7hPCQIDbZc
OKcOSi13iIeHgHiIpmaCMHyYIAeSiGaKEs+WqfUTqqvEqgKcmC3Dm4Nq2M9VMsB4PUC11TPzCdqO
D4mYrWnxACGCvvIQS0pDERbPFxa9BS3oiqsLaD5iMogDIgJT4r3CoLKBHk7QfcqE1bOIt96BhKVl
KhC055hG2iMARYErzUFCd+epunB5ZTIWjZ8xhcGB7jrwVv1CHrQDM1G38woRBofXMRHuiOVSBGcw
OcGvmM3Jb9RwHtQvd9x8Ab28xqWKFZeVGK5d4iQFDyJwZGRqt5qLZkV/FxVrPC7hrQCAqK30VW+I
wcaqOdhiBID0KmOUFuDBJXAFOju4xNrV14+5XNiOl2DlFjX1DXNukDwRQzlqU4QQ6TqIQC3Z9k2k
7B4qXJAEp0r3DJjSXt1sVOULBy08yqwXL/77g20JDOxP8h3fHthvEsKk4AV+oTAVtVW//ZRW4Ccv
M7fgCkouDKUgabpE4JaLVKEu5s2I698TAUVDmWaC0PNQyBOS8l5GU6N6gKyrH6JLC1wtU+orThFZ
jzdTSkxTn5j9Aiou5DjYyAhMg6IP5JUJq/5ZapXDfPH8x2qaPVp/sdfcHORXk0HZrI66SPXCHQbj
vxDBbIndxDXYPFS/Q9w94QVAKbvubCp91JeWYF44/wBiiLp7RvVD4GsjCDAiiz5hWhRd5dQ/FCH4
iETAmx/uEZYoDzlRVaiN66mLnpLYCUK6vJj/ALCICz8UcwegSHbUdyQBHRUyxYFQCDGLRZFIRtRE
K6gJ6saIpPaqL4ti2hEG6QiHN0wRp/2KocthaQ2q7RtxeMYISgqAdCE0GIMhAIeM/wCShIEujkJi
TQvqIbjgFshxELqVp5Vb7ibh8tWr/Y1wbkpcHTfat0Oo7ZZBXg+YDXgHkaogez0FxY1LdQNlbvL9
Fs1R6NVRhAlPEO6sucCwvioWhkkfNEopQt8rMiV9+oj6laXyeIYKKfLMhhNLo9yl34nwQRRq1zLQ
KVO4tU46SMNN+ZSkD1U4i0DKHzMPe8S9QVQ31OrVqHM3+2HlqKAYFr34ikg8MvwGsDLinEoKeGoD
AlxpDivITmFZaBvqMpbEPO/xHqSH6YAO1t/5NPVsXXxDSWjl7qaiN2fUFVLruNLWpzNK+JdTmpRF
unUNCmxl9sARlfEEqKhOpOFoDY3CFC16jGWrd9UTRvSvqPBbnJvEKB6eYxnDt9xQtRGCKu6bhQi0
fLl/2N23XXRUICy72HyCdEgFNAOefctIBqnuWmpa3nAgHMEvnAepAsg8YVzMMB0S0G/NXhHehHej
uIuNVfPEY+APnH1dXjPABTzGsrZXiIaUi844jxPNl+4fDaKsgnJq16uWAggtYK99E51KyXvVpTcy
+i7CPRFeZT6Hk4nJ7SlJyt5Dmc/y6JEIrRWiaFbAtJa5olqo4NPmBIDZRUQSx2/E5btf1DCs0LlR
asAOJfNTp1NoBf8ALGp8KIAcHS1B8RSR478SzxstdEHBV5BdX2hbFRteNgb+ha9ys+/xK8AeYCC2
Ox21ovbDYCuVhKFsKbdLXxFUFwSxYM2N5SLwu13cYKC+2EmzXIj9qCFQAcx4tcA7mHi35YQTqd+I
514jV+40gV78SryA3cbk8N3Ouj4eJ7xlQyuxMDhIqh8xA3sT7nhUIQWmgjpf5T2+FYZi8lzK6A/U
B1sFbZnQfoSnyDi+pkwUaPm4O0BV36mmxDHmPk+x3EAaQlwA7VK5HdhbG7jku3YsvsLZT3sMkTld
bUvQ8EAQvzKPOjcqoN0UiLGGnwjmCcFm+PcER9jliQV0rEN8g0nqPmAyzkl8LB7c8p1kdNPG9ROA
LQKi6lSK+YBwbQ/THWgNTlS32YL+KnX+oeWphM0BvdRnApa6XOJ0BdVHAiEHwuo1YuCd8RfdaB4v
ibcSx42qjSo7uNTOYK8zJlzHGp0gc0WdQMoShzVS0DBeRYnldQdVE2R51Oy5RTVnPEoxsgB6qaLy
i5eIiNLw3g/cscBJp5JQx4q8VUNTfVPNQRTljjYKBAeTMyOhMhxXn4hwtHNV19zQ4ALOZaydsWX0
kVVowCpwgUEriv8AI9kWqjntjdoN3vCKyB54M/yPFEorLrx8kImpqcc5CyMGNb8xkWqoblRQylV5
XuP0UsaDxL/svy+Lh3xy5IniutBrvalBQiEFbDKNX75LyNsJQqwYbh4RlV7cd15gU3g6JEQqp4Vf
5O4D62JiNm6GGdYWPPG7DHbXZbxG7RC8t/MHqQLQ7XVw47hapa3JhvghhaJhTUfezve+P1GebD99
8xZN7P33FrRYpT9RD5W17ljiE6q1olHDBtSPMvkLyShF7DuoREyDQWI3LFRRfqWJU2kEChOj3FEu
FRb/AOqcKEnbYpnP2At1/EKZtVQsvu4hVPgGooz3SHcQ6qqGeH6jCBTePvIpYBZwdQzNIrfu4x0I
ocnVnxHRta1iPP4lQflni0v4yBh4JWCy4KW2G6efxOfEPDXqDKvtZSHNsAFe8CDvhSWsEaMTTaYN
ZPB6T9SqpQZGnmVSmCuMbDzBBKoefmHX6hlf/kJjcvmnP1LDT7GcTA7Rd6wPuoUC0t6JQ+5TXNbM
UcrGuHqPIVkFzXXRCPGsp8y9xwe5gXp5j2gAabONafMTwQPtO7y/zBSo2OxCuwqrBHOGGhx8Rl4Q
VVMODirvy+5TAGyfOwEWd09+5ZEKgBX5IaSnkbPqDCLzyQOywN8QrDQobKuVySovjjZpo3FXKSo5
YXqFzbVrSLDLyxOfIWs2BDDOYFtVs1Lp2N+MiGuiC8QG/I+ZaHGEUsjS+ioyFx4jJ2M69RQbYWMs
jYdXgYNWxscJbPGU4QDScbp9QkEVV8bAOOqF1hDcGZrn7l2Oa0FwYAQseWHxlyGF3m4DI2NikceI
jSDgWXMxViDiHNcC39wMD9EFRHnEtqngN3+JY5T2wULDgnYdKpQLKgFfJpgpQ+ZiQulc8fMFTguw
0Q4oCtQjooHjv7gBd5DKTe3DHZNO2oEXAFdwy5gtYMInaQRfGg6IRxGsN3xEpHZ5jrg5quwuK6qK
hEstVe7lLhV4RahF0ZUFmwuHxKxyB07K5B8Pv3CiWbbGfeYghxq+BuOGSUHeCbPJWYEKxTsoawcL
lIaXKxKb9oHCn5jWKPBMAfvIR479s2IaDg2VR1yEBqEsO0NL+RlGN332jO9Vh3K6WmJ1BWW5g9eI
XAHaYqe6BqWtANg6goSFK+IT4q8bI90z8xwFla+4iCmlrsHvQRruUu2GvAXsJ8gVeWBQ4tDbEL+X
jvmBSmCDSHtwAbiAj0eYRNcb8P8Acro8+BhBB8jfqBUmqjyQCWVa1h9QsRn5PCD1HwdVb5SH5ykB
MIDEuA8xy9uR4JU1INPKZu3S7b8kWmfybDJ6BqpdbBpbnT4ws8Q81FWQqhZKd1lx3V2Tl3JTIRBW
ckOwOnm5opGcMPNoLxd/zCRk58ofS5WYxebF11Ocm4I9yoq7leuq+D/8vG9+URe4J8iy/hg8hW6/
7Ejc0nPzDg0Lioe0joHk74h122xVepjChinkiKMMdPuDTl6Rz+Y4kaFuNjlgANt1n7grqOCkX+oV
RfbbGYSulPlDr9VJfDxZegQobBcHh8SxcTwkiS/HK9fTqPLLAW/cpkF0bu9lcjQKLA2RAngp39QA
xiHTxIxeXktH9QYLeaX5hJSi3Hl1EAE5GjGBFc45XzL0Bxt3A4Qdp3d8zwWGHofMD76TgTxbcT+y
VZbp9RI3219H5juNSG9+5TsLyur8xyQuNq+ZRovjx+KhXPsUU0qKZ5BPmnJkrpYt/wARxy7gWL4l
NhvmHzLVYSpTYoQhDhp3LEE4NN+Yhws1qc9pBElMqrefcp+KnAxTRl8SwaqIArT1UafwE6Y552i2
7zkqD4zstg2FV5jQ1qV0g0VmbwKi4Slu3cHXhTxcdctNnXqXPJbay/NS7sq7xCRfwgr4qKwuv3f3
G+FYWy3OpTXZ2ReAQjmnqeouoET1FhZ3ALucR8dPLVnEq7uIUWts9ooDe3+oVJoPUpl3N1vzOrwI
orqBFzenuZI1tqmC0OUX+Y2xPNu/+wTbX4cy2OrAA+YQihvmv74g6DR+2FegDokSgycdppN8r/c8
8B7JZ3HItH5hAUHk3LWb8iA2oKq5SKEQ8gDF3JeE4W93uPuobPYP5CctEvMpUWmUeoxeg1nj1Arq
fkd8xd0dL69zUJahoGGt5j/pEgs9y117fmKoquYFdNVLDi5toHxFTgbzFDp9pWS44HuACQTIBAr8
y8Dt8VHWVSS4hrdvUUKbfmOm9eI8wqtpTZj0+IYbChtsIz58NtmGlD5hFUcKBFaaHbvqMm46tTvK
CsNIfkKsbpdYMOUa4F7DyEHSu4OQjNNTtgYxfXkKLzfcCA9xurWhgpynUINt34lAVx6lAdgDLGI8
CUFfcEKzWC2+ZZPEXHHkUs1vNuHpi8PYmW6z+k8bwRE+5zrDtWvmNE2u6XmPg/AOiCVBgWiOLatv
zKL6waiOFdnJcli1VVnIs89wBQdQx/MpzQ0bMcvR0ckHvtoMrELwyMq5HY38xBaGtsPD27GJno66
/ESbKGyjjd1EqwNKlInRt4bfzEF10qD+IkXnnV/EQIPltLl18yjsEvOo3cSaI6GQgunqCeKELPqd
kJAjAQzVVBVw7TUegr2b+YrvTtWCaim8OxSlLKqmZDvb49RkG3I0/UARE7GpVB8aEKLvXMHYsu7R
/U2hTnXEDyUt5IA+AN3CSwMTh8yhg6L78R4CA2IzcHf9hrDT6lYAaxQZQm7Laj5XXcWjeRefmBTn
sfVxrS+7mnPACJy2lk2BcUycoF9vMBhHyFfEYJbktL83K4neFiA5CMFhBQZE/t3hDVq1Uvn6h1mm
E/iGAXJowRAW1YQyE8CVcc6DQsvwjO0PDiC3C7pwQEqo1GGSG3L8xGFjUB1cBeh7lGKL0eYHRbS4
OXu90+fECipdNbioRMSXUSaFq2NaQsbsPKpysLWo0IZd1GVpol4jX2NbJaBbVVCVotQuEOg6FcT/
ALXyRRyXApcZfkXTfUvtLX5zjzzLIBqrRJb5a1x/eRqwJd3SR6RlW4uCUwu9D3rH5w02s/MvwtTl
IZq4b4hMlRXVyDWAnkulo/csgKt289QFBdqoUZ0RBrIk+B7jH6WfmNg/+oj7B5GncZhjxrqFmL0N
aie/F2EuJAVKS6fPmFFuTwTh4Ls8fqWVG7BjRrcN1A8po1vvINUa6bH0qKFk2v1LA0DrUqrTd1dE
zbSygLdlC8oQuGOzUqyB0ZwYE4D9dFJqPb6SVwdbd/fuWKmkcNTIfhC1LR0IKpcBNJM5lidwHFnv
HA2F2CCnu+ZW+t8hv+ZZ03mr62OO7XUE2xo6VLUdaAivZsclU2lr1LQaLadRbZ9cj+4Wvi2SgJc6
1ZPAbM4O4beU2bFAmqD3E6VKWsYgdoxUu95zAR0asM0uEfTq8RvwTAcnH9RLWeHoY3L2uoUpFB49
wg4102hFL6TrazJuXSy0hoDwAoge/BBTAAxwGv1DRiC2bcf+ckNiE9yQvDph6uUsgUprhUlwxblQ
HXEt9W26C+433cQ0H8zEzl2Dcf4xQFB8IPLLqOfUHSyoaUhm4WnlDqM+qgLxhSg0NfmPhfgV59RO
jKw7vEN6iUKfwg3hnIgxIiU13giMJaY5hG7wvuZANlIuh5i8UN8DeY46CjCkXrLrBvxg9EaoN8/E
RqxUVKixXaKpfkqIz2gop8xomFvKuIGFC4AppNQ4+BhZcoK8oTFuFp1lW+RoiZ+4nNk+y3uYsmGu
IjWxdH9wlwDINM/ctlpDw54YOHCqQa4WXeJadHupVAHw6yWXruVT8sRQXBgo2xboeIF40HP/AOC2
mnqGiab4rxKuV2CCqgXD1Mo0cODLmoUu2lKHhrTmFJGplIBD1C1CtNjQBMpxkSAU006ucLoVRvcV
yWDOI2ENF1sozXJRx/65VbA5qOeBbojeMaU8xcAF6bcp8Oz8fEW0odEI4oaMghAXCqHUW+8TjKjg
6ihOEipsJb3C+pQN/MAq0kpek4qcScAX5gqqzDuAg7bPUHgeBFVtLRRLsnJnUcANFFnMYKpecwlh
U8NmfdAccQNejI9Qct4uZaJycobBGuKm7ZBTH3CQEO6gL0KEESXGyqHxoWqA/qUuPLiBQosGCFUA
l+GJABCOmDIW1QWAIgLL9QwIB8KJZEDZcGzFrFQBUXxW1OLIuCIrtjiDRYKqpdY0udQbm6Er3Bp0
OCHQMLD6i7xp+5T3Q1BDtgb0KuV2gXcdk7tl1iA3Krv/APNTEQj0CyHNFMqjYWoLwdSsqnghgmFM
cFB3UrwEFDqUJ7hyoEqxesCLQzJwyFAuHMKF9yp2hy52UCuFMZcVR4lBrrDpe4Jda735iWkcx1H4
zszhlgtAqjDvMMFcAqMaxLuopVrZyuClAq6CD5ISn2ow6uYiWaLlMNCqu4aQTGcseXGcxeoNGlWq
4lECVtRtAjGjewXCKuoagOVS8OBcMq4IXENYKoI8C8wUiKIIUSdkd+YEQ6VUI7VLxd/UoVxCUeiV
iErFZCUCoa4iPjQjKg/08ReGeEuHzFaZ31BWJDRdeZassNMhdSBZR35gn3S05PEowoDOopmUttUP
gPTGe0X4DRqqhRUrv+ISzklnBf8A8jINA4xyN43ospcN1dlJwIalKrdrqUmmLga0DTQxKpBqPHmZ
36I1bWepQZREQKTHn4gVF2gchxGFSgKDXxOVeKPI8ykm0thCVqKkb25UEygfm5TCA+wl6UBNi6Cl
EHpiFXYjw8zruDRyxZKxyjcJdE/IilmJEKvxGVjGgtlBTzgsi0jIBh78TukF1Mh8NOD9oEXrKC1+
YwZ5WipbCfI4jiW1YhmCkCI0RItV+IRR5t16/ccMQIPZ6+YkpLSK/PzLnLAHvmZcVGnBFGjY7TxC
GpMfnMOS2HfEOBotrqpgWA68M3+ooDl3KbZvbfJzBxHy4uWWNzUVX/YlFkB/CYgT0KL8xEpDCmWR
CNXsBOIVotXC9SpXBdKyWX1gHJfcznKvZ3B0PQe5X8Rw4tB0A9CrGQkWi9p7yD0SgQdV8xhFWrcA
JSbLcKb7ot0gTzcpzSoizxFwAsa7eo+XBH6DKXObM4f+RlorC8XBQwJsdmNIYs4YpOyKl9ZmggOS
KKVq5zLkeA4ZaKHzKXQ3t4Uxdt4ByJUAABYWo2WHYT2EPDACVQdEEdI4unjx7ibhdFupT6GB4wO5
Wnil6wwwP1zf5lkIth2vmN3KvFoQLHw1/GDSUM18xTNkUSM80UDXzevKcRFA3YWOhOoviGAajYbe
f5mKy7RxfEoWVBozm4UHJztOIHlph0f7CaiyIFi+4kUIaxpxuX0Dysu5jGIodrFpWDWtpHiFTeFF
t1a/mZmMTKdVBOuUyt5jz5LG6aD+fqPGUXGBYQvOkyI8AviCva5MBoyg/wD+jWO6ZFUT69ThcZpE
CoFU08G4AL6hXQmC3EdqaqOmOQQM74uVgKXu5eAX03WQFItjfSE4zw+Zdd5eYcGjd6hNKVy4w6cE
r1DpD8IcsbrYgeOP8hNBVOzBhpy9zojCiqlxavJmcMbZayniJRdayVFRHN67l24F34lkFy8xfwTP
qUUtWqC4xnVB4WURX7rOYbpzPlHLFB3cWcLlC1yzBWEoDbONlEA1fMoNm+Zj5DIXXC4aWIlEwKdu
XgYBHtnGOrRJSy8lLKrhzybMPLBO5aLyIYoYqKHRar1pUTUsuP2rzcC7Beg3B8SwnWEHmVFGwVzs
JLnsm3YjOCFTILBQdSN36RDV101+UqGtBA+UcCbhTliLw2togWw9zLgfwowyGgL0/EcBAr9zU/Ay
lWctzAmPZDgAPEP2gbXzcZMe6+Y7UK/CI1MDW0lR5JXDzkQSVkGNt/nMT3ZSIni4lo816QHxby9R
BFlQ4wAX/BNeodSlqmV3EsOaHEyEtX1E+LhC57lHmCicQYO1dsopHpIGhYq+Ys5Qr8QWBZVuIVZv
MaFtZDutofudnByiD7dUqAtRSZ3UJkcVxBEtagQUmty+KioDC+JiCUdeZWJqxGJo5GqscNReqlce
Wg815luO65qIu1dPzCoKNn1/2GAxwEq1sCnUoGDFZTQ1Y5EYTIhPVly5UVeanVlBmyvA9fEsRE4q
C8gGZLOIGQ7lD7R4mXIjXEcFfAlJ/mi5IsUOZaiLFsj1vzKqFBlQywlqT1FpIV6csalyFvcFnFNq
XljornJS7lLS7KtnR3BQlUcGyxBHVfMBouwJc8bTj1ECMJ4GUALKRuBDWvExhzo7jiwC1+IbKAcr
iXyJNbgIW+CVBy3jxKTS5Z1NKnHRWRwbQLlXqjE3mUwaD4CCmrNngn5UJ/EcqMUDw8S01f0ynLCg
vO3ZQkbKe2FiqKB1LFfNN0Q3Zba5jspsIL8vzEdAmU9TBMJ/KiOwIAU/ZGYYUR4MgPP66ILrR4K+
5RD9qbUU5ramn1LKAWFP/sjNF6LiEruhYosEH6RAJoCm+jj8Q6AOvaj/ACFSmEc4iLcAH5/+xq1S
yHz39y4ri+GTLfiBQ9x5dR+DmVDY1PUHaVdd0LgATf5Sh9F64GBjaKatVKPvZI7s+ZZZAoJtxFFx
fSWPcZ56O/1DzqjkwziZcZcBcBLdNmiC6bQO34r6lWmxv11KIEbqvYC4Ba08xx8pcL5riZCqpRct
InWCmQoPNRgZdK+ICAtHCvUD+BI6YygNYsxfEb1F1+Zg2Q3xq/7G+EVrKRbbr3BHqii/tgAR2c7I
ITkS+tlr8HacMMDaNbfNQVh4zhM6jSOVtcbEsRhPQLUQYOVKL+vmVNtTT7gKsHIfMYVCwq3DCsFj
/wDaW+5Fj4hmLW3iG81hRV8QXuLVfmI4DCHwsEAK5TIOirQPfEsS6NldQzjoIuI1Gl+eYjs0UPzC
mCpp3KoBYBs6jqvs58xicm7zuoNNp1vTUZVbR/UKhKj+D/YTCQaL+K8w27P6dihDyPnYfmjJzHlA
IddSoTgA8SqdDxjCDVeLOP8AsbTQD0VESl7oae7hMWJdrxL0FCeaWRLCEB4YkFa4LWjqAEyUK25I
qdAZZa2K0BN9SldxrQ8QBsLPEteFHfiNg4JhySkAXP5hA6OLAHNg5cyV2+yC8ShnkFRq7CtQUl89
XBX/AGMdwLU8zj3aHn+pVK2qx4JWUsX8RTymPDYZBjD4VANtvHMAcouQ9xcBABeqjLPd8RPTdrfq
ZHFrvqciUqbxsroU/eCa7TwfXuKpIL7hDdbHqzmWTgkYA35isLNZle2NwFeqlhtKioqx4imKpScX
EqdKQvmB+uAgImDgzsdFkOTR1KA9GNbqP1ueBQfeRzYo3LCxs6nPhLey40G2ShgC6i+Jezrf+QvB
LWKA8YiZeKlVlzQp4gKhXFNRcigHneJxcob74hh+NLOPUvFBrVXKQrlRlJYqmGsuCc8JeWX2ka3g
NYDCoWzd0xuIc8XNSF5oGlpqedg9wcJzFvCa92SrDoZ8R+V/wmrjaPmVQoZZVFQC74Oy4wDLtBwA
DeXxNEJRUFQ2Gg6WovR6sVtC1dxcrXocI4I6c8S3gnVxCiMgNvAgEB1iIQnKpmDdF3NGjUby0N8a
ygu5LQmmj5mF3qEOVCsQkaesYhwaqVNG0fiEVXd8R5VA6/EPazmUrarcjywt/KDOGz+JdLTj/EQR
q9B9wXdL/r/IOrWlQSuWoQRwl/UL5GA2yoDgscBGstbewUL+sZZpbXgQUnlH7jagq1+fUozpYqYP
FCEqUYOjyq4Z0WLHuIS8HSOB8EqJvZ9wyxWEIsUN/EEFvH52HXANJ6aj6xbDnVlpdyqqefuASh2v
3APwFE1HXPiXWBUJcFaR9EOh1R7viXBUX/UJ5bYr3DuqrlLwLNy81ptfUG6oeagByHcQVy9RxOFS
8QjtbCC+oOIS3Z35hfAtc+UAVyh6bOIR4lIFSu4ER2yGbRABKLBLT4RbpwiZMsQv2XX9Ts116iWp
a03dxhiED+kaByLAOWG5oyOByASVV1lXxFJDcpUK1msEPNShozfnsuDarpw6h5PW9DLo9Q+gNsGv
mcN8vSOxFQ6qTzEtch8y99qb9XMyIEWdpDjEKQcuf5jeVFj9wxChivglVIgzG4FUi/gciNjZ5PjD
m2P8ECwi4I1o7iUEMD4qCbAU6oxiCahKqR85gVXfi4cOeQOroO4ZkCga59whaI9+IcQhke/4yUwQ
VC84nDiKQblwymKeicXSWdbBy0pGuXCUYkA4+6hSkhW0O8qJbI2DEuWyRXyOphmq/psM9UBDKaR4
aQL6yLqFdmuQYdbb6uouiKlYuovnPDsN5LZwxUAMJKF+jccM5h3/AOuI8FSN2dmVlf0uPqBUeBuY
1wjaXmcIXK+WrmOgOHg5mzUQ8jYQYiYKsH/IWPQDq4BoDT28TbojGg/5DkjY28R+BjXJGd2pVivL
UJxUItb52XJPCnmUxMId05ct4Cs4KY2oJ2Pl1FI84O0TS8Rst5YK+5SCi/8AkPVOPklaEzDi+Q7l
DATzOCxtwARa2OldoNbYMDIFdRhy/qJgVh7E6hEyvaeIUvsE9uW4sw4grYMxBA0WrcgOdIjhfJXq
EU4tq0t/mWQAjQPUNmerUC8PiAfAr+XH1UFTWHJDnxLQkWr0BhzHi9G8af5AFIw4Hf5IJ2pF9BuN
czJMs3+Ja2/nu2KbGrnlL2arZdaO8g+dRCKOY2eyLVviY4Z8v4isVoxqUtcLtuBKd3f1MVqHhY1S
0OTzLk1eod1ZrISEUnPKkoxUtgYC/PzDQAOLhMbVtwem1sQ2KrwqeMl1aVP+wmx2eSFkKcUI0moO
33L0bW2/CNBbNAf4i4LA4eGI90xfggsR+UrVFnm41cyX85UGVEqJwpcg6gdmyjIgq1fUV6qrlGED
molTynUSGmktypm+BZ4YBs7yOnQ8DE7ZAB3s/wCkkIrVVMYlnNRPQBf8TkBu/wAR8RtfUDK9Bzds
oxxFwUgojXENoDs9v+xgcLVdRDlRE9XLt4OIhRtcTWr7XcC5HkQhoMih3vlmNyujKp52BAMBvfgL
S2W/qYP6LTgxsnA3nJzYrCKCHofUF6m55lmM0m8K+D3KPYFre2wZ0f4jGptLuywhfZ+ZQJYPcLW4
f3DfAVxPJFhRcw6tRfqEEHseIUoGE/5ELhTxzFWBFnZKA6NZ8S4LVvWQgETgivZf/SWQAVq2EtDX
ngqKVzVD3UakFXknNWUqXz24Xa3/AGPxaKH6gOEU5ZQjQ8wstjabqFvVaMaMAebldTlC5QNK1bzD
cUNi5blLxcUtwMbl1LptiyB4tnh+o8Ru0Ey5wBzKpKri47RAYLylM8QkWVNR+aTVwUoU3cPBwNYH
GN2UAG13cPMC2XMDpVqGwm0HqPgFwftfDQyvQ3cm1eZcdZe5fUDLeB9RKQq7vEeIsK14mXK6efMG
IcgE4tBtS08qZ59QG2OiV2hOGMc0LlEOIaPkgYSrHyXK+oVs5aJ7BI83b5VoN0rc+CW9nKviUhLu
x5gENR6ya+YYsuE0zeoAl4mct7JdkLWHcBLW20+pctziLku7Agi6TEzDeUSo2Lu9x8xF7VY97CGc
hsThlNu+WvU4a7BOyPsWleIpFthzSRDjdt5vCEroDbyIAYuM5lkwOvCoaua0f+8xDfVU8zhd0Df5
lkaVNF5Uu4bZRznEchvEq/cXWa8Xx4jtbHgpviJHAKHB5ucqjCOPiMVa0cvH+Q3CxTxgS4U5G7c2
HYftb1VQrpShtDOvqE7BkVeWHCIoVc2VADQBl09LKFaOjqNLjQLvZYEjEenxL1hQpL2Rqm3E5mWg
EK4gCNUWtZsK8DB75hEB5PGVKw2NROd/7KVAVl+EZkIaIoJrjUKq5oc3nJGEnttdOZ+oz4UnvBih
7Yli1dkN4LoFPMCyreIxDs1PyxUuYN1SWPhm4gx1fEVEZivmp24fcsdUiD2MOhAg7V1T7i81iob9
RcKBjSDxFMdb3RRmsAtlbIokGLIKtd+kbkV8hWEs7GlSEYjVij9SnWopo56gCwqEu1NX7lpetsRb
+O4Bca8WweJLmtav8kEC8p3CeJeiDP3OXT55XFAgIlfKFDsWsPyRV4ihX18Spmpa3VKD3F4jCCov
I7F9lxdDFbLjY9RHiNPMTb+Lml8fMDN0KXTuKrF0u+cl0AQoX81HtChrruoQTl+Tuk+YMoQLL8wG
l2nwfMSCkNG9bOn6CGe4h2o2v8o4a7hClvWPnYkHDa1ixTjArzkQOoqKgboibs9VHZKkwVBuvUZj
5699S6gLbT9oxoJQsEKq35lWra1WryXxsq0iLqlW6eI8fsOvrfmEOVsqA+lyXdpo2fVyibeoBQtu
ChGMsZWSzpTLyE5RiGgrmWS120FdcxIE+QwFzXgkvCrDbiaXwTXat/UUalruFboFL6uZLneijqCg
DddvceGaLZwsyWDgtV1dy0qVVvH1A1cFPhnonKQerGWnqlS+4zFYNGleY3D5KqYNZre+Iv65zvqc
XkSypes2uLN0e0FYIJeYFW/1OAOIbX1MZq6iaG7lgsV7lqsXfULu8mAOH1Kihu4sRBa+PE5RJr5u
VvJallQZpNi8DcoCLS4zNFBVf7C3Ztj1BsmB85zFwK9F7MF1yyNKlC+4ABtcKMmDQHmedlueINEO
yxZFe47Ddp7VDQ2PGpU4mqe4Ag+oCwy0iy8g9+UVpdFFD9y6pSxseC3iFAkFdPmLYCwsJEeLKv8A
McROm5AgKKClgXXU/wBSl0DQeYSEp7I94YQewCARHc4WuCLsHCEn7N9WxmDR5l4Zo7lmPd9Tg07R
6gYbWKohyKe1+JvoSODxLrLHMdRQOyjMjgyorPTClZVW7hy4laXb3FysaRBcW5EVXGvg1zkVYwgX
kZabMYRzTVsDL2bAOpY8QfX8TjO04t9wTimW/cSKjdwMqDNFs3w1R2HbSng58R3xXOxEo4XOEoU1
jeSgmeNqvUrgGymfvayU1RL1e4bMLXaf3DE2Ks1XdxjRA58vbDQA6Ngk2Ap6iSyE0P4g4YzVwWB8
KoWWJyotjEj4WvBgmf5Tn8ytCYq6jVm83rxAjNDXbhg3Tl8e4K5biFURQqp/cdKkcUS/zCFNgmkr
64CuBLZPcjZokOCdI+AtS7Xn5i4NFBrX5nmZAl/zMwQg7zA2WrXuibkNga/UJJWwra9Q2QMtrAGm
aSffcVKBaoDf1A8KJOQcSoixWWPUenirXMwC3evMatsIFbmWWIuu4qtdoeTxEdLLaNRR4iRjehXG
xTKrRKLCv1AVqh02X5uUpYBei4eqVamb3BZH3SyFNsWL5l5veg+ooRUG5brGGiApR7h9OwTgepbG
WIurm8tug0kN+YM5whQU+b7f3KcJFAdMT1tgfNc+5ZlCNz+UcGxg2PnmMj80UIHsaISdEOwKpPiZ
0t1w/K4QUsmYXiUthFYIEyA23vmEO6UvD4jbombAfmJmAI+H59yzcDacSuuFGqK+oyoLawV+o6YL
IYlQfVUnUXuG4WE6ow2Kq1515hK3uypXGDk36SOuRqgP5qUHLVN13BFkgMUiTC7BNJYHW18xXO2U
zu9lDAv7mcsNLM5SHF36uFhECgg9EcAOQUfiI7lR42GwhQh01X9xugD3CNM8rmK3Ai0d/wBlNEAN
RHi2I2PeI8/c7y4wv5nBKubfHcKw03PDKMB0TRm9E6Kr99RcgdNl+5Y+XDfEP2AaFQgl2jEWvi2U
ahO1E6RnYH6i1ASrmoC7Z+YBSbLBE/EsbllOkwHHIaqcyJsVKq6HX8wc2N27sYJzx3Kh8q7Sp5Op
qVWDeVYj0NDkeGXiHlLQh2eAmIL4XrlcaXvm27getgOd39xgtK4HLLi5V0JnqGPEl1hpYvgTZ5Ke
LVLrSeUuHxCgxwUL6lSMMDmFFzF7X7mrtlG/c6EHKy6UbDlNCcQNj0bdQGA28BzDphxaLfmcMtqq
4iNc75GouNealp8EvEMZaWRqcJw2Oq2GIKsDyQf/ALFtnEt4oCUBU5gVX/43KoO4p02drxFyOGNV
VZyxg1HciO6GBoW2BFFxCEeVZbvzAGA0lXsI0BbqWgk0BlFceC8QMOShWn6lVL8BEXp3VihFTXys
U+o8UDblXXLsxH66DVuNkGxsn1KIj5Of3GTD3GHWxmhOoLZdRoNu9MuPT5iSMIXm6OYcsKhcVTJh
hghQZcHrSVe3j1K5YtyPEXYbiQiw8qhQyOoJxmr7fxMU4ulggoKo0ZW+tiLUJkV4tlBx+C7+5pzW
3NAnoUhICVynI0YUgX3GUDok3L6gRfIOx4m0R5VbGfFY6hdXWi3cThO6e4dC62X9sm4U1YeY+2iU
doNYi6wlME4a5MkRi2tRkjeRNHxFisfER0poHL7glB6jpuXuOG6bnLwO4QqHsaruOQhdy5bTLU3U
oPDkXJm9LVfxGOzuD/F9HJcIHdwETcTBUR5h5j6DPVzYW3lWC8Hq0COHtF2TAbDq9JYB7FrKYMOh
uIt0O0AjpUOgtWCyWu41pZYYb5lzwnQNAUD3cOIRqTCplVPIhYALTyY+piyyZE3C9lpBIk7KTggB
lRCwWH9ZWj29wxzGnsQLfNaJ/M+RhVq4dJ0ry97LCR8Bf8w8Ai7FsqDt0E52L2VlhkXUhAslLKDl
81FgN8X/AFHBFHzd18TEeWIr74A4YbEBYoq/UTvvb+CMCKvSf3CJMW3piaVroIprgEDkXmE1cslB
ZLsxB4RCJYvUyml8gP1Nzk55v0gSdwq4sJqaKloBxzv+J2ADVx5aHIcwMReLdR0jDXD1LW0SHZjf
E1YRH1yCq/UsJ5FP2Mbb5dPcViQWHiJmic08zTUFNdSwSWTj9xUkT/0wEK7EbuPUaCGzyA6Jth1L
uBROvK2JpRwU3ESo88iMW4K8/iUW0RUYsAtUk72Bw7E7E20bgNjmxVtx147QoVAE8J4RsbwHb/iO
5tAP/EGvJ7BFEUbT1DRaHULlu9sTVYjbLmj/ADF2FfGnxLL4clxMg1hwQHYD7UZm4Nht/iIMcvAV
9zg0KU3zTOLlKQwxTOBlSXu6Er1OVo2XR+pgIba2NKWszY8QRGHML4t3iIawIOY/qMsLUCD46YIo
FQCu+5Zp1prKHUKphZLYRK35vJRGETbO38RjmCu7PcdbUQO/iCDgFn7RW2wJWRpQ04ZGVuNHDHXj
fGJxAkrQeILoQNguB0bFciOCN3zJYsijXJBmQiGsV6uHykMSg8VHdtoFhepXrqxTUQ2gAuCI70s7
+YizaUOHh1NF0UDuOLjDTCvqJsFp0AlsSihtq8ZU9AOBYekoAyn66ihwFkWBcPTmrGAGyrcxYCvJ
zcqOBrGO8lCDwICj/UyjAItepfiNzNGITkrAGlDnYwoz1GhWnYvZUAFOw8y0WOYFy4vmeDyTEAap
ib8cwjTWTWF5Al1iC4YiKC8Ip5nEkEH0Go1AsstCGXaWwh/8QjwrVwygdAkqkWcpwgnzOEHgtieY
TdBvlfHETBRAxadwVXqgtMrim4cpjF4+SRfEq0LIBR9slJkL0DVXlZH/AL2goX4gFZwsjOiUCH8R
vR5q4Uf8hOiTaa83CF6wI1vj5hCwd2W++onBue56lCv6mArYgo7lmGQwHCUWn8R725ft+JaKVfUp
Q77m+wK0RCAOJEzhvUzwWPJBopE2II2r4JUZTV4nMYK9XGpidfSHmWqTq4k1YbXjzA4SPBleSL2I
eQlYz5J/cSWpd+0WAZ0dokS7PlAuF1FcTQ5cUHxkdg4xHMZcMB6NGOvTniWDTUEpww8i49RYD9Rb
p0joj9QEN/mNzgPUSUsZqdQ5FhG0mJWm10KUjFl8VDHAFhihFQz2zIyigJdsaVNjbLDl74YeA02o
eRTtiFXXJ7uKBqRaXUWE+ASjlw0aDAgFHNBBCGWBKFrVXkOGRzIlRW7oDDdVbEHh6mo5IzGMNht2
j1kWtJzuYtx8L4eosQtqcAwUiADUbcssDuCURzI8oFwnEIBnJUQGHpKnFQ9czYIDFkdJOaEqN1Uv
iALMa3Luj5JVwZd1H4xyikZgCcpqG1NUe4LfyhRzHHodkuKFWwPKtSjjxMJ3LleWm8CONBL04lq8
YpUqPUKg+0LKHHxKiLPRzLYURYNY4Lo8mWUFgXHdRIVHVQhiaoZHQb5Du4W9BLSqInECrCFJXNXi
5XEQWuodAvNsih5IE2QGWae4YENVpCysFRmu5dSmwCqmiLfQfqb0htXqPJdacLlVi2uNwOQN03jm
CxL0g2LhtuZK7g1siyknQdgzeCSuvcAfqFxzASqox1cCAB2jiZCrL6iEMi619y59Hy+YEoB2QYVC
kCLwjVhCGh8nEr7W+MiFsDVEuwZoo4jkZYqve9j3mOm7FhRgzpcphTLg7Cu6MquZTrUX0OxMDTGv
Pc4wHLJkisDiIZulx8eZgociiPFSJzvxKK7lbldtcSKF1v1BoFXYUYZw1UtKa7iNkFSkE8KGssrI
aujxzBUGJugiqRGiF15FRtKGIVwyj8cPUeAHAlsgBddSmKVNN4jyhiIRtEB30xu2Zntjb0IKOpVd
CFcMpYLC7t3kfCdy9fxEDl1DWBheojBuGwLcQJwcflEw2BgjZYCI8QxhZDA8wZNa5XHBLx3E/aF0
0DsYg6GyyKLQg8tgFCfBXHURUFaMl4Sg+iZBRgaFFHLDawn5+JVSLKz1GIqba8v+QIaOIZ1MJIDT
txz7iGss15bNkhrRZY/8i7peIqi6i1ek1HOx4WvYVkYGuKnPhK4gFLC+IVqlj2eJQjavQj4pBVRx
ATcpV0Ra62O5lgfN4jXniG+Lt+D6hul3LqOUOYIqy6gHhacNxiCdfyIoCUUQL+eIcyyG2DVxuMAx
Cr61Os7qWoH62l9Rwm615q5x3ygqjqDj2XirpxY4e8SGXnH7jKgXk1j+xZ4QxjJOPf5R6qg+B2fi
Uc9kZUqMnINzf3FFdRTT+/iDHLRVBfEG6pW7VOHzSr5fqIyOwDPVyl9sGl+onwINnJ+Il+otiWPA
9j8Sjwslvyf4wy52gWIS5zCaX2P9ShMcNncPebV4G7uAlCIqUHkQ6PBhoP8A4g8g0vtdkGie9oFf
f3G3Hd6zxOHn4ahW88TBwna2BVx+tTTW7id/dKOXmVOnt2NlEVoVAvK647g2FPXgIIAwWBcsghKI
JqgT03VZN3zZVlcSyxsnb8IhFfRqb/iVNCC8OchKQSHqIK+2y98wAg5LvGVtUMcNHMqBGzxGCysj
YLMmOIimMbb7iah33/8AjEMTXDACxI5DR9cQBTnFQSwapo9Sh0a7TCoZn1sXqt75IGVZg58wyNMF
5by4mWC1+IBABcIzF1TCq26+XmBL6SvvyxEthJ+P+zpIUQ5WqbyM9ORgaC4q+5aYbdq5gjzwfMFq
R9OIjI8y3RxBCyFxCU1azzBXT3N4HApTPpTlXJ6YeI/EzpK8R9d/LUUaA/EIHWjXZdQfQbsOZYC7
6m2IBcBDMrYlwIoeCo1SwMRcdrOMvlsapxASnRR+JcYX3c45S8jcY9JqziK1PYVKlUBzFhd6+YVR
FeufCD1pzL2AbFLjkCeM5jRliwxOW6+IJ6AcKlDe6tSxqNoMfXLizFR1fd9TLF9bCl8B3NJUoz5j
FzfymZGN8TeoqeZeRfA+ouC3D1cLRaLQLN+KjL1LEgPEZBqsLLlsSkDm6Dy+Yqyr3/cCAtYkGEp5
p/koB4CoWzXbGL6wLEYNgqiVClK8wRVWlLzFeqgvEiAcq7PyoJd37Ki2vcLnTQTiCKPdSrdNSvEv
2QHXUF8Voni4Fmha40hXar1KSDXXCxCoK0jMXrdZECbVIfyhMKpx47mMVZSoNeB35jMqC0HVQiQt
bpouKkZSz8RjolwfUvb8gVVLOgU1jVJmfNyiIByPERwJXkhcwU8FdhqxXXcUBIdXXlHuAX5jqL5C
LRUimVTl5hQEB1EtlP8AUAtVUVGVQQnV2dIxyW4dpBUYZVVv8kZKCIk/CoUFHS8RlUOMe4yECtfU
tGSH74mrIA/EVcbk8xyDavNxhLgUUkbbbwiXyTCKaPmUcVkSHRaWJ/71EuqkL9R0UhQi5QujK6A+
ogShFZxkAmzPxMrdt8wYKwCNht0tMKiDN/MAHn5PFXCWyuvGQ274MsJkB1xDBCZzmEqIgPiIXBL5
MVNO5FpUJQL24qVKwdsFfkv1GyjDp+UxTru1+oCW6DhUdQ11L93VFrKQFafK+onpEzqWMbK/zFDP
rUtbVKnBOeCKnv8A9kpbAU+/cIjoC9a2AetvgPcoxpjXzAKleDwsFwVyr2SgANo8yxqqdmsRWNU+
L7lAFt39pcCgn41nSoGRPnHL1sIJRZV7Wb0iVI4qvyfMpoWnZ1FADJ8I6rdA+pfBP8nLGF1WnsXH
Eq/+v5ltpUVcrGIB4i5hnEGBlImodU5z1NL2facldzwNOGIXfWfGyvaJW9U1FgJWjSWwnFgxaN4n
CcD7eILbsXftjr4mcfCMEWlHi/mViIC/iXsEnmdxm8oIA/BzBT0KP5mEldFuz/syWGy7zP8AZciU
PRW9z5o1SdxkoBQWi+IozQcI85fcpubdrsefEsUok8OLm1X48VLaLgLdocwKp0BcPEDaDVQq2mYh
EsOyn2LsFXWwPQiGur4Y0ZW9qrmbajUw8VKrhyDh4hx5NVfBBfy0qllp6qr6NinYrbhfH7idgBKD
f3EJINsBxyZK1AqNtfcNDSTv9SsVQJt8bUJC2hERfmOgcCWdF/OS6tJpjYWAUAgfdSEX7EzR60VQ
Ipxu+TGJMIXa3nJyxSUdFPU1vCnzT/stiEo8pqCvCyFlOKjwsjsqj4S+18dIeH5jsqegvtjrdXji
UuubjTgL1BOmF3JktRdvvoitrrLhErK0h9yhUbbRvGcMYdm9gEkC/qWRVhlkRR0+7mUa5VDvO5QO
8+fMDQQUfcuwujlwVxB6Y4OaqLPwB6BfMuPoldHmcLIYioLZXXuF2MZ8R0ZQLfBcDFituPXCjrm1
/cRVBc31kry1dvqE0Q8xsG+oyPCiNoQWwNS6EG4tG9gc8q0llUU9MsRS4B2QKzuXR4vqWXqpf6gH
vpfE5yqo+Yjjap1F1iCThqIBuuEctTXPMfivzM/5BNcLXO9m7cu8pHxDGTJjhKiqlm0x5LdZ/D+Y
1xrVwtGm/eMgNiqlxMTdRMugmGx0DpcHQwK+E5iVito0yulw8GUTR2tZRJ4LfMNq4LdnU4TUdlUL
1hG0DGYfXLcpxDl8UsDJRY/EJZtjsQu0NvicqVweI95S3YIGtLosgRwNr4gp13weWZOlQfEIlAK4
hsAo4HzFc1zD2zKqDi42KHFXFpdoYAUsx2ALhkS7zjmK5f8ANl8SpkGDjZtfIQgNcXzARlGEjjt4
jzKJx2L/ABC3ShlRir5QVJEDfiMJRYxOU3vGxSVFbbu4AD3tfESQobtyyewVPDcGxli/qDMN0zGY
k9vcIjREr6hrUAXXCygvXb9VFg6NCXvmYJQZ1kOe4K9eoFaKVfM8io+6jUrlq6VxFCaypiRJTbAE
VgV+byXNCjXzcRwR34mk4q5XUo+WFeIKKVuvERFIp2opGG2/Mcibz0Qoa65N0uA52Y0pyiZKF7F4
qPkqKYfiauVV/ETRteXu+ZfE2aRZTPqdQMitzu9gIBgkNjBVMyxA7Xo+YQ6UDR+41663LEvIs8wb
0APqKoXgHfP+y8IErxKGL3BmXR2BQp7YPLqjYCawCo6R5YCgTD6qG/Wr5IvIyh9zXAB+k8NAJ9S5
xLceJWakfwnbFSvOTzuHviWlDyvuNpTpZyQI5UrHGxgdKGniWR2mvxLeh7tX7mgZIabFJ1Eaq7gD
FU5+IlCUBA6EkE5tPUp+ugncBAa6fCXCRaBp+YQijr3BoKIV65ldxKA3b1BgriH2wzNYo+5pRdIe
qhmCl9U8wIDmF+yABcXD3fEFQrCVmcDK2IFBQhDRdwg547lrv7iU+XxZEk5Z7VjlAq7ZyyzKK+AN
VAYGS/mBvWIO4vHXV0eoGNCKPwRp0tNtG+DZm6k4sWVZBAPYTbiWg9X1DAI3E7RiDvAWfNxPpJPz
MflJX3OFjSncweE0KqFOkHLUSnzXMwjbyS9ixArK+D+4+t0IL3ceqtBBzY4BzzKbAbEdXcfwzoef
cRAkYqb4jdqRB1aFbiUs7jKzWpjvmFYA7srolXKnU6PiH0Gq2rvzDCBSXzcqdBaoPHFwwwzWbHKR
dI3xtxUhoV2ZFmvwU5fUq7USFnuPhDgUwufEs0LBSvBLKDxFuRrF+rxLRibpVTc+xewPLGjh7HX+
osEleQcTlaXmk8zqChCByzWpQPdbAZh6MR5CUI71dTtt36gnWoZaj8wvAj3Lekzvl3a9Kr3MADTC
u/kipa3A0XR+oLUhUKb+yGXoJ9MJxZonis/mBUXt44Ri5RTF4DP5lnTV/HMKqXtFOj/stG1APNrI
JNQeNeTIaiiQ8f8AmFwOpQC8RYBetSkHyUo/cFgaYi3vhhlWzYq7ja0eYjjymVDhLhMxe78xcur5
PEUFDSc3ENso7zCMAWr1iA2XrDTVmPpna0a7xVQkBpXxXmHyKx8tlV4HBUAaC2QKg136qGx0oeUS
PbojmQ1b+5fUB5OIejBVxPdVq69QqrSKFy32C3yRjpbHlgd/k6jRarWbOB5mgLzBahnuLVM9yhe3
3F1yXGdcx0riATeY/uiXY8kZLS4floj425c8uHqiVWcr9wm2NEgIOo95zAQZXMZOYScn5e80GEMo
GF/qC9JQIQ6HUQEQ6X3ULZtMJvwZo5CyUbiOSck6DcXW2aw3SM8wdel7gKqhd1sQjBdTFQoylMHJ
w/bL4NGhxENEEpwXFSm2XSDQxdMIw2DsYJwVYXRseY/qtw2LghfCIDgUTqq3odxs9x+oHZypBMvd
R5ACxPXBHEIVSMqPZTqlhb6A6yHtzCnUFgPIu7fmBNsYY4sT2MFf86hUtVvioO2UJX7lT1bx7qEK
1rzKKG0V8bEUHBPhDomyc3HS1t0kFXmvEBCnEBZoH5jTUyX6jBBaOY9F7v5jucgDn1A4G5XdRNLF
37hNAe3eriUWEHwqHrEHv9RhChfouHo01Cz1hNcwFAq73sfAqULmmLtXVwsCpdC/BIoG5WRzYNW2
DCeN58RsK2VRvUuqfQEc00BHDSg5V9y+VstfMAj2KfEUkJ6mbv0DXHmUshrX1FimKs7dwbhrs2UQ
x5yCl0JcrUCticSwIKMKlzAGZzBYGGIJ8EKpawgI3CWxCl2PJoaUMZcC8R0NlG8klcL6vOxngUXf
nzH/ADYLhdVw8HM4KcKLpg68PMuJ0X8pQxl5FTOI+e4WkPLxUv5omdxCXvqaCASsFL9yroEBjiSx
mxYiX3EabEiRdXb+WVAhLoYuymRXhwjFG67zi4iawczxBrVropy4EF9UPMBQnb5ZdOQDnfEPlsYL
D/JfqoFXmc0AFDnUFyRhRnhdGB88AItgECnsg1KI1zkdh22pKABoKPV8x8KMDREjwRyDYpigD1Cn
moO1A9IW1dQhN80oag4AcTreZRbjP1a/8grENqpT8y4yEvamIsHA7rmNt1wwbqEgg7dQ3g3Ld7xD
bgo7a39RjLgLYvuKqtJMKefiCBTW7a+Jfhmjtyig9wqPHuZABxcc0pVYvPuZRa8xXiJ3tDseo+E1
AVuqe4EEF1KoO41BApie4oBwwaElZeWuOZ0RZpldDfUStaifcRJSWDgQNPyK6IUeNQfjKvDqrLck
dD8ni4YzOJJfN8Ktzmv7j1Iezi0JYWlCn5ZauHQjbkJu+sIFC3zUUUxZg+iV5MVFZKOUADldyY6r
BVIzf1Lz0CkXjvI4PpoD11DNnLvA8wGUnPZkd85kNmFfAKguoJQsIOFZbc4iq3uEarRWWkIo23gh
eiCoBjAtzsHhvAATKvmK0o8DhyWM8LgaZjH4DXGl+ZiAQoaqocqarKq+YcNqClZ014mBEpNrKKcO
JvsHhh8gKsFr4YqVZeC/xDHdM6B4mSVDoZ1BwqrhUe55uEBdiTobzDe+TxsTU8F+X9ReShtTjqFi
UFcBMPxOsVGxoFl/MVEoGNpZvriJN0O+7YBDMAWlY9xKAqFnb4ggBipHzM8wKjwKtNc/mJKpOjy/
EPg+ZY1HwPdtLGKIYqkFqWVBpOYrWFfMQ07lrPXuX5Mslg3zLEtK89XDYbTlY1I6kwVLNHqDqy7s
VANCbF970MVmfjaZxcOoYNvdwlmEDt5mavFbC8lQqav9x2otgyxEfA5g2Q0LXcaoQ2d4h2kiSlgN
t/LKi0WD9K9jTMbIwXhjB0vLYNV8R5Cy43ofGwx7OyeU2KDmMTkS5UWuyy1WXMC5vxRCrnIqN4jo
NBp1OhhBW/uXFExXWGuXse7lwxQFjJTagwJT+42WFuoAQ1I5TuHGXSZ+5VOotPceBDCrr3DotQyq
iCEmVT/cSGWMc5gtum30qat9NVL/ABLvOIjCHe4vC45ZsLeMgckTHENkhebgAc5NK/uN7rblN/ct
oXcJoWoVC7gdwbmvQUq24rMqgG0S39zjQvPJ+Z2AKq4cneNGa48N5KmscftGJw8KCfuHafoEr8xN
uuyRXBFW5ikQG+IAtKiBzHmPiFaUVGnk7iP8zXq14VMQLh6qVdEMLmRTroV+5pyZk9qIoKhS10ai
EtTsdXVQBCbQUAXYM5Wi5grv+ywevMSuNDLuog27IUBWuYIAEVY2fRLKDWLyytydYvWiLA59XBMN
0OxgJRt4iNHAwd/MJb7mghEst/Ms1SuR/cfYXBZGOxtjouHnQSlaluIc2suMbMqQ3UR0m6LBf5iy
ds0f3F9J8CEYBeijnIusLo9+I3YVzZX8wgKui5fCIlf5gfCrDUUkBQ4X1LRgLt6nMAwzV7+4ixEQ
tXMV1tstH/tgA0l1jwpbFyqAN3kACUK5W/MDfJLabGxXAupL1InW17nN4Ts0/qIKqNGKaEqllQFU
G0dJUkwVogPXGy26vuY0FCqb1F5FnLVIKqlmckqTiujXiYwyaL/qNTtlH05hRiA3i/UIo9dkYGRV
7NgAqsJDgdxRehBQNNbUXRXG2PzCgHqOSnzFFzUXXiNX4Hwk8zVIPfWx1YSjT7SUazCBpNhT7hHa
B2QCspf44q24Pj1A5pG0zeWHkS3Aiyuai22LCxfQFQsYHHBXbAKchYGo4aVnIfmckPzZSXRWBUu3
tqJNq1dl+VqUF/qA0Zzpf6gTF1T16I8oYImgeIxKu3RE+6jLzsHZT6vRvbgEBI9cw0BSuWfmb5ru
otptS0r6+CDCCtCLktpZ4uCvu3RinD8yL4qXwvSQ7mvCMhMII8s/curQAYNeNjESoXkoQfbz6S0d
MTa+4uc+bM5erB8zJdKG3EXCq2rvYvR5NGwQU6RF+bm8UclsfMZSXBWRhaLnht6qDn7Wlgzz9iy3
AbK48EvwV6gABg9y10LFb8SxUui6h9Rrlc7FlakLyPEONMy78olLFUhV/MGlaeJ7H4TTGJVnT36g
C1OFc4OsqkPDHCjcJdJ9RcogwHJ3TLHvmjoYjRiXaLaB2LiZJHOCp9rsKjCdhSLfkmxI4E2oBWFn
CvqULPwt6SqABvmYCHSrqAXAgXCKtl+bqVJHax34jd0g8PmW/wAZ5e8h/uckBYlWWg+Iy+c5D4lI
wR65ls7otbolIvTpx8xY4Hx3OyLBB1AL728ows2qaeGadPIlhKEhLejE3z4xPUfArR6mSS4E/PzC
3nIlMWlBveLucYbVjn5gZaSranzFJq6kOvqWoH9ZAA08JbIEbaHRFa0QmkJArDYDLpCnHXMs0qpW
jNAxOZ6kbFFcgBYF3SCmxseoloKAgVYHc2Ply46OfM3/ADGoX7Utrv1KyVZm8/EzAJeHDCxtXQls
Enzpe/bKMMN03EVuuDhi0AAy7ReBS+DRGw3PSojXmeU00ezomnUpqFWDZHgR8Zj4jJeplbiAomlh
vcL08xbXADqJackq+F1zL+MipNJGGrcJT8Q8ltWdw/oWM/uL8pifxLQWcqdS8FWjVQjmdykl7M1l
xeMqRi9HjtfymYAKxEZzajyi+Q3bpHDthpWRag9waar0xInpUc25meRu1diAqXWI26XSRRHupRBv
ko8pa3Yu1GE8dzXEpIvkwIkXKKoDG+qRQ7OKBIjSaIOTVIV72MAcxdQ65tJUeyT0GPXg7SqmoBuq
OfiCOFdaMvBc+7lhmt3Gm42rj8MO1LTeJhANKTGGx4fiP2dHg+pXhWkucVMpHrrockroG8mcUPBV
wQDGcR/OFDkRci+fmCFdGNloFYKaLjE+CJsAjolHHEDRCEi5REZKu6HmPUw1cfWQNEGe4ZgrwtrA
qlat/uXLYTUNf1EeCVblzuVN1LFmpYEejycJA4agFk9QhIh22R1yXQBHaK0AarzEhetH9KmVINW/
aLh3lBMlVgzhtvmPAaOAyOKIHiou4LfaLVLaZfEOp0eWBVLoh0bvVJMrB7f1FgR1o0ITFV5W/wDY
pNaNY1+Jc9mhZ1cQ+mi2Q7cBdHcftjo67ZSq7WcS5SGByv8AM+CID+prSYVSHjZrpWAJY8emtiuv
UUG6gUjNqf5ni+V9vzGzQtPD5gWIVZ/ECtK077+ZUipoMZEmWAhbUQNJalNSwMaut/M15FhzKIPn
QfuPKbg0yAYjLtKEcVkpU1vxLA18S6g8g5gIgHQAywUVtQftechfSasH+RSxagNiJRbGtrzFclgq
pTE97Vk4plsSldIOkpQZwPMVUltaT4lsVpXZBSSUKCjmyhVH4i+guK5uK02BGRrKD/7Kd+HLdhQ1
QwUCTwNgXUXWnwlGJdHPzMfUqqyXCw9aGkOlwQNIe49wZgsuB8QI+5pekogwF5EKTpiY/c/D+I9E
egKsLY1/CRABmryvOS3lFOY1zEe0Z+COioVss/jhyr7jucgpcxhinA6xh44jnv6lLNVUMhLFUuLj
5fIJbn5I/wB3wVZVylWAWRP3Dg4oiu5ZdeIaL2PZcCVSsnmN+kdtKhTluG66MLxz3AJbNDHYbtaQ
JtxHK1zu5Q5do0+VxNpgaQb5kyfmY9qD/qZX3sNPXHHuMWah5n3UXGJxq0g6Q1Ls8/Mb8YHWZAIk
Ac7qyBzBvNb4gXV1Q27xxACj1iAe5c0bDRp6mq7FM5hFkUNyz5lFBRjz7hLqi5RY5PcMfpSDQhPB
EtFr8Syq0wUnuXuy9LseYBZ6Fhb5mPdwMV/7YlRfL23UUuKxOXdsXeW1MepxuXQzTkFMgUBeOo0c
UEXX3FS/L3VexeV4Zdo88QzV60LfMuS0kFtOPiOHXCnPqaL0OGncHXss1yn3cNNV3A1p5qIqVqqc
bsxVx6L72c4cgZLalBsFPFGXvzMziW09ZExWYxbs+ICZNETuU5EgDPMFAzYBfifmEBOtAu7HQr28
oGh8w+tHTqufWQ9SpUwYXDBRNv3EoDKm16lFktRqldwNvjGs7bFbZhVVPuBDd9iET4MDlXC5zAFI
F6lCgJ4uNUAs71Cova7hkygomz0O4rKiSJ0nC76j0a542dleuQbGawPPceWthOGWnjWgRHinLjJh
eUWjwoo01EgU0OkWrCNlRmwoXl7LSCB5bUWh66CYy7X4gCwQl7vj1KmivcfYvqVTmBRYJAv5iOkW
xAWxsMviJBfxGIDiUnlqwu/zEcyAqVk4ZTpARYXI7lhVRdkseW8AfuX8KTCElBkDIhTg7hIFeGwn
lKFfEK4qZ4gqpeGpixa9GeJq8HpC6QakdreCRLEAahJXbKYd9vFRLC6A8BCHAK2qhgWPqF3wdDAz
tS2RO0HiOHZC2gW2OYaaU8dziCMA5hmtVsPCUANDmio3hEvCBd7b5bCQyVsV1bXiAxuvhkqLGjwT
mO1VULqlYVGTpQOCEwp00joQcBLwoYJ7gAVyQmOqlqcIAXacEqBae0pjFIQMkydiRxrM9KN2c+2b
tG76PuYpHmUKYS1CIWi4ds4E5vt/5GqFWAHEwkA5LvKEqozArlkzWRKSFtiKPzKbADEV7HhKxXaw
hSx4Hc3Cq7qF4FW0Z6hnD0RVQUrHEN5rha9RUuJ6gJzlcRyoskz1G1q4BO0qcCI0El1rX4ZYE6HF
O5xsXUMDkXTqZd1dNcRAAOUBOKdolMQLWwgj5E9xG9DE4RCqh6gQsMfmBw/Si3+ZQClu6SpYvBKK
rN9NQkaym6jMmg31GPK35S+MuWouEvAruVsKiUKIf4WB7l3wXv3WTa9vrmCiuz0YurqIduf5IJ6T
bT1zBhpt6L+ZTAr0OGu4pHIoDb6iqBvdy5xBTRcrKgemgXOCUbTli+FikdShc1tKgw3k+upgFSq8
kBYKK8BnCRLsVBtGsc1Uu/Va+VTrAbRxkU9ZscnmDuGn2Lh39A1Vyt7RI4r3N0hKlSL5pkoGNhnE
KgGwyBiCcYWViOPFSmMaBKa4ittpNc9RhX7AimabqZdypFoselQUuC46uGXtD3RKywWxyvMGRsSU
y56RVy0g8wma1cfxBKpYhEBDMdFq7ZHiU3HmVBRfEEyo862zjnhRw9xL0hw+4ROBhC1kY4mfT9xZ
hgp5f8gCq4FOkpfXc2W7jlVikstNhJXouDiVNZoV4HOJRQmhglTOwRR7iuwpOGuZuICjZnmOSnkc
3dMQc0sXqVlA+4yLYOvmDrgc6P8A5LwS5c1XAZsaVH0Tey5rllEVIHS9wk9AWzgtPuDbogaOYJ4K
BDaqcsZAql1RBSA5XOXNBhrriiMTeVFm+FgUq1s8xwWBJdaFHIPiXO3af3KH7Eb5hZlaarqU+MNy
tlzfti6zmH3QFZsSQdLwV7uUM2ty9qXlZFO4tKtY5q/Udb/qOU1FoBrCmmB4z/YSIQ90bUSx0pTk
dysY5zvKP4iQtCLXT7gkFghzQf7L78vDl/8AMEslkl+86pxZUfx3OUu6d0av2/MOlLVe15b9xlIQ
V0aThOEpSJcSZv4sR/pEjJrW7yIxrgj8fxKybjGDhyL0hDVRxUcoAWU0i0FzIvEAKMlzV5IRxgAp
KS9Ufip5PiZRkDTZ5hSquPpkQO8k9xFNvZBI7iq1yJxgaAnMFL4jfTmfKWgFalRwAQFDodZkA7Rc
KUQpgBfEoumg34iyRqDuqqVfKvl14iazSTmoXQhfiEQA6RMAAlk0BqnnkhhLaWR82HE7KjfO/wDI
UtSbfUWoVakCuACSXxIGXXAkaV1/EGTdO1zkSzLRBCKWVGorqGjz4gEWEaZ4ndwQCY7CwrZZMyCs
vfMCxXiKJFRYTwF3Tgh9kdUR6jKD1CiFmMggWK6hxogj7iCLtIhKiuYhLgT5YQtKVuXzQthxZIsE
qixfw/8AI7UUXZKDck1lQbO9twxqFWcRLBQV6hmN2OZWBGniGv0irY2diqfMY7WUp+KKuVOr4gVo
TmLihDGXkUAwzHogwAogrq5E55R3FmLuYRXZUKttqtxEFvuJAU1yEeqUqPcobdv6iMNGI1tHEBaW
s91GWVeTC6xbO3Wg8iVdkEnm1VCAPwJRiYN/cb14OJcBVDFRXNTB2YFRFOG+GXeFvEEgpFMJRSlV
wxs2uvMdOcag6SyfnxCOM4QOukrPUAt94lNzxfEY7wspUWy3Gzn27X35ikLNpT1FXL3MuhfIggAX
MOWIltVxxQqIXEBAKiWiRiDxF5XQZgQmuLllcW3CPZgyjHzN7IOWL1j1CVXgclI3AHeo5oq5VCQ4
JfxBuhOLlaMHiUHJsb7g1NRtPIyogvtXf8RjIItvJTW6wMIL70K801BIaKW2ARqsLlgUmxO3cYKn
BadPM48tUO7i1ZEx4hKwi7qauNXRnOc5OsYUxLppu6ldk1DxOPAx7b2Gv2APcsaEeGotigoDqMvY
Ua/Et3w8Q2FWwjgio0fZAA2EQ5uLe2LHqDRc/wB1BEVeZ8S5XRz0ShuagL1kTpW/ETuiEgi0Fh4a
jLQ9PqE7QFj4lhcNA6I0S6KF+JQZxJXPEtUvW642pwfKV8wvY4etg0EBf4IpL0H7qVItsBOdhuWW
0fNQP06Da2Jnlx/JDoAX6p4z8b5tiECjA+IOo2qe+WZJr+ixVELgdF/8gKDsQHQUo87B9FxemUpi
Kfmc8IZb2VAcvfUcg6PqFGWLa2Nx9jpuH9kR2rgGPLYRGk3xBBBVVzWRXXQv2xtw5W94xKm2VbuC
EtWl8RIFC19MaNdRGocNvqMxQRkMYFx5FEd05qZHYCqA/coAXVsflgE36iKeQb1zGedX1XcFWAH7
QXaGj6iGU8CXNXc+ANlqQhHIZDbUF288GSlOZl7yIBjPDdytMui36hUthYEAXmC8xWW41ecgDxSz
zOFFJZxZcr0G7OBzCJS6b9SlVoJcbCjzKxN1zd5D9BR/UdsB1qwrCXAlWc+oh1fAPs/2LzbQOUg7
AHTgcmfmWXLq4+ZRmxofMH8LGKrUhnYwiA0GV84wbNrYYTzUb9UQAFp49dbMvU53X/YAgbj6v/sZ
PIm461GjcrfbynTxOMLTX4jAthPiDwIitLXZCqtUq+3Ypu3/AClFkFcUPEA3liuoL4O6L2CqQA+T
/wBm0u+3ku4ucRQHiLYdGXZ7eYBrdHVht/RBrM2zl3/JSEUPsILR54ljwxEhRKyz6nQcieXEYlXT
K+YCDWEp05YHMTFweT3FGIVlMohABYSoORbjAns+5YryD1xxBNlajmXoZ3O5VrClvPiOwL83EFBU
WVFZoNFc6Rwm0GBJS1R0GxX3/sILEFz4gitTb03LTmbb8TLXf7g/MGx8W8fmHSwofiMTDcp5j3Xs
qtnMertz1x4lsPIlrnYk1+4WUcE6wKwuGRrmEKholQlC1s8jRKCS5jOGLYX5lB2hRL6qfxETj/sQ
N/CaxZW4dCQLUvFBpcQ43qC4nMlwYH+z/seWa2YpoTiJCs8QF7HEdqULq4UlmwTbKIvPEHat9SlT
aqT4i9uczEC1FPW6gUIpV9Q3KObD8RRaKCzFQco/iVlDhHoO7GBa6f4hCaI1HuFKjrZLHuHA5mMq
uaIFswcwrYNuVR2QPRw/MsSCc79Rrhd8xCFiMdWK3TEAjysfUcVDpENgWsRuEbKiLQjqTT0O3zCz
RxZ6gIKXwSomApZARWo7i53QjGFtotef/ZGPEi7fiCgbNsJqhoPsu3B6qK7Zbb4hP4Khwlx0wg/N
S2yyJUSogXr7j6dg0imKkhgzTjfs0ATmRei12LgyFQbhWHxCvEC6KizWUh49QBVu31LkqeYhZI2V
hJTNFMCwSgt/Nw6DSw8xmZB/KErWpvqKESrriVnxZEQOW6ZyzEoJSW0iKkqqgcaLBFUatA5gxw3O
b19wnVKUHLNJuIBGoblouktAXZbEcriijxynEukRofEADdqLgo0oKPHc3xRHLgnq7T4nA3RF0XmX
u3PR9xQGAow2NLHT7nB7lRQPEZFIND8x/Qt78S5VTXj5mN5D+Z1ErbqcAEv3EcrKXZGpHFNlJqj8
MPgh0r3CsloB9LgM10ov1EsAB4jeglCHES0U50LrzOC8NOrlLKEDPiWTkYsSsBfEu4qiNcsbQLSG
OoRXOshZdLR+Ygzv37mYokr6YuWaTw71LkGH9ytkFR9y9o48aw15gpjAhU27pZThgX0LtfmHLcW/
/e4UjRj8w52H2WpAd/BhXFxe8oE+4VERHzcWV4hM1pP35UUH+QZRVmtS+xKXz7MBaxEx1AsLLepe
LiXOmmo0tR4i07bNCsgBtLNKUAr7gjlXVRexNY93iAuOE9VLXSFt/wBSpoEB6h2gAA6Qysc76EtH
tLPfnYeqEgNS4dEp5T3cO5OYxiHlwlsmMturuv5IBAuWEdTaQ86pqv7luBb7O9S3cwXYGQhRc/d7
CCtU8BURKyoefiEjmosC+INwSBe+CUxAIOClQKGWJd8ZANwA5DU6GpRdRoD2NNnV+4NZaivEYOF6
iHW7A6BGcKqWgViB4Te/mO/4p44vmGSMD0RDaRvKPMoFLt6yPsVBUvuI5K6LPMQaqp/zA+7GMPUR
tD0Mqp4oEi+nqbfE6g4uXEzjDSkBGjsAp8so7RVta+EvpcuxSyCFKjXeHECkravxAyC2CbxXiHUo
Upae/EN2WFq+Rr6lc8io8g66lpBO7sf5h01DHh+ZdzJH2sZTQJqizWGSqAbs8X4gW/iQwyv1CrXC
lLbpeY+dQaGUXvJaHefmDEDro8AriEktSu9M+Ym6ArhH11Uq4cazbfX3ExvzMFP9wPgdwLQYRIAP
3G0viUYBuCsoK7l1aCT/ANWVypvxFIqqp2Vq7sV9MXMlxgXcIU65jFTRxBXtNtvHU4UNH4Jpwlin
TBM7bDygGFdLceo3FrKsjSF3TriE7A05itrbRyy0g7xgK6sPmXHyI31ZKuDP4yABfxrctEKlOIOR
WYwQGqxBE24I5ixFJwJdy6iBPDEgFDweIoz9xQ6yEUue4AaS4nbS0alXJxodlhqgNVzNURojQfMq
aWusR3pcHiYoge4dyOh1KAKaQATQplUgXYcqgVQ14lKKpMTLdedimkeYSwaQPPnR4hjNZIYq0Wgg
qEhEmqq4nMWWj3DBC0pRwt5l4KcKvmKULSxqoHZmUV88QaacgyscG7kvCFSXKhGBalbwM9RYzeYY
bhC0xa5D4acl6QcLnG2oAMMxca8gx6Y8C4ohTSooAAKdhNUbuiHqN/EXT2EpiVPPEK19BDLb0TzL
Sy3dEexLOTBIqH4RvwQbCiGw7HJWWiu7IFD/ALoFDX7D/ZkRz/UOgBbx5nGeL2hnQsv4jW0VsoIL
dOoVAtIhPUUSFdnO+l8SoUxfmFxRXPFRjK7TFDC9TxDgVKpxLJxqi2NQFioQri4i7PFxBI23xOqZ
5lpHvbqooh67RbwCWNXKeXyFuOg2mhlkbTky6Te1sp3YoEFOqrYq/acWQNSrsdJAKMq5vcnUABVF
42jxzU64hXVS8IOt0icM50RDS/US6QCyDgULvEPNrS9Oploti+GNGGWDxUL5IW95NuENi/mAzVO6
K8RUMXY17ghgW+1RGtO2yMPCOrgOo6A65RADtkobPKUVMHwhvSJ8osMhYkdAogcIw0DGCIww6lWQ
3Vyh0MXTHJAAfmE0Ly7lbGtexH8wK2lAbQQ6O7lw3MLl9Ss0ABaPtEFWbdiDBdrQHiNLK3uuGSjl
dTJ9fMthCoBRw1eSzmB3Bv8A+TrNW3EQJbc3hGUxec7RMgeBMj++3eUs9tQ0W6llWfFh/wCIRcWB
eXUfDhfzLi5YyK17jAaVQu4uBOuCu4aS90Txs1hMqWqjlguiuucPa0CKQQqvqXnsKyv6hA0KXu9f
xLVrqK852LV/SHbOWo6ItDhLLWCu2jP5h/cCJSuvmADDy4vLEyFeetcVFha2AU/EaLgVfRz+IEqe
YhfEyqbfgCPVYiZF6sKH1ENFFixSshktEjJVxt4WLDAEQFrm3N/Mb9brqUuiy6qAIQeGFcmy2mbT
LcRDRnYF0RRgsN/KEiCFCX274hshVjj6qUWEHkPiNDNUxhW5ex+utqmvLCHrBasW1NozOue5e+oI
lvhNR5BQeriVwJFD8w5ABLxnj1APAr0wNBFGBL72UrQ2WMhdgaE0XxKeFWLGoPErQPhNQ6Xd1Tl9
UHb+YA16lq/maugr5HUQGBs3R9xQ2B2o7h/WjClfMdKnfmuYp21rgsU5LbGD0wRpyqD0jCJure1+
Yrvzdn0e46TGUX55lV8Tz13HOqnavzyQxniimffUXwt+hfMPDWtNK+4xIKcS+WyNgubjwVaSOC+h
xCybKbPV7grFp0Ts9xEKitrTj9wyalll5ubE63p8oAI/SgjONgOoSyxglBW3EA33kWyudgLJXlFX
BsRQu5bxFRVqED0eslhNiDTQfuFbQ6YnG3icz6CA7Z5q/U2WTutysZdULS87K1Xe7HqcYldbU4He
06h9Liqun5ixKfKqlOIciy5mAqwtsp9oV4XGXlg4oK4/EP1qUr5lap2ztlGKSim/3GJJsGc60ErS
bbiitfiGisIh3Y8x14KIB5MgLDJg8QrY6MUfUCDx6hMQuLKMS1SlgQJtwljaJUfzffuPWKDkAVjg
RKdAWdQVg2VURjKHKMIBEh54ilUW9V9R3rjDdeopGKVfFTPkrpuAguADX1K6yRou35GVFe7gNydK
uVwK3W6lOAOjmBTag8syNAWcyYuvOyWKiw5TG70epY6dC9Ydkul0+ohqZtIWSV/mUmqc3pCwt8nc
8OS7Tzgg5Auqg3pB2Rcxe5grjZUDutW3L5YPXUrWYCjkoxUzwwQlvALlhSwhGi+RIHIvZsWgXKN5
LeJWrvY5WG0TmfsXANVzzFQCVd7NoIuyb4mX1D5Rw2Zz/DljdQRVyEVpTxCDlVoJqoYLn8TeXVcW
wuSq28nCb4DqDLSGCuJTaWZcRFaXTUXaqWs1MuvCIe+aaeoJXZgty9Vm6IIKk0MPDQcF8w5ZzasF
UXAiXLm1cxQAwxoy9A9WEiz3rrrxBRkZZZ88wmsJwFn7gDAeXiVktLum5weZcj9wILUMASBcV3KC
mq4v4uPLnyH1c2i3R/ieRxC19TrQ9M6jpHeTail1N6PnZb46+H8x2/6BqoczZgT9pdRm2tP8wP4N
PX8xYLW6N1NqYZqRjc0cR8xK7Ij5+Y6YVQLD6Y8XbtDpL8YYTl5lm9rVa+uNgRDHizP4hzuFNFAx
Mp6VsX1Ahs0v0+ISyyug/GSlCq3SwtoZK0KV5lTGkLG/Y39S81zgS/1HbRVtzKJ54u6lc9UWbIVQ
aa0BCmqfXEUVWIikqAb0SlxUtHPlIAb1UX4z1KLypUCRoay7rqPdFsrYz8FFAJHGllt7l4w6VAj+
Uiv9mTJw0So1BrkpiqsJV2o5ZCnaRuaRRTAxeuLdTEttns8x3ZgDljjpOUNfubO8DYaz9w9H10XE
Uw6IxoXVLTdQYXP1AfNS1ijvtlA+kHTFIR2zk+pUyHm4+5pOkz5lluK8JLcv0L+4lwqBgfARKgyW
YqsY5lvpOa3u5FRU29hA3ymk5kAhF0WrMcu8oQlQQvSGNeJRWzxaWKwNalS4BT256jQgasq4NFLg
vWU8GASN69SzKhbcHTFtLZ+YJQ+Qhz0YlJZbrqFWNbj55oLtaOMtsGpAx7ENzLAOPM7K4un4hRJ7
1IS4p4qMYtqzVA/1KZh46fENppAjjD2VhD9pRjGqBhATtAuWKEpXSeSq7ouIVKPdEGoXF/tlooSv
rOAG8jYj0134lOtPGxJaDjbFsBnfxHZvXiis/ULkHQP8pX0CwrE9So1lXeDaQ8OhPJouoc8ELCRb
BK/7BvPccSEoA5pvKF96lQPmYE2zsI1WoYblrVWm31/s2QQxphSqxC1y5Z4VoGNc9RIQtgQJaHzU
G0Z8hFJWhXaEqwEjz1PgBLy+oPuvUD5SMoAnmNbOPUrVbc0pVS9wbxHpQXyxKy7PERiPHn/8ADwP
RK9rqEE0eIIlrUvZnUs4IW1tKS+K8RKKKK24ywGEX81EXdQAg3QC6l/UtC2JDiUxiYnJ5ljo2gqp
f0bODmWAp1ekzJdfCIn2nJBs0ciCBfXwyB8pxr5jRTS4P8/DGLt8zbDPEDqPPiVReF/mW+0queIV
UTtzEsKuonKbmMvY1oEoroh4I98RdM7WiGA2nHlFi3pZECmBxNhQN9L8TFJPEPg8q9s6CAAx/UNn
Lo6ja6FqwynW1YMMDUsK7jymBwR+Jz3CwS6gpVY0aFQZCeVVKmLUpnwlaey19xy1fX9orChyIUS1
zZkF02OO4tekGHboeZg80i6jKFXiwpY0t2K5Qkp5FGErLrEoRby2yqS7c4iAwHA4hlZ1uQpVOaM5
gcwc7HShqeSe7iOLgQGrooEZpO1qX7TqcbA5NNPMHOAWXSpdWaeYvK68MVjZ4qKC7tyLOlfEC81F
uuQ7FVqqwhsc/fMvtgOsy58EcPO9Qg9MuzsoO19QVJ5DV+ZnHAApv5lqR4VHMAKtRzDAjCrXAY24
CFZKgJB7EtQWJbFXTRLbzoL5iM3DgvwyUWk7BKNE8ETMiyvJGfBctpoMOAJZwhVCBKoFAdg00Ygt
oiNOC+YB3qquolvwuzVS7zVCeZQmovXYmy/DJywBAIlMpwTijR4LGQiY8ggcW/JhKyuteGCgNWML
1NucEEBpaIO+2Y9mUCo7gzii78THLyguH+Agef1E8RwcEOtpAU52Pkb1rJXyK8VFGOVD3CG8A34g
rPy6DZ0nAdQ5bm/51wKDsXfKMml0Fb5iWmKCt58RRAwscxxdzAMPqWtbWyoBq74lQw+2NsVayc+l
XjmU6FV8E4rmuFeomY9jqDwGmWUwhZW+Nj9EUR8wFw5SemBbbVqKHogczCNDbti44hVlJmq6Dagb
hliTNUY107lKIUvAJWlTw2wAo4ex5uViGzC5d+fFONm4Wzg35h0mGAylM6cNC5eavJMq4ONrQi7y
UdgUA4Y59aoYbKgilCGMuuNYLKl7gNB3aG6uuf8AEVgpRhKbRhhx/iWONQ0w2Bz7QgcRhTW2WPhG
J6tQ4gtRFjzdTrxWcsW4gSYnWwQ6QRo/9kvXijB8wKyisXT8Q2TT1sq/zjV0QHT+1PKKEzWukrnG
yu/mCzEeAbKLVwLaRX43Fy0hJBhlygSmei+/TDFLBkwg34RcCEQGAL+owkAOsqrioDWV4h9IKOFG
PGUgjgf7GnWsDIfPrIFwhcQAOMQ+qgIdkPyBKDlrmWYCIefuUZOBQyr4qVgkQByRyRiZVPFwH3iC
31UUNYlDvj7jIQglXXLK0WNOI55ghdA3O64ixlwgK8vm5RomVyjUDiYA/wCTigtWaGAgWlCMDVyO
kqBKbgt7+Yhx9QAr/kvZ67CkuqVU5NgmLFaLz8yrNo/2WUGFsDw6gBTBKAd2PKJHXcXTCVYnYeEj
HCqEDkjxKwVI3fcTqQA2nslbExtW+4a9xiJSIspioFwonAgFqgYYsiWNd+OIgUqjpQxIdNgbcLXx
F64sS6c/Mf8AMg87CGmLoLcx6FqHfiMx6J7DuVJOdW5tyryTssar1LFfmpbtQhOoR+57EWlqt5ho
hsKNdZR3+o8gUQryl/MRTCznySlA61lamqxLqB3ClQnJn2KDro1qGhShpj6gkNs8ERCh3xOPqqje
p4xTliyt4uCepemHggYBo2Er0C6wOHVRY4SZxXVQ2kVuyUVK7VVdQnaE2HRcS6tKPxv7lSUiinEE
gFqnEORNhLfULX+omjl+pqnUUaoh35lmiHcUL16iYwfcbuLm2Gyoy1h8wlEOkN8ynCuI8FFNXCiC
EeF8xvoAqyAiFXxVw1LQPKODwqcZDxxq3uGoKVpB3yGndf8AZXEH3D9fV19y8Gg4Jqg9Iy3+dslt
vDgQhNUa5PmUQK3jiXahUgREJPDgI8AGjT+psOKA7ZSQqfojKAgHD8QNkQaYRoCzoRL46WczjbZe
yyINVFEygQQMCuogJdV+JpBKScyxCgt+o0CuprFuH97Ai06uvJCxMykORxKBQBxU8LRRZPiRuQsZ
YuI7q/h+ovoU+I0DZyoG5oL83GOI44RCpIA5IglYDR1G7yY2eQJhYPNQpHDCtElTw+Yaqj1+4Qgq
dgx1m6hSgBqAmyBXljEgcfcGIWLg9AK4JSQ3myhhXIrgJeEbulIXBKoEVyQqmJ4qELyxU2yv2j8V
tuRZRS1tJQEEoZcqnogFhzyZQsOH9x3SaAxiUECJL9cwqknZEwCt1U5ba0VFAbZPE5oz4lkimiZL
6AUFbMxB6hEosbnPiW5trS7IeJ5MbxpQB1KZBSjjYTaAXsWRTbiVxT1KFQbvfqM17U1GzZIG2sAn
eA+YAUUCBqDeV5bG5QA3fiVs2q6Z8QqCLgYwO+uukYuXDRkpeaeOGYTSQnUsgC5hwFoN1QUSxsA2
wmqWovhmUJLE9QNBTkdze7lDj3K7gK8S9Z9dKdHQdwicGyea2FYtk+BEvA5R6njxLXUucg8e6j8B
atXqY+Mj6PE1ARd+ZVTQxo4qLsYV67lRdGL6YXBZ8XNyskGnaPHUruO2OLhtDVs6WKVikOJtiDS9
LY+ZSrPMeA3AeYYFoyOekTQCJyO4i4lED3z+oBxhnR3/ACL/AEq8tly6cDK42U57VGuQXSWnDzKt
HJHkuAumAr1/2IfVdB4QzFWEesl46gUjq0YLhpsu+dT7aaWN+1CkuAWEPiYMWHTfEXqAORWhJNHF
GMsrZradd8SmgOm+qJTahU9Sp4cjF8RfdpfZnEu4s3dqSvzE2gAcQaLjFBTdsZOpWKvUBWc3QTw8
dGxqOsGo8CzgKhSnTHsjR3u9iO1YDwMwaFaOqD+Y9w1OhLgtRV1TAI2rrflkRpjpOsqL1Uda5QDE
EC2RTLgwWtsYXttY6JbEsAXV+ydgcUJu/ceBgWBvm4oESS/ldwhQA5lvuHDlSinvOoR0mEqiuowI
nzBcLFoaC2d3lniBT2iVu0fcNoXjDxLthFduzd6Uo+YauiKx05gAW1UA8RCYh9o8M5NXLJWkfgDv
YXtcEQsAlPyiVBUKi/KCQQYbfNw2FWHgR6pY4XStqLQ3QAxxbf1FJroaC81XcB2qo0i733GFcRjX
j+ZZXkr03FKS7lDp+oHN75Pu8hoFJwa95BuPhBTWkaqCc9L/ALjBCq1uhhuB0bbSG/BafLc95Eo8
NzItBfEWjdk0auoEw2NY0TYV4cQTZjjyjbn3uYlWDr+YwYO6mrRTzZOWceUhjDFPGsPLC5XUx4/k
bHbnIW8iUHrrUvFSyFm7r3U74dnxGCK3VR3LRbwcys2qOe4tKXxMWF5XqGd2cI+6iFboKgwKaD5h
iVSnEdnz6igrWKcOYFLfMG0KbmlqqvMVNnnqKq3qeZYSsIFMMEalhgfFQOACz6ZSIUt9pEOKESLN
FMUrjr7JkpaTOwNhmlADtYa4QqdFThxXixRJpEXEuUyCz8H+QkKgczME2HyjDUdH8QFocfEe4Rw1
ES1X3qEgaLXl+ZSgLheCBDBVkvN/yPkgOcIspn2YB9vCrrzcDBA6KgVuuoNAdoTmGVxGu6rBHW7u
MVVyvmCIaFsl3Qu/3MfBiYtloTy3zGqZBhRMlSpcunbOMGEeItzlLohGlCSqgv3Ec08IbkEp6RYm
FcJXUKNbUogKsYhzBUaCz3GZ0ZxzM6uAqXRFp0lbdK4qIULAivE10JbUNWmvEdFQ7ukbXzBU1C2+
3EZubqBwFp1LgqdV7GO4TyJeUEAzEGOW220idSXDwnRgUPU3SUbiG1qVk0nJGEXhH1ANuu4YrY4e
pa1e0cr7ypCr4ELZ6UeCI4CHMVHIdS3cDj5ZcRb/AMjxEvuXwA7Mo27PCWGuGd6ESCtQun3BNY5k
ujoVWo74gBVj8S9iiUthB1AcD5iIKAo3+IaHZXqp72TfO7AUcAX9bKJBVBqu5Rl6HcIAUas6luSr
MO5xypgezuOFo0SKXqK7L6MYAQcvdQa0i6xcptpUy0IL1bYRFCbzyMCkX/8AJxOrlMi0WMdQUUz1
KSAopFWCkZ9QF16f+9zGAxwZwH4qNuGwf1K/LA+IeqeV/wDeGLDna9MM/NA33CYtlX7lNBfLHc0O
D6lto0F7uaFawkDSj7hU5Y31Pg0NeLSI7OA6hpcW0PL1xEGjSqOJWKgaHzCPwofonC83lUoMo83c
GPSts+ZZ6o1b9R4oap9kSnmq+9jFQxv8sMAb6+IQi0Sn5Y/xZ/hK4AUtcs6usX9P8jNzqvjSHCtR
62dmTa+j/Yhjwv8A99y8iq6fCD/BKuE9QadUsfqV6Zr64ZgZADrYSHLa/TEVNXc36Yjg6EbrqVGp
DPwjFa0vI5gOSI7TUK/mNG7HzX/YZVw/YiUItV15gYXDuH9wT5h1nFxB1LalVH4hptgeZU4yl6eI
LRxE4I1JHcnd/wDYcwhLeOuxKaCNFK5FBZdRyX/9i2yjZeKnGlAHAfUPTQLnJTE11j8bajJAyuDz
EUZSjC65gcCE6KYyu9KHJcDmJFWuWsqOFXFoeovwHwKeb+ZTFvDyZFVcO6fRHVlPiD6h1dmqMRRj
Loau8+YY2yNdjLDQHNTuUprFvqDjqFXuo1w3X2TjMLQ2yhHlCIXG2doCFuOYwBiOC3eIrwFPUZku
lkX+gXxGMEsqavuJnyJ1fEZ+SzavnInDYeWC+B1+a/udtOjlksqaLt8s8DQTnD/Yc6J2fGEx21r6
phrW7VDTGE6VgUr658Ro22NnfZqyWyxs7AAOwh5l3ukU7FBOFOoRV4HxAFjEiMXC+IrCVYBbGq9S
2DnNREtHg/8AyIENNIhrYGlTWwO4s4tt355gIJSbgHKLLlQDRJxB8bPu7qVEXxa8xJ9rPnYNFpLW
EVg5Ew6HcBumqvUuGql9RGidajpTQK6YzCUbEsYtJcsJtNRhlv48vuM2ul9f5EKgVD4qPS5VHgmj
QD1Cprglg6yJYxSXLDH2SlVRA8L5lBsAsQPFRIznu4h9ZIYtAMJR3Hn4mbiq8wJ6qV4letUZRKoc
0bjj4Pt7+o6bQfpHW9jdqge+Zpyqre8ggNBtQ08RSesSxrdKuCFd79wVfB/UU8zjUYo4m6fZtqmc
tvjWpbf8xuTjxHY6/FXWQ+xeRUQEKO3CGERn/ZwmS/zG0e6IB5NVFFqTyd0jMWDWSofKm5YZ4DGd
6Sk6gQCLd1XM1KFfmXPdL5h47sB33c48KD9RoODqW2CYO48d4jHq7lZas6+INywTdXfM5feuxdhR
1FCcagDWoM04s5mEJvYNttpNlTZVq9R7WtuzUv8AEOYRw/UAfLQ9VDZRqxruJzC8aMr5nJSGxlTd
ZGULN8QKTgKgbOKuZpBjUSgUlK1LdhhRQID234gQnTNU01s7+ohbzAJgt51N4g8XDDRXNlp5+B3k
tArcIBVR3CAOM2JwvKo/dfNy2RpRGAhNr18Spod7HLHli74jGleEIMW8vqJ2wriCzBmV1EnwoemO
Y68LV/EuzlaPzsMWDgBznMfSrcvyYOoF74uPqbnwM5l6KFm2+P8Akc6kaPctwQAOarZSkFJ6EsYd
U1yLHiGW4K/3BSootVO/EolFtviIJnLScvmB0TDRfErHtm+P+SlhVdXGcRRLXHpj4hyHMwY5LGot
d8/Mrm0bzdSoi06+v8j3rtPmGuRbfxCoFOyLoZ3wDC/qv4gXQptv8QnNrK/EMcyI8XK1IE5g9COk
7yNWt/5iO1Ee4uldxvcuGRpe6hDQDvyx68OfqGCjeC4e01R1LgKV39bB7EbX8VEo22laNwYFib6S
HbCuC+ZnQ4nbtsQr1zvWRIIGN5mQgl58/wCxqoVWuSIrwBfLf3AhlBNHupkfFnLuK+4SL4jm9V5H
EWIvAHn5irAKPPB/ko4ebS7JRHo2O4CoaJNe2CNAufAqHRMBvkqFjshagZbGwPMoYeceBKiCbS2Y
j6lmo8apjySRV5Ju4nZ3Qf5DF0BFxpc3qCDq4szpNgtFQeGVBFh1UsbIqHMU6GS/dT2hnRfTOMEs
DN5lo980rwRiTlc/xBePDGsYl0rbL0iCoQa+Iufc6uKVZvb+Y5XFaemEwnm8AtzFr72dTRU+WG+8
gfQuduYtQqbDL7lkzS8t8S4ND7DfiFsTDRQxLQvCNztds6e5vHg7KnFwbkVE49xRih0SumW+tLXl
ohnwKW7t1cy2WhvwMdzvMjbgitS2lOxGMRDzWRwmGCm4eMDTB25LEOz9iVfhcnbMmnDUJuvPzHIV
Di+TEO+YbqWYv4mnnSeD3+YSYlPCe5SkRvkvl36jAIe8pyhD6r8xTrNto+oc1E+xG1wHlhABiKsv
RlZVTHxOQgpIq1un5iSzMQH3CdqxkHdjOA2qoBpObbKZRdhXqPryioFeeYBSYq16gtev4lrpveJa
0qLSrmnwbBDTOqjSyqOZ7H8RVa76JYWw/qUJybyOGQCcx7Lj9Rgjygr8wI0L8kr3p+teJowyHLKj
+oAlzVyqgIld4wsU70N1KNAXvFkcKa4QNlBxzmDU21wRIqUPUVBW0RYrXPEGBBatwouXDa9IRLim
HjYderk4nCpdwm6x4gRVV5ibUuuYHQgUNuLsWyFCmQyH8wFNZr28SzfvxMal+oluqRqwCqFPEKwL
DhspYLWEukHS+B6gORD6SyYHQx8SnXULACAzbzmBMUl01AT1ZXsuLhSscdTnAVxKNoaPG5EgUpru
VHuJOJU6UavqXNw6DGPyR0DS05ekW9RQ3acRlFa2sCgpyECYUVfmHaNFXxKpbHuDy2tVLsAAtlmA
CBSW0C4QC0ttJeAr4SEl7R5YOiC6cku0qXBZzL4QsncKCoT3TeNPiaoA4XE1ZWc8TmZnSMO1AFZL
nReLnRlrmAr/AINIaFXjmBDY0tglZDdjzBdCq1gzxMq4ynTzEV4HuUEB3D7QrUfk0cURSOBVg6eg
3YiZvLIeD47hkIqL2itS5jGAAeZmI8LcqPDyAw+nyDK65t2BQQUbzPtZuQuWDaISAfEBRBwYRyPT
HItHfBCgJRt91GagcbUCBVLOVLCwdsQAvjIZJNNMqzErfMTYzm1FxqLy5Z/V/cRsCk9QdwF9ZMuD
PTYyBVFysiltah8NeXo9Qc1weLFymR1rSsdZLtCabq3CRRinlhhbGweZepwjhqYjuReIRCW06SqY
B3C2mJKxGqWPuYKtJwyXG43/AGQaEbQtfiAqsN3ySrrgMZH7yGqreI7dg27ZFQms6qWtgTI6oL6h
muTqNiKcazxLy4Fp6+YvABImE4f3RmE9PkF8kCaNjW5fkBlpVyLfK3zCmmEqG/mM6JSzl+YUcNqD
xKpwUQD6TsyucYBfcIJsDV55uVLYpFBuurgvqUQ3UOBs/wCQfEcCdpiYF5G7+I05s1uxlVd3V6VM
klgg2WG6ZXZsZVYbeioMiWFo/M0cF8BNeCQfS9xjb8NjyeZ4Poc2XcCTaqjDNlgnEqo6OOva1zK3
JQXew0o1mlyGHT0LHgYJVWmsVLZdRtnZB0y0WU2WQkDkMehBXrylWFSpQrDnysXhQotqu4HTNHg+
IlGwux8oSK3POV+YqsfjlHQV3exwR4T3QQPuFcY1HaBBPULISVlg+JultUBfUIFRQeZog4v9RUau
GbY5i7a6gB59y1tsfi7i3IRqycCjpsPkAB0euIPsYtU2lebeVxUAkGi9w5JQFVQ8QwRb7g24SuUH
B6jRdKGX3LEnDDi4MtkKVb5gD5pRXz5lQN+E/PMeDxqlN+cgpjKw/WzuDVjv4Y7BPAW26+IVKBdR
9Ajrr9vP52NiVRTQ9kQlatq6MQkqhQoHFS9pXjV/UTmxtG68B1BokreQd/MOXcCIBfU3bRo5eY3o
LBd7bKdAFalH8Tg7hOCwTide2qcGL11Hxk1J5AyMqAKORXzB/OVuKbJa5R9mSgp6hfMvHQsOJcZs
ptUpdwyx5dXsfxoq7Vf5L7UOsA+ZwGnOVmUChXfyncVComigM7mLBT0P9x3IvA3S8Q+wKAqa9MUg
cKwVuwLSDAvsiq6teY14depaj4MLVbI2ekVBAiOQLKGg+5b5lWtJXUxH2WWUMr9QO/1IbqaS78Li
ttojgjhgkqWJwhNgAHIY5Z5DaYbBWC7vmCyxA6wRyzqosETAJTTdnqNo/wB5X6jModQ/eNJNUWu5
bxyEoIDEBTZxKMfHsrxFFY3kqKC0fErorKhaLxFNm4WvERVuSxWFpRqFe0dUOSj3GzoPcZz/AIlb
yr52FL4WOWoQXzKiKTs2sTIhhd2BmhGnzFDb4bNRMpRPhilwFgbjQdOLq5sCaCwvr1EzIW2VYoqy
5XLQAVblORBSw/iFoo2rgubDFEV53APP6ggVXbMFSG8KXL4s51OtpSvEuxvNL14lYzwu8m8U8PEC
G9jGKogPhhoHhQppMxYK/EcKtuwRZqydf+E4EGmpU0Nde8Iaj4u0u7uko+RtwvueYMlwIHHPuWZX
5NEqoUWBwPEuIV0Cg/EczJyMtXL0cj9LkstQTzXcsghvyhk6qpCQa6RVDdwurebyGiLMcfzEnhzG
LDsNsxLrOGlwE1dUbjxv4o3DEXrhZvr3FLcx7cmmRbvLz8PP74jQY8qMqs4MIb4fXII9gZgwKBtx
u4ECGcMQUCi8iFN3+UamWaELcRVYrGz5yEmVHi8wUNVpkuaW7uGpVsK8MqXZgUZVqTTY8S6tFlOI
GL5QjHpVNo3LanzRyGvGs8nhgFMGIkGtfGoleRZd76gRGOjsWv8AikVHd7u08Qqj/BX3CQR4XSRg
GH55ndGd7UoIvtLNHSVXH7luZtOZclY1wp6JbxVropIJh9HjBj2ps/3hMHkFxIKDYSxDSgTR8Rix
HS5bR5icwmOXbyfzOrZad/cpa+7o/GwC9wo9+4SKpen8phFFaInzM3Q6HIxVq/cTdCr8xRpqRChX
CynZDdrPqNVqOV1BYpNgaYwFzt0PE6gpzbJtWm+YgBWmldnRHuS3xEMsuLe4rWh34Q7qpr1fELk9
eCS/oWrc/EE8JEqEXe3/AMwcErB4gcW8W1+IZ0iktQBQXPmU4Dli76yURLaWCXpNyu2Bx+A/Ny2F
NDo8cRNX+tphCBWnZSDRdNC0Qbyf5iNxerIeaaXZafxKody3tIEkfIeT5IL9UCyEigzEJNCEHplO
XyQhp7pY3jYi6n3AYp/aXIKcG/FQBY61waKXSUkdAU4Vl/ECBbGxMqFJ1Ag5utNXFiq7mnZcI4jM
fUSFuunJbAcgjgpHIflOJEwMT1AANHuUDSL7l49ytkPS4+YPXoWgv1HyI029g5Y5iyHUHN8D3KaO
1oY0veFsb8ToBDevm5UqejkI7J+BTzAiew0yzyCwG79xcClDQRyTVVymkAcVhDTl56T2vqdkd7C7
qOjuRsTQRg9RAmfAKlkQY/8AmxWrZ218L5g5BUvAg+4G80ldBeIp5i1bqruDSXlLGCeuNXPp8Ro9
WoRuFhHFWu/qM3pt3wXrJMFjxcvQ9AGqap66FfcLCHZo4eYSE/lgUxFFjfOwRGsX/wAEcAa63ZAh
IoqzXzkRstNwSiSrUUu5uo73xmfEtoQQbh9SBzfMXxCh0eO4Yq8gX9JX5twBriNxoYP4YetjLN2K
TQlRuKw3geksthTmX1q3zDdYjzUoLF1FOsW648xDo19Q5/P/AOEoaC/iKLejSoEMG35mhAt1saOh
tVxLrCS5An6qiZuIBAlq7cs0UBb3jl1hCSk0AL9pd3qmjFgS7gkF2wrLJY3/AAYFqc6qy/MTw7yJ
sgdUkDL3ENHTaPA8zBYVi7yMxDwwwS4zZWdepZHiLwKhuFHkilA/Mob3UNW8Ig+ZZYwaUqFF2TOB
kMMLYSLMCeJQG1nhByD0psbImtK/ce0O4NeslbIarIjsqCeRqwjOjseYAzdnCCa1tUupR9g5vIy8
AeC4iezc5iOKzINDDaHf+wEJwFsV4BhZMojo5nFYeCoigfYjqjEJQv8ASM8T0u5Xk1HaA5wOaqEk
3pwfMz58SB/ER0UigpbwOJppFtnERtCbhFFnIiqI2lQtzY4DxSWEC26TKgkryQh+o6pGGAbQxG0C
0B3LIbI0Ydy2pAziX8z6JqNolSqun2TudFFIK8lrtbF4Qu3bam8Jz0htId0n5gcGrBqqiRK3hSJa
ody+dRSolvUQvwvOW+ywt6eiLABquI4oO1Blkb4XXkg2sOGqag7QuUFzbp0oc7sYyBqLuWXAeOEG
AVgsONlerErX8xwDWZBQR65hKuWodSgUg4gWf2K4QQQbQx2HxHA1YVQzjIYo5eXLZu4hd9p1dcBU
S2sWAncCCgwWh4IpAxWkQlSPDuJgUpOF8woxQAMCZF0WieQFfZcUaaW1RuK7my2KnqrRyeIAZRCq
s+SLG2Ng6grkgza8ShgB49JnStPCIEzNl23DFgAi4uQlwpxpINPcpBgG0lrWJxDC/wB9XnxFosrW
K8KFuSyeQergZUNll1mTAKBYKp3EvC5zgvctgcQWLM5l1S3GEqXm6gwArMgkd3JyiC60Um0gIRW8
QbLhNjv8QfWQnbd5K1aAFKiHLFcYw2NS44Qi6g2JQQoc0YzWjml3MxdCCPgFHLKlXBwPaCefTXK4
3MUeHUehKcEvlepnFQXqikYRSUQoWM1oeADAkiRtK/cS3BFi6lggWHxxEbt0sGvqVNgAC1qH6Vxa
3gJVOhK2HnqURsLpVRmntdYF2q3L1MbwPQw5jVxJ6hMoDhyiQy2cBKZkFk3zB7gADn/zFuQH/CUD
0rQCozcUtLryyWK+oZBfVURWncFMvv4eETsorT4i4F03IwmxB4UnfsiYMKVxksgHgKgCA9HyHMri
pqhLhDEMHev1E0PEgQBbHSK4QWfvEf5FPijTOEoC+mTLAqK7OZk2fAfJC86FHJYtUAaKtvj4iWgC
FIREdCAEOKYL4Lk1o9UXL3ZzOoGos/c3dp7G9QS5FDpB16lnMogseNgLVUBjcrCsmZriUUwSpqrx
nT3SBU+ZfIFCVp+4YXX8B1FJ+0hzAOihVqeblxWgWKS7rRYs2llQgaAKJNM0bxNw2Ncu2RIEeIbP
cUCArFFnomCQIKqqCBWo49ELJUDL+X4nfhUuRKzMUVYupj51DRl2Ut1XARLvTfQRn2VbKHnuBwhV
R6VKbzlkUFS2Y/M8kXoHVtF5f+R6BpGi6ikDCBYPCx0u1Bit/mFMuUB9AgGKPUUcE6H3jmGpqHap
eyMtCx38VA4gPIBeK8xBARZp7mgvbYRIisqBUBjHQDDmDgwuEXXzEsBXtl//ABE4Fh6ZS9yeCXTE
u9MIhVPiNXQ1y9QL9JqqJQVdPMAOYUeASDREKMrOZZ98yLr3XMWl1B5HHEMIQVkO5dc6ioeC/Nyn
KwleXzAUHfwjUjXJ1sqaORUzlGoVYldI6qZxplHi5Vo0NWMM/opXMvUp8StD5Sdp8wxsWH7j4Gwa
Vdk4W0evE3dVCxdRIviboWZfPJ6gON1TDvKOwISMPBgCdLVK7qVRdNyvuDXmP6XxrAOqBDdlwpRU
0d1srER5yMLGmiOWlBFOEZa6nxkZwLB9TrkOQj3Ck8KvmKE9LbM4iMA3lcI4jAsutgUByqAyF0/m
Zc3RjUWuY5BFhJlDn1KlMWXcJWYa6iAClOe4xAUMCoaOFwllFp6gxVXuGQqnSpRpQaf8lIYc8cSk
CBhcNjZCLxUniGcU8xYgbZ5ikgBXdFxRQIp9ynr2Pi4GApUhmMDykuWaFE5o/jkJfajVnqApApai
1Kd9dyr4KveQ+UCL8TFyQ8eoKs38wNa04jCAtcgd5usRA19wWUVHw/8AqgbQ6hxUCEA1CtRhzmMw
AIBGmEswqtBTyBRD44clTSVcFNjUFDwkeTBglYCuLRvqviVQDrOELtA7VK7LQXUtqavrxLmmhbcr
DoXhFFNdo2PHfENjzVCOghMa6idKUcSvYvQWAQ29dwREbgl0CbvqFbbsxUNFuS0g/Udy5ajcVV2E
6GuFTiHYKr9QF2S+IopG4cQlgXT1DrXvxAJIKgP1HAuqyK2XNEUAXd7GTA0TmPUHRJbBBpqo2QSw
EAGs37meQW33ka26AMo98S3AdhdEQCd33CUoL+JQ2F4JeOLeYaJwDQiI7ZBywK3MW7jmm3m/ESC5
Y5eZchwTvJ4yhTkg7LVMIIFCFde/3AYDYRsyFFZXEUVOZT1HS1KWc8VM8miknMGHj1ByLBcfmKZW
6Gt8RYqj3tsHpYVWGcktfcCCCaxD2/5A8hWTX3PzRWHj9S3CSKrq5QbaFXEHARFca5gCFGoOVLhG
UrFdv/2GDek8RdqAXkqIshAEspz53CltSvS6h2obj5jBKQfcxTQ7ScN9Q1pk/CC2y1ocZCYUAGWy
nVDactBAjeKa48QMdAKvDf3F1tu11sPRCXR8Esc0B6r/AORo2Q4bbqsL48z5L4/UIQvlOy6gSUsV
pL4qGNbS+a5hKAtZYHYTgUVlT+ZOA5IGRyq11xX4gKHs0EcSqemJSgCILgAAK6IOaAC0ncDaVpG0
htIHsNJA20LlaAPlfiX1hQ1XpE5cWeWwh3KWT5bjSHbE71gmK7g4yKob6ttRAfYKyAeitH8whL7S
ilhaCAa1XMMwKt/K5eS8ww1ggyYPxEMaOw03/sQHgsHWoZ72rhcwiKYI5aX1A7QVWhW4Oy61j0/5
LqRq7nEs0As4+YvQPUWLqL8bTSMbC0PFQiUz5TrIKosYfSELpqjvI3SvqBZhjbQH0QFqKehxfmBU
Ld4pIBghPB4cwOIqf3sp1X18n/rmBCMbS4PxcGhqlT1kNHgFv52VgACLb3vzL3Ad8eLIkaiIpvIm
DpaGVUcUY0h4dPG1viM5diADi31A97ghFWU3Fs8c33KAIHt7hUlqvM9eStDiVXWiUA0e5wVpuWIt
OZ6SWAIHsibA6F5Y2UItczQ0vG9lBp7XGjOVZEnM1sAUEWD7JQZYkJCLiyD+ZqEAQaSuGX/Ti3LA
qSwium04Wribbc77jqFLoIinBy+rgaNVsCMq9azDytp9VLHy274mDcSVwcxx9LSu4DpWiMa3ZBdE
qIBTkOgRe4Da8xpqv1FBsAiZ5GNBragAi2qFG8y5Eh4BRPAXGwEAd7X+xYFBAMClpNEdw09kY+rK
HzGCpbC5YbJ7mPNYH4jlVLqXAayziXKOKUHgyNBAGk+Jebw75bLmuIemArYo2A9onTxkuwCiFz2M
Wor2OJQWINQHiBaEdYDmoFDBgUzoDEBsIIUYEDX4hv47clA/JGjSm7DwtzqBE0pq4lOVQkZy1+Zb
1R6viI9NaL3sCzDWZUqAtUV3GJtcvirnBnUDn8y4MPcFqLU4Kxnw6hKSOi6vJlcenvYkgA4Sr6F8
Q8rQ6lGAy+zEvIPweYugqozG3P1DTUdEAKD6REnHuMGAipZ1CpTKzZrY93TH1rduXJ9jXTGKL9sO
O2Ecr+iARRM78xA8zn1RjCeV/uMunMsvBAiXAKlc4AQglImzCGNQgm0kv0NqUeBUvdqFrhhcHXn1
FWn2hsgf42CitmCWuF07D/EW/cCA43ZXY6bqC0DRf5hADh/xOJbCxoAua0Fn5hDYO4w3arAiMiu/
mcVg3s+ylJmNaRCGhWL8w1fJ5hDcl181OUnYRauCSiJ1xCzTRV57gSqBwPiKqkt7RZwpY+2ItYl/
iKMDXyoa6itgpDy2ZKuA4fCPOkS/mEZUl1gncpat1EEcg3fuZYtuVDUChKC+pVFzm+4QkUrT5jTB
hSEJC86+CHg77xbaEHkuc00l0xI6Uq7+IYRCyV7j/d36gVu6fqUduq3ruKoaAfxFqdfzMt4IJus5
h1AQV/NRh6vf7YQ6e097D5GrTgaYr+hWoE7xT+YcAUARMcH6sJTUnOb8QBDwPlSdBDf2ETYjScsq
cpcXitjmT8DiNVyDeDYgRaNV3jB5DljpuNFkr7iNpqsveI52KXPJv6gsw2g/BD8ooEfiGmEHgMIP
ybceyrlkXcF/E5AL18ZcpeyA8tJUgHd+Yxk6n0wNYTDyjhWWbzKZuSyeIOxG6rr62KLAPB/SCI+z
mAQHiME8XKUhUL3Ebi1OsIGhJsEq2LMUV9yvZVJsM5skCrV8xES2ldy7TwWPuGOKhJ1qkflXE2A7
uXAFC21bHUtDr3RZEFyO9qxAurh9x+ELUA86xknZmG+2D5QNePP9y0SGeeIUsSC+2PpsAu69xY2c
N87EetRA5dZHCFgOdgzAEFrjUIukB8k6H9zkPmFzjejKY9N0n7QZOicKdx5YrFwGUQaDBovx9tYQ
l9ifNwIYSy+IOmqUe2uYDbLpVRwyLbARPkISCAVXrzEjU+Jr59RoDhpVYtVDa0r/ADH9LtAvaWoR
+IDVJ19Sgzt+DPMYhHEDzV3LyUUaotA+ZwkFLRfX/Ij4FIsvxfHUd0sR0cV/EFH5V8AlxACXg6IS
Ly7W6JLQ3EbStiGYqn1XENQ+h+5V2T4Y3BoYDXxDC0G+mFFjRFV1uWi+SX8Jgm1Yx6Jp25uB6MeW
FN4nOI35cQLRG24hoadx6wYWWOK76bIQzagxHcEDqETqKqh76jZoiqRt1QAXCEfK/wBQ3exPFSio
rA8QeSBgfE4iBF+opebLzKJo2D39CVCieFV8QcwKiDCXWqWQXZ+okW59xBe3fSRRAKfMLu3A0K0g
EeHqHdqZLsviUpZcdCP1GDeRtiuOYdqSU5Bb/sZIq5DO8o9Rq0CX45g1g5jCpC3HBOdXi4k6jN9k
LaVbt8QKdtb4YxHRTb3c0PZcTmtqFzE/nNxnvAdGw9Y1y/EZ6Hbljnqo0Wdx3EsNesUFkwESlZab
wgM8dMsjWDxKya7IJqxF6ltgLtNgio14iOwO/eRFzX1LdZs4IuRXKDykPMFiGWBCybOrDiUpq2iF
Jo15FxsABrI5ub2Q+RUY9XtzTOQu+o8FbvidgeQS1IbjUe+JTcVkq6svAMfYtVfWQ39OX8w880/3
PnLYIr9VbDyyg75h2rsWXpMPEcDaPLn/AGA4DYuPUJeC3UMkU7CQ4oZvGn9x+WK7QSjqK97HUa3m
/EuA44RVvVAJngOKlzVKgMWuHhyFuL01QQWxWQsJTSkoiqGaLWiHsbyIZahbYTZkyoOA5ctCGAPE
pGY2VyfBvMXuD3OSDse415fPzG4rOUNrVMp4lhlb8xAXXpmJ+SENIIOM66QH+QWfLmXZD+r5je4v
MZb19S+EK2v9yo2rBb7gsqAJD1KXmy6bCi3uVkBLx6qZ/bOxCYPHeRWUtSl/ZMtMT1cNhW0c5Dbg
rh5ruNqbUty15IYiLGlqUlEtH9TAQsD1BSNeqpqE6oXGxyIRSzAF8HfUbzNnKIDqEEpv0/MFoKAX
ywmspnuOSrVrxcppqhu/cwMnVPqNNRZ9oik2kP4ndOmsvl20tsADdwvmblNL8Ftp+Yp9FKPphp7u
pOvqWUULcmWpGvP/AIjC21HRCtBKXWhUsTYk8Bv8RfKOxauNfKd0ELYuweSAttOfiVRGK/D38RzA
sA1+4sN2g85zLFihMxX9yn9UZKusbuLz+5ZnSGX6WCtIIG34j2RiPC495A9niAnwF1lO/iK51WUF
4gq+UDRz+pWvca2O9S9y18OYiGtVbbySkg0I3mbTsb1fz6h2ShFlLm+YANjznEvvER6bZcwWnFsC
hXiCg4rIwg8HAIHtSDyh/wAjABEoEf8AsdkTWorMvHIhbg5p2GxNrKQsN5lW0W+pOt25DbZvz0tj
TiHV4moL5WK5uZhQ8E+ZxRXmoddtT03YKrgiwQrrxKckVeUf7DeJgdke2LdPKmfxKTDg8H/sI7QV
I3nDzEJKUWg1x9RGQlmNPcSTzbWq6IH7xkF07ZwnZkWddQBbgUFTqJ6KjApf8IlC08IwiLAaNuXl
9ykA1sJxx7mXGqSkc/ESwViWtPc6j30z7YFAUWnXn4gVbgu9E/ErHgS5aimxV0Kb8eITMtIrTLSd
RtSB4GVgoRMa45jV0FToHPZzEs3jWL53uJAdpSlZz3/iW0qpjA8C7AqG8paOlRLHB0W5eZSS8GCn
nuCOADwDlNdSsJA42v2w+CUsFtbRDDCgjT7Yw9rdl1ashGgQinVNyiArCBblV7hfJRPBqjrPzAoe
TK6eWD8b7ZdJJyFpgkhfxHlUepYrR9SvCBQtejv1KBoOcjqgadEUtd6uElaOqlgI1mRFbkr5Krwl
8KlrSN+/UOOIWwN/ES1FAew5gJLsrsQWwspZd1D3nFwa08gxI14P7gLQu6eZfvBpWMixdXzcVjX9
IZDavjeYDiQuNK7g8tJ4M7CSvuMTyPUorXExY0yw30w5DDjZRVPpASUHZdqopmXiII8XF7eQDWcb
ECtKXfiCoKGHhUShJwvUqOtpHiBHpXZD0R2ruA9NFSgXiHZuXYART1Dl2ShuCxlqeLghfSC11Fun
gJWrZ1AOQGaN1xCyS1FSoOdluStD7leU5R4g95RR4ggRL4Jais0WKsQS22DVoUeo3v4vniB6JQO2
TLP3zObqqx9wPWPEt1SeE5/FXeoQiU1viJXIu8GCYItbyGKbnq4NgX0IpDBAP/dxgyXBwmxyFm7x
Avo50gUgO3m5WJwN6ISmJwYy2sr03AJbQcCPXnBAxEMKbM5I6twLctSg0dLaFS8RQorYsiqypR5K
48QCMRy4pFLuWA6S8x8mPSIXPshcVpZi4F8HYqHQJtqy5TAbpI+1PCHZaby0eC5yHlvacC1dm1Ny
eydk1DKOdY/qOVoligcUw1lbptmQst3iD/VcWQgAi52WYk4KXZSaQatMpTi67F4KFkLUA5HiFsqc
sDveQ9eSMbi6Md6dNMXNZVuEvIwm+gqICBwOK+YTRUN3/wAZjpRQ7AyeNt4YzF3AYwopXYiGhZTA
18XAEyxYsbGBXAV4jQNvURX1L1jSPT9TfQAUVHWAouR4AsRfgTg3fZCaoUlEQ8YAVlsotSNh6g3T
s05zicmMpAUzNGJeo64eKVfh3iBK80iGfMGi+AVsVz7G+PUW0LKNWrg57rR09TNEh3miG1zw1keT
Zdtc8RGgKH0MMnWmyfiP4XDr8Sj+oUFrmDy6FlfcDnxCFMW5Fj1MMjgOPylgAkTbrLlnAKHw8RQs
i2ulyoWaWFvLmWDGxT3Fy1oDr7jkPh0r7uE7uxVX0QRUSt4OyVVlC6oOTZYGHAP5JaCuKpzeNzFS
8svMEBtUIVzI1OuptoPTFZCp8h2Q8RIwh2olAcKGw9ygLcQA/JjtLhVgUrniHotRFtdZEiFaVx7h
3pYFAUoY4bkea38Rk2G2LfM7WoDaZj54gq46WUKrs8zlQGjAJ0/j4iMLCou8YkFCf2ZexN6GnzEe
MG8ONrK7lCSboJ9QVYNtv9wSyktnpURBtINT2viIkbG2Pio/HSlYr3OZgD5/VWxh3T7IU8y7XG98
QSsTYEL4mc0vJ7wXI+IGYXfmdQma2nClZZsnYXfzBsNegKO8OYHDrnmiEWwD6PmLnsE8LCHTeYxD
fWVtqXGGoNBY+rm+0IOl+Kjp3D4X9TNiQRogQy7tkV/kuL4Kw+qmjIOLsfZLixa4B/uDhEvgF38x
UrsfmF/+i2V3GwBvrYKNeVvI6UTlX2laaZxQ4LgsF3ZYRqaSxDT3Cpxtap7P9lgoLdat+e4x6H31
GDJsXt/5KiVqz14uONxAFK+omUTWpEbn5CnzLOsUrK/MFDCcMP1zYKvY9xIPKgoXGaKnFpTg1FKo
UABpZ8jEFja8bHzOIJ3zlHnBuz8RDnte19ywCLS2IqrXlV/HiABg5XIYDyC2CX+4oUF+CEvQFbB4
TxGNC5Zw8XCsaCMqAoTuZCksbih8fMAoNgIAZsE1ZbPmSkGC55WFFL8xL60ql/SdBYvxKXeRfuWC
i73LeFdfcrUBb3AaBWTPwjGOke6/yJ0VDRdTcT7SlRsqeUshUk8G5WG0wL2R6z3eJZj+Blvcudph
osYEUo8molKWjW/cTCg3brHltNbWfcLLvePNe9i2NfMYoe2NVEZajLWM01WzgL+EFj+4Yd2CoK5U
JqNkSO3iWCPsge+P3HVDAO2viCdnYN2xcvk8E+Jrq5edV2K/uWFn0KP3AFoPMyU3s5Y1s3lEhVRD
r4nEmBXfzGGZzgx4SXnn+oV8/C4MKJUxGR11tytmRi0Bw6RXuvnbltuOHO4HWPl1HDB2q/qXaIba
hIsFHNO5UC3Ao4hgg7DhPYjDLg2i1xSyyALhpo9wquV5sYpc8ndymfVBLKcIbTWMmy23LK1aQv4m
FB4suPImvXFQtbbZ8wY8QUb9tbRQQNLm5UPSHA8fMfHWHkjgULohFtlC4OPRbSWvucnzzsWITbvC
4cRhotMSorpYgOxWgHEMwi+hIgCTkYfssKg60iw9t04ZSh2nJD28QCCPB4YVRTEMeYa9yFiWQpHZ
HQIOehGilwF/RBCUG33DIwaoLPmGfwOMs+9yu4aZug5FCo4XF+LNGQK71qLcLKppYt/cMu8rPME1
jwZXxOItP4lPXcIJ+oEsiXit0BdRulsVFw1d5jRQAD/csMPq/wDNRum2sJLXnqbClMYUhD47l0Ib
q2ym62USzwlsoZPWlYJXq8thbR2XYsRUw0U1MFPWxYEUhqLGoLODlbvxGJC6W2/m4gfWJZctmVGg
vmB6xdjn+xCUp2KIP2tWI36jgMUKN/WxSMjQH7fMEPOLKfpiFym2P8xd1izc2HHCymcBVrR/cENh
yrT3ssncopzK5KpzUDdUCKeOIGWLCb+IRp3avv7nLc4l77nWvKJgK6Co/wDZ+j22Qi1w72XfxgFM
h8E7WM+Yaze4NaT0Qu/cfIQdanKSNtF+ZYTdVVxsL1aKONQ4xx1EPmita2J1ntNv5lwSFgpEoXVS
QrocQ8VekLUh4Tohe9F6DAMo1YB1PwiRkA6VcZsJZmMblnpUEBi2UV5liKPC5lA8YUPxLSGyBwY8
cY7cHTn4gohaNVppJJlXkCOVqcQhBW5gSzv7BAyeDwl7HjBty+jb+eY1wm6CLBNN4UrXOqg+JHp5
gda6PfiVJRi+cUgY8WB1xbLMRFI/zETMQLbEafBONuPnbLWm0ruDDFAV+E5YXfUI+qnSPIznyJNC
4nYJmfUocdrTTy5Naadku11pWWwoJehFR+U6hjhBLar6iBzcKvlYocQKynlUpESwlh7yDVUrxjL+
fNZt9jzAo8ii9zqWBgABUfn6j4UGc/8A5HQeKVG/NVxB9ppc1rjGUQCrhCylg5ZpSBdV9xfUyh6G
y9dajmnm4SBFWqx37llDsHn5t6m6gqz3ATm/0SdqAJpD0xr6D2HH1M6wVaxemKAFWoMv1g/ZJWWr
C8rucNtJRY/cUClgAFDzLojUlFjKB5Kjt1CiIAoOizqLSj5Id6iIpX8eYuEHEwT6iMdSfS39wNbC
+WNRviwNxmJL10S31MepINe5krGbcA88kcWAEDZjzGs+B0qPDnFks1UcUXhgXKgUFUy6r8YBO/MG
GP8A+BBgrn3APLkieY3ozuoAL5ddzBha4eGDSLwAw5ILd+JvkAT7ja5pxGDAERLN8QmpajayapIs
ErjK6KWJkLGHI9Sg3B4g+WfSFoBohKlUnBD3pIAyrjT4lFO6gHw9mAXpAVEBnLl741nCVZ6eypWe
GVDqvcw5zwTwaSrKAsuNnFbBdPUsX8TKnIR1uow2wdRvRRLAzQPHmBXOSt1PBSCAj+echkHwCiGP
uW5QOXpANC2hwI53yFsGzJ1Fj39Siw+JsKiNBDuE+ENeUoFbeCorwtKNZKoI0C271BozNHuAVVFE
GG3V1ZKEmEdopHhlEMLUxLuEFFBE/lDoXDxHKsN0EHaw0CDq0KLtLBNchwcHg0hK2QCyqRj1e1XF
zYUBphsO8ULvEo9t4Kgp1g1sQrcVb1i+AvCuEctUXlgq54hyg6PxVLLyFDhDbRrp/EwqA1Jm1oyE
GDQw1SWsHgufULQjo2c+6F8/xHnSqnhBXxRchq2OVUX7IBTsKzDDLj+UpeSqlYLp4I6tq3UJdlnU
NrbBtvdwUgowIpNwoKIAHAfLukswDTa9RSWd1WEz7gJu83qDZMVxGpGiQR19JTMmvmuKyDAF+pdx
PLF0gOBTiNKQl2EXJj2qVOD35nsKJ0i+ArgCG1iyvEoWoO0tuBWg7rkjZCFBkSLNlqo4RXyyPBdo
KbLFerhVkEqvsuUwxYSEeVAGEWrFVRsuJMyWTlcmJCaFuBIJeHanUu1riwgUtfVM33RPxAvNqNaR
Lg1GzuJok3AkoRpRR+5ivUX3zKDhLDjI9F1zO4IXCGQQtO1LMYixNeKlkVtfkzPFppBWOnOvuGka
UB1HaoUuLTF+4f4j8vMLyALAF0TSRo0Sz0Rnuzkl37goiVXR1ElAdCPtlRwN4lZAHtL8QrENjq6G
Nq3XiVcA5guYxK7mIRTQbfIfE21AxyHENcCostGkI5UWgLOZjzgvKhiOgrh4hsYLj1c4NXulEojT
AVBdAHQd4YP/AAUwMlGni8j8RAKrmYdlSwBTRTk6ldsqQIMpLVc3OK1U9obAJHEKhykwKcqUtVo0
MFKWQSjJrGsYl+iWpY2Wbzcy112ckNydlVwEIlSHKziGvy/EQn0+AuJ0Zw8xpryJVvUpCpt59zyG
xIXsSgIeFZUAqhMQF8/ExVVRs+blGzcHAIUDYUMLu/mFhWk7rZxMFU1L2MJF8/xBLXSHoIsgv5lp
bZbxUZjBKi4FMSOeV4huVFDCs6m6CsL4lpb4iwPNeJaL3021fUv2UlOM2PYNYht1j5g5mC0tW6eY
x1e3l3IRooJq8K/2CcJQdVxty3+yOPHMtgTYOdysiJnPkMjq73Ks3EB3aA6wBTLTmakFUpLU7uAD
SlO3YSkQIAISgpeRDGBZ8b7gfoETq5lH5SsrgqVIcgfFUy3944bexnAgUc/FyjiYb3a8wwHiNZ3B
AotvHfuXA0IUtz0RWiVPAgTABsAsusmHqCJv+9itsW+XR7lQ0BK5/wCZLDFm8PAPqNjCl8lpfMsj
npVu9S1pRm31LdGUKaCtIwiW5Q8jIQK4KgrHJuaQF8IYgrW3/wAVC+zQTXH+x1lLuVVDGkYvocNB
1B8ASwwbMQk02tW0z1GFkoutcLX0kGIJOFrVOwq6XHQCkdiI3uAGyzDAiuEJZkAinK7n0g1ZwDzL
Gw+HmEq6arbjayhGYHHV8fMJdgL5CCSacVBeDQeziIdQqDM7IkKvHKL/AHHIxTXHqIo0jSdQ7AmA
VElJT4JxGxRk8epcWmUHUQVNhPQ2Nq2O0BUApWe4JkvwQx80L0y/+ADG7slGvPNaZCZKk3RsvKDU
BoPPE37eCNMGJ+ibBVnmBPwxDDxOS72WaB1AHzBTIBg3Ue3mANIIJeCNkMtqqOcwWEB0RPzgW9QY
O1t7izi7eIVqtFr7VIObaUGIMjoRnFej8y3+mnJYBBiHE3gqeRLWKSGlLtsjHwZhGCqieJgC+iI7
gHUrFKoSD9Di7jbAAZEeVQgwFXzBR5vDuNOGrIRhVmysdTXuJarHBKhR1TEhZjpBDRxQEfBjq/EN
Dau/UyBALKmH6UykAV79QBi118xUFBkpeyxqJzhsuQsGEYKAK2+6jlWh3AAZxRBXYQjZsw0jgK26
DuAKgTxLyFavkmR7CbGphVpiqjoVh2xWKhbRHzllCvxBPqzGe4LsG4Vb7uaT6PtLlGWJHDuhb+Yt
VaNr1KrSKsL/AHL2bUWw4CmeONjAaASvicd1S13FKTZiTaqnDojWJsqX8S0kLSHb4lqad4JF4gRW
MFvm4Ag05gwADUpTBg3aCshKyLeCESnBhBSwac1OlDL4gAL3Fn6gJQsUnVRRTHFy2sXCviH8hYBH
RZXMG3cimDiEh2tSyJWPArLkia2L0R8Ko/jxO0gpGQKTTvYZigsnN/8AyaMlwIDcWjNveWHMOKmx
EkdND1CGsFbzceAm3dZHvAdCeLQhY+YJgpsFR6IG/MxlLlFrcghRM/KMg6EU/Mew+LloYop5K6g0
9DVQV+cqSnJoNkQQUMr3EQdkoFGZdvwf7K7OnPUYFsDT4jVcUF6gS2rt/wC+YxQWh+IRICcsbeZS
pA3xcK4qkDycTD5bVAdfcEAlNeyOhCfkbCwVaPVP/IrjQMUoUamLSqh4gNKSavZ7+IPDReY5BXZ0
PZL5agl++K8QIAsDiiWjDod3EE+9hARFmtyqpXaHSvUvmTF8/wDrjrCTe7Yf3FW35QlRh1qjjGLg
MhWXvZOWQOSJii5VVcWlqeuLeCEAFyPuNQgZccw1Z0HEMCgEqc7EPUNqkhK75SyWuqZcVmZhxkOY
FhflzZG9y20T1dceoJdO9IRoUbfZ3G0gq1TqZvGmNrMqAbFh1E/tzty/UbKhXXqMWg/MVU5AoPmO
g6xToeoDgqtVzmwGRXebO/uUxGU3psgg5J9Id6trK1xkWFEET9p3KoLOCECajT4e/UKruvivV+Jb
sqVY5yg4YgfhoRPbUCht833HzEEOL5nJy5afiCfU8hkPoZAaq7HfKyqzNqWXRItfhF66RZbhXcxu
HDU7hd7PBL5XgfEKDLVApS7/AOxgU2K0rKg5HaOJ8o1mKcPahoqU8If/AGE3NW4wjnYLKrxHdmUD
qoLadKeOoaMVAHF8sU3YXQd+9SUq/wD2S3FsUBXUOpcEX3yrJxTC/B5GCyYVdX9QCZAp68QZC6MN
LgLWpGheiA5SgEKsrmKwM9zvH7hzKVFljX1k7o7Rwa183Ek2DUWWlZAGJ5cuH/Ygjwq9w03HRhtV
Ta4l4bn9TnvYi5OAy/ibi6zCr8XDm9YWnAu6JTgFGykdLDuCCCvMezi8iFBVeY0PDcQU9z3xWAq8
1AZhOdhqgJlkCjdmeT3C3AX2FXKACvj3LDw8wUTT6HEFdCz0lYKUFzmniJzaHbx1C1iQXkiRa71C
KUlj1D2VFb7IcwTQ9zTwQBwY5dA5fqEGA1rseMFXxK2olS+YRjq4fZcGkzD9QmKbSXphVK2qw9ee
5zPcQiID0jAxW2KeIk2JfSDPBkTdLvEBVeNuK63Y6OgZ5lwlPLARwLacwQFATT5ivHDBMVZIjqSn
1BayhinaCmVUqhZ8wjiuuodJtS2h7T5g3nSrlQ5xETEHfGwHQtLX1PEOeYDuQ1COu2/m4UmxVMvW
qAhxPIEKK1Tx6ic6qHMrF+44zwVsSdhtZKYD4MBGLV5Hss5mpMrmXGVxCItfHUy1ZONLGfmHFuuk
xKIsCU1v8xS+ospRVX3Hu04wgsWKw+ZsIbscRpewKlzO0EyTwbMJAa+MjjA0TRvUaKADSS63wxDQ
unSGioCqiCF+iVAFU38zEtgPZC07hD1Dpurddy2kGFbzFGgnR5T/AJFGVZfzCO1+L56m5FqViHRd
yLvQd752WKFou+oPYBD6qMloPwi41gfxGmsoXzGVlOsvA1wZLxgLrqG+bwh0vF6V/wCZyBG0eajz
SAfmIYlBfCHQF6HmMTIOLhtoX/kVBx4eZSYdtNPuIC6KMSKu5z+9JbeC72Wo7ejmHxVw8Dxcwgvw
wDttUqichKBwS8ao2GlI49Sxk0TsnFYxPioshpxbbVQkIpJ9Xkv9g8OMjlLqz8TgEbbEQCLWcXEw
KRyKyOe/UUTnT62PiqoFxfUFVe0yrP8AstO0FbhIdlX7jEn1CqIAS/URq8HlCI0jz+oIAD/WBrHI
GoZLy3LFQQR9YRELf8ksoKS/gmXQUl+Lh7+rD9QX6OP0TEJQvuHCppy+4VvdrzkbD4x49zAA8nog
pBy/mYC6ifO1CezH5CwnBG1/McugVX3DHUDb6Yds4T6ZrPDVebi2Eo/rcdKji/iU5oAq9hi8Uc+Y
2caT9ErxsN/iohuC6GwRqsleyE9HhcAdtRX0M5VhRw3KuVIX/wC9wLFk7Bm20PRhcFyX6hzrpF7y
xK+qhe1ORWw+ZxJiDei5TYWLKqofNVoRVeu4VdWwEr4IxhkRsqKZKeyFLa6He8QAUUWHhdXK23hQ
CuCJ83Sxh6mTJlVPhFPFSrxx9x0lVB4I3NIkvjhGusvXgueDkNs8PqPfQuPhnq2ADd83EseQ5i+0
pvLiUvclONcS17Rwfk8QPVsXy2Pa+yLFrhiK0Xrt5MegK1X3HLy6C15uIPcLsVBArKTbMJfagXaw
S3A1dtl8vJHEoKClWXfEJ7UDt4cSyWXwYae4B4cr2eH/ACLuBpTgZlx+fI5Z0kZLYnqouOK1d2KV
bNhvwr1UCAae/NkJCLUHSjmDHf2xMGYUeCw/xEBCRscpVVAM2m8Q7yPsSiTeKeqlpoNIpeXb5imU
4UG+oQhhFazd9TLiM444jUABRv8AcOsIAsW5Qigmr44YMNKLTGF1wR+P+xF91zCy08dyhi0l8ig8
3bX9EqZNi6PMIOAQFVjX9SpEQieCPHB9bdFqX9yA1kCgz1fOkNo2+ajnE8PZpziWaQVF0xR1+E1V
kp4YF7C85lsAGymJpRJzTqztp4tOZ0PLEKVu7zGLQJXu9W8Gy/4lMaKUeSLGaG6TmU1FLCcV3GqI
OYNMBV3kLcydeLhUZWR9EIqSl38Qm7AVrj/1ym1XbNtAK+rjBsSD6iIFeLmLaKy64OWFlL0/MPgG
zO4BctOCE2m5Yqdy31OSkgActlVHfcLDdephB2UBwVsfIRHISNGy8leuj84EDpDxLthageN9qFho
Ae4JF5EcaDUKUr8o5OOFMWrCqj5m9TxbGjSjSJZbxK/DtZk+sijYg2ll8QXBqNU7BSSnKicQ7nmO
GgrVPMa03Oo1g3exAEqLeJSkrxsctnsg4gHJcKAKMXzLw0fwhEmkKjJGzzLdauXGwTY1K6ydswxz
fMY6vkj2p8o3AKp2CHNrtl5aqkBMjfFwuqONyzVt6jKpWuAs5/0btxqAuUeYH4ecqaePMvixcUy5
nQ5il4Cq8x22DnTDBTFSo8w/Ed7yGyLeVxfZ1UuETXfuUkUYbzGc2yx8a3UxZsg5d9S4trN0ww5k
+IdjBL2e4lFCV6iMaqCAFTYj3Cw+g+odjVj0fEMENGrgRVxaeY/uFFXxHIsrxcCHZ6S9pPQ1DSg3
o+oSkxsPiNCK7WImEBiKlsfaWaTxBhULDghUJ8Dy1Hp0L5ghG1QQnitG/EqcFrWWIEHTBY6XUWA0
tvxDt43RLTadlXvEdwUqj07Zt4LDalGjWkY4cy1W70+4GdCQ5JWKKBHxXM8gCty6j8Zyl8bkJpMV
T6mKxFb3BI03rE3h0ydvbxajYAHy6slnI8x7iYNXZyfEzyYI1ajHCrv8QToNUx5WPqCVy14u5+JB
OYrCyleXCCBTRyutmSdQI4AG+eYYlKfGapKA8uql6moT6v8AUTlCxbH9yrLjbOKIAINV36hCgRU6
XEFRLXt+YPKCoCE8sh46i14lfAd6Y1LcTmtlX6UCmUcTN4T2WefEoQSeC6u2BAdSUucy0ICoWQ2W
d6S+vWRhRRQ5ZTyqgeiWDfvUtVGulonHu4MJYjfORuFRazHu4rqYKUTiWyh4Str/ACNEtjBXXEAQ
irq8MiJ1J5vuXvoEtZz6nQBNre5iOsJr1K+W7FKJeS7dxfbC0GPQ8ksQJCxK6ieplBzhtxgxYaKd
9QwdmKPhjhqhcuPuUFxddRgTmhMYvUFsZVtDSQWomWqBIl8Qqn0FVK8VKGjZzVFIKx+40Lq3xDFS
pqoPuVRWqKuIiQbVPFT49sPYlLQzkHkYuBMg+KjnoovY3xkWqApFbwM1m4a04cPcdWStKiv1CRaC
3KHCKfuU/FbKHkGl3lF85N4zeC31KuDVBVtXz7gAgNqDvzKyy9KHglzNZZjrxC9IhZLaDn8QuCvM
38TQ8QlnqjL9S6FbDkmJ1MS+0RXiHDtRuR7IayltaB5rPcqmBUlIouURYRRXxFVob4XzfiAlIwC4
j3oGafB5Y2hcd6Oyy1tl37NlDSapb1cRKtcwXrUXMAUrjyfMtEergzxUv7UDCoWbUWZVGBQ9NcS2
NuIqHnxHAPGQbxayAjBVRqXSFGLdotuj8QOFXitt1d8wFIqXAK3/AJFlv11h+bitJPIveQh2cKWc
bOplNESFeP4j8d6XiBXJhhCY78xSAH6BG/cxEXkZ6KhMpkHzOx2rW3eeNRUw82MUaWeYQCAq4K05
8QLDt5lijGCLOk9X7iLRsrm5ZpvXiN4NrZcYdxx0d3IwAtNUde4MhBlW1rXhjwxWwy68xbZkb1sp
lwW8v/JZHXDogt5oXeZf++Tww4xnD1BN2d2P1DkxZf5hYUji+INUuDeYEoHyOKIMGIKOhfMoBAte
TtZ1GBDiIVq8uI7bvEIVtSlLVvEPvfiMExqJvGmOtT7l2W5gkWaRaDVPEAWTlUuiIYfZUEHcBqCD
ZZ3H+wgLbqD9xLu0fEIoCFDTClY8ks3JpByono9oFtQ+Fy7iywRN75eaRe1U3YSnCB3CzkAWt3FN
2nF1guzrY9mnImy0FK/zGLXPORQobAcoQTbTcEOajvECh1OAwJTul7OiW0nFs9HuncY4v2WBBcCg
29lClFgcPmNei1Hidi1CUPWm2oiy24S4g2iVZ5i5Ua4DkKKijeQwpYHrY+XAU3zC/VuljKOclBiI
kKDq5mUcZmuE65TAVKpeSNmoC7O3iCvJgrYjpiknbhVRG2gWxFY3F76BZzmFeI7jwbS6JkO1j5ln
yMOowDp9QDgAq0/MUBrQq0G1a6ezAA0ss9zXO2vqMJG+NMq6A0J8xQScCpl/vSh4+4ZceD4LgqIC
3iIjxo9Rvqa1oXAqFVjz8zgbbJTl8qlXEIUcMcJdw6givjbQKy1N7hoZcxh8zsYKrilLdBsExhHn
4iE8L6EXHgA0+WXBSU4eoJcXKKP3CsDwvn1CKginLepYfFFlhEo3VC+PmUjDD5IIMWmy48om7KKm
J7nMts9uYNhShHFaK1ucrLkdXALBA7A7h4A4tDXjmV3soG/UX7Ys8EoQCNpr7gJrOaOfzGLEcFlh
AyC1aH9wT81Nn7hKqKCgkGAzdib9JaABBUpdjR8Ny8mLu12SiBd8MVWtRGdXUTS9y6SVixtcH4j4
Cd3j6gkVAqPlE3hChu5SZuAaMyrFC1d9Mq3mrY+HEZOplv7YyZbBp+MANpTbwfqBWFo4PqP2LcWW
nmPKJkNvYWd2GWeKh34bweqjvCuA1crttRorzdwEGaMp+IXSgVxs7i53gE2EE1eioHg2bwySuwTs
f2e5jygcB8y6l3dE+Yf1BiB/EBaNMzrvIuWzbcB6I7e4G4W0ZyteQ/wKQ8vl2EYsuRc2o+u68HuN
PjaMewlzKem4v/gwF9xyWLDZ8RijO0tX3A/pOQSherkg+4wlD7GeKll/hMDuogVRqUv5qPEbwph9
Qtc7bSfEEZWqC98fLEqUDgA/mEjdx0j2kfiFC5+GxIqnjIFFZ3T4jFCtovm7rYB4cQodJHvQNnhB
ib8QGcxLYNQT5lzWeLYR+qBRyJeEWFlEPU3ohbYfudf/ADVsHuOCtk8nkcD8EvOBNL3fiJC8NhF7
SWkvhfiaWVXaVZby0X6qW0zOVHwJcxtaD52CIR7SE0Jx22jYT2tTFqz4S/yZ0TcXRBQR6v8Aioon
usVb+Y4g4ceSXpXdg2MumIyfcTt63qfDA1eOEWTYboTfNE0HvHmVKC3ab9Qie61KfmPQivFOYHAv
RWv1NFSNgES1bZ5DxZNE77RCHbFNMGQXlXF1B1O/Yld0irnyrzA6HpaI+YXwIp0X8kcnMFb7YRSB
Vopnnrjj+YK6oHBI06jxeoAWApSmVexnT5zGp4S0Bv5gqY83ovioLaXZdbK53XqIdRKNziRD4Jgq
Bd+YG8e7qK6VpNxeeJ+I3pg+OKl/wvaVByuRaWU88TSKFwVkqDkxFsJ6hwAvdSiaq76/EbfoIefm
cwDgr/ExAFnUCVO0Cw4qF7WS1irtPtF88lUkPubTLgp3zCyD75bLE5HRyw2RZYChKxvWEy5Zyosv
S7W8EsNasRUhxpx7iPKJfdAnPUb0LJ2O5okC46Q0NuGRRRB4drErXb5g013ABX5BInxKqiGURr29
wUUHesPToA58xmH5ijUBt/mLoG3Cjaq+s4abU6lxCZUUP2kvEa5HNpb3AACvQ/2HknAhdwouaBNT
Bt37o1FbaoY9HUKgxKcC0r/EwJvQwLUexZZ7gCDh0Vr6hcY2FYStCtby34jevIsyWdA4vqaaKq6u
4eIPQ2PcsOE21VwgaG2wOoXAUucHFVWpXsjUtLDFSrk9rqpdJo6NfiEIkXbaovEVV1hFgumqIwK5
2G4XuU16uFmUxtB/UFFZYIy3M9oplxf6HqBa6am0/uPDSdbUp4Khu+5STdBYHLslX+EDls9IbN8t
SolSOvMrow1GsYAsYgmVE82o+zVo8pTVpSlESIgvazxUpMqLOgBEPiJAYr5g1eR4fzDiZWQwshC+
RHSQ9QSk3l1+JZzNooR6Wv2gISjqsiOP03+Jdw+FR7aoGq/TBF61t/iGTrQ3cGMozcqXEh9P+RLq
vpr5mlheLtUaBGi6O4huvBefMzJBdJRDOulU6PiowQHVtkcM3kXPxLuFZSGGFw2UshN2Drr+lfFR
TsKuyj9wFBXLpu/4gNCbguCuS117ii8mxIPhLkHruhAm4VcBjAnbaclxadLE2/UVBdB1CcC+NxQ1
UcgyEQImmM2w1mI+SaDVu0t/mHKhLKf1Hh0WLbBC275joIMpN37as48EsWnOo9hR3US0F3Loo2tU
0vp7mEtIKqcw+Qm32glIKvFHUb0q5ZGC2uGiplx7p2jupZ1UyyyMrJlvP/yHLIQsKrE2VV2gdWpd
PEJ2oLZGiUVxe+YSBoYfxHDZKAtX6gbI8wATzii79Mp7rttRTCDylkB7bsQKfSoidPFdQJxXHZ+o
6BXdiqmVOOHUvqa5dSJlC2KYkHdFOIeHiodxGYmm9Zho1ZxNqFGf8pe8zMR91DC2WA3V7CM6gWwG
Y8AUP4lS5LtA9zergyu/ENnFhZz8S6EWykfVZRFPgQaQXHJ+IXYQEs1mYtJw1Yg0R5Bq6FNTPIW9
oGUO5mHOXzLbi8in3TEMN/g/KaZKpKPuH5ESEYwWNszw9ltw9FhIJ+uMJ4JRsqbV1vLH5pigc1cb
BYjtunmobiiCpS/EZx1dVnOXNgxVAgLjnCj2hEhrLAhWsCvsPEG/FeJ+Jb+ALW+uIqXuEtgWpdex
rsjIF+ul5BodU2p/7IqlWlbksgVVnDcoqCJWbC4QPJnQHwhX2AQTowB/A8xSZKkpWc83fqeWJYpE
VBxxp8zTGcBUeuKzmrzOGXLst5h6ytLrV3M2CzouozzDgqVSJnbB9iYC+jUTIgV4yzMXTCTLmFFK
vf3AFJsBGsllDQbavsnD3hRN9wZo6af4StAZOHsHuaDaQAFcsMotpafiLVDgujRuO0LAKFHZSyRv
QeaYS64ANTtYUD4DpL68kpJeClX4yAe6iOu/+wAop0aec+ooBVnEqrMOpR45XiA0yDxy7y4pb/Mq
5mXzAPC7lfCBWgnKxO0iXwcEQIlOZGpF9o3GwX1LSWKHCcvh6gpRFSBNp2jg8wgpjQ/lHpFlBiDV
kNwVinEMZZhNNgcHXZisHoG1vUEpdRElTJTQlENQWlQBoiFU4jkrtWMxQ0+pxn4I22+ZhfbIpa0L
gRRpqNbvqIlA/EdJe3HTFmVLsLCN8PqFC7WIFnLyQDlq54BBXfHiG7gNHsrtdGX0mmMN1xykr2ro
Or7mIgDiJOjIM49V8bKjxDUQuKpwGjLmDQDkZZUTipSi4VUNnwt9oDXVsMCgUbUVSVNpE5JCqxg5
JAEV8Ey92D33bn8QXKA5jMYeXEqJUWPc2ptyMI9CPFVFVmso7nGW5cSk4AKIKPzM4halbHBJwhe0
KYLYa+bgiANWIIcuUfxEQJTIdldg1AdRxUZt4wZAk45ITcptOdgBEKsJf0BVEqnNCUcbKYE6baht
roqA9EckPzIsU4lqdXkhSlFqRvIvSS3VnNlRciXlVC80teciEaLWyK/tQCw0oZ1vA5uUKGdF5LFA
VeQZCqwOrhuFgHIzsPohWFNiDuKIUidmL1tQpAqwKTgymFkA4JUaQtSBAneVUelJ+IqV1ourhFF8
KhSha2kFUDtZGNRxag4hLqoeNR0aQXsHRS+4iA/Dy/iVKlgLshOSC3pGVYiK1dQzU6uoTAVbnEbh
kopzEnFZyVFhyJHGCVQlhtLFIXBCm+EQDu5eH1NcJa12RUxM0ZsqXLl9EAI67wwwI4T+Z0FK0fmV
TE7Gyoa1gc2R0UqraVUUrU3djX1AoUNArYqEgUKWx37QoaYuWdwPzAUK0MNiKeJZ24yFVgc2opxW
jXFRdeOfuWv6S5lqsFBbQS42ECscIo4VZ6gHdynd8RmxuHXmLRkiO5dAGU7f7EqqCs5zSEGAgmtg
ldNthLaKAcbAISgvs4lZRdBu8wHLCtergKsXnahM7fAKi/IrRo/cJvt/utygsAAUvcYBp8wPF8AP
xNcfjUeGHCBXXWHIE0RKfwqdajcUakGQbWczwQ4Adty8x0wCFR0jZYfSVmWbpODf3BpH2z/1wF2r
TgTxKTErV0Pz3B5cEEK1MugRircQUF5CkfuPlttYdZUCFSS9lBQhRT5/yJIWlUBdfMf/AJBgaHSq
riHiqVmV1HMsO89Q+u3PgSju2SjwRkMXyBZhHLjI6XfcOE4B2V1KYQNV649EIvn+bwmAkvgHkg9V
Xf1KUF3cz0GmRMKd8y1ewy1S+AVKskHIDuljiplMd2AoBPRZGlv5I7NeYHFiwCz/ACUAtIdVUsL3
rxd8t9ShJJiuFEMOCWzhyeRQgNMcigyXQ9kbmXvFpqFnFpyK7+4rXlNF0tw81BVWm+MZQtpC15r1
E1EsV+auG6mOAPCkaKJeR93CP0u37CHoGB9uq7jJqEodtqFWSgc/ZBZDTXD0hCQHT1pOYoSA3muy
LKjF/OQOBYIb8QRzwsqqwjp7Vqwvj4hYGICzQIDQBpa6uvMN1S9gH3L64AIprxOETCDfi4Fo2QC7
uQGSVPkBgxwgWFh4+4GWr+IJjBRMu/JOicxrCeTZaym61Ku4TEO5Sm7qWmz7psytJZ2YBw5rphFE
oA3aJna/IHYnuMxLV299xPpQi7NECGFUaas7gdkfyvKIU8ksHINPD0uKqauBVgLYgoyzl/5DRWj6
l+0Bv/CBFhc1zLhNXC8yk0d9bHWgDwzmNqy7HqFtwG6lNFPXDCl1aNcFRBZYWi7VSLeNthZDYp4I
REBVwJUATpuNNrQlvLxCVR4DiO68C/uDgbb8JS4nvuO5VhXfiCaLphLoqFOm8mYS5+kEQBbM8Qcm
mRFT3NPNfEph/MUjl/MquhFwIHqKma1K8t+IAKLviUJdhhZiwbR9kpeDhrjJU4BeTPaULU9QkI6m
tNbCC00v4lUPR5ih68S/00GFqhb44yVxCHRGsiJ4ZKFnK4qsKli2ekr9SXe4cylKVFZaHO06ebgg
ubbqIPkIlBAK15lgKmEuQYsl3GGjxcHnrDmFpCdVBKuFEivZV2FuxyIQ6FddR8bbmpSdVHMRoFLr
IyblKlOE1yxJ2VfEEA+iHTQnDMYDfNEvoCYai4sNwEjdfXE4/KVxBSXd48TkQcrKJCrFELegkqIK
7sMC8U9ECqXYsdEAdV7lZTKcqO3BFWEW0APmYb8yloltbjAyQbHGAWvEOpFt8LG88AJWCziZGEwo
WdEU2jZk/sdSLU5kO/cAzc7r4ljC+RmThBCoQhds+I3ol/gSqHDF4nbH5eLpAqGo6MJolHROIbJH
NVBSI+FSoKvbgOXEo4hyi02pZXjn9kcuAmKIpdcV3KHAKDxLQNHmOA0PSGz1lQse1e5RIQKfmEkS
XRUbKoNB3E4nl2zxUzsxNdPiLwJ+OQNNkgbbuChRoPoNjdLMXcRZvdrps5lAcotUtvQL/mU6g8iL
La9lLgfTDbS4d4CK8rg00NDIoHzVVwDQuAcpHG242TbpviZPPqUt20JULnn4uLUhmzxTLqi10in1
Dvogn4V/WSqFfZ2QbNBr7mR4W3zxEv3mm+YgQjnw4ZkN6Og+0mwSLfVZEIVqVd4iam9jKWCIOq7I
0krP1iOzKxtCPuAsgHYHxNbpWek4v3h0uUwjqwRclY22g6lTDNuQHcpIjTSqhlFUy3gsi/O/8grg
hAjCaK/UuAEFMuAey5aRBECofRsQwKFfk/yJdEKrt2Mb+2LtLxYwiwWrr/Y7epAtHu4NbvhRdssX
KynfNQd1pCt9TXYaLgr1ALtghO4ZoRAapeh+4q06cuWrCiloFce44gxFuqlEx0I/exwSj0gyAOfU
uvmMo11mmrIisKLzcpzpqw6iC55CrX1GFlk127YWc4wZEb9wNM5cLyNTtqIElLLtfL3LOTqTVtyW
6aolVvmX3Nq/qpvAByDwijW0AT2EbrpBFXsMjcbT8UUSG2bNYTOQCEA042Zs9r+yyvllVhix2ikK
snMUGu8JWAm21KPEPDVRdLlF6TAg81BIdQtr4uzqHGS6y67fjiEhJ2Zhly86FFQXxUQ3qqsFb48w
x+bS5SVV5SXVE4Mb5bXH4lgDlH3wziBvlvtE6fPpGmaaj3OQUg8p1cOXeoJfmKSoCnN5B1jH7jxC
rrzfE5lMlqCZOD4g0R07D38wTqssKvWePcP7xctUK8hNbBd/iEHVQFfZiL2OGLl2Z9XBK2eWXuJK
qxdb0b5lLVGuHRa4jS3JXTqKlvaCmY7nEI8F7/UJiQ9jzKwklxo2UOkosEvv1DA9BwvyS4VmeoNG
hB3mGOshWnFx0pHRT3k6Q+oI0hsqC4PEt9fiaFmtVHSsBzH3d9niYH1eDqLRzmQ2GrCyoiPC4pkI
D49fcK2o3yFEvUqyx3cTjgnIOhjzlh+Y3V60MWYKtvEPNT2hwjuoDiyqvDYYWq6eENlLYoBlQ6uG
UQKW6Y/ZLXjSCsx/VLuaK34WFpZYXJfqUuwvuXFEXzFwpzKaDZaBhU1xjVRxX9wRuIitcpBILp6j
sqqqvmBqaXYnxAQaHCKGgQ/GS1ExWTE1p/EAryjcQgVeIUTfxL7Th9MsppvfxE3dQ2MbFc6qotIC
sjx2qUsWv+w1QcX9TQApZzzpBLydSwytZcYW5F4S3fZVf3LAduGOycPMRdrFfmVtqKfxKEpdsFJy
QTO423+Yh0oKjhWloN87D1A+AlR2AQcTFtEK8zh5VMcQKUUxDzoqVfibuaEO1zK+adoORqz+4b0p
L2EURr3FSUgPyh0vfmAIKfhDIwBYEWcEFaFh06l5LmsTR8xEXWPxGSA07RyxS0XfZLwtg5ahW2bK
vUsCu3FQp1xv74iJ0qpcdFL2L7QKevEMSUSfeQj/ADXxGIotp7jWt/qylrIsK4VC+d6lDdcktdDW
f3B2A8K4hOtLFHEYIhXS6mW0BsPbBqSFebATNC5yMovBYY15g2diqwI5JOzhORZh8xsKBLqIXHlf
zKIi8sWJIKV3NGfdzcDyhUdi1XzcxeUTe7gfT05D1QodjGN2mng9RaK1Z68xigDVPUverCmbSVFv
ERhvI+yKhpyNVKA+EfHNxxqzGvUe25BSNlbQRgN6Bq/hBLbB4214nzqL6jFqq9QisvRRwQBgdD1k
WuIHnGUFro/cbDlWbLIcG1gGNd/EvCjRTwEtIsg/UsTM14EOIov4sGSBHB9TQ8stk8QGL2URLYGo
nBxDLqa5fEPeAU9FmRfkSE82kdY1pdBQlWwFV7sMvdSvLmBptNt6WE2ahamxcBq2F6gMpSC7sCUG
iB8RbF8zzcaCdOEL8RXyKAY5fcQ3XWMio2C1oNwFDX8L/wCSuqxB5ImONgtBGqqChrH2HkpIVdUD
q6miwKHG7lCQnss7hQmOjhmSyNbrzxfqJrECi78XzAylO+i6iuACtVdSuxZPLblh2v8AlkCQ5O/d
QCE2du2oj3QqFcNSy+oCQ7jnCFWPWH+QixMh++4qzyEdWkQNnCNEYKfxwjVTLaIwoplbzYxsbJ7X
CeQS07Ldg3QHOpVAJcvwoUuFBL7D4lCFBUeajoVsOw+UbEGsAcH4m0Gb9QQcY7RizhRbKuPFyN8S
pr19UeWC5VaBbAlUKfuANqpAebYhwQLy25c21QfwhRVlgVOMP3FohGHq7r+YT45G6Ov3KEUeAHhH
ihtFdYpKlU9af3GRfNhxHx4IRu+VqpV2gXQ6/ME1wbhazqXYphoHqXNdU6X3F8DlHLicHSeCn9QD
73zcKGD3UB+Ysz2njRxDTQSlWMWxVBXgvl+5XEVDVqgyDVoRKk82fxcpgUQBPDJzMOJRZv8AEq+a
4gp5PccJUE9XTiI100Xf/ghEqVGW8h2nMbg+1fPlbWxmuocIVkgC9oZdQBVgvDXRYQNiDs+HmALg
igD8fUI9biaO9/ENylIeIw+45aAH3Z567ifcJaRzX3EsQ1t6HMOUUoF7um95irVYIabz1Ua5VX5l
MpXxAJZDwXRFHlXmVA0t49S8SCyzI0N4JZAQOPidJ0suBEV5uUTQg9cko9SRslZeiy4vRF63x4iO
TS06YIx13zVkXIAXkF3FW+e5wcFs2GJUXG9uZyKAAOPO8wVjcGCLMAPuII6S1831CMcXsAEKhnZF
yJgReCUvFvMuUUqaQsRspUEB1fJEWPRBWi5gti0yijpEctVFaaZTwlh5QUdKM8xhQhg4r3GuO4eH
zFYwdfichpWtJW0J2vph8Ra5i9yzealoTALH6KFk24ZV3Jh0Q3q48qeF9RsYd8zerwWDr+jzDKYV
FmkttLuLTmCIHtTzKMrdRzirEtjVl8AuZpUeZoELXJEOEKJQAAVzOOS8LKCewHmYkgPzN9h7aIvo
GhDey7oLahiDpLg0dNXEaEKeILEDYKfVUvMZm3DWiAaRtwRxcAgCZyX667uHxMpbDiSt2AjR8rly
A93Lyu0jCVT3AzFEF0V0viEQINkDKJTcZatP1FS0NeIREm8VKqU2VwRuwi7r1E6BFX3BQJVpuPVO
Y32salrK8xvSSu+or1Y9VcNuAApgddoUgmAaq8ie1UoP5jbXEayigzzzuReFFBXMr2VFO5zuFHYT
uo3zsbiWjTB0ODDFBXLI4BKMuPdvhGyj47X5Z2LS90NnSW5hAPA31FqM2MNXSaA8wiIgoPEHjDhf
dwWbhZKMKbDbJOr0QLxbt+oHsATOYOEpzqVnC2Dv3G2lboxfwVUMPg+c8vUGqAUruuoJQtiemS4U
WCtfKX7BAL7i4VaqVMwdQwf8lg3PY8cXHgbsHRNxm+ypRAxvfqZ8nV1C1QqGQkhoO8MVX5JVals1
ijh+JQKA8K8ysURI7vIzSmwpX3AwDWfiLYcCPdQLKaOqlRgCHhGKtq1tUUS8xmKe8lKmFX0gWlCJ
zSFiBPTmJ4Dg5RfEcmG4eDP1NYbYtZC1UNr5QriVo0vy2PGK8s18St1KrAVf3EsSgDm2qim8MXnq
FahDhX78R8EB8vULSWgYvO5SfIsWBLsQFW3BLDIJyKiKlAhksl0F/VGXbHgLxC/0FIUJcs1am/8A
qhLwQVlDzHBO1/8AHUPbcua/cWrOHM11sue/nQcxXtvcHwEFBWyk5vd5FH1BlWF5ITmbDCt7U5cF
K142V7m0KaRSndcU5xC1EYMPcq2DjAPJEqQ3Ra+CuYl8usnGb59RlTGUWp8+4haskV/cNGgoVni8
PcN6qhU+PsgCa74IdANY8AMNG1PUBDUl06EjBYADFepT3Z8Rdyu+8MvIjEYBYt35fUs9h0Z/kChs
KoNF8QQaGi3uBjYKh3y+YA0dOxX34gVT8iPHHMECFY8tibACOFDseiTG0HqK125a+IpxOoNnXu4G
EzfBPEFPy94ygj7RW/MAzhgtvLXEYiaELdYnHZo2/UPaHRTh7mhS7v2RVe+No+JSZp1I+3icv+cq
fHUrhG3zfnmK3cKOzpDiLvmCqm3fiWRKBQwqn6lr5uqWiuSu4RMFTzfEWTVCCpXiogCLLodMyKH7
/fjCY28A6qf33PBRW/5JLO9GS6eoq/BdfjdSqOmITzVkoZBulKfQQ8Fgg0N9R9hLBU0X4qILyow7
9YhD20QeWRaIB6Dtp8SruYgof8g8b3ARP/XAkCqMCgllabWzRnLIoeC5oVQxN87K1e1jR5lPyiKe
HbBRH3Es9HUpwj1KHI4o8koOS8VCqCj9wFrQUTDdgfUClgOh4mEAZREj4YTR1YyKil0O/ctQeGlv
8IhlK23jiEzLyBcdLsa8cWRHAcJiKirQRUsFs8v7j1Cc1S/zC4fQGbmKHd1DC1TgGQYLfFb8ML+l
i+fcQIE4EuM28uDKAOqcwCr31C7HgjQaEwK08SxCtuMexPJCxhvpCdj6g2w2US1rwgRZG6bVjyuE
XywibnbVH6nmWj/EzegKXLgDSHnVgduYniJDphb9ymcIstmyLaB/iWGXQs4fEWcpptl7J4ELPLto
5jTLyLDC5G1QeZZ2BdHiAQItQuYafGlBYbC8mDlVnqL27ppsJe2fDG3oRfvmGq6+yW6qYdofAW1G
rL4qZdYJ6Sr56s6+IzVZzYccDt5EURXDT7qbEx1aSHTr8eLlxYmju4YqzduOlu7dxmCTVrYCgDmH
FBofcpuYK8piXSsWkuQL08Q3UHldmXS8v4lo2mUYxyUa7M+Zwkei7L1I6U1UP7xAaSDXIpGlMTR3
LGI6jGnmMgbjuHLgtaXmTLQqE5HuAl7wLpQIPQP54gonFeCCZyFLWEhp4u4YECfc7jbo4YUaYct/
UFVnbIW0BVWkMCYUr+qh7Q8CqZepPpRddUa3YWGyrOBNFdAg8BCkLgGJc3i/io6FVYniVsckQfZt
wmf1PGWlZUckei24RXGgl4ikaGNtnm7ZfX5gPTKUa9TzciOeo4ENgXmVxCgJf1GVhKG5zSF4BcrO
IIsXVG8N0j9xo/EKyDEtxzw9Re5nAS3mdlapsNISFfddQOmwTn7Q77F2eyMGhwP9ygZ6Jb+42hVT
Gj42Ez2aGkzC2B4hpCSr5PnYMgSlrFxAmkXLWpSvztV+tgYYLoqJxq2AKszxEq0ZD1p+E4yzDJ8V
FXUUnQ+CKrxuf6h8MAU0/WcxkmFVw+WiWOXheM8GSwqWhSm5so0tQX5uUGBYVQRsbMLwZtRBs5MK
rV8IXfuF1jhwyrx/MGBlGJAGkcWrItBF1KXir7H9zxzwbv5jUSRO+R8whNwAlYQkFpYD8ywMtbBf
m4aIKxFv1NpBeqejByX26pfuILRxaCfXMUe2B/dM9i2G2/PML2ikVdZjR+Sp9ZDGgmix9xkwde5X
MNRXj4uUEQ5cix32W35uNUyw7D6l+MnCVvfzLFRtzRGHWz5z14hABrNqwZs8GtgcFjGtIrV95KiB
BqqrnYAYqDxEoq85BrF6tcPKCqbj98yvXLjvYBWHAnfuOoTt5b37iV3+v4lvgygDfrxEsHfU3qil
JfzEB5mkyLr6t57HjkrpQFoLFuIwSDK2HzHkWfEV3hoqwsoXN0+4RQL8DFchQqH6mxJltoJQtCnm
joNwmkluI5pxfmEFk0V4PMCK8x79ssjVbSqo4f60rcaCapyKPcXqCOmOQRYEE3p8L9kbQBO7qLfB
dBIupLVtRR04P6RObaD+0GWlxY+EbEvbCYTV7bHlIFrcz0wHAtSXURJYW2Y1ZNU5+IyllgbXwS/O
excwM3L3OviCUuPIDt9QOlvlLhIa1aGk8kRQDzhsoCUHbCEaf563Fx6+7B7boFfiWgeahXSB26ie
1RnaqAWr4gZTS3kiccpYot4RMx9GcLrI8pDnmEua+IJLRlL8eoIAcj42BQ3vuU+CAdsrYHYeV7ZR
WH0hUlc3eygMoZkXXsNnKLb22CuoF8+Jj1olWQ0t5OnzOQ1ROx5lwHrx7hcCs08SrRzFNhGvJRaX
qFvlw+MjIq82v5lhSnHlEybRVN/nxCWhr0+ZimBqqh+82DACoGLXMDh7yVDRVN3LJRSPcvg4QCJ8
QG9uoQvkiMenPuAhfPiNfJUEC+4A316JYJHIJjK1gwFnMeetYUh0YTxBwx3AfJYxl1bVXGR2yGcS
kK6momG1YAJUQPIcEyKVcshK1GDX7hbaNghSlcIkGDV8rjwDHAq/mOgU3tS92yqKRiqBLx/UScHK
GEgseG/coa2LzlKETkpcX1E0Ag9NlD9kuokGIqN0UOUbNUA7eSAximrrF1mXKFrfThgsqFWNPqM6
oORn4lMKzMdlmUTRGeItXpLm5K3CMKaXlrGMuDopjzEOaWxzVNNbLivOhbA516URB93VjvuOtaHZ
CIyQuiqh6glW7YOGi0qHs/HD+I9ichWsULLvLAetchcpHKuiLQKb1iHRsW9e5e25pOLiO4haGmBh
uuhkfLZyQMUJg3o9RAsRgVFlTFtMqBwOG+4cVXZbaALRbipj5QTBPUAARtv8yginQj2znUcw8m+1
iJke0EEkU6KubbK1BBd4HFYmVBdFD+JlnfkiRAEaKDHa0HM54/A1lmRNTiMggHNcRvOjW9xwW8xU
+Km4ROS2+eI1fiAyHf2CnEIRM6KioYtDlKuo0CgwS+4MZ57aP8IIRkULBFdQcwIhBiaIRoBrF9xr
+C0n6glRWIYfUusbSjmcwgol164lWVXNaH1kDVycqlj0a+kX+ou18hDCsoytwGQRbXuC8WhdcoZl
BjW3KhYaupybbWBpZT5g/wBSRPSOHCe4hGqqznH7MYJjnaiJHoBZTHZXAH+ROOK0BX6hiFi9swXx
XLYMBwdNjiuV00sByxflePcAhqdliRqLv9BkDYQopjgYxd/uFVSq+8w4OPG8kqURAM+YS8DAYwiU
20Mq+4fKADXW/MILYqkTMc9Cu49G6vgrI8KRjQw0vm7pFaKRXC/D5ZRUg86lQCa4DV/MeAuVX3H2
nyGFUqPpUuPL5C/MMWqoDlhs44DYxb02624txUoaD/MoYTnBqGhpB2DmNNDqcjn6gaaV4j4/UvLS
v+QO6TZ35+YucQEGdFCWvqPXvjFN8VO8sW5PiVWmcBlrkXFfKPptsuDLjVLLMlgHQK+k8syTh6ld
6hVEqoyV55mJ9KHB5lZSoOY9ylBjIXtGFFYco1APrjUEVNFwKlOe4q6AXBZl3/Ryn+47om6HPjI1
oCymnev3LrFQmt1Kew4Xx83CgCpOU85ALsL2UbxApY+Kq/Ech7AcHgvxM2NFEfBbGhDVVnjiBsYB
Lb8MC7tf2vmU5tUnuHWytUW/9cK3YP8AL5jDnMKvHxMSQiFnoqDCFSqd+IvQpiKO5cugAR+jDxNx
A24guWwVm6IQHe4FfmpeacDSvTqN0Vyq1v62Ueqo6QhgYaE6cdygq3olrtlQz9YuSNuKHjGQfi/E
1TC9MbX5iA1Md67cPMEVrrH8w27rB1efxNdSNGy0+QaCtIFNgjU1xKMWXBaS6P3xNFKHuNNsckTw
isSV0F4vYjZqjkPNQLxUo3wcMeDt5sTLgYEVWndVOkMYBlcTdrCKAgHo4R6tfqAC21mK3h3PlMCb
1Uuc4OQL0aEvfMwUrLrqM0XahIOAObi3NSjjeEemytxNjy5LALQbmso0NuoV131ctFMKhzkF9Tsy
GtiZUCgeCQcGnnY4hYBT8y3dQ1UruE4PU1ajsgDFgS/EIJKie0XiKwq8gDNMwgXTh2oqRhGWvHuc
AJUnNeIZiNJs2UbY+oFyUxQFw8wWLqphX4TgDmOaC+O7lcGKa4VKDhRVRzYIh5ZQ+otftKud4Spf
jwS1vVa7S5f1jgEgDeHAcwtyKDhbmGAFUGhalJXqZVCWvfEPJAH2KmCQ4SGpUxx4gzOUr7l7ArQJ
BgA8YRRBIK48wKfG0QJFo0SlVotHhmOvgOqlLxRthG9C6/MtW9g1ywIBTsImHZykysCL9QfYfZ6h
FTSqgL6eXC3MGKtqVoNqurhT3vV8yhUW48xgGG3E9BW5sr4UrWXwY1lwWpq4hlKE9Q4SQ7LaB0Sg
RSqPmIbbHPiLA2IAzZYlFFMMslXjbiElWvmNAoCQSBVqRcV4hsLtyFcYhH4IoErUAsqrRsCocVaR
+gE8RaIOnMPqWYXsKOXdncOqNVsLQscMLBwF0TKxSjKKLNNiYoq6OSOC6+1ysGPBzDCZUq4gljBd
pGwA5qcQ9UeIV2ThUCc8vBsDAL0FSg0NJoSYHxQckDByiKEqC9NMBjsVEgWam2Bo6WHMSCw9r75g
EAbuqyFrcRAgqhpRBx1NyXrXdUNjCQdouFijVRajYGtmwKWA5iFC2mCrRZV/94iCLoEMVQt4XEWK
YmcRP1wUXC6SnwuDNUtrsoyBog/EtVeKHC7/APCHTOFFM9zzfYOWoQ6uy5AWgnNwIA3iDTKRVfqB
yAcqle50z4Kl/oWydJmVsE4ljTCo+oSW2g6Q85SqGxDf0A54iUQdk5eIq7mF/lKfF4/DqOwaJfAg
KCwqL6VQ1xRBEqgg4bnQ16vMcXFUeV+Z4FAHA7hMUXf3n3BPqqpy+oyvaX8RSc4Dwf7UPN4IcVEU
Kbo34l4hSYxGoWKlLl9QBPKBx7iPzQDVbzC3lqp7qocuMLkEUFUPUV4qojmzTdO8RcKhXtcHFJpT
ZY9g2spKkCs4HMs4taswlvRxCKt5jnSiFdpbcJOaB0XuJipj0C9ICHCU+Af7jwYAXIXfMuYW0/RF
WxV5bn/yV0xuo7pf6g+kvpq1qXr0AN3VxQFFArOKhQareHMMBFToIRXS0LzAgnJ9N3/EFaXIvcvU
Cl6DEsbqgFUrHgpWnFuxPQfhAoPkYlmiFV/5ssRj9BpOU7SIvv1Lu54a229+4aq0P2Raa23oHjzc
ZkkPk9pS0jHf/slZ4xa6MT1kOrF/hR5l8VJtt0cQeBFlpvh6jb2bjy0QsdjyvP3H8rxDZOsQuQCL
SuoRwpZW28QQBADhoN/mUrjYytF17h2a2pQqzY5Yowco+AcF6D4gjwolYfKRNOlQanzH59peiY4i
f3DnwCOVNgS7YKQNLsN2Fd1Eq3S8ZxG5w2abH/CYN3hWj/sEYEqvlZ/Ex2jgB8dZAcPWWhUBkBoo
HS/ww1F0s8sThKko+f8AkPqSn0Mi1qfGV/2JAsAtWyvGiHOb/M+UIxcL/MpIJfubw8ZUBBzoAv28
QNjDSnKIG00O0EbYQxUt6GXFARonJ2h6gpQngeKgWXUIYC/H3Cl0diq1YzDtl+HiVXlrA1d0cSku
2Ewb+p7CCt7q2W3AP2gmBncsEavuKUOEIoYta7iD456iVH+Eshm3eA6DIp/ep3vEEArqONtuPusK
fBAuC7cVhAKPvqKqIbfwf5CBxF3qDVFiqeZcC0frJZ3Xh4gQgB8eILt2TZ3bFqAX9xmlVluF3YvB
QaU4nT+0tFj6lDtek1SH0iCZS9y3fJ3MdEiHgp9QGIvxES9fETIDYdvhlQA75lWCQ+JjR+QHuV0B
eka8Sr6ZVo4Cuo1kosbjhbbfKZIBiP3KjbGpQZXslmBnXgStT2j7gUYL2IBxtvllsoAw/ucjoyGX
D0l/UGwBVfE4ONXREht0eUdSLrT3Czqix5uE1jmi4LinKdQXAKy+uJZNtxrZXM1qBIWsfiW12Bj9
sa1ucwpLmy3ldhtQpn4mGdXUtoIoPUubi59QHcC62LAoMF5lKBhfgmaKMYUvBz4mMwQrzAOiocM2
p2xhyh13nYd0ZpOmFwxa25si63zFMcPBxF6oOKYo8oCXwwmGmu8IFI1ZgJa6UuTaA5SGEt1LrCNP
UdqXgf5i3AVadzI8XhjpqDS/TLDY6q97GS4LH0j1lar42LZ7D3ke3um2PDepfMoSrrKvOTpfRBJU
cbV7Ha1YZBdOeoC2KQyOvawhG4RtZFKGm8gCWwG5pwJpzOpmFOYed68OoZACtqWWKIK10AjaZyIS
tNSrIX+8jFSitwzMqhFZY2+2V6izYQrrVRg4CWMfFP4gRhqfGNCEIz/KIXdLjwRrg/cd00VfDvX5
ix5DuM5q/wDJbi2KVxzBepw2QJPKl9wDR7ucNez7qZl7iyp2X6l/4op4ohDgXb81KkWCLZBa68s6
S8D3LvaK8dwyCyteYbbhxgAV6hkB/MQgvH92HGit6I/aUonvNg0Qq+fMpRTh4mQKRzCEkgPNZKUT
hGZFnZ8Q7aSGnneYQAXQB6qAEwI9gL39yjENsPNEGh3V/iMEFGvS5R/RQ6ckvqcrGOLTC5QoJDve
JXbim5QAMrg8S4TRD3MC6lfuAArtv7hOIB+FSj2k4fcuBUl/5hdy1G+Oo48lAdpKP/8Aa4SpLEP1
EAPwRqNA8Kviiej7r5ieD+M2s0K2tzi6IWzpKRuhzOPLK9xavDSTgvl/DAeL2/cCgrWO75iflMhz
OaR6fRTedqbZqrZ7jC7RLPBcwpdgcn7g2RwdyvNR/QFuAr9xv0AdsHiA0KweAmITZ4KOYFNkuYrD
klg0iv3Hudqv2oBIDQ8cy8UWo3MhTSB1sRd+4kCtBQ82y7IUw5VwlxrQP1lzZ5oK8wtjc5F4W4qU
CLc2HMGXgHeG/qDC6UZWeIMa+myhzVyybMB24iiACrCyCo8QaKeYlkmVe3lygGiAu3/xOJrDcut/
ELxSQDcnXAIeonchwfvYRJR3rqNMEJOzY7AG0t9ofuKQeROZaBbI6NoTs2FbbMfxG/uugYtIS7Jb
JVL0eoCxSaqeDpi6/wCCmutqPd6wHMd3VKftLfpDk1SrB3jrmiP2lXAXmpkEYaVc2AkFbbSboV3D
ftc8uf3Auqq/BqJ5q1hTnRdgrW+1QuqbqMcUADq4O0qiEU8EGFFZ1TiUo2F8dIfDXuIesenWdR+J
wZxHg8V3LCC7eYK1yfJA0dyrKQHbFtGKvIaNhvpjUmuiPQuFd8YHQUXsdJYWH3HUsMToqA9KFdIY
D+KXiXpuU2oT5ByThUDQ7iJLSjXrJfJVVNYytXHuVcoRrzHGRUXguEp5Dfq4vWK7E8Pn+bIb0BPQ
3Bx0vZcjo9ks8pl5PccG/EUQdqJ2td1A10eWZasc3HLVkqWlPBFitlLN2OorBzWwYLpD1YupgjaW
CDhyJvcOmsD7GPO6/CJYR6Y7umm+JjwCvJLr+p2IVZU7MzSW6ieHuDXbSK8kKVRe+paBQG8eY1Jo
jzVSwhX3FBTXDm4lARF5UgeXRyuUanFvmJ+it+CUpujf4lyKswmi2K9zsxa68ZEsTRUbCmL4y4+j
bHu2PtXY7F2l1m6Q3YILveYlC1CZKK4+JcJSCHiF6eUae5cXldxkScPDfmEMVb8CEbFK2UQlwHCR
+loZEPXIyodZzxNAuNdlZMgSpFpc7vqc1bb0nahWn3ByW83KFnQPezHPbX1MWWxqUY5CZ27bOvhW
x1RqFYEco9QLS42SzHS7LCXUTyXspBwJ8x2V6S0Ji/MtoVq4pMK/pOHhWhlzqYHoOJ0pn8Zpkc/b
YcykMCmuLe5YuW79xArbvSJc6KKJd8rL1C74C3iMoOMfNRyO9rC76qNSQMKX8wAKMXBFwLF2f6hO
mH/MNQSUYn1E1yu6vkm0EgcDQG+46LH2R0GnDN4J8xzJImRZLs9VE5Sib6CFRULol8CnqHQaP6P8
i1kDKfJSsh1hsb0ZUCkIq1iKRJYjDwxHDOYfgXv1BphVU+o9CXLOPUJgIA+SHk13hhApmumwIJYC
noRuaXmccMSlFCkprwhsB59+IbSSjXc3FvMNyW3MEWtDUDeG9XB17oYsDfB6jYSoH4lqDDH72apU
d++YSNoicORHGgrESLAnq4ng2LDhcgX3a8r1MhE77qMoIFnfzNjCss5LjqrK1cYf5L6winxGs4x8
2sSaBEadOb+JdgHl9QcF0afGy1mpJ0Lh8IcnqPQXGuOCoGCWThOZXRnp5slaNSn2xLwwNq8plHTC
+Av/AGOVZIp53vmI1dbhx4ZZdeO74y5dEWSu/cTdXEPb1DoNeF5dQlL7XWjf4gaiKTo5lERYasu4
LFPTeD/I7apS381CV10L4W3+4PNG7gfmJMUpFKU8ynlKKboc/uH+lrV1TDMEFfI/6QaXcVxkRshc
DcFSzvJFxRBNHDeJStZXaw05zKyLC5qgjUHjnYjQ4qF33+ZbYpF83HiAIOZSPyzBHMtPGE8RCADT
u3GZLYX5t/uAPRzms446yGIvM6L5ierUl+4aCnLxm1CD0NG88eYK5Djy1GmIrxKWwvxgLzh/kAPQ
rv8A9cSFa5b35joeh/slUt16uafiUmsOPgP+y80MQWJWypstvEYjNhjSZs7eqA5P+xQ4IjtClhEi
aQl5OGj6clIkDwxzUWoZlB8zNRAjpjFigAgtSk7lOhTwJ/EuYMLFalf3BQBSwcJtSq1PVQYgCojf
i+bnDr3QfnMyb/Pl1CuQiCvdn8wOrOduE/uchLK1ht/qMJoGx+j1KHwEQvT/ACAFMPsPmFGJF5ao
9wEeGN8mERtWxbeciORSvZVFsGJVvOBn4jFxFBZfNwbV5G0eDlvqUCg+uc63eYwuvEtTivEsEICg
4eSIDeRQvH4jAOdhYB93PhGTfFUTqs9OoSA6fyRsbbePqV1vHBxEU1Z4byKwrGGUEKRldjU1JXRE
gI2N+v8AsDINlryXzDtIF8VkVXiF5HA9TDepeiV69rK019oM2SmF+qZFeJtqIlFiUV4o3PqAqtGr
auO5RqFLQzHxUQ8ENCFlncoC67CFQD7uIqK07hjwnQE8wFU0VlRaE/TLvwYZ052MUNXcAsUMos1c
S2JKURgPOw3bzbko3m2zoi7b4q4kwWcuqyEs6dSgq0vzDQNE098yxApg8yxSC4IY8rB1Fup8oKBQ
WGchSn3BGxKT4mUCatdQ0uAv7QXUx54albrKuLzavXfMrqeziI0fN6hlQu8RDOUMTI2ziXd+o+vN
eYokeQ4xnAT9O5hhXUAEFm3pYWiIFY6Y4U/ELBYuoTg3F+LiqLRr6lfOawXlmhYr39S5AAW+iOrV
HmP9CK/mBdCLH1HtrcU4lDgERL49x8Y7Jw8SrDLVmtS0tA7W/cNoALfuMHEIH3EOBiXcqDUrpzsT
gFRTtQZrQeIhWrXUQlZFUlU4koUPgdQqIa1895+4YuwXrVyvwK0RCglJftiEA1INymgH/vUM1z55
lUFQq9qUsZdX6iqlVi+DuGtIFCOuijn3EGLqj5up5XgS7CNhWP6HHNS/EbqlmDXbSbo7yst3t56/
M7fAGkOdll8lwaAtJ9S1qoAOIsAgAFLGm2iR26gHi7Q3uCm5lpoSmGQrtGMqKprqA9zRa5YvKZy1
cElr2e5j/St4ciEaFjs8x9BEu1KW1r2EAgL2IAUDQxRLprGym7ItbGQaW6RDEGk8bS4IBRLjRt4Z
zDCEOEDiUgLUx0ptyrIaMKLuqg/Z0X5Ja4AayOxRFWDxLqKxHgRmgoHEobUJWLCKX47lRinLK9GF
4J5nIrUMUcrhfA4uVNAwK2WaQOLj7h73Ta6bmXQ3bVn7ieLTeUDaiD2PEIjDB7RyqBU0X8MoiVox
zkoXzGeCUUCVRx8xGHS0TxDq3Nct/ZzCYEeGFnEL8cRVKCNJrQmSTBrwJnCaMfuLk36A+mocUvYd
pBG4DdPFRy5L6TeY9ANWt0WS8xl6z5gjboOQxijzxeVy0Sg+B3VxMVUL/b7mVI5fvkhRnged2N7l
gC1XPxAI9hOAnfEGFNg0+GW+XWqmdTaYViPJ9xGTwcQci6LcUUU2aSgDvURJpi/KG6Gayrnt839R
hUKV6FZ9wP4lQz2RCb2rezqAt8dL8o9sLoVqqPjItUeizOP4nDbgA2K6gdKrQPF38RLJavOL3cca
ypp3wR7alcd+fqAQAhpferlVgb7PlVQElmnAPMcCQngedh6XRuzfjYGKtDfi4O7+lW9sIOrV/WoO
BZ0LdtzFKgdvsGA9901YPGMtXrLIo/mEpvohDdXg6FVUX2k4Ss98QWFEUCVjJmnVG39T3UF5SyiV
5ss9bMVtxui7yXPWWnKa2tl+OheQ9MMKGwvL9RnQ1U2nzcQEWcnI+TYhAoWyn+pHh4ioNqU9BbKI
9wuCTg6deiI16Avpl/S2Nm64b6gPdQKCV1HyExyK5fmIk16DlH6g0zqAb0PJGaAAr+JXCYqXXrjY
qKGjKHzdrKs1Xgt8Qyl1wVf/AMmwo32htZE9N1U6SvE20IN3y9vBGYQRX0rJTaHVXzEqcbdv35QP
LjrVc5wgCxcEj+IytKsLVY+o9zgEQx/qLm4Vfg+cgpXdA9OIic3wnA8wKt3KY4mpTfqJVd+GGvOz
FF7c4q58pdSqcD3ORKD1BoNnJfUASF2gvC3moWBvnYyKw5qG+BfPxCmWpfuJXlKS1IFP6gkAJnLf
EP8AMFeDhpKYCvMTZUoSmR2ptRVX1BzXRZZmBq2XLKQtLN/Mycbrj7h+woORHmZFZxbVPCFkMPqP
g3FBRRppzGoWtgMzV2OKuIgBKLb9SsXsWlPhgIvKZvS/Era/EtovMpK5mmw4h9pWek+orCr3ytW+
ARQGrvZO44KvHuoY2NVvcOPIIatTwBDh2izYSwKcEDghcDh8QWyFeX6gB5kFCWLwPJDdBooOYutd
2pSDCT3KbUW6hRerl4V9rYJALKuj6QMNquioizg6IgO1lNIfMI3j3R/uNPTq6+YsYGy1bCalUpdE
3KA1X+SMl33YZ3wW4/McDjzQfiNCAo5ww3aGx2PiGoyo10lqO8t2BHjr9qIbVFHGAtri8JeFiRvt
qoolvOLe34m7o2Hj3CBRxDpNhCVfU50DArRGh3FpDOchZu90Ue49NfEefUFOPZKTTlK4/iHHraSz
oSoM1naUDqfEAhVdi4Y1vA6M5t4epxz0p4WPdqUouv1DeqaKM+CaRACvNJbvPCK/1FbCN4T0Vz7i
lQ1wJQjQDYvNLSBAiNFVUyonJ9g1GDqQ6uM1uwKIGR5XaP5gsD4o3+qiwQHFKfLCQvOl+EIsgAIu
n+woFjkJ4UDCLJJoCLVFeEd57idNy5uvM3CGnuF1j5FgnjIBIr1W3BNSXwrn1cFfRykzAkYFx+Yj
ustlwGm/ItuCG2VVw+mJFqXVNfCc+raIKzKG2n1EYDnkT5uNHNnNWPuYY5XIfqVB1ZwPuIzo0jqR
CHO2D4JR1tbgqD7pi+EvzBgWkTm0s2hxexBorYZCOQVqwqOVBRRCAy+1r57lJC01uUAWeIEOUkyi
g5US4Ll2fiHaEryETj3rtKiNM/JEjg5BZeKuRaBHZuxtI9KVw3PUreVQhn1FF1vF3AfAG6iiAriV
9oX5UXsvzs2yqS4tlyGTml/PmMlw55bfmMSK6dfEFioyrlQClnIX6iogbwUxqgOziRFc7LW/mIoW
oviP1TcKcmLCpE0RCi8sHatnLTBfgvBlOhLKK/cfoegN/EuVpiE+KiREC1bT9sIodeaicUcS37lV
T4P8iMADlVfmoNPeJHfLEaZdzGxl6i5KgndO5xZhdUCZ9m8B8+Zz2GwJpeDr7gXI4Zrxk8DeHmVK
YwyKs6fUNUucEEBONaITpT235g+BOwYjGJ0Yro9eIZNRJo0RUFVBVh9Sv1KWXzbWYSkShyNCJOgA
Ubinoq8iXVakHJjxflqLhFfbXzDlaZHHe5xIyJd/MZgiXTA+fMcN1oEHoPmFXOu2V91BTlRwjXF4
0HzL6YtXYPuA3J1VsLA5zwhsBUtjLxl/uKbav11Ba4cVBeVXAG7l11WhleZU0VYVr18/UFhuaDA6
ginnQ3qooEZOV2CVbuGdOgqwx63Z8Rr7Vc/cGoEvVMKA5u/JEw5/eFyCi3jUIVxO2rChgclFUxUT
H6nPpQNB2xKi8Lq0QKywAoqVXFO0YoShsLfuK5aAFpcETf8AF/ZHT5+a/MKy89oihgLl8I22co+O
bl7FvAoecjLHTqbiK8MJrh6jSuGIVYUtYxSAY6C99R0DXsmeIAqEv+YsN/YlYtjL7nWHgO4nBqcR
/S72jEFC3ifZf4lPisQEIYCwkMBvseYMRyAcRDJXB6LyLiwVwEICHjtMZF9IQi2pJ1F9dCKrIttH
AlMkx8uomYd9ErIBVY1y4Pc9uCdMVgm5cyG3BuMtMDKSLoyNFzIl8MZtK44lrTBuELbSdhjcu4ux
bQFMoaaeoi95vghQ0AqFJLZKHVVTCweeTqWtE9mKLFCpVRvgVcYSj7IIWQA57JiAF4awbl6V03uA
ASaBsDmeVcyrS3muS4zIXA0hfNSNgy2mhIRB6nMYxYyLdDbstJbPB54mAgQfygwqA23jxw3KuvOZ
RZK7COC8RFw67mvYlosjg1F2gNpIz0EoVkbiiVVZK+WZhUQKiVvKNEg5QiMA0A2NmQOg6joNwK4j
wK14SzygCuYVNK5J7sMycOga6lJQ2o0+4pBNVcZwNjpFSANdKlbDAtZA1ZmEIVzkDiHNA2jY0DCv
Ea+De1HOHUIaCxgimsVKbNxXmVpdHGw3T+ScRrY6nFjL5JRgDonNtRTjmZgk8RwGsssuoaWFZQ4i
fbOAMIF0OdEazWniFqkb49weEghqeuqj4N2dSmEdNhrDanKcYxg7+yIYvGiEKAmLa5+IKi5twk4I
pFCAc93iWwHxF2XAAXGO8KMVyYi8zAPa5lbAnlCZSX0RaDgwlVzs5ZA2TI6TpWdMjFtaju+4UslF
V/Ee8ml8TLYA18NnBxNKS3Daa7RYzQocx/t0awTmqoQ4jgUcHs8yhxIFuvUb0ej4VQ1aoOcJGkPJ
s4P/AJKU0CgbHHCZXlGZIb6QBcZ5qHNXfUQoxXzAS870nMiQPdTP6ODPmWwoUU6YAiBuQErN5SsF
ngosCPoKcQoARAfucoaWKslHqbbL7l7QNCfUoaNCHLGzgKD1sLM/DF1FfVicr3NeJVxr8wTA3QWF
f7CDArTNhraj3M1fO5Z6lh5ZaqOxL1sJhkA8cx8JgG/myopVZ35Q6jB8jAfGNK1lIQC1BM1guPCM
uTQ1S37hNZrWZ4/cPCZRwLsjOqmoi9ukDgLFDA5hnUFqUvmIgQCorrJSgOoKPmWOgJ6f5AHk1Su7
gDDnYKu2VomLRfqIfocOW5Y2XLV8HxAUy2xWmXkC7bsHWw8gl2DnqapA2x09RqnGVZ42VrWksO2Y
TWOF+OYfCJpyF/5FcHBVXsLC3mWXekKloKH7g0WGai8RVyc4yJCxT6nuWoDRtnuV+YlVKoJtRDaa
/wCwq1i54f8AIM1YzCC80pop3DZAW3nbHxaJstTBMwxVUDiNFGfPmVmpiW/dT6gsoMyJ+iKXWP8A
M2LpKK/fUV/roFL6KbgoQE1iAcMHZU8DGCBC7okTd4vH1LYE77KHNSBYPKQeHAshDg9S2uNF4P1s
oDWJ4HX6luk1wX+Yur4Bx4mEoSLDtgpiFCC3wRC8dCnniWQnM7XYfdSzBLwX4rtjJtONFX5mARmo
PMuT0qop1EApsLDaqGUPw0TE45loakVZR6jk3lDg6/U9uXCOd9xHFCoCq5/MWqCfcHH5l6StNIKI
ZJ5oDZ6gLg3HChS/qIj6qUJjK2ePqL3WGBFUi0FV+YMUOa1sq7Pv8QdiDMYXfvmHoCydFsG/Mtpc
Q1oCAp5eo36WsFTjcuq0fcqUzqrme5QKVvLEqpW58Q8VWaSUQeG3NHgdpECqnqUEUty0Qf8AmVwb
cxxCtFNl6qUTHVaG0NwdKKaluBTk8iAIRcSNoW5epnFwPFSkVCiHAGNlbmCqqL4iOPuX1qqB3koo
Dq3K5ji8h4cP9nJVq8w0AKYs3VORBV35mwOJVMTNjsvWM4G4ihPcAhRqzAn7gfLEcWVB9sLSqBzc
9UDwlEDexw/+uPyEZXCGpOFBUJGu3/YDsBZK9ynVrgjN51XmCAuNWkXLOeOZRwJa2prkYe7i1LZS
OoURr2jqOECuAigCLCBmTlxHwaYjLSzU0g1NHFVDXCgPcwsJzUUiaWE47FsaXRMyV2luKnU3TJUi
0xPErwTqrhtEGFQxxoFQkhXCyF1HPtLxLbVcRkFXwI0C6EOMQeI7ENuUO6izOGWGlC+Ja9R5Nght
V9pgAOkLLZRkpP06JXrXLUPZANsjpW0IdAWeEprOrhEoDqiUaBvBpaKxVa4eGaXVX6SqjQHwqArg
hdQCN+spqotuRNTRrApGyhItNy+UggghdVFQCMVxGosAeJfmgNA2DZA6yxHrL6JeVa3TmeoApJRu
BdVMh2bc5gYJ41E/XAbOWgt4TMv2Rku5Y+5oQgdIJByVWQ9cZwg8YqclBRvEtmEOOWH1hOdQLQDz
xCzoMDzHOIxTA4I7ajytc3N3Mjd1MsCP5hjT3K8wGVsAeYb4tCnr/sGBPQS1pBWYAQCBL5uJ/sqW
HCpUZ/NB5GhbauoUkB+TzFlGjQXZktYqziAIMKV5q4AzEE8pKBClvWMYAt7EXw2AecuOHNry/cYU
WPcTC+p7hMxuX5uZOtD6VL26UrCGaWjlnwgjBeAOwhh1Wgc4hiUTyRfbCarIG/8AsiPxufXNzOjr
t3TmvmJzAFZwt3UY5Kot8JBrFOP1KxVbHlIe5XRduPiEtSU880SqgXNHmClald3cpd1hApXcZkmH
SXp+4RmHduwnbF2UwvJXB0jZpnUoE0WJee4hUx46Yf4WFuNh8xeX3my4wPHuXPAMB8mArQF2ZsKy
BaAtIkGFaaPk7hikLwhe4IdSptsrj8Q9bVrXvA+4gbTha0PuVLLSXm8nFcQPmX5Jq8cIgWvwD8Qv
xg1pR4M5mY53vZXm4DLgh9Bn9RGGYF3s69rHHxDwjVAH+zXCFZl7h7tNp5plvkylBXxdR7WFb8LH
q2k4q5a0dE0UIMek12XGGlBTqoMZehq2saISQsuu35qGgMUNWFC454Dg1gNxxeyt0z4hNQlO45U6
glAKkOKKl80XzyWJ8wQCiJfKiHtAsMsDIdYhccaWfqJZHRNZ2sNWDWeH/wBUGlMVVb4JnmRq85v9
Q1AUlIvNOiV3uNJvxsY2IgfAEokOORvF+mW9ULB9PxEAqm9ivfUbJuoHPXufZyOeMiXnUPfuF4Lk
F+D+ohFNUSlL/uKPIun5cQIG/Wu3YhsXeayrCVRGgFr4goBcLunIlhe3pwzyac/5uoLVytH0cStK
WMPgBOKw8pY4IIxlB4vuoCY1BX0qEsTBAL6H6jACW5w+ZsmblgeYquwHLXXMa+eApPXvid5twDid
zha9f/MYLzQr8wNaMVMOo4thWF139LKOqnA+CFSW7zk8+ruA8K1XeAhdSI/azhb6llCGbFDZmxSq
piFBWyxHg8TReWPNfPmV7IWA7RopwnXcZ002Rqjp4agqhZO75j3Cj2T1O8w2hv8A+xAVlPbIm8ob
GETw7eGwEdMplcZHYFAtrvJewLY8bCqNlnxFKgPNmzPA/CXIl1Ttbm4x1XM91NBZMB+0HJAEiWUA
il80ZwjgditByQuBsGaYy+YFbzCyzYAPknaj8zCp+IzUavzHByrxDUp6gpdQirltfcqih6uVUvJC
lh8QKtv+pAVEEasLZxhBqeZe0L3K9wsK5DDS7IuxeEuYtcJaUEb8bKGLAV8y8QqpYpYDzK92Aae4
SDYQqqIyh3RZ1zLJOKYG6JqxSvoqepTehKOgIdEtfsfmfYAh7BKUKogJVxj1Vl5KPwrYkqhZDGaH
BL0AGAWNID8XKrzAsO5dSkXM8gjPuGTki+yiLQ0oI64wEHIBksR1YfN9QKGqErcrOYhjzlzA9/UK
ysuYennAFoVRBYxp/EekacV9w8SvEKvkn1DuGuX4i6WWJXixG/cAAahpQU36h4Rqu4AqQR4wBjAr
+5gq4H8SgMDBc1FPzK4Ls2HHDUVu0lFjcHpXzO05hiVHdSXQOm5ZdVKDeyXQwzYAgYH6mG5XuJLB
az5lAFAuFGhsr9HtBbWgAn3A3icRj0xYBOQJb2eYDfhQwZluv1cXhqB+Jwf7Hxigl83eRCxhX+St
vk8TKoKrhYjgE+SLcAILFMV6qor42d3il/mJhGsqouVLIOzgliGgB+JSS3A+pQw8d82EB+F3PFZG
rbiHuKAq34/qMpZrxAdAEB7iAGDHEHyxB7/+ETrase17F4KEPjJcnc3oLnXCPEv/ALBUDFC9UAji
D1cNEsVHR/2paGq18Xx9TnMEHeQEMVnRUQmcE7pi0laviriUO8JV8xeQqJ5KuIFezZx5IVUYq6x8
/MYHaJHPhD4GlHDhHLLwAt/8mdoF5dwMhXFVK8wu6kT+4NU+Fs/UR1EgPV3/AGzeybV4KiAlJRZc
YnoD9kcs0T9w6AAWeonmgXJ5l4aDiza/2U8hyN7i3KRz0cErzKlIp99wbIIBbKVPOMj3CgmTwdrT
uAcpkhUe7gOW4vmrR0SL2sugRni6muV2yzQIr1HYsa9uys9FF/MNJc6UUINLAHvlmSVQ43qo73a1
fxf9xSb24pHar8QWrML7pixUt78Si95ERogkUWDmrjv5cnWkMjpPi1S/qCFsCvpiSVpqXsh+Pic2
Ff4qVx0yeAPEG1WFqu8c+JzfX9hig16Hn0xTW7Kpq+JcZXNb5CBX4Jau8vuFJAB2v3BEKYWUX1FW
VdpS2fxK9waF1pf6jTFGlQZwNAF2HAcxraNsIFxe4ZKAVVHf/JeMRcH3AZL7xD2lue163XRDBAAL
7voKjdo6+cU4rrYo5r9wuFFcK2ruI/2MVhdkoDcvuYHGN6BWV/2Ms61FgI29kePGSoINRzQf9gdl
NgKKsPqErBbNeVHY+cibutVVeWUxIUhPmbZAgLVbN8TGN9KdNTSiAqqtlxaR0VLqF/0d1xSvzK3/
AIBqBp749vMZGWp+6I7lorPF4WxdvLzh/sbdXUHWUKgb+I3vhKctoyyo8A36JgafkeUIQRB9O1xn
bFba54uC2yvcZa4QUDhqbOl4nYc9xVXZscrj7Y5v5mDR7xqEq9TzBrkF0cQLRdfENW73iYHww3Dq
tpgwpuon+lxIwiiVPv8A5HKJxNgAsGVAfbVj0XNqtcr4jdLtr1EfRVPuPa2Z5jOqbL52EsQBEIt5
k9sVetBfgR2AaKeyYxoFAgpq0Img8QsdxqCIiwu28TFuS5S8nI0viFrvGNs5SiYCIXguCEO4PGS6
lShUrtJh9QQRThioq2dRcUsA8xsjnzDbgqbLAbDVagNjFYzZanUlFqpCHcG14iKSB1Ctbrr8rHSK
c+IqA2dMBNBVvpiipQHPUSCWoa1bEsbQIcR2X5mzI0VGAwfmDbPk4JSO2dRjFcDGRAOrlkRpc0MA
1cOyU23MaR1NtBYHiaJb3YDqE8MIHlWMsAgbpgSDYkULnIC2mfErNHJuUUrxzCGqXkMhB2uH9UnM
t1vjkoBYOWXUDfFxKgkrJdEFIgunKO+pShTmRrGkSgNSxiNEgICC2LItDDNw9zDHbzkt1wPcxLvA
y8wo4IZlWDZV7dMlHaTqGXnW7gYYl0/EBKOPuXNXnGFl8pejF0t8S5JTKnDgsi87HwNUEp5Xolq3
V8vewSONuJRLOIsaLaeYHKzgwtIWqviWg4VEdWruWyx36lfdiYHMXlB6YMJGDbF41rZYE6n3KnTY
RZWvUdnYK+rglRzRjJMBKVUKEnGsb3rj/JQgioe4Hrj/AFFpsEPRdwc9Sh68Qn7FKcWM7pVrGqnT
vriFispXhiMZvX1Kih2X4iwGBX6in5Ihbd+I5Gpw5lM8APxKbadfOMytS+BsyUXMwL2pyC6tQ2wF
vyf8hMcJxv5nIbVt62WDbt+X/ItHrPa6j9eJlQmKKGHd/wDYjAojXKdI2Tv5kqGqaW9HxZFoVXar
4TfaKThf/ss7VtMfaFkW2q48y9KAYTd/5HEpMAvm2WJkQXbx6JjWULh5uXJjIPtUN8B5qpFfIuZd
/wDYIBQqbTVTPW69LvuJlZBVacInIA26vmIwL1ygIpLQY0cVCzThqzLr+o3d4WtAh0idIPEuZ1ZF
B03GDu1eeYbgvy5A/wCx2aEqZFOfiJKyHNj1K1ui5V8wLPQ20fEQAyo43q4XHUjxy/3KIC0X4uFf
o1PKgYFKRXQrzcJVeHG+2GBKa7NKJumu2q1a/mIs0IIVByKQDNWUsANnN6SlQKjfDABaL9QXJ4Vx
T/ssRkuHDuzXLADZSUJwZdP+xErBD6Y66Xod3sFpYWWaHZsaoiuiscME0Vdv+xIYqfE1VoDjEA1I
CwBxHGK6KAGcbo4+uYlSLQq9cMypsHte42u2mRWstCWdVLAV8Tg6qUxquBfZELhS1WjvmXMVZh+V
Y0uRrlDGZGur4jWkIWOVnHzM8AelqUbviDznmJnTyDq/PEuvydM1nzsbVbZ+VWfqX28LGFPpNVtc
1GI3OTR7QXYVSqLv2QaEC25Xi2o5PkQapkJYIgAvQyGiYcODh7j7yLd1bDEryw0vEvOVatGMROr0
Kh7hVYqFqP8AcrLxUWNT+YUr1FSgcfUSiCElq9+JbX1o2tEFm5hCtvGUPURpE8vqXGQhA3UF+M5h
DMDN1d3HahWQlY04biklqWwXPFgIcfcWnvZQOC4gBZLjnIeRkXiB4uWmG9y7Jv3XqIsWTjBt7gOL
4DWFMFyUekSLSsNw+QlhoBzYpnVSzvgiZQWkMpjIVlN+2XRQ5cQqWpQoDiUu2tqJTb5mvz8kaBzj
Qh1KxwkOkIcC9SzCju0R8hXfEBvY3dfiUeyIYXOoqOBLaPebfLEAqFnMKjRL1JWTm9Es8MMy5LZ1
AlgfcH0OoA/RLEeCAlmhjwj4KmSAKS5iFmckR0ZV4kS7LyPpEMVnVVERVQA4YkJoqlMy4a2IuM6o
e6KEVBPR1FSnp1HdNYUJlB8sUOKFtikYDkY/MqUOJcBuWBTsJvkPVQtrbE4lLZW3RL5CrbdlpjWI
8/ETLcxfJxEKcFj3OBt09wQCWkvk7uF7Nt8IeAhvSKXXZwltpGVV+yUlguGHk42aP8jkWmO2wOxS
YrScRcGqrM1zEiWwOEqF6ujUFCauuLgBEBAXYcKuY02H7G7DOJyl6ZelC6HiWQKJQ7BVtHnyliyG
XrEIZWUJd3WlxEoAbPcoVR05jO7MoMyQKrsTxo1UoaPidWYa6h0zO+JmAIahOBeqHq47G2wRdiaC
jGWXz2ShPdWXVSiMC7rdRIfNUeIlkIUpV/EvbqtsRU5Xhe4/XVWut8sR5oNKslXGnUZKHgLS567Q
0KiNTCiDsSNXgjx7lY7KND7g9DkE3/MrbQ3TfEdKBs8hgFbLaLcvGNgLI7C2DrZbaJ7J9y64JmA/
EP6xA87KZJARVUsU9ANxNL1HBiMSFWYylk2lAn1EbyhEMq3KWNL0epQqlpXUthBl4RcmqI0y+fqM
w8nY9sVEvlbTDlkIJTvcHnSFmz3Gyiauw62hs5LnqekLQHGUHXLCWlbq21WH6ls4HclvEzARUzUi
XFv1GgIw8k63AqjeHTGWox2A9IcSo4EBS40e6g4IMt34h+VZVFr+ZdgSDRZHRrzDYFtp+Y6RiFAh
BsEYEqM7EqHC3n7lk3mrhsANOjRf3DPJpCQ/MAaLYftC+wgrooPeMMCUllp9kvy5pdviiYujkH7l
w0jaDkWylUhuviVBXRtAeJYUeUAPuABHC0WuGuo5YhbYnh6imKBB5WygypYAwgRVSNlBWfqM5bAV
BhZAsQW/MNsUAK16+InuOHA289y4lXRz7K3ADNhdbzL0lCq1fcTEA2sJYp+TmObqr8v5h3lSzWw8
RnCWsOF6+IMJfLpYKWQ4MiP0bhFjfiASZOufF3t+YbuhBm/cVzBcX0w3iUcWpzXucUUSfO3OlbCp
+EjxSqH34m+1FjgZLVWO67OILsPJ+IyhimrMLf8AzCawa6jU0paUpfD6hDcdoKKvSMAF5ppldOI6
rLa8M5S0wEvG9QiEtEofqXxHLvnuJFjlc9A9y2f0vyMnEDA3DxlEfqBYXU4uBU8o1TneTnUJ0F3U
VOuwdXzDuArmn4iVclWH9IAOwJ8DgfU51HpQfEs/L6q+biS5TyZR8DMPuPt/qahRFHj8xWgiaIJ6
YsdO/R4ltY0204lI9DgcZ3AmnKrV+rZUCaIHyVUcpDnBT8xkpBVaVjwKylX3EpbYgMhi43h7KyWW
oPxF0pbEshAWuK39xTmyKi5ekt/6g6h298Kv5jDPCrmx2CtEI3fffSTs9/VD1GNYrFKq5QJAw7o4
gPa07D8kYhGi88jxLDU4LmMI7aW0oALrSnFX4mcfC6GGJkeAcGeIBVw2IHBsQ123GwR4uKRDiVDU
vyEMsityyHJ/iXw4JnqWFB6VKEDOJWNvPBLYHPTCxuvJcHwK4WHSABofcFbb22oYVc3WVrgAWtOo
KGBQcP8AkrQe7ULglq8diKflgqU8flt5DIg0qNfmLFwYpFlzuHsKl5HShFD8zUnYB5i6gCqDUXLd
YrlzmcaBgai3dWXpl6jpEuvEEJWnEECLwCWZh7pLQ1vAOYKKj7gKte4YF/1GRZ9zHCiXL266hdj7
lo2jfMHAOPgqXCrwMpC93EgOdHFl3K80qy2KXm3Msm5CPHuVxxU+UvgtzuRLh4tnRTzWEZa6pQS4
9BDXOnxFAj94eGpaDi4lWngdIgZffPMDCFU85AVau7LKIptpXU4Wpw6sC3tw1RANmARh7tcpzL2W
EQXb83HGXqG1tzclEReFlFI4LyCUwdU3MsDzDoJeopuPAqqh4VyYUxHVmNZ7eD4n0CWLDl3vthhI
6Uiakr/4ISld57lJK2Iiabqq9HzsB3tzbA0qnsYMADOUTWh5o5l2RWKlA3mJ6f0xRe07PGtfEEsx
ajUuXxGrflVMGIDflEzeZUMlqr5uHC3W1U0oikuyClc9up0gdOYIDU+yVmn25it0jtPMqB3Atyzv
fZ+4dDXnYmZ9F0mvRyXBAht8sdPZEUQgnCoPioWUVmy5fyFVB0aagXQQxWdK8xwHSKXhv1gtb5W3
LGf7CvTsKgiKeYtzbe1jlpcKEo5Xpla6zGK14v8AMuIJ0JUzq1zbB8BUEoVwKVApYvl8QSdPykAH
oRkVHyaxKm1rgjhW0cR0ggQrFwmiltFXK6zDkiKdWnpUKk6dLn3GowpynMbSlRLUfiJbjtrNb6N2
Htc6lER2Onbq5UA7HbRmnvFrr4jQ5A+YBKPLsl++l7xat17jLoNedh1CvFOHxA2M15eYi35B1FiH
8OfzKghfZ2DVsng6hEBsPPmPM1ejsdbhXU5i7lnNkqABXxKLB1XFwlFombLmfwpyha8nUstVHiK1
j2RCbIZfUGbMvsnMDbzszxttJcrdBrmsgtEnLXHjuNTj8MZu08Mbr+r4qBQovCdQfUXzcxpqdsLN
7OwIVAh8wxSqPFxemr3GI6kSAZ8wm2F8kBsA/CWBtfNMpuniKO8ANuPMMMazYFRD0mM1rqcL4a4l
cxKcvJCnG05uM9v1kpHUQbV9QoF1fbsQNrxGwW2EJyOYV77nLC3vYIx2ACXvcsHTNw/MQ447i759
xxXZGUELEFNt7l7FtYqyhPDle4EAxi+h1KTusad71E9al6jZcOcPzCkVx0ywxqL1pdSPEosv/Ywm
PSUnP4lA/umBfbMUd7iMnZfyxhZAqqxHl9ywWr5mxLNrM52IDdEUq2ooStwVXxFOt+EvoY9RN34n
oMdW3rlRuhweYTQRiGvB1GRIC+EsOyvUUbyxbWN+WMAm3IHS7PiISVXxLxE13CnGhYTyhIeqINQj
I8hApd78viCQwDIYXQY6gQEBtSrahQRS1Q8816Qf4VKDiUIyYCMzqMqLl1aE4uPQUPHqYtODysAc
PaudIltYxa5+Z3A8RXYGtp7INENPO9qcIYao5lpHKG+ka2DCjYw72rmaRP1L6vnSBXj0VLwu+pUq
gjIop2x1aNd3CKdeYanJxFa6FqEaJ3bSYVFatSrHHiXZ0O4aEuxOJbKgFeDYolVFA8R1BRqiEdqk
8Tn7h4QogLIOZTF9kOqhQsX3FabJU535RIAVghk1xNLKoWU+I4EohYEnfUaKz6gNlUNNjjIfE+DY
ytCeYeHehZKqvIamoXquI5SVumWRSxRRyxQdicqn2zaOl83CWqpiGrwhbduy5HAROhcq4b5iBcRA
AwLszmXCFlrNolXHccB3Ai844lREUUe5SilI8kUzzBHJZ1N+Bjb+kTxV1EtbS/MElTBXWiIbGnjY
pXCKVe+mMQfiKhZwnkMeh5ivmrm88+IAW2JNRCg24wC6c3AV3dy1Dk52FlZc6S2XdmRZosmQ5uWL
l0S2t4ZcWqIgDjhgrF2MDJ9phAqiDED5R+BeI5WMe4wJDc0vd8x5SWSnCwuUbhyQWwqywMihoO/E
FCm72F15ZFWISqwL1GBQU1s8zIoM5hvuq6ZjrtliwEdrxF3gUxSxvp4itqF8Sm7hCSWsYaQsingK
iINPxKsxfM4p9RFjIPsDBsoC9loVZFaeYIphHE5SWlZXASk8iLYowHyY7wfcbQUTuX35EaXAQNNK
SxqiCgxqqrg1BCu6iFbqAjbKYo+WNS8Y+b3GyrfNxNRv0drAJkQav8RQuc+Ykpqp0XMsJvqNDuyK
vULgAcEaHl/MRAGPwKs2YNXiWYoYWeUlitB77mivmOkLhtVg1LhIVZObiOYg4i+31Hk3zF4m5gAQ
yOXzBTN5siGOIloNRsc9XMlpZHQDTArVOziUqNanjuJqcxGLIPJksLYcfHmcI4qNV1ZEQsWV7uBo
DDxKmjY9gEDnh14jYeSaMRI2RUdLjS2+Y3KNvYNK4YzXsh4MocaiCuvMEqS7IVIu+ouhzcuAtFnM
QK0pna+YGd+2Xi7OgtJbV5fEuC0Cg1Xkmjm4yvceC8eoguc//BQV9N+Ys51aQhRlnPiIpZ9iCVOq
UtFEq/XiCWgs5/5DWqqK5rGA3kB7VGcbavgXSxcjoHn3D6lh02PE8hKF5c5eYVDiLB6gzzZbxc59
JcorJXx1DgG9/EoELrzxFTigB0MIt4tcrqZuoFMh9iCpQj9y4Lu3mE3oXMfKGyE2zuCvaKO5UYoa
9eZfo34m5CvcBcQu51LvH4Zco8t5jHkLsinkF6gItX8RFqZLUhoT3DxxDUlqDXmhh4qmqcx0hvx1
cttVV7aIaLgVGUBbK8+Y9/ItysDHqpbyWoquJb1uxBdl0e+Je6lsLOHiG/kqbDjY+RgN/MwILfLA
gy3RMMnYHyhZTqE/TuUpUIeoNPgD8XK/XjqO6ZXCFWJRxOYBtOoDwVcQUI9HMVFW8VxBAUISrUqK
gwO5BcKU156h4Gyr1CcEF4lCs2YP4qacLvmXRQjqVT6lqpKllglOQi3cor7I3BxlAeziLspgsoXX
MrHiGdTQpBtRcGBaqVWrtiHSzzBC3TODUfU4DPM5IF7LDUhap7l3KBW6A8zrXBzKYF1ATZ8QS3zG
54IZHh5i8S5QAlwprPlMvoiJZzfuIIDIO3Wy2nHiKl6uU8fYjFyBoRTGMq/cVDbYAdluCiW7fMc0
nEF2lPlniOXagDrBYqrQRoCEVDGXGoIHxFK2kwt3uxNcHuKAYGRKqY9y7fHzGwLfUFH5IK+S3JRD
uuYKy/FTABgDkt8S9viAK8zYVbNqYmS1+/cb2fmo7K48Ma6fEq1p3mVTDt7LhZsrZyo3z3iaE2Wy
DJqh1ChSLwot+Z6hUAKfMS5WHmWPDGQjVeR0Mr3G1eybhE01b7gA3ucGk2Xl18xFoUtcQI6VFawE
BVy73FxivCBTpguD7m7Wj1AsnB5liR09TDQyCDzzGhyJVoolm21KUwL7nCjLImhKBg2rllFLniob
EllGoBdlMABw3FOdWV0ZFDw+o82XbkZFQYAoX4RO0uUa05GKwiRPMba58k3dl+4LhY3reS4sNO4q
KcYJa9iMLSanCpoWWRF0RXWRgaMqZbrzcNp+oAoEQXiQLxxEEwZwnzcdOdjpVEsSuHzHnYeJcLxl
VriHK66il7uwdRiKFV4Yi+bAcaTJOfzGk4RSUZAaJRLljHtVc4si80LsKwiW1owgqsuUClLcsbxF
XV01UQ2rYOTLZVdTO5fpgkClOzvYYor5RvPFeZVUqDPhrnqbkKaEJUFHFSr2BjEthuldWsQN/Nie
HAfPcGp+wv3Bt9RbORS7qo2YpKHXM14zzxFCipuupaWti/uUZKW31DSBXUQjV8tioaVWjliYTmut
S/oK3KOyqoQW3dwQiuHZH0pTTtMGTwX5mxNhQIDb4uXVAKahNQPGkwJ2NJCgKXB8wGWUDPmO6iSs
wVbfiU0OR9sW3AQTaTZ8JF5LPCuoTBBy8xvfQB9zjKc04leJVVpA3rTiH8BQVLMYW+r/AOQiryNS
tAA7zmAIhVNHyiIaN/EsTsL5IWx+I5UfEF2hsfErBUljxfcObNIzPweWNiLG6ziCUdvGABPcu4l3
jxKwAFdR1c9KJSzFNqEiLHAToeGcytQgs2J0AwcVR4iMDYCJxd31sCCradPU5tHBkdrP7lxrUFFH
4hRQ7GEVuoNl3b1AqYo4icBkQKebjRLQuk4gFWRrBISYx7iZTdRaqKtN31Gpzcz1p5QAaq5WzyiC
OiacUnmUeddJKbxd83CuvGK3LxEsuz1ALemcT9SyGrmrYhdWVOcNy6B54thenbJZXy8sAasIJJhB
4UhEqoOmnepsBu/MToF8MyOD1LIPEpHLe5ezjqNV7qNsvmFRZsY65SIabLG74jS2VcqnMYPVXbAe
IURdKx8QqTdQ7jlLx8F1K9FUlVZx4YUdDfEvhwXiaBrUVLcYhKpjsn3NWhUGwZNR4WF2DlTgov3C
A9TlTt2ITOZcMFwthZRqX0dxDF0y1SjqyVR9QUG/MS4MeYdFD6nG6I4qxE+YjrZ5IHJx5iFzCCHA
m6UpQKYBgN9SjxSdwprkQQnHqcMxC1gPHzGNLR3cQ1JhCq7a+Jgoq+5l9epYJwSxcVzz7gHCyFou
oGSr8s4DEVJfj1LlFKJrgJbGV8zQGBGV3R5JYVpzuW2SmAXBPcLbEDyY5cHybPcQo8JMyqOnFVCV
cX5jYgFX5QVfXTG3VUUTQnCqoQtkoYKjxyMoE/M8VMqeKjUDmK4NRoKfbEpXnag2eozrnxG0Rg0H
j1KUGUtSyausQolK9wA5WQiYuirAiYW5U6X1N/rmAcMWtY6OaVDzlEBorgsWkVOh5yBouPMposTG
IEeVl/h6jikZLriCNuUyG8nPcHCPQUIjVRS2IZAeS/cQWmlbfEtQyUr4g77glxnmWLf/AIdCuzNl
xtT7l1N12iBWh7jE0pJYNaeUTwB6l9QOzN+2LvY/gJL8po7xTi2CEsd9ZKnPVmEkx5EvU0x3BWo0
yUUjqmKk5FuOv8lgp5LqWtLT6Bf+R1OOfXEOPygvYFA0FeXOhm0PJNML6v8AMV2z0xXgpzPxdn/9
kGgUsrxLC0Va5nJg4ty+/wBajV0X0QIeSnZau16u1c2er6YC6qoQ8cos5g+F+ZdUy+4JYlL9kMhq
A9y4dTE++IvHoaaVC7gBhEtG2UwkrHFvqETlqGJu1Yerf9hJNdr9QqDavb/2RuFWq3VXKUPNXxGF
UF8MhUVaZkdPUrNiSmtXi5iAWa9Tc6g52BRwMtSacvBKhJLrGFg1ICxjwKUSW+6lMyrsQLKRCNNX
DwC44V3K4aBVxCNzElsKvEB/Bxww0YA+hcVCGQleIGNhbO47QX6iC9UzhfiFqV9yi2AvUHaO29zU
+uolCnwZZTlEChnAe50VRUVvzFs5fGQvY78y4VzF3C2MC8ys31AFLnRGzTvmBfGRKcJVgPPmX8C7
EKOQwHXlgNnKzqDlQlA1ltlN4lw/uCFoo4qAiyti40xFEHgsbDMlWwa+JbXEdwOo4U2oq9/cJC98
QLoV1OTfoeJTRf6nJCsl0UcET02WKPcxxl9MKcSr2+iaEsqU6HDY1AtHcAFOQC1/JLhCWy1mioBK
bH9RH3fUbRBUDysdOT5luKhi66PuXG9+Iul/iU0U1XmfxVxItWy5QZtU0RaHbIDL8RarV3HSU08S
wJhBMoyEaawY9FxhhA0GPcuGiiFMO+oCXcNBuROXGFg3CrsxALBlgDa/qCoflGFZHjhiOu4N2u+W
XtDc0gY+oIV5ijVZCIFe4rHOS9K/EeEUErNM5gLKvwwtY8QaEH3CCAb8Re9H8QaXWHZzEtcHGzgd
R91+mP8ACWvp6uKhx+JYRw8wQa2R5v4RU2V1DZpkFbvnqAp5JjdhRUG6lvUGNJ+IlI4+4GMuAFtg
mx3rzOJX4lVDrLtLUWUydmBxdEAoDfM0rsiZR1Ozz1D4WxxTmL5/qdl7Esb1DfY6gQnEsJ4jVGPK
CvcW5enTMcoQS3oJoX3BLXzGhYRbLOPcatps4QceZ3wQBB9wrCQFaRkI0eILd4nmZxCl8oq2leoc
hkY4aPFyvLaxSi904IcC+JQSMVgMdCv4jG3Z6gAIrUORq2oQbfMUkTWHzAnIqtP/AMKkug4CmM1d
X8wkoB1LCEf4RrWAOyUd8XzLUaTkiFnCs45D0JbTRKXt1GZx1dFxqioRJsHZCAORcQjVoU+72ABq
ovlEDCDskubLsDYtrKFPbOjaApfEJqOc+3+y1wCG8ynIAv8AGwoodWJXu4kW+c/qK2y3Moqvaci8
PZHmUBecuANvcsiLU3wlhk1cjeRSGi9dPqYr1zwmVxdVRFqjS3JcEUtXV8ylp8VeIs05BBVPDFdd
MtREHkYzgA51G8EPjNiZWDSDmHwXG9fiYSjumS/Oq9Bf7hD1qEOdwjTUUcgIZDldiUqBeY7hD2Pc
PAI5E/2KpHtyRqW3lwKQ31BGmTkjwDxBcGjlb9x+Imk4wqjV0aES1WjVpvSF7sqiypwV2wRHgWF/
EcHQK4tKQxhaETEolxFW23UMbExAYWLmQL9Qsyy8JHrQcAKfu4WM6hvYypbbvL1K8AKVyRulp4WJ
L7zsXRjHewQSip3kGNC7cQK45bmZYzgi0Zr1CO71HsLIrlHxOA8kcaG+paNh1AwoVtR7xJi5dQc5
NFDzUIvB4Zt1W+ZnYt8yyiQY5HqINo+pabz5iO5Qt1FVqrxKKClxEU8cTRo+pZD5RrtQ3Qq924qU
Umr9x6ZJwaz1BdbpnFF35ZaKGSsHMzE3wzjUBOg3iDLGocVWwt0tfZ1AkOHhjIKH3KkU4gW183Ku
rWkLttV4mFA/E6b91HjYBCZDal0JjC7dX6gC058xuiql3gkFU4ncFHQZegIhB3fBmDV9xLyPjZwh
SMQrnzcalqEXMT4kGJaVyGIGzLXKS0jXqdyYhpWEQn0iAsB4GXpKYXvWDbTYdHE8wacL7goAQ9xB
OXuUPqGic+IjRQgdFzbwRKr5Rku4JbRIvrZGq5XqIsBXhBZEE1WNaxvqIPZ4pgBcnFwTMEgjWXDY
8L4iLQ47mWSGrUWKW72IQCAHRxB0GvuCh8U4I9+MtJdw4iPgZsHEqLr5YwOx5ZablP2j+pjTOfmN
jS26yMEAD3CLxxHtY9QoKj4lIw5sJR6L1LEU84TCb+EVNY1mWMsVeR9jI2Ub3HR1CJ/kHl5nEDPM
BVmvxH3BDjTsRaHPklV2CqoK8wtXlCKjzC2SgB1xL2pUohpojFpzcx3X1ElbzDplyiVrBcJqLXEK
acy2tV8xbn8QxmlJVdGTTsYCc4QKsbDU4gBeS4ACqPEu2+CryXFVwUXUKzb+ZzGoVXR4ghl0xW50
6iApUL2JS3yQHCY9wLbeZZZ7qUGHPUql8FzFXEciUeZRNUSj19wBVcn2hWVu4gbFDi4bJp/iDtpH
VuCuWbjvhemMsKvsjte7qCx11MMs5SyHW8wuPnW2xLIDABq2MqFCiwUidmpa2SrVuVW5RxeQuQyh
XY5F2Iyht+blvGXIRhV7trEtRCwQ62glnHdfAqo9lPa+IktcXka8E7JZAPQkDg1O2LJudi3cBBui
GWffrlxN6Bpx8S768rFfYtp8YnJHiy9pTcWe2cyxCDLFfkWoqtYsrq90LjR5wWsQpQOJiFBxxKYg
QJglBEQofKyhXB2p1LARnzGxIsVSoCGS+XI1cbVqJ+IAQDbLFDg6pDgfBkMAukqkNaKLhXNvSjmE
hbOSmImU2hLQS5Vk9hBBi4Sh4rX8xVQOz/I/fgEXCNgL4gFTlplAcA2fqH9Zimj9SxZ2QvPRH9wd
FmfiIrUbmMu8zhS1KTyKtOZcAFxqbOUcxng/ERoyKgm6F4l2Ml9wINI8VDFUeHUucVcQssW0EOJO
QqOGHtL7uaBBq5XyipZrcyBGlqCovovyQ5vXXSMKsZeIzVTyjI4Nr2JBBh8QkhTUDU/HL4RDthUB
6iNa2xmMx9x0ccJHRyo4NlVF3EyVK8wRcx6S0lxy1DFUcbxMYI81xPNQecvuZivCVxNg+ZYUfmCi
2fATV8niHg1KCJuhwsd3xXmKbcooRVweeXk13wZqTvj0c2AAAKcSttFhS8PXmAvB5PEW7Lb2Iinv
YiKjazVS8VUUJd1xLRaPU5FZMDs2p7qHNS5VepeEHSnajYHNczlKOBGyGi0sWGBkKUpsGDowgILl
sXmV3UVJyJhb9kKhtcsA1cK5PzHVG7ICi8dxBpfaowfkJYmCRcIwG1imYn5FRVoVPECy1dV3LmHD
ULZgpVY/UpTkqiPXEFcCFhS7yErUFfHcI5o+cghKUxK4RnzX1MV/RsrTS+GHgU1zFGiyoKElZdeD
GB2oq4nm8uVlSlArVvVxOlyWKbKu1GDWHwPM6V5EWEt4wqimLxTP6XKnGKbF9RCCvQlw0gX7ZTfW
Z9ymy/M52HgDYw0IUGBVQt6vgl9OjiDsSjC2pH4+ooBR3cKoX1HF3RfDywUL0tVD1Il3A8m42iPy
X3ZXEHQedgdxSe17/bkv7gjG58TtjsPDxLC4+ol1Y+IrEB4fcUw4PFQnScdkBu+CCHJkAoAymxqd
S2naic8iImrl0UyUh5uUAV2MvCx4hbiuIAKqC8x3F1RRFsyotdWxJ/KAHRkOiKXBDBnNwSUDO4Bo
hLF3vMACvMtyFp36lAXC4WQ03HYdMDojqnZLE1ZFOAuA8bnyb/U6W1BcrD9whaD1UCGqgvW5akUH
3Be1wCkFCKL4i3jCBd85l0ksKZlNERsFFzh9S2FMTRshfenBEF8b5i8VD9wO4P3OYVE48TRyCs8Q
DSCIELCtrouW6wfRDRwilepYIhKur5gjihJVQNFFfFKCpm3A07uinMa6peCpt62K7Ly6B3F3ASBd
jIYKsXC77l209pWDaM10nAhfHiICKLeReGBrTvmUFDXzFW3r5Iqq1/ccn0EqL5YFew8x4Xdy7DmU
IdpyTMmlJ8wNRsVdw7zK/iEW68SgdNMl0qXQdQW5tpCtUv7XDdAQ1OPMrihizFkcVwsJNQr/AGgO
06OJgeDxD8Ni67jClRxVQyX6IaahnNe4/VQWORKFYLgJLnVDmcWDsAlaqcjZ16ksr6RYA8bsuI6D
iEqgaogeWrYgt02+RjyKfAwYEFCsY1gwq4EoqkStuohD2tI/aBa1BbAeI6B2ZBYcGqYxRZVtEUGe
sCilWWVDzhopkNIeAji00Sb8Q3EBv0gyLoo2cbIyc7GgoOElujpQbB7TZBIPUAHUp3YseJrRfjcv
IplJAMGrnmNCBDovYuDozqkxbJT9QoAGkUQ6QxYcTjtqgMYjfY6hdaApLv1DupCqhD4MeoR0CmkV
eI67HcoGfYQpKi6OpTwjnPEGAFtJtNYI5qH3k1XUVJYCjk8sz2qYHF+YGvVyy0CQcQpdZzsLi+hX
ZTxAF4JRqe4I0LW17ieltqIBXID8tjPaQpfEXyolV+J08348RukLYbsQ5MgSwV4pfmYInHwgFd+U
ioWDsu44VV9Q6yVhWSg6DoUfEKlq6ph6AatdPzGByKdPxMWpauojqCIiK8Nhq2rWpsJBV59RSQe1
dVkrHdBdZBmgQG7ARn4B3KJIheRex8vEHolTUO4FW3u8RNK8+JUmlVLVLSyDC7PcvwOhUTkC1Ovc
cYZysCoyNHSd7hCkVLKGV+IPW5bxhrkbWeYFlUs8KgU/q9B4ZZm1fYe4kVrjwHmUYksKaR8lOGsq
rgkLlrplBevOmmXvVEDJSYrhiQz4JZEa6HY6RQt6Ja/VHpfMJgLl5iuQmdWzVwKw4bLn1I1ddqPu
MVaionzcsm9o5F6kUgKgbEE6y5UEdtREHAjkAVix8e5ZSEEC8ZZoCixD9gGhz5l0p92+B+pdTDzN
SDVtZXcFJqArbgyuhbtkceAreeoUTOgqu4CyE6CRpXAoHwRepjUvLyFbAsNF7m2VyIEMT2wKqmFv
SMj4Jngrw+yGWBchW4+ilqjpUKFfBOgo/c+toKc2yhbKtrONmNBKKX3EoyGhdMdKYQuRR8RqanxF
AAfUbWkvzLiNWyq3XMdax9wxG3HVopIinOcShXLyQhyqAbubWNHiao6lXMq+IHmnjl4iCiGux6W8
4gW1xzABxLEumuPMxRW+ZcNmxEFyKxjUGz9oBZukorTkBPZDYqaOZYFRxKA31DFrsvAvPFREiURd
pruBLYzqYE5hZRoJfQbKt9zg6JT6dQMPBcbP0irJdOdXuXWyjyQVrXC5alAVx7iQK/wmsOxBXjQd
2WCC1gwUB9VCrfaD2XaPy5HAo1qDjIYWuhvyinC7QeOoKyqyGWUxKGdgfIgmr/BGBVMXMj6XcX0U
CRtNeNzajpRaU/mMurnfHcbVDR8p1cStFR+0jHoar5hMjuAqvtMNHFxAV4wDLlOoht+keUb8aY5Z
ce+KnWLY2PihfzC9wLDsuWGkI3kBsfmEToSBRFHNVUeAOKOxrfHo5L6gDgxcRasF8yh9oD8wOSTE
ZGxs5Aqu9sEdK388wDy1eENEK+iUxq0F+kEKgFqIaIUBfcINERT5ldRSatpVErzDggxJyf5PACLb
zCTjvBqQkAVa1GuDwUEsxCrNjSW8ghtWqql7Fh/kvwwJFKVSuYVpAqoCBTUEfQ8QNV0DABk44iZp
ydtgA9+2IgqF6XmMLYbZEoBqp7WbMrg4WSwyO2y3wgPU0LkAeIv3Kg6rlQLBPDABKm4kAqxTZ0sN
qCkKw2FURHL8whNUr6lpq4SGxCrOUTkExUY4zbqUXDh5lvWgXfUbyjSNzNqhaU76mGiUzoxCUL/U
JfykqS1gFD9w9ZVD9wTa9v8AqZ4i26YCmV4gXZeDYpAeoestoPAQv0mVmNZH4hUMUy+YbNXzEHFr
3OhB59y5EEDkYXVtFd5Hicb87K1BOjeIZoYgQuUpdjmVubj4+InaE7imHEBpPcJHZtDCB1h6RErH
QBgs7CDYXZlYu/cGgJYFdyoDJrn7m+0j9PEdmqjU5W8R4CQruc/AZBqDN7VWXEepUHwQsDYAAv3L
3mXopUUlLWiaf7HhxkwJbVsKT+CJBgoAury4l50MVRLgN0UOjCsapLFuL9QRTh2LKuQuPxKekoJ7
uYokAKJZnwowm1Ma1SryVJ1DJK3n6iF2SDOYfyUgjigsKgPCWxN8pQLCukaaLKijcYMB5YUxc5en
ABfr1GCxCjk53A9HaB3zcJgJ0wREjb6TGVs2qclQKtKF29kKWrNDXtg0UFGubcBUrcqFeNavTU1U
u6vMTkqgYeX52U1eAzmi/wCYL9qxF6jG0hy/SAHK7CEFIWAU7jZPCAB4gLeEG+X5ite6eLjTdsFH
ZWRQKUgu5xqtDQfmM6dASFjuZaHE0auA3DOnviLPSgYWS+2li/Bf9TIgCq02ZEChn+pqpi9l+/iW
2JUz6IYQwvEcsys3wPTB3UguVbPkw7gsm6oIeYuTTbx8zAEc7lb0K4jYXfEW+5YYNkDSL+SKwCpq
mlGmJQd9xwVxFNGiBloGlHMHs6gsywjZXDKGcl7BBO0BTgdRPy9xtOPcw1rqUV3SJChfuNMfzKqg
3Ku5Ev5gcIbWaPUo8E3XMaHGeIuilEZbSuqmIs5hZ6BBDvEalEI6dVLx1UBAA+2AiPM5NIEteRcx
37RXV3FOsgt4zlN5Y0Oq9S0B5uIOukqKxLv9f/ggro4xMz6XAilJ4mOwbzMk5+IkpQ4ZgSKvScrs
2nSw9tb+ovYyjcQ21IwNGwdemXExerONTBUoLbgkf9HLh6pwqX88B4lGGhW+oAklLOkQYRX9BnPt
W30I4iyK8ktFFoNfESh4aqHW7MhsJGni43eK8wbazsVBC5tqdQJdsdHj3D/IjSV13Eh6axW5iO/M
JZydv1FoGwYzhMfC41m4lOepbELFXVGAFoPZ5gO4JZPLLdPcOx8ulcl6q+Zgg6R2cXjg7ZxxBpwT
u/KpURsbeYnNov0hmyxSMboRvxcK64NOpXXPhgnssAeoy3e2lcwaMOlVACY7ACy4D4tAA4IgcH/M
pgaiFtPUoVh2+PmJlZmMSg+a48MQKh+HypHvqjgljgHEfqm41XZUMxoXZ9sHRKP6w+fOiCoLFdEU
fwnMI4YN+poslyNJT7I5NFlR3NjsYlpXYL7hrjpU89oESnco3XYipaDhBzqhYvpK+mw0NBTEq6Ec
SqVTg4XmEArU6xGa9QyWFmaZW8zhxW8kltOlFdQLpUUHzEKUrfUcTywwTDleO40NsQs3fcP1CQOo
Yu00+yLWqnXWS/pjvzLSlSo8EUCrWfUuJE6rnmGO1Fb7iihaI7wtdQAaG+CBLxchDVXXMfYquJ3f
MdWniGJydR21rdligUeLYbxsT54hcgcvLsK4bC46alu6iHOtwog1svmcnH3EJ0WwuDFk0jFVRLUC
rE0I4F21gAKX958Uqn2w/Bqn+IcnLyMdRlvMAaKbHiN3q9fsI4GBZ4Qi6/n3dywRVyc9QJIgL6xO
lOE/EUT2XCZTqKFBsIAyveniNYE2C8QFtOY9IcjTu4ukEK+hX9x7oLevLLFHD95Chtr7yUE20BfU
FReI/ipRJAnXkuWFRXv/AOzkcgucNwp4oT3eP6YyYlpPN8RE9E+kRTZafuVXWWPGMssaui63/UAL
cxppJeEzrkhS1A8rUOUUmMu5du1ovB4hkC33JvsqMeEh1XLNgyqnA7b+iJKBZDdgGzcmqVg8Q/QG
VxH51RpoYMPJAqvvA/qWRXhRzxAIbcwIgKs10/cMVOynpOOJANL5YwSw6XceIQUWVfOwNwAqqwcf
mFcKblKoZCxFhyxMKptWjwRi3VgN1GrQ3xFYysmQ0eOMboItaqojYGpVu4uFIkG2xsNEu2tYUYLG
wp/UpCKSQWRyqcK/dQgd4F2EWi0Oe7Wv2S7JSUVYMuIMwLYw/Upx1fMQniKdZUYZ9T0F+YA9tjVU
XBVt2up5cS9bScwaHAgVBbxcuA/MNeNJUb6VBCWCPNzoB5hXY2svhXM8ljUHPiBetYuBawMSiXxD
RKF9RSFZMsqiXDQYLC8QB0pHSL2KHjBdKJEqJkBwZE9LPEou/HEEgAXCn0zXLPEyUHw8TlBC9LLg
MXOlQWwZ3svfD7hSWVt/UohdXE1hnM4IAXey90fqOCwuKlouC1xLQYaeTkgsFCu6mCwyAolAvPMo
vXCCHIbcbcAau+Sc6dgiDljywMAMD5i0h0exZv6KLPenEQKWhnay/Ba9mwlxEBAhi0nxGYJOC+5W
Atyggiw/xLfWaHHYTrFyrhNZLHVuMSlDB8nzF+lpV8QLCrQS7LsYWWW5dUuqiofKIoLxLUTZbRB8
RWLfUstcIFjqLZekqHwuH9yiiGpDV54uAbNvMvYUfDeoN9jOiLYF8BHAIC+KdqNpopQZ5zGw1uQl
wU5+4ChK7+ghlyRxMjLrOTYDmli/iIIPw2MQ4qrh14NmChFlUGpH8hGLEjefU+BC6gkIJlZcb2G6
hKixWRiicFJiwtLuUe7iuJc1hlPEQaKLrB+ZXl4rcsrqM0XhLGpSfqUsiXcKPDWRYFPKmKTyYRHx
CI1Cl5G9kOepdMqHNe5g4QJUdAJZK9dFAwRH0vwOQSXfM6yZQv6pQ9RHgpGrjNAmquKwS9Sgw6PM
xLQI4KHhGHMCbRzGWnVWYB0m1EWGXwJc1UjVPVSpt8nlURdEMial+CN9qNA5MyLoSz5hMBXruoBN
FFjzCpyOhDY2s7gbHiUh2grwXBEWReOpcuAO8tShfQB6PMUoYzPHXaLuqiWAF0aXsY7mi/Jz+Z0v
MKxTXFl3DczVZwg1wuYe1XNdqlGexUGVHuhbT4irofA6+YLbBqhxLTA2t74mL1IoLMriLcFfCCwK
pR0Kg8V77He1A3MIWHeFJ/s3vGuSdsuRu/UrODV3cFqA4efcKELF9DzCOq28LiKgFnZH3h4gIK5Z
oQslt5A9ygtiqsSoZO3dymwbdGo73DSCqIYOhqz8ylDALhzkVpc8AfmMcgqit4/yAP2MBmxARzVf
MLbWjTQpc1UoWruBEvkjBoG+aTIDKIjw8wjaABeYZdGljdhE6yC9lVAL5HRVpi+pTQNXAlS4oDHe
6uUv5lgxg6fuIIBalX42OXug0fKuoJSIU5bhQNaJLs2dgZym/wCQC9rvxkrfhCTxF954ghCBZ1AN
9SqpiSZfnYds4rIopaDlLzklIpIehcUNQICo25qoK5iwtYJTjYFn4RqgXTdFsL74XtTCNPlJuW52
Fduq6aeu/UTa+oOhcPvQ+R7lBY7yRitb375qE0hwXXj4lsyPC+U8wgYYZnzFFL4ZezOxhsm5yzo1
IrXg9SnOuqyXXiHsqC5ESua5X/5EbhoWW5cEjYFc51PUtCMXVkNX1BEgi2rvaPiAxfEYC1/5CXV7
nm9iEhbAAe1+YjBQVIVzzFINCNI4Wx+c7uiVWdyhRaoJXg7li2rV0v8AaBS7YUMrYgjmALbM7/MJ
F9wMiyCpyqme/EFRcqjZUT22EBy+ZVlMpNzxLi3u5gpmS1v9RAUyFWzDtjJSkuF5TxHDtH5CNxQ2
U1/ZLU8QWLwiSlaRW2FR1t5I3XohRU5vklAp+I5aN/M4AYRhVaDuWspuODdiqrq7uWc5VS8xrXcB
SrqIl5BFc1xBEBoiG/MLsllb+ZQa59x4nK5saHnjIpTzcFO9lvaI8NPMtAS84a1OiDw3SWZKeGCC
mcshBpkV8/8ASX4S+Xc0Fu+o4BfKhCyylJgOmAjsRPPi5U0RNopwoci5zLX7fxAjQHtb+p4Quifq
WsHxA8gRuo1CDdlrgWT3zcYuqWgTdln5HEBoRSbPuO3UT05UNV7Kjw9QtXUB0eOo4oq2aG3iV2LH
hlinEHQ3F4Dq1N1dqFUdhwXDxHWjD3EGqhelRfrQG6yWCL5WNlwFtuHdjaf2wPMKJ5gxtWepiMCs
tQgrs1ADLVpwty3wo0ZAcmCBOIF5p6hmJAaKLHDnEpi37lTDbO/3LdOGiAUdlC2SUmufIkalbqSz
c7KfqA6Ay6L9TlGrX+c4kHL3jgLeeRl08Tjk40dLf0lh7Bav4hjC5cfEYvldmAgKKLHJv+ZQiri+
kXEBcvoOMeoXiiO1hzMlefFLbMooVjX9x4S3HKM2BqtfUC3ipzKGE7EfuFbq+CByl48iG2hTAEFI
fCpl9M7UNUV+4AEpwVxsXIGpTnj6YlQfPR+bjvwEV7BP94XL7Yq4YEef3BRJ/wCrjKWhKbPjYNB4
Lp+Klzg6TPOfc8x88Kr2yn3HDaWnRzLAt1qqYGAh3KCXiqPsmb3c9GRoMUU7laUUFf8AI/ByRtE3
sbLWxeDbF8IKxZ/E5dCNGr2dmouKGzlhdtxJbQ0shiDlAHqVAi/6hA5qu4fZFuQFsQKV3AESBZin
E4ixwiw0bTejeY14xKsqYGBwc9w58PDtw0iaCOPxLsRst5gZldbrPqEmNuy7Jw4WVsWwpalP1GB4
AX1MmLqp99QMfhCYDzKEuUSIU2bqUrgbWwF67CArEE/CVSkSuFjElnRowgA6NFM2C8EVEOqkm0qf
BbG4OygEYH1mLZUci6Uqq5Wg8AMCjXKTP3srlIzktS0tZLY95BoGDcDXPJEQ0eVD8x3UAgh9kXHg
Q0ncAu8bFTLLC/udXrEH4yLgE9WD8xUtaxu4rB8x3xI9x7iul2LIS4TqEWFdtj+pWVWKG/8AIffF
bsIzAUTfzEIktCp9REvyvR5lYF8vBEAh5UL+4579Q3Ag7jxvcjiJgnwe4LoVuMosWCSiXJ0KhOGr
J+rj5VGxVSVBWcKcgEq8L19xUhBRXKPGW0kgODSnY+Ch1QLDVjsESiBHYftZtTyRRZ2Ba6YVSiF9
S1K/KDD3Z5f8mEg2ypLuGWoQWbmGP1K6vpV8e4bt71KPdShQa91NJ7wGJoh67RFu9O3ZQjXwCyza
1FlELJfALWJl51pxHjxWKv4gViBuutqHTK8M4BYcsuY2y5X2Q6QpqDSln5lpQ5jOKHzB01n7hqlV
XmIgEoI8DPnbuoIUK8gm6O+DZbngKFhlSkeYnQ3g1FvknCfMVKQSVTH2yiGWCNB1LEYCu4HCnzKA
s5lz5ieMLMRZ6uN3dVKYq7iiDhUsuAfESKFS14P7iQrmDMalhwWTXIEoPlruAAOZdbSJYqvmWeXI
KlcEdeXzNBm+ZRVp8s21cfxCHFmJpeozB4uYAcSnhiFkwhVRS9wRKfZhpl6weoCXCq2NpTDIWV2a
9oBp5jUti1DaGLLMixVC3JUB9EFDYWle5agji7KsEKaES8reo5h0N0OUtgodlBOIxL5Y8RF2KFG5
5iTmvgj5KAvtYiQUG63YAK9+DFANXuALSpR4SNleA8RoOodr4Z3TCWsO1xBOGSxaRsh0GrBIqzYC
XnxAfgvIg8/kN9xKRTo5gDEr6vcRnRRGNrweYiRvRxAcK5kW16DR8xdeh0heAzYobanCJVTIXTHs
gURpSzuDehtix8eu+Mg+qKo8SovRf+ETMDgJRB38oCRT8CegkuEBEvJDFU3i/wBwruB0cT4M7czq
cw2Nywc0xRaa+bhClN0tROY6SxgUVasP6lfasWkaLUOQqLBtQKulrIuRL0lpJXfSKCB1BXQt9ko1
sBeGQjF/Weuhc6swaISMlOYVAwocEoEKZZZEQrsSRMi6CN3FORVmy5fBmgjYIqC3o29S0dXDzh1H
PBI29OmBwTL2S2CqlTxpwmyyhocS8gaqHaXiKpC6WdGHQoVVcwRPiEbiwjiEglkLFyo7btWM5U8H
MsCuqRKqROuICRX7SppY7cRZUIngV8wxCAcXbLwe4og2BTDJYV6g0ie+YF0Hbqad7Ft9wptKNWL5
IwZvv9oiVLr2iYMb0dSldOd+IwRc7JQ0c2oliILhJw6UOmALyHqYKWNGrgrKUvZeuyniXXTmprse
2HSrt8sxs4OGISJvHn7hwioCy35nMk7Zn5ifpbRq/uLKM1cHqlxYyC6Ayk5lNeymZ+lviAG+wKUP
xA8e7kE5uPiRrSoWz64PDH64G5z/AHKAUAK18xwX5mAYs12uSpgZeKBK8p9GQpLEKAvmCLLxihbM
dhk0PCSvLDee5ozI4x7JcIpdAwAalGMeQpchAR1oW+CWDIEEKuuIIzDHXmckOhUs1JwCpiUq5+YL
CEg52CAToOMiSxLwhioV1RE0q8rU2lD6JYLQwRSrm7zEUdkLFRAOIDCqoHY5zxO36h5jg6OQaI42
lwDVlqPbiNkqEEnhQr/UaBe70S1O/IqJFpMNPfA1ccpgBxBaqnFHwS0SrJPyQEqC9MCCLXrG2u68
RsNPvknQbqrXOWoMbXxMNaOVohjSPashZ9oVPqXI7Cts72UgGzgPFx2AZwHNzPqvFThEoR+5eGGY
gG3Cf0eZH3DoQJQLbcCTGwLTZiQ5aOSyF8TyO61GhDbcX4lTYuHrynLN4OTcbqYw0GqF7jlNR3Pm
n1Nzvpw4yXRVqYPecTYke6HOu5qnKb0Od+YZ1na0FuM5K1VksXezJXGTGaG0iwt/UPgcRI3UwtR7
IKDRSK23WLeZWN2EB3YaY74joSrgCbZFWfgJqMLirmmDb0EG+iUaVfqKylS5fT4itirjU9EBUOYq
KXFTrR5g5CD4lNK9wArTEquPqaK2T1YplacqBfzmMaVfCIipF58Rwm+Ir2usZeueSdSmC2R8qA/K
U1bCU6gWKQOXcP8AI16l8Tn+U4ZhWctQjhtaPETazxzmKpg8siiLaj1xAM81wD4K2GBLfc0+kttK
uYy/gD58cMCZQUImL25nARqLaUhC6PoI31oqBZaiQZ+IWdgAuti7ZUVwVU3R8xYBAyvoql/kcvNi
aYNEhpKL3hm2QrzL4wSyc7C3dqF1A60uh44GD9GwocyvQA9S1QAHu7iohAuccQva9wks6PcPsqXX
GyzVnslLljhj+eFR3cBEFC64qVQLVWS0SF2cMRcA8BzLZ7LpEQALHHxS8+wipnTUQEC4DxAkPABT
MNn2jn5iGa7ddy3kTHLcWiFyVV+ouHUoVRDCiBxzsu4JvIvKV2hkZhRd8ROmBdVCYcatqGBSz0hv
UVL1G4qLBMGgvCbVlo52FcAtwuJJlSgyiVZwnfFwOq4LhoDV5JEke8SonsUWUcQrSToIk0NcRoCg
5qJVOk4CVFca4Der8QWDYKu4IgNxjbO0Ue8O91JayKWcyiCgUtl7AjZtIUTAzy9w4jlb9QlBrUpV
ypzfZZUQ+A7hjKTiKWdGLwgBVaJFdKrhmJs/3jNKV0qNJAUNzNh0oUsVH+MAzaRmTyqfEyBRxfcs
i33BXAwRKWh+OZRlqKKdVNXKNOaWCVQmKZdPDkVuBkBUBA+ts1U/mXgqPAbLGleFQG9jWgr5iSYO
yMRgwdLy01SiFrh/QToHzKwEBULjtrV0hhooX4j+D1EwNX3Gu+rbrxL1gosDFNUTiLQEFOSaJOC5
hNeMi7UJj4ZQAQtq0rqgUDiwdXLa1yXAC3QKfKViXyajsBWVWBUVZ3/5ULo8tHULxuAnj/zFTfvc
yAz4GH9SmQBfk/5BRO0pTdQzKuAarXNgY1HRlwbQkgYwdRurkh/5mRIs1wSlQMBfowhKPGIn1DCl
cI4fcu1MHR9wd3ixqHn/ALHzu2P1Dapd57jZgQV4GYjByAAqBFF2qitBrbpSr/EOalTe75lUpcXY
PDCzEvCDxAV8FW/8QSdOaZF2AWDIplxUB2UwKZ9QLtu0dCGk7LyB/UDXxVME5UD+gCgUsCc9uKGv
uXs8f9kREOVoIj4Obr/cZuICjcpDk+g/8y/KQOAXlAYGJwq5ZfPrF8BiCNY+gYZJ1lod3FDzHgVK
RpWgr1e5S8fALhyglBTnq+492iDN8sOsVNglrqKKr8BsotSiSh7I1Y22XCY6gDa9jGMqqitEBtvP
1LYN6BLR0QQ0Rs5BlnBqCwPcJUZ0EnLFopudc7m5YVAG0wiYN7rzH9y39pBzyDfUEeoqHHhIQzdP
DOYnKgKoq+sBttI+ykmLyVsp4IADAhm28EBuBFqr4uJARXGmyyWUMDarCMgBaaPv9xHqaYlUjZTi
53EhljkUN8Tyq+IKA9dwAAYBipStyptW8Qpl9yralYcFSgOoAN/mA9V+Y5UaICl2IW6RQN4lAuop
RpEpM/cGYQXBUoHth5LiUiVKDtPlqCjEOmV8PxAMVxKm6E8M4SvzCQ1LVUyKUStGVQBrqDUXsbka
f4iIrUE5ltNl7qR0qqUfEQBct/UGXBc8Tj9t6PcNF1RkwTb4iZWl+RlV55XHIe6vSEzXJv7iUlhZ
ggfneLJbexvshFmGwIzVznYgfmU05VhL5THuLhs0lwdRLzxGqHHmHIqEB8Eq3m5c4KI6OiafiO3k
Ev6J9dbjWcLlsFY9VqomDAZUe/EBKYRp7JdFbf8AEpwbouOXqvrjTPGi6JxTl8wAtVL7hPOLnlFV
BaviXfm2gwzSlK9Nl/Vqj7mUpsCM+tJsXjKNWPy6KpjQBc9keu7lFFFRhUK5Nq/qBqw5qMRPBbDK
bFKmQl2OK7h6pE5Itpy4+U2CFlwa2+4DV1RvM1URSy7xEZ0HE6Fn9JyaQj5YzcA/WH+xlkTbyPMb
EDnhcAFonUQz4CPwxFMBBgz3Uou5ShWOFVUMZVpfD1BJHZi+jifmAD6Ui2Jo2Cwilsi7IRSQPChH
7ipUIOwcUcyCpwO1FfKObyl7oyZixLupkpVgnviaJnEHmO6eBx1xAIwVD0lgCEAmrYXQu6aJxkJS
wxP2gEfmVXg3quriABoYBk15VGpWVdG/LBlqaAS+QvKIJ3B/hj5bseeYbKEQQbvdjKl0NeYKI5A3
xAlqga9MMC0wpCrDsDlhjTub+bj7F4e0FGAwDgirjkSk5XBDYT0alp693G0R4cReY+TLUiqt0Y5M
lbk63OwvgLLqMKLrQ+YXG3qWXFi7A8EdDxfVwKy4oGXCZobO1DP3K6Quei7guo7dCb8wx7drjgf7
lQBtiGEfozsrWxcBgT9I6txLiApxTdwBVYBrT3GWtRyef1AcdDhVNvEfW2VXdwSHO3eEA8NjVAHP
m4UHY4v8w8VRU472pcEnHle4yhdzuCniBxA/tSExQup9RcudIrE/PD3/ADGkoUu8v/kR0NpwJCbL
kQdmMzDADByJAHg4gvHD9UuKkIqOjDnWy3A+CF2cRVCFyVTkbOnNvB4nDOivmB7wdtDqv3FTDGKt
sRaCdjACk+9fxDssKGgX1UOi1myWEpSmSqATVz7ipCrHHlRpgKJ8ob9do1TLwhPiupRPd+91KgRS
j5uV2Xxj+ITF9D/8gDMkGl1fxUumnAeRqErdqeipSky1sehghqIJ9kuvLlqrYbDrruXx/ig85LAM
rLOajCOg7n/BHLXYurY3+yIqAu11+IuMA1efmemCLkA6hAcv4ohlHYur4+IF60A0o8xpCtpQXxse
LaYBpxL0Q6tY8ObhAmav5oj8PTOvM1Rys+IqEcI+k3RWa9RbmsN9wkJxluB52UqED0esZy6fQyXj
XYiFBzGDeEAv1dwVZdYF3CEtYHu4L9Uh9x2DwC9XxL+iNhXLxKUgo65v/mFRlJdzkWMahhcQaALY
Cj8IFdtjdi77YqsHMFWBTHs1C5lx62/AwW7q/mdTi4Kccgae4rz1NPNkw+T/APKYHcKGufE1a0ey
DOeOIPoQp1cCIaL3HgXW5pwQaeNucmNt8wW01kG85Dxc+RPULmCwvyyh7jj6jQ0xzVRTco1jC0qf
M0iwQkmVMargn4/uDk4oTlsWfUXDdt/BsoG8c/FQbiFSRHVXqcFy0hTx9QY69K9dzJ4Aetu4YqmS
/M0o03rxDwzd29Gy2VuEcakp9VLRFYStlluIFHkTSXOIl8M1K+4BPZCm7KCIIHnxGwqJLPmCJRzF
WISiNaw4e7jSX9Q2B2v8EXAWYlUg2+JwMCvAqmWxt4M+figTRt6PFyruor+EJS3cmfbB8kGS3UHq
X+qCqDVyYMWFAXvZVC44lxnFghFby4XzKhbdxCVJU5JY4oLeOo6N1r5qWy2dZ5gew+bhlNhlRSjS
jZlQo8TOfMA6W308wkF2tLyZaHQp6nOxgDakdUXd4ggrtk+aJvmKiYQTqFCjS/lLWUrL/wCgiALG
wSrkqjHUgBH3HYjwHvghV1yMqvGmhALEgqWeoQRRP3A2JfiuJfkSXtnAlp9wxUoXf4JU/wCh+YpR
wR7hdQHz9TbZdLC2XkAJ2xJ0DVxZ6BX3A+rCk+JUVQOsoBLRN8w0hQudw2rBrKl9l0aItFVXoQYm
qq+oy21u/wAREatA+pzZtw2GrN/mVWAL9ZAbXyHwkcRyimIG4ENC5wH/APHdL8T6l6VEpfEYyLF/
EKaxxxVwolFeamJqNa5huo4uYwOd8XdwD+AH8Q5Qf63BEOiLM6VfcGytX5jkKNbIh8xWHRBIuX16
l2/E5nm44XrUADpf+JetWPHzHTsFw+GJqAVR4lMBS+E1ujxACVo7ORdWMJgrSfQSnAKR6oJyLRv4
lkwrZ7oP6gYsVoOkqqUr+IyOwL8wDq+/q4t/lFgvYpT3CZBRfdv+Q7VYIfLcVg4vJUm7V8V/kqpX
KXt0/wAgWW9OuIVkBYoqcptqbGoaF8MrCvk8RkQBq4diIrUH3KHMKpvuaNQh+Zb3BpFtYFPTKXaa
8EJ0vU8JDPaRH3FTdCGu6h+7HPXiArqv1VtRMJE8z8wJ2gUPNBn6jTvFsrKyUYiLvjuWxJbTjqX+
GFDxtygPQAmvbJUXQllHnWGqtBv7S2tH74iKKPuLcUOdgnbQ1xzD6k/6RmHoRabzOBgj0EdDS0oG
2oWgJjp5lLqAu9cIzERN0o5iIpAu0+5q+Rt+g+JaZs90WWR7HKcAZfu5XnHVsByUamkLo24iMsNr
3T4gLShDG7oO3P3Dv2HaHgiaUb27zjIY0VV8eU5Dku7CqPzKUsFtUdPuKxr1i3xXEf50a5fW4VYa
qr6lGIRQyzHCaVRTk065gporQH1Od9L11WdLM7DCrfMsbkil8Yr+I9eCi6vZZk1HJMjpyt0W8/Ep
VChS50dy0d2HNHxcoTIGKKXsau0csumJ69FUvylxOA3uhuPUtaczfc0fR1aDxsVvbgE2ZHusvmPo
YbNDN+5f1njauvcMXHHXdsHvYzlpoFTJVBMIaIq3fPFxoilTcqihz2QI4n3FWKLJbFfZCtNMYc6l
BPfMXlsctEoNss/EHynOZHBWyqpUGKbvXzBAXjHRYexMSAoVW+Y3yTxFvO4NgdxWaPxGph+Y2OYS
ls3iVXuNL4leUdBR5jfAr5lXa+oZhuqmHhD/AOQtwOo7QhK7jLK1A/I2HyQYbbXDLQypXT5lRpqh
teWJa6FAfENPymygJwIcMp6qaGb8BsalHvk9ZLCuTLlRS2C+o1gVjfqUMXTd/wAzCv7KDdRZ2NK4
6Sl9PM3DDgjVvqGDoeUl9fKJcwDli2LLudpV87ABZXxEuXUE+UbFVBN4rzFmyIUJ4F8BD75BlCF3
ipX2cbimKOKWav3cF+VC315jYIo0NvqcJoKq4ZqldAkf41TDMiq1KK2B5U9E2LSFFHGo8+6Xj3cc
zBViVxK8lnjZXo8t7I+AIrdRG36kS7gx+VeHiF6KxXmPOHQpMyGT7eLjY0HWhHBd7d8wIQOG4FNP
glKCc21FtebnABuhdxC7QucPuXgGAS2BTfVFVCWArNjQblVcMaCa4XrCNDKpZ9zDgnKlfmYARpVw
0iDyX4jM0L+Y/DgU6RsFu1IPCwRK9EXM4yWxk6+IRr9VeGnJYeUcuLwUp8PEpKoY8HxsrAzKkyYw
kDghMLdha3KH0BdAWfM5KEAdgVYCuhAWAAJKK/jxKu03pwHuFhSdWZkE34RwRwSrw2JQXHnslVgc
Aq0hiDKr8QXt1b8Epo1iUGPE1JmL68zWuBi4TJsp1FYF75ipecL5iCiuHlFcEhGW8iK0dxl3vSAG
BJVlJvPmOu7VgRb6iDUuZcik3ot8bsEUjg5GbSDVUQ0QR2HMXQopS+hKtRywSuUNF8bBCzRb1zqA
+9S9cziXuhkb4i7PEF81BwN8SjNmuhh8CyqWreZWPeHz5jd5ETg+SMtW1uS5fV3d9opC5gulSwQa
p6hOkGxejtSnbGUi/Eb3KgL4h/cq2WlaKHEagU9kHsCgmuJnmzPhvmMDlFhb7l9mWLFrqA6o3bvf
+zhWh/cpdhYsgkRLXviUChN3RdqGIm7KT1UTMoOwEDOKeInUvHxnOVt4Fa+kTMGvqdkWUwy7RWF7
y6jCmuxX6iAseYn5hWiorx9QxascbzzzEhVjyXv9RiQ3olsdqNoAp/MtaZazXDEli6FPGMN7ujb4
I+Ah4W6zA8HAt/MtDWGaGaYIdMXBPD9Q0XkCrQAm2zsILgyEsVA5z3FW98IAg10BZ18MZIwxiHre
YNSFbWpwOfecBWXKkcPRmR8xSjqfkUV/cudhFJR0LO5T7ipWiFdRqpeR8bEMYAzAjK7gI0LnEAB0
5a39THghtUFXhHvN5fcQMHNiiTVD8urKZIjkpPuHLxUUZz8xi1K0CkOnsvbpvlmtC9i94Xsf9kH7
X0wjAIAO/MrybKUWfEL+g1fww290AavxHobi1Fuf+RSwW+FQvYVscD9y8KsHmvKdEB8SwANyCbsz
ehWJ4q3mNVrbeodRicmdtd/MRHyRpD/Y5G/1iepZ+uKxXad3By25LUefmLgaxp7jWTVZ2XAiCKhD
YKnDYifjJskWu3dkJ2kAmzjkgcBsFCjyOcQDF1th8JGONohGe5Q6apoVPonK0uV1fmXRMIdp5lBx
fzDTSkyDauR/UscI8CMBlM5sQWcwNDV+Yq8pboSWupVTpcoClVLKKs6io9iDcKeYq/ERDY0CoC7D
iA0EDxGwobuY0mFy6U8+IzFe413X4ipHd6i0rU5D4mvCCiaZHDTmfSbQCg0luOvB8TAFYygQjm2n
iXNGea7hy8LKqZVVBsKFmzsN3Uz4odR6mZhsHcInXo4S6hXtG30c0kXFi7Vh2jgKV+JePg3Vv9y1
6K3W4bOZzkfEtjIlC1IT1u8eGH2bhdqM0rrojG4pjNwWJW2WA83xOFLmDws7ZYHmIGS9NK4npUTC
PynJ7lhbseoBDah4QN9XzKZwZbqD0WdxM5p9JyBaGIzfaNNqWdmIQauUtidqv9RyGfK39wgkOicX
7hFkzYv+xyekp5Ca4t2JNTLt8Qvv0ExC7xoMjtN/M/cFqEUhf5gVHQCJCutPJ8wbSqq6VfFMRjKa
I7Agk8Eav5CiviLqaa2v5nqShL4D1qxCBvhtix0OsFzRL3CZy3jaRbCrwqDCy+49I00Or38xsCnd
UuOAC2F5A4VuKslIZVdYfUYYvt4PqMHKGGRC3oAoxUM64VuUt7lrbhoI6IzEnCUuCq4uKuZaI6rs
fMLVLtwQaEE/uUaUW1dQzTHKVMdWqY0gSsOY4uKjhxrzHqWYZUeLt3biI95xiETAkdlkXirXQy4e
E8MTE8gseBlHWeYYkJq1ueZJJY8fFhpTYI0r1LcaG7Gn8wEa8y6IE8w4qRplXdbCnDgFwtelqM6I
FNkCKs+Q/UXfKtiQirK0fmC9hCwumAb/AGqFIh2A5hUwQqTFosAuJWjb22RPZyq6l+r+rD8Sm8gq
7M8xQKwjlktY/iLnVjf7R5UtaBUcAh4ew1se01gYDd2mfmG5SFW8/cBMGN2fFdS6fHF4AZ3LD+Xi
Hw6AA8evEPbJR5E6icBWG8sF+kPfDkQ2JiR7U1C1jQzI+4p0/JLoN6XREtcDMg8UwTmsLtVgRRoS
11vl4hnQFwV9Q1SQtbAc15gjRohQgitWJoIF3YjFbOLbIe5s2ll6jPiaqY8WuUA0SC85eSpaHo/u
IKU7xFWxhyD2R59xQ1rywVCed2Nd3DLTYUsECqT1FWCpZVrKm0V2Ncz4mEyECHw0lxQVgSYs1Q4P
fUwwd5TqZVi3fL9w468vMdeFCGRu4tWio0pY7hccXQKR2HaoF11DAsN/MvjwW9x4IDe1UCv4YaEN
ibHnioG31JxkWKAOFEO0CLRajtqvFV+vuFCHB5I+FEt7XqJkfk8JcmujkNWYeoj0o7CoC7MPMQUh
kQcNnjQ+WCRWXmORstvVxR+53N6Fa/IhUjPLmHSJ+Uq0B9mwO5o6AqI2861z+YMGkB6ZnF2slzLP
iLB+y3L6JaHZpLPctDbvzOQOId7nlYOjYeLjOKECLuU6mS1X3NcoSAlOpF0OYxiCYUkLNb+o7lqo
AVz7jNP0l6IKwOzQjVBPmIqvCWFdyjk5CkgRcVLqs+I2jo5ioPSJ6XGpPUpanHuAoFFV3Cyg5C+8
V2I+OXARzxNHP4hfCT7JZhxUbbXEiPEbowz4Xs3Ug+oqPJLFFjcptIpFSKBZGepZArLrzHowIKhr
DQkUnJcTsl+531HdFEcdoxyFjhbf8eYh1rGdw2qFnioTSmnHvmFx5KMUlHNNU4u52QBgrZK5ikCj
FEAFD4r9xQOpzBtUYflKhA1ZzZsVpD7i4JJVBzhSeTqQguXejCFgVLK4aysg6UAjZKqAGim8h5Ex
AujFHxL0VFXVXqLS4G2wdvWEvLjTahsqJLxEFrC8pi/w81NUNFr1MnFQ8pRSqHNqnbuYwEYAUayW
QqNHBIUjkLhcJDwHEoz4wyGMUH6QaHCxKStlXxDsYhFQW9o+eD1wTkC6qpdyNdJf5jGPOXNPc4KV
dYx0EEJRiFAghcVOIHdjzZkUIPrmaUWoCDss2EW0aWgdupioFCA7KgesZYXOQ9aKgQ2U1SNIAjGo
e1eah9uOChMqOFs4Z3mHoi2UXXyQrRrUAiZSuDYSJcEX8a5aggDbSF5VWcxKcLWFA66hwtDo6O4A
sG6Mq40pnIbEIyQQxyWiioPSEQBRyIKNbghTQS8BLJ3dbay38HiEEFdsAOO21XDOAGRKnhiqupco
MI6IQALVxUirKO4kESgP3L6I5hIEKBSEaQBFBaTdeIcK7IK7mcJwpktKZ4lYWncpKu7E/ifFlckR
IfO50WnTAgJHxzBMLmA2ISoO49YUcEVUQ8nhhEcMb8RSCQC9SrAB62XBVwV7lQWuMOGWjPqVjHUz
Fj1A2U5NF+IHJgQypXUlaKuEFTks58S8D80WOhXMu4AHPaFal884H7Q7Q0Q3W+YQC9wCWTnsi0q+
kO2z5SKi9vBxBaW4eUKjaaCSoyZrZ9wWgu8biEESnyYig1Icp4YpM7fBrIobL5uNA78QVV1Pdx8M
SAZz4gBpqMM0g9rgRr7I1fm2q48Q97pA9jerDamcJLCqo83MMnAcEbtTm2yUNaot37gzDUdjd/Ue
YEASkAluiulnj7hmGtKL8x4xFazeY8tXwJYpwGcJSnmjsPbFcb0Ed8ZEjhX8CGqacmz4SWt5iQ75
RVRurSEaPEqymlDQm5UDTZVufEYgqYNF4RQWlI43yxN3VEnXLf8AEaNgUUaF0Q1FgB3jaV3Xapb1
MINKFgL48QlqJSlWSlLz1Lba35nZMiVp7yJYqo9HqKQ0eIwo14YJ+HzDitvxLhfyS+jiPYuUhxSC
Qrz3KLb2E3eIHmfLDWHmLYnUBTq/MVWstVWThWkAc2JfTmCpaU9xrfD5mxXc13kLADSfVLXXPxKA
usEtPDN2RBprzEeVkNZjxsDXgdiRiR2gAiLf8QVC6O7iAofco4gsLdSypVhNrFkNUD8wANHzLJY5
c28QAIgzyd6i3olhw+oI7iA8y1c/UUay/ZODWvuW1hOTZBQvmNsmqdxKVzKJYoVlEu9qW1FwtyWa
2w6npRat9cwqUT7iXTf6jVPIkUVyRjd+vMtTRcuojBm8cNXu+Lg0ZeOTXMIwgS02oIZtVN1UhJCf
SU4A4r5nR4Z4q+Il4sAnxFSVPUxU9fmU+69kfZi7wzg2A1zRHVW6+G4ls6PQ4uLkCTHMp8CgeY3R
ZXURVGR+QJ6h5dRbOvMAIcuy9m7qcyFvmINnPmUWG2/EaL8RLc2aJDiWKt00eNYlTYHbjaV8B5+Y
3RboODzCeJBVIRUPlCB3IO924oBQzXmpeSVdDEFtvkSWvfLPrzDU1vTuLAufcZSCNbL/AFhbHkCj
cIi4o5WPgwz6g1D2h39i+4Km2mMCg8vcMYot+J30kX+IKOtNoiTjFDKnZ1KklRgBbMlK64YKvqjM
AAUIhAEUs/qXobUH7g3ekp6o309wwuDdxu1DsI/wDFg0irTR7rGL5ltffMLmBVHmNjbqjmPFMYQH
sjY7zKrqASEvSGOLlQ+pvNrAU5QqJeMUqdlzC41uiECpEN0mKMPC+YJk8xd98xtRdrVxtkQABHJ4
iUoCD1loBaXthhPE8zns7KnHdRsSi6g1BV9RopmqFsX+YJrYSzpb+IGJpr+0B2Z5hofIxlq9+Wvc
KyBdYaHj9QXXMXvIFkttV3MJImw0lQo2pDQqJZWNj7RBr0q7L+phe6ibys1/kgY3CAEFU0KhVJTh
NjK4vZEBlOg1C1A4qRENg4IVVUUqV7kJdWOSkdaE9+YCNoUYyrnZPRczSJKbliWdoq5YXNKOYsAk
4F1cIUENHF3HsjQH5IW0B6KdguWFSVGViPwnPASvHzLBSQ8yE1pyDUFmNbAkOG6wHDALZ4h/lhb3
TAti6rW5rBu1AnhX+wnArlaslyv0g6wF1r5YrRgsBuFolUHHzEOdapd1AJ5VSmcxQMNqtCACcYZF
PKPOzjWMSjkoI/ccEb+JY1Wg2qjP+9cNSCAB6vFxREOhv3C9f1ta+jmGrr1UPzAeOW8wCBB4gp9R
oSDstRK6Mh0VRFSbZXuVFner2g/qKc/0l3+4mrdNkVb2xGr3CYCj1zCKFMr7pid9olx5HzDtv2AV
EJTNU/SEtIpTD33LNY09X6+E3UGNG7V6j7n+ANcyx9cr+UISneCxthNQrDZ3Lm16rpmJCG+a7qsR
pQvflQNkmPnhMErMr1FICPg2dsMENiW8+5ct2Nw/cYOkRaPxKhZ+Y1FDIyW3/UGRLPMRaCkgVVzz
USwZ0xrROV1UZ2o0AaSw86y7ybGgipT7nMF4MS2qYsdJdsAqr9wYsYN6htEeI/Jk1UdarDxMPMQQ
A93AFjbgCZsq0upYPMQY7HIuorhbcIXhvE6v3F4Gl8y6n+JU4XKFv4ji13G3IaiupitjncHh1C1c
+Jp5qIpNQ1dbLrVBU0pUtr3xAanUeY8xpAwTRcVYe7i7LtrieolNWQVvZXsiKBXpLKPUZZEllXUE
AAcjBXA9e5gILXuC6RPXEAQUXLHYgVfcti1wXlaii7PwVXEMtrGNS49DRYFh7a8Tjy78p1F+oyBb
Q0R1QPTuNUo2viDEGNLfmDKFNv1UPUU+Gy4ColfENCFweGQLaFXtOZSkIwRXjzHlpgstyF2NK4jV
VVH2fmVDC4xNbiPXiHJMlPYg9hX8SkHlPOsu3C36i9yC+pcbwtXW8XLOKBWRCnLhl8u3bt8QdNti
/UsgUXcegAKvmMUJiO8P9gmHij8zyCLerltIdzHP9gQVSCD1kV5aLIqrQPsuBjQj9JeaN6QMFeL1
6hKsC0ZaPMtFwoWt6qbs3qvKPCijzsQZIotslLaBYxzFTRWEuhuqbA7G0NQZY8YwD8iH6l29FepZ
vg24OeqFdRd4KwQzAhNq0/uI4/ElBrmx9ywtZv3sLnrTaQR7LQ8RKysI0i8EDg5B5zgb5I1wBdPc
sIWmguDJ34P4iNkLdnuX4EwepT426vJQIKLtbCtZXdvPMQRtj5jxNtg6iQ8H0gKnorr1LLVf6VLk
NK0t24+4PLgfpKuRyfcY0ebhzLjxTPuUfIOvxFaA0thtVal7XD8xswKMGxA61vll4rDfC+4/4swf
cuIpr12S5iyZ5xiDcE8BJyeMcQ2wLglX1AFhR4Co885KW7ylDYtJbVPUOh4PwKuCxlVh58y0tYDh
OFDSRUUwXcVfcckVS8mpcmjrzGfCi/cOKaIX4i/dBPh/yNCoDc1WQ4iCryy7xEZZu722XKIZ0c3z
FSPEXg+GogvmpPrLigsOPyxd7LT4qE467QX8EfHuofOkUQtsPzAtLjFJxNjeEt1u+PqEKys59x01
AROoilNt/Nxy0e44cviGSrBPxsAaudsq4nLgPkJkIcldf7g9TKThH4yojiPQbEgUhjh6SU3st+iA
6DhnAITxIinwv+R7LKXEWDXmldk2exN44o+IANgA84Q68NNm5fWxRvD5y5RGuFe4PaiT4VogLKAH
4iFWQFd8f1Be3Q6lK7UjSBGL19rBZe3Y/UQIqUVq4jpCRX5RhhkMcwwuAw8sIBSPLa+o6roplX37
nSsvf/e5QcOZ9pQgiVbjY8EeF2FsL/GR0Vekvcz4Tp4tIaQ6H7QpXVJS2+PiECpDfXKF6EG8JgER
VG5cLIOtLfPiWS4gzQApOYVNB5JerVROnDGhfE+2ARb+ENaHqpbPX6gaRgttX6lhrYgA5Y78VFaw
ziW0c/ULdwYFrWPK/wByzQeIi0/ct08zIOJhPUW3qNkO5VvZxZeMKlFg8zgl1ceSt6hBD+YlRaRg
KvRipe7ZwdlKllwBYPqM80CHegPEbTzGy6hFOGWIVL5l0LkoNRAFF8hA0rnywI8xncoIJvZEBrmC
85NDzKtdjuqT4hqlBgorhgclV7iCNI1h1cq3GiFDTXyTvsCh0uaqobZV13/+Lr4F3zOJWkLuNPcY
WMgJMR5YgtXfcNSHqmaHC+Jd2C18Q1K+PJkvoKdVDzFb5R5gywBSPZL1lG03CLksOTYzsUI/EYGw
QqWjW1YSQE79woUPYxL5l7uVFuLNnKDRXzKuAruU8RUtKrfqU9i1OpVbq5yzSOlg3HTDJUt4JSzl
eIwWUR5JQ3niFNTfcoH2yEKy08QgodqEk2gpfGpT3kNeop3t0kHptjenNeI+DDDOYQLricNgw8Pm
VPBL8ISijvMP6rZnLEFDCX0URaIsHMTvrVsaBhQ+T/I64pP8QAgNVeJQ9Gi+YCpbX8TeLRVSIRAN
iLn3sMtNAS29z8OFxdAk6jgsbyMrBrtRsoLSkgOyNtijhl3VMwDTbowCVRdVDAUstnYEvuX5iziI
L90tle49sdOuq17lioVzuZNgm2ALo2P6dKS0hqKQOqIiCwIIHeTNQCGwkljLX3HOxLr4gQN2FpYm
gFsVIt2O5cExhlgLtikwGlpe9R+yrPv/AOy4ANsfmKzhqxeIave5T3FaBXO5cc305ESOYL4iYREW
PqVZ19puUt5N8TIBJr1sNkA0XZzAVi8TSr1dYUPJewcHko8EJW9dzPCTviofAF9QmdZH7gW2K362
DgYGLbIBeO4Bp208QQkYNrGEk5AZM9OKdXCKOVPso4ysbtWC7IHxUopS78ti+8u4/JaEVOYoT7OQ
gtwru+NiDKu2+IUUqqX3H4ykP2hyTUOymDwKWrxLTVWDx3KlVcN9y0nE8KgBCaWOIKWLA9xyRkiH
IJ6E79y7RyV/NsK6pGXxmy7HSBQ+7aJ+P8gMMR/MRpKvYZizFV9P8gsCX5eMi2bQp2bLSZ/qDCo4
e9nTMUeGZ9AFmHKwL6sHs8xaTjT2bDZlkQm+5TGK9Y4hTi8HZ6gKwLt0/wBQjC9udKe4RSqLG0oR
rPaoq+4XC6lL00rLWMby7u8mXNjAt9bKUj+5pjnXwHR1EbA3Qu+oqQA8CKvctrmKX8R0xQ05BuAC
gqoAVkowIFnXOQ1uAvkzKgkVM45y/wDJXtAIB4iYdrllSt0LoAT33GDtanX/AJGwHhMfbDXYUAUV
2gd4i4IXa+9vYlASdTnZ6W0c4P8AsGqJQVx8wPUCNo137jqlvk0oZHzBIMK5/iFSaQpwKfuDTyqd
e8VmsDUuVCluqvS8mp3O7UZwV5uHkqAl5+YRSuSUO8EMA4Qjsv6+43UEihp5gWlGwu6xptKR4sYL
YI5sQU9TPPiXTlsQ8ZGwljCFz9wfbuNhO4HT5gqF19RHHcsBezg4WQRupjivCOns8RLwsIADYbhk
Eg5IjLnTXzKcMilTZBIKH3GS3niFdcOrnRsyJQH3BXO5KGJc5GbxMC9qKJDiZS5A5eSU8D5Yl4q/
MuMS/ER2p1vN7jYGFeY7Q7mt2Wer9zpqKuFwHLJS0WyxNydVV+5pnESiqGJSExR2zPX/AOGl6S1c
UNrzAaLtGepk4jVDNgx7cTc2oFDyjrXnuPRBByCNkewOxBCPba8uxlFNrsczhKHDx8Q25At9yzDu
UGKcCGKbBeuxeUERC1++okwU4GK0IiDoXscEUL6qCeYV+dhCm+nDZcJ+qwLUS+p5lkeyJb9SxEo0
ocVBn1wS2qriFAqmKMqLk6YpSqgiADydwHYgjgBeyIEjCh/sBR1pCmYKKaqJJNZMc/49SoKwoiqr
ZpBsDGCsCC3NQACTlY398DwXLYYTAfCXQcrVjOZ+ynDLpQAJSMsxqxPqFTXLUQtlB7PcOzopL2EB
T5KyNopRfNm47yTsZbHiClIrqll/YnLibe7pc0+Lb8M2fxSf3O0oosIIurlBI9AsbVbUD7RnW5t/
1bzBCHM3CLF5lVy1nCFzrwsjEq2tUV8xubHjUpUjvommYHuS8FSvmOKQmJcCSCSPiLSsALUFXy4g
1cshaRWDuqtcj3Lg0no/uE8I3aAUELo/xBmwjuhfiHoAa8vqILWTDniBvgAh96KqyFCUVjwxGo2i
E/mCaYYCCyz81bOZU+QAtKOoMa7jWR67TK0LGi6gZUbf+o9PoAJwUJaiX7uG16rzN2LEcmCtB8BA
IOLAV9cwALlI8waiyuiL4isIkISwTjmGxTQPXcU1x5NscOlp2HMHm6dTCnxRpiGTTtYisCpA0sFY
ibQ3UXgjyksEjcm3poucuEEbrWBQxrS4+gC+MjgcFdIhJjL75hsSUUWfmCphVjp+I4r6UmrZYoRT
i1OF6LwPtFQOFpxsbWRz/IsoGkMCHLWl8EXqpg5fJCYHVhb+o+W9tmUNmAvih12LpCCAaB03McTV
0dcwXmKxqKs8Q221g9wXwtm6iutwa2sqNuHaC2R5CNv5Cxm7rW/ezodJC3ejYwi7CoPlRwxSdYwo
mDGQsug77lxYzbfwI6FQ+RDEeDgKJY1dxuTcKjRvEJcUpWP/AMiD3srgXfEUXZxQG8jJFiTjnETV
dhuvV3LPJurAPE4waxTPiPTfNJD4bEVrQtNw+Dhon8XzCOxawA+p2JSl1WnxLZiwbfkxKjRgMuox
3QnRGgjY0o+v7jqRrwrRKjgZgw6FRPZ83Lh3Dt91GsHMpPb5gcNzdD7+Y9VAp3jSiznuIEPZbHJP
KKbBl0KuK+GImlwme4QuC1RX9RRUJdWLvdx+BN0VBv3CFOGPuG/KLgvHUSkFSlhWwWeEFgcrEllW
ck1vfiHitqMsDUUBf1Gr2fMshSvJLMlN8RFc/Msa5lwLlx+Bl2uHPcRRXjqcV5LHnPUN6WTt6hZ5
vEV1zLRxKmsXEaKsgvNX8yr4qNqLoWJeKzuptbz5lmnI8E8yvTsFGUzokVuXImkw7h9RFosIGSgi
th+kQoKpgC/EvIbYUQteklkwFF89zgmB1HHNhBviUYdQIWS68uUGlwvi9cjKogBAuwR2HkiR8QtL
6lrzKkRxgabL8SkSHMpRB5nUFFrgr/8AKAqG+JQ9XUEgTnvuI6NK3GzkO+5g6Ryc1SuUw6XzTFEr
hZvRNmj6jq4TAXEralppyL694pCxYdKv4jC8LoGHlVuL3XzFIDj2rjYwq5BB28YvE24Of9QYrjbQ
r6lQqPJYtfcV2bpRhucKNltXN8RLCon+MA2VbfME4a+IkjENUaRBSXcLCV0+YBa2+JR8UxBawEK/
Mpb5CSvxB5gMs5lFKeLMhQ4cxVl8vUIUc0dA9E0JLzDjgNr7LdZ62WE2rOSXzBK0w4qd7bl+y+Fz
ULaw3HZnneh6iJ36otYS4fJDh+ZXNWCuNUgYbOLOYHsum9EsSBqWRgqmzsuFxPktSrrcKDLJYLxR
ElTpU/XicIj5UZGvyuCVd+JUm7imCvHXawu2rjXELHgIvMUeoFzjQdoLKfca7EDRDTRjIIO2sUIF
bQGQLYq6i1BgZ2fzcvRJ1ZuPAjw2g9Qvi9kYUObOYb/NYwXx1bUVXFdvMZSzuC3LByMSz91LrGB8
PiWCPeGj6gBbPbyD1CDkwPMKx6aXpRi3azoi8w7KVE0X1V3HlRzpBwfhEpOatLJZxDaYIl2mo7HR
mqnIg005CoFlxvPsBhGhS77/AMhYBZTLRHkucQGdQwiVcQoEvg1CGv8AYxe3HmUPhwbRfHQ6H4jR
AcBUMu0Wm+4nRBxH+Lu1cJQu3r4iEIFDlGKPFD/ZbjZVftG5beFqlPx/+GAQBucc/cqP5IZUJQOL
Zk9lAE01FkN/Etj0MFVwKUou1RtALRR1H8lWjE1bCt7D1f3VJVAzA5GbwEuSEwMYq4Tp7PEJW5NW
/wDkHRD5SN76cp/U6E8OpUBX6lYKijpAw6rmHojUewCcZDXBMXkACnuX/LXjqKG6b7ZcVxl2re5Z
wHwwAOiPP6HUCau82yhe0L5l2FRbZmX9S2kBtF1KgjcSKgIGgiAL16l3dG3m5Wy1aDzADNseIfMq
6LERp9wPem4cEbacZZAILc2ivg5YKLGoYHex3Urd+u4itQ1VZFbV81HO8PEXyPZlwAulWE5Dfovz
UCG5kwoO8irKVHVjqk4cL8QrDDQd6zmC6Gj6IoCKcnmNwuvB1F/oh1ZL9wQLnmVOC/MLWw7px5jd
dXA8tfMAno7mkcDxBB1zFWhKNcS98w7v3Bs8fEslcRNocvmAXQPuGV1UfW/cs58zoqwjE0YdSyoa
hW08wLIoWoBX9TBHPuJRRkNlwVVssivBNVx6jseYYbqIWrhAdPEOAFR1o8RFbTJrZFhoh3D8wOXN
RUtF0Q17io77hZeV4ilR3kL11xDg5YAL8y3IIepcbNFRboYjCXAAu36irIqbcQNOeJUqLoRVaS62
KBVk14EorLruPRx4l0vzKsPUdS5tqvx/+LAbVomvVHqKE1R1EeOvnxOwB6jlyDbFey2pcqD1FNWm
iMvU0GLkKmgbLPF07XH4VMoh680k6h0mm0g7LA11Ez3pyAtKeAjIki2oB0huhdkCEqq2eofbO3fO
x5IGrLV7uI9pVmS1CjNIh1aFkEgIFDtvYAUpueRBeqcQHe5Vo5h1YWy3DZxsFVapdTED0Wb+5a7w
XXwgdg3QCpRVG1ogwMnmvcBCgL+ajVagA82wa10tyiQRfSTicHg49wuyzDKGoTxB4jCxVJCAQM+X
mJJEdbKK+KJSO/hnNxaAAXfpFoih4gHARhxHDRVhWQawQJXMu9+4wUCJ3CaeR9MSUb5S7kX0QYDr
xkNOOb7luy04lXDY0ZKVJZaxyVMKEOIfrhbmxcAWCOQV0huzWwMNlqqhgUR4IFWY5MlkwMwi+ixf
U6GK09wvbHlDedQEnROk3ZFKfWAN/EFoDTWyJswr8JsAPSOAa7OEEBdCVncfYgsrmPbbBbv1Kszm
DzDPwGHmGKwia59RgfDEazi4H5JUy2DRZK2lUEIuDKe5kN0eVxA8nESFDXAiUfKQKXdGRs4VExJD
hethTGzm6lyvXWogS0vEXaPKowQAxxGIK1FnMrjgXUNgCETohij42QC16FdIJ2ArYcS7EC2nuPpQ
gzmbZbECw4qbdOCHcsh1HF+4UXZ5SVCVduSUpK9RAo/+Qg/LPdwpVsC6hVSiDEodfg31/sHK6ujz
4hytMOWfUNogqhoM7o4NG/U1kvYeDolsQ+TeJU6Y0MvmGFoAd1RKKrIs1dRWwisXYhIqI1xjDVsA
y1CHtgYvkjrZKqzDSJfJBF8ckXa98XKsbMKYV2Q5FQL1cNuCmc3Ovru0Ah4UYqP5idco35QWNRsr
dciIORCDsu9qtvqDtrTyZgVngv3EqJIHuEFwCU0Lv6hTgaV5qtnGsIcurhYoLp3GBqkCtVhDK4me
UJVTBiqWtFKF7NLoupX3D9oFZL8SlNo24BIeIdmUdCor888RSKBFKCZkKDVV+ZVRwHC4/uGYqvWR
uQPuWOXmw2/MFJMXl5P4g/raHR1HrBsLnuUlS1i6Df3UFFCsoX3+IOQd4BD1DK3BeB4iYWMU8XKE
c1zOUyLHISzyo8xaPCAtQ033Kmr5l01c0K8RtylIFb3KDzKta/M5ODcFUAJZOSGuxWjjc1thTFMZ
AB4iLyUNoCBpFjdl2jhSDawMxaN6gq7FXj9RLNKIkpwiFHEERWe2KPKYONPiMcMiqoch5lBwfcKX
Zo1XiBevzBBGVnE0VB3Esn0MsCzMga2qiUMvyRAp3KiZYwXevmA4iLRajbuyBghFapO4x4Ml4eV3
OFHJs52US8csW3nblqHcLDpawCfEGszZUOQm9RWe4IoIS3yRopx7YhztzSglLeEM+Iylr3Yl1TwY
2pq658SpFIvMCjeHnTIFBeiHDUXChMFw7HtAdAGyvBKrXcHttRvOxhYxd/EDeOWQjXQsvOwx7SRw
k8gyCQGUOoUiiDPcrwN7F1L2NQfJKOltgAht5FS3k4B5muRCduJyPAg7JdHuYVURDvI0PExOfcDh
33Ly5dE8WT4h6d5BxVLCQ893QXCRgLbOJeWIqFNTrfTCS5AH2cS2DUb8Jbo3A+fcNQt2nyq/zF2g
3h8Rm6B0lKTxV2cRMQNahXJL7mqLKa5YeBeAnVEDKqxwqwh9R6bacS9l5AWHc4WnLGbXSx2rhWxS
w2K8pQEbS2a9IpMcgETshhRku5NBSA1FVGSg+RP1OA2iS7BL4TyFDY7pPmAE6yYVLbZzOSLGOWTX
HlE+sX5HcqqgUlS1gBb/ADAgMcWQIXA1KZA624DC24MZIvI1fmCAsAh5YEuWM5uUz7GO3mMM2oyg
e/EYuqJVtEhAkPmoeQmx1BJVsv1RHdDRXwzVkdvEuYCLvnqO9Gzz1DEIhYYBa7A5haVsUjtALtfE
VWhlL0rYSi+nVxwZRpdQeoKT/qPDB7sMroiHtUaiRgEPttm7gUtQeYScppcHZYqcKu4D1RBLRqVo
ChTjvP1Gm72WEA0CLZkbMgAoL073mE34/wBErKbqvuGbw124QiT43NetDkfiLokuHzAVdHmGhyXt
LsAKCt/8wMGK8FSl6muiOO0B4Z/sHuosLflKNhCY1qYC4lOLcAxiASKWKChIVIo41Ks6DaXiWwdZ
Zy3Fr11ALVg80cy7KS1SxeBQm7N4IQd0kXEs1z5gKnTz6igrdPbFOg030ygXHR4SWBhX7f5BGFUZ
p4l+QuaAIxCKjN+5xv8Ajm4pBhYZf/2VskobfOzVISg0OpX8AIbVcRAwNXF/Nw73Agc0zjec+4+I
rwfD/wDj8FGCVWrYxgjEAUvuJ5J1Ay6hX+0ge4APGK+Khs89e/H6ik7ANc0UZQ5N9+oQcCXM8ExO
IQ0TZ/cHngvx/wBnMKSOh5mXf0Q/5MXVNG1ZcumFC8mKmTFChxDDsQ+7jMPjtQ+IrAEzmG+fxEQK
2ixu/wDZW333F0wXKlgrLNjlr/oMFBSuHjWWZcuUUok0nMwQpURy2x8Qh76lyK4dSofES4eJYXcl
1Yz4isKZpUMg74it5ArbGwuA0oPcps9HESMcgjFm6fUom3FVDhepgcwK4gL4j16+IAq25RK1eZwt
4jyDOZyIY5sZcrxDY8RrDqA07viXpVK4S55XxAErjmXczGltg2qgg3mKwyohWEsVV8xQVVVlwj9y
0TuVLbtgUvUt5v4nFwqLrbTcmRK2FLiH6i0jEWoT9wqnVfuW3lFVa9yqV0dxd5l2VBZ/UsbFpyWO
oLZRLuyoWMObj08ShvNlPDECJfWxigWnPiB0YwJj11LLTXzPCB4lTVR36gGWCkYeg2vhLYFb7ZFe
eCtdlww0uh18xoBBu/iIU0r47iSpXPjYIw8185KAOOI8rn5CJOrV+6hpE0wO5/U8y3YCefmY+H7C
alxbDa6HL7jYAJK2HYqwRE/MbXtlEqBC3mWWVfEsjgZVaqVEWGRQaO5T5Q3uEvyQids4/UcCgtAe
bR2LFEY8MUdysrJdOCTlC8yxsAHv/wARWYat/EeLdH7p4ljgkQMvj+pRpANRTa1KjM1oB3zGNakU
9RXqLZEoC1XfHpHI0KyNjC6fVwTaItOGAilfkZAEUCCnUYFlcYbGzpOJp1qoP4eqnJBHDvzUDXvv
jmVwS5gQAdlzOEb9uDzFwtF3LUCgqu52bItZBp52ArsUMR1KrIQrmlR10lPfEEoagV3cdXC4w0au
+NuzVfxCvIF/4iJiIvIIAaeoFJXR7qMVFUdQepBxYlaUg/MsQXlJRsBtGxFF/ebsRgBSahlLFLRq
xqV6XZ0FLLDG/wCUYbRkpMQsRqQx/CAwHjxZLHyNMDESw6gw3tkBPP4WwfISsQ31Fvpx+anklDzB
Tbiis1oVaUfETky/1DytHHjYMohSS2SL3UsCrpBY1bjUCFxYXy3FdQHCLIvBWFQMo7UkfnqRT8wU
6taCMfx0YBip9EZWtXzTPqUVL9xTGi3fUWLHojoWyMvuLhWU16P/AJDvwtm3A+Cb2qkpHIfo/wAh
O1Ioq4BMNKIfTEKOLQa8w1YBa7MbwdnEuAAJ2dJF4hNCyyL5HCUcXtyh6dTwU2A1CcJBbyFD54j/
ADvOmh/uU68weeZkISg6IuyXZKPhfUoQwaeblg2Xw/Euopb9R7xpH6YuVl2eq/2DLjBKT7+45Von
yoYfq5DjKmz0/wAqOikLu5AUtiyVwRdMqC1v/kJHJEq7eoiXYdtdwf6kDswPVi/t/wDkPG5T0NlF
prKfExdx8ml/uBSlQ1tuy7WtG+eCKpuCHIv+oDkE4O/8haw1PwEqRYp01yxEWBrq+0ZUrIWuYBuF
VxP7hIKXDVrj+oI5XfcDsQUCwgPHuGa464LqEF84PTUDaaNxa+PUvDLd41LBIDpScNYafWRSdyXb
fRTEvjsSwFz+YpwIFdkuKcSt2uxEtqu4BEePcDiqlrc8Ss02QV4wlh0EzdAnqJRO+YFOJUrqaNQB
g2vfiWpDTzHwuFi+Zdl+epWBhENqchzSviJQXTcAKvmuZxj2It2RaJexDulgIUeY8BVwHo7nNT8Q
FrAeoQiN4gfKWNvJFoPDzFUROD7XApwljzUGrWo5sWWAY9xyKDjvcpvLWJSzmWi3OrgE3f6imuUl
1xR3KtZSTsOrXxClKLPEputJQpxEmkpm7MFOsXJsYrXENyVQpu8iX5iKqm75nBWRYurYb3j1OBq6
6nZKq7qFPCUBa3xOLeHxDuNplvMEUR5ShQV8wdKX5QlhVewJDE7lQKXOCGlS67GZlrtQlXf4VuVh
p18JzLRppV9e51NA/uPGAZWQc8oGVqUPxClBS3jIicC23U4oLl8xDVanqOD0OO6YKQ4fKAmKMW5d
NS7C8OvMQ4tI74nwD6ITeWaF7OFcuWmFrDeTvR8kLN4qIsFxQQCiKinglCJyV5KV2yuDk5IbLdfa
5/kawWqrvIgFCmoPDU8jwyoeb5J6lSDZZ1KplKTumV9ma+4L4J1BXU03vZtMsHju/wC5zC7Hid4J
sp0WyH5l/JS9x+tS8RnefcX5AimFoG7AbOKr9xObU4dR5iy5+WVRtLuWte0yLgEeHhhAS9CoXQPE
FchwxuNnVNTkpHjEfqZkhHpcM30F8FS57bbHZDZVXzKVBoshNSBpuB1h0eJwOtWlw9pglLzNUtUz
rYFAMR8wBRrVpB4bN6MlVBPLBD0JMgxTKbGMgvHzsNZdqs1sYeFhlAb5dssIy60JbRBdItggk2lc
ENLzAv1KItcMFzJR4pgYQrt1kNpWUHuPKjAZXuDEC+agvgOw3kCBzcq0CaTu5Y/QWh8S9y9ULURT
LscR+0N1VDSMQ8iVRsVsSd6UcCMzR4CNwecIA7a2O6yMt7jMWwDhD+J+FRa6TSLl+00v1KLQKv4W
DVAvhMwnzFsDk9dcA8RwhB+lHMxitqkbg4bxzxFpKlY0gSEc0B/cyMHYmtcy4YeQ52K2tbteINVY
tUhNwQBw+ZUWK0mx3zg2i1CVC8Qeh2ANzkCtqAmNEVFIHgJ0phsfQSUQW56tPmj7itce8LlDa0aZ
BepyHKsyjkpu3S/MGq6lnBlwIiIpbVSw/EU9SLdZNDDimkOYM+RGPw4hJQztSpaYLR1tYzIVDagn
K5HaXi2U5EDGoAPUACAcuLuPnrtTjIQEKESyC6tuj8TCXbq/fE7RUWk7kWWqfPMo7lY0sZ8RheHD
Gm6NUtXmGzQ0UH1GCZAF3zOSfKkK6LYL3oA64r6l1aVvAXkJ2GChQEEkBTZvYY8UDXxHC6m105tT
XAh36JdrO6GoswU6CrUbRCpk53AF0ZxBLKqnLewjlgIU/IEq2fUCKqL1yHKWzvJ0YiqKIBCU1Bzy
w8bKquRRX6nUbUIna+4M7swPw4hqRlVkAjyXNiKBRIXdYFXfLkSjRBKtiRVRcR72eYBLvwiCjt+J
dMyNvhyKU/xGx/kWKuiWZCNBqGDzEsbw6g4fMWimIW2HRpAHQlbYFUuvmUrvWWLbV7Bp5g8PmaA2
eJyDI1yXcALSmWNXxLCjh7lhmeYqOSjSD5h31A6hHKrh/wDwHG8y1VZAC3mIchpVU+YoFZcraI00
QQTuAihuA5VPbB4HHuWpfEqqXr3Gid+kATfcfbl9RmdHmdl7Lri5Kv3OHywF80+IqHM8k5S6JRkJ
vGogFjsRLvmGjzMKduXEp8yiMl85PUReQDzHArHYkTx3BI8xSENbtLxHYJYofMQTluFglvU+u0q9
Qi0S76c2MZQbO2WkXGpao8MFyxb+o9KRQo26gYYbSs/UeLTzohlHPuPCorlBAISUmceJz9Bxrxcw
WxodQz98GvaoYJTQMdiYi1ty2deJetawhVarEXyXA6OwabP1C6mOiHmFBT1C/FKatL6iSnL4l8At
2DbQ75KFTUGhyZ+meVJyLUqTH4hz6YIQYLz84M3FnSu2YnDErssC8BwJyFp1xD9AMCKPBIQKrJYi
p5Rjhy7C2MHalCFE8k6ismyowOI6XbpLCBY4ektUqNtvNwnHSgFxQkpvUPUgpKMz5nRZLdE9tv5j
AilFIyMVrXSL2koVyWCbGqE5ixeeY3Gq1DYBooUloDc29UkIsYWuYiIxl4H7jB8tbBPcReEssKr5
RR5NLzDQl141hxfifP5inxi9T+YHMnutBgCqrhNcYynn9xUPmnKgjBW4MPEh0Ztlct4SAt0B6lRm
4oz/ADOSelqINuhosRgs5QxSnhuUTQIqF2e4GkVQlWfEVsBVLjFQWcTioKyNMAJYfwAip+0JoW1X
KgR4xqieeJmKSkXIZ2jvxA2JdRDfmcXYuA//AIfJrFHLP6jQCNK0Tc4NAV8yu6ql5RlpgVXF54wT
x6lgqOWZkECIaA2KVliuXB8kUAv5goEerENgXeNnARIpfiF1cAR/OwU6rDG/E4kbRUH5gU8IoBiv
0hq0Ev5gHhLkyAFu+GkEulyGwBW6jh+pXKDKtf7nV0QJLYe32YdHdVd0PfMEZfF/lzKtGNZ5JbqB
VK5F4cLC/wBwCIvfClQ8mg8/mCifYbhavvF0MRGHFcEA3p3C5f7zAWQgpvQC9zGiahUXtyuQqpTQ
lgb46ljNYF36lTM5lc+Zamu6Tvpl7Cqr1oha38mYhsT25gA0bDt9yk0GugvvzcQIaBLmjK0fslAH
vDU7MwqriazOVgYSbbbgq9FWrp7loFWteY3it4GvE5+3UgHWtJbSVtvNqIpuUUhzhexT8yzVEq2s
lm35XcRwpcbY3Cii9DUUp+PTmmkbZbfzOTaWID+41eextl8MbMut+qtFdSyhVH7hqnd3UBGkeV/u
U6uUKJ8se5NQvovM1zvuXtuQYt5AD1ElVw9QDZiErF6pyZapYh8SwUEtjSZb7GMelShK3UcVd34n
0IC6RSqrOJQpOYQF8kZ7JVxyVThdw6Tht6dyrBb9xDXMtWCu4nJXMXA4jVNsTYK5wQASchmvCFA5
Y7OamSteYgUlV4gAO/DFtBrxLTZVeJSaMpPEJtLMHAgKd33GuiIpyq2Uv4ibubBW+0mm3mNOcIWN
lnUu+Gy0G7AE433GhlPO+5TqpQ5yc8j1Dg/SADOfEUm5Gw0m8VktqIPTIPSiA3luRs5A9wSPMvPE
uc7ZzLZo69kBpFd1PApDuVFZ9+JfgUbE4gcwuBXj1AJtKS1AtxHKtIsh66VrFfuP50CeYoEbB1Fh
odziFTN1g8TXx6pIPLLO0ekUtER+O3eQDG2kYR0MDKcREUaucS1i2jtLGQ5U6irQW3OcDcZ9S0U9
5cxsaRlzIgvUyM1lcjVcQHuJbpLQOo9xuiFYbg4sQoLSEDhlhUYOxwgxfmiROJR8Fw0JVimR4Chz
kq2c+aWgHggKrjiDp9DWQqLIoL7jGAC8xmGIPESb6O0lylFmQJzTKhU4YuosRVONjVRQ7IxaJoqO
kNhyf2jNfcQ4KhrCJiAss0gUuq7qch4WNUwYkLpFU7n6gBAEdzuYyeiLhRcyM1wNhxqL0N+YtmSC
QSzB3REThKWA8wXvuEV4kUjR3P0gsOmgcSk4jm0AgYaSlMHBbGXEjoDoleVypIfiANZxL87y5bbP
iZmnKoDfpIw2lmzuVAbacI+7VwHVxmsYvrK0w1SVE+n8OfMeJoDbjGusPBG5+Gwl4xNKhG0g9VUb
YpLKlQcaOclnLWZr+ZuUjPMIRQv7lxpcboyCuW8QACmjmVlwEwGCey9QWn1VUUAnsYo8BdVEeil0
8L5mAIDucwaG93ArNCh+4XegRpkpdUwd3xBNLB218x8lOrKuDujZDJcUD2v6gIceiYohwf3BehdB
yVUpxGJH4C+LVUGW5Vst0AoDteYZ2KRHNSFEhkVot1BltfFRSm6upWRotBt+4zUHND+YKVX5ow52
xF2C5roAJAaKPRczSkLEhmiC1QB+5RcdBzLCG6Cx3HJavukPcXgW/uK2wtkotym6Lt/uI0BUUnEp
7gOYYlT3UyDFwJLXFOHuW1NAhubCeA2kH8SthCFQtFWwAVUytE1TqDNkkoYPE4VGuDcZQlUUNeiD
xqxKWJqQLowIzeqN+ZcN2MFYv1EREuhezu3BpifcUMI0scxV1KqnIEtuiK0PkhKETw5ZiO01gkbj
vDJbrCOgFLKN3ddRh3WAYWeYfAQFCb5jwOIoLYXFHOkRfG+YnHUGCCVVbAL+ZcbhikF1xLpd3xBA
MoLG1iA3EFtNRNyN28pQ0L+YWBVPzELnDEfZ1EjYBCednqUp69xKw4fEv0jUvCWLqYHBGcuAg3ek
wXVrLG8wCxS55tRBYizmGDn3AOtzi5+JdKM2WV5lgL5mLg9x5oVC6MOw7G/imDy8xqiZfMty4i2o
4l7d1OFRNaMjOgK+Iop15itrIVPUrddu4DgJAGjtxVuxNRPidDFV4itnn3AypRWcx8nrqYK/BGhn
M+RTAVzUgTrz1/8AizijxvcwCycXBMrRxcEtvpKKBrxUuWuHErbqrubhtWXFc6BMO4bFIQnUIkFA
OB9SmNiHi0wCkpoRerAz1Hby6xgy8C/RUsQleCB4QwRseClSihU7qGvpTsnJeBTVeossUBctxXYK
q4FTG6nxCs8xvKicyHxLsq1BsnMxd1hg4QApSObDgKB1EOBaIFHUA9idzj5PcOUQT0a/5A60txVR
H4K05qMyxc9MVMZLOpWlIvwlMSZXzObA2dwClWqEzi8VBv0NjnYUgUUWTLATYA6mQO7iSYOSQ2BB
/wDjiAKrBEGUAhx4jFAGEblYLoCO/gbDSUyg7HqAn2FU71JDj7gtCz+IWP2tkZB8JB6lN6QPeBrE
GoELtIAd4tRxLF5ID3ExBqz1KjVSoA0BiqiCruqhw8y9wKUXjiDEL8vMctC2RfEzHka7lJR7v31C
2IgnUqLxBqLxsHtHbcdQDRDqphUPhLoSpU7hThc1V+IOSg4bU3+Amrsw/Yt1OeDIkAua9a4jRNJV
73uMDpT4EdXpdvaWKVrdHNQ0GjZncbKvCjiYS7PHMoCnIevEvMGV02pQy+ZcxMKB7gKpdwWqaifm
gEf5oU8IR5QLfMduBtdrB/uJEtuRXsfuFydmRrkJN4nXXcgstEyKUVdbHYh1a6qOx/xDAKWWmG8T
FdjHxCisdniMDyARdSoeSfohjksG3Zsul30XCVIyoutlaV3uH4hVr6WKoY4ikCGmb/MY69YQRj3n
wrrP+ys8e0kejrBM2HC2cmjBacJ6ggEoStHu4NFadIjmytS1JLGhgHk6IEz4SrrblCNBXi639wEL
iEf6l4RFwb5mZLtRvB/2KQFMc7So+dXybeweBpDRUtjXkguv7iBSiKjDKgNt9y6iURV+vMbvBYNw
+KqqbV7AbCE2WVBJUSj6IijKUrbfdQXOYopv7YzTZ2F4w/SVm2Ce6KgTXDbtitQkBgHBGKattBfU
W/uk0rn9QS7c+VYF51lxF7xalFb2TFHqZoceYYjAoa9RKYAe4KJwvuFDnUbDiWF3A2m1k/oIa2IK
RQPDHrVXLdHPcsBf3F0v8RbwfcrpNP3OdFEOxxceZ35lgP1AtjI3/qKNHcbFsAabqWQ4SZWMuxH9
wBcH3LCMK6CKtav1Gr1+pRwZOs/aJGrg1bcG5zTFsbL7Sl9xuT9EHau5gv8AUpFnEuyNAC40k66Y
YeoMhgu3uZtxvuVTDkyP6hRNjbBsbx6hlpsSnZYKNRbzfyQNpteZU8t3KSyog+HzG3XUVY75i1Y5
jar6m7UXdRFSj8Sjc5aKgaMgp5hY3mWWNHSm4GFtMSEKqYVxAXzLFJgxXeVajLoLQykQsV8RAvku
Llx8Z+JdsWL3UMGIgvmURWQIpTFwA2K8RrDYfJKLFz1GUHkpuWExaE8zqQtqE1BaJdQSoNcljAPD
AkCm+r2PoBBf1AeDlgRsF4IM6Wyz7mThE0/EsIqKNxHea+aI+glXmDejZBVctn4isLUWqtm3ylfn
zF+g0wARy8ypLvqHQobLYovxCl+GYq9kXk9ws5M8Qiut9RW1arzEW4xl0MyUeH3AqDAs6oY6jjlO
IVrUrRupwY1giK1KyC4oGo2UuO8SqEfnsj4DbZBxtqXx7lArq3zbAkvYnxAay6seI7NPs89wYClk
vzUQkpXLndKRPPuAAG/4ZWVc0fEVHHpxZ/2ESmlK9RRAWgjbOnU+Jbdi7bjsLAK3KhF1c1xsGI6H
cpTnb2SnkTONlEegbDS19Qt9xpcW59Q8l3q5bDetdMAHF5nuQrZQKjcAOXf8Tf1cdcxEC9A+oLzi
iHgKbfzCal8Fn+xUYvSpvCOUyOnQBprFCrUequWTKKCExB5DuLJLURBA3kCEiaB7m64qD6Kl4XgS
fX/JVEBg45l5QFtwClHljcVcVfEsm+hO69ykECWUV8y6SeiXesZUGxsFiv3WH8wgeQn1GQMITQYK
+Y41Ys2qF5osCMZb2FMJzPWf5GRcdrV0Rypf9/ma/wB0PHMwtarziKELzZEG7QxyPA/UDCpk7sgt
2m+/UbcH6GxjQoavxL2+Fixt5y75P65tpW3XMCn1JhUWj7hRMgzcqJirHPzONOte8IiRYtEIviuz
4JcoQRfbmKZn9B/sq6MhgALjF+ILX/c5XsNXfV9zLRY1FFdzIL84DeRzOiOtrsMAgyLwajYadsqi
OSYbcdsGOxeDeu2OcitMNohavN0VDeGCDjxUqV70ezK1kglnuITtfSVXkSh2MXj7pioBE6xPMtQm
pAH3DpoUvJyE2VWLCFvf4i1xPA2LBQLQAbrf5lc9NQc+4UBoIz4ILVKR2oBhVt6RD6lw34m9TeXa
zKrov6lFqoWuYR79QS+huyaVHPKyoDj1GunYI4ghCGK8xY0mxITv1AcuVE6TncBEf7S5x1CgemRV
t48zZxcUK4inPxFh1EcKyU4JYrxFq9QQJhECmycnmong2MNrmYwjKKA5jSlXChwzJhOJWRJ+epgv
sjITPmWHTIWZ+ZyCNW7CWpkAb7j4u2olWhKi72BWtY1FpYK1nEDwz1Ar3LnowAJ28z0kYrTbjXXi
KBkb4/uX2DjxGhCETgjQEaXknBRejfPuFhUFNhgLqOCtnmX6dlFlH4ZUlIownUp7ZnC0a457lapR
EXoHpgolx7g2WXNFqWa2KtefUDYGn8RzOWCLxkwfFwC7RPEsudCNju1Nw/MBXNkAWeYoyWxVduon
DzKduSV8JRo4gEd/cLXVA4vuXDRjj1EhdRuax6iLxnEAbT1csGGHIMLOZ5JhiLVELupD63DvBYoS
WlN2tsbshf1NbZB9XC0oUmRIUDQ8PiB2jT8ZBAyWj55l6dkfqCM0sXLICkUcxg7BZ1TDQ21qXA27
8RlbC8nLwy12XfmK1zcApDe5SlnUMLhQc48zxKi+79RAqhphasIxqn8GMBqUU8WW34vYOUUTkblm
BEofUdvA8lxwaSUNs6l6hrjt1Ai2rUsyvpwzC0C8hcNTRLX1LxEHF4NxVoy9buMQKxXqWkIXfuPu
Dh8X3Gr3/JVSkXzazEjRX7iMh8PiW2gNDwTghQCnxKNOl3WzmlkHUMlSiA5vURGUGw5phIFwNiGe
KCVqPkQ4ePmW2aFP4jIKCohcPT4gJ5sM5lyF05fUPkQ0wKQblyoQ5E+ZY+UWTmN92eoFW5VGNbKf
5IEcXDcfBGqQQa47TAb0A7lASUxoqMxKeFch8K1tTYKUVcLkuiXmC4ZXaU6Af8gDtAoN4gVq+B83
GOE08+GLMe6i/wCYv0sr5CHN0dnh2JzZWCr8QlqpFN/xDtlpWyy/kX4uEOwAl/MIHZCDZvfUS15D
CsIRR1Ub2vVgb4NuBPdf7Rd1UPslLQ3t45ja0lb7KjpaVR8GObL8PmMNDfcdQBRZUFLkbinLTr8M
RaWl8i4KbQA/RNnyPSpSrLg5S+GcHwWDGUIGm6xJUwVQ92EOIhQN+4lpCq+29zN6RT3RGhCwhwnc
z76xmI5Vym9d3KQ2663oP6jH21vXqC+os024Hyr+mNgNoFu2HqJTlZ264hQioD5vYRefeAxLZLwW
w3bgfVGD5EG+4kdh8IrDyYH9RBBqOgggoQxb5ZjfBF4eIFJSLtdynNYul8wZQ05WCQa6/wBoegta
u+pU8ea0RSvzWAf9lrE5F295KBwNIb4ZtYAcbh/UE7dg6E6ErH0VLp5BRRwT041BTIUU6dzUOjvn
xKDXAujmDzE0fOzNSpfQpF2W/MAyqeJSquJH1Y+ESlUDFCP2iJRlRPL8wLdnEBE0HL4mTCLDwjZt
5j6CKU5eoWHiMgzmAFPiIGLt6iHy8TCwKOojsqKzaqWFbsHn3G6XMlJpWPgQDnZgnqDBC/cQnqog
o5hpiK2ztWRZR1E+UR5yAJcfwlWrgiFCriZRvuIFtk26NGdu1iV9xQPMWjbt4lpoychXxEAynzCs
fuCEqYngPcQGUxrtc7i3Y0HUcIGrKBmSqOD7ZYFPTE8Chgip/wAjTEhXhxFLIli9S6U8yuF0Rw1s
u25aR4TLdMiJV8+WKgPLLt2WeOO5dLdvuWB08ww2vcCse57C1yC4OfMVWAruWC8lpfctzFeXMsC6
IC7cAtlKZWeIqfcFmj/8ZJQU7FoBICS7AjRFKuIW7PR6gaKbGUoD3Evau0MwWFNjd9AuK0EJXKry
LJ55UvLcUBDm2VAtYBvkvuP0BF6xIEeKvML6F5Tmbo+kYaWdDB4pRWxJITS38wgW1PzA1Wa97goA
vyMcqWILkYhvbJsjMUcRTjvuEp/E4g/CXoXM4cGXR58xZo0RcruoJPA8Q7hHhCgv2P8AMGkVnIZy
MANwSFuKaRoUuLeoFlZF/MBcVzjewnuKnLyOoBoF8wNCqY+4FXQqdH8QS0RbfGdRwhGs5gACddiO
qmLS9VDw9tssiqXZ5ckHmuuviDO0CJMN9eElis495yCEOshkJqGOf/xLA5t4KWV+P3Ak1NiwZc6P
tKPKr0iSFj06i9dgApMPTdPxASUafGxuoAZaJBDRcjezoecjW2pZ19ymt0ByX7aVUMj3Yjv3FHGq
oZF5UFtKh+8dlKgUUNDZsdA/KiNAEaHjZcQQXaKX731ELtKnl+JR9vU0+ZQUDsDfxAUCt+IKDxQk
20s6IsLpjS2OXBC5TZPtBAvlB2VBAWrRB9cB24cQLxgVYe5VEDFSNjclryEsNCVR8wNUa2WqckaR
tFRbDfpWqgzlN8zCFX6lxAypQkyhDgkJCYxv+YRVKKG67QQRVGL75mzW6pD+KjvDxdSwdTdnNioC
GFFxIpg0SU/w+AXsDXAIAU/MelfAFtNIQzksnSLsgpLrAbE5IhqJpVZNlikANe9gX6NVSTBSGnXz
NmnZurxf5ixbVV4JT7fXFQogEeSX5jHybGAYSwvM+agqxcr8yDaavoQRwZKkJVDRc34R8b36EZ85
Wc/JFCW14fzUNyp1I/5MbRD8MUn9gctmFNpLc7kEWBq2OYOw47HGUO6vx19RB3xVdwMnka4Npa1d
uLaswckXbFVsGosA8bU+KZXKNdgXxUZCmIq6S40aux/5KvUQN15fiB7gq+FfMJpE0P7jAyB7Qaxa
EW7vvxHKTRDf7YgX4XdStpFIpb4DqNdsG30Zb2nZFuujqAS7YTtnrwQbF7xsoIvfEbV8yzED3e44
fNzgKv1AINvjYUcktaKjmV8iFjYOYpYFkTemSvqNRzKsPEQCKsibbXxHQefMFgyUAclIvEFlhnER
7mrNKgnmJTsqgPmFNMep3uXkpud+J2jnzHVVDxCI2tzLNo3EFvMNiqnyMGSdyxWWSgghXLiKjiU0
6jyM4U6iFyqc3zDaVDW76m+NJRuRUCyaukzxKKzIeoKbfxG5p9wVpUxxjUXA2FL4iFfwnL2gAAEC
uTIpdR5pbb4iNShO+y/EVGs5iC9FyzeGvB/Mr0GOJgU3KKzH1Faq+5tRzCo3nY6nKxCPmC0PEupa
VBAmepXghlq2K2PuF1dWEpSycxbExXwTRAeZXRHJeCus7SrlviXVbJ3YLURVO+PMuP5hLjL8kIV5
TkisOL6SM64plrlMe9pApqmHA4DTAmiwQp4S1W4hcQM4JVsZ0hzaIWD4pplDTHlKRng0C5O7VtpS
h2KOkFO6UHj4jwo0XEApNwuT4lRMOCx7XYWWyuS6vcQoMITRMhmag7BsbabLF39Tt4uaKpqWpWeb
hae4RzgjiHqPlMip1VsznNXaWkustXUTbQ81cJ7GtGnqMiBpuESAJhbcWKIOE5ASJHjyloCOGY48
Tca+oRXV1KyNFfhsXJMYWcjID0BxBjQxNIkgAzksdWualTDQQeGnxDOmKE09S6XnIYJjes4LgtIh
TJfFo8BRHJUa/sQQOFVaL5J1BCjDNivJazVV+0ON857sqaUVpcc1jKy5qDyAXUTYw7hbZHviXSxc
lJDTI/b8xh8srmJEyuMzzHiEsnOUHdQKTvLY+oW4LLMCzyutkRDPow+4F2GWpDaZ6YHe2kqvljpy
9rSy1f8ACa8h8m5Q88ooyzM93oQim/V7FAWWxVY+YEBH3eiCWA0tT9RlWBZZzD+g7Ig7IJbEJYRJ
yrlqp8y5NccCMU35Tk16aNeWXBwckopCPaLD4USUA97tfzBqSWNr5lKDy3Qiq/W26oiqcUNNlw0L
yVridAfHMWA3SnJuqmAInIn5uPPCunlNJeB2oqBYlNGDzoF0KocdoMtjXV7AXZYN58wA/gpP2ikq
oce6ric5xsYJzh3KkbuNYKTsYnvON9v3DlaebE1Fji9ictpau3H2pfHmKdQ9lpAFo94o791tmXrb
ky5gOmjqGjzsHn3Ez6lOZqRb5XRLAJLqoCbJTlUKmHQ/qL2IXzTmall9TQzH1EvPa4PVZo3hlROS
BxAxToBeyvknHAjORC7FjKnTmFcQKW8a5Ct9G26i1VY9BAgRWsXLvI5EuIZWUupfmUpAaxc46vmk
UPBZ4qPYbx5GXVzLS2Q6zrtI5SPxAaYTmEea8F/lC1RdoMDJB2O4Iu2q1/7mHaJMu29itrvul3Nm
otEp7ilXkv5niXS+PRKC8P7iNoniGMYtlzJBviNy+HuJNHLKRbKUKv3KGBpDAbAeK/iKacMpCa+4
XrZcXalsTqFXipk7X3FFVslgxbvMargLnmXqGEdlxs5E3n7hie4mtlEfHUbvTzk1v9om87nKSXs/
Eavj5lK52pQWDXTNNuzqFue/MW6JV5AvaOFhFRVZ5lm7yCraX3KZnPcsDF8SzXqBZ5gj0YujW9Qd
bYbK1Z5hR3fbOHa7qLgnHGzlPUaR0yigbctQfuBMReiwta6fcFMWnqW2qUAqtio1zAB3Gbp6iA5r
EvRr1/8AigFfE5BNGQETdjabVcyil2+JuoOSwvtnwQb3AKCriX0L/MNQUvMPit1BZCvMC5xr8xp4
O1KzFVDqV4aifsjRcWBG/dwsB4BAgr2hMgcCm2awSaclbMpVzASVJqBEUhs74wkUy7YVUQdvlFoC
H0mrIlNRNGugQLUDzCz2jL4g/AkC7CGqouWoz7my9kxXOoLluKgzr3As8OpxrspfiSod8AaVX65+
JQ8F7UNLra4jBS/MdoBtZU7NUL6RlgORG6kHa4gJdc2dMWNFOQ8QTQ0qeN6We48g06I9OwqobZtW
OZY4AWzi5RI8kFfbXCWiB1U4MqaJw6JzXEQ49clwdq5TUIOlYhOuQ69xV4niaLX0k5ePEstlZVS0
AhFz8yssoKNADaictyqKhIPVQlKXwEq5ArHMvxV5DZyoVb9wXlrRz8QLCKk8HETJvo8LnAp0oAQc
F+0jQ4YmMagpZZqMSzE5iEdWp3InQX1UevWlKalAId0Kj0huhL647SGVDdlG5OlYhJd1wyohW6EL
lxs71BANlWn4xlmry2iVuKvmVl9pULfFxDmFIn8QxZyhf3c4CCfaoait8QFPR4gAwrlhKtJbZZH9
kr0rIQevK+YOqPRGFVWiHURUB8nEOhcPB3HHQfuOpra9yn7cFEpKh4RCEr0pNC3ZkJWowAGOtbNA
YmzH4loopf5jtHZKbruEiIQFR8s3SBxBq3wHKjrTS1tn6i+okVUI8q8SoTe4lM4AQuY5raL/AC6h
kM31xahbPOcYEeSk7xkc1AFALNGg3Z1cKdhWb6gA0tR4hZRkDQ10Bp8MIvAsxXmCL4ui1hSmeFH9
w7ba0LEKLcEBXu81sciNwQRCBTZDm7eWGAUYe0g6T8ACupqMJWNiVFHJUahvY/cstuWFFHVgEMDY
fmchgaVlcyr0YsMQ8QD3S3uZUmCrhkGGu8bQgWOXynqCyDOR+oSPeUoquiCRMSqILINaj6WcjvuJ
xrpcHs+yJBhaIoPHzNsJt9l/EonWMFt1zARfoLYXkJyMNhV+IRbZhx7S5ZdSeI6VrYVnYdJU5VLV
vXMHuSGsuKvgIwW+YEBdiV+otrrYcAQiUu7Yg4WsCjRcGwhAEHfcqz9QI5yN0lzBu4PClwE6l1rA
UqWBo5hfnKO8EELafcR7MQd4gJoiqk24CuD5mIT8Qx0QKGu6hgQ2AY8TgOpaob9y7GlkQ+SdTX1H
YVsu66ggWiUpZazyeI3uvmVpg20tg3CaDqZR/MbnB3FyC501xsR7V9S8L0glgpmExCS7fUOSQ7IH
qNA5SnopjcvucFk5V2RrkazlxsFo8THl8RaSoaddqVLWjmG3Wjifc4epSh1C/MbRfTzFf35hjp/+
FyehgFQX3FtLVcO+7hiqtwgJebK2VmzX7nMUgvYhXyW40QjwSwzoM76hLVi0eoija50rnA89D7iB
nStS6icFisNuHLapzwxUYTuXQGgTnMJkVWk+/wDIIPzC2KLZcFOJ3Wi/OwqBUDnXUoabWdg7iWmQ
qBWxtUyK49eIG7YHUHzhpesQ2S6w2+5YpOYU1rCqcN2chu64joSJS1q+LjngDh6iNWrR4gCziK8w
sfMPqUd5iyniVqE9bYA6W5OreYeGeiQNCYrBc4ik5gjGkAeot0RZbzAEYxo3NzJhXVRqqa7g5gKv
W8yhNBbXeVON9FIiz9kc8GhjNyicjRAFhTcr8SoU8MstPB1ZUkKPuFYr4e4dCPdR+tJcA5crkrXU
DAAB1xEId0hZ7i0Db/FGpDocNwcgoJRGucWzC8v7k2b7XmJ03Hj54i/AOO2QxVyPwqCKgcPjYh68
Xyic9spwi7iX8Gywlgg+6l5WbUQXK57qO8WiihcoIby9uY7/AEvZko0EXVdrDJdCyyvUchZ4qmYt
XMckpODAcRQd6l8EXhcr85kqFDzggwlNWLhjdtTUGopZUdTsrSJKd1+rmOYV9NgDpcbBTalZnMs9
XFEjgt3fUsQaiMhVX73YJgFjSy2oNVwXKHSHRxKkiyo0NfNQrogvCBQjAChvk/EHkklThzFslFJv
zPTlG2ZZWYvL/Jnb2oOYgFsiUhbNfk14WcSzi32EQyUHG/dymnUGFY4eCsBGWD2YF44dhCpZOodO
nXQ44/MvO6QrghAnlxacf9JR0DgjIupcsBdQDTDtZ+Yv9wk1fUBANDK7isdUFRxaZPPIiMZ1YSjO
JYXkdPZL5gUEOMgU7JUs9zKKHe5fECt1E67RCk9MTuA2mcx86rwLeUjiVutmPhhUhYdYXAcw+c2q
hahQn21HexFc4x0FWK9ZFGVaoBCZFmrkKiVfeBnELXEp96m9iC3Vn/I8pVGd4nL3hNn4IWwcApZL
CgpB46qZHlTUFsINbunm2pWRoHIYFNunjRe3LXEWlUdE5LMSp3cHXaC4j22pb+TYsLgp08RLTQTp
l8naHAwFCxb+G4i3AQt3cJ56nWArudg/URcceJdi6gdFsTCdyk4HcJWxWDlDaspYAS5xzEbCo1Lz
1MC6+ITt11FTJZXZGw9VPIJQwufQSlRz2QqGByc9TBV3H81s2OBLitXXHmUKvEWWuolF1Nu4qIWm
LTVhPoyiWyi2XrAhbIhYWjUaabfuLb6dQe2VFOz4gP6pgjm8qUXceoFS96lF1ti2I3f6lGo2kpO1
BBF99Q0aZLQp3uLhqmWfKNh/CWnn6RbV3OTeToCwgBz8IHSgSxRBpRuCpXqJQ1jYxQ4D3LXX8y62
9gwtzuXYXfhAMLOOqgrCZC1Y98TdDuXBkXaEVqvJxPgEQu9qfiIpbkQBVH8xrkEVIG3zAJRfqCwD
XUYE+FdRKO7lR0EvCz1KkxAd1Rv5gL0ha8wkLXBzHqkOeIJ5B4YJDBPqCbmxX5IMY2WENxFKB5qW
6W437le76beIcGXDxKqNK/7jE9y1H0IcnhP/AGDgGxoIAQ23mVRyECrp6iIEfUufHxEqm2LdwlIQ
aFDicl7gV9IyJdNIGh1eSzFgIHCUnAmy3L1wG24RBSc87LX3RQOIUCOCjHsLFbZn2NfUGmrFxHyr
QIG+qk6TmXqx0QbQ2j4EB9ByXHrlNvcSiLNJHD0PAVyFyKRfUfkk0vmPtTD4OoPcwLv4lDzaWXH+
IuA8S/Y94LuWkPa5YEgKcV3ASulg+anhQB1EDQKRHmLIjD5jBpVWNRShE5JWzSrPJ3AsKstzlWmo
BXkXO4Nf9jplAJNVKS5WibEdOZYOtbccClIMpW4GtZdFfJGgJoWVBYGcFdRFfGh8BGltobcyrBm7
9wkhauHe5WvJY1uThNx9uIKc0W/MehS1WqibUjmg/wBx/tnKOW7SvcUIVd2QeaFfmY7nXV1KLjOF
EbAwDYsKwyog0H+GxcBf/UTQ4g+GzK03dx0oaWJY5chnqiCDBpT9QdDQT1u1AcdZr1DZFaOrvPME
6xESAKHSP3cJS9ncsMhG9xhwf/EHYAoFrISRLGxHxLNMAO9mtzd9/ESBfbfHUEwRNvYxiepTydkT
nxv4IA4t3PjYMY3UcqFs53daXvH5hKnXgfMTNdHe4q+aIJAsjIN4P2ReNt4i8AH19f5NbUlZ8M1f
XLzFNTgLiTv8x+q8yPtnQ6kaGIabFnv/ANctbU6vFDX8Qbkj0NcTc6qvdLhyCVElBa31k6zjPPP/
AGfAqE+ov5KXyMBoFxTvOX+JblZehr27m0BQ8QefiMA1t4DC4IJ8IRQdAKeFLOKSfDLjdRDyJphz
0LpV0P8AsWwrZMQXX9S6EyOVUhkXr1fEdVS0U68fqGi0AHlr/sGCpdKReP8As6+EyqncMqGezfcI
RVNXxRDI5RTsDMGllkeshd27aAvZUcXChp/Ud3blXR4/STXUNFN3zDpQHAsFrBIbR8g2g/ESkEll
nqMWWyB8zoaRHyja0HZ9tRdKwJds6iHHlmS0hID9SgOmWVMPcNBciFOmWyze8RKpKHiabCoNwbW3
FZlHcLKIleoxY2WNJhSU+opKR6lc9wNXYC0nMxSQnENDOe4kDLeowCcRFbaxiHixg2okBGKEVXmi
B5F9GBcIGVcUWxpQd8zlEXTSXFcTRUSa99SqJDDgIgSNOue5dUlnNwHXLjQMeyFo4rsjDtyp8+oW
yb6hoXT4nQ4CCMPG31G0OX2ShTKYapYQ0+UKl7iXcVZIlqS4BnT5lULpiAW9zbI3jgZbbcC+QSZz
xNKVUWgqXstvTmDhBWOu5TVNsTBK1dciJVQOTTBUbgOPMRx0bPg/iZgcl1KQm+eyalciAEpHMFdp
T9JRrS1ieZX5DtAOlHdxNiWpRBuFwl6/8gHSJsi51G4IawtIBEMB5Q4ghzm5cY4hzFIgLBaZ1kcE
C1SJmmI+/wDsqcaX8JaTjVvJcurGBB2JE2bZLwy61+CVZjyQrba2/uWPjmF13EBeDFwOWRpZVMdR
uoJFc8S29fVS73GJw28YNsv1FACpjXHufwgpxdLUFajcURuK81fEBOYIbN8y0KsdRRQ8peoUaLsJ
U5pL+sS1HmJaj3krxnIeZjS3Vw0GgX3AdsP9RY2kuQbl8wemW20WnqFYlpyVeLmMD12N15qLEKAj
zl1G2dzUslbN6xxOCCRpOWVMhqJReCrJXLKOQohqt+KhJCwgl73EVBo+495lVH9hvfUSYlAfuCWA
cYt5lgkWhtgr5i8YnlMyVihYo+51WpbzKCLbuX6WBpozABuOX5LhqCT+GWA1KHzNzL0ZxsC6lUPx
GKDfLWFYBGu44+HQ+YKHwPi4/QOLxYoqyvJHAgrZ4lE5asaYG1LbXBU43SDqlFUtZ/sBiFVJTiM/
QXIEFG+/FsJUo5X+Yvumk8tx3OFLmAUbbHakIOCzYOzye66yIc/xUX0GvLeZT9nWvVRs3Ha6u4eA
YHtqPlmvpDVm6NQHRLDMhGijH3FSlWhp/sKEKttxDNarTioQVpP4ZfO8g9RVAZV4KyX+TSPC8QSN
AH1G4CgrzWDMoOV/uI7yH2YbAiPGzzDDG2w/9ss0Z09pQnpadwkx3bnnmAMGnRmdWYwEhB8snale
m+4hVLvsNVAcl9tHpIImkXi5S+LX5YJo3nXnJduLY+TD064PRENgU5XdyuiDJzkULgw/CEg1AoD8
8R/S2wLXyEbMNgWXb+ZYvAl4M5fMv83ktxYGRXWDuCANdkofNxtRFwHqeWH4DPevQIVWkoR/YuVr
e8BcPAoa41X/AFGKM3BpYcrBGDJlES7Bz/8AIv7FbQg5ruI1iFbg+Ze+wLWXUH0u4DArZeQelYj3
Lr3IbroliUy+EPKIgHeVENFIhYus9RWogpoW5aPqW6cj/IchEFXWW79sxy1eDCxtCIA8whvzho9S
1ZotVd/bKCTtlgPBE1vhiFW/UY6cczjB9xSRQNcxzmHIZfU5In3BW8epRXKjaDGoo5lzRnGELKAZ
CBVxfbfUTvK+YUF8epgBYxenB4gIukKLpVjCFWy7x8MRYcA2DRcm8UkXfUeCyVgIq/tLHIEsU34i
xVKsEB4iAHIMHTiIMcL7mmXsdxJcIcxo06y5j1EpvqdM1iljyxE7/UKONvcp8SM0SXRTZX/SIVoX
4m+Kx4rxUc2/qA0W/coUdwbasgc9SqF2AXFPMdZpxORMefEbQWMSy5r3EEyK1ddw9ojLWYSlHD7g
I8S1J3Ea24ezZU5RKU+JYx67l8yJKtpR1EwXcrVXnMoHeKqfKYjyVzLMFXUKLbQawyHZAND4jBr4
lgLoe/EFhZvIQ6eVjgjxmJfPzBYTVlISqRdrixFwZT9cwzoaVYhsVi6bqWIBY0E/ELFJC64S0fiX
Z+ZphQOP3B8QnMALZqqeYODxpa8mxdB22V6hwavI7o24bQ7FteGMin3LmO5WhXXmDtYwvRIs274j
6Lg0Vu4ltxCt+UbwJSrhqXGcHhLgpflN3YMDTi+JpjeCWoCPJElIoq8J6S+YGpw+91FUGHjgkSsd
nzDSPOkYxKHWMxxTjGwFsxlYqWVUHjmPX0NL5lmQb1jqv5A3zFFPkLgVjgu9ibXYDj/qbBwBt3Kx
JWWLhU6gWrkuLUxANjHQ2/EscuiBhoTYDggsVlVV/MH0o6CojBd0HPqK7728M2Lhx2fuMz98mpUM
aNB/LKsS5CwLAJ1a5f4yntc36bA2ANUtcEbEuyW89x6RQWIplrT5It/LLmbXJuMQ7kA38w2QHAmf
uUkA0vLK80CytiUsTgMRPLByikg1db6g+qFKEjZTj8wsmWGxgbCy0lgrE1hfnCym/MdsBVba95LM
N8ljuyrOgLgYAgEg0SyoFGo2i3K7hyBx7OpCVQc/UWNPATDqaqii2fpFRSjAfHlIQqIs0RgC3C76
bCbpMbG+b2DAwWYsBkTyPrI4dZNvxGZsiC0XpmAJwvmPKVNoTHov0qNnywtX1LCJeTVlQ/C5zq2J
eXbPgI3FwuxX1Uvi/wBrSREtcRC1eYAbpSRH0RC2VHNe4oSm8cfUuwXAA/udyCOt5GNKdhyMFbNZ
RfxFzwl8BCXItXX/ACN7qDXr0bOLCRbdvlYOZKtB+eZSVo1CvrYDqWmBvy7Fw1bV7nPwyO/mcoMo
1SXEjKKF8vM0Jbb7QfQRLozxURIBQXSNBJlh+U+numn1BdxhQK/Uu0LatB3MF2CU6EWVAa72ZCg0
XmPL/EJbH1xUWu28uEr4SJXjxO6ta6+4o1whsLVHMdlC83a7i/Q5c3jT4joFefqcEOO2O3qdyWA3
KpUnqCfFOWArUvSpRoL5my7i8CiwJ65SklLkx6YQS4zAnDXmFGbXVXAJlA2E44hbQrXu3nYABxl6
KxuqvmUusgKs+YxxbUU8MI0aFK7cLUo2Lbj4jI9wLyeIWnVdHEQs9kba1fEDxjGojeG5UsLW4VPm
IDjnRxAaFRitd6Ru0vNwnS1ENhldxHjb8wxS/CMFDsIxklVYFbiWAcjT+4ymjyeIjeVXaVM07Khl
rniNk1EpSFyl68RDxqJWXdZzBS3gJU7Z4iMurlcvXzG6ceY0y5Q8mIEHEye4CtxXNxS1BPqVLrfJ
EgwKuLUtkeSku1/ZAGkqtqAtXEUF4QWWq2a+jzFCJqdwqawjULDZFDimIOQGxljAQhat/XUEApmr
cJRTz1Euino7gveH1CtHYD4MSwjsyrepZK/iWFRx3EJpb5m4bcvDEE7vIlVfM4X5iout9ykqFe41
pD3Lv8fEDvxzFg4rJXOyZ6hOXHMD4K9RCA5HHEax+4tqNMIAAV8ztn8RVzk5jUHAQFFj3EJoVTUx
I/QtdWVTXkrGWIrea59ykJFgvJbgeqVr1BR3OLX8xAmPYoy1WxysrA1NG8+IIYrzfIQq7CRN25t0
kpA5lrDoS1NlzGkABzTs1Q4iEe5bZjBBuXOCpRYb3qFBcfiUsX4uLh+4gWN3CyC7l41oA5g7XL6y
VzbORcfDFgryNja4YuJToXkxB+ExXzVy1lis7t2GAqK2UsK3Slwr4gCErxo1Dsfk814qAB2Wlj12
zRtGSPkRlFvFJs6y7VjSgcWkN0btxTFRwkqodxTcZWjfdZHpWtaWdJHeslI7daVGD6F8y7Z8AeIr
7+Y3Cyq5lFgJiqqLDeAf0QquhmSFvKTp+I6FVSvENGzo/mVGwdb2eOCAyb4XgF3LkNtNf8x4py+h
LIipC0Qcwfn9TmeYsxgDAGtP7hhr8q/mJq1PVRcRWVVn8Sr7XcphPWLs0QA1D2iCJfXUoNaWyXCJ
xqMl4HIdzzxokFVoOi33CHQIrBPZLGMmD5KgFVkaojXv4g+X/h1No7IucWogeIjosOYWxgDXJ7l1
bOeIjZLPbHKXvEqZ+o66U8XUzyR+mEkXAc+O4eLg6aH1G9EaLYfmO9zkrLgANlwfT5zqb6bV68Ny
qHMq46eLgB2Wkx8x0Hb05jAbs5o6jDpInlDo1gyi2qGFoLqyiMpIL3RMeqJqnxUpgxwgSIsb0PKC
38JcyJ2ptO4ivL5qbCz3KSnDdiyIq5Kl1Hng6iOyksDYZzF2QVy+5S+Lawi6N4LENlRJNoeMIWKg
0SkxbpaMEWIvQ2Hih7iHRl1S5Soo4ntiLw3nVwllGCRsVleY2IKu2I6FPdxu0F3iAmrHuuGOVYdw
NA33KrQaK/U3qS7g+IIzDjw0woE1hU4RS+Iw5y+Y16UPUMOKTuMhyqEEe+ohsN9SgU05yCRJAB2w
5q94D17l9FZpJ+DEYA6BwPc4gLVyy4Tghu4A06Rj100cJfL4PmdtWz33XogBBKhF5qOJBBvsNQeS
qrmFctwzqWk8TLGwV+YZy4FECCKOSg8sY4Cu9X3KGLACx9kq6EjcC0Of1FwL1TAEbu9QDwTJHgeJ
+bi8sXV3IG6UKtP/ALLwkZxoL/yJjsem8wOZZRWoeJHRriXqpQ15hLb9QGuKqKVsZB46iQg3AGse
p02q7huzuwitKvUUUCobFWpiyqZbLgF3WQCu7mRUBel7AGyg8S2KIFC/xFQASqVrKg8o5eLgILRU
HFWS2HCsuGqbk1rQ9sAcDYLscMFvj1cznLC7G7cq4I0ysX9Ep40ggDuU6sRq9oLBwwNVVpxHmxTV
TknHzGtDV2U+Al3Tz1k2rpjr0Tve4AN36iynYLVlIBS98yiqy7jsh3jLG7KeoY9HmWeogs4Uy4U5
6isCV/iBYXeYLCY7kdsW3lwAooMZpGphR56jFRQgRuAMOyN1w6VmwUDlgZxG/mbrq5SToBUq8gHk
QfcBIAHNcS8t6KgY7LkSimpqqYXJnInEafDI5gU01U0mcXhUOaj1kG5HApXkioLxFXy7gi6lE1ad
QnBzOT+Ut8GCfGQxQQ9pTmiFCIa+6jLjI4CIMmPHMrAISu0c+FpqXf0LJyxTP9KgBiVqsA8TnLM2
KcwjoQDALA8sdzNMYGDhV0WSljA/cIgNLfhOLCasBeoPEFZDeLiKzkFRFSLD0g+i7UCNesU1kIgF
DI1ao8FxTispyuVa7YyUrFcDmBro5yHcNbbSIhE1nmWi+OeUwXY6XxAYWaEdkuup1MrCiOHSXGxN
OSZrqqzmEuzykOkJzHHiUgYAeL8ygnSjnIFEdNPcNR1VTYFUcVM/MulLau9i7NjR3LjO0OV4qDio
pd/UKrVa2cIELdux/jiz3ARtA/cFu2Ge6iWa2uQNFEqcEt+Rsu2peMKsZRkzyNBXUYvJzaLHrmB6
0nYKaDZft8w65LDYoPGrMcbAGAVzwyu3KurhW0hS0jNYJ7mBSmeOfcQUqr7jBlwDNsspVGfMGiRF
OGV2WAytqEBcSI1dxmyqocCVsTiLFbQpO2I4nQkYUA7O4TuNosxlGMFIgmgDo5iVVOQaxaK2U9xt
EUeS4IgveCNsq0Wvdgvhy2pmM8XVbCYA7rbgSIXcOMKIbuCDksIdVaeosdqBP3BSxQf7hks4EtWD
hEkQaSgUSntwr9xF4IA4p7gTwirvlm6rtoyE2LhaDoIo4WwU+mpgSgoHbACsUO3MMbpzSMICC1Uc
XAyUJrfcoQu8lhBRVWYKV84VLhAOh+CMULreg/8AEtAMoLX5hMPxdxjoAeGWNcQop1ynuBcpou8r
TiExqXm2e40IURajzk9WTr/KDqNxA2v6suL4m6xENNhs1ADseImMOxRT4nBraOW4b2lONVcJYOlM
rzAylk9UsaHGder7hOg0o5KqN66DZnmVsifRXcv3WmmA7ZoEACjH+Ir29xJ0eibBJYct4KxlZPMO
dq5ZJ2/1K2UGj8xhtBxkFP5IRZhXi3ULwIvVVCh0ge6/qKDKtIN83HdiXcr/AKS5NnCXfFQetoDt
uonYJ5J17nByj4K0+ZU9h7mPdYm9lsN4m8gj5fP6iZu9Zh/yG22qF808QyvQnQc/q4AmhhzLSsVF
rIs3fGy4iNj3KQvfMKbRfqJhwgjyURgAvxUYUHqWFVPN7AUjzHBWEcA1EA8xDy7gS/cbdcrqOCt6
mVsrxElePifkOQLB4GBbVWbsGWoX4Yn19ROqFg0fhUWlnPiAKimHmsgKdV3CnQpAIqVbMdwBOa1h
Q0D1O9/EVYhxB1TZWyjjvKWDVeFzW/uJQbdy4vD8wt69xFWcjRo4ZTXu+o5h3hl9TQoR41LA3hAT
iXQVzK7bF358RbcJ+Ig5c9Rvtb0QbCl+YqlLOs6jRfaLS0IDMoMGFG231OBqAKNenJspXGlr4j3X
VN8sO/ovjviEBPtwoBbYeIjLZVOjxP7wBkYXU1fU7iFJidVp9zmbAlFl+C7F11NOqBik/SaZxUJh
unqdygEEDxnxMBHJk1wzT14ZaoVXiE6pQRJav1Eu2ipxVHEoIs+krBvCDv4ha2m+CTSF3iJ9oj6l
FVeGDEtBszyQKrsHT6lglqB9x2qlxByBXtOvmp8oijkx+olilus6ZxdueIIuu54qH+1hBAvbfKYV
Ki/MSGBGiAwWG93OwN7g4UXJfdwHc01MeCVC5bi5EC5QAOS79R6e6gfEL0q3KdQg8RaAZdwoMBVC
DQBFIojYRlq63CoI8eYAAWYVAHIF+JWadU4fU7KQsYGolpcM47VKrwwBcrT+GNQG9W1eyot3SHdj
DirVKMq5b6axGhbOJRfNz5VDu+lVSGTiQ02TT29RODxwPuK1l8lfdRk9IIcy9KTyx8kNHos/cZva
L/cAkoDXlscKgIN9SkRLtMZvZdCMtzRs73meK2/7QK20d8bKrJVvh1F7s9Ry4J6Q8HD9xZxSpW4n
GEsiiK5wDmN3GtpuHVQBfippRN7NkrBiF+WIQ5gdqdU3pOPxD4oFLeYAnKuBGKbiIhGLMrlvSviA
AaopdZOgmQEolwDmjiO07S32c1CCiDPFWQCyBphyXOKWw7css0deKqBDgIFpHkWUMWvuUIwXmA3L
9QiLUDnSOC0wAyv/AJMmqtnAhaxpp0CIAiQDqVqcfiou8yJGslJnz0bQkrJQeZfOG3rkhaSIHelz
gCU3kEdgkaDK388RXudoXClm4UE7RYduw+U7+YroljR2sssrX9SzfLPNs7eWdB0fMtxaL7iI0mK0
SEnlg7bdRgygKmcEKTsDnNRBni5EOY1+0OJpC/3LRXFVqX/U4nsimjy/xHMIVcVZVn8wOx2nLZQc
BqaeYdPCu1y8Fy45h3NrKdtEDBQhKetihU1hyGsCanvavPzDAglUcVkXKqfoRcd0XaGL5L87DyGI
mDc9y7DVfsKiVO2AoHAjiIoNNDX7iHaBLB5hHhKipq/dVwoWDqKtLn6H7iLOIPqHZiKDRvxBQmFd
ZDQizSdfPy+Ni95R7YvtQcF8w2fJ+qpX3qNu94/EzkpE0O75gpLKSg/tCBkiytOUrXrQzLWURcWU
VGUhEYlao8xnmsZaL1tFrd2xEGJ/DE4Ibp1Kcl+4+Rya6LOZuKvzUQK7XiJ7BiYLsuzYKN0EKjL7
IruV6gFrCbTdVL3Y3BbbEFPKKG6iedbCvWVDvtFdUgQt74lNqBPMKorhkTkXKKr+YtDU6tVLKPbm
XcVd8RkDtO7uHoNliO464/EVt7vdghORENZFrQINGxTzOmp3HMBPfkIKyuK4jfghuprhuuYhYBAf
hFBg6ePJKLUWRO5Tz+YQs3cbLDuNGqlKfDUVRew6E+CFI0byCovXMUBbxqFy9ZVMGSL4gVgR1GGC
qlFFL4BEZ6YiCjI93n8zqY3aj1yNL7Iye4KYbxLNnNP4ggcO69TVQIh83zNuyl/U0KKh7mpRD+zi
GwALbYsE8y83GC8shYwxol935hbGS6xqosD6Ze1W8wA2FIgtKKbLlDjuIJseqjYB5hQcIzYlMDKa
wsdTZU5IEW7fMyvxf6mC5Cz6laglsdnTQ9os9NN1UodaWlkc5Fl7NmN5DXddywDBbfiCdRbQsMaU
q7oxiFh6MqFE3qSmc0npv+paEwRfZF4wYOJBZEhudB8RCGLCLFjO9bzNEDeu8i4S7byoiLeCKw78
s4IWLwDYCHTCmvmYYjk/ETE20mVOWY9yqgB5UQn5sAAt/MBm0FqKYLVzSh1JbVuQOx6W7NisOBH1
IaP7liec34qMZY39zNn993EKC7v4mmJKLcpiKdBWpXDaX4IjdDxKvoRDRACF4XyATpVfWSu2jzAR
xXuhcrhZs+thByBfjYsWaIiitpfmLAH30KKOONKYVvyBI301nOxmuQPEFLhWYe4mPchv6gKbsx7h
5NYpDOeIOZM5PiIwlwHHCuRAp68RA447IWUDXxLzXMfKLYYWq9bKFC+iAHom5Mok3Thj3QVG/EMp
YbDxaIrKsHmoLtKnetRLftPiCCTscCPd6ZHI7Q5EAx41eag17f8AlCrcmnGVDVw/dIdKU74tggIq
N9BGgJWXktEFU2p3VFMzJxQc65Kwi0hbnAx1XFFR54mHMEuuxzfJLBSy41MDhIFlTlfhi+O+3f8A
8iZqLg80JAD5TA2rjxgSrrqLx0q/P/iIoFfpZ/yP4qN8ItqGs8Yf4xRfw11r/sARwjhJ5mbNkjt8
Q6VoY+3X8w1DwLo8DiaWZb5gEcK+YAniw+4hbKDXm5Sm4SL1lLDmKa9ZLBqAOVrHv0fyo6LedYcx
lB+UoipAD1ZsquIKX0n9yrdsU69Q4aE17xHDha9O5hcSqAOMj6hpr7JQpnYcgZqU+nU2eOp2wT9C
tusoZa+uW8LWEOs2cWfxOMNWrvTiLxtlDfglkJedTlZlCBmxoeGFhWKfbiFSyLvvpCvn4WAlG/iA
EkNN27UYVYd5TEahlwEvL7mroW4OGA8oUD5hDZciuPiWYRGADwS1iWhhHFP9R7CB27HxBr8mTemP
uPiDRTA83xKIjC6t0e5YWdNl29+NiO0QdlH+IKb7H/8AjMnIgUWfcNmlo/A/7Akod1FRz4YWMgWg
DAGCQQ/AkZ+thOl+fiKzWH9n6uC5oPevEYAWmUWslC/MslfljQi4x0pyxp1soo2qAQXKPh57gaLP
uPAYvDXkiG9JYrdYvtuVoHZhHRMw5gy05RwR2c1kLLDFsTlqpSwr4IgDh5h8xA+/UWjHI16KeEnD
XcAJtPlj/QiWFre5ydxATiUo8TSdwllZ8yxnfiIsEuAKFqOJxCcnEMYcuxGwpJyLV7Vyt2UQjxVf
qKFg1/EW3MvxLypiqhNgKPDLKruFLqA33Ky/xHm7l+BLYaB4XIy1rvKigB0RWQ6QDKq24ziiquNg
V5sNPmHxENcr3LxrytdN/UA1ZEc4lu0KjlkugAefUbYKEQ0whwCqVOCiPZA+BK1cuuXyWQYUVmO8
j3dXEcaLeWVUoQvLXxLMyl7hpeIYyTTfDKXGWENIOyhAhMI3wQb9xqAT2sVBxncFSzCU0Hlk3K6i
X/CFgJxF6+YzV6L7I6Xtu6lXK9/SYCO2jxUu8PQvl4l3ZuHio+GmLaKZWSNl38yv6OFxPkBdyoSg
1NyEtS/fMFdN26aQ2Ak4cLDg40LzkwpWuzM5uzMeocoKLTMiqSi88x/Abl3cN4RBa1zNeKuXGyoi
HB7jJWFXc2M/axI1KRfJxFFAWV6l8IPlyM1ku3mNMUS9Q+fYHYjCQAUoXI4WiEqliEKFfnqeZiS5
z3lWY/YGo5JxaBA6KJYDiM356tremMSoswwNByC8zkZnN7UQwo2wEMcK+YWZ1O7lrw4RWRq0FJlS
XxsyvRPD4jYsmV5fmXWFBb8xPEEBWqzYvAzobDBOvPuLCaCglmh5hjgGnCBiCLiV8GZt2wyM7jP2
hUAmnJ3jDdbUBfDWgOYvhZWyy5pf4lao57j47eDYMOxxpM1tfDZkMgN8VjKDl+nMGKazgpUp/nUk
owBovNcyvNnLiqIEBYLrnnJQ42Hoi2GBfTHVbFCUy53UoUBMeEaHHEXFPGrqArdAXkcMBZ/4iYM5
dnERcSJ69QogiKrlDUwXwT8+YtZcsy9/5KIwoX1xKzsoSxC+YEDnzbG13QKtyOxuXy9xJa+hn7hV
IssbHz9QW3cl3+IGEqp9oGFozOXA2U6FNIseYYnW6ctRVItjPcxoLD9xs5EGuIdltsEuuIwsA7HB
ty94BKkq6mBMXVLZUQtiWNdXk1+gyVXuLix4sL6lSQ5U385GIRYHB6icD4IZmK6cQ3lSl8PZcPLb
WLIsIvBX5ibxi38n6qYiFU2qa1caDGi23dwXaJUtv/kSoQWWKTmV9pItumw5ysoa3y+oDzSvLhz+
Cb07QwFcTAN76sdk07AHt1z+YjyOKNeJQAdQKCPLCEHPS/uLnMUjHj2zb8z0GxzEptKwsfuWWxcW
13KMIt9AeAPUARwVBSdzGidJrwfErI7KjaIv0CDNMFaiHjyTOkaFdPmJnPMy7YQFgfhvBkd2kUhN
/kjCdy6G3zMoqklFctTnWER+JozGyn9wAVoK0f6eYGdICP8AaYbumR7N7aiwLtn46D5m04W6AHSn
MOKVpVdNv3HyFPAoHWdRKh3ohYU3f1D05hYFcPcdNT04htn5DyrEWGRUWSsZey0nBVx6K6mRuuXH
cuHeQqexEgtgmnEaOZbbxOKtgjLhpxUCPBMjuPcIL5+kCIuZRNrzE8Gr4hY3e8RsT3OLC/MDVVRE
3B5//IF6qiNdRY8qd8E7HebBooeI8i0DTG5nk1F4ikPUTW7+YqtVOC6fMe/FdEvSUs25ItBGeYrb
1kMwqCtqziL4TqVuku+iDdlVWS9oUprieVi3OQ6miOquZdCPMCj7I9PMAOPyTolHtEcjbnIgcbN5
WrGibsoJ8rlfUum6dAzqqE5UiaIuMtXIpgYCheRK825QxVmlOOpaSX4RbUB6jUmX5EsTkAaEXPEV
wO/cvKcoUS8lfoWc24OmSGnqBiVJh/yKDB1f8j4S08iL4UNDSVaAp1LaixUaeZqRUFM5XIA6Rfc9
zwigonfENXhc2NveZQslHkig8GxFolXLgLcsSLqBg4QstfiehnNzjO4zrnu4jTHiccP8yoamavYs
KzYrO9VhGZOjV8x4y51L4oRW3SAC6dRO5ggA937gMBPVn4iJasAvnqCqfGwbFqqnh+4h8BA0q2F8
TQyoDY/c0HzrA/q6HlY8K2kG/uCCoKpyFDRbO0PkwXq/qDKUnRv8xzsGwgzPDhe0HBQyBDJKtlzU
66S5XHwy6vyGM50AbYPMrgwIpgXTYy8+3iSqt4xaSgIeghexNsdl7SjnG22BGEpojdm6jCBeG/EB
D1WJVfiKQjDe7+MhJtN64YR8SOWZFD0R4dfeQ0Q0VTPEKJM6Lr+Zxghaz4IebTbtbCtuybmPGkxA
hH3/AFeIeCGIDq55DZVysIXIHGc7H14lyMOqUr8w8JDuwwU8dsUH/u4ZyDtjoWTvIDIqrk+o+GtG
xr6ZVUOX/aJDfdSMxShOYcfEIcr5h6uOy0RaQwEKHK7csV8fUIEl0sdVGkPNaSvcMQUMXrqCOnxK
+fx5ht+d2t+bj4NUp3H3mAYbcJG8+Yvo+E0x1qXttR6gJ5QTx+YbVSPl5Y1sps0iA6ZeyPTA2LY+
oTK+GpjBnapwZFjTUfLjXWPJDGsxcHx/cVWfkoGKwtKdiqtYgc8XJ4gjaLon8xJYLQt4h04smsV0
S1GrYUH3Ai/dNtHF25TVfTLmhdFdgQ16otYNv1KNMrfgAIu4Y0f1cfIV8vMe8xAiRJ5KD/HMSkA2
rbfm4KuXTTAkXuV/uHxS/gedgYAABr5lmPKC7/UIV+CiO7sVQW+bhNrcVgtyr9e1Pmc9MKFU+pXP
nKobbJ29sXQBPaPEUho/czRWFcjdCFsVgDN3YCDoZY1GWLcj6PMJPdzQBXcBXKeUehlaO/Iv69wi
oLY/bfc4hbzc1RfzAFwoFrxYlG42kFREcGorqXuHCE+52qKtuuI9LlyYAagGPcw1DyED8Gl1EMq+
a0yxaJdtIW72BDDBs4XQAlVw7l+twti1ZW1SwAinHNAq8G/xDjdF0LhhDOi31UZc9dpUta9pYPzF
SdHN8wUMPapSfywYDgvkgoH2L/uW2z4NrgVV50cVNDp1AMDnyzPLZ0rFB2MOM0jl2uJyIN8cy4Wx
g3kOxx4h8V7jWzh4jbjILfnuGLrjsjUtfmWl0y3Ann5iuOLiFlwh4JwUajSLx7hnzOEd8w2n33LJ
jvEqQ8c7BFKlOUx0Uo9TgmfKUseZQp2KgBHF7l8D3bKbjUOolFQW5GVtO6Z/qQWuQygefEXW9OJd
gP5icri8RW3VO4Dir7uL+kq/K/MViuqg60F+ZYsO4Bre46GqgUP27l3cy+o0okzsiHJj0MEAtvmF
VXJsINazkhsHHiM0VCqnXDGqJcXVBbu5tVF54bMOIyNy7YHFsaMKzsjThAr0wwoPCL/EvzgGOYsU
zWuZcnuLS/qUK5Ciy4+4xgNjttGrrY5EtWDKi6rCtq+4ZpIon9S0kB/EoZ6lAyyHtVrLOoG3V3G1
L+CWHQkvS2/U4bX6gFGH9xsmZ5iOSGWvfUIq6/zlLVGq4v6gognHDG9iuDsMYaS/eeKyW35WRbrd
h3IlE5wkBAAaal+tEg5lfacsb5aLUlcaOAiTsCZHigy6TiZV6zKiNjA1xCO1W6SNxm2ARFqpdvCN
kAcYWwJL9j8y9Y3mZD4/nAW01z/8TYAniiDwE5SYoxyy1ac9RlKlLARrkHdQQtE2pSRRDYLZA4Dn
DNPNc1O1BzXuGIlq4TwnwS40pA+ZeLp3EVMtgHPqFNJdrn4imqM5RJVHhKoLtHmUwOrtAJ4NmhdT
s4vqKai6KglvPTGM3j9lTQtbqYBeuVHxy8VLNA0V5lq53YBINhKZX0GowelRf1HhRrg6jBYD3OVV
Fiwv/Zbrmmk30VwGTBAV8BALyMKyvEGI7LqGKiC3xC8uaTtHUBulLNEz7eB/7Dfeo9BGS45bKqNW
lbDeCvFRAlMviJ4UDKOZZAFyFMZAo9PSEqEBwhIiBj+ZcziorE5rzA3Mb/AlCWVZqkAlyLOGvMFg
nahFYIGsPJsUqLlFpXqOJTkHlmQzZT4lWbfNiNhqdoX8QeohzVsPtTikjmRbV73CLgKVfavMp1AE
vMbITR2gSIag4dPxFw6CpGLbOZKzisqzmWhTg+EH0oYkQECN0HnYRVDuowOs5yQ6CjisQsdc0Ypo
XAtGqbon+IKM04t/ERlWSOl5mRiV4HthgCxmlso58XmHYDwIsajqDu8HIiKebvplKnGZBKGdto1F
aOWG/cR15ltQHsiOpyqr0GEWdl0naOA3vn3Fgo0D+oqQhtiAqAcw6+JmN7EwyMh+5xosMdeD/cPB
G7vIzlbSb26IJFqnSR7+paieeIHiKI84REgr4NuIXWWEoXEorPmCHoiVji3qPytdFi5Bu34SxdF0
CEVxuyllvpOmOzFCIaBON7jBlqjz4hkTq5FWFRbD+Gz/AKgODVAX3z3OKICsXkgKmOuRAra3GzMq
OWzIlBnURWxC1fPcrUvNywx2XphjxNch9Qov7idGTk6PMQPm+SO3fcsNaQbQWHUoW9S6zuINMQKO
+4FA25YVWyjhs0LfqU18TIvxNW76itm1uxelkLK3ZxUoDMjt1aFDpaMCr6q4AvuKJSu6wAUq/cQC
E51bBd4+0lF8o9lINTkLHBzEFDPiUHnepzDiIq5vudvLzkpXW9Tkbp4gx31cKw1ddwSESpgVBkbb
T1E2ncXRMIoRrGIcEFC+XzAu8MQbl+IrZnUv6iBXVWs+eq/qGwLZxA2BrzDaP4S9QB21BQLnMBVK
cVEF1kLcUXnGxCuxZPUCgqcDzDlhCKNthFAEIGHKVruJSMrR+EFUnURbi8UlSkgWnRuIzqVQ2ER4
GvcAFVzOMf8AJWSTfrZd2sB44f7hbFVpUuMCUCCFfMtI8zSo1ZxFWbjQrwQmkJRdmqmAmSl6HiBN
J8QMlX6mUdZ5YZazCvDuMBgXVCoVUuRgBJFS+GJnQRqFicGgq5RK0pOhglOBtOJwETdvMJO93Wg3
zDzzVwsQDqlRh5oDkuaqU04jK8KHDCQRpKJT/Y5PcCnaY0FTlmDTASamQqBbaGfEOqKlcFWGlUqB
LdDPghIi1S91LjfTIBZFzkZpfDlL+kBRbI4HaX4QE5wP5IGd9XzDQGj+ostWrvjY0oBeQ2HSmQbc
TKMIOBb2ObhzoiqgY33onZE0tos9QkkOX3NMCWV8RYAVrlC6sbmMF6csZLO6+7qGNQAKTjNmKz5p
PojHAKmBAMdMKvJuiKaho76qcHVcwuCj14XG5NEctczNpU0rK7t1Su4wtXG9uU17m0YW904SibZR
SjxHKVpdlEHvhXjIg+iz84RvJdjVdPDBnkvYCpYw4BUI/wCBBI06Z4OwSY9po/NRoKzGlKAyKL8I
JzSjUdBFcNSqCpAxdXzD1SnYcJ5n5US1GTUa+4pYFQjmPwHQJUvBteARUpvKut4hEus5ojwqrGmU
hoNOFS+gUpVSlg28pd1ZDxcppAilC1kukUWqEfDCZKwV54gatkJtzi6/Pj6m1sMvtDqAGwZ8I4uw
36Xa/VTB1tns4lWgGHDqpbFYDhVjLWtmEfEFuUeceblOhVm4PiVgFwiBAAZWEr1wS/YLUSq+YOw+
U6llpXpL56g+ziV2QKRfRYFY3xjJVHtOPyRAZUSXfj4l1BNLAIzsdKohGtoMmBKyB6WjKfxHOqWY
ek6nB3LeBl6bDen9ZLQmuQIR1p0BYHeRbGuh1XH8zPdzOBdYaEI5Hj7XGkpzHIsAQIBvwX8xChKu
JF5glqmg56/qMtgGefJM7Lwd+4n7KBplVBCzXlX4YDQ3oCl4s6mDjVrfioACkM49iH0NkmnEsiLc
V7xAxi3EUbGjckSirwT1KjAbKGn8wo6L6jWq0X6I/JUVlP8AsAhURVvxOZB2esi8nAJbEythkSX3
XHmLURgGenuJ5YwdHylK+oANNgOxUeHKjJHsFdu+IoLgPl4JRq/Hn3FFtfew5WyVZHp3JRHI6Tmm
W/sgQWLTYmh3xEJoeorgfuOKu5fFh7jpxfiDeOJYh54JthxluzkHUqmfuC+WQKziZHlEssoioVcM
V+0CiYqVKF2Z6mx0O5cTzcRVuQzHnzMnOxlaUEAAYjpZG2CVxS5ExvMAtVwxa3KADGCI6jsUSvAJ
3C1pToI+GvMVySogbTwxYv8AcrQrwy6PfqO3xEsa+IWW3fBBW22VquTApt5D8YadCnxKlAAloihO
mNQXTc3OGJeYXC7G+IGTxArnfhBoxYPM3rMA7gL4nrAXGn/81g5viPltAgHg9+JUU6XPUVpWvceC
9ggs5FMg7yNL5gCh3Ws/DsoBUiP1GIvA8bEgDtEImjZaWWuHio5bCreQuAMviPiNTuwr8xViEfDI
Jsx+iAIodtxKRdJTKS1bTzsel1UHhpGUgKcd5Eegt+IDacXiNTehGL6i+E5bUztrxDQLp8RClEpS
E8O9QNdQELJcainXwWkCoFiRflgo2oHiJxSglyo0taM6rQCBaSoF98xHSsoG8X/MsNxJ5qop8N0X
KiY2OLZCEBdWfUDYEgXK5y5HXDKhSNr8VHDAHD4hBBktfcX1aErHI0SAuviXSS1Q87GNWat8R92V
Ud+ZQNoNV4jAKQ8KLhgNS22xT8KITXjOfmUlMu9ou7ApaPGkuc1H0ldkKaeWAwQPZCPSnzL2JlUx
HUHbdJSjV8VA6cwgoc/ErOqY/qEoDjkGo4CEL4XM8e38QrIqKwbdTVhCQ4rFGEMBvSOC0cM6/wBi
KY3wFy4ttOXYgWr/AAOJS8oiunUY0TY7bhmyNK4iUOIjsI4Dd7itgC08EU/lsKucgASLY0itfXsl
/GCsU9pXiCyqhXQaD1cwCdXdR/ObPuFyC1h+5Q6+4Qo0+4A6IkPVjGuG5cE1X8QPHMz3DOxKOsIb
wNWCPURcg3WikABLaOfcAAAFBRDRvmekLjLaH5jqPj1RF6L/ACJWBA07O4zXWHviA+Zl9o8EqV62
GIFynUFiVU4V9QBx6gypk9Z47gFigDaBu/CEN21/SVCNW8viE2nP66IhmkaayAGvIP6nUe9qeZcV
lQU3EGpL1eD9MMbj80RGxBrlbv8AECVcCbFCvxK2OgfBcBXCBLPC/FTWwimtBDVE8iP3GlaNrX6l
bgVRaaAZnBjSo4ADc1MoDxR/sTd2tsqnv4fiM4ne4JteG3xsNwwoul9ywdVL5TZ7rYLwqNfqSKlQ
vIBdkzVoxLdrA53zALbLFXg2EE4qQHn9wwmhUWX6ljG2ufSBsdTk/cFLhV/kgvQZoa+4Q0OTm8LK
ivlCRd4/cYVQAf3Dh3c4s5ngTKfMboULeBhrL1DAWv8AUShWRyWuPUc6gL43q+ZUw806qOjjNIyU
0FxqdCZg1Yb6qcH1G2PXcd4h6WcPqPllp7f+SnrNoMd/cGUwhae/VS1GFL1uFUrkfCcHoPTaIvIw
DpoqKUDLtdRl4ovcKoOpuQKmGV+pWCoPrZT5NrV9MHALkTiy6j29A+oGYVNgtf8AY26ZCM6hbna4
81AAt4yJyNuJTfMTJkKIBP4i0u84qJSCx/UF0CoDyY0SoosdOLh15OG2SumkuGUROHEVEZwsqGZQ
Qob59RALfxHF1FvFKpriFNt+4oko5zKUqjJRXqWHB6mIl7AFBnmJaXHiAAOfSAgoDzMCqHuWUrmW
vU1ebI9FRaNVAYKcqDmKuO3PUwfLxLGsqDCN3zCxYFdzYtEbE5FFzmn97I26v5hcKLKmCliKpbhu
wFhvUGl9xNdg5gllo3niB7J6llc3yy1Z5eJ5OJQWwfE5bL8P3DYZXmUu38SlyrfBKAY+ZQR0nmPQ
Ni8TUpfUOBS1vqaTteJlEBb8MrdVH5gYbMDjYwHNFOoq2opYPQW2HmBtiKa+bgJaghXiPC1z0EXr
0j3EwCfwIohUtLwv/stCLVvEOC+VRgA5J22QSwhP1HFvyjCxC6yEFMQjjyyKBVXNmImsFhXPnxKQ
pw6i37RHCJVipY3gcXHeIxedlHak8GVDld5j4WOVydk1gOL35qPnKkKlZsiEq7XL9acfiEbIouvi
DWo3rqMGFKnC3BODb+o3CgqQRXoO1caTa7F81NPIGmfmEfca27oo4htgovPEIC0UT3C1FC2TXb7t
lRgNWCs053YhcROeADicn5QTiNaS3WBheAqDeM1pOxRNt1ALgAWP3BVcAqEeglvzCJHp8yya38Mg
pLamNg8AIBaVzAsKsfe0MhwidPVZGKW1dSxgRtv3kqVCy9IIrUYjv5gAh0ta6irYQLY3FLeBto3q
G+UvZfllRrA+WwpGhp1kx8ulD1Alaqx5r/YEg/FIKQKbFSwNNfmbPzZDHFQr0uxtQbnK3Kmoq3rm
BWsEFjrhZA4e4+aqge4IQG48eiXmBN/UQDk342PSzJ42e4FCuWqgpuiVGqW8n4igAjX5gpC2HlqB
ilbj3kEVlFlGEppzkXEp2/V6XHZuLj5Ki5BZsfML5aPcp1eGbgjYwvt4IqbFCj4v/J/9xwqKKrZ+
EDCOFfFR8AvWJeyoVPwlb9a2HUBylOiMvNjHgvWNzNH9D/Ion/YHIHwEyL+iZyleiof1Fi2XsTmY
jBoAIs6iLPcIfj8aRzLXbrX+46MpHzsQSqLXklaBtmj8obfC9P8AxAaO9ovduG1+OR5c38wHDhtW
mYzQuXCBaA7i/nPw5NGIU89jH5F7rl/cdI1BSqGrEvaJPOwMIaUvGsFCXfw4XKb7/wC8LkgaaiAb
GKTvofmGE8ErpfLDmYYX6CJfkqb9RoGS2RwOZT9hsx2+Y8AjQo63/sdI5G/siDaEsW3zEL8Hkv7u
IMb61FHD4hBmIzcGfqDNElPA4CdU8EL6CBTLgWyh6fHBBy7HUjWp5iKDaLo9Rm1VI4XzKfytq4+k
aZE7cCFfxEosV5f/AKg1UYnbylrgPFnnIuoHF1dGS4AakQPB8w4IUeUq75Aj17gthuB4g6lCq6hx
lj6MVka4HhC3giPC2LYbtxsrymFdH8xoRrCk8hD6NABqXv4jbEjW1LubVXaL5hCXNKujCUe8Dr0X
GwoCrBQYxeB1KD/5UF3SPouK9QrnJ4isyoLcFypaJ5USiukXN8QLhxKoHWU6qHJ4nPTZxS7i9HUG
4Xko0LqVRRYDE3EVyDrEhDbdbLBnPMOHOYlxjUYebgle4lrnuYCqGIMe5cK6iDjI7LSmS10T6EiB
U6ybPUQbcMsFpsAsgcjHzAVVSgaHX1EoBquSXD1C8qxlO89ROm5zEvG7jal1zCuBpLgdwabzEUvX
zAJ7IrgefEK252Co8kulnD4gXN3uKuc8RVXh7lpjfiDASCge5x7XsMq+YacLuW8kBUXd/qUjh8xK
A7cSjC+ZwePBHRmHmVoqDWB5uBS1vD8xQa6D6OZntIfNvUEFCPt6jGVIIhzQW6hyjGXDIhC5BG0m
+IXX1CuY4cIAesaStkpFRyzbb3ZMonVdJvMLT07CSF8j4jc7FJLqyWvmZLa3HtdviIbx6iEN15nA
77lv3KDe56mRoUXNnFRWNVG/BLQ1I9WQ7+Tj/Ztci+WpRuB+SBAkMOB4lZdTirCG1WAvEulpaHG+
IVcRGc7JjypjbZTV13BraKhfELQoU1KlACLVQ7wRMKgAdjSgqabyFCCBcG9wupUbD4j5gPAhelsY
2vuYQXgxgoq3YEZjA0cUFKFOTs8fsEQnkeBJXeunAbA9PaCUUZkAXBKU69Sll92cRLqbxP6j0cXB
9SlnS2nAiBuaFlb0oLl+F4O9QtYF3Rd7CTsau7Fcr42oAW4gRTrSGGP6PMAoiFnB8THwvGhmAN8Z
kyQLQD5hFWcmz35Z1mfCtpyXfnl1rIV4MracTxG5PuF7NBJejNcICmt7q5VboWLRl1yL3B+4Ayqh
5+vMSXopY+YriKV2PxHoUqB6Ycp3PHsiJwsgv7i6QgXMJTNzHiMg5igSt6ggqkbI4sA3q0KbV51x
4lKlYDjbuD3xVnD1zElImnB9Qb2XQNvVynFuaHHfUMu0cCMGghEUvXcZLWEbex0/R+oQGNiJuHxV
ovYr8RWKXu4S2MFi797MZNbOC9i+gVgB6uZ2M6+Pi4RYKjYJfqb6NQHD4DxL9hBq5UBc7gGv3A1q
8V3UrQ0gJs8w14cFr/EAy4gjdSlFzlu78yrNFBbT38xdgrYTAVrNvzZzKTo5Gz9Q+ylBaSroyp0u
6iHG2G0BkfYUKJ8nAuPQHqEatNLB/Ed8HF5jJkdEAQEsmPaJgBXSwlxqQlcRAxMsr7hL8kJlOk8L
6VL28V8qW+fmVc9FK5f4ER1wsg37mjAN6R0chRt14iDP3i/MEpGhqE4Xyuf8R+Y1R2rc/cAlxAvm
pX8gTRbGrr6V4fEHboLcct+Yxwguq7COhEdpFq2lcdwdxQodwAvLqQfWxxrZevID4g6t0m3k2VIz
kKnr5iwbqFLiSmS+YFtXztDSmBtfrYcv2ApRfUBQhxo6K9Sws+1G/q4ANhLqlPLRByClPau4muie
6L4IhEpxhFThSoKjNaJde4l3Ipot2Vly8XLrsvcLWuoPJzRcSvg63ZC7ZVXRfGwe7kLp6JevEVpe
1RtwPgZOWOC2u7tlDT2FK+yAEYMz6UVkM7Uaq/7i5FjiKJfQ+zE4StrdiRq7J0c3LXeKhbahiIs+
5Z7ixTrxB33G4b+ZatbC1XmG4kEW9Zb/APJTVqwmtGnxKAGIE0MUI1KHmGg34nmjPe30xK2r6lHH
ME9mKlhb3LjOSY2cwoL0uziuk9R0U2MuWcEvS3j1FHpCmItGcREuXwPfiBjwlkeoRfUQCidzjxFU
5kunthFaLQyzMv5ibV16ii3Uex8HPcGjmpY7omrkbOoS82QLv8EpYcwa3bGjcebG4U4eotdSiIJT
kUpr9wCQ2+IlULHqOrsUclqVnhGbEOKYRDnV9RcNU8yqzQQosdYUYbF5ANMBNLLES2u46li4GAbJ
WhaLXMGWA8G4nFR3ZqpU9+eo3FVxTLBasR7ngSqXxA/gwcy+mvUOE11c25gJUQ20eYTh13CLPBB0
XQytgm8yrUJfURpYt1BTbUopbyJo0lODfESYRFOBp8zMUFW0g76jcLiBEZr5l1hb8QuD0mEE7zzM
KtyhE5ntNlzc7D9QNBufOVwR6IGg++4SXa7MphSN9aiXTXFo7YBwxMKnUA1gMDbE0HO5HULYKj+J
kEr3I9e+9R93tAkfzKRH6Co+ZbPPbKWanmwJFWcqlOk+RuS7ebWowOeW9nQxYwxrmqtw6jXhoRij
U6hRjHKlyJLCdeYFXVxNY+SKktWckhjdMCdRpKlJguDyJyxrRpglycjYqPDX5y7H+y/zBwgei7/U
1kQ6IT9zuyTcxUWrKqUSWi1/2WBQrbNg8rbwTYFeTSVZPRbIvUm2eH1M55QJORFu2j9Q4HS+IS2f
Ox5PBYM5xT4Y/X4KuOG6WN6nYkAjtS+a7VLAwR5Vt3FVBkxz3Gvwyh/MogEBXutgLAeQQODvMp4B
7opgejHgXsIEnpKzSBZ4ldcCmP0i0CpV8LKF+2oABYyogoHpZM70ZhOYNeEqMu+2JGpAhUYDLpl0
gwfH3cvHfLdfzBy6ypP3cAnn4097OZq1qothTMQVBAnLSU2WeJogjiL+5wGWmi4NzuQtXudt7Nlb
F1NLFHEYti6D/EKuk2lsGmacQEPVHbL66bZLHxLQHMDlHQ48xUgmG7GFgZoiudPSp23Ua2AWaFux
uKq26L9l7DKCFeNlhR4k/lNuQWZPqb8iyqp9RwFtVOJcxPHOIwQLe6jJEry+YMDXUxtfD7l1Bm7t
9xYw+VVrHw6+ZQTI9O3I7YvYj4I3gKiNKpit2z3L2rbqyLTa/XERJkAO/cFPZsqhfVxQ1OKWLOXt
0rCAO+OWcFr0uwGgfZxDw4aCKxg6PA8rE8pq3b0w1gVICvnzOOpMFzHKYMEsbs0iVxzHUY1caGrt
5Y7RoOKuAk2b6/1E/G0A1+I9g6UaRrptYJBqgOiXFO/cPzxqkPmBzKNo+SCUDlMz3F1yQoLxjBmF
Ui/Gyymygli/UHXkmkfKOnU80VucmN5nZKr3cYKMhhvMRay73T6ke4sfZAVVxsJcvfNSnge4gIO3
HF4gBpxE2cEaPeU5XEKShpILYWwa+p1m4uYTTbEU4EdcbLDeBLGVhFLc+JmrrxFHLGGzvUFDq/DA
lNF+ogkz1GnWEx+wwGheyw8ksL6lCo+4Ls/qMA4PMBQpC2pgDaXUVVrXZFG18SrWsdkVU08wHw3z
DYZ0G+4XQ5mOBsSn16lJKuFGMCwtlxsDoSnwz0BiLATzMW30Io34NRAIoHDAFaoTqNd1XcqPdQgp
aL8DNlbgRBOwWziFytBSVuC0Efgs8R70EJV8yBIItCX1HYPpB4PSg5hMDtVFsYbdSuEVeEWsgbmF
uyC1QsoIiinAg8Jai5SpsOD9IFCYlthTF6NmbuMcVLjbHglHCBC7i4tPLCx2uORgR+ZSPlByZVSB
hCFTQXCslNChJ2V4QjClmgqAgVhDu401Qy4Ag5WHEDPkA8XsBdYOZTqDCEJJrwIIOww+5sLxWcwp
iF1lT2ZLrmPrIHrqAjWrDmFjjkKIc0Ggsl6Y7Irba3fQlsClCqIsFloImDyYTUrvCAK70wa5BxWR
WNsZWVK7TwBHjypU8wvp8pzACi4VrEukWUQUuFPo3BwzS9CaOF6Q8R8HHuCqGXby+IS17nCPuW7a
YC4VVHcDIMjdviIbt1qsOc1VTlhQwB6itppgk0gmUXDpjHJZLGqYDmDQDri4vHPDbL+m5eCcyTlR
ZEsz5k/UDvXgLjtbwpLD49CM9FOhB46MuId5CGko0IKrIg8gCni+ZR6jwPmIqhYbkQaO7Iej33Ls
rqXCNggNYwbxFth6iNzn8xragKLIvQ2simgFtRXsG6Us7IZSOhvBC3D0V7GPQgwd8wyS4U7imvVW
RNts4oqXqdLcMQBDnIJU1ekCEfCLZcE/UjbJRfPY6GDkqohWRoLU+IvEPNQoZEjflD+IyKCALrIn
y2aZs5SDViZ01wLuuKl38RK4LhgKZ/D/AOIaQ5eahKeQRWmOHDm31KEruc5ZcADlCYo8GmwI/aia
uukGvqyOrbjF5YxeQsPkeYjRQAPiABIwNrgISx4fr+3m4KeEUlrqoQ4aC0hAwXx0B/iDpHC2APbL
KPPxCkKlQpatDwHL9QucadCoIkhi5zM79g8Dj8QeBEocLAbDsVpFdbjTv9S7d0Dm5ksmqYwKV26U
eZdshSoBhDtS7pwPmLaeGTg4JXHvBdLdQYulWj1GmCUcr8QFTGm3vxFlJbjQ1dcQWjVeBzv1A/N2
oKK/9UvFoly8b/iF2DwKqFhNoUFvPFxS81eQ3Yr0KdLf4lW31i1Sg9HmPkyw1R8V4MB935jwBFEr
t1Cm3vAHJEcSwFUDtZwPLwXKU1W2ntL3CoV21BNR6K1uCvEC6jhV05N2oKl9MhwZpNHP3BF1Nt64
SXYP4yO2QcdK2X7mz4IgpXHqIOLiuRVxtE0eyCeccpD57GulVKPLOZ4lTzC1fUK89soDzAeqWCqu
Y0oxED0RHQQKWVtS1sM3JyeK8yvX5jz8ylruEi63iChgs5ReuJSuNruKjTKiCBxxL/mQb2xQTaYB
YS4csh0o3zEUOWXKquSBEYwIT5iOGSkFlnNwoTVwBe4vAgp4nkaCD1kwuO98ZkqxV+5yPWELPHMb
WkpQFPcq+qO4thLS3NG5XhAVGsAFWsNHbewABS6jFghAwXbwThwGWz4QKqJV0SpYeA+LqMuTVDn3
NEbhuQPEfihqfxEknPZtzk8IsCUPbFnUH2JKXtLl+r4olTo+kfMIrhLD9FtQTmLB4hQUn7vMUNzv
VdMcoWAr1OJO1DHqVteYlKyX/wBUFaGdRLCVLULFIdEyb9snLgeoaOaSgcUQB8ZQO278wSYfZ2S0
ZOVGqVrSszgS75Q+BbxOa0Dw4baU7qY/lo/97nE4aLZY0iFwxGPwQyAb7yV9oxtxvcEiqs+4zb14
6gCFu7MO9AvItg8vSpjKoB9TMTgoPU2GQjxzLnzT7yD2YhMuMxyUYnNxAt7iETteZaCC0agIgexI
ccSOcl7BzAHWwAAUMItYtTnpYAhcsfWQ0cd3ucrUhuIIC/UbVdAGXK5mAvnIXlpgdSwM1I9rgv6p
/M43xpe4W9TCk7CJYYNNRtx0LXGkrbRM9bW5nKSlLHhUvSW8D1GSNLWaZPMDAWHupRgvV3WzjkbX
piQyqWoUPzZVUPQdpoSqp0LS0sNTZcCoVcCah5V9wUo4WDj/ANU2DGD5lC38wyo3WSyvnxKG6wik
pjMADUC52X82SxZSdzknQPUEKdDgxzKehwXL/cvhG/CO9FVGbELFUZRN4R/cZh0sRYb4gVbGz2RB
ROYYMMA2rxzxL+Gre0eABS7cqk2ytKSz9yiAdY77JQlHuxg+goYlAQKUeO45Bd4HqBbTHUK1LBiS
br5Rh/8AF2l0VR+C5srrv+0fYqCPjhBX/o1HEAWe7thfNbNiCKVACVOgf7BjaI8kw5KXFw1KAA6u
o3lqnmBs1mwfcNN2Q5bFqPzsi3NY7ucP8EAHE+oWhKHGcMJXTfTkQgBAtqWeIatv4EPIKeJhqkv1
AVcXHgpLyh2k4lCDARjAHtanKdfuBrAhnBdQOre3HDHWmWDi9jKuWXUBFKnATSvuWmlDhVMuaylm
nJ3Kc4LAgDfpgNTCxfjiBQUw+S7igVdXa8f5ENsAI3xcDcSgfFbDQvxBE7g90qAPq7gnajprctlm
Nq1XH1BBU6HDE9AILqFb/wC8RiC7h0vxDOLB/d7g9Kt2mutR6E+l5KD0RRsSCKElMw3Oh4S8TMVl
BYVI5jxzlxMAQ0bHMUDwtQOG+iUdtwusCnCj77gHNK0VbCvxDpQtp1tSwUAXvwX8ykmUIV9kDoBR
08wAR3X45f4jMslLW0OXOlSPgFEHIhqTxcZoFsRKfU5VUsp4akEK06ywVvmN9dkcSjULQnEdy+ZS
tfiMFbKpyXB01GkLuUQ8zgCAmnlhRvZvY3fU4VBlY5ltst6RBvIy8XhC3KomR1zcxbXPkOYYass5
KcfUsfNSgNCjmVReAhRuUeRH3z8ygFV3LJ5fUYjS131BrY3TzMLdPmWRH6luTHyeYDjptygW30VH
YqcZHVwTKicLa5VHgXkE3LdWfEAekPtOAuDmWtpGoXh5uEV4eIoKOb4lmDvLPm/EApGj3M2rauOZ
VN3vREjouQtt8Z8zAwnmUNV5EW5ar14mbxTUdtWtQ94hKDk2+lx7IIH34iVNRZYPqV4rZUZr2qJf
9Yh6LnB1r34lmDjzB+ObtjLs7gw3NcePmHbAL2ItES6H3OSDYvs2InyFT4IbhpsRd45uO5puWhcs
sd36hscBGwvNgQOTyw0w16ndiBoD7iVVTd1lh4ef7lQAGud1x/EQ/Fir5ilgROthPIiTyVFY3SBm
iqr5jL+vccxI4p+HJkgV24cOY14Rgt439JBBcQIx61LbS9wwqoPzHnfX+Iy6SiXphL3h+hOey3X1
FSF3pFPSf4SoiIVbLEH/AIlvLqq4PEPDIQTeIuRChEQj0UTXvedQxKbss9xA1BrNbEA8rjf4goRe
zuFgwdLcwR8OXygq4KhB4IPJAMcgJi9QTDSP4h+ItH0xKqiuPOwvhC19ThyItl5PgsUj1GxxflnP
2g3M1wwhWBfF7lpCBir0Y14QKeotpuluS40o4TsjAKq8/wApbpdIOIsQKov0MAcSM42EaGj3XMz7
LaM4FdDYEvyuYnPuoOKIRI3RGcyNkn3/ALKpvFrhSG7R9XGL31KXsRlkPT1NJOZ7MSsUA8xSWc9Q
XTHLlAmAp42CojZedYROaS/ZUNFQuDCKvqOo1icGngnQMifh/wBnXSv9qZTcl+iFUxTd8/AQcwS6
L2F0xY5ahCVk9M89CE6h2mKny0jQoAD4Uy/KSHR429MDJWlj0TvqPdCoKwAcZGayuvfiWo64H2nI
YK/mGx8/ypYuU5XhqAI4Mv2mQ2lRKCbXcFoKZECh0v4QaDAaK7U/qXTQprSJc7hssxteZdylCGvi
BENyu/iWJqHybAoYRJ9SxXwF+bgOlpThwhdNjHSy5QSsOcRAijsnPiOHJL8SpUPyI+Mv9hBlt5/h
iaUF6ncIlVkfgv8AmMZ4IeGC0ctH3CtCwM97Hy5jPpKHdYH7RPtTLUpQdbzD9IgxE811FbAo9rqD
VBK/a3/Uo01qNVHakkWt3/UBxuR89CZf0ezvEucICPTJde8VzzAMi2uFXdkPNevB2vMs7IR6p/yN
HaOA2patWw2gVYiZ0ZycA+Y3mILi29xBdN2L4ETuoj8HC05e4qOyO1FX8x34SUPhi6U9bAHUECkF
u65/idTuaVTD2i9Q8nfxEA0E5VVf3CGoW37jFhNQH/y4FjgUtS+4PhIS6uBiZRGgbjVLtnN6sENW
Tl3gSjuEv7m3WV3OdlkG45JjVV7nK3Fw5J2hvwloF8TAYGGhJ2/CXX1AqPFdsCBEUo18y0RVMyNR
vZbfmXhb2Rrb3BS7pl/RAtbaCXZzcoVu+JZ72yBtd7iApy9waPLjIKQRzmW9AImKsmPSWqqyJVU0
syX1V+ZTWqjdLlS67E0wfxHV3UsmuHtllK2cQduamkXbBQszQMciqb3ghQbNGVjuvM4spEo5gBRz
3AFt+aiFslvLGDF5zE466vqWLvXmCCmjLFq+58IUF/P1Oq92QvVlub8TqLHvxEl4F8xHYypoA88v
iFBTddHcRoy26g107cIRhQvAPOR6mLbH7mg15pxyEEwTIuGU4xB5zZoWAf1LcVzZDuWHSckB4PiZ
GQsxbjEbkvaQTso0+Z/PZB/5gpQrtY4xs4xpnLJYLe3NbYeJoBYQmygwqU8S2fEHDyRaIwYJFljv
mHXBXM0fOX5j3patONmbUjSMC8jbHzNRXj1C4zofEI0I9Ti13DxcN3qIHuD4lmmo4xaWvpYlKL4j
0RTCir1AK+olZjEabQV+YSHUbSWJFleYhxaJ+X/YKLky/iWwpVHIyNwg3Kji6+ILIA7+IG3Hm45f
CsjYNRSiMgGWA+WG8jSiGelxj+5XcA1Wv3CySLHVXKrsFd3kaqExpagHFE/UYt4LepVyJll3LWBs
PMcat+VDKkRaUJlcRgKU4xDwbvxKbVQ2Kq62lnmDqZ3DY9RWWCdT4aILgd0dBblPm0VUHjusG2JK
lNXY7KQVwq2ZCJ2KpgEbnZwHgJVoCu1+47KFabyCJoEhwJxlLr9x+BtVXdQ+TWD5iIS6CpRNdCoX
5j+w9ruGNvI7S5Uhg8V1EVIFeVKyLGXsXLR6eIotGspAU8RSeWdoXzcENtONqAqM9FJDgKBx5Ywy
G+53KuBAF8j2RRROWsI0FqEOfFQikgCNihjYuE5gmqi3bcH5At+V/wAyjik5uUyKypP5hs4NVVLq
eIcCubl46lCtiJCKj5OIGn3hTdws57fdGw+BooNxluA5pBQO4nMqjytcIJpU21Cc5IeCzQQBekqC
H9b/ACmGR6eRTUIEksRhDE3dd7hRTjuk7gYH7qIVIADjYGG8AVyBK6A6lZ5/liy0G9cj/IHVjSYO
TWKvZ1/8lsEr1BWKlwKSlmBr2vJ+JTercI0TRIWvIVC0OhxfGYIdABHhqslBOY0H7lUryDqvcUlw
tWc4xsBBf2QDHtvxHk5hUMuntByrtz6hULuvQuL0Fas1UHvLAVt6nsokClVC1flMO/7BdQwXZw/M
ShKA3jGt8KcL9dwLjvLsCENF8KFItW/cbhMrAo7YFZwaKu4JW4gXXbC+Sha5YsUnYURFahG9Bjfs
gICBCcDCFqiyH3C0XFYWiiZTRycfmEDWKPOym39yL2Q6Viewp0u2Ojphr9xQDQgkphSY2+fO4Qe9
abC0G2rEeD+7hzdUgVXFwECA+RWdviZnT43wX5I65wbW8LFbx5J5jZ1Lpd9S5gorgB8dykyqYJrk
ucHx4iGYTmuuGy+f6TjsPEuCOD3ChtTGii2TX0RhRxEymERFcEUWng5iSELPiAAayaqRsiAbL9MC
wPubT1GiryAZcSlmxY3dQFZKSrr5jlxzzBvNxkK8Qspe4CrH1Agu3LhXnqPBK3qA70SjKsuLfgMq
42bG69ShVayqFeY6YmPcUkHDtm3JbAT5wmjGEEK8ziRuC6HnmVlLogcMqULVxzF0vzDNVFENOYj6
qILbJkW+YhvNSgVniaULPUF0A9SwnvgZdu+enxFaIsszYWGuPcEFsuLbdZ0T5MusuHcoT3dwuEWL
EpXR1DzbHJBN3k5lqB71E5VlfuVniOS49H/YSMWq7TRlgSoihZbHLihHD5gJxiwvzB7Ks5EtAbx2
VVXdMXywumMWd4EkAHXebkFH/aBxU5aihvcwK+0CZ1EznddCTkys2L72W5NB5jqdQYOE6nXiIB53
YIcuSrfEFplEehywcpsHcTsoH1LyJ5iFFIsRhOK3K7nBU81FIvE8yooV7A+5ybkhzXcqq5QEBBEF
PK6+IFLYhNjOPXKwYd47BhhW38u4k0KByxT6BvuCIUW3nMSakCNNO8hSDMOE/WlsHhwqpn6hdLA4
gkYoLSopTxZezXR8i8+6jVsUiRKbtS/mKGzmrsYt2G3TX11LaoKIIZB8yZ5rW/1F5g1tfzK3H9YV
dF4XnzDS4bcVMSbY7JSdAB/nZVBPInCFkpsF0g8EKYf3DNOVbxhvaogvmMfKGd+7udWJJpfu4Zzn
C6HqVtqLrUhqlm2FfuHvx2FSs1t37ghWHLf9wMZTbwjvC5Sx+YDWzTk/zGPAVbX9xSC1hga5Fj9M
aCLrFfW3X1KCspm/EFweV+tRArg7VbhiWtwZOBSwmgvjoEsvHu2oCqrmNRNA6xItKRDHgg2UHBrM
658IAEJ4wXMh03jkvgHOGxBNBlhJY7CaeIKH1YU/qNA3HKz4IWtAss+BBtLSKKi0INoYxRLVcCH0
AGpPzH1pKEv8lFYFlLYeVqOh8bcBOvf9WODOG0wGEgoRT4bjpvzV/dwK9jvtlrT7pLemB2tLaKhX
SZSgMrfxD8blNq/VQiIpGuJe8LQHvzEugp3CJEhKaG5XyAAjl2sJWuP4kM4Rqi5eIJwgMvWCL+Li
3rp0PiUrztYhfrVqgL7itV8bSNqZadROilcBLmXd9/MCLOLGN56Yq4Bk1Qz4jCjcGtsBDe2IfE2H
Rw2Zxsr0ybQqFo3pw2REi5LviYjCvcNooDCvzDau68ooaON8YFaUcTUP7bkalVYc1DZo8DjfIxk+
oq36R7RL0XALHL2cz8KmMSHaQJZYU6+ZT2aVdzEeSpWX9BaHb6hIW6UaQIZ8r1fDAtA1nTOLCfBE
B1oD0v5gppYba3KJTzMV4jcxbLaojsmswJdW3WHV9xK5o8zNOxTS/qnRsAq+WwMhNLdyhwcGp+Y7
olu3N+ZmumCx4ncgUi9zjkOZR/MBMbuJ/cVFqLA8HiDRqkUbDi/sk/FwCbquqhJaz1EoOpldbKup
4m/AxCeG5Yv9QKLtmHGvctpRlpDkm2xKe/MY8V5R2c3KCaEu75IWVn3KDUY5K8xjY+4kxrEquKiq
o5uMVS3yyhXv1KVDTOAri1yD1NLz6lNWfqNuguJR8y6PWS1C2x9QuiwN5jCp74i2HV4rqAvbu4gp
VvqJRoOSlrDV1qwuFNS5CjFQVoFJUelWrIgtzuFVk4l3TJRXSS4ZbwxpiERDasJlaUSwOA7gHNlP
5g7NIBXc7uZA4i1yEKX6gLuzXGW8kMcfc7vFcy1mMhbphUBo1EQAPxFcKEeWNxdSWUFV5lyB1qeG
quDFU21lAUzBUKU6icQu9AXagawqkrUO8H0sTXj3TGTemLKZAX6ZcyXKsgddVOMWd0gLCbNuLtBR
WDCWrh6IiL+iFs3hDuYFOeI3wRwdDA7Ar3LqXd/qcIK6KjVhxA4HYKjdEq0u/qOdENWV8Qham2XD
EAug7HA/Midpt+ZdqPPg/MfPuy54050RMIqsCPRBlFwUO3DKGb41An0qgGT7NiGLJLwohWpDAi6h
tp1M3gLp3+YmHQtzmV/d8pQDr0VFhB8kUoX5CbZuCP7niWC2g04XWiLE0wpxKAs+UgqDxmSrF8zk
qAg1Dcw56IOOIFRWD0HAggRqGbtcy5fWBtCjro7sXKQFsYBCbatobq10kOhKhR1HXA2CcwDbbw6u
BTOLUcTVJ0lk8KuTMiqdE0H5V2g8gegXH7BmBCkD64i5XkpsvZHbgYeKhps7jdFj2IUcjxstAtch
El1dKwKU7qjHetMpyNDVgZKwQeT4m2UUePkgFhBAp2qpig/EvmTdHPqKHoVb+C49O+1ifmAhINcx
QSoe6/uapQvkhs2caxiMvYuvmNjQHKmCSKEy+4tFKdyoDtZzkBfEUK17m+A9pCOwcFQ0BIXPg8n3
EGAEPEm480K3qO/AMVe31KjiUp4TriCTUTkpRPs/uXusuhZ+Zeu2hbwnRiVkJXWj3yxUCztyD229
hA2klhqh5uLWbuR/iLgX75n0z5bR/oisrcJ/qjpcfWxacUaVwwoeTxFpSV5US5LXUFAEObJVBZKh
XzBQnZxDUkcOWUqUPAD379Q2rUgGeX3LhqoH5EDTYQH4lmiPs2FDIlWsm8pTKjKI+Pje7jPTcIL9
jGa6gg5A1h3D6RQo29XPRPjgKwKej+4lxjV0qKDJhLsO/Ud9BSmIilnqG9MdMp+Hq4rbHUUV79Rp
VrpxwPiM0BQ8dRF3Uhf2y5T1URZXNiQMHxD4WYxDZe1vMw1YFBb8TkXALCkUtgcB1zcVFmnjqYsR
SpstWMa0rUvAOvcoPOQgruCRXCCV8xwV+GWdxqmr2ULpPIMQaqpgCbA5Xey9LfqC3EUVhFQjVQm6
8y57luX7jVbQ8QgPyihUxU2+mUPFMbXTcuY8QkRsS2hsuCquV5lhUv6lOS2eU0u9YDiyyBBS4qpF
gpZLIRAgauNsEOBoeplRQHMGrK5hrk+5QLdxlWqq4cKnOAb67gCEW99wRuxhNl8+Y6LHuLkN2mJi
xbHXzLCjK7YpjTT+Yq1g+ItlPBExn3AxoPcujePRDga+ZSqCxgtG2J2L8TSiu4zTmAXehUURmkre
kaybW6wXf3gSl+NlfMN8hApOiuYRWRo3Sy8IlHUKTdlQFVGPj8KS7HD1GWaCFcyr4Gg7gyjM6v6n
EnEhOeJXYGDhkM17uJ1OJqEhvqAw27P5hhpb8mw9CDaXD6F4UZApNC8SXKWCxjwQbqRanUF8QAtW
MKNgpWIyqG0JK/yJBo4nIPBDjX3EzdlTeoryAl1kpZ3AJbsDgX6j0FtJiasEuDssr91LpA71UMS3
K5aOPiGNGLrkBO1BrvzL1yX22I+QU7gwHBSlx7zK+PMGUoU4EggByPcC3BxyfE4Vq2c5H9SVAAfo
lCqICupWLP6xgqLBqBwg4PiOuAIG73mDKaTM5yWBxsrkZgpK81UMryA4nRHaruOhB7qKrgNolbLX
LCuKB49wV8C7T6lUxbj2iUeoL/aFCwuJ5lUN4X8ShTUZFy4of1zA4LY1cN0HLSUE23ILUwbS8L6Q
yLUlL48w6S5coqqhx+SE0QNkeD1FIVq02D9YkYv5h4a7RNhEPDcZaVVA2H3N+tS5V2S5gYeV9QYv
hIKo4BQHULKpGvXMeogE8FzRW2ttZSqRQcxfXXxI7ANhyVjHr85oIAlXx4+4GrTRiVPStvuCJgas
azeQoiVLPmwhujGF1YGdkNy/I2ZVup+AfcyZNK4zIFgG/aJdK1H6hDy98JQUjY1EH20IqPl7d1FQ
tThhbJdamEqtFU4vcai6HJUGy8KIzFReh4/cwfNN9eGd7FQeH1A/h3gAX/MsOFX4bgGZ22F7LXaW
uWV4sB92/wATerQX5Rtzwxe3GSEOAR9z8NYNy9MbwqvUv9AMKLwPqOUQB6ZZPqYL1xCrba5u25XN
dQctQ03CPwCOog4MuIayUoWLygbaUH2hu2UgsGXx8w8CgCh9ytjbSq0yHiGtF5NwgbQVxU38JDq4
CcgUuC1jRnbVQrW5CtB3eyczWykE5RgBYBOViJQk5qeWoxyawZ5J8RzCJVekYWVo5hKpjXkA1+mN
XEVHVxNZi7LB5WO/Ctw7MgCxqhzRyzsjj5K8xtahThTmPBWC8pjNOEbX1AY0lfU7ZgVNBzsBVgE1
Vwepdx0Hiv8A5CE0UsyP0GEN6qKgimzSmu/UsekaaFJT+oJnVSazlnDSF+rgjdvqUq6iPnH8ZsvX
UK3JdXTsHDl8S1al6WfcdccJwvuoX8tOSFs4hLjRlyUhR1gM8gQ836gAu442xBa9gL/YpSYCuZQ8
2CUPPURvBDgudLMGsQuhyUTAnEQFfuJPRiqyI/JHCBQqvic/h7jxcqWHAmqtAgVjniL3yYgefMFP
HETXCELxeReAj7lJFlVAeXMam0+ZUThFLjpAQbpSVPOPc8212xucK8QV4uLXPwqaBCoxiJQc8K6i
1jSwrPDv1LhMrzCuhvIter4INus9TaP5iAA5ipC6gevzFQPLc7HTcuY33UXQ5/iGux4YNOKgHL5n
PQmuN25/+SwTjuWPl3BysO/mD31B4PBWZ47wIQwpe2bvLivMZYdXXiG4GAfMMyAgHTRL2LM55IxH
RR62A7oGmH8EcTBTVtx2OZLQ18zdApr1GFQJfmXA0xfqFOiP3cP/AJuodHC0u/kt8rhkESEGCgX5
hBUNwFY2XLwEgyywTm8sNwczG1r1CyllbjNdgi2olwtDUUi02fzBqG9vtQQisWq4SwvgjhKDbwlM
pS8zqOMCVvP9U5Q8mNv3BWTWXNxi22tyUDWavRG6HQGE4cNvJH81gimuFtmcSvWLVWESClHDsbry
bmVIoc1cR7UC18SkNoCL7h8doPmoYkUU9L7lrVyr6ZV2TY8VL5RUvnY0fmNlcS0oMpV/MVXC5PDF
SlcQbCk6b5mCZbAs4iFQyoY4yUNLyVC51Idxw8fucoIcR1iwBzeygCORX3jK9nPnsIQLdVbXcaPi
C2CeJW+jqD3pbHctSIowm+KgFN0lGRZdhkOmox2i8Cl7CIwNFS/MHIEvBbA6FQ8n/J0K4OiXYMri
t/U5LFwQv5lhNQqrqcH3+pl08BrsnKoiExfUPaxWPUXEWvTYq6MQBAEC9YS2r2HTzLkTLieokCXr
ox8QgBg2QVlBNK7iShFoLYza2Qa1ogA2mrsCL0BusS8IfqMCGhq/yRVPDVd31OIRmjWf9jWIBs49
RBkQoKMIKBJZzEtlIBynf7lYKK14JwgGFLuEtjsBC3cUP/XETIsd11HwuXir4lgNpWPsuIN5tr6h
FtYB3IIq+qcW3KMQBHOmw2sVSdWNxlN5YKW4dNoQeag99ANz3LLXuGvhgUwYxxGVZd+IZ4pkfmF4
jZZyiOmPcL3e4AKCpBWmAQDI4nN+P1KUtz3QXiy6qgfEEOxriOQtuPXEsfCf3L1BWuhcH7QyiUd3
AsKFwvmU8+u13rE/jvxK1WPycdp5Ag08dRSCkquVhmOCgy6WY9eHJUhtRmbezrQiubs/iYBbCPUf
BpBWegmawQoS7u/iUUUoxI4/5KWUHCAf3BWl4H9SoKo1Z+YC1edjlRaXGsbnYCbo3pkQ2gVLSuZV
1SgmLxvfEsNUdAwljfH2Nimq8BzbzOAlXMDwtpG91/idYkP3K3YKX4iE/aBFje4tJ/UL16ljKgpY
XA3k9RwBex7bWbFwHUaqlPqLYIP5mQRZpFrFfccAyA4Fryx4kezgiGtmYVbOBsd825Z9Esp2xwyL
riMVXfJHamdnuFWwplu5eCU62Usq3xEGlpeLEeMiHeQBq7PEN4qMgeIQXTDhviP5LBeSJZTqc0Ud
XOAb7JgK+5R2qrJaPMKG2MA8oHNG1nfmJLUrMic81EEeF6luoChzCjV34jUObmTh2jVtMyNh8R0u
7IUbNi0polg0rzLLWdTOAMqI1FhYPJcbrRDHiXD3fEcTzDg/qasZO7ge5bmqKqyKtFXlxoM8BWTh
Xc0t4usnGcVsp5/KKHGo7C4Mrg6hlg3hdRLKzL8MUBTtUAdRbofcJLaHctW24XQlfhrZSRpZXdIY
2AXXRKVRVjm/EVdwN5jCvAqKwQ85U+gN/EVHp4h0olFOI+CNf6ilEYLztSi9Cz5SALpzzywzSlT4
2M22FUuHQxtIdbXFx4zzzDq8xchyNDzdxOiNVtLzAYKJcEuNoubQ3+Yt8ncFChaHPiUVd090lliW
4h7TSpeR31Zo38oZVaVjHSVw1zUuzQCPDcWEbf0IGJYvXEXKj8LD4KRX5qWhqK7/ABFuQkP4mS6R
riq/7Bha2niPbbG95jwbrfAYE4pR5alQKM/KPcgju8jO3QHJfEA6ab9Q6+Qo457gaXvGmRTBIBJd
ONw9wbnZPqKFioWLCJEdIFYlTtCVmOQaldC0r+LlRBbv4hbti+F8Re7fK/EGYK6uCc+KCBYHF3cp
hXAtrBkrs9cwRigFfBDuM1qcQ9PJs9wMAoJnXMYySHbtjqxNtVUI/OAvizmDaaNXvIQUG9HZQSAI
dVGWdn9bBxA2d0+J5xFBL75jA7C/UXfftnHAV9R60HV4S4VIGfnmK3xyjC+YQeBk7NWO6GLcrDuK
4VGl64tOG8i0OxhoqM/tmipcusZcQRB5b3BRUC6VATqSuIIZxvamINK3gvCJpFivZA1CGih3uc12
Y40i3xUDDS6PgP6lidKfRv8AENFyZ9kBxBaJ7hDrjD4yv4lCaZ11Ue4lqngFcxBrJa8EGEpPDkYZ
QIbVlCXeJ4eYr9gjRdXAGbsQXNt4vsIl4YX4Ur+IP1n+R/swiaa5uc6wtrqNQ4ENr3B9mOhT0wwl
l3MHxOcVrr4l59U8dw3ogo9guC6rKWtXzDEAuzcdkNqqoqr51gj235LyDOjQeriIoC0u1ANAqRcu
cfzGlBaX89THaOADfDECIajwf7G5Uxgae/ECQdBy6jmk+QcTkA6Kuigi306TW8RIMDVUUYf3DvYs
uV5fuCSKi3hXP4l44XshkAmwls9CcC0mqXn9QzGWsMOJZAe9nfvakdEsC7SvLGbQXOSTA4iM3fAQ
KuUFVtQ1svcJz/EXKt42DlflmnqwF8vM02aZVm+YTlnZuxNoC/LWwHbWE4bBO2wYy014jwF+oe61
ujGj5Y9wwOVRbtylu8y29xDOCNtmxIF2itr8iI9bYIgEwn1GuPpDBIC6vxKqIsbXxAthuGix2Wvg
ZY9TVqKsrPEFOuYK78RCg09kNwZbKOI828wXv6lkaiCraY6vZKieUaMiYv1BBc5tvqNkVBE2FT5l
9hqJG/HU1a4av1EMqyM57IIfBHOWJdcxg8EsCcR9K2PruChZhwBdRSXVdQWG9oXXIyWU2XLGXnuM
HiMW33kFT45iIG8gUdkScim+K4lnlXxEWMK25UrTU4CVT0x1hRLNvTxGq8TICuI9h1mtvBFtNouO
gAomDivBEHRfiO5DJTmYFTWl8wKeRyeggrs7sKXGPEpvjPUXu1KSUuyvhFpT6ltCt7mm5Iy+9qHT
XkHdMdgMlmwKYd0+qggtBdJKFt7TzkR5ctVlsdwU4YWTCha1pi2NBorzKpBcq91K5hAjk2DhBcjG
u5aREexcKgGiaSCGG6pNlILXdivlOA0uUG4kMVS7BtwqUorjzKl2/M6RqGqHuA41MGFReQJZG6Db
+YWUFL6P8hHpRaQlZd64hT6xoS+IlC0Upb+4woBpHMH9VgzmJYfdg+oK7FtHEc9NJ4OowZzfqMAF
ePc80wVyDCERxE3g/wAimgHMeS3T1tjkaV+CXcp7inERC7y8e4W4ABZFIwXXUrKjt3DnAeHkjqiJ
UaAEUKtGldQCGD6Tic14JCql36iWq34lqeivhcrjYsOJzFEHpvjueJApHUu7JTLiEGQT38REdq7z
mLeOWnKOgENLeIXAUiY/MXEYsDKaAiPy6ggLVN3Cxpn7g+vkNrmACuieMUOSNT6i+XhRhoq1AQSx
5pXc5/7DroAeGcxGuBsL5+Y5HW+CEtcDqUv2Ct/lBTKhWcEYP4oLfMQFbiV1+ZVYVWCpw+1sF/Mv
mmNd+p9nnDmYaET49w6HYAk9fMqIwDaPFxs2XziJbgIilSxBigY6dXCRsbrK9VFb4UqjcRCbD7iP
DSpdqv8AyVLcWo5D5MUL21C/8IbYfML0ZdUbjsulhR8hCOOU7pKf9nIcvFTlOyKhH3M5mBfiaIUQ
ZTM/lACMmgNpNiHioyE8qCMH3L8lTlbz+paBElTSETypZfl+Zmwjio4/U8+zXS6wYDbBwkT+EwtK
6lddJDa/PiBd6IhdzW6Bah+4AXgCML37guWBBREcEuiyNfvAF/hKR1D0zO+JnQ5y7fmDVHUbRbTL
HCLb9SqIWRwCCwB0KXxcACIL+0z2W12rWBjIAQQD1EheWPQpz6MWFd1cCLW70uAHo8KovVzC8fqX
evwEfCp20Sgj6PuV6+V4Vb6ZQDHcGeLZaaVcMcM6igCOEPi4JEdKfAuPJqg3RvhF1t3jwq/EVYts
Wn5hNVl2eYDExsyvcKdKg1Lx6ynVL4le9ZAqqt7lu2rbsXgEIhRpax4gfbu1TsXUMF5dZ65ijvLQ
L7uUL6kpSE1BF3K8S44lNb31kfYqpV9r7jjMHuLytHVSxMB3K7DIXa29RE6MZ80ESqBnmCSnCVp5
jIBUKPiNsqfM0UY+Y3CxAFFzg15mluppX7lX5jQx33A0BFd3s8TQs4mXEsasZTaVODYG6q5VNXpL
HkTGXjxK1QUQxd2+I0NlrLNdzVWAqANzHpkUPidzj3KKoLAsaD8RLhZEUyrlBCUP1UQTpKefqGle
YxQkuCHwlgDArYYgnt3HTtfEwXdepsNDHwe+YHtnFSy+poXJDGZACDqcQchp5qL1glpWgJRqjCMK
8V5gw8dJYCVE0dqioYDFRxCQaipsStjTxAWXApsRagQUi4Vz7ly5rkRB5OyXaUxrL6lKA6n2wHa7
dQgoS8cXBoWB5IPffEqcKRis9eYpdbvJVDSbGYqMlgRWwWQ4jBIGNTmEurl6b8QNHTRZpv0JpuGB
qdTf6qBXfVKJaB4UtDRTXd8iUJbT3TFRa+eYCtIK1xAyVbDlLehRVVXEUXNnFoottbZBaLbHTio/
DhSqjeCKFBxEcELZRqBeS/iHI4YCKG4AFaZShVnct06y2xgclGjf1FvMDySgWHxLo1zhAJ4Vi4lh
C3ZwfMvwmY6yriHBeRRi7dB4SNgAZdLidhhsQL4VSgkRdlX9y1E50XdS+V3tmSn7ART9RTQxLfZY
0S4qP9dbymqB2WnrYkKzzb77gdG/BxLR8ZjxL8x6FyL+pDiPmBOnFs/iXekpX/U9U/RxCCtdI72O
C0+KloNvBl6cuFiaI+M4lsVnaWrNK75r8QW6OmWH3BI5aBlkKCUy2/EDqQukclJwfRwx6tW0eZjC
xVtQ1WmD9jVWLQAn8UCMSxtub+41ghw7hQyLtqpSD2qZlN5X5j7P46MUH7xIDyJVkXI+235l4J7o
4lm+QK2JCpVXRUYqOd2RSvj3NkCeMqIkbnTi8oBoxGjKmrLjsEqcouI1ggfce6S6KEDYWPtT9QuK
7t3UPjN4Obh7Cstgc5UEiuBLC4seemJKV9ufMV9I7c39QKJcjYnTexApYDzxHeoq6m/mPUZvYxRN
iqI/tnRAC0r+ZSLDMa/mCusVLimJ/FMqroYN0FGjLycHIF24DOae49GmqL5jlDsEEIM9bWWN1E0M
lSvgiqCuN5SkCwEo0e7lOQoKeeIytHK42WJuSSrW4PldogFO5KqD4nG7ldjMVrXCJAZza9RhLcQj
UZFpb7PqBnVto1F1QTG0OUZoH8xGOvfmEqMXDl1GuCXkhZasXw6g/wCulTQSeUj4KdAZMC54SWEB
TSBC6EVrUPcuHylm4Cmlqo+KlQY8+XqLGHC1UFfV8xIDh72Aey8tI4hR9ZB5xcNLEwUoB0i4zy6E
VoPSLBu+hceP3BcJOxqdn4iZx0JVfmc5jzp/qd7sTOxLow+zNfZ4vj44i5wljkdK+mHdmPq3cdZx
HDtTicjGF5kpvRKULmM5hLqFaOu2dIkEL6JrbAcL+I0UvZS7diND9S3FqmaF6gF2I176g7R5lteU
siaPiHBWnc8Xm4mcxeHUQLuWW/EB449wRd7ODL0VdQe8QFbcUsoaUxilWMKnWwQ6NQI5jLoBA70q
viUorzK4SUjt1ALrvTBbOAQxW2ll0rUb1fiIJW6Kg+UoFKqAvy1CmcEVOMSjexuhDk2KmNkAPaJa
WtMlAGwoaWvmUd1GmlweefEs1WENND6lIkuooWvYic5yeB8Sutuc9LuK9S1/1MAxfEQfhFPDTWfS
YoNr3L2n2IIIJdzYOjioy0t7EBXJnEQNt4Zc0o49ytDm4BidzTiDg6gVQ5xrkDgNCl5AlU1hUUTp
QstnlHrRArB65TlfuqDiGWV1zg82q8m1IvpF+jwJAzMFgodjCkbL6eo9HxlGEv4OJe3UHEWeSGnw
RqbCDWuZY5KiWvEbAPknfbucrJYr0xPZUA1sQqoFhkpJYWwKABeOvqWxRrIx2isiROrVP8lsUP5v
xNCR6irA2nlNKW8InMpfEOtIcRyU50lr5oZ7jEWrWlTjy5ThqIVxCoBRgMCDM4QQosGyBEDBqsi+
0VZRsCH1yESDOEKjJQsolOQA9TnUEvxA2CeYnWU/qVFgGj3KDlXhsvgRgy4qgeWnBKG2/CQOSPC4
S1OMGGIHQWA1F5QNajtT2EOqszgrzLapVMOHUqkL0eGUK2mOJs1cCCpkgxEDHAKADp6nLIwdDHSm
mFkCiO4kyIUIFTtncKldYloHI2WygeuoGV6gbGOoSnOxiwihK1rzBxBVlHJDp9CIsIm17lHy+duI
2UDVVCqYa8EpiI4F38QeNEECKpSaVgQqDLzYultkzgtXggqI+BcCKh/SNuhFhNljRijCQUNAoiEY
Q+wuUmsVci4XPJ+4gyNHpKQPY3U/EsGuKqLHJ3UA0SwKu5nQfgEuHf2Xi6gDlKIXQwOJRdu4QrmX
RnCcksqlAKGckQdQQDA4/cscINcrx/MdcY+MRIxvACHyvGujtwUEoLQjBGvXmU78Ba+iIANEcnQL
yy4N7QH1tw2BmjhL54lUldx1W5LsY+SXqWNisGpdrcAp5i8Qwl24PMOoTKW+X9XKWzDsa6/i4XYH
vBGRNQ4LwyiCBaw6lCaEKgRFpfEdLDycS4/B+HyiDaSoQupe7Aisq8lJwQMolWUWtIYGjxsV5hF/
qw30VOFMprR18wG/4ay/JsZAmqr+/iF0NqIIwm8lfNnLq8JKKKwIBVgdw+nkMQHlsDfT/YFWisBv
AeoLvlKjiAMGig83Gwk2KVnmPAnkJIzptKT0fzHbxaU7UdOyRCinNZEnlvkcMtxAQflBhHXS+6mU
BQ5dp8zDwYPiWqeJZZ0Sq+UVbeyphcNucYB5pLkfWWmu+IGTILU4+ZdVOPEPOpZcKhOsJyt7jZ9y
02mo742McjVtYhTcIa4vqUKJbtL+1uJVyCWC+ZU1tjqlJSAr7j4HEyN8zaxLqLA4Fg8pYKuKC0Vh
cUudfUvg9xYv6hRbthAKyUfSAe7uCxuVAsDTuMqJSw/MUAHqab1AN0URNq9nGOeWJDIgLVMovFw3
M4t2WcxziAcdz6gsdqmPJw8EIgCrEFiEKjaYEW73H2JYI2Esbsy17r4gnX3DZ0eINhat6ib/AEJs
WkgvYSPHFJzBdeIU3jMg83UeW+wwb8UuDVDR7eZY1fDl7g2LPLKTwbWGWAuK6cvEIctNqO37VFW3
LHGAQH2wloS3wuOKJYU24ppUeRLMYhwQJHV4vzNO2I7YiQtx1Lbk1QgQAkLfM2BAtq7mx7inMQhd
DUAzRg+5RgSUoLJbuDlUqkQqEUU1OILUhGj6mwEQcqYlysiN2xh8CNrFBC+YwVQyXMa3S6NikApG
VMAIDhEwsn0JdWL1CGtQSwQ32QlKpgVcaW/LBylNB4qKNhVs4HbPuVW1KeNhWUL1OIfaEgcxWwDp
1CKlULFM4vJXiiyTaLTddMsAY35d4io4LiQZQige4PQcaOc2OwrNOZjjTaqhCWlphxM7zEG3W0n5
RCdJx0lww+GRx40tZCBFRmTaF61XxGNhl0epwxrR1GhKPwRyCHLLlmNqmCI3slNxWALQdXsoNEUa
QLKgT9Mc7VNjyXCU7w3ushEazuNwELtl+ICdCy1zkG+vBcyhEFpi4Hjq4Mua+cc2HJxGr5k1xr/s
pu6AskKi44aIgkHZ9PcaJurF/EVkqoXxMLe8QCYsLOF6giGdTi/MvCnNhACkUIJCC76u/EbsfytS
iYBUn3AsqN1IqvgyMygS2ZiIFifMIDLxabBZcFwVKDZFvucj7FfFImrT/oiIFtVirxUDFB8b/kus
JQET8y1hq24d4+4EGir0stqJgC4vUNe07/mE3KUDsGNExQNwDwKsaqy46OREBpRUJXzGuLbV52NQ
HI/hKR5K/mCtu11/cN4DlavYEnlV+YB6F/cc3W0/uEta8BHqnDmW9QzgeBxyxC6AccX8RSbtlqNy
AP4V80m/zCbRBDzDGElqsDggj7Kq6LCly1G/coV0u39Sgks2G4Gflibpxa6F/dR1Eht5dRge9Oq8
/MJey/MYCShUUt2/EvxMKmVeV8w9gwBVFRDsAC6BeoVYtAPObLImYYl4CF3CvYlJlQRAByEeENCX
83uWmcE1tdQI1QuqeOIhVMNd9QuEGnuXkTWbNcptUxecyOtGgFTWxxMOyr5ZuV7geF/MAwEEwOoU
xA0BQijIlunlgdEIw3HvWcT5GNzNIZ5NzztGT2vvJbaYjKY4GoH5H4Sl417USp9ZW91kH01xwB1C
FLVp5IvqKsaHHpnNbywU3yxR60ilrdlgSDwPzFS+4CmkQW7EBZPyyyl9RFj45iEKuVZp6B3CzmxR
6ERwL8wXlPaBQXko7fDxALphqh+YqUb/ADF2mIio9FT2YRCQLl7CBAphaBwlOtcRbi8m9xHSZzAF
VtyiXKCnmCj4lyBgqpufD3LUVKClMlEzItHTLDwwQgEppAW3ucLXMXS2XeCrhzTY4CKeZyWce42C
UfMEo89ykLKXdkOrEKgiviNtyBVfUUWWbAU2o1PKcQDTQDBN3O3oZYOk9TE5RLBaCcDKNCpIqqu3
yS4LL8wKPHiKq3yci2FLEUFZew6nxhNBNyoguklrFkFIsWcgAwnQq2VWmaVCUO8XUJgsvmPcG3Hx
TCKdWR7jUiHP1sU1ahruGzvB62XydJfNEZraWEdd2JheMaHRlptKw4dhVaxt9ZG2VUKIba6EZc0s
TBMRKZ4+ZeJYCLzU0eQg5KxhIicxP7hmcxWLIgpvPUfBkCgnEEepVFrSM7RIMOIUhBTey/XZXeiB
OsHSMdQX7g8MWZ5glgdBdyqV0pXAadsST0QQLqAiFUBH5YX6b4lNyUt5PMDg7Neaji6ZOC082Ily
cQALbPBUtQulHiFLALIKIFg93xLWcaDzeSnRBVL0gM0AZzLuw0kN9UNErJjp/wBlLYoGrWo0VJB/
iFRDQvuoREzHA9x9lydpKt1owsC8XFmtw79/8jrcOfCGNog+4YEoxHgNcFH1CJ0AFeokjld/EWrx
ClrmPZp7+yDWIraQ/mUlrJrCjxfzBhojeoNVpd3COagHAucE/kXfHAuVfewVcqx2VyImBHhGkQF2
B80R7N2QktUuLHKviPcbAfpihHj+n/ZQiAzwTnAQD0kwOJZxBOUALBASYsFhcqrBXlvlnIoA+slr
roLj7gu3vlitZrBZuipwR1X0RRk2kNej8IOr1f3LnroI4Fy19UWB+EQKySnnCBoLbznCNwku3r9Q
UDXQN/cbhdh68QYA6Xhhljok0QwMWDpGUbRL7lJTERYodqm9huq2cjEsBpjUUNPgi2DQgHzHS8lT
62MAWDX8wOSwVfm6l1C7AeS4KF0OeramhYf1kJNBd/MCoYRC5RV7s2OxlFrfiMySiy7viD0HH8Mc
t3Z9+ULuDD+GHpCvuET4qxbV8RINQq/P/ZQbd4/iOylF8uSC0qWFUYw5coIc9S1zcw7kpHS+ZzIR
o+1zJ4S6DAX1iR8lEdAAaRpqLUGoL6yApD8FiK4pBNWxsfjJY6vAqiv8KioEq1LF4+ozEOG9e2sE
/DTxq6qDLpKeP/MBjwUUQALYbyQJhgPfH9y+BwNqvqbgsk0uru34lCFMqmAPUS6h2PmPVIAR5JuR
g0NNh+XhLuiqr5gpDSt12r34mHkXWoTQY87wnjxEOqiUcrz8S2dcG5ANQlqg92qXPI3yGojeaNS7
e41FTD4FoDm6NjkpyI4rjuFQWO5R1JrmsRXaxWLS/ENkGycJ214TDuwE2JbcuHCpruhzUYqh+Jcb
3GrH8QUKwXgS5YbcSNlQprOYm+GCz+Y0a6hwJ1K+MO5a/wDMI7xCc+xAFOzCvibbDZdUTSLt/UMB
0yzeiFTEIHkw6YKj0TC1WzUq7iG1bBDTnuUU+YrMvOZzz8RgaCWA49wPemVU5VwIssgwbSBFXEKP
pGlHMgqr24tUMnMWvqNVGSkruozpQ6lV10RJfGFVeEo9Y3GlW+IkayLlweoWujtTFHWVfd+oCxrf
EwHEuVv3NE+FxRabXzHjBvkglrs27q0bmK33tzAWswYpXeSz3FDt8f5BIfCFheehlXdIHeqt1lo5
ebPM0otDG3UrIAOuB7g1WIXwQIMcQ8FVUuCaHSXNBCX8ziyOs6m4dEdIKNnruMfR/hR7Jt2jegHp
iFawt+I3vAqWHRo81GF1W7jZn2BDi8Zb5JhgJWmM21TKCqmPRxJgWeoG9XcpJbbiDiwQ8DKwmxVK
S/cQzUBnp2ClXb+IxCynPEeFXhGI0rHHBS9BuqhZT1vVS0xniXiKLnLsWC9GjxkMApERKjA55lca
IaLN2e6lQWixB7WuOKL5/cLxDkhuuyVYvgrMQgl6Al+ozrycY9oERr6lXUCj52VJoAa7mRBaeZtg
lEMS6ol8XxHwA2Xnc5sIub1FDzTpKzgUyn5uA8VdE8e4mC+b8VGtAW25iQNA1GxE8Ly5UGtDY4Ai
aVU2LlEQwQ+M658e5QOuMdqJN2Db3sYnL+GBb2DMPcz6+6T0Tse5TYAt9QGwPTFOa2PVRVNL0wh1
1KRl8aFKfNwU0QBfiNqo00lEV8HRdCKLBsVB+5fOijQX5gquR9EelUfvghqESVWvP6l2dR+PEUGC
GWJKAoKCgx4AHK4ddiwWiJJSbfQSz4V/mXa7laWop0Cl7UTCU1+IALQ0x/BGuaVH+4J4/GFwj0Vu
EuinI1TwS/VRghoEpuHadOlRvyGBKcC0KQnIgOYg16rG/wAE4vBs4WtmgSUVpmx69nkZfCk81dxu
1LbIGsHmiAFiS0oq4gV3wehDAA0ua/8AEbLdqLBaE+GHwFQG1twRSr8GNzQBWre/UWBZO3Fzna4K
owjNXGlwRoClNUo/mJBDAI1XmX2XwLbPEOq/oS+IbWblzhwhwFpcXVQLmuPuIq2gKahe/wASjGyi
7yBivB1TMTtF7epzEALNChfcTWsEH4P4nCQSDmrshNFSbU8rTz9x21DT1LfzCWrLhw7gBnpCVfLB
ddAG2cD5gRWsl28Cw3tC40uNgS+potNYHcZIcFdXw8xNEuVAvMADWyqJVibz2uP9QD8rjpMY6C6S
nnuCDxu5qPS8czxeygrCakOAeItnFZTuSrsKSVT5t5j4dCCN8LHVnbcz/wCyXklXLK4Qioaiqdb1
NOSLMN0xQNuyjcPKCha4d/mA+sNeX/yAyi+/lCYYAwNUiXzB5LyL6IjMI7W5VdHuI+ZQ49CInhWR
J5JHBZGIMO4SJHR+EulpsSrKYqVcd1qWazJy26JtA8zQJaca5VFcyneHiIGETXuOlOYrRKfMBJS3
zKLvcRoNvxBKbbClLuGT8oMK69xCemAPKU7ZBXghG1GaQ9wlafM7DmdvJ6itPNPEHZ5ricaeIAVx
6mC8J4OIWLrYthex4hxHDLmaNnxLjUqFr6ia5T+Jo8y9iOQ4K3AZGohq55jowSbAKIWteYeypQJV
MqgGvmAJo+IlCmdQI1t6nQDiW0CCn7MoOthZ8tgLPruCxKFLu2W0b4l+zPmaMbYsJceaiLrnYqLS
zIqrcYcLwzhtKrm9mGFnuV8IDl4bhaBZQ7MHoVUaqaoypioEdaiBxy9lYBRLqPDllaKPmJf56gtV
pDp6nZOEL4mPEXApuGn6W764yImt2fC4SjU1YKBNZZ0gLrIjYUEJhGFNNXnmK9wEnVQ98oM+PmGQ
vKX3cOFrYFCJRIKXapveL1jbnidrbF0MFFpnmO9NQbPDACnWcufqWM4mQYt03AHOYi2pTmHloXfu
UhS8EjM6277JUKGnq6lfq9XDxCGByc4mtzJ0uDSXTXHiHk29I/ct/sVtorP2aqhD35sqc+Yt6LlZ
XNZt4ZYQyh5CbWtTiAocEKv1sppqVcETmD9kJYIG8nmICM0fWIrAaILjW3NLI/mjtUpBHmslJ3s2
CyVNuWpn7jxVTmirlPVtU8xlQLkd7K/tSgz9x2YmIf7HgskGUNY3X+wEi0RalW70LWlxsDdzb+4m
81R2Ik62p5JntDdjUpO9KDliIY2mHCRZNMcijzly/wA1gt7lE04AtkAeDKqM9Us7ighu7VEGkcck
IS8w78ZGMaiV0TmTlZ/SGxCt/wDjOcrrjtdQ4APA/EWrvFi/xDzYgzPcTeXmN9wMb3g5ECWbVjiL
CuY73KlPmg348w2miXw/UYdbKN9R2zV2E8KjpChtLVVl8Q4kH/gy3r9LMSMDYuH5l+OdK2Aj5SJj
42BCTNkXzPGgBig3uCjP5l7yKsoH7ja9tj+UQuxKHH7h4INjW/HMO96C8P2yqcCkKX63JetTpWTV
+6pBZSvQ/pJXKg+AxGgF0UOeJdFdNUdMM0IVfA8xDuOjZ/VQKXftVEWN0GhU9sfOLq+ipXgQs52U
S4BbigssBnZqEQ6JgpNhdgfr8RLrQTTbceIsRt4pIPKhYQfiodUyMUHjiXHjqt5EnQXiMBpQNH+o
7CE5U+PEQRwAcvUNHTB49MLy2BgfqIzlUKC4JVFvmbnyEbExzZ3OdOrrSiKljYFfLNAHGYWMmiIL
p/pnMVnCA1AG6Ss/iUyTb7jLYmeNxZ9TXINlKBydnTLe/uXWTQWyviKVHsyWs27j7lbBR0iJ2Qvx
oi5PDrxCgNt1K2YlFf5gmBbLteUhdiq79/EBA3XCeoRwtFyB49wGQFPhBWTly+lBnhgwBAC4HWyz
eD/Eq5i9CyOEVVRb7lqkThtPUAbaPMW0565LWyqgrfFckQLLgaNrZhrLZdUs0VcZYVkA0BYpPUG6
/SILES3K8j3EReVHiBAMHMbZN7mG3XFxRpxOA6lro6R0ypcorZ3xPtsuVbC0bp8QCyERLpXxFsJl
0vBkQ6R6Hcu0yU66ImDxEsrzDVc+4XB58Q8BKbFiKKuCvlLqrkjC9xxq6jQO0YSsjhb5iqBVRTQ1
Udo68yyAhLXH3KZGwYSPBA0AXuGua56gvqNXAe5Rdqwm9+Iwbj1NqVdmRUhybsS2Gx4HBzUFk3fq
b1X3kLlQWnL0gC+bMvmU89yhto9R+WWqunzAJeJ3Essy+Y+R4GwWQo8MfuRRDqpTwmjb/cf0eYrF
LvtlGI6wA0GFFKHRLUfylyiAdeYV0ab/ADCVvUqV2+VDLVrZVTN5LakhO6Ypr4iYpdFElNnOLXID
RHyyE8eYX2OWc4U1C6M0LL+SdYuX3mCMssD8RUvjVwSpc0fYO+hu2KI9IldAmzzUdoO8VENQibKL
mOOJcrOcjYs5O48kyGC1Clh8xws+oZa2gsGPO56yKxk7ukJrjU2K6mqYq9ovEpGYcFLCBxRYgCK5
Moli1vE24eb7i4AWm1TRZOqbfbElDS3ZNIy0gZcygBxuokPXhVSlRBqhlDa4bciAbBQPFRhrHogI
q7uRSm+XYVpraGqYaM1wMUk+r4gVlTlZvDRpXUoN1udsCAHDzMjdju5y6VrzL3CPtGixdVrIL8AH
cuCdAHEfCi9VxLCDeF6xa2ENYRWZUeQ3qu4AUEygwTuSFNmKNznyNUX0DHyHaqJxCSviMoIYFxQP
RURvg0CPjtoC0ACAfA+IIGdmXrqTFgjlxztY7UAOaliWB1aiA2T3C8uL00QBtlYyOQ+bZRGQh67g
kIwDzNssFB3LgqjBtTM2BPq4xyyUcEQ3CmBgpoDucJyg3fqLt+6YlPSqP6I8h5h+uJiAOwVEvrDx
BqFOc9wxpXzBzTrWX2vTWoDQIvG5niuqHE6HIFDYWdo4lgSZ9Rd6GjYw5O1lK39seAvFz54jh+dx
PzLlfY5Z1ALQRMgbFi5U77D8wAvFRIWVClwY54Db8w1yO1TX91F9NWHJddQ2g1s8ni4hA48uhi4t
KgLAC2YdaVnFMC7DiOlO6l8pQ5ZsYHUslJzzAZhKop1AYSqh16hw8cm/mcHLDq/ekOEqhrnalegS
uAdxAXZR/PiB0qXXH19QVSaiethggL7XMXLA5VNojt5qaOWNyX6qnXqDkbhXJKoDI4fNVcr7vBuv
cQButgbIeU44hKvfRCuHCVcqUi8H0IHpRVNmH6gKUFqolHmXKAo8ppBbYwKnC5RdcqRuCwBaj2nU
fcqtyA8xtToU5+IuEfhATX/U8GbI+yB8p5qahBzaXGbcJsCH5FoqxWCWM0S32igAWCsiiS/EoXqf
IYmr4WKFpyMgDYbU5By5UNO/CU3eKhRVNdjBPOWK+UVLbKN7hAbCo0S3cA4YxxGAjphTqNWsCobH
zFOQ9H5nBewVXWMuCJQLeyuBfuZNlhkp6xKwHHazhdKjgrnxNHxFR0yJFtUI33EqiYUHMdzmwoeN
hZzstRR8TEOJ48BpXMDGJ81LALvxKKXiKrq4IY7LXwGWC8dwF2UV+5S60+poEMioJw2UDs/UtCi6
q4nlzOoXpIOiWj6Zaf8AIiPrslbfDqDl/Ut6FSiBuxUsbW4t+50FsG1h9yrdWaZCw78pSIV+Zaqf
cEEU3P8A8LEU2FJa8WQqNUKYAKh2M5LL+ISrwqAuluplvwfiUaSy8g8gbGBtdB1BodDy+YKxwV+Z
vDBDuXjZYsy7jGmrc4lDFtodS4BtxFR4TyrCWhk5TmH9kxPEIC5VHDKV69ebisYChtHoSHqTRkeO
FZXE1EKIgGb33DWqZQM57ZVLdTwSiCNUuatImyz1DFwdVBqhlhbrLFnBrUrKVLUvLiFReROYTIDk
lwi7M0EwVOpeTNlV4liLSvXPEo5mrOMujPdwizYNr3ANqTHSozdJUGdd4EBFbLrjY4ScRSFAYaYd
xGru4+EU5EdfA2ocIAtRKuAoBsviDYoIZULUOo5QMq6sCjZgIKbU7UbOot1F7wT5S9fCcitjBQsg
Unq49mcwTA0OZkvo+CZsBu3QIz+42vBlO4OosaZH8YKOZgLHmbVegI80LXi+oa2AxJnmFis8eJf1
wI5jpKVTj8VEdHoO/qMVB4qU+qeqjlCvWRCGABzN1tga/EHxCUMfErc3yntlg8FDOMjGiFUCpXav
vNltyTocvWUYVlqocwL35VcJhLVws9RYsdo3jJmEbzqARusjHdI888UZTuHNlvwLI9ABn7lMXuYS
/iCEZXc4gY3wz5rCgVCfNhV9V/sHGPEeGHyov9GWqqFQFVFpmgQsgEt8IqVKWKiXxHVyWrSFapMO
xHWq5Eh0I7VptTg8lB3Arg3RwYOMHdTGxCHdRQAtQwxlxIoM8l3GxB5WxcM9tYk0tyioCmlOPdRV
gd1hxBSI1LeoS6nAML4lflzPNFzdAc2jqllJaoh44IamtoDz8QTDcu7TTA/gI+bihai4KNO7HMZ9
VV5+Y5OS7S/9gcRCEWL1MSwXBXUI+BZw8w+9cwTS1S7Kv9R4dQ243KlQsGPsiDewj0H4iTcA5b0P
iNTdkFoOW2FHClluZOJc2Otl2uhMWHP+Q2GDAXRfMVur8Od5+4AL05ZfX1EhVVCDfqGYwha6t/iJ
o4IcmBJsHlXwRV1QSKLPmVwisHFGCBwO5FFXVfMK4TV3AikX7eIDBlAvuMsxwUr8RCWAcEPZNPqp
/YQNQJFDZDbFwcO3c5YUIXCWY87LzzCTyKOekAffBhYYfEpapyEVvnmBiKg9MoDuAlLfUNmN96Pn
7i+Tw8RqASpTgAwtw68wWNZGrrxG5JBSSy54hlA25gG+ZlS2SqEGCsDYy7NQTuDRFDBbgB3KbvPU
Wg7jd/2mmyQS31FjzNAvxA0lXEKdxUfcAIoJe31OlOeJYEaAq/ETgVCuVsEFG9xbHzGRGoxyc5cB
+WBUWcMlBgQKiDduy13cYeks3tPE2OmcA/MvD1LKyhDrzNldyyDz4ggg2++ocBVncUW2cxAj+YKg
So2WkuZ90RQqxst+4BgRBejMZqOa1eo878czOnUQbplXV33Al2yhjfiU1osSG6SiS7gSx7qNAlHT
BeCM3cz4DxEQpgcQspgWTVz0ENr6SxVwR8DkmqFquoALW+PU1D1OCKeam0abqaQ/iC8974XBWZBP
Ub+1s8wOWGXO1fJKo9P1g0HnvmZpQK+I9lbdvJzFUFCnhHdAO5uE+UESIh6TIJXpSobKjmq8x7qF
JoEHQgX6IoaKK8bkAHUaB15hQEqM7XiCVu0lKXuwq7uWCnZp4+otA8MSB74mZQByPUQbnNP/AJ7j
yoaHxLXd4r1PLSh5nNvfOkusaoLjFqboTp4JyCeb9URLIuI1oCp8M7ADPlxEi+IcQuGwXxFbC9S9
y1vpPHUAvcix5nFm6Rn5hcpGvonl1Q4LmgGN99Swku3/AFD08r6lzKri8S9cfBBQTsyOQnGvuadp
YlA55juUQNWRGl/Ay2Xgm6LJcoDhHILbM+mPR1AeKz+5SCt3dXUGIH0SzCIqQiyCG6+JZCfa+4DA
Bs/EEoVxdd7Jy5Bfww11VbfuA/IHlzHKjuA0ynyDknwXQ6SydQ5gdmlPUFWqorsYU4tAqiYR8bHY
rsO1sgGtch66YJqAp+Rl9CoK9xEZ0FxZYp3wM4Pu38R9SQHesb4KrbfHE4HltlNTg1XYEagXjp6W
eOU/xKESxO+LlpWFpZ5gsZY3L0q481yF05v7lF4MOJ/65cXIL9EwUkLdPL5lufvezNopODpgZ5rI
3uLCguoxHA0DpDSjFcPeYRFi6NCOMiohBBGQlqHr+7FNkaXLD7U7RpHaDErxKD9+PmdE6XxHeEzg
Z+5c829zqdN2VNuRD/KAsq2IK4XUSUaviWxvOfSOlr1w2mcQfuJUkSr8pUQ0UfM2UjdbYh1rX9xu
PBDDxBfctjaxVgFfzK9U60t91FfY7bWDttFprFyPmuPiXsoCbkLdpQVA7b8wFA0DbvuBK9hwBQ0g
fTNY47xU4WpepyNbKuZSE0LDVMbIvUUg4jgHwm71Brqlyr7YZl2Xw47hzsZOEPEMQDAsKD/YPzAL
SC5x0wDVgOr1fBBUCKtKOV8ROpYFYeyNv/3XpSFU5Kfibf1pXF+ZwIZscvB69yqFsEzWZ5ZnS4p0
3F8YXIncMxYpwVtR2DGizLSDXSMWj4iIw1EKO25VFDugXX2wUAANjx2ShdhA2+GIAAUnMLE7nmyI
VcclpaJPyiMhErrY4BdzHilhsVV8+pbplFnCWrOJRWCp8RrTw+4YYc9yzoeYWIMWbfMVK8nqLRfB
EAeuYlE6hQPEQozkAiGsgtR31K3UibeGPDB9osUK+JpS5AFD1BA2BUI/MN9CXENH4jUG/qG7TXUS
u5CAyzuoq3dncpej7ljzvU0VygddReQuISyqgvUEi6IFOYixM4yFo0fM8Ao8s6GHcy60fMcHiYhv
iFIcbuY8UxEoSImm+pUI66gVB3kBC6epch4MZdl36lwsptLWqlc1KF6Y9Q0XV9S6F8koQdI98JgA
p7muywbKaqADpnbB5xREB3Ufeo1Foo3ivMrwlpBpLI5TqNgmq18Es1I8yitaagFrlSy4GjIFTy5a
myUF0VKTqrBeofZAJy0BucABgdNwAhLp1UoBc3uANTDf5gv2rfDdS+9KLe56JRdXNAARfecQ8cdb
7lB4DR3x/sRjeGBQLUA6uYo5QX3kfIIa+5aCx4CEgMd5lHPFTfBFgx1jOLiRN8eIHSxWlp6j1EBB
hfMejFRFP5QqcG8FpV5/iMEYUfzMKuHxPJHUqbv+seo1t+X54hlcEP1iVO6A+SV/ypWuvEKu2a87
A6oqOKFw1mZcSI2ZK1RGeetmEo2v1MTUVXElRijkWUhunXjJQjG59XDk/Qg9iMPMSkV4jD4xH7hA
7BVd1OQtKsRsAaPcJWisrmqmW121T6jZIUeQliIYMfzEDEgRjPgwfMdwCX7lMbC/KcwwsD62PvJy
wa1qjwXKgIcWsdhY9EHi4jALr9XFIETk+GZmKl/ccKmYJksEGaAgQEsbAnmMuWxHEcDhgMI1/jmi
shwUzY16GXf2VOIAyGqGoAwrIngZ+nEa22y/R/2M8UVWXOM3A8PxEK1AarmDQB7V5p/sGxCnY2zk
FDo+EURKtFOKIzWB5fUUiEHHuAHQbPkj65EP3Hbbj5mhuvUSUM7vonGGsPRVQKyiIPz/AMgDa/pl
iUCL9/zMCCU+SiDIoV3wcxaVsX4eoDwKseYV5CwOmcw1A7TxHJXi/wBxrvW4SRRSaX/Euzjv9sCp
gL4Ni0w8j3eSwZRDy3Ajtw9XGrAXvXBLm3Z9dxIy4EWq/wA3LXH29HjJfG4g5aiiJfHELDaF67iZ
avq5v2D7PlLaREB22icmsfEVoFGs8w/EJXhccqFsflCRNQBvco7TfoivtwtkRSbp3Am8kA6pl+pq
ceEOB/uAgjWHUV2cUv3UUG+qRtygxZ0vPzCIhbXVv5i8CB+agB0oF1sq7Ko8oP2SmXoxwvowKhyn
zBe0C2ajhdSa3xEfO5FXqUm1ReTiBSi4nisiIkajR3FaBFg2x+qIklE02W5f5gpPskpWRzJRodl8
wP2ViPuZZ0uEst2dKAQNMh4TBe9yowUQVVTjP6hCMK+Srz6mWalS1BsPfEZJEoS8v+wcm/Dz6QQK
EabtX+pQ4UFzR5jeAC9KJcBteoco7H8CtuqDDWW9AbyK8SBVY6PxAUwt7XK6f9Y15gAO1meWIzEf
PJx9wUYoEOoAR53RFCl5zDIFHmFv2QqyiAWvg6lAt5me2WKEfPmXDcJVWORoDLmKZZxFNNpORZcN
M8RwXzEHpOTUNnqZcwOFtsuwG+YgX1Godkp4EVaEuZX4m9Lw6nh1UubpqK2wmKPuIA9xfgy9U56g
WEuvMqU5ipy6jrXZi7llBcyE1mEQA5C4A31ORRnUR476g6VxDJE0wjiOpZ5UPnmIF4eZczglOYqc
+0amnyiVU0ZFB2dQ0SjYKBK/uc4r3CAuTlvxty1UOa2JetdRI55SmrzO45IqZz3KBbuUXT6IsBVS
1no4WIzLV7mIRFe35ggb1djq2YwBK5GBRf48xGy9wAiZfwl5S7cS8nPjmWK/Q9xlwYx9ymysvsYf
5Aai+5OJeqmVKPCOWfEAYGLtQxiWAz2Q6Zj/ADCs3JcGUI77j+goqWWlaH3LntVW+EB4KsXBrfQ9
vqUqlngccQpNznn5m58SCW6hAxuUWXtTVLbrmUTMmtnTKDmo1zYrxEGwtiLS011CrbZlu0oQFE+4
5A5H4h3aJXFxbA55hmQhpTfxOcFa1yIsWryQGPNoBeclP83Fg9dh9bBlgxbOqj5zC2kvcLUe1lXq
RWq24nBrroQCAKscRxADF1UrJgIUwKqSDzsDQpWRIByvtL+1G7JuJxRj4Ny9XLaK8LX8ysUlWobh
AtoWHxDpPwtK5o3gWjwslhXMOLtea/1NJFux9RfFdp4agAYdQgihw1ZQGm3EPQw0AibvIrrl2y2A
UfyCMgdis65gm7SlDio/YC2DCCunBrEUK8FEJtSePJd38zpuUyn11LjWkuf7FDW1XL+JWMqy/MZ6
KqvFepeA0r9XA6RVJKZVCaBPMTK3SvlguHMDc7U8SIW3omr2sy+cs4h2KVYohadzYxcs6vWetjxd
5A05jYJTbo1kOAhVX5YioX/UH0eYeVbFXvENShlCWnuP3bXJCpcUhVxsjVWK+CDcqmkbVt4lzrTY
g4dgyBOJo9wSFikkS0IRB08kBlqFx0pg8VjCMmiMwsTrWU3Q1GEplj0aPXMfkHkC/E50VeN/ENpj
YUag4JQzKKyAAFLVsEA8w1g7LjF5bQt+Jc8FSgH1Fa3KFhBVqjcKhhZuX/4l2b0XpBiotXyL/cXq
xUi/ibJ1W67uQSaAGIV2MRlWqi0bV4ThfFSusyN0f9js9AEG4g2XUzkB14Uw3YNLUGWt+FQqtuUY
9sB9MIO6UBthBGrkF5h1d2br3Dg4eBXx5gtSmIv4iJEnLH7S4EIF0VcOPusoxaqO9weAlp18hXsh
BG42oSKL8sU/3FZglBqi9lahp3CvEeA9EfoPMQld1QDhvnmDSCwcA6oi+lN3HH6jEAEBgcDC6TqL
1bEElpcF9SsERMwcDzEulbsXK/mJhWstL5e4AKFbaR5orwvmF3CiOJ8QlQg85WAdTvzE2N4Fx0Ik
GlngPErnIBEHVLNbiC0dCyqxKRkYETeDBb1bFGXUEl4D32xC+1JYQW6ioLfZDMczZ5Pv4iBy7V83
DrfMrg+2JTVRdbhLIpglSlyxyJYFqFXfzFpQbYw5chCXfUbqL+IlEFtdSlQ+oKo48RbSqiOmRG+G
XVIgBVV4gbhT72awUwoPC5GAbKbdQC2DfiWgdqIVypVOQF7pGcn4l28nbwxNvxMfEGlRVeKleFrH
4IMa2+TECWyhXuOICa4hS3mUR2uoizWhVkQhqqlq9QUl4Ydj57haIuixyL5Op7mpVtcioXk3lkBb
z6hoKMYNC+pQ0fxKdOc7ikJKlFgpYyt2+Jo8FSwA6+pTau+J3mooG7icrS5UKG78RK+HqU1OeobO
V5lqHjiAPTxF2d6//PTo3zAKY6YNLdMagQaV5lOhuR0ryRa6U9QNLwTGAeqialnhuD+cXqgdMN9Y
86qo7NRKGow/ladSxQVbVf3Kcn0WH5iLTVsW/mMhZu2XGGQrtCBnYp+YjYFNKgKUdBparZiNCrDJ
WrlWTf5lk976r6litvluIWc6jgviHoVKOm43cDPUIUKjfmULcONiEtfUaLt9QbceuIYzuIQ5Yo9V
2eV5BmePIP3PMRRwILQF5jlOIiJCK0beonYx/tI61tnxOvmayOmjPMSLyHSwStTL/wCkAUlTWVL/
APQ9MBawBonHXVZvyS61G3OGMgG7ePcXOWLqChNaOIbR7Lj4eJSCvA39QIL5x/UWLUbXMHP0v/Jk
1HlDP1Cxk2sbKk4og5CsaDv4lD3duylW139zpX0FTlmWvL3Dcj3pRKEBVCl+5d215z+JdrqtFCI1
VIMvmPkXP3BJBrF2mB87jgJSo+kUP5lScKQJL4MvIfxEZJWLtn7hkrnDCYPJpXmIFErBX7i5r/rA
inMs1iG5clj9QDEdikhRlrQ2AQYwpbLw+FSs+I4tx0IDRcu0SgBerSS4Jd3kmy5cHDClS6MfUbtO
8iNabTqDPyg0IsKTAbLkaVLlUbgrKiVVkKiw/AyqPyuTANK4TqF0yk6i7xIaYSVnWNVPRxESIPmq
5hgUhoBEXjXlUf3Gl8AL9oRdOAP/AGFqPZK1iu8eLwlmJvBKiQoPen+5d0WrYjSji0ktCiVQiXxI
dI1+5Q0eFwPegoWfuXB3Y/4IHGbiA+RNXA3xfcI+gQfSzKae99kjZk7ct9xtQuQUJA0rUt71imge
CieMUAJfYi3FQ7C+I+1DVeB72GVJ7BHxXyC5dW0+c+mPUMXbsonmriD6WOBChI5q1VEFbvlZuO7g
JzbS8sqJI5hZR4i9tYHiwOrgTb/FpUurBfbZVU9W6sdXeRuwvcUm+jLDgA2BIxQHYU/MKjquhH5l
H6OBSH7m2tZ4Gv3BCM+01DgVFniS3IrEhlt0qKH9zLV91NDy5giHZ0rbWZBVfYmEniBXYyIDoDUL
sb72K7XPDU5QDLtAmhMZH7jxR7sfpAE+ZTGBFLlBE9pNl3TzCKZbLyr3KYpDmFRWoXV6VC80+IoW
LqAUlVfcSGtV1Bib3xFonJUK3nOQ5eZWOA5gNNsVWSllfcukDRioi0vWXxWShl0Sw2FDWVnLZ0W1
PYMrE6SuBs7Ta+IYX3LYpzHVOoqcU+5j3NN9ID441WoeVpmSTbGWZVQV0lUqlqK4uZASg3EJziBs
ZWAR9br1OS7u+pz3KYhLtGvUFI5jhCQ8ZFuwNFWRSsSmEoEsI2FX3LXzUBQKPcq0XK2uSBKxNp5n
Faw0uWlqy6nLnMyvh6j0LvioS4rMWAm3zLpVviWbA2UG4+JiR9bGraiCyrkNDR5ldVEu5TSFfH/4
gJRCB61DiGhWgcO4iAoNfSL1A9yha+pU428SkttyAAc9yib48x5bVcXHuhORkVBCFVWT6ga6eYAL
Q0gwSS7ZAVHTYAKa+I0JQqF0C/icGxd1dREKT1jM2jbTggdDgq7gwUs7IHthqsRB4dQAgfEpbdyY
KXtMLGv1BK23xFgUTgHHcuq+ohwSvEA3FAvm5VvmCQSFUWMMEyYpcdylLu+YgAhTkOWC1ZL5ocVc
uqfiqgV8bLLqZYReifqX6FG31HS40JDiqAXbq49ktuDmVhbh98xXVQHdEP5S6RUOsgsEvuXO7LWb
cAILDtwqKjENYsKlD7SsStECspZANCV0cpuIrmOHAUyGKqnuIGqvZBxbeJwmHoB5ZUyq4btcSiZ5
VDlcq0C3F4RDii4woXAbLn5oIfzBQXTtIOaN01H0rMcllgKWaKZBnYinOww3IHUe4ShYIQbAmsbk
wU15l2lBdFENGBeEojzZa4TT7Jar+Y/d2nKwUwgV4iLVDmI+U8FwKzi8OWDNZIFr7jomsomkyi+i
lgu1RocSjJVyOYzC6tJU1w7PRcQwQbEYtQBgCCOlJVcS8duGDYGk5NwiU2ABqpYaCzmDt26mb5Xx
G2nhAQY8hMoU6YZaURrayHaS7qI1Yu/EROIDQwRxaC4ORuc6QXUKop8pMQx4siinqylxshZ2ZEyU
F2kt1BESavMYeaXuKcXSdsrlAsO5/EvKspwB4SHHAKOH1GlUScdFlHqaIYzQ2IkVdP8AYVmqKpoX
LyDMgKGXA0OUPbABHAUFYs0TlcXlbLQWR61LxRKnAsAWuV6mPV+iJ+ViFRAte6O0Yj4IMCVxbaX5
oVnCGJI64I8QTlHUoymuhLAglL0VENbrZZPgqLlUP2sJrPnA655mE6Y6E6PBO4mwzlU+oHSzDpsv
4QPJzEt0JodS5m6o52XbxKoM0PRGI46nF8fMd83ZKCymodKBQF9QkKRq21xvSF1A+YBXoANTveCV
IQUtrDIRLhRwI803bK6o6BMvJIqlbfuN0UCDauCGmbAkW1kc+hMntMgC0GtXR9xHEA0CbRexoBKf
AckAqgXHuNS+t2I6gy5bfES28SgLg3akT25LBPM+DfMLKEUXsC0I1QwGEFsYRefqexuUL/RF0wK9
hCscwtq2SlfUUMDFaXEBtchG1tQYdSyzxxDWwsQuo7iJSDBXqF8aRVG7GWBlRVfctVE+Jhi03PEB
8I0sO+pux2Uc8xBaXCtvuIaPiCXgXAiVeSq8qPSFvmJauHQvxAoi8QAd06gUqPEpiYCd8kPDgwNL
QttWn7m699RXxg4/EFa5hTCN9StlNWqilhxOzkxsUpQgUZG3zR1Up0b5lOT3FqN3tbLosHuLXhx8
wFn8SrFkWu7vieyEAV+ZQAny8ypW7OfELkM4OrHXMF5RwukD4hnE4QUjg9wyDT5mCvnhDPSmepyt
TS4jO02Xq5YR1zX5i8DyZ6lyqMnTmWwUMQZMsKUjDalqDsf+yskppoSAXkHBRA+JZjizG77Y6wbS
cTMUP3BHtAKVxER/CItC1xJYLa8vuNfB9RWWYRBd8Q5eH3FVeYyDgYgnaCIDF9mRQnBwNyMGxpir
jSxwEHMXbHEqDhoJzKagRDkuPHKrOXxLU0LuI+9KqOGcZPbTM5luYrgDSUSKz1c5MT/lxAYKgsHq
XWodrmCPAHrcjguaadVKVjOq2X/ELVQZ1F5DiZRqyu2VyXYc5Mp50SfNQ/uhTa9wt1SguWXLqLbw
uUCaNy46CsPBGyeFzmUDcUtX+QKTqz8MKw2q9sKhA5skXylt3/csEW7HMuCA0HqJh5XwRNMULXH/
AK5kuAsXjmIVivuL9gmFLigAkQu/uA84s6d/qJh8ReMh0qUbb64j4RGrKLmOtanqFCwOdbNpNysf
iL7Voo2+pdyILdzxGYgiX+YKwroG5VSkU42FnKSY8eI7vwBwHiIVYLZzk3iDDlccigsNXPNKXUC6
VpqqgvJRUnngjRrbQvwUCpSzAupYUS/cW2k5KtniXquo0zxxDbQ3uBVtFpAElXqBAqWHQEV8qs5+
5waVuVKpGmq4G6ZYqrfLO1XB6h3RqH0e46xUFgPTKz8ugEWun/8ALLM1N6n/AMRmw+g8fiAZlqNC
oV0HS/csS5yGaI7iVm6Jr8RBqMBUX2QQDCHILX8XG8c64CLDWxv5xDqSW6AwrP67O8kvM4IqqYIs
T06Vk59gfvmOHlKjhKCO9GmTx/wCO5hgYvqABy4ib5YGyl55SrX8TPjAgFgNWvkFr4j7ilUoHMZ6
QAuIdqQ0IAqgKw8PjYa9yp6oIcOIUbvDkN0TVUFIEVYD9R5iYQnYWDpZ/Us52Q0C7/TAPntqml2F
xID5VeQMMI5kGVQ18D/7HgVBVGHAzpcvck8ETm8MEeiM3hLVguiDQwbG2MAVQ2wBUFfxeRyoRoZq
DYa2zDglVBy7txclUPd85BOI7SBsU6r0zly8UiIFK6YNJerBwB7jY2r6A9AGxpyBNp/8h16KSw+W
/cO+JWEvqdHDTyW/zCFMIsC/8gEoA3p3KygwuQY0sOaqC1pHrme4zhUayMGvN9Rau7fEqGqthc7O
oJca7jop1yHspT1zLqn5QuUy5omNqiOzIKrN7Gq8QDbyNFGxL0Y4KdgtHgh7GXOATJZP3LPE5Bw3
EQWZKAaalFzUWjiWhrJajVHUq7TmLqJtfEVvlxUQ5ZTC2ZUcQGsZl3uI0vLBiVRzLA3xEFzbK6W2
PYEBuMJYcbrWC0m3Hat0iaVdPcvgV6javhhoNXUF1WDFEBa8sN8jNrhcKz3cuinDFxgUcqVbm1gX
OrgGbx4ljBey6azwQKI9cEbTeDuIpOSupTvi4LQbPUsKHXcXl1CXVbxEUoKGVFWjtlq1ZDWXKwLv
xCYgoiDkDxOKsyZqHzN4U8ENEKB17hbvTE7Bo/bGtF1ybBYYeTZe7WtbErOvUvsrOebRhZo+YU5F
74gjoo1UvOVVY1QV1supMDWS3p+YgVAgdbzF35Bv45lnizT1zAJwLk4wc4YQLQgAc5BbNiLF73KK
KfaK0/JKsLQ6gUBBX4RhUvYKzFo/CaFUg/UaOOmWsU54VjfAi/hEvRQHmHK+7oZm9RlPiAQvYPji
cWGNY7xYGpAJs46jGAFb2R9cIHxcbVSFTfWYBEWX5/8Akp2DQPmZn4tudkO8XVvgAj20q32L4lqo
7p/PUcMTjOjBQoNnE99wR1NDBsHCMl2lmcxTBfLKQWhbaUzqODkG91bKCNNmgehmxB1U3fTfxAga
0PKWwKqRbD91aDmKu9ePBKwWrkKzYAEIS1ZT9R0sGlp9RmOhf5iVDla3bubDPohEyAotfPxAmliI
cxasX9cI4AYgMLmSRge4BJXa/wA3CBcngqzYXKs+Udss8Mpq1gUQs7PoRU1APB9e5pK+Ty3MntJe
/uYbQEaJd5RT4q471Kt/bEoFgceIdM+XKuouILoqohrLNHxcNUtwoFZZfjYNjTZSKO+JoblWJFJW
pfj5hctkcYouMKi0RP8AIJoKKo/KCyVkBb9QGGNhrF3sALL5gigR9HuWqFO/Kv6hW2nYc9xWbS+E
MY2Y7Loft4gH6VdcV3LlwoX42Vog4Wm0dwWsbObIYPZ+4qvi5QtXsH2zcNNK8jsEfryrf+Yw3UeX
ETdov4Qg0IvzZFkGAKcN8xpfgF5eIywXz3SGNbSssbZd1EOUR0IBF3s/Mq3DBa1GMR3la0nyRsi1
UzNLm4JTCIcW7ErXxLqmL6ANB62S9WwvC9xvK+zl1gKtLDlcFWdwZRLHB/ZAtzVL+mKmK025f3Kd
IL6r5jpXKeLcIS5UIVl5BuNLpZMGya4Yx2Bt2cESwIG4G7GCNfpS7CnZGMV59S+YzXDEmiIsbAAX
RuMwT/bYLHxUA1Blzho7tUr4YjnQA2l/3LKxb+3+QKF0Hltgx1Y5uok5zVfPLLfHpjSxL94BGkef
mUoLkqnP/BLMwoNqTg/3qLzbHt+c/Mw/PF8I0uFq1hEQu4mvlH9lsrc6ylqtIkPDK1U/UEpOTv4g
KryjFbbPcAGiJp3N1ckW5pfMDdLXzAsar1ErizDf3GD7pj2vZg6QdgEKziWOOHUWnMV+Iq1tRP1K
j8IbXRSxFE2JOntg55il31LQ1+YUjbsSqq69RaMKGWUp3xA5NVGryJ9vcGR29l2KgC6ZZ8PfmWSm
FinHzFYXCIFGqg5Hm6hVQUSvqUd8fjuaV14mMtI2Dx6iLOupiPBsGGmywNN/EJOXPMoQ2pFIgELE
Iuq+4hXzkXd5hgUSNtGn7jQEolSg2BoSMpAojxoXALXcw6L3ULauRlliQEu9p1Bce58f5gChz3UQ
K+e4XbV9MQdUco7wyIpcrZgrFlgqPRDcB3b3DfQI8RUliHjWDE2AlOEXc+epiwCp6iB87ahKgXU7
iHG7qfr/ACW/c0eUpaXU+CMHrVXzEB8IvnuXcgtxeG6lNzRzPFQ9bK/BfEc3Z36lcAKK7jJS2zjm
UV/mHD1EBjpHfW/5llBR4is4uB2j7iinnzNw7iMSZL3P1BdjZvxn+S2iytP1LDKTyR3gsHddQJOl
LuFujbqaFotwuxb/AFDdwD0D7Rk7EDzGqFgl2VxEMl1nUo1XaKSG6PjvUA08KcXUZfWKW+IEloCO
XcOF2T8REDYj4Jw0Ay7gu1U0X1fqCuoad1AjKRYwSrCiviWfssuPcEQPYVK1hR7EQqbYGKTJStvn
iJcnFEr52VmFLDRjW1kTniABW7fnYBJAqv7i28NKqU9niOx3U8KR420opXM6obHtj4QWm0sPihp9
9wWNFTIaBp3q2UZ/ltR7pKi3lxTCgQnMU9qYcwj7UvwoiARX46gi2wduJQDMp3f/AGBIA2r2H1Cj
YNUS/JFjovm4NMXdSzXmIZrrw42MsCObojWTTnQqrnOCuDSzZcEo/wDlbKZZivLFyXIV1C9yAQg6
qiz6IA3mV8lxWpzmFAwsZEbPPaUwJrlCCYVa/Er3RTOY10XUCq1gcyVbjTyEmNbfEOFyAcWQJYug
W3GcEcXlqBR8V9v9jZJqsKHxAF1YPl4i41qrT4gFTNeb5ic1NHxbD8It9PEVEYVcKDCF0t/G2AXa
rLB5lMeTnOY2XMJei+YqENA2tI9ukGmnENEFld7Kicv/AIKgRco/xF1CtO+X+pTyuJMWUM3xe8Ai
FzEu3LEQhNxPpSdw6hE1jLjgAJTsPM5T3fQ4BOQCrgQIu8GuIS24N8NlXKH5b8sgYO3b4CMs4ZV3
wCEGUODxrF7jA+MC1nCq4bcpYOwTkrRvbf8Ase8E8jyC/wBlQqkcHWQt4ArVj61lVSywUUPM2LZL
1vMspoJRdLBhPQVYIqALawF37mtW0/hcufzfI+Q2B/dpnJex+uhUcr4icBcPV9KxNC8tWyo6tKro
rSUUKitzzWu64IvMLnT5lCJRWtJ3FB8xAULx+ZoAaylh48xpJ6tarKv9zXcV7+iKJgOQgUn4uKZg
CulcfuMWWJBrhrGPKb01xdBxMhPVlPzFh85PLCJpt4bb5uU7jGLMz/5HWCtHg9s2n8SiwljCkoyO
LUmwsbF5YrT4joJ9wwFcTCgURNW4LUuYNpieBcTvHeC0wkc4qGNaXdRELBjRuC1tRtm9ja01UoG0
Qg1ZEK8Q0KJ6hu5XpHgVxClrqXYq4aYRIIccwaWIFXUBGIEF9DcoC3PiX7xKMZoOQEIajwrkgh6Z
pOZ1CnQcxaOMdTOIXIFU5YRrwx2jydwrKg2heP3AtzBf0l7sSI6Le5VKcpenTLqDz3UMAJZRWvEs
TmCvxEQPnYYp29uNq8PEVsjQyps3AGWQbrXMx6o5qPXD5jrBRd3KBdBWCqLULo2X6IIyz1Lw4duE
oc8e4Pt4+IzQxq4UmtjaLuCpqu51mwKpuzxBqyjpgZrj9poSDbB8w/IPzVC0021Jk4VELz5l1aGm
ACBZd5GKqKSlfzM/UK6yJKOduVEq0PErSXQqDqcTA3XxxFYA2QTxirhT+42KEKiHh6iGrd9S2iov
xH+GKXzzLSy1FJ2dpLV2dQUAiGe6yI3kMtENWzsr5iyzSwCoa/rtB2KkcHA4ghegDar5IB7UDv8A
DsvL8KCgYdUFHwwXXDVIwO1Z4Cbt0x8QDKbslmVN2wOTYMgjiBnHl3r+UThSvHYEK3VqkRo7FOHx
LWC2nVvUQYnnhsmn9NC/udoIBYM3JbFQjW1o8RED50+mUa7pkuXq2YOEPYyMTYpTNFQ2ernBbocN
SmcFo5tg8G8mVNRI05JTUhFQJHd2FOJNq7cgY3XlWzZbSFgdLh3yG5Y1sMPuOIlO4ogdLG33ONs2
xjXzF0CBC4BFEHEFJ6rFEOXq4L/U5IBG87bcuIOYNuqiqxssHSb6AQ4jF6q3BvxzECqeBCfzOBuA
cPvmdkkLi3uNysYR38wXdylqU1WveDxGNpuqlEvti3bi8GL8kH8xhYvM7aWG+OogIzopYrY0gqHV
1xEQlDzQ3ohqxuU6tOxG8nopzHyU9doXAp6YgdFeiqgElVgPUB9MNmTZ6halPl6iVC3Sdpi6lrk1
MlWWNXWSkAEXtuCVDnWAX6lkqOOYxIZVyn+JSwP4AN/bCBpQ5Vq4l7RAGsO5Urc2W3LH2pcGU+L/
AKxLMbDPEGqrs6LPwS/qaGllx54MSU9S8pxXyVzcwQTu0fPMM+fQh81fNS9YId+QROuqKNPjY2ar
n8hcqYCm/hX9xSs1w3j1BRQKNf0mv09ZPlpEEWQroCTsscUL7hzaISD8wlJUI/5jIFUle/5mUwUJ
xbf9wAgQpevPcX7IipzqpUMwXtc4uJkdiN08x+KYojHJGbvTxDxEy2y7B6modOCKpPg5UPAozYfq
XiYS9a+ILSlmKty8ANOBfP3Db3eFpdbgSy2bH6ggzWjWvmL+wGKWQKhtlPl9wX9gF2n15lnNAWnl
jsRXcW8I85TpIQ2ziZquhZHfrYh1tu/XMvTquLncBDegl5fuILxaFtL6hOqcGn9k2IFX2fxDPgOC
PxsVluLPiEciDF07blGeqjJOMltETKMhCUpOaJSwf+Il1xEN1p6lpxsamtl49HcYVG86iKsmZuDl
3GtnNkUllxgafEEmZFBQ7jyuxUF48QK0LI9yiGW6ljTh5hy2yFveQHHbIcJwS1ZwTQD8T86dVxaE
qzzCoweHcCqdk5BQnMduGyyJeSjpk0ZESPUQkFqn9Q0rN+JwxrSgB/MuYGCFHbiqZF4doALJwJUv
mosV1eMqW7fmEK2vUBcwmG4vqNNtYNQS75jZrt5uBC72CF4ZSLPiMBhigDwyha66jGz54mUlV4nV
lEeztcH2ZBLFIkMTYu+RuxiKq/bKULbGxdj7lDxusnqItqn3Nx4ngKcgFwEibUa8MYdbXU0I3ncA
RrudN+nmBFc+CNwA0A+Yn6lbiWbZjvQCL7qUCVp+q83BTeFFwx34HJDjUOnaNAE7pJtAN9GOgHxv
E51T8L9wQH8sX7N68svZPVNncHmANFkEqSmHfEY28le6IKX0mJr21MBOICiuXqVAYlIJZhniGmA5
ikZL+yhlqYFNlv8AM6Qb5i4rb+YdpRwVUVtVeSuOh1RUZFXNhIcEO3XcvQTy5e6R2rcTKV5RSQDO
Gakb/aU3NeAZTgjTxUqRIoHGNqhNOnAu4JR7MsMxdlyFFdWVDDGNWlrM0A0U2GDX7VyLVzBmalfx
YRKye3ImoRxaqwIFa7h3g/L9RxajSsUWA0OwivuOS6Ydo1CSPEScV1Pf7mNdLXdS7BHOQuxaKxj4
qLUWIBs0cmbbG5G+b0OY4eQ4YhxW6xF85t4I9QehX1NnA1UFL6Th4QEKXVPMbwC8SpehQVBHxfcU
eTRXKZNrxuMvdqbRkgV04Iu1wpL2CUh5xUcAcd+YWNLVRwDRe9Pm5fFUwP1KDtxZxHddRDV7VQYI
FJwEAmSnjf7LQL5IS9RAYFcQVipyPCLgMvUr8R6lYwEouB5dfVsVDSPdcziz+IgSd3IDdFS7U45Y
XFKwfZAYPihMIuIar3CMks0ehs4+eHz/AHH28bASpr3oBxvmHC28P+I0UXDr/CbACt5N/Ev/AOnL
55i0+40uvLAAQaFOSG6hDMCLyyzURvqOUsigCrtj8f5IeSzSiF2GCuBhDnubdRvRbL8fzHVoMyUZ
Vu+mCmzbuX/UWtzZfMaQuuYOGovg9VM2ABwH4iR/qBoXxG6Ct3jHgtSEvuXbxLsBvi4WRKw/ucki
9ShXx1GNqFcvUs0Xkweth3cJmll21+adQRm2PVdeJW/Kc37jzyINt/MNJRqmBmVXBFAKo7qEBCNF
EeGxFtgbzJON+KjPl61V+yM1g3W9zl6ePER2AqwSAutxwHbDAkOlv6h5cbSA/iOTYoIJhOdEVeF8
3DCAUNRUNS4FHUUui+RiFLKg2uXFHcL9oWxecxxrbHVZXUrSJKVKoo7FKvj3LoKZ3AKobEYgSfqi
smyyHEsc/MrSOcwq9sW6jbaQXLK6iyxg6VEoE+ydZw5hXRj6g5KljEsbhUDLiljSooX2iJmviIVf
mO+SPq24ihCHKLVdMYmOy229GC8FRU4XUKnogLGhABSAjxFcOJwAtQbrrI9yLKlLlCr3zLifyQqW
RT+XmMNK5wQIF3cJgVXMQR/oRNwXb+INDh6lR9fE4NtuWvO10Sqcb5gKQsLNjsPCZEC/EQ0rT6hQ
ULIlSM7Zc54gX7MRDqpYD+pdRMUKm3NXqw5lSpmrfLLeGCappy5ZKrdZMKbQxBpteoyl41F0wWEr
OTlSg4ekZ8H0Q+G3xGTABdS1LsdmcTYI6eBcf4EKrnIqUqoacwqJgbXqIkhWKHED40Ui6QJG3ZqE
ZuHIoCxvhG7FIsSoMVrCBabzUGr8QWLsGLqLy6tecRUngg7ZFc0R2Jg4lY3uNolFDuLZNaCnzAKV
PuM1R9zmFwrkh2aoLwtRsB1b3BFV6KVLPLsRSao16hZgmhhBIVAEF5LkwdrMOCZBFsEPRmGurgca
l29IOwgsQ5l9Ue1vMuGB+hPeLSbUJma/nZUrU3gIM1HQ4hIJWukOu7sIvC7oSCg02aPyh0mNOGEG
uoGLimgloqoikCKEQvR5AjtIfcv5KDI7+54PkRro4jbJz3jBxAwYKL7+YkvLbBdSztXK5ETjutag
BVSvGETwOnMEJLb6dxvjy6u3m4OFDX5itPLXayV10gAK+LlpgQVu+4Bk9AvmBjZPFC/zOP30K2yU
0Bosp+ZSUFUQH2wQhdlh+ch34wDkBg5YNLFt6mxZ7Cq8QzSNTFdQXAhU1X3E02SzZa3boQncLApf
dRcEUqoMYgtDB7O0vuebQ4IFeBcnxCnJB71/yNNDtQDRc9xEcrCDUciivqHU/E5RKYHK5lSwp4i1
aqAwY3W5wNgPy9WnE8q46qOo1XCtfErjOanEFi/MNEnaC+fEGA95m3EqjO2yy5V2DG4hQS1b6fmK
BeVqKu521EKyqy7Qfar2hu1QPSFKUKqrh3Ei0l+pojKGQTkkeWpdlwYC9rIaqtv4lEBsRb8Rasww
NxiLSpm9oroe2ClLXbnK+Y6w7Q6Opc3wEYHlltRDtRcaMA4eUD1AluIwC3Jy/ibbvCz4QARNayAJ
boeYBJCgOiWVbuE5iXQBZpej5hliY8N+KlgqyjySy46ueUK3IfKmwxAygfoLhzVeod9x/WcC6o/7
CO152UfiG3AH5DUardGXa+408dDc/Etc7C0q/qDslDe5kjYLEr4zZNvuJgYsXT4+4G4FB7d8SoZx
wUE/ZAVBOhYG1UCLCavPLnOHwtktLuKeVldxTYDC29PEqUcCLB+IAxRlvQ8xXwaOgLVhpl3HV1TK
roUcF/8AZr4dL4ZRnQyUOkA0lspKPCYPXzHje3CmjiEHiE6FZ/8AgBDZvcV/MPJF8E1v6iFnB1LI
LbKiu4Jt2ZKW87FGgxQVVXywfUQRkdqcSteUNXVxbFZCiu/JGqxkKLyxOJlH6lAxsosKfMW+HmDy
uANOssWvdSzqclWBLFlX3BxaVzLEBGDaeph5tYw08MJBXManl+I5sC+4abUWoH2QE2o3S62IiuIA
Rc8TPtnkiAmxD0riC8KDzDttHE4CxKIKAgmwtgRgr1E1bqHRPuDehty1P6my+Y6kdiDeVHVOoDau
4+1dyguL5gbW/EXgRcq0eojfvMtL8QFy7Ujd85y5XkhKMt8EUvblJB0oN3XaWUueYipV9WSq+Uvm
MQqqgU1zxLn6oC+rdUw9xI3ndkajsA9DqNQatdlw2ZVi/URc+0YStFC8eiJihbWElQCpy5EvUHXk
jiKoreYARLHzNw8Iczgy0P4/2Xmbp7L4iFr6b6lbSbLihlKDBVXPcO6DCOW9xFpdbL0MqFyxUOhL
5Xkvmb7isFSrUKf3C4XBGea+jhhuaUpoOjTwjbAjC63mIwVcS7l0VNfwhFDuOAuORDwubjzIilPU
PbUkWEW1/wCWLh849hHdxOnTEq7qASei1r4gvLBdQDJHwYBuLfvqIrC0DnmGmsukrjY38U1XUq7N
y2OAVivCx8VBRZFUMavT7yWFHoK6RQRlabETqOLItDJlpChEvsbConQ8BEIW2xbZ3bw7luzjtqpT
IuFj1Hw74qPuLVG1F9sk8Q4OwPyMKRzmhfuENwIvYogOTWFXS8DdxYTXYXb5gRUN2qv9iv3sPdDV
UaG4dQHUqq6P1L+yYeCWevXTEDDEenZ+45ecGirsq3kd3n8Q6QaHSICoC/uJ7jRS8j/XtfaJJx0K
zAEj4BGoiLtp5jm5u9eO4CqVdoVxxAMLSid+pRgBsag4ill83bPGfSbRW/iDXUA7LlL1ojdPqEFd
wFMUxn0dzLKxFZYFjFH9RMPKwCfceobYKHESuG7NhGbVqzgY9MX6ut5lJDBuKKgB7iDOCmpcJz6t
a9riKNOhQ/MO6yXG+IZZa7LfUsWqPwjc0WAHDzLGylpSL/yB1yx2ESkwNBSFppSxHpgCtVgK9sE0
0bWfX/ZVb2EL63mJvy68QVy13VTnVwaIJx4RbOFg59pUMX9SmkivIkMcJS7GcyrmiTay7uBskpRp
bq2P6rTD5hs2WxaSnOfpOyJUVrNd0zhiHIKmc3LU14p3VwpRgTtVk43OIZnMIL1uwHFEKg0A5VxH
TOrvolXoZH1ZKOGETwBLMmGlHauU7co38KlIO4QXDLlyLdAXxLlTpefHVxOJdtA8cQ3ERKMKbUoS
mtd+LmkjFJffDDLXgA0U7jZBgeAWXJUd5fKRGJiffonC7V7lihbLJ3zOEtFOGMnI0ViPUp50RWHR
+pwAOgo8w1VCRnydxE5pWb3v9wSGNeA5D1cuYF861zfGwhLTvhJT/wALvF6wLKhd+BhpiHbfniIG
0W/1OdG62KSuMQDpMFcSkr+BMgePEAWdIHi2QLQsDfESlG7gNXOAbIF3PVS4IRgFluoBYhW72+Ig
FJbLkOFKBAHlZBRB2Glq7R4Vlg9ww9MMeZeXPmfkMeMha5TOQIoqgYtTFR9Sk80tleWJa3XiOUbL
NFo6gtKzmN22AOohds9QClNEqU7BAEUE4WVAOygKluTruC3VEsBVRRSGi5ZBqyKwuiWQquZ6h5yI
QKUitsBySzLW8Q3TUWfbmc1urLlxdsqlu+JbVLPE6jGWODOCWy+OfUw0HfUaHlLC2wgiC2S7mUdy
wNyDRpNs7i15VsahNuc+BU1U8eZXuWmleGHd0WVzFPGeYogUYap3p8zjasyotFHJeUF8GNFeLiuJ
Q0ziyWbhfumxE/ZPYkXetbE8w5tB/MMC+aEDXQgTp9JHuwT9TbuwoRowW0zNuWuYhBbT/wC8yonB
K+a/yXauQp8xt2qo3xcuOAkIoG6jtFkIVVRu3MnAnI9MsR+pYNbYKBTVdQ5bIFfFcR4ppHanA1bK
rHHPdMeHUEa45D7mUnR1T1Fx1p52pU+1Q4QMIEfreZeA3R4Z4k8xAY1qd7cDOaMO7yUzoP4I7lxL
fDcruHpHf/qhWY4nzzGMZrrxF2RzgSzrJpDutmUI9lYRYq03E5l221A3iOJubDuKLoH3AbOick6r
7AfzO8EuBt4hggCc8yw4InblAV0vrV7ClAAKYrQAzqzddbv8RP5QB1V1Lpr6AZOG9BxfEFnLArvJ
RONhnrYM2MPwwbdV11fcPLsJfiDVRcvzuzwokJ7g/wBn0ov01YeD1POzc0nmKTYCHBx3DypCacgX
AD8edlVOJEz0yxLoUOhwSxbYflKSUUPjKIzyppfmP80wdNsU21QbUvcLlvS+pTbrh6NQ2TiA9yvZ
QM7LgsBErhc5ZYfspfER3V3ZGA83VHWHw3yx0a5jOWe5U+QzsgSA5YvgNK8pR0xa5VwLTFFl6NNZ
CCbvxFSDQinu4Q9J1XzLFLSE+Zc/RKerZn7tbEtBI2xzo8lwBQmzkfMQPoPKBDoCpV9RnlOz6ivT
SpFTUc23gCd8n8Syu5DrhuEhaxC5EEfGEKLmM1EC91ZCneufwRjF0A65Y9tILrykGJw3Hkg1XdMP
LSwB+RjtxZfH4jsKVpB4j7nK5WHmdoW2F+vK6Iblqt36B/UPSrBaWpjbYJTgS/PGqIQo9/xRhiQX
hOFQGArJ+Ji/OKbKv5g+jxsvi0r9SgpsIrv/AGMJd991sVpFpXi4PQP8E2D/AASuOTDEoxd6FX+4
xgRcFPFwySKKh5uWPVUYo+bjJgBUW76ljEBVZxUqLJ2prtXK4wqbkf7HGtQHvYGYZ238/Eb5IA2q
sB3GUC7elvBg0BjPCMa/a6LzT9R1SmY2X3seJ104LrqNjwfLaupS/ajGEb6hBZpp74hOSurwPP8A
EGMlc0tQT45lwe7A21Y4g8Osb7nGAAwcm/iJ0EBxdw1yGDumV12+Klhrhe50NRtfpEYGywe/coF4
kbWczAeDBAb5mYX3F8O3UaC2kSbVfMRw6h0msAacMvRI1rc3mLfIW65g2+zuATUAKsBsqr7gM8kt
DlpmHzDYcSlmJ+ZAAtVcwcPJH1xgnSKquQ4is3jLmJycyoV3LWzGJygpBhABViGl99R5rr3DdFQu
yVVqxyGDWrhH+0xc2BFpnEQAupVN7kpesdH6lB3WOH2RtfuagyFg/kQAr7iLG87IcI3AWiWwlf5L
dcSoBcfUDtqyNIhZKVXDmmNlpu/MCG6vxDhefMpjCdxbP0IqqYKebGKjArzL8vwgU8L7g2yrVAAo
VyMCmT4I8LZ8pS2294qUlKQJytQHglqAsNv3CeXgli2j0TkNMvy3eIwwHwzgLZ3C6LIWrM/yE2vm
9pNZ+rzMbZLhlMlavUH1WJXFykopeedlUEuin1EFSo9IsEummZV1cRAPgHqz/IpKw0wwBuJ0lxIw
GF9cxY8ikYLry+YW6nPBOKD7hpBNc4lQ3JRQl3Fpq85+JoPEONwRGeLyBR4SjQMj5ai0bYOpWgHb
awZdiWrh4hUBWXU8zZ0Cyo1FIvu7hczttjRYZCAcvXcQh2jrf+wyKwLMR/LGvuFvBfT43/YXCCgN
9Q0YnAnPMYFxBfuPRA5HGQJCxFPLDHPadPUFiAhcPzD0Bh5uVieZ4OAN1HdPi2VBwoIgaw+yrEep
gi4Okc9wUJfEdHSzpFmartgJX6O9yS681NvLL04K54IKJAGjghRXKPHMpHfzkruuwQX0RY4S5+WD
NYspiThtoPwSmvSquOZViUE72U0FnUshhRruFAa3Cj4ZR7FPhYQs7ty1wVF8mCD0OR0qpd/EFVxP
KpVnRRjzCCqd08xq0twurAwHUAtrw7iMLbWj9srdmxpkxEwQcLh4vCQunLCUKUdhW+2tfNrFbmtk
aivAEBtGBFg7P7liBfvYQxVQHrEyWjc9aPh4lxzyKEV43qn3OsDTbp5hBRRzUtSir8ykD4GR7YDN
ZYnmPNlUNfglj8UN0eM4ganQCsLDt5hLaCtkBiGFIaqGSO8WMkUeD6lKACIH13Ao12sN+SJEZQBR
W/MDyGwC7tl1ArmhrjN9xKhguhx0/qKJgt8e5rQJK2S8cSpRKdRaoHVar/0hlRm6TSXvxQgcOSaZ
YEJUzw3idHGwUfmX5E1HwCEFFcoLr+IBcAixWRMSDhsfKx+t14VZxcbKAS+L8y3ha2b+Y+tdq2V4
I9U/oQrYFUC+omY6I3XnEaSCTyMQnVtt+kBsEbOWCyIjaAD56i+iKJofAnUa3sIZ0p66JkksLS1h
xeBbo5XxMwrIAnNpCrjaKOK+5RNgjQ8RFstfiAzTCQ4V+Y2jNua868y/5eQP6jwDDnEObhUQALmx
14lq9ry2OCEldXaBA5IqHzE9eINR4l2kD4hxfQcwQgCxll12L0X9LH9VFp8uwLFNwxuASfJyPTKA
Bsv/AJKUAKE/L+YrdAB5i6sVv3Pl67lFQ6Mp/uL8im8+B5ipChyvK+WKgGOY7D7luIiGNyjS3Ewz
jzFuwshs1vURd66nocTFRz1MD1KUKN4jK8iAf3EcUbjCzqFEEqvDqXaitMiDJhFY4gNKKChfM4Jl
O3EjP3E1jEO0uW/NxDrw9EDy7yMFD7nfdjuzrxGr9TbrJbp2WppK7WT1Dpv6lH2ZwC38StO0U0cx
qHHiG9M3I5LzUK58RXtZB/UbqYgBTb5IDYcErRy4FshkLN8WQ7b5gm3dXrKorY5iUMaqiU8jcbvi
G7VzBTTEFRyQWt5viCilDzsWaExeaiAv4gMqaHE5VMeJgNfiOxRN5iWsSLbbtRazR6lIscOo1XzI
qu9dw5AUIosqt2fJDb7LlSrd8RhPHMoKB1HRRnLGmwVO47ilra8Rbq3TsrXm7jBKGJm5gWLsIgYA
LjkbIulS3fzA3QFc+ooxyFLUoivG11X4nhQFYBd59wR/iBJ5EgLERKrN2dOA1BxNhLl7BXBqwqKe
s2ox3v8A2Bo1V9x2hwrljlasMj5bPiVqO5dtnzCxe/ESoyBVEzzP8EF3D6m5CFcQnFw9h/8AJdjD
HCVQptrAy1txcPs3/UBHeWL75gJZsvHMq0Dg0P7lJaK3D+YZJbGnNbUCggwDO+YNMLkV/cx5tbeo
a0NUMH5jowTS3/KayDsKqZfKlQ9yRReH9x0HFVqpdBrdXmD6IVu/uL7eKkr42O5SNPGzdKGNXcXU
Htqn8xX5e3XuIImbbfpD+Sif9QZQO2D5inM8izFR2FkSQTRtR+I3dVq4Y1b44/0h2JKC5cTQitaF
wCqe142IU6TIfqed/YuQdSWKsPslQDyqU/qLc7JzUZVkiJkFOyi0CWgTdNcS1Xru5CxIy7bPmN1p
oUz3tjvYNdJQbZGAL1ReRg/A20SAApWHEsK7lFkavgWHD8wAEudXBRcCi1vzLizbQQiGMOSvlCgD
co/3FlbRAiujf31GcSUUX47iorOQfzGC1doj4sHmF+vq5UrcbMeDXpn1BwHtBYvrZlwtaSkR48Sy
tb8DB+I1DH5pSNehvuMysj2dS5maeRfnxBiC/LT3FUFVuLMx9IfzD3UcV8epYWDYbPhMVTgKqO07
g/4S37bp4MKToNvibWNo8R8VlD/IQqMqBZ3/ABC4KqHCeJeOrY9PqITeKyjXiGDFr9s3R8GeAgQP
CHjxwQXfMe1/qNzcExdYRSBRVf7jgW3GxL7pytGHhPvuN7iqK1FnSxo7mF0iQ1WyqU+uYhWPJAxH
QnaWA9ywoDfCiP39gqFXioq/Ko/mULthYn4lZ0hGYtERH5lAE2cIfcWbFrXVYigBVKB9Rj3StrLD
pysJYj51rzcQKlhROYF3OzK+YiPRVtv5gIozEgQBaluLxq3PLH8pmOcg4+4UqjAaSAbp5SVcV7Qa
gr6lKQOFwltqytWVepUri1puVV/MN1vtQ/UElt94/mYKFKR6PFQyvA2Dnm49wDzzEU1OokHDZVC9
Rx1pxv8AfccJaeIcSGWtHuWAh4bBxtljgsMi9hHBwHJZB9tlRY9q4cGG9l5ZfMAobBKLvFC2DaiD
hv1B0eWIDSm5QxYt914nAYA3g+4Eep1+I8DnjIulq3+JX7tiFJqOTeeJci1nmLY8k7iLePUYoDUF
KxVHbuBXvYi6Zk5YvuFtgWIGtv1Holw3rkDxyMWI4fMDjQ5gRb7Zyxpr1LxXESiorEaPDAjcqc88
wFLWGQB244lzq96hqpd33HaLrzCnC4Z3dQAtmxKV33kDybYl9/MCgvR4ihVkWBbvuJFaZS003F/P
xG6W2+IGz6gtlxR1cAaJZ8WwAo09wGhdjLwJUQ28itC7RAOReC9qZXxXP/4OVnJUeW3iqlgG72gm
ei4cFjxpSHDIaEcvhjKBFuCdwcIHHJWS/Bp9EGKT3CxrcTISeQAndxBCOwcERblvbzBBIqwCJqy8
HcEagY9I7C1YKRONqUkfkJu659RKu0sVMLiY1ceQXq2WgT5gouE6grLvgiSgoYES92sipXiQuirY
0SsY2tELsuPcppczlK/Maj1wljpwn3HLCxIHRNwKUlGJTjzF5dBVw1YBokEK3WFbYKGKBT4BH4jg
dMHyrb4pQVRphDWUP2uM9RLbKhnAOeU4KDAJBjQ54wqxxryjQi5VCGlyyurR4LiOxYWulCWfxEZl
zwx9tNuDhqMjW0sSsfCLVjmNQSkNMZjFq+P3AxjpCKMgu4KRKGUlhWDlIctbY6AfMccZ5GV+eGS5
otWWE4Ihc3HiGc4h0Zw04qtEJX3SwfxOPpxAL9QVQ6fD1GsB8gcx2A2XQqLbS1AksmhFKwvbImvs
BK6h2S00F+paKs6oqNGq33EdrDYj+CUlLyojYOlldWKy0+DiW5xXhFgfOCGeSnTcNq3on5l+LKQg
u0pVdxvQZXq8lB0gmfeoJKxBfIZaSopVcpHoHqrcuDXUDmV19u6fMQ3WKWTBIIOGWlr2GW+KgAp1
QtXXC3EZw24RWWzm6d4k17qNl+tFlB5hlVV0BscsctPUycejALRJYExBEFnRBfz7qbAs6Yrnp6Y6
KAPUcbOiUkJ2AdkuVCkNsgdpri1n7jZwdLnIeCRgU1m3yiGgo+pg2W3UaWdbVbH12FKhVXwqFVuT
MVdjgLrPqOvcDhFqBVJZAZ9qgigbSYVxHyU4WVF5CzJaEsavqasWIlFUaGo1BjSs1xnMZoKZgUod
RlvhzfmBVhxtmU0yqFzU1Id6z0nBWgflm8ryFQUiou5Dro1bWXcH8G8/ZYggW2/4cymXsOS/LHS8
NTFh9g1it8XcPHHWW5WgWJWczmIHiKOzJGiYANh3TyOfd8woUC1npUJRF01ba+SECj9SxUn1LfQ0
gW8ynUXRLsK6l4ioPOL5+4gqPc1BS7Vjgg8Uj0m1d0e47ucdLjuou4TwMrhWqHIRuWFsBMV2HXiW
I7VODoLKVmXBAoRAI1MO6VFZtMHS4pf+QepgxUVD7lmlPi5o3QsFIAabrqUpmVLLYuJ2amyg3ajo
kM6jgN7zLWeCaU91AoTJgiLd1UIKvmBS4NINQAeVU3LLTfEoi8xU4G5MShncs3lfERNuRA+DiWvM
6eO5tQsLjhRtjq8LBCLw9w9ojFkFt7EYeYpYduK2LFqiGgvn9QoVRTsiotGuJ8COPnuWFltVUQAp
bEGCslFXzA4WFDnD3FfLnzCtYLiHqiUQhg6xRGhu4h3rARLP6gh0PNywjYZfjFOwyw28RbDfMpQ4
fxKdLD5lmuRw31BX1eVkobQBLiPVTQ7u5o5VlqCKUK8sirYAAEqAWcF5u4SJh0SuCrTiM2xs04uI
xhcBG/mEwPYgMIWcVApyoQ0ghGvaI6sz/GEjsCu3cbKAUpIBAA2SKVKpbJUjG+4kHfmDofxArZm9
wbGsouJbLouNwx2i7BCrIols+YNJ+IIjpfKDzMgaZGXtYEaqOWiWmNKeqAnY/Ff3GjpU6YIGnXap
4M7Spdog75gmklLhBh7YrBwgKaVF8MMAvBjOZTRpPKZSBSkDukp2LhyzQoTwQWGC0m1g8cqFYsqR
h4l9ZPGEgdhOCcLCgG0SMsGlkZsvH8kX5Sujk8kEJK7scbMsyDw0CfMIroBwprr5hBarUxcjLXPq
WSqrlTK0G1aGty76gNVZFMYrB3NmmR/uKYI3nDVxKC1fE3G70b6lPBsQPcPuKzkLr3CkCqlAL1UQ
vGm+Jyqk2QyV4qg/mJRDBYBW8w2VA6PzCIq7Mz6hi/EbB7UKBxIZrlQ4PzBzMii1V/5B8B5fbKFA
0fwmcxArFC+4KpDr4atlaJFup1CI0DbuXgeghL2xSASsXvhzNPkh2C8TIYhdHuPgMhP2pdOriEBW
5PsqYD3I/rUr33JWB4ZSZAi1+YBRzKBf1EEIPREqWJwO9uY74Abb5l8nlscTg7DlZ6jqcmry6iXC
CbMjuplcyMnqvDgj8CZZoiNFtrvwWJ3TjGvAxRolYc6qvtOxaYzf7lzKHReau0gKTXuKvi0I60rm
pSw0cTDEFDoix8BlRl8Q7EN5l+Y0LYALPQ9xIukw0f4lCAHxIIgKjoe8i+AQwCVwVFp9Ea9QD8UY
LlJ5wilIpnU0dHiEZQ4nwh0IHQbLzDUrVeoXvggAmbQDp03nzFQmAcXvAx8EN4FhBYXlB8GBHl9B
FXUrQclW0KlkQrqdGVMt/ZGPIobekqCQBJRfaZIoGqo5S8l0PIQ6fMK1+ZZ9yADC1/mW1q8kpDdc
O8B5Dti9ljgUG4LEmTvoVLfYS6Bt+ouBYT6UfuGvutzV88RJ8BssXwVLVrBcs12XdmkNy3+pb82D
D5gIhq6LO2UMJ5WdsCO/dg8w7Ed7uvULhGQ5EcvqIYfS5PdMESZUKHvYm2vELDW+4zKJ9UrcSiC7
G8wTtoHsM0eDR9o3VzoYSxoLBb2Qxg49wdRcJop11H+KLdjzLy+lNQpnLb00dbNMXRMe4yK4qCaQ
t7BBXEsaLPU0J7jWtxCydpjwagF6u4o7axqzHxNMdoioi5zCO0Kl34GJByaRBJfmAAqmAA3R4jUo
Opgur3icAcMqCvxC0dBKaXoi211zF6YeZQ0cRs24Vzz2TpFvuGumxWCFQUWMV11uOhlsC/6T72K8
mCVECN8xZSc9kNuLqBOX6hcDseVnMQCoDZZLXfE7PBMXeujuUxqjuVanTogV7N4lVBBrHfFRgE/E
MKRausapRZ4hVNzs8TCujtC4NsXGFDnnqAGuFgJZRc0BjhQC2+4ry8ZUuG6dSyO3hAhCeEN9nI8t
oHETQN3yiBXrJ5kTfUAulfzBqbgi5sL66/iIHhSCGIXfAx74AJZVy6uiJrjmK8U3E1RFDzjNEaD+
WHl1U6YloOh/96h9Nww+udqAbf8AymXoU2B75incCb4uVaq+pzDC9Mb5G4Q70g6XTxF5HEvtydSA
3dxeVuUU/SDSoZ03L0rXKgGC/iAk6hfklY2EbifA9Nu4wmlLnGw8VZ/XmHaspaVFuS2euYL0yAHi
iVTC3PTGTFRtBVgCxtq9irgrL7uUMqiVbzLoqL3YZMaD4rJWWWqGUFLEP+Iwa0VfmDqy0nVynQKK
9bK2QWro4gCJwuNepRuBHqPlK0Z77ixumhFmdwae0fLeIBpF3OguXLJRKkEsCAbrcIdNbSxvqfGa
kYtdd/5EFR4RwX0xaJDBwAOPBlmsFBOUdzHeBbPcLg9cyr9wOcx1TETvCHS50ZSxrCHqEWdjwRju
EO8cHupZQbWwd4jwABKDtb6g56tcKrj0RFI7jDkip/R4ib4PceDqOl4+YcAS5h9wvpvdYaqz6i12
EB54jgafzRAKWB/l9eIgoSW6viLhUpV6PTOgMQcXVMeWWgnGZcMhGivtFS0lENdP9kokL5B4djbD
/soCmRi1yPGk6ZsfqXd9PhgMWhPYkOKbrm1EW39wNbLD0kGXbB8wKqXoZtRRqboL+yiDiIAeZ9IU
V3Y17uCyp6+xIxtG1sUmCSr5qC3Xa6Nf8jLW+w+42oDdByXJz86TY/E8tW9zkNAoKrIwrSxwD1c5
bXpHPEPscpuPfiPVQDasvv6iubUX2iG3S6bd1jK7iBSioOhMg9eoYDPH95FIBBEVOFIIw4ULI6QG
dr6l4FA7vMZiraUbfFxLADzF7OcHRfvPcMmJZ1zVD9yg2vtiTcDj1GhUukxQjSc3rHpqFQHM14gs
z0AtIXedSkIg1pcpzGlShSi82LocAWq4puVwcLmU8X5gfnxjZhM0OcKhDVQ4KMgkw0+ceZ9XtNcQ
Zbf9lRiehfLt09mQjo1BVAX/AFN2yr0V4+pinpuDfbL2S0BT/wC4h4jezXdeV8wIkd7F9suC6Fda
/cuLxORXF9BFOoVtcXiMwJ7fnLcS3xsUrAf31FLrYvChXuUVhPTIWpBw1ncoR6scUQPgFLoT/ZXV
cPS/6iJPysVOPVwlApnWXCqAMUV3Gga0IVBraWXof7iwPMgR6OYT42U8ix+4jLRFOiyPEW7PPX7Y
2zAK0q7IDlD4JdbKAtpoYa5ZApPMWCyiJSzmYFkAziFlDcwizwSo+AuFsxOVP6naXsABy2WCrW8S
yFag+XT1C7O/JMQKqeYC14ne+cw3uohUPORE33dUwQY3PY+u5syA0eu4PgQK0ZynEAiUjqVXyXqU
oCiBHnZdssuPe4IXVBdRV8/TCuDF4jpaji/MRltVDNkvnlsSwQFzz3EFX7//ACFgvETS3MLhfPiE
r+ZyPN9QNOGNjmy9U/cXOTux6VHmOlgScCrLgJXJjVSW+pYHY+eosG87YZZEapuR1ehO4rGPqOi3
N8k526ZG6Vbzfc46LYJNmXPQRrKWwJOriC52jl9RtieBzMO3Q4Zo2m7qIGuGy1a6BETykRAuvct3
oA/k/uFgFTF0rv5XMEOtI6CUKh1NEhFBlUoxFfudnsPzKhw1CAImcTv/AMx4FX39RbQykaqbjor+
P+yxonIf+9xQyt/DsfK3T8MRxu7e3ZxtkHZKuIUV1zBJ5eIqxVRAUjteZdNlnQxXbj1MOpzYyNSS
aJi34I72FPslB2y8+YSFQI8V3+IUOiQtRKnXLxKJwVeyLBXY+1GQnVaAeIw9y18ShKBZgWcRuxEq
8xt0KXMAkuXbOe4i8sVPHEtrBfccAFHjBmqtEffKDNkr36hzVUO/P/ZcM0bp16gr9fJaL9yihCx5
2HeF2Bd+ISZIWxfzLjJrBUBYaoF91OVhXK6YcXhyGh/MpzY0PJAAHqzH3kfuEh7qVMpoH1CFpS1t
x97l3V5hRkncOwYaSV2h081CNh8hhTHMIUPAwv8AYpfVH+Qn0nYJZooW6YQ7EnF1zHchdtFYm5aP
ZrP5ImOhUz0R2alo4ZcJV2ByLlCzVH0yH5gKBQIPg8wEalTpuht9S+fy11nLG+4ZV/iAAWUXwbyT
8bqDwg8YpbjnmOzZQq9iiqAXDNW4KdYhbjj0Ev5NQetjYF4uG9jBsr5QOWFJ4M/uJiZAkt6qAi4o
Gui50BJf0QoAiNnfwHLmyBrYXsJRMUDhe2MW1R9sBwBwe24GjjX2ZffUikX4mW1yAJ6llo3jfgqV
03SX6YqFIh5xgi1LqPKd2frzYym7KHNK/wCyyHV/uXv0F9bEv7cEwI3TXTBU4AuX5uo9pBel53qw
Fy7SlfPMF0NdGpAqing6jAgvHsGpb+3r7AuXuquCHMMuO7SHnJU+LxHhSYF44BvWwkmNSfhDC7uM
C4jFbQNah2HgjSurlSworycyxt1afDoyxEiLuXhabk1lmqVlNVxcOYzWV5i0RkHFwe1Y727/AHB+
QBNv/wCI0cKkVBuJMFR5EEUsqbKZqGHAfVLHmCprb8kHrEpeqcauTaBIKj3ac3KpBrkvtexSULBr
QvslIFPmK7jhMsSta+mL9VLzh7uFHY0XSnO3YgAv2xd3UooAmvaMFO7XGbn6nArfXk3zLQVDTmrm
yy1cZeArbEi7zOfssLF238QeI6CxeKIvpNRogI6SRaEfc0yCF2TuuIkImGB8x/b5uRq7lhRDcoxV
jJbpnE9ECuri6u3ePklIwE9HuIC2K+WdMBPoA/xHJyEpQza+blt7YMoSxcHTbayN7CWtacr9SuRw
Y3ep4GEYHdvxGDEXFi9M8xc20Fr8S03mIptVdxQ0D5jOKx1NDVNUSgNb7gavPSVwKPEGxf1ACnLk
HIsYBa2vUAD0RhmFeX5hxPMF6EabjxMbdZSoRaTxKM+5yF1itbqZU7jR2fLEHxUapU9ZBXTWECcv
Es5gNJngjDrERdGeo2Y1ErcS1DUqi6J0zPMba6hqlFbB+kuy6yLVEyLZTRwEax6i1a4+o4HzN7Q6
e5emwDqX0yNLTYy/wMAFGdxCL+SIBVwq4+hommdOVKWufCIFooMX1ewTFauUoc4gRV1KVXxAq7wi
pncULEF37igm7tQtR9sKA6b5jVtDPpEVFqgZeyvUARmEIFXRzNwX5qXodcfEvYPv3KFLU7mwJTk2
C1cXiACfcqS9hdfUDvA7aXbiugwPD7le6APChXQuDBycNHVFIYic2QxHRXmWofoCZE1cItTxCI9l
vIJBaUOOxDlsfbHAU5OoaI3QeeozXV/UtbycMpG+48BXEUuVE5PHqIbG8lA3zAVs1FBHKxqXol14
DKgT7n8dIBiUDZsghLwYNCuG4ArkM2aQXweZfkulDM4hOKViVzB6oixD1zHZojYRC2c9IvMFsHrn
8RqvoWDx8wZZpPBkBEBgXToorOJaESqHmYSw0z9zU+ii01sbfNKWI7hrSkXCHiQm2PaTgHYeqhba
Wg5ihs7+4hVzbQv+Y5JsAXnxNJVtevzCltyiLjVMVSXj1MIxNHiLAA7R6iGvHNXLvfI3dzq1QK4V
vVhzS4DEbH1LfTEv7JXTWUG1zUqDsEbEgPcXjIJ4EBG/EcFhzlBKXQnB7mhGVcFcTY1dg+7gicUw
vCMI/ppUNo64UMOmVaGe4Gds2/cux21Xc5uuBfuHftS42NKArC82Oxqag+lRevlHyKh1Q64lklZN
5izgxWfDGKspq6TacKTLg6ZcMhhpEfufo8csjBN1T5l9sGKru6jmKFHUvlgouhwy/wAXeBJhwlyi
08xwxYzX6nfD0j+YHv7gFfb1FsK4K1g9cwKa/Wx+MIhv/sZIV1Ovia5XmF+olYl4r4jBspmga2Pm
iS07Mmu5Nsz5mlZNClXDzICyVXFdysB8KsX/ALGzgAbtb7lshTtfsxhtxurHxxBHiwukuzQkvjbv
+otMcKosK6Ay0Dc6lG9sYTg1Yv7yV0lhEKiU8gvnbqLp6LQz9wdr7syqDKaUeTcUpznAGf3c90li
PyStYldX9y+bYfQ6I4DUZw6G5eh8C/nevmLRrcjlbBYx9dZGJGR0n5ZxdbNt+TYOsaFf1MumcNfE
0JS33F3ss3mDdfpYtebjVMftHuMVTe9XlnHHHCQSb/AZcpRAeC4CWAhds45jXG5UHzK3TfRBKzqz
TB/ghhAAs2c5M0sFxfjYP6nC3leIRQsnHVZ1VwWdqtNR/aOycQ36HAXzGaqljfE/7Sh18R69Wmz0
JqvbhNf5KnOkA0ovjxOLa7NPvv4hTzmq3IeIukVK4HWy3TI6vxfiKCDWtMrnxCoJt/4XGpHZYxxa
k2ouXStcuzuQrBqkVs1ppr09xL/GueFy1vhpUAVhCrvQVoJUbFWr9o5V8xcbU/wERYbYZ4T9CBzo
+Io69ypbdviPNeqm1HyzyNlcRUV69wI7+bY25aRsB28QKehAN4CcQEVCxLsOohwIRWv0QocgauLU
Jvn4mHVxLOpi7sVaGAKcV3LgG09xV/suNXtFKdSw4LmxL4O1B0ZSQpgcx1xNFeI3y2dPmIBsF3eP
8zBtHEQQ5hp4TCqWkvA/cFbXII1NlRmQQdkgLapg6iyXVtHEBo5eyqg4igRs8TA+oN2Nh1zCwoFr
34iE6eKlMc8xReBw+YKYVuWwo1+5bpLi8N2BpqxC9xWObC2vBBQOpZ6mFwefcQbz0ExI1fJBa7rm
Wk/SXFtREd/So2G781E1lJ4lVj8XCFOFcRKeVAoJUK+o8Q9kZwKqWW9b0y5zYOBNi5qOomjLxd5B
lFHktstijYwH2NnsLInVn2GSwL8cx8y91mrWuAaJbUlV83ES+pZKLluX4iK5yAtLubNm4zZ4gUFM
BDWviGoeJhEvxG299Mbqox5ESOAKF/FQ2sjR1UtLuIFCq3mE3DyuR2K7OWLWj4DEzm4txETksIKI
6GqWJ8VKtxAh65GdEdFT7JZ8SiSpbhtlwcKtpgbyYemXlWWIv5hFVtwS5QJdyol8E9AEf1pnO5jC
vgJqbCumCMVo7SRFvO7SCDc8Wg2wHaMXqt2cSvCkqZ6Omq+44RHKqsbPnqEwqGXJqkuMMsEeFi0S
1b0UpQuTaeJTgPAghoStEPuUk1tIfcOJHCi8gypypG4tapbWkSgE51cOFhyWUfmPq4G2YpLO6QXJ
dlJAIaPlv7j6KDll1CclOLgVBYkhZLI8Rx2oOpUhFlOIbFdD3C+EXTuOlTdQw2bayVqoNumUMqLo
qLaOlbKjZxwSx7GAqKX0nM1hAu6RXWh/cyOigwIFT5BqNyZGDVU85hLZ47OpQAujUvMHlRCPKOIG
GigpiGiYKgOoKHYSuY8AFGtOJcCO4XLkL8HSEQqOnYRWr1EsIPUWh7CyKPHDbz8wwJTbL/UfD+x2
fErCrZfqF3r4JGP13GvUasQZXUMJRb4KeYq0tWOYKVY46gDj4cPcaGLdGtd/EborU3uEpCj2+ots
HItD6loEG6QsW9uCkFLhew9MqJjBaDr8wyUnQRIIXaFVDt1Y35iHeognb6l2wLFa/UNvIULViqAq
D2MMLPLFkfiB0c4Wh5Ip8dRatlU1P/MV5EqjV/zFz1IlYhQvSvTGve64w2QpJb4FwhCPC8sVb3CV
Ox2ld+Y2wydrD1Bsw6yIB+bgNYWPlFviOhRebMReF+WfmZoYeIEou04YCWarhlFBf4mF250H4eYQ
lVXfmDC28bmkXREFq4e6DalyvLI24Leai4RGNAVMcB2o20CpkV01hLt4yWtfPmUa/BAGBolHws2N
wceoFnQiLZXipo533LCzGgn2+YtijUGyXSzKtfiUAvfFy6BRQgbdeIgY3csKFvMbTzLy+LiFxFXO
mb4cEBaK/MsI5GD3I2iWnzLcORHHJKqghX9Q4kqVWzzHdLbijb18QUW+IUNtcEMX4RF7zFbUWsd8
qIqvwECWCxYlHdvYAiu3AWqHVrB5Jk2OqVfljegNauDsjUAMu0dgHuFhVnTGPXiUFexDa9hfw5NK
96S1kAvfBxGgdVBSmHmANJTd3EQ0RKpRPKCuYtQ0e57oscRMiwoo9oFJMiqBSdkS3hbfmPleuiJM
u2UTe2a/MQmWKfmHDwylKqNS1tGySYt4bfBEZMKTuJkRsojAdDSxgpIU44ghrU75fiBFU8PU4Aow
jNth4DUAXcp9oKMF45yMXAlHiBSW2rMiMg+ILxdKTUnE1qZ1LF1zEIZvuHwKfM1DnqZHY9ywX/E7
WvUan9RqcQhnY7HpQ7CMDQwWvEYiB2Kg3DZ9IbLpkGaOhsMoDvk5ZhvXo5lWL8EWsZeo7jQHmOyV
adOPiCSBey4GcCXcb0d/icPCESu1Ft1zL3BA2WhKqoNlPas0ZAx0L1IkNdULP9S8IBeyoWOiqKY2
JW0LFDeLMqZQNF+Y5SvFQ3QfUtr68QbEFlwPEsmiEDguW8DloBc7ELORRFF3gI5tOEF71HpmEAW5
zcWIA3Cl1sdEJgjh9wBNMZ5eD1HXoULw35i1aQBYnmEVxWCpZW2ZKZqGWpjBEFYstanDqurQjort
67llsdUqBPBbkRpxxfaXYnCkrRJF3g+lIqtLkrIcWVsNn8QkA0RyXX9y1kxTF2XhUBruN5cW3UQE
Aawf5cEbYOATZKwoAX68wVjd6MAsumkEF5HLQKAy5myGjiG6T0MW2D4y0ATB8TV0co6gRqqSuCNs
DQG5QOueOfU8DepVR9McLrzBclApCvFXLENQDAG825/EMUpb0z+Jt5tAOZQhflkrmVqHSIAOp5Ee
ku19ug/EW5gcHwH1OamUP5/Msi8qGB5ljPwRTe4HBQlmdpQY8GDzg2c0+JUEUPQt11BEw+AJQRul
rHkrB9GAQPXnmpo4ra1UQ03IN3om/GOBFZDy7UPm5nGWFc/EttYN0gEIL8DuW9UXH/r4gcYqB8i9
sbQDazl/MIRgA48kr5K3IESlamIVQYIiEEmMxzOTwlMj0SgGuIBclAqmrjUwhQsA4H3OcqWqWcQH
zxBbwwc1Q8g3hDFI64toj1X0d0weooXG8SjS7lFgcEri5gnnDzM7D8QAo8xWNuYgsAz9QJRt83Bt
Yw5vPqVrmChR2DcukW416h3btRo8VUxlu+pZbXE83HqKBsIWgGzuUnC3EURO5YNnzAJh+YbNndfo
jspwhIpZ7hxHh7l2LuW3x/cugMGdjrEI81PJfESlGmHQWrYMVab/ADKqUA+Z2Uy9cCFN16hRLjQn
uVWosMjaGXOQ2vJNMj6qKLKeJQx2NcM9k0asryTuLZvMc6kqIlKi+RKKioFiEWuxi6jACULYNqWe
I8dfEAQpROZwvmCz8I2liRdZACZdoFl8x1GqJd4tjelw6lFH8dTFeEAKbeRXpAhDmASw7AC5dQaX
cLpGnbuKK3IidXzAd6rxMyru6Y1xK48wBHiGrc+pQW05yNEqyHSMriDShQVCcmHUdNYniBbHmNXd
+oIRVDsFaLfxPkghLKt3O4peIujjn3EVLDy9RAQ08IAyj5qALP12E1gHqdQrVsCcBXI+9AfmMgEV
aEygISqracMu4AJwxeqlCV5liRW38H7i9Qttu7gftq6+Isupsa6mZz3HYqxCP1OFAHiSn1HwkdIQ
r5IXmS3bYlAO11zkI5iFRBBizTx5ruIwEtvRIgVcErT2sK7Ny945gLK1U8+j3CHbuAgxqJy9WEcA
tP8AkC2+zz1AjK4Exsj0M4us7BnEwHIDjBKalU4iJlch65gdiKSijKT5GpngAAdkpzcCWEqhQyA5
RaB3KMJwwHRb08XBGCBx4i7QF64KjGrsBJUApy6vIqVsQ3X/ANnKETnPqUOYb0XywNlgC197BwV4
e+IBynIg+zRiOPMrB5B5l0stolFdsMDnjtrllRcjPwxgNFzyb7hguNW8xnqWX75gT+ByqP2bhc1t
QiDWZXL/ABBd8wyhIBuvXJxFIkRHNH+I3hQhWvzGyRKOX8RpLh8CLOcihuZXecRFW9fKPMTTjmaa
wAAx5usQ1Mu9U5UgVRLYTZSvIQuwFA9w3q1TPqBsfWF/KHZ0SH4RW4WQpYeMlmvWe2QrO7yQGrVQ
riHwyGIW7C4iqSw8G9JQbqugeoGzZ8S0eGP4gWwLDV5+ZhdEA2/EtE+wIQopUnFxlCvcMYaj2epx
Dh1Kis20w8sHyWKjbxA2lbjgHSEAOLy/uOmqR7FzYGajauPIkRXbW54lwPxXX/EW1TgKuauGmweH
qBPSYv0HzDCkYeDzAJC1MPAZFkpKJ3/64ht7VakGqHKOR4g6HqD5S3bdKM6P7ZtjYPnbb+WIlgoC
jh4ibCcp4siVVkDyXxADHN3sF+CHLt6J9fUvMXhpEAhuLKacBL+2BQz47lQMK55ycSGoOw7jI6gH
EHfgqGKFg7+JXEoWGwf+x9khpVnH9wKQEKV03/yaAIfdGw8IheBHHVrQHuI/pTW+KoiBtRLU5f1K
30d6TfiKxM/PolxBWY8gxlq44G6CoFIuCoToFK+yBxY2zRv/AMiN0D9CDlxa/wARqgsi/cdwOe4R
FdnNEGqx8zYJR6jZ1xAot2zcqyABNIMso+YGDy1HcbuCCnXdzYEjRoL8yyx4yELcnNQAeSVFXiTF
CDiNlxspkESOsCVwSYu38QpxYbfgjRnUdwdlUIw2GhrI0rWEGlcumUnJ8RezDqGdLuLeAHuWj1Di
NvJxyF8QQ2S/cwPgl7LMTm3UbeHD+J27l1FqaVzknMKWsHyS1rLiKUV7mDbs6lh3iED5nIXVdQA2
+CaHHqDoYAIyYNhVV9wHKuJali6gVrtt3DgB6jarS5yWfCDYOrx5ibc9ELjvqpmu76i7X6lApz3C
Cku+50pmxLPD7i9D0ilUceYV2RUb7jCHJDCUs4uIlYeYWvISy2fEoDmomxXE4DzKGOYcKvichwiA
1qDkaxQ0yiUZH6QlvEdIcdxPDNjzDMxINXLl/MU04XYxd59nqWowO4LMAu7mkltyvEWhYvKwEKVT
GKzpDhiHPZXMLgVvEQmtQV8kJZxCa+I3AKLrmG/gE8ELa1rQeibGVoYCzKOS9giCi134qWFTneWW
fh8/cqDdpfrib1rjkhDAjQT5mKjqIGpb2fcAu0dfiLHWpDahG5t5qLYSpAKSxtv1Awnp24yqeog2
RUWW8QFiGFhUIpq1x3kbV06fipVzRbfmc2Piodlu4VJF6ih5OB1NPEbxeypdOvxAWMWeJmjbdPcr
QBXkhFWVn9ymalnpOUXkxqC8UQfBxGyrX8Gyl99Xa+ZcTAAHgSDhgDfZR/kwUInxcE1NH0IC4ago
yEzXqqgJ7EB1DhUDzWoOdr5BLh0N7XPBEegQZZfEEITLLt9yzzcjn3Fkhw1KBbw1+JfDLPkcxsim
oDBQKcNRc+Go0lHU4ixvlBSuR9oRjdNU8bKiXRwvwQVO2EfqNS4u5fEUZbOscXUIej4riXyattla
Yri6iwgsAUbUcDeUh7JgCUnxF0bRWDmKNtETymQ6/wDICiUc4uVguynkyGYq1dstsH8CrhsvX+Yl
UjqemYbhWEXtv9wKloEuCJQV0XGVL5SCYpS5npK2nxLaJQlWeCG2WVIPNx2HRu/UKVQTYPOxWu3f
zRctRh6niLJwSZzVTV8fwxiWhPQw4vJ9OR1rZZPewXjvXqCAmAHn/RNm/wDSglyvL8QrfRv9oWhw
HaN8SkLe6op+I4WtAR3pqVN75XhF6etjZ9zFdWp4sEl+DUKdstcNe2qN/NxcFwe/+M5KEkazOfxA
MfzVlpS/iJELB2vB6jH0AqcaTHoguGwg55gSoWCAPOx+MlPyD8xH65sU8v7gNEkVAvMBfRwZcNgF
7w+SXeNhDwxWC6gC0cIH4qLC745WKdiIa7H+oypZORqUaGNap4/c0VEfgr+5i4TilpVfhiL/AFg7
+41S+Ct8/EoqIFpa/uMMKupx5jojpoy6KlZACqKvIoMtS5aKj3pR5hXcHYnQ5p7gpzVleY/myVtd
wBt3vO8fxO0bLr7lN0bGq8MFFUs8PEsiJMWJPSidBiRbuMSqpeomO4lG+4IwOkuYyC7dSzFjEC/t
niacl7CiAVu8zwzOKnVVkK9kqQI0NLrOBpihqzYdFP3G6+aJZYXDYKPiWpdysBveIE1ssg1jBVgK
gll2MCWp7lDd9y0POwBnnzANdRCqc8RKvCG6qPUbaLkwv9zkpaoaMpTiLBZV2pwus8MYpYj4h7UG
GbeOpa1z3G9gcIreL8QpoxlnkA68xq8gt6fMSl9pQYLjPUWtY+Zxg5gnBF4iB3HxFb7vZpiGkdG8
Mpf+UVfcobxGsDjqag+UMHUZW0D5YdUseKjtFHJCngIkDzUv+Y2acTl1zFwp3KwvPiA0HEDk1FC4
qCN8y7VMUcT1EJxkaEqCrOZj2g2atZRVS3hKtHd3AI5t3XiX5Epg+kVIN7JdB4rZkNTCUlwifJ1k
0vArfEC6AuUdxNHyeo1U3sONTpeYkJ5oxYWA28TV5M34uPxQe4cqFFrEh4b3TxcuHRUfDUfSLbvu
4hIK222Co2tfhEBMtHluElvFfq5czG+WwGeHbUaacA91GhLBriJUFviXSNRdwEcMdl0MfUwxbHMc
i+eY4TBqxYaVxUqUvGH5qo9dCt8kbjSlTzGrlXxON5iUkqwlUE5MVaCchFZNiz34hTFYq72/7ObT
D+Jd3EsfcXkcD6heAhfeS0VXajLZS3rZV85j8xcT2ry4xFEFHzOJKG/Qcw1AFW4QiKnouMB8D5SU
KzbfuLVb2DcDUAnc9kKtQ23FQWaBo8eo9DTQ+o1AdCnHMdGWRAnzFLvAur2OOtAV0t9wMgIPpKed
FOVMcNwS/mE7S1N+YR91cGpVnlwPMHN3lZ9pZpgtf+CP0RHiYQFi08y+cQ78S5dXCorqAPL8Rdmm
DcjTIRBLhQEFHrZo1gqUEDg7nyeoVCkW+e5da2+QfzCJhUFCl6jQQtKvqLl5QiXtw0vicQJT6I5E
+YLQY3HHwXd3KyYMZxxcdNx2Q6yLuLO5jmKQfPmNOuEqqNhiFrod8ylcbqJxWsRr5P5I7uj/AFlw
pfDTNnNp1yEQT6PUvqvpFXDG6TOh2/FRlqEQOVuLBWjOO98S64KrutggLa5xbd34jjgQ0BLr9xge
0N7sYEi78rf9i0KVOwmsaRBXM18xm2ti6OvuNiKLOVuDSGrJfyl4yFWuB8KF8jguUZaU4nq46HSP
wZKAgMA1fj3EIbBaDouByWQvXpnYwZi91ARRVoqdRdVDfOzkVzZp23NF+VxV9xmpaKNp9R35qhDm
oqFhfJHb1sq+6VAXzC3mgb2X4yFJCvHLuuYBIW8PV57WX+qrHK+WO8YCrS9loqgGU0i5WIB9n+2E
c7Xqxhf4l3VhlkcssIkhpd5uH8nk1E2Tkk5Z+kovmAIEUridoyPTMbTV+IuiIaxtDI1DumXxLBrQ
qKen1FgxQTU5Hc7olgRmiJfoHLOpcK5bqJWhSvuW0OURo6XUpTmRWvJEPXMtpwY1VlEqa6uGk/U5
h4lD1FFj2hLAyAqmhhdl2E2q/UdL21uKiru/ELq7iKB3uBGnmN03EJyEWb5ZatL7jFl+IuELQKuy
XI38Ji3dQq68e4yFZ6h0v8zF6148R5hp6jvK65YHVUBFYrZ6iDG3BtS42mA+YqYt7yRF6bPMRpVC
OvUSht3BXiNtoULcvb4iDfjI2AupsDwZAouvmOLx5lAURryTOaRLiitQuWNL8bD7EMV7RCTy7hds
HmLgvfUc0bfEOVwi5azTs+46QCHmUXNssoVEas17gHK5dnNS41V9S5cLcIhZ5iXYGvcdxwQOxUaH
QlTlXmEg1DpehM8m8QCPmIuAWOoX0QUu9dSqrQuDZbNJCi847YChDYVQQrxBWdepcN9vLCluXVQG
l766gcHbmpxGvmpT6hVrY+YVFXfl5gZHQ8ncy4Xd7M9qPDABqk6lq+L1PFtdj4jsEpX4iXtA9Q0U
vw6ndaibT5lymLMXAcIQAGiNbR9EpNDC7L+YnUTaLbjqFFIdZ1xSkRtuXuqWDLl12WDbro0iF6LC
PNR6QuronRXeG30xN1HdTI0m+5aqXcCECmLQLHmWvr6gCle4rhoSxVmsqLZCXSuVC6+SVss0QYdT
k+gc5AlFFhu6GueIkGNEb/CovrZqADWbHxGowAmAPMK6JqKJ4h0ZAbqzuH2o52jGbSLibUud0E0z
XRKLJHuANoyojOCLj1F7S4TiItXon4tQ4+ITrhrUVCATbF+TUScTVMb97G1S4P4iOMpXi+YtKzL6
fJsSfOopnRwFqP5hDAVpX/cuFBVWf/YWLqUXfbsa+66YeptmVgOuFGBb9xKpN8KvqD20abNhurFU
JUUqB7cvmboWcB6grx74ywjuiws6wBpKM1fRJWCNWbSZVh5CBCB6P/IXdbLgr5yab5MKYIHUKP8A
U8BRsIO6cdm/1AckoLZUcbaK4D+IWWYSVYjii1BdwTifqWBgoCB+ZyVG2x8JSHE0AX8R7UvVsXq5
67SgmKHNiNTkV7Z7IbZBJSoBxB9f1p+p6wdOJcFF8lqYsyUQyAdzkoKdqO35g12AP0ZNTCy+dfLF
aLtrNa8xXfzVcdkptTQwnYG1cMog97GBVhwRlC9QKlumWDCW207GESOG9CCTkoGxqWRisBY1wbvE
HHIvmMwDyj8D0gVQmi5GGRyivCLn+Qsgvkl4llpksRird1BwiKPDs7FD+EPx42+hF5f3vIYEmA9+
oqFjucrCXnOTPTGaluS17ijZ1Tbl3GbiUgfxEIg2TcaZEz+9rcQWB1dubQ1c0QGWnQqXLt1lDfMU
qzisPmu5wruAqiFx7XAsHhHIpIHzIXly3FYt35gOzpxS/wBg+vMWL/cFBNXLfM2HPAfzC4zzQX72
GNJtAVWcqocd0QQbvu4qlnizLInlcqyUFM1rl0TgsRXQsviXVKFgtu289zhj8zSAc0r5la08nEQr
q5SW9QGmKOGggWumFgdJTfCNkD8y2jdniULTfcNEChja3axG559R7A5ETObclB0epoYWKLO5etrf
UbhXggDKL5lioLieHfiWY+CKWD4qUVphvyZbh4YIaygqA9VFyv1GbdxOyaQmwijlvEopZ8sNASq7
jtyaYLgtkJ6Hm4AtsOZtO8kFC5ezLOIabVvqb4PiWway3Jt9TCuIWy44Dweo21ZXmDty4hW78sGj
XHMXGuZVwxlEc1MFc9yy3nqcGz5rAhb5jQ9PEBY3bwRSvLLLanqG1VvUUdDcCVOe4KEMbuwPAx+i
efZBFpecxCy+eYDxtRRTMgKLzwS7gVarl2B1JTcDFQst6qWIDqNEeWcQ0EGy3CbG+Zc9yJABV9xA
F28XL1blMtYr2T/wJQ0GGEtqUjRddw4nd5juTfAmbDjuO6M8+IC3cP3Eipj1KmD6l9hg8RkVYXdz
tJiqBGnDQ3aUwHk6msbFBVSiUTplS2g4qpfSscJhOUhyNpaKg5EqIAAO5iBRcErJbS5qC12LEO42
ODQMWwmxQo7mQGncbi0UwQFB4gXU8E0l1GWuvM09xtysinRb4mHNf1KeFBnzQVyw5pQlHUdA15Ll
sDwbtSxoeemCaF4CCCugCEP0Pf6lrkS8ZLBUDhLYgdtDmZ2EKziOTiaUlR6eDGI5K6o/cuLZ2XUq
CA9lVClB3qIzWPGQtWvUZad3/KNcA9qcxAUS3CDJle5HHJKG9MPK+bIRm2NIlVFpZburJxKqoiKH
hFxheBCl4LJNVGgcFy73nSrgha1dJE3kl1xL7zdFrJSQxp5y/ivMKAVofMtuiFLf3KTsLDDluQt/
6oGIQLtdRsI0c1zHOJYyivcAmtNtBEqnFLCCEcKThjDZxWI8xdTKLaIbq2a9IoYjcJxQ+JkAfEFQ
HPEoZvQbH3/SVCDMCE2zWfFGrFNXCwXpsYGUR0xYHq9XO3p6bLFR2iHFZKKMI4udNEOkt4AVbbiL
fiuEV6OMEhlXUWt2PVcRhIu8TFQLuDYO6VC5Q2Mug8eI68qlADWt+qiXwq6bccko2Nj5LVAhdlX8
TEtsMhF8EOO2uAlAoQdsaDS74mCCwqAt80cQyk7qvMAKaCmFPiUBLGFA6uAExk/Edb2cEF4l4w+W
VcI6IzET0e4ojVUAJd+FUtD5S5fApYsXLyUs5aSLXfAFpP8ARAQIa1xBWxHjUY5iFl+bgC+AtX8y
7A+gKHuoGy9fiBX+wbLLobi6t7HU4cp8ThFc9S6XlPcFEpzwRP6p+xtjzVPCBY+tvtV6/cEIBbK4
2I3AKrIHIffULpuljj5iXHWQAvqyXiHKRI+oIDKz+fEIACU35lALA8zU5KD3GErs+AgkhFEDfNQc
IcO3Xczd4J3DHgR7gGBOZUL1AA3lTBVIAobAV2LELeOooq7qWCtuMNhb4IiFuXzlfEUiGS4FHMF5
jqLTlTT3sAVHEZFwBUFeslhEJARXQcBPI6l17pA0h8PcWKLqbo9YQshbIpUGDC+YId4lQnxLcF+4
Ij9TmbNgAI6+oHp5hbNfUVK1fuN8p5TBzCKp4m9l5b8RaCV5ZbUd4hkUalXiaAC3Wy0TzbOCcxVp
XxKlbTDCctcwBawxFbBzZQYW9RUXsoVYMR80wUitzEZcVNrubSjD4Hl1MTFVVJMnhxZFz2d+YrFf
cIvMr3lvgmNqonUd3KWtYuSgfLBe0QMdXuC3b2grmRrLqOi8fMKC1276jpCy1dvzCuXexCy/xLql
ysgrNMAqGn8y43i+SX6Y0x4QlBTeqmoLPNxIZhsoFOLxGuLYArdtwFPDvyRgo3FkbahtvnncAwmr
VFeCwsNeosF3fAuGJ4A1sdgBIJVw8SgdowEqmhyBA059TrvsuqhKmOd+pWpQVwS5gHA5CZnrA+YL
ZeUC3KSmy7CVzUuEDyrxOY2pRT+5pbT7gpC4G6OMUSmIN9SyZVxRjVx0lSngIKIfuX4WgIxYF5gu
2rliCE6o3VquKw2YRkZAU5IB9ZAK4yDZycR5zUHEC0GS4PAPSs5ggii5Txccahemel4Qq4kxF+WE
pdzg5jiEC1uj3LfUGm2xKHxpz8RIAAKeYVKoDkhMD1gX8tndoVMIEUxsy4f1OjrXER7DTXLXESXe
MWOz0GFAjpo1y0jHaCqhuhSe3l8S6KhqeNIuwlAXYN1KknhXgrxKmgx0SLwEq6ypba9oW0Ww65Eq
79y/83Q1cQaTJxwAJwAQqObr6QiYQtTxyzdBzlV8cRkw96pa4HxGilpQGs7/ADCOUURj8zgjIFF+
oIO4HSy2XiApWCpTaPH9x+FrApa8KgYCTB14ThOS7Q+YBVCBuq4eKFiFuQTxpvIEBLRXgeodXzgH
MVQI7ZxAU3YWh6jmWgRxzAeaaT8EZ4aqnLOuoSKkfPUo1QNbRfiWEBOlACCeE7fLiBVbfDvqJ3fv
ZAwFcq2OowCkQtOvgbYymrQVdkCdGI4ZojEzQhUKFK8jO78Wu4oramUD7Zg3PcUkjicvMe3LiwMr
Ylrq/wARhyOBjfjzKCd4KsP2QchiUWrDsqR8k3m4wk8V3/EFcLPwZDvUcfmCpbT0Skm7ojOK8w0W
hU97swKUoatWr7hNpB8Nq4ZgSfYnMtN50NAS5Kr7uORwaF1Wsr39KF88o9Qat6FUPGdeoa367Uo/
u4GCcAba/wDkP9JZQwl0EPp54eNlKmFFItCvqZfedljx1D5R8MgmjjGOvxErLbUqXKWX+BGmjIKY
b4rzl4+oW6AVJeepdnG2qJLR1TC4axiWX4joaOK3rIViUvYrhUqxsD6FN14iGEHI3hzBLtAHwxPa
nJAykW8ymC1xxR8kycdzlO1lrFxXgtgUxqLLTZoERa5RY60IC8IFKujzAgjZ3cwLqJbyZa2PqVG8
9xRFlHcKCW+Jqj7jr3lOlxBe1DCBG6iDpswmb3K2xBY2NBf7ZrQZ6liOl4lDeLhslQEoKfcaE5Zc
DV3GpyslBEbZcFaMMsyohInPEQBwyqjlLCVsF/KC0PEVKBMOIV6Lh0u3cFWwxRIgxpCh9RSHH8xc
VzkK088wStcQNlYxEVbZDV7uUlO5uk1bcbb1AdLzxFdaOUyocLlrQ74lk2viUJXKFphzLtiGpEb6
lM8sQL7iXEzL2drddEo8pnESAZ2uUMOSq5PUFA9zW5jstBddsNUdCJKImFu+CXIC67l2hZ15gcnk
6mF8NQApKjh6TVSlEBUVGo+orjj1AaKmnaTxLoVyK5cPmYVRymkqpXzLc25RcVbzBgO9vMVqgHXm
IG2+EtxgU1GKrKLCpUVzhAJsNV8RPI3CDBUAfMBywUZzDzYKtr1ULaThx9x2hoUPIk5Zcx8RFVUI
+WNdv2Qx3bncYpukPmG/wEX7/wCzmFYtIANY/wAbGAciUIoJfBhUAsF+p1Oco3LldSrL+pckYFxd
VpNhbcFBvDKhB5IFr0nQNMb6q+oHpXEEcyhHICMCrUH6lrAWzzsXwqB7liJt1OY50wACwcq0W28W
VsrGkybsi/Up3Y2PUfwdNjzsXVDEvqiUNC27YT5cAqr3LM2b+8ZUeSnOS4aPPCGV2Hg6izWAA74l
/Y9GiupxxFCzjlgvnJRYwibYVPMUtNFvcNkhEQtjxtwHDqoC2geXMDo4K6+4YCNhFYIG7QU18RC3
T09SxY+ITSrF8bMgHFVB8xyBZZMNHdTqa5VsWNVwOeZUEsswoBqexfEZJULd5GF29HmiVUsVIfzF
kArAp9SmDlJ2SvBzlTJjSVAm5xBAfnNK+ofvIEJ0PT4XcOEcaik2cVFA2A6oVfuCxynqcIW0O36g
OhWgKW3iWuLY1MBKphXUGNQWvcU2ocKCc/y1OSXAgFORQPBb99x2vBn4NnighXxku0MduUvnPCSs
ayknBqI7zA5uTEE5PqnW8mJjrKDUIf2UThXiCqtAcQN46HrL/uWwDAAIBKiXdHzBWsQePFQ4IQHQ
XuCQuGleX7mcKbo52ItXjctEX6ZYkcBUtSgX1yNeiA1yfaQjq1etjWG5AMrGW1SFAOvMKLznqGEm
1fkY1lQbD68EAjQ1+UqAkhevLB3OhQr3NCtBT0uUzAly6vxN9Am/iUdjXB1tgqzk2fEfsSutLovx
KkKKjp8LowCActIFhMJP8HlCZsB3/r0RihNEKPn/ABGa7gXVLy+4F7UIvyHvwQig1aouUf29TJ0b
HC+B0QnbKAdx8rvRH8zY/wCEDba44lwreS7iFraoFa3f79SpkpnBa+j1EXs1V/EpVFbrZnHgDgnI
997aD/cEm7tl12PMO0AyC3iiERYpRZtzj+ea3nhi9lIdmdcQtATpihK9KdRHQ8f3krHotY+agcsY
qXzCzgbgu7PwqDeuX9v+xXh+YVACX26dse9Aeos81Eq2hBHxArlyoYrtujogW3uxoKV5CBpC2WEd
cShTleYdgLqM3Vku7b4ZSHHtmA8xsXw9SkRTTJawC1cApjbAaPMRwZzCYKr8wDxRAOvjI1bXU4FL
eIlt5RCd8V2yhTz2Sw7tZRqvtLFDPFx7A73KvbmMHjOo3oGwErL8Jt2/iXYtTAkVBdEsIcmxWtF+
4HM6ubePPUBsteoCl7jR5FePE3QfmKKLv4lLTSAJsB6lF8PUEh4cSrWa5lxZk0QShVrCijh3PMDw
RKrcZxCzd4NgWw+YFBU5nLcRIou40BvsglYUQJOHqVqvTuMHPuHIF2yydEefMM8lZEdd9JDcdMFA
Fl69xoZxKJWNTt9QIFql7lwtNsuACju4/Cg0ejxGJ6CfBAvUKJldnUuKWK5iyznnJWlt+YxlbxFQ
ur7Yjll9SwFp7c5XMQ3Si9b/ANg3CIeKOIN3YA6iHGUKwOa+KheuYgMwtmjoiehcDWroBg9xQ21D
Mm0Cz0w9pmeYJ+lb5qYuim9zbFCNdlwFoBaeiFZWGqdx7umEPhgqDZbcqJQCoAyEGGeZ8MLo5iVL
3xC2ycQvilnnEQOtJ3ui19RpULUEQHzbz6gK8Y2qfuM6lVquUsMul7Q8qJY9y6MCod5BrQt3xzCb
kPmvMcFtTFoaMX4gibAePzLxKInniKa0rHWqA8XsvVdVXzGhbHqdRsF2KWXNmNNqpSlWunMReFD6
itpe7HtM3gsMD1L7Dq+DKHWrZfUskxwWwwqENU/UI8cAtX5jCGlBqIORF/S5nnPgQSdFEpMYtEU6
AfcrKv5VB87SjtwfOgcBfMPwRa8+WOJSqPmVLRrX0QOvA/xL3MNbR/UrXhckrBOxtD3EEAK1YR47
0F1Cp5ffJq1zigFkoS6gA7YY7fFSgYS3T3KjiMg85xCTcgGm/NQSmw3FPq+prW3RK2A8rrNoIGxI
soZdDllXUAPfhFnoYyj0EbufAgTQVVnMpFxR4uM6AWfUWqN+oFINlBiUDUMD3sOKE19cf1BphI/U
fbAV7epYbqfy2NXclP4I3CIR80inM5H4ibRaYpXfopxm5j7GYylg2O6yLwi0Kz15hoAg01KvxuGB
2hLKvmUyCXwW8sUQ4Iy6yE5wAx1HU7/94jKkSyMGgULvOZ0jN1CmtQeCLdqCWkaPdQzVh4jf3KdY
ppo4EQz1Vq8L9RuhAnDTqD72q9N7o9QfUSutlX6hAaQpVLv91OPiy4L8HxFppbA5u9i0ij57/wAh
BA0w5b5ncTA8Dg/JAb0QBFKP7ic8K8Cm2Xxcs0U8W/om8xzz+4vo9zrfEL0i2uHZrFcUWYdkR0Ro
Ae35YG9Kx2dquD1GICI2qMLFxmFWcQtqGFAwIP5eWWxujgvCh+Kg5XCteTmbhktEoNH7gEbLF/ZG
Ijjs1X+w6bOOT5h4WQcOyNqJyb1VJLMEEkNeeKiRjsLazvGeJvr464dIvLNoL6qZK3qngB+IBSQn
DfHqCicjKwwi3YRAt7hbbPEo8OcWO3gdxYaGXAjFbsa+K9wrRT7hAMKLUxmxa/USm6sZh6KldQr5
gEtu5Y4UiJtwIrkqojncNjx5hg0iuO0Q6x7IDRhAsqCmJyzVGg8QnwG5vI+5QIfmUtcuA1Z1L0fK
yIZY2rGcMOIlSEqFXnxMB7IGggTXNMfL+E4AIoFncxXhZUcXSIVrxxEIQqUDuWBsK5IhsRgJfubF
NHiU6cwJJqLtSAdSgQgD+JcsMMiUADi4oFTmUVc+41EFgIF35nqKbhUb4bEpvHU8dXUNZ1KCltbF
BqzFoGo9xV+VuI3HZFa3jLCMDxFy4IrR4gxZF1PuMKNeqhb8NwQmLzYWKeDiCwfuPDt4hwnBTNhx
cUFXJTwQS1/9gKLHUacAbtmgjRApHZTcsqVbVLCsDqbcszivYxAKnfUYm+RmYgz8kN2Qea1AXW+V
QfMM0T0HGbaGWnETcabavYzytGy4OscK9ISwK8nvmPKxTxf1MeqKLTHALZ5BsfhOKC2upccHNOTG
eVobKIkbE2gEammVVaAVhxChBgzS1A3s2CWh16lI9Irh7jGOOp0uC5ZCHNnwF8w/ixZeYrYpgR2L
nTNvOx8t3otQ+LI28PcURYYE5hRhAq1epd+AUOIo7VQeZZOBYgr1HR6VbHFTk6IL/ku4LqA/UNLw
EHa72XDnhZkuMi7aOeIab5K/CGHlAlPUvaM7ggjZkLHEGi/HDYfqhyAObmQ0LbDBs92g39zpEygf
rzOP9Cz5gCzr2D4ThXRjxbGrbqYv8EserjZyiPJXzL/ZG1hdy88C1HIFFHLHxGYFBD1Ap6p0PxCS
HQV+/mPHYgeI52L5qwULUAbIZYMWOCWz28QXxKMcrC4xGKFG5fow3p8yinZw4Mv2jkUPzKUbgoKl
RTFGb8sSRrSuHNdy/ag4EuFjxSu1WwUkHYNIM8OYKxPy4437homKu2yh1JAfxLXATXFuGYbi5ANd
QpNlJvJS+SnJ2q2Cr9TxJIKKh2UJXAOoRasfiVXxY5ngKqFfXcRHiZSHisDzsBfUWPDWEV7qnY44
djNUp9i+5RHsCIBxzAhjacD/AOJi5vLXm4ZssAWv5ioF+jUL+RXl5VKPSWNb+xl7ZUqac+4IP+Zp
c0nC4S8b2B4gFQ9X1BG8ppYnfmH1rSkr7hxL3Dre/wCy/wApRKXoBKEipAWmuvuICKMJTriF+VRq
zxcpsqUuPURMOC0A8v4gkbQfDVRvDjasIerY7mgCSfgl0SxVIx4iopUApq4J0TjPfVANfXqVvK2s
Xkf5unby/hC31/nNYA9IpeuK9XC5i0FKsezuU1qNXdfEyBjswvvkgq46XD9SlGqRAdve5Zy0Km/N
QVPBD/iL2Oe8DwHmMLwxAzYzb+2jNRv2g1m2K2HPAhpUcMDS8O6L1YNJo8A829zqgfqeK8xLkBwr
/wAYyZ102d0XxGFWsgW7P8QDJUdKPnr6mwdwD4S+zm3RXTLYvBlmoVqRjUeU9sB0qCvyQtEgUq/q
4lqiVrw9QhSjoyGx+ORO1oc5GpKUHcpFZfRMV+Jkg1ZZUbczq6PUdRKviUadYmMUxQQ2viUFpbGL
2P8AEGsn5mhXqpVtxCBpuBoOMYovpAm0X5g1RyQxqeo2evDLh1XiUXfDZqWkaCfSWTYHmDsuAHNt
xbVYsVZTUUaHvZoVujxDfEsAqo9lsICqs6j6jDmcrNUduIGzmQFo5KWElzhqFErlZhaWRnBFaM1t
URqG6YhvMHlMiLP4Sym6a4govF9QAfMRxLeT4i25pnFx9xCvttTZR1koBbCHqhpXN9QmxwlUaiVS
o3wQArjOXkQFqvRNcEzglAt+EFV8dkuCW6hWy7VS1t2wqdxrhgVa8vEBFM8x8cvSBYZxEaMQ68xt
xxhYDxsQIotXCKq9GACuGWIti3Oal/c2BsZadzceK7FNrIDXLyoguthtC9lV7JzFTXY4lwJQl/C7
jaQKraS3TClBLPc2j/AXb5gRr5/2iEk8DmOtW8BYC+GFol5PFPE05DyuffEDfzHKal93C9ziDqKd
Y4+nxF4aODo9y+AONbLlGjvJiGwlLg7VdwVQclzbgYeRalKzuDUhA8lvnxB5FSlqwFbUdQlXIY+I
0g08xhGLBwe4+O8QVHDKYE/Koe90mI3Wm+b9RMGMrjGTDyjCXuAc9yysSwKhgZ3AKqjmPPuLYCN2
V+ZTYlB1LY5LFtkRIz8hNth00MqXN0saRGWb4WQjfDbcpVje6Hu1BSBhqdqTiqc26Y8A2pGXwK+R
DwSHELK3ge7hAgutD+IDpy7OSqTdu3F/J/M/EsdA0tU4Xzm9nqGZ27PM1GJyN/Utw8bBBG8XVLQl
wtUOHcl1XD2qFREigKkiFJBbd2/MHLm8HCX291V0Si3VLdMZK0bR2PJ8w0U+SCOBwl/lF7SOawlV
YtI2CiODS1f5lv4bAUn3L2Q25sQQTqliCa88m/cXcddCbwDkAsQuATeh7VBFs6WonoGAclSKRYNL
IlgKyKjRvMW/JLSqx6e5ZFA7VLjSO6jkg08SnHNKKv5jw87bmxXAToIxcNGXlxENhggYbKKPWXBF
VT1AFm3dsIYUhhPiBndRrMYWJiEVpSRdg5WWArPFRSNNjRXMPaqjmr3MBQeU5ilQXOooFvhLuOgy
eSslFW9jiUAKvCjJu/Hm6mn4oE5YI7LxyTmB0iUYUOkziNmL2x+DVgNRXMUBObfctB7xrkrULDY1
GSg38yo9jiJRNfEUBdcnUDX45qY87yTdMhst13EGWAAN2F/hQcAW7BasVxzPQfBFBN1yXsOJNDo+
2alKXpLRQDhSFRg/qNYmWgKvia4XY6AA+Elue0b/AGixw84T5iHhcJU6UHNyxtC1HAQTiI2eq7jz
DFnO2pUZ3hTZRvls/BfmFpwtOFr8ywQBb2TgW1aq5zUrSOAJfqVUbYURFWLJe/ZL4DsLM+IX5rvT
zKtqXs6liEEKhcfEdAoa8lnLK1a+vmXI04FMFJNK7Lolzcg8ESzA2Nw81GRLwJq8RcZscR8weglF
v2QyRt0ipgXENPGIeI242LHKUE8yit0HUprrjuWU4Jk1Bt7lxvl1GynF8Sm2B538wUteYWhdDmWW
so4iUesqbFyIh4qoIR/EsOuVOGlVKra2xNPAZXmJQ1xFc4KliqxhXbc5gDH0lZeoVjiGge2M6LnI
WsqFZB5rYNpkat4isDmNRSi6EiclPUusX3HtrZdTAbQ6ZeoCL9RCf1DLZzLAv6ZREhC3+ZtyZVxQ
Dx1EUSWQX3FbODBTdUC4HY5iB0HESy2xdqvzAWr+4koZUCxXxKp5HUSVFk4lyzZwqWT9EtqLLuXb
dZEC70ELt1hR4dy/bCAd+ZTYoCyPppuNyFGMoBG3dkCgL6uFzqZpOKao4O4zRLKWXi48XOZpcuK9
WpyYwHw2qOuYYIVjgyrDlYGmTfuDZ1cpIqClcQtyolMhZALQNS5YDxUVXDyP+QIihuuWzmiTxxDt
moqGCUKAQWV9oc7Z1FCFXGr5IlCflly36lcNb+JbSxFC6uWBuwMtanBUQNtjhedxymiP5ixwVk3j
iAdM5ElV4unuLTpTgg6p8Wg4hshTxLWUhfXMZ7g7WxrWU0lRbqcXJcEC4sBCOvHTSMBxR6lQEUX2
6lhMJTpLwF2VMygt4keEdQTLlqJwmqI1Tol4fML7cpV3HN1nTuMwfcH9xiTfCVfiNSPwrqV5atJC
sidCUi0vYRWKzealJtUkNLcucRzfyqjWvEZlK9THYLQg4IGS0vQcLBBoUSGoW7CnwlfWUJGoVCKo
mGo/g2AFp6gBiXoPwSoHSOnT1GLaKKKXcI/aI12fiIQAoJSHZBYOPtEHq+V9yhkZwgkPsa+pRzTT
/wBIjcyUOYW9UXb1D5IUHC+sgoZ6DM/MW1YSIGJKMMbRWMtzMt/UvzUEtPmAAQ5a+kCOHe85j6VR
VrJd1LZG2UJhLcMIKNAWs53VPXDX7jlt2Y7q46KX8zpkRqvmUAxwEc2WcKKDUQpzGwyL+JrITXwr
mK068QaKqGbbEGr7cOQw5WlS0c4tBEevI/iOmPByjOqss2KSk0mojUDV0lMFr4hxfmHJeUVhDVHJ
g48RfZZVF+5w/wAA2psWDVH3LG1hUloD8XLFtp4m1TK5inWaOL1NEVrnBUGqApTF+JYTWevLguXw
kVAKfH4lXSqeGz/kW9LBGhCHd/mV35YDhODUAaHmWuWaAtcCAjQ8IAfTr0h8QsuHun8S5R5WBP4j
jT6cpVEuwl/qG5TAHgSoLG6lDIa1KEp3cLFUxQAO4EgKwVUVCRpmG5DAfHxE9HKthHioqJzCo2So
PzC93RTPC5tkFdNbGDvhA+V/qX1SpDQ7yUqiBW0vhilkjDqDXq73GNkFTnzhg2APgF7Hrb4K21Yk
ahBHaq7+IXOjaB1cEKvcoB7rtjRfxRgnfuUTB+tcCVBNjg8RfAdLUsHAq/tMeYYF/wAPUc6M8g9f
MomIUfb6jqxTVFDlnFoE4QrS9EsU7gLfR6A7agipgBSvL5WEVS1a8hAwpQLYu/mVhjwdFOn1AqPE
bpzeYKRKK4OX7jlKMKqHcGtEuhvm4PmiC73SBpceIaQ3qC2mYKVLLCjZ1jaAt9RABbTNJKuWSc93
Dv5GNaiiNrIECV57mWn4iiHzk0DtOwHoMTd6XkFbFepoFVF6q/MoRFnpnmKzzfcQFgUGX0SgOpaC
7iAdQrfiKoccws8HcBE15iXQKfibbAfxLofHnzGxnMZca3sZAuppxfgzE4JcxsSNrUQ+MByzwy/k
ryy2rZMl0DlRHvE4RXzKdvHzKqu1Bg/MujWGbGFfpLSt49Syl13UbI33U1LepS9uKNZF0GD4laGr
Yg1KObBclo2RDYUSpa87DJYnmFEMq4ESwniXaPysNNu7PqX8QEs55uYZZVWxIOX4lXXbwjQU4BOA
v4R2apv+Ig2E5qIri8R4iqwXMI2yFIWDgK4+YgrQy5EWOS5RgmQ91NMRvgbAPBx8E5pqUSU2kOyd
cEBe3NzNP4hUIPOS7rFCW9HL8RS2lG9HiAobeXxAMFVAO4jVqrhq1k5A4qVdrxkAvKFbGe13zAzL
ubfEE88SxI36ik4H3FNT6vcO7EC4cMAYcgcSX1rqvxHwpsgmK74UBfPejGciMWcMVcVFvgJekYng
j1lI8tuUZcKOnlhtYG88QhNox88wB0bqD1AK4tiFWsQ53uKAiAhr5jjK+DxLTVNpLGEWOQ8RUNXY
0FymDWjPBBNr4dPqPA1aLBv+ogiAMU5XUtUmmSDY1KpBc5cplJcgeY4XD0pABVjqKuqaLCj87st9
vVdvEWKUgLVwbECmJlBYJwUZLbHV4uYXtAM4QuC7/kvxLyMbv4iB+LZ5/wDXAm2BT2dSujClByoZ
/Ys+qqcldwqohpnUbqOmo/8AA56jTcrVokasbdW3AS+tGcgQszCluQBraNL+ZSDgHuqIyCyw4HiF
AUWsA1rxC9n36ulpLmxHLF/5KbfrW+CU9TtGxyu4qrlV2aaeY7ABXAM4JTrxF8FJoLYZYP0JYYYP
JlDgXYoM5Y6oqFSmWQBbTXhix6wBUVBFVy3Ll6YLZfmN5rtX+IszB6FvMLUHKKA0iwVWGNtmHIwg
H61MOPBrX3g9cBTTIP8AsaXvY+DRVg9S7Du02jA9Aa9ZzAQADxxswT0+Dyh+KiJlWk0+olB+Q3sh
LwkHyoYvEulUjC5YcaN40rxlX0w+asZdjgB05c3WUxT7PxMiS4GHwTINqVwcSj+Ci6efzKCseyzP
nKMSWBDiK4ZBhVyrQ97ABMvgLc3rFFaduFCyKNUboQXlpctnu18pxNNQOUt5cciEPQcwCoIEenmW
+ZctOEpc4wNCf9mZ1rsLVZ6mB2hWr5j6gg0F1kpNCoMBQeo1XwGi0v8AFrHKVQ+7fH0QWG2gC2n8
sJVB9OkSV24DWhON/MPRLhcLUEcCrx3OBVMQPMAF2fP/ACEeECB4H5gD0WtetQGYlTR59o7S2/Lw
nwPc0ruIB/Mz/wA4ud2+JeG7FcF154qXhgC8KHB74l97QpYdlZK6jjWlyiMDQQDUAUjGO3yuEagk
Fn3HkCGC+aktoOI+19viIyhiShug72XRQkFG6yoMq4IvcvuVUKZR5gvm9XkaPzAZolCAFe+pV6Aa
gfdk2wiftcwaRHBvP7lunIPHn+CZlB741KbKaPmpaY5zGNW+RlCguFkIF+JbAdSzpZRjhLsTINUo
OoU42fqcFCpbeMgBjfaoDe/iIqctmw4e4lrweIIvL+JsPLiITlvcrLwQQDgjQLyFXwO5wOHqpfRf
ucIZ5mUKxsO3EprTqKXkemEwb3FAP2yhGfMXnqUXbV3OQOO/MoCUCwhYp8Sg02rwRE0NDKBw+GAR
G18VGtLvqXptEEhrlbxKLAU8ZsHAbMhfzUHbniCjWSk6s/ceAPuKzezQ8wHtUAuN8xr7iY0LlAXS
9gK+2MY7RlFcb2Wy283D4XeSlJd+4gUF9hHSZGn/AGW3j8wpXlnMr2QyaK6uIPy3IzarfUvZNWXN
DdLm0U35gHLpsRiF8jAI4fEZ7GQ6TpD1eyxFX/UjwFAqJwaqfdywPxuL6iCcCr56ihyF2ueeZxa6
T8EIpM1eSYmkhBd2MfiHhtQIDBZUWB4j2coqcqpa1jE4h1V85EC7a8mQ+YNuPiNhWsHvVnhLfc5q
5AjW3LBLZYvc3lXKGrplBbGrGjm75lnrr86/+RDmfLqE8oWvFX3M0LsziXzERL2oyts53djKiU4x
S6H8kagNEK8RHzevq57gPtVSk2Fw72ASJBfGCZoYPBUcYhrywnqtUVgQDOgR8SljDl4Vn3cPVjbH
JnfX4pexGls/lYc1fwU8MHqwQ0jxBLz77eeYYqUGw5zYQB0tZRHKbR7n8ywAScAhYdvKm2I3YWHZ
K98F9m5yLrB/71OhLLv8zkieQX+Efqor24xyNWjf9krvUfK5t0Tkv4hhys3iPqbjocqC1SgLDWV1
murha0At2Wqduz+Jz5W2XdQKEhQ5olDAU1dbDceI11yy1AkNtSJ2ollfxM0WqBQ/EAflPRbQtQ8p
5WAD0mlD18x+totr0t9sVrd22we6tmr2AE4R7rg8wDpvnUETRleYgqVap84QlC0F/CJpTVxDtcUD
Vae6hq/S/wDRFa5Us5gxIJwL/MBxBcLBdpLIHlhU4+ahFOwLDdvEbcY2kIaJ3N9IFcHPUqISlzL+
fFizBgHZwLrVIrXsde8JUgMXN+IRlzCtpsYcwDjViOSztdYRgryVOuZUGh2fRDuAgQvN1nzDecxZ
h/kuq1V8vllJa26tgu7Z0E4S+CGo2iKluD0e45rBUXzxBfFUGARdbGhxCi9F/VRl1ay+/wDrCLI6
VB8cRtjrZaevUXqgS3Wkld+G33GkPT9wvPQYeagKbmuPd/5LnQglg22OrK4ruZigp93O/jr6YeSA
k8qyxYKkBFLj555nTXU4mgOheQlnR/aMolAou2iFI2QfxHDj4yAanAQSBYPFy2otmmhd/qUSGTVa
UtuxtCnIau/4gtqHZeIpbse6H/kdPKjh6iaE5Be87FxmhNlHIRhZ1y+cu4xMr84uVnFdspdacB68
PiE6C4G87FTonKW/+Rp+FoSd/PD6mLgAt52BBDkgQFFpcXBgVw8N+HsIFD6zakr+4gGAs+5s1R0x
2IzQAP5f6l6s0jid/UXcWdjjNsjCG40qC20DoPNxkDAPqGtIu4sNeZlRi75INLCtiy81G+V+0gYZ
PNB5Bsi4maPS5XPs/k2oVZ0+hV/MuOLoPBeR2m/MG1fUC63maBONfcEpRxAN31LDXNbNh5nbLhjQ
K8QARX6gBYlwhCA8sKFUwnTt5Gluupq1h8wow57g5RbuzBp3qEgpqGitNZTGpblwBSlEyXqFEop0
QEhxbVhQJKI0kHEHI8PuFLbGDajEDxcVqGiFjlzSMbDeJQsKeIq3D1U+pLVgE8n4wI9r7ilKBU5I
cxq+cJa42OvKuLhWZXHk579xKeAhSg7spGnjmpRBSvBGfbxC4OGJHiwiKptXgg26hUaiWoeS9lWN
GJPi3iIvo+IFN4g107lA2SjBksrVER2PCMCHUo+FT2RKyuDiK0SzQwDnEEEWeJaIFCNh1KhR5Y0E
XcI7EpZwiKDCQaSHsOoxPajcdkc5Wa4SogQDgHlgfhZQ1xLZFsHjahvCC9lUIzwtepfwvegepB/K
HgKSz1FV8S6LnLVvSxiCLYX7j4OCfGwMTgLpkpKX+lzFWh2JctpnxPEvUq/JEQSx3URKXnLYFX0I
xFcQXWjLA2m+oqgnPcLaS416CkvYgMu/uYSEpUaKzf1HnqCw74ZaC9BhaaD4EqWJ04hiMK/CpkBV
VTmNAoal18RWBfbeZuRrUS90+TztIPUfjrV1nxHvQGnWwlPZecOI15XRzxA5ADfJBvLD6I6eSEN5
8y8EqJZ8VBRdyeajIlukzmLjBa5ZKaUMCuYrBlidRWMVYXf3LxbnbfqZbdhb3IDWIsqRSCXlezdR
d/qWnO3hnOouvE6QhjzKC278n5gPVggFBwRCiwMugy7C3anxkqQVQVlNy3QurhjtlIePURsHwQav
HUe1HG3mU9CKalEaklcc1L5t0DSn+SrwUF+eIPS6Q28ZKZ6jhtpFQGg39TyvQiL0GzS1XEyiLB6i
EaFvWnELZdC+otJaEW7DiDpActB9y5kDSyowXUWVlXkTHuDFVxWV5gSCDHwVNgt5hZrfmo05vOMK
RKWJXEp1qtwUzDpG8UbbR2DDZnByL0quoprg8zPQ6OPPH5ihxyLoitI7WwehsQyVq/BGSAkjr3Hj
qsUD7yN1qOwPAzDkLwOE6DAOptRm4QuoAem0t2FBFw+4RQUl8lKxnpI60ruUSohfhMQPDF+iU8K1
Wz0Jduft1hrfMuKe2uIVtFd0UOoeoFXb6hralucvcIK5C1SpT1ao3buagxdVCmEftsoJSdQTzJoG
24fJBE8JBBIXYZaa2WuwJL5hDUKhFeD+JjGgV0iqfOzOUVXkFp/cH4nDNNZd+Wim1tp4iUNZZA7k
ay8FrVTGeolZ0jFwpoKrAr1DP0sRRWywcsyRDyxZWurDsN+JdFVtQ1xKIPgjyQwh5o5Nz9NJD9Rs
llKr+YVfNKKeSWWxKi03/UbxKjvjPv5lxo+ELwHiur7gMUwQc7r1NEchT5NvMMHAuAeH6hCKKBYX
s5JaLW1uXlPY1o5+ZYp4t+XmXQuguw+ZdvAux2M5nsgPJseIzjWt3zLusfrPlfMZMPB1GxpQKTxr
mIIpczr09zgtnDoof7loJg586+YSg1LORyQlCGYCmHm5xYDh5UXBR9wpv6udKgCFe4HAocEoK8Vs
BBTVKSoumYbAeIQCJwwFGq5yEXoKsr3n6gMtsIX9RwWfpJHEoLf/AKo9Y5KWreLjhfhGpc3TwRQU
6cqFnXxFVNy8r2gYDvmMWLR7ggo6nK5s5cZGiVyxgD03N2Wpx1LKvgy0qX4mhqmNbueYk7PUyO2g
XjpfMzLyPFpPcsrAdRS8HNSiLyaJQczoAo5JkPcME1vZoRdlBo15nCHRzBAOPBN+SG79HiNzh8S1
UdiX5RKSnSKnX5StXTCclHUqOiK0XiUIFU8M5AVFRy41LAepdL778Swp4goYQqrPcQRwy7l0pvhK
i8r1EQeajpeXmGV0xWKiJxORhUNSwDe6RchRlypDvm+pdFNIjD7QXe4t3heZZ4S6wLYVU7fxBBdZ
rKXpu7uIDWhfuG0sTiIjQXkiODw8ksY0l9t9slAnN9TJJCrVHYQGRmnfiI6QK0T35gLAFAQxB+bH
b7gjgAQNkcL8xTL7cvFO4u8tS/upbQItcdmqQFfUvspVsfxALU2gOPUcMKUiPLB3zyEEi/b+CZJZ
LKauKbCq7iVVdgaFFw0VpKEvSXAHFXkujmLSi1O4UbYjE2bRhudJaxr+Ig6sC6+oK6LWNdRiadti
iMN7lQRwGKynIqVfzxkz1NFtqUPlqRUdqVnGx+YtG+9VFKBhqoKp7dXT2Q4gAALQEW6sTqXVjYME
GuNBhPiHnWl1cUkSqDpekIwgEMf3FJWsbH9zUeZxT0Q3h7l/ssztEN/mIVXGRX5m3fwup6YINfzL
dcVpD+Zf9Ftsfv0pe+YZ8vgclEVSYd2XEA4dxBUarP7ghbuL0G1V43JuiwqPuICOFWVF47TRPhmO
Hq4JWiij4Q7/ADLAfEvprm1VXE7m7tT8Qgm0un3DWgzuSnYG2P6lvPmjpKOpcsIYppuLrI+TmUNa
qVp+YA9eNGwuKnqIyB38z3DA1Pee40RaVhFAUnF9VFZiWFUfURk60e43a3zwy2K9Eun1B5GBbnsj
u3sJRKnChQ1yF9BXKD5liYCeqyNwaUHXTNHIqlhTHtZVclAw8A3O+tnciUQuncSAVuht/MN7I4Vv
4jlAQGj2gubqja6hpzypv2kS5yuHlTnUJEhbl8J8xFg2tlv/ABOqpya2GrILOErKv7lNUV2snRwa
TA7ssLLImQYQHsHWF8lLzvzDz6/DlAGgWbCXDQs77Kw596Z0ustXyy01PqghvxVVviKGavgTtRDn
btYepJSOXDnClsCHytUxqLFTpQfNwqfbs9vuML4rFvmVnPV0kTz93tlswc88tiOC8qKh0cLI0ZGO
r5hU8a4yhDqU5iofND2lg7oJFGNfiWb3fKYJbZ1eOX/tjNk8AtvImRFVBhPPxG1nKZZkUQ7thKdC
ljr5hIm45CFS06v0LBPMlBEfUHco6V8NxGtlULj8wADO1b9XD0WUL0n5lRdWq1vzLoEfQCPUSQHY
21iO8Dd6v5nIFOV5ZejvUEGj1KVYeVL/ABDUliivu5YKAcONggEHNvwiA2bKagxxUR8HMrWzdrLK
dC6Krm0Rzdv7jR93Db5hoh7cJFeKaJ4i4oOoAxr0quDEZZcBjrASioseanAbr3KBoZcMFgdMfAKg
5tQPLd5liZb4JoU+3mYA2Vtymr56ng/aEvUMwbhQW+EQUZsoLba6iHjPMSt481BVL0bLm2JMNeoT
I07iXQWXcQ6fSCy89eJQDl9S5dNF2kS+S4k44mxsFBbL7mnvxDUh7lo4JYzx1KX5eJcBw1AMeZfg
reYil6PMKNivxAsrzC5LICR8Qch14iAFb5iXliUzau3ipmt21HjTVxFllc53LBH7JWKT6lgbaZ3H
EajkvaBWSitfuUCGxLvuboaIQipXZCE4DdMGHne4m1i/EVUPwgw8mNbw9S0HJcy+iUNjSxGrjuU5
rleUArRcVCb5hdHN/ce9AugYW6rmKcDT8x5M9i+yAmHKBdShSw4XsXeVsq0h0qciFnb5pXqJNGOU
+4jBx45gopOio5AHOVRa+QVUtmD9o36CpcNfALTUdCvSHZtQVayIAx45jFKm1F/iLzTzL8dMsy5Z
aipA4MJc067lxTruGoDRjMfzBThTuaIZGh48wOhcIKxiK07rEYmw3VqhtUGcVKUjwzfwygylDtpD
3UKCUwFLijFAxgob3wSm9XU3vBuiJiS6ep7uAdTLUjGruFhoXvhE/r3UJ2LOzYAQN8VA6uwhBXV1
VS3AAxrqF6z1YxlWxYwBzBhWymeNAnMUSF9SuFJfllmvT5j+W+Iug2CpwEwZkvKpCrrkY1HpqPxr
uEUxWUFc5Gig1awZ8Fxei1VVKJGX2vuachqKRKcqNGChXoLGZDg+CMlKaCQ6qVhxKreMs0IAGlik
rLhH4ubAAKGz9y4ovsIFw4wqgkL7QUh+yXBSihS5WKlIj0znEL5SCpIeQiXItUy7myDa8xac3XEJ
Dioo4cGyo8RPAMUPBQ/icjvg8IkoESEx3FHTKZkDmfBAJMay0ziW1hvAucO2X+CKznKf3LBXI2hF
CsIl+5why4jkUeEdGhINTCRGHb8y6FBiEEYWIocggPx9R6uk5ruH1hftE7AWa14iIK1Kb7jgbFwl
A5pY7b0eYUtGwW6iofW9aEPQr5uxMl/K8/UVBXR0hFBnjzA1D2imhzc4MR6WVoVSlYAxHwRXxbzs
SvEGgwDB7DOQsQSXP1CYta6iPBxDG7DuQwpLASw31Wh918RtSWjV1nxFEw2dF5F5RUqBLPEef9io
cSIurnraJyk5v4ghWTRrNMgyoeFi3ej4gosF1TsahEDzKA4S3AmgO5e6KCDliLQqiX6kpfS4xWtw
OivMLaHc7gqMbDV5YE3gNCWnonEhh/Zwcq7Zr5Sc6jGha3EgYbbTMSnjOxKwdXLCT2Of+EQckWpH
p1k5gUJu/MvdX3EW9qJQ+JpOV1HKK1B93uLaJBs/hE1pXqWQv4jVeK8yzBt5IKwYFXryTJa3mLYh
+Ucw1V/uZxVvmWa9wytl1DstwxSihp8wgX48S7BjzFbmCz3Lkpa8TYH2wVNWXYbJXFw6SoQU1AgO
/Ms0vUdK8RARLPNQFU59Q4HHqI+vCpcIlQko2+HqDnRHKhHbeeyGgK0csR1eOogPJUaAKDcjcMlN
caaXeIBTjIuETlzjMo0WoaUPmNbhXIyzt8RL2YwpT9QWsUVFEWwy7bzUWAtuAPB8RUlbOZeIwg2P
6gsXAou7YAvc4JXVlTfB8ygFxTiItLyYWU3TEBek5EuG3fmcg67h/QTsok5KjtVxo8E9JLAsq+GX
yPMGRFpt+IEG6HniGwpl5CCrK5fDCjZVdJUKB2X1EfQmKSXBQrp4gwLDmW3ZWKZ/7YtxLYYkLDgQ
x2dVsaL2p3HuK6g4oKvFRMcrkbC1XYdJrThRkMLCrfcejGZTLgK+h4fMPAXinMbcZe7+ING9HlHD
WMAr/wBzGU5qmVUMvJbYqmrnVbMnAeMmAq/KxCqtvmENIJ5lNl+WFilXLFC14lovR1OBOG/S49hx
rriErSJQqOoVZQlJcI2JTQuboycYfx/ETT03TKig5Dl8w2CMHghri9LsgTFdByQRAtqpSMAeWSkb
6eSdRNcpIXCeOSLjG0HEHoNH9IwK7OC0jEgNsGosob9XmMKoIeRN7NYBHxOmrxBfU122NFvEcDRw
cS+pkxtolkQHTLTq6HlMh4alXgl4jgOA8Soxdqd3EHBg7rItMmih+8hGLWscrMdgWr7VLwAKmzAf
RsiuquLEAWAsmuDB4P8AYSQgC1xrAwuO/lpgOt8EexUtHdbMK7IBjEs9F9XMZR1TiCJwNaHMIgVX
0tFH7jGyoFAXUCUleoYuQSW/ggK6YtKL4qGVkb06YsO4F5Nm/tIrcgTKNYgnfcivmWYWeDEA1oNI
dzfgKY33uvC+qnHwGniJKDQYdVAt5JUr18yhXiNoEBzx3GfaX0L6YsXxm71EWknZrUJtYXexw7Bw
TUp+UWAytK9DuClHcIV4rqOCxzsajSapA5biKDo39lFD1RUdggHTiDknQHRjg0ri3vI3gEJW1cyU
UUXl+I99EV9nRpzB0QwcFJmxqPwKukEQYRCtefqO4TSric8xapRxgE5fEIwG0COFS26Lrqj5lJN2
uEo7sY+cDA0qe/lccvRH7ubq+n3KxH6SH8SqZWFEQ7jAwn0Wbv6hZglll/ZDQLA77MYNmEo6SI/Y
Q1doJ+5fQW5oKsyHuFCqlfewA9wQAbabjjDcOVxFxQAFDA+5o8AcbypsiJc/H7lKNDsDxZlxByfP
EIMpkmaHXqOOO4aBKBU+EMAfFtMytYxYofdypQF0UWcFm2hv1FqC7Ve3MZ6TghcqCdAwf76jHLGy
BoXKQdkFFg0EeAcrCr6PiONrVtpzTG+ea3WNX0xRbwzQyw6A8+YWjjBLZ08xEKoZq3bfNfqIpUJr
8/MyJrVjjKIQO6sWc/iUOpHHp3BJuljx18MFA0jXF+IeQLErxleIctwWLjj6gZ1KeCDkYHE1bkYG
ATW38RRfBO51MXLi0L+ZdkR+IVe0VUa8xmhjkDNwyXpIgLxl1Kr0m6j7hyTlip6+YWmnXIqALI4j
Aioca5mAprySlyvxBhdSnLLOyUtBtjCC0tSx8xKmK9/Ep1L2UCLnUt7hBXxOkZQnZ5jB3ZFfluEb
sFA/dS91V8okjtL2JQDVwCEt4uVyVKUXxUGctegirpre4HrfcsOH4hJ5uVdOETqq7igqPep6Jfka
4gLOxCyLfcS0pfmV0O3ESgIPcOQwr0zJQoG29IUBAriC8VgylrLqLG3ngi0I0cxUK/UoRtqWkeU7
iK1d+Eezy9RaVhXfmA1Tg8SwAceYoBbGsy/UoVwtl6lqUFCwm+EJNrY4TN4vMNasrZlEsXhiJLYF
vxLc4LJrQV5lt3WZkCDkiN1vPmXBsNH8Ru4BXxh/kdsvh9QAgu60DHKUOueICoXni4tYxRwEQodD
3OttUrWFRR4nAR9g8sB4iSJT3YxWVKp8WQ7IwqxIKDQHPxKlxtT/AN9RJl4d9wEU5IvRXRHoY8xQ
hx5ZwqjpikY6uWgMPMpYC31GbYPUDHNRUx6l2wUfMv7wIvqG2YWnqBDJpfi2KlVlThMaHUA3JSl6
jZ6IYNoSvHqOg5x6CJPLtL7hNhANs5DR+V8xBo2Jecw4EYEIpp+L1EE70OtL/mGEIKMDYQeHk4Ip
AEQW81xKcSA6Nhzypb48xzz5YC4mBe1cAQypxBQJvGN4LHuL0412nzCTxp90PqmKjgfgjlrwJB2K
pYWt9SqeocAXxHQktxhwV2HO9x/Ws7443+4l81BKeoSQ0C18xtYtKj9Rnlhp4YRh5UlBHQPZjEY3
jkbNnIUCflldg6qP/mGztBo8TgUYt7Pe2HjzEa7WgTqSQLCHAarODyRKeDkoHxyd2+ozqpC/UJCj
Lo2mVX0+PP8A5ioMGHVeiEss9Vh5d+4ao0Wd5+5cPkm+F4jgYKVKrvPcfYtZOXIc2YvZrf5gaBdu
mfMDNdXuK+Muj6Jcdix4wlaO2ssldcYUckBLgUd0QVlFTUALcZ7TSqjuEO/iO4piuvmEa6St8alk
g7aa8yla05gAtA74jSqDN1WKMg3WcsWN0DzRWjiXTYMxcKH5IRu6vA3UwKN2p1xGsc98F4nfGN+E
QHKUJ82wte1UOR8QJbEL+IlYcKrXbfzUsb3N50TFYgHxk4fbfpCxCRg9QRTzL4UTiAbs4Gv/ACVP
jWYFWwyvAQydePEHbCQW1vXmHCNl5VivvWVKOQiyu4iQhbJfqLo7cHLHpv5QQ3Qm/EWC6koLcIan
c2Nu4YQDoxzxeS8EMSni5SzBunXMIQFWBZniIpTUfubTt2hYEMeSqCx6awi6gluLtX5ieAdrbi5O
nHJ0w2tifU4/6DVaibdENUZAFigKgeS+GH6IgKFOd9xuJrQwe/mdgOyDefMCfW7vhZH6yH4qc9ra
N0V9SxoSSummImSw4bVw2nHBGv0sg9la0FOH4lVvudXy+PmDw39KvkhUyVXnzXlf1NaC4cO3leIT
mhDd1vWMKNlW8E/uEABccBVWxxYSpQKd14l08WV1zH2sLCBKtBEqzIgW62Auue2aQoVLVwBSqzuM
CAHCYKCyKI7XTLLZcW3ceQ4QojDzLWLyI6BKO5UDPbLBXXqVhdMF8FLuDgaxAq6YRFI+Yj3VHmHn
mUoEDheGolrMClHxBSDRF1Y+ZWQ2mS1Wt5AAK68y4S/icSIV+IWL5250EBaXraio4P3HnFXEauqj
vo3ZVozxOARCtndy7V4QeVPUBV3BEXLdxCOiAD1CxuDLD2PHqcAtvNyr3wPMsJV8uIjgo3zFamvb
uI8u13LwIA6v3KK68EqNKzYS1XzLsAWeYTB9ktA9yzSl8xvKz4l0Aq58QDwSqhpwaiBK2LwNZem2
XGgGo2o53Y4VoYmhAsnLupXwdSgXWT5S7aFGxxG+ZYo+cD7UdRIFJyqQ8h7hhQPgiv5CDR8HcVul
dMsRThKvLE1l5TC1gs/ECEDR6hPU2jxaEpM4PC7aHuJsLJvuKt1F18IGzYJeSUivqVMoAPEabVQv
kyXW0EswHkGtOYzmCVimosFa2yVQcsWFauVChaCCYFSi1W8yw069SkeduGxXyCcyZ7lI3bURpLM4
hIH7ltrQwPcqdGg/UWRMsNgy4wK52BD5Uax3BR1OctqM0o2pKC6FmVGANoc1FijWvcoCrR3LhYT9
EH3XX9xvKoPxsUdY29mNwogvoIgUAonJEJVCd9QaIwEAdKNj5QrMoh6Rd23RsgVkIH3Ut74C5L5n
LUBXIYeR5rrbnAHuI4ApPjghDpDhqU67l0b9SjJKoCdypyrC7wtR6BisgikMWYHfpFi1y+rZSI3p
PNZLEakLx7glKOvDSoKWtQUvll8h3PMrB2q8ax+FKKsbmwO4Ki0MiW3CECTZVXm6iQjF0LmPsLsh
qIpJSX8Qe1axHj6mwWoqpsMWtC9c3/EIzA0em+YCwaC8MyLTNReDcOlkE+QhKaxRmEehNKIYSlI4
W1iZBC+U6lQuNABXPzG/YWJarESNEIUXh5Cg/qCmdQzzSEoftDfmJi/cCiqoDl3iPETR9ABBDzb6
bLxjYHpCv4lz01fhqZXFMi+xcoWu2QnR3ZB1D54tqFXMgVGYt6hACAIZVSBxBsKRD5u/6m1XheC5
lUYO9lAwKy7a4lXwAGvMVuJ/gB/NyoPik51v9QVVc46HmKYpBfV7/ccaxtP1KdFnrCP9QIdpt+Ml
wy5Vraf5MpOcj4hI8lVLeLfNR7peU8rl4+QE8wBDzDsxeRaj+mNtow3VpEACSd9ojwoHuNmex6m8
lIBuxkhKlfqFzYtxpzqxAZgV9L7PiOwPQmHojIVG4DoHxOW1laTvYdNvX6Gh8yjuS3jbM9wPBT92
VFFYAXt0X8Fw4SoqagbOPBEPfuDiiCtivTBC4WPQ9zehfzbR/cxWW1L5XIZVLM031hyTkHiiNbdx
jlFUBl7+J0fDgDjnUR6wgOMZviccWnqZiqNLd+PmE0B1NcLLgW9VFXdJxsUYEsBBEbQK/cH3bSbQ
4/cxIFrb2uicbeBtvLXx3CZELHgtxVK1aELdNQdE9a0xh6VitFX7mPPhfBq/HMV7pK4H/wAlzc1a
NvH0o3xkXQQ8hY031CCo3FagNXHU2WdVEFV0hQLl1vjmBsPcE7dQ1ZFV6lnVE2cUZBAH4Tau+pSC
uTqWtDriKPJQQiUWm7HpGMI5twi0HghQNbxRxACT6iLiwrbo8QvN6cxKHm+5YUq4GCDFq6mXaFQ2
tm5BKXsLlDLHAXx5hR1ddeo9D0R0chg0V0ljtniCv6pn0KgA05Y9x5dqKYF7PHfiIjfJG5OuowKq
EVdUIFVdtQSBymp8A7iFNZ1KO76gsruPg2FjwCUmjxLez3FKOX4miq4gTWbktppyN2meWXYDEivL
JpVlQtGjxLIUHNiYMYJYKHTDHaKhpLI9dR2k1c6wPmJacU6ilZFCO+4Sh2ZzBdGhzBNHDuw9GipR
5RhnfFTUtY+iYTWrgk0aQiIcMCCMkQNN1gsRVP6hKq14YltWHxOPAI11HAbLU8Mr1jIn8o5KpR87
4g4aiPliRtXTVobsPb6noK6/Cc2wa5uop/S6o/NwLXCwt3GtWlp425Q8oq8GS2OupBjNRVQhKHKE
dJKgjp7gzcutRC06ZLeO5Q6kcLnHCnU0OAQFMDj8h5lABciUBRMJ2QoMCPHqCvBAFOa2PmiaN1UK
45t8RwxeQuSqs+rBmh1AI5H5lRrdEyyyo5PuIYA1s1Zk1dwK9xH04goWfMallukyGm3EHRcqAlkD
TtXsGYSgI/3LU4PxCZPaEWyuSOQ2gN+FwaKiKc1ce0+AlQw7iyRLRARfmBNsKsZnewt55AwcChyl
/Mo4S0QqBGpLs/uaGq5C3UpyLNZbUITc2r8pUXTAz5cw3u2No8w8g6AI/UalrjrYXde3y5m7uJSh
jbD0FXx6liiC0CamQINuL3d3OO0y5cyp6wuoLgERArURLCghc4EsNiNdsfBgbCyK3RaILfEp0ABq
VOal0ldjGS7wPzS6HrQYhHHOC5lTc7TbPErRtGzvYtGLW5OmH2TqOpblHe4V4liq8UdZKW0wP0Qv
VSrZ8x15YAcWULwYivmYUWAF+uZb602YdThW1dYHQgeZRin5IrdNmC11KoDQYp35jBapGoDBdFeF
YSvJsqu44xTos/8AsTSaQV7IIHGgJv7mdKLkX7l8QB6Dv+JdkUKF5++I4YMdWbEoHQTwTfzHC9Ge
r5/ERG5o0t8zKk802+2X18sU1/UzhMDH5gNXQmAygKJS0nvIGu4C8CXAVrUcnBcJQ1s3d19wf1Ao
D+GMcCgpnP8ANouuBFV5HHWQIuORqDcSWFc9y1INXbhyRFfED/krnzgj8saPCbsU/wAi4NSDVpf6
jH0eQCnrJaT0bXZMeqIfvbK2uuomxAm0en1O+KQNZ9wJMHriPKGtc3sMKjw+fMo4TQXcKpjjkwW7
0acRWhq5B2/cqMXDHoZaYNGUl7fu5m5VozHNRAL5tsfJ1Kxe806+kmUlxch7bldHSV+B5Ide74GJ
HbEqnR6g6tW4oGwfUSj/AGbsQUPxy8nHgnvnJGlcRN7AbDy9ES6bigXe3ysoxoKmMeeI4JPkUC+G
XuA0Hsd4i1YoUA/+JWjj85YSHGwl+U4UVrw9SzFAelNb3OzYCpz4h4MaQ187HI5KtK6i2VW3yy76
jxRy9g8ekUPARaTruZhqV9ofFxGpjLF1dZG5gSi+18wQ53x1KLTWAtey4VJd08MEVNs6hS/J2adJ
oK7NrouWZdPFywA2rOFq3qbVoe0avLJSK36hFarsYDV27sAWUvEuI2GZnC+IgNrR46gHJwXZBGFF
HYCcGPaAu8Y6SXeM5wogdi80yiC6eoje/uBQ2t6wWE45uZOFuLCuYXVHfM+cOotQlg1s4By4TmNs
KnmMWu96gf0OZWOBEAPK/qVTDr3MyV9yoLAD/cqpTnxFlo0QtzeEaVwHMpsxO2IKrkgKBAVS4TWs
6GDaPuUeLY1adws+PMEDXpL42x1URsRDzGtCPVxrhteVhULtdThX/E4ryoVRB7IoXyQbfL3F8Ndh
LvTnmHRW7ARbey7S+Al+kLkaYkvVvDZQY88+YK0BT3Ea03TcKWCp+I1LnTiJFRvUawiI69e5R8Fe
vqaQu/UuoVnz6neq+I+5Rsp9Eh4JVJnxAVsjY6MCL0olRgTEuN3gAk9qZxfmN2zlP4R9hqWKKDgc
R5OVNcfiWOvpqEQ/MlQtvshsZvMUK8Pc5oWkHwPMJ4URDBXuDFaL7myqogG8HmjiWfbxMNrp4jRI
rtPiIohf8RhImvJfWE5TUuqQ7p2Jhd8TwvnniKYM3zAb03rfzNzs75ZeHjiPV0KuAC01Y7fxAgWC
1xb5QaSE6nhbKVP87kqyHHaGwl8nmA0XtGj3L1cOVNv1hWhG321ILbC6/lbFDnYV+ZXih6tEA/qU
GXA3kRH5jD4bSlqGXz7Fg0rzCUT6XQjoIaFkXrHNrgZHtURqALtkRXO3UD6PdxiFJzAFJpg8JVgi
xTQtEh1ipzbnxOpDaj+oG6IEdXzDNuRgVA0oDuXX5gpOctYy7saYDKiwLR1aIZoHvWLlA8rY4NKX
SUjZSriaIq6QagyrA21ZqBW9Q0vO6w/EopHlbyXYi8VF3I5VHJA7vamxgvbAR2/EUFfWRIO8IVXC
CV3HMdIPUQZb5lraZqFfrzK4SWlcwqJY0RwpfMRxvHkyG5NTVNAs4qPZ78fEMHkF0QqaKOOJcgEC
WVYHR0MiACpi4qHlbBKUF3yJS6CuKgum7OIPbUbFC1OHXkZUYwD1XEJDsBWwQySEAozkiRWl8Tq4
JZC2yz8RMjoQHhR5lu580B8xaiihCOdy8P8A0gTtwO49MQNVSaMTVq9IFD4hSndRPUg5XTrJVHFK
LWuoe9Sg/aBbtvD7nAtX1LiAvipWas4CMbA7cfEQohSSWDhdrmKC9OSsoHkQ1vh2cQQhMAaytWBW
3mXwtyCkTqYaJfRbBAB9pPxKR7Ua/udBmyyIYUEUQXwuoDKmKdmCNQXs54jIVxWqltWg9RnOH8Sh
AL9SusW3fEUH1B0ErZU4j8ReI+lFxy6idEoCK7sp1XxVzbWZaiQMF2eLg6xcsS4TcVrlvR5OdcNb
doPvBq6z3sq3oLAnxECW+BufeQPGacJ0D7ic1Scs6ycjKzEv4O+SVKnBNC7+II7qWN/zEmOB1JVa
mu1CxwPBHgg1KnkSyy5u6UViWFLviyWBRW+O4FV8cgQG1rnPlXmGBLPE4N71MAu2RIBxVtRNUaJf
c2ynkX8QWa+RG4rtkty7g3W8hVTo+YATalDSY4SAjyp3LBtDmDpfPVRU9TuIgKSg058RoUrbiWy7
PFyhOB3cbbKTiaLOoGq1apZEX3xK2Xe9R8AlCjSBFaMOGuIQ9GDBZnUqxFqqgdNoyl79kJEWvcNG
pcsrXZY4bGLQqVw0Xlxtt5yAt8KlX+RStPyItDqmccynRui0JqY8IAnbEBXJ6haDXicRIsoT5lIu
XFuhqkLHkdQ0a1C4AaLPMtSLXmW8wbL4jfGuxPP/ACNmwLl12u47B48kSFcd1AUrnqUBnVwyhyFB
hDM8VEQgj5iZXRrFHKWjG6rgHGy4cV4ZxC+A8QGqgOIfhqgPcfpTkmVFvR3wlErl8Q1Wqirs3lfI
L5YxFhwt9iV92NCXB2mr7lSGe4NRaCHMbjBnL0wZdAsybELx4howhpbS6YpgCvEEF8orht8wVZw4
gCp1jqGEotdhAwso4fqO1uXxLsT8hcPdi3q4yuDwGQzxYDz7lAGdDHFi6AzmVEVmfMOtKqwsYOFF
owxxbnDjCVanFbC8hUBsS6AdZDXkzXcaATXSVQltrlHlCWDWBHuNNcxtnPCz1cPNDwF3KFtsRv1D
6Uto6gfoUDmW26XIkEAr7i2moGv/AJEW0hgA+o6yrq5LlECCgDEKXD2406htNEdvSKPLioHqagUs
+pRr5IITxQQPTYkZG1hIjweQj7GcKRa8vMQmpjVL8QKMO4bnj6pVbMWqq24jbF8y7CyhSO2IidEI
84aGqS5wyPCSxriAQ49Q5MvTg5BFIqjYl1pAujQ2bk1dSYyEI04Cnq46dkSjTU0P2uiMdNPxKUwA
QRhNH4x/+QUAERhZcCyVrGaBZLXaBR1PSRDoCC2tsquImuBssYss2EquyYLfV9jQGdwQczSVs65O
tK9EOkUKaYiBoVvhUviTXwQZNub6GaBLBUZWorxzOZNw4R0EFqkTyPpcFLi7iP8AWOPVVrq9uOv2
YdJDA0nAMI0LJ0s6+4I4vByYkmltqnSaALh5H0iZC6RLKfcqKh6xFJFVTh9RtUroO4udTfYPmIbu
h3+JfwHNnEtKOqE3NdX3D8qR6BzcKhxOnsf8h+XKAU31Mgo2D/3cAeiXl8hR3GnaCy7gceTLoBbJ
UryQ0zWWwmM3pXyuLE9KyoFFBARLr4ItMrIcfMMR3xHLn7Ja/EAWeZSiTtcsPejRsh5vr5mlk13g
4imW04Gxy9mk6gl2LQEXEygYHHACEHLsikxawPdvuJFMLErwe2LyeFo1ZHa0BXBdRX3j4eY2WCgX
nmJXREmNyeL7eGnIYMrkA/LBEMUlLzDMpY3h6/cQpqN2Agute4DDnz7IswAX47TAqNig3bpGqZB7
oLc1LFntjpK/09FdyosDoUQwG/7FS6A1bFaLu4DR2ppfCBNNXSbAbxcWwGPcLjz4jB5Q2A5Fyw48
eYk7TuK255xDwfZEuZSKhuJwSmANSh0LuGijm7uIF7ssbaOoA/1HAXuN2hqIgrIBTnO4FnFbHvdF
8RgxdB2NRZvU01s5BACopiXawyXNhvEVsNPMZVeHSDS6t8RAoanDKxx7qcfi7yNK19wwJnI+JR1t
wOUx4lsn7I21VPqKSq2XSdELXLSK2oq5jaZ1HDFvyRFXfdTsTmFhvNMIob9pULZcVFviFapYygG7
zOm+S4maPl1BR5rdiLrx5jjRw5YLUKDbhj34jgFV68TXhw6hwrqVWcmotFGVUqafSKDvWy4q6dSz
E2pfyyxzKbg1LymBYocMsi/AEOPJoILd7R7eGooAKGhhhdr5lieA5g2ta8Qrlwr31Ap+F4s5wqqX
zBnH8wRp3G3imDQNcsVt8G2D3S9EPKCbGEDiJSpcyCkSJk9WV1KuLLxO4G+ffAsYC5C+2DoVHHmK
Ma9Q2JABXL5m0ipxAu4ITyUICgTalkIPR3ECPIYKNBcnIiUor+JUl0EuohAtRVR01G7rxEiXU3Bq
soOBTP8AIjOzQQCdQwA4u9hM8H8ZxCLnVXaZJBWe7uGXmEquslL21p9wqRCB8pX8Cg7rZc8Wn5I4
JTKNv3O9NYolywv5iYDsOSXqqgh/MaCWaL66j5mgPwl+neFGbH6ZLDYIXv0q0rYSXYrwq92FsopO
h+YZmvpCzsKYPcLOFTrVURQHOmOJUWC9RsOkFZEp7y3mHZfA+clXzWDibvqoDQvZ2kpfmpunxd3P
ASpChI3rbyDMSt8jtiAOJ+6/qZVhsdXDUBPnKfmJ3kKcIWIB9SiVeSGQdBIHCaTZ66XetHcpBp0X
nLH2osIdulOR+o6ilmU0Q1IWadQ8PJrxv+TjMVXc5c4rk7KGJgweIy3CpGYN1UZzptGcx8pUL81C
CAAYHqEFqA+4YD47jbQUG2xSbsWB3ALdlwgDvq52B3FWhYYfBswJS0wLg4pWdp2w9BbwH5iNee6q
usmFoJd4Z+4rNlZeYOtpqZvcYQ/QG3kGCnb77Y6QdNcA6MH86Aq1mfuc9r5p/BHpxsRJjuASkg6R
3jDggwPopqzuVN07+SAMeuahSGty3GClM3imLwZTKBXP5hS66jfma8joelR+oavJ0H3EGkStsmKw
oPEMwqG9PfPEYtYOUHwSoeoYRbc1g52rlwSDRHSpLx1VX6MDylvHV8xcxVUYNj/TESwIbcpBkUzR
B5O4rlXmAPiXplW/+8INigBhT+yoGq7ay3CviVl4gaFGVp3g95Uqoxso0PUThUYA6IsOqHFWr+41
wKzleHxKObKEoDggCWRsZKDQCq1crJaQVfRMyhQH/wAVGyNwjAs39yq8EAujyxg22uUu+X1LVKnw
8BNKZ+SjAM7Q0tDulFPxFG5sAiX3LavPCPpUxURtU4Njc+y0DfI+IkwUpU1t3MEbW9ikAAcBoRbf
6lCHo3RXHb5hHAwcqlL7Sj6D1iuoCTSc+qhos3Ye/wBR0wqm7OoxRVejmIauzgDcIMAlPE5LUZXV
sC1vXzG70QFBymMSENQhdVMBdbC1S3JAR0lAGUQWrtKyAAtUdivE6GQRTl5uWxur8xpFFfERLqNp
8y44mwpiBPRkLh3f6iIqviKhP1EdDYRBu7/qJSk0PHM5B9pdLUHZOAdYh0wVkpvRJdJaVlBywDvP
qDa5eVjcmXA4hQpyrJgt9EEcmqyAU1Yk5m/qYPY5g5eX5YhACuYJnDzAGaVxXcGjfFRXZxlznp+Z
Q5dqrjWWhia3c5U3u4tPolfEF1Z1BYTnCIBGzpKnYUu99wSNhXE15lF5b4olMcHbxEBYxgLt3alL
nJ4lFyBrcW4sK3KOoxKeJUo4GJb3OIhy9yoXkaJ7Y7tU2EUF3UrCKrPQLqe+FALs7kCiXTyJLVsV
2QxUF9RmzmorBjfmALc9ZAmnaeIBxqmEFfyQQgWOI7eSeiMSpauB8Qr7F3mrhE0McH4jVpzWTFBY
L6hC5LUXtt1oH+zodbA9IHhgzeI1S/cWBg4JYmXT+EEl2FuW4aOp4yMpbgeWx2bEleLKlDTb8SgV
k+IiK3bFXQ28VDsmk5lkCq7hKPMQ5ykcpwZZLZqO6rcagA6Cle//ABAt7mQvyn7glVKNGKxKE88T
I5u0YxA2QK6vEWRar8mqqIKxh7IFVNAefmGSwbV8VcIDaVWzkAMdwysQH5ihGo/JL6HTPldMEYYI
8mQ6S3Q/BL1uJ/xE0WNHlAgPYI+51LjQesH4ltTLGFwsBXEyGpmtC9/MCd4LfzHJaF5B9R2vlGWp
/sQsWUYy+pWEV0LWsOwakcQMVpRyFQW9AeWC5L3hkOaXE+ZUafg9QIcKzjZ1QF/iXYV2mC/8RVIF
mV7vr1H62QoxP8hynN8C68ToEaP/ACDJTFCq4ltSOggSyXxCPZppp5/MY2yKS1VxGFJr7r/Y4mlI
9AKqNbOt9uQP3JJo9xkb7BxLGYgD5gCgoHfzERLsfHMTK5SvCQSASrwTYaL0CaEf3HwjIOKFQyHW
BOagt8g445JctNr/AAlFnbP6iZlkKQw7csPLYneo8yl9Ky2p80Og0b3uIgEXKxS74YRb4FWpXhth
WM4g8WxGz8dxRp2WqniUIESX7sS1ieEDrkZG3FRq4WsldV3WMp9WtZmPcI6W/qlByrD7Wf5HZC08
kBaibMlbLSLthpnhbPHrdHq04LfQoVx/E8eKE4Ja3qMqIauWi1VqHVSj5jYFpVP0wTK23b4jfWgV
Zz19yzoVamqKIcGaINMESuQWh53iDIApPcWgUKpERpB/UWSiDspXiILwAihQ0qHHVRvQRDblGsJZ
vrRtBrGLMb1rVV/cBkLu6uj/AKTCltwtcqNmG1BUcl0o2G9eIuVBtOVv9wq0q0/uLvgV7/8AXKet
sSqt/wAlllIz22iAkpFeVWKyMJX5lzmyKDatj5MColIShWr580ytXT74vtJWw2yuBUL5T/5BLhv/
AH6JXqOS7lB6z4m5lm8qg+ZqixL8CP31XPPZ+IXBS3eXK49MsvhekuBHHloXLrnuUe1PiV2Xv/EE
l/AT5gKOEAbb5hd2snxcssOOFrzBYbdLTnB6jhVS3W31LsG/zukAQhs8l8xZ6fp5hdBAJaIWVlqY
sQj6WwnSZt3fE517mlX7mqoERu8iULxYsjz4INqC+JQtGfuDYNXbLr38IoZRZaFtdGXC/tNEWDGD
w9R8AVyQARa8QNjdQUMTENLBrliibp4iGvDwEKbpayEW78yx1T4mOcwQb1zE4FCLq1fzEWwpY+ml
jWglRQA4Y3NK8uYINitwBSlvzEc3VN1KabChVEahIxDa43CbBuSEOzJQ1+4Jlb5i5H7iqNzh0nzE
VR7WQUafC5bRVQUpKqFkOkSco+pyKt6juuSIVNX/ADKLzjU+Era5mDwuJdtOY9iy41Ng7qKeMZyA
ruo8qhNNTojUG/EKJAiVc4Th5gpW6cShC725W2ZxA57qALLy5YLqUMOO/wD8LDzkXtz1GlqQdCYy
rS/r5hEq02yUleeY70A+WJWxPKx7vUSPGmbteLz6jVBsj8RRoBbXTAjJEs1Y95urypD0ULtEzpQf
jYV6MBTHolbddl6E+CBCNc5GNzeCz4ZXQYA7AjzVNxzcorbKz1E9LRzYx6RduUXFGcRafCmAVsW+
ZYqdh6YIAWl33MpMGLlwFRZRTBKOqu4q0tx3CPSQVSwn27MANKrmoQ0eBIqALkYfEIRAclR1IGoR
Brild3AJWe/mZsgaWPfaVnucIzH4hVyKcZEINS0I1zGkVz5hcUloGzNirqoivmjN20IdGCluL6nE
lEPAkTtI0nKBZmBF4gMA97Vz/hTymECHa4j6LURZMbxCmwUOV7Ira7WIK+Eh3IDG1sMFIUW1WQkM
qaCtf9IK4QSypVyU1MS7gNxKclEMSS7G3xB7LqXy9ykgIAVbKhbCnnLcxSnLpB3cGcmr+yBZ10qs
YxcEkhwsLEA3i4RFgMNXEHvJbXIwqhA2m31VwgRGwUOxnUUI84cQBh7wO1A0y2WzlWC4irVk4beI
cdwYyBs44ZmvsHzsMdU9uqYc608db/cc+5BrHEC35pBbyX3DBmCtp8v+REfNdMCD1RypgDLto9f8
ndHUvrRiLGKyyKXNhmhVqq2KULzoXBSMnUPtCPDYYUt1rjyW8Vyjl+NCtuGLcFHJ1LzKB0fFwdIY
UAA7i/4dWu/3Hgb4dw1H1K4LcljaqIWuL8+pmH93hXMvb+XOrKGSraAtMI5TjQHTc3WFXrKh5tuO
pizFv9j2SEKldkFSuA0cR0rcYa8M69zbUXdXLqVvCuKV8EWyh26ggOPUJtkuouri0SFobO4YIRaF
iV+cnOncUcfMPz0woqm9ipFaUAUrf1MvsIPx/cBtVpTwCUZN09G6uPxoRbKYHfHt1a/niaCyBpDy
wiZMRKUqC/NpERDVUoaN1nnqC0XJAHhAYE3umrq1+ZwuIB4OpZDMsAkFl4f+2U9J8XJ/xMY+EDNs
KoZMVA4mPP3gR7jNGIxXhPzKGCNhrn+44vqEqbUNw7rdynjYgaSw2NIWJdCrm/5lw4hWEOnqIupD
tTgDhiVbFLYX5o9xiARHkhmgA/zBeD1KyHmbvhsqxt212f8AzCRkKBFLVfMQdjmAPSErSECPk9S0
dlAq2NspNgjHcwHHly2gvqKRKw2zHS5QD6HZHqB76VhZbupURbTuGMizZ4pvk4iQ220oHHMPzoYy
vp7yVJhL6Nz6StEBKg5I6dbrDwVf4iMEeoXmDyTh3kVC8IWsPuWWfEh2hquKmxW13KG1WceoKBzu
50dLzHLaKqCI+HEK057leDk0C6PEaC1C7gCcQ8uRFUCo92A+2IX5aqdFRXUVbFHiaLeXgjcKNw4r
pxctYdepdOZKqFHqUU4eWJbjWwEbw+ZpYlSwoWvcdK/cQF3vM4K4owrLm0vN2XYG64ZtW3OZe5TS
F1XbMMT4IYhjh7I2dPLKpABdPBUbWg8XKxrb4JQWM9waUq1eolIrGWNb4mS3T+IIFdwlCD2wBrUX
qco9GTqP3BQNPcLo45zuaK78+IqxZlppW8KjRXrL0TGtIEAiEHvuGRtHblpYGLQhzs3x56vXuPvX
yncK059xtT3LsTs5nrQkpsDxCFqJYCxcL5jYBsayoNOVEHNrFbNfcRC+1R3PBgQC8h2bfx1GyVzk
KlKK1Crp5hS0KO51LxJKThxNL24T5l9YheSclIiY1AremSsnZdMuYTdB4j6pStOfcsORpVpjoGxo
lyyu65o8ZCi6UCr/ABHPmjfMV7EbUG9MI6qqHxEGnh8EVYHHRKIF3KjTy7GRTYsFsPJVKljR6Rcc
WrIMp0cue4hsDs5jy1TQNJc2u8fEeipvu9wHs0WLb8svss81xMOSq1D8XEh8R56iegC6aPkjY0A0
KD5i3p9QfzHIi1PCC+lAJ8bGZRTkPnYI9Ka4dvYzsQDBdfcr/wCwt/mYilI5WGzsPFkUDK4FH8wZ
LiieCPjCPCvzLcUOQd/cFCp0Ql2s2vH4mYAV/wCmeXUlPt2c5Iu3FMBXB+hBexVXQkXTOiuXBAaK
b1CK8/Is1r7od8xOQVTwsMitYKRdSXRaoFOpCF+cgPEuqsMzAyLVR+oMYqy+PzBKIVoL/UrPysHy
qXNIEb2eC4JEqBtfzHKV4oUg6xMGDCpVQsWvsh22fAPyEuDJXMt/NJ99XEUA3fn9QqloClsD/wBp
bZ4FzGMT4DdhNL7lqHuE6LgEz1Kn3tvbATYr1EC7yNNyKkkpsjq04Y3PT4loaLyoKUfqJeWA0oUA
yV+o4CqA2XvmYNE51cQv8it/zFqb8l/zG6B6C3OTqjyfU1kkLeIjXntQDtUvMNWY4tkc4l3iv+x0
TCipVFXZBEmhFOj5h9LbSnmC2FV4onn0CaEQm7XtgBC97nbLjQlhUirjhtp9NdNaOYECYIHstJf1
vlik2wKZxBszxGvcDNJjxgIjIXoSKTdoOXb/ALD0Hb246BDa5LaUAwJ7iFN0LUEWPxJoHnuX9V7K
zIJUYA1xeEZ6o8kuP+rOZoLru19woN06q9VGH4tTT7Y0U9uwr+YcBPJBfuWIY2jUvmONo6j/ANi0
ocGX+5zPkW+zM4NORXOSlwsNKG76fzAyr7tr/MRrBSNHprEQVsTja5hVG8Bh654l287tf8xfBbLm
83Ei3US35i44tKuMJSVOfeEB+ELqhVXr+YFqDU19yrxHsAgvLTdWBTzVhL7d7RbfM8WyI4npGsK2
udw2nHlQZaOW3wqOeIAK8OwQ9eBAvTwxgke2rnlAaBRGXGj5TqC0Jbsj9ziDwdQEgs7uYYHzDtyE
IOM5wUEYgnPESd9lHLdoo6jAHnIRHG6TdTGJVdD/ADMADf1OXrtIwVy5OCkZHrxDWaJZq2nwSgG+
ZZ3LJxeTKiaPFeIiT8US0U4c1BGewlaNyJBG+4k0Xf6hHCvuUEUUYIKDl7lFDqeQtl+mxXPUANmE
EFJaZOwNXKVx8xdJp3ACmrFtVvbGrOfEVSLtqbDeSoRVcVEaLlcQs43JwOSdkoKafiLFl/iUF/MF
btXMa1tIVxC2F7hsS/uV8GS7BvYrydawmgOZsXk7ly1A7hnLKnAGlLuUeSsiAbbyxWgLN5cTmC8C
oejWGiXRKNPqKEjO7i2XxzksEBLZTJVR0FlvLE0HeUdAlOmAsoAjVQaAW7w5JcoGrROprdC9eo/H
eICAfMwKU3U4FtPD5g3CBzbMXOHQf7Qy2hyZ8fMUXnQjhSlXiXgoLt4QspvKCAN5eWJahWd1xNqW
eG0oZgZRzGdBEhLqMcZxC9FWA5j2qnKqI0eV3UFUtIzROZbdzoR8fEWdEKpSjuUKnRgXj9EVd+px
NFs4gbAqIobqHfFRXDOtB2RlPcoeBY5+uoYUq1hN3/bhCWUBUIWt8EaWDaxtQGa2ge4KrYoCLzJy
wMCGWlVAutMbAPxG3/Etzq7nBDL1QwuKxBFDjKOLMAl7AJYHMGE+glRkrYP7yqFUBHOJlg2dAx5X
tUJvg8cEaV7bxKhLpjC2ZReym3of0e4OarSV3KSwtVD4JWnQXSyOE3ePENcdhy8RMtOWg8TEEGkA
6StBN4lb+QtjPpV3TslgpuhEQvjQo+vMY7UMMiFYl8kVFUl5A9sVVE0HH6g9QXmRYqlXm+3r5hNK
cDsT2o4HcbB01r9zNppfJXkg6DjZTbRToQfTuU/5HiAQmXIgpGKt86WzWwVdSrptdMwP5YPmH0X1
OT/sFBiLWuCpqpxD2IMoN2V0wkDsF9RcGo5GZ+YVihPL39y4zfN/uAFVV4X+wPfZrj8xPMo9O+Y6
060vB5qYmSuR6WF3CDbQB9vcRXQ+OLmRwZrzNtF5yAQBfGdRk6AXxcGSoDpT8QdrGopVHEEClS6l
TvlUsCVkw7oOYC0x4oQX65XpOM0pW6HqKEJgK39TncAFd+Y4I7Xsc1EtHXMJHvLBZ8E5sN5IIC3T
mxgBRcnmN45XMsEdwV91ALK8F8DzKJ+gHV4S8AAHiFCVviP8yaNnFFrATQD3J6Dh9wp4S6BdYSpl
tIVREUV4NRRUV3HaBXuCNS831CYaRhUZd1LpV4pzDpa3MPAd8b8yw0gCciH6gpHJKgizmEyVeHuW
OpRrGCAeiI1+rOImPoEI5nU6CSOEZBA6XBrHHU4htNq5WW12eJlOmVv8QJeHqUd2oKDygGCkSvvY
fItXD1sGSaIWaai6vO1KYm+GLBpfKS66HzCWsXCRXfMC3UniENVSIeH3EHQ+Yj2HmEtuTADWAK2p
uyK8RF6T1UCMbsma7V4qHDBB9xCi35Q28niNF6iwGryslQi1Gq3TUsfKbD+VlinlBG2wWr3qIK/S
IUvYFJwqIhHLgiox5uXQvRKBTnmBo2XwRn4LwRkL5Oos5A7WLYIc6ZZFduOgnHcWy6fE4C7uUEuu
5bQFb8QAF7bqY4YtFaJ1KaW/cuRV25ITdVYQBmGcMgHUpUjfqAXoixu1DuqajScPKMQ2+WLadsoB
pdS9yCHmHZbJwro5mAd5GsXks807lr57hwHN4+IF1qlZxEOjalhXB5gUc2w5Iq9yWKfcqwGpa0fm
Xivi2Dis7ll0nxGt8W8hOTpcYpQW2iW2Gg4I1oF0+Jb5S1aaA6gpuvFQFjO1eIGit1lCNreMK2by
M4jaKbuIAx5JUGG89x7MYY8TlIQCKVlcSyu6BxkJGOgGW5YlNpZOoZUnM89zJdIVKLVBfaUhoo6S
lAt86h8E+ETItBGEchujCNEUG6l29+mK+4jKe0CU3Qph7iLyRuOGXKwqInWGlnKDPEuThnJB3Avi
5V3NXFAYqNqLxxGsbp6joWL7gMYTQhcVhI6DkaGt86vqGUNcAlZxIr4CIbjooSHUNiqqnHuU+Jee
cjSRMtOIJLsf5kSKwdldVLUtCFIKEKrt7gx0luw0QSfAD+kWqMq+eJys18e4AoDoqggRfD4bGsjt
MW+4HrhKnnkhebFU4K4j3DtgPpMT2BNXbDqi963MoxMA6j+uN1UtSfkluNrWcIuLnEBfA9wNRiaA
QE21DtqY6PeDU2sIsNq8v1GetCmkfEXCmD1NsbOuL4h45eCcxVckEdtj7lJsLX3UexLvuvENKavT
QwVyATAIps9FFTb1AnXZKa7GTxaw6ZAZG8RmKtbwWe6wea2ow0WFcflnVUuvBcT1RS2GwJbC46SG
rC7zguUG4VL8cQEIAdm5VTaFhkJJs1bcr4SlQnzCNlW0LuWiY5nEeohYLR9TlUQSryCxTa6r9ypB
fcbzIpUNUq/cYnbxBSJXo67nc88wqxeI1FIdMCGJUqpdA/tsoBK0A16lyWgciUUAQ6e4a2k3bxzK
2M1DhhF0MxLXGytSYJVU8SumViAPSEcxqfQGL0awB13LAgE0X6i/CcqZsEXiRIaLO3L+yFq3L6g+
YRYP1i4APLp+5jAUhV7WStM91Larb89SsdC+zOPuZYOye3iWHAwx9B7iWnWpIGBo4va35hYwBYV8
/EGOPO34qPTYixbgA73Ak6qC0Ug5ttg2tYBwl8eYVq6miiWW2ArieiVMjuuXvn5jmwW+thiR1IAU
UfuFchVVrxr6i0GYb8QGqs0FldEbbrFsBcWRoJsKOJqgQloBzGIicNrv5nLg4XHcj9sK0KD3fMpn
BDVgIqXQqvgP4iDa2XXXqYlrNIYxI8D8OZTLQKrHn8wD4oMymEEdebRV9fUB8Ey0PEXMTRaeDxFY
XYVjUblK04zi75gXj7gIDTKMPeiz5uLONTUHwxITgJjwXAxLAai/iYpFKvF3z8zEToHyrUXXRFKd
iAGtPMFIR4HEbAWkHi7PLphPksAuLSXcNMqY2puXyqrZZS+SioUzs8yie5yNZWlK7i68nUsDx4RD
2Io5tL7lnlV9RgSiJJiHKIDzfUol4eYHwTI5JZkq+Wb3HHr7lgTg5ljgeoguDwxDay+4KhWHxKG1
lckABsV+5RFHEU61UNjl3OBKtFBrUsuV4qDy9EYPNHMfz8kCFUeZSjdDxGC1FcJupR7hNw/EyJbb
uEAxbkgwNlxFeS+IkNl9XOxy9RJXiAQ3jzAYab5iAtLl5fQiFUjZnmcAW8SgbLSU4Rv3EYc8ZC1P
C4BHx6iAXnc8evM1SVXaRsWGuJeKaiigtsY95IqCi6jjml1DG1QkorO5Qt4ofmuIlVOsooVkJRSd
hDKqhVRAnJcynlEFBwcwaLSeoD3XzCtHDKIKxzM7j34l1PtqTaF8VBtH2gCHFtfE+YOKnLW0B5d4
hdqgF83OXaxTxcPKoFl8FUNS4RvURYUYv3GlWYr1LeArnxGZKxcqDCB5gV68ckN18jhAUbqONcxj
waC+ZxIEU8o7Q8oKpj1CKqYQ6wXLKKI4YCVyZArfyjw8GyoPYckJars0lHEF+LTfUZuq4PiLQEAv
zKW2rB+otK1UoARdvEOJoochwQSNJsVcEhLAhXzGlt0Mqate8dltmCHl3LtsMfNQIqaB4dlV4xbA
uGSARd53HY7B5yK75qHu7gX0UeR3L0UXPN1xCpAFHu4OIQpzb6lk3PKPkJcxt43BK+aKHjYg94Ah
KyFDPL3KYm8Dhd1A4m8Io8e4IEJQUFeJ4xIgr4lT6gcuuYvCnX3CJsoHus/qDdmR4Dq51rWqLA3W
rU8RNs0C4dBMEXdynhcD7jWfZHMYLfvo+InLiZCcGLK56SqvJ4g/2AyBhm6AfUQhqNmPMoacsN9B
B+yBOtfS7EjnThNatoX8v+S2wKLdytZtlbCVq02g53sOtGsxr9x9ixUm/wD2IJryPyTB1Cqg9EPH
gHBt6m8lxShPUpJLElTXv9YiSxX9GVt7ZL8yxXfLAoG2WvTzMOCsQY2XRShzLFtohVNfUs0pQfDm
Ahhe9FJ0g0dJz88RA0VVY5k+iOa9QuBbG86lKaC/aI+OU81b+4FYA4JXmN+8l4xjJqS+1wzcDzlH
LUGnHxUIS0oODchUsDJZLMlBILoN9DLMlJXRUivGcUp0V3HWQlUU8fxE6g6lUSiFPVDSsiz0aF0v
V9TJgGibi/dy4xzl7iMFvHQq4sBaivxCsNA4xzHjxUQac1D4NDaN5VRALlfbfuF5sQXfjz8whOkH
19wWUvQYvBzF6hfjZ7hTRrQngamp2f2iH0Nm2qr+Zzpevm4gZrrQWBEMAeDbeIwMA2nTX66PMqJQ
HPOd/mAWkZWr3UN1iWdCriqoPaK4bgoMQV5omXTcnyqEu1SvfFRsp+BDr8ynI1R5JQiMhOBCmviY
vFL+ZVvKyX437hXQYW+wf3LFv3rBK+qX3PF8x0tbna8sBg8hnIfqVBDYRR8Lcx3JfaJ/kuaWlz7j
IBmPUVWcxG7r1av/ACNCobEVt/xKQ3T6jqOfcsrB5ZHkIwWFETwL/qEIQ9xUjyeSajl3EG134jaB
s/iVIbUy45RfiGv11KFrnnIrwFk4DGxugnMuCXdCjLGKXE1pv5I2PhjcOvRKoFaQ5m9QEtTIDwFP
5gD4raIDkA8bF+3qDemPiNaW/Ue6CruWX9bcbcGL2dA1BB3xUKLqz0yx1b1UbgXfcopFlRBQypZX
NcE0a1PMszYXoxlazLyA8F+oxUgPJFpSJFdFvayDzKr3EC8nMRzPSI8mmGqvA8RQAZBYXu7Hatp4
lhfGcERIOkqJZ7JYIOsAF6HmGl0kLLHbzBNPfDLrWzJYQ25wBPZKHSXfMVgscCAG/MVT0ZAtDYRr
VVXLqjhxLHsym9O4hooO2pewoeCUqUdVs1zt4DqcPFsV8PcsdXsxHOl3EAVys+EcvdjtRLFZv5ih
KrIabu8iDB08TTyvzKparOSBTXXwyusZGNG+ooeRjgWqL3CkYgSpIxB3vMGzoOHMJgwJAYTH/MUB
bh8bFNJZxAVap87FqwRIpUvb3CFpvZ7l7SJuW8ZNkEU+N5lXg5nuiMCLOjCs0J8VMG2eJUFtciAH
JfGSpvbPSozkhVbUa0z2jWVMuIbIHmU+0V0v5Rh9gQgH+y4AiyK/EsN/VXcO9GzUPSwJR5ml+ZsR
2eCYmKK/uJ6sOZxmwKICxWV42W7zFs29xzkKgKoQKA5CvLG3ner1EAV8Dq46dwaZhQvdw2B8Xts+
IilwX22HqKG04uo9ZnE0bp9xIHmF7zIVisxGTxcwcyJTK3otgwRkLeonZ8j5cR6RvqiLXpdXLagy
R7LHPMRfiscW8woCxZ74f9mlFKjzVRZu1G2JicAP4gGsDtCC1xGufMxmLl4vWogalynyx570X7iQ
SOvKXCqg6bCHHQyyI+UNRbr/ACNqpUgyCLcd+p1Q3Kt5PxDxrORq4+WwBZzUuEhhOB4Y4kWam5S/
iG8Vfjmco8y+Nig2ut0RJ6KOoZIpYEZAhbPURcjj5zY817bDv8yxfi0Pk+5wlgX9w3lg817LZUg5
ijZdToFeOf8AYSS8cS2o7LgeHxBCbHiLFebOSq/DHAiPqYWIYQIWo2xVFO2Xu1enxUmD4X8mWBZQ
2rog0apC+WRzUmXyUh1JVScLjpUCvbCVwR+bYC3B/SGIAYfLZHuDW3qv9julva/RKqbYV801Lgqx
tZSAlNcZHvA0oCPMTGTTWjuGDCL5b5TQb7eoTysL5C/6miilwVXNwQFK9W2e5bSJQYJwjuQtFDcS
4civ+RKqSb9XeVGRLVtcYwROisx0bxEVJC3ffMB2WFV+/wC4hQCxq/EZEbhp4Q8wKTFKiN+GDRz+
cqCqS4EKtwwvxXSCdxFaRvec+oQuuZdLszvahcarFKuzI8BtDyJqS+rweSMUIoHTjn9wA0AqLQdV
4gB4HyNISfjuFvEtSYlH8PqXmCqrUx2CgjR9L19wEli6WXf2itGFeCdvx1Gu2wawcgO7Ha3t1AyL
Y2/ddbLiDGunf9FylylzLLYfXcwnWLvmPipY2gaRRRTvpx/2WfR5KB0eotnL8jF0qNu1Xgq+JyQn
cX41GguDKsFg3Gml0lx/JCbRSGdTZVHmibPtUDgo9ZrAFgoZfUoy+agKkW9QxTUeg17JdHBEDSo7
Gc8SoCnzBGt7l4rOiQWU2S1wXCjrSEF9RAW+U4DXq2KvH+4rAyFm6P3BN3a5iKCi4ahv3BQIDUtu
riqhgJUpemvUwF8dzSDljBtoqqlNoo83KSMPEoEUziPOxMlWZXTzCFEQCHbJfcbksUOHMq2jMlkn
lxKPbfEq3yHczUrsLKu3sLQ8BDGtLgo1Hmcs0fzBOjSrqWBmHmUafCmVKEWuIqzlujZeXJeIjO46
t9qIDdpTx5iFK5OZqPfBKuz11AQOCMl5DTt+pfCwPcsvE0WNiWX5CA0nEAwv4nFRzawbAL5lyQSO
fa9wFmhqpYFF+YoVEfMYjk5JSXqoFOcdxCLbOICXHmA4X4iJbOqlMAL6JqnT3KgB8iIaGmN6dL48
RFINVzE0pYOzkYFrYBduyWLZnB/E1K4l8ZXTxUYqZQ4pSPGIfMOZvQuV/TSrEgPgqxbFulZQI/EO
L8MxA7kg8+YAFp0oEWlUACEu1lqubB2CAs8dbB3h4HesdcEAeGoiOxC2E5XbZQ27+pQNMvy7PUpQ
FRECiHd2QgpcAuNAnMOOogGjUo6dltivT4gxIvivYGBmgLCpWq03YS4acjwjVSmO9tkK8xlymAKl
Ryw7bh+J0x7gpviURXUeSi3Ra5xgiRT+Yc82ANfMI/B0zctNQPAKruJ+rlUY1G3qHi4Nu6IVu9wf
xigyvqAj9V3sUIQs4w+Yb5h8T+Y+sHA1xWdRJdCFTf3ESF1/0lKJpVziaRISaNhSLyqK/MGiFiNf
4mUK6TPmDijfCG+5b50B79LAVXr2JHkMq2j5h4spQXDzbalqyWUriZAJ24EU1LhQ7UJyigL944Ax
hxXqKC0aHqWgjU6Tvl0TL8V13/EUmdwLSXdMGwAFf3CzVBh1j7gqrAZSmw11mU/u/ArE+CUWf5RW
x7SWj9wapTbO4h31H4wV9lTRdIHDRrRANpbnfxGH3XZXmFeTL68sGoWj5QVib2wj+cxQvuB9hRQG
CqvAnXhO0DxLOGz1BgbKEvpOVVqwy8+q4TM9ZaWWxO9AZDnj7PKWhYa1EzWrBp/sUJeTo0pw/EvW
UQcG1f5jw8heB2/+xmzeJdHX7idbeNRc3tVz3CKMN6KH6hvw8Q7mJFNXdVLi7qHl3/kJFRWajdf4
mvZAHgeHqFeAUWl2667qNg1No18oIpa87x/kx3wsVnhgtoCrD+oYFdTyazrzOHYllBwVxUAjNfyu
2FCxCnGtnKFBRjZdRau2LV7rmFfQpFd7KfNWN7lK5zHJNtlT7Mjb7XW5KviL1GfhL4lEb+oqDqCn
2+4CKeZj8xo3VCBizoKC7gIa6zD6ihVHh1EJQStt7Y5aLG1u4H4F3tBfNwJSTdJ59QlYEsUW6fMe
Nywwe2JgqoKWnz5l4BByF5IjOujy9fUtidXkz4qbk3AaAfEMFoOobkDU0p1bKyer9De3uoU4CZnF
eIltj81HdGatbK4lv6b92SrIXe2oN3RAmP8Am0bD8IJfEEUdA5lrCBgFVLclR5BjQR8xUpsoh9X0
RI5CeJ78w9LpNaQjC7FWx7/mazi5R8XHTT0XGBGhjwp4iPs8RF3mj7lD8YChsvlgFKNeJUeb6ldC
jpJwbdmFZ4nc4mDCXM+Ri5W0+JasVHUql0x4h5qlBQq6jR1nbieWHVVKowvYA9RpWmcRAvg8RD2i
JShhu4C2T4IUEcvmbBpTiPQFiFK/xENKC8lGmDglgOuI4BRJ4SA5t9Q5mm5Rxw6lCcwORzzC9kS+
h6gUr7MAtv8AMtBffUWHfMUHyl3xEAB724rPE5iCh0VHo2e5teMya6B8yxbGwyfpBonPMSkePiGN
pc5Hi2Oo9KyJdRz3FRrlUtbeJZdPT4hFVWgypdUdRw8KeYdW2+4r8TuJAO8QLfUR1pMWFcwQib1K
5lxq/EuROaagWeF1mQABfMFq/vibE5riFLeEoV3Mn2nKAE25qOG+WGIJXdkuEz1E2GvuKYth6j4P
OQCCpffU8YPTAVsdCI5+UBIG8QFCuvofBKVWu3b/AMivakJi6kWtpUhJsp0x5yvRIAUzhScWo0P+
JuLKBkApiwSn5iZsvlWfEOdUWcfcuS7EC/iLwDRWwkCp2wQPCvEMMaHuUYGsoUGrEZRKKfuA5UR6
hScNxE1Vaym076hTFqJAEfMSpdEOOKhqqUi2vIV+4rnuQyyp8EsQrgcjDUC12VRWrFtK5eBHoKLF
x1sIDpZ7KT7mooPKli04RVeII7DEYcFOy+wUCFAqosutwk6zuLipuVTlP9z4QFtlaMPOXCIl5pxN
88KystnalRKlh7zEd3a2M2x0llEtHysADfhZyB9FFHtXdNROePD/ANgwnh3sPHzbS4iw08WyCBH2
sxqXLu02FD4ZETqGHpbgNHjsyCCNfbY1C92dfzBKrk4WxTwPNn/Yi4a6LsV2S9EBi77ogUDRuw1K
IDT0S5L6EAWwOlYILhwdTAWeE5IdrTLGn7hGqumJCUHxDLd12/2K0Auy8+JgOO7lBCFWl9wGe+w4
l3KXUUU6KqUVBdXe/uUilPBzG5dsHHuQ8gHRLumVQuAEsSpBU4w/qHDnd1/kbsE7ogDQeC+f1FLs
HgbLxlmcK7qzrXXzHAGcFlzoIdAyUjQJlwY/SLi7C7HJ8QQFAGig7nM+g7jauG0Ylde3uZpVywII
PqIRaAcVB6iBhQ6yJ2qXy2Sgep5BPO2trE9W9XajGM8NcQQXaRJebbqpeU57TY0Xhb2V+q8VHUUb
4Ilwu/UJ2h50uOpUeaJZeAdTkKsOJwCHtFRIHFHEFRdqxIaFQxfggXFu4zE/JkUC0ji5VxFNhmsb
rgYWwaYtBo+Y6FiLO1vxLXoOAgkVq8y20UzciUQsa+Z4WV1AqW+FRNC2XUBT30whaDpWVAFEtu4A
oKV8XBU0Skmk4ncBYXWUjABwOfUewqzqv7uBSB2dSmv5DxLlRxtRYBobbblyUe+oXts+ajuDSHHi
IdA8XFTX8wB0bOKzZXxGWCnzKUDcamk4+oCFFuISut4i1cbiLdVXLmw3wQDOVwNCckAYXdrngVeY
LVh4IU4txWAE27jAt57gs3vO9wXfVjwA09RdrZLVVU68x0V45hYHL1NBj/EMBijzzUopyU8RI16R
Ts0GrIqPNXUpYr6IaNcWQunPUeQyraV7gwrVwIW7WU2HJjoKafEAB/mIfL3EybYGruURyeYuTauY
HmvHMHVghgTTeHUaj1yRE4HhlDGKFikwLW8ZLNz6iCgs5uat8xAGMsexewsq+WKHL4QcigNgNNPU
NLseNlJQt6uKOG3oSr4Sz1lFXEdjhuK6bfEWANyxeLpmxpUquXrYO6aWAUTO4QXovES1e/1LE5Nc
RFarZY852T6Igtb8RQ3bV1Gg52l+mDyEsA5ZwLFkXX40GFxO4aU1vqpWKK+IoXlUYkt4e5WnpajG
GMoVosgFFZ5LHZLA5AMwWVhjwiOCfxDRowv0h5S1iCBVtIEvJ18NIpqGz9ps4XtMmTtwMq+oTgxg
yWxd3QdQmHVylF+oiibfMwolQXIaXqNi3Ye4t+MqpRa1goKvioCC0ORE++UsU0qCu96qVVhrmF8M
OpqFqeoiK9Q1EFq68RYoONhtl3PtOpwbYQUsUXEU1fTC9laISiGqc7hactlGzblrr1xOpaniL25v
mJx56Ys5PMLIbErYjOhlpS/UreXmDCFpKl1LC6lrvFOO467/AHEKjY8EQtp+YyzyzB65iQ6lLOOD
zDDPPv6mK9INYPiDSre7nGe5QAN8yhcX3GALahV1XxMY28QNLxItKyjmN9LT4gTXbzcQVfUTf5jY
uKGmwyWFcQAk29JZ1hXEfa64yO40YqjYcSgDacj9jqMK1dxd+nRhAEA0+GKbpfXmFF1YVCl8RBVg
YR2s0MFusPIQMOZaA+Klkp29JdK34jp1fEXNXR1nBsPIIb8JEfaDFYKp4X3EBRd6IGCueIM0GLMq
UnMQiuA0l6jo1xCtPDZZLCucQRbz2EdLYasZbmbU4ZsKtFa/Eym48yuBqxrqx5YxcUjyiu1h1TYG
wXTR52JlHLzEgCPeTHjcoTpEtKLhwGkBtWvUoVoKeR5iODr34IM9pxNIWmRG3MQBicsVZ6RZ0OVC
+jmWhyhVuMXTBphIOGwLKB8TwljaoPmdDvhlFG7dsendfuJ4J7li4YWIADh1FJyHc57g5T3E55+G
Kl12jct2Al++JTyH3LeUhp6RV1GtZKGsVylNSsD3THI9MuA4KPXcUI5JrQ9mUACcrGabqpUswliz
q7gkql7LLa08ShgNcsRi0+SWFLKq5VR+4WoccQNN4cGHY0+oJjanBaSuYSkIlFH1KKObqaitxcAS
3HiLWhPEGiv4lwLUMtxfcpbXdRG1qBWy1lXExHzGRa75YbSx8wAXfhARr4PU62bG8uRlbDsIHSZn
MO3s7eodAr2dwGrd3NKc+CZrtH8xtiAG3c8Qtb4viE4xuLfNpWLnwSqaqx7IEE8LIglt3wwTFQ8V
zBwTDG7lnHbkl+UeY2k+UCaC44HD0vcV1oxpS72viUvs+GXoL2AaHXMCjTzOQHzDDVrkLdXSAtq/
cQi48worZlbOPn4iU6vGRV0y+4CyquYWsthgK0K2W8ZTWt9RQQ9M1DtN1NW5+IKhf2TYVaPMAD4j
kVa6hSVDBW+4l4/MOzYqs42GTAQHkjfkNvk7nFOFvMOWhVwFTMXa+IteIJ5lqEb/AKEfoFbQFVVD
buUp8Ic+Js+BS8DRBXxL+wZz7hhEHCMrFA14IAVCKfuG7XpLHCy5ygc5NBQOmaHbzEAYGzqdLYCn
JXuWzgRldHcRpmRDwpgOxjmAOjXUE7QPUFDb1UGnlStUS42SmvXUG+nZFJQpniAWW2+KhREKWQW3
yRrHYDWPA4llbSAw21i0pX5iCh16Sxdu5Z+vERiLwfmcSNxgwtJa5RmHHHMNDcQux0mGwDhYxTAD
zEopuoRVXfUAaqx8S0AhZ5koIq33xGr4TqLCqiVfEoCOyhLx7iphkzsNJfwgjDs6lpxiFtKu4Grw
QgKEOWBq5f1EhtxLOqAuXfcuuy1B6jFljmoounmWFUofEwq+5yCKgObWRKBhLBeDCmn4lOC2VKQT
Fu4hP1KkrZenMbWK7VE0ODljPdluTgDV9eYThytYoC7g1LHRUaK4eGAobtjQX5Sqq6jqa6tlsVe8
LEDjGN0GvTOC7UALwC4UGrOV3BhefEfakOZnII2MKuyyhEWfbmoJtfdRb6zAMU+4Fu7ErZUyHuuo
vRvMDHgDiKtHK2ch1W3Ls2HVS4C3XiLPjkiEde4dgZ1Cnpo6mamrgvQ81KBatJQpfO3E0NVleZRE
AJvTWKcqB25V1V8qTlA4sqMQ32XzE5KeJ2dufMpYLzCInBqk8wsb6ISo3qGFP1Eso1iLOB4iahdR
Ba66YsLUqokU8x2zKiqG2LpK7FHUEq4dXBRajbaYmlf/ANiUK0czlsKxJdfiKNAhcDpqbpNfcaFP
LuImKUhsUHUwvyymir7tnNn5eI8iu3cRMWrgWQaTmCwWv6E4nFcMTh3U0WVCyhTnELa8d5KFTz0w
KjSN4weIBTB8wtg5UIBS4FgWYIF2xCznxNS2L1AUvUTTz4qeNVWe42INIGXjuMtrdnEKWwcbsvmI
hQlBc/EeMprmPtMOiNtu+IK97cE5f5iaKHg5m5uNbv76hYUMrdljk24ZyEQK5hHNVBp5OJQWQdxI
ecuZvFKgY2hxcVoLajVrOniF0WFVsRUWzcSgOWWxwFT1GByhuq+YivrmoMunHTG1XjxLWgbPMALo
OyYEb4yBXfyRwCnqAHiAffqApoA/mPh4l8H7iULt8DxEoovfMbSir5lOkznZeWcRYNpfELPdT0Y7
NgvFQkpUyyLY8JbhVfTEQdwaQhqNF3BQDkANinliCS7XbLWRS3niIgMvGe9dC97xDE2sN+D/ACCN
hTwfMucORG8xDsLXFaAW15fMIXVg9wwXr7whk7BoyHBdtwzxqw5yXb1N+huCzgl/qGBh787DV3SJ
R7lRmKbFetgWA/JO887USqPfEy4Khd8wVbPC4htN9bLLn6lZy5KDC51EtnF/EpedwTg9fMqkV0LC
AA9ZEU0xLIMCFDR8QNS2giF0xObjmElEBUeWNqNO4FDnzG87JXQvtcFixUI1A2VE4hwepUKnm5Zq
zzLQVlNBr1ErjlCdFQR4zuHo0MoUFo8y9psY4B2UNGvqO1Zk6UZS1qXTfmUAqviG3ltyMccWHEyo
qlUVBTCwA0HDiciu3EoW/SeTgzJQo6e4VYMqFCrd6MbG+5akeb5lmm9VNGK/8MMKWqU7uvCUjVMn
J0ZkrS1DBVOwFdwJp3IN0HXiKxYA99yopSsaWKrlO4sNbG8dvEMgNbM+rIKiviKcOxwFiVctS8jS
IwLziJMF3x4j7Lg6g8AZsew00Up3KGVuXBe9cxOTC7l0eAfiJHCuyOlup0xXYp59QBO08+JnLSsG
K0DleYgKpXqWK1uWUHHo+IdpFHiohcFSywuvUuBHXqWrQTtijTRajhRIWoV+kqSbU5iB17XE1wQL
UaQ7WL+RxA1VO/MJBV0irxeVK68wiLwQsTtMj02s8xYlKHDAGCWH3B1DaRX0dSwvzKoNGMOF8+ZQ
lCeSLb2WVfcF6KKsIFDZXMrcuuSJReXxEECJokKV0eLUSlVhyeJjpPmoLDwRTd081Nh1CAFDqiWS
m+9QCFU8wBuVVZFIcQDuzxUabO1K2B4CDfO8fERAWeaJUwPhaiC21lRF3ioJXYEzgtf5huFP6hWG
ucjyVzFxXvxFbtX4lSmr9sUaJFAh1LBeAzRSWtZkVc8TWDjmaVmOQgiyocwV11qyNRi3aTVW1Wix
aI9KhRQ4S6YAwrIzRbErIwDbdzWhbNSlyq3GWCNi222BzATa/cqyUHMtFY1ULHK+5ecF3+ZraJb6
ihc97HAVGrA2rY7lgZ0uVCj6I6OX4lQhTAjaKZctRL409riGg4+YryruILVDykvRAGxHF3uCFovq
NrrVdVFDvnz6iWUqFWbC1qJaXvzDk5XxOHPGVOW2/wAwVC56gQBFOpRdefogz4HYkua78Q23eOUQ
RBbuogGlHuUstjBbTCSgt8QSSp1C9WMPNpXLCy/OfEsBXywbS6L25QaHOpe1x2wUgSqogCtAXdVC
LVTOaKficwzDid6t1RGoDKfMMocqVKZeMV9zhY0Bd98RAi3UonJTxfBOlaFnuDLSvbxCgEGMXLO7
5l6zbc54dD9wJ1TbvaphasC4XLoFvd9eoauY+i9lhsDipTJX08TJkBD6hAnNSQ/pxvmMZ5ao0ii0
SA59wIoUOZzCCr6ojfaRYKhy0bLviFzdZcuQ9w0baZBO+UxOTuJ0a+4YvHiLTRzkpFv3FTSa4lBX
nuASC4CsiLIpOKjEJRsFRtU4ElJTdvIBDijruYAqnmGU4hNeALtlihu+4g5v8y4aauxVtcyvJXzC
KCr7gYc75Zkothf8KijGS2zERzx77iud76I2B07jg3UFq1tD8xmLGLr4OIF9l+YglK+GC8HqWjg+
ZSjfKYdahUWyWHY9ygBvT6nAF9OIvNcuRrRUtGMQFU0wcpb5jUufXMCPmUJwPEMhVIJBZuVAY4lW
u4QhyVeRTinzKisrT7hdi18JkTnOREo0S0UoPEtZvOZw/Uc3ZgKpTywjZz4lVRkVt44ieajGla3m
5cKrYVHAuYTaLGJL0bArbvuEGlmC+hOKwOrl2q98Rqu15DQwZAAF09RY6HQwDCscyzti3sStbeJa
FCzmDstPATvW3MuckaouPUR5odLK8MrSuYAWKGoV0lrQgFBWcQ0HtrYZZxnULVl5BvKrqJoYRjl2
s4iyqK2l8wFnLyiaFkqWIxPMN0ppLPENRgD7gJyeV7hVDgKiNAoTfJKN4nKiFPCiU8RQYCoaXzNr
qvLEUo4K+SJYCbnxMJVPcbk24IrVK2PGqcqpeAc9QSLceYBvbqJIntZECLyhJcQU9Q6hSJgRCqVa
5g2l1ZKMYXym8bxHGupiQkA3d9g6mR4MFC/gX3LBXLkoaLT6ly/wxsco8xSLh7qKLBrwEsVH5TBW
2KGqKOW3XcKrNQ2EQeJ7Lf5iBsCwi5Pywwu6O0oopepvLt6hOW1DQXFUJbOUNrteI1mrU4gCqC4i
5VJ+4hoIfEVpx4gQtlxcfYfErVLbkgRtSwmrTiEjm+VlKkNppu/mWKuz+JjHLzAaeK8JDsMDVJmT
jEipits2qY8Rw3v3LUp2fiGyiA/U4PV1CL1G7OJay01stqBeVPEK8R7ChzDTfLiAVxvoih8rL+J0
hrzLYJVEUpVYFCgKzzClbluVKMmuUD5h5IPLCNgsYPSuupfAP1OIm+4u3EHa+HUV6Pymgtb3EU83
EAvC+IIKorYB+d2WVjQQUDdxdgRzmW+HiWi2uWLk3LLxsIqz1EUEs9RBA2XKt14gsDFtkTQ29ZCF
RzmHayeL4iHmQNDrUQB1exa2ufeKhRfnxOJYvmAARrzHilsik4UdQSArTmcPOl1Hp3SaHfMINt1z
DAjBWLjaN3aTepccirqH8QqmWlZH35izScB1hZ4EImcQ6PqC0syjn5lwfDacfqNXRxIMQ6VAxzwF
dxWgFcYBYUOcuCGkVX8SKMr2jKC3bRV0StlqeZnembOXqUVnGTmmnU6hK6j0p3uIJba2Ur5HEdXZ
5qolOkEpGQL42P6luF3uN0Bp3GjoFamVNTbrmKxZpyywsBpowheHxXEosOEqUArWuYs9nSy6158T
Pr5hIAV66gecvTGLtPCeLfjqZbsYh4NZycFF7Babp8QEDncBKviLyE8y6XwukQaHWkSLYB067iAE
oU4LzDBWeKdyhZ1ANb+GARwvYggC28wUcdcxtDx7uVqLsRoE3m4tt5fUWtNvREdwhgt8MNOLlMtp
F8Ndw00fcI9f4lVa5KmAsDFKHEtYzLJkLgsU3AbOfEtVzqOm+YlDlmxlA9EUjVg55hoL5igqaQtl
7IIpyQgiS3iCBbtZQkws6ljDpbks0+ne4FnVeIbXnxDWBun8zpgwz2lcREKKymFwheBAgtFc0pRX
qGwVB+YYJw4iXlsizZfSHJrHGNRFMVNjVtI3oU9Edg0p3ERwJSFLXKForIqoKf4iCFC+5wb8iM9W
k4hmbc2CxBpYLiWprBaZZnJeDU0/CQaN4eNUQwXXMYKVTc2tYO15iKIvEvtS4QW005i+hScy4KN1
UNhaHuPSC9hHz6sXqZ9QqtF6xIo9mR20N6q8xEItM7gh/CAIbmyIPwe4LstG4DlfzOWdEp8PYw7x
GdRp3i9+YXF0cxo07FiwgNXySyyzNqDVSpEovvFMxo0HqDs+s+Wc+JjXQOPMaaFp4i7whLKC2+ag
x4ImtAiLYeunxHHQ1iJG4BwyuGp0EeqIib0Oo96omOFRy6iDQfMsILrzA07vqAKRdRtUAvE0d4Kg
DrTtj0Hg4lhXSxQJZ7hLNBmxDAx8S3D8CbN9uZQVVoLlq+oyI+GI8CsMCKcIAi1wEDbLXzAvBgFs
LfCRal+iUgxXqXhp5ZFCB8BMchqIyHD1OK08RTFK6ylSUhovaJsvAr2xA1VdShrDm1NIV25lAWRG
iMCsuKMULzEnV10RK9nxMTiICTO3zOEUpsHnmGFueEg0vl1KvtRLOx6l8uG8qUHSLKHcwcR5Qpp9
XChqj1UA81G46iwuHTuIFbwz5xCCjepM29QKlbkL3WDmfRLoVtzyB48RrktZgXV/UEeVctlBGg4P
UdBuypT1KAvPqDzbvBUV59kpyC4Q0itxLLeVLPFDkYKnXjqGY4+Y4Qy7tl7DR5ls98qIwlCNgBaq
LyD30pctldQ8IfqATY0bh2RSoEG9jw9pZslHFQUDW2hEhBHiWCldfKcFO1q67jcd5xAIvUFPUvtK
cYtF9jLj4qGXLY90cMXYakuRBd3kqzSrRUFi5H+0V17QXJcrgU+492c5pWsEVwloeEousNvuM8z2
iQApnKeIggTYUV0krAp3vcoHA24ILx1HI9+on71wsCUOyK1enuBbtWQn3rzsJ51UStGLhANREQHY
yglCth5qGj9R60neEWnMVLrmAF37hVUR2EVK3VuJQVcRCK5YsKacxxC6cQGv9y9ARYA0L8ywOedm
wAwdbvlgU7ZiW1cCU+Jb+SIqoqezxKcvXMdxjzKNYr4jTP4jLGKWCmRShy8MAlra25dT3BUvU8Si
AbGtHXMHCGkoHhneaeiH8ghPEi2LZ6gbB247t5nBVruIh0cxldZkCLu0R4Ue5VELyogyivEAaW68
QKypWqjWcJRNKLu5gcnhghPbnxKaAkuUvgL3CrwCIoyjbllh/pDmrp2JsrC24AXanhgGFgaWZtwe
YwAFaagoREcMQ1hcqyKYCsoAyNInSA0TFUfuJedogzxY1KVSC7lLC8DIpcvHiKWja/ctoKW1rzLF
LovqaBodsLzS22bUcmJceiIg5ZG1QleDJdKvsiOiiqgZfyjVLu2AN8ceoq0WGsr1Ka5hqBeRYT2S
FAGKYBXVgcytDeB6GLVeD9xLViNq2LuIeSIt2Hqogu2Gsj3tcjGNJDyzc2HtWufcacWviXl2cvM5
BVRtBRPUCFR6EC1rhqVMGs9kVoaHT4g7a9TQrDqHmr5ic2rQYILitEq+IwgldZ3KD2zUBa9hDn+k
VVuwNIK6UN54iTbF7Il0a9x7XQxi1DX1GaVUl3ZXDqfkRNtKstEoqA2dT0Lb0SlOTCSqniopA0iJ
a8PA5gRFiaBEkdH5hftfjolA6L2VyfhCnt5lIHPiENEHbIppJ8T7EGC1AvxABCiu5faa4g7G9mE8
NxmqqeoWwvqGgLqCX9wjrUALWAhbYQWtle8HYr8KeJVuIWIUZXbKGtTYninA0PUUU4T+IVlmRG6a
OoJ0CHuuI8QLrWaOnqWl3flnja6Y0SfiDsqupSwOe4PsrxMrc9RinINwqvmZX3F0lJkS88wUBvYf
xdjl0ThHEsN+GFNmMR20uWXccmHr1AoMLuVQaX1L+GAIw9Qpy42PlcOIA2LSCy2/UYa0vTCyxwUv
mLjdOoN9q9spYEvGPHB3kp20RJQPyIxDlmjgNFPxOhT/AAMRA02WeYbOrFRe6zTAXuZMVI9+omcj
zGnqQBDY30tJRE4BzTmVYK6zzCYyaMfME00WoS8JqIzzi+IRO16lg3O4JenLmEVNmimTRRb4gSuw
FMOYWHFxos54Z2nxEorl8wrTF7ctBde4AIOkSjT3LrHPCw7op7nzDxAd7OoACxcNhPU3F/UHQb9V
KAnbiKtViIgCm9sFvbHiO2Ash9XjzDahXcXt6gwVZ7gYcPjqWA75lmrz6jLXfpHVNnfudU1eZGKq
xfMQS3ZR4vmIj68YxzaUEsjr0dxpLLlg0xgNt69RpmHIqNIBR3GaURQygZ8xb7dSwvkgETVvcAh+
paUSK/OxR0scnAq6PEQKZH25gSWgnZFilsiqBl9yhTsUQ9iEDHPzCWmmruHJoeZfZYjUHO4nKqSo
934gKD5uJtPbUsht41N0u/DAsu9yWQBU2Mo4Ndwy4X6gwLQ8Ts3UIgW1i2Bw4joo88EzT7D3MgtX
ElUeY8Qp5ohi37lUBqoGwIfKBQXYnEISiGhanjzCK031ELTDSHyh2baD3GHDiIgbePMLTVBuRFf3
INAH4TIXDYwEFKrIpCsa4la1ldQK067rKbVohYRNjxNaEeR8TXN08xNCxNiAoodQRcimz+47QHe5
SnkQNJFbFlLLWIUL3fcXAp3KA+11UFirHIAxgaS0UXmWmsLyuYp9wiGVZEAQXLSIF5Mi2FAXSWkW
BtQYzakAYc8xACWd1KN6s8SwFt7hlyhGLd+Y0/BksHL4iAIL8pZS+8lmoyrthRd03EDbJfJo63Eo
aIBe1xlSg+G1LBeKOYhBYvdEIxec0xC0auviNoF7YhKpFw1Gu7IK1Psxrtb5lgi3WBUOZXzKGi3L
lCRR5JVDTSVO92IWFwLl03URk5iquZBgjaq9QSp+4AeOrihxou7ImtWDzKLKfMu8a8x2DZeHF+YK
1xfMPIuohQ4BtRBY4yPaqoPJksrNiEaE7JUq6rmLhLT3BCxFhbZ48SldVEYNX5lYevUw0tD35gQF
a6j1aseY1rOOKIjIfmKQd8wSp1e5UFFQtfEdkAPESgM6yKl4SNKmeYta4ZdBM2ohN5xxAqwgmksn
ITkljik+ZU0XfhhjypHW1r1BCd7VBlKyvUbujXqJ88kFjoaouYHIXBOUQnDXbKIB+CWHkqHwayaq
mq8wVq4j0t44gAFBbYFNae5yKo4yUGrsjgj+CcmThL8sobb4IDdK+4Bt5MJ2PHiWQ84g0EoLvxAd
yB3NIqvWZAr1H0Zc4i2JXcH/AAF+IJIVi/GSjKRbBnMwR33oQUqUxZvxGILQCXEg5PVxVVQOYzsF
3a5h7VNwgGyFFbKeNYsYCARyw60+nqBiUIvmVpvZfM2BXc+4DXRlrLI4VKeGUqvebIBTo7lPr2gD
Vwy4m+VGPtd85AeGNrzCsWLZ6gCNX7jqDY9SzHIQqNkCbDOKiWEOx6lBzr1AWHB7hqvhB3jh6hV4
VzkUuE5eK7ldIyJbD5Ti6xlQqeKmURp7goCc8S3buXBoS1hVUBNCgqXN+ZdjviEdKp/EceECWU4h
cFx5nui+IOmr4g7JtdQVC4qhDTxOB8QzV4lq6UKYLztiGsgB5dRLtVuJwA+D1EV9eq5lVK+00XFs
VDkg0uqP3AIh3sFgGMctjT1BFLpvuAKIe4ANICDVvUS1c87MQ0vUKFufHEsQvzCNNJ4iGrqUl08q
gxgLCVWtvIR3UQZojltg/qFlVvBL3WoNK/Z1DWJE7i2S/JFrlfD1DDbboI5KeREFDGuYgN3KJWjq
OHrohQoioclNqUlVjkKqFK7lgo16lI1eYtTRe7Eoa7Si07lrciB2viC4NNcS1nHVwAaXWzVGt7gw
os4IFyLCMRG+JcPArglsVoXcFDexyrmsh5C7up6gVu2ALq+yHiA0UcqB2mXERFKB7bYkraIztZTY
iQ6VyQMqTuNKJOkFNLKWA2+ozpR7ZjbpzZzOQh0kvYXeHiNKsTxHQsvqUhobumKdTxF6HKDSyEQf
cAAr8kAeB3AJbb8wogpYoEB7JtV5jkOB4Z3MVOF8dWS2ws+JY15PExu+VKVrQZROdRC8uVYYPuBW
jWbcSLyc8QpY5DWI307ueVLY1kb4xagldReezqLfT6g0LlPHcpjtFqict3LtFel7LRXPcVMI4mFN
7UtOAXzAL9Kmg5ZwShPR7g0RTB5Q7YS1vKINPwu5RWFfxOFdhjKECprScyr4RoB9kDSfDFu3ByRV
K/uKrY1zKtKUVsdiHrI9zQ+IrYw5hl+RFI4DuAPlKiniqIDb6krIUVAGs6iNh9ojvZYdvhgBai/B
KkFpiLUfD1NP9kK8U8zS0/ES3d6uY1/UACtiQCo4eYitZuznFSw9CBM1fqG221xUIhy3cJZBzqAp
ArmggHz8KcygY72wKl34lq67L7lEdK6hY8iOk6l+qg8QdiurlhyXvoggmvqXC8fMpXd+2arR+IlG
WDpCh5XDYS15syTg2Znm5bUN93LkMfIQFW2PDKjvUtgC1ds4hjWy7YiXsQ3WhKhCy5lkSfZzAG1t
bDo5WozBdbsJSFKtvMt4Y1elD1vMH1dKtwduRta6hpP9rY+rDpTghIQmLu7h1gAUclyi7UleCo7Y
VV2m4ACLKAxrNlYbcDpUNu5G3sSOeLVdaN9R14VnrzCigTmUlwClfqXbfMQDTykc4cnODOLgWbTz
HAvRCmLdiJkscvmIQH3B3RvOIgrLqW3we5VLZ1UbCtRZw0PEalZceoBe5fTdO4MbBOoqbZ6hQDX4
jXdcpUdjhuQAAbvqLoCxxi4JssgUEaUOJpBjBkHBdzmfM8BscnGBqKgQmWreIaFCsIoCkQaVfiAW
sni4ZXqvEX6N2KjV2cMKrTzBNcPENDe8Tk8u4GnAwM3IgVxCVCG6gr0ypW36npGwlQBcVi7rbloe
uJuunuXGuHhi6U5bkstfUC0O4220Q7qpgolncGJyncWgv0xoXsvKR0bLlxhspVvgvJ4+TkOIEvj+
URza1jEMx6lRRj4iupaeYLpdXmfIcjMdSC5SfEPwC8SlQPhGbfyhQ4g+tO2eozZXDQ4gCG13NXyI
qbP2kKsc4jWgtjG8qvBLAOJfSLKaefERtzfULwWaj7ixr4grSPF+oK0XTU59DY6C6vhmjyO4oFLA
ovmJoGkUNjtmw2G67RKBbRXUTRFU7fRHDQc5CjTyPiCow8eCCAUg/MACtHh17lWhU/cZjz5gALQ8
SgrrtOGy3LXEe+LkOZgNiCIHzEUWxvFiIwv5mCnK0qI0q5cLLPrqPavL11GAOHUZJHNSlFj4JEK4
DlS4hxOSiulwNrDYVydzcCvmAALUWMl64Th2Sc0aZEDYvklyUfTFdlPE2i0sSgir9TjHvqAXVLhW
ewPMUKBA8Tin4S2hwMlRXayxsCvMcGoFPGvFRbWPPEMNbSWM4JzOBqjWWR1ApXhgken1LULV4RF7
o+INUN31OJVbuXoOPshojSdJLGn5dSy7VHfYn7hhDt1sYAPBqTmF9w1aVglb4rqWQsJS1LtwPAcs
6Cb5lel5U2y1inS7KU7mrlH5TAGkCOOfMCllfM0qEO5babwiAaqcrZ9Qajh7gu+bRLHhUoRZ4gAp
L7ggrY4FjUsPiZPzJzrZk7RS/iCJFkV+hGVn33OU1ZADam2r3anMOvMIbg7ULzb7liCeeIJUoTmZ
48RfL1ELrlIOrtMCFwGniCl4bGEFqualhz8ricFeUWlWBLOGx8hXUqC03dSlR05gePVeYcHjzEa8
j1MHSnxF0u66CL8oV1C6XhmY8vqdRofmFo6vcuFY5tP/ADIpatR0RoICpV1NINNy3BK5YBK4+UgH
t55lW07lxR9B3Fo6LgRyWFQaB5nxUn3FcrBQT0QSoMbM4iQU2I/cWG5CzB40fhzHitsRrb0uYMpZ
Cn6gOR3lFDG1oQaFQOhSqmYcLZaBeFeTxHWuAtouaZEoDXr3USNcQguTlVEZLK6IqKPEFjt/Ebfh
fEVTQ+IKvSu55BY+YE4Y+ILgL6nGhLybW35i4V9xDrvojHV75l4XdzMGxocl8S7DgYU2X4qVlV9S
20VlQ5fiYVuzBNH8wSOW4YVagkBdRMUquYJ6ogoVeMsuQ611NtWsurK+ajNqb0xSQuuvM7EdV4g2
k7GojiIQcOS0vDAEV4yOWHiaN3svcK6h8EwKeIqd2SUbV/ybQcVzLar9RdBVfc4DY62/XUxqMuD5
gn2hsBir2jwS4qSyrVX7iorYy1CteYDNY5bNIqTmU/FkcDhXUswV8bECftOFw+iVulN81FUOYMVu
+URRK+UaBXEC3n3DT14qIKo3xKHYIOYCdu4bYBEdOjchWFq8Sg0s5lN6COUDTm40G85IFYWpWymX
8SvuAbOwO4VeL2MlOeqlYXd+GVEvvuPaupnBHyJddKg33HFCtcwNAbMx33U0cJ5CUCgtslkF2aNQ
Ft7xEuapl1HGDrAgFQbvZggpqm4xasQgWAX3BasU6IADRTxFKBpg21AqiNz+otzU6lFqYm/MGFJ8
cxLBd1+GJ4IDpRA6F2EUtD1+pgBs09xIA14JxF14KgG+eviIVTrySwUX4mYcOSiLGoiNgBqNQqTY
+pz5XSAijwuFoD1dQBVotzOYDA9lRuCnhHgeO4QY7Yip/LKER6e5ws0Vew0G2ha6CF1sEc3OncRD
BFo2uoLs042NQXYTFD8RNlayEQEDGCRuhg2X42GQJWoioKd9VGgr3zGtrHJL8h/pAoVQuI2Fn0QC
EWdkHUXzLiNjkmpGjzcAFscxEEEvSIrTjhi7GPKQQQq3iNbbvIwE3OSriqqVf0kNoZyBi7iq5nJU
p7Z7hgNb1lyPJcDc09wDVbULLv8ABFjRT+IBZLRchDz6lyCxOfcY6WnjzNNreJSqHfcaaH3HaiZV
xgb68SgTkgHljscAqJ+IKbviNHgBBTVxoxaOanEvzLR0p8REE2ziVAQChxOPUa7l9nEaZ/cpAx7l
q+fcwnfWRWBxPUw8vEAGG3cgDsXubRk4IXVXqO3hBrsPIxqwLbxMtn/ESkrpKQDUZ7fUs2csIhYn
uNZbPJGTVDyRoC+zCp9hArgp5IA8etjIO0WHR7lkqcE90OeB7RuQL7VDRO4KPhhYtwjIVRxAVGV1
TCJ1DKI9x3BvAeBh1g4nBdxkTrxGCioaLj3eUUtIUIeh4hPn520NXNdWqiARCu5iC3hCSO1Xgrso
jNFS7nM60jyiqZ2PURJXHiikqBggQXixzKLElRCEewX5qXRfxUZeQjcxp06g4FoqinmLrqfEoUrf
iXRemHs0lALbGMnzCq2Bx7jK9fEajluo2P8AkwgobtjviCuLIviq44ZPTkWzgOoi1p1E6LXqVTRX
NxUfMoubHklDRS5cShoGEsSl6wD0lu0/cXdeBOPnJpmviEa+1kR07Wy+uE5YYoaFiijr3E4jXiaV
KO4jAvmWI2PqOLvxKL5e4gVDTE1iBdx1kpIndjFq3rxBs5hFAtFIAPqDTeEqRWdxNxo5EL2LaVcc
QYBoQUGvOdTqERcBe6qPAgnqoBw1VMu6IwsaS1br3KS8tESsWWvaKAZ8iShcvpUUDmMqJEckHGE8
SzwqvEuFBdycl6k59P6gwMdzWggYQxU52RwBy7jFV2ZVQoNUEDuqN5gKhr4i6MWDWnMQGy+fUEuN
9XEBBp8Sq0svjiHEN14giBV2LOwwwDRKbnThLGMasvxEAn5FRxKOsUYVXRssNzqomwumMFQDvNdR
DS95ajGywU8NmN8yvnJSy8BRN9Sm4KEpVVbZcEVtHEBC0wOMB5g3xfCeYuoq+EMKFPNnEAWS0vRb
3B1C/KKBLvME6vYbOEQO3zBYvRFhDKd6IoGP3ANB6HCIgUpcQCeTpfB7jQe6PMFZgw8zlefUWlLq
uGbNDjzKort6g1i07iEBnlmtYOQei+4lLAq0EA4oDuOxKRwlLW6fEWbsE4CNgaU4ypB10CcM+/EL
J/MBK8SURxKORRpT7lID1BY0wIL/AKlAb1+Ij1hFfLxiwgVhXUAKO+I5WWrzAgLHIANH5nJPfxFK
KTxKtEvYv83RMCO2WT8wyUGhZxFtvNhWJkapzPJGbirqPCLp76jSgIWoaN9xrCtXUC6OeYQfsInL
L6gWPnIqQzqquPgKnBAi2eElBwy8lT5bvpMMbDR5iix4lCxXSAGgy4ulO+oWtj8SwPLh9wAO0csV
O0qmASxU4K7ll22AqVGyl3c/EEa3unxFHpfiDS3XUS0eXhlw9Kp4gQDTTxLqcV4iQK2uCdB2tubF
ZxN2P1Fa7iuYIXlR5BGzKOJcL9Itz8AxzWvEBj+oogaXJYlRfERsaPGy1u33L62uRYwa5PHMQgxe
kW1uLhbEsrIaAUFRYpaUL3jkdAbe5jG7/EC2drqU8w7rXshC4HruK0VTuLZtjwc0vCS/E/iYmp4r
mFXecEMilOh3Ks0sq5qpXKnqUB4vZWCgLZ1DClez6lNZ0FMEgByVGttW3pChgC3TC4ekDcMEtXoh
woO8JynrQvPmChGMMlHGDU9ZESEQx5Rs+ws2pfgEWglyKoXzMV8Q1Xk48TamaxdJyEwmThqOlnow
RItWlcHmc7FiGSr++hhI00DtwcaeeErRg5slG3OcQVY53A+dO3EKpfGFANLAICTHFSCDfrIp4/it
gJiGm+IEFjSlRCtnZDYpJX3iNEgL4IuBXYRCmXgqUjC8FbHYi/ELsPoZFKUHKx+kWOACsShECrRr
YSU9CTjpvhJSY9CAUnuEtC1Q6E1KnLFbRLHuBWl6AXKG+4cwuecD5lextVEGCK8XgC7yPSch105x
CpEpdJWR0+XwNEBLE1Vdx+cVzwjItNVZUvSL0kHCo9XjhXiHJiYyli81LcQ6LluGea4lPF7cxI2a
HQQo2PPhGDOFRjUx1BsIj8VGX+Qu018tQlu6pAJ7uyJgOdEfGWohYCLfYllDgG2W012DqomN9QQq
5cAswsZ9s8+4DaGk0nzQ1ZHmhsGJSFjVTuGcwtwr1GaECh4nIlL+XiXyV09IiA2kbYXbytj/ABBF
JhZAyJUHlHi0LskHzLvyyjCH+cbpnP50FqXMIb0S6ADiwiFFi/cSmitV7GbBVqqfUNW0q+E5aHTK
fEro9ChYeY13BVoY4D3eUvR2uRNe4zvEhggygPiJ05R37T6WHI+IGfoCt8pzcEaODz8SjBXyCBhs
KaFO6httve5VsHgFWdoYELUjsdKPVuB3JTnUCEHABEsLAA8w+np2U8ks7egJdne6QHxD9lAHi/Eq
Bn27ePmK+yIsPeRIO3UcA7iZHGnPxE0FPJNhqxTlTFi/iMRKW8kTqOuweCCZRVAU34lo8ereIWqv
6iJ4nUcVeDSUKRuJaJR2Sy4/GENI2a8euYo7V1GTsJgVujImnByXjpXqVZb5RCjURsTlNJTXpq7g
AbvbLMtXHqU9Dfn1FAHO6l0t+CJeZD4HzcBUre4pYL4hauxKohyyqCq85UAxafMoi4HPqEtbJrEv
wzC3z0R4VVbkdWtR8y4ERv1PK1y2UpyJZVSBUArd4ajrjriLqNNw0hnmNCgoQD4r2dQJPNxUv2qm
VFv1HpKHiWggfPcuCnEQmF9xr5PiMCzOyI1PXMtKu04Kii24uoukeLlnQ3ZsHkjaaqpxPTmdfMOF
q3i42G2OEtq6GfMUs0RzwPRFwGdkIEMTezKlFyUtysBX9S62+Kg6NtcVK0sfLxBG7xwxaOH7liWH
xLEEV2q8QKW7+Y0+vNRQvOoYTgOHxNC1UbRzNK/og2za5Y3AWBO0LvpItkwvYu1XLz3CF9HqeQPL
Cy0aFZAJW+EFSWByACgtSl5yRuXb6ia7NwVCAGTFYqhl5SmuYpjepV0jZ70uuQQqWp6Je005Mbka
N3LrRsNjno811EabbsfDBKSqLxxAGrgfmcUTq50SrPG8hXp1ehGPA2inSXKy+FzgCSOc9wgzjXxE
zSqD1FRcGrcRjPLD1BcEWbUSGALvJdVCK7UswiEOrmZLA2vidGKX58SkqFdeYDs09w1c1MDj1LFf
MLNaqE5BYqwSLFuBxKBLfGLAxWlDkRwoBWcCLye+kwRLpjVym3CFsLdtf1ERoHYJDWPmYPLwzAwA
h4cH3HqFjDqGQgK6th9FrFOyoG2DwYO9eCESgNurMlVlwPKikFxapUtOHSzFZzSJT6gJ3UuKPcJN
N43+IgAyuI3UQItanE9wIpfofRBXmdgfETZUY52FqMU8/mNQUaMjEUWTwVcukuW5hKmj/vWV7rR+
ErBcbXEbw1uz/mG/VFb4l5CmuHtEdGKaQXAicbxzELNmqyrh324IvR0VlP1K9/ADmVhqCNlyIsYD
AXKzR917S3OzYXb5lpiLaR+dZT6FqFqfMFh0cgR4VmwgHqWiAiUNRFN7eAMBijqn5Qnd8HV9xBtH
U6WESFqFLJ9tQswCMaEZz5lllGG1+5an0ab/AFDobh1bfMr1gPg9zsiAjPoIOJTEU9TlrVqJWeQQ
BBAQBcwkAm+/wRjXigfmFS0gBwr3Ebcw4UxykHKGy/R5Ytp5tT0rYC8Egf2TYJB36V1FJWW4BcLG
CKV4eIAtu6CY2FleXZ1UdplAAWCv7hVq6GH0Ki51CuF31niHEq0KVBmwPBH0Si0WhqiqicTinA9R
edZCp+iMnhF8lvN9y7vtwD3xKbFdoov3FCOaBZe3mCbS2jOdxz8HgRL1VfOD3f8AUBYuquliwCYA
uImPLo+mbJw4LR8Rc8t0akcW6o+T1LcF4gKcZ1BhIAA06meuxX+kUGzCC2FeJaICkGr5Zf1m2lqK
BTSgtQmxNXAxsgXqAUfgUk2qdVet9K2wIg5aXV8VeRFttUUn1L2eWGB6W4al90Bfn5jIAEw27lof
eUb87h+IwYNEuqqpeXTVEhXHxAj+qK1D1dRjBd4Ch4iuXqNgXmEnSIUv1OfvA7XGB8Qawg2rXs9z
PV1BTXzA5VvU8ouv3H1OuIbVoaRFeC9QAHirqApOKuBgEXmDTxFXAkVYmzWadPEGtrnAgpyjWQvL
drIgV+YxxPuZbu4XRd3KqcL6mzmkAy0ebh4OrBAAoS25quz4lBYn7iMaHGRBMlE4jRO4cBTt2Eaa
eXjxGI7giaR7qG8V8QKjVw1Ms5iNAqnmYgjLIRglqUlEpF2cpFQQAbY3Jb7KghcF/c1eHrYwAtPV
R1H8xXS3KMZbrrgYWljbnqE+mNqyOIaVORujcBGjfc4FUCPltWZFVmh4yVXo81ENGHuWKSCwOpWv
XvIAWdviNhbX1G0CUNmohbyHULDwXYAtdioBhKYPuoEOqjPKW76+4AUC8giEQ45htd31EcNMeO0d
DAGF355jnjfMZmv1BuzxOBSuZVa29JUA1nEqWrCLe1kOSgEaPLmsldw5qDVuvCUam1yckU3CsDnc
xZa81CAl5dsdCq9EYUElm1KnJAAWr6mJUJvzLIo+CIqm9uoULVSq8R7RUVy6eZ+IGFfXxCp5OVgs
sMXQA4Ye3fUpSJrQgW8sORsFK5QVHKOI+/D5iCDTaJc2Hc8XAgL6/U2Cuhiyw4HHuLLRWDDeLQl9
S8F03r5l397/AFxGWsUI1GiJs2dQNZVN/RCMGpWbbgcCDrzUQ5SaO3xHGxoVnBFt9hbrIQVrqu4S
nNpkjl2dwJ+ge8mNKOyp+EqX/MJPp/8AFFVhORvuDBPVsQjA9EEjrNik8QC+0aoxpQ8NQS0inULb
8MfErMr8Aw2d+WDb5qVwYQqs87GTsnJDBJBLTfqDjco1Z9x5UO+2Nz003a/UfNpacfNwN86L+oEA
61QHqXxaUqqhhEeBFv1ETouDkWsotFFfUTDXKUP4hmQal3BcwJyrnOpWDggGPUpoDabZd0Fla/BD
+Xw6V9x4BubD9QR4YKzfqpXJuKcvuOeB0VfwSjrbTwEQXy0W+Lh614FLfqLwoU6qamX30+awQAEG
Fd+KgoN4O8JKdy09mAuyAyvqJQItNwJm0iq7yCf1gibn2t0QFvoCx+JRA1ViL8+I+XaFU/EPbdqX
T0R9G5dkp47l6y4BVK9xdpjFUsQqW65uHbXlHXiuYUlGjIsBf9W3D4bjTxgCI+Kjp4xsZduYAXTy
6QSUUARc7cC4PslSNLK0/mC0WUwAfuHo4xF/CdPuXq/jZaQV0YPPxAwfU1+pvQ1fB8yuEmAKNryx
NvqKm3iuYxdQ1Sk88y9yAbdTHHi1oX0//loIe5FKqfydnDaYB6zlnCjl8xvFpuf9SpiFsD2v5j84
ajUorkfKslEQXdQfMrFQrGHNxWhBy4QtvVsq+PmLiaBbGU1xBT3WzQMiJ2o2gechtcLXk+oIcl0Z
FkwAuWXVVHFo0pS6lSyFyp/lK5UlhG1uToDuhK8SyP0xCud5qcQ7pr7ech5HsAB98Q+MeGI9c3L0
JbCsLX6jIehNOutl5A5Q398xlO70cBxZ7joC7ACdt/EBjNhtnmOWcB0ZXPxFToApNL6hYt88raEc
OPAgTwc+YHX2ipeOGOWRWPDxlxRTlQBW1zL7MsGi6tpidQVg9iXCxmipauqNuCaqGDZLMuI/VBYL
jLiRPA1W9WsW+GowmOfMUdLthr34JXT0OVL5u+IBdFQEBvLxHhQNRR555iOr8nNQIU4QcyHIL6lW
syWAgzlU+4YA2pVsasKUzIwW9B1Nla8ksoSnmAGOu5ZQ9jFw3kQh7Oicw0DGsFCyLgtXmOBaNASj
bF3RxKlqu4XKl8sbZwdivqk4YWv5FltmnENF/US1tV3sJCjkAUbHiUpHJ4BXuW2F4xPNVP5gnZ4A
gYea6l68+WYvM5IFmt6IC8ErnZqlVbkmSA+aiUt5NPcGtC749Q+LlmlyjCPplnZibkAHWusVOng8
xLy87UIS9Mg0A8vEaB28wKDVhwbHEpQUfMKAQuxjywJ93EUn4Sor9IXrn3EmdR/a8yoUWu5mspXc
qSWXkRtncpy7VQ/iW9xFHJAJRu4KwFzFLH1Ei23ssEpgyCqr8PUFwHmoxzagQ6Riwu96JtWx8Tb2
23lxeQgnBLIuUBvzELaNQuCVdwgJqOYjSDnXlUbUiJdsN3RXESw0jdxs7a99TIuKtYWdmtSsll6a
pXiWIpSNpIUHipehP3MdLOXHNDSc3KeQD3DdeSMKTXAwu9urZnljIHkvO4JZiqYgAcOTJVbiy7gV
HQlJvpMD45shVKq7gDTa6JzDi7qUsUqN5XuGAqmID4XefUtcOWlEXPpYROe4Voab4DLDAUbdXASq
PQ7xKGQmWGF2q3dkRIjVQqWEGa3ki5mlbtHW9xsxCpVx1dx/qkKnlcJbREukvAi5GFBcY5XS/COv
QsZFtSAXNuLjsW74fEXx4PKodDoVa9rBzGkfzjN2inD7QFrirnf3FtbXRqAmkxwrLM0H6C2awzuF
/iEsrzvHOjumeISPtHf+ZaBccyPi5SUHYGHyEQ+wK1xsMbrL4gqYAxh5lfgKrWgkdt1coiCiAL8y
8PFNFP3KWDa1CpQueumP+FbWvmUecglP3EOZFlX6meX01fCA0DwGz4iO8FIm/myImSgE/iLII4B8
1UTNjyG/DcXMLxD6qpZ+Qrho7yLnoaKqdS2K4Ab85CaV2Noq7qKsHZwMKkVX7hkDurJH2mapmT0j
1rlhkFfsRjbGejmH+Iw2Hbde9ghmIEh9cSmBKBAr6qFmXp3XxctgJTWLhChtQOqvAuI63GxhxQwo
wAW0HxK301jiqviKt10R+MP6xaunzL4Ysgu/WTecBoP45iVgiyc/TBps3WkZWciI3M81AZi7NiJU
cCAmk35lA100D+oN/QJfCWGy0qUnXMzFzW8J2JYI39EAl0VjuVBRVSL4RFc2No+yC3FzaX1L0Rtk
NX8QZBauy+ycdjwXjynmX3ErLa85HhBlBpnuJbHUT+0qZ+nh6jPa6BT5+I2bVmtfmK4q94uVpkG3
A8TSjKrv/IfF2Hr8wnyw8tJVVxHqW7s/EIcXLuvERA+bBv5nAiXIsxCJBOmZp4XHmut3N8/cFMEp
X4QLS5a2EYqX8uJyr2xs8P1GuPU7bnWD1PvQL81GpSLbuiGL5DcnM0zA8J8QCnHkVrr3EhWUbsZU
Qp2Jf+y8LU4LTlrbhddn4lUPGTg4GYOQeR9/MYAvJ4Hg2cEUA44UQ9Q/LV7n94oATuITy2tsMry6
15JbQAKXRgc+Jzh6PL2sShn0HPHM7guQs8czUPWHk9x1culbfHcGMK2jfxUDX5UA+SNj4FWFHB8R
/wAWTuzy+5uOlpbeDZnJIfQ9Q74wbWWSLR1HCbHiNGxx2IzoYIigWg4uKiXTSgQROB7guL+yJF2f
cYeFh1Oz/wDnMU8JSpre5CrutZ6cOfMUln+yIA+oA1rivUvS3dKlJVVvNgNBco4vzNfAlhr6mYlt
tuNOtrcQl77i2aVNzx5IHh35lDatlKIldQewRO5iQx5iMdpzG8C9ERdSvBKljvYMQdYAVbx1LLo0
jf3bLoo8FQIE0X1Oh6XLsPXdSrlicxtq5GrgKyXTaiUq1xHQlL7IQq75Q73q4jQ0mwrF+biNjVHB
EnoVVRYDYlH5jwS65QwcMcTVN99wCvFJal6MtUoeoq3Snz1KRfL4jfWJFWj4DKTASNCi77lSx58y
6klnBKutDmzhN6qITVsKAxgUW9YgL7L1BR52LOrvVERFPjmWUF75gETepQT2CO2wKK4ZYVx0s62v
uUgXYl/IgDuJiqzdeCIbbzFK9P4RNppmOoFqeuJt2NxKvipQEXL1MLr0epdFGhsSA3XnfuUG2dkX
hoINcardIgFMcalecotFEeY0tznNQC0NeWICq14lhfHvzAVKuuYnc9LqMOF9QEpYJlyzvXa/1ALL
MaiOWtiq6eDqeGPHAS4XrKaxIQLFEV310bBFM0hUH3zKGzhi9/3AbUaGB5nFY5aj6gJkXx+4dVLg
VCEEDylNxTgoUtD1NRF35Q+gbUcpaUhbEGJDGpn2pxJoLr5QPvHzCzV88xeUrEci+yFDwHknQ+CJ
FIswB+YFGb4jG1+8iSrAKl26OLgLFu/ELgtclRMFBiExfNxBfOFrfE6suEi15VC3+IUDjsqLEE72
KzWMsu79uoKGjfMC8nMOFldhbAbV3dqjG0HjlC+Nl1A7KHkSzgcXXEPSVe5QdVwRY1A5yOeJ4VAU
tJ0x4rr2TCoF6s55auLgLKDKNV6lzU+YYBLzmMhgeyIGzvboR4Lr2RUHTkYZaN8kDdx6l46vzU6o
0oNFytJSdzktdbvUFpRXg5lgrX3UoYD1kOFeDiVFZQsXtg2Od4+Yo8BxBRr7qVCaruW4FxAOTOpA
TBUKeSUt5fBNGEOGuIoabYOZRwVHAtkYm7TLlA6OCIg0UyWFCKzI7QqlV78zvXUo8lBx7ilU0vJD
JAFy5U3l241XnhGrKq6lFUl8TFao5RAXI+eSI4ucbDhDyudUj3EgtOcRG68lgBsBJe7fKXZqJxNS
EvsgWU44QU2g7h55JKWsC9VCgUV2SsrfA8kaqtT+I22gcccS6AtcthMvE5liWgN2y5AuLo4OCC3R
XEsL9rhOhHz1BAu0ZoA8MmnkcuWghVuMsEzhSOUt4lSjO7LVNpMgEprYyy84sVOJZVXgrIgJodQ3
KKVECuN58ymzQu8jYQ5ZaAu76gWt7xCqptylh1uIkw8E5xfbKhAackqnmpwQASt14iRKofEYZefE
e77Ea8aHTKDgDVyxU4Y8GE3ZY03niarrzNAIqIWx1FKnpxGeEDkumEGiliuBsf1GG7U3KNtdxoBT
mdka4ItY6meBjWg0Owy5Dk9zDS0djKE19RbL+ZYcti5Esm0dOYhi8SmNXUSm6NrJSDh3NljbgpVo
dxT5Lyhs6yONLH1APaDSCCw1lQRHh6iacC8S1g6uiAAtQ0tDHX4Y3oN5M7PxCsLqoLc58RPLXpIY
2l3EAvCG6mu5SbVbk6bQuphvB2A1L8FwDt3UoAdX8QkhrYgtP4jKCW9S0SsDruaBdZU0HY6TQ10G
WQnFcwCBbeIDaGHDBACq8VESYZ+I6jtXEAQsgQVjtzYFq/mB+nzFFvDY9thhuQ0LjqBKu/EStNJC
vTOIP2QAAL3uOFW1K+Ila4gBfqLJfZiqkN+FlLRA+JVgHHiURQ+S1m+Nf4h+QwgmrgbzxEl2g7VR
KB8vmZLpPRAsb1iUKvq42pWOHuXEu8iC4tyDa0w1LuZxSrYJvCsqr8SqV9gH3EhLvXJHKIl3DMtO
AGNgFrUTIRxVrRPNoWmJ5nDKGORcYTIKpzK8bVZiw/DmaVjh29wWxRqmMV4WA28yvG6K2US7gBbG
RgZDyFZ3PQQ4iQA0ojiI1ynECtrfUFIQ8sWwA9Q/KQtAuyLeiREuIRUCmpYQu3gl/FDxLFu6igij
uEcbncDsL8EEjlXDUphnxCFHGJzAtgziLXnCNxpr8RyCvZ4l6g2OIiFF7E5EqIz4AWEFqitr8JYz
JwGwTsFcCODDwpuJqA4r2VkkbvBsYtieBlxPOh45lxkPHF1A5kHWfqGoEPXUNDdPGcy2CA2zBUre
Dz44iKXmGRTYHc4lElfEK/Pg5hXMDWVNNK5YhB9MEeTL8l29xMrbguMZW93LrYPHU5S7LQW18wiR
F9Jkg4xTvm6gOk5OZYtUPcBVBa5SUQGhiCBfqVSuPuWFGvMbUtdoc3/qlgu15gXRrrxBUBK74jCv
L3EIrTIu8X1GrR+ZVw4gPwZRYt9xsvDx1CyKrNi0beIMRZe4xW2u4402HmLQFoUHUQ6F2QQ0r6iK
19MYi9dVBpqP4iFD6IKtjgjpDDZcVRT2SiWD41Hn3cNcinFSxSHWznlpajODU8Rl8W0LHVcIKvWQ
2O++p0xyziU7Ngxm8btL7iaE28xadKxjdtuEqFDWOXuVQWauUoDzzC41+Iurs8vULCi+Ilqg8B/c
EAAhVRFBfsRhg7u/EoRq147QLAFAa7ibFFSVxHHlcBAWXXIfMVYcJpKFt4ZDBZ7rmUoQcV3ABDju
aSw9sbYHA6gKGj0sAVbziBC4eiIPTffiXrVjyw1p3iFGu3GTSH/SCR9BJS3yhKvVW26gCuKhUO51
sCDXT0jraTf1EwtCeZcCW+oBFOmBcOA8RUaciLL1cRvl1FApjLrwMYrm3mGwW91Ajh5PMNcj/MWb
Wq9TxGPEGFuiwpgxNjUKzEMvtzUEU49MLLctYp8l3UIttv8AUTBTuH8hcrA49TWXd9Q+R8XMDtS6
3yEt6Nj5EKirVE49zkrLKqbh+4CtBIbuivMWjjQypYKKvqHxdX3LBLusLjWeub8QZY2cZ3B7D5lF
a/KHpWr3zKDyvY3B1xRGVFtWcR2LJfUdAGatlFrh9HnjIZ23AAeBzA0WyJ8jkCAMVXUVBbTGXEEN
XEARDgqWLeDIFSCy+j5lIU2BpXARUWsXg8xeVSHEVC3B5jovgy4NwaoSolUvqpezwzArOshJYTm4
2R0rxGhVDFHMaDmCo02XFgEbIoaVR0ppc2cQ1OZuXSoTmceoTTQ+pXg6c3KeoToppSJopFkYdD7l
8lvrxPkAqIGsXH6EdxD5KhId3BEA7aGsKPMbSWDwwJlYVOYVtFDCio57RU9+4Q6mUjzBYKGhrZUC
XwgXIr3X7gqmIKiNSnGjuGwKbnqWml7qccq+D1K45X7TZtj/AGhhDS2nVQWM8Opr4IlgN7H8FKcx
UXXm+Y2vakc5l24oEe2EO7pwIggBdpGGI1xzL2SLKVZ9xF9DjIhtdKCZt1Lz3AazQWQgM8CjmMYu
oBbEx2NQVooNtLiGKDTTmWttt3NDsg5KoECKGLiGoq6xn3GFg3CHFl3FMxEPb+8V4SqDjHAKrZXj
RLwSuarmOCQoeTX9S2wHYzmAmURS5z0oPIUzBL6mXYr8q+pkiHPHiWIFizfRUqDLt+WS4H9DIAnh
Ky+7HMIoR0ZVutGaKj1exer2bUBD/wAeoXHqgPcsBHXWhCoOsAAgblV+5VPk+Y3Rfg6lqSEe2WAP
gnUWzh3ESqIj5VlR1VxeyaF6hcUlL9IrgaTmJ8VrzudRzlMFejU4BooglMHFwYWv3GRXRhhGysh8
HrY7DgYSzmuvEdxg8wIVgq7gsVBcoB6PE4bCtiorBbyIBRsy+psBZblnOXHEPlutjWFXVnU28ni5
jY4GeZ4rrEBpjA7jUU69Q1Bt/E1HaF4QirbF5vg7iOaHJELMGHUCbv8ACXCNNVNUpZhRrgRIStmM
EiI2ffFS7U1fc5F7+pUrtZxEI6ioS4B4cwAPJ8wQeDuXjgOdENL1XfcocBHZcOhDcWAqn5iW93DD
5Bix0vvioIXkuoqhtcD1MyhI7q7zkCAtWpZ3Ogyi8328MFRhvzLttXLfcsAUB4j7AGQrV0FdESJK
nUtA8VNVBmXFuuVFyqJQi2j4ljmI1yuu4hWvCEij4VAO7u4VEQMrZdpu8QTQJeQGILbEufROxEyO
LV9xiNWcsulVkujVQAJEF/MVFDmuIZuxYZ9nIJQzHmaKWOvUWslvUASrSCqMNJcHkMgtOC8mFo3d
Wy27ykQ6W8RoZjG/tRUol7W1Mxi+4au7uUG6teZubHiGkq1SMILXm4pl3TFfIXxFZ0MbQzp7mwuv
TEKmWyLAJCqhz5nCu9VBLFCkQGrvicEKVj6m9R8QSV+GnE1iAvXMQCKrAlGBZYeR5lbBgc1AO3XM
WjW4dL+bhNPL13Gwo5CmF0dxxmlwrt1ly1hx6lvmzxFpgVWXHLQeUWDkcp3GPB+OYJ6574lWm2vL
BEN3bsMG+YVkPNSx6PmUZEvljOltFVKA0G5UA21UJCzCs7j7ZURaIWlgDqABQNNIReY6Ri6jTk9Q
EI0PFx2WIDzLQRY8Qir1Y7ScvJR32QVwUe9QMa+WK6T1GOjiCJEUcDFoeG8lluW0e48t14Z7Moo8
8iGVUHmXVO4N2C+Y3KKvtJYor8wIZoKlr1bipBLLCmqVasYqpUoKG8nI8CzfDKffG6+Ig9MEczUF
bn14lSps/DE8nyV7jBK+YZ3DzAIKlUl7uzD7jLTAtxbgFRbqHcBHAOFp6rh+ZUF0gV9QKwMgHuXj
F3Lx5QuuAe1yqaCteo5ElBL/AJLFlVYcofDYXQfzDcgUkQI7G/DKpjBfxxGB0NL5h+kLadylgNKn
lH3WgFxqFgcD0ht3uQrTNah1mENRFttUJDGMaOoGTk7mCHAlKYQHwjikYLdSrUrHWXyaoeAOIBrO
C+Zbg7L+IJyi8PmMSFfDLj0o9UC5D4g0mkLvxFnK48xApEKVOZVPwqG2HKLb9xsVXFfwnMLcp3kZ
AboL9xqHC0n0RBAGxSFNiirQg8xmZoB+IvnRxd5NELD/ADAKFiyzxcQX842zrAmhce3Ze1h1dhFI
TMy4UCgrlgOFh7IKW2BG0FPn1DFm/cOjiu4vA1JcPUpQX4YyVaggIiVLJKLpTJckCpTfDkm1Hb4l
6q3zHIhpeooAoEW14eaiLa7kxRiIrXOhzElWg5grDm+KgpiWihQ9xAredwUDYhFHlM4WYryMTyUW
kKI5riAwJk4DPcHLUNQ6slufcDUqfBEKhUhvwQxbemVIvVVzFhsS/EFBg8watd0VAXhb4lLIIHAw
+EGUN2sJWuR4lRz1d+JZBTwjRoIlKTYuXcTDaSEhKdy0XA2tQOFXdxNNoLDxLwTdgfEYKVaPUGK6
J11L+gQUJyjzLgaFe4hpVrewWgtY5SKlBLkj6QDxTbjh2dnUbN2teYWDviED6qAHZ8XxLHVamTYu
sirht6nE4F4LiB1erqbVpdzDbjqNUWKiK5jzcwSK9wtXqNBYBVEVdtPEobVTntVMt6jNbQ2c649x
6mVoy7ad4yKaBQ8scdFefiWUU9kwK4gKW18ykjQxuMOURU2fEQqxWlJdUmXzBqFKmAmHcoOauS1I
16gsL2cHa8M0RF3EXVp6gJKt7DelBKAtUOSpQGwJRjz4mhcruIoj81M84m3KKcn8TI4MlUdHMaHF
vTLgoPHMDaqw6EaqNR2EJ6IFe1SyXg8xliwe+ICN34iFr7qWYfHxFtIL7lC25II+LuSo1VeDYFl2
eUEa8VyRaFjbAd8+GAaim5VC36QeBa2OaVXslChl10Q0JfbARbvxBC+6j6u/c5FoxTQlRnhsMNq8
42DBCxwga/hCoB3IkCc+qjdtoq42G0tTzN73BLKQuosOJZxQ8dyhbxi4CtSmMDk34jvQ7qO0LRcS
p8QjTvqXFrnPuULvjmBAL8wA+6YvatIQd0xKm12w+amqYxyNRYk3jxHCl8pM8MQhq7hS5g8wNFaw
qW1ScVN0WwbM4h3qHColWeOTzGcW8wabwZcagZXmCj8lIgtRCLXjSks1vGcS7GwgPiOvWTuqjyoe
bjGkkLUOLicbVT52Kr7eMj+1oBdx6FawDkF0+dhI6rlxZOYWoB8zt6znELaFhzxKW2yXVX6hanzH
uEBbBNf1NGYtpcXlSkJU6LCnZeEloy1NuOduZKCrvxC1HAYGgpF06ZDLqnX2xnauzpEiXYIPxAbq
n5SlCAQFzHgEtoXU1IHNIkChsIHEDiKoPnZe/wAYdQu8CPuKvmUMBYRfi4lBom5u/wCweNg/JUtc
QrjpuXFR3grSlhDIONauyCBYfmlK4XoqiGWxgot8rBXWfyJHOCNLyz3HJbKXfzCtGCn6gKaWxjsH
vVL9EXlbZ/co5zcu6tClBEBvV2MpSKIJxBztQXeOGKvy/iAxB1ZXN0zqIPEFQw0V46JbD8Ihhz/E
tgseLnZVeJctWHMvUE8/EuyX8wRX4i6XDAGs+KjMst4na9HgriJNU2EzzGALl0ovzCwt3K0oB4lR
wrqNgtVPHcGoUBVRgqefzMDNfcsD9QiUcRIK11UrBVvUvguYksQfzKQPJgzE3zxkdpfMTTUbmrVn
iIRWMUUrd2WB4qoRbN9REKrrqM3xa5LItfMtaEsbwijf5I4YcQXXaGZKAbQ1PCqFNA2+YiwxfiAY
J7hvqNwH8CwuneRBGyy/Ma4FibK7gnqDm26qFxAnGRXda4zqA2cvUYKZjUrXtZAqYpjWQogaDuIU
lK5PMRAaIiMXC4KZUoqhbceiJblMQrACygHHAjBPLz4lkUbzUKt/UQqcp1gWPQJZoRr6gwN5zXPq
B5h8MiSJz8kKwpd8VzLiddEEuhcJXKjqMuq4lVcvKuoDWNdIB1s8MaiUc3MisVs7PEnPkvYB2bvi
IgT4QCjkcS+UQ9AUBmmhog2K11KB2LYwIdiDWp3OMZbqIQvb5nsQ0k0Eo3dx1Ya+5a2BeJS+LgoB
G38RAuU6iPRd1HHoctljebsQ8XRMlKtmi27spgsODhFeacSpDbjQL51qUIivVwN3YzmZY8OzKbbX
iErn3GxawiaL4VMFcGLQdoeW64vqaHgOIJXjmXKVQuQVy3NcYvFE4LJXiXLU0wr1NvUt6IYY0l0U
LXUvF7ZGoDcGUEeCiLWuFNkcaHxKKKjXiWVZXExHVyUlN9x4MnMKDEhDfumFAtVzhMVN2nM0Ck5W
EGKXRDr0tvI8BDGX0deCWq70mUNRmTBtt9TNS3zcsa5qHV4VMVu4A0s6cyBBoF6RBnguoWi8emBF
evUug30x2POR8FK6Ira2IJxLZbkQib4QgD81ENlRfiK3YQWWhimeLKWKht4iBtB2aVae5Z/wiUFA
q2KES0bmSi1nIWEFV30QO13ySgNPEQbaasSU75lAEOx2XFpI7TJePEtbcVcHTKzljQ/6j0jVIZF5
cSw0/cMgLa3IErWT6VbnU8tX9xKwvoR8OCrmfHMcCwrfD42IlPEmESELyLb+YrSjy8q4mySA2Puo
CKOy2vqOOWLwQG1Mo4gOA2/9Q+DuKandXhiJJoNR0wmHQBSwhaF7pb3sYIE4FXPcyw7cR91AdyHI
FRCGtau/qGOnEcF8VL8RUxXzUOVaIrv0yxUkXvtBnbq1t+I2R55HxUs+aaOyIwFPnmD0xFCrHoxI
2Kq3+pbUZnz+oAQarSkTHnF5z9GXkWWaLF7E/ZcVGtbcKfeqoi4CC92QeEAGwL65j4jQ3h7Zy7g7
BwlxwWwCZ/RUEsHbPHiVyCrdkp7/AGc/iJwEpLAIvSxnS7fUobuvPmNqE8KqUhEqNLBfmbVtR2pf
dxAEPBIxU6FWKJYBb/MSsGRVwWLsWgWOLgNaeQhhUuMMpRdwPUCyLYNfXVRj+CGhXCZX4mPy4Oor
h3rFl3ffUX2PFykKqpgUtlcZEb5aNZKItrkiFBsiDexCbbNAbqFlPdQq0J6QpHF8s1GJwwNk1PMZ
H9xUKeYFi5Yxy8yihVT1EGuOBUsBWcxcBvE2IdOCPqs5uKFWvUunsti3Zy31CGovAO4IIJSNYH0x
KZQubAJSj7hY1teZotot1OA0HfUc4qcxqLqC3OaSz1AEPSWUG3rxKToW0jALfwhuFnDxN2YvMdrs
dzJHCueciV8t65l0lI4pFU079Rtrxt7Eru3ekOq0HQ8SrB9zjTwuAFwT31DFLy+YFvBxBKRbSWEP
Ds4IGXR89ywLzfE3WKeCALYFjynBdTQOYzmwVUaNVHFC7Llu4lHmX0XgikKwlmBQSw1ncaHlX5ja
tw9QVdfiGXLa2MGgXxAVDTVXAtI3fXconA7sUErTbhY2wFa6gKAfuXAyvcrAPi5fJ5Il1XD34mjt
luQG1nuMLg+pQJnuC0tlXTEFcF30RCw71EFRx1KBQ0yUI2GXm3HMwBZjYSC++YjiNGcRsLVxjU0F
UjrHiip0ilAS+CI2sDgeIF4A76lsxb8wo02Ha6jTQHdkLEtrT3ERKqziDgYuiVTBOfMVXCntITA0
J9yqJY3F54nWVD1LhcviaQ1AVFdJQA1Y8xpUWnqAWmnCApdHEyBvFy6YA8QKvL5uBQPl8x6/GogC
nvric30Sig2+oQFgUiy2IqSVxAJrErrxKFc8XAtpqsqHwNyaAADLnJS/UKEpa2qgwGy3EQq0c91z
cvSV/wAhzXkW+1S9lJZ5uWoVx4lm6GvcRsjeKnAAqFUptyoTaXBNuNXFdV5iK3jmywgvFWS4Sirf
MJW2/EqnxsqN8EswUdS1FX1ROfhjsu+HxMQjORKwI1cupdgFXmCjdXuzjTovZV8ECB5u8i0Y13At
N+ooVd5TDftqiZSr7YAr9wpC25W5GZa65yRF3FyqZljWX7xKMnA52OdV0rEtlZTXCFKA7scUR4OD
Lxgy3CIWU1oi8UMWolxHRUaw+ceSU9qOK5PMpilPCTkljyQw1RcyfXV1ccRpwNZErG1HtDq7glA1
NquCVVG/WQLQo4UvKJ7UDG63NUKXMsUI1dxU3x/M7C3mo0KVDO4ASt3yjHkJSusbw5l7jsjSle6j
1zWwab3PA0JoRMEMzMUpdKhSdzaZKfNjyVBxNfEATdrjZbN0QOtN3xkHWjUlTf0hrZWAYvqOuVMA
4m0q75qXlDfBO528Oy5yD1GgOCAwKLvqai9ZsIbs+CIRVOWuJcOfmGVXEYrtqoEfui0muyiBi0c7
FeuRxYuUJwuIwwjUQtbKHTzVG0W/UahBemUHhykLNAIlyCKZmUudy1o3/UFiGOagK1yyqDpieYsQ
DVGdQQcNx9pq8RqPaFrQpxUoWEvKIoFLYxgI/Ebire5RKqK5norrqNc1d8HcNbVHcTqC3qZU1TyR
pW7ih2CldjFol3LcLF8cxy7Y7I3IbxHO8BESAU3RbK0X5o8rxF5sJA2/MGv62yX2Y2pdIMrYsP5l
49c0D4hFpuiN5zF1spRxEbThWaJacrMSs5sljkcd9wPPqYC+XqOKqWfcb6ceIVVbTMgpbpqiPajP
Eta+mKeW1igLveGNfURBS/Cy7TlVPicFprghjxvMypb11C6WHtUrhKHLGW0KvIQt3PuDbMcLzEgb
MaYEh1K4JPTuUkhfLDFFKk+0g1DFhUQ1M/aKgJTl7IGrf/IONr6hRTSGRQNZUS8stXGsaMbhFW6k
uDhVRAt06JY8deI7W4FX4hclYa2aBunllgCwNwjSLORJsCqh8hGV3vCAYHW1KEa0SbRfC6mG3PUU
EancsX2lyhLOJaIh00PHUeY3GdRbcqOAN0bEIJqwMrTBIdv0hZ9MLupgRfXgiFnZ0y8Xb6nBa29C
Lf4VLUr4iguPEd1dmxm/VwqeznzLoIs8RkWL5iaroqqjVwXaEgCOea5hVir4liwUPNQqauZVH8Rd
FqzmtEqKkHTGiNqGMzvGZtC31BZVVbUIE7iMJb4jS6VzA0nniLgOnmWu0Kispb2pUs0LgOHqvepw
Da6mWtWPEWfgGoIVpG4OpuruOaF8VAecKS+KYDuPVxK4Hr4hRE54mXb2oCR0DGEXk/xNXBfccYgA
La8EdbdeIgeR9EI38seRsqe5T3FWcV+IAG7KmwfRAIDe1kGCvgRJNAbSA8beYYttn1KBV4VVTL2t
hUoqvMULZZwRumXc0O+aZakC3SWDXgsJ6mJstUXvmAxtech0WYdotynqBAuuyo9qDxOROTlw0cL1
BFGeIFvYoD+Uq9PPLzCIvKy+4VLbC69wBwCe2cTVdaaoNyHaLRYHUHiJta4iNoLaBzUDHQRFW0NW
KWVY4KaGfEpFaCGw7hevEBgTfyj2hYto42V+9gDRLL1AZRV1qNdRFbFiLjvzDa3qq6gAXCocxqU8
yYG4CmgQDkjdHQHECp7YupE4syI5sYAnZNWuB9KxAISimycGvqKhOwKBI1YKSM0nxxOXW4Jcu0A5
OJW4tsp1HQAsAvLi8hB9Ajel29jmDTd8STa41TGUDFOOKuEqWIA7p4gtW8JacCx6QgYY3wiYFD4P
MDMEOssppAyn8RlDfh5jW0DcrKbqEwvDMhDBFHtHHOPRzEK8F8TaoY5aTDC7ouH2HcDZTevaW3AA
vS/MBGVxlb6iB9vDBYlPUpW3ppK2+mqSWciaurlwCipXUT2GoRLlxtzmdjZpFJesNoiqiIDhfEC4
MKNU1HSafYKgWFXZTLF5sca+YKhq9QyjHs14jkDu1VfUGtUOZlGjULsgLSHBkl+AtU9okalgzPJZ
7yRkzFkoEHIPFcEENcy4QB7SGfcJXF4W8fE4DGxS/E6wAnCLYonMFQM8mU4G4scNA7hQ31KaiBEd
lf7inheqTldivXmIscx1U42WGmGxtMrYINE8vjmVld8jl3Dw0F2dxv8AMrZCCtX2qF+RsRpa6jqp
E3rzCYtSh81Ha+bnxOCKyDxQLndMQORdUiI0oupQISkclIFQ3xcebCOxVxHx/wAES0teUcxppp+I
Chjy4GkuML8xJovsy8LtYjEhVUsPv/5ESCWaH6hHlIV8QkYYYRWTYQnHvmPdI1viNNW0omv+mDXR
u0SsrhaTIPl1EYI9cRW0aHoNjpaWnuWSzyyWGKdwulg/mOghw3OZZtNeo7JYefE1AU6je7x3AWFx
TRCuYNIoj3BXbcuGp3C68j3H43Kl5dGLS9N3ISBw0EVVuniA2uq3ZZRRxyQo9Fh3pT1LhquhUW0r
qVsFlNaSgit8PUxgreZ1GPdx2oHz6lA2yuOo7Y0eCOIvq7jovLghXIAuyAxMMM5jhwPcNP2qG2Kv
liR2INikXmPTZ8E1BNPMu/XKBermJQQ1Zy3fiEdXl4qAUGj3CaFtzmWNdDx4iXTSeJwKlNmxqOyY
AsHTNisvI2dNw7ALksovOyaoVRUdpceIinCNan8wAAxHQFHmIVZncQGl8EWwrP5i6HxUICueUqzt
JWw63U8QEmL7jBpv44lDNv8AUuFml7FtYtFfEZC231GjRmwK2S9IeIxzDhiU292G8CioBaik4hTQ
1VXLQb18Raqcuo0QXRcSAsqZXPsjinwRqLzq4chz5g2HttQQU/xBIAvNwjdctxtgtPMIsYuCWPRT
YKBaL2UCtbyr4mNO3lRFbavEcO2tFjAPIiAhd3LLQVRKWF2gFyvb8QKWMATkc5Kna2uPcyVnojc7
eo8Ly3crsZsGr33BXannBlVXgZsW9LUEC8HITe0ha9M0As0yoW1QcNy3wIfUKqpRcMZLC6lWoExj
k4TfZnnmoSIB2q2/2wFENWYTB20yhVsefmCiNgodQLRX7tTebEvPM5fQgGmgaTGqjZUSwpV+VQzA
NLXeQ9uYXzCY9pb2dytkNq7Z8w6gTV6S6G6C/wAS+aFlUl5O206lWoOcZtWcE4gaMQLdrIQSrD6K
7izzpixIQh9zEOxcqhV/fVywxwb5yIvNPriKBpWCVftSKHcRie31AK4O5zC4q6YqjkNkUKI8Q3i1
Q4yIpCCLl9y2GVAhIrBXesCcss5qoUce40tKZEWqgmm+Zjq6avtaloA0Iu/nJi8shh92Qsuv1AWb
hn5XqCWe1qCQ/BCWlppb5DuXU+4NbLzkriom0LXTCEBevM4ryC1IQRLgcHexydeGi/M3pq6Oe5nB
pTXEYcgKlYuF1lV5GgHVTiKFvZqB44giVaKvqNdicogmjVy6Dt5FhWTXZekbzPIKpQUqAoWJgDAu
EuEcogeVFR/YDvxOq7NROv4lFAXKAAiL2WAV89xKChdeTuBdXRUQddDVv3ICoy0IB0rgWyp8jWyZ
Ic6DhEGpYZ/MTCgMSUFhZX8So4cGdqihZQyk4oslbdNL+lhdnqjH4jWAQDbl3twu2HH3GyFqV+e5
7kFwF/qZ3Zzn+oaAu32nRAQMl7G+oEWApWed9w2TRvSikaUq5e29itUvwxLbLw1MUwp6gK4veIRY
34AJfVRFl0XLYi9mj8RYOGUhS1taodoAuOJQ9+4DeEB0eJZrNnLIgQA5HfqIur3nqYpVuv2/2BL+
3uEIB2SGrwG2A0KNRbRfmChtNdi2ILsBFpVnLcW2YHMFQaV6xKi0peU1i/MWVpWzwjZzZ3BbKxe+
o1WYVhHdS3kuFRdWcMrXpLAIsNnCCp31LDXnj5ih5XBULa2R7Foz3LqiGFKgrWLB7K5yU0LDssXf
HEWotZxUOPMAq8wvQ1EW+TuDRQ/EwvyyBCOeJUaLvMNN3u1UtQ8o4lAGt6+Y3svsRs9h1KA39pTr
nxFB2XxG2EhnMwY21tUSh2AbRzCwBVzctUFrGC7CGCIYQFG8eosDaY2ctbtjYrFGUKQPh7iXt8XK
EeYTRytxqLZwXA3dq5vqFGtHuF0KGFoRd/qWKUTqJYzWFFD3WxGXBnEGl8Sj234gNBbeou8VcR6I
5VyggLPMIlWSiaweIaN0TuAFInCKtJhVPULYK8RFkVdxWujgkKqOPct+R6lEWHES2uL/AFKG8mhl
3fRz6l3FquXzGig8Ca3OVwHdC2URUF+iGhSr5WVIOOS75Rn5ZGi6vcCi1MRbvMWwYuoCKl1uylo3
q+oMNfctXZjaDSSy7RqODenEEXaquGh3oY6mc9QV4U8sKLSicTDlrV1EIKsHmCFN3ucS/TIkunqJ
NDVDHLTU2Ah6uIz4LpLqY8V8QoxVfHmLXZlTLGnORMFX3cuJ6Slh7WIFSqsuHyKeiCDaUxggAUvO
wcYPO+pcsC49w0QNeQgyunFmHmACIck/ocCZnPG5bC7XMIYBFzn31EZnYPR2VohQguepUlalPuLY
6AqfqAlqQNvUDci9kBouPcJ0cKpYwAPggtkAF8yihIFphLVjVp8wCFcB5S1LWXSh1WRhAlqqhnaW
Eu88SqWzLo/HMa2AZ87KM5OV0+52RsQNN1tSny1z8RbWLYL9RLMOyQ2YOGD8RWRaHZkyX68wVbU3
fmo9AGEKEUMG7FW8wUWNQm4No4Wy44tUsN4JR7HXanUXrRkBN6gIu87pmFob/PMO11le4kZYw4is
89vaXRV1cywRupdjXnZkKbwS4Ipw4+YPHpxfMQIAEqXUitCUYZdq4p4NrsyGktWvqphFi61BYouL
yQTVLPJEQm3x1UHjmHSULqBoBE5KCOq7nM6rX6tqGjKm/ETLwBcRFQH9QuANR5piCvc8dy22dp/E
DeDhSPdQ+SKRzD+fiI4odTeJRX2MZLtCbL0Lzdwob2sFxmLYNpX8x5AQ4/cr1to+NlhFAc8+otJr
SMNa239S3sHL9xx4q1v4hAsjcXKlF9DIrjbMdlQiZzy+7grGCOt6iMSN3g7muCoLreEjXBKF7dkd
rGrB33RDwgXpRUBSAtntCSUXYK18+IoZxnGvU3IcgRvaqtTsI5xQ8OQKaGCj2Yv8Eoo7j8RiFfSN
iGdVHpUhJxeIRLN0ZQRJDt4I5UYyJdsXuLCuGe5UDYeGWFWW4nFq7VdcTYpK4qIuFF8QJA3mkRwU
oIPBXEZQ6vtglUxyUot5JY9V7hLhw4ZbbdCfibpZXHmYB0PEb4x4lKy8ygXd1twHRvxKDg34iFSB
TlEKEBfED0roqYlHwTiGMVt3yp7nnnF4Sg9xdV1NFbG8lrLlFNQm2Up9sowp5JYJdGF8RUVKeYHR
wYqOjxDdU/KaQa5UagTDifkdzA5itgB6PqKSIuvMFFFGI6m1aBdrnhYRjY6qE1o3eQoa7wVKrIgs
A/cQStLqiIL78IKqr2aCr2O1SuGUov8AUuCtHuAocnNzoIL241ABpWxo5GxYAQ7fMNc1eiSpX6lx
lvUVUsRoaW7q4FHP2yjZaruVNNCcVCniWpZQ7iLDQIBVE9NQhVlS6bR8eYWOjFQvA7jbS+3xGrfN
jE08BzKuF33PDRTgjQK1MA58Td21e40a2t2BRDXKmkp93EaXsV1cVwxKHULIbdrtjCOHZA7L4IE4
zzAuHHHYUL58xorygqsqYi/mbR1dwURT5J4ocRe1jxLaSoWY1d9w+1vd9Qql7WjxBEnBER4dIbbp
lxA7Y8RjRy6lHKC+Waa1+IktYsDdNqdQAXe+uo8TbauFasB5qCpvfHqVa2XeS6cpdSAFLlZf/iWB
DZl6LK8MqzRtw4VhbSKostz4gkeqhLupdS9UUG+JUFmo8rzErNF16mG9CUB659wBY4bLFoZspS1c
GIEUW8+ogOHEaBf2hfNBiR0R74l9KXC/ewBzqU62ilAP9jYNV7Gf7PMRMBQm33KmzMAcSqGQ8o39
nHnDgZAV5+IY8FDeQKuk8/qcfctgpo+Da6lUEtDQglLXeWJdmyOHBKiMN1Qum0vt1FJKCHlfmG4X
mm+2B0SGuVOykUn/AGLRxzGnzBWyZkVcbraGnCacHvFuUTLdcENVfkRhvA7qUf626s9QOUAbO5PG
hgHfiHJkWjr49R6WAHFgun7BpjDmdiDHLpZgmG2sDd+iF/kWuuQC6yjeuxq/hAYC1yB1AOwFceYf
FABRK6lUC8eIlFeehijQMwfPMV3zV1cMcBLurlpwLQMvDZnNx/I2OPmMYqmvXEKhSwW1KhwJd3cb
kC6L9RVc1DZjfk6qwr13Eig3kq4O08oAmeZeWgCfhs5LoptF+YANu/aPGhvgxAi7bV+0HsbBPrYS
8CgPRMLhKcN8xgyWAmmu5wcipC+YYtsvLWpTgzaVdeI2qb7Rify525hFQ0kGCB09cgbYuHA4/MMD
evImUSHw+UszBiVYoIdADecQOwLdtjNwFt1eRFDG7peZAqbC112Tan23pkrWuXhztzQctJQQISqc
d/iIs+JLcvPUu9q0cz01cFeNuts6HOm1KgcyQBX5yV8MRA7vf3C6ix1hvqBseW1JbCdKAVxe+Lm5
JoVeeL5lnZbtWXwkNyvi+4nrnusVWQvAsOmGzIYgHh9QcSaU2y5bKfPlv4hURvLM9xWfzA/3N0E3
glJEtN9fHOy4hd+IMRfuEgaUu4AukmbXDVMDFeDZE2dajAQfOShAK8ogtBx6hEvHmGWWNPMYnbv9
Q7W3ixDTWc5BAumEeoAwvqAdKPiCG2OXBm0yKxtrBiDRR+mVyte4dO7KFy2TnCkyoDzbVeI2Uiin
IOGoLSS90OvEGbqcwGpw+v8A8iyMctspDhTmI51xKKjvcQQ6HL3HigbyoeSou18QzeA2/MukeUAl
88oiVvEoos+UUFRuKq4PHiBEVs44gWzSB4OxnBG3rTx1K3PPUOx/ycirGKkpabBuxv0nrxECqy6I
g9Eeom7Gt4IC7Sc3LjYfEV3wtSGcJOwWHU4i6O/ULdNuAum9kTRuvcFFr4JBgspC1mkNRHgrYdgW
YMUKB4KjcBd5cAhZEwLCDarTfTMIKLfMVqzw8zAIqo5zDtgF5FeSUWhzyTKXdeYEa18QQMcxqNq7
p5FjwvnmLCeSysst6gtpaeBlys6g0ejlwEI8s6hVvEJfJu9xAoF1A1vklhRcvLNzx3DDkt0ysQ1L
Sl1Nigc8cwzgp1Ki7gFDwMiG9tYAHBigXkTuJ3GrASnsguDhgVtxk0cLrxEil2sJNFqIDQBzN4Ac
ywWmOpc2N8sbcQqozfUOIHsD9x7IJzLD1zzLAUB4hKF1fD5ls5psLRr8Tsuk3Yup7tuASlHioiuK
9SzW16gspacXNCu0htiZHT9JonSYQU95PpEmD7lo0OmAuR4eItKldaivVlrELejfEBjQBHRLqBY9
EYqu5UuhVPuFpfNxgpbY8kRwsuNQbWOGQZRQar2AXa8QsDWiNfUJPOTSpr+cC4qMzscROnvBRU2A
XW/mOKBzZZXwtXB/EOFrjpAN0eLFv8Q7xNjzF0FkoHBhW8IdxN5XhMSKFHy2rZRaKPN7HZsvCi2A
CR4KRAXPIODoOJwzAojtoZHQAHkX+xBaL8rRKQ4NkMq6RfJfiAhvJlUpSi93yVOh7FMtFUeWzQWe
REo952vIqoj2qWLfjTBGgewVMSA3Z5dxarccFTmD5S2TvmLFR4NMrhm4KSeeghMi+5ZfseeT6Ye4
G2mEWU6G3EzpthCo5AdHqMuZm+bGeIHtaazngYQnLTkzJqgYslCCHNIjdS97jOyj1Le+9wfiOCh6
lhfxLXh6WHiBPgT/ALLstOqMShYVyx1Uea8UofiDS0eyJ0P7GQtHd7MUcUftDQ3eVJ+GX7BwXqFX
PyvceCwWWI9BQEuv0xVCHwuWNJysn5yIHK6+f1ktKg8gg/DMtHwp39zQFbKMjvJ3yyFfaHkdP3Du
LptZDAewuRoDsEBvU4RclcWDcD5wd6TADXFzrkFBvEPAtdJDqDhNcRFhXxVQFarhudlH5jhnw5iY
IBz4YOhe+8i4Dip1LUumLwU9wLdN8RIGnPMdgh4YSAhviqgBqGVUF1acHT8w6gE9ESuOZZia4igY
O6RBqA4uG40EujkKgIPfFTngXTfzFFq6eKgAdXchldJxGgGDdxKcrr2+4M54gqoj6iN3S/U3Ut6R
oTp3XUoqZZdxiAoGnmEXn45ioHPdS8Rw5jzDXid1h4pmWK65g3PMA3XfjzFiksvhjcUKrKiqHiLO
CtkVRyi5SjG4TaqABzTU7SdjCghK6mA0VhHqWsgk3zdoxWatwVDpwTFNHyeJtLDygLFvbUDnMZOI
UYHoFeI1lQdi47ERxUwN6dzSTt6ZVTg4iQEA8xWIHBxNVtN5KYZfbCA5fBKK0WyoxSy3NXVVRSi1
3ULl0uMwqmJAfkRkJ5/UYv4R09hNKyJPFTt0RCUInIR4sPKUw2rkJxMq+4tuykSbePBEWFqXgjBT
Y5YWVXHiVP8AlhYq1ushpK8oDA2XiWXTl6hfNpICppVyy6X8TUqLoG26Rhbi81mgVQ4iQxX3NdBY
uWXqnqW7gdVLAMsolbl8EFDu9EUIu9t6lB4gVKVeLYINe0sJY+DmIl1tGFSoPGykmChQtPJLygWc
yX9SjxADaE9wglbwmCZcttNib1XqLZaTpNqsOGUhBrYAwcQdwo9ShKKId8RIl23mNgiVVswG/qbI
t8RE2p8eotCLW1UNiBWLWsB9KhdDkEulm4DbuWg54KmIRfNQuVw2AitX5IKbW9QUoZXMupiBUCzi
+Kl2UrRt/wD4iwLVdZDHolpKKLR2VUYwtE+XzAAE64hNUcgu6OWcE42wPFcxi+hc7Sq6YbQbXPUV
wuqtFy+3RYFO4ohjSDI3cDgb9ypaAsHviF3FyVWRNrgBVFfTdrIT8yCUa3eJZDkSt8eoZI1Pi4qh
Srq404wTLLnXstdh7iAT6Dicgr4jKch1LA4IQTB0bcBtO2JBwt7QsF1eIcG/mkV+RhDFqNBOZh7F
qQIrjumxgQIdkCCwcwVIQqg5iJk+IWIQakPxvQi8VV+mKM06IOBvgSAYj7CBXV8iVrGdIu7qXhD4
R+2RzWEaKA8VKoJ9Jkoj5/lNeJwihmOEgFY42J+oGAm1VorLB3UpKtoBksRDiq7hgxgOoarGIJYS
qBu+7i9uuhH4Vn5hYi3FI/Ql1MEUtHGkWYG2JSgVguZfgApIOc98IC5SgLXC+Y98J9Ocmwm15p+o
eF91WVKjh6hcwMWPiXFKO0wj4HdSBcugGuE5jsGnkXFCAv7RZEZuuUN391blfJdJHGz9xVLVeAsP
iHNKjAY+Q7jbKtVp3C+qPFxZG8qtAk7wwai0+OGH4icAEDZWV+dKlissETA61OK2KB8gtLIJ4W2W
QSm9kLJV7vuNE5jDUHh+nEZYBD4ICIsAmxUrSu1cs74aQ3XzBKuq2nECpRd8VHLLYbcAPFFoIaAO
lwuHwgNX4nhklopl/Sspj8ysM10V+JUCFWbz5uLrwKoXLj1oGpF1oF3xNDI9xhB26KCMivaqH3Ko
ovA5eKh7Ui74b6YwGWUKq+YCvbg7PUvrnoqj8MoMyoi3GJUHgEfCZif5I6aFJcj8RIJm04RSq7Tk
PNwoDAu1GAXSVKgz7Dyh8zIeqOd8Iddnrs8T5PlGVDp6crGhwxUYl1uiVgF8yHRGkabTCNLL9dYv
7/XFRRZUmm5UIMEaxik+LRLQGHLqYC1XvqWQlOlNkSNDnIUS0tH+fUsLVZ2DQU/MUkUUY5rTxBRG
9cIr1QVyQaC2pKgK03IlN7fHmAd166lAR+pwu7e5ROnrIWOQ7eYYNfBiNj8QwKeFUcRXjrdbG7Vs
yIi84lAGja9RcCGbZAel+iOWrac8Sit0psEAC25iDwX0QOlEcyJYZDShp4+YaA4eOZRNZ+4q0KPM
C0l3DgF9vqLYh06nJFdZQqbWEPU58SyCvZiAUE2MUld3EEG/RKDS2DNb7X4jYBfxALgpzHuNOJVv
db1K2CJULdc+4uxvunUE0lvrqHEB+ZSD4GQ4BmrsX74gVBeWQC4WeIhViii2WyX1dIVA0+IWEp1U
7qAdRFX8SJE5ilwqxXiU0CncgSyQrCt89S3Jol0F/KCG6fxFnD1FSl35gAt04gLyOUZagtnZCoK7
iFS41AuduB2WGxnaWYkLBTkUEBt7JSxs8LmAV2YRTwddyzl4jUAWUAjfcKliO4KbHhphKaeInTKY
LETh6hVr+JfMp/qYgVyKKW2c+ZYAOO/ERo5T5v4jUAOmxlS6KXxKoFqwFGHcOQht7KyAKYuQKFq1
sUAaeYpUtXIzYU/UqvWmzzDinm5YiVDZwwjZU38IW1LTZxmyC3ZCqB0goYVHwi7VNtyvtkq5DYJT
6m8UoD1Dh2xaUCaXhxBMamy1GWirhhof+McTI+5+JlG7BqCA5CPoMCpfpGOFWJt528UFTukukrg1
LjzxqrY3FRVuZYJ9bGXGyHSoLghso2J/EHddWNBddK3C42tuy0t+pToNauBKZhMW4VhDdgZDxxFj
IMDYgFs7SVaFxVQuADtS8cFMahmKVy0H7lEbWFafqXq21cxCYuBdB97EU0UIow5Q2faD654DmUzf
yLFpJVJZzMX1wFVLUjug/wASw97XBIiKxlw+4XrXoPxAZD8mVYl5uXv1EV2cH8XCylfVkpQChfBc
PXzhZcfIKwblLoENcT4gNOwCA+5ddzQHPMb4Gg531KfTsALHjzYBZ/UeAtaPJ8QtRheAfmJrVL1+
Ag0rkAC/qWeESxVM5BGC7PqEAzHD4QX3C5ggpRytSHwSyNCMF+WLQLnXV9S/rUBhrysCyhwAhfP/
ACAAyHOojGVprfUXOVwqfuHLkCSXLOagPqNJzWGz8nErQgKBQnqIDU4xPll3SAaH6CXqbUFafOS8
YwA7931DMXsL+ob9PkKvVxt6tUpS47xwxg9NTTmw8vUIR70cIxNfgU35yJw3brJft2IbKrwd5hzT
S3J2xlquBx8v+QYg9JQK7YS8dJx6ogoDoSP7iS6tC/CiNr1dR7LUeFotzTAtRtBbHJ4iEadtfiDS
Lo6ZfTBm2+gIQc2MDvEua4QXqnERnZUkXUa36VA57Z3x8N7WKcHDQdyov4Gh5uWDZbeukJmuRA+1
gA09RV8lswwt5lOqgWxsSIfxF9pFbjj99zBECSthtRq4/wBhCUq+Mkq1Zw8a9vb/AB6g4FlNH0cV
Lf8ANO0mhXFZB2lAAAHgB7iHUIwlYP3sy/WGB6riIbwm7c+5zKdC7Vq9ywgojg+aP7lGaWAXzD84
VSvg9R4ooCPVBvgl4d9WtB7r5h5ji0D75nMaMlU5+Y8pFgV9/Usfauhb+mb8gTV8mXasO9t9cZKW
vCj+YgNs6heepcSODb+YjwPNBsWVLLyBMHt5g818SsgL26/UOFGQYC5mbOSruFTDnYEiyuXzCc9i
XkyOB7jkHoEP5iAAu38RogbqCy1pAGtbd1Bbhty1Faol6a9CApa1/MqHg69xuW0p1AKtmLI2Slug
r9zSVXk5mWGxdO5aim3cXKr4mmr8rDRy+pTzC5UpLS3qEMC/ASza7p4myhVDkUiuepo1R0QHXTxU
wLadEpXo22AHO9zToVyU5izlJUKs1tR2juXVbA3EBACwCCtu6m2VXjIkmrUVBBRYxaDR9TQWa8Ql
jZe1GraC6lgVlPuFtaeo75HKQUKjZfMyjlfuAKpXuVs7ghRv5it2Pg9QKGbjUbBRvp5gUWN3zKZH
RzLCJXRYCU3yhdRKLxUAwRfjqVNnU5JXogI2LrmCgg5XFcivOy4Nm+pRimONR8RqyXRV1nEHKtzE
Au14gtaBFoM0IpNvEBa1y5OogvY91HQur6iu7iCLaAeGeoPFRGgfQ4js3EtXXgVE0BsMKg0G08EW
qLFMPEvt+pWWEr2YWts5JwAnwiL4iqKiaxfdQhUKnM6HJzAQU3fD17mIbXVzRYfCJRRe6bndx0Nl
crGWlhz4fcspKdV1GSOjRzHsttIvWxXBAc+oCpzzCwHgPQMSm8A+pfD2u/Uqwjd2iiqE26qbOulW
EcqqjOHGW+o9KhKAC1/mG28uU7lx6lTD5auy9hNVBbiPrIxYjhb/AMih6Y5F59XBTcVUUxeIsKjo
L/uZ1WGnmKqHtPmG4AYjhvwW79y67gRQaR1pI63TU5UUgcFdVHxw4DcSSmynK8yvh1RFxAFoHGn4
gsMdKE7nT0qTVe4jEdWVUQyr8uxcPEJjFRUwdQ2QzQsrRqAKtYGhCxgpEUfMlsdilVkt9Stfta/L
1HgsuAH+ILVpcAe4/tWr+PxCvoEL/MOUX4j/APORgSrwwEv5g2hYisIeOKhb2+ILqhoP2XB1s0Xf
3xC+yGov3FwYYGUV7hFcGw1+pVSgQ5S2tlg6+9iAX4UV/UVefnIWXb4Fkt+4ccKDtlUkLYwfMZhD
WE+kE5jxn9xuQRawPuIuJ7ge4EozER+2GLMbMX1FNBzNXG3cmQemypkLVuyJ6bQWbta6l47gVAfc
CpygC/UEX/Vqz8QwVX/acR8ieSKfNTqN1hfAB3LRTLFY+5Qnl4q2+I23QbJAQ5fWfewF0sIv6gC0
F1yZG+t6W0G/NE4pu2QvxsKvtdRgBQFjRe2oDQ91gPuKh4R/MIRVVQW6tyG/ZMIUE2IUfiJYKohL
11GT9w68RsTba/0IDI1gWfjIki1WgPPxGRv6BfXMBuRs2V8sQtOgB9wC2uglviGrdosfMfluI5vN
3DI1gL9sqmPlsfiO2ahpoPbsAiGLEfmEooK1UIhYnXp3yS+6JKvbf+zAmbgs91C6qidW/RZGd0LC
rJxywIpVQfgoiyWLEo56gdoai2g861Cwa476EECtVcUF2xhSnV5usLYOOoEIb8VKjqiN4WGRPM2B
X2FwS2xIPmtlipDkVxyRqaUEGvPP9Ql8qgDzuChd8JhbssmxdxKyREgo86x4Ts3p+fuO8gY6U6gz
LADzxU7LSJWYw2n6/c0gV6Q8+MlFrQXUXpIzE5wXHLcw5kigL9fLAqll78RXLSSwpq/EOeIae5ZX
V22t7NqLF8EZnT4hWpy/UbOnYdwUFtSwhfiYRUdkRRseI2oN3uEuS27haK3vHEGzbBlR1wHagKiK
hjBfmC3duyDI4OsOJ9wCrdf1FFDvGJYrQYs12zrV3ikpy2PUBdhXzHhS2CzVrqIxw9EUouiKQXfc
KdNX34gMbD3EravBKtNM5YgCj48xClST0bFQ0l9RRehWqdSoBuAra7d3UC78F/mIPKeJVTuAtoeX
iDeOnEoHJdaRjgKaqKej0YMgsOHuoFnC8wDTWlz0RFEoJxKVyHUV0OuIRhR3YFm4cQ5SvmAy0hlG
/lI406iK1ntA3Axv1MLwXLG8ExB46ipXp3Elkae6hDjnljAGZLEIZT8MjkMO4OCXXIYJ2ZKUCEVd
Q2lL9hEtRzCGJusqgUr4ld2TKde4pnQlhhD1OJumu4HyuoCVrxcYC6pm15OKIWE28EKjwyi3kqoQ
A0AhtvBovECl3a+OJbYabySjNpqK1T1FlG8QisW+4QLqsZTx+4yDkdxnaWHPR3HRRdG3LHgvWMQt
Fc8xKCucYAkp2YVlRcOTwllG1OXqA5nuvmUC63LnA4VvR+ZwzWwV+JVcNFnn3HOoRQ2CwOZciyPH
GexEPkAidyz1ClE8Q07t0lIWbQmTwhiGhJTAhLvki+FhKGzED1BdN/qVJAfAKjSGgPMZrdviI48/
3GFPZa2Majwf1MQBzVUL3EhtFNCrzbHrbcyX8xZm85x1QSikSkYnvZmU1u/snVFIj+YJUqsx9XGb
goFT8w0BlYlfMJsLszX1cLmLKB+SH3GgTX27GxJ02wfzAhtoFn3cb/OQfI3cCZYrr/pABawFX3yz
OVwKH1s51KDGHaV3BX3LOHuAHzFbu2hoHgj6Yd6B6I1wKw6HslUg7Uzah3gd9ZBJh/6Zra52KQTc
rA8cy8a6cHPcecTb3+YmoquI5u5XrFiNvu1ima33WfdxEJXXKQM9jyGuO7lz+ozfq6gwmNtCeCmL
MbSF/wAs32doV8ruHccKVNeInTcCx/ccgGwV/cXwwWV+dmrfdBvpL6hMgEClNmNolhefc0LIFklv
4NRUCj4rG287HeIoLH26lHFs5vksbJ40HLw9Qwa0FuvU1Qceb5G47DQG1LzBrhV5+Y/oVbb9y5uO
1K+eoMoQdA+iCb0rpX1E2VTxGIXF9AuVaBEJM3fX5hoSIqYjgKDQvW1zLLxAyum0MW5xLv54H2vq
P6i+BqdafDY+agjm2oLXzDi/F1/EQ5alX+muXxeghs+YEQCln9EXUjVDX3LuMvpQbBKgDJO4OFRQ
vWOK/FwX/WjhMUdBWKq/U0boYHl9w+EpAKHnzK1F9Cl+fMUKN2B8e5czBYFhxQ1cNUUr8j14gvSE
1I8ZLbO+dp52WcRdtFu+7jUyFh0XfUupmCpYVfuBRe3yPVw0dC0CCVRtus11ieIQlFConVSpR4Xd
HnJaUSpUV5ziMMdgaLvmiHbdGci5f4h1AXb83BDRKauieKXuFskBGz3cHowhJ4+I/KgtcHhEPF0t
Xe1x3BKAo4m+qiN69BPF38R8u1fybUziipP/ACoBHO0hXjZo6JHD1OJ+MacOWPLF76zzKEY8bfUb
9pRYJT8xSAdFtc6v1BPZt0PmYwUoteccR7Q24H7VFTGUHB4fqGFJW1FT3AIN0oDecR7+7bSOO+aj
Zc88zuXDo7ruJZ2OnmBaWaeevccV2rB6Z8D7qHJVK9TVK04gNWXhGy7tenUCDvpiLul+ktQnGNSc
+YVS14EaAC3YuyxoH6VBpVCXTLZYmeoXdE7g6t3jJYAav6gALncpN7KqBY56lPGTxDHou5oEF+It
bYIyAa4eIXRo2cTAoVdEp0jvMV1PJEaXf7iKBaX7iN8kVGAeDLr8nB3Fo0B46iXcn1D7HTFUWrJa
hXNysW9TOEILGz9EWjQLllpkqb5KqqyGa4PURaWq2yCKP65iiafYIRS8uCCpzXFRSO92xtX08TXw
XmCwLRljWMXbo8TuXb6jbwKbVRYGX1UrFN7KI6D7gawRx3OBfdEAu8sj3VnqG2aZRLilX74irCN4
Y6i54hWBq42R+yAKL/MSlGrmo0HZBYuqeY0OIfuLInB62Kx+J3DRVt1HQj6qEhx2IC6s5GUUKfek
JLYb2KLKW7ECG6LrxFF0vuYr7e4tVwcHmAG+zSWtr6am447MGTAdMBBo5mgFRieYAs0epollXcoh
Ss5YKKipxBp4BzDS9QEaGGdpKeCVFStcVBLP0IuQD3BBNT3AXcA2u4mE4c1A15NXDTOmy6L+oEQI
4ryyxTg4OIC7zmoEAWXCBwbMhKRTF/7RxdXxCT5O5cx+PMpXkr3YgfQxQln5WNgXOHMQoEoeTEuB
fmVonexERe8Oqi6/NE+EbSj/AORKQNE7ilbSm3BbQvExGIPLXOQi1vqK0tXTKBYPewkbs3KSvuor
CA5V1Gi3Elkb9cyyIWd4LIjnfLMJT35hoKngiPaSkl31CqEc8JsYoss6yJcm3DByQ1GiNHdSxDZ0
bgaKeHuVaSns6iN0Omo+kOiUDQnmVpXW73AThV6yWTCe2CQNrynM5LT1Alw8TWxiDlfBxFCMepYV
XMABt8wBVekQlQJzcGHA8x1UqOPiCWv8y5BUe5dbLhCkCsZr4Svvh08zNB8jqUu9+rhxlXqI3e8q
glFzq4URoOAVHUxfiv3BPJ6lq7TsZbURrqK3fMfDRzfEt0WjjZ4IDGBBPsl1SldkWhWRi3F04phH
mdRRRj5YuJb0x0XvioJi3svbehyHwuOQjUVD0dzgLpj3H5goCB6HH3FhpA7KiYcTyZBctAveYNVX
3MYGh6hPdUnEWpai/GLyVXYA05f7gWAu745JYiL4iQQ2KqUtqKVMdtQFC8uccd5YBbsHzEsCVxUU
WqLq15hGpHnLaMvVgBXoSwCvoFwLp4qaNW2uf3LcQNXpssi3NT2SpW9eNij1G+YtFBOb5ibg8Nmw
Cixwb4iEHXCOYku3gO8RVQbWvUuuEOIcxiRVN3HANWee5xxMdCWNNvDFMzjkOog9mtAmCx6l9N41
li1YNYBFwpqCMerr1BCEp6e0obo1eEHTRbIlYg4iRoCI7KiVdHz3Ag8vhHjqJVosc1zCzf6iVH8S
6qLTLFZw1H4reiGQ+k3rgy9qHvB4NfNRsN3ceM9BEXSG5AXCh8SzbeOeiW0Qj6lkPN9IFlWmcRgC
Pe5LilHmHAOe2IpVp8VLKhfuOoYD0+Y3SWDqLfr56nmAuRETpLE1Fc9ReiB5mWt6qLVyngZQ2/IR
RY0OYWbA4CIUOFtuCcoPCJRu14ItwBXNRUTAdzCtHggI3j0zmXe8eYHrzdTEYOyC9LbxONG9Fs4J
StAnqIBp1xMlb0rmYR98wQ+OdiJShWly6Rzwx7TfviKIA+yA5G3MWSxK4gWcBd+Io10XLRFb9yx0
PiaPQy5UUFxCTpnAJrk8QKK1diQI65i0FcLOY0KVeMXFBCB4PmYyWncFtWnqo0iI3pVkFSi3zCnF
J7leYawB8i2oyFh2jzCs2ggN/EDftHUtberimKa8uDxLJX6nPEBSy61TKOuR+5SnZ0sVKcniFgv7
TIcFaTDW3uUmx2czUEsu0o5XAAFq8ZKGl4YKlueKhtXz42KQ/wARUuL6T2fqAvQF6+EwQ05vFwL2
OTxGjRZZjVu8sfidQFG/COz7/UXeUauIYHmLnAYT5EzK2o7605MjxUF5D6lLocPLNo5wJTF7BVEs
kjo6Qg15Lo2S0snpHPSIoZ0oTi9j0DwCVUBghexw1CFKm7wojMOiqHa2ICBi6TtAdRuELa8xmNfE
vjn4lqOltYAcadHMxx3FVHCA7DCoWBu/jmEtwOzmImZepaVm8nmUFtcwHgdSpoE67xUA1UD6BVwG
lN5IHk4iNpbq5Y+hpCledpI66HiLZS7GIWs6hUDjplHNCULpXcl4PPGwp0BcWgNMFeTykVdj4iAW
16lOoeo072c0gLo+RNiht+JYcUsIzadXAomKiFpYTqanUN5Yup6SzEQNKeMmwsrbjwOnLBbUh5oQ
Ry19QovfomvhrnqAzY25HLfJDKrFgVHXNxw1wjGF/MZNHxEOOvidFHy+INnUvx1Cn8zECKuECBbL
ctZ269oIkrnlhNUtdNRUVjtYjavAP7lE4rtOIqnXj5lCi6/mJ17lS8XackZeCMuindDBV7qzvqDS
0r1NBs8VFDhOYjbbpgrLTyncQKSHNvcRKNbtrGLalL6JqYPLwg1auG1B5FOXFqLw5iZdB+2GoHLE
Ss6cMCYYNI5NDxsWvBRcoDZ5E2/EC6IcbEiloFUfzKIy2qFPs1ApnklOVDattI1XMFQ0++o9CB4i
jy/KbkBLq4rwrXzHSvGO6goKiRdNZUYzBG12gQaV2RBWLCox2ujvu4KdKPJFSLzJq35Vdx5BDxCS
anTMtPYvcuLDmrC70LqvMSXHek154LiNNNcQJh64ggXDk6mA3jLJRrDu4goUK31LbW5ewhrt1LgS
77OY+CvRXcUHgqXUJ4Yyhi1qE21PqUY2tvqAcr2cN83x1LrbVQI4LpuOvET4HvuITVK8eIxO45gV
W+5Rga+Y1pXssws/iCgWe4g4cQtQ1tD6lgvrmoysc/iPNXEQXPBHV9sxkw9X3OMoH1KWqj1CQWs5
RxzUI9j7gWVULQeXiXW7rz4gNLYFLWh4lS7fohgtj2zGaXuupYKwK5mAH3CzcNtlEOvU2dQAjSk0
loxS+JUKNIBQ0w5tgcVHnGkU6WvUraLIhWQPMwJs7yNZFPxFUIY9wIBypdsNBy8+I3cqupZqbwQ7
pEXsnkD2xONd1nkOG47DXY1KLvTxARB9XUElt6S0rspiKWD2BEgBBdeDiIn8KmIcO4uNpFAdb3AU
ub5gBdKOIwW75Sy0K+CJjnXMJJYT3HUJK8RqCq9y4WntH0qcuS9yrzApuk0EoBofcut0lZHRLp5l
NAXMlFjVa4nNcTmDT1GlA2PXEUASQwB58S7Gi5kGDDj3PC98MeCqtuIWroBSU8zRO8HxNq2dBlqI
2orY0DiUV5/cfn4QqEBruU5ijj6hZXs2IFL6CWluiozl7rhm9Abfc7uZPNVEhhhzx4hWbTAv4l9B
EOY0FsA7lKBCvMfMvBVGmtg/dG0s/wBwtFi/MoIKU5zKkCK3Vsp0NL+5TTLX2d1AMcAa3DT1F7JD
SVDkdCYENjHeoL17hAus8Jep8AS2xUY2RKX88RlY9Jcqy8EEEYX4ja+D2zYGHZwwDTz+DE1PMAUL
bxOeuoGgM3h+Wci74ScBF9niUFbk/MBE14e4c3k4lY4YWEEeCOCAchLUDfctZuo8CW+YWnvuAVl1
ysawcPBFXl7itbFmtBfEp2NsJDQm7ASOBLf6RihUVacI206chwxAlFxAUCfyIIlV5lSCJdY8y+d1
h4JZ0p8OIHtH5lqi3y6lRKYNrbGLmSwuu2UgCCB5RvJZkU7SWzZ9dy4XDtxG4HmUdawdqxSt9FVA
vVXtU5HKx5Yq+KjiXsWLcXdsG5cmggxU65MGPiFVV85L2xT45ikKr5fUu7t58zQWx58QZ9FwG9v4
Qeijw1D0bffmJbYh4uMmKOHqN9Lbnl0Oc5lyUOFzVYQ8RobvxcQKDp6j4vyVOVglWtcRdJOrrk8Q
J5EyNo3V+pZBgl0n7mYD0tMVXB8PmCnS2FllbHUsWTlQN04ROhz1KFourg3QvuiU2cO1NOtTuuJZ
BHWJSWrt4IkbvQdxyUoq+w+Jgqrv36gy3mHzKI9BwdxTgpfzFZN7yxbU57I2sLV/KW1VWcP8y16I
4CuIIiy8NRhvaLVkyBRAtR0eYDYrlfEyVuqIYKQY7TdHPEodrXGpaAYZkAktGxX6esnAN+SIQsUK
o3hqJSs1xC5YDtJyJw11OxasuFUnXcru+PMKS9zlDmWtFvSRVNCrtHEDM7pgxT275qUFbMe5nVU9
3G10O2LwEbMjvOBtwbAkFxB8eYSrjhJtEcKzuUC9lQCgXmaS8+Y10QE2rU9MphkoQp/SYAiLrAhu
mljtxecSiFzmUba3z4iCCWtthB5pis578QShy4uNNsIuz3LqUauXFbaogcFdSzSUbdVcYNW0ydZb
we475WeeJhVhP3BKs26JQJu2wb6PcWz32RghaRv8AYgBGBUTZL/gibFKOImgBTxUQG0HUFKFXhAH
iN8TFuvbGSJbh6iuHK+IHrW+o9L8ZG7BLITyuO2r+CWXNHxGvC+4WYJVZNFC97giYo9k0zX9RWTG
bDxV9Ez3JweYoBcHEIohgZXbOTfg7iiL9iYeDkpDdVK2Nj4WAQ5eicl/MsUnxkpt5OxJqwLnBEpQ
XhuUObeiAF78OoAYtqLtSuqi8HLMIROXFVScGFRQJqx6uEw4Vr0sFhpoTghTYLureJ/6Eo0XW76j
YHC4K4iSGLyjiAUjRijmbCbWVLVa+YRoqseYWwTsCNlBxLFC3Q1KXmmEKgaU4BCb52Hcadp49wAW
60efMQKVzQ2KKqflUSYqKJYKsG+mCBgs+CGB6EImzKigLgxkRU7yYtU6rwwb83XMBLPCtgIcsq/U
SVAU9QBk49MR9Hc4AqHqWKkemSilDzK1YPZG2WGLhfJhZY2cQ9pvkkuPNnFTnbF3csGSxtgyyV2v
+y5m1UKC2KuMS1p+5cBS9U5iqEo7ZcF3XqOqueIqsc4ghLU8MwsVvUYxuljCAB1idy6ovBcvlwqr
nIrkVQU+WNCDRqiN+rqYdW3vxEPAMXA8+YSqsOZ0bolCrsqXHepo3jElTVoIAaF9cwF1g8wChTyj
i7TiNrUtqF1xTGptG0OlCvK5ta01Asir7hqrX0kTnbdRooK7XBZy8IhySJYNPmAVYQPDj3C4LrWU
Gtb88QHvjJktvUQWm1xLK1nEtgdMKxfiOXSd1BsBU9Q0Wt8VKQGL1hDm2/BE0sLw8QvIceob8X7T
iFJyiSoqnslwWq+I6OdDQRCAxywWy268wW6rKgVZUHqKFGnYeZofBULBaXxF5eg7gFDSyHsHTjnJ
aFtPfUooalc5DmKWZzfDAQZTnJsG+3mNRqkeWbvSIWKL8JvpQ7ctJvskQpavhHNVq9nJA5AjQBG5
EPZEYlX6hjpQ6WKOlrecwa6tTb7fMQKrPM4poq7lKRQ47gmwO63yQN1wNiHifCNU3XUFRsSubZvz
sKXyy1A67lrNULuVYA5hUULK99wdFVPwpkdDY1Wy4ct3niGa4P7lWx0bB0Fu7h6tw/MKbLXIO9g8
dMBZSjc7jO8cQKtyz7zBnInTCMBvSwVEu9iGIv4loJBeDqFHXBy0GAtLYnJy3C3lU2otnFHLxAPF
dDXEsmm0XstoLfcCDTT9Tke3qAUV8dRIqfzLREV4jKhT15ZSy1QdK4uI1VkTZ05uIUYnMVYujaYF
5ndEooWt7F0WHwSm3RIu6MvmC0u4XFaNUqE2Wiwlg+XHcrQKrzcDVbtorqCurHcIGnu4QU1bxktR
Pco3l25lraxKgroBsuBD3kJS/wBTUNpzFAEZxFLuY2L+DNAcliuSoKGhvriKShQeJsKaQ4BEFsPl
8TSCvoweRRfMY0vJgMGJdPBqKzqnmOhDY3jlIzjQ8zlbtYRMVi9PcCktPOwFV+cyG1N6twJjcehE
crZ2aZVHEJEowgF2viW0W+MixrQTEq1X2g0XV1icXK6GwRUA6ndoE4C04h2FvXT1CFrICxLu84Y8
tAVgcxeQnwcyknHzAo1p5gyvtqobqPaOl1Aq/Gw2YUPLCjQK7e3KJ2MuuIka+F+Z7UGiUC441oGM
xU3zKeEVMqK1GOKEMK0Sk7IAraUoIb+RyeYlSkleLbVsXJuyi5ctmvEM82TFfiUQOvQIUm16LjU4
ckEL2Eam1AOYtascvMGgGkrmNYRd5E7VyVK42EmoAgKJxA4rql5zAFy+Zw+YTauxfPzD2oVMXnMq
assZridf/kBBeSuE4giynvEq8DKDfb3EotHqWWKIGihO4YtbzU5uWf3Ko5PEWukOYtouIbudrzLI
nPmVJOINl3ZxB4omhPKGxDnmAqFNhFtxrCBtVpvmCtdPFRbd7QWEavi5V0i+KiNmuoOJ8D5JQ5ZU
eJlRWTRzKv0G/MWlBa/US5KczmiyKDR8QqQV1wdy0FzpOp2WPcpTlFPI56YXtQA8G/zAuXrvzGg4
wjdP5hmj4ruUNpuSlo15gTTd9kYizwsgjdtDCKIuk5IAU4fJL5D8oChXZ8wqP2jTSvtla36mw5Hs
iQA0eKlJT/EtQeXEYWrUuC674haxdtMIJ1Za2weuJxXGuIHISUWyvc14WzGKDy9x08IxrF3FBsB9
TSno8wAu7vmXhS3fuCc3hkUQp4XOIKrxFDIdTAaPEVlmF2HM8ovNRG15a5dzzxcQA5pYORw6Qe1D
3UFdrXiYtLcIEPTZ6hiddpEXBw8xPPDjEWIthaK7iyrhzEGDlYsYGCZy5FgqgfuKAQualg2OmFy6
6dwWPHJGvlc5ig9u5dBS/wCZQjiRyteIXSZ5vuCUFXieZcWtrPfUA1pSmC6UK2iUgQ9iJhn0JhlV
xKhue+pcj1TPHmF7mK1d6dQcQDxZHgLDhjQlvmCoGnT5mK98EOTH+4ABb08RRTKJQmg83OYrb4CV
Hh5L6QEt5zUseSDT4hAp5FfFsPAXPaC6YoPAuiMACG6iNiyu+ri1e4ANjqCGHXcBU4+I7W0/UHFY
/qKkbfdy5buvMDzzR4mjeuIoPN9wTZjxkHRw7lcmi7sik1orIGs57ijbuANseootW87AoFRdnURD
ancWWg8MFBtVqR8I8F5xEoLV4JzHB+GHY3eVGQ9smNFtxLHsL5lbsppkEbG7IWZ67iDajmGyC12n
mKUGHRC/UYBFyycy+I8F98zKOX8xT90BTlyuOw4LtQs9kEouXzLzgeXKeBXLCgUByypcKHklgCjx
FyBFO+4zRSeZl3vLCGLeypQVsJz7q+2CL53fmILdHohWxsHmJIYfMECqzWGhfLuVC68XL379EUiZ
6lSxfCZBA8JU3aPAEvlqA3zBnHDmLsxiQNl5uB4Cp2HfJL0Hl31LAac4kLN+Q67W1cRESjKh83fk
R0HXOQQKWBU0AF4VH7Ci6lABvkl7YDSAVb8SxKU3NGuio1J1nMcnTqorSXNyuIHpZT7l+sfIr4Dq
PyW+IC26VkNoNU3cRCgrmCKmzi5oOVlb5iEiDuWM25287dE03VH0TFLqIlavntAJuA49WFArDODz
Xcs0XZpDNAhSoJXunZy9QKE7zh74icBqqbX1KAKcrxPiEe0gWjyhkuyvsitW7U6+YJaSlDD1ROXD
A2dogCeEuD4jULtl8ssBd5lm9TqcWO9yNAN+3uGqDTAkAhXwqY6Y8E3DTvOIlHl48RiIPxDmefdZ
ODod+ZW5aOyWRXHfmO15MIe+Mi1KfUCbqR6FsRa09nqJueowofW7ZtQ+FjLt8x7C6XEPK7vBIYea
cuWBv1Lq1XzDaw3fECwbDqDbBnHuIoy+3icKWIgBJvcdLSFdxBQfJIajroj9I0tU9OpwyxHuz8y9
A38zYukpE65IaFFrmoupRl5GBlp5grkeJglOIK0CqOebiUVFnKRWq7biPgdQKPD4i3NieJSREr8R
VGjz1Aut3xUvXf8AaBHbRiqNLeOoeGkqthQVdVzKBQV3EKpKYJWN9QgU0yomo0eJXLPdRTQCIrd9
kPrg7gIgYeamGHsE3KD4yAch6rqWAbLuoSHQ5muGnKsE1T9y6VvVcsBusZV1bFaAvGQAAbaiih9c
SiW3hyJQoPiII05vuKpwOXKbtB4sjSDq/HMAJvR8TjgKXabFpYKKrtNNgg2XwsShG2K4lEBfuOER
9xWFCnGLiFdJrDkutr2Ma6buuYkJN3kNcQvL3LzsQjZ71viDFVwxff8AsTFr7gEUJdcwEQtvzABN
MSKCpG3xAJu0Wy4M5BcQUIHdRAhy1Bl32gglTiK2qJoWsbEWm/iLALXiJV7A8SwBPNVFCRBOZers
ZArQRnH6hth+iI4UVowuDAxWa7X6lro8+IXIEzh79zTXJ6C2o6OiMDRF7DSAPRBK9mC3ZaOSEVVx
biR176gA7d7EABatY4mPmPYm5a1HQCW3Gd6Xb8QVcP7iSGgyEapF5MGx9YPJXH3FebXhI1Tt5qNd
lTwzDVQOalLQkDur/EBSkH1zLwYF3Btvg4RU7OIAWrV4inV8VHAR3bgFdCML0+MAo0Q5fMLhvTcu
t54ln1mRMh+EBWFQAKvluKlVjmpfLs9pM6Qc2RAqX2iI8e4gDXpLkX6qHmIS0xvk9xVcVMaEKZfu
Igx7LzMtCreoU19QxTENvuEhYwaohUqkG+aeo3vyHmLYOVUSi+2EFjR8eZhViPF0Tg9QQWtcJVuV
K6AD7IN1r4gK28eYggovPcNXZXALdXkoFt9xYa2vqEFFeEloV0OCp1eTnzAiqvqBUtvxLZJqE71f
UaNlQG2WB7L5RALVXiGzN4+YGq4D1LtG216itRDq6mVHLlQDtfhTuAA4Xfc4i2w5jV0ucysUouo0
sa4nDwr3EK2JkoBq3fzAa1s8eIz1RKe4Ead+JihTnM1vA6OoI7duKjQ2CIIop6IYck3iE0fki0pV
1YQsjKCxrZdwS03UVsQBweI5IggnTNA0aXryXTVcFIg1PhzBg27cIS2oK4cwLlg9svUU25Eg5bmx
3REl6ojZKLQDmI0Jca5j7ZERX6lW2Ry16ik6t8JdKuOy0gAuCTBd04JdaXPKAmxN7RRx56jtTHMl
IQeYz1pdRd0JxUDc85dRyIDTtVGoVR+57d2XAcOSHCyo62ovEtUql7lab8s5gnI8bFo1FUwFokMr
w9eIym7qVqq3ioLRSg4qPW20Ut2G3zWK6jsWMyAQvpxAYn3EUDQ4iNi8+oCsJTVTaS/eDiJa5JoD
hMH3DZCiqrmFFDaqu4yIBbySjKnEaS5iD1LLyrmBFPEbTg4HcXUWduoasE7ajpEdxl7jTxNPJHaF
Jex1uB2HiNvuKHXYhY0b8zH5EaxL+Ys4ls4wU9EzKfcKZZXqWDM4QV+AvUeoqz+XmPcjb6lxcvBO
0FeSGtVoDYMsKjhR8y93h1qWJafeS2wBXdTFHXyS2s0zvWuLlFN7IDyPz6m69Dz3EBA0UlxBUW6I
Xm6vIlgtMmDVTkInINjdcHBcLDSPUGAflFBXd/zLWznmIJVoUuk/USifeXg8cuRspavqDoWjhnDC
8HQhGtWblRZgid1LNkXHi4OXT37mFaH5SyRQ2fEF0avWMmkt0CXFiDwp3KDpPynGFRsziAkWHSgq
G7euoFq+xAyAA6EuFhL8RBvfmjuJVtLXUugaXTXcuU3TuL5Au3L0lcuXLtCBAJ0q67isG/ZCQxdh
DcLL5gKrpOCE4N7nEdC78StbiUq8VOO5O5GB75qKIfIY0JNfUAhQkTjIOlmdS8xL9xLG1DJu2obu
KVfm68xdgnNpNjVv4yUo22XO69B3KoSW4sCpBeAQQnYHBFGNPiUAar1L38EKEfpUWyhz6ieR3Eds
V4KhwivcUahzkfGKhTLwZlx3CKeZ2pPmIgw13KWbfmZ0H4rmIV6INje+qliVtxKs+PJAJ0EArs12
R0FQbXdxrh0illIeSYBh2KWphFQ0NviKBCfEEVeJW77iBqryeKnLbtxGhq2tmt6boIUKWevEutqk
wAlWLLd9THi9WdxK2j4iBx/xEWtEOpba92zAtnm4Jl5iIq3GGxcrUwIN5bBUftA5Xb0Szd5Dgj0F
ldlx5GCIbSLivVjLWPkkLkBX+ICuP6lhV33AqtY1UrqIl0r0Y6COx4l1iH1K9BkQplEKX6uGX4Ph
lvJnDccCtOL4h54cMbC9eD1AlF8cE4NaZVQnI/0jRVXzBmrV3KF2lHbA4JhtZAPkp6GF2veglhVg
lmOCtBRRplQAPHoloPEBRSt2pk7a8simxZ4gBxfuBt6pBNXJDeqgm+GNAKHTNhwKruDuKnQREFta
rdRYuBsWZhz5hHkcXKWLbioVsCtcxFBNpzqUMV0zpgaZyrYHAAVdTJR3EOZcSnY4VE7X9hi33K4L
m+CU68m62Kmbbw3TOB41UdRiadoLdRHEGFv9QAz0ahDE3nKOJBziHOrs2PxDyqh/hgdg2AjhYPEa
tMcBIiBScXK7X9UFt7leV4I5r4iItVdKP1OvtK1coZnUI6iMFvCdILrXEX4jkSd0PGS30iqPcdjY
8BUoLuiEy4jjs/MSIHyxVhOw/tBK+qOSs6YPCIvJBXFxNORvIarWMo1XstULrmXG9L2kKbLPLCNS
GlL5gfLbtxVQAgTAGVLm/Lio2FcwfpKUR2OYrvjzHVqtmXssvJ1hbXURVz2C1ruI9xogwQWBg6Yo
JgVZD8Qgk4l1uD2kW0yo3rir0mk9uoYvZoo1fzBIUL7TIPNW/pFt2dlYpDp64nEtHKIpQfBRApao
Qz7jZCvBaMDK20qLW3Shg+4ubOy1YlYkHCcQwlbVwguvpfzjJTLYXEr47ILYBdrsVbDeRAmq1Dse
4G2jrHcQt07bohMPK0qCANPIC+eo+oKSErTVa4qDDitlJ83AjDynvxHjD9hIVfx5icNdLiACOCur
qpYOXfEGqstqvUCIW+WXKauom3tXkGuuaEs3TwMTEynxLI+PxBcMCr9x67VsoV4u5aOgVzXEEBP4
mFVPmOyl4lVal36mKnxkdYb7JdXyOVIlHi5bbenPxC9dFS7nAeiFBVnGQFdvZBNKr56hnFtLUb/y
KnLWs3iXbEsvmIjMR1GuPRXxBrKvfmMJRLuDhUFcRpQsl8S3B54iaFlOFyUx1czMLc89yxo3phsu
rlvRC6TOL4hpeExktKa8qmGY7uXoq+oAJA9QSKA44/cQURXsnBU8LJyUtrkjaqwalNx47lkVArkI
vxSZtzZxWx1BEdlFB3fiWWjPJLnSx7VtVUSyKniB5FdyxbZ+YvsPMGwAF7kJsOJhRVY6Pw24/Qen
ggKG7PERVJfOOIwIA0heECFKUB7SBZ5UghprnxK6TfBBEqOpRKUJkTlXHqboWX0SyocKruFFJob8
zVhbIWEccLuN1sF9S62cPEo49NlALb4jQDT1OwdElltqPM5Bs6nWt+IQodfEESlH5lqH4UkRHCnc
7wXXiBa24gPZNI6iyidLGxxSpKQaXmpRLYtGQDSi+io9ZUpIZS9cy8Dd9QCfyIyV+ImQWcKx0238
QUuPERGqV5Oo/ReoSQgfUO93i4Yg0l3cRzw4ajXKNxogzhj6OM2ItUHqo6BR5EtWxZEggnXiOY0r
vqKSlapqA6fmWgf4TcXAiBDrplrmPPBGwql3hC5ZZ1BDcXK2g0yWSyjqMjheUjtzcAQ4RK22fcR5
6+IWi5XZFENfbEGOfKZOQWcYczABHiDXRkSea2MkrrFYFKnxUS6tp1UFKuXx6moweVmivSenHz1H
XUpAto5SW1aDtZYFK7cgXuwwaSI+DqoBS4t/ULbZzLaKHxCBdDGu4hDbodfcBDa7fiON1WVO4mbw
j1Ba8RtbccIJvlsYwE17nIANlUlCadXDggqfiojFDK0PEEFLu9jsCjzX8RsCwgHKXo+IQdKB3uzs
IJo2VTEPv1GXEaR2MSltTzkCop5bjhDkovmFY+Bdv4gcEgAr9RizNnm3CHMlDkRofKc44wJQDzGx
ySvOSqvtANg14C68mbhAqNlFDN55IsrwCbUBx0iI12jrH7msKralQii8JxKA2Yv64iyWy2R9XLHA
bdl0aKzJpage4t6Hb0Q59pYbUo3Bg28hRRZgC0RUDh6xpweFcYBVyY4hqQvD5jJTTipQSk7iEdqk
kN4Gy9EvtxODDtmWlq3mG6dq2ahswEqDN8V3CdOoAHUphgbrL7yBoi6Mu+YUtsB3IXtiCqkYFNSG
cQanP8wAcVExl4a3wxwNFJY+B6lwJZRQ+ZVVMAOXEW2l0cvNxnoYARyvCFSsjLOWw5/5LhmA405x
GodSrMLb5Bz+Z1zjSYmMFcnJZa7Ho+f3Kz4cMKl6ZdndrICsEvkhgKihBrbGLsJUrVlkTjOirIML
ywIMklzweeYgBhy8v1Aaym+EvAheL3KjSreI0wpyQdX7mIcOAitovxFUlNcxlm7bGZB3y9RBz8+o
a1SfuPgO59Stw25yVj35jQdWUlqi0iHkxOJlLfjuAkJFdw1DXgEAvD/IIOC69QrD3dTjAzupqo3m
ATS831LBlf3BFqhQVXtAOC1pFChQTZdX1ywRpbpp6IXeQrfsqKKPaBahmLfcISwY4gK35ekG3ovC
Neayk8QwwPlLFATFrJRgUPU4I3+I3Yy9nJwqz1BIVkSkEfDxG8oAX7Sg3ys+GVYNHmEFi3RcYaUX
IraAvmVJtYduupa22WoZ2FW1VSxWWLKCaUK8uRN4A6Euh2iGEa5w5qNOl2ichQ2sloEQYrJ9WRuW
0DzFUwHPzL4C3p/2IBBFyw9XB1lCFVeXKmDjzG+FTBIXFpruo55oMqARtQN+oCe+5ctFv1Nlr8QT
TyeqjnG/c0CLOYVZ5YFU3QXTLfXnxFcVF7UXDnVy1dOVMocl98SgWvKZfUVXtQKPtUFbN4GVKXnm
UQonjwiFoSuIQEr+UNAs9xC2j4ihRQpSyzNjoJdXIuLEilsZGml58RQgbZZkrWrVQRrmYxHCB0HM
tkKiHf1MUprb7i8oEd+IjJblym5f4Q0GzqLac8KgLNb6mAM7EFuuOJZAUDeRkJ2M4FKBzOVV+8gk
HV3iKS6DPUUVt1BanPRBpoCfuGmwLvY0hdVERRooUC1bvieTXolq374qBZK0CvEDddcyx32rO5U3
e4M5d7kBRVySDHBvMTSvpC4JngjgKnh5hVou7YkGWv4lnVlN0E6bVMC/MT0XdIoODzXmUtcnNRpg
97Cg+U2nfkmxRqQpU4wbLQXluYbButfEcONcrKWNq9uIU4WVOhzPkmoMeMnOV+kWgtrHWlFV7ZOW
CUKUsIg1z2kIBXmNQ0eGPrxCLDrOb/UQcVvEJDiVICncWlFbc6j7KWJ2U8t5jciFvxHekpofuUH7
g7hpuUU9y1IM8o4A1vyuMqNVeq2IsX7yUFxzd3UYQLR7bBWrb1AAsFW1zZcbFUq4lFe2vmNpB8xM
N5FuNimEOl7qO5Si4VKejlp9QdbceH7lIU3XIqNpuNFW3+4rHBtX1EsI2HCcWKVkVPa7fEugqT7w
iOxEX1BCUsu+So1lSC6xgFBHyrqX9kDnu5SKIC74lpjkIwYucJwY6NU5SaVinggNFK+eIhlqKLxz
FYednxK+0IHzsBVAP1kuxRLblNT3og81FZNK/MtZFd8RCbRGDuAGtVCh2Q0nNwSsIP5jXgUek39B
qb3DKtTa4+nKUtZfAoYccSqrRJh4hsDSVcNjuBYCDZ9xY63Ff4w/AitjIBtZcGrewNDfOTj8wpAe
5xmk4b3jHzitCpzzHYzbzYf5PA+5pDpOBd4/MNyGL3VuX5pl+Irc2Xp+4TMiWtHuhg5yKR4HTHlF
FFcviAGqhLfiYWBE7qoocBUvgtiQpRW65g2Wjw+SFNUst9f5Ae5Ad5SzSAbXyjQDANfySnQlWjSL
0ztckD3CaK8qUPVQehHA6eSAEVg1xkFeNB1gmCU0qyEQ4ORORlcuY2RaCxbV9xK1xCXNGviPiiDU
gaI0H7lnq3GK2rD2cwGDatvtKcWrQm4UbgpdN1HScgqkNjYOPaAIph3CVEaeGIOGm+LllrwrzLwc
9pOiVfmCi6B9+IdKo1tQuvaCqIpm1OYi9q4D6iLSsMNlLgeoKbOUcYM045bcQAaHCd+orQtPELwh
d0jcfRDdArNAhR5JRSqs4mKSnAh9yjSWEKcJQqG3z4li1upZejxHFE6ggCp+kTfAunmIUAR99S1t
z08xKVl8qiHYU83LhbbkJEsOoIhYmtQ7SFNdk0OC8+IwhsPEpmV4gCa/aWHsnPiA2fFRGhnJ7jSn
k1GWbyyHgxyDajmIC1CjlIbK8OMIcbG4hA48kaaF86x1OxURXl6uaUKD0dRIwQKAGPHcKIweklbB
JKDmyVAEebq5YWqo24VQddwSFtcEAY4uVFm+GAgCLFsKquQiEsdOEsBxIPBkdAWZdSwqo4grOVw5
KBfN9QChvNrgi1OTIttHthVKxicfpFd2fDGqm29eJQA7rnxOMuD6gXpgcRt/ZLObO5Uq6qKStp4J
rCw6M5jXi+4II5CxlATly+4QbQwZVwtuYheS3ww5dXxDNzo3CjLv4jULJyNK3bqG1SLspsL8JULd
dSrcELUsIumqqKpblpqPiUAyLAXXnZQU2r1CL+CWRS19QqRY/wARGNV3L6PQRVyAqlqIIiReYtQV
ppBTAwHNpgtJZVywVneZQXyvmIVu3BS7w6IXI1g8xL9RroKq3KvS81BsVTXGxi03W33KQts5gRUt
M05iM4egilinw8S4G1J+I1rCTR4cBNMclnv8xC7Qef8AIafkIpQ50VC6aOLgQ3qufMsFyGMAC1TF
8xWG8LirDR5ub7KkII6HUPB4mEgRyI3dovfiVKdaCgPi4Z+gL0D8Q8wldZl+8Stb4hLtSx5O/iHn
UOi/Pcbju64YJUeUU/6iXnk4WZU3Ycp8xlPpNXW9xWV63ii+blAlAiBeRYvp+A8N8xbKd7Y7DfpD
qeUX4i9C3w3ASLwwOODdjoxS3X6lasXiWRDQNJjDUAwq1iu7mhR7JVbvoPidXcDh+WF6POCA8xod
ATY90dQtsLLwWBTvuEj/AFS7C9J3/wBkZjcTEojFAN6WV7lCQwvL6lpIBQozlJpY1MgPzC2fSw2X
8j1Le30uCH3vD4gTVqE1yW9vF+XmDlpatMgbG329oXZwp4rx5lnb84CtnqU4HHIWBti5r3M+fgtp
KhlViLPCVBdHmY+DeFZxFcIAs/MePCdW/wCIV2AHb7g19ZQx4lLROKDfEpENkeH5Zaf3EBfzOaJs
PbGNkx2piw2sgsKBowmBa4APBcHEWtOfUfv0iWrC11Xwb4upbyl0plOO0wpnZ5l1QrNWXzL/ACPJ
CLdnrZMETFofuZsUtjns2AQhgaKrIABdootyyqjuzXDDajHZord2anL6dOlOkzKB51XmLWPIoSoI
BGoem+oIlaIV4iKXy1Yv4iwaLDR/UyQael2ChkAAbzzFpPDQ/iKuLq6czVD2gZ8SnUnlmIGClsGc
MegCHijz7lHC2t8udHbDHVTAQlC+gPMEvSkvmc1qDE7QviUK3svmYkVPbEVXpVIjRazqxY0535ly
HTxKTAqF9qpKwPtNtNuISKZX5ubOzstXHR5gKjTaqBEq3dFkK8CrhjVQfB4jaQLVZ3MVyrziUsgC
4MJKIrlnPucyKuA4goXQB+IUjVDmNEdBeHEBZYD8yhROaslrBdvpLCVaUE8QKS6HfUT6vTEoMu8m
kNDiu4bRzqvUNN0HUSRTL1g5dOAP3FFUV4a4ImteWolVyXwcQChQFXUOGq6KiUabcHKe5peXS8RC
BQ9xuDnqL0NV5hu6UeCDabEF2FDX4ITVKQQAJ7lrs7UTgLZ7mUdHENFtcJZvQOQKvNuupo8PECrK
8wPK/qIUcX1AcDXuYlfoiVW6f6l9PPmYIqnCoXIPSpZWl3dVUBt7hV0LC0qiVfmHQrHzGtlB0eJd
LAnmtmRYPMyV8ygK33LCkRuFvWNgtB4lrhaZsECafUvDu4Dr06qM3HMoCm3Be1lP1LGkkG8u0uXd
PVwt4Dc906KjK2Ob1CoI4V4TFtt8ReICVl/RDFbt9TstrxU4LKEaDtEUsL9EirLB1CsOLsiOJZzU
Lq5M2AVyC5Vv8QqnL7jj49dSwFKq/UTwvV7FLQXEoDU1UqNDeJYItL2coJ7nVbWWRRdg9TGGuxYs
OjxOHyeYVFs4QiqFfcNcVe7FDsuyXrAOTjmERZUHqcCC5BYCol6rxEQrpulhb6J6gULFq6lgBaOE
WhGudhpMMIUWjmURuDIvAnwnJChCzrl2CraOYlYBhO7uEoLHqYmL34QVR7uXBazhnw/CVd2A7qOO
6H5gLjNcR0lxTE66ItDPtlMaX4m0bC6PcB7UXWQHpcZN4ueWoOR7WzQprEcCCCOTdT3ENiXmIlgX
/wA8y+wg83GFsX8EeUpwkZtX+E1KY8NeItWkNlc/MFBoeFNNziA9tIRC0ELNAeBUQEBHmyEUpzgz
a21YsIcvXxFdFeUGWwA+zf8AkwQVxSAZMOV/kxhLlGwoHEQdBKymVgZeSUEauxMjVE9AqY5hTbG6
C1F1fDzDA6gggB0L42Wp+BSX9o+bjvOPcAPyBAUBs+R+YIAfQGH1AKbfzEWJp2SitIHSF5b2Cf5A
9EvlQBsHyXHiBPBf7iTRS4t5GATkLtQjo8sN3prlJSDh1CqfsUSAS5MC/wBiDWKpp/MCpW2VOnV5
EK/cJUQ9OkFRU+cmpabaREQF+bCiwjS6kOMfdOpYt9jdRSD6HAiO8NUBOCWK8BEd4uGC2XjsK/EK
UHawPzsqVBee/wBwtK04W455D0EfzKUV9tr+WbjfVuqhKq2iJ/mWBd1yKfzBEMYUEPeKsqV+4C4V
eFK/c46lxxHpiXm3I3SvAXVfiXV/iyw/MPFvhbR/TPmrHJ+5mpPvRnACKAKr3kcSQcip/cQHK29W
WDl3LpL7LajBh4qWManBB5upRDDxWEyb831EShZtX+IIvXFDWEB248IKKAekgdZjohxqlPEpxXGs
mRffHklugD9wI0tvICrwOiUMl6+CHHSqqotFGrXzcNlHyMXRJjk4ZguQ9QTstBomp2wFahC+GkLu
VKNq5A+TdO+IBW08xgTWI3CYtfEDiIHlJb8sZSxLcbLcO7uFF8HNEWhii/Fy8rR454hXQHmORp9C
DVFW4iJ2K2yBQvZVsbPHmEls6YlAHQ8I9aPhABuC2ALanacQXQmOaj8yDS+pUcB65YgLx35EowaD
kiyYRXKTJYPDnEo0VvzExVrN69wU3Q7a5gwYLIjE15QAEid5FNu1FtpQ8y3FfEaS6L6g3v6EoBYH
PiA2EVhw9wofzLsG8NlDXL3UARrHzGBRVRvae1zgdU66ldYZYJ+IpWnk1jGqbPcWrpQOZcWtgXAt
FLMozqNKeSmoi1L2HBeRxAHYPcs5LvMcHbOoUGqGUCgty6jvuvJAvQPETfNJrdNdEaNrRR7xyxtV
UDFXVN8QCL75Jir5WQwNDCZYKqlWhccKjZ4LMyAtjfCAKLXPECvC7J3g6qF6K7yAt7ragkD2qpun
zriKLUVxioCvpBFKz4jI2I5GaHOjZQjlXjzKDgf1OAQJtkBG1B+4VPKytl3I64RVGgpqAaDzFLvB
Z8SoE57ivOOLFUU0EfBaP4ilB8rYA7eVREXfRHZQowtt2nHUSGVUVIUqmDSU/JMAAPzO4D0w4N2d
w3NPhgtN0hYXAX/xKGtgcVywGHfN9xDQoOUlCVbhB0cW7YHBpBvc4lqaCO7Lal8OniJQ5vMpfG9d
xKL/AB3HIunmAKRfNR8Bvip8H8TkkI7Ja93yqdQ24iLkP6hfN3FdSrepQYecQu28+kO4mm9selo3
PIjEL05OY9s2Fm/uAuyqipr7DuYpV8VWQplHtCNmq+I1BTepgUYqqIffRMbVFxZXkWc5AKRt4ES6
2XxL/wDSAtL+Ii20+5QGqefEABl5uZRNuyoAcXBejT1Diw3DbLGolML5lApb4yJKuOChBXl5grbX
eS0Bf2wi6Sc0qX2Vr3mYS8clkUvqOH7WQgrHuVhB4WQNBi7IjZDAZXCCBDTFpDl+YirhXM0cfaFq
1oVC9dkWwIpYeniOwXDvzOsxHJb3dRAH1CJccpshK89SkJgykvxkrQr5kUIrt8VBpSj6I8YAPmXU
14ZdhzuKyUOKrmBSlPog7H9NjYdtgsUprmo6Kg5BzACqj+pacK4zgXnGVWxHJKgOK4qZZN3SJQT6
BKA2T1Gs4Gy4tj9StJ6iLx8VF7Fe6icbUomtHzA0duvEANqnMOQeiDWxXvlmKKutIQ635TABwYRs
D7D1AgNVrIiuuf3NRtVdRgC85iIJzqXMSvnuUs9ZHTAY3Ky3xtS7X5h4lSzjiH1fcUtdnNHUVg2F
ykbNUdsGBReulmW9kuCrDupwD91xFJh8xrUv0iqBQZSRSpWLGZQoO/MANWuyANttfuUxBW1HpIbP
UasWP3MRpF5eoa0E/REYVKc+4pKKz9xvEnNc1DkCikvdsirrHi5dVyAfUBJ55+YFWpaeICLMrmF9
Gt4gFq0cYV1eGwBoKHXcSwtdHcpYFJS+4pV1Y4qUo1DxMlNHGPk9cVEmwNy6hhcNddx2joZOVW92
S8taeciECw8kpR8ktI8rK9ZKGpHqJShF8Qyth2Og9PqUArzKoW0KalLF2oiINDYgKcnVQRQnKjYL
aObiVZZwtiv5CWEjShc5RfgIHIwWWanK6gpmPFxBthTcPRDnI1RLquYitsjWog5S3CFA48RgaUEZ
eW4B0N4IXQ3kgBH5IsBaCCgHHbEWxfgiuE1Vy0PwPEsPiAvZ3KKaIPEGC6+YrUNOGD3fwnCWi8lg
KUmi7EV3Eslr7m7s7lXozgLN7UpQDnL2Tl3yKQsBAc6Qo0A9E5Oj0wEGHuAdhaaZZVn4Qnlpb2JS
6B4mQXnUXtsYdEonEKhKAqvm2bR7gAUWETYWcUxGVHUKbOV4jazR7OYoRtTdsLN2e4UXZLz1AuX0
YVcVNuMwB7iFXnfEa7SeZ0ljCQDRAArblNwMrI7c4mxrB3DTwLZa6eIptU2PUTZLi2C1ovYbJ0U6
M9AbpDKqH4giEHbY0FpcqQXwrlbAhHGsgWwb6jb2qcx4SzOLzJkBAeIKYDyXzEB0DYWr+NOorVYu
iIgrnVT5/hKROTmoHqevE0ALoyPW7PROFeisScY1FRUUd/tFVWizUBwS/RKO6cX1EVWg5hDo/EEc
moGxl9xqy8GAC2PJNADmNKrj6ibftGAQOukEShYfZCYVeR6iCD8orQ+hNs/A6lJ7HcIAb3uKneM2
Cbo1obHJRnpGG6BYRBrUoAO+JSKcd+oXeRUACcPUApPBKlaNRtqCuhd0cEt1+42mDp9wQcKshLom
gdeosThnsBlxeaLOGUsCs9RytVdHEWRqpwgX14mlK0w3Hf5Igl1pk3S8d+YjZc8ZEVeu518y97Ff
EBNnTYLR9ExB8CppdhxCFOHE4gNcxgFaghKETCzm6juCjIAN9uMRl3RgQIp+iCo93Q5jRPa4iuXQ
8FSoU2jrFF0PNTkJj3OYVtxVGXLtqYEXsg6eJajgOCoKMCrxXEBqEvniAU0OPMTQuyEEDQcTmG+m
ww6fmIuNeUQV+lwarLHMFS8P6lihbO4FIepGgUFmsCsbIQm2z1KnVVidQqp0xBPByuoMOA8sBvMQ
AKpGrlc+SYxPsD9zDCG1ELhU7IxNmCWsOiLCL0ruIIWvr1FONVfUqroOZpHjBgbgfEXgLHR3EgLH
qH0/Oom1IfhiqwscrxG7FhweIVDdplShmR6iDYFFFWbEYYA+v/zEcGnxAN6PNykA61CALA4jWw7q
ArtfX8xIhLtr4lLRrciy7R2dkBlC0cj9Q8VKnEXjiFseyw+IKWq5uD4EzO4l3wUe4+Q/iijkvLqL
D8gRUmKdhFQWGSk4ouHpUj+oVVSqcS12UNekC8w5jZtS/EZDYffZLeAtXLhDb/iNV5D+ZRwReFi0
qbWUilLmbT4SyxVv4mABX3i1O7wfECls8TCtVaag2Utd+4hgHxZxBDawMYBs0s8cxOLg2yGq3cbO
jpwEXk32Ex1Wt/DCGiuNhB6PpjZ8Av5iOI8wCBQglF1zlTRFKPEsEWW8x3za+Em4Teo73wnJSXwB
LKQ0NqHSK3weocMXeYaYGxKLhyWoC0FGCKXe2cRq/wATB7BUFF1TjOoWmkLtCgXl/URujL0wtE49
hKPnGTguCaSxqq9S6PHP4myFN4gCwunpipoEZfiVatQZULCmt86oMigrnJtdNcQpxT3QRFm9eCom
G7r8yoBV5hQt0MotZqOAS+YgLXzco3dwNA0r8QgByqhYNEvxDmoXaQFj+ZRDncsXIRFbRfUCgw7E
s2AmVOAcndShYUeKSFNC/CI2CHghh1CoECRVQccw7DhW0RBaojiwoLS3hGnFV4jNKrOLjZ17A6iq
pS9qXscnUsB11VdRsAEGMw1tcSyos+SUhLhZuiXYpYx3jPhiaq5ceBYsquBPHiI4W1YiVDhwUYtF
qs2gKey45l7u4ClwBYMlfH4RXU2c1HZL4kSjaMwmAd+ZYhQ7lRyp6Yg7XvxEDCvPuV9GJUTnDwyx
y53AK4f4iWDfKVhD+57XJBHJlgAIX1FC3yMQKNOUlkNA7kVRQV2ZGkBXJSJm1p4QiDSm1sJhXt8x
VKB+k520CZLA5+IjUL7h1RvDBtFPRLk+HRDqroFIlVt5o5l+wbozmCAU81U4U1ug8RiynjOYqJoS
mHnoX0czoV3yxmcvUKDKbl6RE8E4JWhpDzChyHEqcV9Es2FeYJc07qKIs3eJcprZlkJVu9l6yHER
FseJzKt18Q5jaqa60OiA6qHlA/mIx2LIWV09wSj6FiLXb8Ru8plZHIe4ESr6ENCFp8RBaC6rmBQq
5yRMAQYy8orrYvTxCVt11LKD8QSRTeq4jBNA5Ooos/o1nX1rsGCYe4SwdHOS61gOcg9L8iCy2F9Q
Ou3pMZZ7QS3vSPJd06Qk4Hg8QUInpFJHO4HT/Z0H3UvrKLSAqlo8nUrdXFEJWjbCZWcdwHDK0hJE
tI45A7CWg1GpUvgFOFkoDhf1LowY3aAA2vaQKW8KjpWo265WKxB9wIAd4mtNvcVmdwJDm+LgEX0l
mH5RLV481HTnJl8RPhv2lEpq+Lmjd4+OYdN542HcHZUCJGy4cGh5Zy5XxEO54lIS/wC8AM1Vu5dK
rDjhBYKpqneYbBQ8V/7xBwtaeR1CxaW4hPMOTzABLMnpLmXzYji1iW1yw6l0sgKiKBySzlR8xsQc
OTuW93l3EApgqmJdwAAWwJVkYihx+4FAsDqDsRUv1G2WuIRUFcGiFhcQyAq2K9y4gp6ixooHHuJ1
aNyKwprmLmqu5wwWn5iF2VXFw5dnFR28QvuGDG6lijiXhtOY0KaddTGXb4jfZV8VxEQ2znJUNrfB
FLLvwsiKKIQBc1xRCIm+ZnK32QaGiP3L7texyYrVp48RK4DscBrRRA0HM49J5qUVTR8Q0A9IYrG3
uAuwSxA5DjqYDSGJwHEei8LzUCwtMDSm+JovL4nangjp0fEEC12QKAQNslWs5yyNsXHGwODfHUbA
C7x3AaKKvZVFI2WrxL6fDXEaXLPNShKznJwCx3GqUM+V2V8RLGvcbBYmQQ+MqJMeo2VcupUGCWrE
izEOu4aVFdUQL2PMEIB5zlHfquZgseJdYLfMBTVcxBd3T8RLy75ZoGNcj4FFzgLfZkZUazmo2Jo8
sT1PlCasNlVKOTZyQ6nWQOXgF1x8Qj0R22LK9zbjC9CXKUS2MuIppahBH7GXaDhbrmbKw7c5FmTA
vlpqNQW1WUlqCy5xFSiOeKj2CW8C9BiBG76epjQ3qbDYvBA6pPctSVL0ytCICAOO6g73qdQRDh4u
Nst5dyWBZ5uJ58RQ4bFYFW8Y5FRxVRbQLoaNntficHwznJc7JfUdS6hG7LuEudTYuOaj/nUW0MYL
AWoIpe8zPp4iNXBRVekcbpV7hAV1BmLReS2y4KmnmEK0bzDQHMMOeLqJpip9/MdNDCH4i0i+KgMa
26jiTGcF7zzFh14l1s7hro11Bo9LG9rGI6UFcQ5HIxTipQjXq+okXYb6swgxFrbfMoqCVxUEG/CJ
COWXQqh1SDxCoPqPAsHtkBH5gpF8ksiCnnZaEO8Kic3niCiFGFicsXZ6NlADWAVdoyGi7fmGB1UG
UGjiMhO8xEFCvJFbO7htnRCSy2rjtDwQL9Y6r5CJ6lmaGO7KyOL4iGJWwdPEFoP3AefMJWEH2djf
ygKjtLibN4IBsO4SkoogoSDa+JUsBxAXHKTJa7r7lBWPPMVKM7mtdQbl5GHXiALUZQ6eJc0HhLIm
3yRF4AoTikx8xWjNwiCr2aCH4idjkrTavOy2PiKm0XFAfuYDtEa+4bUVQuNkNI8waJ54h2D1nE+Z
cJbRwRHiuYRyjxU8Fy2HAtnKnNcy2HxNJ3BT2nn7i2g+iJA62DhOJBQUetmIcW1+ILg0CZKun/lR
zgWVxE0biQrCoW8s6nLzc5GmxOLwJLgODK8uCXa3fmJ6KJzuWnmIZ4SBYCJPEcIlIQeY48jxsEK6
Muso5riKNfEyV4QQmL3NFO5AXe4IalwbwxRLudlFjzUyjpLqBtmYMEmxSxgF0VHrpUNdtjh+Ywgo
L8QqsNrOo8QMY2xuorjtRw8GLwHyTVLBMT90wNZMj1HoLPEIpAhaOBgD9xOrbl/ZLLWkpf1OAxYL
DhKFHAw8zU2r+0SgnR8QcnXSDsuhFffRlUAVUSr7iWhxcG4VcFSlfMdA7CEMQgmjxUbd7cdN8tRa
FxqtsEFbI1D4lHhiXKmg7geXUWwUbLAaoDqDfFkCuWk8EpZMgPVzTTXLICoXncqqCeKjzYMykx8x
aBORuEpePUKztmOdxLeiUOF9RtG+cTzGV04uNY9kUGiMvFZd8RCyuG5hl1qoryCAuG5xFaEH6mZM
uhi1OuIoMLNcRIWaE58NgXi609Nxrr5j5+CKvgTidLHdGDHC93ED0itX2xLHmGk8QUmFCeyf/9k=


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

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

--=-tkzN+QYEI59Tez8y2Lgk--



From xen-devel-bounces@lists.xen.org Tue Sep 04 12:27:52 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Sep 2012 12:27:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T8sDq-0000Pg-9x; Tue, 04 Sep 2012 12:27:14 +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 1T8sDo-0000PY-OR
	for xen-devel@lists.xen.org; Tue, 04 Sep 2012 12:27:12 +0000
Received: from [85.158.143.99:7786] by server-3.bemta-4.messagelabs.com id
	E0/FB-08232-0A3F5405; Tue, 04 Sep 2012 12:27:12 +0000
X-Env-Sender: ben.guthro@gmail.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1346761628!27869066!1
X-Originating-IP: [209.85.223.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8810 invoked from network); 4 Sep 2012 12:27:09 -0000
Received: from mail-ie0-f173.google.com (HELO mail-ie0-f173.google.com)
	(209.85.223.173)
	by server-3.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Sep 2012 12:27:09 -0000
Received: by iebc10 with SMTP id c10so5736823ieb.32
	for <xen-devel@lists.xen.org>; Tue, 04 Sep 2012 05:27:07 -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=yRZ8GXnqKuhD33X9+lLeBuaXAqBQhXSfU1XFERCvbDo=;
	b=0KktDlonl59g04X4rxFYmob/5EUSSJpmwIzkMD5Jqh64u77DK9B1dhWbeH9aalRAsd
	marQ6zt6xZUQsCogAS3S+cmb6ryBiJtCQEd7s1kKWVINp0xTwZ278JXrbmyYaCwGgbM7
	8MbapTCPE+cp+EvcmEXVjS2AdRacO5RgzCK4tFp5L79Mj9byp+tZIUXDVkAl24z8O9p9
	M93yCM3x3UOO106Hewg4ctsUy9Hc/i6Nh+CQIrXzP8CI4xs+OUJw2wGjbQvRzETSqDvI
	ewUZA294JRsjqCCOKAy0EnAgtIFDBQ9kdyVt2/vqk9eBe5ueTw9/2GwVWVgRRuKd80H6
	rI/w==
MIME-Version: 1.0
Received: by 10.50.180.129 with SMTP id do1mr13753956igc.28.1346761627663;
	Tue, 04 Sep 2012 05:27:07 -0700 (PDT)
Received: by 10.64.28.203 with HTTP; Tue, 4 Sep 2012 05:27:07 -0700 (PDT)
In-Reply-To: <504494FB0200007800098398@nat28.tlf.novell.com>
References: <CAOvdn6WwgBD-2yf1uu3m9-16=Tb5KUrybXf2KibtnxKbP7YtwA@mail.gmail.com>
	<CAOvdn6UBW-yTOMd3YSf5M9JiHLRivyaKL-qzcKG8epszqaKmGg@mail.gmail.com>
	<20120807163320.GC15053@phenom.dumpdata.com>
	<CAOvdn6XcRGKtJxGwJO8J+ZBJr89wfTLc1woW5rhtMM540H9h1w@mail.gmail.com>
	<CAOvdn6XUoSeGoo7X=AJ1kpDxZB9HZEv+TJ4v-=FHcyR4=CHK-w@mail.gmail.com>
	<502240F302000078000937A6@nat28.tlf.novell.com>
	<CAOvdn6WN3kxC8Bb9g6MpfLULu47EGSGCtajPc-SFeJ-8VSUQDQ@mail.gmail.com>
	<CAOvdn6Xk1inm1hU55i0phU2qvSWyJLNoyDdn43biBAY2OewPtw@mail.gmail.com>
	<5023F5400200007800093F4E@nat28.tlf.novell.com>
	<CAOvdn6U-f3C4U8xVPvDyRFkFFLkbfiCXg_n+9zgA9V5u+q5jfw@mail.gmail.com>
	<5023F8B80200007800093F8C@nat28.tlf.novell.com>
	<CAOvdn6XKHfete_+=Hkvt20G7_cJ-4i8+9j9YD30OxzQ16Ru-+g@mail.gmail.com>
	<5024CB720200007800094124@nat28.tlf.novell.com>
	<CAOvdn6VVJdhWVYa-gNVt3euE4AbGi1TijUCUd1wGzv0SCWEUYA@mail.gmail.com>
	<CAOvdn6USnG9Y4MNBhrDZmob0oJ8BgFfKTvFEhcKbXDxNmzfZ-Q@mail.gmail.com>
	<502B75BA0200007800094FD4@nat28.tlf.novell.com>
	<CAOvdn6Ww5oEj6Xg=XT4dWCYWUBuOdPqLz-CqNjz4HmCScE+==g@mail.gmail.com>
	<CAOvdn6Wsjds_dmZ0dwDTYmD-o-OqjBH5-b9mitAuUADE+A4_ag@mail.gmail.com>
	<502BB8FD02000078000951E0@nat28.tlf.novell.com>
	<CAOvdn6VD6bp13F-tvYdkBsj4hkhE7PTGZrapndtdHrDKeZqccg@mail.gmail.com>
	<502CCC0002000078000955C4@nat28.tlf.novell.com>
	<CAOvdn6VEuX7R2_wz74ZvCxMjC-=YUir9kP5sdxEVaKVspRUd_w@mail.gmail.com>
	<502CF0A8020000780009574E@nat28.tlf.novell.com>
	<CAOvdn6VsZvn_1TCWYeuyY5YuTcP8=miK2KwE4583nsj6Qjb_vg@mail.gmail.com>
	<504494FB0200007800098398@nat28.tlf.novell.com>
Date: Tue, 4 Sep 2012 08:27:07 -0400
X-Google-Sender-Auth: jbDfHIwwWJ1OuqyGo196_lHWaUc
Message-ID: <CAOvdn6UT13qvWbMyfZkWND03RoVKVSgb6wW4yqTUpuBYEX01Dg@mail.gmail.com>
From: Ben Guthro <ben@guthro.net>
To: Jan Beulich <JBeulich@suse.com>
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>, john.baboval@citrix.com,
	Thomas Goetz <thomas.goetz@citrix.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen4.2 S3 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

I've put the console log of this test run here:
https://citrix.sharefile.com/d/sdc383e252fb41c5a

(again, so as not to clog everyone's inbox)

I have not yet gone through the log in its entirety yet, but thought I
would first send it to you to see if you had something in particular
you were looking for.

The file name is console-S3-MSI.txt


On Mon, Sep 3, 2012 at 5:31 AM, Jan Beulich <JBeulich@suse.com> wrote:
>>>> On 16.08.12 at 13:56, Ben Guthro <ben@guthro.net> wrote:
>> Please let me know if there are anything else you'd like me to experiment
>> with.
>
> Attached a first take at a debugging patch.
>
> While putting this together I realized that the situation gets
> complicated by the fact that plain Linux 3.2.23 doesn't even
> have support for post-S3 MSI restoration, so much would
> depend on how exactly this is implemented in the kernel
> you're running (i.e. whether you have a _complete_ backport
> in place). I suppose you must be having some support for this
> patched in, otherwise I wouldn't understand why things work
> without IOMMU/interrupt remapping.
>
> Jan
>

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

From xen-devel-bounces@lists.xen.org Tue Sep 04 12:27:52 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Sep 2012 12:27:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T8sDq-0000Pg-9x; Tue, 04 Sep 2012 12:27:14 +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 1T8sDo-0000PY-OR
	for xen-devel@lists.xen.org; Tue, 04 Sep 2012 12:27:12 +0000
Received: from [85.158.143.99:7786] by server-3.bemta-4.messagelabs.com id
	E0/FB-08232-0A3F5405; Tue, 04 Sep 2012 12:27:12 +0000
X-Env-Sender: ben.guthro@gmail.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1346761628!27869066!1
X-Originating-IP: [209.85.223.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8810 invoked from network); 4 Sep 2012 12:27:09 -0000
Received: from mail-ie0-f173.google.com (HELO mail-ie0-f173.google.com)
	(209.85.223.173)
	by server-3.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Sep 2012 12:27:09 -0000
Received: by iebc10 with SMTP id c10so5736823ieb.32
	for <xen-devel@lists.xen.org>; Tue, 04 Sep 2012 05:27:07 -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=yRZ8GXnqKuhD33X9+lLeBuaXAqBQhXSfU1XFERCvbDo=;
	b=0KktDlonl59g04X4rxFYmob/5EUSSJpmwIzkMD5Jqh64u77DK9B1dhWbeH9aalRAsd
	marQ6zt6xZUQsCogAS3S+cmb6ryBiJtCQEd7s1kKWVINp0xTwZ278JXrbmyYaCwGgbM7
	8MbapTCPE+cp+EvcmEXVjS2AdRacO5RgzCK4tFp5L79Mj9byp+tZIUXDVkAl24z8O9p9
	M93yCM3x3UOO106Hewg4ctsUy9Hc/i6Nh+CQIrXzP8CI4xs+OUJw2wGjbQvRzETSqDvI
	ewUZA294JRsjqCCOKAy0EnAgtIFDBQ9kdyVt2/vqk9eBe5ueTw9/2GwVWVgRRuKd80H6
	rI/w==
MIME-Version: 1.0
Received: by 10.50.180.129 with SMTP id do1mr13753956igc.28.1346761627663;
	Tue, 04 Sep 2012 05:27:07 -0700 (PDT)
Received: by 10.64.28.203 with HTTP; Tue, 4 Sep 2012 05:27:07 -0700 (PDT)
In-Reply-To: <504494FB0200007800098398@nat28.tlf.novell.com>
References: <CAOvdn6WwgBD-2yf1uu3m9-16=Tb5KUrybXf2KibtnxKbP7YtwA@mail.gmail.com>
	<CAOvdn6UBW-yTOMd3YSf5M9JiHLRivyaKL-qzcKG8epszqaKmGg@mail.gmail.com>
	<20120807163320.GC15053@phenom.dumpdata.com>
	<CAOvdn6XcRGKtJxGwJO8J+ZBJr89wfTLc1woW5rhtMM540H9h1w@mail.gmail.com>
	<CAOvdn6XUoSeGoo7X=AJ1kpDxZB9HZEv+TJ4v-=FHcyR4=CHK-w@mail.gmail.com>
	<502240F302000078000937A6@nat28.tlf.novell.com>
	<CAOvdn6WN3kxC8Bb9g6MpfLULu47EGSGCtajPc-SFeJ-8VSUQDQ@mail.gmail.com>
	<CAOvdn6Xk1inm1hU55i0phU2qvSWyJLNoyDdn43biBAY2OewPtw@mail.gmail.com>
	<5023F5400200007800093F4E@nat28.tlf.novell.com>
	<CAOvdn6U-f3C4U8xVPvDyRFkFFLkbfiCXg_n+9zgA9V5u+q5jfw@mail.gmail.com>
	<5023F8B80200007800093F8C@nat28.tlf.novell.com>
	<CAOvdn6XKHfete_+=Hkvt20G7_cJ-4i8+9j9YD30OxzQ16Ru-+g@mail.gmail.com>
	<5024CB720200007800094124@nat28.tlf.novell.com>
	<CAOvdn6VVJdhWVYa-gNVt3euE4AbGi1TijUCUd1wGzv0SCWEUYA@mail.gmail.com>
	<CAOvdn6USnG9Y4MNBhrDZmob0oJ8BgFfKTvFEhcKbXDxNmzfZ-Q@mail.gmail.com>
	<502B75BA0200007800094FD4@nat28.tlf.novell.com>
	<CAOvdn6Ww5oEj6Xg=XT4dWCYWUBuOdPqLz-CqNjz4HmCScE+==g@mail.gmail.com>
	<CAOvdn6Wsjds_dmZ0dwDTYmD-o-OqjBH5-b9mitAuUADE+A4_ag@mail.gmail.com>
	<502BB8FD02000078000951E0@nat28.tlf.novell.com>
	<CAOvdn6VD6bp13F-tvYdkBsj4hkhE7PTGZrapndtdHrDKeZqccg@mail.gmail.com>
	<502CCC0002000078000955C4@nat28.tlf.novell.com>
	<CAOvdn6VEuX7R2_wz74ZvCxMjC-=YUir9kP5sdxEVaKVspRUd_w@mail.gmail.com>
	<502CF0A8020000780009574E@nat28.tlf.novell.com>
	<CAOvdn6VsZvn_1TCWYeuyY5YuTcP8=miK2KwE4583nsj6Qjb_vg@mail.gmail.com>
	<504494FB0200007800098398@nat28.tlf.novell.com>
Date: Tue, 4 Sep 2012 08:27:07 -0400
X-Google-Sender-Auth: jbDfHIwwWJ1OuqyGo196_lHWaUc
Message-ID: <CAOvdn6UT13qvWbMyfZkWND03RoVKVSgb6wW4yqTUpuBYEX01Dg@mail.gmail.com>
From: Ben Guthro <ben@guthro.net>
To: Jan Beulich <JBeulich@suse.com>
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>, john.baboval@citrix.com,
	Thomas Goetz <thomas.goetz@citrix.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen4.2 S3 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

I've put the console log of this test run here:
https://citrix.sharefile.com/d/sdc383e252fb41c5a

(again, so as not to clog everyone's inbox)

I have not yet gone through the log in its entirety yet, but thought I
would first send it to you to see if you had something in particular
you were looking for.

The file name is console-S3-MSI.txt


On Mon, Sep 3, 2012 at 5:31 AM, Jan Beulich <JBeulich@suse.com> wrote:
>>>> On 16.08.12 at 13:56, Ben Guthro <ben@guthro.net> wrote:
>> Please let me know if there are anything else you'd like me to experiment
>> with.
>
> Attached a first take at a debugging patch.
>
> While putting this together I realized that the situation gets
> complicated by the fact that plain Linux 3.2.23 doesn't even
> have support for post-S3 MSI restoration, so much would
> depend on how exactly this is implemented in the kernel
> you're running (i.e. whether you have a _complete_ backport
> in place). I suppose you must be having some support for this
> patched in, otherwise I wouldn't understand why things work
> without IOMMU/interrupt remapping.
>
> Jan
>

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

From xen-devel-bounces@lists.xen.org Tue Sep 04 12:49:50 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Sep 2012 12: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 1T8sZF-0000dp-OR; Tue, 04 Sep 2012 12:49:21 +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 1T8sZD-0000dk-Hk
	for xen-devel@lists.xen.org; Tue, 04 Sep 2012 12:49:19 +0000
Received: from [85.158.139.83:56075] by server-5.bemta-5.messagelabs.com id
	34/D4-30514-EC8F5405; Tue, 04 Sep 2012 12:49:18 +0000
X-Env-Sender: ben.guthro@gmail.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1346762956!28316059!1
X-Originating-IP: [209.85.210.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1761 invoked from network); 4 Sep 2012 12:49:17 -0000
Received: from mail-iy0-f173.google.com (HELO mail-iy0-f173.google.com)
	(209.85.210.173)
	by server-12.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Sep 2012 12:49:17 -0000
Received: by iakx26 with SMTP id x26so11044589iak.32
	for <xen-devel@lists.xen.org>; Tue, 04 Sep 2012 05:49: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;
	bh=Tv8aaB7aJsLJRzkmnfMTlcyCoQ9R0311sWvEW8wF+4Y=;
	b=gNJig9RtwNSiDupbXl+WR4VVejw4AHXx7gLm2mQvjtIxTtiSdNAogF/JuSDFvwiBLL
	/dVcXecbAkcgSZ6WJUnxOyBAxBPB/GzZvoo9Br8ukwk5CZM3T29TTlwLQqF3gzun0tKm
	x+7EhPIZ196+X1hH2ajjYZmND5lDPN6I5+8uN8gs24xn5AF62plFyJJLTeqsqEPvdKDc
	PXttJbSGzdAgqBIul6luRLYQdvx2msaRG+njhDqFnee+HyzCZ2HFpPpm40AZj0DeQueB
	qh1glU1k2DWe3vpoTymGegHtWiHgtfssEAoTR0zm0+l+wliS+4L7AvmGlGBc0f8pibSB
	l/Kw==
MIME-Version: 1.0
Received: by 10.50.236.39 with SMTP id ur7mr13494799igc.62.1346762955878; Tue,
	04 Sep 2012 05:49:15 -0700 (PDT)
Received: by 10.64.28.203 with HTTP; Tue, 4 Sep 2012 05:49:15 -0700 (PDT)
In-Reply-To: <CAOvdn6UT13qvWbMyfZkWND03RoVKVSgb6wW4yqTUpuBYEX01Dg@mail.gmail.com>
References: <CAOvdn6WwgBD-2yf1uu3m9-16=Tb5KUrybXf2KibtnxKbP7YtwA@mail.gmail.com>
	<CAOvdn6UBW-yTOMd3YSf5M9JiHLRivyaKL-qzcKG8epszqaKmGg@mail.gmail.com>
	<20120807163320.GC15053@phenom.dumpdata.com>
	<CAOvdn6XcRGKtJxGwJO8J+ZBJr89wfTLc1woW5rhtMM540H9h1w@mail.gmail.com>
	<CAOvdn6XUoSeGoo7X=AJ1kpDxZB9HZEv+TJ4v-=FHcyR4=CHK-w@mail.gmail.com>
	<502240F302000078000937A6@nat28.tlf.novell.com>
	<CAOvdn6WN3kxC8Bb9g6MpfLULu47EGSGCtajPc-SFeJ-8VSUQDQ@mail.gmail.com>
	<CAOvdn6Xk1inm1hU55i0phU2qvSWyJLNoyDdn43biBAY2OewPtw@mail.gmail.com>
	<5023F5400200007800093F4E@nat28.tlf.novell.com>
	<CAOvdn6U-f3C4U8xVPvDyRFkFFLkbfiCXg_n+9zgA9V5u+q5jfw@mail.gmail.com>
	<5023F8B80200007800093F8C@nat28.tlf.novell.com>
	<CAOvdn6XKHfete_+=Hkvt20G7_cJ-4i8+9j9YD30OxzQ16Ru-+g@mail.gmail.com>
	<5024CB720200007800094124@nat28.tlf.novell.com>
	<CAOvdn6VVJdhWVYa-gNVt3euE4AbGi1TijUCUd1wGzv0SCWEUYA@mail.gmail.com>
	<CAOvdn6USnG9Y4MNBhrDZmob0oJ8BgFfKTvFEhcKbXDxNmzfZ-Q@mail.gmail.com>
	<502B75BA0200007800094FD4@nat28.tlf.novell.com>
	<CAOvdn6Ww5oEj6Xg=XT4dWCYWUBuOdPqLz-CqNjz4HmCScE+==g@mail.gmail.com>
	<CAOvdn6Wsjds_dmZ0dwDTYmD-o-OqjBH5-b9mitAuUADE+A4_ag@mail.gmail.com>
	<502BB8FD02000078000951E0@nat28.tlf.novell.com>
	<CAOvdn6VD6bp13F-tvYdkBsj4hkhE7PTGZrapndtdHrDKeZqccg@mail.gmail.com>
	<502CCC0002000078000955C4@nat28.tlf.novell.com>
	<CAOvdn6VEuX7R2_wz74ZvCxMjC-=YUir9kP5sdxEVaKVspRUd_w@mail.gmail.com>
	<502CF0A8020000780009574E@nat28.tlf.novell.com>
	<CAOvdn6VsZvn_1TCWYeuyY5YuTcP8=miK2KwE4583nsj6Qjb_vg@mail.gmail.com>
	<504494FB0200007800098398@nat28.tlf.novell.com>
	<CAOvdn6UT13qvWbMyfZkWND03RoVKVSgb6wW4yqTUpuBYEX01Dg@mail.gmail.com>
Date: Tue, 4 Sep 2012 08:49:15 -0400
X-Google-Sender-Auth: o_vHqDN8syYD6hGUJZjXqiaTysc
Message-ID: <CAOvdn6W+XZiiJyUb04WwMEh+WFB5Dam+NLpKa1DuTCGLU=BuaA@mail.gmail.com>
From: Ben Guthro <ben@guthro.net>
To: Jan Beulich <JBeulich@suse.com>
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>, john.baboval@citrix.com,
	Thomas Goetz <thomas.goetz@citrix.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen4.2 S3 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

I forgot to address your dom0 kernel concern -

All of these tests have been run with Konrad Wilk's acpi-s3.vX branches.

The later kernels took more recent branches, while the 3.2.yy kernels
used an older (but still functional) branch (acpi-s3.v7)

For reference:
http://git.kernel.org/?p=linux/kernel/git/konrad/xen.git;a=shortlog;h=refs/heads/devel/acpi-s3.v7




On Tue, Sep 4, 2012 at 8:27 AM, Ben Guthro <ben@guthro.net> wrote:
> I've put the console log of this test run here:
> https://citrix.sharefile.com/d/sdc383e252fb41c5a
>
> (again, so as not to clog everyone's inbox)
>
> I have not yet gone through the log in its entirety yet, but thought I
> would first send it to you to see if you had something in particular
> you were looking for.
>
> The file name is console-S3-MSI.txt
>
>
> On Mon, Sep 3, 2012 at 5:31 AM, Jan Beulich <JBeulich@suse.com> wrote:
>>>>> On 16.08.12 at 13:56, Ben Guthro <ben@guthro.net> wrote:
>>> Please let me know if there are anything else you'd like me to experiment
>>> with.
>>
>> Attached a first take at a debugging patch.
>>
>> While putting this together I realized that the situation gets
>> complicated by the fact that plain Linux 3.2.23 doesn't even
>> have support for post-S3 MSI restoration, so much would
>> depend on how exactly this is implemented in the kernel
>> you're running (i.e. whether you have a _complete_ backport
>> in place). I suppose you must be having some support for this
>> patched in, otherwise I wouldn't understand why things work
>> without IOMMU/interrupt remapping.
>>
>> Jan
>>

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

From xen-devel-bounces@lists.xen.org Tue Sep 04 12:49:50 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Sep 2012 12: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 1T8sZF-0000dp-OR; Tue, 04 Sep 2012 12:49:21 +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 1T8sZD-0000dk-Hk
	for xen-devel@lists.xen.org; Tue, 04 Sep 2012 12:49:19 +0000
Received: from [85.158.139.83:56075] by server-5.bemta-5.messagelabs.com id
	34/D4-30514-EC8F5405; Tue, 04 Sep 2012 12:49:18 +0000
X-Env-Sender: ben.guthro@gmail.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1346762956!28316059!1
X-Originating-IP: [209.85.210.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1761 invoked from network); 4 Sep 2012 12:49:17 -0000
Received: from mail-iy0-f173.google.com (HELO mail-iy0-f173.google.com)
	(209.85.210.173)
	by server-12.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Sep 2012 12:49:17 -0000
Received: by iakx26 with SMTP id x26so11044589iak.32
	for <xen-devel@lists.xen.org>; Tue, 04 Sep 2012 05:49: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;
	bh=Tv8aaB7aJsLJRzkmnfMTlcyCoQ9R0311sWvEW8wF+4Y=;
	b=gNJig9RtwNSiDupbXl+WR4VVejw4AHXx7gLm2mQvjtIxTtiSdNAogF/JuSDFvwiBLL
	/dVcXecbAkcgSZ6WJUnxOyBAxBPB/GzZvoo9Br8ukwk5CZM3T29TTlwLQqF3gzun0tKm
	x+7EhPIZ196+X1hH2ajjYZmND5lDPN6I5+8uN8gs24xn5AF62plFyJJLTeqsqEPvdKDc
	PXttJbSGzdAgqBIul6luRLYQdvx2msaRG+njhDqFnee+HyzCZ2HFpPpm40AZj0DeQueB
	qh1glU1k2DWe3vpoTymGegHtWiHgtfssEAoTR0zm0+l+wliS+4L7AvmGlGBc0f8pibSB
	l/Kw==
MIME-Version: 1.0
Received: by 10.50.236.39 with SMTP id ur7mr13494799igc.62.1346762955878; Tue,
	04 Sep 2012 05:49:15 -0700 (PDT)
Received: by 10.64.28.203 with HTTP; Tue, 4 Sep 2012 05:49:15 -0700 (PDT)
In-Reply-To: <CAOvdn6UT13qvWbMyfZkWND03RoVKVSgb6wW4yqTUpuBYEX01Dg@mail.gmail.com>
References: <CAOvdn6WwgBD-2yf1uu3m9-16=Tb5KUrybXf2KibtnxKbP7YtwA@mail.gmail.com>
	<CAOvdn6UBW-yTOMd3YSf5M9JiHLRivyaKL-qzcKG8epszqaKmGg@mail.gmail.com>
	<20120807163320.GC15053@phenom.dumpdata.com>
	<CAOvdn6XcRGKtJxGwJO8J+ZBJr89wfTLc1woW5rhtMM540H9h1w@mail.gmail.com>
	<CAOvdn6XUoSeGoo7X=AJ1kpDxZB9HZEv+TJ4v-=FHcyR4=CHK-w@mail.gmail.com>
	<502240F302000078000937A6@nat28.tlf.novell.com>
	<CAOvdn6WN3kxC8Bb9g6MpfLULu47EGSGCtajPc-SFeJ-8VSUQDQ@mail.gmail.com>
	<CAOvdn6Xk1inm1hU55i0phU2qvSWyJLNoyDdn43biBAY2OewPtw@mail.gmail.com>
	<5023F5400200007800093F4E@nat28.tlf.novell.com>
	<CAOvdn6U-f3C4U8xVPvDyRFkFFLkbfiCXg_n+9zgA9V5u+q5jfw@mail.gmail.com>
	<5023F8B80200007800093F8C@nat28.tlf.novell.com>
	<CAOvdn6XKHfete_+=Hkvt20G7_cJ-4i8+9j9YD30OxzQ16Ru-+g@mail.gmail.com>
	<5024CB720200007800094124@nat28.tlf.novell.com>
	<CAOvdn6VVJdhWVYa-gNVt3euE4AbGi1TijUCUd1wGzv0SCWEUYA@mail.gmail.com>
	<CAOvdn6USnG9Y4MNBhrDZmob0oJ8BgFfKTvFEhcKbXDxNmzfZ-Q@mail.gmail.com>
	<502B75BA0200007800094FD4@nat28.tlf.novell.com>
	<CAOvdn6Ww5oEj6Xg=XT4dWCYWUBuOdPqLz-CqNjz4HmCScE+==g@mail.gmail.com>
	<CAOvdn6Wsjds_dmZ0dwDTYmD-o-OqjBH5-b9mitAuUADE+A4_ag@mail.gmail.com>
	<502BB8FD02000078000951E0@nat28.tlf.novell.com>
	<CAOvdn6VD6bp13F-tvYdkBsj4hkhE7PTGZrapndtdHrDKeZqccg@mail.gmail.com>
	<502CCC0002000078000955C4@nat28.tlf.novell.com>
	<CAOvdn6VEuX7R2_wz74ZvCxMjC-=YUir9kP5sdxEVaKVspRUd_w@mail.gmail.com>
	<502CF0A8020000780009574E@nat28.tlf.novell.com>
	<CAOvdn6VsZvn_1TCWYeuyY5YuTcP8=miK2KwE4583nsj6Qjb_vg@mail.gmail.com>
	<504494FB0200007800098398@nat28.tlf.novell.com>
	<CAOvdn6UT13qvWbMyfZkWND03RoVKVSgb6wW4yqTUpuBYEX01Dg@mail.gmail.com>
Date: Tue, 4 Sep 2012 08:49:15 -0400
X-Google-Sender-Auth: o_vHqDN8syYD6hGUJZjXqiaTysc
Message-ID: <CAOvdn6W+XZiiJyUb04WwMEh+WFB5Dam+NLpKa1DuTCGLU=BuaA@mail.gmail.com>
From: Ben Guthro <ben@guthro.net>
To: Jan Beulich <JBeulich@suse.com>
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>, john.baboval@citrix.com,
	Thomas Goetz <thomas.goetz@citrix.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen4.2 S3 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

I forgot to address your dom0 kernel concern -

All of these tests have been run with Konrad Wilk's acpi-s3.vX branches.

The later kernels took more recent branches, while the 3.2.yy kernels
used an older (but still functional) branch (acpi-s3.v7)

For reference:
http://git.kernel.org/?p=linux/kernel/git/konrad/xen.git;a=shortlog;h=refs/heads/devel/acpi-s3.v7




On Tue, Sep 4, 2012 at 8:27 AM, Ben Guthro <ben@guthro.net> wrote:
> I've put the console log of this test run here:
> https://citrix.sharefile.com/d/sdc383e252fb41c5a
>
> (again, so as not to clog everyone's inbox)
>
> I have not yet gone through the log in its entirety yet, but thought I
> would first send it to you to see if you had something in particular
> you were looking for.
>
> The file name is console-S3-MSI.txt
>
>
> On Mon, Sep 3, 2012 at 5:31 AM, Jan Beulich <JBeulich@suse.com> wrote:
>>>>> On 16.08.12 at 13:56, Ben Guthro <ben@guthro.net> wrote:
>>> Please let me know if there are anything else you'd like me to experiment
>>> with.
>>
>> Attached a first take at a debugging patch.
>>
>> While putting this together I realized that the situation gets
>> complicated by the fact that plain Linux 3.2.23 doesn't even
>> have support for post-S3 MSI restoration, so much would
>> depend on how exactly this is implemented in the kernel
>> you're running (i.e. whether you have a _complete_ backport
>> in place). I suppose you must be having some support for this
>> patched in, otherwise I wouldn't understand why things work
>> without IOMMU/interrupt remapping.
>>
>> Jan
>>

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

From xen-devel-bounces@lists.xen.org Tue Sep 04 13:29:38 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Sep 2012 13:29:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T8tBl-0000v4-9v; Tue, 04 Sep 2012 13:29:09 +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 1T8tBj-0000uz-QL
	for xen-devel@lists.xen.org; Tue, 04 Sep 2012 13:29:08 +0000
Received: from [85.158.139.83:41774] by server-3.bemta-5.messagelabs.com id
	D7/34-21836-22206405; Tue, 04 Sep 2012 13:29:06 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1346765344!27959098!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNzY0OTI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11095 invoked from network); 4 Sep 2012 13:29:05 -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;
	4 Sep 2012 13:29:05 -0000
X-IronPort-AV: E=Sophos;i="4.80,367,1344211200"; d="scan'208";a="207003854"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Sep 2012 13:29:04 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1;
	Tue, 4 Sep 2012 09:29: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 1T8tBf-0005dR-FK	for
	xen-devel@lists.xen.org; Tue, 04 Sep 2012 14:29:03 +0100
Message-ID: <5046021F.7020105@citrix.com>
Date: Tue, 4 Sep 2012 14:29:03 +0100
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:14.0) Gecko/20120714 Thunderbird/14.0
MIME-Version: 1.0
To: xen-devel@lists.xen.org
References: <5045DA360200007800098688@nat28.tlf.novell.com>
	<CC6B803A.4A8E0%keir@xen.org>
	<5045E8B802000078000986F7@nat28.tlf.novell.com>
In-Reply-To: <5045E8B802000078000986F7@nat28.tlf.novell.com>
X-Enigmail-Version: 1.4.4
Subject: Re: [Xen-devel] Using debug-key 'o:  Dump IOMMU p2m table,
 locks up machine
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/09/12 10:40, Jan Beulich wrote:
>>>> On 04.09.12 at 10:54, Keir Fraser <keir@xen.org> wrote:
>> On 04/09/2012 09:38, "Jan Beulich" <JBeulich@suse.com> wrote:
>>
>>>> My pragmatic take would be that: (a) Really long-running handlers that want
>>>> to dump every page mapping of every domain are pretty bloody stupid, and yes
>>>> we should consider if they are worthwhile at all; (b) moderately
>>>> long-running but useful handlers which nonetheless take a long time to dump
>>>> to Xen's console, I would consider a sysctl to allow dom0 to request dump
>>>> into a supplied memory buffer.
>>> At a first glance that sounds like a viable option, assuming that
>>> the bulk of the time otherwise is being spent actually getting the
>>> data out through the serial line. But if the long-running-ness is
>>> in the nature of the keyhandler itself, then this wouldn't help
>>> much though. And I'd be afraid that ought to be the common
>>> case when not running with sync_console, since actual serial
>>> output happens asynchronously and hence shouldn't affect the
>>> latency of the keyhandler's completion too much.
>> Well then, have we actually seen problems with async serial output, a
>> decent-sized serial output buffer, and the 'd'/'0' handlers? Because if not,
>> we don't have a problem to be solved. :)
> To a degree - we have seen (large) systems becoming unstable
> after making use of these keys, but obviously people were
> instructed to use the keys because the system already had some
> sort of problem (e.g. were dead locked on some spin lock, and
> after use of the debug keys additionally got their time screwed
> up).
>
> The 'o' key here just gets this to the extreme, which is why I'm
> wondering whether it was a good decision to add it in the first
> place. And the same would apply to EPT's 'D' key. The more that
> these keys would presumably be used when a guest had a
> problem, yet their use could render the whole system dead
> (whereas 'd' and '0' generally get used when the host is in a
> bad state already). Perhaps a minimal step would be to build/
> enabled these only in debug=y builds? But really this functionality
> should be exposed _only_ through the tools (similar to xenctx
> and lsevtchn) imo (and along those lines I think 'e' should only
> dump Dom0's event channels).
>
> Jan

I would disagree with that final part.  I have lost count of the number
of times that I have used the 'e' debug key to diagnose a problem with a
locked up system where dom0 was not necessarily accessible.  Getting all
domains information is very useful, even if it can be long at times. 
The times when the length is a problem are also the times when the
server is broken to a point that it is not a problem people are
concerned with.

~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 Sep 04 13:29:38 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Sep 2012 13:29:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T8tBl-0000v4-9v; Tue, 04 Sep 2012 13:29:09 +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 1T8tBj-0000uz-QL
	for xen-devel@lists.xen.org; Tue, 04 Sep 2012 13:29:08 +0000
Received: from [85.158.139.83:41774] by server-3.bemta-5.messagelabs.com id
	D7/34-21836-22206405; Tue, 04 Sep 2012 13:29:06 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1346765344!27959098!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNzY0OTI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11095 invoked from network); 4 Sep 2012 13:29:05 -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;
	4 Sep 2012 13:29:05 -0000
X-IronPort-AV: E=Sophos;i="4.80,367,1344211200"; d="scan'208";a="207003854"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Sep 2012 13:29:04 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1;
	Tue, 4 Sep 2012 09:29: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 1T8tBf-0005dR-FK	for
	xen-devel@lists.xen.org; Tue, 04 Sep 2012 14:29:03 +0100
Message-ID: <5046021F.7020105@citrix.com>
Date: Tue, 4 Sep 2012 14:29:03 +0100
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:14.0) Gecko/20120714 Thunderbird/14.0
MIME-Version: 1.0
To: xen-devel@lists.xen.org
References: <5045DA360200007800098688@nat28.tlf.novell.com>
	<CC6B803A.4A8E0%keir@xen.org>
	<5045E8B802000078000986F7@nat28.tlf.novell.com>
In-Reply-To: <5045E8B802000078000986F7@nat28.tlf.novell.com>
X-Enigmail-Version: 1.4.4
Subject: Re: [Xen-devel] Using debug-key 'o:  Dump IOMMU p2m table,
 locks up machine
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/09/12 10:40, Jan Beulich wrote:
>>>> On 04.09.12 at 10:54, Keir Fraser <keir@xen.org> wrote:
>> On 04/09/2012 09:38, "Jan Beulich" <JBeulich@suse.com> wrote:
>>
>>>> My pragmatic take would be that: (a) Really long-running handlers that want
>>>> to dump every page mapping of every domain are pretty bloody stupid, and yes
>>>> we should consider if they are worthwhile at all; (b) moderately
>>>> long-running but useful handlers which nonetheless take a long time to dump
>>>> to Xen's console, I would consider a sysctl to allow dom0 to request dump
>>>> into a supplied memory buffer.
>>> At a first glance that sounds like a viable option, assuming that
>>> the bulk of the time otherwise is being spent actually getting the
>>> data out through the serial line. But if the long-running-ness is
>>> in the nature of the keyhandler itself, then this wouldn't help
>>> much though. And I'd be afraid that ought to be the common
>>> case when not running with sync_console, since actual serial
>>> output happens asynchronously and hence shouldn't affect the
>>> latency of the keyhandler's completion too much.
>> Well then, have we actually seen problems with async serial output, a
>> decent-sized serial output buffer, and the 'd'/'0' handlers? Because if not,
>> we don't have a problem to be solved. :)
> To a degree - we have seen (large) systems becoming unstable
> after making use of these keys, but obviously people were
> instructed to use the keys because the system already had some
> sort of problem (e.g. were dead locked on some spin lock, and
> after use of the debug keys additionally got their time screwed
> up).
>
> The 'o' key here just gets this to the extreme, which is why I'm
> wondering whether it was a good decision to add it in the first
> place. And the same would apply to EPT's 'D' key. The more that
> these keys would presumably be used when a guest had a
> problem, yet their use could render the whole system dead
> (whereas 'd' and '0' generally get used when the host is in a
> bad state already). Perhaps a minimal step would be to build/
> enabled these only in debug=y builds? But really this functionality
> should be exposed _only_ through the tools (similar to xenctx
> and lsevtchn) imo (and along those lines I think 'e' should only
> dump Dom0's event channels).
>
> Jan

I would disagree with that final part.  I have lost count of the number
of times that I have used the 'e' debug key to diagnose a problem with a
locked up system where dom0 was not necessarily accessible.  Getting all
domains information is very useful, even if it can be long at times. 
The times when the length is a problem are also the times when the
server is broken to a point that it is not a problem people are
concerned with.

~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 Sep 04 14:08:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Sep 2012 14:08:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T8tn8-0001Dy-KW; Tue, 04 Sep 2012 14:07:46 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <stefano.panella@citrix.com>) id 1T8tn7-0001Dt-G8
	for xen-devel@lists.xensource.com; Tue, 04 Sep 2012 14:07:45 +0000
Received: from [85.158.138.51:17133] by server-6.bemta-3.messagelabs.com id
	D8/19-29694-03B06405; Tue, 04 Sep 2012 14:07:44 +0000
X-Env-Sender: stefano.panella@citrix.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1346767663!28475855!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTE3MTg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15691 invoked from network); 4 Sep 2012 14:07:44 -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;
	4 Sep 2012 14:07:44 -0000
X-IronPort-AV: E=Sophos;i="4.80,367,1344211200"; d="scan'208";a="14337520"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Sep 2012 14:07: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.279.1; Tue, 4 Sep 2012 15:07:42 +0100
Received: from slimey.cam.xci-test.com ([10.80.249.177])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<stefano.panella@citrix.com>)	id 1T8tn4-0000ei-Df;
	Tue, 04 Sep 2012 14:07:42 +0000
Message-ID: <50460B2E.3020200@citrix.com>
Date: Tue, 4 Sep 2012 15:07:42 +0100
From: Stefano Panella <stefano.panella@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:14.0) Gecko/20120714 Thunderbird/14.0
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
References: <1346407072-6405-1-git-send-email-stefano.panella@citrix.com>
	<5040B249.4000306@citrix.com>
	<20120831164010.GA18929@localhost.localdomain>
In-Reply-To: <20120831164010.GA18929@localhost.localdomain>
Cc: "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 1/1] XEN: Use correct masking in
	xen_swiotlb_alloc_coherent.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-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/31/2012 05:40 PM, Konrad Rzeszutek Wilk wrote:
> On Fri, Aug 31, 2012 at 01:47:05PM +0100, David Vrabel wrote:
>> On 31/08/12 10:57, Stefano Panella wrote:
>>> When running 32-bit pvops-dom0 and a driver tries to allocate a coherent
>>> DMA-memory the xen swiotlb-implementation returned memory beyond 4GB.
>>>
>>> This caused for example not working sound on a system with 4 GB and a 64-bit
>>> compatible sound-card with sets the DMA-mask to 64bit.
>>>
>>> On bare-metal and the forward-ported xen-dom0 patches from OpenSuse a coherent
>>> DMA-memory is always allocated inside the 32-bit address-range by calling
>>> dma_alloc_coherent_mask.
>> We should have the same behaviour under Xen as bare metal so:
>>
>> Acked-By: David Vrabel <david.vrabel@citrix.com>
>>
>> This does limit the DMA mask to 32-bits by passing it through an
>> unsigned long, which seems a bit sneaky...
> so is the issue that we are not casting it from 'u64' to 'u32'
> (unsigned long) on 32-bit?

Yes. I do not completely understand why but I think on 32-bit kernel we need to cast dma_mask to u32. This is done automatically using dma_alloc_coherent_mask()

>
>> Presumably the sound card is capable of handling 64 bit physical
>> addresses (or it would break under 64-bit kernels) so it's not clear why
>> this sound driver requires this restriction.
>>
>> Is there a bug in the sound driver or sound subsystem where it's
>> truncating a dma_addr_t by assigning it to an unsigned long or similar?
>>
>>> --- a/drivers/xen/swiotlb-xen.c
>>> +++ b/drivers/xen/swiotlb-xen.c
>>> @@ -232,7 +232,7 @@ xen_swiotlb_alloc_coherent(struct device *hwdev, size_t size,
>>>   		return ret;
>>>   
>>>   	if (hwdev && hwdev->coherent_dma_mask)
>>> -		dma_mask = hwdev->coherent_dma_mask;
>>> +		dma_mask = dma_alloc_coherent_mask(hwdev, flags);
>> Suggest
>>
>>      if (hwdev)
>>          dma_mask = dma_alloc_coherent_mask(hwdev, flags)

I can change the patch like that if you like.

> Isn't that code just doing this:
> atic inline unsigned long dma_alloc_coherent_mask(struct device *dev,
>                                                      gfp_t gfp)
> {
>          unsigned long dma_mask = 0;
>
>          dma_mask = dev->coherent_dma_mask;
>          if (!dma_mask)
>                  dma_mask = (gfp & GFP_DMA) ? DMA_BIT_MASK(24) :
> DMA_BIT_MASK(32);
>
>          return dma_mask;
> }
>
> and in our code, the dma_mask by default is DMA_BIT_MASK(32):
>
> u64 dma_mask = DMA_BIT_MASK(32);
>
> So what I am missing?

I am not sure what you mean with "what am I missing?"

Current code looks like:

void *
xen_swiotlb_alloc_coherent(struct device *hwdev, size_t size,
                            dma_addr_t *dma_handle, gfp_t flags,
                            struct dma_attrs *attrs)
{
         void *ret;
         int order = get_order(size);
         u64 dma_mask = DMA_BIT_MASK(32);
         unsigned long vstart;
         phys_addr_t phys;
         dma_addr_t dev_addr;

         /*
         * Ignore region specifiers - the kernel's ideas of
         * pseudo-phys memory layout has nothing to do with the
         * machine physical layout.  We can't allocate highmem
         * because we can't return a pointer to it.
         */
         flags &= ~(__GFP_DMA | __GFP_HIGHMEM);

         if (dma_alloc_from_coherent(hwdev, size, dma_handle, &ret))
                 return ret;

         vstart = __get_free_pages(flags, order);
         ret = (void *)vstart;

         if (!ret)
                 return ret;

         if (hwdev && hwdev->coherent_dma_mask)
                 dma_mask = hwdev->coherent_dma_mask;


So if hwdev->coherent_dma_mask is set to 0xffffffffffffffff our dma_mask will
be u64 set to 0xffffffffffffffff even if we set it to DMA_BIT_MASK(32) previously.

I hope I am not getting this wrong and let me know if I should send an updated version
of the patch including David V. change.

Regards,

Stefano


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

From xen-devel-bounces@lists.xen.org Tue Sep 04 14:08:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Sep 2012 14:08:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T8tn8-0001Dy-KW; Tue, 04 Sep 2012 14:07:46 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <stefano.panella@citrix.com>) id 1T8tn7-0001Dt-G8
	for xen-devel@lists.xensource.com; Tue, 04 Sep 2012 14:07:45 +0000
Received: from [85.158.138.51:17133] by server-6.bemta-3.messagelabs.com id
	D8/19-29694-03B06405; Tue, 04 Sep 2012 14:07:44 +0000
X-Env-Sender: stefano.panella@citrix.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1346767663!28475855!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTE3MTg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15691 invoked from network); 4 Sep 2012 14:07:44 -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;
	4 Sep 2012 14:07:44 -0000
X-IronPort-AV: E=Sophos;i="4.80,367,1344211200"; d="scan'208";a="14337520"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Sep 2012 14:07: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.279.1; Tue, 4 Sep 2012 15:07:42 +0100
Received: from slimey.cam.xci-test.com ([10.80.249.177])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<stefano.panella@citrix.com>)	id 1T8tn4-0000ei-Df;
	Tue, 04 Sep 2012 14:07:42 +0000
Message-ID: <50460B2E.3020200@citrix.com>
Date: Tue, 4 Sep 2012 15:07:42 +0100
From: Stefano Panella <stefano.panella@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:14.0) Gecko/20120714 Thunderbird/14.0
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
References: <1346407072-6405-1-git-send-email-stefano.panella@citrix.com>
	<5040B249.4000306@citrix.com>
	<20120831164010.GA18929@localhost.localdomain>
In-Reply-To: <20120831164010.GA18929@localhost.localdomain>
Cc: "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 1/1] XEN: Use correct masking in
	xen_swiotlb_alloc_coherent.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-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/31/2012 05:40 PM, Konrad Rzeszutek Wilk wrote:
> On Fri, Aug 31, 2012 at 01:47:05PM +0100, David Vrabel wrote:
>> On 31/08/12 10:57, Stefano Panella wrote:
>>> When running 32-bit pvops-dom0 and a driver tries to allocate a coherent
>>> DMA-memory the xen swiotlb-implementation returned memory beyond 4GB.
>>>
>>> This caused for example not working sound on a system with 4 GB and a 64-bit
>>> compatible sound-card with sets the DMA-mask to 64bit.
>>>
>>> On bare-metal and the forward-ported xen-dom0 patches from OpenSuse a coherent
>>> DMA-memory is always allocated inside the 32-bit address-range by calling
>>> dma_alloc_coherent_mask.
>> We should have the same behaviour under Xen as bare metal so:
>>
>> Acked-By: David Vrabel <david.vrabel@citrix.com>
>>
>> This does limit the DMA mask to 32-bits by passing it through an
>> unsigned long, which seems a bit sneaky...
> so is the issue that we are not casting it from 'u64' to 'u32'
> (unsigned long) on 32-bit?

Yes. I do not completely understand why but I think on 32-bit kernel we need to cast dma_mask to u32. This is done automatically using dma_alloc_coherent_mask()

>
>> Presumably the sound card is capable of handling 64 bit physical
>> addresses (or it would break under 64-bit kernels) so it's not clear why
>> this sound driver requires this restriction.
>>
>> Is there a bug in the sound driver or sound subsystem where it's
>> truncating a dma_addr_t by assigning it to an unsigned long or similar?
>>
>>> --- a/drivers/xen/swiotlb-xen.c
>>> +++ b/drivers/xen/swiotlb-xen.c
>>> @@ -232,7 +232,7 @@ xen_swiotlb_alloc_coherent(struct device *hwdev, size_t size,
>>>   		return ret;
>>>   
>>>   	if (hwdev && hwdev->coherent_dma_mask)
>>> -		dma_mask = hwdev->coherent_dma_mask;
>>> +		dma_mask = dma_alloc_coherent_mask(hwdev, flags);
>> Suggest
>>
>>      if (hwdev)
>>          dma_mask = dma_alloc_coherent_mask(hwdev, flags)

I can change the patch like that if you like.

> Isn't that code just doing this:
> atic inline unsigned long dma_alloc_coherent_mask(struct device *dev,
>                                                      gfp_t gfp)
> {
>          unsigned long dma_mask = 0;
>
>          dma_mask = dev->coherent_dma_mask;
>          if (!dma_mask)
>                  dma_mask = (gfp & GFP_DMA) ? DMA_BIT_MASK(24) :
> DMA_BIT_MASK(32);
>
>          return dma_mask;
> }
>
> and in our code, the dma_mask by default is DMA_BIT_MASK(32):
>
> u64 dma_mask = DMA_BIT_MASK(32);
>
> So what I am missing?

I am not sure what you mean with "what am I missing?"

Current code looks like:

void *
xen_swiotlb_alloc_coherent(struct device *hwdev, size_t size,
                            dma_addr_t *dma_handle, gfp_t flags,
                            struct dma_attrs *attrs)
{
         void *ret;
         int order = get_order(size);
         u64 dma_mask = DMA_BIT_MASK(32);
         unsigned long vstart;
         phys_addr_t phys;
         dma_addr_t dev_addr;

         /*
         * Ignore region specifiers - the kernel's ideas of
         * pseudo-phys memory layout has nothing to do with the
         * machine physical layout.  We can't allocate highmem
         * because we can't return a pointer to it.
         */
         flags &= ~(__GFP_DMA | __GFP_HIGHMEM);

         if (dma_alloc_from_coherent(hwdev, size, dma_handle, &ret))
                 return ret;

         vstart = __get_free_pages(flags, order);
         ret = (void *)vstart;

         if (!ret)
                 return ret;

         if (hwdev && hwdev->coherent_dma_mask)
                 dma_mask = hwdev->coherent_dma_mask;


So if hwdev->coherent_dma_mask is set to 0xffffffffffffffff our dma_mask will
be u64 set to 0xffffffffffffffff even if we set it to DMA_BIT_MASK(32) previously.

I hope I am not getting this wrong and let me know if I should send an updated version
of the patch including David V. change.

Regards,

Stefano


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

From xen-devel-bounces@lists.xen.org Tue Sep 04 14:27:42 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Sep 2012 14:27: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 1T8u63-0001Wd-4B; Tue, 04 Sep 2012 14:27:19 +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 1T8u62-0001WK-74
	for xen-devel@lists.xen.org; Tue, 04 Sep 2012 14:27:18 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1346768831!4371484!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM4Mzg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11694 invoked from network); 4 Sep 2012 14:27:11 -0000
Received: from unknown (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-10.tower-27.messagelabs.com with SMTP;
	4 Sep 2012 14:27:11 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 04 Sep 2012 15:25:13 +0100
Message-Id: <50462B9D02000078000987A4@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 04 Sep 2012 15:26:05 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ben Guthro" <ben@guthro.net>
References: <CAOvdn6WwgBD-2yf1uu3m9-16=Tb5KUrybXf2KibtnxKbP7YtwA@mail.gmail.com>
	<CAOvdn6UBW-yTOMd3YSf5M9JiHLRivyaKL-qzcKG8epszqaKmGg@mail.gmail.com>
	<20120807163320.GC15053@phenom.dumpdata.com>
	<CAOvdn6XcRGKtJxGwJO8J+ZBJr89wfTLc1woW5rhtMM540H9h1w@mail.gmail.com>
	<CAOvdn6XUoSeGoo7X=AJ1kpDxZB9HZEv+TJ4v-=FHcyR4=CHK-w@mail.gmail.com>
	<502240F302000078000937A6@nat28.tlf.novell.com>
	<CAOvdn6WN3kxC8Bb9g6MpfLULu47EGSGCtajPc-SFeJ-8VSUQDQ@mail.gmail.com>
	<CAOvdn6Xk1inm1hU55i0phU2qvSWyJLNoyDdn43biBAY2OewPtw@mail.gmail.com>
	<5023F5400200007800093F4E@nat28.tlf.novell.com>
	<CAOvdn6U-f3C4U8xVPvDyRFkFFLkbfiCXg_n+9zgA9V5u+q5jfw@mail.gmail.com>
	<5023F8B80200007800093F8C@nat28.tlf.novell.com>
	<CAOvdn6XKHfete_+=Hkvt20G7_cJ-4i8+9j9YD30OxzQ16Ru-+g@mail.gmail.com>
	<5024CB720200007800094124@nat28.tlf.novell.com>
	<CAOvdn6VVJdhWVYa-gNVt3euE4AbGi1TijUCUd1wGzv0SCWEUYA@mail.gmail.com>
	<CAOvdn6USnG9Y4MNBhrDZmob0oJ8BgFfKTvFEhcKbXDxNmzfZ-Q@mail.gmail.com>
	<502B75BA0200007800094FD4@nat28.tlf.novell.com>
	<CAOvdn6Ww5oEj6Xg=XT4dWCYWUBuOdPqLz-CqNjz4HmCScE+==g@mail.gmail.com>
	<CAOvdn6Wsjds_dmZ0dwDTYmD-o-OqjBH5-b9mitAuUADE+A4_ag@mail.gmail.com>
	<502BB8FD02000078000951E0@nat28.tlf.novell.com>
	<CAOvdn6VD6bp13F-tvYdkBsj4hkhE7PTGZrapndtdHrDKeZqccg@mail.gmail.com>
	<502CCC0002000078000955C4@nat28.tlf.novell.com>
	<CAOvdn6VEuX7R2_wz74ZvCxMjC-=YUir9kP5sdxEVaKVspRUd_w@mail.gmail.com>
	<502CF0A8020000780009574E@nat28.tlf.novell.com>
	<CAOvdn6VsZvn_1TCWYeuyY5YuTcP8=miK2KwE4583nsj6Qjb_vg@mail.gmail.com>
	<504494FB0200007800098398@nat28.tlf.novell.com>
	<CAOvdn6UT13qvWbMyfZkWND03RoVKVSgb6wW4yqTUpuBYEX01Dg@mail.gmail.com>
	<CAOvdn6W+XZiiJyUb04WwMEh+WFB5Dam+NLpKa1DuTCGLU=BuaA@mail.gmail.com>
In-Reply-To: <CAOvdn6W+XZiiJyUb04WwMEh+WFB5Dam+NLpKa1DuTCGLU=BuaA@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>, john.baboval@citrix.com,
	Thomas Goetz <thomas.goetz@citrix.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen4.2 S3 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 04.09.12 at 14:49, Ben Guthro <ben@guthro.net> wrote:
> I forgot to address your dom0 kernel concern -
> 
> All of these tests have been run with Konrad Wilk's acpi-s3.vX branches.
> 
> The later kernels took more recent branches, while the 3.2.yy kernels
> used an older (but still functional) branch (acpi-s3.v7)

This and the log you provided suggest that your kernel is lacking
the MSI restore code altogether (or it is not getting called as
intended). With that, there's pretty little point in continuing
the investigation on the hypervisor side.

Jan


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

From xen-devel-bounces@lists.xen.org Tue Sep 04 14:27:42 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Sep 2012 14:27: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 1T8u63-0001Wd-4B; Tue, 04 Sep 2012 14:27:19 +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 1T8u62-0001WK-74
	for xen-devel@lists.xen.org; Tue, 04 Sep 2012 14:27:18 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1346768831!4371484!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM4Mzg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11694 invoked from network); 4 Sep 2012 14:27:11 -0000
Received: from unknown (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-10.tower-27.messagelabs.com with SMTP;
	4 Sep 2012 14:27:11 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 04 Sep 2012 15:25:13 +0100
Message-Id: <50462B9D02000078000987A4@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 04 Sep 2012 15:26:05 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ben Guthro" <ben@guthro.net>
References: <CAOvdn6WwgBD-2yf1uu3m9-16=Tb5KUrybXf2KibtnxKbP7YtwA@mail.gmail.com>
	<CAOvdn6UBW-yTOMd3YSf5M9JiHLRivyaKL-qzcKG8epszqaKmGg@mail.gmail.com>
	<20120807163320.GC15053@phenom.dumpdata.com>
	<CAOvdn6XcRGKtJxGwJO8J+ZBJr89wfTLc1woW5rhtMM540H9h1w@mail.gmail.com>
	<CAOvdn6XUoSeGoo7X=AJ1kpDxZB9HZEv+TJ4v-=FHcyR4=CHK-w@mail.gmail.com>
	<502240F302000078000937A6@nat28.tlf.novell.com>
	<CAOvdn6WN3kxC8Bb9g6MpfLULu47EGSGCtajPc-SFeJ-8VSUQDQ@mail.gmail.com>
	<CAOvdn6Xk1inm1hU55i0phU2qvSWyJLNoyDdn43biBAY2OewPtw@mail.gmail.com>
	<5023F5400200007800093F4E@nat28.tlf.novell.com>
	<CAOvdn6U-f3C4U8xVPvDyRFkFFLkbfiCXg_n+9zgA9V5u+q5jfw@mail.gmail.com>
	<5023F8B80200007800093F8C@nat28.tlf.novell.com>
	<CAOvdn6XKHfete_+=Hkvt20G7_cJ-4i8+9j9YD30OxzQ16Ru-+g@mail.gmail.com>
	<5024CB720200007800094124@nat28.tlf.novell.com>
	<CAOvdn6VVJdhWVYa-gNVt3euE4AbGi1TijUCUd1wGzv0SCWEUYA@mail.gmail.com>
	<CAOvdn6USnG9Y4MNBhrDZmob0oJ8BgFfKTvFEhcKbXDxNmzfZ-Q@mail.gmail.com>
	<502B75BA0200007800094FD4@nat28.tlf.novell.com>
	<CAOvdn6Ww5oEj6Xg=XT4dWCYWUBuOdPqLz-CqNjz4HmCScE+==g@mail.gmail.com>
	<CAOvdn6Wsjds_dmZ0dwDTYmD-o-OqjBH5-b9mitAuUADE+A4_ag@mail.gmail.com>
	<502BB8FD02000078000951E0@nat28.tlf.novell.com>
	<CAOvdn6VD6bp13F-tvYdkBsj4hkhE7PTGZrapndtdHrDKeZqccg@mail.gmail.com>
	<502CCC0002000078000955C4@nat28.tlf.novell.com>
	<CAOvdn6VEuX7R2_wz74ZvCxMjC-=YUir9kP5sdxEVaKVspRUd_w@mail.gmail.com>
	<502CF0A8020000780009574E@nat28.tlf.novell.com>
	<CAOvdn6VsZvn_1TCWYeuyY5YuTcP8=miK2KwE4583nsj6Qjb_vg@mail.gmail.com>
	<504494FB0200007800098398@nat28.tlf.novell.com>
	<CAOvdn6UT13qvWbMyfZkWND03RoVKVSgb6wW4yqTUpuBYEX01Dg@mail.gmail.com>
	<CAOvdn6W+XZiiJyUb04WwMEh+WFB5Dam+NLpKa1DuTCGLU=BuaA@mail.gmail.com>
In-Reply-To: <CAOvdn6W+XZiiJyUb04WwMEh+WFB5Dam+NLpKa1DuTCGLU=BuaA@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>, john.baboval@citrix.com,
	Thomas Goetz <thomas.goetz@citrix.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen4.2 S3 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 04.09.12 at 14:49, Ben Guthro <ben@guthro.net> wrote:
> I forgot to address your dom0 kernel concern -
> 
> All of these tests have been run with Konrad Wilk's acpi-s3.vX branches.
> 
> The later kernels took more recent branches, while the 3.2.yy kernels
> used an older (but still functional) branch (acpi-s3.v7)

This and the log you provided suggest that your kernel is lacking
the MSI restore code altogether (or it is not getting called as
intended). With that, there's pretty little point in continuing
the investigation on the hypervisor side.

Jan


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

From xen-devel-bounces@lists.xen.org Tue Sep 04 14:29:27 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Sep 2012 14:29:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T8u7l-0001ev-K6; Tue, 04 Sep 2012 14:29:05 +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 1T8u7j-0001ek-Pn
	for xen-devel@lists.xen.org; Tue, 04 Sep 2012 14:29:03 +0000
Received: from [85.158.143.99:35844] by server-2.bemta-4.messagelabs.com id
	90/3D-21239-F2016405; Tue, 04 Sep 2012 14:29:03 +0000
X-Env-Sender: ben.guthro@gmail.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1346768940!22088923!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-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20772 invoked from network); 4 Sep 2012 14:29:02 -0000
Received: from mail-vb0-f45.google.com (HELO mail-vb0-f45.google.com)
	(209.85.212.45)
	by server-10.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Sep 2012 14:29:02 -0000
Received: by vbip1 with SMTP id p1so8428916vbi.32
	for <xen-devel@lists.xen.org>; Tue, 04 Sep 2012 07:29:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=references:from:in-reply-to:mime-version:date:message-id:subject:to
	:cc:content-type;
	bh=KMjqh8NB3jqIPLZDAblb6KPW6d4ujxWpZXIBViNHP2s=;
	b=BbjsfBspLGILc76L+96AtQqXBdCm/Ll5I30cKW6TcHSKGYXKAw6QVUksDyYsM7ESYu
	m5p5owU7kjR7EWbYT2RnmWFgNdbvBYnO8zZh1fDlOwv2sEuFF8gw0vV0udCCA2QdKLMA
	WQsqeFdv5VvK+YqLGHnvTiKhKFsA8aZ0DFXReEWLFXgG3K937pF/fdOxHbqgu7Qa9gx+
	tM8t6Hw0LdUNYpAP1Uae0nL+oTMCd+ZfVrRhOGq0ltAtAxKa5Ba9J2xk6yhHn7celRs+
	/75Yw0SKfTovULlgodijHZAGzU9rJhFkZxlZcAc9ofUWEGQpfrOfNeNQnXyMPgVTuN27
	3hwg==
Received: by 10.52.75.36 with SMTP id z4mr12582434vdv.52.1346768917325; Tue,
	04 Sep 2012 07:28:37 -0700 (PDT)
References: <CAOvdn6WwgBD-2yf1uu3m9-16=Tb5KUrybXf2KibtnxKbP7YtwA@mail.gmail.com>
	<CAOvdn6UBW-yTOMd3YSf5M9JiHLRivyaKL-qzcKG8epszqaKmGg@mail.gmail.com>
	<20120807163320.GC15053@phenom.dumpdata.com>
	<CAOvdn6XcRGKtJxGwJO8J+ZBJr89wfTLc1woW5rhtMM540H9h1w@mail.gmail.com>
	<CAOvdn6XUoSeGoo7X=AJ1kpDxZB9HZEv+TJ4v-=FHcyR4=CHK-w@mail.gmail.com>
	<502240F302000078000937A6@nat28.tlf.novell.com>
	<CAOvdn6WN3kxC8Bb9g6MpfLULu47EGSGCtajPc-SFeJ-8VSUQDQ@mail.gmail.com>
	<CAOvdn6Xk1inm1hU55i0phU2qvSWyJLNoyDdn43biBAY2OewPtw@mail.gmail.com>
	<5023F5400200007800093F4E@nat28.tlf.novell.com>
	<CAOvdn6U-f3C4U8xVPvDyRFkFFLkbfiCXg_n+9zgA9V5u+q5jfw@mail.gmail.com>
	<5023F8B80200007800093F8C@nat28.tlf.novell.com>
	<CAOvdn6XKHfete_+=Hkvt20G7_cJ-4i8+9j9YD30OxzQ16Ru-+g@mail.gmail.com>
	<5024CB720200007800094124@nat28.tlf.novell.com>
	<CAOvdn6VVJdhWVYa-gNVt3euE4AbGi1TijUCUd1wGzv0SCWEUYA@mail.gmail.com>
	<CAOvdn6USnG9Y4MNBhrDZmob0oJ8BgFfKTvFEhcKbXDxNmzfZ-Q@mail.gmail.com>
	<502B75BA0200007800094FD4@nat28.tlf.novell.com>
	<CAOvdn6Ww5oEj6Xg=XT4dWCYWUBuOdPqLz-CqNjz4HmCScE+==g@mail.gmail.com>
	<CAOvdn6Wsjds_dmZ0dwDTYmD-o-OqjBH5-b9mitAuUADE+A4_ag@mail.gmail.com>
	<502BB8FD02000078000951E0@nat28.tlf.novell.com>
	<CAOvdn6VD6bp13F-tvYdkBsj4hkhE7PTGZrapndtdHrDKeZqccg@mail.gmail.com>
	<502CCC0002000078000955C4@nat28.tlf.novell.com>
	<CAOvdn6VEuX7R2_wz74ZvCxMjC-=YUir9kP5sdxEVaKVspRUd_w@mail.gmail.com>
	<502CF0A8020000780009574E@nat28.tlf.novell.com>
	<CAOvdn6VsZvn_1TCWYeuyY5YuTcP8=miK2KwE4583nsj6Qjb_vg@mail.gmail.com>
	<504494FB0200007800098398@nat28.tlf.novell.com>
	<CAOvdn6UT13qvWbMyfZkWND03RoVKVSgb6wW4yqTUpuBYEX01Dg@mail.gmail.com>
	<CAOvdn6W+XZiiJyUb04WwMEh+WFB5Dam+NLpKa1DuTCGLU=BuaA@mail.gmail.com>
	<50462B9D02000078000987A4@nat28.tlf.novell.com>
From: Ben Guthro <ben.guthro@gmail.com>
In-Reply-To: <50462B9D02000078000987A4@nat28.tlf.novell.com>
Mime-Version: 1.0 (1.0)
Date: Tue, 4 Sep 2012 10:28:37 -0400
Message-ID: <27134645888804121@unknownmsgid>
To: Jan Beulich <JBeulich@suse.com>
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	xen-devel <xen-devel@lists.xen.org>, Ben Guthro <ben@guthro.net>,
	Thomas Goetz <thomas.goetz@citrix.com>,
	"john.baboval@citrix.com" <john.baboval@citrix.com>
Subject: Re: [Xen-devel] Xen4.2 S3 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

How is it that it works with an older hypervisor, then?

Konrad - is the v7 code functionally different than the v10 code, or
is it more  stylistic changes?

On Sep 4, 2012, at 10:25 AM, Jan Beulich <JBeulich@suse.com> wrote:

>>>> On 04.09.12 at 14:49, Ben Guthro <ben@guthro.net> wrote:
>> I forgot to address your dom0 kernel concern -
>>
>> All of these tests have been run with Konrad Wilk's acpi-s3.vX branches.
>>
>> The later kernels took more recent branches, while the 3.2.yy kernels
>> used an older (but still functional) branch (acpi-s3.v7)
>
> This and the log you provided suggest that your kernel is lacking
> the MSI restore code altogether (or it is not getting called as
> intended). With that, there's pretty little point in continuing
> the investigation on the hypervisor side.
>
> Jan
>

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

From xen-devel-bounces@lists.xen.org Tue Sep 04 14:29:27 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Sep 2012 14:29:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T8u7l-0001ev-K6; Tue, 04 Sep 2012 14:29:05 +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 1T8u7j-0001ek-Pn
	for xen-devel@lists.xen.org; Tue, 04 Sep 2012 14:29:03 +0000
Received: from [85.158.143.99:35844] by server-2.bemta-4.messagelabs.com id
	90/3D-21239-F2016405; Tue, 04 Sep 2012 14:29:03 +0000
X-Env-Sender: ben.guthro@gmail.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1346768940!22088923!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-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20772 invoked from network); 4 Sep 2012 14:29:02 -0000
Received: from mail-vb0-f45.google.com (HELO mail-vb0-f45.google.com)
	(209.85.212.45)
	by server-10.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Sep 2012 14:29:02 -0000
Received: by vbip1 with SMTP id p1so8428916vbi.32
	for <xen-devel@lists.xen.org>; Tue, 04 Sep 2012 07:29:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=references:from:in-reply-to:mime-version:date:message-id:subject:to
	:cc:content-type;
	bh=KMjqh8NB3jqIPLZDAblb6KPW6d4ujxWpZXIBViNHP2s=;
	b=BbjsfBspLGILc76L+96AtQqXBdCm/Ll5I30cKW6TcHSKGYXKAw6QVUksDyYsM7ESYu
	m5p5owU7kjR7EWbYT2RnmWFgNdbvBYnO8zZh1fDlOwv2sEuFF8gw0vV0udCCA2QdKLMA
	WQsqeFdv5VvK+YqLGHnvTiKhKFsA8aZ0DFXReEWLFXgG3K937pF/fdOxHbqgu7Qa9gx+
	tM8t6Hw0LdUNYpAP1Uae0nL+oTMCd+ZfVrRhOGq0ltAtAxKa5Ba9J2xk6yhHn7celRs+
	/75Yw0SKfTovULlgodijHZAGzU9rJhFkZxlZcAc9ofUWEGQpfrOfNeNQnXyMPgVTuN27
	3hwg==
Received: by 10.52.75.36 with SMTP id z4mr12582434vdv.52.1346768917325; Tue,
	04 Sep 2012 07:28:37 -0700 (PDT)
References: <CAOvdn6WwgBD-2yf1uu3m9-16=Tb5KUrybXf2KibtnxKbP7YtwA@mail.gmail.com>
	<CAOvdn6UBW-yTOMd3YSf5M9JiHLRivyaKL-qzcKG8epszqaKmGg@mail.gmail.com>
	<20120807163320.GC15053@phenom.dumpdata.com>
	<CAOvdn6XcRGKtJxGwJO8J+ZBJr89wfTLc1woW5rhtMM540H9h1w@mail.gmail.com>
	<CAOvdn6XUoSeGoo7X=AJ1kpDxZB9HZEv+TJ4v-=FHcyR4=CHK-w@mail.gmail.com>
	<502240F302000078000937A6@nat28.tlf.novell.com>
	<CAOvdn6WN3kxC8Bb9g6MpfLULu47EGSGCtajPc-SFeJ-8VSUQDQ@mail.gmail.com>
	<CAOvdn6Xk1inm1hU55i0phU2qvSWyJLNoyDdn43biBAY2OewPtw@mail.gmail.com>
	<5023F5400200007800093F4E@nat28.tlf.novell.com>
	<CAOvdn6U-f3C4U8xVPvDyRFkFFLkbfiCXg_n+9zgA9V5u+q5jfw@mail.gmail.com>
	<5023F8B80200007800093F8C@nat28.tlf.novell.com>
	<CAOvdn6XKHfete_+=Hkvt20G7_cJ-4i8+9j9YD30OxzQ16Ru-+g@mail.gmail.com>
	<5024CB720200007800094124@nat28.tlf.novell.com>
	<CAOvdn6VVJdhWVYa-gNVt3euE4AbGi1TijUCUd1wGzv0SCWEUYA@mail.gmail.com>
	<CAOvdn6USnG9Y4MNBhrDZmob0oJ8BgFfKTvFEhcKbXDxNmzfZ-Q@mail.gmail.com>
	<502B75BA0200007800094FD4@nat28.tlf.novell.com>
	<CAOvdn6Ww5oEj6Xg=XT4dWCYWUBuOdPqLz-CqNjz4HmCScE+==g@mail.gmail.com>
	<CAOvdn6Wsjds_dmZ0dwDTYmD-o-OqjBH5-b9mitAuUADE+A4_ag@mail.gmail.com>
	<502BB8FD02000078000951E0@nat28.tlf.novell.com>
	<CAOvdn6VD6bp13F-tvYdkBsj4hkhE7PTGZrapndtdHrDKeZqccg@mail.gmail.com>
	<502CCC0002000078000955C4@nat28.tlf.novell.com>
	<CAOvdn6VEuX7R2_wz74ZvCxMjC-=YUir9kP5sdxEVaKVspRUd_w@mail.gmail.com>
	<502CF0A8020000780009574E@nat28.tlf.novell.com>
	<CAOvdn6VsZvn_1TCWYeuyY5YuTcP8=miK2KwE4583nsj6Qjb_vg@mail.gmail.com>
	<504494FB0200007800098398@nat28.tlf.novell.com>
	<CAOvdn6UT13qvWbMyfZkWND03RoVKVSgb6wW4yqTUpuBYEX01Dg@mail.gmail.com>
	<CAOvdn6W+XZiiJyUb04WwMEh+WFB5Dam+NLpKa1DuTCGLU=BuaA@mail.gmail.com>
	<50462B9D02000078000987A4@nat28.tlf.novell.com>
From: Ben Guthro <ben.guthro@gmail.com>
In-Reply-To: <50462B9D02000078000987A4@nat28.tlf.novell.com>
Mime-Version: 1.0 (1.0)
Date: Tue, 4 Sep 2012 10:28:37 -0400
Message-ID: <27134645888804121@unknownmsgid>
To: Jan Beulich <JBeulich@suse.com>
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	xen-devel <xen-devel@lists.xen.org>, Ben Guthro <ben@guthro.net>,
	Thomas Goetz <thomas.goetz@citrix.com>,
	"john.baboval@citrix.com" <john.baboval@citrix.com>
Subject: Re: [Xen-devel] Xen4.2 S3 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

How is it that it works with an older hypervisor, then?

Konrad - is the v7 code functionally different than the v10 code, or
is it more  stylistic changes?

On Sep 4, 2012, at 10:25 AM, Jan Beulich <JBeulich@suse.com> wrote:

>>>> On 04.09.12 at 14:49, Ben Guthro <ben@guthro.net> wrote:
>> I forgot to address your dom0 kernel concern -
>>
>> All of these tests have been run with Konrad Wilk's acpi-s3.vX branches.
>>
>> The later kernels took more recent branches, while the 3.2.yy kernels
>> used an older (but still functional) branch (acpi-s3.v7)
>
> This and the log you provided suggest that your kernel is lacking
> the MSI restore code altogether (or it is not getting called as
> intended). With that, there's pretty little point in continuing
> the investigation on the hypervisor side.
>
> Jan
>

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

From xen-devel-bounces@lists.xen.org Tue Sep 04 14:46:11 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Sep 2012 14: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 1T8uNz-0002N1-FM; Tue, 04 Sep 2012 14:45: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 1T8uNy-0002Mt-64
	for xen-devel@lists.xensource.com; Tue, 04 Sep 2012 14:45:50 +0000
Received: from [85.158.143.35:32716] by server-1.bemta-4.messagelabs.com id
	C5/7C-12504-D1416405; Tue, 04 Sep 2012 14:45:49 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1346769947!16603172!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTE3MTg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17098 invoked from network); 4 Sep 2012 14:45: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;
	4 Sep 2012 14:45:48 -0000
X-IronPort-AV: E=Sophos;i="4.80,367,1344211200"; d="scan'208";a="14338494"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Sep 2012 14:45: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.279.1; Tue, 4 Sep 2012 15:45: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 1T8uNN-0000u6-MU;
	Tue, 04 Sep 2012 14:45:13 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1T8uNN-0003VV-8D;
	Tue, 04 Sep 2012 15:45:13 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-13643-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Tue, 4 Sep 2012 15:45:13 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13643: 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 13643 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13643/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore            fail   like 13640
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail like 13640
 test-i386-i386-xl-qemuu-winxpsp3  9 guest-localmigrate         fail like 13640
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail like 13640

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

version targeted for testing:
 xen                  1dfbae8dd282
baseline version:
 xen                  9e5665f9f430

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@citrix.com>
  Christoph Egger <Christoph.Egger@amd.com>
  David Vrabel <david.vrabel@citrix.com>
  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>
  Matt Wilson <msw@amazon.com>
  Roger Pau Monne <roger.pau@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                                 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                                     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=1dfbae8dd282
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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 1dfbae8dd282
+ branch=xen-unstable
+ revision=1dfbae8dd282
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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 1dfbae8dd282 ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg
pushing to ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg
searching for changes
remote: adding changesets
remote: adding manifests
remote: adding file changes
remote: added 11 changesets with 18 changes to 11 files

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

From xen-devel-bounces@lists.xen.org Tue Sep 04 14:46:11 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Sep 2012 14: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 1T8uNz-0002N1-FM; Tue, 04 Sep 2012 14:45: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 1T8uNy-0002Mt-64
	for xen-devel@lists.xensource.com; Tue, 04 Sep 2012 14:45:50 +0000
Received: from [85.158.143.35:32716] by server-1.bemta-4.messagelabs.com id
	C5/7C-12504-D1416405; Tue, 04 Sep 2012 14:45:49 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1346769947!16603172!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTE3MTg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17098 invoked from network); 4 Sep 2012 14:45: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;
	4 Sep 2012 14:45:48 -0000
X-IronPort-AV: E=Sophos;i="4.80,367,1344211200"; d="scan'208";a="14338494"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Sep 2012 14:45: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.279.1; Tue, 4 Sep 2012 15:45: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 1T8uNN-0000u6-MU;
	Tue, 04 Sep 2012 14:45:13 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1T8uNN-0003VV-8D;
	Tue, 04 Sep 2012 15:45:13 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-13643-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Tue, 4 Sep 2012 15:45:13 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13643: 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 13643 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13643/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore            fail   like 13640
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail like 13640
 test-i386-i386-xl-qemuu-winxpsp3  9 guest-localmigrate         fail like 13640
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail like 13640

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

version targeted for testing:
 xen                  1dfbae8dd282
baseline version:
 xen                  9e5665f9f430

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@citrix.com>
  Christoph Egger <Christoph.Egger@amd.com>
  David Vrabel <david.vrabel@citrix.com>
  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>
  Matt Wilson <msw@amazon.com>
  Roger Pau Monne <roger.pau@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                                 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                                     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=1dfbae8dd282
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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 1dfbae8dd282
+ branch=xen-unstable
+ revision=1dfbae8dd282
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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 1dfbae8dd282 ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg
pushing to ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg
searching for changes
remote: adding changesets
remote: adding manifests
remote: adding file changes
remote: added 11 changesets with 18 changes to 11 files

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

From xen-devel-bounces@lists.xen.org Tue Sep 04 14:47:17 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Sep 2012 14: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 1T8uP1-0002Qp-Vv; Tue, 04 Sep 2012 14:46: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 1T8uP1-0002Qf-Dy
	for xen-devel@lists.xen.org; Tue, 04 Sep 2012 14:46:55 +0000
Received: from [85.158.143.99:5080] by server-3.bemta-4.messagelabs.com id
	24/FA-08232-E5416405; Tue, 04 Sep 2012 14:46:54 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1346770012!23237217!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDczNjI0OQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6959 invoked from network); 4 Sep 2012 14:46:53 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-12.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 4 Sep 2012 14:46:53 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q84EkjEg008155
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 4 Sep 2012 14:46:46 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
	q84Ekj9R025906
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 4 Sep 2012 14:46:45 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
	q84Ekj5h029267; Tue, 4 Sep 2012 09:46:45 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 04 Sep 2012 07:46:45 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 38849402BA; Tue,  4 Sep 2012 10:36:18 -0400 (EDT)
Date: Tue, 4 Sep 2012 10:36:18 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Ben Guthro <ben.guthro@gmail.com>
Message-ID: <20120904143618.GB23361@phenom.dumpdata.com>
References: <CAOvdn6VD6bp13F-tvYdkBsj4hkhE7PTGZrapndtdHrDKeZqccg@mail.gmail.com>
	<502CCC0002000078000955C4@nat28.tlf.novell.com>
	<CAOvdn6VEuX7R2_wz74ZvCxMjC-=YUir9kP5sdxEVaKVspRUd_w@mail.gmail.com>
	<502CF0A8020000780009574E@nat28.tlf.novell.com>
	<CAOvdn6VsZvn_1TCWYeuyY5YuTcP8=miK2KwE4583nsj6Qjb_vg@mail.gmail.com>
	<504494FB0200007800098398@nat28.tlf.novell.com>
	<CAOvdn6UT13qvWbMyfZkWND03RoVKVSgb6wW4yqTUpuBYEX01Dg@mail.gmail.com>
	<CAOvdn6W+XZiiJyUb04WwMEh+WFB5Dam+NLpKa1DuTCGLU=BuaA@mail.gmail.com>
	<50462B9D02000078000987A4@nat28.tlf.novell.com>
	<27134645888804121@unknownmsgid>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <27134645888804121@unknownmsgid>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: Thomas Goetz <thomas.goetz@citrix.com>, xen-devel <xen-devel@lists.xen.org>,
	Ben Guthro <ben@guthro.net>, Jan Beulich <JBeulich@suse.com>,
	"john.baboval@citrix.com" <john.baboval@citrix.com>
Subject: Re: [Xen-devel] Xen4.2 S3 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 Tue, Sep 04, 2012 at 10:28:37AM -0400, Ben Guthro wrote:
> How is it that it works with an older hypervisor, then?
> 
> Konrad - is the v7 code functionally different than the v10 code, or
> is it more  stylistic changes?

It is that v3.4 (and up) already has the restore_MSI hypervisor call:

commit 8605c6844fb9bdf55471bb87c3ac62d44eb34e04
Author: Tang Liang <liang.tang@oracle.com>
Date:   Thu Dec 8 17:36:39 2011 +0800

    xen: Utilize the restore_msi_irqs hook.
    
    to make a hypercall to restore the vectors in the MSI/MSI-X
    configuration space.
    
    Signed-off-by: Tang Liang <liang.tang@oracle.com>
    Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

The only part that is left out of mainline is the part where the hypercall
is done properly. That is what the acpi/s3.v10 does.. but after talking to
Len he pointed out a different way of doing this.

> 
> On Sep 4, 2012, at 10:25 AM, Jan Beulich <JBeulich@suse.com> wrote:
> 
> >>>> On 04.09.12 at 14:49, Ben Guthro <ben@guthro.net> wrote:
> >> I forgot to address your dom0 kernel concern -
> >>
> >> All of these tests have been run with Konrad Wilk's acpi-s3.vX branches.
> >>
> >> The later kernels took more recent branches, while the 3.2.yy kernels
> >> used an older (but still functional) branch (acpi-s3.v7)
> >
> > This and the log you provided suggest that your kernel is lacking
> > the MSI restore code altogether (or it is not getting called as
> > intended). With that, there's pretty little point in continuing
> > the investigation on the hypervisor side.
> >
> > Jan
> >

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

From xen-devel-bounces@lists.xen.org Tue Sep 04 14:47:17 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Sep 2012 14: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 1T8uP1-0002Qp-Vv; Tue, 04 Sep 2012 14:46: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 1T8uP1-0002Qf-Dy
	for xen-devel@lists.xen.org; Tue, 04 Sep 2012 14:46:55 +0000
Received: from [85.158.143.99:5080] by server-3.bemta-4.messagelabs.com id
	24/FA-08232-E5416405; Tue, 04 Sep 2012 14:46:54 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1346770012!23237217!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDczNjI0OQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6959 invoked from network); 4 Sep 2012 14:46:53 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-12.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 4 Sep 2012 14:46:53 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q84EkjEg008155
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 4 Sep 2012 14:46:46 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
	q84Ekj9R025906
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 4 Sep 2012 14:46:45 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
	q84Ekj5h029267; Tue, 4 Sep 2012 09:46:45 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 04 Sep 2012 07:46:45 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 38849402BA; Tue,  4 Sep 2012 10:36:18 -0400 (EDT)
Date: Tue, 4 Sep 2012 10:36:18 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Ben Guthro <ben.guthro@gmail.com>
Message-ID: <20120904143618.GB23361@phenom.dumpdata.com>
References: <CAOvdn6VD6bp13F-tvYdkBsj4hkhE7PTGZrapndtdHrDKeZqccg@mail.gmail.com>
	<502CCC0002000078000955C4@nat28.tlf.novell.com>
	<CAOvdn6VEuX7R2_wz74ZvCxMjC-=YUir9kP5sdxEVaKVspRUd_w@mail.gmail.com>
	<502CF0A8020000780009574E@nat28.tlf.novell.com>
	<CAOvdn6VsZvn_1TCWYeuyY5YuTcP8=miK2KwE4583nsj6Qjb_vg@mail.gmail.com>
	<504494FB0200007800098398@nat28.tlf.novell.com>
	<CAOvdn6UT13qvWbMyfZkWND03RoVKVSgb6wW4yqTUpuBYEX01Dg@mail.gmail.com>
	<CAOvdn6W+XZiiJyUb04WwMEh+WFB5Dam+NLpKa1DuTCGLU=BuaA@mail.gmail.com>
	<50462B9D02000078000987A4@nat28.tlf.novell.com>
	<27134645888804121@unknownmsgid>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <27134645888804121@unknownmsgid>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: Thomas Goetz <thomas.goetz@citrix.com>, xen-devel <xen-devel@lists.xen.org>,
	Ben Guthro <ben@guthro.net>, Jan Beulich <JBeulich@suse.com>,
	"john.baboval@citrix.com" <john.baboval@citrix.com>
Subject: Re: [Xen-devel] Xen4.2 S3 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 Tue, Sep 04, 2012 at 10:28:37AM -0400, Ben Guthro wrote:
> How is it that it works with an older hypervisor, then?
> 
> Konrad - is the v7 code functionally different than the v10 code, or
> is it more  stylistic changes?

It is that v3.4 (and up) already has the restore_MSI hypervisor call:

commit 8605c6844fb9bdf55471bb87c3ac62d44eb34e04
Author: Tang Liang <liang.tang@oracle.com>
Date:   Thu Dec 8 17:36:39 2011 +0800

    xen: Utilize the restore_msi_irqs hook.
    
    to make a hypercall to restore the vectors in the MSI/MSI-X
    configuration space.
    
    Signed-off-by: Tang Liang <liang.tang@oracle.com>
    Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

The only part that is left out of mainline is the part where the hypercall
is done properly. That is what the acpi/s3.v10 does.. but after talking to
Len he pointed out a different way of doing this.

> 
> On Sep 4, 2012, at 10:25 AM, Jan Beulich <JBeulich@suse.com> wrote:
> 
> >>>> On 04.09.12 at 14:49, Ben Guthro <ben@guthro.net> wrote:
> >> I forgot to address your dom0 kernel concern -
> >>
> >> All of these tests have been run with Konrad Wilk's acpi-s3.vX branches.
> >>
> >> The later kernels took more recent branches, while the 3.2.yy kernels
> >> used an older (but still functional) branch (acpi-s3.v7)
> >
> > This and the log you provided suggest that your kernel is lacking
> > the MSI restore code altogether (or it is not getting called as
> > intended). With that, there's pretty little point in continuing
> > the investigation on the hypervisor side.
> >
> > Jan
> >

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

From xen-devel-bounces@lists.xen.org Tue Sep 04 14:48:24 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Sep 2012 14:48:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T8uQA-0002WS-FZ; Tue, 04 Sep 2012 14:48:06 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1T8uQ9-0002WG-7s
	for xen-devel@lists.xensource.com; Tue, 04 Sep 2012 14:48:05 +0000
Received: from [85.158.143.35:55958] by server-1.bemta-4.messagelabs.com id
	40/11-12504-4A416405; Tue, 04 Sep 2012 14:48:04 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1346770081!13334432!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzI5MDMy\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9409 invoked from network); 4 Sep 2012 14:48:02 -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; 4 Sep 2012 14:48: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 q84Elw1h025999
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 4 Sep 2012 14:47:59 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q84ElwVG023930
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 4 Sep 2012 14:47:58 GMT
Received: from abhmt111.oracle.com (abhmt111.oracle.com [141.146.116.63])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q84ElwiZ030236; Tue, 4 Sep 2012 09:47:58 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 04 Sep 2012 07:47:57 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 19DCC402BA; Tue,  4 Sep 2012 10:37:31 -0400 (EDT)
Date: Tue, 4 Sep 2012 10:37:31 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Stefano Panella <stefano.panella@citrix.com>
Message-ID: <20120904143731.GC23361@phenom.dumpdata.com>
References: <1346407072-6405-1-git-send-email-stefano.panella@citrix.com>
	<5040B249.4000306@citrix.com>
	<20120831164010.GA18929@localhost.localdomain>
	<50460B2E.3020200@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <50460B2E.3020200@citrix.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	David Vrabel <david.vrabel@citrix.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [Xen-devel] [PATCH 1/1] XEN: Use correct masking in
 xen_swiotlb_alloc_coherent.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Sep 04, 2012 at 03:07:42PM +0100, Stefano Panella wrote:
> On 08/31/2012 05:40 PM, Konrad Rzeszutek Wilk wrote:
> >On Fri, Aug 31, 2012 at 01:47:05PM +0100, David Vrabel wrote:
> >>On 31/08/12 10:57, Stefano Panella wrote:
> >>>When running 32-bit pvops-dom0 and a driver tries to allocate a coherent
> >>>DMA-memory the xen swiotlb-implementation returned memory beyond 4GB.
> >>>
> >>>This caused for example not working sound on a system with 4 GB and a 64-bit
> >>>compatible sound-card with sets the DMA-mask to 64bit.
> >>>
> >>>On bare-metal and the forward-ported xen-dom0 patches from OpenSuse a coherent
> >>>DMA-memory is always allocated inside the 32-bit address-range by calling
> >>>dma_alloc_coherent_mask.
> >>We should have the same behaviour under Xen as bare metal so:
> >>
> >>Acked-By: David Vrabel <david.vrabel@citrix.com>
> >>
> >>This does limit the DMA mask to 32-bits by passing it through an
> >>unsigned long, which seems a bit sneaky...
> >so is the issue that we are not casting it from 'u64' to 'u32'
> >(unsigned long) on 32-bit?
> 
> Yes. I do not completely understand why but I think on 32-bit kernel we need to cast dma_mask to u32. This is done automatically using dma_alloc_coherent_mask()
> 
> >
> >>Presumably the sound card is capable of handling 64 bit physical
> >>addresses (or it would break under 64-bit kernels) so it's not clear why
> >>this sound driver requires this restriction.
> >>
> >>Is there a bug in the sound driver or sound subsystem where it's
> >>truncating a dma_addr_t by assigning it to an unsigned long or similar?
> >>
> >>>--- a/drivers/xen/swiotlb-xen.c
> >>>+++ b/drivers/xen/swiotlb-xen.c
> >>>@@ -232,7 +232,7 @@ xen_swiotlb_alloc_coherent(struct device *hwdev, size_t size,
> >>>  		return ret;
> >>>  	if (hwdev && hwdev->coherent_dma_mask)
> >>>-		dma_mask = hwdev->coherent_dma_mask;
> >>>+		dma_mask = dma_alloc_coherent_mask(hwdev, flags);
> >>Suggest
> >>
> >>     if (hwdev)
> >>         dma_mask = dma_alloc_coherent_mask(hwdev, flags)
> 
> I can change the patch like that if you like.
> 
> >Isn't that code just doing this:
> >atic inline unsigned long dma_alloc_coherent_mask(struct device *dev,
> >                                                     gfp_t gfp)
> >{
> >         unsigned long dma_mask = 0;
> >
> >         dma_mask = dev->coherent_dma_mask;
> >         if (!dma_mask)
> >                 dma_mask = (gfp & GFP_DMA) ? DMA_BIT_MASK(24) :
> >DMA_BIT_MASK(32);
> >
> >         return dma_mask;
> >}
> >
> >and in our code, the dma_mask by default is DMA_BIT_MASK(32):
> >
> >u64 dma_mask = DMA_BIT_MASK(32);
> >
> >So what I am missing?
> 
> I am not sure what you mean with "what am I missing?"
> 
> Current code looks like:
> 
> void *
> xen_swiotlb_alloc_coherent(struct device *hwdev, size_t size,
>                            dma_addr_t *dma_handle, gfp_t flags,
>                            struct dma_attrs *attrs)
> {
>         void *ret;
>         int order = get_order(size);
>         u64 dma_mask = DMA_BIT_MASK(32);
>         unsigned long vstart;
>         phys_addr_t phys;
>         dma_addr_t dev_addr;
> 
>         /*
>         * Ignore region specifiers - the kernel's ideas of
>         * pseudo-phys memory layout has nothing to do with the
>         * machine physical layout.  We can't allocate highmem
>         * because we can't return a pointer to it.
>         */
>         flags &= ~(__GFP_DMA | __GFP_HIGHMEM);
> 
>         if (dma_alloc_from_coherent(hwdev, size, dma_handle, &ret))
>                 return ret;
> 
>         vstart = __get_free_pages(flags, order);
>         ret = (void *)vstart;
> 
>         if (!ret)
>                 return ret;
> 
>         if (hwdev && hwdev->coherent_dma_mask)
>                 dma_mask = hwdev->coherent_dma_mask;
> 
> 
> So if hwdev->coherent_dma_mask is set to 0xffffffffffffffff our dma_mask will
> be u64 set to 0xffffffffffffffff even if we set it to DMA_BIT_MASK(32) previously.

That is what I was missing. Let me include that in the git commit and also
put this patch on the stable tree.

> 
> I hope I am not getting this wrong and let me know if I should send an updated version
> of the patch including David V. change.
> 
> Regards,
> 
> Stefano

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

From xen-devel-bounces@lists.xen.org Tue Sep 04 14:48:24 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Sep 2012 14:48:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T8uQA-0002WS-FZ; Tue, 04 Sep 2012 14:48:06 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1T8uQ9-0002WG-7s
	for xen-devel@lists.xensource.com; Tue, 04 Sep 2012 14:48:05 +0000
Received: from [85.158.143.35:55958] by server-1.bemta-4.messagelabs.com id
	40/11-12504-4A416405; Tue, 04 Sep 2012 14:48:04 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1346770081!13334432!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzI5MDMy\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9409 invoked from network); 4 Sep 2012 14:48:02 -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; 4 Sep 2012 14:48: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 q84Elw1h025999
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 4 Sep 2012 14:47:59 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q84ElwVG023930
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 4 Sep 2012 14:47:58 GMT
Received: from abhmt111.oracle.com (abhmt111.oracle.com [141.146.116.63])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q84ElwiZ030236; Tue, 4 Sep 2012 09:47:58 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 04 Sep 2012 07:47:57 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 19DCC402BA; Tue,  4 Sep 2012 10:37:31 -0400 (EDT)
Date: Tue, 4 Sep 2012 10:37:31 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Stefano Panella <stefano.panella@citrix.com>
Message-ID: <20120904143731.GC23361@phenom.dumpdata.com>
References: <1346407072-6405-1-git-send-email-stefano.panella@citrix.com>
	<5040B249.4000306@citrix.com>
	<20120831164010.GA18929@localhost.localdomain>
	<50460B2E.3020200@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <50460B2E.3020200@citrix.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	David Vrabel <david.vrabel@citrix.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [Xen-devel] [PATCH 1/1] XEN: Use correct masking in
 xen_swiotlb_alloc_coherent.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Sep 04, 2012 at 03:07:42PM +0100, Stefano Panella wrote:
> On 08/31/2012 05:40 PM, Konrad Rzeszutek Wilk wrote:
> >On Fri, Aug 31, 2012 at 01:47:05PM +0100, David Vrabel wrote:
> >>On 31/08/12 10:57, Stefano Panella wrote:
> >>>When running 32-bit pvops-dom0 and a driver tries to allocate a coherent
> >>>DMA-memory the xen swiotlb-implementation returned memory beyond 4GB.
> >>>
> >>>This caused for example not working sound on a system with 4 GB and a 64-bit
> >>>compatible sound-card with sets the DMA-mask to 64bit.
> >>>
> >>>On bare-metal and the forward-ported xen-dom0 patches from OpenSuse a coherent
> >>>DMA-memory is always allocated inside the 32-bit address-range by calling
> >>>dma_alloc_coherent_mask.
> >>We should have the same behaviour under Xen as bare metal so:
> >>
> >>Acked-By: David Vrabel <david.vrabel@citrix.com>
> >>
> >>This does limit the DMA mask to 32-bits by passing it through an
> >>unsigned long, which seems a bit sneaky...
> >so is the issue that we are not casting it from 'u64' to 'u32'
> >(unsigned long) on 32-bit?
> 
> Yes. I do not completely understand why but I think on 32-bit kernel we need to cast dma_mask to u32. This is done automatically using dma_alloc_coherent_mask()
> 
> >
> >>Presumably the sound card is capable of handling 64 bit physical
> >>addresses (or it would break under 64-bit kernels) so it's not clear why
> >>this sound driver requires this restriction.
> >>
> >>Is there a bug in the sound driver or sound subsystem where it's
> >>truncating a dma_addr_t by assigning it to an unsigned long or similar?
> >>
> >>>--- a/drivers/xen/swiotlb-xen.c
> >>>+++ b/drivers/xen/swiotlb-xen.c
> >>>@@ -232,7 +232,7 @@ xen_swiotlb_alloc_coherent(struct device *hwdev, size_t size,
> >>>  		return ret;
> >>>  	if (hwdev && hwdev->coherent_dma_mask)
> >>>-		dma_mask = hwdev->coherent_dma_mask;
> >>>+		dma_mask = dma_alloc_coherent_mask(hwdev, flags);
> >>Suggest
> >>
> >>     if (hwdev)
> >>         dma_mask = dma_alloc_coherent_mask(hwdev, flags)
> 
> I can change the patch like that if you like.
> 
> >Isn't that code just doing this:
> >atic inline unsigned long dma_alloc_coherent_mask(struct device *dev,
> >                                                     gfp_t gfp)
> >{
> >         unsigned long dma_mask = 0;
> >
> >         dma_mask = dev->coherent_dma_mask;
> >         if (!dma_mask)
> >                 dma_mask = (gfp & GFP_DMA) ? DMA_BIT_MASK(24) :
> >DMA_BIT_MASK(32);
> >
> >         return dma_mask;
> >}
> >
> >and in our code, the dma_mask by default is DMA_BIT_MASK(32):
> >
> >u64 dma_mask = DMA_BIT_MASK(32);
> >
> >So what I am missing?
> 
> I am not sure what you mean with "what am I missing?"
> 
> Current code looks like:
> 
> void *
> xen_swiotlb_alloc_coherent(struct device *hwdev, size_t size,
>                            dma_addr_t *dma_handle, gfp_t flags,
>                            struct dma_attrs *attrs)
> {
>         void *ret;
>         int order = get_order(size);
>         u64 dma_mask = DMA_BIT_MASK(32);
>         unsigned long vstart;
>         phys_addr_t phys;
>         dma_addr_t dev_addr;
> 
>         /*
>         * Ignore region specifiers - the kernel's ideas of
>         * pseudo-phys memory layout has nothing to do with the
>         * machine physical layout.  We can't allocate highmem
>         * because we can't return a pointer to it.
>         */
>         flags &= ~(__GFP_DMA | __GFP_HIGHMEM);
> 
>         if (dma_alloc_from_coherent(hwdev, size, dma_handle, &ret))
>                 return ret;
> 
>         vstart = __get_free_pages(flags, order);
>         ret = (void *)vstart;
> 
>         if (!ret)
>                 return ret;
> 
>         if (hwdev && hwdev->coherent_dma_mask)
>                 dma_mask = hwdev->coherent_dma_mask;
> 
> 
> So if hwdev->coherent_dma_mask is set to 0xffffffffffffffff our dma_mask will
> be u64 set to 0xffffffffffffffff even if we set it to DMA_BIT_MASK(32) previously.

That is what I was missing. Let me include that in the git commit and also
put this patch on the stable tree.

> 
> I hope I am not getting this wrong and let me know if I should send an updated version
> of the patch including David V. change.
> 
> Regards,
> 
> Stefano

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

From xen-devel-bounces@lists.xen.org Tue Sep 04 14:55:44 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Sep 2012 14:55:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T8uXJ-0002qE-D9; Tue, 04 Sep 2012 14:55:29 +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 1T8uXI-0002q9-AU
	for xen-devel@lists.xensource.com; Tue, 04 Sep 2012 14:55:28 +0000
Received: from [85.158.138.51:42501] by server-10.bemta-3.messagelabs.com id
	CF/25-10411-F5616405; Tue, 04 Sep 2012 14:55:27 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1346770523!22229884!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNzY0OTI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7822 invoked from network); 4 Sep 2012 14:55:24 -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;
	4 Sep 2012 14:55:24 -0000
X-IronPort-AV: E=Sophos;i="4.80,367,1344211200"; d="scan'208";a="207015968"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Sep 2012 14:55:18 +0000
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.279.1; Tue, 4 Sep 2012
	10:55:18 -0400
Message-ID: <50461654.5040901@citrix.com>
Date: Tue, 4 Sep 2012 15:55:16 +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 Iceowl/1.0b1 Icedove/3.0.11
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
References: <1346407072-6405-1-git-send-email-stefano.panella@citrix.com>
	<5040B249.4000306@citrix.com>
	<20120831164010.GA18929@localhost.localdomain>
	<50460B2E.3020200@citrix.com>
	<20120904143731.GC23361@phenom.dumpdata.com>
In-Reply-To: <20120904143731.GC23361@phenom.dumpdata.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefano Panella <stefano.panella@citrix.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [Xen-devel] [PATCH 1/1] XEN: Use correct masking in
	xen_swiotlb_alloc_coherent.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/09/12 15:37, Konrad Rzeszutek Wilk wrote:
> On Tue, Sep 04, 2012 at 03:07:42PM +0100, Stefano Panella wrote:
>> 
>> So if hwdev->coherent_dma_mask is set to 0xffffffffffffffff our dma_mask will
>> be u64 set to 0xffffffffffffffff even if we set it to DMA_BIT_MASK(32) previously.
> 
> That is what I was missing. Let me include that in the git commit and also
> put this patch on the stable tree.

Note that this appears to be a work around for a bug in the sound system
or Intel HDA device driver which is incorrectly truncating a dma_addr_t
to a u32.  So by ensuring a DMA_BIT_MASK(32) when the dma_addr_t is
truncated it still works.

David

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

From xen-devel-bounces@lists.xen.org Tue Sep 04 14:55:44 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Sep 2012 14:55:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T8uXJ-0002qE-D9; Tue, 04 Sep 2012 14:55:29 +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 1T8uXI-0002q9-AU
	for xen-devel@lists.xensource.com; Tue, 04 Sep 2012 14:55:28 +0000
Received: from [85.158.138.51:42501] by server-10.bemta-3.messagelabs.com id
	CF/25-10411-F5616405; Tue, 04 Sep 2012 14:55:27 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1346770523!22229884!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNzY0OTI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7822 invoked from network); 4 Sep 2012 14:55:24 -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;
	4 Sep 2012 14:55:24 -0000
X-IronPort-AV: E=Sophos;i="4.80,367,1344211200"; d="scan'208";a="207015968"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Sep 2012 14:55:18 +0000
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.279.1; Tue, 4 Sep 2012
	10:55:18 -0400
Message-ID: <50461654.5040901@citrix.com>
Date: Tue, 4 Sep 2012 15:55:16 +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 Iceowl/1.0b1 Icedove/3.0.11
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
References: <1346407072-6405-1-git-send-email-stefano.panella@citrix.com>
	<5040B249.4000306@citrix.com>
	<20120831164010.GA18929@localhost.localdomain>
	<50460B2E.3020200@citrix.com>
	<20120904143731.GC23361@phenom.dumpdata.com>
In-Reply-To: <20120904143731.GC23361@phenom.dumpdata.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefano Panella <stefano.panella@citrix.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [Xen-devel] [PATCH 1/1] XEN: Use correct masking in
	xen_swiotlb_alloc_coherent.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/09/12 15:37, Konrad Rzeszutek Wilk wrote:
> On Tue, Sep 04, 2012 at 03:07:42PM +0100, Stefano Panella wrote:
>> 
>> So if hwdev->coherent_dma_mask is set to 0xffffffffffffffff our dma_mask will
>> be u64 set to 0xffffffffffffffff even if we set it to DMA_BIT_MASK(32) previously.
> 
> That is what I was missing. Let me include that in the git commit and also
> put this patch on the stable tree.

Note that this appears to be a work around for a bug in the sound system
or Intel HDA device driver which is incorrectly truncating a dma_addr_t
to a u32.  So by ensuring a DMA_BIT_MASK(32) when the dma_addr_t is
truncated it still works.

David

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

From xen-devel-bounces@lists.xen.org Tue Sep 04 15:01:45 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Sep 2012 15:01:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T8ud6-00031T-AX; Tue, 04 Sep 2012 15:01:28 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1T8ud4-00031N-LP
	for xen-devel@lists.xen.org; Tue, 04 Sep 2012 15:01:26 +0000
Received: from [85.158.138.51:60861] by server-2.bemta-3.messagelabs.com id
	EC/72-04862-5C716405; Tue, 04 Sep 2012 15:01:25 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1346770884!28599852!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM4Mzg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13939 invoked from network); 4 Sep 2012 15:01:25 -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;
	4 Sep 2012 15:01:25 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 04 Sep 2012 16:01:25 +0100
Message-Id: <5046341702000078000987E8@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 04 Sep 2012 16:02:15 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ben Guthro" <ben.guthro@gmail.com>
References: <CAOvdn6WwgBD-2yf1uu3m9-16=Tb5KUrybXf2KibtnxKbP7YtwA@mail.gmail.com>
	<CAOvdn6UBW-yTOMd3YSf5M9JiHLRivyaKL-qzcKG8epszqaKmGg@mail.gmail.com>
	<20120807163320.GC15053@phenom.dumpdata.com>
	<CAOvdn6XcRGKtJxGwJO8J+ZBJr89wfTLc1woW5rhtMM540H9h1w@mail.gmail.com>
	<CAOvdn6XUoSeGoo7X=AJ1kpDxZB9HZEv+TJ4v-=FHcyR4=CHK-w@mail.gmail.com>
	<502240F302000078000937A6@nat28.tlf.novell.com>
	<CAOvdn6WN3kxC8Bb9g6MpfLULu47EGSGCtajPc-SFeJ-8VSUQDQ@mail.gmail.com>
	<CAOvdn6Xk1inm1hU55i0phU2qvSWyJLNoyDdn43biBAY2OewPtw@mail.gmail.com>
	<5023F5400200007800093F4E@nat28.tlf.novell.com>
	<CAOvdn6U-f3C4U8xVPvDyRFkFFLkbfiCXg_n+9zgA9V5u+q5jfw@mail.gmail.com>
	<5023F8B80200007800093F8C@nat28.tlf.novell.com>
	<CAOvdn6XKHfete_+=Hkvt20G7_cJ-4i8+9j9YD30OxzQ16Ru-+g@mail.gmail.com>
	<5024CB720200007800094124@nat28.tlf.novell.com>
	<CAOvdn6VVJdhWVYa-gNVt3euE4AbGi1TijUCUd1wGzv0SCWEUYA@mail.gmail.com>
	<CAOvdn6USnG9Y4MNBhrDZmob0oJ8BgFfKTvFEhcKbXDxNmzfZ-Q@mail.gmail.com>
	<502B75BA0200007800094FD4@nat28.tlf.novell.com>
	<CAOvdn6Ww5oEj6Xg=XT4dWCYWUBuOdPqLz-CqNjz4HmCScE+==g@mail.gmail.com>
	<CAOvdn6Wsjds_dmZ0dwDTYmD-o-OqjBH5-b9mitAuUADE+A4_ag@mail.gmail.com>
	<502BB8FD02000078000951E0@nat28.tlf.novell.com>
	<CAOvdn6VD6bp13F-tvYdkBsj4hkhE7PTGZrapndtdHrDKeZqccg@mail.gmail.com>
	<502CCC0002000078000955C4@nat28.tlf.novell.com>
	<CAOvdn6VEuX7R2_wz74ZvCxMjC-=YUir9kP5sdxEVaKVspRUd_w@mail.gmail.com>
	<502CF0A8020000780009574E@nat28.tlf.novell.com>
	<CAOvdn6VsZvn_1TCWYeuyY5YuTcP8=miK2KwE4583nsj6Qjb_vg@mail.gmail.com>
	<504494FB0200007800098398@nat28.tlf.novell.com>
	<CAOvdn6UT13qvWbMyfZkWND03RoVKVSgb6wW4yqTUpuBYEX01Dg@mail.gmail.com>
	<CAOvdn6W+XZiiJyUb04WwMEh+WFB5Dam+NLpKa1DuTCGLU=BuaA@mail.gmail.com>
	<50462B9D02000078000987A4@nat28.tlf.novell.com>
	<27134645888804121@unknownmsgid>
In-Reply-To: <27134645888804121@unknownmsgid>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	xen-devel <xen-devel@lists.xen.org>,
	"john.baboval@citrix.com" <john.baboval@citrix.com>,
	Thomas Goetz <thomas.goetz@citrix.com>, Ben Guthro <ben@guthro.net>
Subject: Re: [Xen-devel] Xen4.2 S3 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 04.09.12 at 16:28, Ben Guthro <ben.guthro@gmail.com> wrote:
> How is it that it works with an older hypervisor, then?

Actually, checking again I see that I overlooked that specific
log entry (I expected them to be all close together, but they
aren't).

It is obvious that on the second restore the kernel passes
bad data to the hypervisor, but I can't tell yet whether that's
the kernel's fault - will need to look more closely.

Jan

> Konrad - is the v7 code functionally different than the v10 code, or
> is it more  stylistic changes?
> 
> On Sep 4, 2012, at 10:25 AM, Jan Beulich <JBeulich@suse.com> wrote:
> 
>>>>> On 04.09.12 at 14:49, Ben Guthro <ben@guthro.net> wrote:
>>> I forgot to address your dom0 kernel concern -
>>>
>>> All of these tests have been run with Konrad Wilk's acpi-s3.vX branches.
>>>
>>> The later kernels took more recent branches, while the 3.2.yy kernels
>>> used an older (but still functional) branch (acpi-s3.v7)
>>
>> This and the log you provided suggest that your kernel is lacking
>> the MSI restore code altogether (or it is not getting called as
>> intended). With that, there's pretty little point in continuing
>> the investigation on the hypervisor side.
>>
>> Jan
>>




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

From xen-devel-bounces@lists.xen.org Tue Sep 04 15:01:45 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Sep 2012 15:01:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T8ud6-00031T-AX; Tue, 04 Sep 2012 15:01:28 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1T8ud4-00031N-LP
	for xen-devel@lists.xen.org; Tue, 04 Sep 2012 15:01:26 +0000
Received: from [85.158.138.51:60861] by server-2.bemta-3.messagelabs.com id
	EC/72-04862-5C716405; Tue, 04 Sep 2012 15:01:25 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1346770884!28599852!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM4Mzg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13939 invoked from network); 4 Sep 2012 15:01:25 -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;
	4 Sep 2012 15:01:25 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 04 Sep 2012 16:01:25 +0100
Message-Id: <5046341702000078000987E8@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 04 Sep 2012 16:02:15 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ben Guthro" <ben.guthro@gmail.com>
References: <CAOvdn6WwgBD-2yf1uu3m9-16=Tb5KUrybXf2KibtnxKbP7YtwA@mail.gmail.com>
	<CAOvdn6UBW-yTOMd3YSf5M9JiHLRivyaKL-qzcKG8epszqaKmGg@mail.gmail.com>
	<20120807163320.GC15053@phenom.dumpdata.com>
	<CAOvdn6XcRGKtJxGwJO8J+ZBJr89wfTLc1woW5rhtMM540H9h1w@mail.gmail.com>
	<CAOvdn6XUoSeGoo7X=AJ1kpDxZB9HZEv+TJ4v-=FHcyR4=CHK-w@mail.gmail.com>
	<502240F302000078000937A6@nat28.tlf.novell.com>
	<CAOvdn6WN3kxC8Bb9g6MpfLULu47EGSGCtajPc-SFeJ-8VSUQDQ@mail.gmail.com>
	<CAOvdn6Xk1inm1hU55i0phU2qvSWyJLNoyDdn43biBAY2OewPtw@mail.gmail.com>
	<5023F5400200007800093F4E@nat28.tlf.novell.com>
	<CAOvdn6U-f3C4U8xVPvDyRFkFFLkbfiCXg_n+9zgA9V5u+q5jfw@mail.gmail.com>
	<5023F8B80200007800093F8C@nat28.tlf.novell.com>
	<CAOvdn6XKHfete_+=Hkvt20G7_cJ-4i8+9j9YD30OxzQ16Ru-+g@mail.gmail.com>
	<5024CB720200007800094124@nat28.tlf.novell.com>
	<CAOvdn6VVJdhWVYa-gNVt3euE4AbGi1TijUCUd1wGzv0SCWEUYA@mail.gmail.com>
	<CAOvdn6USnG9Y4MNBhrDZmob0oJ8BgFfKTvFEhcKbXDxNmzfZ-Q@mail.gmail.com>
	<502B75BA0200007800094FD4@nat28.tlf.novell.com>
	<CAOvdn6Ww5oEj6Xg=XT4dWCYWUBuOdPqLz-CqNjz4HmCScE+==g@mail.gmail.com>
	<CAOvdn6Wsjds_dmZ0dwDTYmD-o-OqjBH5-b9mitAuUADE+A4_ag@mail.gmail.com>
	<502BB8FD02000078000951E0@nat28.tlf.novell.com>
	<CAOvdn6VD6bp13F-tvYdkBsj4hkhE7PTGZrapndtdHrDKeZqccg@mail.gmail.com>
	<502CCC0002000078000955C4@nat28.tlf.novell.com>
	<CAOvdn6VEuX7R2_wz74ZvCxMjC-=YUir9kP5sdxEVaKVspRUd_w@mail.gmail.com>
	<502CF0A8020000780009574E@nat28.tlf.novell.com>
	<CAOvdn6VsZvn_1TCWYeuyY5YuTcP8=miK2KwE4583nsj6Qjb_vg@mail.gmail.com>
	<504494FB0200007800098398@nat28.tlf.novell.com>
	<CAOvdn6UT13qvWbMyfZkWND03RoVKVSgb6wW4yqTUpuBYEX01Dg@mail.gmail.com>
	<CAOvdn6W+XZiiJyUb04WwMEh+WFB5Dam+NLpKa1DuTCGLU=BuaA@mail.gmail.com>
	<50462B9D02000078000987A4@nat28.tlf.novell.com>
	<27134645888804121@unknownmsgid>
In-Reply-To: <27134645888804121@unknownmsgid>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	xen-devel <xen-devel@lists.xen.org>,
	"john.baboval@citrix.com" <john.baboval@citrix.com>,
	Thomas Goetz <thomas.goetz@citrix.com>, Ben Guthro <ben@guthro.net>
Subject: Re: [Xen-devel] Xen4.2 S3 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 04.09.12 at 16:28, Ben Guthro <ben.guthro@gmail.com> wrote:
> How is it that it works with an older hypervisor, then?

Actually, checking again I see that I overlooked that specific
log entry (I expected them to be all close together, but they
aren't).

It is obvious that on the second restore the kernel passes
bad data to the hypervisor, but I can't tell yet whether that's
the kernel's fault - will need to look more closely.

Jan

> Konrad - is the v7 code functionally different than the v10 code, or
> is it more  stylistic changes?
> 
> On Sep 4, 2012, at 10:25 AM, Jan Beulich <JBeulich@suse.com> wrote:
> 
>>>>> On 04.09.12 at 14:49, Ben Guthro <ben@guthro.net> wrote:
>>> I forgot to address your dom0 kernel concern -
>>>
>>> All of these tests have been run with Konrad Wilk's acpi-s3.vX branches.
>>>
>>> The later kernels took more recent branches, while the 3.2.yy kernels
>>> used an older (but still functional) branch (acpi-s3.v7)
>>
>> This and the log you provided suggest that your kernel is lacking
>> the MSI restore code altogether (or it is not getting called as
>> intended). With that, there's pretty little point in continuing
>> the investigation on the hypervisor side.
>>
>> Jan
>>




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

From xen-devel-bounces@lists.xen.org Tue Sep 04 15:07:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Sep 2012 15:07: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 1T8uiU-0003EM-Lo; Tue, 04 Sep 2012 15:07:02 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1T8uiS-0003EF-J9
	for xen-devel@lists.xen.org; Tue, 04 Sep 2012 15:07:00 +0000
Received: from [85.158.143.35:64101] by server-3.bemta-4.messagelabs.com id
	8C/04-08232-31916405; Tue, 04 Sep 2012 15:06:59 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-13.tower-21.messagelabs.com!1346771217!15253487!1
X-Originating-IP: [208.97.132.177]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4xNzcgPT4gMjk1Nzc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14875 invoked from network); 4 Sep 2012 15:06:57 -0000
Received: from caiajhbdcbhh.dreamhost.com (HELO homiemail-a13.g.dreamhost.com)
	(208.97.132.177) by server-13.tower-21.messagelabs.com with SMTP;
	4 Sep 2012 15:06:57 -0000
Received: from homiemail-a13.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a13.g.dreamhost.com (Postfix) with ESMTP id 42D30334082;
	Tue,  4 Sep 2012 08:06:26 -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=Ed+Fap31SIkdvhUW16fof2
	I2MglixE4qsg4Ro1j35HMyZah2lk0MxtumpFco9AH89y71NOiA10u8fSFxANOr2F
	W+e9fQ+5jphq0wBtFVuBHWe5pOBV5I4Lr9JZrq2Ux1UV7zSVD1gcYmrtr4d787Gy
	z4jH4GjO4k5oucyYL9H4c=
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=1s2Y9u29hFi/
	c9dTJkzmCwI+kBc=; b=e8f+7JnDGkN0i0Gad43kNyL/jEVZcmdhxt8Jl8+EsA1J
	cF+1qTl1qWPbLsqr6jGeLHvdHgldtRrkF/DEtisXC4/Qizf121tZLQHRVIBabrH5
	6vjPNDRVnr9WMLG3Tis6G31L+VYjxjIMFGTjyay1VlLjX6Ezcgyau8thJb8euK8=
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-a13.g.dreamhost.com (Postfix) with ESMTPSA id 90AE2334085; 
	Tue,  4 Sep 2012 08:06:25 -0700 (PDT)
MIME-Version: 1.0
X-Mercurial-Node: a18d6bd0d127e8e8903dd582f3c8b51dfb3ef6a0
Message-Id: <a18d6bd0d127e8e8903d.1346771510@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Tue, 04 Sep 2012 11:11:50 -0400
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xen.org
Cc: keir@xen.org, andres@gridcentric.ca, tim@xen.org, JBeulich@suse.com
Subject: [Xen-devel] [PATCH] Extra check in grant table code for mapping of
	shared frame
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

 xen/common/grant_table.c |  9 ++++++---
 1 files changed, 6 insertions(+), 3 deletions(-)


Small fix, please consider for 4.2. Thanks.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r 3a6050031b9f -r a18d6bd0d127 xen/common/grant_table.c
--- a/xen/common/grant_table.c
+++ b/xen/common/grant_table.c
@@ -649,9 +649,12 @@ __gnttab_map_grant_ref(
     }
     else if ( owner == rd || owner == dom_cow )
     {
-        if ( gnttab_host_mapping_get_page_type(op, ld, rd) &&
-             !get_page_type(pg, PGT_writable_page) )
-            goto could_not_pin;
+        if ( gnttab_host_mapping_get_page_type(op, ld, rd) )
+        {
+            if ( (owner == dom_cow) ||
+                 !get_page_type(pg, PGT_writable_page) )
+                goto could_not_pin;
+        }
 
         nr_gets++;
         if ( op->flags & GNTMAP_host_map )

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

From xen-devel-bounces@lists.xen.org Tue Sep 04 15:07:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Sep 2012 15:07: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 1T8uiU-0003EM-Lo; Tue, 04 Sep 2012 15:07:02 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1T8uiS-0003EF-J9
	for xen-devel@lists.xen.org; Tue, 04 Sep 2012 15:07:00 +0000
Received: from [85.158.143.35:64101] by server-3.bemta-4.messagelabs.com id
	8C/04-08232-31916405; Tue, 04 Sep 2012 15:06:59 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-13.tower-21.messagelabs.com!1346771217!15253487!1
X-Originating-IP: [208.97.132.177]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4xNzcgPT4gMjk1Nzc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14875 invoked from network); 4 Sep 2012 15:06:57 -0000
Received: from caiajhbdcbhh.dreamhost.com (HELO homiemail-a13.g.dreamhost.com)
	(208.97.132.177) by server-13.tower-21.messagelabs.com with SMTP;
	4 Sep 2012 15:06:57 -0000
Received: from homiemail-a13.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a13.g.dreamhost.com (Postfix) with ESMTP id 42D30334082;
	Tue,  4 Sep 2012 08:06:26 -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=Ed+Fap31SIkdvhUW16fof2
	I2MglixE4qsg4Ro1j35HMyZah2lk0MxtumpFco9AH89y71NOiA10u8fSFxANOr2F
	W+e9fQ+5jphq0wBtFVuBHWe5pOBV5I4Lr9JZrq2Ux1UV7zSVD1gcYmrtr4d787Gy
	z4jH4GjO4k5oucyYL9H4c=
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=1s2Y9u29hFi/
	c9dTJkzmCwI+kBc=; b=e8f+7JnDGkN0i0Gad43kNyL/jEVZcmdhxt8Jl8+EsA1J
	cF+1qTl1qWPbLsqr6jGeLHvdHgldtRrkF/DEtisXC4/Qizf121tZLQHRVIBabrH5
	6vjPNDRVnr9WMLG3Tis6G31L+VYjxjIMFGTjyay1VlLjX6Ezcgyau8thJb8euK8=
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-a13.g.dreamhost.com (Postfix) with ESMTPSA id 90AE2334085; 
	Tue,  4 Sep 2012 08:06:25 -0700 (PDT)
MIME-Version: 1.0
X-Mercurial-Node: a18d6bd0d127e8e8903dd582f3c8b51dfb3ef6a0
Message-Id: <a18d6bd0d127e8e8903d.1346771510@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Tue, 04 Sep 2012 11:11:50 -0400
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xen.org
Cc: keir@xen.org, andres@gridcentric.ca, tim@xen.org, JBeulich@suse.com
Subject: [Xen-devel] [PATCH] Extra check in grant table code for mapping of
	shared frame
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

 xen/common/grant_table.c |  9 ++++++---
 1 files changed, 6 insertions(+), 3 deletions(-)


Small fix, please consider for 4.2. Thanks.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r 3a6050031b9f -r a18d6bd0d127 xen/common/grant_table.c
--- a/xen/common/grant_table.c
+++ b/xen/common/grant_table.c
@@ -649,9 +649,12 @@ __gnttab_map_grant_ref(
     }
     else if ( owner == rd || owner == dom_cow )
     {
-        if ( gnttab_host_mapping_get_page_type(op, ld, rd) &&
-             !get_page_type(pg, PGT_writable_page) )
-            goto could_not_pin;
+        if ( gnttab_host_mapping_get_page_type(op, ld, rd) )
+        {
+            if ( (owner == dom_cow) ||
+                 !get_page_type(pg, PGT_writable_page) )
+                goto could_not_pin;
+        }
 
         nr_gets++;
         if ( op->flags & GNTMAP_host_map )

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

From xen-devel-bounces@lists.xen.org Tue Sep 04 15:12:54 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Sep 2012 15:12: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 1T8unu-0003NT-Eh; Tue, 04 Sep 2012 15:12:38 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <stefano.panella@citrix.com>) id 1T8uns-0003NM-RE
	for xen-devel@lists.xensource.com; Tue, 04 Sep 2012 15:12:37 +0000
Received: from [85.158.138.51:61616] by server-11.bemta-3.messagelabs.com id
	BE/2C-30250-E5A16405; Tue, 04 Sep 2012 15:12:30 +0000
X-Env-Sender: stefano.panella@citrix.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1346771550!24535713!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTE3MTg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9369 invoked from network); 4 Sep 2012 15:12: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;
	4 Sep 2012 15:12:30 -0000
X-IronPort-AV: E=Sophos;i="4.80,367,1344211200"; d="scan'208";a="14339329"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Sep 2012 15:12: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.279.1; Tue, 4 Sep 2012 16:12:26 +0100
Received: from slimey.cam.xci-test.com ([10.80.249.177])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<stefano.panella@citrix.com>)	id 1T8uni-00019y-6e;
	Tue, 04 Sep 2012 15:12:26 +0000
Message-ID: <50461A59.2050504@citrix.com>
Date: Tue, 4 Sep 2012 16:12:25 +0100
From: Stefano Panella <stefano.panella@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:14.0) Gecko/20120714 Thunderbird/14.0
MIME-Version: 1.0
To: David Vrabel <david.vrabel@citrix.com>
References: <1346407072-6405-1-git-send-email-stefano.panella@citrix.com>
	<5040B249.4000306@citrix.com>
	<20120831164010.GA18929@localhost.localdomain>
	<50460B2E.3020200@citrix.com>
	<20120904143731.GC23361@phenom.dumpdata.com>
	<50461654.5040901@citrix.com>
In-Reply-To: <50461654.5040901@citrix.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH 1/1] XEN: Use correct masking in
	xen_swiotlb_alloc_coherent.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 09/04/2012 03:55 PM, David Vrabel wrote:
> On 04/09/12 15:37, Konrad Rzeszutek Wilk wrote:
>> On Tue, Sep 04, 2012 at 03:07:42PM +0100, Stefano Panella wrote:
>>> So if hwdev->coherent_dma_mask is set to 0xffffffffffffffff our dma_mask will
>>> be u64 set to 0xffffffffffffffff even if we set it to DMA_BIT_MASK(32) previously.
>> That is what I was missing. Let me include that in the git commit and also
>> put this patch on the stable tree.
> Note that this appears to be a work around for a bug in the sound system
> or Intel HDA device driver which is incorrectly truncating a dma_addr_t
> to a u32.  So by ensuring a DMA_BIT_MASK(32) when the dma_addr_t is
> truncated it still works.
>
> David
Sorry David, I am not completely sure I understand your argument in 
favour of a bug in the
sound system or Intel HDA device driver. Could you please elaborate more 
in detail about this?

Thanks,

Stefano

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

From xen-devel-bounces@lists.xen.org Tue Sep 04 15:12:54 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Sep 2012 15:12: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 1T8unu-0003NT-Eh; Tue, 04 Sep 2012 15:12:38 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <stefano.panella@citrix.com>) id 1T8uns-0003NM-RE
	for xen-devel@lists.xensource.com; Tue, 04 Sep 2012 15:12:37 +0000
Received: from [85.158.138.51:61616] by server-11.bemta-3.messagelabs.com id
	BE/2C-30250-E5A16405; Tue, 04 Sep 2012 15:12:30 +0000
X-Env-Sender: stefano.panella@citrix.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1346771550!24535713!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTE3MTg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9369 invoked from network); 4 Sep 2012 15:12: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;
	4 Sep 2012 15:12:30 -0000
X-IronPort-AV: E=Sophos;i="4.80,367,1344211200"; d="scan'208";a="14339329"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Sep 2012 15:12: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.279.1; Tue, 4 Sep 2012 16:12:26 +0100
Received: from slimey.cam.xci-test.com ([10.80.249.177])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<stefano.panella@citrix.com>)	id 1T8uni-00019y-6e;
	Tue, 04 Sep 2012 15:12:26 +0000
Message-ID: <50461A59.2050504@citrix.com>
Date: Tue, 4 Sep 2012 16:12:25 +0100
From: Stefano Panella <stefano.panella@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:14.0) Gecko/20120714 Thunderbird/14.0
MIME-Version: 1.0
To: David Vrabel <david.vrabel@citrix.com>
References: <1346407072-6405-1-git-send-email-stefano.panella@citrix.com>
	<5040B249.4000306@citrix.com>
	<20120831164010.GA18929@localhost.localdomain>
	<50460B2E.3020200@citrix.com>
	<20120904143731.GC23361@phenom.dumpdata.com>
	<50461654.5040901@citrix.com>
In-Reply-To: <50461654.5040901@citrix.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH 1/1] XEN: Use correct masking in
	xen_swiotlb_alloc_coherent.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 09/04/2012 03:55 PM, David Vrabel wrote:
> On 04/09/12 15:37, Konrad Rzeszutek Wilk wrote:
>> On Tue, Sep 04, 2012 at 03:07:42PM +0100, Stefano Panella wrote:
>>> So if hwdev->coherent_dma_mask is set to 0xffffffffffffffff our dma_mask will
>>> be u64 set to 0xffffffffffffffff even if we set it to DMA_BIT_MASK(32) previously.
>> That is what I was missing. Let me include that in the git commit and also
>> put this patch on the stable tree.
> Note that this appears to be a work around for a bug in the sound system
> or Intel HDA device driver which is incorrectly truncating a dma_addr_t
> to a u32.  So by ensuring a DMA_BIT_MASK(32) when the dma_addr_t is
> truncated it still works.
>
> David
Sorry David, I am not completely sure I understand your argument in 
favour of a bug in the
sound system or Intel HDA device driver. Could you please elaborate more 
in detail about this?

Thanks,

Stefano

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

From xen-devel-bounces@lists.xen.org Tue Sep 04 15:18:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Sep 2012 15:18: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 1T8utK-0003X1-JD; Tue, 04 Sep 2012 15:18:14 +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 1T8utJ-0003Wj-8D
	for xen-devel@lists.xen.org; Tue, 04 Sep 2012 15:18:13 +0000
Received: from [85.158.143.35:61845] by server-1.bemta-4.messagelabs.com id
	34/8A-12504-4BB16405; Tue, 04 Sep 2012 15:18:12 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1346771891!14830813!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTE3MTg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22130 invoked from network); 4 Sep 2012 15:18:12 -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;
	4 Sep 2012 15:18:12 -0000
X-IronPort-AV: E=Sophos;i="4.80,367,1344211200"; d="scan'208";a="14339466"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Sep 2012 15:17:10 +0000
Received: from Roger-2.local.net (10.31.3.231) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Tue, 4 Sep 2012
	16:17:10 +0100
From: Roger Pau Monne <roger.pau@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Tue, 4 Sep 2012 17:16:51 +0200
Message-ID: <1346771812-98690-1-git-send-email-roger.pau@citrix.com>
X-Mailer: git-send-email 1.7.7.5 (Apple Git-26)
MIME-Version: 1.0
Cc: Roger Pau Monne <roger.pau@citrix.com>
Subject: [Xen-devel] [PATCH v2 1/2] libxl: fix usage of backend parameter
	and run_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

vif interfaces allows the user to specify the domain that should run
the backend (also known as driver domain) using the 'backend'
parameter. This is not compatible with run_hotplug_scripts=1, since
libxl can only run the hotplug scripts from the Domain 0.

Signed-off-by: Roger Pau Monne <roger.pau@citrix.com>
---
Changes since v1:

 * Remove references to xl.conf, since it's a layering violation.

 * Move the docs update to next patch (that includes xl changes).
---
 tools/libxl/libxl.c |   14 ++++++++++++++
 1 files changed, 14 insertions(+), 0 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 8ea3478..47b1fb9 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -2474,6 +2474,8 @@ out:
 int libxl__device_nic_setdefault(libxl__gc *gc, libxl_device_nic *nic,
                                  uint32_t domid)
 {
+    int run_hotplug_scripts;
+
     if (!nic->mtu)
         nic->mtu = 1492;
     if (!nic->model) {
@@ -2503,6 +2505,18 @@ int libxl__device_nic_setdefault(libxl__gc *gc, libxl_device_nic *nic,
                                   libxl__xen_script_dir_path()) < 0 )
         return ERROR_FAIL;
 
+    run_hotplug_scripts = libxl__hotplug_settings(gc, XBT_NULL);
+    if (run_hotplug_scripts < 0) {
+        LOG(ERROR, "unable to get current hotplug scripts execution setting");
+        return run_hotplug_scripts;
+    }
+    if (nic->backend_domid != LIBXL_TOOLSTACK_DOMID && run_hotplug_scripts) {
+        LOG(ERROR, "cannot use a backend domain different than %d if"
+                   "hotplug scripts are executed from libxl",
+                   LIBXL_TOOLSTACK_DOMID);
+        return ERROR_FAIL;
+    }
+
     switch (libxl__domain_type(gc, domid)) {
     case LIBXL_DOMAIN_TYPE_HVM:
         if (!nic->nictype)
-- 
1.7.7.5 (Apple Git-26)


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

From xen-devel-bounces@lists.xen.org Tue Sep 04 15:18:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Sep 2012 15:18: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 1T8utK-0003X1-JD; Tue, 04 Sep 2012 15:18:14 +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 1T8utJ-0003Wj-8D
	for xen-devel@lists.xen.org; Tue, 04 Sep 2012 15:18:13 +0000
Received: from [85.158.143.35:61845] by server-1.bemta-4.messagelabs.com id
	34/8A-12504-4BB16405; Tue, 04 Sep 2012 15:18:12 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1346771891!14830813!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTE3MTg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22130 invoked from network); 4 Sep 2012 15:18:12 -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;
	4 Sep 2012 15:18:12 -0000
X-IronPort-AV: E=Sophos;i="4.80,367,1344211200"; d="scan'208";a="14339466"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Sep 2012 15:17:10 +0000
Received: from Roger-2.local.net (10.31.3.231) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Tue, 4 Sep 2012
	16:17:10 +0100
From: Roger Pau Monne <roger.pau@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Tue, 4 Sep 2012 17:16:51 +0200
Message-ID: <1346771812-98690-1-git-send-email-roger.pau@citrix.com>
X-Mailer: git-send-email 1.7.7.5 (Apple Git-26)
MIME-Version: 1.0
Cc: Roger Pau Monne <roger.pau@citrix.com>
Subject: [Xen-devel] [PATCH v2 1/2] libxl: fix usage of backend parameter
	and run_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

vif interfaces allows the user to specify the domain that should run
the backend (also known as driver domain) using the 'backend'
parameter. This is not compatible with run_hotplug_scripts=1, since
libxl can only run the hotplug scripts from the Domain 0.

Signed-off-by: Roger Pau Monne <roger.pau@citrix.com>
---
Changes since v1:

 * Remove references to xl.conf, since it's a layering violation.

 * Move the docs update to next patch (that includes xl changes).
---
 tools/libxl/libxl.c |   14 ++++++++++++++
 1 files changed, 14 insertions(+), 0 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 8ea3478..47b1fb9 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -2474,6 +2474,8 @@ out:
 int libxl__device_nic_setdefault(libxl__gc *gc, libxl_device_nic *nic,
                                  uint32_t domid)
 {
+    int run_hotplug_scripts;
+
     if (!nic->mtu)
         nic->mtu = 1492;
     if (!nic->model) {
@@ -2503,6 +2505,18 @@ int libxl__device_nic_setdefault(libxl__gc *gc, libxl_device_nic *nic,
                                   libxl__xen_script_dir_path()) < 0 )
         return ERROR_FAIL;
 
+    run_hotplug_scripts = libxl__hotplug_settings(gc, XBT_NULL);
+    if (run_hotplug_scripts < 0) {
+        LOG(ERROR, "unable to get current hotplug scripts execution setting");
+        return run_hotplug_scripts;
+    }
+    if (nic->backend_domid != LIBXL_TOOLSTACK_DOMID && run_hotplug_scripts) {
+        LOG(ERROR, "cannot use a backend domain different than %d if"
+                   "hotplug scripts are executed from libxl",
+                   LIBXL_TOOLSTACK_DOMID);
+        return ERROR_FAIL;
+    }
+
     switch (libxl__domain_type(gc, domid)) {
     case LIBXL_DOMAIN_TYPE_HVM:
         if (!nic->nictype)
-- 
1.7.7.5 (Apple Git-26)


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

From xen-devel-bounces@lists.xen.org Tue Sep 04 15:18:27 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Sep 2012 15:18:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T8utK-0003Wu-7v; Tue, 04 Sep 2012 15:18:14 +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 1T8utJ-0003Wi-54
	for xen-devel@lists.xen.org; Tue, 04 Sep 2012 15:18:13 +0000
Received: from [85.158.143.35:61840] by server-3.bemta-4.messagelabs.com id
	B5/4A-08232-4BB16405; Tue, 04 Sep 2012 15:18:12 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1346771891!14830813!2
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTE3MTg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22140 invoked from network); 4 Sep 2012 15:18:12 -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;
	4 Sep 2012 15:18:12 -0000
X-IronPort-AV: E=Sophos;i="4.80,367,1344211200"; d="scan'208";a="14339468"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Sep 2012 15:17:12 +0000
Received: from Roger-2.local.net (10.31.3.231) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Tue, 4 Sep 2012
	16:17:11 +0100
From: Roger Pau Monne <roger.pau@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Tue, 4 Sep 2012 17:16:52 +0200
Message-ID: <1346771812-98690-2-git-send-email-roger.pau@citrix.com>
X-Mailer: git-send-email 1.7.7.5 (Apple Git-26)
In-Reply-To: <1346771812-98690-1-git-send-email-roger.pau@citrix.com>
References: <1346771812-98690-1-git-send-email-roger.pau@citrix.com>
MIME-Version: 1.0
Cc: Roger Pau Monne <roger.pau@citrix.com>
Subject: [Xen-devel] [PATCH v2 2/2] xl: error if vif backend!=0 is used with
	run_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

Print an error and exit if backend!=0 is used in conjunction with
run_hotplug_scripts. Currently libxl can only execute hotplug scripts
from the toolstack domain (the same domain xl is running from).

Added a description and workaround of this issue on
xl-network-configuration.

Signed-off-by: Roger Pau Monne <roger.pau@citrix.com>
---
 docs/misc/xl-network-configuration.markdown |    6 ++++--
 tools/libxl/xl_cmdimpl.c                    |    7 +++++++
 2 files changed, 11 insertions(+), 2 deletions(-)

diff --git a/docs/misc/xl-network-configuration.markdown b/docs/misc/xl-network-configuration.markdown
index 650926c..5e2f049 100644
--- a/docs/misc/xl-network-configuration.markdown
+++ b/docs/misc/xl-network-configuration.markdown
@@ -122,8 +122,10 @@ specified IP address to be used by the guest (blocking all others).
 ### backend
 
 Specifies the backend domain which this device should attach to. This
-defaults to domain 0. Specifying another domain requires setting up a
-driver domain which is outside the scope of this document.
+defaults to domain 0. This option does not work if `run_hotplug_scripts`
+is not disabled in xl.conf (see xl.conf(5) man page for more information
+on this option). Specifying another domain requires setting up a driver
+domain which is outside the scope of this document.
 
 ### rate
 
diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index 138cd72..02b9ce8 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -1000,6 +1000,13 @@ static void parse_config_data(const char *config_source,
                         fprintf(stderr, "Specified backend domain does not exist, defaulting to Dom0\n");
                         nic->backend_domid = 0;
                     }
+                    if (nic->backend_domid != 0 && run_hotplug_scripts) {
+                        fprintf(stderr, "ERROR: the vif 'backend=' option "
+                                "cannot be used in conjunction with "
+                                "run_hotplug_scripts, please set "
+                                "run_hotplug_scripts to 0 in xl.conf\n");
+                        exit(EXIT_FAILURE);
+                    }
                 } else if (!strcmp(p, "rate")) {
                     parse_vif_rate(&config, (p2 + 1), nic);
                 } else if (!strcmp(p, "accel")) {
-- 
1.7.7.5 (Apple Git-26)


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

From xen-devel-bounces@lists.xen.org Tue Sep 04 15:18:27 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Sep 2012 15:18:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T8utK-0003Wu-7v; Tue, 04 Sep 2012 15:18:14 +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 1T8utJ-0003Wi-54
	for xen-devel@lists.xen.org; Tue, 04 Sep 2012 15:18:13 +0000
Received: from [85.158.143.35:61840] by server-3.bemta-4.messagelabs.com id
	B5/4A-08232-4BB16405; Tue, 04 Sep 2012 15:18:12 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1346771891!14830813!2
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTE3MTg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22140 invoked from network); 4 Sep 2012 15:18:12 -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;
	4 Sep 2012 15:18:12 -0000
X-IronPort-AV: E=Sophos;i="4.80,367,1344211200"; d="scan'208";a="14339468"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Sep 2012 15:17:12 +0000
Received: from Roger-2.local.net (10.31.3.231) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Tue, 4 Sep 2012
	16:17:11 +0100
From: Roger Pau Monne <roger.pau@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Tue, 4 Sep 2012 17:16:52 +0200
Message-ID: <1346771812-98690-2-git-send-email-roger.pau@citrix.com>
X-Mailer: git-send-email 1.7.7.5 (Apple Git-26)
In-Reply-To: <1346771812-98690-1-git-send-email-roger.pau@citrix.com>
References: <1346771812-98690-1-git-send-email-roger.pau@citrix.com>
MIME-Version: 1.0
Cc: Roger Pau Monne <roger.pau@citrix.com>
Subject: [Xen-devel] [PATCH v2 2/2] xl: error if vif backend!=0 is used with
	run_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

Print an error and exit if backend!=0 is used in conjunction with
run_hotplug_scripts. Currently libxl can only execute hotplug scripts
from the toolstack domain (the same domain xl is running from).

Added a description and workaround of this issue on
xl-network-configuration.

Signed-off-by: Roger Pau Monne <roger.pau@citrix.com>
---
 docs/misc/xl-network-configuration.markdown |    6 ++++--
 tools/libxl/xl_cmdimpl.c                    |    7 +++++++
 2 files changed, 11 insertions(+), 2 deletions(-)

diff --git a/docs/misc/xl-network-configuration.markdown b/docs/misc/xl-network-configuration.markdown
index 650926c..5e2f049 100644
--- a/docs/misc/xl-network-configuration.markdown
+++ b/docs/misc/xl-network-configuration.markdown
@@ -122,8 +122,10 @@ specified IP address to be used by the guest (blocking all others).
 ### backend
 
 Specifies the backend domain which this device should attach to. This
-defaults to domain 0. Specifying another domain requires setting up a
-driver domain which is outside the scope of this document.
+defaults to domain 0. This option does not work if `run_hotplug_scripts`
+is not disabled in xl.conf (see xl.conf(5) man page for more information
+on this option). Specifying another domain requires setting up a driver
+domain which is outside the scope of this document.
 
 ### rate
 
diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index 138cd72..02b9ce8 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -1000,6 +1000,13 @@ static void parse_config_data(const char *config_source,
                         fprintf(stderr, "Specified backend domain does not exist, defaulting to Dom0\n");
                         nic->backend_domid = 0;
                     }
+                    if (nic->backend_domid != 0 && run_hotplug_scripts) {
+                        fprintf(stderr, "ERROR: the vif 'backend=' option "
+                                "cannot be used in conjunction with "
+                                "run_hotplug_scripts, please set "
+                                "run_hotplug_scripts to 0 in xl.conf\n");
+                        exit(EXIT_FAILURE);
+                    }
                 } else if (!strcmp(p, "rate")) {
                     parse_vif_rate(&config, (p2 + 1), nic);
                 } else if (!strcmp(p, "accel")) {
-- 
1.7.7.5 (Apple Git-26)


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

From xen-devel-bounces@lists.xen.org Tue Sep 04 15:29:37 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Sep 2012 15:29:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T8v42-0003qQ-QI; Tue, 04 Sep 2012 15:29:18 +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 1T8v41-0003qL-Cq
	for xen-devel@lists.xen.org; Tue, 04 Sep 2012 15:29:17 +0000
Received: from [85.158.143.35:20007] by server-3.bemta-4.messagelabs.com id
	D0/6F-08232-C4E16405; Tue, 04 Sep 2012 15:29:16 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1346772556!13342682!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTE3MTg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12996 invoked from network); 4 Sep 2012 15:29:16 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Sep 2012 15:29:16 -0000
X-IronPort-AV: E=Sophos;i="4.80,367,1344211200"; d="scan'208";a="14339770"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Sep 2012 15:29:16 +0000
Received: from Roger-2.local.net (10.31.3.231) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Tue, 4 Sep 2012
	16:29:15 +0100
From: Roger Pau Monne <roger.pau@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Tue, 4 Sep 2012 17:29:06 +0200
Message-ID: <1346772546-98864-1-git-send-email-roger.pau@citrix.com>
X-Mailer: git-send-email 1.7.7.5 (Apple Git-26)
MIME-Version: 1.0
Cc: Roger Pau Monne <roger.pau@citrix.com>
Subject: [Xen-devel] [PATCH] libxl: fix error message in
	device_backend_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

device_backend_callback error path always says "unable to disconnect",
but this can also happen during the connection of a device. Fix the
error message using the information in aodev->action.

Signed-off-by: Roger Pau Monne <roger.pau@citrix.com>
---
 tools/libxl/libxl_device.c |    3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/tools/libxl/libxl_device.c b/tools/libxl/libxl_device.c
index 8e8410e..c3283f1 100644
--- a/tools/libxl/libxl_device.c
+++ b/tools/libxl/libxl_device.c
@@ -854,7 +854,8 @@ static void device_backend_callback(libxl__egc *egc, libxl__ev_devstate *ds,
     }
 
     if (rc) {
-        LOG(ERROR, "unable to disconnect device with path %s",
+        LOG(ERROR, "unable to %s device with path %s",
+                   aodev->action == DEVICE_CONNECT ? "connect" : "disconnect",
                    libxl__device_backend_path(gc, aodev->dev));
         goto out;
     }
-- 
1.7.7.5 (Apple Git-26)


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

From xen-devel-bounces@lists.xen.org Tue Sep 04 15:29:37 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Sep 2012 15:29:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T8v42-0003qQ-QI; Tue, 04 Sep 2012 15:29:18 +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 1T8v41-0003qL-Cq
	for xen-devel@lists.xen.org; Tue, 04 Sep 2012 15:29:17 +0000
Received: from [85.158.143.35:20007] by server-3.bemta-4.messagelabs.com id
	D0/6F-08232-C4E16405; Tue, 04 Sep 2012 15:29:16 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1346772556!13342682!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTE3MTg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12996 invoked from network); 4 Sep 2012 15:29:16 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Sep 2012 15:29:16 -0000
X-IronPort-AV: E=Sophos;i="4.80,367,1344211200"; d="scan'208";a="14339770"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Sep 2012 15:29:16 +0000
Received: from Roger-2.local.net (10.31.3.231) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Tue, 4 Sep 2012
	16:29:15 +0100
From: Roger Pau Monne <roger.pau@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Tue, 4 Sep 2012 17:29:06 +0200
Message-ID: <1346772546-98864-1-git-send-email-roger.pau@citrix.com>
X-Mailer: git-send-email 1.7.7.5 (Apple Git-26)
MIME-Version: 1.0
Cc: Roger Pau Monne <roger.pau@citrix.com>
Subject: [Xen-devel] [PATCH] libxl: fix error message in
	device_backend_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

device_backend_callback error path always says "unable to disconnect",
but this can also happen during the connection of a device. Fix the
error message using the information in aodev->action.

Signed-off-by: Roger Pau Monne <roger.pau@citrix.com>
---
 tools/libxl/libxl_device.c |    3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/tools/libxl/libxl_device.c b/tools/libxl/libxl_device.c
index 8e8410e..c3283f1 100644
--- a/tools/libxl/libxl_device.c
+++ b/tools/libxl/libxl_device.c
@@ -854,7 +854,8 @@ static void device_backend_callback(libxl__egc *egc, libxl__ev_devstate *ds,
     }
 
     if (rc) {
-        LOG(ERROR, "unable to disconnect device with path %s",
+        LOG(ERROR, "unable to %s device with path %s",
+                   aodev->action == DEVICE_CONNECT ? "connect" : "disconnect",
                    libxl__device_backend_path(gc, aodev->dev));
         goto out;
     }
-- 
1.7.7.5 (Apple Git-26)


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

From xen-devel-bounces@lists.xen.org Tue Sep 04 15:32:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Sep 2012 15: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 1T8v7J-0003x5-Ed; Tue, 04 Sep 2012 15:32:41 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jmarcet@gmail.com>) id 1T8v7I-0003wy-Ik
	for xen-devel@lists.xen.org; Tue, 04 Sep 2012 15:32:40 +0000
Received: from [85.158.143.35:45590] by server-3.bemta-4.messagelabs.com id
	FA/85-08232-71F16405; Tue, 04 Sep 2012 15:32:39 +0000
X-Env-Sender: jmarcet@gmail.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1346772730!11108045!1
X-Originating-IP: [209.85.210.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26600 invoked from network); 4 Sep 2012 15:32:15 -0000
Received: from mail-iy0-f173.google.com (HELO mail-iy0-f173.google.com)
	(209.85.210.173)
	by server-10.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Sep 2012 15:32:15 -0000
Received: by iakx26 with SMTP id x26so11428592iak.32
	for <xen-devel@lists.xen.org>; Tue, 04 Sep 2012 08:32:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to
	:content-type; bh=nVkLl6CoeB39KWpfMCuojb6a0q97Zox52f9WsooJgCs=;
	b=OPklJYypMHVv4n8bUwLqpe8NjTYjnnTUzyj0EA1vHYL/UBC5cfVotkN0RlQjQejH9W
	qxWPOWwdz8aiU4Yp3YxXS9ZJXbEnENO76NtXmBi9rq4zLYYULnvS95KdV/KQ37Bv7zrw
	DJvZiAOA02Va0+Ihpv/pEF+Y+06GArOdDXZ2zQCuK5dmJnAs1YnEHG0sp2hagpCz5ghK
	R1mES1v6zEtKEln6lYjjBLEm9lRJ6gYBPFXuAWzjj3oXamOlUhWkffiBrO2U+3XgEJYI
	0JRR87q5LE/FJ4Kd1dcAMT4yfBL/kXzHh4/1UOi3YXy9CkT1XHUA7dhi870ykNfLwx7i
	4MzQ==
Received: by 10.60.25.226 with SMTP id f2mr15979364oeg.53.1346772730168; Tue,
	04 Sep 2012 08:32:10 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.60.12.164 with HTTP; Tue, 4 Sep 2012 08:31:50 -0700 (PDT)
In-Reply-To: <CAOvdn6UzdzO_sM6f9coN2udQ6eUC5=Sty-NgC7+yf3XMawF-0A@mail.gmail.com>
References: <CAOvdn6WwgBD-2yf1uu3m9-16=Tb5KUrybXf2KibtnxKbP7YtwA@mail.gmail.com>
	<CAOvdn6UBW-yTOMd3YSf5M9JiHLRivyaKL-qzcKG8epszqaKmGg@mail.gmail.com>
	<20120807163320.GC15053@phenom.dumpdata.com>
	<CAOvdn6XcRGKtJxGwJO8J+ZBJr89wfTLc1woW5rhtMM540H9h1w@mail.gmail.com>
	<CAOvdn6XUoSeGoo7X=AJ1kpDxZB9HZEv+TJ4v-=FHcyR4=CHK-w@mail.gmail.com>
	<502240F302000078000937A6@nat28.tlf.novell.com>
	<CAOvdn6WN3kxC8Bb9g6MpfLULu47EGSGCtajPc-SFeJ-8VSUQDQ@mail.gmail.com>
	<CAOvdn6Xk1inm1hU55i0phU2qvSWyJLNoyDdn43biBAY2OewPtw@mail.gmail.com>
	<5023F5400200007800093F4E@nat28.tlf.novell.com>
	<CAOvdn6U-f3C4U8xVPvDyRFkFFLkbfiCXg_n+9zgA9V5u+q5jfw@mail.gmail.com>
	<5023F8B80200007800093F8C@nat28.tlf.novell.com>
	<CAOvdn6XKHfete_+=Hkvt20G7_cJ-4i8+9j9YD30OxzQ16Ru-+g@mail.gmail.com>
	<5024CB720200007800094124@nat28.tlf.novell.com>
	<CAOvdn6VVJdhWVYa-gNVt3euE4AbGi1TijUCUd1wGzv0SCWEUYA@mail.gmail.com>
	<CAAnFQG-u1VUDgn11ZW0=UaYC4MvUtxxq8ZjjUOrNpXTSUWP41Q@mail.gmail.com>
	<CAOvdn6VuD_5Mhd9wvOskfZWfCBjr2nT5LppDxyY5S-5LhGhSvA@mail.gmail.com>
	<CAAnFQG_hMNvwM9Z3XPGR590=Gifos-kOftqjLFUX4YFW6tTTgg@mail.gmail.com>
	<CAOvdn6UzdzO_sM6f9coN2udQ6eUC5=Sty-NgC7+yf3XMawF-0A@mail.gmail.com>
From: Javier Marcet <jmarcet@gmail.com>
Date: Tue, 4 Sep 2012 17:31:50 +0200
Message-ID: <CAAnFQG9tAwNkjfJ=bOG2Z_wV3HVeSM71fdzpVHaurwrKD_-HXA@mail.gmail.com>
To: Ben Guthro <ben@guthro.net>,
	Xen Devel Mailing list <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen4.2 S3 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 Tue, Sep 4, 2012 at 12:33 PM, Ben Guthro <ben@guthro.net> wrote:

> This is getting reasonably in depth to be off-list.
>
> You really should CC xen-devel for these kinds of things.

> <snip>

>> Damn it. It is a 3.3 tree and I need drivers introduced in 3.4 and I
>> also use bcache
>> which right now has a 3.2 stable version, a 3.5 not so stable and the
>> devel branch.

> Take the top 3 commits by Konrad & apply them as a patch. It should be
> sufficient....but you'll still run into issues with S3 on Xen, related
> to MSI delivery...if it resumes at all. There are clearly still
> hypervisor issues - so you seem to be jumping to some conclusions here
> with workarounds that I'm not sure are going to get you anywhere.

I've tried the top two commits from Konrad's acpi-s3.v10 branch merged on
top of kernel 3.5.3. The third commit was already merged.

I've tried it from work and I believe it suspends fine, but there is
some problem
during resume since the machine responded to a ping for a second and then
rebooted.

The only error I have on the logs is:

(XEN) memory.c:131:d0 Could not allocate order=18 extent: id=5
memflags=0 (0 of 1)
(XEN) sh error: sh_remove_all_mappings(): can't find all mappings of
mfn 270d05: c=c000000000000002 t=7400000000000001

I don't know whether that's enough to make resume from S3 fail or it's
something else.
When I'm at home I'll see if I can dig further.


-- 
Javier Marcet <jmarcet@gmail.com>

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

From xen-devel-bounces@lists.xen.org Tue Sep 04 15:32:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Sep 2012 15: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 1T8v7J-0003x5-Ed; Tue, 04 Sep 2012 15:32:41 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jmarcet@gmail.com>) id 1T8v7I-0003wy-Ik
	for xen-devel@lists.xen.org; Tue, 04 Sep 2012 15:32:40 +0000
Received: from [85.158.143.35:45590] by server-3.bemta-4.messagelabs.com id
	FA/85-08232-71F16405; Tue, 04 Sep 2012 15:32:39 +0000
X-Env-Sender: jmarcet@gmail.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1346772730!11108045!1
X-Originating-IP: [209.85.210.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26600 invoked from network); 4 Sep 2012 15:32:15 -0000
Received: from mail-iy0-f173.google.com (HELO mail-iy0-f173.google.com)
	(209.85.210.173)
	by server-10.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Sep 2012 15:32:15 -0000
Received: by iakx26 with SMTP id x26so11428592iak.32
	for <xen-devel@lists.xen.org>; Tue, 04 Sep 2012 08:32:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to
	:content-type; bh=nVkLl6CoeB39KWpfMCuojb6a0q97Zox52f9WsooJgCs=;
	b=OPklJYypMHVv4n8bUwLqpe8NjTYjnnTUzyj0EA1vHYL/UBC5cfVotkN0RlQjQejH9W
	qxWPOWwdz8aiU4Yp3YxXS9ZJXbEnENO76NtXmBi9rq4zLYYULnvS95KdV/KQ37Bv7zrw
	DJvZiAOA02Va0+Ihpv/pEF+Y+06GArOdDXZ2zQCuK5dmJnAs1YnEHG0sp2hagpCz5ghK
	R1mES1v6zEtKEln6lYjjBLEm9lRJ6gYBPFXuAWzjj3oXamOlUhWkffiBrO2U+3XgEJYI
	0JRR87q5LE/FJ4Kd1dcAMT4yfBL/kXzHh4/1UOi3YXy9CkT1XHUA7dhi870ykNfLwx7i
	4MzQ==
Received: by 10.60.25.226 with SMTP id f2mr15979364oeg.53.1346772730168; Tue,
	04 Sep 2012 08:32:10 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.60.12.164 with HTTP; Tue, 4 Sep 2012 08:31:50 -0700 (PDT)
In-Reply-To: <CAOvdn6UzdzO_sM6f9coN2udQ6eUC5=Sty-NgC7+yf3XMawF-0A@mail.gmail.com>
References: <CAOvdn6WwgBD-2yf1uu3m9-16=Tb5KUrybXf2KibtnxKbP7YtwA@mail.gmail.com>
	<CAOvdn6UBW-yTOMd3YSf5M9JiHLRivyaKL-qzcKG8epszqaKmGg@mail.gmail.com>
	<20120807163320.GC15053@phenom.dumpdata.com>
	<CAOvdn6XcRGKtJxGwJO8J+ZBJr89wfTLc1woW5rhtMM540H9h1w@mail.gmail.com>
	<CAOvdn6XUoSeGoo7X=AJ1kpDxZB9HZEv+TJ4v-=FHcyR4=CHK-w@mail.gmail.com>
	<502240F302000078000937A6@nat28.tlf.novell.com>
	<CAOvdn6WN3kxC8Bb9g6MpfLULu47EGSGCtajPc-SFeJ-8VSUQDQ@mail.gmail.com>
	<CAOvdn6Xk1inm1hU55i0phU2qvSWyJLNoyDdn43biBAY2OewPtw@mail.gmail.com>
	<5023F5400200007800093F4E@nat28.tlf.novell.com>
	<CAOvdn6U-f3C4U8xVPvDyRFkFFLkbfiCXg_n+9zgA9V5u+q5jfw@mail.gmail.com>
	<5023F8B80200007800093F8C@nat28.tlf.novell.com>
	<CAOvdn6XKHfete_+=Hkvt20G7_cJ-4i8+9j9YD30OxzQ16Ru-+g@mail.gmail.com>
	<5024CB720200007800094124@nat28.tlf.novell.com>
	<CAOvdn6VVJdhWVYa-gNVt3euE4AbGi1TijUCUd1wGzv0SCWEUYA@mail.gmail.com>
	<CAAnFQG-u1VUDgn11ZW0=UaYC4MvUtxxq8ZjjUOrNpXTSUWP41Q@mail.gmail.com>
	<CAOvdn6VuD_5Mhd9wvOskfZWfCBjr2nT5LppDxyY5S-5LhGhSvA@mail.gmail.com>
	<CAAnFQG_hMNvwM9Z3XPGR590=Gifos-kOftqjLFUX4YFW6tTTgg@mail.gmail.com>
	<CAOvdn6UzdzO_sM6f9coN2udQ6eUC5=Sty-NgC7+yf3XMawF-0A@mail.gmail.com>
From: Javier Marcet <jmarcet@gmail.com>
Date: Tue, 4 Sep 2012 17:31:50 +0200
Message-ID: <CAAnFQG9tAwNkjfJ=bOG2Z_wV3HVeSM71fdzpVHaurwrKD_-HXA@mail.gmail.com>
To: Ben Guthro <ben@guthro.net>,
	Xen Devel Mailing list <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen4.2 S3 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 Tue, Sep 4, 2012 at 12:33 PM, Ben Guthro <ben@guthro.net> wrote:

> This is getting reasonably in depth to be off-list.
>
> You really should CC xen-devel for these kinds of things.

> <snip>

>> Damn it. It is a 3.3 tree and I need drivers introduced in 3.4 and I
>> also use bcache
>> which right now has a 3.2 stable version, a 3.5 not so stable and the
>> devel branch.

> Take the top 3 commits by Konrad & apply them as a patch. It should be
> sufficient....but you'll still run into issues with S3 on Xen, related
> to MSI delivery...if it resumes at all. There are clearly still
> hypervisor issues - so you seem to be jumping to some conclusions here
> with workarounds that I'm not sure are going to get you anywhere.

I've tried the top two commits from Konrad's acpi-s3.v10 branch merged on
top of kernel 3.5.3. The third commit was already merged.

I've tried it from work and I believe it suspends fine, but there is
some problem
during resume since the machine responded to a ping for a second and then
rebooted.

The only error I have on the logs is:

(XEN) memory.c:131:d0 Could not allocate order=18 extent: id=5
memflags=0 (0 of 1)
(XEN) sh error: sh_remove_all_mappings(): can't find all mappings of
mfn 270d05: c=c000000000000002 t=7400000000000001

I don't know whether that's enough to make resume from S3 fail or it's
something else.
When I'm at home I'll see if I can dig further.


-- 
Javier Marcet <jmarcet@gmail.com>

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

From xen-devel-bounces@lists.xen.org Tue Sep 04 16:13:56 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Sep 2012 16:13:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T8vks-0004fo-32; Tue, 04 Sep 2012 16:13: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 1T8vkp-0004fj-DX
	for xen-devel@lists.xen.org; Tue, 04 Sep 2012 16:13:31 +0000
Received: from [85.158.143.99:18821] by server-2.bemta-4.messagelabs.com id
	2D/36-21239-9A826405; Tue, 04 Sep 2012 16:13:29 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1346775208!28521464!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTE3MTg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4415 invoked from network); 4 Sep 2012 16:13:28 -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;
	4 Sep 2012 16:13:28 -0000
X-IronPort-AV: E=Sophos;i="4.80,367,1344211200"; d="scan'208";a="14340726"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Sep 2012 16:12: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.279.1; Tue, 4 Sep 2012
	17:12:49 +0100
Message-ID: <1346775168.6712.60.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: <valgrind-developers@lists.sourceforge.net>, xen-devel
	<xen-devel@lists.xen.org>
Date: Tue, 4 Sep 2012 17:12:48 +0100
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Subject: [Xen-devel] [PATCH] valgrind: Support for ioctls used by Xen
 toolstack processes.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 CC as I'm not subscribed to valgrind-developers.

Under Xen the toolstack is responsible for managing the domains in
the system, e.g. creating, destroying, and otherwise manipulating
them.

To do this it uses a number of ioctls on the /proc/xen/privcmd
device. Most of these (the MMAPBATCH ones) simply set things up such
that a subsequenct mmap call will map the desired guest memory. Since
valgrind has no way of knowing what the memory contains we assume
that it is all initialised (to do otherwise would require valgrind to
be observing the complete state of the system and not just the given
process).

The most interesting ioctl is XEN_IOCTL_PRIVCMD_HYPERCALL which
allows the toolstack to make arbitrary hypercalls. Although the
mechanism here is specific to the OS of the guest running the
toolstack the hypercalls themselves are defined solely by the
hypervisor. Therefore I have split support for this ioctl into a part
in syswrap-linux.c which handles the ioctl itself and passes things
onto a new syswrap-xen.c which handles the specifics of the
hypercalls themselves. Porting this to another OS should just be a
matter of wiring up syswrap-$OS.c to decode the ioctl and call into
syswrap-xen.c. In the future we may want to split this into
syswrap-$ARCH-xen.c but for now this is x86 only.

The hypercall coverage here is pretty small but is enough to get
reasonable(-ish) results out of the xl toolstack when listing,
creating and destroying domains.

One issue is that the hypercalls which are exlusively used by the
toolstacks (as opposed to those used by guest operating systems) are
not considered a stable ABI, since the hypervisor and the lowlevel
tools are considered a matched pair. This covers the sysctl and
domctl hypercalls which are a fairly large chunk of the support
here. I'm not sure how to solve this without invoking a massive
amount of duplication. Right now this targets the Xen unstable
interface (which will shortly be released as Xen 4.2), perhaps I can
get away with deferring this problem until the first change ;-).

On the plus side the vast majority of hypercalls are not of interest
to the toolstack (they are used by guests) so we can get away without
implementing them.

There are some other wrinkles here I've not been sure how to solve:

Firstly, di_notify_mmap tries to read from the magic proc device:
     --20208-- WARNING: Serious error when reading debug info
     --20208-- When reading debug info from /proc/xen/privcmd:
     --20208-- can't read file to inspect ELF header

I've hacked around this with an explicit check for /proc/xen.
Hopefully someone can point to the right solution.

Secondly, a hypercall only reads as many words from the ioctl arg
struct as there are actual arguments to that hypercall and the
toolstack only initialises the arguments which are used. However
there is no space in the DEFN_PRE_TEMPLATE prototype to allow this to
be communicated from syswrap-xen.c back to syswrap-linux.c. Since a
hypercall can have at most 5 arguments I have hackily stolen ARG8 for
this purpose.
---
 configure.in                           |   19 +
 coregrind/Makefile.am                  |    8 +-
 coregrind/m_debuginfo/debuginfo.c      |    9 +
 coregrind/m_syswrap/priv_syswrap-xen.h |   10 +
 coregrind/m_syswrap/syswrap-linux.c    |  107 ++++-
 coregrind/m_syswrap/syswrap-xen.c      | 1023 ++++++++++++++++++++++++++++++++
 include/Makefile.am                    |    3 +-
 include/pub_tool_vki.h                 |    1 +
 include/vki/vki-linux.h                |   44 ++
 include/vki/vki-xen.h                  |    8 +
 10 files changed, 1229 insertions(+), 3 deletions(-)
 create mode 100644 coregrind/m_syswrap/priv_syswrap-xen.h
 create mode 100644 coregrind/m_syswrap/syswrap-xen.c
 create mode 100644 include/vki/vki-xen.h

diff --git a/configure.in b/configure.in
index b385aed..d94644c 100644
--- a/configure.in
+++ b/configure.in
@@ -2012,6 +2012,25 @@ AC_ARG_WITH(mpicc,
 )
 AC_SUBST(MPI_CC)
 
+#----------------------------------------------------------------------------
+# Xen checks
+#----------------------------------------------------------------------------
+AC_ARG_ENABLE(xen, 
+      [  --enable-xen            Enable support for Xen hypervisor],
+      [vg_cv_xen=$enableval],
+      [vg_cv_xen=no])
+
+AC_ARG_WITH(xen,
+   [  --with-xen=             Specify location of Xen headers],
+   XEN_CFLAGS=-I$withval
+)
+AC_SUBST(XEN_CFLAGS)
+
+AM_CONDITIONAL([ENABLE_XEN], [test x$vg_cv_xen = xyes])
+if test x"$vg_cv_xen" = xyes; then
+    AC_DEFINE([ENABLE_XEN], 1, [configured to support Xen])
+fi
+
 ## We AM_COND_IF here instead of automake "if" in mpi/Makefile.am so that we can
 ## use these values in the check for a functioning mpicc.
 ##
diff --git a/coregrind/Makefile.am b/coregrind/Makefile.am
index 01015a7..58a7dce 100644
--- a/coregrind/Makefile.am
+++ b/coregrind/Makefile.am
@@ -224,6 +224,7 @@ noinst_HEADERS = \
 	m_syswrap/priv_syswrap-linux-variants.h \
 	m_syswrap/priv_syswrap-darwin.h \
 	m_syswrap/priv_syswrap-main.h \
+	m_syswrap/priv_syswrap-xen.h \
 	m_ume/priv_ume.h
 
 #----------------------------------------------------------------------------
@@ -371,6 +372,11 @@ COREGRIND_SOURCES_COMMON = \
 	m_ume/main.c \
 	m_ume/script.c
 
+if ENABLE_XEN
+COREGRIND_SOURCES_COMMON += m_syswrap/syswrap-xen.c
+CFLAGS += @XEN_CFLAGS@
+endif
+
 libcoregrind_@VGCONF_ARCH_PRI@_@VGCONF_OS@_a_SOURCES = \
     $(COREGRIND_SOURCES_COMMON)
 nodist_libcoregrind_@VGCONF_ARCH_PRI@_@VGCONF_OS@_a_SOURCES = \
@@ -378,7 +384,7 @@ nodist_libcoregrind_@VGCONF_ARCH_PRI@_@VGCONF_OS@_a_SOURCES = \
 libcoregrind_@VGCONF_ARCH_PRI@_@VGCONF_OS@_a_CPPFLAGS = \
     $(AM_CPPFLAGS_@VGCONF_PLATFORM_PRI_CAPS@)
 libcoregrind_@VGCONF_ARCH_PRI@_@VGCONF_OS@_a_CFLAGS = \
-    $(AM_CFLAGS_@VGCONF_PLATFORM_PRI_CAPS@)
+    $(AM_CFLAGS_@VGCONF_PLATFORM_PRI_CAPS@) @XEN_CFLAGS@
 libcoregrind_@VGCONF_ARCH_PRI@_@VGCONF_OS@_a_CCASFLAGS = \
     $(AM_CCASFLAGS_@VGCONF_PLATFORM_PRI_CAPS@)
 if ENABLE_LINUX_TICKET_LOCK_PRIMARY
diff --git a/coregrind/m_debuginfo/debuginfo.c b/coregrind/m_debuginfo/debuginfo.c
index 218547b..b634ce0 100644
--- a/coregrind/m_debuginfo/debuginfo.c
+++ b/coregrind/m_debuginfo/debuginfo.c
@@ -729,6 +729,15 @@ ULong VG_(di_notify_mmap)( Addr a, Bool allow_SkFileV, Int use_fd )
    if (!filename)
       return 0;
 
+   /*
+    * Cannot read from these magic files:
+    * --20208-- WARNING: Serious error when reading debug info
+    * --20208-- When reading debug info from /proc/xen/privcmd:
+    * --20208-- can't read file to inspect ELF header
+    */
+   if (VG_(strncmp)(filename, "/proc/xen/", 10) == 0)
+      return 0;
+
    if (debug)
       VG_(printf)("di_notify_mmap-2: %s\n", filename);
 
diff --git a/coregrind/m_syswrap/priv_syswrap-xen.h b/coregrind/m_syswrap/priv_syswrap-xen.h
new file mode 100644
index 0000000..4dc4748
--- /dev/null
+++ b/coregrind/m_syswrap/priv_syswrap-xen.h
@@ -0,0 +1,10 @@
+#ifndef __PRIV_SYSWRAP_XEN_H
+#define __PRIV_SYSWRAP_XEN_H
+
+DECL_TEMPLATE(xen, hypercall);
+
+#endif   // __PRIV_SYSWRAP_XEN_H
+
+/*--------------------------------------------------------------------*/
+/*--- end                                                          ---*/
+/*--------------------------------------------------------------------*/
diff --git a/coregrind/m_syswrap/syswrap-linux.c b/coregrind/m_syswrap/syswrap-linux.c
index 2f1155f..22c1842 100644
--- a/coregrind/m_syswrap/syswrap-linux.c
+++ b/coregrind/m_syswrap/syswrap-linux.c
@@ -63,7 +63,7 @@
 #include "priv_types_n_macros.h"
 #include "priv_syswrap-generic.h"
 #include "priv_syswrap-linux.h"
-
+#include "priv_syswrap-xen.h"
 
 // Run a thread from beginning to end and return the thread's
 // scheduler-return-code.
@@ -5527,6 +5527,73 @@ PRE(sys_ioctl)
    case VKI_KVM_RUN:
       break;
 
+#ifdef ENABLE_XEN
+   case VKI_XEN_IOCTL_PRIVCMD_HYPERCALL: {
+      SyscallArgs harrghs;
+      struct vki_xen_privcmd_hypercall *args =
+         (struct vki_xen_privcmd_hypercall *)(ARG3);
+
+      if (!args)
+         break;
+
+      VG_(memset)(&harrghs, 0, sizeof(harrghs));
+      harrghs.sysno = args->op;
+      harrghs.arg1 = args->arg[0];
+      harrghs.arg2 = args->arg[1];
+      harrghs.arg3 = args->arg[2];
+      harrghs.arg4 = args->arg[3];
+      harrghs.arg5 = args->arg[4];
+      harrghs.arg6 = harrghs.arg7 = harrghs.arg8 = 0;
+
+      WRAPPER_PRE_NAME(xen, hypercall) (tid, layout, &harrghs, status, flags);
+
+      /* HACK. arg8 is used to return the number of hypercall
+       * arguments actually consumed! */
+      PRE_MEM_READ("hypercall", ARG3, sizeof(args->op) +
+                   ( sizeof(args->arg[0]) * harrghs.arg8 ) );
+
+      break;
+   }
+
+   case VKI_XEN_IOCTL_PRIVCMD_MMAP: {
+       struct vki_xen_privcmd_mmap *args =
+           (struct vki_xen_privcmd_mmap *)(ARG3);
+       PRE_MEM_READ("VKI_XEN_IOCTL_PRIVCMD_MMAP",
+                    (Addr)&args->num, sizeof(args->num));
+       PRE_MEM_READ("VKI_XEN_IOCTL_PRIVCMD_MMAP",
+                    (Addr)&args->dom, sizeof(args->dom));
+       PRE_MEM_READ("VKI_XEN_IOCTL_PRIVCMD_MMAP",
+                    (Addr)args->entry, sizeof(*(args->entry)) * args->num);
+      break;
+   }
+   case VKI_XEN_IOCTL_PRIVCMD_MMAPBATCH: {
+       struct vki_xen_privcmd_mmapbatch *args =
+           (struct vki_xen_privcmd_mmapbatch *)(ARG3);
+       PRE_MEM_READ("VKI_XEN_IOCTL_PRIVCMD_MMAPBATCH",
+                    (Addr)&args->num, sizeof(args->num));
+       PRE_MEM_READ("VKI_XEN_IOCTL_PRIVCMD_MMAPBATCH",
+                    (Addr)&args->dom, sizeof(args->dom));
+       PRE_MEM_READ("VKI_XEN_IOCTL_PRIVCMD_MMAPBATCH",
+                    (Addr)&args->addr, sizeof(args->addr));
+       PRE_MEM_READ("VKI_XEN_IOCTL_PRIVCMD_MMAPBATCH",
+                    (Addr)args->arr, sizeof(*(args->arr)) * args->num);
+      break;
+   }
+   case VKI_XEN_IOCTL_PRIVCMD_MMAPBATCH_V2: {
+       struct vki_xen_privcmd_mmapbatch_v2 *args =
+           (struct vki_xen_privcmd_mmapbatch_v2 *)(ARG3);
+       PRE_MEM_READ("VKI_XEN_IOCTL_PRIVCMD_MMAPBATCH_V2",
+                    (Addr)&args->num, sizeof(args->num));
+       PRE_MEM_READ("VKI_XEN_IOCTL_PRIVCMD_MMAPBATCH_V2",
+                    (Addr)&args->dom, sizeof(args->dom));
+       PRE_MEM_READ("VKI_XEN_IOCTL_PRIVCMD_MMAPBATCH_V2",
+                    (Addr)&args->addr, sizeof(args->addr));
+       PRE_MEM_READ("VKI_XEN_IOCTL_PRIVCMD_MMAPBATCH_V2",
+                    (Addr)args->arr, sizeof(*(args->arr)) * args->num);
+      break;
+   }
+#endif
+
    default:
       /* EVIOC* are variable length and return size written on success */
       switch (ARG2 & ~(_VKI_IOC_SIZEMASK << _VKI_IOC_SIZESHIFT)) {
@@ -6524,6 +6591,44 @@ POST(sys_ioctl)
    case VKI_KVM_S390_INITIAL_RESET:
       break;
 
+#ifdef ENABLE_XEN
+   case VKI_XEN_IOCTL_PRIVCMD_HYPERCALL: {
+      SyscallArgs harrghs;
+      struct vki_xen_privcmd_hypercall *args =
+         (struct vki_xen_privcmd_hypercall *)(ARG3);
+
+      if (!args)
+         break;
+
+      VG_(memset)(&harrghs, 0, sizeof(harrghs));
+      harrghs.sysno = args->op;
+      harrghs.arg1 = args->arg[0];
+      harrghs.arg2 = args->arg[1];
+      harrghs.arg3 = args->arg[2];
+      harrghs.arg4 = args->arg[3];
+      harrghs.arg5 = args->arg[4];
+      harrghs.arg6 = harrghs.arg7 = harrghs.arg8 = 0;
+
+      WRAPPER_POST_NAME(xen, hypercall) (tid, &harrghs, status);
+      break;
+   };
+
+   case VKI_XEN_IOCTL_PRIVCMD_MMAP:
+      break;
+   case VKI_XEN_IOCTL_PRIVCMD_MMAPBATCH: {
+       struct vki_xen_privcmd_mmapbatch *args =
+           (struct vki_xen_privcmd_mmapbatch *)(ARG3);
+       POST_MEM_WRITE((Addr)args->arr, sizeof(*(args->arr)) * args->num);
+      }
+      break;
+   case VKI_XEN_IOCTL_PRIVCMD_MMAPBATCH_V2: {
+       struct vki_xen_privcmd_mmapbatch_v2 *args =
+           (struct vki_xen_privcmd_mmapbatch_v2 *)(ARG3);
+       POST_MEM_WRITE((Addr)args->err, sizeof(*(args->err)) * args->num);
+      }
+      break;
+#endif
+
    default:
       /* EVIOC* are variable length and return size written on success */
       switch (ARG2 & ~(_VKI_IOC_SIZEMASK << _VKI_IOC_SIZESHIFT)) {
diff --git a/coregrind/m_syswrap/syswrap-xen.c b/coregrind/m_syswrap/syswrap-xen.c
new file mode 100644
index 0000000..00192bf
--- /dev/null
+++ b/coregrind/m_syswrap/syswrap-xen.c
@@ -0,0 +1,1023 @@
+
+/*--------------------------------------------------------------------*/
+/*--- Xen Hypercalls                                 syswrap-xen.c ---*/
+/*--------------------------------------------------------------------*/
+
+/*
+   This file is part of Valgrind, a dynamic binary instrumentation
+   framework.
+
+   Copyright (C) 2012 Citrix Systems
+      ian.campbell@citrix.com
+
+   This program is free software; you can redistribute it and/or
+   modify it under the terms of the GNU General Public License as
+   published by the Free Software Foundation; either version 2 of the
+   License, or (at your option) any later version.
+
+   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.
+
+   The GNU General Public License is contained in the file COPYING.
+*/
+
+#include "pub_core_basics.h"
+#include "pub_core_vki.h"
+#include "pub_core_vkiscnums.h"
+#include "pub_core_libcsetjmp.h"   // to keep _threadstate.h happy
+#include "pub_core_threadstate.h"
+#include "pub_core_aspacemgr.h"
+#include "pub_core_debuginfo.h"    // VG_(di_notify_*)
+#include "pub_core_transtab.h"     // VG_(discard_translations)
+#include "pub_core_xarray.h"
+#include "pub_core_clientstate.h"
+#include "pub_core_debuglog.h"
+#include "pub_core_libcbase.h"
+#include "pub_core_libcassert.h"
+#include "pub_core_libcfile.h"
+#include "pub_core_libcprint.h"
+#include "pub_core_libcproc.h"
+#include "pub_core_libcsignal.h"
+#include "pub_core_mallocfree.h"
+#include "pub_core_tooliface.h"
+#include "pub_core_options.h"
+#include "pub_core_scheduler.h"
+#include "pub_core_signals.h"
+#include "pub_core_syscall.h"
+#include "pub_core_syswrap.h"
+#include "pub_core_stacktrace.h"    // For VG_(get_and_pp_StackTrace)()
+
+#include "priv_types_n_macros.h"
+#include "priv_syswrap-generic.h"
+#include "priv_syswrap-xen.h"
+
+#include <stdint.h>
+
+#define __XEN_TOOLS__
+
+#include <xen/xen.h>
+#include <xen/sysctl.h>
+#include <xen/domctl.h>
+#include <xen/memory.h>
+#include <xen/event_channel.h>
+#include <xen/version.h>
+
+#include <xen/hvm/hvm_op.h>
+
+#define PRE(name) static DEFN_PRE_TEMPLATE(xen, name)
+#define POST(name) static DEFN_POST_TEMPLATE(xen, name)
+
+static void bad_subop ( ThreadId              tid,
+                        SyscallArgLayout*     layout,
+                        /*MOD*/SyscallArgs*   args,
+                        /*OUT*/SyscallStatus* status,
+                        /*OUT*/UWord*         flags,
+                        const char*           hypercall,
+                        UWord                 subop)
+{
+   VG_(dmsg)("WARNING: unhandled %s subop: %ld\n",
+             hypercall, subop);
+   if (VG_(clo_verbosity) > 1) {
+      VG_(get_and_pp_StackTrace)(tid, VG_(clo_backtrace_size));
+   }
+   VG_(dmsg)("You may be able to write your own handler.\n");
+   VG_(dmsg)("Read the file README_MISSING_SYSCALL_OR_IOCTL.\n");
+   VG_(dmsg)("Nevertheless we consider this a bug.  Please report\n");
+   VG_(dmsg)("it at http://valgrind.org/support/bug_reports.html &\n");
+   VG_(dmsg)("http://wiki.xen.org/wiki/Reporting_Bugs_against_Xen.\n");
+
+   SET_STATUS_Failure(VKI_ENOSYS);
+}
+
+PRE(memory_op)
+{
+   PRINT("__HYPERVISOR_memory_op ( %ld, %lx )", ARG1, ARG2);
+
+   switch (ARG1) {
+   case XENMEM_set_memory_map: {
+      xen_foreign_memory_map_t *arg =
+         (xen_foreign_memory_map_t *)(unsigned int)ARG2;
+      PRE_MEM_READ("XENMEM_set_memory_map",
+                   (Addr)&arg->domid, sizeof(arg->domid));
+      PRE_MEM_READ("XENMEM_set_memory_map",
+                   (Addr)&arg->map, sizeof(arg->map));
+      break;
+   }
+   case XENMEM_increase_reservation:
+   case XENMEM_decrease_reservation:
+   case XENMEM_populate_physmap: {
+      struct xen_memory_reservation *memory_reservation =
+         (struct xen_memory_reservation *)(unsigned int)ARG2;
+      char *which;
+
+      switch (ARG1) {
+      case XENMEM_increase_reservation:
+         which = "XENMEM_increase_reservation";
+         break;
+      case XENMEM_decrease_reservation:
+         which = "XENMEM_decrease_reservation";
+         PRE_MEM_READ(which,
+                      (Addr)memory_reservation->extent_start.p,
+                      sizeof(xen_pfn_t) * memory_reservation->nr_extents);
+      case XENMEM_populate_physmap:
+         which = "XENMEM_populate_physmap";
+         PRE_MEM_READ(which,
+                      (Addr)memory_reservation->extent_start.p,
+                      sizeof(xen_pfn_t) * memory_reservation->nr_extents);
+         break;
+      default:
+         which = "XENMEM_unknown";
+         break;
+      }
+
+      PRE_MEM_READ(which,
+                   (Addr)&memory_reservation->extent_start,
+                   sizeof(memory_reservation->extent_start));
+      PRE_MEM_READ(which,
+                   (Addr)&memory_reservation->nr_extents,
+                   sizeof(memory_reservation->nr_extents));
+      PRE_MEM_READ(which,
+                   (Addr)&memory_reservation->extent_order,
+                   sizeof(memory_reservation->extent_order));
+      PRE_MEM_READ(which,
+                   (Addr)&memory_reservation->mem_flags,
+                   sizeof(memory_reservation->mem_flags));
+      PRE_MEM_READ(which,
+                   (Addr)&memory_reservation->domid,
+                   sizeof(memory_reservation->domid));
+      break;
+   }
+
+   default:
+      bad_subop(tid, layout, arrghs, status, flags,
+                "__HYPERVISOR_memory_op", ARG1);
+      break;
+   }
+}
+
+PRE(mmuext_op)
+{
+   mmuext_op_t *ops = (void *)(unsigned int)ARG1;
+   unsigned int i, nr = ARG2;
+
+
+   for (i=0; i<nr; i++) {
+      mmuext_op_t *op = ops + i;
+      PRE_MEM_READ("__HYPERVISOR_MMUEXT_OP",
+                   (Addr)&op->cmd, sizeof(op->cmd));
+      switch(op->cmd) {
+      case MMUEXT_PIN_L1_TABLE:
+      case MMUEXT_PIN_L2_TABLE:
+      case MMUEXT_PIN_L3_TABLE:
+      case MMUEXT_PIN_L4_TABLE:
+      case MMUEXT_UNPIN_TABLE:
+      case MMUEXT_NEW_BASEPTR:
+      case MMUEXT_CLEAR_PAGE:
+      case MMUEXT_COPY_PAGE:
+      case MMUEXT_MARK_SUPER:
+      case MMUEXT_UNMARK_SUPER:
+         PRE_MEM_READ("__HYPERVISOR_MMUEXT_OP arg1.mfn",
+                      (Addr)&op->arg1.mfn,
+                      sizeof(op->arg1.mfn));
+         break;
+
+      case MMUEXT_INVLPG_LOCAL:
+      case MMUEXT_INVLPG_ALL:
+      case MMUEXT_SET_LDT:
+         PRE_MEM_READ("__HYPERVISOR_MMUEXT_OP arg1.mfn",
+                      (Addr)&op->arg1.linear_addr,
+                      sizeof(op->arg1.linear_addr));
+         break;
+
+      case MMUEXT_TLB_FLUSH_LOCAL:
+      case MMUEXT_TLB_FLUSH_MULTI:
+      case MMUEXT_INVLPG_MULTI:
+      case MMUEXT_TLB_FLUSH_ALL:
+      case MMUEXT_FLUSH_CACHE:
+      case MMUEXT_NEW_USER_BASEPTR:
+      case MMUEXT_FLUSH_CACHE_GLOBAL:
+         /* None */
+         break;
+      }
+
+      switch(op->cmd) {
+      case MMUEXT_SET_LDT:
+         PRE_MEM_READ("__HYPERVISOR_MMUEXT_OP arg2.nr_ents",
+                      (Addr)&op->arg2.nr_ents,
+                      sizeof(op->arg2.nr_ents));
+         break;
+
+      case MMUEXT_TLB_FLUSH_MULTI:
+      case MMUEXT_INVLPG_MULTI:
+         /* How many??? */
+         PRE_MEM_READ("__HYPERVISOR_MMUEXT_OP arg2.vcpumask",
+                      (Addr)&op->arg2.vcpumask,
+                      sizeof(op->arg2.vcpumask));
+         break;
+
+      case MMUEXT_COPY_PAGE:
+         PRE_MEM_READ("__HYPERVISOR_MMUEXT_OP arg2.src_mfn",
+                      (Addr)&op->arg2.src_mfn,
+                      sizeof(op->arg2.src_mfn));
+         break;
+
+      case MMUEXT_PIN_L1_TABLE:
+      case MMUEXT_PIN_L2_TABLE:
+      case MMUEXT_PIN_L3_TABLE:
+      case MMUEXT_PIN_L4_TABLE:
+      case MMUEXT_UNPIN_TABLE:
+      case MMUEXT_NEW_BASEPTR:
+      case MMUEXT_TLB_FLUSH_LOCAL:
+      case MMUEXT_INVLPG_LOCAL:
+      case MMUEXT_TLB_FLUSH_ALL:
+      case MMUEXT_INVLPG_ALL:
+      case MMUEXT_FLUSH_CACHE:
+      case MMUEXT_NEW_USER_BASEPTR:
+      case MMUEXT_CLEAR_PAGE:
+      case MMUEXT_FLUSH_CACHE_GLOBAL:
+      case MMUEXT_MARK_SUPER:
+      case MMUEXT_UNMARK_SUPER:
+         /* None */
+         break;
+      }
+   }
+}
+
+static void pre_evtchn_op(ThreadId tid,
+                          SyscallArgLayout*     layout,
+                          /*MOD*/SyscallArgs*   arrghs,
+                          /*OUT*/SyscallStatus* status,
+                          /*OUT*/UWord*         flags,
+                          __vki_u32 cmd, void *arg, int compat)
+{
+   PRINT("__HYPERVISOR_event_channel_op%s ( %d, %p )",
+         compat ? "_compat" : "", cmd, arg);
+
+   switch (cmd) {
+   case EVTCHNOP_alloc_unbound: {
+      struct evtchn_alloc_unbound *alloc_unbound = arg;
+      PRE_MEM_READ("EVTCHNOP_alloc_unbound",
+                   (Addr)&alloc_unbound->dom, sizeof(alloc_unbound->dom));
+      PRE_MEM_READ("EVTCHNOP_alloc_unbound",
+                   (Addr)&alloc_unbound->remote_dom,
+                   sizeof(alloc_unbound->remote_dom));
+      break;
+   }
+   default:
+      if ( compat )
+         bad_subop(tid, layout, arrghs, status, flags,
+                   "__HYPERVISOR_event_channel_op_compat", cmd);
+      else
+         bad_subop(tid, layout, arrghs, status, flags,
+                   "__HYPERVISOR_event_channel_op", cmd);
+      break;
+   }
+}
+
+PRE(evtchn_op)
+{
+   pre_evtchn_op(tid, layout, arrghs, status, flags,
+                 ARG1, (void *)(unsigned int)ARG2, 0);
+}
+
+PRE(evtchn_op_compat)
+{
+   struct evtchn_op *evtchn = (struct evtchn_op *)(unsigned int)ARG1;
+   PRE_MEM_READ("__HYPERVISOR_event_channel_op_compat",
+                ARG1, sizeof(*evtchn));
+
+   pre_evtchn_op(tid, layout, arrghs, status, flags,
+                 evtchn->cmd, &evtchn->u, 1);
+}
+
+PRE(xen_version)
+{
+   PRINT("__HYPERVISOR_xen_version ( %ld, %lx )", ARG1, ARG2);
+
+   switch (ARG1) {
+   case XENVER_version:
+   case XENVER_extraversion:
+   case XENVER_compile_info:
+   case XENVER_capabilities:
+   case XENVER_changeset:
+   case XENVER_platform_parameters:
+   case XENVER_get_features:
+   case XENVER_pagesize:
+   case XENVER_guest_handle:
+   case XENVER_commandline:
+      /* No inputs */
+      break;
+
+   default:
+      bad_subop(tid, layout, arrghs, status, flags,
+                "__HYPERVISOR_xen_version", ARG1);
+      break;
+   }
+}
+
+PRE(grant_table_op)
+{
+   PRINT("__HYPERVISOR_grant_table_op ( %ld, 0x%lx, %ld )", ARG1, ARG2, ARG3);
+   switch (ARG1) {
+   case GNTTABOP_setup_table: {
+      struct gnttab_setup_table *gst = (void *)(intptr_t)ARG2;
+      PRE_MEM_READ("GNTTABOP_setup_table", (Addr)&gst->dom, sizeof(gst->dom));
+      PRE_MEM_READ("GNTTABOP_setup_table",
+                   (Addr)&gst->nr_frames, sizeof(gst->nr_frames));
+      break;
+   }
+   default:
+      bad_subop(tid, layout, arrghs, status, flags,
+                "__HYPERVISOR_grant_table_op", ARG1);
+      break;
+   }
+}
+
+PRE(sysctl) {
+   struct xen_sysctl *sysctl = (struct xen_sysctl *)(unsigned int)ARG1;
+
+   PRINT("__HYPERVISOR_sysctl ( %d )", sysctl->cmd);
+
+   /*
+    * Common part of xen_sysctl:
+    *    uint32_t cmd;
+    *    uint32_t interface_version;
+    */
+   PRE_MEM_READ("__HYPERVISOR_sysctl", ARG1,
+                sizeof(uint32_t) + sizeof(uint32_t));
+
+   if (!sysctl || sysctl->interface_version != XEN_SYSCTL_INTERFACE_VERSION)
+      /* BUG ? */
+      return;
+
+#define __PRE_XEN_SYSCTL_READ(_sysctl, _union, _field)  \
+      PRE_MEM_READ("XEN_SYSCTL_" # _sysctl,             \
+                   (Addr)&sysctl->u._union._field,      \
+                   sizeof(sysctl->u._union._field))
+#define PRE_XEN_SYSCTL_READ(_sysctl, _field) \
+      __PRE_XEN_SYSCTL_READ(_sysctl, _sysctl, _field)
+
+   switch (sysctl->cmd) {
+   case XEN_SYSCTL_getdomaininfolist:
+      PRE_XEN_SYSCTL_READ(getdomaininfolist, first_domain);
+      PRE_XEN_SYSCTL_READ(getdomaininfolist, max_domains);
+      PRE_XEN_SYSCTL_READ(getdomaininfolist, buffer);
+      break;
+
+   case XEN_SYSCTL_cpupool_op:
+      PRE_XEN_SYSCTL_READ(cpupool_op, op);
+
+      switch(sysctl->u.cpupool_op.op) {
+      case XEN_SYSCTL_CPUPOOL_OP_CREATE:
+      case XEN_SYSCTL_CPUPOOL_OP_DESTROY:
+      case XEN_SYSCTL_CPUPOOL_OP_INFO:
+      case XEN_SYSCTL_CPUPOOL_OP_ADDCPU:
+      case XEN_SYSCTL_CPUPOOL_OP_RMCPU:
+      case XEN_SYSCTL_CPUPOOL_OP_MOVEDOMAIN:
+         PRE_XEN_SYSCTL_READ(cpupool_op, cpupool_id);
+      }
+
+      if (sysctl->u.cpupool_op.op == XEN_SYSCTL_CPUPOOL_OP_CREATE)
+         PRE_XEN_SYSCTL_READ(cpupool_op, sched_id);
+
+      if (sysctl->u.cpupool_op.op == XEN_SYSCTL_CPUPOOL_OP_MOVEDOMAIN)
+         PRE_XEN_SYSCTL_READ(cpupool_op, domid);
+
+      if (sysctl->u.cpupool_op.op == XEN_SYSCTL_CPUPOOL_OP_ADDCPU ||
+          sysctl->u.cpupool_op.op == XEN_SYSCTL_CPUPOOL_OP_RMCPU)
+         PRE_XEN_SYSCTL_READ(cpupool_op, cpu);
+
+      break;
+
+   case XEN_SYSCTL_physinfo:
+      /* No input params */
+      break;
+
+   case XEN_SYSCTL_topologyinfo:
+      PRE_XEN_SYSCTL_READ(topologyinfo, max_cpu_index);
+      PRE_XEN_SYSCTL_READ(topologyinfo, cpu_to_core);
+      PRE_XEN_SYSCTL_READ(topologyinfo, cpu_to_socket);
+      PRE_XEN_SYSCTL_READ(topologyinfo, cpu_to_node);
+      break;
+
+   case XEN_SYSCTL_numainfo:
+      PRE_XEN_SYSCTL_READ(numainfo, max_node_index);
+      PRE_XEN_SYSCTL_READ(numainfo, node_to_memsize);
+      PRE_XEN_SYSCTL_READ(numainfo, node_to_memfree);
+      PRE_XEN_SYSCTL_READ(numainfo, node_to_node_distance);
+      break;
+
+   default:
+      bad_subop(tid, layout, arrghs, status, flags,
+                "__HYPERVISOR_sysctl", sysctl->cmd);
+      break;
+   }
+#undef PRE_XEN_SYSCTL_READ
+#undef __PRE_XEN_SYSCTL_READ
+}
+
+PRE(domctl)
+{
+   struct xen_domctl *domctl = (struct xen_domctl *)(unsigned int)ARG1;
+
+   PRINT("__HYPERVISOR_domctl ( %d ) on dom%d", domctl->cmd, domctl->domain);
+
+   /*
+    * Common part of xen_domctl:
+    *    uint32_t cmd;
+    *    uint32_t interface_version;
+    *    domid_t  domain;
+    */
+   PRE_MEM_READ("__HYPERVISOR_domctl", ARG1,
+                sizeof(uint32_t) + sizeof(uint32_t) + sizeof(domid_t));
+
+   if (!domctl || domctl->interface_version != XEN_DOMCTL_INTERFACE_VERSION)
+      /* BUG ? */
+      return;
+
+#define __PRE_XEN_DOMCTL_READ(_domctl, _union, _field)  \
+      PRE_MEM_READ("XEN_DOMCTL_" # _domctl,             \
+                   (Addr)&domctl->u._union._field,      \
+                   sizeof(domctl->u._union._field))
+#define PRE_XEN_DOMCTL_READ(_domctl, _field) \
+      __PRE_XEN_DOMCTL_READ(_domctl, _domctl, _field)
+
+   switch (domctl->cmd) {
+   case XEN_DOMCTL_destroydomain:
+   case XEN_DOMCTL_pausedomain:
+   case XEN_DOMCTL_max_vcpus:
+   case XEN_DOMCTL_get_address_size:
+   case XEN_DOMCTL_gettscinfo:
+   case XEN_DOMCTL_getdomaininfo:
+   case XEN_DOMCTL_unpausedomain:
+      /* No input fields. */
+      break;
+
+   case XEN_DOMCTL_createdomain:
+      PRE_XEN_DOMCTL_READ(createdomain, ssidref);
+      PRE_XEN_DOMCTL_READ(createdomain, handle);
+      PRE_XEN_DOMCTL_READ(createdomain, flags);
+      break;
+
+   case XEN_DOMCTL_max_mem:
+      PRE_XEN_DOMCTL_READ(max_mem, max_memkb);
+      break;
+
+   case XEN_DOMCTL_set_address_size:
+      __PRE_XEN_DOMCTL_READ(set_address_size, address_size, size);
+      break;
+
+   case XEN_DOMCTL_settscinfo:
+      __PRE_XEN_DOMCTL_READ(settscinfo, tsc_info, info.tsc_mode);
+      __PRE_XEN_DOMCTL_READ(settscinfo, tsc_info, info.gtsc_khz);
+      __PRE_XEN_DOMCTL_READ(settscinfo, tsc_info, info.incarnation);
+      __PRE_XEN_DOMCTL_READ(settscinfo, tsc_info, info.elapsed_nsec);
+      break;
+
+   case XEN_DOMCTL_hypercall_init:
+      PRE_XEN_DOMCTL_READ(hypercall_init, gmfn);
+      break;
+
+   case XEN_DOMCTL_getvcpuinfo:
+      PRE_XEN_DOMCTL_READ(getvcpuinfo, vcpu);
+      break;
+
+   case XEN_DOMCTL_scheduler_op:
+      PRE_XEN_DOMCTL_READ(scheduler_op, sched_id);
+      PRE_XEN_DOMCTL_READ(scheduler_op, cmd);
+      if ( domctl->u.scheduler_op.cmd == XEN_DOMCTL_SCHEDOP_putinfo ) {
+         switch(domctl->u.scheduler_op.sched_id) {
+         case XEN_SCHEDULER_SEDF:
+            PRE_XEN_DOMCTL_READ(scheduler_op, u.sedf.period);
+            PRE_XEN_DOMCTL_READ(scheduler_op, u.sedf.slice);
+            PRE_XEN_DOMCTL_READ(scheduler_op, u.sedf.latency);
+            PRE_XEN_DOMCTL_READ(scheduler_op, u.sedf.extratime);
+            PRE_XEN_DOMCTL_READ(scheduler_op, u.sedf.weight);
+            break;
+         case XEN_SCHEDULER_CREDIT:
+            PRE_XEN_DOMCTL_READ(scheduler_op, u.credit.weight);
+            PRE_XEN_DOMCTL_READ(scheduler_op, u.credit.cap);
+            break;
+         case XEN_SCHEDULER_CREDIT2:
+            PRE_XEN_DOMCTL_READ(scheduler_op, u.credit2.weight);
+            break;
+         case XEN_SCHEDULER_ARINC653:
+            break;
+         }
+      }
+      break;
+
+   case XEN_DOMCTL_getvcpuaffinity:
+      __PRE_XEN_DOMCTL_READ(getvcpuaffinity, vcpuaffinity, vcpu);
+      break;
+
+   case XEN_DOMCTL_setvcpuaffinity:
+      __PRE_XEN_DOMCTL_READ(setvcpuaffinity, vcpuaffinity, vcpu);
+      PRE_MEM_READ("XEN_DOMCTL_setvcpuaffinity",
+                   (Addr)domctl->u.vcpuaffinity.cpumap.bitmap.p,
+                   domctl->u.vcpuaffinity.cpumap.nr_cpus / 8);
+      break;
+
+   case XEN_DOMCTL_getvcpucontext:
+      __PRE_XEN_DOMCTL_READ(getvcpucontext, vcpucontext, vcpu);
+      break;
+
+   case XEN_DOMCTL_setvcpucontext:
+      __PRE_XEN_DOMCTL_READ(setvcpucontext, vcpucontext, vcpu);
+      __PRE_XEN_DOMCTL_READ(setvcpucontext, vcpucontext, ctxt.p);
+      break;
+
+   case XEN_DOMCTL_set_cpuid:
+      PRE_MEM_READ("XEN_DOMCTL_set_cpuid",
+                   (Addr)&domctl->u.cpuid, sizeof(domctl->u.cpuid));
+      break;
+
+   case XEN_DOMCTL_getvcpuextstate:
+      __PRE_XEN_DOMCTL_READ(getvcpuextstate, vcpuextstate, vcpu);
+      __PRE_XEN_DOMCTL_READ(getvcpuextstate, vcpuextstate, xfeature_mask);
+      __PRE_XEN_DOMCTL_READ(getvcpuextstate, vcpuextstate, size);
+      __PRE_XEN_DOMCTL_READ(getvcpuextstate, vcpuextstate, buffer);
+      break;
+
+   default:
+      bad_subop(tid, layout, arrghs, status, flags,
+                "__HYPERVISOR_domctl", domctl->cmd);
+      break;
+   }
+#undef PRE_XEN_DOMCTL_READ
+#undef __PRE_XEN_DOMCTL_READ
+}
+
+PRE(hvm_op)
+{
+   unsigned long op = ARG1;
+   void *arg = (void *)(unsigned long)ARG2;
+
+   PRINT("__HYPERVISOR_hvm_op ( %ld, %p )", op, arg);
+
+#define __PRE_XEN_HVMOP_READ(_hvm_op, _type, _field)    \
+   PRE_MEM_READ("XEN_HVMOP_" # _hvm_op,                 \
+                (Addr)&((_type*)arg)->_field,           \
+                sizeof(((_type*)arg)->_field))
+#define PRE_XEN_HVMOP_READ(_hvm_op, _field)                             \
+   __PRE_XEN_HVMOP_READ(_hvm_op, "xen_hvm_" # _hvm_op "_t", _field)
+
+   switch (op) {
+   case HVMOP_set_param:
+      __PRE_XEN_HVMOP_READ(set_param, xen_hvm_param_t, domid);
+      __PRE_XEN_HVMOP_READ(set_param, xen_hvm_param_t, index);
+      __PRE_XEN_HVMOP_READ(set_param, xen_hvm_param_t, value);
+      break;
+
+   case HVMOP_get_param:
+      __PRE_XEN_HVMOP_READ(get_param, xen_hvm_param_t, domid);
+      __PRE_XEN_HVMOP_READ(get_param, xen_hvm_param_t, index);
+      break;
+
+   default:
+      bad_subop(tid, layout, arrghs, status, flags,
+                "__HYPERVISOR_hvm_op", op);
+      break;
+   }
+#undef __PRE_XEN_HVMOP_READ
+#undef PRE_XEN_HVMOP_READ
+}
+
+POST(memory_op)
+{
+   switch (ARG1) {
+   case XENMEM_set_memory_map:
+   case XENMEM_decrease_reservation:
+      /* No outputs */
+      break;
+   case XENMEM_increase_reservation:
+   case XENMEM_populate_physmap: {
+      struct xen_memory_reservation *memory_reservation =
+         (struct xen_memory_reservation *)(unsigned int)ARG2;
+
+      POST_MEM_WRITE((Addr)memory_reservation->extent_start.p,
+                     sizeof(xen_pfn_t) * memory_reservation->nr_extents);
+      break;
+   }
+   }
+}
+
+POST(mmuext_op)
+{
+   unsigned int *pdone = (void *)(unsigned int)ARG3;
+   /* simplistic */
+   POST_MEM_WRITE((Addr)pdone, sizeof(*pdone));
+}
+
+static void post_evtchn_op(ThreadId tid, __vki_u32 cmd, void *arg, int compat)
+{
+   switch (cmd) {
+   case EVTCHNOP_alloc_unbound: {
+      struct evtchn_alloc_unbound *alloc_unbound = arg;
+      POST_MEM_WRITE((Addr)&alloc_unbound->port, sizeof(alloc_unbound->port));
+      break;
+   }
+   }
+}
+
+POST(evtchn_op)
+{
+   post_evtchn_op(tid, ARG1, (void *)(unsigned int)ARG2, 0);
+}
+
+POST(evtchn_op_compat)
+{
+   struct evtchn_op *evtchn = (struct evtchn_op *)(unsigned int)ARG1;
+   post_evtchn_op(tid, evtchn->cmd, &evtchn->u, 1);
+}
+
+POST(xen_version)
+{
+   switch (ARG1) {
+   case XENVER_version:
+      /* No outputs */
+      break;
+   case XENVER_extraversion:
+      POST_MEM_WRITE((Addr)ARG2, sizeof(xen_extraversion_t));
+      break;
+   case XENVER_compile_info:
+      POST_MEM_WRITE((Addr)ARG2, sizeof(xen_compile_info_t));
+      break;
+   case XENVER_capabilities:
+      POST_MEM_WRITE((Addr)ARG2, sizeof(xen_capabilities_info_t));
+      break;
+   case XENVER_changeset:
+      POST_MEM_WRITE((Addr)ARG2, sizeof(xen_changeset_info_t));
+      break;
+   case XENVER_platform_parameters:
+      POST_MEM_WRITE((Addr)ARG2, sizeof(xen_platform_parameters_t));
+      break;
+   case XENVER_get_features:
+      POST_MEM_WRITE((Addr)ARG2, sizeof(xen_feature_info_t));
+      break;
+   case XENVER_pagesize:
+      /* No outputs */
+      break;
+   case XENVER_guest_handle:
+      POST_MEM_WRITE((Addr)ARG2, sizeof(xen_domain_handle_t));
+      break;
+   case XENVER_commandline:
+      POST_MEM_WRITE((Addr)ARG2, sizeof(xen_commandline_t));
+      break;
+   }
+}
+
+POST(grant_table_op)
+{
+   switch (ARG1) {
+   case GNTTABOP_setup_table: {
+      struct gnttab_setup_table *gst = (void *)(uintptr_t)ARG2;
+      PRE_MEM_WRITE("GNTTABOP_setup_table",
+                    (Addr)&gst->status, sizeof(gst->status));
+      PRE_MEM_WRITE("GNTTABOP_setup_table",
+                    (Addr)gst->frame_list.p,
+                    sizeof(*gst->frame_list.p) & gst->nr_frames);
+      break;
+   }
+   }
+}
+
+POST(sysctl)
+{
+   struct xen_sysctl *sysctl = (struct xen_sysctl *)(unsigned int)ARG1;
+
+   if (!sysctl || sysctl->interface_version != XEN_SYSCTL_INTERFACE_VERSION)
+      return;
+
+#define __POST_XEN_SYSCTL_WRITE(_sysctl, _union, _field)        \
+      POST_MEM_WRITE((Addr)&sysctl->u._union._field,            \
+                     sizeof(sysctl->u._union._field))
+#define POST_XEN_SYSCTL_WRITE(_sysctl, _field) \
+      __POST_XEN_SYSCTL_WRITE(_sysctl, _sysctl, _field)
+
+   switch (sysctl->cmd) {
+   case XEN_SYSCTL_getdomaininfolist:
+      POST_XEN_SYSCTL_WRITE(getdomaininfolist, num_domains);
+      POST_MEM_WRITE((Addr)sysctl->u.getdomaininfolist.buffer.p,
+                     sizeof(xen_domctl_getdomaininfo_t)
+                     * sysctl->u.getdomaininfolist.num_domains);
+      break;
+
+   case XEN_SYSCTL_cpupool_op:
+      if (sysctl->u.cpupool_op.op == XEN_SYSCTL_CPUPOOL_OP_CREATE ||
+          sysctl->u.cpupool_op.op == XEN_SYSCTL_CPUPOOL_OP_INFO)
+         POST_XEN_SYSCTL_WRITE(cpupool_op, cpupool_id);
+      if (sysctl->u.cpupool_op.op == XEN_SYSCTL_CPUPOOL_OP_INFO) {
+         POST_XEN_SYSCTL_WRITE(cpupool_op, sched_id);
+         POST_XEN_SYSCTL_WRITE(cpupool_op, n_dom);
+      }
+      if (sysctl->u.cpupool_op.op == XEN_SYSCTL_CPUPOOL_OP_INFO ||
+          sysctl->u.cpupool_op.op == XEN_SYSCTL_CPUPOOL_OP_FREEINFO)
+         POST_XEN_SYSCTL_WRITE(cpupool_op, cpumap);
+      break;
+
+   case XEN_SYSCTL_physinfo:
+      POST_XEN_SYSCTL_WRITE(physinfo, threads_per_core);
+      POST_XEN_SYSCTL_WRITE(physinfo, cores_per_socket);
+      POST_XEN_SYSCTL_WRITE(physinfo, nr_cpus);
+      POST_XEN_SYSCTL_WRITE(physinfo, max_cpu_id);
+      POST_XEN_SYSCTL_WRITE(physinfo, nr_nodes);
+      POST_XEN_SYSCTL_WRITE(physinfo, max_node_id);
+      POST_XEN_SYSCTL_WRITE(physinfo, cpu_khz);
+      POST_XEN_SYSCTL_WRITE(physinfo, total_pages);
+      POST_XEN_SYSCTL_WRITE(physinfo, free_pages);
+      POST_XEN_SYSCTL_WRITE(physinfo, scrub_pages);
+      POST_XEN_SYSCTL_WRITE(physinfo, hw_cap[8]);
+      POST_XEN_SYSCTL_WRITE(physinfo, capabilities);
+      break;
+
+   case XEN_SYSCTL_topologyinfo:
+      POST_XEN_SYSCTL_WRITE(topologyinfo, max_cpu_index);
+      POST_MEM_WRITE((Addr)sysctl->u.topologyinfo.cpu_to_core.p,
+                     sizeof(uint32_t) * sysctl->u.topologyinfo.max_cpu_index);
+      POST_MEM_WRITE((Addr)sysctl->u.topologyinfo.cpu_to_socket.p,
+                     sizeof(uint32_t) * sysctl->u.topologyinfo.max_cpu_index);
+      POST_MEM_WRITE((Addr)sysctl->u.topologyinfo.cpu_to_node.p,
+                     sizeof(uint32_t) * sysctl->u.topologyinfo.max_cpu_index);
+      break;
+
+   case XEN_SYSCTL_numainfo:
+      POST_XEN_SYSCTL_WRITE(numainfo, max_node_index);
+      POST_MEM_WRITE((Addr)sysctl->u.numainfo.node_to_memsize.p,
+                     sizeof(uint64_t) * sysctl->u.numainfo.max_node_index);
+      POST_MEM_WRITE((Addr)sysctl->u.numainfo.node_to_memfree.p,
+                     sizeof(uint64_t) * sysctl->u.numainfo.max_node_index);
+      POST_MEM_WRITE((Addr)sysctl->u.numainfo.node_to_node_distance.p,
+                     sizeof(uint32_t) * sysctl->u.numainfo.max_node_index);
+   }
+#undef POST_XEN_SYSCTL_WRITE
+#undef __POST_XEN_SYSCTL_WRITE
+}
+
+POST(domctl){
+   struct xen_domctl *domctl = (struct xen_domctl *)(unsigned int)ARG1;
+
+   if (!domctl || domctl->interface_version != XEN_DOMCTL_INTERFACE_VERSION)
+      return;
+
+#define __POST_XEN_DOMCTL_WRITE(_domctl, _union, _field)        \
+   POST_MEM_WRITE((Addr)&domctl->u._union._field,               \
+                  sizeof(domctl->u._union._field));
+#define POST_XEN_DOMCTL_WRITE(_domctl, _field)          \
+   __POST_XEN_DOMCTL_WRITE(_domctl, _domctl, _field)
+
+   switch (domctl->cmd) {
+   case XEN_DOMCTL_createdomain:
+   case XEN_DOMCTL_destroydomain:
+   case XEN_DOMCTL_pausedomain:
+   case XEN_DOMCTL_max_mem:
+   case XEN_DOMCTL_set_address_size:
+   case XEN_DOMCTL_settscinfo:
+   case XEN_DOMCTL_hypercall_init:
+   case XEN_DOMCTL_setvcpuaffinity:
+   case XEN_DOMCTL_setvcpucontext:
+   case XEN_DOMCTL_set_cpuid:
+   case XEN_DOMCTL_unpausedomain:
+      /* No output fields */
+      break;
+
+   case XEN_DOMCTL_max_vcpus:
+      POST_XEN_DOMCTL_WRITE(max_vcpus, max);
+
+   case XEN_DOMCTL_get_address_size:
+      __POST_XEN_DOMCTL_WRITE(get_address_size, address_size, size);
+      break;
+
+   case XEN_DOMCTL_gettscinfo:
+      __POST_XEN_DOMCTL_WRITE(settscinfo, tsc_info, info.tsc_mode);
+      __POST_XEN_DOMCTL_WRITE(settscinfo, tsc_info, info.gtsc_khz);
+      __POST_XEN_DOMCTL_WRITE(settscinfo, tsc_info, info.incarnation);
+      __POST_XEN_DOMCTL_WRITE(settscinfo, tsc_info, info.elapsed_nsec);
+      break;
+
+   case XEN_DOMCTL_getvcpuinfo:
+      POST_XEN_DOMCTL_WRITE(getvcpuinfo, online);
+      POST_XEN_DOMCTL_WRITE(getvcpuinfo, blocked);
+      POST_XEN_DOMCTL_WRITE(getvcpuinfo, running);
+      POST_XEN_DOMCTL_WRITE(getvcpuinfo, cpu_time);
+      POST_XEN_DOMCTL_WRITE(getvcpuinfo, cpu);
+      break;
+
+   case XEN_DOMCTL_scheduler_op:
+      if ( domctl->u.scheduler_op.cmd == XEN_DOMCTL_SCHEDOP_getinfo ) {
+         switch(domctl->u.scheduler_op.sched_id) {
+         case XEN_SCHEDULER_SEDF:
+            POST_XEN_DOMCTL_WRITE(scheduler_op, u.sedf.period);
+            POST_XEN_DOMCTL_WRITE(scheduler_op, u.sedf.slice);
+            POST_XEN_DOMCTL_WRITE(scheduler_op, u.sedf.latency);
+            POST_XEN_DOMCTL_WRITE(scheduler_op, u.sedf.extratime);
+            POST_XEN_DOMCTL_WRITE(scheduler_op, u.sedf.weight);
+            break;
+         case XEN_SCHEDULER_CREDIT:
+            POST_XEN_DOMCTL_WRITE(scheduler_op, u.credit.weight);
+            POST_XEN_DOMCTL_WRITE(scheduler_op, u.credit.cap);
+            break;
+         case XEN_SCHEDULER_CREDIT2:
+            POST_XEN_DOMCTL_WRITE(scheduler_op, u.credit2.weight);
+            break;
+         case XEN_SCHEDULER_ARINC653:
+            break;
+         }
+      }
+      break;
+
+   case XEN_DOMCTL_getvcpuaffinity:
+      POST_MEM_WRITE((Addr)domctl->u.vcpuaffinity.cpumap.bitmap.p,
+                     domctl->u.vcpuaffinity.cpumap.nr_cpus / 8);
+      break;
+
+   case XEN_DOMCTL_getdomaininfo:
+      POST_XEN_DOMCTL_WRITE(getdomaininfo, domain);
+      POST_XEN_DOMCTL_WRITE(getdomaininfo, flags);
+      POST_XEN_DOMCTL_WRITE(getdomaininfo, tot_pages);
+      POST_XEN_DOMCTL_WRITE(getdomaininfo, max_pages);
+      POST_XEN_DOMCTL_WRITE(getdomaininfo, shr_pages);
+      POST_XEN_DOMCTL_WRITE(getdomaininfo, shared_info_frame);
+      POST_XEN_DOMCTL_WRITE(getdomaininfo, cpu_time);
+      POST_XEN_DOMCTL_WRITE(getdomaininfo, nr_online_vcpus);
+      POST_XEN_DOMCTL_WRITE(getdomaininfo, max_vcpu_id);
+      POST_XEN_DOMCTL_WRITE(getdomaininfo, ssidref);
+      POST_XEN_DOMCTL_WRITE(getdomaininfo, handle);
+      POST_XEN_DOMCTL_WRITE(getdomaininfo, cpupool);
+      break;
+
+   case XEN_DOMCTL_getvcpucontext:
+      __POST_XEN_DOMCTL_WRITE(getvcpucontext, vcpucontext, ctxt.p);
+      break;
+
+   case XEN_DOMCTL_getvcpuextstate:
+      __POST_XEN_DOMCTL_WRITE(getvcpuextstate, vcpuextstate, xfeature_mask);
+      __POST_XEN_DOMCTL_WRITE(getvcpuextstate, vcpuextstate, size);
+      POST_MEM_WRITE((Addr)domctl->u.vcpuextstate.buffer.p,
+                     domctl->u.vcpuextstate.size);
+      break;
+
+   }
+#undef POST_XEN_DOMCTL_WRITE
+#undef __POST_XEN_DOMCTL_WRITE
+}
+
+POST(hvm_op)
+{
+   unsigned long op = ARG1;
+   void *arg = (void *)(unsigned long)ARG2;
+
+#define __POST_XEN_HVMOP_WRITE(_hvm_op, _type, _field)  \
+      POST_MEM_WRITE((Addr)&((_type*)arg)->_field,      \
+                     sizeof(((_type*)arg)->_field))
+#define POST_XEN_HVMOP_WRITE(_hvm_op, _field) \
+      __PRE_XEN_HVMOP_READ(_hvm_op, "xen_hvm_" # _hvm_op "_t", _field)
+
+   switch (op) {
+   case HVMOP_set_param:
+      /* No output paramters */
+      break;
+
+   case HVMOP_get_param:
+      __POST_XEN_HVMOP_WRITE(get_param, xen_hvm_param_t, value);
+      break;
+   }
+#undef __POST_XEN_HVMOP_WRITE
+#undef POST_XEN_HVMOP_WRITE
+}
+
+typedef
+   struct {
+      SyscallTableEntry entry;
+      int nr_args;
+   }
+   XenHypercallTableEntry;
+
+#define HYPX_(const, name, nr_args) \
+   [const] = { { vgSysWrap_xen_##name##_before, NULL }, nr_args }
+#define HYPXY(const, name, nr_args)                     \
+   [const] = { { vgSysWrap_xen_##name##_before,         \
+                 vgSysWrap_xen_##name##_after },        \
+               nr_args }
+
+static XenHypercallTableEntry hypercall_table[] = {
+   //    __HYPERVISOR_set_trap_table                                  // 0
+   //    __HYPERVISOR_mmu_update                                      // 1
+   //    __HYPERVISOR_set_gdt                                         // 2
+   //    __HYPERVISOR_stack_switch                                    // 3
+   //    __HYPERVISOR_set_callbacks                                   // 4
+
+   //    __HYPERVISOR_fpu_taskswitch                                  // 5
+   //    __HYPERVISOR_sched_op_compat                                 // 6
+   //    __HYPERVISOR_platform_op                                     // 7
+   //    __HYPERVISOR_set_debugreg                                    // 8
+   //    __HYPERVISOR_get_debugreg                                    // 9
+
+   //    __HYPERVISOR_update_descriptor                               // 10
+   //                                                                 // 11
+   HYPXY(__HYPERVISOR_memory_op,               memory_op,         2), // 12
+   //    __HYPERVISOR_multicall                                       // 13
+   //    __HYPERVISOR_update_va_mapping                               // 14
+
+   //    __HYPERVISOR_set_timer_op                                    // 15
+   HYPXY(__HYPERVISOR_event_channel_op_compat, evtchn_op_compat,  1), // 16
+   HYPXY(__HYPERVISOR_xen_version,             xen_version,       2), // 17
+   //    __HYPERVISOR_console_io                                      // 18
+   //    __HYPERVISOR_physdev_op_compat                               // 19
+
+   HYPXY(__HYPERVISOR_grant_table_op,          grant_table_op,    3), // 20
+   //    __HYPERVISOR_vm_assist                                       // 21
+   //    __HYPERVISOR_update_va_mapping_otherdomain                   // 22
+   //    __HYPERVISOR_iret,                    iret                   // 23
+   //    __HYPERVISOR_vcpu_op,                 vcpu_op                // 24
+
+   //    __HYPERVISOR_set_segment_base                                // 25
+   HYPXY(__HYPERVISOR_mmuext_op,               mmuext_op,         2), // 26
+   //    __HYPERVISOR_xsm_op                                          // 27
+   //    __HYPERVISOR_nmi_op                                          // 28
+   //    __HYPERVISOR_sched_op                                        // 29
+
+   //    __HYPERVISOR_callback_op                                     // 30
+   //    __HYPERVISOR_xenoprof_op                                     // 31
+   HYPXY(__HYPERVISOR_event_channel_op,        evtchn_op,         2), // 32
+   //    __HYPERVISOR_physdev_op                                      // 33
+   HYPXY(__HYPERVISOR_hvm_op,                  hvm_op,            2), // 34
+
+   HYPXY(__HYPERVISOR_sysctl,                  sysctl,            1), // 35
+   HYPXY(__HYPERVISOR_domctl,                  domctl,            1), // 36
+   //    __HYPERVISOR_kexec_op                                        // 37
+   //    __HYPERVISOR_tmem_op                                         // 38
+};
+
+static void bad_before ( ThreadId              tid,
+                         SyscallArgLayout*     layout,
+                         /*MOD*/SyscallArgs*   args,
+                         /*OUT*/SyscallStatus* status,
+                         /*OUT*/UWord*         flags )
+{
+   VG_(dmsg)("WARNING: unhandled hypercall: %s\n",
+      VG_SYSNUM_STRING_EXTRA(args->sysno));
+   if (VG_(clo_verbosity) > 1) {
+      VG_(get_and_pp_StackTrace)(tid, VG_(clo_backtrace_size));
+   }
+   VG_(dmsg)("You may be able to write your own handler.\n");
+   VG_(dmsg)("Read the file README_MISSING_SYSCALL_OR_IOCTL.\n");
+   VG_(dmsg)("Nevertheless we consider this a bug.  Please report\n");
+   VG_(dmsg)("it at http://valgrind.org/support/bug_reports.html &\n");
+   VG_(dmsg)("http://wiki.xen.org/wiki/Reporting_Bugs_against_Xen.\n");
+
+   SET_STATUS_Failure(VKI_ENOSYS);
+}
+
+static XenHypercallTableEntry bad_hyper =
+{ { bad_before, NULL }, 0 };
+
+static XenHypercallTableEntry* ML_(get_xen_hypercall_entry) ( UInt sysno )
+{
+   XenHypercallTableEntry *ret = &bad_hyper;
+
+   const UInt hypercall_table_size
+      = sizeof(hypercall_table) / sizeof(hypercall_table[0]);
+
+   /* Is it in the contiguous initial section of the table? */
+   if (sysno < hypercall_table_size) {
+      XenHypercallTableEntry* ent = &hypercall_table[sysno];
+      if (ent->entry.before != NULL)
+         ret = ent;
+   }
+
+   /* Can't find a wrapper */
+   return ret;
+}
+
+DEFN_PRE_TEMPLATE(xen, hypercall)
+{
+   XenHypercallTableEntry *ent = ML_(get_xen_hypercall_entry)(SYSNO);
+
+   /* Return number of arguments consumed */
+   ARG8 = ent->nr_args;
+
+   vg_assert(ent);
+   vg_assert(ent->entry.before);
+   (ent->entry.before)( tid, layout, arrghs, status, flags );
+
+}
+
+DEFN_POST_TEMPLATE(xen, hypercall)
+{
+   XenHypercallTableEntry *ent = ML_(get_xen_hypercall_entry)(SYSNO);
+
+   /* Return number of arguments consumed */
+   ARG8 = ent->nr_args;
+
+   vg_assert(ent);
+   if (ent->entry.after)
+      (ent->entry.after)( tid, arrghs, status );
+}
diff --git a/include/Makefile.am b/include/Makefile.am
index ade27c2..f1a3443 100644
--- a/include/Makefile.am
+++ b/include/Makefile.am
@@ -64,4 +64,5 @@ nobase_pkginclude_HEADERS = \
 	vki/vki-scnums-arm-linux.h	\
 	vki/vki-scnums-s390x-linux.h	\
 	vki/vki-scnums-mips32-linux.h	\
-	vki/vki-scnums-darwin.h
+	vki/vki-scnums-darwin.h		\
+	vki/vki-xen.h
diff --git a/include/pub_tool_vki.h b/include/pub_tool_vki.h
index a0996f9..6598106 100644
--- a/include/pub_tool_vki.h
+++ b/include/pub_tool_vki.h
@@ -47,6 +47,7 @@
 
 #if defined(VGO_linux)
 #  include "vki/vki-linux.h"
+#  include "vki/vki-xen.h"
 #elif defined(VGO_darwin)
 #  include "vki/vki-darwin.h"
 #else
diff --git a/include/vki/vki-linux.h b/include/vki/vki-linux.h
index c18195e..4fdc353 100644
--- a/include/vki/vki-linux.h
+++ b/include/vki/vki-linux.h
@@ -3009,6 +3009,50 @@ struct vki_hwtstamp_config {
 #define VKI_UI_SET_SWBIT		_VKI_IOW(VKI_UINPUT_IOCTL_BASE, 109, int)
 #define VKI_UI_SET_PROPBIT		_VKI_IOW(VKI_UINPUT_IOCTL_BASE, 110, int)
 
+//----------------------------------------------------------------------
+// Xen privcmd IOCTL
+//----------------------------------------------------------------------
+
+typedef unsigned long __vki_xen_pfn_t;
+
+struct vki_xen_privcmd_hypercall {
+	__vki_u64 op;
+	__vki_u64 arg[5];
+};
+
+struct vki_xen_privcmd_mmap_entry {
+        __vki_u64 va;
+        __vki_u64 mfn;
+        __vki_u64 npages;
+};
+
+struct vki_xen_privcmd_mmap {
+        int num;
+        __vki_u16 dom; /* target domain */
+        struct vki_xen_privcmd_mmap_entry *entry;
+};
+
+struct vki_xen_privcmd_mmapbatch {
+        int num;     /* number of pages to populate */
+        __vki_u16 dom; /* target domain */
+        __vki_u64 addr;  /* virtual address */
+        __vki_xen_pfn_t *arr; /* array of mfns - top nibble set on err */
+};
+
+struct vki_xen_privcmd_mmapbatch_v2 {
+        unsigned int num; /* number of pages to populate */
+        __vki_u16 dom;      /* target domain */
+        __vki_u64 addr;       /* virtual address */
+        const __vki_xen_pfn_t *arr; /* array of mfns */
+        int __user *err;  /* array of error codes */
+};
+
+#define VKI_XEN_IOCTL_PRIVCMD_HYPERCALL    _VKI_IOC(_VKI_IOC_NONE, 'P', 0, sizeof(struct vki_xen_privcmd_hypercall))
+#define VKI_XEN_IOCTL_PRIVCMD_MMAP         _VKI_IOC(_VKI_IOC_NONE, 'P', 2, sizeof(struct vki_xen_privcmd_mmap))
+
+#define VKI_XEN_IOCTL_PRIVCMD_MMAPBATCH    _VKI_IOC(_VKI_IOC_NONE, 'P', 3, sizeof(struct vki_xen_privcmd_mmapbatch))
+#define VKI_XEN_IOCTL_PRIVCMD_MMAPBATCH_V2 _VKI_IOC(_VKI_IOC_NONE, 'P', 4, sizeof(struct vki_xen_privcmd_mmapbatch_v2))
+
 #endif // __VKI_LINUX_H
 
 /*--------------------------------------------------------------------*/
diff --git a/include/vki/vki-xen.h b/include/vki/vki-xen.h
new file mode 100644
index 0000000..7842cc9
--- /dev/null
+++ b/include/vki/vki-xen.h
@@ -0,0 +1,8 @@
+#ifndef __VKI_XEN_H
+#define __VKI_XEN_H
+
+#endif // __VKI_XEN_H
+
+/*--------------------------------------------------------------------*/
+/*--- 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 Tue Sep 04 16:13:56 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Sep 2012 16:13:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T8vks-0004fo-32; Tue, 04 Sep 2012 16:13: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 1T8vkp-0004fj-DX
	for xen-devel@lists.xen.org; Tue, 04 Sep 2012 16:13:31 +0000
Received: from [85.158.143.99:18821] by server-2.bemta-4.messagelabs.com id
	2D/36-21239-9A826405; Tue, 04 Sep 2012 16:13:29 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1346775208!28521464!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTE3MTg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4415 invoked from network); 4 Sep 2012 16:13:28 -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;
	4 Sep 2012 16:13:28 -0000
X-IronPort-AV: E=Sophos;i="4.80,367,1344211200"; d="scan'208";a="14340726"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Sep 2012 16:12: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.279.1; Tue, 4 Sep 2012
	17:12:49 +0100
Message-ID: <1346775168.6712.60.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: <valgrind-developers@lists.sourceforge.net>, xen-devel
	<xen-devel@lists.xen.org>
Date: Tue, 4 Sep 2012 17:12:48 +0100
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Subject: [Xen-devel] [PATCH] valgrind: Support for ioctls used by Xen
 toolstack processes.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 CC as I'm not subscribed to valgrind-developers.

Under Xen the toolstack is responsible for managing the domains in
the system, e.g. creating, destroying, and otherwise manipulating
them.

To do this it uses a number of ioctls on the /proc/xen/privcmd
device. Most of these (the MMAPBATCH ones) simply set things up such
that a subsequenct mmap call will map the desired guest memory. Since
valgrind has no way of knowing what the memory contains we assume
that it is all initialised (to do otherwise would require valgrind to
be observing the complete state of the system and not just the given
process).

The most interesting ioctl is XEN_IOCTL_PRIVCMD_HYPERCALL which
allows the toolstack to make arbitrary hypercalls. Although the
mechanism here is specific to the OS of the guest running the
toolstack the hypercalls themselves are defined solely by the
hypervisor. Therefore I have split support for this ioctl into a part
in syswrap-linux.c which handles the ioctl itself and passes things
onto a new syswrap-xen.c which handles the specifics of the
hypercalls themselves. Porting this to another OS should just be a
matter of wiring up syswrap-$OS.c to decode the ioctl and call into
syswrap-xen.c. In the future we may want to split this into
syswrap-$ARCH-xen.c but for now this is x86 only.

The hypercall coverage here is pretty small but is enough to get
reasonable(-ish) results out of the xl toolstack when listing,
creating and destroying domains.

One issue is that the hypercalls which are exlusively used by the
toolstacks (as opposed to those used by guest operating systems) are
not considered a stable ABI, since the hypervisor and the lowlevel
tools are considered a matched pair. This covers the sysctl and
domctl hypercalls which are a fairly large chunk of the support
here. I'm not sure how to solve this without invoking a massive
amount of duplication. Right now this targets the Xen unstable
interface (which will shortly be released as Xen 4.2), perhaps I can
get away with deferring this problem until the first change ;-).

On the plus side the vast majority of hypercalls are not of interest
to the toolstack (they are used by guests) so we can get away without
implementing them.

There are some other wrinkles here I've not been sure how to solve:

Firstly, di_notify_mmap tries to read from the magic proc device:
     --20208-- WARNING: Serious error when reading debug info
     --20208-- When reading debug info from /proc/xen/privcmd:
     --20208-- can't read file to inspect ELF header

I've hacked around this with an explicit check for /proc/xen.
Hopefully someone can point to the right solution.

Secondly, a hypercall only reads as many words from the ioctl arg
struct as there are actual arguments to that hypercall and the
toolstack only initialises the arguments which are used. However
there is no space in the DEFN_PRE_TEMPLATE prototype to allow this to
be communicated from syswrap-xen.c back to syswrap-linux.c. Since a
hypercall can have at most 5 arguments I have hackily stolen ARG8 for
this purpose.
---
 configure.in                           |   19 +
 coregrind/Makefile.am                  |    8 +-
 coregrind/m_debuginfo/debuginfo.c      |    9 +
 coregrind/m_syswrap/priv_syswrap-xen.h |   10 +
 coregrind/m_syswrap/syswrap-linux.c    |  107 ++++-
 coregrind/m_syswrap/syswrap-xen.c      | 1023 ++++++++++++++++++++++++++++++++
 include/Makefile.am                    |    3 +-
 include/pub_tool_vki.h                 |    1 +
 include/vki/vki-linux.h                |   44 ++
 include/vki/vki-xen.h                  |    8 +
 10 files changed, 1229 insertions(+), 3 deletions(-)
 create mode 100644 coregrind/m_syswrap/priv_syswrap-xen.h
 create mode 100644 coregrind/m_syswrap/syswrap-xen.c
 create mode 100644 include/vki/vki-xen.h

diff --git a/configure.in b/configure.in
index b385aed..d94644c 100644
--- a/configure.in
+++ b/configure.in
@@ -2012,6 +2012,25 @@ AC_ARG_WITH(mpicc,
 )
 AC_SUBST(MPI_CC)
 
+#----------------------------------------------------------------------------
+# Xen checks
+#----------------------------------------------------------------------------
+AC_ARG_ENABLE(xen, 
+      [  --enable-xen            Enable support for Xen hypervisor],
+      [vg_cv_xen=$enableval],
+      [vg_cv_xen=no])
+
+AC_ARG_WITH(xen,
+   [  --with-xen=             Specify location of Xen headers],
+   XEN_CFLAGS=-I$withval
+)
+AC_SUBST(XEN_CFLAGS)
+
+AM_CONDITIONAL([ENABLE_XEN], [test x$vg_cv_xen = xyes])
+if test x"$vg_cv_xen" = xyes; then
+    AC_DEFINE([ENABLE_XEN], 1, [configured to support Xen])
+fi
+
 ## We AM_COND_IF here instead of automake "if" in mpi/Makefile.am so that we can
 ## use these values in the check for a functioning mpicc.
 ##
diff --git a/coregrind/Makefile.am b/coregrind/Makefile.am
index 01015a7..58a7dce 100644
--- a/coregrind/Makefile.am
+++ b/coregrind/Makefile.am
@@ -224,6 +224,7 @@ noinst_HEADERS = \
 	m_syswrap/priv_syswrap-linux-variants.h \
 	m_syswrap/priv_syswrap-darwin.h \
 	m_syswrap/priv_syswrap-main.h \
+	m_syswrap/priv_syswrap-xen.h \
 	m_ume/priv_ume.h
 
 #----------------------------------------------------------------------------
@@ -371,6 +372,11 @@ COREGRIND_SOURCES_COMMON = \
 	m_ume/main.c \
 	m_ume/script.c
 
+if ENABLE_XEN
+COREGRIND_SOURCES_COMMON += m_syswrap/syswrap-xen.c
+CFLAGS += @XEN_CFLAGS@
+endif
+
 libcoregrind_@VGCONF_ARCH_PRI@_@VGCONF_OS@_a_SOURCES = \
     $(COREGRIND_SOURCES_COMMON)
 nodist_libcoregrind_@VGCONF_ARCH_PRI@_@VGCONF_OS@_a_SOURCES = \
@@ -378,7 +384,7 @@ nodist_libcoregrind_@VGCONF_ARCH_PRI@_@VGCONF_OS@_a_SOURCES = \
 libcoregrind_@VGCONF_ARCH_PRI@_@VGCONF_OS@_a_CPPFLAGS = \
     $(AM_CPPFLAGS_@VGCONF_PLATFORM_PRI_CAPS@)
 libcoregrind_@VGCONF_ARCH_PRI@_@VGCONF_OS@_a_CFLAGS = \
-    $(AM_CFLAGS_@VGCONF_PLATFORM_PRI_CAPS@)
+    $(AM_CFLAGS_@VGCONF_PLATFORM_PRI_CAPS@) @XEN_CFLAGS@
 libcoregrind_@VGCONF_ARCH_PRI@_@VGCONF_OS@_a_CCASFLAGS = \
     $(AM_CCASFLAGS_@VGCONF_PLATFORM_PRI_CAPS@)
 if ENABLE_LINUX_TICKET_LOCK_PRIMARY
diff --git a/coregrind/m_debuginfo/debuginfo.c b/coregrind/m_debuginfo/debuginfo.c
index 218547b..b634ce0 100644
--- a/coregrind/m_debuginfo/debuginfo.c
+++ b/coregrind/m_debuginfo/debuginfo.c
@@ -729,6 +729,15 @@ ULong VG_(di_notify_mmap)( Addr a, Bool allow_SkFileV, Int use_fd )
    if (!filename)
       return 0;
 
+   /*
+    * Cannot read from these magic files:
+    * --20208-- WARNING: Serious error when reading debug info
+    * --20208-- When reading debug info from /proc/xen/privcmd:
+    * --20208-- can't read file to inspect ELF header
+    */
+   if (VG_(strncmp)(filename, "/proc/xen/", 10) == 0)
+      return 0;
+
    if (debug)
       VG_(printf)("di_notify_mmap-2: %s\n", filename);
 
diff --git a/coregrind/m_syswrap/priv_syswrap-xen.h b/coregrind/m_syswrap/priv_syswrap-xen.h
new file mode 100644
index 0000000..4dc4748
--- /dev/null
+++ b/coregrind/m_syswrap/priv_syswrap-xen.h
@@ -0,0 +1,10 @@
+#ifndef __PRIV_SYSWRAP_XEN_H
+#define __PRIV_SYSWRAP_XEN_H
+
+DECL_TEMPLATE(xen, hypercall);
+
+#endif   // __PRIV_SYSWRAP_XEN_H
+
+/*--------------------------------------------------------------------*/
+/*--- end                                                          ---*/
+/*--------------------------------------------------------------------*/
diff --git a/coregrind/m_syswrap/syswrap-linux.c b/coregrind/m_syswrap/syswrap-linux.c
index 2f1155f..22c1842 100644
--- a/coregrind/m_syswrap/syswrap-linux.c
+++ b/coregrind/m_syswrap/syswrap-linux.c
@@ -63,7 +63,7 @@
 #include "priv_types_n_macros.h"
 #include "priv_syswrap-generic.h"
 #include "priv_syswrap-linux.h"
-
+#include "priv_syswrap-xen.h"
 
 // Run a thread from beginning to end and return the thread's
 // scheduler-return-code.
@@ -5527,6 +5527,73 @@ PRE(sys_ioctl)
    case VKI_KVM_RUN:
       break;
 
+#ifdef ENABLE_XEN
+   case VKI_XEN_IOCTL_PRIVCMD_HYPERCALL: {
+      SyscallArgs harrghs;
+      struct vki_xen_privcmd_hypercall *args =
+         (struct vki_xen_privcmd_hypercall *)(ARG3);
+
+      if (!args)
+         break;
+
+      VG_(memset)(&harrghs, 0, sizeof(harrghs));
+      harrghs.sysno = args->op;
+      harrghs.arg1 = args->arg[0];
+      harrghs.arg2 = args->arg[1];
+      harrghs.arg3 = args->arg[2];
+      harrghs.arg4 = args->arg[3];
+      harrghs.arg5 = args->arg[4];
+      harrghs.arg6 = harrghs.arg7 = harrghs.arg8 = 0;
+
+      WRAPPER_PRE_NAME(xen, hypercall) (tid, layout, &harrghs, status, flags);
+
+      /* HACK. arg8 is used to return the number of hypercall
+       * arguments actually consumed! */
+      PRE_MEM_READ("hypercall", ARG3, sizeof(args->op) +
+                   ( sizeof(args->arg[0]) * harrghs.arg8 ) );
+
+      break;
+   }
+
+   case VKI_XEN_IOCTL_PRIVCMD_MMAP: {
+       struct vki_xen_privcmd_mmap *args =
+           (struct vki_xen_privcmd_mmap *)(ARG3);
+       PRE_MEM_READ("VKI_XEN_IOCTL_PRIVCMD_MMAP",
+                    (Addr)&args->num, sizeof(args->num));
+       PRE_MEM_READ("VKI_XEN_IOCTL_PRIVCMD_MMAP",
+                    (Addr)&args->dom, sizeof(args->dom));
+       PRE_MEM_READ("VKI_XEN_IOCTL_PRIVCMD_MMAP",
+                    (Addr)args->entry, sizeof(*(args->entry)) * args->num);
+      break;
+   }
+   case VKI_XEN_IOCTL_PRIVCMD_MMAPBATCH: {
+       struct vki_xen_privcmd_mmapbatch *args =
+           (struct vki_xen_privcmd_mmapbatch *)(ARG3);
+       PRE_MEM_READ("VKI_XEN_IOCTL_PRIVCMD_MMAPBATCH",
+                    (Addr)&args->num, sizeof(args->num));
+       PRE_MEM_READ("VKI_XEN_IOCTL_PRIVCMD_MMAPBATCH",
+                    (Addr)&args->dom, sizeof(args->dom));
+       PRE_MEM_READ("VKI_XEN_IOCTL_PRIVCMD_MMAPBATCH",
+                    (Addr)&args->addr, sizeof(args->addr));
+       PRE_MEM_READ("VKI_XEN_IOCTL_PRIVCMD_MMAPBATCH",
+                    (Addr)args->arr, sizeof(*(args->arr)) * args->num);
+      break;
+   }
+   case VKI_XEN_IOCTL_PRIVCMD_MMAPBATCH_V2: {
+       struct vki_xen_privcmd_mmapbatch_v2 *args =
+           (struct vki_xen_privcmd_mmapbatch_v2 *)(ARG3);
+       PRE_MEM_READ("VKI_XEN_IOCTL_PRIVCMD_MMAPBATCH_V2",
+                    (Addr)&args->num, sizeof(args->num));
+       PRE_MEM_READ("VKI_XEN_IOCTL_PRIVCMD_MMAPBATCH_V2",
+                    (Addr)&args->dom, sizeof(args->dom));
+       PRE_MEM_READ("VKI_XEN_IOCTL_PRIVCMD_MMAPBATCH_V2",
+                    (Addr)&args->addr, sizeof(args->addr));
+       PRE_MEM_READ("VKI_XEN_IOCTL_PRIVCMD_MMAPBATCH_V2",
+                    (Addr)args->arr, sizeof(*(args->arr)) * args->num);
+      break;
+   }
+#endif
+
    default:
       /* EVIOC* are variable length and return size written on success */
       switch (ARG2 & ~(_VKI_IOC_SIZEMASK << _VKI_IOC_SIZESHIFT)) {
@@ -6524,6 +6591,44 @@ POST(sys_ioctl)
    case VKI_KVM_S390_INITIAL_RESET:
       break;
 
+#ifdef ENABLE_XEN
+   case VKI_XEN_IOCTL_PRIVCMD_HYPERCALL: {
+      SyscallArgs harrghs;
+      struct vki_xen_privcmd_hypercall *args =
+         (struct vki_xen_privcmd_hypercall *)(ARG3);
+
+      if (!args)
+         break;
+
+      VG_(memset)(&harrghs, 0, sizeof(harrghs));
+      harrghs.sysno = args->op;
+      harrghs.arg1 = args->arg[0];
+      harrghs.arg2 = args->arg[1];
+      harrghs.arg3 = args->arg[2];
+      harrghs.arg4 = args->arg[3];
+      harrghs.arg5 = args->arg[4];
+      harrghs.arg6 = harrghs.arg7 = harrghs.arg8 = 0;
+
+      WRAPPER_POST_NAME(xen, hypercall) (tid, &harrghs, status);
+      break;
+   };
+
+   case VKI_XEN_IOCTL_PRIVCMD_MMAP:
+      break;
+   case VKI_XEN_IOCTL_PRIVCMD_MMAPBATCH: {
+       struct vki_xen_privcmd_mmapbatch *args =
+           (struct vki_xen_privcmd_mmapbatch *)(ARG3);
+       POST_MEM_WRITE((Addr)args->arr, sizeof(*(args->arr)) * args->num);
+      }
+      break;
+   case VKI_XEN_IOCTL_PRIVCMD_MMAPBATCH_V2: {
+       struct vki_xen_privcmd_mmapbatch_v2 *args =
+           (struct vki_xen_privcmd_mmapbatch_v2 *)(ARG3);
+       POST_MEM_WRITE((Addr)args->err, sizeof(*(args->err)) * args->num);
+      }
+      break;
+#endif
+
    default:
       /* EVIOC* are variable length and return size written on success */
       switch (ARG2 & ~(_VKI_IOC_SIZEMASK << _VKI_IOC_SIZESHIFT)) {
diff --git a/coregrind/m_syswrap/syswrap-xen.c b/coregrind/m_syswrap/syswrap-xen.c
new file mode 100644
index 0000000..00192bf
--- /dev/null
+++ b/coregrind/m_syswrap/syswrap-xen.c
@@ -0,0 +1,1023 @@
+
+/*--------------------------------------------------------------------*/
+/*--- Xen Hypercalls                                 syswrap-xen.c ---*/
+/*--------------------------------------------------------------------*/
+
+/*
+   This file is part of Valgrind, a dynamic binary instrumentation
+   framework.
+
+   Copyright (C) 2012 Citrix Systems
+      ian.campbell@citrix.com
+
+   This program is free software; you can redistribute it and/or
+   modify it under the terms of the GNU General Public License as
+   published by the Free Software Foundation; either version 2 of the
+   License, or (at your option) any later version.
+
+   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.
+
+   The GNU General Public License is contained in the file COPYING.
+*/
+
+#include "pub_core_basics.h"
+#include "pub_core_vki.h"
+#include "pub_core_vkiscnums.h"
+#include "pub_core_libcsetjmp.h"   // to keep _threadstate.h happy
+#include "pub_core_threadstate.h"
+#include "pub_core_aspacemgr.h"
+#include "pub_core_debuginfo.h"    // VG_(di_notify_*)
+#include "pub_core_transtab.h"     // VG_(discard_translations)
+#include "pub_core_xarray.h"
+#include "pub_core_clientstate.h"
+#include "pub_core_debuglog.h"
+#include "pub_core_libcbase.h"
+#include "pub_core_libcassert.h"
+#include "pub_core_libcfile.h"
+#include "pub_core_libcprint.h"
+#include "pub_core_libcproc.h"
+#include "pub_core_libcsignal.h"
+#include "pub_core_mallocfree.h"
+#include "pub_core_tooliface.h"
+#include "pub_core_options.h"
+#include "pub_core_scheduler.h"
+#include "pub_core_signals.h"
+#include "pub_core_syscall.h"
+#include "pub_core_syswrap.h"
+#include "pub_core_stacktrace.h"    // For VG_(get_and_pp_StackTrace)()
+
+#include "priv_types_n_macros.h"
+#include "priv_syswrap-generic.h"
+#include "priv_syswrap-xen.h"
+
+#include <stdint.h>
+
+#define __XEN_TOOLS__
+
+#include <xen/xen.h>
+#include <xen/sysctl.h>
+#include <xen/domctl.h>
+#include <xen/memory.h>
+#include <xen/event_channel.h>
+#include <xen/version.h>
+
+#include <xen/hvm/hvm_op.h>
+
+#define PRE(name) static DEFN_PRE_TEMPLATE(xen, name)
+#define POST(name) static DEFN_POST_TEMPLATE(xen, name)
+
+static void bad_subop ( ThreadId              tid,
+                        SyscallArgLayout*     layout,
+                        /*MOD*/SyscallArgs*   args,
+                        /*OUT*/SyscallStatus* status,
+                        /*OUT*/UWord*         flags,
+                        const char*           hypercall,
+                        UWord                 subop)
+{
+   VG_(dmsg)("WARNING: unhandled %s subop: %ld\n",
+             hypercall, subop);
+   if (VG_(clo_verbosity) > 1) {
+      VG_(get_and_pp_StackTrace)(tid, VG_(clo_backtrace_size));
+   }
+   VG_(dmsg)("You may be able to write your own handler.\n");
+   VG_(dmsg)("Read the file README_MISSING_SYSCALL_OR_IOCTL.\n");
+   VG_(dmsg)("Nevertheless we consider this a bug.  Please report\n");
+   VG_(dmsg)("it at http://valgrind.org/support/bug_reports.html &\n");
+   VG_(dmsg)("http://wiki.xen.org/wiki/Reporting_Bugs_against_Xen.\n");
+
+   SET_STATUS_Failure(VKI_ENOSYS);
+}
+
+PRE(memory_op)
+{
+   PRINT("__HYPERVISOR_memory_op ( %ld, %lx )", ARG1, ARG2);
+
+   switch (ARG1) {
+   case XENMEM_set_memory_map: {
+      xen_foreign_memory_map_t *arg =
+         (xen_foreign_memory_map_t *)(unsigned int)ARG2;
+      PRE_MEM_READ("XENMEM_set_memory_map",
+                   (Addr)&arg->domid, sizeof(arg->domid));
+      PRE_MEM_READ("XENMEM_set_memory_map",
+                   (Addr)&arg->map, sizeof(arg->map));
+      break;
+   }
+   case XENMEM_increase_reservation:
+   case XENMEM_decrease_reservation:
+   case XENMEM_populate_physmap: {
+      struct xen_memory_reservation *memory_reservation =
+         (struct xen_memory_reservation *)(unsigned int)ARG2;
+      char *which;
+
+      switch (ARG1) {
+      case XENMEM_increase_reservation:
+         which = "XENMEM_increase_reservation";
+         break;
+      case XENMEM_decrease_reservation:
+         which = "XENMEM_decrease_reservation";
+         PRE_MEM_READ(which,
+                      (Addr)memory_reservation->extent_start.p,
+                      sizeof(xen_pfn_t) * memory_reservation->nr_extents);
+      case XENMEM_populate_physmap:
+         which = "XENMEM_populate_physmap";
+         PRE_MEM_READ(which,
+                      (Addr)memory_reservation->extent_start.p,
+                      sizeof(xen_pfn_t) * memory_reservation->nr_extents);
+         break;
+      default:
+         which = "XENMEM_unknown";
+         break;
+      }
+
+      PRE_MEM_READ(which,
+                   (Addr)&memory_reservation->extent_start,
+                   sizeof(memory_reservation->extent_start));
+      PRE_MEM_READ(which,
+                   (Addr)&memory_reservation->nr_extents,
+                   sizeof(memory_reservation->nr_extents));
+      PRE_MEM_READ(which,
+                   (Addr)&memory_reservation->extent_order,
+                   sizeof(memory_reservation->extent_order));
+      PRE_MEM_READ(which,
+                   (Addr)&memory_reservation->mem_flags,
+                   sizeof(memory_reservation->mem_flags));
+      PRE_MEM_READ(which,
+                   (Addr)&memory_reservation->domid,
+                   sizeof(memory_reservation->domid));
+      break;
+   }
+
+   default:
+      bad_subop(tid, layout, arrghs, status, flags,
+                "__HYPERVISOR_memory_op", ARG1);
+      break;
+   }
+}
+
+PRE(mmuext_op)
+{
+   mmuext_op_t *ops = (void *)(unsigned int)ARG1;
+   unsigned int i, nr = ARG2;
+
+
+   for (i=0; i<nr; i++) {
+      mmuext_op_t *op = ops + i;
+      PRE_MEM_READ("__HYPERVISOR_MMUEXT_OP",
+                   (Addr)&op->cmd, sizeof(op->cmd));
+      switch(op->cmd) {
+      case MMUEXT_PIN_L1_TABLE:
+      case MMUEXT_PIN_L2_TABLE:
+      case MMUEXT_PIN_L3_TABLE:
+      case MMUEXT_PIN_L4_TABLE:
+      case MMUEXT_UNPIN_TABLE:
+      case MMUEXT_NEW_BASEPTR:
+      case MMUEXT_CLEAR_PAGE:
+      case MMUEXT_COPY_PAGE:
+      case MMUEXT_MARK_SUPER:
+      case MMUEXT_UNMARK_SUPER:
+         PRE_MEM_READ("__HYPERVISOR_MMUEXT_OP arg1.mfn",
+                      (Addr)&op->arg1.mfn,
+                      sizeof(op->arg1.mfn));
+         break;
+
+      case MMUEXT_INVLPG_LOCAL:
+      case MMUEXT_INVLPG_ALL:
+      case MMUEXT_SET_LDT:
+         PRE_MEM_READ("__HYPERVISOR_MMUEXT_OP arg1.mfn",
+                      (Addr)&op->arg1.linear_addr,
+                      sizeof(op->arg1.linear_addr));
+         break;
+
+      case MMUEXT_TLB_FLUSH_LOCAL:
+      case MMUEXT_TLB_FLUSH_MULTI:
+      case MMUEXT_INVLPG_MULTI:
+      case MMUEXT_TLB_FLUSH_ALL:
+      case MMUEXT_FLUSH_CACHE:
+      case MMUEXT_NEW_USER_BASEPTR:
+      case MMUEXT_FLUSH_CACHE_GLOBAL:
+         /* None */
+         break;
+      }
+
+      switch(op->cmd) {
+      case MMUEXT_SET_LDT:
+         PRE_MEM_READ("__HYPERVISOR_MMUEXT_OP arg2.nr_ents",
+                      (Addr)&op->arg2.nr_ents,
+                      sizeof(op->arg2.nr_ents));
+         break;
+
+      case MMUEXT_TLB_FLUSH_MULTI:
+      case MMUEXT_INVLPG_MULTI:
+         /* How many??? */
+         PRE_MEM_READ("__HYPERVISOR_MMUEXT_OP arg2.vcpumask",
+                      (Addr)&op->arg2.vcpumask,
+                      sizeof(op->arg2.vcpumask));
+         break;
+
+      case MMUEXT_COPY_PAGE:
+         PRE_MEM_READ("__HYPERVISOR_MMUEXT_OP arg2.src_mfn",
+                      (Addr)&op->arg2.src_mfn,
+                      sizeof(op->arg2.src_mfn));
+         break;
+
+      case MMUEXT_PIN_L1_TABLE:
+      case MMUEXT_PIN_L2_TABLE:
+      case MMUEXT_PIN_L3_TABLE:
+      case MMUEXT_PIN_L4_TABLE:
+      case MMUEXT_UNPIN_TABLE:
+      case MMUEXT_NEW_BASEPTR:
+      case MMUEXT_TLB_FLUSH_LOCAL:
+      case MMUEXT_INVLPG_LOCAL:
+      case MMUEXT_TLB_FLUSH_ALL:
+      case MMUEXT_INVLPG_ALL:
+      case MMUEXT_FLUSH_CACHE:
+      case MMUEXT_NEW_USER_BASEPTR:
+      case MMUEXT_CLEAR_PAGE:
+      case MMUEXT_FLUSH_CACHE_GLOBAL:
+      case MMUEXT_MARK_SUPER:
+      case MMUEXT_UNMARK_SUPER:
+         /* None */
+         break;
+      }
+   }
+}
+
+static void pre_evtchn_op(ThreadId tid,
+                          SyscallArgLayout*     layout,
+                          /*MOD*/SyscallArgs*   arrghs,
+                          /*OUT*/SyscallStatus* status,
+                          /*OUT*/UWord*         flags,
+                          __vki_u32 cmd, void *arg, int compat)
+{
+   PRINT("__HYPERVISOR_event_channel_op%s ( %d, %p )",
+         compat ? "_compat" : "", cmd, arg);
+
+   switch (cmd) {
+   case EVTCHNOP_alloc_unbound: {
+      struct evtchn_alloc_unbound *alloc_unbound = arg;
+      PRE_MEM_READ("EVTCHNOP_alloc_unbound",
+                   (Addr)&alloc_unbound->dom, sizeof(alloc_unbound->dom));
+      PRE_MEM_READ("EVTCHNOP_alloc_unbound",
+                   (Addr)&alloc_unbound->remote_dom,
+                   sizeof(alloc_unbound->remote_dom));
+      break;
+   }
+   default:
+      if ( compat )
+         bad_subop(tid, layout, arrghs, status, flags,
+                   "__HYPERVISOR_event_channel_op_compat", cmd);
+      else
+         bad_subop(tid, layout, arrghs, status, flags,
+                   "__HYPERVISOR_event_channel_op", cmd);
+      break;
+   }
+}
+
+PRE(evtchn_op)
+{
+   pre_evtchn_op(tid, layout, arrghs, status, flags,
+                 ARG1, (void *)(unsigned int)ARG2, 0);
+}
+
+PRE(evtchn_op_compat)
+{
+   struct evtchn_op *evtchn = (struct evtchn_op *)(unsigned int)ARG1;
+   PRE_MEM_READ("__HYPERVISOR_event_channel_op_compat",
+                ARG1, sizeof(*evtchn));
+
+   pre_evtchn_op(tid, layout, arrghs, status, flags,
+                 evtchn->cmd, &evtchn->u, 1);
+}
+
+PRE(xen_version)
+{
+   PRINT("__HYPERVISOR_xen_version ( %ld, %lx )", ARG1, ARG2);
+
+   switch (ARG1) {
+   case XENVER_version:
+   case XENVER_extraversion:
+   case XENVER_compile_info:
+   case XENVER_capabilities:
+   case XENVER_changeset:
+   case XENVER_platform_parameters:
+   case XENVER_get_features:
+   case XENVER_pagesize:
+   case XENVER_guest_handle:
+   case XENVER_commandline:
+      /* No inputs */
+      break;
+
+   default:
+      bad_subop(tid, layout, arrghs, status, flags,
+                "__HYPERVISOR_xen_version", ARG1);
+      break;
+   }
+}
+
+PRE(grant_table_op)
+{
+   PRINT("__HYPERVISOR_grant_table_op ( %ld, 0x%lx, %ld )", ARG1, ARG2, ARG3);
+   switch (ARG1) {
+   case GNTTABOP_setup_table: {
+      struct gnttab_setup_table *gst = (void *)(intptr_t)ARG2;
+      PRE_MEM_READ("GNTTABOP_setup_table", (Addr)&gst->dom, sizeof(gst->dom));
+      PRE_MEM_READ("GNTTABOP_setup_table",
+                   (Addr)&gst->nr_frames, sizeof(gst->nr_frames));
+      break;
+   }
+   default:
+      bad_subop(tid, layout, arrghs, status, flags,
+                "__HYPERVISOR_grant_table_op", ARG1);
+      break;
+   }
+}
+
+PRE(sysctl) {
+   struct xen_sysctl *sysctl = (struct xen_sysctl *)(unsigned int)ARG1;
+
+   PRINT("__HYPERVISOR_sysctl ( %d )", sysctl->cmd);
+
+   /*
+    * Common part of xen_sysctl:
+    *    uint32_t cmd;
+    *    uint32_t interface_version;
+    */
+   PRE_MEM_READ("__HYPERVISOR_sysctl", ARG1,
+                sizeof(uint32_t) + sizeof(uint32_t));
+
+   if (!sysctl || sysctl->interface_version != XEN_SYSCTL_INTERFACE_VERSION)
+      /* BUG ? */
+      return;
+
+#define __PRE_XEN_SYSCTL_READ(_sysctl, _union, _field)  \
+      PRE_MEM_READ("XEN_SYSCTL_" # _sysctl,             \
+                   (Addr)&sysctl->u._union._field,      \
+                   sizeof(sysctl->u._union._field))
+#define PRE_XEN_SYSCTL_READ(_sysctl, _field) \
+      __PRE_XEN_SYSCTL_READ(_sysctl, _sysctl, _field)
+
+   switch (sysctl->cmd) {
+   case XEN_SYSCTL_getdomaininfolist:
+      PRE_XEN_SYSCTL_READ(getdomaininfolist, first_domain);
+      PRE_XEN_SYSCTL_READ(getdomaininfolist, max_domains);
+      PRE_XEN_SYSCTL_READ(getdomaininfolist, buffer);
+      break;
+
+   case XEN_SYSCTL_cpupool_op:
+      PRE_XEN_SYSCTL_READ(cpupool_op, op);
+
+      switch(sysctl->u.cpupool_op.op) {
+      case XEN_SYSCTL_CPUPOOL_OP_CREATE:
+      case XEN_SYSCTL_CPUPOOL_OP_DESTROY:
+      case XEN_SYSCTL_CPUPOOL_OP_INFO:
+      case XEN_SYSCTL_CPUPOOL_OP_ADDCPU:
+      case XEN_SYSCTL_CPUPOOL_OP_RMCPU:
+      case XEN_SYSCTL_CPUPOOL_OP_MOVEDOMAIN:
+         PRE_XEN_SYSCTL_READ(cpupool_op, cpupool_id);
+      }
+
+      if (sysctl->u.cpupool_op.op == XEN_SYSCTL_CPUPOOL_OP_CREATE)
+         PRE_XEN_SYSCTL_READ(cpupool_op, sched_id);
+
+      if (sysctl->u.cpupool_op.op == XEN_SYSCTL_CPUPOOL_OP_MOVEDOMAIN)
+         PRE_XEN_SYSCTL_READ(cpupool_op, domid);
+
+      if (sysctl->u.cpupool_op.op == XEN_SYSCTL_CPUPOOL_OP_ADDCPU ||
+          sysctl->u.cpupool_op.op == XEN_SYSCTL_CPUPOOL_OP_RMCPU)
+         PRE_XEN_SYSCTL_READ(cpupool_op, cpu);
+
+      break;
+
+   case XEN_SYSCTL_physinfo:
+      /* No input params */
+      break;
+
+   case XEN_SYSCTL_topologyinfo:
+      PRE_XEN_SYSCTL_READ(topologyinfo, max_cpu_index);
+      PRE_XEN_SYSCTL_READ(topologyinfo, cpu_to_core);
+      PRE_XEN_SYSCTL_READ(topologyinfo, cpu_to_socket);
+      PRE_XEN_SYSCTL_READ(topologyinfo, cpu_to_node);
+      break;
+
+   case XEN_SYSCTL_numainfo:
+      PRE_XEN_SYSCTL_READ(numainfo, max_node_index);
+      PRE_XEN_SYSCTL_READ(numainfo, node_to_memsize);
+      PRE_XEN_SYSCTL_READ(numainfo, node_to_memfree);
+      PRE_XEN_SYSCTL_READ(numainfo, node_to_node_distance);
+      break;
+
+   default:
+      bad_subop(tid, layout, arrghs, status, flags,
+                "__HYPERVISOR_sysctl", sysctl->cmd);
+      break;
+   }
+#undef PRE_XEN_SYSCTL_READ
+#undef __PRE_XEN_SYSCTL_READ
+}
+
+PRE(domctl)
+{
+   struct xen_domctl *domctl = (struct xen_domctl *)(unsigned int)ARG1;
+
+   PRINT("__HYPERVISOR_domctl ( %d ) on dom%d", domctl->cmd, domctl->domain);
+
+   /*
+    * Common part of xen_domctl:
+    *    uint32_t cmd;
+    *    uint32_t interface_version;
+    *    domid_t  domain;
+    */
+   PRE_MEM_READ("__HYPERVISOR_domctl", ARG1,
+                sizeof(uint32_t) + sizeof(uint32_t) + sizeof(domid_t));
+
+   if (!domctl || domctl->interface_version != XEN_DOMCTL_INTERFACE_VERSION)
+      /* BUG ? */
+      return;
+
+#define __PRE_XEN_DOMCTL_READ(_domctl, _union, _field)  \
+      PRE_MEM_READ("XEN_DOMCTL_" # _domctl,             \
+                   (Addr)&domctl->u._union._field,      \
+                   sizeof(domctl->u._union._field))
+#define PRE_XEN_DOMCTL_READ(_domctl, _field) \
+      __PRE_XEN_DOMCTL_READ(_domctl, _domctl, _field)
+
+   switch (domctl->cmd) {
+   case XEN_DOMCTL_destroydomain:
+   case XEN_DOMCTL_pausedomain:
+   case XEN_DOMCTL_max_vcpus:
+   case XEN_DOMCTL_get_address_size:
+   case XEN_DOMCTL_gettscinfo:
+   case XEN_DOMCTL_getdomaininfo:
+   case XEN_DOMCTL_unpausedomain:
+      /* No input fields. */
+      break;
+
+   case XEN_DOMCTL_createdomain:
+      PRE_XEN_DOMCTL_READ(createdomain, ssidref);
+      PRE_XEN_DOMCTL_READ(createdomain, handle);
+      PRE_XEN_DOMCTL_READ(createdomain, flags);
+      break;
+
+   case XEN_DOMCTL_max_mem:
+      PRE_XEN_DOMCTL_READ(max_mem, max_memkb);
+      break;
+
+   case XEN_DOMCTL_set_address_size:
+      __PRE_XEN_DOMCTL_READ(set_address_size, address_size, size);
+      break;
+
+   case XEN_DOMCTL_settscinfo:
+      __PRE_XEN_DOMCTL_READ(settscinfo, tsc_info, info.tsc_mode);
+      __PRE_XEN_DOMCTL_READ(settscinfo, tsc_info, info.gtsc_khz);
+      __PRE_XEN_DOMCTL_READ(settscinfo, tsc_info, info.incarnation);
+      __PRE_XEN_DOMCTL_READ(settscinfo, tsc_info, info.elapsed_nsec);
+      break;
+
+   case XEN_DOMCTL_hypercall_init:
+      PRE_XEN_DOMCTL_READ(hypercall_init, gmfn);
+      break;
+
+   case XEN_DOMCTL_getvcpuinfo:
+      PRE_XEN_DOMCTL_READ(getvcpuinfo, vcpu);
+      break;
+
+   case XEN_DOMCTL_scheduler_op:
+      PRE_XEN_DOMCTL_READ(scheduler_op, sched_id);
+      PRE_XEN_DOMCTL_READ(scheduler_op, cmd);
+      if ( domctl->u.scheduler_op.cmd == XEN_DOMCTL_SCHEDOP_putinfo ) {
+         switch(domctl->u.scheduler_op.sched_id) {
+         case XEN_SCHEDULER_SEDF:
+            PRE_XEN_DOMCTL_READ(scheduler_op, u.sedf.period);
+            PRE_XEN_DOMCTL_READ(scheduler_op, u.sedf.slice);
+            PRE_XEN_DOMCTL_READ(scheduler_op, u.sedf.latency);
+            PRE_XEN_DOMCTL_READ(scheduler_op, u.sedf.extratime);
+            PRE_XEN_DOMCTL_READ(scheduler_op, u.sedf.weight);
+            break;
+         case XEN_SCHEDULER_CREDIT:
+            PRE_XEN_DOMCTL_READ(scheduler_op, u.credit.weight);
+            PRE_XEN_DOMCTL_READ(scheduler_op, u.credit.cap);
+            break;
+         case XEN_SCHEDULER_CREDIT2:
+            PRE_XEN_DOMCTL_READ(scheduler_op, u.credit2.weight);
+            break;
+         case XEN_SCHEDULER_ARINC653:
+            break;
+         }
+      }
+      break;
+
+   case XEN_DOMCTL_getvcpuaffinity:
+      __PRE_XEN_DOMCTL_READ(getvcpuaffinity, vcpuaffinity, vcpu);
+      break;
+
+   case XEN_DOMCTL_setvcpuaffinity:
+      __PRE_XEN_DOMCTL_READ(setvcpuaffinity, vcpuaffinity, vcpu);
+      PRE_MEM_READ("XEN_DOMCTL_setvcpuaffinity",
+                   (Addr)domctl->u.vcpuaffinity.cpumap.bitmap.p,
+                   domctl->u.vcpuaffinity.cpumap.nr_cpus / 8);
+      break;
+
+   case XEN_DOMCTL_getvcpucontext:
+      __PRE_XEN_DOMCTL_READ(getvcpucontext, vcpucontext, vcpu);
+      break;
+
+   case XEN_DOMCTL_setvcpucontext:
+      __PRE_XEN_DOMCTL_READ(setvcpucontext, vcpucontext, vcpu);
+      __PRE_XEN_DOMCTL_READ(setvcpucontext, vcpucontext, ctxt.p);
+      break;
+
+   case XEN_DOMCTL_set_cpuid:
+      PRE_MEM_READ("XEN_DOMCTL_set_cpuid",
+                   (Addr)&domctl->u.cpuid, sizeof(domctl->u.cpuid));
+      break;
+
+   case XEN_DOMCTL_getvcpuextstate:
+      __PRE_XEN_DOMCTL_READ(getvcpuextstate, vcpuextstate, vcpu);
+      __PRE_XEN_DOMCTL_READ(getvcpuextstate, vcpuextstate, xfeature_mask);
+      __PRE_XEN_DOMCTL_READ(getvcpuextstate, vcpuextstate, size);
+      __PRE_XEN_DOMCTL_READ(getvcpuextstate, vcpuextstate, buffer);
+      break;
+
+   default:
+      bad_subop(tid, layout, arrghs, status, flags,
+                "__HYPERVISOR_domctl", domctl->cmd);
+      break;
+   }
+#undef PRE_XEN_DOMCTL_READ
+#undef __PRE_XEN_DOMCTL_READ
+}
+
+PRE(hvm_op)
+{
+   unsigned long op = ARG1;
+   void *arg = (void *)(unsigned long)ARG2;
+
+   PRINT("__HYPERVISOR_hvm_op ( %ld, %p )", op, arg);
+
+#define __PRE_XEN_HVMOP_READ(_hvm_op, _type, _field)    \
+   PRE_MEM_READ("XEN_HVMOP_" # _hvm_op,                 \
+                (Addr)&((_type*)arg)->_field,           \
+                sizeof(((_type*)arg)->_field))
+#define PRE_XEN_HVMOP_READ(_hvm_op, _field)                             \
+   __PRE_XEN_HVMOP_READ(_hvm_op, "xen_hvm_" # _hvm_op "_t", _field)
+
+   switch (op) {
+   case HVMOP_set_param:
+      __PRE_XEN_HVMOP_READ(set_param, xen_hvm_param_t, domid);
+      __PRE_XEN_HVMOP_READ(set_param, xen_hvm_param_t, index);
+      __PRE_XEN_HVMOP_READ(set_param, xen_hvm_param_t, value);
+      break;
+
+   case HVMOP_get_param:
+      __PRE_XEN_HVMOP_READ(get_param, xen_hvm_param_t, domid);
+      __PRE_XEN_HVMOP_READ(get_param, xen_hvm_param_t, index);
+      break;
+
+   default:
+      bad_subop(tid, layout, arrghs, status, flags,
+                "__HYPERVISOR_hvm_op", op);
+      break;
+   }
+#undef __PRE_XEN_HVMOP_READ
+#undef PRE_XEN_HVMOP_READ
+}
+
+POST(memory_op)
+{
+   switch (ARG1) {
+   case XENMEM_set_memory_map:
+   case XENMEM_decrease_reservation:
+      /* No outputs */
+      break;
+   case XENMEM_increase_reservation:
+   case XENMEM_populate_physmap: {
+      struct xen_memory_reservation *memory_reservation =
+         (struct xen_memory_reservation *)(unsigned int)ARG2;
+
+      POST_MEM_WRITE((Addr)memory_reservation->extent_start.p,
+                     sizeof(xen_pfn_t) * memory_reservation->nr_extents);
+      break;
+   }
+   }
+}
+
+POST(mmuext_op)
+{
+   unsigned int *pdone = (void *)(unsigned int)ARG3;
+   /* simplistic */
+   POST_MEM_WRITE((Addr)pdone, sizeof(*pdone));
+}
+
+static void post_evtchn_op(ThreadId tid, __vki_u32 cmd, void *arg, int compat)
+{
+   switch (cmd) {
+   case EVTCHNOP_alloc_unbound: {
+      struct evtchn_alloc_unbound *alloc_unbound = arg;
+      POST_MEM_WRITE((Addr)&alloc_unbound->port, sizeof(alloc_unbound->port));
+      break;
+   }
+   }
+}
+
+POST(evtchn_op)
+{
+   post_evtchn_op(tid, ARG1, (void *)(unsigned int)ARG2, 0);
+}
+
+POST(evtchn_op_compat)
+{
+   struct evtchn_op *evtchn = (struct evtchn_op *)(unsigned int)ARG1;
+   post_evtchn_op(tid, evtchn->cmd, &evtchn->u, 1);
+}
+
+POST(xen_version)
+{
+   switch (ARG1) {
+   case XENVER_version:
+      /* No outputs */
+      break;
+   case XENVER_extraversion:
+      POST_MEM_WRITE((Addr)ARG2, sizeof(xen_extraversion_t));
+      break;
+   case XENVER_compile_info:
+      POST_MEM_WRITE((Addr)ARG2, sizeof(xen_compile_info_t));
+      break;
+   case XENVER_capabilities:
+      POST_MEM_WRITE((Addr)ARG2, sizeof(xen_capabilities_info_t));
+      break;
+   case XENVER_changeset:
+      POST_MEM_WRITE((Addr)ARG2, sizeof(xen_changeset_info_t));
+      break;
+   case XENVER_platform_parameters:
+      POST_MEM_WRITE((Addr)ARG2, sizeof(xen_platform_parameters_t));
+      break;
+   case XENVER_get_features:
+      POST_MEM_WRITE((Addr)ARG2, sizeof(xen_feature_info_t));
+      break;
+   case XENVER_pagesize:
+      /* No outputs */
+      break;
+   case XENVER_guest_handle:
+      POST_MEM_WRITE((Addr)ARG2, sizeof(xen_domain_handle_t));
+      break;
+   case XENVER_commandline:
+      POST_MEM_WRITE((Addr)ARG2, sizeof(xen_commandline_t));
+      break;
+   }
+}
+
+POST(grant_table_op)
+{
+   switch (ARG1) {
+   case GNTTABOP_setup_table: {
+      struct gnttab_setup_table *gst = (void *)(uintptr_t)ARG2;
+      PRE_MEM_WRITE("GNTTABOP_setup_table",
+                    (Addr)&gst->status, sizeof(gst->status));
+      PRE_MEM_WRITE("GNTTABOP_setup_table",
+                    (Addr)gst->frame_list.p,
+                    sizeof(*gst->frame_list.p) & gst->nr_frames);
+      break;
+   }
+   }
+}
+
+POST(sysctl)
+{
+   struct xen_sysctl *sysctl = (struct xen_sysctl *)(unsigned int)ARG1;
+
+   if (!sysctl || sysctl->interface_version != XEN_SYSCTL_INTERFACE_VERSION)
+      return;
+
+#define __POST_XEN_SYSCTL_WRITE(_sysctl, _union, _field)        \
+      POST_MEM_WRITE((Addr)&sysctl->u._union._field,            \
+                     sizeof(sysctl->u._union._field))
+#define POST_XEN_SYSCTL_WRITE(_sysctl, _field) \
+      __POST_XEN_SYSCTL_WRITE(_sysctl, _sysctl, _field)
+
+   switch (sysctl->cmd) {
+   case XEN_SYSCTL_getdomaininfolist:
+      POST_XEN_SYSCTL_WRITE(getdomaininfolist, num_domains);
+      POST_MEM_WRITE((Addr)sysctl->u.getdomaininfolist.buffer.p,
+                     sizeof(xen_domctl_getdomaininfo_t)
+                     * sysctl->u.getdomaininfolist.num_domains);
+      break;
+
+   case XEN_SYSCTL_cpupool_op:
+      if (sysctl->u.cpupool_op.op == XEN_SYSCTL_CPUPOOL_OP_CREATE ||
+          sysctl->u.cpupool_op.op == XEN_SYSCTL_CPUPOOL_OP_INFO)
+         POST_XEN_SYSCTL_WRITE(cpupool_op, cpupool_id);
+      if (sysctl->u.cpupool_op.op == XEN_SYSCTL_CPUPOOL_OP_INFO) {
+         POST_XEN_SYSCTL_WRITE(cpupool_op, sched_id);
+         POST_XEN_SYSCTL_WRITE(cpupool_op, n_dom);
+      }
+      if (sysctl->u.cpupool_op.op == XEN_SYSCTL_CPUPOOL_OP_INFO ||
+          sysctl->u.cpupool_op.op == XEN_SYSCTL_CPUPOOL_OP_FREEINFO)
+         POST_XEN_SYSCTL_WRITE(cpupool_op, cpumap);
+      break;
+
+   case XEN_SYSCTL_physinfo:
+      POST_XEN_SYSCTL_WRITE(physinfo, threads_per_core);
+      POST_XEN_SYSCTL_WRITE(physinfo, cores_per_socket);
+      POST_XEN_SYSCTL_WRITE(physinfo, nr_cpus);
+      POST_XEN_SYSCTL_WRITE(physinfo, max_cpu_id);
+      POST_XEN_SYSCTL_WRITE(physinfo, nr_nodes);
+      POST_XEN_SYSCTL_WRITE(physinfo, max_node_id);
+      POST_XEN_SYSCTL_WRITE(physinfo, cpu_khz);
+      POST_XEN_SYSCTL_WRITE(physinfo, total_pages);
+      POST_XEN_SYSCTL_WRITE(physinfo, free_pages);
+      POST_XEN_SYSCTL_WRITE(physinfo, scrub_pages);
+      POST_XEN_SYSCTL_WRITE(physinfo, hw_cap[8]);
+      POST_XEN_SYSCTL_WRITE(physinfo, capabilities);
+      break;
+
+   case XEN_SYSCTL_topologyinfo:
+      POST_XEN_SYSCTL_WRITE(topologyinfo, max_cpu_index);
+      POST_MEM_WRITE((Addr)sysctl->u.topologyinfo.cpu_to_core.p,
+                     sizeof(uint32_t) * sysctl->u.topologyinfo.max_cpu_index);
+      POST_MEM_WRITE((Addr)sysctl->u.topologyinfo.cpu_to_socket.p,
+                     sizeof(uint32_t) * sysctl->u.topologyinfo.max_cpu_index);
+      POST_MEM_WRITE((Addr)sysctl->u.topologyinfo.cpu_to_node.p,
+                     sizeof(uint32_t) * sysctl->u.topologyinfo.max_cpu_index);
+      break;
+
+   case XEN_SYSCTL_numainfo:
+      POST_XEN_SYSCTL_WRITE(numainfo, max_node_index);
+      POST_MEM_WRITE((Addr)sysctl->u.numainfo.node_to_memsize.p,
+                     sizeof(uint64_t) * sysctl->u.numainfo.max_node_index);
+      POST_MEM_WRITE((Addr)sysctl->u.numainfo.node_to_memfree.p,
+                     sizeof(uint64_t) * sysctl->u.numainfo.max_node_index);
+      POST_MEM_WRITE((Addr)sysctl->u.numainfo.node_to_node_distance.p,
+                     sizeof(uint32_t) * sysctl->u.numainfo.max_node_index);
+   }
+#undef POST_XEN_SYSCTL_WRITE
+#undef __POST_XEN_SYSCTL_WRITE
+}
+
+POST(domctl){
+   struct xen_domctl *domctl = (struct xen_domctl *)(unsigned int)ARG1;
+
+   if (!domctl || domctl->interface_version != XEN_DOMCTL_INTERFACE_VERSION)
+      return;
+
+#define __POST_XEN_DOMCTL_WRITE(_domctl, _union, _field)        \
+   POST_MEM_WRITE((Addr)&domctl->u._union._field,               \
+                  sizeof(domctl->u._union._field));
+#define POST_XEN_DOMCTL_WRITE(_domctl, _field)          \
+   __POST_XEN_DOMCTL_WRITE(_domctl, _domctl, _field)
+
+   switch (domctl->cmd) {
+   case XEN_DOMCTL_createdomain:
+   case XEN_DOMCTL_destroydomain:
+   case XEN_DOMCTL_pausedomain:
+   case XEN_DOMCTL_max_mem:
+   case XEN_DOMCTL_set_address_size:
+   case XEN_DOMCTL_settscinfo:
+   case XEN_DOMCTL_hypercall_init:
+   case XEN_DOMCTL_setvcpuaffinity:
+   case XEN_DOMCTL_setvcpucontext:
+   case XEN_DOMCTL_set_cpuid:
+   case XEN_DOMCTL_unpausedomain:
+      /* No output fields */
+      break;
+
+   case XEN_DOMCTL_max_vcpus:
+      POST_XEN_DOMCTL_WRITE(max_vcpus, max);
+
+   case XEN_DOMCTL_get_address_size:
+      __POST_XEN_DOMCTL_WRITE(get_address_size, address_size, size);
+      break;
+
+   case XEN_DOMCTL_gettscinfo:
+      __POST_XEN_DOMCTL_WRITE(settscinfo, tsc_info, info.tsc_mode);
+      __POST_XEN_DOMCTL_WRITE(settscinfo, tsc_info, info.gtsc_khz);
+      __POST_XEN_DOMCTL_WRITE(settscinfo, tsc_info, info.incarnation);
+      __POST_XEN_DOMCTL_WRITE(settscinfo, tsc_info, info.elapsed_nsec);
+      break;
+
+   case XEN_DOMCTL_getvcpuinfo:
+      POST_XEN_DOMCTL_WRITE(getvcpuinfo, online);
+      POST_XEN_DOMCTL_WRITE(getvcpuinfo, blocked);
+      POST_XEN_DOMCTL_WRITE(getvcpuinfo, running);
+      POST_XEN_DOMCTL_WRITE(getvcpuinfo, cpu_time);
+      POST_XEN_DOMCTL_WRITE(getvcpuinfo, cpu);
+      break;
+
+   case XEN_DOMCTL_scheduler_op:
+      if ( domctl->u.scheduler_op.cmd == XEN_DOMCTL_SCHEDOP_getinfo ) {
+         switch(domctl->u.scheduler_op.sched_id) {
+         case XEN_SCHEDULER_SEDF:
+            POST_XEN_DOMCTL_WRITE(scheduler_op, u.sedf.period);
+            POST_XEN_DOMCTL_WRITE(scheduler_op, u.sedf.slice);
+            POST_XEN_DOMCTL_WRITE(scheduler_op, u.sedf.latency);
+            POST_XEN_DOMCTL_WRITE(scheduler_op, u.sedf.extratime);
+            POST_XEN_DOMCTL_WRITE(scheduler_op, u.sedf.weight);
+            break;
+         case XEN_SCHEDULER_CREDIT:
+            POST_XEN_DOMCTL_WRITE(scheduler_op, u.credit.weight);
+            POST_XEN_DOMCTL_WRITE(scheduler_op, u.credit.cap);
+            break;
+         case XEN_SCHEDULER_CREDIT2:
+            POST_XEN_DOMCTL_WRITE(scheduler_op, u.credit2.weight);
+            break;
+         case XEN_SCHEDULER_ARINC653:
+            break;
+         }
+      }
+      break;
+
+   case XEN_DOMCTL_getvcpuaffinity:
+      POST_MEM_WRITE((Addr)domctl->u.vcpuaffinity.cpumap.bitmap.p,
+                     domctl->u.vcpuaffinity.cpumap.nr_cpus / 8);
+      break;
+
+   case XEN_DOMCTL_getdomaininfo:
+      POST_XEN_DOMCTL_WRITE(getdomaininfo, domain);
+      POST_XEN_DOMCTL_WRITE(getdomaininfo, flags);
+      POST_XEN_DOMCTL_WRITE(getdomaininfo, tot_pages);
+      POST_XEN_DOMCTL_WRITE(getdomaininfo, max_pages);
+      POST_XEN_DOMCTL_WRITE(getdomaininfo, shr_pages);
+      POST_XEN_DOMCTL_WRITE(getdomaininfo, shared_info_frame);
+      POST_XEN_DOMCTL_WRITE(getdomaininfo, cpu_time);
+      POST_XEN_DOMCTL_WRITE(getdomaininfo, nr_online_vcpus);
+      POST_XEN_DOMCTL_WRITE(getdomaininfo, max_vcpu_id);
+      POST_XEN_DOMCTL_WRITE(getdomaininfo, ssidref);
+      POST_XEN_DOMCTL_WRITE(getdomaininfo, handle);
+      POST_XEN_DOMCTL_WRITE(getdomaininfo, cpupool);
+      break;
+
+   case XEN_DOMCTL_getvcpucontext:
+      __POST_XEN_DOMCTL_WRITE(getvcpucontext, vcpucontext, ctxt.p);
+      break;
+
+   case XEN_DOMCTL_getvcpuextstate:
+      __POST_XEN_DOMCTL_WRITE(getvcpuextstate, vcpuextstate, xfeature_mask);
+      __POST_XEN_DOMCTL_WRITE(getvcpuextstate, vcpuextstate, size);
+      POST_MEM_WRITE((Addr)domctl->u.vcpuextstate.buffer.p,
+                     domctl->u.vcpuextstate.size);
+      break;
+
+   }
+#undef POST_XEN_DOMCTL_WRITE
+#undef __POST_XEN_DOMCTL_WRITE
+}
+
+POST(hvm_op)
+{
+   unsigned long op = ARG1;
+   void *arg = (void *)(unsigned long)ARG2;
+
+#define __POST_XEN_HVMOP_WRITE(_hvm_op, _type, _field)  \
+      POST_MEM_WRITE((Addr)&((_type*)arg)->_field,      \
+                     sizeof(((_type*)arg)->_field))
+#define POST_XEN_HVMOP_WRITE(_hvm_op, _field) \
+      __PRE_XEN_HVMOP_READ(_hvm_op, "xen_hvm_" # _hvm_op "_t", _field)
+
+   switch (op) {
+   case HVMOP_set_param:
+      /* No output paramters */
+      break;
+
+   case HVMOP_get_param:
+      __POST_XEN_HVMOP_WRITE(get_param, xen_hvm_param_t, value);
+      break;
+   }
+#undef __POST_XEN_HVMOP_WRITE
+#undef POST_XEN_HVMOP_WRITE
+}
+
+typedef
+   struct {
+      SyscallTableEntry entry;
+      int nr_args;
+   }
+   XenHypercallTableEntry;
+
+#define HYPX_(const, name, nr_args) \
+   [const] = { { vgSysWrap_xen_##name##_before, NULL }, nr_args }
+#define HYPXY(const, name, nr_args)                     \
+   [const] = { { vgSysWrap_xen_##name##_before,         \
+                 vgSysWrap_xen_##name##_after },        \
+               nr_args }
+
+static XenHypercallTableEntry hypercall_table[] = {
+   //    __HYPERVISOR_set_trap_table                                  // 0
+   //    __HYPERVISOR_mmu_update                                      // 1
+   //    __HYPERVISOR_set_gdt                                         // 2
+   //    __HYPERVISOR_stack_switch                                    // 3
+   //    __HYPERVISOR_set_callbacks                                   // 4
+
+   //    __HYPERVISOR_fpu_taskswitch                                  // 5
+   //    __HYPERVISOR_sched_op_compat                                 // 6
+   //    __HYPERVISOR_platform_op                                     // 7
+   //    __HYPERVISOR_set_debugreg                                    // 8
+   //    __HYPERVISOR_get_debugreg                                    // 9
+
+   //    __HYPERVISOR_update_descriptor                               // 10
+   //                                                                 // 11
+   HYPXY(__HYPERVISOR_memory_op,               memory_op,         2), // 12
+   //    __HYPERVISOR_multicall                                       // 13
+   //    __HYPERVISOR_update_va_mapping                               // 14
+
+   //    __HYPERVISOR_set_timer_op                                    // 15
+   HYPXY(__HYPERVISOR_event_channel_op_compat, evtchn_op_compat,  1), // 16
+   HYPXY(__HYPERVISOR_xen_version,             xen_version,       2), // 17
+   //    __HYPERVISOR_console_io                                      // 18
+   //    __HYPERVISOR_physdev_op_compat                               // 19
+
+   HYPXY(__HYPERVISOR_grant_table_op,          grant_table_op,    3), // 20
+   //    __HYPERVISOR_vm_assist                                       // 21
+   //    __HYPERVISOR_update_va_mapping_otherdomain                   // 22
+   //    __HYPERVISOR_iret,                    iret                   // 23
+   //    __HYPERVISOR_vcpu_op,                 vcpu_op                // 24
+
+   //    __HYPERVISOR_set_segment_base                                // 25
+   HYPXY(__HYPERVISOR_mmuext_op,               mmuext_op,         2), // 26
+   //    __HYPERVISOR_xsm_op                                          // 27
+   //    __HYPERVISOR_nmi_op                                          // 28
+   //    __HYPERVISOR_sched_op                                        // 29
+
+   //    __HYPERVISOR_callback_op                                     // 30
+   //    __HYPERVISOR_xenoprof_op                                     // 31
+   HYPXY(__HYPERVISOR_event_channel_op,        evtchn_op,         2), // 32
+   //    __HYPERVISOR_physdev_op                                      // 33
+   HYPXY(__HYPERVISOR_hvm_op,                  hvm_op,            2), // 34
+
+   HYPXY(__HYPERVISOR_sysctl,                  sysctl,            1), // 35
+   HYPXY(__HYPERVISOR_domctl,                  domctl,            1), // 36
+   //    __HYPERVISOR_kexec_op                                        // 37
+   //    __HYPERVISOR_tmem_op                                         // 38
+};
+
+static void bad_before ( ThreadId              tid,
+                         SyscallArgLayout*     layout,
+                         /*MOD*/SyscallArgs*   args,
+                         /*OUT*/SyscallStatus* status,
+                         /*OUT*/UWord*         flags )
+{
+   VG_(dmsg)("WARNING: unhandled hypercall: %s\n",
+      VG_SYSNUM_STRING_EXTRA(args->sysno));
+   if (VG_(clo_verbosity) > 1) {
+      VG_(get_and_pp_StackTrace)(tid, VG_(clo_backtrace_size));
+   }
+   VG_(dmsg)("You may be able to write your own handler.\n");
+   VG_(dmsg)("Read the file README_MISSING_SYSCALL_OR_IOCTL.\n");
+   VG_(dmsg)("Nevertheless we consider this a bug.  Please report\n");
+   VG_(dmsg)("it at http://valgrind.org/support/bug_reports.html &\n");
+   VG_(dmsg)("http://wiki.xen.org/wiki/Reporting_Bugs_against_Xen.\n");
+
+   SET_STATUS_Failure(VKI_ENOSYS);
+}
+
+static XenHypercallTableEntry bad_hyper =
+{ { bad_before, NULL }, 0 };
+
+static XenHypercallTableEntry* ML_(get_xen_hypercall_entry) ( UInt sysno )
+{
+   XenHypercallTableEntry *ret = &bad_hyper;
+
+   const UInt hypercall_table_size
+      = sizeof(hypercall_table) / sizeof(hypercall_table[0]);
+
+   /* Is it in the contiguous initial section of the table? */
+   if (sysno < hypercall_table_size) {
+      XenHypercallTableEntry* ent = &hypercall_table[sysno];
+      if (ent->entry.before != NULL)
+         ret = ent;
+   }
+
+   /* Can't find a wrapper */
+   return ret;
+}
+
+DEFN_PRE_TEMPLATE(xen, hypercall)
+{
+   XenHypercallTableEntry *ent = ML_(get_xen_hypercall_entry)(SYSNO);
+
+   /* Return number of arguments consumed */
+   ARG8 = ent->nr_args;
+
+   vg_assert(ent);
+   vg_assert(ent->entry.before);
+   (ent->entry.before)( tid, layout, arrghs, status, flags );
+
+}
+
+DEFN_POST_TEMPLATE(xen, hypercall)
+{
+   XenHypercallTableEntry *ent = ML_(get_xen_hypercall_entry)(SYSNO);
+
+   /* Return number of arguments consumed */
+   ARG8 = ent->nr_args;
+
+   vg_assert(ent);
+   if (ent->entry.after)
+      (ent->entry.after)( tid, arrghs, status );
+}
diff --git a/include/Makefile.am b/include/Makefile.am
index ade27c2..f1a3443 100644
--- a/include/Makefile.am
+++ b/include/Makefile.am
@@ -64,4 +64,5 @@ nobase_pkginclude_HEADERS = \
 	vki/vki-scnums-arm-linux.h	\
 	vki/vki-scnums-s390x-linux.h	\
 	vki/vki-scnums-mips32-linux.h	\
-	vki/vki-scnums-darwin.h
+	vki/vki-scnums-darwin.h		\
+	vki/vki-xen.h
diff --git a/include/pub_tool_vki.h b/include/pub_tool_vki.h
index a0996f9..6598106 100644
--- a/include/pub_tool_vki.h
+++ b/include/pub_tool_vki.h
@@ -47,6 +47,7 @@
 
 #if defined(VGO_linux)
 #  include "vki/vki-linux.h"
+#  include "vki/vki-xen.h"
 #elif defined(VGO_darwin)
 #  include "vki/vki-darwin.h"
 #else
diff --git a/include/vki/vki-linux.h b/include/vki/vki-linux.h
index c18195e..4fdc353 100644
--- a/include/vki/vki-linux.h
+++ b/include/vki/vki-linux.h
@@ -3009,6 +3009,50 @@ struct vki_hwtstamp_config {
 #define VKI_UI_SET_SWBIT		_VKI_IOW(VKI_UINPUT_IOCTL_BASE, 109, int)
 #define VKI_UI_SET_PROPBIT		_VKI_IOW(VKI_UINPUT_IOCTL_BASE, 110, int)
 
+//----------------------------------------------------------------------
+// Xen privcmd IOCTL
+//----------------------------------------------------------------------
+
+typedef unsigned long __vki_xen_pfn_t;
+
+struct vki_xen_privcmd_hypercall {
+	__vki_u64 op;
+	__vki_u64 arg[5];
+};
+
+struct vki_xen_privcmd_mmap_entry {
+        __vki_u64 va;
+        __vki_u64 mfn;
+        __vki_u64 npages;
+};
+
+struct vki_xen_privcmd_mmap {
+        int num;
+        __vki_u16 dom; /* target domain */
+        struct vki_xen_privcmd_mmap_entry *entry;
+};
+
+struct vki_xen_privcmd_mmapbatch {
+        int num;     /* number of pages to populate */
+        __vki_u16 dom; /* target domain */
+        __vki_u64 addr;  /* virtual address */
+        __vki_xen_pfn_t *arr; /* array of mfns - top nibble set on err */
+};
+
+struct vki_xen_privcmd_mmapbatch_v2 {
+        unsigned int num; /* number of pages to populate */
+        __vki_u16 dom;      /* target domain */
+        __vki_u64 addr;       /* virtual address */
+        const __vki_xen_pfn_t *arr; /* array of mfns */
+        int __user *err;  /* array of error codes */
+};
+
+#define VKI_XEN_IOCTL_PRIVCMD_HYPERCALL    _VKI_IOC(_VKI_IOC_NONE, 'P', 0, sizeof(struct vki_xen_privcmd_hypercall))
+#define VKI_XEN_IOCTL_PRIVCMD_MMAP         _VKI_IOC(_VKI_IOC_NONE, 'P', 2, sizeof(struct vki_xen_privcmd_mmap))
+
+#define VKI_XEN_IOCTL_PRIVCMD_MMAPBATCH    _VKI_IOC(_VKI_IOC_NONE, 'P', 3, sizeof(struct vki_xen_privcmd_mmapbatch))
+#define VKI_XEN_IOCTL_PRIVCMD_MMAPBATCH_V2 _VKI_IOC(_VKI_IOC_NONE, 'P', 4, sizeof(struct vki_xen_privcmd_mmapbatch_v2))
+
 #endif // __VKI_LINUX_H
 
 /*--------------------------------------------------------------------*/
diff --git a/include/vki/vki-xen.h b/include/vki/vki-xen.h
new file mode 100644
index 0000000..7842cc9
--- /dev/null
+++ b/include/vki/vki-xen.h
@@ -0,0 +1,8 @@
+#ifndef __VKI_XEN_H
+#define __VKI_XEN_H
+
+#endif // __VKI_XEN_H
+
+/*--------------------------------------------------------------------*/
+/*--- 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 Tue Sep 04 16:17:55 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Sep 2012 16:17: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 1T8vom-0004oC-VR; Tue, 04 Sep 2012 16:17: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 1T8vom-0004o3-2O
	for xen-devel@lists.xen.org; Tue, 04 Sep 2012 16:17:36 +0000
Received: from [85.158.138.51:35198] by server-8.bemta-3.messagelabs.com id
	24/51-24700-C9926405; Tue, 04 Sep 2012 16:17:32 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1346775451!19704469!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTE3MTg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14107 invoked from network); 4 Sep 2012 16:17:31 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Sep 2012 16:17:31 -0000
X-IronPort-AV: E=Sophos;i="4.80,367,1344211200"; d="scan'208";a="14340810"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Sep 2012 16:17: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.279.1; Tue, 4 Sep 2012
	17:17:31 +0100
Message-ID: <1346775450.6712.61.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: xen-devel <xen-devel@lists.xen.org>
Date: Tue, 4 Sep 2012 17:17:30 +0100
In-Reply-To: <1346775168.6712.60.camel@zakaz.uk.xensource.com>
References: <1346775168.6712.60.camel@zakaz.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Subject: Re: [Xen-devel] [PATCH] valgrind: Support for ioctls used by Xen
 toolstack processes.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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-09-04 at 17:12 +0100, Ian Campbell wrote:
> Please CC as I'm not subscribed to valgrind-developers.

Which turns out to be a subscriber only list...

Sorry xen-devel for the repost you are about to receive ...

Ian.



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

From xen-devel-bounces@lists.xen.org Tue Sep 04 16:17:55 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Sep 2012 16:17: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 1T8vom-0004oC-VR; Tue, 04 Sep 2012 16:17: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 1T8vom-0004o3-2O
	for xen-devel@lists.xen.org; Tue, 04 Sep 2012 16:17:36 +0000
Received: from [85.158.138.51:35198] by server-8.bemta-3.messagelabs.com id
	24/51-24700-C9926405; Tue, 04 Sep 2012 16:17:32 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1346775451!19704469!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTE3MTg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14107 invoked from network); 4 Sep 2012 16:17:31 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Sep 2012 16:17:31 -0000
X-IronPort-AV: E=Sophos;i="4.80,367,1344211200"; d="scan'208";a="14340810"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Sep 2012 16:17: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.279.1; Tue, 4 Sep 2012
	17:17:31 +0100
Message-ID: <1346775450.6712.61.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: xen-devel <xen-devel@lists.xen.org>
Date: Tue, 4 Sep 2012 17:17:30 +0100
In-Reply-To: <1346775168.6712.60.camel@zakaz.uk.xensource.com>
References: <1346775168.6712.60.camel@zakaz.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Subject: Re: [Xen-devel] [PATCH] valgrind: Support for ioctls used by Xen
 toolstack processes.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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-09-04 at 17:12 +0100, Ian Campbell wrote:
> Please CC as I'm not subscribed to valgrind-developers.

Which turns out to be a subscriber only list...

Sorry xen-devel for the repost you are about to receive ...

Ian.



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

From xen-devel-bounces@lists.xen.org Tue Sep 04 16:21:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Sep 2012 16: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 1T8vrw-0004x4-Jc; Tue, 04 Sep 2012 16:20:52 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1T8vru-0004wv-Us
	for xen-devel@lists.xen.org; Tue, 04 Sep 2012 16:20:51 +0000
Received: from [85.158.143.99:58144] by server-3.bemta-4.messagelabs.com id
	5D/33-08232-26A26405; Tue, 04 Sep 2012 16:20:50 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1346775649!18724886!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTE3MTg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24343 invoked from network); 4 Sep 2012 16:20:49 -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;
	4 Sep 2012 16:20:49 -0000
X-IronPort-AV: E=Sophos;i="4.80,367,1344211200"; d="scan'208";a="14340881"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Sep 2012 16:20: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.279.1; Tue, 4 Sep 2012
	17:20:36 +0100
Message-ID: <1346775635.6712.63.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "valgrind-developers@lists.sourceforge.net"
	<valgrind-developers@lists.sourceforge.net>, xen-devel
	<xen-devel@lists.xen.org>
Date: Tue, 4 Sep 2012 17:20:35 +0100
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Subject: [Xen-devel] [PATCH] valgrind: Support for ioctls used by Xen
 toolstack processes.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Under Xen the toolstack is responsible for managing the domains in
the system, e.g. creating, destroying, and otherwise manipulating
them.

To do this it uses a number of ioctls on the /proc/xen/privcmd
device. Most of these (the MMAPBATCH ones) simply set things up such
that a subsequenct mmap call will map the desired guest memory. Since
valgrind has no way of knowing what the memory contains we assume
that it is all initialised (to do otherwise would require valgrind to
be observing the complete state of the system and not just the given
process).

The most interesting ioctl is XEN_IOCTL_PRIVCMD_HYPERCALL which
allows the toolstack to make arbitrary hypercalls. Although the
mechanism here is specific to the OS of the guest running the
toolstack the hypercalls themselves are defined solely by the
hypervisor. Therefore I have split support for this ioctl into a part
in syswrap-linux.c which handles the ioctl itself and passes things
onto a new syswrap-xen.c which handles the specifics of the
hypercalls themselves. Porting this to another OS should just be a
matter of wiring up syswrap-$OS.c to decode the ioctl and call into
syswrap-xen.c. In the future we may want to split this into
syswrap-$ARCH-xen.c but for now this is x86 only.

The hypercall coverage here is pretty small but is enough to get
reasonable(-ish) results out of the xl toolstack when listing,
creating and destroying domains.

One issue is that the hypercalls which are exlusively used by the
toolstacks (as opposed to those used by guest operating systems) are
not considered a stable ABI, since the hypervisor and the lowlevel
tools are considered a matched pair. This covers the sysctl and
domctl hypercalls which are a fairly large chunk of the support
here. I'm not sure how to solve this without invoking a massive
amount of duplication. Right now this targets the Xen unstable
interface (which will shortly be released as Xen 4.2), perhaps I can
get away with deferring this problem until the first change ;-).

On the plus side the vast majority of hypercalls are not of interest
to the toolstack (they are used by guests) so we can get away without
implementing them.

There are some other wrinkles here I've not been sure how to solve:

Firstly, di_notify_mmap tries to read from the magic proc device:
     --20208-- WARNING: Serious error when reading debug info
     --20208-- When reading debug info from /proc/xen/privcmd:
     --20208-- can't read file to inspect ELF header

I've hacked around this with an explicit check for /proc/xen.
Hopefully someone can point to the right solution.

Secondly, a hypercall only reads as many words from the ioctl arg
struct as there are actual arguments to that hypercall and the
toolstack only initialises the arguments which are used. However
there is no space in the DEFN_PRE_TEMPLATE prototype to allow this to
be communicated from syswrap-xen.c back to syswrap-linux.c. Since a
hypercall can have at most 5 arguments I have hackily stolen ARG8 for
this purpose.
---
 configure.in                           |   19 +
 coregrind/Makefile.am                  |    8 +-
 coregrind/m_debuginfo/debuginfo.c      |    9 +
 coregrind/m_syswrap/priv_syswrap-xen.h |   10 +
 coregrind/m_syswrap/syswrap-linux.c    |  107 ++++-
 coregrind/m_syswrap/syswrap-xen.c      | 1023 ++++++++++++++++++++++++++++++++
 include/Makefile.am                    |    3 +-
 include/pub_tool_vki.h                 |    1 +
 include/vki/vki-linux.h                |   44 ++
 include/vki/vki-xen.h                  |    8 +
 10 files changed, 1229 insertions(+), 3 deletions(-)
 create mode 100644 coregrind/m_syswrap/priv_syswrap-xen.h
 create mode 100644 coregrind/m_syswrap/syswrap-xen.c
 create mode 100644 include/vki/vki-xen.h

diff --git a/configure.in b/configure.in
index b385aed..d94644c 100644
--- a/configure.in
+++ b/configure.in
@@ -2012,6 +2012,25 @@ AC_ARG_WITH(mpicc,
 )
 AC_SUBST(MPI_CC)

+#----------------------------------------------------------------------------
+# Xen checks
+#----------------------------------------------------------------------------
+AC_ARG_ENABLE(xen,
+      [  --enable-xen            Enable support for Xen hypervisor],
+      [vg_cv_xen=$enableval],
+      [vg_cv_xen=no])
+
+AC_ARG_WITH(xen,
+   [  --with-xen=             Specify location of Xen headers],
+   XEN_CFLAGS=-I$withval
+)
+AC_SUBST(XEN_CFLAGS)
+
+AM_CONDITIONAL([ENABLE_XEN], [test x$vg_cv_xen = xyes])
+if test x"$vg_cv_xen" = xyes; then
+    AC_DEFINE([ENABLE_XEN], 1, [configured to support Xen])
+fi
+
 ## We AM_COND_IF here instead of automake "if" in mpi/Makefile.am so that we can
 ## use these values in the check for a functioning mpicc.
 ##
diff --git a/coregrind/Makefile.am b/coregrind/Makefile.am
index 01015a7..58a7dce 100644
--- a/coregrind/Makefile.am
+++ b/coregrind/Makefile.am
@@ -224,6 +224,7 @@ noinst_HEADERS = \
        m_syswrap/priv_syswrap-linux-variants.h \
        m_syswrap/priv_syswrap-darwin.h \
        m_syswrap/priv_syswrap-main.h \
+       m_syswrap/priv_syswrap-xen.h \
        m_ume/priv_ume.h

 #----------------------------------------------------------------------------
@@ -371,6 +372,11 @@ COREGRIND_SOURCES_COMMON = \
        m_ume/main.c \
        m_ume/script.c

+if ENABLE_XEN
+COREGRIND_SOURCES_COMMON += m_syswrap/syswrap-xen.c
+CFLAGS += @XEN_CFLAGS@
+endif
+
 libcoregrind_@VGCONF_ARCH_PRI@_@VGCONF_OS@_a_SOURCES = \
     $(COREGRIND_SOURCES_COMMON)
 nodist_libcoregrind_@VGCONF_ARCH_PRI@_@VGCONF_OS@_a_SOURCES = \
@@ -378,7 +384,7 @@ nodist_libcoregrind_@VGCONF_ARCH_PRI@_@VGCONF_OS@_a_SOURCES = \
 libcoregrind_@VGCONF_ARCH_PRI@_@VGCONF_OS@_a_CPPFLAGS = \
     $(AM_CPPFLAGS_@VGCONF_PLATFORM_PRI_CAPS@)
 libcoregrind_@VGCONF_ARCH_PRI@_@VGCONF_OS@_a_CFLAGS = \
-    $(AM_CFLAGS_@VGCONF_PLATFORM_PRI_CAPS@)
+    $(AM_CFLAGS_@VGCONF_PLATFORM_PRI_CAPS@) @XEN_CFLAGS@
 libcoregrind_@VGCONF_ARCH_PRI@_@VGCONF_OS@_a_CCASFLAGS = \
     $(AM_CCASFLAGS_@VGCONF_PLATFORM_PRI_CAPS@)
 if ENABLE_LINUX_TICKET_LOCK_PRIMARY
diff --git a/coregrind/m_debuginfo/debuginfo.c b/coregrind/m_debuginfo/debuginfo.c
index 218547b..b634ce0 100644
--- a/coregrind/m_debuginfo/debuginfo.c
+++ b/coregrind/m_debuginfo/debuginfo.c
@@ -729,6 +729,15 @@ ULong VG_(di_notify_mmap)( Addr a, Bool allow_SkFileV, Int use_fd )
    if (!filename)
       return 0;

+   /*
+    * Cannot read from these magic files:
+    * --20208-- WARNING: Serious error when reading debug info
+    * --20208-- When reading debug info from /proc/xen/privcmd:
+    * --20208-- can't read file to inspect ELF header
+    */
+   if (VG_(strncmp)(filename, "/proc/xen/", 10) == 0)
+      return 0;
+
    if (debug)
       VG_(printf)("di_notify_mmap-2: %s\n", filename);

diff --git a/coregrind/m_syswrap/priv_syswrap-xen.h b/coregrind/m_syswrap/priv_syswrap-xen.h
new file mode 100644
index 0000000..4dc4748
--- /dev/null
+++ b/coregrind/m_syswrap/priv_syswrap-xen.h
@@ -0,0 +1,10 @@
+#ifndef __PRIV_SYSWRAP_XEN_H
+#define __PRIV_SYSWRAP_XEN_H
+
+DECL_TEMPLATE(xen, hypercall);
+
+#endif   // __PRIV_SYSWRAP_XEN_H
+
+/*--------------------------------------------------------------------*/
+/*--- end                                                          ---*/
+/*--------------------------------------------------------------------*/
diff --git a/coregrind/m_syswrap/syswrap-linux.c b/coregrind/m_syswrap/syswrap-linux.c
index 2f1155f..22c1842 100644
--- a/coregrind/m_syswrap/syswrap-linux.c
+++ b/coregrind/m_syswrap/syswrap-linux.c
@@ -63,7 +63,7 @@
 #include "priv_types_n_macros.h"
 #include "priv_syswrap-generic.h"
 #include "priv_syswrap-linux.h"
-
+#include "priv_syswrap-xen.h"

 // Run a thread from beginning to end and return the thread's
 // scheduler-return-code.
@@ -5527,6 +5527,73 @@ PRE(sys_ioctl)
    case VKI_KVM_RUN:
       break;

+#ifdef ENABLE_XEN
+   case VKI_XEN_IOCTL_PRIVCMD_HYPERCALL: {
+      SyscallArgs harrghs;
+      struct vki_xen_privcmd_hypercall *args =
+         (struct vki_xen_privcmd_hypercall *)(ARG3);
+
+      if (!args)
+         break;
+
+      VG_(memset)(&harrghs, 0, sizeof(harrghs));
+      harrghs.sysno = args->op;
+      harrghs.arg1 = args->arg[0];
+      harrghs.arg2 = args->arg[1];
+      harrghs.arg3 = args->arg[2];
+      harrghs.arg4 = args->arg[3];
+      harrghs.arg5 = args->arg[4];
+      harrghs.arg6 = harrghs.arg7 = harrghs.arg8 = 0;
+
+      WRAPPER_PRE_NAME(xen, hypercall) (tid, layout, &harrghs, status, flags);
+
+      /* HACK. arg8 is used to return the number of hypercall
+       * arguments actually consumed! */
+      PRE_MEM_READ("hypercall", ARG3, sizeof(args->op) +
+                   ( sizeof(args->arg[0]) * harrghs.arg8 ) );
+
+      break;
+   }
+
+   case VKI_XEN_IOCTL_PRIVCMD_MMAP: {
+       struct vki_xen_privcmd_mmap *args =
+           (struct vki_xen_privcmd_mmap *)(ARG3);
+       PRE_MEM_READ("VKI_XEN_IOCTL_PRIVCMD_MMAP",
+                    (Addr)&args->num, sizeof(args->num));
+       PRE_MEM_READ("VKI_XEN_IOCTL_PRIVCMD_MMAP",
+                    (Addr)&args->dom, sizeof(args->dom));
+       PRE_MEM_READ("VKI_XEN_IOCTL_PRIVCMD_MMAP",
+                    (Addr)args->entry, sizeof(*(args->entry)) * args->num);
+      break;
+   }
+   case VKI_XEN_IOCTL_PRIVCMD_MMAPBATCH: {
+       struct vki_xen_privcmd_mmapbatch *args =
+           (struct vki_xen_privcmd_mmapbatch *)(ARG3);
+       PRE_MEM_READ("VKI_XEN_IOCTL_PRIVCMD_MMAPBATCH",
+                    (Addr)&args->num, sizeof(args->num));
+       PRE_MEM_READ("VKI_XEN_IOCTL_PRIVCMD_MMAPBATCH",
+                    (Addr)&args->dom, sizeof(args->dom));
+       PRE_MEM_READ("VKI_XEN_IOCTL_PRIVCMD_MMAPBATCH",
+                    (Addr)&args->addr, sizeof(args->addr));
+       PRE_MEM_READ("VKI_XEN_IOCTL_PRIVCMD_MMAPBATCH",
+                    (Addr)args->arr, sizeof(*(args->arr)) * args->num);
+      break;
+   }
+   case VKI_XEN_IOCTL_PRIVCMD_MMAPBATCH_V2: {
+       struct vki_xen_privcmd_mmapbatch_v2 *args =
+           (struct vki_xen_privcmd_mmapbatch_v2 *)(ARG3);
+       PRE_MEM_READ("VKI_XEN_IOCTL_PRIVCMD_MMAPBATCH_V2",
+                    (Addr)&args->num, sizeof(args->num));
+       PRE_MEM_READ("VKI_XEN_IOCTL_PRIVCMD_MMAPBATCH_V2",
+                    (Addr)&args->dom, sizeof(args->dom));
+       PRE_MEM_READ("VKI_XEN_IOCTL_PRIVCMD_MMAPBATCH_V2",
+                    (Addr)&args->addr, sizeof(args->addr));
+       PRE_MEM_READ("VKI_XEN_IOCTL_PRIVCMD_MMAPBATCH_V2",
+                    (Addr)args->arr, sizeof(*(args->arr)) * args->num);
+      break;
+   }
+#endif
+
    default:
       /* EVIOC* are variable length and return size written on success */
       switch (ARG2 & ~(_VKI_IOC_SIZEMASK << _VKI_IOC_SIZESHIFT)) {
@@ -6524,6 +6591,44 @@ POST(sys_ioctl)
    case VKI_KVM_S390_INITIAL_RESET:
       break;

+#ifdef ENABLE_XEN
+   case VKI_XEN_IOCTL_PRIVCMD_HYPERCALL: {
+      SyscallArgs harrghs;
+      struct vki_xen_privcmd_hypercall *args =
+         (struct vki_xen_privcmd_hypercall *)(ARG3);
+
+      if (!args)
+         break;
+
+      VG_(memset)(&harrghs, 0, sizeof(harrghs));
+      harrghs.sysno = args->op;
+      harrghs.arg1 = args->arg[0];
+      harrghs.arg2 = args->arg[1];
+      harrghs.arg3 = args->arg[2];
+      harrghs.arg4 = args->arg[3];
+      harrghs.arg5 = args->arg[4];
+      harrghs.arg6 = harrghs.arg7 = harrghs.arg8 = 0;
+
+      WRAPPER_POST_NAME(xen, hypercall) (tid, &harrghs, status);
+      break;
+   };
+
+   case VKI_XEN_IOCTL_PRIVCMD_MMAP:
+      break;
+   case VKI_XEN_IOCTL_PRIVCMD_MMAPBATCH: {
+       struct vki_xen_privcmd_mmapbatch *args =
+           (struct vki_xen_privcmd_mmapbatch *)(ARG3);
+       POST_MEM_WRITE((Addr)args->arr, sizeof(*(args->arr)) * args->num);
+      }
+      break;
+   case VKI_XEN_IOCTL_PRIVCMD_MMAPBATCH_V2: {
+       struct vki_xen_privcmd_mmapbatch_v2 *args =
+           (struct vki_xen_privcmd_mmapbatch_v2 *)(ARG3);
+       POST_MEM_WRITE((Addr)args->err, sizeof(*(args->err)) * args->num);
+      }
+      break;
+#endif
+
    default:
       /* EVIOC* are variable length and return size written on success */
       switch (ARG2 & ~(_VKI_IOC_SIZEMASK << _VKI_IOC_SIZESHIFT)) {
diff --git a/coregrind/m_syswrap/syswrap-xen.c b/coregrind/m_syswrap/syswrap-xen.c
new file mode 100644
index 0000000..00192bf
--- /dev/null
+++ b/coregrind/m_syswrap/syswrap-xen.c
@@ -0,0 +1,1023 @@
+
+/*--------------------------------------------------------------------*/
+/*--- Xen Hypercalls                                 syswrap-xen.c ---*/
+/*--------------------------------------------------------------------*/
+
+/*
+   This file is part of Valgrind, a dynamic binary instrumentation
+   framework.
+
+   Copyright (C) 2012 Citrix Systems
+      ian.campbell@citrix.com
+
+   This program is free software; you can redistribute it and/or
+   modify it under the terms of the GNU General Public License as
+   published by the Free Software Foundation; either version 2 of the
+   License, or (at your option) any later version.
+
+   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.
+
+   The GNU General Public License is contained in the file COPYING.
+*/
+
+#include "pub_core_basics.h"
+#include "pub_core_vki.h"
+#include "pub_core_vkiscnums.h"
+#include "pub_core_libcsetjmp.h"   // to keep _threadstate.h happy
+#include "pub_core_threadstate.h"
+#include "pub_core_aspacemgr.h"
+#include "pub_core_debuginfo.h"    // VG_(di_notify_*)
+#include "pub_core_transtab.h"     // VG_(discard_translations)
+#include "pub_core_xarray.h"
+#include "pub_core_clientstate.h"
+#include "pub_core_debuglog.h"
+#include "pub_core_libcbase.h"
+#include "pub_core_libcassert.h"
+#include "pub_core_libcfile.h"
+#include "pub_core_libcprint.h"
+#include "pub_core_libcproc.h"
+#include "pub_core_libcsignal.h"
+#include "pub_core_mallocfree.h"
+#include "pub_core_tooliface.h"
+#include "pub_core_options.h"
+#include "pub_core_scheduler.h"
+#include "pub_core_signals.h"
+#include "pub_core_syscall.h"
+#include "pub_core_syswrap.h"
+#include "pub_core_stacktrace.h"    // For VG_(get_and_pp_StackTrace)()
+
+#include "priv_types_n_macros.h"
+#include "priv_syswrap-generic.h"
+#include "priv_syswrap-xen.h"
+
+#include <stdint.h>
+
+#define __XEN_TOOLS__
+
+#include <xen/xen.h>
+#include <xen/sysctl.h>
+#include <xen/domctl.h>
+#include <xen/memory.h>
+#include <xen/event_channel.h>
+#include <xen/version.h>
+
+#include <xen/hvm/hvm_op.h>
+
+#define PRE(name) static DEFN_PRE_TEMPLATE(xen, name)
+#define POST(name) static DEFN_POST_TEMPLATE(xen, name)
+
+static void bad_subop ( ThreadId              tid,
+                        SyscallArgLayout*     layout,
+                        /*MOD*/SyscallArgs*   args,
+                        /*OUT*/SyscallStatus* status,
+                        /*OUT*/UWord*         flags,
+                        const char*           hypercall,
+                        UWord                 subop)
+{
+   VG_(dmsg)("WARNING: unhandled %s subop: %ld\n",
+             hypercall, subop);
+   if (VG_(clo_verbosity) > 1) {
+      VG_(get_and_pp_StackTrace)(tid, VG_(clo_backtrace_size));
+   }
+   VG_(dmsg)("You may be able to write your own handler.\n");
+   VG_(dmsg)("Read the file README_MISSING_SYSCALL_OR_IOCTL.\n");
+   VG_(dmsg)("Nevertheless we consider this a bug.  Please report\n");
+   VG_(dmsg)("it at http://valgrind.org/support/bug_reports.html &\n");
+   VG_(dmsg)("http://wiki.xen.org/wiki/Reporting_Bugs_against_Xen.\n");
+
+   SET_STATUS_Failure(VKI_ENOSYS);
+}
+
+PRE(memory_op)
+{
+   PRINT("__HYPERVISOR_memory_op ( %ld, %lx )", ARG1, ARG2);
+
+   switch (ARG1) {
+   case XENMEM_set_memory_map: {
+      xen_foreign_memory_map_t *arg =
+         (xen_foreign_memory_map_t *)(unsigned int)ARG2;
+      PRE_MEM_READ("XENMEM_set_memory_map",
+                   (Addr)&arg->domid, sizeof(arg->domid));
+      PRE_MEM_READ("XENMEM_set_memory_map",
+                   (Addr)&arg->map, sizeof(arg->map));
+      break;
+   }
+   case XENMEM_increase_reservation:
+   case XENMEM_decrease_reservation:
+   case XENMEM_populate_physmap: {
+      struct xen_memory_reservation *memory_reservation =
+         (struct xen_memory_reservation *)(unsigned int)ARG2;
+      char *which;
+
+      switch (ARG1) {
+      case XENMEM_increase_reservation:
+         which = "XENMEM_increase_reservation";
+         break;
+      case XENMEM_decrease_reservation:
+         which = "XENMEM_decrease_reservation";
+         PRE_MEM_READ(which,
+                      (Addr)memory_reservation->extent_start.p,
+                      sizeof(xen_pfn_t) * memory_reservation->nr_extents);
+      case XENMEM_populate_physmap:
+         which = "XENMEM_populate_physmap";
+         PRE_MEM_READ(which,
+                      (Addr)memory_reservation->extent_start.p,
+                      sizeof(xen_pfn_t) * memory_reservation->nr_extents);
+         break;
+      default:
+         which = "XENMEM_unknown";
+         break;
+      }
+
+      PRE_MEM_READ(which,
+                   (Addr)&memory_reservation->extent_start,
+                   sizeof(memory_reservation->extent_start));
+      PRE_MEM_READ(which,
+                   (Addr)&memory_reservation->nr_extents,
+                   sizeof(memory_reservation->nr_extents));
+      PRE_MEM_READ(which,
+                   (Addr)&memory_reservation->extent_order,
+                   sizeof(memory_reservation->extent_order));
+      PRE_MEM_READ(which,
+                   (Addr)&memory_reservation->mem_flags,
+                   sizeof(memory_reservation->mem_flags));
+      PRE_MEM_READ(which,
+                   (Addr)&memory_reservation->domid,
+                   sizeof(memory_reservation->domid));
+      break;
+   }
+
+   default:
+      bad_subop(tid, layout, arrghs, status, flags,
+                "__HYPERVISOR_memory_op", ARG1);
+      break;
+   }
+}
+
+PRE(mmuext_op)
+{
+   mmuext_op_t *ops = (void *)(unsigned int)ARG1;
+   unsigned int i, nr = ARG2;
+
+
+   for (i=0; i<nr; i++) {
+      mmuext_op_t *op = ops + i;
+      PRE_MEM_READ("__HYPERVISOR_MMUEXT_OP",
+                   (Addr)&op->cmd, sizeof(op->cmd));
+      switch(op->cmd) {
+      case MMUEXT_PIN_L1_TABLE:
+      case MMUEXT_PIN_L2_TABLE:
+      case MMUEXT_PIN_L3_TABLE:
+      case MMUEXT_PIN_L4_TABLE:
+      case MMUEXT_UNPIN_TABLE:
+      case MMUEXT_NEW_BASEPTR:
+      case MMUEXT_CLEAR_PAGE:
+      case MMUEXT_COPY_PAGE:
+      case MMUEXT_MARK_SUPER:
+      case MMUEXT_UNMARK_SUPER:
+         PRE_MEM_READ("__HYPERVISOR_MMUEXT_OP arg1.mfn",
+                      (Addr)&op->arg1.mfn,
+                      sizeof(op->arg1.mfn));
+         break;
+
+      case MMUEXT_INVLPG_LOCAL:
+      case MMUEXT_INVLPG_ALL:
+      case MMUEXT_SET_LDT:
+         PRE_MEM_READ("__HYPERVISOR_MMUEXT_OP arg1.mfn",
+                      (Addr)&op->arg1.linear_addr,
+                      sizeof(op->arg1.linear_addr));
+         break;
+
+      case MMUEXT_TLB_FLUSH_LOCAL:
+      case MMUEXT_TLB_FLUSH_MULTI:
+      case MMUEXT_INVLPG_MULTI:
+      case MMUEXT_TLB_FLUSH_ALL:
+      case MMUEXT_FLUSH_CACHE:
+      case MMUEXT_NEW_USER_BASEPTR:
+      case MMUEXT_FLUSH_CACHE_GLOBAL:
+         /* None */
+         break;
+      }
+
+      switch(op->cmd) {
+      case MMUEXT_SET_LDT:
+         PRE_MEM_READ("__HYPERVISOR_MMUEXT_OP arg2.nr_ents",
+                      (Addr)&op->arg2.nr_ents,
+                      sizeof(op->arg2.nr_ents));
+         break;
+
+      case MMUEXT_TLB_FLUSH_MULTI:
+      case MMUEXT_INVLPG_MULTI:
+         /* How many??? */
+         PRE_MEM_READ("__HYPERVISOR_MMUEXT_OP arg2.vcpumask",
+                      (Addr)&op->arg2.vcpumask,
+                      sizeof(op->arg2.vcpumask));
+         break;
+
+      case MMUEXT_COPY_PAGE:
+         PRE_MEM_READ("__HYPERVISOR_MMUEXT_OP arg2.src_mfn",
+                      (Addr)&op->arg2.src_mfn,
+                      sizeof(op->arg2.src_mfn));
+         break;
+
+      case MMUEXT_PIN_L1_TABLE:
+      case MMUEXT_PIN_L2_TABLE:
+      case MMUEXT_PIN_L3_TABLE:
+      case MMUEXT_PIN_L4_TABLE:
+      case MMUEXT_UNPIN_TABLE:
+      case MMUEXT_NEW_BASEPTR:
+      case MMUEXT_TLB_FLUSH_LOCAL:
+      case MMUEXT_INVLPG_LOCAL:
+      case MMUEXT_TLB_FLUSH_ALL:
+      case MMUEXT_INVLPG_ALL:
+      case MMUEXT_FLUSH_CACHE:
+      case MMUEXT_NEW_USER_BASEPTR:
+      case MMUEXT_CLEAR_PAGE:
+      case MMUEXT_FLUSH_CACHE_GLOBAL:
+      case MMUEXT_MARK_SUPER:
+      case MMUEXT_UNMARK_SUPER:
+         /* None */
+         break;
+      }
+   }
+}
+
+static void pre_evtchn_op(ThreadId tid,
+                          SyscallArgLayout*     layout,
+                          /*MOD*/SyscallArgs*   arrghs,
+                          /*OUT*/SyscallStatus* status,
+                          /*OUT*/UWord*         flags,
+                          __vki_u32 cmd, void *arg, int compat)
+{
+   PRINT("__HYPERVISOR_event_channel_op%s ( %d, %p )",
+         compat ? "_compat" : "", cmd, arg);
+
+   switch (cmd) {
+   case EVTCHNOP_alloc_unbound: {
+      struct evtchn_alloc_unbound *alloc_unbound = arg;
+      PRE_MEM_READ("EVTCHNOP_alloc_unbound",
+                   (Addr)&alloc_unbound->dom, sizeof(alloc_unbound->dom));
+      PRE_MEM_READ("EVTCHNOP_alloc_unbound",
+                   (Addr)&alloc_unbound->remote_dom,
+                   sizeof(alloc_unbound->remote_dom));
+      break;
+   }
+   default:
+      if ( compat )
+         bad_subop(tid, layout, arrghs, status, flags,
+                   "__HYPERVISOR_event_channel_op_compat", cmd);
+      else
+         bad_subop(tid, layout, arrghs, status, flags,
+                   "__HYPERVISOR_event_channel_op", cmd);
+      break;
+   }
+}
+
+PRE(evtchn_op)
+{
+   pre_evtchn_op(tid, layout, arrghs, status, flags,
+                 ARG1, (void *)(unsigned int)ARG2, 0);
+}
+
+PRE(evtchn_op_compat)
+{
+   struct evtchn_op *evtchn = (struct evtchn_op *)(unsigned int)ARG1;
+   PRE_MEM_READ("__HYPERVISOR_event_channel_op_compat",
+                ARG1, sizeof(*evtchn));
+
+   pre_evtchn_op(tid, layout, arrghs, status, flags,
+                 evtchn->cmd, &evtchn->u, 1);
+}
+
+PRE(xen_version)
+{
+   PRINT("__HYPERVISOR_xen_version ( %ld, %lx )", ARG1, ARG2);
+
+   switch (ARG1) {
+   case XENVER_version:
+   case XENVER_extraversion:
+   case XENVER_compile_info:
+   case XENVER_capabilities:
+   case XENVER_changeset:
+   case XENVER_platform_parameters:
+   case XENVER_get_features:
+   case XENVER_pagesize:
+   case XENVER_guest_handle:
+   case XENVER_commandline:
+      /* No inputs */
+      break;
+
+   default:
+      bad_subop(tid, layout, arrghs, status, flags,
+                "__HYPERVISOR_xen_version", ARG1);
+      break;
+   }
+}
+
+PRE(grant_table_op)
+{
+   PRINT("__HYPERVISOR_grant_table_op ( %ld, 0x%lx, %ld )", ARG1, ARG2, ARG3);
+   switch (ARG1) {
+   case GNTTABOP_setup_table: {
+      struct gnttab_setup_table *gst = (void *)(intptr_t)ARG2;
+      PRE_MEM_READ("GNTTABOP_setup_table", (Addr)&gst->dom, sizeof(gst->dom));
+      PRE_MEM_READ("GNTTABOP_setup_table",
+                   (Addr)&gst->nr_frames, sizeof(gst->nr_frames));
+      break;
+   }
+   default:
+      bad_subop(tid, layout, arrghs, status, flags,
+                "__HYPERVISOR_grant_table_op", ARG1);
+      break;
+   }
+}
+
+PRE(sysctl) {
+   struct xen_sysctl *sysctl = (struct xen_sysctl *)(unsigned int)ARG1;
+
+   PRINT("__HYPERVISOR_sysctl ( %d )", sysctl->cmd);
+
+   /*
+    * Common part of xen_sysctl:
+    *    uint32_t cmd;
+    *    uint32_t interface_version;
+    */
+   PRE_MEM_READ("__HYPERVISOR_sysctl", ARG1,
+                sizeof(uint32_t) + sizeof(uint32_t));
+
+   if (!sysctl || sysctl->interface_version != XEN_SYSCTL_INTERFACE_VERSION)
+      /* BUG ? */
+      return;
+
+#define __PRE_XEN_SYSCTL_READ(_sysctl, _union, _field)  \
+      PRE_MEM_READ("XEN_SYSCTL_" # _sysctl,             \
+                   (Addr)&sysctl->u._union._field,      \
+                   sizeof(sysctl->u._union._field))
+#define PRE_XEN_SYSCTL_READ(_sysctl, _field) \
+      __PRE_XEN_SYSCTL_READ(_sysctl, _sysctl, _field)
+
+   switch (sysctl->cmd) {
+   case XEN_SYSCTL_getdomaininfolist:
+      PRE_XEN_SYSCTL_READ(getdomaininfolist, first_domain);
+      PRE_XEN_SYSCTL_READ(getdomaininfolist, max_domains);
+      PRE_XEN_SYSCTL_READ(getdomaininfolist, buffer);
+      break;
+
+   case XEN_SYSCTL_cpupool_op:
+      PRE_XEN_SYSCTL_READ(cpupool_op, op);
+
+      switch(sysctl->u.cpupool_op.op) {
+      case XEN_SYSCTL_CPUPOOL_OP_CREATE:
+      case XEN_SYSCTL_CPUPOOL_OP_DESTROY:
+      case XEN_SYSCTL_CPUPOOL_OP_INFO:
+      case XEN_SYSCTL_CPUPOOL_OP_ADDCPU:
+      case XEN_SYSCTL_CPUPOOL_OP_RMCPU:
+      case XEN_SYSCTL_CPUPOOL_OP_MOVEDOMAIN:
+         PRE_XEN_SYSCTL_READ(cpupool_op, cpupool_id);
+      }
+
+      if (sysctl->u.cpupool_op.op == XEN_SYSCTL_CPUPOOL_OP_CREATE)
+         PRE_XEN_SYSCTL_READ(cpupool_op, sched_id);
+
+      if (sysctl->u.cpupool_op.op == XEN_SYSCTL_CPUPOOL_OP_MOVEDOMAIN)
+         PRE_XEN_SYSCTL_READ(cpupool_op, domid);
+
+      if (sysctl->u.cpupool_op.op == XEN_SYSCTL_CPUPOOL_OP_ADDCPU ||
+          sysctl->u.cpupool_op.op == XEN_SYSCTL_CPUPOOL_OP_RMCPU)
+         PRE_XEN_SYSCTL_READ(cpupool_op, cpu);
+
+      break;
+
+   case XEN_SYSCTL_physinfo:
+      /* No input params */
+      break;
+
+   case XEN_SYSCTL_topologyinfo:
+      PRE_XEN_SYSCTL_READ(topologyinfo, max_cpu_index);
+      PRE_XEN_SYSCTL_READ(topologyinfo, cpu_to_core);
+      PRE_XEN_SYSCTL_READ(topologyinfo, cpu_to_socket);
+      PRE_XEN_SYSCTL_READ(topologyinfo, cpu_to_node);
+      break;
+
+   case XEN_SYSCTL_numainfo:
+      PRE_XEN_SYSCTL_READ(numainfo, max_node_index);
+      PRE_XEN_SYSCTL_READ(numainfo, node_to_memsize);
+      PRE_XEN_SYSCTL_READ(numainfo, node_to_memfree);
+      PRE_XEN_SYSCTL_READ(numainfo, node_to_node_distance);
+      break;
+
+   default:
+      bad_subop(tid, layout, arrghs, status, flags,
+                "__HYPERVISOR_sysctl", sysctl->cmd);
+      break;
+   }
+#undef PRE_XEN_SYSCTL_READ
+#undef __PRE_XEN_SYSCTL_READ
+}
+
+PRE(domctl)
+{
+   struct xen_domctl *domctl = (struct xen_domctl *)(unsigned int)ARG1;
+
+   PRINT("__HYPERVISOR_domctl ( %d ) on dom%d", domctl->cmd, domctl->domain);
+
+   /*
+    * Common part of xen_domctl:
+    *    uint32_t cmd;
+    *    uint32_t interface_version;
+    *    domid_t  domain;
+    */
+   PRE_MEM_READ("__HYPERVISOR_domctl", ARG1,
+                sizeof(uint32_t) + sizeof(uint32_t) + sizeof(domid_t));
+
+   if (!domctl || domctl->interface_version != XEN_DOMCTL_INTERFACE_VERSION)
+      /* BUG ? */
+      return;
+
+#define __PRE_XEN_DOMCTL_READ(_domctl, _union, _field)  \
+      PRE_MEM_READ("XEN_DOMCTL_" # _domctl,             \
+                   (Addr)&domctl->u._union._field,      \
+                   sizeof(domctl->u._union._field))
+#define PRE_XEN_DOMCTL_READ(_domctl, _field) \
+      __PRE_XEN_DOMCTL_READ(_domctl, _domctl, _field)
+
+   switch (domctl->cmd) {
+   case XEN_DOMCTL_destroydomain:
+   case XEN_DOMCTL_pausedomain:
+   case XEN_DOMCTL_max_vcpus:
+   case XEN_DOMCTL_get_address_size:
+   case XEN_DOMCTL_gettscinfo:
+   case XEN_DOMCTL_getdomaininfo:
+   case XEN_DOMCTL_unpausedomain:
+      /* No input fields. */
+      break;
+
+   case XEN_DOMCTL_createdomain:
+      PRE_XEN_DOMCTL_READ(createdomain, ssidref);
+      PRE_XEN_DOMCTL_READ(createdomain, handle);
+      PRE_XEN_DOMCTL_READ(createdomain, flags);
+      break;
+
+   case XEN_DOMCTL_max_mem:
+      PRE_XEN_DOMCTL_READ(max_mem, max_memkb);
+      break;
+
+   case XEN_DOMCTL_set_address_size:
+      __PRE_XEN_DOMCTL_READ(set_address_size, address_size, size);
+      break;
+
+   case XEN_DOMCTL_settscinfo:
+      __PRE_XEN_DOMCTL_READ(settscinfo, tsc_info, info.tsc_mode);
+      __PRE_XEN_DOMCTL_READ(settscinfo, tsc_info, info.gtsc_khz);
+      __PRE_XEN_DOMCTL_READ(settscinfo, tsc_info, info.incarnation);
+      __PRE_XEN_DOMCTL_READ(settscinfo, tsc_info, info.elapsed_nsec);
+      break;
+
+   case XEN_DOMCTL_hypercall_init:
+      PRE_XEN_DOMCTL_READ(hypercall_init, gmfn);
+      break;
+
+   case XEN_DOMCTL_getvcpuinfo:
+      PRE_XEN_DOMCTL_READ(getvcpuinfo, vcpu);
+      break;
+
+   case XEN_DOMCTL_scheduler_op:
+      PRE_XEN_DOMCTL_READ(scheduler_op, sched_id);
+      PRE_XEN_DOMCTL_READ(scheduler_op, cmd);
+      if ( domctl->u.scheduler_op.cmd == XEN_DOMCTL_SCHEDOP_putinfo ) {
+         switch(domctl->u.scheduler_op.sched_id) {
+         case XEN_SCHEDULER_SEDF:
+            PRE_XEN_DOMCTL_READ(scheduler_op, u.sedf.period);
+            PRE_XEN_DOMCTL_READ(scheduler_op, u.sedf.slice);
+            PRE_XEN_DOMCTL_READ(scheduler_op, u.sedf.latency);
+            PRE_XEN_DOMCTL_READ(scheduler_op, u.sedf.extratime);
+            PRE_XEN_DOMCTL_READ(scheduler_op, u.sedf.weight);
+            break;
+         case XEN_SCHEDULER_CREDIT:
+            PRE_XEN_DOMCTL_READ(scheduler_op, u.credit.weight);
+            PRE_XEN_DOMCTL_READ(scheduler_op, u.credit.cap);
+            break;
+         case XEN_SCHEDULER_CREDIT2:
+            PRE_XEN_DOMCTL_READ(scheduler_op, u.credit2.weight);
+            break;
+         case XEN_SCHEDULER_ARINC653:
+            break;
+         }
+      }
+      break;
+
+   case XEN_DOMCTL_getvcpuaffinity:
+      __PRE_XEN_DOMCTL_READ(getvcpuaffinity, vcpuaffinity, vcpu);
+      break;
+
+   case XEN_DOMCTL_setvcpuaffinity:
+      __PRE_XEN_DOMCTL_READ(setvcpuaffinity, vcpuaffinity, vcpu);
+      PRE_MEM_READ("XEN_DOMCTL_setvcpuaffinity",
+                   (Addr)domctl->u.vcpuaffinity.cpumap.bitmap.p,
+                   domctl->u.vcpuaffinity.cpumap.nr_cpus / 8);
+      break;
+
+   case XEN_DOMCTL_getvcpucontext:
+      __PRE_XEN_DOMCTL_READ(getvcpucontext, vcpucontext, vcpu);
+      break;
+
+   case XEN_DOMCTL_setvcpucontext:
+      __PRE_XEN_DOMCTL_READ(setvcpucontext, vcpucontext, vcpu);
+      __PRE_XEN_DOMCTL_READ(setvcpucontext, vcpucontext, ctxt.p);
+      break;
+
+   case XEN_DOMCTL_set_cpuid:
+      PRE_MEM_READ("XEN_DOMCTL_set_cpuid",
+                   (Addr)&domctl->u.cpuid, sizeof(domctl->u.cpuid));
+      break;
+
+   case XEN_DOMCTL_getvcpuextstate:
+      __PRE_XEN_DOMCTL_READ(getvcpuextstate, vcpuextstate, vcpu);
+      __PRE_XEN_DOMCTL_READ(getvcpuextstate, vcpuextstate, xfeature_mask);
+      __PRE_XEN_DOMCTL_READ(getvcpuextstate, vcpuextstate, size);
+      __PRE_XEN_DOMCTL_READ(getvcpuextstate, vcpuextstate, buffer);
+      break;
+
+   default:
+      bad_subop(tid, layout, arrghs, status, flags,
+                "__HYPERVISOR_domctl", domctl->cmd);
+      break;
+   }
+#undef PRE_XEN_DOMCTL_READ
+#undef __PRE_XEN_DOMCTL_READ
+}
+
+PRE(hvm_op)
+{
+   unsigned long op = ARG1;
+   void *arg = (void *)(unsigned long)ARG2;
+
+   PRINT("__HYPERVISOR_hvm_op ( %ld, %p )", op, arg);
+
+#define __PRE_XEN_HVMOP_READ(_hvm_op, _type, _field)    \
+   PRE_MEM_READ("XEN_HVMOP_" # _hvm_op,                 \
+                (Addr)&((_type*)arg)->_field,           \
+                sizeof(((_type*)arg)->_field))
+#define PRE_XEN_HVMOP_READ(_hvm_op, _field)                             \
+   __PRE_XEN_HVMOP_READ(_hvm_op, "xen_hvm_" # _hvm_op "_t", _field)
+
+   switch (op) {
+   case HVMOP_set_param:
+      __PRE_XEN_HVMOP_READ(set_param, xen_hvm_param_t, domid);
+      __PRE_XEN_HVMOP_READ(set_param, xen_hvm_param_t, index);
+      __PRE_XEN_HVMOP_READ(set_param, xen_hvm_param_t, value);
+      break;
+
+   case HVMOP_get_param:
+      __PRE_XEN_HVMOP_READ(get_param, xen_hvm_param_t, domid);
+      __PRE_XEN_HVMOP_READ(get_param, xen_hvm_param_t, index);
+      break;
+
+   default:
+      bad_subop(tid, layout, arrghs, status, flags,
+                "__HYPERVISOR_hvm_op", op);
+      break;
+   }
+#undef __PRE_XEN_HVMOP_READ
+#undef PRE_XEN_HVMOP_READ
+}
+
+POST(memory_op)
+{
+   switch (ARG1) {
+   case XENMEM_set_memory_map:
+   case XENMEM_decrease_reservation:
+      /* No outputs */
+      break;
+   case XENMEM_increase_reservation:
+   case XENMEM_populate_physmap: {
+      struct xen_memory_reservation *memory_reservation =
+         (struct xen_memory_reservation *)(unsigned int)ARG2;
+
+      POST_MEM_WRITE((Addr)memory_reservation->extent_start.p,
+                     sizeof(xen_pfn_t) * memory_reservation->nr_extents);
+      break;
+   }
+   }
+}
+
+POST(mmuext_op)
+{
+   unsigned int *pdone = (void *)(unsigned int)ARG3;
+   /* simplistic */
+   POST_MEM_WRITE((Addr)pdone, sizeof(*pdone));
+}
+
+static void post_evtchn_op(ThreadId tid, __vki_u32 cmd, void *arg, int compat)
+{
+   switch (cmd) {
+   case EVTCHNOP_alloc_unbound: {
+      struct evtchn_alloc_unbound *alloc_unbound = arg;
+      POST_MEM_WRITE((Addr)&alloc_unbound->port, sizeof(alloc_unbound->port));
+      break;
+   }
+   }
+}
+
+POST(evtchn_op)
+{
+   post_evtchn_op(tid, ARG1, (void *)(unsigned int)ARG2, 0);
+}
+
+POST(evtchn_op_compat)
+{
+   struct evtchn_op *evtchn = (struct evtchn_op *)(unsigned int)ARG1;
+   post_evtchn_op(tid, evtchn->cmd, &evtchn->u, 1);
+}
+
+POST(xen_version)
+{
+   switch (ARG1) {
+   case XENVER_version:
+      /* No outputs */
+      break;
+   case XENVER_extraversion:
+      POST_MEM_WRITE((Addr)ARG2, sizeof(xen_extraversion_t));
+      break;
+   case XENVER_compile_info:
+      POST_MEM_WRITE((Addr)ARG2, sizeof(xen_compile_info_t));
+      break;
+   case XENVER_capabilities:
+      POST_MEM_WRITE((Addr)ARG2, sizeof(xen_capabilities_info_t));
+      break;
+   case XENVER_changeset:
+      POST_MEM_WRITE((Addr)ARG2, sizeof(xen_changeset_info_t));
+      break;
+   case XENVER_platform_parameters:
+      POST_MEM_WRITE((Addr)ARG2, sizeof(xen_platform_parameters_t));
+      break;
+   case XENVER_get_features:
+      POST_MEM_WRITE((Addr)ARG2, sizeof(xen_feature_info_t));
+      break;
+   case XENVER_pagesize:
+      /* No outputs */
+      break;
+   case XENVER_guest_handle:
+      POST_MEM_WRITE((Addr)ARG2, sizeof(xen_domain_handle_t));
+      break;
+   case XENVER_commandline:
+      POST_MEM_WRITE((Addr)ARG2, sizeof(xen_commandline_t));
+      break;
+   }
+}
+
+POST(grant_table_op)
+{
+   switch (ARG1) {
+   case GNTTABOP_setup_table: {
+      struct gnttab_setup_table *gst = (void *)(uintptr_t)ARG2;
+      PRE_MEM_WRITE("GNTTABOP_setup_table",
+                    (Addr)&gst->status, sizeof(gst->status));
+      PRE_MEM_WRITE("GNTTABOP_setup_table",
+                    (Addr)gst->frame_list.p,
+                    sizeof(*gst->frame_list.p) & gst->nr_frames);
+      break;
+   }
+   }
+}
+
+POST(sysctl)
+{
+   struct xen_sysctl *sysctl = (struct xen_sysctl *)(unsigned int)ARG1;
+
+   if (!sysctl || sysctl->interface_version != XEN_SYSCTL_INTERFACE_VERSION)
+      return;
+
+#define __POST_XEN_SYSCTL_WRITE(_sysctl, _union, _field)        \
+      POST_MEM_WRITE((Addr)&sysctl->u._union._field,            \
+                     sizeof(sysctl->u._union._field))
+#define POST_XEN_SYSCTL_WRITE(_sysctl, _field) \
+      __POST_XEN_SYSCTL_WRITE(_sysctl, _sysctl, _field)
+
+   switch (sysctl->cmd) {
+   case XEN_SYSCTL_getdomaininfolist:
+      POST_XEN_SYSCTL_WRITE(getdomaininfolist, num_domains);
+      POST_MEM_WRITE((Addr)sysctl->u.getdomaininfolist.buffer.p,
+                     sizeof(xen_domctl_getdomaininfo_t)
+                     * sysctl->u.getdomaininfolist.num_domains);
+      break;
+
+   case XEN_SYSCTL_cpupool_op:
+      if (sysctl->u.cpupool_op.op == XEN_SYSCTL_CPUPOOL_OP_CREATE ||
+          sysctl->u.cpupool_op.op == XEN_SYSCTL_CPUPOOL_OP_INFO)
+         POST_XEN_SYSCTL_WRITE(cpupool_op, cpupool_id);
+      if (sysctl->u.cpupool_op.op == XEN_SYSCTL_CPUPOOL_OP_INFO) {
+         POST_XEN_SYSCTL_WRITE(cpupool_op, sched_id);
+         POST_XEN_SYSCTL_WRITE(cpupool_op, n_dom);
+      }
+      if (sysctl->u.cpupool_op.op == XEN_SYSCTL_CPUPOOL_OP_INFO ||
+          sysctl->u.cpupool_op.op == XEN_SYSCTL_CPUPOOL_OP_FREEINFO)
+         POST_XEN_SYSCTL_WRITE(cpupool_op, cpumap);
+      break;
+
+   case XEN_SYSCTL_physinfo:
+      POST_XEN_SYSCTL_WRITE(physinfo, threads_per_core);
+      POST_XEN_SYSCTL_WRITE(physinfo, cores_per_socket);
+      POST_XEN_SYSCTL_WRITE(physinfo, nr_cpus);
+      POST_XEN_SYSCTL_WRITE(physinfo, max_cpu_id);
+      POST_XEN_SYSCTL_WRITE(physinfo, nr_nodes);
+      POST_XEN_SYSCTL_WRITE(physinfo, max_node_id);
+      POST_XEN_SYSCTL_WRITE(physinfo, cpu_khz);
+      POST_XEN_SYSCTL_WRITE(physinfo, total_pages);
+      POST_XEN_SYSCTL_WRITE(physinfo, free_pages);
+      POST_XEN_SYSCTL_WRITE(physinfo, scrub_pages);
+      POST_XEN_SYSCTL_WRITE(physinfo, hw_cap[8]);
+      POST_XEN_SYSCTL_WRITE(physinfo, capabilities);
+      break;
+
+   case XEN_SYSCTL_topologyinfo:
+      POST_XEN_SYSCTL_WRITE(topologyinfo, max_cpu_index);
+      POST_MEM_WRITE((Addr)sysctl->u.topologyinfo.cpu_to_core.p,
+                     sizeof(uint32_t) * sysctl->u.topologyinfo.max_cpu_index);
+      POST_MEM_WRITE((Addr)sysctl->u.topologyinfo.cpu_to_socket.p,
+                     sizeof(uint32_t) * sysctl->u.topologyinfo.max_cpu_index);
+      POST_MEM_WRITE((Addr)sysctl->u.topologyinfo.cpu_to_node.p,
+                     sizeof(uint32_t) * sysctl->u.topologyinfo.max_cpu_index);
+      break;
+
+   case XEN_SYSCTL_numainfo:
+      POST_XEN_SYSCTL_WRITE(numainfo, max_node_index);
+      POST_MEM_WRITE((Addr)sysctl->u.numainfo.node_to_memsize.p,
+                     sizeof(uint64_t) * sysctl->u.numainfo.max_node_index);
+      POST_MEM_WRITE((Addr)sysctl->u.numainfo.node_to_memfree.p,
+                     sizeof(uint64_t) * sysctl->u.numainfo.max_node_index);
+      POST_MEM_WRITE((Addr)sysctl->u.numainfo.node_to_node_distance.p,
+                     sizeof(uint32_t) * sysctl->u.numainfo.max_node_index);
+   }
+#undef POST_XEN_SYSCTL_WRITE
+#undef __POST_XEN_SYSCTL_WRITE
+}
+
+POST(domctl){
+   struct xen_domctl *domctl = (struct xen_domctl *)(unsigned int)ARG1;
+
+   if (!domctl || domctl->interface_version != XEN_DOMCTL_INTERFACE_VERSION)
+      return;
+
+#define __POST_XEN_DOMCTL_WRITE(_domctl, _union, _field)        \
+   POST_MEM_WRITE((Addr)&domctl->u._union._field,               \
+                  sizeof(domctl->u._union._field));
+#define POST_XEN_DOMCTL_WRITE(_domctl, _field)          \
+   __POST_XEN_DOMCTL_WRITE(_domctl, _domctl, _field)
+
+   switch (domctl->cmd) {
+   case XEN_DOMCTL_createdomain:
+   case XEN_DOMCTL_destroydomain:
+   case XEN_DOMCTL_pausedomain:
+   case XEN_DOMCTL_max_mem:
+   case XEN_DOMCTL_set_address_size:
+   case XEN_DOMCTL_settscinfo:
+   case XEN_DOMCTL_hypercall_init:
+   case XEN_DOMCTL_setvcpuaffinity:
+   case XEN_DOMCTL_setvcpucontext:
+   case XEN_DOMCTL_set_cpuid:
+   case XEN_DOMCTL_unpausedomain:
+      /* No output fields */
+      break;
+
+   case XEN_DOMCTL_max_vcpus:
+      POST_XEN_DOMCTL_WRITE(max_vcpus, max);
+
+   case XEN_DOMCTL_get_address_size:
+      __POST_XEN_DOMCTL_WRITE(get_address_size, address_size, size);
+      break;
+
+   case XEN_DOMCTL_gettscinfo:
+      __POST_XEN_DOMCTL_WRITE(settscinfo, tsc_info, info.tsc_mode);
+      __POST_XEN_DOMCTL_WRITE(settscinfo, tsc_info, info.gtsc_khz);
+      __POST_XEN_DOMCTL_WRITE(settscinfo, tsc_info, info.incarnation);
+      __POST_XEN_DOMCTL_WRITE(settscinfo, tsc_info, info.elapsed_nsec);
+      break;
+
+   case XEN_DOMCTL_getvcpuinfo:
+      POST_XEN_DOMCTL_WRITE(getvcpuinfo, online);
+      POST_XEN_DOMCTL_WRITE(getvcpuinfo, blocked);
+      POST_XEN_DOMCTL_WRITE(getvcpuinfo, running);
+      POST_XEN_DOMCTL_WRITE(getvcpuinfo, cpu_time);
+      POST_XEN_DOMCTL_WRITE(getvcpuinfo, cpu);
+      break;
+
+   case XEN_DOMCTL_scheduler_op:
+      if ( domctl->u.scheduler_op.cmd == XEN_DOMCTL_SCHEDOP_getinfo ) {
+         switch(domctl->u.scheduler_op.sched_id) {
+         case XEN_SCHEDULER_SEDF:
+            POST_XEN_DOMCTL_WRITE(scheduler_op, u.sedf.period);
+            POST_XEN_DOMCTL_WRITE(scheduler_op, u.sedf.slice);
+            POST_XEN_DOMCTL_WRITE(scheduler_op, u.sedf.latency);
+            POST_XEN_DOMCTL_WRITE(scheduler_op, u.sedf.extratime);
+            POST_XEN_DOMCTL_WRITE(scheduler_op, u.sedf.weight);
+            break;
+         case XEN_SCHEDULER_CREDIT:
+            POST_XEN_DOMCTL_WRITE(scheduler_op, u.credit.weight);
+            POST_XEN_DOMCTL_WRITE(scheduler_op, u.credit.cap);
+            break;
+         case XEN_SCHEDULER_CREDIT2:
+            POST_XEN_DOMCTL_WRITE(scheduler_op, u.credit2.weight);
+            break;
+         case XEN_SCHEDULER_ARINC653:
+            break;
+         }
+      }
+      break;
+
+   case XEN_DOMCTL_getvcpuaffinity:
+      POST_MEM_WRITE((Addr)domctl->u.vcpuaffinity.cpumap.bitmap.p,
+                     domctl->u.vcpuaffinity.cpumap.nr_cpus / 8);
+      break;
+
+   case XEN_DOMCTL_getdomaininfo:
+      POST_XEN_DOMCTL_WRITE(getdomaininfo, domain);
+      POST_XEN_DOMCTL_WRITE(getdomaininfo, flags);
+      POST_XEN_DOMCTL_WRITE(getdomaininfo, tot_pages);
+      POST_XEN_DOMCTL_WRITE(getdomaininfo, max_pages);
+      POST_XEN_DOMCTL_WRITE(getdomaininfo, shr_pages);
+      POST_XEN_DOMCTL_WRITE(getdomaininfo, shared_info_frame);
+      POST_XEN_DOMCTL_WRITE(getdomaininfo, cpu_time);
+      POST_XEN_DOMCTL_WRITE(getdomaininfo, nr_online_vcpus);
+      POST_XEN_DOMCTL_WRITE(getdomaininfo, max_vcpu_id);
+      POST_XEN_DOMCTL_WRITE(getdomaininfo, ssidref);
+      POST_XEN_DOMCTL_WRITE(getdomaininfo, handle);
+      POST_XEN_DOMCTL_WRITE(getdomaininfo, cpupool);
+      break;
+
+   case XEN_DOMCTL_getvcpucontext:
+      __POST_XEN_DOMCTL_WRITE(getvcpucontext, vcpucontext, ctxt.p);
+      break;
+
+   case XEN_DOMCTL_getvcpuextstate:
+      __POST_XEN_DOMCTL_WRITE(getvcpuextstate, vcpuextstate, xfeature_mask);
+      __POST_XEN_DOMCTL_WRITE(getvcpuextstate, vcpuextstate, size);
+      POST_MEM_WRITE((Addr)domctl->u.vcpuextstate.buffer.p,
+                     domctl->u.vcpuextstate.size);
+      break;
+
+   }
+#undef POST_XEN_DOMCTL_WRITE
+#undef __POST_XEN_DOMCTL_WRITE
+}
+
+POST(hvm_op)
+{
+   unsigned long op = ARG1;
+   void *arg = (void *)(unsigned long)ARG2;
+
+#define __POST_XEN_HVMOP_WRITE(_hvm_op, _type, _field)  \
+      POST_MEM_WRITE((Addr)&((_type*)arg)->_field,      \
+                     sizeof(((_type*)arg)->_field))
+#define POST_XEN_HVMOP_WRITE(_hvm_op, _field) \
+      __PRE_XEN_HVMOP_READ(_hvm_op, "xen_hvm_" # _hvm_op "_t", _field)
+
+   switch (op) {
+   case HVMOP_set_param:
+      /* No output paramters */
+      break;
+
+   case HVMOP_get_param:
+      __POST_XEN_HVMOP_WRITE(get_param, xen_hvm_param_t, value);
+      break;
+   }
+#undef __POST_XEN_HVMOP_WRITE
+#undef POST_XEN_HVMOP_WRITE
+}
+
+typedef
+   struct {
+      SyscallTableEntry entry;
+      int nr_args;
+   }
+   XenHypercallTableEntry;
+
+#define HYPX_(const, name, nr_args) \
+   [const] = { { vgSysWrap_xen_##name##_before, NULL }, nr_args }
+#define HYPXY(const, name, nr_args)                     \
+   [const] = { { vgSysWrap_xen_##name##_before,         \
+                 vgSysWrap_xen_##name##_after },        \
+               nr_args }
+
+static XenHypercallTableEntry hypercall_table[] = {
+   //    __HYPERVISOR_set_trap_table                                  // 0
+   //    __HYPERVISOR_mmu_update                                      // 1
+   //    __HYPERVISOR_set_gdt                                         // 2
+   //    __HYPERVISOR_stack_switch                                    // 3
+   //    __HYPERVISOR_set_callbacks                                   // 4
+
+   //    __HYPERVISOR_fpu_taskswitch                                  // 5
+   //    __HYPERVISOR_sched_op_compat                                 // 6
+   //    __HYPERVISOR_platform_op                                     // 7
+   //    __HYPERVISOR_set_debugreg                                    // 8
+   //    __HYPERVISOR_get_debugreg                                    // 9
+
+   //    __HYPERVISOR_update_descriptor                               // 10
+   //                                                                 // 11
+   HYPXY(__HYPERVISOR_memory_op,               memory_op,         2), // 12
+   //    __HYPERVISOR_multicall                                       // 13
+   //    __HYPERVISOR_update_va_mapping                               // 14
+
+   //    __HYPERVISOR_set_timer_op                                    // 15
+   HYPXY(__HYPERVISOR_event_channel_op_compat, evtchn_op_compat,  1), // 16
+   HYPXY(__HYPERVISOR_xen_version,             xen_version,       2), // 17
+   //    __HYPERVISOR_console_io                                      // 18
+   //    __HYPERVISOR_physdev_op_compat                               // 19
+
+   HYPXY(__HYPERVISOR_grant_table_op,          grant_table_op,    3), // 20
+   //    __HYPERVISOR_vm_assist                                       // 21
+   //    __HYPERVISOR_update_va_mapping_otherdomain                   // 22
+   //    __HYPERVISOR_iret,                    iret                   // 23
+   //    __HYPERVISOR_vcpu_op,                 vcpu_op                // 24
+
+   //    __HYPERVISOR_set_segment_base                                // 25
+   HYPXY(__HYPERVISOR_mmuext_op,               mmuext_op,         2), // 26
+   //    __HYPERVISOR_xsm_op                                          // 27
+   //    __HYPERVISOR_nmi_op                                          // 28
+   //    __HYPERVISOR_sched_op                                        // 29
+
+   //    __HYPERVISOR_callback_op                                     // 30
+   //    __HYPERVISOR_xenoprof_op                                     // 31
+   HYPXY(__HYPERVISOR_event_channel_op,        evtchn_op,         2), // 32
+   //    __HYPERVISOR_physdev_op                                      // 33
+   HYPXY(__HYPERVISOR_hvm_op,                  hvm_op,            2), // 34
+
+   HYPXY(__HYPERVISOR_sysctl,                  sysctl,            1), // 35
+   HYPXY(__HYPERVISOR_domctl,                  domctl,            1), // 36
+   //    __HYPERVISOR_kexec_op                                        // 37
+   //    __HYPERVISOR_tmem_op                                         // 38
+};
+
+static void bad_before ( ThreadId              tid,
+                         SyscallArgLayout*     layout,
+                         /*MOD*/SyscallArgs*   args,
+                         /*OUT*/SyscallStatus* status,
+                         /*OUT*/UWord*         flags )
+{
+   VG_(dmsg)("WARNING: unhandled hypercall: %s\n",
+      VG_SYSNUM_STRING_EXTRA(args->sysno));
+   if (VG_(clo_verbosity) > 1) {
+      VG_(get_and_pp_StackTrace)(tid, VG_(clo_backtrace_size));
+   }
+   VG_(dmsg)("You may be able to write your own handler.\n");
+   VG_(dmsg)("Read the file README_MISSING_SYSCALL_OR_IOCTL.\n");
+   VG_(dmsg)("Nevertheless we consider this a bug.  Please report\n");
+   VG_(dmsg)("it at http://valgrind.org/support/bug_reports.html &\n");
+   VG_(dmsg)("http://wiki.xen.org/wiki/Reporting_Bugs_against_Xen.\n");
+
+   SET_STATUS_Failure(VKI_ENOSYS);
+}
+
+static XenHypercallTableEntry bad_hyper =
+{ { bad_before, NULL }, 0 };
+
+static XenHypercallTableEntry* ML_(get_xen_hypercall_entry) ( UInt sysno )
+{
+   XenHypercallTableEntry *ret = &bad_hyper;
+
+   const UInt hypercall_table_size
+      = sizeof(hypercall_table) / sizeof(hypercall_table[0]);
+
+   /* Is it in the contiguous initial section of the table? */
+   if (sysno < hypercall_table_size) {
+      XenHypercallTableEntry* ent = &hypercall_table[sysno];
+      if (ent->entry.before != NULL)
+         ret = ent;
+   }
+
+   /* Can't find a wrapper */
+   return ret;
+}
+
+DEFN_PRE_TEMPLATE(xen, hypercall)
+{
+   XenHypercallTableEntry *ent = ML_(get_xen_hypercall_entry)(SYSNO);
+
+   /* Return number of arguments consumed */
+   ARG8 = ent->nr_args;
+
+   vg_assert(ent);
+   vg_assert(ent->entry.before);
+   (ent->entry.before)( tid, layout, arrghs, status, flags );
+
+}
+
+DEFN_POST_TEMPLATE(xen, hypercall)
+{
+   XenHypercallTableEntry *ent = ML_(get_xen_hypercall_entry)(SYSNO);
+
+   /* Return number of arguments consumed */
+   ARG8 = ent->nr_args;
+
+   vg_assert(ent);
+   if (ent->entry.after)
+      (ent->entry.after)( tid, arrghs, status );
+}
diff --git a/include/Makefile.am b/include/Makefile.am
index ade27c2..f1a3443 100644
--- a/include/Makefile.am
+++ b/include/Makefile.am
@@ -64,4 +64,5 @@ nobase_pkginclude_HEADERS = \
        vki/vki-scnums-arm-linux.h      \
        vki/vki-scnums-s390x-linux.h    \
        vki/vki-scnums-mips32-linux.h   \
-       vki/vki-scnums-darwin.h
+       vki/vki-scnums-darwin.h         \
+       vki/vki-xen.h
diff --git a/include/pub_tool_vki.h b/include/pub_tool_vki.h
index a0996f9..6598106 100644
--- a/include/pub_tool_vki.h
+++ b/include/pub_tool_vki.h
@@ -47,6 +47,7 @@

 #if defined(VGO_linux)
 #  include "vki/vki-linux.h"
+#  include "vki/vki-xen.h"
 #elif defined(VGO_darwin)
 #  include "vki/vki-darwin.h"
 #else
diff --git a/include/vki/vki-linux.h b/include/vki/vki-linux.h
index c18195e..4fdc353 100644
--- a/include/vki/vki-linux.h
+++ b/include/vki/vki-linux.h
@@ -3009,6 +3009,50 @@ struct vki_hwtstamp_config {
 #define VKI_UI_SET_SWBIT               _VKI_IOW(VKI_UINPUT_IOCTL_BASE, 109, int)
 #define VKI_UI_SET_PROPBIT             _VKI_IOW(VKI_UINPUT_IOCTL_BASE, 110, int)

+//----------------------------------------------------------------------
+// Xen privcmd IOCTL
+//----------------------------------------------------------------------
+
+typedef unsigned long __vki_xen_pfn_t;
+
+struct vki_xen_privcmd_hypercall {
+       __vki_u64 op;
+       __vki_u64 arg[5];
+};
+
+struct vki_xen_privcmd_mmap_entry {
+        __vki_u64 va;
+        __vki_u64 mfn;
+        __vki_u64 npages;
+};
+
+struct vki_xen_privcmd_mmap {
+        int num;
+        __vki_u16 dom; /* target domain */
+        struct vki_xen_privcmd_mmap_entry *entry;
+};
+
+struct vki_xen_privcmd_mmapbatch {
+        int num;     /* number of pages to populate */
+        __vki_u16 dom; /* target domain */
+        __vki_u64 addr;  /* virtual address */
+        __vki_xen_pfn_t *arr; /* array of mfns - top nibble set on err */
+};
+
+struct vki_xen_privcmd_mmapbatch_v2 {
+        unsigned int num; /* number of pages to populate */
+        __vki_u16 dom;      /* target domain */
+        __vki_u64 addr;       /* virtual address */
+        const __vki_xen_pfn_t *arr; /* array of mfns */
+        int __user *err;  /* array of error codes */
+};
+
+#define VKI_XEN_IOCTL_PRIVCMD_HYPERCALL    _VKI_IOC(_VKI_IOC_NONE, 'P', 0, sizeof(struct vki_xen_privcmd_hypercall))
+#define VKI_XEN_IOCTL_PRIVCMD_MMAP         _VKI_IOC(_VKI_IOC_NONE, 'P', 2, sizeof(struct vki_xen_privcmd_mmap))
+
+#define VKI_XEN_IOCTL_PRIVCMD_MMAPBATCH    _VKI_IOC(_VKI_IOC_NONE, 'P', 3, sizeof(struct vki_xen_privcmd_mmapbatch))
+#define VKI_XEN_IOCTL_PRIVCMD_MMAPBATCH_V2 _VKI_IOC(_VKI_IOC_NONE, 'P', 4, sizeof(struct vki_xen_privcmd_mmapbatch_v2))
+
 #endif // __VKI_LINUX_H

 /*--------------------------------------------------------------------*/
diff --git a/include/vki/vki-xen.h b/include/vki/vki-xen.h
new file mode 100644
index 0000000..7842cc9
--- /dev/null
+++ b/include/vki/vki-xen.h
@@ -0,0 +1,8 @@
+#ifndef __VKI_XEN_H
+#define __VKI_XEN_H
+
+#endif // __VKI_XEN_H
+
+/*--------------------------------------------------------------------*/
+/*--- 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 Tue Sep 04 16:21:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Sep 2012 16: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 1T8vrw-0004x4-Jc; Tue, 04 Sep 2012 16:20:52 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1T8vru-0004wv-Us
	for xen-devel@lists.xen.org; Tue, 04 Sep 2012 16:20:51 +0000
Received: from [85.158.143.99:58144] by server-3.bemta-4.messagelabs.com id
	5D/33-08232-26A26405; Tue, 04 Sep 2012 16:20:50 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1346775649!18724886!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTE3MTg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24343 invoked from network); 4 Sep 2012 16:20:49 -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;
	4 Sep 2012 16:20:49 -0000
X-IronPort-AV: E=Sophos;i="4.80,367,1344211200"; d="scan'208";a="14340881"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Sep 2012 16:20: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.279.1; Tue, 4 Sep 2012
	17:20:36 +0100
Message-ID: <1346775635.6712.63.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "valgrind-developers@lists.sourceforge.net"
	<valgrind-developers@lists.sourceforge.net>, xen-devel
	<xen-devel@lists.xen.org>
Date: Tue, 4 Sep 2012 17:20:35 +0100
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Subject: [Xen-devel] [PATCH] valgrind: Support for ioctls used by Xen
 toolstack processes.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Under Xen the toolstack is responsible for managing the domains in
the system, e.g. creating, destroying, and otherwise manipulating
them.

To do this it uses a number of ioctls on the /proc/xen/privcmd
device. Most of these (the MMAPBATCH ones) simply set things up such
that a subsequenct mmap call will map the desired guest memory. Since
valgrind has no way of knowing what the memory contains we assume
that it is all initialised (to do otherwise would require valgrind to
be observing the complete state of the system and not just the given
process).

The most interesting ioctl is XEN_IOCTL_PRIVCMD_HYPERCALL which
allows the toolstack to make arbitrary hypercalls. Although the
mechanism here is specific to the OS of the guest running the
toolstack the hypercalls themselves are defined solely by the
hypervisor. Therefore I have split support for this ioctl into a part
in syswrap-linux.c which handles the ioctl itself and passes things
onto a new syswrap-xen.c which handles the specifics of the
hypercalls themselves. Porting this to another OS should just be a
matter of wiring up syswrap-$OS.c to decode the ioctl and call into
syswrap-xen.c. In the future we may want to split this into
syswrap-$ARCH-xen.c but for now this is x86 only.

The hypercall coverage here is pretty small but is enough to get
reasonable(-ish) results out of the xl toolstack when listing,
creating and destroying domains.

One issue is that the hypercalls which are exlusively used by the
toolstacks (as opposed to those used by guest operating systems) are
not considered a stable ABI, since the hypervisor and the lowlevel
tools are considered a matched pair. This covers the sysctl and
domctl hypercalls which are a fairly large chunk of the support
here. I'm not sure how to solve this without invoking a massive
amount of duplication. Right now this targets the Xen unstable
interface (which will shortly be released as Xen 4.2), perhaps I can
get away with deferring this problem until the first change ;-).

On the plus side the vast majority of hypercalls are not of interest
to the toolstack (they are used by guests) so we can get away without
implementing them.

There are some other wrinkles here I've not been sure how to solve:

Firstly, di_notify_mmap tries to read from the magic proc device:
     --20208-- WARNING: Serious error when reading debug info
     --20208-- When reading debug info from /proc/xen/privcmd:
     --20208-- can't read file to inspect ELF header

I've hacked around this with an explicit check for /proc/xen.
Hopefully someone can point to the right solution.

Secondly, a hypercall only reads as many words from the ioctl arg
struct as there are actual arguments to that hypercall and the
toolstack only initialises the arguments which are used. However
there is no space in the DEFN_PRE_TEMPLATE prototype to allow this to
be communicated from syswrap-xen.c back to syswrap-linux.c. Since a
hypercall can have at most 5 arguments I have hackily stolen ARG8 for
this purpose.
---
 configure.in                           |   19 +
 coregrind/Makefile.am                  |    8 +-
 coregrind/m_debuginfo/debuginfo.c      |    9 +
 coregrind/m_syswrap/priv_syswrap-xen.h |   10 +
 coregrind/m_syswrap/syswrap-linux.c    |  107 ++++-
 coregrind/m_syswrap/syswrap-xen.c      | 1023 ++++++++++++++++++++++++++++++++
 include/Makefile.am                    |    3 +-
 include/pub_tool_vki.h                 |    1 +
 include/vki/vki-linux.h                |   44 ++
 include/vki/vki-xen.h                  |    8 +
 10 files changed, 1229 insertions(+), 3 deletions(-)
 create mode 100644 coregrind/m_syswrap/priv_syswrap-xen.h
 create mode 100644 coregrind/m_syswrap/syswrap-xen.c
 create mode 100644 include/vki/vki-xen.h

diff --git a/configure.in b/configure.in
index b385aed..d94644c 100644
--- a/configure.in
+++ b/configure.in
@@ -2012,6 +2012,25 @@ AC_ARG_WITH(mpicc,
 )
 AC_SUBST(MPI_CC)

+#----------------------------------------------------------------------------
+# Xen checks
+#----------------------------------------------------------------------------
+AC_ARG_ENABLE(xen,
+      [  --enable-xen            Enable support for Xen hypervisor],
+      [vg_cv_xen=$enableval],
+      [vg_cv_xen=no])
+
+AC_ARG_WITH(xen,
+   [  --with-xen=             Specify location of Xen headers],
+   XEN_CFLAGS=-I$withval
+)
+AC_SUBST(XEN_CFLAGS)
+
+AM_CONDITIONAL([ENABLE_XEN], [test x$vg_cv_xen = xyes])
+if test x"$vg_cv_xen" = xyes; then
+    AC_DEFINE([ENABLE_XEN], 1, [configured to support Xen])
+fi
+
 ## We AM_COND_IF here instead of automake "if" in mpi/Makefile.am so that we can
 ## use these values in the check for a functioning mpicc.
 ##
diff --git a/coregrind/Makefile.am b/coregrind/Makefile.am
index 01015a7..58a7dce 100644
--- a/coregrind/Makefile.am
+++ b/coregrind/Makefile.am
@@ -224,6 +224,7 @@ noinst_HEADERS = \
        m_syswrap/priv_syswrap-linux-variants.h \
        m_syswrap/priv_syswrap-darwin.h \
        m_syswrap/priv_syswrap-main.h \
+       m_syswrap/priv_syswrap-xen.h \
        m_ume/priv_ume.h

 #----------------------------------------------------------------------------
@@ -371,6 +372,11 @@ COREGRIND_SOURCES_COMMON = \
        m_ume/main.c \
        m_ume/script.c

+if ENABLE_XEN
+COREGRIND_SOURCES_COMMON += m_syswrap/syswrap-xen.c
+CFLAGS += @XEN_CFLAGS@
+endif
+
 libcoregrind_@VGCONF_ARCH_PRI@_@VGCONF_OS@_a_SOURCES = \
     $(COREGRIND_SOURCES_COMMON)
 nodist_libcoregrind_@VGCONF_ARCH_PRI@_@VGCONF_OS@_a_SOURCES = \
@@ -378,7 +384,7 @@ nodist_libcoregrind_@VGCONF_ARCH_PRI@_@VGCONF_OS@_a_SOURCES = \
 libcoregrind_@VGCONF_ARCH_PRI@_@VGCONF_OS@_a_CPPFLAGS = \
     $(AM_CPPFLAGS_@VGCONF_PLATFORM_PRI_CAPS@)
 libcoregrind_@VGCONF_ARCH_PRI@_@VGCONF_OS@_a_CFLAGS = \
-    $(AM_CFLAGS_@VGCONF_PLATFORM_PRI_CAPS@)
+    $(AM_CFLAGS_@VGCONF_PLATFORM_PRI_CAPS@) @XEN_CFLAGS@
 libcoregrind_@VGCONF_ARCH_PRI@_@VGCONF_OS@_a_CCASFLAGS = \
     $(AM_CCASFLAGS_@VGCONF_PLATFORM_PRI_CAPS@)
 if ENABLE_LINUX_TICKET_LOCK_PRIMARY
diff --git a/coregrind/m_debuginfo/debuginfo.c b/coregrind/m_debuginfo/debuginfo.c
index 218547b..b634ce0 100644
--- a/coregrind/m_debuginfo/debuginfo.c
+++ b/coregrind/m_debuginfo/debuginfo.c
@@ -729,6 +729,15 @@ ULong VG_(di_notify_mmap)( Addr a, Bool allow_SkFileV, Int use_fd )
    if (!filename)
       return 0;

+   /*
+    * Cannot read from these magic files:
+    * --20208-- WARNING: Serious error when reading debug info
+    * --20208-- When reading debug info from /proc/xen/privcmd:
+    * --20208-- can't read file to inspect ELF header
+    */
+   if (VG_(strncmp)(filename, "/proc/xen/", 10) == 0)
+      return 0;
+
    if (debug)
       VG_(printf)("di_notify_mmap-2: %s\n", filename);

diff --git a/coregrind/m_syswrap/priv_syswrap-xen.h b/coregrind/m_syswrap/priv_syswrap-xen.h
new file mode 100644
index 0000000..4dc4748
--- /dev/null
+++ b/coregrind/m_syswrap/priv_syswrap-xen.h
@@ -0,0 +1,10 @@
+#ifndef __PRIV_SYSWRAP_XEN_H
+#define __PRIV_SYSWRAP_XEN_H
+
+DECL_TEMPLATE(xen, hypercall);
+
+#endif   // __PRIV_SYSWRAP_XEN_H
+
+/*--------------------------------------------------------------------*/
+/*--- end                                                          ---*/
+/*--------------------------------------------------------------------*/
diff --git a/coregrind/m_syswrap/syswrap-linux.c b/coregrind/m_syswrap/syswrap-linux.c
index 2f1155f..22c1842 100644
--- a/coregrind/m_syswrap/syswrap-linux.c
+++ b/coregrind/m_syswrap/syswrap-linux.c
@@ -63,7 +63,7 @@
 #include "priv_types_n_macros.h"
 #include "priv_syswrap-generic.h"
 #include "priv_syswrap-linux.h"
-
+#include "priv_syswrap-xen.h"

 // Run a thread from beginning to end and return the thread's
 // scheduler-return-code.
@@ -5527,6 +5527,73 @@ PRE(sys_ioctl)
    case VKI_KVM_RUN:
       break;

+#ifdef ENABLE_XEN
+   case VKI_XEN_IOCTL_PRIVCMD_HYPERCALL: {
+      SyscallArgs harrghs;
+      struct vki_xen_privcmd_hypercall *args =
+         (struct vki_xen_privcmd_hypercall *)(ARG3);
+
+      if (!args)
+         break;
+
+      VG_(memset)(&harrghs, 0, sizeof(harrghs));
+      harrghs.sysno = args->op;
+      harrghs.arg1 = args->arg[0];
+      harrghs.arg2 = args->arg[1];
+      harrghs.arg3 = args->arg[2];
+      harrghs.arg4 = args->arg[3];
+      harrghs.arg5 = args->arg[4];
+      harrghs.arg6 = harrghs.arg7 = harrghs.arg8 = 0;
+
+      WRAPPER_PRE_NAME(xen, hypercall) (tid, layout, &harrghs, status, flags);
+
+      /* HACK. arg8 is used to return the number of hypercall
+       * arguments actually consumed! */
+      PRE_MEM_READ("hypercall", ARG3, sizeof(args->op) +
+                   ( sizeof(args->arg[0]) * harrghs.arg8 ) );
+
+      break;
+   }
+
+   case VKI_XEN_IOCTL_PRIVCMD_MMAP: {
+       struct vki_xen_privcmd_mmap *args =
+           (struct vki_xen_privcmd_mmap *)(ARG3);
+       PRE_MEM_READ("VKI_XEN_IOCTL_PRIVCMD_MMAP",
+                    (Addr)&args->num, sizeof(args->num));
+       PRE_MEM_READ("VKI_XEN_IOCTL_PRIVCMD_MMAP",
+                    (Addr)&args->dom, sizeof(args->dom));
+       PRE_MEM_READ("VKI_XEN_IOCTL_PRIVCMD_MMAP",
+                    (Addr)args->entry, sizeof(*(args->entry)) * args->num);
+      break;
+   }
+   case VKI_XEN_IOCTL_PRIVCMD_MMAPBATCH: {
+       struct vki_xen_privcmd_mmapbatch *args =
+           (struct vki_xen_privcmd_mmapbatch *)(ARG3);
+       PRE_MEM_READ("VKI_XEN_IOCTL_PRIVCMD_MMAPBATCH",
+                    (Addr)&args->num, sizeof(args->num));
+       PRE_MEM_READ("VKI_XEN_IOCTL_PRIVCMD_MMAPBATCH",
+                    (Addr)&args->dom, sizeof(args->dom));
+       PRE_MEM_READ("VKI_XEN_IOCTL_PRIVCMD_MMAPBATCH",
+                    (Addr)&args->addr, sizeof(args->addr));
+       PRE_MEM_READ("VKI_XEN_IOCTL_PRIVCMD_MMAPBATCH",
+                    (Addr)args->arr, sizeof(*(args->arr)) * args->num);
+      break;
+   }
+   case VKI_XEN_IOCTL_PRIVCMD_MMAPBATCH_V2: {
+       struct vki_xen_privcmd_mmapbatch_v2 *args =
+           (struct vki_xen_privcmd_mmapbatch_v2 *)(ARG3);
+       PRE_MEM_READ("VKI_XEN_IOCTL_PRIVCMD_MMAPBATCH_V2",
+                    (Addr)&args->num, sizeof(args->num));
+       PRE_MEM_READ("VKI_XEN_IOCTL_PRIVCMD_MMAPBATCH_V2",
+                    (Addr)&args->dom, sizeof(args->dom));
+       PRE_MEM_READ("VKI_XEN_IOCTL_PRIVCMD_MMAPBATCH_V2",
+                    (Addr)&args->addr, sizeof(args->addr));
+       PRE_MEM_READ("VKI_XEN_IOCTL_PRIVCMD_MMAPBATCH_V2",
+                    (Addr)args->arr, sizeof(*(args->arr)) * args->num);
+      break;
+   }
+#endif
+
    default:
       /* EVIOC* are variable length and return size written on success */
       switch (ARG2 & ~(_VKI_IOC_SIZEMASK << _VKI_IOC_SIZESHIFT)) {
@@ -6524,6 +6591,44 @@ POST(sys_ioctl)
    case VKI_KVM_S390_INITIAL_RESET:
       break;

+#ifdef ENABLE_XEN
+   case VKI_XEN_IOCTL_PRIVCMD_HYPERCALL: {
+      SyscallArgs harrghs;
+      struct vki_xen_privcmd_hypercall *args =
+         (struct vki_xen_privcmd_hypercall *)(ARG3);
+
+      if (!args)
+         break;
+
+      VG_(memset)(&harrghs, 0, sizeof(harrghs));
+      harrghs.sysno = args->op;
+      harrghs.arg1 = args->arg[0];
+      harrghs.arg2 = args->arg[1];
+      harrghs.arg3 = args->arg[2];
+      harrghs.arg4 = args->arg[3];
+      harrghs.arg5 = args->arg[4];
+      harrghs.arg6 = harrghs.arg7 = harrghs.arg8 = 0;
+
+      WRAPPER_POST_NAME(xen, hypercall) (tid, &harrghs, status);
+      break;
+   };
+
+   case VKI_XEN_IOCTL_PRIVCMD_MMAP:
+      break;
+   case VKI_XEN_IOCTL_PRIVCMD_MMAPBATCH: {
+       struct vki_xen_privcmd_mmapbatch *args =
+           (struct vki_xen_privcmd_mmapbatch *)(ARG3);
+       POST_MEM_WRITE((Addr)args->arr, sizeof(*(args->arr)) * args->num);
+      }
+      break;
+   case VKI_XEN_IOCTL_PRIVCMD_MMAPBATCH_V2: {
+       struct vki_xen_privcmd_mmapbatch_v2 *args =
+           (struct vki_xen_privcmd_mmapbatch_v2 *)(ARG3);
+       POST_MEM_WRITE((Addr)args->err, sizeof(*(args->err)) * args->num);
+      }
+      break;
+#endif
+
    default:
       /* EVIOC* are variable length and return size written on success */
       switch (ARG2 & ~(_VKI_IOC_SIZEMASK << _VKI_IOC_SIZESHIFT)) {
diff --git a/coregrind/m_syswrap/syswrap-xen.c b/coregrind/m_syswrap/syswrap-xen.c
new file mode 100644
index 0000000..00192bf
--- /dev/null
+++ b/coregrind/m_syswrap/syswrap-xen.c
@@ -0,0 +1,1023 @@
+
+/*--------------------------------------------------------------------*/
+/*--- Xen Hypercalls                                 syswrap-xen.c ---*/
+/*--------------------------------------------------------------------*/
+
+/*
+   This file is part of Valgrind, a dynamic binary instrumentation
+   framework.
+
+   Copyright (C) 2012 Citrix Systems
+      ian.campbell@citrix.com
+
+   This program is free software; you can redistribute it and/or
+   modify it under the terms of the GNU General Public License as
+   published by the Free Software Foundation; either version 2 of the
+   License, or (at your option) any later version.
+
+   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.
+
+   The GNU General Public License is contained in the file COPYING.
+*/
+
+#include "pub_core_basics.h"
+#include "pub_core_vki.h"
+#include "pub_core_vkiscnums.h"
+#include "pub_core_libcsetjmp.h"   // to keep _threadstate.h happy
+#include "pub_core_threadstate.h"
+#include "pub_core_aspacemgr.h"
+#include "pub_core_debuginfo.h"    // VG_(di_notify_*)
+#include "pub_core_transtab.h"     // VG_(discard_translations)
+#include "pub_core_xarray.h"
+#include "pub_core_clientstate.h"
+#include "pub_core_debuglog.h"
+#include "pub_core_libcbase.h"
+#include "pub_core_libcassert.h"
+#include "pub_core_libcfile.h"
+#include "pub_core_libcprint.h"
+#include "pub_core_libcproc.h"
+#include "pub_core_libcsignal.h"
+#include "pub_core_mallocfree.h"
+#include "pub_core_tooliface.h"
+#include "pub_core_options.h"
+#include "pub_core_scheduler.h"
+#include "pub_core_signals.h"
+#include "pub_core_syscall.h"
+#include "pub_core_syswrap.h"
+#include "pub_core_stacktrace.h"    // For VG_(get_and_pp_StackTrace)()
+
+#include "priv_types_n_macros.h"
+#include "priv_syswrap-generic.h"
+#include "priv_syswrap-xen.h"
+
+#include <stdint.h>
+
+#define __XEN_TOOLS__
+
+#include <xen/xen.h>
+#include <xen/sysctl.h>
+#include <xen/domctl.h>
+#include <xen/memory.h>
+#include <xen/event_channel.h>
+#include <xen/version.h>
+
+#include <xen/hvm/hvm_op.h>
+
+#define PRE(name) static DEFN_PRE_TEMPLATE(xen, name)
+#define POST(name) static DEFN_POST_TEMPLATE(xen, name)
+
+static void bad_subop ( ThreadId              tid,
+                        SyscallArgLayout*     layout,
+                        /*MOD*/SyscallArgs*   args,
+                        /*OUT*/SyscallStatus* status,
+                        /*OUT*/UWord*         flags,
+                        const char*           hypercall,
+                        UWord                 subop)
+{
+   VG_(dmsg)("WARNING: unhandled %s subop: %ld\n",
+             hypercall, subop);
+   if (VG_(clo_verbosity) > 1) {
+      VG_(get_and_pp_StackTrace)(tid, VG_(clo_backtrace_size));
+   }
+   VG_(dmsg)("You may be able to write your own handler.\n");
+   VG_(dmsg)("Read the file README_MISSING_SYSCALL_OR_IOCTL.\n");
+   VG_(dmsg)("Nevertheless we consider this a bug.  Please report\n");
+   VG_(dmsg)("it at http://valgrind.org/support/bug_reports.html &\n");
+   VG_(dmsg)("http://wiki.xen.org/wiki/Reporting_Bugs_against_Xen.\n");
+
+   SET_STATUS_Failure(VKI_ENOSYS);
+}
+
+PRE(memory_op)
+{
+   PRINT("__HYPERVISOR_memory_op ( %ld, %lx )", ARG1, ARG2);
+
+   switch (ARG1) {
+   case XENMEM_set_memory_map: {
+      xen_foreign_memory_map_t *arg =
+         (xen_foreign_memory_map_t *)(unsigned int)ARG2;
+      PRE_MEM_READ("XENMEM_set_memory_map",
+                   (Addr)&arg->domid, sizeof(arg->domid));
+      PRE_MEM_READ("XENMEM_set_memory_map",
+                   (Addr)&arg->map, sizeof(arg->map));
+      break;
+   }
+   case XENMEM_increase_reservation:
+   case XENMEM_decrease_reservation:
+   case XENMEM_populate_physmap: {
+      struct xen_memory_reservation *memory_reservation =
+         (struct xen_memory_reservation *)(unsigned int)ARG2;
+      char *which;
+
+      switch (ARG1) {
+      case XENMEM_increase_reservation:
+         which = "XENMEM_increase_reservation";
+         break;
+      case XENMEM_decrease_reservation:
+         which = "XENMEM_decrease_reservation";
+         PRE_MEM_READ(which,
+                      (Addr)memory_reservation->extent_start.p,
+                      sizeof(xen_pfn_t) * memory_reservation->nr_extents);
+      case XENMEM_populate_physmap:
+         which = "XENMEM_populate_physmap";
+         PRE_MEM_READ(which,
+                      (Addr)memory_reservation->extent_start.p,
+                      sizeof(xen_pfn_t) * memory_reservation->nr_extents);
+         break;
+      default:
+         which = "XENMEM_unknown";
+         break;
+      }
+
+      PRE_MEM_READ(which,
+                   (Addr)&memory_reservation->extent_start,
+                   sizeof(memory_reservation->extent_start));
+      PRE_MEM_READ(which,
+                   (Addr)&memory_reservation->nr_extents,
+                   sizeof(memory_reservation->nr_extents));
+      PRE_MEM_READ(which,
+                   (Addr)&memory_reservation->extent_order,
+                   sizeof(memory_reservation->extent_order));
+      PRE_MEM_READ(which,
+                   (Addr)&memory_reservation->mem_flags,
+                   sizeof(memory_reservation->mem_flags));
+      PRE_MEM_READ(which,
+                   (Addr)&memory_reservation->domid,
+                   sizeof(memory_reservation->domid));
+      break;
+   }
+
+   default:
+      bad_subop(tid, layout, arrghs, status, flags,
+                "__HYPERVISOR_memory_op", ARG1);
+      break;
+   }
+}
+
+PRE(mmuext_op)
+{
+   mmuext_op_t *ops = (void *)(unsigned int)ARG1;
+   unsigned int i, nr = ARG2;
+
+
+   for (i=0; i<nr; i++) {
+      mmuext_op_t *op = ops + i;
+      PRE_MEM_READ("__HYPERVISOR_MMUEXT_OP",
+                   (Addr)&op->cmd, sizeof(op->cmd));
+      switch(op->cmd) {
+      case MMUEXT_PIN_L1_TABLE:
+      case MMUEXT_PIN_L2_TABLE:
+      case MMUEXT_PIN_L3_TABLE:
+      case MMUEXT_PIN_L4_TABLE:
+      case MMUEXT_UNPIN_TABLE:
+      case MMUEXT_NEW_BASEPTR:
+      case MMUEXT_CLEAR_PAGE:
+      case MMUEXT_COPY_PAGE:
+      case MMUEXT_MARK_SUPER:
+      case MMUEXT_UNMARK_SUPER:
+         PRE_MEM_READ("__HYPERVISOR_MMUEXT_OP arg1.mfn",
+                      (Addr)&op->arg1.mfn,
+                      sizeof(op->arg1.mfn));
+         break;
+
+      case MMUEXT_INVLPG_LOCAL:
+      case MMUEXT_INVLPG_ALL:
+      case MMUEXT_SET_LDT:
+         PRE_MEM_READ("__HYPERVISOR_MMUEXT_OP arg1.mfn",
+                      (Addr)&op->arg1.linear_addr,
+                      sizeof(op->arg1.linear_addr));
+         break;
+
+      case MMUEXT_TLB_FLUSH_LOCAL:
+      case MMUEXT_TLB_FLUSH_MULTI:
+      case MMUEXT_INVLPG_MULTI:
+      case MMUEXT_TLB_FLUSH_ALL:
+      case MMUEXT_FLUSH_CACHE:
+      case MMUEXT_NEW_USER_BASEPTR:
+      case MMUEXT_FLUSH_CACHE_GLOBAL:
+         /* None */
+         break;
+      }
+
+      switch(op->cmd) {
+      case MMUEXT_SET_LDT:
+         PRE_MEM_READ("__HYPERVISOR_MMUEXT_OP arg2.nr_ents",
+                      (Addr)&op->arg2.nr_ents,
+                      sizeof(op->arg2.nr_ents));
+         break;
+
+      case MMUEXT_TLB_FLUSH_MULTI:
+      case MMUEXT_INVLPG_MULTI:
+         /* How many??? */
+         PRE_MEM_READ("__HYPERVISOR_MMUEXT_OP arg2.vcpumask",
+                      (Addr)&op->arg2.vcpumask,
+                      sizeof(op->arg2.vcpumask));
+         break;
+
+      case MMUEXT_COPY_PAGE:
+         PRE_MEM_READ("__HYPERVISOR_MMUEXT_OP arg2.src_mfn",
+                      (Addr)&op->arg2.src_mfn,
+                      sizeof(op->arg2.src_mfn));
+         break;
+
+      case MMUEXT_PIN_L1_TABLE:
+      case MMUEXT_PIN_L2_TABLE:
+      case MMUEXT_PIN_L3_TABLE:
+      case MMUEXT_PIN_L4_TABLE:
+      case MMUEXT_UNPIN_TABLE:
+      case MMUEXT_NEW_BASEPTR:
+      case MMUEXT_TLB_FLUSH_LOCAL:
+      case MMUEXT_INVLPG_LOCAL:
+      case MMUEXT_TLB_FLUSH_ALL:
+      case MMUEXT_INVLPG_ALL:
+      case MMUEXT_FLUSH_CACHE:
+      case MMUEXT_NEW_USER_BASEPTR:
+      case MMUEXT_CLEAR_PAGE:
+      case MMUEXT_FLUSH_CACHE_GLOBAL:
+      case MMUEXT_MARK_SUPER:
+      case MMUEXT_UNMARK_SUPER:
+         /* None */
+         break;
+      }
+   }
+}
+
+static void pre_evtchn_op(ThreadId tid,
+                          SyscallArgLayout*     layout,
+                          /*MOD*/SyscallArgs*   arrghs,
+                          /*OUT*/SyscallStatus* status,
+                          /*OUT*/UWord*         flags,
+                          __vki_u32 cmd, void *arg, int compat)
+{
+   PRINT("__HYPERVISOR_event_channel_op%s ( %d, %p )",
+         compat ? "_compat" : "", cmd, arg);
+
+   switch (cmd) {
+   case EVTCHNOP_alloc_unbound: {
+      struct evtchn_alloc_unbound *alloc_unbound = arg;
+      PRE_MEM_READ("EVTCHNOP_alloc_unbound",
+                   (Addr)&alloc_unbound->dom, sizeof(alloc_unbound->dom));
+      PRE_MEM_READ("EVTCHNOP_alloc_unbound",
+                   (Addr)&alloc_unbound->remote_dom,
+                   sizeof(alloc_unbound->remote_dom));
+      break;
+   }
+   default:
+      if ( compat )
+         bad_subop(tid, layout, arrghs, status, flags,
+                   "__HYPERVISOR_event_channel_op_compat", cmd);
+      else
+         bad_subop(tid, layout, arrghs, status, flags,
+                   "__HYPERVISOR_event_channel_op", cmd);
+      break;
+   }
+}
+
+PRE(evtchn_op)
+{
+   pre_evtchn_op(tid, layout, arrghs, status, flags,
+                 ARG1, (void *)(unsigned int)ARG2, 0);
+}
+
+PRE(evtchn_op_compat)
+{
+   struct evtchn_op *evtchn = (struct evtchn_op *)(unsigned int)ARG1;
+   PRE_MEM_READ("__HYPERVISOR_event_channel_op_compat",
+                ARG1, sizeof(*evtchn));
+
+   pre_evtchn_op(tid, layout, arrghs, status, flags,
+                 evtchn->cmd, &evtchn->u, 1);
+}
+
+PRE(xen_version)
+{
+   PRINT("__HYPERVISOR_xen_version ( %ld, %lx )", ARG1, ARG2);
+
+   switch (ARG1) {
+   case XENVER_version:
+   case XENVER_extraversion:
+   case XENVER_compile_info:
+   case XENVER_capabilities:
+   case XENVER_changeset:
+   case XENVER_platform_parameters:
+   case XENVER_get_features:
+   case XENVER_pagesize:
+   case XENVER_guest_handle:
+   case XENVER_commandline:
+      /* No inputs */
+      break;
+
+   default:
+      bad_subop(tid, layout, arrghs, status, flags,
+                "__HYPERVISOR_xen_version", ARG1);
+      break;
+   }
+}
+
+PRE(grant_table_op)
+{
+   PRINT("__HYPERVISOR_grant_table_op ( %ld, 0x%lx, %ld )", ARG1, ARG2, ARG3);
+   switch (ARG1) {
+   case GNTTABOP_setup_table: {
+      struct gnttab_setup_table *gst = (void *)(intptr_t)ARG2;
+      PRE_MEM_READ("GNTTABOP_setup_table", (Addr)&gst->dom, sizeof(gst->dom));
+      PRE_MEM_READ("GNTTABOP_setup_table",
+                   (Addr)&gst->nr_frames, sizeof(gst->nr_frames));
+      break;
+   }
+   default:
+      bad_subop(tid, layout, arrghs, status, flags,
+                "__HYPERVISOR_grant_table_op", ARG1);
+      break;
+   }
+}
+
+PRE(sysctl) {
+   struct xen_sysctl *sysctl = (struct xen_sysctl *)(unsigned int)ARG1;
+
+   PRINT("__HYPERVISOR_sysctl ( %d )", sysctl->cmd);
+
+   /*
+    * Common part of xen_sysctl:
+    *    uint32_t cmd;
+    *    uint32_t interface_version;
+    */
+   PRE_MEM_READ("__HYPERVISOR_sysctl", ARG1,
+                sizeof(uint32_t) + sizeof(uint32_t));
+
+   if (!sysctl || sysctl->interface_version != XEN_SYSCTL_INTERFACE_VERSION)
+      /* BUG ? */
+      return;
+
+#define __PRE_XEN_SYSCTL_READ(_sysctl, _union, _field)  \
+      PRE_MEM_READ("XEN_SYSCTL_" # _sysctl,             \
+                   (Addr)&sysctl->u._union._field,      \
+                   sizeof(sysctl->u._union._field))
+#define PRE_XEN_SYSCTL_READ(_sysctl, _field) \
+      __PRE_XEN_SYSCTL_READ(_sysctl, _sysctl, _field)
+
+   switch (sysctl->cmd) {
+   case XEN_SYSCTL_getdomaininfolist:
+      PRE_XEN_SYSCTL_READ(getdomaininfolist, first_domain);
+      PRE_XEN_SYSCTL_READ(getdomaininfolist, max_domains);
+      PRE_XEN_SYSCTL_READ(getdomaininfolist, buffer);
+      break;
+
+   case XEN_SYSCTL_cpupool_op:
+      PRE_XEN_SYSCTL_READ(cpupool_op, op);
+
+      switch(sysctl->u.cpupool_op.op) {
+      case XEN_SYSCTL_CPUPOOL_OP_CREATE:
+      case XEN_SYSCTL_CPUPOOL_OP_DESTROY:
+      case XEN_SYSCTL_CPUPOOL_OP_INFO:
+      case XEN_SYSCTL_CPUPOOL_OP_ADDCPU:
+      case XEN_SYSCTL_CPUPOOL_OP_RMCPU:
+      case XEN_SYSCTL_CPUPOOL_OP_MOVEDOMAIN:
+         PRE_XEN_SYSCTL_READ(cpupool_op, cpupool_id);
+      }
+
+      if (sysctl->u.cpupool_op.op == XEN_SYSCTL_CPUPOOL_OP_CREATE)
+         PRE_XEN_SYSCTL_READ(cpupool_op, sched_id);
+
+      if (sysctl->u.cpupool_op.op == XEN_SYSCTL_CPUPOOL_OP_MOVEDOMAIN)
+         PRE_XEN_SYSCTL_READ(cpupool_op, domid);
+
+      if (sysctl->u.cpupool_op.op == XEN_SYSCTL_CPUPOOL_OP_ADDCPU ||
+          sysctl->u.cpupool_op.op == XEN_SYSCTL_CPUPOOL_OP_RMCPU)
+         PRE_XEN_SYSCTL_READ(cpupool_op, cpu);
+
+      break;
+
+   case XEN_SYSCTL_physinfo:
+      /* No input params */
+      break;
+
+   case XEN_SYSCTL_topologyinfo:
+      PRE_XEN_SYSCTL_READ(topologyinfo, max_cpu_index);
+      PRE_XEN_SYSCTL_READ(topologyinfo, cpu_to_core);
+      PRE_XEN_SYSCTL_READ(topologyinfo, cpu_to_socket);
+      PRE_XEN_SYSCTL_READ(topologyinfo, cpu_to_node);
+      break;
+
+   case XEN_SYSCTL_numainfo:
+      PRE_XEN_SYSCTL_READ(numainfo, max_node_index);
+      PRE_XEN_SYSCTL_READ(numainfo, node_to_memsize);
+      PRE_XEN_SYSCTL_READ(numainfo, node_to_memfree);
+      PRE_XEN_SYSCTL_READ(numainfo, node_to_node_distance);
+      break;
+
+   default:
+      bad_subop(tid, layout, arrghs, status, flags,
+                "__HYPERVISOR_sysctl", sysctl->cmd);
+      break;
+   }
+#undef PRE_XEN_SYSCTL_READ
+#undef __PRE_XEN_SYSCTL_READ
+}
+
+PRE(domctl)
+{
+   struct xen_domctl *domctl = (struct xen_domctl *)(unsigned int)ARG1;
+
+   PRINT("__HYPERVISOR_domctl ( %d ) on dom%d", domctl->cmd, domctl->domain);
+
+   /*
+    * Common part of xen_domctl:
+    *    uint32_t cmd;
+    *    uint32_t interface_version;
+    *    domid_t  domain;
+    */
+   PRE_MEM_READ("__HYPERVISOR_domctl", ARG1,
+                sizeof(uint32_t) + sizeof(uint32_t) + sizeof(domid_t));
+
+   if (!domctl || domctl->interface_version != XEN_DOMCTL_INTERFACE_VERSION)
+      /* BUG ? */
+      return;
+
+#define __PRE_XEN_DOMCTL_READ(_domctl, _union, _field)  \
+      PRE_MEM_READ("XEN_DOMCTL_" # _domctl,             \
+                   (Addr)&domctl->u._union._field,      \
+                   sizeof(domctl->u._union._field))
+#define PRE_XEN_DOMCTL_READ(_domctl, _field) \
+      __PRE_XEN_DOMCTL_READ(_domctl, _domctl, _field)
+
+   switch (domctl->cmd) {
+   case XEN_DOMCTL_destroydomain:
+   case XEN_DOMCTL_pausedomain:
+   case XEN_DOMCTL_max_vcpus:
+   case XEN_DOMCTL_get_address_size:
+   case XEN_DOMCTL_gettscinfo:
+   case XEN_DOMCTL_getdomaininfo:
+   case XEN_DOMCTL_unpausedomain:
+      /* No input fields. */
+      break;
+
+   case XEN_DOMCTL_createdomain:
+      PRE_XEN_DOMCTL_READ(createdomain, ssidref);
+      PRE_XEN_DOMCTL_READ(createdomain, handle);
+      PRE_XEN_DOMCTL_READ(createdomain, flags);
+      break;
+
+   case XEN_DOMCTL_max_mem:
+      PRE_XEN_DOMCTL_READ(max_mem, max_memkb);
+      break;
+
+   case XEN_DOMCTL_set_address_size:
+      __PRE_XEN_DOMCTL_READ(set_address_size, address_size, size);
+      break;
+
+   case XEN_DOMCTL_settscinfo:
+      __PRE_XEN_DOMCTL_READ(settscinfo, tsc_info, info.tsc_mode);
+      __PRE_XEN_DOMCTL_READ(settscinfo, tsc_info, info.gtsc_khz);
+      __PRE_XEN_DOMCTL_READ(settscinfo, tsc_info, info.incarnation);
+      __PRE_XEN_DOMCTL_READ(settscinfo, tsc_info, info.elapsed_nsec);
+      break;
+
+   case XEN_DOMCTL_hypercall_init:
+      PRE_XEN_DOMCTL_READ(hypercall_init, gmfn);
+      break;
+
+   case XEN_DOMCTL_getvcpuinfo:
+      PRE_XEN_DOMCTL_READ(getvcpuinfo, vcpu);
+      break;
+
+   case XEN_DOMCTL_scheduler_op:
+      PRE_XEN_DOMCTL_READ(scheduler_op, sched_id);
+      PRE_XEN_DOMCTL_READ(scheduler_op, cmd);
+      if ( domctl->u.scheduler_op.cmd == XEN_DOMCTL_SCHEDOP_putinfo ) {
+         switch(domctl->u.scheduler_op.sched_id) {
+         case XEN_SCHEDULER_SEDF:
+            PRE_XEN_DOMCTL_READ(scheduler_op, u.sedf.period);
+            PRE_XEN_DOMCTL_READ(scheduler_op, u.sedf.slice);
+            PRE_XEN_DOMCTL_READ(scheduler_op, u.sedf.latency);
+            PRE_XEN_DOMCTL_READ(scheduler_op, u.sedf.extratime);
+            PRE_XEN_DOMCTL_READ(scheduler_op, u.sedf.weight);
+            break;
+         case XEN_SCHEDULER_CREDIT:
+            PRE_XEN_DOMCTL_READ(scheduler_op, u.credit.weight);
+            PRE_XEN_DOMCTL_READ(scheduler_op, u.credit.cap);
+            break;
+         case XEN_SCHEDULER_CREDIT2:
+            PRE_XEN_DOMCTL_READ(scheduler_op, u.credit2.weight);
+            break;
+         case XEN_SCHEDULER_ARINC653:
+            break;
+         }
+      }
+      break;
+
+   case XEN_DOMCTL_getvcpuaffinity:
+      __PRE_XEN_DOMCTL_READ(getvcpuaffinity, vcpuaffinity, vcpu);
+      break;
+
+   case XEN_DOMCTL_setvcpuaffinity:
+      __PRE_XEN_DOMCTL_READ(setvcpuaffinity, vcpuaffinity, vcpu);
+      PRE_MEM_READ("XEN_DOMCTL_setvcpuaffinity",
+                   (Addr)domctl->u.vcpuaffinity.cpumap.bitmap.p,
+                   domctl->u.vcpuaffinity.cpumap.nr_cpus / 8);
+      break;
+
+   case XEN_DOMCTL_getvcpucontext:
+      __PRE_XEN_DOMCTL_READ(getvcpucontext, vcpucontext, vcpu);
+      break;
+
+   case XEN_DOMCTL_setvcpucontext:
+      __PRE_XEN_DOMCTL_READ(setvcpucontext, vcpucontext, vcpu);
+      __PRE_XEN_DOMCTL_READ(setvcpucontext, vcpucontext, ctxt.p);
+      break;
+
+   case XEN_DOMCTL_set_cpuid:
+      PRE_MEM_READ("XEN_DOMCTL_set_cpuid",
+                   (Addr)&domctl->u.cpuid, sizeof(domctl->u.cpuid));
+      break;
+
+   case XEN_DOMCTL_getvcpuextstate:
+      __PRE_XEN_DOMCTL_READ(getvcpuextstate, vcpuextstate, vcpu);
+      __PRE_XEN_DOMCTL_READ(getvcpuextstate, vcpuextstate, xfeature_mask);
+      __PRE_XEN_DOMCTL_READ(getvcpuextstate, vcpuextstate, size);
+      __PRE_XEN_DOMCTL_READ(getvcpuextstate, vcpuextstate, buffer);
+      break;
+
+   default:
+      bad_subop(tid, layout, arrghs, status, flags,
+                "__HYPERVISOR_domctl", domctl->cmd);
+      break;
+   }
+#undef PRE_XEN_DOMCTL_READ
+#undef __PRE_XEN_DOMCTL_READ
+}
+
+PRE(hvm_op)
+{
+   unsigned long op = ARG1;
+   void *arg = (void *)(unsigned long)ARG2;
+
+   PRINT("__HYPERVISOR_hvm_op ( %ld, %p )", op, arg);
+
+#define __PRE_XEN_HVMOP_READ(_hvm_op, _type, _field)    \
+   PRE_MEM_READ("XEN_HVMOP_" # _hvm_op,                 \
+                (Addr)&((_type*)arg)->_field,           \
+                sizeof(((_type*)arg)->_field))
+#define PRE_XEN_HVMOP_READ(_hvm_op, _field)                             \
+   __PRE_XEN_HVMOP_READ(_hvm_op, "xen_hvm_" # _hvm_op "_t", _field)
+
+   switch (op) {
+   case HVMOP_set_param:
+      __PRE_XEN_HVMOP_READ(set_param, xen_hvm_param_t, domid);
+      __PRE_XEN_HVMOP_READ(set_param, xen_hvm_param_t, index);
+      __PRE_XEN_HVMOP_READ(set_param, xen_hvm_param_t, value);
+      break;
+
+   case HVMOP_get_param:
+      __PRE_XEN_HVMOP_READ(get_param, xen_hvm_param_t, domid);
+      __PRE_XEN_HVMOP_READ(get_param, xen_hvm_param_t, index);
+      break;
+
+   default:
+      bad_subop(tid, layout, arrghs, status, flags,
+                "__HYPERVISOR_hvm_op", op);
+      break;
+   }
+#undef __PRE_XEN_HVMOP_READ
+#undef PRE_XEN_HVMOP_READ
+}
+
+POST(memory_op)
+{
+   switch (ARG1) {
+   case XENMEM_set_memory_map:
+   case XENMEM_decrease_reservation:
+      /* No outputs */
+      break;
+   case XENMEM_increase_reservation:
+   case XENMEM_populate_physmap: {
+      struct xen_memory_reservation *memory_reservation =
+         (struct xen_memory_reservation *)(unsigned int)ARG2;
+
+      POST_MEM_WRITE((Addr)memory_reservation->extent_start.p,
+                     sizeof(xen_pfn_t) * memory_reservation->nr_extents);
+      break;
+   }
+   }
+}
+
+POST(mmuext_op)
+{
+   unsigned int *pdone = (void *)(unsigned int)ARG3;
+   /* simplistic */
+   POST_MEM_WRITE((Addr)pdone, sizeof(*pdone));
+}
+
+static void post_evtchn_op(ThreadId tid, __vki_u32 cmd, void *arg, int compat)
+{
+   switch (cmd) {
+   case EVTCHNOP_alloc_unbound: {
+      struct evtchn_alloc_unbound *alloc_unbound = arg;
+      POST_MEM_WRITE((Addr)&alloc_unbound->port, sizeof(alloc_unbound->port));
+      break;
+   }
+   }
+}
+
+POST(evtchn_op)
+{
+   post_evtchn_op(tid, ARG1, (void *)(unsigned int)ARG2, 0);
+}
+
+POST(evtchn_op_compat)
+{
+   struct evtchn_op *evtchn = (struct evtchn_op *)(unsigned int)ARG1;
+   post_evtchn_op(tid, evtchn->cmd, &evtchn->u, 1);
+}
+
+POST(xen_version)
+{
+   switch (ARG1) {
+   case XENVER_version:
+      /* No outputs */
+      break;
+   case XENVER_extraversion:
+      POST_MEM_WRITE((Addr)ARG2, sizeof(xen_extraversion_t));
+      break;
+   case XENVER_compile_info:
+      POST_MEM_WRITE((Addr)ARG2, sizeof(xen_compile_info_t));
+      break;
+   case XENVER_capabilities:
+      POST_MEM_WRITE((Addr)ARG2, sizeof(xen_capabilities_info_t));
+      break;
+   case XENVER_changeset:
+      POST_MEM_WRITE((Addr)ARG2, sizeof(xen_changeset_info_t));
+      break;
+   case XENVER_platform_parameters:
+      POST_MEM_WRITE((Addr)ARG2, sizeof(xen_platform_parameters_t));
+      break;
+   case XENVER_get_features:
+      POST_MEM_WRITE((Addr)ARG2, sizeof(xen_feature_info_t));
+      break;
+   case XENVER_pagesize:
+      /* No outputs */
+      break;
+   case XENVER_guest_handle:
+      POST_MEM_WRITE((Addr)ARG2, sizeof(xen_domain_handle_t));
+      break;
+   case XENVER_commandline:
+      POST_MEM_WRITE((Addr)ARG2, sizeof(xen_commandline_t));
+      break;
+   }
+}
+
+POST(grant_table_op)
+{
+   switch (ARG1) {
+   case GNTTABOP_setup_table: {
+      struct gnttab_setup_table *gst = (void *)(uintptr_t)ARG2;
+      PRE_MEM_WRITE("GNTTABOP_setup_table",
+                    (Addr)&gst->status, sizeof(gst->status));
+      PRE_MEM_WRITE("GNTTABOP_setup_table",
+                    (Addr)gst->frame_list.p,
+                    sizeof(*gst->frame_list.p) & gst->nr_frames);
+      break;
+   }
+   }
+}
+
+POST(sysctl)
+{
+   struct xen_sysctl *sysctl = (struct xen_sysctl *)(unsigned int)ARG1;
+
+   if (!sysctl || sysctl->interface_version != XEN_SYSCTL_INTERFACE_VERSION)
+      return;
+
+#define __POST_XEN_SYSCTL_WRITE(_sysctl, _union, _field)        \
+      POST_MEM_WRITE((Addr)&sysctl->u._union._field,            \
+                     sizeof(sysctl->u._union._field))
+#define POST_XEN_SYSCTL_WRITE(_sysctl, _field) \
+      __POST_XEN_SYSCTL_WRITE(_sysctl, _sysctl, _field)
+
+   switch (sysctl->cmd) {
+   case XEN_SYSCTL_getdomaininfolist:
+      POST_XEN_SYSCTL_WRITE(getdomaininfolist, num_domains);
+      POST_MEM_WRITE((Addr)sysctl->u.getdomaininfolist.buffer.p,
+                     sizeof(xen_domctl_getdomaininfo_t)
+                     * sysctl->u.getdomaininfolist.num_domains);
+      break;
+
+   case XEN_SYSCTL_cpupool_op:
+      if (sysctl->u.cpupool_op.op == XEN_SYSCTL_CPUPOOL_OP_CREATE ||
+          sysctl->u.cpupool_op.op == XEN_SYSCTL_CPUPOOL_OP_INFO)
+         POST_XEN_SYSCTL_WRITE(cpupool_op, cpupool_id);
+      if (sysctl->u.cpupool_op.op == XEN_SYSCTL_CPUPOOL_OP_INFO) {
+         POST_XEN_SYSCTL_WRITE(cpupool_op, sched_id);
+         POST_XEN_SYSCTL_WRITE(cpupool_op, n_dom);
+      }
+      if (sysctl->u.cpupool_op.op == XEN_SYSCTL_CPUPOOL_OP_INFO ||
+          sysctl->u.cpupool_op.op == XEN_SYSCTL_CPUPOOL_OP_FREEINFO)
+         POST_XEN_SYSCTL_WRITE(cpupool_op, cpumap);
+      break;
+
+   case XEN_SYSCTL_physinfo:
+      POST_XEN_SYSCTL_WRITE(physinfo, threads_per_core);
+      POST_XEN_SYSCTL_WRITE(physinfo, cores_per_socket);
+      POST_XEN_SYSCTL_WRITE(physinfo, nr_cpus);
+      POST_XEN_SYSCTL_WRITE(physinfo, max_cpu_id);
+      POST_XEN_SYSCTL_WRITE(physinfo, nr_nodes);
+      POST_XEN_SYSCTL_WRITE(physinfo, max_node_id);
+      POST_XEN_SYSCTL_WRITE(physinfo, cpu_khz);
+      POST_XEN_SYSCTL_WRITE(physinfo, total_pages);
+      POST_XEN_SYSCTL_WRITE(physinfo, free_pages);
+      POST_XEN_SYSCTL_WRITE(physinfo, scrub_pages);
+      POST_XEN_SYSCTL_WRITE(physinfo, hw_cap[8]);
+      POST_XEN_SYSCTL_WRITE(physinfo, capabilities);
+      break;
+
+   case XEN_SYSCTL_topologyinfo:
+      POST_XEN_SYSCTL_WRITE(topologyinfo, max_cpu_index);
+      POST_MEM_WRITE((Addr)sysctl->u.topologyinfo.cpu_to_core.p,
+                     sizeof(uint32_t) * sysctl->u.topologyinfo.max_cpu_index);
+      POST_MEM_WRITE((Addr)sysctl->u.topologyinfo.cpu_to_socket.p,
+                     sizeof(uint32_t) * sysctl->u.topologyinfo.max_cpu_index);
+      POST_MEM_WRITE((Addr)sysctl->u.topologyinfo.cpu_to_node.p,
+                     sizeof(uint32_t) * sysctl->u.topologyinfo.max_cpu_index);
+      break;
+
+   case XEN_SYSCTL_numainfo:
+      POST_XEN_SYSCTL_WRITE(numainfo, max_node_index);
+      POST_MEM_WRITE((Addr)sysctl->u.numainfo.node_to_memsize.p,
+                     sizeof(uint64_t) * sysctl->u.numainfo.max_node_index);
+      POST_MEM_WRITE((Addr)sysctl->u.numainfo.node_to_memfree.p,
+                     sizeof(uint64_t) * sysctl->u.numainfo.max_node_index);
+      POST_MEM_WRITE((Addr)sysctl->u.numainfo.node_to_node_distance.p,
+                     sizeof(uint32_t) * sysctl->u.numainfo.max_node_index);
+   }
+#undef POST_XEN_SYSCTL_WRITE
+#undef __POST_XEN_SYSCTL_WRITE
+}
+
+POST(domctl){
+   struct xen_domctl *domctl = (struct xen_domctl *)(unsigned int)ARG1;
+
+   if (!domctl || domctl->interface_version != XEN_DOMCTL_INTERFACE_VERSION)
+      return;
+
+#define __POST_XEN_DOMCTL_WRITE(_domctl, _union, _field)        \
+   POST_MEM_WRITE((Addr)&domctl->u._union._field,               \
+                  sizeof(domctl->u._union._field));
+#define POST_XEN_DOMCTL_WRITE(_domctl, _field)          \
+   __POST_XEN_DOMCTL_WRITE(_domctl, _domctl, _field)
+
+   switch (domctl->cmd) {
+   case XEN_DOMCTL_createdomain:
+   case XEN_DOMCTL_destroydomain:
+   case XEN_DOMCTL_pausedomain:
+   case XEN_DOMCTL_max_mem:
+   case XEN_DOMCTL_set_address_size:
+   case XEN_DOMCTL_settscinfo:
+   case XEN_DOMCTL_hypercall_init:
+   case XEN_DOMCTL_setvcpuaffinity:
+   case XEN_DOMCTL_setvcpucontext:
+   case XEN_DOMCTL_set_cpuid:
+   case XEN_DOMCTL_unpausedomain:
+      /* No output fields */
+      break;
+
+   case XEN_DOMCTL_max_vcpus:
+      POST_XEN_DOMCTL_WRITE(max_vcpus, max);
+
+   case XEN_DOMCTL_get_address_size:
+      __POST_XEN_DOMCTL_WRITE(get_address_size, address_size, size);
+      break;
+
+   case XEN_DOMCTL_gettscinfo:
+      __POST_XEN_DOMCTL_WRITE(settscinfo, tsc_info, info.tsc_mode);
+      __POST_XEN_DOMCTL_WRITE(settscinfo, tsc_info, info.gtsc_khz);
+      __POST_XEN_DOMCTL_WRITE(settscinfo, tsc_info, info.incarnation);
+      __POST_XEN_DOMCTL_WRITE(settscinfo, tsc_info, info.elapsed_nsec);
+      break;
+
+   case XEN_DOMCTL_getvcpuinfo:
+      POST_XEN_DOMCTL_WRITE(getvcpuinfo, online);
+      POST_XEN_DOMCTL_WRITE(getvcpuinfo, blocked);
+      POST_XEN_DOMCTL_WRITE(getvcpuinfo, running);
+      POST_XEN_DOMCTL_WRITE(getvcpuinfo, cpu_time);
+      POST_XEN_DOMCTL_WRITE(getvcpuinfo, cpu);
+      break;
+
+   case XEN_DOMCTL_scheduler_op:
+      if ( domctl->u.scheduler_op.cmd == XEN_DOMCTL_SCHEDOP_getinfo ) {
+         switch(domctl->u.scheduler_op.sched_id) {
+         case XEN_SCHEDULER_SEDF:
+            POST_XEN_DOMCTL_WRITE(scheduler_op, u.sedf.period);
+            POST_XEN_DOMCTL_WRITE(scheduler_op, u.sedf.slice);
+            POST_XEN_DOMCTL_WRITE(scheduler_op, u.sedf.latency);
+            POST_XEN_DOMCTL_WRITE(scheduler_op, u.sedf.extratime);
+            POST_XEN_DOMCTL_WRITE(scheduler_op, u.sedf.weight);
+            break;
+         case XEN_SCHEDULER_CREDIT:
+            POST_XEN_DOMCTL_WRITE(scheduler_op, u.credit.weight);
+            POST_XEN_DOMCTL_WRITE(scheduler_op, u.credit.cap);
+            break;
+         case XEN_SCHEDULER_CREDIT2:
+            POST_XEN_DOMCTL_WRITE(scheduler_op, u.credit2.weight);
+            break;
+         case XEN_SCHEDULER_ARINC653:
+            break;
+         }
+      }
+      break;
+
+   case XEN_DOMCTL_getvcpuaffinity:
+      POST_MEM_WRITE((Addr)domctl->u.vcpuaffinity.cpumap.bitmap.p,
+                     domctl->u.vcpuaffinity.cpumap.nr_cpus / 8);
+      break;
+
+   case XEN_DOMCTL_getdomaininfo:
+      POST_XEN_DOMCTL_WRITE(getdomaininfo, domain);
+      POST_XEN_DOMCTL_WRITE(getdomaininfo, flags);
+      POST_XEN_DOMCTL_WRITE(getdomaininfo, tot_pages);
+      POST_XEN_DOMCTL_WRITE(getdomaininfo, max_pages);
+      POST_XEN_DOMCTL_WRITE(getdomaininfo, shr_pages);
+      POST_XEN_DOMCTL_WRITE(getdomaininfo, shared_info_frame);
+      POST_XEN_DOMCTL_WRITE(getdomaininfo, cpu_time);
+      POST_XEN_DOMCTL_WRITE(getdomaininfo, nr_online_vcpus);
+      POST_XEN_DOMCTL_WRITE(getdomaininfo, max_vcpu_id);
+      POST_XEN_DOMCTL_WRITE(getdomaininfo, ssidref);
+      POST_XEN_DOMCTL_WRITE(getdomaininfo, handle);
+      POST_XEN_DOMCTL_WRITE(getdomaininfo, cpupool);
+      break;
+
+   case XEN_DOMCTL_getvcpucontext:
+      __POST_XEN_DOMCTL_WRITE(getvcpucontext, vcpucontext, ctxt.p);
+      break;
+
+   case XEN_DOMCTL_getvcpuextstate:
+      __POST_XEN_DOMCTL_WRITE(getvcpuextstate, vcpuextstate, xfeature_mask);
+      __POST_XEN_DOMCTL_WRITE(getvcpuextstate, vcpuextstate, size);
+      POST_MEM_WRITE((Addr)domctl->u.vcpuextstate.buffer.p,
+                     domctl->u.vcpuextstate.size);
+      break;
+
+   }
+#undef POST_XEN_DOMCTL_WRITE
+#undef __POST_XEN_DOMCTL_WRITE
+}
+
+POST(hvm_op)
+{
+   unsigned long op = ARG1;
+   void *arg = (void *)(unsigned long)ARG2;
+
+#define __POST_XEN_HVMOP_WRITE(_hvm_op, _type, _field)  \
+      POST_MEM_WRITE((Addr)&((_type*)arg)->_field,      \
+                     sizeof(((_type*)arg)->_field))
+#define POST_XEN_HVMOP_WRITE(_hvm_op, _field) \
+      __PRE_XEN_HVMOP_READ(_hvm_op, "xen_hvm_" # _hvm_op "_t", _field)
+
+   switch (op) {
+   case HVMOP_set_param:
+      /* No output paramters */
+      break;
+
+   case HVMOP_get_param:
+      __POST_XEN_HVMOP_WRITE(get_param, xen_hvm_param_t, value);
+      break;
+   }
+#undef __POST_XEN_HVMOP_WRITE
+#undef POST_XEN_HVMOP_WRITE
+}
+
+typedef
+   struct {
+      SyscallTableEntry entry;
+      int nr_args;
+   }
+   XenHypercallTableEntry;
+
+#define HYPX_(const, name, nr_args) \
+   [const] = { { vgSysWrap_xen_##name##_before, NULL }, nr_args }
+#define HYPXY(const, name, nr_args)                     \
+   [const] = { { vgSysWrap_xen_##name##_before,         \
+                 vgSysWrap_xen_##name##_after },        \
+               nr_args }
+
+static XenHypercallTableEntry hypercall_table[] = {
+   //    __HYPERVISOR_set_trap_table                                  // 0
+   //    __HYPERVISOR_mmu_update                                      // 1
+   //    __HYPERVISOR_set_gdt                                         // 2
+   //    __HYPERVISOR_stack_switch                                    // 3
+   //    __HYPERVISOR_set_callbacks                                   // 4
+
+   //    __HYPERVISOR_fpu_taskswitch                                  // 5
+   //    __HYPERVISOR_sched_op_compat                                 // 6
+   //    __HYPERVISOR_platform_op                                     // 7
+   //    __HYPERVISOR_set_debugreg                                    // 8
+   //    __HYPERVISOR_get_debugreg                                    // 9
+
+   //    __HYPERVISOR_update_descriptor                               // 10
+   //                                                                 // 11
+   HYPXY(__HYPERVISOR_memory_op,               memory_op,         2), // 12
+   //    __HYPERVISOR_multicall                                       // 13
+   //    __HYPERVISOR_update_va_mapping                               // 14
+
+   //    __HYPERVISOR_set_timer_op                                    // 15
+   HYPXY(__HYPERVISOR_event_channel_op_compat, evtchn_op_compat,  1), // 16
+   HYPXY(__HYPERVISOR_xen_version,             xen_version,       2), // 17
+   //    __HYPERVISOR_console_io                                      // 18
+   //    __HYPERVISOR_physdev_op_compat                               // 19
+
+   HYPXY(__HYPERVISOR_grant_table_op,          grant_table_op,    3), // 20
+   //    __HYPERVISOR_vm_assist                                       // 21
+   //    __HYPERVISOR_update_va_mapping_otherdomain                   // 22
+   //    __HYPERVISOR_iret,                    iret                   // 23
+   //    __HYPERVISOR_vcpu_op,                 vcpu_op                // 24
+
+   //    __HYPERVISOR_set_segment_base                                // 25
+   HYPXY(__HYPERVISOR_mmuext_op,               mmuext_op,         2), // 26
+   //    __HYPERVISOR_xsm_op                                          // 27
+   //    __HYPERVISOR_nmi_op                                          // 28
+   //    __HYPERVISOR_sched_op                                        // 29
+
+   //    __HYPERVISOR_callback_op                                     // 30
+   //    __HYPERVISOR_xenoprof_op                                     // 31
+   HYPXY(__HYPERVISOR_event_channel_op,        evtchn_op,         2), // 32
+   //    __HYPERVISOR_physdev_op                                      // 33
+   HYPXY(__HYPERVISOR_hvm_op,                  hvm_op,            2), // 34
+
+   HYPXY(__HYPERVISOR_sysctl,                  sysctl,            1), // 35
+   HYPXY(__HYPERVISOR_domctl,                  domctl,            1), // 36
+   //    __HYPERVISOR_kexec_op                                        // 37
+   //    __HYPERVISOR_tmem_op                                         // 38
+};
+
+static void bad_before ( ThreadId              tid,
+                         SyscallArgLayout*     layout,
+                         /*MOD*/SyscallArgs*   args,
+                         /*OUT*/SyscallStatus* status,
+                         /*OUT*/UWord*         flags )
+{
+   VG_(dmsg)("WARNING: unhandled hypercall: %s\n",
+      VG_SYSNUM_STRING_EXTRA(args->sysno));
+   if (VG_(clo_verbosity) > 1) {
+      VG_(get_and_pp_StackTrace)(tid, VG_(clo_backtrace_size));
+   }
+   VG_(dmsg)("You may be able to write your own handler.\n");
+   VG_(dmsg)("Read the file README_MISSING_SYSCALL_OR_IOCTL.\n");
+   VG_(dmsg)("Nevertheless we consider this a bug.  Please report\n");
+   VG_(dmsg)("it at http://valgrind.org/support/bug_reports.html &\n");
+   VG_(dmsg)("http://wiki.xen.org/wiki/Reporting_Bugs_against_Xen.\n");
+
+   SET_STATUS_Failure(VKI_ENOSYS);
+}
+
+static XenHypercallTableEntry bad_hyper =
+{ { bad_before, NULL }, 0 };
+
+static XenHypercallTableEntry* ML_(get_xen_hypercall_entry) ( UInt sysno )
+{
+   XenHypercallTableEntry *ret = &bad_hyper;
+
+   const UInt hypercall_table_size
+      = sizeof(hypercall_table) / sizeof(hypercall_table[0]);
+
+   /* Is it in the contiguous initial section of the table? */
+   if (sysno < hypercall_table_size) {
+      XenHypercallTableEntry* ent = &hypercall_table[sysno];
+      if (ent->entry.before != NULL)
+         ret = ent;
+   }
+
+   /* Can't find a wrapper */
+   return ret;
+}
+
+DEFN_PRE_TEMPLATE(xen, hypercall)
+{
+   XenHypercallTableEntry *ent = ML_(get_xen_hypercall_entry)(SYSNO);
+
+   /* Return number of arguments consumed */
+   ARG8 = ent->nr_args;
+
+   vg_assert(ent);
+   vg_assert(ent->entry.before);
+   (ent->entry.before)( tid, layout, arrghs, status, flags );
+
+}
+
+DEFN_POST_TEMPLATE(xen, hypercall)
+{
+   XenHypercallTableEntry *ent = ML_(get_xen_hypercall_entry)(SYSNO);
+
+   /* Return number of arguments consumed */
+   ARG8 = ent->nr_args;
+
+   vg_assert(ent);
+   if (ent->entry.after)
+      (ent->entry.after)( tid, arrghs, status );
+}
diff --git a/include/Makefile.am b/include/Makefile.am
index ade27c2..f1a3443 100644
--- a/include/Makefile.am
+++ b/include/Makefile.am
@@ -64,4 +64,5 @@ nobase_pkginclude_HEADERS = \
        vki/vki-scnums-arm-linux.h      \
        vki/vki-scnums-s390x-linux.h    \
        vki/vki-scnums-mips32-linux.h   \
-       vki/vki-scnums-darwin.h
+       vki/vki-scnums-darwin.h         \
+       vki/vki-xen.h
diff --git a/include/pub_tool_vki.h b/include/pub_tool_vki.h
index a0996f9..6598106 100644
--- a/include/pub_tool_vki.h
+++ b/include/pub_tool_vki.h
@@ -47,6 +47,7 @@

 #if defined(VGO_linux)
 #  include "vki/vki-linux.h"
+#  include "vki/vki-xen.h"
 #elif defined(VGO_darwin)
 #  include "vki/vki-darwin.h"
 #else
diff --git a/include/vki/vki-linux.h b/include/vki/vki-linux.h
index c18195e..4fdc353 100644
--- a/include/vki/vki-linux.h
+++ b/include/vki/vki-linux.h
@@ -3009,6 +3009,50 @@ struct vki_hwtstamp_config {
 #define VKI_UI_SET_SWBIT               _VKI_IOW(VKI_UINPUT_IOCTL_BASE, 109, int)
 #define VKI_UI_SET_PROPBIT             _VKI_IOW(VKI_UINPUT_IOCTL_BASE, 110, int)

+//----------------------------------------------------------------------
+// Xen privcmd IOCTL
+//----------------------------------------------------------------------
+
+typedef unsigned long __vki_xen_pfn_t;
+
+struct vki_xen_privcmd_hypercall {
+       __vki_u64 op;
+       __vki_u64 arg[5];
+};
+
+struct vki_xen_privcmd_mmap_entry {
+        __vki_u64 va;
+        __vki_u64 mfn;
+        __vki_u64 npages;
+};
+
+struct vki_xen_privcmd_mmap {
+        int num;
+        __vki_u16 dom; /* target domain */
+        struct vki_xen_privcmd_mmap_entry *entry;
+};
+
+struct vki_xen_privcmd_mmapbatch {
+        int num;     /* number of pages to populate */
+        __vki_u16 dom; /* target domain */
+        __vki_u64 addr;  /* virtual address */
+        __vki_xen_pfn_t *arr; /* array of mfns - top nibble set on err */
+};
+
+struct vki_xen_privcmd_mmapbatch_v2 {
+        unsigned int num; /* number of pages to populate */
+        __vki_u16 dom;      /* target domain */
+        __vki_u64 addr;       /* virtual address */
+        const __vki_xen_pfn_t *arr; /* array of mfns */
+        int __user *err;  /* array of error codes */
+};
+
+#define VKI_XEN_IOCTL_PRIVCMD_HYPERCALL    _VKI_IOC(_VKI_IOC_NONE, 'P', 0, sizeof(struct vki_xen_privcmd_hypercall))
+#define VKI_XEN_IOCTL_PRIVCMD_MMAP         _VKI_IOC(_VKI_IOC_NONE, 'P', 2, sizeof(struct vki_xen_privcmd_mmap))
+
+#define VKI_XEN_IOCTL_PRIVCMD_MMAPBATCH    _VKI_IOC(_VKI_IOC_NONE, 'P', 3, sizeof(struct vki_xen_privcmd_mmapbatch))
+#define VKI_XEN_IOCTL_PRIVCMD_MMAPBATCH_V2 _VKI_IOC(_VKI_IOC_NONE, 'P', 4, sizeof(struct vki_xen_privcmd_mmapbatch_v2))
+
 #endif // __VKI_LINUX_H

 /*--------------------------------------------------------------------*/
diff --git a/include/vki/vki-xen.h b/include/vki/vki-xen.h
new file mode 100644
index 0000000..7842cc9
--- /dev/null
+++ b/include/vki/vki-xen.h
@@ -0,0 +1,8 @@
+#ifndef __VKI_XEN_H
+#define __VKI_XEN_H
+
+#endif // __VKI_XEN_H
+
+/*--------------------------------------------------------------------*/
+/*--- 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 Tue Sep 04 16:38:53 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Sep 2012 16: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 1T8w8y-0005Ct-F8; Tue, 04 Sep 2012 16:38:28 +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 1T8w8w-0005Co-RY
	for xen-devel@lists.xen.org; Tue, 04 Sep 2012 16:38:27 +0000
Received: from [85.158.143.35:50678] by server-2.bemta-4.messagelabs.com id
	DC/B5-21239-28E26405; Tue, 04 Sep 2012 16:38:26 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-6.tower-21.messagelabs.com!1346776701!16623538!1
X-Originating-IP: [188.40.164.121]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1985 invoked from network); 4 Sep 2012 16:38:22 -0000
Received: from static.121.164.40.188.clients.your-server.de (HELO
	smtp.eikelenboom.it) (188.40.164.121)
	by server-6.tower-21.messagelabs.com with AES256-SHA encrypted SMTP;
	4 Sep 2012 16:38:22 -0000
Received: from 128-64-ftth.onsneteindhoven.nl ([88.159.64.128]:55630
	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 1T8w5T-0004hp-8E; Tue, 04 Sep 2012 18:34:51 +0200
Date: Tue, 4 Sep 2012 18:37:57 +0200
From: Sander Eikelenboom <linux@eikelenboom.it>
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <1136369816.20120904183757@eikelenboom.it>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
MIME-Version: 1.0
Content-Type: multipart/mixed;
 boundary="----------0320050151C2718BB"
Cc: xen-devel@lists.xen.org
Subject: [Xen-devel] dom0 linux 3.6.0-rc4,
	crash due to ballooning althoug dom0_mem=X, max:X 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>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

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

Hi Konrad,

This seems to happen only on a intel machine i'm trying to setup as a devel=
opment machine (haven't seen it on my amd).
It boots fine, i have dom0_mem=3D1024M,max:1024M set, the machine has 2G of=
 mem.

Dom0 and guest kernel are 3.6.0-rc4 with config:
[*] Xen memory balloon driver
[*]   Scrub pages before returning them to system

From=20http://wiki.xen.org/wiki/Do%EF%BB%BFm0_Memory_%E2%80%94_Where_It_Has=
_Not_Gone , I thought this should be okay

But when trying to start a PV guest with 512MB mem, the machine (dom0) cras=
hes with the stacktrace below (complete serial-log.txt attached).

From=20the:
"mapping kernel into physical memory
about to get started..."

I would almost say it's trying to reload dom0 ?


[  897.161119] device vif1.0 entered promiscuous mode
mapping kernel into physical memory
about to get started...
[  897.696619] xen_bridge: port 1(vif1.0) entered forwarding state
[  897.716219] xen_bridge: port 1(vif1.0) entered forwarding state
[  898.129465] ------------[ cut here ]------------
[  898.132209] kernel BUG at drivers/xen/balloon.c:359!
[  898.132209] invalid opcode: 0000 [#1] PREEMPT SMP=20
[  898.132209] Modules linked in:
[  898.132209] CPU 0=20
[  898.132209] Pid: 3338, comm: kworker/0:1 Not tainted 3.6.0-rc4-20120830+=
 #66 System manufacturer System Product Name/P5Q-EM DO
[  898.132209] RIP: e030:[<ffffffff8133b206>]  [<ffffffff8133b206>] balloon=
_process+0x336/0x340
[  898.132209] RSP: e02b:ffff880037b4dce0  EFLAGS: 00010213
[  898.132209] RAX: 00000000242b0000 RBX: ffffea0000dfadc0 RCX: 00000000000=
00000
[  898.132209] RDX: 0000000000037eb7 RSI: 00000000deadbeef RDI: 00000000000=
000b7
[  898.132209] RBP: ffff880037b4dd40 R08: ffffea0000dfade0 R09: 22222222222=
22222
[  898.132209] R10: 2222222222222222 R11: 2222222222222222 R12: 00000000000=
00000
[  898.132209] R13: ffffea0000dfade0 R14: 0000160000000000 R15: 00000000000=
00001
[  898.132209] FS:  00007fd4bd0ec740(0000) GS:ffff88003fc00000(0000) knlGS:=
0000000000000000
[  898.132209] CS:  e033 DS: 0000 ES: 0000 CR0: 000000008005003b
[  898.132209] CR2: 00007fd4b387d000 CR3: 000000003920a000 CR4: 00000000000=
42660
[  898.132209] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 00000000000=
00000
[  898.132209] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 00000000000=
00400
[  898.132209] Process kworker/0:1 (pid: 3338, threadinfo ffff880037b4c000,=
 task ffff8800398fe180)
[  898.132209] Stack:
[  898.132209]  0000000000037eb7 0000000000000001 ffffffff8286c540 00000000=
00000001
[  898.132209]  0000000000000000 0000000000007ff0 ffff880037b4dd20 ffffffff=
81e42a60
[  898.132209]  ffff88003799c6c0 ffff88003fc16700 ffff88003fc0e000 ffff8800=
37b4dd90
[  898.132209] Call Trace:
[  898.132209]  [<ffffffff8107fb8f>] process_one_work+0x1bf/0x4a0
[  898.132209]  [<ffffffff8107fb30>] ? process_one_work+0x160/0x4a0
[  898.132209]  [<ffffffff81849191>] ? __schedule+0x471/0x8a0
[  898.132209]  [<ffffffff8133aed0>] ? decrease_reservation+0x2d0/0x2d0
[  898.132209]  [<ffffffff81080252>] worker_thread+0x152/0x470
[  898.132209]  [<ffffffff8184ad85>] ? _raw_spin_unlock_irqrestore+0x75/0xa0
[  898.132209]  [<ffffffff810ae4dd>] ? trace_hardirqs_on+0xd/0x10
[  898.132209]  [<ffffffff8184ad63>] ? _raw_spin_unlock_irqrestore+0x53/0xa0
[  898.132209]  [<ffffffff81080100>] ? manage_workers+0x290/0x290
[  898.132209]  [<ffffffff81087696>] kthread+0x96/0xa0
[  898.132209]  [<ffffffff8184cb84>] kernel_thread_helper+0x4/0x10
[  898.132209]  [<ffffffff8184b134>] ? retint_restore_args+0x13/0x13
[  898.132209]  [<ffffffff8184cb80>] ? gs_change+0x13/0x13
[  898.132209] Code: ff 0f 1f 40 00 48 89 d8 e9 22 fe ff ff 0f 0b eb fe 48 =
89 d7 48 89 55 a0 e8 18 e7 cc ff 48 83 f8 ff 48 8b 55 a0 0f 84 74 fe ff ff =
<0f> 0b eb fe 66 0f 1f 44 00 00 55 48 89 e5 41 57 41 56 41 89 d6=20
[  898.132209] RIP  [<ffffffff8133b206>] balloon_process+0x336/0x340
[  898.132209]  RSP <ffff880037b4dce0>
[  898.738233] ---[ end trace 3f7af50285edb7bb ]---
[  898.749003] BUG: unable to handle kernel paging request at fffffffffffff=
ff8
[  898.752237] IP: [<ffffffff81086eeb>] kthread_data+0xb/0x20
[  898.752237] PGD 1e0d067 PUD 1e0e067 PMD 0=20
[  898.752237] Oops: 0000 [#2] PREEMPT SMP=20
[  898.752237] Modules linked in:
[  898.752237] CPU 0=20
[  898.752237] Pid: 3338, comm: kworker/0:1 Tainted: G      D      3.6.0-rc=
4-20120830+ #66 System manufacturer System Product Name/P5Q-EM DO
[  898.752237] RIP: e030:[<ffffffff81086eeb>]  [<ffffffff81086eeb>] kthread=
_data+0xb/0x20
[  898.752237] RSP: e02b:ffff880037b4d898  EFLAGS: 00010082
[  898.752237] RAX: 0000000000000000 RBX: ffff88003fc12e80 RCX: 00000000000=
00000
[  898.752237] RDX: ffffffff820057a0 RSI: 0000000000000000 RDI: ffff8800398=
fe180
[  898.752237] RBP: ffff880037b4d898 R08: ffff8800398fe1f0 R09: 00000000000=
00400
[  898.752237] R10: 0000000000000000 R11: 0000000000000001 R12: 00000000000=
00000
[  898.752237] R13: 0000000000000000 R14: ffff880037b4d7b8 R15: ffff880037b=
4da90
[  898.752237] FS:  00007fd4bd0ec740(0000) GS:ffff88003fc00000(0000) knlGS:=
0000000000000000
[  898.752237] CS:  e033 DS: 0000 ES: 0000 CR0: 000000008005003b
[  898.752237] CR2: fffffffffffffff8 CR3: 000000003920a000 CR4: 00000000000=
42660
[  898.752237] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 00000000000=
00000
[  898.752237] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 00000000000=
00400
[  898.752237] Process kworker/0:1 (pid: 3338, threadinfo ffff880037b4c000,=
 task ffff8800398fe180)
[  898.752237] Stack:
[  898.752237]  ffff880037b4d8c8 ffffffff8108306c 0000000000000000 ffff8800=
3fc12e80
[  898.752237]  0000000000000000 ffff8800398fe528 ffff880037b4da18 ffffffff=
8184931f
[  898.752237]  0000000000000000 ffffffff81083bb8 ffff8800398fe180 00000000=
00012e80
[  898.752237] Call Trace:
[  898.752237]  [<ffffffff8108306c>] wq_worker_sleeping+0x1c/0x90
[  898.752237]  [<ffffffff8184931f>] __schedule+0x5ff/0x8a0
[  898.752237]  [<ffffffff81083bb8>] ? free_pid+0x18/0xc0
[  898.752237]  [<ffffffff810602a7>] ? sha1_transform_ssse3+0x187/0xd00
[  898.752237]  [<ffffffff810b1a94>] ? lock_acquire+0xe4/0x110
[  898.752237]  [<ffffffff8106cfa7>] ? do_exit+0x4e7/0x8e0
[  898.752237]  [<ffffffff810e27f2>] ? call_rcu+0x12/0x20
[  898.752237]  [<ffffffff810b1f01>] ? lock_release+0x111/0x260
[  898.752237]  [<ffffffff81849654>] schedule+0x24/0x70
[  898.752237]  [<ffffffff8106d074>] do_exit+0x5b4/0x8e0
[  898.752237]  [<ffffffff81010240>] oops_end+0xb0/0xf0
[  898.752237]  [<ffffffff810103b6>] die+0x56/0x90
[  898.752237]  [<ffffffff8100d6c4>] do_trap+0xc4/0x170
[  898.752237]  [<ffffffff8100dbe2>] ? do_invalid_op+0x72/0xc0
[  898.752237]  [<ffffffff8100dc16>] do_invalid_op+0xa6/0xc0
[  898.752237]  [<ffffffff8133b206>] ? balloon_process+0x336/0x340
[  898.752237]  [<ffffffff810ac9e8>] ? trace_hardirqs_off_caller+0x78/0x150
[  898.752237]  [<ffffffff812b29fd>] ? trace_hardirqs_off_thunk+0x3a/0x3c
[  898.752237]  [<ffffffff8184b164>] ? restore_args+0x30/0x30
[  898.752237]  [<ffffffff8184c9fb>] invalid_op+0x1b/0x20
[  898.752237]  [<ffffffff8133b206>] ? balloon_process+0x336/0x340
[  898.752237]  [<ffffffff8107fb8f>] process_one_work+0x1bf/0x4a0
[  898.752237]  [<ffffffff8107fb30>] ? process_one_work+0x160/0x4a0
[  898.752237]  [<ffffffff81849191>] ? __schedule+0x471/0x8a0
[  898.752237]  [<ffffffff8133aed0>] ? decrease_reservation+0x2d0/0x2d0
[  898.752237]  [<ffffffff81080252>] worker_thread+0x152/0x470
[  898.752237]  [<ffffffff8184ad85>] ? _raw_spin_unlock_irqrestore+0x75/0xa0
[  898.752237]  [<ffffffff810ae4dd>] ? trace_hardirqs_on+0xd/0x10
[  898.752237]  [<ffffffff8184ad63>] ? _raw_spin_unlock_irqrestore+0x53/0xa0
[  898.752237]  [<ffffffff81080100>] ? manage_workers+0x290/0x290
[  898.752237]  [<ffffffff81087696>] kthread+0x96/0xa0
[  898.752237]  [<ffffffff8184cb84>] kernel_thread_helper+0x4/0x10
[  898.752237]  [<ffffffff8184b134>] ? retint_restore_args+0x13/0x13
[  898.752237]  [<ffffffff8184cb80>] ? gs_change+0x13/0x13
[  898.752237] Code: 55 65 48 8b 04 25 80 c6 00 00 48 8b 80 50 03 00 00 48 =
89 e5 8b 40 f0 c9 c3 0f 1f 80 00 00 00 00 48 8b 87 50 03 00 00 55 48 89 e5 =
<48> 8b 40 f8 c9 c3 66 66 66 66 66 66 2e 0f 1f 84 00 00 00 00 00=20
[  898.752237] RIP  [<ffffffff81086eeb>] kthread_data+0xb/0x20
[  898.752237]  RSP <ffff880037b4d898>
[  898.752237] CR2: fffffffffffffff8
[  898.752237] ---[ end trace 3f7af50285edb7bc ]---
[  898.752237] Fixing recursive fault but reboot is needed!
[  912.746625] xen_bridge: port 1(vif1.0) entered forwarding state
------------0320050151C2718BB
Content-Type: text/plain;
 name="serial-log.txt"
Content-transfer-encoding: base64
Content-Disposition: attachment;
 filename="serial-log.txt"

IF9fICBfXyAgICAgICAgICAgIF8gIF8gICAgX19fXyAgICBfX18gICAgICAgICAgICAgIF8g
IF8gICAgICAgICAgICAgICAgICAgICANCiBcIFwvIC9fX18gXyBfXyAgIHwgfHwgfCAgfF9f
XyBcICAvIF8gXCAgICBfIF9fIF9fX3wgfHwgfCAgICAgXyBfXyAgXyBfXyBfX18gDQogIFwg
IC8vIF8gXCAnXyBcICB8IHx8IHxfICAgX18pIHx8IHwgfCB8X198ICdfXy8gX198IHx8IHxf
IF9ffCAnXyBcfCAnX18vIF8gXA0KICAvICBcICBfXy8gfCB8IHwgfF9fICAgX3wgLyBfXy8g
fCB8X3wgfF9ffCB8IHwgKF9ffF9fICAgX3xfX3wgfF8pIHwgfCB8ICBfXy8NCiAvXy9cX1xf
X198X3wgfF98ICAgIHxffChfKV9fX19fKF8pX19fLyAgIHxffCAgXF9fX3wgIHxffCAgICB8
IC5fXy98X3wgIFxfX198DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgfF98ICAgICAgICAgICAgIA0KKFhFTikgWGVuIHZl
cnNpb24gNC4yLjAtcmM0LXByZSAocm9vdEApIChnY2MgKERlYmlhbiA0LjQuNS04KSA0LjQu
NSkgTW9uIFNlcCAgMyAxODozMjowNyBDRVNUIDIwMTINCihYRU4pIExhdGVzdCBDaGFuZ2VT
ZXQ6IFRodSBBdWcgMzAgMTg6MTc6MjAgMjAxMiArMDEwMCAyNTc5MTo5ZTU2NjVmOWY0MzAN
CihYRU4pIEJvb3Rsb2FkZXI6IEdSVUIgMS45OCsyMDEwMDgwNC0xNCtzcXVlZXplMQ0KKFhF
TikgQ29tbWFuZCBsaW5lOiBkb20wX21lbT0xMDI0TSxtYXg6MTAyNE0gbG9nbHZsPWFsbCBs
b2dsdmxfZ3Vlc3Q9YWxsIGNvbnNvbGVfdGltZXN0YW1wcyB2Z2E9Z2Z4LTgwMHg2MDB4OCBu
b3JlYm9vdCBkZWJ1ZyBsYXBpYz1kZWJ1ZyBhcGljX3ZlcmJvc2l0eT1kZWJ1ZyBhcGljPWRl
YnVnIGlvbW11PW9uLHZlcmJvc2UsZGVidWcgY29tMT0zODQwMCw4bjEgY29uc29sZT12Z2Es
Y29tMQ0KKFhFTikgVmlkZW8gaW5mb3JtYXRpb246DQooWEVOKSAgVkdBIGlzIGdyYXBoaWNz
IG1vZGUgODAweDYwMCwgOCBicHANCihYRU4pICBWQkUvRERDIG1ldGhvZHM6IG5vbmU7IEVE
SUQgdHJhbnNmZXIgdGltZTogMCBzZWNvbmRzDQooWEVOKSAgRURJRCBpbmZvIG5vdCByZXRy
aWV2ZWQgYmVjYXVzZSBubyBEREMgcmV0cmlldmFsIG1ldGhvZCBkZXRlY3RlZA0KKFhFTikg
RGlzYyBpbmZvcm1hdGlvbjoNCihYRU4pICBGb3VuZCAwIE1CUiBzaWduYXR1cmVzDQooWEVO
KSAgRm91bmQgMSBFREQgaW5mb3JtYXRpb24gc3RydWN0dXJlcw0KKFhFTikgWGVuLWU4MjAg
UkFNIG1hcDoNCihYRU4pICAwMDAwMDAwMDAwMDAwMDAwIC0gMDAwMDAwMDAwMDA5ZTgwMCAo
dXNhYmxlKQ0KKFhFTikgIDAwMDAwMDAwMDAwOWU4MDAgLSAwMDAwMDAwMDAwMGEwMDAwIChy
ZXNlcnZlZCkNCihYRU4pICAwMDAwMDAwMDAwMGU0MDAwIC0gMDAwMDAwMDAwMDEwMDAwMCAo
cmVzZXJ2ZWQpDQooWEVOKSAgMDAwMDAwMDAwMDEwMDAwMCAtIDAwMDAwMDAwN2VlNzAwMDAg
KHVzYWJsZSkNCihYRU4pICAwMDAwMDAwMDdlZTcwMDAwIC0gMDAwMDAwMDA3ZWU3ZTAwMCAo
QUNQSSBkYXRhKQ0KKFhFTikgIDAwMDAwMDAwN2VlN2UwMDAgLSAwMDAwMDAwMDdlZWQwMDAw
IChBQ1BJIE5WUykNCihYRU4pICAwMDAwMDAwMDdlZWQwMDAwIC0gMDAwMDAwMDA3ZWYwMDAw
MCAocmVzZXJ2ZWQpDQooWEVOKSAgMDAwMDAwMDBmZWQwMDAwMCAtIDAwMDAwMDAwZmVkMDEx
MDAgKHJlc2VydmVkKQ0KKFhFTikgIDAwMDAwMDAwZmVkMDIwMDAgLSAwMDAwMDAwMGZlZDE0
YzAwIChyZXNlcnZlZCkNCihYRU4pICAwMDAwMDAwMGZlZDIwMDAwIC0gMDAwMDAwMDBmZWQ0
MDAwMCAocmVzZXJ2ZWQpDQooWEVOKSAgMDAwMDAwMDBmZWUwMDAwMCAtIDAwMDAwMDAwZmVl
MDEwMDAgKHJlc2VydmVkKQ0KKFhFTikgIDAwMDAwMDAwZmZlMDAwMDAgLSAwMDAwMDAwMTAw
MDAwMDAwIChyZXNlcnZlZCkNCihYRU4pIFN5c3RlbSBSQU06IDIwMzBNQiAoMjA3ODc3NmtC
KQ0KKFhFTikgQUNQSTogUlNEUCAwMDBGQjA4MCwgMDAyNCAocjIgQUNQSUFNKQ0KKFhFTikg
QUNQSTogWFNEVCA3RUU3MDEwMCwgMDA1QyAocjEgQV9NX0lfIE9FTVhTRFQgICA1MDAxMDI1
IE1TRlQgICAgICAgOTcpDQooWEVOKSBBQ1BJOiBGQUNQIDdFRTcwMjkwLCAwMEY0IChyMyBB
X01fSV8gT0VNRkFDUCAgIDUwMDEwMjUgTVNGVCAgICAgICA5NykNCihYRU4pIEFDUEk6IERT
RFQgN0VFNzA0NDAsIDg0MUYgKHIxICBBMTA2NSBBMTA2NTAwMCAgICAgICAgMCBJTlRMIDIw
MDYwMTEzKQ0KKFhFTikgQUNQSTogRkFDUyA3RUU3RTAwMCwgMDA0MA0KKFhFTikgQUNQSTog
QVBJQyA3RUU3MDM5MCwgMDA2QyAocjEgQV9NX0lfIE9FTUFQSUMgICA1MDAxMDI1IE1TRlQg
ICAgICAgOTcpDQooWEVOKSBBQ1BJOiBNQ0ZHIDdFRTcwNDAwLCAwMDNDIChyMSBBX01fSV8g
T0VNTUNGRyAgIDUwMDEwMjUgTVNGVCAgICAgICA5NykNCihYRU4pIEFDUEk6IE9FTUIgN0VF
N0UwNDAsIDAwODkgKHIxIEFfTV9JXyBBTUlfT0VNICAgNTAwMTAyNSBNU0ZUICAgICAgIDk3
KQ0KKFhFTikgQUNQSTogSFBFVCA3RUU3ODg2MCwgMDAzOCAocjEgQV9NX0lfIE9FTUhQRVQg
ICA1MDAxMDI1IE1TRlQgICAgICAgOTcpDQooWEVOKSBBQ1BJOiBHU0NJIDdFRTdFMEQwLCAy
MDI0IChyMSBBX01fSV8gR01DSFNDSSAgIDUwMDEwMjUgTVNGVCAgICAgICA5NykNCihYRU4p
IEFDUEk6IFNTRFQgN0VFODBBMDAsIDBBN0MgKHIxIERwZ1BtbSAgICBDcHVQbSAgICAgICAx
MiBJTlRMIDIwMDYwMTEzKQ0KKFhFTikgTm8gTlVNQSBjb25maWd1cmF0aW9uIGZvdW5kDQoo
WEVOKSBGYWtpbmcgYSBub2RlIGF0IDAwMDAwMDAwMDAwMDAwMDAtMDAwMDAwMDA3ZWU3MDAw
MA0KKFhFTikgRG9tYWluIGhlYXAgaW5pdGlhbGlzZWQNCihYRU4pIHZlc2FmYjogZnJhbWVi
dWZmZXIgYXQgMHhmZDgwMDAwMCwgbWFwcGVkIHRvIDB4ZmZmZjgyYzAwMDAwMDAwMCwgdXNp
bmcgMjA0OGssIHRvdGFsIDQwOTZrDQooWEVOKSB2ZXNhZmI6IG1vZGUgaXMgODAweDYwMHg4
LCBsaW5lbGVuZ3RoPTgwMCwgZm9udCA4eDgNCihYRU4pIHZlc2FmYjogUHNldWRvY29sb3I6
IHNpemU9Njo2OjY6Niwgc2hpZnQ9MDowOjA6MA0KKFhFTikgZm91bmQgU01QIE1QLXRhYmxl
IGF0IDAwMGZmNzgwDQooWEVOKSBETUkgcHJlc2VudC4NCihYRU4pIEFQSUMgYm9vdCBzdGF0
ZSBpcyAneGFwaWMnDQooWEVOKSBVc2luZyBBUElDIGRyaXZlciBkZWZhdWx0DQooWEVOKSBB
Q1BJOiBQTS1UaW1lciBJTyBQb3J0OiAweDgwOA0KKFhFTikgQUNQSTogQUNQSSBTTEVFUCBJ
TkZPOiBwbTF4X2NudFs4MDQsMF0sIHBtMXhfZXZ0WzgwMCwwXQ0KKFhFTikgQUNQSTogICAg
ICAgICAgICAgICAgICB3YWtldXBfdmVjWzdlZTdlMDBjXSwgdmVjX3NpemVbMjBdDQooWEVO
KSBBQ1BJOiBMb2NhbCBBUElDIGFkZHJlc3MgMHhmZWUwMDAwMA0KKFhFTikgQUNQSTogTEFQ
SUMgKGFjcGlfaWRbMHgwMV0gbGFwaWNfaWRbMHgwMF0gZW5hYmxlZCkNCihYRU4pIFByb2Nl
c3NvciAjMCA3OjcgQVBJQyB2ZXJzaW9uIDIwDQooWEVOKSBBQ1BJOiBMQVBJQyAoYWNwaV9p
ZFsweDAyXSBsYXBpY19pZFsweDAxXSBlbmFibGVkKQ0KKFhFTikgUHJvY2Vzc29yICMxIDc6
NyBBUElDIHZlcnNpb24gMjANCihYRU4pIEFDUEk6IExBUElDIChhY3BpX2lkWzB4MDNdIGxh
cGljX2lkWzB4MDJdIGVuYWJsZWQpDQooWEVOKSBQcm9jZXNzb3IgIzIgNzo3IEFQSUMgdmVy
c2lvbiAyMA0KKFhFTikgQUNQSTogTEFQSUMgKGFjcGlfaWRbMHgwNF0gbGFwaWNfaWRbMHgw
M10gZW5hYmxlZCkNCihYRU4pIFByb2Nlc3NvciAjMyA3OjcgQVBJQyB2ZXJzaW9uIDIwDQoo
WEVOKSBBQ1BJOiBJT0FQSUMgKGlkWzB4MDRdIGFkZHJlc3NbMHhmZWMwMDAwMF0gZ3NpX2Jh
c2VbMF0pDQooWEVOKSBJT0FQSUNbMF06IGFwaWNfaWQgNCwgdmVyc2lvbiAzMiwgYWRkcmVz
cyAweGZlYzAwMDAwLCBHU0kgMC0yMw0KKFhFTikgQUNQSTogSU5UX1NSQ19PVlIgKGJ1cyAw
IGJ1c19pcnEgMCBnbG9iYWxfaXJxIDIgZGZsIGRmbCkNCihYRU4pIEFDUEk6IElOVF9TUkNf
T1ZSIChidXMgMCBidXNfaXJxIDkgZ2xvYmFsX2lycSA5IGhpZ2ggbGV2ZWwpDQooWEVOKSBB
Q1BJOiBJUlEwIHVzZWQgYnkgb3ZlcnJpZGUuDQooWEVOKSBBQ1BJOiBJUlEyIHVzZWQgYnkg
b3ZlcnJpZGUuDQooWEVOKSBBQ1BJOiBJUlE5IHVzZWQgYnkgb3ZlcnJpZGUuDQooWEVOKSBF
bmFibGluZyBBUElDIG1vZGU6ICBGbGF0LiAgVXNpbmcgMSBJL08gQVBJQ3MNCihYRU4pIEFD
UEk6IEhQRVQgaWQ6IDB4ODA4NmE3MDEgYmFzZTogMHhmZWQwMDAwMA0KKFhFTikgVGFibGUg
aXMgbm90IGZvdW5kIQ0KKFhFTikgVXNpbmcgQUNQSSAoTUFEVCkgZm9yIFNNUCBjb25maWd1
cmF0aW9uIGluZm9ybWF0aW9uDQooWEVOKSBTTVA6IEFsbG93aW5nIDQgQ1BVcyAoMCBob3Rw
bHVnIENQVXMpDQooWEVOKSBtYXBwZWQgQVBJQyB0byBmZmZmODJjM2ZmZGZlMDAwIChmZWUw
MDAwMCkNCihYRU4pIG1hcHBlZCBJT0FQSUMgdG8gZmZmZjgyYzNmZmRmZDAwMCAoZmVjMDAw
MDApDQooWEVOKSBJUlEgbGltaXRzOiAyNCBHU0ksIDc2MCBNU0kvTVNJLVgNCihYRU4pIFVz
aW5nIHNjaGVkdWxlcjogU01QIENyZWRpdCBTY2hlZHVsZXIgKGNyZWRpdCkNCihYRU4pIERl
dGVjdGVkIDI2NjYuNDI3IE1IeiBwcm9jZXNzb3IuDQooWEVOKSBJbml0aW5nIG1lbW9yeSBz
aGFyaW5nLg0KKFhFTikgeHN0YXRlX2luaXQ6IHVzaW5nIGNudHh0X3NpemU6IDB4MjQwIGFu
ZCBzdGF0ZXM6IDB4Mw0KKFhFTikgbWNlX2ludGVsLmM6MTIzOTogTUNBIENhcGFiaWxpdHk6
IEJDQVNUIDEgU0VSIDAgQ01DSSAwIGZpcnN0YmFuayAxIGV4dGVuZGVkIE1DRSBNU1IgMA0K
KFhFTikgSW50ZWwgbWFjaGluZSBjaGVjayByZXBvcnRpbmcgZW5hYmxlZA0KKFhFTikgUENJ
OiBNQ0ZHIGNvbmZpZ3VyYXRpb24gMDogYmFzZSBlMDAwMDAwMCBzZWdtZW50IDAwMDAgYnVz
ZXMgMDAgLSBmZg0KKFhFTikgUENJOiBOb3QgdXNpbmcgTUNGRyBmb3Igc2VnbWVudCAwMDAw
IGJ1cyAwMC1mZg0KKFhFTikgSS9PIHZpcnR1YWxpc2F0aW9uIGRpc2FibGVkDQooWEVOKSBH
ZXR0aW5nIFZFUlNJT046IDUwMDE0DQooWEVOKSBHZXR0aW5nIFZFUlNJT046IDUwMDE0DQoo
WEVOKSBHZXR0aW5nIElEOiAwDQooWEVOKSBHZXR0aW5nIExWVDA6IDcwMA0KKFhFTikgR2V0
dGluZyBMVlQxOiA0MDANCihYRU4pIGVuYWJsZWQgRXh0SU5UIG9uIENQVSMwDQooWEVOKSBF
TkFCTElORyBJTy1BUElDIElSUXMNCihYRU4pICAtPiBVc2luZyBuZXcgQUNLIG1ldGhvZA0K
KFhFTikgaW5pdCBJT19BUElDIElSUXMNCihYRU4pICBJTy1BUElDIChhcGljaWQtcGluKSA0
LTAsIDQtMTYsIDQtMTcsIDQtMTgsIDQtMTksIDQtMjAsIDQtMjEsIDQtMjIsIDQtMjMgbm90
IGNvbm5lY3RlZC4NCihYRU4pIC4uVElNRVI6IHZlY3Rvcj0weEYwIGFwaWMxPTAgcGluMT0y
IGFwaWMyPS0xIHBpbjI9LTENCihYRU4pIG51bWJlciBvZiBNUCBJUlEgc291cmNlczogMTUu
DQooWEVOKSBudW1iZXIgb2YgSU8tQVBJQyAjNCByZWdpc3RlcnM6IDI0Lg0KKFhFTikgdGVz
dGluZyB0aGUgSU8gQVBJQy4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uDQooWEVOKSBJTyBBUElD
ICM0Li4uLi4uDQooWEVOKSAuLi4uIHJlZ2lzdGVyICMwMDogMDQwMDAwMDANCihYRU4pIC4u
Li4uLi4gICAgOiBwaHlzaWNhbCBBUElDIGlkOiAwNA0KKFhFTikgLi4uLi4uLiAgICA6IERl
bGl2ZXJ5IFR5cGU6IDANCihYRU4pIC4uLi4uLi4gICAgOiBMVFMgICAgICAgICAgOiAwDQoo
WEVOKSAuLi4uIHJlZ2lzdGVyICMwMTogMDAxNzAwMjANCihYRU4pIC4uLi4uLi4gICAgIDog
bWF4IHJlZGlyZWN0aW9uIGVudHJpZXM6IDAwMTcNCihYRU4pIC4uLi4uLi4gICAgIDogUFJR
IGltcGxlbWVudGVkOiAwDQooWEVOKSAuLi4uLi4uICAgICA6IElPIEFQSUMgdmVyc2lvbjog
MDAyMA0KKFhFTikgLi4uLiBJUlEgcmVkaXJlY3Rpb24gdGFibGU6DQooWEVOKSAgTlIgTG9n
IFBoeSBNYXNrIFRyaWcgSVJSIFBvbCBTdGF0IERlc3QgRGVsaSBWZWN0OiAgIA0KKFhFTikg
IDAwIDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDAgICAgMDANCihYRU4p
ICAwMSAwMDEgMDEgIDAgICAgMCAgICAwICAgMCAgIDAgICAgMSAgICAxICAgIDI4DQooWEVO
KSAgMDIgMDAxIDAxICAwICAgIDAgICAgMCAgIDAgICAwICAgIDEgICAgMSAgICBGMA0KKFhF
TikgIDAzIDAwMSAwMSAgMCAgICAwICAgIDAgICAwICAgMCAgICAxICAgIDEgICAgMzANCihY
RU4pICAwNCAwMDEgMDEgIDAgICAgMCAgICAwICAgMCAgIDAgICAgMSAgICAxICAgIEYxDQoo
WEVOKSAgMDUgMDAxIDAxICAwICAgIDAgICAgMCAgIDAgICAwICAgIDEgICAgMSAgICAzOA0K
KFhFTikgIDA2IDAwMSAwMSAgMCAgICAwICAgIDAgICAwICAgMCAgICAxICAgIDEgICAgNDAN
CihYRU4pICAwNyAwMDEgMDEgIDAgICAgMCAgICAwICAgMCAgIDAgICAgMSAgICAxICAgIDQ4
DQooWEVOKSAgMDggMDAxIDAxICAwICAgIDAgICAgMCAgIDAgICAwICAgIDEgICAgMSAgICA1
MA0KKFhFTikgIDA5IDAwMSAwMSAgMSAgICAxICAgIDAgICAwICAgMCAgICAxICAgIDEgICAg
NTgNCihYRU4pICAwYSAwMDEgMDEgIDAgICAgMCAgICAwICAgMCAgIDAgICAgMSAgICAxICAg
IDYwDQooWEVOKSAgMGIgMDAxIDAxICAwICAgIDAgICAgMCAgIDAgICAwICAgIDEgICAgMSAg
ICA2OA0KKFhFTikgIDBjIDAwMSAwMSAgMCAgICAwICAgIDAgICAwICAgMCAgICAxICAgIDEg
ICAgNzANCihYRU4pICAwZCAwMDEgMDEgIDAgICAgMCAgICAwICAgMCAgIDAgICAgMSAgICAx
ICAgIDc4DQooWEVOKSAgMGUgMDAxIDAxICAwICAgIDAgICAgMCAgIDAgICAwICAgIDEgICAg
MSAgICA4OA0KKFhFTikgIDBmIDAwMSAwMSAgMCAgICAwICAgIDAgICAwICAgMCAgICAxICAg
IDEgICAgOTANCihYRU4pICAxMCAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAg
ICAwICAgIDAwDQooWEVOKSAgMTEgMDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAwICAgIDAg
ICAgMCAgICAwMA0KKFhFTikgIDEyIDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAw
ICAgIDAgICAgMDANCihYRU4pICAxMyAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAg
MCAgICAwICAgIDAwDQooWEVOKSAgMTQgMDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAwICAg
IDAgICAgMCAgICAwMA0KKFhFTikgIDE1IDAxMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAg
ICAwICAgIDIgICAgMjANCihYRU4pICAxNiAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAg
ICAgMCAgICAwICAgIDAwDQooWEVOKSAgMTcgMDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAw
ICAgIDAgICAgMCAgICAwMA0KKFhFTikgVXNpbmcgdmVjdG9yLWJhc2VkIGluZGV4aW5nDQoo
WEVOKSBJUlEgdG8gcGluIG1hcHBpbmdzOg0KKFhFTikgSVJRMjQwIC0+IDA6Mg0KKFhFTikg
SVJRNDAgLT4gMDoxDQooWEVOKSBJUlE0OCAtPiAwOjMNCihYRU4pIElSUTI0MSAtPiAwOjQN
CihYRU4pIElSUTU2IC0+IDA6NQ0KKFhFTikgSVJRNjQgLT4gMDo2DQooWEVOKSBJUlE3MiAt
PiAwOjcNCihYRU4pIElSUTgwIC0+IDA6OA0KKFhFTikgSVJRODggLT4gMDo5DQooWEVOKSBJ
UlE5NiAtPiAwOjEwDQooWEVOKSBJUlExMDQgLT4gMDoxMQ0KKFhFTikgSVJRMTEyIC0+IDA6
MTINCihYRU4pIElSUTEyMCAtPiAwOjEzDQooWEVOKSBJUlExMzYgLT4gMDoxNA0KKFhFTikg
SVJRMTQ0IC0+IDA6MTUNCihYRU4pIC4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u
Li4uLiBkb25lLg0KKFhFTikgVXNpbmcgbG9jYWwgQVBJQyB0aW1lciBpbnRlcnJ1cHRzLg0K
KFhFTikgY2FsaWJyYXRpbmcgQVBJQyB0aW1lciAuLi4NCihYRU4pIC4uLi4uIENQVSBjbG9j
ayBzcGVlZCBpcyAyNjY2LjM5MDMgTUh6Lg0KKFhFTikgLi4uLi4gaG9zdCBidXMgY2xvY2sg
c3BlZWQgaXMgMzMzLjI5ODcgTUh6Lg0KKFhFTikgLi4uLi4gYnVzX3NjYWxlID0gMHgwMDAx
NTU1NQ0KKFhFTikgWzIwMTItMDktMDQgMTY6NDA6NDNdIFBsYXRmb3JtIHRpbWVyIGlzIDE0
LjMxOE1IeiBIUEVUDQooWEVOKSBbMjAxMi0wOS0wNCAxNjo0MDo0M10gQWxsb2NhdGVkIGNv
bnNvbGUgcmluZyBvZiAzMiBLaUIuDQooWEVOKSBbMjAxMi0wOS0wNCAxNjo0MDo0M10gVk1Y
OiBTdXBwb3J0ZWQgYWR2YW5jZWQgZmVhdHVyZXM6DQooWEVOKSBbMjAxMi0wOS0wNCAxNjo0
MDo0M10gIC0gQVBJQyBNTUlPIGFjY2VzcyB2aXJ0dWFsaXNhdGlvbg0KKFhFTikgWzIwMTIt
MDktMDQgMTY6NDA6NDNdICAtIEFQSUMgVFBSIHNoYWRvdw0KKFhFTikgWzIwMTItMDktMDQg
MTY6NDA6NDNdICAtIFZpcnR1YWwgTk1JDQooWEVOKSBbMjAxMi0wOS0wNCAxNjo0MDo0M10g
IC0gTVNSIGRpcmVjdC1hY2Nlc3MgYml0bWFwDQooWEVOKSBbMjAxMi0wOS0wNCAxNjo0MDo0
M10gSFZNOiBBU0lEcyBkaXNhYmxlZC4NCihYRU4pIFsyMDEyLTA5LTA0IDE2OjQwOjQzXSBI
Vk06IFZNWCBlbmFibGVkDQooWEVOKSBbMjAxMi0wOS0wNCAxNjo0MDo0Ml0gbWFza2VkIEV4
dElOVCBvbiBDUFUjMQ0KKFhFTikgWzIwMTItMDktMDQgMTY6NDA6NDJdIG1hc2tlZCBFeHRJ
TlQgb24gQ1BVIzINCihYRU4pIFsyMDEyLTA5LTA0IDE2OjQwOjQyXSBtYXNrZWQgRXh0SU5U
IG9uIENQVSMzDQooWEVOKSBbMjAxMi0wOS0wNCAxNjo0MDo0M10gQnJvdWdodCB1cCA0IENQ
VXMNCihYRU4pIFsyMDEyLTA5LTA0IDE2OjQwOjQzXSBIUEVUOiA4IHRpbWVycyAoOCB3aWxs
IGJlIHVzZWQgZm9yIGJyb2FkY2FzdCkNCihYRU4pIFsyMDEyLTA5LTA0IDE2OjQwOjQzXSBB
Q1BJIHNsZWVwIG1vZGVzOiBTMw0KKFhFTikgWzIwMTItMDktMDQgMTY6NDA6NDNdIG1jaGVj
a19wb2xsOiBNYWNoaW5lIGNoZWNrIHBvbGxpbmcgdGltZXIgc3RhcnRlZC4NCihYRU4pIFsy
MDEyLTA5LTA0IDE2OjQwOjQzXSAqKiogTE9BRElORyBET01BSU4gMCAqKioNCihYRU4pIFsy
MDEyLTA5LTA0IDE2OjQwOjQzXSBlbGZfcGFyc2VfYmluYXJ5OiBwaGRyOiBwYWRkcj0weDEw
MDAwMDAgbWVtc3o9MHhkNzQwMDANCihYRU4pIFsyMDEyLTA5LTA0IDE2OjQwOjQzXSBlbGZf
cGFyc2VfYmluYXJ5OiBwaGRyOiBwYWRkcj0weDFlMDAwMDAgbWVtc3o9MHhkZDBlOA0KKFhF
TikgWzIwMTItMDktMDQgMTY6NDA6NDNdIGVsZl9wYXJzZV9iaW5hcnk6IHBoZHI6IHBhZGRy
PTB4MWVkZTAwMCBtZW1zej0weDEzYzAwDQooWEVOKSBbMjAxMi0wOS0wNCAxNjo0MDo0M10g
ZWxmX3BhcnNlX2JpbmFyeTogcGhkcjogcGFkZHI9MHgxZWYyMDAwIG1lbXN6PTB4ZGU2MDAw
DQooWEVOKSBbMjAxMi0wOS0wNCAxNjo0MDo0M10gZWxmX3BhcnNlX2JpbmFyeTogbWVtb3J5
OiAweDEwMDAwMDAgLT4gMHgyY2Q4MDAwDQooWEVOKSBbMjAxMi0wOS0wNCAxNjo0MDo0M10g
ZWxmX3hlbl9wYXJzZV9ub3RlOiBHVUVTVF9PUyA9ICJsaW51eCINCihYRU4pIFsyMDEyLTA5
LTA0IDE2OjQwOjQzXSBlbGZfeGVuX3BhcnNlX25vdGU6IEdVRVNUX1ZFUlNJT04gPSAiMi42
Ig0KKFhFTikgWzIwMTItMDktMDQgMTY6NDA6NDNdIGVsZl94ZW5fcGFyc2Vfbm90ZTogWEVO
X1ZFUlNJT04gPSAieGVuLTMuMCINCihYRU4pIFsyMDEyLTA5LTA0IDE2OjQwOjQzXSBlbGZf
eGVuX3BhcnNlX25vdGU6IFZJUlRfQkFTRSA9IDB4ZmZmZmZmZmY4MDAwMDAwMA0KKFhFTikg
WzIwMTItMDktMDQgMTY6NDA6NDNdIGVsZl94ZW5fcGFyc2Vfbm90ZTogRU5UUlkgPSAweGZm
ZmZmZmZmODFlZjIyMTANCihYRU4pIFsyMDEyLTA5LTA0IDE2OjQwOjQzXSBlbGZfeGVuX3Bh
cnNlX25vdGU6IEhZUEVSQ0FMTF9QQUdFID0gMHhmZmZmZmZmZjgxMDAxMDAwDQooWEVOKSBb
MjAxMi0wOS0wNCAxNjo0MDo0M10gZWxmX3hlbl9wYXJzZV9ub3RlOiBGRUFUVVJFUyA9ICIh
d3JpdGFibGVfcGFnZV90YWJsZXN8cGFlX3BnZGlyX2Fib3ZlXzRnYiINCihYRU4pIFsyMDEy
LTA5LTA0IDE2OjQwOjQzXSBlbGZfeGVuX3BhcnNlX25vdGU6IFBBRV9NT0RFID0gInllcyIN
CihYRU4pIFsyMDEyLTA5LTA0IDE2OjQwOjQzXSBlbGZfeGVuX3BhcnNlX25vdGU6IExPQURF
UiA9ICJnZW5lcmljIg0KKFhFTikgWzIwMTItMDktMDQgMTY6NDA6NDNdIGVsZl94ZW5fcGFy
c2Vfbm90ZTogdW5rbm93biB4ZW4gZWxmIG5vdGUgKDB4ZCkNCihYRU4pIFsyMDEyLTA5LTA0
IDE2OjQwOjQzXSBlbGZfeGVuX3BhcnNlX25vdGU6IFNVU1BFTkRfQ0FOQ0VMID0gMHgxDQoo
WEVOKSBbMjAxMi0wOS0wNCAxNjo0MDo0M10gZWxmX3hlbl9wYXJzZV9ub3RlOiBIVl9TVEFS
VF9MT1cgPSAweGZmZmY4MDAwMDAwMDAwMDANCihYRU4pIFsyMDEyLTA5LTA0IDE2OjQwOjQz
XSBlbGZfeGVuX3BhcnNlX25vdGU6IFBBRERSX09GRlNFVCA9IDB4MA0KKFhFTikgWzIwMTIt
MDktMDQgMTY6NDA6NDNdIGVsZl94ZW5fYWRkcl9jYWxjX2NoZWNrOiBhZGRyZXNzZXM6DQoo
WEVOKSBbMjAxMi0wOS0wNCAxNjo0MDo0M10gICAgIHZpcnRfYmFzZSAgICAgICAgPSAweGZm
ZmZmZmZmODAwMDAwMDANCihYRU4pIFsyMDEyLTA5LTA0IDE2OjQwOjQzXSAgICAgZWxmX3Bh
ZGRyX29mZnNldCA9IDB4MA0KKFhFTikgWzIwMTItMDktMDQgMTY6NDA6NDNdICAgICB2aXJ0
X29mZnNldCAgICAgID0gMHhmZmZmZmZmZjgwMDAwMDAwDQooWEVOKSBbMjAxMi0wOS0wNCAx
Njo0MDo0M10gICAgIHZpcnRfa3N0YXJ0ICAgICAgPSAweGZmZmZmZmZmODEwMDAwMDANCihY
RU4pIFsyMDEyLTA5LTA0IDE2OjQwOjQzXSAgICAgdmlydF9rZW5kICAgICAgICA9IDB4ZmZm
ZmZmZmY4MmNkODAwMA0KKFhFTikgWzIwMTItMDktMDQgMTY6NDA6NDNdICAgICB2aXJ0X2Vu
dHJ5ICAgICAgID0gMHhmZmZmZmZmZjgxZWYyMjEwDQooWEVOKSBbMjAxMi0wOS0wNCAxNjo0
MDo0M10gICAgIHAybV9iYXNlICAgICAgICAgPSAweGZmZmZmZmZmZmZmZmZmZmYNCihYRU4p
IFsyMDEyLTA5LTA0IDE2OjQwOjQzXSAgWGVuICBrZXJuZWw6IDY0LWJpdCwgbHNiLCBjb21w
YXQzMg0KKFhFTikgWzIwMTItMDktMDQgMTY6NDA6NDNdICBEb20wIGtlcm5lbDogNjQtYml0
LCBQQUUsIGxzYiwgcGFkZHIgMHgxMDAwMDAwIC0+IDB4MmNkODAwMA0KKFhFTikgWzIwMTIt
MDktMDQgMTY6NDA6NDNdIFBIWVNJQ0FMIE1FTU9SWSBBUlJBTkdFTUVOVDoNCihYRU4pIFsy
MDEyLTA5LTA0IDE2OjQwOjQzXSAgRG9tMCBhbGxvYy46ICAgMDAwMDAwMDA3NDAwMDAwMC0+
MDAwMDAwMDA3ODAwMDAwMCAoMjQ0NjE3IHBhZ2VzIHRvIGJlIGFsbG9jYXRlZCkNCihYRU4p
IFsyMDEyLTA5LTA0IDE2OjQwOjQ0XSAgSW5pdC4gcmFtZGlzazogMDAwMDAwMDA3ZTU4OTAw
MC0+MDAwMDAwMDA3ZTlmZjYwMA0KKFhFTikgWzIwMTItMDktMDQgMTY6NDA6NDRdIFZJUlRV
QUwgTUVNT1JZIEFSUkFOR0VNRU5UOg0KKFhFTikgWzIwMTItMDktMDQgMTY6NDA6NDRdICBM
b2FkZWQga2VybmVsOiBmZmZmZmZmZjgxMDAwMDAwLT5mZmZmZmZmZjgyY2Q4MDAwDQooWEVO
KSBbMjAxMi0wOS0wNCAxNjo0MDo0NF0gIEluaXQuIHJhbWRpc2s6IGZmZmZmZmZmODJjZDgw
MDAtPmZmZmZmZmZmODMxNGU2MDANCihYRU4pIFsyMDEyLTA5LTA0IDE2OjQwOjQ0XSAgUGh5
cy1NYWNoIG1hcDogZmZmZmZmZmY4MzE0ZjAwMC0+ZmZmZmZmZmY4MzM0ZjAwMA0KKFhFTikg
WzIwMTItMDktMDQgMTY6NDA6NDRdICBTdGFydCBpbmZvOiAgICBmZmZmZmZmZjgzMzRmMDAw
LT5mZmZmZmZmZjgzMzRmNGI0DQooWEVOKSBbMjAxMi0wOS0wNCAxNjo0MDo0NF0gIFBhZ2Ug
dGFibGVzOiAgIGZmZmZmZmZmODMzNTAwMDAtPmZmZmZmZmZmODMzNmQwMDANCihYRU4pIFsy
MDEyLTA5LTA0IDE2OjQwOjQ0XSAgQm9vdCBzdGFjazogICAgZmZmZmZmZmY4MzM2ZDAwMC0+
ZmZmZmZmZmY4MzM2ZTAwMA0KKFhFTikgWzIwMTItMDktMDQgMTY6NDA6NDRdICBUT1RBTDog
ICAgICAgICBmZmZmZmZmZjgwMDAwMDAwLT5mZmZmZmZmZjgzNDAwMDAwDQooWEVOKSBbMjAx
Mi0wOS0wNCAxNjo0MDo0NF0gIEVOVFJZIEFERFJFU1M6IGZmZmZmZmZmODFlZjIyMTANCihY
RU4pIFsyMDEyLTA5LTA0IDE2OjQwOjQ0XSBEb20wIGhhcyBtYXhpbXVtIDQgVkNQVXMNCihY
RU4pIFsyMDEyLTA5LTA0IDE2OjQwOjQ0XSBlbGZfbG9hZF9iaW5hcnk6IHBoZHIgMCBhdCAw
eGZmZmZmZmZmODEwMDAwMDAgLT4gMHhmZmZmZmZmZjgxZDc0MDAwDQooWEVOKSBbMjAxMi0w
OS0wNCAxNjo0MDo0NF0gZWxmX2xvYWRfYmluYXJ5OiBwaGRyIDEgYXQgMHhmZmZmZmZmZjgx
ZTAwMDAwIC0+IDB4ZmZmZmZmZmY4MWVkZDBlOA0KKFhFTikgWzIwMTItMDktMDQgMTY6NDA6
NDRdIGVsZl9sb2FkX2JpbmFyeTogcGhkciAyIGF0IDB4ZmZmZmZmZmY4MWVkZTAwMCAtPiAw
eGZmZmZmZmZmODFlZjFjMDANCihYRU4pIFsyMDEyLTA5LTA0IDE2OjQwOjQ0XSBlbGZfbG9h
ZF9iaW5hcnk6IHBoZHIgMyBhdCAweGZmZmZmZmZmODFlZjIwMDAgLT4gMHhmZmZmZmZmZjgx
ZjhjMDAwDQooWEVOKSBbMjAxMi0wOS0wNCAxNjo0MDo0NF0gU2NydWJiaW5nIEZyZWUgUkFN
OiAuLi4uLi4uLi5kb25lLg0KKFhFTikgWzIwMTItMDktMDQgMTY6NDA6NDRdIEluaXRpYWwg
bG93IG1lbW9yeSB2aXJxIHRocmVzaG9sZCBzZXQgYXQgMHg0MDAwIHBhZ2VzLg0KKFhFTikg
WzIwMTItMDktMDQgMTY6NDA6NDRdIFN0ZC4gTG9nbGV2ZWw6IEFsbA0KKFhFTikgWzIwMTIt
MDktMDQgMTY6NDA6NDRdIEd1ZXN0IExvZ2xldmVsOiBBbGwNCihYRU4pIFsyMDEyLTA5LTA0
IDE2OjQwOjQ0XSBYZW4gaXMgcmVsaW5xdWlzaGluZyBWR0EgY29uc29sZS4NCihYRU4pIFsy
MDEyLTA5LTA0IDE2OjQwOjQ0XSAqKiogU2VyaWFsIGlucHV0IC0+IERPTTAgKHR5cGUgJ0NU
UkwtYScgdGhyZWUgdGltZXMgdG8gc3dpdGNoIGlucHV0IHRvIFhlbikNCihYRU4pIFsyMDEy
LTA5LTA0IDE2OjQwOjQ0XSBGcmVlZCAyNTZrQiBpbml0IG1lbW9yeS4NCm1hcHBpbmcga2Vy
bmVsIGludG8gcGh5c2ljYWwgbWVtb3J5DQphYm91dCB0byBnZXQgc3RhcnRlZC4uLg0KWyAg
ICAwLjAwMDAwMF0gSW5pdGlhbGl6aW5nIGNncm91cCBzdWJzeXMgY3B1c2V0DQpbICAgIDAu
MDAwMDAwXSBJbml0aWFsaXppbmcgY2dyb3VwIHN1YnN5cyBjcHUNClsgICAgMC4wMDAwMDBd
IExpbnV4IHZlcnNpb24gMy42LjAtcmM0LTIwMTIwODMwKyAocm9vdEB4ZW50ZXN0KSAoZ2Nj
IHZlcnNpb24gNC40LjUgKERlYmlhbiA0LjQuNS04KSApICM2NiBTTVAgUFJFRU1QVCBNb24g
U2VwIDMgMjA6MDU6NTAgQ0VTVCAyMDEyDQpbICAgIDAuMDAwMDAwXSBDb21tYW5kIGxpbmU6
IHJvb3Q9L2Rldi9zZGExIHJvIHZlcmJvc2UgbWVtPTEwMjRNIGNvbnNvbGU9aHZjMCBjb25z
b2xlPXR0eTAgbm9tb2Rlc2V0IHZnYT0zMDMgZWFybHlwcmludGs9eGVuIG1heF9sb29wPTUw
IGxvb3BfbWF4X3BhcnQ9MTAgZGVidWcgbG9nbGV2ZWw9MTANClsgICAgMC4wMDAwMDBdIEZy
ZWVpbmcgOWUtMTAwIHBmbiByYW5nZTogOTggcGFnZXMgZnJlZWQNClsgICAgMC4wMDAwMDBd
IFJlbGVhc2VkIDk4IHBhZ2VzIG9mIHVudXNlZCBtZW1vcnkNClsgICAgMC4wMDAwMDBdIFNl
dCA1Mjg4ODIgcGFnZShzKSB0byAxLTEgbWFwcGluZw0KWyAgICAwLjAwMDAwMF0gUG9wdWxh
dGluZyA0MDAwMC00MDA2MiBwZm4gcmFuZ2U6IDk4IHBhZ2VzIGFkZGVkDQpbICAgIDAuMDAw
MDAwXSBlODIwOiBCSU9TLXByb3ZpZGVkIHBoeXNpY2FsIFJBTSBtYXA6DQpbICAgIDAuMDAw
MDAwXSBYZW46IFttZW0gMHgwMDAwMDAwMDAwMDAwMDAwLTB4MDAwMDAwMDAwMDA5ZGZmZl0g
dXNhYmxlDQpbICAgIDAuMDAwMDAwXSBYZW46IFttZW0gMHgwMDAwMDAwMDAwMDllODAwLTB4
MDAwMDAwMDAwMDBmZmZmZl0gcmVzZXJ2ZWQNClsgICAgMC4wMDAwMDBdIFhlbjogW21lbSAw
eDAwMDAwMDAwMDAxMDAwMDAtMHgwMDAwMDAwMDQwMDYxZmZmXSB1c2FibGUNClsgICAgMC4w
MDAwMDBdIFhlbjogW21lbSAweDAwMDAwMDAwNDAwNjIwMDAtMHgwMDAwMDAwMDdlZTZmZmZm
XSB1bnVzYWJsZQ0KWyAgICAwLjAwMDAwMF0gWGVuOiBbbWVtIDB4MDAwMDAwMDA3ZWU3MDAw
MC0weDAwMDAwMDAwN2VlN2RmZmZdIEFDUEkgZGF0YQ0KWyAgICAwLjAwMDAwMF0gWGVuOiBb
bWVtIDB4MDAwMDAwMDA3ZWU3ZTAwMC0weDAwMDAwMDAwN2VlY2ZmZmZdIEFDUEkgTlZTDQpb
ICAgIDAuMDAwMDAwXSBYZW46IFttZW0gMHgwMDAwMDAwMDdlZWQwMDAwLTB4MDAwMDAwMDA3
ZWVmZmZmZl0gcmVzZXJ2ZWQNClsgICAgMC4wMDAwMDBdIFhlbjogW21lbSAweDAwMDAwMDAw
ZmVjMDAwMDAtMHgwMDAwMDAwMGZlYzAwZmZmXSByZXNlcnZlZA0KWyAgICAwLjAwMDAwMF0g
WGVuOiBbbWVtIDB4MDAwMDAwMDBmZWQwMDAwMC0weDAwMDAwMDAwZmVkMDEwZmZdIHJlc2Vy
dmVkDQpbICAgIDAuMDAwMDAwXSBYZW46IFttZW0gMHgwMDAwMDAwMGZlZDAyMDAwLTB4MDAw
MDAwMDBmZWQxNGJmZl0gcmVzZXJ2ZWQNClsgICAgMC4wMDAwMDBdIFhlbjogW21lbSAweDAw
MDAwMDAwZmVkMjAwMDAtMHgwMDAwMDAwMGZlZDNmZmZmXSByZXNlcnZlZA0KWyAgICAwLjAw
MDAwMF0gWGVuOiBbbWVtIDB4MDAwMDAwMDBmZWUwMDAwMC0weDAwMDAwMDAwZmVlMDBmZmZd
IHJlc2VydmVkDQpbICAgIDAuMDAwMDAwXSBYZW46IFttZW0gMHgwMDAwMDAwMGZmZTAwMDAw
LTB4MDAwMDAwMDBmZmZmZmZmZl0gcmVzZXJ2ZWQNClsgICAgMC4wMDAwMDBdIGJvb3Rjb25z
b2xlIFt4ZW5ib290MF0gZW5hYmxlZA0KWyAgICAwLjAwMDAwMF0gTlggKEV4ZWN1dGUgRGlz
YWJsZSkgcHJvdGVjdGlvbjogYWN0aXZlDQpbICAgIDAuMDAwMDAwXSBlODIwOiB1c2VyLWRl
ZmluZWQgcGh5c2ljYWwgUkFNIG1hcDoNClsgICAgMC4wMDAwMDBdIHVzZXI6IFttZW0gMHgw
MDAwMDAwMDAwMDAwMDAwLTB4MDAwMDAwMDAwMDA5ZGZmZl0gdXNhYmxlDQpbICAgIDAuMDAw
MDAwXSB1c2VyOiBbbWVtIDB4MDAwMDAwMDAwMDA5ZTgwMC0weDAwMDAwMDAwMDAwZmZmZmZd
IHJlc2VydmVkDQpbICAgIDAuMDAwMDAwXSB1c2VyOiBbbWVtIDB4MDAwMDAwMDAwMDEwMDAw
MC0weDAwMDAwMDAwM2ZmZmZmZmZdIHVzYWJsZQ0KWyAgICAwLjAwMDAwMF0gdXNlcjogW21l
bSAweDAwMDAwMDAwNDAwNjIwMDAtMHgwMDAwMDAwMDdlZTZmZmZmXSB1bnVzYWJsZQ0KWyAg
ICAwLjAwMDAwMF0gdXNlcjogW21lbSAweDAwMDAwMDAwN2VlNzAwMDAtMHgwMDAwMDAwMDdl
ZTdkZmZmXSBBQ1BJIGRhdGENClsgICAgMC4wMDAwMDBdIHVzZXI6IFttZW0gMHgwMDAwMDAw
MDdlZTdlMDAwLTB4MDAwMDAwMDA3ZWVjZmZmZl0gQUNQSSBOVlMNClsgICAgMC4wMDAwMDBd
IHVzZXI6IFttZW0gMHgwMDAwMDAwMDdlZWQwMDAwLTB4MDAwMDAwMDA3ZWVmZmZmZl0gcmVz
ZXJ2ZWQNClsgICAgMC4wMDAwMDBdIHVzZXI6IFttZW0gMHgwMDAwMDAwMGZlYzAwMDAwLTB4
MDAwMDAwMDBmZWMwMGZmZl0gcmVzZXJ2ZWQNClsgICAgMC4wMDAwMDBdIHVzZXI6IFttZW0g
MHgwMDAwMDAwMGZlZDAwMDAwLTB4MDAwMDAwMDBmZWQwMTBmZl0gcmVzZXJ2ZWQNClsgICAg
MC4wMDAwMDBdIHVzZXI6IFttZW0gMHgwMDAwMDAwMGZlZDAyMDAwLTB4MDAwMDAwMDBmZWQx
NGJmZl0gcmVzZXJ2ZWQNClsgICAgMC4wMDAwMDBdIHVzZXI6IFttZW0gMHgwMDAwMDAwMGZl
ZDIwMDAwLTB4MDAwMDAwMDBmZWQzZmZmZl0gcmVzZXJ2ZWQNClsgICAgMC4wMDAwMDBdIHVz
ZXI6IFttZW0gMHgwMDAwMDAwMGZlZTAwMDAwLTB4MDAwMDAwMDBmZWUwMGZmZl0gcmVzZXJ2
ZWQNClsgICAgMC4wMDAwMDBdIHVzZXI6IFttZW0gMHgwMDAwMDAwMGZmZTAwMDAwLTB4MDAw
MDAwMDBmZmZmZmZmZl0gcmVzZXJ2ZWQNClsgICAgMC4wMDAwMDBdIERNSSBwcmVzZW50Lg0K
WyAgICAwLjAwMDAwMF0gRE1JOiBTeXN0ZW0gbWFudWZhY3R1cmVyIFN5c3RlbSBQcm9kdWN0
IE5hbWUvUDVRLUVNIERPLCBCSU9TIDEyMDggICAgMDUvMjUvMjAxMA0KWyAgICAwLjAwMDAw
MF0gZTgyMDogdXBkYXRlIFttZW0gMHgwMDAwMDAwMC0weDAwMDBmZmZmXSB1c2FibGUgPT0+
IHJlc2VydmVkDQpbICAgIDAuMDAwMDAwXSBlODIwOiByZW1vdmUgW21lbSAweDAwMGEwMDAw
LTB4MDAwZmZmZmZdIHVzYWJsZQ0KWyAgICAwLjAwMDAwMF0gTm8gQUdQIGJyaWRnZSBmb3Vu
ZA0KWyAgICAwLjAwMDAwMF0gZTgyMDogbGFzdF9wZm4gPSAweDQwMDAwIG1heF9hcmNoX3Bm
biA9IDB4NDAwMDAwMDAwDQpbICAgIDAuMDAwMDAwXSBmb3VuZCBTTVAgTVAtdGFibGUgYXQg
W21lbSAweDAwMGZmNzgwLTB4MDAwZmY3OGZdIG1hcHBlZCBhdCBbZmZmZjg4MDAwMDBmZjc4
MF0NClsgICAgMC4wMDAwMDBdIGluaXRpYWwgbWVtb3J5IG1hcHBlZDogW21lbSAweDAwMDAw
MDAwLTB4MDMxNGVmZmZdDQpbICAgIDAuMDAwMDAwXSBCYXNlIG1lbW9yeSB0cmFtcG9saW5l
IGF0IFtmZmZmODgwMDAwMDk4MDAwXSA5ODAwMCBzaXplIDI0NTc2DQpbICAgIDAuMDAwMDAw
XSBpbml0X21lbW9yeV9tYXBwaW5nOiBbbWVtIDB4MDAwMDAwMDAtMHgzZmZmZmZmZl0NClsg
ICAgMC4wMDAwMDBdICBbbWVtIDB4MDAwMDAwMDAtMHgzZmZmZmZmZl0gcGFnZSA0aw0KWyAg
ICAwLjAwMDAwMF0ga2VybmVsIGRpcmVjdCBtYXBwaW5nIHRhYmxlcyB1cCB0byAweDNmZmZm
ZmZmIEAgW21lbSAweDAyYWQ2MDAwLTB4MDJjZDdmZmZdDQpbICAgIDAuMDAwMDAwXSB4ZW46
IHNldHRpbmcgUlcgdGhlIHJhbmdlIDJjYjgwMDAgLSAyY2Q4MDAwDQpbICAgIDAuMDAwMDAw
XSBSQU1ESVNLOiBbbWVtIDB4MDJjZDgwMDAtMHgwMzE0ZWZmZl0NClsgICAgMC4wMDAwMDBd
IEFDUEk6IFJTRFAgMDAwMDAwMDAwMDBmYjA4MCAwMDAyNCAodjAyIEFDUElBTSkNClsgICAg
MC4wMDAwMDBdIEFDUEk6IFhTRFQgMDAwMDAwMDA3ZWU3MDEwMCAwMDA1QyAodjAxIEFfTV9J
XyBPRU1YU0RUICAwNTAwMTAyNSBNU0ZUIDAwMDAwMDk3KQ0KWyAgICAwLjAwMDAwMF0gQUNQ
STogRkFDUCAwMDAwMDAwMDdlZTcwMjkwIDAwMEY0ICh2MDMgQV9NX0lfIE9FTUZBQ1AgIDA1
MDAxMDI1IE1TRlQgMDAwMDAwOTcpDQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBEU0RUIDAwMDAw
MDAwN2VlNzA0NDAgMDg0MUYgKHYwMSAgQTEwNjUgQTEwNjUwMDAgMDAwMDAwMDAgSU5UTCAy
MDA2MDExMykNClsgICAgMC4wMDAwMDBdIEFDUEk6IEZBQ1MgMDAwMDAwMDA3ZWU3ZTAwMCAw
MDA0MA0KWyAgICAwLjAwMDAwMF0gQUNQSTogQVBJQyAwMDAwMDAwMDdlZTcwMzkwIDAwMDZD
ICh2MDEgQV9NX0lfIE9FTUFQSUMgIDA1MDAxMDI1IE1TRlQgMDAwMDAwOTcpDQpbICAgIDAu
MDAwMDAwXSBBQ1BJOiBNQ0ZHIDAwMDAwMDAwN2VlNzA0MDAgMDAwM0MgKHYwMSBBX01fSV8g
T0VNTUNGRyAgMDUwMDEwMjUgTVNGVCAwMDAwMDA5NykNClsgICAgMC4wMDAwMDBdIEFDUEk6
IE9FTUIgMDAwMDAwMDA3ZWU3ZTA0MCAwMDA4OSAodjAxIEFfTV9JXyBBTUlfT0VNICAwNTAw
MTAyNSBNU0ZUIDAwMDAwMDk3KQ0KWyAgICAwLjAwMDAwMF0gQUNQSTogSFBFVCAwMDAwMDAw
MDdlZTc4ODYwIDAwMDM4ICh2MDEgQV9NX0lfIE9FTUhQRVQgIDA1MDAxMDI1IE1TRlQgMDAw
MDAwOTcpDQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBHU0NJIDAwMDAwMDAwN2VlN2UwZDAgMDIw
MjQgKHYwMSBBX01fSV8gR01DSFNDSSAgMDUwMDEwMjUgTVNGVCAwMDAwMDA5NykNClsgICAg
MC4wMDAwMDBdIEFDUEk6IFNTRFQgMDAwMDAwMDA3ZWU4MGEwMCAwMEE3QyAodjAxIERwZ1Bt
bSAgICBDcHVQbSAwMDAwMDAxMiBJTlRMIDIwMDYwMTEzKQ0KWyAgICAwLjAwMDAwMF0gQUNQ
STogTG9jYWwgQVBJQyBhZGRyZXNzIDB4ZmVlMDAwMDANClsgICAgMC4wMDAwMDBdIE5vIE5V
TUEgY29uZmlndXJhdGlvbiBmb3VuZA0KWyAgICAwLjAwMDAwMF0gRmFraW5nIGEgbm9kZSBh
dCBbbWVtIDB4MDAwMDAwMDAwMDAwMDAwMC0weDAwMDAwMDAwM2ZmZmZmZmZdDQpbICAgIDAu
MDAwMDAwXSBJbml0bWVtIHNldHVwIG5vZGUgMCBbbWVtIDB4MDAwMDAwMDAtMHgzZmZmZmZm
Zl0NClsgICAgMC4wMDAwMDBdICAgTk9ERV9EQVRBIFttZW0gMHgzZmZmNTAwMC0weDNmZmZm
ZmZmXQ0KWyAgICAwLjAwMDAwMF0gWm9uZSByYW5nZXM6DQpbICAgIDAuMDAwMDAwXSAgIERN
QSAgICAgIFttZW0gMHgwMDAxMDAwMC0weDAwZmZmZmZmXQ0KWyAgICAwLjAwMDAwMF0gICBE
TUEzMiAgICBbbWVtIDB4MDEwMDAwMDAtMHhmZmZmZmZmZl0NClsgICAgMC4wMDAwMDBdICAg
Tm9ybWFsICAgZW1wdHkNClsgICAgMC4wMDAwMDBdIE1vdmFibGUgem9uZSBzdGFydCBmb3Ig
ZWFjaCBub2RlDQpbICAgIDAuMDAwMDAwXSBFYXJseSBtZW1vcnkgbm9kZSByYW5nZXMNClsg
ICAgMC4wMDAwMDBdICAgbm9kZSAgIDA6IFttZW0gMHgwMDAxMDAwMC0weDAwMDlkZmZmXQ0K
WyAgICAwLjAwMDAwMF0gICBub2RlICAgMDogW21lbSAweDAwMTAwMDAwLTB4M2ZmZmZmZmZd
DQpbICAgIDAuMDAwMDAwXSBPbiBub2RlIDAgdG90YWxwYWdlczogMjYyMDMwDQpbICAgIDAu
MDAwMDAwXSAgIERNQSB6b25lOiA2NCBwYWdlcyB1c2VkIGZvciBtZW1tYXANClsgICAgMC4w
MDAwMDBdICAgRE1BIHpvbmU6IDYgcGFnZXMgcmVzZXJ2ZWQNClsgICAgMC4wMDAwMDBdICAg
RE1BIHpvbmU6IDM5MTIgcGFnZXMsIExJRk8gYmF0Y2g6MA0KWyAgICAwLjAwMDAwMF0gICBE
TUEzMiB6b25lOiA0MDMyIHBhZ2VzIHVzZWQgZm9yIG1lbW1hcA0KWyAgICAwLjAwMDAwMF0g
ICBETUEzMiB6b25lOiAyNTQwMTYgcGFnZXMsIExJRk8gYmF0Y2g6MzENClsgICAgMC4wMDAw
MDBdIEFDUEk6IFBNLVRpbWVyIElPIFBvcnQ6IDB4ODA4DQpbICAgIDAuMDAwMDAwXSBBQ1BJ
OiBMb2NhbCBBUElDIGFkZHJlc3MgMHhmZWUwMDAwMA0KWyAgICAwLjAwMDAwMF0gQUNQSTog
TEFQSUMgKGFjcGlfaWRbMHgwMV0gbGFwaWNfaWRbMHgwMF0gZW5hYmxlZCkNClsgICAgMC4w
MDAwMDBdIEFDUEk6IExBUElDIChhY3BpX2lkWzB4MDJdIGxhcGljX2lkWzB4MDFdIGVuYWJs
ZWQpDQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBMQVBJQyAoYWNwaV9pZFsweDAzXSBsYXBpY19p
ZFsweDAyXSBlbmFibGVkKQ0KWyAgICAwLjAwMDAwMF0gQUNQSTogTEFQSUMgKGFjcGlfaWRb
MHgwNF0gbGFwaWNfaWRbMHgwM10gZW5hYmxlZCkNClsgICAgMC4wMDAwMDBdIEFDUEk6IElP
QVBJQyAoaWRbMHgwNF0gYWRkcmVzc1sweGZlYzAwMDAwXSBnc2lfYmFzZVswXSkNClsgICAg
MC4wMDAwMDBdIElPQVBJQ1swXTogYXBpY19pZCA0LCB2ZXJzaW9uIDMyLCBhZGRyZXNzIDB4
ZmVjMDAwMDAsIEdTSSAwLTIzDQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBJTlRfU1JDX09WUiAo
YnVzIDAgYnVzX2lycSAwIGdsb2JhbF9pcnEgMiBkZmwgZGZsKQ0KWyAgICAwLjAwMDAwMF0g
QUNQSTogSU5UX1NSQ19PVlIgKGJ1cyAwIGJ1c19pcnEgOSBnbG9iYWxfaXJxIDkgaGlnaCBs
ZXZlbCkNClsgICAgMC4wMDAwMDBdIEFDUEk6IElSUTAgdXNlZCBieSBvdmVycmlkZS4NClsg
ICAgMC4wMDAwMDBdIEFDUEk6IElSUTIgdXNlZCBieSBvdmVycmlkZS4NClsgICAgMC4wMDAw
MDBdIEFDUEk6IElSUTkgdXNlZCBieSBvdmVycmlkZS4NClsgICAgMC4wMDAwMDBdIFVzaW5n
IEFDUEkgKE1BRFQpIGZvciBTTVAgY29uZmlndXJhdGlvbiBpbmZvcm1hdGlvbg0KWyAgICAw
LjAwMDAwMF0gQUNQSTogSFBFVCBpZDogMHg4MDg2YTcwMSBiYXNlOiAweGZlZDAwMDAwDQpb
ICAgIDAuMDAwMDAwXSBzbXBib290OiBBbGxvd2luZyA0IENQVXMsIDAgaG90cGx1ZyBDUFVz
DQpbICAgIDAuMDAwMDAwXSBucl9pcnFzX2dzaTogNDANClsgICAgMC4wMDAwMDBdIGU4MjA6
IFttZW0gMHg3ZWYwMDAwMC0weGZlYmZmZmZmXSBhdmFpbGFibGUgZm9yIFBDSSBkZXZpY2Vz
DQpbICAgIDAuMDAwMDAwXSBCb290aW5nIHBhcmF2aXJ0dWFsaXplZCBrZXJuZWwgb24gWGVu
DQpbICAgIDAuMDAwMDAwXSBYZW4gdmVyc2lvbjogNC4yLjAtcmM0LXByZSAocHJlc2VydmUt
QUQpDQpbICAgIDAuMDAwMDAwXSBzZXR1cF9wZXJjcHU6IE5SX0NQVVM6OCBucl9jcHVtYXNr
X2JpdHM6OCBucl9jcHVfaWRzOjQgbnJfbm9kZV9pZHM6MQ0KWyAgICAwLjAwMDAwMF0gUEVS
Q1BVOiBFbWJlZGRlZCAyNyBwYWdlcy9jcHUgQGZmZmY4ODAwM2ZjMDAwMDAgczgwODk2IHI4
MTkyIGQyMTUwNCB1NTI0Mjg4DQpbICAgIDAuMDAwMDAwXSBwY3B1LWFsbG9jOiBzODA4OTYg
cjgxOTIgZDIxNTA0IHU1MjQyODggYWxsb2M9MSoyMDk3MTUyDQpbICAgIDAuMDAwMDAwXSBw
Y3B1LWFsbG9jOiBbMF0gMCAxIDIgMyANClsgICAgMC4wMDAwMDBdIEJ1aWx0IDEgem9uZWxp
c3RzIGluIE5vZGUgb3JkZXIsIG1vYmlsaXR5IGdyb3VwaW5nIG9uLiAgVG90YWwgcGFnZXM6
IDI1NzkyOA0KWyAgICAwLjAwMDAwMF0gUG9saWN5IHpvbmU6IERNQTMyDQpbICAgIDAuMDAw
MDAwXSBLZXJuZWwgY29tbWFuZCBsaW5lOiByb290PS9kZXYvc2RhMSBybyB2ZXJib3NlIG1l
bT0xMDI0TSBjb25zb2xlPWh2YzAgY29uc29sZT10dHkwIG5vbW9kZXNldCB2Z2E9MzAzIGVh
cmx5cHJpbnRrPXhlbiBtYXhfbG9vcD01MCBsb29wX21heF9wYXJ0PTEwIGRlYnVnIGxvZ2xl
dmVsPTEwDQpbICAgIDAuMDAwMDAwXSBQSUQgaGFzaCB0YWJsZSBlbnRyaWVzOiA0MDk2IChv
cmRlcjogMywgMzI3NjggYnl0ZXMpDQpbICAgIDAuMDAwMDAwXSBfX2V4X3RhYmxlIGFscmVh
ZHkgc29ydGVkLCBza2lwcGluZyBzb3J0DQpbICAgIDAuMDAwMDAwXSB4c2F2ZTogZW5hYmxl
ZCB4c3RhdGVfYnYgMHgzLCBjbnR4dCBzaXplIDB4MjQwDQpbICAgIDAuMDAwMDAwXSBzb2Z0
d2FyZSBJTyBUTEIgW21lbSAweDNhNjAwMDAwLTB4M2U1ZmZmZmZdICg2NE1CKSBtYXBwZWQg
YXQgW2ZmZmY4ODAwM2E2MDAwMDAtZmZmZjg4MDAzZTVmZmZmZl0NClsgICAgMC4wMDAwMDBd
IE1lbW9yeTogOTMxMDI0ay8xMDQ4NTc2ayBhdmFpbGFibGUgKDg1MTFrIGtlcm5lbCBjb2Rl
LCA0NTZrIGFic2VudCwgMTE3MDk2ayByZXNlcnZlZCwgNjcwNGsgZGF0YSwgNjcyayBpbml0
KQ0KWyAgICAwLjAwMDAwMF0gU0xVQjogR2Vuc2xhYnM9MTUsIEhXYWxpZ249NjQsIE9yZGVy
PTAtMywgTWluT2JqZWN0cz0wLCBDUFVzPTQsIE5vZGVzPTENClsgICAgMC4wMDAwMDBdIFBy
ZWVtcHRpYmxlIGhpZXJhcmNoaWNhbCBSQ1UgaW1wbGVtZW50YXRpb24uDQpbICAgIDAuMDAw
MDAwXSAJUkNVIGR5bnRpY2staWRsZSBncmFjZS1wZXJpb2QgYWNjZWxlcmF0aW9uIGlzIGVu
YWJsZWQuDQpbICAgIDAuMDAwMDAwXSAJQWRkaXRpb25hbCBwZXItQ1BVIGluZm8gcHJpbnRl
ZCB3aXRoIHN0YWxscy4NClsgICAgMC4wMDAwMDBdIAlSQ1UgcmVzdHJpY3RpbmcgQ1BVcyBm
cm9tIE5SX0NQVVM9OCB0byBucl9jcHVfaWRzPTQuDQpbICAgIDAuMDAwMDAwXSBOUl9JUlFT
OjQzNTIgbnJfaXJxczo3MTIgMTYNClsgICAgMC4wMDAwMDBdIHhlbjogc2NpIG92ZXJyaWRl
OiBnbG9iYWxfaXJxPTkgdHJpZ2dlcj0wIHBvbGFyaXR5PTANClsgICAgMC4wMDAwMDBdIHhl
bjogcmVnaXN0ZXJpbmcgZ3NpIDkgdHJpZ2dlcmluZyAwIHBvbGFyaXR5IDANClsgICAgMC4w
MDAwMDBdIHhlbjogLS0+IHBpcnE9OSAtPiBpcnE9OSAoZ3NpPTkpDQooWEVOKSBbMjAxMi0w
OS0wNCAxNjo0MDo0NV0gSU9BUElDWzBdOiBTZXQgUENJIHJvdXRpbmcgZW50cnkgKDQtOSAt
PiAweDU4IC0+IElSUSA5IE1vZGU6MSBBY3RpdmU6MCkNClsgICAgMC4wMDAwMDBdIHhlbjog
YWNwaSBzY2kgOQ0KWyAgICAwLjAwMDAwMF0geGVuOiAtLT4gcGlycT0xIC0+IGlycT0xIChn
c2k9MSkNClsgICAgMC4wMDAwMDBdIHhlbjogLS0+IHBpcnE9MiAtPiBpcnE9MiAoZ3NpPTIp
DQpbICAgIDAuMDAwMDAwXSB4ZW46IC0tPiBwaXJxPTMgLT4gaXJxPTMgKGdzaT0zKQ0KWyAg
ICAwLjAwMDAwMF0geGVuOiAtLT4gcGlycT00IC0+IGlycT00IChnc2k9NCkNClsgICAgMC4w
MDAwMDBdIHhlbjogLS0+IHBpcnE9NSAtPiBpcnE9NSAoZ3NpPTUpDQpbICAgIDAuMDAwMDAw
XSB4ZW46IC0tPiBwaXJxPTYgLT4gaXJxPTYgKGdzaT02KQ0KWyAgICAwLjAwMDAwMF0geGVu
OiAtLT4gcGlycT03IC0+IGlycT03IChnc2k9NykNClsgICAgMC4wMDAwMDBdIHhlbjogLS0+
IHBpcnE9OCAtPiBpcnE9OCAoZ3NpPTgpDQpbICAgIDAuMDAwMDAwXSB4ZW46IC0tPiBwaXJx
PTEwIC0+IGlycT0xMCAoZ3NpPTEwKQ0KWyAgICAwLjAwMDAwMF0geGVuOiAtLT4gcGlycT0x
MSAtPiBpcnE9MTEgKGdzaT0xMSkNClsgICAgMC4wMDAwMDBdIHhlbjogLS0+IHBpcnE9MTIg
LT4gaXJxPTEyIChnc2k9MTIpDQpbICAgIDAuMDAwMDAwXSB4ZW46IC0tPiBwaXJxPTEzIC0+
IGlycT0xMyAoZ3NpPTEzKQ0KWyAgICAwLjAwMDAwMF0geGVuOiAtLT4gcGlycT0xNCAtPiBp
cnE9MTQgKGdzaT0xNCkNClsgICAgMC4wMDAwMDBdIHhlbjogLS0+IHBpcnE9MTUgLT4gaXJx
PTE1IChnc2k9MTUpDQpbICAgIDAuMDAwMDAwXSBDb25zb2xlOiBjb2xvdXIgZHVtbXkgZGV2
aWNlIDgweDI1DQpbICAgIDAuMDAwMDAwXSBjb25zb2xlIFt0dHkwXSBlbmFibGVkLCBib290
Y29uc29sZSBkaXNhYmxlZA0KWyAgICAwLjAwMDAwMF0gSW5pdGlhbGl6aW5nIGNncm91cCBz
dWJzeXMgY3B1c2V0DQpbICAgIDAuMDAwMDAwXSBJbml0aWFsaXppbmcgY2dyb3VwIHN1YnN5
cyBjcHUNClsgICAgMC4wMDAwMDBdIExpbnV4IHZlcnNpb24gMy42LjAtcmM0LTIwMTIwODMw
KyAocm9vdEB4ZW50ZXN0KSAoZ2NjIHZlcnNpb24gNC40LjUgKERlYmlhbiA0LjQuNS04KSAp
ICM2NiBTTVAgUFJFRU1QVCBNb24gU2VwIDMgMjA6MDU6NTAgQ0VTVCAyMDEyDQpbICAgIDAu
MDAwMDAwXSBDb21tYW5kIGxpbmU6IHJvb3Q9L2Rldi9zZGExIHJvIHZlcmJvc2UgbWVtPTEw
MjRNIGNvbnNvbGU9aHZjMCBjb25zb2xlPXR0eTAgbm9tb2Rlc2V0IHZnYT0zMDMgZWFybHlw
cmludGs9eGVuIG1heF9sb29wPTUwIGxvb3BfbWF4X3BhcnQ9MTAgZGVidWcgbG9nbGV2ZWw9
MTANClsgICAgMC4wMDAwMDBdIEZyZWVpbmcgOWUtMTAwIHBmbiByYW5nZTogOTggcGFnZXMg
ZnJlZWQNClsgICAgMC4wMDAwMDBdIDEtMSBtYXBwaW5nIG9uIDllLT4xMDANClsgICAgMC4w
MDAwMDBdIDEtMSBtYXBwaW5nIG9uIDdlZTcwLT4xMDAwMDANClsgICAgMC4wMDAwMDBdIFJl
bGVhc2VkIDk4IHBhZ2VzIG9mIHVudXNlZCBtZW1vcnkNClsgICAgMC4wMDAwMDBdIFNldCA1
Mjg4ODIgcGFnZShzKSB0byAxLTEgbWFwcGluZw0KWyAgICAwLjAwMDAwMF0gUG9wdWxhdGlu
ZyA0MDAwMC00MDA2MiBwZm4gcmFuZ2U6IDk4IHBhZ2VzIGFkZGVkDQpbICAgIDAuMDAwMDAw
XSBlODIwOiBCSU9TLXByb3ZpZGVkIHBoeXNpY2FsIFJBTSBtYXA6DQpbICAgIDAuMDAwMDAw
XSBYZW46IFttZW0gMHgwMDAwMDAwMDAwMDAwMDAwLTB4MDAwMDAwMDAwMDA5ZGZmZl0gdXNh
YmxlDQpbICAgIDAuMDAwMDAwXSBYZW46IFttZW0gMHgwMDAwMDAwMDAwMDllODAwLTB4MDAw
MDAwMDAwMDBmZmZmZl0gcmVzZXJ2ZWQNClsgICAgMC4wMDAwMDBdIFhlbjogW21lbSAweDAw
MDAwMDAwMDAxMDAwMDAtMHgwMDAwMDAwMDQwMDYxZmZmXSB1c2FibGUNClsgICAgMC4wMDAw
MDBdIFhlbjogW21lbSAweDAwMDAwMDAwNDAwNjIwMDAtMHgwMDAwMDAwMDdlZTZmZmZmXSB1
bnVzYWJsZQ0KWyAgICAwLjAwMDAwMF0gWGVuOiBbbWVtIDB4MDAwMDAwMDA3ZWU3MDAwMC0w
eDAwMDAwMDAwN2VlN2RmZmZdIEFDUEkgZGF0YQ0KWyAgICAwLjAwMDAwMF0gWGVuOiBbbWVt
IDB4MDAwMDAwMDA3ZWU3ZTAwMC0weDAwMDAwMDAwN2VlY2ZmZmZdIEFDUEkgTlZTDQpbICAg
IDAuMDAwMDAwXSBYZW46IFttZW0gMHgwMDAwMDAwMDdlZWQwMDAwLTB4MDAwMDAwMDA3ZWVm
ZmZmZl0gcmVzZXJ2ZWQNClsgICAgMC4wMDAwMDBdIFhlbjogW21lbSAweDAwMDAwMDAwZmVj
MDAwMDAtMHgwMDAwMDAwMGZlYzAwZmZmXSByZXNlcnZlZA0KWyAgICAwLjAwMDAwMF0gWGVu
OiBbbWVtIDB4MDAwMDAwMDBmZWQwMDAwMC0weDAwMDAwMDAwZmVkMDEwZmZdIHJlc2VydmVk
DQpbICAgIDAuMDAwMDAwXSBYZW46IFttZW0gMHgwMDAwMDAwMGZlZDAyMDAwLTB4MDAwMDAw
MDBmZWQxNGJmZl0gcmVzZXJ2ZWQNClsgICAgMC4wMDAwMDBdIFhlbjogW21lbSAweDAwMDAw
MDAwZmVkMjAwMDAtMHgwMDAwMDAwMGZlZDNmZmZmXSByZXNlcnZlZA0KWyAgICAwLjAwMDAw
MF0gWGVuOiBbbWVtIDB4MDAwMDAwMDBmZWUwMDAwMC0weDAwMDAwMDAwZmVlMDBmZmZdIHJl
c2VydmVkDQpbICAgIDAuMDAwMDAwXSBYZW46IFttZW0gMHgwMDAwMDAwMGZmZTAwMDAwLTB4
MDAwMDAwMDBmZmZmZmZmZl0gcmVzZXJ2ZWQNClsgICAgMC4wMDAwMDBdIGU4MjA6IHJlbW92
ZSBbbWVtIDB4NDAwMDAwMDAtMHhmZmZmZmZmZmZmZmZmZmZlXSB1c2FibGUNClsgICAgMC4w
MDAwMDBdIGJvb3Rjb25zb2xlIFt4ZW5ib290MF0gZW5hYmxlZA0KWyAgICAwLjAwMDAwMF0g
TlggKEV4ZWN1dGUgRGlzYWJsZSkgcHJvdGVjdGlvbjogYWN0aXZlDQpbICAgIDAuMDAwMDAw
XSBlODIwOiB1c2VyLWRlZmluZWQgcGh5c2ljYWwgUkFNIG1hcDoNClsgICAgMC4wMDAwMDBd
IHVzZXI6IFttZW0gMHgwMDAwMDAwMDAwMDAwMDAwLTB4MDAwMDAwMDAwMDA5ZGZmZl0gdXNh
YmxlDQpbICAgIDAuMDAwMDAwXSB1c2VyOiBbbWVtIDB4MDAwMDAwMDAwMDA5ZTgwMC0weDAw
MDAwMDAwMDAwZmZmZmZdIHJlc2VydmVkDQpbICAgIDAuMDAwMDAwXSB1c2VyOiBbbWVtIDB4
MDAwMDAwMDAwMDEwMDAwMC0weDAwMDAwMDAwM2ZmZmZmZmZdIHVzYWJsZQ0KWyAgICAwLjAw
MDAwMF0gdXNlcjogW21lbSAweDAwMDAwMDAwNDAwNjIwMDAtMHgwMDAwMDAwMDdlZTZmZmZm
XSB1bnVzYWJsZQ0KWyAgICAwLjAwMDAwMF0gdXNlcjogW21lbSAweDAwMDAwMDAwN2VlNzAw
MDAtMHgwMDAwMDAwMDdlZTdkZmZmXSBBQ1BJIGRhdGENClsgICAgMC4wMDAwMDBdIHVzZXI6
IFttZW0gMHgwMDAwMDAwMDdlZTdlMDAwLTB4MDAwMDAwMDA3ZWVjZmZmZl0gQUNQSSBOVlMN
ClsgICAgMC4wMDAwMDBdIHVzZXI6IFttZW0gMHgwMDAwMDAwMDdlZWQwMDAwLTB4MDAwMDAw
MDA3ZWVmZmZmZl0gcmVzZXJ2ZWQNClsgICAgMC4wMDAwMDBdIHVzZXI6IFttZW0gMHgwMDAw
MDAwMGZlYzAwMDAwLTB4MDAwMDAwMDBmZWMwMGZmZl0gcmVzZXJ2ZWQNClsgICAgMC4wMDAw
MDBdIHVzZXI6IFttZW0gMHgwMDAwMDAwMGZlZDAwMDAwLTB4MDAwMDAwMDBmZWQwMTBmZl0g
cmVzZXJ2ZWQNClsgICAgMC4wMDAwMDBdIHVzZXI6IFttZW0gMHgwMDAwMDAwMGZlZDAyMDAw
LTB4MDAwMDAwMDBmZWQxNGJmZl0gcmVzZXJ2ZWQNClsgICAgMC4wMDAwMDBdIHVzZXI6IFtt
ZW0gMHgwMDAwMDAwMGZlZDIwMDAwLTB4MDAwMDAwMDBmZWQzZmZmZl0gcmVzZXJ2ZWQNClsg
ICAgMC4wMDAwMDBdIHVzZXI6IFttZW0gMHgwMDAwMDAwMGZlZTAwMDAwLTB4MDAwMDAwMDBm
ZWUwMGZmZl0gcmVzZXJ2ZWQNClsgICAgMC4wMDAwMDBdIHVzZXI6IFttZW0gMHgwMDAwMDAw
MGZmZTAwMDAwLTB4MDAwMDAwMDBmZmZmZmZmZl0gcmVzZXJ2ZWQNClsgICAgMC4wMDAwMDBd
IERNSSBwcmVzZW50Lg0KWyAgICAwLjAwMDAwMF0gRE1JOiBTeXN0ZW0gbWFudWZhY3R1cmVy
IFN5c3RlbSBQcm9kdWN0IE5hbWUvUDVRLUVNIERPLCBCSU9TIDEyMDggICAgMDUvMjUvMjAx
MA0KWyAgICAwLjAwMDAwMF0gZTgyMDogdXBkYXRlIFttZW0gMHgwMDAwMDAwMC0weDAwMDBm
ZmZmXSB1c2FibGUgPT0+IHJlc2VydmVkDQpbICAgIDAuMDAwMDAwXSBlODIwOiByZW1vdmUg
W21lbSAweDAwMGEwMDAwLTB4MDAwZmZmZmZdIHVzYWJsZQ0KWyAgICAwLjAwMDAwMF0gTm8g
QUdQIGJyaWRnZSBmb3VuZA0KWyAgICAwLjAwMDAwMF0gZTgyMDogbGFzdF9wZm4gPSAweDQw
MDAwIG1heF9hcmNoX3BmbiA9IDB4NDAwMDAwMDAwDQpbICAgIDAuMDAwMDAwXSBmb3VuZCBT
TVAgTVAtdGFibGUgYXQgW21lbSAweDAwMGZmNzgwLTB4MDAwZmY3OGZdIG1hcHBlZCBhdCBb
ZmZmZjg4MDAwMDBmZjc4MF0NClsgICAgMC4wMDAwMDBdIGluaXRpYWwgbWVtb3J5IG1hcHBl
ZDogW21lbSAweDAwMDAwMDAwLTB4MDMxNGVmZmZdDQpbICAgIDAuMDAwMDAwXSBCYXNlIG1l
bW9yeSB0cmFtcG9saW5lIGF0IFtmZmZmODgwMDAwMDk4MDAwXSA5ODAwMCBzaXplIDI0NTc2
DQpbICAgIDAuMDAwMDAwXSBpbml0X21lbW9yeV9tYXBwaW5nOiBbbWVtIDB4MDAwMDAwMDAt
MHgzZmZmZmZmZl0NClsgICAgMC4wMDAwMDBdICBbbWVtIDB4MDAwMDAwMDAtMHgzZmZmZmZm
Zl0gcGFnZSA0aw0KWyAgICAwLjAwMDAwMF0ga2VybmVsIGRpcmVjdCBtYXBwaW5nIHRhYmxl
cyB1cCB0byAweDNmZmZmZmZmIEAgW21lbSAweDAyYWQ2MDAwLTB4MDJjZDdmZmZdDQpbICAg
IDAuMDAwMDAwXSB4ZW46IHNldHRpbmcgUlcgdGhlIHJhbmdlIDJjYjgwMDAgLSAyY2Q4MDAw
DQpbICAgIDAuMDAwMDAwXSBSQU1ESVNLOiBbbWVtIDB4MDJjZDgwMDAtMHgwMzE0ZWZmZl0N
ClsgICAgMC4wMDAwMDBdIEFDUEk6IFJTRFAgMDAwMDAwMDAwMDBmYjA4MCAwMDAyNCAodjAy
IEFDUElBTSkNClsgICAgMC4wMDAwMDBdIEFDUEk6IFhTRFQgMDAwMDAwMDA3ZWU3MDEwMCAw
MDA1QyAodjAxIEFfTV9JXyBPRU1YU0RUICAwNTAwMTAyNSBNU0ZUIDAwMDAwMDk3KQ0KWyAg
ICAwLjAwMDAwMF0gQUNQSTogRkFDUCAwMDAwMDAwMDdlZTcwMjkwIDAwMEY0ICh2MDMgQV9N
X0lfIE9FTUZBQ1AgIDA1MDAxMDI1IE1TRlQgMDAwMDAwOTcpDQpbICAgIDAuMDAwMDAwXSBB
Q1BJOiBEU0RUIDAwMDAwMDAwN2VlNzA0NDAgMDg0MUYgKHYwMSAgQTEwNjUgQTEwNjUwMDAg
MDAwMDAwMDAgSU5UTCAyMDA2MDExMykNClsgICAgMC4wMDAwMDBdIEFDUEk6IEZBQ1MgMDAw
MDAwMDA3ZWU3ZTAwMCAwMDA0MA0KWyAgICAwLjAwMDAwMF0gQUNQSTogQVBJQyAwMDAwMDAw
MDdlZTcwMzkwIDAwMDZDICh2MDEgQV9NX0lfIE9FTUFQSUMgIDA1MDAxMDI1IE1TRlQgMDAw
MDAwOTcpDQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBNQ0ZHIDAwMDAwMDAwN2VlNzA0MDAgMDAw
M0MgKHYwMSBBX01fSV8gT0VNTUNGRyAgMDUwMDEwMjUgTVNGVCAwMDAwMDA5NykNClsgICAg
MC4wMDAwMDBdIEFDUEk6IE9FTUIgMDAwMDAwMDA3ZWU3ZTA0MCAwMDA4OSAodjAxIEFfTV9J
XyBBTUlfT0VNICAwNTAwMTAyNSBNU0ZUIDAwMDAwMDk3KQ0KWyAgICAwLjAwMDAwMF0gQUNQ
STogSFBFVCAwMDAwMDAwMDdlZTc4ODYwIDAwMDM4ICh2MDEgQV9NX0lfIE9FTUhQRVQgIDA1
MDAxMDI1IE1TRlQgMDAwMDAwOTcpDQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBHU0NJIDAwMDAw
MDAwN2VlN2UwZDAgMDIwMjQgKHYwMSBBX01fSV8gR01DSFNDSSAgMDUwMDEwMjUgTVNGVCAw
MDAwMDA5NykNClsgICAgMC4wMDAwMDBdIEFDUEk6IFNTRFQgMDAwMDAwMDA3ZWU4MGEwMCAw
MEE3QyAodjAxIERwZ1BtbSAgICBDcHVQbSAwMDAwMDAxMiBJTlRMIDIwMDYwMTEzKQ0KWyAg
ICAwLjAwMDAwMF0gQUNQSTogTG9jYWwgQVBJQyBhZGRyZXNzIDB4ZmVlMDAwMDANClsgICAg
MC4wMDAwMDBdIE5vIE5VTUEgY29uZmlndXJhdGlvbiBmb3VuZA0KWyAgICAwLjAwMDAwMF0g
RmFraW5nIGEgbm9kZSBhdCBbbWVtIDB4MDAwMDAwMDAwMDAwMDAwMC0weDAwMDAwMDAwM2Zm
ZmZmZmZdDQpbICAgIDAuMDAwMDAwXSBJbml0bWVtIHNldHVwIG5vZGUgMCBbbWVtIDB4MDAw
MDAwMDAtMHgzZmZmZmZmZl0NClsgICAgMC4wMDAwMDBdICAgTk9ERV9EQVRBIFttZW0gMHgz
ZmZmNTAwMC0weDNmZmZmZmZmXQ0KWyAgICAwLjAwMDAwMF0gWm9uZSByYW5nZXM6DQpbICAg
IDAuMDAwMDAwXSAgIERNQSAgICAgIFttZW0gMHgwMDAxMDAwMC0weDAwZmZmZmZmXQ0KWyAg
ICAwLjAwMDAwMF0gICBETUEzMiAgICBbbWVtIDB4MDEwMDAwMDAtMHhmZmZmZmZmZl0NClsg
ICAgMC4wMDAwMDBdICAgTm9ybWFsICAgZW1wdHkNClsgICAgMC4wMDAwMDBdIE1vdmFibGUg
em9uZSBzdGFydCBmb3IgZWFjaCBub2RlDQpbICAgIDAuMDAwMDAwXSBFYXJseSBtZW1vcnkg
bm9kZSByYW5nZXMNClsgICAgMC4wMDAwMDBdICAgbm9kZSAgIDA6IFttZW0gMHgwMDAxMDAw
MC0weDAwMDlkZmZmXQ0KWyAgICAwLjAwMDAwMF0gICBub2RlICAgMDogW21lbSAweDAwMTAw
MDAwLTB4M2ZmZmZmZmZdDQpbICAgIDAuMDAwMDAwXSBPbiBub2RlIDAgdG90YWxwYWdlczog
MjYyMDMwDQpbICAgIDAuMDAwMDAwXSAgIERNQSB6b25lOiA2NCBwYWdlcyB1c2VkIGZvciBt
ZW1tYXANClsgICAgMC4wMDAwMDBdICAgRE1BIHpvbmU6IDYgcGFnZXMgcmVzZXJ2ZWQNClsg
ICAgMC4wMDAwMDBdICAgRE1BIHpvbmU6IDM5MTIgcGFnZXMsIExJRk8gYmF0Y2g6MA0KWyAg
ICAwLjAwMDAwMF0gICBETUEzMiB6b25lOiA0MDMyIHBhZ2VzIHVzZWQgZm9yIG1lbW1hcA0K
WyAgICAwLjAwMDAwMF0gICBETUEzMiB6b25lOiAyNTQwMTYgcGFnZXMsIExJRk8gYmF0Y2g6
MzENClsgICAgMC4wMDAwMDBdIEFDUEk6IFBNLVRpbWVyIElPIFBvcnQ6IDB4ODA4DQpbICAg
IDAuMDAwMDAwXSBBQ1BJOiBMb2NhbCBBUElDIGFkZHJlc3MgMHhmZWUwMDAwMA0KWyAgICAw
LjAwMDAwMF0gQUNQSTogTEFQSUMgKGFjcGlfaWRbMHgwMV0gbGFwaWNfaWRbMHgwMF0gZW5h
YmxlZCkNClsgICAgMC4wMDAwMDBdIEFDUEk6IExBUElDIChhY3BpX2lkWzB4MDJdIGxhcGlj
X2lkWzB4MDFdIGVuYWJsZWQpDQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBMQVBJQyAoYWNwaV9p
ZFsweDAzXSBsYXBpY19pZFsweDAyXSBlbmFibGVkKQ0KWyAgICAwLjAwMDAwMF0gQUNQSTog
TEFQSUMgKGFjcGlfaWRbMHgwNF0gbGFwaWNfaWRbMHgwM10gZW5hYmxlZCkNClsgICAgMC4w
MDAwMDBdIEFDUEk6IElPQVBJQyAoaWRbMHgwNF0gYWRkcmVzc1sweGZlYzAwMDAwXSBnc2lf
YmFzZVswXSkNClsgICAgMC4wMDAwMDBdIElPQVBJQ1swXTogYXBpY19pZCA0LCB2ZXJzaW9u
IDMyLCBhZGRyZXNzIDB4ZmVjMDAwMDAsIEdTSSAwLTIzDQpbICAgIDAuMDAwMDAwXSBBQ1BJ
OiBJTlRfU1JDX09WUiAoYnVzIDAgYnVzX2lycSAwIGdsb2JhbF9pclsgICAgMS4zMzg2NjFd
IHVoY2lfaGNkIDAwMDA6MDA6MWEuMTogVUhDSSBIb3N0IENvbnRyb2xsZXINClsgICAgMS4z
Mzg4MjhdIHVoY2lfaGNkIDAwMDA6MDA6MWEuMTogbmV3IFVTQiBidXMgcmVnaXN0ZXJlZCwg
YXNzaWduZWQgYnVzIG51bWJlciA0DQpbICAgIDEuMzM4ODM5XSB1aGNpX2hjZCAwMDAwOjAw
OjFhLjE6IGRldGVjdGVkIDIgcG9ydHMNClsgICAgMS4zMzg4NDddIHVoY2lfaGNkIDAwMDA6
MDA6MWEuMTogdWhjaV9jaGVja19hbmRfcmVzZXRfaGM6IGNtZCA9IDB4MDAwMA0KWyAgICAx
LjMzODg0OF0gdWhjaV9oY2QgMDAwMDowMDoxYS4xOiBQZXJmb3JtaW5nIGZ1bGwgcmVzZXQN
ClsgICAgMS4zMzg4NjldIHVoY2lfaGNkIDAwMDA6MDA6MWEuMTogc3VwcG9ydHMgVVNCIHJl
bW90ZSB3YWtldXANClsgICAgMS4zMzg5MDVdIHVoY2lfaGNkIDAwMDA6MDA6MWEuMTogaXJx
IDIxLCBpbyBiYXNlIDB4MDAwMGI4MDANClsgICAgMS4zMzg5NzldIHVzYiB1c2I0OiBkZWZh
dWx0IGxhbmd1YWdlIDB4MDQwOQ0KWyAgICAxLjMzODk5Ml0gdXNiIHVzYjQ6IHVkZXYgMSwg
YnVzbnVtIDQsIG1pbm9yID0gMzg0DQpbICAgIDEuMzM4OTk0XSB1c2IgdXNiNDogTmV3IFVT
QiBkZXZpY2UgZm91bmQsIGlkVmVuZG9yPTFkNmIsIGlkUHJvZHVjdD0wMDAxDQpbICAgIDEu
MzM4OTk2XSB1c2IgdXNiNDogTmV3IFVTQiBkZXZpY2Ugc3RyaW5nczogTWZyPTMsIFByb2R1
Y3Q9MiwgU2VyaWFsTnVtYmVyPTENClsgICAgMS4zMzg5OThdIHVzYiB1c2I0OiBQcm9kdWN0
OiBVSENJIEhvc3QgQ29udHJvbGxlcg0KWyAgICAxLjMzOTAwMF0gdXNiIHVzYjQ6IE1hbnVm
YWN0dXJlcjogTGludXggMy42LjAtcmM0LTIwMTIwODMwKyB1aGNpX2hjZA0KWyAgICAxLjMz
OTAwMV0gdXNiIHVzYjQ6IFNlcmlhbE51bWJlcjogMDAwMDowMDoxYS4xDQpbICAgIDEuMzM5
MjA4XSB1c2IgdXNiNDogdXNiX3Byb2JlX2RldmljZQ0KWyAgICAxLjMzOTIxMV0gdXNiIHVz
YjQ6IGNvbmZpZ3VyYXRpb24gIzEgY2hvc2VuIGZyb20gMSBjaG9pY2UNClsgICAgMS4zMzky
MjZdIHVzYiB1c2I0OiBhZGRpbmcgNC0wOjEuMCAoY29uZmlnICMxLCBpbnRlcmZhY2UgMCkN
ClsgICAgMS4zMzkzNzVdIGh1YiA0LTA6MS4wOiB1c2JfcHJvYmVfaW50ZXJmYWNlDQpbICAg
IDEuMzM5Mzc3XSBodWIgNC0wOjEuMDogdXNiX3Byb2JlX2ludGVyZmFjZSAtIGdvdCBpZA0K
WyAgICAxLjMzOTM3OV0gaHViIDQtMDoxLjA6IFVTQiBodWIgZm91bmQNClsgICAgMS4zMzkz
ODddIGh1YiA0LTA6MS4wOiAyIHBvcnRzIGRldGVjdGVkDQpbICAgIDEuMzM5Mzg4XSBodWIg
NC0wOjEuMDogc3RhbmRhbG9uZSBodWINClsgICAgMS4zMzkzOTBdIGh1YiA0LTA6MS4wOiBu
byBwb3dlciBzd2l0Y2hpbmcgKHVzYiAxLjApDQpbICAgIDEuMzM5MzkxXSBodWIgNC0wOjEu
MDogaW5kaXZpZHVhbCBwb3J0IG92ZXItY3VycmVudCBwcm90ZWN0aW9uDQpbICAgIDEuMzM5
MzkzXSBodWIgNC0wOjEuMDogcG93ZXIgb24gdG8gcG93ZXIgZ29vZCB0aW1lOiAybXMNClsg
ICAgMS4zMzk0MDNdIGh1YiA0LTA6MS4wOiBsb2NhbCBwb3dlciBzb3VyY2UgaXMgZ29vZA0K
WyAgICAxLjMzOTQwNV0gaHViIDQtMDoxLjA6IHRyeWluZyB0byBlbmFibGUgcG9ydCBwb3dl
ciBvbiBub24tc3dpdGNoYWJsZSBodWINClsgICAgMS4zMzk1MDNdIGVoY2lfaGNkIDAwMDA6
MDA6MWEuNzogSFMgY29tcGFuaW9uIGZvciAwMDAwOjAwOjFhLjENClsgICAgMS4zMzk1NDZd
IHhlbjogcmVnaXN0ZXJpbmcgZ3NpIDE4IHRyaWdnZXJpbmcgMCBwb2xhcml0eSAxDQpbICAg
IDEuMzM5NTQ4XSBBbHJlYWR5IHNldHVwIHRoZSBHU0kgOjE4DQpbICAgIDEuMzM5NTYyXSB1
aGNpX2hjZCAwMDAwOjAwOjFhLjI6IHNldHRpbmcgbGF0ZW5jeSB0aW1lciB0byA2NA0KWyAg
ICAxLjMzOTU2N10gdWhjaV9oY2QgMDAwMDowMDoxYS4yOiBVSENJIEhvc3QgQ29udHJvbGxl
cg0KWyAgICAxLjMzOTc3OF0gdWhjaV9oY2QgMDAwMDowMDoxYS4yOiBuZXcgVVNCIGJ1cyBy
ZWdpc3RlcmVkLCBhc3NpZ25lZCBidXMgbnVtYmVyIDUNClsgICAgMS4zMzk3ODldIHVoY2lf
aGNkIDAwMDA6MDA6MWEuMjogZGV0ZWN0ZWQgMiBwb3J0cw0KWyAgICAxLjMzOTc5Nl0gdWhj
aV9oY2QgMDAwMDowMDoxYS4yOiB1aGNpX2NoZWNrX2FuZF9yZXNldF9oYzogY21kID0gMHgw
MDAwDQpbICAgIDEuMzM5Nzk4XSB1aGNpX2hjZCAwMDAwOjAwOjFhLjI6IFBlcmZvcm1pbmcg
ZnVsbCByZXNldA0KWyAgICAxLjMzOTgxOV0gdWhjaV9oY2QgMDAwMDowMDoxYS4yOiBzdXBw
b3J0cyBVU0IgcmVtb3RlIHdha2V1cA0KWyAgICAxLjMzOTgyNl0gdWhjaV9oY2QgMDAwMDow
MDoxYS4yOiBpcnEgMTgsIGlvIGJhc2UgMHgwMDAwYjg4MA0KWyAgICAxLjMzOTkwNF0gdXNi
IHVzYjU6IGRlZmF1bHQgbGFuZ3VhZ2UgMHgwNDA5DQpbICAgIDEuMzM5OTE3XSB1c2IgdXNi
NTogdWRldiAxLCBidXNudW0gNSwgbWlub3IgPSA1MTINClsgICAgMS4zMzk5MjBdIHVzYiB1
c2I1OiBOZXcgVVNCIGRldmljZSBmb3VuZCwgaWRWZW5kb3I9MWQ2YiwgaWRQcm9kdWN0PTAw
MDENClsgICAgMS4zMzk5MjFdIHVzYiB1c2I1OiBOZXcgVVNCIGRldmljZSBzdHJpbmdzOiBN
ZnI9MywgUHJvZHVjdD0yLCBTZXJpYWxOdW1iZXI9MQ0KWyAgICAxLjMzOTkyM10gdXNiIHVz
YjU6IFByb2R1Y3Q6IFVIQ0kgSG9zdCBDb250cm9sbGVyDQpbICAgIDEuMzM5OTI1XSB1c2Ig
dXNiNTogTWFudWZhY3R1cmVyOiBMaW51eCAzLjYuMC1yYzQtMjAxMjA4MzArIHVoY2lfaGNk
DQpbICAgIDEuMzM5OTI3XSB1c2IgdXNiNTogU2VyaWFsTnVtYmVyOiAwMDAwOjAwOjFhLjIN
ClsgICAgMS4zNDAxOTRdIHVzYiB1c2I1OiB1c2JfcHJvYmVfZGV2aWNlDQpbICAgIDEuMzQw
MTk2XSB1c2IgdXNiNTogY29uZmlndXJhdGlvbiAjMSBjaG9zZW4gZnJvbSAxIGNob2ljZQ0K
WyAgICAxLjM0MDIwOF0gdXNiIHVzYjU6IGFkZGluZyA1LTA6MS4wIChjb25maWcgIzEsIGlu
dGVyZmFjZSAwKQ0KWyAgICAxLjM0MDM1MF0gaHViIDUtMDoxLjA6IHVzYl9wcm9iZV9pbnRl
cmZhY2UNClsgICAgMS4zNDAzNTFdIGh1YiA1LTA6MS4wOiB1c2JfcHJvYmVfaW50ZXJmYWNl
IC0gZ290IGlkDQpbICAgIDEuMzQwMzU0XSBodWIgNS0wOjEuMDogVVNCIGh1YiBmb3VuZA0K
WyAgICAxLjM0MDM2MV0gaHViIDUtMDoxLjA6IDIgcG9ydHMgZGV0ZWN0ZWQNClsgICAgMS4z
NDAzNjNdIGh1YiA1LTA6MS4wOiBzdGFuZGFsb25lIGh1Yg0KWyAgICAxLjM0MDM2NV0gaHVi
IDUtMDoxLjA6IG5vIHBvd2VyIHN3aXRjaGluZyAodXNiIDEuMCkNClsgICAgMS4zNDAzNjZd
IGh1YiA1LTA6MS4wOiBpbmRpdmlkdWFsIHBvcnQgb3Zlci1jdXJyZW50IHByb3RlY3Rpb24N
ClsgICAgMS4zNDAzNjhdIGh1YiA1LTA6MS4wOiBwb3dlciBvbiB0byBwb3dlciBnb29kIHRp
bWU6IDJtcw0KWyAgICAxLjM0MDM3OF0gaHViIDUtMDoxLjA6IGxvY2FsIHBvd2VyIHNvdXJj
ZSBpcyBnb29kDQpbICAgIDEuMzQwMzgwXSBodWIgNS0wOjEuMDogdHJ5aW5nIHRvIGVuYWJs
ZSBwb3J0IHBvd2VyIG9uIG5vbi1zd2l0Y2hhYmxlIGh1Yg0KWyAgICAxLjM0MDQ3N10gZWhj
aV9oY2QgMDAwMDowMDoxYS43OiBIUyBjb21wYW5pb24gZm9yIDAwMDA6MDA6MWEuMg0KWyAg
ICAxLjM0MDUyM10geGVuOiByZWdpc3RlcmluZyBnc2kgMjMgdHJpZ2dlcmluZyAwIHBvbGFy
aXR5IDENClsgICAgMS4zNDA1MjVdIEFscmVhZHkgc2V0dXAgdGhlIEdTSSA6MjMNClsgICAg
MS4zNDA1MzhdIHVoY2lfaGNkIDAwMDA6MDA6MWQuMDogc2V0dGluZyBsYXRlbmN5IHRpbWVy
IHRvIDY0DQpbICAgIDEuMzQwNTQyXSB1aGNpX2hjZCAwMDAwOjAwOjFkLjA6IFVIQ0kgSG9z
dCBDb250cm9sbGVyDQpbICAgIDEuMzQwNzA4XSB1aGNpX2hjZCAwMDAwOjAwOjFkLjA6IG5l
dyBVU0IgYnVzIHJlZ2lzdGVyZWQsIGFzc2lnbmVkIGJ1cyBudW1iZXIgNg0KWyAgICAxLjM0
MDcxOV0gdWhjaV9oY2QgMDAwMDowMDoxZC4wOiBkZXRlY3RlZCAyIHBvcnRzDQpbICAgIDEu
MzQwNzI3XSB1aGNpX2hjZCAwMDAwOjAwOjFkLjA6IHVoY2lfY2hlY2tfYW5kX3Jlc2V0X2hj
OiBjbWQgPSAweDAwMDANClsgICAgMS4zNDA3MjhdIHVoY2lfaGNkIDAwMDA6MDA6MWQuMDog
UGVyZm9ybWluZyBmdWxsIHJlc2V0DQpbICAgIDEuMzQwNzQ5XSB1aGNpX2hjZCAwMDAwOjAw
OjFkLjA6IHN1cHBvcnRzIFVTQiByZW1vdGUgd2FrZXVwDQpbICAgIDEuMzQwNzU2XSB1aGNp
X2hjZCAwMDAwOjAwOjFkLjA6IGlycSAyMywgaW8gYmFzZSAweDAwMDBiMDAwDQpbICAgIDEu
MzQwODMyXSB1c2IgdXNiNjogZGVmYXVsdCBsYW5ndWFnZSAweDA0MDkNClsgICAgMS4zNDA4
NDVdIHVzYiB1c2I2OiB1ZGV2IDEsIGJ1c251bSA2LCBtaW5vciA9IDY0MA0KWyAgICAxLjM0
MDg0N10gdXNiIHVzYjY6IE5ldyBVU0IgZGV2aWNlIGZvdW5kLCBpZFZlbmRvcj0xZDZiLCBp
ZFByb2R1Y3Q9MDAwMQ0KWyAgICAxLjM0MDg0OV0gdXNiIHVzYjY6IE5ldyBVU0IgZGV2aWNl
IHN0cmluZ3M6IE1mcj0zLCBQcm9kdWN0PTIsIFNlcmlhbE51bWJlcj0xDQpbICAgIDEuMzQw
ODUxXSB1c2IgdXNiNjogUHJvZHVjdDogVUhDSSBIb3N0IENvbnRyb2xsZXINClsgICAgMS4z
NDA4NTNdIHVzYiB1c2I2OiBNYW51ZmFjdHVyZXI6IExpbnV4IDMuNi4wLXJjNC0yMDEyMDgz
MCsgdWhjaV9oY2QNClsgICAgMS4zNDA4NTRdIHVzYiB1c2I2OiBTZXJpYWxOdW1iZXI6IDAw
MDA6MDA6MWQuMA0KWyAgICAxLjM0MTA2MV0gdXNiIHVzYjY6IHVzYl9wcm9iZV9kZXZpY2UN
ClsgICAgMS4zNDEwNjRdIHVzYiB1c2I2OiBjb25maWd1cmF0aW9uICMxIGNob3NlbiBmcm9t
IDEgY2hvaWNlDQpbICAgIDEuMzQxMDc2XSB1c2IgdXNiNjogYWRkaW5nIDYtMDoxLjAgKGNv
bmZpZyAjMSwgaW50ZXJmYWNlIDApDQpbICAgIDEuMzQxMjIwXSBodWIgNi0wOjEuMDogdXNi
X3Byb2JlX2ludGVyZmFjZQ0KWyAgICAxLjM0MTIyMV0gaHViIDYtMDoxLjA6IHVzYl9wcm9i
ZV9pbnRlcmZhY2UgLSBnb3QgaWQNClsgICAgMS4zNDEyMjRdIGh1YiA2LTA6MS4wOiBVU0Ig
aHViIGZvdW5kDQpbICAgIDEuMzQxMjMyXSBodWIgNi0wOjEuMDogMiBwb3J0cyBkZXRlY3Rl
ZA0KWyAgICAxLjM0MTIzM10gaHViIDYtMDoxLjA6IHN0YW5kYWxvbmUgaHViDQpbICAgIDEu
MzQxMjM1XSBodWIgNi0wOjEuMDogbm8gcG93ZXIgc3dpdGNoaW5nICh1c2IgMS4wKQ0KWyAg
ICAxLjM0MTIzNl0gaHViIDYtMDoxLjA6IGluZGl2aWR1YWwgcG9ydCBvdmVyLWN1cnJlbnQg
cHJvdGVjdGlvbg0KWyAgICAxLjM0MTIzOF0gaHViIDYtMDoxLjA6IHBvd2VyIG9uIHRvIHBv
d2VyIGdvb2QgdGltZTogMm1zDQpbICAgIDEuMzQxMjQ4XSBodWIgNi0wOjEuMDogbG9jYWwg
cG93ZXIgc291cmNlIGlzIGdvb2QNClsgICAgMS4zNDEyNTBdIGh1YiA2LTA6MS4wOiB0cnlp
bmcgdG8gZW5hYmxlIHBvcnQgcG93ZXIgb24gbm9uLXN3aXRjaGFibGUgaHViDQpbICAgIDEu
MzQxMzU5XSBlaGNpX2hjZCAwMDAwOjAwOjFkLjc6IEhTIGNvbXBhbmlvbiBmb3IgMDAwMDow
MDoxZC4wDQpbICAgIDEuMzQxMzkxXSB4ZW46IHJlZ2lzdGVyaW5nIGdzaSAxOSB0cmlnZ2Vy
aW5nIDAgcG9sYXJpdHkgMQ0KWyAgICAxLjM0MTM5M10gQWxyZWFkeSBzZXR1cCB0aGUgR1NJ
IDoxOQ0KWyAgICAxLjM0MTQwNl0gdWhjaV9oY2QgMDAwMDowMDoxZC4xOiBzZXR0aW5nIGxh
dGVuY3kgdGltZXIgdG8gNjQNClsgICAgMS4zNDE0MTBdIHVoY2lfaGNkIDAwMDA6MDA6MWQu
MTogVUhDSSBIb3N0IENvbnRyb2xsZXINClsgICAgMS4zNDE1OTVdIHVoY2lfaGNkIDAwMDA6
MDA6MWQuMTogbmV3IFVTQiBidXMgcmVnaXN0ZXJlZCwgYXNzaWduZWQgYnVzIG51bWJlciA3
DQpbICAgIDEuMzQxNjA1XSB1aGNpX2hjZCAwMDAwOjAwOjFkLjE6IGRldGVjdGVkIDIgcG9y
dHMNClsgICAgMS4zNDE2MTNdIHVoY2lfaGNkIDAwMDA6MDA6MWQuMTogdWhjaV9jaGVja19h
bmRfcmVzZXRfaGM6IGNtZCA9IDB4MDAwMA0KWyAgICAxLjM0MTYxNF0gdWhjaV9oY2QgMDAw
MDowMDoxZC4xOiBQZXJmb3JtaW5nIGZ1bGwgcmVzZXQNClsgICAgMS4zNDE2MzVdIHVoY2lf
aGNkIDAwMDA6MDA6MWQuMTogc3VwcG9ydHMgVVNCIHJlbW90ZSB3YWtldXANClsgICAgMS4z
NDE2NzNdIHVoY2lfaGNkIDAwMDA6MDA6MWQuMTogaXJxIDE5LCBpbyBiYXNlIDB4MDAwMGIw
ODANClsgICAgMS4zNDE3NTBdIHVzYiB1c2I3OiBkZWZhdWx0IGxhbmd1YWdlIDB4MDQwOQ0K
WyAgICAxLjM0MTc2NF0gdXNiIHVzYjc6IHVkZXYgMSwgYnVzbnVtIDcsIG1pbm9yID0gNzY4
DQpbICAgIDEuMzQxNzY2XSB1c2IgdXNiNzogTmV3IFVTQiBkZXZpY2UgZm91bmQsIGlkVmVu
ZG9yPTFkNmIsIGlkUHJvZHVjdD0wMDAxDQpbICAgIDEuMzQxNzY3XSB1c2IgdXNiNzogTmV3
IFVTQiBkZXZpY2Ugc3RyaW5nczogTWZyPTMsIFByb2R1Y3Q9MiwgU2VyaWFsTnVtYmVyPTEN
ClsgICAgMS4zNDE3NjldIHVzYiB1c2I3OiBQcm9kdWN0OiBVSENJIEhvc3QgQ29udHJvbGxl
cg0KWyAgICAxLjM0MTc3MV0gdXNiIHVzYjc6IE1hbnVmYWN0dXJlcjogTGludXggMy42LjAt
cmM0LTIwMTIwODMwKyB1aGNpX2hjZA0KWyAgICAxLjM0MTc3M10gdXNiIHVzYjc6IFNlcmlh
bE51bWJlcjogMDAwMDowMDoxZC4xDQpbICAgIDEuMzQxOTc5XSB1c2IgdXNiNzogdXNiX3By
b2JlX2RldmljZQ0KWyAgICAxLjM0MTk4Ml0gdXNiIHVzYjc6IGNvbmZpZ3VyYXRpb24gIzEg
Y2hvc2VuIGZyb20gMSBjaG9pY2UNClsgICAgMS4zNDE5OTRdIHVzYiB1c2I3OiBhZGRpbmcg
Ny0wOjEuMCAoY29uZmlnICMxLCBpbnRlcmZhY2UgMCkNClsgICAgMS4zNDIxMzVdIGh1YiA3
LTA6MS4wOiB1c2JfcHJvYmVfaW50ZXJmYWNlDQpbICAgIDEuMzQyMTM2XSBodWIgNy0wOjEu
MDogdXNiX3Byb2JlX2ludGVyZmFjZSAtIGdvdCBpZA0KWyAgICAxLjM0MjEzOV0gaHViIDct
MDoxLjA6IFVTQiBodWIgZm91bmQNClsgICAgMS4zNDIxNDZdIGh1YiA3LTA6MS4wOiAyIHBv
cnRzIGRldGVjdGVkDQpbICAgIDEuMzQyMTQ4XSBodWIgNy0wOjEuMDogc3RhbmRhbG9uZSBo
dWINClsgICAgMS4zNDIxNDldIGh1YiA3LTA6MS4wOiBubyBwb3dlciBzd2l0Y2hpbmcgKHVz
YiAxLjApDQpbICAgIDEuMzQyMTUxXSBodWIgNy0wOjEuMDogaW5kaXZpZHVhbCBwb3J0IG92
ZXItY3VycmVudCBwcm90ZWN0aW9uDQpbICAgIDEuMzQyMTUzXSBodWIgNy0wOjEuMDogcG93
ZXIgb24gdG8gcG93ZXIgZ29vZCB0aW1lOiAybXMNClsgICAgMS4zNDIxNjNdIGh1YiA3LTA6
MS4wOiBsb2NhbCBwb3dlciBzb3VyY2UgaXMgZ29vZA0KWyAgICAxLjM0MjE2NV0gaHViIDct
MDoxLjA6IHRyeWluZyB0byBlbmFibGUgcG9ydCBwb3dlciBvbiBub24tc3dpdGNoYWJsZSBo
dWINClsgICAgMS4zNDIyNzRdIGVoY2lfaGNkIDAwMDA6MDA6MWQuNzogSFMgY29tcGFuaW9u
IGZvciAwMDAwOjAwOjFkLjENClsgICAgMS4zNDIzMDZdIHhlbjogcmVnaXN0ZXJpbmcgZ3Np
IDE4IHRyaWdnZXJpbmcgMCBwb2xhcml0eSAxDQpbICAgIDEuMzQyMzA4XSBBbHJlYWR5IHNl
dHVwIHRoZSBHU0kgOjE4DQpbICAgIDEuMzQyMzI1XSB1aGNpX2hjZCAwMDAwOjAwOjFkLjI6
IHNldHRpbmcgbGF0ZW5jeSB0aW1lciB0byA2NA0KWyAgICAxLjM0MjMzMF0gdWhjaV9oY2Qg
MDAwMDowMDoxZC4yOiBVSENJIEhvc3QgQ29udHJvbGxlcg0KWyAgICAxLjM0MjQ5Nl0gdWhj
aV9oY2QgMDAwMDowMDoxZC4yOiBuZXcgVVNCIGJ1cyByZWdpc3RlcmVkLCBhc3NpZ25lZCBi
dXMgbnVtYmVyIDgNClsgICAgMS4zNDI1MDddIHVoY2lfaGNkIDAwMDA6MDA6MWQuMjogZGV0
ZWN0ZWQgMiBwb3J0cw0KWyAgICAxLjM0MjUxNF0gdWhjaV9oY2QgMDAwMDowMDoxZC4yOiB1
aGNpX2NoZWNrX2FuZF9yZXNldF9oYzogY21kID0gMHgwMDAwDQpbICAgIDEuMzQyNTE2XSB1
aGNpX2hjZCAwMDAwOjAwOjFkLjI6IFBlcmZvcm1pbmcgZnVsbCByZXNldA0KWyAgICAxLjM0
MjUzNl0gdWhjaV9oY2QgMDAwMDowMDoxZC4yOiBzdXBwb3J0cyBVU0IgcmVtb3RlIHdha2V1
cA0KWyAgICAxLjM0MjU0NF0gdWhjaV9oY2QgMDAwMDowMDoxZC4yOiBpcnEgMTgsIGlvIGJh
c2UgMHgwMDAwYjQwMA0KWyAgICAxLjM0MjYxOV0gdXNiIHVzYjg6IGRlZmF1bHQgbGFuZ3Vh
Z2UgMHgwNDA5DQpbICAgIDEuMzQyNjMyXSB1c2IgdXNiODogdWRldiAxLCBidXNudW0gOCwg
bWlub3IgPSA4OTYNClsgICAgMS4zNDI2MzRdIHVzYiB1c2I4OiBOZXcgVVNCIGRldmljZSBm
b3VuZCwgaWRWZW5kb3I9MWQ2YiwgaWRQcm9kdWN0PTAwMDENClsgICAgMS4zNDI2MzZdIHVz
YiB1c2I4OiBOZXcgVVNCIGRldmljZSBzdHJpbmdzOiBNZnI9MywgUHJvZHVjdD0yLCBTZXJp
YWxOdW1iZXI9MQ0KWyAgICAxLjM0MjYzOF0gdXNiIHVzYjg6IFByb2R1Y3Q6IFVIQ0kgSG9z
dCBDb250cm9sbGVyDQpbICAgIDEuMzQyNjQwXSB1c2IgdXNiODogTWFudWZhY3R1cmVyOiBM
aW51eCAzLjYuMC1yYzQtMjAxMjA4MzArIHVoY2lfaGNkDQpbICAgIDEuMzQyNjQxXSB1c2Ig
dXNiODogU2VyaWFsTnVtYmVyOiAwMDAwOjAwOjFkLjINClsgICAgMS4zNDI4NDhdIHVzYiB1
c2I4OiB1c2JfcHJvYmVfZGV2aWNlDQpbICAgIDEuMzQyODUwXSB1c2IgdXNiODogY29uZmln
dXJhdGlvbiAjMSBjaG9zZW4gZnJvbSAxIGNob2ljZQ0KWyAgICAxLjM0Mjg2Ml0gdXNiIHVz
Yjg6IGFkZGluZyA4LTA6MS4wIChjb25maWcgIzEsIGludGVyZmFjZSAwKQ0KWyAgICAxLjM0
MzAwOF0gaHViIDgtMDoxLjA6IHVzYl9wcm9iZV9pbnRlcmZhY2UNClsgICAgMS4zNDMwMTBd
IGh1YiA4LTA6MS4wOiB1c2JfcHJvYmVfaW50ZXJmYWNlIC0gZ290IGlkDQpbICAgIDEuMzQz
MDEyXSBodWIgOC0wOjEuMDogVVNCIGh1YiBmb3VuZA0KWyAgICAxLjM0MzAyMF0gaHViIDgt
MDoxLjA6IDIgcG9ydHMgZGV0ZWN0ZWQNClsgICAgMS4zNDMwMjJdIGh1YiA4LTA6MS4wOiBz
dGFuZGFsb25lIGh1Yg0KWyAgICAxLjM0MzAyM10gaHViIDgtMDoxLjA6IG5vIHBvd2VyIHN3
aXRjaGluZyAodXNiIDEuMCkNClsgICAgMS4zNDMwMjRdIGh1YiA4LTA6MS4wOiBpbmRpdmlk
dWFsIHBvcnQgb3Zlci1jdXJyZW50IHByb3RlY3Rpb24NClsgICAgMS4zNDMwMjZdIGh1YiA4
LTA6MS4wOiBwb3dlciBvbiB0byBwb3dlciBnb29kIHRpbWU6IDJtcw0KWyAgICAxLjM0MzAz
Nl0gaHViIDgtMDoxLjA6IGxvY2FsIHBvd2VyIHNvdXJjZSBpcyBnb29kDQpbICAgIDEuMzQz
MDM4XSBodWIgOC0wOjEuMDogdHJ5aW5nIHRvIGVuYWJsZSBwb3J0IHBvd2VyIG9uIG5vbi1z
d2l0Y2hhYmxlIGh1Yg0KWyAgICAxLjM0MzE0Nl0gZWhjaV9oY2QgMDAwMDowMDoxZC43OiBI
UyBjb21wYW5pb24gZm9yIDAwMDA6MDA6MWQuMg0KWyAgICAxLjM0MzQ1M10gdXNiY29yZTog
cmVnaXN0ZXJlZCBuZXcgaW50ZXJmYWNlIGRyaXZlciB1c2JscA0KWyAgICAxLjM0MzQ1NF0g
SW5pdGlhbGl6aW5nIFVTQiBNYXNzIFN0b3JhZ2UgZHJpdmVyLi4uDQpbICAgIDEuMzQzNjA0
XSB1c2Jjb3JlOiByZWdpc3RlcmVkIG5ldyBpbnRlcmZhY2UgZHJpdmVyIHVzYi1zdG9yYWdl
DQpbICAgIDEuMzQzNjA1XSBVU0IgTWFzcyBTdG9yYWdlIHN1cHBvcnQgcmVnaXN0ZXJlZC4N
ClsgICAgMS4zNDM4NTZdIHVzYmNvcmU6IHJlZ2lzdGVyZWQgbmV3IGludGVyZmFjZSBkcml2
ZXIgbGlidXN1YWwNClsgICAgMS4zNDQxMTFdIHVzYmNvcmU6IHJlZ2lzdGVyZWQgbmV3IGlu
dGVyZmFjZSBkcml2ZXIgdXNic2VyaWFsDQpbICAgIDEuMzQ0MTEzXSB1c2JzZXJpYWw6IFVT
QiBTZXJpYWwgRHJpdmVyIGNvcmUNClsgICAgMS4zNDQyMzRdIHVzYmNvcmU6IHJlZ2lzdGVy
ZWQgbmV3IGludGVyZmFjZSBkcml2ZXIgY3AyMTB4DQpbICAgIDEuMzQ0NDIzXSBVU0IgU2Vy
aWFsIHN1cHBvcnQgcmVnaXN0ZXJlZCBmb3IgY3AyMTB4DQpbICAgIDEuMzQ0NTc4XSB1c2Jj
b3JlOiByZWdpc3RlcmVkIG5ldyBpbnRlcmZhY2UgZHJpdmVyIGN5cHJlc3NfbTgNClsgICAg
MS4zNDQ2OTldIFVTQiBTZXJpYWwgc3VwcG9ydCByZWdpc3RlcmVkIGZvciBEZUxvcm1lIEVh
cnRobWF0ZSBVU0INClsgICAgMS4zNDQ4MTBdIFVTQiBTZXJpYWwgc3VwcG9ydCByZWdpc3Rl
cmVkIGZvciBISUQtPkNPTSBSUzIzMiBBZGFwdGVyDQpbICAgIDEuMzQ0OTIwXSBVU0IgU2Vy
aWFsIHN1cHBvcnQgcmVnaXN0ZXJlZCBmb3IgTm9raWEgQ0EtNDIgVjIgQWRhcHRlcg0KWyAg
ICAxLjM0NTA0Nl0gdXNiY29yZTogcmVnaXN0ZXJlZCBuZXcgaW50ZXJmYWNlIGRyaXZlciBt
b3M3NzIwDQpbICAgIDEuMzQ1MTU4XSBVU0IgU2VyaWFsIHN1cHBvcnQgcmVnaXN0ZXJlZCBm
b3IgTW9zY2hpcCAyIHBvcnQgYWRhcHRlcg0KWyAgICAxLjM0NTI4NV0gdXNiY29yZTogcmVn
aXN0ZXJlZCBuZXcgaW50ZXJmYWNlIGRyaXZlciBtb3M3ODQwDQpbICAgIDEuMzQ1Mzk1XSBV
U0IgU2VyaWFsIHN1cHBvcnQgcmVnaXN0ZXJlZCBmb3IgTW9zY2hpcCA3ODQwLzc4MjAgVVNC
IFNlcmlhbCBEcml2ZXINClsgICAgMS4zNDU2ODBdIGk4MDQyOiBQTlA6IFBTLzIgQ29udHJv
bGxlciBbUE5QMDMwMzpQUzJLLFBOUDBmMDM6UFMyTV0gYXQgMHg2MCwweDY0IGlycSAxLDEy
DQpbICAgIDEuMzQ4NjM2XSBzZXJpbzogaTgwNDIgS0JEIHBvcnQgYXQgMHg2MCwweDY0IGly
cSAxDQpbICAgIDEuMzQ4NjYyXSBzZXJpbzogaTgwNDIgQVVYIHBvcnQgYXQgMHg2MCwweDY0
IGlycSAxMg0KWyAgICAxLjM0OTE0OV0gbW91c2VkZXY6IFBTLzIgbW91c2UgZGV2aWNlIGNv
bW1vbiBmb3IgYWxsIG1pY2UNClsgICAgMS4zNTAwNDhdIHJ0Y19jbW9zIDAwOjAzOiBSVEMg
Y2FuIHdha2UgZnJvbSBTNA0KWyAgICAxLjM1MDU4NF0gcnRjX2Ntb3MgMDA6MDM6IHJ0YyBj
b3JlOiByZWdpc3RlcmVkIHJ0Y19jbW9zIGFzIHJ0YzANClsgICAgMS4zNTA2NTJdIHJ0YzA6
IGFsYXJtcyB1cCB0byBvbmUgbW9udGgsIHkzaywgMTE0IGJ5dGVzIG52cmFtDQpbICAgIDEu
MzUwODM3XSB4ZW46IHJlZ2lzdGVyaW5nIGdzaSAxOCB0cmlnZ2VyaW5nIDAgcG9sYXJpdHkg
MQ0KWyAgICAxLjM1MDg0MV0gQWxyZWFkeSBzZXR1cCB0aGUgR1NJIDoxOA0KWyAgICAxLjM1
MDg1Ml0gQUNQSSBXYXJuaW5nOiAweDAwMDAwMDAwMDAwMDA0MDAtMHgwMDAwMDAwMDAwMDAw
NDFmIFN5c3RlbUlPIGNvbmZsaWN0cyB3aXRoIFJlZ2lvbiBcU01SRyAxICgyMDEyMDcxMS91
dGFkZHJlc3MtMjUxKQ0KWyAgICAxLjM1MDg1NV0gQUNQSTogSWYgYW4gQUNQSSBkcml2ZXIg
aXMgYXZhaWxhYmxlIGZvciB0aGlzIGRldmljZSwgeW91IHNob3VsZCB1c2UgaXQgaW5zdGVh
ZCBvZiB0aGUgbmF0aXZlIGRyaXZlcg0KWyAgICAxLjM1MTIzMF0gbGlyY19kZXY6IElSIFJl
bW90ZSBDb250cm9sIGRyaXZlciByZWdpc3RlcmVkLCBtYWpvciAyNTAgDQpbICAgIDEuMzUx
MjUwXSBJUiBORUMgcHJvdG9jb2wgaGFuZGxlciBpbml0aWFsaXplZA0KWyAgICAxLjM1MTI1
Ml0gSVIgUkM1KHgpIHByb3RvY29sIGhhbmRsZXIgaW5pdGlhbGl6ZWQNClsgICAgMS4zNTEy
NTNdIElSIFJDNiBwcm90b2NvbCBoYW5kbGVyIGluaXRpYWxpemVkDQpbICAgIDEuMzUxMjU0
XSBJUiBKVkMgcHJvdG9jb2wgaGFuZGxlciBpbml0aWFsaXplZA0KWyAgICAxLjM1MTI1NV0g
SVIgU29ueSBwcm90b2NvbCBoYW5kbGVyIGluaXRpYWxpemVkDQpbICAgIDEuMzUxMjU3XSBJ
UiBSQzUgKHN0cmVhbXphcCkgcHJvdG9jb2wgaGFuZGxlciBpbml0aWFsaXplZA0KWyAgICAx
LjM1MTI1OF0gSVIgU0FOWU8gcHJvdG9jb2wgaGFuZGxlciBpbml0aWFsaXplZA0KWyAgICAx
LjM1MTI1OV0gSVIgTUNFIEtleWJvYXJkL21vdXNlIHByb3RvY29sIGhhbmRsZXIgaW5pdGlh
bGl6ZWQNClsgICAgMS4zNTEyNjBdIElSIExJUkMgYnJpZGdlIGhhbmRsZXIgaW5pdGlhbGl6
ZWQNClsgICAgMS4zNTI4MDZdIGN4ODgvMDogY3gyMzg4eCB2NGwyIGRyaXZlciB2ZXJzaW9u
IDAuMC45IGxvYWRlZA0KWyAgICAxLjM1MzA3Nl0gdXNiY29yZTogcmVnaXN0ZXJlZCBuZXcg
aW50ZXJmYWNlIGRyaXZlciBlbTI4eHgNClsgICAgMS4zNTMxOThdIHVzYmNvcmU6IHJlZ2lz
dGVyZWQgbmV3IGludGVyZmFjZSBkcml2ZXIgY3gyMzF4eA0KWyAgICAxLjM1MzIwMF0gY3gy
NTgyMTogZHJpdmVyIHZlcnNpb24gMC4wLjEwNiBsb2FkZWQNClsgICAgMS4zNTM1NDZdIHVz
YmNvcmU6IHJlZ2lzdGVyZWQgbmV3IGludGVyZmFjZSBkcml2ZXIgcHZydXNiMg0KWyAgICAx
LjM1MzU0N10gcHZydXNiMjogVjRMIGluLXRyZWUgdmVyc2lvbjpIYXVwcGF1Z2UgV2luVFYt
UFZSLVVTQjIgTVBFRzIgRW5jb2Rlci9UdW5lcg0KWyAgICAxLjM1MzU0OV0gcHZydXNiMjog
RGVidWcgbWFzayBpcyAzMSAoMHgxZikNClsgICAgMS4zNTM2ODZdIHVzYmNvcmU6IHJlZ2lz
dGVyZWQgbmV3IGludGVyZmFjZSBkcml2ZXIgUGhpbGlwcyB3ZWJjYW0NClsgICAgMS4zNTM2
ODddIGl2dHY6IFN0YXJ0IGluaXRpYWxpemF0aW9uLCB2ZXJzaW9uIDEuNC4zDQpbICAgIDEu
MzUzODI3XSBpdnR2OiBFbmQgaW5pdGlhbGl6YXRpb24NClsgICAgMS4zNTM4MjldIGl2dHZm
YjogIG5vIGNhcmRzIGZvdW5kDQpbICAgIDEuMzU0MDk3XSB2aXZpLTAwMDogVjRMMiBkZXZp
Y2UgcmVnaXN0ZXJlZCBhcyB2aWRlbzANClsgICAgMS4zNTQwOTldIFZpZGVvIFRlY2hub2xv
Z3kgTWFnYXppbmUgVmlydHVhbCBWaWRlbyBDYXB0dXJlIEJvYXJkIHZlciAwLjguMSBzdWNj
ZXNzZnVsbHkgbG9hZGVkLg0KWyAgICAxLjM1NDEwMF0gY3gyMzg4NSBkcml2ZXIgdmVyc2lv
biAwLjAuMyBsb2FkZWQNClsgICAgMS4zNTQzNzZdIHVzYmNvcmU6IHJlZ2lzdGVyZWQgbmV3
IGludGVyZmFjZSBkcml2ZXIgdXZjdmlkZW8NClsgICAgMS4zNTQzNzddIFVTQiBWaWRlbyBD
bGFzcyBkcml2ZXIgKDEuMS4xKQ0KWyAgICAxLjM1NTE3MF0gc3A1MTAwX3RjbzogU1A1MTAw
IFRDTyBXYXRjaERvZyBUaW1lciBEcml2ZXIgdjAuMDENClsgICAgMS4zNTU0NDZdIHhlbl93
ZHQ6IFhlbiBXYXRjaERvZyBUaW1lciBEcml2ZXIgdjAuMDENClsgICAgMS4zNTU4ODhdIHhl
bl93ZHQ6IGluaXRpYWxpemVkICh0aW1lb3V0PTYwcywgbm93YXlvdXQ9MCkNClsgICAgMS4z
NTY1MjBdIGRldmljZS1tYXBwZXI6IGlvY3RsOiA0LjIzLjAtaW9jdGwgKDIwMTItMDctMjUp
IGluaXRpYWxpc2VkOiBkbS1kZXZlbEByZWRoYXQuY29tDQpbICAgIDEuMzYwMzgxXSB1c2Jj
b3JlOiByZWdpc3RlcmVkIG5ldyBpbnRlcmZhY2UgZHJpdmVyIHVzYmhpZA0KWyAgICAxLjM2
MDM4Ml0gdXNiaGlkOiBVU0IgSElEIGNvcmUgZHJpdmVyDQpbICAgIDEuMzY1MzE1XSB4ZW46
IHJlZ2lzdGVyaW5nIGdzaSAyMiB0cmlnZ2VyaW5nIDAgcG9sYXJpdHkgMQ0KWyAgICAxLjM2
NTMyMF0gQWxyZWFkeSBzZXR1cCB0aGUgR1NJIDoyMg0KWyAgICAxLjM3MzUyNV0gaW5wdXQ6
IEFUIFRyYW5zbGF0ZWQgU2V0IDIga2V5Ym9hcmQgYXMgL2RldmljZXMvcGxhdGZvcm0vaTgw
NDIvc2VyaW8wL2lucHV0L2lucHV0Mg0KWyAgICAxLjQwNzU3M10geGVuOiByZWdpc3Rlcmlu
ZyBnc2kgMTcgdHJpZ2dlcmluZyAwIHBvbGFyaXR5IDENClsgICAgMS40MDc1NzddIEFscmVh
ZHkgc2V0dXAgdGhlIEdTSSA6MTcNClsgICAgMS40MjIxMTFdIHVzYmNvcmU6IHJlZ2lzdGVy
ZWQgbmV3IGludGVyZmFjZSBkcml2ZXIgc25kLXVzYi1hdWRpbw0KWyAgICAxLjQyMjIzMF0g
dXNiY29yZTogcmVnaXN0ZXJlZCBuZXcgaW50ZXJmYWNlIGRyaXZlciBzbmQtdWExMDENClsg
ICAgMS40MjIzNTBdIHVzYmNvcmU6IHJlZ2lzdGVyZWQgbmV3IGludGVyZmFjZSBkcml2ZXIg
c25kLXVzYi11c3gyeQ0KWyAgICAxLjQyMjQ2OF0gdXNiY29yZTogcmVnaXN0ZXJlZCBuZXcg
aW50ZXJmYWNlIGRyaXZlciBzbmQtdXNiLWNhaWFxDQpbICAgIDEuNDIyNTkwXSB1c2Jjb3Jl
OiByZWdpc3RlcmVkIG5ldyBpbnRlcmZhY2UgZHJpdmVyIHNuZC11c2ItNmZpcmUNClsgICAg
MS40MjI2NDRdIE5ldGZpbHRlciBtZXNzYWdlcyB2aWEgTkVUTElOSyB2MC4zMC4NClsgICAg
MS40MjI2NTJdIG5mbmxfYWNjdDogcmVnaXN0ZXJpbmcgd2l0aCBuZm5ldGxpbmsuDQpbICAg
IDEuNDIyNzE5XSBuZl9jb25udHJhY2sgdmVyc2lvbiAwLjUuMCAoNzMwOSBidWNrZXRzLCAy
OTIzNiBtYXgpDQpbICAgIDEuNDIzMzYzXSBjdG5ldGxpbmsgdjAuOTM6IHJlZ2lzdGVyaW5n
IHdpdGggbmZuZXRsaW5rLg0KWyAgICAxLjQyMzYyNV0gaHViIDEtMDoxLjA6IHN0YXRlIDcg
cG9ydHMgNiBjaGcgMDAwMCBldnQgMDAwMA0KWyAgICAxLjQyNDAwNF0geHRfdGltZToga2Vy
bmVsIHRpbWV6b25lIGlzIC0wMDAwDQpbICAgIDEuNDI0MDI3XSBpcF9zZXQ6IHByb3RvY29s
IDYNClsgICAgMS40MjQwNTddIElQVlM6IFJlZ2lzdGVyZWQgcHJvdG9jb2xzICgpDQpbICAg
IDEuNDI0MjMzXSBJUFZTOiBDb25uZWN0aW9uIGhhc2ggdGFibGUgY29uZmlndXJlZCAoc2l6
ZT00MDk2LCBtZW1vcnk9NjRLYnl0ZXMpDQpbICAgIDEuNDI0MzM4XSBJUFZTOiBDcmVhdGlu
ZyBuZXRucyBzaXplPTE4ODggaWQ9MA0KWyAgICAxLjQyNDM4NF0gSVBWUzogaXB2cyBsb2Fk
ZWQuDQpbICAgIDEuNDI0NjI2XSBpcF90YWJsZXM6IChDKSAyMDAwLTIwMDYgTmV0ZmlsdGVy
IENvcmUgVGVhbQ0KWyAgICAxLjQyNDc0Ml0gVENQOiBjdWJpYyByZWdpc3RlcmVkDQpbICAg
IDEuNDI0NzQ3XSBORVQ6IFJlZ2lzdGVyZWQgcHJvdG9jb2wgZmFtaWx5IDE3DQpbICAgIDEu
NDI0ODEyXSBCcmlkZ2UgZmlyZXdhbGxpbmcgcmVnaXN0ZXJlZA0KWyAgICAxLjQyNDgzNl0g
RWJ0YWJsZXMgdjIuMCByZWdpc3RlcmVkDQpbICAgIDEuNDI2MTI4XSByZWdpc3RlcmVkIHRh
c2tzdGF0cyB2ZXJzaW9uIDENClsgICAgMS40MzY3OThdIGh1YiAyLTA6MS4wOiBzdGF0ZSA3
IHBvcnRzIDYgY2hnIDAwMDAgZXZ0IDAwMDANClsgICAgMS40MzY4MDNdIGh1YiAzLTA6MS4w
OiBzdGF0ZSA3IHBvcnRzIDIgY2hnIDAwMDAgZXZ0IDAwMDANClsgICAgMS40MzY4NDFdIGh1
YiA0LTA6MS4wOiBzdGF0ZSA3IHBvcnRzIDIgY2hnIDAwMDAgZXZ0IDAwMDANClsgICAgMS40
NDAxMThdIGh1YiA1LTA6MS4wOiBzdGF0ZSA3IHBvcnRzIDIgY2hnIDAwMDAgZXZ0IDAwMDAN
ClsgICAgMS40NDAxMjZdIGh1YiA2LTA6MS4wOiBzdGF0ZSA3IHBvcnRzIDIgY2hnIDAwMDAg
ZXZ0IDAwMDANClsgICAgMS40NDAxNjhdIGh1YiA3LTA6MS4wOiBzdGF0ZSA3IHBvcnRzIDIg
Y2hnIDAwMDAgZXZ0IDAwMDANClsgICAgMS40NDAxNzNdIGh1YiA4LTA6MS4wOiBzdGF0ZSA3
IHBvcnRzIDIgY2hnIDAwMDAgZXZ0IDAwMDANClsgICAgMS41MzYzMjldIHBzbW91c2Ugc2Vy
aW8xOiBsb2dpcHMycHA6IERldGVjdGVkIHVua25vd24gTG9naXRlY2ggbW91c2UgbW9kZWwg
NTcNClsgICAgMi4wMDAyMTBdIGlucHV0OiBJbUV4UFMvMiBMb2dpdGVjaCBFeHBsb3JlciBN
b3VzZSBhcyAvZGV2aWNlcy9wbGF0Zm9ybS9pODA0Mi9zZXJpbzEvaW5wdXQvaW5wdXQzDQpb
ICAgIDIuMzQ2NzQzXSB1c2IgdXNiMzogc3VzcGVuZF9yaCAoYXV0by1zdG9wKQ0KWyAgICAy
LjM0Njc3N10gdXNiIHVzYjQ6IHN1c3BlbmRfcmggKGF1dG8tc3RvcCkNClsgICAgMi4zNDY4
MDldIHVzYiB1c2I1OiBzdXNwZW5kX3JoIChhdXRvLXN0b3ApDQpbICAgIDIuMzQ2ODM5XSB1
c2IgdXNiNjogc3VzcGVuZF9yaCAoYXV0by1zdG9wKQ0KWyAgICAyLjM0Njg3MF0gdXNiIHVz
Yjc6IHN1c3BlbmRfcmggKGF1dG8tc3RvcCkNClsgICAgMi4zNDY5MDFdIHVzYiB1c2I4OiBz
dXNwZW5kX3JoIChhdXRvLXN0b3ApDQpbICAgIDQuMTQ4OTU4XSBjb25zb2xlIFtuZXRjb24w
XSBlbmFibGVkDQpbICAgIDQuMTQ4OTYxXSBhdGExLjAwOiAxNTYzMDE0ODggc2VjdG9ycywg
bXVsdGkgMDogTEJbICAgIDYuMzk1NzY0XSBFWFQzLWZzIChzZGExKTogcmVjb3ZlcnkgcmVx
dWlyZWQgb24gcmVhZG9ubHkgZmlsZXN5c3RlbQ0KWyAgICA2LjQwMzc1OV0gRVhUMy1mcyAo
c2RhMSk6IHdyaXRlIGFjY2VzcyB3aWxsIGJlIGVuYWJsZWQgZHVyaW5nIHJlY292ZXJ5DQpb
ICAgIDYuODczMTI2XSBram91cm5hbGQgc3RhcnRpbmcuICBDb21taXQgaW50ZXJ2YWwgNSBz
ZWNvbmRzDQpbICAgIDYuODgxNDY1XSBFWFQzLWZzIChzZGExKTogcmVjb3ZlcnkgY29tcGxl
dGUNClsgICAgNi44ODE0NjddIEVYVDMtZnMgKHNkYTEpOiBtb3VudGVkIGZpbGVzeXN0ZW0g
d2l0aCB3cml0ZWJhY2sgZGF0YSBtb2RlDQpbICAgIDguNTQyNTI5XSB1ZGV2WzE4MTFdOiBz
dGFydGluZyB2ZXJzaW9uIDE2NA0KWyAgIDEwLjg4MTU2MV0gQWRkaW5nIDMyMjkwMjhrIHN3
YXAgb24gL2Rldi9zZGE1LiAgUHJpb3JpdHk6LTEgZXh0ZW50czoxIGFjcm9zczozMjI5MDI4
ayANClsgICAxMS4xODQxMTFdIEVYVDMtZnMgKHNkYTEpOiB1c2luZyBpbnRlcm5hbCBqb3Vy
bmFsDQpbICAgMTUuODgxMTQ5XSBlMTAwMGU6IGV0aDEgTklDIExpbmsgaXMgVXAgMTAwIE1i
cHMgRnVsbCBEdXBsZXgsIEZsb3cgQ29udHJvbDogUngvVHgNClsgICAxNS44OTEwODFdIGUx
MDAwZSAwMDAwOjAwOjE5LjA6IGV0aDE6IDEwLzEwMCBzcGVlZDogZGlzYWJsaW5nIFRTTw0K
WyAgIDE2LjIzMzg1MV0gc3NoZCAoMjU3OCk6IC9wcm9jLzI1Nzgvb29tX2FkaiBpcyBkZXBy
ZWNhdGVkLCBwbGVhc2UgdXNlIC9wcm9jLzI1Nzgvb29tX3Njb3JlX2FkaiBpbnN0ZWFkLg0K
WyAgIDk5LjAyNzgzNl0gPDQ+SU49IE9VVD1ldGgxIFNSQz0xNzIuMTYuMS4yNTEgRFNUPTE3
Mi4xNi4xLjEgTEVOPTg0IFRPUz0weDAwIFBSRUM9MHgwMCBUVEw9NjQgSUQ9MCBERiBQUk9U
Tz1JQ01QIFRZUEU9OCBDT0RFPTAgSUQ9MzE5NSBTRVE9MSANClsgIDE1MC40OTE2NzRdIDw0
PklOPWV0aDEgT1VUPSBNQUM9ZmY6ZmY6ZmY6ZmY6ZmY6ZmY6MDA6MWI6YTk6MjU6ZGY6NGM6
MDg6MDAgU1JDPTE3Mi4xNi4xLjEyIERTVD0yNTUuMjU1LjI1NS4yNTUgTEVOPTIyOSBUT1M9
MHgwMCBQUkVDPTB4MDAgVFRMPTY0IElEPTYyMjcwIFBST1RPPVVEUCBTUFQ9MTM4IERQVD0x
MzggTEVOPTIwOSANClsgIDQ5MS45OTQ3MTldIDw0PklOPSBPVVQ9ZXRoMSBTUkM9MTcyLjE2
LjEuMjUxIERTVD0xNzIuMTYuMS4xIExFTj04NCBUT1M9MHgwMCBQUkVDPTB4MDAgVFRMPTY0
IElEPTAgREYgUFJPVE89SUNNUCBUWVBFPTggQ09ERT0wIElEPTMyNDcgU0VRPTEgDQpbICA1
MDEuNTcyNjU5XSA8ND5JTj1ldGgxIE9VVD0gTUFDPWZmOmZmOmZmOmZmOmZmOmZmOjAwOjI0
OmQ3OjExOmI4OmQwOjA4OjAwIFNSQz0xNzIuMTYuMS4yMCBEU1Q9MjU1LjI1NS4yNTUuMjU1
IExFTj0zMjggVE9TPTB4MDAgUFJFQz0weDAwIFRUTD0xMjggSUQ9MTQ5NzIgUFJPVE89VURQ
IFNQVD02OCBEUFQ9NjcgTEVOPTMwOCANClsgIDUwNC41NzMwNDldIDw0PklOPWV0aDEgT1VU
PSBNQUM9ZmY6ZmY6ZmY6ZmY6ZmY6ZmY6MDA6MjQ6ZDc6MTE6Yjg6ZDA6MDg6MDAgU1JDPTE3
Mi4xNi4xLjIwIERTVD0yNTUuMjU1LjI1NS4yNTUgTEVOPTMyOCBUT1M9MHgwMCBQUkVDPTB4
MDAgVFRMPTEyOCBJRD0xNDk4MCBQUk9UTz1VRFAgU1BUPTY4IERQVD02NyBMRU49MzA4IA0K
WyAgNzU0LjQyNjEwMF0gPDQ+SU49ZXRoMSBPVVQ9IE1BQz0wMDoyMzo1NDo5YTo0NjplYTo0
MDo2MTo4NjpmNDo2NzpkODowODowMCBTUkM9MTcyLjE2LjEuMSBEU1Q9MTcyLjE2LjEuMjUx
IExFTj0zMjggVE9TPTB4MTAgUFJFQz0weDAwIFRUTD0xMjggSUQ9MCBQUk9UTz1VRFAgU1BU
PTY3IERQVD02OCBMRU49MzA4IA0KWyAgODEyLjAwMTg1OF0gPDQ+SU49ZXRoMSBPVVQ9IE1B
Qz1mZjpmZjpmZjpmZjpmZjpmZjowMDoxYjphOToyNTpkZjo0YzowODowMCBTUkM9MTcyLjE2
LjEuMTIgRFNUPTI1NS4yNTUuMjU1LjI1NSBMRU49MjI5IFRPUz0weDAwIFBSRUM9MHgwMCBU
VEw9NjQgSUQ9NjIzMTAgUFJPVE89VURQIFNQVD0xMzggRFBUPTEzOCBMRU49MjA5IA0KWyAg
ODUzLjUyMDg0OV0gZTEwMDBlOiBldGgxIE5JQyBMaW5rIGlzIFVwIDEwMCBNYnBzIEZ1bGwg
RHVwbGV4LCBGbG93IENvbnRyb2w6IFJ4L1R4DQpbICA4NjIuMjcyNDIwXSA8ND5JTj1ldGgx
IE9VVD0gTUFDPWZmOmZmOmZmOmZmOmZmOmZmOjAwOjE2OjM2OmE3OmQwOmYzOjA4OjAwIFNS
Qz0xNzIuMTYuMS4yNDAgRFNUPTE3Mi4xNi4yNTUuMjU1IExFTj0yMDIgVE9TPTB4MDAgUFJF
Qz0weDAwIFRUTD0xMjggSUQ9NTcwMiBQUk9UTz1VRFAgU1BUPTEzOCBEUFQ9MTM4IExFTj0x
ODIgDQpbICA4NjIuMjc1NzA2XSA8ND5JTj1ldGgxIE9VVD0gTUFDPWZmOmZmOmZmOmZmOmZm
OmZmOjAwOjE2OjM2OmE3OmQwOmYzOjA4OjAwIFNSQz0xNzIuMTYuMS4yNDAgRFNUPTE3Mi4x
Ni4yNTUuMjU1IExFTj03OCBUT1M9MHgwMCBQUkVDPTB4MDAgVFRMPTEyOCBJRD01NzA0IFBS
T1RPPVVEUCBTUFQ9MTM3IERQVD0xMzcgTEVOPTU4IA0KWyAgODYzLjA0NTE2N10gPDQ+SU49
ZXRoMSBPVVQ9IE1BQz1mZjpmZjpmZjpmZjpmZjpmZjowMDoxNjozNjphNzpkMDpmMzowODow
MCBTUkM9MTcyLjE2LjEuMjQwIERTVD0xNzIuMTYuMjU1LjI1NSBMRU49NzggVE9TPTB4MDAg
UFJFQz0weDAwIFRUTD0xMjggSUQ9NTcwNSBQUk9UTz1VRFAgU1BUPTEzNyBEUFQ9MTM3IExF
Tj01OCANClsgIDg2My43OTUwNTBdIDw0PklOPWV0aDEgT1VUPSBNQUM9ZmY6ZmY6ZmY6ZmY6
ZmY6ZmY6MDA6MTY6MzY6YTc6ZDA6ZjM6MDg6MDAgU1JDPTE3Mi4xNi4xLjI0MCBEU1Q9MTcy
LjE2LjI1NS4yNTUgTEVOPTc4IFRPUz0weDAwIFBSRUM9MHgwMCBUVEw9MTI4IElEPTU3MDYg
UFJPVE89VURQIFNQVD0xMzcgRFBUPTEzNyBMRU49NTggDQpbICA4NjYuNTQ1MTgwXSA8ND5J
Tj1ldGgxIE9VVD0gTUFDPWZmOmZmOmZmOmZmOmZmOmZmOjAwOjE2OjM2OmE3OmQwOmYzOjA4
OjAwIFNSQz0xNzIuMTYuMS4yNDAgRFNUPTE3Mi4xNi4yNTUuMjU1IExFTj0yMDIgVE9TPTB4
MDAgUFJFQz0weDAwIFRUTD0xMjggSUQ9NTcwNyBQUk9UTz1VRFAgU1BUPTEzOCBEUFQ9MTM4
IExFTj0xODIgDQpbICA4NjYuNTQ4NDgwXSA8ND5JTj1ldGgxIE9VVD0gTUFDPWZmOmZmOmZm
OmZmOmZmOmZmOjAwOjE2OjM2OmE3OmQwOmYzOjA4OjAwIFNSQz0xNzIuMTYuMS4yNDAgRFNU
PTE3Mi4xNi4yNTUuMjU1IExFTj03OCBUT1M9MHgwMCBQUkVDPTB4MDAgVFRMPTEyOCBJRD01
NzA5IFBST1RPPVVEUCBTUFQ9MTM3IERQVD0xMzcgTEVOPTU4IA0KWyAgODY3LjMxODUwMl0g
PDQ+SU49ZXRoMSBPVVQ9IE1BQz1mZjpmZjpmZjpmZjpmZjpmZjowMDoxNjozNjphNzpkMDpm
MzowODowMCBTUkM9MTcyLjE2LjEuMjQwIERTVD0xNzIuMTYuMjU1LjI1NSBMRU49NzggVE9T
PTB4MDAgUFJFQz0weDAwIFRUTD0xMjggSUQ9NTcxMCBQUk9UTz1VRFAgU1BUPTEzNyBEUFQ9
MTM3IExFTj01OCANClsgIDg2OC4wNjg1MDJdIDw0PklOPWV0aDEgT1VUPSBNQUM9ZmY6ZmY6
ZmY6ZmY6ZmY6ZmY6MDA6MTY6MzY6YTc6ZDA6ZjM6MDg6MDAgU1JDPTE3Mi4xNi4xLjI0MCBE
U1Q9MTcyLjE2LjI1NS4yNTUgTEVOPTc4IFRPUz0weDAwIFBSRUM9MHgwMCBUVEw9MTI4IElE
PTU3MTEgUFJPVE89VURQIFNQVD0xMzcgRFBUPTEzNyBMRU49NTggDQpbICA4NzAuODE4NzA5
XSA8ND5JTj1ldGgxIE9VVD0gTUFDPWZmOmZmOmZmOmZmOmZmOmZmOjAwOjE2OjM2OmE3OmQw
OmYzOjA4OjAwIFNSQz0xNzIuMTYuMS4yNDAgRFNUPTE3Mi4xNi4yNTUuMjU1IExFTj0yMDIg
VE9TPTB4MDAgUFJFQz0weDAwIFRUTD0xMjggSUQ9NTcxMiBQUk9UTz1VRFAgU1BUPTEzOCBE
UFQ9MTM4IExFTj0xODIgDQpbICA4NzAuODQ4OTM5XSA8ND5JTj1ldGgxIE9VVD0gTUFDPWZm
OmZmOmZmOmZmOmZmOmZmOjAwOjE2OjM2OmE3OmQwOmYzOjA4OjAwIFNSQz0xNzIuMTYuMS4y
NDAgRFNUPTE3Mi4xNi4yNTUuMjU1IExFTj03OCBUT1M9MHgwMCBQUkVDPTB4MDAgVFRMPTEy
OCBJRD01NzE0IFBST1RPPVVEUCBTUFQ9MTM3IERQVD0xMzcgTEVOPTU4IA0KWyAgODcxLjU5
MTg5NF0gPDQ+SU49ZXRoMSBPVVQ9IE1BQz1mZjpmZjpmZjpmZjpmZjpmZjowMDoxNjozNjph
NzpkMDpmMzowODowMCBTUkM9MTcyLjE2LjEuMjQwIERTVD0xNzIuMTYuMjU1LjI1NSBMRU49
NzggVE9TPTB4MDAgUFJFQz0weDAwIFRUTD0xMjggSUQ9NTcxNSBQUk9UTz1VRFAgU1BUPTEz
NyBEUFQ9MTM3IExFTj01OCANClsgIDg3Mi4zNDE4NzFdIDw0PklOPWV0aDEgT1VUPSBNQUM9
ZmY6ZmY6ZmY6ZmY6ZmY6ZmY6MDA6MTY6MzY6YTc6ZDA6ZjM6MDg6MDAgU1JDPTE3Mi4xNi4x
LjI0MCBEU1Q9MTcyLjE2LjI1NS4yNTUgTEVOPTc4IFRPUz0weDAwIFBSRUM9MHgwMCBUVEw9
MTI4IElEPTU3MTYgUFJPVE89VURQIFNQVD0xMzcgRFBUPTEzNyBMRU49NTggDQpbICA4NzUu
MTE1MTI1XSA8ND5JTj1ldGgxIE9VVD0gTUFDPWZmOmZmOmZmOmZmOmZmOmZmOjAwOjE2OjM2
OmE3OmQwOmYzOjA4OjAwIFNSQz0xNzIuMTYuMS4yNDAgRFNUPTE3Mi4xNi4yNTUuMjU1IExF
Tj03OCBUT1M9MHgwMCBQUkVDPTB4MDAgVFRMPTEyOCBJRD01NzE4IFBST1RPPVVEUCBTUFQ9
MTM3IERQVD0xMzcgTEVOPTU4IA0KWyAgODc1Ljg2NTM4Nl0gPDQ+SU49ZXRoMSBPVVQ9IE1B
Qz1mZjpmZjpmZjpmZjpmZjpmZjowMDoxNjozNjphNzpkMDpmMzowODowMCBTUkM9MTcyLjE2
LjEuMjQwIERTVD0xNzIuMTYuMjU1LjI1NSBMRU49NzggVE9TPTB4MDAgUFJFQz0weDAwIFRU
TD0xMjggSUQ9NTcxOSBQUk9UTz1VRFAgU1BUPTEzNyBEUFQ9MTM3IExFTj01OCANClsgIDg3
Ni42MTUyMzRdIDw0PklOPWV0aDEgT1VUPSBNQUM9ZmY6ZmY6ZmY6ZmY6ZmY6ZmY6MDA6MTY6
MzY6YTc6ZDA6ZjM6MDg6MDAgU1JDPTE3Mi4xNi4xLjI0MCBEU1Q9MTcyLjE2LjI1NS4yNTUg
TEVOPTc4IFRPUz0weDAwIFBSRUM9MHgwMCBUVEw9MTI4IElEPTU3MjAgUFJPVE89VURQIFNQ
VD0xMzcgRFBUPTEzNyBMRU49NTggDQpbICA4OTcuMTYxMTE5XSBkZXZpY2UgdmlmMS4wIGVu
dGVyZWQgcHJvbWlzY3VvdXMgbW9kZQ0KbWFwcGluZyBrZXJuZWwgaW50byBwaHlzaWNhbCBt
ZW1vcnkNCmFib3V0IHRvIGdldCBzdGFydGVkLi4uDQpbICA4OTcuNjk2NjE5XSB4ZW5fYnJp
ZGdlOiBwb3J0IDEodmlmMS4wKSBlbnRlcmVkIGZvcndhcmRpbmcgc3RhdGUNClsgIDg5Ny43
MTYyMTldIHhlbl9icmlkZ2U6IHBvcnQgMSh2aWYxLjApIGVudGVyZWQgZm9yd2FyZGluZyBz
dGF0ZQ0KWyAgODk4LjEyOTQ2NV0gLS0tLS0tLS0tLS0tWyBjdXQgaGVyZSBdLS0tLS0tLS0t
LS0tDQpbICA4OTguMTMyMjA5XSBrZXJuZWwgQlVHIGF0IGRyaXZlcnMveGVuL2JhbGxvb24u
YzozNTkhDQpbICA4OTguMTMyMjA5XSBpbnZhbGlkIG9wY29kZTogMDAwMCBbIzFdIFBSRUVN
UFQgU01QIA0KWyAgODk4LjEzMjIwOV0gTW9kdWxlcyBsaW5rZWQgaW46DQpbICA4OTguMTMy
MjA5XSBDUFUgMCANClsgIDg5OC4xMzIyMDldIFBpZDogMzMzOCwgY29tbToga3dvcmtlci8w
OjEgTm90IHRhaW50ZWQgMy42LjAtcmM0LTIwMTIwODMwKyAjNjYgU3lzdGVtIG1hbnVmYWN0
dXJlciBTeXN0ZW0gUHJvZHVjdCBOYW1lL1A1US1FTSBETw0KWyAgODk4LjEzMjIwOV0gUklQ
OiBlMDMwOls8ZmZmZmZmZmY4MTMzYjIwNj5dICBbPGZmZmZmZmZmODEzM2IyMDY+XSBiYWxs
b29uX3Byb2Nlc3MrMHgzMzYvMHgzNDANClsgIDg5OC4xMzIyMDldIFJTUDogZTAyYjpmZmZm
ODgwMDM3YjRkY2UwICBFRkxBR1M6IDAwMDEwMjEzDQpbICA4OTguMTMyMjA5XSBSQVg6IDAw
MDAwMDAwMjQyYjAwMDAgUkJYOiBmZmZmZWEwMDAwZGZhZGMwIFJDWDogMDAwMDAwMDAwMDAw
MDAwMA0KWyAgODk4LjEzMjIwOV0gUkRYOiAwMDAwMDAwMDAwMDM3ZWI3IFJTSTogMDAwMDAw
MDBkZWFkYmVlZiBSREk6IDAwMDAwMDAwMDAwMDAwYjcNClsgIDg5OC4xMzIyMDldIFJCUDog
ZmZmZjg4MDAzN2I0ZGQ0MCBSMDg6IGZmZmZlYTAwMDBkZmFkZTAgUjA5OiAyMjIyMjIyMjIy
MjIyMjIyDQpbICA4OTguMTMyMjA5XSBSMTA6IDIyMjIyMjIyMjIyMjIyMjIgUjExOiAyMjIy
MjIyMjIyMjIyMjIyIFIxMjogMDAwMDAwMDAwMDAwMDAwMA0KWyAgODk4LjEzMjIwOV0gUjEz
OiBmZmZmZWEwMDAwZGZhZGUwIFIxNDogMDAwMDE2MDAwMDAwMDAwMCBSMTU6IDAwMDAwMDAw
MDAwMDAwMDENClsgIDg5OC4xMzIyMDldIEZTOiAgMDAwMDdmZDRiZDBlYzc0MCgwMDAwKSBH
UzpmZmZmODgwMDNmYzAwMDAwKDAwMDApIGtubEdTOjAwMDAwMDAwMDAwMDAwMDANClsgIDg5
OC4xMzIyMDldIENTOiAgZTAzMyBEUzogMDAwMCBFUzogMDAwMCBDUjA6IDAwMDAwMDAwODAw
NTAwM2INClsgIDg5OC4xMzIyMDldIENSMjogMDAwMDdmZDRiMzg3ZDAwMCBDUjM6IDAwMDAw
MDAwMzkyMGEwMDAgQ1I0OiAwMDAwMDAwMDAwMDQyNjYwDQpbICA4OTguMTMyMjA5XSBEUjA6
IDAwMDAwMDAwMDAwMDAwMDAgRFIxOiAwMDAwMDAwMDAwMDAwMDAwIERSMjogMDAwMDAwMDAw
MDAwMDAwMA0KWyAgODk4LjEzMjIwOV0gRFIzOiAwMDAwMDAwMDAwMDAwMDAwIERSNjogMDAw
MDAwMDBmZmZmMGZmMCBEUjc6IDAwMDAwMDAwMDAwMDA0MDANClsgIDg5OC4xMzIyMDldIFBy
b2Nlc3Mga3dvcmtlci8wOjEgKHBpZDogMzMzOCwgdGhyZWFkaW5mbyBmZmZmODgwMDM3YjRj
MDAwLCB0YXNrIGZmZmY4ODAwMzk4ZmUxODApDQpbICA4OTguMTMyMjA5XSBTdGFjazoNClsg
IDg5OC4xMzIyMDldICAwMDAwMDAwMDAwMDM3ZWI3IDAwMDAwMDAwMDAwMDAwMDEgZmZmZmZm
ZmY4Mjg2YzU0MCAwMDAwMDAwMDAwMDAwMDAxDQpbICA4OTguMTMyMjA5XSAgMDAwMDAwMDAw
MDAwMDAwMCAwMDAwMDAwMDAwMDA3ZmYwIGZmZmY4ODAwMzdiNGRkMjAgZmZmZmZmZmY4MWU0
MmE2MA0KWyAgODk4LjEzMjIwOV0gIGZmZmY4ODAwMzc5OWM2YzAgZmZmZjg4MDAzZmMxNjcw
MCBmZmZmODgwMDNmYzBlMDAwIGZmZmY4ODAwMzdiNGRkOTANClsgIDg5OC4xMzIyMDldIENh
bGwgVHJhY2U6DQpbICA4OTguMTMyMjA5XSAgWzxmZmZmZmZmZjgxMDdmYjhmPl0gcHJvY2Vz
c19vbmVfd29yaysweDFiZi8weDRhMA0KWyAgODk4LjEzMjIwOV0gIFs8ZmZmZmZmZmY4MTA3
ZmIzMD5dID8gcHJvY2Vzc19vbmVfd29yaysweDE2MC8weDRhMA0KWyAgODk4LjEzMjIwOV0g
IFs8ZmZmZmZmZmY4MTg0OTE5MT5dID8gX19zY2hlZHVsZSsweDQ3MS8weDhhMA0KWyAgODk4
LjEzMjIwOV0gIFs8ZmZmZmZmZmY4MTMzYWVkMD5dID8gZGVjcmVhc2VfcmVzZXJ2YXRpb24r
MHgyZDAvMHgyZDANClsgIDg5OC4xMzIyMDldICBbPGZmZmZmZmZmODEwODAyNTI+XSB3b3Jr
ZXJfdGhyZWFkKzB4MTUyLzB4NDcwDQpbICA4OTguMTMyMjA5XSAgWzxmZmZmZmZmZjgxODRh
ZDg1Pl0gPyBfcmF3X3NwaW5fdW5sb2NrX2lycXJlc3RvcmUrMHg3NS8weGEwDQpbICA4OTgu
MTMyMjA5XSAgWzxmZmZmZmZmZjgxMGFlNGRkPl0gPyB0cmFjZV9oYXJkaXJxc19vbisweGQv
MHgxMA0KWyAgODk4LjEzMjIwOV0gIFs8ZmZmZmZmZmY4MTg0YWQ2Mz5dID8gX3Jhd19zcGlu
X3VubG9ja19pcnFyZXN0b3JlKzB4NTMvMHhhMA0KWyAgODk4LjEzMjIwOV0gIFs8ZmZmZmZm
ZmY4MTA4MDEwMD5dID8gbWFuYWdlX3dvcmtlcnMrMHgyOTAvMHgyOTANClsgIDg5OC4xMzIy
MDldICBbPGZmZmZmZmZmODEwODc2OTY+XSBrdGhyZWFkKzB4OTYvMHhhMA0KWyAgODk4LjEz
MjIwOV0gIFs8ZmZmZmZmZmY4MTg0Y2I4ND5dIGtlcm5lbF90aHJlYWRfaGVscGVyKzB4NC8w
eDEwDQpbICA4OTguMTMyMjA5XSAgWzxmZmZmZmZmZjgxODRiMTM0Pl0gPyByZXRpbnRfcmVz
dG9yZV9hcmdzKzB4MTMvMHgxMw0KWyAgODk4LjEzMjIwOV0gIFs8ZmZmZmZmZmY4MTg0Y2I4
MD5dID8gZ3NfY2hhbmdlKzB4MTMvMHgxMw0KWyAgODk4LjEzMjIwOV0gQ29kZTogZmYgMGYg
MWYgNDAgMDAgNDggODkgZDggZTkgMjIgZmUgZmYgZmYgMGYgMGIgZWIgZmUgNDggODkgZDcg
NDggODkgNTUgYTAgZTggMTggZTcgY2MgZmYgNDggODMgZjggZmYgNDggOGIgNTUgYTAgMGYg
ODQgNzQgZmUgZmYgZmYgPDBmPiAwYiBlYiBmZSA2NiAwZiAxZiA0NCAwMCAwMCA1NSA0OCA4
OSBlNSA0MSA1NyA0MSA1NiA0MSA4OSBkNiANClsgIDg5OC4xMzIyMDldIFJJUCAgWzxmZmZm
ZmZmZjgxMzNiMjA2Pl0gYmFsbG9vbl9wcm9jZXNzKzB4MzM2LzB4MzQwDQpbICA4OTguMTMy
MjA5XSAgUlNQIDxmZmZmODgwMDM3YjRkY2UwPg0KWyAgODk4LjczODIzM10gLS0tWyBlbmQg
dHJhY2UgM2Y3YWY1MDI4NWVkYjdiYiBdLS0tDQpbICA4OTguNzQ5MDAzXSBCVUc6IHVuYWJs
ZSB0byBoYW5kbGUga2VybmVsIHBhZ2luZyByZXF1ZXN0IGF0IGZmZmZmZmZmZmZmZmZmZjgN
ClsgIDg5OC43NTIyMzddIElQOiBbPGZmZmZmZmZmODEwODZlZWI+XSBrdGhyZWFkX2RhdGEr
MHhiLzB4MjANClsgIDg5OC43NTIyMzddIFBHRCAxZTBkMDY3IFBVRCAxZTBlMDY3IFBNRCAw
IA0KWyAgODk4Ljc1MjIzN10gT29wczogMDAwMCBbIzJdIFBSRUVNUFQgU01QIA0KWyAgODk4
Ljc1MjIzN10gTW9kdWxlcyBsaW5rZWQgaW46DQpbICA4OTguNzUyMjM3XSBDUFUgMCANClsg
IDg5OC43NTIyMzddIFBpZDogMzMzOCwgY29tbToga3dvcmtlci8wOjEgVGFpbnRlZDogRyAg
ICAgIEQgICAgICAzLjYuMC1yYzQtMjAxMjA4MzArICM2NiBTeXN0ZW0gbWFudWZhY3R1cmVy
IFN5c3RlbSBQcm9kdWN0IE5hbWUvUDVRLUVNIERPDQpbICA4OTguNzUyMjM3XSBSSVA6IGUw
MzA6WzxmZmZmZmZmZjgxMDg2ZWViPl0gIFs8ZmZmZmZmZmY4MTA4NmVlYj5dIGt0aHJlYWRf
ZGF0YSsweGIvMHgyMA0KWyAgODk4Ljc1MjIzN10gUlNQOiBlMDJiOmZmZmY4ODAwMzdiNGQ4
OTggIEVGTEFHUzogMDAwMTAwODINClsgIDg5OC43NTIyMzddIFJBWDogMDAwMDAwMDAwMDAw
MDAwMCBSQlg6IGZmZmY4ODAwM2ZjMTJlODAgUkNYOiAwMDAwMDAwMDAwMDAwMDAwDQpbICA4
OTguNzUyMjM3XSBSRFg6IGZmZmZmZmZmODIwMDU3YTAgUlNJOiAwMDAwMDAwMDAwMDAwMDAw
IFJESTogZmZmZjg4MDAzOThmZTE4MA0KWyAgODk4Ljc1MjIzN10gUkJQOiBmZmZmODgwMDM3
YjRkODk4IFIwODogZmZmZjg4MDAzOThmZTFmMCBSMDk6IDAwMDAwMDAwMDAwMDA0MDANClsg
IDg5OC43NTIyMzddIFIxMDogMDAwMDAwMDAwMDAwMDAwMCBSMTE6IDAwMDAwMDAwMDAwMDAw
MDEgUjEyOiAwMDAwMDAwMDAwMDAwMDAwDQpbICA4OTguNzUyMjM3XSBSMTM6IDAwMDAwMDAw
MDAwMDAwMDAgUjE0OiBmZmZmODgwMDM3YjRkN2I4IFIxNTogZmZmZjg4MDAzN2I0ZGE5MA0K
WyAgODk4Ljc1MjIzN10gRlM6ICAwMDAwN2ZkNGJkMGVjNzQwKDAwMDApIEdTOmZmZmY4ODAw
M2ZjMDAwMDAoMDAwMCkga25sR1M6MDAwMDAwMDAwMDAwMDAwMA0KWyAgODk4Ljc1MjIzN10g
Q1M6ICBlMDMzIERTOiAwMDAwIEVTOiAwMDAwIENSMDogMDAwMDAwMDA4MDA1MDAzYg0KWyAg
ODk4Ljc1MjIzN10gQ1IyOiBmZmZmZmZmZmZmZmZmZmY4IENSMzogMDAwMDAwMDAzOTIwYTAw
MCBDUjQ6IDAwMDAwMDAwMDAwNDI2NjANClsgIDg5OC43NTIyMzddIERSMDogMDAwMDAwMDAw
MDAwMDAwMCBEUjE6IDAwMDAwMDAwMDAwMDAwMDAgRFIyOiAwMDAwMDAwMDAwMDAwMDAwDQpb
ICA4OTguNzUyMjM3XSBEUjM6IDAwMDAwMDAwMDAwMDAwMDAgRFI2OiAwMDAwMDAwMGZmZmYw
ZmYwIERSNzogMDAwMDAwMDAwMDAwMDQwMA0KWyAgODk4Ljc1MjIzN10gUHJvY2VzcyBrd29y
a2VyLzA6MSAocGlkOiAzMzM4LCB0aHJlYWRpbmZvIGZmZmY4ODAwMzdiNGMwMDAsIHRhc2sg
ZmZmZjg4MDAzOThmZTE4MCkNClsgIDg5OC43NTIyMzddIFN0YWNrOg0KWyAgODk4Ljc1MjIz
N10gIGZmZmY4ODAwMzdiNGQ4YzggZmZmZmZmZmY4MTA4MzA2YyAwMDAwMDAwMDAwMDAwMDAw
IGZmZmY4ODAwM2ZjMTJlODANClsgIDg5OC43NTIyMzddICAwMDAwMDAwMDAwMDAwMDAwIGZm
ZmY4ODAwMzk4ZmU1MjggZmZmZjg4MDAzN2I0ZGExOCBmZmZmZmZmZjgxODQ5MzFmDQpbICA4
OTguNzUyMjM3XSAgMDAwMDAwMDAwMDAwMDAwMCBmZmZmZmZmZjgxMDgzYmI4IGZmZmY4ODAw
Mzk4ZmUxODAgMDAwMDAwMDAwMDAxMmU4MA0KWyAgODk4Ljc1MjIzN10gQ2FsbCBUcmFjZToN
ClsgIDg5OC43NTIyMzddICBbPGZmZmZmZmZmODEwODMwNmM+XSB3cV93b3JrZXJfc2xlZXBp
bmcrMHgxYy8weDkwDQpbICA4OTguNzUyMjM3XSAgWzxmZmZmZmZmZjgxODQ5MzFmPl0gX19z
Y2hlZHVsZSsweDVmZi8weDhhMA0KWyAgODk4Ljc1MjIzN10gIFs8ZmZmZmZmZmY4MTA4M2Ji
OD5dID8gZnJlZV9waWQrMHgxOC8weGMwDQpbICA4OTguNzUyMjM3XSAgWzxmZmZmZmZmZjgx
MDYwMmE3Pl0gPyBzaGExX3RyYW5zZm9ybV9zc3NlMysweDE4Ny8weGQwMA0KWyAgODk4Ljc1
MjIzN10gIFs8ZmZmZmZmZmY4MTBiMWE5ND5dID8gbG9ja19hY3F1aXJlKzB4ZTQvMHgxMTAN
ClsgIDg5OC43NTIyMzddICBbPGZmZmZmZmZmODEwNmNmYTc+XSA/IGRvX2V4aXQrMHg0ZTcv
MHg4ZTANClsgIDg5OC43NTIyMzddICBbPGZmZmZmZmZmODEwZTI3ZjI+XSA/IGNhbGxfcmN1
KzB4MTIvMHgyMA0KWyAgODk4Ljc1MjIzN10gIFs8ZmZmZmZmZmY4MTBiMWYwMT5dID8gbG9j
a19yZWxlYXNlKzB4MTExLzB4MjYwDQpbICA4OTguNzUyMjM3XSAgWzxmZmZmZmZmZjgxODQ5
NjU0Pl0gc2NoZWR1bGUrMHgyNC8weDcwDQpbICA4OTguNzUyMjM3XSAgWzxmZmZmZmZmZjgx
MDZkMDc0Pl0gZG9fZXhpdCsweDViNC8weDhlMA0KWyAgODk4Ljc1MjIzN10gIFs8ZmZmZmZm
ZmY4MTAxMDI0MD5dIG9vcHNfZW5kKzB4YjAvMHhmMA0KWyAgODk4Ljc1MjIzN10gIFs8ZmZm
ZmZmZmY4MTAxMDNiNj5dIGRpZSsweDU2LzB4OTANClsgIDg5OC43NTIyMzddICBbPGZmZmZm
ZmZmODEwMGQ2YzQ+XSBkb190cmFwKzB4YzQvMHgxNzANClsgIDg5OC43NTIyMzddICBbPGZm
ZmZmZmZmODEwMGRiZTI+XSA/IGRvX2ludmFsaWRfb3ArMHg3Mi8weGMwDQpbICA4OTguNzUy
MjM3XSAgWzxmZmZmZmZmZjgxMDBkYzE2Pl0gZG9faW52YWxpZF9vcCsweGE2LzB4YzANClsg
IDg5OC43NTIyMzddICBbPGZmZmZmZmZmODEzM2IyMDY+XSA/IGJhbGxvb25fcHJvY2Vzcysw
eDMzNi8weDM0MA0KWyAgODk4Ljc1MjIzN10gIFs8ZmZmZmZmZmY4MTBhYzllOD5dID8gdHJh
Y2VfaGFyZGlycXNfb2ZmX2NhbGxlcisweDc4LzB4MTUwDQpbICA4OTguNzUyMjM3XSAgWzxm
ZmZmZmZmZjgxMmIyOWZkPl0gPyB0cmFjZV9oYXJkaXJxc19vZmZfdGh1bmsrMHgzYS8weDNj
DQpbICA4OTguNzUyMjM3XSAgWzxmZmZmZmZmZjgxODRiMTY0Pl0gPyByZXN0b3JlX2FyZ3Mr
MHgzMC8weDMwDQpbICA4OTguNzUyMjM3XSAgWzxmZmZmZmZmZjgxODRjOWZiPl0gaW52YWxp
ZF9vcCsweDFiLzB4MjANClsgIDg5OC43NTIyMzddICBbPGZmZmZmZmZmODEzM2IyMDY+XSA/
IGJhbGxvb25fcHJvY2VzcysweDMzNi8weDM0MA0KWyAgODk4Ljc1MjIzN10gIFs8ZmZmZmZm
ZmY4MTA3ZmI4Zj5dIHByb2Nlc3Nfb25lX3dvcmsrMHgxYmYvMHg0YTANClsgIDg5OC43NTIy
MzddICBbPGZmZmZmZmZmODEwN2ZiMzA+XSA/IHByb2Nlc3Nfb25lX3dvcmsrMHgxNjAvMHg0
YTANClsgIDg5OC43NTIyMzddICBbPGZmZmZmZmZmODE4NDkxOTE+XSA/IF9fc2NoZWR1bGUr
MHg0NzEvMHg4YTANClsgIDg5OC43NTIyMzddICBbPGZmZmZmZmZmODEzM2FlZDA+XSA/IGRl
Y3JlYXNlX3Jlc2VydmF0aW9uKzB4MmQwLzB4MmQwDQpbICA4OTguNzUyMjM3XSAgWzxmZmZm
ZmZmZjgxMDgwMjUyPl0gd29ya2VyX3RocmVhZCsweDE1Mi8weDQ3MA0KWyAgODk4Ljc1MjIz
N10gIFs8ZmZmZmZmZmY4MTg0YWQ4NT5dID8gX3Jhd19zcGluX3VubG9ja19pcnFyZXN0b3Jl
KzB4NzUvMHhhMA0KWyAgODk4Ljc1MjIzN10gIFs8ZmZmZmZmZmY4MTBhZTRkZD5dID8gdHJh
Y2VfaGFyZGlycXNfb24rMHhkLzB4MTANClsgIDg5OC43NTIyMzddICBbPGZmZmZmZmZmODE4
NGFkNjM+XSA/IF9yYXdfc3Bpbl91bmxvY2tfaXJxcmVzdG9yZSsweDUzLzB4YTANClsgIDg5
OC43NTIyMzddICBbPGZmZmZmZmZmODEwODAxMDA+XSA/IG1hbmFnZV93b3JrZXJzKzB4Mjkw
LzB4MjkwDQpbICA4OTguNzUyMjM3XSAgWzxmZmZmZmZmZjgxMDg3Njk2Pl0ga3RocmVhZCsw
eDk2LzB4YTANClsgIDg5OC43NTIyMzddICBbPGZmZmZmZmZmODE4NGNiODQ+XSBrZXJuZWxf
dGhyZWFkX2hlbHBlcisweDQvMHgxMA0KWyAgODk4Ljc1MjIzN10gIFs8ZmZmZmZmZmY4MTg0
YjEzND5dID8gcmV0aW50X3Jlc3RvcmVfYXJncysweDEzLzB4MTMNClsgIDg5OC43NTIyMzdd
ICBbPGZmZmZmZmZmODE4NGNiODA+XSA/IGdzX2NoYW5nZSsweDEzLzB4MTMNClsgIDg5OC43
NTIyMzddIENvZGU6IDU1IDY1IDQ4IDhiIDA0IDI1IDgwIGM2IDAwIDAwIDQ4IDhiIDgwIDUw
IDAzIDAwIDAwIDQ4IDg5IGU1IDhiIDQwIGYwIGM5IGMzIDBmIDFmIDgwIDAwIDAwIDAwIDAw
IDQ4IDhiIDg3IDUwIDAzIDAwIDAwIDU1IDQ4IDg5IGU1IDw0OD4gOGIgNDAgZjggYzkgYzMg
NjYgNjYgNjYgNjYgNjYgNjYgMmUgMGYgMWYgODQgMDAgMDAgMDAgMDAgMDAgDQpbICA4OTgu
NzUyMjM3XSBSSVAgIFs8ZmZmZmZmZmY4MTA4NmVlYj5dIGt0aHJlYWRfZGF0YSsweGIvMHgy
MA0KWyAgODk4Ljc1MjIzN10gIFJTUCA8ZmZmZjg4MDAzN2I0ZDg5OD4NClsgIDg5OC43NTIy
MzddIENSMjogZmZmZmZmZmZmZmZmZmZmOA0KWyAgODk4Ljc1MjIzN10gLS0tWyBlbmQgdHJh
Y2UgM2Y3YWY1MDI4NWVkYjdiYyBdLS0tDQpbICA4OTguNzUyMjM3XSBGaXhpbmcgcmVjdXJz
aXZlIGZhdWx0IGJ1dCByZWJvb3QgaXMgbmVlZGVkIQ0KWyAgOTEyLjc0NjYyNV0geGVuX2Jy
aWRnZTogcG9ydCAxKHZpZjEuMCkgZW50ZXJlZCBmb3J3YXJkaW5nIHN0YXRlDQo=
------------0320050151C2718BB
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

------------0320050151C2718BB--



From xen-devel-bounces@lists.xen.org Tue Sep 04 16:38:53 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Sep 2012 16: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 1T8w8y-0005Ct-F8; Tue, 04 Sep 2012 16:38:28 +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 1T8w8w-0005Co-RY
	for xen-devel@lists.xen.org; Tue, 04 Sep 2012 16:38:27 +0000
Received: from [85.158.143.35:50678] by server-2.bemta-4.messagelabs.com id
	DC/B5-21239-28E26405; Tue, 04 Sep 2012 16:38:26 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-6.tower-21.messagelabs.com!1346776701!16623538!1
X-Originating-IP: [188.40.164.121]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1985 invoked from network); 4 Sep 2012 16:38:22 -0000
Received: from static.121.164.40.188.clients.your-server.de (HELO
	smtp.eikelenboom.it) (188.40.164.121)
	by server-6.tower-21.messagelabs.com with AES256-SHA encrypted SMTP;
	4 Sep 2012 16:38:22 -0000
Received: from 128-64-ftth.onsneteindhoven.nl ([88.159.64.128]:55630
	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 1T8w5T-0004hp-8E; Tue, 04 Sep 2012 18:34:51 +0200
Date: Tue, 4 Sep 2012 18:37:57 +0200
From: Sander Eikelenboom <linux@eikelenboom.it>
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <1136369816.20120904183757@eikelenboom.it>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
MIME-Version: 1.0
Content-Type: multipart/mixed;
 boundary="----------0320050151C2718BB"
Cc: xen-devel@lists.xen.org
Subject: [Xen-devel] dom0 linux 3.6.0-rc4,
	crash due to ballooning althoug dom0_mem=X, max:X 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>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

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

Hi Konrad,

This seems to happen only on a intel machine i'm trying to setup as a devel=
opment machine (haven't seen it on my amd).
It boots fine, i have dom0_mem=3D1024M,max:1024M set, the machine has 2G of=
 mem.

Dom0 and guest kernel are 3.6.0-rc4 with config:
[*] Xen memory balloon driver
[*]   Scrub pages before returning them to system

From=20http://wiki.xen.org/wiki/Do%EF%BB%BFm0_Memory_%E2%80%94_Where_It_Has=
_Not_Gone , I thought this should be okay

But when trying to start a PV guest with 512MB mem, the machine (dom0) cras=
hes with the stacktrace below (complete serial-log.txt attached).

From=20the:
"mapping kernel into physical memory
about to get started..."

I would almost say it's trying to reload dom0 ?


[  897.161119] device vif1.0 entered promiscuous mode
mapping kernel into physical memory
about to get started...
[  897.696619] xen_bridge: port 1(vif1.0) entered forwarding state
[  897.716219] xen_bridge: port 1(vif1.0) entered forwarding state
[  898.129465] ------------[ cut here ]------------
[  898.132209] kernel BUG at drivers/xen/balloon.c:359!
[  898.132209] invalid opcode: 0000 [#1] PREEMPT SMP=20
[  898.132209] Modules linked in:
[  898.132209] CPU 0=20
[  898.132209] Pid: 3338, comm: kworker/0:1 Not tainted 3.6.0-rc4-20120830+=
 #66 System manufacturer System Product Name/P5Q-EM DO
[  898.132209] RIP: e030:[<ffffffff8133b206>]  [<ffffffff8133b206>] balloon=
_process+0x336/0x340
[  898.132209] RSP: e02b:ffff880037b4dce0  EFLAGS: 00010213
[  898.132209] RAX: 00000000242b0000 RBX: ffffea0000dfadc0 RCX: 00000000000=
00000
[  898.132209] RDX: 0000000000037eb7 RSI: 00000000deadbeef RDI: 00000000000=
000b7
[  898.132209] RBP: ffff880037b4dd40 R08: ffffea0000dfade0 R09: 22222222222=
22222
[  898.132209] R10: 2222222222222222 R11: 2222222222222222 R12: 00000000000=
00000
[  898.132209] R13: ffffea0000dfade0 R14: 0000160000000000 R15: 00000000000=
00001
[  898.132209] FS:  00007fd4bd0ec740(0000) GS:ffff88003fc00000(0000) knlGS:=
0000000000000000
[  898.132209] CS:  e033 DS: 0000 ES: 0000 CR0: 000000008005003b
[  898.132209] CR2: 00007fd4b387d000 CR3: 000000003920a000 CR4: 00000000000=
42660
[  898.132209] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 00000000000=
00000
[  898.132209] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 00000000000=
00400
[  898.132209] Process kworker/0:1 (pid: 3338, threadinfo ffff880037b4c000,=
 task ffff8800398fe180)
[  898.132209] Stack:
[  898.132209]  0000000000037eb7 0000000000000001 ffffffff8286c540 00000000=
00000001
[  898.132209]  0000000000000000 0000000000007ff0 ffff880037b4dd20 ffffffff=
81e42a60
[  898.132209]  ffff88003799c6c0 ffff88003fc16700 ffff88003fc0e000 ffff8800=
37b4dd90
[  898.132209] Call Trace:
[  898.132209]  [<ffffffff8107fb8f>] process_one_work+0x1bf/0x4a0
[  898.132209]  [<ffffffff8107fb30>] ? process_one_work+0x160/0x4a0
[  898.132209]  [<ffffffff81849191>] ? __schedule+0x471/0x8a0
[  898.132209]  [<ffffffff8133aed0>] ? decrease_reservation+0x2d0/0x2d0
[  898.132209]  [<ffffffff81080252>] worker_thread+0x152/0x470
[  898.132209]  [<ffffffff8184ad85>] ? _raw_spin_unlock_irqrestore+0x75/0xa0
[  898.132209]  [<ffffffff810ae4dd>] ? trace_hardirqs_on+0xd/0x10
[  898.132209]  [<ffffffff8184ad63>] ? _raw_spin_unlock_irqrestore+0x53/0xa0
[  898.132209]  [<ffffffff81080100>] ? manage_workers+0x290/0x290
[  898.132209]  [<ffffffff81087696>] kthread+0x96/0xa0
[  898.132209]  [<ffffffff8184cb84>] kernel_thread_helper+0x4/0x10
[  898.132209]  [<ffffffff8184b134>] ? retint_restore_args+0x13/0x13
[  898.132209]  [<ffffffff8184cb80>] ? gs_change+0x13/0x13
[  898.132209] Code: ff 0f 1f 40 00 48 89 d8 e9 22 fe ff ff 0f 0b eb fe 48 =
89 d7 48 89 55 a0 e8 18 e7 cc ff 48 83 f8 ff 48 8b 55 a0 0f 84 74 fe ff ff =
<0f> 0b eb fe 66 0f 1f 44 00 00 55 48 89 e5 41 57 41 56 41 89 d6=20
[  898.132209] RIP  [<ffffffff8133b206>] balloon_process+0x336/0x340
[  898.132209]  RSP <ffff880037b4dce0>
[  898.738233] ---[ end trace 3f7af50285edb7bb ]---
[  898.749003] BUG: unable to handle kernel paging request at fffffffffffff=
ff8
[  898.752237] IP: [<ffffffff81086eeb>] kthread_data+0xb/0x20
[  898.752237] PGD 1e0d067 PUD 1e0e067 PMD 0=20
[  898.752237] Oops: 0000 [#2] PREEMPT SMP=20
[  898.752237] Modules linked in:
[  898.752237] CPU 0=20
[  898.752237] Pid: 3338, comm: kworker/0:1 Tainted: G      D      3.6.0-rc=
4-20120830+ #66 System manufacturer System Product Name/P5Q-EM DO
[  898.752237] RIP: e030:[<ffffffff81086eeb>]  [<ffffffff81086eeb>] kthread=
_data+0xb/0x20
[  898.752237] RSP: e02b:ffff880037b4d898  EFLAGS: 00010082
[  898.752237] RAX: 0000000000000000 RBX: ffff88003fc12e80 RCX: 00000000000=
00000
[  898.752237] RDX: ffffffff820057a0 RSI: 0000000000000000 RDI: ffff8800398=
fe180
[  898.752237] RBP: ffff880037b4d898 R08: ffff8800398fe1f0 R09: 00000000000=
00400
[  898.752237] R10: 0000000000000000 R11: 0000000000000001 R12: 00000000000=
00000
[  898.752237] R13: 0000000000000000 R14: ffff880037b4d7b8 R15: ffff880037b=
4da90
[  898.752237] FS:  00007fd4bd0ec740(0000) GS:ffff88003fc00000(0000) knlGS:=
0000000000000000
[  898.752237] CS:  e033 DS: 0000 ES: 0000 CR0: 000000008005003b
[  898.752237] CR2: fffffffffffffff8 CR3: 000000003920a000 CR4: 00000000000=
42660
[  898.752237] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 00000000000=
00000
[  898.752237] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 00000000000=
00400
[  898.752237] Process kworker/0:1 (pid: 3338, threadinfo ffff880037b4c000,=
 task ffff8800398fe180)
[  898.752237] Stack:
[  898.752237]  ffff880037b4d8c8 ffffffff8108306c 0000000000000000 ffff8800=
3fc12e80
[  898.752237]  0000000000000000 ffff8800398fe528 ffff880037b4da18 ffffffff=
8184931f
[  898.752237]  0000000000000000 ffffffff81083bb8 ffff8800398fe180 00000000=
00012e80
[  898.752237] Call Trace:
[  898.752237]  [<ffffffff8108306c>] wq_worker_sleeping+0x1c/0x90
[  898.752237]  [<ffffffff8184931f>] __schedule+0x5ff/0x8a0
[  898.752237]  [<ffffffff81083bb8>] ? free_pid+0x18/0xc0
[  898.752237]  [<ffffffff810602a7>] ? sha1_transform_ssse3+0x187/0xd00
[  898.752237]  [<ffffffff810b1a94>] ? lock_acquire+0xe4/0x110
[  898.752237]  [<ffffffff8106cfa7>] ? do_exit+0x4e7/0x8e0
[  898.752237]  [<ffffffff810e27f2>] ? call_rcu+0x12/0x20
[  898.752237]  [<ffffffff810b1f01>] ? lock_release+0x111/0x260
[  898.752237]  [<ffffffff81849654>] schedule+0x24/0x70
[  898.752237]  [<ffffffff8106d074>] do_exit+0x5b4/0x8e0
[  898.752237]  [<ffffffff81010240>] oops_end+0xb0/0xf0
[  898.752237]  [<ffffffff810103b6>] die+0x56/0x90
[  898.752237]  [<ffffffff8100d6c4>] do_trap+0xc4/0x170
[  898.752237]  [<ffffffff8100dbe2>] ? do_invalid_op+0x72/0xc0
[  898.752237]  [<ffffffff8100dc16>] do_invalid_op+0xa6/0xc0
[  898.752237]  [<ffffffff8133b206>] ? balloon_process+0x336/0x340
[  898.752237]  [<ffffffff810ac9e8>] ? trace_hardirqs_off_caller+0x78/0x150
[  898.752237]  [<ffffffff812b29fd>] ? trace_hardirqs_off_thunk+0x3a/0x3c
[  898.752237]  [<ffffffff8184b164>] ? restore_args+0x30/0x30
[  898.752237]  [<ffffffff8184c9fb>] invalid_op+0x1b/0x20
[  898.752237]  [<ffffffff8133b206>] ? balloon_process+0x336/0x340
[  898.752237]  [<ffffffff8107fb8f>] process_one_work+0x1bf/0x4a0
[  898.752237]  [<ffffffff8107fb30>] ? process_one_work+0x160/0x4a0
[  898.752237]  [<ffffffff81849191>] ? __schedule+0x471/0x8a0
[  898.752237]  [<ffffffff8133aed0>] ? decrease_reservation+0x2d0/0x2d0
[  898.752237]  [<ffffffff81080252>] worker_thread+0x152/0x470
[  898.752237]  [<ffffffff8184ad85>] ? _raw_spin_unlock_irqrestore+0x75/0xa0
[  898.752237]  [<ffffffff810ae4dd>] ? trace_hardirqs_on+0xd/0x10
[  898.752237]  [<ffffffff8184ad63>] ? _raw_spin_unlock_irqrestore+0x53/0xa0
[  898.752237]  [<ffffffff81080100>] ? manage_workers+0x290/0x290
[  898.752237]  [<ffffffff81087696>] kthread+0x96/0xa0
[  898.752237]  [<ffffffff8184cb84>] kernel_thread_helper+0x4/0x10
[  898.752237]  [<ffffffff8184b134>] ? retint_restore_args+0x13/0x13
[  898.752237]  [<ffffffff8184cb80>] ? gs_change+0x13/0x13
[  898.752237] Code: 55 65 48 8b 04 25 80 c6 00 00 48 8b 80 50 03 00 00 48 =
89 e5 8b 40 f0 c9 c3 0f 1f 80 00 00 00 00 48 8b 87 50 03 00 00 55 48 89 e5 =
<48> 8b 40 f8 c9 c3 66 66 66 66 66 66 2e 0f 1f 84 00 00 00 00 00=20
[  898.752237] RIP  [<ffffffff81086eeb>] kthread_data+0xb/0x20
[  898.752237]  RSP <ffff880037b4d898>
[  898.752237] CR2: fffffffffffffff8
[  898.752237] ---[ end trace 3f7af50285edb7bc ]---
[  898.752237] Fixing recursive fault but reboot is needed!
[  912.746625] xen_bridge: port 1(vif1.0) entered forwarding state
------------0320050151C2718BB
Content-Type: text/plain;
 name="serial-log.txt"
Content-transfer-encoding: base64
Content-Disposition: attachment;
 filename="serial-log.txt"

IF9fICBfXyAgICAgICAgICAgIF8gIF8gICAgX19fXyAgICBfX18gICAgICAgICAgICAgIF8g
IF8gICAgICAgICAgICAgICAgICAgICANCiBcIFwvIC9fX18gXyBfXyAgIHwgfHwgfCAgfF9f
XyBcICAvIF8gXCAgICBfIF9fIF9fX3wgfHwgfCAgICAgXyBfXyAgXyBfXyBfX18gDQogIFwg
IC8vIF8gXCAnXyBcICB8IHx8IHxfICAgX18pIHx8IHwgfCB8X198ICdfXy8gX198IHx8IHxf
IF9ffCAnXyBcfCAnX18vIF8gXA0KICAvICBcICBfXy8gfCB8IHwgfF9fICAgX3wgLyBfXy8g
fCB8X3wgfF9ffCB8IHwgKF9ffF9fICAgX3xfX3wgfF8pIHwgfCB8ICBfXy8NCiAvXy9cX1xf
X198X3wgfF98ICAgIHxffChfKV9fX19fKF8pX19fLyAgIHxffCAgXF9fX3wgIHxffCAgICB8
IC5fXy98X3wgIFxfX198DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgfF98ICAgICAgICAgICAgIA0KKFhFTikgWGVuIHZl
cnNpb24gNC4yLjAtcmM0LXByZSAocm9vdEApIChnY2MgKERlYmlhbiA0LjQuNS04KSA0LjQu
NSkgTW9uIFNlcCAgMyAxODozMjowNyBDRVNUIDIwMTINCihYRU4pIExhdGVzdCBDaGFuZ2VT
ZXQ6IFRodSBBdWcgMzAgMTg6MTc6MjAgMjAxMiArMDEwMCAyNTc5MTo5ZTU2NjVmOWY0MzAN
CihYRU4pIEJvb3Rsb2FkZXI6IEdSVUIgMS45OCsyMDEwMDgwNC0xNCtzcXVlZXplMQ0KKFhF
TikgQ29tbWFuZCBsaW5lOiBkb20wX21lbT0xMDI0TSxtYXg6MTAyNE0gbG9nbHZsPWFsbCBs
b2dsdmxfZ3Vlc3Q9YWxsIGNvbnNvbGVfdGltZXN0YW1wcyB2Z2E9Z2Z4LTgwMHg2MDB4OCBu
b3JlYm9vdCBkZWJ1ZyBsYXBpYz1kZWJ1ZyBhcGljX3ZlcmJvc2l0eT1kZWJ1ZyBhcGljPWRl
YnVnIGlvbW11PW9uLHZlcmJvc2UsZGVidWcgY29tMT0zODQwMCw4bjEgY29uc29sZT12Z2Es
Y29tMQ0KKFhFTikgVmlkZW8gaW5mb3JtYXRpb246DQooWEVOKSAgVkdBIGlzIGdyYXBoaWNz
IG1vZGUgODAweDYwMCwgOCBicHANCihYRU4pICBWQkUvRERDIG1ldGhvZHM6IG5vbmU7IEVE
SUQgdHJhbnNmZXIgdGltZTogMCBzZWNvbmRzDQooWEVOKSAgRURJRCBpbmZvIG5vdCByZXRy
aWV2ZWQgYmVjYXVzZSBubyBEREMgcmV0cmlldmFsIG1ldGhvZCBkZXRlY3RlZA0KKFhFTikg
RGlzYyBpbmZvcm1hdGlvbjoNCihYRU4pICBGb3VuZCAwIE1CUiBzaWduYXR1cmVzDQooWEVO
KSAgRm91bmQgMSBFREQgaW5mb3JtYXRpb24gc3RydWN0dXJlcw0KKFhFTikgWGVuLWU4MjAg
UkFNIG1hcDoNCihYRU4pICAwMDAwMDAwMDAwMDAwMDAwIC0gMDAwMDAwMDAwMDA5ZTgwMCAo
dXNhYmxlKQ0KKFhFTikgIDAwMDAwMDAwMDAwOWU4MDAgLSAwMDAwMDAwMDAwMGEwMDAwIChy
ZXNlcnZlZCkNCihYRU4pICAwMDAwMDAwMDAwMGU0MDAwIC0gMDAwMDAwMDAwMDEwMDAwMCAo
cmVzZXJ2ZWQpDQooWEVOKSAgMDAwMDAwMDAwMDEwMDAwMCAtIDAwMDAwMDAwN2VlNzAwMDAg
KHVzYWJsZSkNCihYRU4pICAwMDAwMDAwMDdlZTcwMDAwIC0gMDAwMDAwMDA3ZWU3ZTAwMCAo
QUNQSSBkYXRhKQ0KKFhFTikgIDAwMDAwMDAwN2VlN2UwMDAgLSAwMDAwMDAwMDdlZWQwMDAw
IChBQ1BJIE5WUykNCihYRU4pICAwMDAwMDAwMDdlZWQwMDAwIC0gMDAwMDAwMDA3ZWYwMDAw
MCAocmVzZXJ2ZWQpDQooWEVOKSAgMDAwMDAwMDBmZWQwMDAwMCAtIDAwMDAwMDAwZmVkMDEx
MDAgKHJlc2VydmVkKQ0KKFhFTikgIDAwMDAwMDAwZmVkMDIwMDAgLSAwMDAwMDAwMGZlZDE0
YzAwIChyZXNlcnZlZCkNCihYRU4pICAwMDAwMDAwMGZlZDIwMDAwIC0gMDAwMDAwMDBmZWQ0
MDAwMCAocmVzZXJ2ZWQpDQooWEVOKSAgMDAwMDAwMDBmZWUwMDAwMCAtIDAwMDAwMDAwZmVl
MDEwMDAgKHJlc2VydmVkKQ0KKFhFTikgIDAwMDAwMDAwZmZlMDAwMDAgLSAwMDAwMDAwMTAw
MDAwMDAwIChyZXNlcnZlZCkNCihYRU4pIFN5c3RlbSBSQU06IDIwMzBNQiAoMjA3ODc3NmtC
KQ0KKFhFTikgQUNQSTogUlNEUCAwMDBGQjA4MCwgMDAyNCAocjIgQUNQSUFNKQ0KKFhFTikg
QUNQSTogWFNEVCA3RUU3MDEwMCwgMDA1QyAocjEgQV9NX0lfIE9FTVhTRFQgICA1MDAxMDI1
IE1TRlQgICAgICAgOTcpDQooWEVOKSBBQ1BJOiBGQUNQIDdFRTcwMjkwLCAwMEY0IChyMyBB
X01fSV8gT0VNRkFDUCAgIDUwMDEwMjUgTVNGVCAgICAgICA5NykNCihYRU4pIEFDUEk6IERT
RFQgN0VFNzA0NDAsIDg0MUYgKHIxICBBMTA2NSBBMTA2NTAwMCAgICAgICAgMCBJTlRMIDIw
MDYwMTEzKQ0KKFhFTikgQUNQSTogRkFDUyA3RUU3RTAwMCwgMDA0MA0KKFhFTikgQUNQSTog
QVBJQyA3RUU3MDM5MCwgMDA2QyAocjEgQV9NX0lfIE9FTUFQSUMgICA1MDAxMDI1IE1TRlQg
ICAgICAgOTcpDQooWEVOKSBBQ1BJOiBNQ0ZHIDdFRTcwNDAwLCAwMDNDIChyMSBBX01fSV8g
T0VNTUNGRyAgIDUwMDEwMjUgTVNGVCAgICAgICA5NykNCihYRU4pIEFDUEk6IE9FTUIgN0VF
N0UwNDAsIDAwODkgKHIxIEFfTV9JXyBBTUlfT0VNICAgNTAwMTAyNSBNU0ZUICAgICAgIDk3
KQ0KKFhFTikgQUNQSTogSFBFVCA3RUU3ODg2MCwgMDAzOCAocjEgQV9NX0lfIE9FTUhQRVQg
ICA1MDAxMDI1IE1TRlQgICAgICAgOTcpDQooWEVOKSBBQ1BJOiBHU0NJIDdFRTdFMEQwLCAy
MDI0IChyMSBBX01fSV8gR01DSFNDSSAgIDUwMDEwMjUgTVNGVCAgICAgICA5NykNCihYRU4p
IEFDUEk6IFNTRFQgN0VFODBBMDAsIDBBN0MgKHIxIERwZ1BtbSAgICBDcHVQbSAgICAgICAx
MiBJTlRMIDIwMDYwMTEzKQ0KKFhFTikgTm8gTlVNQSBjb25maWd1cmF0aW9uIGZvdW5kDQoo
WEVOKSBGYWtpbmcgYSBub2RlIGF0IDAwMDAwMDAwMDAwMDAwMDAtMDAwMDAwMDA3ZWU3MDAw
MA0KKFhFTikgRG9tYWluIGhlYXAgaW5pdGlhbGlzZWQNCihYRU4pIHZlc2FmYjogZnJhbWVi
dWZmZXIgYXQgMHhmZDgwMDAwMCwgbWFwcGVkIHRvIDB4ZmZmZjgyYzAwMDAwMDAwMCwgdXNp
bmcgMjA0OGssIHRvdGFsIDQwOTZrDQooWEVOKSB2ZXNhZmI6IG1vZGUgaXMgODAweDYwMHg4
LCBsaW5lbGVuZ3RoPTgwMCwgZm9udCA4eDgNCihYRU4pIHZlc2FmYjogUHNldWRvY29sb3I6
IHNpemU9Njo2OjY6Niwgc2hpZnQ9MDowOjA6MA0KKFhFTikgZm91bmQgU01QIE1QLXRhYmxl
IGF0IDAwMGZmNzgwDQooWEVOKSBETUkgcHJlc2VudC4NCihYRU4pIEFQSUMgYm9vdCBzdGF0
ZSBpcyAneGFwaWMnDQooWEVOKSBVc2luZyBBUElDIGRyaXZlciBkZWZhdWx0DQooWEVOKSBB
Q1BJOiBQTS1UaW1lciBJTyBQb3J0OiAweDgwOA0KKFhFTikgQUNQSTogQUNQSSBTTEVFUCBJ
TkZPOiBwbTF4X2NudFs4MDQsMF0sIHBtMXhfZXZ0WzgwMCwwXQ0KKFhFTikgQUNQSTogICAg
ICAgICAgICAgICAgICB3YWtldXBfdmVjWzdlZTdlMDBjXSwgdmVjX3NpemVbMjBdDQooWEVO
KSBBQ1BJOiBMb2NhbCBBUElDIGFkZHJlc3MgMHhmZWUwMDAwMA0KKFhFTikgQUNQSTogTEFQ
SUMgKGFjcGlfaWRbMHgwMV0gbGFwaWNfaWRbMHgwMF0gZW5hYmxlZCkNCihYRU4pIFByb2Nl
c3NvciAjMCA3OjcgQVBJQyB2ZXJzaW9uIDIwDQooWEVOKSBBQ1BJOiBMQVBJQyAoYWNwaV9p
ZFsweDAyXSBsYXBpY19pZFsweDAxXSBlbmFibGVkKQ0KKFhFTikgUHJvY2Vzc29yICMxIDc6
NyBBUElDIHZlcnNpb24gMjANCihYRU4pIEFDUEk6IExBUElDIChhY3BpX2lkWzB4MDNdIGxh
cGljX2lkWzB4MDJdIGVuYWJsZWQpDQooWEVOKSBQcm9jZXNzb3IgIzIgNzo3IEFQSUMgdmVy
c2lvbiAyMA0KKFhFTikgQUNQSTogTEFQSUMgKGFjcGlfaWRbMHgwNF0gbGFwaWNfaWRbMHgw
M10gZW5hYmxlZCkNCihYRU4pIFByb2Nlc3NvciAjMyA3OjcgQVBJQyB2ZXJzaW9uIDIwDQoo
WEVOKSBBQ1BJOiBJT0FQSUMgKGlkWzB4MDRdIGFkZHJlc3NbMHhmZWMwMDAwMF0gZ3NpX2Jh
c2VbMF0pDQooWEVOKSBJT0FQSUNbMF06IGFwaWNfaWQgNCwgdmVyc2lvbiAzMiwgYWRkcmVz
cyAweGZlYzAwMDAwLCBHU0kgMC0yMw0KKFhFTikgQUNQSTogSU5UX1NSQ19PVlIgKGJ1cyAw
IGJ1c19pcnEgMCBnbG9iYWxfaXJxIDIgZGZsIGRmbCkNCihYRU4pIEFDUEk6IElOVF9TUkNf
T1ZSIChidXMgMCBidXNfaXJxIDkgZ2xvYmFsX2lycSA5IGhpZ2ggbGV2ZWwpDQooWEVOKSBB
Q1BJOiBJUlEwIHVzZWQgYnkgb3ZlcnJpZGUuDQooWEVOKSBBQ1BJOiBJUlEyIHVzZWQgYnkg
b3ZlcnJpZGUuDQooWEVOKSBBQ1BJOiBJUlE5IHVzZWQgYnkgb3ZlcnJpZGUuDQooWEVOKSBF
bmFibGluZyBBUElDIG1vZGU6ICBGbGF0LiAgVXNpbmcgMSBJL08gQVBJQ3MNCihYRU4pIEFD
UEk6IEhQRVQgaWQ6IDB4ODA4NmE3MDEgYmFzZTogMHhmZWQwMDAwMA0KKFhFTikgVGFibGUg
aXMgbm90IGZvdW5kIQ0KKFhFTikgVXNpbmcgQUNQSSAoTUFEVCkgZm9yIFNNUCBjb25maWd1
cmF0aW9uIGluZm9ybWF0aW9uDQooWEVOKSBTTVA6IEFsbG93aW5nIDQgQ1BVcyAoMCBob3Rw
bHVnIENQVXMpDQooWEVOKSBtYXBwZWQgQVBJQyB0byBmZmZmODJjM2ZmZGZlMDAwIChmZWUw
MDAwMCkNCihYRU4pIG1hcHBlZCBJT0FQSUMgdG8gZmZmZjgyYzNmZmRmZDAwMCAoZmVjMDAw
MDApDQooWEVOKSBJUlEgbGltaXRzOiAyNCBHU0ksIDc2MCBNU0kvTVNJLVgNCihYRU4pIFVz
aW5nIHNjaGVkdWxlcjogU01QIENyZWRpdCBTY2hlZHVsZXIgKGNyZWRpdCkNCihYRU4pIERl
dGVjdGVkIDI2NjYuNDI3IE1IeiBwcm9jZXNzb3IuDQooWEVOKSBJbml0aW5nIG1lbW9yeSBz
aGFyaW5nLg0KKFhFTikgeHN0YXRlX2luaXQ6IHVzaW5nIGNudHh0X3NpemU6IDB4MjQwIGFu
ZCBzdGF0ZXM6IDB4Mw0KKFhFTikgbWNlX2ludGVsLmM6MTIzOTogTUNBIENhcGFiaWxpdHk6
IEJDQVNUIDEgU0VSIDAgQ01DSSAwIGZpcnN0YmFuayAxIGV4dGVuZGVkIE1DRSBNU1IgMA0K
KFhFTikgSW50ZWwgbWFjaGluZSBjaGVjayByZXBvcnRpbmcgZW5hYmxlZA0KKFhFTikgUENJ
OiBNQ0ZHIGNvbmZpZ3VyYXRpb24gMDogYmFzZSBlMDAwMDAwMCBzZWdtZW50IDAwMDAgYnVz
ZXMgMDAgLSBmZg0KKFhFTikgUENJOiBOb3QgdXNpbmcgTUNGRyBmb3Igc2VnbWVudCAwMDAw
IGJ1cyAwMC1mZg0KKFhFTikgSS9PIHZpcnR1YWxpc2F0aW9uIGRpc2FibGVkDQooWEVOKSBH
ZXR0aW5nIFZFUlNJT046IDUwMDE0DQooWEVOKSBHZXR0aW5nIFZFUlNJT046IDUwMDE0DQoo
WEVOKSBHZXR0aW5nIElEOiAwDQooWEVOKSBHZXR0aW5nIExWVDA6IDcwMA0KKFhFTikgR2V0
dGluZyBMVlQxOiA0MDANCihYRU4pIGVuYWJsZWQgRXh0SU5UIG9uIENQVSMwDQooWEVOKSBF
TkFCTElORyBJTy1BUElDIElSUXMNCihYRU4pICAtPiBVc2luZyBuZXcgQUNLIG1ldGhvZA0K
KFhFTikgaW5pdCBJT19BUElDIElSUXMNCihYRU4pICBJTy1BUElDIChhcGljaWQtcGluKSA0
LTAsIDQtMTYsIDQtMTcsIDQtMTgsIDQtMTksIDQtMjAsIDQtMjEsIDQtMjIsIDQtMjMgbm90
IGNvbm5lY3RlZC4NCihYRU4pIC4uVElNRVI6IHZlY3Rvcj0weEYwIGFwaWMxPTAgcGluMT0y
IGFwaWMyPS0xIHBpbjI9LTENCihYRU4pIG51bWJlciBvZiBNUCBJUlEgc291cmNlczogMTUu
DQooWEVOKSBudW1iZXIgb2YgSU8tQVBJQyAjNCByZWdpc3RlcnM6IDI0Lg0KKFhFTikgdGVz
dGluZyB0aGUgSU8gQVBJQy4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uDQooWEVOKSBJTyBBUElD
ICM0Li4uLi4uDQooWEVOKSAuLi4uIHJlZ2lzdGVyICMwMDogMDQwMDAwMDANCihYRU4pIC4u
Li4uLi4gICAgOiBwaHlzaWNhbCBBUElDIGlkOiAwNA0KKFhFTikgLi4uLi4uLiAgICA6IERl
bGl2ZXJ5IFR5cGU6IDANCihYRU4pIC4uLi4uLi4gICAgOiBMVFMgICAgICAgICAgOiAwDQoo
WEVOKSAuLi4uIHJlZ2lzdGVyICMwMTogMDAxNzAwMjANCihYRU4pIC4uLi4uLi4gICAgIDog
bWF4IHJlZGlyZWN0aW9uIGVudHJpZXM6IDAwMTcNCihYRU4pIC4uLi4uLi4gICAgIDogUFJR
IGltcGxlbWVudGVkOiAwDQooWEVOKSAuLi4uLi4uICAgICA6IElPIEFQSUMgdmVyc2lvbjog
MDAyMA0KKFhFTikgLi4uLiBJUlEgcmVkaXJlY3Rpb24gdGFibGU6DQooWEVOKSAgTlIgTG9n
IFBoeSBNYXNrIFRyaWcgSVJSIFBvbCBTdGF0IERlc3QgRGVsaSBWZWN0OiAgIA0KKFhFTikg
IDAwIDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDAgICAgMDANCihYRU4p
ICAwMSAwMDEgMDEgIDAgICAgMCAgICAwICAgMCAgIDAgICAgMSAgICAxICAgIDI4DQooWEVO
KSAgMDIgMDAxIDAxICAwICAgIDAgICAgMCAgIDAgICAwICAgIDEgICAgMSAgICBGMA0KKFhF
TikgIDAzIDAwMSAwMSAgMCAgICAwICAgIDAgICAwICAgMCAgICAxICAgIDEgICAgMzANCihY
RU4pICAwNCAwMDEgMDEgIDAgICAgMCAgICAwICAgMCAgIDAgICAgMSAgICAxICAgIEYxDQoo
WEVOKSAgMDUgMDAxIDAxICAwICAgIDAgICAgMCAgIDAgICAwICAgIDEgICAgMSAgICAzOA0K
KFhFTikgIDA2IDAwMSAwMSAgMCAgICAwICAgIDAgICAwICAgMCAgICAxICAgIDEgICAgNDAN
CihYRU4pICAwNyAwMDEgMDEgIDAgICAgMCAgICAwICAgMCAgIDAgICAgMSAgICAxICAgIDQ4
DQooWEVOKSAgMDggMDAxIDAxICAwICAgIDAgICAgMCAgIDAgICAwICAgIDEgICAgMSAgICA1
MA0KKFhFTikgIDA5IDAwMSAwMSAgMSAgICAxICAgIDAgICAwICAgMCAgICAxICAgIDEgICAg
NTgNCihYRU4pICAwYSAwMDEgMDEgIDAgICAgMCAgICAwICAgMCAgIDAgICAgMSAgICAxICAg
IDYwDQooWEVOKSAgMGIgMDAxIDAxICAwICAgIDAgICAgMCAgIDAgICAwICAgIDEgICAgMSAg
ICA2OA0KKFhFTikgIDBjIDAwMSAwMSAgMCAgICAwICAgIDAgICAwICAgMCAgICAxICAgIDEg
ICAgNzANCihYRU4pICAwZCAwMDEgMDEgIDAgICAgMCAgICAwICAgMCAgIDAgICAgMSAgICAx
ICAgIDc4DQooWEVOKSAgMGUgMDAxIDAxICAwICAgIDAgICAgMCAgIDAgICAwICAgIDEgICAg
MSAgICA4OA0KKFhFTikgIDBmIDAwMSAwMSAgMCAgICAwICAgIDAgICAwICAgMCAgICAxICAg
IDEgICAgOTANCihYRU4pICAxMCAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAg
ICAwICAgIDAwDQooWEVOKSAgMTEgMDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAwICAgIDAg
ICAgMCAgICAwMA0KKFhFTikgIDEyIDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAw
ICAgIDAgICAgMDANCihYRU4pICAxMyAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAg
MCAgICAwICAgIDAwDQooWEVOKSAgMTQgMDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAwICAg
IDAgICAgMCAgICAwMA0KKFhFTikgIDE1IDAxMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAg
ICAwICAgIDIgICAgMjANCihYRU4pICAxNiAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAg
ICAgMCAgICAwICAgIDAwDQooWEVOKSAgMTcgMDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAw
ICAgIDAgICAgMCAgICAwMA0KKFhFTikgVXNpbmcgdmVjdG9yLWJhc2VkIGluZGV4aW5nDQoo
WEVOKSBJUlEgdG8gcGluIG1hcHBpbmdzOg0KKFhFTikgSVJRMjQwIC0+IDA6Mg0KKFhFTikg
SVJRNDAgLT4gMDoxDQooWEVOKSBJUlE0OCAtPiAwOjMNCihYRU4pIElSUTI0MSAtPiAwOjQN
CihYRU4pIElSUTU2IC0+IDA6NQ0KKFhFTikgSVJRNjQgLT4gMDo2DQooWEVOKSBJUlE3MiAt
PiAwOjcNCihYRU4pIElSUTgwIC0+IDA6OA0KKFhFTikgSVJRODggLT4gMDo5DQooWEVOKSBJ
UlE5NiAtPiAwOjEwDQooWEVOKSBJUlExMDQgLT4gMDoxMQ0KKFhFTikgSVJRMTEyIC0+IDA6
MTINCihYRU4pIElSUTEyMCAtPiAwOjEzDQooWEVOKSBJUlExMzYgLT4gMDoxNA0KKFhFTikg
SVJRMTQ0IC0+IDA6MTUNCihYRU4pIC4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u
Li4uLiBkb25lLg0KKFhFTikgVXNpbmcgbG9jYWwgQVBJQyB0aW1lciBpbnRlcnJ1cHRzLg0K
KFhFTikgY2FsaWJyYXRpbmcgQVBJQyB0aW1lciAuLi4NCihYRU4pIC4uLi4uIENQVSBjbG9j
ayBzcGVlZCBpcyAyNjY2LjM5MDMgTUh6Lg0KKFhFTikgLi4uLi4gaG9zdCBidXMgY2xvY2sg
c3BlZWQgaXMgMzMzLjI5ODcgTUh6Lg0KKFhFTikgLi4uLi4gYnVzX3NjYWxlID0gMHgwMDAx
NTU1NQ0KKFhFTikgWzIwMTItMDktMDQgMTY6NDA6NDNdIFBsYXRmb3JtIHRpbWVyIGlzIDE0
LjMxOE1IeiBIUEVUDQooWEVOKSBbMjAxMi0wOS0wNCAxNjo0MDo0M10gQWxsb2NhdGVkIGNv
bnNvbGUgcmluZyBvZiAzMiBLaUIuDQooWEVOKSBbMjAxMi0wOS0wNCAxNjo0MDo0M10gVk1Y
OiBTdXBwb3J0ZWQgYWR2YW5jZWQgZmVhdHVyZXM6DQooWEVOKSBbMjAxMi0wOS0wNCAxNjo0
MDo0M10gIC0gQVBJQyBNTUlPIGFjY2VzcyB2aXJ0dWFsaXNhdGlvbg0KKFhFTikgWzIwMTIt
MDktMDQgMTY6NDA6NDNdICAtIEFQSUMgVFBSIHNoYWRvdw0KKFhFTikgWzIwMTItMDktMDQg
MTY6NDA6NDNdICAtIFZpcnR1YWwgTk1JDQooWEVOKSBbMjAxMi0wOS0wNCAxNjo0MDo0M10g
IC0gTVNSIGRpcmVjdC1hY2Nlc3MgYml0bWFwDQooWEVOKSBbMjAxMi0wOS0wNCAxNjo0MDo0
M10gSFZNOiBBU0lEcyBkaXNhYmxlZC4NCihYRU4pIFsyMDEyLTA5LTA0IDE2OjQwOjQzXSBI
Vk06IFZNWCBlbmFibGVkDQooWEVOKSBbMjAxMi0wOS0wNCAxNjo0MDo0Ml0gbWFza2VkIEV4
dElOVCBvbiBDUFUjMQ0KKFhFTikgWzIwMTItMDktMDQgMTY6NDA6NDJdIG1hc2tlZCBFeHRJ
TlQgb24gQ1BVIzINCihYRU4pIFsyMDEyLTA5LTA0IDE2OjQwOjQyXSBtYXNrZWQgRXh0SU5U
IG9uIENQVSMzDQooWEVOKSBbMjAxMi0wOS0wNCAxNjo0MDo0M10gQnJvdWdodCB1cCA0IENQ
VXMNCihYRU4pIFsyMDEyLTA5LTA0IDE2OjQwOjQzXSBIUEVUOiA4IHRpbWVycyAoOCB3aWxs
IGJlIHVzZWQgZm9yIGJyb2FkY2FzdCkNCihYRU4pIFsyMDEyLTA5LTA0IDE2OjQwOjQzXSBB
Q1BJIHNsZWVwIG1vZGVzOiBTMw0KKFhFTikgWzIwMTItMDktMDQgMTY6NDA6NDNdIG1jaGVj
a19wb2xsOiBNYWNoaW5lIGNoZWNrIHBvbGxpbmcgdGltZXIgc3RhcnRlZC4NCihYRU4pIFsy
MDEyLTA5LTA0IDE2OjQwOjQzXSAqKiogTE9BRElORyBET01BSU4gMCAqKioNCihYRU4pIFsy
MDEyLTA5LTA0IDE2OjQwOjQzXSBlbGZfcGFyc2VfYmluYXJ5OiBwaGRyOiBwYWRkcj0weDEw
MDAwMDAgbWVtc3o9MHhkNzQwMDANCihYRU4pIFsyMDEyLTA5LTA0IDE2OjQwOjQzXSBlbGZf
cGFyc2VfYmluYXJ5OiBwaGRyOiBwYWRkcj0weDFlMDAwMDAgbWVtc3o9MHhkZDBlOA0KKFhF
TikgWzIwMTItMDktMDQgMTY6NDA6NDNdIGVsZl9wYXJzZV9iaW5hcnk6IHBoZHI6IHBhZGRy
PTB4MWVkZTAwMCBtZW1zej0weDEzYzAwDQooWEVOKSBbMjAxMi0wOS0wNCAxNjo0MDo0M10g
ZWxmX3BhcnNlX2JpbmFyeTogcGhkcjogcGFkZHI9MHgxZWYyMDAwIG1lbXN6PTB4ZGU2MDAw
DQooWEVOKSBbMjAxMi0wOS0wNCAxNjo0MDo0M10gZWxmX3BhcnNlX2JpbmFyeTogbWVtb3J5
OiAweDEwMDAwMDAgLT4gMHgyY2Q4MDAwDQooWEVOKSBbMjAxMi0wOS0wNCAxNjo0MDo0M10g
ZWxmX3hlbl9wYXJzZV9ub3RlOiBHVUVTVF9PUyA9ICJsaW51eCINCihYRU4pIFsyMDEyLTA5
LTA0IDE2OjQwOjQzXSBlbGZfeGVuX3BhcnNlX25vdGU6IEdVRVNUX1ZFUlNJT04gPSAiMi42
Ig0KKFhFTikgWzIwMTItMDktMDQgMTY6NDA6NDNdIGVsZl94ZW5fcGFyc2Vfbm90ZTogWEVO
X1ZFUlNJT04gPSAieGVuLTMuMCINCihYRU4pIFsyMDEyLTA5LTA0IDE2OjQwOjQzXSBlbGZf
eGVuX3BhcnNlX25vdGU6IFZJUlRfQkFTRSA9IDB4ZmZmZmZmZmY4MDAwMDAwMA0KKFhFTikg
WzIwMTItMDktMDQgMTY6NDA6NDNdIGVsZl94ZW5fcGFyc2Vfbm90ZTogRU5UUlkgPSAweGZm
ZmZmZmZmODFlZjIyMTANCihYRU4pIFsyMDEyLTA5LTA0IDE2OjQwOjQzXSBlbGZfeGVuX3Bh
cnNlX25vdGU6IEhZUEVSQ0FMTF9QQUdFID0gMHhmZmZmZmZmZjgxMDAxMDAwDQooWEVOKSBb
MjAxMi0wOS0wNCAxNjo0MDo0M10gZWxmX3hlbl9wYXJzZV9ub3RlOiBGRUFUVVJFUyA9ICIh
d3JpdGFibGVfcGFnZV90YWJsZXN8cGFlX3BnZGlyX2Fib3ZlXzRnYiINCihYRU4pIFsyMDEy
LTA5LTA0IDE2OjQwOjQzXSBlbGZfeGVuX3BhcnNlX25vdGU6IFBBRV9NT0RFID0gInllcyIN
CihYRU4pIFsyMDEyLTA5LTA0IDE2OjQwOjQzXSBlbGZfeGVuX3BhcnNlX25vdGU6IExPQURF
UiA9ICJnZW5lcmljIg0KKFhFTikgWzIwMTItMDktMDQgMTY6NDA6NDNdIGVsZl94ZW5fcGFy
c2Vfbm90ZTogdW5rbm93biB4ZW4gZWxmIG5vdGUgKDB4ZCkNCihYRU4pIFsyMDEyLTA5LTA0
IDE2OjQwOjQzXSBlbGZfeGVuX3BhcnNlX25vdGU6IFNVU1BFTkRfQ0FOQ0VMID0gMHgxDQoo
WEVOKSBbMjAxMi0wOS0wNCAxNjo0MDo0M10gZWxmX3hlbl9wYXJzZV9ub3RlOiBIVl9TVEFS
VF9MT1cgPSAweGZmZmY4MDAwMDAwMDAwMDANCihYRU4pIFsyMDEyLTA5LTA0IDE2OjQwOjQz
XSBlbGZfeGVuX3BhcnNlX25vdGU6IFBBRERSX09GRlNFVCA9IDB4MA0KKFhFTikgWzIwMTIt
MDktMDQgMTY6NDA6NDNdIGVsZl94ZW5fYWRkcl9jYWxjX2NoZWNrOiBhZGRyZXNzZXM6DQoo
WEVOKSBbMjAxMi0wOS0wNCAxNjo0MDo0M10gICAgIHZpcnRfYmFzZSAgICAgICAgPSAweGZm
ZmZmZmZmODAwMDAwMDANCihYRU4pIFsyMDEyLTA5LTA0IDE2OjQwOjQzXSAgICAgZWxmX3Bh
ZGRyX29mZnNldCA9IDB4MA0KKFhFTikgWzIwMTItMDktMDQgMTY6NDA6NDNdICAgICB2aXJ0
X29mZnNldCAgICAgID0gMHhmZmZmZmZmZjgwMDAwMDAwDQooWEVOKSBbMjAxMi0wOS0wNCAx
Njo0MDo0M10gICAgIHZpcnRfa3N0YXJ0ICAgICAgPSAweGZmZmZmZmZmODEwMDAwMDANCihY
RU4pIFsyMDEyLTA5LTA0IDE2OjQwOjQzXSAgICAgdmlydF9rZW5kICAgICAgICA9IDB4ZmZm
ZmZmZmY4MmNkODAwMA0KKFhFTikgWzIwMTItMDktMDQgMTY6NDA6NDNdICAgICB2aXJ0X2Vu
dHJ5ICAgICAgID0gMHhmZmZmZmZmZjgxZWYyMjEwDQooWEVOKSBbMjAxMi0wOS0wNCAxNjo0
MDo0M10gICAgIHAybV9iYXNlICAgICAgICAgPSAweGZmZmZmZmZmZmZmZmZmZmYNCihYRU4p
IFsyMDEyLTA5LTA0IDE2OjQwOjQzXSAgWGVuICBrZXJuZWw6IDY0LWJpdCwgbHNiLCBjb21w
YXQzMg0KKFhFTikgWzIwMTItMDktMDQgMTY6NDA6NDNdICBEb20wIGtlcm5lbDogNjQtYml0
LCBQQUUsIGxzYiwgcGFkZHIgMHgxMDAwMDAwIC0+IDB4MmNkODAwMA0KKFhFTikgWzIwMTIt
MDktMDQgMTY6NDA6NDNdIFBIWVNJQ0FMIE1FTU9SWSBBUlJBTkdFTUVOVDoNCihYRU4pIFsy
MDEyLTA5LTA0IDE2OjQwOjQzXSAgRG9tMCBhbGxvYy46ICAgMDAwMDAwMDA3NDAwMDAwMC0+
MDAwMDAwMDA3ODAwMDAwMCAoMjQ0NjE3IHBhZ2VzIHRvIGJlIGFsbG9jYXRlZCkNCihYRU4p
IFsyMDEyLTA5LTA0IDE2OjQwOjQ0XSAgSW5pdC4gcmFtZGlzazogMDAwMDAwMDA3ZTU4OTAw
MC0+MDAwMDAwMDA3ZTlmZjYwMA0KKFhFTikgWzIwMTItMDktMDQgMTY6NDA6NDRdIFZJUlRV
QUwgTUVNT1JZIEFSUkFOR0VNRU5UOg0KKFhFTikgWzIwMTItMDktMDQgMTY6NDA6NDRdICBM
b2FkZWQga2VybmVsOiBmZmZmZmZmZjgxMDAwMDAwLT5mZmZmZmZmZjgyY2Q4MDAwDQooWEVO
KSBbMjAxMi0wOS0wNCAxNjo0MDo0NF0gIEluaXQuIHJhbWRpc2s6IGZmZmZmZmZmODJjZDgw
MDAtPmZmZmZmZmZmODMxNGU2MDANCihYRU4pIFsyMDEyLTA5LTA0IDE2OjQwOjQ0XSAgUGh5
cy1NYWNoIG1hcDogZmZmZmZmZmY4MzE0ZjAwMC0+ZmZmZmZmZmY4MzM0ZjAwMA0KKFhFTikg
WzIwMTItMDktMDQgMTY6NDA6NDRdICBTdGFydCBpbmZvOiAgICBmZmZmZmZmZjgzMzRmMDAw
LT5mZmZmZmZmZjgzMzRmNGI0DQooWEVOKSBbMjAxMi0wOS0wNCAxNjo0MDo0NF0gIFBhZ2Ug
dGFibGVzOiAgIGZmZmZmZmZmODMzNTAwMDAtPmZmZmZmZmZmODMzNmQwMDANCihYRU4pIFsy
MDEyLTA5LTA0IDE2OjQwOjQ0XSAgQm9vdCBzdGFjazogICAgZmZmZmZmZmY4MzM2ZDAwMC0+
ZmZmZmZmZmY4MzM2ZTAwMA0KKFhFTikgWzIwMTItMDktMDQgMTY6NDA6NDRdICBUT1RBTDog
ICAgICAgICBmZmZmZmZmZjgwMDAwMDAwLT5mZmZmZmZmZjgzNDAwMDAwDQooWEVOKSBbMjAx
Mi0wOS0wNCAxNjo0MDo0NF0gIEVOVFJZIEFERFJFU1M6IGZmZmZmZmZmODFlZjIyMTANCihY
RU4pIFsyMDEyLTA5LTA0IDE2OjQwOjQ0XSBEb20wIGhhcyBtYXhpbXVtIDQgVkNQVXMNCihY
RU4pIFsyMDEyLTA5LTA0IDE2OjQwOjQ0XSBlbGZfbG9hZF9iaW5hcnk6IHBoZHIgMCBhdCAw
eGZmZmZmZmZmODEwMDAwMDAgLT4gMHhmZmZmZmZmZjgxZDc0MDAwDQooWEVOKSBbMjAxMi0w
OS0wNCAxNjo0MDo0NF0gZWxmX2xvYWRfYmluYXJ5OiBwaGRyIDEgYXQgMHhmZmZmZmZmZjgx
ZTAwMDAwIC0+IDB4ZmZmZmZmZmY4MWVkZDBlOA0KKFhFTikgWzIwMTItMDktMDQgMTY6NDA6
NDRdIGVsZl9sb2FkX2JpbmFyeTogcGhkciAyIGF0IDB4ZmZmZmZmZmY4MWVkZTAwMCAtPiAw
eGZmZmZmZmZmODFlZjFjMDANCihYRU4pIFsyMDEyLTA5LTA0IDE2OjQwOjQ0XSBlbGZfbG9h
ZF9iaW5hcnk6IHBoZHIgMyBhdCAweGZmZmZmZmZmODFlZjIwMDAgLT4gMHhmZmZmZmZmZjgx
ZjhjMDAwDQooWEVOKSBbMjAxMi0wOS0wNCAxNjo0MDo0NF0gU2NydWJiaW5nIEZyZWUgUkFN
OiAuLi4uLi4uLi5kb25lLg0KKFhFTikgWzIwMTItMDktMDQgMTY6NDA6NDRdIEluaXRpYWwg
bG93IG1lbW9yeSB2aXJxIHRocmVzaG9sZCBzZXQgYXQgMHg0MDAwIHBhZ2VzLg0KKFhFTikg
WzIwMTItMDktMDQgMTY6NDA6NDRdIFN0ZC4gTG9nbGV2ZWw6IEFsbA0KKFhFTikgWzIwMTIt
MDktMDQgMTY6NDA6NDRdIEd1ZXN0IExvZ2xldmVsOiBBbGwNCihYRU4pIFsyMDEyLTA5LTA0
IDE2OjQwOjQ0XSBYZW4gaXMgcmVsaW5xdWlzaGluZyBWR0EgY29uc29sZS4NCihYRU4pIFsy
MDEyLTA5LTA0IDE2OjQwOjQ0XSAqKiogU2VyaWFsIGlucHV0IC0+IERPTTAgKHR5cGUgJ0NU
UkwtYScgdGhyZWUgdGltZXMgdG8gc3dpdGNoIGlucHV0IHRvIFhlbikNCihYRU4pIFsyMDEy
LTA5LTA0IDE2OjQwOjQ0XSBGcmVlZCAyNTZrQiBpbml0IG1lbW9yeS4NCm1hcHBpbmcga2Vy
bmVsIGludG8gcGh5c2ljYWwgbWVtb3J5DQphYm91dCB0byBnZXQgc3RhcnRlZC4uLg0KWyAg
ICAwLjAwMDAwMF0gSW5pdGlhbGl6aW5nIGNncm91cCBzdWJzeXMgY3B1c2V0DQpbICAgIDAu
MDAwMDAwXSBJbml0aWFsaXppbmcgY2dyb3VwIHN1YnN5cyBjcHUNClsgICAgMC4wMDAwMDBd
IExpbnV4IHZlcnNpb24gMy42LjAtcmM0LTIwMTIwODMwKyAocm9vdEB4ZW50ZXN0KSAoZ2Nj
IHZlcnNpb24gNC40LjUgKERlYmlhbiA0LjQuNS04KSApICM2NiBTTVAgUFJFRU1QVCBNb24g
U2VwIDMgMjA6MDU6NTAgQ0VTVCAyMDEyDQpbICAgIDAuMDAwMDAwXSBDb21tYW5kIGxpbmU6
IHJvb3Q9L2Rldi9zZGExIHJvIHZlcmJvc2UgbWVtPTEwMjRNIGNvbnNvbGU9aHZjMCBjb25z
b2xlPXR0eTAgbm9tb2Rlc2V0IHZnYT0zMDMgZWFybHlwcmludGs9eGVuIG1heF9sb29wPTUw
IGxvb3BfbWF4X3BhcnQ9MTAgZGVidWcgbG9nbGV2ZWw9MTANClsgICAgMC4wMDAwMDBdIEZy
ZWVpbmcgOWUtMTAwIHBmbiByYW5nZTogOTggcGFnZXMgZnJlZWQNClsgICAgMC4wMDAwMDBd
IFJlbGVhc2VkIDk4IHBhZ2VzIG9mIHVudXNlZCBtZW1vcnkNClsgICAgMC4wMDAwMDBdIFNl
dCA1Mjg4ODIgcGFnZShzKSB0byAxLTEgbWFwcGluZw0KWyAgICAwLjAwMDAwMF0gUG9wdWxh
dGluZyA0MDAwMC00MDA2MiBwZm4gcmFuZ2U6IDk4IHBhZ2VzIGFkZGVkDQpbICAgIDAuMDAw
MDAwXSBlODIwOiBCSU9TLXByb3ZpZGVkIHBoeXNpY2FsIFJBTSBtYXA6DQpbICAgIDAuMDAw
MDAwXSBYZW46IFttZW0gMHgwMDAwMDAwMDAwMDAwMDAwLTB4MDAwMDAwMDAwMDA5ZGZmZl0g
dXNhYmxlDQpbICAgIDAuMDAwMDAwXSBYZW46IFttZW0gMHgwMDAwMDAwMDAwMDllODAwLTB4
MDAwMDAwMDAwMDBmZmZmZl0gcmVzZXJ2ZWQNClsgICAgMC4wMDAwMDBdIFhlbjogW21lbSAw
eDAwMDAwMDAwMDAxMDAwMDAtMHgwMDAwMDAwMDQwMDYxZmZmXSB1c2FibGUNClsgICAgMC4w
MDAwMDBdIFhlbjogW21lbSAweDAwMDAwMDAwNDAwNjIwMDAtMHgwMDAwMDAwMDdlZTZmZmZm
XSB1bnVzYWJsZQ0KWyAgICAwLjAwMDAwMF0gWGVuOiBbbWVtIDB4MDAwMDAwMDA3ZWU3MDAw
MC0weDAwMDAwMDAwN2VlN2RmZmZdIEFDUEkgZGF0YQ0KWyAgICAwLjAwMDAwMF0gWGVuOiBb
bWVtIDB4MDAwMDAwMDA3ZWU3ZTAwMC0weDAwMDAwMDAwN2VlY2ZmZmZdIEFDUEkgTlZTDQpb
ICAgIDAuMDAwMDAwXSBYZW46IFttZW0gMHgwMDAwMDAwMDdlZWQwMDAwLTB4MDAwMDAwMDA3
ZWVmZmZmZl0gcmVzZXJ2ZWQNClsgICAgMC4wMDAwMDBdIFhlbjogW21lbSAweDAwMDAwMDAw
ZmVjMDAwMDAtMHgwMDAwMDAwMGZlYzAwZmZmXSByZXNlcnZlZA0KWyAgICAwLjAwMDAwMF0g
WGVuOiBbbWVtIDB4MDAwMDAwMDBmZWQwMDAwMC0weDAwMDAwMDAwZmVkMDEwZmZdIHJlc2Vy
dmVkDQpbICAgIDAuMDAwMDAwXSBYZW46IFttZW0gMHgwMDAwMDAwMGZlZDAyMDAwLTB4MDAw
MDAwMDBmZWQxNGJmZl0gcmVzZXJ2ZWQNClsgICAgMC4wMDAwMDBdIFhlbjogW21lbSAweDAw
MDAwMDAwZmVkMjAwMDAtMHgwMDAwMDAwMGZlZDNmZmZmXSByZXNlcnZlZA0KWyAgICAwLjAw
MDAwMF0gWGVuOiBbbWVtIDB4MDAwMDAwMDBmZWUwMDAwMC0weDAwMDAwMDAwZmVlMDBmZmZd
IHJlc2VydmVkDQpbICAgIDAuMDAwMDAwXSBYZW46IFttZW0gMHgwMDAwMDAwMGZmZTAwMDAw
LTB4MDAwMDAwMDBmZmZmZmZmZl0gcmVzZXJ2ZWQNClsgICAgMC4wMDAwMDBdIGJvb3Rjb25z
b2xlIFt4ZW5ib290MF0gZW5hYmxlZA0KWyAgICAwLjAwMDAwMF0gTlggKEV4ZWN1dGUgRGlz
YWJsZSkgcHJvdGVjdGlvbjogYWN0aXZlDQpbICAgIDAuMDAwMDAwXSBlODIwOiB1c2VyLWRl
ZmluZWQgcGh5c2ljYWwgUkFNIG1hcDoNClsgICAgMC4wMDAwMDBdIHVzZXI6IFttZW0gMHgw
MDAwMDAwMDAwMDAwMDAwLTB4MDAwMDAwMDAwMDA5ZGZmZl0gdXNhYmxlDQpbICAgIDAuMDAw
MDAwXSB1c2VyOiBbbWVtIDB4MDAwMDAwMDAwMDA5ZTgwMC0weDAwMDAwMDAwMDAwZmZmZmZd
IHJlc2VydmVkDQpbICAgIDAuMDAwMDAwXSB1c2VyOiBbbWVtIDB4MDAwMDAwMDAwMDEwMDAw
MC0weDAwMDAwMDAwM2ZmZmZmZmZdIHVzYWJsZQ0KWyAgICAwLjAwMDAwMF0gdXNlcjogW21l
bSAweDAwMDAwMDAwNDAwNjIwMDAtMHgwMDAwMDAwMDdlZTZmZmZmXSB1bnVzYWJsZQ0KWyAg
ICAwLjAwMDAwMF0gdXNlcjogW21lbSAweDAwMDAwMDAwN2VlNzAwMDAtMHgwMDAwMDAwMDdl
ZTdkZmZmXSBBQ1BJIGRhdGENClsgICAgMC4wMDAwMDBdIHVzZXI6IFttZW0gMHgwMDAwMDAw
MDdlZTdlMDAwLTB4MDAwMDAwMDA3ZWVjZmZmZl0gQUNQSSBOVlMNClsgICAgMC4wMDAwMDBd
IHVzZXI6IFttZW0gMHgwMDAwMDAwMDdlZWQwMDAwLTB4MDAwMDAwMDA3ZWVmZmZmZl0gcmVz
ZXJ2ZWQNClsgICAgMC4wMDAwMDBdIHVzZXI6IFttZW0gMHgwMDAwMDAwMGZlYzAwMDAwLTB4
MDAwMDAwMDBmZWMwMGZmZl0gcmVzZXJ2ZWQNClsgICAgMC4wMDAwMDBdIHVzZXI6IFttZW0g
MHgwMDAwMDAwMGZlZDAwMDAwLTB4MDAwMDAwMDBmZWQwMTBmZl0gcmVzZXJ2ZWQNClsgICAg
MC4wMDAwMDBdIHVzZXI6IFttZW0gMHgwMDAwMDAwMGZlZDAyMDAwLTB4MDAwMDAwMDBmZWQx
NGJmZl0gcmVzZXJ2ZWQNClsgICAgMC4wMDAwMDBdIHVzZXI6IFttZW0gMHgwMDAwMDAwMGZl
ZDIwMDAwLTB4MDAwMDAwMDBmZWQzZmZmZl0gcmVzZXJ2ZWQNClsgICAgMC4wMDAwMDBdIHVz
ZXI6IFttZW0gMHgwMDAwMDAwMGZlZTAwMDAwLTB4MDAwMDAwMDBmZWUwMGZmZl0gcmVzZXJ2
ZWQNClsgICAgMC4wMDAwMDBdIHVzZXI6IFttZW0gMHgwMDAwMDAwMGZmZTAwMDAwLTB4MDAw
MDAwMDBmZmZmZmZmZl0gcmVzZXJ2ZWQNClsgICAgMC4wMDAwMDBdIERNSSBwcmVzZW50Lg0K
WyAgICAwLjAwMDAwMF0gRE1JOiBTeXN0ZW0gbWFudWZhY3R1cmVyIFN5c3RlbSBQcm9kdWN0
IE5hbWUvUDVRLUVNIERPLCBCSU9TIDEyMDggICAgMDUvMjUvMjAxMA0KWyAgICAwLjAwMDAw
MF0gZTgyMDogdXBkYXRlIFttZW0gMHgwMDAwMDAwMC0weDAwMDBmZmZmXSB1c2FibGUgPT0+
IHJlc2VydmVkDQpbICAgIDAuMDAwMDAwXSBlODIwOiByZW1vdmUgW21lbSAweDAwMGEwMDAw
LTB4MDAwZmZmZmZdIHVzYWJsZQ0KWyAgICAwLjAwMDAwMF0gTm8gQUdQIGJyaWRnZSBmb3Vu
ZA0KWyAgICAwLjAwMDAwMF0gZTgyMDogbGFzdF9wZm4gPSAweDQwMDAwIG1heF9hcmNoX3Bm
biA9IDB4NDAwMDAwMDAwDQpbICAgIDAuMDAwMDAwXSBmb3VuZCBTTVAgTVAtdGFibGUgYXQg
W21lbSAweDAwMGZmNzgwLTB4MDAwZmY3OGZdIG1hcHBlZCBhdCBbZmZmZjg4MDAwMDBmZjc4
MF0NClsgICAgMC4wMDAwMDBdIGluaXRpYWwgbWVtb3J5IG1hcHBlZDogW21lbSAweDAwMDAw
MDAwLTB4MDMxNGVmZmZdDQpbICAgIDAuMDAwMDAwXSBCYXNlIG1lbW9yeSB0cmFtcG9saW5l
IGF0IFtmZmZmODgwMDAwMDk4MDAwXSA5ODAwMCBzaXplIDI0NTc2DQpbICAgIDAuMDAwMDAw
XSBpbml0X21lbW9yeV9tYXBwaW5nOiBbbWVtIDB4MDAwMDAwMDAtMHgzZmZmZmZmZl0NClsg
ICAgMC4wMDAwMDBdICBbbWVtIDB4MDAwMDAwMDAtMHgzZmZmZmZmZl0gcGFnZSA0aw0KWyAg
ICAwLjAwMDAwMF0ga2VybmVsIGRpcmVjdCBtYXBwaW5nIHRhYmxlcyB1cCB0byAweDNmZmZm
ZmZmIEAgW21lbSAweDAyYWQ2MDAwLTB4MDJjZDdmZmZdDQpbICAgIDAuMDAwMDAwXSB4ZW46
IHNldHRpbmcgUlcgdGhlIHJhbmdlIDJjYjgwMDAgLSAyY2Q4MDAwDQpbICAgIDAuMDAwMDAw
XSBSQU1ESVNLOiBbbWVtIDB4MDJjZDgwMDAtMHgwMzE0ZWZmZl0NClsgICAgMC4wMDAwMDBd
IEFDUEk6IFJTRFAgMDAwMDAwMDAwMDBmYjA4MCAwMDAyNCAodjAyIEFDUElBTSkNClsgICAg
MC4wMDAwMDBdIEFDUEk6IFhTRFQgMDAwMDAwMDA3ZWU3MDEwMCAwMDA1QyAodjAxIEFfTV9J
XyBPRU1YU0RUICAwNTAwMTAyNSBNU0ZUIDAwMDAwMDk3KQ0KWyAgICAwLjAwMDAwMF0gQUNQ
STogRkFDUCAwMDAwMDAwMDdlZTcwMjkwIDAwMEY0ICh2MDMgQV9NX0lfIE9FTUZBQ1AgIDA1
MDAxMDI1IE1TRlQgMDAwMDAwOTcpDQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBEU0RUIDAwMDAw
MDAwN2VlNzA0NDAgMDg0MUYgKHYwMSAgQTEwNjUgQTEwNjUwMDAgMDAwMDAwMDAgSU5UTCAy
MDA2MDExMykNClsgICAgMC4wMDAwMDBdIEFDUEk6IEZBQ1MgMDAwMDAwMDA3ZWU3ZTAwMCAw
MDA0MA0KWyAgICAwLjAwMDAwMF0gQUNQSTogQVBJQyAwMDAwMDAwMDdlZTcwMzkwIDAwMDZD
ICh2MDEgQV9NX0lfIE9FTUFQSUMgIDA1MDAxMDI1IE1TRlQgMDAwMDAwOTcpDQpbICAgIDAu
MDAwMDAwXSBBQ1BJOiBNQ0ZHIDAwMDAwMDAwN2VlNzA0MDAgMDAwM0MgKHYwMSBBX01fSV8g
T0VNTUNGRyAgMDUwMDEwMjUgTVNGVCAwMDAwMDA5NykNClsgICAgMC4wMDAwMDBdIEFDUEk6
IE9FTUIgMDAwMDAwMDA3ZWU3ZTA0MCAwMDA4OSAodjAxIEFfTV9JXyBBTUlfT0VNICAwNTAw
MTAyNSBNU0ZUIDAwMDAwMDk3KQ0KWyAgICAwLjAwMDAwMF0gQUNQSTogSFBFVCAwMDAwMDAw
MDdlZTc4ODYwIDAwMDM4ICh2MDEgQV9NX0lfIE9FTUhQRVQgIDA1MDAxMDI1IE1TRlQgMDAw
MDAwOTcpDQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBHU0NJIDAwMDAwMDAwN2VlN2UwZDAgMDIw
MjQgKHYwMSBBX01fSV8gR01DSFNDSSAgMDUwMDEwMjUgTVNGVCAwMDAwMDA5NykNClsgICAg
MC4wMDAwMDBdIEFDUEk6IFNTRFQgMDAwMDAwMDA3ZWU4MGEwMCAwMEE3QyAodjAxIERwZ1Bt
bSAgICBDcHVQbSAwMDAwMDAxMiBJTlRMIDIwMDYwMTEzKQ0KWyAgICAwLjAwMDAwMF0gQUNQ
STogTG9jYWwgQVBJQyBhZGRyZXNzIDB4ZmVlMDAwMDANClsgICAgMC4wMDAwMDBdIE5vIE5V
TUEgY29uZmlndXJhdGlvbiBmb3VuZA0KWyAgICAwLjAwMDAwMF0gRmFraW5nIGEgbm9kZSBh
dCBbbWVtIDB4MDAwMDAwMDAwMDAwMDAwMC0weDAwMDAwMDAwM2ZmZmZmZmZdDQpbICAgIDAu
MDAwMDAwXSBJbml0bWVtIHNldHVwIG5vZGUgMCBbbWVtIDB4MDAwMDAwMDAtMHgzZmZmZmZm
Zl0NClsgICAgMC4wMDAwMDBdICAgTk9ERV9EQVRBIFttZW0gMHgzZmZmNTAwMC0weDNmZmZm
ZmZmXQ0KWyAgICAwLjAwMDAwMF0gWm9uZSByYW5nZXM6DQpbICAgIDAuMDAwMDAwXSAgIERN
QSAgICAgIFttZW0gMHgwMDAxMDAwMC0weDAwZmZmZmZmXQ0KWyAgICAwLjAwMDAwMF0gICBE
TUEzMiAgICBbbWVtIDB4MDEwMDAwMDAtMHhmZmZmZmZmZl0NClsgICAgMC4wMDAwMDBdICAg
Tm9ybWFsICAgZW1wdHkNClsgICAgMC4wMDAwMDBdIE1vdmFibGUgem9uZSBzdGFydCBmb3Ig
ZWFjaCBub2RlDQpbICAgIDAuMDAwMDAwXSBFYXJseSBtZW1vcnkgbm9kZSByYW5nZXMNClsg
ICAgMC4wMDAwMDBdICAgbm9kZSAgIDA6IFttZW0gMHgwMDAxMDAwMC0weDAwMDlkZmZmXQ0K
WyAgICAwLjAwMDAwMF0gICBub2RlICAgMDogW21lbSAweDAwMTAwMDAwLTB4M2ZmZmZmZmZd
DQpbICAgIDAuMDAwMDAwXSBPbiBub2RlIDAgdG90YWxwYWdlczogMjYyMDMwDQpbICAgIDAu
MDAwMDAwXSAgIERNQSB6b25lOiA2NCBwYWdlcyB1c2VkIGZvciBtZW1tYXANClsgICAgMC4w
MDAwMDBdICAgRE1BIHpvbmU6IDYgcGFnZXMgcmVzZXJ2ZWQNClsgICAgMC4wMDAwMDBdICAg
RE1BIHpvbmU6IDM5MTIgcGFnZXMsIExJRk8gYmF0Y2g6MA0KWyAgICAwLjAwMDAwMF0gICBE
TUEzMiB6b25lOiA0MDMyIHBhZ2VzIHVzZWQgZm9yIG1lbW1hcA0KWyAgICAwLjAwMDAwMF0g
ICBETUEzMiB6b25lOiAyNTQwMTYgcGFnZXMsIExJRk8gYmF0Y2g6MzENClsgICAgMC4wMDAw
MDBdIEFDUEk6IFBNLVRpbWVyIElPIFBvcnQ6IDB4ODA4DQpbICAgIDAuMDAwMDAwXSBBQ1BJ
OiBMb2NhbCBBUElDIGFkZHJlc3MgMHhmZWUwMDAwMA0KWyAgICAwLjAwMDAwMF0gQUNQSTog
TEFQSUMgKGFjcGlfaWRbMHgwMV0gbGFwaWNfaWRbMHgwMF0gZW5hYmxlZCkNClsgICAgMC4w
MDAwMDBdIEFDUEk6IExBUElDIChhY3BpX2lkWzB4MDJdIGxhcGljX2lkWzB4MDFdIGVuYWJs
ZWQpDQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBMQVBJQyAoYWNwaV9pZFsweDAzXSBsYXBpY19p
ZFsweDAyXSBlbmFibGVkKQ0KWyAgICAwLjAwMDAwMF0gQUNQSTogTEFQSUMgKGFjcGlfaWRb
MHgwNF0gbGFwaWNfaWRbMHgwM10gZW5hYmxlZCkNClsgICAgMC4wMDAwMDBdIEFDUEk6IElP
QVBJQyAoaWRbMHgwNF0gYWRkcmVzc1sweGZlYzAwMDAwXSBnc2lfYmFzZVswXSkNClsgICAg
MC4wMDAwMDBdIElPQVBJQ1swXTogYXBpY19pZCA0LCB2ZXJzaW9uIDMyLCBhZGRyZXNzIDB4
ZmVjMDAwMDAsIEdTSSAwLTIzDQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBJTlRfU1JDX09WUiAo
YnVzIDAgYnVzX2lycSAwIGdsb2JhbF9pcnEgMiBkZmwgZGZsKQ0KWyAgICAwLjAwMDAwMF0g
QUNQSTogSU5UX1NSQ19PVlIgKGJ1cyAwIGJ1c19pcnEgOSBnbG9iYWxfaXJxIDkgaGlnaCBs
ZXZlbCkNClsgICAgMC4wMDAwMDBdIEFDUEk6IElSUTAgdXNlZCBieSBvdmVycmlkZS4NClsg
ICAgMC4wMDAwMDBdIEFDUEk6IElSUTIgdXNlZCBieSBvdmVycmlkZS4NClsgICAgMC4wMDAw
MDBdIEFDUEk6IElSUTkgdXNlZCBieSBvdmVycmlkZS4NClsgICAgMC4wMDAwMDBdIFVzaW5n
IEFDUEkgKE1BRFQpIGZvciBTTVAgY29uZmlndXJhdGlvbiBpbmZvcm1hdGlvbg0KWyAgICAw
LjAwMDAwMF0gQUNQSTogSFBFVCBpZDogMHg4MDg2YTcwMSBiYXNlOiAweGZlZDAwMDAwDQpb
ICAgIDAuMDAwMDAwXSBzbXBib290OiBBbGxvd2luZyA0IENQVXMsIDAgaG90cGx1ZyBDUFVz
DQpbICAgIDAuMDAwMDAwXSBucl9pcnFzX2dzaTogNDANClsgICAgMC4wMDAwMDBdIGU4MjA6
IFttZW0gMHg3ZWYwMDAwMC0weGZlYmZmZmZmXSBhdmFpbGFibGUgZm9yIFBDSSBkZXZpY2Vz
DQpbICAgIDAuMDAwMDAwXSBCb290aW5nIHBhcmF2aXJ0dWFsaXplZCBrZXJuZWwgb24gWGVu
DQpbICAgIDAuMDAwMDAwXSBYZW4gdmVyc2lvbjogNC4yLjAtcmM0LXByZSAocHJlc2VydmUt
QUQpDQpbICAgIDAuMDAwMDAwXSBzZXR1cF9wZXJjcHU6IE5SX0NQVVM6OCBucl9jcHVtYXNr
X2JpdHM6OCBucl9jcHVfaWRzOjQgbnJfbm9kZV9pZHM6MQ0KWyAgICAwLjAwMDAwMF0gUEVS
Q1BVOiBFbWJlZGRlZCAyNyBwYWdlcy9jcHUgQGZmZmY4ODAwM2ZjMDAwMDAgczgwODk2IHI4
MTkyIGQyMTUwNCB1NTI0Mjg4DQpbICAgIDAuMDAwMDAwXSBwY3B1LWFsbG9jOiBzODA4OTYg
cjgxOTIgZDIxNTA0IHU1MjQyODggYWxsb2M9MSoyMDk3MTUyDQpbICAgIDAuMDAwMDAwXSBw
Y3B1LWFsbG9jOiBbMF0gMCAxIDIgMyANClsgICAgMC4wMDAwMDBdIEJ1aWx0IDEgem9uZWxp
c3RzIGluIE5vZGUgb3JkZXIsIG1vYmlsaXR5IGdyb3VwaW5nIG9uLiAgVG90YWwgcGFnZXM6
IDI1NzkyOA0KWyAgICAwLjAwMDAwMF0gUG9saWN5IHpvbmU6IERNQTMyDQpbICAgIDAuMDAw
MDAwXSBLZXJuZWwgY29tbWFuZCBsaW5lOiByb290PS9kZXYvc2RhMSBybyB2ZXJib3NlIG1l
bT0xMDI0TSBjb25zb2xlPWh2YzAgY29uc29sZT10dHkwIG5vbW9kZXNldCB2Z2E9MzAzIGVh
cmx5cHJpbnRrPXhlbiBtYXhfbG9vcD01MCBsb29wX21heF9wYXJ0PTEwIGRlYnVnIGxvZ2xl
dmVsPTEwDQpbICAgIDAuMDAwMDAwXSBQSUQgaGFzaCB0YWJsZSBlbnRyaWVzOiA0MDk2IChv
cmRlcjogMywgMzI3NjggYnl0ZXMpDQpbICAgIDAuMDAwMDAwXSBfX2V4X3RhYmxlIGFscmVh
ZHkgc29ydGVkLCBza2lwcGluZyBzb3J0DQpbICAgIDAuMDAwMDAwXSB4c2F2ZTogZW5hYmxl
ZCB4c3RhdGVfYnYgMHgzLCBjbnR4dCBzaXplIDB4MjQwDQpbICAgIDAuMDAwMDAwXSBzb2Z0
d2FyZSBJTyBUTEIgW21lbSAweDNhNjAwMDAwLTB4M2U1ZmZmZmZdICg2NE1CKSBtYXBwZWQg
YXQgW2ZmZmY4ODAwM2E2MDAwMDAtZmZmZjg4MDAzZTVmZmZmZl0NClsgICAgMC4wMDAwMDBd
IE1lbW9yeTogOTMxMDI0ay8xMDQ4NTc2ayBhdmFpbGFibGUgKDg1MTFrIGtlcm5lbCBjb2Rl
LCA0NTZrIGFic2VudCwgMTE3MDk2ayByZXNlcnZlZCwgNjcwNGsgZGF0YSwgNjcyayBpbml0
KQ0KWyAgICAwLjAwMDAwMF0gU0xVQjogR2Vuc2xhYnM9MTUsIEhXYWxpZ249NjQsIE9yZGVy
PTAtMywgTWluT2JqZWN0cz0wLCBDUFVzPTQsIE5vZGVzPTENClsgICAgMC4wMDAwMDBdIFBy
ZWVtcHRpYmxlIGhpZXJhcmNoaWNhbCBSQ1UgaW1wbGVtZW50YXRpb24uDQpbICAgIDAuMDAw
MDAwXSAJUkNVIGR5bnRpY2staWRsZSBncmFjZS1wZXJpb2QgYWNjZWxlcmF0aW9uIGlzIGVu
YWJsZWQuDQpbICAgIDAuMDAwMDAwXSAJQWRkaXRpb25hbCBwZXItQ1BVIGluZm8gcHJpbnRl
ZCB3aXRoIHN0YWxscy4NClsgICAgMC4wMDAwMDBdIAlSQ1UgcmVzdHJpY3RpbmcgQ1BVcyBm
cm9tIE5SX0NQVVM9OCB0byBucl9jcHVfaWRzPTQuDQpbICAgIDAuMDAwMDAwXSBOUl9JUlFT
OjQzNTIgbnJfaXJxczo3MTIgMTYNClsgICAgMC4wMDAwMDBdIHhlbjogc2NpIG92ZXJyaWRl
OiBnbG9iYWxfaXJxPTkgdHJpZ2dlcj0wIHBvbGFyaXR5PTANClsgICAgMC4wMDAwMDBdIHhl
bjogcmVnaXN0ZXJpbmcgZ3NpIDkgdHJpZ2dlcmluZyAwIHBvbGFyaXR5IDANClsgICAgMC4w
MDAwMDBdIHhlbjogLS0+IHBpcnE9OSAtPiBpcnE9OSAoZ3NpPTkpDQooWEVOKSBbMjAxMi0w
OS0wNCAxNjo0MDo0NV0gSU9BUElDWzBdOiBTZXQgUENJIHJvdXRpbmcgZW50cnkgKDQtOSAt
PiAweDU4IC0+IElSUSA5IE1vZGU6MSBBY3RpdmU6MCkNClsgICAgMC4wMDAwMDBdIHhlbjog
YWNwaSBzY2kgOQ0KWyAgICAwLjAwMDAwMF0geGVuOiAtLT4gcGlycT0xIC0+IGlycT0xIChn
c2k9MSkNClsgICAgMC4wMDAwMDBdIHhlbjogLS0+IHBpcnE9MiAtPiBpcnE9MiAoZ3NpPTIp
DQpbICAgIDAuMDAwMDAwXSB4ZW46IC0tPiBwaXJxPTMgLT4gaXJxPTMgKGdzaT0zKQ0KWyAg
ICAwLjAwMDAwMF0geGVuOiAtLT4gcGlycT00IC0+IGlycT00IChnc2k9NCkNClsgICAgMC4w
MDAwMDBdIHhlbjogLS0+IHBpcnE9NSAtPiBpcnE9NSAoZ3NpPTUpDQpbICAgIDAuMDAwMDAw
XSB4ZW46IC0tPiBwaXJxPTYgLT4gaXJxPTYgKGdzaT02KQ0KWyAgICAwLjAwMDAwMF0geGVu
OiAtLT4gcGlycT03IC0+IGlycT03IChnc2k9NykNClsgICAgMC4wMDAwMDBdIHhlbjogLS0+
IHBpcnE9OCAtPiBpcnE9OCAoZ3NpPTgpDQpbICAgIDAuMDAwMDAwXSB4ZW46IC0tPiBwaXJx
PTEwIC0+IGlycT0xMCAoZ3NpPTEwKQ0KWyAgICAwLjAwMDAwMF0geGVuOiAtLT4gcGlycT0x
MSAtPiBpcnE9MTEgKGdzaT0xMSkNClsgICAgMC4wMDAwMDBdIHhlbjogLS0+IHBpcnE9MTIg
LT4gaXJxPTEyIChnc2k9MTIpDQpbICAgIDAuMDAwMDAwXSB4ZW46IC0tPiBwaXJxPTEzIC0+
IGlycT0xMyAoZ3NpPTEzKQ0KWyAgICAwLjAwMDAwMF0geGVuOiAtLT4gcGlycT0xNCAtPiBp
cnE9MTQgKGdzaT0xNCkNClsgICAgMC4wMDAwMDBdIHhlbjogLS0+IHBpcnE9MTUgLT4gaXJx
PTE1IChnc2k9MTUpDQpbICAgIDAuMDAwMDAwXSBDb25zb2xlOiBjb2xvdXIgZHVtbXkgZGV2
aWNlIDgweDI1DQpbICAgIDAuMDAwMDAwXSBjb25zb2xlIFt0dHkwXSBlbmFibGVkLCBib290
Y29uc29sZSBkaXNhYmxlZA0KWyAgICAwLjAwMDAwMF0gSW5pdGlhbGl6aW5nIGNncm91cCBz
dWJzeXMgY3B1c2V0DQpbICAgIDAuMDAwMDAwXSBJbml0aWFsaXppbmcgY2dyb3VwIHN1YnN5
cyBjcHUNClsgICAgMC4wMDAwMDBdIExpbnV4IHZlcnNpb24gMy42LjAtcmM0LTIwMTIwODMw
KyAocm9vdEB4ZW50ZXN0KSAoZ2NjIHZlcnNpb24gNC40LjUgKERlYmlhbiA0LjQuNS04KSAp
ICM2NiBTTVAgUFJFRU1QVCBNb24gU2VwIDMgMjA6MDU6NTAgQ0VTVCAyMDEyDQpbICAgIDAu
MDAwMDAwXSBDb21tYW5kIGxpbmU6IHJvb3Q9L2Rldi9zZGExIHJvIHZlcmJvc2UgbWVtPTEw
MjRNIGNvbnNvbGU9aHZjMCBjb25zb2xlPXR0eTAgbm9tb2Rlc2V0IHZnYT0zMDMgZWFybHlw
cmludGs9eGVuIG1heF9sb29wPTUwIGxvb3BfbWF4X3BhcnQ9MTAgZGVidWcgbG9nbGV2ZWw9
MTANClsgICAgMC4wMDAwMDBdIEZyZWVpbmcgOWUtMTAwIHBmbiByYW5nZTogOTggcGFnZXMg
ZnJlZWQNClsgICAgMC4wMDAwMDBdIDEtMSBtYXBwaW5nIG9uIDllLT4xMDANClsgICAgMC4w
MDAwMDBdIDEtMSBtYXBwaW5nIG9uIDdlZTcwLT4xMDAwMDANClsgICAgMC4wMDAwMDBdIFJl
bGVhc2VkIDk4IHBhZ2VzIG9mIHVudXNlZCBtZW1vcnkNClsgICAgMC4wMDAwMDBdIFNldCA1
Mjg4ODIgcGFnZShzKSB0byAxLTEgbWFwcGluZw0KWyAgICAwLjAwMDAwMF0gUG9wdWxhdGlu
ZyA0MDAwMC00MDA2MiBwZm4gcmFuZ2U6IDk4IHBhZ2VzIGFkZGVkDQpbICAgIDAuMDAwMDAw
XSBlODIwOiBCSU9TLXByb3ZpZGVkIHBoeXNpY2FsIFJBTSBtYXA6DQpbICAgIDAuMDAwMDAw
XSBYZW46IFttZW0gMHgwMDAwMDAwMDAwMDAwMDAwLTB4MDAwMDAwMDAwMDA5ZGZmZl0gdXNh
YmxlDQpbICAgIDAuMDAwMDAwXSBYZW46IFttZW0gMHgwMDAwMDAwMDAwMDllODAwLTB4MDAw
MDAwMDAwMDBmZmZmZl0gcmVzZXJ2ZWQNClsgICAgMC4wMDAwMDBdIFhlbjogW21lbSAweDAw
MDAwMDAwMDAxMDAwMDAtMHgwMDAwMDAwMDQwMDYxZmZmXSB1c2FibGUNClsgICAgMC4wMDAw
MDBdIFhlbjogW21lbSAweDAwMDAwMDAwNDAwNjIwMDAtMHgwMDAwMDAwMDdlZTZmZmZmXSB1
bnVzYWJsZQ0KWyAgICAwLjAwMDAwMF0gWGVuOiBbbWVtIDB4MDAwMDAwMDA3ZWU3MDAwMC0w
eDAwMDAwMDAwN2VlN2RmZmZdIEFDUEkgZGF0YQ0KWyAgICAwLjAwMDAwMF0gWGVuOiBbbWVt
IDB4MDAwMDAwMDA3ZWU3ZTAwMC0weDAwMDAwMDAwN2VlY2ZmZmZdIEFDUEkgTlZTDQpbICAg
IDAuMDAwMDAwXSBYZW46IFttZW0gMHgwMDAwMDAwMDdlZWQwMDAwLTB4MDAwMDAwMDA3ZWVm
ZmZmZl0gcmVzZXJ2ZWQNClsgICAgMC4wMDAwMDBdIFhlbjogW21lbSAweDAwMDAwMDAwZmVj
MDAwMDAtMHgwMDAwMDAwMGZlYzAwZmZmXSByZXNlcnZlZA0KWyAgICAwLjAwMDAwMF0gWGVu
OiBbbWVtIDB4MDAwMDAwMDBmZWQwMDAwMC0weDAwMDAwMDAwZmVkMDEwZmZdIHJlc2VydmVk
DQpbICAgIDAuMDAwMDAwXSBYZW46IFttZW0gMHgwMDAwMDAwMGZlZDAyMDAwLTB4MDAwMDAw
MDBmZWQxNGJmZl0gcmVzZXJ2ZWQNClsgICAgMC4wMDAwMDBdIFhlbjogW21lbSAweDAwMDAw
MDAwZmVkMjAwMDAtMHgwMDAwMDAwMGZlZDNmZmZmXSByZXNlcnZlZA0KWyAgICAwLjAwMDAw
MF0gWGVuOiBbbWVtIDB4MDAwMDAwMDBmZWUwMDAwMC0weDAwMDAwMDAwZmVlMDBmZmZdIHJl
c2VydmVkDQpbICAgIDAuMDAwMDAwXSBYZW46IFttZW0gMHgwMDAwMDAwMGZmZTAwMDAwLTB4
MDAwMDAwMDBmZmZmZmZmZl0gcmVzZXJ2ZWQNClsgICAgMC4wMDAwMDBdIGU4MjA6IHJlbW92
ZSBbbWVtIDB4NDAwMDAwMDAtMHhmZmZmZmZmZmZmZmZmZmZlXSB1c2FibGUNClsgICAgMC4w
MDAwMDBdIGJvb3Rjb25zb2xlIFt4ZW5ib290MF0gZW5hYmxlZA0KWyAgICAwLjAwMDAwMF0g
TlggKEV4ZWN1dGUgRGlzYWJsZSkgcHJvdGVjdGlvbjogYWN0aXZlDQpbICAgIDAuMDAwMDAw
XSBlODIwOiB1c2VyLWRlZmluZWQgcGh5c2ljYWwgUkFNIG1hcDoNClsgICAgMC4wMDAwMDBd
IHVzZXI6IFttZW0gMHgwMDAwMDAwMDAwMDAwMDAwLTB4MDAwMDAwMDAwMDA5ZGZmZl0gdXNh
YmxlDQpbICAgIDAuMDAwMDAwXSB1c2VyOiBbbWVtIDB4MDAwMDAwMDAwMDA5ZTgwMC0weDAw
MDAwMDAwMDAwZmZmZmZdIHJlc2VydmVkDQpbICAgIDAuMDAwMDAwXSB1c2VyOiBbbWVtIDB4
MDAwMDAwMDAwMDEwMDAwMC0weDAwMDAwMDAwM2ZmZmZmZmZdIHVzYWJsZQ0KWyAgICAwLjAw
MDAwMF0gdXNlcjogW21lbSAweDAwMDAwMDAwNDAwNjIwMDAtMHgwMDAwMDAwMDdlZTZmZmZm
XSB1bnVzYWJsZQ0KWyAgICAwLjAwMDAwMF0gdXNlcjogW21lbSAweDAwMDAwMDAwN2VlNzAw
MDAtMHgwMDAwMDAwMDdlZTdkZmZmXSBBQ1BJIGRhdGENClsgICAgMC4wMDAwMDBdIHVzZXI6
IFttZW0gMHgwMDAwMDAwMDdlZTdlMDAwLTB4MDAwMDAwMDA3ZWVjZmZmZl0gQUNQSSBOVlMN
ClsgICAgMC4wMDAwMDBdIHVzZXI6IFttZW0gMHgwMDAwMDAwMDdlZWQwMDAwLTB4MDAwMDAw
MDA3ZWVmZmZmZl0gcmVzZXJ2ZWQNClsgICAgMC4wMDAwMDBdIHVzZXI6IFttZW0gMHgwMDAw
MDAwMGZlYzAwMDAwLTB4MDAwMDAwMDBmZWMwMGZmZl0gcmVzZXJ2ZWQNClsgICAgMC4wMDAw
MDBdIHVzZXI6IFttZW0gMHgwMDAwMDAwMGZlZDAwMDAwLTB4MDAwMDAwMDBmZWQwMTBmZl0g
cmVzZXJ2ZWQNClsgICAgMC4wMDAwMDBdIHVzZXI6IFttZW0gMHgwMDAwMDAwMGZlZDAyMDAw
LTB4MDAwMDAwMDBmZWQxNGJmZl0gcmVzZXJ2ZWQNClsgICAgMC4wMDAwMDBdIHVzZXI6IFtt
ZW0gMHgwMDAwMDAwMGZlZDIwMDAwLTB4MDAwMDAwMDBmZWQzZmZmZl0gcmVzZXJ2ZWQNClsg
ICAgMC4wMDAwMDBdIHVzZXI6IFttZW0gMHgwMDAwMDAwMGZlZTAwMDAwLTB4MDAwMDAwMDBm
ZWUwMGZmZl0gcmVzZXJ2ZWQNClsgICAgMC4wMDAwMDBdIHVzZXI6IFttZW0gMHgwMDAwMDAw
MGZmZTAwMDAwLTB4MDAwMDAwMDBmZmZmZmZmZl0gcmVzZXJ2ZWQNClsgICAgMC4wMDAwMDBd
IERNSSBwcmVzZW50Lg0KWyAgICAwLjAwMDAwMF0gRE1JOiBTeXN0ZW0gbWFudWZhY3R1cmVy
IFN5c3RlbSBQcm9kdWN0IE5hbWUvUDVRLUVNIERPLCBCSU9TIDEyMDggICAgMDUvMjUvMjAx
MA0KWyAgICAwLjAwMDAwMF0gZTgyMDogdXBkYXRlIFttZW0gMHgwMDAwMDAwMC0weDAwMDBm
ZmZmXSB1c2FibGUgPT0+IHJlc2VydmVkDQpbICAgIDAuMDAwMDAwXSBlODIwOiByZW1vdmUg
W21lbSAweDAwMGEwMDAwLTB4MDAwZmZmZmZdIHVzYWJsZQ0KWyAgICAwLjAwMDAwMF0gTm8g
QUdQIGJyaWRnZSBmb3VuZA0KWyAgICAwLjAwMDAwMF0gZTgyMDogbGFzdF9wZm4gPSAweDQw
MDAwIG1heF9hcmNoX3BmbiA9IDB4NDAwMDAwMDAwDQpbICAgIDAuMDAwMDAwXSBmb3VuZCBT
TVAgTVAtdGFibGUgYXQgW21lbSAweDAwMGZmNzgwLTB4MDAwZmY3OGZdIG1hcHBlZCBhdCBb
ZmZmZjg4MDAwMDBmZjc4MF0NClsgICAgMC4wMDAwMDBdIGluaXRpYWwgbWVtb3J5IG1hcHBl
ZDogW21lbSAweDAwMDAwMDAwLTB4MDMxNGVmZmZdDQpbICAgIDAuMDAwMDAwXSBCYXNlIG1l
bW9yeSB0cmFtcG9saW5lIGF0IFtmZmZmODgwMDAwMDk4MDAwXSA5ODAwMCBzaXplIDI0NTc2
DQpbICAgIDAuMDAwMDAwXSBpbml0X21lbW9yeV9tYXBwaW5nOiBbbWVtIDB4MDAwMDAwMDAt
MHgzZmZmZmZmZl0NClsgICAgMC4wMDAwMDBdICBbbWVtIDB4MDAwMDAwMDAtMHgzZmZmZmZm
Zl0gcGFnZSA0aw0KWyAgICAwLjAwMDAwMF0ga2VybmVsIGRpcmVjdCBtYXBwaW5nIHRhYmxl
cyB1cCB0byAweDNmZmZmZmZmIEAgW21lbSAweDAyYWQ2MDAwLTB4MDJjZDdmZmZdDQpbICAg
IDAuMDAwMDAwXSB4ZW46IHNldHRpbmcgUlcgdGhlIHJhbmdlIDJjYjgwMDAgLSAyY2Q4MDAw
DQpbICAgIDAuMDAwMDAwXSBSQU1ESVNLOiBbbWVtIDB4MDJjZDgwMDAtMHgwMzE0ZWZmZl0N
ClsgICAgMC4wMDAwMDBdIEFDUEk6IFJTRFAgMDAwMDAwMDAwMDBmYjA4MCAwMDAyNCAodjAy
IEFDUElBTSkNClsgICAgMC4wMDAwMDBdIEFDUEk6IFhTRFQgMDAwMDAwMDA3ZWU3MDEwMCAw
MDA1QyAodjAxIEFfTV9JXyBPRU1YU0RUICAwNTAwMTAyNSBNU0ZUIDAwMDAwMDk3KQ0KWyAg
ICAwLjAwMDAwMF0gQUNQSTogRkFDUCAwMDAwMDAwMDdlZTcwMjkwIDAwMEY0ICh2MDMgQV9N
X0lfIE9FTUZBQ1AgIDA1MDAxMDI1IE1TRlQgMDAwMDAwOTcpDQpbICAgIDAuMDAwMDAwXSBB
Q1BJOiBEU0RUIDAwMDAwMDAwN2VlNzA0NDAgMDg0MUYgKHYwMSAgQTEwNjUgQTEwNjUwMDAg
MDAwMDAwMDAgSU5UTCAyMDA2MDExMykNClsgICAgMC4wMDAwMDBdIEFDUEk6IEZBQ1MgMDAw
MDAwMDA3ZWU3ZTAwMCAwMDA0MA0KWyAgICAwLjAwMDAwMF0gQUNQSTogQVBJQyAwMDAwMDAw
MDdlZTcwMzkwIDAwMDZDICh2MDEgQV9NX0lfIE9FTUFQSUMgIDA1MDAxMDI1IE1TRlQgMDAw
MDAwOTcpDQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBNQ0ZHIDAwMDAwMDAwN2VlNzA0MDAgMDAw
M0MgKHYwMSBBX01fSV8gT0VNTUNGRyAgMDUwMDEwMjUgTVNGVCAwMDAwMDA5NykNClsgICAg
MC4wMDAwMDBdIEFDUEk6IE9FTUIgMDAwMDAwMDA3ZWU3ZTA0MCAwMDA4OSAodjAxIEFfTV9J
XyBBTUlfT0VNICAwNTAwMTAyNSBNU0ZUIDAwMDAwMDk3KQ0KWyAgICAwLjAwMDAwMF0gQUNQ
STogSFBFVCAwMDAwMDAwMDdlZTc4ODYwIDAwMDM4ICh2MDEgQV9NX0lfIE9FTUhQRVQgIDA1
MDAxMDI1IE1TRlQgMDAwMDAwOTcpDQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBHU0NJIDAwMDAw
MDAwN2VlN2UwZDAgMDIwMjQgKHYwMSBBX01fSV8gR01DSFNDSSAgMDUwMDEwMjUgTVNGVCAw
MDAwMDA5NykNClsgICAgMC4wMDAwMDBdIEFDUEk6IFNTRFQgMDAwMDAwMDA3ZWU4MGEwMCAw
MEE3QyAodjAxIERwZ1BtbSAgICBDcHVQbSAwMDAwMDAxMiBJTlRMIDIwMDYwMTEzKQ0KWyAg
ICAwLjAwMDAwMF0gQUNQSTogTG9jYWwgQVBJQyBhZGRyZXNzIDB4ZmVlMDAwMDANClsgICAg
MC4wMDAwMDBdIE5vIE5VTUEgY29uZmlndXJhdGlvbiBmb3VuZA0KWyAgICAwLjAwMDAwMF0g
RmFraW5nIGEgbm9kZSBhdCBbbWVtIDB4MDAwMDAwMDAwMDAwMDAwMC0weDAwMDAwMDAwM2Zm
ZmZmZmZdDQpbICAgIDAuMDAwMDAwXSBJbml0bWVtIHNldHVwIG5vZGUgMCBbbWVtIDB4MDAw
MDAwMDAtMHgzZmZmZmZmZl0NClsgICAgMC4wMDAwMDBdICAgTk9ERV9EQVRBIFttZW0gMHgz
ZmZmNTAwMC0weDNmZmZmZmZmXQ0KWyAgICAwLjAwMDAwMF0gWm9uZSByYW5nZXM6DQpbICAg
IDAuMDAwMDAwXSAgIERNQSAgICAgIFttZW0gMHgwMDAxMDAwMC0weDAwZmZmZmZmXQ0KWyAg
ICAwLjAwMDAwMF0gICBETUEzMiAgICBbbWVtIDB4MDEwMDAwMDAtMHhmZmZmZmZmZl0NClsg
ICAgMC4wMDAwMDBdICAgTm9ybWFsICAgZW1wdHkNClsgICAgMC4wMDAwMDBdIE1vdmFibGUg
em9uZSBzdGFydCBmb3IgZWFjaCBub2RlDQpbICAgIDAuMDAwMDAwXSBFYXJseSBtZW1vcnkg
bm9kZSByYW5nZXMNClsgICAgMC4wMDAwMDBdICAgbm9kZSAgIDA6IFttZW0gMHgwMDAxMDAw
MC0weDAwMDlkZmZmXQ0KWyAgICAwLjAwMDAwMF0gICBub2RlICAgMDogW21lbSAweDAwMTAw
MDAwLTB4M2ZmZmZmZmZdDQpbICAgIDAuMDAwMDAwXSBPbiBub2RlIDAgdG90YWxwYWdlczog
MjYyMDMwDQpbICAgIDAuMDAwMDAwXSAgIERNQSB6b25lOiA2NCBwYWdlcyB1c2VkIGZvciBt
ZW1tYXANClsgICAgMC4wMDAwMDBdICAgRE1BIHpvbmU6IDYgcGFnZXMgcmVzZXJ2ZWQNClsg
ICAgMC4wMDAwMDBdICAgRE1BIHpvbmU6IDM5MTIgcGFnZXMsIExJRk8gYmF0Y2g6MA0KWyAg
ICAwLjAwMDAwMF0gICBETUEzMiB6b25lOiA0MDMyIHBhZ2VzIHVzZWQgZm9yIG1lbW1hcA0K
WyAgICAwLjAwMDAwMF0gICBETUEzMiB6b25lOiAyNTQwMTYgcGFnZXMsIExJRk8gYmF0Y2g6
MzENClsgICAgMC4wMDAwMDBdIEFDUEk6IFBNLVRpbWVyIElPIFBvcnQ6IDB4ODA4DQpbICAg
IDAuMDAwMDAwXSBBQ1BJOiBMb2NhbCBBUElDIGFkZHJlc3MgMHhmZWUwMDAwMA0KWyAgICAw
LjAwMDAwMF0gQUNQSTogTEFQSUMgKGFjcGlfaWRbMHgwMV0gbGFwaWNfaWRbMHgwMF0gZW5h
YmxlZCkNClsgICAgMC4wMDAwMDBdIEFDUEk6IExBUElDIChhY3BpX2lkWzB4MDJdIGxhcGlj
X2lkWzB4MDFdIGVuYWJsZWQpDQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBMQVBJQyAoYWNwaV9p
ZFsweDAzXSBsYXBpY19pZFsweDAyXSBlbmFibGVkKQ0KWyAgICAwLjAwMDAwMF0gQUNQSTog
TEFQSUMgKGFjcGlfaWRbMHgwNF0gbGFwaWNfaWRbMHgwM10gZW5hYmxlZCkNClsgICAgMC4w
MDAwMDBdIEFDUEk6IElPQVBJQyAoaWRbMHgwNF0gYWRkcmVzc1sweGZlYzAwMDAwXSBnc2lf
YmFzZVswXSkNClsgICAgMC4wMDAwMDBdIElPQVBJQ1swXTogYXBpY19pZCA0LCB2ZXJzaW9u
IDMyLCBhZGRyZXNzIDB4ZmVjMDAwMDAsIEdTSSAwLTIzDQpbICAgIDAuMDAwMDAwXSBBQ1BJ
OiBJTlRfU1JDX09WUiAoYnVzIDAgYnVzX2lycSAwIGdsb2JhbF9pclsgICAgMS4zMzg2NjFd
IHVoY2lfaGNkIDAwMDA6MDA6MWEuMTogVUhDSSBIb3N0IENvbnRyb2xsZXINClsgICAgMS4z
Mzg4MjhdIHVoY2lfaGNkIDAwMDA6MDA6MWEuMTogbmV3IFVTQiBidXMgcmVnaXN0ZXJlZCwg
YXNzaWduZWQgYnVzIG51bWJlciA0DQpbICAgIDEuMzM4ODM5XSB1aGNpX2hjZCAwMDAwOjAw
OjFhLjE6IGRldGVjdGVkIDIgcG9ydHMNClsgICAgMS4zMzg4NDddIHVoY2lfaGNkIDAwMDA6
MDA6MWEuMTogdWhjaV9jaGVja19hbmRfcmVzZXRfaGM6IGNtZCA9IDB4MDAwMA0KWyAgICAx
LjMzODg0OF0gdWhjaV9oY2QgMDAwMDowMDoxYS4xOiBQZXJmb3JtaW5nIGZ1bGwgcmVzZXQN
ClsgICAgMS4zMzg4NjldIHVoY2lfaGNkIDAwMDA6MDA6MWEuMTogc3VwcG9ydHMgVVNCIHJl
bW90ZSB3YWtldXANClsgICAgMS4zMzg5MDVdIHVoY2lfaGNkIDAwMDA6MDA6MWEuMTogaXJx
IDIxLCBpbyBiYXNlIDB4MDAwMGI4MDANClsgICAgMS4zMzg5NzldIHVzYiB1c2I0OiBkZWZh
dWx0IGxhbmd1YWdlIDB4MDQwOQ0KWyAgICAxLjMzODk5Ml0gdXNiIHVzYjQ6IHVkZXYgMSwg
YnVzbnVtIDQsIG1pbm9yID0gMzg0DQpbICAgIDEuMzM4OTk0XSB1c2IgdXNiNDogTmV3IFVT
QiBkZXZpY2UgZm91bmQsIGlkVmVuZG9yPTFkNmIsIGlkUHJvZHVjdD0wMDAxDQpbICAgIDEu
MzM4OTk2XSB1c2IgdXNiNDogTmV3IFVTQiBkZXZpY2Ugc3RyaW5nczogTWZyPTMsIFByb2R1
Y3Q9MiwgU2VyaWFsTnVtYmVyPTENClsgICAgMS4zMzg5OThdIHVzYiB1c2I0OiBQcm9kdWN0
OiBVSENJIEhvc3QgQ29udHJvbGxlcg0KWyAgICAxLjMzOTAwMF0gdXNiIHVzYjQ6IE1hbnVm
YWN0dXJlcjogTGludXggMy42LjAtcmM0LTIwMTIwODMwKyB1aGNpX2hjZA0KWyAgICAxLjMz
OTAwMV0gdXNiIHVzYjQ6IFNlcmlhbE51bWJlcjogMDAwMDowMDoxYS4xDQpbICAgIDEuMzM5
MjA4XSB1c2IgdXNiNDogdXNiX3Byb2JlX2RldmljZQ0KWyAgICAxLjMzOTIxMV0gdXNiIHVz
YjQ6IGNvbmZpZ3VyYXRpb24gIzEgY2hvc2VuIGZyb20gMSBjaG9pY2UNClsgICAgMS4zMzky
MjZdIHVzYiB1c2I0OiBhZGRpbmcgNC0wOjEuMCAoY29uZmlnICMxLCBpbnRlcmZhY2UgMCkN
ClsgICAgMS4zMzkzNzVdIGh1YiA0LTA6MS4wOiB1c2JfcHJvYmVfaW50ZXJmYWNlDQpbICAg
IDEuMzM5Mzc3XSBodWIgNC0wOjEuMDogdXNiX3Byb2JlX2ludGVyZmFjZSAtIGdvdCBpZA0K
WyAgICAxLjMzOTM3OV0gaHViIDQtMDoxLjA6IFVTQiBodWIgZm91bmQNClsgICAgMS4zMzkz
ODddIGh1YiA0LTA6MS4wOiAyIHBvcnRzIGRldGVjdGVkDQpbICAgIDEuMzM5Mzg4XSBodWIg
NC0wOjEuMDogc3RhbmRhbG9uZSBodWINClsgICAgMS4zMzkzOTBdIGh1YiA0LTA6MS4wOiBu
byBwb3dlciBzd2l0Y2hpbmcgKHVzYiAxLjApDQpbICAgIDEuMzM5MzkxXSBodWIgNC0wOjEu
MDogaW5kaXZpZHVhbCBwb3J0IG92ZXItY3VycmVudCBwcm90ZWN0aW9uDQpbICAgIDEuMzM5
MzkzXSBodWIgNC0wOjEuMDogcG93ZXIgb24gdG8gcG93ZXIgZ29vZCB0aW1lOiAybXMNClsg
ICAgMS4zMzk0MDNdIGh1YiA0LTA6MS4wOiBsb2NhbCBwb3dlciBzb3VyY2UgaXMgZ29vZA0K
WyAgICAxLjMzOTQwNV0gaHViIDQtMDoxLjA6IHRyeWluZyB0byBlbmFibGUgcG9ydCBwb3dl
ciBvbiBub24tc3dpdGNoYWJsZSBodWINClsgICAgMS4zMzk1MDNdIGVoY2lfaGNkIDAwMDA6
MDA6MWEuNzogSFMgY29tcGFuaW9uIGZvciAwMDAwOjAwOjFhLjENClsgICAgMS4zMzk1NDZd
IHhlbjogcmVnaXN0ZXJpbmcgZ3NpIDE4IHRyaWdnZXJpbmcgMCBwb2xhcml0eSAxDQpbICAg
IDEuMzM5NTQ4XSBBbHJlYWR5IHNldHVwIHRoZSBHU0kgOjE4DQpbICAgIDEuMzM5NTYyXSB1
aGNpX2hjZCAwMDAwOjAwOjFhLjI6IHNldHRpbmcgbGF0ZW5jeSB0aW1lciB0byA2NA0KWyAg
ICAxLjMzOTU2N10gdWhjaV9oY2QgMDAwMDowMDoxYS4yOiBVSENJIEhvc3QgQ29udHJvbGxl
cg0KWyAgICAxLjMzOTc3OF0gdWhjaV9oY2QgMDAwMDowMDoxYS4yOiBuZXcgVVNCIGJ1cyBy
ZWdpc3RlcmVkLCBhc3NpZ25lZCBidXMgbnVtYmVyIDUNClsgICAgMS4zMzk3ODldIHVoY2lf
aGNkIDAwMDA6MDA6MWEuMjogZGV0ZWN0ZWQgMiBwb3J0cw0KWyAgICAxLjMzOTc5Nl0gdWhj
aV9oY2QgMDAwMDowMDoxYS4yOiB1aGNpX2NoZWNrX2FuZF9yZXNldF9oYzogY21kID0gMHgw
MDAwDQpbICAgIDEuMzM5Nzk4XSB1aGNpX2hjZCAwMDAwOjAwOjFhLjI6IFBlcmZvcm1pbmcg
ZnVsbCByZXNldA0KWyAgICAxLjMzOTgxOV0gdWhjaV9oY2QgMDAwMDowMDoxYS4yOiBzdXBw
b3J0cyBVU0IgcmVtb3RlIHdha2V1cA0KWyAgICAxLjMzOTgyNl0gdWhjaV9oY2QgMDAwMDow
MDoxYS4yOiBpcnEgMTgsIGlvIGJhc2UgMHgwMDAwYjg4MA0KWyAgICAxLjMzOTkwNF0gdXNi
IHVzYjU6IGRlZmF1bHQgbGFuZ3VhZ2UgMHgwNDA5DQpbICAgIDEuMzM5OTE3XSB1c2IgdXNi
NTogdWRldiAxLCBidXNudW0gNSwgbWlub3IgPSA1MTINClsgICAgMS4zMzk5MjBdIHVzYiB1
c2I1OiBOZXcgVVNCIGRldmljZSBmb3VuZCwgaWRWZW5kb3I9MWQ2YiwgaWRQcm9kdWN0PTAw
MDENClsgICAgMS4zMzk5MjFdIHVzYiB1c2I1OiBOZXcgVVNCIGRldmljZSBzdHJpbmdzOiBN
ZnI9MywgUHJvZHVjdD0yLCBTZXJpYWxOdW1iZXI9MQ0KWyAgICAxLjMzOTkyM10gdXNiIHVz
YjU6IFByb2R1Y3Q6IFVIQ0kgSG9zdCBDb250cm9sbGVyDQpbICAgIDEuMzM5OTI1XSB1c2Ig
dXNiNTogTWFudWZhY3R1cmVyOiBMaW51eCAzLjYuMC1yYzQtMjAxMjA4MzArIHVoY2lfaGNk
DQpbICAgIDEuMzM5OTI3XSB1c2IgdXNiNTogU2VyaWFsTnVtYmVyOiAwMDAwOjAwOjFhLjIN
ClsgICAgMS4zNDAxOTRdIHVzYiB1c2I1OiB1c2JfcHJvYmVfZGV2aWNlDQpbICAgIDEuMzQw
MTk2XSB1c2IgdXNiNTogY29uZmlndXJhdGlvbiAjMSBjaG9zZW4gZnJvbSAxIGNob2ljZQ0K
WyAgICAxLjM0MDIwOF0gdXNiIHVzYjU6IGFkZGluZyA1LTA6MS4wIChjb25maWcgIzEsIGlu
dGVyZmFjZSAwKQ0KWyAgICAxLjM0MDM1MF0gaHViIDUtMDoxLjA6IHVzYl9wcm9iZV9pbnRl
cmZhY2UNClsgICAgMS4zNDAzNTFdIGh1YiA1LTA6MS4wOiB1c2JfcHJvYmVfaW50ZXJmYWNl
IC0gZ290IGlkDQpbICAgIDEuMzQwMzU0XSBodWIgNS0wOjEuMDogVVNCIGh1YiBmb3VuZA0K
WyAgICAxLjM0MDM2MV0gaHViIDUtMDoxLjA6IDIgcG9ydHMgZGV0ZWN0ZWQNClsgICAgMS4z
NDAzNjNdIGh1YiA1LTA6MS4wOiBzdGFuZGFsb25lIGh1Yg0KWyAgICAxLjM0MDM2NV0gaHVi
IDUtMDoxLjA6IG5vIHBvd2VyIHN3aXRjaGluZyAodXNiIDEuMCkNClsgICAgMS4zNDAzNjZd
IGh1YiA1LTA6MS4wOiBpbmRpdmlkdWFsIHBvcnQgb3Zlci1jdXJyZW50IHByb3RlY3Rpb24N
ClsgICAgMS4zNDAzNjhdIGh1YiA1LTA6MS4wOiBwb3dlciBvbiB0byBwb3dlciBnb29kIHRp
bWU6IDJtcw0KWyAgICAxLjM0MDM3OF0gaHViIDUtMDoxLjA6IGxvY2FsIHBvd2VyIHNvdXJj
ZSBpcyBnb29kDQpbICAgIDEuMzQwMzgwXSBodWIgNS0wOjEuMDogdHJ5aW5nIHRvIGVuYWJs
ZSBwb3J0IHBvd2VyIG9uIG5vbi1zd2l0Y2hhYmxlIGh1Yg0KWyAgICAxLjM0MDQ3N10gZWhj
aV9oY2QgMDAwMDowMDoxYS43OiBIUyBjb21wYW5pb24gZm9yIDAwMDA6MDA6MWEuMg0KWyAg
ICAxLjM0MDUyM10geGVuOiByZWdpc3RlcmluZyBnc2kgMjMgdHJpZ2dlcmluZyAwIHBvbGFy
aXR5IDENClsgICAgMS4zNDA1MjVdIEFscmVhZHkgc2V0dXAgdGhlIEdTSSA6MjMNClsgICAg
MS4zNDA1MzhdIHVoY2lfaGNkIDAwMDA6MDA6MWQuMDogc2V0dGluZyBsYXRlbmN5IHRpbWVy
IHRvIDY0DQpbICAgIDEuMzQwNTQyXSB1aGNpX2hjZCAwMDAwOjAwOjFkLjA6IFVIQ0kgSG9z
dCBDb250cm9sbGVyDQpbICAgIDEuMzQwNzA4XSB1aGNpX2hjZCAwMDAwOjAwOjFkLjA6IG5l
dyBVU0IgYnVzIHJlZ2lzdGVyZWQsIGFzc2lnbmVkIGJ1cyBudW1iZXIgNg0KWyAgICAxLjM0
MDcxOV0gdWhjaV9oY2QgMDAwMDowMDoxZC4wOiBkZXRlY3RlZCAyIHBvcnRzDQpbICAgIDEu
MzQwNzI3XSB1aGNpX2hjZCAwMDAwOjAwOjFkLjA6IHVoY2lfY2hlY2tfYW5kX3Jlc2V0X2hj
OiBjbWQgPSAweDAwMDANClsgICAgMS4zNDA3MjhdIHVoY2lfaGNkIDAwMDA6MDA6MWQuMDog
UGVyZm9ybWluZyBmdWxsIHJlc2V0DQpbICAgIDEuMzQwNzQ5XSB1aGNpX2hjZCAwMDAwOjAw
OjFkLjA6IHN1cHBvcnRzIFVTQiByZW1vdGUgd2FrZXVwDQpbICAgIDEuMzQwNzU2XSB1aGNp
X2hjZCAwMDAwOjAwOjFkLjA6IGlycSAyMywgaW8gYmFzZSAweDAwMDBiMDAwDQpbICAgIDEu
MzQwODMyXSB1c2IgdXNiNjogZGVmYXVsdCBsYW5ndWFnZSAweDA0MDkNClsgICAgMS4zNDA4
NDVdIHVzYiB1c2I2OiB1ZGV2IDEsIGJ1c251bSA2LCBtaW5vciA9IDY0MA0KWyAgICAxLjM0
MDg0N10gdXNiIHVzYjY6IE5ldyBVU0IgZGV2aWNlIGZvdW5kLCBpZFZlbmRvcj0xZDZiLCBp
ZFByb2R1Y3Q9MDAwMQ0KWyAgICAxLjM0MDg0OV0gdXNiIHVzYjY6IE5ldyBVU0IgZGV2aWNl
IHN0cmluZ3M6IE1mcj0zLCBQcm9kdWN0PTIsIFNlcmlhbE51bWJlcj0xDQpbICAgIDEuMzQw
ODUxXSB1c2IgdXNiNjogUHJvZHVjdDogVUhDSSBIb3N0IENvbnRyb2xsZXINClsgICAgMS4z
NDA4NTNdIHVzYiB1c2I2OiBNYW51ZmFjdHVyZXI6IExpbnV4IDMuNi4wLXJjNC0yMDEyMDgz
MCsgdWhjaV9oY2QNClsgICAgMS4zNDA4NTRdIHVzYiB1c2I2OiBTZXJpYWxOdW1iZXI6IDAw
MDA6MDA6MWQuMA0KWyAgICAxLjM0MTA2MV0gdXNiIHVzYjY6IHVzYl9wcm9iZV9kZXZpY2UN
ClsgICAgMS4zNDEwNjRdIHVzYiB1c2I2OiBjb25maWd1cmF0aW9uICMxIGNob3NlbiBmcm9t
IDEgY2hvaWNlDQpbICAgIDEuMzQxMDc2XSB1c2IgdXNiNjogYWRkaW5nIDYtMDoxLjAgKGNv
bmZpZyAjMSwgaW50ZXJmYWNlIDApDQpbICAgIDEuMzQxMjIwXSBodWIgNi0wOjEuMDogdXNi
X3Byb2JlX2ludGVyZmFjZQ0KWyAgICAxLjM0MTIyMV0gaHViIDYtMDoxLjA6IHVzYl9wcm9i
ZV9pbnRlcmZhY2UgLSBnb3QgaWQNClsgICAgMS4zNDEyMjRdIGh1YiA2LTA6MS4wOiBVU0Ig
aHViIGZvdW5kDQpbICAgIDEuMzQxMjMyXSBodWIgNi0wOjEuMDogMiBwb3J0cyBkZXRlY3Rl
ZA0KWyAgICAxLjM0MTIzM10gaHViIDYtMDoxLjA6IHN0YW5kYWxvbmUgaHViDQpbICAgIDEu
MzQxMjM1XSBodWIgNi0wOjEuMDogbm8gcG93ZXIgc3dpdGNoaW5nICh1c2IgMS4wKQ0KWyAg
ICAxLjM0MTIzNl0gaHViIDYtMDoxLjA6IGluZGl2aWR1YWwgcG9ydCBvdmVyLWN1cnJlbnQg
cHJvdGVjdGlvbg0KWyAgICAxLjM0MTIzOF0gaHViIDYtMDoxLjA6IHBvd2VyIG9uIHRvIHBv
d2VyIGdvb2QgdGltZTogMm1zDQpbICAgIDEuMzQxMjQ4XSBodWIgNi0wOjEuMDogbG9jYWwg
cG93ZXIgc291cmNlIGlzIGdvb2QNClsgICAgMS4zNDEyNTBdIGh1YiA2LTA6MS4wOiB0cnlp
bmcgdG8gZW5hYmxlIHBvcnQgcG93ZXIgb24gbm9uLXN3aXRjaGFibGUgaHViDQpbICAgIDEu
MzQxMzU5XSBlaGNpX2hjZCAwMDAwOjAwOjFkLjc6IEhTIGNvbXBhbmlvbiBmb3IgMDAwMDow
MDoxZC4wDQpbICAgIDEuMzQxMzkxXSB4ZW46IHJlZ2lzdGVyaW5nIGdzaSAxOSB0cmlnZ2Vy
aW5nIDAgcG9sYXJpdHkgMQ0KWyAgICAxLjM0MTM5M10gQWxyZWFkeSBzZXR1cCB0aGUgR1NJ
IDoxOQ0KWyAgICAxLjM0MTQwNl0gdWhjaV9oY2QgMDAwMDowMDoxZC4xOiBzZXR0aW5nIGxh
dGVuY3kgdGltZXIgdG8gNjQNClsgICAgMS4zNDE0MTBdIHVoY2lfaGNkIDAwMDA6MDA6MWQu
MTogVUhDSSBIb3N0IENvbnRyb2xsZXINClsgICAgMS4zNDE1OTVdIHVoY2lfaGNkIDAwMDA6
MDA6MWQuMTogbmV3IFVTQiBidXMgcmVnaXN0ZXJlZCwgYXNzaWduZWQgYnVzIG51bWJlciA3
DQpbICAgIDEuMzQxNjA1XSB1aGNpX2hjZCAwMDAwOjAwOjFkLjE6IGRldGVjdGVkIDIgcG9y
dHMNClsgICAgMS4zNDE2MTNdIHVoY2lfaGNkIDAwMDA6MDA6MWQuMTogdWhjaV9jaGVja19h
bmRfcmVzZXRfaGM6IGNtZCA9IDB4MDAwMA0KWyAgICAxLjM0MTYxNF0gdWhjaV9oY2QgMDAw
MDowMDoxZC4xOiBQZXJmb3JtaW5nIGZ1bGwgcmVzZXQNClsgICAgMS4zNDE2MzVdIHVoY2lf
aGNkIDAwMDA6MDA6MWQuMTogc3VwcG9ydHMgVVNCIHJlbW90ZSB3YWtldXANClsgICAgMS4z
NDE2NzNdIHVoY2lfaGNkIDAwMDA6MDA6MWQuMTogaXJxIDE5LCBpbyBiYXNlIDB4MDAwMGIw
ODANClsgICAgMS4zNDE3NTBdIHVzYiB1c2I3OiBkZWZhdWx0IGxhbmd1YWdlIDB4MDQwOQ0K
WyAgICAxLjM0MTc2NF0gdXNiIHVzYjc6IHVkZXYgMSwgYnVzbnVtIDcsIG1pbm9yID0gNzY4
DQpbICAgIDEuMzQxNzY2XSB1c2IgdXNiNzogTmV3IFVTQiBkZXZpY2UgZm91bmQsIGlkVmVu
ZG9yPTFkNmIsIGlkUHJvZHVjdD0wMDAxDQpbICAgIDEuMzQxNzY3XSB1c2IgdXNiNzogTmV3
IFVTQiBkZXZpY2Ugc3RyaW5nczogTWZyPTMsIFByb2R1Y3Q9MiwgU2VyaWFsTnVtYmVyPTEN
ClsgICAgMS4zNDE3NjldIHVzYiB1c2I3OiBQcm9kdWN0OiBVSENJIEhvc3QgQ29udHJvbGxl
cg0KWyAgICAxLjM0MTc3MV0gdXNiIHVzYjc6IE1hbnVmYWN0dXJlcjogTGludXggMy42LjAt
cmM0LTIwMTIwODMwKyB1aGNpX2hjZA0KWyAgICAxLjM0MTc3M10gdXNiIHVzYjc6IFNlcmlh
bE51bWJlcjogMDAwMDowMDoxZC4xDQpbICAgIDEuMzQxOTc5XSB1c2IgdXNiNzogdXNiX3By
b2JlX2RldmljZQ0KWyAgICAxLjM0MTk4Ml0gdXNiIHVzYjc6IGNvbmZpZ3VyYXRpb24gIzEg
Y2hvc2VuIGZyb20gMSBjaG9pY2UNClsgICAgMS4zNDE5OTRdIHVzYiB1c2I3OiBhZGRpbmcg
Ny0wOjEuMCAoY29uZmlnICMxLCBpbnRlcmZhY2UgMCkNClsgICAgMS4zNDIxMzVdIGh1YiA3
LTA6MS4wOiB1c2JfcHJvYmVfaW50ZXJmYWNlDQpbICAgIDEuMzQyMTM2XSBodWIgNy0wOjEu
MDogdXNiX3Byb2JlX2ludGVyZmFjZSAtIGdvdCBpZA0KWyAgICAxLjM0MjEzOV0gaHViIDct
MDoxLjA6IFVTQiBodWIgZm91bmQNClsgICAgMS4zNDIxNDZdIGh1YiA3LTA6MS4wOiAyIHBv
cnRzIGRldGVjdGVkDQpbICAgIDEuMzQyMTQ4XSBodWIgNy0wOjEuMDogc3RhbmRhbG9uZSBo
dWINClsgICAgMS4zNDIxNDldIGh1YiA3LTA6MS4wOiBubyBwb3dlciBzd2l0Y2hpbmcgKHVz
YiAxLjApDQpbICAgIDEuMzQyMTUxXSBodWIgNy0wOjEuMDogaW5kaXZpZHVhbCBwb3J0IG92
ZXItY3VycmVudCBwcm90ZWN0aW9uDQpbICAgIDEuMzQyMTUzXSBodWIgNy0wOjEuMDogcG93
ZXIgb24gdG8gcG93ZXIgZ29vZCB0aW1lOiAybXMNClsgICAgMS4zNDIxNjNdIGh1YiA3LTA6
MS4wOiBsb2NhbCBwb3dlciBzb3VyY2UgaXMgZ29vZA0KWyAgICAxLjM0MjE2NV0gaHViIDct
MDoxLjA6IHRyeWluZyB0byBlbmFibGUgcG9ydCBwb3dlciBvbiBub24tc3dpdGNoYWJsZSBo
dWINClsgICAgMS4zNDIyNzRdIGVoY2lfaGNkIDAwMDA6MDA6MWQuNzogSFMgY29tcGFuaW9u
IGZvciAwMDAwOjAwOjFkLjENClsgICAgMS4zNDIzMDZdIHhlbjogcmVnaXN0ZXJpbmcgZ3Np
IDE4IHRyaWdnZXJpbmcgMCBwb2xhcml0eSAxDQpbICAgIDEuMzQyMzA4XSBBbHJlYWR5IHNl
dHVwIHRoZSBHU0kgOjE4DQpbICAgIDEuMzQyMzI1XSB1aGNpX2hjZCAwMDAwOjAwOjFkLjI6
IHNldHRpbmcgbGF0ZW5jeSB0aW1lciB0byA2NA0KWyAgICAxLjM0MjMzMF0gdWhjaV9oY2Qg
MDAwMDowMDoxZC4yOiBVSENJIEhvc3QgQ29udHJvbGxlcg0KWyAgICAxLjM0MjQ5Nl0gdWhj
aV9oY2QgMDAwMDowMDoxZC4yOiBuZXcgVVNCIGJ1cyByZWdpc3RlcmVkLCBhc3NpZ25lZCBi
dXMgbnVtYmVyIDgNClsgICAgMS4zNDI1MDddIHVoY2lfaGNkIDAwMDA6MDA6MWQuMjogZGV0
ZWN0ZWQgMiBwb3J0cw0KWyAgICAxLjM0MjUxNF0gdWhjaV9oY2QgMDAwMDowMDoxZC4yOiB1
aGNpX2NoZWNrX2FuZF9yZXNldF9oYzogY21kID0gMHgwMDAwDQpbICAgIDEuMzQyNTE2XSB1
aGNpX2hjZCAwMDAwOjAwOjFkLjI6IFBlcmZvcm1pbmcgZnVsbCByZXNldA0KWyAgICAxLjM0
MjUzNl0gdWhjaV9oY2QgMDAwMDowMDoxZC4yOiBzdXBwb3J0cyBVU0IgcmVtb3RlIHdha2V1
cA0KWyAgICAxLjM0MjU0NF0gdWhjaV9oY2QgMDAwMDowMDoxZC4yOiBpcnEgMTgsIGlvIGJh
c2UgMHgwMDAwYjQwMA0KWyAgICAxLjM0MjYxOV0gdXNiIHVzYjg6IGRlZmF1bHQgbGFuZ3Vh
Z2UgMHgwNDA5DQpbICAgIDEuMzQyNjMyXSB1c2IgdXNiODogdWRldiAxLCBidXNudW0gOCwg
bWlub3IgPSA4OTYNClsgICAgMS4zNDI2MzRdIHVzYiB1c2I4OiBOZXcgVVNCIGRldmljZSBm
b3VuZCwgaWRWZW5kb3I9MWQ2YiwgaWRQcm9kdWN0PTAwMDENClsgICAgMS4zNDI2MzZdIHVz
YiB1c2I4OiBOZXcgVVNCIGRldmljZSBzdHJpbmdzOiBNZnI9MywgUHJvZHVjdD0yLCBTZXJp
YWxOdW1iZXI9MQ0KWyAgICAxLjM0MjYzOF0gdXNiIHVzYjg6IFByb2R1Y3Q6IFVIQ0kgSG9z
dCBDb250cm9sbGVyDQpbICAgIDEuMzQyNjQwXSB1c2IgdXNiODogTWFudWZhY3R1cmVyOiBM
aW51eCAzLjYuMC1yYzQtMjAxMjA4MzArIHVoY2lfaGNkDQpbICAgIDEuMzQyNjQxXSB1c2Ig
dXNiODogU2VyaWFsTnVtYmVyOiAwMDAwOjAwOjFkLjINClsgICAgMS4zNDI4NDhdIHVzYiB1
c2I4OiB1c2JfcHJvYmVfZGV2aWNlDQpbICAgIDEuMzQyODUwXSB1c2IgdXNiODogY29uZmln
dXJhdGlvbiAjMSBjaG9zZW4gZnJvbSAxIGNob2ljZQ0KWyAgICAxLjM0Mjg2Ml0gdXNiIHVz
Yjg6IGFkZGluZyA4LTA6MS4wIChjb25maWcgIzEsIGludGVyZmFjZSAwKQ0KWyAgICAxLjM0
MzAwOF0gaHViIDgtMDoxLjA6IHVzYl9wcm9iZV9pbnRlcmZhY2UNClsgICAgMS4zNDMwMTBd
IGh1YiA4LTA6MS4wOiB1c2JfcHJvYmVfaW50ZXJmYWNlIC0gZ290IGlkDQpbICAgIDEuMzQz
MDEyXSBodWIgOC0wOjEuMDogVVNCIGh1YiBmb3VuZA0KWyAgICAxLjM0MzAyMF0gaHViIDgt
MDoxLjA6IDIgcG9ydHMgZGV0ZWN0ZWQNClsgICAgMS4zNDMwMjJdIGh1YiA4LTA6MS4wOiBz
dGFuZGFsb25lIGh1Yg0KWyAgICAxLjM0MzAyM10gaHViIDgtMDoxLjA6IG5vIHBvd2VyIHN3
aXRjaGluZyAodXNiIDEuMCkNClsgICAgMS4zNDMwMjRdIGh1YiA4LTA6MS4wOiBpbmRpdmlk
dWFsIHBvcnQgb3Zlci1jdXJyZW50IHByb3RlY3Rpb24NClsgICAgMS4zNDMwMjZdIGh1YiA4
LTA6MS4wOiBwb3dlciBvbiB0byBwb3dlciBnb29kIHRpbWU6IDJtcw0KWyAgICAxLjM0MzAz
Nl0gaHViIDgtMDoxLjA6IGxvY2FsIHBvd2VyIHNvdXJjZSBpcyBnb29kDQpbICAgIDEuMzQz
MDM4XSBodWIgOC0wOjEuMDogdHJ5aW5nIHRvIGVuYWJsZSBwb3J0IHBvd2VyIG9uIG5vbi1z
d2l0Y2hhYmxlIGh1Yg0KWyAgICAxLjM0MzE0Nl0gZWhjaV9oY2QgMDAwMDowMDoxZC43OiBI
UyBjb21wYW5pb24gZm9yIDAwMDA6MDA6MWQuMg0KWyAgICAxLjM0MzQ1M10gdXNiY29yZTog
cmVnaXN0ZXJlZCBuZXcgaW50ZXJmYWNlIGRyaXZlciB1c2JscA0KWyAgICAxLjM0MzQ1NF0g
SW5pdGlhbGl6aW5nIFVTQiBNYXNzIFN0b3JhZ2UgZHJpdmVyLi4uDQpbICAgIDEuMzQzNjA0
XSB1c2Jjb3JlOiByZWdpc3RlcmVkIG5ldyBpbnRlcmZhY2UgZHJpdmVyIHVzYi1zdG9yYWdl
DQpbICAgIDEuMzQzNjA1XSBVU0IgTWFzcyBTdG9yYWdlIHN1cHBvcnQgcmVnaXN0ZXJlZC4N
ClsgICAgMS4zNDM4NTZdIHVzYmNvcmU6IHJlZ2lzdGVyZWQgbmV3IGludGVyZmFjZSBkcml2
ZXIgbGlidXN1YWwNClsgICAgMS4zNDQxMTFdIHVzYmNvcmU6IHJlZ2lzdGVyZWQgbmV3IGlu
dGVyZmFjZSBkcml2ZXIgdXNic2VyaWFsDQpbICAgIDEuMzQ0MTEzXSB1c2JzZXJpYWw6IFVT
QiBTZXJpYWwgRHJpdmVyIGNvcmUNClsgICAgMS4zNDQyMzRdIHVzYmNvcmU6IHJlZ2lzdGVy
ZWQgbmV3IGludGVyZmFjZSBkcml2ZXIgY3AyMTB4DQpbICAgIDEuMzQ0NDIzXSBVU0IgU2Vy
aWFsIHN1cHBvcnQgcmVnaXN0ZXJlZCBmb3IgY3AyMTB4DQpbICAgIDEuMzQ0NTc4XSB1c2Jj
b3JlOiByZWdpc3RlcmVkIG5ldyBpbnRlcmZhY2UgZHJpdmVyIGN5cHJlc3NfbTgNClsgICAg
MS4zNDQ2OTldIFVTQiBTZXJpYWwgc3VwcG9ydCByZWdpc3RlcmVkIGZvciBEZUxvcm1lIEVh
cnRobWF0ZSBVU0INClsgICAgMS4zNDQ4MTBdIFVTQiBTZXJpYWwgc3VwcG9ydCByZWdpc3Rl
cmVkIGZvciBISUQtPkNPTSBSUzIzMiBBZGFwdGVyDQpbICAgIDEuMzQ0OTIwXSBVU0IgU2Vy
aWFsIHN1cHBvcnQgcmVnaXN0ZXJlZCBmb3IgTm9raWEgQ0EtNDIgVjIgQWRhcHRlcg0KWyAg
ICAxLjM0NTA0Nl0gdXNiY29yZTogcmVnaXN0ZXJlZCBuZXcgaW50ZXJmYWNlIGRyaXZlciBt
b3M3NzIwDQpbICAgIDEuMzQ1MTU4XSBVU0IgU2VyaWFsIHN1cHBvcnQgcmVnaXN0ZXJlZCBm
b3IgTW9zY2hpcCAyIHBvcnQgYWRhcHRlcg0KWyAgICAxLjM0NTI4NV0gdXNiY29yZTogcmVn
aXN0ZXJlZCBuZXcgaW50ZXJmYWNlIGRyaXZlciBtb3M3ODQwDQpbICAgIDEuMzQ1Mzk1XSBV
U0IgU2VyaWFsIHN1cHBvcnQgcmVnaXN0ZXJlZCBmb3IgTW9zY2hpcCA3ODQwLzc4MjAgVVNC
IFNlcmlhbCBEcml2ZXINClsgICAgMS4zNDU2ODBdIGk4MDQyOiBQTlA6IFBTLzIgQ29udHJv
bGxlciBbUE5QMDMwMzpQUzJLLFBOUDBmMDM6UFMyTV0gYXQgMHg2MCwweDY0IGlycSAxLDEy
DQpbICAgIDEuMzQ4NjM2XSBzZXJpbzogaTgwNDIgS0JEIHBvcnQgYXQgMHg2MCwweDY0IGly
cSAxDQpbICAgIDEuMzQ4NjYyXSBzZXJpbzogaTgwNDIgQVVYIHBvcnQgYXQgMHg2MCwweDY0
IGlycSAxMg0KWyAgICAxLjM0OTE0OV0gbW91c2VkZXY6IFBTLzIgbW91c2UgZGV2aWNlIGNv
bW1vbiBmb3IgYWxsIG1pY2UNClsgICAgMS4zNTAwNDhdIHJ0Y19jbW9zIDAwOjAzOiBSVEMg
Y2FuIHdha2UgZnJvbSBTNA0KWyAgICAxLjM1MDU4NF0gcnRjX2Ntb3MgMDA6MDM6IHJ0YyBj
b3JlOiByZWdpc3RlcmVkIHJ0Y19jbW9zIGFzIHJ0YzANClsgICAgMS4zNTA2NTJdIHJ0YzA6
IGFsYXJtcyB1cCB0byBvbmUgbW9udGgsIHkzaywgMTE0IGJ5dGVzIG52cmFtDQpbICAgIDEu
MzUwODM3XSB4ZW46IHJlZ2lzdGVyaW5nIGdzaSAxOCB0cmlnZ2VyaW5nIDAgcG9sYXJpdHkg
MQ0KWyAgICAxLjM1MDg0MV0gQWxyZWFkeSBzZXR1cCB0aGUgR1NJIDoxOA0KWyAgICAxLjM1
MDg1Ml0gQUNQSSBXYXJuaW5nOiAweDAwMDAwMDAwMDAwMDA0MDAtMHgwMDAwMDAwMDAwMDAw
NDFmIFN5c3RlbUlPIGNvbmZsaWN0cyB3aXRoIFJlZ2lvbiBcU01SRyAxICgyMDEyMDcxMS91
dGFkZHJlc3MtMjUxKQ0KWyAgICAxLjM1MDg1NV0gQUNQSTogSWYgYW4gQUNQSSBkcml2ZXIg
aXMgYXZhaWxhYmxlIGZvciB0aGlzIGRldmljZSwgeW91IHNob3VsZCB1c2UgaXQgaW5zdGVh
ZCBvZiB0aGUgbmF0aXZlIGRyaXZlcg0KWyAgICAxLjM1MTIzMF0gbGlyY19kZXY6IElSIFJl
bW90ZSBDb250cm9sIGRyaXZlciByZWdpc3RlcmVkLCBtYWpvciAyNTAgDQpbICAgIDEuMzUx
MjUwXSBJUiBORUMgcHJvdG9jb2wgaGFuZGxlciBpbml0aWFsaXplZA0KWyAgICAxLjM1MTI1
Ml0gSVIgUkM1KHgpIHByb3RvY29sIGhhbmRsZXIgaW5pdGlhbGl6ZWQNClsgICAgMS4zNTEy
NTNdIElSIFJDNiBwcm90b2NvbCBoYW5kbGVyIGluaXRpYWxpemVkDQpbICAgIDEuMzUxMjU0
XSBJUiBKVkMgcHJvdG9jb2wgaGFuZGxlciBpbml0aWFsaXplZA0KWyAgICAxLjM1MTI1NV0g
SVIgU29ueSBwcm90b2NvbCBoYW5kbGVyIGluaXRpYWxpemVkDQpbICAgIDEuMzUxMjU3XSBJ
UiBSQzUgKHN0cmVhbXphcCkgcHJvdG9jb2wgaGFuZGxlciBpbml0aWFsaXplZA0KWyAgICAx
LjM1MTI1OF0gSVIgU0FOWU8gcHJvdG9jb2wgaGFuZGxlciBpbml0aWFsaXplZA0KWyAgICAx
LjM1MTI1OV0gSVIgTUNFIEtleWJvYXJkL21vdXNlIHByb3RvY29sIGhhbmRsZXIgaW5pdGlh
bGl6ZWQNClsgICAgMS4zNTEyNjBdIElSIExJUkMgYnJpZGdlIGhhbmRsZXIgaW5pdGlhbGl6
ZWQNClsgICAgMS4zNTI4MDZdIGN4ODgvMDogY3gyMzg4eCB2NGwyIGRyaXZlciB2ZXJzaW9u
IDAuMC45IGxvYWRlZA0KWyAgICAxLjM1MzA3Nl0gdXNiY29yZTogcmVnaXN0ZXJlZCBuZXcg
aW50ZXJmYWNlIGRyaXZlciBlbTI4eHgNClsgICAgMS4zNTMxOThdIHVzYmNvcmU6IHJlZ2lz
dGVyZWQgbmV3IGludGVyZmFjZSBkcml2ZXIgY3gyMzF4eA0KWyAgICAxLjM1MzIwMF0gY3gy
NTgyMTogZHJpdmVyIHZlcnNpb24gMC4wLjEwNiBsb2FkZWQNClsgICAgMS4zNTM1NDZdIHVz
YmNvcmU6IHJlZ2lzdGVyZWQgbmV3IGludGVyZmFjZSBkcml2ZXIgcHZydXNiMg0KWyAgICAx
LjM1MzU0N10gcHZydXNiMjogVjRMIGluLXRyZWUgdmVyc2lvbjpIYXVwcGF1Z2UgV2luVFYt
UFZSLVVTQjIgTVBFRzIgRW5jb2Rlci9UdW5lcg0KWyAgICAxLjM1MzU0OV0gcHZydXNiMjog
RGVidWcgbWFzayBpcyAzMSAoMHgxZikNClsgICAgMS4zNTM2ODZdIHVzYmNvcmU6IHJlZ2lz
dGVyZWQgbmV3IGludGVyZmFjZSBkcml2ZXIgUGhpbGlwcyB3ZWJjYW0NClsgICAgMS4zNTM2
ODddIGl2dHY6IFN0YXJ0IGluaXRpYWxpemF0aW9uLCB2ZXJzaW9uIDEuNC4zDQpbICAgIDEu
MzUzODI3XSBpdnR2OiBFbmQgaW5pdGlhbGl6YXRpb24NClsgICAgMS4zNTM4MjldIGl2dHZm
YjogIG5vIGNhcmRzIGZvdW5kDQpbICAgIDEuMzU0MDk3XSB2aXZpLTAwMDogVjRMMiBkZXZp
Y2UgcmVnaXN0ZXJlZCBhcyB2aWRlbzANClsgICAgMS4zNTQwOTldIFZpZGVvIFRlY2hub2xv
Z3kgTWFnYXppbmUgVmlydHVhbCBWaWRlbyBDYXB0dXJlIEJvYXJkIHZlciAwLjguMSBzdWNj
ZXNzZnVsbHkgbG9hZGVkLg0KWyAgICAxLjM1NDEwMF0gY3gyMzg4NSBkcml2ZXIgdmVyc2lv
biAwLjAuMyBsb2FkZWQNClsgICAgMS4zNTQzNzZdIHVzYmNvcmU6IHJlZ2lzdGVyZWQgbmV3
IGludGVyZmFjZSBkcml2ZXIgdXZjdmlkZW8NClsgICAgMS4zNTQzNzddIFVTQiBWaWRlbyBD
bGFzcyBkcml2ZXIgKDEuMS4xKQ0KWyAgICAxLjM1NTE3MF0gc3A1MTAwX3RjbzogU1A1MTAw
IFRDTyBXYXRjaERvZyBUaW1lciBEcml2ZXIgdjAuMDENClsgICAgMS4zNTU0NDZdIHhlbl93
ZHQ6IFhlbiBXYXRjaERvZyBUaW1lciBEcml2ZXIgdjAuMDENClsgICAgMS4zNTU4ODhdIHhl
bl93ZHQ6IGluaXRpYWxpemVkICh0aW1lb3V0PTYwcywgbm93YXlvdXQ9MCkNClsgICAgMS4z
NTY1MjBdIGRldmljZS1tYXBwZXI6IGlvY3RsOiA0LjIzLjAtaW9jdGwgKDIwMTItMDctMjUp
IGluaXRpYWxpc2VkOiBkbS1kZXZlbEByZWRoYXQuY29tDQpbICAgIDEuMzYwMzgxXSB1c2Jj
b3JlOiByZWdpc3RlcmVkIG5ldyBpbnRlcmZhY2UgZHJpdmVyIHVzYmhpZA0KWyAgICAxLjM2
MDM4Ml0gdXNiaGlkOiBVU0IgSElEIGNvcmUgZHJpdmVyDQpbICAgIDEuMzY1MzE1XSB4ZW46
IHJlZ2lzdGVyaW5nIGdzaSAyMiB0cmlnZ2VyaW5nIDAgcG9sYXJpdHkgMQ0KWyAgICAxLjM2
NTMyMF0gQWxyZWFkeSBzZXR1cCB0aGUgR1NJIDoyMg0KWyAgICAxLjM3MzUyNV0gaW5wdXQ6
IEFUIFRyYW5zbGF0ZWQgU2V0IDIga2V5Ym9hcmQgYXMgL2RldmljZXMvcGxhdGZvcm0vaTgw
NDIvc2VyaW8wL2lucHV0L2lucHV0Mg0KWyAgICAxLjQwNzU3M10geGVuOiByZWdpc3Rlcmlu
ZyBnc2kgMTcgdHJpZ2dlcmluZyAwIHBvbGFyaXR5IDENClsgICAgMS40MDc1NzddIEFscmVh
ZHkgc2V0dXAgdGhlIEdTSSA6MTcNClsgICAgMS40MjIxMTFdIHVzYmNvcmU6IHJlZ2lzdGVy
ZWQgbmV3IGludGVyZmFjZSBkcml2ZXIgc25kLXVzYi1hdWRpbw0KWyAgICAxLjQyMjIzMF0g
dXNiY29yZTogcmVnaXN0ZXJlZCBuZXcgaW50ZXJmYWNlIGRyaXZlciBzbmQtdWExMDENClsg
ICAgMS40MjIzNTBdIHVzYmNvcmU6IHJlZ2lzdGVyZWQgbmV3IGludGVyZmFjZSBkcml2ZXIg
c25kLXVzYi11c3gyeQ0KWyAgICAxLjQyMjQ2OF0gdXNiY29yZTogcmVnaXN0ZXJlZCBuZXcg
aW50ZXJmYWNlIGRyaXZlciBzbmQtdXNiLWNhaWFxDQpbICAgIDEuNDIyNTkwXSB1c2Jjb3Jl
OiByZWdpc3RlcmVkIG5ldyBpbnRlcmZhY2UgZHJpdmVyIHNuZC11c2ItNmZpcmUNClsgICAg
MS40MjI2NDRdIE5ldGZpbHRlciBtZXNzYWdlcyB2aWEgTkVUTElOSyB2MC4zMC4NClsgICAg
MS40MjI2NTJdIG5mbmxfYWNjdDogcmVnaXN0ZXJpbmcgd2l0aCBuZm5ldGxpbmsuDQpbICAg
IDEuNDIyNzE5XSBuZl9jb25udHJhY2sgdmVyc2lvbiAwLjUuMCAoNzMwOSBidWNrZXRzLCAy
OTIzNiBtYXgpDQpbICAgIDEuNDIzMzYzXSBjdG5ldGxpbmsgdjAuOTM6IHJlZ2lzdGVyaW5n
IHdpdGggbmZuZXRsaW5rLg0KWyAgICAxLjQyMzYyNV0gaHViIDEtMDoxLjA6IHN0YXRlIDcg
cG9ydHMgNiBjaGcgMDAwMCBldnQgMDAwMA0KWyAgICAxLjQyNDAwNF0geHRfdGltZToga2Vy
bmVsIHRpbWV6b25lIGlzIC0wMDAwDQpbICAgIDEuNDI0MDI3XSBpcF9zZXQ6IHByb3RvY29s
IDYNClsgICAgMS40MjQwNTddIElQVlM6IFJlZ2lzdGVyZWQgcHJvdG9jb2xzICgpDQpbICAg
IDEuNDI0MjMzXSBJUFZTOiBDb25uZWN0aW9uIGhhc2ggdGFibGUgY29uZmlndXJlZCAoc2l6
ZT00MDk2LCBtZW1vcnk9NjRLYnl0ZXMpDQpbICAgIDEuNDI0MzM4XSBJUFZTOiBDcmVhdGlu
ZyBuZXRucyBzaXplPTE4ODggaWQ9MA0KWyAgICAxLjQyNDM4NF0gSVBWUzogaXB2cyBsb2Fk
ZWQuDQpbICAgIDEuNDI0NjI2XSBpcF90YWJsZXM6IChDKSAyMDAwLTIwMDYgTmV0ZmlsdGVy
IENvcmUgVGVhbQ0KWyAgICAxLjQyNDc0Ml0gVENQOiBjdWJpYyByZWdpc3RlcmVkDQpbICAg
IDEuNDI0NzQ3XSBORVQ6IFJlZ2lzdGVyZWQgcHJvdG9jb2wgZmFtaWx5IDE3DQpbICAgIDEu
NDI0ODEyXSBCcmlkZ2UgZmlyZXdhbGxpbmcgcmVnaXN0ZXJlZA0KWyAgICAxLjQyNDgzNl0g
RWJ0YWJsZXMgdjIuMCByZWdpc3RlcmVkDQpbICAgIDEuNDI2MTI4XSByZWdpc3RlcmVkIHRh
c2tzdGF0cyB2ZXJzaW9uIDENClsgICAgMS40MzY3OThdIGh1YiAyLTA6MS4wOiBzdGF0ZSA3
IHBvcnRzIDYgY2hnIDAwMDAgZXZ0IDAwMDANClsgICAgMS40MzY4MDNdIGh1YiAzLTA6MS4w
OiBzdGF0ZSA3IHBvcnRzIDIgY2hnIDAwMDAgZXZ0IDAwMDANClsgICAgMS40MzY4NDFdIGh1
YiA0LTA6MS4wOiBzdGF0ZSA3IHBvcnRzIDIgY2hnIDAwMDAgZXZ0IDAwMDANClsgICAgMS40
NDAxMThdIGh1YiA1LTA6MS4wOiBzdGF0ZSA3IHBvcnRzIDIgY2hnIDAwMDAgZXZ0IDAwMDAN
ClsgICAgMS40NDAxMjZdIGh1YiA2LTA6MS4wOiBzdGF0ZSA3IHBvcnRzIDIgY2hnIDAwMDAg
ZXZ0IDAwMDANClsgICAgMS40NDAxNjhdIGh1YiA3LTA6MS4wOiBzdGF0ZSA3IHBvcnRzIDIg
Y2hnIDAwMDAgZXZ0IDAwMDANClsgICAgMS40NDAxNzNdIGh1YiA4LTA6MS4wOiBzdGF0ZSA3
IHBvcnRzIDIgY2hnIDAwMDAgZXZ0IDAwMDANClsgICAgMS41MzYzMjldIHBzbW91c2Ugc2Vy
aW8xOiBsb2dpcHMycHA6IERldGVjdGVkIHVua25vd24gTG9naXRlY2ggbW91c2UgbW9kZWwg
NTcNClsgICAgMi4wMDAyMTBdIGlucHV0OiBJbUV4UFMvMiBMb2dpdGVjaCBFeHBsb3JlciBN
b3VzZSBhcyAvZGV2aWNlcy9wbGF0Zm9ybS9pODA0Mi9zZXJpbzEvaW5wdXQvaW5wdXQzDQpb
ICAgIDIuMzQ2NzQzXSB1c2IgdXNiMzogc3VzcGVuZF9yaCAoYXV0by1zdG9wKQ0KWyAgICAy
LjM0Njc3N10gdXNiIHVzYjQ6IHN1c3BlbmRfcmggKGF1dG8tc3RvcCkNClsgICAgMi4zNDY4
MDldIHVzYiB1c2I1OiBzdXNwZW5kX3JoIChhdXRvLXN0b3ApDQpbICAgIDIuMzQ2ODM5XSB1
c2IgdXNiNjogc3VzcGVuZF9yaCAoYXV0by1zdG9wKQ0KWyAgICAyLjM0Njg3MF0gdXNiIHVz
Yjc6IHN1c3BlbmRfcmggKGF1dG8tc3RvcCkNClsgICAgMi4zNDY5MDFdIHVzYiB1c2I4OiBz
dXNwZW5kX3JoIChhdXRvLXN0b3ApDQpbICAgIDQuMTQ4OTU4XSBjb25zb2xlIFtuZXRjb24w
XSBlbmFibGVkDQpbICAgIDQuMTQ4OTYxXSBhdGExLjAwOiAxNTYzMDE0ODggc2VjdG9ycywg
bXVsdGkgMDogTEJbICAgIDYuMzk1NzY0XSBFWFQzLWZzIChzZGExKTogcmVjb3ZlcnkgcmVx
dWlyZWQgb24gcmVhZG9ubHkgZmlsZXN5c3RlbQ0KWyAgICA2LjQwMzc1OV0gRVhUMy1mcyAo
c2RhMSk6IHdyaXRlIGFjY2VzcyB3aWxsIGJlIGVuYWJsZWQgZHVyaW5nIHJlY292ZXJ5DQpb
ICAgIDYuODczMTI2XSBram91cm5hbGQgc3RhcnRpbmcuICBDb21taXQgaW50ZXJ2YWwgNSBz
ZWNvbmRzDQpbICAgIDYuODgxNDY1XSBFWFQzLWZzIChzZGExKTogcmVjb3ZlcnkgY29tcGxl
dGUNClsgICAgNi44ODE0NjddIEVYVDMtZnMgKHNkYTEpOiBtb3VudGVkIGZpbGVzeXN0ZW0g
d2l0aCB3cml0ZWJhY2sgZGF0YSBtb2RlDQpbICAgIDguNTQyNTI5XSB1ZGV2WzE4MTFdOiBz
dGFydGluZyB2ZXJzaW9uIDE2NA0KWyAgIDEwLjg4MTU2MV0gQWRkaW5nIDMyMjkwMjhrIHN3
YXAgb24gL2Rldi9zZGE1LiAgUHJpb3JpdHk6LTEgZXh0ZW50czoxIGFjcm9zczozMjI5MDI4
ayANClsgICAxMS4xODQxMTFdIEVYVDMtZnMgKHNkYTEpOiB1c2luZyBpbnRlcm5hbCBqb3Vy
bmFsDQpbICAgMTUuODgxMTQ5XSBlMTAwMGU6IGV0aDEgTklDIExpbmsgaXMgVXAgMTAwIE1i
cHMgRnVsbCBEdXBsZXgsIEZsb3cgQ29udHJvbDogUngvVHgNClsgICAxNS44OTEwODFdIGUx
MDAwZSAwMDAwOjAwOjE5LjA6IGV0aDE6IDEwLzEwMCBzcGVlZDogZGlzYWJsaW5nIFRTTw0K
WyAgIDE2LjIzMzg1MV0gc3NoZCAoMjU3OCk6IC9wcm9jLzI1Nzgvb29tX2FkaiBpcyBkZXBy
ZWNhdGVkLCBwbGVhc2UgdXNlIC9wcm9jLzI1Nzgvb29tX3Njb3JlX2FkaiBpbnN0ZWFkLg0K
WyAgIDk5LjAyNzgzNl0gPDQ+SU49IE9VVD1ldGgxIFNSQz0xNzIuMTYuMS4yNTEgRFNUPTE3
Mi4xNi4xLjEgTEVOPTg0IFRPUz0weDAwIFBSRUM9MHgwMCBUVEw9NjQgSUQ9MCBERiBQUk9U
Tz1JQ01QIFRZUEU9OCBDT0RFPTAgSUQ9MzE5NSBTRVE9MSANClsgIDE1MC40OTE2NzRdIDw0
PklOPWV0aDEgT1VUPSBNQUM9ZmY6ZmY6ZmY6ZmY6ZmY6ZmY6MDA6MWI6YTk6MjU6ZGY6NGM6
MDg6MDAgU1JDPTE3Mi4xNi4xLjEyIERTVD0yNTUuMjU1LjI1NS4yNTUgTEVOPTIyOSBUT1M9
MHgwMCBQUkVDPTB4MDAgVFRMPTY0IElEPTYyMjcwIFBST1RPPVVEUCBTUFQ9MTM4IERQVD0x
MzggTEVOPTIwOSANClsgIDQ5MS45OTQ3MTldIDw0PklOPSBPVVQ9ZXRoMSBTUkM9MTcyLjE2
LjEuMjUxIERTVD0xNzIuMTYuMS4xIExFTj04NCBUT1M9MHgwMCBQUkVDPTB4MDAgVFRMPTY0
IElEPTAgREYgUFJPVE89SUNNUCBUWVBFPTggQ09ERT0wIElEPTMyNDcgU0VRPTEgDQpbICA1
MDEuNTcyNjU5XSA8ND5JTj1ldGgxIE9VVD0gTUFDPWZmOmZmOmZmOmZmOmZmOmZmOjAwOjI0
OmQ3OjExOmI4OmQwOjA4OjAwIFNSQz0xNzIuMTYuMS4yMCBEU1Q9MjU1LjI1NS4yNTUuMjU1
IExFTj0zMjggVE9TPTB4MDAgUFJFQz0weDAwIFRUTD0xMjggSUQ9MTQ5NzIgUFJPVE89VURQ
IFNQVD02OCBEUFQ9NjcgTEVOPTMwOCANClsgIDUwNC41NzMwNDldIDw0PklOPWV0aDEgT1VU
PSBNQUM9ZmY6ZmY6ZmY6ZmY6ZmY6ZmY6MDA6MjQ6ZDc6MTE6Yjg6ZDA6MDg6MDAgU1JDPTE3
Mi4xNi4xLjIwIERTVD0yNTUuMjU1LjI1NS4yNTUgTEVOPTMyOCBUT1M9MHgwMCBQUkVDPTB4
MDAgVFRMPTEyOCBJRD0xNDk4MCBQUk9UTz1VRFAgU1BUPTY4IERQVD02NyBMRU49MzA4IA0K
WyAgNzU0LjQyNjEwMF0gPDQ+SU49ZXRoMSBPVVQ9IE1BQz0wMDoyMzo1NDo5YTo0NjplYTo0
MDo2MTo4NjpmNDo2NzpkODowODowMCBTUkM9MTcyLjE2LjEuMSBEU1Q9MTcyLjE2LjEuMjUx
IExFTj0zMjggVE9TPTB4MTAgUFJFQz0weDAwIFRUTD0xMjggSUQ9MCBQUk9UTz1VRFAgU1BU
PTY3IERQVD02OCBMRU49MzA4IA0KWyAgODEyLjAwMTg1OF0gPDQ+SU49ZXRoMSBPVVQ9IE1B
Qz1mZjpmZjpmZjpmZjpmZjpmZjowMDoxYjphOToyNTpkZjo0YzowODowMCBTUkM9MTcyLjE2
LjEuMTIgRFNUPTI1NS4yNTUuMjU1LjI1NSBMRU49MjI5IFRPUz0weDAwIFBSRUM9MHgwMCBU
VEw9NjQgSUQ9NjIzMTAgUFJPVE89VURQIFNQVD0xMzggRFBUPTEzOCBMRU49MjA5IA0KWyAg
ODUzLjUyMDg0OV0gZTEwMDBlOiBldGgxIE5JQyBMaW5rIGlzIFVwIDEwMCBNYnBzIEZ1bGwg
RHVwbGV4LCBGbG93IENvbnRyb2w6IFJ4L1R4DQpbICA4NjIuMjcyNDIwXSA8ND5JTj1ldGgx
IE9VVD0gTUFDPWZmOmZmOmZmOmZmOmZmOmZmOjAwOjE2OjM2OmE3OmQwOmYzOjA4OjAwIFNS
Qz0xNzIuMTYuMS4yNDAgRFNUPTE3Mi4xNi4yNTUuMjU1IExFTj0yMDIgVE9TPTB4MDAgUFJF
Qz0weDAwIFRUTD0xMjggSUQ9NTcwMiBQUk9UTz1VRFAgU1BUPTEzOCBEUFQ9MTM4IExFTj0x
ODIgDQpbICA4NjIuMjc1NzA2XSA8ND5JTj1ldGgxIE9VVD0gTUFDPWZmOmZmOmZmOmZmOmZm
OmZmOjAwOjE2OjM2OmE3OmQwOmYzOjA4OjAwIFNSQz0xNzIuMTYuMS4yNDAgRFNUPTE3Mi4x
Ni4yNTUuMjU1IExFTj03OCBUT1M9MHgwMCBQUkVDPTB4MDAgVFRMPTEyOCBJRD01NzA0IFBS
T1RPPVVEUCBTUFQ9MTM3IERQVD0xMzcgTEVOPTU4IA0KWyAgODYzLjA0NTE2N10gPDQ+SU49
ZXRoMSBPVVQ9IE1BQz1mZjpmZjpmZjpmZjpmZjpmZjowMDoxNjozNjphNzpkMDpmMzowODow
MCBTUkM9MTcyLjE2LjEuMjQwIERTVD0xNzIuMTYuMjU1LjI1NSBMRU49NzggVE9TPTB4MDAg
UFJFQz0weDAwIFRUTD0xMjggSUQ9NTcwNSBQUk9UTz1VRFAgU1BUPTEzNyBEUFQ9MTM3IExF
Tj01OCANClsgIDg2My43OTUwNTBdIDw0PklOPWV0aDEgT1VUPSBNQUM9ZmY6ZmY6ZmY6ZmY6
ZmY6ZmY6MDA6MTY6MzY6YTc6ZDA6ZjM6MDg6MDAgU1JDPTE3Mi4xNi4xLjI0MCBEU1Q9MTcy
LjE2LjI1NS4yNTUgTEVOPTc4IFRPUz0weDAwIFBSRUM9MHgwMCBUVEw9MTI4IElEPTU3MDYg
UFJPVE89VURQIFNQVD0xMzcgRFBUPTEzNyBMRU49NTggDQpbICA4NjYuNTQ1MTgwXSA8ND5J
Tj1ldGgxIE9VVD0gTUFDPWZmOmZmOmZmOmZmOmZmOmZmOjAwOjE2OjM2OmE3OmQwOmYzOjA4
OjAwIFNSQz0xNzIuMTYuMS4yNDAgRFNUPTE3Mi4xNi4yNTUuMjU1IExFTj0yMDIgVE9TPTB4
MDAgUFJFQz0weDAwIFRUTD0xMjggSUQ9NTcwNyBQUk9UTz1VRFAgU1BUPTEzOCBEUFQ9MTM4
IExFTj0xODIgDQpbICA4NjYuNTQ4NDgwXSA8ND5JTj1ldGgxIE9VVD0gTUFDPWZmOmZmOmZm
OmZmOmZmOmZmOjAwOjE2OjM2OmE3OmQwOmYzOjA4OjAwIFNSQz0xNzIuMTYuMS4yNDAgRFNU
PTE3Mi4xNi4yNTUuMjU1IExFTj03OCBUT1M9MHgwMCBQUkVDPTB4MDAgVFRMPTEyOCBJRD01
NzA5IFBST1RPPVVEUCBTUFQ9MTM3IERQVD0xMzcgTEVOPTU4IA0KWyAgODY3LjMxODUwMl0g
PDQ+SU49ZXRoMSBPVVQ9IE1BQz1mZjpmZjpmZjpmZjpmZjpmZjowMDoxNjozNjphNzpkMDpm
MzowODowMCBTUkM9MTcyLjE2LjEuMjQwIERTVD0xNzIuMTYuMjU1LjI1NSBMRU49NzggVE9T
PTB4MDAgUFJFQz0weDAwIFRUTD0xMjggSUQ9NTcxMCBQUk9UTz1VRFAgU1BUPTEzNyBEUFQ9
MTM3IExFTj01OCANClsgIDg2OC4wNjg1MDJdIDw0PklOPWV0aDEgT1VUPSBNQUM9ZmY6ZmY6
ZmY6ZmY6ZmY6ZmY6MDA6MTY6MzY6YTc6ZDA6ZjM6MDg6MDAgU1JDPTE3Mi4xNi4xLjI0MCBE
U1Q9MTcyLjE2LjI1NS4yNTUgTEVOPTc4IFRPUz0weDAwIFBSRUM9MHgwMCBUVEw9MTI4IElE
PTU3MTEgUFJPVE89VURQIFNQVD0xMzcgRFBUPTEzNyBMRU49NTggDQpbICA4NzAuODE4NzA5
XSA8ND5JTj1ldGgxIE9VVD0gTUFDPWZmOmZmOmZmOmZmOmZmOmZmOjAwOjE2OjM2OmE3OmQw
OmYzOjA4OjAwIFNSQz0xNzIuMTYuMS4yNDAgRFNUPTE3Mi4xNi4yNTUuMjU1IExFTj0yMDIg
VE9TPTB4MDAgUFJFQz0weDAwIFRUTD0xMjggSUQ9NTcxMiBQUk9UTz1VRFAgU1BUPTEzOCBE
UFQ9MTM4IExFTj0xODIgDQpbICA4NzAuODQ4OTM5XSA8ND5JTj1ldGgxIE9VVD0gTUFDPWZm
OmZmOmZmOmZmOmZmOmZmOjAwOjE2OjM2OmE3OmQwOmYzOjA4OjAwIFNSQz0xNzIuMTYuMS4y
NDAgRFNUPTE3Mi4xNi4yNTUuMjU1IExFTj03OCBUT1M9MHgwMCBQUkVDPTB4MDAgVFRMPTEy
OCBJRD01NzE0IFBST1RPPVVEUCBTUFQ9MTM3IERQVD0xMzcgTEVOPTU4IA0KWyAgODcxLjU5
MTg5NF0gPDQ+SU49ZXRoMSBPVVQ9IE1BQz1mZjpmZjpmZjpmZjpmZjpmZjowMDoxNjozNjph
NzpkMDpmMzowODowMCBTUkM9MTcyLjE2LjEuMjQwIERTVD0xNzIuMTYuMjU1LjI1NSBMRU49
NzggVE9TPTB4MDAgUFJFQz0weDAwIFRUTD0xMjggSUQ9NTcxNSBQUk9UTz1VRFAgU1BUPTEz
NyBEUFQ9MTM3IExFTj01OCANClsgIDg3Mi4zNDE4NzFdIDw0PklOPWV0aDEgT1VUPSBNQUM9
ZmY6ZmY6ZmY6ZmY6ZmY6ZmY6MDA6MTY6MzY6YTc6ZDA6ZjM6MDg6MDAgU1JDPTE3Mi4xNi4x
LjI0MCBEU1Q9MTcyLjE2LjI1NS4yNTUgTEVOPTc4IFRPUz0weDAwIFBSRUM9MHgwMCBUVEw9
MTI4IElEPTU3MTYgUFJPVE89VURQIFNQVD0xMzcgRFBUPTEzNyBMRU49NTggDQpbICA4NzUu
MTE1MTI1XSA8ND5JTj1ldGgxIE9VVD0gTUFDPWZmOmZmOmZmOmZmOmZmOmZmOjAwOjE2OjM2
OmE3OmQwOmYzOjA4OjAwIFNSQz0xNzIuMTYuMS4yNDAgRFNUPTE3Mi4xNi4yNTUuMjU1IExF
Tj03OCBUT1M9MHgwMCBQUkVDPTB4MDAgVFRMPTEyOCBJRD01NzE4IFBST1RPPVVEUCBTUFQ9
MTM3IERQVD0xMzcgTEVOPTU4IA0KWyAgODc1Ljg2NTM4Nl0gPDQ+SU49ZXRoMSBPVVQ9IE1B
Qz1mZjpmZjpmZjpmZjpmZjpmZjowMDoxNjozNjphNzpkMDpmMzowODowMCBTUkM9MTcyLjE2
LjEuMjQwIERTVD0xNzIuMTYuMjU1LjI1NSBMRU49NzggVE9TPTB4MDAgUFJFQz0weDAwIFRU
TD0xMjggSUQ9NTcxOSBQUk9UTz1VRFAgU1BUPTEzNyBEUFQ9MTM3IExFTj01OCANClsgIDg3
Ni42MTUyMzRdIDw0PklOPWV0aDEgT1VUPSBNQUM9ZmY6ZmY6ZmY6ZmY6ZmY6ZmY6MDA6MTY6
MzY6YTc6ZDA6ZjM6MDg6MDAgU1JDPTE3Mi4xNi4xLjI0MCBEU1Q9MTcyLjE2LjI1NS4yNTUg
TEVOPTc4IFRPUz0weDAwIFBSRUM9MHgwMCBUVEw9MTI4IElEPTU3MjAgUFJPVE89VURQIFNQ
VD0xMzcgRFBUPTEzNyBMRU49NTggDQpbICA4OTcuMTYxMTE5XSBkZXZpY2UgdmlmMS4wIGVu
dGVyZWQgcHJvbWlzY3VvdXMgbW9kZQ0KbWFwcGluZyBrZXJuZWwgaW50byBwaHlzaWNhbCBt
ZW1vcnkNCmFib3V0IHRvIGdldCBzdGFydGVkLi4uDQpbICA4OTcuNjk2NjE5XSB4ZW5fYnJp
ZGdlOiBwb3J0IDEodmlmMS4wKSBlbnRlcmVkIGZvcndhcmRpbmcgc3RhdGUNClsgIDg5Ny43
MTYyMTldIHhlbl9icmlkZ2U6IHBvcnQgMSh2aWYxLjApIGVudGVyZWQgZm9yd2FyZGluZyBz
dGF0ZQ0KWyAgODk4LjEyOTQ2NV0gLS0tLS0tLS0tLS0tWyBjdXQgaGVyZSBdLS0tLS0tLS0t
LS0tDQpbICA4OTguMTMyMjA5XSBrZXJuZWwgQlVHIGF0IGRyaXZlcnMveGVuL2JhbGxvb24u
YzozNTkhDQpbICA4OTguMTMyMjA5XSBpbnZhbGlkIG9wY29kZTogMDAwMCBbIzFdIFBSRUVN
UFQgU01QIA0KWyAgODk4LjEzMjIwOV0gTW9kdWxlcyBsaW5rZWQgaW46DQpbICA4OTguMTMy
MjA5XSBDUFUgMCANClsgIDg5OC4xMzIyMDldIFBpZDogMzMzOCwgY29tbToga3dvcmtlci8w
OjEgTm90IHRhaW50ZWQgMy42LjAtcmM0LTIwMTIwODMwKyAjNjYgU3lzdGVtIG1hbnVmYWN0
dXJlciBTeXN0ZW0gUHJvZHVjdCBOYW1lL1A1US1FTSBETw0KWyAgODk4LjEzMjIwOV0gUklQ
OiBlMDMwOls8ZmZmZmZmZmY4MTMzYjIwNj5dICBbPGZmZmZmZmZmODEzM2IyMDY+XSBiYWxs
b29uX3Byb2Nlc3MrMHgzMzYvMHgzNDANClsgIDg5OC4xMzIyMDldIFJTUDogZTAyYjpmZmZm
ODgwMDM3YjRkY2UwICBFRkxBR1M6IDAwMDEwMjEzDQpbICA4OTguMTMyMjA5XSBSQVg6IDAw
MDAwMDAwMjQyYjAwMDAgUkJYOiBmZmZmZWEwMDAwZGZhZGMwIFJDWDogMDAwMDAwMDAwMDAw
MDAwMA0KWyAgODk4LjEzMjIwOV0gUkRYOiAwMDAwMDAwMDAwMDM3ZWI3IFJTSTogMDAwMDAw
MDBkZWFkYmVlZiBSREk6IDAwMDAwMDAwMDAwMDAwYjcNClsgIDg5OC4xMzIyMDldIFJCUDog
ZmZmZjg4MDAzN2I0ZGQ0MCBSMDg6IGZmZmZlYTAwMDBkZmFkZTAgUjA5OiAyMjIyMjIyMjIy
MjIyMjIyDQpbICA4OTguMTMyMjA5XSBSMTA6IDIyMjIyMjIyMjIyMjIyMjIgUjExOiAyMjIy
MjIyMjIyMjIyMjIyIFIxMjogMDAwMDAwMDAwMDAwMDAwMA0KWyAgODk4LjEzMjIwOV0gUjEz
OiBmZmZmZWEwMDAwZGZhZGUwIFIxNDogMDAwMDE2MDAwMDAwMDAwMCBSMTU6IDAwMDAwMDAw
MDAwMDAwMDENClsgIDg5OC4xMzIyMDldIEZTOiAgMDAwMDdmZDRiZDBlYzc0MCgwMDAwKSBH
UzpmZmZmODgwMDNmYzAwMDAwKDAwMDApIGtubEdTOjAwMDAwMDAwMDAwMDAwMDANClsgIDg5
OC4xMzIyMDldIENTOiAgZTAzMyBEUzogMDAwMCBFUzogMDAwMCBDUjA6IDAwMDAwMDAwODAw
NTAwM2INClsgIDg5OC4xMzIyMDldIENSMjogMDAwMDdmZDRiMzg3ZDAwMCBDUjM6IDAwMDAw
MDAwMzkyMGEwMDAgQ1I0OiAwMDAwMDAwMDAwMDQyNjYwDQpbICA4OTguMTMyMjA5XSBEUjA6
IDAwMDAwMDAwMDAwMDAwMDAgRFIxOiAwMDAwMDAwMDAwMDAwMDAwIERSMjogMDAwMDAwMDAw
MDAwMDAwMA0KWyAgODk4LjEzMjIwOV0gRFIzOiAwMDAwMDAwMDAwMDAwMDAwIERSNjogMDAw
MDAwMDBmZmZmMGZmMCBEUjc6IDAwMDAwMDAwMDAwMDA0MDANClsgIDg5OC4xMzIyMDldIFBy
b2Nlc3Mga3dvcmtlci8wOjEgKHBpZDogMzMzOCwgdGhyZWFkaW5mbyBmZmZmODgwMDM3YjRj
MDAwLCB0YXNrIGZmZmY4ODAwMzk4ZmUxODApDQpbICA4OTguMTMyMjA5XSBTdGFjazoNClsg
IDg5OC4xMzIyMDldICAwMDAwMDAwMDAwMDM3ZWI3IDAwMDAwMDAwMDAwMDAwMDEgZmZmZmZm
ZmY4Mjg2YzU0MCAwMDAwMDAwMDAwMDAwMDAxDQpbICA4OTguMTMyMjA5XSAgMDAwMDAwMDAw
MDAwMDAwMCAwMDAwMDAwMDAwMDA3ZmYwIGZmZmY4ODAwMzdiNGRkMjAgZmZmZmZmZmY4MWU0
MmE2MA0KWyAgODk4LjEzMjIwOV0gIGZmZmY4ODAwMzc5OWM2YzAgZmZmZjg4MDAzZmMxNjcw
MCBmZmZmODgwMDNmYzBlMDAwIGZmZmY4ODAwMzdiNGRkOTANClsgIDg5OC4xMzIyMDldIENh
bGwgVHJhY2U6DQpbICA4OTguMTMyMjA5XSAgWzxmZmZmZmZmZjgxMDdmYjhmPl0gcHJvY2Vz
c19vbmVfd29yaysweDFiZi8weDRhMA0KWyAgODk4LjEzMjIwOV0gIFs8ZmZmZmZmZmY4MTA3
ZmIzMD5dID8gcHJvY2Vzc19vbmVfd29yaysweDE2MC8weDRhMA0KWyAgODk4LjEzMjIwOV0g
IFs8ZmZmZmZmZmY4MTg0OTE5MT5dID8gX19zY2hlZHVsZSsweDQ3MS8weDhhMA0KWyAgODk4
LjEzMjIwOV0gIFs8ZmZmZmZmZmY4MTMzYWVkMD5dID8gZGVjcmVhc2VfcmVzZXJ2YXRpb24r
MHgyZDAvMHgyZDANClsgIDg5OC4xMzIyMDldICBbPGZmZmZmZmZmODEwODAyNTI+XSB3b3Jr
ZXJfdGhyZWFkKzB4MTUyLzB4NDcwDQpbICA4OTguMTMyMjA5XSAgWzxmZmZmZmZmZjgxODRh
ZDg1Pl0gPyBfcmF3X3NwaW5fdW5sb2NrX2lycXJlc3RvcmUrMHg3NS8weGEwDQpbICA4OTgu
MTMyMjA5XSAgWzxmZmZmZmZmZjgxMGFlNGRkPl0gPyB0cmFjZV9oYXJkaXJxc19vbisweGQv
MHgxMA0KWyAgODk4LjEzMjIwOV0gIFs8ZmZmZmZmZmY4MTg0YWQ2Mz5dID8gX3Jhd19zcGlu
X3VubG9ja19pcnFyZXN0b3JlKzB4NTMvMHhhMA0KWyAgODk4LjEzMjIwOV0gIFs8ZmZmZmZm
ZmY4MTA4MDEwMD5dID8gbWFuYWdlX3dvcmtlcnMrMHgyOTAvMHgyOTANClsgIDg5OC4xMzIy
MDldICBbPGZmZmZmZmZmODEwODc2OTY+XSBrdGhyZWFkKzB4OTYvMHhhMA0KWyAgODk4LjEz
MjIwOV0gIFs8ZmZmZmZmZmY4MTg0Y2I4ND5dIGtlcm5lbF90aHJlYWRfaGVscGVyKzB4NC8w
eDEwDQpbICA4OTguMTMyMjA5XSAgWzxmZmZmZmZmZjgxODRiMTM0Pl0gPyByZXRpbnRfcmVz
dG9yZV9hcmdzKzB4MTMvMHgxMw0KWyAgODk4LjEzMjIwOV0gIFs8ZmZmZmZmZmY4MTg0Y2I4
MD5dID8gZ3NfY2hhbmdlKzB4MTMvMHgxMw0KWyAgODk4LjEzMjIwOV0gQ29kZTogZmYgMGYg
MWYgNDAgMDAgNDggODkgZDggZTkgMjIgZmUgZmYgZmYgMGYgMGIgZWIgZmUgNDggODkgZDcg
NDggODkgNTUgYTAgZTggMTggZTcgY2MgZmYgNDggODMgZjggZmYgNDggOGIgNTUgYTAgMGYg
ODQgNzQgZmUgZmYgZmYgPDBmPiAwYiBlYiBmZSA2NiAwZiAxZiA0NCAwMCAwMCA1NSA0OCA4
OSBlNSA0MSA1NyA0MSA1NiA0MSA4OSBkNiANClsgIDg5OC4xMzIyMDldIFJJUCAgWzxmZmZm
ZmZmZjgxMzNiMjA2Pl0gYmFsbG9vbl9wcm9jZXNzKzB4MzM2LzB4MzQwDQpbICA4OTguMTMy
MjA5XSAgUlNQIDxmZmZmODgwMDM3YjRkY2UwPg0KWyAgODk4LjczODIzM10gLS0tWyBlbmQg
dHJhY2UgM2Y3YWY1MDI4NWVkYjdiYiBdLS0tDQpbICA4OTguNzQ5MDAzXSBCVUc6IHVuYWJs
ZSB0byBoYW5kbGUga2VybmVsIHBhZ2luZyByZXF1ZXN0IGF0IGZmZmZmZmZmZmZmZmZmZjgN
ClsgIDg5OC43NTIyMzddIElQOiBbPGZmZmZmZmZmODEwODZlZWI+XSBrdGhyZWFkX2RhdGEr
MHhiLzB4MjANClsgIDg5OC43NTIyMzddIFBHRCAxZTBkMDY3IFBVRCAxZTBlMDY3IFBNRCAw
IA0KWyAgODk4Ljc1MjIzN10gT29wczogMDAwMCBbIzJdIFBSRUVNUFQgU01QIA0KWyAgODk4
Ljc1MjIzN10gTW9kdWxlcyBsaW5rZWQgaW46DQpbICA4OTguNzUyMjM3XSBDUFUgMCANClsg
IDg5OC43NTIyMzddIFBpZDogMzMzOCwgY29tbToga3dvcmtlci8wOjEgVGFpbnRlZDogRyAg
ICAgIEQgICAgICAzLjYuMC1yYzQtMjAxMjA4MzArICM2NiBTeXN0ZW0gbWFudWZhY3R1cmVy
IFN5c3RlbSBQcm9kdWN0IE5hbWUvUDVRLUVNIERPDQpbICA4OTguNzUyMjM3XSBSSVA6IGUw
MzA6WzxmZmZmZmZmZjgxMDg2ZWViPl0gIFs8ZmZmZmZmZmY4MTA4NmVlYj5dIGt0aHJlYWRf
ZGF0YSsweGIvMHgyMA0KWyAgODk4Ljc1MjIzN10gUlNQOiBlMDJiOmZmZmY4ODAwMzdiNGQ4
OTggIEVGTEFHUzogMDAwMTAwODINClsgIDg5OC43NTIyMzddIFJBWDogMDAwMDAwMDAwMDAw
MDAwMCBSQlg6IGZmZmY4ODAwM2ZjMTJlODAgUkNYOiAwMDAwMDAwMDAwMDAwMDAwDQpbICA4
OTguNzUyMjM3XSBSRFg6IGZmZmZmZmZmODIwMDU3YTAgUlNJOiAwMDAwMDAwMDAwMDAwMDAw
IFJESTogZmZmZjg4MDAzOThmZTE4MA0KWyAgODk4Ljc1MjIzN10gUkJQOiBmZmZmODgwMDM3
YjRkODk4IFIwODogZmZmZjg4MDAzOThmZTFmMCBSMDk6IDAwMDAwMDAwMDAwMDA0MDANClsg
IDg5OC43NTIyMzddIFIxMDogMDAwMDAwMDAwMDAwMDAwMCBSMTE6IDAwMDAwMDAwMDAwMDAw
MDEgUjEyOiAwMDAwMDAwMDAwMDAwMDAwDQpbICA4OTguNzUyMjM3XSBSMTM6IDAwMDAwMDAw
MDAwMDAwMDAgUjE0OiBmZmZmODgwMDM3YjRkN2I4IFIxNTogZmZmZjg4MDAzN2I0ZGE5MA0K
WyAgODk4Ljc1MjIzN10gRlM6ICAwMDAwN2ZkNGJkMGVjNzQwKDAwMDApIEdTOmZmZmY4ODAw
M2ZjMDAwMDAoMDAwMCkga25sR1M6MDAwMDAwMDAwMDAwMDAwMA0KWyAgODk4Ljc1MjIzN10g
Q1M6ICBlMDMzIERTOiAwMDAwIEVTOiAwMDAwIENSMDogMDAwMDAwMDA4MDA1MDAzYg0KWyAg
ODk4Ljc1MjIzN10gQ1IyOiBmZmZmZmZmZmZmZmZmZmY4IENSMzogMDAwMDAwMDAzOTIwYTAw
MCBDUjQ6IDAwMDAwMDAwMDAwNDI2NjANClsgIDg5OC43NTIyMzddIERSMDogMDAwMDAwMDAw
MDAwMDAwMCBEUjE6IDAwMDAwMDAwMDAwMDAwMDAgRFIyOiAwMDAwMDAwMDAwMDAwMDAwDQpb
ICA4OTguNzUyMjM3XSBEUjM6IDAwMDAwMDAwMDAwMDAwMDAgRFI2OiAwMDAwMDAwMGZmZmYw
ZmYwIERSNzogMDAwMDAwMDAwMDAwMDQwMA0KWyAgODk4Ljc1MjIzN10gUHJvY2VzcyBrd29y
a2VyLzA6MSAocGlkOiAzMzM4LCB0aHJlYWRpbmZvIGZmZmY4ODAwMzdiNGMwMDAsIHRhc2sg
ZmZmZjg4MDAzOThmZTE4MCkNClsgIDg5OC43NTIyMzddIFN0YWNrOg0KWyAgODk4Ljc1MjIz
N10gIGZmZmY4ODAwMzdiNGQ4YzggZmZmZmZmZmY4MTA4MzA2YyAwMDAwMDAwMDAwMDAwMDAw
IGZmZmY4ODAwM2ZjMTJlODANClsgIDg5OC43NTIyMzddICAwMDAwMDAwMDAwMDAwMDAwIGZm
ZmY4ODAwMzk4ZmU1MjggZmZmZjg4MDAzN2I0ZGExOCBmZmZmZmZmZjgxODQ5MzFmDQpbICA4
OTguNzUyMjM3XSAgMDAwMDAwMDAwMDAwMDAwMCBmZmZmZmZmZjgxMDgzYmI4IGZmZmY4ODAw
Mzk4ZmUxODAgMDAwMDAwMDAwMDAxMmU4MA0KWyAgODk4Ljc1MjIzN10gQ2FsbCBUcmFjZToN
ClsgIDg5OC43NTIyMzddICBbPGZmZmZmZmZmODEwODMwNmM+XSB3cV93b3JrZXJfc2xlZXBp
bmcrMHgxYy8weDkwDQpbICA4OTguNzUyMjM3XSAgWzxmZmZmZmZmZjgxODQ5MzFmPl0gX19z
Y2hlZHVsZSsweDVmZi8weDhhMA0KWyAgODk4Ljc1MjIzN10gIFs8ZmZmZmZmZmY4MTA4M2Ji
OD5dID8gZnJlZV9waWQrMHgxOC8weGMwDQpbICA4OTguNzUyMjM3XSAgWzxmZmZmZmZmZjgx
MDYwMmE3Pl0gPyBzaGExX3RyYW5zZm9ybV9zc3NlMysweDE4Ny8weGQwMA0KWyAgODk4Ljc1
MjIzN10gIFs8ZmZmZmZmZmY4MTBiMWE5ND5dID8gbG9ja19hY3F1aXJlKzB4ZTQvMHgxMTAN
ClsgIDg5OC43NTIyMzddICBbPGZmZmZmZmZmODEwNmNmYTc+XSA/IGRvX2V4aXQrMHg0ZTcv
MHg4ZTANClsgIDg5OC43NTIyMzddICBbPGZmZmZmZmZmODEwZTI3ZjI+XSA/IGNhbGxfcmN1
KzB4MTIvMHgyMA0KWyAgODk4Ljc1MjIzN10gIFs8ZmZmZmZmZmY4MTBiMWYwMT5dID8gbG9j
a19yZWxlYXNlKzB4MTExLzB4MjYwDQpbICA4OTguNzUyMjM3XSAgWzxmZmZmZmZmZjgxODQ5
NjU0Pl0gc2NoZWR1bGUrMHgyNC8weDcwDQpbICA4OTguNzUyMjM3XSAgWzxmZmZmZmZmZjgx
MDZkMDc0Pl0gZG9fZXhpdCsweDViNC8weDhlMA0KWyAgODk4Ljc1MjIzN10gIFs8ZmZmZmZm
ZmY4MTAxMDI0MD5dIG9vcHNfZW5kKzB4YjAvMHhmMA0KWyAgODk4Ljc1MjIzN10gIFs8ZmZm
ZmZmZmY4MTAxMDNiNj5dIGRpZSsweDU2LzB4OTANClsgIDg5OC43NTIyMzddICBbPGZmZmZm
ZmZmODEwMGQ2YzQ+XSBkb190cmFwKzB4YzQvMHgxNzANClsgIDg5OC43NTIyMzddICBbPGZm
ZmZmZmZmODEwMGRiZTI+XSA/IGRvX2ludmFsaWRfb3ArMHg3Mi8weGMwDQpbICA4OTguNzUy
MjM3XSAgWzxmZmZmZmZmZjgxMDBkYzE2Pl0gZG9faW52YWxpZF9vcCsweGE2LzB4YzANClsg
IDg5OC43NTIyMzddICBbPGZmZmZmZmZmODEzM2IyMDY+XSA/IGJhbGxvb25fcHJvY2Vzcysw
eDMzNi8weDM0MA0KWyAgODk4Ljc1MjIzN10gIFs8ZmZmZmZmZmY4MTBhYzllOD5dID8gdHJh
Y2VfaGFyZGlycXNfb2ZmX2NhbGxlcisweDc4LzB4MTUwDQpbICA4OTguNzUyMjM3XSAgWzxm
ZmZmZmZmZjgxMmIyOWZkPl0gPyB0cmFjZV9oYXJkaXJxc19vZmZfdGh1bmsrMHgzYS8weDNj
DQpbICA4OTguNzUyMjM3XSAgWzxmZmZmZmZmZjgxODRiMTY0Pl0gPyByZXN0b3JlX2FyZ3Mr
MHgzMC8weDMwDQpbICA4OTguNzUyMjM3XSAgWzxmZmZmZmZmZjgxODRjOWZiPl0gaW52YWxp
ZF9vcCsweDFiLzB4MjANClsgIDg5OC43NTIyMzddICBbPGZmZmZmZmZmODEzM2IyMDY+XSA/
IGJhbGxvb25fcHJvY2VzcysweDMzNi8weDM0MA0KWyAgODk4Ljc1MjIzN10gIFs8ZmZmZmZm
ZmY4MTA3ZmI4Zj5dIHByb2Nlc3Nfb25lX3dvcmsrMHgxYmYvMHg0YTANClsgIDg5OC43NTIy
MzddICBbPGZmZmZmZmZmODEwN2ZiMzA+XSA/IHByb2Nlc3Nfb25lX3dvcmsrMHgxNjAvMHg0
YTANClsgIDg5OC43NTIyMzddICBbPGZmZmZmZmZmODE4NDkxOTE+XSA/IF9fc2NoZWR1bGUr
MHg0NzEvMHg4YTANClsgIDg5OC43NTIyMzddICBbPGZmZmZmZmZmODEzM2FlZDA+XSA/IGRl
Y3JlYXNlX3Jlc2VydmF0aW9uKzB4MmQwLzB4MmQwDQpbICA4OTguNzUyMjM3XSAgWzxmZmZm
ZmZmZjgxMDgwMjUyPl0gd29ya2VyX3RocmVhZCsweDE1Mi8weDQ3MA0KWyAgODk4Ljc1MjIz
N10gIFs8ZmZmZmZmZmY4MTg0YWQ4NT5dID8gX3Jhd19zcGluX3VubG9ja19pcnFyZXN0b3Jl
KzB4NzUvMHhhMA0KWyAgODk4Ljc1MjIzN10gIFs8ZmZmZmZmZmY4MTBhZTRkZD5dID8gdHJh
Y2VfaGFyZGlycXNfb24rMHhkLzB4MTANClsgIDg5OC43NTIyMzddICBbPGZmZmZmZmZmODE4
NGFkNjM+XSA/IF9yYXdfc3Bpbl91bmxvY2tfaXJxcmVzdG9yZSsweDUzLzB4YTANClsgIDg5
OC43NTIyMzddICBbPGZmZmZmZmZmODEwODAxMDA+XSA/IG1hbmFnZV93b3JrZXJzKzB4Mjkw
LzB4MjkwDQpbICA4OTguNzUyMjM3XSAgWzxmZmZmZmZmZjgxMDg3Njk2Pl0ga3RocmVhZCsw
eDk2LzB4YTANClsgIDg5OC43NTIyMzddICBbPGZmZmZmZmZmODE4NGNiODQ+XSBrZXJuZWxf
dGhyZWFkX2hlbHBlcisweDQvMHgxMA0KWyAgODk4Ljc1MjIzN10gIFs8ZmZmZmZmZmY4MTg0
YjEzND5dID8gcmV0aW50X3Jlc3RvcmVfYXJncysweDEzLzB4MTMNClsgIDg5OC43NTIyMzdd
ICBbPGZmZmZmZmZmODE4NGNiODA+XSA/IGdzX2NoYW5nZSsweDEzLzB4MTMNClsgIDg5OC43
NTIyMzddIENvZGU6IDU1IDY1IDQ4IDhiIDA0IDI1IDgwIGM2IDAwIDAwIDQ4IDhiIDgwIDUw
IDAzIDAwIDAwIDQ4IDg5IGU1IDhiIDQwIGYwIGM5IGMzIDBmIDFmIDgwIDAwIDAwIDAwIDAw
IDQ4IDhiIDg3IDUwIDAzIDAwIDAwIDU1IDQ4IDg5IGU1IDw0OD4gOGIgNDAgZjggYzkgYzMg
NjYgNjYgNjYgNjYgNjYgNjYgMmUgMGYgMWYgODQgMDAgMDAgMDAgMDAgMDAgDQpbICA4OTgu
NzUyMjM3XSBSSVAgIFs8ZmZmZmZmZmY4MTA4NmVlYj5dIGt0aHJlYWRfZGF0YSsweGIvMHgy
MA0KWyAgODk4Ljc1MjIzN10gIFJTUCA8ZmZmZjg4MDAzN2I0ZDg5OD4NClsgIDg5OC43NTIy
MzddIENSMjogZmZmZmZmZmZmZmZmZmZmOA0KWyAgODk4Ljc1MjIzN10gLS0tWyBlbmQgdHJh
Y2UgM2Y3YWY1MDI4NWVkYjdiYyBdLS0tDQpbICA4OTguNzUyMjM3XSBGaXhpbmcgcmVjdXJz
aXZlIGZhdWx0IGJ1dCByZWJvb3QgaXMgbmVlZGVkIQ0KWyAgOTEyLjc0NjYyNV0geGVuX2Jy
aWRnZTogcG9ydCAxKHZpZjEuMCkgZW50ZXJlZCBmb3J3YXJkaW5nIHN0YXRlDQo=
------------0320050151C2718BB
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

------------0320050151C2718BB--



From xen-devel-bounces@lists.xen.org Tue Sep 04 16:44:44 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Sep 2012 16:44: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 1T8wEj-0005Mv-GH; Tue, 04 Sep 2012 16:44:25 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1T8wEh-0005Mp-LC
	for xen-devel@lists.xen.org; Tue, 04 Sep 2012 16:44:24 +0000
Received: from [85.158.138.51:22982] by server-9.bemta-3.messagelabs.com id
	38/34-15390-6EF26405; Tue, 04 Sep 2012 16:44:22 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1346777059!28599291!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzI5MDMy\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16514 invoked from network); 4 Sep 2012 16:44:22 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-11.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 4 Sep 2012 16:44:22 -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 q84GiFiS031848
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 4 Sep 2012 16:44:17 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
	q84GiEgg010654
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 4 Sep 2012 16:44:14 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
	q84GiE8g025887; Tue, 4 Sep 2012 11:44:14 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 04 Sep 2012 09:44:14 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 753E4402BA; Tue,  4 Sep 2012 12:33:47 -0400 (EDT)
Date: Tue, 4 Sep 2012 12:33:47 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Sander Eikelenboom <linux@eikelenboom.it>
Message-ID: <20120904163347.GH23361@phenom.dumpdata.com>
References: <1136369816.20120904183757@eikelenboom.it>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1136369816.20120904183757@eikelenboom.it>
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
Subject: Re: [Xen-devel] dom0 linux 3.6.0-rc4,
 crash due to ballooning althoug dom0_mem=X, max:X set
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Sep 04, 2012 at 06:37:57PM +0200, Sander Eikelenboom wrote:
> Hi Konrad,
> 
> This seems to happen only on a intel machine i'm trying to setup as a development machine (haven't seen it on my amd).
> It boots fine, i have dom0_mem=1024M,max:1024M set, the machine has 2G of mem.

Is this only with Xen 4.2? As, does Xen 4.1 work?
> 
> Dom0 and guest kernel are 3.6.0-rc4 with config:

If you back out:

f393387d160211f60398d58463a7e65
Author: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date:   Fri Aug 17 16:43:28 2012 -0400

    xen/setup: Fix one-off error when adding for-balloon PFNs to the P2M.

Do you see this bug? (Either with Xen 4.1 or Xen 4.2)?

> [*] Xen memory balloon driver
> [*]   Scrub pages before returning them to system
> 
> From http://wiki.xen.org/wiki/Do%EF%BB%BFm0_Memory_%E2%80%94_Where_It_Has_Not_Gone , I thought this should be okay
> 
> But when trying to start a PV guest with 512MB mem, the machine (dom0) crashes with the stacktrace below (complete serial-log.txt attached).
> 
> From the:
> "mapping kernel into physical memory
> about to get started..."
> 
> I would almost say it's trying to reload dom0 ?
> 
> 
> [  897.161119] device vif1.0 entered promiscuous mode
> mapping kernel into physical memory
> about to get started...
> [  897.696619] xen_bridge: port 1(vif1.0) entered forwarding state
> [  897.716219] xen_bridge: port 1(vif1.0) entered forwarding state
> [  898.129465] ------------[ cut here ]------------
> [  898.132209] kernel BUG at drivers/xen/balloon.c:359!
> [  898.132209] invalid opcode: 0000 [#1] PREEMPT SMP 

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

From xen-devel-bounces@lists.xen.org Tue Sep 04 16:44:44 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Sep 2012 16:44: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 1T8wEj-0005Mv-GH; Tue, 04 Sep 2012 16:44:25 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1T8wEh-0005Mp-LC
	for xen-devel@lists.xen.org; Tue, 04 Sep 2012 16:44:24 +0000
Received: from [85.158.138.51:22982] by server-9.bemta-3.messagelabs.com id
	38/34-15390-6EF26405; Tue, 04 Sep 2012 16:44:22 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1346777059!28599291!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzI5MDMy\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16514 invoked from network); 4 Sep 2012 16:44:22 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-11.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 4 Sep 2012 16:44:22 -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 q84GiFiS031848
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 4 Sep 2012 16:44:17 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
	q84GiEgg010654
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 4 Sep 2012 16:44:14 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
	q84GiE8g025887; Tue, 4 Sep 2012 11:44:14 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 04 Sep 2012 09:44:14 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 753E4402BA; Tue,  4 Sep 2012 12:33:47 -0400 (EDT)
Date: Tue, 4 Sep 2012 12:33:47 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Sander Eikelenboom <linux@eikelenboom.it>
Message-ID: <20120904163347.GH23361@phenom.dumpdata.com>
References: <1136369816.20120904183757@eikelenboom.it>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1136369816.20120904183757@eikelenboom.it>
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
Subject: Re: [Xen-devel] dom0 linux 3.6.0-rc4,
 crash due to ballooning althoug dom0_mem=X, max:X set
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Sep 04, 2012 at 06:37:57PM +0200, Sander Eikelenboom wrote:
> Hi Konrad,
> 
> This seems to happen only on a intel machine i'm trying to setup as a development machine (haven't seen it on my amd).
> It boots fine, i have dom0_mem=1024M,max:1024M set, the machine has 2G of mem.

Is this only with Xen 4.2? As, does Xen 4.1 work?
> 
> Dom0 and guest kernel are 3.6.0-rc4 with config:

If you back out:

f393387d160211f60398d58463a7e65
Author: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date:   Fri Aug 17 16:43:28 2012 -0400

    xen/setup: Fix one-off error when adding for-balloon PFNs to the P2M.

Do you see this bug? (Either with Xen 4.1 or Xen 4.2)?

> [*] Xen memory balloon driver
> [*]   Scrub pages before returning them to system
> 
> From http://wiki.xen.org/wiki/Do%EF%BB%BFm0_Memory_%E2%80%94_Where_It_Has_Not_Gone , I thought this should be okay
> 
> But when trying to start a PV guest with 512MB mem, the machine (dom0) crashes with the stacktrace below (complete serial-log.txt attached).
> 
> From the:
> "mapping kernel into physical memory
> about to get started..."
> 
> I would almost say it's trying to reload dom0 ?
> 
> 
> [  897.161119] device vif1.0 entered promiscuous mode
> mapping kernel into physical memory
> about to get started...
> [  897.696619] xen_bridge: port 1(vif1.0) entered forwarding state
> [  897.716219] xen_bridge: port 1(vif1.0) entered forwarding state
> [  898.129465] ------------[ cut here ]------------
> [  898.132209] kernel BUG at drivers/xen/balloon.c:359!
> [  898.132209] invalid opcode: 0000 [#1] PREEMPT SMP 

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

From xen-devel-bounces@lists.xen.org Tue Sep 04 16:44:48 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Sep 2012 16:44:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T8wEn-0005NJ-St; Tue, 04 Sep 2012 16:44:29 +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 1T8wEm-0005N6-3A
	for xen-devel@lists.xen.org; Tue, 04 Sep 2012 16:44:28 +0000
Received: from [85.158.143.35:52476] by server-2.bemta-4.messagelabs.com id
	19/FB-21239-BEF26405; Tue, 04 Sep 2012 16:44:27 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-2.tower-21.messagelabs.com!1346777054!5703510!1
X-Originating-IP: [188.40.164.121]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20215 invoked from network); 4 Sep 2012 16:44:16 -0000
Received: from static.121.164.40.188.clients.your-server.de (HELO
	smtp.eikelenboom.it) (188.40.164.121)
	by server-2.tower-21.messagelabs.com with AES256-SHA encrypted SMTP;
	4 Sep 2012 16:44:16 -0000
Received: from 128-64-ftth.onsneteindhoven.nl ([88.159.64.128]:55637
	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 1T8wB5-0004jo-8A; Tue, 04 Sep 2012 18:40:39 +0200
Date: Tue, 4 Sep 2012 18:43:45 +0200
From: Sander Eikelenboom <linux@eikelenboom.it>
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <1144695277.20120904184345@eikelenboom.it>
To: Wei Wang <wei.wang2@amd.com>
In-Reply-To: <5044CAD7.8030800@amd.com>
References: <40501859.20120902104331@eikelenboom.it>
	<CC6932C2.3D99D%keir.xen@gmail.com>
	<217459398.20120902171441@eikelenboom.it>
	<5044CAD7.8030800@amd.com>
MIME-Version: 1.0
Content-Type: multipart/mixed;
 boundary="----------0C30E31DB2590EB56"
Cc: Keir Fraser <keir.xen@gmail.com>, Jan Beulich <JBeulich@suse.com>,
	Santosh Jodh <Santosh.Jodh@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Using debug-key 'o:  Dump IOMMU p2m table,
	locks up machine
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

------------0C30E31DB2590EB56
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hello Wei,

Monday, September 3, 2012, 5:20:55 PM, you wrote:

> On 09/02/2012 05:14 PM, Sander Eikelenboom wrote:
>> Sunday, September 2, 2012, 4:58:58 PM, you wrote:
>>
>>> On 02/09/2012 09:43, "Sander Eikelenboom"<linux@eikelenboom.it>  wrote:
>>
>>>>> Quite simply, there likely needs to be more tracing on the IOMMU fault path.
>>>>> That's a separate concern from your keyhandler of course, but just saying
>>>>> I'd be looking for the former rather than the latter, for diagnosing
>>>>> Sander's bug.
>>>>
>>>> Are there any printk's I could add to get more relevant info about the AMD-Vi:
>>>> IO_PAGE_FAULT ?
>>
>>> No really straightforward one. I think we need a per-IOMMU-type handler to
>>> walk the IOMMU page table for a given virtual address, and dump every
>>> page-table-entry on the path. Like an IOMMU version of show_page_walk().
>>> Personally I would suspect this is more useful than the dump-everything
>>> handlers: just give a *full* *detailed* walk for the actually interesting
>>> virtual address (the one faulted on).
>>
>>>> I have attached new output from xl dmesg, this time with iommu=debug on (the
>>>> option changed from 4.1 to 4.2).
>>
>>> Not easy to glean any more from that, without extra tracing such as
>>> described above, and/or digging into the guest to find what driver-side
>>> actions are causing the faults.
>>
>> OK, too bad!
>> With xen 4.1 i haven't experienced those page faults, but a diff between /xen/drivers/passthrough/amd in both trees show quite some changes :(

> Did you also update xen tools accordingly? Sometime I also saw a few 
> IO_PAGE_FAULTs came from nic if my tools version and HV version did not 
> match. But using recent 4.2 and corresponding xl, my tests went well.
> BTW: You could also try iommu=no-sharept to see if it helps.

Tried it and it doesn't help.
I now even got a "xl dmesg" which shows a IO_PAGE_FAULT occuring very early, before any toolstack or guest can be involved:

(XEN) [2012-09-04 15:51:17] AMD-Vi: Setup I/O page table: device id = 0x0a05, root table = 0x24d84b000, domain = 0, paging mode = 3
(XEN) [2012-09-04 15:51:17] AMD-Vi: Setup I/O page table: device id = 0x0a06, root table = 0x24d84b000, domain = 0, paging mode = 3
(XEN) [2012-09-04 15:51:17] AMD-Vi: Setup I/O page table: device id = 0x0a07, root table = 0x24d84b000, domain = 0, paging mode = 3
(XEN) [2012-09-04 15:51:17] AMD-Vi: Setup I/O page table: device id = 0x0b00, root table = 0x24d84b000, domain = 0, paging mode = 3
(XEN) [2012-09-04 15:51:17] Scrubbing Free RAM: ...........................<0>AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0a06, fault address = 0xc2c2c2c0
(XEN) [2012-09-04 15:51:18] ............................................done.
(XEN) [2012-09-04 15:51:19] Initial low memory virq threshold set at 0x4000 pages.
(XEN) [2012-09-04 15:51:19] Std. Loglevel: All
(XEN) [2012-09-04 15:51:19] Guest Loglevel: All
(XEN) [2012-09-04 15:51:19] Xen is relinquishing VGA console.


Complete dmesg attached.

> Thanks,
> Wei

>>>   -- Keir
>>
>>>>
>>>>
>>>>>   -- Keir
>>>>
>>
>>
>>
>>
>>
>>






-- 
Best regards,
 Sander                            mailto:linux@eikelenboom.it
------------0C30E31DB2590EB56
Content-Type: text/plain;
 name="xl-dmesg.txt"
Content-transfer-encoding: base64
Content-Disposition: attachment;
 filename="xl-dmesg.txt"

IF9fICBfXyAgICAgICAgICAgIF8gIF8gICAgX19fXyAgICBfX18gICAgICAgICAgICAgIF8g
IF8gICAgICAgICAgICAgICAgICAgICANCiBcIFwvIC9fX18gXyBfXyAgIHwgfHwgfCAgfF9f
XyBcICAvIF8gXCAgICBfIF9fIF9fX3wgfHwgfCAgICAgXyBfXyAgXyBfXyBfX18gDQogIFwg
IC8vIF8gXCAnXyBcICB8IHx8IHxfICAgX18pIHx8IHwgfCB8X198ICdfXy8gX198IHx8IHxf
IF9ffCAnXyBcfCAnX18vIF8gXA0KICAvICBcICBfXy8gfCB8IHwgfF9fICAgX3wgLyBfXy8g
fCB8X3wgfF9ffCB8IHwgKF9ffF9fICAgX3xfX3wgfF8pIHwgfCB8ICBfXy8NCiAvXy9cX1xf
X198X3wgfF98ICAgIHxffChfKV9fX19fKF8pX19fLyAgIHxffCAgXF9fX3wgIHxffCAgICB8
IC5fXy98X3wgIFxfX198DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgfF98ICAgICAgICAgICAgIA0KKFhFTikgWGVuIHZl
cnNpb24gNC4yLjAtcmM0LXByZSAocm9vdEBkeW5kbnMub3JnKSAoZ2NjIChEZWJpYW4gNC40
LjUtOCkgNC40LjUpIE1vbiBTZXAgIDMgMjI6MzY6MzAgQ0VTVCAyMDEyDQooWEVOKSBMYXRl
c3QgQ2hhbmdlU2V0OiBUdWUgQXVnIDI4IDIyOjQwOjQ1IDIwMTIgKzAxMDAgMjU3ODY6YTBi
NWY4MTAyYTAwDQooWEVOKSBCb290bG9hZGVyOiBHUlVCIDEuOTgrMjAxMDA4MDQtMTQrc3F1
ZWV6ZTENCihYRU4pIENvbW1hbmQgbGluZTogZG9tMF9tZW09MTAyNE0sbWF4OjEwMjRNIGxv
Z2x2bD1hbGwgbG9nbHZsX2d1ZXN0PWFsbCBjb25zb2xlX3RpbWVzdGFtcHMgdmdhPWdmeC0x
MjgweDEwMjR4MzIgY3B1aWRsZSBjcHVmcmVxPXhlbiBub3JlYm9vdCBkZWJ1ZyBsYXBpYz1k
ZWJ1ZyBhcGljX3ZlcmJvc2l0eT1kZWJ1ZyBhcGljPWRlYnVnIGlvbW11PW9uLHZlcmJvc2Us
ZGVidWcsbm8tc2hhcmVwdCBjb20xPTM4NDAwLDhuMSBjb25zb2xlPXZnYSxjb20xDQooWEVO
KSBWaWRlbyBpbmZvcm1hdGlvbjoNCihYRU4pICBWR0EgaXMgZ3JhcGhpY3MgbW9kZSAxMjgw
eDEwMjQsIDMyIGJwcA0KKFhFTikgIFZCRS9EREMgbWV0aG9kczogVjI7IEVESUQgdHJhbnNm
ZXIgdGltZTogMSBzZWNvbmRzDQooWEVOKSBEaXNjIGluZm9ybWF0aW9uOg0KKFhFTikgIEZv
dW5kIDIgTUJSIHNpZ25hdHVyZXMNCihYRU4pICBGb3VuZCAyIEVERCBpbmZvcm1hdGlvbiBz
dHJ1Y3R1cmVzDQooWEVOKSBYZW4tZTgyMCBSQU0gbWFwOg0KKFhFTikgIDAwMDAwMDAwMDAw
MDAwMDAgLSAwMDAwMDAwMDAwMDliMDAwICh1c2FibGUpDQooWEVOKSAgMDAwMDAwMDAwMDA5
YjAwMCAtIDAwMDAwMDAwMDAwYTAwMDAgKHJlc2VydmVkKQ0KKFhFTikgIDAwMDAwMDAwMDAw
ZTQwMDAgLSAwMDAwMDAwMDAwMTAwMDAwIChyZXNlcnZlZCkNCihYRU4pICAwMDAwMDAwMDAw
MTAwMDAwIC0gMDAwMDAwMDBhZmU5MDAwMCAodXNhYmxlKQ0KKFhFTikgIDAwMDAwMDAwYWZl
OTAwMDAgLSAwMDAwMDAwMGFmZTllMDAwIChBQ1BJIGRhdGEpDQooWEVOKSAgMDAwMDAwMDBh
ZmU5ZTAwMCAtIDAwMDAwMDAwYWZlZTAwMDAgKEFDUEkgTlZTKQ0KKFhFTikgIDAwMDAwMDAw
YWZlZTAwMDAgLSAwMDAwMDAwMGFmZjAwMDAwIChyZXNlcnZlZCkNCihYRU4pICAwMDAwMDAw
MGZmZTAwMDAwIC0gMDAwMDAwMDEwMDAwMDAwMCAocmVzZXJ2ZWQpDQooWEVOKSAgMDAwMDAw
MDEwMDAwMDAwMCAtIDAwMDAwMDAyNTAwMDAwMDAgKHVzYWJsZSkNCihYRU4pIEFDUEk6IFJT
RFAgMDAwRkIxMjAsIDAwMTQgKHIwIEFDUElBTSkNCihYRU4pIEFDUEk6IFJTRFQgQUZFOTAw
MDAsIDAwNDggKHIxIE1TSSAgICBPRU1TTElDICAyMDEwMDYyMiBNU0ZUICAgICAgIDk3KQ0K
KFhFTikgQUNQSTogRkFDUCBBRkU5MDIwMCwgMDA4NCAocjEgNzY0ME1TIEE3NjQwMTAwIDIw
MTAwNjIyIE1TRlQgICAgICAgOTcpDQooWEVOKSBBQ1BJOiBEU0RUIEFGRTkwNUUwLCA5NDQ5
IChyMSAgQTc2NDAgQTc2NDAxMDAgICAgICAxMDAgSU5UTCAyMDA1MTExNykNCihYRU4pIEFD
UEk6IEZBQ1MgQUZFOUUwMDAsIDAwNDANCihYRU4pIEFDUEk6IEFQSUMgQUZFOTAzOTAsIDAw
ODggKHIxIDc2NDBNUyBBNzY0MDEwMCAyMDEwMDYyMiBNU0ZUICAgICAgIDk3KQ0KKFhFTikg
QUNQSTogTUNGRyBBRkU5MDQyMCwgMDAzQyAocjEgNzY0ME1TIE9FTU1DRkcgIDIwMTAwNjIy
IE1TRlQgICAgICAgOTcpDQooWEVOKSBBQ1BJOiBTTElDIEFGRTkwNDYwLCAwMTc2IChyMSBN
U0kgICAgT0VNU0xJQyAgMjAxMDA2MjIgTVNGVCAgICAgICA5NykNCihYRU4pIEFDUEk6IE9F
TUIgQUZFOUUwNDAsIDAwNzIgKHIxIDc2NDBNUyBBNzY0MDEwMCAyMDEwMDYyMiBNU0ZUICAg
ICAgIDk3KQ0KKFhFTikgQUNQSTogU1JBVCBBRkU5QTVFMCwgMDEwOCAocjMgQU1EICAgIEZB
TV9GXzEwICAgICAgICAyIEFNRCAgICAgICAgIDEpDQooWEVOKSBBQ1BJOiBIUEVUIEFGRTlB
NkYwLCAwMDM4IChyMSA3NjQwTVMgT0VNSFBFVCAgMjAxMDA2MjIgTVNGVCAgICAgICA5NykN
CihYRU4pIEFDUEk6IElWUlMgQUZFOUE3MzAsIDAwRjggKHIxICBBTUQgICAgIFJEODkwUyAg
IDIwMjAzMSBBTUQgICAgICAgICAwKQ0KKFhFTikgQUNQSTogU1NEVCBBRkU5QTgzMCwgMERB
NCAocjEgQSBNIEkgIFBPV0VSTk9XICAgICAgICAxIEFNRCAgICAgICAgIDEpDQooWEVOKSBT
eXN0ZW0gUkFNOiA4MTkwTUIgKDgzODY3MzJrQikNCihYRU4pIFNSQVQ6IFBYTSAwIC0+IEFQ
SUMgMCAtPiBOb2RlIDANCihYRU4pIFNSQVQ6IFBYTSAwIC0+IEFQSUMgMSAtPiBOb2RlIDAN
CihYRU4pIFNSQVQ6IFBYTSAwIC0+IEFQSUMgMiAtPiBOb2RlIDANCihYRU4pIFNSQVQ6IFBY
TSAwIC0+IEFQSUMgMyAtPiBOb2RlIDANCihYRU4pIFNSQVQ6IFBYTSAwIC0+IEFQSUMgNCAt
PiBOb2RlIDANCihYRU4pIFNSQVQ6IFBYTSAwIC0+IEFQSUMgNSAtPiBOb2RlIDANCihYRU4p
IFNSQVQ6IE5vZGUgMCBQWE0gMCAwLWEwMDAwDQooWEVOKSBTUkFUOiBOb2RlIDAgUFhNIDAg
MTAwMDAwLWIwMDAwMDAwDQooWEVOKSBTUkFUOiBOb2RlIDAgUFhNIDAgMTAwMDAwMDAwLTI1
MDAwMDAwMA0KKFhFTikgTlVNQTogQWxsb2NhdGVkIG1lbW5vZGVtYXAgZnJvbSAyNGQ5YTQw
MDAgLSAyNGQ5YTcwMDANCihYRU4pIE5VTUE6IFVzaW5nIDggZm9yIHRoZSBoYXNoIHNoaWZ0
Lg0KKFhFTikgRG9tYWluIGhlYXAgaW5pdGlhbGlzZWQNCihYRU4pIHZlc2FmYjogZnJhbWVi
dWZmZXIgYXQgMHhmYjAwMDAwMCwgbWFwcGVkIHRvIDB4ZmZmZjgyYzAwMDAwMDAwMCwgdXNp
bmcgNjE0NGssIHRvdGFsIDE0MzM2aw0KKFhFTikgdmVzYWZiOiBtb2RlIGlzIDEyODB4MTAy
NHgzMiwgbGluZWxlbmd0aD01MTIwLCBmb250IDh4MTYNCihYRU4pIHZlc2FmYjogVHJ1ZWNv
bG9yOiBzaXplPTg6ODo4OjgsIHNoaWZ0PTI0OjE2Ojg6MA0KKFhFTikgZm91bmQgU01QIE1Q
LXRhYmxlIGF0IDAwMGZmNzgwDQooWEVOKSBETUkgcHJlc2VudC4NCihYRU4pIEFQSUMgYm9v
dCBzdGF0ZSBpcyAneGFwaWMnDQooWEVOKSBVc2luZyBBUElDIGRyaXZlciBkZWZhdWx0DQoo
WEVOKSBBQ1BJOiBQTS1UaW1lciBJTyBQb3J0OiAweDgwOA0KKFhFTikgQUNQSTogQUNQSSBT
TEVFUCBJTkZPOiBwbTF4X2NudFs4MDQsMF0sIHBtMXhfZXZ0WzgwMCwwXQ0KKFhFTikgQUNQ
STogICAgICAgICAgICAgICAgICB3YWtldXBfdmVjW2FmZTllMDBjXSwgdmVjX3NpemVbMjBd
DQooWEVOKSBBQ1BJOiBMb2NhbCBBUElDIGFkZHJlc3MgMHhmZWUwMDAwMA0KKFhFTikgQUNQ
STogTEFQSUMgKGFjcGlfaWRbMHgwMV0gbGFwaWNfaWRbMHgwMF0gZW5hYmxlZCkNCihYRU4p
IFByb2Nlc3NvciAjMCAwOjEwIEFQSUMgdmVyc2lvbiAxNg0KKFhFTikgQUNQSTogTEFQSUMg
KGFjcGlfaWRbMHgwMl0gbGFwaWNfaWRbMHgwMV0gZW5hYmxlZCkNCihYRU4pIFByb2Nlc3Nv
ciAjMSAwOjEwIEFQSUMgdmVyc2lvbiAxNg0KKFhFTikgQUNQSTogTEFQSUMgKGFjcGlfaWRb
MHgwM10gbGFwaWNfaWRbMHgwMl0gZW5hYmxlZCkNCihYRU4pIFByb2Nlc3NvciAjMiAwOjEw
IEFQSUMgdmVyc2lvbiAxNg0KKFhFTikgQUNQSTogTEFQSUMgKGFjcGlfaWRbMHgwNF0gbGFw
aWNfaWRbMHgwM10gZW5hYmxlZCkNCihYRU4pIFByb2Nlc3NvciAjMyAwOjEwIEFQSUMgdmVy
c2lvbiAxNg0KKFhFTikgQUNQSTogTEFQSUMgKGFjcGlfaWRbMHgwNV0gbGFwaWNfaWRbMHgw
NF0gZW5hYmxlZCkNCihYRU4pIFByb2Nlc3NvciAjNCAwOjEwIEFQSUMgdmVyc2lvbiAxNg0K
KFhFTikgQUNQSTogTEFQSUMgKGFjcGlfaWRbMHgwNl0gbGFwaWNfaWRbMHgwNV0gZW5hYmxl
ZCkNCihYRU4pIFByb2Nlc3NvciAjNSAwOjEwIEFQSUMgdmVyc2lvbiAxNg0KKFhFTikgQUNQ
STogSU9BUElDIChpZFsweDA2XSBhZGRyZXNzWzB4ZmVjMDAwMDBdIGdzaV9iYXNlWzBdKQ0K
KFhFTikgSU9BUElDWzBdOiBhcGljX2lkIDYsIHZlcnNpb24gMzMsIGFkZHJlc3MgMHhmZWMw
MDAwMCwgR1NJIDAtMjMNCihYRU4pIEFDUEk6IElPQVBJQyAoaWRbMHgwN10gYWRkcmVzc1sw
eGZlYzIwMDAwXSBnc2lfYmFzZVsyNF0pDQooWEVOKSBJT0FQSUNbMV06IGFwaWNfaWQgNywg
dmVyc2lvbiAzMywgYWRkcmVzcyAweGZlYzIwMDAwLCBHU0kgMjQtNTUNCihYRU4pIEFDUEk6
IElOVF9TUkNfT1ZSIChidXMgMCBidXNfaXJxIDAgZ2xvYmFsX2lycSAyIGRmbCBkZmwpDQoo
WEVOKSBBQ1BJOiBJTlRfU1JDX09WUiAoYnVzIDAgYnVzX2lycSA5IGdsb2JhbF9pcnEgOSBs
b3cgbGV2ZWwpDQooWEVOKSBBQ1BJOiBJUlEwIHVzZWQgYnkgb3ZlcnJpZGUuDQooWEVOKSBB
Q1BJOiBJUlEyIHVzZWQgYnkgb3ZlcnJpZGUuDQooWEVOKSBBQ1BJOiBJUlE5IHVzZWQgYnkg
b3ZlcnJpZGUuDQooWEVOKSBFbmFibGluZyBBUElDIG1vZGU6ICBGbGF0LiAgVXNpbmcgMiBJ
L08gQVBJQ3MNCihYRU4pIEFDUEk6IEhQRVQgaWQ6IDB4ODMwMCBiYXNlOiAweGZlZDAwMDAw
DQooWEVOKSBUYWJsZSBpcyBub3QgZm91bmQhDQooWEVOKSBVc2luZyBBQ1BJIChNQURUKSBm
b3IgU01QIGNvbmZpZ3VyYXRpb24gaW5mb3JtYXRpb24NCihYRU4pIFNNUDogQWxsb3dpbmcg
NiBDUFVzICgwIGhvdHBsdWcgQ1BVcykNCihYRU4pIG1hcHBlZCBBUElDIHRvIGZmZmY4MmMz
ZmZkZmUwMDAgKGZlZTAwMDAwKQ0KKFhFTikgbWFwcGVkIElPQVBJQyB0byBmZmZmODJjM2Zm
ZGZkMDAwIChmZWMwMDAwMCkNCihYRU4pIG1hcHBlZCBJT0FQSUMgdG8gZmZmZjgyYzNmZmRm
YzAwMCAoZmVjMjAwMDApDQooWEVOKSBJUlEgbGltaXRzOiA1NiBHU0ksIDExMTIgTVNJL01T
SS1YDQooWEVOKSBVc2luZyBzY2hlZHVsZXI6IFNNUCBDcmVkaXQgU2NoZWR1bGVyIChjcmVk
aXQpDQooWEVOKSBEZXRlY3RlZCAzMjAwLjE0OCBNSHogcHJvY2Vzc29yLg0KKFhFTikgSW5p
dGluZyBtZW1vcnkgc2hhcmluZy4NCihYRU4pIEFNRCBGYW0xMGggbWFjaGluZSBjaGVjayBy
ZXBvcnRpbmcgZW5hYmxlZA0KKFhFTikgUENJOiBNQ0ZHIGNvbmZpZ3VyYXRpb24gMDogYmFz
ZSBlMDAwMDAwMCBzZWdtZW50IDAwMDAgYnVzZXMgMDAgLSBmZg0KKFhFTikgUENJOiBOb3Qg
dXNpbmcgTUNGRyBmb3Igc2VnbWVudCAwMDAwIGJ1cyAwMC1mZg0KKFhFTikgQU1ELVZpOiBG
b3VuZCBNU0kgY2FwYWJpbGl0eSBibG9jayBhdCAweDU0DQooWEVOKSBBTUQtVmk6IEFDUEkg
VGFibGU6DQooWEVOKSBBTUQtVmk6ICBTaWduYXR1cmUgSVZSUw0KKFhFTikgQU1ELVZpOiAg
TGVuZ3RoIDB4ZjgNCihYRU4pIEFNRC1WaTogIFJldmlzaW9uIDB4MQ0KKFhFTikgQU1ELVZp
OiAgQ2hlY2tTdW0gMHg2ZQ0KKFhFTikgQU1ELVZpOiAgT0VNX0lkIEFNRCAgDQooWEVOKSBB
TUQtVmk6ICBPRU1fVGFibGVfSWQgUkQ4OTBTDQooWEVOKSBBTUQtVmk6ICBPRU1fUmV2aXNp
b24gMHgyMDIwMzENCihYRU4pIEFNRC1WaTogIENyZWF0b3JfSWQgQU1EIA0KKFhFTikgQU1E
LVZpOiAgQ3JlYXRvcl9SZXZpc2lvbiAweDANCihYRU4pIEFNRC1WaTogSVZSUyBCbG9jazoN
CihYRU4pIEFNRC1WaTogIFR5cGUgMHgxMA0KKFhFTikgQU1ELVZpOiAgRmxhZ3MgMHgzZQ0K
KFhFTikgQU1ELVZpOiAgTGVuZ3RoIDB4YzgNCihYRU4pIEFNRC1WaTogIERldl9JZCAweDIN
CihYRU4pIEFNRC1WaTogSVZIRCBEZXZpY2UgRW50cnk6DQooWEVOKSBBTUQtVmk6ICBUeXBl
IDB4Mw0KKFhFTikgQU1ELVZpOiAgRGV2X0lkIDB4MA0KKFhFTikgQU1ELVZpOiAgRmxhZ3Mg
MHgwDQooWEVOKSBBTUQtVmk6ICBEZXZfSWQgUmFuZ2U6IDB4MCAtPiAweDINCihYRU4pIEFN
RC1WaTogSVZIRCBEZXZpY2UgRW50cnk6DQooWEVOKSBBTUQtVmk6ICBUeXBlIDB4Mg0KKFhF
TikgQU1ELVZpOiAgRGV2X0lkIDB4MTANCihYRU4pIEFNRC1WaTogIEZsYWdzIDB4MA0KKFhF
TikgQU1ELVZpOiBJVkhEIERldmljZSBFbnRyeToNCihYRU4pIEFNRC1WaTogIFR5cGUgMHgy
DQooWEVOKSBBTUQtVmk6ICBEZXZfSWQgMHhiMDANCihYRU4pIEFNRC1WaTogIEZsYWdzIDB4
MA0KKFhFTikgQU1ELVZpOiBJVkhEIERldmljZSBFbnRyeToNCihYRU4pIEFNRC1WaTogIFR5
cGUgMHgyDQooWEVOKSBBTUQtVmk6ICBEZXZfSWQgMHgxOA0KKFhFTikgQU1ELVZpOiAgRmxh
Z3MgMHgwDQooWEVOKSBBTUQtVmk6IElWSEQgRGV2aWNlIEVudHJ5Og0KKFhFTikgQU1ELVZp
OiAgVHlwZSAweDMNCihYRU4pIEFNRC1WaTogIERldl9JZCAweGEwMA0KKFhFTikgQU1ELVZp
OiAgRmxhZ3MgMHgwDQooWEVOKSBBTUQtVmk6ICBEZXZfSWQgUmFuZ2U6IDB4YTAwIC0+IDB4
YTA3DQooWEVOKSBBTUQtVmk6IElWSEQgRGV2aWNlIEVudHJ5Og0KKFhFTikgQU1ELVZpOiAg
VHlwZSAweDINCihYRU4pIEFNRC1WaTogIERldl9JZCAweDI4DQooWEVOKSBBTUQtVmk6ICBG
bGFncyAweDANCihYRU4pIEFNRC1WaTogSVZIRCBEZXZpY2UgRW50cnk6DQooWEVOKSBBTUQt
Vmk6ICBUeXBlIDB4Mg0KKFhFTikgQU1ELVZpOiAgRGV2X0lkIDB4OTAwDQooWEVOKSBBTUQt
Vmk6ICBGbGFncyAweDANCihYRU4pIEFNRC1WaTogSVZIRCBEZXZpY2UgRW50cnk6DQooWEVO
KSBBTUQtVmk6ICBUeXBlIDB4Mg0KKFhFTikgQU1ELVZpOiAgRGV2X0lkIDB4MzANCihYRU4p
IEFNRC1WaTogIEZsYWdzIDB4MA0KKFhFTikgQU1ELVZpOiBJVkhEIERldmljZSBFbnRyeToN
CihYRU4pIEFNRC1WaTogIFR5cGUgMHgyDQooWEVOKSBBTUQtVmk6ICBEZXZfSWQgMHg4MDAN
CihYRU4pIEFNRC1WaTogIEZsYWdzIDB4MA0KKFhFTikgQU1ELVZpOiBJVkhEIERldmljZSBF
bnRyeToNCihYRU4pIEFNRC1WaTogIFR5cGUgMHgyDQooWEVOKSBBTUQtVmk6ICBEZXZfSWQg
MHg1MA0KKFhFTikgQU1ELVZpOiAgRmxhZ3MgMHgwDQooWEVOKSBBTUQtVmk6IElWSEQgRGV2
aWNlIEVudHJ5Og0KKFhFTikgQU1ELVZpOiAgVHlwZSAweDINCihYRU4pIEFNRC1WaTogIERl
dl9JZCAweDcwMA0KKFhFTikgQU1ELVZpOiAgRmxhZ3MgMHgwDQooWEVOKSBBTUQtVmk6IElW
SEQgRGV2aWNlIEVudHJ5Og0KKFhFTikgQU1ELVZpOiAgVHlwZSAweDINCihYRU4pIEFNRC1W
aTogIERldl9JZCAweDU4DQooWEVOKSBBTUQtVmk6ICBGbGFncyAweDANCihYRU4pIEFNRC1W
aTogSVZIRCBEZXZpY2UgRW50cnk6DQooWEVOKSBBTUQtVmk6ICBUeXBlIDB4Mw0KKFhFTikg
QU1ELVZpOiAgRGV2X0lkIDB4NjAwDQooWEVOKSBBTUQtVmk6ICBGbGFncyAweDANCihYRU4p
IEFNRC1WaTogIERldl9JZCBSYW5nZTogMHg2MDAgLT4gMHg2MDENCihYRU4pIEFNRC1WaTog
SVZIRCBEZXZpY2UgRW50cnk6DQooWEVOKSBBTUQtVmk6ICBUeXBlIDB4Mg0KKFhFTikgQU1E
LVZpOiAgRGV2X0lkIDB4NjANCihYRU4pIEFNRC1WaTogIEZsYWdzIDB4MA0KKFhFTikgQU1E
LVZpOiBJVkhEIERldmljZSBFbnRyeToNCihYRU4pIEFNRC1WaTogIFR5cGUgMHgyDQooWEVO
KSBBTUQtVmk6ICBEZXZfSWQgMHg1MDANCihYRU4pIEFNRC1WaTogIEZsYWdzIDB4MA0KKFhF
TikgQU1ELVZpOiBJVkhEIERldmljZSBFbnRyeToNCihYRU4pIEFNRC1WaTogIFR5cGUgMHgy
DQooWEVOKSBBTUQtVmk6ICBEZXZfSWQgMHg2OA0KKFhFTikgQU1ELVZpOiAgRmxhZ3MgMHgw
DQooWEVOKSBBTUQtVmk6IElWSEQgRGV2aWNlIEVudHJ5Og0KKFhFTikgQU1ELVZpOiAgVHlw
ZSAweDMNCihYRU4pIEFNRC1WaTogIERldl9JZCAweDQwMA0KKFhFTikgQU1ELVZpOiAgRmxh
Z3MgMHgwDQooWEVOKSBBTUQtVmk6ICBEZXZfSWQgUmFuZ2U6IDB4NDAwIC0+IDB4NDA3DQoo
WEVOKSBBTUQtVmk6IElWSEQgRGV2aWNlIEVudHJ5Og0KKFhFTikgQU1ELVZpOiAgVHlwZSAw
eDINCihYRU4pIEFNRC1WaTogIERldl9JZCAweDg4DQooWEVOKSBBTUQtVmk6ICBGbGFncyAw
eDANCihYRU4pIEFNRC1WaTogSVZIRCBEZXZpY2UgRW50cnk6DQooWEVOKSBBTUQtVmk6ICBU
eXBlIDB4Mw0KKFhFTikgQU1ELVZpOiAgRGV2X0lkIDB4OTANCihYRU4pIEFNRC1WaTogIEZs
YWdzIDB4MA0KKFhFTikgQU1ELVZpOiAgRGV2X0lkIFJhbmdlOiAweDkwIC0+IDB4OTINCihY
RU4pIEFNRC1WaTogSVZIRCBEZXZpY2UgRW50cnk6DQooWEVOKSBBTUQtVmk6ICBUeXBlIDB4
Mw0KKFhFTikgQU1ELVZpOiAgRGV2X0lkIDB4OTgNCihYRU4pIEFNRC1WaTogIEZsYWdzIDB4
MA0KKFhFTikgQU1ELVZpOiAgRGV2X0lkIFJhbmdlOiAweDk4IC0+IDB4OWENCihYRU4pIEFN
RC1WaTogSVZIRCBEZXZpY2UgRW50cnk6DQooWEVOKSBBTUQtVmk6ICBUeXBlIDB4Mg0KKFhF
TikgQU1ELVZpOiAgRGV2X0lkIDB4YTANCihYRU4pIEFNRC1WaTogIEZsYWdzIDB4ZDcNCihY
RU4pIEFNRC1WaTogSVZIRCBEZXZpY2UgRW50cnk6DQooWEVOKSBBTUQtVmk6ICBUeXBlIDB4
Mg0KKFhFTikgQU1ELVZpOiAgRGV2X0lkIDB4YTMNCihYRU4pIEFNRC1WaTogIEZsYWdzIDB4
MA0KKFhFTikgQU1ELVZpOiBJVkhEIERldmljZSBFbnRyeToNCihYRU4pIEFNRC1WaTogIFR5
cGUgMHgyDQooWEVOKSBBTUQtVmk6ICBEZXZfSWQgMHhhNA0KKFhFTikgQU1ELVZpOiAgRmxh
Z3MgMHgwDQooWEVOKSBBTUQtVmk6IElWSEQgRGV2aWNlIEVudHJ5Og0KKFhFTikgQU1ELVZp
OiAgVHlwZSAweDANCihYRU4pIEFNRC1WaTogIERldl9JZCAweDANCihYRU4pIEFNRC1WaTog
IEZsYWdzIDB4MA0KKFhFTikgQU1ELVZpOiBJVkhEIERldmljZSBFbnRyeToNCihYRU4pIEFN
RC1WaTogIFR5cGUgMHg0Mw0KKFhFTikgQU1ELVZpOiAgRGV2X0lkIDB4MzAwDQooWEVOKSBB
TUQtVmk6ICBGbGFncyAweDANCihYRU4pIEFNRC1WaTogIERldl9JZCBSYW5nZTogMHgzMDAg
LT4gMHgzZmYNCihYRU4pIEFNRC1WaTogIERldl9JZCBBbGlhczogMHhhNA0KKFhFTikgQU1E
LVZpOiBJVkhEIERldmljZSBFbnRyeToNCihYRU4pIEFNRC1WaTogIFR5cGUgMHgyDQooWEVO
KSBBTUQtVmk6ICBEZXZfSWQgMHhhNQ0KKFhFTikgQU1ELVZpOiAgRmxhZ3MgMHgwDQooWEVO
KSBBTUQtVmk6IElWSEQgRGV2aWNlIEVudHJ5Og0KKFhFTikgQU1ELVZpOiAgVHlwZSAweDIN
CihYRU4pIEFNRC1WaTogIERldl9JZCAweGE4DQooWEVOKSBBTUQtVmk6ICBGbGFncyAweDAN
CihYRU4pIEFNRC1WaTogSVZIRCBEZXZpY2UgRW50cnk6DQooWEVOKSBBTUQtVmk6ICBUeXBl
IDB4Mg0KKFhFTikgQU1ELVZpOiAgRGV2X0lkIDB4YTkNCihYRU4pIEFNRC1WaTogIEZsYWdz
IDB4MA0KKFhFTikgQU1ELVZpOiBJVkhEIERldmljZSBFbnRyeToNCihYRU4pIEFNRC1WaTog
IFR5cGUgMHgyDQooWEVOKSBBTUQtVmk6ICBEZXZfSWQgMHgxMDANCihYRU4pIEFNRC1WaTog
IEZsYWdzIDB4MA0KKFhFTikgQU1ELVZpOiBJVkhEIERldmljZSBFbnRyeToNCihYRU4pIEFN
RC1WaTogIFR5cGUgMHgzDQooWEVOKSBBTUQtVmk6ICBEZXZfSWQgMHhiMA0KKFhFTikgQU1E
LVZpOiAgRmxhZ3MgMHgwDQooWEVOKSBBTUQtVmk6ICBEZXZfSWQgUmFuZ2U6IDB4YjAgLT4g
MHhiMg0KKFhFTikgQU1ELVZpOiBJVkhEIERldmljZSBFbnRyeToNCihYRU4pIEFNRC1WaTog
IFR5cGUgMHgwDQooWEVOKSBBTUQtVmk6ICBEZXZfSWQgMHgwDQooWEVOKSBBTUQtVmk6ICBG
bGFncyAweDANCihYRU4pIEFNRC1WaTogSVZIRCBEZXZpY2UgRW50cnk6DQooWEVOKSBBTUQt
Vmk6ICBUeXBlIDB4NDgNCihYRU4pIEFNRC1WaTogIERldl9JZCAweDANCihYRU4pIEFNRC1W
aTogIEZsYWdzIDB4ZDcNCihYRU4pIEFNRC1WaTogSVZIRCBEZXZpY2UgRW50cnk6DQooWEVO
KSBBTUQtVmk6ICBUeXBlIDB4NDgNCihYRU4pIEFNRC1WaTogIERldl9JZCAweDANCihYRU4p
IEFNRC1WaTogIEZsYWdzIDB4MA0KKFhFTikgQU1ELVZpOiBJT01NVSAwIEVuYWJsZWQuDQoo
WEVOKSBBTUQtVmk6IEVuYWJsaW5nIGdsb2JhbCB2ZWN0b3IgbWFwDQooWEVOKSBJL08gdmly
dHVhbGlzYXRpb24gZW5hYmxlZA0KKFhFTikgIC0gRG9tMCBtb2RlOiBSZWxheGVkDQooWEVO
KSBHZXR0aW5nIFZFUlNJT046IDgwMDUwMDEwDQooWEVOKSBHZXR0aW5nIFZFUlNJT046IDgw
MDUwMDEwDQooWEVOKSBHZXR0aW5nIElEOiAwDQooWEVOKSBHZXR0aW5nIExWVDA6IDcwMA0K
KFhFTikgR2V0dGluZyBMVlQxOiA0MDANCihYRU4pIGVuYWJsZWQgRXh0SU5UIG9uIENQVSMw
DQooWEVOKSBFU1IgdmFsdWUgYmVmb3JlIGVuYWJsaW5nIHZlY3RvcjogMHgwMDAwMDAwNCAg
YWZ0ZXI6IDB4MDAwMDAwMDANCihYRU4pIEVOQUJMSU5HIElPLUFQSUMgSVJRcw0KKFhFTikg
IC0+IFVzaW5nIG5ldyBBQ0sgbWV0aG9kDQooWEVOKSBpbml0IElPX0FQSUMgSVJRcw0KKFhF
TikgIElPLUFQSUMgKGFwaWNpZC1waW4pIDYtMCwgNi0xNiwgNi0xNywgNi0xOCwgNi0xOSwg
Ni0yMCwgNi0yMSwgNi0yMiwgNi0yMywgNy0wLCA3LTEsIDctMiwgNy0zLCA3LTQsIDctNSwg
Ny02LCA3LTcsIDctOCwgNy05LCA3LTEwLCA3LTExLCA3LTEyLCA3LTEzLCA3LTE0LCA3LTE1
LCA3LTE2LCA3LTE3LCA3LTE4LCA3LTE5LCA3LTIwLCA3LTIxLCA3LTIyLCA3LTIzLCA3LTI0
LCA3LTI1LCA3LTI2LCA3LTI3LCA3LTI4LCA3LTI5LCA3LTMwLCA3LTMxIG5vdCBjb25uZWN0
ZWQuDQooWEVOKSAuLlRJTUVSOiB2ZWN0b3I9MHhGMCBhcGljMT0wIHBpbjE9MiBhcGljMj0t
MSBwaW4yPS0xDQooWEVOKSBudW1iZXIgb2YgTVAgSVJRIHNvdXJjZXM6IDE1Lg0KKFhFTikg
bnVtYmVyIG9mIElPLUFQSUMgIzYgcmVnaXN0ZXJzOiAyNC4NCihYRU4pIG51bWJlciBvZiBJ
Ty1BUElDICM3IHJlZ2lzdGVyczogMzIuDQooWEVOKSB0ZXN0aW5nIHRoZSBJTyBBUElDLi4u
Li4uLi4uLi4uLi4uLi4uLi4uLi4NCihYRU4pIElPIEFQSUMgIzYuLi4uLi4NCihYRU4pIC4u
Li4gcmVnaXN0ZXIgIzAwOiAwNjAwMDAwMA0KKFhFTikgLi4uLi4uLiAgICA6IHBoeXNpY2Fs
IEFQSUMgaWQ6IDA2DQooWEVOKSAuLi4uLi4uICAgIDogRGVsaXZlcnkgVHlwZTogMA0KKFhF
TikgLi4uLi4uLiAgICA6IExUUyAgICAgICAgICA6IDANCihYRU4pIC4uLi4gcmVnaXN0ZXIg
IzAxOiAwMDE3ODAyMQ0KKFhFTikgLi4uLi4uLiAgICAgOiBtYXggcmVkaXJlY3Rpb24gZW50
cmllczogMDAxNw0KKFhFTikgLi4uLi4uLiAgICAgOiBQUlEgaW1wbGVtZW50ZWQ6IDENCihY
RU4pIC4uLi4uLi4gICAgIDogSU8gQVBJQyB2ZXJzaW9uOiAwMDIxDQooWEVOKSAuLi4uIHJl
Z2lzdGVyICMwMjogMDYwMDAwMDANCihYRU4pIC4uLi4uLi4gICAgIDogYXJiaXRyYXRpb246
IDA2DQooWEVOKSAuLi4uIHJlZ2lzdGVyICMwMzogMDcwMDAwMDANCihYRU4pIC4uLi4uLi4g
ICAgIDogQm9vdCBEVCAgICA6IDANCihYRU4pIC4uLi4gSVJRIHJlZGlyZWN0aW9uIHRhYmxl
Og0KKFhFTikgIE5SIExvZyBQaHkgTWFzayBUcmlnIElSUiBQb2wgU3RhdCBEZXN0IERlbGkg
VmVjdDogICANCihYRU4pICAwMCAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAg
ICAwICAgIDAwDQooWEVOKSAgMDEgMDAxIDAxICAwICAgIDAgICAgMCAgIDAgICAwICAgIDEg
ICAgMSAgICAzMA0KKFhFTikgIDAyIDAwMSAwMSAgMCAgICAwICAgIDAgICAwICAgMCAgICAx
ICAgIDEgICAgRjANCihYRU4pICAwMyAwMDEgMDEgIDAgICAgMCAgICAwICAgMCAgIDAgICAg
MSAgICAxICAgIDM4DQooWEVOKSAgMDQgMDAxIDAxICAwICAgIDAgICAgMCAgIDAgICAwICAg
IDEgICAgMSAgICBGMQ0KKFhFTikgIDA1IDAwMSAwMSAgMCAgICAwICAgIDAgICAwICAgMCAg
ICAxICAgIDEgICAgNDANCihYRU4pICAwNiAwMDEgMDEgIDAgICAgMCAgICAwICAgMCAgIDAg
ICAgMSAgICAxICAgIDQ4DQooWEVOKSAgMDcgMDAxIDAxICAwICAgIDAgICAgMCAgIDAgICAw
ICAgIDEgICAgMSAgICA1MA0KKFhFTikgIDA4IDAwMSAwMSAgMCAgICAwICAgIDAgICAwICAg
MCAgICAxICAgIDEgICAgNTgNCihYRU4pICAwOSAwMDEgMDEgIDEgICAgMSAgICAwICAgMSAg
IDAgICAgMSAgICAxICAgIDYwDQooWEVOKSAgMGEgMDAxIDAxICAwICAgIDAgICAgMCAgIDAg
ICAwICAgIDEgICAgMSAgICA2OA0KKFhFTikgIDBiIDAwMSAwMSAgMCAgICAwICAgIDAgICAw
ICAgMCAgICAxICAgIDEgICAgNzANCihYRU4pICAwYyAwMDEgMDEgIDAgICAgMCAgICAwICAg
MCAgIDAgICAgMSAgICAxICAgIDc4DQooWEVOKSAgMGQgMDAxIDAxICAwICAgIDAgICAgMCAg
IDAgICAwICAgIDEgICAgMSAgICA4OA0KKFhFTikgIDBlIDAwMSAwMSAgMCAgICAwICAgIDAg
ICAwICAgMCAgICAxICAgIDEgICAgOTANCihYRU4pICAwZiAwMDEgMDEgIDAgICAgMCAgICAw
ICAgMCAgIDAgICAgMSAgICAxICAgIDk4DQooWEVOKSAgMTAgMDAwIDAwICAxICAgIDAgICAg
MCAgIDAgICAwICAgIDAgICAgMCAgICAwMA0KKFhFTikgIDExIDAwMCAwMCAgMSAgICAwICAg
IDAgICAwICAgMCAgICAwICAgIDAgICAgMDANCihYRU4pICAxMiAwMDAgMDAgIDEgICAgMCAg
ICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwDQooWEVOKSAgMTMgMDAwIDAwICAxICAgIDAg
ICAgMCAgIDAgICAwICAgIDAgICAgMCAgICAwMA0KKFhFTikgIDE0IDAwMCAwMCAgMSAgICAw
ICAgIDAgICAwICAgMCAgICAwICAgIDAgICAgMDANCihYRU4pICAxNSAwMDAgMDAgIDEgICAg
MCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwDQooWEVOKSAgMTYgMDAwIDAwICAxICAg
IDAgICAgMCAgIDAgICAwICAgIDAgICAgMCAgICAwMA0KKFhFTikgIDE3IDAwMCAwMCAgMSAg
ICAwICAgIDAgICAwICAgMCAgICAwICAgIDAgICAgMDANCihYRU4pIElPIEFQSUMgIzcuLi4u
Li4NCihYRU4pIC4uLi4gcmVnaXN0ZXIgIzAwOiAwNzAwMDAwMA0KKFhFTikgLi4uLi4uLiAg
ICA6IHBoeXNpY2FsIEFQSUMgaWQ6IDA3DQooWEVOKSAuLi4uLi4uICAgIDogRGVsaXZlcnkg
VHlwZTogMA0KKFhFTikgLi4uLi4uLiAgICA6IExUUyAgICAgICAgICA6IDANCihYRU4pIC4u
Li4gcmVnaXN0ZXIgIzAxOiAwMDFGODAyMQ0KKFhFTikgLi4uLi4uLiAgICAgOiBtYXggcmVk
aXJlY3Rpb24gZW50cmllczogMDAxRg0KKFhFTikgLi4uLi4uLiAgICAgOiBQUlEgaW1wbGVt
ZW50ZWQ6IDENCihYRU4pIC4uLi4uLi4gICAgIDogSU8gQVBJQyB2ZXJzaW9uOiAwMDIxDQoo
WEVOKSAuLi4uIHJlZ2lzdGVyICMwMjogMDAwMDAwMDANCihYRU4pIC4uLi4uLi4gICAgIDog
YXJiaXRyYXRpb246IDAwDQooWEVOKSAuLi4uIElSUSByZWRpcmVjdGlvbiB0YWJsZToNCihY
RU4pICBOUiBMb2cgUGh5IE1hc2sgVHJpZyBJUlIgUG9sIFN0YXQgRGVzdCBEZWxpIFZlY3Q6
ICAgDQooWEVOKSAgMDAgMDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAwICAgIDAgICAgMCAg
ICAwMA0KKFhFTikgIDAxIDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDAg
ICAgMDANCihYRU4pICAwMiAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAw
ICAgIDAwDQooWEVOKSAgMDMgMDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAwICAgIDAgICAg
MCAgICAwMA0KKFhFTikgIDA0IDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAg
IDAgICAgMDANCihYRU4pICAwNSAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAg
ICAwICAgIDAwDQooWEVOKSAgMDYgMDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAwICAgIDAg
ICAgMCAgICAwMA0KKFhFTikgIDA3IDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAw
ICAgIDAgICAgMDANCihYRU4pICAwOCAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAg
MCAgICAwICAgIDAwDQooWEVOKSAgMDkgMDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAwICAg
IDAgICAgMCAgICAwMA0KKFhFTikgIDBhIDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAg
ICAwICAgIDAgICAgMDANCihYRU4pICAwYiAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAg
ICAgMCAgICAwICAgIDAwDQooWEVOKSAgMGMgMDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAw
ICAgIDAgICAgMCAgICAwMA0KKFhFTikgIDBkIDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAg
MCAgICAwICAgIDAgICAgMDANCihYRU4pICAwZSAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAg
IDAgICAgMCAgICAwICAgIDAwDQooWEVOKSAgMGYgMDAwIDAwICAxICAgIDAgICAgMCAgIDAg
ICAwICAgIDAgICAgMCAgICAwMA0KKFhFTikgIDEwIDAwMCAwMCAgMSAgICAwICAgIDAgICAw
ICAgMCAgICAwICAgIDAgICAgMDANCihYRU4pICAxMSAwMDAgMDAgIDEgICAgMCAgICAwICAg
MCAgIDAgICAgMCAgICAwICAgIDAwDQooWEVOKSAgMTIgMDAwIDAwICAxICAgIDAgICAgMCAg
IDAgICAwICAgIDAgICAgMCAgICAwMA0KKFhFTikgIDEzIDAwMCAwMCAgMSAgICAwICAgIDAg
ICAwICAgMCAgICAwICAgIDAgICAgMDANCihYRU4pICAxNCAwMDAgMDAgIDEgICAgMCAgICAw
ICAgMCAgIDAgICAgMCAgICAwICAgIDAwDQooWEVOKSAgMTUgMDAwIDAwICAxICAgIDAgICAg
MCAgIDAgICAwICAgIDAgICAgMCAgICAwMA0KKFhFTikgIDE2IDAwMCAwMCAgMSAgICAwICAg
IDAgICAwICAgMCAgICAwICAgIDAgICAgMDANCihYRU4pICAxNyAwMDAgMDAgIDEgICAgMCAg
ICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwDQooWEVOKSAgMTggMDAwIDAwICAxICAgIDAg
ICAgMCAgIDAgICAwICAgIDAgICAgMCAgICAwMA0KKFhFTikgIDE5IDAwMCAwMCAgMSAgICAw
ICAgIDAgICAwICAgMCAgICAwICAgIDAgICAgMDANCihYRU4pICAxYSAwMDAgMDAgIDEgICAg
MCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwDQooWEVOKSAgMWIgMDAwIDAwICAxICAg
IDAgICAgMCAgIDAgICAwICAgIDAgICAgMCAgICAwMA0KKFhFTikgIDFjIDAwMCAwMCAgMSAg
ICAwICAgIDAgICAwICAgMCAgICAwICAgIDAgICAgMDANCihYRU4pICAxZCAwMDAgMDAgIDEg
ICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwDQooWEVOKSAgMWUgMDAwIDAwICAx
ICAgIDAgICAgMCAgIDAgICAwICAgIDAgICAgMCAgICAwMA0KKFhFTikgIDFmIDAwMCAwMCAg
MSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDAgICAgMDANCihYRU4pIFVzaW5nIHZlY3Rv
ci1iYXNlZCBpbmRleGluZw0KKFhFTikgSVJRIHRvIHBpbiBtYXBwaW5nczoNCihYRU4pIElS
UTI0MCAtPiAwOjINCihYRU4pIElSUTQ4IC0+IDA6MQ0KKFhFTikgSVJRNTYgLT4gMDozDQoo
WEVOKSBJUlEyNDEgLT4gMDo0DQooWEVOKSBJUlE2NCAtPiAwOjUNCihYRU4pIElSUTcyIC0+
IDA6Ng0KKFhFTikgSVJRODAgLT4gMDo3DQooWEVOKSBJUlE4OCAtPiAwOjgNCihYRU4pIElS
UTk2IC0+IDA6OQ0KKFhFTikgSVJRMTA0IC0+IDA6MTANCihYRU4pIElSUTExMiAtPiAwOjEx
DQooWEVOKSBJUlExMjAgLT4gMDoxMg0KKFhFTikgSVJRMTM2IC0+IDA6MTMNCihYRU4pIElS
UTE0NCAtPiAwOjE0DQooWEVOKSBJUlExNTIgLT4gMDoxNQ0KKFhFTikgLi4uLi4uLi4uLi4u
Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uIGRvbmUuDQooWEVOKSBVc2luZyBsb2NhbCBBUElD
IHRpbWVyIGludGVycnVwdHMuDQooWEVOKSBjYWxpYnJhdGluZyBBUElDIHRpbWVyIC4uLg0K
KFhFTikgLi4uLi4gQ1BVIGNsb2NrIHNwZWVkIGlzIDMyMDAuMTM1NyBNSHouDQooWEVOKSAu
Li4uLiBob3N0IGJ1cyBjbG9jayBzcGVlZCBpcyAyMDAuMDA4MyBNSHouDQooWEVOKSAuLi4u
LiBidXNfc2NhbGUgPSAweDAwMDBDQ0Q3DQooWEVOKSBbMjAxMi0wOS0wNCAxNTo1MToxNV0g
UGxhdGZvcm0gdGltZXIgaXMgMTQuMzE4TUh6IEhQRVQNCihYRU4pIFsyMDEyLTA5LTA0IDE1
OjUxOjE1XSBBbGxvY2F0ZWQgY29uc29sZSByaW5nIG9mIDY0IEtpQi4NCihYRU4pIFsyMDEy
LTA5LTA0IDE1OjUxOjE1XSBIVk06IEFTSURzIGVuYWJsZWQuDQooWEVOKSBbMjAxMi0wOS0w
NCAxNTo1MToxNV0gU1ZNOiBTdXBwb3J0ZWQgYWR2YW5jZWQgZmVhdHVyZXM6DQooWEVOKSBb
MjAxMi0wOS0wNCAxNTo1MToxNV0gIC0gTmVzdGVkIFBhZ2UgVGFibGVzIChOUFQpDQooWEVO
KSBbMjAxMi0wOS0wNCAxNTo1MToxNV0gIC0gTGFzdCBCcmFuY2ggUmVjb3JkIChMQlIpIFZp
cnR1YWxpc2F0aW9uDQooWEVOKSBbMjAxMi0wOS0wNCAxNTo1MToxNV0gIC0gTmV4dC1SSVAg
U2F2ZWQgb24gI1ZNRVhJVA0KKFhFTikgWzIwMTItMDktMDQgMTU6NTE6MTVdICAtIFBhdXNl
LUludGVyY2VwdCBGaWx0ZXINCihYRU4pIFsyMDEyLTA5LTA0IDE1OjUxOjE1XSBIVk06IFNW
TSBlbmFibGVkDQooWEVOKSBbMjAxMi0wOS0wNCAxNTo1MToxNV0gSFZNOiBIYXJkd2FyZSBB
c3Npc3RlZCBQYWdpbmcgKEhBUCkgZGV0ZWN0ZWQNCihYRU4pIFsyMDEyLTA5LTA0IDE1OjUx
OjE1XSBIVk06IEhBUCBwYWdlIHNpemVzOiA0a0IsIDJNQiwgMUdCDQooWEVOKSBbMjAxMi0w
OS0wNCAxNTo1MToxNF0gbWFza2VkIEV4dElOVCBvbiBDUFUjMQ0KKFhFTikgWzIwMTItMDkt
MDQgMTU6NTE6MTVdIG1pY3JvY29kZTogY29sbGVjdF9jcHVfaW5mbzogcGF0Y2hfaWQ9MHgx
MDAwMGJmDQooWEVOKSBbMjAxMi0wOS0wNCAxNTo1MToxNF0gbWFza2VkIEV4dElOVCBvbiBD
UFUjMg0KKFhFTikgWzIwMTItMDktMDQgMTU6NTE6MTVdIG1pY3JvY29kZTogY29sbGVjdF9j
cHVfaW5mbzogcGF0Y2hfaWQ9MHgxMDAwMGJmDQooWEVOKSBbMjAxMi0wOS0wNCAxNTo1MTox
NF0gbWFza2VkIEV4dElOVCBvbiBDUFUjMw0KKFhFTikgWzIwMTItMDktMDQgMTU6NTE6MTVd
IG1pY3JvY29kZTogY29sbGVjdF9jcHVfaW5mbzogcGF0Y2hfaWQ9MHgxMDAwMGJmDQooWEVO
KSBbMjAxMi0wOS0wNCAxNTo1MToxNF0gbWFza2VkIEV4dElOVCBvbiBDUFUjNA0KKFhFTikg
WzIwMTItMDktMDQgMTU6NTE6MTVdIG1pY3JvY29kZTogY29sbGVjdF9jcHVfaW5mbzogcGF0
Y2hfaWQ9MHgxMDAwMGJmDQooWEVOKSBbMjAxMi0wOS0wNCAxNTo1MToxNF0gbWFza2VkIEV4
dElOVCBvbiBDUFUjNQ0KKFhFTikgWzIwMTItMDktMDQgMTU6NTE6MTVdIEJyb3VnaHQgdXAg
NiBDUFVzDQooWEVOKSBbMjAxMi0wOS0wNCAxNTo1MToxNV0gbWljcm9jb2RlOiBjb2xsZWN0
X2NwdV9pbmZvOiBwYXRjaF9pZD0weDEwMDAwYmYNCihYRU4pIFsyMDEyLTA5LTA0IDE1OjUx
OjE1XSBIUEVUJ3MgTVNJIG1vZGUgaGFzbid0IGJlZW4gc3VwcG9ydGVkIHdoZW4gSW50ZXJy
dXB0IFJlbWFwcGluZyBpcyBlbmFibGVkLg0KKFhFTikgWzIwMTItMDktMDQgMTU6NTE6MTVd
IEFDUEkgc2xlZXAgbW9kZXM6IFMzDQooWEVOKSBbMjAxMi0wOS0wNCAxNTo1MToxNV0gTUNB
OiBVc2UgaHcgdGhyZXNob2xkaW5nIHRvIGFkanVzdCBwb2xsaW5nIGZyZXF1ZW5jeQ0KKFhF
TikgWzIwMTItMDktMDQgMTU6NTE6MTVdIG1jaGVja19wb2xsOiBNYWNoaW5lIGNoZWNrIHBv
bGxpbmcgdGltZXIgc3RhcnRlZC4NCihYRU4pIFsyMDEyLTA5LTA0IDE1OjUxOjE1XSBYZW5v
cHJvZmlsZTogRmFpbGVkIHRvIHNldHVwIElCUyBMVlQgb2Zmc2V0LCBJQlNDVEwgPSAweGZm
ZmZmZmZmDQooWEVOKSBbMjAxMi0wOS0wNCAxNTo1MToxNV0gKioqIExPQURJTkcgRE9NQUlO
IDAgKioqDQooWEVOKSBbMjAxMi0wOS0wNCAxNTo1MToxNl0gZWxmX3BhcnNlX2JpbmFyeTog
cGhkcjogcGFkZHI9MHgxMDAwMDAwIG1lbXN6PTB4ZDZhMDAwDQooWEVOKSBbMjAxMi0wOS0w
NCAxNTo1MToxNl0gZWxmX3BhcnNlX2JpbmFyeTogcGhkcjogcGFkZHI9MHgxZTAwMDAwIG1l
bXN6PTB4ZGIwZTgNCihYRU4pIFsyMDEyLTA5LTA0IDE1OjUxOjE2XSBlbGZfcGFyc2VfYmlu
YXJ5OiBwaGRyOiBwYWRkcj0weDFlZGMwMDAgbWVtc3o9MHgxM2MwMA0KKFhFTikgWzIwMTIt
MDktMDQgMTU6NTE6MTZdIGVsZl9wYXJzZV9iaW5hcnk6IHBoZHI6IHBhZGRyPTB4MWVmMDAw
MCBtZW1zej0weGRlNTAwMA0KKFhFTikgWzIwMTItMDktMDQgMTU6NTE6MTZdIGVsZl9wYXJz
ZV9iaW5hcnk6IG1lbW9yeTogMHgxMDAwMDAwIC0+IDB4MmNkNTAwMA0KKFhFTikgWzIwMTIt
MDktMDQgMTU6NTE6MTZdIGVsZl94ZW5fcGFyc2Vfbm90ZTogR1VFU1RfT1MgPSAibGludXgi
DQooWEVOKSBbMjAxMi0wOS0wNCAxNTo1MToxNl0gZWxmX3hlbl9wYXJzZV9ub3RlOiBHVUVT
VF9WRVJTSU9OID0gIjIuNiINCihYRU4pIFsyMDEyLTA5LTA0IDE1OjUxOjE2XSBlbGZfeGVu
X3BhcnNlX25vdGU6IFhFTl9WRVJTSU9OID0gInhlbi0zLjAiDQooWEVOKSBbMjAxMi0wOS0w
NCAxNTo1MToxNl0gZWxmX3hlbl9wYXJzZV9ub3RlOiBWSVJUX0JBU0UgPSAweGZmZmZmZmZm
ODAwMDAwMDANCihYRU4pIFsyMDEyLTA5LTA0IDE1OjUxOjE2XSBlbGZfeGVuX3BhcnNlX25v
dGU6IEVOVFJZID0gMHhmZmZmZmZmZjgxZWYwMjEwDQooWEVOKSBbMjAxMi0wOS0wNCAxNTo1
MToxNl0gZWxmX3hlbl9wYXJzZV9ub3RlOiBIWVBFUkNBTExfUEFHRSA9IDB4ZmZmZmZmZmY4
MTAwMTAwMA0KKFhFTikgWzIwMTItMDktMDQgMTU6NTE6MTZdIGVsZl94ZW5fcGFyc2Vfbm90
ZTogRkVBVFVSRVMgPSAiIXdyaXRhYmxlX3BhZ2VfdGFibGVzfHBhZV9wZ2Rpcl9hYm92ZV80
Z2IiDQooWEVOKSBbMjAxMi0wOS0wNCAxNTo1MToxNl0gZWxmX3hlbl9wYXJzZV9ub3RlOiBQ
QUVfTU9ERSA9ICJ5ZXMiDQooWEVOKSBbMjAxMi0wOS0wNCAxNTo1MToxNl0gZWxmX3hlbl9w
YXJzZV9ub3RlOiBMT0FERVIgPSAiZ2VuZXJpYyINCihYRU4pIFsyMDEyLTA5LTA0IDE1OjUx
OjE2XSBlbGZfeGVuX3BhcnNlX25vdGU6IHVua25vd24geGVuIGVsZiBub3RlICgweGQpDQoo
WEVOKSBbMjAxMi0wOS0wNCAxNTo1MToxNl0gZWxmX3hlbl9wYXJzZV9ub3RlOiBTVVNQRU5E
X0NBTkNFTCA9IDB4MQ0KKFhFTikgWzIwMTItMDktMDQgMTU6NTE6MTZdIGVsZl94ZW5fcGFy
c2Vfbm90ZTogSFZfU1RBUlRfTE9XID0gMHhmZmZmODAwMDAwMDAwMDAwDQooWEVOKSBbMjAx
Mi0wOS0wNCAxNTo1MToxNl0gZWxmX3hlbl9wYXJzZV9ub3RlOiBQQUREUl9PRkZTRVQgPSAw
eDANCihYRU4pIFsyMDEyLTA5LTA0IDE1OjUxOjE2XSBlbGZfeGVuX2FkZHJfY2FsY19jaGVj
azogYWRkcmVzc2VzOg0KKFhFTikgWzIwMTItMDktMDQgMTU6NTE6MTZdICAgICB2aXJ0X2Jh
c2UgICAgICAgID0gMHhmZmZmZmZmZjgwMDAwMDAwDQooWEVOKSBbMjAxMi0wOS0wNCAxNTo1
MToxNl0gICAgIGVsZl9wYWRkcl9vZmZzZXQgPSAweDANCihYRU4pIFsyMDEyLTA5LTA0IDE1
OjUxOjE2XSAgICAgdmlydF9vZmZzZXQgICAgICA9IDB4ZmZmZmZmZmY4MDAwMDAwMA0KKFhF
TikgWzIwMTItMDktMDQgMTU6NTE6MTZdICAgICB2aXJ0X2tzdGFydCAgICAgID0gMHhmZmZm
ZmZmZjgxMDAwMDAwDQooWEVOKSBbMjAxMi0wOS0wNCAxNTo1MToxNl0gICAgIHZpcnRfa2Vu
ZCAgICAgICAgPSAweGZmZmZmZmZmODJjZDUwMDANCihYRU4pIFsyMDEyLTA5LTA0IDE1OjUx
OjE2XSAgICAgdmlydF9lbnRyeSAgICAgICA9IDB4ZmZmZmZmZmY4MWVmMDIxMA0KKFhFTikg
WzIwMTItMDktMDQgMTU6NTE6MTZdICAgICBwMm1fYmFzZSAgICAgICAgID0gMHhmZmZmZmZm
ZmZmZmZmZmZmDQooWEVOKSBbMjAxMi0wOS0wNCAxNTo1MToxNl0gIFhlbiAga2VybmVsOiA2
NC1iaXQsIGxzYiwgY29tcGF0MzINCihYRU4pIFsyMDEyLTA5LTA0IDE1OjUxOjE2XSAgRG9t
MCBrZXJuZWw6IDY0LWJpdCwgUEFFLCBsc2IsIHBhZGRyIDB4MTAwMDAwMCAtPiAweDJjZDUw
MDANCihYRU4pIFsyMDEyLTA5LTA0IDE1OjUxOjE2XSBQSFlTSUNBTCBNRU1PUlkgQVJSQU5H
RU1FTlQ6DQooWEVOKSBbMjAxMi0wOS0wNCAxNTo1MToxNl0gIERvbTAgYWxsb2MuOiAgIDAw
MDAwMDAyNDAwMDAwMDAtPjAwMDAwMDAyNDQwMDAwMDAgKDI0MjQyOCBwYWdlcyB0byBiZSBh
bGxvY2F0ZWQpDQooWEVOKSBbMjAxMi0wOS0wNCAxNTo1MToxNl0gIEluaXQuIHJhbWRpc2s6
IDAwMDAwMDAyNGYyZmMwMDAtPjAwMDAwMDAyNGZmZmY4MDANCihYRU4pIFsyMDEyLTA5LTA0
IDE1OjUxOjE2XSBWSVJUVUFMIE1FTU9SWSBBUlJBTkdFTUVOVDoNCihYRU4pIFsyMDEyLTA5
LTA0IDE1OjUxOjE2XSAgTG9hZGVkIGtlcm5lbDogZmZmZmZmZmY4MTAwMDAwMC0+ZmZmZmZm
ZmY4MmNkNTAwMA0KKFhFTikgWzIwMTItMDktMDQgMTU6NTE6MTZdICBJbml0LiByYW1kaXNr
OiBmZmZmZmZmZjgyY2Q1MDAwLT5mZmZmZmZmZjgzOWQ4ODAwDQooWEVOKSBbMjAxMi0wOS0w
NCAxNTo1MToxNl0gIFBoeXMtTWFjaCBtYXA6IGZmZmZmZmZmODM5ZDkwMDAtPmZmZmZmZmZm
ODNiZDkwMDANCihYRU4pIFsyMDEyLTA5LTA0IDE1OjUxOjE2XSAgU3RhcnQgaW5mbzogICAg
ZmZmZmZmZmY4M2JkOTAwMC0+ZmZmZmZmZmY4M2JkOTRiNA0KKFhFTikgWzIwMTItMDktMDQg
MTU6NTE6MTZdICBQYWdlIHRhYmxlczogICBmZmZmZmZmZjgzYmRhMDAwLT5mZmZmZmZmZjgz
YmZkMDAwDQooWEVOKSBbMjAxMi0wOS0wNCAxNTo1MToxNl0gIEJvb3Qgc3RhY2s6ICAgIGZm
ZmZmZmZmODNiZmQwMDAtPmZmZmZmZmZmODNiZmUwMDANCihYRU4pIFsyMDEyLTA5LTA0IDE1
OjUxOjE2XSAgVE9UQUw6ICAgICAgICAgZmZmZmZmZmY4MDAwMDAwMC0+ZmZmZmZmZmY4NDAw
MDAwMA0KKFhFTikgWzIwMTItMDktMDQgMTU6NTE6MTZdICBFTlRSWSBBRERSRVNTOiBmZmZm
ZmZmZjgxZWYwMjEwDQooWEVOKSBbMjAxMi0wOS0wNCAxNTo1MToxNl0gRG9tMCBoYXMgbWF4
aW11bSA2IFZDUFVzDQooWEVOKSBbMjAxMi0wOS0wNCAxNTo1MToxNl0gZWxmX2xvYWRfYmlu
YXJ5OiBwaGRyIDAgYXQgMHhmZmZmZmZmZjgxMDAwMDAwIC0+IDB4ZmZmZmZmZmY4MWQ2YTAw
MA0KKFhFTikgWzIwMTItMDktMDQgMTU6NTE6MTZdIGVsZl9sb2FkX2JpbmFyeTogcGhkciAx
IGF0IDB4ZmZmZmZmZmY4MWUwMDAwMCAtPiAweGZmZmZmZmZmODFlZGIwZTgNCihYRU4pIFsy
MDEyLTA5LTA0IDE1OjUxOjE2XSBlbGZfbG9hZF9iaW5hcnk6IHBoZHIgMiBhdCAweGZmZmZm
ZmZmODFlZGMwMDAgLT4gMHhmZmZmZmZmZjgxZWVmYzAwDQooWEVOKSBbMjAxMi0wOS0wNCAx
NTo1MToxNl0gZWxmX2xvYWRfYmluYXJ5OiBwaGRyIDMgYXQgMHhmZmZmZmZmZjgxZWYwMDAw
IC0+IDB4ZmZmZmZmZmY4MWY4OTAwMA0KKFhFTikgWzIwMTItMDktMDQgMTU6NTE6MTZdIEFN
RC1WaTogTUUgSEVSRSAhPDI+QU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNl
IGlkID0gMHgwMDAwLCByb290IHRhYmxlID0gMHgyNGQ4NGIwMDAsIGRvbWFpbiA9IDAsIHBh
Z2luZyBtb2RlID0gMw0KKFhFTikgWzIwMTItMDktMDQgMTU6NTE6MTZdIEFNRC1WaTogU2V0
dXAgSS9PIHBhZ2UgdGFibGU6IGRldmljZSBpZCA9IDB4MDAwMiwgcm9vdCB0YWJsZSA9IDB4
MjRkODRiMDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMNCihYRU4pIFsyMDEyLTA5
LTA0IDE1OjUxOjE2XSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQg
PSAweDAwMTAsIHJvb3QgdGFibGUgPSAweDI0ZDg0YjAwMCwgZG9tYWluID0gMCwgcGFnaW5n
IG1vZGUgPSAzDQooWEVOKSBbMjAxMi0wOS0wNCAxNTo1MToxNl0gQU1ELVZpOiBTZXR1cCBJ
L08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHgwMDE4LCByb290IHRhYmxlID0gMHgyNGQ4
NGIwMDAsIGRvbWFpbiA9IDAsIHBhZ2luZyBtb2RlID0gMw0KKFhFTikgWzIwMTItMDktMDQg
MTU6NTE6MTZdIEFNRC1WaTogU2V0dXAgSS9PIHBhZ2UgdGFibGU6IGRldmljZSBpZCA9IDB4
MDAyOCwgcm9vdCB0YWJsZSA9IDB4MjRkODRiMDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9k
ZSA9IDMNCihYRU4pIFsyMDEyLTA5LTA0IDE1OjUxOjE2XSBBTUQtVmk6IFNldHVwIEkvTyBw
YWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweDAwMzAsIHJvb3QgdGFibGUgPSAweDI0ZDg0YjAw
MCwgZG9tYWluID0gMCwgcGFnaW5nIG1vZGUgPSAzDQooWEVOKSBbMjAxMi0wOS0wNCAxNTo1
MToxNl0gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHgwMDUw
LCByb290IHRhYmxlID0gMHgyNGQ4NGIwMDAsIGRvbWFpbiA9IDAsIHBhZ2luZyBtb2RlID0g
Mw0KKFhFTikgWzIwMTItMDktMDQgMTU6NTE6MTZdIEFNRC1WaTogU2V0dXAgSS9PIHBhZ2Ug
dGFibGU6IGRldmljZSBpZCA9IDB4MDA1OCwgcm9vdCB0YWJsZSA9IDB4MjRkODRiMDAwLCBk
b21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMNCihYRU4pIFsyMDEyLTA5LTA0IDE1OjUxOjE2
XSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweDAwNjAsIHJv
b3QgdGFibGUgPSAweDI0ZDg0YjAwMCwgZG9tYWluID0gMCwgcGFnaW5nIG1vZGUgPSAzDQoo
WEVOKSBbMjAxMi0wOS0wNCAxNTo1MToxNl0gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJs
ZTogZGV2aWNlIGlkID0gMHgwMDY4LCByb290IHRhYmxlID0gMHgyNGQ4NGIwMDAsIGRvbWFp
biA9IDAsIHBhZ2luZyBtb2RlID0gMw0KKFhFTikgWzIwMTItMDktMDQgMTU6NTE6MTZdIEFN
RC1WaTogU2V0dXAgSS9PIHBhZ2UgdGFibGU6IGRldmljZSBpZCA9IDB4MDA4OCwgcm9vdCB0
YWJsZSA9IDB4MjRkODRiMDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMNCihYRU4p
IFsyMDEyLTA5LTA0IDE1OjUxOjE2XSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBk
ZXZpY2UgaWQgPSAweDAwOTAsIHJvb3QgdGFibGUgPSAweDI0ZDg0YjAwMCwgZG9tYWluID0g
MCwgcGFnaW5nIG1vZGUgPSAzDQooWEVOKSBbMjAxMi0wOS0wNCAxNTo1MToxNl0gQU1ELVZp
OiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHgwMDkyLCByb290IHRhYmxl
ID0gMHgyNGQ4NGIwMDAsIGRvbWFpbiA9IDAsIHBhZ2luZyBtb2RlID0gMw0KKFhFTikgWzIw
MTItMDktMDQgMTU6NTE6MTZdIEFNRC1WaTogU2V0dXAgSS9PIHBhZ2UgdGFibGU6IGRldmlj
ZSBpZCA9IDB4MDA5OCwgcm9vdCB0YWJsZSA9IDB4MjRkODRiMDAwLCBkb21haW4gPSAwLCBw
YWdpbmcgbW9kZSA9IDMNCihYRU4pIFsyMDEyLTA5LTA0IDE1OjUxOjE2XSBBTUQtVmk6IFNl
dHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweDAwOWEsIHJvb3QgdGFibGUgPSAw
eDI0ZDg0YjAwMCwgZG9tYWluID0gMCwgcGFnaW5nIG1vZGUgPSAzDQooWEVOKSBbMjAxMi0w
OS0wNCAxNTo1MToxNl0gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlk
ID0gMHgwMGEwLCByb290IHRhYmxlID0gMHgyNGQ4NGIwMDAsIGRvbWFpbiA9IDAsIHBhZ2lu
ZyBtb2RlID0gMw0KKFhFTikgWzIwMTItMDktMDQgMTU6NTE6MTZdIEFNRC1WaTogU2V0dXAg
SS9PIHBhZ2UgdGFibGU6IGRldmljZSBpZCA9IDB4MDBhMywgcm9vdCB0YWJsZSA9IDB4MjRk
ODRiMDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMNCihYRU4pIFsyMDEyLTA5LTA0
IDE1OjUxOjE2XSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAw
eDAwYTQsIHJvb3QgdGFibGUgPSAweDI0ZDg0YjAwMCwgZG9tYWluID0gMCwgcGFnaW5nIG1v
ZGUgPSAzDQooWEVOKSBbMjAxMi0wOS0wNCAxNTo1MToxNl0gQU1ELVZpOiBTZXR1cCBJL08g
cGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHgwMGE1LCByb290IHRhYmxlID0gMHgyNGQ4NGIw
MDAsIGRvbWFpbiA9IDAsIHBhZ2luZyBtb2RlID0gMw0KKFhFTikgWzIwMTItMDktMDQgMTU6
NTE6MTZdIEFNRC1WaTogU2V0dXAgSS9PIHBhZ2UgdGFibGU6IGRldmljZSBpZCA9IDB4MDBh
OCwgcm9vdCB0YWJsZSA9IDB4MjRkODRiMDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9
IDMNCihYRU4pIFsyMDEyLTA5LTA0IDE1OjUxOjE2XSBBTUQtVmk6IFNldHVwIEkvTyBwYWdl
IHRhYmxlOiBkZXZpY2UgaWQgPSAweDAwYjAsIHJvb3QgdGFibGUgPSAweDI0ZDg0YjAwMCwg
ZG9tYWluID0gMCwgcGFnaW5nIG1vZGUgPSAzDQooWEVOKSBbMjAxMi0wOS0wNCAxNTo1MTox
Nl0gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHgwMGIyLCBy
b290IHRhYmxlID0gMHgyNGQ4NGIwMDAsIGRvbWFpbiA9IDAsIHBhZ2luZyBtb2RlID0gMw0K
KFhFTikgWzIwMTItMDktMDQgMTU6NTE6MTZdIEFNRC1WaTogTm8gaW9tbXUgZm9yIGRldmlj
ZSAwMDAwOjAwOjE4LjANCihYRU4pIFsyMDEyLTA5LTA0IDE1OjUxOjE2XSBBTUQtVmk6IE5v
IGlvbW11IGZvciBkZXZpY2UgMDAwMDowMDoxOC4xDQooWEVOKSBbMjAxMi0wOS0wNCAxNTo1
MToxNl0gQU1ELVZpOiBObyBpb21tdSBmb3IgZGV2aWNlIDAwMDA6MDA6MTguMg0KKFhFTikg
WzIwMTItMDktMDQgMTU6NTE6MTZdIEFNRC1WaTogTm8gaW9tbXUgZm9yIGRldmljZSAwMDAw
OjAwOjE4LjMNCihYRU4pIFsyMDEyLTA5LTA0IDE1OjUxOjE2XSBBTUQtVmk6IE5vIGlvbW11
IGZvciBkZXZpY2UgMDAwMDowMDoxOC40DQooWEVOKSBbMjAxMi0wOS0wNCAxNTo1MToxNl0g
QU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHgwNDAwLCByb290
IHRhYmxlID0gMHgyNGQ4NGIwMDAsIGRvbWFpbiA9IDAsIHBhZ2luZyBtb2RlID0gMw0KKFhF
TikgWzIwMTItMDktMDQgMTU6NTE6MTddIEFNRC1WaTogU2V0dXAgSS9PIHBhZ2UgdGFibGU6
IGRldmljZSBpZCA9IDB4MDQwMSwgcm9vdCB0YWJsZSA9IDB4MjRkODRiMDAwLCBkb21haW4g
PSAwLCBwYWdpbmcgbW9kZSA9IDMNCihYRU4pIFsyMDEyLTA5LTA0IDE1OjUxOjE3XSBBTUQt
Vmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweDA0MDIsIHJvb3QgdGFi
bGUgPSAweDI0ZDg0YjAwMCwgZG9tYWluID0gMCwgcGFnaW5nIG1vZGUgPSAzDQooWEVOKSBb
MjAxMi0wOS0wNCAxNTo1MToxN10gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2
aWNlIGlkID0gMHgwNDAzLCByb290IHRhYmxlID0gMHgyNGQ4NGIwMDAsIGRvbWFpbiA9IDAs
IHBhZ2luZyBtb2RlID0gMw0KKFhFTikgWzIwMTItMDktMDQgMTU6NTE6MTddIEFNRC1WaTog
U2V0dXAgSS9PIHBhZ2UgdGFibGU6IGRldmljZSBpZCA9IDB4MDQwNCwgcm9vdCB0YWJsZSA9
IDB4MjRkODRiMDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMNCihYRU4pIFsyMDEy
LTA5LTA0IDE1OjUxOjE3XSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2Ug
aWQgPSAweDA0MDUsIHJvb3QgdGFibGUgPSAweDI0ZDg0YjAwMCwgZG9tYWluID0gMCwgcGFn
aW5nIG1vZGUgPSAzDQooWEVOKSBbMjAxMi0wOS0wNCAxNTo1MToxN10gQU1ELVZpOiBTZXR1
cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHgwNDA2LCByb290IHRhYmxlID0gMHgy
NGQ4NGIwMDAsIGRvbWFpbiA9IDAsIHBhZ2luZyBtb2RlID0gMw0KKFhFTikgWzIwMTItMDkt
MDQgMTU6NTE6MTddIEFNRC1WaTogU2V0dXAgSS9PIHBhZ2UgdGFibGU6IGRldmljZSBpZCA9
IDB4MDQwNywgcm9vdCB0YWJsZSA9IDB4MjRkODRiMDAwLCBkb21haW4gPSAwLCBwYWdpbmcg
bW9kZSA9IDMNCihYRU4pIFsyMDEyLTA5LTA0IDE1OjUxOjE3XSBBTUQtVmk6IFNldHVwIEkv
TyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweDA1MDAsIHJvb3QgdGFibGUgPSAweDI0ZDg0
YjAwMCwgZG9tYWluID0gMCwgcGFnaW5nIG1vZGUgPSAzDQooWEVOKSBbMjAxMi0wOS0wNCAx
NTo1MToxN10gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHgw
NjAwLCByb290IHRhYmxlID0gMHgyNGQ4NGIwMDAsIGRvbWFpbiA9IDAsIHBhZ2luZyBtb2Rl
ID0gMw0KKFhFTikgWzIwMTItMDktMDQgMTU6NTE6MTddIEFNRC1WaTogU2V0dXAgSS9PIHBh
Z2UgdGFibGU6IGRldmljZSBpZCA9IDB4MDYwMSwgcm9vdCB0YWJsZSA9IDB4MjRkODRiMDAw
LCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMNCihYRU4pIFsyMDEyLTA5LTA0IDE1OjUx
OjE3XSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweDA3MDAs
IHJvb3QgdGFibGUgPSAweDI0ZDg0YjAwMCwgZG9tYWluID0gMCwgcGFnaW5nIG1vZGUgPSAz
DQooWEVOKSBbMjAxMi0wOS0wNCAxNTo1MToxN10gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0
YWJsZTogZGV2aWNlIGlkID0gMHgwODAwLCByb290IHRhYmxlID0gMHgyNGQ4NGIwMDAsIGRv
bWFpbiA9IDAsIHBhZ2luZyBtb2RlID0gMw0KKFhFTikgWzIwMTItMDktMDQgMTU6NTE6MTdd
IEFNRC1WaTogU2V0dXAgSS9PIHBhZ2UgdGFibGU6IGRldmljZSBpZCA9IDB4MDkwMCwgcm9v
dCB0YWJsZSA9IDB4MjRkODRiMDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMNCihY
RU4pIFsyMDEyLTA5LTA0IDE1OjUxOjE3XSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxl
OiBkZXZpY2UgaWQgPSAweDBhMDAsIHJvb3QgdGFibGUgPSAweDI0ZDg0YjAwMCwgZG9tYWlu
ID0gMCwgcGFnaW5nIG1vZGUgPSAzDQooWEVOKSBbMjAxMi0wOS0wNCAxNTo1MToxN10gQU1E
LVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHgwYTAxLCByb290IHRh
YmxlID0gMHgyNGQ4NGIwMDAsIGRvbWFpbiA9IDAsIHBhZ2luZyBtb2RlID0gMw0KKFhFTikg
WzIwMTItMDktMDQgMTU6NTE6MTddIEFNRC1WaTogU2V0dXAgSS9PIHBhZ2UgdGFibGU6IGRl
dmljZSBpZCA9IDB4MGEwMiwgcm9vdCB0YWJsZSA9IDB4MjRkODRiMDAwLCBkb21haW4gPSAw
LCBwYWdpbmcgbW9kZSA9IDMNCihYRU4pIFsyMDEyLTA5LTA0IDE1OjUxOjE3XSBBTUQtVmk6
IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweDBhMDMsIHJvb3QgdGFibGUg
PSAweDI0ZDg0YjAwMCwgZG9tYWluID0gMCwgcGFnaW5nIG1vZGUgPSAzDQooWEVOKSBbMjAx
Mi0wOS0wNCAxNTo1MToxN10gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNl
IGlkID0gMHgwYTA0LCByb290IHRhYmxlID0gMHgyNGQ4NGIwMDAsIGRvbWFpbiA9IDAsIHBh
Z2luZyBtb2RlID0gMw0KKFhFTikgWzIwMTItMDktMDQgMTU6NTE6MTddIEFNRC1WaTogU2V0
dXAgSS9PIHBhZ2UgdGFibGU6IGRldmljZSBpZCA9IDB4MGEwNSwgcm9vdCB0YWJsZSA9IDB4
MjRkODRiMDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMNCihYRU4pIFsyMDEyLTA5
LTA0IDE1OjUxOjE3XSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQg
PSAweDBhMDYsIHJvb3QgdGFibGUgPSAweDI0ZDg0YjAwMCwgZG9tYWluID0gMCwgcGFnaW5n
IG1vZGUgPSAzDQooWEVOKSBbMjAxMi0wOS0wNCAxNTo1MToxN10gQU1ELVZpOiBTZXR1cCBJ
L08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHgwYTA3LCByb290IHRhYmxlID0gMHgyNGQ4
NGIwMDAsIGRvbWFpbiA9IDAsIHBhZ2luZyBtb2RlID0gMw0KKFhFTikgWzIwMTItMDktMDQg
MTU6NTE6MTddIEFNRC1WaTogU2V0dXAgSS9PIHBhZ2UgdGFibGU6IGRldmljZSBpZCA9IDB4
MGIwMCwgcm9vdCB0YWJsZSA9IDB4MjRkODRiMDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9k
ZSA9IDMNCihYRU4pIFsyMDEyLTA5LTA0IDE1OjUxOjE3XSBTY3J1YmJpbmcgRnJlZSBSQU06
IC4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjwwPkFNRC1WaTogSU9fUEFHRV9GQVVMVDog
ZG9tYWluID0gMCwgZGV2aWNlIGlkID0gMHgwYTA2LCBmYXVsdCBhZGRyZXNzID0gMHhjMmMy
YzJjMA0KKFhFTikgWzIwMTItMDktMDQgMTU6NTE6MThdIC4uLi4uLi4uLi4uLi4uLi4uLi4u
Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uZG9uZS4NCihYRU4pIFsyMDEyLTA5LTA0IDE1OjUx
OjE5XSBJbml0aWFsIGxvdyBtZW1vcnkgdmlycSB0aHJlc2hvbGQgc2V0IGF0IDB4NDAwMCBw
YWdlcy4NCihYRU4pIFsyMDEyLTA5LTA0IDE1OjUxOjE5XSBTdGQuIExvZ2xldmVsOiBBbGwN
CihYRU4pIFsyMDEyLTA5LTA0IDE1OjUxOjE5XSBHdWVzdCBMb2dsZXZlbDogQWxsDQooWEVO
KSBbMjAxMi0wOS0wNCAxNTo1MToxOV0gWGVuIGlzIHJlbGlucXVpc2hpbmcgVkdBIGNvbnNv
bGUuDQooWEVOKSBbMjAxMi0wOS0wNCAxNTo1MToxOV0gKioqIFNlcmlhbCBpbnB1dCAtPiBE
T00wICh0eXBlICdDVFJMLWEnIHRocmVlIHRpbWVzIHRvIHN3aXRjaCBpbnB1dCB0byBYZW4p
DQooWEVOKSBbMjAxMi0wOS0wNCAxNTo1MToxOV0gRnJlZWQgMjU2a0IgaW5pdCBtZW1vcnku
DQooWEVOKSBbMjAxMi0wOS0wNCAxNTo1MToxOV0gSU9BUElDWzBdOiBTZXQgUENJIHJvdXRp
bmcgZW50cnkgKDYtOSAtPiAweDYwIC0+IElSUSA5IE1vZGU6MSBBY3RpdmU6MSkNCihYRU4p
IFsyMDEyLTA5LTA0IDE1OjUxOjE5XSB0cmFwcy5jOjI1ODQ6ZDAgRG9tYWluIGF0dGVtcHRl
ZCBXUk1TUiAwMDAwMDAwMGMwMDAwNDA4IGZyb20gMHhjMDAwMDAwMDAxMDAwMDAwIHRvIDB4
YzAwODAwMDAwMTAwMDAwMC4NCihYRU4pIFsyMDEyLTA5LTA0IDE1OjUxOjE5XSB0cmFwcy5j
OjI1ODQ6ZDAgRG9tYWluIGF0dGVtcHRlZCBXUk1TUiAwMDAwMDAwMGMwMDAwNDA5IGZyb20g
MHhjMDAwMDAwMDAxMDAwMDAwIHRvIDB4YzAwODAwMDAwMTAwMDAwMC4NCihYRU4pIFsyMDEy
LTA5LTA0IDE1OjUxOjE5XSB0cmFwcy5jOjI1ODQ6ZDAgRG9tYWluIGF0dGVtcHRlZCBXUk1T
UiAwMDAwMDAwMGMwMDEwMDA0IGZyb20gMHgwMDAwZWZmMGJkZmIxZmNlIHRvIDB4MDAwMDAw
MDAwMDAwYWJjZC4NCihYRU4pIFsyMDEyLTA5LTA0IDE1OjUxOjE5XSB0cmFwcy5jOjI1ODQ6
ZDAgRG9tYWluIGF0dGVtcHRlZCBXUk1TUiAwMDAwMDAwMGMwMDAwNDA4IGZyb20gMHhjMDAw
MDAwMDAxMDAwMDAwIHRvIDB4YzAwODAwMDAwMTAwMDAwMC4NCihYRU4pIFsyMDEyLTA5LTA0
IDE1OjUxOjE5XSB0cmFwcy5jOjI1ODQ6ZDAgRG9tYWluIGF0dGVtcHRlZCBXUk1TUiAwMDAw
MDAwMGMwMDAwNDA5IGZyb20gMHhjMDAwMDAwMDAxMDAwMDAwIHRvIDB4YzAwODAwMDAwMTAw
MDAwMC4NCihYRU4pIFsyMDEyLTA5LTA0IDE1OjUxOjE5XSB0cmFwcy5jOjI1ODQ6ZDAgRG9t
YWluIGF0dGVtcHRlZCBXUk1TUiAwMDAwMDAwMGMwMDAwNDA4IGZyb20gMHhjMDAwMDAwMDAx
MDAwMDAwIHRvIDB4YzAwODAwMDAwMTAwMDAwMC4NCihYRU4pIFsyMDEyLTA5LTA0IDE1OjUx
OjE5XSB0cmFwcy5jOjI1ODQ6ZDAgRG9tYWluIGF0dGVtcHRlZCBXUk1TUiAwMDAwMDAwMGMw
MDAwNDA5IGZyb20gMHhjMDAwMDAwMDAxMDAwMDAwIHRvIDB4YzAwODAwMDAwMTAwMDAwMC4N
CihYRU4pIFsyMDEyLTA5LTA0IDE1OjUxOjE5XSB0cmFwcy5jOjI1ODQ6ZDAgRG9tYWluIGF0
dGVtcHRlZCBXUk1TUiAwMDAwMDAwMGMwMDAwNDA4IGZyb20gMHhjMDAwMDAwMDAxMDAwMDAw
IHRvIDB4YzAwODAwMDAwMTAwMDAwMC4NCihYRU4pIFsyMDEyLTA5LTA0IDE1OjUxOjE5XSB0
cmFwcy5jOjI1ODQ6ZDAgRG9tYWluIGF0dGVtcHRlZCBXUk1TUiAwMDAwMDAwMGMwMDAwNDA5
IGZyb20gMHhjMDAwMDAwMDAxMDAwMDAwIHRvIDB4YzAwODAwMDAwMTAwMDAwMC4NCihYRU4p
IFsyMDEyLTA5LTA0IDE1OjUxOjE5XSB0cmFwcy5jOjI1ODQ6ZDAgRG9tYWluIGF0dGVtcHRl
ZCBXUk1TUiAwMDAwMDAwMGMwMDAwNDA4IGZyb20gMHhjMDAwMDAwMDAxMDAwMDAwIHRvIDB4
YzAwODAwMDAwMTAwMDAwMC4NCihYRU4pIFsyMDEyLTA5LTA0IDE1OjUxOjE5XSB0cmFwcy5j
OjI1ODQ6ZDAgRG9tYWluIGF0dGVtcHRlZCBXUk1TUiAwMDAwMDAwMGMwMDAwNDA5IGZyb20g
MHhjMDAwMDAwMDAxMDAwMDAwIHRvIDB4YzAwODAwMDAwMTAwMDAwMC4NCihYRU4pIFsyMDEy
LTA5LTA0IDE1OjUxOjE5XSB0cmFwcy5jOjI1ODQ6ZDAgRG9tYWluIGF0dGVtcHRlZCBXUk1T
UiAwMDAwMDAwMGMwMDAwNDA4IGZyb20gMHhjMDAwMDAwMDAxMDAwMDAwIHRvIDB4YzAwODAw
MDAwMTAwMDAwMC4NCihYRU4pIFsyMDEyLTA5LTA0IDE1OjUxOjE5XSB0cmFwcy5jOjI1ODQ6
ZDAgRG9tYWluIGF0dGVtcHRlZCBXUk1TUiAwMDAwMDAwMGMwMDAwNDA5IGZyb20gMHhjMDAw
MDAwMDAxMDAwMDAwIHRvIDB4YzAwODAwMDAwMTAwMDAwMC4NCihYRU4pIFsyMDEyLTA5LTA0
IDE1OjUxOjE5XSBQQ0kgYWRkIGRldmljZSAwMDAwOjAwOjAwLjANCihYRU4pIFsyMDEyLTA5
LTA0IDE1OjUxOjE5XSBQQ0kgYWRkIGRldmljZSAwMDAwOjAwOjAwLjINCihYRU4pIFsyMDEy
LTA5LTA0IDE1OjUxOjE5XSBQQ0kgYWRkIGRldmljZSAwMDAwOjAwOjAyLjANCihYRU4pIFsy
MDEyLTA5LTA0IDE1OjUxOjE5XSBQQ0kgYWRkIGRldmljZSAwMDAwOjAwOjAzLjANCihYRU4p
IFsyMDEyLTA5LTA0IDE1OjUxOjE5XSBQQ0kgYWRkIGRldmljZSAwMDAwOjAwOjA1LjANCihY
RU4pIFsyMDEyLTA5LTA0IDE1OjUxOjE5XSBQQ0kgYWRkIGRldmljZSAwMDAwOjAwOjA2LjAN
CihYRU4pIFsyMDEyLTA5LTA0IDE1OjUxOjE5XSBQQ0kgYWRkIGRldmljZSAwMDAwOjAwOjBh
LjANCihYRU4pIFsyMDEyLTA5LTA0IDE1OjUxOjE5XSBQQ0kgYWRkIGRldmljZSAwMDAwOjAw
OjBiLjANCihYRU4pIFsyMDEyLTA5LTA0IDE1OjUxOjE5XSBQQ0kgYWRkIGRldmljZSAwMDAw
OjAwOjBjLjANCihYRU4pIFsyMDEyLTA5LTA0IDE1OjUxOjE5XSBQQ0kgYWRkIGRldmljZSAw
MDAwOjAwOjBkLjANCihYRU4pIFsyMDEyLTA5LTA0IDE1OjUxOjE5XSBQQ0kgYWRkIGRldmlj
ZSAwMDAwOjAwOjExLjANCihYRU4pIFsyMDEyLTA5LTA0IDE1OjUxOjE5XSBQQ0kgYWRkIGRl
dmljZSAwMDAwOjAwOjEyLjANCihYRU4pIFsyMDEyLTA5LTA0IDE1OjUxOjE5XSBQQ0kgYWRk
IGRldmljZSAwMDAwOjAwOjEyLjINCihYRU4pIFsyMDEyLTA5LTA0IDE1OjUxOjE5XSBQQ0kg
YWRkIGRldmljZSAwMDAwOjAwOjEzLjANCihYRU4pIFsyMDEyLTA5LTA0IDE1OjUxOjE5XSBQ
Q0kgYWRkIGRldmljZSAwMDAwOjAwOjEzLjINCihYRU4pIFsyMDEyLTA5LTA0IDE1OjUxOjE5
XSBQQ0kgYWRkIGRldmljZSAwMDAwOjAwOjE0LjANCihYRU4pIFsyMDEyLTA5LTA0IDE1OjUx
OjE5XSBQQ0kgYWRkIGRldmljZSAwMDAwOjAwOjE0LjMNCihYRU4pIFsyMDEyLTA5LTA0IDE1
OjUxOjE5XSBQQ0kgYWRkIGRldmljZSAwMDAwOjAwOjE0LjQNCihYRU4pIFsyMDEyLTA5LTA0
IDE1OjUxOjE5XSBQQ0kgYWRkIGRldmljZSAwMDAwOjAwOjE0LjUNCihYRU4pIFsyMDEyLTA5
LTA0IDE1OjUxOjE5XSBQQ0kgYWRkIGRldmljZSAwMDAwOjAwOjE1LjANCihYRU4pIFsyMDEy
LTA5LTA0IDE1OjUxOjE5XSBQQ0kgYWRkIGRldmljZSAwMDAwOjAwOjE2LjANCihYRU4pIFsy
MDEyLTA5LTA0IDE1OjUxOjE5XSBQQ0kgYWRkIGRldmljZSAwMDAwOjAwOjE2LjINCihYRU4p
IFsyMDEyLTA5LTA0IDE1OjUxOjE5XSBQQ0kgYWRkIGRldmljZSAwMDAwOjAwOjE4LjANCihY
RU4pIFsyMDEyLTA5LTA0IDE1OjUxOjE5XSBQQ0kgYWRkIGRldmljZSAwMDAwOjAwOjE4LjEN
CihYRU4pIFsyMDEyLTA5LTA0IDE1OjUxOjE5XSBQQ0kgYWRkIGRldmljZSAwMDAwOjAwOjE4
LjINCihYRU4pIFsyMDEyLTA5LTA0IDE1OjUxOjE5XSBQQ0kgYWRkIGRldmljZSAwMDAwOjAw
OjE4LjMNCihYRU4pIFsyMDEyLTA5LTA0IDE1OjUxOjE5XSBQQ0kgYWRkIGRldmljZSAwMDAw
OjAwOjE4LjQNCihYRU4pIFsyMDEyLTA5LTA0IDE1OjUxOjE5XSBQQ0kgYWRkIGRldmljZSAw
MDAwOjBiOjAwLjANCihYRU4pIFsyMDEyLTA5LTA0IDE1OjUxOjE5XSBQQ0kgYWRkIGRldmlj
ZSAwMDAwOjBhOjAwLjANCihYRU4pIFsyMDEyLTA5LTA0IDE1OjUxOjE5XSBQQ0kgYWRkIGRl
dmljZSAwMDAwOjBhOjAwLjENCihYRU4pIFsyMDEyLTA5LTA0IDE1OjUxOjE5XSBQQ0kgYWRk
IGRldmljZSAwMDAwOjBhOjAwLjINCihYRU4pIFsyMDEyLTA5LTA0IDE1OjUxOjE5XSBQQ0kg
YWRkIGRldmljZSAwMDAwOjBhOjAwLjMNCihYRU4pIFsyMDEyLTA5LTA0IDE1OjUxOjE5XSBQ
Q0kgYWRkIGRldmljZSAwMDAwOjBhOjAwLjQNCihYRU4pIFsyMDEyLTA5LTA0IDE1OjUxOjE5
XSBQQ0kgYWRkIGRldmljZSAwMDAwOjBhOjAwLjUNCihYRU4pIFsyMDEyLTA5LTA0IDE1OjUx
OjE5XSBQQ0kgYWRkIGRldmljZSAwMDAwOjBhOjAwLjYNCihYRU4pIFsyMDEyLTA5LTA0IDE1
OjUxOjE5XSBQQ0kgYWRkIGRldmljZSAwMDAwOjBhOjAwLjcNCihYRU4pIFsyMDEyLTA5LTA0
IDE1OjUxOjE5XSBQQ0kgYWRkIGRldmljZSAwMDAwOjA5OjAwLjANCihYRU4pIFsyMDEyLTA5
LTA0IDE1OjUxOjE5XSBQQ0kgYWRkIGRldmljZSAwMDAwOjA4OjAwLjANCihYRU4pIFsyMDEy
LTA5LTA0IDE1OjUxOjE5XSBQQ0kgYWRkIGRldmljZSAwMDAwOjA3OjAwLjANCihYRU4pIFsy
MDEyLTA5LTA0IDE1OjUxOjE5XSBQQ0kgYWRkIGRldmljZSAwMDAwOjA2OjAwLjANCihYRU4p
IFsyMDEyLTA5LTA0IDE1OjUxOjE5XSBQQ0kgYWRkIGRldmljZSAwMDAwOjA2OjAwLjENCihY
RU4pIFsyMDEyLTA5LTA0IDE1OjUxOjE5XSBQQ0kgYWRkIGRldmljZSAwMDAwOjA1OjAwLjAN
CihYRU4pIFsyMDEyLTA5LTA0IDE1OjUxOjE5XSBQQ0kgYWRkIGRldmljZSAwMDAwOjA0OjAw
LjANCihYRU4pIFsyMDEyLTA5LTA0IDE1OjUxOjE5XSBQQ0kgYWRkIGRldmljZSAwMDAwOjA0
OjAwLjENCihYRU4pIFsyMDEyLTA5LTA0IDE1OjUxOjE5XSBQQ0kgYWRkIGRldmljZSAwMDAw
OjA0OjAwLjINCihYRU4pIFsyMDEyLTA5LTA0IDE1OjUxOjE5XSBQQ0kgYWRkIGRldmljZSAw
MDAwOjA0OjAwLjMNCihYRU4pIFsyMDEyLTA5LTA0IDE1OjUxOjE5XSBQQ0kgYWRkIGRldmlj
ZSAwMDAwOjA0OjAwLjQNCihYRU4pIFsyMDEyLTA5LTA0IDE1OjUxOjE5XSBQQ0kgYWRkIGRl
dmljZSAwMDAwOjA0OjAwLjUNCihYRU4pIFsyMDEyLTA5LTA0IDE1OjUxOjE5XSBQQ0kgYWRk
IGRldmljZSAwMDAwOjA0OjAwLjYNCihYRU4pIFsyMDEyLTA5LTA0IDE1OjUxOjE5XSBQQ0kg
YWRkIGRldmljZSAwMDAwOjA0OjAwLjcNCihYRU4pIFsyMDEyLTA5LTA0IDE1OjUxOjE5XSBQ
Q0kgYWRkIGRldmljZSAwMDAwOjAzOjA2LjANCihYRU4pIFsyMDEyLTA5LTA0IDE1OjUxOjE5
XSBJT0FQSUNbMF06IFNldCBQQ0kgcm91dGluZyBlbnRyeSAoNi04IC0+IDB4NTggLT4gSVJR
IDggTW9kZTowIEFjdGl2ZTowKQ0KKFhFTikgWzIwMTItMDktMDQgMTU6NTE6MTldIElPQVBJ
Q1swXTogU2V0IFBDSSByb3V0aW5nIGVudHJ5ICg2LTEzIC0+IDB4ODggLT4gSVJRIDEzIE1v
ZGU6MCBBY3RpdmU6MCkNCihYRU4pIFsyMDEyLTA5LTA0IDE1OjUxOjE5XSBJT0FQSUNbMV06
IFNldCBQQ0kgcm91dGluZyBlbnRyeSAoNy0yOCAtPiAweGEwIC0+IElSUSA1MiBNb2RlOjEg
QWN0aXZlOjEpDQooWEVOKSBbMjAxMi0wOS0wNCAxNTo1MToxOV0gSU9BUElDWzFdOiBTZXQg
UENJIHJvdXRpbmcgZW50cnkgKDctMjkgLT4gMHhhOCAtPiBJUlEgNTMgTW9kZToxIEFjdGl2
ZToxKQ0KKFhFTikgWzIwMTItMDktMDQgMTU6NTE6MTldIElPQVBJQ1sxXTogU2V0IFBDSSBy
b3V0aW5nIGVudHJ5ICg3LTMwIC0+IDB4YjAgLT4gSVJRIDU0IE1vZGU6MSBBY3RpdmU6MSkN
CihYRU4pIFsyMDEyLTA5LTA0IDE1OjUxOjE5XSBJT0FQSUNbMF06IFNldCBQQ0kgcm91dGlu
ZyBlbnRyeSAoNi0xNiAtPiAweGI4IC0+IElSUSAxNiBNb2RlOjEgQWN0aXZlOjEpDQooWEVO
KSBbMjAxMi0wOS0wNCAxNTo1MToxOV0gSU9BUElDWzBdOiBTZXQgUENJIHJvdXRpbmcgZW50
cnkgKDYtMTggLT4gMHhjMCAtPiBJUlEgMTggTW9kZToxIEFjdGl2ZToxKQ0KKFhFTikgWzIw
MTItMDktMDQgMTU6NTE6MTldIElPQVBJQ1swXTogU2V0IFBDSSByb3V0aW5nIGVudHJ5ICg2
LTE3IC0+IDB4YzggLT4gSVJRIDE3IE1vZGU6MSBBY3RpdmU6MSkNCihYRU4pIFsyMDEyLTA5
LTA0IDE1OjUxOjIwXSBJT0FQSUNbMV06IFNldCBQQ0kgcm91dGluZyBlbnRyeSAoNy00IC0+
IDB4ZDAgLT4gSVJRIDI4IE1vZGU6MSBBY3RpdmU6MSkNCihYRU4pIFsyMDEyLTA5LTA0IDE1
OjUxOjIwXSBJT0FQSUNbMV06IFNldCBQQ0kgcm91dGluZyBlbnRyeSAoNy01IC0+IDB4ZDgg
LT4gSVJRIDI5IE1vZGU6MSBBY3RpdmU6MSkNCihYRU4pIFsyMDEyLTA5LTA0IDE1OjUxOjIw
XSBJT0FQSUNbMV06IFNldCBQQ0kgcm91dGluZyBlbnRyeSAoNy02IC0+IDB4MjEgLT4gSVJR
IDMwIE1vZGU6MSBBY3RpdmU6MSkNCihYRU4pIFsyMDEyLTA5LTA0IDE1OjUxOjIwXSBJT0FQ
SUNbMV06IFNldCBQQ0kgcm91dGluZyBlbnRyeSAoNy03IC0+IDB4MjkgLT4gSVJRIDMxIE1v
ZGU6MSBBY3RpdmU6MSkNCihYRU4pIFsyMDEyLTA5LTA0IDE1OjUxOjIwXSBJT0FQSUNbMV06
IFNldCBQQ0kgcm91dGluZyBlbnRyeSAoNy0xNiAtPiAweDMxIC0+IElSUSA0MCBNb2RlOjEg
QWN0aXZlOjEpDQooWEVOKSBbMjAxMi0wOS0wNCAxNTo1MToyMF0gSU9BUElDWzFdOiBTZXQg
UENJIHJvdXRpbmcgZW50cnkgKDctMTcgLT4gMHgzOSAtPiBJUlEgNDEgTW9kZToxIEFjdGl2
ZToxKQ0KKFhFTikgWzIwMTItMDktMDQgMTU6NTE6MjBdIElPQVBJQ1sxXTogU2V0IFBDSSBy
b3V0aW5nIGVudHJ5ICg3LTE4IC0+IDB4NDEgLT4gSVJRIDQyIE1vZGU6MSBBY3RpdmU6MSkN
CihYRU4pIFsyMDEyLTA5LTA0IDE1OjUxOjIwXSBJT0FQSUNbMV06IFNldCBQQ0kgcm91dGlu
ZyBlbnRyeSAoNy0xOSAtPiAweDQ5IC0+IElSUSA0MyBNb2RlOjEgQWN0aXZlOjEpDQooWEVO
KSBbMjAxMi0wOS0wNCAxNTo1MToyMF0gSU9BUElDWzBdOiBTZXQgUENJIHJvdXRpbmcgZW50
cnkgKDYtMjIgLT4gMHg5OSAtPiBJUlEgMjIgTW9kZToxIEFjdGl2ZToxKQ0KKFhFTikgWzIw
MTItMDktMDQgMTU6NTE6MjBdIElPQVBJQ1sxXTogU2V0IFBDSSByb3V0aW5nIGVudHJ5ICg3
LTEyIC0+IDB4YTEgLT4gSVJRIDM2IE1vZGU6MSBBY3RpdmU6MSkNCihYRU4pIFsyMDEyLTA5
LTA0IDE1OjUxOjIwXSBJT0FQSUNbMV06IFNldCBQQ0kgcm91dGluZyBlbnRyeSAoNy0yMyAt
PiAweGE5IC0+IElSUSA0NyBNb2RlOjEgQWN0aXZlOjEpDQooWEVOKSBbMjAxMi0wOS0wNCAx
NTo1MToyMV0gSU9BUElDWzBdOiBTZXQgUENJIHJvdXRpbmcgZW50cnkgKDYtMTkgLT4gMHhi
MSAtPiBJUlEgMTkgTW9kZToxIEFjdGl2ZToxKQ0KKFhFTikgWzIwMTItMDktMDQgMTU6NTE6
MjFdIElPQVBJQ1sxXTogU2V0IFBDSSByb3V0aW5nIGVudHJ5ICg3LTIyIC0+IDB4YzEgLT4g
SVJRIDQ2IE1vZGU6MSBBY3RpdmU6MSkNCihYRU4pIFsyMDEyLTA5LTA0IDE1OjUxOjIxXSBJ
T0FQSUNbMV06IFNldCBQQ0kgcm91dGluZyBlbnRyeSAoNy0yNyAtPiAweGQxIC0+IElSUSA1
MSBNb2RlOjEgQWN0aXZlOjEpDQooWEVOKSBbMjAxMi0wOS0wNCAxNTo1MToyM10gSU9BUElD
WzFdOiBTZXQgUENJIHJvdXRpbmcgZW50cnkgKDctOSAtPiAweDIyIC0+IElSUSAzMyBNb2Rl
OjEgQWN0aXZlOjEpDQooWEVOKSBbMjAxMi0wOS0wNCAxNTo1MjoyMl0gdHJhcHMuYzoyNTg0
OmQxIERvbWFpbiBhdHRlbXB0ZWQgV1JNU1IgMDAwMDAwMDBjMDAxMDAwNCBmcm9tIDB4MDAw
MDg2NzljMDJiNDE2NSB0byAweDAwMDAwMDAwMDAwMGFiY2QuDQooWEVOKSBbMjAxMi0wOS0w
NCAxNTo1MjoyOF0gdHJhcHMuYzoyNTg0OmQyIERvbWFpbiBhdHRlbXB0ZWQgV1JNU1IgMDAw
MDAwMDBjMDAxMDAwNCBmcm9tIDB4MDAwMDQyMzQ1YTBkYTU0NSB0byAweDAwMDAwMDAwMDAw
MGFiY2QuDQooWEVOKSBbMjAxMi0wOS0wNCAxNTo1MjozNF0gdHJhcHMuYzoyNTg0OmQzIERv
bWFpbiBhdHRlbXB0ZWQgV1JNU1IgMDAwMDAwMDBjMDAxMDAwNCBmcm9tIDB4MDAwMDg2Nzlj
MDJiNDE2NSB0byAweDAwMDAwMDAwMDAwMGFiY2QuDQooWEVOKSBbMjAxMi0wOS0wNCAxNTo1
Mjo0MV0gdHJhcHMuYzoyNTg0OmQ0IERvbWFpbiBhdHRlbXB0ZWQgV1JNU1IgMDAwMDAwMDBj
MDAxMDAwNCBmcm9tIDB4MDAwMDZmYjAzOWRlNzkwMCB0byAweDAwMDAwMDAwMDAwMGFiY2Qu
DQooWEVOKSBbMjAxMi0wOS0wNCAxNTo1Mjo0N10gdHJhcHMuYzoyNTg0OmQ1IERvbWFpbiBh
dHRlbXB0ZWQgV1JNU1IgMDAwMDAwMDBjMDAxMDAwNCBmcm9tIDB4MDAwMDZmYjAzOWRlNzkw
MCB0byAweDAwMDAwMDAwMDAwMGFiY2QuDQooWEVOKSBbMjAxMi0wOS0wNCAxNTo1Mjo1M10g
dHJhcHMuYzoyNTg0OmQ2IERvbWFpbiBhdHRlbXB0ZWQgV1JNU1IgMDAwMDAwMDBjMDAxMDAw
NCBmcm9tIDB4MDAwMGExOTVjNDBmNjE4ZiB0byAweDAwMDAwMDAwMDAwMGFiY2QuDQooWEVO
KSBbMjAxMi0wOS0wNCAxNTo1Mjo1OV0gdHJhcHMuYzoyNTg0OmQ3IERvbWFpbiBhdHRlbXB0
ZWQgV1JNU1IgMDAwMDAwMDBjMDAxMDAwNCBmcm9tIDB4MDAwMGExOTVjNDBmNjE4ZiB0byAw
eDAwMDAwMDAwMDAwMGFiY2QuDQooWEVOKSBbMjAxMi0wOS0wNCAxNTo1MzowOF0gdHJhcHMu
YzoyNTg0OmQ4IERvbWFpbiBhdHRlbXB0ZWQgV1JNU1IgMDAwMDAwMDBjMDAxMDAwNCBmcm9t
IDB4MDAwMDg2NzljMDJiNDE2NSB0byAweDAwMDAwMDAwMDAwMGFiY2QuDQooWEVOKSBbMjAx
Mi0wOS0wNCAxNTo1MzoxNF0gdHJhcHMuYzoyNTg0OmQ5IERvbWFpbiBhdHRlbXB0ZWQgV1JN
U1IgMDAwMDAwMDBjMDAxMDAwNCBmcm9tIDB4MDAwMGExOTVjNDBmNjE4ZiB0byAweDAwMDAw
MDAwMDAwMGFiY2QuDQooWEVOKSBbMjAxMi0wOS0wNCAxNTo1MzoyMF0gdHJhcHMuYzoyNTg0
OmQxMCBEb21haW4gYXR0ZW1wdGVkIFdSTVNSIDAwMDAwMDAwYzAwMTAwMDQgZnJvbSAweDAw
MDBhMTk1YzQwZjYxOGYgdG8gMHgwMDAwMDAwMDAwMDBhYmNkLg0KKFhFTikgWzIwMTItMDkt
MDQgMTU6NTM6MjddIEFNRC1WaTogRGlzYWJsZTogZGV2aWNlIGlkID0gMHgwMGE0LCBkb21h
aW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMNCihYRU4pIFsyMDEyLTA5LTA0IDE1OjUzOjI3XSBB
TUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweDAwYTQsIHJvb3Qg
dGFibGUgPSAweDE4ZTBhMTAwMCwgZG9tYWluID0gMTEsIHBhZ2luZyBtb2RlID0gMw0KKFhF
TikgWzIwMTItMDktMDQgMTU6NTM6MjddIEFNRC1WaTogUmUtYXNzaWduIDAwMDA6MDM6MDYu
MCBmcm9tIGRvbTAgdG8gZG9tMTENCihYRU4pIFsyMDEyLTA5LTA0IDE1OjUzOjI3XSB0cmFw
cy5jOjI1ODQ6ZDExIERvbWFpbiBhdHRlbXB0ZWQgV1JNU1IgMDAwMDAwMDBjMDAxMDAwNCBm
cm9tIDB4MDAwMGExOTVjNDBmNjE4ZiB0byAweDAwMDAwMDAwMDAwMGFiY2QuDQooWEVOKSBb
MjAxMi0wOS0wNCAxNTo1MzozOF0gdHJhcHMuYzoyNTg0OmQxMiBEb21haW4gYXR0ZW1wdGVk
IFdSTVNSIDAwMDAwMDAwYzAwMTAwMDQgZnJvbSAweDAwMDA0MjM0NWEwZGE1NDUgdG8gMHgw
MDAwMDAwMDAwMDBhYmNkLg0KKFhFTikgWzIwMTItMDktMDQgMTU6NTM6NDRdIHRyYXBzLmM6
MjU4NDpkMTMgRG9tYWluIGF0dGVtcHRlZCBXUk1TUiAwMDAwMDAwMGMwMDEwMDA0IGZyb20g
MHgwMDAwODY3OWMwMmI0MTY1IHRvIDB4MDAwMDAwMDAwMDAwYWJjZC4NCihYRU4pIFsyMDEy
LTA5LTA0IDE1OjUzOjUxXSBBTUQtVmk6IERpc2FibGU6IGRldmljZSBpZCA9IDB4MGEwMCwg
ZG9tYWluID0gMCwgcGFnaW5nIG1vZGUgPSAzDQooWEVOKSBbMjAxMi0wOS0wNCAxNTo1Mzo1
MV0gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHgwYTAwLCBy
b290IHRhYmxlID0gMHgxZTFmYzAwMDAsIGRvbWFpbiA9IDE0LCBwYWdpbmcgbW9kZSA9IDMN
CihYRU4pIFsyMDEyLTA5LTA0IDE1OjUzOjUxXSBBTUQtVmk6IFJlLWFzc2lnbiAwMDAwOjBh
OjAwLjAgZnJvbSBkb20wIHRvIGRvbTE0DQooWEVOKSBbMjAxMi0wOS0wNCAxNTo1Mzo1MV0g
QU1ELVZpOiBEaXNhYmxlOiBkZXZpY2UgaWQgPSAweDBhMDEsIGRvbWFpbiA9IDAsIHBhZ2lu
ZyBtb2RlID0gMw0KKFhFTikgWzIwMTItMDktMDQgMTU6NTM6NTFdIEFNRC1WaTogU2V0dXAg
SS9PIHBhZ2UgdGFibGU6IGRldmljZSBpZCA9IDB4MGEwMSwgcm9vdCB0YWJsZSA9IDB4MWUx
ZmMwMDAwLCBkb21haW4gPSAxNCwgcGFnaW5nIG1vZGUgPSAzDQooWEVOKSBbMjAxMi0wOS0w
NCAxNTo1Mzo1MV0gQU1ELVZpOiBSZS1hc3NpZ24gMDAwMDowYTowMC4xIGZyb20gZG9tMCB0
byBkb20xNA0KKFhFTikgWzIwMTItMDktMDQgMTU6NTM6NTFdIEFNRC1WaTogRGlzYWJsZTog
ZGV2aWNlIGlkID0gMHgwYTAyLCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMNCihYRU4p
IFsyMDEyLTA5LTA0IDE1OjUzOjUxXSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBk
ZXZpY2UgaWQgPSAweDBhMDIsIHJvb3QgdGFibGUgPSAweDFlMWZjMDAwMCwgZG9tYWluID0g
MTQsIHBhZ2luZyBtb2RlID0gMw0KKFhFTikgWzIwMTItMDktMDQgMTU6NTM6NTFdIEFNRC1W
aTogUmUtYXNzaWduIDAwMDA6MGE6MDAuMiBmcm9tIGRvbTAgdG8gZG9tMTQNCihYRU4pIFsy
MDEyLTA5LTA0IDE1OjUzOjUxXSBBTUQtVmk6IERpc2FibGU6IGRldmljZSBpZCA9IDB4MGEw
MywgZG9tYWluID0gMCwgcGFnaW5nIG1vZGUgPSAzDQooWEVOKSBbMjAxMi0wOS0wNCAxNTo1
Mzo1MV0gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHgwYTAz
LCByb290IHRhYmxlID0gMHgxZTFmYzAwMDAsIGRvbWFpbiA9IDE0LCBwYWdpbmcgbW9kZSA9
IDMNCihYRU4pIFsyMDEyLTA5LTA0IDE1OjUzOjUxXSBBTUQtVmk6IFJlLWFzc2lnbiAwMDAw
OjBhOjAwLjMgZnJvbSBkb20wIHRvIGRvbTE0DQooWEVOKSBbMjAxMi0wOS0wNCAxNTo1Mzo1
MV0gQU1ELVZpOiBEaXNhYmxlOiBkZXZpY2UgaWQgPSAweDBhMDQsIGRvbWFpbiA9IDAsIHBh
Z2luZyBtb2RlID0gMw0KKFhFTikgWzIwMTItMDktMDQgMTU6NTM6NTFdIEFNRC1WaTogU2V0
dXAgSS9PIHBhZ2UgdGFibGU6IGRldmljZSBpZCA9IDB4MGEwNCwgcm9vdCB0YWJsZSA9IDB4
MWUxZmMwMDAwLCBkb21haW4gPSAxNCwgcGFnaW5nIG1vZGUgPSAzDQooWEVOKSBbMjAxMi0w
OS0wNCAxNTo1Mzo1MV0gQU1ELVZpOiBSZS1hc3NpZ24gMDAwMDowYTowMC40IGZyb20gZG9t
MCB0byBkb20xNA0KKFhFTikgWzIwMTItMDktMDQgMTU6NTM6NTFdIEFNRC1WaTogRGlzYWJs
ZTogZGV2aWNlIGlkID0gMHgwYTA1LCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMNCihY
RU4pIFsyMDEyLTA5LTA0IDE1OjUzOjUxXSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxl
OiBkZXZpY2UgaWQgPSAweDBhMDUsIHJvb3QgdGFibGUgPSAweDFlMWZjMDAwMCwgZG9tYWlu
ID0gMTQsIHBhZ2luZyBtb2RlID0gMw0KKFhFTikgWzIwMTItMDktMDQgMTU6NTM6NTFdIEFN
RC1WaTogUmUtYXNzaWduIDAwMDA6MGE6MDAuNSBmcm9tIGRvbTAgdG8gZG9tMTQNCihYRU4p
IFsyMDEyLTA5LTA0IDE1OjUzOjUxXSBBTUQtVmk6IERpc2FibGU6IGRldmljZSBpZCA9IDB4
MGEwNiwgZG9tYWluID0gMCwgcGFnaW5nIG1vZGUgPSAzDQooWEVOKSBbMjAxMi0wOS0wNCAx
NTo1Mzo1MV0gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHgw
YTA2LCByb290IHRhYmxlID0gMHgxZTFmYzAwMDAsIGRvbWFpbiA9IDE0LCBwYWdpbmcgbW9k
ZSA9IDMNCihYRU4pIFsyMDEyLTA5LTA0IDE1OjUzOjUxXSBBTUQtVmk6IFJlLWFzc2lnbiAw
MDAwOjBhOjAwLjYgZnJvbSBkb20wIHRvIGRvbTE0DQooWEVOKSBbMjAxMi0wOS0wNCAxNTo1
Mzo1MV0gQU1ELVZpOiBEaXNhYmxlOiBkZXZpY2UgaWQgPSAweDBhMDcsIGRvbWFpbiA9IDAs
IHBhZ2luZyBtb2RlID0gMw0KKFhFTikgWzIwMTItMDktMDQgMTU6NTM6NTFdIEFNRC1WaTog
U2V0dXAgSS9PIHBhZ2UgdGFibGU6IGRldmljZSBpZCA9IDB4MGEwNywgcm9vdCB0YWJsZSA9
IDB4MWUxZmMwMDAwLCBkb21haW4gPSAxNCwgcGFnaW5nIG1vZGUgPSAzDQooWEVOKSBbMjAx
Mi0wOS0wNCAxNTo1Mzo1MV0gQU1ELVZpOiBSZS1hc3NpZ24gMDAwMDowYTowMC43IGZyb20g
ZG9tMCB0byBkb20xNA0KKFhFTikgWzIwMTItMDktMDQgMTU6NTM6NTFdIEFNRC1WaTogRGlz
YWJsZTogZGV2aWNlIGlkID0gMHgwNzAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMN
CihYRU4pIFsyMDEyLTA5LTA0IDE1OjUzOjUxXSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRh
YmxlOiBkZXZpY2UgaWQgPSAweDA3MDAsIHJvb3QgdGFibGUgPSAweDFlMWZjMDAwMCwgZG9t
YWluID0gMTQsIHBhZ2luZyBtb2RlID0gMw0KKFhFTikgWzIwMTItMDktMDQgMTU6NTM6NTFd
IEFNRC1WaTogUmUtYXNzaWduIDAwMDA6MDc6MDAuMCBmcm9tIGRvbTAgdG8gZG9tMTQNCihY
RU4pIFsyMDEyLTA5LTA0IDE1OjUzOjUxXSB0cmFwcy5jOjI1ODQ6ZDE0IERvbWFpbiBhdHRl
bXB0ZWQgV1JNU1IgMDAwMDAwMDBjMDAxMDAwNCBmcm9tIDB4MDAwMDQyMzQ1YTBkYTU0NSB0
byAweDAwMDAwMDAwMDAwMGFiY2QuDQooWEVOKSBbMjAxMi0wOS0wNCAxNTo1NDowMF0gSFZN
MTU6IEhWTSBMb2FkZXINCihYRU4pIFsyMDEyLTA5LTA0IDE1OjU0OjAwXSBIVk0xNTogRGV0
ZWN0ZWQgWGVuIHY0LjIuMC1yYzQtcHJlDQooWEVOKSBbMjAxMi0wOS0wNCAxNTo1NDowMF0g
SFZNMTU6IFhlbmJ1cyByaW5ncyBAMHhmZWZmYzAwMCwgZXZlbnQgY2hhbm5lbCA0DQooWEVO
KSBbMjAxMi0wOS0wNCAxNTo1NDowMF0gSFZNMTU6IFN5c3RlbSByZXF1ZXN0ZWQgUk9NQklP
Uw0KKFhFTikgWzIwMTItMDktMDQgMTU6NTQ6MDBdIEhWTTE1OiBDUFUgc3BlZWQgaXMgMzIw
MCBNSHoNCihYRU4pIFsyMDEyLTA5LTA0IDE1OjU0OjAwXSBpcnEuYzoyNzA6IERvbTE1IFBD
SSBsaW5rIDAgY2hhbmdlZCAwIC0+IDUNCihYRU4pIFsyMDEyLTA5LTA0IDE1OjU0OjAwXSBI
Vk0xNTogUENJLUlTQSBsaW5rIDAgcm91dGVkIHRvIElSUTUNCihYRU4pIFsyMDEyLTA5LTA0
IDE1OjU0OjAwXSBpcnEuYzoyNzA6IERvbTE1IFBDSSBsaW5rIDEgY2hhbmdlZCAwIC0+IDEw
DQooWEVOKSBbMjAxMi0wOS0wNCAxNTo1NDowMF0gSFZNMTU6IFBDSS1JU0EgbGluayAxIHJv
dXRlZCB0byBJUlExMA0KKFhFTikgWzIwMTItMDktMDQgMTU6NTQ6MDBdIGlycS5jOjI3MDog
RG9tMTUgUENJIGxpbmsgMiBjaGFuZ2VkIDAgLT4gMTENCihYRU4pIFsyMDEyLTA5LTA0IDE1
OjU0OjAwXSBIVk0xNTogUENJLUlTQSBsaW5rIDIgcm91dGVkIHRvIElSUTExDQooWEVOKSBb
MjAxMi0wOS0wNCAxNTo1NDowMF0gaXJxLmM6MjcwOiBEb20xNSBQQ0kgbGluayAzIGNoYW5n
ZWQgMCAtPiA1DQooWEVOKSBbMjAxMi0wOS0wNCAxNTo1NDowMF0gSFZNMTU6IFBDSS1JU0Eg
bGluayAzIHJvdXRlZCB0byBJUlE1DQooWEVOKSBbMjAxMi0wOS0wNCAxNTo1NDowMF0gSFZN
MTU6IHBjaSBkZXYgMDE6MiBJTlRELT5JUlE1DQooWEVOKSBbMjAxMi0wOS0wNCAxNTo1NDow
MF0gSFZNMTU6IHBjaSBkZXYgMDE6MyBJTlRBLT5JUlExMA0KKFhFTikgWzIwMTItMDktMDQg
MTU6NTQ6MDBdIEhWTTE1OiBwY2kgZGV2IDAzOjAgSU5UQS0+SVJRNQ0KKFhFTikgWzIwMTIt
MDktMDQgMTU6NTQ6MDBdIEhWTTE1OiBwY2kgZGV2IDA0OjAgSU5UQS0+SVJRNQ0KKFhFTikg
WzIwMTItMDktMDQgMTU6NTQ6MDFdIEhWTTE1OiBwY2kgZGV2IDAyOjAgYmFyIDEwIHNpemUg
MDIwMDAwMDA6IGYwMDAwMDA4DQooWEVOKSBbMjAxMi0wOS0wNCAxNTo1NDowMV0gSFZNMTU6
IHBjaSBkZXYgMDM6MCBiYXIgMTQgc2l6ZSAwMTAwMDAwMDogZjIwMDAwMDgNCihYRU4pIFsy
MDEyLTA5LTA0IDE1OjU0OjAxXSBIVk0xNTogcGNpIGRldiAwNDowIGJhciAxMCBzaXplIDAw
MDIwMDAwOiBmMzAwMDAwMA0KKFhFTikgWzIwMTItMDktMDQgMTU6NTQ6MDFdIEhWTTE1OiBw
Y2kgZGV2IDAyOjAgYmFyIDE0IHNpemUgMDAwMDEwMDA6IGYzMDIwMDAwDQooWEVOKSBbMjAx
Mi0wOS0wNCAxNTo1NDowMV0gSFZNMTU6IHBjaSBkZXYgMDM6MCBiYXIgMTAgc2l6ZSAwMDAw
MDEwMDogMDAwMGMwMDENCihYRU4pIFsyMDEyLTA5LTA0IDE1OjU0OjAxXSBIVk0xNTogcGNp
IGRldiAwNDowIGJhciAxNCBzaXplIDAwMDAwMDQwOiAwMDAwYzEwMQ0KKFhFTikgWzIwMTIt
MDktMDQgMTU6NTQ6MDFdIEhWTTE1OiBwY2kgZGV2IDAxOjIgYmFyIDIwIHNpemUgMDAwMDAw
MjA6IDAwMDBjMTQxDQooWEVOKSBbMjAxMi0wOS0wNCAxNTo1NDowMV0gSFZNMTU6IHBjaSBk
ZXYgMDE6MSBiYXIgMjAgc2l6ZSAwMDAwMDAxMDogMDAwMGMxNjENCihYRU4pIFsyMDEyLTA5
LTA0IDE1OjU0OjAxXSBIVk0xNTogTXVsdGlwcm9jZXNzb3IgaW5pdGlhbGlzYXRpb246DQoo
WEVOKSBbMjAxMi0wOS0wNCAxNTo1NDowMV0gSFZNMTU6ICAtIENQVTAgLi4uIDQ4LWJpdCBw
aHlzIC4uLiBmaXhlZCBNVFJScyAuLi4gdmFyIE1UUlJzIFsyLzhdIC4uLiBkb25lLg0KKFhF
TikgWzIwMTItMDktMDQgMTU6NTQ6MDFdIEhWTTE1OiAgLSBDUFUxIC4uLiA0OC1iaXQgcGh5
cyAuLi4gZml4ZWQgTVRSUnMgLi4uIHZhciBNVFJScyBbMi84XSAuLi4gZG9uZS4NCihYRU4p
IFsyMDEyLTA5LTA0IDE1OjU0OjAxXSBIVk0xNTogVGVzdGluZyBIVk0gZW52aXJvbm1lbnQ6
DQooWEVOKSBbMjAxMi0wOS0wNCAxNTo1NDowMV0gSFZNMTU6ICAtIFJFUCBJTlNCIGFjcm9z
cyBwYWdlIGJvdW5kYXJpZXMgLi4uIHBhc3NlZA0KKFhFTikgWzIwMTItMDktMDQgMTU6NTQ6
MDFdIEhWTTE1OiAgLSBHUyBiYXNlIE1TUnMgYW5kIFNXQVBHUyAuLi4gcGFzc2VkDQooWEVO
KSBbMjAxMi0wOS0wNCAxNTo1NDowMV0gSFZNMTU6IFBhc3NlZCAyIG9mIDIgdGVzdHMNCihY
RU4pIFsyMDEyLTA5LTA0IDE1OjU0OjAxXSBIVk0xNTogV3JpdGluZyBTTUJJT1MgdGFibGVz
IC4uLg0KKFhFTikgWzIwMTItMDktMDQgMTU6NTQ6MDFdIEhWTTE1OiBMb2FkaW5nIFJPTUJJ
T1MgLi4uDQooWEVOKSBbMjAxMi0wOS0wNCAxNTo1NDowMV0gSFZNMTU6IDk2NjAgYnl0ZXMg
b2YgUk9NQklPUyBoaWdoLW1lbW9yeSBleHRlbnNpb25zOg0KKFhFTikgWzIwMTItMDktMDQg
MTU6NTQ6MDFdIEhWTTE1OiAgIFJlbG9jYXRpbmcgdG8gMHhmYzAwMTAwMC0weGZjMDAzNWJj
IC4uLiBkb25lDQooWEVOKSBbMjAxMi0wOS0wNCAxNTo1NDowMV0gSFZNMTU6IENyZWF0aW5n
IE1QIHRhYmxlcyAuLi4NCihYRU4pIFsyMDEyLTA5LTA0IDE1OjU0OjAxXSBIVk0xNTogTG9h
ZGluZyBDaXJydXMgVkdBQklPUyAuLi4NCihYRU4pIFsyMDEyLTA5LTA0IDE1OjU0OjAxXSBI
Vk0xNTogTG9hZGluZyBQQ0kgT3B0aW9uIFJPTSAuLi4NCihYRU4pIFsyMDEyLTA5LTA0IDE1
OjU0OjAxXSBIVk0xNTogIC0gTWFudWZhY3R1cmVyOiBodHRwOi8vaXB4ZS5vcmcNCihYRU4p
IFsyMDEyLTA5LTA0IDE1OjU0OjAxXSBIVk0xNTogIC0gUHJvZHVjdCBuYW1lOiBpUFhFDQoo
WEVOKSBbMjAxMi0wOS0wNCAxNTo1NDowMV0gSFZNMTU6IE9wdGlvbiBST01zOg0KKFhFTikg
WzIwMTItMDktMDQgMTU6NTQ6MDFdIEhWTTE1OiAgYzAwMDAtYzhmZmY6IFZHQSBCSU9TDQoo
WEVOKSBbMjAxMi0wOS0wNCAxNTo1NDowMV0gSFZNMTU6ICBjOTAwMC1kOWZmZjogRXRoZXJi
b290IFJPTQ0KKFhFTikgWzIwMTItMDktMDQgMTU6NTQ6MDFdIEhWTTE1OiBMb2FkaW5nIEFD
UEkgLi4uDQooWEVOKSBbMjAxMi0wOS0wNCAxNTo1NDowMV0gSFZNMTU6IHZtODYgVFNTIGF0
IGZjMDBmNjgwDQooWEVOKSBbMjAxMi0wOS0wNCAxNTo1NDowMV0gSFZNMTU6IEJJT1MgbWFw
Og0KKFhFTikgWzIwMTItMDktMDQgMTU6NTQ6MDFdIEhWTTE1OiAgZjAwMDAtZmZmZmY6IE1h
aW4gQklPUw0KKFhFTikgWzIwMTItMDktMDQgMTU6NTQ6MDFdIEhWTTE1OiBFODIwIHRhYmxl
Og0KKFhFTikgWzIwMTItMDktMDQgMTU6NTQ6MDFdIEhWTTE1OiAgWzAwXTogMDAwMDAwMDA6
MDAwMDAwMDAgLSAwMDAwMDAwMDowMDA5ZTAwMDogUkFNDQooWEVOKSBbMjAxMi0wOS0wNCAx
NTo1NDowMV0gSFZNMTU6ICBbMDFdOiAwMDAwMDAwMDowMDA5ZTAwMCAtIDAwMDAwMDAwOjAw
MGEwMDAwOiBSRVNFUlZFRA0KKFhFTikgWzIwMTItMDktMDQgMTU6NTQ6MDFdIEhWTTE1OiAg
SE9MRTogMDAwMDAwMDA6MDAwYTAwMDAgLSAwMDAwMDAwMDowMDBlMDAwMA0KKFhFTikgWzIw
MTItMDktMDQgMTU6NTQ6MDFdIEhWTTE1OiAgWzAyXTogMDAwMDAwMDA6MDAwZTAwMDAgLSAw
MDAwMDAwMDowMDEwMDAwMDogUkVTRVJWRUQNCihYRU4pIFsyMDEyLTA5LTA0IDE1OjU0OjAx
XSBIVk0xNTogIFswM106IDAwMDAwMDAwOjAwMTAwMDAwIC0gMDAwMDAwMDA6MWY4MDAwMDA6
IFJBTQ0KKFhFTikgWzIwMTItMDktMDQgMTU6NTQ6MDFdIEhWTTE1OiAgSE9MRTogMDAwMDAw
MDA6MWY4MDAwMDAgLSAwMDAwMDAwMDpmYzAwMDAwMA0KKFhFTikgWzIwMTItMDktMDQgMTU6
NTQ6MDFdIEhWTTE1OiAgWzA0XTogMDAwMDAwMDA6ZmMwMDAwMDAgLSAwMDAwMDAwMTowMDAw
MDAwMDogUkVTRVJWRUQNCihYRU4pIFsyMDEyLTA5LTA0IDE1OjU0OjAxXSBIVk0xNTogSW52
b2tpbmcgUk9NQklPUyAuLi4NCihYRU4pIFsyMDEyLTA5LTA0IDE1OjU0OjAxXSBIVk0xNTog
JFJldmlzaW9uOiAxLjIyMSAkICREYXRlOiAyMDA4LzEyLzA3IDE3OjMyOjI5ICQNCihYRU4p
IFsyMDEyLTA5LTA0IDE1OjU0OjAxXSBzdGR2Z2EuYzoxNDc6ZDE1IGVudGVyaW5nIHN0ZHZn
YSBhbmQgY2FjaGluZyBtb2Rlcw0KKFhFTikgWzIwMTItMDktMDQgMTU6NTQ6MDFdIEhWTTE1
OiBWR0FCaW9zICRJZDogdmdhYmlvcy5jLHYgMS42NyAyMDA4LzAxLzI3IDA5OjQ0OjEyIHZy
dXBwZXJ0IEV4cCAkDQooWEVOKSBbMjAxMi0wOS0wNCAxNTo1NDowMV0gSFZNMTU6IEJvY2hz
IEJJT1MgLSBidWlsZDogMDYvMjMvOTkNCihYRU4pIFsyMDEyLTA5LTA0IDE1OjU0OjAxXSBI
Vk0xNTogJFJldmlzaW9uOiAxLjIyMSAkICREYXRlOiAyMDA4LzEyLzA3IDE3OjMyOjI5ICQN
CihYRU4pIFsyMDEyLTA5LTA0IDE1OjU0OjAxXSBIVk0xNTogT3B0aW9uczogYXBtYmlvcyBw
Y2liaW9zIGVsdG9yaXRvIFBNTSANCihYRU4pIFsyMDEyLTA5LTA0IDE1OjU0OjAxXSBIVk0x
NTogDQooWEVOKSBbMjAxMi0wOS0wNCAxNTo1NDowMV0gSFZNMTU6IGF0YTAtMDogUENIUz0x
NjM4My8xNi82MyB0cmFuc2xhdGlvbj1sYmEgTENIUz0xMDI0LzI1NS82Mw0KKFhFTikgWzIw
MTItMDktMDQgMTU6NTQ6MDFdIEhWTTE1OiBhdGEwIG1hc3RlcjogUUVNVSBIQVJERElTSyBB
VEEtNyBIYXJkLURpc2sgKDU3MjQ0IE1CeXRlcykNCihYRU4pIFsyMDEyLTA5LTA0IDE1OjU0
OjAyXSBIVk0xNTogSURFIHRpbWUgb3V0DQooWEVOKSBbMjAxMi0wOS0wNCAxNTo1NDowMl0g
SFZNMTU6IGF0YTEgbWFzdGVyOiBRRU1VIERWRC1ST00gQVRBUEktNCBDRC1Sb20vRFZELVJv
bQ0KKFhFTikgWzIwMTItMDktMDQgMTU6NTQ6MDRdIEhWTTE1OiBJREUgdGltZSBvdXQNCihY
RU4pIFsyMDEyLTA5LTA0IDE1OjU0OjA0XSBIVk0xNTogDQooWEVOKSBbMjAxMi0wOS0wNCAx
NTo1NDowNF0gSFZNMTU6IA0KKFhFTikgWzIwMTItMDktMDQgMTU6NTQ6MDRdIEhWTTE1OiAN
CihYRU4pIFsyMDEyLTA5LTA0IDE1OjU0OjA0XSBIVk0xNTogUHJlc3MgRjEyIGZvciBib290
IG1lbnUuDQooWEVOKSBbMjAxMi0wOS0wNCAxNTo1NDowNF0gSFZNMTU6IA0KKFhFTikgWzIw
MTItMDktMDQgMTU6NTQ6MDRdIEhWTTE1OiBCb290aW5nIGZyb20gSGFyZCBEaXNrLi4uDQoo
WEVOKSBbMjAxMi0wOS0wNCAxNTo1NDowNF0gSFZNMTU6IEJvb3RpbmcgZnJvbSAwMDAwOjdj
MDANCihYRU4pIFsyMDEyLTA5LTA0IDE1OjU0OjMyXSBpcnEuYzoyNzA6IERvbTE1IFBDSSBs
aW5rIDAgY2hhbmdlZCA1IC0+IDANCihYRU4pIFsyMDEyLTA5LTA0IDE1OjU0OjMyXSBpcnEu
YzoyNzA6IERvbTE1IFBDSSBsaW5rIDEgY2hhbmdlZCAxMCAtPiAwDQooWEVOKSBbMjAxMi0w
OS0wNCAxNTo1NDozMl0gaXJxLmM6MjcwOiBEb20xNSBQQ0kgbGluayAyIGNoYW5nZWQgMTEg
LT4gMA0KKFhFTikgWzIwMTItMDktMDQgMTU6NTQ6MzJdIGlycS5jOjI3MDogRG9tMTUgUENJ
IGxpbmsgMyBjaGFuZ2VkIDUgLT4gMA0KKFhFTikgWzIwMTItMDktMDQgMTU6NTQ6MzNdIGh2
bS5jOjI0MzU6ZDE1IGd1ZXN0IGF0dGVtcHRlZCB3cml0ZSB0byByZWFkLW9ubHkgbWVtb3J5
IHBhZ2UuIGdmbj0weGRjLCBtZm49MHhhNGEwYQ0KKFhFTikgWzIwMTItMDktMDQgMTU6NTQ6
MzNdIGh2bS5jOjI0MzU6ZDE1IGd1ZXN0IGF0dGVtcHRlZCB3cml0ZSB0byByZWFkLW9ubHkg
bWVtb3J5IHBhZ2UuIGdmbj0weGRkLCBtZm49MHhhNGEwOQ0KKFhFTikgWzIwMTItMDktMDQg
MTU6NTQ6MzNdIGh2bS5jOjI0MzU6ZDE1IGd1ZXN0IGF0dGVtcHRlZCB3cml0ZSB0byByZWFk
LW9ubHkgbWVtb3J5IHBhZ2UuIGdmbj0weGRlLCBtZm49MHhhNGEwOA0KKFhFTikgWzIwMTIt
MDktMDQgMTU6NTQ6MzNdIGh2bS5jOjI0MzU6ZDE1IGd1ZXN0IGF0dGVtcHRlZCB3cml0ZSB0
byByZWFkLW9ubHkgbWVtb3J5IHBhZ2UuIGdmbj0weGRkLCBtZm49MHhhNGEwOQ0KKFhFTikg
WzIwMTItMDktMDQgMTU6NTQ6MzNdIGh2bS5jOjI0MzU6ZDE1IGd1ZXN0IGF0dGVtcHRlZCB3
cml0ZSB0byByZWFkLW9ubHkgbWVtb3J5IHBhZ2UuIGdmbj0weGRjLCBtZm49MHhhNGEwYQ0K
KFhFTikgWzIwMTItMDktMDQgMTU6NTQ6MzNdIGh2bS5jOjI0MzU6ZDE1IGd1ZXN0IGF0dGVt
cHRlZCB3cml0ZSB0byByZWFkLW9ubHkgbWVtb3J5IHBhZ2UuIGdmbj0weGRlLCBtZm49MHhh
NGEwOA0KKFhFTikgWzIwMTItMDktMDQgMTU6NTQ6MzNdIGh2bS5jOjI0MzU6ZDE1IGd1ZXN0
IGF0dGVtcHRlZCB3cml0ZSB0byByZWFkLW9ubHkgbWVtb3J5IHBhZ2UuIGdmbj0weGRkLCBt
Zm49MHhhNGEwOQ0KKFhFTikgWzIwMTItMDktMDQgMTU6NTQ6MzNdIGh2bS5jOjI0MzU6ZDE1
IGd1ZXN0IGF0dGVtcHRlZCB3cml0ZSB0byByZWFkLW9ubHkgbWVtb3J5IHBhZ2UuIGdmbj0w
eGRlLCBtZm49MHhhNGEwOA0KKFhFTikgWzIwMTItMDktMDQgMTU6NTQ6MzNdIGh2bS5jOjI0
MzU6ZDE1IGd1ZXN0IGF0dGVtcHRlZCB3cml0ZSB0byByZWFkLW9ubHkgbWVtb3J5IHBhZ2Uu
IGdmbj0weGRjLCBtZm49MHhhNGEwYQ0KKFhFTikgWzIwMTItMDktMDQgMTU6NTQ6MzNdIGh2
bS5jOjI0MzU6ZDE1IGd1ZXN0IGF0dGVtcHRlZCB3cml0ZSB0byByZWFkLW9ubHkgbWVtb3J5
IHBhZ2UuIGdmbj0weGRkLCBtZm49MHhhNGEwOQ0KKFhFTikgWzIwMTItMDktMDQgMTU6NTQ6
MzNdIGh2bS5jOjI0MzU6ZDE1IGd1ZXN0IGF0dGVtcHRlZCB3cml0ZSB0byByZWFkLW9ubHkg
bWVtb3J5IHBhZ2UuIGdmbj0weGRjLCBtZm49MHhhNGEwYQ0KKFhFTikgWzIwMTItMDktMDQg
MTU6NTQ6MzNdIGh2bS5jOjI0MzU6ZDE1IGd1ZXN0IGF0dGVtcHRlZCB3cml0ZSB0byByZWFk
LW9ubHkgbWVtb3J5IHBhZ2UuIGdmbj0weGRkLCBtZm49MHhhNGEwOQ0KKFhFTikgWzIwMTIt
MDktMDQgMTU6NTQ6MzNdIGh2bS5jOjI0MzU6ZDE1IGd1ZXN0IGF0dGVtcHRlZCB3cml0ZSB0
byByZWFkLW9ubHkgbWVtb3J5IHBhZ2UuIGdmbj0weGRlLCBtZm49MHhhNGEwOA0KKFhFTikg
WzIwMTItMDktMDQgMTU6NTQ6MzNdIGh2bS5jOjI0MzU6ZDE1IGd1ZXN0IGF0dGVtcHRlZCB3
cml0ZSB0byByZWFkLW9ubHkgbWVtb3J5IHBhZ2UuIGdmbj0weGRkLCBtZm49MHhhNGEwOQ0K
KFhFTikgWzIwMTItMDktMDQgMTU6NTQ6MzNdIGh2bS5jOjI0MzU6ZDE1IGd1ZXN0IGF0dGVt
cHRlZCB3cml0ZSB0byByZWFkLW9ubHkgbWVtb3J5IHBhZ2UuIGdmbj0weGRjLCBtZm49MHhh
NGEwYQ0KKFhFTikgWzIwMTItMDktMDQgMTU6NTQ6MzNdIGh2bS5jOjI0MzU6ZDE1IGd1ZXN0
IGF0dGVtcHRlZCB3cml0ZSB0byByZWFkLW9ubHkgbWVtb3J5IHBhZ2UuIGdmbj0weGRkLCBt
Zm49MHhhNGEwOQ0KKFhFTikgWzIwMTItMDktMDQgMTU6NTQ6MzNdIGh2bS5jOjI0MzU6ZDE1
IGd1ZXN0IGF0dGVtcHRlZCB3cml0ZSB0byByZWFkLW9ubHkgbWVtb3J5IHBhZ2UuIGdmbj0w
eGRjLCBtZm49MHhhNGEwYQ0KKFhFTikgWzIwMTItMDktMDQgMTU6NTQ6MzNdIGh2bS5jOjI0
MzU6ZDE1IGd1ZXN0IGF0dGVtcHRlZCB3cml0ZSB0byByZWFkLW9ubHkgbWVtb3J5IHBhZ2Uu
IGdmbj0weGRkLCBtZm49MHhhNGEwOQ0KKFhFTikgWzIwMTItMDktMDQgMTU6NTQ6MzVdIGh2
bS5jOjI0MzU6ZDE1IGd1ZXN0IGF0dGVtcHRlZCB3cml0ZSB0byByZWFkLW9ubHkgbWVtb3J5
IHBhZ2UuIGdmbj0weGM5LCBtZm49MHhhNGExZA0KKFhFTikgWzIwMTItMDktMDQgMTU6NTQ6
MzVdIGh2bS5jOjI0MzU6ZDE1IGd1ZXN0IGF0dGVtcHRlZCB3cml0ZSB0byByZWFkLW9ubHkg
bWVtb3J5IHBhZ2UuIGdmbj0weGNiLCBtZm49MHhhNGExYg0KKFhFTikgWzIwMTItMDktMDQg
MTU6NTQ6MzVdIGh2bS5jOjI0MzU6ZDE1IGd1ZXN0IGF0dGVtcHRlZCB3cml0ZSB0byByZWFk
LW9ubHkgbWVtb3J5IHBhZ2UuIGdmbj0weGNkLCBtZm49MHhhNGExOQ0KKFhFTikgWzIwMTIt
MDktMDQgMTU6NTQ6MzVdIGh2bS5jOjI0MzU6ZDE1IGd1ZXN0IGF0dGVtcHRlZCB3cml0ZSB0
byByZWFkLW9ubHkgbWVtb3J5IHBhZ2UuIGdmbj0weGNmLCBtZm49MHhhNGExNw0KKFhFTikg
WzIwMTItMDktMDQgMTU6NTQ6MzVdIGh2bS5jOjI0MzU6ZDE1IGd1ZXN0IGF0dGVtcHRlZCB3
cml0ZSB0byByZWFkLW9ubHkgbWVtb3J5IHBhZ2UuIGdmbj0weGQxLCBtZm49MHhhNGExNQ0K
KFhFTikgWzIwMTItMDktMDQgMTU6NTQ6MzVdIGh2bS5jOjI0MzU6ZDE1IGd1ZXN0IGF0dGVt
cHRlZCB3cml0ZSB0byByZWFkLW9ubHkgbWVtb3J5IHBhZ2UuIGdmbj0weGQzLCBtZm49MHhh
NGExMw0KKFhFTikgWzIwMTItMDktMDQgMTU6NTQ6MzVdIGh2bS5jOjI0MzU6ZDE1IGd1ZXN0
IGF0dGVtcHRlZCB3cml0ZSB0byByZWFkLW9ubHkgbWVtb3J5IHBhZ2UuIGdmbj0weGQ1LCBt
Zm49MHhhNGExMQ0KKFhFTikgWzIwMTItMDktMDQgMTU6NTQ6MzVdIGh2bS5jOjI0MzU6ZDE1
IGd1ZXN0IGF0dGVtcHRlZCB3cml0ZSB0byByZWFkLW9ubHkgbWVtb3J5IHBhZ2UuIGdmbj0w
eGQ3LCBtZm49MHhhNGEwZg0KKFhFTikgWzIwMTItMDktMDQgMTU6NTQ6MzVdIGh2bS5jOjI0
MzU6ZDE1IGd1ZXN0IGF0dGVtcHRlZCB3cml0ZSB0byByZWFkLW9ubHkgbWVtb3J5IHBhZ2Uu
IGdmbj0weGQ5LCBtZm49MHhhNGEwZA0KKFhFTikgWzIwMTItMDktMDQgMTU6NTQ6MzVdIGh2
bS5jOjI0MzU6ZDE1IGd1ZXN0IGF0dGVtcHRlZCB3cml0ZSB0byByZWFkLW9ubHkgbWVtb3J5
IHBhZ2UuIGdmbj0weGRiLCBtZm49MHhhNGEwYg0KKFhFTikgWzIwMTItMDktMDQgMTU6NTQ6
MzVdIGh2bS5jOjI0MzU6ZDE1IGd1ZXN0IGF0dGVtcHRlZCB3cml0ZSB0byByZWFkLW9ubHkg
bWVtb3J5IHBhZ2UuIGdmbj0weGRkLCBtZm49MHhhNGEwOQ0KKFhFTikgWzIwMTItMDktMDQg
MTU6NTQ6MzVdIGh2bS5jOjI0MzU6ZDE1IGd1ZXN0IGF0dGVtcHRlZCB3cml0ZSB0byByZWFk
LW9ubHkgbWVtb3J5IHBhZ2UuIGdmbj0weGRmLCBtZm49MHhhNGEwNw0KKFhFTikgWzIwMTIt
MDktMDQgMTU6NTQ6MzVdIGh2bS5jOjI0MzU6ZDE1IGd1ZXN0IGF0dGVtcHRlZCB3cml0ZSB0
byByZWFkLW9ubHkgbWVtb3J5IHBhZ2UuIGdmbj0weGUxLCBtZm49MHhhNGEwNQ0KKFhFTikg
WzIwMTItMDktMDQgMTU6NTQ6MzVdIGh2bS5jOjI0MzU6ZDE1IGd1ZXN0IGF0dGVtcHRlZCB3
cml0ZSB0byByZWFkLW9ubHkgbWVtb3J5IHBhZ2UuIGdmbj0weGUzLCBtZm49MHhhNGEwMw0K
KFhFTikgWzIwMTItMDktMDQgMTU6NTQ6MzVdIGh2bS5jOjI0MzU6ZDE1IGd1ZXN0IGF0dGVt
cHRlZCB3cml0ZSB0byByZWFkLW9ubHkgbWVtb3J5IHBhZ2UuIGdmbj0weGU1LCBtZm49MHhh
NGEwMQ0KKFhFTikgWzIwMTItMDktMDQgMTU6NTQ6MzVdIGh2bS5jOjI0MzU6ZDE1IGd1ZXN0
IGF0dGVtcHRlZCB3cml0ZSB0byByZWFkLW9ubHkgbWVtb3J5IHBhZ2UuIGdmbj0weGU3LCBt
Zm49MHhhNDYzZg0KKFhFTikgWzIwMTItMDktMDQgMTU6NTQ6MzVdIGh2bS5jOjI0MzU6ZDE1
IGd1ZXN0IGF0dGVtcHRlZCB3cml0ZSB0byByZWFkLW9ubHkgbWVtb3J5IHBhZ2UuIGdmbj0w
eGU5LCBtZm49MHhhNDYzZA0KKFhFTikgWzIwMTItMDktMDQgMTU6NTQ6MzVdIGh2bS5jOjI0
MzU6ZDE1IGd1ZXN0IGF0dGVtcHRlZCB3cml0ZSB0byByZWFkLW9ubHkgbWVtb3J5IHBhZ2Uu
IGdmbj0weGViLCBtZm49MHhhNDYzYg0KKFhFTikgWzIwMTItMDktMDQgMTU6NTQ6MzVdIGh2
bS5jOjI0MzU6ZDE1IGd1ZXN0IGF0dGVtcHRlZCB3cml0ZSB0byByZWFkLW9ubHkgbWVtb3J5
IHBhZ2UuIGdmbj0weGVkLCBtZm49MHhhNDYzOQ0KKFhFTikgWzIwMTItMDktMDQgMTU6NTQ6
MzVdIGh2bS5jOjI0MzU6ZDE1IGd1ZXN0IGF0dGVtcHRlZCB3cml0ZSB0byByZWFkLW9ubHkg
bWVtb3J5IHBhZ2UuIGdmbj0weGVmLCBtZm49MHhhNDYzNw0KKFhFTikgWzIwMTItMDktMDQg
MTY6MTM6NTZdIEFNRC1WaTogSU9fUEFHRV9GQVVMVDogZG9tYWluID0gMCwgZGV2aWNlIGlk
ID0gMHgwYTA2LCBmYXVsdCBhZGRyZXNzID0gMHhjMmMyYzJjMA0KKFhFTikgWzIwMTItMDkt
MDQgMTY6MTM6NTZdIEFNRC1WaTogSU9fUEFHRV9GQVVMVDogZG9tYWluID0gMTQsIGRldmlj
ZSBpZCA9IDB4MDcwMCwgZmF1bHQgYWRkcmVzcyA9IDB4YTkwZjgzMDANCihYRU4pIFsyMDEy
LTA5LTA0IDE2OjEzOjU2XSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDE0LCBk
ZXZpY2UgaWQgPSAweDA3MDAsIGZhdWx0IGFkZHJlc3MgPSAweGE5MGY4MzQwDQooWEVOKSBb
MjAxMi0wOS0wNCAxNjoxMzo1Nl0gQU1ELVZpOiBJT19QQUdFX0ZBVUxUOiBkb21haW4gPSAx
NCwgZGV2aWNlIGlkID0gMHgwNzAwLCBmYXVsdCBhZGRyZXNzID0gMHhhOTBmODM4MA0KKFhF
TikgWzIwMTItMDktMDQgMTY6MTM6NTZdIEFNRC1WaTogSU9fUEFHRV9GQVVMVDogZG9tYWlu
ID0gMTQsIGRldmljZSBpZCA9IDB4MDcwMCwgZmF1bHQgYWRkcmVzcyA9IDB4YTkwZjgzYzAN
Cg==
------------0C30E31DB2590EB56
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

------------0C30E31DB2590EB56--



From xen-devel-bounces@lists.xen.org Tue Sep 04 16:44:48 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Sep 2012 16:44:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T8wEn-0005NJ-St; Tue, 04 Sep 2012 16:44:29 +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 1T8wEm-0005N6-3A
	for xen-devel@lists.xen.org; Tue, 04 Sep 2012 16:44:28 +0000
Received: from [85.158.143.35:52476] by server-2.bemta-4.messagelabs.com id
	19/FB-21239-BEF26405; Tue, 04 Sep 2012 16:44:27 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-2.tower-21.messagelabs.com!1346777054!5703510!1
X-Originating-IP: [188.40.164.121]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20215 invoked from network); 4 Sep 2012 16:44:16 -0000
Received: from static.121.164.40.188.clients.your-server.de (HELO
	smtp.eikelenboom.it) (188.40.164.121)
	by server-2.tower-21.messagelabs.com with AES256-SHA encrypted SMTP;
	4 Sep 2012 16:44:16 -0000
Received: from 128-64-ftth.onsneteindhoven.nl ([88.159.64.128]:55637
	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 1T8wB5-0004jo-8A; Tue, 04 Sep 2012 18:40:39 +0200
Date: Tue, 4 Sep 2012 18:43:45 +0200
From: Sander Eikelenboom <linux@eikelenboom.it>
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <1144695277.20120904184345@eikelenboom.it>
To: Wei Wang <wei.wang2@amd.com>
In-Reply-To: <5044CAD7.8030800@amd.com>
References: <40501859.20120902104331@eikelenboom.it>
	<CC6932C2.3D99D%keir.xen@gmail.com>
	<217459398.20120902171441@eikelenboom.it>
	<5044CAD7.8030800@amd.com>
MIME-Version: 1.0
Content-Type: multipart/mixed;
 boundary="----------0C30E31DB2590EB56"
Cc: Keir Fraser <keir.xen@gmail.com>, Jan Beulich <JBeulich@suse.com>,
	Santosh Jodh <Santosh.Jodh@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Using debug-key 'o:  Dump IOMMU p2m table,
	locks up machine
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

------------0C30E31DB2590EB56
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hello Wei,

Monday, September 3, 2012, 5:20:55 PM, you wrote:

> On 09/02/2012 05:14 PM, Sander Eikelenboom wrote:
>> Sunday, September 2, 2012, 4:58:58 PM, you wrote:
>>
>>> On 02/09/2012 09:43, "Sander Eikelenboom"<linux@eikelenboom.it>  wrote:
>>
>>>>> Quite simply, there likely needs to be more tracing on the IOMMU fault path.
>>>>> That's a separate concern from your keyhandler of course, but just saying
>>>>> I'd be looking for the former rather than the latter, for diagnosing
>>>>> Sander's bug.
>>>>
>>>> Are there any printk's I could add to get more relevant info about the AMD-Vi:
>>>> IO_PAGE_FAULT ?
>>
>>> No really straightforward one. I think we need a per-IOMMU-type handler to
>>> walk the IOMMU page table for a given virtual address, and dump every
>>> page-table-entry on the path. Like an IOMMU version of show_page_walk().
>>> Personally I would suspect this is more useful than the dump-everything
>>> handlers: just give a *full* *detailed* walk for the actually interesting
>>> virtual address (the one faulted on).
>>
>>>> I have attached new output from xl dmesg, this time with iommu=debug on (the
>>>> option changed from 4.1 to 4.2).
>>
>>> Not easy to glean any more from that, without extra tracing such as
>>> described above, and/or digging into the guest to find what driver-side
>>> actions are causing the faults.
>>
>> OK, too bad!
>> With xen 4.1 i haven't experienced those page faults, but a diff between /xen/drivers/passthrough/amd in both trees show quite some changes :(

> Did you also update xen tools accordingly? Sometime I also saw a few 
> IO_PAGE_FAULTs came from nic if my tools version and HV version did not 
> match. But using recent 4.2 and corresponding xl, my tests went well.
> BTW: You could also try iommu=no-sharept to see if it helps.

Tried it and it doesn't help.
I now even got a "xl dmesg" which shows a IO_PAGE_FAULT occuring very early, before any toolstack or guest can be involved:

(XEN) [2012-09-04 15:51:17] AMD-Vi: Setup I/O page table: device id = 0x0a05, root table = 0x24d84b000, domain = 0, paging mode = 3
(XEN) [2012-09-04 15:51:17] AMD-Vi: Setup I/O page table: device id = 0x0a06, root table = 0x24d84b000, domain = 0, paging mode = 3
(XEN) [2012-09-04 15:51:17] AMD-Vi: Setup I/O page table: device id = 0x0a07, root table = 0x24d84b000, domain = 0, paging mode = 3
(XEN) [2012-09-04 15:51:17] AMD-Vi: Setup I/O page table: device id = 0x0b00, root table = 0x24d84b000, domain = 0, paging mode = 3
(XEN) [2012-09-04 15:51:17] Scrubbing Free RAM: ...........................<0>AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0a06, fault address = 0xc2c2c2c0
(XEN) [2012-09-04 15:51:18] ............................................done.
(XEN) [2012-09-04 15:51:19] Initial low memory virq threshold set at 0x4000 pages.
(XEN) [2012-09-04 15:51:19] Std. Loglevel: All
(XEN) [2012-09-04 15:51:19] Guest Loglevel: All
(XEN) [2012-09-04 15:51:19] Xen is relinquishing VGA console.


Complete dmesg attached.

> Thanks,
> Wei

>>>   -- Keir
>>
>>>>
>>>>
>>>>>   -- Keir
>>>>
>>
>>
>>
>>
>>
>>






-- 
Best regards,
 Sander                            mailto:linux@eikelenboom.it
------------0C30E31DB2590EB56
Content-Type: text/plain;
 name="xl-dmesg.txt"
Content-transfer-encoding: base64
Content-Disposition: attachment;
 filename="xl-dmesg.txt"

IF9fICBfXyAgICAgICAgICAgIF8gIF8gICAgX19fXyAgICBfX18gICAgICAgICAgICAgIF8g
IF8gICAgICAgICAgICAgICAgICAgICANCiBcIFwvIC9fX18gXyBfXyAgIHwgfHwgfCAgfF9f
XyBcICAvIF8gXCAgICBfIF9fIF9fX3wgfHwgfCAgICAgXyBfXyAgXyBfXyBfX18gDQogIFwg
IC8vIF8gXCAnXyBcICB8IHx8IHxfICAgX18pIHx8IHwgfCB8X198ICdfXy8gX198IHx8IHxf
IF9ffCAnXyBcfCAnX18vIF8gXA0KICAvICBcICBfXy8gfCB8IHwgfF9fICAgX3wgLyBfXy8g
fCB8X3wgfF9ffCB8IHwgKF9ffF9fICAgX3xfX3wgfF8pIHwgfCB8ICBfXy8NCiAvXy9cX1xf
X198X3wgfF98ICAgIHxffChfKV9fX19fKF8pX19fLyAgIHxffCAgXF9fX3wgIHxffCAgICB8
IC5fXy98X3wgIFxfX198DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgfF98ICAgICAgICAgICAgIA0KKFhFTikgWGVuIHZl
cnNpb24gNC4yLjAtcmM0LXByZSAocm9vdEBkeW5kbnMub3JnKSAoZ2NjIChEZWJpYW4gNC40
LjUtOCkgNC40LjUpIE1vbiBTZXAgIDMgMjI6MzY6MzAgQ0VTVCAyMDEyDQooWEVOKSBMYXRl
c3QgQ2hhbmdlU2V0OiBUdWUgQXVnIDI4IDIyOjQwOjQ1IDIwMTIgKzAxMDAgMjU3ODY6YTBi
NWY4MTAyYTAwDQooWEVOKSBCb290bG9hZGVyOiBHUlVCIDEuOTgrMjAxMDA4MDQtMTQrc3F1
ZWV6ZTENCihYRU4pIENvbW1hbmQgbGluZTogZG9tMF9tZW09MTAyNE0sbWF4OjEwMjRNIGxv
Z2x2bD1hbGwgbG9nbHZsX2d1ZXN0PWFsbCBjb25zb2xlX3RpbWVzdGFtcHMgdmdhPWdmeC0x
MjgweDEwMjR4MzIgY3B1aWRsZSBjcHVmcmVxPXhlbiBub3JlYm9vdCBkZWJ1ZyBsYXBpYz1k
ZWJ1ZyBhcGljX3ZlcmJvc2l0eT1kZWJ1ZyBhcGljPWRlYnVnIGlvbW11PW9uLHZlcmJvc2Us
ZGVidWcsbm8tc2hhcmVwdCBjb20xPTM4NDAwLDhuMSBjb25zb2xlPXZnYSxjb20xDQooWEVO
KSBWaWRlbyBpbmZvcm1hdGlvbjoNCihYRU4pICBWR0EgaXMgZ3JhcGhpY3MgbW9kZSAxMjgw
eDEwMjQsIDMyIGJwcA0KKFhFTikgIFZCRS9EREMgbWV0aG9kczogVjI7IEVESUQgdHJhbnNm
ZXIgdGltZTogMSBzZWNvbmRzDQooWEVOKSBEaXNjIGluZm9ybWF0aW9uOg0KKFhFTikgIEZv
dW5kIDIgTUJSIHNpZ25hdHVyZXMNCihYRU4pICBGb3VuZCAyIEVERCBpbmZvcm1hdGlvbiBz
dHJ1Y3R1cmVzDQooWEVOKSBYZW4tZTgyMCBSQU0gbWFwOg0KKFhFTikgIDAwMDAwMDAwMDAw
MDAwMDAgLSAwMDAwMDAwMDAwMDliMDAwICh1c2FibGUpDQooWEVOKSAgMDAwMDAwMDAwMDA5
YjAwMCAtIDAwMDAwMDAwMDAwYTAwMDAgKHJlc2VydmVkKQ0KKFhFTikgIDAwMDAwMDAwMDAw
ZTQwMDAgLSAwMDAwMDAwMDAwMTAwMDAwIChyZXNlcnZlZCkNCihYRU4pICAwMDAwMDAwMDAw
MTAwMDAwIC0gMDAwMDAwMDBhZmU5MDAwMCAodXNhYmxlKQ0KKFhFTikgIDAwMDAwMDAwYWZl
OTAwMDAgLSAwMDAwMDAwMGFmZTllMDAwIChBQ1BJIGRhdGEpDQooWEVOKSAgMDAwMDAwMDBh
ZmU5ZTAwMCAtIDAwMDAwMDAwYWZlZTAwMDAgKEFDUEkgTlZTKQ0KKFhFTikgIDAwMDAwMDAw
YWZlZTAwMDAgLSAwMDAwMDAwMGFmZjAwMDAwIChyZXNlcnZlZCkNCihYRU4pICAwMDAwMDAw
MGZmZTAwMDAwIC0gMDAwMDAwMDEwMDAwMDAwMCAocmVzZXJ2ZWQpDQooWEVOKSAgMDAwMDAw
MDEwMDAwMDAwMCAtIDAwMDAwMDAyNTAwMDAwMDAgKHVzYWJsZSkNCihYRU4pIEFDUEk6IFJT
RFAgMDAwRkIxMjAsIDAwMTQgKHIwIEFDUElBTSkNCihYRU4pIEFDUEk6IFJTRFQgQUZFOTAw
MDAsIDAwNDggKHIxIE1TSSAgICBPRU1TTElDICAyMDEwMDYyMiBNU0ZUICAgICAgIDk3KQ0K
KFhFTikgQUNQSTogRkFDUCBBRkU5MDIwMCwgMDA4NCAocjEgNzY0ME1TIEE3NjQwMTAwIDIw
MTAwNjIyIE1TRlQgICAgICAgOTcpDQooWEVOKSBBQ1BJOiBEU0RUIEFGRTkwNUUwLCA5NDQ5
IChyMSAgQTc2NDAgQTc2NDAxMDAgICAgICAxMDAgSU5UTCAyMDA1MTExNykNCihYRU4pIEFD
UEk6IEZBQ1MgQUZFOUUwMDAsIDAwNDANCihYRU4pIEFDUEk6IEFQSUMgQUZFOTAzOTAsIDAw
ODggKHIxIDc2NDBNUyBBNzY0MDEwMCAyMDEwMDYyMiBNU0ZUICAgICAgIDk3KQ0KKFhFTikg
QUNQSTogTUNGRyBBRkU5MDQyMCwgMDAzQyAocjEgNzY0ME1TIE9FTU1DRkcgIDIwMTAwNjIy
IE1TRlQgICAgICAgOTcpDQooWEVOKSBBQ1BJOiBTTElDIEFGRTkwNDYwLCAwMTc2IChyMSBN
U0kgICAgT0VNU0xJQyAgMjAxMDA2MjIgTVNGVCAgICAgICA5NykNCihYRU4pIEFDUEk6IE9F
TUIgQUZFOUUwNDAsIDAwNzIgKHIxIDc2NDBNUyBBNzY0MDEwMCAyMDEwMDYyMiBNU0ZUICAg
ICAgIDk3KQ0KKFhFTikgQUNQSTogU1JBVCBBRkU5QTVFMCwgMDEwOCAocjMgQU1EICAgIEZB
TV9GXzEwICAgICAgICAyIEFNRCAgICAgICAgIDEpDQooWEVOKSBBQ1BJOiBIUEVUIEFGRTlB
NkYwLCAwMDM4IChyMSA3NjQwTVMgT0VNSFBFVCAgMjAxMDA2MjIgTVNGVCAgICAgICA5NykN
CihYRU4pIEFDUEk6IElWUlMgQUZFOUE3MzAsIDAwRjggKHIxICBBTUQgICAgIFJEODkwUyAg
IDIwMjAzMSBBTUQgICAgICAgICAwKQ0KKFhFTikgQUNQSTogU1NEVCBBRkU5QTgzMCwgMERB
NCAocjEgQSBNIEkgIFBPV0VSTk9XICAgICAgICAxIEFNRCAgICAgICAgIDEpDQooWEVOKSBT
eXN0ZW0gUkFNOiA4MTkwTUIgKDgzODY3MzJrQikNCihYRU4pIFNSQVQ6IFBYTSAwIC0+IEFQ
SUMgMCAtPiBOb2RlIDANCihYRU4pIFNSQVQ6IFBYTSAwIC0+IEFQSUMgMSAtPiBOb2RlIDAN
CihYRU4pIFNSQVQ6IFBYTSAwIC0+IEFQSUMgMiAtPiBOb2RlIDANCihYRU4pIFNSQVQ6IFBY
TSAwIC0+IEFQSUMgMyAtPiBOb2RlIDANCihYRU4pIFNSQVQ6IFBYTSAwIC0+IEFQSUMgNCAt
PiBOb2RlIDANCihYRU4pIFNSQVQ6IFBYTSAwIC0+IEFQSUMgNSAtPiBOb2RlIDANCihYRU4p
IFNSQVQ6IE5vZGUgMCBQWE0gMCAwLWEwMDAwDQooWEVOKSBTUkFUOiBOb2RlIDAgUFhNIDAg
MTAwMDAwLWIwMDAwMDAwDQooWEVOKSBTUkFUOiBOb2RlIDAgUFhNIDAgMTAwMDAwMDAwLTI1
MDAwMDAwMA0KKFhFTikgTlVNQTogQWxsb2NhdGVkIG1lbW5vZGVtYXAgZnJvbSAyNGQ5YTQw
MDAgLSAyNGQ5YTcwMDANCihYRU4pIE5VTUE6IFVzaW5nIDggZm9yIHRoZSBoYXNoIHNoaWZ0
Lg0KKFhFTikgRG9tYWluIGhlYXAgaW5pdGlhbGlzZWQNCihYRU4pIHZlc2FmYjogZnJhbWVi
dWZmZXIgYXQgMHhmYjAwMDAwMCwgbWFwcGVkIHRvIDB4ZmZmZjgyYzAwMDAwMDAwMCwgdXNp
bmcgNjE0NGssIHRvdGFsIDE0MzM2aw0KKFhFTikgdmVzYWZiOiBtb2RlIGlzIDEyODB4MTAy
NHgzMiwgbGluZWxlbmd0aD01MTIwLCBmb250IDh4MTYNCihYRU4pIHZlc2FmYjogVHJ1ZWNv
bG9yOiBzaXplPTg6ODo4OjgsIHNoaWZ0PTI0OjE2Ojg6MA0KKFhFTikgZm91bmQgU01QIE1Q
LXRhYmxlIGF0IDAwMGZmNzgwDQooWEVOKSBETUkgcHJlc2VudC4NCihYRU4pIEFQSUMgYm9v
dCBzdGF0ZSBpcyAneGFwaWMnDQooWEVOKSBVc2luZyBBUElDIGRyaXZlciBkZWZhdWx0DQoo
WEVOKSBBQ1BJOiBQTS1UaW1lciBJTyBQb3J0OiAweDgwOA0KKFhFTikgQUNQSTogQUNQSSBT
TEVFUCBJTkZPOiBwbTF4X2NudFs4MDQsMF0sIHBtMXhfZXZ0WzgwMCwwXQ0KKFhFTikgQUNQ
STogICAgICAgICAgICAgICAgICB3YWtldXBfdmVjW2FmZTllMDBjXSwgdmVjX3NpemVbMjBd
DQooWEVOKSBBQ1BJOiBMb2NhbCBBUElDIGFkZHJlc3MgMHhmZWUwMDAwMA0KKFhFTikgQUNQ
STogTEFQSUMgKGFjcGlfaWRbMHgwMV0gbGFwaWNfaWRbMHgwMF0gZW5hYmxlZCkNCihYRU4p
IFByb2Nlc3NvciAjMCAwOjEwIEFQSUMgdmVyc2lvbiAxNg0KKFhFTikgQUNQSTogTEFQSUMg
KGFjcGlfaWRbMHgwMl0gbGFwaWNfaWRbMHgwMV0gZW5hYmxlZCkNCihYRU4pIFByb2Nlc3Nv
ciAjMSAwOjEwIEFQSUMgdmVyc2lvbiAxNg0KKFhFTikgQUNQSTogTEFQSUMgKGFjcGlfaWRb
MHgwM10gbGFwaWNfaWRbMHgwMl0gZW5hYmxlZCkNCihYRU4pIFByb2Nlc3NvciAjMiAwOjEw
IEFQSUMgdmVyc2lvbiAxNg0KKFhFTikgQUNQSTogTEFQSUMgKGFjcGlfaWRbMHgwNF0gbGFw
aWNfaWRbMHgwM10gZW5hYmxlZCkNCihYRU4pIFByb2Nlc3NvciAjMyAwOjEwIEFQSUMgdmVy
c2lvbiAxNg0KKFhFTikgQUNQSTogTEFQSUMgKGFjcGlfaWRbMHgwNV0gbGFwaWNfaWRbMHgw
NF0gZW5hYmxlZCkNCihYRU4pIFByb2Nlc3NvciAjNCAwOjEwIEFQSUMgdmVyc2lvbiAxNg0K
KFhFTikgQUNQSTogTEFQSUMgKGFjcGlfaWRbMHgwNl0gbGFwaWNfaWRbMHgwNV0gZW5hYmxl
ZCkNCihYRU4pIFByb2Nlc3NvciAjNSAwOjEwIEFQSUMgdmVyc2lvbiAxNg0KKFhFTikgQUNQ
STogSU9BUElDIChpZFsweDA2XSBhZGRyZXNzWzB4ZmVjMDAwMDBdIGdzaV9iYXNlWzBdKQ0K
KFhFTikgSU9BUElDWzBdOiBhcGljX2lkIDYsIHZlcnNpb24gMzMsIGFkZHJlc3MgMHhmZWMw
MDAwMCwgR1NJIDAtMjMNCihYRU4pIEFDUEk6IElPQVBJQyAoaWRbMHgwN10gYWRkcmVzc1sw
eGZlYzIwMDAwXSBnc2lfYmFzZVsyNF0pDQooWEVOKSBJT0FQSUNbMV06IGFwaWNfaWQgNywg
dmVyc2lvbiAzMywgYWRkcmVzcyAweGZlYzIwMDAwLCBHU0kgMjQtNTUNCihYRU4pIEFDUEk6
IElOVF9TUkNfT1ZSIChidXMgMCBidXNfaXJxIDAgZ2xvYmFsX2lycSAyIGRmbCBkZmwpDQoo
WEVOKSBBQ1BJOiBJTlRfU1JDX09WUiAoYnVzIDAgYnVzX2lycSA5IGdsb2JhbF9pcnEgOSBs
b3cgbGV2ZWwpDQooWEVOKSBBQ1BJOiBJUlEwIHVzZWQgYnkgb3ZlcnJpZGUuDQooWEVOKSBB
Q1BJOiBJUlEyIHVzZWQgYnkgb3ZlcnJpZGUuDQooWEVOKSBBQ1BJOiBJUlE5IHVzZWQgYnkg
b3ZlcnJpZGUuDQooWEVOKSBFbmFibGluZyBBUElDIG1vZGU6ICBGbGF0LiAgVXNpbmcgMiBJ
L08gQVBJQ3MNCihYRU4pIEFDUEk6IEhQRVQgaWQ6IDB4ODMwMCBiYXNlOiAweGZlZDAwMDAw
DQooWEVOKSBUYWJsZSBpcyBub3QgZm91bmQhDQooWEVOKSBVc2luZyBBQ1BJIChNQURUKSBm
b3IgU01QIGNvbmZpZ3VyYXRpb24gaW5mb3JtYXRpb24NCihYRU4pIFNNUDogQWxsb3dpbmcg
NiBDUFVzICgwIGhvdHBsdWcgQ1BVcykNCihYRU4pIG1hcHBlZCBBUElDIHRvIGZmZmY4MmMz
ZmZkZmUwMDAgKGZlZTAwMDAwKQ0KKFhFTikgbWFwcGVkIElPQVBJQyB0byBmZmZmODJjM2Zm
ZGZkMDAwIChmZWMwMDAwMCkNCihYRU4pIG1hcHBlZCBJT0FQSUMgdG8gZmZmZjgyYzNmZmRm
YzAwMCAoZmVjMjAwMDApDQooWEVOKSBJUlEgbGltaXRzOiA1NiBHU0ksIDExMTIgTVNJL01T
SS1YDQooWEVOKSBVc2luZyBzY2hlZHVsZXI6IFNNUCBDcmVkaXQgU2NoZWR1bGVyIChjcmVk
aXQpDQooWEVOKSBEZXRlY3RlZCAzMjAwLjE0OCBNSHogcHJvY2Vzc29yLg0KKFhFTikgSW5p
dGluZyBtZW1vcnkgc2hhcmluZy4NCihYRU4pIEFNRCBGYW0xMGggbWFjaGluZSBjaGVjayBy
ZXBvcnRpbmcgZW5hYmxlZA0KKFhFTikgUENJOiBNQ0ZHIGNvbmZpZ3VyYXRpb24gMDogYmFz
ZSBlMDAwMDAwMCBzZWdtZW50IDAwMDAgYnVzZXMgMDAgLSBmZg0KKFhFTikgUENJOiBOb3Qg
dXNpbmcgTUNGRyBmb3Igc2VnbWVudCAwMDAwIGJ1cyAwMC1mZg0KKFhFTikgQU1ELVZpOiBG
b3VuZCBNU0kgY2FwYWJpbGl0eSBibG9jayBhdCAweDU0DQooWEVOKSBBTUQtVmk6IEFDUEkg
VGFibGU6DQooWEVOKSBBTUQtVmk6ICBTaWduYXR1cmUgSVZSUw0KKFhFTikgQU1ELVZpOiAg
TGVuZ3RoIDB4ZjgNCihYRU4pIEFNRC1WaTogIFJldmlzaW9uIDB4MQ0KKFhFTikgQU1ELVZp
OiAgQ2hlY2tTdW0gMHg2ZQ0KKFhFTikgQU1ELVZpOiAgT0VNX0lkIEFNRCAgDQooWEVOKSBB
TUQtVmk6ICBPRU1fVGFibGVfSWQgUkQ4OTBTDQooWEVOKSBBTUQtVmk6ICBPRU1fUmV2aXNp
b24gMHgyMDIwMzENCihYRU4pIEFNRC1WaTogIENyZWF0b3JfSWQgQU1EIA0KKFhFTikgQU1E
LVZpOiAgQ3JlYXRvcl9SZXZpc2lvbiAweDANCihYRU4pIEFNRC1WaTogSVZSUyBCbG9jazoN
CihYRU4pIEFNRC1WaTogIFR5cGUgMHgxMA0KKFhFTikgQU1ELVZpOiAgRmxhZ3MgMHgzZQ0K
KFhFTikgQU1ELVZpOiAgTGVuZ3RoIDB4YzgNCihYRU4pIEFNRC1WaTogIERldl9JZCAweDIN
CihYRU4pIEFNRC1WaTogSVZIRCBEZXZpY2UgRW50cnk6DQooWEVOKSBBTUQtVmk6ICBUeXBl
IDB4Mw0KKFhFTikgQU1ELVZpOiAgRGV2X0lkIDB4MA0KKFhFTikgQU1ELVZpOiAgRmxhZ3Mg
MHgwDQooWEVOKSBBTUQtVmk6ICBEZXZfSWQgUmFuZ2U6IDB4MCAtPiAweDINCihYRU4pIEFN
RC1WaTogSVZIRCBEZXZpY2UgRW50cnk6DQooWEVOKSBBTUQtVmk6ICBUeXBlIDB4Mg0KKFhF
TikgQU1ELVZpOiAgRGV2X0lkIDB4MTANCihYRU4pIEFNRC1WaTogIEZsYWdzIDB4MA0KKFhF
TikgQU1ELVZpOiBJVkhEIERldmljZSBFbnRyeToNCihYRU4pIEFNRC1WaTogIFR5cGUgMHgy
DQooWEVOKSBBTUQtVmk6ICBEZXZfSWQgMHhiMDANCihYRU4pIEFNRC1WaTogIEZsYWdzIDB4
MA0KKFhFTikgQU1ELVZpOiBJVkhEIERldmljZSBFbnRyeToNCihYRU4pIEFNRC1WaTogIFR5
cGUgMHgyDQooWEVOKSBBTUQtVmk6ICBEZXZfSWQgMHgxOA0KKFhFTikgQU1ELVZpOiAgRmxh
Z3MgMHgwDQooWEVOKSBBTUQtVmk6IElWSEQgRGV2aWNlIEVudHJ5Og0KKFhFTikgQU1ELVZp
OiAgVHlwZSAweDMNCihYRU4pIEFNRC1WaTogIERldl9JZCAweGEwMA0KKFhFTikgQU1ELVZp
OiAgRmxhZ3MgMHgwDQooWEVOKSBBTUQtVmk6ICBEZXZfSWQgUmFuZ2U6IDB4YTAwIC0+IDB4
YTA3DQooWEVOKSBBTUQtVmk6IElWSEQgRGV2aWNlIEVudHJ5Og0KKFhFTikgQU1ELVZpOiAg
VHlwZSAweDINCihYRU4pIEFNRC1WaTogIERldl9JZCAweDI4DQooWEVOKSBBTUQtVmk6ICBG
bGFncyAweDANCihYRU4pIEFNRC1WaTogSVZIRCBEZXZpY2UgRW50cnk6DQooWEVOKSBBTUQt
Vmk6ICBUeXBlIDB4Mg0KKFhFTikgQU1ELVZpOiAgRGV2X0lkIDB4OTAwDQooWEVOKSBBTUQt
Vmk6ICBGbGFncyAweDANCihYRU4pIEFNRC1WaTogSVZIRCBEZXZpY2UgRW50cnk6DQooWEVO
KSBBTUQtVmk6ICBUeXBlIDB4Mg0KKFhFTikgQU1ELVZpOiAgRGV2X0lkIDB4MzANCihYRU4p
IEFNRC1WaTogIEZsYWdzIDB4MA0KKFhFTikgQU1ELVZpOiBJVkhEIERldmljZSBFbnRyeToN
CihYRU4pIEFNRC1WaTogIFR5cGUgMHgyDQooWEVOKSBBTUQtVmk6ICBEZXZfSWQgMHg4MDAN
CihYRU4pIEFNRC1WaTogIEZsYWdzIDB4MA0KKFhFTikgQU1ELVZpOiBJVkhEIERldmljZSBF
bnRyeToNCihYRU4pIEFNRC1WaTogIFR5cGUgMHgyDQooWEVOKSBBTUQtVmk6ICBEZXZfSWQg
MHg1MA0KKFhFTikgQU1ELVZpOiAgRmxhZ3MgMHgwDQooWEVOKSBBTUQtVmk6IElWSEQgRGV2
aWNlIEVudHJ5Og0KKFhFTikgQU1ELVZpOiAgVHlwZSAweDINCihYRU4pIEFNRC1WaTogIERl
dl9JZCAweDcwMA0KKFhFTikgQU1ELVZpOiAgRmxhZ3MgMHgwDQooWEVOKSBBTUQtVmk6IElW
SEQgRGV2aWNlIEVudHJ5Og0KKFhFTikgQU1ELVZpOiAgVHlwZSAweDINCihYRU4pIEFNRC1W
aTogIERldl9JZCAweDU4DQooWEVOKSBBTUQtVmk6ICBGbGFncyAweDANCihYRU4pIEFNRC1W
aTogSVZIRCBEZXZpY2UgRW50cnk6DQooWEVOKSBBTUQtVmk6ICBUeXBlIDB4Mw0KKFhFTikg
QU1ELVZpOiAgRGV2X0lkIDB4NjAwDQooWEVOKSBBTUQtVmk6ICBGbGFncyAweDANCihYRU4p
IEFNRC1WaTogIERldl9JZCBSYW5nZTogMHg2MDAgLT4gMHg2MDENCihYRU4pIEFNRC1WaTog
SVZIRCBEZXZpY2UgRW50cnk6DQooWEVOKSBBTUQtVmk6ICBUeXBlIDB4Mg0KKFhFTikgQU1E
LVZpOiAgRGV2X0lkIDB4NjANCihYRU4pIEFNRC1WaTogIEZsYWdzIDB4MA0KKFhFTikgQU1E
LVZpOiBJVkhEIERldmljZSBFbnRyeToNCihYRU4pIEFNRC1WaTogIFR5cGUgMHgyDQooWEVO
KSBBTUQtVmk6ICBEZXZfSWQgMHg1MDANCihYRU4pIEFNRC1WaTogIEZsYWdzIDB4MA0KKFhF
TikgQU1ELVZpOiBJVkhEIERldmljZSBFbnRyeToNCihYRU4pIEFNRC1WaTogIFR5cGUgMHgy
DQooWEVOKSBBTUQtVmk6ICBEZXZfSWQgMHg2OA0KKFhFTikgQU1ELVZpOiAgRmxhZ3MgMHgw
DQooWEVOKSBBTUQtVmk6IElWSEQgRGV2aWNlIEVudHJ5Og0KKFhFTikgQU1ELVZpOiAgVHlw
ZSAweDMNCihYRU4pIEFNRC1WaTogIERldl9JZCAweDQwMA0KKFhFTikgQU1ELVZpOiAgRmxh
Z3MgMHgwDQooWEVOKSBBTUQtVmk6ICBEZXZfSWQgUmFuZ2U6IDB4NDAwIC0+IDB4NDA3DQoo
WEVOKSBBTUQtVmk6IElWSEQgRGV2aWNlIEVudHJ5Og0KKFhFTikgQU1ELVZpOiAgVHlwZSAw
eDINCihYRU4pIEFNRC1WaTogIERldl9JZCAweDg4DQooWEVOKSBBTUQtVmk6ICBGbGFncyAw
eDANCihYRU4pIEFNRC1WaTogSVZIRCBEZXZpY2UgRW50cnk6DQooWEVOKSBBTUQtVmk6ICBU
eXBlIDB4Mw0KKFhFTikgQU1ELVZpOiAgRGV2X0lkIDB4OTANCihYRU4pIEFNRC1WaTogIEZs
YWdzIDB4MA0KKFhFTikgQU1ELVZpOiAgRGV2X0lkIFJhbmdlOiAweDkwIC0+IDB4OTINCihY
RU4pIEFNRC1WaTogSVZIRCBEZXZpY2UgRW50cnk6DQooWEVOKSBBTUQtVmk6ICBUeXBlIDB4
Mw0KKFhFTikgQU1ELVZpOiAgRGV2X0lkIDB4OTgNCihYRU4pIEFNRC1WaTogIEZsYWdzIDB4
MA0KKFhFTikgQU1ELVZpOiAgRGV2X0lkIFJhbmdlOiAweDk4IC0+IDB4OWENCihYRU4pIEFN
RC1WaTogSVZIRCBEZXZpY2UgRW50cnk6DQooWEVOKSBBTUQtVmk6ICBUeXBlIDB4Mg0KKFhF
TikgQU1ELVZpOiAgRGV2X0lkIDB4YTANCihYRU4pIEFNRC1WaTogIEZsYWdzIDB4ZDcNCihY
RU4pIEFNRC1WaTogSVZIRCBEZXZpY2UgRW50cnk6DQooWEVOKSBBTUQtVmk6ICBUeXBlIDB4
Mg0KKFhFTikgQU1ELVZpOiAgRGV2X0lkIDB4YTMNCihYRU4pIEFNRC1WaTogIEZsYWdzIDB4
MA0KKFhFTikgQU1ELVZpOiBJVkhEIERldmljZSBFbnRyeToNCihYRU4pIEFNRC1WaTogIFR5
cGUgMHgyDQooWEVOKSBBTUQtVmk6ICBEZXZfSWQgMHhhNA0KKFhFTikgQU1ELVZpOiAgRmxh
Z3MgMHgwDQooWEVOKSBBTUQtVmk6IElWSEQgRGV2aWNlIEVudHJ5Og0KKFhFTikgQU1ELVZp
OiAgVHlwZSAweDANCihYRU4pIEFNRC1WaTogIERldl9JZCAweDANCihYRU4pIEFNRC1WaTog
IEZsYWdzIDB4MA0KKFhFTikgQU1ELVZpOiBJVkhEIERldmljZSBFbnRyeToNCihYRU4pIEFN
RC1WaTogIFR5cGUgMHg0Mw0KKFhFTikgQU1ELVZpOiAgRGV2X0lkIDB4MzAwDQooWEVOKSBB
TUQtVmk6ICBGbGFncyAweDANCihYRU4pIEFNRC1WaTogIERldl9JZCBSYW5nZTogMHgzMDAg
LT4gMHgzZmYNCihYRU4pIEFNRC1WaTogIERldl9JZCBBbGlhczogMHhhNA0KKFhFTikgQU1E
LVZpOiBJVkhEIERldmljZSBFbnRyeToNCihYRU4pIEFNRC1WaTogIFR5cGUgMHgyDQooWEVO
KSBBTUQtVmk6ICBEZXZfSWQgMHhhNQ0KKFhFTikgQU1ELVZpOiAgRmxhZ3MgMHgwDQooWEVO
KSBBTUQtVmk6IElWSEQgRGV2aWNlIEVudHJ5Og0KKFhFTikgQU1ELVZpOiAgVHlwZSAweDIN
CihYRU4pIEFNRC1WaTogIERldl9JZCAweGE4DQooWEVOKSBBTUQtVmk6ICBGbGFncyAweDAN
CihYRU4pIEFNRC1WaTogSVZIRCBEZXZpY2UgRW50cnk6DQooWEVOKSBBTUQtVmk6ICBUeXBl
IDB4Mg0KKFhFTikgQU1ELVZpOiAgRGV2X0lkIDB4YTkNCihYRU4pIEFNRC1WaTogIEZsYWdz
IDB4MA0KKFhFTikgQU1ELVZpOiBJVkhEIERldmljZSBFbnRyeToNCihYRU4pIEFNRC1WaTog
IFR5cGUgMHgyDQooWEVOKSBBTUQtVmk6ICBEZXZfSWQgMHgxMDANCihYRU4pIEFNRC1WaTog
IEZsYWdzIDB4MA0KKFhFTikgQU1ELVZpOiBJVkhEIERldmljZSBFbnRyeToNCihYRU4pIEFN
RC1WaTogIFR5cGUgMHgzDQooWEVOKSBBTUQtVmk6ICBEZXZfSWQgMHhiMA0KKFhFTikgQU1E
LVZpOiAgRmxhZ3MgMHgwDQooWEVOKSBBTUQtVmk6ICBEZXZfSWQgUmFuZ2U6IDB4YjAgLT4g
MHhiMg0KKFhFTikgQU1ELVZpOiBJVkhEIERldmljZSBFbnRyeToNCihYRU4pIEFNRC1WaTog
IFR5cGUgMHgwDQooWEVOKSBBTUQtVmk6ICBEZXZfSWQgMHgwDQooWEVOKSBBTUQtVmk6ICBG
bGFncyAweDANCihYRU4pIEFNRC1WaTogSVZIRCBEZXZpY2UgRW50cnk6DQooWEVOKSBBTUQt
Vmk6ICBUeXBlIDB4NDgNCihYRU4pIEFNRC1WaTogIERldl9JZCAweDANCihYRU4pIEFNRC1W
aTogIEZsYWdzIDB4ZDcNCihYRU4pIEFNRC1WaTogSVZIRCBEZXZpY2UgRW50cnk6DQooWEVO
KSBBTUQtVmk6ICBUeXBlIDB4NDgNCihYRU4pIEFNRC1WaTogIERldl9JZCAweDANCihYRU4p
IEFNRC1WaTogIEZsYWdzIDB4MA0KKFhFTikgQU1ELVZpOiBJT01NVSAwIEVuYWJsZWQuDQoo
WEVOKSBBTUQtVmk6IEVuYWJsaW5nIGdsb2JhbCB2ZWN0b3IgbWFwDQooWEVOKSBJL08gdmly
dHVhbGlzYXRpb24gZW5hYmxlZA0KKFhFTikgIC0gRG9tMCBtb2RlOiBSZWxheGVkDQooWEVO
KSBHZXR0aW5nIFZFUlNJT046IDgwMDUwMDEwDQooWEVOKSBHZXR0aW5nIFZFUlNJT046IDgw
MDUwMDEwDQooWEVOKSBHZXR0aW5nIElEOiAwDQooWEVOKSBHZXR0aW5nIExWVDA6IDcwMA0K
KFhFTikgR2V0dGluZyBMVlQxOiA0MDANCihYRU4pIGVuYWJsZWQgRXh0SU5UIG9uIENQVSMw
DQooWEVOKSBFU1IgdmFsdWUgYmVmb3JlIGVuYWJsaW5nIHZlY3RvcjogMHgwMDAwMDAwNCAg
YWZ0ZXI6IDB4MDAwMDAwMDANCihYRU4pIEVOQUJMSU5HIElPLUFQSUMgSVJRcw0KKFhFTikg
IC0+IFVzaW5nIG5ldyBBQ0sgbWV0aG9kDQooWEVOKSBpbml0IElPX0FQSUMgSVJRcw0KKFhF
TikgIElPLUFQSUMgKGFwaWNpZC1waW4pIDYtMCwgNi0xNiwgNi0xNywgNi0xOCwgNi0xOSwg
Ni0yMCwgNi0yMSwgNi0yMiwgNi0yMywgNy0wLCA3LTEsIDctMiwgNy0zLCA3LTQsIDctNSwg
Ny02LCA3LTcsIDctOCwgNy05LCA3LTEwLCA3LTExLCA3LTEyLCA3LTEzLCA3LTE0LCA3LTE1
LCA3LTE2LCA3LTE3LCA3LTE4LCA3LTE5LCA3LTIwLCA3LTIxLCA3LTIyLCA3LTIzLCA3LTI0
LCA3LTI1LCA3LTI2LCA3LTI3LCA3LTI4LCA3LTI5LCA3LTMwLCA3LTMxIG5vdCBjb25uZWN0
ZWQuDQooWEVOKSAuLlRJTUVSOiB2ZWN0b3I9MHhGMCBhcGljMT0wIHBpbjE9MiBhcGljMj0t
MSBwaW4yPS0xDQooWEVOKSBudW1iZXIgb2YgTVAgSVJRIHNvdXJjZXM6IDE1Lg0KKFhFTikg
bnVtYmVyIG9mIElPLUFQSUMgIzYgcmVnaXN0ZXJzOiAyNC4NCihYRU4pIG51bWJlciBvZiBJ
Ty1BUElDICM3IHJlZ2lzdGVyczogMzIuDQooWEVOKSB0ZXN0aW5nIHRoZSBJTyBBUElDLi4u
Li4uLi4uLi4uLi4uLi4uLi4uLi4NCihYRU4pIElPIEFQSUMgIzYuLi4uLi4NCihYRU4pIC4u
Li4gcmVnaXN0ZXIgIzAwOiAwNjAwMDAwMA0KKFhFTikgLi4uLi4uLiAgICA6IHBoeXNpY2Fs
IEFQSUMgaWQ6IDA2DQooWEVOKSAuLi4uLi4uICAgIDogRGVsaXZlcnkgVHlwZTogMA0KKFhF
TikgLi4uLi4uLiAgICA6IExUUyAgICAgICAgICA6IDANCihYRU4pIC4uLi4gcmVnaXN0ZXIg
IzAxOiAwMDE3ODAyMQ0KKFhFTikgLi4uLi4uLiAgICAgOiBtYXggcmVkaXJlY3Rpb24gZW50
cmllczogMDAxNw0KKFhFTikgLi4uLi4uLiAgICAgOiBQUlEgaW1wbGVtZW50ZWQ6IDENCihY
RU4pIC4uLi4uLi4gICAgIDogSU8gQVBJQyB2ZXJzaW9uOiAwMDIxDQooWEVOKSAuLi4uIHJl
Z2lzdGVyICMwMjogMDYwMDAwMDANCihYRU4pIC4uLi4uLi4gICAgIDogYXJiaXRyYXRpb246
IDA2DQooWEVOKSAuLi4uIHJlZ2lzdGVyICMwMzogMDcwMDAwMDANCihYRU4pIC4uLi4uLi4g
ICAgIDogQm9vdCBEVCAgICA6IDANCihYRU4pIC4uLi4gSVJRIHJlZGlyZWN0aW9uIHRhYmxl
Og0KKFhFTikgIE5SIExvZyBQaHkgTWFzayBUcmlnIElSUiBQb2wgU3RhdCBEZXN0IERlbGkg
VmVjdDogICANCihYRU4pICAwMCAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAg
ICAwICAgIDAwDQooWEVOKSAgMDEgMDAxIDAxICAwICAgIDAgICAgMCAgIDAgICAwICAgIDEg
ICAgMSAgICAzMA0KKFhFTikgIDAyIDAwMSAwMSAgMCAgICAwICAgIDAgICAwICAgMCAgICAx
ICAgIDEgICAgRjANCihYRU4pICAwMyAwMDEgMDEgIDAgICAgMCAgICAwICAgMCAgIDAgICAg
MSAgICAxICAgIDM4DQooWEVOKSAgMDQgMDAxIDAxICAwICAgIDAgICAgMCAgIDAgICAwICAg
IDEgICAgMSAgICBGMQ0KKFhFTikgIDA1IDAwMSAwMSAgMCAgICAwICAgIDAgICAwICAgMCAg
ICAxICAgIDEgICAgNDANCihYRU4pICAwNiAwMDEgMDEgIDAgICAgMCAgICAwICAgMCAgIDAg
ICAgMSAgICAxICAgIDQ4DQooWEVOKSAgMDcgMDAxIDAxICAwICAgIDAgICAgMCAgIDAgICAw
ICAgIDEgICAgMSAgICA1MA0KKFhFTikgIDA4IDAwMSAwMSAgMCAgICAwICAgIDAgICAwICAg
MCAgICAxICAgIDEgICAgNTgNCihYRU4pICAwOSAwMDEgMDEgIDEgICAgMSAgICAwICAgMSAg
IDAgICAgMSAgICAxICAgIDYwDQooWEVOKSAgMGEgMDAxIDAxICAwICAgIDAgICAgMCAgIDAg
ICAwICAgIDEgICAgMSAgICA2OA0KKFhFTikgIDBiIDAwMSAwMSAgMCAgICAwICAgIDAgICAw
ICAgMCAgICAxICAgIDEgICAgNzANCihYRU4pICAwYyAwMDEgMDEgIDAgICAgMCAgICAwICAg
MCAgIDAgICAgMSAgICAxICAgIDc4DQooWEVOKSAgMGQgMDAxIDAxICAwICAgIDAgICAgMCAg
IDAgICAwICAgIDEgICAgMSAgICA4OA0KKFhFTikgIDBlIDAwMSAwMSAgMCAgICAwICAgIDAg
ICAwICAgMCAgICAxICAgIDEgICAgOTANCihYRU4pICAwZiAwMDEgMDEgIDAgICAgMCAgICAw
ICAgMCAgIDAgICAgMSAgICAxICAgIDk4DQooWEVOKSAgMTAgMDAwIDAwICAxICAgIDAgICAg
MCAgIDAgICAwICAgIDAgICAgMCAgICAwMA0KKFhFTikgIDExIDAwMCAwMCAgMSAgICAwICAg
IDAgICAwICAgMCAgICAwICAgIDAgICAgMDANCihYRU4pICAxMiAwMDAgMDAgIDEgICAgMCAg
ICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwDQooWEVOKSAgMTMgMDAwIDAwICAxICAgIDAg
ICAgMCAgIDAgICAwICAgIDAgICAgMCAgICAwMA0KKFhFTikgIDE0IDAwMCAwMCAgMSAgICAw
ICAgIDAgICAwICAgMCAgICAwICAgIDAgICAgMDANCihYRU4pICAxNSAwMDAgMDAgIDEgICAg
MCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwDQooWEVOKSAgMTYgMDAwIDAwICAxICAg
IDAgICAgMCAgIDAgICAwICAgIDAgICAgMCAgICAwMA0KKFhFTikgIDE3IDAwMCAwMCAgMSAg
ICAwICAgIDAgICAwICAgMCAgICAwICAgIDAgICAgMDANCihYRU4pIElPIEFQSUMgIzcuLi4u
Li4NCihYRU4pIC4uLi4gcmVnaXN0ZXIgIzAwOiAwNzAwMDAwMA0KKFhFTikgLi4uLi4uLiAg
ICA6IHBoeXNpY2FsIEFQSUMgaWQ6IDA3DQooWEVOKSAuLi4uLi4uICAgIDogRGVsaXZlcnkg
VHlwZTogMA0KKFhFTikgLi4uLi4uLiAgICA6IExUUyAgICAgICAgICA6IDANCihYRU4pIC4u
Li4gcmVnaXN0ZXIgIzAxOiAwMDFGODAyMQ0KKFhFTikgLi4uLi4uLiAgICAgOiBtYXggcmVk
aXJlY3Rpb24gZW50cmllczogMDAxRg0KKFhFTikgLi4uLi4uLiAgICAgOiBQUlEgaW1wbGVt
ZW50ZWQ6IDENCihYRU4pIC4uLi4uLi4gICAgIDogSU8gQVBJQyB2ZXJzaW9uOiAwMDIxDQoo
WEVOKSAuLi4uIHJlZ2lzdGVyICMwMjogMDAwMDAwMDANCihYRU4pIC4uLi4uLi4gICAgIDog
YXJiaXRyYXRpb246IDAwDQooWEVOKSAuLi4uIElSUSByZWRpcmVjdGlvbiB0YWJsZToNCihY
RU4pICBOUiBMb2cgUGh5IE1hc2sgVHJpZyBJUlIgUG9sIFN0YXQgRGVzdCBEZWxpIFZlY3Q6
ICAgDQooWEVOKSAgMDAgMDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAwICAgIDAgICAgMCAg
ICAwMA0KKFhFTikgIDAxIDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDAg
ICAgMDANCihYRU4pICAwMiAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAw
ICAgIDAwDQooWEVOKSAgMDMgMDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAwICAgIDAgICAg
MCAgICAwMA0KKFhFTikgIDA0IDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAg
IDAgICAgMDANCihYRU4pICAwNSAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAg
ICAwICAgIDAwDQooWEVOKSAgMDYgMDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAwICAgIDAg
ICAgMCAgICAwMA0KKFhFTikgIDA3IDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAw
ICAgIDAgICAgMDANCihYRU4pICAwOCAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAg
MCAgICAwICAgIDAwDQooWEVOKSAgMDkgMDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAwICAg
IDAgICAgMCAgICAwMA0KKFhFTikgIDBhIDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAg
ICAwICAgIDAgICAgMDANCihYRU4pICAwYiAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAg
ICAgMCAgICAwICAgIDAwDQooWEVOKSAgMGMgMDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAw
ICAgIDAgICAgMCAgICAwMA0KKFhFTikgIDBkIDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAg
MCAgICAwICAgIDAgICAgMDANCihYRU4pICAwZSAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAg
IDAgICAgMCAgICAwICAgIDAwDQooWEVOKSAgMGYgMDAwIDAwICAxICAgIDAgICAgMCAgIDAg
ICAwICAgIDAgICAgMCAgICAwMA0KKFhFTikgIDEwIDAwMCAwMCAgMSAgICAwICAgIDAgICAw
ICAgMCAgICAwICAgIDAgICAgMDANCihYRU4pICAxMSAwMDAgMDAgIDEgICAgMCAgICAwICAg
MCAgIDAgICAgMCAgICAwICAgIDAwDQooWEVOKSAgMTIgMDAwIDAwICAxICAgIDAgICAgMCAg
IDAgICAwICAgIDAgICAgMCAgICAwMA0KKFhFTikgIDEzIDAwMCAwMCAgMSAgICAwICAgIDAg
ICAwICAgMCAgICAwICAgIDAgICAgMDANCihYRU4pICAxNCAwMDAgMDAgIDEgICAgMCAgICAw
ICAgMCAgIDAgICAgMCAgICAwICAgIDAwDQooWEVOKSAgMTUgMDAwIDAwICAxICAgIDAgICAg
MCAgIDAgICAwICAgIDAgICAgMCAgICAwMA0KKFhFTikgIDE2IDAwMCAwMCAgMSAgICAwICAg
IDAgICAwICAgMCAgICAwICAgIDAgICAgMDANCihYRU4pICAxNyAwMDAgMDAgIDEgICAgMCAg
ICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwDQooWEVOKSAgMTggMDAwIDAwICAxICAgIDAg
ICAgMCAgIDAgICAwICAgIDAgICAgMCAgICAwMA0KKFhFTikgIDE5IDAwMCAwMCAgMSAgICAw
ICAgIDAgICAwICAgMCAgICAwICAgIDAgICAgMDANCihYRU4pICAxYSAwMDAgMDAgIDEgICAg
MCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwDQooWEVOKSAgMWIgMDAwIDAwICAxICAg
IDAgICAgMCAgIDAgICAwICAgIDAgICAgMCAgICAwMA0KKFhFTikgIDFjIDAwMCAwMCAgMSAg
ICAwICAgIDAgICAwICAgMCAgICAwICAgIDAgICAgMDANCihYRU4pICAxZCAwMDAgMDAgIDEg
ICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwDQooWEVOKSAgMWUgMDAwIDAwICAx
ICAgIDAgICAgMCAgIDAgICAwICAgIDAgICAgMCAgICAwMA0KKFhFTikgIDFmIDAwMCAwMCAg
MSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDAgICAgMDANCihYRU4pIFVzaW5nIHZlY3Rv
ci1iYXNlZCBpbmRleGluZw0KKFhFTikgSVJRIHRvIHBpbiBtYXBwaW5nczoNCihYRU4pIElS
UTI0MCAtPiAwOjINCihYRU4pIElSUTQ4IC0+IDA6MQ0KKFhFTikgSVJRNTYgLT4gMDozDQoo
WEVOKSBJUlEyNDEgLT4gMDo0DQooWEVOKSBJUlE2NCAtPiAwOjUNCihYRU4pIElSUTcyIC0+
IDA6Ng0KKFhFTikgSVJRODAgLT4gMDo3DQooWEVOKSBJUlE4OCAtPiAwOjgNCihYRU4pIElS
UTk2IC0+IDA6OQ0KKFhFTikgSVJRMTA0IC0+IDA6MTANCihYRU4pIElSUTExMiAtPiAwOjEx
DQooWEVOKSBJUlExMjAgLT4gMDoxMg0KKFhFTikgSVJRMTM2IC0+IDA6MTMNCihYRU4pIElS
UTE0NCAtPiAwOjE0DQooWEVOKSBJUlExNTIgLT4gMDoxNQ0KKFhFTikgLi4uLi4uLi4uLi4u
Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uIGRvbmUuDQooWEVOKSBVc2luZyBsb2NhbCBBUElD
IHRpbWVyIGludGVycnVwdHMuDQooWEVOKSBjYWxpYnJhdGluZyBBUElDIHRpbWVyIC4uLg0K
KFhFTikgLi4uLi4gQ1BVIGNsb2NrIHNwZWVkIGlzIDMyMDAuMTM1NyBNSHouDQooWEVOKSAu
Li4uLiBob3N0IGJ1cyBjbG9jayBzcGVlZCBpcyAyMDAuMDA4MyBNSHouDQooWEVOKSAuLi4u
LiBidXNfc2NhbGUgPSAweDAwMDBDQ0Q3DQooWEVOKSBbMjAxMi0wOS0wNCAxNTo1MToxNV0g
UGxhdGZvcm0gdGltZXIgaXMgMTQuMzE4TUh6IEhQRVQNCihYRU4pIFsyMDEyLTA5LTA0IDE1
OjUxOjE1XSBBbGxvY2F0ZWQgY29uc29sZSByaW5nIG9mIDY0IEtpQi4NCihYRU4pIFsyMDEy
LTA5LTA0IDE1OjUxOjE1XSBIVk06IEFTSURzIGVuYWJsZWQuDQooWEVOKSBbMjAxMi0wOS0w
NCAxNTo1MToxNV0gU1ZNOiBTdXBwb3J0ZWQgYWR2YW5jZWQgZmVhdHVyZXM6DQooWEVOKSBb
MjAxMi0wOS0wNCAxNTo1MToxNV0gIC0gTmVzdGVkIFBhZ2UgVGFibGVzIChOUFQpDQooWEVO
KSBbMjAxMi0wOS0wNCAxNTo1MToxNV0gIC0gTGFzdCBCcmFuY2ggUmVjb3JkIChMQlIpIFZp
cnR1YWxpc2F0aW9uDQooWEVOKSBbMjAxMi0wOS0wNCAxNTo1MToxNV0gIC0gTmV4dC1SSVAg
U2F2ZWQgb24gI1ZNRVhJVA0KKFhFTikgWzIwMTItMDktMDQgMTU6NTE6MTVdICAtIFBhdXNl
LUludGVyY2VwdCBGaWx0ZXINCihYRU4pIFsyMDEyLTA5LTA0IDE1OjUxOjE1XSBIVk06IFNW
TSBlbmFibGVkDQooWEVOKSBbMjAxMi0wOS0wNCAxNTo1MToxNV0gSFZNOiBIYXJkd2FyZSBB
c3Npc3RlZCBQYWdpbmcgKEhBUCkgZGV0ZWN0ZWQNCihYRU4pIFsyMDEyLTA5LTA0IDE1OjUx
OjE1XSBIVk06IEhBUCBwYWdlIHNpemVzOiA0a0IsIDJNQiwgMUdCDQooWEVOKSBbMjAxMi0w
OS0wNCAxNTo1MToxNF0gbWFza2VkIEV4dElOVCBvbiBDUFUjMQ0KKFhFTikgWzIwMTItMDkt
MDQgMTU6NTE6MTVdIG1pY3JvY29kZTogY29sbGVjdF9jcHVfaW5mbzogcGF0Y2hfaWQ9MHgx
MDAwMGJmDQooWEVOKSBbMjAxMi0wOS0wNCAxNTo1MToxNF0gbWFza2VkIEV4dElOVCBvbiBD
UFUjMg0KKFhFTikgWzIwMTItMDktMDQgMTU6NTE6MTVdIG1pY3JvY29kZTogY29sbGVjdF9j
cHVfaW5mbzogcGF0Y2hfaWQ9MHgxMDAwMGJmDQooWEVOKSBbMjAxMi0wOS0wNCAxNTo1MTox
NF0gbWFza2VkIEV4dElOVCBvbiBDUFUjMw0KKFhFTikgWzIwMTItMDktMDQgMTU6NTE6MTVd
IG1pY3JvY29kZTogY29sbGVjdF9jcHVfaW5mbzogcGF0Y2hfaWQ9MHgxMDAwMGJmDQooWEVO
KSBbMjAxMi0wOS0wNCAxNTo1MToxNF0gbWFza2VkIEV4dElOVCBvbiBDUFUjNA0KKFhFTikg
WzIwMTItMDktMDQgMTU6NTE6MTVdIG1pY3JvY29kZTogY29sbGVjdF9jcHVfaW5mbzogcGF0
Y2hfaWQ9MHgxMDAwMGJmDQooWEVOKSBbMjAxMi0wOS0wNCAxNTo1MToxNF0gbWFza2VkIEV4
dElOVCBvbiBDUFUjNQ0KKFhFTikgWzIwMTItMDktMDQgMTU6NTE6MTVdIEJyb3VnaHQgdXAg
NiBDUFVzDQooWEVOKSBbMjAxMi0wOS0wNCAxNTo1MToxNV0gbWljcm9jb2RlOiBjb2xsZWN0
X2NwdV9pbmZvOiBwYXRjaF9pZD0weDEwMDAwYmYNCihYRU4pIFsyMDEyLTA5LTA0IDE1OjUx
OjE1XSBIUEVUJ3MgTVNJIG1vZGUgaGFzbid0IGJlZW4gc3VwcG9ydGVkIHdoZW4gSW50ZXJy
dXB0IFJlbWFwcGluZyBpcyBlbmFibGVkLg0KKFhFTikgWzIwMTItMDktMDQgMTU6NTE6MTVd
IEFDUEkgc2xlZXAgbW9kZXM6IFMzDQooWEVOKSBbMjAxMi0wOS0wNCAxNTo1MToxNV0gTUNB
OiBVc2UgaHcgdGhyZXNob2xkaW5nIHRvIGFkanVzdCBwb2xsaW5nIGZyZXF1ZW5jeQ0KKFhF
TikgWzIwMTItMDktMDQgMTU6NTE6MTVdIG1jaGVja19wb2xsOiBNYWNoaW5lIGNoZWNrIHBv
bGxpbmcgdGltZXIgc3RhcnRlZC4NCihYRU4pIFsyMDEyLTA5LTA0IDE1OjUxOjE1XSBYZW5v
cHJvZmlsZTogRmFpbGVkIHRvIHNldHVwIElCUyBMVlQgb2Zmc2V0LCBJQlNDVEwgPSAweGZm
ZmZmZmZmDQooWEVOKSBbMjAxMi0wOS0wNCAxNTo1MToxNV0gKioqIExPQURJTkcgRE9NQUlO
IDAgKioqDQooWEVOKSBbMjAxMi0wOS0wNCAxNTo1MToxNl0gZWxmX3BhcnNlX2JpbmFyeTog
cGhkcjogcGFkZHI9MHgxMDAwMDAwIG1lbXN6PTB4ZDZhMDAwDQooWEVOKSBbMjAxMi0wOS0w
NCAxNTo1MToxNl0gZWxmX3BhcnNlX2JpbmFyeTogcGhkcjogcGFkZHI9MHgxZTAwMDAwIG1l
bXN6PTB4ZGIwZTgNCihYRU4pIFsyMDEyLTA5LTA0IDE1OjUxOjE2XSBlbGZfcGFyc2VfYmlu
YXJ5OiBwaGRyOiBwYWRkcj0weDFlZGMwMDAgbWVtc3o9MHgxM2MwMA0KKFhFTikgWzIwMTIt
MDktMDQgMTU6NTE6MTZdIGVsZl9wYXJzZV9iaW5hcnk6IHBoZHI6IHBhZGRyPTB4MWVmMDAw
MCBtZW1zej0weGRlNTAwMA0KKFhFTikgWzIwMTItMDktMDQgMTU6NTE6MTZdIGVsZl9wYXJz
ZV9iaW5hcnk6IG1lbW9yeTogMHgxMDAwMDAwIC0+IDB4MmNkNTAwMA0KKFhFTikgWzIwMTIt
MDktMDQgMTU6NTE6MTZdIGVsZl94ZW5fcGFyc2Vfbm90ZTogR1VFU1RfT1MgPSAibGludXgi
DQooWEVOKSBbMjAxMi0wOS0wNCAxNTo1MToxNl0gZWxmX3hlbl9wYXJzZV9ub3RlOiBHVUVT
VF9WRVJTSU9OID0gIjIuNiINCihYRU4pIFsyMDEyLTA5LTA0IDE1OjUxOjE2XSBlbGZfeGVu
X3BhcnNlX25vdGU6IFhFTl9WRVJTSU9OID0gInhlbi0zLjAiDQooWEVOKSBbMjAxMi0wOS0w
NCAxNTo1MToxNl0gZWxmX3hlbl9wYXJzZV9ub3RlOiBWSVJUX0JBU0UgPSAweGZmZmZmZmZm
ODAwMDAwMDANCihYRU4pIFsyMDEyLTA5LTA0IDE1OjUxOjE2XSBlbGZfeGVuX3BhcnNlX25v
dGU6IEVOVFJZID0gMHhmZmZmZmZmZjgxZWYwMjEwDQooWEVOKSBbMjAxMi0wOS0wNCAxNTo1
MToxNl0gZWxmX3hlbl9wYXJzZV9ub3RlOiBIWVBFUkNBTExfUEFHRSA9IDB4ZmZmZmZmZmY4
MTAwMTAwMA0KKFhFTikgWzIwMTItMDktMDQgMTU6NTE6MTZdIGVsZl94ZW5fcGFyc2Vfbm90
ZTogRkVBVFVSRVMgPSAiIXdyaXRhYmxlX3BhZ2VfdGFibGVzfHBhZV9wZ2Rpcl9hYm92ZV80
Z2IiDQooWEVOKSBbMjAxMi0wOS0wNCAxNTo1MToxNl0gZWxmX3hlbl9wYXJzZV9ub3RlOiBQ
QUVfTU9ERSA9ICJ5ZXMiDQooWEVOKSBbMjAxMi0wOS0wNCAxNTo1MToxNl0gZWxmX3hlbl9w
YXJzZV9ub3RlOiBMT0FERVIgPSAiZ2VuZXJpYyINCihYRU4pIFsyMDEyLTA5LTA0IDE1OjUx
OjE2XSBlbGZfeGVuX3BhcnNlX25vdGU6IHVua25vd24geGVuIGVsZiBub3RlICgweGQpDQoo
WEVOKSBbMjAxMi0wOS0wNCAxNTo1MToxNl0gZWxmX3hlbl9wYXJzZV9ub3RlOiBTVVNQRU5E
X0NBTkNFTCA9IDB4MQ0KKFhFTikgWzIwMTItMDktMDQgMTU6NTE6MTZdIGVsZl94ZW5fcGFy
c2Vfbm90ZTogSFZfU1RBUlRfTE9XID0gMHhmZmZmODAwMDAwMDAwMDAwDQooWEVOKSBbMjAx
Mi0wOS0wNCAxNTo1MToxNl0gZWxmX3hlbl9wYXJzZV9ub3RlOiBQQUREUl9PRkZTRVQgPSAw
eDANCihYRU4pIFsyMDEyLTA5LTA0IDE1OjUxOjE2XSBlbGZfeGVuX2FkZHJfY2FsY19jaGVj
azogYWRkcmVzc2VzOg0KKFhFTikgWzIwMTItMDktMDQgMTU6NTE6MTZdICAgICB2aXJ0X2Jh
c2UgICAgICAgID0gMHhmZmZmZmZmZjgwMDAwMDAwDQooWEVOKSBbMjAxMi0wOS0wNCAxNTo1
MToxNl0gICAgIGVsZl9wYWRkcl9vZmZzZXQgPSAweDANCihYRU4pIFsyMDEyLTA5LTA0IDE1
OjUxOjE2XSAgICAgdmlydF9vZmZzZXQgICAgICA9IDB4ZmZmZmZmZmY4MDAwMDAwMA0KKFhF
TikgWzIwMTItMDktMDQgMTU6NTE6MTZdICAgICB2aXJ0X2tzdGFydCAgICAgID0gMHhmZmZm
ZmZmZjgxMDAwMDAwDQooWEVOKSBbMjAxMi0wOS0wNCAxNTo1MToxNl0gICAgIHZpcnRfa2Vu
ZCAgICAgICAgPSAweGZmZmZmZmZmODJjZDUwMDANCihYRU4pIFsyMDEyLTA5LTA0IDE1OjUx
OjE2XSAgICAgdmlydF9lbnRyeSAgICAgICA9IDB4ZmZmZmZmZmY4MWVmMDIxMA0KKFhFTikg
WzIwMTItMDktMDQgMTU6NTE6MTZdICAgICBwMm1fYmFzZSAgICAgICAgID0gMHhmZmZmZmZm
ZmZmZmZmZmZmDQooWEVOKSBbMjAxMi0wOS0wNCAxNTo1MToxNl0gIFhlbiAga2VybmVsOiA2
NC1iaXQsIGxzYiwgY29tcGF0MzINCihYRU4pIFsyMDEyLTA5LTA0IDE1OjUxOjE2XSAgRG9t
MCBrZXJuZWw6IDY0LWJpdCwgUEFFLCBsc2IsIHBhZGRyIDB4MTAwMDAwMCAtPiAweDJjZDUw
MDANCihYRU4pIFsyMDEyLTA5LTA0IDE1OjUxOjE2XSBQSFlTSUNBTCBNRU1PUlkgQVJSQU5H
RU1FTlQ6DQooWEVOKSBbMjAxMi0wOS0wNCAxNTo1MToxNl0gIERvbTAgYWxsb2MuOiAgIDAw
MDAwMDAyNDAwMDAwMDAtPjAwMDAwMDAyNDQwMDAwMDAgKDI0MjQyOCBwYWdlcyB0byBiZSBh
bGxvY2F0ZWQpDQooWEVOKSBbMjAxMi0wOS0wNCAxNTo1MToxNl0gIEluaXQuIHJhbWRpc2s6
IDAwMDAwMDAyNGYyZmMwMDAtPjAwMDAwMDAyNGZmZmY4MDANCihYRU4pIFsyMDEyLTA5LTA0
IDE1OjUxOjE2XSBWSVJUVUFMIE1FTU9SWSBBUlJBTkdFTUVOVDoNCihYRU4pIFsyMDEyLTA5
LTA0IDE1OjUxOjE2XSAgTG9hZGVkIGtlcm5lbDogZmZmZmZmZmY4MTAwMDAwMC0+ZmZmZmZm
ZmY4MmNkNTAwMA0KKFhFTikgWzIwMTItMDktMDQgMTU6NTE6MTZdICBJbml0LiByYW1kaXNr
OiBmZmZmZmZmZjgyY2Q1MDAwLT5mZmZmZmZmZjgzOWQ4ODAwDQooWEVOKSBbMjAxMi0wOS0w
NCAxNTo1MToxNl0gIFBoeXMtTWFjaCBtYXA6IGZmZmZmZmZmODM5ZDkwMDAtPmZmZmZmZmZm
ODNiZDkwMDANCihYRU4pIFsyMDEyLTA5LTA0IDE1OjUxOjE2XSAgU3RhcnQgaW5mbzogICAg
ZmZmZmZmZmY4M2JkOTAwMC0+ZmZmZmZmZmY4M2JkOTRiNA0KKFhFTikgWzIwMTItMDktMDQg
MTU6NTE6MTZdICBQYWdlIHRhYmxlczogICBmZmZmZmZmZjgzYmRhMDAwLT5mZmZmZmZmZjgz
YmZkMDAwDQooWEVOKSBbMjAxMi0wOS0wNCAxNTo1MToxNl0gIEJvb3Qgc3RhY2s6ICAgIGZm
ZmZmZmZmODNiZmQwMDAtPmZmZmZmZmZmODNiZmUwMDANCihYRU4pIFsyMDEyLTA5LTA0IDE1
OjUxOjE2XSAgVE9UQUw6ICAgICAgICAgZmZmZmZmZmY4MDAwMDAwMC0+ZmZmZmZmZmY4NDAw
MDAwMA0KKFhFTikgWzIwMTItMDktMDQgMTU6NTE6MTZdICBFTlRSWSBBRERSRVNTOiBmZmZm
ZmZmZjgxZWYwMjEwDQooWEVOKSBbMjAxMi0wOS0wNCAxNTo1MToxNl0gRG9tMCBoYXMgbWF4
aW11bSA2IFZDUFVzDQooWEVOKSBbMjAxMi0wOS0wNCAxNTo1MToxNl0gZWxmX2xvYWRfYmlu
YXJ5OiBwaGRyIDAgYXQgMHhmZmZmZmZmZjgxMDAwMDAwIC0+IDB4ZmZmZmZmZmY4MWQ2YTAw
MA0KKFhFTikgWzIwMTItMDktMDQgMTU6NTE6MTZdIGVsZl9sb2FkX2JpbmFyeTogcGhkciAx
IGF0IDB4ZmZmZmZmZmY4MWUwMDAwMCAtPiAweGZmZmZmZmZmODFlZGIwZTgNCihYRU4pIFsy
MDEyLTA5LTA0IDE1OjUxOjE2XSBlbGZfbG9hZF9iaW5hcnk6IHBoZHIgMiBhdCAweGZmZmZm
ZmZmODFlZGMwMDAgLT4gMHhmZmZmZmZmZjgxZWVmYzAwDQooWEVOKSBbMjAxMi0wOS0wNCAx
NTo1MToxNl0gZWxmX2xvYWRfYmluYXJ5OiBwaGRyIDMgYXQgMHhmZmZmZmZmZjgxZWYwMDAw
IC0+IDB4ZmZmZmZmZmY4MWY4OTAwMA0KKFhFTikgWzIwMTItMDktMDQgMTU6NTE6MTZdIEFN
RC1WaTogTUUgSEVSRSAhPDI+QU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNl
IGlkID0gMHgwMDAwLCByb290IHRhYmxlID0gMHgyNGQ4NGIwMDAsIGRvbWFpbiA9IDAsIHBh
Z2luZyBtb2RlID0gMw0KKFhFTikgWzIwMTItMDktMDQgMTU6NTE6MTZdIEFNRC1WaTogU2V0
dXAgSS9PIHBhZ2UgdGFibGU6IGRldmljZSBpZCA9IDB4MDAwMiwgcm9vdCB0YWJsZSA9IDB4
MjRkODRiMDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMNCihYRU4pIFsyMDEyLTA5
LTA0IDE1OjUxOjE2XSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQg
PSAweDAwMTAsIHJvb3QgdGFibGUgPSAweDI0ZDg0YjAwMCwgZG9tYWluID0gMCwgcGFnaW5n
IG1vZGUgPSAzDQooWEVOKSBbMjAxMi0wOS0wNCAxNTo1MToxNl0gQU1ELVZpOiBTZXR1cCBJ
L08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHgwMDE4LCByb290IHRhYmxlID0gMHgyNGQ4
NGIwMDAsIGRvbWFpbiA9IDAsIHBhZ2luZyBtb2RlID0gMw0KKFhFTikgWzIwMTItMDktMDQg
MTU6NTE6MTZdIEFNRC1WaTogU2V0dXAgSS9PIHBhZ2UgdGFibGU6IGRldmljZSBpZCA9IDB4
MDAyOCwgcm9vdCB0YWJsZSA9IDB4MjRkODRiMDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9k
ZSA9IDMNCihYRU4pIFsyMDEyLTA5LTA0IDE1OjUxOjE2XSBBTUQtVmk6IFNldHVwIEkvTyBw
YWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweDAwMzAsIHJvb3QgdGFibGUgPSAweDI0ZDg0YjAw
MCwgZG9tYWluID0gMCwgcGFnaW5nIG1vZGUgPSAzDQooWEVOKSBbMjAxMi0wOS0wNCAxNTo1
MToxNl0gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHgwMDUw
LCByb290IHRhYmxlID0gMHgyNGQ4NGIwMDAsIGRvbWFpbiA9IDAsIHBhZ2luZyBtb2RlID0g
Mw0KKFhFTikgWzIwMTItMDktMDQgMTU6NTE6MTZdIEFNRC1WaTogU2V0dXAgSS9PIHBhZ2Ug
dGFibGU6IGRldmljZSBpZCA9IDB4MDA1OCwgcm9vdCB0YWJsZSA9IDB4MjRkODRiMDAwLCBk
b21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMNCihYRU4pIFsyMDEyLTA5LTA0IDE1OjUxOjE2
XSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweDAwNjAsIHJv
b3QgdGFibGUgPSAweDI0ZDg0YjAwMCwgZG9tYWluID0gMCwgcGFnaW5nIG1vZGUgPSAzDQoo
WEVOKSBbMjAxMi0wOS0wNCAxNTo1MToxNl0gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJs
ZTogZGV2aWNlIGlkID0gMHgwMDY4LCByb290IHRhYmxlID0gMHgyNGQ4NGIwMDAsIGRvbWFp
biA9IDAsIHBhZ2luZyBtb2RlID0gMw0KKFhFTikgWzIwMTItMDktMDQgMTU6NTE6MTZdIEFN
RC1WaTogU2V0dXAgSS9PIHBhZ2UgdGFibGU6IGRldmljZSBpZCA9IDB4MDA4OCwgcm9vdCB0
YWJsZSA9IDB4MjRkODRiMDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMNCihYRU4p
IFsyMDEyLTA5LTA0IDE1OjUxOjE2XSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBk
ZXZpY2UgaWQgPSAweDAwOTAsIHJvb3QgdGFibGUgPSAweDI0ZDg0YjAwMCwgZG9tYWluID0g
MCwgcGFnaW5nIG1vZGUgPSAzDQooWEVOKSBbMjAxMi0wOS0wNCAxNTo1MToxNl0gQU1ELVZp
OiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHgwMDkyLCByb290IHRhYmxl
ID0gMHgyNGQ4NGIwMDAsIGRvbWFpbiA9IDAsIHBhZ2luZyBtb2RlID0gMw0KKFhFTikgWzIw
MTItMDktMDQgMTU6NTE6MTZdIEFNRC1WaTogU2V0dXAgSS9PIHBhZ2UgdGFibGU6IGRldmlj
ZSBpZCA9IDB4MDA5OCwgcm9vdCB0YWJsZSA9IDB4MjRkODRiMDAwLCBkb21haW4gPSAwLCBw
YWdpbmcgbW9kZSA9IDMNCihYRU4pIFsyMDEyLTA5LTA0IDE1OjUxOjE2XSBBTUQtVmk6IFNl
dHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweDAwOWEsIHJvb3QgdGFibGUgPSAw
eDI0ZDg0YjAwMCwgZG9tYWluID0gMCwgcGFnaW5nIG1vZGUgPSAzDQooWEVOKSBbMjAxMi0w
OS0wNCAxNTo1MToxNl0gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlk
ID0gMHgwMGEwLCByb290IHRhYmxlID0gMHgyNGQ4NGIwMDAsIGRvbWFpbiA9IDAsIHBhZ2lu
ZyBtb2RlID0gMw0KKFhFTikgWzIwMTItMDktMDQgMTU6NTE6MTZdIEFNRC1WaTogU2V0dXAg
SS9PIHBhZ2UgdGFibGU6IGRldmljZSBpZCA9IDB4MDBhMywgcm9vdCB0YWJsZSA9IDB4MjRk
ODRiMDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMNCihYRU4pIFsyMDEyLTA5LTA0
IDE1OjUxOjE2XSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAw
eDAwYTQsIHJvb3QgdGFibGUgPSAweDI0ZDg0YjAwMCwgZG9tYWluID0gMCwgcGFnaW5nIG1v
ZGUgPSAzDQooWEVOKSBbMjAxMi0wOS0wNCAxNTo1MToxNl0gQU1ELVZpOiBTZXR1cCBJL08g
cGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHgwMGE1LCByb290IHRhYmxlID0gMHgyNGQ4NGIw
MDAsIGRvbWFpbiA9IDAsIHBhZ2luZyBtb2RlID0gMw0KKFhFTikgWzIwMTItMDktMDQgMTU6
NTE6MTZdIEFNRC1WaTogU2V0dXAgSS9PIHBhZ2UgdGFibGU6IGRldmljZSBpZCA9IDB4MDBh
OCwgcm9vdCB0YWJsZSA9IDB4MjRkODRiMDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9
IDMNCihYRU4pIFsyMDEyLTA5LTA0IDE1OjUxOjE2XSBBTUQtVmk6IFNldHVwIEkvTyBwYWdl
IHRhYmxlOiBkZXZpY2UgaWQgPSAweDAwYjAsIHJvb3QgdGFibGUgPSAweDI0ZDg0YjAwMCwg
ZG9tYWluID0gMCwgcGFnaW5nIG1vZGUgPSAzDQooWEVOKSBbMjAxMi0wOS0wNCAxNTo1MTox
Nl0gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHgwMGIyLCBy
b290IHRhYmxlID0gMHgyNGQ4NGIwMDAsIGRvbWFpbiA9IDAsIHBhZ2luZyBtb2RlID0gMw0K
KFhFTikgWzIwMTItMDktMDQgMTU6NTE6MTZdIEFNRC1WaTogTm8gaW9tbXUgZm9yIGRldmlj
ZSAwMDAwOjAwOjE4LjANCihYRU4pIFsyMDEyLTA5LTA0IDE1OjUxOjE2XSBBTUQtVmk6IE5v
IGlvbW11IGZvciBkZXZpY2UgMDAwMDowMDoxOC4xDQooWEVOKSBbMjAxMi0wOS0wNCAxNTo1
MToxNl0gQU1ELVZpOiBObyBpb21tdSBmb3IgZGV2aWNlIDAwMDA6MDA6MTguMg0KKFhFTikg
WzIwMTItMDktMDQgMTU6NTE6MTZdIEFNRC1WaTogTm8gaW9tbXUgZm9yIGRldmljZSAwMDAw
OjAwOjE4LjMNCihYRU4pIFsyMDEyLTA5LTA0IDE1OjUxOjE2XSBBTUQtVmk6IE5vIGlvbW11
IGZvciBkZXZpY2UgMDAwMDowMDoxOC40DQooWEVOKSBbMjAxMi0wOS0wNCAxNTo1MToxNl0g
QU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHgwNDAwLCByb290
IHRhYmxlID0gMHgyNGQ4NGIwMDAsIGRvbWFpbiA9IDAsIHBhZ2luZyBtb2RlID0gMw0KKFhF
TikgWzIwMTItMDktMDQgMTU6NTE6MTddIEFNRC1WaTogU2V0dXAgSS9PIHBhZ2UgdGFibGU6
IGRldmljZSBpZCA9IDB4MDQwMSwgcm9vdCB0YWJsZSA9IDB4MjRkODRiMDAwLCBkb21haW4g
PSAwLCBwYWdpbmcgbW9kZSA9IDMNCihYRU4pIFsyMDEyLTA5LTA0IDE1OjUxOjE3XSBBTUQt
Vmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweDA0MDIsIHJvb3QgdGFi
bGUgPSAweDI0ZDg0YjAwMCwgZG9tYWluID0gMCwgcGFnaW5nIG1vZGUgPSAzDQooWEVOKSBb
MjAxMi0wOS0wNCAxNTo1MToxN10gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2
aWNlIGlkID0gMHgwNDAzLCByb290IHRhYmxlID0gMHgyNGQ4NGIwMDAsIGRvbWFpbiA9IDAs
IHBhZ2luZyBtb2RlID0gMw0KKFhFTikgWzIwMTItMDktMDQgMTU6NTE6MTddIEFNRC1WaTog
U2V0dXAgSS9PIHBhZ2UgdGFibGU6IGRldmljZSBpZCA9IDB4MDQwNCwgcm9vdCB0YWJsZSA9
IDB4MjRkODRiMDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMNCihYRU4pIFsyMDEy
LTA5LTA0IDE1OjUxOjE3XSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2Ug
aWQgPSAweDA0MDUsIHJvb3QgdGFibGUgPSAweDI0ZDg0YjAwMCwgZG9tYWluID0gMCwgcGFn
aW5nIG1vZGUgPSAzDQooWEVOKSBbMjAxMi0wOS0wNCAxNTo1MToxN10gQU1ELVZpOiBTZXR1
cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHgwNDA2LCByb290IHRhYmxlID0gMHgy
NGQ4NGIwMDAsIGRvbWFpbiA9IDAsIHBhZ2luZyBtb2RlID0gMw0KKFhFTikgWzIwMTItMDkt
MDQgMTU6NTE6MTddIEFNRC1WaTogU2V0dXAgSS9PIHBhZ2UgdGFibGU6IGRldmljZSBpZCA9
IDB4MDQwNywgcm9vdCB0YWJsZSA9IDB4MjRkODRiMDAwLCBkb21haW4gPSAwLCBwYWdpbmcg
bW9kZSA9IDMNCihYRU4pIFsyMDEyLTA5LTA0IDE1OjUxOjE3XSBBTUQtVmk6IFNldHVwIEkv
TyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweDA1MDAsIHJvb3QgdGFibGUgPSAweDI0ZDg0
YjAwMCwgZG9tYWluID0gMCwgcGFnaW5nIG1vZGUgPSAzDQooWEVOKSBbMjAxMi0wOS0wNCAx
NTo1MToxN10gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHgw
NjAwLCByb290IHRhYmxlID0gMHgyNGQ4NGIwMDAsIGRvbWFpbiA9IDAsIHBhZ2luZyBtb2Rl
ID0gMw0KKFhFTikgWzIwMTItMDktMDQgMTU6NTE6MTddIEFNRC1WaTogU2V0dXAgSS9PIHBh
Z2UgdGFibGU6IGRldmljZSBpZCA9IDB4MDYwMSwgcm9vdCB0YWJsZSA9IDB4MjRkODRiMDAw
LCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMNCihYRU4pIFsyMDEyLTA5LTA0IDE1OjUx
OjE3XSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweDA3MDAs
IHJvb3QgdGFibGUgPSAweDI0ZDg0YjAwMCwgZG9tYWluID0gMCwgcGFnaW5nIG1vZGUgPSAz
DQooWEVOKSBbMjAxMi0wOS0wNCAxNTo1MToxN10gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0
YWJsZTogZGV2aWNlIGlkID0gMHgwODAwLCByb290IHRhYmxlID0gMHgyNGQ4NGIwMDAsIGRv
bWFpbiA9IDAsIHBhZ2luZyBtb2RlID0gMw0KKFhFTikgWzIwMTItMDktMDQgMTU6NTE6MTdd
IEFNRC1WaTogU2V0dXAgSS9PIHBhZ2UgdGFibGU6IGRldmljZSBpZCA9IDB4MDkwMCwgcm9v
dCB0YWJsZSA9IDB4MjRkODRiMDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMNCihY
RU4pIFsyMDEyLTA5LTA0IDE1OjUxOjE3XSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxl
OiBkZXZpY2UgaWQgPSAweDBhMDAsIHJvb3QgdGFibGUgPSAweDI0ZDg0YjAwMCwgZG9tYWlu
ID0gMCwgcGFnaW5nIG1vZGUgPSAzDQooWEVOKSBbMjAxMi0wOS0wNCAxNTo1MToxN10gQU1E
LVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHgwYTAxLCByb290IHRh
YmxlID0gMHgyNGQ4NGIwMDAsIGRvbWFpbiA9IDAsIHBhZ2luZyBtb2RlID0gMw0KKFhFTikg
WzIwMTItMDktMDQgMTU6NTE6MTddIEFNRC1WaTogU2V0dXAgSS9PIHBhZ2UgdGFibGU6IGRl
dmljZSBpZCA9IDB4MGEwMiwgcm9vdCB0YWJsZSA9IDB4MjRkODRiMDAwLCBkb21haW4gPSAw
LCBwYWdpbmcgbW9kZSA9IDMNCihYRU4pIFsyMDEyLTA5LTA0IDE1OjUxOjE3XSBBTUQtVmk6
IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweDBhMDMsIHJvb3QgdGFibGUg
PSAweDI0ZDg0YjAwMCwgZG9tYWluID0gMCwgcGFnaW5nIG1vZGUgPSAzDQooWEVOKSBbMjAx
Mi0wOS0wNCAxNTo1MToxN10gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNl
IGlkID0gMHgwYTA0LCByb290IHRhYmxlID0gMHgyNGQ4NGIwMDAsIGRvbWFpbiA9IDAsIHBh
Z2luZyBtb2RlID0gMw0KKFhFTikgWzIwMTItMDktMDQgMTU6NTE6MTddIEFNRC1WaTogU2V0
dXAgSS9PIHBhZ2UgdGFibGU6IGRldmljZSBpZCA9IDB4MGEwNSwgcm9vdCB0YWJsZSA9IDB4
MjRkODRiMDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMNCihYRU4pIFsyMDEyLTA5
LTA0IDE1OjUxOjE3XSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQg
PSAweDBhMDYsIHJvb3QgdGFibGUgPSAweDI0ZDg0YjAwMCwgZG9tYWluID0gMCwgcGFnaW5n
IG1vZGUgPSAzDQooWEVOKSBbMjAxMi0wOS0wNCAxNTo1MToxN10gQU1ELVZpOiBTZXR1cCBJ
L08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHgwYTA3LCByb290IHRhYmxlID0gMHgyNGQ4
NGIwMDAsIGRvbWFpbiA9IDAsIHBhZ2luZyBtb2RlID0gMw0KKFhFTikgWzIwMTItMDktMDQg
MTU6NTE6MTddIEFNRC1WaTogU2V0dXAgSS9PIHBhZ2UgdGFibGU6IGRldmljZSBpZCA9IDB4
MGIwMCwgcm9vdCB0YWJsZSA9IDB4MjRkODRiMDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9k
ZSA9IDMNCihYRU4pIFsyMDEyLTA5LTA0IDE1OjUxOjE3XSBTY3J1YmJpbmcgRnJlZSBSQU06
IC4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjwwPkFNRC1WaTogSU9fUEFHRV9GQVVMVDog
ZG9tYWluID0gMCwgZGV2aWNlIGlkID0gMHgwYTA2LCBmYXVsdCBhZGRyZXNzID0gMHhjMmMy
YzJjMA0KKFhFTikgWzIwMTItMDktMDQgMTU6NTE6MThdIC4uLi4uLi4uLi4uLi4uLi4uLi4u
Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uZG9uZS4NCihYRU4pIFsyMDEyLTA5LTA0IDE1OjUx
OjE5XSBJbml0aWFsIGxvdyBtZW1vcnkgdmlycSB0aHJlc2hvbGQgc2V0IGF0IDB4NDAwMCBw
YWdlcy4NCihYRU4pIFsyMDEyLTA5LTA0IDE1OjUxOjE5XSBTdGQuIExvZ2xldmVsOiBBbGwN
CihYRU4pIFsyMDEyLTA5LTA0IDE1OjUxOjE5XSBHdWVzdCBMb2dsZXZlbDogQWxsDQooWEVO
KSBbMjAxMi0wOS0wNCAxNTo1MToxOV0gWGVuIGlzIHJlbGlucXVpc2hpbmcgVkdBIGNvbnNv
bGUuDQooWEVOKSBbMjAxMi0wOS0wNCAxNTo1MToxOV0gKioqIFNlcmlhbCBpbnB1dCAtPiBE
T00wICh0eXBlICdDVFJMLWEnIHRocmVlIHRpbWVzIHRvIHN3aXRjaCBpbnB1dCB0byBYZW4p
DQooWEVOKSBbMjAxMi0wOS0wNCAxNTo1MToxOV0gRnJlZWQgMjU2a0IgaW5pdCBtZW1vcnku
DQooWEVOKSBbMjAxMi0wOS0wNCAxNTo1MToxOV0gSU9BUElDWzBdOiBTZXQgUENJIHJvdXRp
bmcgZW50cnkgKDYtOSAtPiAweDYwIC0+IElSUSA5IE1vZGU6MSBBY3RpdmU6MSkNCihYRU4p
IFsyMDEyLTA5LTA0IDE1OjUxOjE5XSB0cmFwcy5jOjI1ODQ6ZDAgRG9tYWluIGF0dGVtcHRl
ZCBXUk1TUiAwMDAwMDAwMGMwMDAwNDA4IGZyb20gMHhjMDAwMDAwMDAxMDAwMDAwIHRvIDB4
YzAwODAwMDAwMTAwMDAwMC4NCihYRU4pIFsyMDEyLTA5LTA0IDE1OjUxOjE5XSB0cmFwcy5j
OjI1ODQ6ZDAgRG9tYWluIGF0dGVtcHRlZCBXUk1TUiAwMDAwMDAwMGMwMDAwNDA5IGZyb20g
MHhjMDAwMDAwMDAxMDAwMDAwIHRvIDB4YzAwODAwMDAwMTAwMDAwMC4NCihYRU4pIFsyMDEy
LTA5LTA0IDE1OjUxOjE5XSB0cmFwcy5jOjI1ODQ6ZDAgRG9tYWluIGF0dGVtcHRlZCBXUk1T
UiAwMDAwMDAwMGMwMDEwMDA0IGZyb20gMHgwMDAwZWZmMGJkZmIxZmNlIHRvIDB4MDAwMDAw
MDAwMDAwYWJjZC4NCihYRU4pIFsyMDEyLTA5LTA0IDE1OjUxOjE5XSB0cmFwcy5jOjI1ODQ6
ZDAgRG9tYWluIGF0dGVtcHRlZCBXUk1TUiAwMDAwMDAwMGMwMDAwNDA4IGZyb20gMHhjMDAw
MDAwMDAxMDAwMDAwIHRvIDB4YzAwODAwMDAwMTAwMDAwMC4NCihYRU4pIFsyMDEyLTA5LTA0
IDE1OjUxOjE5XSB0cmFwcy5jOjI1ODQ6ZDAgRG9tYWluIGF0dGVtcHRlZCBXUk1TUiAwMDAw
MDAwMGMwMDAwNDA5IGZyb20gMHhjMDAwMDAwMDAxMDAwMDAwIHRvIDB4YzAwODAwMDAwMTAw
MDAwMC4NCihYRU4pIFsyMDEyLTA5LTA0IDE1OjUxOjE5XSB0cmFwcy5jOjI1ODQ6ZDAgRG9t
YWluIGF0dGVtcHRlZCBXUk1TUiAwMDAwMDAwMGMwMDAwNDA4IGZyb20gMHhjMDAwMDAwMDAx
MDAwMDAwIHRvIDB4YzAwODAwMDAwMTAwMDAwMC4NCihYRU4pIFsyMDEyLTA5LTA0IDE1OjUx
OjE5XSB0cmFwcy5jOjI1ODQ6ZDAgRG9tYWluIGF0dGVtcHRlZCBXUk1TUiAwMDAwMDAwMGMw
MDAwNDA5IGZyb20gMHhjMDAwMDAwMDAxMDAwMDAwIHRvIDB4YzAwODAwMDAwMTAwMDAwMC4N
CihYRU4pIFsyMDEyLTA5LTA0IDE1OjUxOjE5XSB0cmFwcy5jOjI1ODQ6ZDAgRG9tYWluIGF0
dGVtcHRlZCBXUk1TUiAwMDAwMDAwMGMwMDAwNDA4IGZyb20gMHhjMDAwMDAwMDAxMDAwMDAw
IHRvIDB4YzAwODAwMDAwMTAwMDAwMC4NCihYRU4pIFsyMDEyLTA5LTA0IDE1OjUxOjE5XSB0
cmFwcy5jOjI1ODQ6ZDAgRG9tYWluIGF0dGVtcHRlZCBXUk1TUiAwMDAwMDAwMGMwMDAwNDA5
IGZyb20gMHhjMDAwMDAwMDAxMDAwMDAwIHRvIDB4YzAwODAwMDAwMTAwMDAwMC4NCihYRU4p
IFsyMDEyLTA5LTA0IDE1OjUxOjE5XSB0cmFwcy5jOjI1ODQ6ZDAgRG9tYWluIGF0dGVtcHRl
ZCBXUk1TUiAwMDAwMDAwMGMwMDAwNDA4IGZyb20gMHhjMDAwMDAwMDAxMDAwMDAwIHRvIDB4
YzAwODAwMDAwMTAwMDAwMC4NCihYRU4pIFsyMDEyLTA5LTA0IDE1OjUxOjE5XSB0cmFwcy5j
OjI1ODQ6ZDAgRG9tYWluIGF0dGVtcHRlZCBXUk1TUiAwMDAwMDAwMGMwMDAwNDA5IGZyb20g
MHhjMDAwMDAwMDAxMDAwMDAwIHRvIDB4YzAwODAwMDAwMTAwMDAwMC4NCihYRU4pIFsyMDEy
LTA5LTA0IDE1OjUxOjE5XSB0cmFwcy5jOjI1ODQ6ZDAgRG9tYWluIGF0dGVtcHRlZCBXUk1T
UiAwMDAwMDAwMGMwMDAwNDA4IGZyb20gMHhjMDAwMDAwMDAxMDAwMDAwIHRvIDB4YzAwODAw
MDAwMTAwMDAwMC4NCihYRU4pIFsyMDEyLTA5LTA0IDE1OjUxOjE5XSB0cmFwcy5jOjI1ODQ6
ZDAgRG9tYWluIGF0dGVtcHRlZCBXUk1TUiAwMDAwMDAwMGMwMDAwNDA5IGZyb20gMHhjMDAw
MDAwMDAxMDAwMDAwIHRvIDB4YzAwODAwMDAwMTAwMDAwMC4NCihYRU4pIFsyMDEyLTA5LTA0
IDE1OjUxOjE5XSBQQ0kgYWRkIGRldmljZSAwMDAwOjAwOjAwLjANCihYRU4pIFsyMDEyLTA5
LTA0IDE1OjUxOjE5XSBQQ0kgYWRkIGRldmljZSAwMDAwOjAwOjAwLjINCihYRU4pIFsyMDEy
LTA5LTA0IDE1OjUxOjE5XSBQQ0kgYWRkIGRldmljZSAwMDAwOjAwOjAyLjANCihYRU4pIFsy
MDEyLTA5LTA0IDE1OjUxOjE5XSBQQ0kgYWRkIGRldmljZSAwMDAwOjAwOjAzLjANCihYRU4p
IFsyMDEyLTA5LTA0IDE1OjUxOjE5XSBQQ0kgYWRkIGRldmljZSAwMDAwOjAwOjA1LjANCihY
RU4pIFsyMDEyLTA5LTA0IDE1OjUxOjE5XSBQQ0kgYWRkIGRldmljZSAwMDAwOjAwOjA2LjAN
CihYRU4pIFsyMDEyLTA5LTA0IDE1OjUxOjE5XSBQQ0kgYWRkIGRldmljZSAwMDAwOjAwOjBh
LjANCihYRU4pIFsyMDEyLTA5LTA0IDE1OjUxOjE5XSBQQ0kgYWRkIGRldmljZSAwMDAwOjAw
OjBiLjANCihYRU4pIFsyMDEyLTA5LTA0IDE1OjUxOjE5XSBQQ0kgYWRkIGRldmljZSAwMDAw
OjAwOjBjLjANCihYRU4pIFsyMDEyLTA5LTA0IDE1OjUxOjE5XSBQQ0kgYWRkIGRldmljZSAw
MDAwOjAwOjBkLjANCihYRU4pIFsyMDEyLTA5LTA0IDE1OjUxOjE5XSBQQ0kgYWRkIGRldmlj
ZSAwMDAwOjAwOjExLjANCihYRU4pIFsyMDEyLTA5LTA0IDE1OjUxOjE5XSBQQ0kgYWRkIGRl
dmljZSAwMDAwOjAwOjEyLjANCihYRU4pIFsyMDEyLTA5LTA0IDE1OjUxOjE5XSBQQ0kgYWRk
IGRldmljZSAwMDAwOjAwOjEyLjINCihYRU4pIFsyMDEyLTA5LTA0IDE1OjUxOjE5XSBQQ0kg
YWRkIGRldmljZSAwMDAwOjAwOjEzLjANCihYRU4pIFsyMDEyLTA5LTA0IDE1OjUxOjE5XSBQ
Q0kgYWRkIGRldmljZSAwMDAwOjAwOjEzLjINCihYRU4pIFsyMDEyLTA5LTA0IDE1OjUxOjE5
XSBQQ0kgYWRkIGRldmljZSAwMDAwOjAwOjE0LjANCihYRU4pIFsyMDEyLTA5LTA0IDE1OjUx
OjE5XSBQQ0kgYWRkIGRldmljZSAwMDAwOjAwOjE0LjMNCihYRU4pIFsyMDEyLTA5LTA0IDE1
OjUxOjE5XSBQQ0kgYWRkIGRldmljZSAwMDAwOjAwOjE0LjQNCihYRU4pIFsyMDEyLTA5LTA0
IDE1OjUxOjE5XSBQQ0kgYWRkIGRldmljZSAwMDAwOjAwOjE0LjUNCihYRU4pIFsyMDEyLTA5
LTA0IDE1OjUxOjE5XSBQQ0kgYWRkIGRldmljZSAwMDAwOjAwOjE1LjANCihYRU4pIFsyMDEy
LTA5LTA0IDE1OjUxOjE5XSBQQ0kgYWRkIGRldmljZSAwMDAwOjAwOjE2LjANCihYRU4pIFsy
MDEyLTA5LTA0IDE1OjUxOjE5XSBQQ0kgYWRkIGRldmljZSAwMDAwOjAwOjE2LjINCihYRU4p
IFsyMDEyLTA5LTA0IDE1OjUxOjE5XSBQQ0kgYWRkIGRldmljZSAwMDAwOjAwOjE4LjANCihY
RU4pIFsyMDEyLTA5LTA0IDE1OjUxOjE5XSBQQ0kgYWRkIGRldmljZSAwMDAwOjAwOjE4LjEN
CihYRU4pIFsyMDEyLTA5LTA0IDE1OjUxOjE5XSBQQ0kgYWRkIGRldmljZSAwMDAwOjAwOjE4
LjINCihYRU4pIFsyMDEyLTA5LTA0IDE1OjUxOjE5XSBQQ0kgYWRkIGRldmljZSAwMDAwOjAw
OjE4LjMNCihYRU4pIFsyMDEyLTA5LTA0IDE1OjUxOjE5XSBQQ0kgYWRkIGRldmljZSAwMDAw
OjAwOjE4LjQNCihYRU4pIFsyMDEyLTA5LTA0IDE1OjUxOjE5XSBQQ0kgYWRkIGRldmljZSAw
MDAwOjBiOjAwLjANCihYRU4pIFsyMDEyLTA5LTA0IDE1OjUxOjE5XSBQQ0kgYWRkIGRldmlj
ZSAwMDAwOjBhOjAwLjANCihYRU4pIFsyMDEyLTA5LTA0IDE1OjUxOjE5XSBQQ0kgYWRkIGRl
dmljZSAwMDAwOjBhOjAwLjENCihYRU4pIFsyMDEyLTA5LTA0IDE1OjUxOjE5XSBQQ0kgYWRk
IGRldmljZSAwMDAwOjBhOjAwLjINCihYRU4pIFsyMDEyLTA5LTA0IDE1OjUxOjE5XSBQQ0kg
YWRkIGRldmljZSAwMDAwOjBhOjAwLjMNCihYRU4pIFsyMDEyLTA5LTA0IDE1OjUxOjE5XSBQ
Q0kgYWRkIGRldmljZSAwMDAwOjBhOjAwLjQNCihYRU4pIFsyMDEyLTA5LTA0IDE1OjUxOjE5
XSBQQ0kgYWRkIGRldmljZSAwMDAwOjBhOjAwLjUNCihYRU4pIFsyMDEyLTA5LTA0IDE1OjUx
OjE5XSBQQ0kgYWRkIGRldmljZSAwMDAwOjBhOjAwLjYNCihYRU4pIFsyMDEyLTA5LTA0IDE1
OjUxOjE5XSBQQ0kgYWRkIGRldmljZSAwMDAwOjBhOjAwLjcNCihYRU4pIFsyMDEyLTA5LTA0
IDE1OjUxOjE5XSBQQ0kgYWRkIGRldmljZSAwMDAwOjA5OjAwLjANCihYRU4pIFsyMDEyLTA5
LTA0IDE1OjUxOjE5XSBQQ0kgYWRkIGRldmljZSAwMDAwOjA4OjAwLjANCihYRU4pIFsyMDEy
LTA5LTA0IDE1OjUxOjE5XSBQQ0kgYWRkIGRldmljZSAwMDAwOjA3OjAwLjANCihYRU4pIFsy
MDEyLTA5LTA0IDE1OjUxOjE5XSBQQ0kgYWRkIGRldmljZSAwMDAwOjA2OjAwLjANCihYRU4p
IFsyMDEyLTA5LTA0IDE1OjUxOjE5XSBQQ0kgYWRkIGRldmljZSAwMDAwOjA2OjAwLjENCihY
RU4pIFsyMDEyLTA5LTA0IDE1OjUxOjE5XSBQQ0kgYWRkIGRldmljZSAwMDAwOjA1OjAwLjAN
CihYRU4pIFsyMDEyLTA5LTA0IDE1OjUxOjE5XSBQQ0kgYWRkIGRldmljZSAwMDAwOjA0OjAw
LjANCihYRU4pIFsyMDEyLTA5LTA0IDE1OjUxOjE5XSBQQ0kgYWRkIGRldmljZSAwMDAwOjA0
OjAwLjENCihYRU4pIFsyMDEyLTA5LTA0IDE1OjUxOjE5XSBQQ0kgYWRkIGRldmljZSAwMDAw
OjA0OjAwLjINCihYRU4pIFsyMDEyLTA5LTA0IDE1OjUxOjE5XSBQQ0kgYWRkIGRldmljZSAw
MDAwOjA0OjAwLjMNCihYRU4pIFsyMDEyLTA5LTA0IDE1OjUxOjE5XSBQQ0kgYWRkIGRldmlj
ZSAwMDAwOjA0OjAwLjQNCihYRU4pIFsyMDEyLTA5LTA0IDE1OjUxOjE5XSBQQ0kgYWRkIGRl
dmljZSAwMDAwOjA0OjAwLjUNCihYRU4pIFsyMDEyLTA5LTA0IDE1OjUxOjE5XSBQQ0kgYWRk
IGRldmljZSAwMDAwOjA0OjAwLjYNCihYRU4pIFsyMDEyLTA5LTA0IDE1OjUxOjE5XSBQQ0kg
YWRkIGRldmljZSAwMDAwOjA0OjAwLjcNCihYRU4pIFsyMDEyLTA5LTA0IDE1OjUxOjE5XSBQ
Q0kgYWRkIGRldmljZSAwMDAwOjAzOjA2LjANCihYRU4pIFsyMDEyLTA5LTA0IDE1OjUxOjE5
XSBJT0FQSUNbMF06IFNldCBQQ0kgcm91dGluZyBlbnRyeSAoNi04IC0+IDB4NTggLT4gSVJR
IDggTW9kZTowIEFjdGl2ZTowKQ0KKFhFTikgWzIwMTItMDktMDQgMTU6NTE6MTldIElPQVBJ
Q1swXTogU2V0IFBDSSByb3V0aW5nIGVudHJ5ICg2LTEzIC0+IDB4ODggLT4gSVJRIDEzIE1v
ZGU6MCBBY3RpdmU6MCkNCihYRU4pIFsyMDEyLTA5LTA0IDE1OjUxOjE5XSBJT0FQSUNbMV06
IFNldCBQQ0kgcm91dGluZyBlbnRyeSAoNy0yOCAtPiAweGEwIC0+IElSUSA1MiBNb2RlOjEg
QWN0aXZlOjEpDQooWEVOKSBbMjAxMi0wOS0wNCAxNTo1MToxOV0gSU9BUElDWzFdOiBTZXQg
UENJIHJvdXRpbmcgZW50cnkgKDctMjkgLT4gMHhhOCAtPiBJUlEgNTMgTW9kZToxIEFjdGl2
ZToxKQ0KKFhFTikgWzIwMTItMDktMDQgMTU6NTE6MTldIElPQVBJQ1sxXTogU2V0IFBDSSBy
b3V0aW5nIGVudHJ5ICg3LTMwIC0+IDB4YjAgLT4gSVJRIDU0IE1vZGU6MSBBY3RpdmU6MSkN
CihYRU4pIFsyMDEyLTA5LTA0IDE1OjUxOjE5XSBJT0FQSUNbMF06IFNldCBQQ0kgcm91dGlu
ZyBlbnRyeSAoNi0xNiAtPiAweGI4IC0+IElSUSAxNiBNb2RlOjEgQWN0aXZlOjEpDQooWEVO
KSBbMjAxMi0wOS0wNCAxNTo1MToxOV0gSU9BUElDWzBdOiBTZXQgUENJIHJvdXRpbmcgZW50
cnkgKDYtMTggLT4gMHhjMCAtPiBJUlEgMTggTW9kZToxIEFjdGl2ZToxKQ0KKFhFTikgWzIw
MTItMDktMDQgMTU6NTE6MTldIElPQVBJQ1swXTogU2V0IFBDSSByb3V0aW5nIGVudHJ5ICg2
LTE3IC0+IDB4YzggLT4gSVJRIDE3IE1vZGU6MSBBY3RpdmU6MSkNCihYRU4pIFsyMDEyLTA5
LTA0IDE1OjUxOjIwXSBJT0FQSUNbMV06IFNldCBQQ0kgcm91dGluZyBlbnRyeSAoNy00IC0+
IDB4ZDAgLT4gSVJRIDI4IE1vZGU6MSBBY3RpdmU6MSkNCihYRU4pIFsyMDEyLTA5LTA0IDE1
OjUxOjIwXSBJT0FQSUNbMV06IFNldCBQQ0kgcm91dGluZyBlbnRyeSAoNy01IC0+IDB4ZDgg
LT4gSVJRIDI5IE1vZGU6MSBBY3RpdmU6MSkNCihYRU4pIFsyMDEyLTA5LTA0IDE1OjUxOjIw
XSBJT0FQSUNbMV06IFNldCBQQ0kgcm91dGluZyBlbnRyeSAoNy02IC0+IDB4MjEgLT4gSVJR
IDMwIE1vZGU6MSBBY3RpdmU6MSkNCihYRU4pIFsyMDEyLTA5LTA0IDE1OjUxOjIwXSBJT0FQ
SUNbMV06IFNldCBQQ0kgcm91dGluZyBlbnRyeSAoNy03IC0+IDB4MjkgLT4gSVJRIDMxIE1v
ZGU6MSBBY3RpdmU6MSkNCihYRU4pIFsyMDEyLTA5LTA0IDE1OjUxOjIwXSBJT0FQSUNbMV06
IFNldCBQQ0kgcm91dGluZyBlbnRyeSAoNy0xNiAtPiAweDMxIC0+IElSUSA0MCBNb2RlOjEg
QWN0aXZlOjEpDQooWEVOKSBbMjAxMi0wOS0wNCAxNTo1MToyMF0gSU9BUElDWzFdOiBTZXQg
UENJIHJvdXRpbmcgZW50cnkgKDctMTcgLT4gMHgzOSAtPiBJUlEgNDEgTW9kZToxIEFjdGl2
ZToxKQ0KKFhFTikgWzIwMTItMDktMDQgMTU6NTE6MjBdIElPQVBJQ1sxXTogU2V0IFBDSSBy
b3V0aW5nIGVudHJ5ICg3LTE4IC0+IDB4NDEgLT4gSVJRIDQyIE1vZGU6MSBBY3RpdmU6MSkN
CihYRU4pIFsyMDEyLTA5LTA0IDE1OjUxOjIwXSBJT0FQSUNbMV06IFNldCBQQ0kgcm91dGlu
ZyBlbnRyeSAoNy0xOSAtPiAweDQ5IC0+IElSUSA0MyBNb2RlOjEgQWN0aXZlOjEpDQooWEVO
KSBbMjAxMi0wOS0wNCAxNTo1MToyMF0gSU9BUElDWzBdOiBTZXQgUENJIHJvdXRpbmcgZW50
cnkgKDYtMjIgLT4gMHg5OSAtPiBJUlEgMjIgTW9kZToxIEFjdGl2ZToxKQ0KKFhFTikgWzIw
MTItMDktMDQgMTU6NTE6MjBdIElPQVBJQ1sxXTogU2V0IFBDSSByb3V0aW5nIGVudHJ5ICg3
LTEyIC0+IDB4YTEgLT4gSVJRIDM2IE1vZGU6MSBBY3RpdmU6MSkNCihYRU4pIFsyMDEyLTA5
LTA0IDE1OjUxOjIwXSBJT0FQSUNbMV06IFNldCBQQ0kgcm91dGluZyBlbnRyeSAoNy0yMyAt
PiAweGE5IC0+IElSUSA0NyBNb2RlOjEgQWN0aXZlOjEpDQooWEVOKSBbMjAxMi0wOS0wNCAx
NTo1MToyMV0gSU9BUElDWzBdOiBTZXQgUENJIHJvdXRpbmcgZW50cnkgKDYtMTkgLT4gMHhi
MSAtPiBJUlEgMTkgTW9kZToxIEFjdGl2ZToxKQ0KKFhFTikgWzIwMTItMDktMDQgMTU6NTE6
MjFdIElPQVBJQ1sxXTogU2V0IFBDSSByb3V0aW5nIGVudHJ5ICg3LTIyIC0+IDB4YzEgLT4g
SVJRIDQ2IE1vZGU6MSBBY3RpdmU6MSkNCihYRU4pIFsyMDEyLTA5LTA0IDE1OjUxOjIxXSBJ
T0FQSUNbMV06IFNldCBQQ0kgcm91dGluZyBlbnRyeSAoNy0yNyAtPiAweGQxIC0+IElSUSA1
MSBNb2RlOjEgQWN0aXZlOjEpDQooWEVOKSBbMjAxMi0wOS0wNCAxNTo1MToyM10gSU9BUElD
WzFdOiBTZXQgUENJIHJvdXRpbmcgZW50cnkgKDctOSAtPiAweDIyIC0+IElSUSAzMyBNb2Rl
OjEgQWN0aXZlOjEpDQooWEVOKSBbMjAxMi0wOS0wNCAxNTo1MjoyMl0gdHJhcHMuYzoyNTg0
OmQxIERvbWFpbiBhdHRlbXB0ZWQgV1JNU1IgMDAwMDAwMDBjMDAxMDAwNCBmcm9tIDB4MDAw
MDg2NzljMDJiNDE2NSB0byAweDAwMDAwMDAwMDAwMGFiY2QuDQooWEVOKSBbMjAxMi0wOS0w
NCAxNTo1MjoyOF0gdHJhcHMuYzoyNTg0OmQyIERvbWFpbiBhdHRlbXB0ZWQgV1JNU1IgMDAw
MDAwMDBjMDAxMDAwNCBmcm9tIDB4MDAwMDQyMzQ1YTBkYTU0NSB0byAweDAwMDAwMDAwMDAw
MGFiY2QuDQooWEVOKSBbMjAxMi0wOS0wNCAxNTo1MjozNF0gdHJhcHMuYzoyNTg0OmQzIERv
bWFpbiBhdHRlbXB0ZWQgV1JNU1IgMDAwMDAwMDBjMDAxMDAwNCBmcm9tIDB4MDAwMDg2Nzlj
MDJiNDE2NSB0byAweDAwMDAwMDAwMDAwMGFiY2QuDQooWEVOKSBbMjAxMi0wOS0wNCAxNTo1
Mjo0MV0gdHJhcHMuYzoyNTg0OmQ0IERvbWFpbiBhdHRlbXB0ZWQgV1JNU1IgMDAwMDAwMDBj
MDAxMDAwNCBmcm9tIDB4MDAwMDZmYjAzOWRlNzkwMCB0byAweDAwMDAwMDAwMDAwMGFiY2Qu
DQooWEVOKSBbMjAxMi0wOS0wNCAxNTo1Mjo0N10gdHJhcHMuYzoyNTg0OmQ1IERvbWFpbiBh
dHRlbXB0ZWQgV1JNU1IgMDAwMDAwMDBjMDAxMDAwNCBmcm9tIDB4MDAwMDZmYjAzOWRlNzkw
MCB0byAweDAwMDAwMDAwMDAwMGFiY2QuDQooWEVOKSBbMjAxMi0wOS0wNCAxNTo1Mjo1M10g
dHJhcHMuYzoyNTg0OmQ2IERvbWFpbiBhdHRlbXB0ZWQgV1JNU1IgMDAwMDAwMDBjMDAxMDAw
NCBmcm9tIDB4MDAwMGExOTVjNDBmNjE4ZiB0byAweDAwMDAwMDAwMDAwMGFiY2QuDQooWEVO
KSBbMjAxMi0wOS0wNCAxNTo1Mjo1OV0gdHJhcHMuYzoyNTg0OmQ3IERvbWFpbiBhdHRlbXB0
ZWQgV1JNU1IgMDAwMDAwMDBjMDAxMDAwNCBmcm9tIDB4MDAwMGExOTVjNDBmNjE4ZiB0byAw
eDAwMDAwMDAwMDAwMGFiY2QuDQooWEVOKSBbMjAxMi0wOS0wNCAxNTo1MzowOF0gdHJhcHMu
YzoyNTg0OmQ4IERvbWFpbiBhdHRlbXB0ZWQgV1JNU1IgMDAwMDAwMDBjMDAxMDAwNCBmcm9t
IDB4MDAwMDg2NzljMDJiNDE2NSB0byAweDAwMDAwMDAwMDAwMGFiY2QuDQooWEVOKSBbMjAx
Mi0wOS0wNCAxNTo1MzoxNF0gdHJhcHMuYzoyNTg0OmQ5IERvbWFpbiBhdHRlbXB0ZWQgV1JN
U1IgMDAwMDAwMDBjMDAxMDAwNCBmcm9tIDB4MDAwMGExOTVjNDBmNjE4ZiB0byAweDAwMDAw
MDAwMDAwMGFiY2QuDQooWEVOKSBbMjAxMi0wOS0wNCAxNTo1MzoyMF0gdHJhcHMuYzoyNTg0
OmQxMCBEb21haW4gYXR0ZW1wdGVkIFdSTVNSIDAwMDAwMDAwYzAwMTAwMDQgZnJvbSAweDAw
MDBhMTk1YzQwZjYxOGYgdG8gMHgwMDAwMDAwMDAwMDBhYmNkLg0KKFhFTikgWzIwMTItMDkt
MDQgMTU6NTM6MjddIEFNRC1WaTogRGlzYWJsZTogZGV2aWNlIGlkID0gMHgwMGE0LCBkb21h
aW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMNCihYRU4pIFsyMDEyLTA5LTA0IDE1OjUzOjI3XSBB
TUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweDAwYTQsIHJvb3Qg
dGFibGUgPSAweDE4ZTBhMTAwMCwgZG9tYWluID0gMTEsIHBhZ2luZyBtb2RlID0gMw0KKFhF
TikgWzIwMTItMDktMDQgMTU6NTM6MjddIEFNRC1WaTogUmUtYXNzaWduIDAwMDA6MDM6MDYu
MCBmcm9tIGRvbTAgdG8gZG9tMTENCihYRU4pIFsyMDEyLTA5LTA0IDE1OjUzOjI3XSB0cmFw
cy5jOjI1ODQ6ZDExIERvbWFpbiBhdHRlbXB0ZWQgV1JNU1IgMDAwMDAwMDBjMDAxMDAwNCBm
cm9tIDB4MDAwMGExOTVjNDBmNjE4ZiB0byAweDAwMDAwMDAwMDAwMGFiY2QuDQooWEVOKSBb
MjAxMi0wOS0wNCAxNTo1MzozOF0gdHJhcHMuYzoyNTg0OmQxMiBEb21haW4gYXR0ZW1wdGVk
IFdSTVNSIDAwMDAwMDAwYzAwMTAwMDQgZnJvbSAweDAwMDA0MjM0NWEwZGE1NDUgdG8gMHgw
MDAwMDAwMDAwMDBhYmNkLg0KKFhFTikgWzIwMTItMDktMDQgMTU6NTM6NDRdIHRyYXBzLmM6
MjU4NDpkMTMgRG9tYWluIGF0dGVtcHRlZCBXUk1TUiAwMDAwMDAwMGMwMDEwMDA0IGZyb20g
MHgwMDAwODY3OWMwMmI0MTY1IHRvIDB4MDAwMDAwMDAwMDAwYWJjZC4NCihYRU4pIFsyMDEy
LTA5LTA0IDE1OjUzOjUxXSBBTUQtVmk6IERpc2FibGU6IGRldmljZSBpZCA9IDB4MGEwMCwg
ZG9tYWluID0gMCwgcGFnaW5nIG1vZGUgPSAzDQooWEVOKSBbMjAxMi0wOS0wNCAxNTo1Mzo1
MV0gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHgwYTAwLCBy
b290IHRhYmxlID0gMHgxZTFmYzAwMDAsIGRvbWFpbiA9IDE0LCBwYWdpbmcgbW9kZSA9IDMN
CihYRU4pIFsyMDEyLTA5LTA0IDE1OjUzOjUxXSBBTUQtVmk6IFJlLWFzc2lnbiAwMDAwOjBh
OjAwLjAgZnJvbSBkb20wIHRvIGRvbTE0DQooWEVOKSBbMjAxMi0wOS0wNCAxNTo1Mzo1MV0g
QU1ELVZpOiBEaXNhYmxlOiBkZXZpY2UgaWQgPSAweDBhMDEsIGRvbWFpbiA9IDAsIHBhZ2lu
ZyBtb2RlID0gMw0KKFhFTikgWzIwMTItMDktMDQgMTU6NTM6NTFdIEFNRC1WaTogU2V0dXAg
SS9PIHBhZ2UgdGFibGU6IGRldmljZSBpZCA9IDB4MGEwMSwgcm9vdCB0YWJsZSA9IDB4MWUx
ZmMwMDAwLCBkb21haW4gPSAxNCwgcGFnaW5nIG1vZGUgPSAzDQooWEVOKSBbMjAxMi0wOS0w
NCAxNTo1Mzo1MV0gQU1ELVZpOiBSZS1hc3NpZ24gMDAwMDowYTowMC4xIGZyb20gZG9tMCB0
byBkb20xNA0KKFhFTikgWzIwMTItMDktMDQgMTU6NTM6NTFdIEFNRC1WaTogRGlzYWJsZTog
ZGV2aWNlIGlkID0gMHgwYTAyLCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMNCihYRU4p
IFsyMDEyLTA5LTA0IDE1OjUzOjUxXSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBk
ZXZpY2UgaWQgPSAweDBhMDIsIHJvb3QgdGFibGUgPSAweDFlMWZjMDAwMCwgZG9tYWluID0g
MTQsIHBhZ2luZyBtb2RlID0gMw0KKFhFTikgWzIwMTItMDktMDQgMTU6NTM6NTFdIEFNRC1W
aTogUmUtYXNzaWduIDAwMDA6MGE6MDAuMiBmcm9tIGRvbTAgdG8gZG9tMTQNCihYRU4pIFsy
MDEyLTA5LTA0IDE1OjUzOjUxXSBBTUQtVmk6IERpc2FibGU6IGRldmljZSBpZCA9IDB4MGEw
MywgZG9tYWluID0gMCwgcGFnaW5nIG1vZGUgPSAzDQooWEVOKSBbMjAxMi0wOS0wNCAxNTo1
Mzo1MV0gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHgwYTAz
LCByb290IHRhYmxlID0gMHgxZTFmYzAwMDAsIGRvbWFpbiA9IDE0LCBwYWdpbmcgbW9kZSA9
IDMNCihYRU4pIFsyMDEyLTA5LTA0IDE1OjUzOjUxXSBBTUQtVmk6IFJlLWFzc2lnbiAwMDAw
OjBhOjAwLjMgZnJvbSBkb20wIHRvIGRvbTE0DQooWEVOKSBbMjAxMi0wOS0wNCAxNTo1Mzo1
MV0gQU1ELVZpOiBEaXNhYmxlOiBkZXZpY2UgaWQgPSAweDBhMDQsIGRvbWFpbiA9IDAsIHBh
Z2luZyBtb2RlID0gMw0KKFhFTikgWzIwMTItMDktMDQgMTU6NTM6NTFdIEFNRC1WaTogU2V0
dXAgSS9PIHBhZ2UgdGFibGU6IGRldmljZSBpZCA9IDB4MGEwNCwgcm9vdCB0YWJsZSA9IDB4
MWUxZmMwMDAwLCBkb21haW4gPSAxNCwgcGFnaW5nIG1vZGUgPSAzDQooWEVOKSBbMjAxMi0w
OS0wNCAxNTo1Mzo1MV0gQU1ELVZpOiBSZS1hc3NpZ24gMDAwMDowYTowMC40IGZyb20gZG9t
MCB0byBkb20xNA0KKFhFTikgWzIwMTItMDktMDQgMTU6NTM6NTFdIEFNRC1WaTogRGlzYWJs
ZTogZGV2aWNlIGlkID0gMHgwYTA1LCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMNCihY
RU4pIFsyMDEyLTA5LTA0IDE1OjUzOjUxXSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxl
OiBkZXZpY2UgaWQgPSAweDBhMDUsIHJvb3QgdGFibGUgPSAweDFlMWZjMDAwMCwgZG9tYWlu
ID0gMTQsIHBhZ2luZyBtb2RlID0gMw0KKFhFTikgWzIwMTItMDktMDQgMTU6NTM6NTFdIEFN
RC1WaTogUmUtYXNzaWduIDAwMDA6MGE6MDAuNSBmcm9tIGRvbTAgdG8gZG9tMTQNCihYRU4p
IFsyMDEyLTA5LTA0IDE1OjUzOjUxXSBBTUQtVmk6IERpc2FibGU6IGRldmljZSBpZCA9IDB4
MGEwNiwgZG9tYWluID0gMCwgcGFnaW5nIG1vZGUgPSAzDQooWEVOKSBbMjAxMi0wOS0wNCAx
NTo1Mzo1MV0gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHgw
YTA2LCByb290IHRhYmxlID0gMHgxZTFmYzAwMDAsIGRvbWFpbiA9IDE0LCBwYWdpbmcgbW9k
ZSA9IDMNCihYRU4pIFsyMDEyLTA5LTA0IDE1OjUzOjUxXSBBTUQtVmk6IFJlLWFzc2lnbiAw
MDAwOjBhOjAwLjYgZnJvbSBkb20wIHRvIGRvbTE0DQooWEVOKSBbMjAxMi0wOS0wNCAxNTo1
Mzo1MV0gQU1ELVZpOiBEaXNhYmxlOiBkZXZpY2UgaWQgPSAweDBhMDcsIGRvbWFpbiA9IDAs
IHBhZ2luZyBtb2RlID0gMw0KKFhFTikgWzIwMTItMDktMDQgMTU6NTM6NTFdIEFNRC1WaTog
U2V0dXAgSS9PIHBhZ2UgdGFibGU6IGRldmljZSBpZCA9IDB4MGEwNywgcm9vdCB0YWJsZSA9
IDB4MWUxZmMwMDAwLCBkb21haW4gPSAxNCwgcGFnaW5nIG1vZGUgPSAzDQooWEVOKSBbMjAx
Mi0wOS0wNCAxNTo1Mzo1MV0gQU1ELVZpOiBSZS1hc3NpZ24gMDAwMDowYTowMC43IGZyb20g
ZG9tMCB0byBkb20xNA0KKFhFTikgWzIwMTItMDktMDQgMTU6NTM6NTFdIEFNRC1WaTogRGlz
YWJsZTogZGV2aWNlIGlkID0gMHgwNzAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMN
CihYRU4pIFsyMDEyLTA5LTA0IDE1OjUzOjUxXSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRh
YmxlOiBkZXZpY2UgaWQgPSAweDA3MDAsIHJvb3QgdGFibGUgPSAweDFlMWZjMDAwMCwgZG9t
YWluID0gMTQsIHBhZ2luZyBtb2RlID0gMw0KKFhFTikgWzIwMTItMDktMDQgMTU6NTM6NTFd
IEFNRC1WaTogUmUtYXNzaWduIDAwMDA6MDc6MDAuMCBmcm9tIGRvbTAgdG8gZG9tMTQNCihY
RU4pIFsyMDEyLTA5LTA0IDE1OjUzOjUxXSB0cmFwcy5jOjI1ODQ6ZDE0IERvbWFpbiBhdHRl
bXB0ZWQgV1JNU1IgMDAwMDAwMDBjMDAxMDAwNCBmcm9tIDB4MDAwMDQyMzQ1YTBkYTU0NSB0
byAweDAwMDAwMDAwMDAwMGFiY2QuDQooWEVOKSBbMjAxMi0wOS0wNCAxNTo1NDowMF0gSFZN
MTU6IEhWTSBMb2FkZXINCihYRU4pIFsyMDEyLTA5LTA0IDE1OjU0OjAwXSBIVk0xNTogRGV0
ZWN0ZWQgWGVuIHY0LjIuMC1yYzQtcHJlDQooWEVOKSBbMjAxMi0wOS0wNCAxNTo1NDowMF0g
SFZNMTU6IFhlbmJ1cyByaW5ncyBAMHhmZWZmYzAwMCwgZXZlbnQgY2hhbm5lbCA0DQooWEVO
KSBbMjAxMi0wOS0wNCAxNTo1NDowMF0gSFZNMTU6IFN5c3RlbSByZXF1ZXN0ZWQgUk9NQklP
Uw0KKFhFTikgWzIwMTItMDktMDQgMTU6NTQ6MDBdIEhWTTE1OiBDUFUgc3BlZWQgaXMgMzIw
MCBNSHoNCihYRU4pIFsyMDEyLTA5LTA0IDE1OjU0OjAwXSBpcnEuYzoyNzA6IERvbTE1IFBD
SSBsaW5rIDAgY2hhbmdlZCAwIC0+IDUNCihYRU4pIFsyMDEyLTA5LTA0IDE1OjU0OjAwXSBI
Vk0xNTogUENJLUlTQSBsaW5rIDAgcm91dGVkIHRvIElSUTUNCihYRU4pIFsyMDEyLTA5LTA0
IDE1OjU0OjAwXSBpcnEuYzoyNzA6IERvbTE1IFBDSSBsaW5rIDEgY2hhbmdlZCAwIC0+IDEw
DQooWEVOKSBbMjAxMi0wOS0wNCAxNTo1NDowMF0gSFZNMTU6IFBDSS1JU0EgbGluayAxIHJv
dXRlZCB0byBJUlExMA0KKFhFTikgWzIwMTItMDktMDQgMTU6NTQ6MDBdIGlycS5jOjI3MDog
RG9tMTUgUENJIGxpbmsgMiBjaGFuZ2VkIDAgLT4gMTENCihYRU4pIFsyMDEyLTA5LTA0IDE1
OjU0OjAwXSBIVk0xNTogUENJLUlTQSBsaW5rIDIgcm91dGVkIHRvIElSUTExDQooWEVOKSBb
MjAxMi0wOS0wNCAxNTo1NDowMF0gaXJxLmM6MjcwOiBEb20xNSBQQ0kgbGluayAzIGNoYW5n
ZWQgMCAtPiA1DQooWEVOKSBbMjAxMi0wOS0wNCAxNTo1NDowMF0gSFZNMTU6IFBDSS1JU0Eg
bGluayAzIHJvdXRlZCB0byBJUlE1DQooWEVOKSBbMjAxMi0wOS0wNCAxNTo1NDowMF0gSFZN
MTU6IHBjaSBkZXYgMDE6MiBJTlRELT5JUlE1DQooWEVOKSBbMjAxMi0wOS0wNCAxNTo1NDow
MF0gSFZNMTU6IHBjaSBkZXYgMDE6MyBJTlRBLT5JUlExMA0KKFhFTikgWzIwMTItMDktMDQg
MTU6NTQ6MDBdIEhWTTE1OiBwY2kgZGV2IDAzOjAgSU5UQS0+SVJRNQ0KKFhFTikgWzIwMTIt
MDktMDQgMTU6NTQ6MDBdIEhWTTE1OiBwY2kgZGV2IDA0OjAgSU5UQS0+SVJRNQ0KKFhFTikg
WzIwMTItMDktMDQgMTU6NTQ6MDFdIEhWTTE1OiBwY2kgZGV2IDAyOjAgYmFyIDEwIHNpemUg
MDIwMDAwMDA6IGYwMDAwMDA4DQooWEVOKSBbMjAxMi0wOS0wNCAxNTo1NDowMV0gSFZNMTU6
IHBjaSBkZXYgMDM6MCBiYXIgMTQgc2l6ZSAwMTAwMDAwMDogZjIwMDAwMDgNCihYRU4pIFsy
MDEyLTA5LTA0IDE1OjU0OjAxXSBIVk0xNTogcGNpIGRldiAwNDowIGJhciAxMCBzaXplIDAw
MDIwMDAwOiBmMzAwMDAwMA0KKFhFTikgWzIwMTItMDktMDQgMTU6NTQ6MDFdIEhWTTE1OiBw
Y2kgZGV2IDAyOjAgYmFyIDE0IHNpemUgMDAwMDEwMDA6IGYzMDIwMDAwDQooWEVOKSBbMjAx
Mi0wOS0wNCAxNTo1NDowMV0gSFZNMTU6IHBjaSBkZXYgMDM6MCBiYXIgMTAgc2l6ZSAwMDAw
MDEwMDogMDAwMGMwMDENCihYRU4pIFsyMDEyLTA5LTA0IDE1OjU0OjAxXSBIVk0xNTogcGNp
IGRldiAwNDowIGJhciAxNCBzaXplIDAwMDAwMDQwOiAwMDAwYzEwMQ0KKFhFTikgWzIwMTIt
MDktMDQgMTU6NTQ6MDFdIEhWTTE1OiBwY2kgZGV2IDAxOjIgYmFyIDIwIHNpemUgMDAwMDAw
MjA6IDAwMDBjMTQxDQooWEVOKSBbMjAxMi0wOS0wNCAxNTo1NDowMV0gSFZNMTU6IHBjaSBk
ZXYgMDE6MSBiYXIgMjAgc2l6ZSAwMDAwMDAxMDogMDAwMGMxNjENCihYRU4pIFsyMDEyLTA5
LTA0IDE1OjU0OjAxXSBIVk0xNTogTXVsdGlwcm9jZXNzb3IgaW5pdGlhbGlzYXRpb246DQoo
WEVOKSBbMjAxMi0wOS0wNCAxNTo1NDowMV0gSFZNMTU6ICAtIENQVTAgLi4uIDQ4LWJpdCBw
aHlzIC4uLiBmaXhlZCBNVFJScyAuLi4gdmFyIE1UUlJzIFsyLzhdIC4uLiBkb25lLg0KKFhF
TikgWzIwMTItMDktMDQgMTU6NTQ6MDFdIEhWTTE1OiAgLSBDUFUxIC4uLiA0OC1iaXQgcGh5
cyAuLi4gZml4ZWQgTVRSUnMgLi4uIHZhciBNVFJScyBbMi84XSAuLi4gZG9uZS4NCihYRU4p
IFsyMDEyLTA5LTA0IDE1OjU0OjAxXSBIVk0xNTogVGVzdGluZyBIVk0gZW52aXJvbm1lbnQ6
DQooWEVOKSBbMjAxMi0wOS0wNCAxNTo1NDowMV0gSFZNMTU6ICAtIFJFUCBJTlNCIGFjcm9z
cyBwYWdlIGJvdW5kYXJpZXMgLi4uIHBhc3NlZA0KKFhFTikgWzIwMTItMDktMDQgMTU6NTQ6
MDFdIEhWTTE1OiAgLSBHUyBiYXNlIE1TUnMgYW5kIFNXQVBHUyAuLi4gcGFzc2VkDQooWEVO
KSBbMjAxMi0wOS0wNCAxNTo1NDowMV0gSFZNMTU6IFBhc3NlZCAyIG9mIDIgdGVzdHMNCihY
RU4pIFsyMDEyLTA5LTA0IDE1OjU0OjAxXSBIVk0xNTogV3JpdGluZyBTTUJJT1MgdGFibGVz
IC4uLg0KKFhFTikgWzIwMTItMDktMDQgMTU6NTQ6MDFdIEhWTTE1OiBMb2FkaW5nIFJPTUJJ
T1MgLi4uDQooWEVOKSBbMjAxMi0wOS0wNCAxNTo1NDowMV0gSFZNMTU6IDk2NjAgYnl0ZXMg
b2YgUk9NQklPUyBoaWdoLW1lbW9yeSBleHRlbnNpb25zOg0KKFhFTikgWzIwMTItMDktMDQg
MTU6NTQ6MDFdIEhWTTE1OiAgIFJlbG9jYXRpbmcgdG8gMHhmYzAwMTAwMC0weGZjMDAzNWJj
IC4uLiBkb25lDQooWEVOKSBbMjAxMi0wOS0wNCAxNTo1NDowMV0gSFZNMTU6IENyZWF0aW5n
IE1QIHRhYmxlcyAuLi4NCihYRU4pIFsyMDEyLTA5LTA0IDE1OjU0OjAxXSBIVk0xNTogTG9h
ZGluZyBDaXJydXMgVkdBQklPUyAuLi4NCihYRU4pIFsyMDEyLTA5LTA0IDE1OjU0OjAxXSBI
Vk0xNTogTG9hZGluZyBQQ0kgT3B0aW9uIFJPTSAuLi4NCihYRU4pIFsyMDEyLTA5LTA0IDE1
OjU0OjAxXSBIVk0xNTogIC0gTWFudWZhY3R1cmVyOiBodHRwOi8vaXB4ZS5vcmcNCihYRU4p
IFsyMDEyLTA5LTA0IDE1OjU0OjAxXSBIVk0xNTogIC0gUHJvZHVjdCBuYW1lOiBpUFhFDQoo
WEVOKSBbMjAxMi0wOS0wNCAxNTo1NDowMV0gSFZNMTU6IE9wdGlvbiBST01zOg0KKFhFTikg
WzIwMTItMDktMDQgMTU6NTQ6MDFdIEhWTTE1OiAgYzAwMDAtYzhmZmY6IFZHQSBCSU9TDQoo
WEVOKSBbMjAxMi0wOS0wNCAxNTo1NDowMV0gSFZNMTU6ICBjOTAwMC1kOWZmZjogRXRoZXJi
b290IFJPTQ0KKFhFTikgWzIwMTItMDktMDQgMTU6NTQ6MDFdIEhWTTE1OiBMb2FkaW5nIEFD
UEkgLi4uDQooWEVOKSBbMjAxMi0wOS0wNCAxNTo1NDowMV0gSFZNMTU6IHZtODYgVFNTIGF0
IGZjMDBmNjgwDQooWEVOKSBbMjAxMi0wOS0wNCAxNTo1NDowMV0gSFZNMTU6IEJJT1MgbWFw
Og0KKFhFTikgWzIwMTItMDktMDQgMTU6NTQ6MDFdIEhWTTE1OiAgZjAwMDAtZmZmZmY6IE1h
aW4gQklPUw0KKFhFTikgWzIwMTItMDktMDQgMTU6NTQ6MDFdIEhWTTE1OiBFODIwIHRhYmxl
Og0KKFhFTikgWzIwMTItMDktMDQgMTU6NTQ6MDFdIEhWTTE1OiAgWzAwXTogMDAwMDAwMDA6
MDAwMDAwMDAgLSAwMDAwMDAwMDowMDA5ZTAwMDogUkFNDQooWEVOKSBbMjAxMi0wOS0wNCAx
NTo1NDowMV0gSFZNMTU6ICBbMDFdOiAwMDAwMDAwMDowMDA5ZTAwMCAtIDAwMDAwMDAwOjAw
MGEwMDAwOiBSRVNFUlZFRA0KKFhFTikgWzIwMTItMDktMDQgMTU6NTQ6MDFdIEhWTTE1OiAg
SE9MRTogMDAwMDAwMDA6MDAwYTAwMDAgLSAwMDAwMDAwMDowMDBlMDAwMA0KKFhFTikgWzIw
MTItMDktMDQgMTU6NTQ6MDFdIEhWTTE1OiAgWzAyXTogMDAwMDAwMDA6MDAwZTAwMDAgLSAw
MDAwMDAwMDowMDEwMDAwMDogUkVTRVJWRUQNCihYRU4pIFsyMDEyLTA5LTA0IDE1OjU0OjAx
XSBIVk0xNTogIFswM106IDAwMDAwMDAwOjAwMTAwMDAwIC0gMDAwMDAwMDA6MWY4MDAwMDA6
IFJBTQ0KKFhFTikgWzIwMTItMDktMDQgMTU6NTQ6MDFdIEhWTTE1OiAgSE9MRTogMDAwMDAw
MDA6MWY4MDAwMDAgLSAwMDAwMDAwMDpmYzAwMDAwMA0KKFhFTikgWzIwMTItMDktMDQgMTU6
NTQ6MDFdIEhWTTE1OiAgWzA0XTogMDAwMDAwMDA6ZmMwMDAwMDAgLSAwMDAwMDAwMTowMDAw
MDAwMDogUkVTRVJWRUQNCihYRU4pIFsyMDEyLTA5LTA0IDE1OjU0OjAxXSBIVk0xNTogSW52
b2tpbmcgUk9NQklPUyAuLi4NCihYRU4pIFsyMDEyLTA5LTA0IDE1OjU0OjAxXSBIVk0xNTog
JFJldmlzaW9uOiAxLjIyMSAkICREYXRlOiAyMDA4LzEyLzA3IDE3OjMyOjI5ICQNCihYRU4p
IFsyMDEyLTA5LTA0IDE1OjU0OjAxXSBzdGR2Z2EuYzoxNDc6ZDE1IGVudGVyaW5nIHN0ZHZn
YSBhbmQgY2FjaGluZyBtb2Rlcw0KKFhFTikgWzIwMTItMDktMDQgMTU6NTQ6MDFdIEhWTTE1
OiBWR0FCaW9zICRJZDogdmdhYmlvcy5jLHYgMS42NyAyMDA4LzAxLzI3IDA5OjQ0OjEyIHZy
dXBwZXJ0IEV4cCAkDQooWEVOKSBbMjAxMi0wOS0wNCAxNTo1NDowMV0gSFZNMTU6IEJvY2hz
IEJJT1MgLSBidWlsZDogMDYvMjMvOTkNCihYRU4pIFsyMDEyLTA5LTA0IDE1OjU0OjAxXSBI
Vk0xNTogJFJldmlzaW9uOiAxLjIyMSAkICREYXRlOiAyMDA4LzEyLzA3IDE3OjMyOjI5ICQN
CihYRU4pIFsyMDEyLTA5LTA0IDE1OjU0OjAxXSBIVk0xNTogT3B0aW9uczogYXBtYmlvcyBw
Y2liaW9zIGVsdG9yaXRvIFBNTSANCihYRU4pIFsyMDEyLTA5LTA0IDE1OjU0OjAxXSBIVk0x
NTogDQooWEVOKSBbMjAxMi0wOS0wNCAxNTo1NDowMV0gSFZNMTU6IGF0YTAtMDogUENIUz0x
NjM4My8xNi82MyB0cmFuc2xhdGlvbj1sYmEgTENIUz0xMDI0LzI1NS82Mw0KKFhFTikgWzIw
MTItMDktMDQgMTU6NTQ6MDFdIEhWTTE1OiBhdGEwIG1hc3RlcjogUUVNVSBIQVJERElTSyBB
VEEtNyBIYXJkLURpc2sgKDU3MjQ0IE1CeXRlcykNCihYRU4pIFsyMDEyLTA5LTA0IDE1OjU0
OjAyXSBIVk0xNTogSURFIHRpbWUgb3V0DQooWEVOKSBbMjAxMi0wOS0wNCAxNTo1NDowMl0g
SFZNMTU6IGF0YTEgbWFzdGVyOiBRRU1VIERWRC1ST00gQVRBUEktNCBDRC1Sb20vRFZELVJv
bQ0KKFhFTikgWzIwMTItMDktMDQgMTU6NTQ6MDRdIEhWTTE1OiBJREUgdGltZSBvdXQNCihY
RU4pIFsyMDEyLTA5LTA0IDE1OjU0OjA0XSBIVk0xNTogDQooWEVOKSBbMjAxMi0wOS0wNCAx
NTo1NDowNF0gSFZNMTU6IA0KKFhFTikgWzIwMTItMDktMDQgMTU6NTQ6MDRdIEhWTTE1OiAN
CihYRU4pIFsyMDEyLTA5LTA0IDE1OjU0OjA0XSBIVk0xNTogUHJlc3MgRjEyIGZvciBib290
IG1lbnUuDQooWEVOKSBbMjAxMi0wOS0wNCAxNTo1NDowNF0gSFZNMTU6IA0KKFhFTikgWzIw
MTItMDktMDQgMTU6NTQ6MDRdIEhWTTE1OiBCb290aW5nIGZyb20gSGFyZCBEaXNrLi4uDQoo
WEVOKSBbMjAxMi0wOS0wNCAxNTo1NDowNF0gSFZNMTU6IEJvb3RpbmcgZnJvbSAwMDAwOjdj
MDANCihYRU4pIFsyMDEyLTA5LTA0IDE1OjU0OjMyXSBpcnEuYzoyNzA6IERvbTE1IFBDSSBs
aW5rIDAgY2hhbmdlZCA1IC0+IDANCihYRU4pIFsyMDEyLTA5LTA0IDE1OjU0OjMyXSBpcnEu
YzoyNzA6IERvbTE1IFBDSSBsaW5rIDEgY2hhbmdlZCAxMCAtPiAwDQooWEVOKSBbMjAxMi0w
OS0wNCAxNTo1NDozMl0gaXJxLmM6MjcwOiBEb20xNSBQQ0kgbGluayAyIGNoYW5nZWQgMTEg
LT4gMA0KKFhFTikgWzIwMTItMDktMDQgMTU6NTQ6MzJdIGlycS5jOjI3MDogRG9tMTUgUENJ
IGxpbmsgMyBjaGFuZ2VkIDUgLT4gMA0KKFhFTikgWzIwMTItMDktMDQgMTU6NTQ6MzNdIGh2
bS5jOjI0MzU6ZDE1IGd1ZXN0IGF0dGVtcHRlZCB3cml0ZSB0byByZWFkLW9ubHkgbWVtb3J5
IHBhZ2UuIGdmbj0weGRjLCBtZm49MHhhNGEwYQ0KKFhFTikgWzIwMTItMDktMDQgMTU6NTQ6
MzNdIGh2bS5jOjI0MzU6ZDE1IGd1ZXN0IGF0dGVtcHRlZCB3cml0ZSB0byByZWFkLW9ubHkg
bWVtb3J5IHBhZ2UuIGdmbj0weGRkLCBtZm49MHhhNGEwOQ0KKFhFTikgWzIwMTItMDktMDQg
MTU6NTQ6MzNdIGh2bS5jOjI0MzU6ZDE1IGd1ZXN0IGF0dGVtcHRlZCB3cml0ZSB0byByZWFk
LW9ubHkgbWVtb3J5IHBhZ2UuIGdmbj0weGRlLCBtZm49MHhhNGEwOA0KKFhFTikgWzIwMTIt
MDktMDQgMTU6NTQ6MzNdIGh2bS5jOjI0MzU6ZDE1IGd1ZXN0IGF0dGVtcHRlZCB3cml0ZSB0
byByZWFkLW9ubHkgbWVtb3J5IHBhZ2UuIGdmbj0weGRkLCBtZm49MHhhNGEwOQ0KKFhFTikg
WzIwMTItMDktMDQgMTU6NTQ6MzNdIGh2bS5jOjI0MzU6ZDE1IGd1ZXN0IGF0dGVtcHRlZCB3
cml0ZSB0byByZWFkLW9ubHkgbWVtb3J5IHBhZ2UuIGdmbj0weGRjLCBtZm49MHhhNGEwYQ0K
KFhFTikgWzIwMTItMDktMDQgMTU6NTQ6MzNdIGh2bS5jOjI0MzU6ZDE1IGd1ZXN0IGF0dGVt
cHRlZCB3cml0ZSB0byByZWFkLW9ubHkgbWVtb3J5IHBhZ2UuIGdmbj0weGRlLCBtZm49MHhh
NGEwOA0KKFhFTikgWzIwMTItMDktMDQgMTU6NTQ6MzNdIGh2bS5jOjI0MzU6ZDE1IGd1ZXN0
IGF0dGVtcHRlZCB3cml0ZSB0byByZWFkLW9ubHkgbWVtb3J5IHBhZ2UuIGdmbj0weGRkLCBt
Zm49MHhhNGEwOQ0KKFhFTikgWzIwMTItMDktMDQgMTU6NTQ6MzNdIGh2bS5jOjI0MzU6ZDE1
IGd1ZXN0IGF0dGVtcHRlZCB3cml0ZSB0byByZWFkLW9ubHkgbWVtb3J5IHBhZ2UuIGdmbj0w
eGRlLCBtZm49MHhhNGEwOA0KKFhFTikgWzIwMTItMDktMDQgMTU6NTQ6MzNdIGh2bS5jOjI0
MzU6ZDE1IGd1ZXN0IGF0dGVtcHRlZCB3cml0ZSB0byByZWFkLW9ubHkgbWVtb3J5IHBhZ2Uu
IGdmbj0weGRjLCBtZm49MHhhNGEwYQ0KKFhFTikgWzIwMTItMDktMDQgMTU6NTQ6MzNdIGh2
bS5jOjI0MzU6ZDE1IGd1ZXN0IGF0dGVtcHRlZCB3cml0ZSB0byByZWFkLW9ubHkgbWVtb3J5
IHBhZ2UuIGdmbj0weGRkLCBtZm49MHhhNGEwOQ0KKFhFTikgWzIwMTItMDktMDQgMTU6NTQ6
MzNdIGh2bS5jOjI0MzU6ZDE1IGd1ZXN0IGF0dGVtcHRlZCB3cml0ZSB0byByZWFkLW9ubHkg
bWVtb3J5IHBhZ2UuIGdmbj0weGRjLCBtZm49MHhhNGEwYQ0KKFhFTikgWzIwMTItMDktMDQg
MTU6NTQ6MzNdIGh2bS5jOjI0MzU6ZDE1IGd1ZXN0IGF0dGVtcHRlZCB3cml0ZSB0byByZWFk
LW9ubHkgbWVtb3J5IHBhZ2UuIGdmbj0weGRkLCBtZm49MHhhNGEwOQ0KKFhFTikgWzIwMTIt
MDktMDQgMTU6NTQ6MzNdIGh2bS5jOjI0MzU6ZDE1IGd1ZXN0IGF0dGVtcHRlZCB3cml0ZSB0
byByZWFkLW9ubHkgbWVtb3J5IHBhZ2UuIGdmbj0weGRlLCBtZm49MHhhNGEwOA0KKFhFTikg
WzIwMTItMDktMDQgMTU6NTQ6MzNdIGh2bS5jOjI0MzU6ZDE1IGd1ZXN0IGF0dGVtcHRlZCB3
cml0ZSB0byByZWFkLW9ubHkgbWVtb3J5IHBhZ2UuIGdmbj0weGRkLCBtZm49MHhhNGEwOQ0K
KFhFTikgWzIwMTItMDktMDQgMTU6NTQ6MzNdIGh2bS5jOjI0MzU6ZDE1IGd1ZXN0IGF0dGVt
cHRlZCB3cml0ZSB0byByZWFkLW9ubHkgbWVtb3J5IHBhZ2UuIGdmbj0weGRjLCBtZm49MHhh
NGEwYQ0KKFhFTikgWzIwMTItMDktMDQgMTU6NTQ6MzNdIGh2bS5jOjI0MzU6ZDE1IGd1ZXN0
IGF0dGVtcHRlZCB3cml0ZSB0byByZWFkLW9ubHkgbWVtb3J5IHBhZ2UuIGdmbj0weGRkLCBt
Zm49MHhhNGEwOQ0KKFhFTikgWzIwMTItMDktMDQgMTU6NTQ6MzNdIGh2bS5jOjI0MzU6ZDE1
IGd1ZXN0IGF0dGVtcHRlZCB3cml0ZSB0byByZWFkLW9ubHkgbWVtb3J5IHBhZ2UuIGdmbj0w
eGRjLCBtZm49MHhhNGEwYQ0KKFhFTikgWzIwMTItMDktMDQgMTU6NTQ6MzNdIGh2bS5jOjI0
MzU6ZDE1IGd1ZXN0IGF0dGVtcHRlZCB3cml0ZSB0byByZWFkLW9ubHkgbWVtb3J5IHBhZ2Uu
IGdmbj0weGRkLCBtZm49MHhhNGEwOQ0KKFhFTikgWzIwMTItMDktMDQgMTU6NTQ6MzVdIGh2
bS5jOjI0MzU6ZDE1IGd1ZXN0IGF0dGVtcHRlZCB3cml0ZSB0byByZWFkLW9ubHkgbWVtb3J5
IHBhZ2UuIGdmbj0weGM5LCBtZm49MHhhNGExZA0KKFhFTikgWzIwMTItMDktMDQgMTU6NTQ6
MzVdIGh2bS5jOjI0MzU6ZDE1IGd1ZXN0IGF0dGVtcHRlZCB3cml0ZSB0byByZWFkLW9ubHkg
bWVtb3J5IHBhZ2UuIGdmbj0weGNiLCBtZm49MHhhNGExYg0KKFhFTikgWzIwMTItMDktMDQg
MTU6NTQ6MzVdIGh2bS5jOjI0MzU6ZDE1IGd1ZXN0IGF0dGVtcHRlZCB3cml0ZSB0byByZWFk
LW9ubHkgbWVtb3J5IHBhZ2UuIGdmbj0weGNkLCBtZm49MHhhNGExOQ0KKFhFTikgWzIwMTIt
MDktMDQgMTU6NTQ6MzVdIGh2bS5jOjI0MzU6ZDE1IGd1ZXN0IGF0dGVtcHRlZCB3cml0ZSB0
byByZWFkLW9ubHkgbWVtb3J5IHBhZ2UuIGdmbj0weGNmLCBtZm49MHhhNGExNw0KKFhFTikg
WzIwMTItMDktMDQgMTU6NTQ6MzVdIGh2bS5jOjI0MzU6ZDE1IGd1ZXN0IGF0dGVtcHRlZCB3
cml0ZSB0byByZWFkLW9ubHkgbWVtb3J5IHBhZ2UuIGdmbj0weGQxLCBtZm49MHhhNGExNQ0K
KFhFTikgWzIwMTItMDktMDQgMTU6NTQ6MzVdIGh2bS5jOjI0MzU6ZDE1IGd1ZXN0IGF0dGVt
cHRlZCB3cml0ZSB0byByZWFkLW9ubHkgbWVtb3J5IHBhZ2UuIGdmbj0weGQzLCBtZm49MHhh
NGExMw0KKFhFTikgWzIwMTItMDktMDQgMTU6NTQ6MzVdIGh2bS5jOjI0MzU6ZDE1IGd1ZXN0
IGF0dGVtcHRlZCB3cml0ZSB0byByZWFkLW9ubHkgbWVtb3J5IHBhZ2UuIGdmbj0weGQ1LCBt
Zm49MHhhNGExMQ0KKFhFTikgWzIwMTItMDktMDQgMTU6NTQ6MzVdIGh2bS5jOjI0MzU6ZDE1
IGd1ZXN0IGF0dGVtcHRlZCB3cml0ZSB0byByZWFkLW9ubHkgbWVtb3J5IHBhZ2UuIGdmbj0w
eGQ3LCBtZm49MHhhNGEwZg0KKFhFTikgWzIwMTItMDktMDQgMTU6NTQ6MzVdIGh2bS5jOjI0
MzU6ZDE1IGd1ZXN0IGF0dGVtcHRlZCB3cml0ZSB0byByZWFkLW9ubHkgbWVtb3J5IHBhZ2Uu
IGdmbj0weGQ5LCBtZm49MHhhNGEwZA0KKFhFTikgWzIwMTItMDktMDQgMTU6NTQ6MzVdIGh2
bS5jOjI0MzU6ZDE1IGd1ZXN0IGF0dGVtcHRlZCB3cml0ZSB0byByZWFkLW9ubHkgbWVtb3J5
IHBhZ2UuIGdmbj0weGRiLCBtZm49MHhhNGEwYg0KKFhFTikgWzIwMTItMDktMDQgMTU6NTQ6
MzVdIGh2bS5jOjI0MzU6ZDE1IGd1ZXN0IGF0dGVtcHRlZCB3cml0ZSB0byByZWFkLW9ubHkg
bWVtb3J5IHBhZ2UuIGdmbj0weGRkLCBtZm49MHhhNGEwOQ0KKFhFTikgWzIwMTItMDktMDQg
MTU6NTQ6MzVdIGh2bS5jOjI0MzU6ZDE1IGd1ZXN0IGF0dGVtcHRlZCB3cml0ZSB0byByZWFk
LW9ubHkgbWVtb3J5IHBhZ2UuIGdmbj0weGRmLCBtZm49MHhhNGEwNw0KKFhFTikgWzIwMTIt
MDktMDQgMTU6NTQ6MzVdIGh2bS5jOjI0MzU6ZDE1IGd1ZXN0IGF0dGVtcHRlZCB3cml0ZSB0
byByZWFkLW9ubHkgbWVtb3J5IHBhZ2UuIGdmbj0weGUxLCBtZm49MHhhNGEwNQ0KKFhFTikg
WzIwMTItMDktMDQgMTU6NTQ6MzVdIGh2bS5jOjI0MzU6ZDE1IGd1ZXN0IGF0dGVtcHRlZCB3
cml0ZSB0byByZWFkLW9ubHkgbWVtb3J5IHBhZ2UuIGdmbj0weGUzLCBtZm49MHhhNGEwMw0K
KFhFTikgWzIwMTItMDktMDQgMTU6NTQ6MzVdIGh2bS5jOjI0MzU6ZDE1IGd1ZXN0IGF0dGVt
cHRlZCB3cml0ZSB0byByZWFkLW9ubHkgbWVtb3J5IHBhZ2UuIGdmbj0weGU1LCBtZm49MHhh
NGEwMQ0KKFhFTikgWzIwMTItMDktMDQgMTU6NTQ6MzVdIGh2bS5jOjI0MzU6ZDE1IGd1ZXN0
IGF0dGVtcHRlZCB3cml0ZSB0byByZWFkLW9ubHkgbWVtb3J5IHBhZ2UuIGdmbj0weGU3LCBt
Zm49MHhhNDYzZg0KKFhFTikgWzIwMTItMDktMDQgMTU6NTQ6MzVdIGh2bS5jOjI0MzU6ZDE1
IGd1ZXN0IGF0dGVtcHRlZCB3cml0ZSB0byByZWFkLW9ubHkgbWVtb3J5IHBhZ2UuIGdmbj0w
eGU5LCBtZm49MHhhNDYzZA0KKFhFTikgWzIwMTItMDktMDQgMTU6NTQ6MzVdIGh2bS5jOjI0
MzU6ZDE1IGd1ZXN0IGF0dGVtcHRlZCB3cml0ZSB0byByZWFkLW9ubHkgbWVtb3J5IHBhZ2Uu
IGdmbj0weGViLCBtZm49MHhhNDYzYg0KKFhFTikgWzIwMTItMDktMDQgMTU6NTQ6MzVdIGh2
bS5jOjI0MzU6ZDE1IGd1ZXN0IGF0dGVtcHRlZCB3cml0ZSB0byByZWFkLW9ubHkgbWVtb3J5
IHBhZ2UuIGdmbj0weGVkLCBtZm49MHhhNDYzOQ0KKFhFTikgWzIwMTItMDktMDQgMTU6NTQ6
MzVdIGh2bS5jOjI0MzU6ZDE1IGd1ZXN0IGF0dGVtcHRlZCB3cml0ZSB0byByZWFkLW9ubHkg
bWVtb3J5IHBhZ2UuIGdmbj0weGVmLCBtZm49MHhhNDYzNw0KKFhFTikgWzIwMTItMDktMDQg
MTY6MTM6NTZdIEFNRC1WaTogSU9fUEFHRV9GQVVMVDogZG9tYWluID0gMCwgZGV2aWNlIGlk
ID0gMHgwYTA2LCBmYXVsdCBhZGRyZXNzID0gMHhjMmMyYzJjMA0KKFhFTikgWzIwMTItMDkt
MDQgMTY6MTM6NTZdIEFNRC1WaTogSU9fUEFHRV9GQVVMVDogZG9tYWluID0gMTQsIGRldmlj
ZSBpZCA9IDB4MDcwMCwgZmF1bHQgYWRkcmVzcyA9IDB4YTkwZjgzMDANCihYRU4pIFsyMDEy
LTA5LTA0IDE2OjEzOjU2XSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDE0LCBk
ZXZpY2UgaWQgPSAweDA3MDAsIGZhdWx0IGFkZHJlc3MgPSAweGE5MGY4MzQwDQooWEVOKSBb
MjAxMi0wOS0wNCAxNjoxMzo1Nl0gQU1ELVZpOiBJT19QQUdFX0ZBVUxUOiBkb21haW4gPSAx
NCwgZGV2aWNlIGlkID0gMHgwNzAwLCBmYXVsdCBhZGRyZXNzID0gMHhhOTBmODM4MA0KKFhF
TikgWzIwMTItMDktMDQgMTY6MTM6NTZdIEFNRC1WaTogSU9fUEFHRV9GQVVMVDogZG9tYWlu
ID0gMTQsIGRldmljZSBpZCA9IDB4MDcwMCwgZmF1bHQgYWRkcmVzcyA9IDB4YTkwZjgzYzAN
Cg==
------------0C30E31DB2590EB56
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

------------0C30E31DB2590EB56--



From xen-devel-bounces@lists.xen.org Tue Sep 04 16:45:07 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Sep 2012 16:45:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T8wFA-0005Qb-H3; Tue, 04 Sep 2012 16:44:52 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1T8wF9-0005QE-A8
	for xen-devel@lists.xensource.com; Tue, 04 Sep 2012 16:44:51 +0000
Received: from [85.158.138.51:25629] by server-12.bemta-3.messagelabs.com id
	FD/52-10384-20036405; Tue, 04 Sep 2012 16:44:50 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1346777088!28599401!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNjg0OTY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18100 invoked from network); 4 Sep 2012 16:44:49 -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;
	4 Sep 2012 16:44:49 -0000
X-IronPort-AV: E=Sophos;i="4.80,367,1344211200"; d="scan'208";a="36719631"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Sep 2012 16:44:48 +0000
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.279.1; Tue, 4 Sep 2012
	12:44:47 -0400
Message-ID: <50462FFE.7070100@citrix.com>
Date: Tue, 4 Sep 2012 17:44:46 +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 Iceowl/1.0b1 Icedove/3.0.11
MIME-Version: 1.0
To: Stefano Panella <stefano.panella@citrix.com>
References: <1346407072-6405-1-git-send-email-stefano.panella@citrix.com>	<5040B249.4000306@citrix.com>	<20120831164010.GA18929@localhost.localdomain>	<50460B2E.3020200@citrix.com>	<20120904143731.GC23361@phenom.dumpdata.com>	<50461654.5040901@citrix.com>
	<50461A59.2050504@citrix.com>
In-Reply-To: <50461A59.2050504@citrix.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	David Vrabel <david.vrabel@citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [Xen-devel] [PATCH 1/1] XEN: Use correct masking
	in	xen_swiotlb_alloc_coherent.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/09/12 16:12, Stefano Panella wrote:
> On 09/04/2012 03:55 PM, David Vrabel wrote:
>> On 04/09/12 15:37, Konrad Rzeszutek Wilk wrote:
>>> On Tue, Sep 04, 2012 at 03:07:42PM +0100, Stefano Panella wrote:
>>>> So if hwdev->coherent_dma_mask is set to 0xffffffffffffffff our
>>>> dma_mask will
>>>> be u64 set to 0xffffffffffffffff even if we set it to
>>>> DMA_BIT_MASK(32) previously.
>>> That is what I was missing. Let me include that in the git commit and
>>> also
>>> put this patch on the stable tree.
>> Note that this appears to be a work around for a bug in the sound system
>> or Intel HDA device driver which is incorrectly truncating a dma_addr_t
>> to a u32.  So by ensuring a DMA_BIT_MASK(32) when the dma_addr_t is
>> truncated it still works.
>>
>> David
> Sorry David, I am not completely sure I understand your argument in
> favour of a bug in the
> sound system or Intel HDA device driver. Could you please elaborate more
> in detail about this?

The HDA driver claims to support 64-bit DMA addresses, so it should be
perfectly fine for the Xen DMA mapping/allocation functions to return
DMA addresses > 4 GiB.  For most devices this seems to work just fine.

I think that somewhere between the buffer being mapped or allocated and
the address being programmed into the hardware, the 64-bit dma_addr_t
value is being truncated to 32 bits giving an invalid DMA address.

The patch would avoid this by setting the DMA mask to 32-bit and only
returning DMA address < 4 GiB which can quite happily be stuffed into a
u32 without losing bits.

I think it would be useful (without the patch applied) to print the DMA
addresses returned by the allocate/mapping functions and the address
programmed into the hardware.  It will be easily to spot if it got
truncated or not.

David

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

From xen-devel-bounces@lists.xen.org Tue Sep 04 16:45:07 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Sep 2012 16:45:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T8wFA-0005Qb-H3; Tue, 04 Sep 2012 16:44:52 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1T8wF9-0005QE-A8
	for xen-devel@lists.xensource.com; Tue, 04 Sep 2012 16:44:51 +0000
Received: from [85.158.138.51:25629] by server-12.bemta-3.messagelabs.com id
	FD/52-10384-20036405; Tue, 04 Sep 2012 16:44:50 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1346777088!28599401!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNjg0OTY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18100 invoked from network); 4 Sep 2012 16:44:49 -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;
	4 Sep 2012 16:44:49 -0000
X-IronPort-AV: E=Sophos;i="4.80,367,1344211200"; d="scan'208";a="36719631"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Sep 2012 16:44:48 +0000
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.279.1; Tue, 4 Sep 2012
	12:44:47 -0400
Message-ID: <50462FFE.7070100@citrix.com>
Date: Tue, 4 Sep 2012 17:44:46 +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 Iceowl/1.0b1 Icedove/3.0.11
MIME-Version: 1.0
To: Stefano Panella <stefano.panella@citrix.com>
References: <1346407072-6405-1-git-send-email-stefano.panella@citrix.com>	<5040B249.4000306@citrix.com>	<20120831164010.GA18929@localhost.localdomain>	<50460B2E.3020200@citrix.com>	<20120904143731.GC23361@phenom.dumpdata.com>	<50461654.5040901@citrix.com>
	<50461A59.2050504@citrix.com>
In-Reply-To: <50461A59.2050504@citrix.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	David Vrabel <david.vrabel@citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [Xen-devel] [PATCH 1/1] XEN: Use correct masking
	in	xen_swiotlb_alloc_coherent.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/09/12 16:12, Stefano Panella wrote:
> On 09/04/2012 03:55 PM, David Vrabel wrote:
>> On 04/09/12 15:37, Konrad Rzeszutek Wilk wrote:
>>> On Tue, Sep 04, 2012 at 03:07:42PM +0100, Stefano Panella wrote:
>>>> So if hwdev->coherent_dma_mask is set to 0xffffffffffffffff our
>>>> dma_mask will
>>>> be u64 set to 0xffffffffffffffff even if we set it to
>>>> DMA_BIT_MASK(32) previously.
>>> That is what I was missing. Let me include that in the git commit and
>>> also
>>> put this patch on the stable tree.
>> Note that this appears to be a work around for a bug in the sound system
>> or Intel HDA device driver which is incorrectly truncating a dma_addr_t
>> to a u32.  So by ensuring a DMA_BIT_MASK(32) when the dma_addr_t is
>> truncated it still works.
>>
>> David
> Sorry David, I am not completely sure I understand your argument in
> favour of a bug in the
> sound system or Intel HDA device driver. Could you please elaborate more
> in detail about this?

The HDA driver claims to support 64-bit DMA addresses, so it should be
perfectly fine for the Xen DMA mapping/allocation functions to return
DMA addresses > 4 GiB.  For most devices this seems to work just fine.

I think that somewhere between the buffer being mapped or allocated and
the address being programmed into the hardware, the 64-bit dma_addr_t
value is being truncated to 32 bits giving an invalid DMA address.

The patch would avoid this by setting the DMA mask to 32-bit and only
returning DMA address < 4 GiB which can quite happily be stuffed into a
u32 without losing bits.

I think it would be useful (without the patch applied) to print the DMA
addresses returned by the allocate/mapping functions and the address
programmed into the hardware.  It will be easily to spot if it got
truncated or not.

David

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

From xen-devel-bounces@lists.xen.org Tue Sep 04 16:49:53 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Sep 2012 16:49:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T8wJp-0005pG-8f; Tue, 04 Sep 2012 16:49: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 1T8wJn-0005oh-Ck
	for xen-devel@lists.xen.org; Tue, 04 Sep 2012 16:49:39 +0000
Received: from [85.158.143.35:7402] by server-3.bemta-4.messagelabs.com id
	39/F5-08232-32136405; Tue, 04 Sep 2012 16:49:39 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1346777377!12194088!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDczNjI0OQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1414 invoked from network); 4 Sep 2012 16:49:38 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-7.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 4 Sep 2012 16:49:38 -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 q84GnV1R020705
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 4 Sep 2012 16:49:33 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q84GnVoP019850
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 4 Sep 2012 16:49:31 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
	q84GnU3u030057; Tue, 4 Sep 2012 11:49:30 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 04 Sep 2012 09:49:30 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id CC0F9402BA; Tue,  4 Sep 2012 12:39:03 -0400 (EDT)
Date: Tue, 4 Sep 2012 12:39:03 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Sander Eikelenboom <linux@eikelenboom.it>
Message-ID: <20120904163903.GI23361@phenom.dumpdata.com>
References: <1136369816.20120904183757@eikelenboom.it>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1136369816.20120904183757@eikelenboom.it>
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
Subject: Re: [Xen-devel] dom0 linux 3.6.0-rc4,
 crash due to ballooning althoug dom0_mem=X, max:X set
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Sep 04, 2012 at 06:37:57PM +0200, Sander Eikelenboom wrote:
> Hi Konrad,
> 
> This seems to happen only on a intel machine i'm trying to setup as a development machine (haven't seen it on my amd).
> It boots fine, i have dom0_mem=1024M,max:1024M set, the machine has 2G of mem.
> 
> Dom0 and guest kernel are 3.6.0-rc4 with config:
> [*] Xen memory balloon driver
> [*]   Scrub pages before returning them to system

Can you also try this patch out and provide the full log (bootup and such). Thanks!

diff --git a/drivers/xen/balloon.c b/drivers/xen/balloon.c
index 31ab82f..871a93c 100644
--- a/drivers/xen/balloon.c
+++ b/drivers/xen/balloon.c
@@ -355,8 +355,12 @@ static enum bp_state increase_reservation(unsigned long nr_pages)
 		BUG_ON(page == NULL);
 
 		pfn = page_to_pfn(page);
-		BUG_ON(!xen_feature(XENFEAT_auto_translated_physmap) &&
-		       phys_to_machine_mapping_valid(pfn));
+		if (!xen_feature(XENFEAT_auto_translated_physmap)) {
+			if (phys_to_machine_mapping_valid(pfn)) {
+				printk(KERN_DEBUG "%lx is %lx!\n", pfn, get_phys_to_machine(pfn));
+				continue;
+			}
+		}
 
 		set_phys_to_machine(pfn, frame_list[i]);
 
@@ -572,6 +576,7 @@ static void __init balloon_add_region(unsigned long start_pfn,
 	 */
 	extra_pfn_end = min(max_pfn, start_pfn + pages);
 
+	printk(KERN_INFO "%s: [%lx->%lx]\n", __func__, start_pfn, extra_pfn_end);
 	for (pfn = start_pfn; pfn < extra_pfn_end; pfn++) {
 		page = pfn_to_page(pfn);
 		/* totalram_pages and totalhigh_pages do not

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

From xen-devel-bounces@lists.xen.org Tue Sep 04 16:49:53 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Sep 2012 16:49:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T8wJp-0005pG-8f; Tue, 04 Sep 2012 16:49: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 1T8wJn-0005oh-Ck
	for xen-devel@lists.xen.org; Tue, 04 Sep 2012 16:49:39 +0000
Received: from [85.158.143.35:7402] by server-3.bemta-4.messagelabs.com id
	39/F5-08232-32136405; Tue, 04 Sep 2012 16:49:39 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1346777377!12194088!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDczNjI0OQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1414 invoked from network); 4 Sep 2012 16:49:38 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-7.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 4 Sep 2012 16:49:38 -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 q84GnV1R020705
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 4 Sep 2012 16:49:33 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q84GnVoP019850
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 4 Sep 2012 16:49:31 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
	q84GnU3u030057; Tue, 4 Sep 2012 11:49:30 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 04 Sep 2012 09:49:30 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id CC0F9402BA; Tue,  4 Sep 2012 12:39:03 -0400 (EDT)
Date: Tue, 4 Sep 2012 12:39:03 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Sander Eikelenboom <linux@eikelenboom.it>
Message-ID: <20120904163903.GI23361@phenom.dumpdata.com>
References: <1136369816.20120904183757@eikelenboom.it>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1136369816.20120904183757@eikelenboom.it>
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
Subject: Re: [Xen-devel] dom0 linux 3.6.0-rc4,
 crash due to ballooning althoug dom0_mem=X, max:X set
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Sep 04, 2012 at 06:37:57PM +0200, Sander Eikelenboom wrote:
> Hi Konrad,
> 
> This seems to happen only on a intel machine i'm trying to setup as a development machine (haven't seen it on my amd).
> It boots fine, i have dom0_mem=1024M,max:1024M set, the machine has 2G of mem.
> 
> Dom0 and guest kernel are 3.6.0-rc4 with config:
> [*] Xen memory balloon driver
> [*]   Scrub pages before returning them to system

Can you also try this patch out and provide the full log (bootup and such). Thanks!

diff --git a/drivers/xen/balloon.c b/drivers/xen/balloon.c
index 31ab82f..871a93c 100644
--- a/drivers/xen/balloon.c
+++ b/drivers/xen/balloon.c
@@ -355,8 +355,12 @@ static enum bp_state increase_reservation(unsigned long nr_pages)
 		BUG_ON(page == NULL);
 
 		pfn = page_to_pfn(page);
-		BUG_ON(!xen_feature(XENFEAT_auto_translated_physmap) &&
-		       phys_to_machine_mapping_valid(pfn));
+		if (!xen_feature(XENFEAT_auto_translated_physmap)) {
+			if (phys_to_machine_mapping_valid(pfn)) {
+				printk(KERN_DEBUG "%lx is %lx!\n", pfn, get_phys_to_machine(pfn));
+				continue;
+			}
+		}
 
 		set_phys_to_machine(pfn, frame_list[i]);
 
@@ -572,6 +576,7 @@ static void __init balloon_add_region(unsigned long start_pfn,
 	 */
 	extra_pfn_end = min(max_pfn, start_pfn + pages);
 
+	printk(KERN_INFO "%s: [%lx->%lx]\n", __func__, start_pfn, extra_pfn_end);
 	for (pfn = start_pfn; pfn < extra_pfn_end; pfn++) {
 		page = pfn_to_page(pfn);
 		/* totalram_pages and totalhigh_pages do not

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

From xen-devel-bounces@lists.xen.org Tue Sep 04 16:51:16 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Sep 2012 16:51:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T8wLA-0005uo-O3; Tue, 04 Sep 2012 16:51: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 1T8wL8-0005ud-8M
	for xen-devel@lists.xensource.com; Tue, 04 Sep 2012 16:51:02 +0000
Received: from [85.158.143.99:19099] by server-1.bemta-4.messagelabs.com id
	29/50-12504-57136405; Tue, 04 Sep 2012 16:51:01 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1346777459!23224649!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDczNjI0OQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14101 invoked from network); 4 Sep 2012 16:51:00 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-4.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 4 Sep 2012 16:51:00 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q84GouRm022025
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 4 Sep 2012 16:50:57 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
	q84Gou8V026093
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 4 Sep 2012 16:50:56 GMT
Received: from abhmt108.oracle.com (abhmt108.oracle.com [141.146.116.60])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q84GotTH005476; Tue, 4 Sep 2012 11:50:55 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 04 Sep 2012 09:50:55 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id CB522402BA; Tue,  4 Sep 2012 12:40:28 -0400 (EDT)
Date: Tue, 4 Sep 2012 12:40:28 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: David Vrabel <david.vrabel@citrix.com>
Message-ID: <20120904164028.GJ23361@phenom.dumpdata.com>
References: <1346407072-6405-1-git-send-email-stefano.panella@citrix.com>
	<5040B249.4000306@citrix.com>
	<20120831164010.GA18929@localhost.localdomain>
	<50460B2E.3020200@citrix.com>
	<20120904143731.GC23361@phenom.dumpdata.com>
	<50461654.5040901@citrix.com> <50461A59.2050504@citrix.com>
	<50462FFE.7070100@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <50462FFE.7070100@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" <xen-devel@lists.xensource.com>,
	Stefano Panella <stefano.panella@citrix.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [Xen-devel] [PATCH 1/1] XEN: Use correct masking
	in	xen_swiotlb_alloc_coherent.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Sep 04, 2012 at 05:44:46PM +0100, David Vrabel wrote:
> On 04/09/12 16:12, Stefano Panella wrote:
> > On 09/04/2012 03:55 PM, David Vrabel wrote:
> >> On 04/09/12 15:37, Konrad Rzeszutek Wilk wrote:
> >>> On Tue, Sep 04, 2012 at 03:07:42PM +0100, Stefano Panella wrote:
> >>>> So if hwdev->coherent_dma_mask is set to 0xffffffffffffffff our
> >>>> dma_mask will
> >>>> be u64 set to 0xffffffffffffffff even if we set it to
> >>>> DMA_BIT_MASK(32) previously.
> >>> That is what I was missing. Let me include that in the git commit and
> >>> also
> >>> put this patch on the stable tree.
> >> Note that this appears to be a work around for a bug in the sound system
> >> or Intel HDA device driver which is incorrectly truncating a dma_addr_t
> >> to a u32.  So by ensuring a DMA_BIT_MASK(32) when the dma_addr_t is
> >> truncated it still works.
> >>
> >> David
> > Sorry David, I am not completely sure I understand your argument in
> > favour of a bug in the
> > sound system or Intel HDA device driver. Could you please elaborate more
> > in detail about this?
> 
> The HDA driver claims to support 64-bit DMA addresses, so it should be
> perfectly fine for the Xen DMA mapping/allocation functions to return
> DMA addresses > 4 GiB.  For most devices this seems to work just fine.
> 
> I think that somewhere between the buffer being mapped or allocated and
> the address being programmed into the hardware, the 64-bit dma_addr_t
> value is being truncated to 32 bits giving an invalid DMA address.
> 
> The patch would avoid this by setting the DMA mask to 32-bit and only
> returning DMA address < 4 GiB which can quite happily be stuffed into a
> u32 without losing bits.
> 
> I think it would be useful (without the patch applied) to print the DMA
> addresses returned by the allocate/mapping functions and the address
> programmed into the hardware.  It will be easily to spot if it got
> truncated or not.

Just enable DMA debug API (CONFIG_DEBUG_DMA_API) and use this fancy module:


/*
 *
 * This program is free software; you can redistribute it and/or modify
 * it under the terms of the GNU General Public License v2.0 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.
 */

#include <linux/module.h>
#include <linux/string.h>
#include <linux/types.h>
#include <linux/init.h>
#include <linux/stat.h>
#include <linux/err.h>
#include <linux/ctype.h>
#include <linux/slab.h>
#include <linux/limits.h>
#include <linux/device.h>
#include <linux/pci.h>
#include <linux/blkdev.h>
#include <linux/device.h>

#include <linux/init.h>
#include <linux/mm.h>
#include <linux/fcntl.h>
#include <linux/slab.h>
#include <linux/kmod.h>
#include <linux/major.h>
#include <linux/highmem.h>
#include <linux/blkdev.h>
#include <linux/module.h>
#include <linux/blkpg.h>
#include <linux/buffer_head.h>
#include <linux/mpage.h>
#include <linux/mount.h>
#include <linux/uio.h>
#include <linux/namei.h>
#include <asm/uaccess.h>

#include <linux/pagemap.h>
#include <linux/pagevec.h>

#include <linux/dma-debug.h>

#define DUMP_DMA_FUN  "0.1"

MODULE_AUTHOR("Konrad Rzeszutek Wilk <konrad@virtualiron>");
MODULE_DESCRIPTION("dump dma");
MODULE_LICENSE("GPL");
MODULE_VERSION(DUMP_DMA_FUN);

static int __init dump_dma_init(void)
{
	debug_dma_dump_mappings(NULL);
	return 0;
}

static void __exit dump_dma_exit(void)
{
}

module_init(dump_dma_init);
module_exit(dump_dma_exit);
> 
> David

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

From xen-devel-bounces@lists.xen.org Tue Sep 04 16:51:16 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Sep 2012 16:51:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T8wLA-0005uo-O3; Tue, 04 Sep 2012 16:51: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 1T8wL8-0005ud-8M
	for xen-devel@lists.xensource.com; Tue, 04 Sep 2012 16:51:02 +0000
Received: from [85.158.143.99:19099] by server-1.bemta-4.messagelabs.com id
	29/50-12504-57136405; Tue, 04 Sep 2012 16:51:01 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1346777459!23224649!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDczNjI0OQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14101 invoked from network); 4 Sep 2012 16:51:00 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-4.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 4 Sep 2012 16:51:00 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q84GouRm022025
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 4 Sep 2012 16:50:57 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
	q84Gou8V026093
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 4 Sep 2012 16:50:56 GMT
Received: from abhmt108.oracle.com (abhmt108.oracle.com [141.146.116.60])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q84GotTH005476; Tue, 4 Sep 2012 11:50:55 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 04 Sep 2012 09:50:55 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id CB522402BA; Tue,  4 Sep 2012 12:40:28 -0400 (EDT)
Date: Tue, 4 Sep 2012 12:40:28 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: David Vrabel <david.vrabel@citrix.com>
Message-ID: <20120904164028.GJ23361@phenom.dumpdata.com>
References: <1346407072-6405-1-git-send-email-stefano.panella@citrix.com>
	<5040B249.4000306@citrix.com>
	<20120831164010.GA18929@localhost.localdomain>
	<50460B2E.3020200@citrix.com>
	<20120904143731.GC23361@phenom.dumpdata.com>
	<50461654.5040901@citrix.com> <50461A59.2050504@citrix.com>
	<50462FFE.7070100@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <50462FFE.7070100@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" <xen-devel@lists.xensource.com>,
	Stefano Panella <stefano.panella@citrix.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [Xen-devel] [PATCH 1/1] XEN: Use correct masking
	in	xen_swiotlb_alloc_coherent.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Sep 04, 2012 at 05:44:46PM +0100, David Vrabel wrote:
> On 04/09/12 16:12, Stefano Panella wrote:
> > On 09/04/2012 03:55 PM, David Vrabel wrote:
> >> On 04/09/12 15:37, Konrad Rzeszutek Wilk wrote:
> >>> On Tue, Sep 04, 2012 at 03:07:42PM +0100, Stefano Panella wrote:
> >>>> So if hwdev->coherent_dma_mask is set to 0xffffffffffffffff our
> >>>> dma_mask will
> >>>> be u64 set to 0xffffffffffffffff even if we set it to
> >>>> DMA_BIT_MASK(32) previously.
> >>> That is what I was missing. Let me include that in the git commit and
> >>> also
> >>> put this patch on the stable tree.
> >> Note that this appears to be a work around for a bug in the sound system
> >> or Intel HDA device driver which is incorrectly truncating a dma_addr_t
> >> to a u32.  So by ensuring a DMA_BIT_MASK(32) when the dma_addr_t is
> >> truncated it still works.
> >>
> >> David
> > Sorry David, I am not completely sure I understand your argument in
> > favour of a bug in the
> > sound system or Intel HDA device driver. Could you please elaborate more
> > in detail about this?
> 
> The HDA driver claims to support 64-bit DMA addresses, so it should be
> perfectly fine for the Xen DMA mapping/allocation functions to return
> DMA addresses > 4 GiB.  For most devices this seems to work just fine.
> 
> I think that somewhere between the buffer being mapped or allocated and
> the address being programmed into the hardware, the 64-bit dma_addr_t
> value is being truncated to 32 bits giving an invalid DMA address.
> 
> The patch would avoid this by setting the DMA mask to 32-bit and only
> returning DMA address < 4 GiB which can quite happily be stuffed into a
> u32 without losing bits.
> 
> I think it would be useful (without the patch applied) to print the DMA
> addresses returned by the allocate/mapping functions and the address
> programmed into the hardware.  It will be easily to spot if it got
> truncated or not.

Just enable DMA debug API (CONFIG_DEBUG_DMA_API) and use this fancy module:


/*
 *
 * This program is free software; you can redistribute it and/or modify
 * it under the terms of the GNU General Public License v2.0 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.
 */

#include <linux/module.h>
#include <linux/string.h>
#include <linux/types.h>
#include <linux/init.h>
#include <linux/stat.h>
#include <linux/err.h>
#include <linux/ctype.h>
#include <linux/slab.h>
#include <linux/limits.h>
#include <linux/device.h>
#include <linux/pci.h>
#include <linux/blkdev.h>
#include <linux/device.h>

#include <linux/init.h>
#include <linux/mm.h>
#include <linux/fcntl.h>
#include <linux/slab.h>
#include <linux/kmod.h>
#include <linux/major.h>
#include <linux/highmem.h>
#include <linux/blkdev.h>
#include <linux/module.h>
#include <linux/blkpg.h>
#include <linux/buffer_head.h>
#include <linux/mpage.h>
#include <linux/mount.h>
#include <linux/uio.h>
#include <linux/namei.h>
#include <asm/uaccess.h>

#include <linux/pagemap.h>
#include <linux/pagevec.h>

#include <linux/dma-debug.h>

#define DUMP_DMA_FUN  "0.1"

MODULE_AUTHOR("Konrad Rzeszutek Wilk <konrad@virtualiron>");
MODULE_DESCRIPTION("dump dma");
MODULE_LICENSE("GPL");
MODULE_VERSION(DUMP_DMA_FUN);

static int __init dump_dma_init(void)
{
	debug_dma_dump_mappings(NULL);
	return 0;
}

static void __exit dump_dma_exit(void)
{
}

module_init(dump_dma_init);
module_exit(dump_dma_exit);
> 
> David

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

From xen-devel-bounces@lists.xen.org Tue Sep 04 17:04:54 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Sep 2012 17: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 1T8wYK-0006DR-7M; Tue, 04 Sep 2012 17:04:40 +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 1T8wYI-0006DM-MH
	for xen-devel@lists.xensource.com; Tue, 04 Sep 2012 17:04:38 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1346778269!9528824!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTE3MTg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13735 invoked from network); 4 Sep 2012 17:04:29 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Sep 2012 17:04:29 -0000
X-IronPort-AV: E=Sophos;i="4.80,367,1344211200"; d="scan'208";a="14341493"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Sep 2012 17:04: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.279.1; Tue, 4 Sep 2012 18:04: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 1T8wXo-0002VN-3G;
	Tue, 04 Sep 2012 17:04:08 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1T8wXn-0002Px-Nh;
	Tue, 04 Sep 2012 18:04:07 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-13644-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Tue, 4 Sep 2012 18:04:07 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.1-testing test] 13644: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 13644 xen-4.1-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13644/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-win          8 guest-saverestore         fail REGR. vs. 13581

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-pcipt-intel  8 debian-fixup                fail like 13581

Tests which did not succeed, but are not blocking:
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-i386-qemuu-rhel6hvm-amd 11 leak-check/check         fail never pass
 test-amd64-i386-rhel6hvm-intel 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-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 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-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 13 guest-stop             fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-i386-i386-xl-qemuu-winxpsp3 13 guest-stop                 fail never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  58d3c21ee4bd
baseline version:
 xen                  1225aff05dd2

------------------------------------------------------------
People who touched revisions under test:
------------------------------------------------------------

jobs:
 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:   23337:58d3c21ee4bd
tag:         tip
user:        Jan Beulich
date:        Tue Sep 04 12:03:35 2012 +0200
    
    Update Xen version to 4.1.4-pre
    
    
changeset:   23336:1225aff05dd2
user:        Keir Fraser <keir@xen.org>
date:        Thu Aug 09 16:48:07 2012 +0100
    
    Added signature for changeset ce7195d2b80e
    
    
(qemu changes not included)

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

From xen-devel-bounces@lists.xen.org Tue Sep 04 17:04:54 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Sep 2012 17: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 1T8wYK-0006DR-7M; Tue, 04 Sep 2012 17:04:40 +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 1T8wYI-0006DM-MH
	for xen-devel@lists.xensource.com; Tue, 04 Sep 2012 17:04:38 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1346778269!9528824!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTE3MTg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13735 invoked from network); 4 Sep 2012 17:04:29 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Sep 2012 17:04:29 -0000
X-IronPort-AV: E=Sophos;i="4.80,367,1344211200"; d="scan'208";a="14341493"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Sep 2012 17:04: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.279.1; Tue, 4 Sep 2012 18:04: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 1T8wXo-0002VN-3G;
	Tue, 04 Sep 2012 17:04:08 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1T8wXn-0002Px-Nh;
	Tue, 04 Sep 2012 18:04:07 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-13644-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Tue, 4 Sep 2012 18:04:07 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.1-testing test] 13644: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 13644 xen-4.1-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13644/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-win          8 guest-saverestore         fail REGR. vs. 13581

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-pcipt-intel  8 debian-fixup                fail like 13581

Tests which did not succeed, but are not blocking:
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-i386-qemuu-rhel6hvm-amd 11 leak-check/check         fail never pass
 test-amd64-i386-rhel6hvm-intel 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-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 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-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 13 guest-stop             fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-i386-i386-xl-qemuu-winxpsp3 13 guest-stop                 fail never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  58d3c21ee4bd
baseline version:
 xen                  1225aff05dd2

------------------------------------------------------------
People who touched revisions under test:
------------------------------------------------------------

jobs:
 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:   23337:58d3c21ee4bd
tag:         tip
user:        Jan Beulich
date:        Tue Sep 04 12:03:35 2012 +0200
    
    Update Xen version to 4.1.4-pre
    
    
changeset:   23336:1225aff05dd2
user:        Keir Fraser <keir@xen.org>
date:        Thu Aug 09 16:48:07 2012 +0100
    
    Added signature for changeset ce7195d2b80e
    
    
(qemu changes not included)

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

From xen-devel-bounces@lists.xen.org Tue Sep 04 17:16:18 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Sep 2012 17:16:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T8wjM-0006RE-Iq; Tue, 04 Sep 2012 17:16:04 +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 1T8wjL-0006R9-9w
	for xen-devel@lists.xen.org; Tue, 04 Sep 2012 17:16:03 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-11.tower-27.messagelabs.com!1346778956!2738917!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA1MDA5NDY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24568 invoked from network); 4 Sep 2012 17:15:57 -0000
Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25)
	by server-11.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 4 Sep 2012 17:15:57 -0000
X-Originating-Ip: [194.89.68.22]
Received: from ydin.reaktio.net (reaktio.net [194.89.68.22])
	by smtp.tele.fi (Postfix) with ESMTP id 14F762C72;
	Tue,  4 Sep 2012 20:15:55 +0300 (EEST)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id 1E3792005D; Tue,  4 Sep 2012 20:15:55 +0300 (EEST)
Date: Tue, 4 Sep 2012 20:15:54 +0300
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: Daniel Di Giacomo <lists@dadigi.com>
Message-ID: <20120904171554.GG8912@reaktio.net>
References: <5044DA01.9070201@dadigi.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <5044DA01.9070201@dadigi.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] PCI passthrough for domU allocated with more than
 4G memory
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Sep 03, 2012 at 06:25:37PM +0200, Daniel Di Giacomo wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Same problem here.
> I'm using gentoo with kernel 3.5.3 (gentoo-sources) and XEN 4.1.2 as dom0.
> DomU is also gentoo with the same kernel version.
> When I assign more than 4G memory to this domU, the memory for the
> passed-through Intel-gigabit-nic cannot be allocated and the
> initialization of the device fails.
> With 3968M memory assigned everything works fine.
> Assigning 8GB RAM to domU works without any problems, when I use the
> old kernel-version 2.6.34 (xen-sources) in domU.
> 

I think you need Xen 4.2 and e820_host=1 option.

-- Pasi


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

From xen-devel-bounces@lists.xen.org Tue Sep 04 17:16:18 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Sep 2012 17:16:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T8wjM-0006RE-Iq; Tue, 04 Sep 2012 17:16:04 +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 1T8wjL-0006R9-9w
	for xen-devel@lists.xen.org; Tue, 04 Sep 2012 17:16:03 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-11.tower-27.messagelabs.com!1346778956!2738917!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA1MDA5NDY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24568 invoked from network); 4 Sep 2012 17:15:57 -0000
Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25)
	by server-11.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 4 Sep 2012 17:15:57 -0000
X-Originating-Ip: [194.89.68.22]
Received: from ydin.reaktio.net (reaktio.net [194.89.68.22])
	by smtp.tele.fi (Postfix) with ESMTP id 14F762C72;
	Tue,  4 Sep 2012 20:15:55 +0300 (EEST)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id 1E3792005D; Tue,  4 Sep 2012 20:15:55 +0300 (EEST)
Date: Tue, 4 Sep 2012 20:15:54 +0300
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: Daniel Di Giacomo <lists@dadigi.com>
Message-ID: <20120904171554.GG8912@reaktio.net>
References: <5044DA01.9070201@dadigi.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <5044DA01.9070201@dadigi.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] PCI passthrough for domU allocated with more than
 4G memory
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Sep 03, 2012 at 06:25:37PM +0200, Daniel Di Giacomo wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Same problem here.
> I'm using gentoo with kernel 3.5.3 (gentoo-sources) and XEN 4.1.2 as dom0.
> DomU is also gentoo with the same kernel version.
> When I assign more than 4G memory to this domU, the memory for the
> passed-through Intel-gigabit-nic cannot be allocated and the
> initialization of the device fails.
> With 3968M memory assigned everything works fine.
> Assigning 8GB RAM to domU works without any problems, when I use the
> old kernel-version 2.6.34 (xen-sources) in domU.
> 

I think you need Xen 4.2 and e820_host=1 option.

-- Pasi


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

From xen-devel-bounces@lists.xen.org Tue Sep 04 17:20:07 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Sep 2012 17: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 1T8wn1-0006YU-7T; Tue, 04 Sep 2012 17:19:51 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <linux@eikelenboom.it>) id 1T8wn0-0006YI-81
	for xen-devel@lists.xen.org; Tue, 04 Sep 2012 17:19:50 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-13.tower-27.messagelabs.com!1346779183!8472044!1
X-Originating-IP: [188.40.164.121]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16499 invoked from network); 4 Sep 2012 17:19:44 -0000
Received: from static.121.164.40.188.clients.your-server.de (HELO
	smtp.eikelenboom.it) (188.40.164.121)
	by server-13.tower-27.messagelabs.com with AES256-SHA encrypted SMTP;
	4 Sep 2012 17:19:44 -0000
Received: from 128-64-ftth.onsneteindhoven.nl ([88.159.64.128]:55891
	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 1T8wjr-0004uo-8m; Tue, 04 Sep 2012 19:16:35 +0200
Date: Tue, 4 Sep 2012 19:19:41 +0200
From: Sander Eikelenboom <linux@eikelenboom.it>
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <143844933.20120904191941@eikelenboom.it>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
In-Reply-To: <20120904163347.GH23361@phenom.dumpdata.com>
References: <1136369816.20120904183757@eikelenboom.it>
	<20120904163347.GH23361@phenom.dumpdata.com>
MIME-Version: 1.0
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] dom0 linux 3.6.0-rc4,
	crash due to ballooning althoug dom0_mem=X, max:X 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


Tuesday, September 4, 2012, 6:33:47 PM, you wrote:

> On Tue, Sep 04, 2012 at 06:37:57PM +0200, Sander Eikelenboom wrote:
>> Hi Konrad,
>> 
>> This seems to happen only on a intel machine i'm trying to setup as a development machine (haven't seen it on my amd).
>> It boots fine, i have dom0_mem=1024M,max:1024M set, the machine has 2G of mem.

> Is this only with Xen 4.2? As, does Xen 4.1 work?
>> 
>> Dom0 and guest kernel are 3.6.0-rc4 with config:

> If you back out:

> f393387d160211f60398d58463a7e65
> Author: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> Date:   Fri Aug 17 16:43:28 2012 -0400

>     xen/setup: Fix one-off error when adding for-balloon PFNs to the P2M.

> Do you see this bug? (Either with Xen 4.1 or Xen 4.2)?

With c96aae1f7f393387d160211f60398d58463a7e65 reverted i still see this bug (with Xen 4.2).

Will use the debug patch you mailed and send back the results ...


>> [*] Xen memory balloon driver
>> [*]   Scrub pages before returning them to system
>> 
>> From http://wiki.xen.org/wiki/Do%EF%BB%BFm0_Memory_%E2%80%94_Where_It_Has_Not_Gone , I thought this should be okay
>> 
>> But when trying to start a PV guest with 512MB mem, the machine (dom0) crashes with the stacktrace below (complete serial-log.txt attached).
>> 
>> From the:
>> "mapping kernel into physical memory
>> about to get started..."
>> 
>> I would almost say it's trying to reload dom0 ?
>> 
>> 
>> [  897.161119] device vif1.0 entered promiscuous mode
>> mapping kernel into physical memory
>> about to get started...
>> [  897.696619] xen_bridge: port 1(vif1.0) entered forwarding state
>> [  897.716219] xen_bridge: port 1(vif1.0) entered forwarding state
>> [  898.129465] ------------[ cut here ]------------
>> [  898.132209] kernel BUG at drivers/xen/balloon.c:359!
>> [  898.132209] invalid opcode: 0000 [#1] PREEMPT SMP 



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

From xen-devel-bounces@lists.xen.org Tue Sep 04 17:20:07 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Sep 2012 17: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 1T8wn1-0006YU-7T; Tue, 04 Sep 2012 17:19:51 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <linux@eikelenboom.it>) id 1T8wn0-0006YI-81
	for xen-devel@lists.xen.org; Tue, 04 Sep 2012 17:19:50 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-13.tower-27.messagelabs.com!1346779183!8472044!1
X-Originating-IP: [188.40.164.121]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16499 invoked from network); 4 Sep 2012 17:19:44 -0000
Received: from static.121.164.40.188.clients.your-server.de (HELO
	smtp.eikelenboom.it) (188.40.164.121)
	by server-13.tower-27.messagelabs.com with AES256-SHA encrypted SMTP;
	4 Sep 2012 17:19:44 -0000
Received: from 128-64-ftth.onsneteindhoven.nl ([88.159.64.128]:55891
	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 1T8wjr-0004uo-8m; Tue, 04 Sep 2012 19:16:35 +0200
Date: Tue, 4 Sep 2012 19:19:41 +0200
From: Sander Eikelenboom <linux@eikelenboom.it>
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <143844933.20120904191941@eikelenboom.it>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
In-Reply-To: <20120904163347.GH23361@phenom.dumpdata.com>
References: <1136369816.20120904183757@eikelenboom.it>
	<20120904163347.GH23361@phenom.dumpdata.com>
MIME-Version: 1.0
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] dom0 linux 3.6.0-rc4,
	crash due to ballooning althoug dom0_mem=X, max:X 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


Tuesday, September 4, 2012, 6:33:47 PM, you wrote:

> On Tue, Sep 04, 2012 at 06:37:57PM +0200, Sander Eikelenboom wrote:
>> Hi Konrad,
>> 
>> This seems to happen only on a intel machine i'm trying to setup as a development machine (haven't seen it on my amd).
>> It boots fine, i have dom0_mem=1024M,max:1024M set, the machine has 2G of mem.

> Is this only with Xen 4.2? As, does Xen 4.1 work?
>> 
>> Dom0 and guest kernel are 3.6.0-rc4 with config:

> If you back out:

> f393387d160211f60398d58463a7e65
> Author: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> Date:   Fri Aug 17 16:43:28 2012 -0400

>     xen/setup: Fix one-off error when adding for-balloon PFNs to the P2M.

> Do you see this bug? (Either with Xen 4.1 or Xen 4.2)?

With c96aae1f7f393387d160211f60398d58463a7e65 reverted i still see this bug (with Xen 4.2).

Will use the debug patch you mailed and send back the results ...


>> [*] Xen memory balloon driver
>> [*]   Scrub pages before returning them to system
>> 
>> From http://wiki.xen.org/wiki/Do%EF%BB%BFm0_Memory_%E2%80%94_Where_It_Has_Not_Gone , I thought this should be okay
>> 
>> But when trying to start a PV guest with 512MB mem, the machine (dom0) crashes with the stacktrace below (complete serial-log.txt attached).
>> 
>> From the:
>> "mapping kernel into physical memory
>> about to get started..."
>> 
>> I would almost say it's trying to reload dom0 ?
>> 
>> 
>> [  897.161119] device vif1.0 entered promiscuous mode
>> mapping kernel into physical memory
>> about to get started...
>> [  897.696619] xen_bridge: port 1(vif1.0) entered forwarding state
>> [  897.716219] xen_bridge: port 1(vif1.0) entered forwarding state
>> [  898.129465] ------------[ cut here ]------------
>> [  898.132209] kernel BUG at drivers/xen/balloon.c:359!
>> [  898.132209] invalid opcode: 0000 [#1] PREEMPT SMP 



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

From xen-devel-bounces@lists.xen.org Tue Sep 04 18:08:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Sep 2012 18:08:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T8xXD-00070a-Qc; Tue, 04 Sep 2012 18:07:35 +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 1T8xXC-00070V-ED
	for xen-devel@lists.xen.org; Tue, 04 Sep 2012 18:07:34 +0000
Received: from [85.158.143.35:36892] by server-1.bemta-4.messagelabs.com id
	5B/7E-12504-56346405; Tue, 04 Sep 2012 18:07:33 +0000
X-Env-Sender: ben.guthro@gmail.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1346782031!5712846!1
X-Originating-IP: [209.85.223.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28620 invoked from network); 4 Sep 2012 18:07:13 -0000
Received: from mail-ie0-f173.google.com (HELO mail-ie0-f173.google.com)
	(209.85.223.173)
	by server-2.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Sep 2012 18:07:13 -0000
Received: by iebc10 with SMTP id c10so6784814ieb.32
	for <xen-devel@lists.xen.org>; Tue, 04 Sep 2012 11:07: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;
	bh=lP1JhgXwvOgOn5r96C0AF4W5ffp0iwqsVYTiy5noDow=;
	b=d+24qyBNffHfXXb6qT3ALNCtoREf+kShYwQK1XVoTiCaBwrTAEzXuyGL1ZKyNLjpED
	IX+kET2fHxUw0i9xJZrdwo6qQPOCwdM2ZwKNxgekot+NRlUhgxE+Rgpl4avSW6/+v4G4
	tRJuJPtATOF6EzLMDE3JHNTU89o+eEBiraBbRnrxVLOjGe1tSHWvHz/b7H4b7BPUfoRb
	YuNjrwVpzoIwcdIoLY1afwgT72DJwUJb/RMEaIMAfwKMiTZqEBYXcuwuMUviDneCmng1
	nn33HbrYtMtieGmkT5+/e4hiLA99kx5jUqkwqyhmPETGXakLpxsR1FxZpE1j3vb1kQPq
	b/zA==
MIME-Version: 1.0
Received: by 10.43.9.3 with SMTP id ou3mr18520472icb.14.1346782031112; Tue, 04
	Sep 2012 11:07:11 -0700 (PDT)
Received: by 10.64.28.203 with HTTP; Tue, 4 Sep 2012 11:07:11 -0700 (PDT)
In-Reply-To: <143844933.20120904191941@eikelenboom.it>
References: <1136369816.20120904183757@eikelenboom.it>
	<20120904163347.GH23361@phenom.dumpdata.com>
	<143844933.20120904191941@eikelenboom.it>
Date: Tue, 4 Sep 2012 14:07:11 -0400
X-Google-Sender-Auth: DKwM2mltsCq-VzkV65K56nhnBkA
Message-ID: <CAOvdn6U_yHgtZwv9MWazdLbd3NLq3pwGXnZY5sL2UVBhV_FUoQ@mail.gmail.com>
From: Ben Guthro <ben@guthro.net>
To: Sander Eikelenboom <linux@eikelenboom.it>
Content-Type: multipart/mixed; boundary=bcaec50fe0ad8de98e04c8e420e1
Cc: xen-devel@lists.xen.org, robert.phillips@citrix.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] dom0 linux 3.6.0-rc4,
 crash due to ballooning althoug dom0_mem=X, max:X 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>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

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

We ran into the same issue, in newer kernels - but had not yet
submitted this fix.

One of the developers here came up with a fix (attached, and CC'ed
here) that fixes an issue where the p2m code reuses a structure member
where it shouldn't.
The patch adds a new "old_mfn"  member to the gnttab_map_grant_ref
structure, instead of re-using  dev_bus_addr.


If this also works for you, I can re-submit it with a Signed-off-by
line, if you prefer, Konrad.

Ben


On Tue, Sep 4, 2012 at 1:19 PM, Sander Eikelenboom <linux@eikelenboom.it> wrote:
>
> Tuesday, September 4, 2012, 6:33:47 PM, you wrote:
>
>> On Tue, Sep 04, 2012 at 06:37:57PM +0200, Sander Eikelenboom wrote:
>>> Hi Konrad,
>>>
>>> This seems to happen only on a intel machine i'm trying to setup as a development machine (haven't seen it on my amd).
>>> It boots fine, i have dom0_mem=1024M,max:1024M set, the machine has 2G of mem.
>
>> Is this only with Xen 4.2? As, does Xen 4.1 work?
>>>
>>> Dom0 and guest kernel are 3.6.0-rc4 with config:
>
>> If you back out:
>
>> f393387d160211f60398d58463a7e65
>> Author: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
>> Date:   Fri Aug 17 16:43:28 2012 -0400
>
>>     xen/setup: Fix one-off error when adding for-balloon PFNs to the P2M.
>
>> Do you see this bug? (Either with Xen 4.1 or Xen 4.2)?
>
> With c96aae1f7f393387d160211f60398d58463a7e65 reverted i still see this bug (with Xen 4.2).
>
> Will use the debug patch you mailed and send back the results ...
>
>
>>> [*] Xen memory balloon driver
>>> [*]   Scrub pages before returning them to system
>>>
>>> From http://wiki.xen.org/wiki/Do%EF%BB%BFm0_Memory_%E2%80%94_Where_It_Has_Not_Gone , I thought this should be okay
>>>
>>> But when trying to start a PV guest with 512MB mem, the machine (dom0) crashes with the stacktrace below (complete serial-log.txt attached).
>>>
>>> From the:
>>> "mapping kernel into physical memory
>>> about to get started..."
>>>
>>> I would almost say it's trying to reload dom0 ?
>>>
>>>
>>> [  897.161119] device vif1.0 entered promiscuous mode
>>> mapping kernel into physical memory
>>> about to get started...
>>> [  897.696619] xen_bridge: port 1(vif1.0) entered forwarding state
>>> [  897.716219] xen_bridge: port 1(vif1.0) entered forwarding state
>>> [  898.129465] ------------[ cut here ]------------
>>> [  898.132209] kernel BUG at drivers/xen/balloon.c:359!
>>> [  898.132209] invalid opcode: 0000 [#1] PREEMPT SMP
>
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

--bcaec50fe0ad8de98e04c8e420e1
Content-Type: application/octet-stream; name=gnttab_old_mfn
Content-Disposition: attachment; filename=gnttab_old_mfn
Content-Transfer-Encoding: base64
X-Attachment-Id: f_h6pb6np10

ZGlmZiAtLWdpdCBhL2FyY2gveDg2L3hlbi9wMm0uYyBiL2FyY2gveDg2L3hlbi9wMm0uYwppbmRl
eCBiYmFmNDgzLi4zMmRkNjg2IDEwMDY0NAotLS0gYS9hcmNoL3g4Ni94ZW4vcDJtLmMKKysrIGIv
YXJjaC94ODYveGVuL3AybS5jCkBAIC03MzUsOCArNzM1LDcgQEAgaW50IG0ycF9hZGRfb3ZlcnJp
ZGUodW5zaWduZWQgbG9uZyBtZm4sIHN0cnVjdCBwYWdlICpwYWdlLAogCiAJCQl4ZW5fbWNfaXNz
dWUoUEFSQVZJUlRfTEFaWV9NTVUpOwogCQl9Ci0JCS8qIGxldCdzIHVzZSBkZXZfYnVzX2FkZHIg
dG8gcmVjb3JkIHRoZSBvbGQgbWZuIGluc3RlYWQgKi8KLQkJa21hcF9vcC0+ZGV2X2J1c19hZGRy
ID0gcGFnZS0+aW5kZXg7CisJCWttYXBfb3AtPm9sZF9tZm4gPSBwYWdlLT5pbmRleDsKIAkJcGFn
ZS0+aW5kZXggPSAodW5zaWduZWQgbG9uZykga21hcF9vcDsKIAl9CiAJc3Bpbl9sb2NrX2lycXNh
dmUoJm0ycF9vdmVycmlkZV9sb2NrLCBmbGFncyk7CkBAIC03OTcsNyArNzk2LDcgQEAgaW50IG0y
cF9yZW1vdmVfb3ZlcnJpZGUoc3RydWN0IHBhZ2UgKnBhZ2UsIGJvb2wgY2xlYXJfcHRlKQogCWlm
IChjbGVhcl9wdGUpIHsKIAkJc3RydWN0IGdudHRhYl9tYXBfZ3JhbnRfcmVmICptYXBfb3AgPQog
CQkJKHN0cnVjdCBnbnR0YWJfbWFwX2dyYW50X3JlZiAqKSBwYWdlLT5pbmRleDsKLQkJc2V0X3Bo
eXNfdG9fbWFjaGluZShwZm4sIG1hcF9vcC0+ZGV2X2J1c19hZGRyKTsKKwkJc2V0X3BoeXNfdG9f
bWFjaGluZShwZm4sIG1hcF9vcC0+b2xkX21mbik7CiAJCWlmICghUGFnZUhpZ2hNZW0ocGFnZSkp
IHsKIAkJCXN0cnVjdCBtdWx0aWNhbGxfc3BhY2UgbWNzOwogCQkJc3RydWN0IGdudHRhYl91bm1h
cF9ncmFudF9yZWYgKnVubWFwX29wOwpkaWZmIC0tZ2l0IGEvaW5jbHVkZS94ZW4vaW50ZXJmYWNl
L2dyYW50X3RhYmxlLmggYi9pbmNsdWRlL3hlbi9pbnRlcmZhY2UvZ3JhbnRfdGFibGUuaAppbmRl
eCBhMTdkODQ0Li5jM2JiZGEzIDEwMDY0NAotLS0gYS9pbmNsdWRlL3hlbi9pbnRlcmZhY2UvZ3Jh
bnRfdGFibGUuaAorKysgYi9pbmNsdWRlL3hlbi9pbnRlcmZhY2UvZ3JhbnRfdGFibGUuaApAQCAt
MjY5LDYgKzI2OSw3IEBAIHN0cnVjdCBnbnR0YWJfbWFwX2dyYW50X3JlZiB7CiAgICAgaW50MTZf
dCAgc3RhdHVzOyAgICAgICAgICAgICAgLyogR05UU1RfKiAqLwogICAgIGdyYW50X2hhbmRsZV90
IGhhbmRsZTsKICAgICB1aW50NjRfdCBkZXZfYnVzX2FkZHI7CisgICAgdW5zaWduZWQgbG9uZyBv
bGRfbWZuOwogfTsKIERFRklORV9HVUVTVF9IQU5ETEVfU1RSVUNUKGdudHRhYl9tYXBfZ3JhbnRf
cmVmKTsKIAo=
--bcaec50fe0ad8de98e04c8e420e1
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--bcaec50fe0ad8de98e04c8e420e1--


From xen-devel-bounces@lists.xen.org Tue Sep 04 18:08:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Sep 2012 18:08:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T8xXD-00070a-Qc; Tue, 04 Sep 2012 18:07:35 +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 1T8xXC-00070V-ED
	for xen-devel@lists.xen.org; Tue, 04 Sep 2012 18:07:34 +0000
Received: from [85.158.143.35:36892] by server-1.bemta-4.messagelabs.com id
	5B/7E-12504-56346405; Tue, 04 Sep 2012 18:07:33 +0000
X-Env-Sender: ben.guthro@gmail.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1346782031!5712846!1
X-Originating-IP: [209.85.223.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28620 invoked from network); 4 Sep 2012 18:07:13 -0000
Received: from mail-ie0-f173.google.com (HELO mail-ie0-f173.google.com)
	(209.85.223.173)
	by server-2.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Sep 2012 18:07:13 -0000
Received: by iebc10 with SMTP id c10so6784814ieb.32
	for <xen-devel@lists.xen.org>; Tue, 04 Sep 2012 11:07: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;
	bh=lP1JhgXwvOgOn5r96C0AF4W5ffp0iwqsVYTiy5noDow=;
	b=d+24qyBNffHfXXb6qT3ALNCtoREf+kShYwQK1XVoTiCaBwrTAEzXuyGL1ZKyNLjpED
	IX+kET2fHxUw0i9xJZrdwo6qQPOCwdM2ZwKNxgekot+NRlUhgxE+Rgpl4avSW6/+v4G4
	tRJuJPtATOF6EzLMDE3JHNTU89o+eEBiraBbRnrxVLOjGe1tSHWvHz/b7H4b7BPUfoRb
	YuNjrwVpzoIwcdIoLY1afwgT72DJwUJb/RMEaIMAfwKMiTZqEBYXcuwuMUviDneCmng1
	nn33HbrYtMtieGmkT5+/e4hiLA99kx5jUqkwqyhmPETGXakLpxsR1FxZpE1j3vb1kQPq
	b/zA==
MIME-Version: 1.0
Received: by 10.43.9.3 with SMTP id ou3mr18520472icb.14.1346782031112; Tue, 04
	Sep 2012 11:07:11 -0700 (PDT)
Received: by 10.64.28.203 with HTTP; Tue, 4 Sep 2012 11:07:11 -0700 (PDT)
In-Reply-To: <143844933.20120904191941@eikelenboom.it>
References: <1136369816.20120904183757@eikelenboom.it>
	<20120904163347.GH23361@phenom.dumpdata.com>
	<143844933.20120904191941@eikelenboom.it>
Date: Tue, 4 Sep 2012 14:07:11 -0400
X-Google-Sender-Auth: DKwM2mltsCq-VzkV65K56nhnBkA
Message-ID: <CAOvdn6U_yHgtZwv9MWazdLbd3NLq3pwGXnZY5sL2UVBhV_FUoQ@mail.gmail.com>
From: Ben Guthro <ben@guthro.net>
To: Sander Eikelenboom <linux@eikelenboom.it>
Content-Type: multipart/mixed; boundary=bcaec50fe0ad8de98e04c8e420e1
Cc: xen-devel@lists.xen.org, robert.phillips@citrix.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] dom0 linux 3.6.0-rc4,
 crash due to ballooning althoug dom0_mem=X, max:X 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>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

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

We ran into the same issue, in newer kernels - but had not yet
submitted this fix.

One of the developers here came up with a fix (attached, and CC'ed
here) that fixes an issue where the p2m code reuses a structure member
where it shouldn't.
The patch adds a new "old_mfn"  member to the gnttab_map_grant_ref
structure, instead of re-using  dev_bus_addr.


If this also works for you, I can re-submit it with a Signed-off-by
line, if you prefer, Konrad.

Ben


On Tue, Sep 4, 2012 at 1:19 PM, Sander Eikelenboom <linux@eikelenboom.it> wrote:
>
> Tuesday, September 4, 2012, 6:33:47 PM, you wrote:
>
>> On Tue, Sep 04, 2012 at 06:37:57PM +0200, Sander Eikelenboom wrote:
>>> Hi Konrad,
>>>
>>> This seems to happen only on a intel machine i'm trying to setup as a development machine (haven't seen it on my amd).
>>> It boots fine, i have dom0_mem=1024M,max:1024M set, the machine has 2G of mem.
>
>> Is this only with Xen 4.2? As, does Xen 4.1 work?
>>>
>>> Dom0 and guest kernel are 3.6.0-rc4 with config:
>
>> If you back out:
>
>> f393387d160211f60398d58463a7e65
>> Author: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
>> Date:   Fri Aug 17 16:43:28 2012 -0400
>
>>     xen/setup: Fix one-off error when adding for-balloon PFNs to the P2M.
>
>> Do you see this bug? (Either with Xen 4.1 or Xen 4.2)?
>
> With c96aae1f7f393387d160211f60398d58463a7e65 reverted i still see this bug (with Xen 4.2).
>
> Will use the debug patch you mailed and send back the results ...
>
>
>>> [*] Xen memory balloon driver
>>> [*]   Scrub pages before returning them to system
>>>
>>> From http://wiki.xen.org/wiki/Do%EF%BB%BFm0_Memory_%E2%80%94_Where_It_Has_Not_Gone , I thought this should be okay
>>>
>>> But when trying to start a PV guest with 512MB mem, the machine (dom0) crashes with the stacktrace below (complete serial-log.txt attached).
>>>
>>> From the:
>>> "mapping kernel into physical memory
>>> about to get started..."
>>>
>>> I would almost say it's trying to reload dom0 ?
>>>
>>>
>>> [  897.161119] device vif1.0 entered promiscuous mode
>>> mapping kernel into physical memory
>>> about to get started...
>>> [  897.696619] xen_bridge: port 1(vif1.0) entered forwarding state
>>> [  897.716219] xen_bridge: port 1(vif1.0) entered forwarding state
>>> [  898.129465] ------------[ cut here ]------------
>>> [  898.132209] kernel BUG at drivers/xen/balloon.c:359!
>>> [  898.132209] invalid opcode: 0000 [#1] PREEMPT SMP
>
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

--bcaec50fe0ad8de98e04c8e420e1
Content-Type: application/octet-stream; name=gnttab_old_mfn
Content-Disposition: attachment; filename=gnttab_old_mfn
Content-Transfer-Encoding: base64
X-Attachment-Id: f_h6pb6np10

ZGlmZiAtLWdpdCBhL2FyY2gveDg2L3hlbi9wMm0uYyBiL2FyY2gveDg2L3hlbi9wMm0uYwppbmRl
eCBiYmFmNDgzLi4zMmRkNjg2IDEwMDY0NAotLS0gYS9hcmNoL3g4Ni94ZW4vcDJtLmMKKysrIGIv
YXJjaC94ODYveGVuL3AybS5jCkBAIC03MzUsOCArNzM1LDcgQEAgaW50IG0ycF9hZGRfb3ZlcnJp
ZGUodW5zaWduZWQgbG9uZyBtZm4sIHN0cnVjdCBwYWdlICpwYWdlLAogCiAJCQl4ZW5fbWNfaXNz
dWUoUEFSQVZJUlRfTEFaWV9NTVUpOwogCQl9Ci0JCS8qIGxldCdzIHVzZSBkZXZfYnVzX2FkZHIg
dG8gcmVjb3JkIHRoZSBvbGQgbWZuIGluc3RlYWQgKi8KLQkJa21hcF9vcC0+ZGV2X2J1c19hZGRy
ID0gcGFnZS0+aW5kZXg7CisJCWttYXBfb3AtPm9sZF9tZm4gPSBwYWdlLT5pbmRleDsKIAkJcGFn
ZS0+aW5kZXggPSAodW5zaWduZWQgbG9uZykga21hcF9vcDsKIAl9CiAJc3Bpbl9sb2NrX2lycXNh
dmUoJm0ycF9vdmVycmlkZV9sb2NrLCBmbGFncyk7CkBAIC03OTcsNyArNzk2LDcgQEAgaW50IG0y
cF9yZW1vdmVfb3ZlcnJpZGUoc3RydWN0IHBhZ2UgKnBhZ2UsIGJvb2wgY2xlYXJfcHRlKQogCWlm
IChjbGVhcl9wdGUpIHsKIAkJc3RydWN0IGdudHRhYl9tYXBfZ3JhbnRfcmVmICptYXBfb3AgPQog
CQkJKHN0cnVjdCBnbnR0YWJfbWFwX2dyYW50X3JlZiAqKSBwYWdlLT5pbmRleDsKLQkJc2V0X3Bo
eXNfdG9fbWFjaGluZShwZm4sIG1hcF9vcC0+ZGV2X2J1c19hZGRyKTsKKwkJc2V0X3BoeXNfdG9f
bWFjaGluZShwZm4sIG1hcF9vcC0+b2xkX21mbik7CiAJCWlmICghUGFnZUhpZ2hNZW0ocGFnZSkp
IHsKIAkJCXN0cnVjdCBtdWx0aWNhbGxfc3BhY2UgbWNzOwogCQkJc3RydWN0IGdudHRhYl91bm1h
cF9ncmFudF9yZWYgKnVubWFwX29wOwpkaWZmIC0tZ2l0IGEvaW5jbHVkZS94ZW4vaW50ZXJmYWNl
L2dyYW50X3RhYmxlLmggYi9pbmNsdWRlL3hlbi9pbnRlcmZhY2UvZ3JhbnRfdGFibGUuaAppbmRl
eCBhMTdkODQ0Li5jM2JiZGEzIDEwMDY0NAotLS0gYS9pbmNsdWRlL3hlbi9pbnRlcmZhY2UvZ3Jh
bnRfdGFibGUuaAorKysgYi9pbmNsdWRlL3hlbi9pbnRlcmZhY2UvZ3JhbnRfdGFibGUuaApAQCAt
MjY5LDYgKzI2OSw3IEBAIHN0cnVjdCBnbnR0YWJfbWFwX2dyYW50X3JlZiB7CiAgICAgaW50MTZf
dCAgc3RhdHVzOyAgICAgICAgICAgICAgLyogR05UU1RfKiAqLwogICAgIGdyYW50X2hhbmRsZV90
IGhhbmRsZTsKICAgICB1aW50NjRfdCBkZXZfYnVzX2FkZHI7CisgICAgdW5zaWduZWQgbG9uZyBv
bGRfbWZuOwogfTsKIERFRklORV9HVUVTVF9IQU5ETEVfU1RSVUNUKGdudHRhYl9tYXBfZ3JhbnRf
cmVmKTsKIAo=
--bcaec50fe0ad8de98e04c8e420e1
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--bcaec50fe0ad8de98e04c8e420e1--


From xen-devel-bounces@lists.xen.org Tue Sep 04 18:09:45 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Sep 2012 18: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 1T8xYv-00074V-AO; Tue, 04 Sep 2012 18:09: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 1T8xYt-00074M-IV
	for xen-devel@lists.xen.org; Tue, 04 Sep 2012 18:09:19 +0000
Received: from [85.158.139.83:28196] by server-12.bemta-5.messagelabs.com id
	85/8D-18300-EC346405; Tue, 04 Sep 2012 18:09:18 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1346782156!24605126!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDczNjI0OQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7227 invoked from network); 4 Sep 2012 18:09:18 -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; 4 Sep 2012 18:09:18 -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 q84I9912005199
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 4 Sep 2012 18:09:10 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
	q84I98TZ017470
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 4 Sep 2012 18:09:09 GMT
Received: from abhmt112.oracle.com (abhmt112.oracle.com [141.146.116.64])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q84I98DE026420; Tue, 4 Sep 2012 13:09:08 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 04 Sep 2012 11:09:08 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 52A62402BA; Tue,  4 Sep 2012 13:58:41 -0400 (EDT)
Date: Tue, 4 Sep 2012 13:58:41 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Sander Eikelenboom <linux@eikelenboom.it>
Message-ID: <20120904175841.GA10379@phenom.dumpdata.com>
References: <1136369816.20120904183757@eikelenboom.it>
	<20120904163903.GI23361@phenom.dumpdata.com>
	<8328705.20120904200241@eikelenboom.it>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <8328705.20120904200241@eikelenboom.it>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] dom0 linux 3.6.0-rc4,
 crash due to ballooning althoug dom0_mem=X, max:X set
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Sep 04, 2012 at 08:02:41PM +0200, Sander Eikelenboom wrote:
> 
> Tuesday, September 4, 2012, 6:39:03 PM, you wrote:
> 
> > On Tue, Sep 04, 2012 at 06:37:57PM +0200, Sander Eikelenboom wrote:
> >> Hi Konrad,
> >> 
> >> This seems to happen only on a intel machine i'm trying to setup as a development machine (haven't seen it on my amd).
> >> It boots fine, i have dom0_mem=1024M,max:1024M set, the machine has 2G of mem.
> >> 
> >> Dom0 and guest kernel are 3.6.0-rc4 with config:
> >> [*] Xen memory balloon driver
> >> [*]   Scrub pages before returning them to system
> 
> > Can you also try this patch out and provide the full log (bootup and such). Thanks!
> 
> After applying this patch and due to the removal of the BUG_ON the domU boots and is reachable by SSH.
> Serial log attached.

Wow. That is a lot of .. And if you use Xen 4.1 it works fine?

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

From xen-devel-bounces@lists.xen.org Tue Sep 04 18:09:45 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Sep 2012 18: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 1T8xYv-00074V-AO; Tue, 04 Sep 2012 18:09: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 1T8xYt-00074M-IV
	for xen-devel@lists.xen.org; Tue, 04 Sep 2012 18:09:19 +0000
Received: from [85.158.139.83:28196] by server-12.bemta-5.messagelabs.com id
	85/8D-18300-EC346405; Tue, 04 Sep 2012 18:09:18 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1346782156!24605126!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDczNjI0OQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7227 invoked from network); 4 Sep 2012 18:09:18 -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; 4 Sep 2012 18:09:18 -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 q84I9912005199
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 4 Sep 2012 18:09:10 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
	q84I98TZ017470
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 4 Sep 2012 18:09:09 GMT
Received: from abhmt112.oracle.com (abhmt112.oracle.com [141.146.116.64])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q84I98DE026420; Tue, 4 Sep 2012 13:09:08 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 04 Sep 2012 11:09:08 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 52A62402BA; Tue,  4 Sep 2012 13:58:41 -0400 (EDT)
Date: Tue, 4 Sep 2012 13:58:41 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Sander Eikelenboom <linux@eikelenboom.it>
Message-ID: <20120904175841.GA10379@phenom.dumpdata.com>
References: <1136369816.20120904183757@eikelenboom.it>
	<20120904163903.GI23361@phenom.dumpdata.com>
	<8328705.20120904200241@eikelenboom.it>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <8328705.20120904200241@eikelenboom.it>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] dom0 linux 3.6.0-rc4,
 crash due to ballooning althoug dom0_mem=X, max:X set
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Sep 04, 2012 at 08:02:41PM +0200, Sander Eikelenboom wrote:
> 
> Tuesday, September 4, 2012, 6:39:03 PM, you wrote:
> 
> > On Tue, Sep 04, 2012 at 06:37:57PM +0200, Sander Eikelenboom wrote:
> >> Hi Konrad,
> >> 
> >> This seems to happen only on a intel machine i'm trying to setup as a development machine (haven't seen it on my amd).
> >> It boots fine, i have dom0_mem=1024M,max:1024M set, the machine has 2G of mem.
> >> 
> >> Dom0 and guest kernel are 3.6.0-rc4 with config:
> >> [*] Xen memory balloon driver
> >> [*]   Scrub pages before returning them to system
> 
> > Can you also try this patch out and provide the full log (bootup and such). Thanks!
> 
> After applying this patch and due to the removal of the BUG_ON the domU boots and is reachable by SSH.
> Serial log attached.

Wow. That is a lot of .. And if you use Xen 4.1 it works fine?

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

From xen-devel-bounces@lists.xen.org Tue Sep 04 18:10:29 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Sep 2012 18:10: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 1T8xZe-000785-QC; Tue, 04 Sep 2012 18:10:06 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <linux@eikelenboom.it>) id 1T8xSq-0006zC-OJ
	for xen-devel@lists.xen.org; Tue, 04 Sep 2012 18:03:06 +0000
Received: from [85.158.139.83:61107] by server-6.bemta-5.messagelabs.com id
	7D/D9-21336-75246405; Tue, 04 Sep 2012 18:03:03 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-7.tower-182.messagelabs.com!1346781767!24604452!1
X-Originating-IP: [188.40.164.121]
X-SpamReason: No, hits=2.6 required=7.0 tests=BODY_RANDOM_LONG, UNIQUE_WORDS
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25357 invoked from network); 4 Sep 2012 18:02:47 -0000
Received: from static.121.164.40.188.clients.your-server.de (HELO
	smtp.eikelenboom.it) (188.40.164.121)
	by server-7.tower-182.messagelabs.com with AES256-SHA encrypted SMTP;
	4 Sep 2012 18:02:47 -0000
Received: from 128-64-ftth.onsneteindhoven.nl ([88.159.64.128]:56377
	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 1T8xPV-00056Z-0p; Tue, 04 Sep 2012 19:59:38 +0200
Date: Tue, 4 Sep 2012 20:02:41 +0200
From: Sander Eikelenboom <linux@eikelenboom.it>
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <8328705.20120904200241@eikelenboom.it>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
In-Reply-To: <20120904163903.GI23361@phenom.dumpdata.com>
References: <1136369816.20120904183757@eikelenboom.it>
	<20120904163903.GI23361@phenom.dumpdata.com>
MIME-Version: 1.0
Content-Type: multipart/mixed;
 boundary="----------0CA04210C17B3F3A8"
X-Mailman-Approved-At: Tue, 04 Sep 2012 18:10:05 +0000
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] dom0 linux 3.6.0-rc4,
	crash due to ballooning althoug dom0_mem=X, max:X 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>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

------------0CA04210C17B3F3A8
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit


Tuesday, September 4, 2012, 6:39:03 PM, you wrote:

> On Tue, Sep 04, 2012 at 06:37:57PM +0200, Sander Eikelenboom wrote:
>> Hi Konrad,
>> 
>> This seems to happen only on a intel machine i'm trying to setup as a development machine (haven't seen it on my amd).
>> It boots fine, i have dom0_mem=1024M,max:1024M set, the machine has 2G of mem.
>> 
>> Dom0 and guest kernel are 3.6.0-rc4 with config:
>> [*] Xen memory balloon driver
>> [*]   Scrub pages before returning them to system

> Can you also try this patch out and provide the full log (bootup and such). Thanks!

After applying this patch and due to the removal of the BUG_ON the domU boots and is reachable by SSH.
Serial log attached.



> diff --git a/drivers/xen/balloon.c b/drivers/xen/balloon.c
> index 31ab82f..871a93c 100644
> --- a/drivers/xen/balloon.c
> +++ b/drivers/xen/balloon.c
> @@ -355,8 +355,12 @@ static enum bp_state increase_reservation(unsigned long nr_pages)
>                 BUG_ON(page == NULL);
>  
>                 pfn = page_to_pfn(page);
> -               BUG_ON(!xen_feature(XENFEAT_auto_translated_physmap) &&
> -                      phys_to_machine_mapping_valid(pfn));
> +               if (!xen_feature(XENFEAT_auto_translated_physmap)) {
> +                       if (phys_to_machine_mapping_valid(pfn)) {
> +                               printk(KERN_DEBUG "%lx is %lx!\n", pfn, get_phys_to_machine(pfn));
> +                               continue;
> +                       }
> +               }
>  
>                 set_phys_to_machine(pfn, frame_list[i]);
>  
> @@ -572,6 +576,7 @@ static void __init balloon_add_region(unsigned long start_pfn,
>          */
>         extra_pfn_end = min(max_pfn, start_pfn + pages);
>  
> +       printk(KERN_INFO "%s: [%lx->%lx]\n", __func__, start_pfn, extra_pfn_end);
>         for (pfn = start_pfn; pfn < extra_pfn_end; pfn++) {
>                 page = pfn_to_page(pfn);
>                 /* totalram_pages and totalhigh_pages do not

------------0CA04210C17B3F3A8
Content-Type: text/plain;
 name="serial-log.txt"
Content-transfer-encoding: base64
Content-Disposition: attachment;
 filename="serial-log.txt"

IF9fICBfXyAgICAgICAgICAgIF8gIF8gICAgX19fXyAgICBfX18gICAgICAgICAgICAgIF8g
IF8gICAgICAgICAgICAgICAgICAgICANCiBcIFwvIC9fX18gXyBfXyAgIHwgfHwgfCAgfF9f
XyBcICAvIF8gXCAgICBfIF9fIF9fX3wgfHwgfCAgICAgXyBfXyAgXyBfXyBfX18gDQogIFwg
IC8vIF8gXCAnXyBcICB8IHx8IHxfICAgX18pIHx8IHwgfCB8X198ICdfXy8gX198IHx8IHxf
IF9ffCAnXyBcfCAnX18vIF8gXA0KICAvICBcICBfXy8gfCB8IHwgfF9fICAgX3wgLyBfXy8g
fCB8X3wgfF9ffCB8IHwgKF9ffF9fICAgX3xfX3wgfF8pIHwgfCB8ICBfXy8NCiAvXy9cX1xf
X198X3wgfF98ICAgIHxffChfKV9fX19fKF8pX19fLyAgIHxffCAgXF9fX3wgIHxffCAgICB8
IC5fXy98X3wgIFxfX198DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgfF98ICAgICAgICAgICAgIA0KKFhFTikgWGVuIHZl
cnNpb24gNC4yLjAtcmM0LXByZSAocm9vdEApIChnY2MgKERlYmlhbiA0LjQuNS04KSA0LjQu
NSkgTW9uIFNlcCAgMyAxODozMjowNyBDRVNUIDIwMTINCihYRU4pIExhdGVzdCBDaGFuZ2VT
ZXQ6IFRodSBBdWcgMzAgMTg6MTc6MjAgMjAxMiArMDEwMCAyNTc5MTo5ZTU2NjVmOWY0MzAN
CihYRU4pIEJvb3Rsb2FkZXI6IEdSVUIgMS45OCsyMDEwMDgwNC0xNCtzcXVlZXplMQ0KKFhF
TikgQ29tbWFuZCBsaW5lOiBkb20wX21lbT0xMDI0TSxtYXg6MTAyNE0gbG9nbHZsPWFsbCBs
b2dsdmxfZ3Vlc3Q9YWxsIGNvbnNvbGVfdGltZXN0YW1wcyB2Z2E9Z2Z4LTgwMHg2MDB4OCBu
b3JlYm9vdCBkZWJ1ZyBsYXBpYz1kZWJ1ZyBhcGljX3ZlcmJvc2l0eT1kZWJ1ZyBhcGljPWRl
YnVnIGlvbW11PW9uLHZlcmJvc2UsZGVidWcgY29tMT0zODQwMCw4bjEgY29uc29sZT12Z2Es
Y29tMQ0KKFhFTikgVmlkZW8gaW5mb3JtYXRpb246DQooWEVOKSAgVkdBIGlzIGdyYXBoaWNz
IG1vZGUgODAweDYwMCwgOCBicHANCihYRU4pICBWQkUvRERDIG1ldGhvZHM6IG5vbmU7IEVE
SUQgdHJhbnNmZXIgdGltZTogMCBzZWNvbmRzDQooWEVOKSAgRURJRCBpbmZvIG5vdCByZXRy
aWV2ZWQgYmVjYXVzZSBubyBEREMgcmV0cmlldmFsIG1ldGhvZCBkZXRlY3RlZA0KKFhFTikg
RGlzYyBpbmZvcm1hdGlvbjoNCihYRU4pICBGb3VuZCAwIE1CUiBzaWduYXR1cmVzDQooWEVO
KSAgRm91bmQgMSBFREQgaW5mb3JtYXRpb24gc3RydWN0dXJlcw0KKFhFTikgWGVuLWU4MjAg
UkFNIG1hcDoNCihYRU4pICAwMDAwMDAwMDAwMDAwMDAwIC0gMDAwMDAwMDAwMDA5ZTgwMCAo
dXNhYmxlKQ0KKFhFTikgIDAwMDAwMDAwMDAwOWU4MDAgLSAwMDAwMDAwMDAwMGEwMDAwIChy
ZXNlcnZlZCkNCihYRU4pICAwMDAwMDAwMDAwMGU0MDAwIC0gMDAwMDAwMDAwMDEwMDAwMCAo
cmVzZXJ2ZWQpDQooWEVOKSAgMDAwMDAwMDAwMDEwMDAwMCAtIDAwMDAwMDAwN2VlNzAwMDAg
KHVzYWJsZSkNCihYRU4pICAwMDAwMDAwMDdlZTcwMDAwIC0gMDAwMDAwMDA3ZWU3ZTAwMCAo
QUNQSSBkYXRhKQ0KKFhFTikgIDAwMDAwMDAwN2VlN2UwMDAgLSAwMDAwMDAwMDdlZWQwMDAw
IChBQ1BJIE5WUykNCihYRU4pICAwMDAwMDAwMDdlZWQwMDAwIC0gMDAwMDAwMDA3ZWYwMDAw
MCAocmVzZXJ2ZWQpDQooWEVOKSAgMDAwMDAwMDBmZWQwMDAwMCAtIDAwMDAwMDAwZmVkMDEx
MDAgKHJlc2VydmVkKQ0KKFhFTikgIDAwMDAwMDAwZmVkMDIwMDAgLSAwMDAwMDAwMGZlZDE0
YzAwIChyZXNlcnZlZCkNCihYRU4pICAwMDAwMDAwMGZlZDIwMDAwIC0gMDAwMDAwMDBmZWQ0
MDAwMCAocmVzZXJ2ZWQpDQooWEVOKSAgMDAwMDAwMDBmZWUwMDAwMCAtIDAwMDAwMDAwZmVl
MDEwMDAgKHJlc2VydmVkKQ0KKFhFTikgIDAwMDAwMDAwZmZlMDAwMDAgLSAwMDAwMDAwMTAw
MDAwMDAwIChyZXNlcnZlZCkNCihYRU4pIFN5c3RlbSBSQU06IDIwMzBNQiAoMjA3ODc3NmtC
KQ0KKFhFTikgQUNQSTogUlNEUCAwMDBGQjA4MCwgMDAyNCAocjIgQUNQSUFNKQ0KKFhFTikg
QUNQSTogWFNEVCA3RUU3MDEwMCwgMDA1QyAocjEgQV9NX0lfIE9FTVhTRFQgICA1MDAxMDI1
IE1TRlQgICAgICAgOTcpDQooWEVOKSBBQ1BJOiBGQUNQIDdFRTcwMjkwLCAwMEY0IChyMyBB
X01fSV8gT0VNRkFDUCAgIDUwMDEwMjUgTVNGVCAgICAgICA5NykNCihYRU4pIEFDUEk6IERT
RFQgN0VFNzA0NDAsIDg0MUYgKHIxICBBMTA2NSBBMTA2NTAwMCAgICAgICAgMCBJTlRMIDIw
MDYwMTEzKQ0KKFhFTikgQUNQSTogRkFDUyA3RUU3RTAwMCwgMDA0MA0KKFhFTikgQUNQSTog
QVBJQyA3RUU3MDM5MCwgMDA2QyAocjEgQV9NX0lfIE9FTUFQSUMgICA1MDAxMDI1IE1TRlQg
ICAgICAgOTcpDQooWEVOKSBBQ1BJOiBNQ0ZHIDdFRTcwNDAwLCAwMDNDIChyMSBBX01fSV8g
T0VNTUNGRyAgIDUwMDEwMjUgTVNGVCAgICAgICA5NykNCihYRU4pIEFDUEk6IE9FTUIgN0VF
N0UwNDAsIDAwODkgKHIxIEFfTV9JXyBBTUlfT0VNICAgNTAwMTAyNSBNU0ZUICAgICAgIDk3
KQ0KKFhFTikgQUNQSTogSFBFVCA3RUU3ODg2MCwgMDAzOCAocjEgQV9NX0lfIE9FTUhQRVQg
ICA1MDAxMDI1IE1TRlQgICAgICAgOTcpDQooWEVOKSBBQ1BJOiBHU0NJIDdFRTdFMEQwLCAy
MDI0IChyMSBBX01fSV8gR01DSFNDSSAgIDUwMDEwMjUgTVNGVCAgICAgICA5NykNCihYRU4p
IEFDUEk6IFNTRFQgN0VFODBBMDAsIDBBN0MgKHIxIERwZ1BtbSAgICBDcHVQbSAgICAgICAx
MiBJTlRMIDIwMDYwMTEzKQ0KKFhFTikgTm8gTlVNQSBjb25maWd1cmF0aW9uIGZvdW5kDQoo
WEVOKSBGYWtpbmcgYSBub2RlIGF0IDAwMDAwMDAwMDAwMDAwMDAtMDAwMDAwMDA3ZWU3MDAw
MA0KKFhFTikgRG9tYWluIGhlYXAgaW5pdGlhbGlzZWQNCihYRU4pIHZlc2FmYjogZnJhbWVi
dWZmZXIgYXQgMHhmZDgwMDAwMCwgbWFwcGVkIHRvIDB4ZmZmZjgyYzAwMDAwMDAwMCwgdXNp
bmcgMjA0OGssIHRvdGFsIDQwOTZrDQooWEVOKSB2ZXNhZmI6IG1vZGUgaXMgODAweDYwMHg4
LCBsaW5lbGVuZ3RoPTgwMCwgZm9udCA4eDgNCihYRU4pIHZlc2FmYjogUHNldWRvY29sb3I6
IHNpemU9Njo2OjY6Niwgc2hpZnQ9MDowOjA6MA0KKFhFTikgZm91bmQgU01QIE1QLXRhYmxl
IGF0IDAwMGZmNzgwDQooWEVOKSBETUkgcHJlc2VudC4NCihYRU4pIEFQSUMgYm9vdCBzdGF0
ZSBpcyAneGFwaWMnDQooWEVOKSBVc2luZyBBUElDIGRyaXZlciBkZWZhdWx0DQooWEVOKSBB
Q1BJOiBQTS1UaW1lciBJTyBQb3J0OiAweDgwOA0KKFhFTikgQUNQSTogQUNQSSBTTEVFUCBJ
TkZPOiBwbTF4X2NudFs4MDQsMF0sIHBtMXhfZXZ0WzgwMCwwXQ0KKFhFTikgQUNQSTogICAg
ICAgICAgICAgICAgICB3YWtldXBfdmVjWzdlZTdlMDBjXSwgdmVjX3NpemVbMjBdDQooWEVO
KSBBQ1BJOiBMb2NhbCBBUElDIGFkZHJlc3MgMHhmZWUwMDAwMA0KKFhFTikgQUNQSTogTEFQ
SUMgKGFjcGlfaWRbMHgwMV0gbGFwaWNfaWRbMHgwMF0gZW5hYmxlZCkNCihYRU4pIFByb2Nl
c3NvciAjMCA3OjcgQVBJQyB2ZXJzaW9uIDIwDQooWEVOKSBBQ1BJOiBMQVBJQyAoYWNwaV9p
ZFsweDAyXSBsYXBpY19pZFsweDAxXSBlbmFibGVkKQ0KKFhFTikgUHJvY2Vzc29yICMxIDc6
NyBBUElDIHZlcnNpb24gMjANCihYRU4pIEFDUEk6IExBUElDIChhY3BpX2lkWzB4MDNdIGxh
cGljX2lkWzB4MDJdIGVuYWJsZWQpDQooWEVOKSBQcm9jZXNzb3IgIzIgNzo3IEFQSUMgdmVy
c2lvbiAyMA0KKFhFTikgQUNQSTogTEFQSUMgKGFjcGlfaWRbMHgwNF0gbGFwaWNfaWRbMHgw
M10gZW5hYmxlZCkNCihYRU4pIFByb2Nlc3NvciAjMyA3OjcgQVBJQyB2ZXJzaW9uIDIwDQoo
WEVOKSBBQ1BJOiBJT0FQSUMgKGlkWzB4MDRdIGFkZHJlc3NbMHhmZWMwMDAwMF0gZ3NpX2Jh
c2VbMF0pDQooWEVOKSBJT0FQSUNbMF06IGFwaWNfaWQgNCwgdmVyc2lvbiAzMiwgYWRkcmVz
cyAweGZlYzAwMDAwLCBHU0kgMC0yMw0KKFhFTikgQUNQSTogSU5UX1NSQ19PVlIgKGJ1cyAw
IGJ1c19pcnEgMCBnbG9iYWxfaXJxIDIgZGZsIGRmbCkNCihYRU4pIEFDUEk6IElOVF9TUkNf
T1ZSIChidXMgMCBidXNfaXJxIDkgZ2xvYmFsX2lycSA5IGhpZ2ggbGV2ZWwpDQooWEVOKSBB
Q1BJOiBJUlEwIHVzZWQgYnkgb3ZlcnJpZGUuDQooWEVOKSBBQ1BJOiBJUlEyIHVzZWQgYnkg
b3ZlcnJpZGUuDQooWEVOKSBBQ1BJOiBJUlE5IHVzZWQgYnkgb3ZlcnJpZGUuDQooWEVOKSBF
bmFibGluZyBBUElDIG1vZGU6ICBGbGF0LiAgVXNpbmcgMSBJL08gQVBJQ3MNCihYRU4pIEFD
UEk6IEhQRVQgaWQ6IDB4ODA4NmE3MDEgYmFzZTogMHhmZWQwMDAwMA0KKFhFTikgVGFibGUg
aXMgbm90IGZvdW5kIQ0KKFhFTikgVXNpbmcgQUNQSSAoTUFEVCkgZm9yIFNNUCBjb25maWd1
cmF0aW9uIGluZm9ybWF0aW9uDQooWEVOKSBTTVA6IEFsbG93aW5nIDQgQ1BVcyAoMCBob3Rw
bHVnIENQVXMpDQooWEVOKSBtYXBwZWQgQVBJQyB0byBmZmZmODJjM2ZmZGZlMDAwIChmZWUw
MDAwMCkNCihYRU4pIG1hcHBlZCBJT0FQSUMgdG8gZmZmZjgyYzNmZmRmZDAwMCAoZmVjMDAw
MDApDQooWEVOKSBJUlEgbGltaXRzOiAyNCBHU0ksIDc2MCBNU0kvTVNJLVgNCihYRU4pIFVz
aW5nIHNjaGVkdWxlcjogU01QIENyZWRpdCBTY2hlZHVsZXIgKGNyZWRpdCkNCihYRU4pIERl
dGVjdGVkIDI2NjYuNDQzIE1IeiBwcm9jZXNzb3IuDQooWEVOKSBJbml0aW5nIG1lbW9yeSBz
aGFyaW5nLg0KKFhFTikgeHN0YXRlX2luaXQ6IHVzaW5nIGNudHh0X3NpemU6IDB4MjQwIGFu
ZCBzdGF0ZXM6IDB4Mw0KKFhFTikgbWNlX2ludGVsLmM6MTIzOTogTUNBIENhcGFiaWxpdHk6
IEJDQVNUIDEgU0VSIDAgQ01DSSAwIGZpcnN0YmFuayAxIGV4dGVuZGVkIE1DRSBNU1IgMA0K
KFhFTikgSW50ZWwgbWFjaGluZSBjaGVjayByZXBvcnRpbmcgZW5hYmxlZA0KKFhFTikgUENJ
OiBNQ0ZHIGNvbmZpZ3VyYXRpb24gMDogYmFzZSBlMDAwMDAwMCBzZWdtZW50IDAwMDAgYnVz
ZXMgMDAgLSBmZg0KKFhFTikgUENJOiBOb3QgdXNpbmcgTUNGRyBmb3Igc2VnbWVudCAwMDAw
IGJ1cyAwMC1mZg0KKFhFTikgSS9PIHZpcnR1YWxpc2F0aW9uIGRpc2FibGVkDQooWEVOKSBH
ZXR0aW5nIFZFUlNJT046IDUwMDE0DQooWEVOKSBHZXR0aW5nIFZFUlNJT046IDUwMDE0DQoo
WEVOKSBHZXR0aW5nIElEOiAwDQooWEVOKSBHZXR0aW5nIExWVDA6IDcwMA0KKFhFTikgR2V0
dGluZyBMVlQxOiA0MDANCihYRU4pIGVuYWJsZWQgRXh0SU5UIG9uIENQVSMwDQooWEVOKSBF
TkFCTElORyBJTy1BUElDIElSUXMNCihYRU4pICAtPiBVc2luZyBuZXcgQUNLIG1ldGhvZA0K
KFhFTikgaW5pdCBJT19BUElDIElSUXMNCihYRU4pICBJTy1BUElDIChhcGljaWQtcGluKSA0
LTAsIDQtMTYsIDQtMTcsIDQtMTgsIDQtMTksIDQtMjAsIDQtMjEsIDQtMjIsIDQtMjMgbm90
IGNvbm5lY3RlZC4NCihYRU4pIC4uVElNRVI6IHZlY3Rvcj0weEYwIGFwaWMxPTAgcGluMT0y
IGFwaWMyPS0xIHBpbjI9LTENCihYRU4pIG51bWJlciBvZiBNUCBJUlEgc291cmNlczogMTUu
DQooWEVOKSBudW1iZXIgb2YgSU8tQVBJQyAjNCByZWdpc3RlcnM6IDI0Lg0KKFhFTikgdGVz
dGluZyB0aGUgSU8gQVBJQy4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uDQooWEVOKSBJTyBBUElD
ICM0Li4uLi4uDQooWEVOKSAuLi4uIHJlZ2lzdGVyICMwMDogMDQwMDAwMDANCihYRU4pIC4u
Li4uLi4gICAgOiBwaHlzaWNhbCBBUElDIGlkOiAwNA0KKFhFTikgLi4uLi4uLiAgICA6IERl
bGl2ZXJ5IFR5cGU6IDANCihYRU4pIC4uLi4uLi4gICAgOiBMVFMgICAgICAgICAgOiAwDQoo
WEVOKSAuLi4uIHJlZ2lzdGVyICMwMTogMDAxNzAwMjANCihYRU4pIC4uLi4uLi4gICAgIDog
bWF4IHJlZGlyZWN0aW9uIGVudHJpZXM6IDAwMTcNCihYRU4pIC4uLi4uLi4gICAgIDogUFJR
IGltcGxlbWVudGVkOiAwDQooWEVOKSAuLi4uLi4uICAgICA6IElPIEFQSUMgdmVyc2lvbjog
MDAyMA0KKFhFTikgLi4uLiBJUlEgcmVkaXJlY3Rpb24gdGFibGU6DQooWEVOKSAgTlIgTG9n
IFBoeSBNYXNrIFRyaWcgSVJSIFBvbCBTdGF0IERlc3QgRGVsaSBWZWN0OiAgIA0KKFhFTikg
IDAwIDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDAgICAgMDANCihYRU4p
ICAwMSAwMDEgMDEgIDAgICAgMCAgICAwICAgMCAgIDAgICAgMSAgICAxICAgIDI4DQooWEVO
KSAgMDIgMDAxIDAxICAwICAgIDAgICAgMCAgIDAgICAwICAgIDEgICAgMSAgICBGMA0KKFhF
TikgIDAzIDAwMSAwMSAgMCAgICAwICAgIDAgICAwICAgMCAgICAxICAgIDEgICAgMzANCihY
RU4pICAwNCAwMDEgMDEgIDAgICAgMCAgICAwICAgMCAgIDAgICAgMSAgICAxICAgIEYxDQoo
WEVOKSAgMDUgMDAxIDAxICAwICAgIDAgICAgMCAgIDAgICAwICAgIDEgICAgMSAgICAzOA0K
KFhFTikgIDA2IDAwMSAwMSAgMCAgICAwICAgIDAgICAwICAgMCAgICAxICAgIDEgICAgNDAN
CihYRU4pICAwNyAwMDEgMDEgIDAgICAgMCAgICAwICAgMCAgIDAgICAgMSAgICAxICAgIDQ4
DQooWEVOKSAgMDggMDAxIDAxICAwICAgIDAgICAgMCAgIDAgICAwICAgIDEgICAgMSAgICA1
MA0KKFhFTikgIDA5IDAwMSAwMSAgMSAgICAxICAgIDAgICAwICAgMCAgICAxICAgIDEgICAg
NTgNCihYRU4pICAwYSAwMDEgMDEgIDAgICAgMCAgICAwICAgMCAgIDAgICAgMSAgICAxICAg
IDYwDQooWEVOKSAgMGIgMDAxIDAxICAwICAgIDAgICAgMCAgIDAgICAwICAgIDEgICAgMSAg
ICA2OA0KKFhFTikgIDBjIDAwMSAwMSAgMCAgICAwICAgIDAgICAwICAgMCAgICAxICAgIDEg
ICAgNzANCihYRU4pICAwZCAwMDEgMDEgIDAgICAgMCAgICAwICAgMCAgIDAgICAgMSAgICAx
ICAgIDc4DQooWEVOKSAgMGUgMDAxIDAxICAwICAgIDAgICAgMCAgIDAgICAwICAgIDEgICAg
MSAgICA4OA0KKFhFTikgIDBmIDAwMSAwMSAgMCAgICAwICAgIDAgICAwICAgMCAgICAxICAg
IDEgICAgOTANCihYRU4pICAxMCAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAg
ICAwICAgIDAwDQooWEVOKSAgMTEgMDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAwICAgIDAg
ICAgMCAgICAwMA0KKFhFTikgIDEyIDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAw
ICAgIDAgICAgMDANCihYRU4pICAxMyAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAg
MCAgICAwICAgIDAwDQooWEVOKSAgMTQgMDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAwICAg
IDAgICAgMCAgICAwMA0KKFhFTikgIDE1IDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAg
ICAwICAgIDAgICAgMDANCihYRU4pICAxNiAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAg
ICAgMCAgICAwICAgIDAwDQooWEVOKSAgMTcgMDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAw
ICAgIDAgICAgMCAgICAwMA0KKFhFTikgVXNpbmcgdmVjdG9yLWJhc2VkIGluZGV4aW5nDQoo
WEVOKSBJUlEgdG8gcGluIG1hcHBpbmdzOg0KKFhFTikgSVJRMjQwIC0+IDA6Mg0KKFhFTikg
SVJRNDAgLT4gMDoxDQooWEVOKSBJUlE0OCAtPiAwOjMNCihYRU4pIElSUTI0MSAtPiAwOjQN
CihYRU4pIElSUTU2IC0+IDA6NQ0KKFhFTikgSVJRNjQgLT4gMDo2DQooWEVOKSBJUlE3MiAt
PiAwOjcNCihYRU4pIElSUTgwIC0+IDA6OA0KKFhFTikgSVJRODggLT4gMDo5DQooWEVOKSBJ
UlE5NiAtPiAwOjEwDQooWEVOKSBJUlExMDQgLT4gMDoxMQ0KKFhFTikgSVJRMTEyIC0+IDA6
MTINCihYRU4pIElSUTEyMCAtPiAwOjEzDQooWEVOKSBJUlExMzYgLT4gMDoxNA0KKFhFTikg
SVJRMTQ0IC0+IDA6MTUNCihYRU4pIC4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u
Li4uLiBkb25lLg0KKFhFTikgVXNpbmcgbG9jYWwgQVBJQyB0aW1lciBpbnRlcnJ1cHRzLg0K
KFhFTikgY2FsaWJyYXRpbmcgQVBJQyB0aW1lciAuLi4NCihYRU4pIC4uLi4uIENQVSBjbG9j
ayBzcGVlZCBpcyAyNjY2LjQxNjcgTUh6Lg0KKFhFTikgLi4uLi4gaG9zdCBidXMgY2xvY2sg
c3BlZWQgaXMgMzMzLjMwMjAgTUh6Lg0KKFhFTikgLi4uLi4gYnVzX3NjYWxlID0gMHgwMDAx
NTU1NQ0KKFhFTikgWzIwMTItMDktMDQgMTg6NDE6MjRdIFBsYXRmb3JtIHRpbWVyIGlzIDE0
LjMxOE1IeiBIUEVUDQooWEVOKSBbMjAxMi0wOS0wNCAxODo0MToyNF0gQWxsb2NhdGVkIGNv
bnNvbGUgcmluZyBvZiAzMiBLaUIuDQooWEVOKSBbMjAxMi0wOS0wNCAxODo0MToyNF0gVk1Y
OiBTdXBwb3J0ZWQgYWR2YW5jZWQgZmVhdHVyZXM6DQooWEVOKSBbMjAxMi0wOS0wNCAxODo0
MToyNF0gIC0gQVBJQyBNTUlPIGFjY2VzcyB2aXJ0dWFsaXNhdGlvbg0KKFhFTikgWzIwMTIt
MDktMDQgMTg6NDE6MjRdICAtIEFQSUMgVFBSIHNoYWRvdw0KKFhFTikgWzIwMTItMDktMDQg
MTg6NDE6MjRdICAtIFZpcnR1YWwgTk1JDQooWEVOKSBbMjAxMi0wOS0wNCAxODo0MToyNF0g
IC0gTVNSIGRpcmVjdC1hY2Nlc3MgYml0bWFwDQooWEVOKSBbMjAxMi0wOS0wNCAxODo0MToy
NF0gSFZNOiBBU0lEcyBkaXNhYmxlZC4NCihYRU4pIFsyMDEyLTA5LTA0IDE4OjQxOjI0XSBI
Vk06IFZNWCBlbmFibGVkDQooWEVOKSBbMjAxMi0wOS0wNCAxODo0MToyM10gbWFza2VkIEV4
dElOVCBvbiBDUFUjMQ0KKFhFTikgWzIwMTItMDktMDQgMTg6NDE6MjNdIG1hc2tlZCBFeHRJ
TlQgb24gQ1BVIzINCihYRU4pIFsyMDEyLTA5LTA0IDE4OjQxOjIzXSBtYXNrZWQgRXh0SU5U
IG9uIENQVSMzDQooWEVOKSBbMjAxMi0wOS0wNCAxODo0MToyNF0gQnJvdWdodCB1cCA0IENQ
VXMNCihYRU4pIFsyMDEyLTA5LTA0IDE4OjQxOjI0XSBIUEVUOiA4IHRpbWVycyAoOCB3aWxs
IGJlIHVzZWQgZm9yIGJyb2FkY2FzdCkNCihYRU4pIFsyMDEyLTA5LTA0IDE4OjQxOjI0XSBB
Q1BJIHNsZWVwIG1vZGVzOiBTMw0KKFhFTikgWzIwMTItMDktMDQgMTg6NDE6MjRdIG1jaGVj
a19wb2xsOiBNYWNoaW5lIGNoZWNrIHBvbGxpbmcgdGltZXIgc3RhcnRlZC4NCihYRU4pIFsy
MDEyLTA5LTA0IDE4OjQxOjI0XSAqKiogTE9BRElORyBET01BSU4gMCAqKioNCihYRU4pIFsy
MDEyLTA5LTA0IDE4OjQxOjI0XSBlbGZfcGFyc2VfYmluYXJ5OiBwaGRyOiBwYWRkcj0weDEw
MDAwMDAgbWVtc3o9MHhkNzQwMDANCihYRU4pIFsyMDEyLTA5LTA0IDE4OjQxOjI0XSBlbGZf
cGFyc2VfYmluYXJ5OiBwaGRyOiBwYWRkcj0weDFlMDAwMDAgbWVtc3o9MHhkZDBlOA0KKFhF
TikgWzIwMTItMDktMDQgMTg6NDE6MjRdIGVsZl9wYXJzZV9iaW5hcnk6IHBoZHI6IHBhZGRy
PTB4MWVkZTAwMCBtZW1zej0weDEzYzAwDQooWEVOKSBbMjAxMi0wOS0wNCAxODo0MToyNF0g
ZWxmX3BhcnNlX2JpbmFyeTogcGhkcjogcGFkZHI9MHgxZWYyMDAwIG1lbXN6PTB4ZGU2MDAw
DQooWEVOKSBbMjAxMi0wOS0wNCAxODo0MToyNF0gZWxmX3BhcnNlX2JpbmFyeTogbWVtb3J5
OiAweDEwMDAwMDAgLT4gMHgyY2Q4MDAwDQooWEVOKSBbMjAxMi0wOS0wNCAxODo0MToyNF0g
ZWxmX3hlbl9wYXJzZV9ub3RlOiBHVUVTVF9PUyA9ICJsaW51eCINCihYRU4pIFsyMDEyLTA5
LTA0IDE4OjQxOjI0XSBlbGZfeGVuX3BhcnNlX25vdGU6IEdVRVNUX1ZFUlNJT04gPSAiMi42
Ig0KKFhFTikgWzIwMTItMDktMDQgMTg6NDE6MjRdIGVsZl94ZW5fcGFyc2Vfbm90ZTogWEVO
X1ZFUlNJT04gPSAieGVuLTMuMCINCihYRU4pIFsyMDEyLTA5LTA0IDE4OjQxOjI0XSBlbGZf
eGVuX3BhcnNlX25vdGU6IFZJUlRfQkFTRSA9IDB4ZmZmZmZmZmY4MDAwMDAwMA0KKFhFTikg
WzIwMTItMDktMDQgMTg6NDE6MjRdIGVsZl94ZW5fcGFyc2Vfbm90ZTogRU5UUlkgPSAweGZm
ZmZmZmZmODFlZjIyMTANCihYRU4pIFsyMDEyLTA5LTA0IDE4OjQxOjI0XSBlbGZfeGVuX3Bh
cnNlX25vdGU6IEhZUEVSQ0FMTF9QQUdFID0gMHhmZmZmZmZmZjgxMDAxMDAwDQooWEVOKSBb
MjAxMi0wOS0wNCAxODo0MToyNF0gZWxmX3hlbl9wYXJzZV9ub3RlOiBGRUFUVVJFUyA9ICIh
d3JpdGFibGVfcGFnZV90YWJsZXN8cGFlX3BnZGlyX2Fib3ZlXzRnYiINCihYRU4pIFsyMDEy
LTA5LTA0IDE4OjQxOjI0XSBlbGZfeGVuX3BhcnNlX25vdGU6IFBBRV9NT0RFID0gInllcyIN
CihYRU4pIFsyMDEyLTA5LTA0IDE4OjQxOjI0XSBlbGZfeGVuX3BhcnNlX25vdGU6IExPQURF
UiA9ICJnZW5lcmljIg0KKFhFTikgWzIwMTItMDktMDQgMTg6NDE6MjRdIGVsZl94ZW5fcGFy
c2Vfbm90ZTogdW5rbm93biB4ZW4gZWxmIG5vdGUgKDB4ZCkNCihYRU4pIFsyMDEyLTA5LTA0
IDE4OjQxOjI0XSBlbGZfeGVuX3BhcnNlX25vdGU6IFNVU1BFTkRfQ0FOQ0VMID0gMHgxDQoo
WEVOKSBbMjAxMi0wOS0wNCAxODo0MToyNF0gZWxmX3hlbl9wYXJzZV9ub3RlOiBIVl9TVEFS
VF9MT1cgPSAweGZmZmY4MDAwMDAwMDAwMDANCihYRU4pIFsyMDEyLTA5LTA0IDE4OjQxOjI0
XSBlbGZfeGVuX3BhcnNlX25vdGU6IFBBRERSX09GRlNFVCA9IDB4MA0KKFhFTikgWzIwMTIt
MDktMDQgMTg6NDE6MjRdIGVsZl94ZW5fYWRkcl9jYWxjX2NoZWNrOiBhZGRyZXNzZXM6DQoo
WEVOKSBbMjAxMi0wOS0wNCAxODo0MToyNF0gICAgIHZpcnRfYmFzZSAgICAgICAgPSAweGZm
ZmZmZmZmODAwMDAwMDANCihYRU4pIFsyMDEyLTA5LTA0IDE4OjQxOjI0XSAgICAgZWxmX3Bh
ZGRyX29mZnNldCA9IDB4MA0KKFhFTikgWzIwMTItMDktMDQgMTg6NDE6MjVdICAgICB2aXJ0
X29mZnNldCAgICAgID0gMHhmZmZmZmZmZjgwMDAwMDAwDQooWEVOKSBbMjAxMi0wOS0wNCAx
ODo0MToyNV0gICAgIHZpcnRfa3N0YXJ0ICAgICAgPSAweGZmZmZmZmZmODEwMDAwMDANCihY
RU4pIFsyMDEyLTA5LTA0IDE4OjQxOjI1XSAgICAgdmlydF9rZW5kICAgICAgICA9IDB4ZmZm
ZmZmZmY4MmNkODAwMA0KKFhFTikgWzIwMTItMDktMDQgMTg6NDE6MjVdICAgICB2aXJ0X2Vu
dHJ5ICAgICAgID0gMHhmZmZmZmZmZjgxZWYyMjEwDQooWEVOKSBbMjAxMi0wOS0wNCAxODo0
MToyNV0gICAgIHAybV9iYXNlICAgICAgICAgPSAweGZmZmZmZmZmZmZmZmZmZmYNCihYRU4p
IFsyMDEyLTA5LTA0IDE4OjQxOjI1XSAgWGVuICBrZXJuZWw6IDY0LWJpdCwgbHNiLCBjb21w
YXQzMg0KKFhFTikgWzIwMTItMDktMDQgMTg6NDE6MjVdICBEb20wIGtlcm5lbDogNjQtYml0
LCBQQUUsIGxzYiwgcGFkZHIgMHgxMDAwMDAwIC0+IDB4MmNkODAwMA0KKFhFTikgWzIwMTIt
MDktMDQgMTg6NDE6MjVdIFBIWVNJQ0FMIE1FTU9SWSBBUlJBTkdFTUVOVDoNCihYRU4pIFsy
MDEyLTA5LTA0IDE4OjQxOjI1XSAgRG9tMCBhbGxvYy46ICAgMDAwMDAwMDA3NDAwMDAwMC0+
MDAwMDAwMDA3ODAwMDAwMCAoMjQ0NjE3IHBhZ2VzIHRvIGJlIGFsbG9jYXRlZCkNCihYRU4p
IFsyMDEyLTA5LTA0IDE4OjQxOjI1XSAgSW5pdC4gcmFtZGlzazogMDAwMDAwMDA3ZTU4OTAw
MC0+MDAwMDAwMDA3ZTlmZjYwMA0KKFhFTikgWzIwMTItMDktMDQgMTg6NDE6MjVdIFZJUlRV
QUwgTUVNT1JZIEFSUkFOR0VNRU5UOg0KKFhFTikgWzIwMTItMDktMDQgMTg6NDE6MjVdICBM
b2FkZWQga2VybmVsOiBmZmZmZmZmZjgxMDAwMDAwLT5mZmZmZmZmZjgyY2Q4MDAwDQooWEVO
KSBbMjAxMi0wOS0wNCAxODo0MToyNV0gIEluaXQuIHJhbWRpc2s6IGZmZmZmZmZmODJjZDgw
MDAtPmZmZmZmZmZmODMxNGU2MDANCihYRU4pIFsyMDEyLTA5LTA0IDE4OjQxOjI1XSAgUGh5
cy1NYWNoIG1hcDogZmZmZmZmZmY4MzE0ZjAwMC0+ZmZmZmZmZmY4MzM0ZjAwMA0KKFhFTikg
WzIwMTItMDktMDQgMTg6NDE6MjVdICBTdGFydCBpbmZvOiAgICBmZmZmZmZmZjgzMzRmMDAw
LT5mZmZmZmZmZjgzMzRmNGI0DQooWEVOKSBbMjAxMi0wOS0wNCAxODo0MToyNV0gIFBhZ2Ug
dGFibGVzOiAgIGZmZmZmZmZmODMzNTAwMDAtPmZmZmZmZmZmODMzNmQwMDANCihYRU4pIFsy
MDEyLTA5LTA0IDE4OjQxOjI1XSAgQm9vdCBzdGFjazogICAgZmZmZmZmZmY4MzM2ZDAwMC0+
ZmZmZmZmZmY4MzM2ZTAwMA0KKFhFTikgWzIwMTItMDktMDQgMTg6NDE6MjVdICBUT1RBTDog
ICAgICAgICBmZmZmZmZmZjgwMDAwMDAwLT5mZmZmZmZmZjgzNDAwMDAwDQooWEVOKSBbMjAx
Mi0wOS0wNCAxODo0MToyNV0gIEVOVFJZIEFERFJFU1M6IGZmZmZmZmZmODFlZjIyMTANCihY
RU4pIFsyMDEyLTA5LTA0IDE4OjQxOjI1XSBEb20wIGhhcyBtYXhpbXVtIDQgVkNQVXMNCihY
RU4pIFsyMDEyLTA5LTA0IDE4OjQxOjI1XSBlbGZfbG9hZF9iaW5hcnk6IHBoZHIgMCBhdCAw
eGZmZmZmZmZmODEwMDAwMDAgLT4gMHhmZmZmZmZmZjgxZDc0MDAwDQooWEVOKSBbMjAxMi0w
OS0wNCAxODo0MToyNV0gZWxmX2xvYWRfYmluYXJ5OiBwaGRyIDEgYXQgMHhmZmZmZmZmZjgx
ZTAwMDAwIC0+IDB4ZmZmZmZmZmY4MWVkZDBlOA0KKFhFTikgWzIwMTItMDktMDQgMTg6NDE6
MjVdIGVsZl9sb2FkX2JpbmFyeTogcGhkciAyIGF0IDB4ZmZmZmZmZmY4MWVkZTAwMCAtPiAw
eGZmZmZmZmZmODFlZjFjMDANCihYRU4pIFsyMDEyLTA5LTA0IDE4OjQxOjI1XSBlbGZfbG9h
ZF9iaW5hcnk6IHBoZHIgMyBhdCAweGZmZmZmZmZmODFlZjIwMDAgLT4gMHhmZmZmZmZmZjgx
ZjhjMDAwDQooWEVOKSBbMjAxMi0wOS0wNCAxODo0MToyNV0gU2NydWJiaW5nIEZyZWUgUkFN
OiAuLi4uLi4uLi5kb25lLg0KKFhFTikgWzIwMTItMDktMDQgMTg6NDE6MjVdIEluaXRpYWwg
bG93IG1lbW9yeSB2aXJxIHRocmVzaG9sZCBzZXQgYXQgMHg0MDAwIHBhZ2VzLg0KKFhFTikg
WzIwMTItMDktMDQgMTg6NDE6MjVdIFN0ZC4gTG9nbGV2ZWw6IEFsbA0KKFhFTikgWzIwMTIt
MDktMDQgMTg6NDE6MjVdIEd1ZXN0IExvZ2xldmVsOiBBbGwNCihYRU4pIFsyMDEyLTA5LTA0
IDE4OjQxOjI1XSBYZW4gaXMgcmVsaW5xdWlzaGluZyBWR0EgY29uc29sZS4NCihYRU4pIFsy
MDEyLTA5LTA0IDE4OjQxOjI1XSAqKiogU2VyaWFsIGlucHV0IC0+IERPTTAgKHR5cGUgJ0NU
UkwtYScgdGhyZWUgdGltZXMgdG8gc3dpdGNoIGlucHV0IHRvIFhlbikNCihYRU4pIFsyMDEy
LTA5LTA0IDE4OjQxOjI1XSBGcmVlZCAyNTZrQiBpbml0IG1lbW9yeS4NCm1hcHBpbmcga2Vy
bmVsIGludG8gcGh5c2ljYWwgbWVtb3J5DQphYm91dCB0byBnZXQgc3RhcnRlZC4uLg0KWyAg
ICAwLjAwMDAwMF0gSW5pdGlhbGl6aW5nIGNncm91cCBzdWJzeXMgY3B1c2V0DQpbICAgIDAu
MDAwMDAwXSBJbml0aWFsaXppbmcgY2dyb3VwIHN1YnN5cyBjcHUNClsgICAgMC4wMDAwMDBd
IExpbnV4IHZlcnNpb24gMy42LjAtcmM0LTIwMTIwODMwKyAocm9vdEB4ZW50ZXN0KSAoZ2Nj
IHZlcnNpb24gNC40LjUgKERlYmlhbiA0LjQuNS04KSApICM2OCBTTVAgUFJFRU1QVCBUdWUg
U2VwIDQgMjA6MzY6NDcgQ0VTVCAyMDEyDQpbICAgIDAuMDAwMDAwXSBDb21tYW5kIGxpbmU6
IHJvb3Q9L2Rldi9zZGExIHJvIHZlcmJvc2UgbWVtPTEwMjRNIGNvbnNvbGU9aHZjMCBjb25z
b2xlPXR0eTAgbm9tb2Rlc2V0IHZnYT0zMDMgZWFybHlwcmludGs9eGVuIG1heF9sb29wPTUw
IGxvb3BfbWF4X3BhcnQ9MTAgZGVidWcgbG9nbGV2ZWw9MTANClsgICAgMC4wMDAwMDBdIEZy
ZWVpbmcgOWUtMTAwIHBmbiByYW5nZTogOTggcGFnZXMgZnJlZWQNClsgICAgMC4wMDAwMDBd
IFJlbGVhc2VkIDk4IHBhZ2VzIG9mIHVudXNlZCBtZW1vcnkNClsgICAgMC4wMDAwMDBdIFNl
dCA1Mjg4ODIgcGFnZShzKSB0byAxLTEgbWFwcGluZw0KWyAgICAwLjAwMDAwMF0gUG9wdWxh
dGluZyA0MDAwMC00MDA2MiBwZm4gcmFuZ2U6IDk4IHBhZ2VzIGFkZGVkDQpbICAgIDAuMDAw
MDAwXSBlODIwOiBCSU9TLXByb3ZpZGVkIHBoeXNpY2FsIFJBTSBtYXA6DQpbICAgIDAuMDAw
MDAwXSBYZW46IFttZW0gMHgwMDAwMDAwMDAwMDAwMDAwLTB4MDAwMDAwMDAwMDA5ZGZmZl0g
dXNhYmxlDQpbICAgIDAuMDAwMDAwXSBYZW46IFttZW0gMHgwMDAwMDAwMDAwMDllODAwLTB4
MDAwMDAwMDAwMDBmZmZmZl0gcmVzZXJ2ZWQNClsgICAgMC4wMDAwMDBdIFhlbjogW21lbSAw
eDAwMDAwMDAwMDAxMDAwMDAtMHgwMDAwMDAwMDQwMDYxZmZmXSB1c2FibGUNClsgICAgMC4w
MDAwMDBdIFhlbjogW21lbSAweDAwMDAwMDAwNDAwNjIwMDAtMHgwMDAwMDAwMDdlZTZmZmZm
XSB1bnVzYWJsZQ0KWyAgICAwLjAwMDAwMF0gWGVuOiBbbWVtIDB4MDAwMDAwMDA3ZWU3MDAw
MC0weDAwMDAwMDAwN2VlN2RmZmZdIEFDUEkgZGF0YQ0KWyAgICAwLjAwMDAwMF0gWGVuOiBb
bWVtIDB4MDAwMDAwMDA3ZWU3ZTAwMC0weDAwMDAwMDAwN2VlY2ZmZmZdIEFDUEkgTlZTDQpb
ICAgIDAuMDAwMDAwXSBYZW46IFttZW0gMHgwMDAwMDAwMDdlZWQwMDAwLTB4MDAwMDAwMDA3
ZWVmZmZmZl0gcmVzZXJ2ZWQNClsgICAgMC4wMDAwMDBdIFhlbjogW21lbSAweDAwMDAwMDAw
ZmVjMDAwMDAtMHgwMDAwMDAwMGZlYzAwZmZmXSByZXNlcnZlZA0KWyAgICAwLjAwMDAwMF0g
WGVuOiBbbWVtIDB4MDAwMDAwMDBmZWQwMDAwMC0weDAwMDAwMDAwZmVkMDEwZmZdIHJlc2Vy
dmVkDQpbICAgIDAuMDAwMDAwXSBYZW46IFttZW0gMHgwMDAwMDAwMGZlZDAyMDAwLTB4MDAw
MDAwMDBmZWQxNGJmZl0gcmVzZXJ2ZWQNClsgICAgMC4wMDAwMDBdIFhlbjogW21lbSAweDAw
MDAwMDAwZmVkMjAwMDAtMHgwMDAwMDAwMGZlZDNmZmZmXSByZXNlcnZlZA0KWyAgICAwLjAw
MDAwMF0gWGVuOiBbbWVtIDB4MDAwMDAwMDBmZWUwMDAwMC0weDAwMDAwMDAwZmVlMDBmZmZd
IHJlc2VydmVkDQpbICAgIDAuMDAwMDAwXSBYZW46IFttZW0gMHgwMDAwMDAwMGZmZTAwMDAw
LTB4MDAwMDAwMDBmZmZmZmZmZl0gcmVzZXJ2ZWQNClsgICAgMC4wMDAwMDBdIGJvb3Rjb25z
b2xlIFt4ZW5ib290MF0gZW5hYmxlZA0KWyAgICAwLjAwMDAwMF0gTlggKEV4ZWN1dGUgRGlz
YWJsZSkgcHJvdGVjdGlvbjogYWN0aXZlDQpbICAgIDAuMDAwMDAwXSBlODIwOiB1c2VyLWRl
ZmluZWQgcGh5c2ljYWwgUkFNIG1hcDoNClsgICAgMC4wMDAwMDBdIHVzZXI6IFttZW0gMHgw
MDAwMDAwMDAwMDAwMDAwLTB4MDAwMDAwMDAwMDA5ZGZmZl0gdXNhYmxlDQpbICAgIDAuMDAw
MDAwXSB1c2VyOiBbbWVtIDB4MDAwMDAwMDAwMDA5ZTgwMC0weDAwMDAwMDAwMDAwZmZmZmZd
IHJlc2VydmVkDQpbICAgIDAuMDAwMDAwXSB1c2VyOiBbbWVtIDB4MDAwMDAwMDAwMDEwMDAw
MC0weDAwMDAwMDAwM2ZmZmZmZmZdIHVzYWJsZQ0KWyAgICAwLjAwMDAwMF0gdXNlcjogW21l
bSAweDAwMDAwMDAwNDAwNjIwMDAtMHgwMDAwMDAwMDdlZTZmZmZmXSB1bnVzYWJsZQ0KWyAg
ICAwLjAwMDAwMF0gdXNlcjogW21lbSAweDAwMDAwMDAwN2VlNzAwMDAtMHgwMDAwMDAwMDdl
ZTdkZmZmXSBBQ1BJIGRhdGENClsgICAgMC4wMDAwMDBdIHVzZXI6IFttZW0gMHgwMDAwMDAw
MDdlZTdlMDAwLTB4MDAwMDAwMDA3ZWVjZmZmZl0gQUNQSSBOVlMNClsgICAgMC4wMDAwMDBd
IHVzZXI6IFttZW0gMHgwMDAwMDAwMDdlZWQwMDAwLTB4MDAwMDAwMDA3ZWVmZmZmZl0gcmVz
ZXJ2ZWQNClsgICAgMC4wMDAwMDBdIHVzZXI6IFttZW0gMHgwMDAwMDAwMGZlYzAwMDAwLTB4
MDAwMDAwMDBmZWMwMGZmZl0gcmVzZXJ2ZWQNClsgICAgMC4wMDAwMDBdIHVzZXI6IFttZW0g
MHgwMDAwMDAwMGZlZDAwMDAwLTB4MDAwMDAwMDBmZWQwMTBmZl0gcmVzZXJ2ZWQNClsgICAg
MC4wMDAwMDBdIHVzZXI6IFttZW0gMHgwMDAwMDAwMGZlZDAyMDAwLTB4MDAwMDAwMDBmZWQx
NGJmZl0gcmVzZXJ2ZWQNClsgICAgMC4wMDAwMDBdIHVzZXI6IFttZW0gMHgwMDAwMDAwMGZl
ZDIwMDAwLTB4MDAwMDAwMDBmZWQzZmZmZl0gcmVzZXJ2ZWQNClsgICAgMC4wMDAwMDBdIHVz
ZXI6IFttZW0gMHgwMDAwMDAwMGZlZTAwMDAwLTB4MDAwMDAwMDBmZWUwMGZmZl0gcmVzZXJ2
ZWQNClsgICAgMC4wMDAwMDBdIHVzZXI6IFttZW0gMHgwMDAwMDAwMGZmZTAwMDAwLTB4MDAw
MDAwMDBmZmZmZmZmZl0gcmVzZXJ2ZWQNClsgICAgMC4wMDAwMDBdIERNSSBwcmVzZW50Lg0K
WyAgICAwLjAwMDAwMF0gRE1JOiBTeXN0ZW0gbWFudWZhY3R1cmVyIFN5c3RlbSBQcm9kdWN0
IE5hbWUvUDVRLUVNIERPLCBCSU9TIDEyMDggICAgMDUvMjUvMjAxMA0KWyAgICAwLjAwMDAw
MF0gZTgyMDogdXBkYXRlIFttZW0gMHgwMDAwMDAwMC0weDAwMDBmZmZmXSB1c2FibGUgPT0+
IHJlc2VydmVkDQpbICAgIDAuMDAwMDAwXSBlODIwOiByZW1vdmUgW21lbSAweDAwMGEwMDAw
LTB4MDAwZmZmZmZdIHVzYWJsZQ0KWyAgICAwLjAwMDAwMF0gTm8gQUdQIGJyaWRnZSBmb3Vu
ZA0KWyAgICAwLjAwMDAwMF0gZTgyMDogbGFzdF9wZm4gPSAweDQwMDAwIG1heF9hcmNoX3Bm
biA9IDB4NDAwMDAwMDAwDQpbICAgIDAuMDAwMDAwXSBmb3VuZCBTTVAgTVAtdGFibGUgYXQg
W21lbSAweDAwMGZmNzgwLTB4MDAwZmY3OGZdIG1hcHBlZCBhdCBbZmZmZjg4MDAwMDBmZjc4
MF0NClsgICAgMC4wMDAwMDBdIGluaXRpYWwgbWVtb3J5IG1hcHBlZDogW21lbSAweDAwMDAw
MDAwLTB4MDMxNGVmZmZdDQpbICAgIDAuMDAwMDAwXSBCYXNlIG1lbW9yeSB0cmFtcG9saW5l
IGF0IFtmZmZmODgwMDAwMDk4MDAwXSA5ODAwMCBzaXplIDI0NTc2DQpbICAgIDAuMDAwMDAw
XSBpbml0X21lbW9yeV9tYXBwaW5nOiBbbWVtIDB4MDAwMDAwMDAtMHgzZmZmZmZmZl0NClsg
ICAgMC4wMDAwMDBdICBbbWVtIDB4MDAwMDAwMDAtMHgzZmZmZmZmZl0gcGFnZSA0aw0KWyAg
ICAwLjAwMDAwMF0ga2VybmVsIGRpcmVjdCBtYXBwaW5nIHRhYmxlcyB1cCB0byAweDNmZmZm
ZmZmIEAgW21lbSAweDAyYWQ2MDAwLTB4MDJjZDdmZmZdDQpbICAgIDAuMDAwMDAwXSB4ZW46
IHNldHRpbmcgUlcgdGhlIHJhbmdlIDJjYjgwMDAgLSAyY2Q4MDAwDQpbICAgIDAuMDAwMDAw
XSBSQU1ESVNLOiBbbWVtIDB4MDJjZDgwMDAtMHgwMzE0ZWZmZl0NClsgICAgMC4wMDAwMDBd
IEFDUEk6IFJTRFAgMDAwMDAwMDAwMDBmYjA4MCAwMDAyNCAodjAyIEFDUElBTSkNClsgICAg
MC4wMDAwMDBdIEFDUEk6IFhTRFQgMDAwMDAwMDA3ZWU3MDEwMCAwMDA1QyAodjAxIEFfTV9J
XyBPRU1YU0RUICAwNTAwMTAyNSBNU0ZUIDAwMDAwMDk3KQ0KWyAgICAwLjAwMDAwMF0gQUNQ
STogRkFDUCAwMDAwMDAwMDdlZTcwMjkwIDAwMEY0ICh2MDMgQV9NX0lfIE9FTUZBQ1AgIDA1
MDAxMDI1IE1TRlQgMDAwMDAwOTcpDQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBEU0RUIDAwMDAw
MDAwN2VlNzA0NDAgMDg0MUYgKHYwMSAgQTEwNjUgQTEwNjUwMDAgMDAwMDAwMDAgSU5UTCAy
MDA2MDExMykNClsgICAgMC4wMDAwMDBdIEFDUEk6IEZBQ1MgMDAwMDAwMDA3ZWU3ZTAwMCAw
MDA0MA0KWyAgICAwLjAwMDAwMF0gQUNQSTogQVBJQyAwMDAwMDAwMDdlZTcwMzkwIDAwMDZD
ICh2MDEgQV9NX0lfIE9FTUFQSUMgIDA1MDAxMDI1IE1TRlQgMDAwMDAwOTcpDQpbICAgIDAu
MDAwMDAwXSBBQ1BJOiBNQ0ZHIDAwMDAwMDAwN2VlNzA0MDAgMDAwM0MgKHYwMSBBX01fSV8g
T0VNTUNGRyAgMDUwMDEwMjUgTVNGVCAwMDAwMDA5NykNClsgICAgMC4wMDAwMDBdIEFDUEk6
IE9FTUIgMDAwMDAwMDA3ZWU3ZTA0MCAwMDA4OSAodjAxIEFfTV9JXyBBTUlfT0VNICAwNTAw
MTAyNSBNU0ZUIDAwMDAwMDk3KQ0KWyAgICAwLjAwMDAwMF0gQUNQSTogSFBFVCAwMDAwMDAw
MDdlZTc4ODYwIDAwMDM4ICh2MDEgQV9NX0lfIE9FTUhQRVQgIDA1MDAxMDI1IE1TRlQgMDAw
MDAwOTcpDQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBHU0NJIDAwMDAwMDAwN2VlN2UwZDAgMDIw
MjQgKHYwMSBBX01fSV8gR01DSFNDSSAgMDUwMDEwMjUgTVNGVCAwMDAwMDA5NykNClsgICAg
MC4wMDAwMDBdIEFDUEk6IFNTRFQgMDAwMDAwMDA3ZWU4MGEwMCAwMEE3QyAodjAxIERwZ1Bt
bSAgICBDcHVQbSAwMDAwMDAxMiBJTlRMIDIwMDYwMTEzKQ0KWyAgICAwLjAwMDAwMF0gQUNQ
STogTG9jYWwgQVBJQyBhZGRyZXNzIDB4ZmVlMDAwMDANClsgICAgMC4wMDAwMDBdIE5vIE5V
TUEgY29uZmlndXJhdGlvbiBmb3VuZA0KWyAgICAwLjAwMDAwMF0gRmFraW5nIGEgbm9kZSBh
dCBbbWVtIDB4MDAwMDAwMDAwMDAwMDAwMC0weDAwMDAwMDAwM2ZmZmZmZmZdDQpbICAgIDAu
MDAwMDAwXSBJbml0bWVtIHNldHVwIG5vZGUgMCBbbWVtIDB4MDAwMDAwMDAtMHgzZmZmZmZm
Zl0NClsgICAgMC4wMDAwMDBdICAgTk9ERV9EQVRBIFttZW0gMHgzZmZmNTAwMC0weDNmZmZm
ZmZmXQ0KWyAgICAwLjAwMDAwMF0gWm9uZSByYW5nZXM6DQpbICAgIDAuMDAwMDAwXSAgIERN
QSAgICAgIFttZW0gMHgwMDAxMDAwMC0weDAwZmZmZmZmXQ0KWyAgICAwLjAwMDAwMF0gICBE
TUEzMiAgICBbbWVtIDB4MDEwMDAwMDAtMHhmZmZmZmZmZl0NClsgICAgMC4wMDAwMDBdICAg
Tm9ybWFsICAgZW1wdHkNClsgICAgMC4wMDAwMDBdIE1vdmFibGUgem9uZSBzdGFydCBmb3Ig
ZWFjaCBub2RlDQpbICAgIDAuMDAwMDAwXSBFYXJseSBtZW1vcnkgbm9kZSByYW5nZXMNClsg
ICAgMC4wMDAwMDBdICAgbm9kZSAgIDA6IFttZW0gMHgwMDAxMDAwMC0weDAwMDlkZmZmXQ0K
WyAgICAwLjAwMDAwMF0gICBub2RlICAgMDogW21lbSAweDAwMTAwMDAwLTB4M2ZmZmZmZmZd
DQpbICAgIDAuMDAwMDAwXSBPbiBub2RlIDAgdG90YWxwYWdlczogMjYyMDMwDQpbICAgIDAu
MDAwMDAwXSAgIERNQSB6b25lOiA2NCBwYWdlcyB1c2VkIGZvciBtZW1tYXANClsgICAgMC4w
MDAwMDBdICAgRE1BIHpvbmU6IDYgcGFnZXMgcmVzZXJ2ZWQNClsgICAgMC4wMDAwMDBdICAg
RE1BIHpvbmU6IDM5MTIgcGFnZXMsIExJRk8gYmF0Y2g6MA0KWyAgICAwLjAwMDAwMF0gICBE
TUEzMiB6b25lOiA0MDMyIHBhZ2VzIHVzZWQgZm9yIG1lbW1hcA0KWyAgICAwLjAwMDAwMF0g
ICBETUEzMiB6b25lOiAyNTQwMTYgcGFnZXMsIExJRk8gYmF0Y2g6MzENClsgICAgMC4wMDAw
MDBdIEFDUEk6IFBNLVRpbWVyIElPIFBvcnQ6IDB4ODA4DQpbICAgIDAuMDAwMDAwXSBBQ1BJ
OiBMb2NhbCBBUElDIGFkZHJlc3MgMHhmZWUwMDAwMA0KWyAgICAwLjAwMDAwMF0gQUNQSTog
TEFQSUMgKGFjcGlfaWRbMHgwMV0gbGFwaWNfaWRbMHgwMF0gZW5hYmxlZCkNClsgICAgMC4w
MDAwMDBdIEFDUEk6IExBUElDIChhY3BpX2lkWzB4MDJdIGxhcGljX2lkWzB4MDFdIGVuYWJs
ZWQpDQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBMQVBJQyAoYWNwaV9pZFsweDAzXSBsYXBpY19p
ZFsweDAyXSBlbmFibGVkKQ0KWyAgICAwLjAwMDAwMF0gQUNQSTogTEFQSUMgKGFjcGlfaWRb
MHgwNF0gbGFwaWNfaWRbMHgwM10gZW5hYmxlZCkNClsgICAgMC4wMDAwMDBdIEFDUEk6IElP
QVBJQyAoaWRbMHgwNF0gYWRkcmVzc1sweGZlYzAwMDAwXSBnc2lfYmFzZVswXSkNClsgICAg
MC4wMDAwMDBdIElPQVBJQ1swXTogYXBpY19pZCA0LCB2ZXJzaW9uIDMyLCBhZGRyZXNzIDB4
ZmVjMDAwMDAsIEdTSSAwLTIzDQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBJTlRfU1JDX09WUiAo
YnVzIDAgYnVzX2lycSAwIGdsb2JhbF9pcnEgMiBkZmwgZGZsKQ0KWyAgICAwLjAwMDAwMF0g
QUNQSTogSU5UX1NSQ19PVlIgKGJ1cyAwIGJ1c19pcnEgOSBnbG9iYWxfaXJxIDkgaGlnaCBs
ZXZlbCkNClsgICAgMC4wMDAwMDBdIEFDUEk6IElSUTAgdXNlZCBieSBvdmVycmlkZS4NClsg
ICAgMC4wMDAwMDBdIEFDUEk6IElSUTIgdXNlZCBieSBvdmVycmlkZS4NClsgICAgMC4wMDAw
MDBdIEFDUEk6IElSUTkgdXNlZCBieSBvdmVycmlkZS4NClsgICAgMC4wMDAwMDBdIFVzaW5n
IEFDUEkgKE1BRFQpIGZvciBTTVAgY29uZmlndXJhdGlvbiBpbmZvcm1hdGlvbg0KWyAgICAw
LjAwMDAwMF0gQUNQSTogSFBFVCBpZDogMHg4MDg2YTcwMSBiYXNlOiAweGZlZDAwMDAwDQpb
ICAgIDAuMDAwMDAwXSBzbXBib290OiBBbGxvd2luZyA0IENQVXMsIDAgaG90cGx1ZyBDUFVz
DQpbICAgIDAuMDAwMDAwXSBucl9pcnFzX2dzaTogNDANClsgICAgMC4wMDAwMDBdIGU4MjA6
IFttZW0gMHg3ZWYwMDAwMC0weGZlYmZmZmZmXSBhdmFpbGFibGUgZm9yIFBDSSBkZXZpY2Vz
DQpbICAgIDAuMDAwMDAwXSBCb290aW5nIHBhcmF2aXJ0dWFsaXplZCBrZXJuZWwgb24gWGVu
DQpbICAgIDAuMDAwMDAwXSBYZW4gdmVyc2lvbjogNC4yLjAtcmM0LXByZSAocHJlc2VydmUt
QUQpDQpbICAgIDAuMDAwMDAwXSBzZXR1cF9wZXJjcHU6IE5SX0NQVVM6OCBucl9jcHVtYXNr
X2JpdHM6OCBucl9jcHVfaWRzOjQgbnJfbm9kZV9pZHM6MQ0KWyAgICAwLjAwMDAwMF0gUEVS
Q1BVOiBFbWJlZGRlZCAyNyBwYWdlcy9jcHUgQGZmZmY4ODAwM2ZjMDAwMDAgczgwODk2IHI4
MTkyIGQyMTUwNCB1NTI0Mjg4DQpbICAgIDAuMDAwMDAwXSBwY3B1LWFsbG9jOiBzODA4OTYg
cjgxOTIgZDIxNTA0IHU1MjQyODggYWxsb2M9MSoyMDk3MTUyDQpbICAgIDAuMDAwMDAwXSBw
Y3B1LWFsbG9jOiBbMF0gMCAxIDIgMyANClsgICAgMC4wMDAwMDBdIEJ1aWx0IDEgem9uZWxp
c3RzIGluIE5vZGUgb3JkZXIsIG1vYmlsaXR5IGdyb3VwaW5nIG9uLiAgVG90YWwgcGFnZXM6
IDI1NzkyOA0KWyAgICAwLjAwMDAwMF0gUG9saWN5IHpvbmU6IERNQTMyDQpbICAgIDAuMDAw
MDAwXSBLZXJuZWwgY29tbWFuZCBsaW5lOiByb290PS9kZXYvc2RhMSBybyB2ZXJib3NlIG1l
bT0xMDI0TSBjb25zb2xlPWh2YzAgY29uc29sZT10dHkwIG5vbW9kZXNldCB2Z2E9MzAzIGVh
cmx5cHJpbnRrPXhlbiBtYXhfbG9vcD01MCBsb29wX21heF9wYXJ0PTEwIGRlYnVnIGxvZ2xl
dmVsPTEwDQpbICAgIDAuMDAwMDAwXSBQSUQgaGFzaCB0YWJsZSBlbnRyaWVzOiA0MDk2IChv
cmRlcjogMywgMzI3NjggYnl0ZXMpDQpbICAgIDAuMDAwMDAwXSBfX2V4X3RhYmxlIGFscmVh
ZHkgc29ydGVkLCBza2lwcGluZyBzb3J0DQpbICAgIDAuMDAwMDAwXSB4c2F2ZTogZW5hYmxl
ZCB4c3RhdGVfYnYgMHgzLCBjbnR4dCBzaXplIDB4MjQwDQpbICAgIDAuMDAwMDAwXSBzb2Z0
d2FyZSBJTyBUTEIgW21lbSAweDNhNjAwMDAwLTB4M2U1ZmZmZmZdICg2NE1CKSBtYXBwZWQg
YXQgW2ZmZmY4ODAwM2E2MDAwMDAtZmZmZjg4MDAzZTVmZmZmZl0NClsgICAgMC4wMDAwMDBd
IE1lbW9yeTogOTMxMDI0ay8xMDQ4NTc2ayBhdmFpbGFibGUgKDg1MTFrIGtlcm5lbCBjb2Rl
LCA0NTZrIGFic2VudCwgMTE3MDk2ayByZXNlcnZlZCwgNjcwNGsgZGF0YSwgNjcyayBpbml0
KQ0KWyAgICAwLjAwMDAwMF0gU0xVQjogR2Vuc2xhYnM9MTUsIEhXYWxpZ249NjQsIE9yZGVy
PTAtMywgTWluT2JqZWN0cz0wLCBDUFVzPTQsIE5vZGVzPTENClsgICAgMC4wMDAwMDBdIFBy
ZWVtcHRpYmxlIGhpZXJhcmNoaWNhbCBSQ1UgaW1wbGVtZW50YXRpb24uDQpbICAgIDAuMDAw
MDAwXSAJUkNVIGR5bnRpY2staWRsZSBncmFjZS1wZXJpb2QgYWNjZWxlcmF0aW9uIGlzIGVu
YWJsZWQuDQpbICAgIDAuMDAwMDAwXSAJQWRkaXRpb25hbCBwZXItQ1BVIGluZm8gcHJpbnRl
ZCB3aXRoIHN0YWxscy4NClsgICAgMC4wMDAwMDBdIAlSQ1UgcmVzdHJpY3RpbmcgQ1BVcyBm
cm9tIE5SX0NQVVM9OCB0byBucl9jcHVfaWRzPTQuDQpbICAgIDAuMDAwMDAwXSBOUl9JUlFT
OjQzNTIgbnJfaXJxczo3MTIgMTYNClsgICAgMC4wMDAwMDBdIHhlbjogc2NpIG92ZXJyaWRl
OiBnbG9iYWxfaXJxPTkgdHJpZ2dlcj0wIHBvbGFyaXR5PTANClsgICAgMC4wMDAwMDBdIHhl
bjogcmVnaXN0ZXJpbmcgZ3NpIDkgdHJpZ2dlcmluZyAwIHBvbGFyaXR5IDANClsgICAgMC4w
MDAwMDBdIHhlbjogLS0+IHBpcnE9OSAtPiBpcnE9OSAoZ3NpPTkpDQooWEVOKSBbMjAxMi0w
OS0wNCAxODo0MToyNl0gSU9BUElDWzBdOiBTZXQgUENJIHJvdXRpbmcgZW50cnkgKDQtOSAt
PiAweDU4IC0+IElSUSA5IE1vZGU6MSBBY3RpdmU6MCkNClsgICAgMC4wMDAwMDBdIHhlbjog
YWNwaSBzY2kgOQ0KWyAgICAwLjAwMDAwMF0geGVuOiAtLT4gcGlycT0xIC0+IGlycT0xIChn
c2k9MSkNClsgICAgMC4wMDAwMDBdIHhlbjogLS0+IHBpcnE9MiAtPiBpcnE9MiAoZ3NpPTIp
DQpbICAgIDAuMDAwMDAwXSB4ZW46IC0tPiBwaXJxPTMgLT4gaXJxPTMgKGdzaT0zKQ0KWyAg
ICAwLjAwMDAwMF0geGVuOiAtLT4gcGlycT00IC0+IGlycT00IChnc2k9NCkNClsgICAgMC4w
MDAwMDBdIHhlbjogLS0+IHBpcnE9NSAtPiBpcnE9NSAoZ3NpPTUpDQpbICAgIDAuMDAwMDAw
XSB4ZW46IC0tPiBwaXJxPTYgLT4gaXJxPTYgKGdzaT02KQ0KWyAgICAwLjAwMDAwMF0geGVu
OiAtLT4gcGlycT03IC0+IGlycT03IChnc2k9NykNClsgICAgMC4wMDAwMDBdIHhlbjogLS0+
IHBpcnE9OCAtPiBpcnE9OCAoZ3NpPTgpDQpbICAgIDAuMDAwMDAwXSB4ZW46IC0tPiBwaXJx
PTEwIC0+IGlycT0xMCAoZ3NpPTEwKQ0KWyAgICAwLjAwMDAwMF0geGVuOiAtLT4gcGlycT0x
MSAtPiBpcnE9MTEgKGdzaT0xMSkNClsgICAgMC4wMDAwMDBdIHhlbjogLS0+IHBpcnE9MTIg
LT4gaXJxPTEyIChnc2k9MTIpDQpbICAgIDAuMDAwMDAwXSB4ZW46IC0tPiBwaXJxPTEzIC0+
IGlycT0xMyAoZ3NpPTEzKQ0KWyAgICAwLjAwMDAwMF0geGVuOiAtLT4gcGlycT0xNCAtPiBp
cnE9MTQgKGdzaT0xNCkNClsgICAgMC4wMDAwMDBdIHhlbjogLS0+IHBpcnE9MTUgLT4gaXJx
PTE1IChnc2k9MTUpDQpbICAgIDAuMDAwMDAwXSBDb25zb2xlOiBjb2xvdXIgZHVtbXkgZGV2
aWNlIDgweDI1DQpbICAgIDAuMDAwMDAwXSBjb25zb2xlIFt0dHkwXSBlbmFibGVkLCBib290
Y29uc29sZSBkaXNhYmxlZA0KWyAgICAwLjAwMDAwMF0gSW5pdGlhbGl6aW5nIGNncm91cCBz
dWJzeXMgY3B1c2V0DQpbICAgIDAuMDAwMDAwXSBJbml0aWFsaXppbmcgY2dyb3VwIHN1YnN5
cyBjcHUNClsgICAgMC4wMDAwMDBdIExpbnV4IHZlcnNpb24gMy42LjAtcmM0LTIwMTIwODMw
KyAocm9vdEB4ZW50ZXN0KSAoZ2NjIHZlcnNpb24gNC40LjUgKERlYmlhbiA0LjQuNS04KSAp
ICM2OCBTTVAgUFJFRU1QVCBUdWUgU2VwIDQgMjA6MzY6NDcgQ0VTVCAyMDEyDQpbICAgIDAu
MDAwMDAwXSBDb21tYW5kIGxpbmU6IHJvb3Q9L2Rldi9zZGExIHJvIHZlcmJvc2UgbWVtPTEw
MjRNIGNvbnNvbGU9aHZjMCBjb25zb2xlPXR0eTAgbm9tb2Rlc2V0IHZnYT0zMDMgZWFybHlw
cmludGs9eGVuIG1heF9sb29wPTUwIGxvb3BfbWF4X3BhcnQ9MTAgZGVidWcgbG9nbGV2ZWw9
MTANClsgICAgMC4wMDAwMDBdIEZyZWVpbmcgOWUtMTAwIHBmbiByYW5nZTogOTggcGFnZXMg
ZnJlZWQNClsgICAgMC4wMDAwMDBdIDEtMSBtYXBwaW5nIG9uIDllLT4xMDANClsgICAgMC4w
MDAwMDBdIDEtMSBtYXBwaW5nIG9uIDdlZTcwLT4xMDAwMDANClsgICAgMC4wMDAwMDBdIFJl
bGVhc2VkIDk4IHBhZ2VzIG9mIHVudXNlZCBtZW1vcnkNClsgICAgMC4wMDAwMDBdIFNldCA1
Mjg4ODIgcGFnZShzKSB0byAxLTEgbWFwcGluZw0KWyAgICAwLjAwMDAwMF0gUG9wdWxhdGlu
ZyA0MDAwMC00MDA2MiBwZm4gcmFuZ2U6IDk4IHBhZ2VzIGFkZGVkDQpbICAgIDAuMDAwMDAw
XSBlODIwOiBCSU9TLXByb3ZpZGVkIHBoeXNpY2FsIFJBTSBtYXA6DQpbICAgIDAuMDAwMDAw
XSBYZW46IFttZW0gMHgwMDAwMDAwMDAwMDAwMDAwLTB4MDAwMDAwMDAwMDA5ZGZmZl0gdXNh
YmxlDQpbICAgIDAuMDAwMDAwXSBYZW46IFttZW0gMHgwMDAwMDAwMDAwMDllODAwLTB4MDAw
MDAwMDAwMDBmZmZmZl0gcmVzZXJ2ZWQNClsgICAgMC4wMDAwMDBdIFhlbjogW21lbSAweDAw
MDAwMDAwMDAxMDAwMDAtMHgwMDAwMDAwMDQwMDYxZmZmXSB1c2FibGUNClsgICAgMC4wMDAw
MDBdIFhlbjogW21lbSAweDAwMDAwMDAwNDAwNjIwMDAtMHgwMDAwMDAwMDdlZTZmZmZmXSB1
bnVzYWJsZQ0KWyAgICAwLjAwMDAwMF0gWGVuOiBbbWVtIDB4MDAwMDAwMDA3ZWU3MDAwMC0w
eDAwMDAwMDAwN2VlN2RmZmZdIEFDUEkgZGF0YQ0KWyAgICAwLjAwMDAwMF0gWGVuOiBbbWVt
IDB4MDAwMDAwMDA3ZWU3ZTAwMC0weDAwMDAwMDAwN2VlY2ZmZmZdIEFDUEkgTlZTDQpbICAg
IDAuMDAwMDAwXSBYZW46IFttZW0gMHgwMDAwMDAwMDdlZWQwMDAwLTB4MDAwMDAwMDA3ZWVm
ZmZmZl0gcmVzZXJ2ZWQNClsgICAgMC4wMDAwMDBdIFhlbjogW21lbSAweDAwMDAwMDAwZmVj
MDAwMDAtMHgwMDAwMDAwMGZlYzAwZmZmXSByZXNlcnZlZA0KWyAgICAwLjAwMDAwMF0gWGVu
OiBbbWVtIDB4MDAwMDAwMDBmZWQwMDAwMC0weDAwMDAwMDAwZmVkMDEwZmZdIHJlc2VydmVk
DQpbICAgIDAuMDAwMDAwXSBYZW46IFttZW0gMHgwMDAwMDAwMGZlZDAyMDAwLTB4MDAwMDAw
MDBmZWQxNGJmZl0gcmVzZXJ2ZWQNClsgICAgMC4wMDAwMDBdIFhlbjogW21lbSAweDAwMDAw
MDAwZmVkMjAwMDAtMHgwMDAwMDAwMGZlZDNmZmZmXSByZXNlcnZlZA0KWyAgICAwLjAwMDAw
MF0gWGVuOiBbbWVtIDB4MDAwMDAwMDBmZWUwMDAwMC0weDAwMDAwMDAwZmVlMDBmZmZdIHJl
c2VydmVkDQpbICAgIDAuMDAwMDAwXSBYZW46IFttZW0gMHgwMDAwMDAwMGZmZTAwMDAwLTB4
MDAwMDAwMDBmZmZmZmZmZl0gcmVzZXJ2ZWQNClsgICAgMC4wMDAwMDBdIGU4MjA6IHJlbW92
ZSBbbWVtIDB4NDAwMDAwMDAtMHhmZmZmZmZmZmZmZmZmZmZlXSB1c2FibGUNClsgICAgMC4w
MDAwMDBdIGJvb3Rjb25zb2xlIFt4ZW5ib290MF0gZW5hYmxlZA0KWyAgICAwLjAwMDAwMF0g
TlggKEV4ZWN1dGUgRGlzYWJsZSkgcHJvdGVjdGlvbjogYWN0aXZlDQpbICAgIDAuMDAwMDAw
XSBlODIwOiB1c2VyLWRlZmluZWQgcGh5c2ljYWwgUkFNIG1hcDoNClsgICAgMC4wMDAwMDBd
IHVzZXI6IFttZW0gMHgwMDAwMDAwMDAwMDAwMDAwLTB4MDAwMDAwMDAwMDA5ZGZmZl0gdXNh
YmxlDQpbICAgIDAuMDAwMDAwXSB1c2VyOiBbbWVtIDB4MDAwMDAwMDAwMDA5ZTgwMC0weDAw
MDAwMDAwMDAwZmZmZmZdIHJlc2VydmVkDQpbICAgIDAuMDAwMDAwXSB1c2VyOiBbbWVtIDB4
MDAwMDAwMDAwMDEwMDAwMC0weDAwMDAwMDAwM2ZmZmZmZmZdIHVzYWJsZQ0KWyAgICAwLjAw
MDAwMF0gdXNlcjogW21lbSAweDAwMDAwMDAwNDAwNjIwMDAtMHgwMDAwMDAwMDdlZTZmZmZm
XSB1bnVzYWJsZQ0KWyAgICAwLjAwMDAwMF0gdXNlcjogW21lbSAweDAwMDAwMDAwN2VlNzAw
MDAtMHgwMDAwMDAwMDdlZTdkZmZmXSBBQ1BJIGRhdGENClsgICAgMC4wMDAwMDBdIHVzZXI6
IFttZW0gMHgwMDAwMDAwMDdlZTdlMDAwLTB4MDAwMDAwMDA3ZWVjZmZmZl0gQUNQSSBOVlMN
ClsgICAgMC4wMDAwMDBdIHVzZXI6IFttZW0gMHgwMDAwMDAwMDdlZWQwMDAwLTB4MDAwMDAw
MDA3ZWVmZmZmZl0gcmVzZXJ2ZWQNClsgICAgMC4wMDAwMDBdIHVzZXI6IFttZW0gMHgwMDAw
MDAwMGZlYzAwMDAwLTB4MDAwMDAwMDBmZWMwMGZmZl0gcmVzZXJ2ZWQNClsgICAgMC4wMDAw
MDBdIHVzZXI6IFttZW0gMHgwMDAwMDAwMGZlZDAwMDAwLTB4MDAwMDAwMDBmZWQwMTBmZl0g
cmVzZXJ2ZWQNClsgICAgMC4wMDAwMDBdIHVzZXI6IFttZW0gMHgwMDAwMDAwMGZlZDAyMDAw
LTB4MDAwMDAwMDBmZWQxNGJmZl0gcmVzZXJ2ZWQNClsgICAgMC4wMDAwMDBdIHVzZXI6IFtt
ZW0gMHgwMDAwMDAwMGZlZDIwMDAwLTB4MDAwMDAwMDBmZWQzZmZmZl0gcmVzZXJ2ZWQNClsg
ICAgMC4wMDAwMDBdIHVzZXI6IFttZW0gMHgwMDAwMDAwMGZlZTAwMDAwLTB4MDAwMDAwMDBm
ZWUwMGZmZl0gcmVzZXJ2ZWQNClsgICAgMC4wMDAwMDBdIHVzZXI6IFttZW0gMHgwMDAwMDAw
MGZmZTAwMDAwLTB4MDAwMDAwMDBmZmZmZmZmZl0gcmVzZXJ2ZWQNClsgICAgMC4wMDAwMDBd
IERNSSBwcmVzZW50Lg0KWyAgICAwLjAwMDAwMF0gRE1JOiBTeXN0ZW0gbWFudWZhY3R1cmVy
IFN5c3RlbSBQcm9kdWN0IE5hbWUvUDVRLUVNIERPLCBCSU9TIDEyMDggICAgMDUvMjUvMjAx
MA0KWyAgICAwLjAwMDAwMF0gZTgyMDogdXBkYXRlIFttZW0gMHgwMDAwMDAwMC0weDAwMDBm
ZmZmXSB1c2FibGUgPT0+IHJlc2VydmVkDQpbICAgIDAuMDAwMDAwXSBlODIwOiByZW1vdmUg
W21lbSAweDAwMGEwMDAwLTB4MDAwZmZmZmZdIHVzYWJsZQ0KWyAgICAwLjAwMDAwMF0gTm8g
QUdQIGJyaWRnZSBmb3VuZA0KWyAgICAwLjAwMDAwMF0gZTgyMDogbGFzdF9wZm4gPSAweDQw
MDAwIG1heF9hcmNoX3BmbiA9IDB4NDAwMDAwMDAwDQpbICAgIDAuMDAwMDAwXSBmb3VuZCBT
TVAgTVAtdGFibGUgYXQgW21lbSAweDAwMGZmNzgwLTB4MDAwZmY3OGZdIG1hcHBlZCBhdCBb
ZmZmZjg4MDAwMDBmZjc4MF0NClsgICAgMC4wMDAwMDBdIGluaXRpYWwgbWVtb3J5IG1hcHBl
ZDogW21lbSAweDAwMDAwMDAwLTB4MDMxNGVmZmZdDQpbICAgIDAuMDAwMDAwXSBCYXNlIG1l
bW9yeSB0cmFtcG9saW5lIGF0IFtmZmZmODgwMDAwMDk4MDAwXSA5ODAwMCBzaXplIDI0NTc2
DQpbICAgIDAuMDAwMDAwXSBpbml0X21lbW9yeV9tYXBwaW5nOiBbbWVtIDB4MDAwMDAwMDAt
MHgzZmZmZmZmZl0NClsgICAgMC4wMDAwMDBdICBbbWVtIDB4MDAwMDAwMDAtMHgzZmZmZmZm
Zl0gcGFnZSA0aw0KWyAgICAwLjAwMDAwMF0ga2VybmVsIGRpcmVjdCBtYXBwaW5nIHRhYmxl
cyB1cCB0byAweDNmZmZmZmZmIEAgW21lbSAweDAyYWQ2MDAwLTB4MDJjZDdmZmZdDQpbICAg
IDAuMDAwMDAwXSB4ZW46IHNldHRpbmcgUlcgdGhlIHJhbmdlIDJjYjgwMDAgLSAyY2Q4MDAw
DQpbICAgIDAuMDAwMDAwXSBSQU1ESVNLOiBbbWVtIDB4MDJjZDgwMDAtMHgwMzE0ZWZmZl0N
ClsgICAgMC4wMDAwMDBdIEFDUEk6IFJTRFAgMDAwMDAwMDAwMDBmYjA4MCAwMDAyNCAodjAy
IEFDUElBTSkNClsgICAgMC4wMDAwMDBdIEFDUEk6IFhTRFQgMDAwMDAwMDA3ZWU3MDEwMCAw
MDA1QyAodjAxIEFfTV9JXyBPRU1YU0RUICAwNTAwMTAyNSBNU0ZUIDAwMDAwMDk3KQ0KWyAg
ICAwLjAwMDAwMF0gQUNQSTogRkFDUCAwMDAwMDAwMDdlZTcwMjkwIDAwMEY0ICh2MDMgQV9N
X0lfIE9FTUZBQ1AgIDA1MDAxMDI1IE1TRlQgMDAwMDAwOTcpDQpbICAgIDAuMDAwMDAwXSBB
Q1BJOiBEU0RUIDAwMDAwMDAwN2VlNzA0NDAgMDg0MUYgKHYwMSAgQTEwNjUgQTEwNjUwMDAg
MDAwMDAwMDAgSU5UTCAyMDA2MDExMykNClsgICAgMC4wMDAwMDBdIEFDUEk6IEZBQ1MgMDAw
MDAwMDA3ZWU3ZTAwMCAwMDA0MA0KWyAgICAwLjAwMDAwMF0gQUNQSTogQVBJQyAwMDAwMDAw
MDdlZTcwMzkwIDAwMDZDICh2MDEgQV9NX0lfIE9FTUFQSUMgIDA1MDAxMDI1IE1TRlQgMDAw
MDAwOTcpDQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBNQ0ZHIDAwMDAwMDAwN2VlNzA0MDAgMDAw
M0MgKHYwMSBBX01fSV8gT0VNTUNGRyAgMDUwMDEwMjUgTVNGVCAwMDAwMDA5NykNClsgICAg
MC4wMDAwMDBdIEFDUEk6IE9FTUIgMDAwMDAwMDA3ZWU3ZTA0MCAwMDA4OSAodjAxIEFfTV9J
XyBBTUlfT0VNICAwNTAwMTAyNSBNU0ZUIDAwMDAwMDk3KQ0KWyAgICAwLjAwMDAwMF0gQUNQ
STogSFBFVCAwMDAwMDAwMDdlZTc4ODYwIDAwMDM4ICh2MDEgQV9NX0lfIE9FTUhQRVQgIDA1
MDAxMDI1IE1TRlQgMDAwMDAwOTcpDQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBHU0NJIDAwMDAw
MDAwN2VlN2UwZDAgMDIwMjQgKHYwMSBBX01fSV8gR01DSFNDSSAgMDUwMDEwMjUgTVNGVCAw
MDAwMDA5NykNClsgICAgMC4wMDAwMDBdIEFDUEk6IFNTRFQgMDAwMDAwMDA3ZWU4MGEwMCAw
MEE3QyAodjAxIERwZ1BtbSAgICBDcHVQbSAwMDAwMDAxMiBJTlRMIDIwMDYwMTEzKQ0KWyAg
ICAwLjAwMDAwMF0gQUNQSTogTG9jYWwgQVBJQyBhZGRyZXNzIDB4ZmVlMDAwMDANClsgICAg
MC4wMDAwMDBdIE5vIE5VTUEgY29uZmlndXJhdGlvbiBmb3VuZA0KWyAgICAwLjAwMDAwMF0g
RmFraW5nIGEgbm9kZSBhdCBbbWVtIDB4MDAwMDAwMDAwMDAwMDAwMC0weDAwMDAwMDAwM2Zm
ZmZmZmZdDQpbICAgIDAuMDAwMDAwXSBJbml0bWVtIHNldHVwIG5vZGUgMCBbbWVtIDB4MDAw
MDAwMDAtMHgzZmZmZmZmZl0NClsgICAgMC4wMDAwMDBdICAgTk9ERV9EQVRBIFttZW0gMHgz
ZmZmNTAwMC0weDNmZmZmZmZmXQ0KWyAgICAwLjAwMDAwMF0gWm9uZSByYW5nZXM6DQpbICAg
IDAuMDAwMDAwXSAgIERNQSAgICAgIFttZW0gMHgwMDAxMDAwMC0weDAwZmZmZmZmXQ0KWyAg
ICAwLjAwMDAwMF0gICBETUEzMiAgICBbbWVtIDB4MDEwMDAwMDAtMHhmZmZmZmZmZl0NClsg
ICAgMC4wMDAwMDBdICAgTm9ybWFsICAgZW1wdHkNClsgICAgMC4wMDAwMDBdIE1vdmFibGUg
em9uZSBzdGFydCBmb3IgZWFjaCBub2RlDQpbICAgIDAuMDAwMDAwXSBFYXJseSBtZW1vcnkg
bm9kZSByYW5nZXMNClsgICAgMC4wMDAwMDBdICAgbm9kZSAgIDA6IFttZW0gMHgwMDAxMDAw
MC0weDAwMDlkZmZmXQ0KWyAgICAwLjAwMDAwMF0gICBub2RlICAgMDogW21lbSAweDAwMTAw
MDAwLTB4M2ZmZmZmZmZdDQpbICAgIDAuMDAwMDAwXSBPbiBub2RlIDAgdG90YWxwYWdlczog
MjYyMDMwDQpbICAgIDAuMDAwMDAwXSAgIERNQSB6b25lOiA2NCBwYWdlcyB1c2VkIGZvciBt
ZW1tYXANClsgICAgMC4wMDAwMDBdICAgRE1BIHpvbmU6IDYgcGFnZXMgcmVzZXJ2ZWQNClsg
ICAgMC4wMDAwMDBdICAgRE1BIHpvbmU6IDM5MTIgcGFnZXMsIExJRk8gYmF0Y2g6MA0KWyAg
ICAwLjAwMDAwMF0gICBETUEzMiB6b25lOiA0MDMyIHBhZ2VzIHVzZWQgZm9yIG1lbW1hcA0K
WyAgICAwLjAwMDAwMF0gICBETUEzMiB6b25lOiAyNTQwMTYgcGFnZXMsIExJRk8gYmF0Y2g6
MzENClsgICAgMC4wMDAwMDBdIEFDUEk6IFBNLVRpbWVyIElPIFBvcnQ6IDB4ODA4DQpbICAg
IDAuMDAwMDAwXSBBQ1BJOiBMb2NhbCBBUElDIGFkZHJlc3MgMHhmZWUwMDAwMA0KWyAgICAw
LjAwMDAwMF0gQUNQSTogTEFQSUMgKGFjcGlfaWRbMHgwMV0gbGFwaWNfaWRbMHgwMF0gZW5h
YmxlZCkNClsgICAgMC4wMDAwMDBdIEFDUEk6IExBUElDIChhY3BpX2lkWzB4MDJdIGxhcGlj
X2lkWzB4MDFdIGVuYWJsZWQpDQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBMQVBJQyAoYWNwaV9p
ZFsweDAzXSBsYXBpY19pZFsweDAyXSBlbmFibGVkKQ0KWyAgICAwLjAwMDAwMF0gQUNQSTog
TEFQSUMgKGFjcGlfaWRbMHgwNF0gbGFwaWNfaWRbMHgwM10gZW5hYmxlZCkNClsgICAgMC4w
MDAwMDBdIEFDUEk6IElPQVBJQyAoaWRbMHgwNF0gYWRkcmVzc1sweGZlYzAwMDAwXSBnc2lf
YmFzZVswXSkNClsgICAgMC4wMDAwMDBdIElPQVBJQ1swXTogYXBpY19pZCA0LCB2ZXJzaW9u
IDMyLCBhZGRyZXNzIDB4ZmVjMDAwMDAsIEdTSSAwLTIzDQpbICAgIDAuMDAwMDAwXSBBQ1BJ
OiBJTlRfU1JDX09WUiAoYnVzIDAgYnVzX2lycSAwIGdsb2JhbF9pclsgICAgMi4xMTM0ODdd
IGh1YiAyLTA6MS4wOiBzdGF0ZSA3IHBvcnRzIDYgY2hnIDAwMDAgZXZ0IDAwMDANClsgICAg
Mi4xMTM1MDFdIHVoY2lfaGNkIDAwMDA6MDA6MWEuMDogaXJxIDE2LCBpbyBiYXNlIDB4MDAw
MGI0ODANClsgICAgMi4xMTM1OTZdIHVzYiB1c2IzOiBkZWZhdWx0IGxhbmd1YWdlIDB4MDQw
OQ0KWyAgICAyLjExMzYwOF0gdXNiIHVzYjM6IHVkZXYgMSwgYnVzbnVtIDMsIG1pbm9yID0g
MjU2DQpbICAgIDIuMTEzNjEwXSB1c2IgdXNiMzogTmV3IFVTQiBkZXZpY2UgZm91bmQsIGlk
VmVuZG9yPTFkNmIsIGlkUHJvZHVjdD0wMDAxDQpbICAgIDIuMTEzNjEyXSB1c2IgdXNiMzog
TmV3IFVTQiBkZXZpY2Ugc3RyaW5nczogTWZyPTMsIFByb2R1Y3Q9MiwgU2VyaWFsTnVtYmVy
PTENClsgICAgMi4xMTM2MTNdIHVzYiB1c2IzOiBQcm9kdWN0OiBVSENJIEhvc3QgQ29udHJv
bGxlcg0KWyAgICAyLjExMzYxNV0gdXNiIHVzYjM6IE1hbnVmYWN0dXJlcjogTGludXggMy42
LjAtcmM0LTIwMTIwODMwKyB1aGNpX2hjZA0KWyAgICAyLjExMzYxNl0gdXNiIHVzYjM6IFNl
cmlhbE51bWJlcjogMDAwMDowMDoxYS4wDQpbICAgIDIuMTEzODYzXSB1c2IgdXNiMzogdXNi
X3Byb2JlX2RldmljZQ0KWyAgICAyLjExMzg2NV0gdXNiIHVzYjM6IGNvbmZpZ3VyYXRpb24g
IzEgY2hvc2VuIGZyb20gMSBjaG9pY2UNClsgICAgMi4xMTM4NzZdIHVzYiB1c2IzOiBhZGRp
bmcgMy0wOjEuMCAoY29uZmlnICMxLCBpbnRlcmZhY2UgMCkNClsgICAgMi4xMTQwMzJdIGh1
YiAzLTA6MS4wOiB1c2JfcHJvYmVfaW50ZXJmYWNlDQpbICAgIDIuMTE0MDM1XSBodWIgMy0w
OjEuMDogdXNiX3Byb2JlX2ludGVyZmFjZSAtIGdvdCBpZA0KWyAgICAyLjExNDAzOF0gaHVi
IDMtMDoxLjA6IFVTQiBodWIgZm91bmQNClsgICAgMi4xMTQwNTBdIGh1YiAzLTA6MS4wOiAy
IHBvcnRzIGRldGVjdGVkDQpbICAgIDIuMTE0MDUzXSBodWIgMy0wOjEuMDogc3RhbmRhbG9u
ZSBodWINClsgICAgMi4xMTQwNTRdIGh1YiAzLTA6MS4wOiBubyBwb3dlciBzd2l0Y2hpbmcg
KHVzYiAxLjApDQpbICAgIDIuMTE0MDU2XSBodWIgMy0wOjEuMDogaW5kaXZpZHVhbCBwb3J0
IG92ZXItY3VycmVudCBwcm90ZWN0aW9uDQpbICAgIDIuMTE0MDU4XSBodWIgMy0wOjEuMDog
cG93ZXIgb24gdG8gcG93ZXIgZ29vZCB0aW1lOiAybXMNClsgICAgMi4xMTQwODZdIGh1YiAz
LTA6MS4wOiBsb2NhbCBwb3dlciBzb3VyY2UgaXMgZ29vZA0KWyAgICAyLjExNDA4OF0gaHVi
IDMtMDoxLjA6IHRyeWluZyB0byBlbmFibGUgcG9ydCBwb3dlciBvbiBub24tc3dpdGNoYWJs
ZSBodWINClsgICAgMi4xMTQxOTldIGVoY2lfaGNkIDAwMDA6MDA6MWEuNzogSFMgY29tcGFu
aW9uIGZvciAwMDAwOjAwOjFhLjANClsgICAgMi4xMTQyNTVdIHhlbjogcmVnaXN0ZXJpbmcg
Z3NpIDIxIHRyaWdnZXJpbmcgMCBwb2xhcml0eSAxDQpbICAgIDIuMTE0MjU3XSBBbHJlYWR5
IHNldHVwIHRoZSBHU0kgOjIxDQpbICAgIDIuMTE0MjcwXSB1aGNpX2hjZCAwMDAwOjAwOjFh
LjE6IHNldHRpbmcgbGF0ZW5jeSB0aW1lciB0byA2NA0KWyAgICAyLjExNDI3NF0gdWhjaV9o
Y2QgMDAwMDowMDoxYS4xOiBVSENJIEhvc3QgQ29udHJvbGxlcg0KWyAgICAyLjExNDQyM10g
dWhjaV9oY2QgMDAwMDowMDoxYS4xOiBuZXcgVVNCIGJ1cyByZWdpc3RlcmVkLCBhc3NpZ25l
ZCBidXMgbnVtYmVyIDQNClsgICAgMi4xMTQ0MzNdIHVoY2lfaGNkIDAwMDA6MDA6MWEuMTog
ZGV0ZWN0ZWQgMiBwb3J0cw0KWyAgICAyLjExNDQ0MF0gdWhjaV9oY2QgMDAwMDowMDoxYS4x
OiB1aGNpX2NoZWNrX2FuZF9yZXNldF9oYzogY21kID0gMHgwMDAwDQpbICAgIDIuMTE0NDQy
XSB1aGNpX2hjZCAwMDAwOjAwOjFhLjE6IFBlcmZvcm1pbmcgZnVsbCByZXNldA0KWyAgICAy
LjExNDQ2MV0gdWhjaV9oY2QgMDAwMDowMDoxYS4xOiBzdXBwb3J0cyBVU0IgcmVtb3RlIHdh
a2V1cA0KWyAgICAyLjExNDQ5MF0gdWhjaV9oY2QgMDAwMDowMDoxYS4xOiBpcnEgMjEsIGlv
IGJhc2UgMHgwMDAwYjgwMA0KWyAgICAyLjExNDU2M10gdXNiIHVzYjQ6IGRlZmF1bHQgbGFu
Z3VhZ2UgMHgwNDA5DQpbICAgIDIuMTE0NTc1XSB1c2IgdXNiNDogdWRldiAxLCBidXNudW0g
NCwgbWlub3IgPSAzODQNClsgICAgMi4xMTQ1NzddIHVzYiB1c2I0OiBOZXcgVVNCIGRldmlj
ZSBmb3VuZCwgaWRWZW5kb3I9MWQ2YiwgaWRQcm9kdWN0PTAwMDENClsgICAgMi4xMTQ1Nzld
IHVzYiB1c2I0OiBOZXcgVVNCIGRldmljZSBzdHJpbmdzOiBNZnI9MywgUHJvZHVjdD0yLCBT
ZXJpYWxOdW1iZXI9MQ0KWyAgICAyLjExNDU4MF0gdXNiIHVzYjQ6IFByb2R1Y3Q6IFVIQ0kg
SG9zdCBDb250cm9sbGVyDQpbICAgIDIuMTE0NTgyXSB1c2IgdXNiNDogTWFudWZhY3R1cmVy
OiBMaW51eCAzLjYuMC1yYzQtMjAxMjA4MzArIHVoY2lfaGNkDQpbICAgIDIuMTE0NTgzXSB1
c2IgdXNiNDogU2VyaWFsTnVtYmVyOiAwMDAwOjAwOjFhLjENClsgICAgMi4xMTQ3NDZdIHVz
YiB1c2I0OiB1c2JfcHJvYmVfZGV2aWNlDQpbICAgIDIuMTE0NzQ4XSB1c2IgdXNiNDogY29u
ZmlndXJhdGlvbiAjMSBjaG9zZW4gZnJvbSAxIGNob2ljZQ0KWyAgICAyLjExNDc1OV0gdXNi
IHVzYjQ6IGFkZGluZyA0LTA6MS4wIChjb25maWcgIzEsIGludGVyZmFjZSAwKQ0KWyAgICAy
LjExNDg2MV0gaHViIDQtMDoxLjA6IHVzYl9wcm9iZV9pbnRlcmZhY2UNClsgICAgMi4xMTQ4
NjNdIGh1YiA0LTA6MS4wOiB1c2JfcHJvYmVfaW50ZXJmYWNlIC0gZ290IGlkDQpbICAgIDIu
MTE0ODY0XSBodWIgNC0wOjEuMDogVVNCIGh1YiBmb3VuZA0KWyAgICAyLjExNDg3Ml0gaHVi
IDQtMDoxLjA6IDIgcG9ydHMgZGV0ZWN0ZWQNClsgICAgMi4xMTQ4NzNdIGh1YiA0LTA6MS4w
OiBzdGFuZGFsb25lIGh1Yg0KWyAgICAyLjExNDg3NF0gaHViIDQtMDoxLjA6IG5vIHBvd2Vy
IHN3aXRjaGluZyAodXNiIDEuMCkNClsgICAgMi4xMTQ4NzVdIGh1YiA0LTA6MS4wOiBpbmRp
dmlkdWFsIHBvcnQgb3Zlci1jdXJyZW50IHByb3RlY3Rpb24NClsgICAgMi4xMTQ4NzddIGh1
YiA0LTA6MS4wOiBwb3dlciBvbiB0byBwb3dlciBnb29kIHRpbWU6IDJtcw0KWyAgICAyLjEx
NDg4Nl0gaHViIDQtMDoxLjA6IGxvY2FsIHBvd2VyIHNvdXJjZSBpcyBnb29kDQpbICAgIDIu
MTE0ODg3XSBodWIgNC0wOjEuMDogdHJ5aW5nIHRvIGVuYWJsZSBwb3J0IHBvd2VyIG9uIG5v
bi1zd2l0Y2hhYmxlIGh1Yg0KWyAgICAyLjExNDk3N10gZWhjaV9oY2QgMDAwMDowMDoxYS43
OiBIUyBjb21wYW5pb24gZm9yIDAwMDA6MDA6MWEuMQ0KWyAgICAyLjExNTAxNl0geGVuOiBy
ZWdpc3RlcmluZyBnc2kgMTggdHJpZ2dlcmluZyAwIHBvbGFyaXR5IDENClsgICAgMi4xMTUw
MThdIEFscmVhZHkgc2V0dXAgdGhlIEdTSSA6MTgNClsgICAgMi4xMTUwMzFdIHVoY2lfaGNk
IDAwMDA6MDA6MWEuMjogc2V0dGluZyBsYXRlbmN5IHRpbWVyIHRvIDY0DQpbICAgIDIuMTE1
MDM1XSB1aGNpX2hjZCAwMDAwOjAwOjFhLjI6IFVIQ0kgSG9zdCBDb250cm9sbGVyDQpbICAg
IDIuMTE1MTU4XSB1aGNpX2hjZCAwMDAwOjAwOjFhLjI6IG5ldyBVU0IgYnVzIHJlZ2lzdGVy
ZWQsIGFzc2lnbmVkIGJ1cyBudW1iZXIgNQ0KWyAgICAyLjExNTE2OV0gdWhjaV9oY2QgMDAw
MDowMDoxYS4yOiBkZXRlY3RlZCAyIHBvcnRzDQpbICAgIDIuMTE1MTc1XSB1aGNpX2hjZCAw
MDAwOjAwOjFhLjI6IHVoY2lfY2hlY2tfYW5kX3Jlc2V0X2hjOiBjbWQgPSAweDAwMDANClsg
ICAgMi4xMTUxNzddIHVoY2lfaGNkIDAwMDA6MDA6MWEuMjogUGVyZm9ybWluZyBmdWxsIHJl
c2V0DQpbICAgIDIuMTE1MTk2XSB1aGNpX2hjZCAwMDAwOjAwOjFhLjI6IHN1cHBvcnRzIFVT
QiByZW1vdGUgd2FrZXVwDQpbICAgIDIuMTE1MjA0XSB1aGNpX2hjZCAwMDAwOjAwOjFhLjI6
IGlycSAxOCwgaW8gYmFzZSAweDAwMDBiODgwDQpbICAgIDIuMTE1MjcxXSB1c2IgdXNiNTog
ZGVmYXVsdCBsYW5ndWFnZSAweDA0MDkNClsgICAgMi4xMTUyODNdIHVzYiB1c2I1OiB1ZGV2
IDEsIGJ1c251bSA1LCBtaW5vciA9IDUxMg0KWyAgICAyLjExNTI4NV0gdXNiIHVzYjU6IE5l
dyBVU0IgZGV2aWNlIGZvdW5kLCBpZFZlbmRvcj0xZDZiLCBpZFByb2R1Y3Q9MDAwMQ0KWyAg
ICAyLjExNTI4N10gdXNiIHVzYjU6IE5ldyBVU0IgZGV2aWNlIHN0cmluZ3M6IE1mcj0zLCBQ
cm9kdWN0PTIsIFNlcmlhbE51bWJlcj0xDQpbICAgIDIuMTE1Mjg4XSB1c2IgdXNiNTogUHJv
ZHVjdDogVUhDSSBIb3N0IENvbnRyb2xsZXINClsgICAgMi4xMTUyOTBdIHVzYiB1c2I1OiBN
YW51ZmFjdHVyZXI6IExpbnV4IDMuNi4wLXJjNC0yMDEyMDgzMCsgdWhjaV9oY2QNClsgICAg
Mi4xMTUyOTFdIHVzYiB1c2I1OiBTZXJpYWxOdW1iZXI6IDAwMDA6MDA6MWEuMg0KWyAgICAy
LjExNTQ1Ml0gdXNiIHVzYjU6IHVzYl9wcm9iZV9kZXZpY2UNClsgICAgMi4xMTU0NTRdIHVz
YiB1c2I1OiBjb25maWd1cmF0aW9uICMxIGNob3NlbiBmcm9tIDEgY2hvaWNlDQpbICAgIDIu
MTE1NDY1XSB1c2IgdXNiNTogYWRkaW5nIDUtMDoxLjAgKGNvbmZpZyAjMSwgaW50ZXJmYWNl
IDApDQpbICAgIDIuMTE1NTczXSBodWIgNS0wOjEuMDogdXNiX3Byb2JlX2ludGVyZmFjZQ0K
WyAgICAyLjExNTU3NF0gaHViIDUtMDoxLjA6IHVzYl9wcm9iZV9pbnRlcmZhY2UgLSBnb3Qg
aWQNClsgICAgMi4xMTU1NzZdIGh1YiA1LTA6MS4wOiBVU0IgaHViIGZvdW5kDQpbICAgIDIu
MTE1NTgzXSBodWIgNS0wOjEuMDogMiBwb3J0cyBkZXRlY3RlZA0KWyAgICAyLjExNTU4NV0g
aHViIDUtMDoxLjA6IHN0YW5kYWxvbmUgaHViDQpbICAgIDIuMTE1NTg2XSBodWIgNS0wOjEu
MDogbm8gcG93ZXIgc3dpdGNoaW5nICh1c2IgMS4wKQ0KWyAgICAyLjExNTU4N10gaHViIDUt
MDoxLjA6IGluZGl2aWR1YWwgcG9ydCBvdmVyLWN1cnJlbnQgcHJvdGVjdGlvbg0KWyAgICAy
LjExNTU4OV0gaHViIDUtMDoxLjA6IHBvd2VyIG9uIHRvIHBvd2VyIGdvb2QgdGltZTogMm1z
DQpbICAgIDIuMTE1NTk4XSBodWIgNS0wOjEuMDogbG9jYWwgcG93ZXIgc291cmNlIGlzIGdv
b2QNClsgICAgMi4xMTU1OTldIGh1YiA1LTA6MS4wOiB0cnlpbmcgdG8gZW5hYmxlIHBvcnQg
cG93ZXIgb24gbm9uLXN3aXRjaGFibGUgaHViDQpbICAgIDIuMTE1Njg5XSBlaGNpX2hjZCAw
MDAwOjAwOjFhLjc6IEhTIGNvbXBhbmlvbiBmb3IgMDAwMDowMDoxYS4yDQpbICAgIDIuMTE1
NzI5XSB4ZW46IHJlZ2lzdGVyaW5nIGdzaSAyMyB0cmlnZ2VyaW5nIDAgcG9sYXJpdHkgMQ0K
WyAgICAyLjExNTczMV0gQWxyZWFkeSBzZXR1cCB0aGUgR1NJIDoyMw0KWyAgICAyLjExNTc0
M10gdWhjaV9oY2QgMDAwMDowMDoxZC4wOiBzZXR0aW5nIGxhdGVuY3kgdGltZXIgdG8gNjQN
ClsgICAgMi4xMTU3NDddIHVoY2lfaGNkIDAwMDA6MDA6MWQuMDogVUhDSSBIb3N0IENvbnRy
b2xsZXINClsgICAgMi4xMTU4NzJdIHVoY2lfaGNkIDAwMDA6MDA6MWQuMDogbmV3IFVTQiBi
dXMgcmVnaXN0ZXJlZCwgYXNzaWduZWQgYnVzIG51bWJlciA2DQpbICAgIDIuMTE1ODgyXSB1
aGNpX2hjZCAwMDAwOjAwOjFkLjA6IGRldGVjdGVkIDIgcG9ydHMNClsgICAgMi4xMTU4ODld
IHVoY2lfaGNkIDAwMDA6MDA6MWQuMDogdWhjaV9jaGVja19hbmRfcmVzZXRfaGM6IGNtZCA9
IDB4MDAwMA0KWyAgICAyLjExNTg5MF0gdWhjaV9oY2QgMDAwMDowMDoxZC4wOiBQZXJmb3Jt
aW5nIGZ1bGwgcmVzZXQNClsgICAgMi4xMTU5MTBdIHVoY2lfaGNkIDAwMDA6MDA6MWQuMDog
c3VwcG9ydHMgVVNCIHJlbW90ZSB3YWtldXANClsgICAgMi4xMTU5MTddIHVoY2lfaGNkIDAw
MDA6MDA6MWQuMDogaXJxIDIzLCBpbyBiYXNlIDB4MDAwMGIwMDANClsgICAgMi4xMTU5ODdd
IHVzYiB1c2I2OiBkZWZhdWx0IGxhbmd1YWdlIDB4MDQwOQ0KWyAgICAyLjExNTk5OV0gdXNi
IHVzYjY6IHVkZXYgMSwgYnVzbnVtIDYsIG1pbm9yID0gNjQwDQpbICAgIDIuMTE2MDAxXSB1
c2IgdXNiNjogTmV3IFVTQiBkZXZpY2UgZm91bmQsIGlkVmVuZG9yPTFkNmIsIGlkUHJvZHVj
dD0wMDAxDQpbICAgIDIuMTE2MDAyXSB1c2IgdXNiNjogTmV3IFVTQiBkZXZpY2Ugc3RyaW5n
czogTWZyPTMsIFByb2R1Y3Q9MiwgU2VyaWFsTnVtYmVyPTENClsgICAgMi4xMTYwMDRdIHVz
YiB1c2I2OiBQcm9kdWN0OiBVSENJIEhvc3QgQ29udHJvbGxlcg0KWyAgICAyLjExNjAwNl0g
dXNiIHVzYjY6IE1hbnVmYWN0dXJlcjogTGludXggMy42LjAtcmM0LTIwMTIwODMwKyB1aGNp
X2hjZA0KWyAgICAyLjExNjAwN10gdXNiIHVzYjY6IFNlcmlhbE51bWJlcjogMDAwMDowMDox
ZC4wDQpbICAgIDIuMTE2MTY3XSB1c2IgdXNiNjogdXNiX3Byb2JlX2RldmljZQ0KWyAgICAy
LjExNjE2OV0gdXNiIHVzYjY6IGNvbmZpZ3VyYXRpb24gIzEgY2hvc2VuIGZyb20gMSBjaG9p
Y2UNClsgICAgMi4xMTYxODBdIHVzYiB1c2I2OiBhZGRpbmcgNi0wOjEuMCAoY29uZmlnICMx
LCBpbnRlcmZhY2UgMCkNClsgICAgMi4xMTYyODRdIGh1YiA2LTA6MS4wOiB1c2JfcHJvYmVf
aW50ZXJmYWNlDQpbICAgIDIuMTE2Mjg2XSBodWIgNi0wOjEuMDogdXNiX3Byb2JlX2ludGVy
ZmFjZSAtIGdvdCBpZA0KWyAgICAyLjExNjI4OF0gaHViIDYtMDoxLjA6IFVTQiBodWIgZm91
bmQNClsgICAgMi4xMTYyOTVdIGh1YiA2LTA6MS4wOiAyIHBvcnRzIGRldGVjdGVkDQpbICAg
IDIuMTE2Mjk2XSBodWIgNi0wOjEuMDogc3RhbmRhbG9uZSBodWINClsgICAgMi4xMTYyOThd
IGh1YiA2LTA6MS4wOiBubyBwb3dlciBzd2l0Y2hpbmcgKHVzYiAxLjApDQpbICAgIDIuMTE2
Mjk5XSBodWIgNi0wOjEuMDogaW5kaXZpZHVhbCBwb3J0IG92ZXItY3VycmVudCBwcm90ZWN0
aW9uDQpbICAgIDIuMTE2MzAwXSBodWIgNi0wOjEuMDogcG93ZXIgb24gdG8gcG93ZXIgZ29v
ZCB0aW1lOiAybXMNClsgICAgMi4xMTYzMDldIGh1YiA2LTA6MS4wOiBsb2NhbCBwb3dlciBz
b3VyY2UgaXMgZ29vZA0KWyAgICAyLjExNjMxMV0gaHViIDYtMDoxLjA6IHRyeWluZyB0byBl
bmFibGUgcG9ydCBwb3dlciBvbiBub24tc3dpdGNoYWJsZSBodWINClsgICAgMi4xMTY0MDhd
IGVoY2lfaGNkIDAwMDA6MDA6MWQuNzogSFMgY29tcGFuaW9uIGZvciAwMDAwOjAwOjFkLjAN
ClsgICAgMi4xMTY0MzddIHhlbjogcmVnaXN0ZXJpbmcgZ3NpIDE5IHRyaWdnZXJpbmcgMCBw
b2xhcml0eSAxDQpbICAgIDIuMTE2NDM5XSBBbHJlYWR5IHNldHVwIHRoZSBHU0kgOjE5DQpb
ICAgIDIuMTE2NDUxXSB1aGNpX2hjZCAwMDAwOjAwOjFkLjE6IHNldHRpbmcgbGF0ZW5jeSB0
aW1lciB0byA2NA0KWyAgICAyLjExNjQ1NV0gdWhjaV9oY2QgMDAwMDowMDoxZC4xOiBVSENJ
IEhvc3QgQ29udHJvbGxlcg0KWyAgICAyLjExNjU4MV0gdWhjaV9oY2QgMDAwMDowMDoxZC4x
OiBuZXcgVVNCIGJ1cyByZWdpc3RlcmVkLCBhc3NpZ25lZCBidXMgbnVtYmVyIDcNClsgICAg
Mi4xMTY1OTJdIHVoY2lfaGNkIDAwMDA6MDA6MWQuMTogZGV0ZWN0ZWQgMiBwb3J0cw0KWyAg
ICAyLjExNjU5OV0gdWhjaV9oY2QgMDAwMDowMDoxZC4xOiB1aGNpX2NoZWNrX2FuZF9yZXNl
dF9oYzogY21kID0gMHgwMDAwDQpbICAgIDIuMTE2NjAwXSB1aGNpX2hjZCAwMDAwOjAwOjFk
LjE6IFBlcmZvcm1pbmcgZnVsbCByZXNldA0KWyAgICAyLjExNjYxOV0gdWhjaV9oY2QgMDAw
MDowMDoxZC4xOiBzdXBwb3J0cyBVU0IgcmVtb3RlIHdha2V1cA0KWyAgICAyLjExNjY0OF0g
dWhjaV9oY2QgMDAwMDowMDoxZC4xOiBpcnEgMTksIGlvIGJhc2UgMHgwMDAwYjA4MA0KWyAg
ICAyLjExNjczMF0gdXNiIHVzYjc6IGRlZmF1bHQgbGFuZ3VhZ2UgMHgwNDA5DQpbICAgIDIu
MTE2NzQyXSB1c2IgdXNiNzogdWRldiAxLCBidXNudW0gNywgbWlub3IgPSA3NjgNClsgICAg
Mi4xMTY3NDRdIHVzYiB1c2I3OiBOZXcgVVNCIGRldmljZSBmb3VuZCwgaWRWZW5kb3I9MWQ2
YiwgaWRQcm9kdWN0PTAwMDENClsgICAgMi4xMTY3NDZdIHVzYiB1c2I3OiBOZXcgVVNCIGRl
dmljZSBzdHJpbmdzOiBNZnI9MywgUHJvZHVjdD0yLCBTZXJpYWxOdW1iZXI9MQ0KWyAgICAy
LjExNjc0N10gdXNiIHVzYjc6IFByb2R1Y3Q6IFVIQ0kgSG9zdCBDb250cm9sbGVyDQpbICAg
IDIuMTE2NzQ5XSB1c2IgdXNiNzogTWFudWZhY3R1cmVyOiBMaW51eCAzLjYuMC1yYzQtMjAx
MjA4MzArIHVoY2lfaGNkDQpbICAgIDIuMTE2NzUwXSB1c2IgdXNiNzogU2VyaWFsTnVtYmVy
OiAwMDAwOjAwOjFkLjENClsgICAgMi4xMTY5NjFdIHVzYiB1c2I3OiB1c2JfcHJvYmVfZGV2
aWNlDQpbICAgIDIuMTE2OTY0XSB1c2IgdXNiNzogY29uZmlndXJhdGlvbiAjMSBjaG9zZW4g
ZnJvbSAxIGNob2ljZQ0KWyAgICAyLjExNjk3OF0gdXNiIHVzYjc6IGFkZGluZyA3LTA6MS4w
IChjb25maWcgIzEsIGludGVyZmFjZSAwKQ0KWyAgICAyLjExNzEyNl0gaHViIDctMDoxLjA6
IHVzYl9wcm9iZV9pbnRlcmZhY2UNClsgICAgMi4xMTcxMjhdIGh1YiA3LTA6MS4wOiB1c2Jf
cHJvYmVfaW50ZXJmYWNlIC0gZ290IGlkDQpbICAgIDIuMTE3MTMxXSBodWIgNy0wOjEuMDog
VVNCIGh1YiBmb3VuZA0KWyAgICAyLjExNzE1MF0gaHViIDctMDoxLjA6IDIgcG9ydHMgZGV0
ZWN0ZWQNClsgICAgMi4xMTcxNTJdIGh1YiA3LTA6MS4wOiBzdGFuZGFsb25lIGh1Yg0KWyAg
ICAyLjExNzE1M10gaHViIDctMDoxLjA6IG5vIHBvd2VyIHN3aXRjaGluZyAodXNiIDEuMCkN
ClsgICAgMi4xMTcxNTVdIGh1YiA3LTA6MS4wOiBpbmRpdmlkdWFsIHBvcnQgb3Zlci1jdXJy
ZW50IHByb3RlY3Rpb24NClsgICAgMi4xMTcxNTddIGh1YiA3LTA6MS4wOiBwb3dlciBvbiB0
byBwb3dlciBnb29kIHRpbWU6IDJtcw0KWyAgICAyLjExNzE2OV0gaHViIDctMDoxLjA6IGxv
Y2FsIHBvd2VyIHNvdXJjZSBpcyBnb29kDQpbICAgIDIuMTE3MTcyXSBodWIgNy0wOjEuMDog
dHJ5aW5nIHRvIGVuYWJsZSBwb3J0IHBvd2VyIG9uIG5vbi1zd2l0Y2hhYmxlIGh1Yg0KWyAg
ICAyLjExNzI3Ml0gZWhjaV9oY2QgMDAwMDowMDoxZC43OiBIUyBjb21wYW5pb24gZm9yIDAw
MDA6MDA6MWQuMQ0KWyAgICAyLjExNzMwMV0geGVuOiByZWdpc3RlcmluZyBnc2kgMTggdHJp
Z2dlcmluZyAwIHBvbGFyaXR5IDENClsgICAgMi4xMTczMDNdIEFscmVhZHkgc2V0dXAgdGhl
IEdTSSA6MTgNClsgICAgMi4xMTczMTVdIHVoY2lfaGNkIDAwMDA6MDA6MWQuMjogc2V0dGlu
ZyBsYXRlbmN5IHRpbWVyIHRvIDY0DQpbICAgIDIuMTE3MzE5XSB1aGNpX2hjZCAwMDAwOjAw
OjFkLjI6IFVIQ0kgSG9zdCBDb250cm9sbGVyDQpbICAgIDIuMTE3NDYwXSB1aGNpX2hjZCAw
MDAwOjAwOjFkLjI6IG5ldyBVU0IgYnVzIHJlZ2lzdGVyZWQsIGFzc2lnbmVkIGJ1cyBudW1i
ZXIgOA0KWyAgICAyLjExNzQ3MF0gdWhjaV9oY2QgMDAwMDowMDoxZC4yOiBkZXRlY3RlZCAy
IHBvcnRzDQpbICAgIDIuMTE3NDc3XSB1aGNpX2hjZCAwMDAwOjAwOjFkLjI6IHVoY2lfY2hl
Y2tfYW5kX3Jlc2V0X2hjOiBjbWQgPSAweDAwMDANClsgICAgMi4xMTc0NzhdIHVoY2lfaGNk
IDAwMDA6MDA6MWQuMjogUGVyZm9ybWluZyBmdWxsIHJlc2V0DQpbICAgIDIuMTE3NDk4XSB1
aGNpX2hjZCAwMDAwOjAwOjFkLjI6IHN1cHBvcnRzIFVTQiByZW1vdGUgd2FrZXVwDQpbICAg
IDIuMTE3NTA0XSB1aGNpX2hjZCAwMDAwOjAwOjFkLjI6IGlycSAxOCwgaW8gYmFzZSAweDAw
MDBiNDAwDQpbICAgIDIuMTE3NTcyXSB1c2IgdXNiODogZGVmYXVsdCBsYW5ndWFnZSAweDA0
MDkNClsgICAgMi4xMTc1ODRdIHVzYiB1c2I4OiB1ZGV2IDEsIGJ1c251bSA4LCBtaW5vciA9
IDg5Ng0KWyAgICAyLjExNzU4Nl0gdXNiIHVzYjg6IE5ldyBVU0IgZGV2aWNlIGZvdW5kLCBp
ZFZlbmRvcj0xZDZiLCBpZFByb2R1Y3Q9MDAwMQ0KWyAgICAyLjExNzU4OF0gdXNiIHVzYjg6
IE5ldyBVU0IgZGV2aWNlIHN0cmluZ3M6IE1mcj0zLCBQcm9kdWN0PTIsIFNlcmlhbE51bWJl
cj0xDQpbICAgIDIuMTE3NTg5XSB1c2IgdXNiODogUHJvZHVjdDogVUhDSSBIb3N0IENvbnRy
b2xsZXINClsgICAgMi4xMTc1OTFdIHVzYiB1c2I4OiBNYW51ZmFjdHVyZXI6IExpbnV4IDMu
Ni4wLXJjNC0yMDEyMDgzMCsgdWhjaV9oY2QNClsgICAgMi4xMTc1OTJdIHVzYiB1c2I4OiBT
ZXJpYWxOdW1iZXI6IDAwMDA6MDA6MWQuMg0KWyAgICAyLjExNzc1M10gdXNiIHVzYjg6IHVz
Yl9wcm9iZV9kZXZpY2UNClsgICAgMi4xMTc3NTVdIHVzYiB1c2I4OiBjb25maWd1cmF0aW9u
ICMxIGNob3NlbiBmcm9tIDEgY2hvaWNlDQpbICAgIDIuMTE3NzY1XSB1c2IgdXNiODogYWRk
aW5nIDgtMDoxLjAgKGNvbmZpZyAjMSwgaW50ZXJmYWNlIDApDQpbICAgIDIuMTE3ODk5XSBo
dWIgOC0wOjEuMDogdXNiX3Byb2JlX2ludGVyZmFjZQ0KWyAgICAyLjExNzkwMV0gaHViIDgt
MDoxLjA6IHVzYl9wcm9iZV9pbnRlcmZhY2UgLSBnb3QgaWQNClsgICAgMi4xMTc5MDNdIGh1
YiA4LTA6MS4wOiBVU0IgaHViIGZvdW5kDQpbICAgIDIuMTE3OTEwXSBodWIgOC0wOjEuMDog
MiBwb3J0cyBkZXRlY3RlZA0KWyAgICAyLjExNzkxMl0gaHViIDgtMDoxLjA6IHN0YW5kYWxv
bmUgaHViDQpbICAgIDIuMTE3OTEzXSBodWIgOC0wOjEuMDogbm8gcG93ZXIgc3dpdGNoaW5n
ICh1c2IgMS4wKQ0KWyAgICAyLjExNzkxNF0gaHViIDgtMDoxLjA6IGluZGl2aWR1YWwgcG9y
dCBvdmVyLWN1cnJlbnQgcHJvdGVjdGlvbg0KWyAgICAyLjExNzkxNV0gaHViIDgtMDoxLjA6
IHBvd2VyIG9uIHRvIHBvd2VyIGdvb2QgdGltZTogMm1zDQpbICAgIDIuMTE3OTI0XSBodWIg
OC0wOjEuMDogbG9jYWwgcG93ZXIgc291cmNlIGlzIGdvb2QNClsgICAgMi4xMTc5MjZdIGh1
YiA4LTA6MS4wOiB0cnlpbmcgdG8gZW5hYmxlIHBvcnQgcG93ZXIgb24gbm9uLXN3aXRjaGFi
bGUgaHViDQpbICAgIDIuMTE4MDI0XSBlaGNpX2hjZCAwMDAwOjAwOjFkLjc6IEhTIGNvbXBh
bmlvbiBmb3IgMDAwMDowMDoxZC4yDQpbICAgIDIuMTE4MjI5XSB1c2Jjb3JlOiByZWdpc3Rl
cmVkIG5ldyBpbnRlcmZhY2UgZHJpdmVyIHVzYmxwDQpbICAgIDIuMTE4MjMwXSBJbml0aWFs
aXppbmcgVVNCIE1hc3MgU3RvcmFnZSBkcml2ZXIuLi4NClsgICAgMi4xMTgzMzldIHVzYmNv
cmU6IHJlZ2lzdGVyZWQgbmV3IGludGVyZmFjZSBkcml2ZXIgdXNiLXN0b3JhZ2UNClsgICAg
Mi4xMTgzNDBdIFVTQiBNYXNzIFN0b3JhZ2Ugc3VwcG9ydCByZWdpc3RlcmVkLg0KWyAgICAy
LjExODU1N10gdXNiY29yZTogcmVnaXN0ZXJlZCBuZXcgaW50ZXJmYWNlIGRyaXZlciBsaWJ1
c3VhbA0KWyAgICAyLjExODc0N10gdXNiY29yZTogcmVnaXN0ZXJlZCBuZXcgaW50ZXJmYWNl
IGRyaXZlciB1c2JzZXJpYWwNClsgICAgMi4xMTg3NDhdIHVzYnNlcmlhbDogVVNCIFNlcmlh
bCBEcml2ZXIgY29yZQ0KWyAgICAyLjExODgzNV0gdXNiY29yZTogcmVnaXN0ZXJlZCBuZXcg
aW50ZXJmYWNlIGRyaXZlciBjcDIxMHgNClsgICAgMi4xMTg5ODVdIFVTQiBTZXJpYWwgc3Vw
cG9ydCByZWdpc3RlcmVkIGZvciBjcDIxMHgNClsgICAgMi4xMTkwODddIHVzYmNvcmU6IHJl
Z2lzdGVyZWQgbmV3IGludGVyZmFjZSBkcml2ZXIgY3lwcmVzc19tOA0KWyAgICAyLjExOTE2
N10gVVNCIFNlcmlhbCBzdXBwb3J0IHJlZ2lzdGVyZWQgZm9yIERlTG9ybWUgRWFydGhtYXRl
IFVTQg0KWyAgICAyLjExOTI1NV0gVVNCIFNlcmlhbCBzdXBwb3J0IHJlZ2lzdGVyZWQgZm9y
IEhJRC0+Q09NIFJTMjMyIEFkYXB0ZXINClsgICAgMi4xMTkzMzhdIFVTQiBTZXJpYWwgc3Vw
cG9ydCByZWdpc3RlcmVkIGZvciBOb2tpYSBDQS00MiBWMiBBZGFwdGVyDQpbICAgIDIuMTE5
NDMyXSB1c2Jjb3JlOiByZWdpc3RlcmVkIG5ldyBpbnRlcmZhY2UgZHJpdmVyIG1vczc3MjAN
ClsgICAgMi4xMTk1MTJdIFVTQiBTZXJpYWwgc3VwcG9ydCByZWdpc3RlcmVkIGZvciBNb3Nj
aGlwIDIgcG9ydCBhZGFwdGVyDQpbICAgIDIuMTE5NjA4XSB1c2Jjb3JlOiByZWdpc3RlcmVk
IG5ldyBpbnRlcmZhY2UgZHJpdmVyIG1vczc4NDANClsgICAgMi4xMTk2OTJdIFVTQiBTZXJp
YWwgc3VwcG9ydCByZWdpc3RlcmVkIGZvciBNb3NjaGlwIDc4NDAvNzgyMCBVU0IgU2VyaWFs
IERyaXZlcg0KWyAgICAyLjExOTkxNF0gaTgwNDI6IFBOUDogUFMvMiBDb250cm9sbGVyIFtQ
TlAwMzAzOlBTMkssUE5QMGYwMzpQUzJNXSBhdCAweDYwLDB4NjQgaXJxIDEsMTINClsgICAg
Mi4xMjMzNDFdIHNlcmlvOiBpODA0MiBLQkQgcG9ydCBhdCAweDYwLDB4NjQgaXJxIDENClsg
ICAgMi4xMjM2MDZdIHNlcmlvOiBpODA0MiBBVVggcG9ydCBhdCAweDYwLDB4NjQgaXJxIDEy
DQpbICAgIDIuMTIzODk1XSBtb3VzZWRldjogUFMvMiBtb3VzZSBkZXZpY2UgY29tbW9uIGZv
ciBhbGwgbWljZQ0KWyAgICAyLjEyNDUzOF0gcnRjX2Ntb3MgMDA6MDM6IFJUQyBjYW4gd2Fr
ZSBmcm9tIFM0DQpbICAgIDIuMTI1MDMzXSBydGNfY21vcyAwMDowMzogcnRjIGNvcmU6IHJl
Z2lzdGVyZWQgcnRjX2Ntb3MgYXMgcnRjMA0KWyAgICAyLjEyNTA5Ml0gcnRjMDogYWxhcm1z
IHVwIHRvIG9uZSBtb250aCwgeTNrLCAxMTQgYnl0ZXMgbnZyYW0NClsgICAgMi4xMjUyNzFd
IHhlbjogcmVnaXN0ZXJpbmcgZ3NpIDE4IHRyaWdnZXJpbmcgMCBwb2xhcml0eSAxDQpbICAg
IDIuMTI1Mjc1XSBBbHJlYWR5IHNldHVwIHRoZSBHU0kgOjE4DQpbICAgIDIuMTI1Mjg0XSBB
Q1BJIFdhcm5pbmc6IDB4MDAwMDAwMDAwMDAwMDQwMC0weDAwMDAwMDAwMDAwMDA0MWYgU3lz
dGVtSU8gY29uZmxpY3RzIHdpdGggUmVnaW9uIFxTTVJHIDEgKDIwMTIwNzExL3V0YWRkcmVz
cy0yNTEpDQpbICAgIDIuMTI1Mjg2XSBBQ1BJOiBJZiBhbiBBQ1BJIGRyaXZlciBpcyBhdmFp
bGFibGUgZm9yIHRoaXMgZGV2aWNlLCB5b3Ugc2hvdWxkIHVzZSBpdCBpbnN0ZWFkIG9mIHRo
ZSBuYXRpdmUgZHJpdmVyDQpbICAgIDIuMTI1Njg3XSBsaXJjX2RldjogSVIgUmVtb3RlIENv
bnRyb2wgZHJpdmVyIHJlZ2lzdGVyZWQsIG1ham9yIDI1MCANClsgICAgMi4xMjU3MDhdIElS
IE5FQyBwcm90b2NvbCBoYW5kbGVyIGluaXRpYWxpemVkDQpbICAgIDIuMTI1NzEwXSBJUiBS
QzUoeCkgcHJvdG9jb2wgaGFuZGxlciBpbml0aWFsaXplZA0KWyAgICAyLjEyNTcxMV0gSVIg
UkM2IHByb3RvY29sIGhhbmRsZXIgaW5pdGlhbGl6ZWQNClsgICAgMi4xMjU3MTJdIElSIEpW
QyBwcm90b2NvbCBoYW5kbGVyIGluaXRpYWxpemVkDQpbICAgIDIuMTI1NzEzXSBJUiBTb255
IHByb3RvY29sIGhhbmRsZXIgaW5pdGlhbGl6ZWQNClsgICAgMi4xMjU3MTVdIElSIFJDNSAo
c3RyZWFtemFwKSBwcm90b2NvbCBoYW5kbGVyIGluaXRpYWxpemVkDQpbICAgIDIuMTI1NzE2
XSBJUiBTQU5ZTyBwcm90b2NvbCBoYW5kbGVyIGluaXRpYWxpemVkDQpbICAgIDIuMTI1NzE3
XSBJUiBNQ0UgS2V5Ym9hcmQvbW91c2UgcHJvdG9jb2wgaGFuZGxlciBpbml0aWFsaXplZA0K
WyAgICAyLjEyNTcxOF0gSVIgTElSQyBicmlkZ2UgaGFuZGxlciBpbml0aWFsaXplZA0KWyAg
ICAyLjEyNzM1Nl0gY3g4OC8wOiBjeDIzODh4IHY0bDIgZHJpdmVyIHZlcnNpb24gMC4wLjkg
bG9hZGVkDQpbICAgIDIuMTI3NjM2XSB1c2Jjb3JlOiByZWdpc3RlcmVkIG5ldyBpbnRlcmZh
Y2UgZHJpdmVyIGVtMjh4eA0KWyAgICAyLjEyNzc2OV0gdXNiY29yZTogcmVnaXN0ZXJlZCBu
ZXcgaW50ZXJmYWNlIGRyaXZlciBjeDIzMXh4DQpbICAgIDIuMTI3NzczXSBjeDI1ODIxOiBk
cml2ZXIgdmVyc2lvbiAwLjAuMTA2IGxvYWRlZA0KWyAgICAyLjEyODIwNF0gdXNiY29yZTog
cmVnaXN0ZXJlZCBuZXcgaW50ZXJmYWNlIGRyaXZlciBwdnJ1c2IyDQpbICAgIDIuMTI4MjA1
XSBwdnJ1c2IyOiBWNEwgaW4tdHJlZSB2ZXJzaW9uOkhhdXBwYXVnZSBXaW5UVi1QVlItVVNC
MiBNUEVHMiBFbmNvZGVyL1R1bmVyDQpbICAgIDIuMTI4MjA2XSBwdnJ1c2IyOiBEZWJ1ZyBt
YXNrIGlzIDMxICgweDFmKQ0KWyAgICAyLjEyODMzNl0gdXNiY29yZTogcmVnaXN0ZXJlZCBu
ZXcgaW50ZXJmYWNlIGRyaXZlciBQaGlsaXBzIHdlYmNhbQ0KWyAgICAyLjEyODMzN10gaXZ0
djogU3RhcnQgaW5pdGlhbGl6YXRpb24sIHZlcnNpb24gMS40LjMNClsgICAgMi4xMjg0NjVd
IGl2dHY6IEVuZCBpbml0aWFsaXphdGlvbg0KWyAgICAyLjEyODQ2N10gaXZ0dmZiOiAgbm8g
Y2FyZHMgZm91bmQNClsgICAgMi4xMjg3NTZdIHZpdmktMDAwOiBWNEwyIGRldmljZSByZWdp
c3RlcmVkIGFzIHZpZGVvMA0KWyAgICAyLjEyODc1N10gVmlkZW8gVGVjaG5vbG9neSBNYWdh
emluZSBWaXJ0dWFsIFZpZGVvIENhcHR1cmUgQm9hcmQgdmVyIDAuOC4xIHN1Y2Nlc3NmdWxs
eSBsb2FkZWQuDQpbICAgIDIuMTI4NzU4XSBjeDIzODg1IGRyaXZlciB2ZXJzaW9uIDAuMC4z
IGxvYWRlZA0KWyAgICAyLjEyOTA0Nl0gdXNiY29yZTogcmVnaXN0ZXJlZCBuZXcgaW50ZXJm
YWNlIGRyaXZlciB1dmN2aWRlbw0KWyAgICAyLjEyOTA0N10gVVNCIFZpZGVvIENsYXNzIGRy
aXZlciAoMS4xLjEpDQpbICAgIDIuMTI5OTAxXSBzcDUxMDBfdGNvOiBTUDUxMDAgVENPIFdh
dGNoRG9nIFRpbWVyIERyaXZlciB2MC4wMQ0KWyAgICAyLjEzMDIzOF0geGVuX3dkdDogWGVu
IFdhdGNoRG9nIFRpbWVyIERyaXZlciB2MC4wMQ0KWyAgICAyLjEzMDcxOF0geGVuX3dkdDog
aW5pdGlhbGl6ZWQgKHRpbWVvdXQ9NjBzLCBub3dheW91dD0wKQ0KWyAgICAyLjEzMTM3M10g
ZGV2aWNlLW1hcHBlcjogaW9jdGw6IDQuMjMuMC1pb2N0bCAoMjAxMi0wNy0yNSkgaW5pdGlh
bGlzZWQ6IGRtLWRldmVsQHJlZGhhdC5jb20NClsgICAgMi4xMzU1MTZdIHVzYmNvcmU6IHJl
Z2lzdGVyZWQgbmV3IGludGVyZmFjZSBkcml2ZXIgdXNiaGlkDQpbICAgIDIuMTM1NTE3XSB1
c2JoaWQ6IFVTQiBISUQgY29yZSBkcml2ZXINClsgICAgMi4xMzk4NTVdIHhlbjogcmVnaXN0
ZXJpbmcgZ3NpIDIyIHRyaWdnZXJpbmcgMCBwb2xhcml0eSAxDQpbICAgIDIuMTM5ODU5XSBB
bHJlYWR5IHNldHVwIHRoZSBHU0kgOjIyDQpbICAgIDIuMTQ3NTAzXSBpbnB1dDogQVQgVHJh
bnNsYXRlZCBTZXQgMiBrZXlib2FyZCBhcyAvZGV2aWNlcy9wbGF0Zm9ybS9pODA0Mi9zZXJp
bzAvaW5wdXQvaW5wdXQyDQpbICAgIDIuMTg0NjM2XSB4ZW46IHJlZ2lzdGVyaW5nIGdzaSAx
NyB0cmlnZ2VyaW5nIDAgcG9sYXJpdHkgMQ0KWyAgICAyLjE4NDYzOV0gQWxyZWFkeSBzZXR1
cCB0aGUgR1NJIDoxNw0KWyAgICAyLjE5ODY0Nl0gdXNiY29yZTogcmVnaXN0ZXJlZCBuZXcg
aW50ZXJmYWNlIGRyaXZlciBzbmQtdXNiLWF1ZGlvDQpbICAgIDIuMTk4NzY1XSB1c2Jjb3Jl
OiByZWdpc3RlcmVkIG5ldyBpbnRlcmZhY2UgZHJpdmVyIHNuZC11YTEwMQ0KWyAgICAyLjE5
ODg4NF0gdXNiY29yZTogcmVnaXN0ZXJlZCBuZXcgaW50ZXJmYWNlIGRyaXZlciBzbmQtdXNi
LXVzeDJ5DQpbICAgIDIuMTk5MDIxXSB1c2Jjb3JlOiByZWdpc3RlcmVkIG5ldyBpbnRlcmZh
Y2UgZHJpdmVyIHNuZC11c2ItY2FpYXENClsgICAgMi4xOTkxNDRdIHVzYmNvcmU6IHJlZ2lz
dGVyZWQgbmV3IGludGVyZmFjZSBkcml2ZXIgc25kLXVzYi02ZmlyZQ0KWyAgICAyLjE5OTE3
OF0gTmV0ZmlsdGVyIG1lc3NhZ2VzIHZpYSBORVRMSU5LIHYwLjMwLg0KWyAgICAyLjE5OTE4
NV0gbmZubF9hY2N0OiByZWdpc3RlcmluZyB3aXRoIG5mbmV0bGluay4NClsgICAgMi4xOTky
MzhdIG5mX2Nvbm50cmFjayB2ZXJzaW9uIDAuNS4wICg3MzA5IGJ1Y1sgICAgNy40MDQ3Njdd
IHVkZXZbMTgwNV06IHN0YXJ0aW5nIHZlcnNpb24gMTY0DQpbICAgIDkuNzY3ODkzXSBBZGRp
bmcgMzIyOTAyOGsgc3dhcCBvbiAvZGV2L3NkYTUuICBQcmlvcml0eTotMSBleHRlbnRzOjEg
YWNyb3NzOjMyMjkwMjhrIA0KWyAgIDEwLjA2OTg1M10gRVhUMy1mcyAoc2RhMSk6IHVzaW5n
IGludGVybmFsIGpvdXJuYWwNClsgICAxMy40ODQyODFdIGUxMDAwZTogZXRoMSBOSUMgTGlu
ayBpcyBVcCAxMDAgTWJwcyBGdWxsIER1cGxleCwgRmxvdyBDb250cm9sOiBSeC9UeA0KWyAg
IDEzLjUwNTk3M10gZTEwMDBlIDAwMDA6MDA6MTkuMDogZXRoMTogMTAvMTAwIHNwZWVkOiBk
aXNhYmxpbmcgVFNPDQpbICAgMTYuMjY5MzYzXSBzc2hkICgyNzA1KTogL3Byb2MvMjcwNS9v
b21fYWRqIGlzIGRlcHJlY2F0ZWQsIHBsZWFzZSB1c2UgL3Byb2MvMjcwNS9vb21fc2NvcmVf
YWRqIGluc3RlYWQuDQpbICAxMzMuNzU5OTM1XSBkZXZpY2UgdmlmMS4wIGVudGVyZWQgcHJv
bWlzY3VvdXMgbW9kZQ0KbWFwcGluZyBrZXJuZWwgaW50byBwaHlzaWNhbCBtZW1vcnkNCmFi
b3V0IHRvIGdldCBzdGFydGVkLi4uDQpbICAxMzQuMjgzODEwXSB4ZW5fYnJpZGdlOiBwb3J0
IDEodmlmMS4wKSBlbnRlcmVkIGZvcndhcmRpbmcgc3RhdGUNClsgIDEzNC4yOTQ1NzddIHhl
bl9icmlkZ2U6IHBvcnQgMSh2aWYxLjApIGVudGVyZWQgZm9yd2FyZGluZyBzdGF0ZQ0KWyAg
MTM0LjcwODcxNV0gMzk4M2MgaXMgMjQyMmIwMDAhDQpbICAxMzQuNzE4OTc5XSAzNmQxYSBp
cyAyNDM0MTAwMCENClsgIDEzNC43NzA5MThdIDM3NDE3IGlzIDI0MzJiMDAwIQ0KWyAgMTM0
LjgwNjEwNl0gMzc2YjUgaXMgMjQxY2YwMDAhDQpbICAxMzQuODMxNDc2XSAzN2I2OSBpcyAy
NDFkNzAwMCENClsgIDEzNC44NDA3NzBdIDM3N2VjIGlzIDI0MWY5MDAwIQ0KWyAgMTM0Ljg1
MDAwN10gMzZmMTcgaXMgMjQxZDYwMDAhDQpbICAxMzQuODU4NzA1XSAzOGNhYyBpcyAyNDFj
YjAwMCENClsgIDEzNC44ODA2OTVdIDM3YjgzIGlzIDI0Mjk4MDAwIQ0KWyAgMTM0LjkxNjc3
Nl0gMzc4NzcgaXMgMjQyNTEwMDAhDQpbICAxMzQuOTI0NTUxXSAzNjQzZCBpcyAyNDFkMTAw
MCENClsgIDEzNC45MzI1OTZdIDM3ODkwIGlzIDI0MjlkMDAwIQ0KWyAgMTM0Ljk0MDEzNF0g
MzkzYzcgaXMgMjQyMGEwMDAhDQpbICAxMzQuOTQ3OTc4XSAzNzY5MiBpcyAyNDI4NjAwMCEN
ClsgIDEzNC45NTUzNThdIDM2ZWE2IGlzIDI0MWE5MDAwIQ0KWyAgMTM0Ljk2MjkyOV0gMzY1
NDEgaXMgMjQxYTcwMDAhDQpbICAxMzQuOTgxNTU4XSAzN2VlZCBpcyAyNDFhNjAwMCENClsg
IDEzNC45OTUzNDZdIDM5MTljIGlzIDI0MWE4MDAwIQ0KWyAgMTM1LjAwMjIyNl0gMzZmY2Mg
aXMgMjQzMzcwMDAhDQpbICAxMzUuMDA4MzMxXSAzNzUwZSBpcyAyNDIxMzAwMCENClsgIDEz
NS4wMTUxNzhdIDM3NDE2IGlzIDI0MjZkMDAwIQ0KWyAgMTM1LjAzMTU0MF0gMzZkNjAgaXMg
MjQyM2IwMDAhDQpbICAxMzUuMDM4MDY3XSAzNzg5MSBpcyAyNDIyZTAwMCENClsgIDEzNS4w
NDI0MjNdIDM4NDg1IGlzIDI0MmVjMDAwIQ0KWyAgMTM1LjA0NzA0MV0gMzZlMTIgaXMgMjQy
MmQwMDAhDQpbICAxMzUuMDUyNTAyXSAzN2VlYyBpcyAyNDIyMDAwMCENClsgIDEzNS4wNjA0
MzNdIDM3NTU0IGlzIDI0MmNiMDAwIQ0KWyAgMTM1LjA2NjE0M10gMzkzODkgaXMgMjQyZTMw
MDAhDQpbICAxMzUuMDcwNjU4XSAzOGNiMCBpcyAyNDJkNjAwMCENClsgIDEzNS4xNDI5NzNd
IDM3ZDIxIGlzIDI0MWE2MDAwIQ0KWyAgMTM1LjE0NTYzOF0gMzZlNTYgaXMgMjQyZTMwMDAh
DQpbICAxMzUuMTQ4MzM4XSAzN2ZjNCBpcyAyNDFhNzAwMCENClsgIDEzNS4xNTA3NzNdIDM3
ODZjIGlzIDI0MjUxMDAwIQ0KWyAgMTM1LjE1MzgyMV0gMzdiMzEgaXMgMjQyNjkwMDAhDQpb
ICAxMzUuMTU2MjUxXSAzODM4YSBpcyAyNDJlZTAwMCENClsgIDEzNS4xNTg2ODBdIDM3YmMw
IGlzIDI0MWRjMDAwIQ0KWyAgMTM1LjE2MTA5OF0gMzdmZGYgaXMgMjQyNTIwMDAhDQpbICAx
MzUuMTY1NjYyXSAzN2Q4MyBpcyA3YTIwZjAwMCENClsgIDEzNS4xNjg1MDddIDM5MzdhIGlz
IDdhMjBmMDAwIQ0KWyAgMTM1LjE3MTMxMV0gMzZmMzEgaXMgN2EyNDEwMDAhDQpbICAxMzUu
MTc0MDk1XSAzOTBmNiBpcyA3YTIwNzAwMCENClsgIDEzNS4xODY0OTJdIDM5ODI4IGlzIDdh
MGQ0MDAwIQ0KWyAgMTM1LjIyNjQyOF0gMzZlNzEgaXMgNzk0MmUwMDAhDQpbICAxMzUuMjM3
NTkxXSAzN2I4MSBpcyA3YTIzMDAwMCENClsgIDEzNS4yNTI4NDldIDM4MzhiIGlzIDdhMjQ2
MDAwIQ0KWyAgMTM1LjI1OTI4Ml0gMzhjYWQgaXMgN2EyMTEwMDAhDQpbICAxMzUuMjY1MjYx
XSAzOGQxMCBpcyA3YTI0MDAwMCENClsgIDEzNS4yODEzOTZdIDM4MzM2IGlzIDdhMWYxMDAw
IQ0KWyAgMTM1LjI4NDI1Ml0gMzY1OTYgaXMgNzhlYWYwMDAhDQpbICAxMzUuMzA1NzA1XSAz
NzVjYyBpcyA3YTFkMDAwMCENClsgIDEzNS4zMDgyMjJdIDM2NTk3IGlzIDdhMWNlMDAwIQ0K
WyAgMTM1LjMxMDY0OV0gMzY0YzQgaXMgN2ExZDEwMDAhDQpbICAxMzUuMzEzMDYxXSAzNjRj
NSBpcyA3YTI0OTAwMCENClsgIDEzNS4zMjI3NjVdIDM3NTJiIGlzIDdhMjA2MDAwIQ0KWyAg
MTM1LjMzNjY2NV0gMzhkMTggaXMgN2ExZmUwMDAhDQpbICAxMzUuMzQ3MjIyXSAzOGQxOSBp
cyA3YTIwZTAwMCENClsgIDEzNS4zNTAyMDldIDM3NTJhIGlzIDdhMWNmMDAwIQ0KWyAgMTM1
LjM1Mjk4OF0gMzdhMWUgaXMgN2EyMTAwMDAhDQpbICAxMzUuMzY3NjQyXSAzN2E5OCBpcyA3
YTFmMDAwMCENClsgIDEzNS4zODMwNDFdIDM3YTk5IGlzIDIxOTE1MDAwIQ0KWyAgMTM1LjM4
NTQ4M10gMzdmMTAgaXMgN2E3NzgwMDAhDQpbICAxMzUuMzg3ODkzXSAzODI5MiBpcyAyMWQ5
MTAwMCENClsgIDEzNS4zOTAyODldIDM3NzhhIGlzIDIxOWY1MDAwIQ0KWyAgMTM1LjM5MzMz
MF0gMzc1ZTggaXMgMjFkYTkwMDAhDQpbICAxMzUuMzk1NzY1XSAzOTNjNiBpcyA3YTIwNDAw
MCENClsgIDEzNS4zOTgxOThdIDM2ZTcwIGlzIDdhMjQ0MDAwIQ0KWyAgMTM1LjQwMDY0Ml0g
MzhjYmQgaXMgN2ExY2MwMDAhDQpbICAxMzUuNDAzMDYxXSAzN2JjMSBpcyA3YTFlMTAwMCEN
ClsgIDEzNS40MDU1MDldIDM3ZTZjIGlzIDdhMWZmMDAwIQ0KWyAgMTM1LjQwODMzMV0gMzdm
MjIgaXMgN2ExZmQwMDAhDQpbICAxMzUuNDExNjc3XSAzN2ZjNSBpcyA3OGVhZTAwMCENClsg
IDEzNS40MTQxMTBdIDM5MjQ2IGlzIDc4ZDVjMDAwIQ0KWyAgMTM1LjQxNjUzMl0gMzkzZWQg
aXMgNzk0MzEwMDAhDQpbICAxMzUuNDE4OTU4XSAzODI5MSBpcyAyMTkyNzAwMCENClsgIDEz
NS40MjE0NDJdIDM2ZmNkIGlzIDc5NDJmMDAwIQ0KWyAgMTM1LjQyMzg4NF0gMzkxNDggaXMg
NzhlN2QwMDAhDQpbICAxMzUuNDI2MzM0XSAzNmU5YSBpcyAyMWRiYzAwMCENClsgIDEzNS40
Mjg4MThdIDM2NTU3IGlzIDdhMGQ1MDAwIQ0KWyAgMTM1LjQzMTMwMV0gMzZkZjggaXMgN2Ey
MzEwMDAhDQpbICAxMzUuNDMzNzk5XSAzNmRmNSBpcyAyMTkwNjAwMCENClsgIDEzNS40MzYy
NjJdIDM5ODI5IGlzIDdhMjU1MDAwIQ0KWyAgMTM1LjQzODg2Nl0gMzdlYzAgaXMgNzhlYmMw
MDAhDQpbICAxMzUuNDQxNDIwXSAzNjQ2MSBpcyA3OTJkNDAwMCENClsgIDEzNS40NDM5NDRd
IDM3ZTZkIGlzIDdhMjQ3MDAwIQ0KWyAgMTM1LjQ0NjQ5NF0gMzgzMDggaXMgN2EwZWEwMDAh
DQpbICAxMzUuNDQ5MDI3XSAzN2UyNSBpcyAyMWQ5ODAwMCENClsgIDEzNS40NTE1ODVdIDM5
MzIyIGlzIDdhMGNlMDAwIQ0KWyAgMTM1LjQ1NDE3MV0gMzdjMjQgaXMgN2ExY2QwMDAhDQpb
ICAxMzUuNDU3NDY3XSAzOTFmYyBpcyAyMWRlMzAwMCENClsgIDEzNS40NjAwODNdIDM3NWU5
IGlzIDIxZGZkMDAwIQ0KWyAgMTM1LjQ2MjY2N10gMzc3NWMgaXMgNzk0M2MwMDAhDQpbICAx
MzUuNDY1MjczXSAzNzc1ZCBpcyA3YTI0NTAwMCENClsgIDEzNS40Njc4NzNdIDM2ZDZjIGlz
IDdhMjRlMDAwIQ0KWyAgMTM1LjQ3MDQ0M10gMzZkNmQgaXMgNzk0MzMwMDAhDQpbICAxMzUu
NDcyOTU5XSAzNmNjMCBpcyA3OTQ0NjAwMCENClsgIDEzNS40NzU1MDhdIDM2Y2MxIGlzIDdh
MWUzMDAwIQ0KWyAgMTM1LjQ4NDMyNV0gMzZkYzQgaXMgMjFkZmYwMDAhDQpbICAxMzUuNDk3
NzEwXSAzOTExMCBpcyAyMWUwMDAwMCENClsgIDEzNS41MDA2NzldIDM2ZGM1IGlzIDIxOTk0
MDAwIQ0KWyAgMTM1LjUyMDM2NV0gMzdlNWQgaXMgN2EyNDgwMDAhDQpbICAxMzUuNTY0ODM1
XSAzNzk2NCBpcyA3YTFkMzAwMCENClsgIDEzNS41Njc0NzddIDM3OTY1IGlzIDdhMjBjMDAw
IQ0KWyAgMTM1LjU3MDAyOF0gMzhjNmMgaXMgN2EyMGQwMDAhDQpbICAxMzUuNTcyNTc4XSAz
OGM2ZCBpcyA3OGQ0ZjAwMCENClsgIDEzNS41NzUxMjFdIDM4ZDZjIGlzIDdhMWZjMDAwIQ0K
WyAgMTM1LjU3NzYzMV0gMzhkNmQgaXMgN2E1ZjIwMDAhDQpbICAxMzUuNTgwMTE1XSAzNzVj
NCBpcyA3OTQ0NDAwMCENClsgIDEzNS41ODI5NjNdIDM3NWM1IGlzIDc5NDJjMDAwIQ0KWyAg
MTM1LjYwMzk3M10gMzc1NjYgaXMgNzhkNGQwMDAhDQpbICAxMzUuNjA2Mzk1XSAzNzVjZCBp
cyA3YTIxMjAwMCENClsgIDEzNS42MDg4NTBdIDM3YmZkIGlzIDdhMjEzMDAwIQ0KWyAgMTM1
LjYxMTI2NV0gMzZmZmMgaXMgN2ExZDIwMDAhDQpbICAxMzUuNjE0MDY3XSAzODMyOCBpcyAy
MTkyNjAwMCENClsgIDEzNS42MjYxMjddIDM2ZmZkIGlzIDdhMjMyMDAwIQ0KWyAgMTM1LjYy
ODcwN10gMzZmZmUgaXMgN2EyMzMwMDAhDQpbICAxMzUuNjMxMDg3XSAzNmZmZiBpcyA3OGVi
ZTAwMCENClsgIDEzNS42MzM0NzRdIDM3YTljIGlzIDc4ZWJmMDAwIQ0KWyAgMTM1LjYzNTgw
MV0gMzdhOWQgaXMgNzkyZDYwMDAhDQpbICAxMzUuNjM4MTQwXSAzN2E5ZSBpcyA3OTJkNzAw
MCENClsgIDEzNS42NDA0NDZdIDM3YTlmIGlzIDdhMjRhMDAwIQ0KWyAgMTM1LjY0MjcyMF0g
MzY0OGMgaXMgN2EyNGIwMDAhDQpbICAxMzUuNjQ0OTk1XSAzNjQ4ZCBpcyAyMWRhYjAwMCEN
ClsgIDEzNS42NDcyNDVdIDM2NDhlIGlzIDIxZGFjMDAwIQ0KWyAgMTM1LjY0OTQ3Ml0gMzY0
OGYgaXMgNzhkNGMwMDAhDQpbICAxMzUuNjUxNzc2XSAzNmM0YyBpcyAyMWRiOTAwMCENClsg
IDEzNS42NTQwMzZdIDM2YzRkIGlzIDIxZGJhMDAwIQ0KWyAgMTM1LjY1NjIzNV0gMzZjNGUg
aXMgNzk0M2UwMDAhDQpbICAxMzUuNjU4NDY0XSAzNmM0ZiBpcyA3OTQzZjAwMCENClsgIDEz
NS42NjA2NDJdIDM3YmY0IGlzIDIxOTIxMDAwIQ0KWyAgMTM1LjY2MjgzMl0gMzdiZjUgaXMg
MjE5MjIwMDAhDQpbICAxMzUuNjY4MTExXSAzN2JmNiBpcyA3YTBkNjAwMCENClsgIDEzNS42
NzAyOTZdIDM3YmY3IGlzIDdhMGQ3MDAwIQ0KWyAgMTM1LjY3MjM5MF0gMzc4YTAgaXMgNzhl
YmEwMDAhDQpbICAxMzUuNjc0NTMwXSAzNzhhMSBpcyA3OGViYjAwMCENClsgIDEzNS42Nzcw
OTZdIDM3OGEyIGlzIDdhMjA4MDAwIQ0KWyAgMTM1LjY3OTIxMV0gMzc4YTMgaXMgN2EwZTgw
MDAhDQpbICAxMzUuNjgxMjk4XSAzNzhkNCBpcyA3YTBlOTAwMCENClsgIDEzNS42ODQzNDRd
IDM2NDZjIGlzIDIxOTA4MDAwIQ0KWyAgMTM1LjY4NjQzM10gMzY0NmQgaXMgNzhlYWMwMDAh
DQpbICAxMzUuNjg4NTYxXSAzNjQ2ZSBpcyA3OGVhZDAwMCENClsgIDEzNS42OTA2NTFdIDM2
NDZmIGlzIDdhMGNjMDAwIQ0KWyAgMTM1LjY5MjcyMF0gMzc4ZDUgaXMgN2EwY2QwMDAhDQpb
ICAxMzUuNjk0ODEwXSAzNzhkNiBpcyAyMWRlMTAwMCENClsgIDEzNS42OTY4OTZdIDM3OGQ3
IGlzIDIxZGUyMDAwIQ0KWyAgMTM1LjY5ODkyMF0gMzZkYmMgaXMgMjE5MjUwMDAhDQpbICAx
MzUuNzAwOTYzXSAzNmRiZCBpcyA3OTNmNzAwMCENClsgIDEzNS43MDMwMTFdIDM2ZGJlIGlz
IDdhMjU2MDAwIQ0KWyAgMTM1LjcwNTA4OF0gMzZkYmYgaXMgN2EyNTcwMDAhDQpbICAxMzUu
NzA3MTI2XSAzNmZmMCBpcyA3YTI0YzAwMCENClsgIDEzNS43MDkxNjhdIDM2ZmYxIGlzIDdh
MjRkMDAwIQ0KWyAgMTM1LjcxMTIwMV0gMzZmZjIgaXMgN2EwZWMwMDAhDQpbICAxMzUuNzEz
MjQxXSAzNmZmMyBpcyA3YTBlZDAwMCENClsgIDEzNS43MTU2MzldIDM3YWNjIGlzIDdhMjBh
MDAwIQ0KWyAgMTM1LjcxODA3OV0gMzdhY2QgaXMgN2EyMGIwMDAhDQpbICAxMzUuNzIwNjY3
XSAzN2FjZSBpcyAyMTlmODAwMCENClsgIDEzNS43MjI3MDJdIDM3YWNmIGlzIDIxOTE3MDAw
IQ0KWyAgMTM1LjcyNDczNl0gMzZlMzQgaXMgMjE5MTgwMDAhDQpbICAxMzUuNzI2Nzc0XSAz
NmUzNSBpcyAyMTkwNzAwMCENClsgIDEzNS43MjkxNjVdIDM2ZTM2IGlzIDIxOThlMDAwIQ0K
WyAgMTM1Ljc0Njc0NV0gMzZlMzcgaXMgN2EyNDMwMDAhDQpbICAxMzUuNzQ4ODAzXSAzODNl
OCBpcyA3OGU3ZTAwMCENClsgIDEzNS43NTA4NzhdIDM4M2U5IGlzIDc4ZTdmMDAwIQ0KWyAg
MTM1Ljc1Mjg4MV0gMzgzZWEgaXMgMjE5ZjcwMDAhDQpbICAxMzUuNzU1MTgwXSAzNzkwOCBp
cyA3YTBkMjAwMCENClsgIDEzNS43NTcyNjFdIDM3OTA5IGlzIDdhMGQzMDAwIQ0KWyAgMTM1
Ljc1OTI5NV0gMzdhODggaXMgN2EyMDAwMDAhDQpbICAxMzUuNzYxMzQ4XSAzN2E4OSBpcyA3
YTIwMTAwMCENClsgIDEzNS43NjM0MTNdIDM4MzI5IGlzIDdhMjAyMDAwIQ0KWyAgMTM1Ljc2
NTQ1Ml0gMzZmZjggaXMgN2EyMDMwMDAhDQpbICAxMzUuNzY3NDk2XSAzNmZmOSBpcyA3YTFl
ZTAwMCENClsgIDEzNS43Njk0OTFdIDM3ZjdjIGlzIDdhMWVmMDAwIQ0KWyAgMTM1Ljc3MTUx
N10gMzdmN2QgaXMgN2ExZGMwMDAhDQpbICAxMzUuNzczNTIzXSAzNmZmNCBpcyA3YTFkZDAw
MCENClsgIDEzNS43NzU1MTRdIDM2ZmY1IGlzIDdhMWRlMDAwIQ0KWyAgMTM1Ljc3NzQ4M10g
MzZkYWMgaXMgN2ExZGYwMDAhDQpbICAxMzUuNzc5NDcwXSAzNmRhZCBpcyA3YTFmMjAwMCEN
ClsgIDEzNS43ODE0MjhdIDM2Y2VjIGlzIDdhMWYzMDAwIQ0KWyAgMTM1Ljc4MzM2N10gMzZj
ZWQgaXMgN2EyNDIwMDAhDQpbICAxMzUuNzg2MzU4XSAzNjRmMSBpcyAyMTkxOTAwMCENClsg
IDEzNS43ODg1MzZdIDM3NjYwIGlzIDIxOTFhMDAwIQ0KWyAgMTM1Ljc5MDU0Nl0gMzc2NjEg
aXMgMjE5MWIwMDAhDQpbICAxMzUuNzkyNTA3XSAzNmU3OCBpcyAyMTkxYzAwMCENClsgIDEz
NS43OTQ0NzZdIDM2ZTc5IGlzIDdhNzc0MDAwIQ0KWyAgMTM1Ljc5NjQ4MV0gMzc5NzggaXMg
N2E3NzUwMDAhDQpbICAxMzUuNzk4NDY4XSAzNzk3OSBpcyA3YTc3NjAwMCENClsgIDEzNS44
MDA0ODBdIDM3YjRhIGlzIDdhNzc3MDAwIQ0KWyAgMTM1LjgwMjQzNF0gMzdiNGIgaXMgMjE5
OGQwMDAhDQpbICAxMzUuODA0NDI5XSAzN2IxOCBpcyAyMTk5MDAwMCENClsgIDEzNS44MDYz
OTBdIDM3YjE5IGlzIDc5M2Y4MDAwIQ0KWyAgMTM1LjgwODQwOV0gMzdiMWEgaXMgNzkzZjkw
MDAhDQpbICAxMzUuODEwNDA5XSAzN2IxYiBpcyA3OTNmYTAwMCENClsgIDEzNS44MTIzNThd
IDM2NGY4IGlzIDc5M2ZiMDAwIQ0KWyAgMTM1LjgxNDQzNl0gMzY0ZjkgaXMgN2EyMmMwMDAh
DQpbICAxMzUuODE2Mzk3XSAzNjRmYSBpcyA3YTIyZDAwMCENClsgIDEzNS44MTgzMzBdIDM2
NGZiIGlzIDdhMjJlMDAwIQ0KWyAgMTM1LjgyMDIzN10gMzZjNTQgaXMgN2EyMmYwMDAhDQpb
ICAxMzUuODIyMTIzXSAzNmM1NSBpcyAyMTk2NTAwMCENClsgIDEzNS44MjQwNDNdIDM2YzU2
IGlzIDIxOTY2MDAwIQ0KWyAgMTM1LjgyNTkyM10gMzZjNTcgaXMgMjE5NjcwMDAhDQpbICAx
MzUuODI3ODAyXSAzNmYyOCBpcyAyMTk2ODAwMCENClsgIDEzNS44Mjk2ODJdIDM2ZjI5IGlz
IDc4ZWI0MDAwIQ0KWyAgMTM1LjgzMTU3MF0gMzZmMmEgaXMgNzhlYjUwMDAhDQpbICAxMzUu
ODMzNDc5XSAzNmYyYiBpcyA3OGViNjAwMCENClsgIDEzNS44MzUzNDJdIDM5MzdjIGlzIDc4
ZWI3MDAwIQ0KWyAgMTM1LjgzNzI0OF0gMzkzN2QgaXMgN2EyM2MwMDAhDQpbICAxMzUuODM5
MTM5XSAzOTM3ZSBpcyA3YTIzZDAwMCENClsgIDEzNS44NDEwNTBdIDM5MzdmIGlzIDdhMjNl
MDAwIQ0KWyAgMTM1Ljg0MjkzNV0gMzc3NTggaXMgN2EyM2YwMDAhDQpbICAxMzUuODQ0OTAy
XSAzNzc1OSBpcyA3YTBkMDAwMCENClsgIDEzNS44NDY4MDVdIDM3NzVhIGlzIDdhMGQxMDAw
IQ0KWyAgMTM1Ljg1MzM4OV0gMzc3NWIgaXMgMjFkOGQwMDAhDQpbICAxMzUuODU1MjYzXSAz
ODNlYiBpcyAyMWQ4ZTAwMCENClsgIDEzNS44NTcxNzhdIDM3OGMwIGlzIDIxZDhmMDAwIQ0K
WyAgMTM1Ljg1OTA2NF0gMzc4YzEgaXMgMjFkOTAwMDAhDQpbICAxMzUuODYxNTIxXSAzNzhj
MiBpcyAyMWRhNzAwMCENClsgIDEzNS44NjM0NTNdIDM3OGMzIGlzIDIxZGE4MDAwIQ0KWyAg
MTM1Ljg2NTMzNF0gMzZjYzQgaXMgN2E1ZWMwMDAhDQpbICAxMzUuODY3MjY3XSAzNmNjNSBp
cyA3YTVlZDAwMCENClsgIDEzNS44NjkxNDldIDM2Y2M2IGlzIDdhNWVlMDAwIQ0KWyAgMTM1
Ljg3MTA1NV0gMzZjYzcgaXMgN2E1ZWYwMDAhDQpbICAxMzUuODczODAwXSAzN2I0OCBpcyAy
MWRhNjAwMCENClsgIDEzNS44ODMyODRdIDM3OTJmIGlzIDc4ZWIwMDAwIQ0KWyAgMTM1Ljg4
NTM5N10gMzdiMjAgaXMgNzhlYjEwMDAhDQpbICAxMzUuODg3MzY5XSAzN2IyMSBpcyA3OGVi
MjAwMCENClsgIDEzNS44ODkyODddIDM3YjIyIGlzIDc4ZWIzMDAwIQ0KWyAgMTM1Ljg5MTIz
NF0gMzdiMjMgaXMgMjFkOTkwMDAhDQpbICAxMzUuODkzMTcyXSAzNzc0YyBpcyAyMWQ5YTAw
MCENClsgIDEzNS44OTUxNDRdIDM3NzRkIGlzIDIxZDliMDAwIQ0KWyAgMTM1Ljg5NzA3NV0g
Mzc3NGUgaXMgMjFkOWMwMDAhDQpbICAxMzUuODk5MDA3XSAzNzc0ZiBpcyA3OGVjMDAwMCEN
ClsgIDEzNS45MDA5NjJdIDM2NGQ4IGlzIDc4ZWMxMDAwIQ0KWyAgMTM1LjkwMjkzMV0gMzY0
ZDkgaXMgNzhlYzIwMDAhDQpbICAxMzUuOTA1MzMxXSAzNjRkYSBpcyA3OGQ1MjAwMCENClsg
IDEzNS45MDczMThdIDM2NGRiIGlzIDc4ZDUzMDAwIQ0KWyAgMTM1LjkwOTI2N10gMzc1Yzgg
aXMgMjFkYjUwMDAhDQpbICAxMzUuOTExMjUwXSAzNzVjOSBpcyAyMWRiNjAwMCENClsgIDEz
NS45MTMxODddIDM3NWNhIGlzIDIxZGI3MDAwIQ0KWyAgMTM1LjkxNTE0NF0gMzc1Y2IgaXMg
MjFkYjgwMDAhDQpbICAxMzUuOTE3MTA3XSAzNzVhYyBpcyA3YTBkODAwMCENClsgIDEzNS45
MTkwMzRdIDM3NWFkIGlzIDdhMGQ5MDAwIQ0KWyAgMTM1LjkyMDk5MF0gMzc1YWUgaXMgN2Ew
ZGEwMDAhDQpbICAxMzUuOTIyOTIzXSAzNzVhZiBpcyA3YTBkYjAwMCENClsgIDEzNS45MjQ4
NTVdIDM3OWI0IGlzIDc4ZTgzMDAwIQ0KWyAgMTM1LjkyNjc4OF0gMzZkNzQgaXMgMjE5Mjkw
MDAhDQpbICAxMzUuOTI4NzcxXSAzNmQ3NSBpcyAyMTkyYTAwMCENClsgIDEzNS45MzA2OTVd
IDM2ZDc2IGlzIDIxOTJiMDAwIQ0KWyAgMTM1LjkzMjYxNF0gMzZkNzcgaXMgMjE5MmMwMDAh
DQpbICAxMzUuOTM0NTI1XSAzN2YzNCBpcyAyMTlmOTAwMCENClsgIDEzNS45MzY0MjZdIDM2
Y2ViIGlzIDIxOWZhMDAwIQ0KWyAgMTM1LjkzODMzN10gMzdlNzQgaXMgMjE5ZmIwMDAhDQpb
ICAxMzUuOTQwMjgyXSAzNzkyZSBpcyAyMTlmYzAwMCENClsgIDEzNS45NDIyMDhdIDM3OTJk
IGlzIDIxOTFkMDAwIQ0KWyAgMTM1Ljk0NDEwN10gMzc5MmMgaXMgMjE5MWUwMDAhDQpbICAx
MzUuOTQ1OTY5XSAzN2U3NSBpcyAyMTkwOTAwMCENClsgIDEzNS45NDc4MzldIDM3ZTc2IGlz
IDIxOTBhMDAwIQ0KWyAgMTM1Ljk0OTcxNF0gMzdlNzcgaXMgMjE5MGIwMDAhDQpbICAxMzUu
OTUxNTg1XSAzN2ZiOCBpcyAyMTkwYzAwMCENClsgIDEzNS45NTM0NjddIDM3ZmI5IGlzIDc5
MmQ4MDAwIQ0KWyAgMTM1Ljk1NTMyOF0gMzdmYmEgaXMgNzkyZDkwMDAhDQpbICAxMzUuOTU3
MjI1XSAzN2ZiYiBpcyA3OTJkYTAwMCENClsgIDEzNS45NTkwODhdIDM3OTYwIGlzIDc5MmRi
MDAwIQ0KWyAgMTM1Ljk2MDk1OV0gMzc5NjEgaXMgNzhlODAwMDAhDQpbICAxMzUuOTYyODI2
XSAzNzk2MiBpcyA3OGU4MTAwMCENClsgIDEzNS45NjQ2OThdIDM3OTYzIGlzIDc4ZTgyMDAw
IQ0KWyAgMTM1Ljk2NjU3N10gMzZjM2QgaXMgMjFlMDMwMDAhDQpbICAxMzUuOTY4NDk0XSAz
NmMzZSBpcyAyMWUwNDAwMCENClsgIDEzNS45NzAzOTVdIDM2YzNmIGlzIDdhMDQxMDAwIQ0K
WyAgMTM1Ljk3MjI4Nl0gMzgyOTggaXMgN2EwNDIwMDAhDQpbICAxMzUuOTc0MjI2XSAzODI5
OSBpcyA3YTA0MzAwMCENClsgIDEzNS45NzYxMjhdIDM4MjlhIGlzIDIxZTAxMDAwIQ0KWyAg
MTM1Ljk3ODA2MV0gMzgyOWIgaXMgMjFlMDIwMDAhDQpbICAxMzUuOTc5OTY1XSAzNzkwZiBp
cyAyMTkxZjAwMCENClsgIDEzNS45ODE5MTRdIDM3OTBlIGlzIDIxOTIwMDAwIQ0KWyAgMTM1
Ljk4Mzg2MF0gMzc5MGQgaXMgMjFkZGQwMDAhDQpbICAxMzUuOTg1Nzc0XSAzNzkwYyBpcyAy
MWRkZTAwMCENClsgIDEzNS45ODc2ODRdIDM3ZjM3IGlzIDIxZGRmMDAwIQ0KWyAgMTM1Ljk4
OTU3N10gMzdmMzYgaXMgMjFkZTAwMDAhDQpbICAxMzUuOTkxNDk5XSAzN2YzNSBpcyA3OGQ1
MDAwMCENClsgIDEzNS45OTM0MjhdIDM3YjQ5IGlzIDc4ZDUxMDAwIQ0KWyAgMTM2LjAwNzE4
OF0gMzZkYTkgaXMgN2ExZGEwMDAhDQpbICAxMzYuMDA5MTk0XSAzNmRhYSBpcyA3YTFkYjAw
MCENClsgIDEzNi4wMTEyMzVdIDM2ZGFiIGlzIDdhMDQwMDAwIQ0KWyAgMTM2LjAxMzQ2NF0g
MzdiMTcgaXMgN2ExZjQwMDAhDQpbICAxMzYuMDE1NDE5XSAzNzZiYyBpcyA3YTFmNTAwMCEN
ClsgIDEzNi4wMTczODVdIDM3NmJkIGlzIDdhMWY2MDAwIQ0KWyAgMTM2LjAxOTMzMF0gMzc2
YmUgaXMgN2ExZjcwMDAhDQpbICAxMzYuMDIxMjc4XSAzNzZiZiBpcyA3YTFmODAwMCENClsg
IDEzNi4wMjMyMTNdIDM3NjQ0IGlzIDdhMWY5MDAwIQ0KWyAgMTM2LjAyNTE2NV0gMzc2NDUg
aXMgN2ExZmEwMDAhDQpbICAxMzYuMDI3MDc4XSAzNzY0NiBpcyA3YTFmYjAwMCENClsgIDEz
Ni4wMjg5OTBdIDM3NjQ3IGlzIDdhMWU0MDAwIQ0KWyAgMTM2LjAzMDkxNl0gMzdjNmMgaXMg
N2ExZTUwMDAhDQpbICAxMzYuMDMyODM4XSAzN2M2ZCBpcyA3YTFlNjAwMCENClsgIDEzNi4w
MzQ3MzddIDM3YzZlIGlzIDdhMjM0MDAwIQ0KWyAgMTM2LjAzNjY0MV0gMzdjNmYgaXMgN2Ey
MzUwMDAhDQpbICAxMzYuMDM4NTQ4XSAzOGQ0YyBpcyA3YTIzNjAwMCENClsgIDEzNi4wNDA0
NDhdIDM4ZDRkIGlzIDdhMjM3MDAwIQ0KWyAgMTM2LjA0MjMwN10gMzhkNGUgaXMgN2EyMzgw
MDAhDQpbICAxMzYuMDQ0MTYyXSAzOGQ0ZiBpcyA3YTIzYTAwMCENClsgIDEzNi4wNDU5OThd
IDM2ZDdjIGlzIDdhMjNiMDAwIQ0KWyAgMTM2LjA0Nzg1OV0gMzdlZjQgaXMgN2ExZTcwMDAh
DQpbICAxMzYuMDQ5NzM2XSAzN2VmNSBpcyA3YTFlODAwMCENClsgIDEzNi4wNTE2MDNdIDM3
ZWY2IGlzIDdhMWU5MDAwIQ0KWyAgMTM2LjA1MzQ2OF0gMzdlZjcgaXMgN2ExZWEwMDAhDQpb
ICAxMzYuMDU1Mjk2XSAzN2QwYyBpcyA3YTFlYjAwMCENClsgIDEzNi4wNTcxNTRdIDM3ZDBk
IGlzIDdhMWQ0MDAwIQ0KWyAgMTM2LjA1ODk4OF0gMzdkMGUgaXMgN2ExZDUwMDAhDQpbICAx
MzYuMDYwODMxXSAzN2QwZiBpcyA3YTFkNjAwMCENClsgIDEzNi4wNjI2NzZdIDM3YjE0IGlz
IDdhMWQ3MDAwIQ0KWyAgMTM2LjA2NDUxMl0gMzdiMTUgaXMgN2ExZDgwMDAhDQpbICAxMzYu
MDY2MzQ1XSAzN2IxNiBpcyA3YTFkOTAwMCENClsgIDEzNi4wNzM2MThdIDM5M2E4IGlzIDc4
ZDVhMDAwIQ0KWyAgMTM2LjA3NTUzN10gMzkzYTkgaXMgNzhkNWIwMDAhDQpbICAxMzYuMDc3
Mzg0XSAzOTNhYSBpcyA3OGVjNDAwMCENClsgIDEzNi4wNzkyMDFdIDM2ZDdkIGlzIDc4ZDU3
MDAwIQ0KWyAgMTM2LjA4MTA1N10gMzZkN2UgaXMgNzhkNTgwMDAhDQpbICAxMzYuMDgyOTAx
XSAzNmQ3ZiBpcyA3OGQ1OTAwMCENClsgIDEzNi4wOTM2NzVdIDM5MjgwIGlzIDdhNzZmMDAw
IQ0KWyAgMTM2LjA5NTY1Nl0gMzc0ZmYgaXMgN2E3NzAwMDAhDQpbICAxMzYuMDk3NTY4XSAz
NzRmZSBpcyA3YTc3MTAwMCENClsgIDEzNi4wOTk0NjNdIDM3NGZkIGlzIDdhNzcyMDAwIQ0K
WyAgMTM2LjEwMTM1OV0gMzc0ZmMgaXMgN2E3NzMwMDAhDQpbICAxMzYuMTAzMjUyXSAzOTNj
MyBpcyA3YTBkYzAwMCENClsgIDEzNi4xMDUxNjBdIDM5M2MyIGlzIDdhMGRkMDAwIQ0KWyAg
MTM2LjEwNzA4NV0gMzkzYzEgaXMgN2EwZGUwMDAhDQpbICAxMzYuMTA4OTcxXSAzOTNjMCBp
cyA3YTBkZjAwMCENClsgIDEzNi4xMTA4ODhdIDM5M2FiIGlzIDdhMGUwMDAwIQ0KWyAgMTM2
LjExMjk3M10gMzkzODIgaXMgN2EwZTEwMDAhDQpbICAxMzYuMTE0OTExXSAzNzliNSBpcyA3
YTBlMjAwMCENClsgIDEzNi4xMTY4NjBdIDM3OWI2IGlzIDdhMGUzMDAwIQ0KWyAgMTM2LjEx
ODc3Ml0gMzc5YjcgaXMgMjFkOWQwMDAhDQpbICAxMzYuMTIwNzM0XSAzNmNiYyBpcyAyMWQ5
ZTAwMCENClsgIDEzNi4xMjI2NDBdIDM2Y2JkIGlzIDIxZDlmMDAwIQ0KWyAgMTM2LjEyNDU4
M10gMzkzODEgaXMgMjFkYTAwMDAhDQpbICAxMzYuMTI2NTA2XSAzOTM4MCBpcyAyMWRhMTAw
MCENClsgIDEzNi4xMjg0NThdIDM5MjgzIGlzIDIxZGEyMDAwIQ0KWyAgMTM2LjEzMDM5NF0g
MzkyODIgaXMgMjFkYTMwMDAhDQpbICAxMzYuMTMyMzIyXSAzOTI4MSBpcyAyMWRhNDAwMCEN
ClsgIDEzNi4xMzQyNDddIDM2Y2JlIGlzIDc5NmZjMDAwIQ0KWyAgMTM2LjEzNjIwM10gMzZj
YmYgaXMgNzk2ZmQwMDAhDQpbICAxMzYuMTM4MTQ1XSAzN2YxYyBpcyA3OTZmZTAwMCENClsg
IDEzNi4xNDAxMjFdIDM3ZjFkIGlzIDc5NmZmMDAwIQ0KWyAgMTM2LjE0MjA2Ml0gMzdmMWUg
aXMgNzk3MDAwMDAhDQpbICAxMzYuMTQzOTkzXSAzN2YxZiBpcyA3OTcwMTAwMCENClsgIDEz
Ni4xNDU5MjJdIDM3ODk0IGlzIDc5NzAyMDAwIQ0KWyAgMTM2LjE0Nzg0Nl0gMzc4OTUgaXMg
Nzk3MDMwMDAhDQpbICAxMzYuMTQ5NzQ1XSAzNzg5NiBpcyA3OGQ1NDAwMCENClsgIDEzNi4x
NTE2NDFdIDM3ODk3IGlzIDc4ZDU1MDAwIQ0KWyAgMTM2LjE1MzU1Ml0gMzc2ZjAgaXMgNzhk
NTYwMDAhDQpbICAxMzYuMTU5NzcxXSAzNzZmMSBpcyAyMTkxMDAwMCENClsgIDEzNi4xNjE3
ODNdIDM5MzgzIGlzIDIxOTExMDAwIQ0KWyAgMTM2LjE2MzcwMl0gMzZlOTAgaXMgMjE5MTIw
MDAhDQpbICAxMzYuMTY1NjIyXSAzNmU5MSBpcyAyMTkxMzAwMCENClsgIDEzNi4xNjc1MjJd
IDM2ZTkyIGlzIDIxOTE0MDAwIQ0KWyAgMTM2LjE2OTQwMV0gMzZlOTMgaXMgNzkzMGMwMDAh
DQpbICAxMzYuMTcxMjg1XSAzNmQ1NCBpcyA3OTMwZDAwMCENClsgIDEzNi4xNzMxNjhdIDM2
ZDU1IGlzIDc5MzBlMDAwIQ0KWyAgMTM2LjE3NTA4NV0gMzZkNTYgaXMgNzkzMGYwMDAhDQpb
ICAxMzYuMTc2OTY5XSAzNmQ1NyBpcyA3OTMxMDAwMCENClsgIDEzNi4xNzkwNTBdIDM3YWY0
IGlzIDc5MzExMDAwIQ0KWyAgMTM2LjE4MDk1Ml0gMzdhZjUgaXMgNzkzMTIwMDAhDQpbICAx
MzYuMTgyODM5XSAzN2FmNiBpcyA3OTMxMzAwMCENClsgIDEzNi4xODQ3MDhdIDM3YWY3IGlz
IDc5MmNjMDAwIQ0KWyAgMTM2LjE4NjU3Ml0gMzZmMjAgaXMgNzkyY2QwMDAhDQpbICAxMzYu
MTg4NDU2XSAzNmYyMSBpcyA3OTJjZTAwMCENClsgIDEzNi4xOTAzMzhdIDM2ZjIyIGlzIDc5
MmNmMDAwIQ0KWyAgMTM2LjE5MjE5MV0gMzZmMjMgaXMgNzkyZDAwMDAhDQpbICAxMzYuMTk0
MDc4XSAzNzg2OCBpcyA3OTJkMTAwMCENClsgIDEzNi4xOTU5NDRdIDM3ODY5IGlzIDc5MmQy
MDAwIQ0KWyAgMTM2LjE5NzgzNF0gMzc4NmEgaXMgNzkyZDMwMDAhDQpbICAxMzYuMTk5Njc2
XSAzNzg2YiBpcyAyMWRmNTAwMCENClsgIDEzNi4yMDE1NTFdIDM2ZDY4IGlzIDIxZGY2MDAw
IQ0KWyAgMTM2LjIwMzQ0N10gMzZkNjkgaXMgMjFkZjcwMDAhDQpbICAxMzYuMjA1MzA3XSAz
NmQ2YSBpcyAyMWRmODAwMCENClsgIDEzNi4yMDcxODRdIDM2ZDZiIGlzIDIxZGY5MDAwIQ0K
WyAgMTM2LjIwOTAzM10gMzc2MjggaXMgMjFkZmEwMDAhDQpbICAxMzYuMjEwOTE0XSAzNzYy
OSBpcyAyMWRmYjAwMCENClsgIDEzNi4yMTI3NzBdIDM3NjJhIGlzIDIxZGZjMDAwIQ0KWyAg
MTM2LjIxNDYzMF0gMzc2MmIgaXMgN2E3NmMwMDAhDQpbICAxMzYuMjE2NTAzXSAzN2ViMCBp
cyA3YTc2ZDAwMCENClsgIDEzNi4yMTgzNzRdIDM3ZWIxIGlzIDdhNzZlMDAwIQ0KWyAgMTM2
LjIyMzQ4N10gMzdlYjIgaXMgNzhlOGEwMDAhDQpbICAxMzYuMjI1NDA4XSAzN2ViMyBpcyA3
OGU4YjAwMCENClsgIDEzNi4yMjcyNzJdIDM5MTE0IGlzIDIxOTJkMDAwIQ0KWyAgMTM2LjIy
OTE3NF0gMzkxMTUgaXMgMjE5MmUwMDAhDQpbICAxMzYuMjMxMDgzXSAzOTExNiBpcyAyMTky
ZjAwMCENClsgIDEzNi4yMzI5NjldIDM5MTE3IGlzIDIxOTMwMDAwIQ0KWyAgMTM2LjIzNDg0
NF0gMzZkZDAgaXMgMjE5MzEwMDAhDQpbICAxMzYuMjM2NzU1XSAzNmRkMSBpcyAyMTkzMjAw
MCENClsgIDEzNi4yMzg2MjldIDM2ZGQyIGlzIDIxOTMzMDAwIQ0KWyAgMTM2LjI0MTA5NV0g
MzZjN2UgaXMgMjFkYmQwMDAhDQpbICAxMzYuMjQyOTcyXSAzNmM3ZCBpcyAyMWRiZTAwMCEN
ClsgIDEzNi4yNDQ4ODZdIDM2YzdjIGlzIDIxZGJmMDAwIQ0KWyAgMTM2LjI0Njc3OV0gMzZk
ZDMgaXMgMjFkYzAwMDAhDQpbICAxMzYuMjQ4OTE4XSAzNjU1MiBpcyAyMWRjNDAwMCENClsg
IDEzNi4yNTA4MjhdIDM3NmYyIGlzIDIxZDg1MDAwIQ0KWyAgMTM2LjI1MjczNF0gMzc2ZjMg
aXMgMjFkOGEwMDAhDQpbICAxMzYuMjU0NjkzXSAzNzQxMCBpcyAyMWQ4YjAwMCENClsgIDEz
Ni4yNTY1OTddIDM3NDExIGlzIDIxZDhjMDAwIQ0KWyAgMTM2LjI1ODQ4M10gMzc0MTIgaXMg
NzhlODQwMDAhDQpbICAxMzYuMjYwMzg3XSAzNzQxMyBpcyA3OGU4NTAwMCENClsgIDEzNi4y
NjIyOTJdIDM2NTUxIGlzIDc4ZTg2MDAwIQ0KWyAgMTM2LjI2NDE5M10gMzY1NTAgaXMgNzhl
ODcwMDAhDQpbICAxMzYuMjY2MDYzXSAzNjUyZiBpcyA3OGU4ODAwMCENClsgIDEzNi4yNjc5
NzNdIDM2NTJlIGlzIDc4ZTg5MDAwIQ0KWyAgMTM2LjI2OTg1MV0gMzY1MmQgaXMgMjFkYzEw
MDAhDQpbICAxMzYuMjcxNzM5XSAzNjUyYyBpcyAyMWRjMjAwMCENClsgIDEzNi4yNzM2MzNd
IDM2YzdmIGlzIDIxZGMzMDAwIQ0KWyAgMTM2LjI3NjQ2NF0gMzZmY2IgaXMgMjFkZDcwMDAh
DQpbICAxMzYuMjc4NDM4XSAzNmNlOCBpcyAyMWRkODAwMCENClsgIDEzNi4yODAzNTVdIDM2
Y2U5IGlzIDIxZGQ5MDAwIQ0KWyAgMTM2LjI4MjI2Ml0gMzZjZWEgaXMgMjFkZGEwMDAhDQpb
ICAxMzYuMjg0MTU3XSAzNzZkZSBpcyAyMWRkYjAwMCENClsgIDEzNi4yODYwNTddIDM3NmRm
IGlzIDIxZGRjMDAwIQ0KWyAgMTM2LjI4NzkzNl0gMzc1ZjQgaXMgMjE5ODUwMDAhDQpbICAx
MzYuMjg5ODEzXSAzNzVmNSBpcyAyMTk4NjAwMCENClsgIDEzNi4yOTE2ODJdIDM3NWY2IGlz
IDIxOTg3MDAwIQ0KWyAgMTM2LjI5MzU1MV0gMzc1ZjcgaXMgMjE5ODgwMDAhDQpbICAxMzYu
Mjk1NDEwXSAzOGMyOCBpcyAyMTk4OTAwMCENClsgIDEzNi4yOTcyNzJdIDM2ZmM4IGlzIDIx
OThhMDAwIQ0KWyAgMTM2LjI5OTE0Ml0gMzZmYzkgaXMgMjE5OGIwMDAhDQpbICAxMzYuMzAx
MDEyXSAzNmZjYSBpcyAyMTk4YzAwMCENClsgIDEzNi4zMDMwOTVdIDM4YzI5IGlzIDIxYTA0
MDAwIQ0KWyAgMTM2LjMwNDk4MF0gMzhjMmEgaXMgNzk0MzQwMDAhDQpbICAxMzYuMzA2ODg0
XSAzOGMyYiBpcyA3OTQzNTAwMCENClsgIDEzNi4zMDg3MjldIDM5Mjc4IGlzIDc5NDM2MDAw
IQ0KWyAgMTM2LjMxMDYxMF0gMzkyNzkgaXMgNzk0MzcwMDAhDQpbICAxMzYuMzEyNDQ3XSAz
OTI3YSBpcyA3OTQzODAwMCENClsgIDEzNi4zMTQzNTVdIDM5MjdiIGlzIDc5NDM5MDAwIQ0K
WyAgMTM2LjMxNjIxNF0gMzdmZTQgaXMgNzk0M2EwMDAhDQpbICAxMzYuMzE4MDgyXSAzN2Zl
NSBpcyA3OTQzYjAwMCENClsgIDEzNi4zMTk5MzJdIDM3ZmU2IGlzIDIxZGQ1MDAwIQ0KWyAg
MTM2LjMyMTc5OV0gMzdmZTcgaXMgMjFkZDYwMDAhDQpbICAxMzYuMzIzNjcxXSAzNmY1MCBp
cyAyMTlmZDAwMCENClsgIDEzNi4zMjU1MzddIDM2ZjUxIGlzIDIxOWZlMDAwIQ0KWyAgMTM2
LjMyNzQzNF0gMzZmNTIgaXMgMjE5ZmYwMDAhDQpbICAxMzYuMzI5MzA2XSAzNmY1MyBpcyAy
MWEwMDAwMCENClsgIDEzNi4zMzExNzFdIDM2Zjg0IGlzIDIxYTAxMDAwIQ0KWyAgMTM2LjMz
MzA0NV0gMzZmODUgaXMgMjFhMDIwMDAhDQpbICAxMzYuMzM0OTEwXSAzNmY4NiBpcyAyMWEw
MzAwMCENClsgIDEzNi4zNDg3NzddIDM2Zjg3IGlzIDc5NDA3MDAwIQ0KWyAgMTM2LjM1MTA5
N10gMzkyZWMgaXMgNzk0MDkwMDAhDQpbICAxMzYuMzY4NTIyXSAzOTJlZCBpcyA3YTVmODAw
MCENClsgIDEzNi4zNzA0NjNdIDM5MmVlIGlzIDdhNWY5MDAwIQ0KWyAgMTM2LjM3MjM0MF0g
MzkyZWYgaXMgN2E1ZmEwMDAhDQpbICAxMzYuMzc0MjcwXSAzN2JkNCBpcyA3YTVmYjAwMCEN
ClsgIDEzNi4zODA5MzBdIDM2NTUzIGlzIDdhNWY0MDAwIQ0KWyAgMTM2LjM4Mjg1N10gMzdi
ZDUgaXMgN2E1ZjUwMDAhDQpbICAxMzYuMzg0Nzg1XSAzN2JkNiBpcyA3YTVmNjAwMCENClsg
IDEzNi4zODY3MzJdIDM3YmQ3IGlzIDdhNWY3MDAwIQ0KWyAgMTM2LjM5ODE1Ml0gMzhjNjgg
aXMgN2EyMjIwMDAhDQpbICAxMzYuNDAwMjIwXSAzOGM2OSBpcyA3YTIyMTAwMCENClsgIDEz
Ni40MDIxNTJdIDM4YzZhIGlzIDdhMjIwMDAwIQ0KWyAgMTM2LjQwNDA4Nl0gMzhjNmIgaXMg
N2EyMWYwMDAhDQpbICAxMzYuNDA1OTgwXSAzN2U5OCBpcyA3YTIxZTAwMCENClsgIDEzNi40
MDc5MDddIDM3ZTk5IGlzIDdhMjFkMDAwIQ0KWyAgMTM2LjQwOTgwMF0gMzdlOWEgaXMgN2Ey
MWMwMDAhDQpbICAxMzYuNDExNzAxXSAzN2U5YiBpcyAyMWRmNDAwMCENClsgIDEzNi40MTM2
MDNdIDM3ZGZjIGlzIDIxZGYzMDAwIQ0KWyAgMTM2LjQxNTUwOF0gMzdkZmQgaXMgMjFkZjIw
MDAhDQpbICAxMzYuNDE3NDA4XSAzN2RmZSBpcyAyMWRmMTAwMCENClsgIDEzNi40MTk0NzRd
IDM4Mzg0IGlzIDdhMjI2MDAwIQ0KWyAgMTM2LjQyMTQwOV0gMzgzODUgaXMgN2EyMjUwMDAh
DQpbICAxMzYuNDIzMjk3XSAzODM4NiBpcyA3YTIyNDAwMCENClsgIDEzNi40MjUxODBdIDM4
Mzg3IGlzIDdhMjIzMDAwIQ0KWyAgMTM2LjQyNzE1N10gMzdkZmYgaXMgNzkzZmMwMDAhDQpb
ICAxMzYuNDMyMzAwXSAzNzhmNSBpcyA3YTIyYTAwMCENClsgIDEzNi40MzQ2NDldIDM3OGY0
IGlzIDIxZGViMDAwIQ0KWyAgMTM2LjQzNzA0Nl0gMzc4ZjYgaXMgMjFkZWEwMDAhDQpbICAx
MzYuNDQ0NjcxXSAzNzhmNyBpcyA3YTYwOTAwMCENClsgIDEzNi40NDcwODBdIDM2NGY0IGlz
IDdhNjBiMDAwIQ0KWyAgMTM2LjQ0OTA1NF0gMzY0ZjUgaXMgN2E2MGEwMDAhDQpbICAxMzYu
NDUxMzg4XSAzNjRmNiBpcyAyMWRlOTAwMCENClsgIDEzNi40NjE1MzRdIDM2NGY3IGlzIDc5
NmVjMDAwIQ0KWyAgMTM2LjQ3NzkwM10gMzdlNDAgaXMgNzk2ZWQwMDAhDQpbICAxMzYuNDk3
MDU3XSAzN2U0MSBpcyA3OTZlZTAwMCENClsgIDEzNi41MTQyODBdIDM2ZjM0IGlzIDIxZGU3
MDAwIQ0KWyAgMTM2LjUyODc5MV0gMzZmMzUgaXMgMjFkZTUwMDAhDQpbICAxMzYuNTMxMzU4
XSAzN2U0MiBpcyA3OTZmMjAwMCENClsgIDEzNi41MzMzNTldIDM2ZjM2IGlzIDc5NmYxMDAw
IQ0KWyAgMTM2LjUzNTM4OF0gMzZmMzcgaXMgNzk2ZjAwMDAhDQpbICAxMzYuNTM3NDA1XSAz
NmRjMCBpcyA3OTZlZjAwMCENClsgIDEzNi41Mzk3ODddIDM2ZGMxIGlzIDc5NmY5MDAwIQ0K
WyAgMTM2LjU1MTU5Nl0gMzZkYzIgaXMgNzk2ZjMwMDAhDQpbICAxMzYuNTY0ODYzXSAzNmRj
MyBpcyA3OTQwYTAwMCENClsgIDEzNi41Nzk5ODJdIDM3ZTQzIGlzIDdhMjE2MDAwIQ0KWyAg
MTM2LjU5Mjk5NV0gMzZkNjQgaXMgN2EyMjgwMDAhDQpbICAxMzYuNjA3NTU3XSAzNmQ2NSBp
cyAyMWRlZTAwMCENClsgIDEzNi42MTAxMTNdIDM2ZGNjIGlzIDIxZGVkMDAwIQ0KWyAgMTM2
LjYxOTE0MF0gMzZkY2QgaXMgN2EyMTQwMDAhDQpbICAxMzYuNjQyNjM1XSAzNmRjZSBpcyA3
OTNmZjAwMCENClsgIDEzNi42NzM5MzBdIDM2ZGNmIGlzIDc5NmZiMDAwIQ0KWyAgMTM2LjY4
Mzk4OV0gMzY0NGMgaXMgNzk2ZjYwMDAhDQpbICAxMzYuNjg2MTI1XSAzNmQ2NyBpcyA3OTZm
NzAwMCENClsgIDEzNi43MDM1MTZdIDM2NDRkIGlzIDdhNjAwMDAwIQ0KWyAgMTM2LjcxODE0
OV0gMzY0NGUgaXMgNzk2ZjQwMDAhDQpbICAxMzYuNzIxMDgyXSAzNjQ0ZiBpcyA3YTYwNzAw
MCENClsgIDEzNi43MjM3MDFdIDM2ZjVjIGlzIDdhNjA2MDAwIQ0KWyAgMTM2Ljc0NzI5MV0g
Mzc3YTggaXMgN2E2MDQwMDAhDQpbICAxMzYuNzQ5NDQyXSAzNzdhOSBpcyA3YTYwMzAwMCEN
ClsgIDEzNi43NTE2MTddIDM3N2FhIGlzIDdhNjAyMDAwIQ0KWyAgMTM2Ljc1Mzc1Nl0gMzc3
YWIgaXMgN2E2MDEwMDAhDQpbICAxMzYuNzU2MjcwXSAzNmY1ZCBpcyAyMTkzOTAwMCENClsg
IDEzNi43NjYyNzJdIDM2NDM4IGlzIDIxZGYwMDAwIQ0KWyAgMTM2Ljc2ODYwMl0gMzY0Mzkg
aXMgMjE5OTIwMDAhDQpbICAxMzYuNzcwNzQ2XSAzNjQzYSBpcyA3YTFlYzAwMCENClsgIDEz
Ni43NzI4ODldIDM2NDNiIGlzIDdhMGU1MDAwIQ0KWyAgMTM2Ljc3NTA0NF0gMzc5ZTggaXMg
MjFkODgwMDAhDQpbICAxMzYuNzc3MjA2XSAzNzllOSBpcyAyMWQ4NjAwMCENClsgIDEzNi43
NzkzMjVdIDM3OWVhIGlzIDIxZDg3MDAwIQ0KWyAgMTM2Ljc4MTQzM10gMzc5ZWIgaXMgN2Ex
ZWQwMDAhDQpbICAxMzYuNzgzNTUyXSAzN2MzMCBpcyA3OTQwMjAwMCENClsgIDEzNi43ODU2
OTldIDM3YzMxIGlzIDdhMGNmMDAwIQ0KWyAgMTM2Ljc4Nzg0OV0gMzdjMzIgaXMgN2E2MDUw
MDAhDQpbICAxMzYuNzkwMTM1XSAzN2MzMyBpcyA3OTJlOTAwMCENClsgIDEzNi43OTIzMTRd
IDM5MTRjIGlzIDc5MmVhMDAwIQ0KWyAgMTM2Ljc5NDUyMF0gMzkxNGQgaXMgNzkyZWIwMDAh
DQpbICAxMzYuNzk2NjQzXSAzOTE0ZSBpcyA3YTVmYzAwMCENClsgIDEzNi43OTg4MDVdIDM5
MTRmIGlzIDdhNWZkMDAwIQ0KWyAgMTM2LjgwMDkwN10gMzZmNjAgaXMgN2E1ZmUwMDAhDQpb
ICAxMzYuODAzNzIzXSAzNmY2MiBpcyAyMWRjZTAwMCENClsgIDEzNi44MDU4ODldIDM2ZjYx
IGlzIDIxZGNmMDAwIQ0KWyAgMTM2LjgwNzk3MF0gMzZmNWUgaXMgMjFkZDAwMDAhDQpbICAx
MzYuODEwMDg1XSAzNmY1ZiBpcyAyMWRkMTAwMCENClsgIDEzNi44MTIxNTRdIDM2ZjEwIGlz
IDIxZGQyMDAwIQ0KWyAgMTM2LjgxNDMxMF0gMzZmMTEgaXMgMjFkZDMwMDAhDQpbICAxMzYu
ODE2MzUzXSAzNmYxMiBpcyAyMWRkNDAwMCENClsgIDEzNi44MTgzOTRdIDM2ZjEzIGlzIDIx
OTM1MDAwIQ0KWyAgMTM2LjgyMDQwNl0gMzZkZmMgaXMgMjE5MzYwMDAhDQpbICAxMzYuODIy
NDE5XSAzNmRmZCBpcyAyMTkzNzAwMCENClsgIDEzNi44MjQ2MzJdIDM2ZGZlIGlzIDIxOTM4
MDAwIQ0KWyAgMTM2LjgyNjYyOV0gMzZkZmYgaXMgMjE5NDAwMDAhDQpbICAxMzYuODI4NjMy
XSAzNzZkYyBpcyAyMTk0MTAwMCENClsgIDEzNi44MzA2NDddIDM3NmRkIGlzIDIxOTQyMDAw
IQ0KWyAgMTM2LjgzMjU4N10gMzZmNjMgaXMgMjE5NDMwMDAhDQpbICAxMzYuODM0NTQ2XSAz
NjUwOCBpcyAyMTk0NDAwMCENClsgIDEzNi44MzY1MDJdIDM2NTA5IGlzIDc5MmRjMDAwIQ0K
WyAgMTM2LjgzODQ0OV0gMzY1MGEgaXMgNzkyZGQwMDAhDQpbICAxMzYuODQwNDA5XSAzNjUw
YiBpcyA3OTJkZTAwMCENClsgIDEzNi44NDIyODZdIDM4M2FjIGlzIDc5MmRmMDAwIQ0KWyAg
MTM2Ljg0NDIxNl0gMzgzYWQgaXMgNzkyZTAwMDAhDQpbICAxMzYuODQ2MTEyXSAzODNhZSBp
cyA3OTJlMTAwMCENClsgIDEzNi44NDgwMDJdIDM4M2FmIGlzIDc5MmUyMDAwIQ0KWyAgMTM2
Ljg0OTgyN10gMzkxOTggaXMgNzkyZTMwMDAhDQpbICAxMzYuODUxNjc0XSAzOTE5OSBpcyA3
OTJlNDAwMCENClsgIDEzNi44NTM1MDddIDM5MTlhIGlzIDc5MmU1MDAwIQ0KWyAgMTM2Ljg1
NTMwMV0gMzkxOWIgaXMgNzkyZTYwMDAhDQpbICAxMzYuODU3MTAzXSAzOGMyNCBpcyA3OTJl
NzAwMCENClsgIDEzNi44NTg4ODRdIDM4YzI1IGlzIDc5MmU4MDAwIQ0KWyAgMTM2Ljg3MTQy
OF0gMzhjMjYgaXMgMjE5ZWIwMDAhDQpbICAxMzYuODg1NTcwXSAzOGMyNyBpcyAyMWRjYTAw
MCENClsgIDEzNi44ODc0MzBdIDM3ZjRlIGlzIDIxZGNiMDAwIQ0KWyAgMTM2Ljg4OTI0N10g
MzdmNGYgaXMgMjFkY2MwMDAhDQpbICAxMzYuODkxMDUzXSAzNmViYyBpcyAyMWRjZDAwMCEN
ClsgIDEzNi44OTMyNTVdIDM2ZWJkIGlzIDIxOTViMDAwIQ0KWyAgMTM2Ljg5ODY3MF0gMzZl
YmUgaXMgMjE5ZWYwMDAhDQpbICAxMzYuOTAwNjQwXSAzN2RhYyBpcyAyMTlmMDAwMCENClsg
IDEzNi45MDI0NzVdIDM3ZGFkIGlzIDIxOWYxMDAwIQ0KWyAgMTM2LjkwNDMxN10gMzdkYWUg
aXMgMjE5ZjIwMDAhDQpbICAxMzYuOTA2MTQ2XSAzN2RhZiBpcyAyMTlmMzAwMCENClsgIDEz
Ni45MDc5NjZdIDM3OWMwIGlzIDIxOWY0MDAwIQ0KWyAgMTM2LjkwOTc5NV0gMzc5YzEgaXMg
MjFkYzUwMDAhDQpbICAxMzYuOTExNzI4XSAzNzljMiBpcyAyMWRjNjAwMCENClsgIDEzNi45
MTM1NjRdIDM3OWMzIGlzIDIxZGM3MDAwIQ0KWyAgMTM2LjkxNTM4NV0gMzgzZTAgaXMgMjFk
YzgwMDAhDQpbICAxMzYuOTE3MjIzXSAzODNlMSBpcyAyMWRjOTAwMCENClsgIDEzNi45MTkx
NzRdIDM4M2UyIGlzIDIxOWU1MDAwIQ0KWyAgMTM2LjkyMTEwNl0gMzgzZTMgaXMgMjE5ZTYw
MDAhDQpbICAxMzYuOTIyOTM0XSAzN2Y0YyBpcyAyMTllNzAwMCENClsgIDEzNi45MjQ3NzVd
IDM3ZjRkIGlzIDIxOWU4MDAwIQ0KWyAgMTM2LjkyNjYzNF0gMzdlMTkgaXMgMjE5ZTkwMDAh
DQpbICAxMzYuOTI4NDcwXSAzN2UxYSBpcyAyMTllZTAwMCENClsgIDEzNi45MzEyNDZdIDM3
YThkIGlzIDIxOTU1MDAwIQ0KWyAgMTM2LjkzMzExMV0gMzdhOGUgaXMgMjE5NTYwMDAhDQpb
ICAxMzYuOTM1MDExXSAzN2E4ZiBpcyAyMTk1NzAwMCENClsgIDEzNi45MzY4NjRdIDM2NTI0
IGlzIDIxOTU4MDAwIQ0KWyAgMTM2LjkzODcyMV0gMzY1MjUgaXMgMjE5NTkwMDAhDQpbICAx
MzYuOTQwNTgxXSAzNjUyNiBpcyAyMTk1YTAwMCENClsgIDEzNi45NDI0MjhdIDM2NTI3IGlz
IDIxOTVkMDAwIQ0KWyAgMTM2Ljk0NDMwMF0gMzZlMzggaXMgMjE5NWUwMDAhDQpbICAxMzYu
OTQ2MTUwXSAzNmUzOSBpcyAyMTk1ZjAwMCENClsgIDEzNi45NDgwMDJdIDM2ZTNhIGlzIDIx
OTYwMDAwIQ0KWyAgMTM2Ljk0OTgxNl0gMzZlM2IgaXMgMjE5NjEwMDAhDQpbICAxMzYuOTUx
NjQwXSAzNmViZiBpcyAyMTk1MzAwMCENClsgIDEzNi45NTM0NjRdIDM3YThjIGlzIDIxOTU0
MDAwIQ0KWyAgMTM2Ljk1NTQ1OF0gMzZlYjcgaXMgMjE5OWQwMDAhDQpbICAxMzYuOTU3Mjk4
XSAzN2UxOCBpcyAyMTk5ZTAwMCENClsgIDEzNi45NTkxMTVdIDM3ZWU0IGlzIDIxOTlmMDAw
IQ0KWyAgMTM2Ljk2MDk0NV0gMzdlZTUgaXMgMjE5YTAwMDAhDQpbICAxMzYuOTYyNzQ5XSAz
N2VlNiBpcyAyMTlhMTAwMCENClsgIDEzNi45NjQ1NzhdIDM3ZWU3IGlzIDIxOWEyMDAwIQ0K
WyAgMTM2Ljk2NjM3OF0gMzgyYTQgaXMgMjE5YTMwMDAhDQpbICAxMzYuOTY4MjA3XSAzODJh
NSBpcyAyMTlhNDAwMCENClsgIDEzNi45NzAwMDddIDM2ZTE0IGlzIDIxOTYyMDAwIQ0KWyAg
MTM2Ljk3MTgyOV0gMzZlMTUgaXMgMjE5NjMwMDAhDQpbICAxMzYuOTczNjY0XSAzNmUxNiBp
cyAyMTk2NDAwMCENClsgIDEzNi45NzU0NTNdIDM2ZTE3IGlzIDIxOTk1MDAwIQ0KWyAgMTM2
Ljk3NzI3Nl0gMzZlYzggaXMgMjE5OTYwMDAhDQpbICAxMzYuOTc5MTAxXSAzNmVjOSBpcyAy
MTk5NzAwMCENClsgIDEzNi45ODA5MjddIDM2ZWNhIGlzIDIxOTk4MDAwIQ0KWyAgMTM2Ljk4
MjcwM10gMzZlY2IgaXMgMjE5OTkwMDAhDQpbICAxMzYuOTg0NTA2XSAzNmViNCBpcyAyMTk5
YTAwMCENClsgIDEzNi45ODYyNzJdIDM2ZWI1IGlzIDIxOTliMDAwIQ0KWyAgMTM2Ljk4ODA0
OV0gMzZlYjYgaXMgMjE5OWMwMDAhDQpbICAxMzYuOTkxMDAxXSAzODJhNiBpcyAyMTk0ODAw
MCENClsgIDEzNi45OTI3NzhdIDM4MmE3IGlzIDIxOTQ5MDAwIQ0KWyAgMTM2Ljk5NDU2Nl0g
MzY0NzQgaXMgMjE5NGEwMDAhDQpbICAxMzYuOTk2MzM4XSAzNjQ3NSBpcyAyMTk0YjAwMCEN
ClsgIDEzNi45OTgxMzhdIDM2NDc2IGlzIDIxOTRjMDAwIQ0KWyAgMTM2Ljk5OTg5N10gMzY0
NzcgaXMgMjE5NGQwMDAhDQpbICAxMzcuMDAxNjg2XSAzNzdlOCBpcyAyMTk0ZTAwMCENClsg
IDEzNy4wMDM0ODFdIDM3N2U5IGlzIDIxOTRmMDAwIQ0KWyAgMTM3LjAwNTI3OV0gMzc3ZWEg
aXMgMjE5NTAwMDAhDQpbICAxMzcuMDA3MDczXSAzNzdlYiBpcyAyMTk1MTAwMCENClsgIDEz
Ny4wMDg4NThdIDM3NmMwIGlzIDIxOTUyMDAwIQ0KWyAgMTM3LjAxMTA3N10gMzgzOTQgaXMg
N2E1ZDUwMDAhDQpbICAxMzcuMDEyODc5XSAzODM5NSBpcyA3YTVkNjAwMCENClsgIDEzNy4w
MTQ2OTFdIDM4Mzk2IGlzIDdhNWQ3MDAwIQ0KWyAgMTM3LjAxNjQ2MV0gMzgzOTcgaXMgN2E1
ZDgwMDAhDQpbICAxMzcuMDE4MjUwXSAzNjQyNCBpcyA3YTVkOTAwMCENClsgIDEzNy4wMjAw
MjBdIDM2NDI1IGlzIDdhNWRhMDAwIQ0KWyAgMTM3LjAyMTgwOV0gMzY0MjYgaXMgN2E1ZGIw
MDAhDQpbICAxMzcuMDIzNjE1XSAzNjQyNyBpcyA3YTVkYzAwMCENClsgIDEzNy4wMjUzODdd
IDM3NzM4IGlzIDdhNWRkMDAwIQ0KWyAgMTM3LjAyNzIwM10gMzc3MzkgaXMgN2E1ZGUwMDAh
DQpbICAxMzcuMDI4OTc0XSAzNzczYSBpcyA3OTQyYjAwMCENClsgIDEzNy4wMzA3OTFdIDM3
NzNiIGlzIDdhNWNjMDAwIQ0KWyAgMTM3LjAzMjYwMl0gMzY0YjQgaXMgN2E1Y2QwMDAhDQpb
ICAxMzcuMDM0NDUxXSAzNjRiNSBpcyA3YTVjZTAwMCENClsgIDEzNy4wMzYyNjddIDM2NGI2
IGlzIDdhNWNmMDAwIQ0KWyAgMTM3LjAzODA5Nl0gMzY0YjcgaXMgN2E1ZDAwMDAhDQpbICAx
MzcuMDM5OTI4XSAzNzYwOCBpcyA3YTVkMTAwMCENClsgIDEzNy4wNDE3NzRdIDM3NjA5IGlz
IDdhNWQyMDAwIQ0KWyAgMTM3LjA0MzY0M10gMzc2MGEgaXMgN2E1ZDMwMDAhDQpbICAxMzcu
MDQ1NDg0XSAzNzYwYiBpcyA3YTVkNDAwMCENClsgIDEzNy4wNDczNTJdIDM3NTI0IGlzIDc5
NDBmMDAwIQ0KWyAgMTM3LjA0OTIwNF0gMzc1MjUgaXMgNzk0MGUwMDAhDQpbICAxMzcuMDUx
MDgzXSAzNzUyNiBpcyA3OTQwZDAwMCENClsgIDEzNy4wNTI5MjJdIDM3NTI3IGlzIDc5NDBj
MDAwIQ0KWyAgMTM3LjA1NDc3NV0gMzkyZjQgaXMgNzhlYWIwMDAhDQpbICAxMzcuMDU2Njc3
XSAzOTJmNSBpcyA3OGVhYTAwMCENClsgIDEzNy4wNTg1NzBdIDM5MmY2IGlzIDc4ZWE5MDAw
IQ0KWyAgMTM3LjA2MDQ0MF0gMzkyZjcgaXMgNzhlYTgwMDAhDQpbICAxMzcuMDYyMjg1XSAz
OTJlMCBpcyA3OGVhNzAwMCENClsgIDEzNy4wNjQxNTldIDM5MmUxIGlzIDc4ZWE2MDAwIQ0K
WyAgMTM3LjA2NjAxMV0gMzkyZTIgaXMgNzhlYTUwMDAhDQpbICAxMzcuMDY3ODc3XSAzOTJl
MyBpcyA3OTQxYTAwMCENClsgIDEzNy4wNjk2ODldIDM4YzgwIGlzIDc5NDE5MDAwIQ0KWyAg
MTM3LjA3MTUzNV0gMzhjODEgaXMgNzk0MTgwMDAhDQpbICAxMzcuMDczNDAzXSAzOGM4MiBp
cyA3OTQxNzAwMCENClsgIDEzNy4wNzUyNDldIDM4YzgzIGlzIDc5NDE2MDAwIQ0KWyAgMTM3
LjA3NzEwNV0gMzZmNDQgaXMgNzk0MTUwMDAhDQpbICAxMzcuMDc4OTUwXSAzNmY0NSBpcyA3
OTQxNDAwMCENClsgIDEzNy4wODA4MjhdIDM2ZjQ2IGlzIDc5NDEzMDAwIQ0KWyAgMTM3LjA4
MjY3OV0gMzZmNDcgaXMgNzk0MTIwMDAhDQpbICAxMzcuMDg0NTQwXSAzOGNmMCBpcyA3OTQx
MTAwMCENClsgIDEzNy4wODYzOTFdIDM4Y2YxIGlzIDc5NDEwMDAwIQ0KWyAgMTM3LjA4ODIz
OF0gMzhjZjMgaXMgNzhlYTIwMDAhDQpbICAxMzcuMDkwMDk2XSAzNzhjOCBpcyA3OGVhMzAw
MCENClsgIDEzNy4wOTE5MzBdIDM3OGM5IGlzIDc4ZWE0MDAwIQ0KWyAgMTM3LjA5Mzc5Ml0g
Mzc4Y2EgaXMgNzk0MjEwMDAhDQpbICAxMzcuMDk1NjUxXSAzNzhjYiBpcyA3OTQyMDAwMCEN
ClsgIDEzNy4wOTc1MjZdIDM4Yzc0IGlzIDc5NDFmMDAwIQ0KWyAgMTM3LjA5OTM3Nl0gMzhj
NzUgaXMgNzk0MWUwMDAhDQpbICAxMzcuMTAxMjQ1XSAzOGM3NiBpcyA3OTQxZDAwMCENClsg
IDEzNy4xMDMwOTVdIDM4Yzc3IGlzIDc5NDFjMDAwIQ0KWyAgMTM3LjEwNDk1NF0gMzc5ZTAg
aXMgNzk0MWIwMDAhDQpbICAxMzcuMTA2ODE3XSAzNzZjMSBpcyA3YTVkZjAwMCENClsgIDEz
Ny4xMDg2ODBdIDM3NmMyIGlzIDdhNWUwMDAwIQ0KWyAgMTM3LjExMDU3M10gMzc2YzMgaXMg
N2E1ZTEwMDAhDQpbICAxMzcuMTEyNDQxXSAzN2ZmMCBpcyA3YTVlMjAwMCENClsgIDEzNy4x
MTQzMTVdIDM3ZmYxIGlzIDdhNWU4MDAwIQ0KWyAgMTM3LjExNjE2N10gMzdmZjIgaXMgN2E1
ZTkwMDAhDQpbICAxMzcuMTE4MDU0XSAzN2ZmMyBpcyA3YTVlYTAwMCENClsgIDEzNy4xMTk5
MTBdIDM3YTI4IGlzIDdhNWViMDAwIQ0KWyAgMTM3LjEyMTgwMF0gMzdhMjkgaXMgMjE5NDUw
MDAhDQpbICAxMzcuMTIzNjk5XSAzN2EyYSBpcyAyMTk0NjAwMCENClsgIDEzNy4xMjU1ODVd
IDM3YTJiIGlzIDIxOTQ3MDAwIQ0KWyAgMTM3LjEyODE1MV0gMzc5ZTIgaXMgNzkzMDEwMDAh
DQpbICAxMzcuMTMwMTQwXSAzNzllMSBpcyA3OTMwMjAwMCENClsgIDEzNy4xMzIwMjZdIDM3
ZTFiIGlzIDc5MzAzMDAwIQ0KWyAgMTM3LjEzMzkzNF0gMzc1YzAgaXMgNzkzMDQwMDAhDQpb
ICAxMzcuMTM1ODUzXSAzNzVjMSBpcyA3OTMwNTAwMCENClsgIDEzNy4xMzc3NTVdIDM3NWMy
IGlzIDc5MzA3MDAwIQ0KWyAgMTM3LjEzOTY1MV0gMzc1YzMgaXMgNzkzMDgwMDAhDQpbICAx
MzcuMTQxNTMyXSAzNzU1MCBpcyA3OTMwOTAwMCENClsgIDEzNy4xNDM0NDJdIDM3NTUxIGlz
IDc5MzBhMDAwIQ0KWyAgMTM3LjE0NTI5OF0gMzc1NTIgaXMgNzkzMGIwMDAhDQpbICAxMzcu
MTQ3MzQyXSAzNzU1MyBpcyA3OGU4YzAwMCENClsgIDEzNy4xNDkyMjNdIDM4Y2E4IGlzIDc4
ZThkMDAwIQ0KWyAgMTM3LjE1MTEwNF0gMzhjYTkgaXMgNzhlOGUwMDAhDQpbICAxMzcuMTUy
OTYxXSAzOGNhYSBpcyA3OGU4ZjAwMCENClsgIDEzNy4xNTQ4MTNdIDM4Y2FiIGlzIDc4ZTkw
MDAwIQ0KWyAgMTM3LjE1NjY3Nl0gMzdlZTggaXMgNzhlOTEwMDAhDQpbICAxMzcuMTU4NTI5
XSAzN2VlOSBpcyA3OGU5MjAwMCENClsgIDEzNy4xNjA0MDVdIDM3ZWVhIGlzIDc4ZTkzMDAw
IQ0KWyAgMTM3LjE2MjI0M10gMzdlZWIgaXMgNzhlOTQwMDAhDQpbICAxMzcuMTY0MTE4XSAz
ODMyYyBpcyA3OGU5NTAwMCENClsgIDEzNy4xNjU5NjJdIDM4MzJkIGlzIDc4ZTk2MDAwIQ0K
WyAgMTM3LjE2NzgwOV0gMzgzMmUgaXMgNzhlOTcwMDAhDQpbICAxMzcuMTY5NjIxXSAzODMy
ZiBbICAxMzkuMjk3MjI1XSAzNzliYyBpcyAyMzRhYzAwMCENClsgIDEzOS4yOTk0NDVdIDM3
OWJkIGlzIDI0NDdhMDAwIQ0KWyAgMTM5LjMwMjk3MV0gMzc3YTcgaXMgMjQ0NTYwMDAhDQpb
ICAxMzkuMzE4OTExXSAzNzdhMSBpcyAyMmIxOTAwMCENClsgIDEzOS4zMjExMTddIDM3N2Ey
IGlzIDIzMzhlMDAwIQ0KWyAgMTM5LjMyMzI5OF0gMzc3YTMgaXMgMjQyMmEwMDAhDQpbICAx
MzkuMzI1NDk3XSAzNzdhNCBpcyAyMmJhYzAwMCENClsgIDEzOS4zMjc3MDZdIDM3N2E1IGlz
IDI0MjYwMDAwIQ0KWyAgMTM5LjMyOTkyOV0gMzc3YTYgaXMgMjQyZWMwMDAhDQpbICAxMzku
MzMyMTQ3XSAzNzdhMCBpcyAyNDI2YzAwMCENClsgIDEzOS4zMzQzNDBdIDM3OWJlIGlzIDIz
NGFiMDAwIQ0KWyAgMTM5LjMzNzE2Ml0gMzdmYzggaXMgMjQ0MjkwMDAhDQpbICAxMzkuMzcx
Mzg0XSAzN2ZjOSBpcyA3OTQ2NDAwMCENClsgIDEzOS4zNzM2NzBdIDM4Y2E1IGlzIDc5NDdk
MDAwIQ0KWyAgMTM5LjM3NTg0M10gMzhjYTYgaXMgNzk0OTcwMDAhDQpbICAxMzkuMzc4MDU3
XSAzNzliZiBpcyA3OTQ4OTAwMCENClsgIDEzOS4zODg4NzddIDM3ZmNhIGlzIDIyYTRiMDAw
IQ0KWyAgMTM5LjM5MTIyNF0gMzdmY2IgaXMgMjJhNGEwMDAhDQpbICAxMzkuMzkzNDA1XSAz
N2ZjYyBpcyAyMmE0OTAwMCENClsgIDEzOS4zOTU2NTJdIDM4Y2E3IGlzIDdhMDY3MDAwIQ0K
WyAgMTM5LjQwNzQ2Ml0gMzdmY2UgaXMgN2E2ZWQwMDAhDQpbICAxMzkuNDIyOTIzXSAzN2Zj
ZCBpcyAyMWU0YjAwMCENClsgIDEzOS40MzAyOTZdIDM3YmIwIGlzIDIxNjgzMDAwIQ0KWyAg
MTM5LjQzOTMzN10gMzdiYjEgaXMgNzk0YjYwMDAhDQpbICAxMzkuNDYyODIwXSAzN2JiMiBp
cyAyMWUzYzAwMCENClsgIDEzOS40ODgxNjVdIDM3YmIzIGlzIDIxZTU3MDAwIQ0KWyAgMTM5
LjQ5MDQ2Ml0gMzdiYjQgaXMgNzhkMWEwMDAhDQpbICAxMzkuNDkyNjg1XSAzN2JiNSBpcyAy
MWU1OTAwMCENClsgIDEzOS40OTQ5NTVdIDM3YmI2IGlzIDc4ZDQ5MDAwIQ0KWyAgMTM5LjQ5
OTM3NV0gMzdiYjcgaXMgNzk0NzEwMDAhDQpbICAxMzkuNTAxNzEyXSAzN2ZjZiBpcyAyMThh
YTAwMCENClsgIDEzOS41MDM5NjldIDM2ZjAwIGlzIDc5NDhmMDAwIQ0KWyAgMTM5LjUwNjIz
MF0gMzZmMDEgaXMgMjFlNWUwMDAhDQpbICAxMzkuNTA4NTE2XSAzNmYwMiBpcyAyMTY0YTAw
MCENClsgIDEzOS41MTA4MDFdIDM2ZjAzIGlzIDIxNjdjMDAwIQ0KWyAgMTM5LjUxMzk4N10g
MzZmMDQgaXMgNzk0NTAwMDAhDQpbICAxMzkuNTE2MjYxXSAzNmYwNSBpcyA3YTA1MjAwMCEN
ClsgIDEzOS41MTg1NThdIDM2ZjA2IGlzIDc5NDRjMDAwIQ0KWyAgMTM5LjU1MDk1MF0gMzZm
MDcgaXMgMjFlNmMwMDAhDQpbICAxMzkuNTUzMjI1XSAzNzU2OCBpcyA3OTRjNDAwMCENClsg
IDEzOS41NTU1NDNdIDM3NTY5IGlzIDdhNjFkMDAwIQ0KWyAgMTM5LjU1Nzg0NV0gMzc1NmEg
aXMgMjFlNjMwMDAhDQpbICAxMzkuNTYwMTY3XSAzNzU2YiBpcyA3OGNkOTAwMCENClsgIDEz
OS41NjI0NjJdIDM3NTZjIGlzIDIxNjQ4MDAwIQ0KWyAgMTM5LjU2NDc4M10gMzc1NmQgaXMg
N2EwNTMwMDAhDQpbICAxMzkuNTY3MDgzXSAzNzU2ZSBpcyA3OGNkZDAwMCENClsgIDEzOS41
NjkzOThdIDM3NTZmIGlzIDdhMDU4MDAwIQ0KWyAgMTM5LjU3MjE4Nl0gMzdmYTAgaXMgMjE2
NDAwMDAhDQpbICAxMzkuNTc0NTA4XSAzN2ZhMSBpcyA3YTZiYjAwMCENClsgIDEzOS41NzY4
NTBdIDM3ZmEyIGlzIDc4Y2QyMDAwIQ0KWyAgMTM5LjU3OTE3M10gMzdmYTMgaXMgMjFlNTgw
MDAhDQpbICAxMzkuNTgyMTcwXSAzN2ZhNCBpcyA3YTA0ZDAwMCENClsgIDEzOS41ODQ0OTdd
IDM2ZWMwIGlzIDIxNjI5MDAwIQ0KWyAgMTM5LjU4NjgxNl0gMzZlYzEgaXMgN2EwODcwMDAh
DQpbICAxMzkuNTg5MTM5XSAzNmVjMiBpcyA3OTRhODAwMCENClsgIDEzOS41OTE0NDBdIDM2
ZWMzIGlzIDc5NGJkMDAwIQ0KWyAgMTM5LjU5Mzc4OF0gMzZlYzQgaXMgMjFlNzUwMDAhDQpb
ICAxMzkuNTk2MDcyXSAzNmVjNSBpcyAyMTY1ZTAwMCENClsgIDEzOS41OTgzNzNdIDM2ZWM2
IGlzIDIxNjE2MDAwIQ0KWyAgMTM5LjYwMDYzNV0gMzZlYzcgaXMgMjE2MTUwMDAhDQpbICAx
MzkuNjAzNDAwXSAzNzVhMCBpcyA3OGNkMTAwMCENClsgIDEzOS42MDU3MDNdIDM3NWExIGlz
IDc5NDdmMDAwIQ0KWyAgMTM5LjYwNzk2NF0gMzc1YTIgaXMgNzk0YmIwMDAhDQpbICAxMzku
NjMzNjAyXSAzNzVhMyBpcyA3OGQxODAwMCENClsgIDEzOS42MzU5MDBdIDM3NWE0IGlzIDIx
ZTYwMDAwIQ0KWyAgMTM5LjYzODc0MF0gMzc1YTUgaXMgMjE4YWUwMDAhDQpbICAxMzkuNjQx
MDExXSAzNzVhNiBpcyAyMWU1YTAwMCENClsgIDEzOS42NDMyODFdIDM3NWE3IGlzIDIxZTZl
MDAwIQ0KWyAgMTM5LjY1MjI1N10gMzc3NTAgaXMgMjFlMTAwMDAhDQpbICAxMzkuNjU0NTA1
XSAzNzc1MSBpcyAyMWUwZjAwMCENClsgIDEzOS42NTY3MzBdIDM3NzUyIGlzIDIxZTBlMDAw
IQ0KWyAgMTM5LjY1ODg3OF0gMzc3NTMgaXMgMjFlMGQwMDAhDQpbICAxMzkuNjYxNTczXSAz
Nzc1NCBpcyAyMWUzNzAwMCENClsgIDEzOS42NjM3MzBdIDM3NzU1IGlzIDIxZTM4MDAwIQ0K
WyAgMTM5LjY2NTgxOF0gMzc3NTYgaXMgMjFlM2QwMDAhDQpbICAxMzkuNjY3OTIxXSAzNzc1
NyBpcyAyMWU1MjAwMCENClsgIDEzOS43MTIzMTFdIDM2ZTYxIGlzIDIxODhhMDAwIQ0KWyAg
MTM5LjcxNTA0OV0gMzdmYTUgaXMgNzhjZWQwMDAhDQpbICAxMzkuNzQ5NDQ1XSAzNmU2MiBp
cyA3OTQ4ZTAwMCENClsgIDEzOS43NTM0ODRdIDM5MTQ0IGlzIDIxOGJkMDAwIQ0KWyAgMTM5
Ljc4MzMyNV0gMzdlNjUgaXMgMjFlNDgwMDAhDQpbICAxMzkuNzg1NTA3XSAzN2UxZCBpcyA3
YTY2MDAwMCENClsgIDEzOS43OTgxMDRdIDM3ZmE2IGlzIDdhNzFiMDAwIQ0KWyAgMTM5Ljgw
MDMyNV0gMzdmYTcgaXMgNzk0YmUwMDAhDQpbICAxMzkuODAyNDc5XSAzN2QxOCBpcyAyMWUz
ZTAwMCENClsgIDEzOS44MDQ2NDZdIDM3ZDE5IGlzIDIxNjE5MDAwIQ0KWyAgMTM5LjgwNzMy
M10gMzdkMWEgaXMgMjFlM2EwMDAhDQpbICAxMzkuODA5NDk0XSAzNmU2MyBpcyA3YTY5MzAw
MCENClsgIDEzOS44MTE3MjhdIDM2ZTY0IGlzIDIxNjUxMDAwIQ0KWyAgMTM5LjgxMzkzNl0g
MzZlNjUgaXMgMjE4ODkwMDAhDQpbICAxMzkuODE2NjE4XSAzNmU2NiBpcyAyMTYwYTAwMCEN
ClsgIDEzOS44MTg4NDNdIDM2ZTY3IGlzIDc4Y2Q3MDAwIQ0KWyAgMTM5LjgyMTAyNV0gMzdh
NTggaXMgN2EwNmIwMDAhDQpbICAxMzkuODIzMjI5XSAzN2E1OSBpcyA3OTQ0ZjAwMCENClsg
IDEzOS44MzEyNjhdIDM3YTVhIGlzIDIxNWJjMDAwIQ0KWyAgMTM5LjgzMzQ4MV0gMzdhNWIg
aXMgMjE2NmMwMDAhDQpbICAxMzkuODM1NzM2XSAzN2E1YyBpcyA3YTA5MDAwMCENClsgIDEz
OS44Mzc5NTJdIDM3YTVkIGlzIDc5NGM4MDAwIQ0KWyAgMTM5Ljg0MDE4MF0gMzdhNWUgaXMg
MjE2NTkwMDAhDQpbICAxMzkuODQyNDE5XSAzN2E1ZiBpcyAyMWU3ZjAwMCENClsgIDEzOS44
NDQ3MDBdIDM2NTU4IGlzIDc4Y2YxMDAwIQ0KWyAgMTM5Ljg0Njk3OV0gMzY1NTkgaXMgNzk0
OWEwMDAhDQpbICAxMzkuODQ5MjQ3XSAzNjU1YSBpcyAyMTYwNjAwMCENClsgIDEzOS44NTIw
NDddIDM2NTViIGlzIDc4Y2NkMDAwIQ0KWyAgMTM5Ljg1NDM2OV0gMzY1NWMgaXMgMjE4YTgw
MDAhDQpbICAxMzkuODU2NzI3XSAzNjU1ZCBpcyA3OGQzODAwMCENClsgIDEzOS44NTkwODJd
IDM2NTVlIGlzIDc5NDUxMDAwIQ0KWyAgMTM5Ljg2MTc0Ml0gMzY1NWYgaXMgNzhkMzUwMDAh
DQpbICAxMzkuODc2NTY2XSAzN2RjOCBpcyA3OGQwNDAwMCENClsgIDE0MC4wMjgzMDZdIDM3
ZGM5IGlzIDIxOGI1MDAwIQ0KWyAgMTQwLjA3NjMyNV0gMzdkMWIgaXMgNzk0OGEwMDAhDQpb
ICAxNDAuMDc4NzQ3XSAzN2QxYyBpcyA3OTRhYTAwMCENClsgIDE0MC4wODEwNzldIDM2Yzcz
IGlzIDc4ZDQyMDAwIQ0KWyAgMTQwLjA4MzQwMV0gMzZjNzQgaXMgNzk0YTYwMDAhDQpbICAx
NDAuMTEwMDMyXSAzNmM3NSBpcyAyMTY3NjAwMCENClsgIDE0MC4xMTI0MTBdIDM3YjVlIGlz
IDc5NDU4MDAwIQ0KWyAgMTQwLjExNDc1OF0gMzdmMmMgaXMgNzhkMTQwMDAhDQpbICAxNDAu
MTE3MTI0XSAzN2RjZCBpcyAyMWU3YzAwMCENClsgIDE0MC4xMjg4MzNdIDM3ZGNlIGlzIDIx
NWJhMDAwIQ0KWyAgMTQwLjEzMTIwOF0gMzdkY2YgaXMgMjE4YWMwMDAhDQpbICAxNDAuMTMz
NTY2XSAzN2YwMCBpcyA3YTY4ZjAwMCENClsgIDE0MC4xODU1MjhdIDM3ZjAxIGlzIDIxZTMw
MDAwIQ0KWyAgMTQwLjE4Nzk3M10gMzZjNzYgaXMgMjFlMmYwMDAhDQpbICAxNDAuMTkwMzUz
XSAzNmM3NyBpcyAyMWUyZTAwMCENClsgIDE0MC4xOTI2ODNdIDM2ZjY4IGlzIDIxZTJkMDAw
IQ0KWyAgMTQwLjIyNzMxM10gMzZmNjkgaXMgNzhjZjkwMDAhDQpbICAxNDAuMjI5NjY3XSAz
N2YwMiBpcyA3OGNmODAwMCENClsgIDE0MC4yMzIyNjNdIDM3ZjAzIGlzIDI0NGM4MDAwIQ0K
WyAgMTQwLjIzOTI5Ml0gMzdmMDUgaXMgMjQ0YzEwMDAhDQpbICAxNDAuMjQxNzIxXSAzN2Yw
NiBpcyAyNDMyZTAwMCENClsgIDE0MC4yNDQwMzRdIDM3ZjA3IGlzIDIzNGFlMDAwIQ0KWyAg
MTQwLjI0NjMzMF0gMzkyZjggaXMgMjJhMmQwMDAhDQpbICAxNDAuMjQ4NjI3XSAzOTJmOSBp
cyAyNDNhMDAwMCENClsgIDE0MC4yNTA5NDFdIDM5MmZhIGlzIDI0NDE3MDAwIQ0KWyAgMTQw
LjI1MzIxMF0gMzkyZmIgaXMgMjQzNDUwMDAhDQpbICAxNDAuMjU1NTIzXSAzOTJmYyBpcyAy
NDQ3ZTAwMCENClsgIDE0MC4yNTc3OTVdIDM5MmZkIGlzIDI0Mzg2MDAwIQ0KWyAgMTQwLjI2
MDA3N10gMzkyZmUgaXMgMjQ0YzMwMDAhDQpbICAxNDAuMjYyMzIzXSAzOTJmZiBpcyAyNDM1
ZjAwMCENClsgIDE0MC4yNjQ4MDhdIDM3NWI4IGlzIDIzZGQ4MDAwIQ0KWyAgMTQwLjI2NzEw
OF0gMzc1YjkgaXMgMjQyYmIwMDAhDQpbICAxNDAuMjY5Mzc5XSAzNzViYSBpcyAyNDQ3YTAw
MCENClsgIDE0MC4yNzE2MTldIDM3NWJiIGlzIDI0NGQ4MDAwIQ0KWyAgMTQwLjI3Mzg0OF0g
Mzc1YmMgaXMgMjQyMzIwMDAhDQpbICAxNDAuMjc2MDYxXSAzNzViZCBpcyAyMmExYzAwMCEN
ClsgIDE0MC4yNzgyNTFdIDM3NWJlIGlzIDIzZGI1MDAwIQ0KWyAgMTQwLjI4MDQ1OV0gMzc1
YmYgaXMgMjQ0NTYwMDAhDQpbICAxNDAuMjgyNjAwXSAzNmM3MCBpcyAyMmJhNzAwMCENClsg
IDE0MC4yODQ3ODFdIDM2YzcxIGlzIDI0MzJiMDAwIQ0KWyAgMTQwLjI4NjkzN10gMzZjNzIg
aXMgMjQyYTEwMDAhDQpbICAxNDAuMjg5MTAxXSAzNjRhMyBpcyAyMzM5MDAwMCENClsgIDE0
MC4yOTEyMzddIDM2NGE0IGlzIDI0M2QyMDAwIQ0KWyAgMTQwLjI5MzM1OV0gMzY0YTUgaXMg
MjMyZTQwMDAhDQpbICAxNDAuMjk1NDczXSAzNjRhNiBpcyAyMzRhZjAwMCENClsgIDE0MC4y
OTc1OTJdIDM2NGE3IGlzIDI0MzllMDAwIQ0KWyAgMTQwLjI5OTY5Nl0gMzkyYjggaXMgMjJj
MDMwMDAhDQpbICAxNDAuMzAxODU1XSAzOTJiOSBpcyAyNDJlMDAwMCENClsgIDE0MC4zMDM5
OTldIDM5MmJhIGlzIDI0MjcwMDAwIQ0KWyAgMTQwLjMwNjEzMl0gMzkyYmIgaXMgMjJiYjcw
MDAhDQpbICAxNDAuMzA4MjYwXSAzOTJiYyBpcyAyNDNkZDAwMCENClsgIDE0MC4zMzYzMzZd
IDM5MmJkIGlzIDI0M2NhMDAwIQ0KWyAgMTQwLjM1MDMxNF0gMzdmMDQgaXMgMjJiYTcwMDAh
DQpbICAxNDAuMzc2OTg3XSAzOTJiZSBpcyA3OGNmYTAwMCENClsgIDE0MC40MTI2NzJdIDM2
ZjZhIGlzIDIxZTFjMDAwIQ0KWyAgMTQwLjQxNDk1MV0gMzZmNmIgaXMgMjFlMWIwMDAhDQpb
ICAxNDAuNDE3MTgzXSAzNmY2YyBpcyAyMWUxYTAwMCENClsgIDE0MC40NTM3ODNdIDM2ZjZk
IGlzIDc5NDc3MDAwIQ0KWyAgMTQwLjUxNDAwNl0gMzkyYmYgaXMgMjE2NGQwMDAhDQpbICAx
NDAuNTE2NzkwXSAzNmY2ZSBpcyA3YTZiODAwMCENClsgIDE0MC41MTk1MDddIDM4YzA4IGlz
IDIxZTEyMDAwIQ0KWyAgMTQwLjUzMzUwNl0gMzhjMDkgaXMgMjFlMjAwMDAhDQpbICAxNDAu
NTM1NzYyXSAzNmY2ZiBpcyAyMWUxZjAwMCENClsgIDE0MC41MzgwNzRdIDM3ZWY4IGlzIDIx
ZTFlMDAwIQ0KWyAgMTQwLjU0MDM1OF0gMzdlZjkgaXMgMjFlMWQwMDAhDQpbICAxNDAuNTQz
MDc1XSAzN2VmYSBpcyAyMWUyMjAwMCENClsgIDE0MC41NDUzNzZdIDM4YzBhIGlzIDIxZTIx
MDAwIQ0KWyAgMTQwLjU1NDg3Nl0gMzhjMGMgaXMgMjFlMDYwMDAhDQpbICAxNDAuNTU3MTUz
XSAzOGMwZCBpcyAyMWUwNTAwMCENClsgIDE0MC41NTkzODddIDM4YzBlIGlzIDIxZTI0MDAw
IQ0KWyAgMTQwLjU2MTYwMF0gMzhjMGYgaXMgMjFlMjMwMDAhDQpbICAxNDAuNTY0MjAxXSAz
OGMwYiBpcyAyMWE2YjAwMCENClsgIDE0MC41NzQ2MTZdIDM3NTEwIGlzIDIxZTRlMDAwIQ0K
WyAgMTQwLjU3Njk2Nl0gMzc1MTEgaXMgN2EwYjEwMDAhDQpbICAxNDAuNTc5MTU1XSAzNzUx
MiBpcyAyMWUyNTAwMCENClsgIDE0MC41ODEzNTRdIDM3NTEzIGlzIDIxZTMxMDAwIQ0KWyAg
MTQwLjU4MzU2OF0gMzc1MTQgaXMgMjE2NWMwMDAhDQpbICAxNDAuNTg1NzMzXSAzNzUxNSBp
cyAyMWUwYzAwMCENClsgIDE0MC41ODc5MTBdIDM3NTE2IGlzIDIxZTBiMDAwIQ0KWyAgMTQw
LjU5MDAyNV0gMzc1MTcgaXMgMjFlMGEwMDAhDQpbICAxNDAuNTkyMTgxXSAzOTMzMCBpcyAy
MWUwOTAwMCENClsgIDE0MC41OTQzNzhdIDM5MzMxIGlzIDIxZTA4MDAwIQ0KWyAgMTQwLjU5
NjQ5Nl0gMzdkY2EgaXMgMjFlMDcwMDAhDQpbICAxNDAuNTk4NzExXSAzN2RjYiBpcyAyMWUx
ODAwMCENClsgIDE0MC42MDA4NDRdIDM5MzMyIGlzIDIxZTE5MDAwIQ0KWyAgMTQwLjYwMjkw
N10gMzkzMzMgaXMgMjFlMzUwMDAhDQpbICAxNDAuNjA0OTYwXSAzOTMzNCBpcyA3YTA4NjAw
MCENClsgIDE0MC42MDcwMTJdIDM5MzM1IGlzIDIxZTI5MDAwIQ0KWyAgMTQwLjYwOTA5MV0g
MzkzMzYgaXMgN2E2YmMwMDAhDQpbICAxNDAuNjExOTk3XSAzOTMzNyBpcyAyMWE2OTAwMCEN
ClsgIDE0MC42MTQwODZdIDM3ZjM4IGlzIDIxYTZhMDAwIQ0KWyAgMTQwLjYxNjExM10gMzdm
MzkgaXMgMjFhNzMwMDAhDQpbICAxNDAuNjE4MTAxXSAzN2YzYSBpcyAyMWE3NDAwMCENClsg
IDE0MC42MjAzMzNdIDM2NWE2IGlzIDIxYTgwMDAwIQ0KWyAgMTQwLjYyMjMwMl0gMzY1YTcg
aXMgMjFhODEwMDAhDQpbICAxNDAuNjI0MjY3XSAzOTJhOCBpcyAyMWE4MjAwMCENClsgIDE0
MC42MjYyMzNdIDM5MmE5IGlzIDIxYTgzMDAwIQ0KWyAgMTQwLjYyODI5NF0gMzkyYWEgaXMg
MjFhODQwMDAhDQpbICAxNDAuNjMwMjY0XSAzOTJhYiBpcyAyMWUxNTAwMCENClsgIDE0MC42
MzIxOTddIDM5MmFjIGlzIDIxZTE2MDAwIQ0KWyAgMTQwLjYzNDE2Nl0gMzkyYWQgaXMgMjFl
MTcwMDAhDQpbICAxNDAuNjM2MDg3XSAzN2YzYiBpcyAyMWE3NTAwMCENClsgIDE0MC42Mzgw
NjNdIDM3ZjNjIGlzIDIxYTc2MDAwIQ0KWyAgMTQwLjYzOTk5Nl0gMzdmM2QgaXMgMjFhNzcw
MDAhDQpbICAxNDAuNjQxOTMyXSAzN2YzZSBpcyAyMWE3ODAwMCENClsgIDE0MC42NDM4Mzdd
IDM3ZjNmIGlzIDIxYTc5MDAwIQ0KWyAgMTQwLjY0NTcxMV0gMzY1YTAgaXMgMjFhN2EwMDAh
DQpbICAxNDAuNjQ3NTk2XSAzNjVhMSBpcyAyMWE3YjAwMCENClsgIDE0MC42NDk0NzRdIDM2
NWEyIGlzIDIxYTdjMDAwIQ0KWyAgMTQwLjY1MTM0MV0gMzY1YTMgaXMgMjFhN2QwMDAhDQpb
ICAxNDAuNjUzMTk5XSAzNjVhNCBpcyAyMWE3ZTAwMCENClsgIDE0MC42NTUwODBdIDM2NWE1
IGlzIDIxYTdmMDAwIQ0KWyAgMTQwLjY1Njk5NV0gMzkyYWUgaXMgMjFhNjUwMDAhDQpbICAx
NDAuNjU4ODcyXSAzOTJhZiBpcyAyMWE2NjAwMCENClsgIDE0MC42NjA3MjBdIDM3YTIwIGlz
IDIxYTY3MDAwIQ0KWyAgMTQwLjY2MjU4OF0gMzdhMjEgaXMgMjFhNjgwMDAhDQpbICAxNDAu
NjcwOTU5XSAzN2EyMiBpcyAyMWE0ZTAwMCENClsgIDE0MC42Nzk2ODRdIDM3YTIzIGlzIDIx
YTVhMDAwIQ0KWyAgMTQwLjY4MTYzOF0gMzdhMjQgaXMgMjFhNWIwMDAhDQpbICAxNDAuNjgz
NDY4XSAzN2EyNSBpcyAyMWE1YzAwMCENClsgIDE0MC42ODUyMzldIDM3YTI2IGlzIDIxYTVk
MDAwIQ0KWyAgMTQwLjY4NzAxOV0gMzdhMjcgaXMgMjFhNWUwMDAhDQpbICAxNDAuNjg4NzU3
XSAzNmY5MCBpcyAyMWE1ZjAwMCENClsgIDE0MC42OTA1MTZdIDM2ZjkxIGlzIDIxYTYwMDAw
IQ0KWyAgMTQwLjY5MjI5M10gMzZmOTIgaXMgMjFhNjEwMDAhDQpbICAxNDAuNjk0MDQwXSAz
NmY5MyBpcyAyMWE2MjAwMCENClsgIDE0MC42OTU3OTNdIDM2Zjk0IGlzIDIxYTYzMDAwIQ0K
WyAgMTQwLjY5NzUzNV0gMzZmOTUgaXMgMjFhNjQwMDAhDQpbICAxNDAuNjk5NDAxXSAzNmY5
NiBpcyAyMWE1NDAwMCENClsgIDE0MC43MDEyMTJdIDM2Zjk3IGlzIDIxYTU1MDAwIQ0KWyAg
MTQwLjcwMjk2N10gMzZlZDAgaXMgMjFhNTYwMDAhDQpbICAxNDAuNzA0NzgwXSAzNmVkMSBp
cyAyMWE1NzAwMCENClsgIDE0MC43MDY1NTFdIDM2ZWQyIGlzIDIxYTU4MDAwIQ0KWyAgMTQw
LjcwODMxOV0gMzZlZDMgaXMgMjFhNTkwMDAhDQpbICAxNDAuNzEwODMyXSAzNmVkNSBpcyAy
MWEzZjAwMCENClsgIDE0MC43MTI2OTZdIDM2ZWQ0IGlzIDIxZTUwMDAwIQ0KWyAgMTQwLjcx
NDQ5N10gMzdlZmIgaXMgMjFhNDEwMDAhDQpbICAxNDAuNzE2MzAwXSAzN2VmYyBpcyA3OTQ3
NDAwMCENClsgIDE0MC43MTgxMTVdIDM3ZWZkIGlzIDc5NDZiMDAwIQ0KWyAgMTQwLjcxOTkx
Ml0gMzdlZmUgaXMgMjFlNTEwMDAhDQpbICAxNDAuNzIxOTU0XSAzNjQ0NSBpcyAyMWEzNDAw
MCENClsgIDE0MC43MjM4MzBdIDM2NDQ2IGlzIDIxYTMzMDAwIQ0KWyAgMTQwLjcyNTY4M10g
MzY0NDcgaXMgMjFhMzIwMDAhDQpbICAxNDAuNzI3NTQwXSAzNjQzMCBpcyAyMWEzMTAwMCEN
ClsgIDE0MC43MjkzODNdIDM2NDMxIGlzIDIxYTMwMDAwIQ0KWyAgMTQwLjczMTIyN10gMzY0
MzIgaXMgMjFhMmYwMDAhDQpbICAxNDAuNzMzMDYwXSAzNjQzMyBpcyAyMWEyZTAwMCENClsg
IDE0MC43MzQ4OTJdIDM2NDM0IGlzIDIxYTJkMDAwIQ0KWyAgMTQwLjczNjY5NV0gMzdlZmYg
aXMgMjFhM2UwMDAhDQpbICAxNDAuNzM4NTQ0XSAzN2E2OCBpcyA3OTQ2MzAwMCENClsgIDE0
MC43NDA0MTJdIDM3YTY5IGlzIDc5NDcwMDAwIQ0KWyAgMTQwLjc0MjI5Nl0gMzdhNmEgaXMg
MjFhM2MwMDAhDQpbICAxNDAuNzQ0MjAzXSAzN2E2YiBpcyAyMWEzYjAwMCENClsgIDE0MC43
NDYxMDhdIDM3YTZjIGlzIDIxYTNhMDAwIQ0KWyAgMTQwLjc0Nzk5Ml0gMzdhNmQgaXMgMjFh
MzkwMDAhDQpbICAxNDAuNzQ5ODY5XSAzN2E2ZSBpcyAyMWEzODAwMCENClsgIDE0MC43NTE3
MzVdIDM3YTZmIGlzIDIxYTM3MDAwIQ0KWyAgMTQwLjc1MzYyM10gMzY0YTAgaXMgMjFhMzYw
MDAhDQpbICAxNDAuNzU1NDk3XSAzNjRhMSBpcyAyMWEzNTAwMCENClsgIDE0MC43NjU0ODBd
IDM2NDM1IGlzIDIxYTUwMDAwIQ0KWyAgMTQwLjc2NzQzMF0gMzY0MzYgaXMgMjFhNDcwMDAh
DQpbICAxNDAuNzY5MzI1XSAzNjQzNyBpcyAyMWE1MTAwMCENClsgIDE0MC43NzE3MzBdIDM2
NDc5IGlzIDIxYTJiMDAwIQ0KWyAgMTQwLjc3MzY0NF0gMzY0N2EgaXMgMjFhMmMwMDAhDQpb
ICAxNDAuNzc1NTM4XSAzNjQ3YiBpcyAyMWE0ODAwMCENClsgIDE0MC43Nzc0NDZdIDM2NDdj
IGlzIDIxYTQ2MDAwIQ0KWyAgMTQwLjc3OTgzNV0gMzY0N2QgaXMgMjFhMjgwMDAhDQpbICAx
NDAuNzgxNzI3XSAzNjQ3OCBpcyAyMWEyOTAwMCENClsgIDE0MC43ODM2MzFdIDM2ZWQ2IGlz
IDIxYTJhMDAwIQ0KWyAgMTQwLjc5MzkyNV0gMzZlZDcgaXMgMjM0YTUwMDAhDQpbICAxNDAu
Nzk2MzkxXSAzNjQ0MCBpcyAyMzRhNjAwMCENClsgIDE0MC44MDI1MDJdIDM2NDdlIGlzIDIy
YmIwMDAwIQ0KWyAgMTQwLjgwNDUwNF0gMzY0NDEgaXMgMjQyMmMwMDAhDQpbICAxNDAuODA2
MzY3XSAzNjQ0MiBpcyAyNDRjZTAwMCENClsgIDE0MC44MDgyNzhdIDM2NDQzIGlzIDI0NGU2
MDAwIQ0KWyAgMTQwLjgxMDY2NV0gMzY0NDQgaXMgMjQyNWMwMDAhDQpbICAxNDAuODE5MDI2
XSAzNjQ3ZiBpcyAyMzg3YTAwMCENClsgIDE0MC44MjQ3NDZdIDM5M2M4IGlzIDIzM2M2MDAw
IQ0KWyAgMTQwLjgzNjgxM10gMzkzYzkgaXMgMjQzZTIwMDAhDQpbICAxNDAuODQ0NzM1XSAz
OTNjYSBpcyAyNDI3ODAwMCENClsgIDE0MC44NDczMDVdIDM5M2NiIGlzIDI0MjMwMDAwIQ0K
WyAgMTQwLjg1NzEyMl0gMzkzY2MgaXMgMjQzMWEwMDAhDQpbICAxNDAuODU5NjUwXSAzOTNj
ZCBpcyAyNDNjMDAwMCENClsgIDE0MC44Njg2MzNdIDM5M2NlIGlzIDI0NDhjMDAwIQ0KWyAg
MTQwLjg3NzkxOF0gMzkzY2YgaXMgMjQxZDQwMDAhDQpbICAxNDAuODgzNTQ2XSAzOTM3MCBp
cyAyNDQ2NjAwMCENClsgIDE0MC44ODYwODVdIDM5MzcxIGlzIDI0M2YzMDAwIQ0KWyAgMTQw
Ljg5MzY0OV0gMzkzNzIgaXMgMjQzZTgwMDAhDQpbICAxNDAuOTAyMDY3XSAzOTM3MyBpcyAy
NDUyOTAwMCENClsgIDE0MC45MDY0ODddIDM5Mzc0IGlzIDI0MmU5MDAwIQ0KWyAgMTQwLjkx
MjAxMF0gMzkzNzUgaXMgMjQyNmUwMDAhDQpbICAxNDAuOTE3NDg5XSAzOTM3NiBpcyAyNDJl
ZDAwMCENClsgIDE0MC45MjI2NTBdIDM5Mzc3IGlzIDIyYmQ0MDAwIQ0KWyAgMTQwLjkyNzM3
MV0gMzkzYjggaXMgMjMzYmYwMDAhDQpbICAxNDAuOTMwMDAwXSAzOTNiOSBpcyAyMzNhNTAw
MCENClsgIDE0MC45Mzk0MDhdIDM5M2JhIGlzIDIzM2I2MDAwIQ0KWyAgMTQwLjk1MTE3OF0g
MzkzYmIgaXMgMjNkODUwMDAhDQpbICAxNDAuOTY1NDMwXSAzOTNiYyBpcyAyNDU3NjAwMCEN
ClsgIDE0MC45NzA1MDddIDM5M2JkIGlzIDI0MzJlMDAwIQ0KWyAgMTQwLjk3MzE4NV0gMzkz
YmUgaXMgMjM5MDYwMDAhDQpbICAxNDAuOTg3NzU3XSAzOTNiZiBpcyAyNDRjMTAwMCENClsg
IDE0MC45OTMwODVdIDM5MWYwIGlzIDIzNGFlMDAwIQ0KWyAgMTQwLjk5ODcxNF0gMzkxZjEg
aXMgMjQyNTUwMDAhDQpbICAxNDEuMDAxNTA4XSAzOTFmMiBpcyAyNDMzZDAwMCENClsgIDE0
MS4wMTUwNDJdIDM5MWYzIGlzIDI0M2NjMDAwIQ0KWyAgMTQxLjAzMDQyNl0gMzkxZjQgaXMg
MjJiMWIwMDAhDQpbICAxNDEuMDM2NzI1XSAzOGQzYiBpcyAyMmEyZDAwMCENClsgIDE0MS4w
Mzg5MzZdIDM4ZDNjIGlzIDI0NDM3MDAwIQ0KWyAgMTQxLjA0MTA5OF0gMzhkM2QgaXMgMjQy
NzIwMDAhDQpbICAxNDEuMDQzMjA2XSAzOGQzZSBpcyAyNDMyOTAwMCENClsgIDE0MS4wNDUz
NDldIDM4ZDNmIGlzIDI0MzlkMDAwIQ0KWyAgMTQxLjA0NzQ1OV0gMzc4YjggaXMgMjJhMjUw
MDAhDQpbICAxNDEuMDUxMTA2XSAzOTkxYiBpcyAyNDU3YjAwMCENClsgIDE0MS4wNTMyOTdd
IDM5OTFhIGlzIDI0NTdjMDAwIQ0KWyAgMTQxLjA1NTQ2OF0gMzk5MTkgaXMgMjJiYjEwMDAh
DQpbICAxNDEuMDU3NjYwXSAzOTkxOCBpcyAyMmJiMjAwMCENClsgIDE0MS4wNTk3ODVdIDM3
OGJmIGlzIDIyYWJkMDAwIQ0KWyAgMTQxLjA2MTk0Nl0gMzc4YmUgaXMgMjJhYmUwMDAhDQpb
ICAxNDEuMDY0MDg4XSAzNzhiZCBpcyAyNDI2NTAwMCENClsgIDE0MS4wNjYyMjhdIDM3OGJj
IGlzIDI0MjY2MDAwIQ0KWyAgMTQxLjA2ODM0M10gMzc4YmIgaXMgMjQ1NzcwMDAhDQpbICAx
NDEuMDcwNDg4XSAzNzhiYSBpcyAyNDU3ODAwMCENClsgIDE0MS4wNzI1ODddIDM3OGI5IGlz
IDI0MmEzMDAwIQ0KWyAgMTQxLjA3NDcxOF0gMzk5MWQgaXMgMjM0YjQwMDAhDQpbICAxNDEu
MDc2ODQzXSAzOTkxZSBpcyAyMzM4ZDAwMCENClsgIDE0MS4wNzg5NTldIDM5OTFmIGlzIDIz
MzhlMDAwIQ0KWyAgMTQxLjA4MTA2MV0gMzdiNjAgaXMgMjQzMzUwMDAhDQpbICAxNDEuMDgz
MTk5XSAzN2I2MSBpcyAyNDMzNjAwMCENClsgIDE0MS4wODUzMjZdIDM3YjYyIGlzIDI0MjI5
MDAwIQ0KWyAgMTQxLjA4NzQ1Nl0gMzdiNjMgaXMgMjQyMmEwMDAhDQpbICAxNDEuMDg5NTM0
XSAzN2I2NCBpcyAyNDQwNTAwMCENClsgIDE0MS4wOTE2MzVdIDM3YjY1IGlzIDI0NDA2MDAw
IQ0KWyAgMTQxLjA5MzY5OV0gMzdiNjYgaXMgMjJiYWQwMDAhDQpbICAxNDEuMDk1NzUzXSAz
OTkxYyBpcyAyMmJhZTAwMCENClsgIDE0MS4wOTc3OTddIDM3YjY3IGlzIDI0MzlhMDAwIQ0K
WyAgMTQxLjA5OTg0M10gMzZmNDggaXMgMjM0YjMwMDAhDQpbICAxNDEuMTAyODcyXSAzNzcx
YyBpcyAyMzNiODAwMCENClsgIDE0MS4xMDUxOTBdIDM3NzFkIGlzIDIzM2I3MDAwIQ0KWyAg
MTQxLjEwNzI3Nl0gMzc3MWUgaXMgMjQzOGEwMDAhDQpbICAxNDEuMTA5MzI4XSAzNzcxZiBp
cyAyNDM4OTAwMCENClsgIDE0MS4xMTE0MDBdIDM2ZDI4IGlzIDIyYjE4MDAwIQ0KWyAgMTQx
LjExMzQ3NF0gMzZkMjkgaXMgMjJiMTcwMDAhDQpbICAxNDEuMTE1NTQwXSAzNmQyYSBpcyAy
MzNhMjAwMCENClsgIDE0MS4xMTc1ODBdIDM2ZDJiIGlzIDIzM2ExMDAwIQ0KWyAgMTQxLjEx
OTU4MF0gMzZkMmMgaXMgMjQ1MmMwMDAhDQpbICAxNDEuMTIxNTc3XSAzNmQyZCBpcyAyNDUy
YjAwMCENClsgIDE0MS4xMjM1NTldIDM2ZDJlIGlzIDIyYTk0MDAwIQ0KWyAgMTQxLjEyNTU1
NV0gMzZkMmYgaXMgMjQyNDUwMDAhDQpbICAxNDEuMTI3NTI1XSAzNzUwMCBpcyAyNDI0NjAw
MCENClsgIDE0MS4xMjk1MThdIDM3NTAxIGlzIDI0NDgwMDAwIQ0KWyAgMTQxLjEzMTQ3MF0g
Mzc1MDIgaXMgMjQ0N2YwMDAhDQpbICAxNDEuMTMzNDU4XSAzNzUwMyBpcyAyM2RkYzAwMCEN
ClsgIDE0MS4xMzU0MTNdIDM3NTA0IGlzIDIzZGRiMDAwIQ0KWyAgMTQxLjEzNzM4N10gMzc1
MDUgaXMgMjJiMWEwMDAhDQpbICAxNDEuMTM5MzQxXSAzNzUwNiBpcyAyMmIxOTAwMCENClsg
IDE0MS4xNDEyODZdIDM3NTA3IGlzIDI0NDUyMDAwIQ0KWyAgMTQxLjE0MzIxMl0gMzY0Mjgg
aXMgMjQ0NTEwMDAhDQpbICAxNDEuMTQ1MTgwXSAzNzcxYiBpcyAyMzg3YzAwMCENClsgIDE0
MS4xNDcxMzRdIDM3NzFhIGlzIDIyYmNkMDAwIQ0KWyAgMTQxLjE0OTEwMF0gMzc3MTkgaXMg
MjJiY2UwMDAhDQpbICAxNDEuMTUxMDQ2XSAzNzcxOCBpcyAyNDFjZjAwMCENClsgIDE0MS4x
NTMwMTVdIDM2ZjRmIGlzIDI0MWQwMDAwIQ0KWyAgMTQxLjE1NDk4OV0gMzZmNGUgaXMgMjJi
MmIwMDAhDQpbICAxNDEuMTU2OTk4XSAzNmY0ZCBpcyAyMmIyYzAwMCENClsgIDE0MS4xNTg5
NTldIDM2ZjRjIGlzIDI0NDg5MDAwIQ0KWyAgMTQxLjE2MDkyOF0gMzZmNGIgaXMgMjQ0OGEw
MDAhDQpbICAxNDEuMTYyODcxXSAzNmY0YSBpcyAyNDUyZDAwMCENClsgIDE0MS4xNjQ3ODdd
IDM2ZjQ5IGlzIDI0NTJlMDAwIQ0KWyAgMTQxLjE2Njk0N10gMzkxZjUgaXMgMjQyMDQwMDAh
DQpbICAxNDEuMTY4ODYzXSAzOTFmNiBpcyAyMzRhYjAwMCENClsgIDE0MS4xNzA4MTNdIDM5
MWY3IGlzIDIzNGFjMDAwIQ0KWyAgMTQxLjE3MjcyMl0gMzdhNDAgaXMgMjQxZmQwMDAhDQpb
ICAxNDEuMTc0NjU1XSAzN2E0MSBpcyAyNDFmZTAwMCENClsgIDE0MS4xNzY1ODRdIDM3YTQy
IGlzIDIyYmQxMDAwIQ0KWyAgMTQxLjE3ODUzMF0gMzdhNDMgaXMgMjJiZDIwMDAhDQpbICAx
NDEuMTgwNDc0XSAzN2E0NCBpcyAyMmI3YjAwMCENClsgIDE0MS4xODI0MTZdIDM3YTQ1IGlz
IDIyYjdjMDAwIQ0KWyAgMTQxLjE4NDM0OV0gMzdhNDYgaXMgMjM4N2IwMDAhDQpbICAxNDEu
MTg2MjkyXSAzN2E0NyBpcyAyNDNmYTAwMCENClsgIDE0MS4xODgyNDNdIDM4ZDM4IGlzIDI0
NTEzMDAwIQ0KWyAgMTQxLjE5MDIyOF0gMzhkMzkgaXMgMjQ1MTQwMDAhDQpbICAxNDEuMTky
MTYwXSAzOGQzYSBpcyAyNDRkOTAwMCENClsgIDE0MS4xOTQxMDddIDM5M2Q4IGlzIDIyYTI3
MDAwIQ0KWyAgMTQxLjE5NjA3M10gMzkzZDkgaXMgMjJhMjgwMDAhDQpbICAxNDEuMTk4MDQ0
XSAzOTNkYSBpcyAyMmEwMTAwMCENClsgIDE0MS4xOTk5OThdIDM5M2RiIGlzIDIyYTAyMDAw
IQ0KWyAgMTQxLjIwMTk1Nl0gMzkzZGMgaXMgMjQxZDEwMDAhDQpbICAxNDEuMjAzOTMzXSAz
OTNkZCBpcyAyNDFkMjAwMCENClsgIDE0MS4yMDU5NzJdIDM2NDI5IGlzIDI0M2Y5MDAwIQ0K
WyAgMTQxLjIwODQyMV0gMzkzZGUgaXMgMjQzYmQwMDAhDQpbICAxNDEuMjEwNTI4XSAzNjQy
YSBpcyAyNDNiZTAwMCENClsgIDE0MS4yMTI1MTBdIDM2NDJiIGlzIDIzM2MzMDAwIQ0KWyAg
MTQxLjIxNDQ4NV0gMzY0MmMgaXMgMjMzYzQwMDAhDQpbICAxNDEuMjE3NDI4XSAzNjQyZSBp
cyAyNDRmZTAwMCENClsgIDE0MS4yMTkzNzddIDM2NDJmIGlzIDI0M2UzMDAwIQ0KWyAgMTQx
LjIyMTM0MF0gMzZjMTggaXMgMjQzZTQwMDAhDQpbICAxNDEuMjIzMjcyXSAzNmMxOSBpcyAy
NDIyZDAwMCENClsgIDE0MS4yMjUyNTBdIDM2YzFhIGlzIDI0MjJlMDAwIQ0KWyAgMTQxLjIy
NzE5NV0gMzZjMWIgaXMgMjQyMjEwMDAhDQpbICAxNDEuMjI5MTM5XSAzNmMxYyBpcyAyNDIy
MjAwMCENClsgIDE0MS4yMzEwNTddIDM2YzFkIGlzIDIyYjVmMDAwIQ0KWyAgMTQxLjIzMjk3
N10gMzZjMWUgaXMgMjJiNjAwMDAhDQpbICAxNDEuMjM0OTAwXSAzNmMxZiBpcyAyNDI1OTAw
MCENClsgIDE0MS4yMzY4MTddIDM2ZDMwIGlzIDI0MjVhMDAwIQ0KWyAgMTQxLjI0MDk4OV0g
MzhjOGMgaXMgMjQ0ZWIwMDAhDQpbICAxNDEuMjQyOTgzXSAzOGM4ZCBpcyAyNDRlYzAwMCEN
ClsgIDE0MS4yNDQ5NjJdIDM4YzhlIGlzIDI0MmYxMDAwIQ0KWyAgMTQxLjI0NjkwM10gMzhj
OGYgaXMgMjQyZjIwMDAhDQpbICAxNDEuMjQ4ODQ1XSAzN2MyOCBpcyAyNDJmMzAwMCENClsg
IDE0MS4yNTA3NzldIDM3YzI5IGlzIDI0MmY0MDAwIQ0KWyAgMTQxLjI1MjcwNV0gMzdjMmEg
aXMgMjQ0YmQwMDAhDQpbICAxNDEuMjU0NjE0XSAzN2MyYiBpcyAyNDRiZTAwMCENClsgIDE0
MS4yNTY1MDNdIDM3YzJjIGlzIDI0NGJmMDAwIQ0KWyAgMTQxLjI1ODQxMl0gMzdjMmQgaXMg
MjQ0YzAwMDAhDQpbICAxNDEuMjYwMjkyXSAzN2MyZSBpcyAyNDIxZDAwMCENClsgIDE0MS4y
NjIxODhdIDM2YzBhIGlzIDI0MjFlMDAwIQ0KWyAgMTQxLjI2NDA3Ml0gMzZjMGIgaXMgMjQy
MWYwMDAhDQpbICAxNDEuMjY1OTczXSAzNmMwYyBpcyAyNDIyMDAwMCENClsgIDE0MS4yNjc4
MzRdIDM2YzBkIGlzIDI0NGY1MDAwIQ0KWyAgMTQxLjI2OTc4Ml0gMzZjMGUgaXMgMjQ0ZjYw
MDAhDQpbICAxNDEuMjcxNjMxXSAzNzRlZSBpcyAyNDRmNzAwMCENClsgIDE0MS4yNzM0ODld
IDM3NGVmIGlzIDI0NGY4MDAwIQ0KWyAgMTQxLjI3NTI5OV0gMzhjODggaXMgMjQyNTEwMDAh
DQpbICAxNDEuMjc3MTQzXSAzOGM4OSBpcyAyNDI1MjAwMCENClsgIDE0MS4yNzg5ODddIDM4
YzhhIGlzIDI0MjUzMDAwIQ0KWyAgMTQxLjI4MDgxOF0gMzhjOGIgaXMgMjQyNTQwMDAhDQpb
ICAxNDEuMjgyNjQ1XSAzODNmNCBpcyAyNDQ2ODAwMCENClsgIDE0MS4yODQ0ODJdIDM4M2Y1
IGlzIDI0MzFiMDAwIQ0KWyAgMTQxLjI4NjMyMV0gMzgzZjYgaXMgMjQzMWMwMDAhDQpbICAx
NDEuMjg4MTY0XSAzODNmNyBpcyAyNDI0ZjAwMCENClsgIDE0MS4yOTAwMDRdIDM2YzBmIGlz
IDI0MjUwMDAwIQ0KWyAgMTQxLjI5MTkwM10gM1sgIDE0My40MTgyNDddIDM5Mjk5IGlzIDIz
MzI0MDAwIQ0KWyAgMTQzLjQyMDYwN10gMzkyOWEgaXMgMjMzMjMwMDAhDQpbICAxNDMuNDIy
ODQ1XSAzOTI5YiBpcyAyMzMyMjAwMCENClsgIDE0My40MjUyNTVdIDM5MjljIGlzIDIzMzIx
MDAwIQ0KWyAgMTQzLjQyODgzNV0gMzkyOWQgaXMgMjMzMjAwMDAhDQpbICAxNDMuNDMxMTIz
XSAzOTI5ZSBpcyAyMzMxZjAwMCENClsgIDE0My40MzM4ODVdIDM5MjlmIGlzIDIzMzFlMDAw
IQ0KWyAgMTQzLjQ0NTczMF0gMzhjOTAgaXMgMjMzMWQwMDAhDQpbICAxNDMuNDUzNjQ2XSAz
OGM5MSBpcyAyMzMxYzAwMCENClsgIDE0My40NTU4MTddIDM4YzkyIGlzIDIzMzFiMDAwIQ0K
WyAgMTQzLjQ1ODE0OV0gMzhjOTMgaXMgMjMzMWEwMDAhDQpbICAxNDMuNDYwMzgyXSAzOGM5
NCBpcyAyMzMxOTAwMCENClsgIDE0My40NjI2NTJdIDM3YmVkIGlzIDIzMzE4MDAwIQ0KWyAg
MTQzLjQ3MjYzMl0gMzdiZWUgaXMgMjMzMTcwMDAhDQpbICAxNDMuNDc0ODE1XSAzOGM5NSBp
cyAyMzMxNjAwMCENClsgIDE0My40ODE3OTddIDM3YmVmIGlzIDIzMzE1MDAwIQ0KWyAgMTQz
LjQ4NjI4NF0gMzhjOTYgaXMgMjMzMTQwMDAhDQpbICAxNDMuNDk4OTQ3XSAzOGM5NyBpcyAy
MzMxMzAwMCENClsgIDE0My41MDkzMDNdIDM4Yzk4IGlzIDIzMzEyMDAwIQ0KWyAgMTQzLjUy
NTg3NV0gMzhjOTkgaXMgMjMzMTEwMDAhDQpbICAxNDMuNTI4MjI0XSAzNzU0MCBpcyAyMzMx
MDAwMCENClsgIDE0My41NDQyNzddIDM4YzlhIGlzIDIzMzBmMDAwIQ0KWyAgMTQzLjU0NzEx
Ml0gMzc1NDEgaXMgMjMzMGUwMDAhDQpbICAxNDMuNTYyMjY4XSAzOGM5YiBpcyAyMzMwZDAw
MCENClsgIDE0My41NzMyNTddIDM4YzljIGlzIDIzMzBjMDAwIQ0KWyAgMTQzLjU4MzQ3NF0g
MzhjOWQgaXMgMjMzMGIwMDAhDQpbICAxNDMuNTg1NzE0XSAzOGM5ZSBpcyAyMzMwYTAwMCEN
ClsgIDE0My41OTAyMDRdIDM4YzlmIGlzIDIzMzA5MDAwIQ0KWyAgMTQzLjU5MzkzM10gMzY1
ZTAgaXMgMjMzMDgwMDAhDQpbICAxNDMuNjAyNzQ4XSAzNjVlMSBpcyAyMzMwNzAwMCENClsg
IDE0My42MjY4ODNdIDM2NWUyIGlzIDIzMzA2MDAwIQ0KWyAgMTQzLjYzNDA1OF0gMzc1NDIg
aXMgMjMzMDUwMDAhDQpbICAxNDMuNjYxMDUzXSAzNjVlMyBpcyAyMzIwNDAwMCENClsgIDE0
My42NzI5NDJdIDM3NTQzIGlzIDIzMjAzMDAwIQ0KWyAgMTQzLjY4MjYzMV0gMzc1NDQgaXMg
MjMyMDIwMDAhDQpbICAxNDMuNjg1MDUwXSAzNjVlNCBpcyAyMzIwMTAwMCENClsgIDE0My42
OTA3NzBdIDM2NWU1IGlzIDIzMjAwMDAwIQ0KWyAgMTQzLjY5OTIzNl0gMzY1ZTYgaXMgMjMx
ZDUwMDAhDQpbICAxNDMuNzAyODEwXSAzNzU0NSBpcyAyMzFkNjAwMCENClsgIDE0My43MjYw
MzddIDM2NWU3IGlzIDIzMWQ3MDAwIQ0KWyAgMTQzLjczNDUyMF0gMzc1NDYgaXMgMjMxZDgw
MDAhDQpbICAxNDMuNzQxOTI4XSAzNjVlOCBpcyAyMzFkOTAwMCENClsgIDE0My43NDcyMzVd
IDM2NWU5IGlzIDIzMWRhMDAwIQ0KWyAgMTQzLjc2NjE1MV0gMzY1ZWEgaXMgMjMxZGIwMDAh
DQpbICAxNDMuNzY4NjM0XSAzNzU0NyBpcyAyMzFkYzAwMCENClsgIDE0My43NzUxMTVdIDM2
NWViIGlzIDIzMWRkMDAwIQ0KWyAgMTQzLjc4NTg4NV0gMzY1ZWMgaXMgMjMxZGUwMDAhDQpb
ICAxNDMuNzg4MzczXSAzNjVlZCBpcyAyMzFlNTAwMCENClsgIDE0My43OTIxMzddIDM2NWVl
IGlzIDIzMWZmMDAwIQ0KWyAgMTQzLjc5NTExMV0gMzY1ZWYgaXMgMjMxZjcwMDAhDQpbICAx
NDMuNzk3OTA3XSAzNmNhMCBpcyAyMzFmZTAwMCENClsgIDE0My44MDQ2MTFdIDM2Y2ExIGlz
IDIzMWZkMDAwIQ0KWyAgMTQzLjgxMjQ3NF0gMzZjYTIgaXMgMjMxZjAwMDAhDQpbICAxNDMu
ODIyNDQwXSAzNmNhMyBpcyAyMzFlZjAwMCENClsgIDE0My44MjUyMDddIDM3NTQ4IGlzIDIz
MWVlMDAwIQ0KWyAgMTQzLjgyNzcyOV0gMzZjYTQgaXMgMjMxZWMwMDAhDQpbICAxNDMuODMw
MTI3XSAzNmNhNSBpcyAyMzFlOTAwMCENClsgIDE0My44NDA3MzldIDM2Y2E3IGlzIDIzMWU4
MDAwIQ0KWyAgMTQzLjg1ODkxN10gMzZjYTggaXMgMjMxZWIwMDAhDQpbICAxNDMuODYyNjcz
XSAzNmNhNiBpcyAyMzFkZjAwMCENClsgIDE0My44NjU0NjRdIDM2Y2E5IGlzIDIzMWUwMDAw
IQ0KWyAgMTQzLjg2ODA4MF0gMzZjYWEgaXMgMjMxZTQwMDAhDQpbICAxNDMuODcxOTkzXSAz
NmNhYiBpcyAyMzFlYTAwMCENClsgIDE0My44NzQ0MTJdIDM2Y2FjIGlzIDIzMWYxMDAwIQ0K
WyAgMTQzLjg3Njc5OF0gMzZjYWQgaXMgMjMxZjIwMDAhDQpbICAxNDMuODgwNDEwXSAzNmNh
ZSBpcyAyMzFlNjAwMCENClsgIDE0My44ODM1MDldIDM2Y2FmIGlzIDIzMWU3MDAwIQ0KWyAg
MTQzLjg4NzM1Nl0gMzkxZDAgaXMgMjM0MjYwMDAhDQpbICAxNDMuOTAwOTY2XSAzOTFkMSBp
cyAyMzFmODAwMCENClsgIDE0My45MDMzMDZdIDM5MWQyIGlzIDIzMWY5MDAwIQ0KWyAgMTQz
LjkwNzI2Ml0gMzkxZDMgaXMgMjJhMTYwMDAhDQpbICAxNDMuOTEwNTU2XSAzOTFkNCBpcyAy
MzQzNTAwMCENClsgIDE0My45MTQ4ODFdIDM5MWQ1IGlzIDIyYTE1MDAwIQ0KWyAgMTQzLjkx
NzQ5NF0gMzkxZDYgaXMgMjMxZTMwMDAhDQpbICAxNDMuOTQwNjg4XSAzOTFkNyBpcyAyNDI5
YTAwMCENClsgIDE0My45NDMwMjldIDM3NTQ5IGlzIDIzNDM3MDAwIQ0KWyAgMTQzLjk1NzE1
MV0gMzkxZDggaXMgMjMxZjUwMDAhDQpbICAxNDMuOTU5NTI2XSAzOTFkOSBpcyAyMzFmNDAw
MCENClsgIDE0My45NjMxNjddIDM5MWRhIGlzIDIzMWYzMDAwIQ0KWyAgMTQzLjk2NTY3OV0g
MzkxZGIgaXMgMjMxZDQwMDAhDQpbICAxNDMuOTY4MTY2XSAzOTFkYyBpcyAyMzFkMzAwMCEN
ClsgIDE0My45NzgxNTZdIDM5MWRkIGlzIDIzMWQyMDAwIQ0KWyAgMTQzLjk4ODAyM10gMzkx
ZGUgaXMgMjMxZDEwMDAhDQpbICAxNDQuMDAwMjQ2XSAzOTFkZiBpcyAyMzFkMDAwMCENClsg
IDE0NC4wMDY4NzRdIDM3NGIwIGlzIDIzMWNmMDAwIQ0KWyAgMTQ0LjAwOTI2Nl0gMzc0YjEg
aXMgMjMxY2UwMDAhDQpbICAxNDQuMDExODE2XSAzNzRiMiBpcyAyMzFjZDAwMCENClsgIDE0
NC4wMjE1ODRdIDM3NGIzIGlzIDIzMWNjMDAwIQ0KWyAgMTQ0LjAyNDI0NV0gMzc0YjQgaXMg
MjMxY2IwMDAhDQpbICAxNDQuMDI2NTg4XSAzNzRiNSBpcyAyMzFjYTAwMCENClsgIDE0NC4w
MjkxMTZdIDM3NGI2IGlzIDIzMWM5MDAwIQ0KWyAgMTQ0LjAzMTU1N10gMzc0YjcgaXMgMjMx
YzgwMDAhDQpbICAxNDQuMDM0MDIwXSAzNzRiOCBpcyAyMzFjNzAwMCENClsgIDE0NC4wNDU5
MzddIDM3NGI5IGlzIDIzMWM2MDAwIQ0KWyAgMTQ0LjA0ODM4NF0gMzc0YmEgaXMgMjMxYzUw
MDAhDQpbICAxNDQuMDUyMTEwXSAzNzRiYiBpcyAyMzFjNDAwMCENClsgIDE0NC4wNTQ1Njhd
IDM3NGJjIGlzIDIzMWMzMDAwIQ0KWyAgMTQ0LjA2MjIzNV0gMzc0YmQgaXMgMjMxYzIwMDAh
DQpbICAxNDQuMDgxNDMzXSAzNzU0YSBpcyAyMzFjMTAwMCENClsgIDE0NC4wODU2MzRdIDM3
NTRiIGlzIDIzMWMwMDAwIQ0KWyAgMTQ0LjA5NDQ3N10gMzc0YmUgaXMgMjMxYmYwMDAhDQpb
ICAxNDQuMTExOTUwXSAzNzU0YyBpcyAyMzFiZTAwMCENClsgIDE0NC4xMjMzNDJdIDM3NGJm
IGlzIDIzMWIzMDAwIQ0KWyAgMTQ0LjEyNTQ1Ml0gMzkxODAgaXMgMjMxYjQwMDAhDQpbICAx
NDQuMTI3NDQwXSAzOTE4MSBpcyAyMzFiNTAwMCENClsgIDE0NC4xMjkzNTVdIDM5MTgyIGlz
IDIzMWI2MDAwIQ0KWyAgMTQ0LjEzMTIxMF0gMzkxODMgaXMgMjMxYjcwMDAhDQpbICAxNDQu
MTMzMDI5XSAzOTE4NCBpcyAyMzFiODAwMCENClsgIDE0NC4xMzQ4MjFdIDM5MTg1IGlzIDIz
MWI5MDAwIQ0KWyAgMTQ0LjEzNjU5OV0gMzkxODYgaXMgMjMxYmEwMDAhDQpbICAxNDQuMTM4
Mzc0XSAzOTE4NyBpcyAyMzFiYjAwMCENClsgIDE0NC4xNDAxNjBdIDM5MTg4IGlzIDIzMWJj
MDAwIQ0KWyAgMTQ0LjE0MTkxOV0gMzkxODkgaXMgMjMxYmQwMDAhDQpbICAxNDQuMTQ0MTc3
XSAzOGM0ZiBpcyAyMzE5MzAwMCENClsgIDE0NC4xNDU5ODNdIDM2NTcwIGlzIDIzMTk0MDAw
IQ0KWyAgMTQ0LjE0Nzc5N10gMzY1NzEgaXMgMjMxOTUwMDAhDQpbICAxNDQuMTQ5NTg4XSAz
NjU3MiBpcyAyMzE5NjAwMCENClsgIDE0NC4xNTEzNjldIDM2NTczIGlzIDIzMTk3MDAwIQ0K
WyAgMTQ0LjE1MzE1Nl0gMzY1NzQgaXMgMjMxOTgwMDAhDQpbICAxNDQuMTU0OTQxXSAzNjU3
NSBpcyAyMzE5OTAwMCENClsgIDE0NC4xNTY3NDRdIDM2NTc2IGlzIDIzMTlhMDAwIQ0KWyAg
MTQ0LjE1ODUwOF0gMzY1NzcgaXMgMjMxOWIwMDAhDQpbICAxNDQuMTYwMjg3XSAzNjU3OCBp
cyAyMzE5YzAwMCENClsgIDE0NC4xNjIwNjldIDM2NTc5IGlzIDIzMTlkMDAwIQ0KWyAgMTQ0
LjE2Mzg0OF0gMzY1N2EgaXMgMjMxODgwMDAhDQpbICAxNDQuMTY1NjI5XSAzNjU3YiBpcyAy
MzE4OTAwMCENClsgIDE0NC4xNjc0MDhdIDM2NTdjIGlzIDIzMThhMDAwIQ0KWyAgMTQ0LjE2
OTE4NV0gMzY1N2QgaXMgMjMxOGIwMDAhDQpbICAxNDQuMTcwOTU5XSAzNjU3ZSBpcyAyMzE4
YzAwMCENClsgIDE0NC4xNzI3MThdIDM2NTdmIGlzIDIzMThkMDAwIQ0KWyAgMTQ0LjE3NDQ5
Nl0gMzc2MTAgaXMgMjMxOGUwMDAhDQpbICAxNDQuMTc2MjY2XSAzNzYxMSBpcyAyMzE4ZjAw
MCENClsgIDE0NC4xNzgwMzldIDM3NjEyIGlzIDIzMTkwMDAwIQ0KWyAgMTQ0LjE3OTc2M10g
Mzc2MTMgaXMgMjMxOTEwMDAhDQpbICAxNDQuMTgxNDk5XSAzNzYxNCBpcyAyMzE5MjAwMCEN
ClsgIDE0NC4xODMyMDFdIDM3NjE2IGlzIDIzOGZlMDAwIQ0KWyAgMTQ0LjE4NDkzNV0gMzc2
MTcgaXMgMjM4ZmYwMDAhDQpbICAxNDQuMTg2NjY5XSAzNzYxOCBpcyAyMzkwMDAwMCENClsg
IDE0NC4xODg0MDhdIDM3NjE5IGlzIDIzOTAxMDAwIQ0KWyAgMTQ0LjE5MDE2M10gMzc2MWEg
aXMgMjM5MDIwMDAhDQpbICAxNDQuMTkxOTAwXSAzNzYxYiBpcyAyMzkwMzAwMCENClsgIDE0
NC4xOTM2NTFdIDM3NjFjIGlzIDIzOTA0MDAwIQ0KWyAgMTQ0LjE5NTQwM10gMzc2MWQgaXMg
MjMxODUwMDAhDQpbICAxNDQuMTk3MTU5XSAzNzYxZSBpcyAyMzE4NjAwMCENClsgIDE0NC4x
OTg5MTddIDM3NjFmIGlzIDIzMTg3MDAwIQ0KWyAgMTQ0LjIwMDY1MV0gMzkxOGEgaXMgMjMx
YTgwMDAhDQpbICAxNDQuMjAyNDAzXSAzOTE4YiBpcyAyMzFhOTAwMCENClsgIDE0NC4yMDQx
NTNdIDM5MThjIGlzIDIzMWFhMDAwIQ0KWyAgMTQ0LjIwNTg4M10gMzkxOGQgaXMgMjMxYWIw
MDAhDQpbICAxNDQuMjA3NjMxXSAzOTE4ZSBpcyAyMzFhYzAwMCENClsgIDE0NC4yMDkzNTBd
IDM5MThmIGlzIDIzMWFkMDAwIQ0KWyAgMTQ0LjIxMTEwMF0gMzhjNDAgaXMgMjMxYWUwMDAh
DQpbICAxNDQuMjEyODQyXSAzOGM0MSBpcyAyMzFhZjAwMCENClsgIDE0NC4yMTQ2MTNdIDM4
YzQyIGlzIDIzMWIwMDAwIQ0KWyAgMTQ0LjIxNjM1NF0gMzhjNDMgaXMgMjMxYjEwMDAhDQpb
ICAxNDQuMjE4MTExXSAzOGM0NCBpcyAyMzFiMjAwMCENClsgIDE0NC4yMTk4NjNdIDM4YzQ1
IGlzIDIzMTllMDAwIQ0KWyAgMTQ0LjIyMTYyMF0gMzhjNDYgaXMgMjMxOWYwMDAhDQpbICAx
NDQuMjIzMzk5XSAzOGM0NyBpcyAyMzFhMDAwMCENClsgIDE0NC4yMjUxNTJdIDM4YzQ4IGlz
IDIzMWExMDAwIQ0KWyAgMTQ0LjIyNjkxM10gMzhjNDkgaXMgMjMxYTIwMDAhDQpbICAxNDQu
MjI4Njc3XSAzOGM0YSBpcyAyMzFhMzAwMCENClsgIDE0NC4yMzA0MjFdIDM4YzRiIGlzIDIz
MWE0MDAwIQ0KWyAgMTQ0LjIzMjE4MF0gMzhjNGMgaXMgMjMxYTUwMDAhDQpbICAxNDQuMjMz
OTI4XSAzOGM0ZCBpcyAyMzFhNjAwMCENClsgIDE0NC4yMzU2ODBdIDM4YzRlIGlzIDIzMWE3
MDAwIQ0KWyAgMTQ0LjIzODc0M10gMzY1Y2IgaXMgMjM4ZTgwMDAhDQpbICAxNDQuMjQwNjAy
XSAzNjVjYyBpcyAyMzhlOTAwMCENClsgIDE0NC4yNDIzODVdIDM2NWNkIGlzIDIzOGVhMDAw
IQ0KWyAgMTQ0LjI0NDE3NV0gMzY1Y2UgaXMgMjM4ZWIwMDAhDQpbICAxNDQuMjQ1OTIzXSAz
NjVjZiBpcyAyMzhlYzAwMCENClsgIDE0NC4yNDc2NzZdIDM4Y2UwIGlzIDIzOGVkMDAwIQ0K
WyAgMTQ0LjI0OTQ2NV0gMzhjZTEgaXMgMjM4ZWUwMDAhDQpbICAxNDQuMjUxMjM1XSAzOGNl
MiBpcyAyMzhlZjAwMCENClsgIDE0NC4yNTI5OTBdIDM4Y2UzIGlzIDIzOGYwMDAwIQ0KWyAg
MTQ0LjI1NDc1NF0gMzhjZTQgaXMgMjM4ZjEwMDAhDQpbICAxNDQuMjU2NTE1XSAzOGNlNSBp
cyAyMzhmMjAwMCENClsgIDE0NC4yNTg3NDhdIDM4Y2U2IGlzIDIzOGRlMDAwIQ0KWyAgMTQ0
LjI2MDUyM10gMzhjZTcgaXMgMjM4ZGYwMDAhDQpbICAxNDQuMjYyMjU0XSAzOGNlOCBpcyAy
MzhlMDAwMCENClsgIDE0NC4yNjQwMTRdIDM4Y2U5IGlzIDIzOGUxMDAwIQ0KWyAgMTQ0LjI2
NTc2NF0gMzhjZWEgaXMgMjM4ZTIwMDAhDQpbICAxNDQuMjY3NTExXSAzOGNlYiBpcyAyMzhl
MzAwMCENClsgIDE0NC4yNjkyNzldIDM4Y2VjIGlzIDIzOGU0MDAwIQ0KWyAgMTQ0LjI3MTAw
OV0gMzhjZWQgaXMgMjM4ZTUwMDAhDQpbICAxNDQuMjcyNzEzXSAzOGNlZSBpcyAyMzhlNjAw
MCENClsgIDE0NC4yNzQ0NTJdIDM4Y2VmIGlzIDIzOGU3MDAwIQ0KWyAgMTQ0LjI3NjE1N10g
MzZmYWIgaXMgMjM4YzgwMDAhDQpbICAxNDQuMjc3OTA3XSAzNmZhYyBpcyAyMzhjOTAwMCEN
ClsgIDE0NC4yNzk2MTJdIDM2ZmFkIGlzIDIzOGNhMDAwIQ0KWyAgMTQ0LjI4MTM0NV0gMzZm
YWUgaXMgMjM4Y2IwMDAhDQpbICAxNDQuMjgzMDQ5XSAzNmZhZiBpcyAyMzhjYzAwMCENClsg
IDE0NC4yODQ3NjddIDM2ZmIwIGlzIDIzOGNkMDAwIQ0KWyAgMTQ0LjI4NjQ4OF0gMzZmYjEg
aXMgMjM4Y2UwMDAhDQpbICAxNDQuMjg4MjA1XSAzNmZiMiBpcyAyMzhjZjAwMCENClsgIDE0
NC4yODk5MjddIDM2ZmIzIGlzIDIzOGQwMDAwIQ0KWyAgMTQ0LjI5MTY0NF0gMzZmYjQgaXMg
MjM4ZDEwMDAhDQpbICAxNDQuMjkzMzUxXSAzNmZiNSBpcyAyMzhkMjAwMCENClsgIDE0NC4y
OTUwNjBdIDM2ZmEwIGlzIDIzOGQzMDAwIQ0KWyAgMTQ0LjI5Njc1M10gMzZmYTEgaXMgMjM4
ZDQwMDAhDQpbICAxNDQuMjk4NDQ4XSAzNmZhMiBpcyAyMzhkNTAwMCENClsgIDE0NC4zMDAx
NDZdIDM2ZmEzIGlzIDIzOGQ2MDAwIQ0KWyAgMTQ0LjMwMTgzN10gMzZmYTQgaXMgMjM4ZDcw
MDAhDQpbICAxNDQuMzAzNTQxXSAzNmZhNSBpcyAyMzhkODAwMCENClsgIDE0NC4zMDUyMTRd
IDM2ZmE2IGlzIDIzOGQ5MDAwIQ0KWyAgMTQ0LjMwNjkxNl0gMzZmYTcgaXMgMjM4ZGEwMDAh
DQpbICAxNDQuMzA4NTc3XSAzNmZhOCBpcyAyMzhkYjAwMCENClsgIDE0NC4zMTAyNjddIDM2
ZmE5IGlzIDIzOGRjMDAwIQ0KWyAgMTQ0LjMxMTkzMF0gMzZmYWEgaXMgMjM4ZGQwMDAhDQpb
ICAxNDQuMzEzNjAwXSAzNmZiNiBpcyAyMzhiZTAwMCENClsgIDE0NC4zMTUyNzJdIDM2ZmI3
IGlzIDIzOGJmMDAwIQ0KWyAgMTQ0LjMxNjkzNF0gMzZmYjggaXMgMjM4YzAwMDAhDQpbICAx
NDQuMzE4NjEwXSAzNmZiOSBpcyAyMzhjMTAwMCENClsgIDE0NC4zMjAyOTFdIDM2ZmJhIGlz
IDIzOGMyMDAwIQ0KWyAgMTQ0LjMyMTk2NF0gMzZmYmIgaXMgMjM4YzMwMDAhDQpbICAxNDQu
MzIzNjY3XSAzNmZiYyBpcyAyMzhjNDAwMCENClsgIDE0NC4zMjUzMzRdIDM2ZmJkIGlzIDIz
OGM1MDAwIQ0KWyAgMTQ0LjMyNzAzMF0gMzZmYmUgaXMgMjM4YzYwMDAhDQpbICAxNDQuMzI4
NjkyXSAzNmZiZiBpcyAyMzhjNzAwMCENClsgIDE0NC4zMzAzNDldIDM2NWMwIGlzIDIzOGYz
MDAwIQ0KWyAgMTQ0LjMzMjAzOF0gMzY1YzEgaXMgMjM4ZjQwMDAhDQpbICAxNDQuMzMzNzI1
XSAzNjVjMiBpcyAyMzhmNTAwMCENClsgIDE0NC4zMzU0MDZdIDM2NWMzIGlzIDIzOGY2MDAw
IQ0KWyAgMTQ0LjMzNzA5M10gMzY1YzQgaXMgMjM4ZjcwMDAhDQpbICAxNDQuMzM4NzYwXSAz
NjVjNSBpcyAyMzhmODAwMCENClsgIDE0NC4zNDA0NTddIDM2NWM2IGlzIDIzOGY5MDAwIQ0K
WyAgMTQ0LjM0MjEzMl0gMzY1YzcgaXMgMjM4ZmEwMDAhDQpbICAxNDQuMzQzODc0XSAzNjVj
OCBpcyAyMzhmYjAwMCENClsgIDE0NC4zNDU1MzVdIDM2NWM5IGlzIDIzOGZjMDAwIQ0KWyAg
MTQ0LjM0NzIxMl0gMzY1Y2EgaXMgMjM4ZmQwMDAhDQpbICAxNDQuMzU0MjE1XSAzODJkNyBp
cyAyMzhiZDAwMCENClsgIDE0NC4zNjY1NDVdIDM4Y2MwIGlzIDIzOGJjMDAwIQ0KWyAgMTQ0
LjM3NjUwM10gMzhjYzEgaXMgMjM4YmIwMDAhDQpbICAxNDQuMzg0MDA1XSAzOGNjMiBpcyAy
MzhiYTAwMCENClsgIDE0NC4zODYxMjFdIDM4Y2MzIGlzIDIzOGI5MDAwIQ0KWyAgMTQ0LjM4
ODM5MF0gMzhjYzQgaXMgMjM4YjgwMDAhDQpbICAxNDQuMzkwNjEwXSAzOGNjNSBpcyAyMzhi
NzAwMCENClsgIDE0NC4zOTI3MTNdIDM4Y2M2IGlzIDIzOGI2MDAwIQ0KWyAgMTQ0LjM5NDk5
Nl0gMzhjYzcgaXMgMjM4YjUwMDAhDQpbICAxNDQuMzk3MTExXSAzOGNjOCBpcyAyMzhiNDAw
MCENClsgIDE0NC4zOTkyMzBdIDM4Y2M5IGlzIDIzOGIzMDAwIQ0KWyAgMTQ0LjQwMTQ5Ml0g
MzhjY2EgaXMgMjM4YjIwMDAhDQpbICAxNDQuNDAzNjAzXSAzOGNjYiBpcyAyMzhiMTAwMCEN
ClsgIDE0NC40MDU2NzZdIDM4Y2NjIGlzIDIzOGIwMDAwIQ0KWyAgMTQ0LjQwNzgwNV0gMzc1
NGQgaXMgMjM4YWYwMDAhDQpbICAxNDQuNDA5OTA1XSAzOGNjZCBpcyAyMzhhZTAwMCENClsg
IDE0NC40MTIwNDFdIDM4Y2NmIGlzIDIzOGFkMDAwIQ0KWyAgMTQ0LjQxNzUxM10gMzhjZDAg
aXMgMjM4YWMwMDAhDQpbICAxNDQuNDI3MzExXSAzOGNkMSBpcyAyMzhhYjAwMCENClsgIDE0
NC40MzQ5MzldIDM2NjAzIGlzIDIzOGFhMDAwIQ0KWyAgMTQ0LjQ0MzQ1M10gMzY2MDQgaXMg
MjM4YTkwMDAhDQpbICAxNDQuNDQ1NTM0XSAzOGNkMiBpcyAyMzhhODAwMCENClsgIDE0NC40
NTUwNzddIDM4Y2QzIGlzIDIzOGE3MDAwIQ0KWyAgMTQ0LjQ1NzM0OV0gMzhjZDQgaXMgMjM4
YTYwMDAhDQpbICAxNDQuNDU5NTA3XSAzOGNkNSBpcyAyMzhhNTAwMCENClsgIDE0NC40NjE4
NDldIDM4Y2Q2IGlzIDIzOGE0MDAwIQ0KWyAgMTQ0LjQ2NDA5OF0gMzhjZDcgaXMgMjM4YTMw
MDAhDQpbICAxNDQuNDcxNTc5XSAzOGNkOCBpcyAyMzhhMjAwMCENClsgIDE0NC40NzY1MjJd
IDM4Y2Q5IGlzIDIzOGExMDAwIQ0KWyAgMTQ0LjQ5MjQ5OV0gMzhjZGEgaXMgMjM4YTAwMDAh
DQpbICAxNDQuNTA2NjI2XSAzNjYwNSBpcyAyMzg5ZjAwMCENClsgIDE0NC41MDg5MzRdIDM4
Y2RiIGlzIDIzODllMDAwIQ0KWyAgMTQ0LjUxNjU4OV0gMzhjZGMgaXMgMjM4OWQwMDAhDQpb
ICAxNDQuNTIzNDkwXSAzOGNkZCBpcyAyMzg5YzAwMCENClsgIDE0NC41MzcyNjBdIDM4Y2Rl
IGlzIDIzODliMDAwIQ0KWyAgMTQ0LjUzOTQ5Ml0gMzY2MDYgaXMgMjM4OWEwMDAhDQpbICAx
NDQuNTQzMjcwXSAzOGNkZiBpcyAyMzg5OTAwMCENClsgIDE0NC41NDU2MjFdIDM2NjAwIGlz
IDIzODk4MDAwIQ0KWyAgMTQ0LjU1MzI4Nl0gMzY2MDEgaXMgMjM4OTcwMDAhDQpbICAxNDQu
NTY4MTYwXSAzNjYwMiBpcyAyMzg5NjAwMCENClsgIDE0NC41NzIwMzBdIDM2NjIyIGlzIDIz
ODk1MDAwIQ0KWyAgMTQ0LjU3NDk1MV0gMzY2MjMgaXMgMjM4OTQwMDAhDQpbICAxNDQuNTk1
NTM3XSAzNjYyNCBpcyAyMzg5MzAwMCENClsgIDE0NC42MDE3MDhdIDM2NjA3IGlzIDIzODky
MDAwIQ0KWyAgMTQ0LjYwNDY5Nl0gMzY2MjUgaXMgMjM4OTEwMDAhDQpbICAxNDQuNjExMjAw
XSAzNjYyNiBpcyAyMzg5MDAwMCENClsgIDE0NC42MTc5MjVdIDM2NjI3IGlzIDIzODhmMDAw
IQ0KWyAgMTQ0LjYyNDY3NF0gMzY2MjggaXMgMjM4OGUwMDAhDQpbICAxNDQuNjI2OTg1XSAz
NjYyOSBpcyAyMzg4ZDAwMCENClsgIDE0NC42MjkyMjNdIDM2NjJhIGlzIDIzODhjMDAwIQ0K
WyAgMTQ0LjYzMTU1NF0gMzY2MDggaXMgMjM4OGIwMDAhDQpbICAxNDQuNjMzODI1XSAzNjYy
YiBpcyAyMzg4YTAwMCENClsgIDE0NC42MzYxMzRdIDM2NjA5IGlzIDIzODg5MDAwIQ0KWyAg
MTQ0LjYzODM5M10gMzY2MmMgaXMgMjM4ODgwMDAhDQpbICAxNDQuNjQwNjcyXSAzNjYwYSBp
cyAyMzg4NzAwMCENClsgIDE0NC42NDI5NzNdIDM2NjBiIGlzIDIzODg2MDAwIQ0KWyAgMTQ0
LjY0NTMyNl0gMzY2MmQgaXMgMjM4ODUwMDAhDQpbICAxNDQuNjQ3Njg5XSAzNjYyZSBpcyAy
NDkwNDAwMCENClsgIDE0NC42NDk5NzldIDM2NjJmIGlzIDI0OTAzMDAwIQ0KWyAgMTQ0LjY1
MjI5OF0gMzY2MzAgaXMgMjQ5MDIwMDAhDQpbICAxNDQuNjU0NjM0XSAzNjYzMSBpcyAyNDkw
MTAwMCENClsgIDE0NC42NTY5MjZdIDM2NjMyIGlzIDI0OTAwMDAwIQ0KWyAgMTQ0LjY1OTE0
Nl0gMzY2MzMgaXMgMjQ4ZmYwMDAhDQpbICAxNDQuNjYxNDI1XSAzNjYwYyBpcyAyNDhmZTAw
MCENClsgIDE0NC43MDI2NDJdIDM2NjM0IGlzIDI0OGZkMDAwIQ0KWyAgMTQ0LjcwNTIyOF0g
MzY2MGQgaXMgMjQ4YmUwMDAhDQpbICAxNDQuNzIwMTAxXSAzNjYwZSBpcyAyNDhiZjAwMCEN
ClsgIDE0NC43MjI1MDZdIDM2NjBmIGlzIDI0OGMwMDAwIQ0KWyAgMTQ0LjcyNDc0OF0gMzY2
MTAgaXMgMjQ4YzEwMDAhDQpbICAxNDQuNzQxMTQxXSAzNjYzNSBpcyAyNDhjMjAwMCENClsg
IDE0NC43NTU1MDddIDM2NjExIGlzIDI0OGMzMDAwIQ0KWyAgMTQ0Ljc3OTAzNF0gMzY2MzYg
aXMgMjQ4YzQwMDAhDQpbICAxNDQuNzgxNDI3XSAzNjYxMiBpcyAyNDhjODAwMCENClsgIDE0
NC43ODMyNzJdIDM2NjM3IGlzIDI0OGM3MDAwIQ0KWyAgMTQ0Ljc4NTE0MV0gMzY2MzggaXMg
MjQ4YzYwMDAhDQpbICAxNDQuNzg3MDY1XSAzNjYzOSBpcyAyNDhjNTAwMCENClsgIDE0NC44
MjcwMTFdIDM2NjNhIGlzIDI0OGM5MDAwIQ0KWyAgMTQ0Ljg2NzM0N10gMzY2M2IgaXMgMjQ4
Y2EwMDAhDQpbICAxNDQuODc2ODQwXSAzNjYzYyBpcyAyNDhjYjAwMCENClsgIDE0NC44ODU0
NjddIDM3OGNjIGlzIDI0OGNjMDAwIQ0KWyAgMTQ0Ljg5MDI5N10gMzY2M2QgaXMgMjQ4Y2Qw
MDAhDQpbICAxNDQuOTAwMjM3XSAzNjYzZSBpcyAyNDhjZTAwMCENClsgIDE0NC45MDMzMDdd
IDM2NjNmIGlzIDI0OGNmMDAwIQ0KWyAgMTQ0LjkwNTY3Nl0gMzY2NDAgaXMgMjQ4ZDAwMDAh
DQpbICAxNDQuOTE0MDcxXSAzNjY0MSBpcyAyNDhkMTAwMCENClsgIDE0NC45MjUwNzNdIDM2
NjQyIGlzIDI0OGQyMDAwIQ0KWyAgMTQ0LjkzMDU5OF0gMzY2NDMgaXMgMjQ4ZDMwMDAhDQpb
ICAxNDQuOTMyNzk2XSAzNjY0NCBpcyAyNDhkNDAwMCENClsgIDE0NC45MzY5NDZdIDM2NjQ1
IGlzIDI0OGQ1MDAwIQ0KWyAgMTQ0Ljk0NzExNl0gMzY2NDYgaXMgMjQ4ZDYwMDAhDQpbICAx
NDQuOTU0NTg4XSAzOTNlZSBpcyAyNDhkNzAwMCENClsgIDE0NC45NjA2NDNdIDM2NjQ4IGlz
IDI0OGQ4MDAwIQ0KWyAgMTQ0Ljk4MjEyOV0gMzY2NDkgaXMgMjQ4ZDkwMDAhDQpbICAxNDQu
OTg0NDgzXSAzNjYxMyBpcyAyNDhlODAwMCENClsgIDE0NC45ODYzMDddIDM2NjRhIGlzIDI0
OGY3MDAwIQ0KWyAgMTQ0Ljk4ODEzOF0gMzY2NGIgaXMgMjQ4ZGIwMDAhDQpbICAxNDQuOTg5
OTUyXSAzNjY0YyBpcyAyNDhkYTAwMCENClsgIDE0NS4wMDQ2MjNdIDM2NjE0IGlzIDI0OGU5
MDAwIQ0KWyAgMTQ1LjAxNTI3OF0gMzY2MTUgaXMgMjQ4ZTcwMDAhDQpbICAxNDUuMDE3NDk1
XSAzNjY0ZCBpcyAyNDhlNjAwMCENClsgIDE0NS4wMTk3MTBdIDM2NjRlIGlzIDI0OGVjMDAw
IQ0KWyAgMTQ1LjAyMjEwNV0gMzY2NGYgaXMgMjQ4ZWQwMDAhDQpbICAxNDUuMDI0MzkwXSAz
NjY1MCBpcyAyNDhlZTAwMCENClsgIDE0NS4wMzQyNDVdIDM2NjUxIGlzIDI0OGVmMDAwIQ0K
WyAgMTQ1LjAzNjQ0Ml0gMzY2NTIgaXMgMjQ4ZjEwMDAhDQpbICAxNDUuMDM4Nzk0XSAzNjY1
NCBpcyAyNDhmMzAwMCENClsgIDE0NS4wNDA5NzZdIDM2NjU1IGlzIDI0OGY0MDAwIQ0KWyAg
MTQ1LjA0MzE2MV0gMzY2NTYgaXMgMjQ4ZjIwMDAhDQpbICAxNDUuMDQ1NDk5XSAzNjY1NyBp
cyAyNDhkYzAwMCENClsgIDE0NS4wNDc4MDJdIDM2NjU4IGlzIDI0OGZjMDAwIQ0KWyAgMTQ1
LjA1NDYzNF0gMzY2NTkgaXMgMjQ4ZjgwMDAhDQpbICAxNDUuMDcwMzg3XSAzNjY1YSBpcyAy
NDhlYjAwMCENClsgIDE0NS4wNzcwNTldIDM2NjViIGlzIDI0OGVhMDAwIQ0KWyAgMTQ1LjA3
OTg5Nl0gMzY2NWMgaXMgMjQ4ZjYwMDAhDQpbICAxNDUuMDg0NDkyXSAzNjY1ZCBpcyAyNDhm
NTAwMCENClsgIDE0NS4wOTM3MjFdIDM2NjVlIGlzIDIzMWVkMDAwIQ0KWyAgMTQ1LjEwMzE0
OF0gMzY2NWYgaXMgMjQ4ZTEwMDAhDQpbICAxNDUuMTA1NDA1XSAzNjY2MCBpcyAyNDhlMjAw
MCENClsgIDE0NS4xMDg1MTJdIDM2NjYxIGlzIDI0M2I0MDAwIQ0KWyAgMTQ1LjExOTkwMF0g
MzY2NjIgaXMgMjMxZmEwMDAhDQpbICAxNDUuMTI3MzQ3XSAzNjYxNiBpcyAyNDI2YzAwMCEN
ClsgIDE0NS4xMzE1ODBdIDM2NjYzIGlzIDI0OGY5MDAwIQ0KWyAgMTQ1LjE0MzA2NF0gMzY2
NjQgaXMgMjMxZmMwMDAhDQpbICAxNDUuMTQ5MDYwXSAzNjY2NSBpcyAyMzFmYjAwMCENClsg
IDE0NS4xNTg2MDhdIDM2NjY2IGlzIDI0OGJkMDAwIQ0KWyAgMTQ1LjE2ODQ0MF0gMzY2Njcg
aXMgMjQ4ZTAwMDAhDQpbICAxNDUuMTc3NzE5XSAzNjY2OCBpcyAyNDhkZjAwMCENClsgIDE0
NS4xODE0NjBdIDM2NjY5IGlzIDI0OGRlMDAwIQ0KWyAgMTQ1LjE5MDUwN10gMzY2NmEgaXMg
MjQ4ZGQwMDAhDQpbICAxNDUuMTk3NzI5XSAzNjY2YiBpcyAyNDhiYzAwMCENClsgIDE0NS4y
MDAxODFdIDM2NjZjIGlzIDI0OGJiMDAwIQ0KWyAgMTQ1LjIwMjY4M10gMzY2NmQgaXMgMjQ4
YmEwMDAhDQpbICAxNDUuMjA5MDE5XSAzNjY2ZSBpcyAyNDhiOTAwMCENClsgIDE0NS4yMTEy
OTRdIDM2NjE3IGlzIDI0OGI4MDAwIQ0KWyAgMTQ1LjIxMzYwNl0gMzY2MTggaXMgMjQ4Yjcw
MDAhDQpbICAxNDUuMjE3ODE2XSAzNjY2ZiBpcyAyNDhiNjAwMCENClsgIDE0NS4yMjIzOTRd
IDM2NjE5IGlzIDI0OGI1MDAwIQ0KWyAgMTQ1LjIzNzQ2M10gMzY2NzAgaXMgMjQ4YjQwMDAh
DQpbICAxNDUuMjQ1NjEzXSAzNjY3MSBpcyAyNDhiMzAwMCENClsgIDE0NS4yNjAxOTNdIDM2
NjcyIGlzIDI0OGIyMDAwIQ0KWyAgMTQ1LjI4MTM3N10gMzY2NzMgaXMgMjQ4YjEwMDAhDQpb
ICAxNDUuMjgzNjA3XSAzNjYxYSBpcyAyNDhiMDAwMCENClsgIDE0NS4yODYwMDNdIDM2Njc0
IGlzIDI0OGFmMDAwIQ0KWyAgMTQ1LjI4ODI5MF0gMzY2MWIgaXMgMjQ4YWUwMDAhDQpbICAx
NDUuMjkwNTg4XSAzNjY3NSBpcyAyNDhhZDAwMCENClsgIDE0NS4yOTI4OThdIDM2NjFjIGlz
IDI0OGFjMDAwIQ0KWyAgMTQ1LjI5NTE4N10gMzY2NzYgaXMgMjQ4YWIwMDAhDQpbICAxNDUu
MzAwOTI0XSAzNjYxZCBpcyAyNDhhYTAwMCENClsgIDE0NS4zMDMyMDVdIDM2NjFlIGlzIDI0
OGE5MDAwIQ0KWyAgMTQ1LjMxNDg4NF0gMzY2NzcgaXMgMjQ4YTgwMDAhDQpbICAxNDUuMzMw
MjczXSAzNjYxZiBpcyAyNDhhNzAwMCENClsgIDE0NS4zMzI1MjddIDM2NjIwIGlzIDI0OGE2
MDAwIQ0KWyAgMTQ1LjMzNjU0Nl0gMzY2NzggaXMgMjQ4YTUwMDAhDQpbICAxNDUuMzQwMjM0
XSAzNjYyMSBpcyAyNDhhNDAwMCENClsgIDE0NS4zNDMxNThdIDM2NjdmIGlzIDI0OGEzMDAw
IQ0KWyAgMTQ1LjM0NjgyNV0gMzY2NzkgaXMgMjQ4YTIwMDAhDQpbICAxNDUuMzQ5MDQzXSAz
NjY4MCBpcyAyNDhhMTAwMCENClsgIDE0NS4zNTYyOTBdIDM2NjdhIGlzIDI0OGEwMDAwIQ0K
WyAgMTQ1LjM2Njc3MF0gMzY2ODEgaXMgMjQ4OWYwMDAhDQpbICAxNDUuMzcwNDg4XSAzNjY4
MiBpcyAyNDg5ZTAwMCENClsgIDE0NS4zNzc0NDhdIDM2NjgzIGlzIDI0ODlkMDAwIQ0KWyAg
MTQ1LjM4MDgyMV0gMzY2N2IgaXMgMjQ4OWMwMDAhDQpbICAxNDUuMzkxMjIyXSAzNjY3YyBp
cyAyNDg5YjAwMCENClsgIDE0NS4zOTUwNjhdIDM2NjdkIGlzIDI0ODlhMDAwIQ0KWyAgMTQ1
LjQwODQwMV0gMzY2N2UgaXMgMjQ4OTkwMDAhDQpbICAxNDUuNDExNzQwXSAzNjY4NCBpcyAy
NDg5ODAwMCENClsgIDE0NS40MTYyODRdIDM2NjllIGlzIDI0ODk3MDAwIQ0KWyAgMTQ1LjQx
ODk4OV0gMzY2OWYgaXMgMjQ4OTYwMDAhDQpbICAxNDUuNDI2NTEzXSAzNjZhMCBpcyAyNDg5
NTAwMCENClsgIDE0NS40MzEwNzBdIDM2NmExIGlzIDI0ODk0MDAwIQ0KWyAgMTQ1LjQzNTMx
Nl0gMzY2YTIgaXMgMjQ4OTMwMDAhDQpbICAxNDUuNDM4NjUzXSAzNjZhMyBpcyAyNDg5MjAw
MCENClsgIDE0NS40NDEyMTBdIDM2NmE0IGlzIDI0ODkxMDAwIQ0KWyAgMTQ1LjQ0NDQ1N10g
MzY2YTYgaXMgMjQ4OTAwMDAhDQpbICAxNDUuNDUwMjU2XSAzNjZhNyBpcyAyNDg4ZjAwMCEN
ClsgIDE0NS40NTc4MjJdIDM2NmE4IGlzIDI0ODhlMDAwIQ0KWyAgMTQ1LjQ4MjE2NV0gMzY2
YTkgaXMgMjQ4OGQwMDAhDQpbICAxNDUuNDg0NzI2XSAzNjY4NSBpcyAyNDg4OTAwMCENClsg
IDE0NS40ODY1MjFdIDM2NmFhIGlzIDI0ODhhMDAwIQ0KWyAgMTQ1LjQ4ODMyMF0gMzY2YWIg
aXMgMjQ4OGIwMDAhDQpbICAxNDUuNDkwMTAwXSAzNjZhYyBpcyAyNDg4YzAwMCENClsgIDE0
NS41MDkxODddIDM2NmFkIGlzIDI0ODg4MDAwIQ0KWyAgMTQ1LjUxNzYwOF0gMzY2ODYgaXMg
MjQ4ODcwMDAhDQpbICAxNDUuNTI4MDIyXSAzNjZhZSBpcyAyNDg4NjAwMCENClsgIDE0NS41
MzIwMDldIDM2NmFmIGlzIDI0ODg1MDAwIQ0KWyAgMTQ1LjU0MDgxMl0gMzY2YjAgaXMgMjQ4
ODQwMDAhDQpbICAxNDUuNTUzMDQyXSAzNjZiMSBpcyAyNDg4MzAwMCENClsgIDE0NS41NjM1
MDRdIDM2NmIyIGlzIDI0ODgyMDAwIQ0KWyAgMTQ1LjU2NzYzNF0gMzY2YjMgaXMgMjQ4ODEw
MDAhDQpbICAxNDUuNTc1MjM0XSAzNjZiNCBpcyAyNDg4MDAwMCENClsgIDE0NS41NzkwNDNd
IDM2NmI1IGlzIDI0ODdmMDAwIQ0KWyAgMTQ1LjU5NDkyNF0gMzY2YjYgaXMgMjQ4N2UwMDAh
DQpbICAxNDUuNTk3MDg3XSAzNjY4NyBpcyAyNDg3ZDAwMCENClsgIDE0NS41OTkyMTZdIDM2
NmI3IGlzIDI0ODdjMDAwIQ0KWyAgMTQ1LjYxNDg1N10gMzY2YjggaXMgMjQ4N2IwMDAhDQpb
ICAxNDUuNjIxNDg1XSAzNjZiOSBpcyAyNDg3YTAwMCENClsgIDE0NS42MjUzNTZdIDM2NmJh
IGlzIDI0ODc5MDAwIQ0KWyAgMTQ1LjYzMDc5NF0gMzY2YmIgaXMgMjQ4NzgwMDAhDQpbICAx
NDUuNjQzNTgxXSAzNjZiYyBpcyAyNDg3NzAwMCENClsgIDE0NS42NDc5OTZdIDM2NmJkIGlz
IDI0ODc2MDAwIQ0KWyAgMTQ1LjY1MTE4M10gMzY2YmUgaXMgMjQ4NzUwMDAhDQpbICAxNDUu
NjY2MDMyXSAzNjZiZiBpcyAyNDg3NDAwMCENClsgIDE0NS42Njg1OTFdIDM2Njg4IGlzIDI0
ODczMDAwIQ0KWyAgMTQ1LjY3MTY1Nl0gMzY2YzAgaXMgMjQ4NzIwMDAhDQpbICAxNDUuNjcz
OTE2XSAzNjZjMSBpcyAyNDg3MTAwMCENClsgIDE0NS42NzYwNTNdIDM2NmMyIGlzIDI0ODcw
MDAwIQ0KWyAgMTQ1LjY3OTg5OV0gMzY2YzMgaXMgMjQ4NmYwMDAhDQpbICAxNDUuNjgyMTM3
XSAzNjZjNCBpcyAyNDg2ZTAwMCENClsgIDE0NS42ODUyMjFdIDM2NmM1IGlzIDI0ODZkMDAw
IQ0KWyAgMTQ1LjY4Nzk2MF0gMzY2YzYgaXMgMjQ4NmMwMDAhDQpbICAxNDUuNjkxNDA0XSAz
NjZjNyBpcyAyNDg2YjAwMCENClsgIDE0NS42OTQ2MzJdIDM2NmM4IGlzIDI0ODZhMDAwIQ0K
WyAgMTQ1LjY5NzM3Ml0gMzY2YzkgaXMgMjQ4NjkwMDAhDQpbICAxNDUuNzAwNzA5XSAzNjZj
YSBpcyAyNDg2ODAwMCENClsgIDE0NS43MDI4MzldIDM2Njg5IGlzIDI0ODY3MDAwIQ0KWyAg
MTQ1LjcwNTEyMl0gMzY2Y2IgaXMgMjQ4NjYwMDAhDQpbICAxNDUuNzE4NzI3XSAzNjZjYyBp
cyAyNDg2NTAwMCENClsgIDE0NS43MjA5NTJdIDM2NjhhIGlzIDI0ODQ0MDAwIQ0KWyAgMTQ1
LjcyNTYxNV0gMzY2Y2QgaXMgMjQ4NDUwMDAhDQpbICAxNDUuNzI3ODUxXSAzNjZjZSBpcyAy
NDg0YzAwMCENClsgIDE0NS43MzAwMzBdIDM2NmNmIGlzIDI0ODViMDAwIQ0KWyAgMTQ1Ljcz
NDEzNF0gMzY2ZDAgaXMgMjQ4NWEwMDAhDQpbICAxNDUuNzM3NzQ5XSAzNjZkMSBpcyAyNDg1
YzAwMCENClsgIDE0NS43Mzk5MDNdIDM2NmQyIGlzIDI0ODVkMDAwIQ0KWyAgMTQ1Ljc0Mjky
MF0gMzY2ZDMgaXMgMjQ4NTcwMDAhDQpbICAxNDUuNzQ1MTU0XSAzNjZkNCBpcyAyNDg1NjAw
MCENClsgIDE0NS43NDc0MDhdIDM2NmQ1IGlzIDI0ODU1MDAwIQ0KWyAgMTQ1Ljc1NTk0OF0g
MzY2ZDYgaXMgMjQ4NTQwMDAhDQpbICAxNDUuNzU4NjExXSAzNjZkNyBpcyAyNDg1MjAwMCEN
ClsgIDE0NS43NjE3NjBdIDM2NmQ4IGlzIDI0ODU4MDAwIQ0KWyAgMTQ1Ljc2Mzk5NV0gMzY2
ZDkgaXMgMjQ4NGYwMDAhDQpbICAxNDUuNzY5MTkwXSAzNjZkYSBpcyAyNDg1MTAwMCENClsg
IDE0NS43NzE0MzNdIDM2NmRiIGlzIDI0ODQ2MDAwIQ0KWyAgMTQ1Ljc3MzYwMl0gMzY2ZGMg
aXMgMjQ4NDcwMDAhDQpbICAxNDUuNzc1ODM5XSAzNjZkZCBpcyAyNDg1MDAwMCENClsgIDE0
NS43Nzg4NzZdIDM2NjhiIGlzIDI0ODRiMDAwIQ0KWyAgMTQ1Ljc4MTAxNV0gMzY2ZGUgaXMg
MjQ4NTkwMDAhDQpbICAxNDUuNzk3NDMyXSAzNjY4YyBpcyAyNDg0ZDAwMCENClsgIDE0NS43
OTk1ODhdIDM2NjhkIGlzIDI0ODRlMDAwIQ0KWyAgMTQ1LjgwMjc1M10gMzY2ZGYgaXMgMjQ4
ZjAwMDAhDQpbICAxNDUuODA1MDk4XSAzNjZlMCBpcyAyNDg2MjAwMCENClsgIDE0NS44MDg0
NjldIDM2NmUxIGlzIDI0ODYxMDAwIQ0KWyAgMTQ1LjgxMjc5OF0gMzY2ZTIgaXMgMjQzOGQw
MDAhDQpbICAxNDUuODE1MTE0XSAzNjZlMyBpcyAyNDhlMzAwMCENClsgIDE0NS44MTg5Njld
IDM2NmU0IGlzIDI0NGM5MDAwIQ0KWyAgMTQ1LjgyMTI5Nl0gMzY2ZTUgaXMgMjQ4NGEwMDAh
DQpbICAxNDUuODIzNTY1XSAzNjZlNiBpcyAyNDRjMjAwMCENClsgIDE0NS44MjkxODRdIDM2
NmU3IGlzIDI0ODQzMDAwIQ0KWyAgMTQ1LjgzMjY4MV0gMzY2ZTggaXMgMjQ4NjQwMDAhDQpb
ICAxNDUuODM5MDU5XSAzNjY4ZSBpcyAyNDg2MzAwMCENClsgIDE0NS44NDEzMTVdIDM2Njhm
IGlzIDI0ODQyMDAwIQ0KWyAgMTQ1Ljg0NDAzMF0gMzY2OTAgaXMgMjQ4NDEwMDAhDQpbICAx
NDUuODQ3MzA4XSAzNjZlOSBpcyAyNDg0MDAwMCENClsgIDE0NS44NDk1NjJdIDM2NmVhIGlz
IDI0ODNmMDAwIQ0KWyAgMTQ1Ljg1MjA5MV0gMzY2ZWIgaXMgMjQ4M2UwMDAhDQpbICAxNDUu
ODU0NDc3XSAzNjZlYyBpcyAyNDgzZDAwMCENClsgIDE0NS44NTc4OTVdIDM2NmVkIGlzIDI0
ODNjMDAwIQ0KWyAgMTQ1Ljg2MDE4M10gMzY2ZWUgaXMgMjQ4M2IwMDAhDQpbICAxNDUuODY0
MDI0XSAzWyAgMTQ3Ljk5MzU3M10gMzM0ZTIgaXMgMjQ4NWUwMDAhDQpbICAxNDcuOTk3NzE2
XSAzMzRlMyBpcyAyNDczMTAwMCENClsgIDE0OC4wMDE5ODddIDMzNGU0IGlzIDI0NjUyMDAw
IQ0KWyAgMTQ4LjAwNDQxMV0gMzM0ZTUgaXMgMjQ2NTEwMDAhDQpbICAxNDguMDA2ODY4XSAz
MzRlNiBpcyAyNDY1MDAwMCENClsgIDE0OC4wMTcwNzBdIDMzNGU3IGlzIDI0NjRmMDAwIQ0K
WyAgMTQ4LjAyMDIwNl0gMzM0ZTggaXMgMjQ2MzAwMDAhDQpbICAxNDguMDIyNzUxXSAzMzRl
OSBpcyAyNDYyZjAwMCENClsgIDE0OC4wMzMzNjFdIDM2N2FjIGlzIDI0NjJlMDAwIQ0KWyAg
MTQ4LjAzNjYzMF0gMzM0ZWEgaXMgMjQ2MmQwMDAhDQpbICAxNDguMDM5MjQyXSAzNjdhZCBp
cyAyNDYyYzAwMCENClsgIDE0OC4wNDIxMjVdIDM2N2FlIGlzIDI0NjJiMDAwIQ0KWyAgMTQ4
LjA0NDU4Ml0gMzY3YWYgaXMgMjQ2MmEwMDAhDQpbICAxNDguMDQ3ODYzXSAzNjdiMCBpcyAy
NDYyOTAwMCENClsgIDE0OC4wNTAzNjldIDMzNGViIGlzIDI0NjI4MDAwIQ0KWyAgMTQ4LjA1
Mjg2Ml0gMzM0ZWMgaXMgMjQ2MjcwMDAhDQpbICAxNDguMDU2Mjg3XSAzMzRlZCBpcyAyNDYy
NjAwMCENClsgIDE0OC4wNTg5OTBdIDMzNGVlIGlzIDI0NjI1MDAwIQ0KWyAgMTQ4LjA2MTQ0
OV0gMzM0ZWYgaXMgMjQ2MjQwMDAhDQpbICAxNDguMDY2MDYwXSAzMzRmMCBpcyAyNDYyMzAw
MCENClsgIDE0OC4wNjg1MDBdIDMzNGYxIGlzIDI0NjIyMDAwIQ0KWyAgMTQ4LjA3MDkyMl0g
MzM0ZjIgaXMgMjQ2MjEwMDAhDQpbICAxNDguMDgxMzIyXSAzMzRmMyBpcyAyNDYyMDAwMCEN
ClsgIDE0OC4wODU4NzNdIDMzNGY0IGlzIDI0NjFmMDAwIQ0KWyAgMTQ4LjA5MzEwOF0gMzM0
ZjUgaXMgMjQ2MWUwMDAhDQpbICAxNDguMDk5MzM3XSAzNjdiMSBpcyAyNDYxZDAwMCENClsg
IDE0OC4xMTMxMDVdIDMzNGY2IGlzIDI0NjFjMDAwIQ0KWyAgMTQ4LjEyNzI3OF0gMzY3YjIg
aXMgMjQ2MWIwMDAhDQpbICAxNDguMTI5Njg1XSAzNjdiMyBpcyAyNDYxYTAwMCENClsgIDE0
OC4xNDAwMDddIDMzNGY3IGlzIDI0NjE5MDAwIQ0KWyAgMTQ4LjE0NzI3OF0gMzY3YjQgaXMg
MjQ2MTgwMDAhDQpbICAxNDguMTU3NDg5XSAzMzUwMCBpcyAyNDYxNzAwMCENClsgIDE0OC4x
NjQwMjldIDMzNGY4IGlzIDI0NjE2MDAwIQ0KWyAgMTQ4LjE3MTk2MV0gMzM0ZjkgaXMgMjQ2
MTUwMDAhDQpbICAxNDguMTc2Njk3XSAzMzRmYSBpcyAyNDYxNDAwMCENClsgIDE0OC4xODY4
MzddIDMzNGZiIGlzIDI0NjEzMDAwIQ0KWyAgMTQ4LjE5NDAxNF0gMzM0ZmMgaXMgMjQ2MGIw
MDAhDQpbICAxNDguMTk1OTI3XSAzMzUwMSBpcyAyNDYwYzAwMCENClsgIDE0OC4xOTc4MzNd
IDMzNTAyIGlzIDI0NjBkMDAwIQ0KWyAgMTQ4LjE5OTcxMF0gMzM1MDMgaXMgMjQ2MGUwMDAh
DQpbICAxNDguMjAxNjExXSAzMzUwNCBpcyAyNDYwZjAwMCENClsgIDE0OC4yMDM0NzldIDMz
NTA1IGlzIDI0NjEwMDAwIQ0KWyAgMTQ4LjIwNTMzM10gMzM1MDYgaXMgMjQ2MTEwMDAhDQpb
ICAxNDguMjA3MTgzXSAzMzUwNyBpcyAyNDYxMjAwMCENClsgIDE0OC4yMTUyMDZdIDMzNTA4
IGlzIDI0NjBhMDAwIQ0KWyAgMTQ4LjIxOTYxNV0gMzM0ZmQgaXMgMjQ2MDkwMDAhDQpbICAx
NDguMjIyOTIxXSAzMzUyOCBpcyAyNDVmMzAwMCENClsgIDE0OC4yMjQ4NDNdIDMzNTI5IGlz
IDI0NWY0MDAwIQ0KWyAgMTQ4LjIyNjczOF0gMzM1MmEgaXMgMjQ1ZjUwMDAhDQpbICAxNDgu
MjI4NTk4XSAzMzUyYiBpcyAyNDVmNjAwMCENClsgIDE0OC4yMzA0ODVdIDMzNTJjIGlzIDI0
NWY3MDAwIQ0KWyAgMTQ4LjIzMjMzNV0gMzM1MmQgaXMgMjQ1ZjgwMDAhDQpbICAxNDguMjM0
MjE4XSAzMzUyZSBpcyAyNDVmOTAwMCENClsgIDE0OC4yMzYwNjFdIDMzNTJmIGlzIDI0NWZh
MDAwIQ0KWyAgMTQ4LjIzNzk0NF0gMzM1MzAgaXMgMjQ1ZmIwMDAhDQpbICAxNDguMjM5Nzkz
XSAzMzUzMSBpcyAyNDVmYzAwMCENClsgIDE0OC4yNDE2NzZdIDMzNTMyIGlzIDI0NWZkMDAw
IQ0KWyAgMTQ4LjI0NDA4N10gMzM1MzQgaXMgMjQ1ZTkwMDAhDQpbICAxNDguMjQ1OTE3XSAz
MzUzNSBpcyAyNDVlYTAwMCENClsgIDE0OC4yNDc3MjVdIDMzNTM2IGlzIDI0NWViMDAwIQ0K
WyAgMTQ4LjI0OTU1Nl0gMzM1MzcgaXMgMjQ1ZWMwMDAhDQpbICAxNDguMjUxMzU1XSAzMzUz
OCBpcyAyNDVlZDAwMCENClsgIDE0OC4yNTMwOTddIDMzNTM5IGlzIDI0NWVlMDAwIQ0KWyAg
MTQ4LjI1NDg1OV0gMzM1M2EgaXMgMjQ1ZWYwMDAhDQpbICAxNDguMjU2NTY5XSAzMzUzYiBp
cyAyNDVmMDAwMCENClsgIDE0OC4yNTgzMDddIDMzNTNjIGlzIDI0NWYxMDAwIQ0KWyAgMTQ4
LjI2MDAxMl0gMzM1M2QgaXMgMjQ1ZjIwMDAhDQpbICAxNDguMjYxNzQ2XSAzMzUzZiBpcyAy
NDVkYzAwMCENClsgIDE0OC4yNjM0OTRdIDMzNTQwIGlzIDI0NWRkMDAwIQ0KWyAgMTQ4LjI2
NTE5OF0gMzM1NDEgaXMgMjQ1ZGUwMDAhDQpbICAxNDguMjY2OTMxXSAzMzU0MiBpcyAyNDVk
ZjAwMCENClsgIDE0OC4yNjg2MzJdIDMzNTQzIGlzIDI0NWUwMDAwIQ0KWyAgMTQ4LjI3MDM3
OV0gMzM1NDQgaXMgMjQ1ZTEwMDAhDQpbICAxNDguMjcyMDg1XSAzMzU0NSBpcyAyNDVlMjAw
MCENClsgIDE0OC4yNzM3ODldIDMzNTQ2IGlzIDI0NWUzMDAwIQ0KWyAgMTQ4LjI3NTQ5Nl0g
MzM1NDcgaXMgMjQ1ZTQwMDAhDQpbICAxNDguMjc3MTg4XSAzMzU0OCBpcyAyNDVlNTAwMCEN
ClsgIDE0OC4yNzg4NjldIDMzNTQ5IGlzIDI0NWU2MDAwIQ0KWyAgMTQ4LjI4MDUyMV0gMzM1
M2UgaXMgMjQ1ZTcwMDAhDQpbICAxNDguMjgyMTcyXSAzMzU1NSBpcyAyNDVjYTAwMCENClsg
IDE0OC4yODM4NjNdIDMzNTU2IGlzIDI0NWNiMDAwIQ0KWyAgMTQ4LjI4NTUzMF0gMzM1NTcg
aXMgMjQ1Y2MwMDAhDQpbICAxNDguMjg3MjE5XSAzMzU1OCBpcyAyNDVjZDAwMCENClsgIDE0
OC4yODg4ODZdIDMzNTU5IGlzIDI0NWNlMDAwIQ0KWyAgMTQ4LjI5MDU2Nl0gMzM1NWEgaXMg
MjQ1Y2YwMDAhDQpbICAxNDguMjkyMjUwXSAzMzU1YiBpcyAyNDVkMDAwMCENClsgIDE0OC4y
OTM5MzFdIDMzNTRhIGlzIDI0NWQxMDAwIQ0KWyAgMTQ4LjI5NTYxN10gMzM1NGIgaXMgMjQ1
ZDIwMDAhDQpbICAxNDguMjk3Mjk4XSAzMzU0YyBpcyAyNDVkMzAwMCENClsgIDE0OC4yOTg5
NTldIDMzNTRkIGlzIDI0NWQ0MDAwIQ0KWyAgMTQ4LjMwMDY1Nl0gMzM1NGUgaXMgMjQ1ZDUw
MDAhDQpbICAxNDguMzAyMzI5XSAzMzU0ZiBpcyAyNDVkNjAwMCENClsgIDE0OC4zMDQwMzFd
IDMzNTUwIGlzIDI0NWQ3MDAwIQ0KWyAgMTQ4LjMwNTcwOV0gMzM1NTEgaXMgMjQ1ZDgwMDAh
DQpbICAxNDguMzA3NDAwXSAzMzU1MiBpcyAyNDVkOTAwMCENClsgIDE0OC4zMDkwODldIDMz
NTUzIGlzIDI0NWRhMDAwIQ0KWyAgMTQ4LjMxMDc3NV0gMzM1NTQgaXMgMjQ1ZGIwMDAhDQpb
ICAxNDguMzEyNDcwXSAzMzRmZSBpcyAyNDVmZTAwMCENClsgIDE0OC4zMTQxNjhdIDMzNGZm
IGlzIDI0NWZmMDAwIQ0KWyAgMTQ4LjMxNTg0N10gMzM1MWYgaXMgMjQ2MDAwMDAhDQpbICAx
NDguMzE3NTY3XSAzMzUyMCBpcyAyNDYwMTAwMCENClsgIDE0OC4zMTkyNjJdIDMzNTIxIGlz
IDI0NjAyMDAwIQ0KWyAgMTQ4LjMyMDk4Ml0gMzM1MjIgaXMgMjQ2MDMwMDAhDQpbICAxNDgu
MzIyNjczXSAzMzUyMyBpcyAyNDYwNDAwMCENClsgIDE0OC4zMjQzNzBdIDMzNTI0IGlzIDI0
NjA1MDAwIQ0KWyAgMTQ4LjMyNjA2NV0gMzM1MjUgaXMgMjQ2MDYwMDAhDQpbICAxNDguMzI3
NzYzXSAzMzUyNiBpcyAyNDYwNzAwMCENClsgIDE0OC4zMjk0NThdIDMzNTI3IGlzIDI0NjA4
MDAwIQ0KWyAgMTQ4LjMzMTI1NV0gMzM1MzMgaXMgMjQ1YzkwMDAhDQpbICAxNDguMzMzNzk5
XSAzMzUwYSBpcyAyNDViZjAwMCENClsgIDE0OC4zMzU1NTRdIDMzNTBiIGlzIDI0NWMwMDAw
IQ0KWyAgMTQ4LjMzNzI4Ml0gMzM1MGMgaXMgMjQ1YzEwMDAhDQpbICAxNDguMzM5MDA0XSAz
MzUwZCBpcyAyNDVjMjAwMCENClsgIDE0OC4zNDA3MTBdIDMzNTBlIGlzIDI0NWMzMDAwIQ0K
WyAgMTQ4LjM0MjQyM10gMzM1MGYgaXMgMjQ1YzQwMDAhDQpbICAxNDguMzQ0MTgxXSAzMzUx
MCBpcyAyNDVjNTAwMCENClsgIDE0OC4zNDU4OTldIDMzNTExIGlzIDI0NWM2MDAwIQ0KWyAg
MTQ4LjM0NzYxMF0gMzM1MTIgaXMgMjQ1YzcwMDAhDQpbICAxNDguMzQ5MzAxXSAzMzUxMyBp
cyAyNDVjODAwMCENClsgIDE0OC4zNTEzMDRdIDMzNTA5IGlzIDI0NWE4MDAwIQ0KWyAgMTQ4
LjM1MzAyMF0gMzM1MTQgaXMgMjQ1YjMwMDAhDQpbICAxNDguMzU0NzY5XSAzMzUxNSBpcyAy
NDViNDAwMCENClsgIDE0OC4zNTY0NzddIDMzNTE2IGlzIDI0NWI1MDAwIQ0KWyAgMTQ4LjM1
ODIxOF0gMzM1MTcgaXMgMjQ1YjYwMDAhDQpbICAxNDguMzU5OTIwXSAzMzUxOCBpcyAyNDVi
NzAwMCENClsgIDE0OC4zNjE2MzNdIDMzNTE5IGlzIDI0NWI4MDAwIQ0KWyAgMTQ4LjM2MzM5
Ml0gMzM1MWEgaXMgMjQ1YjkwMDAhDQpbICAxNDguMzY1MTA1XSAzMzUxYiBpcyAyNDViYTAw
MCENClsgIDE0OC4zNjY4MzhdIDMzNTFjIGlzIDI0NWJiMDAwIQ0KWyAgMTQ4LjM2ODUzM10g
MzM1MWQgaXMgMjQ1YmMwMDAhDQpbICAxNDguMzcwMjQ0XSAzMzUxZSBpcyAyNDViZDAwMCEN
ClsgIDE0OC4zNzE5MzBdIDMzNTVkIGlzIDI0NWE5MDAwIQ0KWyAgMTQ4LjM3MzYyMl0gMzM1
NWUgaXMgMjQ1YWEwMDAhDQpbICAxNDguMzc1MzIyXSAzMzU1ZiBpcyAyNDVhYjAwMCENClsg
IDE0OC4zNzcwMDldIDMzNTYwIGlzIDI0NWFjMDAwIQ0KWyAgMTQ4LjM3ODcwMl0gMzM1NjEg
aXMgMjQ1YWQwMDAhDQpbICAxNDguMzgwMzk0XSAzMzU2MiBpcyAyNDVhZTAwMCENClsgIDE0
OC4zODIwNzldIDMzNTYzIGlzIDI0NWFmMDAwIQ0KWyAgMTQ4LjM4MzgwMF0gMzM1NjQgaXMg
MjQ1YjAwMDAhDQpbICAxNDguMzg1NDk2XSAzMzU2NSBpcyAyNDViMTAwMCENClsgIDE0OC4z
ODcyMDNdIDMzNTY2IGlzIDI0NWIyMDAwIQ0KWyAgMTQ4LjM4OTI1N10gMzM1NjcgaXMgMjQ1
YTcwMDAhDQpbICAxNDguMzkxNzczXSAzMzU2OCBpcyAyNDU5YzAwMCENClsgIDE0OC4zOTM0
NjldIDMzNTVjIGlzIDI0NTlkMDAwIQ0KWyAgMTQ4LjM5NTE0OF0gMzM1N2MgaXMgMjQ1OWUw
MDAhDQpbICAxNDguMzk2ODUzXSAzMzU3ZCBpcyAyNDU5ZjAwMCENClsgIDE0OC4zOTg1MzJd
IDMzNTdlIGlzIDI0NWEwMDAwIQ0KWyAgMTQ4LjQwMDIzNl0gMzM1N2YgaXMgMjQ1YTEwMDAh
DQpbICAxNDguNDAxOTE2XSAzMzU4MCBpcyAyNDVhMjAwMCENClsgIDE0OC40MDM2MDldIDMz
NTgxIGlzIDI0NWEzMDAwIQ0KWyAgMTQ4LjQwNTMwMV0gMzM1ODIgaXMgMjQ1YTQwMDAhDQpb
ICAxNDguNDA2OTg3XSAzMzU4MyBpcyAyNDVhNTAwMCENClsgIDE0OC40MDg2NjZdIDMzNTg0
IGlzIDI0NWE2MDAwIQ0KWyAgMTQ4LjQxMDYyNV0gMzM1OTAgaXMgMjQ1OGEwMDAhDQpbICAx
NDguNDEyMzU1XSAzMzU5MSBpcyAyNDU4YjAwMCENClsgIDE0OC40MTQwNjldIDMzNTkyIGlz
IDI0NThjMDAwIQ0KWyAgMTQ4LjQxNTc0OF0gMzM1OTMgaXMgMjQ1OGQwMDAhDQpbICAxNDgu
NDE3NDY1XSAzMzU5NCBpcyAyNDU4ZTAwMCENClsgIDE0OC40MTkxMzhdIDMzNTk1IGlzIDI0
NThmMDAwIQ0KWyAgMTQ4LjQyMDg0Nl0gMzM1OTYgaXMgMjQ1OTAwMDAhDQpbICAxNDguNDIy
NTMwXSAzMzU5NyBpcyAyNDU4OTAwMCENClsgIDE0OC40MjQyMzhdIDMzNTk4IGlzIDI0NTg4
MDAwIQ0KWyAgMTQ4LjQyNTkzOF0gMzM1ODUgaXMgMjQ1OTEwMDAhDQpbICAxNDguNDI3NjI4
XSAzMzU4NiBpcyAyNDU5MjAwMCENClsgIDE0OC40MjkzMjhdIDMzNTg3IGlzIDI0NTkzMDAw
IQ0KWyAgMTQ4LjQzMDk5OF0gMzM1ODggaXMgMjQ1OTQwMDAhDQpbICAxNDguNDMyNjQ3XSAz
MzU4OSBpcyAyNDU5NTAwMCENClsgIDE0OC40MzQzMzNdIDMzNThhIGlzIDI0NTk2MDAwIQ0K
WyAgMTQ4LjQzNTk4Ml0gMzM1OGIgaXMgMjQ1OTcwMDAhDQpbICAxNDguNDM3NjYzXSAzMzU4
YyBpcyAyNDU5ODAwMCENClsgIDE0OC40MzkzMDZdIDMzNThkIGlzIDI0NTk5MDAwIQ0KWyAg
MTQ4LjQ0MDk2NF0gMzM1OGUgaXMgMjQ1OWEwMDAhDQpbICAxNDguNDQyNjMwXSAzMzU4ZiBp
cyAyNDU5YjAwMCENClsgIDE0OC40NTg1MzBdIDMzNTk5IGlzIDI0ZDdkMDAwIQ0KWyAgMTQ4
LjQ2MDI2NV0gMzM1OWEgaXMgMjRkN2UwMDAhDQpbICAxNDguNDYxOTY5XSAzMzU5YiBpcyAy
NGQ3ZjAwMCENClsgIDE0OC40NjM2MzFdIDMzNTljIGlzIDI0ZDgwMDAwIQ0KWyAgMTQ4LjQ2
NTI4MV0gMzM1OWQgaXMgMjRkODEwMDAhDQpbICAxNDguNDY2OTUxXSAzMzU5ZSBpcyAyNGQ4
MjAwMCENClsgIDE0OC40Njg1NzhdIDMzNTlmIGlzIDI0ZDgzMDAwIQ0KWyAgMTQ4LjQ3MDI0
N10gMzM1YTAgaXMgMjRkODQwMDAhDQpbICAxNDguNDcxODg4XSAzMzVhMSBpcyAyNDU4NTAw
MCENClsgIDE0OC40NzM1NjBdIDMzNWEyIGlzIDI0NTg2MDAwIQ0KWyAgMTQ4LjQ3NTIyOV0g
MzM1YTMgaXMgMjQ1ODcwMDAhDQpbICAxNDguNDc3MTc5XSAzMzViOSBpcyAyNGQ2NzAwMCEN
ClsgIDE0OC40Nzg4NDddIDMzNWE0IGlzIDI0ZDcyMDAwIQ0KWyAgMTQ4LjQ4MDU0M10gMzM1
YTUgaXMgMjRkNzMwMDAhDQpbICAxNDguNDgyMjA5XSAzMzVhNiBpcyAyNGQ3NDAwMCENClsg
IDE0OC40ODM5MDldIDMzNWE3IGlzIDI0ZDc1MDAwIQ0KWyAgMTQ4LjQ4NTU2Ml0gMzM1YTgg
aXMgMjRkNzYwMDAhDQpbICAxNDguNDg3MjUwXSAzMzVhOSBpcyAyNGQ3NzAwMCENClsgIDE0
OC40ODg4OTJdIDMzNWFhIGlzIDI0ZDc4MDAwIQ0KWyAgMTQ4LjQ5MDU0Nl0gMzM1YWIgaXMg
MjRkNzkwMDAhDQpbICAxNDguNDkyMjExXSAzMzVhYyBpcyAyNGQ3YTAwMCENClsgIDE0OC40
OTM4NzddIDMzNWFkIGlzIDI0ZDdiMDAwIQ0KWyAgMTQ4LjQ5NTU0Nl0gMzM1YWUgaXMgMjRk
N2MwMDAhDQpbICAxNDguNDk3MjI5XSAzMzVhZiBpcyAyNGQ2ODAwMCENClsgIDE0OC40OTg4
OTldIDMzNWIwIGlzIDI0ZDY5MDAwIQ0KWyAgMTQ4LjUwMDYwNF0gMzM1YjEgaXMgMjRkNmEw
MDAhDQpbICAxNDguNTAyMjg2XSAzMzViMiBpcyAyNGQ2YjAwMCENClsgIDE0OC41MDQwMDNd
IDMzNWIzIGlzIDI0ZDZjMDAwIQ0KWyAgMTQ4LjUwNTY4NF0gMzM1YjQgaXMgMjRkNmQwMDAh
DQpbICAxNDguNTA3Mzg1XSAzMzViNSBpcyAyNGQ2ZTAwMCENClsgIDE0OC41MDkwNzddIDMz
NWI2IGlzIDI0ZDZmMDAwIQ0KWyAgMTQ4LjUxMDc1OV0gMzM1YjcgaXMgMjRkNzAwMDAhDQpb
ICAxNDguNTEyNDQ0XSAzMzViOCBpcyAyNGQ3MTAwMCENClsgIDE0OC41MTU3MTFdIDMzNTcz
IGlzIDI0ZDUxMDAwIQ0KWyAgMTQ4LjUxNzU2Ml0gMzM1NzQgaXMgMjRkNTIwMDAhDQpbICAx
NDguNTE5MjUwXSAzMzU3NSBpcyAyNGQ1MzAwMCENClsgIDE0OC41MjA5NzRdIDMzNTc2IGlz
IDI0ZDU0MDAwIQ0KWyAgMTQ4LjUyMjY3OV0gMzM1NzcgaXMgMjRkNTUwMDAhDQpbICAxNDgu
NTI0NDA0XSAzMzU3OCBpcyAyNGQ1NjAwMCENClsgIDE0OC41MjYwODBdIDMzNTc5IGlzIDI0
ZDU3MDAwIQ0KWyAgMTQ4LjUyNzc2Ml0gMzM1N2EgaXMgMjRkNTgwMDAhDQpbICAxNDguNTI5
NDYzXSAzMzU3YiBpcyAyNGQ1OTAwMCENClsgIDE0OC41MzExNDBdIDMzNWQ5IGlzIDI0ZDVh
MDAwIQ0KWyAgMTQ4LjUzMjgxOV0gMzM1ZGEgaXMgMjRkNWIwMDAhDQpbICAxNDguNTM0NDkx
XSAzMzVkYiBpcyAyNGQ0NzAwMCENClsgIDE0OC41MzYxNDldIDMzNWRjIGlzIDI0ZDQ4MDAw
IQ0KWyAgMTQ4LjUzNzg0MV0gMzM1ZGQgaXMgMjRkNDkwMDAhDQpbICAxNDguNTM5NTA1XSAz
MzVkZSBpcyAyNGQ0YTAwMCENClsgIDE0OC41NDEyMDJdIDMzNWRmIGlzIDI0ZDRiMDAwIQ0K
WyAgMTQ4LjU0Mjg2Nl0gMzM1ZTAgaXMgMjRkNGMwMDAhDQpbICAxNDguNTQ0NTU3XSAzMzVl
MSBpcyAyNGQ0ZDAwMCENClsgIDE0OC41NDYyMzhdIDMzNWUyIGlzIDI0ZDRlMDAwIQ0KWyAg
MTQ4LjU0NzkyMF0gMzM1ZTMgaXMgMjRkNGYwMDAhDQpbICAxNDguNTQ5NjA3XSAzMzVlNCBp
cyAyNGQ1MDAwMCENClsgIDE0OC41NTI5MjhdIDMzNWY5IGlzIDI0ZDA3MDAwIQ0KWyAgMTQ4
LjU1NDczMV0gMzM1ZjggaXMgMjRkMDgwMDAhDQpbICAxNDguNTU2NDE0XSAzMzVmNyBpcyAy
NGQwOTAwMCENClsgIDE0OC41NTgxMTZdIDMzNWY2IGlzIDI0ZDBhMDAwIQ0KWyAgMTQ4LjU1
OTc3N10gMzM1ZjUgaXMgMjRkMGIwMDAhDQpbICAxNDguNTYxNDU1XSAzMzVmNCBpcyAyNGQw
YzAwMCENClsgIDE0OC41NjMxMzhdIDMzNWYzIGlzIDI0ZDBkMDAwIQ0KWyAgMTQ4LjU2NDgy
N10gMzM1ZjIgaXMgMjRkMGUwMDAhDQpbICAxNDguNTY2NTE2XSAzMzVmMSBpcyAyNGQwZjAw
MCENClsgIDE0OC41NjgxOTBdIDMzNWYwIGlzIDI0ZDEwMDAwIQ0KWyAgMTQ4LjU2OTg1N10g
MzM1ZWYgaXMgMjRkMTEwMDAhDQpbICAxNDguNTcxNTU0XSAzMzVlZSBpcyAyNGQxMjAwMCEN
ClsgIDE0OC41NzMyMjBdIDMzNWVkIGlzIDI0ZDEzMDAwIQ0KWyAgMTQ4LjU3NDkxOF0gMzM1
ZWMgaXMgMjRkMTQwMDAhDQpbICAxNDguNTc2NTc5XSAzMzVlYiBpcyAyNGQxNTAwMCENClsg
IDE0OC41NzgyNjBdIDMzNWVhIGlzIDI0ZDE2MDAwIQ0KWyAgMTQ4LjU3OTk0M10gMzM1ZTkg
aXMgMjRkMTcwMDAhDQpbICAxNDguNTgxNjI0XSAzMzVlOCBpcyAyNGQxODAwMCENClsgIDE0
OC41ODMzMTRdIDMzNWU3IGlzIDI0ZDE5MDAwIQ0KWyAgMTQ4LjU4NTAwMV0gMzM1ZTYgaXMg
MjRkMWEwMDAhDQpbICAxNDguNTg2Njc3XSAzMzVlNSBpcyAyNGQxYjAwMCENClsgIDE0OC41
ODk4OThdIDMzNWJhIGlzIDI0Y2RjMDAwIQ0KWyAgMTQ4LjU5MTY0M10gMzM1NjkgaXMgMjRj
ZGQwMDAhDQpbICAxNDguNTkzMzY4XSAzMzU2YSBpcyAyNGNkZTAwMCENClsgIDE0OC41OTUx
MDhdIDMzNTZiIGlzIDI0Y2RmMDAwIQ0KWyAgMTQ4LjU5Njg0M10gMzM1NmMgaXMgMjRjZTAw
MDAhDQpbICAxNDguNTk4NTQ1XSAzMzU2ZCBpcyAyNGNlMTAwMCENClsgIDE0OC42MDAyNjJd
IDMzNTZlIGlzIDI0Y2UyMDAwIQ0KWyAgMTQ4LjYwMTk2NV0gMzM1NmYgaXMgMjRjZTMwMDAh
DQpbICAxNDguNjAzNzA0XSAzMzU3MCBpcyAyNGNlNDAwMCENClsgIDE0OC42MDU0MTZdIDMz
NTcxIGlzIDI0Y2U1MDAwIQ0KWyAgMTQ4LjYwNzEzMF0gMzM1NzIgaXMgMjRjZTYwMDAhDQpb
ICAxNDguNjA4ODQwXSAzMzYwNCBpcyAyNGNkMTAwMCENClsgIDE0OC42MTA1MzldIDMzNjAz
IGlzIDI0Y2QyMDAwIQ0KWyAgMTQ4LjYxMjI0MF0gMzM2MDIgaXMgMjRjZDMwMDAhDQpbICAx
NDguNjEzOTQ0XSAzMzYwMSBpcyAyNGNkNDAwMCENClsgIDE0OC42MTU2MjhdIDMzNjAwIGlz
IDI0Y2Q1MDAwIQ0KWyAgMTQ4LjYxNzMzOF0gMzM1ZmYgaXMgMjRjZDYwMDAhDQpbICAxNDgu
NjE5MDIzXSAzMzVmZSBpcyAyNGNkNzAwMCENClsgIDE0OC42MjA3MzhdIDMzNWZkIGlzIDI0
Y2Q4MDAwIQ0KWyAgMTQ4LjYyMjQyOV0gMzM1ZmMgaXMgMjRjZDkwMDAhDQpbICAxNDguNjI0
MTQyXSAzMzVmYiBpcyAyNGNkYTAwMCENClsgIDE0OC42MjU4MjBdIDMzNWZhIGlzIDI0Y2Ri
MDAwIQ0KWyAgMTQ4LjYyOTM0OV0gMzM2MTcgaXMgMjRjODcwMDAhDQpbICAxNDguNjMxMjA5
XSAzMzVkOCBpcyAyNGM4ODAwMCENClsgIDE0OC42MzI5NzFdIDMzNWQ3IGlzIDI0Yzg5MDAw
IQ0KWyAgMTQ4LjYzNDcxM10gMzM1ZDYgaXMgMjRjOGEwMDAhDQpbICAxNDguNjM2NDMxXSAz
MzVkNSBpcyAyNGM4YjAwMCENClsgIDE0OC42MzgxOTFdIDMzNWQ0IGlzIDI0YzhjMDAwIQ0K
WyAgMTQ4LjYzOTg5OV0gMzM1ZDMgaXMgMjRjOGQwMDAhDQpbICAxNDguNjQxNjQyXSAzMzVk
MiBpcyAyNGM4ZTAwMCENClsgIDE0OC42NDMzNTZdIDMzNWQxIGlzIDI0YzhmMDAwIQ0KWyAg
MTQ4LjY0NTEwM10gMzM1ZDAgaXMgMjRjOTAwMDAhDQpbICAxNDguNjQ2ODE1XSAzMzVjZiBp
cyAyNGM5YzAwMCENClsgIDE0OC42NDg1MjBdIDMzNWNlIGlzIDI0YzlkMDAwIQ0KWyAgMTQ4
LjY1MDI1Ml0gMzM1Y2QgaXMgMjRjOWUwMDAhDQpbICAxNDguNjUxOTQ4XSAzMzVjYyBpcyAy
NGM5ZjAwMCENClsgIDE0OC42NTM2NjddIDMzNWNiIGlzIDI0Y2EwMDAwIQ0KWyAgMTQ4LjY1
NTM2OV0gMzM1Y2EgaXMgMjRjYTEwMDAhDQpbICAxNDguNjU3MDY3XSAzMzVjOSBpcyAyNGNh
MjAwMCENClsgIDE0OC42NTg3NjhdIDMzNWM4IGlzIDI0Y2EzMDAwIQ0KWyAgMTQ4LjY2MDQ1
NV0gMzM1YzcgaXMgMjRjYTQwMDAhDQpbICAxNDguNjYyMTQ4XSAzMzVjNiBpcyAyNGNhNTAw
MCENClsgIDE0OC42NjM4NDJdIDMzNWM1IGlzIDI0Y2E2MDAwIQ0KWyAgMTQ4LjY2NTUwM10g
MzM1YzQgaXMgMjRjOTEwMDAhDQpbICAxNDguNjY3MTkzXSAzMzVjMyBpcyAyNGM5MjAwMCEN
ClsgIDE0OC42Njg4NTBdIDMzNWMyIGlzIDI0YzkzMDAwIQ0KWyAgMTQ4LjY3MDU0Ml0gMzM1
YzEgaXMgMjRjOTQwMDAhDQpbICAxNDguNjcyMjA4XSAzMzVjMCBpcyAyNGM5NTAwMCENClsg
IDE0OC42NzM4ODVdIDMzNWJmIGlzIDI0Yzk2MDAwIQ0KWyAgMTQ4LjY3NTU2OF0gMzM1YmUg
aXMgMjRjOTcwMDAhDQpbICAxNDguNjc3MjQzXSAzMzViZCBpcyAyNGM5ODAwMCENClsgIDE0
OC42Nzg5MjBdIDMzNWJjIGlzIDI0Yzk5MDAwIQ0KWyAgMTQ4LjY4MDU5NV0gMzM1YmIgaXMg
MjRjOWEwMDBbICAxNTAuODA3ODkxXSAzMzhjYiBpcyAyNTBhMzAwMCENClsgIDE1MC44MDk1
NjNdIDMzOGNjIGlzIDI1MGEyMDAwIQ0KWyAgMTUwLjgxMTI2M10gMzM4Y2QgaXMgMjUwYTEw
MDAhDQpbICAxNTAuODEyOTIzXSAzMzhjZSBpcyAyNTBhMDAwMCENClsgIDE1MC44MTQ1Nzhd
IDMzOGNmIGlzIDI1MDlmMDAwIQ0KWyAgMTUwLjgxNzg0Nl0gMzM4ZDAgaXMgMjUwYjQwMDAh
DQpbICAxNTAuODE5NDkyXSAzMzhkMSBpcyAyNTBiMzAwMCENClsgIDE1MC44MjExNjhdIDMz
OGQyIGlzIDI1MGIyMDAwIQ0KWyAgMTUwLjgyMjgxOF0gMzM4ZDMgaXMgMjUwYjEwMDAhDQpb
ICAxNTAuODI0NDgxXSAzMzhkNCBpcyAyNTBiMDAwMCENClsgIDE1MC44MjYxNDddIDMzOGQ1
IGlzIDI1MGFmMDAwIQ0KWyAgMTUwLjgyNzg4OF0gMzM4ZDYgaXMgMjUwYWUwMDAhDQpbICAx
NTAuODI5NTYxXSAzMzhkNyBpcyAyNTBhZDAwMCENClsgIDE1MC44MzEyMzRdIDMzOGQ4IGlz
IDI1MGFjMDAwIQ0KWyAgMTUwLjgzMjkwMV0gMzM4ZDkgaXMgMjUwYWIwMDAhDQpbICAxNTAu
ODM0NTk4XSAzMzhkYSBpcyAyNTBhYTAwMCENClsgIDE1MC44MzYyNTldIDMzOGRiIGlzIDI1
MGNjMDAwIQ0KWyAgMTUwLjgzNzk1MV0gMzM4ZGMgaXMgMjUwYzYwMDAhDQpbICAxNTAuODM5
NjA2XSAzMzhkZCBpcyAyNTBjNzAwMCENClsgIDE1MC44NDEyNzddIDMzOGRlIGlzIDI1MGM5
MDAwIQ0KWyAgMTUwLjg0Mjk1NF0gMzM4ZGYgaXMgMjUwYzgwMDAhDQpbICAxNTAuODQ0Njc0
XSAzMzhlMCBpcyAyNTBkNzAwMCENClsgIDE1MC44NDYzNTFdIDMzOGUxIGlzIDI1MGI4MDAw
IQ0KWyAgMTUwLjg0ODAzNF0gMzM4ZTIgaXMgMjUwYjcwMDAhDQpbICAxNTAuODQ5NzE2XSAz
MzhlMyBpcyAyNTBiNjAwMCENClsgIDE1MC44NTE0MDRdIDMzOTAzIGlzIDI1MGI1MDAwIQ0K
WyAgMTUwLjg1MzIxMV0gMzM4ZTggaXMgMjUwY2QwMDAhDQpbICAxNTAuODczOTcwXSAzMzky
YSBpcyAyNTA5NzAwMCENClsgIDE1MC44NzU3MTNdIDMzOGU5IGlzIDI1MGNhMDAwIQ0KWyAg
MTUwLjg3NzQ2NV0gMzM4ZWEgaXMgMjUwY2IwMDAhDQpbICAxNTAuODc5MjAzXSAzMzhlYiBp
cyAyNTBkMjAwMCENClsgIDE1MC44ODA5NTZdIDMzOGVjIGlzIDI1MGQ4MDAwIQ0KWyAgMTUw
Ljg4MjY4OV0gMzM4ZWQgaXMgMjUwYmEwMDAhDQpbICAxNTAuODg0NDY0XSAzMzhlZSBpcyAy
NTBiOTAwMCENClsgIDE1MC44ODYyMDldIDMzOGVmIGlzIDI1MGQxMDAwIQ0KWyAgMTUwLjg4
ODAwMV0gMzM4ZjAgaXMgMjUwZDQwMDAhDQpbICAxNTAuODg5NzUzXSAzMzhmMSBpcyAyNTBk
MzAwMCENClsgIDE1MC44OTE1MjddIDMzOGYyIGlzIDI1MGQwMDAwIQ0KWyAgMTUwLjg5MzI3
Ml0gMzM4ZjMgaXMgMjUwY2UwMDAhDQpbICAxNTAuODk1MDM3XSAzMzhmNCBpcyAyNTA5ZTAw
MCENClsgIDE1MC44OTY4MjRdIDMzOGY1IGlzIDI0ODUzMDAwIQ0KWyAgMTUwLjg5ODU5MV0g
MzM4ZjYgaXMgMjUwYzEwMDAhDQpbICAxNTAuOTAwNDA2XSAzMzhmNyBpcyAyNGJjODAwMCEN
ClsgIDE1MC45MDIyMDhdIDMzOGY4IGlzIDI0OWJiMDAwIQ0KWyAgMTUwLjkwNDA1MV0gMzM4
ZjkgaXMgMjQ4NDgwMDAhDQpbICAxNTAuOTA1ODY2XSAzMzhmYSBpcyAyNTBjMjAwMCENClsg
IDE1MC45MDc3MTVdIDMzOGZiIGlzIDI0NjQwMDAwIQ0KWyAgMTUwLjkwOTU4Nl0gMzM4ZmMg
aXMgMjQ5YmMwMDAhDQpbICAxNTAuOTExNDUyXSAzMzhmZCBpcyAyNTBkNTAwMCENClsgIDE1
MC45MTMzNDhdIDMzOGZlIGlzIDI1MGQ2MDAwIQ0KWyAgMTUwLjkxNTI0M10gMzM4ZmYgaXMg
MjUwOTgwMDAhDQpbICAxNTAuOTE3MTQ5XSAzMzkwMCBpcyAyNTA5OTAwMCENClsgIDE1MC45
MTkwMjldIDMzOTAxIGlzIDI1MDlhMDAwIQ0KWyAgMTUwLjkyMDkyOF0gMzM5MDIgaXMgMjUw
OWIwMDAhDQpbICAxNTAuOTIyNzkxXSAzMzkyNCBpcyAyNTA5YzAwMCENClsgIDE1MC45MjQ2
ODhdIDMzOTI1IGlzIDI1MGJkMDAwIQ0KWyAgMTUwLjkyNjU2M10gMzM5MjYgaXMgMjUwYmUw
MDAhDQpbICAxNTAuOTI4NDM5XSAzMzkyNyBpcyAyNTBiZjAwMCENClsgIDE1MC45MzAzMTdd
IDMzOTI4IGlzIDI1MGMwMDAwIQ0KWyAgMTUwLjkzMjE1N10gMzM5MjkgaXMgMjUwOWQwMDAh
DQpbICAxNTAuOTQwMTEwXSAzMzkwNCBpcyAyNTA4YzAwMCENClsgIDE1MC45NDIwMjhdIDMz
OTJiIGlzIDI1MDhkMDAwIQ0KWyAgMTUwLjk0Mzk0M10gMzM5MmMgaXMgMjUwOGUwMDAhDQpb
ICAxNTAuOTQ1ODMzXSAzMzkyZCBpcyAyNTA4ZjAwMCENClsgIDE1MC45NDc2NjZdIDMzOTJl
IGlzIDI1MDkwMDAwIQ0KWyAgMTUwLjk0OTQ5MF0gMzM5MmYgaXMgMjUwOTEwMDAhDQpbICAx
NTAuOTUxMzM5XSAzMzkzMCBpcyAyNTA5MjAwMCENClsgIDE1MC45NTMxNjhdIDMzOTMxIGlz
IDI1MDkzMDAwIQ0KWyAgMTUwLjk1NTAyOF0gMzM5MzIgaXMgMjUwOTQwMDAhDQpbICAxNTAu
OTU2ODYxXSAzMzkzMyBpcyAyNTA5NTAwMCENClsgIDE1MC45NTg2ODhdIDMzOTM0IGlzIDI1
MDk2MDAwIQ0KWyAgMTUwLjk2MDc1Nl0gMzM5MzYgaXMgMjUwODIwMDAhDQpbICAxNTAuOTYy
NTkxXSAzMzkzNyBpcyAyNTA4MzAwMCENClsgIDE1MC45NjQ0MTVdIDMzOTM4IGlzIDI1MDg0
MDAwIQ0KWyAgMTUwLjk2NjIxNV0gMzM5MzkgaXMgMjUwODUwMDAhDQpbICAxNTAuOTY3OTg2
XSAzMzkzYSBpcyAyNTA4NjAwMCENClsgIDE1MC45Njk3NDVdIDMzOTNiIGlzIDI1MDg3MDAw
IQ0KWyAgMTUwLjk3MTUxNV0gMzM5M2MgaXMgMjUwODgwMDAhDQpbICAxNTAuOTczMjQ2XSAz
MzkzZCBpcyAyNTA4OTAwMCENClsgIDE1MC45NzQ5NzhdIDMzOTNlIGlzIDI1MDhhMDAwIQ0K
WyAgMTUwLjk3NjY2NF0gMzM5M2YgaXMgMjUwOGIwMDAhDQpbICAxNTAuOTc4MzYzXSAzMzk0
MCBpcyAyNTA3NzAwMCENClsgIDE1MC45ODAwODNdIDMzOTQxIGlzIDI1MDc4MDAwIQ0KWyAg
MTUwLjk4MTc2Ml0gMzM5NDIgaXMgMjUwNzkwMDAhDQpbICAxNTAuOTgzNDcyXSAzMzk0MyBp
cyAyNTA3YTAwMCENClsgIDE1MC45ODUxNjFdIDMzOTQ0IGlzIDI1MDdiMDAwIQ0KWyAgMTUw
Ljk4Njg1MV0gMzM5NDUgaXMgMjUwN2MwMDAhDQpbICAxNTAuOTg4NTMwXSAzMzk0NiBpcyAy
NTA3ZDAwMCENClsgIDE1MC45OTAyMTJdIDMzOTQ3IGlzIDI1MDdlMDAwIQ0KWyAgMTUwLjk5
MTg4NV0gMzM5NDggaXMgMjUwN2YwMDAhDQpbICAxNTAuOTkzNTQzXSAzMzk0OSBpcyAyNTA4
MDAwMCENClsgIDE1MC45OTU1NDRdIDMzOTM1IGlzIDI1MDU2MDAwIQ0KWyAgMTUwLjk5NzI0
MF0gMzM5NGEgaXMgMjUwNmMwMDAhDQpbICAxNTAuOTk4ODkwXSAzMzk0YiBpcyAyNTA2ZDAw
MCENClsgIDE1MS4wMDA1ODJdIDMzOTRjIGlzIDI1MDZlMDAwIQ0KWyAgMTUxLjAwMjI0OV0g
MzM5NGQgaXMgMjUwNmYwMDAhDQpbICAxNTEuMDAzOTQ0XSAzMzk0ZSBpcyAyNTA3MDAwMCEN
ClsgIDE1MS4wMDU2MDddIDMzOTRmIGlzIDI1MDcxMDAwIQ0KWyAgMTUxLjAwNzI2Nl0gMzM5
NTAgaXMgMjUwNzIwMDAhDQpbICAxNTEuMDA4OTU3XSAzMzk1MSBpcyAyNTA3MzAwMCENClsg
IDE1MS4wMTA2MjldIDMzOTUyIGlzIDI1MDc0MDAwIQ0KWyAgMTUxLjAxMjMwNF0gMzM5NTMg
aXMgMjUwNzUwMDAhDQpbICAxNTEuMDEzOTgwXSAzMzk1NCBpcyAyNTA3NjAwMCENClsgIDE1
MS4wMTU2MjhdIDMzOTU1IGlzIDI1MDYxMDAwIQ0KWyAgMTUxLjAxNzMxNl0gMzM5NTYgaXMg
MjUwNjIwMDAhDQpbICAxNTEuMDE4OTY5XSAzMzk1NyBpcyAyNTA2MzAwMCENClsgIDE1MS4w
MjA2NjhdIDMzOTU4IGlzIDI1MDY0MDAwIQ0KWyAgMTUxLjAyMjMzMV0gMzM5NTkgaXMgMjUw
NjUwMDAhDQpbICAxNTEuMDI0MDEzXSAzMzk1YSBpcyAyNTA2NjAwMCENClsgIDE1MS4wMjU2
OTZdIDMzOTViIGlzIDI1MDY3MDAwIQ0KWyAgMTUxLjAyNzM3OF0gMzM5NWMgaXMgMjUwNjgw
MDAhDQpbICAxNTEuMDI5MDY1XSAzMzk1ZCBpcyAyNTA2OTAwMCENClsgIDE1MS4wMzA3NDFd
IDMzOTVlIGlzIDI1MDZhMDAwIQ0KWyAgMTUxLjAzMjQwMl0gMzM5NWYgaXMgMjUwNmIwMDAh
DQpbICAxNTEuMDM0MDkyXSAzMzk2MCBpcyAyNTA1NzAwMCENClsgIDE1MS4wMzU3NjBdIDMz
OTYxIGlzIDI1MDU4MDAwIQ0KWyAgMTUxLjAzNzQ2M10gMzM5NjQgaXMgMjUwNTkwMDAhDQpb
ICAxNTEuMDM5MTMwXSAzMzk2NSBpcyAyNTA1YTAwMCENClsgIDE1MS4wNDA4MTddIDMzOTY2
IGlzIDI1MDViMDAwIQ0KWyAgMTUxLjA0MjUxMl0gMzM5NjcgaXMgMjUwNWMwMDAhDQpbICAx
NTEuMDQ0MTkyXSAzMzk2OCBpcyAyNTA1ZDAwMCENClsgIDE1MS4wNDU4NzFdIDMzOTY5IGlz
IDI1MDVlMDAwIQ0KWyAgMTUxLjA0NzU0MF0gMzM5NmEgaXMgMjUwNWYwMDAhDQpbICAxNTEu
MDQ5MTk3XSAzMzk2YiBpcyAyNTA2MDAwMCENClsgIDE1MS4wNTI0NjZdIDMzOTgxIGlzIDI1
MDM2MDAwIQ0KWyAgMTUxLjA1NDI0MV0gMzM5ODIgaXMgMjUwMzcwMDAhDQpbICAxNTEuMDU1
OTMyXSAzMzk4MyBpcyAyNTAzODAwMCENClsgIDE1MS4wNTc2MjNdIDMzOTg0IGlzIDI1MDM5
MDAwIQ0KWyAgMTUxLjA1OTMxMl0gMzM5ODUgaXMgMjUwM2EwMDAhDQpbICAxNTEuMDYwOTk1
XSAzMzk4NiBpcyAyNTAzYjAwMCENClsgIDE1MS4wNjI2ODVdIDMzOTg3IGlzIDI1MDNjMDAw
IQ0KWyAgMTUxLjA2NDM2M10gMzM5ODggaXMgMjUwM2QwMDAhDQpbICAxNTEuMDY2MDU3XSAz
Mzk4OSBpcyAyNTAzZTAwMCENClsgIDE1MS4wNjc3MjddIDMzOThhIGlzIDI1MDNmMDAwIQ0K
WyAgMTUxLjA2OTQwMF0gMzM5MDUgaXMgMjUwNGIwMDAhDQpbICAxNTEuMDcxMDgxXSAzMzk2
YyBpcyAyNTA0YzAwMCENClsgIDE1MS4wNzI3NDNdIDMzOTZkIGlzIDI1MDRkMDAwIQ0KWyAg
MTUxLjA3NDQzNF0gMzM5NmUgaXMgMjUwNGUwMDAhDQpbICAxNTEuMDc2MDk1XSAzMzk2ZiBp
cyAyNTA0ZjAwMCENClsgIDE1MS4wNzc3NzBdIDMzOTcwIGlzIDI1MDUwMDAwIQ0KWyAgMTUx
LjA3OTQ2MF0gMzM5NzEgaXMgMjUwNTEwMDAhDQpbICAxNTEuMDgxMTQyXSAzMzk3MiBpcyAy
NTA1MjAwMCENClsgIDE1MS4wODI4MzBdIDMzOTczIGlzIDI1MDUzMDAwIQ0KWyAgMTUxLjA4
NDUxN10gMzM5NzQgaXMgMjUwNTQwMDAhDQpbICAxNTEuMDg2MTg0XSAzMzk3NSBpcyAyNTA1
NTAwMCENClsgIDE1MS4wODc4ODJdIDMzOTc2IGlzIDI1MDQwMDAwIQ0KWyAgMTUxLjA4OTU0
NF0gMzM5NzcgaXMgMjUwNDEwMDAhDQpbICAxNTEuMDkxMjM1XSAzMzk3OCBpcyAyNTA0MjAw
MCENClsgIDE1MS4wOTI5MDddIDMzOTc5IGlzIDI1MDQzMDAwIQ0KWyAgMTUxLjA5NDU5NV0g
MzM5N2EgaXMgMjUwNDQwMDAhDQpbICAxNTEuMDk2Mjg2XSAzMzk3YiBpcyAyNTA0NTAwMCEN
ClsgIDE1MS4wOTc5NzNdIDMzOTdjIGlzIDI1MDQ2MDAwIQ0KWyAgMTUxLjA5OTY2OF0gMzM5
N2QgaXMgMjUwNDcwMDAhDQpbICAxNTEuMTAxMzYwXSAzMzk3ZSBpcyAyNTA0ODAwMCENClsg
IDE1MS4xMDMwNDVdIDMzOTdmIGlzIDI1MDQ5MDAwIQ0KWyAgMTUxLjEwNDc1NV0gMzM5ODAg
aXMgMjUwNGEwMDAhDQpbICAxNTEuMTA3NjE1XSAzMzlhZCBpcyAyNTAwMDAwMCENClsgIDE1
MS4xMDkzNzNdIDMzOTA2IGlzIDI1MDAxMDAwIQ0KWyAgMTUxLjExMTA5OV0gMzM5MDcgaXMg
MjUwMDIwMDAhDQpbICAxNTEuMTEyODE1XSAzMzkwOCBpcyAyNTAwMzAwMCENClsgIDE1MS4x
MTQ1MjFdIDMzOTA5IGlzIDI1MDA0MDAwIQ0KWyAgMTUxLjExNjIzMF0gMzM5MGEgaXMgMjUw
MDUwMDAhDQpbICAxNTEuMTE3OTQwXSAzMzkwYiBpcyAyNTAwNjAwMCENClsgIDE1MS4xMTk2
MjRdIDMzOTBjIGlzIDI1MDA3MDAwIQ0KWyAgMTUxLjEyMTM1M10gMzM5MGQgaXMgMjUwMDgw
MDAhDQpbICAxNTEuMTIzMDQ5XSAzMzkwZSBpcyAyNTAwOTAwMCENClsgIDE1MS4xMjQ3NzBd
IDMzOTBmIGlzIDI1MDBhMDAwIQ0KWyAgMTUxLjEyNjQ0NV0gMzM5OGIgaXMgMjUwMmIwMDAh
DQpbICAxNTEuMTI4MTM4XSAzMzk4YyBpcyAyNTAyYzAwMCENClsgIDE1MS4xMjk4NTVdIDMz
OThkIGlzIDI1MDJkMDAwIQ0KWyAgMTUxLjEzMTU0Ml0gMzM5OGUgaXMgMjUwMmUwMDAhDQpb
ICAxNTEuMTMzMjI1XSAzMzk4ZiBpcyAyNTAyZjAwMCENClsgIDE1MS4xMzQ5MTJdIDMzOTkw
IGlzIDI1MDMwMDAwIQ0KWyAgMTUxLjEzNjU5Ml0gMzM5OTEgaXMgMjUwMzEwMDAhDQpbICAx
NTEuMTM4Mjk1XSAzMzk5MiBpcyAyNTAzMjAwMCENClsgIDE1MS4xMzk5NjJdIDMzOTkzIGlz
IDI1MDMzMDAwIQ0KWyAgMTUxLjE0MTY2MF0gMzM5OTQgaXMgMjUwMzQwMDAhDQpbICAxNTEu
MTQzMzI3XSAzMzk5NSBpcyAyNTAzNTAwMCENClsgIDE1MS4xNDUwMDhdIDMzOWExIGlzIDI1
MDE2MDAwIQ0KWyAgMTUxLjE0NjY5Nl0gMzM5YTQgaXMgMjUwMTcwMDAhDQpbICAxNTEuMTQ4
MzgzXSAzMzlhNSBpcyAyNTAxODAwMCENClsgIDE1MS4xNTAwODhdIDMzOWE2IGlzIDI1MDE5
MDAwIQ0KWyAgMTUxLjE1MTc2MF0gMzM5YTcgaXMgMjUwMWEwMDAhDQpbICAxNTEuMTUzNDYx
XSAzMzlhOCBpcyAyNTAxYjAwMCENClsgIDE1MS4xNTUxMjhdIDMzOWE5IGlzIDI1MDFjMDAw
IQ0KWyAgMTUxLjE1NjgwNV0gMzM5YWEgaXMgMjUwMWQwMDAhDQpbICAxNTEuMTU4NDgyXSAz
MzlhYiBpcyAyNTAxZTAwMCENClsgIDE1MS4xNjAxNTddIDMzOWFjIGlzIDI1MDFmMDAwIQ0K
WyAgMTUxLjE2MTgzM10gMzM5YTAgaXMgMjUwMGIwMDAhDQpbICAxNTEuMTYzNTA3XSAzMzk5
ZiBpcyAyNTAwYzAwMCENClsgIDE1MS4xNjUxNjldIDMzOTllIGlzIDI1MDBkMDAwIQ0KWyAg
MTUxLjE2Njg2MV0gMzM5OWQgaXMgMjUwMGUwMDAhDQpbICAxNTEuMTY4NTE2XSAzMzk5YyBp
cyAyNTAwZjAwMCENClsgIDE1MS4xNzAyMDFdIDMzOTliIGlzIDI1MDEwMDAwIQ0KWyAgMTUx
LjE3MTg3M10gMzM5OWEgaXMgMjUwMTEwMDAhDQpbICAxNTEuMTczNTYwXSAzMzk5OSBpcyAy
NTAxMjAwMCENClsgIDE1MS4xNzUyNDNdIDMzOTk4IGlzIDI1MDEzMDAwIQ0KWyAgMTUxLjE3
NjkyNl0gMzM5OTcgaXMgMjUwMTQwMDAhDQpbICAxNTEuMTc4NjA3XSAzMzk5NiBpcyAyNTAx
NTAwMCENClsgIDE1MS4xODE5MzldIDMzOWI5IGlzIDI0ZmQ2MDAwIQ0KWyAgMTUxLjE4Mzcy
MF0gMzM5YmEgaXMgMjRmZDcwMDAhDQpbICAxNTEuMTg1NDE4XSAzMzliYiBpcyAyNGZkODAw
MCENClsgIDE1MS4xODcxNTNdIDMzOWJjIGlzIDI0ZmQ5MDAwIQ0KWyAgMTUxLjE4ODg1NF0g
MzM5YmQgaXMgMjRmZGEwMDAhDQpbICAxNTEuMTkwNTM4XSAzMzliZSBpcyAyNGZkYjAwMCEN
ClsgIDE1MS4xOTIyMzldIDMzOWJmIGlzIDI0ZmRjMDAwIQ0KWyAgMTUxLjE5MzkzM10gMzM5
YzAgaXMgMjRmZGQwMDAhDQpbICAxNTEuMTk1NjU1XSAzMzljMSBpcyAyNGZkZTAwMCENClsg
IDE1MS4xOTczNzNdIDMzOWMyIGlzIDI0ZmRmMDAwIQ0KWyAgMTUxLjE5OTA1N10gMzM5MWEg
aXMgMjRmZWIwMDAhDQpbICAxNTEuMjAwNzczXSAzMzkxOSBpcyAyNGZlYzAwMCENClsgIDE1
MS4yMDI0NzBdIDMzOTE4IGlzIDI0ZmVkMDAwIQ0KWyAgMTUxLjIwNDE4Nl0gMzM5MTcgaXMg
MjRmZWUwMDAhDQpbICAxNTEuMjA1ODc4XSAzMzkxNiBpcyAyNGZlZjAwMCENClsgIDE1MS4y
MDc2MDldIDMzOTE1IGlzIDI0ZmYwMDAwIQ0KWyAgMTUxLjIwOTMyN10gMzM5MTQgaXMgMjRm
ZjEwMDAhDQpbICAxNTEuMjExMDMyXSAzMzkxMyBpcyAyNGZmMjAwMCENClsgIDE1MS4yMTI3
NDVdIDMzOTEyIGlzIDI0ZmYzMDAwIQ0KWyAgMTUxLjIxNDQ1NF0gMzM5MTEgaXMgMjRmZjQw
MDAhDQpbICAxNTEuMjE2MTYyXSAzMzkxMCBpcyAyNGZmNTAwMCENClsgIDE1MS4yMTc4NjBd
IDMzOWFlIGlzIDI0ZmUwMDAwIQ0KWyAgMTUxLjIxOTU0NF0gMzM5YWYgaXMgMjRmZTEwMDAh
DQpbICAxNTEuMjIxMjU5XSAzMzliMCBpcyAyNGZlMjAwMCENClsgIDE1MS4yMjI5NjBdIDMz
OWIxIGlzIDI0ZmUzMDAwIQ0KWyAgMTUxLjIyNDY5Ml0gMzM5YjIgaXMgMjRmZTQwMDAhDQpb
ICAxNTEuMjI2MzgzXSAzMzliMyBpcyAyNGZlNTAwMCENClsgIDE1MS4yMjgwODddIDMzOWI0
IGlzIDI0ZmU2MDAwIQ0KWyAgMTUxLjIyOTc4OF0gMzM5YjUgaXMgMjRmZTcwMDAhDQpbICAx
NTEuMjMxNDgxXSAzMzliNiBpcyAyNGZlODAwMCENClsgIDE1MS4yMzMxNzZdIDMzOWI3IGlz
IDI0ZmU5MDAwIQ0KWyAgMTUxLjIzNDg2N10gMzM5YjggaXMgMjRmZWEwMDAhDQpbICAxNTEu
MjM3NjcxXSAzMzllMyBpcyAyNGZhMDAwMCENClsgIDE1MS4yMzk0MTFdIDMzOTFiIGlzIDI0
ZmExMDAwIQ0KWyAgMTUxLjI0MTE0M10gMzM5MWMgaXMgMjRmYTIwMDAhDQpbICAxNTEuMjQy
ODIyXSAzMzkxZCBpcyAyNGZhMzAwMCENClsgIDE1MS4yNDQ1MjJdIDMzOTFlIGlzIDI0ZmE0
MDAwIQ0KWyAgMTUxLjI0NjIxNV0gMzM5MWYgaXMgMjRmYTUwMDAhDQpbICAxNTEuMjQ3ODk5
XSAzMzkyMCBpcyAyNGZhNjAwMCENClsgIDE1MS4yNDk2MDVdIDMzOTIxIGlzIDI0ZmE3MDAw
IQ0KWyAgMTUxLjI1MTI5NF0gMzNhMDEgaXMgMjRmYTgwMDAhDQpbICAxNTEuMjUyOTc1XSAz
M2EwMiBpcyAyNGZhOTAwMCENClsgIDE1MS4yNTQ2NzldIDMzYTAzIGlzIDI0ZmFhMDAwIQ0K
WyAgMTUxLjI1NjMzNF0gMzM5Y2UgaXMgMjRmYzAwMDAhDQpbICAxNTEuMjU4MDQ1XSAzMzlj
ZiBpcyAyNGZjMTAwMCENClsgIDE1MS4yNTk3MjFdIDMzOWQwIGlzIDI0ZmMyMDAwIQ0KWyAg
MTUxLjI2MTQyMV0gMzM5ZDEgaXMgMjRmYzMwMDAhDQpbICAxNTEuMjYzMTA3XSAzMzlkMiBp
cyAyNGZjNDAwMCENClsgIDE1MS4yNjQ3OTVdIDMzOWQzIGlzIDI0ZmM1MDAwIQ0KWyAgMTUx
LjI2NjQ3N10gMzM5ZDQgaXMgMjRmYzYwMDAhDQpbICAxNTEuMjY4MTYxXSAzMzlkNSBpcyAy
NGZjNzAwMCENClsgIDE1MS4yNjk4ODVdIDMzOWQ2IGlzIDI0ZmM4MDAwIQ0KWyAgMTUxLjI3
MTU2MV0gMzM5ZDcgaXMgMjRmYzkwMDAhDQpbICAxNTEuMjczMjIyXSAzMzlkOCBpcyAyNGZj
YTAwMCENClsgIDE1MS4yNzQ5MTRdIDMzOWQ5IGlzIDI0ZmI2MDAwIQ0KWyAgMTUxLjI3NjU3
MF0gMzM5ZGEgaXMgMjRmYjcwMDAhDQpbICAxNTEuMjc4MjU0XSAzMzlkYiBpcyAyNGZiODAw
MCENClsgIDE1MS4yNzk5MTBdIDMzOWRjIGlzIDI0ZmI5MDAwIQ0KWyAgMTUxLjI4MTU3OV0g
MzM5ZGQgaXMgMjRmYmEwMDAhDQpbICAxNTEuMjgzMjYyXSAzMzlkZSBpcyAyNGZiYjAwMCEN
ClsgIDE1MS4yODQ5NDldIDMzOWRmIGlzIDI0ZmJjMDAwIQ0KWyAgMTUxLjI4NjYzN10gMzM5
ZTAgaXMgMjRmYmQwMDAhDQpbICAxNTEuMjg4MzI4XSAzMzllMSBpcyAyNGZiZTAwMCENClsg
IDE1MS4yOTAwMDddIDMzOWUyIGlzIDI0ZmJmMDAwIQ0KWyAgMTUxLjI5MTcxMV0gMzM5Y2Qg
aXMgMjRmYWIwMDAhDQpbICAxNTEuMjkzNDA5XSAzMzljYyBpcyAyNGZhYzAwMCENClsgIDE1
MS4yOTUxMDJdIDMzOWNiIGlzIDI0ZmFkMDAwIQ0KWyAgMTUxLjI5Njc5MV0gMzM5Y2EgaXMg
MjRmYWUwMDAhDQpbICAxNTEuMjk4NDc1XSAzMzljOSBpcyAyNGZhZjAwMCENClsgIDE1MS4z
MDAxODldIDMzOWM4IGlzIDI0ZmIwMDAwIQ0KWyAgMTUxLjMwMTg4NV0gMzM5YzcgaXMgMjRm
YjEwMDAhDQpbICAxNTEuMzAzNjA1XSAzMzljNiBpcyAyNGZiMjAwMCENClsgIDE1MS4zMDUy
NzhdIDMzOWM1IGlzIDI0ZmIzMDAwIQ0KWyAgMTUxLjMwNjk2Nl0gMzM5YzQgaXMgMjRmYjQw
MDAhDQpbICAxNTEuMzA4NjYyXSAzMzljMyBpcyAyNGZiNTAwMCENClsgIDE1MS4zMTE5Nzdd
IDMzOWVmIGlzIDI0Zjc2MDAwIQ0KWyAgMTUxLjMxMzczMF0gMzM5ZjAgaXMgMjRmNzcwMDAh
DQpbICAxNTEuMzE1NDE1XSAzMzlmMSBpcyAyNGY3ODAwMCENClsgIDE1MS4zMTcxNThdIDMz
OWYyIGlzIDI0Zjc5MDAwIQ0KWyAgMTUxLjMxODg0OV0gMzM5ZjMgaXMgMjRmN2EwMDAhDQpb
ICAxNTEuMzIwNTY4XSAzMzlmNCBpcyAyNGY3YjAwMCENClsgIDE1MS4zMjIyNjRdIDMzOWY1
IGlzIDI0ZjdjMDAwIQ0KWyAgMTUxLjMyMzk4Ml0gMzM5ZjYgaXMgMjRmN2QwMDAhDQpbICAx
NTEuMzI1Njc1XSAzMzlmNyBpcyBbICAxNTMuNDU2MDEyXSAzM2JmMCBpcyAyNTU0ZjAwMCEN
ClsgIDE1My40NjI4MTRdIDMzYmYxIGlzIDI1NTRlMDAwIQ0KWyAgMTUzLjQ3MDk1M10gMzNi
ZjIgaXMgMjU1NGQwMDAhDQpbICAxNTMuNDk5NTI0XSAzM2JmMyBpcyAyNTU0YzAwMCENClsg
IDE1My41MTgyMTddIDMzYmQyIGlzIDI1NTRiMDAwIQ0KWyAgMTUzLjUyMDU5N10gMzNiZDMg
aXMgMjU1NDcwMDAhDQpbICAxNTMuNTIyMzk1XSAzM2JmNCBpcyAyNTU0ODAwMCENClsgIDE1
My41MjQyMDFdIDMzYmY1IGlzIDI1NTQ5MDAwIQ0KWyAgMTUzLjUyNTk5Ml0gMzNiZjYgaXMg
MjU1NGEwMDAhDQpbICAxNTMuNTM0OTU5XSAzM2MxMiBpcyAyNTU0NjAwMCENClsgIDE1My41
NDQ2NTFdIDMzYzEzIGlzIDI1NTQ1MDAwIQ0KWyAgMTUzLjU0Njg5M10gMzNjMTQgaXMgMjU1
NDQwMDAhDQpbICAxNTMuNTUzNzI3XSAzM2JmNyBpcyAyNTU0MzAwMCENClsgIDE1My41NzQ0
NDJdIDMzYmY4IGlzIDI1NTQyMDAwIQ0KWyAgMTUzLjU3ODg0NF0gMzNjMTUgaXMgMjU1NDEw
MDAhDQpbICAxNTMuNTg5NDUwXSAzM2JmOSBpcyAyNTU0MDAwMCENClsgIDE1My41OTk4NzRd
IDMzYzE2IGlzIDI1NTNmMDAwIQ0KWyAgMTUzLjYwNzM1OF0gMzNiZmEgaXMgMjU1M2UwMDAh
DQpbICAxNTMuNjA5NjE2XSAzM2JmYiBpcyAyNTUzZDAwMCENClsgIDE1My42MjQ4NjNdIDMz
YmZjIGlzIDI1NTNjMDAwIQ0KWyAgMTUzLjYzNjIxNF0gMzNjMTcgaXMgMjU1M2IwMDAhDQpb
ICAxNTMuNjQ4MDM3XSAzM2MxOCBpcyAyNTUzYTAwMCENClsgIDE1My42NTgxMjVdIDMzYmZk
IGlzIDI1NTM5MDAwIQ0KWyAgMTUzLjY2Mjg2MF0gMzNiZmUgaXMgMjU1MzgwMDAhDQpbICAx
NTMuNjczMjEyXSAzM2JmZiBpcyAyNTUzNzAwMCENClsgIDE1My42NzY2OTRdIDMzYzAwIGlz
IDI1NTM2MDAwIQ0KWyAgMTUzLjY4NDk1OF0gMzNjMDEgaXMgMjU1MzUwMDAhDQpbICAxNTMu
NjkyMDM5XSAzM2MwMiBpcyAyNTUzNDAwMCENClsgIDE1My43MDMxODldIDMzYzAzIGlzIDI1
NTMzMDAwIQ0KWyAgMTUzLjcyMzI1MV0gMzNjMDQgaXMgMjU1MzIwMDAhDQpbICAxNTMuNzMw
ODU4XSAzM2MxOSBpcyAyNTUzMTAwMCENClsgIDE1My43MzMxODZdIDMzYzA1IGlzIDI1NTMw
MDAwIQ0KWyAgMTUzLjc0ODk3NF0gMzNjMDYgaXMgMjU1MmYwMDAhDQpbICAxNTMuNzUyOTQy
XSAzM2MwNyBpcyAyNTUyZTAwMCENClsgIDE1My43NTUzMjJdIDMzYzA4IGlzIDI1NTJkMDAw
IQ0KWyAgMTUzLjc1NzY4MF0gMzNjMDkgaXMgMjU1MmMwMDAhDQpbICAxNTMuNzU5OTIyXSAz
M2MwYSBpcyAyNTUyYjAwMCENClsgIDE1My43NjIzNDddIDMzYzBiIGlzIDI1NTJhMDAwIQ0K
WyAgMTUzLjc2NDY5N10gMzNjMGMgaXMgMjU1MjkwMDAhDQpbICAxNTMuNzY5OTQzXSAzM2Mw
ZCBpcyAyNTUyODAwMCENClsgIDE1My43OTA4OThdIDMzYzBlIGlzIDI1NTI3MDAwIQ0KWyAg
MTUzLjc5NTkxNl0gMzNjMWEgaXMgMjU0ZmQwMDAhDQpbICAxNTMuNzk4MzM2XSAzM2MwZiBp
cyAyNTRmZTAwMCENClsgIDE1My44MDU4NjFdIDMzYzEwIGlzIDI1NGZmMDAwIQ0KWyAgMTUz
LjgxMzAzNV0gMzNjMTEgaXMgMjU1MDAwMDAhDQpbICAxNTMuODIwNDUyXSAzM2MzMSBpcyAy
NTUwMTAwMCENClsgIDE1My44MjcwODFdIDMzYzMyIGlzIDI1NTAyMDAwIQ0KWyAgMTUzLjgz
MzExN10gMzNjMzMgaXMgMjU1MDMwMDAhDQpbICAxNTMuODM3OTIzXSAzM2MzNCBpcyAyNTUw
NDAwMCENClsgIDE1My44NDQ2NDNdIDMzYzM1IGlzIDI1NTA1MDAwIQ0KWyAgMTUzLjg0Njk2
NV0gMzNjMzYgaXMgMjU1MGMwMDAhDQpbICAxNTMuODY1NDc0XSAzM2MzNyBpcyAyNTUxZjAw
MCENClsgIDE1My44NzQ4MTRdIDMzYzFiIGlzIDI1NTE3MDAwIQ0KWyAgMTUzLjg3NjYxMF0g
MzNjMWMgaXMgMjU1MjUwMDAhDQpbICAxNTMuODc4NDIwXSAzM2MxZCBpcyAyNTUyNjAwMCEN
ClsgIDE1My44ODAyMDJdIDMzYzFlIGlzIDI1NTFhMDAwIQ0KWyAgMTUzLjkwMDY4NV0gMzNj
MWYgaXMgMjU1MTYwMDAhDQpbICAxNTMuOTE4NjM5XSAzM2MyMCBpcyAyNTUxNTAwMCENClsg
IDE1My45MzQ0NzBdIDMzYzIxIGlzIDI1NTE0MDAwIQ0KWyAgMTUzLjk0NzAxNl0gMzNjMjIg
aXMgMjU1MTIwMDAhDQpbICAxNTMuOTU1MjQ4XSAzM2MzOCBpcyAyNTUxODAwMCENClsgIDE1
My45NTc1NzddIDMzYzM5IGlzIDI1NTBmMDAwIQ0KWyAgMTUzLjk3MTI0N10gMzNjM2EgaXMg
MjU1MTEwMDAhDQpbICAxNTMuOTc3NzU4XSAzM2MzYiBpcyAyNTUwNjAwMCENClsgIDE1My45
Nzk5NzFdIDMzYzIzIGlzIDI1NTA3MDAwIQ0KWyAgMTUzLjk5MDA2MF0gMzNjM2MgaXMgMjU1
MTAwMDAhDQpbICAxNTMuOTkyMzAyXSAzM2MzZCBpcyAyNTUwYjAwMCENClsgIDE1My45OTQ2
ODhdIDMzYzNlIGlzIDI1NTE5MDAwIQ0KWyAgMTU0LjAxMzUyNF0gMzNjM2YgaXMgMjU1MGQw
MDAhDQpbICAxNTQuMDQwNDI1XSAzM2MyNCBpcyAyNTUwZTAwMCENClsgIDE1NC4wNDY1NzRd
IDMzYzI1IGlzIDI0ZTI2MDAwIQ0KWyAgMTU0LjA2MjM5MV0gMzNjMjYgaXMgMjRlMTkwMDAh
DQpbICAxNTQuMDY0MzIxXSAzM2M0MCBpcyAyNDlhMDAwMCENClsgIDE1NC4wNjYxODFdIDMz
YzQxIGlzIDI1NTIxMDAwIQ0KWyAgMTU0LjA2ODA2Ml0gMzNjNDIgaXMgMjU1MjAwMDAhDQpb
ICAxNTQuMDgwMTA0XSAzM2M0MyBpcyAyNGJjNzAwMCENClsgIDE1NC4wODIzMzFdIDMzYzQ0
IGlzIDI1NTBhMDAwIQ0KWyAgMTU0LjEwMjEwM10gMzNjNDUgaXMgMjQ2M2UwMDAhDQpbICAx
NTQuMTEyNDg3XSAzM2MyNyBpcyAyNTUxYzAwMCENClsgIDE1NC4xMTQ0NTZdIDMzYzQ2IGlz
IDI1NTFkMDAwIQ0KWyAgMTU0LjExNjM2N10gMzNjNDcgaXMgMjU1MWUwMDAhDQpbICAxNTQu
MTE4Mjg3XSAzM2M0OCBpcyAyNGUxYjAwMCENClsgIDE1NC4xMjA2MTJdIDMzYzQ5IGlzIDI1
NTFiMDAwIQ0KWyAgMTU0LjEyMjkzOV0gMzNjNGEgaXMgMjRiYzQwMDAhDQpbICAxNTQuMTI1
MzAxXSAzM2M0YiBpcyAyNGJjMzAwMCENClsgIDE1NC4xMjc2MzZdIDMzYzI4IGlzIDI1NGZh
MDAwIQ0KWyAgMTU0LjEzNDg4OV0gMzNjMjkgaXMgMjU0ZjkwMDAhDQpbICAxNTQuMTM3Mzky
XSAzM2M0YyBpcyAyNTRmODAwMCENClsgIDE1NC4xMzk3NjRdIDMzYzRkIGlzIDI1NGY3MDAw
IQ0KWyAgMTU0LjE2Mzk2NF0gMzNjNGUgaXMgMjU0ZjYwMDAhDQpbICAxNTQuMTY2MzE5XSAz
M2MyYSBpcyAyNTRmNTAwMCENClsgIDE1NC4xNzc1NjddIDMzYzRmIGlzIDI1NGY0MDAwIQ0K
WyAgMTU0LjE3OTk0Ml0gMzNjNTAgaXMgMjU0ZjMwMDAhDQpbICAxNTQuMTkwMDAzXSAzM2M1
MSBpcyAyNTRmMjAwMCENClsgIDE1NC4xOTI0ODZdIDMzYzUyIGlzIDI1NGYxMDAwIQ0KWyAg
MTU0LjE5NDk1Nl0gMzNjNTMgaXMgMjU0ZjAwMDAhDQpbICAxNTQuMTk3NDAxXSAzM2M1NCBp
cyAyNTRlZjAwMCENClsgIDE1NC4xOTk3NDBdIDMzYzU1IGlzIDI1NGVlMDAwIQ0KWyAgMTU0
LjIwMjIzMF0gMzNjNTYgaXMgMjU0ZWQwMDAhDQpbICAxNTQuMjM3NjEwXSAzM2M1NyBpcyAy
NTRlYzAwMCENClsgIDE1NC4yMzk5MTNdIDMzYzU4IGlzIDI1NGViMDAwIQ0KWyAgMTU0LjI0
MjM2N10gMzNjNTkgaXMgMjU0ZWEwMDAhDQpbICAxNTQuMjQ0NzQ0XSAzM2M1YSBpcyAyNTRl
OTAwMCENClsgIDE1NC4yNDY5MjVdIDMzYzViIGlzIDI1NGU4MDAwIQ0KWyAgMTU0LjI2Njk4
OV0gMzNjNWMgaXMgMjU0ZTcwMDAhDQpbICAxNTQuMjY5MjQ4XSAzM2MyYiBpcyAyNTRlNjAw
MCENClsgIDE1NC4yOTYzNDhdIDMzYzVkIGlzIDI1NGU1MDAwIQ0KWyAgMTU0LjMwMTQwM10g
MzNjMmMgaXMgMjU0ZTQwMDAhDQpbICAxNTQuMzAzODExXSAzM2MyZCBpcyAyNTRlMzAwMCEN
ClsgIDE1NC4zMDYwMDldIDMzYzVlIGlzIDI1NGUyMDAwIQ0KWyAgMTU0LjMzMDMzOV0gMzNj
NWYgaXMgMjU0ZTEwMDAhDQpbICAxNTQuMzQxODEwXSAzM2MyZSBpcyAyNTRlMDAwMCENClsg
IDE1NC4zNjI0MzhdIDMzYzYwIGlzIDI1NGRmMDAwIQ0KWyAgMTU0LjM3MjQwOF0gMzNjMmYg
aXMgMjU0ZGUwMDAhDQpbICAxNTQuMzc2ODEyXSAzM2M2MSBpcyAyNTRkZDAwMCENClsgIDE1
NC4zODY5NjldIDMzYzYyIGlzIDI1NGRjMDAwIQ0KWyAgMTU0LjM5NzY0MV0gMzNjNjMgaXMg
MjU0ZGIwMDAhDQpbICAxNTQuNDEzMzU3XSAzM2M2NCBpcyAyNTRkYTAwMCENClsgIDE1NC40
MjYwMTRdIDMzYzY1IGlzIDI1NGQ5MDAwIQ0KWyAgMTU0LjQyODI4OV0gMzNjNjYgaXMgMjU0
ZDgwMDAhDQpbICAxNTQuNDM4NDI3XSAzM2M2NyBpcyAyNTRkNzAwMCENClsgIDE1NC40NDQy
MzhdIDMzYzY4IGlzIDI1NGQ2MDAwIQ0KWyAgMTU0LjQ2NDMyOV0gMzNjNjkgaXMgMjU0ZDUw
MDAhDQpbICAxNTQuNDY2NTE5XSAzM2MzMCBpcyAyNTRkNDAwMCENClsgIDE1NC40NzM0OThd
IDMzYzZhIGlzIDI1NGQzMDAwIQ0KWyAgMTU0LjQ4MTg5OF0gMzNjNmIgaXMgMjU0ZDIwMDAh
DQpbICAxNTQuNDg0MTQ4XSAzM2M2YyBpcyAyNTRkMTAwMCENClsgIDE1NC40OTM5MjldIDMz
YzZkIGlzIDI1NGQwMDAwIQ0KWyAgMTU0LjUwMDQyMV0gMzNjNmUgaXMgMjU0Y2YwMDAhDQpb
ICAxNTQuNTA5ODg5XSAzM2M3MCBpcyAyNTRjZTAwMCENClsgIDE1NC41MTIxODZdIDMzYzhl
IGlzIDI1NGNkMDAwIQ0KWyAgMTU0LjUxNDQ2NV0gMzNjNzEgaXMgMjU0Y2MwMDAhDQpbICAx
NTQuNTE2NjYwXSAzM2M3MiBpcyAyNTRjYjAwMCENClsgIDE1NC41MTg5MjNdIDMzYzczIGlz
IDI1NGNhMDAwIQ0KWyAgMTU0LjUyMTIyMV0gMzNjNzQgaXMgMjU0YzkwMDAhDQpbICAxNTQu
NTIzNDc5XSAzM2M3NSBpcyAyNTRjODAwMCENClsgIDE1NC41NDE1MzJdIDMzYzc3IGlzIDI1
NGM3MDAwIQ0KWyAgMTU0LjU0MzYzOV0gMzNjNzYgaXMgMjU0YzYwMDAhDQpbICAxNTQuNTQ1
OTI0XSAzM2M3OCBpcyAyNTRjNTAwMCENClsgIDE1NC41NDgwOTRdIDMzYzhmIGlzIDI1NGM0
MDAwIQ0KWyAgMTU0LjU1MDI4NF0gMzNjNzkgaXMgMjU0YzMwMDAhDQpbICAxNTQuNTUyNTU3
XSAzM2M3YSBpcyAyNTRjMjAwMCENClsgIDE1NC41NTU2NDZdIDMzYzkwIGlzIDI1NGMxMDAw
IQ0KWyAgMTU0LjU1Nzc5NV0gMzNjN2IgaXMgMjU0YzAwMDAhDQpbICAxNTQuNTU5OTM5XSAz
M2M5MSBpcyAyNTRiZjAwMCENClsgIDE1NC41NjIwOTldIDMzYzdjIGlzIDI1NGJlMDAwIQ0K
WyAgMTU0LjU2NDIzNl0gMzNjOTIgaXMgMjU0YmQwMDAhDQpbICAxNTQuNTY2NDE2XSAzM2M5
MyBpcyAyNTRiYzAwMCENClsgIDE1NC41Njg1NDddIDMzYzdkIGlzIDI1NGJiMDAwIQ0KWyAg
MTU0LjU3MDY2MF0gMzNjOTQgaXMgMjU0YmEwMDAhDQpbICAxNTQuNTcyODA2XSAzM2M5NSBp
cyAyNTRiOTAwMCENClsgIDE1NC41NzQ5ODNdIDMzYzdlIGlzIDI1NGI4MDAwIQ0KWyAgMTU0
LjYwNjE1Nl0gMzNjN2YgaXMgMjU0YjcwMDAhDQpbICAxNTQuNjA4MzI1XSAzM2M5NiBpcyAy
NTRiNjAwMCENClsgIDE1NC42MTA0ODFdIDMzYzk3IGlzIDI1NGI1MDAwIQ0KWyAgMTU0LjYx
MjY1Nl0gMzNjOTggaXMgMjU0YjQwMDAhDQpbICAxNTQuNjE0ODIyXSAzM2M4MCBpcyAyNTRi
MzAwMCENClsgIDE1NC42MTY5MzddIDMzYzk5IGlzIDI1NGIyMDAwIQ0KWyAgMTU0LjY3NTAw
Ml0gMzNjODEgaXMgMjU0YjEwMDAhDQpbICAxNTQuNjc3MTc0XSAzM2M5YSBpcyAyNTRiMDAw
MCENClsgIDE1NC42ODU3MTBdIDMzYzliIGlzIDI1NGFmMDAwIQ0KWyAgMTU0LjY4ODAwNV0g
MzNjODIgaXMgMjU0YWUwMDAhDQpbICAxNTQuNjkwMjM3XSAzM2M4MyBpcyAyNTRhZDAwMCEN
ClsgIDE1NC42OTI0MTBdIDMzYzg0IGlzIDI1NGFjMDAwIQ0KWyAgMTU0LjY5NDYxMl0gMzNj
ODUgaXMgMjU0YWIwMDAhDQpbICAxNTQuNzAwNDc1XSAzM2M5YyBpcyAyNTRhYTAwMCENClsg
IDE1NC43MDI3MDNdIDMzYzg2IGlzIDI1NGE5MDAwIQ0KWyAgMTU0LjcwNTA4NV0gMzNjODcg
aXMgMjU0YTgwMDAhDQpbICAxNTQuNzA3NDEzXSAzM2M4OCBpcyAyNTRhNzAwMCENClsgIDE1
NC43MjY4OTBdIDMzYzg5IGlzIDI1NGE2MDAwIQ0KWyAgMTU0LjczOTk5M10gMzNjOWQgaXMg
MjU0YTUwMDAhDQpbICAxNTQuNzU3MzY4XSAzM2M4YSBpcyAyNTRhNDAwMCENClsgIDE1NC43
NzkxNjZdIDMzYzllIGlzIDI1NGEzMDAwIQ0KWyAgMTU0Ljc5MjgxNl0gMzNjOWYgaXMgMjU0
YTIwMDAhDQpbICAxNTQuODAzOTI2XSAzM2M4YyBpcyAyNTRhMTAwMCENClsgIDE1NC44MDcw
NjddIDMzYzhkIGlzIDI1NDYyMDAwIQ0KWyAgMTU0LjgyNzU5Nl0gMzNjYWQgaXMgMjU0NjMw
MDAhDQpbICAxNTQuODMxNTQ5XSAzM2NhMCBpcyAyNTQ2NDAwMCENClsgIDE1NC44MzM3NjFd
IDMzY2FlIGlzIDI1NDY1MDAwIQ0KWyAgMTU0Ljg0Mzk5OV0gMzNjYWYgaXMgMjU0NjYwMDAh
DQpbICAxNTQuODg2MzAyXSAzM2NiMSBpcyAyNTQ2NzAwMCENClsgIDE1NC45MTE4MTJdIDMz
Y2IyIGlzIDI1NDY4MDAwIQ0KWyAgMTU0LjkzMDUzNF0gMzNjYjMgaXMgMjU0NjkwMDAhDQpb
ICAxNTQuOTUzNzM3XSAzM2NiNCBpcyAyNTQ2YTAwMCENClsgIDE1NC45NTU5NzhdIDM2NGVj
IGlzIDI1NDZiMDAwIQ0KWyAgMTU0Ljk2MjM3Nl0gMzNjYjYgaXMgMjU0NmMwMDAhDQpbICAx
NTQuOTcwNTkwXSAzM2NiNyBpcyAyNTQ2ZDAwMCENClsgIDE1NC45ODI4NjBdIDMzY2I4IGlz
IDI1NDZlMDAwIQ0KWyAgMTU0Ljk4ODQyNF0gMzNjYjkgaXMgMjU0NmYwMDAhDQpbICAxNTQu
OTkyNjQ3XSAzM2NiYSBpcyAyNTQ3MDAwMCENClsgIDE1NS4wMTQ0NjRdIDMzY2JiIGlzIDI1
NDcxMDAwIQ0KWyAgMTU1LjAxNjc4NV0gMzNjOGIgaXMgMjU0NzIwMDAhDQpbICAxNTUuMDMx
MzA5XSAzM2NiZCBpcyAyNTQ3MzAwMCENClsgIDE1NS4wNDA1MDhdIDMzY2JlIGlzIDI1NDc0
MDAwIQ0KWyAgMTU1LjA0Mzk1N10gMzNjYmYgaXMgMjU0NzUwMDAhDQpbICAxNTUuMDY1MDE4
XSAzM2NjMCBpcyAyNTQ3NjAwMCENClsgIDE1NS4wNjczNzldIDMzY2JjIGlzIDI1NDc3MDAw
IQ0KWyAgMTU1LjA4MjMwOF0gMzNjYzEgaXMgMjU0NzgwMDAhDQpbICAxNTUuMDkxMjMyXSAz
NzZiMiBpcyAyNTQ3OTAwMCENClsgIDE1NS4wOTc0NTRdIDMzY2MyIGlzIDI1NDdhMDAwIQ0K
WyAgMTU1LjA5OTc0Ml0gMzNjYzMgaXMgMjU0N2IwMDAhDQpbICAxNTUuMTA3ODIzXSAzM2Nj
NCBpcyAyNTQ3YzAwMCENClsgIDE1NS4xMTAxMzNdIDMzY2M1IGlzIDI1NDdkMDAwIQ0KWyAg
MTU1LjExMjQ5Ml0gMzNjYzYgaXMgMjU0N2UwMDAhDQpbICAxNTUuMTIzMTYzXSAzM2NjNyBp
cyAyNTQ3ZjAwMCENClsgIDE1NS4xMjY2MzJdIDMzY2ExIGlzIDI1NDliMDAwIQ0KWyAgMTU1
LjEzMDE2OF0gMzNjYTIgaXMgMjU0OGMwMDAhDQpbICAxNTUuMTU1MTA0XSAzM2NhMyBpcyAy
NTQ4ZDAwMCENClsgIDE1NS4xNzE0NDBdIDMzY2E0IGlzIDI1NDhiMDAwIQ0KWyAgMTU1LjE3
MzkyM10gMzNjYTUgaXMgMjU0OTIwMDAhDQpbICAxNTUuMTc1Nzc2XSAzM2NjOCBpcyAyNTQ5
MTAwMCENClsgIDE1NS4xNzc2NThdIDMzY2M5IGlzIDI1NDkwMDAwIQ0KWyAgMTU1LjE3OTQ5
MV0gMzNjY2EgaXMgMjU0OGEwMDAhDQpbICAxNTUuMTk5NDM1XSAzM2NhNiBpcyAyNTQ5MzAw
MCENClsgIDE1NS4yMjg2MjJdIDMzY2E3IGlzIDI1NDk1MDAwIQ0KWyAgMTU1LjI1OTI2MV0g
MzNjYTggaXMgMjU0OGYwMDAhDQpbICAxNTUuMjkwMDg1XSAzM2NhOSBpcyAyNTQ5ODAwMCEN
ClsgIDE1NS4zMDM1ODFdIDMzY2FiIGlzIDI1NDk2MDAwIQ0KWyAgMTU1LjMzNzg1Nl0gMzNj
YWMgaXMgMjU0ODAwMDAhDQpbICAxNTUuMzU2NTQ3XSAzM2NjYyBpcyAyNTQ4ZTAwMCENClsg
IDE1NS4zNTg0NzFdIDMzY2NiIGlzIDI1NDljMDAwIQ0KWyAgMTU1LjM2MDM1OF0gMzNjZWIg
aXMgMjU0OTcwMDAhDQpbICAxNTUuMzYyMTkwXSAzM2NlYyBpcyAyNTRhMDAwMCENClsgIDE1
NS4zOTAzOTRdIDMzY2NkIGlzIDI1NDlhMDAwIQ0KWyAgMTU1LjQwODIxNl0gMzNjY2UgaXMg
MjU0OTkwMDAhDQpbICAxNTUuNDE1NTA3XSAzM2NlZCBpcyAyNTUxMzAwMCENClsgIDE1NS40
MzQzNDBdIDMzY2VlIGlzIDI1NDg1MDAwIQ0KWyAgMTU1LjQ0MDYxNl0gMzNjZWYgaXMgMjU0
ODYwMDAhDQpbICAxNTUuNDQyOTc5XSAzM2NmMCBpcyAyNTBiYjAwMCENClsgIDE1NS40Njg4
MzNdIDMzY2YxIGlzIDI1NTIyMDAwIQ0KWyAgMTU1LjQ3MTI2M10gMzNjY2YgaXMgMjUwYmMw
MDAhDQpbICAxNTUuNDkwNzgxXSAzM2NmMiBpcyAyNTQ5ZDAwMCENClsgIDE1NS40OTQ4MzBd
IDMzY2YzIGlzIDI0ZTFhMDAwIQ0KWyAgMTU1LjQ5ODM0OV0gMzNjZjQgaXMgMjU1MjQwMDAh
DQpbICAxNTUuNTAwODM2XSAzM2NmNSBpcyAyNTUyMzAwMCENClsgIDE1NS41MTE3MzFdIDMz
Y2Y2IGlzIDI1NDYxMDAwIQ0KWyAgMTU1LjUzMDE5MV0gMzNjZjcgaXMgMjU0ZmMwMDAhDQpb
ICAxNTUuNTM0MTE4XSAzM2NkMCBpcyAyNTRmYjAwMCENClsgIDE1NS41Mzg2NDRdIDMzY2Y4
IGlzIDI1NDVlMDAwIQ0KWyAgMTU1LjU0NDgyNV0gMzNjZjkgaXMgMjU0NWQwMDAhDQpbICAx
NTUuNTQ5NzIyXSAzM2NmYSBpcyAyNTQ4NDAwMCENClsgIDE1NS41NTI0ODNdIDMzY2ZiIGlz
IDI1NDgzMDAwIQ0KWyAgMTU1LjU1NDk2OF0gMzNjZmMgaXMgMjU0ODIwMDAhDQpbICAxNTUu
NTY0NzgzXSAzM2NmZCBpcyAyNTQ4MTAwMCENClsgIDE1NS41ODA3ODFdIDMzY2ZlIGlzIDI1
NDVjMDAwIQ0KWyAgMTU1LjU4NzI2OF0gMzNjZDEgaXMgMjU0NWIwMDAhDQpbICAxNTUuNjA5
Nzg5XSAzM2NmZiBpcyAyNTQ1YTAwMCENClsgIDE1NS42MjAyMzRdIDMzY2QyIGlzIDI1NDU5
MDAwIQ0KWyAgMTU1LjYyMjY0MF0gMzNkMDAgaXMgMjU0NTgwMDAhDQpbICAxNTUuNjU3Nzkx
XSAzM2QwMSBpcyAyNTQ1NzAwMCENClsgIDE1NS42ODk3NjZdIDMzY2QzIGlzIDI1NDU2MDAw
IQ0KWyAgMTU1LjY5OTgwOF0gMzNjZDQgaXMgMjU0NTUwMDAhDQpbICAxNTUuNzI4Nzk5XSAz
M2QwMiBpcyAyNTQ1NDAwMCENClsgIDE1NS43NDE0NTNdIDMzY2Q1IGlzIDI1NDQ5MDAwIQ0K
WyAgMTU1Ljc0MzY3Ml0gMzNkMDMgaXMgMjU0NGEwMDAhDQpbICAxNTUuNzQ1NzEzXSAzM2Qw
NCBpcyAyNTQ0YjAwMCENClsgIDE1NS43NDc3NTldIDMzZDA1IGlzIDI1NDRjMDAwIQ0KWyAg
MTU1Ljc0OTY4NV0gMzNkMDYgaXMgMjU0NGQwMDAhDQpbICAxNTUuNzUxNjMwXSAzM2QwNyBp
cyAyNTQ0ZTAwMCENClsgIDE1NS43NTM1NTddIDMzZDA4IGlzIDI1NDRmMDAwIQ0KWyAgMTU1
Ljc1NTQ1Nl0gMzNkMDkgaXMgMjU0NTAwMDAhDQpbICAxNTUuNzU3MzQyXSAzM2QwYSBpcyAy
NTQ1MTAwMCENClsgIDE1NS43NTkyMDZdIDMzZDBiIGlzIDI1NDUyMDAwIQ0KWyAgMTU1Ljc2
MTA0OV0gMzNkMGMgaXMgMjU0NTMwMDAhDQpbICAxNTUuNzYyOTQwXSAzM2QxOCBpcyAyNTQz
NDAwMCENClsgIDE1NS43NjQ3OTFdIDMzZDE5IGlzIDI1NDM1MDAwIQ0KWyAgMTU1Ljc2NjU5
MV0gMzNkMWEgaXMgMjU0MzYwMDAhDQpbICAxNTUuNzY4Mzk4XSAzM2QxYiBpcyAyNTQzNzAw
MCENClsgIDE1NS43NzAxNzZdIDMzZDFjIGlzIDI1NDM4MDAwIQ0KWyAgMTU1Ljc3MTk1NV0g
MzNkMWQgaXMgMjU0MzkwMDAhDQpbICAxNTUuNzczNzI0XSAzM2QxZSBpcyAyNTQzYTAwMCEN
ClsgIDE1NS43NzU0ODNdIDMzZDFmIGlzIDI1NDNiMDAwIQ0KWyAgMTU1Ljc3NzI0Nl0gMzNk
MjAgaXMgMjU0M2MwMDAhDQpbICAxNTUuNzc4OTkyXSAzM2QyMSBpcyAyNTQzZDAwMCENClsg
IDE1NS43ODExNzhdIDMzZDIyIGlzIDI1NDI5MDAwIQ0KWyAgMTU1Ljc4Mjk1Nl0gMzNkMjMg
aXMgMjU0MmEwMDAhDQpbICAxNTUuNzg0NzU3XSAzM2QyNCBpcyAyNTQyYjAwMCENClsgIDE1
NS43ODY1MDJdIDMzZDI1IGlzIDI1NDJjMDAwIQ0KWyAgMTU1Ljc4ODI2NV0gMzNkMjYgaXMg
MjU0MmQwMDAhDQpbICAxNTUuNzg5OTgyXSAzM2QyNyBpcyAyNTQyZTAwMCENClsgIDE1NS43
OTE3MDZdIDMzZDI4IGlzIDI1NDJmMDAwIQ0KWyAgMTU1Ljc5MzQ0Nl0gMzNkMjkgaXMgMjU0
MzAwMDAhDQpbICAxNTUuNzk1MTQwXSAzM2QyYSBpcyAyNTQzMTAwMCENClsgIDE1NS43OTY4
NjJdIDMzZDJiIGlzIDI1NDMyMDAwIQ0KWyAgMTU1Ljc5ODUyNl0gMzNkMmMgaXMgMjU0MzMw
MDAhDQpbICAxNTUuODAwMjAwXSAzM2QyZCBpcyAyNTQxZTAwMCENClsgIDE1NS44MDE4NDdd
IDMzZDJlIGlzIDI1NDFmMDAwIQ0KWyAgMTU1LjgwMzUxNF0gMzNkMmYgaXMgMjU0MjAwMDAh
DQpbICAxNTUuODA1MTg5XSAzM2QzMCBpcyAyNTQyMTAwMCENClsgIDE1NS44MDY4NzFdIDMz
ZDMxIGlzIDI1NDIyMDAwIQ0KWyAgMTU1LjgwODU1MF0gMzNkMzIgaXMgMjU0MjMwMDAhDQpb
ICAxNTUuODEwMjM0XSAzM2QzMyBpcyAyNTQyNDAwMCENClsgIDE1NS44MTE5MDJdIDMzZDM0
IGlzIDI1NDI1MDAwIQ0KWyAgMTU1LjgxMzYwMF0gMzNkMzUgaXMgMjU0MjYwMDAhDQpbICAx
NTUuODE1MjYxXSAzM2QzNiBpcyAyNTQyNzAwMCENClsgIDE1NS44MTY5NDVdIDMzZDM3IGlz
IDI1NDI4MDAwIQ0KWyAgMTU1LjgxODU5NV0gMzNkMzggaXMgMjU0MTQwMDAhDQpbICAxNTUu
ODIwMjU4XSAzM2QzOSBpcyAyNTQxNTAwMCENClsgIDE1NS44MjE5NDFdIDMzZDNhIGlzIDI1
NDE2MDAwIQ0KWyAgMTU1LjgyMzYyOV0gMzNkM2IgaXMgMjU0MTcwMDAhDQpbICAxNTUuODI1
MzEwXSAzM2QzYyBpcyAyNTQxODAwMCENClsgIDE1NS44MjY5OTFdIDMzZDNkIGlzIDI1NDE5
MDAwIQ0KWyAgMTU1LjgyODY1OV0gMzNkM2UgaXMgMjU0MWEwMDAhDQpbICAxNTUuODMwMzU2
XSAzM2QzZiBpcyAyNTQxYjAwMCENClsgIDE1NS44MzIwMTddIDMzZDQwIGlzIDI1NDFjMDAw
IQ0KWyAgMTU1LjgzMzcxMV0gMzNkNDEgaXMgMjU0MWQwMDAhDQpbICAxNTUuODM1MzYxXSAz
M2QwZCBpcyAyNTQzZTAwMCENClsgIDE1NS44MzcwMzBdIDMzZDBlIGlzIDI1NDNmMDAwIQ0K
WyAgMTU1LjgzODcwN10gMzNkMGYgaXMgMjU0NDAwMDAhDQpbICAxNTUuODQwMzg4XSAzM2Qx
MCBpcyAyNTQ0MTAwMCENClsgIDE1NS44NDIwODRdIDMzZDExIGlzIDI1NDQyMDAwIQ0KWyAg
MTU1Ljg0MzgxNV0gMzNkMTIgaXMgMjU0NDMwMDAhDQpbICAxNTUuODQ1NDgyXSAzM2QxMyBp
cyAyNTQ0NDAwMCENClsgIDE1NS44NDcxNzldIDMzZDE0IGlzIDI1NDQ1MDAwIQ0KWyAgMTU1
Ljg0ODg1M10gMzNkMTUgaXMgMjU0NDYwMDAhDQpbICAxNTUuODUwNTU2XSAzM2QxNiBpcyAy
NTQ0NzAwMCENClsgIDE1NS44NTIyMjldIDMzZDE3IGlzIDI1NDQ4MDAwIQ0KWyAgMTU1Ljg1
NTYwMV0gMzNkNWEgaXMgMjUzZjQwMDAhDQpbICAxNTUuODU3MzcyXSAzM2Q1YiBpcyAyNTNm
NTAwMCENClsgIDE1NS44NTkwNjhdIDMzZDVjIGlzIDI1M2Y2MDAwIQ0KWyAgMTU1Ljg2MDc2
OF0gMzNkNWQgaXMgMjUzZjcwMDAhDQpbICAxNTUuODYyNDM2XSAzM2Q1ZSBpcyAyNTNmODAw
MCENClsgIDE1NS44NjQxMzldIDMzZDVmIGlzIDI1M2Y5MDAwIQ0KWyAgMTU1Ljg2NTc5NV0g
MzNkNjAgaXMgMjUzZmEwMDAhDQpbICAxNTUuODY3NDgxXSAzM2Q2MSBpcyAyNTNmYjAwMCEN
ClsgIDE1NS44NjkxNTldIDMzZDYyIGlzIDI1M2ZjMDAwIQ0KWyAgMTU1Ljg3MDg1MV0gMzNk
NjMgaXMgMjUzZmQwMDAhDQpbICAxNTUuODcyNTA5XSAzM2Q0MiBpcyAyNTQwOTAwMCENClsg
IDE1NS44NzQyMDNdIDMzZDQzIGlzIDI1NDBhMDAwIQ0KWyAgMTU1Ljg3NTg4NF0gMzNkNDQg
aXMgMjU0MGIwMDAhDQpbICAxNTUuODc3NTY2XSAzM2Q0NSBpcyAyNTQwYzAwMCENClsgIDE1
NS44NzkyNDZdIDMzZDQ2IGlzIDI1NDBkMDAwIQ0KWyAgMTU1Ljg4MDkyM10gMzNkNDcgaXMg
MjU0MGUwMDAhDQpbICAxNTUuODgyNTg3XSAzM2Q0YSBpcyAyNTQwZjAwMCENClsgIDE1NS44
ODQyODddIDMzZDRiIGlzIDI1NDEwMDAwIQ0KWyAgMTU1Ljg4NTk0NV0gMzNkNGMgaXMgMjU0
MTEwMDAhDQpbICAxNTUuODg3NjMwXSAzM2Q0ZCBpcyAyNTQxMjAwMCENClsgIDE1NS44ODky
OTZdIDMzZDRlIGlzIDI1NDEzMDAwIQ0KWyAgMTU1Ljg5MDk2MF0gMzNkNGYgaXMgMjUzZmUw
MDAhDQpbICAxNTUuODkyNjQzXSAzM2Q1MCBpcyAyNTNmZjAwMCENClsgIDE1NS44OTQzMjVd
IDMzZDUxIGlzIDI1NDAwMDAwIQ0KWyAgMTU1Ljg5NjAwN10gMzNkNTIgaXMgMjU0MDEwMDAh
DQpbICAxNTUuODk3NjkzXSAzM2Q1MyBpcyAyNTQwMjAwMCENClsgIDE1NS44OTkzNjhdIDMz
ZDU0IGlzIDI1NDAzMDAwIQ0KWyAgMTU1LjkwMTA3MF0gMzNkNTUgaXMgMjU0MDQwMDAhDQpb
ICAxNTUuOTAyNzUzXSAzM2Q1NiBpcyAyNTQwNTAwMCENClsgIDE1NS45MDQ0NjldIDMzZDU3
IGlzIDI1NDA2MDAwIQ0KWyAgMTU1LjkwNjE1Ml0gMzNkNTggaXMgMjU0MDcwMDAhDQpbICAx
NTUuOTA3ODUwXSAzM2Q1OSBpcyAyNTQwODAwMCENClsgIDE1NS45MTA0NTldIDMzZDZmIGlz
IDI1M2RlMDAwIQ0KWyAgMTU1LjkxMjE1OF0gMzNkNzAgaXMgMjUzZGYwMDAhDQpbICAxNTUu
OTE0MTA0XSAzM2Q3MSBpcyAyNTNlMDAwMCENClsgIDE1NS45MTU4MDZdIDMzZDcyIGlzIDI1
M2UxMDAwIQ0KWyAgMTU1LjkxNzU0Ml0gMzNkNzMgaXMgMjUzZTIwMDAhDQpbICAxNTUuOTE5
MjQ3XSAzM2Q3NCBpcyAyNTNlMzAwMCENClsgIDE1NS45MjA5NzFdIDMzZDc1IGlzIDI1M2U0
MDAwIQ0KWyAgMTU1LjkyMjY2Ml0gMzNkNzYgaXMgMjUzZTUwMDAhDQpbICAxNTUuOTI0MzY0
XSAzM2Q3NyBpcyAyNTNlNjAwMCENClsgIDE1NS45MjYwODNdIDMzZDc4IGlzIDI1M2U3MDAw
IQ0KWyAgMTU1LjkyNzc2MV0gMzNkNzkgaXMgMjUzZTgwMDAhDQpbICAxNTUuOTI5NDY3XSAz
M2Q3YSBpcyAyNTNkNDAwMCENClsgIDE1NS45MzExNDJdIDMzZDdiIGlzIDI1M2Q1MDAwIQ0K
WyAgMTU1LjkzMjgwOV0gMzNkN2MgaXMgMjUzZDYwMDAhDQpbICAxNTUuOTM0NTE0XSAzM2Q3
ZCBpcyAyNTNkNzAwMCENClsgIDE1NS45MzYxODFdIDMzZDdlIGlzIDI1M2Q4MDAwIQ0KWyAg
MTU1LjkzNzg4Ml0gMzNkN2YgaXMgMjUzZDkwMDAhDQpbICAxNTUuOTM5NTQ5XSAzM2Q4MCBp
cyAyNTNkYTAwMCENClsgIDE1NS45NDEyMzddIDMzZDgxIGlzIDI1M2RiMDAwIQ0KWyAgMTU1
Ljk0MjkzMV0gMzNkODIgaXMgMjUzZGMwMDAhDQpbICAxNTUuOTQ0NjE5XSAzM2Q4MyBpcyAy
NTNkZDAwMCENClsgIDE1NS45NDYyOTFdIDMzZDZlIGlzIDI1M2I4MDAwIQ0KWyAgMTU1Ljk0
Nzk2Nl0gMzNkNmQgaXMgMjUzYjEwMDAhDQpbICAxNTUuOTQ5NjE2XSAzM2Q2YyBpcyAyNTNi
MDAwMCENClsgIDE1NS45NTEyOTFdIDMzZDZiIGlzIDI1M2FmMDAwIQ0KWyAgMTU1Ljk1Mjk0
Nl0gMzNkNmEgaXMgMjUzYWUwMDAhDQpbICAxNTUuOTU0NjMzXSAzM2Q2OSBpcyAyNTNhZDAw
MCENClsgIDE1NS45NTYyNzZdIDMzZDY4IGlzIDI1M2FjMDAwIQ0KWyAgMTU1Ljk1NzkzNF0g
MzNkNjcgaXMgMjUzYWIwMDAhDQpbICAxNTUuOTU5NTk1XSAzM2Q2NiBpcyAyNTNhYTAwMCEN
ClsgIDE1NS45NjEyNTJdIDMzZDY1IGlzIDI1M2E5MDAwIQ0KWyAgMTU1Ljk2MjkyNF0gMzNk
NjQgaXMgMjUzYTgwMDAhDQpbICAxNTUuOTY1Nzg3XSAzM2NkZiBpcyAyNTNjODAwMCENClsg
IDE1NS45Njc2NjZdIDMzY2RlIGlzIDI1M2M5MDAwIQ0KWyAgMTU1Ljk2OTMxOF0gMzNjZGQg
aXMgMjUzY2EwMDAhDQpbICAxNTUuOTcxMDA1XSAzM2NkYyBpcyAyNTNhNzAwMCENClsgIDE1
NS45NzI2NzJdIDMzY2RiIGlzIDI0ZTlkMDAwIQ0KWyAgMTU1Ljk3NDM4MV0gMzNjZGEgaXMg
MjQ4ZmEwMDAhDQpbICAxNTUuOTc2MDkyXSAzM2NkOSBpcyAyNTNiNjAwMCENClsgIDE1NS45
Nzc4MjBdIDMzY2Q4IGlzIDI0ZTljMDAwIQ0KWyAgMTU1Ljk3OTU3M10gMzNjZDcgaXMgMjU0
ODcwMDAhDQpbICAxNTUuOTgxMzQwXSAzM2NkNiBpcyAyNTNjYjAwMCENClsgIDE1NS45ODMx
MTBdIDMzZDg0IGlzIDI1M2NkMDAwIQ0KWyAgMTU1Ljk4NDkxOV0gMzNjZWEgaXMgMjUzOWQw
MDAhDQpbICAxNTUuOTg2Njk1XSAzM2NlOSBpcyAyNTM5ZTAwMCENClsgIDE1NS45ODg1MDNd
IDMzY2U4IGlzIDI1MzlmMDAwIQ0KWyAgMTU1Ljk5MDI5NV0gMzNjZTcgaXMgMjUzYTAwMDAh
DQpbICAxNTUuOTkyMDk5XSAzM2NlNiBpcyAyNTNhMTAwMCENClsgIDE1NS45OTM5MDNdIDMz
Y2U1IGlzIDI1M2EyMDAwIQ0KWyAgMTU1Ljk5NTY5OV0gMzNjZTQgaXMgMjUzYTMwMDAhDQpb
ICAxNTUuOTk3NDkwXSAzM2NlMyBpcyAyNTNhNDAwMCENClsgIDE1NS45OTkyNjZdIDMzY2Uy
IGlzIDI1M2E1MDAwIQ0KWyAgMTU2LjAwMTA3NF0gMzNjZTEgaXMgMjUzYTYwMDAhDQpbICAx
NTYuMDAyODU2XSAzM2NlMCBpcyAyNTNjNzAwMCENClsgIDE1Ni4wMDQ5NTBdIDMzZDk0IGlz
IDI1Mzg4MDAwIQ0KWyAgMTU2LjAwNjc3OV0gMzNkOTUgaXMgMjUzODkwMDAhDQpbICAxNTYu
MDA4NTg5XSAzM2Q5NiBpcyAyNTM4YTAwMCENClsgIDE1Ni4wMTAzOTNdIDMzZDk3IGlzIDI1
MzhiMDAwIQ0KWyAgMTU2LjAxMjE4Nl0gMzNkOTggaXMgMjUzOGMwMDAhDQpbICAxNTYuMDE0
MDEyXSAzM2Q5OSBpcyAyNTM4ZDAwMCENClsgIDE1Ni4wMTU4MDVdIDMzZDlhIGlzIDI1Mzhl
MDAwIQ0KWyAgMTU2LjAxNzYzMF0gMzNkOWIgaXMgMjUzOGYwMDAhDQpbICAxNTYuMDE5NDE3
XSAzM2Q5YyBpcyAyNTM5MDAwMCENClsgIDE1Ni4wMjEyNDJdIDMzZDlkIGlzIDI1MzkxMDAw
IQ0KWyAgMTU2LjAyMzAyOV0gMzNkOWUgaXMgMjUzOTIwMDAhDQpbICAxNTYuMDI0ODQ3XSAz
M2Q4YSBpcyAyNTM5MzAwMCENClsgIDE1Ni4wMjY2NDBdIDMzZDhiIGlzIDI1Mzk0MDAwIQ0K
WyAgMTU2LjAyODQzMF0gMzNkOGMgaXMgMjUzOTUwMDAhDQpbICAxNTYuMDMwMjE2XSAzM2Q4
ZCBpcyAyNTM5NjAwMCENClsgIDE1Ni4wMzE5NjNdIDMzZDhlIGlzIDI1Mzk3MDAwIQ0KWyAg
MTU2LjAzMzcyM10gMzNkOGYgaXMgMjUzOTgwMDAhDQpbICAxNTYuMDM1NDMwXSAzM2Q5MCBp
cyAyNTM5OTAwMCENClsgIDE1Ni4wMzcxNDBdIDMzZDkxIGlzIDI1MzlhMDAwIQ0KWyAgMTU2
LjAzODgyOV0gMzNkOTIgaXMgMjUzOWIwMDAhDQpbICAxNTYuMDQwNTEwXSAzM2Q5MyBpcyAy
NTM5YzAwMCENClsgIDE1Ni4wNDIxOTNdIDMzZDlmIGlzIDI1MzdkMDAwIQ0KWyAgMTU2LjA0
Mzg4MF0gMzNkYTAgaXMgMjUzN2UwMDAhDQpbICAxNTYuMDQ1NTcyXSAzM2RhMSBpcyAyNTM3
ZjAwMCENClsgIDE1Ni4wNDcyNTNdIDMzZGEyIGlzIDI1MzgwMDAwIQ0KWyAgMTU2LjA0ODkz
Ml0gMzNkYTMgaXMgMjUzODEwMDAhDQpbICAxNTYuMDUwNjQyXSAzM2RhNCBpcyAyNTM4MjAw
MCENClsgIDE1Ni4wNTIzMjBdIDMzZGE1IGlzIDI1MzgzMDAwIQ0KWyAgMTU2LjA1NDAzM10g
MzNkYTYgaXMgMjUzODQwMDAhDQpbICAxNTYuMDU1NzE3XSAzM2RhNyBpcyAyNTM4NTAwMCEN
ClsgIDE1Ni4wNTczOTldIDMzZGE4IGlzIDI1Mzg2MDAwIQ0KWyAgMTU2LjA1OTA3Nl0gMzNk
YTkgaXMgMjUzODcwMDAhDQpbICAxNTYuMDYwNzQxXSAzM2RhYyBpcyAyNTM3MzAwMCENClsg
IDE1Ni4wNjI0MTVdIDMzZGFkIGlzIDI1Mzc0MDAwIQ0KWyAgMTU2LjA2NDA5N10gMzNkYWUg
aXMgMjUzNzUwMDAhDQpbICAxNTYuMDY1NzU4XSAzM2RhZiBpcyAyNTM3NjAwMCENClsgIDE1
Ni4wNjc0NDldIDMzZGIwIGlzIDI1Mzc3MDAwIQ0KWyAgMTU2LjA2OTExN10gMzNkYjEgaXMg
MjUzNzgwMDAhDQpbICAxNTYuMDcwODEzXSAzM2RiMiBpcyAyNTM3OTAwMCENClsgIDE1Ni4w
NzI0ODBdIDMzZGIzIGlzIDI1MzdhMDAwIQ0KWyAgMTU2LjA3NDE1Nl0gMzNkYjQgaXMgMjUz
N2IwMDAhDQpbICAxNTYuMDc1ODI4XSAzM2RiNSBpcyAyNTM3YzAwMCENClsgIDE1Ni4wNzkx
NDVdIDMzZGRjIGlzIDI1MzUzMDAwIQ0KWyAgMTU2LjA4MDg5NV0gMzNkZGQgaXMgMjUzNTQw
MDAhDQpbICAxNTYuMDgyNTc1XSAzM2RkZSBpcyAyNTM1NTAwMCENClsgIDE1Ni4wODQyOTdd
IDMzZGRmIGlzIDI1MzU2MDAwIQ0KWyAgMTU2LjA4NTk3MF0gMzNkZTAgaXMgMjUzNTcwMDAh
DQpbICAxNTYuMDg3Njc1XSAzM2RlMSBpcyAyNTM1ODAwMCENClsgIDE1Ni4wODkzNjRdIDMz
ZGUyIGlzIDI1MzU5MDAwIQ0KWyAgMTU2LjA5MTA0OV0gMzNkZTMgaXMgMjUzNWEwMDAhDQpb
ICAxNTYuMDkyNzQxXSAzM2RlNCBpcyAyNTM1YjAwMCENClsgIDE1Ni4wOTQ0MzBdIDMzZGU1
IGlzIDI1MzVjMDAwIQ0KWyAgMTU2LjA5NjExN10gMzNkYjYgaXMgMjUzNjgwMDAhDQpbICAx
NTYuMDk3ODA0XSAzM2Q4NSBpcyAyNTM2OTAwMCENClsgIDE1Ni4wOTk0NzRdIDMzZDg2IGlz
IDI1MzZhMDAwIQ0KWyAgMTU2LjEwMTE3NF0gMzNkODcgaXMgMjUzNmIwMDAhDQpbICAxNTYu
MTAyODMyXSAzM2RjYSBpcyAyNTM2YzAwMCENClsgIDE1Ni4xMDQ1MzFdIDMzZGNiIGlzIDI1
MzZkMDAwIQ0KWyAgMTU2LjEwNjE5MF0gMzNkY2MgaXMgMjUzNmUwMDAhDQpbICAxNTYuMTA3
ODY3XSAzM2RjZCBpcyAyNTM2ZjAwMCENClsgIDE1Ni4xMDk1NDddIDMzZGNlIGlzIDI1Mzcw
MDAwIQ0KWyAgMTU2LjExMTIxOF0gMzNkY2YgaXMgMjUzNzEwMDAhDQpbICAxNTYuMTEyODk2
XSAzM2RkMCBpcyAyNTM3MjAwMCENClsgIDE1Ni4xMTQ1NzddIDMzZGQxIGlzIDI1MzVkMDAw
IQ0KWyAgMTU2LjExNjI1OV0gMzNkZDIgaXMgMjUzNWUwMDAhDQpbICAxNTYuMTE3OTM0XSAz
M2RkMyBpcyAyNTM1ZjAwMCENClsgIDE1Ni4xMTk1OTZdIDMzZGQ0IGlzIDI1MzYwMDAwIQ0K
WyAgMTU2LjEyMTI5NF0gMzNkZDUgaXMgMjUzNjEwMDAhDQpbICAxNTYuMTIyOTU1XSAzM2Rk
NiBpcyAyNTM2MjAwMCENClsgIDE1Ni4xMjQ2NDVdIDMzZGQ3IGlzIDI1MzYzMDAwIQ0KWyAg
MTU2LjEyNjMwMF0gMzNkZDggaXMgMjUzNjQwMDAhDQpbICAxNTYuMTI3OTcwXSAzM2RkOSBp
cyAyNTM2NTAwMCENClsgIDE1Ni4xMjk2MzddIDMzZGRhIGlzIDI1MzY2MDAwIQ0KWyAgMTU2
LjEzMTMwMl0gMzNkZGIgaXMgMjUzNjcwMDAhDQpbICAxNTYuMTMzOTg0XSAzM2RmMSBpcyAy
NTMzZDAwMCENClsgIDE1Ni4xMzU2NzBdIDMzZGYyIGlzIDI1MzNlMDAwIQ0KWyAgMTU2LjEz
NzQwMF0gMzNkZjMgaXMgMjUzM2YwMDAhDQpbICAxNTYuMTM5MTI0XSAzM2RmNCBpcyAyNTM0
MDAwMCENClsgIDE1Ni4xNDA4MTZdIDMzZGY1IGlzIDI1MzQxMDAwIQ0KWyAgMTU2LjE0MjUy
MF0gMzNkZjYgaXMgMjUzNDIwMDAhDQpbICAxNTYuMTQ0MjE0XSAzM2RmNyBpcyAyNTM0MzAw
MCENClsgIDE1Ni4xNDU5MTNdIDMzZGY4IGlzIDI1MzQ0MDAwIQ0KWyAgMTU2LjE0NzYwNl0g
MzNkZjkgaXMgMjUzNDUwMDAhDQpbICAxNTYuMTQ5Mjg5XSAzM2RmYSBpcyAyNTM0NjAwMCEN
ClsgIDE1Ni4xNTA5NzddIDMzZGZiIGlzIDI1MzQ3MDAwIQ0KWyAgMTU2LjE1MjYzMF0gMzNk
ZmMgaXMgMjUzMzMwMDAhDQpbICAxNTYuMTU0MzMxXSAzM2RmZCBpcyAyNTMzNDAwMCENClsg
IDE1Ni4xNTU5OTBdIDMzZGZlIGlzIDI1MzM1MDAwIQ0KWyAgMTU2LjE1NzY2MV0gMzNkZmYg
aXMgMjUzMzYwMDAhDQpbICAxNTYuMTU5MzM2XSAzM2UwMCBpcyAyNTMzNzAwMCENClsgIDE1
Ni4xNjEwMjVdIDMzZTAxIGlzIDI1MzM4MDAwIQ0KWyAgMTU2LjE2MjcxN10gMzNlMDIgaXMg
MjUzMzkwMDAhDQpbICAxNTYuMTY0NDE0XSAzM2UwMyBpcyAyNTMzYTAwMCENClsgIDE1Ni4x
NjYwNzhdIDMzZTA0IGlzIDI1MzNiMDAwIQ0KWyAgMTU2LjE2Nzc3MV0gMzNlMDUgaXMgMjUz
M2MwMDAhDQpbICAxNTYuMTY5NDI0XSAzM2RmMCBpcyAyNTMyODAwMCENClsgIDE1Ni4xNzEx
MTZdIDMzZGVmIGlzIDI1MzI5MDAwIQ0KWyAgMTU2LjE3Mjc4OV0gMzNkZWUgaXMgMjUzMmEw
MDAhDQpbICAxNTYuMTc0NDcxXSAzM2RlZCBpcyAyNTMyYjAwMCENClsgIDE1Ni4xNzYxNTFd
IDMzZGVjIGlzIDI1MzJjMDAwIQ0KWyAgMTU2LjE3NzgyNl0gMzNkZWIgaXMgMjUzMmQwMDAh
DQpbICAxNTYuMTc5NTA5XSAzM2RlYSBpcyAyNTMyZTAwMCENClsgIDE1Ni4xODExOTFdIDMz
ZGU5IGlzIDI1MzJmMDAwIQ0KWyAgMTU2LjE4Mjg4NF0gMzNkZTggaXMgMjUzMzAwMDAhDQpb
ICAxNTYuMTg0NTgyXSAzM2RlNyBpcyAyNTMzMTAwMCENClsgIDE1Ni4xODYyNTVdIDMzZGU2
IGlzIDI1MzMyMDAwIQ0KWyAgMTU2LjE4ODkzMV0gMzNkYzEgaXMgMjUzMTMwMDAhDQpbICAx
NTYuMTkwNjU5XSAzM2RjMiBpcyAyNTMxNDAwMCENClsgIDE1Ni4xOTIzODFdIDMzZGMzIGlz
IDI1MzE1MDAwIQ0KWyAgMTU2LjE5NDA5Nl0gMzNkYzQgaXMgMjUzMTYwMDAhDQpbICAxNTYu
MTk1ODA3XSAzM2RjNSBpcyAyNTMxNzAwMCENClsgIDE1Ni4xOTc1MDJdIDMzZGM2IGlzIDI1
MzE4MDAwIQ0KWyAgMTU2LjE5OTE4MV0gMzNkYzcgaXMgMjUzMTkwMDAhDQpbICAxNTYuMjAw
ODkzXSAzM2RjOCBpcyAyNTMxYTAwMCENClsgIDE1Ni4yMDI2MDddIDMzZGM5IGlzIDI1MzFi
MDAwIQ0KWyAgMTU2LjIwNDMzOF0gMzNlMDggaXMgMjUzMWMwMDAhDQpbICAxNTYuMjA2MDM5
XSAzM2RjMCBpcyAyNTMwODAwMCENClsgIDE1Ni4yMDc3NTZdIDMzZGJmIGlzIDI1MzA5MDAw
IQ0KWyAgMTU2LjIwOTUwMF0gMzNkYmUgaXMgMjUzMFsgIDE1OC4zMzYxOTddIDMzZjhlIGlz
IDI1OTc5MDAwIQ0KWyAgMTU4LjMzNzkwM10gMzNmOGYgaXMgMjU5N2EwMDAhDQpbICAxNTgu
MzM5NTgxXSAzM2Y5MCBpcyAyNTk3YjAwMCENClsgIDE1OC4zNDEyODJdIDMzZjkxIGlzIDI1
OTdjMDAwIQ0KWyAgMTU4LjM0Mjk5MF0gMzNmOTIgaXMgMjU5N2QwMDAhDQpbICAxNTguMzQ0
NjkyXSAzM2Y5MyBpcyAyNTk3ZTAwMCENClsgIDE1OC4zNDY0MDVdIDMzZjk0IGlzIDI1OTdm
MDAwIQ0KWyAgMTU4LjM0ODEwNl0gMzNmOTUgaXMgMjU5ODAwMDAhDQpbICAxNTguMzQ5Nzkx
XSAzM2Y5NiBpcyAyNTk4MTAwMCENClsgIDE1OC4zNTE1MDhdIDMzZjk3IGlzIDI1OTgyMDAw
IQ0KWyAgMTU4LjM2MDM4MV0gMzNmYjcgaXMgMjU5NDMwMDAhDQpbICAxNTguMzYyMTIzXSAz
M2ZiOCBpcyAyNTk0NDAwMCENClsgIDE1OC4zNjM4NTldIDMzZmI5IGlzIDI1OTQ1MDAwIQ0K
WyAgMTU4LjM2NTYwM10gMzNmYmEgaXMgMjU5NDYwMDAhDQpbICAxNTguMzY3MzY4XSAzM2Zi
YiBpcyAyNTk0NzAwMCENClsgIDE1OC4zNjkwNzJdIDMzZmJjIGlzIDI1OTQ4MDAwIQ0KWyAg
MTU4LjM3MDc4OF0gMzNmYmQgaXMgMjU5NDkwMDAhDQpbICAxNTguMzcyNTAzXSAzM2ZiZSBp
cyAyNTk0YTAwMCENClsgIDE1OC4zNzQyMDldIDMzZmJmIGlzIDI1OTRiMDAwIQ0KWyAgMTU4
LjM3NTkwOV0gMzNmYzAgaXMgMjU5NGMwMDAhDQpbICAxNTguMzc3NjAxXSAzM2ZjMSBpcyAy
NTk0ZDAwMCENClsgIDE1OC4zNzk2NTBdIDMzZmNjIGlzIDI1OTIzMDAwIQ0KWyAgMTU4LjM4
MTMyOF0gMzNmY2QgaXMgMjU5MjQwMDAhDQpbICAxNTguMzgyOTg4XSAzM2ZjZSBpcyAyNTky
NTAwMCENClsgIDE1OC4zODQ2NzVdIDMzZmNmIGlzIDI1OTI2MDAwIQ0KWyAgMTU4LjM4NjMy
OF0gMzNmZDAgaXMgMjU5MjcwMDAhDQpbICAxNTguMzg4MDE5XSAzM2ZkMSBpcyAyNTkyODAw
MCENClsgIDE1OC4zODk2NzldIDMzZmQyIGlzIDI1OTI5MDAwIQ0KWyAgMTU4LjM5MTM0Nl0g
MzNmZDMgaXMgMjU5MmEwMDAhDQpbICAxNTguMzkzMDEwXSAzM2ZkNCBpcyAyNTkyYjAwMCEN
ClsgIDE1OC4zOTQ2NzNdIDMzZmQ1IGlzIDI1OTJjMDAwIQ0KWyAgMTU4LjM5NjMzNl0gMzNm
ZDYgaXMgMjU5MmQwMDAhDQpbICAxNTguMzk3OTg3XSAzM2ZkNyBpcyAyNTkxOTAwMCENClsg
IDE1OC4zOTk2MjhdIDMzZmQ4IGlzIDI1OTFhMDAwIQ0KWyAgMTU4LjQwMTI5Nl0gMzNmZDkg
aXMgMjU5MWIwMDAhDQpbICAxNTguNDAyOTQ0XSAzM2ZkYyBpcyAyNTkxYzAwMCENClsgIDE1
OC40MDQ2MjJdIDMzZmRkIGlzIDI1OTFkMDAwIQ0KWyAgMTU4LjQwNjI3NV0gMzNmZGUgaXMg
MjU5MWUwMDAhDQpbICAxNTguNDA3OTQzXSAzM2ZkZiBpcyAyNTkxZjAwMCENClsgIDE1OC40
MDk2MThdIDMzZmUwIGlzIDI1OTIwMDAwIQ0KWyAgMTU4LjQxMTI5MV0gMzNmZTEgaXMgMjU5
MjEwMDAhDQpbICAxNTguNDEyOTY5XSAzM2ZlMiBpcyAyNTkyMjAwMCENClsgIDE1OC40MTQ2
MzBdIDMzZmI2IGlzIDI1OTJlMDAwIQ0KWyAgMTU4LjQxNjI4NF0gMzNmYjUgaXMgMjU5MmYw
MDAhDQpbICAxNTguNDE3OTY4XSAzM2ZiNCBpcyAyNTkzMDAwMCENClsgIDE1OC40MTk2Mjld
IDMzZmIzIGlzIDI1OTMxMDAwIQ0KWyAgMTU4LjQyMTMxN10gMzNmYjIgaXMgMjU5MzIwMDAh
DQpbICAxNTguNDIyOTg0XSAzM2ZiMSBpcyAyNTkzMzAwMCENClsgIDE1OC40MjQ2NTZdIDMz
ZmIwIGlzIDI1OTM0MDAwIQ0KWyAgMTU4LjQyNjMzM10gMzNmYWYgaXMgMjU5MzUwMDAhDQpb
ICAxNTguNDI4MDE3XSAzM2ZhZSBpcyAyNTkzNjAwMCENClsgIDE1OC40Mjk3MTJdIDMzZmFk
IGlzIDI1OTM3MDAwIQ0KWyAgMTU4LjQzMTQwMl0gMzNmNzggaXMgMjU5MzgwMDAhDQpbICAx
NTguNDMzMDg3XSAzM2ZjMiBpcyAyNTkzOTAwMCENClsgIDE1OC40MzQ3OTldIDMzZmMzIGlz
IDI1OTNhMDAwIQ0KWyAgMTU4LjQzNjQ4OF0gMzNmYzQgaXMgMjU5M2IwMDAhDQpbICAxNTgu
NDM4MjEzXSAzM2ZjNSBpcyAyNTkzYzAwMCENClsgIDE1OC40Mzk4OTddIDMzZmM2IGlzIDI1
OTNkMDAwIQ0KWyAgMTU4LjQ0MTU5M10gMzNmYzcgaXMgMjU5M2UwMDAhDQpbICAxNTguNDQz
Mjk5XSAzM2ZjOCBpcyAyNTkzZjAwMCENClsgIDE1OC40NDQ5ODldIDMzZmM5IGlzIDI1OTQw
MDAwIQ0KWyAgMTU4LjQ0NjY4NF0gMzNmY2EgaXMgMjU5NDEwMDAhDQpbICAxNTguNDQ4MzY3
XSAzM2ZjYiBpcyAyNTk0MjAwMCENClsgIDE1OC40NTg3OTRdIDMzZmVlIGlzIDI1OTAzMDAw
IQ0KWyAgMTU4LjQ2MDYxNV0gMzNmZWYgaXMgMjU5MDQwMDAhDQpbICAxNTguNDYyMzMxXSAz
M2ZmMCBpcyAyNTkwNTAwMCENClsgIDE1OC40NjQwOTldIDMzZmYxIGlzIDI1OTA2MDAwIQ0K
WyAgMTU4LjQ2NTc3N10gMzNmZjIgaXMgMjU5MDcwMDAhDQpbICAxNTguNDY3NDg2XSAzM2Zm
MyBpcyAyNTkwODAwMCENClsgIDE1OC40NjkxNzJdIDMzZmY0IGlzIDI1OTA5MDAwIQ0KWyAg
MTU4LjQ3MDg4OF0gMzNmZjUgaXMgMjU5MGEwMDAhDQpbICAxNTguNDcyNTYzXSAzM2ZmNiBp
cyAyNTkwYjAwMCENClsgIDE1OC40NzQyNDldIDMzZmY3IGlzIDI1OTBjMDAwIQ0KWyAgMTU4
LjQ3NTkzNF0gMzNmZjggaXMgMjU5MGQwMDAhDQpbICAxNTguNDc4NDQ0XSAzM2ZmOSBpcyAy
NThmOTAwMCENClsgIDE1OC40ODAxNTZdIDMzZmZhIGlzIDI1OGZhMDAwIQ0KWyAgMTU4LjQ4
MTg3NV0gMzNmZmIgaXMgMjU4ZmIwMDAhDQpbICAxNTguNDgzNjYyXSAzM2ZmYyBpcyAyNThm
YzAwMCENClsgIDE1OC40ODUzMjddIDMzZmZkIGlzIDI1OGZkMDAwIQ0KWyAgMTU4LjQ4NzAx
MF0gMzNmZmUgaXMgMjU4ZmUwMDAhDQpbICAxNTguNDg4Njk0XSAzM2ZmZiBpcyAyNThmZjAw
MCENClsgIDE1OC40OTAzNzBdIDMyMDAwIGlzIDI1OTAwMDAwIQ0KWyAgMTU4LjQ5MjA3Nl0g
MzIwMDEgaXMgMjU5MDEwMDAhDQpbICAxNTguNDkzNzc2XSAzMjAwMiBpcyAyNTkwMjAwMCEN
ClsgIDE1OC40OTYxOTNdIDMyMDAzIGlzIDI1OGFlMDAwIQ0KWyAgMTU4LjQ5Nzg5Nl0gMzIw
MDQgaXMgMjU4YWYwMDAhDQpbICAxNTguNDk5NTY4XSAzMjAwNSBpcyAyNThiMDAwMCENClsg
IDE1OC41MDEyNzZdIDMyMDA2IGlzIDI1OGIxMDAwIQ0KWyAgMTU4LjUwMjk2Nl0gMzIwMDcg
aXMgMjU4YjIwMDAhDQpbICAxNTguNTA0NjgwXSAzMjAwOCBpcyAyNThiMzAwMCENClsgIDE1
OC41MDYzNjNdIDMyMDA5IGlzIDI1OGI0MDAwIQ0KWyAgMTU4LjUwODA2NF0gMzIwMGEgaXMg
MjU4YjUwMDAhDQpbICAxNTguNTA5Nzc3XSAzMjAwYiBpcyAyNThiNjAwMCENClsgIDE1OC41
MTE0NzhdIDMyMDBjIGlzIDI1OGI3MDAwIQ0KWyAgMTU4LjUxMzE4NF0gMzIwMGQgaXMgMjU4
YjgwMDAhDQpbICAxNTguNTE0ODc1XSAzM2ZlMyBpcyAyNThjMzAwMCENClsgIDE1OC41MTY1
NzBdIDMzZmU0IGlzIDI1OGM0MDAwIQ0KWyAgMTU4LjUxODI4Ml0gMzNmZTUgaXMgMjU4YzUw
MDAhDQpbICAxNTguNTE5OTY2XSAzM2ZlNiBpcyAyNThjNjAwMCENClsgIDE1OC41MjE2Nzld
IDMzZmU3IGlzIDI1OGM3MDAwIQ0KWyAgMTU4LjUyMzM4MV0gMzNmZTggaXMgMjU4YzgwMDAh
DQpbICAxNTguNTI1MDg2XSAzM2ZlOSBpcyAyNThjOTAwMCENClsgIDE1OC41MjY3NzddIDMz
ZmVhIGlzIDI1OGNhMDAwIQ0KWyAgMTU4LjUyODQ1NV0gMzNmZWIgaXMgMjU4Y2IwMDAhDQpb
ICAxNTguNTMwMTYyXSAzM2ZlYyBpcyAyNThjYzAwMCENClsgIDE1OC41MzE4NDZdIDMzZmVk
IGlzIDI1OGNkMDAwIQ0KWyAgMTU4LjUzMzU1MV0gMzIwMTcgaXMgMjU4YjkwMDAhDQpbICAx
NTguNTM1MjQ2XSAzMjAxNiBpcyAyNThiYTAwMCENClsgIDE1OC41MzY5NTRdIDMyMDE1IGlz
IDI1OGJiMDAwIQ0KWyAgMTU4LjUzODY2NV0gMzIwMTQgaXMgMjU4YmMwMDAhDQpbICAxNTgu
NTQwMzczXSAzMjAxMyBpcyAyNThiZDAwMCENClsgIDE1OC41NDIwOTBdIDMyMDEyIGlzIDI1
OGJlMDAwIQ0KWyAgMTU4LjU0MzgwNF0gMzIwMTEgaXMgMjU4YmYwMDAhDQpbICAxNTguNTQ1
NDcwXSAzMjAxMCBpcyAyNThjMDAwMCENClsgIDE1OC41NDcxNzVdIDMyMDBmIGlzIDI1OGMx
MDAwIQ0KWyAgMTU4LjU0ODg2NV0gMzIwMGUgaXMgMjU4YzIwMDAhDQpbICAxNTguNTUxMjU0
XSAzMjAxZiBpcyAyNTg4ZTAwMCENClsgIDE1OC41NTMwMThdIDMyMDFlIGlzIDI1ODhmMDAw
IQ0KWyAgMTU4LjU1NDc0M10gMzIwMWQgaXMgMjU4OTAwMDAhDQpbICAxNTguNTU2NDI3XSAz
MjAxYyBpcyAyNTg5MTAwMCENClsgIDE1OC41NTgxMzNdIDMyMDFiIGlzIDI1ODkyMDAwIQ0K
WyAgMTU4LjU1OTgzOV0gMzIwMWEgaXMgMjU4OTMwMDAhDQpbICAxNTguNTYxNTM1XSAzMjAx
OSBpcyAyNTg5NDAwMCENClsgIDE1OC41NjMyNDFdIDMzZjdiIGlzIDI1ODk1MDAwIQ0KWyAg
MTU4LjU2NDk1OF0gMzNmN2EgaXMgMjU4OTYwMDAhDQpbICAxNTguNTY2NjgwXSAzM2Y3OSBp
cyAyNTg5NzAwMCENClsgIDE1OC41NjgzOTldIDMyMDE4IGlzIDI1ODk4MDAwIQ0KWyAgMTU4
LjU3MDEyNV0gMzIwMjAgaXMgMjU4OTkwMDAhDQpbICAxNTguNTcxODYwXSAzMjAyMSBpcyAy
NTg5YTAwMCENClsgIDE1OC41NzM1ODldIDMyMDIyIGlzIDI1ODliMDAwIQ0KWyAgMTU4LjU3
NTMyNF0gMzIwMjMgaXMgMjU4OWMwMDAhDQpbICAxNTguNTc3MDQ5XSAzMjAyNCBpcyAyNTg5
ZDAwMCENClsgIDE1OC41Nzg3NjJdIDMyMDI1IGlzIDI1ODllMDAwIQ0KWyAgMTU4LjU4MDUw
OV0gMzIwMjYgaXMgMjU4OWYwMDAhDQpbICAxNTguNTgyMjMzXSAzMjAyNyBpcyAyNThhMDAw
MCENClsgIDE1OC41ODM5OTFdIDMyMDI4IGlzIDI1OGExMDAwIQ0KWyAgMTU4LjU4NTcxNV0g
MzIwMjkgaXMgMjU4YTIwMDAhDQpbICAxNTguNTg4NjM4XSAzMjA0YyBpcyAyNTg2MzAwMCEN
ClsgIDE1OC41OTAzNzddIDMyMDRiIGlzIDI1ODY0MDAwIQ0KWyAgMTU4LjU5MjExMV0gMzIw
NGEgaXMgMjU4NjUwMDAhDQpbICAxNTguNTkzODQ3XSAzMjA0OSBpcyAyNTg2NjAwMCENClsg
IDE1OC41OTU1NzNdIDMyMDQ4IGlzIDI1ODY3MDAwIQ0KWyAgMTU4LjU5NzMxNV0gMzIwNDcg
aXMgMjU4NjgwMDAhDQpbICAxNTguNTk5MDI3XSAzMjA0NiBpcyAyNTg2OTAwMCENClsgIDE1
OC42MDA3NjhdIDMyMDQ1IGlzIDI1ODZhMDAwIQ0KWyAgMTU4LjYwMjQ4Nl0gMzIwNDQgaXMg
MjU4NmIwMDAhDQpbICAxNTguNjA0MjMyXSAzMjA0MyBpcyAyNTg2YzAwMCENClsgIDE1OC42
MDU5NTZdIDMyMDQyIGlzIDI1ODZkMDAwIQ0KWyAgMTU4LjYwNzY3NF0gMzIwNDEgaXMgMjU4
NmUwMDAhDQpbICAxNTguNjA5NDEwXSAzMjA0MCBpcyAyNTg2ZjAwMCENClsgIDE1OC42MTEx
MjZdIDMyMDNmIGlzIDI1ODcwMDAwIQ0KWyAgMTU4LjYxMjg2MV0gMzIwM2UgaXMgMjU4NzEw
MDAhDQpbICAxNTguNjE0NTkzXSAzMjAzZCBpcyAyNTg3MjAwMCENClsgIDE1OC42MTYzMTdd
IDMyMDNjIGlzIDI1ODczMDAwIQ0KWyAgMTU4LjYxODA2OV0gMzIwM2IgaXMgMjU4NzQwMDAh
DQpbICAxNTguNjE5Nzc1XSAzMjAzYSBpcyAyNTg3NTAwMCENClsgIDE1OC42MjE1MTBdIDMy
MDM5IGlzIDI1ODc2MDAwIQ0KWyAgMTU4LjYyMzIyMl0gMzIwMzggaXMgMjU4NzcwMDAhDQpb
ICAxNTguNjI0OTQ1XSAzMjAyYSBpcyAyNTg3ODAwMCENClsgIDE1OC42MjY5NTJdIDMyMDYx
IGlzIDI1ODQzMDAwIQ0KWyAgMTU4LjYyODY2MF0gMzIwNjIgaXMgMjU4NDQwMDAhDQpbICAx
NTguNjMwMzg3XSAzMjA2MyBpcyAyNTg0NTAwMCENClsgIDE1OC42MzIwODhdIDMyMDY0IGlz
IDI1ODQ2MDAwIQ0KWyAgMTU4LjYzMzgxMl0gMzIwNjUgaXMgMjU4NDcwMDAhDQpbICAxNTgu
NjM1NTA2XSAzMjA2NiBpcyAyNTg0ODAwMCENClsgIDE1OC42MzcyMDldIDMyMDY3IGlzIDI1
ODQ5MDAwIQ0KWyAgMTU4LjYzODkwMF0gMzIwNjggaXMgMjU4NGEwMDAhDQpbICAxNTguNjQw
NTg1XSAzMjA2OSBpcyAyNTg0YjAwMCENClsgIDE1OC42NDIyNzldIDMyMDZhIGlzIDI1ODRj
MDAwIQ0KWyAgMTU4LjY0Mzk1N10gMzIwNmIgaXMgMjU4NGQwMDAhDQpbICAxNTguNjQ1NjMy
XSAzMjA2YyBpcyAyNTgzOTAwMCENClsgIDE1OC42NDczMTBdIDMyMDZkIGlzIDI1ODNhMDAw
IQ0KWyAgMTU4LjY0ODk3OV0gMzIwNmUgaXMgMjU4M2IwMDAhDQpbICAxNTguNjUwNjc0XSAz
MjA2ZiBpcyAyNTgzYzAwMCENClsgIDE1OC42NTIzNDBdIDMyMDcwIGlzIDI1ODNkMDAwIQ0K
WyAgMTU4LjY1NDAzOV0gMzIwNzEgaXMgMjU4M2UwMDAhDQpbICAxNTguNjU1Njk5XSAzMjA3
MiBpcyAyNTgzZjAwMCENClsgIDE1OC42NTczNjhdIDMyMDczIGlzIDI1ODQwMDAwIQ0KWyAg
MTU4LjY1OTA0NV0gMzIwNzQgaXMgMjU4NDEwMDAhDQpbICAxNTguNjYwNzE4XSAzMjA3NSBp
cyAyNTg0MjAwMCENClsgIDE1OC42NjIzOTldIDMyMDM1IGlzIDI1ODRlMDAwIQ0KWyAgMTU4
LjY2NDA3N10gMzIwMzYgaXMgMjU4NGYwMDAhDQpbICAxNTguNjY1NzI2XSAzMjAzNyBpcyAy
NTg1MDAwMCENClsgIDE1OC42Njc0MTBdIDMyMDU3IGlzIDI1ODUxMDAwIQ0KWyAgMTU4LjY2
OTA2Nl0gMzIwNWEgaXMgMjU4NTIwMDAhDQpbICAxNTguNjcwNzQ3XSAzMjA1YiBpcyAyNTg1
MzAwMCENClsgIDE1OC42NzI0MDhdIDMyMDVjIGlzIDI1ODU0MDAwIQ0KWyAgMTU4LjY3NDA4
MF0gMzIwNWQgaXMgMjU4NTUwMDAhDQpbICAxNTguNjc1NzUxXSAzMjA1ZSBpcyAyNTg1NjAw
MCENClsgIDE1OC42Nzc0MTldIDMyMDVmIGlzIDI1ODU3MDAwIQ0KWyAgMTU4LjY3OTA4Ml0g
MzIwNjAgaXMgMjU4NTgwMDAhDQpbICAxNTguNjgwNzQ0XSAzMjAyYiBpcyAyNTg1OTAwMCEN
ClsgIDE1OC42ODI0MDRdIDMyMDJjIGlzIDI1ODVhMDAwIQ0KWyAgMTU4LjY4NDA4Ml0gMzIw
MmQgaXMgMjU4NWIwMDAhDQpbICAxNTguNjg1NzM3XSAzMjAyZSBpcyAyNTg1YzAwMCENClsg
IDE1OC42ODc0MTldIDMyMDJmIGlzIDI1ODVkMDAwIQ0KWyAgMTU4LjY4OTA3NF0gMzIwMzAg
aXMgMjU4NWUwMDAhDQpbICAxNTguNjkwNzUyXSAzMjAzMSBpcyAyNTg1ZjAwMCENClsgIDE1
OC42OTI0NDVdIDMyMDMyIGlzIDI1ODYwMDAwIQ0KWyAgMTU4LjY5NDEzNV0gMzIwMzMgaXMg
MjU4NjEwMDAhDQpbICAxNTguNjk1ODI0XSAzMjAzNCBpcyAyNTg2MjAwMCENClsgIDE1OC42
OTg2MjNdIDMyMDgxIGlzIDI1ODIzMDAwIQ0KWyAgMTU4LjcwMDMzN10gMzIwODIgaXMgMjU4
MjQwMDAhDQpbICAxNTguNzAyMDIxXSAzMjA4MyBpcyAyNTgyNTAwMCENClsgIDE1OC43MDM3
MTldIDMyMDg0IGlzIDI1ODI2MDAwIQ0KWyAgMTU4LjcwNTQyMF0gMzIwODUgaXMgMjU4Mjcw
MDAhDQpbICAxNTguNzA3MTEyXSAzMjA4NiBpcyAyNTgyODAwMCENClsgIDE1OC43MDg4MTVd
IDMyMDg3IGlzIDI1ODI5MDAwIQ0KWyAgMTU4LjcxMDUxM10gMzIwODggaXMgMjU4MmEwMDAh
DQpbICAxNTguNzEyMjAzXSAzMjA4OSBpcyAyNTgyYjAwMCENClsgIDE1OC43MTM4ODhdIDMy
MDhhIGlzIDI1ODJjMDAwIQ0KWyAgMTU4LjcxNTU1NF0gMzIwOGIgaXMgMjU4MmQwMDAhDQpb
ICAxNTguNzE3MjQ5XSAzMjA3NiBpcyAyNTgyZTAwMCENClsgIDE1OC43MTg5MTldIDMyMDc3
IGlzIDI1ODJmMDAwIQ0KWyAgMTU4LjcyMDYwN10gMzIwNzggaXMgMjU4MzAwMDAhDQpbICAx
NTguNzIyMjc3XSAzMjA3OSBpcyAyNTgzMTAwMCENClsgIDE1OC43MjM5NTddIDMyMDdhIGlz
IDI1ODMyMDAwIQ0KWyAgMTU4LjcyNTYyOF0gMzIwN2IgaXMgMjU4MzMwMDAhDQpbICAxNTgu
NzI3Mjk2XSAzMjA3YyBpcyAyNTgzNDAwMCENClsgIDE1OC43Mjg5NzBdIDMyMDdkIGlzIDI1
ODM1MDAwIQ0KWyAgMTU4LjczMDYzMl0gMzIwN2UgaXMgMjU4MzYwMDAhDQpbICAxNTguNzMy
Mjg2XSAzMjA3ZiBpcyAyNTgzNzAwMCENClsgIDE1OC43MzM5NjRdIDMyMDgwIGlzIDI1ODM4
MDAwIQ0KWyAgMTU4LjczNTg5NF0gMzIwYTEgaXMgMjU4MDMwMDAhDQpbICAxNTguNzM3NTg5
XSAzMjBhMiBpcyAyNTgwNDAwMCENClsgIDE1OC43MzkyNDVdIDMyMGEzIGlzIDI1ODA1MDAw
IQ0KWyAgMTU4Ljc0MDkxM10gMzIwYTQgaXMgMjU4MDYwMDAhDQpbICAxNTguNzQyNTkwXSAz
MjBhNSBpcyAyNTgwNzAwMCENClsgIDE1OC43NDQyNTddIDMyMGE2IGlzIDI1ODA4MDAwIQ0K
WyAgMTU4Ljc0NTkyMl0gMzIwYTcgaXMgMjU4MDkwMDAhDQpbICAxNTguNzQ3NTc4XSAzMjBh
OCBpcyAyNTgwYTAwMCENClsgIDE1OC43NDkyMjhdIDMyMGE5IGlzIDI1ODBiMDAwIQ0KWyAg
MTU4Ljc1MDkwMV0gMzIwYWEgaXMgMjU4MGMwMDAhDQpbICAxNTguNzUyNTQ0XSAzMjBhYiBp
cyAyNTgwZDAwMCENClsgIDE1OC43NTQyMDRdIDMyMGFjIGlzIDI1N2Y5MDAwIQ0KWyAgMTU4
Ljc1NTg0Ml0gMzIwYWQgaXMgMjU3ZmEwMDAhDQpbICAxNTguNzU3NDkyXSAzMjBhZSBpcyAy
NTdmYjAwMCENClsgIDE1OC43NTkxNDFdIDMyMGFmIGlzIDI1N2ZjMDAwIQ0KWyAgMTU4Ljc2
MDc4NF0gMzIwYjAgaXMgMjU3ZmQwMDAhDQpbICAxNTguNzYyNDUwXSAzMjBiMSBpcyAyNTdm
ZTAwMCENClsgIDE1OC43NjQxMTFdIDMyMGIyIGlzIDI1N2ZmMDAwIQ0KWyAgMTU4Ljc2NTc2
Nl0gMzIwYjMgaXMgMjU4MDAwMDAhDQpbICAxNTguNzY3NDYwXSAzMjBiNCBpcyAyNTgwMTAw
MCENClsgIDE1OC43NjkxMjNdIDMyMGI1IGlzIDI1ODAyMDAwIQ0KWyAgMTU4Ljc3MDgwN10g
MzIwOTYgaXMgMjU4MGUwMDAhDQpbICAxNTguNzcyNDc5XSAzMjA5NyBpcyAyNTgwZjAwMCEN
ClsgIDE1OC43NzQxNTFdIDMyMDk4IGlzIDI1ODEwMDAwIQ0KWyAgMTU4Ljc3NTg0MF0gMzIw
OTkgaXMgMjU4MTEwMDAhDQpbICAxNTguNzc3NTI5XSAzMjA5YSBpcyAyNTgxMjAwMCENClsg
IDE1OC43NzkyMjRdIDMyMDliIGlzIDI1ODEzMDAwIQ0KWyAgMTU4Ljc4MDkwOF0gMzIwOWMg
aXMgMjU4MTQwMDAhDQpbICAxNTguNzgyNTg2XSAzMjA5ZCBpcyAyNTgxNTAwMCENClsgIDE1
OC43ODQyODddIDMyMDllIGlzIDI1ODE2MDAwIQ0KWyAgMTU4Ljc4NTk1M10gMzIwOWYgaXMg
MjU4MTcwMDAhDQpbICAxNTguNzg3NjQzXSAzMjBhMCBpcyAyNTgxODAwMCENClsgIDE1OC43
ODkyOThdIDMyMDhjIGlzIDI1ODE5MDAwIQ0KWyAgMTU4Ljc5MDk3MV0gMzIwOGQgaXMgMjU4
MWEwMDAhDQpbICAxNTguNzkyNjU0XSAzMjA4ZSBpcyAyNTgxYjAwMCENClsgIDE1OC43OTQz
MjZdIDMyMDhmIGlzIDI1ODFjMDAwIQ0KWyAgMTU4Ljc5NjAwNF0gMzIwOTAgaXMgMjU4MWQw
MDAhDQpbICAxNTguNzk3Njg0XSAzMjA5MSBpcyAyNTgxZTAwMCENClsgIDE1OC43OTkzNDVd
IDMyMDkyIGlzIDI1ODFmMDAwIQ0KWyAgMTU4LjgwMTAzNF0gMzIwOTMgaXMgMjU4MjAwMDAh
DQpbICAxNTguODAyNzE4XSAzMjA5NCBpcyAyNTgyMTAwMCENClsgIDE1OC44MDQ0MjRdIDMy
MDk1IGlzIDI1ODIyMDAwIQ0KWyAgMTU4LjgyNTA3Nl0gMzIwYjYgaXMgMjU3ZWUwMDAhDQpb
ICAxNTguODI2ODA5XSAzMjBiNyBpcyAyNTdlZjAwMCENClsgIDE1OC44Mjg1MjldIDMyMGI4
IGlzIDI1N2YwMDAwIQ0KWyAgMTU4LjgzMDI3Nl0gMzIwYjkgaXMgMjU3ZjEwMDAhDQpbICAx
NTguODMxOTg2XSAzMjBiYSBpcyAyNTdmMjAwMCENClsgIDE1OC44MzM3MTRdIDMyMGJiIGlz
IDI1N2YzMDAwIQ0KWyAgMTU4LjgzNTQ2MF0gMzIwYmMgaXMgMjU3ZjQwMDAhDQpbICAxNTgu
ODM3MTk0XSAzMjBiZCBpcyAyNTdmNTAwMCENClsgIDE1OC44Mzg4NzddIDMyMGJlIGlzIDI1
N2Y2MDAwIQ0KWyAgMTU4Ljg0MDU4NF0gMzIwYmYgaXMgMjU3ZjcwMDAhDQpbICAxNTguODQy
MjkzXSAzMjBjMCBpcyAyNTdmODAwMCENClsgIDE1OC44NDQyODRdIDMyMGMyIGlzIDI1N2U0
MDAwIQ0KWyAgMTU4Ljg0NTk5Ml0gMzIwYzMgaXMgMjU3ZTUwMDAhDQpbICAxNTguODQ3Njk1
XSAzMjBjNCBpcyAyNTdlNjAwMCENClsgIDE1OC44NDkzOTVdIDMyMGM1IGlzIDI1N2U3MDAw
IQ0KWyAgMTU4Ljg1MTA3N10gMzIwYzYgaXMgMjU3ZTgwMDAhDQpbICAxNTguODUyNzUzXSAz
MjBjNyBpcyAyNTdlOTAwMCENClsgIDE1OC44NTQ0NTVdIDMyMGM4IGlzIFsgIDE2MC45ODMy
OTRdIDMxY2JlIGlzIDI1ZmM4MDAwIQ0KWyAgMTYwLjk4NTA0OF0gMzFjYmYgaXMgMjVmYzkw
MDAhDQpbICAxNjAuOTg2NzcwXSAzMWM3ZiBpcyAyNWZkNTAwMCENClsgIDE2MC45ODg0Nzdd
IDMxYzgwIGlzIDI1ZmQ2MDAwIQ0KWyAgMTYwLjk5MDE4M10gMzFjODEgaXMgMjVmZDcwMDAh
DQpbICAxNjAuOTkxODk0XSAzMWM4MiBpcyAyNWZkODAwMCENClsgIDE2MC45OTM2MDNdIDMx
Y2E0IGlzIDI1ZmQ5MDAwIQ0KWyAgMTYwLjk5NTMwNV0gMzFjYTUgaXMgMjVmZGEwMDAhDQpb
ICAxNjAuOTk3MDI1XSAzMWNhNiBpcyAyNWZkYjAwMCENClsgIDE2MC45OTg3MDldIDMxY2E3
IGlzIDI1ZmRjMDAwIQ0KWyAgMTYxLjAwMDQwNV0gMzFjYTggaXMgMjVmZGQwMDAhDQpbICAx
NjEuMDAyMDg5XSAzMWNhOSBpcyAyNWZkZTAwMCENClsgIDE2MS4wMDM3OTRdIDMxY2FhIGlz
IDI1ZmRmMDAwIQ0KWyAgMTYxLjAwNTQ3N10gMzFjODkgaXMgMjYwMGEwMDAhDQpbICAxNjEu
MDA3MTc1XSAzMWM4OCBpcyAyNWZlNzAwMCENClsgIDE2MS4wMDg4ODhdIDMxYzg3IGlzIDI1
M2I0MDAwIQ0KWyAgMTYxLjAxMDYxMF0gMzFjODYgaXMgMjYwMDQwMDAhDQpbICAxNjEuMDEy
MzQwXSAzMWM4MyBpcyAyNTI2OTAwMCENClsgIDE2MS4wMTQxMDVdIDMyM2M2IGlzIDI2MTgx
MDAwIQ0KWyAgMTYxLjAxNTg2NF0gMzIzYzUgaXMgMjYwMGIwMDAhDQpbICAxNjEuMDE3Njcx
XSAzMjNjNCBpcyAyNjAwZDAwMCENClsgIDE2MS4wMTk0NDhdIDMyM2MzIGlzIDI2MDBjMDAw
IQ0KWyAgMTYxLjAyMTI1NF0gMzIzYzIgaXMgMjU1OGQwMDAhDQpbICAxNjEuMDIzMDUzXSAz
MjNjMSBpcyAyNjAyMDAwMCENClsgIDE2MS4wMjkyNDhdIDMxY2MxIGlzIDI1ZmI1MDAwIQ0K
WyAgMTYxLjAzMTI2MV0gMzFjYzIgaXMgMjVmYjYwMDAhDQpbICAxNjEuMDMzMTQ0XSAzMWNj
MyBpcyAyNWZiNzAwMCENClsgIDE2MS4wMzUwNDFdIDMxY2M0IGlzIDI1ZmI4MDAwIQ0KWyAg
MTYxLjAzNjg3NV0gMzFjYzUgaXMgMjVmYjkwMDAhDQpbICAxNjEuMDM4NzA3XSAzMWNjNiBp
cyAyNWZiYTAwMCENClsgIDE2MS4wNDA1NDNdIDMxY2M3IGlzIDI1ZmJiMDAwIQ0KWyAgMTYx
LjA0MjM3Nl0gMzFjYzggaXMgMjVmYmMwMDAhDQpbICAxNjEuMDQ0MjA3XSAzMWNjOSBpcyAy
NWZiZDAwMCENClsgIDE2MS4wNDYwMzhdIDMxY2NhIGlzIDI1ZmJlMDAwIQ0KWyAgMTYxLjA0
Nzg2M10gMzFjY2IgaXMgMjVmYmYwMDAhDQpbICAxNjEuMDUwMjM5XSAzMWNlMSBpcyAyNWY5
NTAwMCENClsgIDE2MS4wNTIwODVdIDMxY2UyIGlzIDI1Zjk2MDAwIQ0KWyAgMTYxLjA1Mzkz
NV0gMzFjZTMgaXMgMjVmOTcwMDAhDQpbICAxNjEuMDU1Nzg1XSAzMWNlNCBpcyAyNWY5ODAw
MCENClsgIDE2MS4wNTc2MjddIDMxY2U1IGlzIDI1Zjk5MDAwIQ0KWyAgMTYxLjA1OTQ5MF0g
MzFjZTYgaXMgMjVmOWEwMDAhDQpbICAxNjEuMDYxMzI4XSAzMWNlNyBpcyAyNWY5YjAwMCEN
ClsgIDE2MS4wNjMxNzldIDMxY2U4IGlzIDI1ZjljMDAwIQ0KWyAgMTYxLjA2NTAxM10gMzFj
ZTkgaXMgMjVmOWQwMDAhDQpbICAxNjEuMDY2ODgwXSAzMWNlYSBpcyAyNWY5ZTAwMCENClsg
IDE2MS4wNjg2ODNdIDMxY2ViIGlzIDI1ZjlmMDAwIQ0KWyAgMTYxLjA3MDQ4M10gMzFjZWMg
aXMgMjVmOGEwMDAhDQpbICAxNjEuMDcyMjY4XSAzMWNlZCBpcyAyNWY4YjAwMCENClsgIDE2
MS4wNzQwMjRdIDMxY2VlIGlzIDI1ZjhjMDAwIQ0KWyAgMTYxLjA3NTc3OV0gMzFjZWYgaXMg
MjVmOGQwMDAhDQpbICAxNjEuMDc3NDg5XSAzMWNmMCBpcyAyNWY4ZTAwMCENClsgIDE2MS4w
NzkxOThdIDMxY2YxIGlzIDI1ZjhmMDAwIQ0KWyAgMTYxLjA4MDg5OF0gMzFjZjIgaXMgMjVm
OTAwMDAhDQpbICAxNjEuMDgyNTg0XSAzMWNmMyBpcyAyNWY5MTAwMCENClsgIDE2MS4wODQy
ODRdIDMxY2Y0IGlzIDI1ZjkyMDAwIQ0KWyAgMTYxLjA4NTkyMl0gMzFjZjUgaXMgMjVmOTMw
MDAhDQpbICAxNjEuMDg3NTc2XSAzMWNmNiBpcyAyNWY5NDAwMCENClsgIDE2MS4wODkxOTJd
IDMxY2Y3IGlzIDI1ZjgwMDAwIQ0KWyAgMTYxLjA5MDgyN10gMzFjZjggaXMgMjVmODEwMDAh
DQpbICAxNjEuMDkyNDg1XSAzMWNmOSBpcyAyNWY4MjAwMCENClsgIDE2MS4wOTQxMzNdIDMx
Y2ZhIGlzIDI1ZjgzMDAwIQ0KWyAgMTYxLjA5NTc5N10gMzFjZmIgaXMgMjVmODQwMDAhDQpb
ICAxNjEuMDk3NDM4XSAzMWNmYyBpcyAyNWY4NTAwMCENClsgIDE2MS4wOTkwNjRdIDMxY2Zk
IGlzIDI1Zjg2MDAwIQ0KWyAgMTYxLjEwMDczMF0gMzFjZmUgaXMgMjVmODcwMDAhDQpbICAx
NjEuMTAyMzY4XSAzMWNmZiBpcyAyNWY4ODAwMCENClsgIDE2MS4xMDQwMjBdIDMxZDAwIGlz
IDI1Zjg5MDAwIQ0KWyAgMTYxLjEwNTY3N10gMzFjY2MgaXMgMjVmYWEwMDAhDQpbICAxNjEu
MTA3MzQxXSAzMWNjZCBpcyAyNWZhYjAwMCENClsgIDE2MS4xMDkwMjJdIDMxY2NlIGlzIDI1
ZmFjMDAwIQ0KWyAgMTYxLjExMDY5OF0gMzFjY2YgaXMgMjVmYWQwMDAhDQpbICAxNjEuMTEy
MzY1XSAzMWNkMCBpcyAyNWZhZTAwMCENClsgIDE2MS4xMTQwNzddIDMxY2QxIGlzIDI1ZmFm
MDAwIQ0KWyAgMTYxLjExNTc0NF0gMzFjZDIgaXMgMjVmYjAwMDAhDQpbICAxNjEuMTE3NDU2
XSAzMWNkMyBpcyAyNWZiMTAwMCENClsgIDE2MS4xMTkxMjhdIDMxY2Q0IGlzIDI1ZmIyMDAw
IQ0KWyAgMTYxLjEyMDgzOV0gMzFjZDUgaXMgMjVmYjMwMDAhDQpbICAxNjEuMTIyNTI0XSAz
MWNkNiBpcyAyNWZiNDAwMCENClsgIDE2MS4xMjQyMjNdIDMxY2Q3IGlzIDI1ZmEwMDAwIQ0K
WyAgMTYxLjEyNTkzMl0gMzFjZDggaXMgMjVmYTEwMDAhDQpbICAxNjEuMTI3NjMwXSAzMWNk
OSBpcyAyNWZhMjAwMCENClsgIDE2MS4xMjkzMzRdIDMxY2RhIGlzIDI1ZmEzMDAwIQ0KWyAg
MTYxLjEzMTAyMF0gMzFjZGIgaXMgMjVmYTQwMDAhDQpbICAxNjEuMTMyNzAwXSAzMWNkYyBp
cyAyNWZhNTAwMCENClsgIDE2MS4xMzQ0MTJdIDMxY2RkIGlzIDI1ZmE2MDAwIQ0KWyAgMTYx
LjEzNjA4NF0gMzFjZGUgaXMgMjVmYTcwMDAhDQpbICAxNjEuMTM3ODA3XSAzMWNkZiBpcyAy
NWZhODAwMCENClsgIDE2MS4xMzk0OTFdIDMxY2UwIGlzIDI1ZmE5MDAwIQ0KWyAgMTYxLjE0
MjgxM10gMzFjOTMgaXMgMjVmNmEwMDAhDQpbICAxNjEuMTQ0ODAwXSAzMWM5NCBpcyAyNWY2
YjAwMCENClsgIDE2MS4xNDY1MjBdIDMxYzk1IGlzIDI1ZjZjMDAwIQ0KWyAgMTYxLjE0ODIz
MF0gMzFjOTYgaXMgMjVmNmQwMDAhDQpbICAxNjEuMTQ5OTM3XSAzMWM5NyBpcyAyNWY2ZTAw
MCENClsgIDE2MS4xNTE2NDVdIDMxYzk4IGlzIDI1ZjZmMDAwIQ0KWyAgMTYxLjE1MzM0NV0g
MzFjOTkgaXMgMjVmNzAwMDAhDQpbICAxNjEuMTU1MDY1XSAzMWM5YSBpcyAyNWY3MTAwMCEN
ClsgIDE2MS4xNTY3NjFdIDMxYzliIGlzIDI1ZjcyMDAwIQ0KWyAgMTYxLjE1ODQ0NV0gMzFj
OWMgaXMgMjVmNzMwMDAhDQpbICAxNjEuMTYwMTA2XSAzMWM5ZCBpcyAyNWY3NDAwMCENClsg
IDE2MS4xNjE3NDRdIDMxYzllIGlzIDI1ZjYwMDAwIQ0KWyAgMTYxLjE2MzQyNF0gMzFjOWYg
aXMgMjVmNjEwMDAhDQpbICAxNjEuMTY1MDYyXSAzMWNhMCBpcyAyNWY2MjAwMCENClsgIDE2
MS4xNjY3NDJdIDMxY2ExIGlzIDI1ZjYzMDAwIQ0KWyAgMTYxLjE2ODM2OF0gMzFjYTIgaXMg
MjVmNjQwMDAhDQpbICAxNjEuMTcwMDAxXSAzMWNhMyBpcyAyNWY2NTAwMCENClsgIDE2MS4x
NzE2NDddIDMxZDIyIGlzIDI1ZjY2MDAwIQ0KWyAgMTYxLjE3MzI3M10gMzFkMjMgaXMgMjVm
NjcwMDAhDQpbICAxNjEuMTc0OTI4XSAzMWQyNCBpcyAyNWY2ODAwMCENClsgIDE2MS4xNzY1
NDhdIDMxZDI1IGlzIDI1ZjY5MDAwIQ0KWyAgMTYxLjE3OTU0N10gMzFkMzAgaXMgMjVmMmEw
MDAhDQpbICAxNjEuMTgxMzg2XSAzMWQyZiBpcyAyNWYyYjAwMCENClsgIDE2MS4xODMwMTNd
IDMxZDJlIGlzIDI1ZjJjMDAwIQ0KWyAgMTYxLjE4NDY3OV0gMzFkMmQgaXMgMjVmMmQwMDAh
DQpbICAxNjEuMTg2MzE3XSAzMWQyYyBpcyAyNWYyZTAwMCENClsgIDE2MS4xODc5ODNdIDMx
ZDJiIGlzIDI1ZjJmMDAwIQ0KWyAgMTYxLjE4OTYyMl0gMzFkMmEgaXMgMjVmMzAwMDAhDQpb
ICAxNjEuMTkxMjgxXSAzMWQyOSBpcyAyNWYzMTAwMCENClsgIDE2MS4xOTI5NDZdIDMxZDI4
IGlzIDI1ZjMyMDAwIQ0KWyAgMTYxLjE5NDYxMF0gMzFkMjcgaXMgMjVmMzMwMDAhDQpbICAx
NjEuMTk2MjY5XSAzMWQyNiBpcyAyNWYzNDAwMCENClsgIDE2MS4xOTgxOTZdIDMxYzkyIGlz
IDI1ZjE1MDAwIQ0KWyAgMTYxLjE5OTg3Ml0gMzFjOTEgaXMgMjVmMTYwMDAhDQpbICAxNjEu
MjAxNTQ0XSAzMWM5MCBpcyAyNWYxNzAwMCENClsgIDE2MS4yMDMyMTddIDMxYzhmIGlzIDI1
ZjE4MDAwIQ0KWyAgMTYxLjIwNDkzM10gMzFjOGUgaXMgMjVmMTkwMDAhDQpbICAxNjEuMjA2
NjExXSAzMWM4ZCBpcyAyNWYxYTAwMCENClsgIDE2MS4yMDgzMjRdIDMxYzhjIGlzIDI1ZjFi
MDAwIQ0KWyAgMTYxLjIxMDAxNl0gMzFjOGIgaXMgMjVmMWMwMDAhDQpbICAxNjEuMjExNzMy
XSAzMWM4YSBpcyAyNWYxZDAwMCENClsgIDE2MS4yMTM0NjVdIDMxZDAxIGlzIDI1ZjFlMDAw
IQ0KWyAgMTYxLjIxNTE3Ml0gMzFkMDQgaXMgMjVmMWYwMDAhDQpbICAxNjEuMjE2OTAzXSAz
MWQzYiBpcyAyNWYwYTAwMCENClsgIDE2MS4yMTg2MjJdIDMxZDNjIGlzIDI1ZjBiMDAwIQ0K
WyAgMTYxLjIyMDM1MF0gMzFkM2QgaXMgMjVmMGMwMDAhDQpbICAxNjEuMjIyMDkxXSAzMWQz
ZSBpcyAyNWYwZDAwMCENClsgIDE2MS4yMjM4MzBdIDMxZDNmIGlzIDI1ZjBlMDAwIQ0KWyAg
MTYxLjIyNTU2NF0gMzFkNDAgaXMgMjVmMGYwMDAhDQpbICAxNjEuMjI3MjkyXSAzMWQ0MSBp
cyAyNWYxMDAwMCENClsgIDE2MS4yMjkwMjZdIDMxZDQyIGlzIDI1ZjExMDAwIQ0KWyAgMTYx
LjIzMDc2MF0gMzFkNDMgaXMgMjVmMTIwMDAhDQpbICAxNjEuMjMyNDkwXSAzMWQ0NCBpcyAy
NWYxMzAwMCENClsgIDE2MS4yMzQyNDNdIDMxZDQ1IGlzIDI1ZjE0MDAwIQ0KWyAgMTYxLjIz
NTk1NV0gMzFkM2EgaXMgMjVmMjAwMDAhDQpbICAxNjEuMjM3NzA5XSAzMWQzOSBpcyAyNWYy
MTAwMCENClsgIDE2MS4yMzk0MzVdIDMxZDM4IGlzIDI1ZjIyMDAwIQ0KWyAgMTYxLjI0MTE3
NF0gMzFkMzcgaXMgMjVmMjMwMDAhDQpbICAxNjEuMjQyOTIwXSAzMWQzNiBpcyAyNWYyNDAw
MCENClsgIDE2MS4yNDQ2NThdIDMxZDM1IGlzIDI1ZjI1MDAwIQ0KWyAgMTYxLjI0NjM5Ml0g
MzFkMzQgaXMgMjVmMjYwMDAhDQpbICAxNjEuMjQ4MTI1XSAzMWQzMyBpcyAyNWYyNzAwMCEN
ClsgIDE2MS4yNDk4NTldIDMxZDMyIGlzIDI1ZjI4MDAwIQ0KWyAgMTYxLjI1MTU5M10gMzFk
MzEgaXMgMjVmMjkwMDAhDQpbICAxNjEuMjUzMzAwXSAzMWQ0NiBpcyAyNWYwMDAwMCENClsg
IDE2MS4yNTUwNDldIDMxZDQ3IGlzIDI1ZjAxMDAwIQ0KWyAgMTYxLjI1Njc3Ml0gMzFkNDgg
aXMgMjVmMDIwMDAhDQpbICAxNjEuMjU4NDg5XSAzMWQ0OSBpcyAyNWYwMzAwMCENClsgIDE2
MS4yNjAyMDVdIDMxZDRhIGlzIDI1ZjA0MDAwIQ0KWyAgMTYxLjI2MTkxMl0gMzFkNGIgaXMg
MjVmMDUwMDAhDQpbICAxNjEuMjYzNjQ5XSAzMWQ0YyBpcyAyNWYwNjAwMCENClsgIDE2MS4y
NjUzNTFdIDMxZDRkIGlzIDI1ZjA3MDAwIQ0KWyAgMTYxLjI2NzA4Ml0gMzFkNGUgaXMgMjVm
MDgwMDAhDQpbICAxNjEuMjY4NzczXSAzMWQ0ZiBpcyAyNWYwOTAwMCENClsgIDE2MS4yNzE2
OTddIDMxZDUxIGlzIDI1ZWY1MDAwIQ0KWyAgMTYxLjI3MzQyMl0gMzFkNTIgaXMgMjVlZjYw
MDAhDQpbICAxNjEuMjc1MTQwXSAzMWQ1MyBpcyAyNWVmNzAwMCENClsgIDE2MS4yNzY5ODNd
IDMxZDU0IGlzIDI1ZWY4MDAwIQ0KWyAgMTYxLjI3ODY3OV0gMzFkNTUgaXMgMjVlZjkwMDAh
DQpbICAxNjEuMjgwNDM4XSAzMWQ1NiBpcyAyNWVmYTAwMCENClsgIDE2MS4yODIxMzVdIDMx
ZDU3IGlzIDI1ZWZiMDAwIQ0KWyAgMTYxLjI4Mzg1MF0gMzFkNTggaXMgMjVlZmMwMDAhDQpb
ICAxNjEuMjg1NTM0XSAzMWQ1OSBpcyAyNWVmZDAwMCENClsgIDE2MS4yODcyNThdIDMxZDVh
IGlzIDI1ZWZlMDAwIQ0KWyAgMTYxLjI4ODk0NF0gMzFkNWIgaXMgMjVlZmYwMDAhDQpbICAx
NjEuMjkwNjQ0XSAzMWQ1YyBpcyAyNWVlYTAwMCENClsgIDE2MS4yOTIzMzNdIDMxZDVkIGlz
IDI1ZWViMDAwIQ0KWyAgMTYxLjI5NDAyMF0gMzFkNWUgaXMgMjVlZWMwMDAhDQpbICAxNjEu
Mjk1NzA3XSAzMWQ1ZiBpcyAyNWVlZDAwMCENClsgIDE2MS4yOTczODddIDMxZDYwIGlzIDI1
ZWVlMDAwIQ0KWyAgMTYxLjI5OTA3NF0gMzFkNjEgaXMgMjVlZWYwMDAhDQpbICAxNjEuMzAw
Nzk3XSAzMWQ2MiBpcyAyNWVmMDAwMCENClsgIDE2MS4zMDI0ODFdIDMxZDYzIGlzIDI1ZWYx
MDAwIQ0KWyAgMTYxLjMwNDE5N10gMzFkNjQgaXMgMjVlZjIwMDAhDQpbICAxNjEuMzA1ODgx
XSAzMWQ2NSBpcyAyNWVmMzAwMCENClsgIDE2MS4zMDc1NzRdIDMxZDY2IGlzIDI1ZWY0MDAw
IQ0KWyAgMTYxLjMxMDQxMF0gMzFkNjggaXMgMjVlZTEwMDAhDQpbICAxNjEuMzEyMTQxXSAz
MWQ2OSBpcyAyNWVlMjAwMCENClsgIDE2MS4zMTM4NDldIDMxZDZhIGlzIDI1ZWUzMDAwIQ0K
WyAgMTYxLjMxNTUzM10gMzFkNmIgaXMgMjVlZTQwMDAhDQpbICAxNjEuMzE3MjY5XSAzMWQ2
YyBpcyAyNWVlNTAwMCENClsgIDE2MS4zMTg5NTZdIDMxZDZkIGlzIDI1ZWU2MDAwIQ0KWyAg
MTYxLjMyMDY3OV0gMzFkNmUgaXMgMjVlZTcwMDAhDQpbICAxNjEuMzIyMzY0XSAzMWQ2ZiBp
cyAyNWVlODAwMCENClsgIDE2MS4zMjQwNjFdIDMxZDcwIGlzIDI1ZWU5MDAwIQ0KWyAgMTYx
LjM0MTk4OV0gMzFkN2MgaXMgMjVlYjUwMDAhDQpbICAxNjEuMzQzNzUwXSAzMWQ5MCBpcyAy
NWViNjAwMCENClsgIDE2MS4zNDU0NDRdIDMxZDhmIGlzIDI1ZWI3MDAwIQ0KWyAgMTYxLjM0
NzE2MV0gMzFkOGUgaXMgMjVlYjgwMDAhDQpbICAxNjEuMzQ4ODkwXSAzMWQ4ZCBpcyAyNWVi
OTAwMCENClsgIDE2MS4zNTA2MzFdIDMxZDhjIGlzIDI1ZWJhMDAwIQ0KWyAgMTYxLjM1MjMw
OV0gMzFkOGIgaXMgMjVlYmIwMDAhDQpbICAxNjEuMzU0MDI1XSAzMWQ4YSBpcyAyNWViYzAw
MCENClsgIDE2MS4zNTU3MDddIDMxZDg5IGlzIDI1ZWJkMDAwIQ0KWyAgMTYxLjM1NzU4N10g
MzFkODggaXMgMjVlYmUwMDAhDQpbICAxNjEuMzU5MjgxXSAzMWQ4NyBpcyAyNWViZjAwMCEN
ClsgIDE2MS4zNjEwOTVdIDMxZDcxIGlzIDI1ZWFhMDAwIQ0KWyAgMTYxLjM2Mjg1N10gMzFk
ODYgaXMgMjVlYWIwMDAhDQpbICAxNjEuMzY0NTgzXSAzMWQ4NSBpcyAyNWVhYzAwMCENClsg
IDE2MS4zNjYyOTFdIDMxZDg0IGlzIDI1ZWFkMDAwIQ0KWyAgMTYxLjM2ODAwM10gMzFkODMg
aXMgMjVlYWUwMDAhDQpbICAxNjEuMzY5NzAyXSAzMWQ4MiBpcyAyNWVhZjAwMCENClsgIDE2
MS4zNzE0NDhdIDMxZDgxIGlzIDI1ZWIwMDAwIQ0KWyAgMTYxLjM3MzEyOV0gMzFkODAgaXMg
MjVlYjEwMDAhDQpbICAxNjEuMzc0ODM4XSAzMWQ3ZiBpcyAyNWViMjAwMCENClsgIDE2MS4z
NzY1MjJdIDMxZDdlIGlzIDI1ZWIzMDAwIQ0KWyAgMTYxLjM3ODIyNF0gMzFkN2QgaXMgMjVl
YjQwMDAhDQpbICAxNjEuMzgwMTM5XSAzMWQ2NyBpcyAyNWU5ZjAwMCENClsgIDE2MS4zODE4
NTBdIDMxZDdiIGlzIDI1ZWEwMDAwIQ0KWyAgMTYxLjM4MzU5OV0gMzFkN2EgaXMgMjVlYTEw
MDAhDQpbICAxNjEuMzg1MzE0XSAzMWQ3OSBpcyAyNWVhMjAwMCENClsgIDE2MS4zODcwNjNd
IDMxZDc4IGlzIDI1ZWEzMDAwIQ0KWyAgMTYxLjM4ODc4N10gMzFkNzcgaXMgMjVlYTQwMDAh
DQpbICAxNjEuMzkwNTA5XSAzMWQ3NiBpcyAyNWVhNTAwMCENClsgIDE2MS4zOTIyNDldIDMx
ZDc1IGlzIDI1ZWE2MDAwIQ0KWyAgMTYxLjM5Mzk2OF0gMzFkNzQgaXMgMjVlYTcwMDAhDQpb
ICAxNjEuMzk1NzAzXSAzMWQ3MyBpcyAyNWVhODAwMCENClsgIDE2MS4zOTc0MDhdIDMxZDcy
IGlzIDI1ZWE5MDAwIQ0KWyAgMTYxLjQxMTA0MV0gMzFkNTAgaXMgMjVlOWUwMDAhDQpbICAx
NjEuNDIwNDUwXSAzMWQ5MSBpcyAyNWU5ZDAwMCENClsgIDE2MS40Mjc1MTBdIDMxZDA1IGlz
IDI1ZTljMDAwIQ0KWyAgMTYxLjQzMDAzN10gMzFkMDYgaXMgMjVlOWIwMDAhDQpbICAxNjEu
NDMyMzU0XSAzMWQwNyBpcyAyNWU5YTAwMCENClsgIDE2MS40MzQ1MjVdIDMxZDA4IGlzIDI1
ZTk5MDAwIQ0KWyAgMTYxLjQzNjY3MF0gMzFkMDkgaXMgMjVlOTgwMDAhDQpbICAxNjEuNDM5
MDU0XSAzMWQwYSBpcyAyNWU5NzAwMCENClsgIDE2MS40NDEyMDddIDMxZDBiIGlzIDI1ZTk2
MDAwIQ0KWyAgMTYxLjQ0MzM2MV0gMzFkMGMgaXMgMjVlOTUwMDAhDQpbICAxNjEuNDQ1NzM3
XSAzMWQwZCBpcyAyNWU5NDAwMCENClsgIDE2MS40NDc4NzRdIDMxZDBlIGlzIDI1ZTkzMDAw
IQ0KWyAgMTYxLjQ1MDAyM10gMzFkMGYgaXMgMjVlOTIwMDAhDQpbICAxNjEuNDU2OTI0XSAz
MWQxMCBpcyAyNWU5MTAwMCENClsgIDE2MS40NTkwNzNdIDMxZDExIGlzIDI1ZTkwMDAwIQ0K
WyAgMTYxLjQ3MjE2NV0gMzFkMTIgaXMgMjVlOGYwMDAhDQpbICAxNjEuNDc0NDYzXSAzMWQ5
MiBpcyAyNWU4ZTAwMCENClsgIDE2MS40NzY1OTldIDMxZDEzIGlzIDI1ZThkMDAwIQ0KWyAg
MTYxLjQ3ODk4N10gMzFkMTQgaXMgMjVlOGMwMDAhDQpbICAxNjEuNDk0MTIzXSAzMWQxNSBp
cyAyNWU4YjAwMCENClsgIDE2MS41MDM3NjBdIDMxZDE2IGlzIDI1ZThhMDAwIQ0KWyAgMTYx
LjUwOTkwM10gMzFkMTcgaXMgMjVlODkwMDAhDQpbICAxNjEuNTIxNDAwXSAzMWQxOCBpcyAy
NWU4ODAwMCENClsgIDE2MS41MzAyODhdIDMxZDE5IGlzIDI1ZTg3MDAwIQ0KWyAgMTYxLjU0
MTAzMF0gMzFkMWEgaXMgMjVlODYwMDAhDQpbICAxNjEuNTQ1NDAzXSAzMWQxYyBpcyAyNWU4
NTAwMCENClsgIDE2MS41NTQ4MzVdIDMxZDFkIGlzIDI1ZTg0MDAwIQ0KWyAgMTYxLjU3NTg4
Ml0gMzFkMWUgaXMgMjVlODMwMDAhDQpbICAxNjEuNTg4MDM0XSAzMWQxZiBpcyAyNWU4MjAw
MCENClsgIDE2MS42MDM4NzFdIDMxZDIwIGlzIDI1ZTgxMDAwIQ0KWyAgMTYxLjYzNDk1Nl0g
MzFkMjEgaXMgMjVlODAwMDAhDQpbICAxNjEuNjczODgxXSAzMWQ5MyBpcyAyNWU3ZjAwMCEN
ClsgIDE2MS42ODQxNTJdIDMxZDk0IGlzIDI1ZTdlMDAwIQ0KWyAgMTYxLjY4NjMyOV0gMzFk
OWUgaXMgMjVlN2QwMDAhDQpbICAxNjEuNzA4MzYyXSAzMWQ5ZiBpcyAyNWU3YzAwMCENClsg
IDE2MS43MTUzNjNdIDMxZDk1IGlzIDI1ZTdiMDAwIQ0KWyAgMTYxLjcxNzY2Ml0gMzFkYTAg
aXMgMjVlN2EwMDAhDQpbICAxNjEuNzI2NDE3XSAzMWRhMSBpcyAyNWU3OTAwMCENClsgIDE2
MS43Mjg3MjhdIDMxZGEyIGlzIDI1ZTc4MDAwIQ0KWyAgMTYxLjc2NTI4MV0gMzFkYTMgaXMg
MjVlNzcwMDAhDQpbICAxNjEuNzY3NTg0XSAzMWQ5NiBpcyAyNWU3NjAwMCENClsgIDE2MS43
NzExNzZdIDMxZGE0IGlzIDI1ZTc1MDAwIQ0KWyAgMTYxLjc4NjYxOF0gMzFkYTUgaXMgMjVl
NzQwMDAhDQpbICAxNjEuODA1NjE2XSAzMWQ5NyBpcyAyNWU3MzAwMCENClsgIDE2MS44MjI2
ODhdIDMxZGE2IGlzIDI1ZTcyMDAwIQ0KWyAgMTYxLjgyNTAxOV0gMzFkOTggaXMgMjVlNzEw
MDAhDQpbICAxNjEuODI3MzE4XSAzMWRhNyBpcyAyNWU3MDAwMCENClsgIDE2MS44Mjk1MjFd
IDMxZGE4IGlzIDI1ZTZmMDAwIQ0KWyAgMTYxLjgzMTg4Nl0gMzFkYTkgaXMgMjVlNmUwMDAh
DQpbICAxNjEuODM0MjA5XSAzMWRhYSBpcyAyNWU2ZDAwMCENClsgIDE2MS44NDI1MTddIDMx
ZGFiIGlzIDI1ZTZjMDAwIQ0KWyAgMTYxLjg0NDkwOF0gMzFkYWMgaXMgMjVlNmIwMDAhDQpb
ICAxNjEuODUzMDMxXSAzMWRhZCBpcyAyNWU2YTAwMCENClsgIDE2MS44NTUzMjhdIDMxZGFl
IGlzIDI1ZTY5MDAwIQ0KWyAgMTYxLjg1NzY0OV0gMzFkYWYgaXMgMjVlNjgwMDAhDQpbICAx
NjEuODY3ODAxXSAzMWRiMCBpcyAyNWU2NzAwMCENClsgIDE2MS44ODI5ODVdIDMxZGIxIGlz
IDI1ZTM2MDAwIQ0KWyAgMTYxLjg5ODExOF0gMzFkOTkgaXMgMjVlMzcwMDAhDQpbICAxNjEu
OTE3NzMzXSAzMWQ5YSBpcyAyNWUzODAwMCENClsgIDE2MS45MTk5NjNdIDMxZGIyIGlzIDI1
ZTM5MDAwIQ0KWyAgMTYxLjkyNjgwNl0gMzFkYjMgaXMgMjVlM2EwMDAhDQpbICAxNjEuOTM5
NjIwXSAzMWRiNCBpcyAyNWUzYjAwMCENClsgIDE2MS45NDE5NjNdIDMxZGI1IGlzIDI1ZTNj
MDAwIQ0KWyAgMTYxLjk0NDI2Ml0gMzFkYjYgaXMgMjVlM2QwMDAhDQpbICAxNjEuOTQ5NDM4
XSAzMWRiNyBpcyAyNWUzZTAwMCENClsgIDE2MS45NTE3MjFdIDMxZGI4IGlzIDI1ZTNmMDAw
IQ0KWyAgMTYxLjk2MzY4OV0gMzFkYjkgaXMgMjVlNDAwMDAhDQpbICAxNjEuOTcyODY2XSAz
MWRiYSBpcyAyNWU0MTAwMCENClsgIDE2MS45NzUyMTVdIDMxZGJiIGlzIDI1ZTQyMDAwIQ0K
WyAgMTYxLjk3NzUyMV0gMzFkYmMgaXMgMjVlNDMwMDAhDQpbICAxNjEuOTkyNzI4XSAzMWRi
ZCBpcyAyNWU0NDAwMCENClsgIDE2MS45OTUwNTBdIDMxZDliIGlzIDI1ZTQ1MDAwIQ0KWyAg
MTYxLjk5NzM1Nl0gMzFkYmUgaXMgMjVlNDYwMDAhDQpbICAxNjEuOTk5NTU1XSAzMWRiZiBp
cyAyNWU0ZDAwMCENClsgIDE2Mi4wMDE4OTZdIDMxZGMwIGlzIDI1ZTVmMDAwIQ0KWyAgMTYy
LjAwNDIxNl0gMzFkYzEgaXMgMjVlNjAwMDAhDQpbICAxNjIuMDA2NDAzXSAzMWRjMiBpcyAy
NWU1ZTAwMCENClsgIDE2Mi4wMDg3ODFdIDMxZGMzIGlzIDI1ZTVkMDAwIQ0KWyAgMTYyLjAx
MTA4OF0gMzFkYzQgaXMgMjVlNjMwMDAhDQpbICAxNjIuMDIyNTM4XSAzMWRjNSBpcyAyNWU2
NDAwMCENClsgIDE2Mi4wMjQ4NjNdIDMxZGM2IGlzIDI1ZTY1MDAwIQ0KWyAgMTYyLjAyNzA2
N10gMzFkYzcgaXMgMjVlNTQwMDAhDQpbICAxNjIuMDMzNDg3XSAzMWRjOCBpcyAyNWU1MTAw
MCENClsgIDE2Mi4wNjk0NDJdIDMxZGM5IGlzIDI1ZTUwMDAwIQ0KWyAgMTYyLjA3MTczNV0g
MzFkOWMgaXMgMjVlNTMwMDAhDQpbICAxNjIuMDg0NjU4XSAzMWRjYSBpcyAyNWU0NzAwMCEN
ClsgIDE2Mi4wODcwMzVdIDMxZGNiIGlzIDI1ZTQ4MDAwIQ0KWyAgMTYyLjExNjcwMF0gMzFk
Y2MgaXMgMjVlNGMwMDAhDQpbICAxNjIuMTE4OTk4XSAzMWQ5ZCBpcyAyNWU1MjAwMCENClsg
IDE2Mi4xMjEzMjldIDMxZGNkIGlzIDI1ZTYyMDAwIQ0KWyAgMTYyLjEyMzY0Nl0gMzFkY2Ug
aXMgMjVlNjEwMDAhDQpbICAxNjIuMTM0NzQ0XSAzMWRjZiBpcyAyNWU0ZTAwMCENClsgIDE2
Mi4xMzY5MTJdIDMxZGQwIGlzIDI1ZTRmMDAwIQ0KWyAgMTYyLjEzOTIxM10gMzFkZDEgaXMg
MjYwMGYwMDAhDQpbICAxNjIuMTQ4OTk5XSAzMWRkYyBpcyAyNTc5YTAwMCENClsgIDE2Mi4x
NTk1MDBdIDMxZGQyIGlzIDI1ZTM1MDAwIQ0KWyAgMTYyLjE2MTM1M10gMzFkZGQgaXMgMjYw
MTAwMDAhDQpbICAxNjIuMTYzMTczXSAzMWRkZSBpcyAyMzRjYTAwMCENClsgIDE2Mi4xNjUw
MzVdIDMxZGRmIGlzIDI1ZTRiMDAwIQ0KWyAgMTYyLjE2Njg4Nl0gMzFkZTAgaXMgMjUzZDAw
MDAhDQpbICAxNjIuMTY4NzM2XSAzMWRlMSBpcyAyNjAwZTAwMCENClsgIDE2Mi4xNzA2MzJd
IDMxZGUyIGlzIDI1MWYwMDAwIQ0KWyAgMTYyLjE3MjUwOV0gMzFkZTMgaXMgMjVlNTkwMDAh
DQpbICAxNjIuMTc1NDA0XSAzMWRmMCBpcyAyNWUyOTAwMCENClsgIDE2Mi4xNzczMjddIDMx
ZGYxIGlzIDI1ZTJhMDAwIQ0KWyAgMTYyLjE3OTIzNF0gMzFkZjIgaXMgMjVlMmIwMDAhDQpb
ICAxNjIuMTgxMTE5XSAzMWRmMyBpcyAyNWUyYzAwMCENClsgIDE2Mi4xODMwMDFdIDMxZGY0
IGlzIDI1ZTJkMDAwIQ0KWyAgMTYyLjE4NDg4MV0gMzFkZTUgaXMgMjVlMmUwMDAhDQpbICAx
NjIuMTg2Nzc3XSAzMWRlNiBpcyAyNWUyZjAwMCENClsgIDE2Mi4xODg2MzRdIDMxZGU3IGlz
IDI1ZTMwMDAwIQ0KWyAgMTYyLjE5MDUyOF0gMzFkZTggaXMgMjVlNTUwMDAhDQpbICAxNjIu
MTkyMzk2XSAzMWRlOSBpcyAyNWU1NjAwMCENClsgIDE2Mi4xOTQyOTNdIDMxZGVhIGlzIDI1
ZTU3MDAwIQ0KWyAgMTYyLjE5NjE1OF0gMzFkZWIgaXMgMjVlNTgwMDAhDQpbICAxNjIuMTk4
MDM2XSAzMWRlYyBpcyAyNWUzMTAwMCENClsgIDE2Mi4xOTk5MDldIDMxZGVkIGlzIDI1ZTMy
MDAwIQ0KWyAgMTYyLjIwMTc2M10gMzFkZWUgaXMgMjU0NWYwMDAhDQpbICAxNjIuMjAzNjU3
XSAzMWRlZiBpcyAyNTQ2MDAwMCENClsgIDE2Mi4yMDY5MjddIDMxZGZiIGlzIDI1ZTEzMDAw
IQ0KWyAgMTYyLjIwODgzNV0gMzFkZmMgaXMgMjVlMTQwMDAhDQpbICAxNjIuMjEwNzYxXSAz
MWRmZCBpcyAyNWUxNTAwMCENClsgIDE2Mi4yMTI2MzldIDMxZGZlIGlzIDI1ZTE2MDAwIQ0K
WyAgMTYyLjIxNDUzMF0gMzFkZmYgaXMgMjVlMTcwMDAhDQpbICAxNjIuMjE2NDE3XSAzMWUw
MCBpcyAyNWUxODAwMCENClsgIDE2Mi4yMTgyODddIDMxZTAxIGlzIDI1ZTE5MDAwIQ0KWyAg
MTYyLjIyMDE2MV0gMzFlMDIgaXMgMjVlMWEwMDAhDQpbICAxNjIuMjIxOTc5XSAzMWUwMyBp
cyAyNWUxYjAwMCENClsgIDE2Mi4yMjM4MThdIDMxZTA0IGlzIDI1ZTFjMDAwIQ0KWyAgMTYy
LjIyNTYwOV0gMzFlMDUgaXMgMjVlMWQwMDAhDQpbICAxNjIuMjI3ODQ2XSAzMWUwNiBpcyAy
NWUwOTAwMCENClsgIDE2Mi4yMjk2MTZdIDMxZTA3IGlzIDI1ZTBhMDAwIQ0KWyAgMTYyLjIz
MTM4OV0gMzFlMDggaXMgMjVlMGIwMDAhDQpbICAxNjIuMjMzMTMxXSAzMWUwOSBpcyAyNWUw
YzAwMCENClsgIDE2Mi4yMzQ4NTJdIDMxZTBhIGlzIDI1ZTBkMDAwIQ0KWyAgMTYyLjIzNjYw
WyAgMTY0LjM2Mzk4NV0gMzE5YmYgaXMgMjY4ZmYwMDAhDQpbICAxNjQuMzY1NjgzXSAzMTlh
NiBpcyAyNjhlYjAwMCENClsgIDE2NC4zNjczODNdIDMxOWE1IGlzIDI2OGVjMDAwIQ0KWyAg
MTY0LjM2OTA1MV0gMzE5YTQgaXMgMjY4ZWQwMDAhDQpbICAxNjQuMzcwNzQ5XSAzMTlhMyBp
cyAyNjhlZTAwMCENClsgIDE2NC4zNzI0MjFdIDMxOWEyIGlzIDI2OGVmMDAwIQ0KWyAgMTY0
LjM3NDEyMl0gMzE5YTEgaXMgMjY4ZjAwMDAhDQpbICAxNjQuMzc1Nzg0XSAzMTlhMCBpcyAy
NjhmMTAwMCENClsgIDE2NC4zNzc0NTldIDMxOTlmIGlzIDI2OGYyMDAwIQ0KWyAgMTY0LjM3
OTE0Ml0gMzE5OWUgaXMgMjY4ZjMwMDAhDQpbICAxNjQuMzgwODI0XSAzMTk5ZCBpcyAyNjhm
NDAwMCENClsgIDE2NC4zODI1MTBdIDMxOTljIGlzIDI2OGY1MDAwIQ0KWyAgMTY0LjM4NTg1
MV0gMzE5ZWIgaXMgMjY4YjYwMDAhDQpbICAxNjQuMzg3NjIyXSAzMTllYyBpcyAyNjhiNzAw
MCENClsgIDE2NC4zODkzMTRdIDMxOWVkIGlzIDI2OGI4MDAwIQ0KWyAgMTY0LjM5MTAzNV0g
MzE5ZWUgaXMgMjY4YjkwMDAhDQpbICAxNjQuMzkyNzIwXSAzMTllZiBpcyAyNjhiYTAwMCEN
ClsgIDE2NC4zOTQ0MThdIDMxOWYwIGlzIDI2OGJiMDAwIQ0KWyAgMTY0LjM5NjE0NF0gMzE5
ZjEgaXMgMjY4YmMwMDAhDQpbICAxNjQuMzk3ODM4XSAzMTlmMiBpcyAyNjhiZDAwMCENClsg
IDE2NC4zOTk1NTFdIDMxOWYzIGlzIDI2OGJlMDAwIQ0KWyAgMTY0LjQwMTI0Nl0gMzE5ZjQg
aXMgMjY4YmYwMDAhDQpbICAxNjQuNDAyOTQzXSAzMTlkZiBpcyAyNjhjYjAwMCENClsgIDE2
NC40MDQ2ODRdIDMxOWRlIGlzIDI2OGNjMDAwIQ0KWyAgMTY0LjQwNjM4NF0gMzE5ZGQgaXMg
MjY4Y2QwMDAhDQpbICAxNjQuNDA4MDk4XSAzMTlkYyBpcyAyNjhjZTAwMCENClsgIDE2NC40
MDk3OTNdIDMxOWRiIGlzIDI2OGNmMDAwIQ0KWyAgMTY0LjQxMTQ5M10gMzE5ZGEgaXMgMjY4
ZDAwMDAhDQpbICAxNjQuNDEzMTU0XSAzMTlkOSBpcyAyNjhkMTAwMCENClsgIDE2NC40MTQ4
MzBdIDMxOWQ4IGlzIDI2OGQyMDAwIQ0KWyAgMTY0LjQxNjUxMV0gMzE5ZDcgaXMgMjY4ZDMw
MDAhDQpbICAxNjQuNDE4MTgwXSAzMTlkNiBpcyAyNjhkNDAwMCENClsgIDE2NC40MTk4NjJd
IDMxOWQ1IGlzIDI2OGQ1MDAwIQ0KWyAgMTY0LjQyMTUyNV0gMzE5YzEgaXMgMjY4YzAwMDAh
DQpbICAxNjQuNDIzMjAzXSAzMTljMiBpcyAyNjhjMTAwMCENClsgIDE2NC40MjQ5MjFdIDMx
OWMzIGlzIDI2OGMyMDAwIQ0KWyAgMTY0LjQyNjU5NF0gMzE5YzQgaXMgMjY4YzMwMDAhDQpb
ICAxNjQuNDI4MzA2XSAzMTljNSBpcyAyNjhjNDAwMCENClsgIDE2NC40Mjk5ODBdIDMxOWM2
IGlzIDI2OGM1MDAwIQ0KWyAgMTY0LjQzMTY2N10gMzE5YzcgaXMgMjY4YzYwMDAhDQpbICAx
NjQuNDMzMzY1XSAzMTljOCBpcyAyNjhjNzAwMCENClsgIDE2NC40MzUwNDZdIDMxOWM5IGlz
IDI2OGM4MDAwIQ0KWyAgMTY0LjQzNjc1NF0gMzE5Y2EgaXMgMjY4YzkwMDAhDQpbICAxNjQu
NDM4NDE1XSAzMTljYiBpcyAyNjhjYTAwMCENClsgIDE2NC40NDEyMjNdIDMxYTAwIGlzIDI2
OGEwMDAwIQ0KWyAgMTY0LjQ0Mjk3OV0gMzFhMDEgaXMgMjY4YTEwMDAhDQpbICAxNjQuNDQ0
NzAwXSAzMWEwMiBpcyAyNjhhMjAwMCENClsgIDE2NC40NDYzODFdIDMxYTAzIGlzIDI2OGEz
MDAwIQ0KWyAgMTY0LjQ0ODA3NV0gMzFhMDQgaXMgMjY4YTQwMDAhDQpbICAxNjQuNDQ5Nzgx
XSAzMWEwNSBpcyAyNjhhNTAwMCENClsgIDE2NC40NTE0NjVdIDMxYTA2IGlzIDI2OGE2MDAw
IQ0KWyAgMTY0LjQ1MzE3Nl0gMzFhMDcgaXMgMjY4YTcwMDAhDQpbICAxNjQuNDU0ODY0XSAz
MWEwOCBpcyAyNjhhODAwMCENClsgIDE2NC40NTY1MzJdIDMxYTA5IGlzIDI2OGE5MDAwIQ0K
WyAgMTY0LjQ1ODIyOV0gMzFhMGEgaXMgMjY4YWEwMDAhDQpbICAxNjQuNDU5OTA4XSAzMWEw
YiBpcyAyNjg5NjAwMCENClsgIDE2NC40NjE2MjJdIDMxYTBjIGlzIDI2ODk3MDAwIQ0KWyAg
MTY0LjQ2MzMxNl0gMzFhMGQgaXMgMjY4OTgwMDAhDQpbICAxNjQuNDY1MDE2XSAzMWEwZSBp
cyAyNjg5OTAwMCENClsgIDE2NC40NjY3NDFdIDMxYTBmIGlzIDI2ODlhMDAwIQ0KWyAgMTY0
LjQ2ODQyMF0gMzFhMTAgaXMgMjY4OWIwMDAhDQpbICAxNjQuNDcwMTQyXSAzMWExMSBpcyAy
Njg5YzAwMCENClsgIDE2NC40NzE4MjBdIDMxYTEyIGlzIDI2ODlkMDAwIQ0KWyAgMTY0LjQ3
MzUxMl0gMzFhMTMgaXMgMjY4OWUwMDAhDQpbICAxNjQuNDc1MjA2XSAzMWExNCBpcyAyNjg5
ZjAwMCENClsgIDE2NC40NzY4ODJdIDMxOWZmIGlzIDI2ODhiMDAwIQ0KWyAgMTY0LjQ3ODU3
N10gMzE5ZmUgaXMgMjY4OGMwMDAhDQpbICAxNjQuNDgwMjY5XSAzMTlmZCBpcyAyNjg4ZDAw
MCENClsgIDE2NC40ODE5NTNdIDMxOWZjIGlzIDI2ODhlMDAwIQ0KWyAgMTY0LjQ4MzY2OF0g
MzE5ZmIgaXMgMjY4OGYwMDAhDQpbICAxNjQuNDg1MzUyXSAzMTlmYSBpcyAyNjg5MDAwMCEN
ClsgIDE2NC40ODcwNjddIDMxOWY5IGlzIDI2ODkxMDAwIQ0KWyAgMTY0LjQ4ODc1OF0gMzE5
ZjggaXMgMjY4OTIwMDAhDQpbICAxNjQuNDkwNDc2XSAzMTlmNyBpcyAyNjg5MzAwMCENClsg
IDE2NC40OTIxNzFdIDMxOWY2IGlzIDI2ODk0MDAwIQ0KWyAgMTY0LjQ5Mzg3NV0gMzE5ZjUg
aXMgMjY4OTUwMDAhDQpbICAxNjQuNDk2NDc0XSAzMTllOSBpcyAyNjg2YjAwMCENClsgIDE2
NC40OTgyMTNdIDMxOWU4IGlzIDI2ODZjMDAwIQ0KWyAgMTY0LjQ5OTkyMF0gMzE5ZTcgaXMg
MjY4NmQwMDAhDQpbICAxNjQuNTAxNjEyXSAzMTllNiBpcyAyNjg2ZTAwMCENClsgIDE2NC41
MDMzMjhdIDMxOWU1IGlzIDI2ODZmMDAwIQ0KWyAgMTY0LjUwNTA0M10gMzE5ZTQgaXMgMjY4
NzAwMDAhDQpbICAxNjQuNTA2NzYyXSAzMTllMyBpcyAyNjg3MTAwMCENClsgIDE2NC41MDg0
NzhdIDMxOWUyIGlzIDI2ODcyMDAwIQ0KWyAgMTY0LjUxMDE5MF0gMzE5ZTEgaXMgMjY4NzMw
MDAhDQpbICAxNjQuNTExOTA0XSAzMTllMCBpcyAyNjg3NDAwMCENClsgIDE2NC41MTM2MDld
IDMxYTE1IGlzIDI2ODc1MDAwIQ0KWyAgMTY0LjUxNTMyM10gMzE5ZWEgaXMgMjY4NzYwMDAh
DQpbICAxNjQuNTE3MDQxXSAzMWEyOSBpcyAyNjg3NzAwMCENClsgIDE2NC41MTg3NTBdIDMx
YTJhIGlzIDI2ODc4MDAwIQ0KWyAgMTY0LjUyMDUxNl0gMzFhMmIgaXMgMjY4NzkwMDAhDQpb
ICAxNjQuNTIyMjM4XSAzMWEyYyBpcyAyNjg3YTAwMCENClsgIDE2NC41MjM5OTZdIDMxYTJk
IGlzIDI2ODdiMDAwIQ0KWyAgMTY0LjUyNTcwOF0gMzFhMmUgaXMgMjY4N2MwMDAhDQpbICAx
NjQuNTI3NDM2XSAzMWEyZiBpcyAyNjg3ZDAwMCENClsgIDE2NC41MjkxNzhdIDMxYTMwIGlz
IDI2ODdlMDAwIQ0KWyAgMTY0LjUzMDkwNV0gMzFhMzEgaXMgMjY4N2YwMDAhDQpbICAxNjQu
NTMzNTk0XSAzMWEyMCBpcyAyNjg1NjAwMCENClsgIDE2NC41MzU1MTddIDMxYTIxIGlzIDI2
ODU3MDAwIQ0KWyAgMTY0LjUzNzM2NF0gMzFhMjIgaXMgMjY4NTgwMDAhDQpbICAxNjQuNTM5
MjI4XSAzMWEyMyBpcyAyNjg1OTAwMCENClsgIDE2NC41NDExNjRdIDMxYTI0IGlzIDI2ODVh
MDAwIQ0KWyAgMTY0LjU0MzAyMl0gMzFhMjUgaXMgMjY4NWIwMDAhDQpbICAxNjQuNTQ0OTI0
XSAzMWEyNiBpcyAyNjg1YzAwMCENClsgIDE2NC41NDY2NzhdIDMxYTI3IGlzIDI2ODVkMDAw
IQ0KWyAgMTY0LjU0ODQwOV0gMzFhMjggaXMgMjY4NWUwMDAhDQpbICAxNjQuNTUwMTU3XSAz
MWE0OCBpcyAyNjg1ZjAwMCENClsgIDE2NC41Nzg2NzBdIDMxYTNkIGlzIDI2ODQwMDAwIQ0K
WyAgMTY0LjU4MDQyMF0gMzFhM2UgaXMgMjY4NDEwMDAhDQpbICAxNjQuNTgyMjM3XSAzMWEz
ZiBpcyAyNjg0MjAwMCENClsgIDE2NC41ODQwNzddIDMxYTQwIGlzIDI2ODQzMDAwIQ0KWyAg
MTY0LjU4NTc4N10gMzFhNDEgaXMgMjY4NDQwMDAhDQpbICAxNjQuNTg3NTMxXSAzMWE0MiBp
cyAyNjg0NTAwMCENClsgIDE2NC41ODkyMzJdIDMxYTQzIGlzIDI2ODQ2MDAwIQ0KWyAgMTY0
LjU5MDk2NV0gMzFhNDQgaXMgMjY4NDcwMDAhDQpbICAxNjQuNTkyNjY0XSAzMWE0NSBpcyAy
Njg0ODAwMCENClsgIDE2NC41OTQ0MzldIDMxYTQ2IGlzIDI2ODQ5MDAwIQ0KWyAgMTY0LjU5
NjEyNl0gMzFhNDcgaXMgMjY4NGEwMDAhDQpbICAxNjQuNTk4MjU5XSAzMWE3MiBpcyAyNjgy
MDAwMCENClsgIDE2NC41OTk5NzRdIDMxYTRhIGlzIDI2ODIxMDAwIQ0KWyAgMTY0LjYwMTY3
Nl0gMzFhNGIgaXMgMjY4MjIwMDAhDQpbICAxNjQuNjAzMzk1XSAzMWE0YyBpcyAyNjgyMzAw
MCENClsgIDE2NC42MDUwNzBdIDMxYTRkIGlzIDI2ODI0MDAwIQ0KWyAgMTY0LjYwNjc2NV0g
MzFhNGUgaXMgMjY4MjUwMDAhDQpbICAxNjQuNjA4NDU5XSAzMWE0ZiBpcyAyNjgyNjAwMCEN
ClsgIDE2NC42MTAxNTVdIDMxYTUwIGlzIDI2ODI3MDAwIQ0KWyAgMTY0LjYxMTg0OV0gMzFh
NTEgaXMgMjY4MjgwMDAhDQpbICAxNjQuNjEzNTM2XSAzMWE1MiBpcyAyNjgyOTAwMCENClsg
IDE2NC42MTUyMTddIDMxYTUzIGlzIDI2ODJhMDAwIQ0KWyAgMTY0LjYxNjg4N10gMzFhNTQg
aXMgMjY4MTYwMDAhDQpbICAxNjQuNjE4NTQ4XSAzMWE1NSBpcyAyNjgxNzAwMCENClsgIDE2
NC42MjAyNDBdIDMxYTU2IGlzIDI2ODE4MDAwIQ0KWyAgMTY0LjYyMTkwMV0gMzFhNTcgaXMg
MjY4MTkwMDAhDQpbICAxNjQuNjIzNTg1XSAzMWE1OCBpcyAyNjgxYTAwMCENClsgIDE2NC42
MjUyNDBdIDMxYTU5IGlzIDI2ODFiMDAwIQ0KWyAgMTY0LjYyNjkxN10gMzFhNWEgaXMgMjY4
MWMwMDAhDQpbICAxNjQuNjI4NTk0XSAzMWE1YiBpcyAyNjgxZDAwMCENClsgIDE2NC42MzAy
NzBdIDMxYTVjIGlzIDI2ODFlMDAwIQ0KWyAgMTY0LjYzMTk0NV0gMzFhNWQgaXMgMjY4MWYw
MDAhDQpbICAxNjQuNjMzNjAxXSAzMWEzMiBpcyAyNjgyYjAwMCENClsgIDE2NC42MzUyNTdd
IDMxYTE2IGlzIDI2ODJjMDAwIQ0KWyAgMTY0LjYzNjk0OF0gMzFhMTcgaXMgMjY4MmQwMDAh
DQpbICAxNjQuNjM4NjExXSAzMWExOCBpcyAyNjgyZTAwMCENClsgIDE2NC42NDAzMDZdIDMx
YTE5IGlzIDI2ODJmMDAwIQ0KWyAgMTY0LjY0MTk3OV0gMzFhMWEgaXMgMjY4MzAwMDAhDQpb
ICAxNjQuNjQzNjc3XSAzMWExYiBpcyAyNjgzMTAwMCENClsgIDE2NC42NDUzNjVdIDMxYTFj
IGlzIDI2ODMyMDAwIQ0KWyAgMTY0LjY0NzA1OF0gMzFhMWQgaXMgMjY4MzMwMDAhDQpbICAx
NjQuNjQ4NzUyXSAzMWExZSBpcyAyNjgzNDAwMCENClsgIDE2NC42NTA0MzldIDMxYTFmIGlz
IDI2ODM1MDAwIQ0KWyAgMTY0LjY1MjEwNF0gMzFhNjcgaXMgMjY4MzYwMDAhDQpbICAxNjQu
NjUzODAyXSAzMWE2OCBpcyAyNjgzNzAwMCENClsgIDE2NC42NTU0NTddIDMxYTY5IGlzIDI2
ODM4MDAwIQ0KWyAgMTY0LjY1NzE0M10gMzFhNmEgaXMgMjY4MzkwMDAhDQpbICAxNjQuNjU4
Nzk4XSAzMWE2YiBpcyAyNjgzYTAwMCENClsgIDE2NC42NjA0NjhdIDMxYTZjIGlzIDI2ODNi
MDAwIQ0KWyAgMTY0LjY2MjE0MF0gMzFhNmQgaXMgMjY4M2MwMDAhDQpbICAxNjQuNjYzODA0
XSAzMWE2ZSBpcyAyNjgzZDAwMCENClsgIDE2NC42NjU0NzBdIDMxYTZmIGlzIDI2ODNlMDAw
IQ0KWyAgMTY0LjY2NzEzNl0gMzFhNzAgaXMgMjY4M2YwMDAhDQpbICAxNjQuNjcwNDIwXSAz
MWE5MiBpcyAyNjdmNjAwMCENClsgIDE2NC42NzIxNTBdIDMxYTkzIGlzIDI2N2Y3MDAwIQ0K
WyAgMTY0LjY3Mzg4OF0gMzFhOTQgaXMgMjY3ZjgwMDAhDQpbICAxNjQuNjc1NTgyXSAzMWE5
NSBpcyAyNjdmOTAwMCENClsgIDE2NC42NzcyNzZdIDMxYTk2IGlzIDI2N2ZhMDAwIQ0KWyAg
MTY0LjY3ODk4MV0gMzFhOTcgaXMgMjY3ZmIwMDAhDQpbICAxNjQuNjgwNjcxXSAzMWE5OCBp
cyAyNjdmYzAwMCENClsgIDE2NC42ODIzNzZdIDMxYTk5IGlzIDI2N2ZkMDAwIQ0KWyAgMTY0
LjY4NDA1OV0gMzFhOWEgaXMgMjY3ZmUwMDAhDQpbICAxNjQuNjg1NzM1XSAzMWE5YiBpcyAy
NjdmZjAwMCENClsgIDE2NC42ODc0NDRdIDMxYTczIGlzIDI2ODBiMDAwIQ0KWyAgMTY0LjY4
OTEzM10gMzFhNWUgaXMgMjY4MGMwMDAhDQpbICAxNjQuNjkwODM2XSAzMWE1ZiBpcyAyNjgw
ZDAwMCENClsgIDE2NC42OTI0OTddIDMxYTYwIGlzIDI2ODBlMDAwIQ0KWyAgMTY0LjY5NDIw
NF0gMzFhNjEgaXMgMjY4MGYwMDAhDQpbICAxNjQuNjk1ODY0XSAzMWE2MiBpcyAyNjgxMDAw
MCENClsgIDE2NC42OTc1MzNdIDMxYTYzIGlzIDI2ODExMDAwIQ0KWyAgMTY0LjY5OTIyMF0g
MzFhNjQgaXMgMjY4MTIwMDAhDQpbICAxNjQuNzAwODk2XSAzMWE2NSBpcyAyNjgxMzAwMCEN
ClsgIDE2NC43MDI1OTNdIDMxYTY2IGlzIDI2ODE0MDAwIQ0KWyAgMTY0LjcwNDI4MF0gMzFh
ODYgaXMgMjY4MTUwMDAhDQpbICAxNjQuNzA1OTQ3XSAzMWE4NyBpcyAyNjgwMDAwMCENClsg
IDE2NC43MDc2NTFdIDMxYTg4IGlzIDI2ODAxMDAwIQ0KWyAgMTY0LjcwOTMyNV0gMzFhODkg
aXMgMjY4MDIwMDAhDQpbICAxNjQuNzExMDM3XSAzMWE4YSBpcyAyNjgwMzAwMCENClsgIDE2
NC43MTI3MTZdIDMxYThiIGlzIDI2ODA0MDAwIQ0KWyAgMTY0LjcxNDQwOF0gMzFhOGMgaXMg
MjY4MDUwMDAhDQpbICAxNjQuNzE2MTExXSAzMWE4ZCBpcyAyNjgwNjAwMCENClsgIDE2NC43
MTc4MDNdIDMxYThlIGlzIDI2ODA3MDAwIQ0KWyAgMTY0LjcxOTUwNl0gMzFhOGYgaXMgMjY4
MDgwMDAhDQpbICAxNjQuNzIxMTkzXSAzMWE5MCBpcyAyNjgwOTAwMCENClsgIDE2NC43MjI4
NzBdIDMxYTkxIGlzIDI2ODBhMDAwIQ0KWyAgMTY0LjcyNTU4MV0gMzFhYTkgaXMgMjY3ZTAw
MDAhDQpbICAxNjQuNzI3Mzc3XSAzMWFhYSBpcyAyNjdlMTAwMCENClsgIDE2NC43MjkwOTZd
IDMxYWFiIGlzIDI2N2UyMDAwIQ0KWyAgMTY0LjczMDgxNV0gMzFhYWMgaXMgMjY3ZTMwMDAh
DQpbICAxNjQuNzMyNTQyXSAzMWFhZCBpcyAyNjdlNDAwMCENClsgIDE2NC43MzQyNjddIDMx
YWFlIGlzIDI2N2U1MDAwIQ0KWyAgMTY0LjczNjA2MF0gMzFhYWYgaXMgMjY3ZTYwMDAhDQpb
ICAxNjQuNzM3NzgzXSAzMWFiMCBpcyAyNjdlNzAwMCENClsgIDE2NC43Mzk0OTFdIDMxYWIx
IGlzIDI2N2U4MDAwIQ0KWyAgMTY0Ljc0MTI0MV0gMzFhYjIgaXMgMjY3ZTkwMDAhDQpbICAx
NjQuNzQyOTMxXSAzMWFiMyBpcyAyNjdlYTAwMCENClsgIDE2NC43NDQ2NTRdIDMxYWI0IGlz
IDI2N2Q2MDAwIQ0KWyAgMTY0Ljc0NjMzOF0gMzFhYjUgaXMgMjY3ZDcwMDAhDQpbICAxNjQu
NzQ4MDI5XSAzMWFiNiBpcyAyNjdkODAwMCENClsgIDE2NC43NDk3NDBdIDMxYWI3IGlzIDI2
N2Q5MDAwIQ0KWyAgMTY0Ljc1MTQyMl0gMzFhYjggaXMgMjY3ZGEwMDAhDQpbICAxNjQuNzUz
MTExXSAzMWFiOSBpcyAyNjdkYjAwMCENClsgIDE2NC43NTQ3OThdIDMxYWJhIGlzIDI2N2Rj
MDAwIQ0KWyAgMTY0Ljc1NjQ1OV0gMzFhYmIgaXMgMjY3ZGQwMDAhDQpbICAxNjQuNzU4MTU3
XSAzMWFiYyBpcyAyNjdkZTAwMCENClsgIDE2NC43NTk4MThdIDMxYWJkIGlzIDI2N2RmMDAw
IQ0KWyAgMTY0Ljc2MTUwNF0gMzFhYTggaXMgMjY3Y2IwMDAhDQpbICAxNjQuNzYzMTc3XSAz
MWFhNSBpcyAyNjdjYzAwMCENClsgIDE2NC43NjQ4NjRdIDMxYWE0IGlzIDI2N2NkMDAwIQ0K
WyAgMTY0Ljc2NjU0Nl0gMzFhYTMgaXMgMjY3Y2UwMDAhDQpbICAxNjQuNzY4MjI4XSAzMWFh
MiBpcyAyNjdjZjAwMCENClsgIDE2NC43Njk5MTJdIDMxYWExIGlzIDI2N2QwMDAwIQ0KWyAg
MTY0Ljc3MTYwMF0gMzFhYTAgaXMgMjY3ZDEwMDAhDQpbICAxNjQuNzczMjkyXSAzMWE5ZiBp
cyAyNjdkMjAwMCENClsgIDE2NC43NzQ5OTZdIDMxYTllIGlzIDI2N2QzMDAwIQ0KWyAgMTY0
Ljc3NjY2OV0gMzFhOWQgaXMgMjY3ZDQwMDAhDQpbICAxNjQuNzc4MzczXSAzMWE5YyBpcyAy
NjdkNTAwMCENClsgIDE2NC43ODA2MjJdIDMxYTdlIGlzIDI2N2I2MDAwIQ0KWyAgMTY0Ljc4
MjM2NF0gMzFhN2YgaXMgMjY3YjcwMDAhDQpbICAxNjQuNzg0MDc5XSAzMWE4MCBpcyAyNjdi
ODAwMCENClsgIDE2NC43ODU3OTldIDMxYTgxIGlzIDI2N2I5MDAwIQ0KWyAgMTY0Ljc4NzQ4
OF0gMzFhODIgaXMgMjY3YmEwMDAhDQpbICAxNjQuNzg5MTgyXSAzMWE4MyBpcyAyNjdiYjAw
MCENClsgIDE2NC43OTA4OTddIDMxYTg0IGlzIDI2N2JjMDAwIQ0KWyAgMTY0Ljc5MjU3N10g
MzFhODUgaXMgMjY3YmQwMDAhDQpbICAxNjQuNzk0Mjg1XSAzMWFjNiBpcyAyNjdiZTAwMCEN
ClsgIDE2NC43OTU5ODJdIDMxYWM3IGlzIDI2N2JmMDAwIQ0KWyAgMTY0LjgwMzIxMl0gMzFh
YzggaXMgMjY3YTAwMDAhDQpbICAxNjQuODA0OTE2XSAzMWFiZiBpcyAyNjdhMTAwMCENClsg
IDE2NC44MDY2MDRdIDMxYWMwIGlzIDI2N2EyMDAwIQ0KWyAgMTY0LjgwODQ1MV0gMzFhYzEg
aXMgMjY3YTMwMDAhDQpbICAxNjQuODEwMTY0XSAzMWFjMiBpcyAyNjdhNDAwMCENClsgIDE2
NC44MTE4NjFdIDMxYWMzIGlzIDI2N2E1MDAwIQ0KWyAgMTY0LjgxMzU1Nl0gMzFhYzQgaXMg
MjY3YTYwMDAhDQpbICAxNjQuODE1MjQ4XSAzMWFjNSBpcyAyNjdhNzAwMCENClsgIDE2NC44
MTY5NDJdIDMxYWU1IGlzIDI2N2E4MDAwIQ0KWyAgMTY0LjgxODYyMF0gMzFhZTYgaXMgMjY3
YTkwMDAhDQpbICAxNjQuODIwMzMxXSAzMWFlNyBpcyAyNjdhYTAwMCENClsgIDE2NC44MjIx
MThdIDMxYWU5IGlzIDI2Nzk3MDAwIQ0KWyAgMTY0LjgyMzg0N10gMzFhZWEgaXMgMjY3OTgw
MDAhDQpbICAxNjQuODI1NTE3XSAzMWFlYiBpcyAyNjc5OTAwMCENClsgIDE2NC44MjcyMDBd
IDMxYWVjIGlzIDI2NzlhMDAwIQ0KWyAgMTY0LjgyODg5Ml0gMzFhZWQgaXMgMjY3OWIwMDAh
DQpbICAxNjQuODMwNTY4XSAzMWFlZSBpcyAyNjc5YzAwMCENClsgIDE2NC44MzIyNTRdIDMx
YWVmIGlzIDI2NzlkMDAwIQ0KWyAgMTY0LjgzMzkyNV0gMzFhZjAgaXMgMjY3OWUwMDAhDQpb
ICAxNjQuODM1NTg5XSAzMWFmMSBpcyAyNjc5ZjAwMCENClsgIDE2NC44NTgyNzVdIDMxYWQz
IGlzIDI2Nzc2MDAwIQ0KWyAgMTY0Ljg1OTk2NF0gMzFhZDQgaXMgMjY3NzcwMDAhDQpbICAx
NjQuODYxNjY3XSAzMWFkNSBpcyAyNjc3ODAwMCENClsgIDE2NC44NjMzMzFdIDMxYWQ2IGlz
IDI2Nzc5MDAwIQ0KWyAgMTY0Ljg2NTAyN10gMzFhZDcgaXMgMjY3N2EwMDAhDQpbICAxNjQu
ODY2NzQ0XSAzMWFkOCBpcyAyNjc3YjAwMCENClsgIDE2NC44Njg0MTRdIDMxYWQ5IGlzIDI2
NzdjMDAwIQ0KWyAgMTY0Ljg3MDExNl0gMzFhZGEgaXMgMjY3N2QwMDAhDQpbICAxNjQuODcx
Nzc1XSAzMWFkYiBpcyAyNjc3ZTAwMCENClsgIDE2NC44NzM0NzZdIDMxYWRjIGlzIDI2Nzdm
MDAwIQ0KWyAgMTY0Ljg3NTEyOF0gMzFhYmUgaXMgMjY3OGIwMDAhDQpbICAxNjQuODc2ODE2
XSAzMWE3NCBpcyAyNjc4YzAwMCENClsgIDE2NC44Nzg0OThdIDMxYTc1IGlzIDI2NzhkMDAw
IQ0KWyAgMTY0Ljg4MDE4MV0gMzFhNzYgaXMgMjY3OGUwMDAhDQpbICAxNjQuODgxODYxXSAz
MWE3NyBpcyAyNjc4ZjAwMCENClsgIDE2NC44ODM1MzhdIDMxYTc4IGlzIDI2NzkwMDAwIQ0K
WyAgMTY0Ljg4NTE5Nl0gMzFhNzkgaXMgMjY3OTEwMDAhDQpbICAxNjQuODg2ODk1XSAzMWE3
YSBpcyAyNjc5MjAwMCENClsgIDE2NC44ODg1NTZdIDMxYTdiIGlzIDI2NzkzMDAwIQ0KWyAg
MTY0Ljg5MDI0OV0gMzFhN2MgaXMgMjY3OTQwMDAhDQpbICAxNjQuODkxOTE3XSAzMWE3ZCBp
cyAyNjc5NTAwMCENClsgIDE2NC44OTM2MDhdIDMxYWYyIGlzIDI2NzgwMDAwIQ0KWyAgMTY0
Ljg5NTMwMF0gMzFhYzkgaXMgMjY3ODEwMDAhDQpbICAxNjQuODk2OTg5XSAzMWFjYSBpcyAy
Njc4MjAwMCENClsgIDE2NC44OTg2NzddIDMxYWNiIGlzIDI2NzgzMDAwIQ0KWyAgMTY0Ljkw
MDM2M10gMzFhY2MgaXMgMjY3ODQwMDAhDQpbICAxNjQuOTAyMDQ3XSAzMWFjZCBpcyAyNjc4
NTAwMCENClsgIDE2NC45MDM3NjNdIDMxYWNlIGlzIDI2Nzg2MDAwIQ0KWyAgMTY0LjkwNTQ0
MV0gMzFhY2YgaXMgMjY3ODcwMDAhDQpbICAxNjQuOTA3MTUwXSAzMWFkMCBpcyAyNjc4ODAw
MCENClsgIDE2NC45MDg4MzBdIDMxYWQxIGlzIDI2Nzg5MDAwIQ0KWyAgMTY0LjkxMDUzM10g
MzFhZDIgaXMgMjY3OFsgIDE2Ny4wMzk5MjBdIDMxNjgyIGlzIDI2YTMxMDAwIQ0KWyAgMTY3
LjA0MTYxN10gMzE2ODEgaXMgMjZhMzAwMDAhDQpbICAxNjcuMDQzMjk1XSAzMTY4MCBpcyAy
NmE0ZDAwMCENClsgIDE2Ny4wNDUwMTBdIDMxNjdmIGlzIDI2YTRmMDAwIQ0KWyAgMTY3LjA0
NjY5M10gMzE2N2UgaXMgMjZhNGUwMDAhDQpbICAxNjcuMDQ5MjYwXSAzMTY2OCBpcyAyNmEx
MzAwMCENClsgIDE2Ny4wNTA5OTZdIDMxNjY5IGlzIDI2YTE0MDAwIQ0KWyAgMTY3LjA1Mjcw
MF0gMzE2NmEgaXMgMjZhMTUwMDAhDQpbICAxNjcuMDU0NDM5XSAzMTY2YiBpcyAyNmExNjAw
MCENClsgIDE2Ny4wNTYxNDddIDMxNjZjIGlzIDI2YTE3MDAwIQ0KWyAgMTY3LjA1NzkwM10g
MzE2NmQgaXMgMjZhMTgwMDAhDQpbICAxNjcuMDU5NjAyXSAzMTY2ZSBpcyAyNmEzOTAwMCEN
ClsgIDE2Ny4wNjEzMzNdIDMxNjZmIGlzIDI2YTNhMDAwIQ0KWyAgMTY3LjA2MzAzMl0gMzE2
NzAgaXMgMjZhM2IwMDAhDQpbICAxNjcuMDY0NzQyXSAzMTY3MSBpcyAyNmEzYzAwMCENClsg
IDE2Ny4wNjY0NjVdIDMxNjY3IGlzIDI2YTA4MDAwIQ0KWyAgMTY3LjA2ODE4NF0gMzE2NjYg
aXMgMjZhMDkwMDAhDQpbICAxNjcuMDY5OTI3XSAzMTY2NSBpcyAyNmEwYTAwMCENClsgIDE2
Ny4wNzE2MzddIDMxNjY0IGlzIDI2YTBiMDAwIQ0KWyAgMTY3LjA3MzMzM10gMzE2NjMgaXMg
MjZhMGMwMDAhDQpbICAxNjcuMDc1MDYyXSAzMTY2MiBpcyAyNmEwZDAwMCENClsgIDE2Ny4w
NzY3NjBdIDMxNjYxIGlzIDI2YTBlMDAwIQ0KWyAgMTY3LjA3ODQ3MF0gMzE2NjAgaXMgMjZh
MGYwMDAhDQpbICAxNjcuMDgwMTYyXSAzMTY1ZiBpcyAyNmExMDAwMCENClsgIDE2Ny4wODE4
NThdIDMxNjVlIGlzIDI2YTExMDAwIQ0KWyAgMTY3LjA4MzU5M10gMzE2OWUgaXMgMjZhMTIw
MDAhDQpbICAxNjcuMDg2MTM5XSAzMTZhOSBpcyAyNjlmMzAwMCENClsgIDE2Ny4wODc5NzNd
IDMxNmFhIGlzIDI2OWY0MDAwIQ0KWyAgMTY3LjA4OTY5Nl0gMzE2YWIgaXMgMjY5ZjUwMDAh
DQpbICAxNjcuMDkxNDMxXSAzMTZhYyBpcyAyNjlmNjAwMCENClsgIDE2Ny4wOTMxNDJdIDMx
NmFkIGlzIDI2OWY3MDAwIQ0KWyAgMTY3LjA5NDkzNl0gMzE2YWUgaXMgMjY5ZjgwMDAhDQpb
ICAxNjcuMDk2NjQ3XSAzMTZhZiBpcyAyNjlmOTAwMCENClsgIDE2Ny4wOTgzNTNdIDMxNmIw
IGlzIDI2OWZhMDAwIQ0KWyAgMTY3LjEwMDA4OF0gMzE2YjEgaXMgMjY5ZmIwMDAhDQpbICAx
NjcuMTAxNzg5XSAzMTZiMiBpcyAyNjlmYzAwMCENClsgIDE2Ny4xMDM1MzFdIDMxNmE4IGlz
IDI2OWU4MDAwIQ0KWyAgMTY3LjEwNTIzNl0gMzE2YTcgaXMgMjY5ZTkwMDAhDQpbICAxNjcu
MTA2OTM5XSAzMTZhNiBpcyAyNjllYTAwMCENClsgIDE2Ny4xMDg2MzZdIDMxNmE1IGlzIDI2
OWViMDAwIQ0KWyAgMTY3LjExMDMyN10gMzE2YTQgaXMgMjY5ZWMwMDAhDQpbICAxNjcuMTEy
MDEwXSAzMTZhMyBpcyAyNjllZDAwMCENClsgIDE2Ny4xMTM2OTFdIDMxNmEyIGlzIDI2OWVl
MDAwIQ0KWyAgMTY3LjExNTM3M10gMzE2YTEgaXMgMjY5ZWYwMDAhDQpbICAxNjcuMTE3MDQ4
XSAzMTZhMCBpcyAyNjlmMDAwMCENClsgIDE2Ny4xMTg3MTRdIDMxNjlmIGlzIDI2OWYxMDAw
IQ0KWyAgMTY3LjEyMDQyM10gMzE2NzIgaXMgMjY5ZjIwMDAhDQpbICAxNjcuMTIzODIzXSAz
MTZiNCBpcyAyNjliMzAwMCENClsgIDE2Ny4xMjU1NTJdIDMxNmI1IGlzIDI2OWI0MDAwIQ0K
WyAgMTY3LjEyNzI3OV0gMzE2ZDUgaXMgMjY5YjUwMDAhDQpbICAxNjcuMTI5MDA3XSAzMTZk
NiBpcyAyNjliNjAwMCENClsgIDE2Ny4xMzA3MjddIDMxNmQ3IGlzIDI2OWI3MDAwIQ0KWyAg
MTY3LjEzMjQ1MV0gMzE2ZDggaXMgMjY5YjgwMDAhDQpbICAxNjcuMTM0MTYyXSAzMTZkOSBp
cyAyNjliOTAwMCENClsgIDE2Ny4xMzU4NzFdIDMxNmRhIGlzIDI2OWJhMDAwIQ0KWyAgMTY3
LjEzNzYwN10gMzE2ZGIgaXMgMjY5YmIwMDAhDQpbICAxNjcuMTM5Mjk4XSAzMTZkYyBpcyAy
NjliYzAwMCENClsgIDE2Ny4xNDEwMzJdIDMxNmJjIGlzIDI2OWM4MDAwIQ0KWyAgMTY3LjE0
MjcxOF0gMzE2YmIgaXMgMjY5YzkwMDAhDQpbICAxNjcuMTQ0NDM4XSAzMTZiYSBpcyAyNjlj
YTAwMCENClsgIDE2Ny4xNDYxMTddIDMxNmI5IGlzIDI2OWNiMDAwIQ0KWyAgMTY3LjE0Nzgw
OF0gMzE2YjggaXMgMjY5Y2MwMDAhDQpbICAxNjcuMTQ5NTIzXSAzMTZiNyBpcyAyNjljZDAw
MCENClsgIDE2Ny4xNTExOThdIDMxNmI2IGlzIDI2OWNlMDAwIQ0KWyAgMTY3LjE1Mjg5MV0g
MzE2NzUgaXMgMjY5Y2YwMDAhDQpbICAxNjcuMTU0NTY2XSAzMTY3NCBpcyAyNjlkMDAwMCEN
ClsgIDE2Ny4xNTYyMjFdIDMxNjczIGlzIDI2OWQxMDAwIQ0KWyAgMTY3LjE1NzkyMl0gMzE2
YjMgaXMgMjY5ZDIwMDAhDQpbICAxNjcuMTU5NTY1XSAzMTZjNyBpcyAyNjliZDAwMCENClsg
IDE2Ny4xNjEyNjRdIDMxNmM2IGlzIDI2OWJlMDAwIQ0KWyAgMTY3LjE2MjkzMl0gMzE2YzUg
aXMgMjY5YmYwMDAhDQpbICAxNjcuMTY0NjE5XSAzMTZjNCBpcyAyNjljMDAwMCENClsgIDE2
Ny4xNjYzMTZdIDMxNmMzIGlzIDI2OWMxMDAwIQ0KWyAgMTY3LjE2Nzk5Nl0gMzE2YzIgaXMg
MjY5YzIwMDAhDQpbICAxNjcuMTY5NjgzXSAzMTZjMSBpcyAyNjljMzAwMCENClsgIDE2Ny4x
NzEzNThdIDMxNmMwIGlzIDI2OWM0MDAwIQ0KWyAgMTY3LjE3MzAyMF0gMzE2YmYgaXMgMjY5
YzUwMDAhDQpbICAxNjcuMTc0NzE5XSAzMTZiZSBpcyAyNjljNjAwMCENClsgIDE2Ny4xNzYz
NjldIDMxNmJkIGlzIDI2OWM3MDAwIQ0KWyAgMTY3LjE3OTA4OV0gMzE2ZTggaXMgMjY5OWQw
MDAhDQpbICAxNjcuMTgwODQ5XSAzMTZlOSBpcyAyNjk5ZTAwMCENClsgIDE2Ny4xODI1MzZd
IDMxNmVhIGlzIDI2OTlmMDAwIQ0KWyAgMTY3LjE4NDIyMF0gMzE2ZWIgaXMgMjY5YTAwMDAh
DQpbICAxNjcuMTg1ODg2XSAzMTZlYyBpcyAyNjlhMTAwMCENClsgIDE2Ny4xODc1OTJdIDMx
NmVkIGlzIDI2OWEyMDAwIQ0KWyAgMTY3LjE4OTI3MF0gMzE2ZWUgaXMgMjY5YTMwMDAhDQpb
ICAxNjcuMTkwOTY1XSAzMTZlZiBpcyAyNjlhNDAwMCENClsgIDE2Ny4xOTI2MzBdIDMxNmYw
IGlzIDI2OWE1MDAwIQ0KWyAgMTY3LjE5NDMxOF0gMzE2ZjEgaXMgMjY5YTYwMDAhDQpbICAx
NjcuMTk1OTg2XSAzMTZmMiBpcyAyNjlhNzAwMCENClsgIDE2Ny4xOTc2NjNdIDMxNmYzIGlz
IDI2OTkzMDAwIQ0KWyAgMTY3LjE5OTM0OV0gMzE2ZjYgaXMgMjY5OTQwMDAhDQpbICAxNjcu
MjAxMDM4XSAzMTZmNyBpcyAyNjk5NTAwMCENClsgIDE2Ny4yMDI3MzRdIDMxNmY4IGlzIDI2
OTk2MDAwIQ0KWyAgMTY3LjIwNDQyOF0gMzE2ZjkgaXMgMjY5OTcwMDAhDQpbICAxNjcuMjA2
MDk4XSAzMTZmYSBpcyAyNjk5ODAwMCENClsgIDE2Ny4yMDc3OTZdIDMxNmZiIGlzIDI2OTk5
MDAwIQ0KWyAgMTY3LjIwOTQ1N10gMzE2ZmMgaXMgMjY5OWEwMDAhDQpbICAxNjcuMjExMTM2
XSAzMTZmZCBpcyAyNjk5YjAwMCENClsgIDE2Ny4yMTI3OTddIDMxNmZlIGlzIDI2OTljMDAw
IQ0KWyAgMTY3LjIxNDQ2MV0gMzE2ZTcgaXMgMjY5ODgwMDAhDQpbICAxNjcuMjE2MTM4XSAz
MTZlNiBpcyAyNjk4OTAwMCENClsgIDE2Ny4yMTc4MTNdIDMxNmU1IGlzIDI2OThhMDAwIQ0K
WyAgMTY3LjIxOTQ4M10gMzE2ZTQgaXMgMjY5OGIwMDAhDQpbICAxNjcuMjIxMTU0XSAzMTZl
MyBpcyAyNjk4YzAwMCENClsgIDE2Ny4yMjI4MjFdIDMxNmUyIGlzIDI2OThkMDAwIQ0KWyAg
MTY3LjIyNDUxOF0gMzE2ZTEgaXMgMjY5OGUwMDAhDQpbICAxNjcuMjI2MTc5XSAzMTZlMCBp
cyAyNjk4ZjAwMCENClsgIDE2Ny4yMjc4NjJdIDMxNmRmIGlzIDI2OTkwMDAwIQ0KWyAgMTY3
LjIyOTUzMF0gMzE2ZGUgaXMgMjY5OTEwMDAhDQpbICAxNjcuMjMxMjE4XSAzMTZkZCBpcyAy
Njk5MjAwMCENClsgIDE2Ny4yMzM4MzRdIDMxNmQxIGlzIDI3MTY4MDAwIQ0KWyAgMTY3LjIz
NTU2M10gMzE2ZDAgaXMgMjcxNjkwMDAhDQpbICAxNjcuMjM3MzExXSAzMTZjZiBpcyAyNzE2
YTAwMCENClsgIDE2Ny4yMzkwMTNdIDMxNmNlIGlzIDI3MTZiMDAwIQ0KWyAgMTY3LjI0MDc2
NF0gMzE2Y2QgaXMgMjcxNmMwMDAhDQpbICAxNjcuMjQyNDY2XSAzMTZjYyBpcyAyNzE2ZDAw
MCENClsgIDE2Ny4yNDQxNzddIDMxNmNiIGlzIDI3MTZlMDAwIQ0KWyAgMTY3LjI0NTg5M10g
MzE2Y2EgaXMgMjcxNmYwMDAhDQpbICAxNjcuMjQ3NTk2XSAzMTZjOSBpcyAyNzE3MDAwMCEN
ClsgIDE2Ny4yNDkzMTddIDMxNmM4IGlzIDI3MTcxMDAwIQ0KWyAgMTY3LjI1MTAxNl0gMzE2
ZmYgaXMgMjcxNzIwMDAhDQpbICAxNjcuMjUyNzE3XSAzMTZkMiBpcyAyNzE3MzAwMCENClsg
IDE2Ny4yNTQ0MTJdIDMxNmQzIGlzIDI3MTc0MDAwIQ0KWyAgMTY3LjI1NjA3Ml0gMzE2ZDQg
aXMgMjcxNzUwMDAhDQpbICAxNjcuMjU3Nzc0XSAzMTcxNSBpcyAyNzE3NjAwMCENClsgIDE2
Ny4yNTk0MzhdIDMxNzE2IGlzIDI3MTc3MDAwIQ0KWyAgMTY3LjI2MTE1MV0gMzE3MTcgaXMg
MjcxNzgwMDAhDQpbICAxNjcuMjYyODMyXSAzMTcxOCBpcyAyNzE3OTAwMCENClsgIDE2Ny4y
NjQ1MzRdIDMxNzE5IGlzIDI3MTdhMDAwIQ0KWyAgMTY3LjI2NjIzMF0gMzE3MWEgaXMgMjcx
N2IwMDAhDQpbICAxNjcuMjY3OTEyXSAzMTcxYiBpcyAyNzE3YzAwMCENClsgIDE2Ny4yNzA0
NzhdIDMxNzBhIGlzIDI3MTUzMDAwIQ0KWyAgMTY3LjI3MjI5N10gMzE3MGIgaXMgMjcxNTQw
MDAhDQpbICAxNjcuMjc0MDQ0XSAzMTcwYyBpcyAyNzE1NTAwMCENClsgIDE2Ny4yNzU3Mjld
IDMxNzBkIGlzIDI3MTU2MDAwIQ0KWyAgMTY3LjI3NzQzOF0gMzE3MGUgaXMgMjcxNTcwMDAh
DQpbICAxNjcuMjc5MTMzXSAzMTcwZiBpcyAyNzE1ODAwMCENClsgIDE2Ny4yODA4MThdIDMx
NzEwIGlzIDI3MTU5MDAwIQ0KWyAgMTY3LjI4MjUyN10gMzE3MTEgaXMgMjcxNWEwMDAhDQpb
ICAxNjcuMjg0MjIwXSAzMTcxMiBpcyAyNzE1YjAwMCENClsgIDE2Ny4yODU5MTBdIDMxNzEz
IGlzIDI3MTVjMDAwIQ0KWyAgMTY3LjI4NzU5M10gMzE3MDkgaXMgMjcxNDgwMDAhDQpbICAx
NjcuMjg5MjU5XSAzMTcwOCBpcyAyNzE0OTAwMCENClsgIDE2Ny4yOTA5MjhdIDMxNzA3IGlz
IDI3MTRhMDAwIQ0KWyAgMTY3LjI5MjU2Nl0gMzE3MDYgaXMgMjcxNGIwMDAhDQpbICAxNjcu
Mjk0MjM4XSAzMTcwNSBpcyAyNzE0YzAwMCENClsgIDE2Ny4yOTU4NzZdIDMxNzA0IGlzIDI3
MTRkMDAwIQ0KWyAgMTY3LjI5NzUzM10gMzE3MDMgaXMgMjcxNGUwMDAhDQpbICAxNjcuMjk5
MTkzXSAzMTcwMiBpcyAyNzE0ZjAwMCENClsgIDE2Ny4zMDA4NDddIDMxNzAxIGlzIDI3MTUw
MDAwIQ0KWyAgMTY3LjMwMjUwMl0gMzE3MDAgaXMgMjcxNTEwMDAhDQpbICAxNjcuMzA0MTg2
XSAzMTcxYyBpcyAyNzE1MjAwMCENClsgIDE2Ny4zMDc1NjddIDMxNzM0IGlzIDI3MTEzMDAw
IQ0KWyAgMTY3LjMwOTI5NF0gMzE3MzUgaXMgMjcxMTQwMDAhDQpbICAxNjcuMzExMDQxXSAz
MTczNiBpcyAyNzExNTAwMCENClsgIDE2Ny4zMTI3MzhdIDMxNzM3IGlzIDI3MTE2MDAwIQ0K
WyAgMTY3LjMxNDQ0NF0gMzE3MzggaXMgMjcxMTcwMDAhDQpbICAxNjcuMzE2MTYyXSAzMTcz
OSBpcyAyNzExODAwMCENClsgIDE2Ny4zMTc4NjVdIDMxNzNhIGlzIDI3MTE5MDAwIQ0KWyAg
MTY3LjMxOTU2MV0gMzE3M2IgaXMgMjcxMWEwMDAhDQpbICAxNjcuMzIxMjU3XSAzMTczYyBp
cyAyNzExYjAwMCENClsgIDE2Ny4zMjI5NDhdIDMxNzNkIGlzIDI3MTFjMDAwIQ0KWyAgMTY3
LjMyNDY3Nl0gMzE3MjYgaXMgMjcxMjgwMDAhDQpbICAxNjcuMzI2MzYwXSAzMTcyNSBpcyAy
NzEyOTAwMCENClsgIDE2Ny4zMjgwODddIDMxNzI0IGlzIDI3MTJhMDAwIQ0KWyAgMTY3LjMy
OTc4OF0gMzE3MjMgaXMgMjcxMmIwMDAhDQpbICAxNjcuMzMxNDY3XSAzMTcyMiBpcyAyNzEy
YzAwMCENClsgIDE2Ny4zMzMxNjVdIDMxNzIxIGlzIDI3MTJkMDAwIQ0KWyAgMTY3LjMzNDg1
Ml0gMzE3MjAgaXMgMjcxMmUwMDAhDQpbICAxNjcuMzM2NTM5XSAzMTcxZiBpcyAyNzEyZjAw
MCENClsgIDE2Ny4zMzgyMjFdIDMxNzFlIGlzIDI3MTMwMDAwIQ0KWyAgMTY3LjMzOTg5OV0g
MzE3MWQgaXMgMjcxMzEwMDAhDQpbICAxNjcuMzQxNjIyXSAzMTcxNCBpcyAyNzEzMjAwMCEN
ClsgIDE2Ny4zNDMzMDFdIDMxNzMxIGlzIDI3MTFkMDAwIQ0KWyAgMTY3LjM0NTAzMF0gMzE3
MzAgaXMgMjcxMWUwMDAhDQpbICAxNjcuMzQ2NzM2XSAzMTcyZiBpcyAyNzExZjAwMCENClsg
IDE2Ny4zNDg0NDZdIDMxNzJlIGlzIDI3MTIwMDAwIQ0KWyAgMTY3LjM1MDE0NV0gMzE3MmQg
aXMgMjcxMjEwMDAhDQpbICAxNjcuMzUxODM5XSAzMTcyYyBpcyAyNzEyMjAwMCENClsgIDE2
Ny4zNTM1NjNdIDMxNzJiIGlzIDI3MTIzMDAwIQ0KWyAgMTY3LjM1NTI1M10gMzE3MmEgaXMg
MjcxMjQwMDAhDQpbICAxNjcuMzU2OTU4XSAzMTcyOSBpcyAyNzEyNTAwMCENClsgIDE2Ny4z
NTg2MTldIDMxNzI4IGlzIDI3MTI2MDAwIQ0KWyAgMTY3LjM2MDI4OF0gMzE3MjcgaXMgMjcx
MjcwMDAhDQpbICAxNjcuMzYzMDU4XSAzMTc0OCBpcyAyNzBlODAwMCENClsgIDE2Ny4zNjQ4
NDBdIDMxNzQ3IGlzIDI3MGU5MDAwIQ0KWyAgMTY3LjM2NjUyNV0gMzE3NDYgaXMgMjcwZWEw
MDAhDQpbICAxNjcuMzY4MjE5XSAzMTc0NSBpcyAyNzBlYjAwMCENClsgIDE2Ny4zNjk5MjJd
IDMxNzQ0IGlzIDI3MGVjMDAwIQ0KWyAgMTY3LjM3MTYwMl0gMzE3NDMgaXMgMjcwZWQwMDAh
DQpbICAxNjcuMzczMjg5XSAzMTc0MiBpcyAyNzBlZTAwMCENClsgIDE2Ny4zNzQ5OTVdIDMx
NzQxIGlzIDI3MGVmMDAwIQ0KWyAgMTY3LjM3NjY2OF0gMzE3NDAgaXMgMjcwZjAwMDAhDQpb
ICAxNjcuMzc4MzkwXSAzMTczZiBpcyAyNzBmMTAwMCENClsgIDE2Ny4zODAwODJdIDMxNzNl
IGlzIDI3MGYyMDAwIQ0KWyAgMTY3LjM4MTc4NV0gMzE3NDkgaXMgMjcwZmQwMDAhDQpbICAx
NjcuMzgzNDcyXSAzMTc0YSBpcyAyNzBmZTAwMCENClsgIDE2Ny4zODUxNTZdIDMxNzRiIGlz
IDI3MGZmMDAwIQ0KWyAgMTY3LjM4Njg3N10gMzE3NGMgaXMgMjcxMDAwMDAhDQpbICAxNjcu
Mzg4NTY0XSAzMTc0ZCBpcyAyNzEwMTAwMCENClsgIDE2Ny4zOTAyOTVdIDMxNzRlIGlzIDI3
MTAyMDAwIQ0KWyAgMTY3LjM5MTk4MV0gMzE3NGYgaXMgMjcxMDMwMDAhDQpbICAxNjcuMzkz
NjczXSAzMTc1MCBpcyAyNzEwNDAwMCENClsgIDE2Ny4zOTUzNzRdIDMxNzUxIGlzIDI3MTA1
MDAwIQ0KWyAgMTY3LjM5NzA2MF0gMzE3NTIgaXMgMjcxMDYwMDAhDQpbICAxNjcuMzk4NzM3
XSAzMTc1MyBpcyAyNzEwNzAwMCENClsgIDE2Ny40MDA0MTJdIDMxNzU0IGlzIDI3MGYzMDAw
IQ0KWyAgMTY3LjQwMjA5Nl0gMzE3NTUgaXMgMjcwZjQwMDAhDQpbICAxNjcuNDAzODEwXSAz
MTc1NiBpcyAyNzBmNTAwMCENClsgIDE2Ny40MDU0OTRdIDMxNzU3IGlzIDI3MGY2MDAwIQ0K
WyAgMTY3LjQwNzIwOF0gMzE3NTggaXMgMjcwZjcwMDAhDQpbICAxNjcuNDA4ODkzXSAzMTc1
OSBpcyAyNzBmODAwMCENClsgIDE2Ny40MTA1OTZdIDMxNzVhIGlzIDI3MGY5MDAwIQ0KWyAg
MTY3LjQxMjMwOV0gMzE3NWIgaXMgMjcwZmEwMDAhDQpbICAxNjcuNDE0MDE4XSAzMTc1YyBp
cyAyNzBmYjAwMCENClsgIDE2Ny40MTU3MjNdIDMxNzVkIGlzIDI3MGZjMDAwIQ0KWyAgMTY3
LjQxNzQxNV0gMzE3NWUgaXMgMjcwZGQwMDAhDQpbICAxNjcuNDE5MTEzXSAzMTczMiBpcyAy
NzBkZTAwMCENClsgIDE2Ny40MjA4MTJdIDMxNzMzIGlzIDI3MGRmMDAwIQ0KWyAgMTY3LjQy
MjQ5Nl0gMzE3NzQgaXMgMjcwZTAwMDAhDQpbICAxNjcuNDI0MjIyXSAzMTc3NSBpcyAyNzBl
MTAwMCENClsgIDE2Ny40MjU5MThdIDMxNzc2IGlzIDI3MGUyMDAwIQ0KWyAgMTY3LjQyNzY0
MV0gMzE3NzcgaXMgMjcwZTMwMDAhDQpbICAxNjcuNDI5MzM3XSAzMTc3OCBpcyAyNzBlNDAw
MCENClsgIDE2Ny40MzEwNDJdIDMxNzc5IGlzIDI3MGU1MDAwIQ0KWyAgMTY3LjQzMjc0OF0g
MzE3N2EgaXMgMjcwZTYwMDAhDQpbICAxNjcuNDM0NDM4XSAzMTc3YiBpcyAyNzBlNzAwMCEN
ClsgIDE2Ny40MzYxMjddIDMxNzdjIGlzIDI3MGQzMDAwIQ0KWyAgMTY3LjQzNzgxOV0gMzE3
N2QgaXMgMjcwZDQwMDAhDQpbICAxNjcuNDM5NDk3XSAzMTc3ZSBpcyAyNzBkNTAwMCENClsg
IDE2Ny40NDExOTRdIDMxNzdmIGlzIDI3MGQ2MDAwIQ0KWyAgMTY3LjQ0Mjg2MV0gMzE3ODAg
aXMgMjcwZDcwMDAhDQpbICAxNjcuNDQ0NTU3XSAzMTc4MSBpcyAyNzBkODAwMCENClsgIDE2
Ny40NDYyMjRdIDMxNzgyIGlzIDI3MGQ5MDAwIQ0KWyAgMTY3LjQ0Nzg5OF0gMzE3ODMgaXMg
MjcwZGEwMDAhDQpbICAxNjcuNDQ5NTgyXSAzMTc4NCBpcyAyNzBkYjAwMCENClsgIDE2Ny40
NTEyNjNdIDMxNzg1IGlzIDI3MGRjMDAwIQ0KWyAgMTY3LjQ1NjE4M10gMzE3NWYgaXMgMjcw
YzgwMDAhDQpbICAxNjcuNDU4MDAzXSAzMTc2MCBpcyAyNzBjOTAwMCENClsgIDE2Ny40NTk2
NTldIDMxNzYxIGlzIDI3MGNhMDAwIQ0KWyAgMTY3LjQ2MTM0OV0gMzE3NjIgaXMgMjcwY2Iw
MDAhDQpbICAxNjcuNDYzMDA1XSAzMTc2MyBpcyAyNzBjYzAwMCENClsgIDE2Ny40NjQ2Nzhd
IDMxNzY0IGlzIDI3MGNkMDAwIQ0KWyAgMTY3LjQ2NjM1MF0gMzE3NjUgaXMgMjcwY2UwMDAh
DQpbICAxNjcuNDY4MDE5XSAzMTc2NiBpcyAyNzBjZjAwMCENClsgIDE2Ny40Njk2OTJdIDMx
NzY3IGlzIDI3MGQwMDAwIQ0KWyAgMTY3LjQ3MTM2N10gMzE3NjggaXMgMjcwZDEwMDAhDQpb
ICAxNjcuNDczMDM0XSAzMTc2OSBpcyAyNzBkMjAwMCENClsgIDE2Ny40NzQ3MjZdIDMxNzZh
IGlzIDI3MGJkMDAwIQ0KWyAgMTY3LjQ3NjM5M10gMzE3NmIgaXMgMjcwYmUwMDAhDQpbICAx
NjcuNDc4MDkxXSAzMTc2YyBpcyAyNzBiZjAwMCENClsgIDE2Ny40Nzk3NDBdIDMxNzZkIGlz
IDI3MGMwMDAwIQ0KWyAgMTY3LjQ4MTQyNV0gMzE3NmUgaXMgMjcwYzEwMDAhDQpbICAxNjcu
NDgzMDg2XSAzMTc2ZiBpcyAyNzBjMjAwMCENClsgIDE2Ny40ODQ3NjFdIDMxNzcwIGlzIDI3
MGMzMDAwIQ0KWyAgMTY3LjQ4NjQ0Nl0gMzE3NzEgaXMgMjcwYzQwMDAhDQpbICAxNjcuNDg4
MTIxXSAzMTc5MyBpcyAyNzBjNTAwMCENClsgIDE2Ny40ODk4MDldIDMxNzk0IGlzIDI3MGM2
MDAwIQ0KWyAgMTY3LjQ5MTUwMV0gMzE3OTUgaXMgMjcwYzcwMDAhDQpbICAxNjcuNDkzMTc0
XSAzMTc5NiBpcyAyNzBiMzAwMCENClsgIDE2Ny40OTQ4ODNdIDMxNzk3IGlzIDI3MGI0MDAw
IQ0KWyAgMTY3LjQ5NjU2MV0gMzE3OTggaXMgMjcwYjUwMDAhDQpbICAxNjcuNDk4MjY4XSAz
MTc5OSBpcyAyNzBiNjAwMCENClsgIDE2Ny40OTk5MzVdIDMxNzlhIGlzIDI3MGI3MDAwIQ0K
WyAgMTY3LjUwMTYxN10gMzE3OWIgaXMgMjcwYjgwMDAhDQpbICAxNjcuNTAzMzEyXSAzMTc5
YyBpcyAyNzBiOTAwMCENClsgIDE2Ny41MDQ5OTldIDMxNzlkIGlzIDI3MGJhMDAwIQ0KWyAg
MTY3LjUwNjY4Nl0gMzE3OWUgaXMgMjcwYmIwMDAhDQpbICAxNjcuNTA4MzY3XSAzMTc5ZiBp
cyAyNzBiYzAwMCENClsgIDE2Ny41MTAxNjldIDMxN2EwIGlzIDI3MGFiMDAwIQ0KWyAgMTY3
LjUxMTg5N10gMzE3YTEgaXMgMjcwYWMwMDAhDQpbICAxNjcuNTEzNjA0XSAzMTdhMiBpcyAy
NzBhZDAwMCENClsgIDE2Ny41MTUzMTZdIDMxN2EzIGlzIDI3MGFlMDAwIQ0KWyAgMTY3LjUx
NzAxMF0gMzE3YTQgaXMgMjcwYWYwMDAhDQpbICAxNjcuNTE4Njg5XSAzMTdhNSBpcyAyNzBi
MDAwMCENClsgIDE2Ny41MjA0MTddIDMxN2E2IGlzIDI3MGIxMDAwIQ0KWyAgMTY3LjUyMjEx
N10gMzE3YTcgaXMgMjcwYjIwMDAhDQpbICAxNjcuNTI0Nzk3XSAzMTdiNCBpcyAyNzA5YjAw
MCENClsgIDE2Ny41MjY0NzJdIDMxN2I1WyAgMTY5LjY2MTkyMF0gMzBjM2EgaXMgMjcyM2Yw
MDAhDQpbICAxNjkuNjYzNjYxXSAzMGM2YSBpcyAyNzI0MDAwMCENClsgIDE2OS42NjU0MTVd
IDMwYzZiIGlzIDI3MjQxMDAwIQ0KWyAgMTY5LjY2NzE4NF0gMzBjNmMgaXMgMjcyNDIwMDAh
DQpbICAxNjkuNjY4ODc0XSAzMGM2ZCBpcyAyNzI0MzAwMCENClsgIDE2OS42NzA1ODVdIDMw
YzZlIGlzIDI3MjQ0MDAwIQ0KWyAgMTY5LjY3MjI0M10gMzBjNmYgaXMgMjcyNDUwMDAhDQpb
ICAxNjkuNjczOTg2XSAzMGM3MCBpcyAyNzI0NjAwMCENClsgIDE2OS42NzU2NThdIDMwYzcx
IGlzIDI3MjQ3MDAwIQ0KWyAgMTY5LjY3NzM0OV0gMzBjNzIgaXMgMjcyNDgwMDAhDQpbICAx
NjkuNjc5MDQ0XSAzMGM3MyBpcyAyNzI0OTAwMCENClsgIDE2OS42ODEwOThdIDMwYzdlIGlz
IDI3MjJhMDAwIQ0KWyAgMTY5LjY4Mjc5Ml0gMzBjMzAgaXMgMjcyMmIwMDAhDQpbICAxNjku
Njg0NDcwXSAzMGMzMSBpcyAyNzIyYzAwMCENClsgIDE2OS42ODYxMTldIDMwYzMyIGlzIDI3
MjJkMDAwIQ0KWyAgMTY5LjY4NzgxMF0gMzBjMzMgaXMgMjcyMmUwMDAhDQpbICAxNjkuNjg5
NDU3XSAzMGMzNCBpcyAyNzIyZjAwMCENClsgIDE2OS42OTExMzBdIDMwYzM1IGlzIDI3MjMw
MDAwIQ0KWyAgMTY5LjY5Mjc3NV0gMzBjMzYgaXMgMjcyMzEwMDAhDQpbICAxNjkuNjk0NDMz
XSAzMGMzNyBpcyAyNzIzMjAwMCENClsgIDE2OS42OTYxMDldIDMwYzM4IGlzIDI3MjMzMDAw
IQ0KWyAgMTY5LjY5Nzc3M10gMzBjMzkgaXMgMjcyMzQwMDAhDQpbICAxNjkuNjk5NDUzXSAz
MGM3ZiBpcyAyNzIxZjAwMCENClsgIDE2OS43MDExMThdIDMwYzgwIGlzIDI3MjIwMDAwIQ0K
WyAgMTY5LjcwMjc5MF0gMzBjODEgaXMgMjcyMjEwMDAhDQpbICAxNjkuNzA0NTA4XSAzMGM4
MiBpcyAyNzIyMjAwMCENClsgIDE2OS43MDYxOTNdIDMwYzgzIGlzIDI3MjIzMDAwIQ0KWyAg
MTY5LjcwNzkxNl0gMzBjODQgaXMgMjcyMjQwMDAhDQpbICAxNjkuNzA5NTg5XSAzMGM4NSBp
cyAyNzIyNTAwMCENClsgIDE2OS43MTEzMDddIDMwYzg2IGlzIDI3MjI2MDAwIQ0KWyAgMTY5
LjcxMjk5MV0gMzBjODcgaXMgMjcyMjcwMDAhDQpbICAxNjkuNzE0Njk1XSAzMGM4OCBpcyAy
NzIyODAwMCENClsgIDE2OS43MTYzODhdIDMwYzg5IGlzIDI3MjI5MDAwIQ0KWyAgMTY5Ljcx
ODA2M10gMzBjOGEgaXMgMjcyMTQwMDAhDQpbICAxNjkuNzE5NzU2XSAzMGM3NCBpcyAyNzIz
NTAwMCENClsgIDE2OS43MjE0NDhdIDMwYzc1IGlzIDI3MjM2MDAwIQ0KWyAgMTY5LjcyMzEz
OV0gMzBjNzYgaXMgMjcyMzcwMDAhDQpbICAxNjkuNzI0ODYyXSAzMGM3NyBpcyAyNzIzODAw
MCENClsgIDE2OS43MjY1NDhdIDMwYzc4IGlzIDI3MjM5MDAwIQ0KWyAgMTY5LjcyODI2NV0g
MzBjNzkgaXMgMjcyM2EwMDAhDQpbICAxNjkuNzI5OTQ0XSAzMGM3YSBpcyAyNzIzYjAwMCEN
ClsgIDE2OS43MzE2MzddIDMwYzdiIGlzIDI3MjNjMDAwIQ0KWyAgMTY5LjczMzM1Ml0gMzBj
N2MgaXMgMjcyM2QwMDAhDQpbICAxNjkuNzM1MDUwXSAzMGM3ZCBpcyAyNzIzZTAwMCENClsg
IDE2OS43NTgyNzNdIDMwYzNjIGlzIDI3MjEzMDAwIQ0KWyAgMTY5Ljc4MzIwN10gMzBjM2Qg
aXMgMjcyMTIwMDAhDQpbICAxNjkuNzg1MzUxXSAzMGMzYiBpcyAyNzIxMTAwMCENClsgIDE2
OS43ODc1MDRdIDMwYzk0IGlzIDI3MjEwMDAwIQ0KWyAgMTY5LjgyMzc4NF0gMzBjOTUgaXMg
MjcyMGYwMDAhDQpbICAxNjkuODI1OTM5XSAzMGM5NiBpcyAyNzIwZTAwMCENClsgIDE2OS44
MjgxMjldIDMwYzk3IGlzIDI3MjBkMDAwIQ0KWyAgMTY5LjgzMjE2NF0gMzBjOTggaXMgMjcy
MGMwMDAhDQpbICAxNjkuODM0MzAzXSAzMGM5OSBpcyAyNzIwYjAwMCENClsgIDE2OS44NDU3
MzVdIDMwYzlhIGlzIDI3MjBhMDAwIQ0KWyAgMTY5Ljg2NjQ3MV0gMzBjOWIgaXMgMjcyMDkw
MDAhDQpbICAxNjkuODgxMTk1XSAzNzUyMCBpcyAyNzIwODAwMCENClsgIDE2OS44ODcxNzhd
IDM4MmRlIGlzIDI3MjA3MDAwIQ0KWyAgMTY5Ljg4OTMyOF0gMzBjOWMgaXMgMjcyMDYwMDAh
DQpbICAxNjkuODkxNTEyXSAzMGM5ZCBpcyAyNzIwNTAwMCENClsgIDE2OS45MzUyNTVdIDMw
YzllIGlzIDI3MjA0MDAwIQ0KWyAgMTY5LjkzODU3OF0gMzBjOWYgaXMgMjcxZTAwMDAhDQpb
ICAxNjkuOTQwODg2XSAzNjRmZSBpcyAyNzFlMTAwMCENClsgIDE2OS45NDQ3MDldIDMwY2Fj
IGlzIDI3MWQ5MDAwIQ0KWyAgMTY5Ljk0NjUzNV0gMzBjYWQgaXMgMjcxZGEwMDAhDQpbICAx
NjkuOTQ4MzkwXSAzMGNhZSBpcyAyNzFkYjAwMCENClsgIDE2OS45NTAyMTZdIDMwY2FmIGlz
IDI3MWRjMDAwIQ0KWyAgMTY5Ljk1MjAxM10gMzBjYjAgaXMgMjcxZGYwMDAhDQpbICAxNjku
OTUzODQwXSAzMGNiMSBpcyAyNzQyNTAwMCENClsgIDE2OS45NTU2NDJdIDMwY2IyIGlzIDI3
NDNlMDAwIQ0KWyAgMTY5Ljk1NzQ4MF0gMzBjYjMgaXMgMjcxZmUwMDAhDQpbICAxNjkuOTU5
Mjg4XSAzMGNiNCBpcyAyNzFlNjAwMCENClsgIDE2OS45NjExMzFdIDMwY2I1IGlzIDI3MWU1
MDAwIQ0KWyAgMTY5Ljk2Mjk0NF0gMzBjYjYgaXMgMjcxZmQwMDAhDQpbICAxNjkuOTY0Nzc3
XSAzMGNhMCBpcyAyNzFmMTAwMCENClsgIDE2OS45NjY2MTNdIDM3YTBmIGlzIDI3MWYzMDAw
IQ0KWyAgMTY5Ljk2ODQ3M10gMzBjM2UgaXMgMjcxZjQwMDAhDQpbICAxNjkuOTcwMzQ2XSAz
MGNiZCBpcyAyNzFmNTAwMCENClsgIDE2OS45NzIxOTFdIDMwY2JlIGlzIDI3MWZiMDAwIQ0K
WyAgMTY5Ljk3NDA2OF0gMzBjYmYgaXMgMjcxZmEwMDAhDQpbICAxNjkuOTc1OTA3XSAzMGNj
MCBpcyAyNzFmODAwMCENClsgIDE2OS45Nzc3NzJdIDMwY2MxIGlzIDI3MWY5MDAwIQ0KWyAg
MTY5Ljk3OTYwNV0gMzBjYzIgaXMgMjcxZWEwMDAhDQpbICAxNjkuOTgxNDY0XSAzMGNjMyBp
cyAyNzFlMzAwMCENClsgIDE2OS45ODMzMzFdIDMwY2M0IGlzIDI3MWUyMDAwIQ0KWyAgMTY5
Ljk4NTE5N10gMzBjYTEgaXMgMjcxZWMwMDAhDQpbICAxNjkuOTg3MDc5XSAzMGNhMiBpcyAy
NzFlYjAwMCENClsgIDE2OS45ODg5MjZdIDMwY2EzIGlzIDI3MWY3MDAwIQ0KWyAgMTY5Ljk5
MDc4NF0gMzBjYTQgaXMgMjcxZjYwMDAhDQpbICAxNjkuOTkyNjA2XSAzMGNhNSBpcyAyNzFl
ZjAwMCENClsgIDE2OS45OTQ0NTNdIDMwY2E2IGlzIDI3MWU5MDAwIQ0KWyAgMTY5Ljk5NjI2
NF0gMzBjYTcgaXMgMjcxZTQwMDAhDQpbICAxNjkuOTk4MDc3XSAzMGNhOCBpcyAyNzFmYzAw
MCENClsgIDE2OS45OTk4ODZdIDMwY2E5IGlzIDI3MWYwMDAwIQ0KWyAgMTcwLjAwMTY3MF0g
MzBjYWEgaXMgMjcxZWQwMDAhDQpbICAxNzAuMDAzNDc4XSAzMGNhYiBpcyAyNzFlZTAwMCEN
ClsgIDE3MC4wMDYxMzNdIDMwY2UxIGlzIDI3MWNhMDAwIQ0KWyAgMTcwLjAwODA4NF0gMzBj
ZTIgaXMgMjcxY2IwMDAhDQpbICAxNzAuMDA5ODkzXSAzMGNlMyBpcyAyNzFjYzAwMCENClsg
IDE3MC4wMTE3MjldIDMwY2U0IGlzIDI3MWNkMDAwIQ0KWyAgMTcwLjAxMzUzNl0gMzBjZTAg
aXMgMjZjODkwMDAhDQpbICAxNzAuMDE1MzYyXSAzMGNkZiBpcyAyNzQzMTAwMCENClsgIDE3
MC4wMTcxOTBdIDMwY2RlIGlzIDI3MjAxMDAwIQ0KWyAgMTcwLjAxOTAzOV0gMzBjZGQgaXMg
MjcyMDMwMDAhDQpbICAxNzAuMDIwODY2XSAzMGNkYyBpcyAyNzIwMjAwMCENClsgIDE3MC4w
MjI2ODNdIDMwY2JjIGlzIDI3NDMyMDAwIQ0KWyAgMTcwLjAyNDU0M10gMzBjYmIgaXMgMjcx
YzUwMDAhDQpbICAxNzAuMDI2MzQ5XSAzMGNiYSBpcyAyNzFjNjAwMCENClsgIDE3MC4wMjgx
NzJdIDMwY2I5IGlzIDI3MWM3MDAwIQ0KWyAgMTcwLjAyOTk2NV0gMzBjYjggaXMgMjcxYzgw
MDAhDQpbICAxNzAuMDMxNzY4XSAzMGNiNyBpcyAyNzFjOTAwMCENClsgIDE3MC4wMzUwOThd
IDMwY2NlIGlzIDI3MWE3MDAwIQ0KWyAgMTcwLjAzNjkzOF0gMzBjY2QgaXMgMjcxYTgwMDAh
DQpbICAxNzAuMDM4NzA4XSAzMGNjYyBpcyAyNzFhOTAwMCENClsgIDE3MC4wNDA1MDVdIDMw
Y2NiIGlzIDI3MWFhMDAwIQ0KWyAgMTcwLjA0MjI1OF0gMzBjY2EgaXMgMjcxYWIwMDAhDQpb
ICAxNzAuMDQ0MDM4XSAzMGNjOSBpcyAyNzFhYzAwMCENClsgIDE3MC4wNDU4MDldIDMwY2M4
IGlzIDI3MWFkMDAwIQ0KWyAgMTcwLjA0NzU4OV0gMzBjYzcgaXMgMjcxYWUwMDAhDQpbICAx
NzAuMDQ5MzU1XSAzMGNjNiBpcyAyNzFhZjAwMCENClsgIDE3MC4wNTEwOTBdIDMwY2M1IGlz
IDI3MWIwMDAwIQ0KWyAgMTcwLjA1MjgyOF0gMzBjZTUgaXMgMjcxYjEwMDAhDQpbICAxNzAu
MDU0NTc1XSAzMGNkOSBpcyAyNzE5YzAwMCENClsgIDE3MC4wNTYzMDldIDMwY2Q4IGlzIDI3
MTlkMDAwIQ0KWyAgMTcwLjA1ODA3Ml0gMzBjZDcgaXMgMjcxOWUwMDAhDQpbICAxNzAuMDU5
Nzk5XSAzMGNkNiBpcyAyNzE5ZjAwMCENClsgIDE3MC4wNjE1MzNdIDMwY2Q1IGlzIDI3MWEw
MDAwIQ0KWyAgMTcwLjA2MzI0OF0gMzBjZDQgaXMgMjcxYTEwMDAhDQpbICAxNzAuMDY0OTg4
XSAzMGNkMyBpcyAyNzFhMjAwMCENClsgIDE3MC4wNjY2ODZdIDMwY2QyIGlzIDI3MWEzMDAw
IQ0KWyAgMTcwLjA2ODM5OF0gMzBjZDEgaXMgMjcxYTQwMDAhDQpbICAxNzAuMDcwMTIyXSAz
MGNkMCBpcyAyNzFhNTAwMCENClsgIDE3MC4wNzE3OTRdIDMwY2NmIGlzIDI3MWE2MDAwIQ0K
WyAgMTcwLjA3NDM0Nl0gMzBjZTYgaXMgMjcxOTIwMDAhDQpbICAxNzAuMDc2MTQ1XSAzMGNl
NyBpcyAyNzE5MzAwMCENClsgIDE3MC4wNzc4NzhdIDMwY2U4IGlzIDI3MTk0MDAwIQ0KWyAg
MTcwLjA3OTU0Ml0gMzBjZTkgaXMgMjcxOTUwMDAhDQpbICAxNzAuMDgxMjEzXSAzMGNlYSBp
cyAyNzE5NjAwMCENClsgIDE3MC4wODI4OTZdIDMwY2ViIGlzIDI3MTk3MDAwIQ0KWyAgMTcw
LjA4NDU3N10gMzBjZWMgaXMgMjcxOTgwMDAhDQpbICAxNzAuMDg2MjY0XSAzMGNlZCBpcyAy
NzE5OTAwMCENClsgIDE3MC4wODc5MzZdIDMwY2VlIGlzIDI3MTlhMDAwIQ0KWyAgMTcwLjA4
OTYwOV0gMzBjZWYgaXMgMjcxOWIwMDAhDQpbICAxNzAuMDkyOTg5XSAzMGQwOCBpcyAyNzkz
MjAwMCENClsgIDE3MC4wOTQ3NDFdIDMwZDA5IGlzIDI3OTMzMDAwIQ0KWyAgMTcwLjA5NjQy
M10gMzBkMGEgaXMgMjc5MzQwMDAhDQpbICAxNzAuMDk4MTQwXSAzMGQwYiBpcyAyNzkzNTAw
MCENClsgIDE3MC4wOTk4MjFdIDMwZDBjIGlzIDI3OTM2MDAwIQ0KWyAgMTcwLjEwMTUzMl0g
MzBkMGQgaXMgMjc5MzcwMDAhDQpbICAxNzAuMTAzMjQ4XSAzMGQwZSBpcyAyNzkzODAwMCEN
ClsgIDE3MC4xMDQ5NzRdIDMwZDBmIGlzIDI3OTM5MDAwIQ0KWyAgMTcwLjEwNjY5NV0gMzBk
MTAgaXMgMjc5M2EwMDAhDQpbICAxNzAuMTA4NDEzXSAzMGQxMSBpcyAyNzkzYjAwMCENClsg
IDE3MC4xMTAxMzJdIDMwY2YwIGlzIDI3OTQ3MDAwIQ0KWyAgMTcwLjExMTg1NV0gMzBjZjEg
aXMgMjc5NDgwMDAhDQpbICAxNzAuMTEzNTc2XSAzMGNmMiBpcyAyNzk0OTAwMCENClsgIDE3
MC4xMTUzMDFdIDMwY2YzIGlzIDI3OTRhMDAwIQ0KWyAgMTcwLjExNzAyMl0gMzBjZjQgaXMg
Mjc5NGIwMDAhDQpbICAxNzAuMTE4NzE4XSAzMGNmNSBpcyAyNzk0YzAwMCENClsgIDE3MC4x
MjA0NDRdIDMwY2Y2IGlzIDI3OTRkMDAwIQ0KWyAgMTcwLjEyMjE1M10gMzBjZjcgaXMgMjc5
NGUwMDAhDQpbICAxNzAuMTIzODk2XSAzMGNmOCBpcyAyNzk0ZjAwMCENClsgIDE3MC4xMjU2
MTBdIDMwY2Y5IGlzIDI3OTUwMDAwIQ0KWyAgMTcwLjEyNzM1MV0gMzBjZmEgaXMgMjc5NTEw
MDAhDQpbICAxNzAuMTI5MDYwXSAzMGNmYiBpcyAyNzkzYzAwMCENClsgIDE3MC4xMzA3NzVd
IDMwY2ZlIGlzIDI3OTNkMDAwIQ0KWyAgMTcwLjEzMjUwNV0gMzBjZmYgaXMgMjc5M2UwMDAh
DQpbICAxNzAuMTM0MjI3XSAzMGQwMCBpcyAyNzkzZjAwMCENClsgIDE3MC4xMzU5NjFdIDMw
ZDAxIGlzIDI3OTQwMDAwIQ0KWyAgMTcwLjEzNzY5NV0gMzBkMDIgaXMgMjc5NDEwMDAhDQpb
ICAxNzAuMTM5NDEzXSAzMGQwMyBpcyAyNzk0MjAwMCENClsgIDE3MC4xNDExNjRdIDMwZDA0
IGlzIDI3OTQzMDAwIQ0KWyAgMTcwLjE0Mjg4OV0gMzBkMDUgaXMgMjc5NDQwMDAhDQpbICAx
NzAuMTQ0NjQ1XSAzMGQwNiBpcyAyNzk0NTAwMCENClsgIDE3MC4xNDYzNjldIDMwZDA3IGlz
IDI3OTQ2MDAwIQ0KWyAgMTcwLjE0OTMxMV0gMzBkMzIgaXMgMjc4ZmMwMDAhDQpbICAxNzAu
MTUxMTI4XSAzMGNkYSBpcyAyNzhmZDAwMCENClsgIDE3MC4xNTI5MTRdIDMwY2RiIGlzIDI3
OGZlMDAwIQ0KWyAgMTcwLjE1NDY3OV0gMzBkM2IgaXMgMjc4ZmYwMDAhDQpbICAxNzAuMTU2
NDUzXSAzMGQzYyBpcyAyNzkwMDAwMCENClsgIDE3MC4xNTgyMTZdIDMwZDNkIGlzIDI3OTAx
MDAwIQ0KWyAgMTcwLjE1OTk2NF0gMzBkM2UgaXMgMjc5MDIwMDAhDQpbICAxNzAuMTYxNzQ4
XSAzMGQzZiBpcyAyNzkwMzAwMCENClsgIDE3MC4xNjM1MTVdIDMwZDQwIGlzIDI3OTA0MDAw
IQ0KWyAgMTcwLjE2NTMwNF0gMzBkNDEgaXMgMjc5MDUwMDAhDQpbICAxNzAuMTY3MDQ0XSAz
MGQ0MiBpcyAyNzkwNjAwMCENClsgIDE3MC4xNjg4MTNdIDMwZDEyIGlzIDI3OTI3MDAwIQ0K
WyAgMTcwLjE3MDU0N10gMzBkMTMgaXMgMjc5MjgwMDAhDQpbICAxNzAuMTcyMjcxXSAzMGQx
NCBpcyAyNzkyOTAwMCENClsgIDE3MC4xNzQwMzRdIDMwZDE1IGlzIDI3OTJhMDAwIQ0KWyAg
MTcwLjE3NTc1OV0gMzBkMTYgaXMgMjc5MmIwMDAhDQpbICAxNzAuMTc3NTE3XSAzMGQxNyBp
cyAyNzkyYzAwMCENClsgIDE3MC4xNzkyMzddIDMwZDE4IGlzIDI3OTJkMDAwIQ0KWyAgMTcw
LjE4MDk2NF0gMzBkMTkgaXMgMjc5MmUwMDAhDQpbICAxNzAuMTgyNzAyXSAzMGQxYSBpcyAy
NzkyZjAwMCENClsgIDE3MC4xODQ0MjhdIDMwZDFiIGlzIDI3OTMwMDAwIQ0KWyAgMTcwLjE4
NjE2Nl0gMzBkMWMgaXMgMjc5MzEwMDAhDQpbICAxNzAuMTg3ODg3XSAzMGQyOCBpcyAyNzkx
MjAwMCENClsgIDE3MC4xODk2MzldIDMwZDI5IGlzIDI3OTEzMDAwIQ0KWyAgMTcwLjE5MTM2
NV0gMzBkMmEgaXMgMjc5MTQwMDAhDQpbICAxNzAuMTkzMDc4XSAzMGQyYiBpcyAyNzkxNTAw
MCENClsgIDE3MC4xOTQ4MjldIDMwZDJjIGlzIDI3OTE2MDAwIQ0KWyAgMTcwLjE5NjU0Ml0g
MzBkMmQgaXMgMjc5MTcwMDAhDQpbICAxNzAuMTk4Mjg4XSAzMGQyZSBpcyAyNzkxODAwMCEN
ClsgIDE3MC4xOTk5OTZdIDMwZDJmIGlzIDI3OTE5MDAwIQ0KWyAgMTcwLjIwMTcxN10gMzBk
MzAgaXMgMjc5MWEwMDAhDQpbICAxNzAuMjAzNDgwXSAzMGQzMSBpcyAyNzkxYjAwMCENClsg
IDE3MC4yMDUxOTRdIDMwZDI3IGlzIDI3OTA3MDAwIQ0KWyAgMTcwLjIwNjkzOF0gMzBkMjYg
aXMgMjc5MDgwMDAhDQpbICAxNzAuMjA4NjQ3XSAzMGQyNSBpcyAyNzkwOTAwMCENClsgIDE3
MC4yMTAzODddIDMwZDI0IGlzIDI3OTBhMDAwIQ0KWyAgMTcwLjIxMjA3N10gMzBkMjMgaXMg
Mjc5MGIwMDAhDQpbICAxNzAuMjEzNzc1XSAzMGQyMiBpcyAyNzkwYzAwMCENClsgIDE3MC4y
MTU0NzhdIDMwZDIxIGlzIDI3OTBkMDAwIQ0KWyAgMTcwLjIxNzE1OF0gMzBkMjAgaXMgMjc5
MGUwMDAhDQpbICAxNzAuMjE4ODM5XSAzMGQxZiBpcyAyNzkwZjAwMCENClsgIDE3MC4yMjA1
MTRdIDMwZDFlIGlzIDI3OTEwMDAwIQ0KWyAgMTcwLjIyMjE5Ml0gMzBkMWQgaXMgMjc5MTEw
MDAhDQpbICAxNzAuMjI1NDUzXSAzMGQ0ZCBpcyAyNzhlNzAwMCENClsgIDE3MC4yMjcyMDld
IDMwZDRjIGlzIDI3OGU4MDAwIQ0KWyAgMTcwLjIyODkyMV0gMzBkNGIgaXMgMjc4ZTkwMDAh
DQpbICAxNzAuMjMwNjQ2XSAzMGQ0YSBpcyAyNzhlYTAwMCENClsgIDE3MC4yMzIzNzddIDMw
ZDQ5IGlzIDI3OGViMDAwIQ0KWyAgMTcwLjIzNDA5MF0gMzBkNDggaXMgMjc4ZWMwMDAhDQpb
ICAxNzAuMjM1ODE5XSAzMGQ0NyBpcyAyNzhlZDAwMCENClsgIDE3MC4yMzc1MzBdIDMwZDQ2
IGlzIDI3OGVlMDAwIQ0KWyAgMTcwLjIzOTIyNl0gMzBkNDUgaXMgMjc4ZWYwMDAhDQpbICAx
NzAuMjQwOTYwXSAzMGQ0NCBpcyAyNzhmMDAwMCENClsgIDE3MC4yNDI2NjJdIDMwZDQzIGlz
IDI3OGYxMDAwIQ0KWyAgMTcwLjI0NDM4Ml0gMzBkMzMgaXMgMjc4ZGMwMDAhDQpbICAxNzAu
MjQ2MDY4XSAzMGQzNCBpcyAyNzhkZDAwMCENClsgIDE3MC4yNDc3NTZdIDMwZDM1IGlzIDI3
OGRlMDAwIQ0KWyAgMTcwLjI0OTQ2NV0gMzBkMzYgaXMgMjc4ZGYwMDAhDQpbICAxNzAuMjUx
MTQ2XSAzMGQzNyBpcyAyNzhlMDAwMCENClsgIDE3MC4yNTI4NDFdIDMwZDM4IGlzIDI3OGUx
MDAwIQ0KWyAgMTcwLjI1NDUyOV0gMzBkMzkgaXMgMjc4ZTIwMDAhDQpbICAxNzAuMjU2MjE3
XSAzMGQzYSBpcyAyNzhlMzAwMCENClsgIDE3MC4yNTc4ODddIDMwZDVhIGlzIDI3OGU0MDAw
IQ0KWyAgMTcwLjI1OTUzNl0gMzBkNWIgaXMgMjc4ZTUwMDAhDQpbICAxNzAuMjYxMjA1XSAz
MGQ1YyBpcyAyNzhlNjAwMCENClsgIDE3MC4yNjMyNjldIDMwZDY3IGlzIDI3OGM3MDAwIQ0K
WyAgMTcwLjI2NTAwMF0gMzBkNjggaXMgMjc4YzgwMDAhDQpbICAxNzAuMjY2NjYyXSAzMGQ2
OSBpcyAyNzhjOTAwMCENClsgIDE3MC4yNjgzNDFdIDMwZDZhIGlzIDI3OGNhMDAwIQ0KWyAg
MTcwLjI3MDA2M10gMzBkNmIgaXMgMjc4Y2IwMDAhDQpbICAxNzAuMjcxNzk4XSAzMGQ2YyBp
cyAyNzhjYzAwMCENClsgIDE3MC4yNzM1MzRdIDMwZDZkIGlzIDI3OGNkMDAwIQ0KWyAgMTcw
LjI3NTIyN10gMzBkNmUgaXMgMjc4Y2UwMDAhDQpbICAxNzAuMjc2OTM3XSAzMGQ2ZiBpcyAy
NzhjZjAwMCENClsgIDE3MC4yNzg2MDZdIDMwZDcwIGlzIDI3OGQwMDAwIQ0KWyAgMTcwLjI4
MDI4M10gMzBkNzEgaXMgMjc4ZDEwMDAhDQpbICAxNzAuMjgxOTgyXSAzMGQ3MiBpcyAyNzhi
YzAwMCENClsgIDE3MC4yODM2NzNdIDMwZDczIGlzIDI3OGJkMDAwIQ0KWyAgMTcwLjI4NTM3
NF0gMzBkNzQgaXMgMjc4YmUwMDAhDQpbICAxNzAuMjg3MDQ1XSAzMGQ3NSBpcyAyNzhiZjAw
MCENClsgIDE3MC4yODg3MTFdIDMwZDc2IGlzIDI3OGMwMDAwIQ0KWyAgMTcwLjI5MDQyMl0g
MzBkNzcgaXMgMjc4YzEwMDAhDQpbICAxNzAuMjkyMDgzXSAzMGQ3OCBpcyAyNzhjMjAwMCEN
ClsgIDE3MC4yOTM3ODRdIDMwZDc5IGlzIDI3OGMzMDAwIQ0KWyAgMTcwLjI5NTQyN10gMzBk
N2EgaXMgMjc4YzQwMDAhDQpbICAxNzAuMjk3MDkwXSAzMGQ3YiBpcyAyNzhjNTAwMCENClsg
IDE3MC4yOTg3NjZdIDMwZDdjIGlzIDI3OGM2MDAwIQ0KWyAgMTcwLjMwMDQzMF0gMzBkN2Qg
aXMgMjc4YjIwMDAhDQpbICAxNzAuMzAyMTIxXSAzMGQ3ZSBpcyAyNzhiMzAwMCENClsgIDE3
MC4zMDM4MDNdIDMwZDdmIGlzIDI3OGI0MDAwIQ0KWyAgMTcwLjMwNTQ1OF0gMzBkODAgaXMg
Mjc4YjUwMDAhDQpbICAxNzAuMzA3MTYzXSAzMGQ4MSBpcyAyNzhiNjAwMCENClsgIDE3MC4z
MDg4MzJdIDMwZDgyIGlzIDI3OGI3MDAwIQ0KWyAgMTcwLjMxMDUzN10gMzBkODMgaXMgMjc4
YjgwMDAhDQpbICAxNzAuMzEyMjEwXSAzMGQ4NCBpcyAyNzhiOTAwMCENClsgIDE3MC4zMTM4
OTddIDMwZDg1IGlzIDI3OGJhMDAwIQ0KWyAgMTcwLjMxNTU4OF0gMzBkODYgaXMgMjc4YmIw
MDAhDQpbICAxNzAuMzE3MjY0XSAzMGQ1ZCBpcyAyNzhkMjAwMCENClsgIDE3MC4zMTg5NjJd
IDMwZDVlIGlzIDI3OGQzMDAwIQ0KWyAgMTcwLjMyMDY0M10gMzBkNWYgaXMgMjc4ZDQwMDAh
DQpbICAxNzAuMzIyMzE2XSAzMGQ2MCBpcyAyNzhkNTAwMCENClsgIDE3MC4zMjQwMjldIDMw
ZDYxIGlzIDI3OGQ2MDAwIQ0KWyAgMTcwLjMyNTcwMV0gMzBkNjIgaXMgMjc4ZDcwMDAhDQpb
ICAxNzAuMzI3NDEzXSAzMGQ2MyBpcyAyNzhkODAwMCENClsgIDE3MC4zMjkwODhdIDMwZDY0
IGlzIDI3OGQ5MDAwIQ0KWyAgMTcwLjMzMDc3OV0gMzBkNjUgaXMgMjc4ZGEwMDAhDQpbICAx
NzAuMzMyNDc3XSAzMGQ2NiBpcyAyNzhkYjAwMCENClsgIDE3MC4zMzU3NTRdIDMwZDlkIGlz
IDI3ODkyMDAwIQ0KWyAgMTcwLjMzNzUwMV0gMzBkOWUgaXMgMjc4OTMwMDAhDQpbICAxNzAu
MzM5MTk2XSAzMGQ5ZiBpcyAyNzg5NDAwMCENClsgIDE3MC4zNDA5MjldIDMwZGEwIGlzIDI3
ODk1MDAwIQ0KWyAgMTcwLjM0MjYzMl0gMzBkYTEgaXMgMjc4OTYwMDAhDQpbICAxNzAuMzQ0
MzY0XSAzMGRhMiBpcyAyNzg5NzAwMCENClsgIDE3MC4zNDYwNjNdIDMwZGEzIGlzIDI3ODk4
MDAwIQ0KWyAgMTcwLjM0Nzc3OF0gMzBkYTQgaXMgMjc4OTkwMDAhDQpbICAxNzAuMzQ5NDg0
XSAzMGRhNSBpcyAyNzg5YTAwMCENClsgIDE3MC4zNTExODVdIDMwZGE2IGlzIDI3ODliMDAw
IQ0KWyAgMTcwLjM1Mjg4M10gMzBkOTIgaXMgMjc4OWMwMDAhDQpbICAxNzAuMzU0NTgzXSAz
MGQ5MyBpcyAyNzg5ZDAwMCENClsgIDE3MC4zNTYyNTFdIDMwZDk0IGlzIDI3ODllMDAwIQ0K
WyAgMTcwLjM1NzkyMl0gMzBkOTUgaXMgMjc4OWYwMDAhDQpbICAxNzAuMzU5NTc1XSAzMGQ5
NiBpcyAyNzhhMDAwMCENClsgIDE3MC4zNjEyNjNdIDMwZDk3IGlzIDI3OGExMDAwIQ0KWyAg
MTcwLjM2MjkyMV0gMzBkOTggaXMgMjc4YTIwMDAhDQpbICAxNzAuMzY0NjE0XSAzMGQ5OSBp
cyAyNzhhMzAwMCENClsgIDE3MC4zNjYyNzNdIDMwZDlhIGlzIDI3OGE0MDAwIQ0KWyAgMTcw
LjM2Nzk1MF0gMzBkOWIgaXMgMjc4YTUwMDAhDQpbICAxNzAuMzY5NjMwXSAzMGQ5YyBpcyAy
NzhhNjAwMCENClsgIDE3MC4zNzI0ODNdIDMwZGJlIGlzIDI3ODVjMDAwIQ0KWyAgMTcwLjM3
NDI4MF0gMzBkNGUgaXMgMjc4NWQwMDAhDQpbICAxNzAuMzc1OTY2XSAzWyAgMTcyLjUwNTEw
NF0gMzA1ZTMgaXMgMjdiYjIwMDAhDQpbICAxNzIuNTA2Nzk1XSAzMDVlNCBpcyAyN2JiMzAw
MCENClsgIDE3Mi41MDg1MThdIDMwNWU1IGlzIDI3YmI0MDAwIQ0KWyAgMTcyLjUxMDI3Ml0g
MzA1ZTYgaXMgMjdiYjUwMDAhDQpbICAxNzIuNTExOTU3XSAzMDVlNyBpcyAyN2JiNjAwMCEN
ClsgIDE3Mi41MTM2NDFdIDMwNWU4IGlzIDI3YmI3MDAwIQ0KWyAgMTcyLjUxNTMxN10gMzA1
ZTkgaXMgMjdiYjgwMDAhDQpbICAxNzIuNTE2OTk3XSAzMDVlYSBpcyAyN2JiOTAwMCENClsg
IDE3Mi41MTg2NTNdIDMwNWViIGlzIDI3YmJhMDAwIQ0KWyAgMTcyLjUyMDY3Ml0gMzA1ZjYg
aXMgMjdiOTAwMDAhDQpbICAxNzIuNTIyMzQwXSAzMDVmNyBpcyAyN2I5MTAwMCENClsgIDE3
Mi41MjQwMzRdIDMwNWY4IGlzIDI3YjkyMDAwIQ0KWyAgMTcyLjUyNTY4NF0gMzA1ZjkgaXMg
MjdiOTMwMDAhDQpbICAxNzIuNTI3MzQ0XSAzMDVmYSBpcyAyN2I5NDAwMCENClsgIDE3Mi41
MjkwMjNdIDMwNWZiIGlzIDI3Yjk1MDAwIQ0KWyAgMTcyLjUzMDY4NV0gMzA1ZmMgaXMgMjdi
OTYwMDAhDQpbICAxNzIuNTMyMzU4XSAzMDVmZCBpcyAyN2I5NzAwMCENClsgIDE3Mi41MzQw
MjddIDMwNWZlIGlzIDI3Yjk4MDAwIQ0KWyAgMTcyLjUzNTY3Nl0gMzA1ZmYgaXMgMjdiOTkw
MDAhDQpbICAxNzIuNTM3MzU1XSAzMDYwMCBpcyAyN2I5YTAwMCENClsgIDE3Mi41MzkwMTBd
IDMwNjAxIGlzIDI3Yjg2MDAwIQ0KWyAgMTcyLjU0MDcwMF0gMzA2MDIgaXMgMjdiODcwMDAh
DQpbICAxNzIuNTQyMzYwXSAzMDYwMyBpcyAyN2I4ODAwMCENClsgIDE3Mi41NDQwMzBdIDMw
NjA0IGlzIDI3Yjg5MDAwIQ0KWyAgMTcyLjU0NTY4OV0gMzA2MDUgaXMgMjdiOGEwMDAhDQpb
ICAxNzIuNTQ3MzQ1XSAzMDYwNiBpcyAyN2I4YjAwMCENClsgIDE3Mi41NDkwMDVdIDMwNjA3
IGlzIDI3YjhjMDAwIQ0KWyAgMTcyLjU1MDY1Nl0gMzA2MDggaXMgMjdiOGQwMDAhDQpbICAx
NzIuNTUyMzA1XSAzMDYwOSBpcyAyN2I4ZTAwMCENClsgIDE3Mi41NTM5ODRdIDMwNjBhIGlz
IDI3YjhmMDAwIQ0KWyAgMTcyLjU1NTYxNl0gMzA1ZTAgaXMgMjdiOWIwMDAhDQpbICAxNzIu
NTU3Mjk1XSAzMDVkZiBpcyAyN2I5YzAwMCENClsgIDE3Mi41NTg5NDldIDMwNWRlIGlzIDI3
YjlkMDAwIQ0KWyAgMTcyLjU2MDYxN10gMzA1ZGQgaXMgMjdiOWUwMDAhDQpbICAxNzIuNTYy
Mjk1XSAzMDVkYyBpcyAyN2I5ZjAwMCENClsgIDE3Mi41NjM5NjRdIDMwNWRiIGlzIDI3YmEw
MDAwIQ0KWyAgMTcyLjU2NTY0MV0gMzA1ZGEgaXMgMjdiYTEwMDAhDQpbICAxNzIuNTY3MzE0
XSAzMDVkOSBpcyAyN2JhMjAwMCENClsgIDE3Mi41Njg5NzZdIDMwNWQ4IGlzIDI3YmEzMDAw
IQ0KWyAgMTcyLjU3MDY3Ml0gMzA1ZDcgaXMgMjdiYTQwMDAhDQpbICAxNzIuNTcyMzM4XSAz
MDVkNiBpcyAyN2JhNTAwMCENClsgIDE3Mi41NzQwMjVdIDMwNWVjIGlzIDI3YmE2MDAwIQ0K
WyAgMTcyLjU3NTY4NV0gMzA1ZWQgaXMgMjdiYTcwMDAhDQpbICAxNzIuNTc3MzUzXSAzMDVl
ZSBpcyAyN2JhODAwMCENClsgIDE3Mi41NzkwMzBdIDMwNWVmIGlzIDI3YmE5MDAwIQ0KWyAg
MTcyLjU4MDcxMl0gMzA1ZjAgaXMgMjdiYWEwMDAhDQpbICAxNzIuNTgyNDA3XSAzMDVmMSBp
cyAyN2JhYjAwMCENClsgIDE3Mi41ODQwOTNdIDMwNWYyIGlzIDI3YmFjMDAwIQ0KWyAgMTcy
LjU4NTc4MF0gMzA1ZjMgaXMgMjdiYWQwMDAhDQpbICAxNzIuNTg3NDY1XSAzMDVmNCBpcyAy
N2JhZTAwMCENClsgIDE3Mi41ODkxMzhdIDMwNWY1IGlzIDI3YmFmMDAwIQ0KWyAgMTcyLjU5
MjAxM10gMzA1OTkgaXMgMjdiNzAwMDAhDQpbICAxNzIuNTkzNzI1XSAzMDU5YSBpcyAyN2I3
MTAwMCENClsgIDE3Mi41OTU0MTRdIDMwNTliIGlzIDI3YjcyMDAwIQ0KWyAgMTcyLjU5NzEx
M10gMzA1OWMgaXMgMjdiNzMwMDAhDQpbICAxNzIuNTk4ODA4XSAzMDU5ZCBpcyAyN2I3NDAw
MCENClsgIDE3Mi42MDA1MDBdIDMwNTllIGlzIDI3Yjc1MDAwIQ0KWyAgMTcyLjYwMjE4M10g
MzA1OWYgaXMgMjdiNzYwMDAhDQpbICAxNzIuNjAzOTAzXSAzMDVhMCBpcyAyN2I3NzAwMCEN
ClsgIDE3Mi42MDU1ODddIDMwNWExIGlzIDI3Yjc4MDAwIQ0KWyAgMTcyLjYwNzMwMl0gMzA1
YTIgaXMgMjdiNzkwMDAhDQpbICAxNzIuNjA4OTk5XSAzMDVhMyBpcyAyN2I3YTAwMCENClsg
IDE3Mi42MTA2OTldIDMwNjBjIGlzIDI3YjdiMDAwIQ0KWyAgMTcyLjYxMjM2NV0gMzA2MGIg
aXMgMjdiN2MwMDAhDQpbICAxNzIuNjE0MDQ2XSAzMDU5MCBpcyAyN2I3ZDAwMCENClsgIDE3
Mi42MTU3MzVdIDMwNTkxIGlzIDI3YjdlMDAwIQ0KWyAgMTcyLjYxNzQyM10gMzA1OTIgaXMg
MjdiN2YwMDAhDQpbICAxNzIuNjE5MTA0XSAzMDU5MyBpcyAyN2I4MDAwMCENClsgIDE3Mi42
MjA3OTBdIDMwNTk0IGlzIDI3YjgxMDAwIQ0KWyAgMTcyLjYyMjQ2OV0gMzA1OTUgaXMgMjdi
ODIwMDAhDQpbICAxNzIuNjI0MTc3XSAzMDU5NiBpcyAyN2I4MzAwMCENClsgIDE3Mi42MjU4
NTVdIDMwNTk3IGlzIDI3Yjg0MDAwIQ0KWyAgMTcyLjYyNzU2Ml0gMzA1OTggaXMgMjdiODUw
MDAhDQpbICAxNzIuNjI5NjYzXSAzMDYzNSBpcyAyN2I1MDAwMCENClsgIDE3Mi42MzE0Mjhd
IDMwNjM2IGlzIDI3YjUxMDAwIQ0KWyAgMTcyLjYzMzE1N10gMzA2MzcgaXMgMjdiNTIwMDAh
DQpbICAxNzIuNjM0ODgzXSAzMDYzOCBpcyAyN2I1MzAwMCENClsgIDE3Mi42MzY1OTVdIDMw
NjM5IGlzIDI3YjU0MDAwIQ0KWyAgMTcyLjYzODMxMF0gMzA2M2EgaXMgMjdiNTUwMDAhDQpb
ICAxNzIuNjQwMDIxXSAzMDYzYiBpcyAyN2I1NjAwMCENClsgIDE3Mi42NDE3MzNdIDMwNjNj
IGlzIDI3YjU3MDAwIQ0KWyAgMTcyLjY0MzQ1Nl0gMzA2M2QgaXMgMjdiNTgwMDAhDQpbICAx
NzIuNjQ1MTgzXSAzMDYzZSBpcyAyN2I1OTAwMCENClsgIDE3Mi42NDY4ODZdIDMwNjNmIGlz
IDI3YjVhMDAwIQ0KWyAgMTcyLjY0ODU4MF0gMzA2MmEgaXMgMjdiNWIwMDAhDQpbICAxNzIu
NjUwMjgwXSAzMDYyYiBpcyAyN2I1YzAwMCENClsgIDE3Mi42NTE5NDddIDMwNjJjIGlzIDI3
YjVkMDAwIQ0KWyAgMTcyLjY1MzY0Nl0gMzA2MmQgaXMgMjdiNWUwMDAhDQpbICAxNzIuNjU1
MzAxXSAzMDYyZSBpcyAyN2I1ZjAwMCENClsgIDE3Mi42NTY5ODddIDMwNjJmIGlzIDI3YjYw
MDAwIQ0KWyAgMTcyLjY1ODY0OF0gMzA2MzAgaXMgMjdiNjEwMDAhDQpbICAxNzIuNjYwMzMw
XSAzMDYzMSBpcyAyN2I2MjAwMCENClsgIDE3Mi42NjIwMjBdIDMwNjMyIGlzIDI3YjYzMDAw
IQ0KWyAgMTcyLjY2MzcwMl0gMzA2MzMgaXMgMjdiNjQwMDAhDQpbICAxNzIuNjY1Mzc5XSAz
MDYzNCBpcyAyN2I2NTAwMCENClsgIDE3Mi42NjcwNTVdIDMwNjQwIGlzIDI3YjQ2MDAwIQ0K
WyAgMTcyLjY2ODcxN10gMzA2NDEgaXMgMjdiNDcwMDAhDQpbICAxNzIuNjcwNDA4XSAzMDY0
NCBpcyAyN2I0ODAwMCENClsgIDE3Mi42NzIwNzVdIDMwNjQ1IGlzIDI3YjQ5MDAwIQ0KWyAg
MTcyLjY3Mzc2N10gMzA2NDYgaXMgMjdiNGEwMDAhDQpbICAxNzIuNjc1NDIzXSAzMDY0NyBp
cyAyN2I0YjAwMCENClsgIDE3Mi42NzcwOTNdIDMwNjQ4IGlzIDI3YjRjMDAwIQ0KWyAgMTcy
LjY3ODc1OV0gMzA2NDkgaXMgMjdiNGQwMDAhDQpbICAxNzIuNjgwNDIzXSAzMDY0YSBpcyAy
N2I0ZTAwMCENClsgIDE3Mi42ODIwOTRdIDMwNjRiIGlzIDI3YjRmMDAwIQ0KWyAgMTcyLjY4
Mzc1NF0gMzA1YTQgaXMgMjdiNjYwMDAhDQpbICAxNzIuNjg1NDA0XSAzMDVhNSBpcyAyN2I2
NzAwMCENClsgIDE3Mi42ODcwNzldIDMwNWE2IGlzIDI3YjY4MDAwIQ0KWyAgMTcyLjY4ODcy
M10gMzA2MjMgaXMgMjdiNjkwMDAhDQpbICAxNzIuNjkwNDA5XSAzMDYyNCBpcyAyN2I2YTAw
MCENClsgIDE3Mi42OTIwNzBdIDMwNjI1IGlzIDI3YjZiMDAwIQ0KWyAgMTcyLjY5Mzc0MV0g
MzA2MjYgaXMgMjdiNmMwMDAhDQpbICAxNzIuNjk1NDEzXSAzMDYyNyBpcyAyN2I2ZDAwMCEN
ClsgIDE3Mi42OTcwODJdIDMwNjI4IGlzIDI3YjZlMDAwIQ0KWyAgMTcyLjY5ODc1NF0gMzA2
MjkgaXMgMjdiNmYwMDAhDQpbICAxNzIuNzAyMDIxXSAzMDY2MiBpcyAyN2IyNjAwMCENClsg
IDE3Mi43MDM4MTFdIDMwNjYzIGlzIDI3YjI3MDAwIQ0KWyAgMTcyLjcwNTUwOV0gMzA2NjQg
aXMgMjdiMjgwMDAhDQpbICAxNzIuNzA3MjQ3XSAzMDY2NSBpcyAyN2IyOTAwMCENClsgIDE3
Mi43MDg5NjJdIDMwNjY2IGlzIDI3YjJhMDAwIQ0KWyAgMTcyLjcxMDcwNl0gMzA2NjcgaXMg
MjdiMmIwMDAhDQpbICAxNzIuNzEyNDA5XSAzMDY2OCBpcyAyN2IyYzAwMCENClsgIDE3Mi43
MTQxMTddIDMwNjY5IGlzIDI3YjJkMDAwIQ0KWyAgMTcyLjcxNTgyN10gMzA2NmEgaXMgMjdi
MmUwMDAhDQpbICAxNzIuNzE3NTIzXSAzMDY2YiBpcyAyN2IyZjAwMCENClsgIDE3Mi43MTky
MjddIDMwNjRjIGlzIDI3YjNiMDAwIQ0KWyAgMTcyLjcyMDkzMF0gMzA2NGQgaXMgMjdiM2Mw
MDAhDQpbICAxNzIuNzIyNjA4XSAzMDY0ZSBpcyAyN2IzZDAwMCENClsgIDE3Mi43MjQzNDBd
IDMwNjRmIGlzIDI3YjNlMDAwIQ0KWyAgMTcyLjcyNjAxM10gMzA2NTAgaXMgMjdiM2YwMDAh
DQpbICAxNzIuNzI3NzI4XSAzMDY1MSBpcyAyN2I0MDAwMCENClsgIDE3Mi43Mjk0MjddIDMw
NjUyIGlzIDI3YjQxMDAwIQ0KWyAgMTcyLjczMTEwOV0gMzA2NTMgaXMgMjdiNDIwMDAhDQpb
ICAxNzIuNzMyODA0XSAzMDY1NCBpcyAyN2I0MzAwMCENClsgIDE3Mi43MzQ0ODldIDMwNjU1
IGlzIDI3YjQ0MDAwIQ0KWyAgMTcyLjczNjE3Ml0gMzA2NTYgaXMgMjdiNDUwMDAhDQpbICAx
NzIuNzM3ODU0XSAzMDY1NyBpcyAyN2IzMDAwMCENClsgIDE3Mi43Mzk1MTVdIDMwNjU4IGlz
IDI3YjMxMDAwIQ0KWyAgMTcyLjc0MTIxMl0gMzA2NTkgaXMgMjdiMzIwMDAhDQpbICAxNzIu
NzQyODc4XSAzMDY1YSBpcyAyN2IzMzAwMCENClsgIDE3Mi43NDQ1NjJdIDMwNjViIGlzIDI3
YjM0MDAwIQ0KWyAgMTcyLjc0NjIxMV0gMzA2NWMgaXMgMjdiMzUwMDAhDQpbICAxNzIuNzQ3
ODc1XSAzMDY1ZCBpcyAyN2IzNjAwMCENClsgIDE3Mi43NDk1NDFdIDMwNjVlIGlzIDI3YjM3
MDAwIQ0KWyAgMTcyLjc1MTIwNV0gMzA2NWYgaXMgMjdiMzgwMDAhDQpbICAxNzIuNzUyODc2
XSAzMDY2MCBpcyAyN2IzOTAwMCENClsgIDE3Mi43NTQ1NTFdIDMwNjYxIGlzIDI3YjNhMDAw
IQ0KWyAgMTcyLjc1NzQwOF0gMzA2OGMgaXMgMjdhZjAwMDAhDQpbICAxNzIuNzU5MDg1XSAz
MDYwZCBpcyAyN2FmMTAwMCENClsgIDE3Mi43NjA3OTRdIDMwNjBlIGlzIDI3YWYyMDAwIQ0K
WyAgMTcyLjc2MjU0Ml0gMzA2MGYgaXMgMjdhZjMwMDAhDQpbICAxNzIuNzY0MjU2XSAzMDYx
MCBpcyAyN2FmNDAwMCENClsgIDE3Mi43NjU5NjddIDMwNjExIGlzIDI3YWY1MDAwIQ0KWyAg
MTcyLjc2NzY3OF0gMzA2MTIgaXMgMjdhZjYwMDAhDQpbICAxNzIuNzY5Mzk2XSAzMDYxMyBp
cyAyN2FmNzAwMCENClsgIDE3Mi43NzExMDJdIDMwNjE0IGlzIDI3YWY4MDAwIQ0KWyAgMTcy
Ljc3MjgwMV0gMzA2MTUgaXMgMjdhZjkwMDAhDQpbICAxNzIuNzc0NTI2XSAzMDYxNiBpcyAy
N2FmYTAwMCENClsgIDE3Mi43NzYyMDhdIDMwNjc3IGlzIDI3YjEwMDAwIQ0KWyAgMTcyLjc3
Nzk0M10gMzA2NzggaXMgMjdiMTEwMDAhDQpbICAxNzIuNzc5NjQwXSAzMDY3OSBpcyAyN2Ix
MjAwMCENClsgIDE3Mi43ODEzNjFdIDMwNjdhIGlzIDI3YjEzMDAwIQ0KWyAgMTcyLjc4MzA0
OF0gMzA2N2IgaXMgMjdiMTQwMDAhDQpbICAxNzIuNzg0NzYxXSAzMDY3YyBpcyAyN2IxNTAw
MCENClsgIDE3Mi43ODY0NjZdIDMwNjdkIGlzIDI3YjE2MDAwIQ0KWyAgMTcyLjc4ODE3Ml0g
MzA2N2UgaXMgMjdiMTcwMDAhDQpbICAxNzIuNzg5ODgwXSAzMDY3ZiBpcyAyN2IxODAwMCEN
ClsgIDE3Mi43OTE1NzldIDMwNjgwIGlzIDI3YjE5MDAwIQ0KWyAgMTcyLjc5MzI2OV0gMzA2
ODEgaXMgMjdiMWEwMDAhDQpbICAxNzIuNzk0OTg2XSAzMDY4MiBpcyAyN2IwNjAwMCENClsg
IDE3Mi43OTY2NzVdIDMwNjgzIGlzIDI3YjA3MDAwIQ0KWyAgMTcyLjc5ODM5Nl0gMzA2ODQg
aXMgMjdiMDgwMDAhDQpbICAxNzIuODAwMTAyXSAzMDY4NSBpcyAyN2IwOTAwMCENClsgIDE3
Mi44MDE4MDNdIDMwNjg2IGlzIDI3YjBhMDAwIQ0KWyAgMTcyLjgwMzUzMF0gMzA2ODcgaXMg
MjdiMGIwMDAhDQpbICAxNzIuODA1MjI3XSAzMDY4OCBpcyAyN2IwYzAwMCENClsgIDE3Mi44
MDY5NDldIDMwNjg5IGlzIDI3YjBkMDAwIQ0KWyAgMTcyLjgwODYzNF0gMzA2OGEgaXMgMjdi
MGUwMDAhDQpbICAxNzIuODEwMzMyXSAzMDY4YiBpcyAyN2IwZjAwMCENClsgIDE3Mi44MTIw
MTFdIDMwNjc2IGlzIDI3YWZiMDAwIQ0KWyAgMTcyLjgxMzcwNF0gMzA2NzUgaXMgMjdhZmMw
MDAhDQpbICAxNzIuODE1MzkyXSAzMDY3NCBpcyAyN2FmZDAwMCENClsgIDE3Mi44MTcwODFd
IDMwNjczIGlzIDI3YWZlMDAwIQ0KWyAgMTcyLjgxODc2Ml0gMzA2NzIgaXMgMjdhZmYwMDAh
DQpbICAxNzIuODIwNDQzXSAzMDY3MSBpcyAyN2IwMDAwMCENClsgIDE3Mi44MjIxMjddIDMw
NjcwIGlzIDI3YjAxMDAwIQ0KWyAgMTcyLjgyMzg0Ml0gMzA2NmYgaXMgMjdiMDIwMDAhDQpb
ICAxNzIuODI1NTI3XSAzMDY2ZSBpcyAyN2IwMzAwMCENClsgIDE3Mi44MjcyNDVdIDMwNjZk
IGlzIDI3YjA0MDAwIQ0KWyAgMTcyLjgyODkzNl0gMzA2NmMgaXMgMjdiMDUwMDAhDQpbICAx
NzIuODMyMzMwXSAzMDY5OCBpcyAyN2FjNjAwMCENClsgIDE3Mi44MzQxMTVdIDMwNjk5IGlz
IDI3YWM3MDAwIQ0KWyAgMTcyLjgzNTg0OF0gMzA2OWEgaXMgMjdhYzgwMDAhDQpbICAxNzIu
ODM3NTY5XSAzMDY5YiBpcyAyN2FjOTAwMCENClsgIDE3Mi44MzkyNzJdIDMwNjljIGlzIDI3
YWNhMDAwIQ0KWyAgMTcyLjg0MTAxN10gMzA2OWQgaXMgMjdhY2IwMDAhDQpbICAxNzIuODQy
NzMxXSAzMDY5ZSBpcyAyN2FjYzAwMCENClsgIDE3Mi44NDQ0ODhdIDMwNjlmIGlzIDI3YWNk
MDAwIQ0KWyAgMTcyLjg0NjIwOV0gMzA2YTAgaXMgMjdhY2UwMDAhDQpbICAxNzIuODQ3OTUw
XSAzMDZhMSBpcyAyN2FjZjAwMCENClsgIDE3Mi44NDk2NzBdIDMwNjIxIGlzIDI3YWRiMDAw
IQ0KWyAgMTcyLjg1MTM4MV0gMzA2MjAgaXMgMjdhZGMwMDAhDQpbICAxNzIuODUzMDk4XSAz
MDYxZiBpcyAyN2FkZDAwMCENClsgIDE3Mi44NTQ4MTldIDMwNjFlIGlzIDI3YWRlMDAwIQ0K
WyAgMTcyLjg1NjUzMl0gMzA2MWQgaXMgMjdhZGYwMDAhDQpbICAxNzIuODU4MjQ5XSAzMDYx
YyBpcyAyN2FlMDAwMCENClsgIDE3Mi44NTk5NTZdIDMwNjFiIGlzIDI3YWUxMDAwIQ0KWyAg
MTcyLjg2MTY5NF0gMzA2MWEgaXMgMjdhZTIwMDAhDQpbICAxNzIuODYzNDIxXSAzMDYxOSBp
cyAyN2FlMzAwMCENClsgIDE3Mi44NjUxNTBdIDMwNjE4IGlzIDI3YWU0MDAwIQ0KWyAgMTcy
Ljg2Njg3N10gMzA2MTcgaXMgMjdhZTUwMDAhDQpbICAxNzIuODY4NTk1XSAzMDY4ZCBpcyAy
N2FkMDAwMCENClsgIDE3Mi44NzAzMTddIDMwNjhlIGlzIDI3YWQxMDAwIQ0KWyAgMTcyLjg3
MjAyOV0gMzA2OGYgaXMgMjdhZDIwMDAhDQpbICAxNzIuODczNzcyXSAzMDY5MCBpcyAyN2Fk
MzAwMCENClsgIDE3Mi44NzU0OTFdIDMwNjkxIGlzIDI3YWQ0MDAwIQ0KWyAgMTcyLjg3NzIy
MF0gMzA2OTIgaXMgMjdhZDUwMDAhDQpbICAxNzIuODc4OTIyXSAzMDY5MyBpcyAyN2FkNjAw
MCENClsgIDE3Mi44ODA2MjZdIDMwNjk0IGlzIDI3YWQ3MDAwIQ0KWyAgMTcyLjg4MjMzMV0g
MzA2OTUgaXMgMjdhZDgwMDAhDQpbICAxNzIuODg0MDM1XSAzMDY5NiBpcyAyN2FkOTAwMCEN
ClsgIDE3Mi44ODU3MzVdIDMwNjk3IGlzIDI3YWRhMDAwIQ0KWyAgMTcyLjg4ODM4N10gMzA2
YWQgaXMgMjdhYjAwMDAhDQpbICAxNzIuODkwMTI0XSAzMDZhZSBpcyAyN2FiMTAwMCENClsg
IDE3Mi44OTE4MDldIDMwNmFmIGlzIDI3YWIyMDAwIQ0KWyAgMTcyLjg5MzUwNV0gMzA2YjAg
aXMgMjdhYjMwMDAhDQpbICAxNzIuODk1MjA3XSAzMDZiMSBpcyAyN2FiNDAwMCENClsgIDE3
Mi44OTY5MjRdIDMwNmIyIGlzIDI3YWI1MDAwIQ0KWyAgMTcyLjg5ODYyM10gMzA2YjMgaXMg
MjdhYjYwMDAhDQpbICAxNzIuOTAwMzAxXSAzMDZiNCBpcyAyN2FiNzAwMCENClsgIDE3Mi45
MDIwMTFdIDMwNmI1IGlzIDI3YWI4MDAwIQ0KWyAgMTcyLjkwMzY5MV0gMzA2YjYgaXMgMjdh
YjkwMDAhDQpbICAxNzIuOTA1MzU0XSAzMDZiNyBpcyAyN2FiYTAwMCENClsgIDE3Mi45MDcw
NDVdIDMwNmI4IGlzIDI3YWE2MDAwIQ0KWyAgMTcyLjkwODcxM10gMzA2YjkgaXMgMjdhYTcw
MDAhDQpbICAxNzIuOTEwNDAyXSAzMDZiYSBpcyAyN2FhODAwMCENClsgIDE3Mi45MTIwNzdd
IDMwNmJiIGlzIDI3YWE5MDAwIQ0KWyAgMTcyLjkxMzc0Ml0gMzA2YmMgaXMgMjdhYWEwMDAh
DQpbICAxNzIuOTE1NDA1XSAzMDZiZCBpcyAyN2FhYjAwMCENClsgIDE3Mi45MTcwNTddIDMw
NmJlIGlzIDI3YWFjMDAwIQ0KWyAgMTcyLjkxODcyOV0gMzA2YmYgaXMgMjdhYWQwMDAhDQpb
ICAxNzIuOTIwMzgyXSAzMDZjMCBpcyAyN2FhZTAwMCENClsgIDE3Mi45MjIwMzFdIDMwNmMx
IGlzIDI3YWFmMDAwIQ0KWyAgMTcyLjkyMzcwMF0gMzA2YzIgaXMgMjdhOTAwMDAhDQpbICAx
NzIuOTI1MzU1XSAzMGZjNiBpcyAyN2E5MTAwMCENClsgIDE3Mi45MjcwMzBdIDMwNjIyIGlz
IDI3YTkyMDAwIQ0KWyAgMTcyLjkyODY4MV0gMzA2ZGYgaXMgMjdhOTMwMDAhDQpbICAxNzIu
OTMwMzUwXSAzMDZlMCBpcyAyN2E5NDAwMCENClsgIDE3Mi45MzIwNTFdIDMwNmUxIGlzIDI3
YTk1MDAwIQ0KWyAgMTcyLjkzMzczNF0gMzA2ZTIgaXMgMjdhOTYwMDAhDQpbICAxNzIuOTM1
NDE3XSAzMDZlMyBpcyAyN2E5NzAwMCENClsgIDE3Mi45MzcwOTddIDMwNmU0IGlzIDI3YTk4
MDAwIQ0KWyAgMTcyLjkzODc4Ml0gMzA2ZTUgaXMgMjdhOTkwMDAhDQpbICAxNzIuOTQwNDkz
XSAzMDZlNiBpcyAyN2E5YTAwMCENClsgIDE3Mi45NDQ5MjVdIDMwNmU3IGlzIDI3YTg2MDAw
IQ0KWyAgMTcyLjk0NjU5OV0gMzA2ZTggaXMgMjdhODcwMDAhDQpbICAxNzIuOTQ4MzA2XSAz
MDZlOSBpcyAyN2E4ODAwMCENClsgIDE3Mi45NDk5ODBdIDMwNmVhIGlzIDI3YTg5MDAwIQ0K
WyAgMTcyLjk1MTY3NF0gMzA2ZWIgaXMgMjdhOGEwMDAhDQpbICAxNzIuOTUzMzkwXSAzMDZl
YyBpcyAyN2E4YjAwMCENClsgIDE3Mi45NTUwODFdIDMwNmVkIGlzIDI3YThjMDAwIQ0KWyAg
MTcyLjk1Njc5MF0gMzA2ZWUgaXMgMjdhOGQwMDAhDQpbICAxNzIuOTU4NDc0XSAzMDZlZiBp
cyAyN2E4ZTAwMCENClsgIDE3Mi45NjAzMzZdIDMwNmYwIGlzIDI3YThmMDAwIQ0KWyAgMTcy
Ljk2MjQ3N10gMzA3MDAgaXMgMjdhNDkwMDAhDQpbICAxNzIuOTY0MjQ2XSAzMDcwMSBpcyAy
N2E0YTAwMCENClsgIDE3Mi45NjU5ODFdIDMwNzAyIGlzIDI3YTRiMDAwIQ0KWyAgMTcyLjk2
NzcxNF0gMzA3MDMgaXMgMjdhNGMwMDAhDQpbICAxNzIuOTY5NDYwXSAzMDcwNCBpcyAyN2E0
ZDAwMCENClsgIDE3Mi45NzExOThdIDMwNzA1IGlzIDI3YTRlMDAwIQ0KWyAgMTcyLjk3Mjk1
M10gMzA3MDYgaXMgMjdhNGYwMDAhDQpbICAxNzIuOTc0NjkyXSAzMDcwNyBpcyAyN2E1MDAw
MCENClsgIDE3Mi45NzY0MTddIDMwNzA4IGlzIDI3YTUxMDAwIQ0KWyAgMTcyLjk3ODE2NV0g
MzA3MDkgaXMgMjdhNTIwMDAhDQpbICAxNzIuOTc5ODgyXSAzMDcwYSBpcyAyN2E1MzAwMCEN
ClsgIDE3Mi45ODE2MzRdIDMwNzBiIGlzIDI3YTNlMDAwIQ0KWyAgMTcyLjk4MzM0OF0gMzA3
MGMgaXMgMjdhM2YwMDAhDQpbICAxNzIuOTg1MDkzXSAzMDcwZCBpcyAyN2E0MDAwMCENClsg
IDE3Mi45ODY4MTVdIDMwNzBlIGlzIFsgIDE3NS4xMTM2NDNdIDMwMWJiIGlzIDI3ZjdkMDAw
IQ0KWyAgMTc1LjExNTM3NF0gMzAxYmMgaXMgMjdmN2YwMDAhDQpbICAxNzUuMTE3MDk1XSAz
MDFiZCBpcyAyN2Y3ZTAwMCENClsgIDE3NS4xMTg4MDhdIDMwMWJlIGlzIDI3ZjZlMDAwIQ0K
WyAgMTc1LjEyMDgxOF0gMzAxYmYgaXMgMjcxYzIwMDAhDQpbICAxNzUuMTIyNDk2XSAzMDE3
YiBpcyAyN2Y2YzAwMCENClsgIDE3NS4xMjQyMjVdIDMwMTdjIGlzIDI3NzYwMDAwIQ0KWyAg
MTc1LjEyNTkyOV0gMzAxN2QgaXMgMjgxNjIwMDAhDQpbICAxNzUuMTI3NzQ0XSAzMDE3ZSBp
cyAyN2Y3NjAwMCENClsgIDE3NS4xMjk0NjVdIDMwMTdmIGlzIDI3Zjc4MDAwIQ0KWyAgMTc1
LjEzMTIwMF0gMzAxODAgaXMgMjdmNzcwMDAhDQpbICAxNzUuMTMyOTQxXSAzMDE4MSBpcyAy
ODE1NjAwMCENClsgIDE3NS4xMzQ3MDVdIDMwMWE5IGlzIDI3ZjcwMDAwIQ0KWyAgMTc1LjEz
NjQ5M10gMzAxYTggaXMgMjdmNmYwMDAhDQpbICAxNzUuMTM4Mjc4XSAzMDFhNyBpcyAyN2Y4
MDAwMCENClsgIDE3NS4xNDAwODJdIDMwMTgyIGlzIDI3ZjRkMDAwIQ0KWyAgMTc1LjE0MTg2
NF0gMzAxODMgaXMgMjdmNGUwMDAhDQpbICAxNzUuMTQzNjYwXSAzMDE4NCBpcyAyN2Y0ZjAw
MCENClsgIDE3NS4xNDU0NTRdIDMwMTg1IGlzIDI3ZjUwMDAwIQ0KWyAgMTc1LjE0NzI0NF0g
MzAxODYgaXMgMjdmNzEwMDAhDQpbICAxNzUuMTQ5MDQ0XSAzMDE4NyBpcyAyN2Y3MjAwMCEN
ClsgIDE3NS4xNTA4MjJdIDMwMTg4IGlzIDI3ZjczMDAwIQ0KWyAgMTc1LjE1MjYxM10gMzAx
ODkgaXMgMjdmNzQwMDAhDQpbICAxNzUuMTU0Mzk3XSAzMDE4YSBpcyAyN2Y1MTAwMCENClsg
IDE3NS4xNTYxNzRdIDMwMThiIGlzIDI3ZjUyMDAwIQ0KWyAgMTc1LjE1Nzk2OF0gMzAxOGMg
aXMgMjgxNjAwMDAhDQpbICAxNzUuMTU5NzQ0XSAzMDE4ZCBpcyAyN2Y0YjAwMCENClsgIDE3
NS4xNjE1NjhdIDMwMThlIGlzIDI3ZjRjMDAwIQ0KWyAgMTc1LjE2MzM4M10gMzAxYTYgaXMg
MjdmODEwMDAhDQpbICAxNzUuMTY1MjA5XSAzMDFhNSBpcyAyN2Y4ODAwMCENClsgIDE3NS4x
NjcwMjhdIDMwMWE0IGlzIDI3ZjZkMDAwIQ0KWyAgMTc1LjE2ODg0MF0gMzAxYTMgaXMgMjdm
NjkwMDAhDQpbICAxNzUuMTcwNjgxXSAzMDFhMiBpcyAyN2Y2ODAwMCENClsgIDE3NS4xNzI0
OThdIDMwMWExIGlzIDI3Zjg3MDAwIQ0KWyAgMTc1LjE3NDM1MV0gMzAxYTAgaXMgMjdmNzUw
MDAhDQpbICAxNzUuMTc2MzA1XSAzMDFhYSBpcyAyN2Y0YTAwMCENClsgIDE3NS4xODM3NTNd
IDMwMWMwIGlzIDI3ZjQ5MDAwIQ0KWyAgMTc1LjE5NDY2N10gMzAxOGYgaXMgMjdmNDgwMDAh
DQpbICAxNzUuMjA0MzYyXSAzMDFjMSBpcyAyN2Y0NzAwMCENClsgIDE3NS4yMTIzMTldIDMw
MWMyIGlzIDI3ZjQ2MDAwIQ0KWyAgMTc1LjIxNzI5NV0gMzAxYzMgaXMgMjdmNDUwMDAhDQpb
ICAxNzUuMjIxMzgwXSAzMDFjNCBpcyAyN2Y0NDAwMCENClsgIDE3NS4yMjQ5MDddIDMwMWM1
IGlzIDI3ZjQzMDAwIQ0KWyAgMTc1LjIyNzEyM10gMzAxYzYgaXMgMjdmNDIwMDAhDQpbICAx
NzUuMjM1NDMyXSAzMDFjNyBpcyAyN2Y0MTAwMCENClsgIDE3NS4yNDU5NDZdIDMwMWM4IGlz
IDI3ZjQwMDAwIQ0KWyAgMTc1LjI0ODk0NV0gMzAxYzkgaXMgMjdmM2YwMDAhDQpbICAxNzUu
MjUxMzgxXSAzMDFjYSBpcyAyN2YzZTAwMCENClsgIDE3NS4yNTM2MzVdIDMwMWNiIGlzIDI3
ZjNkMDAwIQ0KWyAgMTc1LjI1ODYyOV0gMzAxY2MgaXMgMjdmM2MwMDAhDQpbICAxNzUuMjYx
ODc4XSAzMDFjZCBpcyAyN2YzYjAwMCENClsgIDE3NS4yNzc4MzldIDMwMWNlIGlzIDI3ZjNh
MDAwIQ0KWyAgMTc1LjI4NzE3OV0gMzAxOTAgaXMgMjdmMzkwMDAhDQpbICAxNzUuMjkxMTU2
XSAzMDFjZiBpcyAyN2YzODAwMCENClsgIDE3NS4yOTMzNDJdIDMwMWQwIGlzIDI3ZjM3MDAw
IQ0KWyAgMTc1LjI5OTkyOF0gMzAxZDEgaXMgMjdmMzYwMDAhDQpbICAxNzUuMzA3NDY0XSAz
MDFkMiBpcyAyN2YzNTAwMCENClsgIDE3NS4zMTI1MDVdIDMwMWQzIGlzIDI3ZjM0MDAwIQ0K
WyAgMTc1LjMxNTYwNV0gMzAxZDQgaXMgMjdmMzMwMDAhDQpbICAxNzUuMzE3NzYxXSAzMDFk
NSBpcyAyN2YzMjAwMCENClsgIDE3NS4zMjA1NzhdIDMwMWQ2IGlzIDI3ZjMxMDAwIQ0KWyAg
MTc1LjMyNzI4MV0gMzAxZDcgaXMgMjdmMzAwMDAhDQpbICAxNzUuMzMwODA4XSAzMDFkOCBp
cyAyN2YyZjAwMCENClsgIDE3NS4zMzc5NjddIDMwMWQ5IGlzIDI3ZjJlMDAwIQ0KWyAgMTc1
LjM0MTY3Ml0gMzAxZGEgaXMgMjdmMmQwMDAhDQpbICAxNzUuMzQ5MDAzXSAzMDFkYiBpcyAy
N2YyYzAwMCENClsgIDE3NS4zNTExNjZdIDMwMWRjIGlzIDI3ZjJiMDAwIQ0KWyAgMTc1LjM1
MzMyN10gMzAxZGQgaXMgMjdmMmEwMDAhDQpbICAxNzUuMzc0NjE5XSAzMDFkZSBpcyAyN2Yy
OTAwMCENClsgIDE3NS4zODM0MjFdIDMwMWVlIGlzIDI3ZjI4MDAwIQ0KWyAgMTc1LjM4NTU0
Nl0gMzAxZGYgaXMgMjdmMjcwMDAhDQpbICAxNzUuMzg3NzIyXSAzMDFlMCBpcyAyN2YyNjAw
MCENClsgIDE3NS4zOTE1NjBdIDMwMWUxIGlzIDI3ZjI1MDAwIQ0KWyAgMTc1LjM5NDgwOF0g
MzAxZTIgaXMgMjdmMjQwMDAhDQpbICAxNzUuMzk5MDQ3XSAzMDFlMyBpcyAyN2YyMzAwMCEN
ClsgIDE3NS40MDIxNTNdIDMwMWU0IGlzIDI3ZjIyMDAwIQ0KWyAgMTc1LjQwODE1MV0gMzAx
ZTUgaXMgMjdmMjEwMDAhDQpbICAxNzUuNDE3MzA4XSAzMDFlNiBpcyAyN2YyMDAwMCENClsg
IDE3NS40MTk0NzZdIDMwMWU3IGlzIDI3ZjFmMDAwIQ0KWyAgMTc1LjQyMTYxNl0gMzAxZTgg
aXMgMjdmMWUwMDAhDQpbICAxNzUuNDI1MTgxXSAzMDFlOSBpcyAyN2YxZDAwMCENClsgIDE3
NS40Mjg5NzBdIDMwMWVhIGlzIDI3ZjFjMDAwIQ0KWyAgMTc1LjQzMTk1OF0gMzAxZWIgaXMg
MjdmMWIwMDAhDQpbICAxNzUuNDM2NTAwXSAzMDFlYyBpcyAyN2YxYTAwMCENClsgIDE3NS40
NDIyNjVdIDMwMWVkIGlzIDI3ZjE5MDAwIQ0KWyAgMTc1LjQ0Nzg3MV0gMzAyMGQgaXMgMjdm
MTgwMDAhDQpbICAxNzUuNDYwODkzXSAzMDIwZSBpcyAyN2YxNzAwMCENClsgIDE3NS40NzE0
ODBdIDMwMjBmIGlzIDI3ZjE2MDAwIQ0KWyAgMTc1LjQ3OTkzNF0gMzAxZWYgaXMgMjdmMTUw
MDAhDQpbICAxNzUuNDgyOTA1XSAzMDIxMCBpcyAyN2YxNDAwMCENClsgIDE3NS40ODY5MDRd
IDMwMjExIGlzIDI3ZjEzMDAwIQ0KWyAgMTc1LjQ5MTk2MV0gMzAyMTIgaXMgMjdmMTIwMDAh
DQpbICAxNzUuNDk3NjY3XSAzMDIxMyBpcyAyN2YxMTAwMCENClsgIDE3NS40OTk4MzBdIDMw
MjE0IGlzIDI3ZjEwMDAwIQ0KWyAgMTc1LjUwMjE4NF0gMzAyMTUgaXMgMjdmMGYwMDAhDQpb
ICAxNzUuNTA3MDAyXSAzMDIxNiBpcyAyN2YwZTAwMCENClsgIDE3NS41MTAxOTddIDMwMjE3
IGlzIDI3ZjBkMDAwIQ0KWyAgMTc1LjUxNDU3M10gMzAyMTggaXMgMjdmMGMwMDAhDQpbICAx
NzUuNTIwMTQyXSAzMDFmMCBpcyAyN2YwYjAwMCENClsgIDE3NS41MjcwMDddIDMwMjE5IGlz
IDI3ZjBhMDAwIQ0KWyAgMTc1LjUzMTc5NF0gMzAyMWEgaXMgMjdmMDkwMDAhDQpbICAxNzUu
NTQxMDk5XSAzMDIxYiBpcyAyN2YwODAwMCENClsgIDE3NS41NTUzMDZdIDMwMjFjIGlzIDI3
ZjA3MDAwIQ0KWyAgMTc1LjU1OTA2M10gMzAyMWQgaXMgMjdmMDYwMDAhDQpbICAxNzUuNTYy
NTY5XSAzMDIxZSBpcyAyN2YwNTAwMCENClsgIDE3NS41NjQ3MzNdIDMwMjFmIGlzIDI3ZjA0
MDAwIQ0KWyAgMTc1LjU3NTQ4Nl0gMzAyMjAgaXMgMjdmMDMwMDAhDQpbICAxNzUuNTc5NjY1
XSAzMDIyMSBpcyAyN2YwMjAwMCENClsgIDE3NS41ODI2NzBdIDMwMjIyIGlzIDI3ZjAxMDAw
IQ0KWyAgMTc1LjU5MTQ0OF0gMzAyMjMgaXMgMjdmMDAwMDAhDQpbICAxNzUuNjAyNTE5XSAz
MDIyNCBpcyAyN2VmZjAwMCENClsgIDE3NS42MDQ3MDJdIDMwMjI1IGlzIDI3ZWZlMDAwIQ0K
WyAgMTc1LjYxNzMyM10gMzAyMjYgaXMgMjdlZmQwMDAhDQpbICAxNzUuNjIzODI3XSAzMDIy
NyBpcyAyN2VmYzAwMCENClsgIDE3NS42MzAyNTFdIDMwMjI4IGlzIDI3ZWZiMDAwIQ0KWyAg
MTc1LjYzMjQ5Ml0gMzAyMjkgaXMgMjdlZmEwMDAhDQpbICAxNzUuNjM4MjIzXSAzMDIyYSBp
cyAyN2VmOTAwMCENClsgIDE3NS42NDA0MjhdIDMwMjJiIGlzIDI3ZWY4MDAwIQ0KWyAgMTc1
LjY0NDA5NF0gMzAyMmMgaXMgMjdlZjcwMDAhDQpbICAxNzUuNjQ3NzM2XSAzMDIyZCBpcyAy
N2VmNjAwMCENClsgIDE3NS42NTU4MDBdIDMwMjJlIGlzIDI3ZWY1MDAwIQ0KWyAgMTc1LjY2
MDMyNl0gMzAyMmYgaXMgMjdlZjQwMDAhDQpbICAxNzUuNjcxMDcxXSAzMDIzMSBpcyAyN2Vm
MjAwMCENClsgIDE3NS42NzMyOTBdIDMwMjMyIGlzIDI3ZWYxMDAwIQ0KWyAgMTc1LjY3Nzg2
N10gMzAyMzMgaXMgMjdlZjAwMDAhDQpbICAxNzUuNjg1NjkyXSAzMDFmMSBpcyAyN2VlZjAw
MCENClsgIDE3NS42ODgxMjNdIDMwMjM0IGlzIDI3ZWVlMDAwIQ0KWyAgMTc1LjY5OTA2NF0g
MzAyMzUgaXMgMjdlZWQwMDAhDQpbICAxNzUuNzEwMjAyXSAzMDIzNiBpcyAyN2VlYzAwMCEN
ClsgIDE3NS43MTI0MjVdIDMwMjM3IGlzIDI3ZWViMDAwIQ0KWyAgMTc1LjcxNDczN10gMzAy
MzggaXMgMjdlZWEwMDAhDQpbICAxNzUuNzE3NTQ1XSAzMDIzOSBpcyAyN2VlOTAwMCENClsg
IDE3NS43MTk3OTldIDMwMjNhIGlzIDI3ZWU4MDAwIQ0KWyAgMTc1LjcyMTk5N10gMzAyM2Ig
aXMgMjdlZTcwMDAhDQpbICAxNzUuNzI3MjI0XSAzMDIzYyBpcyAyN2VlNjAwMCENClsgIDE3
NS43MzA1NjldIDMwMjNkIGlzIDI3ZWU1MDAwIQ0KWyAgMTc1Ljc0MTg3MF0gMzAyM2UgaXMg
MjdlZTQwMDAhDQpbICAxNzUuNzUyNjk0XSAzMDIzZiBpcyAyN2VlMzAwMCENClsgIDE3NS43
NTUzMDNdIDMwMjQwIGlzIDI3ZWUyMDAwIQ0KWyAgMTc1Ljc1NzUyM10gMzAyNDEgaXMgMjdl
ZTEwMDAhDQpbICAxNzUuNzYxMzgxXSAzMDI0MiBpcyAyN2VlMDAwMCENClsgIDE3NS43NjM1
MThdIDMwMjQzIGlzIDI3ZWRmMDAwIQ0KWyAgMTc1Ljc2NTgwNV0gMzAyNDQgaXMgMjdlZGUw
MDAhDQpbICAxNzUuNzcwNjQxXSAzMDFmMiBpcyAyN2VkZDAwMCENClsgIDE3NS43NzI4NDhd
IDMwMjQ1IGlzIDI3ZWRjMDAwIQ0KWyAgMTc1Ljc3NTAxMl0gMzAyNDYgaXMgMjdlZGIwMDAh
DQpbICAxNzUuNzg0MTc1XSAzMDFmMyBpcyAyN2VkYTAwMCENClsgIDE3NS43ODgwMjVdIDMw
MWY0IGlzIDI3ZWQ5MDAwIQ0KWyAgMTc1Ljc5NTcxNF0gMzAyNDcgaXMgMjdlZDgwMDAhDQpb
ICAxNzUuODEyMjQ2XSAzMDI0OCBpcyAyN2VkNzAwMCENClsgIDE3NS44MjQwMjddIDMwMjQ5
IGlzIDI3ZWQ2MDAwIQ0KWyAgMTc1LjgyNjI2NV0gMzAyNGEgaXMgMjdlZDUwMDAhDQpbICAx
NzUuODI4NTA0XSAzMDI0YiBpcyAyN2VkNDAwMCENClsgIDE3NS44MzUwNjFdIDMwMjRjIGlz
IDI3ZWQzMDAwIQ0KWyAgMTc1LjgzODA0OF0gMzAyNGQgaXMgMjdlZDIwMDAhDQpbICAxNzUu
ODQyNTg2XSAzMDI0ZSBpcyAyN2VkMTAwMCENClsgIDE3NS44NDgyNjNdIDMwMjRmIGlzIDI3
ZWQwMDAwIQ0KWyAgMTc1Ljg1MzAwMV0gMzAyNTAgaXMgMjdlY2YwMDAhDQpbICAxNzUuODU4
MzA3XSAzMDI1MSBpcyAyN2VjZTAwMCENClsgIDE3NS44NzMzNjNdIDMwMjUyIGlzIDI3ZWNk
MDAwIQ0KWyAgMTc1Ljg4MDUxMV0gMzAyNTMgaXMgMjdlY2MwMDAhDQpbICAxNzUuODg0MDM1
XSAzMDI1NCBpcyAyN2VjYjAwMCENClsgIDE3NS44ODYyMzJdIDMwMjU1IGlzIDI3ZWNhMDAw
IQ0KWyAgMTc1Ljg4ODQxMF0gMzAyNTYgaXMgMjdlYzkwMDAhDQpbICAxNzUuODkxMjgxXSAz
MDI1NyBpcyAyN2VjODAwMCENClsgIDE3NS44OTg5NzRdIDMwMjU4IGlzIDI3ZWM3MDAwIQ0K
WyAgMTc1LjkwMTE2NF0gMzAyNTkgaXMgMjdlYzYwMDAhDQpbICAxNzUuOTEwMTY2XSAzMDI1
YSBpcyAyN2VjNTAwMCENClsgIDE3NS45MTUxMDldIDMwMjViIGlzIDI3ZWM0MDAwIQ0KWyAg
MTc1LjkyNDc4NF0gMzAyNWMgaXMgMjdlYzMwMDAhDQpbICAxNzUuOTI2OTY5XSAzMDI1ZCBp
cyAyN2VjMjAwMCENClsgIDE3NS45NDA4MTldIDMwMjVlIGlzIDI3ZWMxMDAwIQ0KWyAgMTc1
Ljk0NDc5M10gMzAyNWYgaXMgMjdlYzAwMDAhDQpbICAxNzUuOTQ5MDYwXSAzMDI2MCBpcyAy
N2ViZjAwMCENClsgIDE3NS45NTE4NThdIDMwMjYxIGlzIDI3ZWJlMDAwIQ0KWyAgMTc1Ljk1
NzY2OF0gMzAyNjIgaXMgMjdlYmQwMDAhDQpbICAxNzUuOTY0MDY0XSAzMDI2MyBpcyAyN2Vi
YzAwMCENClsgIDE3NS45NzgyOTFdIDMwMjY0IGlzIDI3ZWJiMDAwIQ0KWyAgMTc1Ljk4MDQz
NF0gMzAyNjUgaXMgMjdlYmEwMDAhDQpbICAxNzUuOTg1OTA1XSAzMDI2NiBpcyAyN2ViOTAw
MCENClsgIDE3NS45ODg2MTZdIDMwMjY3IGlzIDI3ZWI4MDAwIQ0KWyAgMTc1Ljk5ODI5Nl0g
MzAyNjggaXMgMjdlYjcwMDAhDQpbICAxNzYuMDAwNTA0XSAzMDI2OSBpcyAyN2U3YTAwMCEN
ClsgIDE3Ni4wMDI2NzJdIDMwMjZhIGlzIDI3ZTdiMDAwIQ0KWyAgMTc2LjAwNjM1N10gMzAy
NmIgaXMgMjdlN2MwMDAhDQpbICAxNzYuMDEwMDg4XSAzMDI2YyBpcyAyN2U3ZDAwMCENClsg
IDE3Ni4wMTIxNjZdIDMwMjZkIGlzIDI3ZTdlMDAwIQ0KWyAgMTc2LjAxNTg2Ml0gMzAyNmUg
aXMgMjdlN2YwMDAhDQpbICAxNzYuMDMwMzI5XSAzMDI2ZiBpcyAyN2U4MDAwMCENClsgIDE3
Ni4wMzM4MDBdIDMwMWY1IGlzIDI3ZTgxMDAwIQ0KWyAgMTc2LjAzODEzMV0gMzAyNzAgaXMg
MjdlODIwMDAhDQpbICAxNzYuMDQ0NzQwXSAzMDI3MSBpcyAyN2U4MzAwMCENClsgIDE3Ni4w
NDgyNjddIDMwMjcyIGlzIDI3ZTg0MDAwIQ0KWyAgMTc2LjA1MDQxOF0gMzAyNzMgaXMgMjdl
ODUwMDAhDQpbICAxNzYuMDU4MjI1XSAzMDI3NCBpcyAyN2U4NjAwMCENClsgIDE3Ni4wNjQ1
OTddIDMwMjc1IGlzIDI3ZTg3MDAwIQ0KWyAgMTc2LjA2ODI0M10gMzAyNzYgaXMgMjdlODgw
MDAhDQpbICAxNzYuMDcxNDAwXSAzMDI3NyBpcyAyN2U4OTAwMCENClsgIDE3Ni4wNzUwOTdd
IDMwMjc4IGlzIDI3ZThhMDAwIQ0KWyAgMTc2LjA4MjQzMF0gMzAyNzkgaXMgMjdlOGIwMDAh
DQpbICAxNzYuMDg1NTA3XSAzMDI3YSBpcyAyN2U4YzAwMCENClsgIDE3Ni4wOTUzODRdIDMw
MjdiIGlzIDI3ZThkMDAwIQ0KWyAgMTc2LjA5OTc1OF0gMzAyN2MgaXMgMjdlOGUwMDAhDQpb
ICAxNzYuMTAyOTI0XSAzMDI3ZCBpcyAyN2U4ZjAwMCENClsgIDE3Ni4xMTE3MDFdIDMwMjdl
IGlzIDI3ZTkwMDAwIQ0KWyAgMTc2LjExNDc3NV0gMzAyN2YgaXMgMjdlOTEwMDAhDQpbICAx
NzYuMTE3Mjk4XSAzMDI4MCBpcyAyN2U5MjAwMCENClsgIDE3Ni4xMjA1NzldIDMwMjgxIGlz
IDI3ZTkzMDAwIQ0KWyAgMTc2LjEyNjY0Ml0gMzAyODIgaXMgMjdlOTQwMDAhDQpbICAxNzYu
MTI4ODIyXSAzMDI4MyBpcyAyN2U5NTAwMCENClsgIDE3Ni4xMzI4MTFdIDMwMjg0IGlzIDI3
ZWIzMDAwIQ0KWyAgMTc2LjEzNTAyM10gMzAyODUgaXMgMjdlYTQwMDAhDQpbICAxNzYuMTQx
MDQzXSAzMDI4NiBpcyAyN2VhNTAwMCENClsgIDE3Ni4xNDMyNDBdIDMwMjg3IGlzIDI3ZWEz
MDAwIQ0KWyAgMTc2LjE3NTQzNV0gMzAyODggaXMgMjdlYTIwMDAhDQpbICAxNzYuMTc3NjA5
XSAzMDFmNiBpcyAyN2VhODAwMCENClsgIDE3Ni4xODExNzNdIDMwMjg5IGlzIDI3ZWE5MDAw
IQ0KWyAgMTc2LjE4MzM0MF0gMzAyOGEgaXMgMjdlYWEwMDAhDQpbICAxNzYuMTg1NTUxXSAz
MDI4YiBpcyAyN2VhYjAwMCENClsgIDE3Ni4xODc3MjldIDMwMjhjIGlzIDI3ZWFkMDAwIQ0K
WyAgMTc2LjE5MTk2M10gMzAyOGQgaXMgMjdlYTcwMDAhDQpbICAxNzYuMTk0MTM4XSAzMDI4
ZSBpcyAyN2ViMDAwMCENClsgIDE3Ni4xOTYyNzhdIDMwMjhmIGlzIDI3ZWFlMDAwIQ0KWyAg
MTc2LjIwMzkyNF0gMzAyOTAgaXMgMjdlOTYwMDAhDQpbICAxNzYuMjA2MTE4XSAzMDFmNyBp
cyAyN2U5NzAwMCENClsgIDE3Ni4yMDgzMDhdIDMwMjkxIGlzIDI3ZWFmMDAwIQ0KWyAgMTc2
LjIxMDUyMF0gMzAyOTIgaXMgMjdlYjQwMDAhDQpbICAxNzYuMjEyNzA4XSAzMDI5MyBpcyAy
N2VhNjAwMCENClsgIDE3Ni4yMTQ5NDJdIDMwMjk0IGlzIDI3ZWIyMDAwIQ0KWyAgMTc2LjIx
NzEyOV0gMzAyOTUgaXMgMjdlYjEwMDAhDQpbICAxNzYuMjE5MzQ1XSAzMDI5NiBpcyAyN2Y4
NTAwMCENClsgIDE3Ni4yMjE1NzRdIDMwMjk3IGlzIDI3ZTlkMDAwIQ0KWyAgMTc2LjIyMzgw
MF0gMzAyOTggaXMgMjdlOWUwMDAhDQpbICAxNzYuMjI2MDQ3XSAzMDI5OSBpcyAyN2M5MjAw
MCENClsgIDE3Ni4yMjgyODVdIDMwMjlhIGlzIDI3Zjc5MDAwIQ0KWyAgMTc2LjIzMDUxM10g
MzAyOWIgaXMgMjdjOTMwMDAhDQpbICAxNzYuMjMyNzM3XSAzMDI5YyBpcyAyN2ViNTAwMCEN
ClsgIDE3Ni4yMzQ5NzldIDMwMjlkIGlzIDI4MTYxMDAwIQ0KWyAgMTc2LjIzNzIzMF0gMzAy
OWUgaXMgMjdlNzkwMDAhDQpbICAxNzYuMjM5NTExXSAzMDI5ZiBpcyAyN2U5YzAwMCENClsg
IDE3Ni4yNDE3NzJdIDMwMmEwIGlzIDI3ZTliMDAwIQ0KWyAgMTc2LjI0ODg0Ml0gMzAyYTEg
aXMgMjdlOWEwMDAhDQpbICAxNzYuMjU4NjU0XSAzMDJhMiBpcyAyN2U5OTAwMCENClsgIDE3
Ni4yNjA5NTJdIDMwMWY4IGlzIDI3ZTc4MDAwIQ0KWyAgMTc2LjI2MzIzN10gMzAyYTMgaXMg
MjdlNzcwMDAhDQpbICAxNzYuMjY5OTI4XSAzMDJhNCBpcyAyN2U3NjAwMCENClsgIDE3Ni4y
NzIzMTBdIDMwMmE1IGlzIDI3ZTc1MDAwIQ0KWyAgMTc2LjI3NDYyNF0gMzAyYTYgaXMgMjdl
NzQwMDAhDQpbICAxNzYuMjc2ODc3XSAzMDJhNyBpcyAyN2U3MzAwMCENClsgIDE3Ni4yNzky
ODNdIDMwMmE4IGlzIDI3ZTcyMDAwIQ0KWyAgMTc2LjI4MTYxN10gMzAxZjkgaXMgMjdlNzEw
MDAhDQpbICAxNzYuMjgzOTA1XSAzMDJhOSBpcyAyN2U3MDAwMCENClsgIDE3Ni4yODYyMzld
IDMwMWZhIGlzIDI3ZTZmMDAwIQ0KWyAgMTc2LjI5MjU2MF0gMzAyYWEgaXMgMjdlNmUwMDAh
DQpbICAxNzYuMjk0ODkwXSAzMDFmYiBpcyAyN2U2ZDAwMCENClsgIDE3Ni4yOTcxOTBdIDMw
MWZjIGlzIDI3ZTZjMDAwIQ0KWyAgMTc2LjI5OTQ5Ml0gMzAxZmQgaXMgMjdlNmIwMDAhDQpb
ICAxNzYuMzAxNzU2XSAzMDJhYiBpcyAyN2U2YTAwMCENClsgIDE3Ni4zMDQwMjldIDMwMWZl
IGlzIDI3ZTY5MDAwIQ0KWyAgMTc2LjMyMTgzOV0gMzAxZmYgaXMgMjdlNjIwMDAhDQpbICAx
NzYuMzIzNzIzXSAzMDIwMCBpcyAyN2U2MzAwMCENClsgIDE3Ni4zMjU2NzhdIDMwMjAxIGlz
IDI3ZTY0MDAwIQ0KWyAgMTc2LjMyNzYzN10gMzAyMDIgaXMgMjdlNjUwMDAhDQpbICAxNzYu
MzI5NDcwXSAzMDIwMyBpcyAyN2U2NjAwMCENClsgIDE3Ni4zMzEzMzldIDMwMjA0IGlzIDI3
ZTY3MDAwIQ0KWyAgMTc2LjMzMzE3MV0gMzAyMDUgaXMgMjdlNjgwMDAhDQpbICAxNzYuMzM1
NDI2XSAzMDJkNiBpcyAyN2U0MTAwMCENClsgIDE3Ni4zMzcyNzRdIDMwMmQ3IGlzIDI3ZTQy
MDAwIQ0KWyAgMTc2LjMzOTA5NF0gMzAyZDggaXMgMjdlNDMwMDAhDQpbICAxNzYuMzQwODk0
XSAzMDJkOSBpcyAyN2U0NDAwMCENClsgIDE3Ni4zNDI2NzBdIDMwMmRhIGlzIDI3ZTQ1MDAw
IQ0KWyAgMTc2LjM0NDQ5Nl0gMzAyZGIgaXMgMjdlNDYwMDAhDQpbICAxNzYuMzQ2MjM1XSAz
MDJkYyBpcyAyN2U0NzAwMCENClsgIDE3Ni4zNDgwMTddIDMwMmRkIGlzIDI3ZTQ4MDAwIQ0K
WyAgMTc2LjM0OTc2OV0gMzAyZGUgaXMgMjdlNDkwMDAhDQpbICAxNzYuMzUxNTI1XSAzMDJk
ZiBpcyAyN2U0YTAwMCENClsgIDE3Ni4zNTMyNDVdIDMwMmUwIGlzIDI3ZTRiMDAwIQ0KWyAg
MTc2LjM1NDk5M10gMzAyZTEgaXMgMjdlM2EwMDAhDQpbICAxNzYuMzU2NzI5XSAzMDJlMiBp
cyAyN2UzYjAwMCENClsgIDE3Ni4zNTg0NDhdIDMwMmUzIGlzIDI3ZTNjMDAwIQ0KWyAgMTc2
LjM2MDE5OF0gMzAyZTQgaXMgMjdlM2QwMDAhDQpbICAxNzYuMzYxOTE4XSAzMDJlNSBpcyAy
N2UzZTAwMCENClsgIDE3Ni4zNjM2NDVdIDMwMmU2IGlzIDI3ZTNmMDAwIQ0KWyAgMTc2LjM2
NTMzNF0gMzAyZTcgaXMgMjdlNDAwMDAhDQpbICAxNzYuMzY3MDI3XSAzMDIwNiBpcyAyN2U1
NzAwMCENClsgIDE3Ni4zNjg3MjNdIDMwMjA3IGlzIDI3ZTU4MDAwIQ0KWyAgMTc2LjM3MDQw
NV0gMzAyMDggaXMgMjdlNTkwMDAhDQpbICAxNzYuMzcyMTA2XSAzMDIwOSBpcyAyN2U1YTAw
MCENClsgIDE3Ni4zNzM4MDVdIDMwMjBhIGlzIDI3ZTViMDAwIQ0KWyAgMTc2LjM3NTQ2MF0g
MzAyMGIgaXMgMjdlNWMwMDAhDQpbICAxNzYuMzc3MTM1XSAzMDIwYyBpcyAyN2U1ZDAwMCEN
ClsgIDE3Ni4zNzg3NzldIDMwMmM3IGlzIDI3ZTVlMDAwIQ0KWyAgMTc2LjM4MDQ0OF0gMzAy
YzggaXMgMjdlNWYwMDAhDQpbICAxNzYuMzgyMDkzXSAzMDJjOSBpcyAyN2U2MDAwMCENClsg
IDE3Ni4zODM3NjNdIDMwMmNhIGlzIDI3ZTYxMDAwIQ0KWyAgMTc2LjM4NTQzMF0gMzAyY2Ig
aXMgMjdlNGMwMDAhDQpbICAxNzYuMzg3MDkzXSAzMDJjYyBpcyAyN2U0ZDAwMCENClsgIDE3
Ni4zODg3NjFdIDMwMmNkIGlzIDI3ZTRlMDAwIQ0KWyAgMTc2LjM5MDQxM10gMzAyY2UgaXMg
MjdlNGYwMDAhDQpbICAxNzYuMzkyMDU4XSAzMDJjZiBpcyAyN2U1MDAwMCENClsgIDE3Ni4z
OTM3NDVdIDMwMmQwIGlzIDI3ZTUxMDAwIQ0KWyAgMTc2LjM5NTQxMl0gMzAyZDEgaXMgMjdl
NTIwMDAhDQpbICAxNzYuMzk3MTEwXSAzMDJkMiBpcyAyN2U1MzAwMCENClsgIDE3Ni4zOTg3
NzFdIDMwMmQzIGlzIDI3ZTU0MDAwIQ0KWyAgMTc2LjQwMDQ2N10gMzAyZDQgaXMgMjdlNTUw
MDAhDQpbICAxNzYuNDAyMTQxXSAzMDJkNSBpcyAyN2U1NjAwMCENClsgIDE3Ni40MDUwMDZd
IDMwMmVhIGlzIDI3ZTJmMDAwIQ0KWyAgMTc2LjQwNjkyMV0gMzAyZWIgaXMgMjdlMzAwMDAh
DQpbICAxNzYuNDA4NjA3XSAzMDJlYyBpcyAyN2UzMTAwMCENClsgIDE3Ni40MTAzMjBdIDMw
MmVkIGlzIDI3ZTMyMDAwIQ0KWyAgMTc2LjQxMjAwN10gMzAyZWUgaXMgMjdlMzMwMDAhDQpb
ICAxNzYuNDEzNzI2XSAzMDJlZiBpcyAyN2UzNDAwMCENClsgIDE3Ni40MTU0MTBdIDMwMmYw
IGlzIDI3ZTM1MDAwIQ0KWyAgMTc2LjQxNzEzNV0gMzAyZjEgaXMgMjdlMzYwMDAhDQpbICAx
NzYuNDE4ODMxXSAzMDJmMiBpcyAyN2UzNzAwMCENClsgIDE3Ni40MjA1MjldIDMwMmYzIGlz
IDI3ZTM4MDAwIQ0KWyAgMTc2LjQyMjIyNl0gMzAyZjQgaXMgMjdlMzkwMDAhDQpbICAxNzYu
NDIzOTIyXSAzMDJmNSBpcyAyN2UyNDAwMCENClsgIDE3Ni40MjU2MDldIDMwMmY2IGlzIDI3
ZTI1MDAwIQ0KWyAgMTc2LjQyNzMwMl0gMzAyZjcgaXMgMjdlMjYwMDAhDQpbICAxNzYuNDI4
OTgxXSAzMDJmOCBpcyAyN2UyNzAwMCENClsgIDE3Ni40MzA2OTJdIDMwMmY5IGlzIDI3ZTI4
MDAwIQ0KWyAgMTc2LjQzMjM3N10gMzAyZmEgaXMgMjdlMjkwMDAhDQpbICAxNzYuNDM0MDgz
XSAzMDJmYiBpcyAyN2UyYTAwMCENClsgIDE3Ni40MzU3NTVdIDMwMmZjIGlzIDI3ZTJiMDAw
IQ0KWyAgMTc2LjQzNzQzNl0gMzAyZmQgaXMgMjdlMmMwMDAhDQpbICAxNzYuNDM5MTI1XSAz
MDJmZSBpcyAyN2UyZDAwMCENClsgIDE3Ni40NDA4MDZdIDMwMmZmIGlzIDI3ZTJlMDAwIQ0K
WyAgMTc2LjQ0MjU1Ml0gMzAzMjAgaXMgMjdkZmEwMDAhDQpbICAxNzYuNDQ0MjkwXSAzMDMy
MSBpcyAyN2RmYjAwMCENClsgIDE3Ni40NDYwMDFdIDMwMzIyIGlzIDI3ZGZjMDAwIQ0KWyAg
MTc2LjQ0Nzc0MF0gMzAzMjMgaXMgMjdkZmQwMDAhDQpbICAxNzYuNDQ5NDUwXSAzMDMyNCBp
cyAyN2RmZTAwMCENClsgIDE3Ni40NTExODBdIDMwMzI1IGlzIDI3ZGZmMDAwIQ0KWyAgMTc2
LjQ1Mjg3OF0gMzAzMjYgaXMgMjdlMDAwMDAhDQpbICAxNzYuNDU0NjA0XSAzMDMyNyBpcyAy
N2UwMTAwMCENClsgIDE3Ni40NTYyOTddIDMwMzI4IGlzIDI3ZTAyMDAwIQ0KWyAgMTc2LjQ1
Nzk5N10gMzAzMjkgaXMgMjdlMDMwMDAhDQpbICAxNzYuNDU5OTM1XSAzMDMwYSBpcyAyN2Uw
ZjAwMCENClsgIDE3Ni40NjE2MTddIDMwMzBiIGlzIDI3ZTEwMDAwIQ0KWyAgMTc2LjQ2MzI5
Nl0gMzAzMGMgaXMgMjdlMTEwMDAhDQpbICAxNzYuNDY0OTY4XSAzMDMwZCBpcyAyN2UxMjAw
MCENClsgIDE3Ni40NjY2MjNdIDMwMzBlIGlzIDI3ZTEzMDAwIQ0KWyAgMTc2LjQ2ODMxMF0g
MzAzMGYgaXMgMjdlMTQwMDAhDQpbICAxNzYuNDY5OTY5XSAzMDMxMCBpcyAyN2UxNTAwMCEN
ClsgIDE3Ni40NzE2NjJdIDMwMzExIGlzIDI3ZTE2MDAwIQ0KWyAgMTc2LjQ3MzMyOF0gMzAz
MTIgaXMgMjdlMTcwMDAhDQpbICAxNzYuNDc1MDA2XSAzMDMxMyBpcyAyN2UxODAwMCENClsg
IDE3Ni40NzY2ODZdIDMwMzE0IGlzIDI3ZTE5MDAwIQ0KWyAgMTc2LjQ3ODM2M10gMzAzMDAg
aXMgMjdlMWEwMDAhDQpbICAxNzYuNDgwMDY0XSAzMDMwMSBpcyAyN2UxYjAwMCENClsgIDE3
Ni40ODE3MzRdIDMwMzAyIGlzIDI3ZTFjMDAwIQ0KWyAgMTc2LjQ4MzQxN10gMzAzMDMgaXMg
MjdlMWQwMDAhDQpbICAxNzYuNDg1MDkyXSAzMDMwNCBpcyAyN2UxZTAwMCENClsgIDE3Ni40
ODY3NjldIDMwMzA1IGlzIDI3ZTFmMDAwIQ0KWyAgMTc2LjQ4ODQ0M10gMzAzMDYgaXMgMjdl
MjAwMDAhDQpbICAxNzYuNDkwMTI3XSAzMDMwNyBpcyAyN2UyMTAwMCENClsgIDE3Ni40OTE3
OTRdIDMwMzA4IGlzIDI3ZTIyMDAwIQ0KWyAgMTc2LjQ5MzQ5M10gMzAzMDkgaXMgMjdlMjMw
MDAhDQpbICAxNzYuNDk1MTQ4XSAzMDMxNSBpcyAyN2UwNDAwMCENClsgIDE3Ni40OTY4MjNd
IDMwMzE2IGlzIDI3ZTA1MDAwIQ0KWyAgMTc2LjQ5ODQ2N10gMzAzMTcgaXMgMjdlMDYwMDAh
DQpbICAxNzYuNTAwMTI1XSAzMDMxOCBpcyAyN2UwNzAwMCENClsgIDE3Ni41MDE3OTddIDMw
MzE5IGlzIDI3ZTA4MDAwIQ0KWyAgMTc2LjUwMzQ3M10gMzAzMWEgaXMgMjdlMDkwMDAhDQpb
ICAxNzYuNTA1MTUxXSAzMDMxYiBpcyAyN2UwYTAwMCENClsgIDE3Ni41MDY4MTNdIDMwMzFj
IGlzIDI3ZTBiMDAwIQ0KWyAgMTc2LjUwODQ2Ml0gMzAzMWQgaXMgMjdlMGMwMDAhDQpbICAx
NzYuNTEwMTQ0XSAzMDMxZSBpcyAyN2UwZDAwMCENClsgIDE3Ni41MTE4MTFdIDMwMzFmIGlz
IDI3ZTBlMDAwIQ0KWyAgMTc2LjUxNDg4MV0gMzAzMmEgaXMgMjdkZWYwMDAhDQpbICAxNzYu
NTE2NTY4XSAzMDJlOSBpcyAyN2RmMDAwMCENClsgIDE3Ni41MTgzMDJdIDMwMmU4IGlzIDI3
ZGYxMDAwIQ0KWyAgMTc2LjUyMDAxN10gMzAyYWMgaXMgMjdkZjIwMDAhDQpbICAxNzYuNTIx
NzY1XSAzMDJhZCBpcyAyN2RmMzAwMCENClsgIDE3Ni41MjM1MDZdIDMwMmFlIGlzIDI3ZGY0
MDAwIQ0KWyAgMTc2LjUyNTIwMl0gMzAyYWYgaXMgMjdkZjUwMDAhDQpbICAxNzYuNTI2OTM1
XSAzMDJiMCBpcyAyN2RmNjAwMCENClsgIDE3Ni41Mjg2MzNdIDMwMmIxIGlzIFsgIDE3OC42
NTk5NjJdIDJmZTM2IGlzIDI4MjdhMDAwIQ0KWyAgMTc4LjY2MjE1Nl0gMmZlMzcgaXMgMjgy
NzkwMDAhDQpbICAxNzguNjY0NDY1XSAyZmUzOCBpcyAyODI3ODAwMCENClsgIDE3OC42NjY2
NDFdIDJmZTM5IGlzIDI4Mjc3MDAwIQ0KWyAgMTc4LjY2OTAwNF0gMmZlM2EgaXMgMjgyNzYw
MDAhDQpbICAxNzguNjcxMjgxXSAyZmUzYiBpcyAyODI3NTAwMCENClsgIDE3OC42NzM1MjZd
IDJmZTNjIGlzIDI4Mjc0MDAwIQ0KWyAgMTc4LjY4MTIzNV0gMmZlM2QgaXMgMjgyNzMwMDAh
DQpbICAxNzguNjkxOTkyXSAyZmUzZSBpcyAyODI3MjAwMCENClsgIDE3OC43MDI5NTldIDJm
ZTNmIGlzIDI4MjcxMDAwIQ0KWyAgMTc4LjcwNTI4OV0gMmZlNDAgaXMgMjgyNzAwMDAhDQpb
ICAxNzguNzA3NTkxXSAyZmU0MSBpcyAyODI2ZjAwMCENClsgIDE3OC43NDI4NTldIDJmZTQy
IGlzIDI4MjZlMDAwIQ0KWyAgMTc4Ljc0NTE5Ml0gMmZlNDMgaXMgMjgyNmQwMDAhDQpbICAx
NzguNzQ3NDg5XSAyZmU0NCBpcyAyODI2YzAwMCENClsgIDE3OC43NDk2NjJdIDJmZTQ1IGlz
IDI4MjZiMDAwIQ0KWyAgMTc4Ljc1MjAzMF0gMmZlNDYgaXMgMjgyNmEwMDAhDQpbICAxNzgu
NzU2MDQzXSAyZmU0NyBpcyAyODI2OTAwMCENClsgIDE3OC43NTgzMzhdIDJmZTJhIGlzIDI4
MjY4MDAwIQ0KWyAgMTc4Ljc2MDYyM10gMmZlNDggaXMgMjgyNjcwMDAhDQpbICAxNzguNzYy
ODAyXSAyZmU0OSBpcyAyODI2NjAwMCENClsgIDE3OC43NjUxNzFdIDJmZTRhIGlzIDI4MjY1
MDAwIQ0KWyAgMTc4Ljc2NzQ1MF0gMmZlNGIgaXMgMjgyNjQwMDAhDQpbICAxNzguNzY5NjQy
XSAyZmU0YyBpcyAyODI2MzAwMCENClsgIDE3OC43NzE5ODhdIDJmZTRkIGlzIDI4MjYyMDAw
IQ0KWyAgMTc4Ljc3NDI1MF0gMmZlNGUgaXMgMjgyNjEwMDAhDQpbICAxNzguNzc2NDE5XSAy
ZmU0ZiBpcyAyODI2MDAwMCENClsgIDE3OC43Nzg3MjZdIDJmZTUwIGlzIDI4MjVmMDAwIQ0K
WyAgMTc4Ljc4MDk2NV0gMmZlNTEgaXMgMjgyNWUwMDAhDQpbICAxNzguNzgzMDg3XSAyZmU1
MiBpcyAyODI1ZDAwMCENClsgIDE3OC43ODU0MTZdIDJmZTUzIGlzIDI4MjVjMDAwIQ0KWyAg
MTc4Ljc4NzYyMF0gMmZlNTQgaXMgMjgyNWIwMDAhDQpbICAxNzguNzg5NzY1XSAyZmU1NSBp
cyAyODI1YTAwMCENClsgIDE3OC43OTIwNTldIDJmZTU2IGlzIDI4MjU5MDAwIQ0KWyAgMTc4
Ljc5NDI3OF0gMmZlNTcgaXMgMjgyNTgwMDAhDQpbICAxNzguNzk2Mzg2XSAyZmU1OSBpcyAy
ODI1NzAwMCENClsgIDE3OC44MDQwMTRdIDJmZTVhIGlzIDI4MjU2MDAwIQ0KWyAgMTc4Ljgx
NzEyOF0gMmZlNWIgaXMgMjgyNTUwMDAhDQpbICAxNzguODE5MzEzXSAyZmUyYiBpcyAyODI1
NDAwMCENClsgIDE3OC44MjE2MzhdIDJmZTVjIGlzIDI4MjUzMDAwIQ0KWyAgMTc4LjgzMDI1
M10gMmZlNWQgaXMgMjgyNTIwMDAhDQpbICAxNzguODMyNDE1XSAyZmU1ZSBpcyAyODI1MTAw
MCENClsgIDE3OC44MzQ3NDldIDJmZTVmIGlzIDI4MjUwMDAwIQ0KWyAgMTc4LjgzNjkwN10g
MmZlNjAgaXMgMjgyNGYwMDAhDQpbICAxNzguODM5MDg2XSAyZmU2MSBpcyAyODI0ZTAwMCEN
ClsgIDE3OC44NDEyMjNdIDJmZTYyIGlzIDI4MjRkMDAwIQ0KWyAgMTc4Ljg0OTk3MF0gMmZl
MmMgaXMgMjgyNGMwMDAhDQpbICAxNzguODUyMjg0XSAyZmU2MyBpcyAyODI0YjAwMCENClsg
IDE3OC44NTQ1NjFdIDJmZTY0IGlzIDI4MjRhMDAwIQ0KWyAgMTc4Ljg1NzEyN10gMmZlNjUg
aXMgMjgyNDgwMDAhDQpbICAxNzguODc5OTkxXSAyZmU2NiBpcyAyODI0NzAwMCENClsgIDE3
OC45MDE2ODFdIDJmZTJkIGlzIDI4MjQ2MDAwIQ0KWyAgMTc4LjkxMzgzMV0gMmZlMmUgaXMg
MjgyNDUwMDAhDQpbICAxNzguOTIzNzQyXSAyZmU2NyBpcyAyODI0NDAwMCENClsgIDE3OC45
MjU5MTddIDJmZTY4IGlzIDI4MjQzMDAwIQ0KWyAgMTc4LjkzNzM1Nl0gMmZlNjkgaXMgMjgy
NDIwMDAhDQpbICAxNzguOTM5NTY1XSAyZmU2YSBpcyAyODI0MTAwMCENClsgIDE3OC45NDYy
MzldIDJmZTZiIGlzIDI4MjQwMDAwIQ0KWyAgMTc4Ljk0ODU0N10gMmZlMmYgaXMgMjgyM2Yw
MDAhDQpbICAxNzguOTc4NDk0XSAyZmU2YyBpcyAyODIzZTAwMCENClsgIDE3OC45ODA4MTRd
IDJmZTMwIGlzIDI4MjNkMDAwIQ0KWyAgMTc4Ljk4Mjk4OF0gMmZlNmQgaXMgMjgyM2MwMDAh
DQpbICAxNzguOTg1Mzc0XSAyZmU2ZSBpcyAyODIzYjAwMCENClsgIDE3OC45ODc2NjJdIDJm
ZTZmIGlzIDI4MjNhMDAwIQ0KWyAgMTc4Ljk4OTg4NF0gMmZlNzAgaXMgMjgyMzkwMDAhDQpb
ICAxNzguOTkyMjczXSAyZmU3MSBpcyAyODIzODAwMCENClsgIDE3OC45OTQ1ODBdIDJmZTcy
IGlzIDI4MjM3MDAwIQ0KWyAgMTc4Ljk5NjgxN10gMmZlNzMgaXMgMjgyMzYwMDAhDQpbICAx
NzguOTk5MDA5XSAyZmU3NCBpcyAyODIzNTAwMCENClsgIDE3OS4wMDEyNjFdIDJmZTc1IGlz
IDI4MjM0MDAwIQ0KWyAgMTc5LjAwMzQ5Ml0gMmZlNzYgaXMgMjgyMzMwMDAhDQpbICAxNzku
MDA1NzEyXSAyZmU3NyBpcyAyODIzMjAwMCENClsgIDE3OS4wMDc5NDVdIDJmZTc4IGlzIDI4
MjMxMDAwIQ0KWyAgMTc5LjAxMDE3MF0gMmZlNzkgaXMgMjgyMzAwMDAhDQpbICAxNzkuMDEy
MzQ1XSAyZmU3YSBpcyAyODIyZjAwMCENClsgIDE3OS4wMTQ1NjhdIDJmZTdiIGlzIDI4MjJl
MDAwIQ0KWyAgMTc5LjAxOTg4MF0gMmZlN2MgaXMgMjgyMmQwMDAhDQpbICAxNzkuMDIzNjk0
XSAyZmUzMSBpcyAyODFmZjAwMCENClsgIDE3OS4wMjU5MThdIDJmZTMyIGlzIDI4MjAwMDAw
IQ0KWyAgMTc5LjAyODA4Nl0gMmZlN2QgaXMgMjgyMDEwMDAhDQpbICAxNzkuMDMwMjYyXSAy
ZmU5MCBpcyAyODIwMjAwMCENClsgIDE3OS4wMzI1NzRdIDJmZTdlIGlzIDI4MjAzMDAwIQ0K
WyAgMTc5LjAzNDgyMV0gMmZlOTEgaXMgMjgyMDQwMDAhDQpbICAxNzkuMDM2OTU0XSAyZmU3
ZiBpcyAyODIwNTAwMCENClsgIDE3OS4wNDMwNDNdIDJmZTgwIGlzIDI4MjA2MDAwIQ0KWyAg
MTc5LjA0NTMyM10gMmZlOTIgaXMgMjgyMDcwMDAhDQpbICAxNzkuMDQ3NTU5XSAyZmU5MyBp
cyAyODIwODAwMCENClsgIDE3OS4wNTQ4ODhdIDJmZTk0IGlzIDI4MjA5MDAwIQ0KWyAgMTc5
LjA1NzEzMF0gMmZlODEgaXMgMjgyMGEwMDAhDQpbICAxNzkuMDU5MzYxXSAyZmU4MiBpcyAy
ODIwYjAwMCENClsgIDE3OS4wNjE2OTVdIDJmZTgzIGlzIDI4MjEyMDAwIQ0KWyAgMTc5LjA2
Mzk5Nl0gMmZlODQgaXMgMjgyMjkwMDAhDQpbICAxNzkuMDY2MTg2XSAyZmU4NSBpcyAyODIy
YTAwMCENClsgIDE3OS4wNjg1MjNdIDJmZTg2IGlzIDI4MjI4MDAwIQ0KWyAgMTc5LjA3MDc4
M10gMmZlODcgaXMgMjgyMjcwMDAhDQpbICAxNzkuMDcyOTg0XSAyZmU4OCBpcyAyODIyMTAw
MCENClsgIDE3OS4wNzUyNzNdIDJmZTg5IGlzIDI4MjFjMDAwIQ0KWyAgMTc5LjA3NzU0NF0g
MmZlOGEgaXMgMjgyMWIwMDAhDQpbICAxNzkuMDc5NzA1XSAyZmU4YiBpcyAyODIxYTAwMCEN
ClsgIDE3OS4wODIwMDhdIDJmZThjIGlzIDI4MjE5MDAwIQ0KWyAgMTc5LjA4NDI4NF0gMmZl
OGQgaXMgMjgyMTcwMDAhDQpbICAxNzkuMDg2NDI5XSAyZmU4ZSBpcyAyODIyYzAwMCENClsg
IDE3OS4wODg3NzVdIDJmZThmIGlzIDI4MjE1MDAwIQ0KWyAgMTc5LjA5MDk5N10gMmZlYWYg
aXMgMjgyMTEwMDAhDQpbICAxNzkuMTAyODAwXSAyZmViMCBpcyAyODIwYzAwMCENClsgIDE3
OS4xMDUxNDBdIDJmZTk1IGlzIDI4MjBkMDAwIQ0KWyAgMTc5LjEwNzQzOF0gMmZlYjEgaXMg
MjgyMTYwMDAhDQpbICAxNzkuMTA5Njc2XSAyZmViMiBpcyAyODIyYjAwMCENClsgIDE3OS4x
MTIwNTldIDJmZWIzIGlzIDI4MjEzMDAwIQ0KWyAgMTc5LjExNDM5NF0gMmZlYjQgaXMgMjgy
MTQwMDAhDQpbICAxNzkuMTE2NTc0XSAyZmViNSBpcyAyODM4YTAwMCENClsgIDE3OS4xMTg5
NjBdIDJmZWI2IGlzIDI4MjIyMDAwIQ0KWyAgMTc5LjEyMTI3MV0gMmZlYjcgaXMgMjgyMjMw
MDAhDQpbICAxNzkuMTIzNDg5XSAyZmViOCBpcyAyN2ViNjAwMCENClsgIDE3OS4xMjU3MTFd
IDJmZWI5IGlzIDI4Mzk4MDAwIQ0KWyAgMTc5LjEyNzk4Ml0gMmZlYmEgaXMgMjgxNGEwMDAh
DQpbICAxNzkuMTMwMTc3XSAyZmViYiBpcyAyODIxMDAwMCENClsgIDE3OS4xMzI1MjBdIDJm
ZWJjIGlzIDI4NDUyMDAwIQ0KWyAgMTc5LjEzNDgwM10gMmZlOTYgaXMgMjg0MmMwMDAhDQpb
ICAxNzkuMTM3MDQyXSAyZmViZCBpcyAyODQyYjAwMCENClsgIDE3OS4xMzkyOTRdIDJmZWJl
IGlzIDI4MjIwMDAwIQ0KWyAgMTc5LjE0MTY1OF0gMmZlYmYgaXMgMjgyMWYwMDAhDQpbICAx
NzkuMTQzOTkxXSAyZmVjMCBpcyAyODIxZTAwMCENClsgIDE3OS4xNDYyMjhdIDJmZWMxIGlz
IDI4MjFkMDAwIQ0KWyAgMTc5LjE0ODU4MV0gMmZlYzIgaXMgMjgxZmMwMDAhDQpbICAxNzku
MTUwOTE4XSAyZmVjMyBpcyAyODFmYjAwMCENClsgIDE3OS4xNjA0OTddIDJmZWM0IGlzIDI4
MWZhMDAwIQ0KWyAgMTc5LjE2MjkxNV0gMmZlOTcgaXMgMjgxZjkwMDAhDQpbICAxNzkuMTc0
ODUzXSAyZmVjNSBpcyAyODFmODAwMCENClsgIDE3OS4xNzcyOTddIDJmZWM2IGlzIDI4MWY3
MDAwIQ0KWyAgMTc5LjE3OTU4OF0gMmZlYzcgaXMgMjgxZjYwMDAhDQpbICAxNzkuMTkxMjM3
XSAyZmVjOCBpcyAyODFmNTAwMCENClsgIDE3OS4xOTM2MTZdIDJmZTk4IGlzIDI4MWY0MDAw
IQ0KWyAgMTc5LjE5NjAzNF0gMmZlYzkgaXMgMjgxZjMwMDAhDQpbICAxNzkuMTk4MzUyXSAy
ZmU5OSBpcyAyODFmMjAwMCENClsgIDE3OS4yMDA2NTldIDJmZWNhIGlzIDI4MWYxMDAwIQ0K
WyAgMTc5LjIwMjk0OF0gMmZlOWEgaXMgMjgxZjAwMDAhDQpbICAxNzkuMjEzNTczXSAyZmVj
YiBpcyAyODFlZjAwMCENClsgIDE3OS4yMTU4NjhdIDJmZTliIGlzIDI4MWVlMDAwIQ0KWyAg
MTc5LjIxODE2NF0gMmZlY2MgaXMgMjgxZWQwMDAhDQpbICAxNzkuMjIwNDU4XSAyZmU5YyBp
cyAyODFlYzAwMCENClsgIDE3OS4yMjI3NjFdIDJmZWNkIGlzIDI4MWViMDAwIQ0KWyAgMTc5
LjIyNTIyNV0gMmZlY2UgaXMgMjgxZWEwMDAhDQpbICAxNzkuMjI3NTgyXSAyZmVjZiBpcyAy
ODFlOTAwMCENClsgIDE3OS4yMzQzNjFdIDJmZWQwIGlzIDI4MWU4MDAwIQ0KWyAgMTc5LjIz
NzA5MV0gMmZlOWQgaXMgMjgxZTYwMDAhDQpbICAxNzkuMjM5MzQ4XSAyZmVkMSBpcyAyODFl
NTAwMCENClsgIDE3OS4yNDE1NjFdIDJmZWQyIGlzIDI4MWU0MDAwIQ0KWyAgMTc5LjI0Mzc5
Ml0gMmZlOWUgaXMgMjgxZTMwMDAhDQpbICAxNzkuMjQ2MDI4XSAyZmU5ZiBpcyAyODFlMjAw
MCENClsgIDE3OS4yNDgyODNdIDJmZWQzIGlzIDI4MWUxMDAwIQ0KWyAgMTc5LjI1MDU2MV0g
MmZlZDQgaXMgMjgxZTAwMDAhDQpbICAxNzkuMjUyNzQ3XSAyZmVkNSBpcyAyODFkZjAwMCEN
ClsgIDE3OS4yNTUwMjldIDJmZWQ2IGlzIDI4MWRlMDAwIQ0KWyAgMTc5LjI1NzI2M10gMmZl
ZDcgaXMgMjgxZGQwMDAhDQpbICAxNzkuMjY4MjA5XSAyZmVkOCBpcyAyODFkYzAwMCENClsg
IDE3OS4yNzA0MDhdIDJmZWEwIGlzIDI4MWRiMDAwIQ0KWyAgMTc5LjI3MjY1NV0gMmZlZDkg
aXMgMjgxZGEwMDAhDQpbICAxNzkuMjc1MDQwXSAyZmVkYSBpcyAyODFkOTAwMCENClsgIDE3
OS4yNzcxODZdIDJmZWExIGlzIDI4MWQ4MDAwIQ0KWyAgMTc5LjI3OTM3Nl0gMmZlYTIgaXMg
MjgxZDcwMDAhDQpbICAxNzkuMjgxNTk2XSAyZmVkYiBpcyAyODFkNjAwMCENClsgIDE3OS4y
ODM4NTRdIDJmZWRjIGlzIDI4MWQ1MDAwIQ0KWyAgMTc5LjI4NjAwNV0gMmZlZGQgaXMgMjgx
ZDQwMDAhDQpbICAxNzkuMjg4MjQwXSAyZmVkZSBpcyAyODFkMzAwMCENClsgIDE3OS4yOTAz
ODldIDJmZWRmIGlzIDI4MWQyMDAwIQ0KWyAgMTc5LjI5MjU3MF0gMmZlZTAgaXMgMjgxZDEw
MDAhDQpbICAxNzkuMjk0ODI5XSAyZmVlMSBpcyAyODFkMDAwMCENClsgIDE3OS4yOTY5NTRd
IDJmZWUyIGlzIDI4MWNmMDAwIQ0KWyAgMTc5LjI5OTE4NF0gMmZlZTMgaXMgMjgxY2UwMDAh
DQpbICAxNzkuMzAxMzY5XSAyZmVhMyBpcyAyODFjZDAwMCENClsgIDE3OS4zMDM1MjRdIDJm
ZWU0IGlzIDI4MWNjMDAwIQ0KWyAgMTc5LjMxMTE1MF0gMmZlZTUgaXMgMjgxY2IwMDAhDQpb
ICAxNzkuMzEzMzQzXSAyZmVhNCBpcyAyODFjYTAwMCENClsgIDE3OS4zMTU2NDVdIDJmZWU2
IGlzIDI4MWM5MDAwIQ0KWyAgMTc5LjMxNzkzMV0gMmZlZTcgaXMgMjgxYzgwMDAhDQpbICAx
NzkuMzIwNDEzXSAyZmVlOSBpcyAyODFjNjAwMCENClsgIDE3OS4zMjI1OTddIDJmZWVhIGlz
IDI4MWM1MDAwIQ0KWyAgMTc5LjMyNDY5OF0gMmZlZWIgaXMgMjgxYzQwMDAhDQpbICAxNzku
MzI2ODkyXSAyZmVhNSBpcyAyODFjMzAwMCENClsgIDE3OS4zMjkwMjBdIDJmZWVjIGlzIDI4
MWMyMDAwIQ0KWyAgMTc5LjMzMTIwNl0gMmZlZWQgaXMgMjgxYzEwMDAhDQpbICAxNzkuMzQx
OTAyXSAyZmVlZSBpcyAyODFjMDAwMCENClsgIDE3OS4zNDQxNDldIDJmZWVmIGlzIDI4MWJm
MDAwIQ0KWyAgMTc5LjM0NjQyMV0gMmZlZjAgaXMgMjgxYmUwMDAhDQpbICAxNzkuMzQ4NzAx
XSAyZmVmMSBpcyAyODFiZDAwMCENClsgIDE3OS4zNTA5NDhdIDJmZWYyIGlzIDI4MWJjMDAw
IQ0KWyAgMTc5LjM1MzA3Nl0gMmZlZjMgaXMgMjgxYmIwMDAhDQpbICAxNzkuMzU1NDAwXSAy
ZmVmNCBpcyAyODFiYTAwMCENClsgIDE3OS4zNTc2MjddIDJmZWY1IGlzIDI4MWI5MDAwIQ0K
WyAgMTc5LjM1OTc3Ml0gMmZlZjYgaXMgMjgxYjgwMDAhDQpbICAxNzkuMzYyMDU2XSAyZmVm
NyBpcyAyODFiNzAwMCENClsgIDE3OS4zNjQzMTZdIDJmZWY4IGlzIDI4MWI2MDAwIQ0KWyAg
MTc5LjM2NjQxN10gMmZlZjkgaXMgMjgxYjUwMDAhDQpbICAxNzkuNDEyMzk3XSAyZmVmYSBp
cyAyODFiNDAwMCENClsgIDE3OS40MTQ2MjBdIDJmZWE2IGlzIDI4MWIzMDAwIQ0KWyAgMTc5
LjQxNzExMl0gMmZlZmIgaXMgMjgxYjEwMDAhDQpbICAxNzkuNDE5MjMxXSAyZmVmYyBpcyAy
ODFiMDAwMCENClsgIDE3OS40MjEzNDVdIDJmZWZkIGlzIDI4MWFmMDAwIQ0KWyAgMTc5LjQy
MzUxM10gMmZlYTcgaXMgMjgxYWUwMDAhDQpbICAxNzkuNDI1NjcyXSAyZmVmZSBpcyAyODFh
ZDAwMCENClsgIDE3OS40Mjc4NjFdIDJmZWZmIGlzIDI4MWFjMDAwIQ0KWyAgMTc5LjQzMDAx
NV0gMmZmMDAgaXMgMjgxYWIwMDAhDQpbICAxNzkuNDMyMjEwXSAyZmYwMSBpcyAyODFhYTAw
MCENClsgIDE3OS40MzQ0MDRdIDJmZjAyIGlzIDI4MWE5MDAwIQ0KWyAgMTc5LjQzNjUyM10g
MmZmMDMgaXMgMjgxYTgwMDAhDQpbICAxNzkuNDM4NzE3XSAyZmYwNCBpcyAyODFhNzAwMCEN
ClsgIDE3OS40NDA4ODddIDJmZjA1IGlzIDI4MWE2MDAwIQ0KWyAgMTc5LjQ0MzAyNV0gMmZm
MDYgaXMgMjgxYTUwMDAhDQpbICAxNzkuNDQ1MTk2XSAyZmYwNyBpcyAyODFhNDAwMCENClsg
IDE3OS40NTA0MTFdIDJmZjA4IGlzIDI4MWEzMDAwIQ0KWyAgMTc5LjQ2OTc3M10gMmZmMDkg
aXMgMjgxOTgwMDAhDQpbICAxNzkuNDcxNzM3XSAyZmYwYSBpcyAyODE5OTAwMCENClsgIDE3
OS40NzM0OTddIDJmZjBiIGlzIDI4MTlhMDAwIQ0KWyAgMTc5LjQ3NTI2M10gMmZmMGMgaXMg
MjgxOWIwMDAhDQpbICAxNzkuNDc3MDI5XSAyZmYwZCBpcyAyODE5YzAwMCENClsgIDE3OS40
Nzg3MTFdIDJmZjBlIGlzIDI4MTlkMDAwIQ0KWyAgMTc5LjQ4MDQ0Nl0gMmZmMGYgaXMgMjgx
OWUwMDAhDQpbICAxNzkuNDgyMTMzXSAyZmYxMCBpcyAyODE5ZjAwMCENClsgIDE3OS40ODM4
NzJdIDJmZjExIGlzIDI4MWEwMDAwIQ0KWyAgMTc5LjQ4NTU3M10gMmZmMTIgaXMgMjgxYTEw
MDAhDQpbICAxNzkuNDg3MzEwXSAyZmYxMyBpcyAyODFhMjAwMCENClsgIDE3OS40ODkwNjld
IDJmZjFmIGlzIDI4OTgzMDAwIQ0KWyAgMTc5LjQ5MDgxMF0gMmZmMjAgaXMgMjg5ODQwMDAh
DQpbICAxNzkuNDkyNTY5XSAyZmYyMSBpcyAyODE4NTAwMCENClsgIDE3OS40OTQzMjJdIDJm
ZjIyIGlzIDI4MTg2MDAwIQ0KWyAgMTc5LjQ5NjA3OV0gMmZmMjMgaXMgMjgxODcwMDAhDQpb
ICAxNzkuNDk3ODIzXSAyZmYyNCBpcyAyODE4ODAwMCENClsgIDE3OS40OTk1NDJdIDJmZjI1
IGlzIDI4MTg5MDAwIQ0KWyAgMTc5LjUwMTI5Nl0gMmZmMjYgaXMgMjgxOGEwMDAhDQpbICAx
NzkuNTAzMDE4XSAyZmYyNyBpcyAyODE4YjAwMCENClsgIDE3OS41MDQ3NzVdIDJmZjI4IGlz
IDI4MThjMDAwIQ0KWyAgMTc5LjUwNjg1OF0gMmZmMjkgaXMgMjg5NzgwMDAhDQpbICAxNzku
NTA4NjA1XSAyZmYyYSBpcyAyODk3OTAwMCENClsgIDE3OS41MTAzNDddIDJmZjJiIGlzIDI4
OTdhMDAwIQ0KWyAgMTc5LjUxMjA3MF0gMmZmMmMgaXMgMjg5N2IwMDAhDQpbICAxNzkuNTEz
ODIwXSAyZmYyZCBpcyAyODk3YzAwMCENClsgIDE3OS41MTU1MzFdIDJmZjJlIGlzIDI4OTdk
MDAwIQ0KWyAgMTc5LjUxNzI4MF0gMmZmMmYgaXMgMjg5N2UwMDAhDQpbICAxNzkuNTE4OTg3
XSAyZmYzMCBpcyAyODk3ZjAwMCENClsgIDE3OS41MjA3NjNdIDJmZjMxIGlzIDI4OTgwMDAw
IQ0KWyAgMTc5LjUyMjQ5MV0gMmZmMzIgaXMgMjg5ODEwMDAhDQpbICAxNzkuNTI0MjE1XSAy
ZmYzMyBpcyAyODk4MjAwMCENClsgIDE3OS41MjU5NDRdIDJmZjM0IGlzIDI4OTZkMDAwIQ0K
WyAgMTc5LjUyNzY2MV0gMmZmMzUgaXMgMjg5NmUwMDAhDQpbICAxNzkuNTI5NDE2XSAyZmYz
NiBpcyAyODk2ZjAwMCENClsgIDE3OS41MzExMzJdIDJmZjM3IGlzIDI4OTcwMDAwIQ0KWyAg
MTc5LjUzMjg0NV0gMmZmMzggaXMgMjg5NzEwMDAhDQpbICAxNzkuNTM0NTk4XSAyZmYzOSBp
cyAyODk3MjAwMCENClsgIDE3OS41MzYzMDVdIDJmZjNhIGlzIDI4OTczMDAwIQ0KWyAgMTc5
LjUzODA0N10gMmZmM2IgaXMgMjg5NzQwMDAhDQpbICAxNzkuNTM5NzQyXSAyZmYzYyBpcyAy
ODk3NTAwMCENClsgIDE3OS41NDE0NzZdIDJmZjNkIGlzIDI4OTc2MDAwIQ0KWyAgMTc5LjU0
MzE3N10gMmZmM2UgaXMgMjg5NzcwMDAhDQpbICAxNzkuNTQ0ODc2XSAyZmYzZiBpcyAyODk2
MzAwMCENClsgIDE3OS41NDY1NzRdIDJmZjQwIGlzIDI4OTY0MDAwIQ0KWyAgMTc5LjU0ODI1
NV0gMmZmNDEgaXMgMjg5NjUwMDAhDQpbICAxNzkuNTQ5OTQ4XSAyZmY0MiBpcyAyODk2NjAw
MCENClsgIDE3OS41NTE2MjldIDJmZjQzIGlzIDI4OTY3MDAwIQ0KWyAgMTc5LjU1MzMwMl0g
MmZmNDQgaXMgMjg5NjgwMDAhDQpbICAxNzkuNTU1MDE0XSAyZmY0NSBpcyAyODk2OTAwMCEN
ClsgIDE3OS41NTY2NzVdIDJmZjQ2IGlzIDI4OTZhMDAwIQ0KWyAgMTc5LjU1ODM3Nl0gMmZm
NDcgaXMgMjg5NmIwMDAhDQpbICAxNzkuNTYwMDMxXSAyZmY0OCBpcyAyODk2YzAwMCENClsg
IDE3OS41NjE2OTVdIDJmZjE0IGlzIDI4MThkMDAwIQ0KWyAgMTc5LjU2MzQwMl0gMmZmMTUg
aXMgMjgxOGUwMDAhDQpbICAxNzkuNTY1MDY0XSAyZmYxNiBpcyAyODE4ZjAwMCENClsgIDE3
OS41NjY3NjRdIDJmZjE3IGlzIDI4MTkwMDAwIQ0KWyAgMTc5LjU2ODQyNl0gMmZmMTggaXMg
MjgxOTEwMDAhDQpbICAxNzkuNTcwMTAzXSAyZmYxOSBpcyAyODE5MjAwMCENClsgIDE3OS41
NzE3OTZdIDJmZjFhIGlzIDI4MTkzMDAwIQ0KWyAgMTc5LjU3MzQ3N10gMmZmMWIgaXMgMjgx
OTQwMDAhDQpbICAxNzkuNTc1MTU4XSAyZmYxYyBpcyAyODE5NTAwMCENClsgIDE3OS41NzY4
MjddIDJmZjFkIGlzIDI4MTk2MDAwIQ0KWyAgMTc5LjU3ODQ4Ml0gMmZmMWUgaXMgMjgxOTcw
MDAhDQpbICAxNzkuNTkzODcxXSAyZmY0OSBpcyAyODk1ODAwMCENClsgIDE3OS41OTU1NzNd
IDJmZjRjIGlzIDI4OTU5MDAwIQ0KWyAgMTc5LjU5NzI2M10gMmZmNGQgaXMgMjg5NWEwMDAh
DQpbICAxNzkuNTk4OTEzXSAyZmY0ZSBpcyAyODk1YjAwMCENClsgIDE3OS42MDA2MDVdIDJm
ZjRmIGlzIDI4OTVjMDAwIQ0KWyAgMTc5LjYwMjI5MV0gMmZmNTAgaXMgMjg5NWQwMDAhDQpb
ICAxNzkuNjA0MDAwXSAyZmY1MSBpcyAyODk1ZTAwMCENClsgIDE3OS42MDU2NjRdIDJmZjUy
IGlzIDI4OTVmMDAwIQ0KWyAgMTc5LjYwNzM0OF0gMmZmNTMgaXMgMjg5NjAwMDAhDQpbICAx
NzkuNjA5MDQzXSAyZmY1NCBpcyAyODk2MTAwMCENClsgIDE3OS42MTA3MjddIDJmZjU1IGlz
IDI4OTYyMDAwIQ0KWyAgMTc5LjYxMjQyNV0gMmZmNTYgaXMgMjg5NGQwMDAhDQpbICAxNzku
NjE0MTE1XSAyZmY1NyBpcyAyODk0ZTAwMCENClsgIDE3OS42MTU3ODNdIDJmZjU4IGlzIDI4
OTRmMDAwIQ0KWyAgMTc5LjYxNzQ5Ml0gMmZmNTkgaXMgMjg5NTAwMDAhDQpbICAxNzkuNjE5
MTYwXSAyZmY1YSBpcyAyODk1MTAwMCENClsgIDE3OS42MjA4NzBdIDJmZjViIGlzIDI4OTUy
MDAwIQ0KWyAgMTc5LjYyMjUzOF0gMmZmNWMgaXMgMjg5NTMwMDAhDQpbICAxNzkuNjI0MjIz
XSAyZmY1ZCBpcyAyODk1NDAwMCENClsgIDE3OS42MjU5MjNdIDJmZjVlIGlzIDI4OTU1MDAw
IQ0KWyAgMTc5LjYyNzU5NV0gMmZmNWYgaXMgMjg5NTYwMDAhDQpbICAxNzkuNjI5MjY2XSAy
ZmY2MCBpcyAyODk1NzAwMCENClsgIDE3OS42MzA5MjRdIDJmZjYxIGlzIDI4OTQzMDAwIQ0K
WyAgMTc5LjYzMjU4MF0gMmZmNjIgaXMgMjg5NDQwMDAhDQpbICAxNzkuNjM0Mjc4XSAyZmY2
MyBpcyAyODk0NTAwMCENClsgIDE3OS42MzU5NDFdIDJmZjY0IGlzIDI4OTQ2MDAwIQ0KWyAg
MTc5LjYzNzYzNV0gMmZmNjUgaXMgMjg5NDcwMDAhDQpbICAxNzkuNjM5MjkxXSAyZmY2NiBp
cyAyODk0ODAwMCENClsgIDE3OS42NDA5NjFdIDJmZjY3IGlzIDI4OTQ5MDAwIQ0KWyAgMTc5
LjY0MjY0MV0gMmZmNjggaXMgMjg5NGEwMDAhDQpbICAxNzkuNjQ0MzA1XSAyZmY2OSBpcyAy
ODk0YjAwMCENClsgIDE3OS42NDU5ODFdIDJmZjZhIGlzIDI4OTRjMDAwIQ0KWyAgMTc5LjY0
NzcyNV0gMmZmNmIgaXMgMjg5NDIwMDAhDQpbICAxNzkuNjcyNDE4XSAyZmVhOCBpcyAyODk0
MTAwMCENClsgIDE3OS42NzcyMDRdIDJmZWE5IGlzIDI4OTQwMDAwIQ0KWyAgMTc5LjY4Mjg5
Ml0gMmZmNmMgaXMgMjg5M2YwMDAhDQpbICAxNzkuNjg2MTA0XSAyZmY2ZCBpcyAyODkzZTAw
MCENClsgIDE3OS42ODgzMzhdIDJmZjZlIGlzIDI4OTNkMDAwIQ0KWyAgMTc5LjY5NzUwNV0g
MmZmNmYgaXMgMjg5M2MwMDAhDQpbICAxNzkuNzAyNzcxXSAyZmY3MCBpcyAyODkzYjAwMCEN
ClsgIDE3OS43MDQ5MjhdIDJmZjcxIGlzIDI4OTNhMDAwIQ0KWyAgMTc5LjcxNDIzMF0gMmZm
NzIgaXMgMjg5MzkwMDAhDQpbICAxNzkuNzI2NDAwXSAyZmY3MyBpcyAyODkzODAwMCENClsg
IDE3OS43Mjg4NjNdIDJmZjc0IGlzIDI4OTM3MDAwIQ0KWyAgMTc5LjczMzQ2N10gMmZmNzUg
aXMgMjg5MzYwMDAhDQpbICAxNzkuNzM4ODA1XSAyZmY3NiBpcyAyODkzNTAwMCENClsgIDE3
OS43NTMwMjRdIDJmZWFhIGlzIDI4OTM0MDAwIQ0KWyAgMTc5Ljc3MjUwNV0gMmZlYWIgaXMg
Mjg5MzMwMDAhDQpbICAxNzkuNzc0NzgzXSAyZmY3NyBpcyAyODkzMjAwMCENClsgIDE3OS43
ODE5NjFdIDJmZjc5IGlzIDI4OTMxMDAwIQ0KWyAgMTc5Ljc4NjI4OF0gMmZmN2EgaXMgMjg5
MzAwMDAhDQpbICAxNzkuNzkxOTY5XSAyZmY3YiBpcyAyODkyZjAwMCENClsgIDE3OS43OTUz
MjFdIDJmZjdjIGlzIDI4OTJlMDAwIQ0KWyAgMTc5Ljc5NzYwNF0gMmZmN2QgaXMgMjg5MmQw
MDAhDQpbICAxNzkuODA1MTUwXSAyZmY3ZSBpcyAyODkyYzAwMCENClsgIDE3OS44MTY4NDBd
IDJmZjdmIGlzIDI4OTJiMDAwIQ0KWyAgMTc5LjgzMDUwOF0gMmZmODAgaXMgMjg5MmEwMDAh
DQpbICAxNzkuODMzODUxXSAyZmY4MSBpcyAyODkyOTAwMCENClsgIDE3OS44NDE0OTldIDJm
ZjgyIGlzIDI4OTI4MDAwIQ0KWyAgMTc5Ljg0Nzk0OF0gMmZmODMgaXMgMjg5MjcwMDAhDQpb
ICAxNzkuODUyOTUwXSAyZmY4NCBpcyAyODkyNjAwMCENClsgIDE3OS44NTYyODZdIDJmZjg1
IGlzIDI4OTI1MDAwIQ0KWyAgMTc5Ljg3NzQ3NV0gMmZmODYgaXMgMjg5MjQwMDAhDQpbICAx
NzkuODgwNzA5XSAyZmY4NyBpcyAyODkyMzAwMCENClsgIDE3OS44OTQ2MzhdIDJmZjg4IGlz
IDI4OTIyMDAwIQ0KWyAgMTc5Ljg5NjkwOF0gMmZmODkgaXMgMjg5MjEwMDAhDQpbICAxNzku
ODk5MTU0XSAyZmY4YSBpcyAyODkyMDAwMCENClsgIDE3OS45MDEzMjddIDJmZjhiIGlzIDI4
OTFmMDAwIQ0KWyAgMTc5LjkwMzU1N10gMzc2N2QgaXMgMjg5MWUwMDAhDQpbICAxNzkuOTA1
NzczXSAyZmY4ZCBpcyAyODkxZDAwMCENClsgIDE3OS45MTQwNjRdIDJmZjhlIGlzIDI4OTFj
MDAwIQ0KWyAgMTc5LjkxNjMxM10gMmZmNzggaXMgMjg5MWIwMDAhDQpbICAxNzkuOTE4NTIx
XSAyZmY4ZiBpcyAyODkxYTAwMCENClsgIDE3OS45MjA3NTRdIDM3ODExIGlzIDI4OTE5MDAw
IQ0KWyAgMTc5LjkyMzAxMF0gMmZlYWMgaXMgMjg5MTgwMDAhDQpbICAxNzkuOTI1Mjg3XSAy
ZmY5MCBpcyAyODkxNzAwMCENClsgIDE3OS45Mjc1NTZdIDJmZWFkIGlzIDI4OTE2MDAwIQ0K
WyAgMTc5LjkzODMzNl0gMmZlYWUgaXMgMjg5MTUwMDAhDQpbICAxNzkuOTQ2NDI3XSAyZmY5
MSBpcyAyODkxNDAwMCENClsgIDE3OS45NDg4NTRdIDJmZjkyIGlzIDI4OTEzMDAwIQ0KWyAg
MTc5Ljk1MTI2Ml0gMmZmOTMgaXMgMjg5MTIwMDAhDQpbICAxNzkuOTUzNTE3XSAyZmY5NCBp
cyAyODkxMTAwMCENClsgIDE3OS45NTU4ODVdIDJmZjk1IGlzIDI4OTEwMDAwIQ0KWyAgMTc5
Ljk1ODE4NF0gMmZmYWEgaXMgMjg5MGYwMDAhDQpbICAxNzkuOTYwNDUwXSAyZmY5NiBpcyAy
ODkwZTAwMCENClsgIDE3OS45NjI3NTFdIDJmZmFiIGlzIDI4OTBkMDAwIQ0KWyAgMTc5Ljk2
NTAwOV0gMmZmOTcgaXMgMjg5MGMwMDAhDQpbICAxNzkuOTY3Mjk0XSAyZmZhYyBpcyAyODkw
YjAwMCENClsgIDE3OS45NzIwODJdIDJmZmFkIGlzIDI4OTBhMDAwIQ0KWyAgMTc5Ljk3NDQw
Ml0gMmZmOTggaXMgMjg5MDkwMDAhDQpbICAxNzkuOTc2NjQ3XSAyZmY5OSBpcyAyODkwODAw
MCENClsgIDE3OS45NzkwNTRdIDJmZjlhIGlzIDI4OTA3MDAwIQ0KWyAgMTc5Ljk4MTM2MF0g
MmZmOWIgaXMgMjg5MDYwMDAhDQpbICAxNzkuOTgzNTg4XSAyZmY5YyBpcyAyODkwNTAwMFsg
IDE4Mi4xMjI2NTFdIDJmYTRiIGlzIDI4NWFmMDAwIQ0KWyAgMTgyLjEyNDkwNF0gMmZhNGMg
aXMgMjg1YjAwMDAhDQpbICAxODIuMTI3MTA2XSAyZmE1YyBpcyAyODViMTAwMCENClsgIDE4
Mi4xMjkzNjBdIDJmYTVkIGlzIDI4NWIyMDAwIQ0KWyAgMTgyLjEzMTU2NF0gMmZhNGQgaXMg
Mjg1YjMwMDAhDQpbICAxODIuMTMzNzU4XSAyZmE1ZSBpcyAyODViYTAwMCENClsgIDE4Mi4x
MzU5NTVdIDJmYTVmIGlzIDI4NWNlMDAwIQ0KWyAgMTgyLjEzODIyNl0gMmZhNGUgaXMgMjg1
Y2YwMDAhDQpbICAxODIuMTQwNDIzXSAyZmE0ZiBpcyAyODVjZDAwMCENClsgIDE4Mi4xNDI2
MzVdIDJmYTUwIGlzIDI4NWNjMDAwIQ0KWyAgMTgyLjE0NDk3Nl0gMmZhNTEgaXMgMjg1ZDIw
MDAhDQpbICAxODIuMTQ3MjcwXSAyZmE1MiBpcyAyODVkMzAwMCENClsgIDE4Mi4xNDk0MzRd
IDJmYTUzIGlzIDI4NWQ0MDAwIQ0KWyAgMTgyLjE1MTcxN10gMmZhNTQgaXMgMjg1ZDUwMDAh
DQpbICAxODIuMTUzOTEzXSAyZmE1NSBpcyAyODVjNTAwMCENClsgIDE4Mi4xNTYwNDNdIDJm
YTU2IGlzIDI4NWJmMDAwIQ0KWyAgMTgyLjE2NjczMl0gMmZhNzYgaXMgMjg1ZDEwMDAhDQpb
ICAxODIuMTY4ODk0XSAyZmE2MCBpcyAyODViZDAwMCENClsgIDE4Mi4xNzEyNDddIDJmYTc3
IGlzIDI4NWI5MDAwIQ0KWyAgMTgyLjE3Mzc4NV0gMmZhNzggaXMgMjg1YjUwMDAhDQpbICAx
ODIuMTc1OTY3XSAyZmE3OSBpcyAyODViZTAwMCENClsgIDE4Mi4xNzgwOTldIDJmYTdhIGlz
IDI4NWQwMDAwIQ0KWyAgMTgyLjE4MDIyNF0gMmZhNjEgaXMgMjg1YmIwMDAhDQpbICAxODIu
MTgyNDY4XSAyZmE3YiBpcyAyODViYzAwMCENClsgIDE4Mi4xODQ2NjNdIDJmYTYyIGlzIDI4
NzBmMDAwIQ0KWyAgMTgyLjE4Njg2MV0gMmZhN2MgaXMgMjg1YzcwMDAhDQpbICAxODIuMTg5
MDc2XSAyZmE3ZCBpcyAyODVjODAwMCENClsgIDE4Mi4xOTEyMzhdIDJmYTdlIGlzIDI4NWM2
MDAwIQ0KWyAgMTgyLjE5MzQ4NV0gMmZhNjMgaXMgMjg3MWQwMDAhDQpbICAxODIuMjAyMzg1
XSAyZmE4MCBpcyAyODM4MDAwMCENClsgIDE4Mi4yMDQ3MDRdIDJmYTgxIGlzIDI4NWI4MDAw
IQ0KWyAgMTgyLjIwNjk1OF0gMmZhODIgaXMgMjgzODEwMDAhDQpbICAxODIuMjA5MzAzXSAy
ZmE4MyBpcyAyODE0YjAwMCENClsgIDE4Mi4yMTE1NDhdIDJmYTdmIGlzIDI4NzFmMDAwIQ0K
WyAgMTgyLjIxODg3NF0gMmZhODQgaXMgMjg1YTIwMDAhDQpbICAxODIuMjI1NTkzXSAyZmE2
NCBpcyAyODVhMTAwMCENClsgIDE4Mi4yMjc4NjldIDJmYTY1IGlzIDI4NWM0MDAwIQ0KWyAg
MTgyLjIzMDIwNV0gMmZhNjYgaXMgMjg1YzMwMDAhDQpbICAxODIuMjMyNDkyXSAyZmE4NSBp
cyAyODVjMjAwMCENClsgIDE4Mi4yMzQ3OTJdIDJmYTg2IGlzIDI4NWMxMDAwIQ0KWyAgMTgy
LjIzNzEwNV0gMmZhNjcgaXMgMjg1YTAwMDAhDQpbICAxODIuMjQ3OTI0XSAyZmE4NyBpcyAy
ODU5ZjAwMCENClsgIDE4Mi4yNTAyODRdIDJmYTg4IGlzIDI4NTllMDAwIQ0KWyAgMTgyLjI1
MjY2N10gMmZhODkgaXMgMjg1OWQwMDAhDQpbICAxODIuMjU0OTgwXSAyZmE2OCBpcyAyODU5
YzAwMCENClsgIDE4Mi4yNTcyNDJdIDJmYThhIGlzIDI4NTliMDAwIQ0KWyAgMTgyLjI1OTU2
OF0gMmZhNjkgaXMgMjg1OWEwMDAhDQpbICAxODIuMjYyMjEzXSAyZmE4YiBpcyAyODU5ODAw
MCENClsgIDE4Mi4yNjQ0OTZdIDJmYTZiIGlzIDI4NTk3MDAwIQ0KWyAgMTgyLjI2Njg1NF0g
MmZhNmMgaXMgMjg1OTYwMDAhDQpbICAxODIuMjY5MTI4XSAyZmE4YyBpcyAyODU5NTAwMCEN
ClsgIDE4Mi4yNzE0NDddIDJmYThkIGlzIDI4NTk0MDAwIQ0KWyAgMTgyLjI4MTQ0NF0gMmZh
OGUgaXMgMjg1OTMwMDAhDQpbICAxODIuMzEwODQ2XSAyZmE4ZiBpcyAyODU5MjAwMCENClsg
IDE4Mi4zMTMxNDBdIDJmYTZkIGlzIDI4NTkxMDAwIQ0KWyAgMTgyLjMxNTU0NF0gMmZhOTAg
aXMgMjg1OTAwMDAhDQpbICAxODIuMzE3OTA0XSAyZmE5MSBpcyAyODU4ZjAwMCENClsgIDE4
Mi4zMjA1MjddIDJmYTkyIGlzIDI4NThkMDAwIQ0KWyAgMTgyLjMyMjc3NF0gMmZhOTMgaXMg
Mjg1OGMwMDAhDQpbICAxODIuMzMwMzE0XSAyZmE5NCBpcyAyODU4YjAwMCENClsgIDE4Mi4z
MzI1MzhdIDJmYTZlIGlzIDI4NThhMDAwIQ0KWyAgMTgyLjMzNDc1Ml0gMmZhOTUgaXMgMjg1
ODkwMDAhDQpbICAxODIuMzM2OTA1XSAyZmE2ZiBpcyAyODU4ODAwMCENClsgIDE4Mi4zMzkx
OTFdIDJmYTk2IGlzIDI4NTg3MDAwIQ0KWyAgMTgyLjM0MTQxNF0gMmZhNzAgaXMgMjg1ODYw
MDAhDQpbICAxODIuMzQzNjY4XSAyZmE5NyBpcyAyODU4NTAwMCENClsgIDE4Mi4zNDU5MTld
IDJmYTk4IGlzIDI4ZDg0MDAwIQ0KWyAgMTgyLjM0ODEwMF0gMmZhNzEgaXMgMjhkODMwMDAh
DQpbICAxODIuMzUwMjkxXSAyZmE5OSBpcyAyOGQ4MjAwMCENClsgIDE4Mi4zNTI1NDldIDJm
YTlhIGlzIDI4ZDgxMDAwIQ0KWyAgMTgyLjM1NDc1NV0gMmZhNzIgaXMgMjhkODAwMDAhDQpb
ICAxODIuMzU2ODYzXSAyZmE5YiBpcyAyOGQ3ZjAwMCENClsgIDE4Mi4zOTM1OTNdIDJmYTlj
IGlzIDI4ZDdlMDAwIQ0KWyAgMTgyLjM5NTgwMl0gMmZhNzMgaXMgMjhkN2QwMDAhDQpbICAx
ODIuMzk3OTYwXSAyZmE5ZCBpcyAyOGQ3YzAwMCENClsgIDE4Mi40MDAyMDFdIDJmYTc0IGlz
IDI4ZDdiMDAwIQ0KWyAgMTgyLjQwMjM5NF0gMmZhOWUgaXMgMjhkN2EwMDAhDQpbICAxODIu
NDA0NjA3XSAyZmE5ZiBpcyAyOGQ3OTAwMCENClsgIDE4Mi40MDY4MzZdIDJmYTc1IGlzIDI4
ZDc4MDAwIQ0KWyAgMTgyLjQwOTAzOV0gMmZhYTAgaXMgMjhkNzcwMDAhDQpbICAxODIuNDEx
Mjc1XSAyZmFhMSBpcyAyOGQ3NjAwMCENClsgIDE4Mi40MTM1MjBdIDJmYWEyIGlzIDI4ZDc1
MDAwIQ0KWyAgMTgyLjQxNTcxM10gMmZhYTMgaXMgMjhkNzQwMDAhDQpbICAxODIuNDE3OTcz
XSAyZmFhNCBpcyAyOGQ3MzAwMCENClsgIDE4Mi40MjAyMDRdIDJmYWE1IGlzIDI4ZDcyMDAw
IQ0KWyAgMTgyLjQyMjM4NV0gMmZhYTYgaXMgMjhkNzEwMDAhDQpbICAxODIuNDM5Mzc1XSAy
ZmFhNyBpcyAyOGQ2NjAwMCENClsgIDE4Mi40NDEzNjhdIDJmYWE4IGlzIDI4ZDY3MDAwIQ0K
WyAgMTgyLjQ0MzIwMl0gMmZhYTkgaXMgMjhkNjgwMDAhDQpbICAxODIuNDQ1MDg2XSAyZmFh
YSBpcyAyOGQ2OTAwMCENClsgIDE4Mi40NDY4NjBdIDJmYWFiIGlzIDI4ZDZhMDAwIQ0KWyAg
MTgyLjQ0ODYxMl0gMmZhYWMgaXMgMjhkNmIwMDAhDQpbICAxODIuNDUwNDExXSAyZmFhZCBp
cyAyOGQ2YzAwMCENClsgIDE4Mi40NTIxNDldIDJmYWFlIGlzIDI4ZDZkMDAwIQ0KWyAgMTgy
LjQ1MzkyN10gMmZhYWYgaXMgMjhkNmUwMDAhDQpbICAxODIuNDU1NjU1XSAyZmFiMCBpcyAy
OGQ2ZjAwMCENClsgIDE4Mi40NTc0MjJdIDJmYWIxIGlzIDI4ZDcwMDAwIQ0KWyAgMTgyLjQ1
OTIwM10gMmZhYjIgaXMgMjhkNWIwMDAhDQpbICAxODIuNDYwOTYxXSAyZmFiMyBpcyAyOGQ1
YzAwMCENClsgIDE4Mi40NjI3MDldIDJmYWI0IGlzIDI4ZDVkMDAwIQ0KWyAgMTgyLjQ2NDQ0
MV0gMmZhYjUgaXMgMjhkNWUwMDAhDQpbICAxODIuNDY2MTY3XSAyZmFiNiBpcyAyOGQ1ZjAw
MCENClsgIDE4Mi40Njc4OTFdIDJmYWI3IGlzIDI4ZDYwMDAwIQ0KWyAgMTgyLjQ2OTU5MV0g
MmZhYjggaXMgMjhkNjEwMDAhDQpbICAxODIuNDcxMzE1XSAyZmFiOSBpcyAyOGQ2MjAwMCEN
ClsgIDE4Mi40NzMwMDJdIDJmYWJhIGlzIDI4ZDYzMDAwIQ0KWyAgMTgyLjQ3NDcyMl0gMmZh
YmIgaXMgMjhkNjQwMDAhDQpbICAxODIuNDc2MzgwXSAyZmFiYyBpcyAyOGQ2NTAwMCENClsg
IDE4Mi40Nzg0NDVdIDJmYWJkIGlzIDI4ZDUxMDAwIQ0KWyAgMTgyLjQ4MDE0Nl0gMmZhYmUg
aXMgMjhkNTIwMDAhDQpbICAxODIuNDgxNzk5XSAyZmFiZiBpcyAyOGQ1MzAwMCENClsgIDE4
Mi40ODM0OTldIDJmYWMwIGlzIDI4ZDU0MDAwIQ0KWyAgMTgyLjQ4NTE0MF0gMmZhYzEgaXMg
MjhkNTUwMDAhDQpbICAxODIuNDg2ODI0XSAyZmFjMiBpcyAyOGQ1NjAwMCENClsgIDE4Mi40
ODg0NjZdIDJmYWMzIGlzIDI4ZDU3MDAwIQ0KWyAgMTgyLjQ5MDEzN10gMmZhYzQgaXMgMjhk
NTgwMDAhDQpbICAxODIuNDkxODEwXSAyZmFjNSBpcyAyOGQ1OTAwMCENClsgIDE4Mi40OTM0
NzVdIDJmYWM2IGlzIDI4ZDVhMDAwIQ0KWyAgMTgyLjQ5NTE0OF0gMmZhYzcgaXMgMjhkNDYw
MDAhDQpbICAxODIuNDk2ODE4XSAyZmFjOCBpcyAyOGQ0NzAwMCENClsgIDE4Mi40OTg0NjVd
IDJmYWM5IGlzIDI4ZDQ4MDAwIQ0KWyAgMTgyLjUwMDE1N10gMmZhY2EgaXMgMjhkNDkwMDAh
DQpbICAxODIuNTAxODE2XSAyZmFjYiBpcyAyOGQ0YTAwMCENClsgIDE4Mi41MDM1MThdIDJm
YWNjIGlzIDI4ZDRiMDAwIQ0KWyAgMTgyLjUwNTE2OV0gMmZhY2QgaXMgMjhkNGMwMDAhDQpb
ICAxODIuNTA2ODQwXSAyZmFjZSBpcyAyOGQ0ZDAwMCENClsgIDE4Mi41MDg1MjBdIDJmYWNm
IGlzIDI4ZDRlMDAwIQ0KWyAgMTgyLjUxMDE4Ml0gMmZhZDAgaXMgMjhkNGYwMDAhDQpbICAx
ODIuNTExODUxXSAyZmFkMSBpcyAyOGQ1MDAwMCENClsgIDE4Mi41MTM1MDldIDJmYWQyIGlz
IDI4ZDNiMDAwIQ0KWyAgMTgyLjUxNTE1Ml0gMmZhZDMgaXMgMjhkM2MwMDAhDQpbICAxODIu
NTE2ODM5XSAyZmFkNCBpcyAyOGQzZDAwMCENClsgIDE4Mi41MTg0ODNdIDJmYWQ1IGlzIDI4
ZDNlMDAwIQ0KWyAgMTgyLjUyMDE2N10gMmZhZDYgaXMgMjhkM2YwMDAhDQpbICAxODIuNTIx
ODExXSAyZmFkNyBpcyAyOGQ0MDAwMCENClsgIDE4Mi41MjM0ODZdIDJmYWQ4IGlzIDI4ZDQx
MDAwIQ0KWyAgMTgyLjUyNTE2N10gMmZhZDkgaXMgMjhkNDIwMDAhDQpbICAxODIuNTI2ODM1
XSAyZmFkYSBpcyAyOGQ0MzAwMCENClsgIDE4Mi41Mjg1MjJdIDJmYWRiIGlzIDI4ZDQ0MDAw
IQ0KWyAgMTgyLjUzMDE5OV0gMmZhZGMgaXMgMjhkNDUwMDAhDQpbICAxODIuNTMxODYxXSAy
ZmFkZCBpcyAyOGQzMTAwMCENClsgIDE4Mi41MzM1NjddIDJmYWRlIGlzIDI4ZDMyMDAwIQ0K
WyAgMTgyLjUzNTIyOF0gMmZhZGYgaXMgMjhkMzMwMDAhDQpbICAxODIuNTM2OTMzXSAyZmFl
MCBpcyAyOGQzNDAwMCENClsgIDE4Mi41Mzg2MDddIDJmYWUxIGlzIDI4ZDM1MDAwIQ0KWyAg
MTgyLjU0MDI5NF0gMmZhZTIgaXMgMjhkMzYwMDAhDQpbICAxODIuNTQxOTk3XSAyZmFlMyBp
cyAyOGQzNzAwMCENClsgIDE4Mi41NDM2NzhdIDJmYWU0IGlzIDI4ZDM4MDAwIQ0KWyAgMTgy
LjU0NTM3MF0gMmZhZTUgaXMgMjhkMzkwMDAhDQpbICAxODIuNTQ3MDQ1XSAyZmFlNiBpcyAy
OGQzYTAwMCENClsgIDE4Mi41NTAzMzNdIDJmYWZmIGlzIDI4ZDExMDAwIQ0KWyAgMTgyLjU1
MjA2M10gMmZiMDAgaXMgMjhkMTIwMDAhDQpbICAxODIuNTUzODExXSAyZmIwMSBpcyAyOGQx
MzAwMCENClsgIDE4Mi41NTU0OTVdIDJmYjAyIGlzIDI4ZDE0MDAwIQ0KWyAgMTgyLjU1NzE5
OF0gMmZiMDMgaXMgMjhkMTUwMDAhDQpbICAxODIuNTU4ODk5XSAyZmIwNCBpcyAyOGQxNjAw
MCENClsgIDE4Mi41NjA1OTddIDJmYjA1IGlzIDI4ZDE3MDAwIQ0KWyAgMTgyLjU2MjMwM10g
MmZiMDYgaXMgMjhkMTgwMDAhDQpbICAxODIuNTYzOTk4XSAyZmIwNyBpcyAyOGQxOTAwMCEN
ClsgIDE4Mi41NjU2ODldIDJmYjA4IGlzIDI4ZDFhMDAwIQ0KWyAgMTgyLjU2NzM3M10gMmZh
ZTcgaXMgMjhkMjYwMDAhDQpbICAxODIuNTY5MDY4XSAyZmFlOCBpcyAyOGQyNzAwMCENClsg
IDE4Mi41NzA3NjZdIDJmYWU5IGlzIDI4ZDI4MDAwIQ0KWyAgMTgyLjU3MjQzMl0gMmZhZWEg
aXMgMjhkMjkwMDAhDQpbICAxODIuNTc0MTI4XSAyZmFlYiBpcyAyOGQyYTAwMCENClsgIDE4
Mi41NzU3ODhdIDJmYWVjIGlzIDI4ZDJiMDAwIQ0KWyAgMTgyLjU3NzQ1Ml0gMmZhZWQgaXMg
MjhkMmMwMDAhDQpbICAxODIuNTc5MTE5XSAyZmFlZSBpcyAyOGQyZDAwMCENClsgIDE4Mi41
ODA3ODNdIDJmYWVmIGlzIDI4ZDJlMDAwIQ0KWyAgMTgyLjU4MjQ1M10gMmZhZjAgaXMgMjhk
MmYwMDAhDQpbICAxODIuNTg0MTI1XSAyZmFmMSBpcyAyOGQzMDAwMCENClsgIDE4Mi41ODU3
ODBdIDJmYWY0IGlzIDI4ZDFiMDAwIQ0KWyAgMTgyLjU4NzQ2N10gMmZhZjUgaXMgMjhkMWMw
MDAhDQpbICAxODIuNTg5MTI4XSAyZmFmNiBpcyAyOGQxZDAwMCENClsgIDE4Mi41OTA4MThd
IDJmYWY3IGlzIDI4ZDFlMDAwIQ0KWyAgMTgyLjU5MjQ3M10gMmZhZjggaXMgMjhkMWYwMDAh
DQpbICAxODIuNTk0MTQzXSAyZmFmOSBpcyAyOGQyMDAwMCENClsgIDE4Mi41OTU4MTZdIDJm
YWZhIGlzIDI4ZDIxMDAwIQ0KWyAgMTgyLjU5NzQ4Nl0gMmZhZmIgaXMgMjhkMjIwMDAhDQpb
ICAxODIuNTk5MTUwXSAyZmFmYyBpcyAyOGQyMzAwMCENClsgIDE4Mi42MDA4MjRdIDJmYWZk
IGlzIDI4ZDI0MDAwIQ0KWyAgMTgyLjYwMjQ5MV0gMmZhZmUgaXMgMjhkMjUwMDAhDQpbICAx
ODIuNjA1MTUwXSAyZmIxNCBpcyAyOGNmYjAwMCENClsgIDE4Mi42MDY4NjJdIDJmYjE1IGlz
IDI4Y2ZjMDAwIQ0KWyAgMTgyLjYwODU3N10gMmZiMTYgaXMgMjhjZmQwMDAhDQpbICAxODIu
NjEwMjc5XSAyZmIxNyBpcyAyOGNmZTAwMCENClsgIDE4Mi42MTIwMzldIDJmYjE4IGlzIDI4
Y2ZmMDAwIQ0KWyAgMTgyLjYxMzgwN10gMmZiMTkgaXMgMjhkMDAwMDAhDQpbICAxODIuNjE1
NTM5XSAyZmIxYSBpcyAyOGQwMTAwMCENClsgIDE4Mi42MTcyNDddIDJmYjFiIGlzIDI4ZDAy
MDAwIQ0KWyAgMTgyLjYxODk0M10gMmZiMWMgaXMgMjhkMDMwMDAhDQpbICAxODIuNjIwNjc1
XSAyZmIxZCBpcyAyOGQwNDAwMCENClsgIDE4Mi42MjIzNjNdIDJmYjFlIGlzIDI4ZDA1MDAw
IQ0KWyAgMTgyLjYyNDA3N10gMmZiMWYgaXMgMjhjZjEwMDAhDQpbICAxODIuNjI1Nzg1XSAy
ZmIyMCBpcyAyOGNmMjAwMCENClsgIDE4Mi42Mjc0OTFdIDJmYjIxIGlzIDI4Y2YzMDAwIQ0K
WyAgMTgyLjYyOTIyOF0gMmZiMjIgaXMgMjhjZjQwMDAhDQpbICAxODIuNjMwOTM0XSAyZmIy
MyBpcyAyOGNmNTAwMCENClsgIDE4Mi42MzI2NTRdIDJmYjI0IGlzIDI4Y2Y2MDAwIQ0KWyAg
MTgyLjYzNDM1OF0gMmZiMjUgaXMgMjhjZjcwMDAhDQpbICAxODIuNjM2MDM2XSAyZmIyNiBp
cyAyOGNmODAwMCENClsgIDE4Mi42Mzc3NTNdIDJmYjI3IGlzIDI4Y2Y5MDAwIQ0KWyAgMTgy
LjYzOTQyNl0gMmZiMjggaXMgMjhjZmEwMDAhDQpbICAxODIuNjQxMTM0XSAyZmIxMyBpcyAy
OGNlNjAwMCENClsgIDE4Mi42NDI4MThdIDJmYjEyIGlzIDI4Y2U3MDAwIQ0KWyAgMTgyLjY0
NDUxNl0gMmZiMTEgaXMgMjhjZTgwMDAhDQpbICAxODIuNjQ2MjIwXSAyZmIxMCBpcyAyOGNl
OTAwMCENClsgIDE4Mi42NDc5MTJdIDJmYjBmIGlzIDI4Y2VhMDAwIQ0KWyAgMTgyLjY0OTYy
Ml0gMmZiMGUgaXMgMjhjZWIwMDAhDQpbICAxODIuNjUxMzE2XSAyZmIwZCBpcyAyOGNlYzAw
MCENClsgIDE4Mi42NTMwMzFdIDJmYjBjIGlzIDI4Y2VkMDAwIQ0KWyAgMTgyLjY1NDczNV0g
MmZiMGIgaXMgMjhjZWUwMDAhDQpbICAxODIuNjU2NDA4XSAyZmIwYSBpcyAyOGNlZjAwMCEN
ClsgIDE4Mi42NTgxMTldIDJmYjA5IGlzIDI4Y2YwMDAwIQ0KWyAgMTgyLjY2MDY5OV0gMmZi
M2IgaXMgMjhjYzYwMDAhDQpbICAxODIuNjYyNDQxXSAyZmIzYSBpcyAyOGNjNzAwMCENClsg
IDE4Mi42NjQxMzddIDJmYjM5IGlzIDI4Y2M4MDAwIQ0KWyAgMTgyLjY2NTg0MV0gMmZiMzgg
aXMgMjhjYzkwMDAhDQpbICAxODIuNjY3NTQyXSAyZmIzNyBpcyAyOGNjYTAwMCENClsgIDE4
Mi42NjkyMjVdIDJmYjM2IGlzIDI4Y2NiMDAwIQ0KWyAgMTgyLjY3MDk0N10gMmZiMzUgaXMg
MjhjY2MwMDAhDQpbICAxODIuNjcyNjI5XSAyZmIzNCBpcyAyOGNjZDAwMCENClsgIDE4Mi42
NzQzNDNdIDJmYjMzIGlzIDI4Y2NlMDAwIQ0KWyAgMTgyLjY3NjAxNl0gMmZiMzIgaXMgMjhj
Y2YwMDAhDQpbICAxODIuNjc3NzAwXSAyZmIyOSBpcyAyOGNkMDAwMCENClsgIDE4Mi42Nzkz
OTBdIDJmYjNjIGlzIDI4Y2QxMDAwIQ0KWyAgMTgyLjY4MTA3Nl0gMmZiM2QgaXMgMjhjZDIw
MDAhDQpbICAxODIuNjgyNzgyXSAyZmIzZSBpcyAyOGNkMzAwMCENClsgIDE4Mi42ODQ0NjZd
IDJmYjNmIGlzIDI4Y2Q0MDAwIQ0KWyAgMTgyLjY4NjEzM10gMmZiNDAgaXMgMjhjZDUwMDAh
DQpbICAxODIuNjg3ODQ4XSAyZmI0MSBpcyAyOGNkNjAwMCENClsgIDE4Mi42ODk1NDddIDJm
YjQyIGlzIDI4Y2Q3MDAwIQ0KWyAgMTgyLjY5MTI0Nl0gMmZiNDMgaXMgMjhjZDgwMDAhDQpb
ICAxODIuNjkyOTEyXSAyZmI0NCBpcyAyOGNkOTAwMCENClsgIDE4Mi42OTQ2MDhdIDJmYjQ1
IGlzIDI4Y2RhMDAwIQ0KWyAgMTgyLjY5NzE0M10gMmZiNTMgaXMgMjhjYjEwMDAhDQpbICAx
ODIuNjk4OTUwXSAyZmI1NCBpcyAyOGNiMjAwMCENClsgIDE4Mi43MDA2NjRdIDJmYjU1IGlz
IDI4Y2IzMDAwIQ0KWyAgMTgyLjcwMjM1NV0gMmZiNTYgaXMgMjhjYjQwMDAhDQpbICAxODIu
NzA0MDgwXSAyZmI1NyBpcyAyOGNiNTAwMCENClsgIDE4Mi43MDU3NzldIDJmYjU4IGlzIDI4
Y2I2MDAwIQ0KWyAgMTgyLjcwNzUwMF0gMmZiNTkgaXMgMjhjYjcwMDAhDQpbICAxODIuNzA5
MjA0XSAyZmI1YSBpcyAyOGNiODAwMCENClsgIDE4Mi43MTA5MDBdIDJmYjViIGlzIDI4Y2I5
MDAwIQ0KWyAgMTgyLjcxMjYwMV0gMmZiNWMgaXMgMjhjYmEwMDAhDQpbICAxODIuNzE0Mjg0
XSAyZmI1MiBpcyAyOGNhNjAwMCENClsgIDE4Mi43MTU5NjhdIDJmYjUxIGlzIDI4Y2E3MDAw
IQ0KWyAgMTgyLjcxNzY0NV0gMmZiMzEgaXMgMjhjYTgwMDAhDQpbICAxODIuNzE5MzAzXSAy
ZmIzMCBpcyAyOGNhOTAwMCENClsgIDE4Mi43MjEwMDhdIDJmYjJmIGlzIDI4Y2FhMDAwIQ0K
WyAgMTgyLjcyMjY3OF0gMmZiMmUgaXMgMjhjYWIwMDAhDQpbICAxODIuNzI0Mzg2XSAyZmIy
ZCBpcyAyOGNhYzAwMCENClsgIDE4Mi43MjYwNDVdIDJmYjJjIGlzIDI4Y2FkMDAwIQ0KWyAg
MTgyLjcyNzcyM10gMmZiMmIgaXMgMjhjYWUwMDAhDQpbICAxODIuNzI5NDEzXSAyZmIyYSBp
cyAyOGNhZjAwMCENClsgIDE4Mi43MzEwNzldIDJmYjQ2IGlzIDI4Y2IwMDAwIQ0KWyAgMTgy
LjczNDQ2Nl0gMmZiNWUgaXMgMjhjNzEwMDAhDQpbICAxODIuNzM2MTk2XSAyZmI1ZiBpcyAy
OGM3MjAwMCENClsgIDE4Mi43Mzc4OTFdIDJmYjYwIGlzIDI4YzczMDAwIQ0KWyAgMTgyLjcz
OTU2MF0gMmZiNjEgaXMgMjhjNzQwMDAhDQpbICAxODIuNzQxMjY5XSAyZmI2MiBpcyAyOGM3
NTAwMCENClsgIDE4Mi43NDI5MzldIDJmYjYzIGlzIDI4Yzc2MDAwIQ0KWyAgMTgyLjc0NDYy
OV0gMmZiNjQgaXMgMjhjNzcwMDAhDQpbICAxODIuNzQ2Mjg1XSAyZmI2NSBpcyAyOGM3ODAw
MCENClsgIDE4Mi43NDc5NDldIDJmYjY2IGlzIDI4Yzc5MDAwIQ0KWyAgMTgyLjc0OTYzNF0g
MmZiNjcgaXMgMjhjN2EwMDAhDQpbICAxODIuNzUxMzAxXSAyZmI1MCBpcyAyOGM4NjAwMCEN
ClsgIDE4Mi43NTI5NjddIDJmYjRmIGlzIDI4Yzg3MDAwIQ0KWyAgMTgyLjc1NDY0NF0gMmZi
NGUgaXMgMjhjODgwMDAhDQpbICAxODIuNzU2MjkwXSAyZmI0ZCBpcyAyOGM4OTAwMCENClsg
IDE4Mi43NTc5NzFdIDJmYjRjIGlzIDI4YzhhMDAwIQ0KWyAgMTgyLjc1OTYxOV0gMmZiNGIg
aXMgMjhjOGIwMDAhDQpbICAxODIuNzYxMjk5XSAyZmI0YSBpcyAyOGM4YzAwMCENClsgIDE4
Mi43NjI5NDddIDJmYjQ5IGlzIDI4YzhkMDAwIQ0KWyAgMTgyLjc2NDYxOF0gMmZiNDggaXMg
MjhjOGUwMDAhDQpbICAxODIuNzY2Mjg3XSAyZmI0NyBpcyAyOGM4ZjAwMCENClsgIDE4Mi43
Njc5NjRdIDJmYjVkIGlzIDI4YzkwMDAwIQ0KWyAgMTgyLjc2OTY0OF0gMmZiN2EgaXMgMjhj
N2IwMDAhDQpbICAxODIuNzcxMzM2XSAyZmI3OSBpcyAyOGM3YzAwMCENClsgIDE4Mi43NzMw
MTRdIDJmYjc4IGlzIDI4YzdkMDAwIQ0KWyAgMTgyLjc3NDcyM10gMmZiNzcgaXMgMjhjN2Uw
MDAhDQpbICAxODIuNzc2Mzk1XSAyZmI3NiBpcyAyOGM3ZjAwMCENClsgIDE4Mi43NzgxMDRd
IDJmYjc1IGlzIDI4YzgwMDAwIQ0KWyAgMTgyLjc3OTc4OV0gMmZiNzQgaXMgMjhjODEwMDAh
DQpbICAxODIuNzgxNDg4XSAyZmI3MyBpcyAyOGM4MjAwMCENClsgIDE4Mi43ODMxODhdIDJm
YjcyIGlzIDI4YzgzMDAwIQ0KWyAgMTgyLjc4NDg4MV0gMmZiNzEgaXMgMjhjODQwMDAhDQpb
ICAxODIuNzg2NTUyXSAyZmI3MCBpcyAyOGM4NTAwMCENClsgIDE4Mi43ODkyMTVdIDJmYjky
IGlzIDI4YzViMDAwIQ0KWyAgMTgyLjc5MDk2MF0gMmZiOTMgaXMgMjhjNWMwMDAhDQpbICAx
ODIuNzkyNjQwXSAyZmI5NCBpcyAyOGM1ZDAwMCENClsgIDE4Mi43OTQzMjRdIDJmYjk1IGlz
IDI4YzVlMDAwIQ0KWyAgMTgyLjc5NjA4Nl0gMmZiOTYgaXMgMjhjNWYwMDAhDQpbICAxODIu
Nzk3Nzc2XSAyZmI5NyBpcyAyOGM2MDAwMCENClsgIDE4Mi43OTk0OTZdIDJmYjk4IGlzIDI4
YzYxMDAwIQ0KWyAgMTgyLjgwMTE4OF0gMmZiOTkgaXMgMjhjNjIwMDAhDQpbICAxODIuODAy
OTA0XSAyZmI5YSBpcyAyOGM2MzAwMCENClsgIDE4Mi44MDQ2MDVdIDJmYjliIGlzIDI4YzY0
MDAwIQ0KWyAgMTgyLjgwNjI4MV0gMmZiOWMgaXMgMjhjNjUwMDAhDQpbICAxODIuODA3OTc4
XSAyZmI5ZCBpcyAyOGM1MTAwMCENClsgIDE4Mi44MDk2NjBdIDJmYjllIGlzIDI4YzUyMDAw
IQ0KWyAgMTgyLjgxMTM1Nl0gMmZiOWYgaXMgMjhjNTMwMDAhDQpbICAxODIuOFsgIDE4NC45
NDA4ODhdIDJmNmI3IGlzIDI5MGYyMDAwIQ0KWyAgMTg0Ljk0MzE3MF0gMmY2YjggaXMgMjkw
ZjEwMDAhDQpbICAxODQuOTQ1NDU1XSAyZjZiOSBpcyAyOTBmMDAwMCENClsgIDE4NC45NDc3
MzBdIDJmNmJhIGlzIDI5MGVmMDAwIQ0KWyAgMTg0Ljk0OTk2Ml0gMmY2YmIgaXMgMjkwZWUw
MDAhDQpbICAxODQuOTUyMjE4XSAyZjZiYyBpcyAyOTBlZDAwMCENClsgIDE4NC45NTQ0ODBd
IDJmNmJkIGlzIDI5MGVjMDAwIQ0KWyAgMTg0Ljk1NjY5NV0gMmY2YmUgaXMgMjkwZWIwMDAh
DQpbICAxODQuOTU4OTczXSAyZjZiZiBpcyAyOTBlYTAwMCENClsgIDE4NC45NjEyMTldIDJm
NmMwIGlzIDI5MGU5MDAwIQ0KWyAgMTg0Ljk2MzQ4MV0gMmY2YzEgaXMgMjkwZTgwMDAhDQpb
ICAxODQuOTY1Njg1XSAyZjZjMiBpcyAyOTBlNzAwMCENClsgIDE4NC45NzQzNjZdIDJmNmMz
IGlzIDI5MGU2MDAwIQ0KWyAgMTg0Ljk3NjU0Nl0gMmY1ZGMgaXMgMjkwZTUwMDAhDQpbICAx
ODQuOTc4NzIwXSAyZjZjNCBpcyAyOTBlNDAwMCENClsgIDE4NC45ODA4NTBdIDJmNWRkIGlz
IDI5MGUzMDAwIQ0KWyAgMTg0Ljk4MzA3NV0gMmY1ZGUgaXMgMjkwZTIwMDAhDQpbICAxODQu
OTg1MjE0XSAyZjZjNSBpcyAyOTBlMTAwMCENClsgIDE4NC45OTYwNTNdIDJmNWRmIGlzIDI5
MGUwMDAwIQ0KWyAgMTg0Ljk5ODIzNl0gMmY2ZGEgaXMgMjkwZGYwMDAhDQpbICAxODUuMDAw
NDI2XSAyZjZkYiBpcyAyOTBkZTAwMCENClsgIDE4NS4wMDI2NTNdIDJmNmRjIGlzIDI5MGRk
MDAwIQ0KWyAgMTg1LjAwNDg2N10gMmY2YzYgaXMgMjkwZGMwMDAhDQpbICAxODUuMDA3MTA5
XSAyZjZkZCBpcyAyOTBkYjAwMCENClsgIDE4NS4wMDkzNzZdIDJmNmM3IGlzIDI5MGRhMDAw
IQ0KWyAgMTg1LjAyMDM4NV0gMmY2YzggaXMgMjkwZDkwMDAhDQpbICAxODUuMDIyNjE1XSAy
ZjZjOSBpcyAyOTBkODAwMCENClsgIDE4NS4wMjQ4ODFdIDJmNmNhIGlzIDI5MGQ3MDAwIQ0K
WyAgMTg1LjAzMjgwMF0gMmY2Y2IgaXMgMjkwZDUwMDAhDQpbICAxODUuMDM0OTkxXSAyZjZj
YyBpcyAyOTBkNDAwMCENClsgIDE4NS4wNDAwNjJdIDJmNmNkIGlzIDI5MGQzMDAwIQ0KWyAg
MTg1LjA0Mzk5NF0gMmY2ZGUgaXMgMjkwZDIwMDAhDQpbICAxODUuMDQ2MjEwXSAyZjZjZSBp
cyAyOTBkMTAwMCENClsgIDE4NS4wNDg0MjFdIDJmNmNmIGlzIDI5MGQwMDAwIQ0KWyAgMTg1
LjA1MjA5OV0gMmY2ZDAgaXMgMjkwY2YwMDAhDQpbICAxODUuMDU0MzIwXSAyZjZkMSBpcyAy
OTBjZTAwMCENClsgIDE4NS4wNjM4NTJdIDJmNmQyIGlzIDI5MGNkMDAwIQ0KWyAgMTg1LjA2
NjA3NF0gMmY2ZDMgaXMgMjkwY2MwMDAhDQpbICAxODUuMDY4MjgxXSAyZjZkNCBpcyAyOTBj
YjAwMCENClsgIDE4NS4wNzA1MDddIDJmNmQ1IGlzIDI5MGNhMDAwIQ0KWyAgMTg1LjA3MjY5
N10gMmY2ZDYgaXMgMjkwYzkwMDAhDQpbICAxODUuMDc0OTI3XSAyZjZkNyBpcyAyOTBjODAw
MCENClsgIDE4NS4wNzcxMjJdIDJmNmQ4IGlzIDI5MGM3MDAwIQ0KWyAgMTg1LjA4NjM2MF0g
MmY2ZDkgaXMgMjkwOGQwMDAhDQpbICAxODUuMDg4NjQ5XSAyZjZkZiBpcyAyOTA4ZTAwMCEN
ClsgIDE4NS4wOTA4NTldIDJmNmY5IGlzIDI5MDhmMDAwIQ0KWyAgMTg1LjA5MzAzOF0gMmY2
ZmEgaXMgMjkwOTAwMDAhDQpbICAxODUuMDk1Mjc0XSAyZjZmYiBpcyAyOTA5MTAwMCENClsg
IDE4NS4wOTc0MzddIDJmNmZjIGlzIDI5MDkyMDAwIQ0KWyAgMTg1LjA5OTYyNV0gMmY2ZTAg
aXMgMjkwOTMwMDAhDQpbICAxODUuMTA3MDgzXSAyZjZmZCBpcyAyOTA5NDAwMCENClsgIDE4
NS4xMDkyNzhdIDJmNmUxIGlzIDI5MDk1MDAwIQ0KWyAgMTg1LjExNDY3Nl0gMmY2ZmUgaXMg
MjkwOTYwMDAhDQpbICAxODUuMTE2OTAwXSAyZjZlMiBpcyAyOTA5NzAwMCENClsgIDE4NS4x
MTkwNjBdIDJmNmZmIGlzIDI5MDk4MDAwIQ0KWyAgMTg1LjEyMTIxOV0gMmY3MDAgaXMgMjkw
OTkwMDAhDQpbICAxODUuMTI3ODg5XSAyZjcwMSBpcyAyOTA5YjAwMCENClsgIDE4NS4xMzA0
NTJdIDJmNzAyIGlzIDI5MDlkMDAwIQ0KWyAgMTg1LjEzMjYxM10gMmY3MDMgaXMgMjkwOWUw
MDAhDQpbICAxODUuMTM0NzY5XSAyZjcwNCBpcyAyOTA5ZjAwMCENClsgIDE4NS4xMzY5MDBd
IDJmNmU0IGlzIDI5MGEwMDAwIQ0KWyAgMTg1LjEzOTE2NF0gMmY3MDUgaXMgMjkwYTEwMDAh
DQpbICAxODUuMTQxMzg4XSAyZjZlNSBpcyAyOTBhMjAwMCENClsgIDE4NS4xNDM1MTJdIDJm
NzA2IGlzIDI5MGEzMDAwIQ0KWyAgMTg1LjE0NTgwOF0gMmY3MDcgaXMgMjkwYTQwMDAhDQpb
ICAxODUuMTQ4MDIzXSAyZjZlNiBpcyAyOTBhNTAwMCENClsgIDE4NS4xNTAxNzddIDJmNzA4
IGlzIDI5MGM2MDAwIQ0KWyAgMTg1LjE1Njc3NF0gMmY3MDkgaXMgMjkwYjcwMDAhDQpbICAx
ODUuMTY3ODk2XSAyZjZlNyBpcyAyOTBiODAwMCENClsgIDE4NS4xNzAxOTRdIDJmNmU4IGlz
IDI5MGI2MDAwIQ0KWyAgMTg1LjE3MjQzNV0gMmY3MGEgaXMgMjkwYjUwMDAhDQpbICAxODUu
MTc0Njg0XSAyZjcwYiBpcyAyOTBiYjAwMCENClsgIDE4NS4xNzY4NjFdIDJmNmU5IGlzIDI5
MGJjMDAwIQ0KWyAgMTg1LjE3OTIxM10gMmY3MGMgaXMgMjkwYmQwMDAhDQpbICAxODUuMTgx
NTA4XSAyZjZlYSBpcyAyOTBiZTAwMCENClsgIDE4NS4xODM3ODNdIDJmNzBkIGlzIDI5MGMw
MDAwIQ0KWyAgMTg1LjE4NjA4M10gMmY2ZWIgaXMgMjkwYzIwMDAhDQpbICAxODUuMTg4Mzg1
XSAyZjcwZSBpcyAyOTBjMzAwMCENClsgIDE4NS4xOTA2NTZdIDJmNmVjIGlzIDI5MGMxMDAw
IQ0KWyAgMTg1LjE5Mjk2Nl0gMmY2ZWQgaXMgMjkwYTYwMDAhDQpbICAxODUuMTk1Mjk3XSAy
ZjcwZiBpcyAyOTBhNzAwMCENClsgIDE4NS4xOTc3OTJdIDJmNzEwIGlzIDI5MGFmMDAwIQ0K
WyAgMTg1LjIwMDEzMF0gMmY2ZWUgaXMgMjkwYmEwMDAhDQpbICAxODUuMjAyNDM4XSAyZjcx
MSBpcyAyOTBiOTAwMCENClsgIDE4NS4yMDQ3ODJdIDJmNzEyIGlzIDI5MGM1MDAwIQ0KWyAg
MTg1LjIwNzA2Nl0gMmY3MTMgaXMgMjkwYzQwMDAhDQpbICAxODUuMjA5NDAxXSAyZjcxNCBp
cyAyODlmZTAwMCENClsgIDE4NS4yMTE3MzVdIDJmNzE1IGlzIDI5MGIwMDAwIQ0KWyAgMTg1
LjIxNDA4Nl0gMmY3MTYgaXMgMjkwYjEwMDAhDQpbICAxODUuMjE2NDQwXSAyZjcxNyBpcyAy
ODcwMzAwMCENClsgIDE4NS4yMTg3OTFdIDJmNzE4IGlzIDI4YTA4MDAwIQ0KWyAgMTg1LjIy
MTE4NF0gMmY3MTkgaXMgMjg3MDQwMDAhDQpbICAxODUuMjIzNTA2XSAyZjcxYSBpcyAyOTBh
YTAwMCENClsgIDE4NS4yMjc1NzJdIDJmNzQyIGlzIDI5MDcyMDAwIQ0KWyAgMTg1LjIyOTU2
Nl0gMmY3NDMgaXMgMjkwNzMwMDAhDQpbICAxODUuMjMxNTAwXSAyZjc0NCBpcyAyOTA3NDAw
MCENClsgIDE4NS4yMzM0NDldIDJmNzQ1IGlzIDI5MDc1MDAwIQ0KWyAgMTg1LjIzNTM0N10g
MmY3NDYgaXMgMjkwNzYwMDAhDQpbICAxODUuMjM3MjU0XSAyZjc0NyBpcyAyOTA3NzAwMCEN
ClsgIDE4NS4yMzkxMjNdIDJmNzQ4IGlzIDI5MDc4MDAwIQ0KWyAgMTg1LjI0MTAxM10gMmY3
NDkgaXMgMjkwNzkwMDAhDQpbICAxODUuMjQyODY0XSAyZjc0YSBpcyAyOTA3YTAwMCENClsg
IDE4NS4yNDQ4MTFdIDJmNzRiIGlzIDI5MDdiMDAwIQ0KWyAgMTg1LjI0NjY0N10gMmY3Mzcg
aXMgMjkwN2MwMDAhDQpbICAxODUuMjQ4NDkwXSAyZjczOCBpcyAyOTA3ZDAwMCENClsgIDE4
NS4yNTAzNTBdIDJmNzM5IGlzIDI5MDdlMDAwIQ0KWyAgMTg1LjI1MjE0OV0gMmY3M2EgaXMg
MjkwN2YwMDAhDQpbICAxODUuMjUzOTcyXSAyZjczYiBpcyAyOTA4MDAwMCENClsgIDE4NS4y
NTU3NTldIDJmNzNjIGlzIDI5MDgxMDAwIQ0KWyAgMTg1LjI1NzU4MV0gMmY3M2QgaXMgMjkw
ODIwMDAhDQpbICAxODUuMjU5MzQ2XSAyZjczZSBpcyAyOTA4MzAwMCENClsgIDE4NS4yNjEx
MjRdIDJmNzNmIGlzIDI5MDg0MDAwIQ0KWyAgMTg1LjI2MjkwOF0gMmY3NDAgaXMgMjkwODUw
MDAhDQpbICAxODUuMjY0Njg3XSAyZjc0MSBpcyAyOTA4NjAwMCENClsgIDE4NS4yNjY1MDRd
IDJmNmY4IGlzIDI5MDY3MDAwIQ0KWyAgMTg1LjI2ODMwMF0gMmY2ZjcgaXMgMjkwNjgwMDAh
DQpbICAxODUuMjcwMTA3XSAyZjZmNiBpcyAyOTA2OTAwMCENClsgIDE4NS4yNzE4NTVdIDJm
NmY1IGlzIDI5MDZhMDAwIQ0KWyAgMTg1LjI3MzY1MV0gMmY2ZjQgaXMgMjkwNmIwMDAhDQpb
ICAxODUuMjc1Mzc4XSAyZjZmMyBpcyAyOTA2YzAwMCENClsgIDE4NS4yNzcwOTBdIDJmNmYy
IGlzIDI5MDZkMDAwIQ0KWyAgMTg1LjI3ODgwMl0gMmY2ZjEgaXMgMjkwNmUwMDAhDQpbICAx
ODUuMjgwNDkwXSAyZjZmMCBpcyAyOTA2ZjAwMCENClsgIDE4NS4yODIxODNdIDJmNmVmIGlz
IDI5MDcwMDAwIQ0KWyAgMTg1LjI4Mzg3M10gMmY3MWIgaXMgMjkwNzEwMDAhDQpbICAxODUu
Mjg2NDI4XSAyZjc2MiBpcyAyOTA0NzAwMCENClsgIDE4NS4yODgxODldIDJmNzYzIGlzIDI5
MDQ4MDAwIQ0KWyAgMTg1LjI4OTg4Nl0gMmY3NjQgaXMgMjkwNDkwMDAhDQpbICAxODUuMjkx
NjE0XSAyZjc2NSBpcyAyOTA0YTAwMCENClsgIDE4NS4yOTMzMDRdIDJmNzY2IGlzIDI5MDRi
MDAwIQ0KWyAgMTg1LjI5NTAyOV0gMmY3NjcgaXMgMjkwNGMwMDAhDQpbICAxODUuMjk2NzM0
XSAyZjc2OCBpcyAyOTA0ZDAwMCENClsgIDE4NS4yOTg0MTldIDJmNzY5IGlzIDI5MDRlMDAw
IQ0KWyAgMTg1LjMwMDE0OF0gMmY3NmEgaXMgMjkwNGYwMDAhDQpbICAxODUuMzAxODU5XSAy
Zjc2YiBpcyAyOTA1MDAwMCENClsgIDE4NS4zMDM1OTddIDJmNzZjIGlzIDI5MDUxMDAwIQ0K
WyAgMTg1LjMwNTI5OV0gMmY3NGMgaXMgMjkwNWMwMDAhDQpbICAxODUuMzA3MDMwXSAyZjc0
ZCBpcyAyOTA1ZDAwMCENClsgIDE4NS4zMDg3NDJdIDJmNzRlIGlzIDI5MDVlMDAwIQ0KWyAg
MTg1LjMxMDQzNF0gMmY3NGYgaXMgMjkwNWYwMDAhDQpbICAxODUuMzEyMTQzXSAyZjc1MCBp
cyAyOTA2MDAwMCENClsgIDE4NS4zMTM4NTNdIDJmNzUxIGlzIDI5MDYxMDAwIQ0KWyAgMTg1
LjMxNTU2OV0gMmY3NTIgaXMgMjkwNjIwMDAhDQpbICAxODUuMzE3MjcxXSAyZjc1MyBpcyAy
OTA2MzAwMCENClsgIDE4NS4zMTg5NDldIDJmNzU0IGlzIDI5MDY0MDAwIQ0KWyAgMTg1LjMy
MDY2N10gMmY3NTUgaXMgMjkwNjUwMDAhDQpbICAxODUuMzIyMzMzXSAyZjc1NiBpcyAyOTA2
NjAwMCENClsgIDE4NS4zMjQwNDZdIDJmNzU3IGlzIDI5MDUyMDAwIQ0KWyAgMTg1LjMyNTcy
NF0gMmY3NTggaXMgMjkwNTMwMDAhDQpbICAxODUuMzI3NDE1XSAyZjc1OSBpcyAyOTA1NDAw
MCENClsgIDE4NS4zMjkxMjVdIDJmNzVhIGlzIDI5MDU1MDAwIQ0KWyAgMTg1LjMzMDgxOF0g
MmY3NWIgaXMgMjkwNTYwMDAhDQpbICAxODUuMzMyNTI3XSAyZjc1YyBpcyAyOTA1NzAwMCEN
ClsgIDE4NS4zMzQyMjZdIDJmNzVkIGlzIDI5MDU4MDAwIQ0KWyAgMTg1LjMzNTg5OF0gMmY3
NWUgaXMgMjkwNTkwMDAhDQpbICAxODUuMzM3NTk4XSAyZjc1ZiBpcyAyOTA1YTAwMCENClsg
IDE4NS4zMzkyNDFdIDJmNzYwIGlzIDI5MDViMDAwIQ0KWyAgMTg1LjM0MjYxNV0gMmY3NjEg
aXMgMjkwMTIwMDAhDQpbICAxODUuMzQ0MzU1XSAyZjcxYyBpcyAyOTAxMzAwMCENClsgIDE4
NS4zNDYwNDldIDJmNzFkIGlzIDI5MDE0MDAwIQ0KWyAgMTg1LjM0NzcyM10gMmY3MWUgaXMg
MjkwMTUwMDAhDQpbICAxODUuMzQ5NDE3XSAyZjcxZiBpcyAyOTAxNjAwMCENClsgIDE4NS4z
NTExMTFdIDJmNzIwIGlzIDI5MDE3MDAwIQ0KWyAgMTg1LjM1MjgxOV0gMmY3MjEgaXMgMjkw
MTgwMDAhDQpbICAxODUuMzU0NTE0XSAyZjcyMiBpcyAyOTAxOTAwMCENClsgIDE4NS4zNTYx
NjRdIDJmNzIzIGlzIDI5MDFhMDAwIQ0KWyAgMTg1LjM1NzgzN10gMmY3MjQgaXMgMjkwMWIw
MDAhDQpbICAxODUuMzU5NDc3XSAyZjc3NyBpcyAyOTAyNzAwMCENClsgIDE4NS4zNjExNTFd
IDJmNzc2IGlzIDI5MDI4MDAwIQ0KWyAgMTg1LjM2MjgwN10gMmY3NzUgaXMgMjkwMjkwMDAh
DQpbICAxODUuMzY0NDgwXSAyZjc3NCBpcyAyOTAyYTAwMCENClsgIDE4NS4zNjYxNTZdIDJm
NzczIGlzIDI5MDJiMDAwIQ0KWyAgMTg1LjM2NzgwM10gMmY3NzIgaXMgMjkwMmMwMDAhDQpb
ICAxODUuMzY5NDc4XSAyZjc3MSBpcyAyOTAyZDAwMCENClsgIDE4NS4zNzExMjVdIDJmNzcw
IGlzIDI5MDJlMDAwIQ0KWyAgMTg1LjM3Mjc2M10gMmY3NmYgaXMgMjkwMmYwMDAhDQpbICAx
ODUuMzc0NDM2XSAyZjc2ZSBpcyAyOTAzMDAwMCENClsgIDE4NS4zNzYwODBdIDJmNzZkIGlz
IDI5MDMxMDAwIQ0KWyAgMTg1LjM3Nzc1NV0gMmY3ODIgaXMgMjkwMWMwMDAhDQpbICAxODUu
Mzc5NDA2XSAyZjc4MSBpcyAyOTAxZDAwMCENClsgIDE4NS4zODEwNjldIDJmNzgwIGlzIDI5
MDFlMDAwIQ0KWyAgMTg1LjM4Mjc0MV0gMmY3N2YgaXMgMjkwMWYwMDAhDQpbICAxODUuMzg0
NDIzXSAyZjc3ZSBpcyAyOTAyMDAwMCENClsgIDE4NS4zODYxMDRdIDJmNzdkIGlzIDI5MDIx
MDAwIQ0KWyAgMTg1LjM4Nzc4NF0gMmY3N2MgaXMgMjkwMjIwMDAhDQpbICAxODUuMzg5NDUz
XSAyZjc3YiBpcyAyOTAyMzAwMCENClsgIDE4NS4zOTExNTBdIDJmNzdhIGlzIDI5MDI0MDAw
IQ0KWyAgMTg1LjM5MjgyOF0gMmY3NzkgaXMgMjkwMjUwMDAhDQpbICAxODUuMzk0NTI5XSAy
Zjc3OCBpcyAyOTAyNjAwMCENClsgIDE4NS4zOTczNzVdIDJmN2EyIGlzIDI4ZmRjMDAwIQ0K
WyAgMTg1LjM5OTE3MF0gMmY3ODMgaXMgMjhmZGQwMDAhDQpbICAxODUuNDAwODk1XSAyZjc4
NCBpcyAyOGZkZTAwMCENClsgIDE4NS40MDI2MDddIDJmNzg1IGlzIDI4ZmRmMDAwIQ0KWyAg
MTg1LjQwNDM1MV0gMmY3ODYgaXMgMjhmZTAwMDAhDQpbICAxODUuNDA2MDU1XSAyZjc4NyBp
cyAyOGZlMTAwMCENClsgIDE4NS40MDc3OTJdIDJmNzg4IGlzIDI4ZmUyMDAwIQ0KWyAgMTg1
LjQwOTUxMV0gMmY3ODkgaXMgMjhmZTMwMDAhDQpbICAxODUuNDExMjYxXSAyZjc4YSBpcyAy
OGZlNDAwMCENClsgIDE4NS40MTI5NjVdIDJmNzhiIGlzIDI4ZmU1MDAwIQ0KWyAgMTg1LjQx
NDY3OF0gMmY3OGMgaXMgMjhmZTYwMDAhDQpbICAxODUuNDE2MzkxXSAyZjc5OCBpcyAyOGZm
MjAwMCENClsgIDE4NS40MTgxMDldIDJmNzk5IGlzIDI4ZmYzMDAwIQ0KWyAgMTg1LjQxOTgz
M10gMmY3OWEgaXMgMjhmZjQwMDAhDQpbICAxODUuNDIxNTUyXSAyZjc5YiBpcyAyOGZmNTAw
MCENClsgIDE4NS40MjMyNTZdIDJmNzljIGlzIDI4ZmY2MDAwIQ0KWyAgMTg1LjQyNTAwMF0g
MmY3OWQgaXMgMjhmZjcwMDAhDQpbICAxODUuNDI2Njk1XSAyZjc5ZSBpcyAyOGZmODAwMCEN
ClsgIDE4NS40Mjg0MjZdIDJmNzlmIGlzIDI4ZmY5MDAwIQ0KWyAgMTg1LjQzMDEyOV0gMmY3
YTAgaXMgMjhmZmEwMDAhDQpbICAxODUuNDMxODM4XSAyZjdhMSBpcyAyOGZmYjAwMCENClsg
IDE4NS40MzM1MjJdIDJmNzMwIGlzIDI4ZmZjMDAwIQ0KWyAgMTg1LjQzNTIwMV0gMmY3MzEg
aXMgMjhmZmQwMDAhDQpbICAxODUuNDM2OTEzXSAyZjczMiBpcyAyOGZmZTAwMCENClsgIDE4
NS40Mzg1ODBdIDJmNzMzIGlzIDI4ZmZmMDAwIQ0KWyAgMTg1LjQ0MDI4MF0gMmY3MzQgaXMg
MjkwMDAwMDAhDQpbICAxODUuNDQxOTUzXSAyZjczNSBpcyAyOTAwMTAwMCENClsgIDE4NS40
NDM2NDVdIDJmNzM2IGlzIDI5MDAyMDAwIQ0KWyAgMTg1LjQ0NTM1MF0gMmY3OTQgaXMgMjkw
MDMwMDAhDQpbICAxODUuNDQ3MDQ4XSAyZjc5NSBpcyAyOTAwNDAwMCENClsgIDE4NS40NDg3
NThdIDJmNzk2IGlzIDI5MDA1MDAwIQ0KWyAgMTg1LjQ1MDQ1N10gMmY3OTcgaXMgMjkwMDYw
MDAhDQpbICAxODUuNDUyMTE4XSAyZjcyZiBpcyAyOGZlNzAwMCENClsgIDE4NS40NTM4NDFd
IDJmNzJlIGlzIDI4ZmU4MDAwIQ0KWyAgMTg1LjQ1NTUxNF0gMmY3MmQgaXMgMjhmZTkwMDAh
DQpbICAxODUuNDU3MjI3XSAyZjcyYyBpcyAyOGZlYTAwMCENClsgIDE4NS40NTg4OTRdIDJm
NzJiIGlzIDI4ZmViMDAwIQ0KWyAgMTg1LjQ2MDU4MV0gMmY3MmEgaXMgMjhmZWMwMDAhDQpb
ICAxODUuNDYyMjg0XSAyZjcyOSBpcyAyOGZlZDAwMCENClsgIDE4NS40NjM5NzFdIDJmNzI4
IGlzIDI4ZmVlMDAwIQ0KWyAgMTg1LjQ2NTY2OV0gMmY3MjcgaXMgMjhmZWYwMDAhDQpbICAx
ODUuNDY3MzYyXSAyZjcyNiBpcyAyOGZmMDAwMCENClsgIDE4NS40NjkwNDFdIDJmNzI1IGlz
IDI4ZmYxMDAwIQ0KWyAgMTg1LjQ3MjM0Nl0gMmY3YjYgaXMgMjhmYzcwMDAhDQpbICAxODUu
NDc0MDk5XSAyZjdiNSBpcyAyOGZjODAwMCENClsgIDE4NS40NzU3OTldIDJmN2I0IGlzIDI4
ZmM5MDAwIQ0KWyAgMTg1LjQ3NzQ4Ml0gMmY3YjMgaXMgMjhmY2EwMDAhDQpbICAxODUuNDc5
MjA0XSAyZjc5MyBpcyAyOGZjYjAwMCENClsgIDE4NS40ODA5MDFdIDJmNzkyIGlzIDI4ZmNj
MDAwIQ0KWyAgMTg1LjQ4MjYwNV0gMmY3OTEgaXMgMjhmY2QwMDAhDQpbICAxODUuNDg0Mjg4
XSAyZjc5MCBpcyAyOGZjZTAwMCENClsgIDE4NS40ODU5NzldIDJmNzhmIGlzIDI4ZmNmMDAw
IQ0KWyAgMTg1LjQ4NzY3MF0gMmY3OGUgaXMgMjhmZDAwMDAhDQpbICAxODUuNDg5MzUzXSAy
Zjc4ZCBpcyAyOGZkMTAwMCENClsgIDE4NS40OTEwMzddIDJmN2EzIGlzIDI4ZmJjMDAwIQ0K
WyAgMTg1LjQ5MjcxMV0gMmY3YTQgaXMgMjhmYmQwMDAhDQpbICAxODUuNDk0NDEyXSAyZjdh
NSBpcyAyOGZiZTAwMCENClsgIDE4NS40OTYwNjhdIDJmN2E2IGlzIDI4ZmJmMDAwIQ0KWyAg
MTg1LjQ5NzczNl0gMmY3YTcgaXMgMjhmYzAwMDAhDQpbICAxODUuNDk5NDE0XSAyZjdhOCBp
cyAyOGZjMTAwMCENClsgIDE4NS41MDEwODVdIDJmN2E5IGlzIDI4ZmMyMDAwIQ0KWyAgMTg1
LjUwMjc2Nl0gMmY3YWEgaXMgMjhmYzMwMDAhDQpbICAxODUuNTA0NDUxXSAyZjdhYiBpcyAy
OGZjNDAwMCENClsgIDE4NS41MDYxMjNdIDJmN2FjIGlzIDI4ZmM1MDAwIQ0KWyAgMTg1LjUw
NzgwNF0gMmY3YWQgaXMgMjhmYzYwMDAhDQpbICAxODUuNTA5NzAyXSAyZjdkNyBpcyAyOGZh
NzAwMCENClsgIDE4NS41MTE0MzhdIDJmN2Q4IGlzIDI4ZmE4MDAwIQ0KWyAgMTg1LjUxMzEy
MF0gMmY3ZDkgaXMgMjhmYTkwMDAhDQpbICAxODUuNTE0ODA2XSAyZjdkYSBpcyAyOGZhYTAw
MCENClsgIDE4NS41MTY0OTldIDJmN2RiIGlzIDI4ZmFiMDAwIQ0KWyAgMTg1LjUxODE4OF0g
MmY3ZGMgaXMgMjhmYWMwMDAhDQpbICAxODUuNTE5OTk2XSAyZjdkZCBpcyAyOGZhZDAwMCEN
ClsgIDE4NS41MjE3MDJdIDJmN2RlIGlzIDI4ZmFlMDAwIQ0KWyAgMTg1LjUyMzQzMV0gMmY3
ZGYgaXMgMjhmYWYwMDAhDQpbICAxODUuNTI1MTEyXSAyZjdlMCBpcyAyOGZiMDAwMCENClsg
IDE4NS41MjY4MDNdIDJmN2UxIGlzIDI4ZmIxMDAwIQ0KWyAgMTg1LjUyODUwOF0gMmY3YWUg
aXMgMjhmYjIwMDAhDQpbICAxODUuNTMwMjE5XSAyZjdhZiBpcyAyOGZiMzAwMCENClsgIDE4
NS41MzE5MjldIDJmN2IwIGlzIDI4ZmI0MDAwIQ0KWyAgMTg1LjUzMzYyNl0gMmY3YjEgaXMg
MjhmYjUwMDAhDQpbICAxODUuNTM1MzA1XSAyZjdiMiBpcyAyOGZiNjAwMCENClsgIDE4NS41
MzcwMjhdIDJmN2QyIGlzIDI4ZmI3MDAwIQ0KWyAgMTg1LjUzODcxMl0gMmY3ZDMgaXMgMjhm
YjgwMDAhDQpbICAxODUuNTQwNDMxXSAyZjdkNCBpcyAyOGZiOTAwMCENClsgIDE4NS41NDIx
MTVdIDJmN2Q1IGlzIDI4ZmJhMDAwIQ0KWyAgMTg1LjU0MzgxM10gMmY3ZDYgaXMgMjhmYmIw
MDAhDQpbICAxODUuNTQ2NDYwXSAyZjdlMyBpcyAyOGY5MDAwMCENClsgIDE4NS41NDgyMDNd
IDJmN2UyIGlzIDI4ZjkxMDAwIQ0KWyAgMTg1LjU0OTkyMl0gMmY3ZWUgaXMgMjhmODUwMDAh
DQpbICAxODUuNTUxNjMwXSAyZjdlZCBpcyAyOGY4NjAwMCENClsgIDE4NS41NTMzNTJdIDJm
N2VjIGlzIDI4Zjg3MDAwIQ0KWyAgMTg1LjU1NTA3MV0gMmY3ZWIgaXMgMjhmODgwMDAhDQpb
ICAxODUuNTU2Nzk5XSAyZjdlYSBpcyAyOGY4OTAwMCENClsgIDE4NS41NTg0NzVdIDJmN2U5
IGlzIDI4ZjhhMDAwIQ0KWyAgMTg1LjU2MDE2OV0gMmY3ZTggaXMgMjhmOGIwMDAhDQpbICAx
ODUuNTYxODg0XSAyZjdlNyBpcyAyOGY4YzAwMCENClsgIDE4NS41NjM1ODRdIDJmN2U2IGlz
IDI4ZjhkMDAwIQ0KWyAgMTg1LjU2NTI5MV0gMmY3ZTUgaXMgMjhmOGUwMDAhDQpbICAxODUu
NTY2OTc2XSAyZjdlNCBpcyAyOGY4ZjAwMCENClsgIDE4NS41Njg5MzldIDJmN2Y5IGlzIDI4
ZjdhMDAwIQ0KWyAgMTg1LjU3MDY5NV0gMmY3ZmEgaXMgMjhmN2IwMDAhDQpbICAxODUuNTcy
MzgzXSAyZjdmYiBpcyAyOGY3YzAwMCENClsgIDE4NS41NzQxMDBdIDJmN2Y4IGlzIDI4Zjdk
MDAwIQ0KWyAgMTg1LjU3NTc4MV0gMmY3ZjcgaXMgMjhmN2UwMDAhDQpbICAxODUuNTc3NDkw
XSAyZjdmNiBpcyAyOGY3ZjAwMCENClsgIDE4NS41NzkxNjNdIDJmN2Y1IGlzIDI4ZjgwMDAw
IQ0KWyAgMTg1LjU4MDg0OV0gMmY3ZjQgaXMgMjhmODEwMDAhDQpbICAxODcuNzA5Nzg4XSAy
ZjJkYiBpcyAyOTMxODAwMCENClsgIDE4Ny43MTE5NjNdIDJmMzUwIGlzIDI5MzE3MDAwIQ0K
WyAgMTg3LjcxNDE0MV0gMmYyZGMgaXMgMjkzMTYwMDAhDQpbICAxODcuNzE2NDA3XSAyZjJk
ZCBpcyAyOTMxNTAwMCENClsgIDE4Ny43MTg2NDhdIDJmMzUxIGlzIDI5MzE0MDAwIQ0KWyAg
MTg3LjcyMDkxMV0gMmYzNTIgaXMgMjkzMTMwMDAhDQpbICAxODcuNzIzMTMwXSAyZjM1MyBp
cyAyOTMxMjAwMCENClsgIDE4Ny43MjUzODddIDJmMzU0IGlzIDI5MzExMDAwIQ0KWyAgMTg3
LjcyNzYzOF0gMmYzNTUgaXMgMjkzMTAwMDAhDQpbICAxODcuNzI5ODY1XSAyZjM1NiBpcyAy
OTMwZjAwMCENClsgIDE4Ny43MzIwODhdIDJmMzU3IGlzIDI5MzBlMDAwIQ0KWyAgMTg3Ljcz
NDM0MF0gMmYzNTggaXMgMjkzMGQwMDAhDQpbICAxODcuNzM2NTQ2XSAyZjM1OSBpcyAyOTMw
YzAwMCENClsgIDE4Ny43Mzg3NjddIDJmMzVhIGlzIDI5MzBiMDAwIQ0KWyAgMTg3Ljc0MTAx
OV0gMmYzNWIgaXMgMjkzMGEwMDAhDQpbICAxODcuNzQzMjE3XSAyZjM1YyBpcyAyOTMwOTAw
MCENClsgIDE4Ny43NTIzODNdIDJmMzVkIGlzIDI5MzA4MDAwIQ0KWyAgMTg3Ljc1NDU2N10g
MmYyZGUgaXMgMjkzMDcwMDAhDQpbICAxODcuNzU2NzkxXSAyZjJkZiBpcyAyOTMwNjAwMCEN
ClsgIDE4Ny43NTkwMDVdIDJmMzVlIGlzIDI5MzA1MDAwIQ0KWyAgMTg3Ljc2MTEyNV0gMmYz
NWYgaXMgMjkzMDQwMDAhDQpbICAxODcuNzYzMzYwXSAyZjJlMCBpcyAyOTMwMzAwMCENClsg
IDE4Ny43Njk1NjhdIDJmMzYwIGlzIDI5MzAyMDAwIQ0KWyAgMTg3Ljc3MTc2N10gMmYyZTEg
aXMgMjkzMDEwMDAhDQpbICAxODcuNzczOTM1XSAyZjJlMiBpcyAyOTMwMDAwMCENClsgIDE4
Ny43NzYxNDJdIDJmMzdlIGlzIDI5MmZmMDAwIQ0KWyAgMTg3Ljc3ODI5MV0gMmYzNjEgaXMg
MjkyZmUwMDAhDQpbICAxODcuNzgwNDc3XSAyZjM3ZiBpcyAyOTJmZDAwMCENClsgIDE4Ny43
ODI3MjVdIDJmMzgwIGlzIDI5MmZjMDAwIQ0KWyAgMTg3Ljc4NDkxNV0gMmYzNjIgaXMgMjky
ZmIwMDAhDQpbICAxODcuNzg3MjAzXSAyZjM4MSBpcyAyOTJmYTAwMCENClsgIDE4Ny43ODk0
MTJdIDJmMzYzIGlzIDI5MmY5MDAwIQ0KWyAgMTg3Ljc5MTY1MF0gMmYzNjQgaXMgMjkyZjgw
MDAhDQpbICAxODcuNzkzODY0XSAyZjM2NSBpcyAyOTJmNzAwMCENClsgIDE4Ny43OTYwNjZd
IDJmMzY2IGlzIDI5MmY2MDAwIQ0KWyAgMTg3LjgwMjIzMF0gMmYzNjcgaXMgMjkyZjUwMDAh
DQpbICAxODcuODA0Mzk2XSAyZjM4MiBpcyAyOTJmNDAwMCENClsgIDE4Ny44MDY1ODZdIDJm
MzgzIGlzIDI5MmYzMDAwIQ0KWyAgMTg3LjgwODczOV0gMmYzNjggaXMgMjkyZjIwMDAhDQpb
ICAxODcuODE2OTM2XSAyZjM4NCBpcyAyOTJmMTAwMCENClsgIDE4Ny44MTkxMjFdIDJmMzg1
IGlzIDI5MmYwMDAwIQ0KWyAgMTg3LjgyMTI3M10gMmYzNjkgaXMgMjkyZWYwMDAhDQpbICAx
ODcuODM4NTgyXSAyZjM4NiBpcyAyOTJlNDAwMCENClsgIDE4Ny44NDA0NjhdIDJmMzZhIGlz
IDI5MmU1MDAwIQ0KWyAgMTg3Ljg0MjM0OF0gMmYzNmIgaXMgMjkyZTYwMDAhDQpbICAxODcu
ODQ0MjY5XSAyZjM2YyBpcyAyOTJlNzAwMCENClsgIDE4Ny44NDYwNzBdIDJmMzZkIGlzIDI5
MmU4MDAwIQ0KWyAgMTg3Ljg0Nzg4Ml0gMmYzNmUgaXMgMjkyZTkwMDAhDQpbICAxODcuODQ5
Njg2XSAyZjM2ZiBpcyAyOTJlYTAwMCENClsgIDE4Ny44NTE0NzZdIDJmMzcwIGlzIDI5MmVi
MDAwIQ0KWyAgMTg3Ljg1MzI2NV0gMmYzNzEgaXMgMjkyZWMwMDAhDQpbICAxODcuODU1MDQ2
XSAyZjM3MiBpcyAyOTJlZDAwMCENClsgIDE4Ny44NTY4MzBdIDJmMzczIGlzIDI5MmVlMDAw
IQ0KWyAgMTg3Ljg1ODY1MV0gMmYzOWUgaXMgMjkyY2YwMDAhDQpbICAxODcuODYwNDUyXSAy
ZjM5ZiBpcyAyOTJkMDAwMCENClsgIDE4Ny44NjIyMzRdIDJmM2EwIGlzIDI5MmQxMDAwIQ0K
WyAgMTg3Ljg2NDAxOV0gMmYzYTEgaXMgMjkyZDIwMDAhDQpbICAxODcuODY1Nzc1XSAyZjNh
MiBpcyAyOTJkMzAwMCENClsgIDE4Ny44Njc1MjhdIDJmM2EzIGlzIDI5MmQ0MDAwIQ0KWyAg
MTg3Ljg2OTI1Ml0gMmYzYTQgaXMgMjkyZDUwMDAhDQpbICAxODcuODcxMDAzXSAyZjNhNSBp
cyAyOTJkNjAwMCENClsgIDE4Ny44NzI3MjZdIDJmM2E2IGlzIDI5MmQ3MDAwIQ0KWyAgMTg3
Ljg3NDQ3N10gMmYzYTcgaXMgMjkyZDgwMDAhDQpbICAxODcuODc2NTg4XSAyZjNhOCBpcyAy
OTJjNDAwMCENClsgIDE4Ny44NzgzNTRdIDJmM2E5IGlzIDI5MmM1MDAwIQ0KWyAgMTg3Ljg4
MDA4N10gMmYzYWEgaXMgMjkyYzYwMDAhDQpbICAxODcuODgxODA5XSAyZjNhYiBpcyAyOTJj
NzAwMCENClsgIDE4Ny44ODM1NTNdIDJmM2FjIGlzIDI5MmM4MDAwIQ0KWyAgMTg3Ljg4NTI1
OF0gMmYzYWQgaXMgMjkyYzkwMDAhDQpbICAxODcuODg2OTk4XSAyZjNhZSBpcyAyOTJjYTAw
MCENClsgIDE4Ny44ODg2OTNdIDJmM2FmIGlzIDI5MmNiMDAwIQ0KWyAgMTg3Ljg5MDQwN10g
MmYzYjAgaXMgMjkyY2MwMDAhDQpbICAxODcuODkyMTAwXSAyZjNiMSBpcyAyOTJjZDAwMCEN
ClsgIDE4Ny44OTM3ODhdIDJmM2IyIGlzIDI5MmNlMDAwIQ0KWyAgMTg3Ljg5NTQ2Ml0gMmYz
YjMgaXMgMjkyYjkwMDAhDQpbICAxODcuODk3MTM0XSAyZjNiNCBpcyAyOTJiYTAwMCENClsg
IDE4Ny44OTg4MDddIDJmM2I1IGlzIDI5MmJiMDAwIQ0KWyAgMTg3LjkwMDQ4NF0gMmYzYjYg
aXMgMjkyYmMwMDAhDQpbICAxODcuOTAyMTU0XSAyZjNiNyBpcyAyOTJiZDAwMCENClsgIDE4
Ny45MDM4NTNdIDJmM2I4IGlzIDI5MmJlMDAwIQ0KWyAgMTg3LjkwNTUxNl0gMmYzYjkgaXMg
MjkyYmYwMDAhDQpbICAxODcuOTA3MjEwXSAyZjNiYSBpcyAyOTJjMDAwMCENClsgIDE4Ny45
MDg4NzRdIDJmM2JiIGlzIDI5MmMxMDAwIQ0KWyAgMTg3LjkxMDU0NF0gMmYzYmUgaXMgMjky
YzIwMDAhDQpbICAxODcuOTEyMjE1XSAyZjNiZiBpcyAyOTJjMzAwMCENClsgIDE4Ny45MTM4
NzNdIDJmM2MwIGlzIDI5MmFmMDAwIQ0KWyAgMTg3LjkxNTUzN10gMmYzYzEgaXMgMjkyYjAw
MDAhDQpbICAxODcuOTE3MjAxXSAyZjNjMiBpcyAyOTJiMTAwMCENClsgIDE4Ny45MTg4NTFd
IDJmM2MzIGlzIDI5MmIyMDAwIQ0KWyAgMTg3LjkyMDUyNV0gMmYzYzQgaXMgMjkyYjMwMDAh
DQpbICAxODcuOTIyMTc1XSAyZjNjNSBpcyAyOTJiNDAwMCENClsgIDE4Ny45MjM4NDddIDJm
M2M2IGlzIDI5MmI1MDAwIQ0KWyAgMTg3LjkyNTQ4NV0gMmYzYzcgaXMgMjkyYjYwMDAhDQpb
ICAxODcuOTI3MTM3XSAyZjNjOCBpcyAyOTJiNzAwMCENClsgIDE4Ny45Mjg3OTJdIDJmM2M5
IGlzIDI5MmI4MDAwIQ0KWyAgMTg3LjkzMDQzOV0gMmYzNzQgaXMgMjkyZDkwMDAhDQpbICAx
ODcuOTMyMTAzXSAyZjM3NSBpcyAyOTJkYTAwMCENClsgIDE4Ny45MzM3NjBdIDJmMzc2IGlz
IDI5MmRiMDAwIQ0KWyAgMTg3LjkzNTQwM10gMmYzNzcgaXMgMjkyZGMwMDAhDQpbICAxODcu
OTM3MDgxXSAyZjM3OCBpcyAyOTJkZDAwMCENClsgIDE4Ny45Mzg3MzFdIDJmMzc5IGlzIDI5
MmRlMDAwIQ0KWyAgMTg3Ljk0MDQwOV0gMmYzN2EgaXMgMjkyZGYwMDAhDQpbICAxODcuOTQy
MDcwXSAyZjM3YiBpcyAyOTJlMDAwMCENClsgIDE4Ny45NDM3NDBdIDJmMzdjIGlzIDI5MmUx
MDAwIQ0KWyAgMTg3Ljk0NTQxMV0gMmYzN2QgaXMgMjkyZTIwMDAhDQpbICAxODcuOTQ3MDgw
XSAyZjM5ZCBpcyAyOTJlMzAwMCENClsgIDE4Ny45NDk2NTFdIDJmMzg3IGlzIDI5MmE0MDAw
IQ0KWyAgMTg3Ljk1MTM4OF0gMmYzY2EgaXMgMjkyYTUwMDAhDQpbICAxODcuOTUzMDk2XSAy
ZjNjYiBpcyAyOTJhNjAwMCENClsgIDE4Ny45NTQ3ODFdIDJmM2NjIGlzIDI5MmE3MDAwIQ0K
WyAgMTg3Ljk1NjQ2OV0gMmYzY2QgaXMgMjkyYTgwMDAhDQpbICAxODcuOTU4MTk1XSAyZjNj
ZSBpcyAyOTJhOTAwMCENClsgIDE4Ny45NTk4ODldIDJmM2NmIGlzIDI5MmFhMDAwIQ0KWyAg
MTg3Ljk2MTYxMF0gMmYzZDAgaXMgMjkyYWIwMDAhDQpbICAxODcuOTYzMzA3XSAyZjNkMSBp
cyAyOTJhYzAwMCENClsgIDE4Ny45NjUwMTNdIDJmM2QyIGlzIDI5MmFkMDAwIQ0KWyAgMTg3
Ljk2Njc1NF0gMmYzZDMgaXMgMjkyYWUwMDAhDQpbICAxODcuOTY4NzE0XSAyZjNkZiBpcyAy
OTI4ZjAwMCENClsgIDE4Ny45NzA0NDhdIDJmM2UwIGlzIDI5MjkwMDAwIQ0KWyAgMTg3Ljk3
MjE0OF0gMmYzZTEgaXMgMjkyOTEwMDAhDQpbICAxODcuOTczODYwXSAyZjNlMiBpcyAyOTI5
MjAwMCENClsgIDE4Ny45NzU1MzhdIDJmM2UzIGlzIDI5MjkzMDAwIQ0KWyAgMTg3Ljk3NzIz
M10gMmYzZTQgaXMgMjkyOTQwMDAhDQpbICAxODcuOTc4OTI5XSAyZjNlNSBpcyAyOTI5NTAw
MCENClsgIDE4Ny45ODA2MTddIDJmM2U2IGlzIDI5Mjk2MDAwIQ0KWyAgMTg3Ljk4MjMyNl0g
MmYzZTcgaXMgMjkyOTcwMDAhDQpbICAxODcuOTg0MDIwXSAyZjNlOCBpcyAyOTI5ODAwMCEN
ClsgIDE4Ny45ODU2ODJdIDJmM2U5IGlzIDI5MjhlMDAwIQ0KWyAgMTg3Ljk4NzM3Nl0gMmYz
ZDQgaXMgMjkyOTkwMDAhDQpbICAxODcuOTg5MDcxXSAyZjNkNSBpcyAyOTI5YTAwMCENClsg
IDE4Ny45OTA3NjJdIDJmM2Q2IGlzIDI5MjliMDAwIQ0KWyAgMTg3Ljk5MjQyOV0gMmYzZDcg
aXMgMjkyOWMwMDAhDQpbICAxODcuOTk0MTE3XSAyZjNkOCBpcyAyOTI5ZDAwMCENClsgIDE4
Ny45OTU4MDBdIDJmM2Q5IGlzIDI5MjllMDAwIQ0KWyAgMTg3Ljk5NzQ3Nl0gMmYzZGEgaXMg
MjkyOWYwMDAhDQpbICAxODcuOTk5MTYwXSAyZjNkYiBpcyAyOTJhMDAwMCENClsgIDE4OC4w
MDA4NDZdIDJmM2RjIGlzIDI5MmExMDAwIQ0KWyAgMTg4LjAwMjUzNl0gMmYzZGQgaXMgMjky
YTIwMDAhDQpbICAxODguMDA0MjM5XSAyZjNkZSBpcyAyOTJhMzAwMCENClsgIDE4OC4wMDYy
ODJdIDJmM2VhIGlzIDI5MjhkMDAwIQ0KWyAgMTg4LjAwODQwN10gMmYzZWIgaXMgMjkyOGMw
MDAhDQpbICAxODguMDEwNTAxXSAyZjNlYyBpcyAyOTI4YjAwMCENClsgIDE4OC4wMTI2MDRd
IDJmM2VkIGlzIDI5MjhhMDAwIQ0KWyAgMTg4LjAxNDY4Nl0gMmYzZWUgaXMgMjkyODkwMDAh
DQpbICAxODguMDMyNzIxXSAyZjNlZiBpcyAyOTI4ODAwMCENClsgIDE4OC4wMzQ4MDZdIDJm
M2YwIGlzIDI5Mjg3MDAwIQ0KWyAgMTg4LjAzNjkwM10gMmYzZjEgaXMgMjkyODYwMDAhDQpb
ICAxODguMDM4OTMyXSAyZjNmMiBpcyAyOTI4NTAwMCENClsgIDE4OC4wNDEwMzhdIDJmMzg4
IGlzIDI5Mjg0MDAwIQ0KWyAgMTg4LjA0MzExOF0gMmYzZjMgaXMgMjkyODMwMDAhDQpbICAx
ODguMDQ1MTc4XSAyZjNmNCBpcyAyOTI4MjAwMCENClsgIDE4OC4wNDcyMTFdIDJmMzg5IGlz
IDI5MjgxMDAwIQ0KWyAgMTg4LjA0OTMxM10gMmYzOGEgaXMgMjkyODAwMDAhDQpbICAxODgu
MDU4MTE3XSAyZjNmNSBpcyAyOTI3ZjAwMCENClsgIDE4OC4wNjAyMjNdIDJmMzhiIGlzIDI5
MjdlMDAwIQ0KWyAgMTg4LjA2MjI4M10gMmYzZjYgaXMgMjkyN2QwMDAhDQpbICAxODguMDY0
Mzc4XSAyZjNmNyBpcyAyOTI3YzAwMCENClsgIDE4OC4wNjY0NjNdIDJmM2Y4IGlzIDI5Mjdi
MDAwIQ0KWyAgMTg4LjA2ODU3OV0gMmYzZjkgaXMgMjkyN2EwMDAhDQpbICAxODguMDcwNjY3
XSAyZjNmYSBpcyAyOTI3OTAwMCENClsgIDE4OC4wNzI3NDZdIDJmM2ZiIGlzIDI5Mjc4MDAw
IQ0KWyAgMTg4LjA3NDgzMV0gMmYzZmMgaXMgMjkyNzcwMDAhDQpbICAxODguMDc2OTA1XSAy
ZjNmZCBpcyAyOTI3NjAwMCENClsgIDE4OC4wNzg5MjFdIDJmM2ZlIGlzIDI5Mjc1MDAwIQ0K
WyAgMTg4LjA4MTAwN10gMmYzOGQgaXMgMjkyNzQwMDAhDQpbICAxODguMDgzMDk2XSAyZjNm
ZiBpcyAyOTI3MzAwMCENClsgIDE4OC4wODUxNTZdIDJlYzAwIGlzIDI5MjcyMDAwIQ0KWyAg
MTg4LjA4NzIzNV0gMmYzOGUgaXMgMjkyNzEwMDAhDQpbICAxODguMDg5MzMxXSAyZjM4ZiBp
cyAyOTI3MDAwMCENClsgIDE4OC4wOTEzOTBdIDJlYzAxIGlzIDI5MjZmMDAwIQ0KWyAgMTg4
LjA5MzU3N10gMmYzOTAgaXMgMjkyNmUwMDAhDQpbICAxODguMDk1NzE4XSAyZWMwMiBpcyAy
OTI2ZDAwMCENClsgIDE4OC4wOTc4ODBdIDJlYzAzIGlzIDI5MjZjMDAwIQ0KWyAgMTg4LjEw
MDA0OV0gMmVjMDQgaXMgMjkyNmIwMDAhDQpbICAxODguMTAyMjA2XSAyZWMwNSBpcyAyOTI2
YTAwMCENClsgIDE4OC4xMDQ0MDRdIDJlYzA2IGlzIDI5MjY5MDAwIQ0KWyAgMTg4LjEwNjU1
NF0gMmVjMDcgaXMgMjkyNjgwMDAhDQpbICAxODguMTA4NzcyXSAyZWMwOCBpcyAyOTI2NzAw
MCENClsgIDE4OC4xMTM0ODRdIDJlYzA5IGlzIDI5MjQxMDAwIQ0KWyAgMTg4LjExNTczOF0g
MmYzOTEgaXMgMjkyNDIwMDAhDQpbICAxODguMTE3OTE0XSAyZWMwYSBpcyAyOTI0MzAwMCEN
ClsgIDE4OC4xMjAxODJdIDJmMzkyIGlzIDI5MjQ0MDAwIQ0KWyAgMTg4LjEyNjAxMl0gMmVj
MGIgaXMgMjkyNDUwMDAhDQpbICAxODguMTI4MjYyXSAyZjM5MyBpcyAyOTI0YzAwMCENClsg
IDE4OC4xMzA1MjNdIDJlYzBjIGlzIDI5MjViMDAwIQ0KWyAgMTg4LjEzMjgwN10gMmVjMGQg
aXMgMjkyNWEwMDAhDQpbICAxODguMTM1MDUxXSAyZWMwZSBpcyAyOTI1YzAwMCENClsgIDE4
OC4xMzczMzVdIDJlYzBmIGlzIDI5MjVkMDAwIQ0KWyAgMTg4LjEzOTU4MV0gMmVjMTAgaXMg
MjkyNTcwMDAhDQpbICAxODguMTQxODUyXSAyZWMxMSBpcyAyOTI1NjAwMCENClsgIDE4OC4x
NDQxMzRdIDJlYzEyIGlzIDI5MjU1MDAwIQ0KWyAgMTg4LjE0NjM5OV0gMmVjMTMgaXMgMjky
NTQwMDAhDQpbICAxODguMTQ4NjU1XSAyZWMxNCBpcyAyOTI1MzAwMCENClsgIDE4OC4xNTA5
MzJdIDJlYzE1IGlzIDI5MjUxMDAwIQ0KWyAgMTg4LjE1MzIwNl0gMmVjMTYgaXMgMjkyNTgw
MDAhDQpbICAxODguMTU1NDg2XSAyZWMxNyBpcyAyOTI0ZjAwMCENClsgIDE4OC4xNTc3ODBd
IDJlYzE4IGlzIDI5MjRiMDAwIQ0KWyAgMTg4LjE2MDA1OV0gMmVjMTkgaXMgMjkyNWUwMDAh
DQpbICAxODguMTYyMzM3XSAyZWMxYSBpcyAyOTI0NjAwMCENClsgIDE4OC4xNjQ2MDBdIDJl
YzFiIGlzIDI5MjUwMDAwIQ0KWyAgMTg4LjE2NjkxM10gMmVjMWMgaXMgMjkyNTkwMDAhDQpb
ICAxODguMTY5MTE1XSAyZWMxZCBpcyAyOTI0ZDAwMCENClsgIDE4OC4xODE5NzJdIDJmMzk0
IGlzIDI5MjRlMDAwIQ0KWyAgMTg4LjE4NDE3NF0gMmYzOTUgaXMgMjkzOGEwMDAhDQpbICAx
ODguMTg2NDQwXSAyZjM5NiBpcyAyOTI2NDAwMCENClsgIDE4OC4xODg2MzZdIDJlYzFlIGlz
IDI5MjY1MDAwIQ0KWyAgMTg4LjE5MDg5M10gMmYzOTcgaXMgMjg5ZjQwMDAhDQpbICAxODgu
MTkzMTkyXSAyZjM5OCBpcyAyOTM3ZDAwMCENClsgIDE4OC4xOTU1MDldIDJlYzFmIGlzIDI4
OWY1MDAwIQ0KWyAgMTg4LjE5NzkxMV0gMmYzOTkgaXMgMjkyNGEwMDAhDQpbICAxODguMjAw
MzAxXSAyZWMyMCBpcyAyOGU0NjAwMCENClsgIDE4OC4yMDI3MDZdIDJlYzIxIGlzIDI5Mzdm
MDAwIQ0KWyAgMTg4LjIwNTEwMl0gMmVjMjIgaXMgMjkyNjIwMDAhDQpbICAxODguMjA3NDkz
XSAyZWMyMyBpcyAyOTI2MTAwMCENClsgIDE4OC4yMDk4NTldIDJlYzI0IGlzIDI5MjYwMDAw
IQ0KWyAgMTg4LjIxMjIxOF0gMmVjMjUgaXMgMjkyNWYwMDAhDQpbICAxODguMjE0NTUxXSAy
ZWMyNiBpcyAyODFmZTAwMCENClsgIDE4OC4yMTY5MTRdIDJlYzI3IGlzIDI4MWZkMDAwIQ0K
WyAgMTg4LjIxOTIyNl0gMmVjMjggaXMgMjkyM2UwMDAhDQpbICAxODguMjIxNTkyXSAyZjM5
YSBpcyAyOTIzZDAwMCENClsgIDE4OC4yMzA3ODddIDJlYzI5IGlzIDI5MjNjMDAwIQ0KWyAg
MTg4LjIzMzIxNF0gMmYzOWIgaXMgMjkyM2IwMDAhDQpbICAxODguMjQ5NTQxXSAyZWMyYSBp
cyAyOTIzYTAwMCENClsgIDE4OC4yNTE5NzNdIDJmMzljIGlzIDI5MjM5MDAwIQ0KWyAgMTg4
LjI1NDQzOV0gMmVjM2EgaXMgMjkyMzgwMDAhDQpbICAxODguMjU2OTQ5XSAyZWMzYiBpcyAy
OTIzNzAwMCENClsgIDE4OC4yNTkzNTZdIDJlYzJiIGlzIDI5MjM2MDAwIQ0KWyAgMTg4LjI2
ODA4MV0gMmVjM2MgaXMgMjkyMzUwMDAhDQpbICAxODguMjcwNTgzXSAyZWMyYyBpcyAyOTIz
NDAwMCENClsgIDE4OC4yNzMxMDNdIDJlYzNkIGlzIDI5MjMzMDAwIQ0KWyAgMTg4LjI3NTU2
NV0gMmVjMmQgaXMgMjkyMzIwMDAhDQpbICAxODguMjc4MDI1XSAyZWMzZSBpcyAyOTIzMTAw
MCENClsgIDE4OC4yODA0NThdIDJlYzNmIGlzIDI5MjMwMDAwIQ0KWyAgMTg4LjI4Mjk1Ml0g
MmVjNDAgaXMgMjkyMmYwMDAhDQpbICAxODguMjg1MzgyXSAyZWMyZSBpcyAyOTIyZTAwMCEN
ClsgIDE4OC4yODc4ODldIDJlYzQxIGlzIDI5MjJkMDAwIQ0KWyAgMTg4LjI5MzI2MV0gMmVj
MmYgaXMgMjkyMmMwMDAhDQpbICAxODguMjk1NzA4XSAyZWM0MiBpcyAyOTIyYjAwMCENClsg
IDE4OC4yOTgwOTFdIDJlYzMwIGlzIDI5MjJhMDAwIQ0KWyAgMTg4LjMwMDQ3NV0gMmVjMzEg
aXMgMjkyMjkwMDAhDQpbICAxODguMzAyODQ2XSAyZWMzMiBpcyAyOTIyODAwMCENClsgIDE4
OC4zMDUxNzFdIDJlYzMzIGlzIDI5MjI3MDAwIQ0KWyAgMTg4LjMwNzQ3OF0gMmVjMzQgaXMg
MjkyMjYwMDAhDQpbICAxODguMzA5NzQ2XSAyZWMzNSBpcyAyOTIyNTAwMCENClsgIDE4OC4z
MTIwMjldIDJlYzM2IGlzIDI5MjI0MDAwIQ0KWyAgMTg4LjMxNDMxNF0gMmVjMzcgaXMgMjky
MjMwMDAhDQpbICAxODguMzE2NTk1XSAyZWMzOCBpcyAyOTIyMjAwMCENClsgIDE4OC4zMTg3
OTldIDJlYzM5IGlzIDI5MjIxMDAwIQ0KWyAgMTg4LjMyMTA2Ml0gMmVjNTkgaXMgMjkyMjAw
MDAhDQpbICAxODguMzIzMjkyXSAyZWM1YSBpcyAyOTIxZjAwMCENClsgIDE4OC4zMjU1MTdd
IDJlYzViIGlzIDI5MjFlMDAwIQ0KWyAgMTg4LjMyNzg2MV0gMmVjNWMgaXMgMjkyMWQwMDAh
DQpbICAxODguMzMwMDU5XSAyZWM0MyBpcyAyOTIxYzAwMCENClsgIDE4OC4zMzIyNTJdIDJl
YzVkIGlzIDI5MjFiMDAwIQ0KWyAgMTg4LjMzNDQyMV0gMmVjNWUgaXMgMjkyMWEwMDAhDQpb
ICAxODguMzM2NTY4XSAyZWM1ZiBpcyAyOTIxOTAwMCENClsgIDE4OC4zMzg2OTRdIDJlYzYw
IGlzIDI5MjE4MDAwIQ0KWyAgMTg4LjM0MDg1MV0gMmVjNjEgaXMgMjkyMTcwMDAhDQpbICAx
ODguMzQyOTc3XSAyZWM2MiBpcyAyOTIxNjAwMCENClsgIDE4OC4zNDUxNjldIDJlYzYzIGlz
IDI5MjE1MDAwIQ0KWyAgMTg4LjM1MTYzOF0gMmVjNjQgaXMgMjkyMTQwMDAhDQpbICAxODgu
MzUzNzk2XSAyZWM2NSBpcyAyOTIxMzAwMCENClsgIDE4OC4zNTU5MThdIDJlYzY2IGlzIDI5
MjEyMDAwIQ0KWyAgMTg4LjM1ODA2Ml0gMmVjNjcgaXMgMjkyMTEwMDAhDQpbICAxODguMzk1
Njg4XSAyZWM2OCBpcyAyOTIxMDAwMCENClsgIDE4OC4zOTc4MjNdIDJlYzQ0IGlzIDI5MjBm
MDAwIQ0KWyAgMTg4LjM5OTk2Ml0gMmVjNjkgaXMgMjkyMGUwMDAhDQpbICAxODguNDExODky
XSAyZWM2YSBpcyAyOTIwZDAwMCENClsgIDE4OC40MTQwMjRdIDJlYzZiIGlzIDI5MjBjMDAw
IQ0KWyAgMTg4LjQxNjE3OV0gMmVjNmMgaXMgMjkyMGIwMDAhDQpbICAxODguNDUxMDc4XSAy
ZWM2ZCBpcyAyOTIwYTAwMCENClsgIDE4OC40NTMyMTddIDJlYzZlIGlzIDI5MjA5MDAwIQ0K
WyAgMTg4LjQ1NTMxOF0gMmVjNmYgaXMgMjkyMDgwMDAhDQpbICAxODguNDU3NDQwXSAyZWM3
MCBpcyAyOTIwNzAwMCENClsgIDE4OC40NTk1NjBdIDJlYzcxIGlzIDI5MjA2MDAwIQ0KWyAg
MTg4LjQ2NTE1MF0gMmVjNzIgaXMgMjkyMDUwMDAhDQpbICAxODguNDY3MjY5XSAyZWM3MyBp
cyAyOTIwNDAwMCENClsgIDE4OC40NjkzOTNdIDJlYzc0IGlzIDI5MjAzMDAwIQ0KWyAgMTg4
LjQ3MTQ5N10gMmVjNzUgaXMgMjkyMDIwMDAhDQpbICAxODguNDczNjMwXSAyZWM3NiBpcyAy
OTIwMTAwMCENClsgIDE4OC40NzU3NDJdIDJlYzc3IGlzIDI5MjAwMDAwIQ0KWyAgMTg4LjQ4
NjQyNF0gMmVjNzggaXMgMjkxZmYwMDAhDQpbICAxODguNDg4NTUyXSAyZWM3OSBpcyAyOTFm
ZTAwMCENClsgIDE4OC40OTA2ODFdIDJlYzdhIGlzIDI5MWZkMDAwIQ0KWyAgMTg4LjQ5NjM4
OV0gMmVjN2IgaXMgMjkxZmMwMDAhDQpbICAxODguNDk4NjQzXSAyZWM0NSBpcyAyOTFmYjAw
MCENClsgIDE4OC41MDA4NzNdIDJlYzdjIGlzIDI5MWZhMDAwIQ0KWyAgMTg4LjUwMzAwNF0g
MmVjN2QgaXMgMjkxZjkwMDAhDQpbICAxODguNTA1MzI5XSAyZWM3ZSBpcyAyOTFmODAwMCEN
ClsgIDE4OC41MDc1NzBdIDJlYzdmIGlzIDI5MWY3MDAwIQ0KWyAgMTg4LjUwOTY5NV0gMmVj
ODAgaXMgMjkxZjYwMDAhDQpbICAxODguNTExOTkxXSAyZWM4MSBpcyAyOTFmNTAwMCENClsg
IDE4OC41MTQyMTddIDJlYzgyIGlzIDI5MWY0MDAwIQ0KWyAgMTg4LjUxNjM0NV0gMmVjODMg
aXMgMjkxZjMwMDAhDQpbICAxODguNTE4NjM4XSAyZWM4NCBpcyAyOTFmMjAwMCENClsgIDE4
OC41MjA4NjJdIDJlYzg1IGlzIDI5MWYxMDAwIQ0KWyAgMTg4LjUyMjk4MF0gMmVjODYgaXMg
MjkxZjAwMDAhDQpbICAxODguNTI1MjU2XSAyZWM4NyBpcyAyOTFlZjAwMCENClsgIDE4OC41
Mjc0ODNdIDJlYzg4IGlzIDI5MWVlMDAwIQ0KWyAgMTg4LjUyOTU3OF0gMmVjODkgaXMgMjkx
ZWQwMDAhDQpbICAxODguNTMxODYyXSAyZWM4YSBpcyAyOTFlYzAwMCENClsgIDE4OC41MzQw
NDJdIDJlYzhiIGlzIDI5MWViMDAwIQ0KWyAgMTg4LjUzNjE0OV0gMmVjOGMgaXMgMjkxZWEw
MDAhDQpbICAxODguNTM4NDE0XSAyZWM4ZCBpcyAyOTFlOTAwMCENClsgIDE4OC41NDA2MDhd
IDJlYzhmIGlzIDI5MWU4MDAwIQ0KWyAgMTg4LjU0MjY5OF0gMmVjOTAgaXMgMjkxZTcwMDAh
DQpbICAxODguNTQ0OTI5XSAyZWM5MSBpcyAyOTFlNjAwMCENClsgIDE4OC41NDk1MjFdIDJl
YzkyIGlzIDI5MWU1MDAwIQ0KWyAgMTg4LjU1MTY3Nl0gMmVjNDYgaXMgMjkxZTQwMDAhDQpb
ICAxODguNTUzODM3XSAyZWM5MyBpcyAyOTFlMzAwMCENClsgIDE4OC41NTU5MzhdIDJlYzk0
IGlzIDI5MWUyMDAwIQ0KWyAgMTg4LjU1ODE0OV0gMmVjOTUgaXMgMjkxZTEwMDAhDQpbICAx
ODguNTYwMjA1XSAyZWM5NiBpcyAyOTFlMDAwMCENClsgIDE4OC41NjI0MDRdIDJlYzk3IGlz
IDI5MWRmMDAwIQ0KWyAgMTg4LjU2NDUwM10gMmVjNDcgaXMgMjkxZGUwMDAhDQpbICAxODgu
NTY2NTY2XSAyZWM5OCBpcyAyOTFkZDAwMCENClsgIDE4OC41Njg2MTVdIDJlYzk5IGlzIDI5
MWRjMDAwIQ0KWyAgMTg4LjU3MDY2MV0gMmVjNDggaXMgMjkxZGIwMDAhDQpbICAxODguNTcy
NzQ2XSAyZWM0OSBpcyAyOTFkYTAwMCENClsgIDE4OC41NzQ3NzldIDJlYzlhWyAgMTkwLjcw
MTc1N10gMmU4YjIgaXMgMjlkMGUwMDAhDQpbICAxOTAuNzAzNDg2XSAyZThiMyBpcyAyOWQw
ZjAwMCENClsgIDE5MC43MDUxNzZdIDJlOGI0IGlzIDI5ZDEwMDAwIQ0KWyAgMTkwLjcwNjg5
MV0gMmU4YjUgaXMgMjlkMTEwMDAhDQpbICAxOTAuNzA4NTY0XSAyZTg5ZiBpcyAyOWQxMjAw
MCENClsgIDE5MC43MTAyNTVdIDJlOGEyIGlzIDI5ZDEzMDAwIQ0KWyAgMTkwLjcxMTk2N10g
MmU4YTMgaXMgMjlkMTQwMDAhDQpbICAxOTAuNzEzNjczXSAyZThhNCBpcyAyOWQxNTAwMCEN
ClsgIDE5MC43MTUzNjhdIDJlOGE1IGlzIDI5ZDE2MDAwIQ0KWyAgMTkwLjcxNzA1OF0gMmU4
YTYgaXMgMjlkMTcwMDAhDQpbICAxOTAuNzE4NzMxXSAyZThhNyBpcyAyOWQxODAwMCENClsg
IDE5MC43MjA0NDRdIDJlOGE4IGlzIDI5ZDE5MDAwIQ0KWyAgMTkwLjcyMjEzMl0gMmU4YTkg
aXMgMjlkMWEwMDAhDQpbICAxOTAuNzIzODUxXSAyZThhYSBpcyAyOWQxYjAwMCENClsgIDE5
MC43Mzg1NzFdIDJlOGNiIGlzIDI5Y2U3MDAwIQ0KWyAgMTkwLjc0MDI4N10gMmU4Y2MgaXMg
MjljZTgwMDAhDQpbICAxOTAuNzQxOTc3XSAyZThjZCBpcyAyOWNlOTAwMCENClsgIDE5MC43
NDM3NDldIDJlOGNlIGlzIDI5Y2VhMDAwIQ0KWyAgMTkwLjc0NTQ1MF0gMmU4Y2YgaXMgMjlj
ZWIwMDAhDQpbICAxOTAuNzQ3MTQ5XSAyZThkMCBpcyAyOWNlYzAwMCENClsgIDE5MC43NDg4
NjRdIDJlOGQxIGlzIDI5Y2VkMDAwIQ0KWyAgMTkwLjc1MDU4NV0gMmU4ZDIgaXMgMjljZWUw
MDAhDQpbICAxOTAuNzUyMjk1XSAyZThkMyBpcyAyOWNlZjAwMCENClsgIDE5MC43NTQwMzNd
IDJlOGQ0IGlzIDI5Y2YwMDAwIQ0KWyAgMTkwLjc1NTc0M10gMmU4ZDUgaXMgMjljZjEwMDAh
DQpbICAxOTAuNzU3NDYyXSAyZThkNiBpcyAyOWNkYzAwMCENClsgIDE5MC43NTkxNTBdIDJl
OGQ3IGlzIDI5Y2RkMDAwIQ0KWyAgMTkwLjc2MDg2OF0gMmU4ZDggaXMgMjljZGUwMDAhDQpb
ICAxOTAuNzYyNTYwXSAyZThkOSBpcyAyOWNkZjAwMCENClsgIDE5MC43NjQyNjNdIDJlOGRh
IGlzIDI5Y2UwMDAwIQ0KWyAgMTkwLjc2NTk2MF0gMmU4ZGIgaXMgMjljZTEwMDAhDQpbICAx
OTAuNzY3NjQwXSAyZThkYyBpcyAyOWNlMjAwMCENClsgIDE5MC43NjkzMjBdIDJlOGRkIGlz
IDI5Y2UzMDAwIQ0KWyAgMTkwLjc3MDk4M10gMmU4ZGUgaXMgMjljZTQwMDAhDQpbICAxOTAu
NzcyNjM4XSAyZThkZiBpcyAyOWNlNTAwMCENClsgIDE5MC43NzQzMjFdIDJlOGUwIGlzIDI5
Y2U2MDAwIQ0KWyAgMTkwLjc3NTk3Nl0gMmU4ZTEgaXMgMjljZDIwMDAhDQpbICAxOTAuNzc3
NjUxXSAyZThlMiBpcyAyOWNkMzAwMCENClsgIDE5MC43NzkzMDJdIDJlOGUzIGlzIDI5Y2Q0
MDAwIQ0KWyAgMTkwLjc4MDk2M10gMmU4ZTQgaXMgMjljZDUwMDAhDQpbICAxOTAuNzgyNjM0
XSAyZThlNSBpcyAyOWNkNjAwMCENClsgIDE5MC43ODQzMDddIDJlOGU2IGlzIDI5Y2Q3MDAw
IQ0KWyAgMTkwLjc4NTk4Ml0gMmU4ZTcgaXMgMjljZDgwMDAhDQpbICAxOTAuNzg3NjQ5XSAy
ZThlOCBpcyAyOWNkOTAwMCENClsgIDE5MC43ODkzMDVdIDJlOGU5IGlzIDI5Y2RhMDAwIQ0K
WyAgMTkwLjc5MDk4OV0gMmU4ZWEgaXMgMjljZGIwMDAhDQpbICAxOTAuNzkyNzA3XSAyZThl
YiBpcyAyOWNkMTAwMCENClsgIDE5MC43OTQ3MTVdIDJlOGVjIGlzIDI5Y2QwMDAwIQ0KWyAg
MTkwLjgwMjY0NV0gMmU4MWQgaXMgMjljY2YwMDAhDQpbICAxOTAuODA0NjcxXSAyZThlZCBp
cyAyOWNjZTAwMCENClsgIDE5MC44MDY2ODddIDJlOGVlIGlzIDI5Y2NkMDAwIQ0KWyAgMTkw
LjgwODc5M10gMmU4ZWYgaXMgMjljY2MwMDAhDQpbICAxOTAuODEwODk2XSAyZThmMCBpcyAy
OWNjYjAwMCENClsgIDE5MC44MTI5MjFdIDJlOGYxIGlzIDI5Y2NhMDAwIQ0KWyAgMTkwLjgx
NTEwMl0gMmU4ZjIgaXMgMjljYzkwMDAhDQpbICAxOTAuODE3MTkzXSAyZThmMyBpcyAyOWNj
ODAwMCENClsgIDE5MC44MTkyMTVdIDJlOGY0IGlzIDI5Y2M3MDAwIQ0KWyAgMTkwLjgyMTM4
MV0gMmU4ZjUgaXMgMjljYzYwMDAhDQpbICAxOTAuODIzNzA0XSAyZThmNiBpcyAyOWNjNDAw
MCENClsgIDE5MC44MjU3MTBdIDJlOGY3IGlzIDI5Y2MzMDAwIQ0KWyAgMTkwLjgyNzcwN10g
MmU4ZjggaXMgMjljYzIwMDAhDQpbICAxOTAuODI5NzE5XSAyZTgxZSBpcyAyOWNjMTAwMCEN
ClsgIDE5MC44MzE3MzBdIDJlODFmIGlzIDI5Y2MwMDAwIQ0KWyAgMTkwLjgzMzcyMF0gMmU4
ZjkgaXMgMjljYmYwMDAhDQpbICAxOTAuODM1NzQ3XSAyZThmYSBpcyAyOWNiZTAwMCENClsg
IDE5MC44NDY0MDJdIDJlOGZiIGlzIDI5Y2JkMDAwIQ0KWyAgMTkwLjg0ODQ0OF0gMmU4MjAg
aXMgMjljYmMwMDAhDQpbICAxOTAuODUwNjAwXSAyZThmYyBpcyAyOWNiYjAwMCENClsgIDE5
MC44NTI2MzddIDJlOGZkIGlzIDI5Y2JhMDAwIQ0KWyAgMTkwLjg1NDgzNF0gMmU4ZmUgaXMg
MjljYjkwMDAhDQpbICAxOTAuODU2ODg4XSAyZThmZiBpcyAyOWNiODAwMCENClsgIDE5MC44
NTg4NjhdIDJlOTAwIGlzIDI5Y2I3MDAwIQ0KWyAgMTkwLjg2MDg5M10gMmU4MjEgaXMgMjlj
YjYwMDAhDQpbICAxOTAuODYyOTI2XSAyZTkwMSBpcyAyOWNiNTAwMCENClsgIDE5MC44NjQ5
NDhdIDJlOTAyIGlzIDI5Y2I0MDAwIQ0KWyAgMTkwLjg2NjkyOV0gMmU5MDMgaXMgMjljYjMw
MDAhDQpbICAxOTAuODY4OTExXSAyZTgyMiBpcyAyOWNiMjAwMCENClsgIDE5MC44NzA5NDld
IDJlODIzIGlzIDI5Y2IxMDAwIQ0KWyAgMTkwLjg3Mjk3OF0gMmU5MDQgaXMgMjljYjAwMDAh
DQpbICAxOTAuODc1MDE3XSAyZTkwNSBpcyAyOWNhZjAwMCENClsgIDE5MC44ODk0NjVdIDJl
OTA2IGlzIDI5Y2FlMDAwIQ0KWyAgMTkwLjg5MTUyM10gMmU5MWUgaXMgMjljYWQwMDAhDQpb
ICAxOTAuODkzNTcwXSAyZTkwNyBpcyAyOWNhYzAwMCENClsgIDE5MC44OTU1OTddIDJlOTA4
IGlzIDI5Y2FiMDAwIQ0KWyAgMTkwLjg5NzY0NV0gMmU5MWYgaXMgMjljYWEwMDAhDQpbICAx
OTAuODk5NzEyXSAyZTkwOSBpcyAyOWNhOTAwMCENClsgIDE5MC45MDE3NTNdIDJlOTBhIGlz
IDI5Y2E4MDAwIQ0KWyAgMTkwLjkwMzc4OV0gMmU5MGIgaXMgMjljYTcwMDAhDQpbICAxOTAu
OTA1ODU2XSAyZTkyMCBpcyAyOWNhNjAwMCENClsgIDE5MC45MDc5MjFdIDJlOTBjIGlzIDI5
Y2E1MDAwIQ0KWyAgMTkwLjkwOTkzMF0gMmU5MGQgaXMgMjljYTQwMDAhDQpbICAxOTAuOTEy
MDEzXSAyZTkyMSBpcyAyOWNhMzAwMCENClsgIDE5MC45MjI2MDddIDJlOTBlIGlzIDI5Y2Ey
MDAwIQ0KWyAgMTkwLjkyNDcwNl0gMmU5MGYgaXMgMjljYTEwMDAhDQpbICAxOTAuOTI2Nzk3
XSAyZTkxMCBpcyAyOWNhMDAwMCENClsgIDE5MC45Mjg5MDNdIDJlOTExIGlzIDI5YzlmMDAw
IQ0KWyAgMTkwLjkzMTAxNF0gMmU5MTIgaXMgMjljOWUwMDAhDQpbICAxOTAuOTQwMTcwXSAy
ZTkyMiBpcyAyOWM5ZDAwMCENClsgIDE5MC45NDIyNzNdIDJlOTIzIGlzIDI5YzljMDAwIQ0K
WyAgMTkwLjk0NDUyOV0gMmU5MTMgaXMgMjljOWIwMDAhDQpbICAxOTAuOTQ2NjA3XSAyZTkx
NCBpcyAyOWM5YTAwMCENClsgIDE5MC45NDg4NzRdIDJlOTE1IGlzIDI5Yzk5MDAwIQ0KWyAg
MTkwLjk1MDk3NV0gMmU5MTcgaXMgMjljOTgwMDAhDQpbICAxOTAuOTUzMDg4XSAyZTkxOCBp
cyAyOWM5NzAwMCENClsgIDE5MC45NTUzMzZdIDJlOTE5IGlzIDI5Yzk2MDAwIQ0KWyAgMTkw
Ljk1NzUxOF0gMmU5MWEgaXMgMjljOTUwMDAhDQpbICAxOTAuOTU5NTk3XSAyZTkxYiBpcyAy
OWM5NDAwMCENClsgIDE5MC45NjE4ODJdIDJlOTFjIGlzIDI5YzkzMDAwIQ0KWyAgMTkwLjk2
NDA2M10gMmU5MWQgaXMgMjljOTIwMDAhDQpbICAxOTAuOTY2MTQ3XSAyZTkzZCBpcyAyOWM5
MTAwMCENClsgIDE5MC45NjgzNzVdIDJlOTNlIGlzIDI5YzkwMDAwIQ0KWyAgMTkwLjk3MDUw
Nl0gMmU5M2YgaXMgMjljOGYwMDAhDQpbICAxOTAuOTcyNTQxXSAyZTk0MCBpcyAyOWM4ZTAw
MCENClsgIDE5MC45NzQ3MTddIDJlOTQxIGlzIDI5YzhkMDAwIQ0KWyAgMTkwLjk3NzA5OF0g
MmU5NDIgaXMgMjljOGIwMDAhDQpbICAxOTAuOTc5MTM3XSAyZTk0MyBpcyAyOWM4YTAwMCEN
ClsgIDE5MC45ODUyMjVdIDJlOTQ0IGlzIDI5Yzg5MDAwIQ0KWyAgMTkwLjk4NzI5MF0gMmU5
MjQgaXMgMjljODgwMDAhDQpbICAxOTAuOTg5MzI4XSAyZTkyNSBpcyAyOWM4NzAwMCENClsg
IDE5MC45OTEzOTFdIDJlOTQ1IGlzIDI5Yzg2MDAwIQ0KWyAgMTkwLjk5Mzc3Nl0gMmU5MjYg
aXMgMjljODQwMDAhDQpbICAxOTAuOTk1ODEwXSAyZTk0NiBpcyAyOWM4MzAwMCENClsgIDE5
MC45OTc4ODNdIDJlOTQ3IGlzIDI5YzgyMDAwIQ0KWyAgMTkwLjk5OTg4Nl0gMmU5NDggaXMg
MjljODEwMDAhDQpbICAxOTEuMDAxOTEzXSAyZTk0OSBpcyAyOWM4MDAwMCENClsgIDE5MS4w
MDM5ODJdIDJlOTRhIGlzIDI5YzdmMDAwIQ0KWyAgMTkxLjAwNjAwNV0gMmU5NGIgaXMgMjlj
N2UwMDAhDQpbICAxOTEuMDA4MDczXSAyZTk0YyBpcyAyOWM3ZDAwMCENClsgIDE5MS4wMTA0
MzBdIDJlOTRkIGlzIDI5YzdiMDAwIQ0KWyAgMTkxLjAxMjQ0MV0gMmU5NGUgaXMgMjljN2Ew
MDAhDQpbICAxOTEuMDE0NDg1XSAyZTk0ZiBpcyAyOWM3OTAwMCENClsgIDE5MS4wMTY1MDBd
IDJlOTUwIGlzIDI5Yzc4MDAwIQ0KWyAgMTkxLjAxODU0Ml0gMmU5NTEgaXMgMjljNzcwMDAh
DQpbICAxOTEuMDIwNTgzXSAyZTk1MiBpcyAyOWM3NjAwMCENClsgIDE5MS4wMjI1ODJdIDJl
OTUzIGlzIDI5Yzc1MDAwIQ0KWyAgMTkxLjAyNDYyMl0gMmU5NTQgaXMgMjljNzQwMDAhDQpb
ICAxOTEuMDI2NjA1XSAyZTk1NSBpcyAyOWM3MzAwMCENClsgIDE5MS4wMjg2MzVdIDJlOTU2
IGlzIDI5YzcyMDAwIQ0KWyAgMTkxLjAzMDYyOF0gMmU5NTcgaXMgMjljNzEwMDAhDQpbICAx
OTEuMDMyNjA0XSAyZTk1OCBpcyAyOWM3MDAwMCENClsgIDE5MS4wNDQxOThdIDJlOTU5IGlz
IDI5YzZmMDAwIQ0KWyAgMTkxLjA0NjE4MF0gMmU5MjcgaXMgMjljNmUwMDAhDQpbICAxOTEu
MDQ4MTgxXSAyZTk1YSBpcyAyOWM2ZDAwMCENClsgIDE5MS4wNTAyMTFdIDJlOTI4IGlzIDI5
YzZjMDAwIQ0KWyAgMTkxLjA1MjE5MV0gMmU5NWIgaXMgMjljNmIwMDAhDQpbICAxOTEuMDU0
MTk4XSAyZTk1YyBpcyAyOWM2YTAwMCENClsgIDE5MS4wNTYxODRdIDJlOTI5IGlzIDI5YzY5
MDAwIQ0KWyAgMTkxLjA1ODIxMV0gMmU5NWQgaXMgMjljNjgwMDAhDQpbICAxOTEuMDYwMjE0
XSAyZTk1ZSBpcyAyOWM2NzAwMCENClsgIDE5MS4wNjIyMTNdIDJlOTVmIGlzIDI5YzY2MDAw
IQ0KWyAgMTkxLjA2NDIxOV0gMmU5NjAgaXMgMjljNjUwMDAhDQpbICAxOTEuMDY2MTk0XSAy
ZTk2MSBpcyAyOWM2NDAwMCENClsgIDE5MS4wNjgxOThdIDJlOTYyIGlzIDI5YzYzMDAwIQ0K
WyAgMTkxLjA3MDE1OF0gMmU5NjMgaXMgMjljNjIwMDAhDQpbICAxOTEuMDcyMTk3XSAyZTk2
NCBpcyAyOWM2MTAwMCENClsgIDE5MS4wNzQxNjBdIDJlOTJhIGlzIDI5YzYwMDAwIQ0KWyAg
MTkxLjA3NjA2M10gMmU5NjUgaXMgMjljNWYwMDAhDQpbICAxOTEuMDc4MDE1XSAyZTk2NiBp
cyAyOWM1ZTAwMCENClsgIDE5MS4wNzk5MTldIDJlOTY3IGlzIDI5YzVkMDAwIQ0KWyAgMTkx
LjA4MTg3MV0gMmU5NjggaXMgMjljNWMwMDAhDQpbICAxOTEuMDgzODAwXSAyZTk2OSBpcyAy
OWM1YjAwMCENClsgIDE5MS4wODU3MThdIDJlOTZhIGlzIDI5YzVhMDAwIQ0KWyAgMTkxLjA4
NzY1Nl0gMmU5NmIgaXMgMjljNTkwMDAhDQpbICAxOTEuMTA0MDIzXSAyZTk2YyBpcyAyOWM1
ODAwMCENClsgIDE5MS4xMDU5NTldIDJlOTJiIGlzIDI5YzU3MDAwIQ0KWyAgMTkxLjEwODAy
N10gMmU5NmQgaXMgMjljNTYwMDAhDQpbICAxOTEuMTEwMDEyXSAyZTk2ZSBpcyAyOWM1NTAw
MCENClsgIDE5MS4xMTIxOTBdIDJlOTZmIGlzIDI5YzU0MDAwIQ0KWyAgMTkxLjExNDI3N10g
MmU5NzAgaXMgMjljNTMwMDAhDQpbICAxOTEuMTE2Mjk1XSAyZTk3MSBpcyAyOWM1MjAwMCEN
ClsgIDE5MS4xMTg0NTBdIDJlOTcyIGlzIDI5YzUxMDAwIQ0KWyAgMTkxLjEyMDU3M10gMmU5
NzMgaXMgMjljNTAwMDAhDQpbICAxOTEuMTIyNTU5XSAyZTk3NCBpcyAyOWM0ZjAwMCENClsg
IDE5MS4xMjQ3MzNdIDJlOTc1IGlzIDI5YzRlMDAwIQ0KWyAgMTkxLjEyNzA2OV0gMmU5NzYg
aXMgMjljNGMwMDAhDQpbICAxOTEuMTI5MDU0XSAyZTk3NyBpcyAyOWM0YjAwMCENClsgIDE5
MS4xMzEwNjFdIDJlOTc4IGlzIDI5YzRhMDAwIQ0KWyAgMTkxLjEzMzA0MF0gMmU5NzkgaXMg
MjljNDkwMDAhDQpbICAxOTEuMTM1MDQ1XSAyZTk3YSBpcyAyOWM0ODAwMCENClsgIDE5MS4x
Mzg2MTddIDJlOTdiIGlzIDI5YzE0MDAwIQ0KWyAgMTkxLjE0MDcwMl0gMmU5MmMgaXMgMjlj
MTUwMDAhDQpbICAxOTEuMTQyNjk5XSAyZTk3YyBpcyAyOWMxNjAwMCENClsgIDE5MS4xNDQ4
MzRdIDJlOTdkIGlzIDI5YzE3MDAwIQ0KWyAgMTkxLjE0Njg1N10gMmU5N2UgaXMgMjljMTgw
MDAhDQpbICAxOTEuMTQ4ODc2XSAyZTk3ZiBpcyAyOWMxOTAwMCENClsgIDE5MS4xNTA4OTFd
IDJlOTgwIGlzIDI5YzFhMDAwIQ0KWyAgMTkxLjE1MjkyN10gMmU5MmQgaXMgMjljMWIwMDAh
DQpbICAxOTEuMTU0OTg1XSAyZTk4MSBpcyAyOWMxYzAwMCENClsgIDE5MS4xNTcwMTNdIDJl
OTgyIGlzIDI5YzFkMDAwIQ0KWyAgMTkxLjE1OTAzMl0gMmU5ODMgaXMgMjljMWUwMDAhDQpb
ICAxOTEuMTYxMTk0XSAyZTk4NCBpcyAyOWMxZjAwMCENClsgIDE5MS4xNjMyMDBdIDJlOTg1
IGlzIDI5YzIwMDAwIQ0KWyAgMTkxLjE2NTM3MF0gMmU5ODYgaXMgMjljMjEwMDAhDQpbICAx
OTEuMTY3NDYzXSAyZTk4NyBpcyAyOWMyMjAwMCENClsgIDE5MS4xNjk1MTVdIDJlOTg4IGlz
IDI5YzIzMDAwIQ0KWyAgMTkxLjE3MTY1NF0gMmU5ODkgaXMgMjljMjQwMDAhDQpbICAxOTEu
MTczNjg1XSAyZTk4YSBpcyAyOWMyNTAwMCENClsgIDE5MS4xNzU2ODFdIDJlOThiIGlzIDI5
YzJjMDAwIQ0KWyAgMTkxLjE3NzgxMl0gMmU5OGMgaXMgMjljM2YwMDAhDQpbICAxOTEuMTc5
ODA3XSAyZTk4ZCBpcyAyOWM0MDAwMCENClsgIDE5MS4xOTU2MDVdIDJlOThlIGlzIDI5YzNl
MDAwIQ0KWyAgMTkxLjE5NzcyOF0gMmU5MmUgaXMgMjljM2QwMDAhDQpbICAxOTEuMTk5NzU0
XSAyZTk4ZiBpcyAyOWM0MzAwMCENClsgIDE5MS4yMDE5MTJdIDJlOTkwIGlzIDI5YzQ0MDAw
IQ0KWyAgMTkxLjIwNDAyOF0gMmU5OTEgaXMgMjljNDUwMDAhDQpbICAxOTEuMjA2MDU4XSAy
ZTk5MiBpcyAyOWM0NjAwMCENClsgIDE5MS4yMDkyOTRdIDJlOTkzIGlzIDI5YzQ3MDAwIQ0K
WyAgMTkxLjIxMTQ0Nl0gMmU5OTQgaXMgMjljMzEwMDAhDQpbICAxOTEuMjEzNDk5XSAyZTk5
NSBpcyAyOWM0MjAwMCENClsgIDE5MS4yMTU1NTRdIDJlOTk2IGlzIDI5YzJmMDAwIQ0KWyAg
MTkxLjIxNzYyN10gMmU5OTcgaXMgMjljM2MwMDAhDQpbICAxOTEuMjE5NzExXSAyZTkyZiBp
cyAyOWMyNjAwMCENClsgIDE5MS4yMjE3ODhdIDJlOTk4IGlzIDI5YzMwMDAwIQ0KWyAgMTkx
LjIyMzkwMF0gMmU5MzAgaXMgMjljMmIwMDAhDQpbICAxOTEuMjMwNzcyXSAyZTkzMSBpcyAy
OWM0MTAwMCENClsgIDE5MS4yMzI5MDVdIDJlOTk5IGlzIDI5YzJkMDAwIQ0KWyAgMTkxLjIz
NTE5MF0gMmU5OWEgaXMgMjljMmUwMDAhDQpbICAxOTEuMjM3NDExXSAyZTk5YiBpcyAyOTVm
OTAwMCENClsgIDE5MS4yMzk1NDddIDJlOTljIGlzIDI5YzM4MDAwIQ0KWyAgMTkxLjI0MTgz
MV0gMmU5OWQgaXMgMjljMzkwMDAhDQpbICAxOTEuMjQ0MDg3XSAyZTk5ZSBpcyAyOWMzNzAw
MCENClsgIDE5MS4yNDYyMzVdIDJlOTlmIGlzIDI5NWVjMDAwIQ0KWyAgMTkxLjI1NzgwN10g
MmU5YTAgaXMgMjkzOTUwMDAhDQpbICAxOTEuMjU5OTgyXSAyZTkzMiBpcyAyOWMyYTAwMCEN
ClsgIDE5MS4yNjg4NjNdIDJlOWExIGlzIDI5MGE5MDAwIQ0KWyAgMTkxLjI3MTMxNV0gMmU5
YTIgaXMgMjk4NTgwMDAhDQpbICAxOTEuMjczNTQyXSAyZTlhMyBpcyAyOWMxMzAwMCENClsg
IDE5MS4yNzU4ODddIDJlOWE0IGlzIDI5YzM2MDAwIQ0KWyAgMTkxLjI3ODE2N10gMmU5MzMg
aXMgMjljMzUwMDAhDQpbICAxOTEuMjg1NDIzXSAyZTlhNSBpcyAyOWMzNDAwMCENClsgIDE5
MS4yODc3MTldIDJlOTM0IGlzIDI5YzMzMDAwIQ0KWyAgMTkxLjI5MDAwN10gMmU5MzUgaXMg
MjljMTIwMDAhDQpbICAxOTEuMjkyMjkxXSAyZTlhNiBpcyAyOWMxMTAwMCENClsgIDE5MS4y
OTQ2MDhdIDJlOTM2IGlzIDI5YzEwMDAwIQ0KWyAgMTkxLjI5NjkzMF0gMmU5MzcgaXMgMjlj
MGYwMDAhDQpbICAxOTEuMjk5MzE3XSAyZTlhNyBpcyAyOWMwZTAwMCENClsgIDE5MS4zMDE2
MDBdIDJlOTM4IGlzIDI5YzBkMDAwIQ0KWyAgMTkxLjMwMzkwNF0gMmU5YTggaXMgMjljMGMw
MDAhDQpbICAxOTEuMzIwNTA1XSAyZTkzOSBpcyAyOWMwYjAwMCENClsgIDE5MS4zMjI4MjFd
IDJlOTNhIGlzIDI5YzBhMDAwIQ0KWyAgMTkxLjMyNTI5NV0gMmU5YTkgaXMgMjljMDkwMDAh
DQpbICAxOTEuMzI3NzAxXSAyZTlhYSBpcyAyOWMwODAwMCENClsgIDE5MS4zMjk5ODRdIDJl
OWFiIGlzIDI5YzA3MDAwIQ0KWyAgMTkxLjMzMjQyM10gMmU5YWMgaXMgMjljMDYwMDAhDQpb
ICAxOTEuMzM0NzkyXSAyZTlhZSBpcyAyOWMwNTAwMCENClsgIDE5MS4zMzcwNjldIDJlOWFm
IGlzIDI5YzA0MDAwIQ0KWyAgMTkxLjMzOTMxMV0gMmU5YjAgaXMgMjljMDMwMDAhDQpbICAx
OTEuMzQxNzA4XSAyZTliMSBpcyAyOWMwMjAwMCENClsgIDE5MS4zNDQwMjJdIDJlOWIyIGlz
IDI5YzAxMDAwIQ0KWyAgMTkxLjM0NjM5OV0gMmU5YjMgaXMgMjljMDAwMDAhDQpbICAxOTEu
MzQ4Njg2XSAyZTkzYiBpcyAyOWJmZjAwMCENClsgIDE5MS4zNTA5MzhdIDJlOWI0IGlzIDI5
YmZlMDAwIQ0KWyAgMTkxLjM1MzE3MF0gMmU5YjUgaXMgMjliZmQwMDAhDQpbICAxOTEuMzU1
NDA3XSAyZTliNiBpcyAyOWJmYzAwMCENClsgIDE5MS4zNTc2MzNdIDJlOWI3IGlzIDI5YmZi
MDAwIQ0KWyAgMTkxLjM1OTc5NF0gMmU5YjggaXMgMjliZmEwMDAhDQpbICAxOTEuMzc3NjE2
XSAyZTliOSBpcyAyOWJmOTAwMCENClsgIDE5MS4zNzk3NjNdIDJlOWJhIGlzIDI5YmY4MDAw
IQ0KWyAgMTkxLjM4MTkyMl0gMmU5YmIgaXMgMjliZjcwMDAhDQpbICAxOTEuMzg0MDY3XSAy
ZTkzYyBpcyAyOWJmNjAwMCENClsgIDE5MS4zODYyMjZdIDJlOWQ4IGlzIDI5YmY1MDAwIQ0K
WyAgMTkxLjM4ODM2OV0gMmU5YmMgaXMgMjliZjQwMDAhDQpbICAxOTEuMzkwNTU4XSAyZTlk
OSBpcyAyOWJmMzAwMCENClsgIDE5MS4zOTI2OTZdIDJlOWRhIGlzIDI5YmYyMDAwIQ0KWyAg
MTkxLjM5NDg4NV0gMmU5YmQgaXMgMjliZjEwMDAhDQpbICAxOTEuMzk3MDM4XSAyZTliZSBp
cyAyOWJmMDAwMCENClsgIDE5MS4zOTkxODldIDJlOWJmIGlzIDI5YmVmMDAwIQ0KWyAgMTkx
LjQwMTUyMF0gMmU5YzAgaXMgMjliZWUwMDAhDQpbICAxOTEuNDExNTQ4XSAyZTljMSBpcyAy
OWJlZDAwMCENClsgIDE5MS40MTM3MDddIDJlOWRiIGlzIDI5YmVjMDAwIQ0KWyAgMTkxLjQx
NTg2Nl0gMmU5YzIgaXMgMjliZWIwMDAhDQpbICAxOTEuNDE4MTY3XSAyZTljMyBpcyAyOWJl
YTAwMCENClsgIDE5MS40MjAyMjhdIDJlOWM0IGlzIDI5YmU5MDAwIQ0KWyAgMTkxLjQyMjQ3
Nl0gMmU5YzUgaXMgMjliZTgwMDAhDQpbICAxOTEuNDI0NjM0XSAyZTlkYyBpcyAyOWJlNzAw
MCENClsgIDE5MS40MjY4MTJdIDJlOWM2IGlzIDI5YmU2MDAwIQ0KWyAgMTkxLjQyODk2OF0g
MmU5YzcgaXMgMjliZTUwMDAhDQpbICAxOTEuNDMxMTQ3XSAyZTljOCBpcyAyOWJlNDAwMCEN
ClsgIDE5MS40MzMzMDZdIDJlOWRkIGlzIDI5YmUzMDAwIQ0KWyAgMTkxLjQzNTQ5MV0gMmU5
YzkgaXMgMjliZTIwMDAhDQpbICAxOTEuNDM3Njg4XSAyZTlkZSBpcyAyOWJlMTAwMCENClsg
IDE5MS40NDM0MzFdIDJlOWNhIGlzIDI5YmUwMDAwIQ0KWyAgMTkxLjQ0NTU0OF0gMmU5Y2Ig
aXMgMjliZGYwMDAhDQpbICAxOTEuNDQ3ODc5XSAyZTljYyBpcyAyOWJkZTAwMCENClsgIDE5
MS40NTAwMjNdIDJlOWNkIGlzIDI5YmRkMDAwIQ0KWyAgMTkxLjQ1MjM2Ml0gMmU5Y2UgaXMg
MjliZGMwMDAhDQpbICAxOTEuNDU0NjIzXSAyZTljZiBpcyAyOWJkYjAwMCENClsgIDE5MS40
NTY3OTldIDJlOWQwIGlzIDI5YmRhMDAwIQ0KWyAgMTkxLjQ1ODk1M10gMmU5ZDEgaXMgMjli
ZDkwMDAhDQpbICAxOTEuNTA0OTUzXSAyZTlkMiBpcyAyOWJkODAwMCENClsgIDE5MS41MDcx
MzhdIDJlOWRmIGlzIDI5YmQ3MDAwIQ0KWyAgMTkxLjUwOTI3OV0gMmU5ZTAgaXMgMjliZDYw
MDAhDQpbICAxOTEuNTExNDQ3XSAyZTlkMyBpcyAyOWJkNTAwMCENClsgIDE5MS41MTM2MjVd
IDJlOWUxIGlzIDI5YmQ0MDAwIQ0KWyAgMTkxLjUxNTg3NF0gMmU5ZDQgaXMgMjliZDMwMDAh
DQpbICAxOTEuNTE4MDEzXSAyZTllMiBpcyAyOWJkMjAwMCENClsgIDE5MS41MjAxNjVdIDJl
OWQ1IGlzIDI5YmQxMDAwIQ0KWyAgMTkxLjUyMzI1Nl0gMmVhMDAgaXMgMjliYmIwMDAhDQpb
ICAxOTEuNTI1MDUwXSAyZWEwMSBpcyAyOWJiYzAwMCENClsgIDE5MS41MjY4MzhdIDJlYTAy
IGlzIDI5YmJkMDAwIQ0KWyAgMTkxLjUyODU4OV0gMmVhMDMgaXMgMjliYmUwMDAhDQpbICAx
OTEuNTMwMzUzXSAyZWEwNCBpcyAyOWJiZjAwMCENClsgIDE5MS41MzIxMTBdIDJlYTA1IGlz
IDI5YmMwMDAwIQ0KWyAgMTkxLjUzMzg4Ml0gMmVhMDYgaXMgMjliYzEwMDAhDQpbICAxOTEu
NTM1NjQ5XSAyZWEwNyBpcyAyOWJjMjAwMCENClsgIDE5MS41Mzc0MTZdIDJlYTA4IGlzIDI5
YmMzMDAwIQ0KWyAgMTkxLjUzOTE3N10gMmVhMDkgaXMgMjliYzQwMDAhDQpbICAxOTEuNTQw
OTMzXSAyZWEwYSBpcyAyOWJjNTAwMCENClsgIDE5MS41NDMxMzJdIDJlYTBiIGlzIDI5YmIx
MDAwIQ0KWyAgMTkxLjU0NDkwMl0gMmVhMGMgaXMgMjliYjIwMDAhDQpbICAxOTEuNTQ2NjMw
XSAyZWEwZCBpcyAyOWJiMzAwMCENClsgIDE5MS41NDgzODVdIDJlYTBlIGlzIDI5YmI0MDAw
IQ0KWyAgMTkxLjU1MDExOV0gMmVhMGYgaXMgMjliYjUwMDAhDQpbICAxOTEuNTUxODQ4XSAy
ZWExMCBpcyAyOWJiNjAwMCENClsgIDE5MS41NTM1NzVdIDJlYTExIGlzIDI5YmI3MDAwIQ0K
WyAgMTkxLjU1NTI4NV0gMmVhMTIgaXMgMjliYjgwMDAhDQpbICAxOTEuNTU3MDE2XSAyZWEx
MyBpcyAyOWJiOTAwMCENClsgIDE5MS41NTg3MTVdIDJlYTE0IGlzIDI5YmJhMDAwIQ0KWyAg
MTkxLjU2MDQ0MV0gMmVhMTUgaXMgMjliYTYwMDAhDQpbICAxOTEuNTYyMTQwXSAyZWExOFsg
IDE5My42OTY4MTRdIDJlNWVjIGlzIDI5ZWUxMDAwIQ0KWyAgMTkzLjY5ODkxNl0gMmU1YWIg
aXMgMjllZTAwMDAhDQpbICAxOTMuNzAxMDA1XSAyZTVlZCBpcyAyOWVkZjAwMCENClsgIDE5
My43MDMxMzFdIDJlNWFjIGlzIDI5ZWRlMDAwIQ0KWyAgMTkzLjcwNTI0OF0gMmU1ZWUgaXMg
MjllZGQwMDAhDQpbICAxOTMuNzA3Mzg2XSAyZTVhZCBpcyAyOWVkYzAwMCENClsgIDE5My43
MDk0ODNdIDJlNWFlIGlzIDI5ZWRiMDAwIQ0KWyAgMTkzLjcxMTYxN10gMmU1ZWYgaXMgMjll
ZGEwMDAhDQpbICAxOTMuNzEzNzIyXSAyZTVmMCBpcyAyOWVkOTAwMCENClsgIDE5My43MTU4
NDRdIDJlNWYxIGlzIDI5ZWQ4MDAwIQ0KWyAgMTkzLjcxODA2MF0gMmU1ZjIgaXMgMjllZDcw
MDAhDQpbICAxOTMuNzIwMjAyXSAyZTVmMyBpcyAyOWVkNjAwMCENClsgIDE5My43MjIzMTRd
IDJlNWY0IGlzIDI5ZWQ1MDAwIQ0KWyAgMTkzLjcyNDQ3NV0gMmU1ZjUgaXMgMjllZDQwMDAh
DQpbICAxOTMuNzI2NTczXSAyZTVmNiBpcyAyOWVkMzAwMCENClsgIDE5My43Mjg3MTZdIDJl
NWY3IGlzIDI5ZWQyMDAwIQ0KWyAgMTkzLjczMDg0MF0gMmU1ZjggaXMgMjllZDEwMDAhDQpb
ICAxOTMuNzMyOTYwXSAyZTVmOSBpcyAyOWVkMDAwMCENClsgIDE5My43Mzk4MDBdIDJlNWZh
IGlzIDI5ZWNmMDAwIQ0KWyAgMTkzLjc0MTg5N10gMmU1YWYgaXMgMjllY2UwMDAhDQpbICAx
OTMuNzQ0MDAwXSAyZTViMCBpcyAyOWVjZDAwMCENClsgIDE5My43NDYwODldIDJlNWIxIGlz
IDI5ZWNjMDAwIQ0KWyAgMTkzLjc0ODE4OF0gMmU1ZmIgaXMgMjllY2IwMDAhDQpbICAxOTMu
NzUwMjI4XSAyZTViMiBpcyAyOWVjYTAwMCENClsgIDE5My43NTIzMDBdIDJlNWZjIGlzIDI5
ZWM5MDAwIQ0KWyAgMTkzLjc1NDQ4M10gMmU1ZmQgaXMgMjllYzgwMDAhDQpbICAxOTMuNzU2
NTYxXSAyZTVmZSBpcyAyOWVjNzAwMCENClsgIDE5My43Njc1NzhdIDJlNWZmIGlzIDI5ZWM2
MDAwIQ0KWyAgMTkzLjc2OTcwMF0gMmU2MDAgaXMgMjllYzUwMDAhDQpbICAxOTMuNzcxOTcx
XSAyZTYwMSBpcyAyOWVjNDAwMCENClsgIDE5My43NzQyMDddIDJlNjAyIGlzIDI5ZWMzMDAw
IQ0KWyAgMTkzLjc3NjMyNV0gMmU2MDMgaXMgMjllYzIwMDAhDQpbICAxOTMuNzg0MDExXSAy
ZTYwNCBpcyAyOWVjMTAwMCENClsgIDE5My43ODYxNDVdIDJlNjA1IGlzIDI5ZWMwMDAwIQ0K
WyAgMTkzLjc4ODM5NV0gMmU2MDYgaXMgMjllYmYwMDAhDQpbICAxOTMuNzkwNjAxXSAyZTYw
NyBpcyAyOWViZTAwMCENClsgIDE5My43OTI2ODNdIDJlNjA4IGlzIDI5ZWJkMDAwIQ0KWyAg
MTkzLjc5NDkyMV0gMmU2MDkgaXMgMjllYmMwMDAhDQpbICAxOTMuNzk2OTkxXSAyZTYwYSBp
cyAyOWViYjAwMCENClsgIDE5My43OTkwMjVdIDJlNjBiIGlzIDI5ZWJhMDAwIQ0KWyAgMTkz
LjgxNDE5OV0gMmU1YjMgaXMgMjllYjkwMDAhDQpbICAxOTMuODE2MjgwXSAyZTViNCBpcyAy
OWViODAwMCENClsgIDE5My44MTgzNzldIDJlNjBjIGlzIDI5ZWI3MDAwIQ0KWyAgMTkzLjgy
MDQ3N10gMmU1YjUgaXMgMjllYjYwMDAhDQpbICAxOTMuODIyNTY3XSAyZTViNiBpcyAyOWVi
NTAwMCENClsgIDE5My44MjQ2NzFdIDJlNjBkIGlzIDI5ZWI0MDAwIQ0KWyAgMTkzLjgyNjgx
Ml0gMmU1YjcgaXMgMjllYjMwMDAhDQpbICAxOTMuODI4OTMzXSAyZTYwZSBpcyAyOWViMjAw
MCENClsgIDE5My44MzEwOTVdIDJlNjBmIGlzIDI5ZWIxMDAwIQ0KWyAgMTkzLjgzMzIyMV0g
MmU2MTAgaXMgMjllYjAwMDAhDQpbICAxOTMuODM1NDA2XSAyZTYxMSBpcyAyOWVhZjAwMCEN
ClsgIDE5My44Mzc1ODhdIDJlNjEyIGlzIDI5ZWFlMDAwIQ0KWyAgMTkzLjgzOTcxOV0gMmU2
MTMgaXMgMjllYWQwMDAhDQpbICAxOTMuODQxOTA0XSAyZTYxNCBpcyAyOWVhYzAwMCENClsg
IDE5My44NDQxODRdIDJlNjE1IGlzIDI5ZWFiMDAwIQ0KWyAgMTkzLjg0NjMxMV0gMmU2MTYg
aXMgMjllYWEwMDAhDQpbICAxOTMuODQ4NDk1XSAyZTYxNyBpcyAyOWVhOTAwMCENClsgIDE5
My44NjIzNTldIDJlNjE4IGlzIDI5ZWE4MDAwIQ0KWyAgMTkzLjg2NDQ3Nl0gMmU2MTkgaXMg
MjllYTcwMDAhDQpbICAxOTMuODY2NTg4XSAyZTViOCBpcyAyOWVhNjAwMCENClsgIDE5My44
Njg4NzZdIDJlNjFhIGlzIDI5ZWE1MDAwIQ0KWyAgMTkzLjg3MTAxOF0gMmU1YjkgaXMgMjll
YTQwMDAhDQpbICAxOTMuODczMTk3XSAyZTViYSBpcyAyOWVhMzAwMCENClsgIDE5My44NzUz
NjldIDJlNjFiIGlzIDI5ZWEyMDAwIQ0KWyAgMTkzLjg3NzU2OV0gMmU1YmIgaXMgMjllYTEw
MDAhDQpbICAxOTMuODc5NzIxXSAyZTYxYyBpcyAyOWVhMDAwMCENClsgIDE5My44ODE5NTBd
IDJlNjFkIGlzIDI5ZTlmMDAwIQ0KWyAgMTkzLjg4NDE1OF0gMmU2MWUgaXMgMjllOWUwMDAh
DQpbICAxOTMuODg2MzM2XSAyZTYxZiBpcyAyOWU5ZDAwMCENClsgIDE5My44ODg1NTFdIDJl
NjIwIGlzIDI5ZTljMDAwIQ0KWyAgMTkzLjg5MDc1M10gMmU2MjEgaXMgMjllOWIwMDAhDQpb
ICAxOTMuODkyOTE1XSAyZTYyMiBpcyAyOWU5YTAwMCENClsgIDE5My44OTUxMDVdIDJlNjIz
IGlzIDI5ZTk5MDAwIQ0KWyAgMTkzLjkwNjExMV0gMmU2MjQgaXMgMjllOTgwMDAhDQpbICAx
OTMuOTA4MjQ4XSAyZTViYyBpcyAyOWU5NzAwMCENClsgIDE5My45MTA0MzJdIDJlNWJkIGlz
IDI5ZTk2MDAwIQ0KWyAgMTkzLjkxMjYwNV0gMmU1YmUgaXMgMjllOTUwMDAhDQpbICAxOTMu
OTE0NzkyXSAyZTYyNSBpcyAyOWU5NDAwMCENClsgIDE5My45MTY4OTFdIDJlNWJmIGlzIDI5
ZTkzMDAwIQ0KWyAgMTkzLjkxOTE1NV0gMmU2MjYgaXMgMjllOTIwMDAhDQpbICAxOTMuOTIx
MzIxXSAyZTVjMCBpcyAyOWU5MTAwMCENClsgIDE5My45MjM1MjVdIDJlNjI3IGlzIDI5ZTkw
MDAwIQ0KWyAgMTkzLjkyNTY5OF0gMmU2MjggaXMgMjllOGYwMDAhDQpbICAxOTMuOTI3ODg4
XSAyZTYyOSBpcyAyOWU4ZTAwMCENClsgIDE5My45MzAwMjNdIDJlNWMxIGlzIDI5ZThkMDAw
IQ0KWyAgMTkzLjkzMjUyMl0gMmU2MmEgaXMgMjllODUwMDAhDQpbICAxOTMuOTM0MzMzXSAy
ZTVjMiBpcyAyOWU4NjAwMCENClsgIDE5My45MzYxNDhdIDJlNWMzIGlzIDI5ZTg3MDAwIQ0K
WyAgMTkzLjkzNzk2N10gMmU2NDAgaXMgMjllODgwMDAhDQpbICAxOTMuOTM5Nzg4XSAyZTY0
MSBpcyAyOWU4OTAwMCENClsgIDE5My45NDE2MDVdIDJlNjQyIGlzIDI5ZThhMDAwIQ0KWyAg
MTkzLjk0MzQzMV0gMmU2NDMgaXMgMjllOGIwMDAhDQpbICAxOTMuOTQ1MjE5XSAyZTY0NCBp
cyAyOWU4YzAwMCENClsgIDE5My45NDc5MTVdIDJlNjM1IGlzIDI5ZTc1MDAwIQ0KWyAgMTkz
Ljk0OTcwM10gMmU2MzYgaXMgMjllNzYwMDAhDQpbICAxOTMuOTUxNTAxXSAyZTYzNyBpcyAy
OWU3NzAwMCENClsgIDE5My45NTMyNzFdIDJlNjM4IGlzIDI5ZTc4MDAwIQ0KWyAgMTkzLjk1
NTA0Ml0gMmU2MzkgaXMgMjllNzkwMDAhDQpbICAxOTMuOTU2ODEzXSAyZTY0NSBpcyAyOWU3
YTAwMCENClsgIDE5My45NTg1NjZdIDJlNjJiIGlzIDI5ZTdiMDAwIQ0KWyAgMTkzLjk2MDM1
M10gMmU2MmMgaXMgMjllN2MwMDAhDQpbICAxOTMuOTYyMTExXSAyZTYyZCBpcyAyOWU3ZDAw
MCENClsgIDE5My45NjM4ODNdIDJlNjJlIGlzIDI5ZTdlMDAwIQ0KWyAgMTkzLjk2NTY1OF0g
MmU2MmYgaXMgMjllN2YwMDAhDQpbICAxOTMuOTY3NDM0XSAyZTYzMCBpcyAyOWU4MDAwMCEN
ClsgIDE5My45NjkyMjBdIDJlNjMxIGlzIDI5ZTgxMDAwIQ0KWyAgMTkzLjk3MDk5MF0gMmU2
MzIgaXMgMjllODIwMDAhDQpbICAxOTMuOTcyNzU5XSAyZTYzMyBpcyAyOWU4MzAwMCENClsg
IDE5My45NzQ1MjZdIDJlNjM0IGlzIDI5ZTg0MDAwIQ0KWyAgMTkzLjk3NzI3OF0gMmU2M2Eg
aXMgMjllNmEwMDAhDQpbICAxOTMuOTc5MDIxXSAyZTYzYiBpcyAyOWU2YjAwMCENClsgIDE5
My45ODA3ODNdIDJlNjNjIGlzIDI5ZTZjMDAwIQ0KWyAgMTkzLjk4MjUwM10gMmU2M2QgaXMg
MjllNmQwMDAhDQpbICAxOTMuOTg0MjIzXSAyZTYzZSBpcyAyOWU2ZTAwMCENClsgIDE5My45
ODU5MzRdIDJlNjNmIGlzIDI5ZTZmMDAwIQ0KWyAgMTkzLjk4NzY0N10gMmU2NWYgaXMgMjll
NzAwMDAhDQpbICAxOTMuOTg5MzU1XSAyZTY2MCBpcyAyOWU3MTAwMCENClsgIDE5My45OTEw
NTZdIDJlNjYxIGlzIDI5ZTcyMDAwIQ0KWyAgMTkzLjk5MjczNV0gMmU2NjIgaXMgMjllNzMw
MDAhDQpbICAxOTMuOTk0NDQzXSAyZTY2MyBpcyAyOWU3NDAwMCENClsgIDE5My45OTYzMzdd
IDJlNjZmIGlzIDI5ZTU1MDAwIQ0KWyAgMTkzLjk5ODEwNV0gMmU2NzAgaXMgMjllNTYwMDAh
DQpbICAxOTMuOTk5NzgwXSAyZTY3MSBpcyAyOWU1NzAwMCENClsgIDE5NC4wMDE0ODJdIDJl
NjcyIGlzIDI5ZTU4MDAwIQ0KWyAgMTk0LjAwMzE2NV0gMmU2NzMgaXMgMjllNTkwMDAhDQpb
ICAxOTQuMDA0ODU4XSAyZTY3NCBpcyAyOWU1YTAwMCENClsgIDE5NC4wMDY1NTNdIDJlNjc1
IGlzIDI5ZTViMDAwIQ0KWyAgMTk0LjAwODIzN10gMmU2NzYgaXMgMjllNWMwMDAhDQpbICAx
OTQuMDA5OTQyXSAyZTY3NyBpcyAyOWU1ZDAwMCENClsgIDE5NC4wMTE2MzJdIDJlNjc4IGlz
IDI5ZTVlMDAwIQ0KWyAgMTk0LjAxMzMwNV0gMmU2NzkgaXMgMjllNGEwMDAhDQpbICAxOTQu
MDE1MDA2XSAyZTY3YSBpcyAyOWU0YjAwMCENClsgIDE5NC4wMTY2NjddIDJlNjdiIGlzIDI5
ZTRjMDAwIQ0KWyAgMTk0LjAxODM1NF0gMmU2N2MgaXMgMjllNGQwMDAhDQpbICAxOTQuMDIw
MDE0XSAyZTY3ZCBpcyAyOWU0ZTAwMCENClsgIDE5NC4wMjE2ODddIDJlNjdlIGlzIDI5ZTRm
MDAwIQ0KWyAgMTk0LjAyMzM1Ml0gMmU2N2YgaXMgMjllNTAwMDAhDQpbICAxOTQuMDI1MDE5
XSAyZTY4MCBpcyAyOWU1MTAwMCENClsgIDE5NC4wMjY2OTZdIDJlNjgxIGlzIDI5ZTUyMDAw
IQ0KWyAgMTk0LjAyODM2OF0gMmU2ODIgaXMgMjllNTMwMDAhDQpbICAxOTQuMDMwMDMwXSAy
ZTY4MyBpcyAyOWU1NDAwMCENClsgIDE5NC4wMzE3MjBdIDJlNjY0IGlzIDI5ZTVmMDAwIQ0K
WyAgMTk0LjAzMzM5M10gMmU2NjUgaXMgMjllNjAwMDAhDQpbICAxOTQuMDM1MDcyXSAyZTY2
NiBpcyAyOWU2MTAwMCENClsgIDE5NC4wMzY3NTFdIDJlNjY3IGlzIDI5ZTYyMDAwIQ0KWyAg
MTk0LjAzODQyM10gMmU2NjggaXMgMjllNjMwMDAhDQpbICAxOTQuMDQwMTIzXSAyZTY2OSBp
cyAyOWU2NDAwMCENClsgIDE5NC4wNDE3ODNdIDJlNjZhIGlzIDI5ZTY1MDAwIQ0KWyAgMTk0
LjA0MzQ2MF0gMmU2NmIgaXMgMjllNjYwMDAhDQpbICAxOTQuMDQ1MTEwXSAyZTY2YyBpcyAy
OWU2NzAwMCENClsgIDE5NC4wNDY3NjVdIDJlNjZkIGlzIDI5ZTY4MDAwIQ0KWyAgMTk0LjA0
ODQyNV0gMmU2NmUgaXMgMjllNjkwMDAhDQpbICAxOTQuMDUxNTM4XSAyZTY5OSBpcyAyOWUx
NTAwMCENClsgIDE5NC4wNTMyNjldIDJlNjlhIGlzIDI5ZTE2MDAwIQ0KWyAgMTk0LjA1NDkz
Nl0gMmU2OWIgaXMgMjllMTcwMDAhDQpbICAxOTQuMDU2NTg0XSAyZTY5YyBpcyAyOWUxODAw
MCENClsgIDE5NC4wNTgyMzFdIDJlNjlkIGlzIDI5ZTE5MDAwIQ0KWyAgMTk0LjA1OTg3N10g
MmU2YTAgaXMgMjllMWEwMDAhDQpbICAxOTQuMDYxNTMzXSAyZTZhMSBpcyAyOWUxYjAwMCEN
ClsgIDE5NC4wNjMxODJdIDJlNmEyIGlzIDI5ZTFjMDAwIQ0KWyAgMTk0LjA2NDg2Ml0gMmU2
YTMgaXMgMjllMWQwMDAhDQpbICAxOTQuMDY2NTA1XSAyZTZhNCBpcyAyOWUxZTAwMCENClsg
IDE5NC4wNjgxNjldIDJlNjQ2IGlzIDI5ZTFmMDAwIQ0KWyAgMTk0LjA2OTgyMF0gMmU2OTgg
aXMgMjllMjAwMDAhDQpbICAxOTQuMDcxNDkzXSAyZTY5NyBpcyAyOWUyMTAwMCENClsgIDE5
NC4wNzMxNzVdIDJlNjk2IGlzIDI5ZTIyMDAwIQ0KWyAgMTk0LjA3NDg1NF0gMmU2OTUgaXMg
MjllMjMwMDAhDQpbICAxOTQuMDc2NTM1XSAyZTY5NCBpcyAyOWUyNDAwMCENClsgIDE5NC4w
NzgyMDhdIDJlNjkzIGlzIDI5ZTI1MDAwIQ0KWyAgMTk0LjA3OTg2M10gMmU2OTIgaXMgMjll
MjYwMDAhDQpbICAxOTQuMDgxNTQ3XSAyZTY5MSBpcyAyOWUyNzAwMCENClsgIDE5NC4wODMy
MDhdIDJlNjkwIGlzIDI5ZTI4MDAwIQ0KWyAgMTk0LjA4NDg5MF0gMmU2OGYgaXMgMjllMjkw
MDAhDQpbICAxOTQuMDg3NDI0XSAyZTY4ZSBpcyAyOWRlYTAwMCENClsgIDE5NC4wODkxNzFd
IDJlNjhkIGlzIDI5ZGViMDAwIQ0KWyAgMTk0LjA5MDg1Nl0gMmU2OGMgaXMgMjlkZWMwMDAh
DQpbICAxOTQuMDkyNTI4XSAyZTY4YiBpcyAyOWRlZDAwMCENClsgIDE5NC4wOTQyNzRdIDJl
NjhhIGlzIDI5ZGVlMDAwIQ0KWyAgMTk0LjA5NTk1NF0gMmU2ODkgaXMgMjlkZWYwMDAhDQpb
ICAxOTQuMDk3NjYxXSAyZTY4OCBpcyAyOWRmMDAwMCENClsgIDE5NC4wOTkzNzVdIDJlNjg3
IGlzIDI5ZGYxMDAwIQ0KWyAgMTk0LjEwMTA3OV0gMmU2ODYgaXMgMjlkZjIwMDAhDQpbICAx
OTQuMTAyNzkxXSAyZTY4NSBpcyAyOWRmMzAwMCENClsgIDE5NC4xMDQ1MDddIDJlNjg0IGlz
IDI5ZGY0MDAwIQ0KWyAgMTk0LjEwNjM5OV0gMmU2NWIgaXMgMjlkZDQwMDAhDQpbICAxOTQu
MTA4MTA1XSAyZTY1MCBpcyAyOWRkZjAwMCENClsgIDE5NC4xMDk4MTBdIDJlNjRmIGlzIDI5
ZGUwMDAwIQ0KWyAgMTk0LjExMTUyM10gMmU2NGUgaXMgMjlkZTEwMDAhDQpbICAxOTQuMTEz
MjMxXSAyZTY0ZCBpcyAyOWRlMjAwMCENClsgIDE5NC4xMTQ5NjFdIDJlNjRjIGlzIDI5ZGUz
MDAwIQ0KWyAgMTk0LjExNjY1MF0gMmU2NGIgaXMgMjlkZTQwMDAhDQpbICAxOTQuMTE4MzY5
XSAyZTY0YSBpcyAyOWRlNTAwMCENClsgIDE5NC4xMjAwNzZdIDJlNjQ5IGlzIDI5ZGU2MDAw
IQ0KWyAgMTk0LjEyMTc3N10gMmU2NDggaXMgMjlkZTcwMDAhDQpbICAxOTQuMTIzNDk2XSAy
ZTY0NyBpcyAyOWRlODAwMCENClsgIDE5NC4xMjUxNzRdIDJlNmE1IGlzIDI5ZGU5MDAwIQ0K
WyAgMTk0LjEyNjg4MF0gMmU2NWEgaXMgMjlkZDUwMDAhDQpbICAxOTQuMTI4NTY5XSAyZTY1
OSBpcyAyOWRkNjAwMCENClsgIDE5NC4xMzAyNzJdIDJlNjU4IGlzIDI5ZGQ3MDAwIQ0KWyAg
MTk0LjEzMTk4M10gMmU2NTcgaXMgMjlkZDgwMDAhDQpbICAxOTQuMTMzNjkxXSAyZTY1NiBp
cyAyOWRkOTAwMCENClsgIDE5NC4xMzU0MDNdIDJlNjU1IGlzIDI5ZGRhMDAwIQ0KWyAgMTk0
LjEzNzEwNV0gMmU2NTQgaXMgMjlkZGIwMDAhDQpbICAxOTQuMTM4ODAzXSAyZTY1MyBpcyAy
OWRkYzAwMCENClsgIDE5NC4xNDA0ODhdIDJlNjUyIGlzIDI5ZGRkMDAwIQ0KWyAgMTk0LjE0
MjE1NF0gMmU2NTEgaXMgMjlkZGUwMDAhDQpbICAxOTQuMTQ0MTc0XSAyZTZhNiBpcyAyOWRk
MzAwMCENClsgIDE5NC4xNDYyMDFdIDJlNjVjIGlzIDI5ZGQyMDAwIQ0KWyAgMTk0LjE0OTc5
MF0gMmU2YTcgaXMgMjlkZDEwMDAhDQpbICAxOTQuMTU5MzY3XSAyZTY1ZCBpcyAyOWRkMDAw
MCENClsgIDE5NC4xNjE1MThdIDJlNmE4IGlzIDI5ZGNmMDAwIQ0KWyAgMTk0LjE2MzUzNF0g
MmU2YTkgaXMgMjlkY2UwMDAhDQpbICAxOTQuMTY3ODY4XSAyZTZhYSBpcyAyOWRhYjAwMCEN
ClsgIDE5NC4xNjk5ODNdIDJlNjVlIGlzIDI5ZGFjMDAwIQ0KWyAgMTk0LjE4MDA2NF0gMmU2
YWIgaXMgMjlkYWQwMDAhDQpbICAxOTQuMTgyMjI3XSAyZTZiZSBpcyAyOWRhZTAwMCENClsg
IDE5NC4xODQ0NTJdIDJlNmFjIGlzIDI5ZGI1MDAwIQ0KWyAgMTk0LjE4NjU3NF0gMmU2YWQg
aXMgMjlkYzQwMDAhDQpbICAxOTQuMjM4MTg5XSAyZTZhZSBpcyAyOWRjMzAwMCENClsgIDE5
NC4yNDAzMDZdIDJlNmFmIGlzIDI5ZGM1MDAwIQ0KWyAgMTk0LjI0MjM4NV0gMmU2YjAgaXMg
MjlkYzYwMDAhDQpbICAxOTQuMjQ0NTI0XSAyZTZiZiBpcyAyOWRjMDAwMCENClsgIDE5NC4y
NDY2NTFdIDJlNmIxIGlzIDI5ZGJmMDAwIQ0KWyAgMTk0LjI1Mjc4NV0gMmU2YjIgaXMgMjlk
YmUwMDAhDQpbICAxOTQuMjU0OTMxXSAyZTZiMyBpcyAyOWRiZDAwMCENClsgIDE5NC4yNjAy
NDZdIDJlNmI0IGlzIDI5ZGJiMDAwIQ0KWyAgMTk0LjI2MjM1N10gMmU2YzAgaXMgMjlkYzEw
MDAhDQpbICAxOTQuMjY3MDgzXSAyZTZjMSBpcyAyOWRiODAwMCENClsgIDE5NC4yNjkyMzNd
IDJlNmI1IGlzIDI5ZGJhMDAwIQ0KWyAgMTk0LjI3MTU0MF0gMmU2YjYgaXMgMjlkYWYwMDAh
DQpbICAxOTQuMjczNzU0XSAyZTZiNyBpcyAyOWRiMDAwMCENClsgIDE5NC4yNzU5MDldIDJl
NmI4IGlzIDI5ZGI5MDAwIQ0KWyAgMTk0LjI3ODI3MV0gMmU2YjkgaXMgMjlkYjQwMDAhDQpb
ICAxOTQuMjgwNTMwXSAyZTZiYSBpcyAyOWRjMjAwMCENClsgIDE5NC4yODI3MDFdIDJlNmJi
IGlzIDI5ZGI2MDAwIQ0KWyAgMTk0LjI4NTA0OF0gMmU2YmMgaXMgMjlkYjcwMDAhDQpbICAx
OTQuMjg3MzI3XSAyZTZiZCBpcyAyYTAxMDAwMCENClsgIDE5NC4yODk1MDddIDJlNmRlIGlz
IDI5ZGNjMDAwIQ0KWyAgMTk0LjI5MTgyMl0gMmU2ZGYgaXMgMjlkY2QwMDAhDQpbICAxOTQu
Mjk0MTA2XSAyZTZlMCBpcyAyOTVkYjAwMCENClsgIDE5NC4yOTYzMDNdIDJlNmUxIGlzIDJh
MDFiMDAwIQ0KWyAgMTk0LjI5ODY0MF0gMmU2ZTIgaXMgMjk1ZGMwMDAhDQpbICAxOTQuMzA2
OTM4XSAyZTZlMyBpcyAyOWRiMzAwMCENClsgIDE5NC4zMDkxNjhdIDJlNmMyIGlzIDI5YWM2
MDAwIQ0KWyAgMTk0LjMxMTUzMl0gMmU2ZTQgaXMgMjlkY2EwMDAhDQpbICAxOTQuMzEzODU5
XSAyZTZlNSBpcyAyOWRjOTAwMCENClsgIDE5NC4zMTYwODldIDJlNmU2IGlzIDI5ZGFhMDAw
IQ0KWyAgMTk0LjMxODQ2MV0gMmU2ZTcgaXMgMjlkYTkwMDAhDQpbICAxOTQuMzIwNzU1XSAy
ZTZlOCBpcyAyOWRhODAwMCENClsgIDE5NC4zMjI5ODhdIDJlNmU5IGlzIDI5ZGE3MDAwIQ0K
WyAgMTk0LjMyNTMxOV0gMmU2ZWEgaXMgMjlkYTYwMDAhDQpbICAxOTQuMzI3NjA4XSAyZTZl
YiBpcyAyOWRhNTAwMCENClsgIDE5NC4zMjk3OTNdIDJlNmVjIGlzIDI5ZGE0MDAwIQ0KWyAg
MTk0LjMzMjEyM10gMmU2ZWQgaXMgMjlkYTMwMDAhDQpbICAxOTQuMzM0NDAxXSAyZTZlZSBp
cyAyOWRhMjAwMCENClsgIDE5NC4zMzY1ODddIDJlNmVmIGlzIDI5ZGExMDAwIQ0KWyAgMTk0
LjMzODkxNV0gMmU2ZjAgaXMgMjlkYTAwMDAhDQpbICAxOTQuMzQxMTc4XSAyZTZmMSBpcyAy
OWQ5ZjAwMCENClsgIDE5NC4zNDM3ODhdIDJlNmYyIGlzIDI5ZDlkMDAwIQ0KWyAgMTk0LjM0
NTk3NF0gMmU2ZjMgaXMgMjlkOWMwMDAhDQpbICAxOTQuMzQ5NTQ0XSAyZTZmNCBpcyAyOWQ5
YjAwMCENClsgIDE5NC4zNTE3MzldIDJlNmMzIGlzIDI5ZDlhMDAwIQ0KWyAgMTk0LjM1Mzky
OV0gMmU2YzUgaXMgMjlkOTkwMDAhDQpbICAxOTQuMzU2MTE0XSAyZTZjNiBpcyAyOWQ5ODAw
MCENClsgIDE5NC4zNTgyOTBdIDJlNmY1IGlzIDI5ZDk3MDAwIQ0KWyAgMTk0LjM2MDQ3MV0g
MmU2YzcgaXMgMjlkOTYwMDAhDQpbICAxOTQuMzYyNjQxXSAyZTZjOCBpcyAyOWQ5NTAwMCEN
ClsgIDE5NC4zNjQ4NTFdIDJlNmY2IGlzIDI5ZDk0MDAwIQ0KWyAgMTk0LjM2NjkzNl0gMmU2
ZjcgaXMgMjlkOTMwMDAhDQpbICAxOTQuMzY5MDU5XSAyZTZmOCBpcyAyOWQ5MjAwMCENClsg
IDE5NC4zNzEyOTJdIDJlNmY5IGlzIDI5ZDkxMDAwIQ0KWyAgMTk0LjM3Mzc3MV0gMmU2ZmEg
aXMgMjlkOGYwMDAhDQpbICAxOTQuMzc1ODg0XSAyZTZmYiBpcyAyOWQ4ZTAwMCENClsgIDE5
NC4zNzgwMTJdIDJlNmZjIGlzIDI5ZDhkMDAwIQ0KWyAgMTk0LjM4MDQyMF0gMmU2ZmQgaXMg
MjlkOGIwMDAhDQpbICAxOTQuMzgyNDg2XSAyZTZmZSBpcyAyOWQ4YTAwMCENClsgIDE5NC4z
ODQ1NzNdIDJlNmZmIGlzIDI5ZDg5MDAwIQ0KWyAgMTk0LjM4NjYwNF0gMmU3MDAgaXMgMjlk
ODgwMDAhDQpbICAxOTQuMzg4Njk0XSAyZTcwMSBpcyAyOWQ4NzAwMCENClsgIDE5NC4zOTA3
NTddIDJlNzAyIGlzIDI5ZDg2MDAwIQ0KWyAgMTk0LjM5Mjc4OV0gMmU3MDMgaXMgMjlkODUw
MDAhDQpbICAxOTQuMzk0ODU0XSAyZTcwNCBpcyAyYTU4NDAwMCENClsgIDE5NC4zOTY4ODJd
IDJlNzA1IGlzIDJhNTgzMDAwIQ0KWyAgMTk0LjM5ODg4OF0gMmU3MDYgaXMgMmE1ODIwMDAh
DQpbICAxOTQuNDExNzYzXSAyZTZjOSBpcyAyYTU4MTAwMCENClsgIDE5NC40MTM4NTddIDJl
NmNhIGlzIDJhNTgwMDAwIQ0KWyAgMTk0LjQxNTkzM10gMmU2Y2IgaXMgMmE1N2YwMDAhDQpb
ICAxOTQuNDE4MDQ1XSAyZTcwNyBpcyAyYTU3ZTAwMCENClsgIDE5NC40MjAxNjNdIDJlNmNj
IGlzIDJhNTdkMDAwIQ0KWyAgMTk0LjQyMjI3MV0gMmU3MDggaXMgMmE1N2MwMDAhDQpbICAx
OTQuNDI0Mzk0XSAyZTcwOSBpcyAyYTU3YjAwMCENClsgIDE5NC40MjY1MjRdIDJlNmNkIGlz
IDJhNTdhMDAwIQ0KWyAgMTk0LjQyODY4Ml0gMmU3MGEgaXMgMmE1NzkwMDAhDQpbICAxOTQu
NDQwOTkxXSAyZTcwYiBpcyAyYTU3ODAwMCENClsgIDE5NC40NDMxMzJdIDJlNzBjIGlzIDJh
NTc3MDAwIQ0KWyAgMTk0LjQ0NTI4M10gMmU3MGQgaXMgMmE1NzYwMDAhDQpbICAxOTQuNDQ3
NDM3XSAyZTZjZSBpcyAyYTU3NTAwMCENClsgIDE5NC40NDk1NzddIDJlNmNmIGlzIDJhNTc0
MDAwIQ0KWyAgMTk0LjQ1MTczOV0gMmU3MGUgaXMgMmE1NzMwMDAhDQpbICAxOTQuNDUzODc5
XSAyZTZkMCBpcyAyYTU3MjAwMCENClsgIDE5NC40NTYwNDldIDJlNmQxIGlzIDJhNTcxMDAw
IQ0KWyAgMTk0LjQ1ODI0MV0gMmU3MGYgaXMgMmE1NzAwMDAhDQpbICAxOTQuNDYwNDA2XSAy
ZTcxMCBpcyAyYTU2ZjAwMCENClsgIDE5NC40NjI1NThdIDJlNzExIGlzIDJhNTZlMDAwIQ0K
WyAgMTk0LjQ2NTAzNF0gMmU3MTIgaXMgMmE1NmQwMDAhDQpbICAxOTQuNDY3Mjc4XSAyZTZk
MiBpcyAyYTU2YzAwMCENClsgIDE5NC40Njk0MDddIDJlNzEzIGlzIDJhNTZiMDAwIQ0KWyAg
MTk0LjQ3MTY3OF0gMmU3MTQgaXMgMmE1NmEwMDAhDQpbICAxOTQuNDczOTAxXSAyZTcxNSBp
cyAyYTU2OTAwMCENClsgIDE5NC40NzYwNTFdIDJlNzE2IGlzIDJhNTY4MDAwIQ0KWyAgMTk0
LjQ3ODMyMF0gMmU3MTcgaXMgMmE1NjcwMDAhDQpbICAxOTQuNDgwNTQ3XSAyZTcxOFsgIDE5
Ni42MDkyNzldIDJlMjM1IGlzIDJhMWU3MDAwIQ0KWyAgMTk2LjYxMTA5Ml0gMmUyMzYgaXMg
MmExZTgwMDAhDQpbICAxOTYuNjEyODY1XSAyZTIzNyBpcyAyYTFlOTAwMCENClsgIDE5Ni42
MTQ2NjBdIDJlMjM4IGlzIDJhMWVhMDAwIQ0KWyAgMTk2LjYxNjQwNF0gMmUyMzkgaXMgMmEx
ZWIwMDAhDQpbICAxOTYuNjE4MTg2XSAyZTIzYSBpcyAyYTFlYzAwMCENClsgIDE5Ni42MjAx
OTRdIDJlMjNjIGlzIDJhMWQ4MDAwIQ0KWyAgMTk2LjYyMTk0OV0gMmUyM2QgaXMgMmExZDkw
MDAhDQpbICAxOTYuNjIzNzI2XSAyZTIzZSBpcyAyYTFkYTAwMCENClsgIDE5Ni42MjU0NzFd
IDJlMjNmIGlzIDJhMWRiMDAwIQ0KWyAgMTk2LjYyNzI0OV0gMmUyNDAgaXMgMmExZGMwMDAh
DQpbICAxOTYuNjI5MDAxXSAyZTI0MSBpcyAyYTFkZDAwMCENClsgIDE5Ni42MzA3NzBdIDJl
MjQyIGlzIDJhMWRlMDAwIQ0KWyAgMTk2LjYzMjUxNV0gMmUyNDMgaXMgMmExZGYwMDAhDQpb
ICAxOTYuNjM0MjcwXSAyZTI0NCBpcyAyYTFlMDAwMCENClsgIDE5Ni42MzYwMjhdIDJlMjQ1
IGlzIDJhMWUxMDAwIQ0KWyAgMTk2LjYzNzc3Ml0gMmUyNDYgaXMgMmExZDYwMDAhDQpbICAx
OTYuNjM5NjE3XSAyZTIzYiBpcyAyYTFkNTAwMCENClsgIDE5Ni42NDE3NTddIDJlMjQ3IGlz
IDJhMWQ0MDAwIQ0KWyAgMTk2LjY1MTQwN10gMmUyNDggaXMgMmExZDAwMDAhDQpbICAxOTYu
NjUzMTM4XSAyZTI0OSBpcyAyYTFkMTAwMCENClsgIDE5Ni42NTQ4NzRdIDJlMjRhIGlzIDJh
MWQyMDAwIQ0KWyAgMTk2LjY1NjYwMF0gMmUyNGIgaXMgMmExZDMwMDAhDQpbICAxOTYuNjY5
MTE5XSAyZTFjMiBpcyAyYTFjZjAwMCENClsgIDE5Ni42NzE0NDddIDJlMWMzIGlzIDJhMWNi
MDAwIQ0KWyAgMTk2LjY3MzIwMV0gMmUyNGMgaXMgMmExY2MwMDAhDQpbICAxOTYuNjc0OTQw
XSAyZTI0ZCBpcyAyYTFjZDAwMCENClsgIDE5Ni42NzY2NTVdIDJlMjRlIGlzIDJhMWNlMDAw
IQ0KWyAgMTk2LjY3ODcyN10gMmUxYzQgaXMgMmExY2EwMDAhDQpbICAxOTYuNjkyODQxXSAy
ZTFjNSBpcyAyYTFjNjAwMCENClsgIDE5Ni42OTQ3MzhdIDJlMjRmIGlzIDJhMWM3MDAwIQ0K
WyAgMTk2LjY5NjQ2Nl0gMmUyNTAgaXMgMmExYzgwMDAhDQpbICAxOTYuNjk4MjQyXSAyZTI1
MSBpcyAyYTFjOTAwMCENClsgIDE5Ni43MDAzNDldIDJlMjUyIGlzIDJhMWM1MDAwIQ0KWyAg
MTk2LjcwMjQ4Ml0gMmUyNTMgaXMgMmExYzQwMDAhDQpbICAxOTYuNzA0NzY4XSAyZTI1NCBp
cyAyYTFjMzAwMCENClsgIDE5Ni43MDY5MTFdIDJlMjU1IGlzIDJhMWMyMDAwIQ0KWyAgMTk2
LjcwOTAxMl0gMmUyNTYgaXMgMmExYzEwMDAhDQpbICAxOTYuNzExMTU4XSAyZTFjNiBpcyAy
YTFjMDAwMCENClsgIDE5Ni43MTMyODddIDJlMjU3IGlzIDJhMWJmMDAwIQ0KWyAgMTk2Ljcx
NTYxOV0gMmUyNTggaXMgMmExYmUwMDAhDQpbICAxOTYuNzE3NzgzXSAyZTI1OSBpcyAyYTFi
ZDAwMCENClsgIDE5Ni43MzA3ODRdIDJlMjVhIGlzIDJhMWI0MDAwIQ0KWyAgMTk2LjczMjU3
OV0gMmUyNWIgaXMgMmExYjUwMDAhDQpbICAxOTYuNzM0NDg2XSAyZTI1YyBpcyAyYTFiNjAw
MCENClsgIDE5Ni43MzYyNDNdIDJlMjVkIGlzIDJhMWI3MDAwIQ0KWyAgMTk2LjczNzk5Nl0g
MmUyNWUgaXMgMmExYjgwMDAhDQpbICAxOTYuNzM5NzQ2XSAyZTI1ZiBpcyAyYTFiOTAwMCEN
ClsgIDE5Ni43NDE0ODldIDJlMjYwIGlzIDJhMWJhMDAwIQ0KWyAgMTk2Ljc0MzIzM10gMmUy
NjEgaXMgMmExYmIwMDAhDQpbICAxOTYuNzQ0OTcxXSAyZTI2MiBpcyAyYTFiYzAwMCENClsg
IDE5Ni43NDY4ODFdIDJlMjYzIGlzIDJhMWE5MDAwIQ0KWyAgMTk2Ljc0ODY0MV0gMmUyNjQg
aXMgMmExYWEwMDAhDQpbICAxOTYuNzUwMzgwXSAyZTI2NSBpcyAyYTFhYjAwMCENClsgIDE5
Ni43NTIxMjBdIDJlMjY2IGlzIDJhMWFjMDAwIQ0KWyAgMTk2Ljc1MzgyN10gMmUyNjcgaXMg
MmExYWQwMDAhDQpbICAxOTYuNzU1NTI0XSAyZTI2OCBpcyAyYTFhZTAwMCENClsgIDE5Ni43
NTcyMDJdIDJlMjY5IGlzIDJhMWFmMDAwIQ0KWyAgMTk2Ljc1ODg3MF0gMmUyNmEgaXMgMmEx
YjAwMDAhDQpbICAxOTYuNzYwNTcwXSAyZTI2YiBpcyAyYTFiMTAwMCENClsgIDE5Ni43NjIy
MjZdIDJlMjZjIGlzIDJhMWIyMDAwIQ0KWyAgMTk2Ljc2MzkwMl0gMmUyNmQgaXMgMmExYjMw
MDAhDQpbICAxOTYuNzY1NTQwXSAyZTI2ZSBpcyAyYTFhNjAwMCENClsgIDE5Ni43NjcxODld
IDJlMjZmIGlzIDJhMWE3MDAwIQ0KWyAgMTk2Ljc2ODg0NF0gMmUyNzAgaXMgMmExYTgwMDAh
DQpbICAxOTYuNzcwODMxXSAyZTI3MSBpcyAyYTFhNTAwMCENClsgIDE5Ni43NzI4NTRdIDJl
MjcyIGlzIDJhMWE0MDAwIQ0KWyAgMTk2Ljc3NDk4NV0gMmUyNzMgaXMgMmExYTMwMDAhDQpb
ICAxOTYuNzc3MDE3XSAyZTI3NCBpcyAyYTFhMjAwMCENClsgIDE5Ni43ODQ5NzFdIDJlMjc1
IGlzIDJhMTllMDAwIQ0KWyAgMTk2Ljc4NjYxOV0gMmUyNzYgaXMgMmExOWYwMDAhDQpbICAx
OTYuNzg4MjU1XSAyZTI3NyBpcyAyYTFhMDAwMCENClsgIDE5Ni43ODk4OTldIDJlMjc4IGlz
IDJhMWExMDAwIQ0KWyAgMTk2Ljc5MTg3OV0gMmUxYzcgaXMgMmExOWQwMDAhDQpbICAxOTYu
NzkzOTExXSAyZTFjOCBpcyAyYTE5YzAwMCENClsgIDE5Ni43OTU5MzRdIDJlMjc5IGlzIDJh
MTliMDAwIQ0KWyAgMTk2Ljc5ODEwN10gMmUyN2EgaXMgMmExOWEwMDAhDQpbICAxOTYuODA5
MTkyXSAyZTI3YiBpcyAyYTE5NjAwMCENClsgIDE5Ni44MTA5MzFdIDJlMjdjIGlzIDJhMTk3
MDAwIQ0KWyAgMTk2LjgxMjYwMl0gMmUyN2QgaXMgMmExOTgwMDAhDQpbICAxOTYuODE0MzAw
XSAyZTI3ZSBpcyAyYTE5OTAwMCENClsgIDE5Ni44MTYzMjBdIDJlMjdmIGlzIDJhMTk1MDAw
IQ0KWyAgMTk2LjgxODM2OF0gMmUyODAgaXMgMmExOTQwMDAhDQpbICAxOTYuODIwNDg0XSAy
ZTI4MSBpcyAyYTE5MzAwMCENClsgIDE5Ni44MjI1NTldIDJlMjgzIGlzIDJhMTkyMDAwIQ0K
WyAgMTk2LjgyOTkyMl0gMmUyODIgaXMgMmExOGUwMDAhDQpbICAxOTYuODMxNjYxXSAyZTJh
MiBpcyAyYTE4ZjAwMCENClsgIDE5Ni44MzMzMzFdIDJlMmEzIGlzIDJhMTkwMDAwIQ0KWyAg
MTk2LjgzNTA0Nl0gMmUyYTQgaXMgMmExOTEwMDAhDQpbICAxOTYuODM3MDg4XSAyZTJhNSBp
cyAyYTE4ZDAwMCENClsgIDE5Ni44NDgwODBdIDJlMmE2IGlzIDJhMThjMDAwIQ0KWyAgMTk2
Ljg1MDE4N10gMmUyYTcgaXMgMmExOGIwMDAhDQpbICAxOTYuODUyNDc5XSAyZTJhOCBpcyAy
YTE4NzAwMCENClsgIDE5Ni44NTQxNzldIDJlMmE5IGlzIDJhMTg4MDAwIQ0KWyAgMTk2Ljg1
NTg0OF0gMmUyYWEgaXMgMmExODkwMDAhDQpbICAxOTYuODU3NTIyXSAyZTJhYiBpcyAyYTE4
YTAwMCENClsgIDE5Ni44NjAxNTFdIDJlMmFjIGlzIDJhOTdjMDAwIQ0KWyAgMTk2Ljg2MTgx
OF0gMmUyYWQgaXMgMmE5N2QwMDAhDQpbICAxOTYuODYzNTIxXSAyZTJhZSBpcyAyYTk3ZTAw
MCENClsgIDE5Ni44NjUxOTFdIDJlMmFmIGlzIDJhOTdmMDAwIQ0KWyAgMTk2Ljg2Njg3MF0g
MmUyYjAgaXMgMmE5ODAwMDAhDQpbICAxOTYuODY4NjMwXSAyZTJiMSBpcyAyYTk4MTAwMCEN
ClsgIDE5Ni44NzAzMTFdIDJlMmIyIGlzIDJhOTgyMDAwIQ0KWyAgMTk2Ljg3MTk4MF0gMmUy
YjMgaXMgMmE5ODMwMDAhDQpbICAxOTYuODczNjUwXSAyZTJiNCBpcyAyYTk4NDAwMCENClsg
IDE5Ni44NzUyODhdIDJlMmI1IGlzIDJhMTg1MDAwIQ0KWyAgMTk2Ljg3Njk2M10gMmUyYjYg
aXMgMmExODYwMDAhDQpbICAxOTYuODc4NzEwXSAyZTJjNCBpcyAyYTk2ZjAwMCENClsgIDE5
Ni44ODAzOTldIDJlMmM1IGlzIDJhOTcwMDAwIQ0KWyAgMTk2Ljg4MjA2MF0gMmUyYjcgaXMg
MmE5NzEwMDAhDQpbICAxOTYuODgzNzM0XSAyZTJiOCBpcyAyYTk3MjAwMCENClsgIDE5Ni44
ODU0MTFdIDJlMmI5IGlzIDJhOTczMDAwIQ0KWyAgMTk2Ljg4NzA5MF0gMmUyYmEgaXMgMmE5
NzQwMDAhDQpbICAxOTYuODg4NzkxXSAyZTJiYiBpcyAyYTk3NTAwMCENClsgIDE5Ni44OTA0
ODJdIDJlMmJjIGlzIDJhOTc2MDAwIQ0KWyAgMTk2Ljg5MjE1N10gMmUyYmQgaXMgMmE5Nzcw
MDAhDQpbICAxOTYuODkzODY2XSAyZTJiZSBpcyAyYTk3ODAwMCENClsgIDE5Ni44OTU1MzVd
IDJlMmJmIGlzIDJhOTc5MDAwIQ0KWyAgMTk2Ljg5NzIzM10gMmUyYzAgaXMgMmE5N2EwMDAh
DQpbICAxOTYuODk4ODk3XSAyZTJjMSBpcyAyYTk3YjAwMCENClsgIDE5Ni45MDA5MzFdIDJl
MmM2IGlzIDJhOTZlMDAwIQ0KWyAgMTk2LjkwMzE4OV0gMmUyODQgaXMgMmE5NmEwMDAhDQpb
ICAxOTYuOTA0OTE0XSAyZTJjNyBpcyAyYTk2YjAwMCENClsgIDE5Ni45MDY2MjldIDJlMmM4
IGlzIDJhOTZjMDAwIQ0KWyAgMTk2LjkwODM0OF0gMmUyYzkgaXMgMmE5NmQwMDAhDQpbICAx
OTYuOTEwNDQ3XSAyZTJjYSBpcyAyYTk2OTAwMCENClsgIDE5Ni45MTI3MjVdIDJlMmNiIGlz
IDJhOTY1MDAwIQ0KWyAgMTk2LjkxNDUyNl0gMmUyY2MgaXMgMmE5NjYwMDAhDQpbICAxOTYu
OTE2MjEzXSAyZTJjZCBpcyAyYTk2NzAwMCENClsgIDE5Ni45MTc5NDBdIDJlMmNlIGlzIDJh
OTY4MDAwIQ0KWyAgMTk2LjkxOTk4MF0gMmUyY2YgaXMgMmE5NjQwMDAhDQpbICAxOTYuOTIy
MjY0XSAyZTJkMCBpcyAyYTk2MDAwMCENClsgIDE5Ni45MjQwOTZdIDJlMmQxIGlzIDJhOTYx
MDAwIQ0KWyAgMTk2LjkyNTc4NF0gMmUyZDIgaXMgMmE5NjIwMDAhDQpbICAxOTYuOTI3NTA1
XSAyZTJkMyBpcyAyYTk2MzAwMCENClsgIDE5Ni45Mjk1MjNdIDJlMmQ0IGlzIDJhOTVmMDAw
IQ0KWyAgMTk2LjkzMTc1OV0gMmUyZDUgaXMgMmE5NWIwMDAhDQpbICAxOTYuOTMzNTUyXSAy
ZTJkNiBpcyAyYTk1YzAwMCENClsgIDE5Ni45MzUyNDddIDJlMmQ3IGlzIDJhOTVkMDAwIQ0K
WyAgMTk2LjkzNjkyNl0gMmUyZDggaXMgMmE5NWUwMDAhDQpbICAxOTYuOTM4OTM2XSAyZTJk
OSBpcyAyYTk1YTAwMCENClsgIDE5Ni45NDExNDBdIDJlMmRhIGlzIDJhOTU2MDAwIQ0KWyAg
MTk2Ljk0MjgwOV0gMmUyZGIgaXMgMmE5NTcwMDAhDQpbICAxOTYuOTQ0NDYzXSAyZTJkYyBp
cyAyYTk1ODAwMCENClsgIDE5Ni45NDYxMDFdIDJlMmRkIGlzIDJhOTU5MDAwIQ0KWyAgMTk2
Ljk0ODEyOV0gMmUyZGYgaXMgMmE5NTUwMDAhDQpbICAxOTYuOTUwMzExXSAyZTJlMCBpcyAy
YTk1MTAwMCENClsgIDE5Ni45NTE5ODFdIDJlMmUxIGlzIDJhOTUyMDAwIQ0KWyAgMTk2Ljk1
MzYzNF0gMmUyZTIgaXMgMmE5NTMwMDAhDQpbICAxOTYuOTU1Mjg2XSAyZTJlMyBpcyAyYTk1
NDAwMCENClsgIDE5Ni45NTc3NTRdIDJlMmU0IGlzIDJhOTQ2MDAwIQ0KWyAgMTk2Ljk1OTQ3
OF0gMmUyZTUgaXMgMmE5NDcwMDAhDQpbICAxOTYuOTYxMTIyXSAyZTJlNiBpcyAyYTk0ODAw
MCENClsgIDE5Ni45NjI3NDhdIDJlMmU3IGlzIDJhOTQ5MDAwIQ0KWyAgMTk2Ljk2NDQwMV0g
MmUyZTggaXMgMmE5NGEwMDAhDQpbICAxOTYuOTY2MDIxXSAyZTJlOSBpcyAyYTk0YjAwMCEN
ClsgIDE5Ni45Njc2NjJdIDJlMmVhIGlzIDJhOTRjMDAwIQ0KWyAgMTk2Ljk2OTI3OF0gMmUy
ZWIgaXMgMmE5NGQwMDAhDQpbICAxOTYuOTcwOTA2XSAyZTJlYyBpcyAyYTk0ZTAwMCENClsg
IDE5Ni45NzI1NDhdIDJlMmVkIGlzIDJhOTRmMDAwIQ0KWyAgMTk2Ljk3NDE4Nl0gMmUyZWUg
aXMgMmE5NTAwMDAhDQpbICAxOTYuOTc1OTcxXSAyZTJlZiBpcyAyYTkzYjAwMCENClsgIDE5
Ni45Nzc2MzldIDJlMmYwIGlzIDJhOTNjMDAwIQ0KWyAgMTk2Ljk3OTI4M10gMmUyZjEgaXMg
MmE5M2QwMDAhDQpbICAxOTYuOTgwOTU2XSAyZTJmMiBpcyAyYTkzZTAwMCENClsgIDE5Ni45
ODI2MDZdIDJlMmYzIGlzIDJhOTNmMDAwIQ0KWyAgMTk2Ljk4NDI3Nl0gMmUyZjQgaXMgMmE5
NDAwMDAhDQpbICAxOTYuOTg1OTE5XSAyZTJmNSBpcyAyYTk0MTAwMCENClsgIDE5Ni45ODc1
NzBdIDJlMmY2IGlzIDJhOTQyMDAwIQ0KWyAgMTk2Ljk4OTIzMV0gMmUyZjcgaXMgMmE5NDMw
MDAhDQpbICAxOTYuOTkwODg3XSAyZTJmOCBpcyAyYTk0NDAwMCENClsgIDE5Ni45OTI1NTFd
IDJlMmY5IGlzIDJhOTQ1MDAwIQ0KWyAgMTk2Ljk5NDIyM10gMmUyZmEgaXMgMmE5MzkwMDAh
DQpbICAxOTYuOTk1ODg0XSAyZTJmYiBpcyAyYTkzYTAwMCENClsgIDE5Ni45OTg4OTVdIDJl
Mjk5IGlzIDJhOTE5MDAwIQ0KWyAgMTk3LjAwMDcxNl0gMmUyOWEgaXMgMmE5MWEwMDAhDQpb
ICAxOTcuMDAyNDE3XSAyZTI5YiBpcyAyYTkxYjAwMCENClsgIDE5Ny4wMDQxMTVdIDJlMjlj
IGlzIDJhOTFjMDAwIQ0KWyAgMTk3LjAwNTc5OF0gMmUyOWQgaXMgMmE5MWQwMDAhDQpbICAx
OTcuMDA3NTE4XSAyZTI5ZSBpcyAyYTkxZTAwMCENClsgIDE5Ny4wMDkyODhdIDJlMjlmIGlz
IDJhOTFmMDAwIQ0KWyAgMTk3LjAxMDk3Ml0gMmUyYTAgaXMgMmE5MjAwMDAhDQpbICAxOTcu
MDEyNjQ3XSAyZTJhMSBpcyAyYTkyMTAwMCENClsgIDE5Ny4wMTQzNjBdIDJlMzAxIGlzIDJh
OTIyMDAwIQ0KWyAgMTk3LjAxNjAzNV0gMmUzMDIgaXMgMmE5MjMwMDAhDQpbICAxOTcuMDE3
NzQxXSAyZTJmYyBpcyAyYTkyZjAwMCENClsgIDE5Ny4wMTk0MjldIDJlMjg1IGlzIDJhOTMw
MDAwIQ0KWyAgMTk3LjAyMTE1MF0gMmUyODYgaXMgMmE5MzEwMDAhDQpbICAxOTcuMDIyODc2
XSAyZTI4NyBpcyAyYTkzMjAwMCENClsgIDE5Ny4wMjQ2MDJdIDJlMjg4IGlzIDJhOTMzMDAw
IQ0KWyAgMTk3LjAyNjMyMl0gMmUyODkgaXMgMmE5MzQwMDAhDQpbICAxOTcuMDI4MDM3XSAy
ZTI4YSBpcyAyYTkzNTAwMCENClsgIDE5Ny4wMjk3MzZdIDJlMjhiIGlzIDJhOTM2MDAwIQ0K
WyAgMTk3LjAzMTQ0M10gMmUyOGMgaXMgMmE5MzcwMDAhDQpbICAxOTcuMDMzMTIxXSAyZTI4
ZCBpcyAyYTkzODAwMCENClsgIDE5Ny4wMzUxMTJdIDJlMzAzIGlzIDJhOTBlMDAwIQ0KWyAg
MTk3LjAzNjgxN10gMmUzMDQgaXMgMmE5MGYwMDAhDQpbICAxOTcuMDM4NTE1XSAyZTMwNSBp
cyAyYTkxMDAwMCENClsgIDE5Ny4wNDAyMTNdIDJlMzA2IGlzIDJhOTExMDAwIQ0KWyAgMTk3
LjA0MTg5N10gMmUzMDcgaXMgMmE5MTIwMDAhDQpbICAxOTcuMDQzNjA5XSAyZTMwOCBpcyAy
YTkxMzAwMCENClsgIDE5Ny4wNDUyOTNdIDJlMzA5IGlzIDJhOTE0MDAwIQ0KWyAgMTk3LjA0
Njk5OV0gMmUzMGEgaXMgMmE5MTUwMDAhDQpbICAxOTcuMDQ4NjcyXSAyZTMwYiBpcyAyYTkx
NjAwMCENClsgIDE5Ny4wNTAzNTFdIDJlMzBjIGlzIDJhOTE3MDAwIQ0KWyAgMTk3LjA1MjA0
MF0gMmUzMGQgaXMgMmE5MTgwMDAhDQpbICAxOTcuMDUzNzIwXSAyZTMwZSBpcyAyYTkwMzAw
MCENClsgIDE5Ny4wNTUzODZdIDJlMzBmIGlzIDJhOTA0MDAwIQ0KWyAgMTk3LjA1NzA1Ml0g
MmUzMTAgaXMgMmE5MDUwMDAhDQpbICAxOTcuMDU4NzE5XSAyZTMxMSBpcyAyYTkwNjAwMCEN
ClsgIDE5Ny4wNjA0MTVdIDJlMzEyIGlzIDJhOTA3MDAwIQ0KWyAgMTk3LjA2MjA4OF0gMmUz
MTMgaXMgMmE5MDgwMDAhDQpbICAxOTcuMDYzNzk0XSAyZTMxNCBpcyAyYTkwOTAwMCENClsg
IDE5Ny4wNjU0NTVdIDJlMzE1IGlzIDJhOTBhMDAwIQ0KWyAgMTk3LjA2NzEyN10gMmUzMTYg
aXMgMmE5MGIwMDAhDQpbICAxOTcuMDY4Nzk5XSAyZTMxNyBpcyAyYTkwYzAwMCENClsgIDE5
Ny4wNzA0NjddIDJlMzE4IGlzIDJhOTBkMDAwIQ0KWyAgMTk3LjA3MjEzM10gMmUzMTkgaXMg
MmE4ZmQwMDAhDQpbICAxOTcuMDczNzg4XSAyZTMxYSBpcyAyYThmZTAwMCENClsgIDE5Ny4w
NzU0MjVdIDJlMzFiIGlzIDJhOGZmMDAwIQ0KWyAgMTk3LjA3NzA5MV0gMmUzMWMgaXMgMmE5
MDAwMDAhDQpbICAxOTcuMDc4NzQxXSAyZTMxZCBpcyAyYTkwMTAwMCENClsgIDE5Ny4wODA0
MTldIDJlMzFlIGlzIDJhOTAyMDAwIQ0KWyAgMTk3LjA4MjA3NF0gMmUzMWYgaXMgMmE4ZmMw
MDAhDQpbICAxOTcuMDgzNzU4XSAyZTI4ZSBpcyAyYTkyNDAwMCENClsgIDE5Ny4wODU0NjRd
IDJlMjhmIGlzIDJhOTI1MDAwIQ0KWyAgMTk3LjA4NzE2NV0gMmUyOTAgaXMgMmE5MjYwMDAh
DQpbICAxOTcuMDg4ODYxXSAyZTI5MSBpcyAyYTkyNzAwMCENClsgIDE5Ny4wOTA1NTFdIDJl
MjkyIGlzIDJhOTI4MDAwIQ0KWyAgMTk3LjA5MjIyOV0gMmUyOTMgaXMgMmE5MjkwMDAhDQpb
ICAxOTcuMDkzOTgwXSAyZTI5NCBpcyAyYTkyYTAwMCENClsgIDE5Ny4wOTU2NThdIDJlMjk1
IGlzIDJhOTJiMDAwIQ0KWyAgMTk3LjA5NzM2NV0gMmUyOTYgaXMgMmE5MmMwMDAhDQpbICAx
OTcuMDk5MDQzXSAyZTI5NyBpcyAyYTkyZDAwMCENClsgIDE5Ny4xMDA3NTRdIDJlMjk4IGlz
IDJhOTJlMDAwIQ0KWyAgMTk3LjEwMjc4NV0gMmUzMjAgaXMgMmE4ZmIwMDAhDQpbICAxOTcu
MTA0ODk5XSAyZTJmZCBpcyAyYThmYTAwMCENClsgIDE5Ny4xMDY5NDhdIDJlMzIxIGlzIDJh
OGY5MDAwIQ0KWyAgMTk3LjEwOTA1OV0gMmUyZmUgaXMgMmE4ZjgwMDAhDQpbICAxOTcuMTEx
MzA4XSAyZTJmZiBpcyAyYThmNzAwMCENClsgIDE5Ny4xMTM0NTZdIDJlMzAwIGlzIDJhOGY2
MDAwIQ0KWyAgMTk3LjExNTU4OF0gMmUzM2YgaXMgMmE4ZjUwMDAhDQpbICAxOTcuMTE3Njkx
XSAyZTM0MCBpcyAyYThmNDAwMCENClsgIDE5Ny4xMTk4MDBdIDJlMzQxIGlzIDJhOGYzMDAw
IQ0KWyAgMTk3LjEyMTk1NV0gMmUzMjIgaXMgMmE4ZjIwMDAhDQpbICAxOTcuMTI0MDgyXSAy
ZTM0MiBpcyAyYThmMTAwMCENClsgIDE5Ny4xMzE2MTldIDJlMzRlIGlzIDJhOGU1MDAwIQ0K
WyAgMTk3LjEzMzQ1OF0gMmUzNDMgaXMgMmE4ZTYwMDAhDQpbICAxOTcuMTM1MjU2XSAyZTM0
NCBpcyAyYThlNzAwMCENClsgIDE5Ny4xMzcwNDNdIDJlMzQ1IGlzIDJhOGU4MDAwIQ0KWyAg
MTk3LjEzODgzMV0gMmUzNDYgaXMgMmE4ZTkwMDAhDQpbICAxOTcuMTQwNjE1XSAyZTM0NyBp
cyAyYThlYTAwMCENClsgIDE5Ny4xNDIzOTNdIDJlMzQ4IGlzIDJhOGViMDAwIQ0KWyAgMTk3
LjE0NDE3NV0gMmUzNDkgaXMgMmE4ZWMwMDAhDQpbICAxOTcuMTQ1OTM5XSAyZTM0YSBpcyAy
YThlZDAwMCENClsgIDE5Ny4xNDc3MjBdIDJlMzRiIGlzIDJhOGVlMDAwIQ0KWyAgMTk3LjE0
OTQ1MV0gMmUzNGMgaXMgMmE4ZWYwMDAhDQpbICAxOTcuMTUxMjEwXSAyZTM0ZCBpcyAyYThm
MDAwMCENClsgIDE5Ny4xNTMyOTVdIDJlMzRmIGlzIDJhOGU0MDAwIQ0KWyAgMTk3LjE1NTYw
Nl0gMmUzNTAgaXMgMmE4ZTAwMDAhDQpbICAxOTcuMTU3NDczXSAyZTM1MSBpcyAyYThlMTAw
MCENClsgIDE5Ny4xNTkyNDJdIDJlMzUyIGlzIDJhOGUyMDAwIQ0KWyAgMTk3LjE2MTAxNF0g
MmUzNTMgaXMgMmE4ZTMwMDAhDQpbICAxOTcuMTYzNDk1XSAyZTM1YyBpcyAyYThkNzAwMCEN
ClsgIDE5Ny4xNjUyNzBdIDJlMzU0IGlzIDJhOGQ4MDAwIQ0KWyAgMTk3LjE2NzA1Ml0gMmUz
NTUgaXMgMmE4ZDkwMDAhDQpbICAxOTcuMTY4ODIyXSAyZTM1NiBpcyAyYThkYTAwMCENClsg
IDE5Ny4xNzA1NjVdIDJlMzU3IGlzIDJhOGRiMDAwIQ0KWyAgMTk3LjE3MjMwNV0gMmUzNTgg
aXMgMmE4ZGMwMDAhDQpbICAxOTcuMTc0MDI0XSAyZTM1OSBpcyAyYThkZDAwMCENClsgIDE5
Ny4xNzU3MzRdIDJlMzVhIGlzIDJhOGRlMDAwIQ0KWyAgMTk3LjE3NzQyOV0gMmUzNWIgaXMg
MmE4ZGYwMDAhDQpbICAxOTcuMTg3NDI1XSAyZTM1ZCBpcyAyYThkMjAwMCENClsgIDE5Ny4x
ODkxNTNdIDJlMzVlIGlzIDJhOGQzMDAwIQ0KWyAgMTk3LjE5MDgyNV0gMmUzNWYgaXMgMmE4
ZDQwMDAhDQpbICAxOTcuMTkyNDk4XSAyZTM2MCBpcyAyYThkNTAwMCENClsgIDE5Ny4xOTQx
NjddIDJlMzYxIGlzIDJhOGQ2MDAwIQ0KWyAgMTk3LjE5NTk2MV0gMmUzNjMgaXMgMmE4Y2Qw
MDAhDQpbICAxOTcuMTk3NjQyXSAyZTM2NCBpcyAyYThjZTAwMCENClsgIDE5Ny4xOTkyODFd
IDJlMzY1IGlzIDJhOGNmMDAwIQ0KWyAgMTk3LjIwMDk1Nl0gMmUzNjYgaXMgMmE4ZDAwMDAh
DQpbICAxOTcuMjAyNjE4XSAyZTM2NyBpcyAyYThkMTAwMCENClsgIDE5Ny4yMDQzNzNdIDJl
MzYyIGlzIDJhOGNiMDAwIQ0KWyAgMTk3LjIxNjc0OF0gMmUzNjggaXMgMmE4OTYwMDAhDQpb
ICAxOTcuMjE4NDU0XSAyZTM2OSBpcyAyYTg5NTAwMCENClsgIDE5Ny4yMjAxNTJdIDJlMzZh
IGlzIDJhODk0MDAwIQ0KWyAgMTk3LjIyMTg0NV0gMmUzNmIgaXMgMmE4OTMwMDAhDQpbICAx
OTcuMjI0MjgzXSAyZTM2YyBpcyAyYTg5ZTAwMCENClsgIDE5Ny4yMjU5OTBdIDJlMzZkIGlz
IDJhODlkMDAwIQ0KWyAgMTk3LjIyNzY3N10gMmUzNmUgaXMgMmE4OWMwMDAhDQpbICAxOTcu
MjI5MzQzXSAyZTM2ZiBpcyAyYTg5YjAwMCENClsgIDE5Ny4yMzEwNDFdIDJlMzcwIGlzIDJh
ODlhMDAwIQ0KWyAgMTk3LjIzMjcwNV0gMmUzNzEgaXMgMmE4OTkwMDAhDQpbICAxOTcuMjM0
NDAyXSAyZTM3MiBpcyAyYTg5ODAwMCENClsgIDE5Ny4yWyAgMTk5LjM3Mjg1N10gMmRlZmYg
aXMgMmFkMGUwMDAhDQpbICAxOTkuMzc0NjY0XSAyZGYwMCBpcyAyYWQyZjAwMCENClsgIDE5
OS4zNzY0MjNdIDJkZjAxIGlzIDJhZDMwMDAwIQ0KWyAgMTk5LjM3ODE5Ml0gMmRmMDIgaXMg
MmFkMzEwMDAhDQpbICAxOTkuMzg1MTA1XSAyZGYwMyBpcyAyYWQwZDAwMCENClsgIDE5OS4z
ODcyODBdIDJkZjA0IGlzIDJhZDBjMDAwIQ0KWyAgMTk5LjM4OTQzOV0gMmRmMDUgaXMgMmFk
MGIwMDAhDQpbICAxOTkuMzkxNTg2XSAyZGYwNiBpcyAyYWQwYTAwMCENClsgIDE5OS40MDQx
OTFdIDJkZjEyIGlzIDJhY2ZlMDAwIQ0KWyAgMTk5LjQwNTk3OF0gMmRmMDcgaXMgMmFjZmYw
MDAhDQpbICAxOTkuNDA3NzY2XSAyZGYwOCBpcyAyYWQwMDAwMCENClsgIDE5OS40MDk1NjFd
IDJkZjA5IGlzIDJhZDAxMDAwIQ0KWyAgMTk5LjQxMTM2NF0gMmRmMGEgaXMgMmFkMDIwMDAh
DQpbICAxOTkuNDEzMTQ0XSAyZGYwYiBpcyAyYWQwMzAwMCENClsgIDE5OS40MTQ5NDZdIDJk
ZjBjIGlzIDJhZDA0MDAwIQ0KWyAgMTk5LjQxNjcyNl0gMmRmMGQgaXMgMmFkMDUwMDAhDQpb
ICAxOTkuNDE4NDkzXSAyZGYwZSBpcyAyYWQwNjAwMCENClsgIDE5OS40MjAyNTldIDJkZjBm
IGlzIDJhZDA3MDAwIQ0KWyAgMTk5LjQyMjAyNV0gMmRmMTAgaXMgMmFkMDgwMDAhDQpbICAx
OTkuNDIzODAyXSAyZGYxMSBpcyAyYWQwOTAwMCENClsgIDE5OS40MjU5MjBdIDJkZjEzIGlz
IDJhY2ZkMDAwIQ0KWyAgMTk5LjQyODExMF0gMmRmMTQgaXMgMmFjZmMwMDAhDQpbICAxOTku
NDMwMTQ2XSAyZGU5OCBpcyAyYWNmYjAwMCENClsgIDE5OS40MzI2NDBdIDJkZjE1IGlzIDJh
Y2ZhMDAwIQ0KWyAgMTk5LjQzNDgwM10gMmRmMTYgaXMgMmFjZjkwMDAhDQpbICAxOTkuNDM2
OTQ2XSAyZGYxNyBpcyAyYWNmODAwMCENClsgIDE5OS40MzkwNzRdIDJkZjE4IGlzIDJhY2Y3
MDAwIQ0KWyAgMTk5LjQ0MTIwOV0gMmRmMTkgaXMgMmFjZjYwMDAhDQpbICAxOTkuNDQzMzM5
XSAyZGYxYSBpcyAyYWNmNTAwMCENClsgIDE5OS40NDU0OTldIDJkZjFiIGlzIDJhY2Y0MDAw
IQ0KWyAgMTk5LjQ0NzYyNl0gMmRmMWMgaXMgMmFjZjMwMDAhDQpbICAxOTkuNDUzNjAyXSAy
ZGYxZCBpcyAyYWNmMjAwMCENClsgIDE5OS40NTU2OTZdIDJkZjFlIGlzIDJhY2YxMDAwIQ0K
WyAgMTk5LjQ2NjgxMV0gMmRmMWYgaXMgMmFjZWQwMDAhDQpbICAxOTkuNDY4NTI3XSAyZGYy
MCBpcyAyYWNlZTAwMCENClsgIDE5OS40NzAyNTVdIDJkZjIxIGlzIDJhY2VmMDAwIQ0KWyAg
MTk5LjQ3MTk3MF0gMmRmMjIgaXMgMmFjZjAwMDAhDQpbICAxOTkuNDc0MDU0XSAyZGU5OSBp
cyAyYWNlYzAwMCENClsgIDE5OS40NzYxODNdIDJkZTlhIGlzIDJhY2ViMDAwIQ0KWyAgMTk5
LjQ3ODMxNl0gMmRmMjMgaXMgMmFjZWEwMDAhDQpbICAxOTkuNDg2OTExXSAyZGU5YiBpcyAy
YWNlNjAwMCENClsgIDE5OS40ODg2NDZdIDJkZjI0IGlzIDJhY2U3MDAwIQ0KWyAgMTk5LjQ5
MDM2OV0gMmRmMjUgaXMgMmFjZTgwMDAhDQpbICAxOTkuNDkyMDg3XSAyZGYyNiBpcyAyYWNl
OTAwMCENClsgIDE5OS40OTQxOThdIDJkZTljIGlzIDJhY2U1MDAwIQ0KWyAgMTk5LjUwMTM2
NF0gMmRlOWQgaXMgMmFjZTQwMDAhDQpbICAxOTkuNTAzODEwXSAyZGYyNyBpcyAyYWNlMzAw
MCENClsgIDE5OS41MDU5OTNdIDJkZjI4IGlzIDJhY2UyMDAwIQ0KWyAgMTk5LjUwODE4Ml0g
MmRmMjkgaXMgMmFjZTEwMDAhDQpbICAxOTkuNTEwOTcxXSAyZGYzNSBpcyAyYWNkNTAwMCEN
ClsgIDE5OS41MTI3NjFdIDJkZjJhIGlzIDJhY2Q2MDAwIQ0KWyAgMTk5LjUxNDU3Ml0gMmRm
MmIgaXMgMmFjZDcwMDAhDQpbICAxOTkuNTE2MzM0XSAyZGYyYyBpcyAyYWNkODAwMCENClsg
IDE5OS41MTgxNDBdIDJkZjJkIGlzIDJhY2Q5MDAwIQ0KWyAgMTk5LjUxOTg5OF0gMmRmMmUg
aXMgMmFjZGEwMDAhDQpbICAxOTkuNTIxNjY3XSAyZGYyZiBpcyAyYWNkYjAwMCENClsgIDE5
OS41MjM0NjJdIDJkZjMwIGlzIDJhY2RjMDAwIQ0KWyAgMTk5LjUyNTIxOF0gMmRmMzEgaXMg
MmFjZGQwMDAhDQpbICAxOTkuNTI3MDA3XSAyZGYzMiBpcyAyYWNkZTAwMCENClsgIDE5OS41
Mjg3NjBdIDJkZjMzIGlzIDJhY2RmMDAwIQ0KWyAgMTk5LjUzMDU0OF0gMmRmMzQgaXMgMmFj
ZTAwMDAhDQpbICAxOTkuNjY1NjQyXSAyZGY1OCBpcyAyYWNkNDAwMCENClsgIDE5OS42NzI0
MjBdIDJkZjU5IGlzIDJhY2QzMDAwIQ0KWyAgMTk5LjY3NDc0Nl0gMmRmNWEgaXMgMmFjZDIw
MDAhDQpbICAxOTkuNjc3MTI5XSAyZGY1YiBpcyAyYWNjZTAwMCENClsgIDE5OS42Nzg5NDBd
IDJkZjVjIGlzIDJhY2NmMDAwIQ0KWyAgMTk5LjY4MDc2OF0gMmRmNWQgaXMgMmFjZDAwMDAh
DQpbICAxOTkuNjgyNTY2XSAyZGY1ZSBpcyAyYWNkMTAwMCENClsgIDE5OS43MDIzMTJdIDMx
YTNiIGlzIDJhY2M2MDAwIQ0KWyAgMTk5LjcwNDE0OV0gMzFhM2EgaXMgMmFjYzcwMDAhDQpb
ICAxOTkuNzA1OTY4XSAzMWEzOSBpcyAyYWNjODAwMCENClsgIDE5OS43MDc3ODBdIDMxYTM4
IGlzIDJhY2M5MDAwIQ0KWyAgMTk5LjcwOTU3N10gMzFhMzcgaXMgMmFjY2EwMDAhDQpbICAx
OTkuNzExMzYzXSAzMWEzNiBpcyAyYWNjYjAwMCENClsgIDE5OS43MTMxNDZdIDMxYTM1IGlz
IDJhY2NjMDAwIQ0KWyAgMTk5LjcxNDkzMF0gMzFhMzQgaXMgMmFjY2QwMDAhDQpbICAxOTku
NzI2NTM4XSAzMWEzMyBpcyAyYWNjNTAwMCENClsgIDE5OS43MzM0MTBdIDJkZjVmIGlzIDJh
Y2M0MDAwIQ0KWyAgMTk5LjczOTYwMl0gMmRmNzAgaXMgMmFjYzMwMDAhDQpbICAxOTkuNzQy
MDE5XSAyZGY3MSBpcyAyYWNiZjAwMCENClsgIDE5OS43NDM4ODFdIDJkZjcyIGlzIDJhY2Mw
MDAwIQ0KWyAgMTk5Ljc0NTY0OV0gMmRmNzMgaXMgMmFjYzEwMDAhDQpbICAxOTkuNzQ3NDU3
XSAyZGY3NCBpcyAyYWNjMjAwMCENClsgIDE5OS43NjMzMzZdIDJkZjc1IGlzIDJhY2JlMDAw
IQ0KWyAgMTk5Ljc2NTgwMl0gMmRmNzggaXMgMmFjYmEwMDAhDQpbICAxOTkuNzY3NjYzXSAy
ZGY3OSBpcyAyYWNiYjAwMCENClsgIDE5OS43Njk0NDVdIDJkZjdhIGlzIDJhY2JjMDAwIQ0K
WyAgMTk5Ljc3MTMyOV0gMmRmN2IgaXMgMmFjYmQwMDAhDQpbICAxOTkuODI2MTk1XSAzMWE0
OSBpcyAyYWNiMjAwMCENClsgIDE5OS44MjgxMTddIDM5M2I2IGlzIDJhY2IzMDAwIQ0KWyAg
MTk5LjgyOTk2Ml0gMzZlNDYgaXMgMmFjYjQwMDAhDQpbICAxOTkuODMxODI0XSAzN2IzZiBp
cyAyYWNiNTAwMCENClsgIDE5OS44MzM2OTVdIDM2ZDZmIGlzIDJhY2I2MDAwIQ0KWyAgMTk5
LjgzNTU1NF0gMzhjYmMgaXMgMmFjYjcwMDAhDQpbICAxOTkuODM3NDI3XSAyZGU5ZSBpcyAy
YWNiODAwMCENClsgIDE5OS44MzkzMjBdIDJkZTlmIGlzIDJhY2I5MDAwIQ0KWyAgMTk5Ljg0
MTIwNV0gMmRlYTAgaXMgMmFjYTcwMDAhDQpbICAxOTkuODQzMTQyXSAyZGVhMSBpcyAyYWNh
ODAwMCENClsgIDE5OS44NDUwOTBdIDJkZWEyIGlzIDJhY2E5MDAwIQ0KWyAgMTk5Ljg0NzAw
Ml0gMmRlYTMgaXMgMmFjYWEwMDAhDQpbICAxOTkuODQ4ODQ1XSAyZGVhNCBpcyAyYWNhYjAw
MCENClsgIDE5OS44NTA3MTBdIDJkZjhlIGlzIDJhY2FjMDAwIQ0KWyAgMTk5Ljg1MjU2Ml0g
MmRmOGYgaXMgMmFjYWQwMDAhDQpbICAxOTkuODU0NDI3XSAyZGY5MCBpcyAyYWNhZTAwMCEN
ClsgIDE5OS44NTYzMDJdIDJkZjkxIGlzIDJhY2FmMDAwIQ0KWyAgMTk5Ljg1ODE2OF0gMmRm
OTIgaXMgMmFjYjAwMDAhDQpbICAxOTkuODYwMDU2XSAyZGY5MyBpcyAyYWNiMTAwMCENClsg
IDE5OS44NjE5MThdIDJkZjk0IGlzIDJhY2EyMDAwIQ0KWyAgMTk5Ljg2MzgxOV0gMmRmOTUg
aXMgMmFjYTMwMDAhDQpbICAxOTkuODY1NjUyXSAyZGY5NiBpcyAyYWNhNDAwMCENClsgIDE5
OS44Njc1MDldIDJkZjk3IGlzIDJhY2E1MDAwIQ0KWyAgMTk5Ljg2OTMyN10gMmRmOTggaXMg
MmFjYTYwMDAhDQpbICAxOTkuODcyMTkxXSAyZTc0YyBpcyAyYWM5NzAwMCENClsgIDE5OS44
NzQwNTJdIDJkZjc2IGlzIDJhYzk4MDAwIQ0KWyAgMTk5Ljg3NTkyNl0gMmRmNzcgaXMgMmFj
OTkwMDAhDQpbICAxOTkuODc3NzkwXSAyZTdhNyBpcyAyYWM5YTAwMCENClsgIDE5OS44Nzk2
NjJdIDJkZjdjIGlzIDJhYzliMDAwIQ0KWyAgMTk5Ljg4MTU1MF0gMmRmN2QgaXMgMmFjOWMw
MDAhDQpbICAxOTkuODgzNDQ3XSAyZGY3ZSBpcyAyYWM5ZDAwMCENClsgIDE5OS44ODUzMzhd
IDJkZjdmIGlzIDJhYzllMDAwIQ0KWyAgMTk5Ljg4NzE4OV0gMmRmODAgaXMgMmFjOWYwMDAh
DQpbICAxOTkuODg5MDU0XSAyZGY4MSBpcyAyYWNhMDAwMCENClsgIDE5OS44OTA4OTZdIDJk
ZjgyIGlzIDJhY2ExMDAwIQ0KWyAgMTk5Ljg5MzIxNF0gMmRmODMgaXMgMmFjNjMwMDAhDQpb
ICAxOTkuODk1MDQzXSAyZGY4YiBpcyAyYWM4NDAwMCENClsgIDE5OS44OTY4NzFdIDJkZjhj
IGlzIDJhYzg1MDAwIQ0KWyAgMTk5Ljg5ODY0Ml0gMmRmOGQgaXMgMmFjODYwMDAhDQpbICAx
OTkuOTAwNDQ2XSAyZGZhZCBpcyAyYWM4NzAwMCENClsgIDE5OS45MDIyMTBdIDJkZmFlIGlz
IDJhYzg4MDAwIQ0KWyAgMTk5LjkwMzk5MF0gMmRmYWYgaXMgMmFjODkwMDAhDQpbICAxOTku
OTA1NzY1XSAyZGZiMCBpcyAyYWM4YTAwMCENClsgIDE5OS45MDc1NDhdIDJkZmIxIGlzIDJh
YzhiMDAwIQ0KWyAgMTk5LjkwOTMzNl0gMmRmYjIgaXMgMmFjOGMwMDAhDQpbICAxOTkuOTEx
MTAzXSAyZGZiMyBpcyAyYWM4ZDAwMCENClsgIDE5OS45MTI4NzZdIDJkZmI0IGlzIDJhYzhl
MDAwIQ0KWyAgMTk5LjkxNDY0Ml0gMmRmYjUgaXMgMmFjNzkwMDAhDQpbICAxOTkuOTE2NDAw
XSAyZGZiNiBpcyAyYWM3YTAwMCENClsgIDE5OS45MTgxODNdIDJkZmI3IGlzIDJhYzdiMDAw
IQ0KWyAgMTk5LjkxOTkzMF0gMmRmYjggaXMgMmFjN2MwMDAhDQpbICAxOTkuOTIxNzAxXSAy
ZGZiOSBpcyAyYWM3ZDAwMCENClsgIDE5OS45MjM0NjldIDJkZmJhIGlzIDJhYzdlMDAwIQ0K
WyAgMTk5LjkyNTIyNF0gMmRmYmIgaXMgMmFjN2YwMDAhDQpbICAxOTkuOTI3MDA0XSAyZGZi
YyBpcyAyYWM4MDAwMCENClsgIDE5OS45Mjg3NThdIDJkZmJkIGlzIDJhYzgxMDAwIQ0KWyAg
MTk5LjkzMDUxMV0gMmRmYmUgaXMgMmFjODIwMDAhDQpbICAxOTkuOTMyMjIzXSAyZGZiZiBp
cyAyYWM4MzAwMCENClsgIDE5OS45MzM5NjZdIDJkZmMwIGlzIDJhYzc2MDAwIQ0KWyAgMTk5
LjkzNTY3OF0gMmRmYzEgaXMgMmFjNzcwMDAhDQpbICAxOTkuOTM3MzkwXSAyZGZjMiBpcyAy
YWM3ODAwMCENClsgIDE5OS45MzkwOTddIDJkZmMzIGlzIDJhYzZiMDAwIQ0KWyAgMTk5Ljk0
MDgwMF0gMmRmYzQgaXMgMmFjNmMwMDAhDQpbICAxOTkuOTQyNTEyXSAyZGZjNSBpcyAyYWM2
ZDAwMCENClsgIDE5OS45NDQyMTVdIDJkZmM2IGlzIDJhYzZlMDAwIQ0KWyAgMTk5Ljk0NTg5
M10gMmRmYzcgaXMgMmFjNmYwMDAhDQpbICAxOTkuOTQ3NTk0XSAyZGZjOCBpcyAyYWM3MDAw
MCENClsgIDE5OS45NDkyNjFdIDJkZmM5IGlzIDJhYzcxMDAwIQ0KWyAgMTk5Ljk1MDk1Ml0g
MmRmY2EgaXMgMmFjNzIwMDAhDQpbICAxOTkuOTUyNjE4XSAyZGZjYiBpcyAyYWM3MzAwMCEN
ClsgIDE5OS45NTQzMDBdIDJkZmNlIGlzIDJhYzc0MDAwIQ0KWyAgMTk5Ljk1NTk3N10gMmRm
Y2YgaXMgMmFjNzUwMDAhDQpbICAxOTkuOTU3NjUwXSAyZGZkMCBpcyAyYWM2NDAwMCENClsg
IDE5OS45NTkzNDVdIDJkZmQxIGlzIDJhYzY1MDAwIQ0KWyAgMTk5Ljk2MTAzMF0gMmRmZDIg
aXMgMmFjNjYwMDAhDQpbICAxOTkuOTYyNzIzXSAyZGZkMyBpcyAyYWM2NzAwMCENClsgIDE5
OS45NjQ0MTVdIDJkZmQ0IGlzIDJhYzY4MDAwIQ0KWyAgMTk5Ljk2NjA4N10gMmRmZDUgaXMg
MmFjNjkwMDAhDQpbICAxOTkuOTY3Nzg4XSAyZGZkNiBpcyAyYWM2YTAwMCENClsgIDE5OS45
Njk0NDldIDJkZjg0IGlzIDJhYzkwMDAwIQ0KWyAgMTk5Ljk3MTE0OF0gMmRmODUgaXMgMmFj
OTEwMDAhDQpbICAxOTkuOTcyODIxXSAyZGY4NiBpcyAyYWM5MjAwMCENClsgIDE5OS45NzQ1
MDhdIDJkZjg3IGlzIDJhYzkzMDAwIQ0KWyAgMTk5Ljk3NjE5MV0gMmRmODggaXMgMmFjOTQw
MDAhDQpbICAxOTkuOTc3ODcxXSAyZGY4OSBpcyAyYWM5NTAwMCENClsgIDE5OS45Nzk1NDVd
IDJkZjhhIGlzIDJhYzk2MDAwIQ0KWyAgMTk5Ljk4MTU3NF0gMmRmOTkgaXMgMmFjNjIwMDAh
DQpbICAxOTkuOTgzNjM4XSAyZGY5YSBpcyAyYWM2MTAwMCENClsgIDE5OS45ODU2ODZdIDM2
ZGVkIGlzIDJhYzYwMDAwIQ0KWyAgMTk5Ljk4Nzc2Nl0gMmRmZDcgaXMgMmFjNWYwMDAhDQpb
ICAxOTkuOTg5ODUxXSAyZGZkOCBpcyAyYWM1ZTAwMCENClsgIDE5OS45OTE5MzNdIDJkZmQ5
IGlzIDJhYzVkMDAwIQ0KWyAgMTk5Ljk5NDAwNF0gMmRmZGEgaXMgMmFjNWMwMDAhDQpbICAx
OTkuOTk2MDgzXSAyZGZkYiBpcyAyYWM1YjAwMCENClsgIDIwMC4wMTM1MDldIDJkZmRjIGlz
IDJhYzUwMDAwIQ0KWyAgMjAwLjAxNTI4MV0gMmRmZGQgaXMgMmFjNTEwMDAhDQpbICAyMDAu
MDE3MDQ1XSAyZGZkZSBpcyAyYWM1MjAwMCENClsgIDIwMC4wMTg3NzJdIDJkZmRmIGlzIDJh
YzUzMDAwIQ0KWyAgMjAwLjAyMDUyM10gMmRmZTAgaXMgMmFjNTQwMDAhDQpbICAyMDAuMDIy
Mjc4XSAyZGZlMSBpcyAyYWM1NTAwMCENClsgIDIwMC4wMjQwMjhdIDJkZmUyIGlzIDJhYzU2
MDAwIQ0KWyAgMjAwLjAyNTc3M10gMmRmZTMgaXMgMmFjNTcwMDAhDQpbICAyMDAuMDI3NTE3
XSAyZGZlNCBpcyAyYWM1ODAwMCENClsgIDIwMC4wMjkyNjFdIDJkZmU1IGlzIDJhYzU5MDAw
IQ0KWyAgMjAwLjAzMDk5NV0gMmRmZTYgaXMgMmFjNWEwMDAhDQpbICAyMDAuMDMyODE4XSAy
ZGZlNyBpcyAyYWM0ZTAwMCENClsgIDIwMC4wNDI3OTVdIDJkZmU4IGlzIDJhYzRjMDAwIQ0K
WyAgMjAwLjA0NjM2OV0gMmRmOWIgaXMgMmFjNGIwMDAhDQpbICAyMDAuMDQ4NTUwXSAyZGZl
OSBpcyAyYWM0YTAwMCENClsgIDIwMC4wNTU5NTFdIDJkZmVhIGlzIDJhYzQ5MDAwIQ0KWyAg
MjAwLjA1ODEzOF0gMmRmZWIgaXMgMmFjNDgwMDAhDQpbICAyMDAuMDYwMzM1XSAyZGZlYyBp
cyAyYWM0NzAwMCENClsgIDIwMC4wNjI1NDJdIDJkZmVkIGlzIDJhYzQ2MDAwIQ0KWyAgMjAw
LjA2NDY3NV0gMmRmOWMgaXMgMmFjNDUwMDAhDQpbICAyMDAuMTA1NzYyXSAyZGY5ZCBpcyAy
YWM0NDAwMCENClsgIDIwMC4xMTU0MzVdIDJkZmVlIGlzIDJhYzQzMDAwIQ0KWyAgMjAwLjEx
ODc0Ml0gMmRmZWYgaXMgMmFjNDIwMDAhDQpbICAyMDAuMTI4MDI5XSAyZGZmMCBpcyAyYWM0
MTAwMCENClsgIDIwMC4xNDI3ODZdIDJkZmYxIGlzIDJhYzNmMDAwIQ0KWyAgMjAwLjE0NDU3
NF0gMmRmZjIgaXMgMmFjNDAwMDAhDQpbICAyMDAuMTU0NjI3XSAyZGZmNCBpcyAyYWMzNjAw
MCENClsgIDIwMC4xNTYzNjRdIDJkZjllIGlzIDJhYzM3MDAwIQ0KWyAgMjAwLjE1ODEyNV0g
MmRmOWYgaXMgMmFjMzgwMDAhDQpbICAyMDAuMTU5ODg2XSAyZGZhMCBpcyAyYWMzOTAwMCEN
ClsgIDIwMC4xNjE2NDVdIDJkZmExIGlzIDJhYzNhMDAwIQ0KWyAgMjAwLjE2MzQ0MV0gMmRm
YTIgaXMgMmFjM2IwMDAhDQpbICAyMDAuMTY1MTU3XSAyZGZhMyBpcyAyYWMzYzAwMCENClsg
IDIwMC4xNjcwMjldIDJkZmYzIGlzIDJhYzNkMDAwIQ0KWyAgMjAwLjE2ODg2OV0gMmRmYTQg
aXMgMmFjMzUwMDAhDQpbICAyMDAuMTcxMDA2XSAyZGZmNSBpcyAyYWMzNDAwMCENClsgIDIw
MC4xNzMxNjRdIDJkZmE1IGlzIDJhYzMzMDAwIQ0KWyAgMjAwLjE3NTM0Nl0gMmRmZjYgaXMg
MmFjMzIwMDAhDQpbICAyMDAuMTc3NTA5XSAyZGZmNyBpcyAyYWMzMTAwMCENClsgIDIwMC4x
Nzk3MDJdIDJkZmY4IGlzIDJhYzMwMDAwIQ0KWyAgMjAwLjE4MTk0M10gMmRmZmEgaXMgMmFj
MmYwMDAhDQpbICAyMDAuMTg0MTI1XSAyZGZmYiBpcyAyYWMyZTAwMCENClsgIDIwMC4xODYy
ODhdIDJkZmZjIGlzIDJhYzJkMDAwIQ0KWyAgMjAwLjE4ODQ3M10gMmRmZmQgaXMgMmFjMmMw
MDAhDQpbICAyMDAuMTkwNjM5XSAyZGZmZSBpcyAyYWMyYjAwMCENClsgIDIwMC4xOTI3OTNd
IDJkZmZmIGlzIDJhYzJhMDAwIQ0KWyAgMjAwLjE5OTU5NF0gMmQ4MDAgaXMgMmFjMjkwMDAh
DQpbICAyMDAuMjAxNzgzXSAyZDgwMSBpcyAyYWMyODAwMCENClsgIDIwMC4yMDQyOThdIDJk
ODAyIGlzIDJhYzI2MDAwIQ0KWyAgMjAwLjIxNzU4M10gMmQ4MDMgaXMgMmFjMjUwMDAhDQpb
ICAyMDAuMjE5NzU3XSAyZDgwNCBpcyAyYWMyNDAwMCENClsgIDIwMC4yMjE5ODBdIDJkODA1
IGlzIDJhYzIzMDAwIQ0KWyAgMjAwLjIyNTE1Ml0gMmQ4MDYgaXMgMmFiZjkwMDAhDQpbICAy
MDAuMjI3MzE1XSAyZGZmOSBpcyAyYWJmYTAwMCENClsgIDIwMC4yMjk2MTldIDJkZmE2IGlz
IDJhYmZiMDAwIQ0KWyAgMjAwLjIzMTkzN10gMmQ4MDcgaXMgMmFiZmYwMDAhDQpbICAyMDAu
MjMzNzQyXSAyZGZhNyBpcyAyYWJmZTAwMCENClsgIDIwMC4yMzU0ODhdIDJkZmE4IGlzIDJh
YmZkMDAwIQ0KWyAgMjAwLjIzNzI3OF0gMmRmYTkgaXMgMmFiZmMwMDAhDQpbICAyMDAuMjM5
NDE0XSAyZGZhYSBpcyAyYWMwMDAwMCENClsgIDIwMC4yNDE3MzJdIDJkODA4IGlzIDJhYzIy
MDAwIQ0KWyAgMjAwLjI0MzUyM10gMmRmYWIgaXMgMmFjMDkwMDAhDQpbICAyMDAuMjQ1Mjky
XSAyZGZhYyBpcyAyYWMwMjAwMCENClsgIDIwMC4yNDcxMThdIDJkODBjIGlzIDJhYzAxMDAw
IQ0KWyAgMjAwLjI3MzY2MF0gMmQ4MGQgaXMgMmFjMWIwMDAhDQpbICAyMDAuMjc2MDc5XSAy
ZDgwOSBpcyAyYWMxMzAwMCENClsgIDIwMC4yNzc5NTZdIDJkODBhIGlzIDJhYzE0MDAwIQ0K
WyAgMjAwLjI3OTc2NV0gMmQ4MGIgaXMgMmFjMjAwMDAhDQpbICAyMDAuMjgxNTc4XSAyZDgy
YiBpcyAyYWMyMTAwMCENClsgIDIwMC4yODM3OThdIDJkODJjIGlzIDJhYzEyMDAwIQ0KWyAg
MjAwLjI4OTcxNV0gMmQ4MmQgaXMgMmFjMTEwMDAhDQpbICAyMDAuMzAwMjE5XSAyZDgyZSBp
cyAyYWMxMDAwMCENClsgIDIwMC4zMDI0NDJdIDJkODJmIGlzIDJhYzBlMDAwIQ0KWyAgMjAw
LjMwNTU3N10gMmQ4MzAgaXMgMmFjMTUwMDAhDQpbICAyMDAuMzA3OTU3XSAyZDgzMSBpcyAy
YWMwNDAwMCENClsgIDIwMC4zMDk3OTldIDJkODMyIGlzIDJhYzAzMDAwIQ0KWyAgMjAwLjMx
MTYxNF0gMmQ4MzMgaXMgMmFjMDgwMDAhDQpbICAyMDAuMzEzNDYyXSAyZDgzNCBpcyAyYWMw
YzAwMCENClsgIDIwMC4zMTU2NDFdIDJkODM1IGlzIDJhYzBkMDAwIQ0KWyAgMjAwLjMxNzg3
MV0gMmQ4MzYgaXMgMmFjMTYwMDAhDQpbICAyMDAuMzIwMjU3XSAyZDgwZSBpcyAyYThhYzAw
MCENClsgIDIwMC4zMjIwODRdIDJkODM3IGlzIDJhZDQ0MDAwIQ0KWyAgMjAwLjMyMzkzMF0g
MmQ4MzggaXMgMmFjMGIwMDAhDQpbICAyMDAuMzI1NzY2XSAyZDgzOSBpcyAyYWMwYTAwMCEN
ClsgIDIwMC4zMjgwMDVdIDJkODNiIGlzIDJhYzFjMDAwIQ0KWyAgMjAwLjMzODgxMl0gMmQ4
M2MgaXMgMmFjMDcwMDAhDQpbICAyMDAuMzQwNjkzXSAyZDgzZCBpcyAyOWRiMjAwMCENClsg
IDIwMC4zNDI1MjRdIDJkODNlIGlzIDJhZDM2MDAwIQ0KWyAgMjAwLjM0NDQyNV0gMmQ4M2Yg
aXMgMmEyNTQwMDAhDQpbICAyMDAuMzQ5ODgyXSAyZDg0MCBpcyAyYWQzODAwMCENClsgIDIw
MC4zNTIxNzRdIDJkODQxIGlzIDJhZDM3MDAwIQ0KWyAgMjAwLjM1NDYxMl0gMmQ4NDIgaXMg
MmFjMTcwMDAhDQpbICAyMDAuMzU2NDUyXSAyZDg0MyBpcyAyYWMxODAwMCENClsgIDIwMC4z
NTgyOTNdIDJkODQ0IGlzIDJhYzE5MDAwIQ0KWyAgMjAwLjM2MDEyMl0gMmQ4NDUgaXMgMmFj
MWEwMDAhDQpbICAyMDAuMzYyMzEyXSAyZDg0NiBpcyAyYWJmODAwMCENClsgIDIwMC4zNjQ1
NDVdIDJkODNhIGlzIDJhYmY3MDAwIQ0KWyAgMjAwLjM2Njk0NF0gMmQ4MGYgaXMgMmFiZjMw
MDAhDQpbICAyMDAuMzY4NzU2XSAyZDg0OCBpcyAyYWJmNDAwMCENClsgIDIwMC4zNzA2MDFd
IDJkODQ5IGlzIDJhYmY1MDAwIQ0KWyAgMjAwLjM3MjQwNF0gMmQ4NGEgaXMgMmFiZjYwMDAh
DQpbICAyMDAuMzgyOTA1XSAyZDg0YyBpcyAyYWJmMjAwMCENClsgIDIwMC4zODUxNTFdIDJk
ODRkIGlzIDJhYmYxMDAwIQ0KWyAgMjAwLjM4NzM3OV0gMmQ4NGUgaXMgMmFiZjAwMDAhDQpb
ICAyMDAuMzg5NTkzXSAyZDg0ZiBpcyAyYWJlZjAwMCENClsgIDIwMC4zOTE5NjZdIDJkODRi
IGlzIDJhYmViMDAwIQ0KWyAgMjAwLjM5MzgyMV0gMmQ4NTAgaXMgMmFiZWMwMDAhDQpbICAy
MDAuMzk1NjI3XSAyZDg1MSBpcyAyYWJlZDAwMCENClsgIDIwMC4zOTc0MzNdIDJkODUyIGlz
IDJhYmVlMDAwIQ0KWyAgMjAwLjQwMzk2NF0gMmQ4NTMgaXMgMmFiZWEwMDAhDQpbICAyMDAu
NDA2MjE1XSAyZDg1NCBpcyAyYWJlOTAwMCENClsgIDIwMC40MDg2MTldIDJkODU1IGlzIDJh
YmU1MDAwIQ0KWyAgMjAwLjQxMDQ1Nl0gMmQ4NTYgaXMgMmFiZTYwMDAhDQpbICAyMDAuNDEy
MjIyXSAyZDg1NyBpcyAyYWJlNzAwMCENClsgIDIwMC40MTM5ODhdIDJkODU4IGlzIDJhYmU4
MDAwIQ0KWyAgMjAwLjQxNjU0Ml0gMmQ4NjEgaXMgMmFiZGMwMDAhDQpbICAyMDAuNDE4MzE5
XSAyZDg1OSBpcyAyYWJkZDAwMCENClsgIDIwMC40MjAwOTBdIDJkODVhIGlzIDJhYmRlMDAw
IQ0KWyAgMjAwLjQyMTgzNl0gMmQ4NWIgaXMgMmFiZGYwMDAhDQpbICAyMDAuNDIzNTcyXSAy
ZDg1YyBpcyAyYWJlMDAwMCENClsgIDIwMC40MjUzMDVdIDJkODVkIGlzIDJhYmUxMDAwIQ0K
WyAgMjAwLjQyNzAyMl0gMmQ4NWUgaXMgMmFiZTIwMDAhDQpbICAyMDAuNDI4NzMyXSAyZDg1
ZiBpcyAyYWJlMzAwMCENClsgIDIwMC40MzA0MzFdIDJkODYwIGlzIDJhYmU0MDAwIQ0KWyAg
MjAwLjQzMjY0MF0gMmQ4NjIgaXMgMmFiZDgwMDAhDQpbICAyMDAuNDM0Mzc2XSAyZDg2MyBp
cyAyYWJkOTAwMCENClsgIDIwMC40MzYwNjZdIDJkODY0IGlzIDJhYmRhMDAwIQ0KWyAgMjAw
LjQzNzc4MV0gMmQ4NjUgaXMgMmFiZGIwMDAhDQpbICAyMDAuNDM5ODM1XSAyZDg2NiBpcyAy
YWJkNzAwMCENClsgIDIwMC40NDIwNTVdIDJkODY3IGlzIDJhYmQzMDAwIQ0KWyAgMjAwLjQ0
Mzc4NF0gMmQ4MTAgaXMgMmFiZDQwMDAhDQpbICAyMDAuNDQ1NDY2XSAyZDgxMSBpcyAyYWJk
NTAwMCENClsgIDIwMC40NDcxNTddIDJkODEyIGlzIDJhYmQ2MDAwIQ0KWyAgMjAwLjQ0OTIy
Ml0gMmQ4NjggaXMgMmFiZDIwMDAhDQpbICAyMDAuNDY4NDM5XSAyZDg2OSBpcyAyYWJkMTAw
MCENClsgIDIwMC40NzA1NjNdIDJkODE0IGlzIDJhYmQwMDAwIQ0KWyAgMjAwLjQ3MjcwOF0g
MmQ4MTUgaXMgMmFiY2YwMDAhDQpbICAyMDAuNDc0ODQwXSAyZDg2YSBpcyAyYWJjZTAwMCEN
ClsgIDIwMC40NzY5ODNdIDJkODE2IGlzIDJhYmNkMDAwIQ0KWyAgMjAwLjQ4MTQ3N10gMmQ4
NmIgaXMgMmFiY2MwMDAhDQpbICAyMDAuNDgzNjQwXSAyZDg2YyBpcyAyYWJjYjAwMCENClsg
IDIwMC40ODU3NzJdIDJkODZkIGlzIDJhYmNhMDAwIQ0KWyAgMjAwLjQ4Nzk0OV0gMmQ4NmUg
aXMgMmFiYzkwMDAhDQpbICAyMDAuNDkwMjU1XSAyZDg2ZiBpcyAyYWJjNTAwMCENClsgIDIw
MC40OTIwMjJdIDJkODcwIGlzIDJhYmM2MDAwIQ0KWyAgMjAwLjQ5Mzc3NF0gMmQ4NzEgaXMg
MmFiYzcwMDAhDQpbICAyMDAuNDk1NTMwXSAyZDg3MiBpcyAyYWJjODAwMCENClsgIDIwMC40
OTc2NDldIDJkODc0IGlzIDJhYmM0MDAwIQ0KWyAgMjAwLjUwMzgyNF0gMmQ4NzUgaXMgMmFi
YzMwMDAhDQpbICAyMDAuNTA4NDI5XSAyZDg3NiBpcyAyYWJjMjAwMCENClsgIDIwMC41MTA3
MzRdIDJkODc3IGlzIDJhYmJlMDAwIQ0KWyAgMjAwLjUxMjQ3OF0gMmQ4NzggaXMgMmFiYmYw
MDAhDQpbICAyMDAuNTE0MjExXSAyZDg3OSBpcyAyYWJjMDAwMCENClsgIDIwMC41MTU5Mjdd
IDJkODdhIGlzIDJhYmMxMDAwIQ0KWyAgMjAwLjUxODA2MV0gMmQ4NzMgaXMgMmFiYmQwMDAh
DQpbICAyMDAuNTI1MDc5XSAyZDgxNyBpcyAyYWJiYzAwMCENClsgIDIwMC41MzIwNzBdIDJk
ODdiIGlzIDJhYmJiMDAwIQ0KWyAgMjAwLjUzNTE0M10gMmQ4N2MgaXMgMmFiYmEwMDAhDQpb
ICAyMDAuNTM3MzE4XSAyZDg3ZCBpcyAyYWJiOTAwMCENClsgIDIwMC41Mzk1NDRdIDJkODdl
IGlzIDJhYmI4MDAwIQ0KWyAgMjAwLjU0MTg5Nl0gMmQ4N2YgaXMgMmFiYjQwMDAhDQpbICAy
MDAuNTQzNzAxXSAyZDg4MCBpcyAyYWJiNTAwMCENClsgIDIwMC41NDU0NTFdIDJkODgxIGlz
IDJhYmI2MDAwIQ0KWyAgMjAwLjU0NzIwNV0gMmQ4ODIgaXMgMmFiYjcwMDAhDQpbICAyMDAu
NTQ5NzgzXSAyZDg4MyBpcyAyYWJhOTAwMCENClsgIDIwMC41NTE2MTNdIDJkODg0IGlzIDJh
YmFhMDAwIQ0KWyAgMjAwLjU1MzMzN10gMmQ4ODUgaXMgMmFiYWIwMDAhDQpbICAyMDAuNTU1
MDg4XSAyZDg4NiBpcyAyYWJhYzAwMCENClsgIDIwMC41NTY4MTddIDJkODg3IGlzIDJhYmFk
MDAwIQ0KWyAgMjAwLjU1ODUzMl0gMmQ4ODggaXMgMmFiYWUwMDAhDQpbICAyMDAuNTYwMjQ0
XSAyZDg4OSBpcyAyYWJhZjAwMCENClsgIDIwMC41NjE5NDldIDJkODhhIGlzIDJhYmIwMDAw
IQ0KWyAgMjAwLjU2MzY1NV0gMmQ4OGIgaXMgMmFiYjEwMDAhDQpbICAyMDAuNTY1MzQyXSAy
ZDg4YyBpcyAyYWJiMjAwMCENClsgIDIwMi42OTU0ODFdIDJkYjhkIGlzIDJiMDg3MDAwIQ0K
WyAgMjAyLjY5NzE4OF0gMmRiOGUgaXMgMmIwODgwMDAhDQpbICAyMDIuNzA4OTEyXSAyZGJh
ZSBpcyAyYjA4NDAwMCENClsgIDIwMi43MTY3ODFdIDJkYmFmIGlzIDJiMDgwMDAwIQ0KWyAg
MjAyLjcxODQ3Ml0gMmRiYjAgaXMgMmIwODEwMDAhDQpbICAyMDIuNzIwMTczXSAyZGJiMSBp
cyAyYjA4MjAwMCENClsgIDIwMi43MjE4NjZdIDJkYmIyIGlzIDJiMDgzMDAwIQ0KWyAgMjAy
LjczMjA0Ml0gMmRiOWIgaXMgMmIwNzgwMDAhDQpbICAyMDIuNzMzNzc1XSAyZGI5YyBpcyAy
YjA3OTAwMCENClsgIDIwMi43MzU1MTldIDJkYjlkIGlzIDJiMDdhMDAwIQ0KWyAgMjAyLjcz
NzIzOF0gMmRiOWUgaXMgMmIwN2IwMDAhDQpbICAyMDIuNzM4OTU0XSAyZGI5ZiBpcyAyYjA3
YzAwMCENClsgIDIwMi43NDA2NjZdIDJkYmEwIGlzIDJiMDdkMDAwIQ0KWyAgMjAyLjc0MjM4
OF0gMmRiYTEgaXMgMmIwN2UwMDAhDQpbICAyMDIuNzQ0MTY1XSAyZGJhMiBpcyAyYjA3ZjAw
MCENClsgIDIwMi43NDYxNjZdIDJkYmNlIGlzIDJiMDY5MDAwIQ0KWyAgMjAyLjc0NzkxM10g
MmRiY2YgaXMgMmIwNmEwMDAhDQpbICAyMDIuNzQ5NjE0XSAyZGJkMCBpcyAyYjA2YjAwMCEN
ClsgIDIwMi43NTEzNDFdIDJkYmQxIGlzIDJiMDZjMDAwIQ0KWyAgMjAyLjc1MzA0MV0gMmRi
YTMgaXMgMmIwNmQwMDAhDQpbICAyMDIuNzU0NzcwXSAyZGJhNCBpcyAyYjA2ZTAwMCENClsg
IDIwMi43NTY0NThdIDJkYmE1IGlzIDJiMDZmMDAwIQ0KWyAgMjAyLjc1ODE2NV0gMmRiYTYg
aXMgMmIwNzAwMDAhDQpbICAyMDIuNzU5ODc0XSAyZGJhNyBpcyAyYjA3MTAwMCENClsgIDIw
Mi43NjE1ODZdIDJkYmE4IGlzIDJiMDcyMDAwIQ0KWyAgMjAyLjc2MzI5OF0gMmRiYTkgaXMg
MmIwNzMwMDAhDQpbICAyMDIuNzY1MDE2XSAyZGJhYSBpcyAyYjA3NDAwMCENClsgIDIwMi43
NjY3MzhdIDJkYmFiIGlzIDJiMDc1MDAwIQ0KWyAgMjAyLjc2ODQxOV0gMmRiYWMgaXMgMmIw
NzYwMDAhDQpbICAyMDIuNzcwMTIwXSAyZGJhZCBpcyAyYjA3NzAwMCENClsgIDIwMi43NzE5
MzNdIDJkYmNkIGlzIDJiMDY3MDAwIQ0KWyAgMjAyLjc3NDA5OF0gMmRiZDIgaXMgMmIwNjYw
MDAhDQpbICAyMDIuNzc2MjY4XSAyZGJiMyBpcyAyYjA2NTAwMCENClsgIDIwMi43ODM1MTRd
IDJkYmI0IGlzIDJiMDY0MDAwIQ0KWyAgMjAyLjc4NTY2Ml0gMmRiZDMgaXMgMmIwNjMwMDAh
DQpbICAyMDIuNzkzNzcyXSAyZGJiNSBpcyAyYjA2MjAwMCENClsgIDIwMi44MDEzODRdIDJk
YmQ0IGlzIDJiMDVlMDAwIQ0KWyAgMjAyLjgwMzExN10gMmRiYjYgaXMgMmIwNWYwMDAhDQpb
ICAyMDIuODA0ODc4XSAyZGJiNyBpcyAyYjA2MDAwMCENClsgIDIwMi44MDY1ODldIDJkYmI4
IGlzIDJiMDYxMDAwIQ0KWyAgMjAyLjgwOTA2M10gMmRiZDUgaXMgMmIwNTYwMDAhDQpbICAy
MDIuODEwODIxXSAyZGJkNiBpcyAyYjA1NzAwMCENClsgIDIwMi44MTI1NjRdIDJkYmQ3IGlz
IDJiMDU4MDAwIQ0KWyAgMjAyLjgxNDMxNl0gMmRiZDggaXMgMmIwNTkwMDAhDQpbICAyMDIu
ODE2MDMyXSAyZGJkOSBpcyAyYjA1YTAwMCENClsgIDIwMi44MTc3ODVdIDJkYmRhIGlzIDJi
MDViMDAwIQ0KWyAgMjAyLjgxOTUwMl0gMmRiZGIgaXMgMmIwNWMwMDAhDQpbICAyMDIuODIx
MjUzXSAyZGJkYyBpcyAyYjA1ZDAwMCENClsgIDIwMi44MjMzNThdIDJkYmRkIGlzIDJiMDU1
MDAwIQ0KWyAgMjAyLjgzMjQxNF0gMmRiYjkgaXMgMmIwNTQwMDAhDQpbICAyMDIuODM0NTk2
XSAyZGJiYSBpcyAyYjA1MzAwMCENClsgIDIwMi44MzY5MjZdIDJkYmJiIGlzIDJiMDRmMDAw
IQ0KWyAgMjAyLjgzODY3OF0gMmRiYmMgaXMgMmIwNTAwMDAhDQpbICAyMDIuODQwNDI1XSAy
ZGJiZCBpcyAyYjA1MTAwMCENClsgIDIwMi44NDIxNzFdIDJkYmJlIGlzIDJiMDUyMDAwIQ0K
WyAgMjAyLjg0NDM1Nl0gMmRiYmYgaXMgMmIwNGUwMDAhDQpbICAyMDIuODU0NDMwXSAyZGJj
YiBpcyAyYjA0MjAwMCENClsgIDIwMi44NTYxNzddIDJkYmMwIGlzIDJiMDQzMDAwIQ0KWyAg
MjAyLjg1NzkzM10gMmRiYzEgaXMgMmIwNDQwMDAhDQpbICAyMDIuODU5Njg1XSAyZGJjMiBp
cyAyYjA0NTAwMCENClsgIDIwMi44NjE0MzhdIDJkYmMzIGlzIDJiMDQ2MDAwIQ0KWyAgMjAy
Ljg2MzE5MV0gMmRiYzQgaXMgMmIwNDcwMDAhDQpbICAyMDIuODY0OTQwXSAyZGJjNSBpcyAy
YjA0ODAwMCENClsgIDIwMi44NjY2ODVdIDJkYmM2IGlzIDJiMDQ5MDAwIQ0KWyAgMjAyLjg2
ODQyN10gMmRiYzcgaXMgMmIwNGEwMDAhDQpbICAyMDIuODcwMTY4XSAyZGJjOCBpcyAyYjA0
YjAwMCENClsgIDIwMi44NzE5MDhdIDJkYmM5IGlzIDJiMDRjMDAwIQ0KWyAgMjAyLjg3MzYz
NV0gMmRiY2EgaXMgMmIwNGQwMDAhDQpbICAyMDIuODc1NzI5XSAyZGJjYyBpcyAyYjA0MTAw
MCENClsgIDIwMi44Nzc4NDJdIDJkYmVjIGlzIDJiMDQwMDAwIQ0KWyAgMjAyLjg3OTk2Ml0g
MmRiZWQgaXMgMmIwM2YwMDAhDQpbICAyMDIuODgyMDU3XSAyZGJlZSBpcyAyYjAzZTAwMCEN
ClsgIDIwMi44OTAxNThdIDJkYmVmIGlzIDJiMDNkMDAwIQ0KWyAgMjAyLjg5MjI3NV0gMmRi
ZjAgaXMgMmIwM2MwMDAhDQpbICAyMDIuODk0Mzc5XSAyZGJmMSBpcyAyYjAzYjAwMCENClsg
IDIwMi45MDM2ODBdIDJkYmZkIGlzIDJiMDJmMDAwIQ0KWyAgMjAyLjkwNTM5Ml0gMmRiZjIg
aXMgMmIwMzAwMDAhDQpbICAyMDIuOTA3MTAxXSAyZGJmMyBpcyAyYjAzMTAwMCENClsgIDIw
Mi45MDg4MTZdIDJkYmY0IGlzIDJiMDMyMDAwIQ0KWyAgMjAyLjkxMDUyMV0gMmRiZjUgaXMg
MmIwMzMwMDAhDQpbICAyMDIuOTEyMjMzXSAyZGJmNiBpcyAyYjAzNDAwMCENClsgIDIwMi45
MTM5MzNdIDJkYmY3IGlzIDJiMDM1MDAwIQ0KWyAgMjAyLjkxNTYwNl0gMmRiZjggaXMgMmIw
MzYwMDAhDQpbICAyMDIuOTE3MzEzXSAyZGJmOSBpcyAyYjAzNzAwMCENClsgIDIwMi45MTg5
ODFdIDJkYmZhIGlzIDJiMDM4MDAwIQ0KWyAgMjAyLjkyMDY3M10gMmRiZmIgaXMgMmIwMzkw
MDAhDQpbICAyMDIuOTIyMzQxXSAyZGJmYyBpcyAyYjAzYTAwMCENClsgIDIwMi45MjQzNzld
IDJkYmRlIGlzIDJiMDJlMDAwIQ0KWyAgMjAyLjkyNjQ5MV0gMmRiZGYgaXMgMmIwMmQwMDAh
DQpbICAyMDIuOTI4NzU1XSAyZGJmZSBpcyAyYjAyOTAwMCENClsgIDIwMi45MzA0NjFdIDJk
YmUwIGlzIDJiMDJhMDAwIQ0KWyAgMjAyLjkzMjE0MF0gMmRiZTEgaXMgMmIwMmIwMDAhDQpb
ICAyMDIuOTMzODQ3XSAyZGJlMiBpcyAyYjAyYzAwMCENClsgIDIwMi45MzU5MDFdIDJkYmUz
IGlzIDJiMDI4MDAwIQ0KWyAgMjAyLjkzNzk3Ml0gMmRiZmYgaXMgMmIwMjcwMDAhDQpbICAy
MDIuOTQwMTAyXSAyZGJlNCBpcyAyYjAyNjAwMCENClsgIDIwMi45NDIyMTRdIDJkNDAwIGlz
IDJiMDI1MDAwIQ0KWyAgMjAyLjk0NDI3OV0gMmQ0MDEgaXMgMmIwMjQwMDAhDQpbICAyMDIu
OTQ2NDEwXSAyZGJlNSBpcyAyYjAyMzAwMCENClsgIDIwMi45NDg1MzhdIDJkNDAyIGlzIDJi
MDIyMDAwIQ0KWyAgMjAyLjk1ODcxMl0gMmQ0MDMgaXMgMmIwMWUwMDAhDQpbICAyMDIuOTYw
NDQ3XSAyZDQwNCBpcyAyYjAxZjAwMCENClsgIDIwMi45NjIxNzRdIDJkNDA1IGlzIDJiMDIw
MDAwIQ0KWyAgMjAyLjk2MzkwNl0gMmQ0MDYgaXMgMmIwMjEwMDAhDQpbICAyMDIuOTY2NTMw
XSAyZDQwNyBpcyAyYjAxMzAwMCENClsgIDIwMi45NjgyNjNdIDJkNDA4IGlzIDJiMDE0MDAw
IQ0KWyAgMjAyLjk2OTk5MF0gMmQ0MDkgaXMgMmIwMTUwMDAhDQpbICAyMDIuOTcxODExXSAy
ZDQwYSBpcyAyYjAxNjAwMCENClsgIDIwMi45NzM1MzZdIDJkNDBiIGlzIDJiMDE3MDAwIQ0K
WyAgMjAyLjk3NTI1NV0gMmQ0MGMgaXMgMmIwMTgwMDAhDQpbICAyMDIuOTc2OTc5XSAyZDQw
ZCBpcyAyYjAxOTAwMCENClsgIDIwMi45Nzg2OTNdIDJkNDBlIGlzIDJiMDFhMDAwIQ0KWyAg
MjAyLjk4MDQwNV0gMmQ0MGYgaXMgMmIwMWIwMDAhDQpbICAyMDIuOTgyMTE5XSAyZDQxMCBp
cyAyYjAxYzAwMCENClsgIDIwMi45ODM4NzFdIDJkNDExIGlzIDJiMDFkMDAwIQ0KWyAgMjAy
Ljk4NzMzOV0gMmQ0MjggaXMgMmFmZTcwMDAhDQpbICAyMDIuOTg5MTIwXSAyZDQyOSBpcyAy
YWZlODAwMCENClsgIDIwMi45OTA4ODZdIDJkNDJjIGlzIDJhZmU5MDAwIQ0KWyAgMjAyLjk5
MjY1Nl0gMmQ0MmQgaXMgMmFmZWEwMDAhDQpbICAyMDIuOTk0NDExXSAyZDQyZSBpcyAyYWZl
YjAwMCENClsgIDIwMi45OTYxNzBdIDJkNDJmIGlzIDJhZmVjMDAwIQ0KWyAgMjAyLjk5Nzk0
NV0gMmQ0MzAgaXMgMmFmZWQwMDAhDQpbICAyMDIuOTk5Njk5XSAyZDQzMSBpcyAyYWZlZTAw
MCENClsgIDIwMy4wMDE0MzldIDJkNDMyIGlzIDJhZmVmMDAwIQ0KWyAgMjAzLjAwMzE4N10g
MmQ0MWMgaXMgMmFmZmIwMDAhDQpbICAyMDMuMDA0OTc1XSAyZDQxYiBpcyAyYWZmYzAwMCEN
ClsgIDIwMy4wMDY3NjJdIDJkNDFhIGlzIDJhZmZkMDAwIQ0KWyAgMjAzLjAwODU0MV0gMmQ0
MTkgaXMgMmFmZmUwMDAhDQpbICAyMDMuMDEwMzAzXSAyZDQxOCBpcyAyYWZmZjAwMCENClsg
IDIwMy4wMTIwNjBdIDJkNDE3IGlzIDJiMDAwMDAwIQ0KWyAgMjAzLjAxMzgyM10gMmQ0MTYg
aXMgMmIwMDEwMDAhDQpbICAyMDMuMDE1NTU5XSAyZDQxNSBpcyAyYjAwMjAwMCENClsgIDIw
My4wMTczMjFdIDJkNDE0IGlzIDJiMDAzMDAwIQ0KWyAgMjAzLjAxOTA0NV0gMmQ0MTMgaXMg
MmIwMDQwMDAhDQpbICAyMDMuMDIwNzk1XSAyZDQxMiBpcyAyYjAwNTAwMCENClsgIDIwMy4w
MjI1MTNdIDJkNDFmIGlzIDJhZmYwMDAwIQ0KWyAgMjAzLjAyNDI1OV0gMmQ0MjAgaXMgMmFm
ZjEwMDAhDQpbICAyMDMuMDI2MDExXSAyZDQyMSBpcyAyYWZmMjAwMCENClsgIDIwMy4wMjc3
NjFdIDJkNDIyIGlzIDJhZmYzMDAwIQ0KWyAgMjAzLjAyOTUwM10gMmQ0MjMgaXMgMmFmZjQw
MDAhDQpbICAyMDMuMDMxMjQxXSAyZDQyNCBpcyAyYWZmNTAwMCENClsgIDIwMy4wMzI5ODdd
IDJkNDI1IGlzIDJhZmY2MDAwIQ0KWyAgMjAzLjAzNDczMF0gMmQ0MjYgaXMgMmFmZjcwMDAh
DQpbICAyMDMuMDM2NDYwXSAyZDQyNyBpcyAyYWZmODAwMCENClsgIDIwMy4wMzgyMDhdIDJk
NDFlIGlzIDJhZmY5MDAwIQ0KWyAgMjAzLjAzOTkyN10gMmQ0MWQgaXMgMmFmZmEwMDAhDQpb
ICAyMDMuMDQyMDEyXSAyZDQzZSBpcyAyYWZkMTAwMCENClsgIDIwMy4wNDM3OTVdIDJkNDNm
IGlzIDJhZmQyMDAwIQ0KWyAgMjAzLjA0NTU1Ml0gMmQ0NDAgaXMgMmFmZDMwMDAhDQpbICAy
MDMuMDQ3Mjg4XSAyZDQ0MSBpcyAyYWZkNDAwMCENClsgIDIwMy4wNDkwMzFdIDJkNDQyIGlz
IDJhZmQ1MDAwIQ0KWyAgMjAzLjA1MDc5N10gMmQ0NDMgaXMgMmFmZDYwMDAhDQpbICAyMDMu
MDUyNTM0XSAyZDQ0NCBpcyAyYWZkNzAwMCENClsgIDIwMy4wNTQzMDhdIDJkNDQ1IGlzIDJh
ZmQ4MDAwIQ0KWyAgMjAzLjA1NjAzOF0gMmQ0NDYgaXMgMmFmZDkwMDAhDQpbICAyMDMuMDU3
Nzc3XSAyZDQ0NyBpcyAyYWZkYTAwMCENClsgIDIwMy4wNTk0NzldIDJkNDQ4IGlzIDJhZmRi
MDAwIQ0KWyAgMjAzLjA2MTE4NF0gMmQ0NDkgaXMgMmFmYzcwMDAhDQpbICAyMDMuMDYyOTI1
XSAyZDQ0YSBpcyAyYWZjODAwMCENClsgIDIwMy4wNjQ2NTFdIDJkNDRiIGlzIDJhZmM5MDAw
IQ0KWyAgMjAzLjA2NjM3Nl0gMmQ0NGMgaXMgMmFmY2EwMDAhDQpbICAyMDMuMDY4MDcxXSAy
ZDQ0ZCBpcyAyYWZjYjAwMCENClsgIDIwMy4wNjk3NjVdIDJkNDRlIGlzIDJhZmNjMDAwIQ0K
WyAgMjAzLjA3MTQ2Ml0gMmQ0NGYgaXMgMmFmY2QwMDAhDQpbICAyMDMuMDczMTI5XSAyZDQ1
MCBpcyAyYWZjZTAwMCENClsgIDIwMy4wNzQ4MzJdIDJkNDUxIGlzIDJhZmNmMDAwIQ0KWyAg
MjAzLjA3NjUwNV0gMmQ0NTIgaXMgMmFmZDAwMDAhDQpbICAyMDMuMDc4MTgxXSAyZDQzMyBp
cyAyYWZkYzAwMCENClsgIDIwMy4wNzk4NThdIDJkNDM0IGlzIDJhZmRkMDAwIQ0KWyAgMjAz
LjA4MTUzM10gMmQ0MzUgaXMgMmFmZGUwMDAhDQpbICAyMDMuMDgzMjIyXSAyZDQzNiBpcyAy
YWZkZjAwMCENClsgIDIwMy4wODQ5MTFdIDJkNDM3IGlzIDJhZmUwMDAwIQ0KWyAgMjAzLjA4
NjU4NF0gMmQ0MzggaXMgMmFmZTEwMDAhDQpbICAyMDMuMDg4Mjg3XSAyZDQzOSBpcyAyYWZl
MjAwMCENClsgIDIwMy4wODk5NTVdIDJkNDNhIGlzIDJhZmUzMDAwIQ0KWyAgMjAzLjA5MTY1
N10gMmQ0M2IgaXMgMmFmZTQwMDAhDQpbICAyMDMuMDkzMzI0XSAyZDQzYyBpcyAyYWZlNTAw
MCENClsgIDIwMy4wOTUwNDldIDJkNDNkIGlzIDJhZmU2MDAwIQ0KWyAgMjAzLjA5OTkxN10g
MmQ0NTMgaXMgMmFmYzYwMDAhDQpbICAyMDMuMTAyMDE2XSAyZDQ1NCBpcyAyYWZjNTAwMCEN
ClsgIDIwMy4xMDczODVdIDJkNDU1IGlzIDJhZmM0MDAwIQ0KWyAgMjAzLjEwOTQ5Ml0gMmRi
ZTYgaXMgMmFmYzMwMDAhDQpbICAyMDMuMTExNTc3XSAyZDQ1NiBpcyAyYWZjMjAwMCENClsg
IDIwMy4xMTM2ODRdIDJkNDU3IGlzIDJhZmMxMDAwIQ0KWyAgMjAzLjEyMTk4OV0gMmQ0NTgg
aXMgMmFmYmQwMDAhDQpbICAyMDMuMTIzNzE3XSAyZDQ1OSBpcyAyYWZiZTAwMCENClsgIDIw
My4xMjU0MTddIDJkNDVhIGlzIDJhZmJmMDAwIQ0KWyAgMjAzLjEyNzEwOV0gMmQ0NWIgaXMg
MmFmYzAwMDAhDQpbICAyMDMuMTI5MTk3XSAyZDQ1YyBpcyAyYWZiYzAwMCENClsgIDIwMy4x
MzM2MDddIDJkNDVkIGlzIDJhZmJiMDAwIQ0KWyAgMjAzLjEzNTcxNF0gMmQ0NWUgaXMgMmFm
YmEwMDAhDQpbICAyMDMuMTM3ODM3XSAyZDQ1ZiBpcyAyYWZiOTAwMCENClsgIDIwMy4xMzk5
MzNdIDJkNDYwIGlzIDJhZmI4MDAwIQ0KWyAgMjAzLjE0MjA1OF0gMmQ0NjEgaXMgMmFmYjcw
MDAhDQpbICAyMDMuMTUyMjg0XSAyZDQ2MiBpcyAyYWZiNjAwMCENClsgIDIwMy4xNTQ4NTFd
IDJkNDYzIGlzIDJhZmI1MDAwIQ0KWyAgMjAzLjE1Njk1OV0gMmQ0NjQgaXMgMmFmYjQwMDAh
DQpbICAyMDMuMTY3NTAzXSAyZDQ2NSBpcyAyYWZiMDAwMCENClsgIDIwMy4xNjkyMDFdIDJk
NDY2IGlzIDJhZmIxMDAwIQ0KWyAgMjAzLjE3MDkwNF0gMmQ0NjcgaXMgMmFmYjIwMDAhDQpb
ICAyMDMuMTcyNTY4XSAyZDQ2OCBpcyAyYWZiMzAwMCENClsgIDIwMy4xNzQ2MThdIDJkYmU3
IGlzIDJhZmFmMDAwIQ0KWyAgMjAzLjE3Njk2Ml0gMmRiZTggaXMgMmFmYWIwMDAhDQpbICAy
MDMuMTc4NjQ5XSAyZDQ2OSBpcyAyYWZhYzAwMCENClsgIDIwMy4xODAzNTFdIDJkNDZhIGlz
IDJhZmFkMDAwIQ0KWyAgMjAzLjE4MjAzOF0gMmQ0NmIgaXMgMmFmYWUwMDAhDQpbICAyMDMu
MTg0MTU3XSAyZDQ2ZCBpcyAyYWZhYTAwMCENClsgIDIwMy4xODY1MDhdIDJkNDZlIGlzIDJh
ZmE2MDAwIQ0KWyAgMjAzLjE4ODI4OV0gMmQ0NmYgaXMgMmFmYTcwMDAhDQpbICAyMDMuMTg5
OTc5XSAyZDQ3MCBpcyAyYWZhODAwMCENClsgIDIwMy4xOTE3MDNdIDJkNDcxIGlzIDJhZmE5
MDAwIQ0KWyAgMjAzLjIwMjQ2MF0gMmQ0NzIgaXMgMmFmOWIwMDAhDQpbICAyMDMuMjA0MjAy
XSAyZDQ3MyBpcyAyYWY5YzAwMCENClsgIDIwMy4yMDU5MjhdIDJkNDc0IGlzIDJhZjlkMDAw
IQ0KWyAgMjAzLjIwNzY0MF0gMmQ0NzUgaXMgMmFmOWUwMDAhDQpbICAyMDMuMjA5MzQ2XSAy
ZDQ3NiBpcyAyYWY5ZjAwMCENClsgIDIwMy4yMTEwMzJdIDJkNDc3IGlzIDJhZmEwMDAwIQ0K
WyAgMjAzLjIxMjcyNF0gMmQ0NzggaXMgMmFmYTEwMDAhDQpbICAyMDMuMjE0NDMwXSAyZDQ3
OSBpcyAyYWZhMjAwMCENClsgIDIwMy4yMTYxMjVdIDJkNDdhIGlzIDJhZmEzMDAwIQ0KWyAg
MjAzLjIxNzg0NV0gMmQ0N2IgaXMgMmFmYTQwMDAhDQpbICAyMDMuMjE5NTIzXSAyZDQ3YyBp
cyAyYWZhNTAwMCENClsgIDIwMy4yMjQyNzldIDJkNDdkIGlzIDJhZjkwMDAwIQ0KWyAgMjAz
LjIyNTk2OV0gMmQ0N2UgaXMgMmFmOTEwMDAhDQpbICAyMDMuMjI3NjcxXSAyZDQ3ZiBpcyAy
YWY5MjAwMCENClsgIDIwMy4yMjkzNzBdIDJkNDgwIGlzIDJhZjkzMDAwIQ0KWyAgMjAzLjIz
MTE0OV0gMmQ0ODEgaXMgMmFmOTQwMDAhDQpbICAyMDMuMjMyODQ1XSAyZDQ4MiBpcyAyYWY5
NTAwMCENClsgIDIwMy4yMzQ1MzhdIDJkNDgzIGlzIDJhZjk2MDAwIQ0KWyAgMjAzLjIzNjIx
MV0gMmQ0ODQgaXMgMmFmOTcwMDAhDQpbICAyMDMuMjM3OTIzXSAyZDQ4NSBpcyAyYWY5ODAw
MCENClsgIDIwMy4yMzk2MDNdIDJkNDg2IGlzIDJhZjk5MDAwIQ0KWyAgMjAzLjI0MTMwNl0g
MmQ0ODcgaXMgMmFmOWEwMDAhDQpbICAyMDMuMjQzMDg4XSAyZDQ4OCBpcyAyYWY4ZTAwMCEN
ClsgIDIwMy4yNDQ4MTNdIDJkNDg5IGlzIDJhZjhmMDAwIQ0KWyAgMjAzLjI1MzI0MV0gMmQ0
OGIgaXMgMmFmOGQwMDAhDQpbICAyMDMuMjU5MjM2XSAyZDQ4YSBpcyAyYWY1ZjAwMCENClsg
IDIwMy4yNjEzNTVdIDJkNDhjIGlzIDJhZjYwMDAwIQ0KWyAgMjAzLjI2MzQ4OF0gMmQ0OGQg
aXMgMmFmNjEwMDAhDQpbICAyMDMuMjY1NzA0XSAyZDQ4ZSBpcyAyYWY2NDAwMCENClsgIDIw
My4yNjc0NTJdIDJkNDhmIGlzIDJhZjYzMDAwIQ0KWyAgMjAzLjI2OTE0MV0gMmQ0OTAgaXMg
MmFmNjIwMDAhDQpbICAyMDMuMjcxMDMyXSAyZDQ5MiBpcyAyYWY2YjAwMCENClsgIDIwMy4y
NzI2OTFdIDJkNDkzIGlzIDJhZjZhMDAwIQ0KWyAgMjAzLjI3NDQzMl0gMmQ0OTQgaXMgMmFm
NjkwMDAhDQpbICAyMDMuMjc2MDk0XSAyZDQ5NSBpcyAyYWY2ODAwMCENClsgIDIwMy4yNzc3
NzVdIDJkNDk2IGlzIDJhZjY3MDAwIQ0KWyAgMjAzLjI3OTQ1NV0gMmQ0OTcgaXMgMmFmNjYw
MDAhDQpbICAyMDMuMjgxMTIxXSAyZDQ5OCBpcyAyYWY2NTAwMCENClsgIDIwMy4yODI4OThd
IDJkNDkxIGlzIDJhZjZkMDAwIQ0KWyAgMjAzLjI4NzM5MV0gMmQ0OWEgaXMgMmFmNzQwMDAh
DQpbICAyMDMuMjg5NDg0XSAyZDQ5YiBpcyAyYWY4NzAwMCENClsgIDIwMy4yOTE2MTNdIDJk
NDljIGlzIDJhZjg4MDAwIQ0KWyAgMjAzLjI5MzcyOV0gMmQ0OWQgaXMgMmFmODYwMDAhDQpb
ICAyMDMuMjk1ODI0XSAyZDQ5ZSBpcyAyYWY4NTAwMCENClsgIDIwMy4yOTgwMDBdIDJkNGEw
IGlzIDJhZjhiMDAwIQ0KWyAgMjAzLjMwMDE0MV0gMmQ0YTEgaXMgMmFmOGMwMDAhDQpbICAy
MDMuMzA0NDExXSAyZDRhMiBpcyAyYWY4MTAwMCENClsgIDIwMy4zMTU1NDZdIDJkNGEzIGlz
IDJhZjdhMDAwIQ0KWyAgMjAzLjMxNzMwOV0gMmQ0YTQgaXMgMmFmNzcwMDAhDQpbICAyMDMu
MzE4OTkzXSAyZDRhNSBpcyAyYWY3ODAwMCENClsgIDIwMy4zMjA3MTddIDJkNGE2IGlzIDJh
ZjdiMDAwIQ0KWyAgMjAzLjMyMjc5NV0gMmQ0YTcgaXMgMmFmODQwMDAhDQpbICAyMDMuMzI2
NDg2XSAyZDRhOCBpcyAyYWY2ZTAwMCENClsgIDIwMy4zMjg2MjFdIDJkNDlmIGlzIDJhZjcz
MDAwIQ0KWyAgMjAzLjMzMDgwNF0gMmQ0OTkgaXMgMmFmNzkwMDAhDQpbICAyMDMuMzMyOTU4
XSAyZDQ2YyBpcyAyYWY4YTAwMCENClsgIDIwMy4zNDM0NzBdIDJkNGE5IGlzIDJhZjg5MDAw
IQ0KWyAgMjAzLjM0NTY0M10gMmRiZTkgaXMgMmFmNzUwMDAhDQpbICAyMDMuMzU0NDcxXSAy
ZDRhYSBpcyAyYWY3NjAwMCENClsgIDIwMy4zNTY4NDJdIDJkNGFiIGlzIDJiMTI0MDAwIQ0K
WyAgMjAzLjM1OTA0NV0gMmQ0YWMgaXMgMmFkMmQwMDAhDQpbICAyMDMuMzYxMjQzXSAyZDRh
ZCBpcyAyYTZjOTAwMCENClsgIDIwMy4zNjM1MTBdIDJkYmVhIGlzIDJhYzFmMDAwIQ0KWyAg
MjAzLjM3MDQwN10gMmQ0YWUgaXMgMmIxMGUwMDAhDQpbICAyMDMuMzcyMjQ4XSAyZDRhZiBp
cyAyYWY3MjAwMCENClsgIDIwMy4zNzQxMjhdIDJkNGIwIGlzIDJiMTE4MDAwIQ0KWyAgMjAz
LjM3NTk4OF0gMmQ0YjEgaXMgMmIxMTcwMDAhDQpbICAyMDMuMzc4MjM0XSAyZGJlYiBpcyAy
YWY1ZTAwMCENClsgIDIwMy4zODA1MzFdIDJkNGM3IGlzIDJhZjVkMDAwIQ0KWyAgMjAzLjM4
Mjg4Ml0gMmQ0YzggaXMgMmFmODAwMDAhDQpbICAyMDMuMzkxMjQ1XSAyZDRiMiBpcyAyYWY1
YzAwMCENClsgIDIwMy4zOTMxNzhdIDJkNGM5IGlzIDJhZjdkMDAwIQ0KWyAgMjAzLjM5NTE0
NF0gMmQ0Y2EgaXMgMmFmN2UwMDAhDQpbICAyMDMuMzk3MDc3XSAyZDRjYiBpcyAyYWY3ZjAw
MCENClsgIDIwMy4zOTkzOTVdIDJkNGNjIGlzIDJhZjViMDAwIQ0KWyAgMjAzLjQwMTczM10g
MmQ0YjMgaXMgMmFmNWEwMDAhDQpbICAyMDMuNDA0MTAzXSAyZDRjZCBpcyAyYWY1OTAwMCEN
ClsgIDIwMy40MDY4MDJdIDJkNGNlIGlzIDJhZjU1MDAwIQ0KWyAgMjAzLjQwODc0Nl0gMmQ0
YjQgaXMgMmFmNTYwMDAhDQpbICAyMDMuNDEwNjg2XSAyZDRiNSBpcyAyYWY1NzAwMCENClsg
IDIwMy40MTI2MTddIDJkNGI2IGlzIDJhZjU4MDAwIQ0KWyAgMjAzLjQxNDg3M10gMmQ0Yjcg
aXMgMmFmNTQwMDAhDQpbICAyMDMuNDI0MDIxXSAyZDRjZiBpcyAyYWY1MDAwMCENClsgIDIw
My40MjU5NDFdIDJkNGI4IGlzIDJhZjUxMDAwIQ0KWyAgMjAzLjQyNzg2NF0gMmQ0YjkgaXMg
MmFmNTIwMDAhDQpbICAyMDMuNDI5Nzc0XSAyZDRiYSBpcyAyYWY1MzAwMCENClsgIDIwMy40
NDA1NThdIDJkNGQwIGlzIDJhZjRmMDAwIQ0KWyAgMjAzLjQ0MzAxN10gMmQ0ZDEgaXMgMmFm
NGIwMDAhDQpbICAyMDMuNDQ0OTMzXSAyZDRiYiBpcyAyYWY0YzAwMCENClsgIDIwMy40NDY4
MjFdIDJkNGJjIGlzIDJhZjRkMDAwIQ0KWyAgMjAzLjQ0ODY4MF0gMmQ0YmQgaXMgMmFmNGUw
MDAhDQpbICAyMDMuNDUxNTM0XSAyZDRiZSBpcyAyYWY0MDAwMCENClsgIDIwMy40NTM0NTdd
IDJkNGJmIGlzIDJhZjQxMDAwIQ0KWyAgMjAzLjQ1NTI4MV0gMmQ0YzAgaXMgMmFmNDIwMDAh
DQpbICAyMDMuNDU3MTI2XSAyZDRjMSBpcyAyYWY0MzAwMCENClsgIDIwMy40NTg4OThdIDJk
NGMyIGlzIDJhZjQ0MDAwIQ0KWyAgMjAzLjQ2MDY2OV0gMmQ0YzMgaXMgMmFmNDUwMDAhDQpb
ICAyMDMuNDYyNDI5XSAyZDRjNCBpcyAyYWY0NjAwMCENClsgIDIwMy40NjQxODZdIDJkNGM1
IGlzIDJhZjRbICAyMDUuNjAwMTg5XSAyZDAyMiBpcyAyYjNlYzAwMCENClsgIDIwNS42MDE5
MjBdIDJkMDIzIGlzIDJiM2VkMDAwIQ0KWyAgMjA1LjYwMzY1OV0gMmQwMjQgaXMgMmIzZWUw
MDAhDQpbICAyMDUuNjA1Mzc0XSAyZDAyNSBpcyAyYjNlZjAwMCENClsgIDIwNS42MDc0NTZd
IDJkMDAxIGlzIDJiM2ViMDAwIQ0KWyAgMjA1LjYwOTYzM10gMmQwMDIgaXMgMmIzZWEwMDAh
DQpbICAyMDUuNjExNzUwXSAyZDAyNiBpcyAyYjNlOTAwMCENClsgIDIwNS42MTM5MDFdIDJk
MDI3IGlzIDJiM2U4MDAwIQ0KWyAgMjA1LjYxNTk4OF0gMmQwMjggaXMgMmIzZTcwMDAhDQpb
ICAyMDUuNjE4MTQzXSAyZDAwMyBpcyAyYjNlNjAwMCENClsgIDIwNS42MjAyNzZdIDJkMDI5
IGlzIDJiM2U1MDAwIQ0KWyAgMjA1LjYyMjM2MF0gMmQwMmEgaXMgMmIzZTQwMDAhDQpbICAy
MDUuNjI1OTU1XSAyZDAwNCBpcyAyYjNlMDAwMCENClsgIDIwNS42Mjc2OTJdIDJkMDJiIGlz
IDJiM2UxMDAwIQ0KWyAgMjA1LjYyOTQyOF0gMmQwMmMgaXMgMmIzZTIwMDAhDQpbICAyMDUu
NjMxMTc4XSAyZDAyZCBpcyAyYjNlMzAwMCENClsgIDIwNS42MzMyODVdIDJkMDJlIGlzIDJi
M2RmMDAwIQ0KWyAgMjA1LjYzNTU1M10gMmQwMmYgaXMgMmIzZGIwMDAhDQpbICAyMDUuNjM3
Mjc4XSAyZDAwNSBpcyAyYjNkYzAwMCENClsgIDIwNS42Mzg5NjldIDJkMDA2IGlzIDJiM2Rk
MDAwIQ0KWyAgMjA1LjY0MDY4Ml0gMmQwMDcgaXMgMmIzZGUwMDAhDQpbICAyMDUuNjQzMTQ2
XSAyZDAwOCBpcyAyYjNkMzAwMCENClsgIDIwNS42NDQ4OTFdIDJkMDMwIGlzIDJiM2Q0MDAw
IQ0KWyAgMjA1LjY0NjYxNF0gMmQwMzEgaXMgMmIzZDUwMDAhDQpbICAyMDUuNjQ4MzM1XSAy
ZDAzMiBpcyAyYjNkNjAwMCENClsgIDIwNS42NTAxMDBdIDJkMDMzIGlzIDJiM2Q3MDAwIQ0K
WyAgMjA1LjY1MTgzMl0gMmQwMzQgaXMgMmIzZDgwMDAhDQpbICAyMDUuNjUzNjEwXSAyZDAz
NSBpcyAyYjNkOTAwMCENClsgIDIwNS42NTUzMTldIDJkMDM2IGlzIDJiM2RhMDAwIQ0KWyAg
MjA1LjY1Nzk4MF0gMmQwNDEgaXMgMmIzYjgwMDAhDQpbICAyMDUuNjU5NzI0XSAyZDA0MCBp
cyAyYjNiOTAwMCENClsgIDIwNS42NjE0ODNdIDJkMDNmIGlzIDJiM2JhMDAwIQ0KWyAgMjA1
LjY2MzIxOF0gMmQwM2UgaXMgMmIzYmIwMDAhDQpbICAyMDUuNjY0OTQ5XSAyZDAzZCBpcyAy
YjNiYzAwMCENClsgIDIwNS42NjY2ODVdIDJkMDNjIGlzIDJiM2JkMDAwIQ0KWyAgMjA1LjY2
ODQyMF0gMmQwM2IgaXMgMmIzYmUwMDAhDQpbICAyMDUuNjcwMTU1XSAyZDAzYSBpcyAyYjNi
ZjAwMCENClsgIDIwNS42NzE4NzldIDJkMDM5IGlzIDJiM2MwMDAwIQ0KWyAgMjA1LjY3MzU5
NV0gMmQwMzggaXMgMmIzYzEwMDAhDQpbICAyMDUuNjc1MzEzXSAyZDAzNyBpcyAyYjNjMjAw
MCENClsgIDIwNS42NzcwMzZdIDJkMDQzIGlzIDJiM2MzMDAwIQ0KWyAgMjA1LjY3ODc1OF0g
MmQwNDQgaXMgMmIzYzQwMDAhDQpbICAyMDUuNjgwNDY4XSAyZDA0NSBpcyAyYjNjNTAwMCEN
ClsgIDIwNS42ODIxNjNdIDJkMDQ2IGlzIDJiM2M2MDAwIQ0KWyAgMjA1LjY4Mzg3OF0gMmQw
NDcgaXMgMmIzYzcwMDAhDQpbICAyMDUuNjg2NDEwXSAyZDA1NiBpcyAyYjNhMzAwMCENClsg
IDIwNS42ODgyNTJdIDJkMDU3IGlzIDJiM2E0MDAwIQ0KWyAgMjA1LjY4OTk4NF0gMmQwNTgg
aXMgMmIzYTUwMDAhDQpbICAyMDUuNjkxNzIxXSAyZDA1OSBpcyAyYjNhNjAwMCENClsgIDIw
NS42OTM0NDhdIDJkMDVhIGlzIDJiM2E3MDAwIQ0KWyAgMjA1LjY5NTE0NF0gMmQwNWIgaXMg
MmIzYTgwMDAhDQpbICAyMDUuNjk2ODc5XSAyZDA1YyBpcyAyYjNhOTAwMCENClsgIDIwNS42
OTg1NjNdIDJkMDVkIGlzIDJiM2FhMDAwIQ0KWyAgMjA1LjcwMDI4Ml0gMmQwNWUgaXMgMmIz
YWIwMDAhDQpbICAyMDUuNzAxOTgzXSAyZDA1ZiBpcyAyYjNhYzAwMCENClsgIDIwNS43MDM3
MDBdIDJkMDU1IGlzIDJiMzk4MDAwIQ0KWyAgMjA1LjcwNTM4Ml0gMmQwNTQgaXMgMmIzOTkw
MDAhDQpbICAyMDUuNzA3MDg4XSAyZDA1MyBpcyAyYjM5YTAwMCENClsgIDIwNS43MDg4MTJd
IDJkMDUyIGlzIDJiMzliMDAwIQ0KWyAgMjA1LjcxMDQ5Ml0gMmQwNGYgaXMgMmIzOWMwMDAh
DQpbICAyMDUuNzEyMTg3XSAyZDA0ZSBpcyAyYjM5ZDAwMCENClsgIDIwNS43MTM4NjhdIDJk
MDRkIGlzIDJiMzllMDAwIQ0KWyAgMjA1LjcxNTUzNF0gMmQwNGMgaXMgMmIzOWYwMDAhDQpb
ICAyMDUuNzE3MjIxXSAyZDA0YiBpcyAyYjNhMDAwMCENClsgIDIwNS43MTg4ODJdIDJkMDRh
IGlzIDJiM2ExMDAwIQ0KWyAgMjA1LjcyMDU3M10gMmQwNDkgaXMgMmIzYTIwMDAhDQpbICAy
MDUuNzMxNjc4XSAyZDAxMSBpcyAyYjM3ODAwMCENClsgIDIwNS43MzM1NzhdIDJkMDEwIGlz
IDJiMzc5MDAwIQ0KWyAgMjA1LjczNTI3NF0gMmQwMGYgaXMgMmIzN2EwMDAhDQpbICAyMDUu
NzM2OTkzXSAyZDAwZSBpcyAyYjM3YjAwMCENClsgIDIwNS43Mzg2OTJdIDJkMDBkIGlzIDJi
MzdjMDAwIQ0KWyAgMjA1Ljc0MDM1OF0gMmQwMGMgaXMgMmIzN2QwMDAhDQpbICAyMDUuNzQy
MDI1XSAyZDAwYiBpcyAyYjM3ZTAwMCENClsgIDIwNS43NDM2OTNdIDJkMDBhIGlzIDJiMzdm
MDAwIQ0KWyAgMjA1Ljc0NTM1N10gMmQwMDkgaXMgMmIzODAwMDAhDQpbICAyMDUuNzQ3MDMy
XSAyZDA0OCBpcyAyYjM4MTAwMCENClsgIDIwNS43NDg3MDBdIDJkMDYwIGlzIDJiMzgyMDAw
IQ0KWyAgMjA1Ljc1MDc1MF0gMmQwNjEgaXMgMmIzNjMwMDAhDQpbICAyMDUuNzUyNDY2XSAy
ZDA2MiBpcyAyYjM2NDAwMCENClsgIDIwNS43NTQxNjhdIDJkMDYzIGlzIDJiMzY1MDAwIQ0K
WyAgMjA1Ljc1NTgxOF0gMmQwNjQgaXMgMmIzNjYwMDAhDQpbICAyMDUuNzU3NDc2XSAyZDA2
NSBpcyAyYjM2NzAwMCENClsgIDIwNS43NTkxNDJdIDJkMDY2IGlzIDJiMzY4MDAwIQ0KWyAg
MjA1Ljc2MDgwN10gMmQwNjcgaXMgMmIzNjkwMDAhDQpbICAyMDUuNzYyNDc5XSAyZDA2OCBp
cyAyYjM2YTAwMCENClsgIDIwNS43NjQxMzddIDJkMDY5IGlzIDJiMzZiMDAwIQ0KWyAgMjA1
Ljc2NTc4Nl0gMmQwNmEgaXMgMmIzNmMwMDAhDQpbICAyMDUuNzY3NDYwXSAyZDA2YiBpcyAy
YjM1ODAwMCENClsgIDIwNS43NjkxMTBdIDJkMDZjIGlzIDJiMzU5MDAwIQ0KWyAgMjA1Ljc3
MDc4OV0gMmQwNmQgaXMgMmIzNWEwMDAhDQpbICAyMDUuNzcyNDQ1XSAyZDA2ZSBpcyAyYjM1
YjAwMCENClsgIDIwNS43NzQxMDhdIDJkMDZmIGlzIDJiMzVjMDAwIQ0KWyAgMjA1Ljc3NTc3
NF0gMmQwNzAgaXMgMmIzNWQwMDAhDQpbICAyMDUuNzc3NDQzXSAyZDA5MCBpcyAyYjM1ZTAw
MCENClsgIDIwNS43NzkxMTRdIDJkMDkxIGlzIDJiMzVmMDAwIQ0KWyAgMjA1Ljc4MDc3N10g
MmQwOTIgaXMgMmIzNjAwMDAhDQpbICAyMDUuNzgyNDM5XSAyZDA5MyBpcyAyYjM2MTAwMCEN
ClsgIDIwNS43ODQxMjRdIDJkMDk0IGlzIDJiMzYyMDAwIQ0KWyAgMjA1Ljc4NTc2OF0gMmQw
OTUgaXMgMmIzNGQwMDAhDQpbICAyMDUuNzg3NDU5XSAyZDA5NiBpcyAyYjM0ZTAwMCENClsg
IDIwNS43ODkxMjBdIDJkMDk3IGlzIDJiMzRmMDAwIQ0KWyAgMjA1Ljc5MDc5NV0gMmQwOTgg
aXMgMmIzNTAwMDAhDQpbICAyMDUuNzkyNDkxXSAyZDA5OSBpcyAyYjM1MTAwMCENClsgIDIw
NS43OTQxNzJdIDJkMDlhIGlzIDJiMzUyMDAwIQ0KWyAgMjA1Ljc5NTg1NV0gMmQwOWIgaXMg
MmIzNTMwMDAhDQpbICAyMDUuNzk3NTM1XSAyZDA5YyBpcyAyYjM1NDAwMCENClsgIDIwNS43
OTkyMDVdIDJkMDlkIGlzIDJiMzU1MDAwIQ0KWyAgMjA1LjgwMDg2Ml0gMmQwOWUgaXMgMmIz
NTYwMDAhDQpbICAyMDUuODAyNTEyXSAyZDA5ZiBpcyAyYjM1NzAwMCENClsgIDIwNS44MDQx
ODZdIDJkMGEwIGlzIDJiMzQzMDAwIQ0KWyAgMjA1LjgwNTg0MV0gMmQwYTEgaXMgMmIzNDQw
MDAhDQpbICAyMDUuODA3NTI5XSAyZDBhMiBpcyAyYjM0NTAwMCENClsgIDIwNS44MDkxOTdd
IDJkMGEzIGlzIDJiMzQ2MDAwIQ0KWyAgMjA1LjgxMDg3N10gMmQwYTQgaXMgMmIzNDcwMDAh
DQpbICAyMDUuODEyNTYxXSAyZDBhNSBpcyAyYjM0ODAwMCENClsgIDIwNS44MTQyMzZdIDJk
MGE2IGlzIDJiMzQ5MDAwIQ0KWyAgMjA1LjgxNTkxMV0gMmQwYTcgaXMgMmIzNGEwMDAhDQpb
ICAyMDUuODE3NTg1XSAyZDBhOCBpcyAyYjM0YjAwMCENClsgIDIwNS44MTkyNDddIDJkMGE5
IGlzIDJiMzRjMDAwIQ0KWyAgMjA1LjgyMDkzMV0gMmQwN2IgaXMgMmIzNmQwMDAhDQpbICAy
MDUuODIyNjExXSAyZDA3YSBpcyAyYjM2ZTAwMCENClsgIDIwNS44MjQzMDVdIDJkMDc5IGlz
IDJiMzZmMDAwIQ0KWyAgMjA1LjgyNTk3MV0gMmQwNzggaXMgMmIzNzAwMDAhDQpbICAyMDUu
ODI3NjU3XSAyZDA3NyBpcyAyYjM3MTAwMCENClsgIDIwNS44MjkzNDFdIDJkMDc2IGlzIDJi
MzcyMDAwIQ0KWyAgMjA1LjgzMTAyMV0gMmQwNzUgaXMgMmIzNzMwMDAhDQpbICAyMDUuODMy
NzAzXSAyZDA3NCBpcyAyYjM3NDAwMCENClsgIDIwNS44MzQzNzBdIDJkMDczIGlzIDJiMzc1
MDAwIQ0KWyAgMjA1LjgzNjAyNV0gMmQwNzIgaXMgMmIzNzYwMDAhDQpbICAyMDUuODM3NzEw
XSAyZDA3MSBpcyAyYjM3NzAwMCENClsgIDIwNS44NDEwMDBdIDJkMGMzIGlzIDJiMzIzMDAw
IQ0KWyAgMjA1Ljg0MjcyNl0gMmQwYzQgaXMgMmIzMjQwMDAhDQpbICAyMDUuODQ0NDQyXSAy
ZDBjNSBpcyAyYjMyNTAwMCENClsgIDIwNS44NDYxMjBdIDJkMGM2IGlzIDJiMzI2MDAwIQ0K
WyAgMjA1Ljg0NzgwNV0gMmQwYzcgaXMgMmIzMjcwMDAhDQpbICAyMDUuODQ5NTA0XSAyZDBj
OCBpcyAyYjMyODAwMCENClsgIDIwNS44NTExNzZdIDJkMGM5IGlzIDJiMzI5MDAwIQ0KWyAg
MjA1Ljg1Mjg1OV0gMmQwY2EgaXMgMmIzMmEwMDAhDQpbICAyMDUuODU0NTY0XSAyZDBjYiBp
cyAyYjMyYjAwMCENClsgIDIwNS44NTYyMzFdIDJkMGNjIGlzIDJiMzJjMDAwIQ0KWyAgMjA1
Ljg1NzkzMl0gMmQwYWIgaXMgMmIzMzgwMDAhDQpbICAyMDUuODU5NTk4XSAyZDBhYyBpcyAy
YjMzOTAwMCENClsgIDIwNS44NjEyNzVdIDJkMGFkIGlzIDJiMzNhMDAwIQ0KWyAgMjA1Ljg2
Mjk3M10gMmQwYWUgaXMgMmIzM2IwMDAhDQpbICAyMDUuODY0NjQ5XSAyZDBhZiBpcyAyYjMz
YzAwMCENClsgIDIwNS44NjYzMzNdIDJkMGIyIGlzIDJiMzNkMDAwIQ0KWyAgMjA1Ljg2ODAx
Nl0gMmQwYjMgaXMgMmIzM2UwMDAhDQpbICAyMDUuODY5NzA1XSAyZDBiNCBpcyAyYjMzZjAw
MCENClsgIDIwNS44NzEzOTZdIDJkMGI1IGlzIDJiMzQwMDAwIQ0KWyAgMjA1Ljg3MzA2OV0g
MmQwYjYgaXMgMmIzNDEwMDAhDQpbICAyMDUuODc0NzcyXSAyZDBiNyBpcyAyYjM0MjAwMCEN
ClsgIDIwNS44NzY0MjddIDJkMGI4IGlzIDJiMzJkMDAwIQ0KWyAgMjA1Ljg3ODEwOF0gMmQw
YjkgaXMgMmIzMmUwMDAhDQpbICAyMDUuODc5NzkxXSAyZDBiYSBpcyAyYjMyZjAwMCENClsg
IDIwNS44ODE0NjZdIDJkMGJiIGlzIDJiMzMwMDAwIQ0KWyAgMjA1Ljg4MzE1Nl0gMmQwYmMg
aXMgMmIzMzEwMDAhDQpbICAyMDUuODg0ODM2XSAyZDBiZCBpcyAyYjMzMjAwMCENClsgIDIw
NS44ODY0OThdIDJkMGJlIGlzIDJiMzMzMDAwIQ0KWyAgMjA1Ljg4ODE4OV0gMmQwYmYgaXMg
MmIzMzQwMDAhDQpbICAyMDUuODg5ODUyXSAyZDBjMCBpcyAyYjMzNTAwMCENClsgIDIwNS44
OTE1NDhdIDJkMGMxIGlzIDJiMzM2MDAwIQ0KWyAgMjA1Ljg5MzIyMF0gMmQwYzIgaXMgMmIz
MzcwMDAhDQpbICAyMDUuODk2MTMzXSAyZDBlZCBpcyAyYjJlZDAwMCENClsgIDIwNS44OTc5
MjZdIDJkMGFhIGlzIDJiMmVlMDAwIQ0KWyAgMjA1Ljg5OTY1Nl0gMmQwN2MgaXMgMmIyZWYw
MDAhDQpbICAyMDUuOTAxMzc2XSAyZDA3ZCBpcyAyYjJmMDAwMCENClsgIDIwNS45MDMwODVd
IDJkMDdlIGlzIDJiMmYxMDAwIQ0KWyAgMjA1LjkwNDgzN10gMmQwN2YgaXMgMmIyZjIwMDAh
DQpbICAyMDUuOTA2NTQ1XSAyZDA4MCBpcyAyYjJmMzAwMCENClsgIDIwNS45MDgzMTBdIDJk
MDgxIGlzIDJiMmY0MDAwIQ0KWyAgMjA1LjkxMDA1NF0gMmQwODIgaXMgMmIyZjUwMDAhDQpb
ICAyMDUuOTExNzgwXSAyZDA4MyBpcyAyYjJmNjAwMCENClsgIDIwNS45MTM1MDNdIDJkMDg0
IGlzIDJiMmY3MDAwIQ0KWyAgMjA1LjkxNTIwN10gMmQwZDggaXMgMmIzMGQwMDAhDQpbICAy
MDUuOTE2OTUyXSAyZDBkOSBpcyAyYjMwZTAwMCENClsgIDIwNS45MTg2NjhdIDJkMGRhIGlz
IDJiMzBmMDAwIQ0KWyAgMjA1LjkyMDQxOF0gMmQwZGIgaXMgMmIzMTAwMDAhDQpbICAyMDUu
OTIyMTM2XSAyZDBkYyBpcyAyYjMxMTAwMCENClsgIDIwNS45MjM4NjldIDJkMGRkIGlzIDJi
MzEyMDAwIQ0KWyAgMjA1LjkyNTYwM10gMmQwZGUgaXMgMmIzMTMwMDAhDQpbICAyMDUuOTI3
MzI2XSAyZDBkZiBpcyAyYjMxNDAwMCENClsgIDIwNS45MjkwNTJdIDJkMGUwIGlzIDJiMzE1
MDAwIQ0KWyAgMjA1LjkzMDc3Ml0gMmQwZTEgaXMgMmIzMTYwMDAhDQpbICAyMDUuOTMyNDg5
XSAyZDBlMiBpcyAyYjMxNzAwMCENClsgIDIwNS45MzQyMDRdIDJkMGUzIGlzIDJiMzAzMDAw
IQ0KWyAgMjA1LjkzNTkxMV0gMmQwZTQgaXMgMmIzMDQwMDAhDQpbICAyMDUuOTM3NjQxXSAy
ZDBlNSBpcyAyYjMwNTAwMCENClsgIDIwNS45MzkzMzZdIDJkMGU2IGlzIDJiMzA2MDAwIQ0K
WyAgMjA1Ljk0MTA2N10gMmQwZTcgaXMgMmIzMDcwMDAhDQpbICAyMDUuOTQyNzc1XSAyZDBl
OCBpcyAyYjMwODAwMCENClsgIDIwNS45NDQ0OTddIDJkMGU5IGlzIDJiMzA5MDAwIQ0KWyAg
MjA1Ljk0NjIxNF0gMmQwZWEgaXMgMmIzMGEwMDAhDQpbICAyMDUuOTQ3OTIzXSAyZDBlYiBp
cyAyYjMwYjAwMCENClsgIDIwNS45NDk2MzZdIDJkMGVjIGlzIDJiMzBjMDAwIQ0KWyAgMjA1
Ljk1MTMyOF0gMmQwZDcgaXMgMmIyZjgwMDAhDQpbICAyMDUuOTUzMDI1XSAyZDBkNiBpcyAy
YjJmOTAwMCENClsgIDIwNS45NTQ3NDRdIDJkMGQ1IGlzIDJiMmZhMDAwIQ0KWyAgMjA1Ljk1
NjQyM10gMmQwZDQgaXMgMmIyZmIwMDAhDQpbICAyMDUuOTU4MTMxXSAyZDBkMyBpcyAyYjJm
YzAwMCENClsgIDIwNS45NTk4MTBdIDJkMGQyIGlzIDJiMmZkMDAwIQ0KWyAgMjA1Ljk2MTUx
MF0gMmQwZDEgaXMgMmIyZmUwMDAhDQpbICAyMDUuOTYzMTc4XSAyZDBkMCBpcyAyYjJmZjAw
MCENClsgIDIwNS45NjQ4NTNdIDJkMGNmIGlzIDJiMzAwMDAwIQ0KWyAgMjA1Ljk2NjU0N10g
MmQwY2UgaXMgMmIzMDEwMDAhDQpbICAyMDUuOTY4MjM5XSAyZDBjZCBpcyAyYjMwMjAwMCEN
ClsgIDIwNS45NzE1OTRdIDJkMGY5IGlzIDJiMmMzMDAwIQ0KWyAgMjA1Ljk3MzMzNF0gMmQw
ZmEgaXMgMmIyYzQwMDAhDQpbICAyMDUuOTc1MDY4XSAyZDBmYiBpcyAyYjJjNTAwMCENClsg
IDIwNS45NzY3NzhdIDJkMGZjIGlzIDJiMmM2MDAwIQ0KWyAgMjA1Ljk3ODQ4MV0gMmQwZmQg
aXMgMmIyYzcwMDAhDQpbICAyMDUuOTgwMTc2XSAyZDBmZSBpcyAyYjJjODAwMCENClsgIDIw
NS45ODE4NzZdIDJkMGZmIGlzIDJiMmM5MDAwIQ0KWyAgMjA1Ljk4MzYwMl0gMmQxMDAgaXMg
MmIyY2EwMDAhDQpbICAyMDUuOTg1Mjg2XSAyZDEwMSBpcyAyYjJjYjAwMCENClsgIDIwNS45
ODcwMDJdIDJkMTAyIGlzIDJiMmNjMDAwIQ0KWyAgMjA1Ljk4ODY5MV0gMmQwOGYgaXMgMmIy
ZDgwMDAhDQpbICAyMDUuOTkwNDA1XSAyZDA4ZSBpcyAyYjJkOTAwMCENClsgIDIwNS45OTIx
MTJdIDJkMDhkIGlzIDJiMmRhMDAwIQ0KWyAgMjA1Ljk5MzgyMV0gMmQwOGMgaXMgMmIyZGIw
MDAhDQpbICAyMDUuOTk1NTM0XSAyZDA4YiBpcyAyYjJkYzAwMCENClsgIDIwNS45OTcyMzdd
IDJkMDhhIGlzIDJiMmRkMDAwIQ0KWyAgMjA1Ljk5ODkzNl0gMmQwODkgaXMgMmIyZGUwMDAh
DQpbICAyMDYuMDAwNjI5XSAyZDA4OCBpcyAyYjJkZjAwMCENClsgIDIwNi4wMDIzMjRdIDJk
MDg3IGlzIDJiMmUwMDAwIQ0KWyAgMjA2LjAwNDA1MF0gMmQwODYgaXMgMmIyZTEwMDAhDQpb
ICAyMDYuMDA1NzQ1XSAyZDA4NSBpcyAyYjJlMjAwMCENClsgIDIwNi4wMDc0NDZdIDJkMGVl
IGlzIDJiMmNkMDAwIQ0KWyAgMjA2LjAwOTEzMl0gMmQwZWYgaXMgMmIyY2UwMDAhDQpbICAy
MDYuMDEwODMwXSAyZDBmMCBpcyAyYjJjZjAwMCENClsgIDIwNi4wMTI1MzZdIDJkMGYxIGlz
IDJiMmQwMDAwIQ0KWyAgMjA2LjAxNDIzOV0gMmQwZjIgaXMgMmIyZDEwMDAhDQpbICAyMDYu
MDE1OTQwXSAyZDBmMyBpcyAyYjJkMjAwMCENClsgIDIwNi4wMTc2NDNdIDJkMGY0IGlzIDJi
MmQzMDAwIQ0KWyAgMjA2LjAxOTMyN10gMmQwZjUgaXMgMmIyZDQwMDAhDQpbICAyMDYuMDIx
MDI0XSAyZDBmNiBpcyAyYjJkNTAwMCENClsgIDIwNi4wMjI2OTFdIDJkMGY3IGlzIDJiMmQ2
MDAwIQ0KWyAgMjA2LjAyNDM4OF0gMmQwZjggaXMgMmIyZDcwMDAhDQpbICAyMDYuMDI2OTYw
XSAyZDExMCBpcyAyYjJhZDAwMCENClsgIDIwNi4wMjg2ODJdIDJkMTExIGlzIDJiMmFlMDAw
IQ0KWyAgMjA2LjAzMDM4NF0gMmQxMTIgaXMgMmIyYWYwMDAhDQpbICAyMDYuMDMyMDY5XSAy
ZDExMyBpcyAyYjJiMDAwMCENClsgIDIwNi4wMzM3OTNdIDJkMTE0IGlzIDJiMmIxMDAwIQ0K
WyAgMjA2LjAzNTQ3OF0gMmQxMTUgaXMgMmIyYjIwMDAhDQpbICAyMDYuMDM3MjA4XSAyZDEx
NiBpcyAyYjJiMzAwMCENClsgIDIwNi4wMzkwMDldIDJkMTE3IGlzIDJiMmI0MDAwIQ0KWyAg
MjA2LjA0MDczN10gMmQxMTggaXMgMmIyYjUwMDAhDQpbICAyMDYuMDQyNDE4XSAyZDExOSBp
cyAyYjJiNjAwMCENClsgIDIwNi4wNDQwOTRdIDJkMTFhIGlzIDJiMmI3MDAwIQ0KWyAgMjA2
LjA0NTc3NF0gMmQxMWIgaXMgMmIyYTMwMDAhDQpbICAyMDYuMDQ3NDQwXSAyZDExYyBpcyAy
YjJhNDAwMCENClsgIDIwNi4wNDkxMjddIDJkMTFkIGlzIDJiMmE1MDAwIQ0KWyAgMjA2LjA1
MDc4Nl0gMmQxMWUgaXMgMmIyYTYwMDAhDQpbICAyMDYuMDUyNDQyXSAyZDExZiBpcyAyYjJh
NzAwMCENClsgIDIwNi4wNTQxMzNdIDJkMTIwIGlzIDJiMmE4MDAwIQ0KWyAgMjA2LjA1NTc4
M10gMmQxMjEgaXMgMmIyYTkwMDAhDQpbICAyMDYuMDU3NDU5XSAyZDEyMiBpcyAyYjJhYTAw
MCENClsgIDIwNi4wNTkxMDJdIDJkMTIzIGlzIDJiMmFiMDAwIQ0KWyAgMjA2LjA2MDc2MF0g
MmQxMjQgaXMgMmIyYWMwMDAhDQpbICAyMDYuMDYyNzAxXSAyZDEwZCBpcyAyYjI5ODAwMCEN
ClsgIDIwNi4wNjQ0MDFdIDJkMTBjIGlzIDJiMjk5MDAwIQ0KWyAgMjA2LjA2NjA2Ml0gMmQx
MGIgaXMgMmIyOWEwMDAhDQpbICAyMDYuMDY3NzE3XSAyZDEwYSBpcyAyYjI5YjAwMCENClsg
IDIwNi4wNjkzNzldIDJkMTA5IGlzIDJiMjljMDAwIQ0KWyAgMjA2LjA3MTA1NF0gMmQxMDgg
aXMgMmIyOWQwMDAhDQpbICAyMDYuMDcyNzIzXSAyZDEwNyBpcyAyYjI5ZTAwMCENClsgIDIw
Ni4wNzQ0MTldIDJkMTA2IGlzIDJiMjlmMDAwIQ0KWyAgMjA2LjA3NjA4MV0gMmQxMDUgaXMg
MmIyYTAwMDAhDQpbICAyMDYuMDc3NzU2XSAyZDEwNCBpcyAyYjJhMTAwMCENClsgIDIwNi4w
Nzk0NDJdIDJkMTAzIGlzIDJiMmEyMDAwIQ0KWyAgMjA2LjA4MTEwMV0gMmQxMjUgaXMgMmIy
OGQwMDAhDQpbICAyMDYuMDgyNzkzXSAyZDEyZiBpcyAyYjI4ZTAwMCENClsgIDIwNi4wODQ0
NzldIDJkMTMwIGlzIDJiMjhmMDAwIQ0KWyAgMjA2LjA4NjE0Nl0gMmQxMzEgaXMgMmIyOTAw
MDAhDQpbICAyMDYuMDg3ODQ0XSAyZDEzMiBpcyAyYjI5MTAwMCENClsgIDIwNi4wODk1Mjhd
IDJkMTMzIGlzIDJiMjkyMDAwIQ0KWyAgMjA2LjA5MTIyMF0gMmQxMzQgaXMgMmIyOTMwMDAh
DQpbICAyMDYuMDkyODg3XSAyZDEzNSBpcyAyYjI5NDAwMCENClsgIDIwNi4wOTQ1NzhdIDJk
MTM2IGlzIDJiMjk1MDAwIQ0KWyAgMjA2LjA5NjI0Nl0gMmQxMzcgaXMgMmIyOTYwMDAhDQpb
ICAyMDYuMDk3OTI2XSAyZDEzOCBpcyAyYjI5NzAwMCENClsgIDIwNi4wOTk1OTldIDJkMTM5
IGlzIDJiMjgzMDAwIQ0KWyAgMjA2LjEwMTI3NF0gMmQxM2EgaXMgMmIyOFsgIDIwOC4yMzI0
NzddIDJjODVhIGlzIDJiYjVmMDAwIQ0KWyAgMjA4LjIzNDcyNF0gMmM4NGIgaXMgMmJiNWIw
MDAhDQpbICAyMDguMjM2Mzk3XSAyYzg0YyBpcyAyYmI1YzAwMCENClsgIDIwOC4yMzgwODVd
IDJjODRkIGlzIDJiYjVkMDAwIQ0KWyAgMjA4LjIzOTc0MV0gMmM4NGUgaXMgMmJiNWUwMDAh
DQpbICAyMDguMjQxNzgxXSAyYzg1YyBpcyAyYmI1YTAwMCENClsgIDIwOC4yNDM4ODhdIDJj
ODVkIGlzIDJiYjU5MDAwIQ0KWyAgMjA4LjI0NTk2M10gMmM4NGYgaXMgMmJiNTgwMDAhDQpb
ICAyMDguMjQ4MDgyXSAyYzg1MCBpcyAyYmI1NzAwMCENClsgIDIwOC4yNTIyNTBdIDJjODUx
IGlzIDJiYjU2MDAwIQ0KWyAgMjA4LjI1NDMzOV0gMmM4NTIgaXMgMmJiNTUwMDAhDQpbICAy
MDguMjU2NDE4XSAyYzg1MyBpcyAyYmI1NDAwMCENClsgIDIwOC4yNTg0OTldIDJjODU1IGlz
IDJiYjUzMDAwIQ0KWyAgMjA4LjI2MDU2N10gMmM4NTYgaXMgMmJiNTIwMDAhDQpbICAyMDgu
MjYyNjQ0XSAyYzg3NiBpcyAyYmI1MTAwMCENClsgIDIwOC4yNjQ3MTBdIDJjODc3IGlzIDJi
YjUwMDAwIQ0KWyAgMjA4LjI2NjgxMV0gMmM4NzggaXMgMmJiNGYwMDAhDQpbICAyMDguMjY4
ODYxXSAyYzg3OSBpcyAyYmI0ZTAwMCENClsgIDIwOC4yNzA5NzFdIDJjODdhIGlzIDJiYjRk
MDAwIQ0KWyAgMjA4LjI3MzAyOF0gMmM4N2IgaXMgMmJiNGMwMDAhDQpbICAyMDguMjgwODM0
XSAyYzg3YyBpcyAyYmI0ODAwMCENClsgIDIwOC4yODI0NzJdIDJjODdkIGlzIDJiYjQ5MDAw
IQ0KWyAgMjA4LjI4NDEzNV0gMmM4N2UgaXMgMmJiNGEwMDAhDQpbICAyMDguMjg1NzYxXSAy
Yzg3ZiBpcyAyYmI0YjAwMCENClsgIDIwOC4yODc3NzNdIDJjODVlIGlzIDJiYjQ3MDAwIQ0K
WyAgMjA4LjI4OTgzMV0gMmM4NWYgaXMgMmJiNDYwMDAhDQpbICAyMDguMjkxODU0XSAyYzg4
MCBpcyAyYmI0NTAwMCENClsgIDIwOC4yOTM4OTZdIDJjODYwIGlzIDJiYjQ0MDAwIQ0KWyAg
MjA4LjI5NjU4NF0gMmM4NjEgaXMgMmJiMDQwMDAhDQpbICAyMDguMjk4NjM4XSAyYzg2MiBp
cyAyYmIwNTAwMCENClsgIDIwOC4zMDA3OTVdIDJjODYzIGlzIDJiYjA2MDAwIQ0KWyAgMjA4
LjMwNTc5N10gMmM4ODEgaXMgMmJiMGEwMDAhDQpbICAyMDguMzA3NDkyXSAyYzg4MiBpcyAy
YmIwOTAwMCENClsgIDIwOC4zMDkxMzZdIDJjODgzIGlzIDJiYjA4MDAwIQ0KWyAgMjA4LjMx
MDc4NF0gMmM4ODQgaXMgMmJiMDcwMDAhDQpbICAyMDguMzEzMzA2XSAyYzg4NSBpcyAyYmIx
NTAwMCENClsgIDIwOC4zMTUxOTddIDJjODg2IGlzIDJiYjE0MDAwIQ0KWyAgMjA4LjMxNjg5
NV0gMmM4ODcgaXMgMmJiMTMwMDAhDQpbICAyMDguMzE4NTM2XSAyYzg4OCBpcyAyYmIxMjAw
MCENClsgIDIwOC4zMjAyMDJdIDJjODg5IGlzIDJiYjExMDAwIQ0KWyAgMjA4LjMyMTgzNF0g
MmM4OGEgaXMgMmJiMTAwMDAhDQpbICAyMDguMzIzNDc1XSAyYzg4YiBpcyAyYmIwZjAwMCEN
ClsgIDIwOC4zMjUxMjVdIDJjODhjIGlzIDJiYjBlMDAwIQ0KWyAgMjA4LjMyNjc2NV0gMmM4
OGQgaXMgMmJiMGQwMDAhDQpbICAyMDguMzI4MzkxXSAyYzg4ZSBpcyAyYmIwYzAwMCENClsg
IDIwOC4zMzAwMjhdIDJjODhmIGlzIDJiYjBiMDAwIQ0KWyAgMjA4LjMzMTcxNF0gMmM4OTAg
aXMgMmJiMjAwMDAhDQpbICAyMDguMzMzNDE5XSAyYzg5MSBpcyAyYmIxZjAwMCENClsgIDIw
OC4zMzUwODFdIDJjODkyIGlzIDJiYjFlMDAwIQ0KWyAgMjA4LjMzNjc1N10gMmM4OTMgaXMg
MmJiMWQwMDAhDQpbICAyMDguMzM4NDM0XSAyYzg5NCBpcyAyYmIxYzAwMCENClsgIDIwOC4z
NDAxMDVdIDJjODk1IGlzIDJiYjFiMDAwIQ0KWyAgMjA4LjM0MTc4NF0gMmM4OTYgaXMgMmJi
MWEwMDAhDQpbICAyMDguMzQzNDU1XSAyYzg5NyBpcyAyYmIxOTAwMCENClsgIDIwOC4zNDUx
NDddIDJjODk4IGlzIDJiYjE4MDAwIQ0KWyAgMjA4LjM0NjgxOF0gMmM4OTkgaXMgMmJiMTcw
MDAhDQpbICAyMDguMzQ4NDc5XSAyYzg5YSBpcyAyYmIxNjAwMCENClsgIDIwOC4zNTAyODJd
IDJjODliIGlzIDJiYjNlMDAwIQ0KWyAgMjA4LjM1MTk2Nl0gMmM4OWMgaXMgMmJiMjEwMDAh
DQpbICAyMDguMzU0MDkxXSAyYzg2NSBpcyAyYmIyZjAwMCENClsgIDIwOC4zNTYyMDZdIDJj
ODY2IGlzIDJiYjMwMDAwIQ0KWyAgMjA4LjM2NzE0Ml0gMmM4NjQgaXMgMmJiMmUwMDAhDQpb
ICAyMDguMzY5MjkyXSAyYzg2NyBpcyAyYmIyZDAwMCENClsgIDIwOC4zNzgyMjhdIDJjODll
IGlzIDJiYjM3MDAwIQ0KWyAgMjA4LjM3OTk1OF0gMmM4NjggaXMgMmJiMzUwMDAhDQpbICAy
MDguMzgxNjgzXSAyYzg2OSBpcyAyYmIzNDAwMCENClsgIDIwOC4zODM0MjRdIDJjODZhIGlz
IDJiYjMzMDAwIQ0KWyAgMjA4LjM5MDgxOF0gMmM4NmIgaXMgMmJiM2EwMDAhDQpbICAyMDgu
MzkyOTc1XSAyYzg5ZiBpcyAyYmIzYjAwMCENClsgIDIwOC4zOTUxNTBdIDJjOGEwIGlzIDJi
YjM4MDAwIQ0KWyAgMjA4LjQwOTE2M10gMmM4YTEgaXMgMmJiMjIwMDAhDQpbICAyMDguNDE2
MzUzXSAyYzhhMiBpcyAyYmIzMjAwMCENClsgIDIwOC40MTgxNDZdIDJjOGEzIGlzIDJiYjM5
MDAwIQ0KWyAgMjA4LjQxOTg2Ml0gMmM4YTQgaXMgMmJiM2YwMDAhDQpbICAyMDguNDIxNjI3
XSAyYzhhNSBpcyAyYmI0MzAwMCENClsgIDIwOC40MjQwODRdIDJjOGE2IGlzIDJiYzlkMDAw
IQ0KWyAgMjA4LjQyNTg1M10gMmM4YTcgaXMgMmJiMjcwMDAhDQpbICAyMDguNDI3NjMxXSAy
YzhhOCBpcyAyYmIyOTAwMCENClsgIDIwOC40MjkzOTRdIDJjOGE5IGlzIDJiYjI4MDAwIQ0K
WyAgMjA4LjQzMTE2MF0gMmM4YWEgaXMgMmJjYWEwMDAhDQpbICAyMDguNDMyOTM3XSAyYzhh
YiBpcyAyYmIzYzAwMCENClsgIDIwOC40MzQ3MjldIDJjOGFjIGlzIDJiYjNkMDAwIQ0KWyAg
MjA4LjQzNjU1M10gMmM4YWQgaXMgMmJiMzEwMDAhDQpbICAyMDguNDM4NDc1XSAyYzhhZSBp
cyAyYTI2YjAwMCENClsgIDIwOC40NDk4ODldIDJjODZjIGlzIDJiYjQwMDAwIQ0KWyAgMjA4
LjQ3MDAxOF0gMmM4NmQgaXMgMmFkYTQwMDAhDQpbICAyMDguNDc2OTAwXSAyYzhhZiBpcyAy
YmM5ZjAwMCENClsgIDIwOC40NzkyMTNdIDJjOGIwIGlzIDJiYjAzMDAwIQ0KWyAgMjA4LjQ4
MTU0OV0gMmM4YjEgaXMgMmJiMjYwMDAhDQpbICAyMDguNDg0ODA0XSAyYzhiMiBpcyAyYmIy
NTAwMCENClsgIDIwOC40ODcxMjhdIDJjOGIzIGlzIDJiYjI0MDAwIQ0KWyAgMjA4LjUyOTM5
Ml0gMmM4YjQgaXMgMmJiMjMwMDAhDQpbICAyMDguNTQ2OTg3XSAyYzhiNSBpcyAyYjFjYzAw
MCENClsgIDIwOC41NzAyNDhdIDJjOGI2IGlzIDJiMWNiMDAwIQ0KWyAgMjA4LjU3MzgzNV0g
MmM4YjcgaXMgMmJiMDAwMDAhDQpbICAyMDguNTc2MTgwXSAyYzhiOCBpcyAyYmFmZjAwMCEN
ClsgIDIwOC41Nzg1NTVdIDJjOGI5IGlzIDJiYWZlMDAwIQ0KWyAgMjA4LjU4MDg4OV0gMmM4
YmEgaXMgMmJhZmQwMDAhDQpbICAyMDguNTgzMjM2XSAyYzhiYiBpcyAyYmFmYzAwMCENClsg
IDIwOC41ODYxMDFdIDJjOGJjIGlzIDJiYWYxMDAwIQ0KWyAgMjA4LjU4ODA3OV0gMmM4YmQg
aXMgMmJhZjIwMDAhDQpbICAyMDguNTg5OTY2XSAyYzhiZSBpcyAyYmFmMzAwMCENClsgIDIw
OC41OTE4ODBdIDJjOGJmIGlzIDJiYWY0MDAwIQ0KWyAgMjA4LjU5MzgzMl0gMmM4YzAgaXMg
MmJhZjUwMDAhDQpbICAyMDguNTk1NzI4XSAyYzhjMSBpcyAyYmFmNjAwMCENClsgIDIwOC41
OTc2MjRdIDJjOGMyIGlzIDJiYWY3MDAwIQ0KWyAgMjA4LjU5OTUwMV0gMmM4YzMgaXMgMmJh
ZjgwMDAhDQpbICAyMDguNjAxMzY4XSAyYzhjNCBpcyAyYmFmOTAwMCENClsgIDIwOC42MDMy
MzFdIDJjOGM1IGlzIDJiYWZhMDAwIQ0KWyAgMjA4LjYwNTEwMF0gMmM4YzYgaXMgMmJhZmIw
MDAhDQpbICAyMDguNjA2OTY5XSAyYzhjNyBpcyAyYmFmMDAwMCENClsgIDIwOC42MTA0NDRd
IDJjOGRmIGlzIDJiYWQwMDAwIQ0KWyAgMjA4LjYxMjM0MV0gMmM4ZTAgaXMgMmJhZDEwMDAh
DQpbICAyMDguNjE0MjAxXSAyYzhlMSBpcyAyYmFkMjAwMCENClsgIDIwOC42MTYwNjldIDJj
OGUyIGlzIDJiYWQzMDAwIQ0KWyAgMjA4LjYxNzkwM10gMmM4ZTMgaXMgMmJhZDQwMDAhDQpb
ICAyMDguNjE5NzA2XSAyYzhlNCBpcyAyYmFkNTAwMCENClsgIDIwOC42MjE0NzRdIDJjOGU1
IGlzIDJiYWQ2MDAwIQ0KWyAgMjA4LjYyMzIyMF0gMmM4ZTYgaXMgMmJhZDcwMDAhDQpbICAy
MDguNjI0OTcwXSAyYzhlNyBpcyAyYmFkODAwMCENClsgIDIwOC42MjY2ODddIDJjOGU4IGlz
IDJiYWQ5MDAwIQ0KWyAgMjA4LjYyODQyMF0gMmM4YzggaXMgMmJhZTUwMDAhDQpbICAyMDgu
NjMwMTUzXSAyYzhjOSBpcyAyYmFlNjAwMCENClsgIDIwOC42MzE4NTBdIDJjOGNhIGlzIDJi
YWU3MDAwIQ0KWyAgMjA4LjYzMzU1Ml0gMmM4Y2IgaXMgMmJhZTgwMDAhDQpbICAyMDguNjM1
MjEzXSAyYzhjYyBpcyAyYmFlOTAwMCENClsgIDIwOC42MzY4OTNdIDJjOGNkIGlzIDJiYWVh
MDAwIQ0KWyAgMjA4LjYzODUyNV0gMmM4Y2UgaXMgMmJhZWIwMDAhDQpbICAyMDguNjQwMTcx
XSAyYzhjZiBpcyAyYmFlYzAwMCENClsgIDIwOC42NDE4MjBdIDJjOGQwIGlzIDJiYWVkMDAw
IQ0KWyAgMjA4LjY0MzQ3Ml0gMmM4ZDEgaXMgMmJhZWUwMDAhDQpbICAyMDguNjQ1MTI2XSAy
YzhkMiBpcyAyYmFlZjAwMCENClsgIDIwOC42NDY3NzddIDJjOGQzIGlzIDJiYWRhMDAwIQ0K
WyAgMjA4LjY0ODQyMF0gMmM4ZDQgaXMgMmJhZGIwMDAhDQpbICAyMDguNjUwMDg5XSAyYzhk
NSBpcyAyYmFkYzAwMCENClsgIDIwOC42NTE3MzNdIDJjOGQ2IGlzIDJiYWRkMDAwIQ0KWyAg
MjA4LjY1MzQwOF0gMmM4ZDcgaXMgMmJhZGUwMDAhDQpbICAyMDguNjU1MDU3XSAyYzhkOCBp
cyAyYmFkZjAwMCENClsgIDIwOC42NTY3MjFdIDJjOGQ5IGlzIDJiYWUwMDAwIQ0KWyAgMjA4
LjY1ODM4MF0gMmM4ZGEgaXMgMmJhZTEwMDAhDQpbICAyMDguNjYwMDIzXSAyYzhkYiBpcyAy
YmFlMjAwMCENClsgIDIwOC42NjE3MDNdIDJjOGRjIGlzIDJiYWUzMDAwIQ0KWyAgMjA4LjY2
MzM0OF0gMmM4ZGQgaXMgMmJhZTQwMDAhDQpbICAyMDguNjY1MzA0XSAyYzhmNiBpcyAyYmFi
OTAwMCENClsgIDIwOC42NjcwMTVdIDJjOGY3IGlzIDJiYWJhMDAwIQ0KWyAgMjA4LjY2ODY3
M10gMmM4ZjggaXMgMmJhYmIwMDAhDQpbICAyMDguNjcwMzc2XSAyYzhmOSBpcyAyYmFiYzAw
MCENClsgIDIwOC42NzIwNDFdIDJjOGZhIGlzIDJiYWJkMDAwIQ0KWyAgMjA4LjY3MzcyMl0g
MmM4ZmIgaXMgMmJhYmUwMDAhDQpbICAyMDguNjc1Mzg5XSAyYzhmYyBpcyAyYmFiZjAwMCEN
ClsgIDIwOC42NzcwNTRdIDJjOGZkIGlzIDJiYWMwMDAwIQ0KWyAgMjA4LjY3ODc0Nl0gMmM4
ZmUgaXMgMmJhYzEwMDAhDQpbICAyMDguNjgwNDI0XSAyYzhmZiBpcyAyYmFjMjAwMCENClsg
IDIwOC42ODIxMjRdIDJjOTAwIGlzIDJiYWMzMDAwIQ0KWyAgMjA4LjY4Mzc5NV0gMmM5MDEg
aXMgMmJhYjgwMDAhDQpbICAyMDguNjg1NDcwXSAyYzhkZSBpcyAyYmFiNzAwMCENClsgIDIw
OC42ODcxOTVdIDJjOGU5IGlzIDJiYWM0MDAwIQ0KWyAgMjA4LjY4ODkxMl0gMmM4ZWEgaXMg
MmJhYzUwMDAhDQpbICAyMDguNjkwNjM3XSAyYzhlYiBpcyAyYmFjNjAwMCENClsgIDIwOC42
OTIzMzldIDJjOGVjIGlzIDJiYWM3MDAwIQ0KWyAgMjA4LjY5NDA0M10gMmM4ZWQgaXMgMmJh
YzgwMDAhDQpbICAyMDguNjk1NzQ1XSAyYzhlZSBpcyAyYmFjOTAwMCENClsgIDIwOC42OTc0
NDFdIDJjOGVmIGlzIDJiYWNhMDAwIQ0KWyAgMjA4LjY5OTEyOV0gMmM4ZjAgaXMgMmJhY2Iw
MDAhDQpbICAyMDguNzAwODE2XSAyYzhmMSBpcyAyYmFjYzAwMCENClsgIDIwOC43MDI1MDFd
IDJjOGY0IGlzIDJiYWNkMDAwIQ0KWyAgMjA4LjcwNDIwOV0gMmM4ZjUgaXMgMmJhY2UwMDAh
DQpbICAyMDguNzM0MzY3XSAyYzkwMiBpcyAyYmFiMzAwMCENClsgIDIwOC43MzYwNzddIDJj
OTAzIGlzIDJiYWI0MDAwIQ0KWyAgMjA4LjczNzgwNF0gMmM5MDQgaXMgMmJhYjUwMDAhDQpb
ICAyMDguNzM5NDg1XSAyYzkwNSBpcyAyYmFiNjAwMCENClsgIDIwOC43NDIwNDNdIDJjOTEz
IGlzIDJiYWFhMDAwIQ0KWyAgMjA4Ljc0MzgzNV0gMmM4NmUgaXMgMmJhYWIwMDAhDQpbICAy
MDguNzQ1NTYyXSAyYzg2ZiBpcyAyYmFhYzAwMCENClsgIDIwOC43NDczMDJdIDJjODcwIGlz
IDJiYWFkMDAwIQ0KWyAgMjA4Ljc0OTAyNV0gMmM4NzEgaXMgMmJhYWUwMDAhDQpbICAyMDgu
NzUwNzQ5XSAyYzg3MiBpcyAyYmFhZjAwMCENClsgIDIwOC43NTI0NThdIDJjODczIGlzIDJi
YWIwMDAwIQ0KWyAgMjA4Ljc1NDIxMF0gMmM4NzQgaXMgMmJhYjEwMDAhDQpbICAyMDguNzU1
OTI3XSAyYzg3NSBpcyAyYmFiMjAwMCENClsgIDIwOC43NzM1MjFdIDJjOTE0IGlzIDJiYWE5
MDAwIQ0KWyAgMjA4Ljc3OTc1OV0gMmM5MTUgaXMgMmJhYTgwMDAhDQpbICAyMDguNzgxOTE1
XSAyYzkwNiBpcyAyYmFhNzAwMCENClsgIDIwOC43ODQ3MDJdIDJjOTA3IGlzIDJiYWE2MDAw
IQ0KWyAgMjA4Ljc4Njg5MF0gMmM5MDggaXMgMmJhYTUwMDAhDQpbICAyMDguODA1NDIzXSAy
YzkwOSBpcyAyYmFhNDAwMCENClsgIDIwOC44MTY1NDhdIDJjOTE2IGlzIDJiYWEzMDAwIQ0K
WyAgMjA4LjgxODcyOF0gMmM5MGEgaXMgMmJhYTIwMDAhDQpbICAyMDguODI3NTk1XSAyYzkw
YiBpcyAyYmFhMTAwMCENClsgIDIwOC44NDUwMzhdIDJjOTBjIGlzIDJiYWEwMDAwIQ0KWyAg
MjA4Ljg1NDE4OV0gMmM5MGQgaXMgMmJhOWYwMDAhDQpbICAyMDguODU2NTI1XSAyYzkxNyBp
cyAyYmE5ZTAwMCENClsgIDIwOC44NjgyMzNdIDJjOTE4IGlzIDJiYTlkMDAwIQ0KWyAgMjA4
Ljg4MjY5M10gMmM5MGUgaXMgMmJhOWMwMDAhDQpbICAyMDguODg0OTAyXSAyYzkwZiBpcyAy
YmE5YjAwMCENClsgIDIwOC44OTg5NjJdIDJjOTEwIGlzIDJiYTlhMDAwIQ0KWyAgMjA4Ljkw
MTE2OF0gMmM5MTkgaXMgMmJhOTkwMDAhDQpbICAyMDguOTAzNzg0XSAyYzkxMSBpcyAyYmE5
NzAwMCENClsgIDIwOC45MTgyNTVdIDJjOTEyIGlzIDJiYTk2MDAwIQ0KWyAgMjA4LjkyMDQ3
M10gMmM5MzIgaXMgMmJhOTUwMDAhDQpbICAyMDguOTIyNjgwXSAyYzkzMyBpcyAyYmE5NDAw
MCENClsgIDIwOC45MzAwMDhdIDJjOTM0IGlzIDJiYTkzMDAwIQ0KWyAgMjA4LjkzMjIzN10g
MmM5MzUgaXMgMmJhOTIwMDAhDQpbICAyMDguOTM0NDE4XSAyYzkzNiBpcyAyYmE5MTAwMCEN
ClsgIDIwOC45MzY2MDFdIDJjOTM3IGlzIDJiYTkwMDAwIQ0KWyAgMjA4LjkzODgwM10gMmM5
MzggaXMgMmJhOGYwMDAhDQpbICAyMDguOTQxMDA0XSAyYzkzOSBpcyAyYmE4ZTAwMCENClsg
IDIwOC45NDMxODVdIDJjOTNhIGlzIDJiYThkMDAwIQ0KWyAgMjA4Ljk0NzQyNl0gMmM5M2Ig
aXMgMmJhOGMwMDAhDQpbICAyMDguOTQ5NjE4XSAyYzkzYyBpcyAyYmE4YjAwMCENClsgIDIw
OC45NTE4MTFdIDJjOTNkIGlzIDJiYThhMDAwIQ0KWyAgMjA4Ljk1Mzk5OF0gMmM5M2UgaXMg
MmJhODkwMDAhDQpbICAyMDguOTU2MTUxXSAyYzkzZiBpcyAyYmE4ODAwMCENClsgIDIwOC45
NTgzNDRdIDJjOTQwIGlzIDJiYTg3MDAwIQ0KWyAgMjA4Ljk2MDUxOF0gMmM5NDEgaXMgMmJh
ODYwMDAhDQpbICAyMDguOTYyNjc0XSAyYzk0MiBpcyAyYmE4NTAwMCENClsgIDIwOC45NjQ4
NTBdIDJjOTQzIGlzIDJiYTg0MDAwIQ0KWyAgMjA4Ljk2NzAxM10gMmM5NDQgaXMgMmJhODMw
MDAhDQpbICAyMDguOTY5MTQ2XSAyYzk0NSBpcyAyYmE4MjAwMCENClsgIDIwOC45NzEyODld
IDJjOTQ2IGlzIDJiYTgxMDAwIQ0KWyAgMjA4Ljk3MzQ0NF0gMmM5MWEgaXMgMmJhODAwMDAh
DQpbICAyMDguOTc1NTUyXSAyYzk0NyBpcyAyYmE3ZjAwMCENClsgIDIwOC45Nzc3MzVdIDJj
OTQ4IGlzIDJiYTdlMDAwIQ0KWyAgMjA4Ljk4MzI1OF0gMmM5NDkgaXMgMmJhN2EwMDAhDQpb
ICAyMDguOTg1MDAyXSAyYzk0YSBpcyAyYmE3YjAwMCENClsgIDIwOC45ODY3MjRdIDJjOTRi
IGlzIDJiYTdjMDAwIQ0KWyAgMjA4Ljk4ODQxMF0gMmM5NGMgaXMgMmJhN2QwMDAhDQpbICAy
MDguOTkwNDY1XSAyYzkxYiBpcyAyYmE3OTAwMCENClsgIDIwOC45OTI1ODldIDJjOTFjIGlz
IDJiYTc4MDAwIQ0KWyAgMjA4Ljk5NDY3MF0gMmM5NGQgaXMgMmJhNzcwMDAhDQpbICAyMDku
MDA1NzAwXSAyYzkxZCBpcyAyYmE3MzAwMCENClsgIDIwOS4wMDc0NjFdIDJjOTRlIGlzIDJi
YTc0MDAwIQ0KWyAgMjA5LjAwOTE2Nl0gMmM5NGYgaXMgMmJhNzUwMDAhDQpbICAyMDkuMDEw
ODk1XSAyYzk1MCBpcyAyYmE3NjAwMCENClsgIDIwOS4wMjcxMTJdIDJjOTUxIGlzIDJiYTY4
MDAwIQ0KWyAgMjA5LjAyODkwMF0gMmM5NTIgaXMgMmJhNjkwMDAhDQpbICAyMDkuMDMwNjM1
XSAyYzk1MyBpcyAyYmE2YTAwMCENClsgIDIwOS4wMzIzNjddIDJjOTU0IGlzIDJiYTZiMDAw
IQ0KWyAgMjA5LjAzNDEwNl0gMmM5NTUgaXMgMmJhNmMwMDAhDQpbICAyMDkuMDM1ODM2XSAy
Yzk1NiBpcyAyYmE2ZDAwMCENClsgIDIwOS4wMzc1NjddIDJjOTU3IGlzIDJiYTZlMDAwIQ0K
WyAgMjA5LjAzOTI3N10gMmM5NTggaXMgMmJhNmYwMDAhDQpbICAyMDkuMDQxMDE3XSAyYzk1
OSBpcyAyYmE3MDAwMCENClsgIDIwOS4wNDI3MjhdIDJjOTVhIGlzIDJiYTcxMDAwIQ0KWyAg
MjA5LjA0NDQ3NF0gMmM5NWIgaXMgMmJhNzIwMDAhDQpbICAyMDkuMDQ2NDM0XSAyYzk2MyBp
cyAyYmE1YzAwMCENClsgIDIwOS4wNDgxODRdIDJjOTY0IGlzIDJiYTVkMDAwIQ0KWyAgMjA5
LjA0OTg4OF0gMmM5NjUgaXMgMmJhNWUwMDAhDQpbICAyMDkuMDUxNTk3XSAyYzk2NiBpcyAy
YmE1ZjAwMCENClsgIDIwOS4wNTMzMTVdIDJjOTY3IGlzIDJiYTYwMDAwIQ0KWyAgMjA5LjA1
NTA1M10gMmM5NjggaXMgMmJhNjEwMDAhDQpbICAyMDkuMDU2Nzg5XSAyYzk1ZSBpcyAyYmE2
MzAwMCENClsgIDIwOS4wNTg1MDldIDJjOTVmIGlzIDJiYTY0MDAwIQ0KWyAgMjA5LjA2MDIx
MV0gMmM5NjAgaXMgMmJhNjUwMDAhDQpbICAyMDkuMDYxOTIzXSAyYzk2MSBpcyAyYmE2NjAw
MCENClsgIDIwOS4wNjM2MjJdIDJjOTYyIGlzIDJiYTY3MDAwIQ0KWyAgMjA5LjA2NTQzM10g
MmM5NWQgaXMgMmJhNWIwMDAhDQpbICAyMDkuMDc1MTE3XSAyYzk2OSBpcyAyYmE1YTAwMCEN
ClsgIDIwOS4wNzc0MDhdIDJjOTZhIGlzIDJiYTU2MDAwIQ0KWyAgMjA5LjA3OTExMV0gMmM5
MWUgaXMgMmJhNTcwMDAhDQpbICAyMDkuMDgwODM5XSAyYzkxZiBpcyAyYmE1ODAwMCENClsg
IDIwOS4wODI1NjZdIDJjOTIwIGlzIDJiYTU5MDAwIQ0KWyAgMjA5LjA4NTAzM10gMmM5MjIg
aXMgMmJhNGUwMDAhDQpbICAyMDkuMDg2ODU5XSAyYzkyMyBpcyAyYmE0ZjAwMCENClsgIDIw
OS4wODg1NzJdIDJjOTI0IGlzIDJiYTUwMDAwIQ0KWyAgMjA5LjA5MDMwOF0gMmM5MjUgaXMg
MmJhNTEwMDAhDQpbICAyMDkuMDkxOTkwXSAyYzkyNiBpcyAyYmE1MjAwMCENClsgIDIwOS4w
OTM3NDhdIDJjOTI3IGlzIDJiYTUzMDAwIQ0KWyAgMjA5LjA5NTQ0MF0gMmM5MjggaXMgMmJh
NTQwMDAhDQpbICAyMDkuMDk3MTMwXSAyYzkyOSBpcyAyYmE1NTAwMCENClsgIDIwOS4wOTg5
NzldIDJjOTczIGlzIDJiYTNlMDAwIQ0KWyAgMjA5LjEwMDY5NF0gMmM5NzQgaXMgMmJhM2Yw
MDAhDQpbICAyMDkuMTAyNDAyXSAyYzk3NSBpcyAyYmE0MDAwMCENClsgIDIwOS4xMDQxMjdd
IDJjOTc2IGlzIDJiYTQxMDAwIQ0KWyAgMjA5LjEwNTgyNl0gMmM5NzcgaXMgMmJhNDIwMDAh
DQpbICAyMDkuMTA3NTUyXSAyYzkyYSBpcyAyYmE0MzAwMCENClsgIDIwOS4xMDkyNTJdIDJj
OTJiIGlzIDJiYTQ0MDAwIQ0KWyAgMjA5LjExMDk3NF0gMmM5MmMgaXMgMmJhNDUwMDAhDQpb
ICAyMDkuMTEyNjczXSAyYzkyZCBpcyAyYmE0NjAwMCENClsgIDIwOS4xMTQzOTFdIDJjOTJl
IGlzIDJiYTQ3MDAwIQ0KWyAgMjA5LjExNjEwMF0gMmM5MmYgaXMgMmJhNDgwMDAhDQpbICAy
MDkuMTE3ODA2XSAyYzkzMCBpcyAyYmE0OTAwMCENClsgIDIwOS4xMTk1MDldIDJjOTMxIGlz
IDJiYTRhMDAwIQ0KWyAgMjA5LjEyMTIwM10gMmM5NzAgaXMgMmJhNGIwMDAhDQpbICAyMDku
MTIyODkwXSAyYzk3MSBpcyAyYmE0YzAwMCENClsgIDIwOS4xMjQ2MDFdIDJjOTcyIGlzIDJi
YTRkMDAwIQ0KWyAgMjA5LjEyNjY2MF0gMmM5NzggaXMgMmJhM2QwMDAhDQpbICAyMDkuMTI4
OTQ5XSAyYzk3OSBpcyAyYmEzOTAwMCENClsgIDIwOS4xMzA2OTZdIDJjOTIxIGlzIDJiYTNh
MDAwIQ0KWyAgMjA5LjEzMjQwMV0gMmM5NmIgaXMgMmJhM2IwMDAhDQpbICAyMDkuMTM0MTEy
XSAyYzk2YyBpcyAyYmEzYzAwMCENClsgIDIwOS4xNjg5OTddIDJjOTZkIGlzIDJiYTJlMDAw
IQ0KWyAgMjA5LjE3MDc2MV0gMmM5NmUgaXMgMmJhMmYwMDAhDQpbICAyMDkuMTcyNDQ3XSAy
Yzk2ZiBpcyAyYmEzMDAwMCENClsgIDIwOS4xNzQxNjFdIDJjOThmIGlzIDJiYTMxMDAwIQ0K
WyAgMjA5LjE3NTgzN10gMmM5OTAgaXMgMmJhMzIwMDAhDQpbICAyMDkuMTc3NTQ5XSAyYzk5
MSBpcyAyYmEzMzAwMCENClsgIDIwOS4xNzkyNjVdIDJjOTkyIGlzIDJiYTM0MDAwIQ0KWyAg
MjA5LjE4MDk2MV0gMmM5OTMgaXMgMmJhMzUwMDAhDQpbICAyMDkuMTgyNjQ4XSAyYzk5NCBp
cyAyYmEzNjAwMCENClsgIDIwOS4xODQzNDhdIDJjOTk1IGlzIDJiYTM3MDAwIQ0KWyAgMjA5
LjE4NjAzNF0gMmM5OTYgaXMgMmJhMzgwMDAhDQpbICAyMDkuMTg3OTQxXSAyYzlhMiBpcyAy
YmEyMTAwMCENClsgIDIwOS4xODk2MzFdIDJjOWEzIGlzIDJiYTIyMDAwIQ0KWyAgMjA5LjE5
MTMyOF0gMmM5OTggaXMgMmJhMjQwMDAhDQpbICAyMDkuMTkyOTk2XSAyYzk5OSBpcyAyYmEy
NTAwMCENClsgIDIwOS4xOTQ3MDZdIDJjOTlhIGlzIDJiYTI2MDAwIQ0KWyAgMjA5LjE5NjM2
N10gMmM5OWIgaXMgMmJhMjcwMDAhDQpbICAyMDkuMTk4MDYzXSAyYzk5YyBpcyAyYmEyODAw
MCENClsgIDIwOS4xOTk3MzNdIDJjOTlkIGlzIDJiYTI5MDAwIQ0KWyAgMjA5LjIwMTQwNF0g
MmM5OWUgaXMgMmJhMmEwMDAhDQpbICAyMDkuMjAzMDkzXSAyYzk5ZiBpcyAyYmEyYjAwMCEN
ClsgIDIwOS4yMDQ3NzddIDJjOWEwIGlzIDJiYTJjMDAwIQ0KWyAgMjA5LjIwNjQ3MF0gMmM5
YTEgaXMgMmJhMmQwMDAhDQpbICAyMDkuMjA4MjY2XSAyYzk5NyBpcyAyYmEyMDAwMCENClsg
IDIwOS4yMTA2MDRdIDJjOWE0IGlzIDJiYTFjMDAwIQ0KWyAgMjA5LjIxMjMxNl0gMmM5YTUg
aXMgMmJhMWQwMDAhDQpbICAyMDkuMjE0MDQzXSAyYzlhNiBpcyAyYmExZTAwMCENClsgIDIw
OS4yMTU3NzBdIDJjOWE3IGlzIDJiYTFmMDAwIQ0KWyAgMjA5LjIyNDMwOV0gMmM5N2EgaXMg
MmJhMTQwMDAhDQpbICAyMDkuMjI2MDM3XSAyYzk3YiBpcyAyYmExNTAwMCENClsgIDIwOS4y
Mjc3OTldIDJjOTdjIGlzIDJiYTE2MDAwIQ0KWyAgMjA5LjIyOTU1Ml0gMmM5N2QgaXMgMmJh
MTcwMDAhDQpbICAyMDkuMjMxMzM4XSAyYzk3ZSBpcyAyYmExODAwMCENClsgIDIwOS4yMzMw
MTldIDJjOTdmIGlzIDJiYTE5MDAwIQ0KWyAgMjA5LjIzNDcxMF0gMmM5ODAgaXMgMmJhMWEw
MDAhDQpbICAyMDkuMjM2Mzk2XSAyYzk4MSBpcyAyYmExYjAwMCENClsgIDIwOS4yNDEwODNd
IDJjOThjIGlzIDJiOWY5MDAwIQ0KWyAgMjA5LjI0Mjg1MV0gMmM5OGIgaXMgMmI5ZmEwMDAh
DQpbICAyMDkuMjQ0NTgzXSAyYzk4YSBpcyAyYjlmYjAwMCENClsgIDIwOS4yNDYyNjVdIDJj
OTg5IGlzIDJiOWZjMDAwIQ0KWyAgMjA5LjI0Nzk4MV0gMmM5ODggaXMgMmI5ZmQwMDAhDQpb
ICAyMDkuMjQ5NzI2XSAyYzk4NyBpcyAyYjlmZTAwMCENClsgIDIwOS4yNTE0MzNdIDJjOTg2
IGlzIDJiOWZmMDAwIQ0KWyAgMjA5LjI1MzEzM10gMmM5ODUgaXMgMmJhMDAwMDAhDQpbICAy
MDkuMjU0ODM4XSAyYzk4NCBpcyAyYmEwMTAwMCENClsgIDIwOS4yNTY2MThdIDJjOTgzIGlz
IDJiYTAyMDAwWyAgMjExLjQwNjk0N10gMmM0MjcgaXMgMmJmMmUwMDAhDQpbICAyMTEuNDA4
NjYyXSAyYzQyOCBpcyAyYmYzMDAwMCENClsgIDIxMS40MTAzNTldIDJjNDI5IGlzIDJiZjJm
MDAwIQ0KWyAgMjExLjQxMjA5MF0gMmM0MmEgaXMgMmJmMTgwMDAhDQpbICAyMTEuNDEzNzkz
XSAyYzQyYiBpcyAyYmYxMTAwMCENClsgIDIxMS40MTU0ODRdIDJjNDJjIGlzIDJiZjEwMDAw
IQ0KWyAgMjExLjQxNzE3Ml0gMmM0MmQgaXMgMmJmMGYwMDAhDQpbICAyMTEuNDE4ODUzXSAy
YzQyZSBpcyAyYmYwZTAwMCENClsgIDIxMS40MjA1NjVdIDJjNDJmIGlzIDJiZjBkMDAwIQ0K
WyAgMjExLjQyMjI1Ml0gMmM0MzAgaXMgMmJmMGMwMDAhDQpbICAyMTEuNDIzOTgwXSAyYzQz
MSBpcyAyYmYwYjAwMCENClsgIDIxMS40MjU4MjldIDJjNDNkIGlzIDJiZjFjMDAwIQ0KWyAg
MjExLjQyNzU2MF0gMmM0M2UgaXMgMmJmMzIwMDAhDQpbICAyMTEuNDI5Mzk5XSAyYzQzMiBp
cyAyYmYxZDAwMCENClsgIDIxMS40MzExMjddIDJjNDMzIGlzIDJiZjEyMDAwIQ0KWyAgMjEx
LjQzMjg0NF0gMmM0MzQgaXMgMmJmMmMwMDAhDQpbICAyMTEuNDM0NTYxXSAyYzQzNSBpcyAy
YmYxZTAwMCENClsgIDIxMS40MzYyODNdIDJjNDM2IGlzIDJiZjFiMDAwIQ0KWyAgMjExLjQz
ODAwNF0gMmM0MzcgaXMgMmJmMTcwMDAhDQpbICAyMTEuNDM5NzExXSAyYzQzOCBpcyAyYmYx
ZjAwMCENClsgIDIxMS40NDE0NTBdIDJjNDM5IGlzIDJiZjIxMDAwIQ0KWyAgMjExLjQ0MzE2
M10gMmM0M2EgaXMgMmJmMjIwMDAhDQpbICAyMTEuNDQ0OTQ0XSAyYzQzYiBpcyAyYmYyNzAw
MCENClsgIDIxMS40NDY2NjNdIDJjNDNjIGlzIDJiZjJkMDAwIQ0KWyAgMjExLjQ0OTUzNF0g
MmM0ODEgaXMgMmJlZWEwMDAhDQpbICAyMTEuNDUxMzA5XSAyYzQ4MiBpcyAyYmVlYjAwMCEN
ClsgIDIxMS40NTMxMjddIDJjNDgzIGlzIDJiZWVjMDAwIQ0KWyAgMjExLjQ1NDg5Ml0gMmM0
ODQgaXMgMmJlZWQwMDAhDQpbICAyMTEuNDU2Njc4XSAyYzQ4NSBpcyAyYmVlZTAwMCENClsg
IDIxMS40NTg0NTddIDJjNDg2IGlzIDJiZWVmMDAwIQ0KWyAgMjExLjQ2MDIyMl0gMmM0ODcg
aXMgMmJlZjAwMDAhDQpbICAyMTEuNDYxOTkyXSAyYzQ4OCBpcyAyYmVmMTAwMCENClsgIDIx
MS40NjM3NzVdIDJjNDg5IGlzIDJiZWYyMDAwIQ0KWyAgMjExLjQ2NTUxN10gMmM0OGEgaXMg
MmJlZjMwMDAhDQpbICAyMTEuNDY3MjQ0XSAyYzQ4YiBpcyAyYmVmNDAwMCENClsgIDIxMS40
Njg5NTJdIDJjNDhjIGlzIDJiZWRmMDAwIQ0KWyAgMjExLjQ3MDcwNV0gMmM0OGQgaXMgMmJl
ZTAwMDAhDQpbICAyMTEuNDcyNDM1XSAyYzQ4ZSBpcyAyYmVlMTAwMCENClsgIDIxMS40NzQx
ODRdIDJjNDhmIGlzIDJiZWUyMDAwIQ0KWyAgMjExLjQ3NTkwM10gMmM0OTAgaXMgMmJlZTMw
MDAhDQpbICAyMTEuNDc3NjU0XSAyYzQ5MSBpcyAyYmVlNDAwMCENClsgIDIxMS40NzkzNjdd
IDJjNDkyIGlzIDJiZWU1MDAwIQ0KWyAgMjExLjQ4MTA5NF0gMmM0OTMgaXMgMmJlZTYwMDAh
DQpbICAyMTEuNDgyODIzXSAyYzQ5NCBpcyAyYmVlNzAwMCENClsgIDIxMS40ODQ1NDRdIDJj
NDk1IGlzIDJiZWU4MDAwIQ0KWyAgMjExLjQ4NjI2MV0gMmM0OTYgaXMgMmJlZTkwMDAhDQpb
ICAyMTEuNDg3OTcxXSAyYzQ5NyBpcyAyYmVkNjAwMCENClsgIDIxMS40ODk2NjJdIDJjNDk4
IGlzIDJiZWQ3MDAwIQ0KWyAgMjExLjQ5MTM3N10gMmM0OTkgaXMgMmJlZDgwMDAhDQpbICAy
MTEuNDkzMDY3XSAyYzQ5YSBpcyAyYmVkOTAwMCENClsgIDIxMS40OTQ3ODFdIDJjNDliIGlz
IDJiZWRhMDAwIQ0KWyAgMjExLjQ5NjQ2NV0gMmM0OWUgaXMgMmJlZGIwMDAhDQpbICAyMTEu
NDk4MTUxXSAyYzQ5ZiBpcyAyYmVkYzAwMCENClsgIDIxMS40OTk4NDBdIDJjNGEwIGlzIDJi
ZWRkMDAwIQ0KWyAgMjExLjUwMTUzM10gMmM0YTEgaXMgMmJlZGUwMDAhDQpbICAyMTEuNTAz
NjA4XSAyYzQ2YiBpcyAyYmYwMDAwMCENClsgIDIxMS41MDUzMTJdIDJjNDZjIGlzIDJiZjAx
MDAwIQ0KWyAgMjExLjUwNzAzOV0gMmM0NmQgaXMgMmJmMDIwMDAhDQpbICAyMTEuNTA4NzM3
XSAyYzQ2ZSBpcyAyYmYwMzAwMCENClsgIDIxMS41MTA0NjVdIDJjNDZmIGlzIDJiZjA0MDAw
IQ0KWyAgMjExLjUxMjE3N10gMmM0NzAgaXMgMmJmMjMwMDAhDQpbICAyMTEuNTEzODk1XSAy
YzQ3MSBpcyAyYmYyNDAwMCENClsgIDIxMS41MTU2MDhdIDJjNDcyIGlzIDJiZjI1MDAwIQ0K
WyAgMjExLjUxNzMyMV0gMmM0NzMgaXMgMmJmMjYwMDAhDQpbICAyMTEuNTE5MDIzXSAyYzQ3
NCBpcyAyYmZlNTAwMCENClsgIDIxMS41MjA3NjddIDJjNDc1IGlzIDJiZmU2MDAwIQ0KWyAg
MjExLjUyMjQ3NV0gMmM0NzYgaXMgMmJlZjUwMDAhDQpbICAyMTEuNTI0MjE0XSAyYzQ3NyBp
cyAyYmVmNjAwMCENClsgIDIxMS41MjU5MTZdIDJjNDc4IGlzIDJiZWY3MDAwIQ0KWyAgMjEx
LjUyNzY0M10gMmM0NzkgaXMgMmJlZjgwMDAhDQpbICAyMTEuNTI5MzYyXSAyYzQ3YSBpcyAy
YmVmOTAwMCENClsgIDIxMS41MzEwNjBdIDJjNDdiIGlzIDJiZWZhMDAwIQ0KWyAgMjExLjUz
Mjc2MF0gMmM0N2MgaXMgMmJlZmIwMDAhDQpbICAyMTEuNTM0NDQ4XSAyYzQ3ZCBpcyAyYmVm
YzAwMCENClsgIDIxMS41MzYxMjldIDJjNDdlIGlzIDJiZWZkMDAwIQ0KWyAgMjExLjUzNzgx
Ml0gMmM0N2YgaXMgMmJlZmUwMDAhDQpbICAyMTEuNTM5NDc5XSAyYzQ4MCBpcyAyYmVmZjAw
MCENClsgIDIxMS41NDExODNdIDJjNDYwIGlzIDJiOTk3MDAwIQ0KWyAgMjExLjU0Mjg3Ml0g
MmM0NjEgaXMgMmJmMTYwMDAhDQpbICAyMTEuNTQ0NjA1XSAyYzQ2MiBpcyAyYjFkZDAwMCEN
ClsgIDIxMS41NDYzMTRdIDJjNDYzIGlzIDJiZmU0MDAwIQ0KWyAgMjExLjU0ODA1M10gMmM0
NjQgaXMgMmJjYjUwMDAhDQpbICAyMTEuNTQ5ODA3XSAyYzQ2NSBpcyAyYmYyOTAwMCENClsg
IDIxMS41NTE1NzBdIDJjNDY2IGlzIDJiZjI4MDAwIQ0KWyAgMjExLjU1MzMzOV0gMmM0Njcg
aXMgMmJmZjAwMDAhDQpbICAyMTEuNTU1MTA2XSAyYzQ2OCBpcyAyYmYxYTAwMCENClsgIDIx
MS41NTY4ODRdIDJjNDY5IGlzIDJiZjE5MDAwIQ0KWyAgMjExLjU1ODYxNF0gMmM0NmEgaXMg
MmJmMzEwMDAhDQpbICAyMTEuNTYwNzQ0XSAyYzRhMiBpcyAyYmVkNTAwMCENClsgIDIxMS41
NzIzNzVdIDJjNGEzIGlzIDJiZWQ0MDAwIQ0KWyAgMjExLjU4NTEwOF0gMmM0YTQgaXMgMmJl
ZDMwMDAhDQpbICAyMTEuNTg3MzU5XSAyYzRhNSBpcyAyYmVkMjAwMCENClsgIDIxMS41ODk1
NjFdIDJjNDVmIGlzIDJiZWQxMDAwIQ0KWyAgMjExLjU5MTc2Ml0gMmM0NWUgaXMgMmJlZDAw
MDAhDQpbICAyMTEuNTk0MDIwXSAyYzQ1MSBpcyAyYmVjZjAwMCENClsgIDIxMS41OTYyMjVd
IDJjNDUyIGlzIDJiZWNlMDAwIQ0KWyAgMjExLjU5ODQxMl0gMmM0NTMgaXMgMmJlY2QwMDAh
DQpbICAyMTEuNjAwNjM4XSAyYzRhNiBpcyAyYmVjYzAwMCENClsgIDIxMS42MDI4NDNdIDJj
NDU0IGlzIDJiZWNiMDAwIQ0KWyAgMjExLjYwNTA4OV0gMmM0NTUgaXMgMmJlY2EwMDAhDQpb
ICAyMTEuNjU1ODAwXSAyYzRjMCBpcyAyYmViZTAwMCENClsgIDIxMS42NTc3MDNdIDJjNDU2
IGlzIDJiZWJmMDAwIQ0KWyAgMjExLjY1OTQ4NF0gMmM0NTcgaXMgMmJlYzAwMDAhDQpbICAy
MTEuNjYxMzEzXSAyYzQ1OCBpcyAyYmVjMTAwMCENClsgIDIxMS42NjMxMTVdIDJjNDU5IGlz
IDJiZWMyMDAwIQ0KWyAgMjExLjY2NDk0NV0gMmM0NWEgaXMgMmJlYzMwMDAhDQpbICAyMTEu
NjY2NzU1XSAyYzQ1YiBpcyAyYmVjNDAwMCENClsgIDIxMS42Njg1NDBdIDJjNDVjIGlzIDJi
ZWM1MDAwIQ0KWyAgMjExLjY3MDM1Nl0gMmM0NWQgaXMgMmJlYzYwMDAhDQpbICAyMTEuNjcy
MTI1XSAyYzRiZCBpcyAyYmVjNzAwMCENClsgIDIxMS42NzM5MTZdIDJjNGJlIGlzIDJiZWM4
MDAwIQ0KWyAgMjExLjY3NTY2MV0gMmM0YmYgaXMgMmJlYzkwMDAhDQpbICAyMTEuNjc4Mjcy
XSAyYzRjMSBpcyAyYmViMzAwMCENClsgIDIxMS42ODAxODNdIDJjNGE3IGlzIDJiZWI0MDAw
IQ0KWyAgMjExLjY4MTkzN10gMmM0YTggaXMgMmJlYjUwMDAhDQpbICAyMTEuNjgzNjg1XSAy
YzRhOSBpcyAyYmViNjAwMCENClsgIDIxMS42ODU0MDddIDJjNGFhIGlzIDJiZWI3MDAwIQ0K
WyAgMjExLjY4NzE2M10gMmM0YWIgaXMgMmJlYjgwMDAhDQpbICAyMTEuNjg4ODg2XSAyYzRh
YyBpcyAyYmViOTAwMCENClsgIDIxMS42OTA2MjldIDJjNGFkIGlzIDJiZWJhMDAwIQ0KWyAg
MjExLjY5MjMzMV0gMmM0YWUgaXMgMmJlYmIwMDAhDQpbICAyMTEuNjk0MDU1XSAyYzRhZiBp
cyAyYmViYzAwMCENClsgIDIxMS42OTU3NDRdIDJjNGIwIGlzIDJiZWJkMDAwIQ0KWyAgMjEx
LjY5NzY0OF0gMmM0YjIgaXMgMmJlYTkwMDAhDQpbICAyMTEuNjk5MzkyXSAyYzRiMyBpcyAy
YmVhYTAwMCENClsgIDIxMS43MDExMDJdIDJjNGI0IGlzIDJiZWFiMDAwIQ0KWyAgMjExLjcw
MjgwOV0gMmM0YjUgaXMgMmJlYWMwMDAhDQpbICAyMTEuNzA0NTE2XSAyYzRiNiBpcyAyYmVh
ZDAwMCENClsgIDIxMS43MDYyMDZdIDJjNGI3IGlzIDJiZWFlMDAwIQ0KWyAgMjExLjcwNzkw
Ml0gMmM0YjggaXMgMmJlYWYwMDAhDQpbICAyMTEuNzA5NTU5XSAyYzRiOSBpcyAyYmViMDAw
MCENClsgIDIxMS43MTEyNTFdIDJjNGJhIGlzIDJiZWIxMDAwIQ0KWyAgMjExLjcxMjkwMV0g
MmM0YmIgaXMgMmJlYjIwMDAhDQpbICAyMTEuNzE0NTU4XSAyYzRiYyBpcyAyYmVhNjAwMCEN
ClsgIDIxMS43MTYyMTddIDJjNGRjIGlzIDJiZWE3MDAwIQ0KWyAgMjExLjcxNzk1OF0gMmM0
YjEgaXMgMmJlYTUwMDAhDQpbICAyMTEuNzIwMDg3XSAyYzRkZSBpcyAyYmVhNDAwMCENClsg
IDIxMS43MzAwMTNdIDJjNGRkIGlzIDJiZWEwMDAwIQ0KWyAgMjExLjczMTc1MV0gMmM0YzIg
aXMgMmJlYTEwMDAhDQpbICAyMTEuNzMzNDQ4XSAyYzRjMyBpcyAyYmVhMjAwMCENClsgIDIx
MS43MzUxMTVdIDJjNGM0IGlzIDJiZWEzMDAwIQ0KWyAgMjExLjc0NTQ4Nl0gMmM0ZGYgaXMg
MmJlOTgwMDAhDQpbICAyMTEuNzQ3MTk4XSAyYzRlMCBpcyAyYmU5OTAwMCENClsgIDIxMS43
NDg5MDddIDJjNGUxIGlzIDJiZTlhMDAwIQ0KWyAgMjExLjc1MDYwN10gMmM0ZTIgaXMgMmJl
OWIwMDAhDQpbICAyMTEuNzUyMjgxXSAyYzRlMyBpcyAyYmU5YzAwMCENClsgIDIxMS43NTM5
NTldIDJjNGU0IGlzIDJiZTlkMDAwIQ0KWyAgMjExLjc1NTYxN10gMmM0ZTUgaXMgMmJlOWUw
MDAhDQpbICAyMTEuNzU3MzExXSAyYzRlNiBpcyAyYmU5ZjAwMCENClsgIDIxMS43NTkzNDRd
IDJjNGU3IGlzIDJiZTk3MDAwIQ0KWyAgMjExLjc2MTQyN10gMmM0YzUgaXMgMmJlOTYwMDAh
DQpbICAyMTEuNzYzNTUzXSAyYzRlOCBpcyAyYmU5NTAwMCENClsgIDIxMS43NjU2NjhdIDJj
NGM2IGlzIDJiZTk0MDAwIQ0KWyAgMjExLjc2Nzc0Ml0gMmM0YzcgaXMgMmJlOTMwMDAhDQpb
ICAyMTEuODAwNjI3XSAyYzRlOSBpcyAyYmU4ODAwMCENClsgIDIxMS44MDIzNzRdIDJjNGM4
IGlzIDJiZTg5MDAwIQ0KWyAgMjExLjgwNDA4OF0gMmM0YzkgaXMgMmJlOGEwMDAhDQpbICAy
MTEuODA1NzY5XSAyYzRjYSBpcyAyYmU4YjAwMCENClsgIDIxMS44MDc0OTZdIDJjNGNiIGlz
IDJiZThjMDAwIQ0KWyAgMjExLjgwOTE4NV0gMmM0Y2MgaXMgMmJlOGQwMDAhDQpbICAyMTEu
ODEwOTEzXSAyYzRjZCBpcyAyYmU4ZTAwMCENClsgIDIxMS44MTI2MjBdIDJjNGNlIGlzIDJi
ZThmMDAwIQ0KWyAgMjExLjgxNDMzN10gMmM0Y2YgaXMgMmJlOTAwMDAhDQpbICAyMTEuODE2
MDU4XSAyYzRkMCBpcyAyYmU5MTAwMCENClsgIDIxMS44MTc3OTJdIDJjNGQxIGlzIDJiZTky
MDAwIQ0KWyAgMjExLjgxOTYzMV0gMmM0ZDIgaXMgMmJlODYwMDAhDQpbICAyMTEuODM5NzM2
XSAyYzRkMyBpcyAyYmU4NTAwMCENClsgIDIxMS44NTM1NDddIDJjNGVhIGlzIDJiZTg0MDAw
IQ0KWyAgMjExLjg1ODI4MV0gMmM0ZDUgaXMgMmJlODMwMDAhDQpbICAyMTEuODY1OTAxXSAy
YzRkNCBpcyAyYmU4MTAwMCENClsgIDIxMS44NzU2OTNdIDJjNGQ2IGlzIDJiZTdkMDAwIQ0K
WyAgMjExLjg3NzQ5NV0gMmM0ZDcgaXMgMmJlN2UwMDAhDQpbICAyMTEuODc5MjA2XSAyYzRk
OCBpcyAyYmU3ZjAwMCENClsgIDIxMS44ODA5MzBdIDJjNGQ5IGlzIDJiZTgwMDAwIQ0KWyAg
MjExLjkxMTA5OF0gMmM0ZGEgaXMgMmJlNzIwMDAhDQpbICAyMTEuOTEyODIzXSAyYzRkYiBp
cyAyYmU3MzAwMCENClsgIDIxMS45MTQ1ODhdIDJjNGZiIGlzIDJiZTc0MDAwIQ0KWyAgMjEx
LjkxNjMxNV0gMmM0ZmMgaXMgMmJlNzUwMDAhDQpbICAyMTEuOTE4MTc0XSAyYzRmZCBpcyAy
YmU3NjAwMCENClsgIDIxMS45MTk5MjBdIDJjNGZlIGlzIDJiZTc3MDAwIQ0KWyAgMjExLjky
MTY3NF0gMmM0ZmYgaXMgMmJlNzgwMDAhDQpbICAyMTEuOTIzNDYxXSAyYzUwMCBpcyAyYmU3
OTAwMCENClsgIDIxMS45MjUyMDZdIDJjNTAxIGlzIDJiZTdhMDAwIQ0KWyAgMjExLjkyNjk3
OF0gMmM1MDIgaXMgMmJlN2IwMDAhDQpbICAyMTEuOTI4NzE0XSAyYzUwMyBpcyAyYmU3YzAw
MCENClsgIDIxMS45NDAwNDldIDJjNTA0IGlzIDJiZTcwMDAwIQ0KWyAgMjExLjk0MjMzNl0g
MmM1MDUgaXMgMmJlNmMwMDAhDQpbICAyMTEuOTQ0MDkzXSAyYzRlYiBpcyAyYmU2ZDAwMCEN
ClsgIDIxMS45NDU4MThdIDJjNGVjIGlzIDJiZTZlMDAwIQ0KWyAgMjExLjk0NzU2MV0gMmM0
ZWQgaXMgMmJlNmYwMDAhDQpbICAyMTEuOTQ5Njk2XSAyYzRlZSBpcyAyYmU2YjAwMCENClsg
IDIxMS45NjgyNDhdIDJjNTA2IGlzIDJiZTZhMDAwIQ0KWyAgMjExLjk4MDM3NF0gMmM0ZWYg
aXMgMmJlNjkwMDAhDQpbICAyMTEuOTg4MzM0XSAyYzRmMCBpcyAyYmU2ODAwMCENClsgIDIx
MS45OTA1NDJdIDJjNGYxIGlzIDJiZTY3MDAwIQ0KWyAgMjExLjk5MjcxN10gMmM1MDcgaXMg
MmJlNjYwMDAhDQpbICAyMTEuOTk0OTI1XSAyYzUwOCBpcyAyYmU2NTAwMCENClsgIDIxMS45
OTcxMjldIDJjNTA5IGlzIDJiZTY0MDAwIQ0KWyAgMjEyLjAwMTAwNl0gMmM1MGEgaXMgMmJl
NjMwMDAhDQpbICAyMTIuMDE0MjYxXSAyYzUwYiBpcyAyYmU2MjAwMCENClsgIDIxMi4wMjUx
MjRdIDJjNGYyIGlzIDJiZTYxMDAwIQ0KWyAgMjEyLjA0NjgyOV0gMmM0ZjMgaXMgMmJlNWQw
MDAhDQpbICAyMTIuMDQ4NjM4XSAyYzUwYyBpcyAyYmU1ZTAwMCENClsgIDIxMi4wNTA0NTVd
IDJjNTBkIGlzIDJiZTVmMDAwIQ0KWyAgMjEyLjA1MjI2OV0gMmM1MGUgaXMgMmJlNjAwMDAh
DQpbICAyMTIuMDU1MzE1XSAyYzRmNCBpcyAyYmU1NTAwMCENClsgIDIxMi4wNTcxNTNdIDJj
NGY1IGlzIDJiZTU2MDAwIQ0KWyAgMjEyLjA1ODk0NV0gMmM0ZjYgaXMgMmJlNTcwMDAhDQpb
ICAyMTIuMDYwNzczXSAyYzRmNyBpcyAyYmU1ODAwMCENClsgIDIxMi4wNjI2MzddIDJjNGY4
IGlzIDJiZTU5MDAwIQ0KWyAgMjEyLjA2NDQ4MV0gMmM0ZjkgaXMgMmJlNWEwMDAhDQpbICAy
MTIuMDY2Mjc4XSAyYzRmYSBpcyAyYmU1YjAwMCENClsgIDIxMi4wNjgxMjZdIDJjNTFhIGlz
IDJiZTVjMDAwIQ0KWyAgMjEyLjA3MDcyNV0gMmM1MjYgaXMgMmJlNDUwMDAhDQpbICAyMTIu
MDcyNTcyXSAyYzUyNyBpcyAyYmU0NjAwMCENClsgIDIxMi4wNzQ0MDNdIDJjNTI4IGlzIDJi
ZTQ3MDAwIQ0KWyAgMjEyLjA3NjIwOV0gMmM1MjkgaXMgMmJlNDgwMDAhDQpbICAyMTIuMDc4
MDUxXSAyYzUyYSBpcyAyYmU0OTAwMCENClsgIDIxMi4wODA3MDNdIDJjNTFiIGlzIDJiZTFh
MDAwIQ0KWyAgMjEyLjA4MjU3NF0gMmM1MWMgaXMgMmJlMWIwMDAhDQpbICAyMTIuMDg0Mzg1
XSAyYzUxZCBpcyAyYmUxYzAwMCENClsgIDIxMi4wODYxODNdIDJjNTFlIGlzIDJiZTFkMDAw
IQ0KWyAgMjEyLjA4Nzk3N10gMmM1MWYgaXMgMmJlMWUwMDAhDQpbICAyMTIuMDg5NzYzXSAy
YzUyMCBpcyAyYmUxZjAwMCENClsgIDIxMi4wOTE1MzJdIDJjNTIxIGlzIDJiZTIwMDAwIQ0K
WyAgMjEyLjA5MzMxNl0gMmM1MjIgaXMgMmJlMjEwMDAhDQpbICAyMTIuMDk1MTQ5XSAyYzUy
MyBpcyAyYmUyMjAwMCENClsgIDIxMi4wOTY5MjBdIDJjNTI0IGlzIDJiZTIzMDAwIQ0KWyAg
MjEyLjA5ODY4N10gMmM1MjUgaXMgMmJlMjQwMDAhDQpbICAyMTIuMTAwNDYyXSAyYzUyYiBp
cyAyYmUyZjAwMCENClsgIDIxMi4xMDIyMjldIDJjNTBmIGlzIDJiZTMwMDAwIQ0KWyAgMjEy
LjEwNDAwNl0gMmM1MTAgaXMgMmJlMzEwMDAhDQpbICAyMTIuMTA1NzY1XSAyYzUxMSBpcyAy
YmUzMjAwMCENClsgIDIxMi4xMDc1MjFdIDJjNTEyIGlzIDJiZTMzMDAwIQ0KWyAgMjEyLjEw
OTI1NV0gMmM1MTMgaXMgMmJlMzQwMDAhDQpbICAyMTIuMTExMDA1XSAyYzUxNCBpcyAyYmUz
NTAwMCENClsgIDIxMi4xMTI3MThdIDJjNTE1IGlzIDJiZTM2MDAwIQ0KWyAgMjEyLjExNDQ0
NF0gMmM1MTYgaXMgMmJlMzcwMDAhDQpbICAyMTIuMTE2MTQwXSAyYzUxNyBpcyAyYmUzODAw
MCENClsgIDIxMi4xMTc4NDRdIDJjNTE4IGlzIDJiZTM5MDAwIQ0KWyAgMjEyLjExOTUzOF0g
MmM1MTkgaXMgMmJlMjUwMDAhDQpbICAyMTIuMTIxMjM2XSAyYzUzOSBpcyAyYmUyNjAwMCEN
ClsgIDIxMi4xMjI5MzddIDJjNTNhIGlzIDJiZTI3MDAwIQ0KWyAgMjEyLjEyNDYzMF0gMmM1
M2IgaXMgMmJlMjgwMDAhDQpbICAyMTIuMTI2Mjk3XSAyYzUzYyBpcyAyYmUyOTAwMCENClsg
IDIxMi4xMjc5ODJdIDJjNTNkIGlzIDJiZTJhMDAwIQ0KWyAgMjEyLjEyOTYzOF0gMmM1M2Ug
aXMgMmJlMmIwMDAhDQpbICAyMTIuMTMxMzIzXSAyYzUzZiBpcyAyYmUyYzAwMCENClsgIDIx
Mi4xMzI5OTBdIDJjNTQwIGlzIDJiZTJkMDAwIQ0KWyAgMjEyLjEzNDY3N10gMmM1NDEgaXMg
MmJlMmUwMDAhDQpbICAyMTIuMTM4MDU4XSAyYzU0MiBpcyAyYmRkYTAwMCENClsgIDIxMi4x
Mzk5MDldIDJjNTJjIGlzIDJiZGRiMDAwIQ0KWyAgMjEyLjE0MTYyM10gMmM1MmQgaXMgMmJk
ZGMwMDAhDQpbICAyMTIuMTQzMzQzXSAyYzUyZSBpcyAyYmRkZDAwMCENClsgIDIxMi4xNDUw
NjldIDJjNTJmIGlzIDJiZGRlMDAwIQ0KWyAgMjEyLjE0Njc2NF0gMmM1MzAgaXMgMmJkZGYw
MDAhDQpbICAyMTIuMTQ4NDU0XSAyYzUzMSBpcyAyYmRlMDAwMCENClsgIDIxMi4xNTAxNTVd
IDJjNTMyIGlzIDJiZGUxMDAwIQ0KWyAgMjEyLjE1MTgzNV0gMmM1MzMgaXMgMmJkZTIwMDAh
DQpbICAyMTIuMTUzNTEyXSAyYzUzNCBpcyAyYmRlMzAwMCENClsgIDIxMi4xNTUxNzBdIDJj
NTM1IGlzIDJiZGU0MDAwIQ0KWyAgMjEyLjE1Njg1MF0gMmM1NWYgaXMgMmJkZWYwMDAhDQpb
ICAyMTIuMTU4NDg1XSAyYzU1ZSBpcyAyYmRmMDAwMCENClsgIDIxMi4xNjAxNTNdIDJjNTVk
IGlzIDJiZGYxMDAwIQ0KWyAgMjEyLjE2MTc5M10gMmM1NWMgaXMgMmJkZjIwMDAhDQpbICAy
MTIuMTYzNDQ2XSAyYzU1YiBpcyAyYmRmMzAwMCENClsgIDIxMi4xNjUwOTddIDJjNTVhIGlz
IDJiZGY0MDAwIQ0KWyAgMjEyLjE2Njc1MV0gMmM1NTkgaXMgMmJkZjUwMDAhDQpbICAyMTIu
MTY4NDAwXSAyYzU1OCBpcyAyYmRmNjAwMCENClsgIDIxMi4xNzAwNTZdIDJjNTM4IGlzIDJi
ZGY3MDAwIQ0KWyAgMjEyLjE3MTY5OV0gMmM1MzcgaXMgMmJkZjgwMDAhDQpbICAyMTIuMTcz
MzgwXSAyYzUzNiBpcyAyYmRmOTAwMCENClsgIDIxMi4xNzUzNjJdIDJjNTc3IGlzIDJiZGM1
MDAwIQ0KWyAgMjEyLjE3NzA5Ml0gMmM1N2EgaXMgMmJkYzYwMDAhDQpbICAyMTIuMTc4NzYy
XSAyYzU3YiBpcyAyYmRjNzAwMCENClsgIDIxMi4xODA0NTVdIDJjNTdjIGlzIDJiZGM4MDAw
IQ0KWyAgMjEyLjE4MjEzOF0gMmM1N2QgaXMgMmJkYzkwMDAhDQpbICAyMTIuMTgzODE3XSAy
YzU3ZSBpcyAyYmRjYTAwMCENClsgIDIxMi4xODU1MDldIDJjNTdmIGlzIDJiZGNiMDAwIQ0K
WyAgMjEyLjE4NzE4MF0gMmM1ODAgaXMgMmJkY2MwMDAhDQpbICAyMTIuMTg4ODYxXSAyYzU4
MSBpcyAyYmRjZDAwMCENClsgIDIxMi4xOTA1NTBdIDJjNTgyIGlzIDJiZGNlMDAwIQ0KWyAg
MjEyLjE5MjE5N10gMmM1NDMgaXMgMmJkZTUwMDAhDQpbICAyMTIuMTkzODg2XSAyYzU0NCBp
cyAyYmRlNjAwMCENClsgIDIxMi4xOTU1MzJdIDJjNTQ1IGlzIDJiZGU3MDAwIQ0KWyAgMjEy
LjE5NzIwNF0gMmM1NDYgaXMgMmJkZTgwMDAhDQpbICAyMTIuMTk4ODczXSAyYzU0NyBpcyAy
YmRlOTAwMCENClsgIDIxMi4yMDA1NDVdIDJjNTQ4IGlzIDJiZGVhMDAwIQ0KWyAgMjEyLjIw
MjIyNV0gMmM1NDkgaXMgMmJkZWIwMDAhDQpbICAyMTIuMjAzOTAzXSAyYzU0YSBpcyAyYmRl
YzAwMCENClsgIDIxMi4yMDU1ODRdIDJjNTRiIGlzIDJiZGVkMDAwIQ0KWyAgMjEyLjIwNzI2
Nl0gMmM1NGMgaXMgMmJkZWUwMDAhDQpbICAyMTIuMjA4OTM2XSAyYzU0ZCBpcyAyYmRjZjAw
MCENClsgIDIxMi4yMTA2MzNdIDJjNTRlIGlzIDJiZGQwMDAwIQ0KWyAgMjEyLjIxMjI5NV0g
MmM1NGYgaXMgMmJkZDEwMDAhDQpbICAyMTIuMjEzOTgxXSAyYzU1MCBpcyAyYmRkMjAwMCEN
ClsgIDIxMi4yMTU2NDhdIDJjNTUxIGlzIDJiZGQzMDAwIQ0KWyAgMjEyLjIxNzMyOV0gMmM1
NTIgaXMgMmJkZDQwMDAhDQpbICAyMTIuMjE5MDEyXSAyYzU1MyBpcyAyYmRkNTAwMCENClsg
IDIxMi4yMjA2OTNdIDJjNTU0IGlzIDJiZGQ2MDAwIQ0KWyAgMjEyLjIyMjM4MF0gMmM1NTUg
aXMgMmJkZDcwMDAhDQpbICAyMTIuMjI0MDYyXSAyYzU1NiBpcyAyYmRkODAwMCENClsgIDIx
Mi4yMjU3MjldIDJjNTU3IGlzIDJiZGQ5MDAwIQ0KWyAgMjEyLjIyOTAzNF0gMmM1OTggaXMg
MmJkYTUwMDAhDQpbICAyMTIuMjMwNzk1XSAyYzU5OSBpcyAyYmRhNjAwMCENClsgIDIxMi4y
MzI0OTJdIDJjNTlhIGlzIDJiZGE3MDAwIQ0KWyAgMjEyLjIzNDIyMV0gMmM1OWIgaXMgMmJk
YTgwMDAhDQpbICAyMTIuMjM1OTI5XSAyYzU5YyBpcyAyYmRhOTAwMCENClsgIDIxMi4yMzc2
MjNdIDJjNTlkIGlzIDJiZGFhMDAwIQ0KWyAgMjEyLjIzOTMxOF0gMmM1OWUgaXMgMmJkYWIw
MDAhDQpbICAyMTIuMjQxMDA5XSAyYzU5ZiBpcyAyYmRhYzAwMCENClsgIDIxMi4yNDI2ODld
IDJjNWEwIGlzIDJiZGFkMDAwIQ0KWyAgMjEyLjI0NDQxMV0gMmM1YTEgaXMgMmJkYWUwMDAh
DQpbICAyMTIuMjQ2MDg0XSAyYzU2MCBpcyAyYmRiYTAwMCENClsgIDIxMi4yNDc3ODJdIDJj
NTgzIGlzIDJiZGJiMDAwIQ0KWyAgMjEyLjI0OTQ3Ml0gMmM1ODQgaXMgMmJkYmMwMDAhDQpb
ICAyMTIuMjUxMTQyXSAyYzU4NSBpcyAyYmRiZDAwMCENClsgIDIxMi4yNTI4MTRdIDJjNTg2
IGlzIDJiZGJlMDAwIQ0KWyAgMjEyLjI1NDQ4M10gMmM1ODcgaXMgMmJkYmYwMDAhDQpbICAy
MTIuMjU2MTQzXSAyYzU4OCBpcyAyYmRjMDAwMCENClsgIDIxMi4yNTc4MDZdIDJbICAyMTQu
MzgzOTE2XSAyYzEzNyBpcyAyYzE5ODAwMCENClsgIDIxNC4zODU1ODddIDJjMTM4IGlzIDJj
MTk5MDAwIQ0KWyAgMjE0LjM4NzI1N10gMmMxMzkgaXMgMmMxOWEwMDAhDQpbICAyMTQuMzg4
OTEzXSAyYzEzYSBpcyAyYzE5YjAwMCENClsgIDIxNC4zOTA1OTldIDJjMTNiIGlzIDJjMTlj
MDAwIQ0KWyAgMjE0LjM5MjI2MV0gMmMxM2MgaXMgMmMxOWQwMDAhDQpbICAyMTQuMzkzOTUw
XSAyYzEzZCBpcyAyYzE5ZTAwMCENClsgIDIxNC4zOTU2MDldIDJjMTQwIGlzIDJjMTlmMDAw
IQ0KWyAgMjE0LjM5NzI3NF0gMmMxMGEgaXMgMmMxOGIwMDAhDQpbICAyMTQuMzk4OTUxXSAy
YzEwYiBpcyAyYzE4YzAwMCENClsgIDIxNC40MDA2MjddIDJjMTBjIGlzIDJjMThkMDAwIQ0K
WyAgMjE0LjQwMjMxNF0gMmMxMGQgaXMgMmMxOGUwMDAhDQpbICAyMTQuNDA0MDAxXSAyYzEw
ZSBpcyAyYzE4ZjAwMCENClsgIDIxNC40MDU2NjNdIDJjMTBmIGlzIDJjMTkwMDAwIQ0KWyAg
MjE0LjQwNzM2N10gMmMxMTAgaXMgMmMxOTEwMDAhDQpbICAyMTQuNDA5MDQwXSAyYzExMSBp
cyAyYzE5MjAwMCENClsgIDIxNC40MTA3NDJdIDJjMTEyIGlzIDJjMTkzMDAwIQ0KWyAgMjE0
LjQxMjQxNV0gMmMxMTMgaXMgMmMxOTQwMDAhDQpbICAyMTQuNDE0MTAyXSAyYzExNCBpcyAy
YzE5NTAwMCENClsgIDIxNC40MTU5ODBdIDJjMGY1IGlzIDJjOTc3MDAwIQ0KWyAgMjE0LjQx
Nzc0NF0gMmMwZjYgaXMgMmM5NzgwMDAhDQpbICAyMTQuNDE5NDYzXSAyYzBmNyBpcyAyYzk3
OTAwMCENClsgIDIxNC40MjExODRdIDJjMGY4IGlzIDJjOTdhMDAwIQ0KWyAgMjE0LjQyMjkx
Ml0gMmMwZjkgaXMgMmM5N2IwMDAhDQpbICAyMTQuNDI0NjM4XSAyYzBmYSBpcyAyYzk3YzAw
MCENClsgIDIxNC40MjYzNDZdIDJjMGZiIGlzIDJjOTdkMDAwIQ0KWyAgMjE0LjQyODA3OF0g
MmMwZmMgaXMgMmM5N2UwMDAhDQpbICAyMTQuNDI5Nzk3XSAyYzBmZCBpcyAyYzk3ZjAwMCEN
ClsgIDIxNC40MzE2NzldIDJjMGY0IGlzIDJjOTc1MDAwIQ0KWyAgMjE0LjQ0MDMyMF0gMmMw
ZmUgaXMgMmM5NmUwMDAhDQpbICAyMTQuNDQyNDU4XSAyYzE0MiBpcyAyYzk1ZjAwMCENClsg
IDIxNC40NDQ2MzVdIDJjMTQzIGlzIDJjOTYwMDAwIQ0KWyAgMjE0LjQ0NjgyN10gMmMxNDQg
aXMgMmM5NWUwMDAhDQpbICAyMTQuNDQ4OTk5XSAyYzE0NSBpcyAyYzk1ZDAwMCENClsgIDIx
NC40NjcwNDhdIDJjMTQ2IGlzIDJjOTYzMDAwIQ0KWyAgMjE0LjQ3ODI5NF0gMmMxNTEgaXMg
MmM5NjEwMDAhDQpbICAyMTQuNDgwMTIzXSAyYzBmZiBpcyAyYzk2ZjAwMCENClsgIDIxNC40
ODE5MTRdIDJjMTQ3IGlzIDJjOTZhMDAwIQ0KWyAgMjE0LjQ4MzcyNV0gMmMxNDggaXMgMmM5
NzMwMDAhDQpbICAyMTQuNDg1NTI2XSAyYzE0OSBpcyAyYzk3NDAwMCENClsgIDIxNC40ODcz
MTNdIDJjMTRhIGlzIDJjOTY5MDAwIQ0KWyAgMjE0LjQ4OTA4OV0gMmMxNGIgaXMgMmM5NmIw
MDAhDQpbICAyMTQuNDkwODg3XSAyYzE0YyBpcyAyYzk2MjAwMCENClsgIDIxNC40OTI2NDld
IDJjMTRkIGlzIDJjOTY4MDAwIQ0KWyAgMjE0LjQ5NDQ0N10gMmMxNGUgaXMgMmM5NjYwMDAh
DQpbICAyMTQuNDk2MTk4XSAyYzE0ZiBpcyAyYzk2NTAwMCENClsgIDIxNC40OTc5ODJdIDJj
MTUwIGlzIDJjOTY0MDAwIQ0KWyAgMjE0LjUxNDAzOV0gMmMxNWQgaXMgMmM5NTYwMDAhDQpb
ICAyMTQuNTE1ODg0XSAyYzE1ZSBpcyAyYzk1NzAwMCENClsgIDIxNC41MTc2OTBdIDJjMTUy
IGlzIDJhNDI4MDAwIQ0KWyAgMjE0LjUxOTQ5OF0gMmMxNTMgaXMgMmFkYmYwMDAhDQpbICAy
MTQuNTIxMjkyXSAyYzE1NCBpcyAyYzk3MDAwMCENClsgIDIxNC41MjMxMDBdIDJjMTU1IGlz
IDJiZmZiMDAwIQ0KWyAgMjE0LjUyNDkyNl0gMmMxNTYgaXMgMmMzYzcwMDAhDQpbICAyMTQu
NTI2NzY3XSAyYzE1NyBpcyAyYmZmYzAwMCENClsgIDIxNC41Mjg2MjFdIDJjMTU4IGlzIDJj
OTU5MDAwIQ0KWyAgMjE0LjUzMDQ5N10gMmMxNTkgaXMgMmM5NTgwMDAhDQpbICAyMTQuNTMy
NDE1XSAyYzE1YSBpcyAyYzNjODAwMCENClsgIDIxNC41MzQyOTddIDJjMTViIGlzIDJjOTZj
MDAwIQ0KWyAgMjE0LjUzNjE4Nl0gMmMxNWMgaXMgMmM5NmQwMDAhDQpbICAyMTQuNTM4Mjc0
XSAyYzE2OSBpcyAyYzk0YjAwMCENClsgIDIxNC41NDAxOTFdIDJjMTVmIGlzIDJjOTRjMDAw
IQ0KWyAgMjE0LjU0MjA1MV0gMmMxNjAgaXMgMmM5NGQwMDAhDQpbICAyMTQuNTQzOTQzXSAy
YzE2MSBpcyAyYzk0ZTAwMCENClsgIDIxNC41NDU3OTNdIDJjMTYyIGlzIDJjOTRmMDAwIQ0K
WyAgMjE0LjU0NzY1NV0gMmMxNjMgaXMgMmM5NTAwMDAhDQpbICAyMTQuNTQ5NTA1XSAyYzE2
NCBpcyAyYzk1MzAwMCENClsgIDIxNC41NTEzMzddIDJjMTY1IGlzIDJjOTU0MDAwIQ0KWyAg
MjE0LjU1MzE1OF0gMmMxNjYgaXMgMmJiMDEwMDAhDQpbICAyMTQuNTU0OTg0XSAyYzE2NyBp
cyAyYmIwMjAwMCENClsgIDIxNC41NTY4MjZdIDJjMTY4IGlzIDJjOTU1MDAwIQ0KWyAgMjE0
LjU1OTE3N10gMmMxN2UgaXMgMmM5NDcwMDAhDQpbICAyMTQuNTYxMDUzXSAyYzE2YSBpcyAy
Yzk0ODAwMCENClsgIDIxNC41NjI4OThdIDJjMTZiIGlzIDJjOTQ5MDAwIQ0KWyAgMjE0LjU2
NDc3OV0gMmMxNmMgaXMgMmM5NGEwMDAhDQpbICAyMTQuNTY3Mzg3XSAyYzE2ZCBpcyAyYzkz
ZjAwMCENClsgIDIxNC41NjkzMDFdIDJjMTZlIGlzIDJjOTQwMDAwIQ0KWyAgMjE0LjU3MTE4
NV0gMmMxNmYgaXMgMmM5NDEwMDAhDQpbICAyMTQuNTczMDcxXSAyYzE3MCBpcyAyYzk0MjAw
MCENClsgIDIxNC41NzQ5NThdIDJjMTcxIGlzIDJjOTQzMDAwIQ0KWyAgMjE0LjU3Njg1OV0g
MmMxNzIgaXMgMmM5NDQwMDAhDQpbICAyMTQuNTc4NjkzXSAyYzE3MyBpcyAyYzk0NTAwMCEN
ClsgIDIxNC41ODA1MzBdIDJjMTc0IGlzIDJjOTQ2MDAwIQ0KWyAgMjE0LjU4MzE1NF0gMmMx
OWYgaXMgMmM5MmYwMDAhDQpbICAyMTQuNTg1MDIzXSAyYzFhMCBpcyAyYzkzMDAwMCENClsg
IDIxNC41ODY4OTddIDJjMWExIGlzIDJjOTMxMDAwIQ0KWyAgMjE0LjU4ODY4NF0gMmMxYTIg
aXMgMmM5MzIwMDAhDQpbICAyMTQuNTkwNDgzXSAyYzFhMyBpcyAyYzkzMzAwMCENClsgIDIx
NC41OTIyNDBdIDJjMTllIGlzIDJjOTI0MDAwIQ0KWyAgMjE0LjU5NDEwMl0gMmMxOWQgaXMg
MmM5MjUwMDAhDQpbICAyMTQuNTk1ODYxXSAyYzE3ZCBpcyAyYzkyNjAwMCENClsgIDIxNC41
OTc2NTFdIDJjMTdjIGlzIDJjOTI3MDAwIQ0KWyAgMjE0LjU5OTM5MF0gMmMxN2IgaXMgMmM5
MjgwMDAhDQpbICAyMTQuNjAxMTM3XSAyYzE3YSBpcyAyYzkyOTAwMCENClsgIDIxNC42MDI4
OTNdIDJjMTc5IGlzIDJjOTJhMDAwIQ0KWyAgMjE0LjYwNDY1MF0gMmMxNzggaXMgMmM5MmIw
MDAhDQpbICAyMTQuNjA2NDEzXSAyYzE3NyBpcyAyYzkyYzAwMCENClsgIDIxNC42MDgxNzFd
IDJjMTc2IGlzIDJjOTJkMDAwIQ0KWyAgMjE0LjYwOTkyMV0gMmMxNzUgaXMgMmM5MmUwMDAh
DQpbICAyMTQuNjEyNTU3XSAyYzE4OSBpcyAyYzkwZjAwMCENClsgIDIxNC42MTQzNzBdIDJj
MThhIGlzIDJjOTEwMDAwIQ0KWyAgMjE0LjYxNjEyN10gMmMxOGIgaXMgMmM5MTEwMDAhDQpb
ICAyMTQuNjE3ODc1XSAyYzE4YyBpcyAyYzkxMjAwMCENClsgIDIxNC42MTk2MTFdIDJjMThk
IGlzIDJjOTEzMDAwIQ0KWyAgMjE0LjYyMTMzMF0gMmMxOGUgaXMgMmM5MTQwMDAhDQpbICAy
MTQuNjIzMDYxXSAyYzE4ZiBpcyAyYzkxNTAwMCENClsgIDIxNC42MjQ3ODRdIDJjMTkwIGlz
IDJjOTE2MDAwIQ0KWyAgMjE0LjYyNjUwNl0gMmMxOTEgaXMgMmM5MTcwMDAhDQpbICAyMTQu
NjI4MjQ1XSAyYzE5MiBpcyAyYzkxODAwMCENClsgIDIxNC42Mjk5NjldIDJjMTg4IGlzIDJj
OTA0MDAwIQ0KWyAgMjE0LjYzMTcwMV0gMmMxODcgaXMgMmM5MDUwMDAhDQpbICAyMTQuNjMz
NDIyXSAyYzE4NiBpcyAyYzkwNjAwMCENClsgIDIxNC42MzUxNTBdIDJjMTg1IGlzIDJjOTA3
MDAwIQ0KWyAgMjE0LjYzNjg3N10gMmMxODQgaXMgMmM5MDgwMDAhDQpbICAyMTQuNjM4NTg1
XSAyYzE4MyBpcyAyYzkwOTAwMCENClsgIDIxNC42NDAzMTFdIDJjMTgyIGlzIDJjOTBhMDAw
IQ0KWyAgMjE0LjY0MjAwMl0gMmMxODEgaXMgMmM5MGIwMDAhDQpbICAyMTQuNjQzNzI0XSAy
YzE4MCBpcyAyYzkwYzAwMCENClsgIDIxNC42NDU0MTRdIDJjMTdmIGlzIDJjOTBkMDAwIQ0K
WyAgMjE0LjY0NzExOV0gMmMxYTQgaXMgMmM5MGUwMDAhDQpbICAyMTQuNjQ5NzQxXSAyYzFh
ZiBpcyAyYzhlZjAwMCENClsgIDIxNC42NTE0OTRdIDJjMWIwIGlzIDJjOGYwMDAwIQ0KWyAg
MjE0LjY1MzIzOV0gMmMxYjEgaXMgMmM4ZjEwMDAhDQpbICAyMTQuNjU1MDA0XSAyYzFiMiBp
cyAyYzhmMjAwMCENClsgIDIxNC42NTY4NTFdIDJjMWIzIGlzIDJjOGYzMDAwIQ0KWyAgMjE0
LjY1ODU3M10gMmMxYjQgaXMgMmM4ZjQwMDAhDQpbICAyMTQuNjYwMzIzXSAyYzFiNSBpcyAy
YzhmNTAwMCENClsgIDIxNC42NjIwNDVdIDJjMWI2IGlzIDJjOGY2MDAwIQ0KWyAgMjE0LjY2
Mzc4M10gMmMxYjcgaXMgMmM4ZjcwMDAhDQpbICAyMTQuNjY1NTI0XSAyYzFiOCBpcyAyYzhm
ODAwMCENClsgIDIxNC42NjcyNTRdIDJjMWFlIGlzIDJjOGU0MDAwIQ0KWyAgMjE0LjY2OTAw
NF0gMmMxYWQgaXMgMmM4ZTUwMDAhDQpbICAyMTQuNjcwNzAyXSAyYzFhYyBpcyAyYzhlNjAw
MCENClsgIDIxNC42NzIzODZdIDJjMWFiIGlzIDJjOGU3MDAwIQ0KWyAgMjE0LjY3NDEwMF0g
MmMxYWEgaXMgMmM4ZTgwMDAhDQpbICAyMTQuNjc1Nzg0XSAyYzFhOSBpcyAyYzhlOTAwMCEN
ClsgIDIxNC42Nzc0OTNdIDJjMWE4IGlzIDJjOGVhMDAwIQ0KWyAgMjE0LjY3OTE3Ml0gMmMx
YTcgaXMgMmM4ZWIwMDAhDQpbICAyMTQuNjgwODczXSAyYzFhNiBpcyAyYzhlYzAwMCENClsg
IDIxNC42ODI1NDVdIDJjMWE1IGlzIDJjOGVkMDAwIQ0KWyAgMjE0LjY4NDIzMV0gMmMxOTMg
aXMgMmM4ZWUwMDAhDQpbICAyMTQuNjg3NjI0XSAyYzFiYSBpcyAyYzhhZjAwMCENClsgIDIx
NC42ODkzNDldIDJjMWJiIGlzIDJjOGIwMDAwIQ0KWyAgMjE0LjY5MTA1NV0gMmMxZGQgaXMg
MmM4YjEwMDAhDQpbICAyMTQuNjkyNzU5XSAyYzFkZSBpcyAyYzhiMjAwMCENClsgIDIxNC42
OTQ0ODJdIDJjMWRmIGlzIDJjOGIzMDAwIQ0KWyAgMjE0LjY5NjE4Nl0gMmMxZTAgaXMgMmM4
YjQwMDAhDQpbICAyMTQuNjk3OTEyXSAyYzFlMSBpcyAyYzhiNTAwMCENClsgIDIxNC42OTk2
MDJdIDJjMWUyIGlzIDJjOGI2MDAwIQ0KWyAgMjE0LjcwMTMxOV0gMmMxZTMgaXMgMmM4Yjcw
MDAhDQpbICAyMTQuNzAzMDQ0XSAyYzFlNCBpcyAyYzhiODAwMCENClsgIDIxNC43MDQ3NTld
IDJjMWJlIGlzIDJjOGM0MDAwIQ0KWyAgMjE0LjcwNjQ5MF0gMmMxOWMgaXMgMmM4YzUwMDAh
DQpbICAyMTQuNzA4MTk3XSAyYzE5YiBpcyAyYzhjNjAwMCENClsgIDIxNC43MDk5MDddIDJj
MTlhIGlzIDJjOGM3MDAwIQ0KWyAgMjE0LjcxMTU4M10gMmMxOTkgaXMgMmM4YzgwMDAhDQpb
ICAyMTQuNzEzMjUxXSAyYzE5OCBpcyAyYzhjOTAwMCENClsgIDIxNC43MTQ5NDhdIDJjMTk3
IGlzIDJjOGNhMDAwIQ0KWyAgMjE0LjcxNjYxNl0gMmMxOTYgaXMgMmM4Y2IwMDAhDQpbICAy
MTQuNzE4MzEyXSAyYzE5NSBpcyAyYzhjYzAwMCENClsgIDIxNC43MTk5NzNdIDJjMTk0IGlz
IDJjOGNkMDAwIQ0KWyAgMjE0LjcyMTY0OV0gMmMxYjkgaXMgMmM4Y2UwMDAhDQpbICAyMTQu
NzIzMzM0XSAyYzFjOSBpcyAyYzhiOTAwMCENClsgIDIxNC43MjUwMjddIDJjMWM4IGlzIDJj
OGJhMDAwIQ0KWyAgMjE0LjcyNjc0MF0gMmMxYzcgaXMgMmM4YmIwMDAhDQpbICAyMTQuNzI4
NDE5XSAyYzFjNiBpcyAyYzhiYzAwMCENClsgIDIxNC43MzAxMTJdIDJjMWM1IGlzIDJjOGJk
MDAwIQ0KWyAgMjE0LjczMTgwN10gMmMxYzQgaXMgMmM4YmUwMDAhDQpbICAyMTQuNzMzNTAw
XSAyYzFjMyBpcyAyYzhiZjAwMCENClsgIDIxNC43MzUxODhdIDJjMWMyIGlzIDJjOGMwMDAw
IQ0KWyAgMjE0LjczNjg4MF0gMmMxYzEgaXMgMmM4YzEwMDAhDQpbICAyMTQuNzM4NTUyXSAy
YzFjMCBpcyAyYzhjMjAwMCENClsgIDIxNC43NDAyNTBdIDJjMWJmIGlzIDJjOGMzMDAwIQ0K
WyAgMjE0Ljc0MzAxMV0gMmMxZjEgaXMgMmM4OWEwMDAhDQpbICAyMTQuNzQ0NzkyXSAyYzFm
MiBpcyAyYzg5YjAwMCENClsgIDIxNC43NDY0NjFdIDJjMWYzIGlzIDJjODljMDAwIQ0KWyAg
MjE0Ljc0ODE3Ml0gMmMxZjQgaXMgMmM4OWQwMDAhDQpbICAyMTQuNzQ5ODU2XSAyYzFmNSBp
cyAyYzg5ZTAwMCENClsgIDIxNC43NTE1NjNdIDJjMWY2IGlzIDJjODlmMDAwIQ0KWyAgMjE0
Ljc1MzI1MV0gMmMxZjcgaXMgMmM4YTAwMDAhDQpbICAyMTQuNzU1MTg5XSAyYzFmOCBpcyAy
YzhhMTAwMCENClsgIDIxNC43NTY5MTFdIDJjMWY5IGlzIDJjOGEyMDAwIQ0KWyAgMjE0Ljc1
ODU5MF0gMmMxZmEgaXMgMmM4YTMwMDAhDQpbICAyMTQuNzYwMjk2XSAyYzFmYiBpcyAyYzg4
ZjAwMCENClsgIDIxNC43NjE5NzNdIDJjMWZlIGlzIDJjODkwMDAwIQ0KWyAgMjE0Ljc2MzY2
OV0gMmMxZmYgaXMgMmM4OTEwMDAhDQpbICAyMTQuNzY1NDQ4XSAyYzIwMCBpcyAyYzg5MjAw
MCENClsgIDIxNC43NjcxNjBdIDJjMjAxIGlzIDJjODkzMDAwIQ0KWyAgMjE0Ljc2ODg5MV0g
MmMyMDIgaXMgMmM4OTQwMDAhDQpbICAyMTQuNzcwNTg0XSAyYzIwMyBpcyAyYzg5NTAwMCEN
ClsgIDIxNC43NzIyNjhdIDJjMjA0IGlzIDJjODk2MDAwIQ0KWyAgMjE0Ljc3Mzk4OF0gMmMy
MDUgaXMgMmM4OTcwMDAhDQpbICAyMTQuNzc1NjcyXSAyYzIwNiBpcyAyYzg5ODAwMCENClsg
IDIxNC43NzczNzVdIDJjMWVmIGlzIDJjODg0MDAwIQ0KWyAgMjE0Ljc3OTA1NF0gMmMxZWUg
aXMgMmM4ODUwMDAhDQpbICAyMTQuNzgwNzYwXSAyYzFlZCBpcyAyYzg4NjAwMCENClsgIDIx
NC43ODI0ODNdIDJjMWVjIGlzIDJjODg3MDAwIQ0KWyAgMjE0Ljc4NDIwN10gMmMxZWIgaXMg
MmM4ODgwMDAhDQpbICAyMTQuNzg1OTA3XSAyYzFlYSBpcyAyYzg4OTAwMCENClsgIDIxNC43
ODc1OTVdIDJjMWU5IGlzIDJjODhhMDAwIQ0KWyAgMjE0Ljc4OTI5MV0gMmMxZTggaXMgMmM4
OGIwMDAhDQpbICAyMTQuNzkwOTk3XSAyYzFlNyBpcyAyYzg4YzAwMCENClsgIDIxNC43OTI2
NzBdIDJjMWU2IGlzIDJjODhkMDAwIQ0KWyAgMjE0Ljc5NDM3M10gMmMxZTUgaXMgMmM4OGUw
MDAhDQpbICAyMTQuNzk2MzMzXSAyYzFmMCBpcyAyYzg2ZjAwMCENClsgIDIxNC43OTgwNTFd
IDJjMjA3IGlzIDJjODdlMDAwIQ0KWyAgMjE0Ljc5OTczMV0gMmMxY2EgaXMgMmM4N2YwMDAh
DQpbICAyMTQuODAxNDQ2XSAyYzFjYiBpcyAyYzg4MDAwMCENClsgIDIxNC44MDMxNDldIDJj
MWNjIGlzIDJjODgxMDAwIQ0KWyAgMjE0LjgwNDg1NF0gMmMxY2QgaXMgMmM4ODIwMDAhDQpb
ICAyMTQuODA2NTcwXSAyYzFjZSBpcyAyYzg4MzAwMCENClsgIDIxNC44MDgyNzNdIDJjMWRh
IGlzIDJjODcwMDAwIQ0KWyAgMjE0LjgwOTk4OF0gMmMxZGIgaXMgMmM4NzEwMDAhDQpbICAy
MTQuODExNjg4XSAyYzFkYyBpcyAyYzg3MjAwMCENClsgIDIxNC44MTMzODddIDJjMWNmIGlz
IDJjODczMDAwIQ0KWyAgMjE0LjgxNTA3M10gMmMxZDAgaXMgMmM4NzQwMDAhDQpbICAyMTQu
ODE2NzYxXSAyYzFkMSBpcyAyYzg3NTAwMCENClsgIDIxNC44MTg0NDddIDJjMWQyIGlzIDJj
ODc2MDAwIQ0KWyAgMjE0LjgyMDEyNV0gMmMxZDMgaXMgMmM4NzcwMDAhDQpbICAyMTQuODIx
Nzg4XSAyYzFkNCBpcyAyYzg3ODAwMCENClsgIDIxNC44MjM0ODhdIDJjMWQ1IGlzIDJjODc5
MDAwIQ0KWyAgMjE0LjgyNTEzNV0gMmMxZDYgaXMgMmM4N2EwMDAhDQpbICAyMTQuODI2ODE4
XSAyYzFkNyBpcyAyYzg3YjAwMCENClsgIDIxNC44Mjg0NzBdIDJjMWQ4IGlzIDJjODdjMDAw
IQ0KWyAgMjE0LjgzMDE0MV0gMmMxZDkgaXMgMmM4N2QwMDAhDQpbICAyMTQuODMyMzM5XSAz
NmQ1MSBpcyAyYzg2YjAwMCENClsgIDIxNC44MzQwODVdIDJjMjFkIGlzIDJjODZjMDAwIQ0K
WyAgMjE0LjgzNTgxMl0gMmMyMWUgaXMgMmM4NmQwMDAhDQpbICAyMTQuODM3NTMxXSAyYzIx
ZiBpcyAyYzg2ZTAwMCENClsgIDIxNC44NDAwMDldIDJjMjIwIGlzIDJjODYzMDAwIQ0KWyAg
MjE0Ljg0MTgzOV0gMzc2NzggaXMgMmM4NjQwMDAhDQpbICAyMTQuODQzNjg1XSAzNmRlYyBp
cyAyYzg2NTAwMCENClsgIDIxNC44NDU0NTBdIDJjMjA4IGlzIDJjODY2MDAwIQ0KWyAgMjE0
Ljg0NzI2OV0gMmMyMDkgaXMgMmM4NjcwMDAhDQpbICAyMTQuODQ5MDY4XSAyYzIwYSBpcyAy
Yzg2ODAwMCENClsgIDIxNC44NTA4NjZdIDJjMjBiIGlzIDJjODY5MDAwIQ0KWyAgMjE0Ljg1
MjY2M10gMmMyMGMgaXMgMmM4NmEwMDAhDQpbICAyMTQuODU1MzU2XSAyYzIxNyBpcyAyYzg0
ODAwMCENClsgIDIxNC44NTcxNzNdIDJjMjE2IGlzIDJjODQ5MDAwIQ0KWyAgMjE0Ljg1ODkx
OF0gMmMyMTUgaXMgMmM4NGEwMDAhDQpbICAyMTQuODYwNzA2XSAyYzIxNCBpcyAyYzg0YjAw
MCENClsgIDIxNC44NjI0NjJdIDJjMjEzIGlzIDJjODRjMDAwIQ0KWyAgMjE0Ljg2NDI1NF0g
MmMyMTIgaXMgMmM4NGQwMDAhDQpbICAyMTQuODY2MDA1XSAyYzIxMSBpcyAyYzg0ZTAwMCEN
ClsgIDIxNC44Njc3ODNdIDJjMjEwIGlzIDJjODRmMDAwIQ0KWyAgMjE0Ljg2OTU1OF0gMmMy
MGYgaXMgMmM4NTAwMDAhDQpbICAyMTQuODcxMzQ1XSAyYzIwZSBpcyAyYzg1MTAwMCENClsg
IDIxNC44NzMxMzFdIDJjMjBkIGlzIDJjODUyMDAwIQ0KWyAgMjE0Ljg3NTgyNl0gMmMyMTgg
aXMgMmM4MjgwMDAhDQpbICAyMTQuODc3NjY4XSAyYzIxOSBpcyAyYzgyOTAwMCENClsgIDIx
NC44Nzk0NDJdIDJjMjFhIGlzIDJjODJhMDAwIQ0KWyAgMjE0Ljg4MTI1Nl0gMmMyMWIgaXMg
MmM4MmIwMDAhDQpbICAyMTQuODgzMDQ3XSAyYzIxYyBpcyAyYzgyYzAwMCENClsgIDIxNC44
ODQ4NzRdIDJjMjQxIGlzIDJjODJkMDAwIQ0KWyAgMjE0Ljg4NjY3MV0gMmMyNDAgaXMgMmM4
MmUwMDAhDQpbICAyMTQuODg4NDc5XSAyYzIzZiBpcyAyYzgyZjAwMCENClsgIDIxNC44OTAz
MDFdIDJjMjNlIGlzIDJjODMwMDAwIQ0KWyAgMjE0Ljg5MjA2Nl0gMmMyM2QgaXMgMmM4MzEw
MDAhDQpbICAyMTQuODkzODM4XSAyYzIzYyBpcyAyYzgzMjAwMCENClsgIDIxNC44OTU1ODBd
IDJjMjQyIGlzIDJjODMzMDAwIQ0KWyAgMjE0Ljg5NzM1Nl0gMmMyNDMgaXMgMmM4MzQwMDAh
DQpbICAyMTQuODk5MDkyXSAyYzI0NCBpcyAyYzgzNTAwMCENClsgIDIxNC45MDA4MjRdIDJj
MjQ1IGlzIDJjODM2MDAwIQ0KWyAgMjE0LjkwMjU1NF0gMmMyNDYgaXMgMmM4MzcwMDAhDQpb
ICAyMTQuOTA0MjUxXSAyYzI0NyBpcyAyYzgzODAwMCENClsgIDIxNC45MDU5NDZdIDJjMjQ4
IGlzIDJjODM5MDAwIQ0KWyAgMjE0LjkwNzY0Ml0gMmMyNDkgaXMgMmM4M2EwMDAhDQpbICAy
MTQuOTA5MzIxXSAyYzI0YSBpcyAyYzgzYjAwMCENClsgIDIxNC45MTEwMzZdIDJjMjRiIGlz
IDJjODNjMDAwIQ0KWyAgMjE0LjkxMzYxNV0gMmMyNTggaXMgMmM4MTMwMDAhDQpbICAyMTQu
OTE1NDQzXSAyYzI1OSBpcyAyYzgxNDAwMCENClsgIDIxNC45MTcxNzldIDJjMjVhIGlzIDJj
ODE1MDAwIQ0KWyAgMjE0LjkxODkwMl0gMmMyNWIgaXMgMmM4MTYwMDAhDQpbICAyMTQuOTIw
NjEzXSAyYzI1YyBpcyAyYzgxNzAwMCENClsgIDIxNC45MjIzMzhdIDJjMjVkIGlzIDJjODE4
MDAwIQ0KWyAgMjE0LjkyNDA2MF0gMmMyNWUgaXMgMmM4MTkwMDAhDQpbICAyMTQuOTI1NzYy
XSAyYzI1ZiBpcyAyYzgxYTAwMCENClsgIDIxNC45Mjc0ODNdIDJjMjYwIGlzIDJjODFiMDAw
IQ0KWyAgMjE0LjkyOTE3OF0gMmMyNjEgaXMgMmM4MWMwMDAhDQpbICAyMTQuOTMwODg5XSAy
YzI1NyBpcyAyYzgwODAwMCENClsgIDIxNC45MzI1NzFdIDJjMjU2IGlzIDJjODA5MDAwIQ0K
WyAgMjE0LjkzNDI3MV0gMmMyNTUgaXMgMmM4MGEwMDAhDQpbICAyMTQuOTM1OTU3XSAyYzI1
NCBpcyAyYzgwYjAwMCENClsgIDIxNC45Mzc2MzldIDJjMjUzIGlzIDJjODBjMDAwIQ0KWyAg
MjE0LjkzOTMyMF0gMmMyNTIgaXMgMmM4MGQwMDAhDQpbICAyMTQuOTQwOTk2XSAyYzI1MSBp
cyAyYzgwZTAwMCENClsgIDIxNC45NDI2NjZdIDJjMjUwIGlzIDJjODBmMDAwIQ0KWyAgMlsg
IDIxNy4wNzIwMzFdIDJiZWRjIGlzIDJjYTI3MDAwIQ0KWyAgMjE3LjA3Mzc5OV0gMmJlZGQg
aXMgMmNhMjgwMDAhDQpbICAyMTcuMDc1NDg4XSAyYmVkZSBpcyAyY2EyOTAwMCENClsgIDIx
Ny4wNzcxOTVdIDJiZWRmIGlzIDJjYTJhMDAwIQ0KWyAgMjE3LjA3ODg3OF0gMmJlZTAgaXMg
MmNhMmIwMDAhDQpbICAyMTcuMDgwNTY1XSAyYmVlMSBpcyAyY2EyYzAwMCENClsgIDIxNy4w
ODIyNjldIDJiZWUyIGlzIDJjYTJkMDAwIQ0KWyAgMjE3LjA4Mzk2N10gMmJlZTMgaXMgMmNh
MmUwMDAhDQpbICAyMTcuMDg1NjY1XSAyYmVlNCBpcyAyY2EyZjAwMCENClsgIDIxNy4wODcz
MjRdIDJiZWU1IGlzIDJjYTFiMDAwIQ0KWyAgMjE3LjA4ODk5MF0gMmJlZTYgaXMgMmNhMWMw
MDAhDQpbICAyMTcuMDkwNjY0XSAyYmVlNyBpcyAyY2ExZDAwMCENClsgIDIxNy4wOTIzMTRd
IDJiZjA3IGlzIDJjYTFlMDAwIQ0KWyAgMjE3LjA5NDA0Ml0gMmJmMDggaXMgMmNhMWYwMDAh
DQpbICAyMTcuMDk1Njg2XSAyYmYwOSBpcyAyY2EyMDAwMCENClsgIDIxNy4wOTczNDRdIDJi
ZjBhIGlzIDJjYTIxMDAwIQ0KWyAgMjE3LjA5OTAwNl0gMmJmMGIgaXMgMmNhMjIwMDAhDQpb
ICAyMTcuMTAwNjY5XSAyYmYwYyBpcyAyY2EyMzAwMCENClsgIDIxNy4xMDIzNDZdIDJiZjBk
IGlzIDJjYTI0MDAwIQ0KWyAgMjE3LjEwNDcxMF0gMmJmMGUgaXMgMmNhMDUwMDAhDQpbICAy
MTcuMTA2MzgzXSAyYmYwZiBpcyAyY2EwNjAwMCENClsgIDIxNy4xMDgwNTZdIDJiZjEwIGlz
IDJjYTA3MDAwIQ0KWyAgMjE3LjEwOTcxOF0gMmJmMTEgaXMgMmNhMDgwMDAhDQpbICAyMTcu
MTExNDA5XSAyYmYxMiBpcyAyY2EwOTAwMCENClsgIDIxNy4xMTMwODJdIDJiZjEzIGlzIDJj
YTBhMDAwIQ0KWyAgMjE3LjExNDg4OF0gMmJmMTQgaXMgMmNhMGIwMDAhDQpbICAyMTcuMTE2
NTYwXSAyYmYxNSBpcyAyY2EwYzAwMCENClsgIDIxNy4xMTgyNDRdIDJiZjE2IGlzIDJjYTBk
MDAwIQ0KWyAgMjE3LjExOTkyN10gMmJmMTcgaXMgMmNhMGUwMDAhDQpbICAyMTcuMTIxNjA2
XSAyYmYxOCBpcyAyY2EwZjAwMCENClsgIDIxNy4xMjMyODNdIDJiZjE5IGlzIDJjOWZiMDAw
IQ0KWyAgMjE3LjEyNDk3MF0gMmJmMWEgaXMgMmM5ZmMwMDAhDQpbICAyMTcuMTI2NjQzXSAy
YmYxYiBpcyAyYzlmZDAwMCENClsgIDIxNy4xMjgzNDddIDJiZjFjIGlzIDJjOWZlMDAwIQ0K
WyAgMjE3LjEzMDAxNV0gMmJmMWQgaXMgMmM5ZmYwMDAhDQpbICAyMTcuMTMxNzE4XSAyYmYx
ZSBpcyAyY2EwMDAwMCENClsgIDIxNy4xMzM0MDVdIDJiZjFmIGlzIDJjYTAxMDAwIQ0KWyAg
MjE3LjEzNTA3Ml0gMmJmMjAgaXMgMmNhMDIwMDAhDQpbICAyMTcuMTM2Nzc5XSAyYmYyMSBp
cyAyY2EwMzAwMCENClsgIDIxNy4xMzg0NTldIDJiZjIyIGlzIDJjYTA0MDAwIQ0KWyAgMjE3
LjE0MTE0NV0gMmJlZDkgaXMgMmM5ZDAwMDAhDQpbICAyMTcuMTQyODUwXSAyYmVkOCBpcyAy
YzlkMTAwMCENClsgIDIxNy4xNDQ2NjJdIDJiZWQ3IGlzIDJjOWQyMDAwIQ0KWyAgMjE3LjE0
NjM5Nl0gMmJlZDYgaXMgMmM5ZDMwMDAhDQpbICAyMTcuMTQ4MTI1XSAyYmVkNSBpcyAyYzlk
NDAwMCENClsgIDIxNy4xNDk4MjJdIDJiZWQ0IGlzIDJjOWQ1MDAwIQ0KWyAgMjE3LjE1MTUy
NF0gMmJlZDMgaXMgMmM5ZDYwMDAhDQpbICAyMTcuMTUzMjI1XSAyYmVkMiBpcyAyYzlkNzAw
MCENClsgIDIxNy4xNTQ5MTddIDJiZWQxIGlzIDJjOWQ4MDAwIQ0KWyAgMjE3LjE1NjYwMF0g
MmJlZDAgaXMgMmM5ZDkwMDAhDQpbICAyMTcuMTU4MjgzXSAyYmVlYyBpcyAyYzlkYTAwMCEN
ClsgIDIxNy4xNjA4MjRdIDJiZjM3IGlzIDJjOWJiMDAwIQ0KWyAgMjE3LjE2MjU2MV0gMmJm
MzYgaXMgMmM5YmMwMDAhDQpbICAyMTcuMTY0MjczXSAyYmYzNSBpcyAyYzliZDAwMCENClsg
IDIxNy4xNjU5ODBdIDJiZjM0IGlzIDJjOWJlMDAwIQ0KWyAgMjE3LjE2NzY5NV0gMmJmMzMg
aXMgMmM5YmYwMDAhDQpbICAyMTcuMTY5NDI2XSAyYmYzMiBpcyAyYzljMDAwMCENClsgIDIx
Ny4xNzExMzldIDJiZjMxIGlzIDJjOWMxMDAwIQ0KWyAgMjE3LjE3Mjg2MV0gMmJmMzAgaXMg
MmM5YzIwMDAhDQpbICAyMTcuMTc0NTc4XSAyYmYyZiBpcyAyYzljMzAwMCENClsgIDIxNy4x
NzYyOTNdIDJiZjJlIGlzIDJjOWM0MDAwIQ0KWyAgMjE3LjE3ODAzNV0gMmJmMjMgaXMgMmM5
YjAwMDAhDQpbICAyMTcuMTc5NzQ2XSAyYmYyNCBpcyAyYzliMTAwMCENClsgIDIxNy4xODE0
NzNdIDJiZjI1IGlzIDJjOWIyMDAwIQ0KWyAgMjE3LjE4MzE4MV0gMmJmMjYgaXMgMmM5YjMw
MDAhDQpbICAyMTcuMTg0OTA1XSAyYmYyNyBpcyAyYzliNDAwMCENClsgIDIxNy4xODY2MzBd
IDJiZjI4IGlzIDJjOWI1MDAwIQ0KWyAgMjE3LjE4ODM0OV0gMmJmMjkgaXMgMmM5YjYwMDAh
DQpbICAyMTcuMTkwMDkwXSAyYmYyYSBpcyAyYzliNzAwMCENClsgIDIxNy4xOTE3NzldIDJi
ZjJiIGlzIDJjOWI4MDAwIQ0KWyAgMjE3LjE5MzUwNF0gMmJmMmMgaXMgMmM5YjkwMDAhDQpb
ICAyMTcuMTk1MjA2XSAyYmYyZCBpcyAyYzliYTAwMCENClsgIDIxNy4xOTc3ODhdIDJiZWY3
IGlzIDJjOTliMDAwIQ0KWyAgMjE3LjE5OTU4OF0gMmJlZjggaXMgMmM5OWMwMDAhDQpbICAy
MTcuMjAxMzEwXSAyYmVmOSBpcyAyYzk5ZDAwMCENClsgIDIxNy4yMDMwMzJdIDJiZWZhIGlz
IDJjOTllMDAwIQ0KWyAgMjE3LjIwNDc1Ml0gMmJlZmIgaXMgMmM5OWYwMDAhDQpbICAyMTcu
MjA2NDczXSAyYmVmYyBpcyAyYzlhMDAwMCENClsgIDIxNy4yMDgxODVdIDJiZWZkIGlzIDJj
OWExMDAwIQ0KWyAgMjE3LjIwOTkwNF0gMmJlZmUgaXMgMmM5YTIwMDAhDQpbICAyMTcuMjEx
NjQxXSAyYmVmZiBpcyAyYzlhMzAwMCENClsgIDIxNy4yMTMzNDZdIDJiZjAwIGlzIDJjOWE0
MDAwIQ0KWyAgMjE3LjIxNTA4Nl0gMmJlZjYgaXMgMmM5OTAwMDAhDQpbICAyMTcuMjE2Nzk4
XSAyYmVmNSBpcyAyYzk5MTAwMCENClsgIDIxNy4yMTg1MDVdIDJiZWY0IGlzIDJjOTkyMDAw
IQ0KWyAgMjE3LjIyMDIxOF0gMmJlZjMgaXMgMmM5OTMwMDAhDQpbICAyMTcuMjIxOTE3XSAy
YmVmMiBpcyAyYzk5NDAwMCENClsgIDIxNy4yMjM2NDVdIDJiZWYxIGlzIDJjOTk1MDAwIQ0K
WyAgMjE3LjIyNTMzMl0gMmJlZjAgaXMgMmM5OTYwMDAhDQpbICAyMTcuMjI3MDQ4XSAyYmVl
ZiBpcyAyYzk5NzAwMCENClsgIDIxNy4yMjg3NDRdIDJiZWVlIGlzIDJjOTk4MDAwIQ0KWyAg
MjE3LjIzMDQzNF0gMmJlZWQgaXMgMmM5OTkwMDAhDQpbICAyMTcuMjMyMTIzXSAyYmYzOCBp
cyAyYzk5YTAwMCENClsgIDIxNy4yMzU1ODBdIDJiZjAyIGlzIDJkMTViMDAwIQ0KWyAgMjE3
LjIzNzMzOF0gMmJmMDMgaXMgMmQxNWMwMDAhDQpbICAyMTcuMjM5MDY0XSAyYmYwNCBpcyAy
ZDE1ZDAwMCENClsgIDIxNy4yNDA4MDZdIDJiZjA1IGlzIDJkMTVlMDAwIQ0KWyAgMjE3LjI0
MjUyMF0gMmJmMDYgaXMgMmQxNWYwMDAhDQpbICAyMTcuMjQ0MjU5XSAyYmY2NiBpcyAyZDE2
MDAwMCENClsgIDIxNy4yNDU5ODBdIDJiZjY3IGlzIDJkMTYxMDAwIQ0KWyAgMjE3LjI0Nzcx
OF0gMmJmNjggaXMgMmQxNjIwMDAhDQpbICAyMTcuMjQ5NDQyXSAyYmY2OSBpcyAyZDE2MzAw
MCENClsgIDIxNy4yNTExNjZdIDJiZjZhIGlzIDJkMTY0MDAwIQ0KWyAgMjE3LjI1Mjg5N10g
MmJmMDEgaXMgMmQxNTAwMDAhDQpbICAyMTcuMjU0NjI2XSAyYmYzOSBpcyAyZDE1MTAwMCEN
ClsgIDIxNy4yNTYzNzFdIDJiZjNhIGlzIDJkMTUyMDAwIQ0KWyAgMjE3LjI1ODEwNl0gMmJm
M2IgaXMgMmQxNTMwMDAhDQpbICAyMTcuMjU5ODIyXSAyYmYzYyBpcyAyZDE1NDAwMCENClsg
IDIxNy4yNjE1NzldIDJiZjNkIGlzIDJkMTU1MDAwIQ0KWyAgMjE3LjI2MzMwMV0gMmJmM2Ug
aXMgMmQxNTYwMDAhDQpbICAyMTcuMjY1MDYxXSAyYmYzZiBpcyAyZDE1NzAwMCENClsgIDIx
Ny4yNjY3OTddIDJiZjQwIGlzIDJkMTU4MDAwIQ0KWyAgMjE3LjI2ODUyN10gMmJmNDEgaXMg
MmQxNTkwMDAhDQpbICAyMTcuMjcwMjUxXSAyYmY0MiBpcyAyZDE1YTAwMCENClsgIDIxNy4y
NzE5NDddIDJiZjZiIGlzIDJkMTQ1MDAwIQ0KWyAgMjE3LjI3MzY4NV0gMmJmNmMgaXMgMmQx
NDYwMDAhDQpbICAyMTcuMjc1NDMwXSAyYmY2ZCBpcyAyZDE0NzAwMCENClsgIDIxNy4yNzcx
NjNdIDJiZjZlIGlzIDJkMTQ4MDAwIQ0KWyAgMjE3LjI3ODg3MF0gMmJmNmYgaXMgMmQxNDkw
MDAhDQpbICAyMTcuMjgwNTkxXSAyYmY3MCBpcyAyZDE0YTAwMCENClsgIDIxNy4yODIzMjZd
IDJiZjcxIGlzIDJkMTRiMDAwIQ0KWyAgMjE3LjI4NDA1M10gMmJmNzIgaXMgMmQxNGMwMDAh
DQpbICAyMTcuMjg1NzkwXSAyYmY3MyBpcyAyZDE0ZDAwMCENClsgIDIxNy4yODc1MjNdIDJi
Zjc0IGlzIDJkMTRlMDAwIQ0KWyAgMjE3LjI4OTI0Nl0gMmJmNzUgaXMgMmQxNGYwMDAhDQpb
ICAyMTcuMjkwOTQ0XSAyYmY0ZiBpcyAyZDE2NTAwMCENClsgIDIxNy4yOTI2NDBdIDJiZjRl
IGlzIDJkMTY2MDAwIQ0KWyAgMjE3LjI5NDM2MV0gMmJmNGQgaXMgMmQxNjcwMDAhDQpbICAy
MTcuMjk2MDQ3XSAyYmY0YyBpcyAyZDE2ODAwMCENClsgIDIxNy4yOTc3NTldIDJiZjRiIGlz
IDJkMTY5MDAwIQ0KWyAgMjE3LjI5OTQzOF0gMmJmNGEgaXMgMmQxNmEwMDAhDQpbICAyMTcu
MzAxMTMwXSAyYmY0OSBpcyAyZDE2YjAwMCENClsgIDIxNy4zMDI4MzFdIDJiZjQ4IGlzIDJk
MTZjMDAwIQ0KWyAgMjE3LjMwNDUyM10gMmJmNDUgaXMgMmQxNmQwMDAhDQpbICAyMTcuMzA2
MjEyXSAyYmY0NCBpcyAyZDE2ZTAwMCENClsgIDIxNy4zMDc4ODddIDJiZjQzIGlzIDJkMTZm
MDAwIQ0KWyAgMjE3LjMwOTU0NF0gMmJmNzYgaXMgMmQxM2IwMDAhDQpbICAyMTcuMzExMjQx
XSAyYmY3NyBpcyAyZDEzYzAwMCENClsgIDIxNy4zMTI5MDldIDJiZjc4IGlzIDJkMTNkMDAw
IQ0KWyAgMjE3LjMxNDYwNl0gMmJmNzkgaXMgMmQxM2UwMDAhDQpbICAyMTcuMzE2MjYzXSAy
YmY3YSBpcyAyZDEzZjAwMCENClsgIDIxNy4zMTc5MzJdIDJiZjdiIGlzIDJkMTQwMDAwIQ0K
WyAgMjE3LjMxOTYxNl0gMmJmN2MgaXMgMmQxNDEwMDAhDQpbICAyMTcuMzIxMjkxXSAyYmY3
ZCBpcyAyZDE0MjAwMCENClsgIDIxNy4zMjI5ODBdIDJiZjdlIGlzIDJkMTQzMDAwIQ0KWyAg
MjE3LjMyNDY2M10gMmJmN2YgaXMgMmQxNDQwMDAhDQpbICAyMTcuMzMxNTUzXSAyYmY4MCBp
cyAyZDEzYTAwMCENClsgIDIxNy4zMzU1NTddIDJiZjUwIGlzIDJkMTM2MDAwIQ0KWyAgMjE3
LjMzNzI5NF0gMmJmODEgaXMgMmQxMzcwMDAhDQpbICAyMTcuMzM4OTY5XSAyYmY4MiBpcyAy
ZDEzODAwMCENClsgIDIxNy4zNDA2ODZdIDJiZjgzIGlzIDJkMTM5MDAwIQ0KWyAgMjE3LjM0
MzA2N10gMmJmODQgaXMgMmQxMmUwMDAhDQpbICAyMTcuMzQ0ODgwXSAyYmY4NSBpcyAyZDEy
ZjAwMCENClsgIDIxNy4zNDY1NjNdIDJiZjg2IGlzIDJkMTMwMDAwIQ0KWyAgMjE3LjM0ODQ2
MF0gMmJmODcgaXMgMmQxMzEwMDAhDQpbICAyMTcuMzUwMjEwXSAyYmY4OCBpcyAyZDEzMjAw
MCENClsgIDIxNy4zNTE4OTJdIDJiZjg5IGlzIDJkMTMzMDAwIQ0KWyAgMjE3LjM1MzU2NV0g
MmJmOGEgaXMgMmQxMzQwMDAhDQpbICAyMTcuMzU1MjIzXSAyYmY4YiBpcyAyZDEzNTAwMCEN
ClsgIDIxNy4zNTc3MTddIDJiZjk3IGlzIDJkMTFlMDAwIQ0KWyAgMjE3LjM1OTQwMl0gMmJm
OTggaXMgMmQxMWYwMDAhDQpbICAyMTcuMzYxMTExXSAyYmY5OSBpcyAyZDEyMDAwMCENClsg
IDIxNy4zNjI4MzddIDJiZjlhIGlzIDJkMTIxMDAwIQ0KWyAgMjE3LjM2NDY0N10gMmJmOWIg
aXMgMmQxMjIwMDAhDQpbICAyMTcuMzY2NDY5XSAyYmY5NSBpcyAyZDExNDAwMCENClsgIDIx
Ny4zNjgyMTNdIDJiZjk0IGlzIDJkMTE1MDAwIQ0KWyAgMjE3LjM2OTkxNV0gMmJmOTMgaXMg
MmQxMTYwMDAhDQpbICAyMTcuMzcxNjE4XSAyYmY5MiBpcyAyZDExNzAwMCENClsgIDIxNy4z
NzMzMDddIDJiZjkxIGlzIDJkMTE4MDAwIQ0KWyAgMjE3LjM3NDk5MF0gMmJmOTAgaXMgMmQx
MTkwMDAhDQpbICAyMTcuMzc2NjgwXSAyYmY4ZiBpcyAyZDExYTAwMCENClsgIDIxNy4zNzgz
NzRdIDJiZjhlIGlzIDJkMTFiMDAwIQ0KWyAgMjE3LjM4MDA4NV0gMmJmOGQgaXMgMmQxMWMw
MDAhDQpbICAyMTcuMzgxNzgyXSAyYmY4YyBpcyAyZDExZDAwMCENClsgIDIxNy4zODM3MzJd
IDJiZjk2IGlzIDJkMGZkMDAwIQ0KWyAgMjE3LjM4NTQxOF0gMmJmOWMgaXMgMmQxMDgwMDAh
DQpbICAyMTcuMzg3MTA2XSAyYmY1MSBpcyAyZDEwOTAwMCENClsgIDIxNy4zODg3ODhdIDJi
ZjUyIGlzIDJkMTBhMDAwIQ0KWyAgMjE3LjM5MDQ4OV0gMmJmNTMgaXMgMmQxMGIwMDAhDQpb
ICAyMTcuMzkyMTY1XSAyYmY1NCBpcyAyZDEwYzAwMCENClsgIDIxNy4zOTM4NjldIDJiZjU1
IGlzIDJkMTBkMDAwIQ0KWyAgMjE3LjM5NTUzM10gMmJmNTYgaXMgMmQxMGUwMDAhDQpbICAy
MTcuMzk3MjA5XSAyYmY1NyBpcyAyZDEwZjAwMCENClsgIDIxNy4zOTg4ODBdIDJiZjU4IGlz
IDJkMTEwMDAwIQ0KWyAgMjE3LjQwMDU1Nl0gMmJmNTkgaXMgMmQxMTEwMDAhDQpbICAyMTcu
NDAyMjM3XSAyYmY1YSBpcyAyZDExMjAwMCENClsgIDIxNy40MDM5MjRdIDJiZjViIGlzIDJk
MGZlMDAwIQ0KWyAgMjE3LjQwNTYyMF0gMmJmNWMgaXMgMmQwZmYwMDAhDQpbICAyMTcuNDA3
MzEzXSAyYmY1ZCBpcyAyZDEwMDAwMCENClsgIDIxNy40MDkwMDZdIDJiZjVlIGlzIDJkMTAx
MDAwIQ0KWyAgMjE3LjQxMDcyMV0gMmJmNWYgaXMgMmQxMDIwMDAhDQpbICAyMTcuNDEyMzk5
XSAyYmY2MCBpcyAyZDEwMzAwMCENClsgIDIxNy40MTQxMTJdIDJiZjYxIGlzIDJkMTA0MDAw
IQ0KWyAgMjE3LjQxNTc4NV0gMmJmNjIgaXMgMmQxMDUwMDAhDQpbICAyMTcuNDE3NDcwXSAy
YmY2MyBpcyAyZDEwNjAwMCENClsgIDIxNy40MTkxNjZdIDJiZjY0IGlzIDJkMTA3MDAwIQ0K
WyAgMjE3LjQyMTQwOV0gMmJmYTQgaXMgMmQwZTUwMDAhDQpbICAyMTcuNDIzMTI3XSAyYmY2
NSBpcyAyZDBkZTAwMCENClsgIDIxNy40MjQ4NTRdIDJiZjlkIGlzIDJkMGRkMDAwIQ0KWyAg
MjE3LjQyNjU4MV0gMmJmOWUgaXMgMmQwZGMwMDAhDQpbICAyMTcuNDM4NTcwXSAyYmZhNSBp
cyAyZDBlZDAwMCENClsgIDIxNy40NDAzMzZdIDJiZmE2IGlzIDJkMGVlMDAwIQ0KWyAgMjE3
LjQ0MjA2Nl0gMmJmYTcgaXMgMmQwZWYwMDAhDQpbICAyMTcuNDQzODIyXSAyYmZhOCBpcyAy
ZDBmMDAwMCENClsgIDIxNy40NDU1NDZdIDJiZmE5IGlzIDJkMGY2MDAwIQ0KWyAgMjE3LjQ0
NzQ1OV0gMmJmYWEgaXMgMmQwZjUwMDAhDQpbICAyMTcuNDQ5MjAxXSAyYmZhYiBpcyAyZDBm
MzAwMCENClsgIDIxNy40NTA5NDRdIDJiZmFjIGlzIDJkMGY0MDAwIQ0KWyAgMjE3LjQ1NDQ0
Ml0gMmJmYzQgaXMgMmQwYzIwMDAhDQpbICAyMTcuNDU2MjA5XSAyYmZjNSBpcyAyZDBjMzAw
MCENClsgIDIxNy40NTc5NjVdIDJiZmM2IGlzIDJkMGM0MDAwIQ0KWyAgMjE3LjQ1OTcwN10g
MmJmYzcgaXMgMmQwYzUwMDAhDQpbICAyMTcuNDYxNDYwXSAyYmZjOCBpcyAyZDBjNjAwMCEN
ClsgIDIxNy40NjMyMDBdIDJiZmM5IGlzIDJkMGM3MDAwIQ0KWyAgMjE3LjQ2NDk2OF0gMmJm
Y2EgaXMgMmQwYzgwMDAhDQpbICAyMTcuNDY2NzE5XSAyYmZjYiBpcyAyZDBjOTAwMCENClsg
IDIxNy40Njg0NTFdIDJiZmNjIGlzIDJkMGNhMDAwIQ0KWyAgMjE3LjQ3MDE4N10gMmJmY2Qg
aXMgMmQwY2IwMDAhDQpbICAyMTcuNDcxODk3XSAyYmY5ZiBpcyAyZDBjYzAwMCENClsgIDIx
Ny40NzM2NDddIDJiZmEwIGlzIDJkMGNkMDAwIQ0KWyAgMjE3LjQ3NTM1Ml0gMmJmYTEgaXMg
MmQwY2UwMDAhDQpbICAyMTcuNDc3MDkzXSAyYmZhMiBpcyAyZDBjZjAwMCENClsgIDIxNy40
Nzg3OTJdIDJiZmEzIGlzIDJkMGQwMDAwIQ0KWyAgMjE3LjQ4MDUxOF0gMmJmYzMgaXMgMmQw
ZDEwMDAhDQpbICAyMTcuNDgyMjE3XSAyYmZiNyBpcyAyZDBkMjAwMCENClsgIDIxNy40ODM5
MzRdIDJiZmI2IGlzIDJkMGQzMDAwIQ0KWyAgMjE3LjQ4NTY1MF0gMmJmYjUgaXMgMmQwZDQw
MDAhDQpbICAyMTcuNDg3MzY4XSAyYmZiNCBpcyAyZDBkNTAwMCENClsgIDIxNy40ODkwNzFd
IDJiZmIzIGlzIDJkMGQ2MDAwIQ0KWyAgMjE3LjQ5MzM0M10gMmJmZDkgaXMgMmQwYTIwMDAh
DQpbICAyMTcuNDk1MTI5XSAyYmZkYSBpcyAyZDBhMzAwMCENClsgIDIxNy40OTY5NjJdIDJi
ZmRiIGlzIDJkMGE0MDAwIQ0KWyAgMjE3LjQ5ODY1OF0gMmJmZGMgaXMgMmQwYTUwMDAhDQpb
ICAyMTcuNTAwMzU1XSAyYmZkZCBpcyAyZDBhNjAwMCENClsgIDIxNy41MDIwNjVdIDJiZmRl
IGlzIDJkMGE3MDAwIQ0KWyAgMjE3LjUwMzc1M10gMmJmZGYgaXMgMmQwYTgwMDAhDQpbICAy
MTcuNTA1NDQ5XSAyYmZlMCBpcyAyZDBhOTAwMCENClsgIDIxNy41MDcxNTZdIDJiZmUxIGlz
IDJkMGFhMDAwIQ0KWyAgMjE3LjUwODg1MV0gMmJmZTIgaXMgMmQwYWIwMDAhDQpbICAyMTcu
NTEwOTU3XSAyYmZiMiBpcyAyZDA5NzAwMCENClsgIDIxNy41MTI2NDFdIDJiZmIxIGlzIDJk
MDk4MDAwIQ0KWyAgMjE3LjUxNDM0OV0gMmJmYjAgaXMgMmQwOTkwMDAhDQpbICAyMTcuNTE2
MDEyXSAyYmZhZiBpcyAyZDA5YTAwMCENClsgIDIxNy41MTc2OTJdIDJiZmFlIGlzIDJkMDli
MDAwIQ0KWyAgMjE3LjUxOTM2Ml0gMmJmYWQgaXMgMmQwOWMwMDAhDQpbICAyMTcuNTIxMDQ1
XSAyYmZiYyBpcyAyZDA5ZDAwMCENClsgIDIxNy41MjI3MjhdIDJiZmJiIGlzIDJkMDllMDAw
IQ0KWyAgMjE3LjUyNDQwNV0gMmJmYmEgaXMgMmQwOWYwMDAhDQpbICAyMTcuNTI2MDgwXSAy
YmZiOSBpcyAyZDBhMDAwMCENClsgIDIxNy41Mjc3NzVdIDJiZmI4IGlzIDJkMGExMDAwIQ0K
WyAgMjE3LjUyOTQ1OF0gMmJmZTMgaXMgMmQwOGMwMDAhDQpbICAyMTcuNTMxMTU3XSAyYmZi
ZCBpcyAyZDA4ZDAwMCENClsgIDIxNy41MzI4MjldIDJiZmJlIGlzIDJkMDhlMDAwIQ0KWyAg
MjE3LjUzNDUxNV0gMmJmYmYgaXMgMmQwOGYwMDAhDQpbICAyMTcuNTM2MjA1XSAyYmZjMCBp
cyAyZDA5MDAwMCENClsgIDIxNy41Mzc4OTNdIDJiZmMxIGlzIDJkMDkxMDAwIQ0KWyAgMjE3
LjUzOTU4M10gMmJmYzIgaXMgMmQwOTIwMDAhDQpbICAyMTcuNTQxMjY1XSAyYjgwMSBpcyAy
ZDA5MzAwMCENClsgIDIxNy41NDI5NjRdIDJiODAyIGlzIDJkMDk0MDAwIQ0KWyAgMjE3LjU0
NDY1N10gMmI4MDMgaXMgMmQwOTUwMDAhDQpbICAyMTcuNTQ2MzM1XSAyYjgwNCBpcyAyZDA5
NjAwMCENClsgIDIxNy41NDgwMjhdIDJiODA1IGlzIDJkMDgyMDAwIQ0KWyAgMjE3LjU0OTY5
Nl0gMmI4MDYgaXMgMmQwODMwMDAhDQpbICAyMTcuNTUxMzkyXSAyYjgwNyBpcyAyZDA4NDAw
MCENClsgIDIxNy41NTMwNThdIDJiODA4IGlzIDJkMDg1MDAwIQ0KWyAgMjE3LjU1NDczM10g
MmI4MDkgaXMgMmQwODYwMDAhDQpbICAyMTcuNTU2NDE2XSAyYjgwYSBpcyAyZDA4NzAwMCEN
ClsgIDIxNy41NTgwOTldIDJiODBiIGlzIDJkMDg4MDAwIQ0KWyAgMjE3LjU1OTc3NF0gMmI4
MGMgaXMgMmQwODkwMDAhDQpbICAyMTcuNTYxNDUwXSAyYjgwZCBpcyAyZDA4YTAwMCENClsg
IDIxNy41NjMxMjNdIDJiODBlIGlzIDJkMDhiMDAwIQ0KWyAgMjE3LjU2NDgxOV0gMmJmY2Ug
aXMgMmQwYWMwMDAhDQpbICAyMTcuNTY2NDk4XSAyYmZjZiBpcyAyZDBhZDAwMCENClsgIDIx
Ny41NjgyMTNdIDJiZmQwIGlzIDJkMGFlMDAwIQ0KWyAgMjE3LjU2OTg5OF0gMmJmZDEgaXMg
MmQwYWYwMDAhDQpbICAyMTcuNTcxNjAzXSAyYmZkMiBpcyAyZDBiMDAwMCENClsgIDIxNy41
NzMzMjddIDJiZmQzIGlzIDJkMGIxMDAwIQ0KWyAgMjE3LjU3NTAzN10gMmJmZDQgaXMgMmQw
YjIwMDAhDQpbICAyMTcuNTc2NzYwXSAyYmZkNSBpcyAyZDBiMzAwMCENClsgIDIxNy41Nzg0
NDldIDJiZmQ2IGlzIDJkMGI0MDAwIQ0KWyAgMjE3LjU4MDE0OF0gMmJmZDcgaXMgMmQwYjUw
MDAhDQpbICAyMTcuNTgxODQ5XSAyYmZkOCBpcyAyZDBiWyAgMjE5LjcwOTEwNl0gMmI0ZDUg
aXMgMmQyMjkwMDAhDQpbICAyMTkuNzEwODEzXSAyYjRkNCBpcyAyZDIyYTAwMCENClsgIDIx
OS43MTI5NjFdIDJiNGI1IGlzIDJkMjBiMDAwIQ0KWyAgMjE5LjcxNDcxNF0gMmI0YjYgaXMg
MmQyMGMwMDAhDQpbICAyMTkuNzE2NDIwXSAyYjRiNyBpcyAyZDIwZDAwMCENClsgIDIxOS43
MTgxMzldIDJiNGI4IGlzIDJkMjBlMDAwIQ0KWyAgMjE5LjcxOTg2MF0gMmI0YjkgaXMgMmQy
MGYwMDAhDQpbICAyMTkuNzIxNTY4XSAyYjRiYSBpcyAyZDIxMDAwMCENClsgIDIxOS43MjMy
ODRdIDJiNGJiIGlzIDJkMjExMDAwIQ0KWyAgMjE5LjcyNDk5MF0gMmI0YmMgaXMgMmQyMTIw
MDAhDQpbICAyMTkuNzI2Njg5XSAyYjRiZCBpcyAyZDIxMzAwMCENClsgIDIxOS43Mjg0MTdd
IDJiNGJlIGlzIDJkMjE0MDAwIQ0KWyAgMjE5LjczMDEyMl0gMmI0Y2EgaXMgMmQxZjUwMDAh
DQpbICAyMTkuNzMxODM5XSAyYjRjYiBpcyAyZDFmNjAwMCENClsgIDIxOS43MzM1NTVdIDJi
NGNjIGlzIDJkMWY3MDAwIQ0KWyAgMjE5LjczNTI2Ml0gMmI0Y2QgaXMgMmQxZjgwMDAhDQpb
ICAyMTkuNzM2OTYxXSAyYjRlZCBpcyAyZDFmOTAwMCENClsgIDIxOS43Mzg2MzddIDJiNGYw
IGlzIDJkMWZhMDAwIQ0KWyAgMjE5Ljc0MDM1M10gMmI0ZjEgaXMgMmQxZmIwMDAhDQpbICAy
MTkuNzQyMDM2XSAyYjRmMiBpcyAyZDFmYzAwMCENClsgIDIxOS43NDM3NDVdIDJiNGYzIGlz
IDJkMWZkMDAwIQ0KWyAgMjE5Ljc0NTQyNl0gMmI0ZjQgaXMgMmQxZmUwMDAhDQpbICAyMTku
NzQ3MTE5XSAyYjRmNSBpcyAyZDFmZjAwMCENClsgIDIxOS43NDg4MTFdIDJiNGY2IGlzIDJk
MWViMDAwIQ0KWyAgMjE5Ljc1MDQ5OF0gMmI0ZjcgaXMgMmQxZWMwMDAhDQpbICAyMTkuNzUy
MTkzXSAyYjRmOCBpcyAyZDFlZDAwMCENClsgIDIxOS43NTM4NzldIDJiNGY5IGlzIDJkMWVl
MDAwIQ0KWyAgMjE5Ljc1NTUzOV0gMmI0ZmEgaXMgMmQxZWYwMDAhDQpbICAyMTkuNzU3MjI0
XSAyYjRmYiBpcyAyZDFmMDAwMCENClsgIDIxOS43NTg4ODVdIDJiNGZjIGlzIDJkMWYxMDAw
IQ0KWyAgMjE5Ljc2MDU4NF0gMmI0ZmQgaXMgMmQxZjIwMDAhDQpbICAyMTkuNzYyMjUxXSAy
YjRmZSBpcyAyZDFmMzAwMCENClsgIDIxOS43NjM5MzddIDJiNGZmIGlzIDJkMWY0MDAwIQ0K
WyAgMjE5Ljc2NTY4MV0gMmI0YmYgaXMgMmQyMDAwMDAhDQpbICAyMTkuNzY3MzY0XSAyYjRj
MCBpcyAyZDIwMTAwMCENClsgIDIxOS43NjkwNTRdIDJiNGMxIGlzIDJkMjAyMDAwIQ0KWyAg
MjE5Ljc3MDczNV0gMmI0YzIgaXMgMmQyMDMwMDAhDQpbICAyMTkuNzcyNDA3XSAyYjRjMyBp
cyAyZDIwNDAwMCENClsgIDIxOS43NzQxMTFdIDJiNGM0IGlzIDJkMjA1MDAwIQ0KWyAgMjE5
Ljc3NTc3N10gMmI0YzUgaXMgMmQyMDYwMDAhDQpbICAyMTkuNzc3NDc1XSAyYjRjNiBpcyAy
ZDIwNzAwMCENClsgIDIxOS43NzkxMzZdIDJiNGM3IGlzIDJkMjA4MDAwIQ0KWyAgMjE5Ljc4
MDgxMV0gMmI0YzggaXMgMmQyMDkwMDAhDQpbICAyMTkuNzgyNTMzXSAyYjRjOSBpcyAyZDIw
YTAwMCENClsgIDIxOS43ODQyMThdIDJiNGFmIGlzIDJkMjE1MDAwIQ0KWyAgMjE5Ljc4NTg5
MF0gMmI0YjAgaXMgMmQyMTYwMDAhDQpbICAyMTkuNzg3NTY1XSAyYjRiMSBpcyAyZDIxNzAw
MCENClsgIDIxOS43ODkyMjddIDJiNGIyIGlzIDJkMjE4MDAwIQ0KWyAgMjE5Ljc5MDk0OF0g
MmI0YjMgaXMgMmQyMTkwMDAhDQpbICAyMTkuNzkyNjE2XSAyYjRiNCBpcyAyZDIxYTAwMCEN
ClsgIDIxOS43OTQzMDddIDJiNGUzIGlzIDJkMjFiMDAwIQ0KWyAgMjE5Ljc5NTk3NF0gMmI0
ZTIgaXMgMmQyMWMwMDAhDQpbICAyMTkuNzk3NjY5XSAyYjRlMSBpcyAyZDIxZDAwMCENClsg
IDIxOS43OTkzMzZdIDJiNGUwIGlzIDJkMjFlMDAwIQ0KWyAgMjE5LjgwMTAxNl0gMmI0ZGYg
aXMgMmQyMWYwMDAhDQpbICAyMTkuODE5NDk1XSAzN2U4YSBpcyAyZDFlMDAwMCENClsgIDIx
OS44MjEyOTVdIDM2ZGY5IGlzIDJkMWUxMDAwIQ0KWyAgMjE5LjgyMzA0N10gMzdmOTcgaXMg
MmQxZTIwMDAhDQpbICAyMTkuODI0ODEyXSAyYjUwMCBpcyAyZDFlMzAwMCENClsgIDIxOS44
MjY1ODhdIDJiNTAxIGlzIDJkMWU0MDAwIQ0KWyAgMjE5LjgyODM4OV0gMmI1MDIgaXMgMmQx
ZTUwMDAhDQpbICAyMTkuODMwMjcyXSAyYjUwMyBpcyAyZDFlNjAwMCENClsgIDIxOS44MzIx
NDBdIDJiNTA0IGlzIDJkMWU3MDAwIQ0KWyAgMjE5LjgzMzkzM10gMmI1MDUgaXMgMmQxZTgw
MDAhDQpbICAyMTkuODM1NzIzXSAyYjUwNiBpcyAyZDFlOTAwMCENClsgIDIxOS44Mzc0OTld
IDJiNTA3IGlzIDJkMWVhMDAwIQ0KWyAgMjE5LjgzOTY4NF0gMmI1MTMgaXMgMmQxY2IwMDAh
DQpbICAyMTkuODQxNDk3XSAyYjUxNCBpcyAyZDFjYzAwMCENClsgIDIxOS44NDMyNjddIDJi
NTE1IGlzIDJkMWNkMDAwIQ0KWyAgMjE5Ljg0NTA4N10gMmI1MTYgaXMgMmQxY2UwMDAhDQpb
ICAyMTkuODQ2ODY3XSAyYjUxNyBpcyAyZDFjZjAwMCENClsgIDIxOS44NDg2NDVdIDJiNTE4
IGlzIDJkMWQwMDAwIQ0KWyAgMjE5Ljg1MDQyN10gMmI1MTkgaXMgMmQxZDEwMDAhDQpbICAy
MTkuODUyMjIxXSAyYjUxYSBpcyAyZDFkMjAwMCENClsgIDIxOS44NTM5OTddIDJiNTFiIGlz
IDJkMWQzMDAwIQ0KWyAgMjE5Ljg1NTc1M10gMmI1MWMgaXMgMmQxZDQwMDAhDQpbICAyMTku
ODU3NTQ3XSAyYjUxZCBpcyAyZDFjMDAwMCENClsgIDIxOS44NTkyOTFdIDJiNTFlIGlzIDJk
MWMxMDAwIQ0KWyAgMjE5Ljg2MTA4MF0gMmI1MWYgaXMgMmQxYzIwMDAhDQpbICAyMTkuODYy
ODMxXSAyYjUyMCBpcyAyZDFjMzAwMCENClsgIDIxOS44NjQ2MjddIDJiNTIxIGlzIDJkMWM0
MDAwIQ0KWyAgMjE5Ljg2NjM3OF0gMmI1MjIgaXMgMmQxYzUwMDAhDQpbICAyMTkuODY4MTQz
XSAyYjUyMyBpcyAyZDFjNjAwMCENClsgIDIxOS44Njk5MjBdIDJiNTI0IGlzIDJkMWM3MDAw
IQ0KWyAgMjE5Ljg3MTY3Nl0gMmI1MjUgaXMgMmQxYzgwMDAhDQpbICAyMTkuODczNDY1XSAy
YjUyNiBpcyAyZDFjOTAwMCENClsgIDIxOS44NzUyMDFdIDJiNTI3IGlzIDJkMWNhMDAwIQ0K
WyAgMjE5Ljg3NjkzN10gMmI1MjggaXMgMmQxYjUwMDAhDQpbICAyMTkuODc4NjI2XSAyYjUy
OSBpcyAyZDFiNjAwMCENClsgIDIxOS44ODAzMTNdIDJiNTJhIGlzIDJkMWI3MDAwIQ0KWyAg
MjE5Ljg4MTk5M10gMmI1MmIgaXMgMmQxYjgwMDAhDQpbICAyMTkuODgzNjU3XSAyYjUyYyBp
cyAyZDFiOTAwMCENClsgIDIxOS44ODUzMzddIDJiNTJkIGlzIDJkMWJhMDAwIQ0KWyAgMjE5
Ljg4Njk5Nl0gMmI1MmUgaXMgMmQxYmIwMDAhDQpbICAyMTkuODg4NjQwXSAyYjUyZiBpcyAy
ZDFiYzAwMCENClsgIDIxOS44OTAzMjNdIDJiNTMwIGlzIDJkMWJkMDAwIQ0KWyAgMjE5Ljg5
MTk4NF0gMmI1MzEgaXMgMmQxYmUwMDAhDQpbICAyMTkuODkzNjg0XSAyYjUzMiBpcyAyZDFi
ZjAwMCENClsgIDIxOS44OTUzMjNdIDJiNTA4IGlzIDJkMWQ1MDAwIQ0KWyAgMjE5Ljg5Njk4
MV0gMmI1MDkgaXMgMmQxZDYwMDAhDQpbICAyMTkuODk4NjU2XSAyYjUwYSBpcyAyZDFkNzAw
MCENClsgIDIxOS45MDAzMjZdIDJiNTBiIGlzIDJkMWQ4MDAwIQ0KWyAgMjE5LjkwMjAxOF0g
MmI1MGMgaXMgMmQxZDkwMDAhDQpbICAyMTkuOTAzNjk0XSAyYjUwZCBpcyAyZDFkYTAwMCEN
ClsgIDIxOS45MDUzNDldIDJiNTBlIGlzIDJkMWRiMDAwIQ0KWyAgMjE5LjkwNzA1MF0gMmI1
MGYgaXMgMmQxZGMwMDAhDQpbICAyMTkuOTA4NzExXSAyYjUxMCBpcyAyZDFkZDAwMCENClsg
IDIxOS45MTA0MThdIDJiNTExIGlzIDJkMWRlMDAwIQ0KWyAgMjE5LjkxMjA3OV0gMmI1MTIg
aXMgMmQxZGYwMDAhDQpbICAyMTkuOTE1NTkzXSAyYjRlNSBpcyAyZDE5NjAwMCENClsgIDIx
OS45MTczNDhdIDJiNGU2IGlzIDJkMTk3MDAwIQ0KWyAgMjE5LjkxOTEwM10gMmI0ZTcgaXMg
MmQxOTgwMDAhDQpbICAyMTkuOTIwNzk2XSAyYjRlOCBpcyAyZDE5OTAwMCENClsgIDIxOS45
MjI1MDFdIDJiNGU5IGlzIDJkMTlhMDAwIQ0KWyAgMjE5LjkyNDE5OV0gMmI0ZWEgaXMgMmQx
OWIwMDAhDQpbICAyMTkuOTI1OTI4XSAyYjRlYiBpcyAyZDE5YzAwMCENClsgIDIxOS45Mjc3
MTNdIDJiNGVjIGlzIDJkMTlkMDAwIQ0KWyAgMjE5LjkyOTQxMl0gMmI1NGMgaXMgMmQxOWUw
MDAhDQpbICAyMTkuOTMxMTE5XSAyYjU0ZCBpcyAyZDE5ZjAwMCENClsgIDIxOS45MzI3ODRd
IDJiNTRlIGlzIDJkMThiMDAwIQ0KWyAgMjE5LjkzNDQ3OF0gMmI1NGYgaXMgMmQxOGMwMDAh
DQpbICAyMTkuOTM2MTU4XSAyYjU1MCBpcyAyZDE4ZDAwMCENClsgIDIxOS45Mzc4NTJdIDJi
NTUxIGlzIDJkMThlMDAwIQ0KWyAgMjE5LjkzOTUzMl0gMmI1NTIgaXMgMmQxOGYwMDAhDQpb
ICAyMTkuOTQxMjE1XSAyYjU1MyBpcyAyZDE5MDAwMCENClsgIDIxOS45NDI4OTJdIDJiNTU0
IGlzIDJkMTkxMDAwIQ0KWyAgMjE5Ljk0NDYwNF0gMmI1NTUgaXMgMmQxOTIwMDAhDQpbICAy
MTkuOTQ2MjY4XSAyYjU1NiBpcyAyZDE5MzAwMCENClsgIDIxOS45NDc5NjddIDJiNTU3IGlz
IDJkMTk0MDAwIQ0KWyAgMjE5Ljk1MDAwMV0gMmI0ZTQgaXMgMmQ5NmIwMDAhDQpbICAyMTku
OTUxNzcyXSAyYjUzMyBpcyAyZDk4MDAwMCENClsgIDIxOS45NTM1MDhdIDJiNTM0IGlzIDJk
OTgxMDAwIQ0KWyAgMjE5Ljk1NTIyMl0gMmI1MzUgaXMgMmQ5ODIwMDAhDQpbICAyMTkuOTU2
OTY0XSAyYjUzNiBpcyAyZDk4MzAwMCENClsgIDIxOS45NTg2NzNdIDJiNTM3IGlzIDJkOTg0
MDAwIQ0KWyAgMjE5Ljk2MDQxNV0gMmI1MzggaXMgMmQxODUwMDAhDQpbICAyMTkuOTYyMTQz
XSAyYjUzOSBpcyAyZDE4NjAwMCENClsgIDIxOS45NjM4ODFdIDJiNTNhIGlzIDJkMTg3MDAw
IQ0KWyAgMjE5Ljk2NTYyMF0gMmI1M2IgaXMgMmQxODgwMDAhDQpbICAyMTkuOTY3MzQzXSAy
YjUzYyBpcyAyZDE4OTAwMCENClsgIDIxOS45NjkwOThdIDJiNTNkIGlzIDJkMThhMDAwIQ0K
WyAgMjE5Ljk3MDc5Nl0gMmI1NTggaXMgMmQ5NzgwMDAhDQpbICAyMTkuOTcyNTIzXSAyYjU1
OSBpcyAyZDk3OTAwMCENClsgIDIxOS45NzQyMzhdIDJiNTVhIGlzIDJkOTdhMDAwIQ0KWyAg
MjE5Ljk3NTkzM10gMmI1NWIgaXMgMmQ5N2IwMDAhDQpbICAyMTkuOTc3NjYzXSAyYjU1YyBp
cyAyZDk3YzAwMCENClsgIDIxOS45NzkzNDddIDJiNTVkIGlzIDJkOTdkMDAwIQ0KWyAgMjE5
Ljk4MTA3MF0gMmI1NWUgaXMgMmQ5N2UwMDAhDQpbICAyMTkuOTgyNzYwXSAyYjU1ZiBpcyAy
ZDk3ZjAwMCENClsgIDIxOS45ODQ0NThdIDJiNTZiIGlzIDJkOTZjMDAwIQ0KWyAgMjE5Ljk4
NjE3N10gMmI1NjAgaXMgMmQ5NmQwMDAhDQpbICAyMTkuOTg3ODgyXSAyYjU2MSBpcyAyZDk2
ZTAwMCENClsgIDIxOS45ODk1OThdIDJiNTYyIGlzIDJkOTZmMDAwIQ0KWyAgMjE5Ljk5MTMw
MV0gMmI1NjMgaXMgMmQ5NzAwMDAhDQpbICAyMTkuOTkzMDA4XSAyYjU2NCBpcyAyZDk3MTAw
MCENClsgIDIxOS45OTQ3NTVdIDJiNTY1IGlzIDJkOTcyMDAwIQ0KWyAgMjE5Ljk5NjQ1MF0g
MmI1NjYgaXMgMmQ5NzMwMDAhDQpbICAyMTkuOTk4MTgwXSAyYjU2NyBpcyAyZDk3NDAwMCEN
ClsgIDIxOS45OTk4NjRdIDJiNTY4IGlzIDJkOTc1MDAwIQ0KWyAgMjIwLjAwMTU4Nl0gMmI1
NjkgaXMgMmQ5NzYwMDAhDQpbICAyMjAuMDAzMzAwXSAyYjU2YSBpcyAyZDk3NzAwMCENClsg
IDIyMC4wMDU1MzJdIDJiNTNmIGlzIDJkOTY3MDAwIQ0KWyAgMjIwLjAwNzMxNV0gMmI1NDAg
aXMgMmQ5NjgwMDAhDQpbICAyMjAuMDA5MDE3XSAyYjU0MSBpcyAyZDk2OTAwMCENClsgIDIy
MC4wMTA3NDVdIDJiNTQyIGlzIDJkOTZhMDAwIQ0KWyAgMjIwLjAxMzg5NV0gMmI1NDMgaXMg
MmQ5NWYwMDAhDQpbICAyMjAuMDE1NTg1XSAyYjU0NCBpcyAyZDk2MDAwMCENClsgIDIyMC4w
MTcyNzhdIDJiNTQ1IGlzIDJkOTYxMDAwIQ0KWyAgMjIwLjAxODk5MV0gMmI1NDYgaXMgMmQ5
NjIwMDAhDQpbICAyMjAuMDIwNjg1XSAyYjU0NyBpcyAyZDk2MzAwMCENClsgIDIyMC4wMjIz
OTRdIDJiNTQ4IGlzIDJkOTY0MDAwIQ0KWyAgMjIwLjAyNDA5OV0gMmI1NDkgaXMgMmQ5NjUw
MDAhDQpbICAyMjAuMDI1Nzc4XSAyYjU0YSBpcyAyZDk2NjAwMCENClsgIDIyMC4wMjgyNjFd
IDJiNTc2IGlzIDJkOTRmMDAwIQ0KWyAgMjIwLjAyOTk1NF0gMmI1NzcgaXMgMmQ5NTAwMDAh
DQpbICAyMjAuMDMxNjYwXSAyYjU3OCBpcyAyZDk1MTAwMCENClsgIDIyMC4wMzMzNDBdIDJi
NTc5IGlzIDJkOTUyMDAwIQ0KWyAgMjIwLjAzNTA0OF0gMmI1N2EgaXMgMmQ5NTMwMDAhDQpb
ICAyMjAuMDM4NDc1XSAyYjU3YyBpcyAyZDkzOTAwMCENClsgIDIyMC4wNDAyNDBdIDJiNTdk
IGlzIDJkOTNhMDAwIQ0KWyAgMjIwLjA0MTk1OV0gMmI1N2UgaXMgMmQ5M2IwMDAhDQpbICAy
MjAuMDQzNzA0XSAyYjU3ZiBpcyAyZDkzYzAwMCENClsgIDIyMC4wNDUzNzddIDJiNTgwIGlz
IDJkOTNkMDAwIQ0KWyAgMjIwLjA0NzA3Ml0gMmI1ODEgaXMgMmQ5M2UwMDAhDQpbICAyMjAu
MDQ4NzYxXSAyYjU4MiBpcyAyZDkzZjAwMCENClsgIDIyMC4wNTA0NDBdIDJiNTgzIGlzIDJk
OTQwMDAwIQ0KWyAgMjIwLjA1MjEzNl0gMmI1ODQgaXMgMmQ5NDEwMDAhDQpbICAyMjAuMDUz
ODMwXSAyYjU4NSBpcyAyZDk0MjAwMCENClsgIDIyMC4wNTU1MjJdIDJiNTg2IGlzIDJkOTQz
MDAwIQ0KWyAgMjIwLjA1NzY0MF0gMmI1OTEgaXMgMmQ5MTkwMDAhDQpbICAyMjAuMDU5MzUx
XSAyYjU5MiBpcyAyZDkxYTAwMCENClsgIDIyMC4wNjEwODRdIDJiNTkzIGlzIDJkOTFiMDAw
IQ0KWyAgMjIwLjA2Mjc4NF0gMmI1OTQgaXMgMmQ5MWMwMDAhDQpbICAyMjAuMDY0NTAzXSAy
YjU5NSBpcyAyZDkxZDAwMCENClsgIDIyMC4wNjYxNzBdIDJiNTk2IGlzIDJkOTFlMDAwIQ0K
WyAgMjIwLjA2Nzg1M10gMmI1OTcgaXMgMmQ5MWYwMDAhDQpbICAyMjAuMDY5NTU3XSAyYjU5
OCBpcyAyZDkyMDAwMCENClsgIDIyMC4wNzEyMzRdIDJiNTk5IGlzIDJkOTIxMDAwIQ0KWyAg
MjIwLjA3MjkyNF0gMmI1OWEgaXMgMmQ5MjIwMDAhDQpbICAyMjAuMDc0NjAwXSAyYjU5YiBp
cyAyZDkyMzAwMCENClsgIDIyMC4wNzYyNThdIDJiNTljIGlzIDJkOTBmMDAwIQ0KWyAgMjIw
LjA3Nzk2MV0gMmI1OWQgaXMgMmQ5MTAwMDAhDQpbICAyMjAuMDc5NjI1XSAyYjU5ZSBpcyAy
ZDkxMTAwMCENClsgIDIyMC4wODEzMzldIDJiNTlmIGlzIDJkOTEyMDAwIQ0KWyAgMjIwLjA4
MzAxNF0gMmI1YTAgaXMgMmQ5MTMwMDAhDQpbICAyMjAuMDg0NzI5XSAyYjVhMSBpcyAyZDkx
NDAwMCENClsgIDIyMC4wODYzOTNdIDJiNWEyIGlzIDJkOTE1MDAwIQ0KWyAgMjIwLjA4ODA3
M10gMmI1YTMgaXMgMmQ5MTYwMDAhDQpbICAyMjAuMDg5NzYzXSAyYjVhNCBpcyAyZDkxNzAw
MCENClsgIDIyMC4wOTE0MzJdIDJiNWE1IGlzIDJkOTE4MDAwIQ0KWyAgMjIwLjA5MzExMl0g
MmI1M2UgaXMgMmQ5MjQwMDAhDQpbICAyMjAuMDk0NzgyXSAyYjU2YyBpcyAyZDkyNTAwMCEN
ClsgIDIyMC4wOTY0NDRdIDJiNTZkIGlzIDJkOTI2MDAwIQ0KWyAgMjIwLjA5ODEzOV0gMmI1
NmUgaXMgMmQ5MjcwMDAhDQpbICAyMjAuMDk5Nzg5XSAyYjU2ZiBpcyAyZDkyODAwMCENClsg
IDIyMC4xMDE0NzddIDJiNTcwIGlzIDJkOTI5MDAwIQ0KWyAgMjIwLjEwMzE0NF0gMmI1NzEg
aXMgMmQ5MmEwMDAhDQpbICAyMjAuMTA0ODEzXSAyYjU3MiBpcyAyZDkyYjAwMCENClsgIDIy
MC4xMDY0OTRdIDJiNTczIGlzIDJkOTJjMDAwIQ0KWyAgMjIwLjEwODE2OV0gMmI1NzQgaXMg
MmQ5MmQwMDAhDQpbICAyMjAuMTA5ODU2XSAyYjU3NSBpcyAyZDkyZTAwMCENClsgIDIyMC4x
MTE1MjBdIDJiNTg3IGlzIDJkOTJmMDAwIQ0KWyAgMjIwLjExMzE4MV0gMmI1ODggaXMgMmQ5
MzAwMDAhDQpbICAyMjAuMTE0ODgxXSAyYjU4OSBpcyAyZDkzMTAwMCENClsgIDIyMC4xMTY1
NDJdIDJiNThhIGlzIDJkOTMyMDAwIQ0KWyAgMjIwLjExODI0NF0gMmI1OGIgaXMgMmQ5MzMw
MDAhDQpbICAyMjAuMTE5ODk4XSAyYjU4YyBpcyAyZDkzNDAwMCENClsgIDIyMC4xMjE1Njhd
IDJiNThkIGlzIDJkOTM1MDAwIQ0KWyAgMjIwLjEyMzI0OF0gMmI1OGUgaXMgMmQ5MzYwMDAh
DQpbICAyMjAuMTI0OTA1XSAyYjU4ZiBpcyAyZDkzNzAwMCENClsgIDIyMC4xMjY1NzldIDJi
NTkwIGlzIDJkOTM4MDAwIQ0KWyAgMjIwLjEyOTg2OF0gMmI1YjEgaXMgMmQ4ZjkwMDAhDQpb
ICAyMjAuMTMxNzIwXSAyYjViMiBpcyAyZDhmYTAwMCENClsgIDIyMC4xMzM0MzNdIDJiNWIz
IGlzIDJkOGZiMDAwIQ0KWyAgMjIwLjEzNTEzN10gMmI1YjQgaXMgMmQ4ZmMwMDAhDQpbICAy
MjAuMTM2ODE5XSAyYjViNSBpcyAyZDhmZDAwMCENClsgIDIyMC4xMzg0OTBdIDJiNWI2IGlz
IDJkOGZlMDAwIQ0KWyAgMjIwLjE0MDE5NV0gMmI1YjcgaXMgMmQ4ZmYwMDAhDQpbICAyMjAu
MTQxODU2XSAyYjViOCBpcyAyZDkwMDAwMCENClsgIDIyMC4xNDM1NzJdIDJiNWI5IGlzIDJk
OTAxMDAwIQ0KWyAgMjIwLjE0NTI1N10gMmI1YmEgaXMgMmQ5MDIwMDAhDQpbICAyMjAuMTQ2
OTQ0XSAyYjViYiBpcyAyZDkwMzAwMCENClsgIDIyMC4xNDg2NDVdIDJiNWJjIGlzIDJkOGVm
MDAwIQ0KWyAgMjIwLjE1MDM0MV0gMmI1YmQgaXMgMmQ4ZjAwMDAhDQpbICAyMjAuMTUyMDI5
XSAyYjViZSBpcyAyZDhmMTAwMCENClsgIDIyMC4xNTM3MTZdIDJiNWJmIGlzIDJkOGYyMDAw
IQ0KWyAgMjIwLjE1NTQwOV0gMmI1YzAgaXMgMmQ4ZjMwMDAhDQpbICAyMjAuMTU3MDg5XSAy
YjVjMSBpcyAyZDhmNDAwMCENClsgIDIyMC4xNTg3NTFdIDJiNWMyIGlzIDJkOGY1MDAwIQ0K
WyAgMjIwLjE2MDQ0Ml0gMmI1YzMgaXMgMmQ4ZjYwMDAhDQpbICAyMjAuMTYyMTA5XSAyYjVj
NCBpcyAyZDhmNzAwMCENClsgIDIyMC4xNjM4MDRdIDJiNWM1IGlzIDJkOGY4MDAwIQ0KWyAg
MjIwLjE2NzE0OV0gMmI1ZGEgaXMgMmQ4YWYwMDAhDQpbICAyMjAuMTY4OTIwXSAyYjVkOSBp
cyAyZDhiMDAwMCENClsgIDIyMC4xNzA2MDVdIDJiNWQ4IGlzIDJkOGIxMDAwIQ0KWyAgMjIw
LjE3MjI5N10gMmI1ZDcgaXMgMmQ4YjIwMDAhDQpbICAyMjAuMTczOTk3XSAyYjVkNiBpcyAy
ZDhiMzAwMCENClsgIDIyMC4xNzU2NzBdIDJiNWQ1IGlzIDJkOGI0MDAwIQ0KWyAgMjIwLjE3
NzM3NF0gMmI1ZDQgaXMgMmQ4YjUwMDAhDQpbICAyMjAuMTc5MDQwXSAyYjVkMyBpcyAyZDhi
NjAwMCENClsgIDIyMC4xODA3NDNdIDJiNWQyIGlzIDJkOGI3MDAwIQ0KWyAgMjIwLjE4MjQx
Nl0gMmI1ZDEgaXMgMmQ4YjgwMDAhDQpbICAyMjAuMTg0MDk4XSAyYjVkMCBpcyAyZDhiOTAw
MCENClsgIDIyMC4xODU3NjRdIDJiNWNmIGlzIDJkOGJhMDAwIQ0KWyAgMjIwLjE4NzQyOF0g
MmI1Y2UgaXMgMmQ4YmIwMDAhDQpbICAyMjAuMTg5MDk1XSAyYjVjZCBpcyAyZDhiYzAwMCEN
ClsgIDIyMC4xOTA3NjRdIDJiNWNjIGlzIDJkOGJkMDAwIQ0KWyAgMjIwLjE5MjQyNV0gMmI1
Y2IgaXMgMmQ4YmUwMDAhDQpbICAyMjAuMTk0MTE3XSAyYjVjYSBpcyAyZDhiZjAwMCENClsg
IDIyMC4xOTU3NzhdIDJiNWM5IGlzIDJkOGMwMDAwIQ0KWyAgMjIwLjE5NzQ2NV0gMmI1Yzgg
aXMgMmQ4YzEwMDAhDQpbICAyMjAuMTk5MTE5XSAyYjVjNyBpcyAyZDhjMjAwMCENClsgIDIy
MC4yMDA3ODhdIDJiNWM2IGlzIDJkOGMzMDAwIQ0KWyAgMjIwLjIwNDA1N10gMmI1YTYgaXMg
MmQ4ODQwMDAhDQpbICAyMjAuMjA1NzkyXSAyYjVhNyBpcyAyZDg4NTAwMCENClsgIDIyMC4y
MDc1MDNdIDJiNWE4IGlzIDJkODg2MDAwIQ0KWyAgMjIwLjIwOTE5OF0gMmI1YTkgaXMgMmQ4
ODcwMDAhDQpbICAyMjAuMjEwOTA5XSAyYjVhYSBpcyAyZDg4ODAwMCENClsgIDIyMC4yMTI1
ODJdIDJiNWFiIGlzIDJkODg5MDAwIQ0KWyAgMjIwLjIxNDMxNV0gMmI1YWMgaXMgMmQ4OGEw
MDAhDQpbICAyMjAuMjE1OTk0XSAyYjVhZCBpcyAyZDg4YjAwMCENClsgIDIyMC4yMTc2NzVd
IDJiNWFlIGlzIDJkODhbICAyMjIuMzUyOTQxXSAyYjEwZiBpcyAyZGNmMzAwMCENClsgIDIy
Mi4zNTUwODddIDJiMTEwIGlzIDJkY2YyMDAwIQ0KWyAgMjIyLjM2MDE4MV0gMmIxMTEgaXMg
MmRjZjEwMDAhDQpbICAyMjIuMzYyMzUyXSAyYjExMiBpcyAyZGNmMDAwMCENClsgIDIyMi4z
NzM0MTJdIDJiMTEzIGlzIDJkY2VmMDAwIQ0KWyAgMjIyLjM3NTU1OV0gMmIxMTQgaXMgMmRj
ZWUwMDAhDQpbICAyMjIuMzc4ODg0XSAyYjExNSBpcyAyZGNlZDAwMCENClsgIDIyMi4zODEw
MDRdIDJiMTE2IGlzIDJkY2VjMDAwIQ0KWyAgMjIyLjM5MDg5Nl0gMmIxMzYgaXMgMmRjZWIw
MDAhDQpbICAyMjIuMzkzMDY2XSAyYjExYiBpcyAyZGNlYTAwMCENClsgIDIyMi40MDM4ODhd
IDJiMTM3IGlzIDJkY2U5MDAwIQ0KWyAgMjIyLjQwNjA3OV0gMmIxMzggaXMgMmRjZTgwMDAh
DQpbICAyMjIuNDE3MjcwXSAyYjEzOSBpcyAyZGNlNzAwMCENClsgIDIyMi40MTk1NTFdIDJi
MTFjIGlzIDJkY2U2MDAwIQ0KWyAgMjIyLjQyMTY3OF0gMmIxM2IgaXMgMmRjZTUwMDAhDQpb
ICAyMjIuNDI1MjA3XSAyYjEzYyBpcyAyZGNiZTAwMCENClsgIDIyMi40Mjc0MjJdIDJiMTNk
IGlzIDJkY2JmMDAwIQ0KWyAgMjIyLjQyOTU5OV0gMmIxMWQgaXMgMmRjYzAwMDAhDQpbICAy
MjIuNDMyMDEzXSAyYjExZSBpcyAyZGNjMTAwMCENClsgIDIyMi40MzQyOThdIDJiMTFmIGlz
IDJkY2MyMDAwIQ0KWyAgMjIyLjQzNjQ0M10gMmIxMjAgaXMgMmRjYzkwMDAhDQpbICAyMjIu
NDM4NTkzXSAyYjEzZSBpcyAyZGNkODAwMCENClsgIDIyMi40NDA4MTJdIDJiMTNmIGlzIDJk
Y2Q3MDAwIQ0KWyAgMjIyLjQ0MjkxNV0gMmIxMjEgaXMgMmRjZDkwMDAhDQpbICAyMjIuNDQ1
MTU3XSAyYjEyMiBpcyAyZGNkYTAwMCENClsgIDIyMi40NDczNzNdIDJiMTIzIGlzIDJkY2Q0
MDAwIQ0KWyAgMjIyLjQ0OTQ4NF0gMmIxMjQgaXMgMmRjZDMwMDAhDQpbICAyMjIuNDUxNjUw
XSAyYjEyNSBpcyAyZGNkMjAwMCENClsgIDIyMi40NTM4NjBdIDJiMTI2IGlzIDJkY2QxMDAw
IQ0KWyAgMjIyLjQ1NTkzNl0gMmIxMjcgaXMgMmRjY2YwMDAhDQpbICAyMjIuNDU4MTA2XSAy
YjEyOCBpcyAyZGNkNTAwMCENClsgIDIyMi40NjAyNDBdIDJiMTI5IGlzIDJkY2NjMDAwIQ0K
WyAgMjIyLjQ2MjM3MV0gMmIxMmEgaXMgMmRjYzgwMDAhDQpbICAyMjIuNDY0NTM2XSAyYjE0
MCBpcyAyZGNjMzAwMCENClsgIDIyMi40NjY2MzNdIDJiMTJiIGlzIDJkY2M0MDAwIQ0KWyAg
MjIyLjQ2ODc2Nl0gMmIxMmMgaXMgMmRjY2QwMDAhDQpbICAyMjIuNDcwODU1XSAyYjE0MSBp
cyAyZGNjZTAwMCENClsgIDIyMi40NzMwMzldIDJiMTQyIGlzIDJkY2Q2MDAwIQ0KWyAgMjIy
LjQ3NTE1OF0gMmIxMmQgaXMgMmRjY2EwMDAhDQpbICAyMjIuNDc3Mzg3XSAyYjE0MyBpcyAy
ZGNjYjAwMCENClsgIDIyMi40Nzk0OTNdIDJiMTJlIGlzIDJkNWU2MDAwIQ0KWyAgMjIyLjQ4
MTczMF0gMmIxMmYgaXMgMmRjZTIwMDAhDQpbICAyMjIuNTAxMjc1XSAyYjEzMCBpcyA3YTI0
MTAwMCENClsgIDIyMi41MTU0NjFdIDJiMTQ1IGlzIDdhMjBmMDAwIQ0KWyAgMjIyLjUyNDUy
OV0gMmIxNDYgaXMgN2EyMGYwMDAhDQpbICAyMjIuNTQ2MDUwXSAyYjE0NyBpcyA3OGY3NDAw
MCENClsgIDIyMi41NDc5MTNdIDJiMTQ4IGlzIDc4Zjc1MDAwIQ0KWyAgMjIyLjU0OTczMF0g
MmIxNDkgaXMgNzhmNzYwMDAhDQpbICAyMjIuNTgyMDIxXSAyYjE0YiBpcyA3YTY1ZjAwMCEN
ClsgIDIyMi41ODM4ODVdIDJiMTRjIGlzIDdhNjkxMDAwIQ0KWyAgMjIyLjYyNzM3MF0gMmIx
NGQgaXMgN2E2YTAwMDAhDQpbICAyMjIuNzU5NTI3XSAyYjE0ZSBpcyAyMTY4MDAwMCENClsg
IDIyMi43NjU1MzRdIDJiMTRmIGlzIDc5NDllMDAwIQ0KWyAgMjIyLjc5NjA4OF0gMmIxNTAg
aXMgN2E2MTAwMDAhDQpbICAyMjIuODEyMDg1XSAyYjE1MSBpcyAyMTYzNTAwMCENClsgIDIy
Mi44MjE2MTJdIDJiMTUyIGlzIDc4ZDMwMDAwIQ0KWyAgMjIyLjg1NTI3NF0gMmIxNTMgaXMg
N2EwNmEwMDAhDQpbICAyMjIuODczMTA3XSAyYjE1NCBpcyA3OGYwMDAwMCENClsgIDIyMi44
ODkyODddIDJiMTU1IGlzIDIxNWFhMDAwIQ0KWyAgMjIyLjg5NjUxMF0gMmIxNTggaXMgN2E3
MWMwMDAhDQpbICAyMjIuODk4NjAzXSAyYjE1OSBpcyAyMWU0MzAwMCENClsgIDIyMi45MDA2
OTNdIDJiMTVhIGlzIDc5NDY3MDAwIQ0KWyAgMjIyLjkwMzI0NV0gMmIxNWIgaXMgN2E2MjMw
MDAhDQpbICAyMjIuOTEwNTgyXSAyYjEzMSBpcyA3OGNlNzAwMCENClsgIDIyMi45Mzk0OTRd
IDJiMTVjIGlzIDIxYTQzMDAwIQ0KWyAgMjIyLjk0NjA2Nl0gMmIxNWQgaXMgN2E3NDMwMDAh
DQpbICAyMjIuOTQ4Mjc5XSAyYjEzMiBpcyA3OGNlMzAwMCENClsgIDIyMi45Njk2MjldIDJi
MTMzIGlzIDc4ZjFjMDAwIQ0KWyAgMjIyLjk3MTg3M10gMmIxNWUgaXMgMjFlMzIwMDAhDQpb
ICAyMjIuOTc0MTIzXSAyYjE1ZiBpcyAyMTYyNzAwMCENClsgIDIyMi45NzYzNTRdIDJiMTYw
IGlzIDdhNmIzMDAwIQ0KWyAgMjIyLjk4MzA3NF0gMmIxNjIgaXMgNzhkMzQwMDAhDQpbICAy
MjIuOTg1NTE0XSAyYjE2MyBpcyA3OTZjZjAwMCENClsgIDIyMi45ODc3ODBdIDJiMTY0IGlz
IDIxOGIxMDAwIQ0KWyAgMjIyLjk5MDAyN10gMmIxNjUgaXMgNzhjZGMwMDAhDQpbICAyMjIu
OTkyMjc1XSAyYjE2NiBpcyAyMWU0ZDAwMCENClsgIDIyMi45OTQ1NTldIDJiMTY3IGlzIDdh
NjQ2MDAwIQ0KWyAgMjIyLjk5NjgzNF0gMmIxNjggaXMgNzhmNGIwMDAhDQpbICAyMjIuOTk5
MDg2XSAyYjE2OSBpcyAyMWE0MjAwMCENClsgIDIyMy4wMDEzODldIDJiMTZhIGlzIDIxNWIx
MDAwIQ0KWyAgMjIzLjAwMzY4MF0gMmIxNmIgaXMgMjE2MGUwMDAhDQpbICAyMjMuMDA1OTY1
XSAyYjE2YyBpcyA3OGY0YzAwMCENClsgIDIyMy4wMDgzNDhdIDJiMTZkIGlzIDIxYTNkMDAw
IQ0KWyAgMjIzLjAxMDY3MV0gMmIxNmUgaXMgN2E3NDQwMDAhDQpbICAyMjMuMDEyOTQ5XSAy
YjE2ZiBpcyA3YTc0MTAwMCENClsgIDIyMy4wMTUyMzJdIDJiMTcwIGlzIDdhNjIxMDAwIQ0K
WyAgMjIzLjAxNzUwNV0gMmIxNzEgaXMgN2EwNTEwMDAhDQpbICAyMjMuMDE5NzMxXSAyYjE3
MiBpcyAyMWRlNDAwMCENClsgIDIyMy4wMjE5ODhdIDJiMTczIGlzIDIxNWQ5MDAwIQ0KWyAg
MjIzLjAyNTI5NF0gMmIxMzQgaXMgMjFlMmEwMDAhDQpbICAyMjMuMDI3NjExXSAyYjEzNSBp
cyA3OGYwZjAwMCENClsgIDIyMy4wMjk4NTZdIDJiMTc2IGlzIDc4ZjMxMDAwIQ0KWyAgMjIz
LjAzMjEwNF0gMmIxNzcgaXMgNzhmNTEwMDAhDQpbICAyMjMuMDM0MzUyXSAyYjE3OCBpcyA3
OTQ5YjAwMCENClsgIDIyMy4wMzY1NDRdIDJiMTc5IGlzIDc5NDY5MDAwIQ0KWyAgMjIzLjAz
ODc0OF0gMmIxN2EgaXMgNzhlZDgwMDAhDQpbICAyMjMuMDQwOTEzXSAyYjE3YiBpcyA3OGVl
NzAwMCENClsgIDIyMy4wNDMwNzhdIDJiMTdjIGlzIDc4ZjA3MDAwIQ0KWyAgMjIzLjA0NTIy
NF0gMmIxN2QgaXMgNzhkMDMwMDAhDQpbICAyMjMuMDQ3MzkyXSAyYjE3ZSBpcyAyMTY0ZjAw
MCENClsgIDIyMy4wNDk4ODJdIDJiMTdmIGlzIDc4ZDNjMDAwIQ0KWyAgMjIzLjA1MjA2NF0g
MmIxODAgaXMgNzhlZGUwMDAhDQpbICAyMjMuMDU0MjEyXSAyYjE4MSBpcyA3OTRhMTAwMCEN
ClsgIDIyMy4wNTYzNDldIDJiMTgyIGlzIDc4ZjAzMDAwIQ0KWyAgMjIzLjA1ODUwNl0gMmIx
ODMgaXMgMjFlNTUwMDAhDQpbICAyMjMuMDYwNjcwXSAyYjE4NCBpcyA3OGYwYTAwMCENClsg
IDIyMy4wNjI3OThdIDJiMTg1IGlzIDc4ZWQ3MDAwIQ0KWyAgMjIzLjA2NDk0Ml0gMmIxODYg
aXMgNzhlZGEwMDAhDQpbICAyMjMuMDY3MDYyXSAyYjE4NyBpcyAyMWE1MzAwMCENClsgIDIy
My4wNjkyMDldIDJiMTg4IGlzIDIxYTRmMDAwIQ0KWyAgMjIzLjA3MTMwNV0gMmIxODkgaXMg
NzhlZGQwMDAhDQpbICAyMjMuMDczNDE4XSAyYjE4YSBpcyA3OGVkNTAwMCENClsgIDIyMy4w
NzU0OTVdIDJiMThiIGlzIDc4ZjRmMDAwIQ0KWyAgMjIzLjA3NzU4NF0gMmIxOGMgaXMgMjE2
NDcwMDAhDQpbICAyMjMuMDc5NjM4XSAyYjE4ZCBpcyAyMTkwMjAwMCENClsgIDIyMy4wODE3
MDRdIDJiMThlIGlzIDdhNjNjMDAwIQ0KWyAgMjIzLjA4Mzc4NV0gMmIxOGYgaXMgMjE2NzEw
MDAhDQpbICAyMjMuMDg1ODY2XSAyYjE5MCBpcyA3OGQzZjAwMCENClsgIDIyMy4wODc5Njdd
IDJiMTkxIGlzIDIxOGIwMDAwIQ0KWyAgMjIzLjA5MDA4MV0gMmIxOTIgaXMgN2E2NDEwMDAh
DQpbICAyMjMuMDkyMTc0XSAyYjE5MyBpcyA3YTczYzAwMCENClsgIDIyMy4wOTQzNDFdIDJi
MTk0IGlzIDdhNzNkMDAwIQ0KWyAgMjIzLjA5NjQwNl0gMmIxOTUgaXMgMjFlMjcwMDAhDQpb
ICAyMjMuMDk4NTEzXSAyYjE3NCBpcyAyMWUyNjAwMCENClsgIDIyMy4xMDA2MDRdIDJiMTYx
IGlzIDc4ZjNmMDAwIQ0KWyAgMjIzLjEwNzg5MV0gMmIxNzUgaXMgNzk0OTQwMDAhDQpbICAy
MjMuMTEwMTYyXSAyYjE5NiBpcyA3OTQ5NTAwMCENClsgIDIyMy4xMTIyNzldIDJiMTk3IGlz
IDdhNjM4MDAwIQ0KWyAgMjIzLjExNDQzOF0gMmIxOTggaXMgN2E2MzkwMDAhDQpbICAyMjMu
MTE2NTU0XSAyYjE5OSBpcyA3YTY1NjAwMCENClsgIDIyMy4xMTg3MDVdIDJiMTlhIGlzIDdh
NjU3MDAwIQ0KWyAgMjIzLjEyMDgxNF0gMmIxOWIgaXMgN2E2NTIwMDAhDQpbICAyMjMuMTIy
OTEyXSAyYjE5YyBpcyA3YTY1MzAwMCENClsgIDIyMy4xMjQ5ODBdIDJiMTlkIGlzIDIxNjYz
MDAwIQ0KWyAgMjIzLjEyNzA1Ml0gMmIxOWUgaXMgMjE2NjQwMDAhDQpbICAyMjMuMTI5MDc4
XSAyYjE5ZiBpcyA3YTY0MDAwMCENClsgIDIyMy4xMzExODhdIDJiMWEwIGlzIDIxYTcxMDAw
IQ0KWyAgMjIzLjEzMzIxM10gMmIxYTEgaXMgMjFhNzIwMDAhDQpbICAyMjMuMTM1MjQ4XSAy
YjFhMiBpcyAyMWU1YjAwMCENClsgIDIyMy4xMzcyNzFdIDJiMWEzIGlzIDIxZTVjMDAwIQ0K
WyAgMjIzLjEzOTI3Ml0gMmIxYTQgaXMgNzk0YjIwMDAhDQpbICAyMjMuMTQxMjc2XSAyYjFh
NSBpcyA3OTRiMzAwMCENClsgIDIyMy4xNDQ3MDddIDJiMWE2IGlzIDc4ZjI3MDAwIQ0KWyAg
MjIzLjE0Njc2NF0gMmIxYTcgaXMgNzhlZTgwMDAhDQpbICAyMjMuMTU0MzUyXSAyYjFhOCBp
cyA3OGVlOTAwMCENClsgIDIyMy4xNTY0MDNdIDJiMWE5IGlzIDc4ZWVhMDAwIQ0KWyAgMjIz
LjE1ODM4NF0gMmIxYWEgaXMgNzhmM2MwMDAhDQpbICAyMjMuMTYwMzU1XSAyYjFhYiBpcyAy
MWEyNjAwMCENClsgIDIyMy4xNjIzNjRdIDJiMWFjIGlzIDIxYTI1MDAwIQ0KWyAgMjIzLjE2
NDM1NV0gMmIxYWQgaXMgNzhmNDEwMDAhDQpbICAyMjMuMTY2MjcwXSAyYjFhZSBpcyA3OGY0
MDAwMCENClsgIDIyMy4xNjgxODhdIDJiMWFmIGlzIDc4ZjUzMDAwIQ0KWyAgMjIzLjE3MDA4
OF0gMmIxYjAgaXMgNzhmNTIwMDAhDQpbICAyMjMuMTcxOTg1XSAyYjFiMSBpcyA3OGVkMTAw
MCENClsgIDIyMy4xNzM4NjJdIDJiMWIyIGlzIDc4ZWQwMDAwIQ0KWyAgMjIzLjE3NjIwNl0g
MmIxZDEgaXMgNzhlZTEwMDAhDQpbICAyMjMuMTc4MDczXSAyYjFkMiBpcyA3OGVlMjAwMCEN
ClsgIDIyMy4xNzk4OTldIDJiMWQzIGlzIDc4ZWUzMDAwIQ0KWyAgMjIzLjE4MTcxN10gMmIx
ZDYgaXMgNzhmNDQwMDAhDQpbICAyMjMuMTgzNTM0XSAyYjFkNyBpcyA3OGY0NTAwMCENClsg
IDIyMy4xODUzNDhdIDJiMWQ4IGlzIDc4ZjQ2MDAwIQ0KWyAgMjIzLjE4NzE1N10gMmIxZDkg
aXMgNzhmNDcwMDAhDQpbICAyMjMuMTg4OTgxXSAyYjFkYSBpcyAyMWEyMTAwMCENClsgIDIy
My4xOTA4MDhdIDJiMWRiIGlzIDIxYTIyMDAwIQ0KWyAgMjIzLjE5MjY2MV0gMmIxZGMgaXMg
MjFhMjMwMDAhDQpbICAyMjMuMTk0NTExXSAyYjFkZCBpcyAyMWEyNDAwMCENClsgIDIyMy4x
OTYzNDJdIDJiMWRlIGlzIDIxYTE4MDAwIQ0KWyAgMjIzLjE5ODE3MV0gMmIxZGYgaXMgMjFh
MTkwMDAhDQpbICAyMjMuMTk5OTU1XSAyYjFlMCBpcyAyMWExYTAwMCENClsgIDIyMy4yMDE3
NzhdIDJiMWUxIGlzIDIxYTFiMDAwIQ0KWyAgMjIzLjIwMzYwMF0gMmIxZTIgaXMgMjFhMWMw
MDAhDQpbICAyMjMuMjA1NDM0XSAyYjFlMyBpcyA3OGYxMDAwMCENClsgIDIyMy4yMDcyNTBd
IDJiMWU0IGlzIDc4ZjExMDAwIQ0KWyAgMjIzLjIwOTEwMV0gMmIxZTUgaXMgNzhmMTIwMDAh
DQpbICAyMjMuMjEwODk4XSAyYjFlNiBpcyA3OGYxMzAwMCENClsgIDIyMy4yMTI2ODBdIDJi
MWU3IGlzIDc4ZWUwMDAwIQ0KWyAgMjIzLjIxNDQ5OV0gMmIxYzYgaXMgNzhmNzgwMDAhDQpb
ICAyMjMuMjE2MzA0XSAyYjFjNyBpcyA3OGY3OTAwMCENClsgIDIyMy4yMTgxMjhdIDJiMWM4
IGlzIDc4ZjdhMDAwIQ0KWyAgMjIzLjIxOTkwMF0gMmIxYzkgaXMgNzhmN2IwMDAhDQpbICAy
MjMuMjIxNzA4XSAyYjFjYSBpcyA3OGYyMDAwMCENClsgIDIyMy4yMjM0ODhdIDJiMWNiIGlz
IDc4ZjIxMDAwIQ0KWyAgMjIzLjIyNTI0N10gMmIxY2MgaXMgNzhmMjIwMDAhDQpbICAyMjMu
MjI3MDMwXSAyYjFjZCBpcyA3OGYyMzAwMCENClsgIDIyMy4yMjg3ODVdIDJiMWNlIGlzIDc4
ZjI0MDAwIQ0KWyAgMjIzLjIzMDU2M10gMmIxY2YgaXMgNzhmMjUwMDAhDQpbICAyMjMuMjMy
MzE2XSAyYjFkMCBpcyA3OGYyNjAwMCENClsgIDIyMy4yMzQwOTNdIDJiMWIzIGlzIDIxYTIw
MDAwIQ0KWyAgMjIzLjIzNTg2NF0gMmIxYjQgaXMgMjFhMWYwMDAhDQpbICAyMjMuMjM3NjU0
XSAyYjFiNSBpcyA3OGYyZjAwMCENClsgIDIyMy4yMzk0NDJdIDJiMWI2IGlzIDc4ZjJlMDAw
IQ0KWyAgMjIzLjI0MTIyN10gMmIxYjcgaXMgNzhmMmQwMDAhDQpbICAyMjMuMjQzMDIwXSAy
YjFiOCBpcyA3OGYyYzAwMCENClsgIDIyMy4yNDQ4MDVdIDJiMWI5IGlzIDIxYTcwMDAwIQ0K
WyAgMjIzLjI0NjU5Ml0gMmIxYmEgaXMgMjFhNmYwMDAhDQpbICAyMjMuMjQ4Mzc2XSAyYjFi
YiBpcyAyMWE2ZTAwMCENClsgIDIyMy4yNTAxNjRdIDJiMWJjIGlzIDIxYTZkMDAwIQ0KWyAg
MjIzLjI1MTk2Ml0gMmIxYmQgaXMgMjFhNGMwMDAhDQpbICAyMjMuMjUzNzUyXSAyYjFiZSBp
cyAyMWE0YjAwMCENClsgIDIyMy4yNTU1MzldIDJiMWJmIGlzIDIxYTRhMDAwIQ0KWyAgMjIz
LjI1NzMxOF0gMmIxYzAgaXMgMjFhNDkwMDAhDQpbICAyMjMuMjU5MDk0XSAyYjFjMSBpcyA3
OGVmZjAwMCENClsgIDIyMy4yNjA4OTBdIDJiMWMyIGlzIDc4ZWZlMDAwIQ0KWyAgMjIzLjI2
MjY1NV0gMmIxYzMgaXMgNzhlZmQwMDAhDQpbICAyMjMuMjY0NDUwXSAyYjFjNCBpcyA3OGVm
YzAwMCENClsgIDIyMy4yNjYyMTBdIDJiMWM1IGlzIDc4ZWViMDAwIQ0KWyAgMjIzLjI3NjYx
NV0gMmIxZjQgaXMgNzhmMWEwMDAhDQpbICAyMjMuMjc4NDM1XSAyYjFmNSBpcyA3OGYxYjAw
MCENClsgIDIyMy4yODAyMzBdIDJiMWY2IGlzIDIxYTE1MDAwIQ0KWyAgMjIzLjI4MTk5MF0g
MmIxZTggaXMgMjFhMTYwMDAhDQpbICAyMjMuMjg0NDI2XSAyYjFmNyBpcyA3OGYzNzAwMCEN
ClsgIDIyMy4yODYyMTldIDJiMWU5IGlzIDc4ZjE1MDAwIQ0KWyAgMjIzLjI4ODA1Nl0gMmIx
ZWEgaXMgNzhmMTYwMDAhDQpbICAyMjMuMjg5ODY4XSAyYjFlYiBpcyA3OGYxNzAwMCENClsg
IDIyMy4yOTE3MDRdIDJiMWVjIGlzIDc4ZjE4MDAwIQ0KWyAgMjIzLjI5MzU0MF0gMmIxZWQg
aXMgNzhmMTkwMDAhDQpbICAyMjMuMzAxMzYxXSAyYjFlZSBpcyA3OGYzNjAwMCENClsgIDIy
My4zMDMxODZdIDJiMWVmIGlzIDIxNWNkMDAwIQ0KWyAgMjIzLjMwNTA1MF0gMmIxZjAgaXMg
Nzk0OGIwMDAhDQpbICAyMjMuMzA2OTA2XSAyYjFmMSBpcyAyMThhZDAwMCENClsgIDIyMy4z
MDkyOThdIDJiMWYyIGlzIDc5NDkyMDAwIQ0KWyAgMjIzLjMxMTE4OF0gMmIxZjMgaXMgNzhm
MzkwMDAhDQpbICAyMjMuMzEzMDgxXSAyYjIxMyBpcyA3OGYyOTAwMCENClsgIDIyMy4zMTQ5
ODldIDJiMjE0IGlzIDc4ZDQ4MDAwIQ0KWyAgMjIzLjM0NTIyOF0gMmIyMTUgaXMgN2E2NzQw
MDAhDQpbICAyMjMuMzU5OTA5XSAyYjFmOCBpcyA3OGNmNTAwMCENClsgIDIyMy4zODEwMDNd
IDJiMWY5IGlzIDc4ZjM1MDAwIQ0KWyAgMjIzLjM4Mjk1MF0gMmIxZmEgaXMgNzhmMzQwMDAh
DQpbICAyMjMuMzg0OTEwXSAyYjFmYiBpcyAyMWUyYzAwMCENClsgIDIyMy4zODY4NjJdIDJi
MWZjIGlzIDIxZTJiMDAwIQ0KWyAgMjIzLjM4OTYwOV0gMmIxZmQgaXMgMjFhMTEwMDAhDQpb
ICAyMjMuMzkxNTc4XSAyYjIxNiBpcyAyMWEwYzAwMCENClsgIDIyMy4zOTM1NzddIDJiMjE3
IGlzIDIxYTBiMDAwIQ0KWyAgMjIzLjM5NTUwMl0gMmIyMTggaXMgMjFhMGEwMDAhDQpbICAy
MjMuMzk3NDY2XSAyYjIxOSBpcyAyMWEwOTAwMCENClsgIDIyMy4zOTkzODNdIDJiMjFhIGlz
IDIxYTA4MDAwIQ0KWyAgMjIzLjQwMTM0Ml0gMmIyMWIgaXMgMjFhMDcwMDAhDQpbICAyMjMu
NDAzMjcwXSAyYjIxYyBpcyAyMWEwNjAwMCENClsgIDIyMy40MDU2ODBdIDJiMjFkIGlzIDc4
ZDAxMDAwIQ0KWyAgMjIzLjQyNDAzNl0gMmIyMWUgaXMgNzhmNmMwMDAhDQpbICAyMjMuNDI2
MDA0XSAyYjFmZSBpcyA3OGY2ZDAwMCENClsgIDIyMy40Mjc5NTddIDJiMWZmIGlzIDc4ZjZm
MDAwIQ0KWyAgMjIzLjQyOTg4Nl0gMmIyMDAgaXMgNzhmNmUwMDAhDQpbICAyMjMuNDMyNTA3
XSAyYjIwMSBpcyA3OGVmNjAwMCENClsgIDIyMy40MzQ1MDVdIDJiMjFmIGlzIDc4ZWY3MDAw
IQ0KWyAgMjIzLjQzNjQyNl0gMmIyMjAgaXMgNzhlZjgwMDAhDQpbICAyMjMuNDM4Mzg1XSAy
YjIyMSBpcyA3OGVmOTAwMCENClsgIDIyMy40NDAzMzFdIDJiMjIyIGlzIDc4ZWZhMDAwIQ0K
WyAgMjIzLjQ0MjI0OF0gMmIyMjMgaXMgNzhlZmIwMDAhDQpbICAyMjMuNDQ4NTI0XSAyYjIy
NCBpcyAyMWU3ODAwMCENClsgIDIyMy40NTA0OTldIDJiMjAyIGlzIDIxYTEyMDAwIQ0KWyAg
MjIzLjQ1MjM2Nl0gMmIyMDMgaXMgN2E2MjYwMDAhDQpbICAyMjMuNDU0Mjg0XSAyYjIwNCBp
cyA3YTY3ZDAwMCENClsgIDIyMy40NTY4MDBdIDJiMjA1IGlzIDc4ZjgzMDAwIQ0KWyAgMjIz
LjQ1ODcwMV0gMmIyMjUgaXMgN2E2NjYwMDAhDQpbICAyMjMuNDYwNjA1XSAyYjIyNiBpcyAy
MWE0NTAwMCENClsgIDIyMy40NjI0ODNdIDJiMjI3IGlzIDc4ZjcxMDAwIQ0KWyAgMjIzLjQ5
NjEyOV0gMmIyMjggaXMgMjE2NTUwMDAhDQpbICAyMjMuNTA5OTI5XSAyYjIwNiBpcyA3YTYy
ZDAwMCENClsgIDIyMy41MTE4OTBdIDJiMjA3IGlzIDc4Y2VjMDAwIQ0KWyAgMjIzLjUxMzg2
Nl0gMmIyMDggaXMgNzk0YTMwMDAhDQpbICAyMjMuNTE1ODAyXSAyYjIwOSBpcyA3YTY1MTAw
MCENClsgIDIyMy41MTgzODddIDJiMjBhIGlzIDIxOGE1MDAwIQ0KWyAgMjIzLjUyMDM1N10g
MmIyMjkgaXMgMjFhMGQwMDAhDQpbICAyMjMuNTIyMzQzXSAyYjIyYSBpcyA3OGYzYTAwMCEN
ClsgIDIyMy41MjQzODBdIDJiMjJiIGlzIDIxNjFjMDAwIQ0KWyAgMjIzLjUzNDI1M10gMmIy
MmMgaXMgNzhmNjAwMDAhDQpbICAyMjMuNTM2Mjc2XSAyYjIyZCBpcyA3OGY1ZjAwMCENClsg
IDIyMy41Mzg0MjNdIDJiMjJlIGlzIDc4ZjVlMDAwIQ0KWyAgMjIzLjU0MDUwNl0gMmIyMmYg
aXMgNzhmNWQwMDAhDQpbICAyMjMuNTQ5NDIwXSAyYjIzMCBpcyA3OGY2NDAwMCENClsgIDIy
My41NTE1MjhdIDJiMjMxIGlzIDc4ZjYzMDAwIQ0KWyAgMjIzLjU1MzU1OV0gMmIyMzIgaXMg
NzhmNjIwMDAhDQpbICAyMjMuNTU1NTg2XSAyYjIzMyBpcyA3OGY2MTAwMCENClsgIDIyMy41
NTg0MjVdIDJiMjNkIGlzIDc4ZWYxMDAwIQ0KWyAgMjIzLjU2MDQ0NF0gMmIyM2UgaXMgNzhl
ZjAwMDAhDQpbICAyMjMuNTYyNDM1XSAyYjIzZiBpcyA3OGVlZjAwMCENClsgIDIyMy41NjQ0
MjldIDJiMjQwIGlzIDc4ZWVlMDAwIQ0KWyAgMjIzLjU2NjM5OV0gMmIyNDEgaXMgNzhlZWQw
MDAhDQpbICAyMjMuNTY4Mzk3XSAyYjIzNSBpcyA3OGVlYzAwMCENClsgIDIyMy41NzAzODJd
IDJiMjM2IGlzIDc4ZjZiMDAwIQ0KWyAgMjIzLjU3MjM1MF0gMmIyMzcgaXMgNzhmNmEwMDAh
DQpbICAyMjMuNTc0MjkyXSAyYjIzOCBpcyA3OGY2OTAwMCENClsgIDIyMy41NzYyMDhdIDJi
MjM5IGlzIDc4ZjY4MDAwIQ0KWyAgMjIzLjU3ODExNV0gMmIyM2EgaXMgNzhmNjcwMDAhDQpb
ICAyMjMuNTgwMDA1XSAyYjIzYiBpcyA3OGY2NjAwMCENClsgIDIyMy41ODE4ODNdIDJiMjNj
IGlzIDc4ZjY1MDAwIQ0KWyAgMjIzLjU4NDI2MV0gMmIyNDIgaXMgN2E2YzAwMDAhDQpbICAy
MjMuNTg2MTE2XSAyYjIwYiBpcyA3OGVmMjAwMCENClsgIDIyMy42MDcxMzddIDJiMjBjIGlz
IDc5MmJhMDAwIQ0KWyAgMjIzLjYzNTAxOV0gMmIyMGQgaXMgN2E2MjIwMDAhDQpbICAyMjMu
NjM2OTQxXSAyYjIwZSBpcyA3OGZiNDAwMCENClsgIDIyMy42Mzg4MTRdIDJiMjBmIGlzIDc4
ZmI5MDAwIQ0KWyAgMjIzLjY0MDY3NV0gMmIyMTAgaXMgNzhmYzAwMDAhDQpbICAyMjMuNjQ2
MTc5XSAyYjIxMSBpcyA3OGZjODAwMCENClsgIDIyMy42NDgxNDVdIDJiMjQzIGlzIDc4Zjkz
MDAwIQ0KWyAgMjIzLjY0OTk4M10gMmIyNDQgaXMgNzhmYWQwMDAhDQpbICAyMjMuNjUxNzg1
XSAyYjI0NSBpcyA3OGY5YTAwMCENClsgIDIyMy42NTM1NzFdIDJiMjQ2IGlzIDIxYTA1MDAw
IQ0KWyAgMjIzLjY1NTM4M10gMmIyNDcgaXMgNzhmYjAwMDAhDQpbICAyMjMuNjU3MjA5XSAy
YjI0OCBpcyA3OGZiMTAwMCENClsgIDIyMy42NTkwMzddIDJiMjQ5IGlzIDc4ZmIyMDAwIQ0K
WyAgMjIzLjY2MDkzNV0gMmIyNGEgaXMgNzhmOTQwMDAhDQpbICAyMjMuNjYyNzYwXSAyYjI0
YiBpcyA3OGY5MDAwMCENClsgIDIyMy42NjQ1ODRdIDJiMjRjIGlzIDc4ZmFhMDAwIQ0KWyAg
MjIzLjcyMDU0OV0gMmIyNGQgaXMgNzhmYmMwMDAhDQpbICAyMjMuNzM5Mzc0XSAyYjIxMiBp
cyA3OGY4OTAwMCENClsgIDIyMy43ODEzMjldIDJiMjUxIGlzIDdhMGFlMDAwIQ0KWyAgMjIz
Ljc4MzI1N10gMmIyNTIgaXMgNzhmYzEwMDAhDQpbICAyMjMuNzg1MTU5XSAyYjI1MyBpcyAy
MWU3YTAwMCENClsgIDIyMy43ODcxMDRdIDJiMjU0IGlzIDdhNjBkMDAwIQ0KWyAgMjIzLjc4
OTc1NF0gMmIyNTUgaXMgMjE1YWQwMDAhDQpbICAyMjMuNzkxNzIwXSAyYjI0ZSBpcyAyMTVj
YTAwMCENClsgIDIyMy43OTM2ODJdIDJiMjRmIGlzIDc4ZmFiMDAwIQ0KWyAgMjIzLjc5NTY2
MF0gMmIyNTAgaXMgNzk0Y2IwMDAhDQpbICAyMjMuNzk3NjY0XSAyYjI3MCBpcyA3YTY5ZDAw
MCENClsgIDIyMy43OTk2NjRdIDJiMjcxIGlzIDc5NDRlMDAwIQ0KWyAgMjIzLjgwMTY2N10g
MmIyNzIgaXMgMjE1YjIwMDAhDQpbICAyMjMuODAzNzA4XSAyYjI3MyBpcyA3OGZiODAwMCEN
ClsgIDIyMy44MjI1MjZdIDJiMjc0IGlzIDc4ZWNlMDAwIQ0KWyAgMjIzLjg0MTYxN10gMmIy
NTYgaXMgMjE4ZmMwMDAhDQpbICAyMjMuODQzNzQ0XSAyYjI1NyBpcyAyMWEwZjAwMCENClsg
IDIyMy44NDU3NzddIDJiMjU4IGlzIDdhMDkxMDAwIQ0KWyAgMjIzLjg0NzgyNl0gMmIyNTkg
aXMgN2E3M2UwMDAhDQpbICAyMjMuODUwNzQ5XSAyYjI1YSBpcyAyMWUxMTAwMCENClsgIDIy
My44NTI3NzVdIDJiMjc1IGlzIDc4ZWRmMDAwIQ0KWyAgMjIzLjg1NDk0N10gMmIyNzYgaXMg
Nzk0ODUwMDAhDQpbICAyMjMuODU3MDM1XSAyYjI3NyBpcyA3OTRiNTAwMCENClsgIDIyMy44
NTkxMDFdIDJiMjc4IGlzIDdhNjRlMDAwIQ0KWyAgMjIzLjg2MTE4M10gMmIyNzkgaXMgNzhm
NWMwMDAhDQpbICAyMjMuODYzMjU2XSAyYjI3YSBpcyAyMWU0MTAwMCENClsgIDIyMy44NjUz
MzBdIDJiMjdiIGlzIDc4Zjk1MDAwIQ0KWyAgMjIzLjg2NzQ0NV0gMmIyN2MgaXMgNzhmMjgw
MDAhDQpbICAyMjMuODc1OTExXSAyYjI3ZSBpcyA3YTYxNDAwMCENClsgIDIyMy44NzgwNzNd
IDJiMjdmIGlzIDdhNjFiMDAwIQ0KWyAgMjIzLjg4MDIxMF0gMmIyODAgaXMgNzhmOTIwMDAh
DQpbICAyMjMuODgyMzMzXSAyYjI3ZCBpcyA3OGYwNTAwMCENClsgIDIyMy44OTM0NTldIDJi
Mjg5IGlzIDdhNmJmMDAwIQ0KWyAgMjIzLjg5NTYxN10gMmIyODEgaXMgN2E2MTYwMDAhDQpb
ICAyMjMuODk3NzczXSAyYjI4MiBpcyA3OGZiMzAwMCENClsgIDIyMy44OTk5MTBdIDJiMjgz
IGlzIDc5NDg4MDAwIQ0KWyAgMjIzLjkwMjA1Nl0gMmIyODQgaXMgNzhkMDgwMDAhDQpbICAy
MjMuOTA0MjMwXSAyYjI4NSBpcyAyMWUxNDAwMCENClsgIDIyMy45MDYzNjZdIDJiMjg2IGlz
IDdhNjEzMDAwIQ0KWyAgMjIzLjkwODU0NF0gMmIyODcgaXMgNzhmYjUwMDAhDQpbICAyMjMu
OTEwNzAzXSAyYjI4OCBpcyA3YTBiNzAwMCENClsgIDIyMy45MjIyMjBdIDJiMjhhIGlzIDIx
ZTVmMDAwIQ0KWyAgMjIzLjkzNTAxNl0gMmIyOGIgaXMgNzhmYjcwMDAhDQpbICAyMjMuOTM3
MjgyXSAyYjI1YiBpcyA3OGZiNjAwMCENClsgIDIyMy45Mzk0NTRdIDJiMjVjIGlzIDc5Mjhm
MDAwIQ0KWyAgMjIzLjk1NTY1M10gMmIyNWQgaXMgNzkyOTMwMDAhDQpbICAyMjMuOTU3ODY1
XSAyYjI1ZSBpcyA3OTI5MjAwMCENClsgIDIyMy45NTk5OTBdIDJiMjVmIGlzIDc5MjkxMDAw
IQ0KWyAgMjIzLjk2MjE0N10gMmIyNjAgaXMgNzkyOTAwMDAhDQpbICAyMjMuOTY0ODAzXSAy
YjI2MSBpcyA3OGZhNjAwMCENClsgIDIyMy45NjY5NjJdIDJiMjhjIGlzIDc4ZmE1MDAwIQ0K
WyAgMjIzLjk2OTA1NF0gMmIyOGQgaXMgNzhmYTQwMDAhDQpbICAyMjMuOTg0MTg1XSAyYjI4
ZSBpcyA3OTJjODAwMCENClsgIDIyMy45ODYyODFdIDJiMjYyIGlzIDc5MmM3MDAwIQ0KWyAg
MjIzLjk4ODQwNF0gMmIyNjMgaXMgNzkyYzYwMDAhDQpbICAyMjMuOTkwNDkzXSAyYjI2NCBp
cyA3OTJjNTAwMCENClsgIDIyMy45OTMwOTNdIDJiMjY1IGlzIDc4ZmM3MDAwIQ0KWyAgMjIz
Ljk5NTE2Ml0gMmIyOGYgaXMgNzhmNTYwMDAhDQpbICAyMjMuOTk3MjAwXSAyYjI5MCBpcyA3
OTJjOTAwMCENClsgIDIyNC4wMDM5NzZdIDJiMjkxIGlzIDc5MmI4MDAwIQ0KWyAgMjI0LjAw
NjAyNF0gMmIyNjYgaXMgNzhmYTEwMDAhDQpbICAyMjQuMDA4MTE1XSAyYjI2NyBpcyA3OGZh
MzAwMCENClsgIDIyNC4wMTAxNjRdIDJiMjY4IGlzIDc4ZmE3MDAwIQ0KWyAgMjI0LjAxMjk4
MV0gMmIyNjkgaXMgNzkyYjUwMDAhDQpbICAyMjQuMDE1MTc3XSAyYjI5MiBpcyA3OTJiNjAw
MCENClsgIDIyNC4wMTcyMTddIDJiMjkzIGlzIDc5MmI3MDAwIQ0KWyAgMjI0LjAxOTE5Ml0g
MmIyOTQgaXMgMjFlNGMwMDAhDQpbICAyMjQuMDIxMjEzXSAyYjI5NSBpcyA3OGY3ZDAwMCEN
ClsgIDIyNC4wMjMyMDJdIDJiMjk2IGlzIDc4ZjhmMDAwIQ0KWyAgMjI0LjAyNTIwMV0gMmIy
OTcgaXMgNzhmYTIwMDAhDQpbICAyMjQuMDI3MTYxXSAyYjI5OCBpcyA3OTJiNDAwMCENClsg
IDIyNC4wMjkyNTVdIDJiMjk5IGlzIDc5Mjk3MDAwIQ0KWyAgMjI0LjAzMTI0NV0gMmIyOWEg
aXMgNzkyOTgwMDAhDQpbICAyMjQuMDMzMTg4XSAyYjI5YiBpcyA3OTI5OTAwMCENClsgIDIy
NC4wMzUwNzVdIDJiMjljIGlzIDc5MjlhMDAwIQ0KWyAgMjI0LjAzNjk5MV0gMmIyOWQgaXMg
NzkyYWYwMDAhDQpbICAyMjQuMDM4ODUwXSAyYjI5ZSBpcyA3OGY5YzAwMCENClsgIDIyNC4w
NDA3MjldIDJiMjlmIGlzIDc4ZjlmMDAwIQ0KWyAgMjI0LjA0MjYzOF0gMmIyYTAgaXMgNzhm
YTAwMDAhDQpbICAyMjQuMDQ0NTM0XSAyYjJhMSBpcyA3OGZjNTAwMCENClsgIDIyNC4wNTMy
MDFdIDJiMmEzIGlzIDc4ZmNiMDAwIQ0KWyAgMjI0LjA1NTEyNV0gMmIyYTIgaXMgNzhmODUw
MDAhDQpbICAyMjQuMDU3MDE1XSAyYjI2YSBpcyA3OGQxMjAwMCENClsgIDIyNC4wNTg5MjNd
IDJiMjZiIGlzIDc5Mjk2MDAwIQ0KWyAgMjI0LjA2MTM3MV0gMmIyYTUgaXMgNzhlZjQwMDAh
DQpbICAyMjQuMDYzMzAyXSAyYjJhNiBpcyA3OGY5OTAwMCENClsgIDIyNC4wNjUyMjldIDJi
MjZjIGlzIDc4ZjU3MDAwIQ0KWyAgMjI0LjA2NzE5Nl0gMmIyYTQgaXMgNzhmYmEwMDAhDQpb
ICAyMjQuMDY5NjcyXSAyYjJhNyBpcyA3OGZhZTAwMCENClsgIDIyNC4wNzE2NDVdIDJiMmE4
IGlzIDc4ZmE5MDAwIQ0KWyAgMjI0LjA3MzU2OV0gMmIyYTkgaXMgNzhmOWQwMDAhDQpbICAy
MjQuMDc1NDU3XSAyYjJhYSBpcyA3OGY5ZTAwMCENClsgIDIyNC4wNzc3NDZdIDJiMmFiIGlz
IDc5Mjg2MDAwIQ0KWyAgMjI0LjA5MjQ4MF0gMmIyYWMgaXMgNzkyOGEwMDAhDQpbICAyMjQu
MDk0NDYwXSAyYjI2ZCBpcyA3OTI4OTAwMCENClsgIDIyNC4wOTYzMjZdIDJiMjZlIGlzIDc5
Mjg4MDAwIQ0KWyAgMjI0LjA5ODE5NV0gMmIyNmYgaXMgNzkyODcwMDAhDQpbICAyMjQuMTA5
MDczXSAyYjJhZSBpcyA3OTJhMjAwMCENClsgIDIyNC4xMTA5NTBdIDJiMmFkIGlzIDc5MmEx
MDAwIQ0KWyAgMjI0LjExMjg0OF0gMmIyY2QgaXMgNzkyYTAwMDAhDQpbICAyMjQuMTE0NzAy
XSAyYjJjZSBpcyA3OTI5ZjAwMCENClsgIDIyNC4xMTY1NTVdIDJiMmNmIGlzIDc5MjllMDAw
IQ0KWyAgMjI0LjExODQwNF0gMmIyZDAgaXMgNzkyOWQwMDAhDQpbICAyMjQuMTIwMjY2XSAy
YjJkMSBpcyA3OTI5YzAwMCENClsgIDIyNC4xMjIxMDNdIDJiMmQyIGlzIDc5MjhiMDAwIQ0K
WyAgMjI0LjEyNDA3Ml0gMmIyZDMgaXMgNzkyYTYwMDAhDQpbICAyMjQuMTI1OTM4XSAyYjJk
NCBpcyA3OTJhNTAwMCENClsgIDIyNC4xMjc4MDldIDJiMmQ1IGlzIDc5MmE0MDAwIQ0KWyAg
MjI0LjEyOTY1OF0gMmIyZDYgaXMgNzkyYTMwMDAhDQpbICAyMjQuMTQxODMyXSAyYjJhZiBp
cyA3OTI2OTAwMCENClsgIDIyNC4xNDM2NzddIDJiMmQ3IGlzIDc5MjY4MDAwIQ0KWyAgMjI0
LjE0NTUyMl0gMmIyZDggaXMgNzkyNjcwMDAhDQpbICAyMjQuMTUyNDI5XSAyYjJkOSBpcyA3
OTI2YTAwMCENClsgIDIyNC4xNTQ0NDddIDJiMmRhIGlzIDc5MjZiMDAwIQ0KWyAgMjI0LjE1
NzU1OV0gMmIyZGIgaXMgNzkyNmQwMDAhDQpbICAyMjQuMTU5NDAyXSAyYjJkYyBpcyA3OTI2
YzAwMFsgIDIyNi4yODY1ODNdIDJhZTAyIGlzIDc4YzkwMDAwIQ0KWyAgMjI2LjI4ODM1Nl0g
MmFlMDMgaXMgNzhjOTEwMDAhDQpbICAyMjYuMjkwMDk1XSAyYWUwNCBpcyA3OGM5MjAwMCEN
ClsgIDIyNi4yOTE4MjJdIDJhZTA1IGlzIDc4YzkzMDAwIQ0KWyAgMjI2LjI5MzU0OF0gMmFl
MDYgaXMgNzhjOTQwMDAhDQpbICAyMjYuMjk1Mjk4XSAyYWUwNyBpcyA3OGM5NTAwMCENClsg
IDIyNi4yOTcwMzldIDJhZTA4IGlzIDc4Yzk2MDAwIQ0KWyAgMjI2LjI5ODk2MF0gMmFlMTQg
aXMgNzhjYTIwMDAhDQpbICAyMjYuMzAwNzA5XSAyYWUxNSBpcyA3OGNhMzAwMCENClsgIDIy
Ni4zMDI0MTldIDJhZTE4IGlzIDc4Y2E0MDAwIQ0KWyAgMjI2LjMwNDE1Nl0gMmFlMTkgaXMg
NzhjYTUwMDAhDQpbICAyMjYuMzA1ODYwXSAyYWUxYSBpcyA3OGNhNjAwMCENClsgIDIyNi4z
MDc1ODBdIDJhZTFiIGlzIDc4Y2E3MDAwIQ0KWyAgMjI2LjMwOTI5N10gMmFlMWMgaXMgNzhj
YTgwMDAhDQpbICAyMjYuMzExMDEyXSAyYWUxZCBpcyA3OGNhOTAwMCENClsgIDIyNi4zMTI3
MzJdIDJhZTFlIGlzIDc4Y2FhMDAwIQ0KWyAgMjI2LjMxNDQ0OV0gMmFlMWYgaXMgNzhjYWIw
MDAhDQpbICAyMjYuMzE2MTUyXSAyYWUyMCBpcyA3OGNjMzAwMCENClsgIDIyNi4zMTc4OTZd
IDJhZTA5IGlzIDc4Yzk3MDAwIQ0KWyAgMjI2LjMxOTU4OF0gMmFlMGEgaXMgNzhjOTgwMDAh
DQpbICAyMjYuMzIxMzE0XSAyYWUwYiBpcyA3OGM5OTAwMCENClsgIDIyNi4zMjMwMThdIDJh
ZTBjIGlzIDc4YzlhMDAwIQ0KWyAgMjI2LjMyNDc0OF0gMmFlMGQgaXMgNzhjOWIwMDAhDQpb
ICAyMjYuMzI2NDQwXSAyYWUwZSBpcyA3OGM5YzAwMCENClsgIDIyNi4zMjgxNDNdIDJhZTBm
IGlzIDc4YzlkMDAwIQ0KWyAgMjI2LjMyOTg1Ml0gMmFlMTAgaXMgNzhjOWUwMDAhDQpbICAy
MjYuMzMxNTQzXSAyYWUxMSBpcyA3OGM5ZjAwMCENClsgIDIyNi4zMzMyNDFdIDJhZTEyIGlz
IDc4Y2EwMDAwIQ0KWyAgMjI2LjMzNDkzOF0gMmFlMTMgaXMgNzhjYTEwMDAhDQpbICAyMjYu
MzUxOTE2XSAyYWUyMSBpcyA3OGM3ODAwMCENClsgIDIyNi4zNTM2MTNdIDJhZTIyIGlzIDc4
Yzc3MDAwIQ0KWyAgMjI2LjM1NTM4N10gMmFlMjMgaXMgNzhjNzYwMDAhDQpbICAyMjYuMzU3
MDcwXSAyYWUyNCBpcyA3OGM3NTAwMCENClsgIDIyNi4zNTg3NDVdIDJhZTI1IGlzIDc4Yzc0
MDAwIQ0KWyAgMjI2LjM2MDQxOF0gMmFlMjYgaXMgNzhjNzMwMDAhDQpbICAyMjYuMzYyMDkx
XSAyYWUyNyBpcyA3OGM3MjAwMCENClsgIDIyNi4zNjM3NjVdIDJhZTI4IGlzIDc4YzcxMDAw
IQ0KWyAgMjI2LjM2NTQzMF0gMmFlMjkgaXMgNzhjNzAwMDAhDQpbICAyMjYuMzY3MTI4XSAy
YWUyYSBpcyA3OGM2ZjAwMCENClsgIDIyNi4zNjg3OTJdIDJhZTJiIGlzIDc4YzZlMDAwIQ0K
WyAgMjI2LjM3MDYwMV0gMmFlMmMgaXMgNzhjODMwMDAhDQpbICAyMjYuMzcyMjYzXSAyYWUy
ZCBpcyA3OGM4MjAwMCENClsgIDIyNi4zNzM5NDBdIDJhZTJlIGlzIDc4YzgxMDAwIQ0KWyAg
MjI2LjM3NTYxOF0gMmFlMmYgaXMgNzhjODAwMDAhDQpbICAyMjYuMzc3Mjk3XSAyYWUzMCBp
cyA3OGM3ZjAwMCENClsgIDIyNi4zNzg5ODldIDJhZTMxIGlzIDc4YzdlMDAwIQ0KWyAgMjI2
LjM4MDY3M10gMmFlMzIgaXMgNzhjN2QwMDAhDQpbICAyMjYuMzgyMzU3XSAyYWUzMyBpcyA3
OGM3YzAwMCENClsgIDIyNi4zODQwNjldIDJhZTM0IGlzIDc4YzdiMDAwIQ0KWyAgMjI2LjM4
NTc0M10gMmFlMzUgaXMgNzhjN2EwMDAhDQpbICAyMjYuMzg3NDMxXSAyYWUzNiBpcyA3OGM3
OTAwMCENClsgIDIyNi4zODkwOTRdIDJhZTM3IGlzIDc4YzZkMDAwIQ0KWyAgMjI2LjM5MDc2
N10gMmFlMzggaXMgNzhjODkwMDAhDQpbICAyMjYuMzkyNDYwXSAyYWUzOSBpcyA3OGM4ODAw
MCENClsgIDIyNi4zOTQxNTFdIDJhZTNhIGlzIDc4Yzg3MDAwIQ0KWyAgMjI2LjM5NTg1MV0g
MmFlM2IgaXMgNzhjODYwMDAhDQpbICAyMjYuMzk3NTQxXSAyYWUzYyBpcyA3OGM4NTAwMCEN
ClsgIDIyNi4zOTkyMDddIDJhZTNkIGlzIDc4Yzg0MDAwIQ0KWyAgMjI2LjQwMTIzN10gMmFl
M2UgaXMgNzhjYzQwMDAhDQpbICAyMjYuNDIyMjI0XSAyYWUzZiBpcyAyMTZkMTAwMCENClsg
IDIyNi40MjM5NDVdIDJhZTQwIGlzIDIxNmQyMDAwIQ0KWyAgMjI2LjQyNTY3OV0gMmFlNDEg
aXMgMjE2Y2IwMDAhDQpbICAyMjYuNDI3NDI0XSAyYWU0MiBpcyAyMTZjYzAwMCENClsgIDIy
Ni40MjkxMzddIDJhZTQzIGlzIDIxZjVmMDAwIQ0KWyAgMjI2LjQzMDg2MF0gMmFlNDQgaXMg
MjFmNjAwMDAhDQpbICAyMjYuNDMyNTc2XSAyYWU0NSBpcyAyMWY1ZTAwMCENClsgIDIyNi40
MzQzMjhdIDJhZTQ2IGlzIDIxZjgwMDAwIQ0KWyAgMjI2LjQzNjA1MV0gMmFlNDcgaXMgMjFm
N2YwMDAhDQpbICAyMjYuNDM3ODEyXSAyYWU0OCBpcyAyMWY2NjAwMCENClsgIDIyNi40Mzk1
NDVdIDJhZTQ5IGlzIDIxZjY1MDAwIQ0KWyAgMjI2LjQ0MTUzMl0gMmFlNTUgaXMgNzhjNWYw
MDAhDQpbICAyMjYuNDQzMjkwXSAyYWU1NiBpcyA3OGM2MDAwMCENClsgIDIyNi40NDUwNjZd
IDJhZTU3IGlzIDc4YzYxMDAwIQ0KWyAgMjI2LjQ0Njg1MF0gMmFlNTggaXMgNzhjNjIwMDAh
DQpbICAyMjYuNDQ4NjAwXSAyYWU1OSBpcyA3OGM2MzAwMCENClsgIDIyNi40NTAzNzldIDJh
ZTVhIGlzIDc4YzY0MDAwIQ0KWyAgMjI2LjQ1MjExN10gMmFlNWIgaXMgNzhjNjUwMDAhDQpb
ICAyMjYuNDUzODg2XSAyYWU1YyBpcyA3OGM2NjAwMCENClsgIDIyNi40NTU2MjBdIDJhZTVk
IGlzIDc4YzY3MDAwIQ0KWyAgMjI2LjQ1NzM2OV0gMmFlNWUgaXMgNzhjNjgwMDAhDQpbICAy
MjYuNDU5MTE5XSAyYWU0YSBpcyA3OGM2OTAwMCENClsgIDIyNi40NjA4NjhdIDJhZTRiIGlz
IDc4YzZhMDAwIQ0KWyAgMjI2LjQ2MjYyM10gMmFlNGMgaXMgNzhjNmIwMDAhDQpbICAyMjYu
NDY0MzcxXSAyYWU0ZCBpcyA3OGM1ODAwMCENClsgIDIyNi40NjYxMTRdIDJhZTRlIGlzIDc4
YzU5MDAwIQ0KWyAgMjI2LjQ2Nzg2Ml0gMmFlNGYgaXMgNzhjNWEwMDAhDQpbICAyMjYuNDY5
NjAwXSAyYWU1MCBpcyA3OGM1YjAwMCENClsgIDIyNi40NzEzNzZdIDJhZTUxIGlzIDc4YzRj
MDAwIQ0KWyAgMjI2LjQ3MzE0MV0gMmFlNTIgaXMgNzhjNGQwMDAhDQpbICAyMjYuNDc0OTM0
XSAyYWU1MyBpcyAyMTZjNTAwMCENClsgIDIyNi40NzY3MzRdIDJhZTU0IGlzIDIxNmM2MDAw
IQ0KWyAgMjI2LjQ5MDQ4N10gMmFlNWYgaXMgNzhjNDQwMDAhDQpbICAyMjYuNDkyMjg2XSAy
YWU2MCBpcyA3OGM0NTAwMCENClsgIDIyNi40OTQyMzVdIDJhZTYxIGlzIDc4YzQ2MDAwIQ0K
WyAgMjI2LjQ5NjAyMV0gMmFlNjIgaXMgNzhjNDcwMDAhDQpbICAyMjYuNDk3Nzk3XSAyYWU2
MyBpcyA3OGM0ODAwMCENClsgIDIyNi40OTk1NTZdIDJhZTY0IGlzIDc4YzQ5MDAwIQ0KWyAg
MjI2LjUwMTMxNl0gMmFlNjUgaXMgNzhjNGEwMDAhDQpbICAyMjYuNTAzMDU1XSAyYWU2NiBp
cyA3OGM0YjAwMCENClsgIDIyNi41MDQ4MjBdIDJhZTY3IGlzIDc4YzVjMDAwIQ0KWyAgMjI2
LjUwNjU1NV0gMmFlNjggaXMgNzhjNWQwMDAhDQpbICAyMjYuNTA4MzIwXSAyYWU2OSBpcyA3
OGM1ZTAwMCENClsgIDIyNi41MTk4MTRdIDJhZTc0IGlzIDc4YzI3MDAwIQ0KWyAgMjI2LjUy
MTY3N10gMmFlNzMgaXMgNzhjMjgwMDAhDQpbICAyMjYuNTIzNDEyXSAyYWU3MiBpcyA3OGMy
OTAwMCENClsgIDIyNi41MjUxNDhdIDJhZTcxIGlzIDc4YzJhMDAwIQ0KWyAgMjI2LjUyNjg4
N10gMmFlNzAgaXMgNzhjMmIwMDAhDQpbICAyMjYuNTI4NjE5XSAyYWU2ZiBpcyA3OGMzMDAw
MCENClsgIDIyNi41MzAzNzJdIDJhZTZlIGlzIDc4YzMxMDAwIQ0KWyAgMjI2LjUzMjEwOF0g
MmFlNmQgaXMgNzhjMzIwMDAhDQpbICAyMjYuNTMzODc0XSAyYWU2YyBpcyA3OGMzMzAwMCEN
ClsgIDIyNi41MzU2MTJdIDJhZTZiIGlzIDc4YzM0MDAwIQ0KWyAgMjI2LjUzNzM4MF0gMmFl
NmEgaXMgNzhjMzUwMDAhDQpbICAyMjYuNTM5MjcyXSAyYWU3OCBpcyA3OGMxYzAwMCENClsg
IDIyNi41NDEwNDhdIDJhZTc5IGlzIDc4YzFkMDAwIQ0KWyAgMjI2LjU0Mjc5MV0gMmFlN2Eg
aXMgNzhjMWUwMDAhDQpbICAyMjYuNTQ0NTQ4XSAyYWU3YiBpcyA3OGMxZjAwMCENClsgIDIy
Ni41NDYzMDddIDJhZTdjIGlzIDc4YzIwMDAwIQ0KWyAgMjI2LjU0ODA2M10gMmFlN2QgaXMg
NzhjMjEwMDAhDQpbICAyMjYuNTQ5ODE4XSAyYWU3ZSBpcyA3OGMyMjAwMCENClsgIDIyNi41
NTE1NjhdIDJhZTdmIGlzIDc4YzIzMDAwIQ0KWyAgMjI2LjU1MzI3OF0gMmFlNzcgaXMgNzhj
MjQwMDAhDQpbICAyMjYuNTU1MDI4XSAyYWU3NiBpcyA3OGMyNTAwMCENClsgIDIyNi41NTY3
MjZdIDJhZTc1IGlzIDc4YzI2MDAwIQ0KWyAgMjI2LjU1ODQxOF0gMmFlODAgaXMgNzhjMTkw
MDAhDQpbICAyMjYuNTYwMTI3XSAyYWU4MSBpcyA3OGMxYTAwMCENClsgIDIyNi41NjE4NDBd
IDJhZTgyIGlzIDc4YzFiMDAwIQ0KWyAgMjI2LjU2NzIzNV0gMmFkZDcgaXMgNzhjMTMwMDAh
DQpbICAyMjYuNTY4OTYzXSAyYWU4MyBpcyA3OGMxNDAwMCENClsgIDIyNi41NzA3MjFdIDJh
ZTg0IGlzIDc4YzE1MDAwIQ0KWyAgMjI2LjU3MjQ0Ml0gMmFlODUgaXMgNzhjMTYwMDAhDQpb
ICAyMjYuNTc0MTc5XSAyYWU4NiBpcyA3OGMxNzAwMCENClsgIDIyNi41NzU5MTNdIDJhZTg3
IGlzIDc4YzE4MDAwIQ0KWyAgMjI2LjU4MjIwMV0gMmFlODggaXMgNzhjMTIwMDAhDQpbICAy
MjYuNTkzNDUyXSAyYWU5NCBpcyA3OGMxMTAwMCENClsgIDIyNi42MTkzNzFdIDJhZTk1IGlz
IDc4YmNmMDAwIQ0KWyAgMjI2LjYyMjAzNV0gMmFlODkgaXMgNzhiZGEwMDAhDQpbICAyMjYu
NjIzOTkwXSAyYWU5NiBpcyA3OGJkOTAwMCENClsgIDIyNi42MjU3NjVdIDJhZTk3IGlzIDc4
YmQ4MDAwIQ0KWyAgMjI2LjYyNzUzMF0gMmFlOTggaXMgNzhiZDcwMDAhDQpbICAyMjYuNjI5
Mjg4XSAyYWU5OSBpcyA3OGJkNjAwMCENClsgIDIyNi42MzEwNDRdIDJhZTlhIGlzIDc4YmQ1
MDAwIQ0KWyAgMjI2LjYzMjgwM10gMmFlOWIgaXMgNzhiZDQwMDAhDQpbICAyMjYuNjM0NTY1
XSAyYWU5YyBpcyA3OGJkMzAwMCENClsgIDIyNi42MzYzNTFdIDJhZTlkIGlzIDc4YmQyMDAw
IQ0KWyAgMjI2LjYzODEyMV0gMmFlOWUgaXMgNzhiZDEwMDAhDQpbICAyMjYuNjM5ODQzXSAy
YWU5ZiBpcyA3OGJkMDAwMCENClsgIDIyNi42NDE4MjJdIDJhZWE5IGlzIDc4YmY3MDAwIQ0K
WyAgMjI2LjY0MzU4M10gMmFlYWEgaXMgNzhiZjgwMDAhDQpbICAyMjYuNjQ1MzI3XSAyYWVh
YiBpcyA3OGJmOTAwMCENClsgIDIyNi42NDcwNzNdIDJhZWFjIGlzIDc4YzBjMDAwIQ0KWyAg
MjI2LjY0ODgxN10gMmFlYWQgaXMgNzhiZWEwMDAhDQpbICAyMjYuNjUwNTkzXSAyYWVhZSBp
cyA3OGJlOTAwMCENClsgIDIyNi42NTIzNTNdIDJhZWFmIGlzIDc4YmU4MDAwIQ0KWyAgMjI2
LjY1NDE0MF0gMmFlYjAgaXMgNzhiZTcwMDAhDQpbICAyMjYuNjU1OTEwXSAyYWViMSBpcyA3
OGJlNjAwMCENClsgIDIyNi42NTc2OTBdIDJhZWIyIGlzIDc4YmU1MDAwIQ0KWyAgMjI2LjY1
OTQzMV0gMmFlYjMgaXMgNzhiZTQwMDAhDQpbICAyMjYuNjYxMTg0XSAyYWVhMCBpcyA3OGJl
MzAwMCENClsgIDIyNi42NjI5NDJdIDJhZWExIGlzIDc4YmUyMDAwIQ0KWyAgMjI2LjY2NDY4
NF0gMmFlYTIgaXMgNzhiZTEwMDAhDQpbICAyMjYuNjY2NDI1XSAyYWVhMyBpcyA3OGJlMDAw
MCENClsgIDIyNi42NjgxNjFdIDJhZWE0IGlzIDc4YmRmMDAwIQ0KWyAgMjI2LjY2OTkxMl0g
MmFlYTUgaXMgNzhiZGUwMDAhDQpbICAyMjYuNjcxNjU0XSAyYWVhNiBpcyA3OGJkZDAwMCEN
ClsgIDIyNi42NzMzOTVdIDJhZWE3IGlzIDc4YmRjMDAwIQ0KWyAgMjI2LjY3NTEzMF0gMmFl
YTggaXMgNzhiZGIwMDAhDQpbICAyMjYuNjc3NTc1XSAyYWViNCBpcyA3OGMwMzAwMCENClsg
IDIyNi42NzkzMzNdIDJhZWI1IGlzIDc4YmZlMDAwIQ0KWyAgMjI2LjY4MTA1NF0gMmFlYjYg
aXMgNzhiZmYwMDAhDQpbICAyMjYuNjgyNzc4XSAyYWViNyBpcyA3OGMwMDAwMCENClsgIDIy
Ni42ODQ1MTJdIDJhZWI4IGlzIDc4YmYwMDAwIQ0KWyAgMjI2LjY4NjIzN10gMmFlYjkgaXMg
NzhiZWQwMDAhDQpbICAyMjYuNjg3OTg5XSAyYWViYSBpcyA3OGJlZTAwMCENClsgIDIyNi42
ODk3MTRdIDJhZWJiIGlzIDc4YmVmMDAwIQ0KWyAgMjI2LjY5MTQ2Nl0gMmFlYmMgaXMgNzhi
ZjEwMDAhDQpbICAyMjYuNjkzMjAyXSAyYWViZCBpcyA3OGJmNDAwMCENClsgIDIyNi42OTQ5
NzBdIDJhZWJlIGlzIDc4YmY1MDAwIQ0KWyAgMjI2LjY5Njg5NV0gMmFlYzcgaXMgNzhjMDQw
MDAhDQpbICAyMjYuNzEwMjg0XSAyYWVjMiBpcyA3OTVjYTAwMCENClsgIDIyNi43MTIwODNd
IDJhZWMxIGlzIDc5NWNiMDAwIQ0KWyAgMjI2LjcxMzg3OV0gMmFlYzAgaXMgNzhiY2MwMDAh
DQpbICAyMjYuNzE1NjczXSAyYWViZiBpcyA3OGJjZDAwMCENClsgIDIyNi43MTk0NDVdIDJh
ZWMzIGlzIDc5NWMyMDAwIQ0KWyAgMjI2LjcyMTI2NV0gMmFlYzQgaXMgNzk1YzMwMDAhDQpb
ICAyMjYuNzIzMDQ0XSAyYWVjNSBpcyA3OTVjNDAwMCENClsgIDIyNi43MjQ4NTVdIDJhZWM2
IGlzIDc5NWM1MDAwIQ0KWyAgMjI2LjcyODU5Ml0gMmFlYzggaXMgNzk1YzEwMDAhDQpbICAy
MjYuNzMyNzQ5XSAyYWVjOSBpcyA3OTVjMDAwMCENClsgIDIyNi43Mzg0MjVdIDJhZWNhIGlz
IDc5NWJmMDAwIQ0KWyAgMjI2Ljc0MDkyMV0gMmFlY2IgaXMgNzk1YmUwMDAhDQpbICAyMjYu
NzQzMDYyXSAyYWVjYyBpcyA3OTViZDAwMCENClsgIDIyNi43NDUyMjddIDJhZWNkIGlzIDc5
NWJjMDAwIQ0KWyAgMjI2Ljc0OTc2NV0gMmFlY2UgaXMgNzk1YmIwMDAhDQpbICAyMjYuNzUx
OTEwXSAyYWVjZiBpcyA3OTViYTAwMCENClsgIDIyNi43NTQwNjZdIDJhZWQxIGlzIDc5NWI5
MDAwIQ0KWyAgMjI2Ljc1NjAxNF0gMmFlZDUgaXMgNzk1YjgwMDAhDQpbICAyMjYuNzY1OTQ5
XSAyYWVkNCBpcyA3OTViNjAwMCENClsgIDIyNi43NzYzOThdIDJhZWQ2IGlzIDc5NWIyMDAw
IQ0KWyAgMjI2Ljc3ODM1OF0gMmFlZDcgaXMgNzk1YjMwMDAhDQpbICAyMjYuNzgwMTM1XSAy
YWVkOCBpcyA3OTViNDAwMCENClsgIDIyNi43ODE4ODVdIDJhZWQ5IGlzIDc5NWI1MDAwIQ0K
WyAgMjI2Ljc4NTYzMF0gMmFlZGEgaXMgNzk1YjEwMDAhDQpbICAyMjYuNzg5Nzg1XSAyYWVk
YiBpcyA3OGMwNTAwMCENClsgIDIyNi43OTk2MjRdIDJhZWRjIGlzIDc5NWFmMDAwIQ0KWyAg
MjI2LjgxMzQxNF0gMmFlZGQgaXMgNzk1YWUwMDAhDQpbICAyMjYuODE1NTI4XSAyYWVkZSBp
cyA3OTVhZDAwMCENClsgIDIyNi44MTc4MzZdIDJhZWRmIGlzIDc5NWFjMDAwIQ0KWyAgMjI2
LjgxOTk1Ml0gMmFlZTAgaXMgNzk1YWIwMDAhDQpbICAyMjYuODIyMDc3XSAyYWVlMSBpcyA3
OTVhYTAwMCENClsgIDIyNi44MjQ1OTVdIDJhZWViIGlzIDc5NWE5MDAwIQ0KWyAgMjI2Ljgy
NjMxNV0gMmFlZTcgaXMgNzk1YTEwMDAhDQpbICAyMjYuODI4MDcxXSAyYWVlOCBpcyA3OTVh
MjAwMCENClsgIDIyNi44Mjk3NzddIDJhZWU5IGlzIDc5NWEzMDAwIQ0KWyAgMjI2LjgzMTQ5
OF0gMmFlZWEgaXMgNzk1YTQwMDAhDQpbICAyMjYuODMzMjAzXSAyYWVlMyBpcyA3OTVhODAw
MCENClsgIDIyNi44MzQ5MDddIDJhZWU0IGlzIDc5NWE1MDAwIQ0KWyAgMjI2LjgzNjYwM10g
MmFlZTUgaXMgNzk1YTYwMDAhDQpbICAyMjYuODM4Mjk2XSAyYWVlNiBpcyA3OTVhNzAwMCEN
ClsgIDIyNi44NDM3MzBdIDJhZWVjIGlzIDIxNzdjMDAwIQ0KWyAgMjI2Ljg2NDcyMV0gMmFl
ZTIgaXMgNzk1NmUwMDAhDQpbICAyMjYuODY2NDc1XSAyYWVkMCBpcyA3OTU4ODAwMCENClsg
IDIyNi44NzE3OTRdIDJhZThhIGlzIDc5NTljMDAwIQ0KWyAgMjI2Ljg4NDQzNV0gMmFlOGIg
aXMgNzk1NjEwMDAhDQpbICAyMjYuOTAyNzExXSAyYWU4YyBpcyA3OTU0ZDAwMCENClsgIDIy
Ni45Mzc2ODRdIDJhZThkIGlzIDc5NTU0MDAwIQ0KWyAgMjI2Ljk0MTc1NV0gMmFlOGUgaXMg
Nzk1NTMwMDAhDQpbICAyMjYuOTYyNjQ2XSAyYWU5MSBpcyAyMTVlYjAwMCENClsgIDIyNi45
NjQ2MzZdIDJhZTkwIGlzIDc5NTNiMDAwIQ0KWyAgMjI2Ljk2NjQ2M10gMmFlOGYgaXMgNzk1
NDEwMDAhDQpbICAyMjYuOTY4MzAxXSAyYWVmMyBpcyAyMTZiMDAwMCENClsgIDIyNi45NzAy
MDBdIDJhZTkzIGlzIDIxZTY5MDAwIQ0KWyAgMjI2Ljk3MjI4OV0gMmFlZjQgaXMgNzk1OGMw
MDAhDQpbICAyMjYuOTc0MjQ3XSAyYWVmNSBpcyA3OTUzYTAwMCENClsgIDIyNi45NzYxMzdd
IDJhZTkyIGlzIDc5NTNlMDAwIQ0KWyAgMjI2Ljk3ODA0NV0gMmFlZjYgaXMgNzk1M2QwMDAh
DQpbICAyMjcuMDA3NTMwXSAyYWVlZCBpcyA3OTU2YzAwMCENClsgIDIyNy4wMDk0MzddIDJh
ZWY3IGlzIDc5NTY3MDAwIQ0KWyAgMjI3LjAxMTM2MF0gMmFlZjggaXMgNzk1OGIwMDAhDQpb
ICAyMjcuMDEzMjUyXSAyYWVmOSBpcyAyMTZkNzAwMCENClsgIDIyNy4wMTU4MTBdIDJhZWZi
IGlzIDc5NTM4MDAwIQ0KWyAgMjI3LjAxNzc3NF0gMmFlZmMgaXMgNzk1ODUwMDAhDQpbICAy
MjcuMDE5NzI0XSAyYWVmZCBpcyA3OTU2NTAwMCENClsgIDIyNy4wMjE2ODZdIDJhZWZlIGlz
IDc5NThlMDAwIQ0KWyAgMjI3LjAyMzY3Nl0gMmFlZmYgaXMgNzk1M2YwMDAhDQpbICAyMjcu
MDI1NjE1XSAyYWYwMCBpcyA3OTU4MTAwMCENClsgIDIyNy4wMjgxNzBdIDJhZjAxIGlzIDc5
NTFkMDAwIQ0KWyAgMjI3LjA1Mjg2NF0gMmFlZmEgaXMgNzhjZGIwMDAhDQpbICAyMjcuMDY5
MDQ5XSAyYWYwMiBpcyA3OTUyMzAwMCENClsgIDIyNy4wNzY2ODZdIDJhZjAzIGlzIDc5NTBl
MDAwIQ0KWyAgMjI3LjA5MDY2NV0gMmFmMDQgaXMgNzk1MWEwMDAhDQpbICAyMjcuMTE1ODA3
XSAyYWYwNSBpcyA3OTU3MTAwMCENClsgIDIyNy4xMTc5MDhdIDJhZjA2IGlzIDc4YzU2MDAw
IQ0KWyAgMjI3LjExOTk2MF0gMmFmMDcgaXMgMjE3NzkwMDAhDQpbICAyMjcuMTIyMDAyXSAy
YWYwOCBpcyAyMTc4MDAwMCENClsgIDIyNy4xMjQ1NTddIDJhZjA5IGlzIDc4Y2M5MDAwIQ0K
WyAgMjI3LjUwNDEzNV0gMmFmMTMgaXMgMjFlNjEwMDAhDQpbICAyMjcuNTA2MzQwXSAyYWYx
NCBpcyA3OTIyMjAwMCENClsgIDIyNy41MDg0MjZdIDJhZjE1IGlzIDc5MjBlMDAwIQ0KWyAg
MjI3LjUxMDUwOF0gMmFmMTYgaXMgNzkyYzEwMDAhDQpbICAyMjcuNTEyNTU4XSAyYWYxNyBp
cyA3OTI3YjAwMCENClsgIDIyNy41MjQyOTFdIDJhZjIxIGlzIDIxNmQ4MDAwIQ0KWyAgMjI3
LjUyNjMzM10gMmFmMjIgaXMgNzkyMWMwMDAhDQpbICAyMjcuNTI4NDIyXSAyYWYwZSBpcyA3
YTYzZjAwMCENClsgIDIyNy41MzA1MDFdIDJhZjBkIGlzIDIxODg1MDAwIQ0KWyAgMjI3LjUz
MjU5Nl0gMmFlZWUgaXMgNzkyMWYwMDAhDQpbICAyMjcuNTM0NzI0XSAyYWYwYSBpcyA3OTIw
ZDAwMCENClsgIDIyNy41MzY4ODBdIDJhZjBjIGlzIDc5MjEwMDAwIQ0KWyAgMjI3LjUzODk3
Nl0gMmFmMTggaXMgNzkxZjkwMDAhDQpbICAyMjcuNTQxMTI3XSAyYWYxMSBpcyA3OTFmYTAw
MCENClsgIDIyNy41NDMyMzRdIDJhZjEyIGlzIDc5MjQ2MDAwIQ0KWyAgMjI3LjU0NTM2Nl0g
MmFmMTAgaXMgMjFhNGQwMDAhDQpbICAyMjcuNTQ3NDc2XSAyYWYwZiBpcyA3OTI4ZTAwMCEN
ClsgIDIyNy41NDk2MDZdIDJhZjBiIGlzIDc5MjBjMDAwIQ0KWyAgMjI3LjU1MTczOF0gMmFm
MWEgaXMgNzkyMGYwMDAhDQpbICAyMjcuNTUzODg2XSAyYWYxOSBpcyAyMWExMDAwMCENClsg
IDIyNy41NTYwNDZdIDJhZjFkIGlzIDc5NTJhMDAwIQ0KWyAgMjI3LjU1ODIxMV0gMmFmMWUg
aXMgNzhiZWIwMDAhDQpbICAyMjcuNTYwNDA1XSAyYWYxZiBpcyA3OTU5ZDAwMCENClsgIDIy
Ny41NjI1NTVdIDJhZjIwIGlzIDIxNzdjMDAwIQ0KWyAgMjI4LjEyNjY1NF0gMmFmMjMgaXMg
NzhmODIwMDAhDQpbICAyMjguNDIxOTYwXSAyYWYyNCBpcyA3YTBkNDAwMCENClsgIDIyOC40
MjU1NDhdIDJhZjI1IGlzIDJkY2ZiMDAwIQ0KWyAgMjI4LjQyNzgwMV0gMmFlZWYgaXMgN2E2
YjgwMDAhDQpbICAyMjguNDMwMDYyXSAyYWVmMCBpcyAyMWUwMDAwMCENClsgIDIyOC40MzIy
OTFdIDJhZWYxIGlzIDIxZGZmMDAwIQ0KWyAgMjI4LjQzNDU1NF0gMmFlZjIgaXMgMmRjYzIw
MDAhDQpbICAyMjguNDM2ODA0XSAyYWYzMSBpcyA3YTI0MTAwMCENClsgIDIyOC40MzkwMzhd
IDJhZjMyIGlzIDJkY2MxMDAwIQ0KWyAgMjI4LjQ0MTI2OV0gMmFmMzMgaXMgN2EyMGYwMDAh
DQpbICAyMjguNDQzNTQwXSAyYWYzNCBpcyA3YTZjODAwMCENClsgIDIyOC40NDU3NzRdIDJh
ZjM1IGlzIDI2ZWFmMDAwIQ0KWyAgMjI4LjQ0ODA3Ml0gMmFmMzYgaXMgMjZlYjAwMDAhDQpb
ICAyMjguNDUwNzA0XSAyYWY0MiBpcyAyNGRmZjAwMCENClsgIDIyOC40NTI5NjddIDJhZjQz
IGlzIDI0ZTAwMDAwIQ0KWyAgMjI4LjQ1NTMyOV0gMmFmNDQgaXMgNzk2ZmIwMDAhDQpbICAy
MjguNDU3NTgwXSAyYWY0NSBpcyAyMWRlZDAwMCENClsgIDIyOC40NTk4MjddIDJhZjQ2IGlz
IDJiNDg5MDAwIQ0KWyAgMjI4LjQ2MjA4MF0gMmFmNDcgaXMgMjUyNjgwMDAhDQpbICAyMjgu
NDY0MzY0XSAyYWY0OCBpcyAyZGNmNTAwMCENClsgIDIyOC40NjY2MDNdIDJhZjQ5IGlzIDI1
ZGI3MDAwIQ0KWyAgMjI4LjQ2ODkwNl0gMmFmNGEgaXMgMmRjZjQwMDAhDQpbICAyMjguNDcx
MTU5XSAyYWY0YiBpcyAyNTMwNDAwMCENClsgIDIyOC40NzM0MjhdIDJhZjRjIGlzIDI0ZGZk
MDAwIQ0KWyAgMjI4LjQ3NTY3NV0gMmFmNGQgaXMgMjU0NjUwMDAhDQpbICAyMjguNDc3OTM4
XSAyYWY0ZSBpcyAyZGNmOTAwMCENClsgIDIyOC40ODAyMjRdIDJhZjRmIGlzIDI1NTM2MDAw
IQ0KWyAgMjI4LjQ4MjQ3OV0gMmFmNTAgaXMgMjRlMTgwMDAhDQpbICAyMjguNDg0NzcwXSAy
YWY1MSBpcyAyNGUyNDAwMCENClsgIDIyOC40ODcwMjhdIDJhZjUyIGlzIDI0ZTBkMDAwIQ0K
WyAgMjI4LjQ4OTI3MV0gMmFmNTMgaXMgNzk2ZjcwMDAhDQpbICAyMjguNDkxNTQ5XSAyYWY1
NCBpcyAyMWUzZjAwMCENClsgIDIyOC40OTM4MjhdIDJhZjU1IGlzIDc5MjU4MDAwIQ0KWyAg
MjI4LjQ5NjA0OV0gMmFmNTYgaXMgNzk0NzcwMDAhDQpbICAyMjguNDk4MjkwXSAyYWY1NyBp
cyAyYWU1YTAwMCENClsgIDIyOC41MDA1MTddIDJhZjU4IGlzIDI0ZTIyMDAwIQ0KWyAgMjI4
LjUwMjcwM10gMmFmNTkgaXMgMmI0OGQwMDAhDQpbICAyMjguNTA0OTI0XSAyYWY1YSBpcyAy
NTFiMDAwMCENClsgIDIyOC41MDcxMzJdIDJhZjViIGlzIDI1MjA1MDAwIQ0KWyAgMjI4LjUw
OTMyM10gMmFmNWMgaXMgMmRjZmEwMDAhDQpbICAyMjguNTExNTEyXSAyYWY1ZCBpcyAyNTQ2
NDAwMCENClsgIDIyOC41MTM3MzddIDJhZjVlIGlzIDJkY2Y3MDAwIQ0KWyAgMjI4LjUxNTky
M10gMmFmMzcgaXMgMjRlMDMwMDAhDQpbICAyMjguNTE4MTI5XSAyYWYzOCBpcyAyNGRmZTAw
MCENClsgIDIyOC41MjAzMjVdIDJhZjM5IGlzIDJkY2ZjMDAwIQ0KWyAgMjI4LjUyMjUwMl0g
MmFmM2EgaXMgMjRlMDIwMDAhDQpbICAyMjguNTI0Njg0XSAyYWYzYiBpcyA3YTIyODAwMCEN
ClsgIDIyOC41MjY4ODVdIDJhZjNjIGlzIDIxZGVlMDAwIQ0KWyAgMjI4LjUyOTA0OF0gMmFm
M2QgaXMgMmRjYzkwMDAhDQpbICAyMjguNTMxMjQxXSAyYWYzZSBpcyAyN2E5ZDAwMCENClsg
IDIyOC41MzM0MTNdIDJhZjNmIGlzIDI3YzljMDAwIQ0KWyAgMjI4LjUzNTU3NF0gMmFmNDAg
aXMgMmRjZDgwMDAhDQpbICAyMjguNTM3NzM0XSAyYWY0MSBpcyAyZGNmZDAwMCENClsgIDIy
OC41NTc5MzRdIDJiMzZmIGlzIDI2ZTdkMDAwIQ0KWyAgMjU4LjU3MjI2MF0gMmFmMmIgaXMg
Nzk2ZjcwMDAhDQpbICAyNTguNTc0NTMyXSAyYWYyYyBpcyAyNTMwNDAwMCENClsgIDI1OC41
NzY3NTBdIDJhZjJkIGlzIDc5NmZiMDAwIQ0KWyAgMjU4LjU3ODk0N10gMmFmMmUgaXMgMjFk
ZWUwMDAhDQpbICAyNTguNTgxMTUwXSAyYWYyZiBpcyAyNTUzNjAwMCENClsgIDI1OC41ODMz
NDldIDJhZjMwIGlzIDJhZTVhMDAwIQ0KWyAgMjU4LjU4NTU3NF0gMmIxNTYgaXMgMjUyMDUw
MDAhDQpbICAyNTguNTg3ODQ2XSAyYjE1NyBpcyAyZGNmYTAwMCENClsgIDI1OC41OTAxNTld
IDJhZjkwIGlzIDJkY2ZiMDAwIQ0KWyAgMjU4LjU5MjQyNl0gMmFmOTEgaXMgMjUyNjgwMDAh
DQpbICAyNTguNjAxMTE3XSAyYWY5MiBpcyAyNTFiMDAwMCENClsgIDI1OC42MDMzOTldIDJh
Zjk0IGlzIDJiNDhkMDAwIQ0KWyAgMjU4LjYwNTYzN10gMmIzNjcgaXMgMmI0ODkwMDAhDQpb
ICAyNTguNjA3ODgzXSAyYWY2YyBpcyAyZGNmOTAwMCENClsgIDI1OC42MTAxMjRdIDJhZjZi
IGlzIDI1NDY0MDAwIQ0KWyAgMjU4LjYxMjM2Nl0gMmFmNjYgaXMgMjU0NjUwMDAhDQpbICAy
NTguNjE0NTk5XSAyYWY2NSBpcyAyZGNmNzAwMCENClsgIDI1OC42MTY4NDVdIDJhZjYzIGlz
IDJkY2Y0MDAwIQ0KWyAgMjU4LjYxOTAzNV0gMmFmNjQgaXMgMmRjZjUwMDAhDQpbICAyNTgu
NjIxMjM0XSAyYWY2MiBpcyAyNWRiNzAwMCENClsgIDI1OC42MjM0MTJdIDJhZjFiIGlzIDdh
NmM4MDAwIQ0KWyAgMjU4LjYyNTYxM10gMmFmNWYgaXMgMjFlMDAwMDAhDQpbICAyNTguNjI3
ODI0XSAyYWYxYyBpcyAyMWRmZjAwMCENClsgIDI1OC42MzAwNTRdIDJhZjYwIGlzIDJkY2My
MDAwIQ0KWyAgMjU4LjYzMjI1Ml0gMmFmNjEgaXMgMmRjYzEwMDAhDQpbICAyNTguNjM0NDU1
XSAyYWYyOSBpcyAyN2E5ZDAwMCENClsgIDI1OC42MzY2MjhdIDJhZjI4IGlzIDI3YzljMDAw
IQ0KWyAgMjU4LjYzODgyMF0gMmFmMjcgaXMgMmRjZDgwMDAhDQpbICAyNTguNjQwOTk4XSAy
YWYyNiBpcyAyZGNjOTAwMCENClsgIDI1OC42NDMxNzFdIDJhZjJhIGlzIDc5MjU4MDAwIQ0K
WyAgMjU4LjY0NTQ4OF0gMmFmOTYgaXMgMjFlM2YwMDAhDQpbICAyODcuMDQ1MjM5XSAyYWY3
NyBpcyAyMTdiYTAwMCENClsgIDI4Ny4wNDc2MjVdIDJhZjk3IGlzIDIxNWY5MDAwIQ0KWyAg
Mjg3LjA0OTgwM10gMmFmOTggaXMgN2E2MTkwMDAhDQpbICAyODcuMDUxOTk5XSAyYWY5OSBp
cyA3OTU4YTAwMCENClsgIDI4Ny4wNTQ4MzRdIDJhZjlhIGlzIDdhNjVlMDAwIQ0KWyAgMjg3
LjA1NzIyNl0gMmFmNzggaXMgNzk1OTAwMDAhDQpbICAyODcuMDU5Mzc0XSAyYWY3OSBpcyA3
OGY4ODAwMCENClsgIDI4Ny4wNjE1NDRdIDJhZjdhIGlzIDc5MjE4MDAwIQ0KWyAgMjg3LjA2
MzY5NF0gMmFmN2IgaXMgMjE2NjIwMDAhDQpbICAyODcuMDY1ODMyXSAyYWY3YyBpcyA3OTU1
MjAwMCENClsgIDI4Ny4wNjgwNjJdIDJhZjdkIGlzIDIxZjYxMDAwIQ0KWyAgMjg3LjA3MDIy
M10gMmFmN2UgaXMgMjE3NzgwMDAhDQpbICAyODcuMDcyMzMzXSAyYWY3ZiBpcyA3YTc0ODAw
MCENClsgIDI4Ny4wNzQ0NjRdIDJhZjgwIGlzIDc5NTc4MDAwIQ0KWyAgMjg3LjA3NjU1OF0g
MmFmODEgaXMgNzkyMjEwMDAhDQpbICAyODcuMDc4NjcxXSAyYWY4MiBpcyA3YTc0NzAwMCEN
ClsgIDI4Ny4wODA4MDBdIDJhZjgzIGlzIDIxNjAxMDAwIQ0KWyAgMjg3LjA4MjkxMF0gMmFm
ODQgaXMgMjE1ZGEwMDAhDQpbICAyODcuMDg1MDU5XSAyYWY4NSBpcyAyMTVmNDAwMCENClsg
IDI4Ny4wODcyMDNdIDJhZjg2IGlzIDc4ZjgxMDAwIQ0KWyAgMjg3LjA4OTM1MV0gMmFmODcg
aXMgMjE5ZGQwMDAhDQpbICAyODcuMDkxOTQ4XSAyYWY4OSBpcyA3OTU3NTAwMCENClsgIDI4
Ny4wOTQxNjJdIDJhZjhhIGlzIDc4ZmM0MDAwIQ0KWyAgOTE0LjM0MzQ2N10gMmFmOGIgaXMg
Nzk1NjMwMDAhDQpbICA5MTQuMzU5OTI0XSAyYWZhYiBpcyA3OTUwZjAwMCENClsgIDkxNC4z
NzE5NTldIDM3NGZhIGlzIDIxNWQ2MDAwIQ0KWyAgOTE0LjM4OTE5M10gMzdkZmEgaXMgNzk1
N2QwMDAhDQpbICA5MTQuMzkyMTcxXSAyYWZhMiBpcyA3OTU3YzAwMCENClsgIDkxNC4zOTUx
NDZdIDM5MTAwIGlzIDc5NTU3MDAwIQ0KWyAgOTE0LjM5ODExMF0gMmFmYWEgaXMgNzk1NTYw
MDAhDQpbICA5MTQuNDA5MDIzXSAyYWZhYyBpcyA3OTU2ZDAwMCENClsgIDkxNC40MTIwOTFd
IDJhZmEwIGlzIDc4YzUzMDAwIQ0KWyAgOTE0LjQxNTA2M10gMzc1MGYgaXMgNzhjNTEwMDAh
DQpbICA5MTQuNDE4MDM4XSAzNmY4MSBpcyAyMTc3NzAwMCENClsgIDkxNC40MjEwNDZdIDM3
ZWQwIGlzIDc5NTg0MDAwIQ0KWyAgOTE0LjQyNDA0Nl0gMzY1MTUgaXMgNzk1OWIwMDAhDQpb
ICA5MTQuNDI3MDM4XSAzN2U5YyBpcyA3OTUxYjAwMCENClsgIDkxNC40MzAwMjRdIDM2NTMx
IGlzIDc5NTI3MDAwIQ0KWyAgOTE0LjQzMzM2MF0gMzhjMmQgaXMgNzk0ODEwMDAhDQpbICA5
MTQuNDM2Mzg4XSAzNzg2ZCBpcyA3YTY4MjAwMCENClsgIDkxNC40Mzk0MDZdIDM3NjJkIGlz
IDc5NWEwMDAwIQ0KWyAgOTE0LjQ0MjQ1M10gMzZlYjggaXMgNzk1NWYwMDAhDQpbICA5MTQu
NDQ1NDc5XSAyYWY4ZCBpcyAyMTVkNzAwMCENClsgIDkxNC40NDg1MzRdIDM3ZTVjIGlzIDc5
NTU1MDAwIQ0KWyAgOTE0LjQ1MTYxNF0gMzdlOGIgaXMgNzk1OTYwMDAhDQpbICA5MTQuNDU0
NjY1XSAzNmViOSBpcyA3OTU0NTAwMCENClsgIDkxNC40NTc3MDhdIDM2NGZkIGlzIDIxNmFk
MDAwIQ0KWyAgOTE0LjQ2MDc5N10gMzY0M2MgaXMgNzk1NWMwMDAhDQpbICA5MTQuNDYzODk0
XSAzNmUzZSBpcyA3OTUyNTAwMCENClsgIDkxNC40NjY5NTNdIDM2ZTNmIGlzIDc5NTY4MDAw
IQ0KWyAgOTE0LjQ3MDAwNl0gMzhkMTMgaXMgNzk1NjkwMDAhDQpbICA5MTQuNDczMTYyXSAy
YWZhZCBpcyA3OTUxODAwMCENClsgIDkxNC40NzYyMDRdIDJhZjhjIGlzIDc5NTE5MDAwIQ0K
WyAgOTE0LjQ3OTA1M10gMzgzMzggaXMgNzk1MjQwMDAhDQpbICA5MTQuNTcwMzIzXSAzN2Vk
MSBpcyA3OTU3MjAwMCENClsgIDkxNC41NzI4NzNdIDJhZmE2IGlzIDc5NTczMDAwIQ0KWyAg
OTE0LjU3NTIxMF0gMmFmYTcgaXMgNzk1MjAwMDAhDQpbICA5MTQuNTc3NTI4XSAyYWZhOCBp
cyA3OTUyMTAwMCENClsgIDkxNC41ODAyMzRdIDM5MmExIGlzIDc5NTA0MDAwIQ0KWyAgOTE5
LjQyMTkzMV0gMmFmYTkgaXMgMjRlMjIwMDAhDQpbICA5MTkuNDI0MzAyXSAzNzZhMCBpcyAy
NGUwZDAwMCENClsgIDkxOS40MjY2MTFdIDJhZmE0IGlzIDI2ZTdjMDAwIQ0KWyAgOTE5LjQ2
Mzc0NV0gMmFmYTUgaXMgNzk0ZTkwMDAhDQpbICA5MjQuNTkyMTM0XSAyYWY5ZSBpcyA3OTUw
MzAwMCENClsgIDkyNC42MjQ4OTZdIDJhZjlmIGlzIDc5NGUzMDAwIQ0KWyAgOTI0LjYyNzI1
OV0gMzc3M2MgaXMgNzk0ZTQwMDAhDQpbICA5MjQuNjI5NTgxXSAyYWY5YyBpcyA3OTRlNTAw
MCENClsgIDkyNC42NTkxNzFdIDM5MGNhIGlzIDc5NGUyMDAwIQ0KWyAgOTI0LjY4MjUzMl0g
MmFmYTMgaXMgNzk0ZGUwMDAhDQpbICA5MjQuNjg0OTQxXSAzODE5MCBpcyA3OTRkZjAwMCEN
ClsgIDkyNC42ODczMTJdIDM4MTkxIGlzIDc5NGUwMDAwIQ0KWyAgOTI0LjY4OTY0NV0gM2Ey
NGUgaXMgNzk0ZTEwMDAhDQpbICA5MjQuNjkyNzM4XSAzYTI0ZiBpcyA3OTRkNjAwMCENClsg
IDkyNC42OTUxMjhdIDM4NDlhIGlzIDc5NGQ3MDAwIQ0KWyAgOTI0LjY5NzQ0NV0gMzg0OWIg
aXMgNzk0ZDgwMDAhDQpbICA5MjQuNjk5NjgxXSAzYTIwMiBpcyA3OTRkOTAwMCENClsgIDky
NC43MDE5NTldIDNhMjAzIGlzIDc5NGRhMDAwIQ0KWyAgOTI0LjcwNDIyMF0gM2EyMGEgaXMg
Nzk0ZGIwMDAhDQpbICA5MjQuNzA2NDQyXSAzYTIwYiBpcyA3OTRkYzAwMCENClsgIDkyNC43
MDg2NDBdIDM4MTlhIGlzIDc5NGRkMDAwIQ0KWyAgOTI0LjcxMDg2MV0gMzgxOWIgaXMgNzk0
ZDUwMDAhDQpbICA5MjQuNzEzNTAxXSAzYTMwYyBpcyA3OTRkMzAwMCENClsgIDkyNC43MTU3
MjFdIDNhMzBkIGlzIDc5NGQ0MDAwIQ0KWyAgOTI0LjcxODMwOV0gMzgyMDEgaXMgNzk0ZDIw
MDAhDQpbICA5MjQuNzIwODc1XSAzODE5YyBpcyA3OTRkMTAwMCENClsgIDkyNC43NDM3NzFd
IDM4MTlkIGlzIDc5NGNmMDAwIQ0KWyAgOTI0Ljc0NTkwMF0gMmFmYWUgaXMgNzk0ZDAwMDAh
DQpbICA5MjQuNzU1Mzc0XSAzODIwMCBpcyA3OTZjNjAwMCENClsgIDkyNC43NTc1NzhdIDJh
ZmFmIGlzIDc5NGNkMDAwIQ0KWyAgOTI0Ljc1OTc1Nl0gMmFmYjAgaXMgNzk0Y2UwMDAhDQpb
ICA5MjQuNzYyNDg2XSAyYWZiMSBpcyA3OTZjMjAwMCENClsgIDkyNC43NjQ2NDNdIDJhZmIy
IGlzIDc5NmMzMDAwIQ0KWyAgOTI0Ljc2Njc1M10gMmFmYjMgaXMgNzk2YzQwMDAhDQpbICA5
MjQuNzY4ODIzXSAyYWZiNCBpcyA3OTZjNTAwMCENClsgIDkyNC43NzEyNDVdIDJhZmI1IGlz
IDc5NmMxMDAwIQ0KWyAgOTI0Ljc4MTQ1M10gMmFmYjYgaXMgNzk2YzAwMDAhDQpbICA5Mjgu
MDg0OTk4XSAyYWZiNyBpcyA3OTZiZjAwMCENClsgIDkyOC4wODg1NjVdIDJhZjg4IGlzIDc5
NmJlMDAwIQ0KWyAgOTI4LjA5MTA1MV0gMmFmOWIgaXMgNzk2YmQwMDAhDQpbICA5MjguMTA1
NzY0XSAzNmU4NiBpcyA3OTZiYzAwMCENClsgIDkyOC4xMTcyNTddIDM4YzU0IGlzIDc5NmI4
MDAwIQ0KWyAgOTI4LjEzMTAyNV0gMmFmZTcgaXMgNzk2YWMwMDAhDQpbICA5MjguMTMzMDA0
XSAyYWZlOCBpcyA3OTZhYjAwMCENClsgIDkyOC4xMzQ5OTFdIDJhZmU5IGlzIDIxNmRiMDAw
IQ0KWyAgOTI4LjEzNzAxM10gMmFmZWEgaXMgNzk1OTUwMDAhDQpbICA5MjguMTM4OTk1XSAy
YWZlYiBpcyA3OTU2NjAwMCENClsgIDkyOC4xNDA5ODFdIDJhZmVjIGlzIDIxOWMxMDAwIQ0K
WyAgOTI4LjE0Mjk2N10gMmFmZWQgaXMgNzk2ZWEwMDAhDQpbICA5MjguMTQ1MDg0XSAyYWZl
ZSBpcyA3OTZiMzAwMCENClsgIDkyOC4xNDcxMjhdIDJhZmVmIGlzIDdhNWU2MDAwIQ0KWyAg
OTI4LjE0OTEyOV0gMmFmZjAgaXMgNzk2YWUwMDAhDQpbICA5MjguMTUxMTY3XSAyYWZmMSBp
cyA3OTQ0ZDAwMCENClsgIDkyOC4xNTMxNzJdIDJhZmYyIGlzIDc5NTZmMDAwIQ0KWyAgOTI4
LjE1NTIwN10gMmFmZjMgaXMgNzhjNTUwMDAhDQpbICA5MjguMTU3ODE2XSAyYWZmNCBpcyA3
OTZhNjAwMCENClsgIDkyOC4xNTk5MzBdIDJhZmY1IGlzIDc5NmE3MDAwIQ0KWyAgOTI4LjE2
MTk3Nl0gMmFmZjYgaXMgMjE2YzMwMDAhDQpbICA5MjguMTY0MDM4XSAyYWZmNyBpcyA3OTUw
MDAwMCENClsgIDkyOC4xNjYwNTZdIDJhZmY4IGlzIDc5NmQxMDAwIQ0KWyAgOTI4LjE2ODE4
Ml0gMmFmZjkgaXMgNzk1OGQwMDAhDQpbICA5MjguMTcwMTkzXSAyYWZmYSBpcyAyMWU0YTAw
MCENClsgIDkyOC4xNzIyMDRdIDJhZmZiIGlzIDc5NTcwMDAwIQ0KWyAgOTI4LjE3NDIzNF0g
MmFmZmMgaXMgNzk1MzkwMDAhDQpbICA5MjguMTc2MjU0XSAyYWZmZCBpcyA3OTUzYzAwMCEN
ClsgIDkyOC4xNzgyNzFdIDJhZmZlIGlzIDc5NTU4MDAwIQ0KWyAgOTI4LjE4MDMxMV0gMmFm
ZmYgaXMgNzk1OTEwMDAhDQpbICA5MjguMTgyMzE1XSAyYTQwMCBpcyAyMTVmMDAwMCENClsg
IDkyOC4xODQzNzJdIDJhNDAxIGlzIDIxZjYzMDAwIQ0KWyAgOTI4LjE4NjM4MV0gMmE0MDIg
aXMgMjE2Y2QwMDAhDQpbICA5MjguMTg4NDI1XSAyYTQwMyBpcyA3OTU0YjAwMCENClsgIDky
OC4yMDAzMzddIDJhNDA0IGlzIDc5NjliMDAwIQ0KWyAgOTI4LjIwMjQwNF0gMmE0MDYgaXMg
Nzk2OWMwMDAhDQpbICA5MjguMjA0NTEwXSAyYTQwNyBpcyA3OTY5ZDAwMCENClsgIDkyOC4y
MDY0NjZdIDJhNDA4IGlzIDc5NjllMDAwIQ0KWyAgOTI4LjIwODQ2M10gMmE0MDkgaXMgNzk2
OWYwMDAhDQpbICA5MjguMjEwNDI3XSAyYTQwYSBpcyA3OTZhMDAwMCENClsgIDkyOC4yMTIz
MzldIDJhNDBiIGlzIDc5NmExMDAwIQ0KWyAgOTI4LjIxNDI4MF0gMmE0MGMgaXMgNzk2YTIw
MDAhDQpbICA5MjguMjE2MTY0XSAyYTQwZCBpcyA3OTZhMzAwMCENClsgIDkyOC4yMTgwNjVd
IDJhNDBlIGlzIDc5NmE0MDAwIQ0KWyAgOTI4LjIxOTkxOV0gMmE0MGYgaXMgNzk2YTUwMDAh
DQpbICA5MjguMjIyMzU0XSAyYTQxOCBpcyA3OTY5ODAwMCENClsgIDkyOC4yMjQyNDVdIDJh
NDE5IGlzIDc5Njk5MDAwIQ0KWyAgOTI4LjIyNjA5Ml0gMmE0MWEgaXMgNzk2OWEwMDAhDQpb
ICA5MjguMjI4MTcyXSAyYTQxNyBpcyA3OTY3NDAwMCENClsgIDkyOC4yMzAwMjZdIDJhNDE2
IGlzIDc5Njc1MDAwIQ0KWyAgOTI4LjIzMTgyMl0gMmE0MTUgaXMgNzk2NzYwMDAhDQpbICA5
MjguMjMzNjQ3XSAyYTQxNCBpcyA3OTY3NzAwMCENClsgIDkyOC4yMzU0MjBdIDJhNDEzIGlz
IDc5Njc4MDAwIQ0KWyAgOTI4LjIzNzE5MF0gMmE0MTIgaXMgNzk2NzkwMDAhDQpbICA5Mjgu
MjM4OTQ1XSAyYTQxMSBpcyA3OTY3YTAwMCENClsgIDkyOC4yNDA2OTBdIDJhNDEwIGlzIDc5
NjdiMDAwIQ0KWyAgOTI4LjI0MjQxOF0gMmE0MjQgaXMgNzk2N2MwMDAhDQpbICA5MjguMjQ0
MTI5XSAyYTQyMyBpcyA3OTY3ZDAwMCENClsgIDkyOC4yNDU4MjhdIDJhNDIyIGlzIDc5Njdl
MDAwIQ0KWyAgOTI4LjI0NzU2N10gMmE0MjEgaXMgNzk2N2YwMDAhDQpbICA5MjguMjQ5Mjc3
XSAyYTQyMCBpcyA3OTY4MDAwMCENClsgIDkyOC4yNTEwMDRdIDJhNDFmIGlzIDc5NjgxMDAw
IQ0KWyAgOTI4LjI1MjY5Nl0gMmE0MWUgaXMgNzk2ODIwMDAhDQpbICA5MjguMjU0NDA5XSAy
YTQxZCBpcyA3OTY4MzAwMCENClsgIDkyOC4yNTYwODddIDJhNDFjIGlzIDc5Njg0MDAwIQ0K
WyAgOTI4LjI1Nzc1N10gMmE0MWIgaXMgNzk2ODUwMDAhDQpbICA5MjguMjYwMjIyXSAyYTQw
NSBpcyA3OTY1ZjAwMCENClsgIDkyOC4yNjE5NDddIDJhNDI1IGlzIDc5NjYwMDAwIQ0KWyAg
OTI4LjI2MzY3M10gMmE0MjYgaXMgNzk2NjEwMDAhDQpbICA5MjguMjY1MzQxXSAyYTQyNyBp
cyA3OTY2MjAwMCENClsgIDkyOC4yNjcwNjNdIDJhNDI4IGlzIDc5NjYzMDAwIQ0KWyAgOTI4
LjI2ODczOF0gMmE0MjkgaXMgNzk2NjQwMDAhDQpbICA5MjguMjcwNDM0XSAyYTQyYSBpcyA3
OTY2NTAwMCENClsgIDkyOC4yNzIxMzNdIDJhNDJiIGlzIDc5NjY2MDAwIQ0KWyAgOTI4LjI3
MzgxOF0gMmE0MmMgaXMgNzk2NjcwMDAhDQpbICA5MjguMjc1NTE2XSAyYTQyZCBpcyA3OTY2
ODAwMCENClsgIDkyOC4yNzczMDBdIDJhNDJlIGlzIDc5NjY5MDAwIQ0KWyAgOTI4LjI3ODk0
Ml0gMmE0MmYgaXMgNzk2NmEwMDAhDQpbICA5MjguMjgwNjIxXSAyYTQzMCBpcyA3OTY2YjAw
MCENClsgIDkyOC4yODIyNzJdIDJhNDMxIGlzIDc5NjZjMDAwIQ0KWyAgOTI4LjI4Mzk1OF0g
MmE0MzIgaXMgNzk2NmQwMDAhDQpbICA5MjguMjg1NjAyXSAyYTQzMyBpcyA3OTY2ZTAwMCEN
ClsgIDkyOC4yODcyNzBdIDJhNDM0IGlzIDc5NjZmMDAwIQ0KWyAgOTI4LjI4ODk0NF0gMmE0
MzUgaXMgNzk2NzAwMDAhDQpbICA5MjguMjkwNjIyXSAyYTQzNiBpcyA3OTY3MTAwMCENClsg
IDkyOC4yOTIzMDhdIDJhNDM3IGlzIDc5NjcyMDAwIQ0KWyAgOTI4LjI5Mzk5OF0gMmE0Mzgg
aXMgNzk2NzMwMDAhDQpbICA5MjguMjk5MjcwXSAyYTQzOSBpcyA3OTY1NDAwMCENClsgIDky
OC4zMDEwNDhdIDJhNDNhIGlzIDc5NjU1MDAwIQ0KWyAgOTI4LjMwMjcyNF0gMmE0M2IgaXMg
Nzk2NTYwMDAhDQpbICA5MjguMzA0NDQxXSAyYTQzYyBpcyA3OTY1NzAwMCENClsgIDkyOC4z
MDYxMThdIDJhNDNkIGlzIDc5NjU4MDAwIQ0KWyAgOTI4LjMwNzgxN10gMmE0M2UgaXMgNzk2
NTkwMDAhDQpbICA5MjguMzA5NDk0XSAyYTQzZiBpcyA3OTY1YTAwMCENClsgIDkyOC4zMTEx
NzNdIDJhNDQwIGlzIDc5NjViMDAwIQ0KWyAgOTI4LjMxMjg1OV0gMmE0NDEgaXMgNzk2NWMw
MDAhDQpbICA5MjguMzE0NTQ4XSAyYTQ0MiBpcyA3OTY1ZDAwMCENClsgIDkyOC4zMTYyMjVd
IDJhNDQzIGlzIDc5NjVlMDAwIQ0KWyAgOTI4LjMxODEzMF0gMmE0NDQgaXMgNzk2NDkwMDAh
DQpbICA5MjguMzE5Nzk2XSAyYTQ0NSBpcyA3OTY0YTAwMCENClsgIDkyOC4zMjE0OThdIDJh
NDQ2IGlzIDc5NjRiMDAwIQ0KWyAgOTI4LjMyMzE1OF0gMmE0NDcgaXMgNzk2NGMwMDAhDQpb
ICA5MjguMzI0ODMwXSAyYTQ0OCBpcyA3OTY0ZDAwMCENClsgIDkyOC4zMjY0OTldIDJhNDQ5
IGlzIDc5NjRlMDAwIQ0KWyAgOTI4LjMyODE3MF0gMmE0NGEgaXMgNzk2NGYwMDAhDQpbICA5
MjguMzI5ODQ2XSAyYTQ0YiBpcyA3OTY1MDAwMCENClsgIDkyOC4zMzE1MjhdIDJhNDRjIGlz
IDc5NjUxMDAwIQ0KWyAgOTI4LjMzMzIwNl0gMmE0NGQgaXMgNzk2NTIwMDAhDQpbICA5Mjgu
MzM0OTE0XSAyYTQ0ZSBpcyA3OTY1MzAwMCENClsgIDkyOC4zMzY1OTBdIDJhNDRmIGlzIDc5
NjQ2MDAwIQ0KWyAgOTI4LjMzODMzMV0gMmE0NTAgaXMgNzk2NDcwMDAhDQpbICA5MjguMzQw
MDI1XSAyYTQ1MSBpcyA3OTY0ODAwMCENClsgIDkyOC4zNTMwNDFdIDJhNDUyIGlzIDc5NjI2
MDAwIQ0KWyAgOTI4LjM1NDc5M10gMmE0NTMgaXMgNzk2MjcwMDAhDQpbICA5MjguMzU2NDg0
XSAyYTQ1NCBpcyA3OTYyODAwMCENClsgIDkyOC4zNTgxOThdIDJhNDU1IGlzIDc5NjI5MDAw
IQ0KWyAgOTI4LjM1OTg4Nl0gMmE0NTYgaXMgNzk2MmEwMDAhDQpbICA5MjguMzYxNTgyXSAy
YTQ1NyBpcyA3OTYyYjAwMCENClsgIDkyOC4zNjMyNzldIDJhNDU4IGlzIDc5NjQ1MDAwIQ0K
WyAgOTI4LjM3MTMwOF0gMmE0NTkgaXMgNzk2MjUwMDAhDQpbICA5MjguMzg0NDA2XSAyYWY5
ZCBpcyA3OTVmMTAwMCENClsgIDkyOC4zODYxMjNdIDJhNDVhIGlzIDc5NWYwMDAwIQ0KWyAg
OTI4LjM4Nzg3NV0gMmE0NWIgaXMgNzk1ZWYwMDAhDQpbICA5MjguMzg5NTk0XSAyYTQ1YyBp
cyA3OTVlZTAwMCENClsgIDkyOC4zOTE4NTldIDJhNDVlIGlzIDc5NWY1MDAwIQ0KWyAgOTI4
LjM5MzYyNl0gMmE0NWYgaXMgNzk1ZjQwMDAhDQpbICA5MjguMzk1MzUwXSAyYTQ2MCBpcyA3
OTVmMzAwMCENClsgIDkyOC4zOTcxMzZdIDJhNDYxIGlzIDc5NWYyMDAwIQ0KWyAgOTI4LjQw
NTUxMF0gMmE0NjIgaXMgNzk1Y2YwMDAhDQpbICA5MjguNDE2ODMzXSAyYTQ1ZCBpcyA3OTVk
MDAwMCENClsgIDkyOC40MzI5NjZdIDJhNDYzIGlzIDc5NWQ0MDAwIQ0KWyAgOTI4LjQzNDgy
N10gMmE0NjQgaXMgNzk1ZDMwMDAhDQpbICA5MjguNDM2NTk3XSAyYTQ2NSBpcyA3OTVkMjAw
MCENClsgIDkyOC40Mzg0MTFdIDJhNDY2IGlzIDc5NWQxMDAwIQ0KWyAgOTI4LjQ0MDc4M10g
MmE0NjcgaXMgNzk1ZDkwMDAhDQpbICA5MjguNDQyNTc3XSAzNmU4NyBpcyA3OTVkODAwMCEN
ClsgIDkyOC40NDQ0MDNdIDM5MzE0IGlzIDc5NWQ3MDAwIQ0KWyAgOTI4LjQ0NjIzOV0gMzkz
MTUgaXMgNzk1ZDYwMDAhDQpbICA5MjguNDQ4MDY2XSAyYWZjYyBpcyA3OTVkNTAwMCENClsg
IDkyOC40NjI2NTFdIDJhZmNkIGlzIDc5NWRiMDAwIQ0KWyAgOTI4LjQ2NDUwNl0gMmFmY2Ug
aXMgNzk1ZGEwMDAhDQpbICA5MjguNDc4MTA3XSAyYWZjZiBpcyA3OTVkZDAwMCENClsgIDky
OC40Nzk5NDJdIDJhZmQwIGlzIDc5NWRjMDAwIQ0KWyAgOTI4LjQ4OTAyOV0gMmE0NjggaXMg
Nzk1ZGUwMDAhDQpbICA5MjguNDk5MDU4XSAyYWZkMSBpcyA3OTVkZjAwMCENClsgIDkzMy40
MjIwOTJdIDJhZmQyIGlzIDdhMjQxMDAwIQ0KWyAgOTMzLjQyMzk5NV0gMzgyYjkgaXMgMmRj
ZjkwMDAhDQpbICA5MzMuNDI1OTA2XSAzNzczZSBpcyA3OTZmNzAwMCENClsgIDkzMy40Mjc4
NTZdIDJhNDgxIGlzIDIxZGVkMDAwIQ0KWyAgOTMzLjQyOTgzOF0gMmE0NjkgaXMgMjRlMjIw
MDAhDQpbICA5MzMuNDMxODMzXSAyYTQ2YSBpcyAyMWI3NzAwMCENClsgIDkzMy40NDMwNDJd
IDJhNDZiIGlzIDIxYjc2MDAwIQ0KWyAgOTQxLjgwODI4Nl0gMmFmZDMgaXMgNzk1ZGQwMDAh
DQpbICA5NDEuODEwMzQzXSAyYTQ2ZiBpcyA3OTVkYzAwMCENClsgIDk0NC4zMjg2MTldIDJh
NDZlIGlzIDc4YmViMDAwIQ0KWyAgOTQ0LjMzMDcwOV0gMmE0NmMgaXMgNzkxZmIwMDAhDQpb
ICA5NDcuNDIyMjcyXSAyYTQ3MCBpcyAyNGUyMjAwMCENClsgIDk0Ny40MjQ0NTVdIDJhNDcx
IGlzIDc5NmY3MDAwIQ0KWyAgOTQ3LjQyNjYwMl0gMmE0NzIgaXMgMjFkZWQwMDAhDQpbICA5
NDcuNDI4Nzk1XSAyYTQ3MyBpcyA3YTI0MTAwMCENClsgIDk0Ny40MzA5NjRdIDJhNDc0IGlz
IDJkY2VkMDAwIQ0KWyAgOTQ3LjQzMzE0OF0gMmE0NzUgaXMgN2EyMGYwMDAhDQpbICA5NDcu
NDM1MzM1XSAyYTQ3NiBpcyAyNmQyYzAwMCENClsgIDk0Ny40Mzc1NzNdIDJhNDc3IGlzIDc4
Y2YyMDAwIQ0KWyAgOTQ3LjQ0NzUzN10gMmE0NzggaXMgMjE5YzMwMDAhDQpbICA5NTQuMzI5
NTUwXSAzNzZjNiBpcyAyNmQyYzAwMCENClsgIDk1NC4zMzE4ODBdIDJhNDc5IGlzIDdhMjQx
MDAwIQ0KWyAgOTU0LjMzNDI0M10gMzhjZjUgaXMgN2EyMGYwMDAhDQpbICA5NTQuMzM2NTkx
XSAyYTQ3YSBpcyAyMWRlZDAwMCENClsgIDk1NC4zMzg5ODZdIDJhNDdiIGlzIDI0ZTBkMDAw
IQ0KWyAgOTU0LjM0MTQyN10gMmE0N2MgaXMgMjRlMjIwMDAhDQpbICA5NTQuMzQzODczXSAy
YTQ3ZCBpcyA3OTZmNzAwMCENClsgIDk1NC4zNDYyODRdIDJhNDdlIGlzIDJkY2Y5MDAwIQ0K
WyAgOTU0LjM0ODczMV0gMmE0N2YgaXMgMmRjZWQwMDAhDQpbICA5NTkuMzI4ODc1XSAzN2Yy
NiBpcyA3OTZiYzAwMCENClsgIDk1OS4zMzEzNjNdIDM2NDYwIGlzIDIxNzdjMDAwIQ0KWyAg
OTU5LjMzMzk0NV0gMzdiY2EgaXMgNzhmMWUwMDAhDQpbICA5NTkuMzM2NTA5XSAzNzY3YyBp
cyAyMTllYTAwMCENClsgIDk1OS4zMzkwMjVdIDM3ZTFjIGlzIDIxNjA0MDAwIQ0K
------------0CA04210C17B3F3A8
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

------------0CA04210C17B3F3A8--



From xen-devel-bounces@lists.xen.org Tue Sep 04 18:10:29 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Sep 2012 18:10: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 1T8xZe-000785-QC; Tue, 04 Sep 2012 18:10:06 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <linux@eikelenboom.it>) id 1T8xSq-0006zC-OJ
	for xen-devel@lists.xen.org; Tue, 04 Sep 2012 18:03:06 +0000
Received: from [85.158.139.83:61107] by server-6.bemta-5.messagelabs.com id
	7D/D9-21336-75246405; Tue, 04 Sep 2012 18:03:03 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-7.tower-182.messagelabs.com!1346781767!24604452!1
X-Originating-IP: [188.40.164.121]
X-SpamReason: No, hits=2.6 required=7.0 tests=BODY_RANDOM_LONG, UNIQUE_WORDS
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25357 invoked from network); 4 Sep 2012 18:02:47 -0000
Received: from static.121.164.40.188.clients.your-server.de (HELO
	smtp.eikelenboom.it) (188.40.164.121)
	by server-7.tower-182.messagelabs.com with AES256-SHA encrypted SMTP;
	4 Sep 2012 18:02:47 -0000
Received: from 128-64-ftth.onsneteindhoven.nl ([88.159.64.128]:56377
	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 1T8xPV-00056Z-0p; Tue, 04 Sep 2012 19:59:38 +0200
Date: Tue, 4 Sep 2012 20:02:41 +0200
From: Sander Eikelenboom <linux@eikelenboom.it>
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <8328705.20120904200241@eikelenboom.it>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
In-Reply-To: <20120904163903.GI23361@phenom.dumpdata.com>
References: <1136369816.20120904183757@eikelenboom.it>
	<20120904163903.GI23361@phenom.dumpdata.com>
MIME-Version: 1.0
Content-Type: multipart/mixed;
 boundary="----------0CA04210C17B3F3A8"
X-Mailman-Approved-At: Tue, 04 Sep 2012 18:10:05 +0000
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] dom0 linux 3.6.0-rc4,
	crash due to ballooning althoug dom0_mem=X, max:X 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>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

------------0CA04210C17B3F3A8
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit


Tuesday, September 4, 2012, 6:39:03 PM, you wrote:

> On Tue, Sep 04, 2012 at 06:37:57PM +0200, Sander Eikelenboom wrote:
>> Hi Konrad,
>> 
>> This seems to happen only on a intel machine i'm trying to setup as a development machine (haven't seen it on my amd).
>> It boots fine, i have dom0_mem=1024M,max:1024M set, the machine has 2G of mem.
>> 
>> Dom0 and guest kernel are 3.6.0-rc4 with config:
>> [*] Xen memory balloon driver
>> [*]   Scrub pages before returning them to system

> Can you also try this patch out and provide the full log (bootup and such). Thanks!

After applying this patch and due to the removal of the BUG_ON the domU boots and is reachable by SSH.
Serial log attached.



> diff --git a/drivers/xen/balloon.c b/drivers/xen/balloon.c
> index 31ab82f..871a93c 100644
> --- a/drivers/xen/balloon.c
> +++ b/drivers/xen/balloon.c
> @@ -355,8 +355,12 @@ static enum bp_state increase_reservation(unsigned long nr_pages)
>                 BUG_ON(page == NULL);
>  
>                 pfn = page_to_pfn(page);
> -               BUG_ON(!xen_feature(XENFEAT_auto_translated_physmap) &&
> -                      phys_to_machine_mapping_valid(pfn));
> +               if (!xen_feature(XENFEAT_auto_translated_physmap)) {
> +                       if (phys_to_machine_mapping_valid(pfn)) {
> +                               printk(KERN_DEBUG "%lx is %lx!\n", pfn, get_phys_to_machine(pfn));
> +                               continue;
> +                       }
> +               }
>  
>                 set_phys_to_machine(pfn, frame_list[i]);
>  
> @@ -572,6 +576,7 @@ static void __init balloon_add_region(unsigned long start_pfn,
>          */
>         extra_pfn_end = min(max_pfn, start_pfn + pages);
>  
> +       printk(KERN_INFO "%s: [%lx->%lx]\n", __func__, start_pfn, extra_pfn_end);
>         for (pfn = start_pfn; pfn < extra_pfn_end; pfn++) {
>                 page = pfn_to_page(pfn);
>                 /* totalram_pages and totalhigh_pages do not

------------0CA04210C17B3F3A8
Content-Type: text/plain;
 name="serial-log.txt"
Content-transfer-encoding: base64
Content-Disposition: attachment;
 filename="serial-log.txt"

IF9fICBfXyAgICAgICAgICAgIF8gIF8gICAgX19fXyAgICBfX18gICAgICAgICAgICAgIF8g
IF8gICAgICAgICAgICAgICAgICAgICANCiBcIFwvIC9fX18gXyBfXyAgIHwgfHwgfCAgfF9f
XyBcICAvIF8gXCAgICBfIF9fIF9fX3wgfHwgfCAgICAgXyBfXyAgXyBfXyBfX18gDQogIFwg
IC8vIF8gXCAnXyBcICB8IHx8IHxfICAgX18pIHx8IHwgfCB8X198ICdfXy8gX198IHx8IHxf
IF9ffCAnXyBcfCAnX18vIF8gXA0KICAvICBcICBfXy8gfCB8IHwgfF9fICAgX3wgLyBfXy8g
fCB8X3wgfF9ffCB8IHwgKF9ffF9fICAgX3xfX3wgfF8pIHwgfCB8ICBfXy8NCiAvXy9cX1xf
X198X3wgfF98ICAgIHxffChfKV9fX19fKF8pX19fLyAgIHxffCAgXF9fX3wgIHxffCAgICB8
IC5fXy98X3wgIFxfX198DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgfF98ICAgICAgICAgICAgIA0KKFhFTikgWGVuIHZl
cnNpb24gNC4yLjAtcmM0LXByZSAocm9vdEApIChnY2MgKERlYmlhbiA0LjQuNS04KSA0LjQu
NSkgTW9uIFNlcCAgMyAxODozMjowNyBDRVNUIDIwMTINCihYRU4pIExhdGVzdCBDaGFuZ2VT
ZXQ6IFRodSBBdWcgMzAgMTg6MTc6MjAgMjAxMiArMDEwMCAyNTc5MTo5ZTU2NjVmOWY0MzAN
CihYRU4pIEJvb3Rsb2FkZXI6IEdSVUIgMS45OCsyMDEwMDgwNC0xNCtzcXVlZXplMQ0KKFhF
TikgQ29tbWFuZCBsaW5lOiBkb20wX21lbT0xMDI0TSxtYXg6MTAyNE0gbG9nbHZsPWFsbCBs
b2dsdmxfZ3Vlc3Q9YWxsIGNvbnNvbGVfdGltZXN0YW1wcyB2Z2E9Z2Z4LTgwMHg2MDB4OCBu
b3JlYm9vdCBkZWJ1ZyBsYXBpYz1kZWJ1ZyBhcGljX3ZlcmJvc2l0eT1kZWJ1ZyBhcGljPWRl
YnVnIGlvbW11PW9uLHZlcmJvc2UsZGVidWcgY29tMT0zODQwMCw4bjEgY29uc29sZT12Z2Es
Y29tMQ0KKFhFTikgVmlkZW8gaW5mb3JtYXRpb246DQooWEVOKSAgVkdBIGlzIGdyYXBoaWNz
IG1vZGUgODAweDYwMCwgOCBicHANCihYRU4pICBWQkUvRERDIG1ldGhvZHM6IG5vbmU7IEVE
SUQgdHJhbnNmZXIgdGltZTogMCBzZWNvbmRzDQooWEVOKSAgRURJRCBpbmZvIG5vdCByZXRy
aWV2ZWQgYmVjYXVzZSBubyBEREMgcmV0cmlldmFsIG1ldGhvZCBkZXRlY3RlZA0KKFhFTikg
RGlzYyBpbmZvcm1hdGlvbjoNCihYRU4pICBGb3VuZCAwIE1CUiBzaWduYXR1cmVzDQooWEVO
KSAgRm91bmQgMSBFREQgaW5mb3JtYXRpb24gc3RydWN0dXJlcw0KKFhFTikgWGVuLWU4MjAg
UkFNIG1hcDoNCihYRU4pICAwMDAwMDAwMDAwMDAwMDAwIC0gMDAwMDAwMDAwMDA5ZTgwMCAo
dXNhYmxlKQ0KKFhFTikgIDAwMDAwMDAwMDAwOWU4MDAgLSAwMDAwMDAwMDAwMGEwMDAwIChy
ZXNlcnZlZCkNCihYRU4pICAwMDAwMDAwMDAwMGU0MDAwIC0gMDAwMDAwMDAwMDEwMDAwMCAo
cmVzZXJ2ZWQpDQooWEVOKSAgMDAwMDAwMDAwMDEwMDAwMCAtIDAwMDAwMDAwN2VlNzAwMDAg
KHVzYWJsZSkNCihYRU4pICAwMDAwMDAwMDdlZTcwMDAwIC0gMDAwMDAwMDA3ZWU3ZTAwMCAo
QUNQSSBkYXRhKQ0KKFhFTikgIDAwMDAwMDAwN2VlN2UwMDAgLSAwMDAwMDAwMDdlZWQwMDAw
IChBQ1BJIE5WUykNCihYRU4pICAwMDAwMDAwMDdlZWQwMDAwIC0gMDAwMDAwMDA3ZWYwMDAw
MCAocmVzZXJ2ZWQpDQooWEVOKSAgMDAwMDAwMDBmZWQwMDAwMCAtIDAwMDAwMDAwZmVkMDEx
MDAgKHJlc2VydmVkKQ0KKFhFTikgIDAwMDAwMDAwZmVkMDIwMDAgLSAwMDAwMDAwMGZlZDE0
YzAwIChyZXNlcnZlZCkNCihYRU4pICAwMDAwMDAwMGZlZDIwMDAwIC0gMDAwMDAwMDBmZWQ0
MDAwMCAocmVzZXJ2ZWQpDQooWEVOKSAgMDAwMDAwMDBmZWUwMDAwMCAtIDAwMDAwMDAwZmVl
MDEwMDAgKHJlc2VydmVkKQ0KKFhFTikgIDAwMDAwMDAwZmZlMDAwMDAgLSAwMDAwMDAwMTAw
MDAwMDAwIChyZXNlcnZlZCkNCihYRU4pIFN5c3RlbSBSQU06IDIwMzBNQiAoMjA3ODc3NmtC
KQ0KKFhFTikgQUNQSTogUlNEUCAwMDBGQjA4MCwgMDAyNCAocjIgQUNQSUFNKQ0KKFhFTikg
QUNQSTogWFNEVCA3RUU3MDEwMCwgMDA1QyAocjEgQV9NX0lfIE9FTVhTRFQgICA1MDAxMDI1
IE1TRlQgICAgICAgOTcpDQooWEVOKSBBQ1BJOiBGQUNQIDdFRTcwMjkwLCAwMEY0IChyMyBB
X01fSV8gT0VNRkFDUCAgIDUwMDEwMjUgTVNGVCAgICAgICA5NykNCihYRU4pIEFDUEk6IERT
RFQgN0VFNzA0NDAsIDg0MUYgKHIxICBBMTA2NSBBMTA2NTAwMCAgICAgICAgMCBJTlRMIDIw
MDYwMTEzKQ0KKFhFTikgQUNQSTogRkFDUyA3RUU3RTAwMCwgMDA0MA0KKFhFTikgQUNQSTog
QVBJQyA3RUU3MDM5MCwgMDA2QyAocjEgQV9NX0lfIE9FTUFQSUMgICA1MDAxMDI1IE1TRlQg
ICAgICAgOTcpDQooWEVOKSBBQ1BJOiBNQ0ZHIDdFRTcwNDAwLCAwMDNDIChyMSBBX01fSV8g
T0VNTUNGRyAgIDUwMDEwMjUgTVNGVCAgICAgICA5NykNCihYRU4pIEFDUEk6IE9FTUIgN0VF
N0UwNDAsIDAwODkgKHIxIEFfTV9JXyBBTUlfT0VNICAgNTAwMTAyNSBNU0ZUICAgICAgIDk3
KQ0KKFhFTikgQUNQSTogSFBFVCA3RUU3ODg2MCwgMDAzOCAocjEgQV9NX0lfIE9FTUhQRVQg
ICA1MDAxMDI1IE1TRlQgICAgICAgOTcpDQooWEVOKSBBQ1BJOiBHU0NJIDdFRTdFMEQwLCAy
MDI0IChyMSBBX01fSV8gR01DSFNDSSAgIDUwMDEwMjUgTVNGVCAgICAgICA5NykNCihYRU4p
IEFDUEk6IFNTRFQgN0VFODBBMDAsIDBBN0MgKHIxIERwZ1BtbSAgICBDcHVQbSAgICAgICAx
MiBJTlRMIDIwMDYwMTEzKQ0KKFhFTikgTm8gTlVNQSBjb25maWd1cmF0aW9uIGZvdW5kDQoo
WEVOKSBGYWtpbmcgYSBub2RlIGF0IDAwMDAwMDAwMDAwMDAwMDAtMDAwMDAwMDA3ZWU3MDAw
MA0KKFhFTikgRG9tYWluIGhlYXAgaW5pdGlhbGlzZWQNCihYRU4pIHZlc2FmYjogZnJhbWVi
dWZmZXIgYXQgMHhmZDgwMDAwMCwgbWFwcGVkIHRvIDB4ZmZmZjgyYzAwMDAwMDAwMCwgdXNp
bmcgMjA0OGssIHRvdGFsIDQwOTZrDQooWEVOKSB2ZXNhZmI6IG1vZGUgaXMgODAweDYwMHg4
LCBsaW5lbGVuZ3RoPTgwMCwgZm9udCA4eDgNCihYRU4pIHZlc2FmYjogUHNldWRvY29sb3I6
IHNpemU9Njo2OjY6Niwgc2hpZnQ9MDowOjA6MA0KKFhFTikgZm91bmQgU01QIE1QLXRhYmxl
IGF0IDAwMGZmNzgwDQooWEVOKSBETUkgcHJlc2VudC4NCihYRU4pIEFQSUMgYm9vdCBzdGF0
ZSBpcyAneGFwaWMnDQooWEVOKSBVc2luZyBBUElDIGRyaXZlciBkZWZhdWx0DQooWEVOKSBB
Q1BJOiBQTS1UaW1lciBJTyBQb3J0OiAweDgwOA0KKFhFTikgQUNQSTogQUNQSSBTTEVFUCBJ
TkZPOiBwbTF4X2NudFs4MDQsMF0sIHBtMXhfZXZ0WzgwMCwwXQ0KKFhFTikgQUNQSTogICAg
ICAgICAgICAgICAgICB3YWtldXBfdmVjWzdlZTdlMDBjXSwgdmVjX3NpemVbMjBdDQooWEVO
KSBBQ1BJOiBMb2NhbCBBUElDIGFkZHJlc3MgMHhmZWUwMDAwMA0KKFhFTikgQUNQSTogTEFQ
SUMgKGFjcGlfaWRbMHgwMV0gbGFwaWNfaWRbMHgwMF0gZW5hYmxlZCkNCihYRU4pIFByb2Nl
c3NvciAjMCA3OjcgQVBJQyB2ZXJzaW9uIDIwDQooWEVOKSBBQ1BJOiBMQVBJQyAoYWNwaV9p
ZFsweDAyXSBsYXBpY19pZFsweDAxXSBlbmFibGVkKQ0KKFhFTikgUHJvY2Vzc29yICMxIDc6
NyBBUElDIHZlcnNpb24gMjANCihYRU4pIEFDUEk6IExBUElDIChhY3BpX2lkWzB4MDNdIGxh
cGljX2lkWzB4MDJdIGVuYWJsZWQpDQooWEVOKSBQcm9jZXNzb3IgIzIgNzo3IEFQSUMgdmVy
c2lvbiAyMA0KKFhFTikgQUNQSTogTEFQSUMgKGFjcGlfaWRbMHgwNF0gbGFwaWNfaWRbMHgw
M10gZW5hYmxlZCkNCihYRU4pIFByb2Nlc3NvciAjMyA3OjcgQVBJQyB2ZXJzaW9uIDIwDQoo
WEVOKSBBQ1BJOiBJT0FQSUMgKGlkWzB4MDRdIGFkZHJlc3NbMHhmZWMwMDAwMF0gZ3NpX2Jh
c2VbMF0pDQooWEVOKSBJT0FQSUNbMF06IGFwaWNfaWQgNCwgdmVyc2lvbiAzMiwgYWRkcmVz
cyAweGZlYzAwMDAwLCBHU0kgMC0yMw0KKFhFTikgQUNQSTogSU5UX1NSQ19PVlIgKGJ1cyAw
IGJ1c19pcnEgMCBnbG9iYWxfaXJxIDIgZGZsIGRmbCkNCihYRU4pIEFDUEk6IElOVF9TUkNf
T1ZSIChidXMgMCBidXNfaXJxIDkgZ2xvYmFsX2lycSA5IGhpZ2ggbGV2ZWwpDQooWEVOKSBB
Q1BJOiBJUlEwIHVzZWQgYnkgb3ZlcnJpZGUuDQooWEVOKSBBQ1BJOiBJUlEyIHVzZWQgYnkg
b3ZlcnJpZGUuDQooWEVOKSBBQ1BJOiBJUlE5IHVzZWQgYnkgb3ZlcnJpZGUuDQooWEVOKSBF
bmFibGluZyBBUElDIG1vZGU6ICBGbGF0LiAgVXNpbmcgMSBJL08gQVBJQ3MNCihYRU4pIEFD
UEk6IEhQRVQgaWQ6IDB4ODA4NmE3MDEgYmFzZTogMHhmZWQwMDAwMA0KKFhFTikgVGFibGUg
aXMgbm90IGZvdW5kIQ0KKFhFTikgVXNpbmcgQUNQSSAoTUFEVCkgZm9yIFNNUCBjb25maWd1
cmF0aW9uIGluZm9ybWF0aW9uDQooWEVOKSBTTVA6IEFsbG93aW5nIDQgQ1BVcyAoMCBob3Rw
bHVnIENQVXMpDQooWEVOKSBtYXBwZWQgQVBJQyB0byBmZmZmODJjM2ZmZGZlMDAwIChmZWUw
MDAwMCkNCihYRU4pIG1hcHBlZCBJT0FQSUMgdG8gZmZmZjgyYzNmZmRmZDAwMCAoZmVjMDAw
MDApDQooWEVOKSBJUlEgbGltaXRzOiAyNCBHU0ksIDc2MCBNU0kvTVNJLVgNCihYRU4pIFVz
aW5nIHNjaGVkdWxlcjogU01QIENyZWRpdCBTY2hlZHVsZXIgKGNyZWRpdCkNCihYRU4pIERl
dGVjdGVkIDI2NjYuNDQzIE1IeiBwcm9jZXNzb3IuDQooWEVOKSBJbml0aW5nIG1lbW9yeSBz
aGFyaW5nLg0KKFhFTikgeHN0YXRlX2luaXQ6IHVzaW5nIGNudHh0X3NpemU6IDB4MjQwIGFu
ZCBzdGF0ZXM6IDB4Mw0KKFhFTikgbWNlX2ludGVsLmM6MTIzOTogTUNBIENhcGFiaWxpdHk6
IEJDQVNUIDEgU0VSIDAgQ01DSSAwIGZpcnN0YmFuayAxIGV4dGVuZGVkIE1DRSBNU1IgMA0K
KFhFTikgSW50ZWwgbWFjaGluZSBjaGVjayByZXBvcnRpbmcgZW5hYmxlZA0KKFhFTikgUENJ
OiBNQ0ZHIGNvbmZpZ3VyYXRpb24gMDogYmFzZSBlMDAwMDAwMCBzZWdtZW50IDAwMDAgYnVz
ZXMgMDAgLSBmZg0KKFhFTikgUENJOiBOb3QgdXNpbmcgTUNGRyBmb3Igc2VnbWVudCAwMDAw
IGJ1cyAwMC1mZg0KKFhFTikgSS9PIHZpcnR1YWxpc2F0aW9uIGRpc2FibGVkDQooWEVOKSBH
ZXR0aW5nIFZFUlNJT046IDUwMDE0DQooWEVOKSBHZXR0aW5nIFZFUlNJT046IDUwMDE0DQoo
WEVOKSBHZXR0aW5nIElEOiAwDQooWEVOKSBHZXR0aW5nIExWVDA6IDcwMA0KKFhFTikgR2V0
dGluZyBMVlQxOiA0MDANCihYRU4pIGVuYWJsZWQgRXh0SU5UIG9uIENQVSMwDQooWEVOKSBF
TkFCTElORyBJTy1BUElDIElSUXMNCihYRU4pICAtPiBVc2luZyBuZXcgQUNLIG1ldGhvZA0K
KFhFTikgaW5pdCBJT19BUElDIElSUXMNCihYRU4pICBJTy1BUElDIChhcGljaWQtcGluKSA0
LTAsIDQtMTYsIDQtMTcsIDQtMTgsIDQtMTksIDQtMjAsIDQtMjEsIDQtMjIsIDQtMjMgbm90
IGNvbm5lY3RlZC4NCihYRU4pIC4uVElNRVI6IHZlY3Rvcj0weEYwIGFwaWMxPTAgcGluMT0y
IGFwaWMyPS0xIHBpbjI9LTENCihYRU4pIG51bWJlciBvZiBNUCBJUlEgc291cmNlczogMTUu
DQooWEVOKSBudW1iZXIgb2YgSU8tQVBJQyAjNCByZWdpc3RlcnM6IDI0Lg0KKFhFTikgdGVz
dGluZyB0aGUgSU8gQVBJQy4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uDQooWEVOKSBJTyBBUElD
ICM0Li4uLi4uDQooWEVOKSAuLi4uIHJlZ2lzdGVyICMwMDogMDQwMDAwMDANCihYRU4pIC4u
Li4uLi4gICAgOiBwaHlzaWNhbCBBUElDIGlkOiAwNA0KKFhFTikgLi4uLi4uLiAgICA6IERl
bGl2ZXJ5IFR5cGU6IDANCihYRU4pIC4uLi4uLi4gICAgOiBMVFMgICAgICAgICAgOiAwDQoo
WEVOKSAuLi4uIHJlZ2lzdGVyICMwMTogMDAxNzAwMjANCihYRU4pIC4uLi4uLi4gICAgIDog
bWF4IHJlZGlyZWN0aW9uIGVudHJpZXM6IDAwMTcNCihYRU4pIC4uLi4uLi4gICAgIDogUFJR
IGltcGxlbWVudGVkOiAwDQooWEVOKSAuLi4uLi4uICAgICA6IElPIEFQSUMgdmVyc2lvbjog
MDAyMA0KKFhFTikgLi4uLiBJUlEgcmVkaXJlY3Rpb24gdGFibGU6DQooWEVOKSAgTlIgTG9n
IFBoeSBNYXNrIFRyaWcgSVJSIFBvbCBTdGF0IERlc3QgRGVsaSBWZWN0OiAgIA0KKFhFTikg
IDAwIDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDAgICAgMDANCihYRU4p
ICAwMSAwMDEgMDEgIDAgICAgMCAgICAwICAgMCAgIDAgICAgMSAgICAxICAgIDI4DQooWEVO
KSAgMDIgMDAxIDAxICAwICAgIDAgICAgMCAgIDAgICAwICAgIDEgICAgMSAgICBGMA0KKFhF
TikgIDAzIDAwMSAwMSAgMCAgICAwICAgIDAgICAwICAgMCAgICAxICAgIDEgICAgMzANCihY
RU4pICAwNCAwMDEgMDEgIDAgICAgMCAgICAwICAgMCAgIDAgICAgMSAgICAxICAgIEYxDQoo
WEVOKSAgMDUgMDAxIDAxICAwICAgIDAgICAgMCAgIDAgICAwICAgIDEgICAgMSAgICAzOA0K
KFhFTikgIDA2IDAwMSAwMSAgMCAgICAwICAgIDAgICAwICAgMCAgICAxICAgIDEgICAgNDAN
CihYRU4pICAwNyAwMDEgMDEgIDAgICAgMCAgICAwICAgMCAgIDAgICAgMSAgICAxICAgIDQ4
DQooWEVOKSAgMDggMDAxIDAxICAwICAgIDAgICAgMCAgIDAgICAwICAgIDEgICAgMSAgICA1
MA0KKFhFTikgIDA5IDAwMSAwMSAgMSAgICAxICAgIDAgICAwICAgMCAgICAxICAgIDEgICAg
NTgNCihYRU4pICAwYSAwMDEgMDEgIDAgICAgMCAgICAwICAgMCAgIDAgICAgMSAgICAxICAg
IDYwDQooWEVOKSAgMGIgMDAxIDAxICAwICAgIDAgICAgMCAgIDAgICAwICAgIDEgICAgMSAg
ICA2OA0KKFhFTikgIDBjIDAwMSAwMSAgMCAgICAwICAgIDAgICAwICAgMCAgICAxICAgIDEg
ICAgNzANCihYRU4pICAwZCAwMDEgMDEgIDAgICAgMCAgICAwICAgMCAgIDAgICAgMSAgICAx
ICAgIDc4DQooWEVOKSAgMGUgMDAxIDAxICAwICAgIDAgICAgMCAgIDAgICAwICAgIDEgICAg
MSAgICA4OA0KKFhFTikgIDBmIDAwMSAwMSAgMCAgICAwICAgIDAgICAwICAgMCAgICAxICAg
IDEgICAgOTANCihYRU4pICAxMCAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAg
ICAwICAgIDAwDQooWEVOKSAgMTEgMDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAwICAgIDAg
ICAgMCAgICAwMA0KKFhFTikgIDEyIDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAw
ICAgIDAgICAgMDANCihYRU4pICAxMyAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAg
MCAgICAwICAgIDAwDQooWEVOKSAgMTQgMDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAwICAg
IDAgICAgMCAgICAwMA0KKFhFTikgIDE1IDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAg
ICAwICAgIDAgICAgMDANCihYRU4pICAxNiAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAg
ICAgMCAgICAwICAgIDAwDQooWEVOKSAgMTcgMDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAw
ICAgIDAgICAgMCAgICAwMA0KKFhFTikgVXNpbmcgdmVjdG9yLWJhc2VkIGluZGV4aW5nDQoo
WEVOKSBJUlEgdG8gcGluIG1hcHBpbmdzOg0KKFhFTikgSVJRMjQwIC0+IDA6Mg0KKFhFTikg
SVJRNDAgLT4gMDoxDQooWEVOKSBJUlE0OCAtPiAwOjMNCihYRU4pIElSUTI0MSAtPiAwOjQN
CihYRU4pIElSUTU2IC0+IDA6NQ0KKFhFTikgSVJRNjQgLT4gMDo2DQooWEVOKSBJUlE3MiAt
PiAwOjcNCihYRU4pIElSUTgwIC0+IDA6OA0KKFhFTikgSVJRODggLT4gMDo5DQooWEVOKSBJ
UlE5NiAtPiAwOjEwDQooWEVOKSBJUlExMDQgLT4gMDoxMQ0KKFhFTikgSVJRMTEyIC0+IDA6
MTINCihYRU4pIElSUTEyMCAtPiAwOjEzDQooWEVOKSBJUlExMzYgLT4gMDoxNA0KKFhFTikg
SVJRMTQ0IC0+IDA6MTUNCihYRU4pIC4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u
Li4uLiBkb25lLg0KKFhFTikgVXNpbmcgbG9jYWwgQVBJQyB0aW1lciBpbnRlcnJ1cHRzLg0K
KFhFTikgY2FsaWJyYXRpbmcgQVBJQyB0aW1lciAuLi4NCihYRU4pIC4uLi4uIENQVSBjbG9j
ayBzcGVlZCBpcyAyNjY2LjQxNjcgTUh6Lg0KKFhFTikgLi4uLi4gaG9zdCBidXMgY2xvY2sg
c3BlZWQgaXMgMzMzLjMwMjAgTUh6Lg0KKFhFTikgLi4uLi4gYnVzX3NjYWxlID0gMHgwMDAx
NTU1NQ0KKFhFTikgWzIwMTItMDktMDQgMTg6NDE6MjRdIFBsYXRmb3JtIHRpbWVyIGlzIDE0
LjMxOE1IeiBIUEVUDQooWEVOKSBbMjAxMi0wOS0wNCAxODo0MToyNF0gQWxsb2NhdGVkIGNv
bnNvbGUgcmluZyBvZiAzMiBLaUIuDQooWEVOKSBbMjAxMi0wOS0wNCAxODo0MToyNF0gVk1Y
OiBTdXBwb3J0ZWQgYWR2YW5jZWQgZmVhdHVyZXM6DQooWEVOKSBbMjAxMi0wOS0wNCAxODo0
MToyNF0gIC0gQVBJQyBNTUlPIGFjY2VzcyB2aXJ0dWFsaXNhdGlvbg0KKFhFTikgWzIwMTIt
MDktMDQgMTg6NDE6MjRdICAtIEFQSUMgVFBSIHNoYWRvdw0KKFhFTikgWzIwMTItMDktMDQg
MTg6NDE6MjRdICAtIFZpcnR1YWwgTk1JDQooWEVOKSBbMjAxMi0wOS0wNCAxODo0MToyNF0g
IC0gTVNSIGRpcmVjdC1hY2Nlc3MgYml0bWFwDQooWEVOKSBbMjAxMi0wOS0wNCAxODo0MToy
NF0gSFZNOiBBU0lEcyBkaXNhYmxlZC4NCihYRU4pIFsyMDEyLTA5LTA0IDE4OjQxOjI0XSBI
Vk06IFZNWCBlbmFibGVkDQooWEVOKSBbMjAxMi0wOS0wNCAxODo0MToyM10gbWFza2VkIEV4
dElOVCBvbiBDUFUjMQ0KKFhFTikgWzIwMTItMDktMDQgMTg6NDE6MjNdIG1hc2tlZCBFeHRJ
TlQgb24gQ1BVIzINCihYRU4pIFsyMDEyLTA5LTA0IDE4OjQxOjIzXSBtYXNrZWQgRXh0SU5U
IG9uIENQVSMzDQooWEVOKSBbMjAxMi0wOS0wNCAxODo0MToyNF0gQnJvdWdodCB1cCA0IENQ
VXMNCihYRU4pIFsyMDEyLTA5LTA0IDE4OjQxOjI0XSBIUEVUOiA4IHRpbWVycyAoOCB3aWxs
IGJlIHVzZWQgZm9yIGJyb2FkY2FzdCkNCihYRU4pIFsyMDEyLTA5LTA0IDE4OjQxOjI0XSBB
Q1BJIHNsZWVwIG1vZGVzOiBTMw0KKFhFTikgWzIwMTItMDktMDQgMTg6NDE6MjRdIG1jaGVj
a19wb2xsOiBNYWNoaW5lIGNoZWNrIHBvbGxpbmcgdGltZXIgc3RhcnRlZC4NCihYRU4pIFsy
MDEyLTA5LTA0IDE4OjQxOjI0XSAqKiogTE9BRElORyBET01BSU4gMCAqKioNCihYRU4pIFsy
MDEyLTA5LTA0IDE4OjQxOjI0XSBlbGZfcGFyc2VfYmluYXJ5OiBwaGRyOiBwYWRkcj0weDEw
MDAwMDAgbWVtc3o9MHhkNzQwMDANCihYRU4pIFsyMDEyLTA5LTA0IDE4OjQxOjI0XSBlbGZf
cGFyc2VfYmluYXJ5OiBwaGRyOiBwYWRkcj0weDFlMDAwMDAgbWVtc3o9MHhkZDBlOA0KKFhF
TikgWzIwMTItMDktMDQgMTg6NDE6MjRdIGVsZl9wYXJzZV9iaW5hcnk6IHBoZHI6IHBhZGRy
PTB4MWVkZTAwMCBtZW1zej0weDEzYzAwDQooWEVOKSBbMjAxMi0wOS0wNCAxODo0MToyNF0g
ZWxmX3BhcnNlX2JpbmFyeTogcGhkcjogcGFkZHI9MHgxZWYyMDAwIG1lbXN6PTB4ZGU2MDAw
DQooWEVOKSBbMjAxMi0wOS0wNCAxODo0MToyNF0gZWxmX3BhcnNlX2JpbmFyeTogbWVtb3J5
OiAweDEwMDAwMDAgLT4gMHgyY2Q4MDAwDQooWEVOKSBbMjAxMi0wOS0wNCAxODo0MToyNF0g
ZWxmX3hlbl9wYXJzZV9ub3RlOiBHVUVTVF9PUyA9ICJsaW51eCINCihYRU4pIFsyMDEyLTA5
LTA0IDE4OjQxOjI0XSBlbGZfeGVuX3BhcnNlX25vdGU6IEdVRVNUX1ZFUlNJT04gPSAiMi42
Ig0KKFhFTikgWzIwMTItMDktMDQgMTg6NDE6MjRdIGVsZl94ZW5fcGFyc2Vfbm90ZTogWEVO
X1ZFUlNJT04gPSAieGVuLTMuMCINCihYRU4pIFsyMDEyLTA5LTA0IDE4OjQxOjI0XSBlbGZf
eGVuX3BhcnNlX25vdGU6IFZJUlRfQkFTRSA9IDB4ZmZmZmZmZmY4MDAwMDAwMA0KKFhFTikg
WzIwMTItMDktMDQgMTg6NDE6MjRdIGVsZl94ZW5fcGFyc2Vfbm90ZTogRU5UUlkgPSAweGZm
ZmZmZmZmODFlZjIyMTANCihYRU4pIFsyMDEyLTA5LTA0IDE4OjQxOjI0XSBlbGZfeGVuX3Bh
cnNlX25vdGU6IEhZUEVSQ0FMTF9QQUdFID0gMHhmZmZmZmZmZjgxMDAxMDAwDQooWEVOKSBb
MjAxMi0wOS0wNCAxODo0MToyNF0gZWxmX3hlbl9wYXJzZV9ub3RlOiBGRUFUVVJFUyA9ICIh
d3JpdGFibGVfcGFnZV90YWJsZXN8cGFlX3BnZGlyX2Fib3ZlXzRnYiINCihYRU4pIFsyMDEy
LTA5LTA0IDE4OjQxOjI0XSBlbGZfeGVuX3BhcnNlX25vdGU6IFBBRV9NT0RFID0gInllcyIN
CihYRU4pIFsyMDEyLTA5LTA0IDE4OjQxOjI0XSBlbGZfeGVuX3BhcnNlX25vdGU6IExPQURF
UiA9ICJnZW5lcmljIg0KKFhFTikgWzIwMTItMDktMDQgMTg6NDE6MjRdIGVsZl94ZW5fcGFy
c2Vfbm90ZTogdW5rbm93biB4ZW4gZWxmIG5vdGUgKDB4ZCkNCihYRU4pIFsyMDEyLTA5LTA0
IDE4OjQxOjI0XSBlbGZfeGVuX3BhcnNlX25vdGU6IFNVU1BFTkRfQ0FOQ0VMID0gMHgxDQoo
WEVOKSBbMjAxMi0wOS0wNCAxODo0MToyNF0gZWxmX3hlbl9wYXJzZV9ub3RlOiBIVl9TVEFS
VF9MT1cgPSAweGZmZmY4MDAwMDAwMDAwMDANCihYRU4pIFsyMDEyLTA5LTA0IDE4OjQxOjI0
XSBlbGZfeGVuX3BhcnNlX25vdGU6IFBBRERSX09GRlNFVCA9IDB4MA0KKFhFTikgWzIwMTIt
MDktMDQgMTg6NDE6MjRdIGVsZl94ZW5fYWRkcl9jYWxjX2NoZWNrOiBhZGRyZXNzZXM6DQoo
WEVOKSBbMjAxMi0wOS0wNCAxODo0MToyNF0gICAgIHZpcnRfYmFzZSAgICAgICAgPSAweGZm
ZmZmZmZmODAwMDAwMDANCihYRU4pIFsyMDEyLTA5LTA0IDE4OjQxOjI0XSAgICAgZWxmX3Bh
ZGRyX29mZnNldCA9IDB4MA0KKFhFTikgWzIwMTItMDktMDQgMTg6NDE6MjVdICAgICB2aXJ0
X29mZnNldCAgICAgID0gMHhmZmZmZmZmZjgwMDAwMDAwDQooWEVOKSBbMjAxMi0wOS0wNCAx
ODo0MToyNV0gICAgIHZpcnRfa3N0YXJ0ICAgICAgPSAweGZmZmZmZmZmODEwMDAwMDANCihY
RU4pIFsyMDEyLTA5LTA0IDE4OjQxOjI1XSAgICAgdmlydF9rZW5kICAgICAgICA9IDB4ZmZm
ZmZmZmY4MmNkODAwMA0KKFhFTikgWzIwMTItMDktMDQgMTg6NDE6MjVdICAgICB2aXJ0X2Vu
dHJ5ICAgICAgID0gMHhmZmZmZmZmZjgxZWYyMjEwDQooWEVOKSBbMjAxMi0wOS0wNCAxODo0
MToyNV0gICAgIHAybV9iYXNlICAgICAgICAgPSAweGZmZmZmZmZmZmZmZmZmZmYNCihYRU4p
IFsyMDEyLTA5LTA0IDE4OjQxOjI1XSAgWGVuICBrZXJuZWw6IDY0LWJpdCwgbHNiLCBjb21w
YXQzMg0KKFhFTikgWzIwMTItMDktMDQgMTg6NDE6MjVdICBEb20wIGtlcm5lbDogNjQtYml0
LCBQQUUsIGxzYiwgcGFkZHIgMHgxMDAwMDAwIC0+IDB4MmNkODAwMA0KKFhFTikgWzIwMTIt
MDktMDQgMTg6NDE6MjVdIFBIWVNJQ0FMIE1FTU9SWSBBUlJBTkdFTUVOVDoNCihYRU4pIFsy
MDEyLTA5LTA0IDE4OjQxOjI1XSAgRG9tMCBhbGxvYy46ICAgMDAwMDAwMDA3NDAwMDAwMC0+
MDAwMDAwMDA3ODAwMDAwMCAoMjQ0NjE3IHBhZ2VzIHRvIGJlIGFsbG9jYXRlZCkNCihYRU4p
IFsyMDEyLTA5LTA0IDE4OjQxOjI1XSAgSW5pdC4gcmFtZGlzazogMDAwMDAwMDA3ZTU4OTAw
MC0+MDAwMDAwMDA3ZTlmZjYwMA0KKFhFTikgWzIwMTItMDktMDQgMTg6NDE6MjVdIFZJUlRV
QUwgTUVNT1JZIEFSUkFOR0VNRU5UOg0KKFhFTikgWzIwMTItMDktMDQgMTg6NDE6MjVdICBM
b2FkZWQga2VybmVsOiBmZmZmZmZmZjgxMDAwMDAwLT5mZmZmZmZmZjgyY2Q4MDAwDQooWEVO
KSBbMjAxMi0wOS0wNCAxODo0MToyNV0gIEluaXQuIHJhbWRpc2s6IGZmZmZmZmZmODJjZDgw
MDAtPmZmZmZmZmZmODMxNGU2MDANCihYRU4pIFsyMDEyLTA5LTA0IDE4OjQxOjI1XSAgUGh5
cy1NYWNoIG1hcDogZmZmZmZmZmY4MzE0ZjAwMC0+ZmZmZmZmZmY4MzM0ZjAwMA0KKFhFTikg
WzIwMTItMDktMDQgMTg6NDE6MjVdICBTdGFydCBpbmZvOiAgICBmZmZmZmZmZjgzMzRmMDAw
LT5mZmZmZmZmZjgzMzRmNGI0DQooWEVOKSBbMjAxMi0wOS0wNCAxODo0MToyNV0gIFBhZ2Ug
dGFibGVzOiAgIGZmZmZmZmZmODMzNTAwMDAtPmZmZmZmZmZmODMzNmQwMDANCihYRU4pIFsy
MDEyLTA5LTA0IDE4OjQxOjI1XSAgQm9vdCBzdGFjazogICAgZmZmZmZmZmY4MzM2ZDAwMC0+
ZmZmZmZmZmY4MzM2ZTAwMA0KKFhFTikgWzIwMTItMDktMDQgMTg6NDE6MjVdICBUT1RBTDog
ICAgICAgICBmZmZmZmZmZjgwMDAwMDAwLT5mZmZmZmZmZjgzNDAwMDAwDQooWEVOKSBbMjAx
Mi0wOS0wNCAxODo0MToyNV0gIEVOVFJZIEFERFJFU1M6IGZmZmZmZmZmODFlZjIyMTANCihY
RU4pIFsyMDEyLTA5LTA0IDE4OjQxOjI1XSBEb20wIGhhcyBtYXhpbXVtIDQgVkNQVXMNCihY
RU4pIFsyMDEyLTA5LTA0IDE4OjQxOjI1XSBlbGZfbG9hZF9iaW5hcnk6IHBoZHIgMCBhdCAw
eGZmZmZmZmZmODEwMDAwMDAgLT4gMHhmZmZmZmZmZjgxZDc0MDAwDQooWEVOKSBbMjAxMi0w
OS0wNCAxODo0MToyNV0gZWxmX2xvYWRfYmluYXJ5OiBwaGRyIDEgYXQgMHhmZmZmZmZmZjgx
ZTAwMDAwIC0+IDB4ZmZmZmZmZmY4MWVkZDBlOA0KKFhFTikgWzIwMTItMDktMDQgMTg6NDE6
MjVdIGVsZl9sb2FkX2JpbmFyeTogcGhkciAyIGF0IDB4ZmZmZmZmZmY4MWVkZTAwMCAtPiAw
eGZmZmZmZmZmODFlZjFjMDANCihYRU4pIFsyMDEyLTA5LTA0IDE4OjQxOjI1XSBlbGZfbG9h
ZF9iaW5hcnk6IHBoZHIgMyBhdCAweGZmZmZmZmZmODFlZjIwMDAgLT4gMHhmZmZmZmZmZjgx
ZjhjMDAwDQooWEVOKSBbMjAxMi0wOS0wNCAxODo0MToyNV0gU2NydWJiaW5nIEZyZWUgUkFN
OiAuLi4uLi4uLi5kb25lLg0KKFhFTikgWzIwMTItMDktMDQgMTg6NDE6MjVdIEluaXRpYWwg
bG93IG1lbW9yeSB2aXJxIHRocmVzaG9sZCBzZXQgYXQgMHg0MDAwIHBhZ2VzLg0KKFhFTikg
WzIwMTItMDktMDQgMTg6NDE6MjVdIFN0ZC4gTG9nbGV2ZWw6IEFsbA0KKFhFTikgWzIwMTIt
MDktMDQgMTg6NDE6MjVdIEd1ZXN0IExvZ2xldmVsOiBBbGwNCihYRU4pIFsyMDEyLTA5LTA0
IDE4OjQxOjI1XSBYZW4gaXMgcmVsaW5xdWlzaGluZyBWR0EgY29uc29sZS4NCihYRU4pIFsy
MDEyLTA5LTA0IDE4OjQxOjI1XSAqKiogU2VyaWFsIGlucHV0IC0+IERPTTAgKHR5cGUgJ0NU
UkwtYScgdGhyZWUgdGltZXMgdG8gc3dpdGNoIGlucHV0IHRvIFhlbikNCihYRU4pIFsyMDEy
LTA5LTA0IDE4OjQxOjI1XSBGcmVlZCAyNTZrQiBpbml0IG1lbW9yeS4NCm1hcHBpbmcga2Vy
bmVsIGludG8gcGh5c2ljYWwgbWVtb3J5DQphYm91dCB0byBnZXQgc3RhcnRlZC4uLg0KWyAg
ICAwLjAwMDAwMF0gSW5pdGlhbGl6aW5nIGNncm91cCBzdWJzeXMgY3B1c2V0DQpbICAgIDAu
MDAwMDAwXSBJbml0aWFsaXppbmcgY2dyb3VwIHN1YnN5cyBjcHUNClsgICAgMC4wMDAwMDBd
IExpbnV4IHZlcnNpb24gMy42LjAtcmM0LTIwMTIwODMwKyAocm9vdEB4ZW50ZXN0KSAoZ2Nj
IHZlcnNpb24gNC40LjUgKERlYmlhbiA0LjQuNS04KSApICM2OCBTTVAgUFJFRU1QVCBUdWUg
U2VwIDQgMjA6MzY6NDcgQ0VTVCAyMDEyDQpbICAgIDAuMDAwMDAwXSBDb21tYW5kIGxpbmU6
IHJvb3Q9L2Rldi9zZGExIHJvIHZlcmJvc2UgbWVtPTEwMjRNIGNvbnNvbGU9aHZjMCBjb25z
b2xlPXR0eTAgbm9tb2Rlc2V0IHZnYT0zMDMgZWFybHlwcmludGs9eGVuIG1heF9sb29wPTUw
IGxvb3BfbWF4X3BhcnQ9MTAgZGVidWcgbG9nbGV2ZWw9MTANClsgICAgMC4wMDAwMDBdIEZy
ZWVpbmcgOWUtMTAwIHBmbiByYW5nZTogOTggcGFnZXMgZnJlZWQNClsgICAgMC4wMDAwMDBd
IFJlbGVhc2VkIDk4IHBhZ2VzIG9mIHVudXNlZCBtZW1vcnkNClsgICAgMC4wMDAwMDBdIFNl
dCA1Mjg4ODIgcGFnZShzKSB0byAxLTEgbWFwcGluZw0KWyAgICAwLjAwMDAwMF0gUG9wdWxh
dGluZyA0MDAwMC00MDA2MiBwZm4gcmFuZ2U6IDk4IHBhZ2VzIGFkZGVkDQpbICAgIDAuMDAw
MDAwXSBlODIwOiBCSU9TLXByb3ZpZGVkIHBoeXNpY2FsIFJBTSBtYXA6DQpbICAgIDAuMDAw
MDAwXSBYZW46IFttZW0gMHgwMDAwMDAwMDAwMDAwMDAwLTB4MDAwMDAwMDAwMDA5ZGZmZl0g
dXNhYmxlDQpbICAgIDAuMDAwMDAwXSBYZW46IFttZW0gMHgwMDAwMDAwMDAwMDllODAwLTB4
MDAwMDAwMDAwMDBmZmZmZl0gcmVzZXJ2ZWQNClsgICAgMC4wMDAwMDBdIFhlbjogW21lbSAw
eDAwMDAwMDAwMDAxMDAwMDAtMHgwMDAwMDAwMDQwMDYxZmZmXSB1c2FibGUNClsgICAgMC4w
MDAwMDBdIFhlbjogW21lbSAweDAwMDAwMDAwNDAwNjIwMDAtMHgwMDAwMDAwMDdlZTZmZmZm
XSB1bnVzYWJsZQ0KWyAgICAwLjAwMDAwMF0gWGVuOiBbbWVtIDB4MDAwMDAwMDA3ZWU3MDAw
MC0weDAwMDAwMDAwN2VlN2RmZmZdIEFDUEkgZGF0YQ0KWyAgICAwLjAwMDAwMF0gWGVuOiBb
bWVtIDB4MDAwMDAwMDA3ZWU3ZTAwMC0weDAwMDAwMDAwN2VlY2ZmZmZdIEFDUEkgTlZTDQpb
ICAgIDAuMDAwMDAwXSBYZW46IFttZW0gMHgwMDAwMDAwMDdlZWQwMDAwLTB4MDAwMDAwMDA3
ZWVmZmZmZl0gcmVzZXJ2ZWQNClsgICAgMC4wMDAwMDBdIFhlbjogW21lbSAweDAwMDAwMDAw
ZmVjMDAwMDAtMHgwMDAwMDAwMGZlYzAwZmZmXSByZXNlcnZlZA0KWyAgICAwLjAwMDAwMF0g
WGVuOiBbbWVtIDB4MDAwMDAwMDBmZWQwMDAwMC0weDAwMDAwMDAwZmVkMDEwZmZdIHJlc2Vy
dmVkDQpbICAgIDAuMDAwMDAwXSBYZW46IFttZW0gMHgwMDAwMDAwMGZlZDAyMDAwLTB4MDAw
MDAwMDBmZWQxNGJmZl0gcmVzZXJ2ZWQNClsgICAgMC4wMDAwMDBdIFhlbjogW21lbSAweDAw
MDAwMDAwZmVkMjAwMDAtMHgwMDAwMDAwMGZlZDNmZmZmXSByZXNlcnZlZA0KWyAgICAwLjAw
MDAwMF0gWGVuOiBbbWVtIDB4MDAwMDAwMDBmZWUwMDAwMC0weDAwMDAwMDAwZmVlMDBmZmZd
IHJlc2VydmVkDQpbICAgIDAuMDAwMDAwXSBYZW46IFttZW0gMHgwMDAwMDAwMGZmZTAwMDAw
LTB4MDAwMDAwMDBmZmZmZmZmZl0gcmVzZXJ2ZWQNClsgICAgMC4wMDAwMDBdIGJvb3Rjb25z
b2xlIFt4ZW5ib290MF0gZW5hYmxlZA0KWyAgICAwLjAwMDAwMF0gTlggKEV4ZWN1dGUgRGlz
YWJsZSkgcHJvdGVjdGlvbjogYWN0aXZlDQpbICAgIDAuMDAwMDAwXSBlODIwOiB1c2VyLWRl
ZmluZWQgcGh5c2ljYWwgUkFNIG1hcDoNClsgICAgMC4wMDAwMDBdIHVzZXI6IFttZW0gMHgw
MDAwMDAwMDAwMDAwMDAwLTB4MDAwMDAwMDAwMDA5ZGZmZl0gdXNhYmxlDQpbICAgIDAuMDAw
MDAwXSB1c2VyOiBbbWVtIDB4MDAwMDAwMDAwMDA5ZTgwMC0weDAwMDAwMDAwMDAwZmZmZmZd
IHJlc2VydmVkDQpbICAgIDAuMDAwMDAwXSB1c2VyOiBbbWVtIDB4MDAwMDAwMDAwMDEwMDAw
MC0weDAwMDAwMDAwM2ZmZmZmZmZdIHVzYWJsZQ0KWyAgICAwLjAwMDAwMF0gdXNlcjogW21l
bSAweDAwMDAwMDAwNDAwNjIwMDAtMHgwMDAwMDAwMDdlZTZmZmZmXSB1bnVzYWJsZQ0KWyAg
ICAwLjAwMDAwMF0gdXNlcjogW21lbSAweDAwMDAwMDAwN2VlNzAwMDAtMHgwMDAwMDAwMDdl
ZTdkZmZmXSBBQ1BJIGRhdGENClsgICAgMC4wMDAwMDBdIHVzZXI6IFttZW0gMHgwMDAwMDAw
MDdlZTdlMDAwLTB4MDAwMDAwMDA3ZWVjZmZmZl0gQUNQSSBOVlMNClsgICAgMC4wMDAwMDBd
IHVzZXI6IFttZW0gMHgwMDAwMDAwMDdlZWQwMDAwLTB4MDAwMDAwMDA3ZWVmZmZmZl0gcmVz
ZXJ2ZWQNClsgICAgMC4wMDAwMDBdIHVzZXI6IFttZW0gMHgwMDAwMDAwMGZlYzAwMDAwLTB4
MDAwMDAwMDBmZWMwMGZmZl0gcmVzZXJ2ZWQNClsgICAgMC4wMDAwMDBdIHVzZXI6IFttZW0g
MHgwMDAwMDAwMGZlZDAwMDAwLTB4MDAwMDAwMDBmZWQwMTBmZl0gcmVzZXJ2ZWQNClsgICAg
MC4wMDAwMDBdIHVzZXI6IFttZW0gMHgwMDAwMDAwMGZlZDAyMDAwLTB4MDAwMDAwMDBmZWQx
NGJmZl0gcmVzZXJ2ZWQNClsgICAgMC4wMDAwMDBdIHVzZXI6IFttZW0gMHgwMDAwMDAwMGZl
ZDIwMDAwLTB4MDAwMDAwMDBmZWQzZmZmZl0gcmVzZXJ2ZWQNClsgICAgMC4wMDAwMDBdIHVz
ZXI6IFttZW0gMHgwMDAwMDAwMGZlZTAwMDAwLTB4MDAwMDAwMDBmZWUwMGZmZl0gcmVzZXJ2
ZWQNClsgICAgMC4wMDAwMDBdIHVzZXI6IFttZW0gMHgwMDAwMDAwMGZmZTAwMDAwLTB4MDAw
MDAwMDBmZmZmZmZmZl0gcmVzZXJ2ZWQNClsgICAgMC4wMDAwMDBdIERNSSBwcmVzZW50Lg0K
WyAgICAwLjAwMDAwMF0gRE1JOiBTeXN0ZW0gbWFudWZhY3R1cmVyIFN5c3RlbSBQcm9kdWN0
IE5hbWUvUDVRLUVNIERPLCBCSU9TIDEyMDggICAgMDUvMjUvMjAxMA0KWyAgICAwLjAwMDAw
MF0gZTgyMDogdXBkYXRlIFttZW0gMHgwMDAwMDAwMC0weDAwMDBmZmZmXSB1c2FibGUgPT0+
IHJlc2VydmVkDQpbICAgIDAuMDAwMDAwXSBlODIwOiByZW1vdmUgW21lbSAweDAwMGEwMDAw
LTB4MDAwZmZmZmZdIHVzYWJsZQ0KWyAgICAwLjAwMDAwMF0gTm8gQUdQIGJyaWRnZSBmb3Vu
ZA0KWyAgICAwLjAwMDAwMF0gZTgyMDogbGFzdF9wZm4gPSAweDQwMDAwIG1heF9hcmNoX3Bm
biA9IDB4NDAwMDAwMDAwDQpbICAgIDAuMDAwMDAwXSBmb3VuZCBTTVAgTVAtdGFibGUgYXQg
W21lbSAweDAwMGZmNzgwLTB4MDAwZmY3OGZdIG1hcHBlZCBhdCBbZmZmZjg4MDAwMDBmZjc4
MF0NClsgICAgMC4wMDAwMDBdIGluaXRpYWwgbWVtb3J5IG1hcHBlZDogW21lbSAweDAwMDAw
MDAwLTB4MDMxNGVmZmZdDQpbICAgIDAuMDAwMDAwXSBCYXNlIG1lbW9yeSB0cmFtcG9saW5l
IGF0IFtmZmZmODgwMDAwMDk4MDAwXSA5ODAwMCBzaXplIDI0NTc2DQpbICAgIDAuMDAwMDAw
XSBpbml0X21lbW9yeV9tYXBwaW5nOiBbbWVtIDB4MDAwMDAwMDAtMHgzZmZmZmZmZl0NClsg
ICAgMC4wMDAwMDBdICBbbWVtIDB4MDAwMDAwMDAtMHgzZmZmZmZmZl0gcGFnZSA0aw0KWyAg
ICAwLjAwMDAwMF0ga2VybmVsIGRpcmVjdCBtYXBwaW5nIHRhYmxlcyB1cCB0byAweDNmZmZm
ZmZmIEAgW21lbSAweDAyYWQ2MDAwLTB4MDJjZDdmZmZdDQpbICAgIDAuMDAwMDAwXSB4ZW46
IHNldHRpbmcgUlcgdGhlIHJhbmdlIDJjYjgwMDAgLSAyY2Q4MDAwDQpbICAgIDAuMDAwMDAw
XSBSQU1ESVNLOiBbbWVtIDB4MDJjZDgwMDAtMHgwMzE0ZWZmZl0NClsgICAgMC4wMDAwMDBd
IEFDUEk6IFJTRFAgMDAwMDAwMDAwMDBmYjA4MCAwMDAyNCAodjAyIEFDUElBTSkNClsgICAg
MC4wMDAwMDBdIEFDUEk6IFhTRFQgMDAwMDAwMDA3ZWU3MDEwMCAwMDA1QyAodjAxIEFfTV9J
XyBPRU1YU0RUICAwNTAwMTAyNSBNU0ZUIDAwMDAwMDk3KQ0KWyAgICAwLjAwMDAwMF0gQUNQ
STogRkFDUCAwMDAwMDAwMDdlZTcwMjkwIDAwMEY0ICh2MDMgQV9NX0lfIE9FTUZBQ1AgIDA1
MDAxMDI1IE1TRlQgMDAwMDAwOTcpDQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBEU0RUIDAwMDAw
MDAwN2VlNzA0NDAgMDg0MUYgKHYwMSAgQTEwNjUgQTEwNjUwMDAgMDAwMDAwMDAgSU5UTCAy
MDA2MDExMykNClsgICAgMC4wMDAwMDBdIEFDUEk6IEZBQ1MgMDAwMDAwMDA3ZWU3ZTAwMCAw
MDA0MA0KWyAgICAwLjAwMDAwMF0gQUNQSTogQVBJQyAwMDAwMDAwMDdlZTcwMzkwIDAwMDZD
ICh2MDEgQV9NX0lfIE9FTUFQSUMgIDA1MDAxMDI1IE1TRlQgMDAwMDAwOTcpDQpbICAgIDAu
MDAwMDAwXSBBQ1BJOiBNQ0ZHIDAwMDAwMDAwN2VlNzA0MDAgMDAwM0MgKHYwMSBBX01fSV8g
T0VNTUNGRyAgMDUwMDEwMjUgTVNGVCAwMDAwMDA5NykNClsgICAgMC4wMDAwMDBdIEFDUEk6
IE9FTUIgMDAwMDAwMDA3ZWU3ZTA0MCAwMDA4OSAodjAxIEFfTV9JXyBBTUlfT0VNICAwNTAw
MTAyNSBNU0ZUIDAwMDAwMDk3KQ0KWyAgICAwLjAwMDAwMF0gQUNQSTogSFBFVCAwMDAwMDAw
MDdlZTc4ODYwIDAwMDM4ICh2MDEgQV9NX0lfIE9FTUhQRVQgIDA1MDAxMDI1IE1TRlQgMDAw
MDAwOTcpDQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBHU0NJIDAwMDAwMDAwN2VlN2UwZDAgMDIw
MjQgKHYwMSBBX01fSV8gR01DSFNDSSAgMDUwMDEwMjUgTVNGVCAwMDAwMDA5NykNClsgICAg
MC4wMDAwMDBdIEFDUEk6IFNTRFQgMDAwMDAwMDA3ZWU4MGEwMCAwMEE3QyAodjAxIERwZ1Bt
bSAgICBDcHVQbSAwMDAwMDAxMiBJTlRMIDIwMDYwMTEzKQ0KWyAgICAwLjAwMDAwMF0gQUNQ
STogTG9jYWwgQVBJQyBhZGRyZXNzIDB4ZmVlMDAwMDANClsgICAgMC4wMDAwMDBdIE5vIE5V
TUEgY29uZmlndXJhdGlvbiBmb3VuZA0KWyAgICAwLjAwMDAwMF0gRmFraW5nIGEgbm9kZSBh
dCBbbWVtIDB4MDAwMDAwMDAwMDAwMDAwMC0weDAwMDAwMDAwM2ZmZmZmZmZdDQpbICAgIDAu
MDAwMDAwXSBJbml0bWVtIHNldHVwIG5vZGUgMCBbbWVtIDB4MDAwMDAwMDAtMHgzZmZmZmZm
Zl0NClsgICAgMC4wMDAwMDBdICAgTk9ERV9EQVRBIFttZW0gMHgzZmZmNTAwMC0weDNmZmZm
ZmZmXQ0KWyAgICAwLjAwMDAwMF0gWm9uZSByYW5nZXM6DQpbICAgIDAuMDAwMDAwXSAgIERN
QSAgICAgIFttZW0gMHgwMDAxMDAwMC0weDAwZmZmZmZmXQ0KWyAgICAwLjAwMDAwMF0gICBE
TUEzMiAgICBbbWVtIDB4MDEwMDAwMDAtMHhmZmZmZmZmZl0NClsgICAgMC4wMDAwMDBdICAg
Tm9ybWFsICAgZW1wdHkNClsgICAgMC4wMDAwMDBdIE1vdmFibGUgem9uZSBzdGFydCBmb3Ig
ZWFjaCBub2RlDQpbICAgIDAuMDAwMDAwXSBFYXJseSBtZW1vcnkgbm9kZSByYW5nZXMNClsg
ICAgMC4wMDAwMDBdICAgbm9kZSAgIDA6IFttZW0gMHgwMDAxMDAwMC0weDAwMDlkZmZmXQ0K
WyAgICAwLjAwMDAwMF0gICBub2RlICAgMDogW21lbSAweDAwMTAwMDAwLTB4M2ZmZmZmZmZd
DQpbICAgIDAuMDAwMDAwXSBPbiBub2RlIDAgdG90YWxwYWdlczogMjYyMDMwDQpbICAgIDAu
MDAwMDAwXSAgIERNQSB6b25lOiA2NCBwYWdlcyB1c2VkIGZvciBtZW1tYXANClsgICAgMC4w
MDAwMDBdICAgRE1BIHpvbmU6IDYgcGFnZXMgcmVzZXJ2ZWQNClsgICAgMC4wMDAwMDBdICAg
RE1BIHpvbmU6IDM5MTIgcGFnZXMsIExJRk8gYmF0Y2g6MA0KWyAgICAwLjAwMDAwMF0gICBE
TUEzMiB6b25lOiA0MDMyIHBhZ2VzIHVzZWQgZm9yIG1lbW1hcA0KWyAgICAwLjAwMDAwMF0g
ICBETUEzMiB6b25lOiAyNTQwMTYgcGFnZXMsIExJRk8gYmF0Y2g6MzENClsgICAgMC4wMDAw
MDBdIEFDUEk6IFBNLVRpbWVyIElPIFBvcnQ6IDB4ODA4DQpbICAgIDAuMDAwMDAwXSBBQ1BJ
OiBMb2NhbCBBUElDIGFkZHJlc3MgMHhmZWUwMDAwMA0KWyAgICAwLjAwMDAwMF0gQUNQSTog
TEFQSUMgKGFjcGlfaWRbMHgwMV0gbGFwaWNfaWRbMHgwMF0gZW5hYmxlZCkNClsgICAgMC4w
MDAwMDBdIEFDUEk6IExBUElDIChhY3BpX2lkWzB4MDJdIGxhcGljX2lkWzB4MDFdIGVuYWJs
ZWQpDQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBMQVBJQyAoYWNwaV9pZFsweDAzXSBsYXBpY19p
ZFsweDAyXSBlbmFibGVkKQ0KWyAgICAwLjAwMDAwMF0gQUNQSTogTEFQSUMgKGFjcGlfaWRb
MHgwNF0gbGFwaWNfaWRbMHgwM10gZW5hYmxlZCkNClsgICAgMC4wMDAwMDBdIEFDUEk6IElP
QVBJQyAoaWRbMHgwNF0gYWRkcmVzc1sweGZlYzAwMDAwXSBnc2lfYmFzZVswXSkNClsgICAg
MC4wMDAwMDBdIElPQVBJQ1swXTogYXBpY19pZCA0LCB2ZXJzaW9uIDMyLCBhZGRyZXNzIDB4
ZmVjMDAwMDAsIEdTSSAwLTIzDQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBJTlRfU1JDX09WUiAo
YnVzIDAgYnVzX2lycSAwIGdsb2JhbF9pcnEgMiBkZmwgZGZsKQ0KWyAgICAwLjAwMDAwMF0g
QUNQSTogSU5UX1NSQ19PVlIgKGJ1cyAwIGJ1c19pcnEgOSBnbG9iYWxfaXJxIDkgaGlnaCBs
ZXZlbCkNClsgICAgMC4wMDAwMDBdIEFDUEk6IElSUTAgdXNlZCBieSBvdmVycmlkZS4NClsg
ICAgMC4wMDAwMDBdIEFDUEk6IElSUTIgdXNlZCBieSBvdmVycmlkZS4NClsgICAgMC4wMDAw
MDBdIEFDUEk6IElSUTkgdXNlZCBieSBvdmVycmlkZS4NClsgICAgMC4wMDAwMDBdIFVzaW5n
IEFDUEkgKE1BRFQpIGZvciBTTVAgY29uZmlndXJhdGlvbiBpbmZvcm1hdGlvbg0KWyAgICAw
LjAwMDAwMF0gQUNQSTogSFBFVCBpZDogMHg4MDg2YTcwMSBiYXNlOiAweGZlZDAwMDAwDQpb
ICAgIDAuMDAwMDAwXSBzbXBib290OiBBbGxvd2luZyA0IENQVXMsIDAgaG90cGx1ZyBDUFVz
DQpbICAgIDAuMDAwMDAwXSBucl9pcnFzX2dzaTogNDANClsgICAgMC4wMDAwMDBdIGU4MjA6
IFttZW0gMHg3ZWYwMDAwMC0weGZlYmZmZmZmXSBhdmFpbGFibGUgZm9yIFBDSSBkZXZpY2Vz
DQpbICAgIDAuMDAwMDAwXSBCb290aW5nIHBhcmF2aXJ0dWFsaXplZCBrZXJuZWwgb24gWGVu
DQpbICAgIDAuMDAwMDAwXSBYZW4gdmVyc2lvbjogNC4yLjAtcmM0LXByZSAocHJlc2VydmUt
QUQpDQpbICAgIDAuMDAwMDAwXSBzZXR1cF9wZXJjcHU6IE5SX0NQVVM6OCBucl9jcHVtYXNr
X2JpdHM6OCBucl9jcHVfaWRzOjQgbnJfbm9kZV9pZHM6MQ0KWyAgICAwLjAwMDAwMF0gUEVS
Q1BVOiBFbWJlZGRlZCAyNyBwYWdlcy9jcHUgQGZmZmY4ODAwM2ZjMDAwMDAgczgwODk2IHI4
MTkyIGQyMTUwNCB1NTI0Mjg4DQpbICAgIDAuMDAwMDAwXSBwY3B1LWFsbG9jOiBzODA4OTYg
cjgxOTIgZDIxNTA0IHU1MjQyODggYWxsb2M9MSoyMDk3MTUyDQpbICAgIDAuMDAwMDAwXSBw
Y3B1LWFsbG9jOiBbMF0gMCAxIDIgMyANClsgICAgMC4wMDAwMDBdIEJ1aWx0IDEgem9uZWxp
c3RzIGluIE5vZGUgb3JkZXIsIG1vYmlsaXR5IGdyb3VwaW5nIG9uLiAgVG90YWwgcGFnZXM6
IDI1NzkyOA0KWyAgICAwLjAwMDAwMF0gUG9saWN5IHpvbmU6IERNQTMyDQpbICAgIDAuMDAw
MDAwXSBLZXJuZWwgY29tbWFuZCBsaW5lOiByb290PS9kZXYvc2RhMSBybyB2ZXJib3NlIG1l
bT0xMDI0TSBjb25zb2xlPWh2YzAgY29uc29sZT10dHkwIG5vbW9kZXNldCB2Z2E9MzAzIGVh
cmx5cHJpbnRrPXhlbiBtYXhfbG9vcD01MCBsb29wX21heF9wYXJ0PTEwIGRlYnVnIGxvZ2xl
dmVsPTEwDQpbICAgIDAuMDAwMDAwXSBQSUQgaGFzaCB0YWJsZSBlbnRyaWVzOiA0MDk2IChv
cmRlcjogMywgMzI3NjggYnl0ZXMpDQpbICAgIDAuMDAwMDAwXSBfX2V4X3RhYmxlIGFscmVh
ZHkgc29ydGVkLCBza2lwcGluZyBzb3J0DQpbICAgIDAuMDAwMDAwXSB4c2F2ZTogZW5hYmxl
ZCB4c3RhdGVfYnYgMHgzLCBjbnR4dCBzaXplIDB4MjQwDQpbICAgIDAuMDAwMDAwXSBzb2Z0
d2FyZSBJTyBUTEIgW21lbSAweDNhNjAwMDAwLTB4M2U1ZmZmZmZdICg2NE1CKSBtYXBwZWQg
YXQgW2ZmZmY4ODAwM2E2MDAwMDAtZmZmZjg4MDAzZTVmZmZmZl0NClsgICAgMC4wMDAwMDBd
IE1lbW9yeTogOTMxMDI0ay8xMDQ4NTc2ayBhdmFpbGFibGUgKDg1MTFrIGtlcm5lbCBjb2Rl
LCA0NTZrIGFic2VudCwgMTE3MDk2ayByZXNlcnZlZCwgNjcwNGsgZGF0YSwgNjcyayBpbml0
KQ0KWyAgICAwLjAwMDAwMF0gU0xVQjogR2Vuc2xhYnM9MTUsIEhXYWxpZ249NjQsIE9yZGVy
PTAtMywgTWluT2JqZWN0cz0wLCBDUFVzPTQsIE5vZGVzPTENClsgICAgMC4wMDAwMDBdIFBy
ZWVtcHRpYmxlIGhpZXJhcmNoaWNhbCBSQ1UgaW1wbGVtZW50YXRpb24uDQpbICAgIDAuMDAw
MDAwXSAJUkNVIGR5bnRpY2staWRsZSBncmFjZS1wZXJpb2QgYWNjZWxlcmF0aW9uIGlzIGVu
YWJsZWQuDQpbICAgIDAuMDAwMDAwXSAJQWRkaXRpb25hbCBwZXItQ1BVIGluZm8gcHJpbnRl
ZCB3aXRoIHN0YWxscy4NClsgICAgMC4wMDAwMDBdIAlSQ1UgcmVzdHJpY3RpbmcgQ1BVcyBm
cm9tIE5SX0NQVVM9OCB0byBucl9jcHVfaWRzPTQuDQpbICAgIDAuMDAwMDAwXSBOUl9JUlFT
OjQzNTIgbnJfaXJxczo3MTIgMTYNClsgICAgMC4wMDAwMDBdIHhlbjogc2NpIG92ZXJyaWRl
OiBnbG9iYWxfaXJxPTkgdHJpZ2dlcj0wIHBvbGFyaXR5PTANClsgICAgMC4wMDAwMDBdIHhl
bjogcmVnaXN0ZXJpbmcgZ3NpIDkgdHJpZ2dlcmluZyAwIHBvbGFyaXR5IDANClsgICAgMC4w
MDAwMDBdIHhlbjogLS0+IHBpcnE9OSAtPiBpcnE9OSAoZ3NpPTkpDQooWEVOKSBbMjAxMi0w
OS0wNCAxODo0MToyNl0gSU9BUElDWzBdOiBTZXQgUENJIHJvdXRpbmcgZW50cnkgKDQtOSAt
PiAweDU4IC0+IElSUSA5IE1vZGU6MSBBY3RpdmU6MCkNClsgICAgMC4wMDAwMDBdIHhlbjog
YWNwaSBzY2kgOQ0KWyAgICAwLjAwMDAwMF0geGVuOiAtLT4gcGlycT0xIC0+IGlycT0xIChn
c2k9MSkNClsgICAgMC4wMDAwMDBdIHhlbjogLS0+IHBpcnE9MiAtPiBpcnE9MiAoZ3NpPTIp
DQpbICAgIDAuMDAwMDAwXSB4ZW46IC0tPiBwaXJxPTMgLT4gaXJxPTMgKGdzaT0zKQ0KWyAg
ICAwLjAwMDAwMF0geGVuOiAtLT4gcGlycT00IC0+IGlycT00IChnc2k9NCkNClsgICAgMC4w
MDAwMDBdIHhlbjogLS0+IHBpcnE9NSAtPiBpcnE9NSAoZ3NpPTUpDQpbICAgIDAuMDAwMDAw
XSB4ZW46IC0tPiBwaXJxPTYgLT4gaXJxPTYgKGdzaT02KQ0KWyAgICAwLjAwMDAwMF0geGVu
OiAtLT4gcGlycT03IC0+IGlycT03IChnc2k9NykNClsgICAgMC4wMDAwMDBdIHhlbjogLS0+
IHBpcnE9OCAtPiBpcnE9OCAoZ3NpPTgpDQpbICAgIDAuMDAwMDAwXSB4ZW46IC0tPiBwaXJx
PTEwIC0+IGlycT0xMCAoZ3NpPTEwKQ0KWyAgICAwLjAwMDAwMF0geGVuOiAtLT4gcGlycT0x
MSAtPiBpcnE9MTEgKGdzaT0xMSkNClsgICAgMC4wMDAwMDBdIHhlbjogLS0+IHBpcnE9MTIg
LT4gaXJxPTEyIChnc2k9MTIpDQpbICAgIDAuMDAwMDAwXSB4ZW46IC0tPiBwaXJxPTEzIC0+
IGlycT0xMyAoZ3NpPTEzKQ0KWyAgICAwLjAwMDAwMF0geGVuOiAtLT4gcGlycT0xNCAtPiBp
cnE9MTQgKGdzaT0xNCkNClsgICAgMC4wMDAwMDBdIHhlbjogLS0+IHBpcnE9MTUgLT4gaXJx
PTE1IChnc2k9MTUpDQpbICAgIDAuMDAwMDAwXSBDb25zb2xlOiBjb2xvdXIgZHVtbXkgZGV2
aWNlIDgweDI1DQpbICAgIDAuMDAwMDAwXSBjb25zb2xlIFt0dHkwXSBlbmFibGVkLCBib290
Y29uc29sZSBkaXNhYmxlZA0KWyAgICAwLjAwMDAwMF0gSW5pdGlhbGl6aW5nIGNncm91cCBz
dWJzeXMgY3B1c2V0DQpbICAgIDAuMDAwMDAwXSBJbml0aWFsaXppbmcgY2dyb3VwIHN1YnN5
cyBjcHUNClsgICAgMC4wMDAwMDBdIExpbnV4IHZlcnNpb24gMy42LjAtcmM0LTIwMTIwODMw
KyAocm9vdEB4ZW50ZXN0KSAoZ2NjIHZlcnNpb24gNC40LjUgKERlYmlhbiA0LjQuNS04KSAp
ICM2OCBTTVAgUFJFRU1QVCBUdWUgU2VwIDQgMjA6MzY6NDcgQ0VTVCAyMDEyDQpbICAgIDAu
MDAwMDAwXSBDb21tYW5kIGxpbmU6IHJvb3Q9L2Rldi9zZGExIHJvIHZlcmJvc2UgbWVtPTEw
MjRNIGNvbnNvbGU9aHZjMCBjb25zb2xlPXR0eTAgbm9tb2Rlc2V0IHZnYT0zMDMgZWFybHlw
cmludGs9eGVuIG1heF9sb29wPTUwIGxvb3BfbWF4X3BhcnQ9MTAgZGVidWcgbG9nbGV2ZWw9
MTANClsgICAgMC4wMDAwMDBdIEZyZWVpbmcgOWUtMTAwIHBmbiByYW5nZTogOTggcGFnZXMg
ZnJlZWQNClsgICAgMC4wMDAwMDBdIDEtMSBtYXBwaW5nIG9uIDllLT4xMDANClsgICAgMC4w
MDAwMDBdIDEtMSBtYXBwaW5nIG9uIDdlZTcwLT4xMDAwMDANClsgICAgMC4wMDAwMDBdIFJl
bGVhc2VkIDk4IHBhZ2VzIG9mIHVudXNlZCBtZW1vcnkNClsgICAgMC4wMDAwMDBdIFNldCA1
Mjg4ODIgcGFnZShzKSB0byAxLTEgbWFwcGluZw0KWyAgICAwLjAwMDAwMF0gUG9wdWxhdGlu
ZyA0MDAwMC00MDA2MiBwZm4gcmFuZ2U6IDk4IHBhZ2VzIGFkZGVkDQpbICAgIDAuMDAwMDAw
XSBlODIwOiBCSU9TLXByb3ZpZGVkIHBoeXNpY2FsIFJBTSBtYXA6DQpbICAgIDAuMDAwMDAw
XSBYZW46IFttZW0gMHgwMDAwMDAwMDAwMDAwMDAwLTB4MDAwMDAwMDAwMDA5ZGZmZl0gdXNh
YmxlDQpbICAgIDAuMDAwMDAwXSBYZW46IFttZW0gMHgwMDAwMDAwMDAwMDllODAwLTB4MDAw
MDAwMDAwMDBmZmZmZl0gcmVzZXJ2ZWQNClsgICAgMC4wMDAwMDBdIFhlbjogW21lbSAweDAw
MDAwMDAwMDAxMDAwMDAtMHgwMDAwMDAwMDQwMDYxZmZmXSB1c2FibGUNClsgICAgMC4wMDAw
MDBdIFhlbjogW21lbSAweDAwMDAwMDAwNDAwNjIwMDAtMHgwMDAwMDAwMDdlZTZmZmZmXSB1
bnVzYWJsZQ0KWyAgICAwLjAwMDAwMF0gWGVuOiBbbWVtIDB4MDAwMDAwMDA3ZWU3MDAwMC0w
eDAwMDAwMDAwN2VlN2RmZmZdIEFDUEkgZGF0YQ0KWyAgICAwLjAwMDAwMF0gWGVuOiBbbWVt
IDB4MDAwMDAwMDA3ZWU3ZTAwMC0weDAwMDAwMDAwN2VlY2ZmZmZdIEFDUEkgTlZTDQpbICAg
IDAuMDAwMDAwXSBYZW46IFttZW0gMHgwMDAwMDAwMDdlZWQwMDAwLTB4MDAwMDAwMDA3ZWVm
ZmZmZl0gcmVzZXJ2ZWQNClsgICAgMC4wMDAwMDBdIFhlbjogW21lbSAweDAwMDAwMDAwZmVj
MDAwMDAtMHgwMDAwMDAwMGZlYzAwZmZmXSByZXNlcnZlZA0KWyAgICAwLjAwMDAwMF0gWGVu
OiBbbWVtIDB4MDAwMDAwMDBmZWQwMDAwMC0weDAwMDAwMDAwZmVkMDEwZmZdIHJlc2VydmVk
DQpbICAgIDAuMDAwMDAwXSBYZW46IFttZW0gMHgwMDAwMDAwMGZlZDAyMDAwLTB4MDAwMDAw
MDBmZWQxNGJmZl0gcmVzZXJ2ZWQNClsgICAgMC4wMDAwMDBdIFhlbjogW21lbSAweDAwMDAw
MDAwZmVkMjAwMDAtMHgwMDAwMDAwMGZlZDNmZmZmXSByZXNlcnZlZA0KWyAgICAwLjAwMDAw
MF0gWGVuOiBbbWVtIDB4MDAwMDAwMDBmZWUwMDAwMC0weDAwMDAwMDAwZmVlMDBmZmZdIHJl
c2VydmVkDQpbICAgIDAuMDAwMDAwXSBYZW46IFttZW0gMHgwMDAwMDAwMGZmZTAwMDAwLTB4
MDAwMDAwMDBmZmZmZmZmZl0gcmVzZXJ2ZWQNClsgICAgMC4wMDAwMDBdIGU4MjA6IHJlbW92
ZSBbbWVtIDB4NDAwMDAwMDAtMHhmZmZmZmZmZmZmZmZmZmZlXSB1c2FibGUNClsgICAgMC4w
MDAwMDBdIGJvb3Rjb25zb2xlIFt4ZW5ib290MF0gZW5hYmxlZA0KWyAgICAwLjAwMDAwMF0g
TlggKEV4ZWN1dGUgRGlzYWJsZSkgcHJvdGVjdGlvbjogYWN0aXZlDQpbICAgIDAuMDAwMDAw
XSBlODIwOiB1c2VyLWRlZmluZWQgcGh5c2ljYWwgUkFNIG1hcDoNClsgICAgMC4wMDAwMDBd
IHVzZXI6IFttZW0gMHgwMDAwMDAwMDAwMDAwMDAwLTB4MDAwMDAwMDAwMDA5ZGZmZl0gdXNh
YmxlDQpbICAgIDAuMDAwMDAwXSB1c2VyOiBbbWVtIDB4MDAwMDAwMDAwMDA5ZTgwMC0weDAw
MDAwMDAwMDAwZmZmZmZdIHJlc2VydmVkDQpbICAgIDAuMDAwMDAwXSB1c2VyOiBbbWVtIDB4
MDAwMDAwMDAwMDEwMDAwMC0weDAwMDAwMDAwM2ZmZmZmZmZdIHVzYWJsZQ0KWyAgICAwLjAw
MDAwMF0gdXNlcjogW21lbSAweDAwMDAwMDAwNDAwNjIwMDAtMHgwMDAwMDAwMDdlZTZmZmZm
XSB1bnVzYWJsZQ0KWyAgICAwLjAwMDAwMF0gdXNlcjogW21lbSAweDAwMDAwMDAwN2VlNzAw
MDAtMHgwMDAwMDAwMDdlZTdkZmZmXSBBQ1BJIGRhdGENClsgICAgMC4wMDAwMDBdIHVzZXI6
IFttZW0gMHgwMDAwMDAwMDdlZTdlMDAwLTB4MDAwMDAwMDA3ZWVjZmZmZl0gQUNQSSBOVlMN
ClsgICAgMC4wMDAwMDBdIHVzZXI6IFttZW0gMHgwMDAwMDAwMDdlZWQwMDAwLTB4MDAwMDAw
MDA3ZWVmZmZmZl0gcmVzZXJ2ZWQNClsgICAgMC4wMDAwMDBdIHVzZXI6IFttZW0gMHgwMDAw
MDAwMGZlYzAwMDAwLTB4MDAwMDAwMDBmZWMwMGZmZl0gcmVzZXJ2ZWQNClsgICAgMC4wMDAw
MDBdIHVzZXI6IFttZW0gMHgwMDAwMDAwMGZlZDAwMDAwLTB4MDAwMDAwMDBmZWQwMTBmZl0g
cmVzZXJ2ZWQNClsgICAgMC4wMDAwMDBdIHVzZXI6IFttZW0gMHgwMDAwMDAwMGZlZDAyMDAw
LTB4MDAwMDAwMDBmZWQxNGJmZl0gcmVzZXJ2ZWQNClsgICAgMC4wMDAwMDBdIHVzZXI6IFtt
ZW0gMHgwMDAwMDAwMGZlZDIwMDAwLTB4MDAwMDAwMDBmZWQzZmZmZl0gcmVzZXJ2ZWQNClsg
ICAgMC4wMDAwMDBdIHVzZXI6IFttZW0gMHgwMDAwMDAwMGZlZTAwMDAwLTB4MDAwMDAwMDBm
ZWUwMGZmZl0gcmVzZXJ2ZWQNClsgICAgMC4wMDAwMDBdIHVzZXI6IFttZW0gMHgwMDAwMDAw
MGZmZTAwMDAwLTB4MDAwMDAwMDBmZmZmZmZmZl0gcmVzZXJ2ZWQNClsgICAgMC4wMDAwMDBd
IERNSSBwcmVzZW50Lg0KWyAgICAwLjAwMDAwMF0gRE1JOiBTeXN0ZW0gbWFudWZhY3R1cmVy
IFN5c3RlbSBQcm9kdWN0IE5hbWUvUDVRLUVNIERPLCBCSU9TIDEyMDggICAgMDUvMjUvMjAx
MA0KWyAgICAwLjAwMDAwMF0gZTgyMDogdXBkYXRlIFttZW0gMHgwMDAwMDAwMC0weDAwMDBm
ZmZmXSB1c2FibGUgPT0+IHJlc2VydmVkDQpbICAgIDAuMDAwMDAwXSBlODIwOiByZW1vdmUg
W21lbSAweDAwMGEwMDAwLTB4MDAwZmZmZmZdIHVzYWJsZQ0KWyAgICAwLjAwMDAwMF0gTm8g
QUdQIGJyaWRnZSBmb3VuZA0KWyAgICAwLjAwMDAwMF0gZTgyMDogbGFzdF9wZm4gPSAweDQw
MDAwIG1heF9hcmNoX3BmbiA9IDB4NDAwMDAwMDAwDQpbICAgIDAuMDAwMDAwXSBmb3VuZCBT
TVAgTVAtdGFibGUgYXQgW21lbSAweDAwMGZmNzgwLTB4MDAwZmY3OGZdIG1hcHBlZCBhdCBb
ZmZmZjg4MDAwMDBmZjc4MF0NClsgICAgMC4wMDAwMDBdIGluaXRpYWwgbWVtb3J5IG1hcHBl
ZDogW21lbSAweDAwMDAwMDAwLTB4MDMxNGVmZmZdDQpbICAgIDAuMDAwMDAwXSBCYXNlIG1l
bW9yeSB0cmFtcG9saW5lIGF0IFtmZmZmODgwMDAwMDk4MDAwXSA5ODAwMCBzaXplIDI0NTc2
DQpbICAgIDAuMDAwMDAwXSBpbml0X21lbW9yeV9tYXBwaW5nOiBbbWVtIDB4MDAwMDAwMDAt
MHgzZmZmZmZmZl0NClsgICAgMC4wMDAwMDBdICBbbWVtIDB4MDAwMDAwMDAtMHgzZmZmZmZm
Zl0gcGFnZSA0aw0KWyAgICAwLjAwMDAwMF0ga2VybmVsIGRpcmVjdCBtYXBwaW5nIHRhYmxl
cyB1cCB0byAweDNmZmZmZmZmIEAgW21lbSAweDAyYWQ2MDAwLTB4MDJjZDdmZmZdDQpbICAg
IDAuMDAwMDAwXSB4ZW46IHNldHRpbmcgUlcgdGhlIHJhbmdlIDJjYjgwMDAgLSAyY2Q4MDAw
DQpbICAgIDAuMDAwMDAwXSBSQU1ESVNLOiBbbWVtIDB4MDJjZDgwMDAtMHgwMzE0ZWZmZl0N
ClsgICAgMC4wMDAwMDBdIEFDUEk6IFJTRFAgMDAwMDAwMDAwMDBmYjA4MCAwMDAyNCAodjAy
IEFDUElBTSkNClsgICAgMC4wMDAwMDBdIEFDUEk6IFhTRFQgMDAwMDAwMDA3ZWU3MDEwMCAw
MDA1QyAodjAxIEFfTV9JXyBPRU1YU0RUICAwNTAwMTAyNSBNU0ZUIDAwMDAwMDk3KQ0KWyAg
ICAwLjAwMDAwMF0gQUNQSTogRkFDUCAwMDAwMDAwMDdlZTcwMjkwIDAwMEY0ICh2MDMgQV9N
X0lfIE9FTUZBQ1AgIDA1MDAxMDI1IE1TRlQgMDAwMDAwOTcpDQpbICAgIDAuMDAwMDAwXSBB
Q1BJOiBEU0RUIDAwMDAwMDAwN2VlNzA0NDAgMDg0MUYgKHYwMSAgQTEwNjUgQTEwNjUwMDAg
MDAwMDAwMDAgSU5UTCAyMDA2MDExMykNClsgICAgMC4wMDAwMDBdIEFDUEk6IEZBQ1MgMDAw
MDAwMDA3ZWU3ZTAwMCAwMDA0MA0KWyAgICAwLjAwMDAwMF0gQUNQSTogQVBJQyAwMDAwMDAw
MDdlZTcwMzkwIDAwMDZDICh2MDEgQV9NX0lfIE9FTUFQSUMgIDA1MDAxMDI1IE1TRlQgMDAw
MDAwOTcpDQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBNQ0ZHIDAwMDAwMDAwN2VlNzA0MDAgMDAw
M0MgKHYwMSBBX01fSV8gT0VNTUNGRyAgMDUwMDEwMjUgTVNGVCAwMDAwMDA5NykNClsgICAg
MC4wMDAwMDBdIEFDUEk6IE9FTUIgMDAwMDAwMDA3ZWU3ZTA0MCAwMDA4OSAodjAxIEFfTV9J
XyBBTUlfT0VNICAwNTAwMTAyNSBNU0ZUIDAwMDAwMDk3KQ0KWyAgICAwLjAwMDAwMF0gQUNQ
STogSFBFVCAwMDAwMDAwMDdlZTc4ODYwIDAwMDM4ICh2MDEgQV9NX0lfIE9FTUhQRVQgIDA1
MDAxMDI1IE1TRlQgMDAwMDAwOTcpDQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBHU0NJIDAwMDAw
MDAwN2VlN2UwZDAgMDIwMjQgKHYwMSBBX01fSV8gR01DSFNDSSAgMDUwMDEwMjUgTVNGVCAw
MDAwMDA5NykNClsgICAgMC4wMDAwMDBdIEFDUEk6IFNTRFQgMDAwMDAwMDA3ZWU4MGEwMCAw
MEE3QyAodjAxIERwZ1BtbSAgICBDcHVQbSAwMDAwMDAxMiBJTlRMIDIwMDYwMTEzKQ0KWyAg
ICAwLjAwMDAwMF0gQUNQSTogTG9jYWwgQVBJQyBhZGRyZXNzIDB4ZmVlMDAwMDANClsgICAg
MC4wMDAwMDBdIE5vIE5VTUEgY29uZmlndXJhdGlvbiBmb3VuZA0KWyAgICAwLjAwMDAwMF0g
RmFraW5nIGEgbm9kZSBhdCBbbWVtIDB4MDAwMDAwMDAwMDAwMDAwMC0weDAwMDAwMDAwM2Zm
ZmZmZmZdDQpbICAgIDAuMDAwMDAwXSBJbml0bWVtIHNldHVwIG5vZGUgMCBbbWVtIDB4MDAw
MDAwMDAtMHgzZmZmZmZmZl0NClsgICAgMC4wMDAwMDBdICAgTk9ERV9EQVRBIFttZW0gMHgz
ZmZmNTAwMC0weDNmZmZmZmZmXQ0KWyAgICAwLjAwMDAwMF0gWm9uZSByYW5nZXM6DQpbICAg
IDAuMDAwMDAwXSAgIERNQSAgICAgIFttZW0gMHgwMDAxMDAwMC0weDAwZmZmZmZmXQ0KWyAg
ICAwLjAwMDAwMF0gICBETUEzMiAgICBbbWVtIDB4MDEwMDAwMDAtMHhmZmZmZmZmZl0NClsg
ICAgMC4wMDAwMDBdICAgTm9ybWFsICAgZW1wdHkNClsgICAgMC4wMDAwMDBdIE1vdmFibGUg
em9uZSBzdGFydCBmb3IgZWFjaCBub2RlDQpbICAgIDAuMDAwMDAwXSBFYXJseSBtZW1vcnkg
bm9kZSByYW5nZXMNClsgICAgMC4wMDAwMDBdICAgbm9kZSAgIDA6IFttZW0gMHgwMDAxMDAw
MC0weDAwMDlkZmZmXQ0KWyAgICAwLjAwMDAwMF0gICBub2RlICAgMDogW21lbSAweDAwMTAw
MDAwLTB4M2ZmZmZmZmZdDQpbICAgIDAuMDAwMDAwXSBPbiBub2RlIDAgdG90YWxwYWdlczog
MjYyMDMwDQpbICAgIDAuMDAwMDAwXSAgIERNQSB6b25lOiA2NCBwYWdlcyB1c2VkIGZvciBt
ZW1tYXANClsgICAgMC4wMDAwMDBdICAgRE1BIHpvbmU6IDYgcGFnZXMgcmVzZXJ2ZWQNClsg
ICAgMC4wMDAwMDBdICAgRE1BIHpvbmU6IDM5MTIgcGFnZXMsIExJRk8gYmF0Y2g6MA0KWyAg
ICAwLjAwMDAwMF0gICBETUEzMiB6b25lOiA0MDMyIHBhZ2VzIHVzZWQgZm9yIG1lbW1hcA0K
WyAgICAwLjAwMDAwMF0gICBETUEzMiB6b25lOiAyNTQwMTYgcGFnZXMsIExJRk8gYmF0Y2g6
MzENClsgICAgMC4wMDAwMDBdIEFDUEk6IFBNLVRpbWVyIElPIFBvcnQ6IDB4ODA4DQpbICAg
IDAuMDAwMDAwXSBBQ1BJOiBMb2NhbCBBUElDIGFkZHJlc3MgMHhmZWUwMDAwMA0KWyAgICAw
LjAwMDAwMF0gQUNQSTogTEFQSUMgKGFjcGlfaWRbMHgwMV0gbGFwaWNfaWRbMHgwMF0gZW5h
YmxlZCkNClsgICAgMC4wMDAwMDBdIEFDUEk6IExBUElDIChhY3BpX2lkWzB4MDJdIGxhcGlj
X2lkWzB4MDFdIGVuYWJsZWQpDQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBMQVBJQyAoYWNwaV9p
ZFsweDAzXSBsYXBpY19pZFsweDAyXSBlbmFibGVkKQ0KWyAgICAwLjAwMDAwMF0gQUNQSTog
TEFQSUMgKGFjcGlfaWRbMHgwNF0gbGFwaWNfaWRbMHgwM10gZW5hYmxlZCkNClsgICAgMC4w
MDAwMDBdIEFDUEk6IElPQVBJQyAoaWRbMHgwNF0gYWRkcmVzc1sweGZlYzAwMDAwXSBnc2lf
YmFzZVswXSkNClsgICAgMC4wMDAwMDBdIElPQVBJQ1swXTogYXBpY19pZCA0LCB2ZXJzaW9u
IDMyLCBhZGRyZXNzIDB4ZmVjMDAwMDAsIEdTSSAwLTIzDQpbICAgIDAuMDAwMDAwXSBBQ1BJ
OiBJTlRfU1JDX09WUiAoYnVzIDAgYnVzX2lycSAwIGdsb2JhbF9pclsgICAgMi4xMTM0ODdd
IGh1YiAyLTA6MS4wOiBzdGF0ZSA3IHBvcnRzIDYgY2hnIDAwMDAgZXZ0IDAwMDANClsgICAg
Mi4xMTM1MDFdIHVoY2lfaGNkIDAwMDA6MDA6MWEuMDogaXJxIDE2LCBpbyBiYXNlIDB4MDAw
MGI0ODANClsgICAgMi4xMTM1OTZdIHVzYiB1c2IzOiBkZWZhdWx0IGxhbmd1YWdlIDB4MDQw
OQ0KWyAgICAyLjExMzYwOF0gdXNiIHVzYjM6IHVkZXYgMSwgYnVzbnVtIDMsIG1pbm9yID0g
MjU2DQpbICAgIDIuMTEzNjEwXSB1c2IgdXNiMzogTmV3IFVTQiBkZXZpY2UgZm91bmQsIGlk
VmVuZG9yPTFkNmIsIGlkUHJvZHVjdD0wMDAxDQpbICAgIDIuMTEzNjEyXSB1c2IgdXNiMzog
TmV3IFVTQiBkZXZpY2Ugc3RyaW5nczogTWZyPTMsIFByb2R1Y3Q9MiwgU2VyaWFsTnVtYmVy
PTENClsgICAgMi4xMTM2MTNdIHVzYiB1c2IzOiBQcm9kdWN0OiBVSENJIEhvc3QgQ29udHJv
bGxlcg0KWyAgICAyLjExMzYxNV0gdXNiIHVzYjM6IE1hbnVmYWN0dXJlcjogTGludXggMy42
LjAtcmM0LTIwMTIwODMwKyB1aGNpX2hjZA0KWyAgICAyLjExMzYxNl0gdXNiIHVzYjM6IFNl
cmlhbE51bWJlcjogMDAwMDowMDoxYS4wDQpbICAgIDIuMTEzODYzXSB1c2IgdXNiMzogdXNi
X3Byb2JlX2RldmljZQ0KWyAgICAyLjExMzg2NV0gdXNiIHVzYjM6IGNvbmZpZ3VyYXRpb24g
IzEgY2hvc2VuIGZyb20gMSBjaG9pY2UNClsgICAgMi4xMTM4NzZdIHVzYiB1c2IzOiBhZGRp
bmcgMy0wOjEuMCAoY29uZmlnICMxLCBpbnRlcmZhY2UgMCkNClsgICAgMi4xMTQwMzJdIGh1
YiAzLTA6MS4wOiB1c2JfcHJvYmVfaW50ZXJmYWNlDQpbICAgIDIuMTE0MDM1XSBodWIgMy0w
OjEuMDogdXNiX3Byb2JlX2ludGVyZmFjZSAtIGdvdCBpZA0KWyAgICAyLjExNDAzOF0gaHVi
IDMtMDoxLjA6IFVTQiBodWIgZm91bmQNClsgICAgMi4xMTQwNTBdIGh1YiAzLTA6MS4wOiAy
IHBvcnRzIGRldGVjdGVkDQpbICAgIDIuMTE0MDUzXSBodWIgMy0wOjEuMDogc3RhbmRhbG9u
ZSBodWINClsgICAgMi4xMTQwNTRdIGh1YiAzLTA6MS4wOiBubyBwb3dlciBzd2l0Y2hpbmcg
KHVzYiAxLjApDQpbICAgIDIuMTE0MDU2XSBodWIgMy0wOjEuMDogaW5kaXZpZHVhbCBwb3J0
IG92ZXItY3VycmVudCBwcm90ZWN0aW9uDQpbICAgIDIuMTE0MDU4XSBodWIgMy0wOjEuMDog
cG93ZXIgb24gdG8gcG93ZXIgZ29vZCB0aW1lOiAybXMNClsgICAgMi4xMTQwODZdIGh1YiAz
LTA6MS4wOiBsb2NhbCBwb3dlciBzb3VyY2UgaXMgZ29vZA0KWyAgICAyLjExNDA4OF0gaHVi
IDMtMDoxLjA6IHRyeWluZyB0byBlbmFibGUgcG9ydCBwb3dlciBvbiBub24tc3dpdGNoYWJs
ZSBodWINClsgICAgMi4xMTQxOTldIGVoY2lfaGNkIDAwMDA6MDA6MWEuNzogSFMgY29tcGFu
aW9uIGZvciAwMDAwOjAwOjFhLjANClsgICAgMi4xMTQyNTVdIHhlbjogcmVnaXN0ZXJpbmcg
Z3NpIDIxIHRyaWdnZXJpbmcgMCBwb2xhcml0eSAxDQpbICAgIDIuMTE0MjU3XSBBbHJlYWR5
IHNldHVwIHRoZSBHU0kgOjIxDQpbICAgIDIuMTE0MjcwXSB1aGNpX2hjZCAwMDAwOjAwOjFh
LjE6IHNldHRpbmcgbGF0ZW5jeSB0aW1lciB0byA2NA0KWyAgICAyLjExNDI3NF0gdWhjaV9o
Y2QgMDAwMDowMDoxYS4xOiBVSENJIEhvc3QgQ29udHJvbGxlcg0KWyAgICAyLjExNDQyM10g
dWhjaV9oY2QgMDAwMDowMDoxYS4xOiBuZXcgVVNCIGJ1cyByZWdpc3RlcmVkLCBhc3NpZ25l
ZCBidXMgbnVtYmVyIDQNClsgICAgMi4xMTQ0MzNdIHVoY2lfaGNkIDAwMDA6MDA6MWEuMTog
ZGV0ZWN0ZWQgMiBwb3J0cw0KWyAgICAyLjExNDQ0MF0gdWhjaV9oY2QgMDAwMDowMDoxYS4x
OiB1aGNpX2NoZWNrX2FuZF9yZXNldF9oYzogY21kID0gMHgwMDAwDQpbICAgIDIuMTE0NDQy
XSB1aGNpX2hjZCAwMDAwOjAwOjFhLjE6IFBlcmZvcm1pbmcgZnVsbCByZXNldA0KWyAgICAy
LjExNDQ2MV0gdWhjaV9oY2QgMDAwMDowMDoxYS4xOiBzdXBwb3J0cyBVU0IgcmVtb3RlIHdh
a2V1cA0KWyAgICAyLjExNDQ5MF0gdWhjaV9oY2QgMDAwMDowMDoxYS4xOiBpcnEgMjEsIGlv
IGJhc2UgMHgwMDAwYjgwMA0KWyAgICAyLjExNDU2M10gdXNiIHVzYjQ6IGRlZmF1bHQgbGFu
Z3VhZ2UgMHgwNDA5DQpbICAgIDIuMTE0NTc1XSB1c2IgdXNiNDogdWRldiAxLCBidXNudW0g
NCwgbWlub3IgPSAzODQNClsgICAgMi4xMTQ1NzddIHVzYiB1c2I0OiBOZXcgVVNCIGRldmlj
ZSBmb3VuZCwgaWRWZW5kb3I9MWQ2YiwgaWRQcm9kdWN0PTAwMDENClsgICAgMi4xMTQ1Nzld
IHVzYiB1c2I0OiBOZXcgVVNCIGRldmljZSBzdHJpbmdzOiBNZnI9MywgUHJvZHVjdD0yLCBT
ZXJpYWxOdW1iZXI9MQ0KWyAgICAyLjExNDU4MF0gdXNiIHVzYjQ6IFByb2R1Y3Q6IFVIQ0kg
SG9zdCBDb250cm9sbGVyDQpbICAgIDIuMTE0NTgyXSB1c2IgdXNiNDogTWFudWZhY3R1cmVy
OiBMaW51eCAzLjYuMC1yYzQtMjAxMjA4MzArIHVoY2lfaGNkDQpbICAgIDIuMTE0NTgzXSB1
c2IgdXNiNDogU2VyaWFsTnVtYmVyOiAwMDAwOjAwOjFhLjENClsgICAgMi4xMTQ3NDZdIHVz
YiB1c2I0OiB1c2JfcHJvYmVfZGV2aWNlDQpbICAgIDIuMTE0NzQ4XSB1c2IgdXNiNDogY29u
ZmlndXJhdGlvbiAjMSBjaG9zZW4gZnJvbSAxIGNob2ljZQ0KWyAgICAyLjExNDc1OV0gdXNi
IHVzYjQ6IGFkZGluZyA0LTA6MS4wIChjb25maWcgIzEsIGludGVyZmFjZSAwKQ0KWyAgICAy
LjExNDg2MV0gaHViIDQtMDoxLjA6IHVzYl9wcm9iZV9pbnRlcmZhY2UNClsgICAgMi4xMTQ4
NjNdIGh1YiA0LTA6MS4wOiB1c2JfcHJvYmVfaW50ZXJmYWNlIC0gZ290IGlkDQpbICAgIDIu
MTE0ODY0XSBodWIgNC0wOjEuMDogVVNCIGh1YiBmb3VuZA0KWyAgICAyLjExNDg3Ml0gaHVi
IDQtMDoxLjA6IDIgcG9ydHMgZGV0ZWN0ZWQNClsgICAgMi4xMTQ4NzNdIGh1YiA0LTA6MS4w
OiBzdGFuZGFsb25lIGh1Yg0KWyAgICAyLjExNDg3NF0gaHViIDQtMDoxLjA6IG5vIHBvd2Vy
IHN3aXRjaGluZyAodXNiIDEuMCkNClsgICAgMi4xMTQ4NzVdIGh1YiA0LTA6MS4wOiBpbmRp
dmlkdWFsIHBvcnQgb3Zlci1jdXJyZW50IHByb3RlY3Rpb24NClsgICAgMi4xMTQ4NzddIGh1
YiA0LTA6MS4wOiBwb3dlciBvbiB0byBwb3dlciBnb29kIHRpbWU6IDJtcw0KWyAgICAyLjEx
NDg4Nl0gaHViIDQtMDoxLjA6IGxvY2FsIHBvd2VyIHNvdXJjZSBpcyBnb29kDQpbICAgIDIu
MTE0ODg3XSBodWIgNC0wOjEuMDogdHJ5aW5nIHRvIGVuYWJsZSBwb3J0IHBvd2VyIG9uIG5v
bi1zd2l0Y2hhYmxlIGh1Yg0KWyAgICAyLjExNDk3N10gZWhjaV9oY2QgMDAwMDowMDoxYS43
OiBIUyBjb21wYW5pb24gZm9yIDAwMDA6MDA6MWEuMQ0KWyAgICAyLjExNTAxNl0geGVuOiBy
ZWdpc3RlcmluZyBnc2kgMTggdHJpZ2dlcmluZyAwIHBvbGFyaXR5IDENClsgICAgMi4xMTUw
MThdIEFscmVhZHkgc2V0dXAgdGhlIEdTSSA6MTgNClsgICAgMi4xMTUwMzFdIHVoY2lfaGNk
IDAwMDA6MDA6MWEuMjogc2V0dGluZyBsYXRlbmN5IHRpbWVyIHRvIDY0DQpbICAgIDIuMTE1
MDM1XSB1aGNpX2hjZCAwMDAwOjAwOjFhLjI6IFVIQ0kgSG9zdCBDb250cm9sbGVyDQpbICAg
IDIuMTE1MTU4XSB1aGNpX2hjZCAwMDAwOjAwOjFhLjI6IG5ldyBVU0IgYnVzIHJlZ2lzdGVy
ZWQsIGFzc2lnbmVkIGJ1cyBudW1iZXIgNQ0KWyAgICAyLjExNTE2OV0gdWhjaV9oY2QgMDAw
MDowMDoxYS4yOiBkZXRlY3RlZCAyIHBvcnRzDQpbICAgIDIuMTE1MTc1XSB1aGNpX2hjZCAw
MDAwOjAwOjFhLjI6IHVoY2lfY2hlY2tfYW5kX3Jlc2V0X2hjOiBjbWQgPSAweDAwMDANClsg
ICAgMi4xMTUxNzddIHVoY2lfaGNkIDAwMDA6MDA6MWEuMjogUGVyZm9ybWluZyBmdWxsIHJl
c2V0DQpbICAgIDIuMTE1MTk2XSB1aGNpX2hjZCAwMDAwOjAwOjFhLjI6IHN1cHBvcnRzIFVT
QiByZW1vdGUgd2FrZXVwDQpbICAgIDIuMTE1MjA0XSB1aGNpX2hjZCAwMDAwOjAwOjFhLjI6
IGlycSAxOCwgaW8gYmFzZSAweDAwMDBiODgwDQpbICAgIDIuMTE1MjcxXSB1c2IgdXNiNTog
ZGVmYXVsdCBsYW5ndWFnZSAweDA0MDkNClsgICAgMi4xMTUyODNdIHVzYiB1c2I1OiB1ZGV2
IDEsIGJ1c251bSA1LCBtaW5vciA9IDUxMg0KWyAgICAyLjExNTI4NV0gdXNiIHVzYjU6IE5l
dyBVU0IgZGV2aWNlIGZvdW5kLCBpZFZlbmRvcj0xZDZiLCBpZFByb2R1Y3Q9MDAwMQ0KWyAg
ICAyLjExNTI4N10gdXNiIHVzYjU6IE5ldyBVU0IgZGV2aWNlIHN0cmluZ3M6IE1mcj0zLCBQ
cm9kdWN0PTIsIFNlcmlhbE51bWJlcj0xDQpbICAgIDIuMTE1Mjg4XSB1c2IgdXNiNTogUHJv
ZHVjdDogVUhDSSBIb3N0IENvbnRyb2xsZXINClsgICAgMi4xMTUyOTBdIHVzYiB1c2I1OiBN
YW51ZmFjdHVyZXI6IExpbnV4IDMuNi4wLXJjNC0yMDEyMDgzMCsgdWhjaV9oY2QNClsgICAg
Mi4xMTUyOTFdIHVzYiB1c2I1OiBTZXJpYWxOdW1iZXI6IDAwMDA6MDA6MWEuMg0KWyAgICAy
LjExNTQ1Ml0gdXNiIHVzYjU6IHVzYl9wcm9iZV9kZXZpY2UNClsgICAgMi4xMTU0NTRdIHVz
YiB1c2I1OiBjb25maWd1cmF0aW9uICMxIGNob3NlbiBmcm9tIDEgY2hvaWNlDQpbICAgIDIu
MTE1NDY1XSB1c2IgdXNiNTogYWRkaW5nIDUtMDoxLjAgKGNvbmZpZyAjMSwgaW50ZXJmYWNl
IDApDQpbICAgIDIuMTE1NTczXSBodWIgNS0wOjEuMDogdXNiX3Byb2JlX2ludGVyZmFjZQ0K
WyAgICAyLjExNTU3NF0gaHViIDUtMDoxLjA6IHVzYl9wcm9iZV9pbnRlcmZhY2UgLSBnb3Qg
aWQNClsgICAgMi4xMTU1NzZdIGh1YiA1LTA6MS4wOiBVU0IgaHViIGZvdW5kDQpbICAgIDIu
MTE1NTgzXSBodWIgNS0wOjEuMDogMiBwb3J0cyBkZXRlY3RlZA0KWyAgICAyLjExNTU4NV0g
aHViIDUtMDoxLjA6IHN0YW5kYWxvbmUgaHViDQpbICAgIDIuMTE1NTg2XSBodWIgNS0wOjEu
MDogbm8gcG93ZXIgc3dpdGNoaW5nICh1c2IgMS4wKQ0KWyAgICAyLjExNTU4N10gaHViIDUt
MDoxLjA6IGluZGl2aWR1YWwgcG9ydCBvdmVyLWN1cnJlbnQgcHJvdGVjdGlvbg0KWyAgICAy
LjExNTU4OV0gaHViIDUtMDoxLjA6IHBvd2VyIG9uIHRvIHBvd2VyIGdvb2QgdGltZTogMm1z
DQpbICAgIDIuMTE1NTk4XSBodWIgNS0wOjEuMDogbG9jYWwgcG93ZXIgc291cmNlIGlzIGdv
b2QNClsgICAgMi4xMTU1OTldIGh1YiA1LTA6MS4wOiB0cnlpbmcgdG8gZW5hYmxlIHBvcnQg
cG93ZXIgb24gbm9uLXN3aXRjaGFibGUgaHViDQpbICAgIDIuMTE1Njg5XSBlaGNpX2hjZCAw
MDAwOjAwOjFhLjc6IEhTIGNvbXBhbmlvbiBmb3IgMDAwMDowMDoxYS4yDQpbICAgIDIuMTE1
NzI5XSB4ZW46IHJlZ2lzdGVyaW5nIGdzaSAyMyB0cmlnZ2VyaW5nIDAgcG9sYXJpdHkgMQ0K
WyAgICAyLjExNTczMV0gQWxyZWFkeSBzZXR1cCB0aGUgR1NJIDoyMw0KWyAgICAyLjExNTc0
M10gdWhjaV9oY2QgMDAwMDowMDoxZC4wOiBzZXR0aW5nIGxhdGVuY3kgdGltZXIgdG8gNjQN
ClsgICAgMi4xMTU3NDddIHVoY2lfaGNkIDAwMDA6MDA6MWQuMDogVUhDSSBIb3N0IENvbnRy
b2xsZXINClsgICAgMi4xMTU4NzJdIHVoY2lfaGNkIDAwMDA6MDA6MWQuMDogbmV3IFVTQiBi
dXMgcmVnaXN0ZXJlZCwgYXNzaWduZWQgYnVzIG51bWJlciA2DQpbICAgIDIuMTE1ODgyXSB1
aGNpX2hjZCAwMDAwOjAwOjFkLjA6IGRldGVjdGVkIDIgcG9ydHMNClsgICAgMi4xMTU4ODld
IHVoY2lfaGNkIDAwMDA6MDA6MWQuMDogdWhjaV9jaGVja19hbmRfcmVzZXRfaGM6IGNtZCA9
IDB4MDAwMA0KWyAgICAyLjExNTg5MF0gdWhjaV9oY2QgMDAwMDowMDoxZC4wOiBQZXJmb3Jt
aW5nIGZ1bGwgcmVzZXQNClsgICAgMi4xMTU5MTBdIHVoY2lfaGNkIDAwMDA6MDA6MWQuMDog
c3VwcG9ydHMgVVNCIHJlbW90ZSB3YWtldXANClsgICAgMi4xMTU5MTddIHVoY2lfaGNkIDAw
MDA6MDA6MWQuMDogaXJxIDIzLCBpbyBiYXNlIDB4MDAwMGIwMDANClsgICAgMi4xMTU5ODdd
IHVzYiB1c2I2OiBkZWZhdWx0IGxhbmd1YWdlIDB4MDQwOQ0KWyAgICAyLjExNTk5OV0gdXNi
IHVzYjY6IHVkZXYgMSwgYnVzbnVtIDYsIG1pbm9yID0gNjQwDQpbICAgIDIuMTE2MDAxXSB1
c2IgdXNiNjogTmV3IFVTQiBkZXZpY2UgZm91bmQsIGlkVmVuZG9yPTFkNmIsIGlkUHJvZHVj
dD0wMDAxDQpbICAgIDIuMTE2MDAyXSB1c2IgdXNiNjogTmV3IFVTQiBkZXZpY2Ugc3RyaW5n
czogTWZyPTMsIFByb2R1Y3Q9MiwgU2VyaWFsTnVtYmVyPTENClsgICAgMi4xMTYwMDRdIHVz
YiB1c2I2OiBQcm9kdWN0OiBVSENJIEhvc3QgQ29udHJvbGxlcg0KWyAgICAyLjExNjAwNl0g
dXNiIHVzYjY6IE1hbnVmYWN0dXJlcjogTGludXggMy42LjAtcmM0LTIwMTIwODMwKyB1aGNp
X2hjZA0KWyAgICAyLjExNjAwN10gdXNiIHVzYjY6IFNlcmlhbE51bWJlcjogMDAwMDowMDox
ZC4wDQpbICAgIDIuMTE2MTY3XSB1c2IgdXNiNjogdXNiX3Byb2JlX2RldmljZQ0KWyAgICAy
LjExNjE2OV0gdXNiIHVzYjY6IGNvbmZpZ3VyYXRpb24gIzEgY2hvc2VuIGZyb20gMSBjaG9p
Y2UNClsgICAgMi4xMTYxODBdIHVzYiB1c2I2OiBhZGRpbmcgNi0wOjEuMCAoY29uZmlnICMx
LCBpbnRlcmZhY2UgMCkNClsgICAgMi4xMTYyODRdIGh1YiA2LTA6MS4wOiB1c2JfcHJvYmVf
aW50ZXJmYWNlDQpbICAgIDIuMTE2Mjg2XSBodWIgNi0wOjEuMDogdXNiX3Byb2JlX2ludGVy
ZmFjZSAtIGdvdCBpZA0KWyAgICAyLjExNjI4OF0gaHViIDYtMDoxLjA6IFVTQiBodWIgZm91
bmQNClsgICAgMi4xMTYyOTVdIGh1YiA2LTA6MS4wOiAyIHBvcnRzIGRldGVjdGVkDQpbICAg
IDIuMTE2Mjk2XSBodWIgNi0wOjEuMDogc3RhbmRhbG9uZSBodWINClsgICAgMi4xMTYyOThd
IGh1YiA2LTA6MS4wOiBubyBwb3dlciBzd2l0Y2hpbmcgKHVzYiAxLjApDQpbICAgIDIuMTE2
Mjk5XSBodWIgNi0wOjEuMDogaW5kaXZpZHVhbCBwb3J0IG92ZXItY3VycmVudCBwcm90ZWN0
aW9uDQpbICAgIDIuMTE2MzAwXSBodWIgNi0wOjEuMDogcG93ZXIgb24gdG8gcG93ZXIgZ29v
ZCB0aW1lOiAybXMNClsgICAgMi4xMTYzMDldIGh1YiA2LTA6MS4wOiBsb2NhbCBwb3dlciBz
b3VyY2UgaXMgZ29vZA0KWyAgICAyLjExNjMxMV0gaHViIDYtMDoxLjA6IHRyeWluZyB0byBl
bmFibGUgcG9ydCBwb3dlciBvbiBub24tc3dpdGNoYWJsZSBodWINClsgICAgMi4xMTY0MDhd
IGVoY2lfaGNkIDAwMDA6MDA6MWQuNzogSFMgY29tcGFuaW9uIGZvciAwMDAwOjAwOjFkLjAN
ClsgICAgMi4xMTY0MzddIHhlbjogcmVnaXN0ZXJpbmcgZ3NpIDE5IHRyaWdnZXJpbmcgMCBw
b2xhcml0eSAxDQpbICAgIDIuMTE2NDM5XSBBbHJlYWR5IHNldHVwIHRoZSBHU0kgOjE5DQpb
ICAgIDIuMTE2NDUxXSB1aGNpX2hjZCAwMDAwOjAwOjFkLjE6IHNldHRpbmcgbGF0ZW5jeSB0
aW1lciB0byA2NA0KWyAgICAyLjExNjQ1NV0gdWhjaV9oY2QgMDAwMDowMDoxZC4xOiBVSENJ
IEhvc3QgQ29udHJvbGxlcg0KWyAgICAyLjExNjU4MV0gdWhjaV9oY2QgMDAwMDowMDoxZC4x
OiBuZXcgVVNCIGJ1cyByZWdpc3RlcmVkLCBhc3NpZ25lZCBidXMgbnVtYmVyIDcNClsgICAg
Mi4xMTY1OTJdIHVoY2lfaGNkIDAwMDA6MDA6MWQuMTogZGV0ZWN0ZWQgMiBwb3J0cw0KWyAg
ICAyLjExNjU5OV0gdWhjaV9oY2QgMDAwMDowMDoxZC4xOiB1aGNpX2NoZWNrX2FuZF9yZXNl
dF9oYzogY21kID0gMHgwMDAwDQpbICAgIDIuMTE2NjAwXSB1aGNpX2hjZCAwMDAwOjAwOjFk
LjE6IFBlcmZvcm1pbmcgZnVsbCByZXNldA0KWyAgICAyLjExNjYxOV0gdWhjaV9oY2QgMDAw
MDowMDoxZC4xOiBzdXBwb3J0cyBVU0IgcmVtb3RlIHdha2V1cA0KWyAgICAyLjExNjY0OF0g
dWhjaV9oY2QgMDAwMDowMDoxZC4xOiBpcnEgMTksIGlvIGJhc2UgMHgwMDAwYjA4MA0KWyAg
ICAyLjExNjczMF0gdXNiIHVzYjc6IGRlZmF1bHQgbGFuZ3VhZ2UgMHgwNDA5DQpbICAgIDIu
MTE2NzQyXSB1c2IgdXNiNzogdWRldiAxLCBidXNudW0gNywgbWlub3IgPSA3NjgNClsgICAg
Mi4xMTY3NDRdIHVzYiB1c2I3OiBOZXcgVVNCIGRldmljZSBmb3VuZCwgaWRWZW5kb3I9MWQ2
YiwgaWRQcm9kdWN0PTAwMDENClsgICAgMi4xMTY3NDZdIHVzYiB1c2I3OiBOZXcgVVNCIGRl
dmljZSBzdHJpbmdzOiBNZnI9MywgUHJvZHVjdD0yLCBTZXJpYWxOdW1iZXI9MQ0KWyAgICAy
LjExNjc0N10gdXNiIHVzYjc6IFByb2R1Y3Q6IFVIQ0kgSG9zdCBDb250cm9sbGVyDQpbICAg
IDIuMTE2NzQ5XSB1c2IgdXNiNzogTWFudWZhY3R1cmVyOiBMaW51eCAzLjYuMC1yYzQtMjAx
MjA4MzArIHVoY2lfaGNkDQpbICAgIDIuMTE2NzUwXSB1c2IgdXNiNzogU2VyaWFsTnVtYmVy
OiAwMDAwOjAwOjFkLjENClsgICAgMi4xMTY5NjFdIHVzYiB1c2I3OiB1c2JfcHJvYmVfZGV2
aWNlDQpbICAgIDIuMTE2OTY0XSB1c2IgdXNiNzogY29uZmlndXJhdGlvbiAjMSBjaG9zZW4g
ZnJvbSAxIGNob2ljZQ0KWyAgICAyLjExNjk3OF0gdXNiIHVzYjc6IGFkZGluZyA3LTA6MS4w
IChjb25maWcgIzEsIGludGVyZmFjZSAwKQ0KWyAgICAyLjExNzEyNl0gaHViIDctMDoxLjA6
IHVzYl9wcm9iZV9pbnRlcmZhY2UNClsgICAgMi4xMTcxMjhdIGh1YiA3LTA6MS4wOiB1c2Jf
cHJvYmVfaW50ZXJmYWNlIC0gZ290IGlkDQpbICAgIDIuMTE3MTMxXSBodWIgNy0wOjEuMDog
VVNCIGh1YiBmb3VuZA0KWyAgICAyLjExNzE1MF0gaHViIDctMDoxLjA6IDIgcG9ydHMgZGV0
ZWN0ZWQNClsgICAgMi4xMTcxNTJdIGh1YiA3LTA6MS4wOiBzdGFuZGFsb25lIGh1Yg0KWyAg
ICAyLjExNzE1M10gaHViIDctMDoxLjA6IG5vIHBvd2VyIHN3aXRjaGluZyAodXNiIDEuMCkN
ClsgICAgMi4xMTcxNTVdIGh1YiA3LTA6MS4wOiBpbmRpdmlkdWFsIHBvcnQgb3Zlci1jdXJy
ZW50IHByb3RlY3Rpb24NClsgICAgMi4xMTcxNTddIGh1YiA3LTA6MS4wOiBwb3dlciBvbiB0
byBwb3dlciBnb29kIHRpbWU6IDJtcw0KWyAgICAyLjExNzE2OV0gaHViIDctMDoxLjA6IGxv
Y2FsIHBvd2VyIHNvdXJjZSBpcyBnb29kDQpbICAgIDIuMTE3MTcyXSBodWIgNy0wOjEuMDog
dHJ5aW5nIHRvIGVuYWJsZSBwb3J0IHBvd2VyIG9uIG5vbi1zd2l0Y2hhYmxlIGh1Yg0KWyAg
ICAyLjExNzI3Ml0gZWhjaV9oY2QgMDAwMDowMDoxZC43OiBIUyBjb21wYW5pb24gZm9yIDAw
MDA6MDA6MWQuMQ0KWyAgICAyLjExNzMwMV0geGVuOiByZWdpc3RlcmluZyBnc2kgMTggdHJp
Z2dlcmluZyAwIHBvbGFyaXR5IDENClsgICAgMi4xMTczMDNdIEFscmVhZHkgc2V0dXAgdGhl
IEdTSSA6MTgNClsgICAgMi4xMTczMTVdIHVoY2lfaGNkIDAwMDA6MDA6MWQuMjogc2V0dGlu
ZyBsYXRlbmN5IHRpbWVyIHRvIDY0DQpbICAgIDIuMTE3MzE5XSB1aGNpX2hjZCAwMDAwOjAw
OjFkLjI6IFVIQ0kgSG9zdCBDb250cm9sbGVyDQpbICAgIDIuMTE3NDYwXSB1aGNpX2hjZCAw
MDAwOjAwOjFkLjI6IG5ldyBVU0IgYnVzIHJlZ2lzdGVyZWQsIGFzc2lnbmVkIGJ1cyBudW1i
ZXIgOA0KWyAgICAyLjExNzQ3MF0gdWhjaV9oY2QgMDAwMDowMDoxZC4yOiBkZXRlY3RlZCAy
IHBvcnRzDQpbICAgIDIuMTE3NDc3XSB1aGNpX2hjZCAwMDAwOjAwOjFkLjI6IHVoY2lfY2hl
Y2tfYW5kX3Jlc2V0X2hjOiBjbWQgPSAweDAwMDANClsgICAgMi4xMTc0NzhdIHVoY2lfaGNk
IDAwMDA6MDA6MWQuMjogUGVyZm9ybWluZyBmdWxsIHJlc2V0DQpbICAgIDIuMTE3NDk4XSB1
aGNpX2hjZCAwMDAwOjAwOjFkLjI6IHN1cHBvcnRzIFVTQiByZW1vdGUgd2FrZXVwDQpbICAg
IDIuMTE3NTA0XSB1aGNpX2hjZCAwMDAwOjAwOjFkLjI6IGlycSAxOCwgaW8gYmFzZSAweDAw
MDBiNDAwDQpbICAgIDIuMTE3NTcyXSB1c2IgdXNiODogZGVmYXVsdCBsYW5ndWFnZSAweDA0
MDkNClsgICAgMi4xMTc1ODRdIHVzYiB1c2I4OiB1ZGV2IDEsIGJ1c251bSA4LCBtaW5vciA9
IDg5Ng0KWyAgICAyLjExNzU4Nl0gdXNiIHVzYjg6IE5ldyBVU0IgZGV2aWNlIGZvdW5kLCBp
ZFZlbmRvcj0xZDZiLCBpZFByb2R1Y3Q9MDAwMQ0KWyAgICAyLjExNzU4OF0gdXNiIHVzYjg6
IE5ldyBVU0IgZGV2aWNlIHN0cmluZ3M6IE1mcj0zLCBQcm9kdWN0PTIsIFNlcmlhbE51bWJl
cj0xDQpbICAgIDIuMTE3NTg5XSB1c2IgdXNiODogUHJvZHVjdDogVUhDSSBIb3N0IENvbnRy
b2xsZXINClsgICAgMi4xMTc1OTFdIHVzYiB1c2I4OiBNYW51ZmFjdHVyZXI6IExpbnV4IDMu
Ni4wLXJjNC0yMDEyMDgzMCsgdWhjaV9oY2QNClsgICAgMi4xMTc1OTJdIHVzYiB1c2I4OiBT
ZXJpYWxOdW1iZXI6IDAwMDA6MDA6MWQuMg0KWyAgICAyLjExNzc1M10gdXNiIHVzYjg6IHVz
Yl9wcm9iZV9kZXZpY2UNClsgICAgMi4xMTc3NTVdIHVzYiB1c2I4OiBjb25maWd1cmF0aW9u
ICMxIGNob3NlbiBmcm9tIDEgY2hvaWNlDQpbICAgIDIuMTE3NzY1XSB1c2IgdXNiODogYWRk
aW5nIDgtMDoxLjAgKGNvbmZpZyAjMSwgaW50ZXJmYWNlIDApDQpbICAgIDIuMTE3ODk5XSBo
dWIgOC0wOjEuMDogdXNiX3Byb2JlX2ludGVyZmFjZQ0KWyAgICAyLjExNzkwMV0gaHViIDgt
MDoxLjA6IHVzYl9wcm9iZV9pbnRlcmZhY2UgLSBnb3QgaWQNClsgICAgMi4xMTc5MDNdIGh1
YiA4LTA6MS4wOiBVU0IgaHViIGZvdW5kDQpbICAgIDIuMTE3OTEwXSBodWIgOC0wOjEuMDog
MiBwb3J0cyBkZXRlY3RlZA0KWyAgICAyLjExNzkxMl0gaHViIDgtMDoxLjA6IHN0YW5kYWxv
bmUgaHViDQpbICAgIDIuMTE3OTEzXSBodWIgOC0wOjEuMDogbm8gcG93ZXIgc3dpdGNoaW5n
ICh1c2IgMS4wKQ0KWyAgICAyLjExNzkxNF0gaHViIDgtMDoxLjA6IGluZGl2aWR1YWwgcG9y
dCBvdmVyLWN1cnJlbnQgcHJvdGVjdGlvbg0KWyAgICAyLjExNzkxNV0gaHViIDgtMDoxLjA6
IHBvd2VyIG9uIHRvIHBvd2VyIGdvb2QgdGltZTogMm1zDQpbICAgIDIuMTE3OTI0XSBodWIg
OC0wOjEuMDogbG9jYWwgcG93ZXIgc291cmNlIGlzIGdvb2QNClsgICAgMi4xMTc5MjZdIGh1
YiA4LTA6MS4wOiB0cnlpbmcgdG8gZW5hYmxlIHBvcnQgcG93ZXIgb24gbm9uLXN3aXRjaGFi
bGUgaHViDQpbICAgIDIuMTE4MDI0XSBlaGNpX2hjZCAwMDAwOjAwOjFkLjc6IEhTIGNvbXBh
bmlvbiBmb3IgMDAwMDowMDoxZC4yDQpbICAgIDIuMTE4MjI5XSB1c2Jjb3JlOiByZWdpc3Rl
cmVkIG5ldyBpbnRlcmZhY2UgZHJpdmVyIHVzYmxwDQpbICAgIDIuMTE4MjMwXSBJbml0aWFs
aXppbmcgVVNCIE1hc3MgU3RvcmFnZSBkcml2ZXIuLi4NClsgICAgMi4xMTgzMzldIHVzYmNv
cmU6IHJlZ2lzdGVyZWQgbmV3IGludGVyZmFjZSBkcml2ZXIgdXNiLXN0b3JhZ2UNClsgICAg
Mi4xMTgzNDBdIFVTQiBNYXNzIFN0b3JhZ2Ugc3VwcG9ydCByZWdpc3RlcmVkLg0KWyAgICAy
LjExODU1N10gdXNiY29yZTogcmVnaXN0ZXJlZCBuZXcgaW50ZXJmYWNlIGRyaXZlciBsaWJ1
c3VhbA0KWyAgICAyLjExODc0N10gdXNiY29yZTogcmVnaXN0ZXJlZCBuZXcgaW50ZXJmYWNl
IGRyaXZlciB1c2JzZXJpYWwNClsgICAgMi4xMTg3NDhdIHVzYnNlcmlhbDogVVNCIFNlcmlh
bCBEcml2ZXIgY29yZQ0KWyAgICAyLjExODgzNV0gdXNiY29yZTogcmVnaXN0ZXJlZCBuZXcg
aW50ZXJmYWNlIGRyaXZlciBjcDIxMHgNClsgICAgMi4xMTg5ODVdIFVTQiBTZXJpYWwgc3Vw
cG9ydCByZWdpc3RlcmVkIGZvciBjcDIxMHgNClsgICAgMi4xMTkwODddIHVzYmNvcmU6IHJl
Z2lzdGVyZWQgbmV3IGludGVyZmFjZSBkcml2ZXIgY3lwcmVzc19tOA0KWyAgICAyLjExOTE2
N10gVVNCIFNlcmlhbCBzdXBwb3J0IHJlZ2lzdGVyZWQgZm9yIERlTG9ybWUgRWFydGhtYXRl
IFVTQg0KWyAgICAyLjExOTI1NV0gVVNCIFNlcmlhbCBzdXBwb3J0IHJlZ2lzdGVyZWQgZm9y
IEhJRC0+Q09NIFJTMjMyIEFkYXB0ZXINClsgICAgMi4xMTkzMzhdIFVTQiBTZXJpYWwgc3Vw
cG9ydCByZWdpc3RlcmVkIGZvciBOb2tpYSBDQS00MiBWMiBBZGFwdGVyDQpbICAgIDIuMTE5
NDMyXSB1c2Jjb3JlOiByZWdpc3RlcmVkIG5ldyBpbnRlcmZhY2UgZHJpdmVyIG1vczc3MjAN
ClsgICAgMi4xMTk1MTJdIFVTQiBTZXJpYWwgc3VwcG9ydCByZWdpc3RlcmVkIGZvciBNb3Nj
aGlwIDIgcG9ydCBhZGFwdGVyDQpbICAgIDIuMTE5NjA4XSB1c2Jjb3JlOiByZWdpc3RlcmVk
IG5ldyBpbnRlcmZhY2UgZHJpdmVyIG1vczc4NDANClsgICAgMi4xMTk2OTJdIFVTQiBTZXJp
YWwgc3VwcG9ydCByZWdpc3RlcmVkIGZvciBNb3NjaGlwIDc4NDAvNzgyMCBVU0IgU2VyaWFs
IERyaXZlcg0KWyAgICAyLjExOTkxNF0gaTgwNDI6IFBOUDogUFMvMiBDb250cm9sbGVyIFtQ
TlAwMzAzOlBTMkssUE5QMGYwMzpQUzJNXSBhdCAweDYwLDB4NjQgaXJxIDEsMTINClsgICAg
Mi4xMjMzNDFdIHNlcmlvOiBpODA0MiBLQkQgcG9ydCBhdCAweDYwLDB4NjQgaXJxIDENClsg
ICAgMi4xMjM2MDZdIHNlcmlvOiBpODA0MiBBVVggcG9ydCBhdCAweDYwLDB4NjQgaXJxIDEy
DQpbICAgIDIuMTIzODk1XSBtb3VzZWRldjogUFMvMiBtb3VzZSBkZXZpY2UgY29tbW9uIGZv
ciBhbGwgbWljZQ0KWyAgICAyLjEyNDUzOF0gcnRjX2Ntb3MgMDA6MDM6IFJUQyBjYW4gd2Fr
ZSBmcm9tIFM0DQpbICAgIDIuMTI1MDMzXSBydGNfY21vcyAwMDowMzogcnRjIGNvcmU6IHJl
Z2lzdGVyZWQgcnRjX2Ntb3MgYXMgcnRjMA0KWyAgICAyLjEyNTA5Ml0gcnRjMDogYWxhcm1z
IHVwIHRvIG9uZSBtb250aCwgeTNrLCAxMTQgYnl0ZXMgbnZyYW0NClsgICAgMi4xMjUyNzFd
IHhlbjogcmVnaXN0ZXJpbmcgZ3NpIDE4IHRyaWdnZXJpbmcgMCBwb2xhcml0eSAxDQpbICAg
IDIuMTI1Mjc1XSBBbHJlYWR5IHNldHVwIHRoZSBHU0kgOjE4DQpbICAgIDIuMTI1Mjg0XSBB
Q1BJIFdhcm5pbmc6IDB4MDAwMDAwMDAwMDAwMDQwMC0weDAwMDAwMDAwMDAwMDA0MWYgU3lz
dGVtSU8gY29uZmxpY3RzIHdpdGggUmVnaW9uIFxTTVJHIDEgKDIwMTIwNzExL3V0YWRkcmVz
cy0yNTEpDQpbICAgIDIuMTI1Mjg2XSBBQ1BJOiBJZiBhbiBBQ1BJIGRyaXZlciBpcyBhdmFp
bGFibGUgZm9yIHRoaXMgZGV2aWNlLCB5b3Ugc2hvdWxkIHVzZSBpdCBpbnN0ZWFkIG9mIHRo
ZSBuYXRpdmUgZHJpdmVyDQpbICAgIDIuMTI1Njg3XSBsaXJjX2RldjogSVIgUmVtb3RlIENv
bnRyb2wgZHJpdmVyIHJlZ2lzdGVyZWQsIG1ham9yIDI1MCANClsgICAgMi4xMjU3MDhdIElS
IE5FQyBwcm90b2NvbCBoYW5kbGVyIGluaXRpYWxpemVkDQpbICAgIDIuMTI1NzEwXSBJUiBS
QzUoeCkgcHJvdG9jb2wgaGFuZGxlciBpbml0aWFsaXplZA0KWyAgICAyLjEyNTcxMV0gSVIg
UkM2IHByb3RvY29sIGhhbmRsZXIgaW5pdGlhbGl6ZWQNClsgICAgMi4xMjU3MTJdIElSIEpW
QyBwcm90b2NvbCBoYW5kbGVyIGluaXRpYWxpemVkDQpbICAgIDIuMTI1NzEzXSBJUiBTb255
IHByb3RvY29sIGhhbmRsZXIgaW5pdGlhbGl6ZWQNClsgICAgMi4xMjU3MTVdIElSIFJDNSAo
c3RyZWFtemFwKSBwcm90b2NvbCBoYW5kbGVyIGluaXRpYWxpemVkDQpbICAgIDIuMTI1NzE2
XSBJUiBTQU5ZTyBwcm90b2NvbCBoYW5kbGVyIGluaXRpYWxpemVkDQpbICAgIDIuMTI1NzE3
XSBJUiBNQ0UgS2V5Ym9hcmQvbW91c2UgcHJvdG9jb2wgaGFuZGxlciBpbml0aWFsaXplZA0K
WyAgICAyLjEyNTcxOF0gSVIgTElSQyBicmlkZ2UgaGFuZGxlciBpbml0aWFsaXplZA0KWyAg
ICAyLjEyNzM1Nl0gY3g4OC8wOiBjeDIzODh4IHY0bDIgZHJpdmVyIHZlcnNpb24gMC4wLjkg
bG9hZGVkDQpbICAgIDIuMTI3NjM2XSB1c2Jjb3JlOiByZWdpc3RlcmVkIG5ldyBpbnRlcmZh
Y2UgZHJpdmVyIGVtMjh4eA0KWyAgICAyLjEyNzc2OV0gdXNiY29yZTogcmVnaXN0ZXJlZCBu
ZXcgaW50ZXJmYWNlIGRyaXZlciBjeDIzMXh4DQpbICAgIDIuMTI3NzczXSBjeDI1ODIxOiBk
cml2ZXIgdmVyc2lvbiAwLjAuMTA2IGxvYWRlZA0KWyAgICAyLjEyODIwNF0gdXNiY29yZTog
cmVnaXN0ZXJlZCBuZXcgaW50ZXJmYWNlIGRyaXZlciBwdnJ1c2IyDQpbICAgIDIuMTI4MjA1
XSBwdnJ1c2IyOiBWNEwgaW4tdHJlZSB2ZXJzaW9uOkhhdXBwYXVnZSBXaW5UVi1QVlItVVNC
MiBNUEVHMiBFbmNvZGVyL1R1bmVyDQpbICAgIDIuMTI4MjA2XSBwdnJ1c2IyOiBEZWJ1ZyBt
YXNrIGlzIDMxICgweDFmKQ0KWyAgICAyLjEyODMzNl0gdXNiY29yZTogcmVnaXN0ZXJlZCBu
ZXcgaW50ZXJmYWNlIGRyaXZlciBQaGlsaXBzIHdlYmNhbQ0KWyAgICAyLjEyODMzN10gaXZ0
djogU3RhcnQgaW5pdGlhbGl6YXRpb24sIHZlcnNpb24gMS40LjMNClsgICAgMi4xMjg0NjVd
IGl2dHY6IEVuZCBpbml0aWFsaXphdGlvbg0KWyAgICAyLjEyODQ2N10gaXZ0dmZiOiAgbm8g
Y2FyZHMgZm91bmQNClsgICAgMi4xMjg3NTZdIHZpdmktMDAwOiBWNEwyIGRldmljZSByZWdp
c3RlcmVkIGFzIHZpZGVvMA0KWyAgICAyLjEyODc1N10gVmlkZW8gVGVjaG5vbG9neSBNYWdh
emluZSBWaXJ0dWFsIFZpZGVvIENhcHR1cmUgQm9hcmQgdmVyIDAuOC4xIHN1Y2Nlc3NmdWxs
eSBsb2FkZWQuDQpbICAgIDIuMTI4NzU4XSBjeDIzODg1IGRyaXZlciB2ZXJzaW9uIDAuMC4z
IGxvYWRlZA0KWyAgICAyLjEyOTA0Nl0gdXNiY29yZTogcmVnaXN0ZXJlZCBuZXcgaW50ZXJm
YWNlIGRyaXZlciB1dmN2aWRlbw0KWyAgICAyLjEyOTA0N10gVVNCIFZpZGVvIENsYXNzIGRy
aXZlciAoMS4xLjEpDQpbICAgIDIuMTI5OTAxXSBzcDUxMDBfdGNvOiBTUDUxMDAgVENPIFdh
dGNoRG9nIFRpbWVyIERyaXZlciB2MC4wMQ0KWyAgICAyLjEzMDIzOF0geGVuX3dkdDogWGVu
IFdhdGNoRG9nIFRpbWVyIERyaXZlciB2MC4wMQ0KWyAgICAyLjEzMDcxOF0geGVuX3dkdDog
aW5pdGlhbGl6ZWQgKHRpbWVvdXQ9NjBzLCBub3dheW91dD0wKQ0KWyAgICAyLjEzMTM3M10g
ZGV2aWNlLW1hcHBlcjogaW9jdGw6IDQuMjMuMC1pb2N0bCAoMjAxMi0wNy0yNSkgaW5pdGlh
bGlzZWQ6IGRtLWRldmVsQHJlZGhhdC5jb20NClsgICAgMi4xMzU1MTZdIHVzYmNvcmU6IHJl
Z2lzdGVyZWQgbmV3IGludGVyZmFjZSBkcml2ZXIgdXNiaGlkDQpbICAgIDIuMTM1NTE3XSB1
c2JoaWQ6IFVTQiBISUQgY29yZSBkcml2ZXINClsgICAgMi4xMzk4NTVdIHhlbjogcmVnaXN0
ZXJpbmcgZ3NpIDIyIHRyaWdnZXJpbmcgMCBwb2xhcml0eSAxDQpbICAgIDIuMTM5ODU5XSBB
bHJlYWR5IHNldHVwIHRoZSBHU0kgOjIyDQpbICAgIDIuMTQ3NTAzXSBpbnB1dDogQVQgVHJh
bnNsYXRlZCBTZXQgMiBrZXlib2FyZCBhcyAvZGV2aWNlcy9wbGF0Zm9ybS9pODA0Mi9zZXJp
bzAvaW5wdXQvaW5wdXQyDQpbICAgIDIuMTg0NjM2XSB4ZW46IHJlZ2lzdGVyaW5nIGdzaSAx
NyB0cmlnZ2VyaW5nIDAgcG9sYXJpdHkgMQ0KWyAgICAyLjE4NDYzOV0gQWxyZWFkeSBzZXR1
cCB0aGUgR1NJIDoxNw0KWyAgICAyLjE5ODY0Nl0gdXNiY29yZTogcmVnaXN0ZXJlZCBuZXcg
aW50ZXJmYWNlIGRyaXZlciBzbmQtdXNiLWF1ZGlvDQpbICAgIDIuMTk4NzY1XSB1c2Jjb3Jl
OiByZWdpc3RlcmVkIG5ldyBpbnRlcmZhY2UgZHJpdmVyIHNuZC11YTEwMQ0KWyAgICAyLjE5
ODg4NF0gdXNiY29yZTogcmVnaXN0ZXJlZCBuZXcgaW50ZXJmYWNlIGRyaXZlciBzbmQtdXNi
LXVzeDJ5DQpbICAgIDIuMTk5MDIxXSB1c2Jjb3JlOiByZWdpc3RlcmVkIG5ldyBpbnRlcmZh
Y2UgZHJpdmVyIHNuZC11c2ItY2FpYXENClsgICAgMi4xOTkxNDRdIHVzYmNvcmU6IHJlZ2lz
dGVyZWQgbmV3IGludGVyZmFjZSBkcml2ZXIgc25kLXVzYi02ZmlyZQ0KWyAgICAyLjE5OTE3
OF0gTmV0ZmlsdGVyIG1lc3NhZ2VzIHZpYSBORVRMSU5LIHYwLjMwLg0KWyAgICAyLjE5OTE4
NV0gbmZubF9hY2N0OiByZWdpc3RlcmluZyB3aXRoIG5mbmV0bGluay4NClsgICAgMi4xOTky
MzhdIG5mX2Nvbm50cmFjayB2ZXJzaW9uIDAuNS4wICg3MzA5IGJ1Y1sgICAgNy40MDQ3Njdd
IHVkZXZbMTgwNV06IHN0YXJ0aW5nIHZlcnNpb24gMTY0DQpbICAgIDkuNzY3ODkzXSBBZGRp
bmcgMzIyOTAyOGsgc3dhcCBvbiAvZGV2L3NkYTUuICBQcmlvcml0eTotMSBleHRlbnRzOjEg
YWNyb3NzOjMyMjkwMjhrIA0KWyAgIDEwLjA2OTg1M10gRVhUMy1mcyAoc2RhMSk6IHVzaW5n
IGludGVybmFsIGpvdXJuYWwNClsgICAxMy40ODQyODFdIGUxMDAwZTogZXRoMSBOSUMgTGlu
ayBpcyBVcCAxMDAgTWJwcyBGdWxsIER1cGxleCwgRmxvdyBDb250cm9sOiBSeC9UeA0KWyAg
IDEzLjUwNTk3M10gZTEwMDBlIDAwMDA6MDA6MTkuMDogZXRoMTogMTAvMTAwIHNwZWVkOiBk
aXNhYmxpbmcgVFNPDQpbICAgMTYuMjY5MzYzXSBzc2hkICgyNzA1KTogL3Byb2MvMjcwNS9v
b21fYWRqIGlzIGRlcHJlY2F0ZWQsIHBsZWFzZSB1c2UgL3Byb2MvMjcwNS9vb21fc2NvcmVf
YWRqIGluc3RlYWQuDQpbICAxMzMuNzU5OTM1XSBkZXZpY2UgdmlmMS4wIGVudGVyZWQgcHJv
bWlzY3VvdXMgbW9kZQ0KbWFwcGluZyBrZXJuZWwgaW50byBwaHlzaWNhbCBtZW1vcnkNCmFi
b3V0IHRvIGdldCBzdGFydGVkLi4uDQpbICAxMzQuMjgzODEwXSB4ZW5fYnJpZGdlOiBwb3J0
IDEodmlmMS4wKSBlbnRlcmVkIGZvcndhcmRpbmcgc3RhdGUNClsgIDEzNC4yOTQ1NzddIHhl
bl9icmlkZ2U6IHBvcnQgMSh2aWYxLjApIGVudGVyZWQgZm9yd2FyZGluZyBzdGF0ZQ0KWyAg
MTM0LjcwODcxNV0gMzk4M2MgaXMgMjQyMmIwMDAhDQpbICAxMzQuNzE4OTc5XSAzNmQxYSBp
cyAyNDM0MTAwMCENClsgIDEzNC43NzA5MThdIDM3NDE3IGlzIDI0MzJiMDAwIQ0KWyAgMTM0
LjgwNjEwNl0gMzc2YjUgaXMgMjQxY2YwMDAhDQpbICAxMzQuODMxNDc2XSAzN2I2OSBpcyAy
NDFkNzAwMCENClsgIDEzNC44NDA3NzBdIDM3N2VjIGlzIDI0MWY5MDAwIQ0KWyAgMTM0Ljg1
MDAwN10gMzZmMTcgaXMgMjQxZDYwMDAhDQpbICAxMzQuODU4NzA1XSAzOGNhYyBpcyAyNDFj
YjAwMCENClsgIDEzNC44ODA2OTVdIDM3YjgzIGlzIDI0Mjk4MDAwIQ0KWyAgMTM0LjkxNjc3
Nl0gMzc4NzcgaXMgMjQyNTEwMDAhDQpbICAxMzQuOTI0NTUxXSAzNjQzZCBpcyAyNDFkMTAw
MCENClsgIDEzNC45MzI1OTZdIDM3ODkwIGlzIDI0MjlkMDAwIQ0KWyAgMTM0Ljk0MDEzNF0g
MzkzYzcgaXMgMjQyMGEwMDAhDQpbICAxMzQuOTQ3OTc4XSAzNzY5MiBpcyAyNDI4NjAwMCEN
ClsgIDEzNC45NTUzNThdIDM2ZWE2IGlzIDI0MWE5MDAwIQ0KWyAgMTM0Ljk2MjkyOV0gMzY1
NDEgaXMgMjQxYTcwMDAhDQpbICAxMzQuOTgxNTU4XSAzN2VlZCBpcyAyNDFhNjAwMCENClsg
IDEzNC45OTUzNDZdIDM5MTljIGlzIDI0MWE4MDAwIQ0KWyAgMTM1LjAwMjIyNl0gMzZmY2Mg
aXMgMjQzMzcwMDAhDQpbICAxMzUuMDA4MzMxXSAzNzUwZSBpcyAyNDIxMzAwMCENClsgIDEz
NS4wMTUxNzhdIDM3NDE2IGlzIDI0MjZkMDAwIQ0KWyAgMTM1LjAzMTU0MF0gMzZkNjAgaXMg
MjQyM2IwMDAhDQpbICAxMzUuMDM4MDY3XSAzNzg5MSBpcyAyNDIyZTAwMCENClsgIDEzNS4w
NDI0MjNdIDM4NDg1IGlzIDI0MmVjMDAwIQ0KWyAgMTM1LjA0NzA0MV0gMzZlMTIgaXMgMjQy
MmQwMDAhDQpbICAxMzUuMDUyNTAyXSAzN2VlYyBpcyAyNDIyMDAwMCENClsgIDEzNS4wNjA0
MzNdIDM3NTU0IGlzIDI0MmNiMDAwIQ0KWyAgMTM1LjA2NjE0M10gMzkzODkgaXMgMjQyZTMw
MDAhDQpbICAxMzUuMDcwNjU4XSAzOGNiMCBpcyAyNDJkNjAwMCENClsgIDEzNS4xNDI5NzNd
IDM3ZDIxIGlzIDI0MWE2MDAwIQ0KWyAgMTM1LjE0NTYzOF0gMzZlNTYgaXMgMjQyZTMwMDAh
DQpbICAxMzUuMTQ4MzM4XSAzN2ZjNCBpcyAyNDFhNzAwMCENClsgIDEzNS4xNTA3NzNdIDM3
ODZjIGlzIDI0MjUxMDAwIQ0KWyAgMTM1LjE1MzgyMV0gMzdiMzEgaXMgMjQyNjkwMDAhDQpb
ICAxMzUuMTU2MjUxXSAzODM4YSBpcyAyNDJlZTAwMCENClsgIDEzNS4xNTg2ODBdIDM3YmMw
IGlzIDI0MWRjMDAwIQ0KWyAgMTM1LjE2MTA5OF0gMzdmZGYgaXMgMjQyNTIwMDAhDQpbICAx
MzUuMTY1NjYyXSAzN2Q4MyBpcyA3YTIwZjAwMCENClsgIDEzNS4xNjg1MDddIDM5MzdhIGlz
IDdhMjBmMDAwIQ0KWyAgMTM1LjE3MTMxMV0gMzZmMzEgaXMgN2EyNDEwMDAhDQpbICAxMzUu
MTc0MDk1XSAzOTBmNiBpcyA3YTIwNzAwMCENClsgIDEzNS4xODY0OTJdIDM5ODI4IGlzIDdh
MGQ0MDAwIQ0KWyAgMTM1LjIyNjQyOF0gMzZlNzEgaXMgNzk0MmUwMDAhDQpbICAxMzUuMjM3
NTkxXSAzN2I4MSBpcyA3YTIzMDAwMCENClsgIDEzNS4yNTI4NDldIDM4MzhiIGlzIDdhMjQ2
MDAwIQ0KWyAgMTM1LjI1OTI4Ml0gMzhjYWQgaXMgN2EyMTEwMDAhDQpbICAxMzUuMjY1MjYx
XSAzOGQxMCBpcyA3YTI0MDAwMCENClsgIDEzNS4yODEzOTZdIDM4MzM2IGlzIDdhMWYxMDAw
IQ0KWyAgMTM1LjI4NDI1Ml0gMzY1OTYgaXMgNzhlYWYwMDAhDQpbICAxMzUuMzA1NzA1XSAz
NzVjYyBpcyA3YTFkMDAwMCENClsgIDEzNS4zMDgyMjJdIDM2NTk3IGlzIDdhMWNlMDAwIQ0K
WyAgMTM1LjMxMDY0OV0gMzY0YzQgaXMgN2ExZDEwMDAhDQpbICAxMzUuMzEzMDYxXSAzNjRj
NSBpcyA3YTI0OTAwMCENClsgIDEzNS4zMjI3NjVdIDM3NTJiIGlzIDdhMjA2MDAwIQ0KWyAg
MTM1LjMzNjY2NV0gMzhkMTggaXMgN2ExZmUwMDAhDQpbICAxMzUuMzQ3MjIyXSAzOGQxOSBp
cyA3YTIwZTAwMCENClsgIDEzNS4zNTAyMDldIDM3NTJhIGlzIDdhMWNmMDAwIQ0KWyAgMTM1
LjM1Mjk4OF0gMzdhMWUgaXMgN2EyMTAwMDAhDQpbICAxMzUuMzY3NjQyXSAzN2E5OCBpcyA3
YTFmMDAwMCENClsgIDEzNS4zODMwNDFdIDM3YTk5IGlzIDIxOTE1MDAwIQ0KWyAgMTM1LjM4
NTQ4M10gMzdmMTAgaXMgN2E3NzgwMDAhDQpbICAxMzUuMzg3ODkzXSAzODI5MiBpcyAyMWQ5
MTAwMCENClsgIDEzNS4zOTAyODldIDM3NzhhIGlzIDIxOWY1MDAwIQ0KWyAgMTM1LjM5MzMz
MF0gMzc1ZTggaXMgMjFkYTkwMDAhDQpbICAxMzUuMzk1NzY1XSAzOTNjNiBpcyA3YTIwNDAw
MCENClsgIDEzNS4zOTgxOThdIDM2ZTcwIGlzIDdhMjQ0MDAwIQ0KWyAgMTM1LjQwMDY0Ml0g
MzhjYmQgaXMgN2ExY2MwMDAhDQpbICAxMzUuNDAzMDYxXSAzN2JjMSBpcyA3YTFlMTAwMCEN
ClsgIDEzNS40MDU1MDldIDM3ZTZjIGlzIDdhMWZmMDAwIQ0KWyAgMTM1LjQwODMzMV0gMzdm
MjIgaXMgN2ExZmQwMDAhDQpbICAxMzUuNDExNjc3XSAzN2ZjNSBpcyA3OGVhZTAwMCENClsg
IDEzNS40MTQxMTBdIDM5MjQ2IGlzIDc4ZDVjMDAwIQ0KWyAgMTM1LjQxNjUzMl0gMzkzZWQg
aXMgNzk0MzEwMDAhDQpbICAxMzUuNDE4OTU4XSAzODI5MSBpcyAyMTkyNzAwMCENClsgIDEz
NS40MjE0NDJdIDM2ZmNkIGlzIDc5NDJmMDAwIQ0KWyAgMTM1LjQyMzg4NF0gMzkxNDggaXMg
NzhlN2QwMDAhDQpbICAxMzUuNDI2MzM0XSAzNmU5YSBpcyAyMWRiYzAwMCENClsgIDEzNS40
Mjg4MThdIDM2NTU3IGlzIDdhMGQ1MDAwIQ0KWyAgMTM1LjQzMTMwMV0gMzZkZjggaXMgN2Ey
MzEwMDAhDQpbICAxMzUuNDMzNzk5XSAzNmRmNSBpcyAyMTkwNjAwMCENClsgIDEzNS40MzYy
NjJdIDM5ODI5IGlzIDdhMjU1MDAwIQ0KWyAgMTM1LjQzODg2Nl0gMzdlYzAgaXMgNzhlYmMw
MDAhDQpbICAxMzUuNDQxNDIwXSAzNjQ2MSBpcyA3OTJkNDAwMCENClsgIDEzNS40NDM5NDRd
IDM3ZTZkIGlzIDdhMjQ3MDAwIQ0KWyAgMTM1LjQ0NjQ5NF0gMzgzMDggaXMgN2EwZWEwMDAh
DQpbICAxMzUuNDQ5MDI3XSAzN2UyNSBpcyAyMWQ5ODAwMCENClsgIDEzNS40NTE1ODVdIDM5
MzIyIGlzIDdhMGNlMDAwIQ0KWyAgMTM1LjQ1NDE3MV0gMzdjMjQgaXMgN2ExY2QwMDAhDQpb
ICAxMzUuNDU3NDY3XSAzOTFmYyBpcyAyMWRlMzAwMCENClsgIDEzNS40NjAwODNdIDM3NWU5
IGlzIDIxZGZkMDAwIQ0KWyAgMTM1LjQ2MjY2N10gMzc3NWMgaXMgNzk0M2MwMDAhDQpbICAx
MzUuNDY1MjczXSAzNzc1ZCBpcyA3YTI0NTAwMCENClsgIDEzNS40Njc4NzNdIDM2ZDZjIGlz
IDdhMjRlMDAwIQ0KWyAgMTM1LjQ3MDQ0M10gMzZkNmQgaXMgNzk0MzMwMDAhDQpbICAxMzUu
NDcyOTU5XSAzNmNjMCBpcyA3OTQ0NjAwMCENClsgIDEzNS40NzU1MDhdIDM2Y2MxIGlzIDdh
MWUzMDAwIQ0KWyAgMTM1LjQ4NDMyNV0gMzZkYzQgaXMgMjFkZmYwMDAhDQpbICAxMzUuNDk3
NzEwXSAzOTExMCBpcyAyMWUwMDAwMCENClsgIDEzNS41MDA2NzldIDM2ZGM1IGlzIDIxOTk0
MDAwIQ0KWyAgMTM1LjUyMDM2NV0gMzdlNWQgaXMgN2EyNDgwMDAhDQpbICAxMzUuNTY0ODM1
XSAzNzk2NCBpcyA3YTFkMzAwMCENClsgIDEzNS41Njc0NzddIDM3OTY1IGlzIDdhMjBjMDAw
IQ0KWyAgMTM1LjU3MDAyOF0gMzhjNmMgaXMgN2EyMGQwMDAhDQpbICAxMzUuNTcyNTc4XSAz
OGM2ZCBpcyA3OGQ0ZjAwMCENClsgIDEzNS41NzUxMjFdIDM4ZDZjIGlzIDdhMWZjMDAwIQ0K
WyAgMTM1LjU3NzYzMV0gMzhkNmQgaXMgN2E1ZjIwMDAhDQpbICAxMzUuNTgwMTE1XSAzNzVj
NCBpcyA3OTQ0NDAwMCENClsgIDEzNS41ODI5NjNdIDM3NWM1IGlzIDc5NDJjMDAwIQ0KWyAg
MTM1LjYwMzk3M10gMzc1NjYgaXMgNzhkNGQwMDAhDQpbICAxMzUuNjA2Mzk1XSAzNzVjZCBp
cyA3YTIxMjAwMCENClsgIDEzNS42MDg4NTBdIDM3YmZkIGlzIDdhMjEzMDAwIQ0KWyAgMTM1
LjYxMTI2NV0gMzZmZmMgaXMgN2ExZDIwMDAhDQpbICAxMzUuNjE0MDY3XSAzODMyOCBpcyAy
MTkyNjAwMCENClsgIDEzNS42MjYxMjddIDM2ZmZkIGlzIDdhMjMyMDAwIQ0KWyAgMTM1LjYy
ODcwN10gMzZmZmUgaXMgN2EyMzMwMDAhDQpbICAxMzUuNjMxMDg3XSAzNmZmZiBpcyA3OGVi
ZTAwMCENClsgIDEzNS42MzM0NzRdIDM3YTljIGlzIDc4ZWJmMDAwIQ0KWyAgMTM1LjYzNTgw
MV0gMzdhOWQgaXMgNzkyZDYwMDAhDQpbICAxMzUuNjM4MTQwXSAzN2E5ZSBpcyA3OTJkNzAw
MCENClsgIDEzNS42NDA0NDZdIDM3YTlmIGlzIDdhMjRhMDAwIQ0KWyAgMTM1LjY0MjcyMF0g
MzY0OGMgaXMgN2EyNGIwMDAhDQpbICAxMzUuNjQ0OTk1XSAzNjQ4ZCBpcyAyMWRhYjAwMCEN
ClsgIDEzNS42NDcyNDVdIDM2NDhlIGlzIDIxZGFjMDAwIQ0KWyAgMTM1LjY0OTQ3Ml0gMzY0
OGYgaXMgNzhkNGMwMDAhDQpbICAxMzUuNjUxNzc2XSAzNmM0YyBpcyAyMWRiOTAwMCENClsg
IDEzNS42NTQwMzZdIDM2YzRkIGlzIDIxZGJhMDAwIQ0KWyAgMTM1LjY1NjIzNV0gMzZjNGUg
aXMgNzk0M2UwMDAhDQpbICAxMzUuNjU4NDY0XSAzNmM0ZiBpcyA3OTQzZjAwMCENClsgIDEz
NS42NjA2NDJdIDM3YmY0IGlzIDIxOTIxMDAwIQ0KWyAgMTM1LjY2MjgzMl0gMzdiZjUgaXMg
MjE5MjIwMDAhDQpbICAxMzUuNjY4MTExXSAzN2JmNiBpcyA3YTBkNjAwMCENClsgIDEzNS42
NzAyOTZdIDM3YmY3IGlzIDdhMGQ3MDAwIQ0KWyAgMTM1LjY3MjM5MF0gMzc4YTAgaXMgNzhl
YmEwMDAhDQpbICAxMzUuNjc0NTMwXSAzNzhhMSBpcyA3OGViYjAwMCENClsgIDEzNS42Nzcw
OTZdIDM3OGEyIGlzIDdhMjA4MDAwIQ0KWyAgMTM1LjY3OTIxMV0gMzc4YTMgaXMgN2EwZTgw
MDAhDQpbICAxMzUuNjgxMjk4XSAzNzhkNCBpcyA3YTBlOTAwMCENClsgIDEzNS42ODQzNDRd
IDM2NDZjIGlzIDIxOTA4MDAwIQ0KWyAgMTM1LjY4NjQzM10gMzY0NmQgaXMgNzhlYWMwMDAh
DQpbICAxMzUuNjg4NTYxXSAzNjQ2ZSBpcyA3OGVhZDAwMCENClsgIDEzNS42OTA2NTFdIDM2
NDZmIGlzIDdhMGNjMDAwIQ0KWyAgMTM1LjY5MjcyMF0gMzc4ZDUgaXMgN2EwY2QwMDAhDQpb
ICAxMzUuNjk0ODEwXSAzNzhkNiBpcyAyMWRlMTAwMCENClsgIDEzNS42OTY4OTZdIDM3OGQ3
IGlzIDIxZGUyMDAwIQ0KWyAgMTM1LjY5ODkyMF0gMzZkYmMgaXMgMjE5MjUwMDAhDQpbICAx
MzUuNzAwOTYzXSAzNmRiZCBpcyA3OTNmNzAwMCENClsgIDEzNS43MDMwMTFdIDM2ZGJlIGlz
IDdhMjU2MDAwIQ0KWyAgMTM1LjcwNTA4OF0gMzZkYmYgaXMgN2EyNTcwMDAhDQpbICAxMzUu
NzA3MTI2XSAzNmZmMCBpcyA3YTI0YzAwMCENClsgIDEzNS43MDkxNjhdIDM2ZmYxIGlzIDdh
MjRkMDAwIQ0KWyAgMTM1LjcxMTIwMV0gMzZmZjIgaXMgN2EwZWMwMDAhDQpbICAxMzUuNzEz
MjQxXSAzNmZmMyBpcyA3YTBlZDAwMCENClsgIDEzNS43MTU2MzldIDM3YWNjIGlzIDdhMjBh
MDAwIQ0KWyAgMTM1LjcxODA3OV0gMzdhY2QgaXMgN2EyMGIwMDAhDQpbICAxMzUuNzIwNjY3
XSAzN2FjZSBpcyAyMTlmODAwMCENClsgIDEzNS43MjI3MDJdIDM3YWNmIGlzIDIxOTE3MDAw
IQ0KWyAgMTM1LjcyNDczNl0gMzZlMzQgaXMgMjE5MTgwMDAhDQpbICAxMzUuNzI2Nzc0XSAz
NmUzNSBpcyAyMTkwNzAwMCENClsgIDEzNS43MjkxNjVdIDM2ZTM2IGlzIDIxOThlMDAwIQ0K
WyAgMTM1Ljc0Njc0NV0gMzZlMzcgaXMgN2EyNDMwMDAhDQpbICAxMzUuNzQ4ODAzXSAzODNl
OCBpcyA3OGU3ZTAwMCENClsgIDEzNS43NTA4NzhdIDM4M2U5IGlzIDc4ZTdmMDAwIQ0KWyAg
MTM1Ljc1Mjg4MV0gMzgzZWEgaXMgMjE5ZjcwMDAhDQpbICAxMzUuNzU1MTgwXSAzNzkwOCBp
cyA3YTBkMjAwMCENClsgIDEzNS43NTcyNjFdIDM3OTA5IGlzIDdhMGQzMDAwIQ0KWyAgMTM1
Ljc1OTI5NV0gMzdhODggaXMgN2EyMDAwMDAhDQpbICAxMzUuNzYxMzQ4XSAzN2E4OSBpcyA3
YTIwMTAwMCENClsgIDEzNS43NjM0MTNdIDM4MzI5IGlzIDdhMjAyMDAwIQ0KWyAgMTM1Ljc2
NTQ1Ml0gMzZmZjggaXMgN2EyMDMwMDAhDQpbICAxMzUuNzY3NDk2XSAzNmZmOSBpcyA3YTFl
ZTAwMCENClsgIDEzNS43Njk0OTFdIDM3ZjdjIGlzIDdhMWVmMDAwIQ0KWyAgMTM1Ljc3MTUx
N10gMzdmN2QgaXMgN2ExZGMwMDAhDQpbICAxMzUuNzczNTIzXSAzNmZmNCBpcyA3YTFkZDAw
MCENClsgIDEzNS43NzU1MTRdIDM2ZmY1IGlzIDdhMWRlMDAwIQ0KWyAgMTM1Ljc3NzQ4M10g
MzZkYWMgaXMgN2ExZGYwMDAhDQpbICAxMzUuNzc5NDcwXSAzNmRhZCBpcyA3YTFmMjAwMCEN
ClsgIDEzNS43ODE0MjhdIDM2Y2VjIGlzIDdhMWYzMDAwIQ0KWyAgMTM1Ljc4MzM2N10gMzZj
ZWQgaXMgN2EyNDIwMDAhDQpbICAxMzUuNzg2MzU4XSAzNjRmMSBpcyAyMTkxOTAwMCENClsg
IDEzNS43ODg1MzZdIDM3NjYwIGlzIDIxOTFhMDAwIQ0KWyAgMTM1Ljc5MDU0Nl0gMzc2NjEg
aXMgMjE5MWIwMDAhDQpbICAxMzUuNzkyNTA3XSAzNmU3OCBpcyAyMTkxYzAwMCENClsgIDEz
NS43OTQ0NzZdIDM2ZTc5IGlzIDdhNzc0MDAwIQ0KWyAgMTM1Ljc5NjQ4MV0gMzc5NzggaXMg
N2E3NzUwMDAhDQpbICAxMzUuNzk4NDY4XSAzNzk3OSBpcyA3YTc3NjAwMCENClsgIDEzNS44
MDA0ODBdIDM3YjRhIGlzIDdhNzc3MDAwIQ0KWyAgMTM1LjgwMjQzNF0gMzdiNGIgaXMgMjE5
OGQwMDAhDQpbICAxMzUuODA0NDI5XSAzN2IxOCBpcyAyMTk5MDAwMCENClsgIDEzNS44MDYz
OTBdIDM3YjE5IGlzIDc5M2Y4MDAwIQ0KWyAgMTM1LjgwODQwOV0gMzdiMWEgaXMgNzkzZjkw
MDAhDQpbICAxMzUuODEwNDA5XSAzN2IxYiBpcyA3OTNmYTAwMCENClsgIDEzNS44MTIzNThd
IDM2NGY4IGlzIDc5M2ZiMDAwIQ0KWyAgMTM1LjgxNDQzNl0gMzY0ZjkgaXMgN2EyMmMwMDAh
DQpbICAxMzUuODE2Mzk3XSAzNjRmYSBpcyA3YTIyZDAwMCENClsgIDEzNS44MTgzMzBdIDM2
NGZiIGlzIDdhMjJlMDAwIQ0KWyAgMTM1LjgyMDIzN10gMzZjNTQgaXMgN2EyMmYwMDAhDQpb
ICAxMzUuODIyMTIzXSAzNmM1NSBpcyAyMTk2NTAwMCENClsgIDEzNS44MjQwNDNdIDM2YzU2
IGlzIDIxOTY2MDAwIQ0KWyAgMTM1LjgyNTkyM10gMzZjNTcgaXMgMjE5NjcwMDAhDQpbICAx
MzUuODI3ODAyXSAzNmYyOCBpcyAyMTk2ODAwMCENClsgIDEzNS44Mjk2ODJdIDM2ZjI5IGlz
IDc4ZWI0MDAwIQ0KWyAgMTM1LjgzMTU3MF0gMzZmMmEgaXMgNzhlYjUwMDAhDQpbICAxMzUu
ODMzNDc5XSAzNmYyYiBpcyA3OGViNjAwMCENClsgIDEzNS44MzUzNDJdIDM5MzdjIGlzIDc4
ZWI3MDAwIQ0KWyAgMTM1LjgzNzI0OF0gMzkzN2QgaXMgN2EyM2MwMDAhDQpbICAxMzUuODM5
MTM5XSAzOTM3ZSBpcyA3YTIzZDAwMCENClsgIDEzNS44NDEwNTBdIDM5MzdmIGlzIDdhMjNl
MDAwIQ0KWyAgMTM1Ljg0MjkzNV0gMzc3NTggaXMgN2EyM2YwMDAhDQpbICAxMzUuODQ0OTAy
XSAzNzc1OSBpcyA3YTBkMDAwMCENClsgIDEzNS44NDY4MDVdIDM3NzVhIGlzIDdhMGQxMDAw
IQ0KWyAgMTM1Ljg1MzM4OV0gMzc3NWIgaXMgMjFkOGQwMDAhDQpbICAxMzUuODU1MjYzXSAz
ODNlYiBpcyAyMWQ4ZTAwMCENClsgIDEzNS44NTcxNzhdIDM3OGMwIGlzIDIxZDhmMDAwIQ0K
WyAgMTM1Ljg1OTA2NF0gMzc4YzEgaXMgMjFkOTAwMDAhDQpbICAxMzUuODYxNTIxXSAzNzhj
MiBpcyAyMWRhNzAwMCENClsgIDEzNS44NjM0NTNdIDM3OGMzIGlzIDIxZGE4MDAwIQ0KWyAg
MTM1Ljg2NTMzNF0gMzZjYzQgaXMgN2E1ZWMwMDAhDQpbICAxMzUuODY3MjY3XSAzNmNjNSBp
cyA3YTVlZDAwMCENClsgIDEzNS44NjkxNDldIDM2Y2M2IGlzIDdhNWVlMDAwIQ0KWyAgMTM1
Ljg3MTA1NV0gMzZjYzcgaXMgN2E1ZWYwMDAhDQpbICAxMzUuODczODAwXSAzN2I0OCBpcyAy
MWRhNjAwMCENClsgIDEzNS44ODMyODRdIDM3OTJmIGlzIDc4ZWIwMDAwIQ0KWyAgMTM1Ljg4
NTM5N10gMzdiMjAgaXMgNzhlYjEwMDAhDQpbICAxMzUuODg3MzY5XSAzN2IyMSBpcyA3OGVi
MjAwMCENClsgIDEzNS44ODkyODddIDM3YjIyIGlzIDc4ZWIzMDAwIQ0KWyAgMTM1Ljg5MTIz
NF0gMzdiMjMgaXMgMjFkOTkwMDAhDQpbICAxMzUuODkzMTcyXSAzNzc0YyBpcyAyMWQ5YTAw
MCENClsgIDEzNS44OTUxNDRdIDM3NzRkIGlzIDIxZDliMDAwIQ0KWyAgMTM1Ljg5NzA3NV0g
Mzc3NGUgaXMgMjFkOWMwMDAhDQpbICAxMzUuODk5MDA3XSAzNzc0ZiBpcyA3OGVjMDAwMCEN
ClsgIDEzNS45MDA5NjJdIDM2NGQ4IGlzIDc4ZWMxMDAwIQ0KWyAgMTM1LjkwMjkzMV0gMzY0
ZDkgaXMgNzhlYzIwMDAhDQpbICAxMzUuOTA1MzMxXSAzNjRkYSBpcyA3OGQ1MjAwMCENClsg
IDEzNS45MDczMThdIDM2NGRiIGlzIDc4ZDUzMDAwIQ0KWyAgMTM1LjkwOTI2N10gMzc1Yzgg
aXMgMjFkYjUwMDAhDQpbICAxMzUuOTExMjUwXSAzNzVjOSBpcyAyMWRiNjAwMCENClsgIDEz
NS45MTMxODddIDM3NWNhIGlzIDIxZGI3MDAwIQ0KWyAgMTM1LjkxNTE0NF0gMzc1Y2IgaXMg
MjFkYjgwMDAhDQpbICAxMzUuOTE3MTA3XSAzNzVhYyBpcyA3YTBkODAwMCENClsgIDEzNS45
MTkwMzRdIDM3NWFkIGlzIDdhMGQ5MDAwIQ0KWyAgMTM1LjkyMDk5MF0gMzc1YWUgaXMgN2Ew
ZGEwMDAhDQpbICAxMzUuOTIyOTIzXSAzNzVhZiBpcyA3YTBkYjAwMCENClsgIDEzNS45MjQ4
NTVdIDM3OWI0IGlzIDc4ZTgzMDAwIQ0KWyAgMTM1LjkyNjc4OF0gMzZkNzQgaXMgMjE5Mjkw
MDAhDQpbICAxMzUuOTI4NzcxXSAzNmQ3NSBpcyAyMTkyYTAwMCENClsgIDEzNS45MzA2OTVd
IDM2ZDc2IGlzIDIxOTJiMDAwIQ0KWyAgMTM1LjkzMjYxNF0gMzZkNzcgaXMgMjE5MmMwMDAh
DQpbICAxMzUuOTM0NTI1XSAzN2YzNCBpcyAyMTlmOTAwMCENClsgIDEzNS45MzY0MjZdIDM2
Y2ViIGlzIDIxOWZhMDAwIQ0KWyAgMTM1LjkzODMzN10gMzdlNzQgaXMgMjE5ZmIwMDAhDQpb
ICAxMzUuOTQwMjgyXSAzNzkyZSBpcyAyMTlmYzAwMCENClsgIDEzNS45NDIyMDhdIDM3OTJk
IGlzIDIxOTFkMDAwIQ0KWyAgMTM1Ljk0NDEwN10gMzc5MmMgaXMgMjE5MWUwMDAhDQpbICAx
MzUuOTQ1OTY5XSAzN2U3NSBpcyAyMTkwOTAwMCENClsgIDEzNS45NDc4MzldIDM3ZTc2IGlz
IDIxOTBhMDAwIQ0KWyAgMTM1Ljk0OTcxNF0gMzdlNzcgaXMgMjE5MGIwMDAhDQpbICAxMzUu
OTUxNTg1XSAzN2ZiOCBpcyAyMTkwYzAwMCENClsgIDEzNS45NTM0NjddIDM3ZmI5IGlzIDc5
MmQ4MDAwIQ0KWyAgMTM1Ljk1NTMyOF0gMzdmYmEgaXMgNzkyZDkwMDAhDQpbICAxMzUuOTU3
MjI1XSAzN2ZiYiBpcyA3OTJkYTAwMCENClsgIDEzNS45NTkwODhdIDM3OTYwIGlzIDc5MmRi
MDAwIQ0KWyAgMTM1Ljk2MDk1OV0gMzc5NjEgaXMgNzhlODAwMDAhDQpbICAxMzUuOTYyODI2
XSAzNzk2MiBpcyA3OGU4MTAwMCENClsgIDEzNS45NjQ2OThdIDM3OTYzIGlzIDc4ZTgyMDAw
IQ0KWyAgMTM1Ljk2NjU3N10gMzZjM2QgaXMgMjFlMDMwMDAhDQpbICAxMzUuOTY4NDk0XSAz
NmMzZSBpcyAyMWUwNDAwMCENClsgIDEzNS45NzAzOTVdIDM2YzNmIGlzIDdhMDQxMDAwIQ0K
WyAgMTM1Ljk3MjI4Nl0gMzgyOTggaXMgN2EwNDIwMDAhDQpbICAxMzUuOTc0MjI2XSAzODI5
OSBpcyA3YTA0MzAwMCENClsgIDEzNS45NzYxMjhdIDM4MjlhIGlzIDIxZTAxMDAwIQ0KWyAg
MTM1Ljk3ODA2MV0gMzgyOWIgaXMgMjFlMDIwMDAhDQpbICAxMzUuOTc5OTY1XSAzNzkwZiBp
cyAyMTkxZjAwMCENClsgIDEzNS45ODE5MTRdIDM3OTBlIGlzIDIxOTIwMDAwIQ0KWyAgMTM1
Ljk4Mzg2MF0gMzc5MGQgaXMgMjFkZGQwMDAhDQpbICAxMzUuOTg1Nzc0XSAzNzkwYyBpcyAy
MWRkZTAwMCENClsgIDEzNS45ODc2ODRdIDM3ZjM3IGlzIDIxZGRmMDAwIQ0KWyAgMTM1Ljk4
OTU3N10gMzdmMzYgaXMgMjFkZTAwMDAhDQpbICAxMzUuOTkxNDk5XSAzN2YzNSBpcyA3OGQ1
MDAwMCENClsgIDEzNS45OTM0MjhdIDM3YjQ5IGlzIDc4ZDUxMDAwIQ0KWyAgMTM2LjAwNzE4
OF0gMzZkYTkgaXMgN2ExZGEwMDAhDQpbICAxMzYuMDA5MTk0XSAzNmRhYSBpcyA3YTFkYjAw
MCENClsgIDEzNi4wMTEyMzVdIDM2ZGFiIGlzIDdhMDQwMDAwIQ0KWyAgMTM2LjAxMzQ2NF0g
MzdiMTcgaXMgN2ExZjQwMDAhDQpbICAxMzYuMDE1NDE5XSAzNzZiYyBpcyA3YTFmNTAwMCEN
ClsgIDEzNi4wMTczODVdIDM3NmJkIGlzIDdhMWY2MDAwIQ0KWyAgMTM2LjAxOTMzMF0gMzc2
YmUgaXMgN2ExZjcwMDAhDQpbICAxMzYuMDIxMjc4XSAzNzZiZiBpcyA3YTFmODAwMCENClsg
IDEzNi4wMjMyMTNdIDM3NjQ0IGlzIDdhMWY5MDAwIQ0KWyAgMTM2LjAyNTE2NV0gMzc2NDUg
aXMgN2ExZmEwMDAhDQpbICAxMzYuMDI3MDc4XSAzNzY0NiBpcyA3YTFmYjAwMCENClsgIDEz
Ni4wMjg5OTBdIDM3NjQ3IGlzIDdhMWU0MDAwIQ0KWyAgMTM2LjAzMDkxNl0gMzdjNmMgaXMg
N2ExZTUwMDAhDQpbICAxMzYuMDMyODM4XSAzN2M2ZCBpcyA3YTFlNjAwMCENClsgIDEzNi4w
MzQ3MzddIDM3YzZlIGlzIDdhMjM0MDAwIQ0KWyAgMTM2LjAzNjY0MV0gMzdjNmYgaXMgN2Ey
MzUwMDAhDQpbICAxMzYuMDM4NTQ4XSAzOGQ0YyBpcyA3YTIzNjAwMCENClsgIDEzNi4wNDA0
NDhdIDM4ZDRkIGlzIDdhMjM3MDAwIQ0KWyAgMTM2LjA0MjMwN10gMzhkNGUgaXMgN2EyMzgw
MDAhDQpbICAxMzYuMDQ0MTYyXSAzOGQ0ZiBpcyA3YTIzYTAwMCENClsgIDEzNi4wNDU5OThd
IDM2ZDdjIGlzIDdhMjNiMDAwIQ0KWyAgMTM2LjA0Nzg1OV0gMzdlZjQgaXMgN2ExZTcwMDAh
DQpbICAxMzYuMDQ5NzM2XSAzN2VmNSBpcyA3YTFlODAwMCENClsgIDEzNi4wNTE2MDNdIDM3
ZWY2IGlzIDdhMWU5MDAwIQ0KWyAgMTM2LjA1MzQ2OF0gMzdlZjcgaXMgN2ExZWEwMDAhDQpb
ICAxMzYuMDU1Mjk2XSAzN2QwYyBpcyA3YTFlYjAwMCENClsgIDEzNi4wNTcxNTRdIDM3ZDBk
IGlzIDdhMWQ0MDAwIQ0KWyAgMTM2LjA1ODk4OF0gMzdkMGUgaXMgN2ExZDUwMDAhDQpbICAx
MzYuMDYwODMxXSAzN2QwZiBpcyA3YTFkNjAwMCENClsgIDEzNi4wNjI2NzZdIDM3YjE0IGlz
IDdhMWQ3MDAwIQ0KWyAgMTM2LjA2NDUxMl0gMzdiMTUgaXMgN2ExZDgwMDAhDQpbICAxMzYu
MDY2MzQ1XSAzN2IxNiBpcyA3YTFkOTAwMCENClsgIDEzNi4wNzM2MThdIDM5M2E4IGlzIDc4
ZDVhMDAwIQ0KWyAgMTM2LjA3NTUzN10gMzkzYTkgaXMgNzhkNWIwMDAhDQpbICAxMzYuMDc3
Mzg0XSAzOTNhYSBpcyA3OGVjNDAwMCENClsgIDEzNi4wNzkyMDFdIDM2ZDdkIGlzIDc4ZDU3
MDAwIQ0KWyAgMTM2LjA4MTA1N10gMzZkN2UgaXMgNzhkNTgwMDAhDQpbICAxMzYuMDgyOTAx
XSAzNmQ3ZiBpcyA3OGQ1OTAwMCENClsgIDEzNi4wOTM2NzVdIDM5MjgwIGlzIDdhNzZmMDAw
IQ0KWyAgMTM2LjA5NTY1Nl0gMzc0ZmYgaXMgN2E3NzAwMDAhDQpbICAxMzYuMDk3NTY4XSAz
NzRmZSBpcyA3YTc3MTAwMCENClsgIDEzNi4wOTk0NjNdIDM3NGZkIGlzIDdhNzcyMDAwIQ0K
WyAgMTM2LjEwMTM1OV0gMzc0ZmMgaXMgN2E3NzMwMDAhDQpbICAxMzYuMTAzMjUyXSAzOTNj
MyBpcyA3YTBkYzAwMCENClsgIDEzNi4xMDUxNjBdIDM5M2MyIGlzIDdhMGRkMDAwIQ0KWyAg
MTM2LjEwNzA4NV0gMzkzYzEgaXMgN2EwZGUwMDAhDQpbICAxMzYuMTA4OTcxXSAzOTNjMCBp
cyA3YTBkZjAwMCENClsgIDEzNi4xMTA4ODhdIDM5M2FiIGlzIDdhMGUwMDAwIQ0KWyAgMTM2
LjExMjk3M10gMzkzODIgaXMgN2EwZTEwMDAhDQpbICAxMzYuMTE0OTExXSAzNzliNSBpcyA3
YTBlMjAwMCENClsgIDEzNi4xMTY4NjBdIDM3OWI2IGlzIDdhMGUzMDAwIQ0KWyAgMTM2LjEx
ODc3Ml0gMzc5YjcgaXMgMjFkOWQwMDAhDQpbICAxMzYuMTIwNzM0XSAzNmNiYyBpcyAyMWQ5
ZTAwMCENClsgIDEzNi4xMjI2NDBdIDM2Y2JkIGlzIDIxZDlmMDAwIQ0KWyAgMTM2LjEyNDU4
M10gMzkzODEgaXMgMjFkYTAwMDAhDQpbICAxMzYuMTI2NTA2XSAzOTM4MCBpcyAyMWRhMTAw
MCENClsgIDEzNi4xMjg0NThdIDM5MjgzIGlzIDIxZGEyMDAwIQ0KWyAgMTM2LjEzMDM5NF0g
MzkyODIgaXMgMjFkYTMwMDAhDQpbICAxMzYuMTMyMzIyXSAzOTI4MSBpcyAyMWRhNDAwMCEN
ClsgIDEzNi4xMzQyNDddIDM2Y2JlIGlzIDc5NmZjMDAwIQ0KWyAgMTM2LjEzNjIwM10gMzZj
YmYgaXMgNzk2ZmQwMDAhDQpbICAxMzYuMTM4MTQ1XSAzN2YxYyBpcyA3OTZmZTAwMCENClsg
IDEzNi4xNDAxMjFdIDM3ZjFkIGlzIDc5NmZmMDAwIQ0KWyAgMTM2LjE0MjA2Ml0gMzdmMWUg
aXMgNzk3MDAwMDAhDQpbICAxMzYuMTQzOTkzXSAzN2YxZiBpcyA3OTcwMTAwMCENClsgIDEz
Ni4xNDU5MjJdIDM3ODk0IGlzIDc5NzAyMDAwIQ0KWyAgMTM2LjE0Nzg0Nl0gMzc4OTUgaXMg
Nzk3MDMwMDAhDQpbICAxMzYuMTQ5NzQ1XSAzNzg5NiBpcyA3OGQ1NDAwMCENClsgIDEzNi4x
NTE2NDFdIDM3ODk3IGlzIDc4ZDU1MDAwIQ0KWyAgMTM2LjE1MzU1Ml0gMzc2ZjAgaXMgNzhk
NTYwMDAhDQpbICAxMzYuMTU5NzcxXSAzNzZmMSBpcyAyMTkxMDAwMCENClsgIDEzNi4xNjE3
ODNdIDM5MzgzIGlzIDIxOTExMDAwIQ0KWyAgMTM2LjE2MzcwMl0gMzZlOTAgaXMgMjE5MTIw
MDAhDQpbICAxMzYuMTY1NjIyXSAzNmU5MSBpcyAyMTkxMzAwMCENClsgIDEzNi4xNjc1MjJd
IDM2ZTkyIGlzIDIxOTE0MDAwIQ0KWyAgMTM2LjE2OTQwMV0gMzZlOTMgaXMgNzkzMGMwMDAh
DQpbICAxMzYuMTcxMjg1XSAzNmQ1NCBpcyA3OTMwZDAwMCENClsgIDEzNi4xNzMxNjhdIDM2
ZDU1IGlzIDc5MzBlMDAwIQ0KWyAgMTM2LjE3NTA4NV0gMzZkNTYgaXMgNzkzMGYwMDAhDQpb
ICAxMzYuMTc2OTY5XSAzNmQ1NyBpcyA3OTMxMDAwMCENClsgIDEzNi4xNzkwNTBdIDM3YWY0
IGlzIDc5MzExMDAwIQ0KWyAgMTM2LjE4MDk1Ml0gMzdhZjUgaXMgNzkzMTIwMDAhDQpbICAx
MzYuMTgyODM5XSAzN2FmNiBpcyA3OTMxMzAwMCENClsgIDEzNi4xODQ3MDhdIDM3YWY3IGlz
IDc5MmNjMDAwIQ0KWyAgMTM2LjE4NjU3Ml0gMzZmMjAgaXMgNzkyY2QwMDAhDQpbICAxMzYu
MTg4NDU2XSAzNmYyMSBpcyA3OTJjZTAwMCENClsgIDEzNi4xOTAzMzhdIDM2ZjIyIGlzIDc5
MmNmMDAwIQ0KWyAgMTM2LjE5MjE5MV0gMzZmMjMgaXMgNzkyZDAwMDAhDQpbICAxMzYuMTk0
MDc4XSAzNzg2OCBpcyA3OTJkMTAwMCENClsgIDEzNi4xOTU5NDRdIDM3ODY5IGlzIDc5MmQy
MDAwIQ0KWyAgMTM2LjE5NzgzNF0gMzc4NmEgaXMgNzkyZDMwMDAhDQpbICAxMzYuMTk5Njc2
XSAzNzg2YiBpcyAyMWRmNTAwMCENClsgIDEzNi4yMDE1NTFdIDM2ZDY4IGlzIDIxZGY2MDAw
IQ0KWyAgMTM2LjIwMzQ0N10gMzZkNjkgaXMgMjFkZjcwMDAhDQpbICAxMzYuMjA1MzA3XSAz
NmQ2YSBpcyAyMWRmODAwMCENClsgIDEzNi4yMDcxODRdIDM2ZDZiIGlzIDIxZGY5MDAwIQ0K
WyAgMTM2LjIwOTAzM10gMzc2MjggaXMgMjFkZmEwMDAhDQpbICAxMzYuMjEwOTE0XSAzNzYy
OSBpcyAyMWRmYjAwMCENClsgIDEzNi4yMTI3NzBdIDM3NjJhIGlzIDIxZGZjMDAwIQ0KWyAg
MTM2LjIxNDYzMF0gMzc2MmIgaXMgN2E3NmMwMDAhDQpbICAxMzYuMjE2NTAzXSAzN2ViMCBp
cyA3YTc2ZDAwMCENClsgIDEzNi4yMTgzNzRdIDM3ZWIxIGlzIDdhNzZlMDAwIQ0KWyAgMTM2
LjIyMzQ4N10gMzdlYjIgaXMgNzhlOGEwMDAhDQpbICAxMzYuMjI1NDA4XSAzN2ViMyBpcyA3
OGU4YjAwMCENClsgIDEzNi4yMjcyNzJdIDM5MTE0IGlzIDIxOTJkMDAwIQ0KWyAgMTM2LjIy
OTE3NF0gMzkxMTUgaXMgMjE5MmUwMDAhDQpbICAxMzYuMjMxMDgzXSAzOTExNiBpcyAyMTky
ZjAwMCENClsgIDEzNi4yMzI5NjldIDM5MTE3IGlzIDIxOTMwMDAwIQ0KWyAgMTM2LjIzNDg0
NF0gMzZkZDAgaXMgMjE5MzEwMDAhDQpbICAxMzYuMjM2NzU1XSAzNmRkMSBpcyAyMTkzMjAw
MCENClsgIDEzNi4yMzg2MjldIDM2ZGQyIGlzIDIxOTMzMDAwIQ0KWyAgMTM2LjI0MTA5NV0g
MzZjN2UgaXMgMjFkYmQwMDAhDQpbICAxMzYuMjQyOTcyXSAzNmM3ZCBpcyAyMWRiZTAwMCEN
ClsgIDEzNi4yNDQ4ODZdIDM2YzdjIGlzIDIxZGJmMDAwIQ0KWyAgMTM2LjI0Njc3OV0gMzZk
ZDMgaXMgMjFkYzAwMDAhDQpbICAxMzYuMjQ4OTE4XSAzNjU1MiBpcyAyMWRjNDAwMCENClsg
IDEzNi4yNTA4MjhdIDM3NmYyIGlzIDIxZDg1MDAwIQ0KWyAgMTM2LjI1MjczNF0gMzc2ZjMg
aXMgMjFkOGEwMDAhDQpbICAxMzYuMjU0NjkzXSAzNzQxMCBpcyAyMWQ4YjAwMCENClsgIDEz
Ni4yNTY1OTddIDM3NDExIGlzIDIxZDhjMDAwIQ0KWyAgMTM2LjI1ODQ4M10gMzc0MTIgaXMg
NzhlODQwMDAhDQpbICAxMzYuMjYwMzg3XSAzNzQxMyBpcyA3OGU4NTAwMCENClsgIDEzNi4y
NjIyOTJdIDM2NTUxIGlzIDc4ZTg2MDAwIQ0KWyAgMTM2LjI2NDE5M10gMzY1NTAgaXMgNzhl
ODcwMDAhDQpbICAxMzYuMjY2MDYzXSAzNjUyZiBpcyA3OGU4ODAwMCENClsgIDEzNi4yNjc5
NzNdIDM2NTJlIGlzIDc4ZTg5MDAwIQ0KWyAgMTM2LjI2OTg1MV0gMzY1MmQgaXMgMjFkYzEw
MDAhDQpbICAxMzYuMjcxNzM5XSAzNjUyYyBpcyAyMWRjMjAwMCENClsgIDEzNi4yNzM2MzNd
IDM2YzdmIGlzIDIxZGMzMDAwIQ0KWyAgMTM2LjI3NjQ2NF0gMzZmY2IgaXMgMjFkZDcwMDAh
DQpbICAxMzYuMjc4NDM4XSAzNmNlOCBpcyAyMWRkODAwMCENClsgIDEzNi4yODAzNTVdIDM2
Y2U5IGlzIDIxZGQ5MDAwIQ0KWyAgMTM2LjI4MjI2Ml0gMzZjZWEgaXMgMjFkZGEwMDAhDQpb
ICAxMzYuMjg0MTU3XSAzNzZkZSBpcyAyMWRkYjAwMCENClsgIDEzNi4yODYwNTddIDM3NmRm
IGlzIDIxZGRjMDAwIQ0KWyAgMTM2LjI4NzkzNl0gMzc1ZjQgaXMgMjE5ODUwMDAhDQpbICAx
MzYuMjg5ODEzXSAzNzVmNSBpcyAyMTk4NjAwMCENClsgIDEzNi4yOTE2ODJdIDM3NWY2IGlz
IDIxOTg3MDAwIQ0KWyAgMTM2LjI5MzU1MV0gMzc1ZjcgaXMgMjE5ODgwMDAhDQpbICAxMzYu
Mjk1NDEwXSAzOGMyOCBpcyAyMTk4OTAwMCENClsgIDEzNi4yOTcyNzJdIDM2ZmM4IGlzIDIx
OThhMDAwIQ0KWyAgMTM2LjI5OTE0Ml0gMzZmYzkgaXMgMjE5OGIwMDAhDQpbICAxMzYuMzAx
MDEyXSAzNmZjYSBpcyAyMTk4YzAwMCENClsgIDEzNi4zMDMwOTVdIDM4YzI5IGlzIDIxYTA0
MDAwIQ0KWyAgMTM2LjMwNDk4MF0gMzhjMmEgaXMgNzk0MzQwMDAhDQpbICAxMzYuMzA2ODg0
XSAzOGMyYiBpcyA3OTQzNTAwMCENClsgIDEzNi4zMDg3MjldIDM5Mjc4IGlzIDc5NDM2MDAw
IQ0KWyAgMTM2LjMxMDYxMF0gMzkyNzkgaXMgNzk0MzcwMDAhDQpbICAxMzYuMzEyNDQ3XSAz
OTI3YSBpcyA3OTQzODAwMCENClsgIDEzNi4zMTQzNTVdIDM5MjdiIGlzIDc5NDM5MDAwIQ0K
WyAgMTM2LjMxNjIxNF0gMzdmZTQgaXMgNzk0M2EwMDAhDQpbICAxMzYuMzE4MDgyXSAzN2Zl
NSBpcyA3OTQzYjAwMCENClsgIDEzNi4zMTk5MzJdIDM3ZmU2IGlzIDIxZGQ1MDAwIQ0KWyAg
MTM2LjMyMTc5OV0gMzdmZTcgaXMgMjFkZDYwMDAhDQpbICAxMzYuMzIzNjcxXSAzNmY1MCBp
cyAyMTlmZDAwMCENClsgIDEzNi4zMjU1MzddIDM2ZjUxIGlzIDIxOWZlMDAwIQ0KWyAgMTM2
LjMyNzQzNF0gMzZmNTIgaXMgMjE5ZmYwMDAhDQpbICAxMzYuMzI5MzA2XSAzNmY1MyBpcyAy
MWEwMDAwMCENClsgIDEzNi4zMzExNzFdIDM2Zjg0IGlzIDIxYTAxMDAwIQ0KWyAgMTM2LjMz
MzA0NV0gMzZmODUgaXMgMjFhMDIwMDAhDQpbICAxMzYuMzM0OTEwXSAzNmY4NiBpcyAyMWEw
MzAwMCENClsgIDEzNi4zNDg3NzddIDM2Zjg3IGlzIDc5NDA3MDAwIQ0KWyAgMTM2LjM1MTA5
N10gMzkyZWMgaXMgNzk0MDkwMDAhDQpbICAxMzYuMzY4NTIyXSAzOTJlZCBpcyA3YTVmODAw
MCENClsgIDEzNi4zNzA0NjNdIDM5MmVlIGlzIDdhNWY5MDAwIQ0KWyAgMTM2LjM3MjM0MF0g
MzkyZWYgaXMgN2E1ZmEwMDAhDQpbICAxMzYuMzc0MjcwXSAzN2JkNCBpcyA3YTVmYjAwMCEN
ClsgIDEzNi4zODA5MzBdIDM2NTUzIGlzIDdhNWY0MDAwIQ0KWyAgMTM2LjM4Mjg1N10gMzdi
ZDUgaXMgN2E1ZjUwMDAhDQpbICAxMzYuMzg0Nzg1XSAzN2JkNiBpcyA3YTVmNjAwMCENClsg
IDEzNi4zODY3MzJdIDM3YmQ3IGlzIDdhNWY3MDAwIQ0KWyAgMTM2LjM5ODE1Ml0gMzhjNjgg
aXMgN2EyMjIwMDAhDQpbICAxMzYuNDAwMjIwXSAzOGM2OSBpcyA3YTIyMTAwMCENClsgIDEz
Ni40MDIxNTJdIDM4YzZhIGlzIDdhMjIwMDAwIQ0KWyAgMTM2LjQwNDA4Nl0gMzhjNmIgaXMg
N2EyMWYwMDAhDQpbICAxMzYuNDA1OTgwXSAzN2U5OCBpcyA3YTIxZTAwMCENClsgIDEzNi40
MDc5MDddIDM3ZTk5IGlzIDdhMjFkMDAwIQ0KWyAgMTM2LjQwOTgwMF0gMzdlOWEgaXMgN2Ey
MWMwMDAhDQpbICAxMzYuNDExNzAxXSAzN2U5YiBpcyAyMWRmNDAwMCENClsgIDEzNi40MTM2
MDNdIDM3ZGZjIGlzIDIxZGYzMDAwIQ0KWyAgMTM2LjQxNTUwOF0gMzdkZmQgaXMgMjFkZjIw
MDAhDQpbICAxMzYuNDE3NDA4XSAzN2RmZSBpcyAyMWRmMTAwMCENClsgIDEzNi40MTk0NzRd
IDM4Mzg0IGlzIDdhMjI2MDAwIQ0KWyAgMTM2LjQyMTQwOV0gMzgzODUgaXMgN2EyMjUwMDAh
DQpbICAxMzYuNDIzMjk3XSAzODM4NiBpcyA3YTIyNDAwMCENClsgIDEzNi40MjUxODBdIDM4
Mzg3IGlzIDdhMjIzMDAwIQ0KWyAgMTM2LjQyNzE1N10gMzdkZmYgaXMgNzkzZmMwMDAhDQpb
ICAxMzYuNDMyMzAwXSAzNzhmNSBpcyA3YTIyYTAwMCENClsgIDEzNi40MzQ2NDldIDM3OGY0
IGlzIDIxZGViMDAwIQ0KWyAgMTM2LjQzNzA0Nl0gMzc4ZjYgaXMgMjFkZWEwMDAhDQpbICAx
MzYuNDQ0NjcxXSAzNzhmNyBpcyA3YTYwOTAwMCENClsgIDEzNi40NDcwODBdIDM2NGY0IGlz
IDdhNjBiMDAwIQ0KWyAgMTM2LjQ0OTA1NF0gMzY0ZjUgaXMgN2E2MGEwMDAhDQpbICAxMzYu
NDUxMzg4XSAzNjRmNiBpcyAyMWRlOTAwMCENClsgIDEzNi40NjE1MzRdIDM2NGY3IGlzIDc5
NmVjMDAwIQ0KWyAgMTM2LjQ3NzkwM10gMzdlNDAgaXMgNzk2ZWQwMDAhDQpbICAxMzYuNDk3
MDU3XSAzN2U0MSBpcyA3OTZlZTAwMCENClsgIDEzNi41MTQyODBdIDM2ZjM0IGlzIDIxZGU3
MDAwIQ0KWyAgMTM2LjUyODc5MV0gMzZmMzUgaXMgMjFkZTUwMDAhDQpbICAxMzYuNTMxMzU4
XSAzN2U0MiBpcyA3OTZmMjAwMCENClsgIDEzNi41MzMzNTldIDM2ZjM2IGlzIDc5NmYxMDAw
IQ0KWyAgMTM2LjUzNTM4OF0gMzZmMzcgaXMgNzk2ZjAwMDAhDQpbICAxMzYuNTM3NDA1XSAz
NmRjMCBpcyA3OTZlZjAwMCENClsgIDEzNi41Mzk3ODddIDM2ZGMxIGlzIDc5NmY5MDAwIQ0K
WyAgMTM2LjU1MTU5Nl0gMzZkYzIgaXMgNzk2ZjMwMDAhDQpbICAxMzYuNTY0ODYzXSAzNmRj
MyBpcyA3OTQwYTAwMCENClsgIDEzNi41Nzk5ODJdIDM3ZTQzIGlzIDdhMjE2MDAwIQ0KWyAg
MTM2LjU5Mjk5NV0gMzZkNjQgaXMgN2EyMjgwMDAhDQpbICAxMzYuNjA3NTU3XSAzNmQ2NSBp
cyAyMWRlZTAwMCENClsgIDEzNi42MTAxMTNdIDM2ZGNjIGlzIDIxZGVkMDAwIQ0KWyAgMTM2
LjYxOTE0MF0gMzZkY2QgaXMgN2EyMTQwMDAhDQpbICAxMzYuNjQyNjM1XSAzNmRjZSBpcyA3
OTNmZjAwMCENClsgIDEzNi42NzM5MzBdIDM2ZGNmIGlzIDc5NmZiMDAwIQ0KWyAgMTM2LjY4
Mzk4OV0gMzY0NGMgaXMgNzk2ZjYwMDAhDQpbICAxMzYuNjg2MTI1XSAzNmQ2NyBpcyA3OTZm
NzAwMCENClsgIDEzNi43MDM1MTZdIDM2NDRkIGlzIDdhNjAwMDAwIQ0KWyAgMTM2LjcxODE0
OV0gMzY0NGUgaXMgNzk2ZjQwMDAhDQpbICAxMzYuNzIxMDgyXSAzNjQ0ZiBpcyA3YTYwNzAw
MCENClsgIDEzNi43MjM3MDFdIDM2ZjVjIGlzIDdhNjA2MDAwIQ0KWyAgMTM2Ljc0NzI5MV0g
Mzc3YTggaXMgN2E2MDQwMDAhDQpbICAxMzYuNzQ5NDQyXSAzNzdhOSBpcyA3YTYwMzAwMCEN
ClsgIDEzNi43NTE2MTddIDM3N2FhIGlzIDdhNjAyMDAwIQ0KWyAgMTM2Ljc1Mzc1Nl0gMzc3
YWIgaXMgN2E2MDEwMDAhDQpbICAxMzYuNzU2MjcwXSAzNmY1ZCBpcyAyMTkzOTAwMCENClsg
IDEzNi43NjYyNzJdIDM2NDM4IGlzIDIxZGYwMDAwIQ0KWyAgMTM2Ljc2ODYwMl0gMzY0Mzkg
aXMgMjE5OTIwMDAhDQpbICAxMzYuNzcwNzQ2XSAzNjQzYSBpcyA3YTFlYzAwMCENClsgIDEz
Ni43NzI4ODldIDM2NDNiIGlzIDdhMGU1MDAwIQ0KWyAgMTM2Ljc3NTA0NF0gMzc5ZTggaXMg
MjFkODgwMDAhDQpbICAxMzYuNzc3MjA2XSAzNzllOSBpcyAyMWQ4NjAwMCENClsgIDEzNi43
NzkzMjVdIDM3OWVhIGlzIDIxZDg3MDAwIQ0KWyAgMTM2Ljc4MTQzM10gMzc5ZWIgaXMgN2Ex
ZWQwMDAhDQpbICAxMzYuNzgzNTUyXSAzN2MzMCBpcyA3OTQwMjAwMCENClsgIDEzNi43ODU2
OTldIDM3YzMxIGlzIDdhMGNmMDAwIQ0KWyAgMTM2Ljc4Nzg0OV0gMzdjMzIgaXMgN2E2MDUw
MDAhDQpbICAxMzYuNzkwMTM1XSAzN2MzMyBpcyA3OTJlOTAwMCENClsgIDEzNi43OTIzMTRd
IDM5MTRjIGlzIDc5MmVhMDAwIQ0KWyAgMTM2Ljc5NDUyMF0gMzkxNGQgaXMgNzkyZWIwMDAh
DQpbICAxMzYuNzk2NjQzXSAzOTE0ZSBpcyA3YTVmYzAwMCENClsgIDEzNi43OTg4MDVdIDM5
MTRmIGlzIDdhNWZkMDAwIQ0KWyAgMTM2LjgwMDkwN10gMzZmNjAgaXMgN2E1ZmUwMDAhDQpb
ICAxMzYuODAzNzIzXSAzNmY2MiBpcyAyMWRjZTAwMCENClsgIDEzNi44MDU4ODldIDM2ZjYx
IGlzIDIxZGNmMDAwIQ0KWyAgMTM2LjgwNzk3MF0gMzZmNWUgaXMgMjFkZDAwMDAhDQpbICAx
MzYuODEwMDg1XSAzNmY1ZiBpcyAyMWRkMTAwMCENClsgIDEzNi44MTIxNTRdIDM2ZjEwIGlz
IDIxZGQyMDAwIQ0KWyAgMTM2LjgxNDMxMF0gMzZmMTEgaXMgMjFkZDMwMDAhDQpbICAxMzYu
ODE2MzUzXSAzNmYxMiBpcyAyMWRkNDAwMCENClsgIDEzNi44MTgzOTRdIDM2ZjEzIGlzIDIx
OTM1MDAwIQ0KWyAgMTM2LjgyMDQwNl0gMzZkZmMgaXMgMjE5MzYwMDAhDQpbICAxMzYuODIy
NDE5XSAzNmRmZCBpcyAyMTkzNzAwMCENClsgIDEzNi44MjQ2MzJdIDM2ZGZlIGlzIDIxOTM4
MDAwIQ0KWyAgMTM2LjgyNjYyOV0gMzZkZmYgaXMgMjE5NDAwMDAhDQpbICAxMzYuODI4NjMy
XSAzNzZkYyBpcyAyMTk0MTAwMCENClsgIDEzNi44MzA2NDddIDM3NmRkIGlzIDIxOTQyMDAw
IQ0KWyAgMTM2LjgzMjU4N10gMzZmNjMgaXMgMjE5NDMwMDAhDQpbICAxMzYuODM0NTQ2XSAz
NjUwOCBpcyAyMTk0NDAwMCENClsgIDEzNi44MzY1MDJdIDM2NTA5IGlzIDc5MmRjMDAwIQ0K
WyAgMTM2LjgzODQ0OV0gMzY1MGEgaXMgNzkyZGQwMDAhDQpbICAxMzYuODQwNDA5XSAzNjUw
YiBpcyA3OTJkZTAwMCENClsgIDEzNi44NDIyODZdIDM4M2FjIGlzIDc5MmRmMDAwIQ0KWyAg
MTM2Ljg0NDIxNl0gMzgzYWQgaXMgNzkyZTAwMDAhDQpbICAxMzYuODQ2MTEyXSAzODNhZSBp
cyA3OTJlMTAwMCENClsgIDEzNi44NDgwMDJdIDM4M2FmIGlzIDc5MmUyMDAwIQ0KWyAgMTM2
Ljg0OTgyN10gMzkxOTggaXMgNzkyZTMwMDAhDQpbICAxMzYuODUxNjc0XSAzOTE5OSBpcyA3
OTJlNDAwMCENClsgIDEzNi44NTM1MDddIDM5MTlhIGlzIDc5MmU1MDAwIQ0KWyAgMTM2Ljg1
NTMwMV0gMzkxOWIgaXMgNzkyZTYwMDAhDQpbICAxMzYuODU3MTAzXSAzOGMyNCBpcyA3OTJl
NzAwMCENClsgIDEzNi44NTg4ODRdIDM4YzI1IGlzIDc5MmU4MDAwIQ0KWyAgMTM2Ljg3MTQy
OF0gMzhjMjYgaXMgMjE5ZWIwMDAhDQpbICAxMzYuODg1NTcwXSAzOGMyNyBpcyAyMWRjYTAw
MCENClsgIDEzNi44ODc0MzBdIDM3ZjRlIGlzIDIxZGNiMDAwIQ0KWyAgMTM2Ljg4OTI0N10g
MzdmNGYgaXMgMjFkY2MwMDAhDQpbICAxMzYuODkxMDUzXSAzNmViYyBpcyAyMWRjZDAwMCEN
ClsgIDEzNi44OTMyNTVdIDM2ZWJkIGlzIDIxOTViMDAwIQ0KWyAgMTM2Ljg5ODY3MF0gMzZl
YmUgaXMgMjE5ZWYwMDAhDQpbICAxMzYuOTAwNjQwXSAzN2RhYyBpcyAyMTlmMDAwMCENClsg
IDEzNi45MDI0NzVdIDM3ZGFkIGlzIDIxOWYxMDAwIQ0KWyAgMTM2LjkwNDMxN10gMzdkYWUg
aXMgMjE5ZjIwMDAhDQpbICAxMzYuOTA2MTQ2XSAzN2RhZiBpcyAyMTlmMzAwMCENClsgIDEz
Ni45MDc5NjZdIDM3OWMwIGlzIDIxOWY0MDAwIQ0KWyAgMTM2LjkwOTc5NV0gMzc5YzEgaXMg
MjFkYzUwMDAhDQpbICAxMzYuOTExNzI4XSAzNzljMiBpcyAyMWRjNjAwMCENClsgIDEzNi45
MTM1NjRdIDM3OWMzIGlzIDIxZGM3MDAwIQ0KWyAgMTM2LjkxNTM4NV0gMzgzZTAgaXMgMjFk
YzgwMDAhDQpbICAxMzYuOTE3MjIzXSAzODNlMSBpcyAyMWRjOTAwMCENClsgIDEzNi45MTkx
NzRdIDM4M2UyIGlzIDIxOWU1MDAwIQ0KWyAgMTM2LjkyMTEwNl0gMzgzZTMgaXMgMjE5ZTYw
MDAhDQpbICAxMzYuOTIyOTM0XSAzN2Y0YyBpcyAyMTllNzAwMCENClsgIDEzNi45MjQ3NzVd
IDM3ZjRkIGlzIDIxOWU4MDAwIQ0KWyAgMTM2LjkyNjYzNF0gMzdlMTkgaXMgMjE5ZTkwMDAh
DQpbICAxMzYuOTI4NDcwXSAzN2UxYSBpcyAyMTllZTAwMCENClsgIDEzNi45MzEyNDZdIDM3
YThkIGlzIDIxOTU1MDAwIQ0KWyAgMTM2LjkzMzExMV0gMzdhOGUgaXMgMjE5NTYwMDAhDQpb
ICAxMzYuOTM1MDExXSAzN2E4ZiBpcyAyMTk1NzAwMCENClsgIDEzNi45MzY4NjRdIDM2NTI0
IGlzIDIxOTU4MDAwIQ0KWyAgMTM2LjkzODcyMV0gMzY1MjUgaXMgMjE5NTkwMDAhDQpbICAx
MzYuOTQwNTgxXSAzNjUyNiBpcyAyMTk1YTAwMCENClsgIDEzNi45NDI0MjhdIDM2NTI3IGlz
IDIxOTVkMDAwIQ0KWyAgMTM2Ljk0NDMwMF0gMzZlMzggaXMgMjE5NWUwMDAhDQpbICAxMzYu
OTQ2MTUwXSAzNmUzOSBpcyAyMTk1ZjAwMCENClsgIDEzNi45NDgwMDJdIDM2ZTNhIGlzIDIx
OTYwMDAwIQ0KWyAgMTM2Ljk0OTgxNl0gMzZlM2IgaXMgMjE5NjEwMDAhDQpbICAxMzYuOTUx
NjQwXSAzNmViZiBpcyAyMTk1MzAwMCENClsgIDEzNi45NTM0NjRdIDM3YThjIGlzIDIxOTU0
MDAwIQ0KWyAgMTM2Ljk1NTQ1OF0gMzZlYjcgaXMgMjE5OWQwMDAhDQpbICAxMzYuOTU3Mjk4
XSAzN2UxOCBpcyAyMTk5ZTAwMCENClsgIDEzNi45NTkxMTVdIDM3ZWU0IGlzIDIxOTlmMDAw
IQ0KWyAgMTM2Ljk2MDk0NV0gMzdlZTUgaXMgMjE5YTAwMDAhDQpbICAxMzYuOTYyNzQ5XSAz
N2VlNiBpcyAyMTlhMTAwMCENClsgIDEzNi45NjQ1NzhdIDM3ZWU3IGlzIDIxOWEyMDAwIQ0K
WyAgMTM2Ljk2NjM3OF0gMzgyYTQgaXMgMjE5YTMwMDAhDQpbICAxMzYuOTY4MjA3XSAzODJh
NSBpcyAyMTlhNDAwMCENClsgIDEzNi45NzAwMDddIDM2ZTE0IGlzIDIxOTYyMDAwIQ0KWyAg
MTM2Ljk3MTgyOV0gMzZlMTUgaXMgMjE5NjMwMDAhDQpbICAxMzYuOTczNjY0XSAzNmUxNiBp
cyAyMTk2NDAwMCENClsgIDEzNi45NzU0NTNdIDM2ZTE3IGlzIDIxOTk1MDAwIQ0KWyAgMTM2
Ljk3NzI3Nl0gMzZlYzggaXMgMjE5OTYwMDAhDQpbICAxMzYuOTc5MTAxXSAzNmVjOSBpcyAy
MTk5NzAwMCENClsgIDEzNi45ODA5MjddIDM2ZWNhIGlzIDIxOTk4MDAwIQ0KWyAgMTM2Ljk4
MjcwM10gMzZlY2IgaXMgMjE5OTkwMDAhDQpbICAxMzYuOTg0NTA2XSAzNmViNCBpcyAyMTk5
YTAwMCENClsgIDEzNi45ODYyNzJdIDM2ZWI1IGlzIDIxOTliMDAwIQ0KWyAgMTM2Ljk4ODA0
OV0gMzZlYjYgaXMgMjE5OWMwMDAhDQpbICAxMzYuOTkxMDAxXSAzODJhNiBpcyAyMTk0ODAw
MCENClsgIDEzNi45OTI3NzhdIDM4MmE3IGlzIDIxOTQ5MDAwIQ0KWyAgMTM2Ljk5NDU2Nl0g
MzY0NzQgaXMgMjE5NGEwMDAhDQpbICAxMzYuOTk2MzM4XSAzNjQ3NSBpcyAyMTk0YjAwMCEN
ClsgIDEzNi45OTgxMzhdIDM2NDc2IGlzIDIxOTRjMDAwIQ0KWyAgMTM2Ljk5OTg5N10gMzY0
NzcgaXMgMjE5NGQwMDAhDQpbICAxMzcuMDAxNjg2XSAzNzdlOCBpcyAyMTk0ZTAwMCENClsg
IDEzNy4wMDM0ODFdIDM3N2U5IGlzIDIxOTRmMDAwIQ0KWyAgMTM3LjAwNTI3OV0gMzc3ZWEg
aXMgMjE5NTAwMDAhDQpbICAxMzcuMDA3MDczXSAzNzdlYiBpcyAyMTk1MTAwMCENClsgIDEz
Ny4wMDg4NThdIDM3NmMwIGlzIDIxOTUyMDAwIQ0KWyAgMTM3LjAxMTA3N10gMzgzOTQgaXMg
N2E1ZDUwMDAhDQpbICAxMzcuMDEyODc5XSAzODM5NSBpcyA3YTVkNjAwMCENClsgIDEzNy4w
MTQ2OTFdIDM4Mzk2IGlzIDdhNWQ3MDAwIQ0KWyAgMTM3LjAxNjQ2MV0gMzgzOTcgaXMgN2E1
ZDgwMDAhDQpbICAxMzcuMDE4MjUwXSAzNjQyNCBpcyA3YTVkOTAwMCENClsgIDEzNy4wMjAw
MjBdIDM2NDI1IGlzIDdhNWRhMDAwIQ0KWyAgMTM3LjAyMTgwOV0gMzY0MjYgaXMgN2E1ZGIw
MDAhDQpbICAxMzcuMDIzNjE1XSAzNjQyNyBpcyA3YTVkYzAwMCENClsgIDEzNy4wMjUzODdd
IDM3NzM4IGlzIDdhNWRkMDAwIQ0KWyAgMTM3LjAyNzIwM10gMzc3MzkgaXMgN2E1ZGUwMDAh
DQpbICAxMzcuMDI4OTc0XSAzNzczYSBpcyA3OTQyYjAwMCENClsgIDEzNy4wMzA3OTFdIDM3
NzNiIGlzIDdhNWNjMDAwIQ0KWyAgMTM3LjAzMjYwMl0gMzY0YjQgaXMgN2E1Y2QwMDAhDQpb
ICAxMzcuMDM0NDUxXSAzNjRiNSBpcyA3YTVjZTAwMCENClsgIDEzNy4wMzYyNjddIDM2NGI2
IGlzIDdhNWNmMDAwIQ0KWyAgMTM3LjAzODA5Nl0gMzY0YjcgaXMgN2E1ZDAwMDAhDQpbICAx
MzcuMDM5OTI4XSAzNzYwOCBpcyA3YTVkMTAwMCENClsgIDEzNy4wNDE3NzRdIDM3NjA5IGlz
IDdhNWQyMDAwIQ0KWyAgMTM3LjA0MzY0M10gMzc2MGEgaXMgN2E1ZDMwMDAhDQpbICAxMzcu
MDQ1NDg0XSAzNzYwYiBpcyA3YTVkNDAwMCENClsgIDEzNy4wNDczNTJdIDM3NTI0IGlzIDc5
NDBmMDAwIQ0KWyAgMTM3LjA0OTIwNF0gMzc1MjUgaXMgNzk0MGUwMDAhDQpbICAxMzcuMDUx
MDgzXSAzNzUyNiBpcyA3OTQwZDAwMCENClsgIDEzNy4wNTI5MjJdIDM3NTI3IGlzIDc5NDBj
MDAwIQ0KWyAgMTM3LjA1NDc3NV0gMzkyZjQgaXMgNzhlYWIwMDAhDQpbICAxMzcuMDU2Njc3
XSAzOTJmNSBpcyA3OGVhYTAwMCENClsgIDEzNy4wNTg1NzBdIDM5MmY2IGlzIDc4ZWE5MDAw
IQ0KWyAgMTM3LjA2MDQ0MF0gMzkyZjcgaXMgNzhlYTgwMDAhDQpbICAxMzcuMDYyMjg1XSAz
OTJlMCBpcyA3OGVhNzAwMCENClsgIDEzNy4wNjQxNTldIDM5MmUxIGlzIDc4ZWE2MDAwIQ0K
WyAgMTM3LjA2NjAxMV0gMzkyZTIgaXMgNzhlYTUwMDAhDQpbICAxMzcuMDY3ODc3XSAzOTJl
MyBpcyA3OTQxYTAwMCENClsgIDEzNy4wNjk2ODldIDM4YzgwIGlzIDc5NDE5MDAwIQ0KWyAg
MTM3LjA3MTUzNV0gMzhjODEgaXMgNzk0MTgwMDAhDQpbICAxMzcuMDczNDAzXSAzOGM4MiBp
cyA3OTQxNzAwMCENClsgIDEzNy4wNzUyNDldIDM4YzgzIGlzIDc5NDE2MDAwIQ0KWyAgMTM3
LjA3NzEwNV0gMzZmNDQgaXMgNzk0MTUwMDAhDQpbICAxMzcuMDc4OTUwXSAzNmY0NSBpcyA3
OTQxNDAwMCENClsgIDEzNy4wODA4MjhdIDM2ZjQ2IGlzIDc5NDEzMDAwIQ0KWyAgMTM3LjA4
MjY3OV0gMzZmNDcgaXMgNzk0MTIwMDAhDQpbICAxMzcuMDg0NTQwXSAzOGNmMCBpcyA3OTQx
MTAwMCENClsgIDEzNy4wODYzOTFdIDM4Y2YxIGlzIDc5NDEwMDAwIQ0KWyAgMTM3LjA4ODIz
OF0gMzhjZjMgaXMgNzhlYTIwMDAhDQpbICAxMzcuMDkwMDk2XSAzNzhjOCBpcyA3OGVhMzAw
MCENClsgIDEzNy4wOTE5MzBdIDM3OGM5IGlzIDc4ZWE0MDAwIQ0KWyAgMTM3LjA5Mzc5Ml0g
Mzc4Y2EgaXMgNzk0MjEwMDAhDQpbICAxMzcuMDk1NjUxXSAzNzhjYiBpcyA3OTQyMDAwMCEN
ClsgIDEzNy4wOTc1MjZdIDM4Yzc0IGlzIDc5NDFmMDAwIQ0KWyAgMTM3LjA5OTM3Nl0gMzhj
NzUgaXMgNzk0MWUwMDAhDQpbICAxMzcuMTAxMjQ1XSAzOGM3NiBpcyA3OTQxZDAwMCENClsg
IDEzNy4xMDMwOTVdIDM4Yzc3IGlzIDc5NDFjMDAwIQ0KWyAgMTM3LjEwNDk1NF0gMzc5ZTAg
aXMgNzk0MWIwMDAhDQpbICAxMzcuMTA2ODE3XSAzNzZjMSBpcyA3YTVkZjAwMCENClsgIDEz
Ny4xMDg2ODBdIDM3NmMyIGlzIDdhNWUwMDAwIQ0KWyAgMTM3LjExMDU3M10gMzc2YzMgaXMg
N2E1ZTEwMDAhDQpbICAxMzcuMTEyNDQxXSAzN2ZmMCBpcyA3YTVlMjAwMCENClsgIDEzNy4x
MTQzMTVdIDM3ZmYxIGlzIDdhNWU4MDAwIQ0KWyAgMTM3LjExNjE2N10gMzdmZjIgaXMgN2E1
ZTkwMDAhDQpbICAxMzcuMTE4MDU0XSAzN2ZmMyBpcyA3YTVlYTAwMCENClsgIDEzNy4xMTk5
MTBdIDM3YTI4IGlzIDdhNWViMDAwIQ0KWyAgMTM3LjEyMTgwMF0gMzdhMjkgaXMgMjE5NDUw
MDAhDQpbICAxMzcuMTIzNjk5XSAzN2EyYSBpcyAyMTk0NjAwMCENClsgIDEzNy4xMjU1ODVd
IDM3YTJiIGlzIDIxOTQ3MDAwIQ0KWyAgMTM3LjEyODE1MV0gMzc5ZTIgaXMgNzkzMDEwMDAh
DQpbICAxMzcuMTMwMTQwXSAzNzllMSBpcyA3OTMwMjAwMCENClsgIDEzNy4xMzIwMjZdIDM3
ZTFiIGlzIDc5MzAzMDAwIQ0KWyAgMTM3LjEzMzkzNF0gMzc1YzAgaXMgNzkzMDQwMDAhDQpb
ICAxMzcuMTM1ODUzXSAzNzVjMSBpcyA3OTMwNTAwMCENClsgIDEzNy4xMzc3NTVdIDM3NWMy
IGlzIDc5MzA3MDAwIQ0KWyAgMTM3LjEzOTY1MV0gMzc1YzMgaXMgNzkzMDgwMDAhDQpbICAx
MzcuMTQxNTMyXSAzNzU1MCBpcyA3OTMwOTAwMCENClsgIDEzNy4xNDM0NDJdIDM3NTUxIGlz
IDc5MzBhMDAwIQ0KWyAgMTM3LjE0NTI5OF0gMzc1NTIgaXMgNzkzMGIwMDAhDQpbICAxMzcu
MTQ3MzQyXSAzNzU1MyBpcyA3OGU4YzAwMCENClsgIDEzNy4xNDkyMjNdIDM4Y2E4IGlzIDc4
ZThkMDAwIQ0KWyAgMTM3LjE1MTEwNF0gMzhjYTkgaXMgNzhlOGUwMDAhDQpbICAxMzcuMTUy
OTYxXSAzOGNhYSBpcyA3OGU4ZjAwMCENClsgIDEzNy4xNTQ4MTNdIDM4Y2FiIGlzIDc4ZTkw
MDAwIQ0KWyAgMTM3LjE1NjY3Nl0gMzdlZTggaXMgNzhlOTEwMDAhDQpbICAxMzcuMTU4NTI5
XSAzN2VlOSBpcyA3OGU5MjAwMCENClsgIDEzNy4xNjA0MDVdIDM3ZWVhIGlzIDc4ZTkzMDAw
IQ0KWyAgMTM3LjE2MjI0M10gMzdlZWIgaXMgNzhlOTQwMDAhDQpbICAxMzcuMTY0MTE4XSAz
ODMyYyBpcyA3OGU5NTAwMCENClsgIDEzNy4xNjU5NjJdIDM4MzJkIGlzIDc4ZTk2MDAwIQ0K
WyAgMTM3LjE2NzgwOV0gMzgzMmUgaXMgNzhlOTcwMDAhDQpbICAxMzcuMTY5NjIxXSAzODMy
ZiBbICAxMzkuMjk3MjI1XSAzNzliYyBpcyAyMzRhYzAwMCENClsgIDEzOS4yOTk0NDVdIDM3
OWJkIGlzIDI0NDdhMDAwIQ0KWyAgMTM5LjMwMjk3MV0gMzc3YTcgaXMgMjQ0NTYwMDAhDQpb
ICAxMzkuMzE4OTExXSAzNzdhMSBpcyAyMmIxOTAwMCENClsgIDEzOS4zMjExMTddIDM3N2Ey
IGlzIDIzMzhlMDAwIQ0KWyAgMTM5LjMyMzI5OF0gMzc3YTMgaXMgMjQyMmEwMDAhDQpbICAx
MzkuMzI1NDk3XSAzNzdhNCBpcyAyMmJhYzAwMCENClsgIDEzOS4zMjc3MDZdIDM3N2E1IGlz
IDI0MjYwMDAwIQ0KWyAgMTM5LjMyOTkyOV0gMzc3YTYgaXMgMjQyZWMwMDAhDQpbICAxMzku
MzMyMTQ3XSAzNzdhMCBpcyAyNDI2YzAwMCENClsgIDEzOS4zMzQzNDBdIDM3OWJlIGlzIDIz
NGFiMDAwIQ0KWyAgMTM5LjMzNzE2Ml0gMzdmYzggaXMgMjQ0MjkwMDAhDQpbICAxMzkuMzcx
Mzg0XSAzN2ZjOSBpcyA3OTQ2NDAwMCENClsgIDEzOS4zNzM2NzBdIDM4Y2E1IGlzIDc5NDdk
MDAwIQ0KWyAgMTM5LjM3NTg0M10gMzhjYTYgaXMgNzk0OTcwMDAhDQpbICAxMzkuMzc4MDU3
XSAzNzliZiBpcyA3OTQ4OTAwMCENClsgIDEzOS4zODg4NzddIDM3ZmNhIGlzIDIyYTRiMDAw
IQ0KWyAgMTM5LjM5MTIyNF0gMzdmY2IgaXMgMjJhNGEwMDAhDQpbICAxMzkuMzkzNDA1XSAz
N2ZjYyBpcyAyMmE0OTAwMCENClsgIDEzOS4zOTU2NTJdIDM4Y2E3IGlzIDdhMDY3MDAwIQ0K
WyAgMTM5LjQwNzQ2Ml0gMzdmY2UgaXMgN2E2ZWQwMDAhDQpbICAxMzkuNDIyOTIzXSAzN2Zj
ZCBpcyAyMWU0YjAwMCENClsgIDEzOS40MzAyOTZdIDM3YmIwIGlzIDIxNjgzMDAwIQ0KWyAg
MTM5LjQzOTMzN10gMzdiYjEgaXMgNzk0YjYwMDAhDQpbICAxMzkuNDYyODIwXSAzN2JiMiBp
cyAyMWUzYzAwMCENClsgIDEzOS40ODgxNjVdIDM3YmIzIGlzIDIxZTU3MDAwIQ0KWyAgMTM5
LjQ5MDQ2Ml0gMzdiYjQgaXMgNzhkMWEwMDAhDQpbICAxMzkuNDkyNjg1XSAzN2JiNSBpcyAy
MWU1OTAwMCENClsgIDEzOS40OTQ5NTVdIDM3YmI2IGlzIDc4ZDQ5MDAwIQ0KWyAgMTM5LjQ5
OTM3NV0gMzdiYjcgaXMgNzk0NzEwMDAhDQpbICAxMzkuNTAxNzEyXSAzN2ZjZiBpcyAyMThh
YTAwMCENClsgIDEzOS41MDM5NjldIDM2ZjAwIGlzIDc5NDhmMDAwIQ0KWyAgMTM5LjUwNjIz
MF0gMzZmMDEgaXMgMjFlNWUwMDAhDQpbICAxMzkuNTA4NTE2XSAzNmYwMiBpcyAyMTY0YTAw
MCENClsgIDEzOS41MTA4MDFdIDM2ZjAzIGlzIDIxNjdjMDAwIQ0KWyAgMTM5LjUxMzk4N10g
MzZmMDQgaXMgNzk0NTAwMDAhDQpbICAxMzkuNTE2MjYxXSAzNmYwNSBpcyA3YTA1MjAwMCEN
ClsgIDEzOS41MTg1NThdIDM2ZjA2IGlzIDc5NDRjMDAwIQ0KWyAgMTM5LjU1MDk1MF0gMzZm
MDcgaXMgMjFlNmMwMDAhDQpbICAxMzkuNTUzMjI1XSAzNzU2OCBpcyA3OTRjNDAwMCENClsg
IDEzOS41NTU1NDNdIDM3NTY5IGlzIDdhNjFkMDAwIQ0KWyAgMTM5LjU1Nzg0NV0gMzc1NmEg
aXMgMjFlNjMwMDAhDQpbICAxMzkuNTYwMTY3XSAzNzU2YiBpcyA3OGNkOTAwMCENClsgIDEz
OS41NjI0NjJdIDM3NTZjIGlzIDIxNjQ4MDAwIQ0KWyAgMTM5LjU2NDc4M10gMzc1NmQgaXMg
N2EwNTMwMDAhDQpbICAxMzkuNTY3MDgzXSAzNzU2ZSBpcyA3OGNkZDAwMCENClsgIDEzOS41
NjkzOThdIDM3NTZmIGlzIDdhMDU4MDAwIQ0KWyAgMTM5LjU3MjE4Nl0gMzdmYTAgaXMgMjE2
NDAwMDAhDQpbICAxMzkuNTc0NTA4XSAzN2ZhMSBpcyA3YTZiYjAwMCENClsgIDEzOS41NzY4
NTBdIDM3ZmEyIGlzIDc4Y2QyMDAwIQ0KWyAgMTM5LjU3OTE3M10gMzdmYTMgaXMgMjFlNTgw
MDAhDQpbICAxMzkuNTgyMTcwXSAzN2ZhNCBpcyA3YTA0ZDAwMCENClsgIDEzOS41ODQ0OTdd
IDM2ZWMwIGlzIDIxNjI5MDAwIQ0KWyAgMTM5LjU4NjgxNl0gMzZlYzEgaXMgN2EwODcwMDAh
DQpbICAxMzkuNTg5MTM5XSAzNmVjMiBpcyA3OTRhODAwMCENClsgIDEzOS41OTE0NDBdIDM2
ZWMzIGlzIDc5NGJkMDAwIQ0KWyAgMTM5LjU5Mzc4OF0gMzZlYzQgaXMgMjFlNzUwMDAhDQpb
ICAxMzkuNTk2MDcyXSAzNmVjNSBpcyAyMTY1ZTAwMCENClsgIDEzOS41OTgzNzNdIDM2ZWM2
IGlzIDIxNjE2MDAwIQ0KWyAgMTM5LjYwMDYzNV0gMzZlYzcgaXMgMjE2MTUwMDAhDQpbICAx
MzkuNjAzNDAwXSAzNzVhMCBpcyA3OGNkMTAwMCENClsgIDEzOS42MDU3MDNdIDM3NWExIGlz
IDc5NDdmMDAwIQ0KWyAgMTM5LjYwNzk2NF0gMzc1YTIgaXMgNzk0YmIwMDAhDQpbICAxMzku
NjMzNjAyXSAzNzVhMyBpcyA3OGQxODAwMCENClsgIDEzOS42MzU5MDBdIDM3NWE0IGlzIDIx
ZTYwMDAwIQ0KWyAgMTM5LjYzODc0MF0gMzc1YTUgaXMgMjE4YWUwMDAhDQpbICAxMzkuNjQx
MDExXSAzNzVhNiBpcyAyMWU1YTAwMCENClsgIDEzOS42NDMyODFdIDM3NWE3IGlzIDIxZTZl
MDAwIQ0KWyAgMTM5LjY1MjI1N10gMzc3NTAgaXMgMjFlMTAwMDAhDQpbICAxMzkuNjU0NTA1
XSAzNzc1MSBpcyAyMWUwZjAwMCENClsgIDEzOS42NTY3MzBdIDM3NzUyIGlzIDIxZTBlMDAw
IQ0KWyAgMTM5LjY1ODg3OF0gMzc3NTMgaXMgMjFlMGQwMDAhDQpbICAxMzkuNjYxNTczXSAz
Nzc1NCBpcyAyMWUzNzAwMCENClsgIDEzOS42NjM3MzBdIDM3NzU1IGlzIDIxZTM4MDAwIQ0K
WyAgMTM5LjY2NTgxOF0gMzc3NTYgaXMgMjFlM2QwMDAhDQpbICAxMzkuNjY3OTIxXSAzNzc1
NyBpcyAyMWU1MjAwMCENClsgIDEzOS43MTIzMTFdIDM2ZTYxIGlzIDIxODhhMDAwIQ0KWyAg
MTM5LjcxNTA0OV0gMzdmYTUgaXMgNzhjZWQwMDAhDQpbICAxMzkuNzQ5NDQ1XSAzNmU2MiBp
cyA3OTQ4ZTAwMCENClsgIDEzOS43NTM0ODRdIDM5MTQ0IGlzIDIxOGJkMDAwIQ0KWyAgMTM5
Ljc4MzMyNV0gMzdlNjUgaXMgMjFlNDgwMDAhDQpbICAxMzkuNzg1NTA3XSAzN2UxZCBpcyA3
YTY2MDAwMCENClsgIDEzOS43OTgxMDRdIDM3ZmE2IGlzIDdhNzFiMDAwIQ0KWyAgMTM5Ljgw
MDMyNV0gMzdmYTcgaXMgNzk0YmUwMDAhDQpbICAxMzkuODAyNDc5XSAzN2QxOCBpcyAyMWUz
ZTAwMCENClsgIDEzOS44MDQ2NDZdIDM3ZDE5IGlzIDIxNjE5MDAwIQ0KWyAgMTM5LjgwNzMy
M10gMzdkMWEgaXMgMjFlM2EwMDAhDQpbICAxMzkuODA5NDk0XSAzNmU2MyBpcyA3YTY5MzAw
MCENClsgIDEzOS44MTE3MjhdIDM2ZTY0IGlzIDIxNjUxMDAwIQ0KWyAgMTM5LjgxMzkzNl0g
MzZlNjUgaXMgMjE4ODkwMDAhDQpbICAxMzkuODE2NjE4XSAzNmU2NiBpcyAyMTYwYTAwMCEN
ClsgIDEzOS44MTg4NDNdIDM2ZTY3IGlzIDc4Y2Q3MDAwIQ0KWyAgMTM5LjgyMTAyNV0gMzdh
NTggaXMgN2EwNmIwMDAhDQpbICAxMzkuODIzMjI5XSAzN2E1OSBpcyA3OTQ0ZjAwMCENClsg
IDEzOS44MzEyNjhdIDM3YTVhIGlzIDIxNWJjMDAwIQ0KWyAgMTM5LjgzMzQ4MV0gMzdhNWIg
aXMgMjE2NmMwMDAhDQpbICAxMzkuODM1NzM2XSAzN2E1YyBpcyA3YTA5MDAwMCENClsgIDEz
OS44Mzc5NTJdIDM3YTVkIGlzIDc5NGM4MDAwIQ0KWyAgMTM5Ljg0MDE4MF0gMzdhNWUgaXMg
MjE2NTkwMDAhDQpbICAxMzkuODQyNDE5XSAzN2E1ZiBpcyAyMWU3ZjAwMCENClsgIDEzOS44
NDQ3MDBdIDM2NTU4IGlzIDc4Y2YxMDAwIQ0KWyAgMTM5Ljg0Njk3OV0gMzY1NTkgaXMgNzk0
OWEwMDAhDQpbICAxMzkuODQ5MjQ3XSAzNjU1YSBpcyAyMTYwNjAwMCENClsgIDEzOS44NTIw
NDddIDM2NTViIGlzIDc4Y2NkMDAwIQ0KWyAgMTM5Ljg1NDM2OV0gMzY1NWMgaXMgMjE4YTgw
MDAhDQpbICAxMzkuODU2NzI3XSAzNjU1ZCBpcyA3OGQzODAwMCENClsgIDEzOS44NTkwODJd
IDM2NTVlIGlzIDc5NDUxMDAwIQ0KWyAgMTM5Ljg2MTc0Ml0gMzY1NWYgaXMgNzhkMzUwMDAh
DQpbICAxMzkuODc2NTY2XSAzN2RjOCBpcyA3OGQwNDAwMCENClsgIDE0MC4wMjgzMDZdIDM3
ZGM5IGlzIDIxOGI1MDAwIQ0KWyAgMTQwLjA3NjMyNV0gMzdkMWIgaXMgNzk0OGEwMDAhDQpb
ICAxNDAuMDc4NzQ3XSAzN2QxYyBpcyA3OTRhYTAwMCENClsgIDE0MC4wODEwNzldIDM2Yzcz
IGlzIDc4ZDQyMDAwIQ0KWyAgMTQwLjA4MzQwMV0gMzZjNzQgaXMgNzk0YTYwMDAhDQpbICAx
NDAuMTEwMDMyXSAzNmM3NSBpcyAyMTY3NjAwMCENClsgIDE0MC4xMTI0MTBdIDM3YjVlIGlz
IDc5NDU4MDAwIQ0KWyAgMTQwLjExNDc1OF0gMzdmMmMgaXMgNzhkMTQwMDAhDQpbICAxNDAu
MTE3MTI0XSAzN2RjZCBpcyAyMWU3YzAwMCENClsgIDE0MC4xMjg4MzNdIDM3ZGNlIGlzIDIx
NWJhMDAwIQ0KWyAgMTQwLjEzMTIwOF0gMzdkY2YgaXMgMjE4YWMwMDAhDQpbICAxNDAuMTMz
NTY2XSAzN2YwMCBpcyA3YTY4ZjAwMCENClsgIDE0MC4xODU1MjhdIDM3ZjAxIGlzIDIxZTMw
MDAwIQ0KWyAgMTQwLjE4Nzk3M10gMzZjNzYgaXMgMjFlMmYwMDAhDQpbICAxNDAuMTkwMzUz
XSAzNmM3NyBpcyAyMWUyZTAwMCENClsgIDE0MC4xOTI2ODNdIDM2ZjY4IGlzIDIxZTJkMDAw
IQ0KWyAgMTQwLjIyNzMxM10gMzZmNjkgaXMgNzhjZjkwMDAhDQpbICAxNDAuMjI5NjY3XSAz
N2YwMiBpcyA3OGNmODAwMCENClsgIDE0MC4yMzIyNjNdIDM3ZjAzIGlzIDI0NGM4MDAwIQ0K
WyAgMTQwLjIzOTI5Ml0gMzdmMDUgaXMgMjQ0YzEwMDAhDQpbICAxNDAuMjQxNzIxXSAzN2Yw
NiBpcyAyNDMyZTAwMCENClsgIDE0MC4yNDQwMzRdIDM3ZjA3IGlzIDIzNGFlMDAwIQ0KWyAg
MTQwLjI0NjMzMF0gMzkyZjggaXMgMjJhMmQwMDAhDQpbICAxNDAuMjQ4NjI3XSAzOTJmOSBp
cyAyNDNhMDAwMCENClsgIDE0MC4yNTA5NDFdIDM5MmZhIGlzIDI0NDE3MDAwIQ0KWyAgMTQw
LjI1MzIxMF0gMzkyZmIgaXMgMjQzNDUwMDAhDQpbICAxNDAuMjU1NTIzXSAzOTJmYyBpcyAy
NDQ3ZTAwMCENClsgIDE0MC4yNTc3OTVdIDM5MmZkIGlzIDI0Mzg2MDAwIQ0KWyAgMTQwLjI2
MDA3N10gMzkyZmUgaXMgMjQ0YzMwMDAhDQpbICAxNDAuMjYyMzIzXSAzOTJmZiBpcyAyNDM1
ZjAwMCENClsgIDE0MC4yNjQ4MDhdIDM3NWI4IGlzIDIzZGQ4MDAwIQ0KWyAgMTQwLjI2NzEw
OF0gMzc1YjkgaXMgMjQyYmIwMDAhDQpbICAxNDAuMjY5Mzc5XSAzNzViYSBpcyAyNDQ3YTAw
MCENClsgIDE0MC4yNzE2MTldIDM3NWJiIGlzIDI0NGQ4MDAwIQ0KWyAgMTQwLjI3Mzg0OF0g
Mzc1YmMgaXMgMjQyMzIwMDAhDQpbICAxNDAuMjc2MDYxXSAzNzViZCBpcyAyMmExYzAwMCEN
ClsgIDE0MC4yNzgyNTFdIDM3NWJlIGlzIDIzZGI1MDAwIQ0KWyAgMTQwLjI4MDQ1OV0gMzc1
YmYgaXMgMjQ0NTYwMDAhDQpbICAxNDAuMjgyNjAwXSAzNmM3MCBpcyAyMmJhNzAwMCENClsg
IDE0MC4yODQ3ODFdIDM2YzcxIGlzIDI0MzJiMDAwIQ0KWyAgMTQwLjI4NjkzN10gMzZjNzIg
aXMgMjQyYTEwMDAhDQpbICAxNDAuMjg5MTAxXSAzNjRhMyBpcyAyMzM5MDAwMCENClsgIDE0
MC4yOTEyMzddIDM2NGE0IGlzIDI0M2QyMDAwIQ0KWyAgMTQwLjI5MzM1OV0gMzY0YTUgaXMg
MjMyZTQwMDAhDQpbICAxNDAuMjk1NDczXSAzNjRhNiBpcyAyMzRhZjAwMCENClsgIDE0MC4y
OTc1OTJdIDM2NGE3IGlzIDI0MzllMDAwIQ0KWyAgMTQwLjI5OTY5Nl0gMzkyYjggaXMgMjJj
MDMwMDAhDQpbICAxNDAuMzAxODU1XSAzOTJiOSBpcyAyNDJlMDAwMCENClsgIDE0MC4zMDM5
OTldIDM5MmJhIGlzIDI0MjcwMDAwIQ0KWyAgMTQwLjMwNjEzMl0gMzkyYmIgaXMgMjJiYjcw
MDAhDQpbICAxNDAuMzA4MjYwXSAzOTJiYyBpcyAyNDNkZDAwMCENClsgIDE0MC4zMzYzMzZd
IDM5MmJkIGlzIDI0M2NhMDAwIQ0KWyAgMTQwLjM1MDMxNF0gMzdmMDQgaXMgMjJiYTcwMDAh
DQpbICAxNDAuMzc2OTg3XSAzOTJiZSBpcyA3OGNmYTAwMCENClsgIDE0MC40MTI2NzJdIDM2
ZjZhIGlzIDIxZTFjMDAwIQ0KWyAgMTQwLjQxNDk1MV0gMzZmNmIgaXMgMjFlMWIwMDAhDQpb
ICAxNDAuNDE3MTgzXSAzNmY2YyBpcyAyMWUxYTAwMCENClsgIDE0MC40NTM3ODNdIDM2ZjZk
IGlzIDc5NDc3MDAwIQ0KWyAgMTQwLjUxNDAwNl0gMzkyYmYgaXMgMjE2NGQwMDAhDQpbICAx
NDAuNTE2NzkwXSAzNmY2ZSBpcyA3YTZiODAwMCENClsgIDE0MC41MTk1MDddIDM4YzA4IGlz
IDIxZTEyMDAwIQ0KWyAgMTQwLjUzMzUwNl0gMzhjMDkgaXMgMjFlMjAwMDAhDQpbICAxNDAu
NTM1NzYyXSAzNmY2ZiBpcyAyMWUxZjAwMCENClsgIDE0MC41MzgwNzRdIDM3ZWY4IGlzIDIx
ZTFlMDAwIQ0KWyAgMTQwLjU0MDM1OF0gMzdlZjkgaXMgMjFlMWQwMDAhDQpbICAxNDAuNTQz
MDc1XSAzN2VmYSBpcyAyMWUyMjAwMCENClsgIDE0MC41NDUzNzZdIDM4YzBhIGlzIDIxZTIx
MDAwIQ0KWyAgMTQwLjU1NDg3Nl0gMzhjMGMgaXMgMjFlMDYwMDAhDQpbICAxNDAuNTU3MTUz
XSAzOGMwZCBpcyAyMWUwNTAwMCENClsgIDE0MC41NTkzODddIDM4YzBlIGlzIDIxZTI0MDAw
IQ0KWyAgMTQwLjU2MTYwMF0gMzhjMGYgaXMgMjFlMjMwMDAhDQpbICAxNDAuNTY0MjAxXSAz
OGMwYiBpcyAyMWE2YjAwMCENClsgIDE0MC41NzQ2MTZdIDM3NTEwIGlzIDIxZTRlMDAwIQ0K
WyAgMTQwLjU3Njk2Nl0gMzc1MTEgaXMgN2EwYjEwMDAhDQpbICAxNDAuNTc5MTU1XSAzNzUx
MiBpcyAyMWUyNTAwMCENClsgIDE0MC41ODEzNTRdIDM3NTEzIGlzIDIxZTMxMDAwIQ0KWyAg
MTQwLjU4MzU2OF0gMzc1MTQgaXMgMjE2NWMwMDAhDQpbICAxNDAuNTg1NzMzXSAzNzUxNSBp
cyAyMWUwYzAwMCENClsgIDE0MC41ODc5MTBdIDM3NTE2IGlzIDIxZTBiMDAwIQ0KWyAgMTQw
LjU5MDAyNV0gMzc1MTcgaXMgMjFlMGEwMDAhDQpbICAxNDAuNTkyMTgxXSAzOTMzMCBpcyAy
MWUwOTAwMCENClsgIDE0MC41OTQzNzhdIDM5MzMxIGlzIDIxZTA4MDAwIQ0KWyAgMTQwLjU5
NjQ5Nl0gMzdkY2EgaXMgMjFlMDcwMDAhDQpbICAxNDAuNTk4NzExXSAzN2RjYiBpcyAyMWUx
ODAwMCENClsgIDE0MC42MDA4NDRdIDM5MzMyIGlzIDIxZTE5MDAwIQ0KWyAgMTQwLjYwMjkw
N10gMzkzMzMgaXMgMjFlMzUwMDAhDQpbICAxNDAuNjA0OTYwXSAzOTMzNCBpcyA3YTA4NjAw
MCENClsgIDE0MC42MDcwMTJdIDM5MzM1IGlzIDIxZTI5MDAwIQ0KWyAgMTQwLjYwOTA5MV0g
MzkzMzYgaXMgN2E2YmMwMDAhDQpbICAxNDAuNjExOTk3XSAzOTMzNyBpcyAyMWE2OTAwMCEN
ClsgIDE0MC42MTQwODZdIDM3ZjM4IGlzIDIxYTZhMDAwIQ0KWyAgMTQwLjYxNjExM10gMzdm
MzkgaXMgMjFhNzMwMDAhDQpbICAxNDAuNjE4MTAxXSAzN2YzYSBpcyAyMWE3NDAwMCENClsg
IDE0MC42MjAzMzNdIDM2NWE2IGlzIDIxYTgwMDAwIQ0KWyAgMTQwLjYyMjMwMl0gMzY1YTcg
aXMgMjFhODEwMDAhDQpbICAxNDAuNjI0MjY3XSAzOTJhOCBpcyAyMWE4MjAwMCENClsgIDE0
MC42MjYyMzNdIDM5MmE5IGlzIDIxYTgzMDAwIQ0KWyAgMTQwLjYyODI5NF0gMzkyYWEgaXMg
MjFhODQwMDAhDQpbICAxNDAuNjMwMjY0XSAzOTJhYiBpcyAyMWUxNTAwMCENClsgIDE0MC42
MzIxOTddIDM5MmFjIGlzIDIxZTE2MDAwIQ0KWyAgMTQwLjYzNDE2Nl0gMzkyYWQgaXMgMjFl
MTcwMDAhDQpbICAxNDAuNjM2MDg3XSAzN2YzYiBpcyAyMWE3NTAwMCENClsgIDE0MC42Mzgw
NjNdIDM3ZjNjIGlzIDIxYTc2MDAwIQ0KWyAgMTQwLjYzOTk5Nl0gMzdmM2QgaXMgMjFhNzcw
MDAhDQpbICAxNDAuNjQxOTMyXSAzN2YzZSBpcyAyMWE3ODAwMCENClsgIDE0MC42NDM4Mzdd
IDM3ZjNmIGlzIDIxYTc5MDAwIQ0KWyAgMTQwLjY0NTcxMV0gMzY1YTAgaXMgMjFhN2EwMDAh
DQpbICAxNDAuNjQ3NTk2XSAzNjVhMSBpcyAyMWE3YjAwMCENClsgIDE0MC42NDk0NzRdIDM2
NWEyIGlzIDIxYTdjMDAwIQ0KWyAgMTQwLjY1MTM0MV0gMzY1YTMgaXMgMjFhN2QwMDAhDQpb
ICAxNDAuNjUzMTk5XSAzNjVhNCBpcyAyMWE3ZTAwMCENClsgIDE0MC42NTUwODBdIDM2NWE1
IGlzIDIxYTdmMDAwIQ0KWyAgMTQwLjY1Njk5NV0gMzkyYWUgaXMgMjFhNjUwMDAhDQpbICAx
NDAuNjU4ODcyXSAzOTJhZiBpcyAyMWE2NjAwMCENClsgIDE0MC42NjA3MjBdIDM3YTIwIGlz
IDIxYTY3MDAwIQ0KWyAgMTQwLjY2MjU4OF0gMzdhMjEgaXMgMjFhNjgwMDAhDQpbICAxNDAu
NjcwOTU5XSAzN2EyMiBpcyAyMWE0ZTAwMCENClsgIDE0MC42Nzk2ODRdIDM3YTIzIGlzIDIx
YTVhMDAwIQ0KWyAgMTQwLjY4MTYzOF0gMzdhMjQgaXMgMjFhNWIwMDAhDQpbICAxNDAuNjgz
NDY4XSAzN2EyNSBpcyAyMWE1YzAwMCENClsgIDE0MC42ODUyMzldIDM3YTI2IGlzIDIxYTVk
MDAwIQ0KWyAgMTQwLjY4NzAxOV0gMzdhMjcgaXMgMjFhNWUwMDAhDQpbICAxNDAuNjg4NzU3
XSAzNmY5MCBpcyAyMWE1ZjAwMCENClsgIDE0MC42OTA1MTZdIDM2ZjkxIGlzIDIxYTYwMDAw
IQ0KWyAgMTQwLjY5MjI5M10gMzZmOTIgaXMgMjFhNjEwMDAhDQpbICAxNDAuNjk0MDQwXSAz
NmY5MyBpcyAyMWE2MjAwMCENClsgIDE0MC42OTU3OTNdIDM2Zjk0IGlzIDIxYTYzMDAwIQ0K
WyAgMTQwLjY5NzUzNV0gMzZmOTUgaXMgMjFhNjQwMDAhDQpbICAxNDAuNjk5NDAxXSAzNmY5
NiBpcyAyMWE1NDAwMCENClsgIDE0MC43MDEyMTJdIDM2Zjk3IGlzIDIxYTU1MDAwIQ0KWyAg
MTQwLjcwMjk2N10gMzZlZDAgaXMgMjFhNTYwMDAhDQpbICAxNDAuNzA0NzgwXSAzNmVkMSBp
cyAyMWE1NzAwMCENClsgIDE0MC43MDY1NTFdIDM2ZWQyIGlzIDIxYTU4MDAwIQ0KWyAgMTQw
LjcwODMxOV0gMzZlZDMgaXMgMjFhNTkwMDAhDQpbICAxNDAuNzEwODMyXSAzNmVkNSBpcyAy
MWEzZjAwMCENClsgIDE0MC43MTI2OTZdIDM2ZWQ0IGlzIDIxZTUwMDAwIQ0KWyAgMTQwLjcx
NDQ5N10gMzdlZmIgaXMgMjFhNDEwMDAhDQpbICAxNDAuNzE2MzAwXSAzN2VmYyBpcyA3OTQ3
NDAwMCENClsgIDE0MC43MTgxMTVdIDM3ZWZkIGlzIDc5NDZiMDAwIQ0KWyAgMTQwLjcxOTkx
Ml0gMzdlZmUgaXMgMjFlNTEwMDAhDQpbICAxNDAuNzIxOTU0XSAzNjQ0NSBpcyAyMWEzNDAw
MCENClsgIDE0MC43MjM4MzBdIDM2NDQ2IGlzIDIxYTMzMDAwIQ0KWyAgMTQwLjcyNTY4M10g
MzY0NDcgaXMgMjFhMzIwMDAhDQpbICAxNDAuNzI3NTQwXSAzNjQzMCBpcyAyMWEzMTAwMCEN
ClsgIDE0MC43MjkzODNdIDM2NDMxIGlzIDIxYTMwMDAwIQ0KWyAgMTQwLjczMTIyN10gMzY0
MzIgaXMgMjFhMmYwMDAhDQpbICAxNDAuNzMzMDYwXSAzNjQzMyBpcyAyMWEyZTAwMCENClsg
IDE0MC43MzQ4OTJdIDM2NDM0IGlzIDIxYTJkMDAwIQ0KWyAgMTQwLjczNjY5NV0gMzdlZmYg
aXMgMjFhM2UwMDAhDQpbICAxNDAuNzM4NTQ0XSAzN2E2OCBpcyA3OTQ2MzAwMCENClsgIDE0
MC43NDA0MTJdIDM3YTY5IGlzIDc5NDcwMDAwIQ0KWyAgMTQwLjc0MjI5Nl0gMzdhNmEgaXMg
MjFhM2MwMDAhDQpbICAxNDAuNzQ0MjAzXSAzN2E2YiBpcyAyMWEzYjAwMCENClsgIDE0MC43
NDYxMDhdIDM3YTZjIGlzIDIxYTNhMDAwIQ0KWyAgMTQwLjc0Nzk5Ml0gMzdhNmQgaXMgMjFh
MzkwMDAhDQpbICAxNDAuNzQ5ODY5XSAzN2E2ZSBpcyAyMWEzODAwMCENClsgIDE0MC43NTE3
MzVdIDM3YTZmIGlzIDIxYTM3MDAwIQ0KWyAgMTQwLjc1MzYyM10gMzY0YTAgaXMgMjFhMzYw
MDAhDQpbICAxNDAuNzU1NDk3XSAzNjRhMSBpcyAyMWEzNTAwMCENClsgIDE0MC43NjU0ODBd
IDM2NDM1IGlzIDIxYTUwMDAwIQ0KWyAgMTQwLjc2NzQzMF0gMzY0MzYgaXMgMjFhNDcwMDAh
DQpbICAxNDAuNzY5MzI1XSAzNjQzNyBpcyAyMWE1MTAwMCENClsgIDE0MC43NzE3MzBdIDM2
NDc5IGlzIDIxYTJiMDAwIQ0KWyAgMTQwLjc3MzY0NF0gMzY0N2EgaXMgMjFhMmMwMDAhDQpb
ICAxNDAuNzc1NTM4XSAzNjQ3YiBpcyAyMWE0ODAwMCENClsgIDE0MC43Nzc0NDZdIDM2NDdj
IGlzIDIxYTQ2MDAwIQ0KWyAgMTQwLjc3OTgzNV0gMzY0N2QgaXMgMjFhMjgwMDAhDQpbICAx
NDAuNzgxNzI3XSAzNjQ3OCBpcyAyMWEyOTAwMCENClsgIDE0MC43ODM2MzFdIDM2ZWQ2IGlz
IDIxYTJhMDAwIQ0KWyAgMTQwLjc5MzkyNV0gMzZlZDcgaXMgMjM0YTUwMDAhDQpbICAxNDAu
Nzk2MzkxXSAzNjQ0MCBpcyAyMzRhNjAwMCENClsgIDE0MC44MDI1MDJdIDM2NDdlIGlzIDIy
YmIwMDAwIQ0KWyAgMTQwLjgwNDUwNF0gMzY0NDEgaXMgMjQyMmMwMDAhDQpbICAxNDAuODA2
MzY3XSAzNjQ0MiBpcyAyNDRjZTAwMCENClsgIDE0MC44MDgyNzhdIDM2NDQzIGlzIDI0NGU2
MDAwIQ0KWyAgMTQwLjgxMDY2NV0gMzY0NDQgaXMgMjQyNWMwMDAhDQpbICAxNDAuODE5MDI2
XSAzNjQ3ZiBpcyAyMzg3YTAwMCENClsgIDE0MC44MjQ3NDZdIDM5M2M4IGlzIDIzM2M2MDAw
IQ0KWyAgMTQwLjgzNjgxM10gMzkzYzkgaXMgMjQzZTIwMDAhDQpbICAxNDAuODQ0NzM1XSAz
OTNjYSBpcyAyNDI3ODAwMCENClsgIDE0MC44NDczMDVdIDM5M2NiIGlzIDI0MjMwMDAwIQ0K
WyAgMTQwLjg1NzEyMl0gMzkzY2MgaXMgMjQzMWEwMDAhDQpbICAxNDAuODU5NjUwXSAzOTNj
ZCBpcyAyNDNjMDAwMCENClsgIDE0MC44Njg2MzNdIDM5M2NlIGlzIDI0NDhjMDAwIQ0KWyAg
MTQwLjg3NzkxOF0gMzkzY2YgaXMgMjQxZDQwMDAhDQpbICAxNDAuODgzNTQ2XSAzOTM3MCBp
cyAyNDQ2NjAwMCENClsgIDE0MC44ODYwODVdIDM5MzcxIGlzIDI0M2YzMDAwIQ0KWyAgMTQw
Ljg5MzY0OV0gMzkzNzIgaXMgMjQzZTgwMDAhDQpbICAxNDAuOTAyMDY3XSAzOTM3MyBpcyAy
NDUyOTAwMCENClsgIDE0MC45MDY0ODddIDM5Mzc0IGlzIDI0MmU5MDAwIQ0KWyAgMTQwLjkx
MjAxMF0gMzkzNzUgaXMgMjQyNmUwMDAhDQpbICAxNDAuOTE3NDg5XSAzOTM3NiBpcyAyNDJl
ZDAwMCENClsgIDE0MC45MjI2NTBdIDM5Mzc3IGlzIDIyYmQ0MDAwIQ0KWyAgMTQwLjkyNzM3
MV0gMzkzYjggaXMgMjMzYmYwMDAhDQpbICAxNDAuOTMwMDAwXSAzOTNiOSBpcyAyMzNhNTAw
MCENClsgIDE0MC45Mzk0MDhdIDM5M2JhIGlzIDIzM2I2MDAwIQ0KWyAgMTQwLjk1MTE3OF0g
MzkzYmIgaXMgMjNkODUwMDAhDQpbICAxNDAuOTY1NDMwXSAzOTNiYyBpcyAyNDU3NjAwMCEN
ClsgIDE0MC45NzA1MDddIDM5M2JkIGlzIDI0MzJlMDAwIQ0KWyAgMTQwLjk3MzE4NV0gMzkz
YmUgaXMgMjM5MDYwMDAhDQpbICAxNDAuOTg3NzU3XSAzOTNiZiBpcyAyNDRjMTAwMCENClsg
IDE0MC45OTMwODVdIDM5MWYwIGlzIDIzNGFlMDAwIQ0KWyAgMTQwLjk5ODcxNF0gMzkxZjEg
aXMgMjQyNTUwMDAhDQpbICAxNDEuMDAxNTA4XSAzOTFmMiBpcyAyNDMzZDAwMCENClsgIDE0
MS4wMTUwNDJdIDM5MWYzIGlzIDI0M2NjMDAwIQ0KWyAgMTQxLjAzMDQyNl0gMzkxZjQgaXMg
MjJiMWIwMDAhDQpbICAxNDEuMDM2NzI1XSAzOGQzYiBpcyAyMmEyZDAwMCENClsgIDE0MS4w
Mzg5MzZdIDM4ZDNjIGlzIDI0NDM3MDAwIQ0KWyAgMTQxLjA0MTA5OF0gMzhkM2QgaXMgMjQy
NzIwMDAhDQpbICAxNDEuMDQzMjA2XSAzOGQzZSBpcyAyNDMyOTAwMCENClsgIDE0MS4wNDUz
NDldIDM4ZDNmIGlzIDI0MzlkMDAwIQ0KWyAgMTQxLjA0NzQ1OV0gMzc4YjggaXMgMjJhMjUw
MDAhDQpbICAxNDEuMDUxMTA2XSAzOTkxYiBpcyAyNDU3YjAwMCENClsgIDE0MS4wNTMyOTdd
IDM5OTFhIGlzIDI0NTdjMDAwIQ0KWyAgMTQxLjA1NTQ2OF0gMzk5MTkgaXMgMjJiYjEwMDAh
DQpbICAxNDEuMDU3NjYwXSAzOTkxOCBpcyAyMmJiMjAwMCENClsgIDE0MS4wNTk3ODVdIDM3
OGJmIGlzIDIyYWJkMDAwIQ0KWyAgMTQxLjA2MTk0Nl0gMzc4YmUgaXMgMjJhYmUwMDAhDQpb
ICAxNDEuMDY0MDg4XSAzNzhiZCBpcyAyNDI2NTAwMCENClsgIDE0MS4wNjYyMjhdIDM3OGJj
IGlzIDI0MjY2MDAwIQ0KWyAgMTQxLjA2ODM0M10gMzc4YmIgaXMgMjQ1NzcwMDAhDQpbICAx
NDEuMDcwNDg4XSAzNzhiYSBpcyAyNDU3ODAwMCENClsgIDE0MS4wNzI1ODddIDM3OGI5IGlz
IDI0MmEzMDAwIQ0KWyAgMTQxLjA3NDcxOF0gMzk5MWQgaXMgMjM0YjQwMDAhDQpbICAxNDEu
MDc2ODQzXSAzOTkxZSBpcyAyMzM4ZDAwMCENClsgIDE0MS4wNzg5NTldIDM5OTFmIGlzIDIz
MzhlMDAwIQ0KWyAgMTQxLjA4MTA2MV0gMzdiNjAgaXMgMjQzMzUwMDAhDQpbICAxNDEuMDgz
MTk5XSAzN2I2MSBpcyAyNDMzNjAwMCENClsgIDE0MS4wODUzMjZdIDM3YjYyIGlzIDI0MjI5
MDAwIQ0KWyAgMTQxLjA4NzQ1Nl0gMzdiNjMgaXMgMjQyMmEwMDAhDQpbICAxNDEuMDg5NTM0
XSAzN2I2NCBpcyAyNDQwNTAwMCENClsgIDE0MS4wOTE2MzVdIDM3YjY1IGlzIDI0NDA2MDAw
IQ0KWyAgMTQxLjA5MzY5OV0gMzdiNjYgaXMgMjJiYWQwMDAhDQpbICAxNDEuMDk1NzUzXSAz
OTkxYyBpcyAyMmJhZTAwMCENClsgIDE0MS4wOTc3OTddIDM3YjY3IGlzIDI0MzlhMDAwIQ0K
WyAgMTQxLjA5OTg0M10gMzZmNDggaXMgMjM0YjMwMDAhDQpbICAxNDEuMTAyODcyXSAzNzcx
YyBpcyAyMzNiODAwMCENClsgIDE0MS4xMDUxOTBdIDM3NzFkIGlzIDIzM2I3MDAwIQ0KWyAg
MTQxLjEwNzI3Nl0gMzc3MWUgaXMgMjQzOGEwMDAhDQpbICAxNDEuMTA5MzI4XSAzNzcxZiBp
cyAyNDM4OTAwMCENClsgIDE0MS4xMTE0MDBdIDM2ZDI4IGlzIDIyYjE4MDAwIQ0KWyAgMTQx
LjExMzQ3NF0gMzZkMjkgaXMgMjJiMTcwMDAhDQpbICAxNDEuMTE1NTQwXSAzNmQyYSBpcyAy
MzNhMjAwMCENClsgIDE0MS4xMTc1ODBdIDM2ZDJiIGlzIDIzM2ExMDAwIQ0KWyAgMTQxLjEx
OTU4MF0gMzZkMmMgaXMgMjQ1MmMwMDAhDQpbICAxNDEuMTIxNTc3XSAzNmQyZCBpcyAyNDUy
YjAwMCENClsgIDE0MS4xMjM1NTldIDM2ZDJlIGlzIDIyYTk0MDAwIQ0KWyAgMTQxLjEyNTU1
NV0gMzZkMmYgaXMgMjQyNDUwMDAhDQpbICAxNDEuMTI3NTI1XSAzNzUwMCBpcyAyNDI0NjAw
MCENClsgIDE0MS4xMjk1MThdIDM3NTAxIGlzIDI0NDgwMDAwIQ0KWyAgMTQxLjEzMTQ3MF0g
Mzc1MDIgaXMgMjQ0N2YwMDAhDQpbICAxNDEuMTMzNDU4XSAzNzUwMyBpcyAyM2RkYzAwMCEN
ClsgIDE0MS4xMzU0MTNdIDM3NTA0IGlzIDIzZGRiMDAwIQ0KWyAgMTQxLjEzNzM4N10gMzc1
MDUgaXMgMjJiMWEwMDAhDQpbICAxNDEuMTM5MzQxXSAzNzUwNiBpcyAyMmIxOTAwMCENClsg
IDE0MS4xNDEyODZdIDM3NTA3IGlzIDI0NDUyMDAwIQ0KWyAgMTQxLjE0MzIxMl0gMzY0Mjgg
aXMgMjQ0NTEwMDAhDQpbICAxNDEuMTQ1MTgwXSAzNzcxYiBpcyAyMzg3YzAwMCENClsgIDE0
MS4xNDcxMzRdIDM3NzFhIGlzIDIyYmNkMDAwIQ0KWyAgMTQxLjE0OTEwMF0gMzc3MTkgaXMg
MjJiY2UwMDAhDQpbICAxNDEuMTUxMDQ2XSAzNzcxOCBpcyAyNDFjZjAwMCENClsgIDE0MS4x
NTMwMTVdIDM2ZjRmIGlzIDI0MWQwMDAwIQ0KWyAgMTQxLjE1NDk4OV0gMzZmNGUgaXMgMjJi
MmIwMDAhDQpbICAxNDEuMTU2OTk4XSAzNmY0ZCBpcyAyMmIyYzAwMCENClsgIDE0MS4xNTg5
NTldIDM2ZjRjIGlzIDI0NDg5MDAwIQ0KWyAgMTQxLjE2MDkyOF0gMzZmNGIgaXMgMjQ0OGEw
MDAhDQpbICAxNDEuMTYyODcxXSAzNmY0YSBpcyAyNDUyZDAwMCENClsgIDE0MS4xNjQ3ODdd
IDM2ZjQ5IGlzIDI0NTJlMDAwIQ0KWyAgMTQxLjE2Njk0N10gMzkxZjUgaXMgMjQyMDQwMDAh
DQpbICAxNDEuMTY4ODYzXSAzOTFmNiBpcyAyMzRhYjAwMCENClsgIDE0MS4xNzA4MTNdIDM5
MWY3IGlzIDIzNGFjMDAwIQ0KWyAgMTQxLjE3MjcyMl0gMzdhNDAgaXMgMjQxZmQwMDAhDQpb
ICAxNDEuMTc0NjU1XSAzN2E0MSBpcyAyNDFmZTAwMCENClsgIDE0MS4xNzY1ODRdIDM3YTQy
IGlzIDIyYmQxMDAwIQ0KWyAgMTQxLjE3ODUzMF0gMzdhNDMgaXMgMjJiZDIwMDAhDQpbICAx
NDEuMTgwNDc0XSAzN2E0NCBpcyAyMmI3YjAwMCENClsgIDE0MS4xODI0MTZdIDM3YTQ1IGlz
IDIyYjdjMDAwIQ0KWyAgMTQxLjE4NDM0OV0gMzdhNDYgaXMgMjM4N2IwMDAhDQpbICAxNDEu
MTg2MjkyXSAzN2E0NyBpcyAyNDNmYTAwMCENClsgIDE0MS4xODgyNDNdIDM4ZDM4IGlzIDI0
NTEzMDAwIQ0KWyAgMTQxLjE5MDIyOF0gMzhkMzkgaXMgMjQ1MTQwMDAhDQpbICAxNDEuMTky
MTYwXSAzOGQzYSBpcyAyNDRkOTAwMCENClsgIDE0MS4xOTQxMDddIDM5M2Q4IGlzIDIyYTI3
MDAwIQ0KWyAgMTQxLjE5NjA3M10gMzkzZDkgaXMgMjJhMjgwMDAhDQpbICAxNDEuMTk4MDQ0
XSAzOTNkYSBpcyAyMmEwMTAwMCENClsgIDE0MS4xOTk5OThdIDM5M2RiIGlzIDIyYTAyMDAw
IQ0KWyAgMTQxLjIwMTk1Nl0gMzkzZGMgaXMgMjQxZDEwMDAhDQpbICAxNDEuMjAzOTMzXSAz
OTNkZCBpcyAyNDFkMjAwMCENClsgIDE0MS4yMDU5NzJdIDM2NDI5IGlzIDI0M2Y5MDAwIQ0K
WyAgMTQxLjIwODQyMV0gMzkzZGUgaXMgMjQzYmQwMDAhDQpbICAxNDEuMjEwNTI4XSAzNjQy
YSBpcyAyNDNiZTAwMCENClsgIDE0MS4yMTI1MTBdIDM2NDJiIGlzIDIzM2MzMDAwIQ0KWyAg
MTQxLjIxNDQ4NV0gMzY0MmMgaXMgMjMzYzQwMDAhDQpbICAxNDEuMjE3NDI4XSAzNjQyZSBp
cyAyNDRmZTAwMCENClsgIDE0MS4yMTkzNzddIDM2NDJmIGlzIDI0M2UzMDAwIQ0KWyAgMTQx
LjIyMTM0MF0gMzZjMTggaXMgMjQzZTQwMDAhDQpbICAxNDEuMjIzMjcyXSAzNmMxOSBpcyAy
NDIyZDAwMCENClsgIDE0MS4yMjUyNTBdIDM2YzFhIGlzIDI0MjJlMDAwIQ0KWyAgMTQxLjIy
NzE5NV0gMzZjMWIgaXMgMjQyMjEwMDAhDQpbICAxNDEuMjI5MTM5XSAzNmMxYyBpcyAyNDIy
MjAwMCENClsgIDE0MS4yMzEwNTddIDM2YzFkIGlzIDIyYjVmMDAwIQ0KWyAgMTQxLjIzMjk3
N10gMzZjMWUgaXMgMjJiNjAwMDAhDQpbICAxNDEuMjM0OTAwXSAzNmMxZiBpcyAyNDI1OTAw
MCENClsgIDE0MS4yMzY4MTddIDM2ZDMwIGlzIDI0MjVhMDAwIQ0KWyAgMTQxLjI0MDk4OV0g
MzhjOGMgaXMgMjQ0ZWIwMDAhDQpbICAxNDEuMjQyOTgzXSAzOGM4ZCBpcyAyNDRlYzAwMCEN
ClsgIDE0MS4yNDQ5NjJdIDM4YzhlIGlzIDI0MmYxMDAwIQ0KWyAgMTQxLjI0NjkwM10gMzhj
OGYgaXMgMjQyZjIwMDAhDQpbICAxNDEuMjQ4ODQ1XSAzN2MyOCBpcyAyNDJmMzAwMCENClsg
IDE0MS4yNTA3NzldIDM3YzI5IGlzIDI0MmY0MDAwIQ0KWyAgMTQxLjI1MjcwNV0gMzdjMmEg
aXMgMjQ0YmQwMDAhDQpbICAxNDEuMjU0NjE0XSAzN2MyYiBpcyAyNDRiZTAwMCENClsgIDE0
MS4yNTY1MDNdIDM3YzJjIGlzIDI0NGJmMDAwIQ0KWyAgMTQxLjI1ODQxMl0gMzdjMmQgaXMg
MjQ0YzAwMDAhDQpbICAxNDEuMjYwMjkyXSAzN2MyZSBpcyAyNDIxZDAwMCENClsgIDE0MS4y
NjIxODhdIDM2YzBhIGlzIDI0MjFlMDAwIQ0KWyAgMTQxLjI2NDA3Ml0gMzZjMGIgaXMgMjQy
MWYwMDAhDQpbICAxNDEuMjY1OTczXSAzNmMwYyBpcyAyNDIyMDAwMCENClsgIDE0MS4yNjc4
MzRdIDM2YzBkIGlzIDI0NGY1MDAwIQ0KWyAgMTQxLjI2OTc4Ml0gMzZjMGUgaXMgMjQ0ZjYw
MDAhDQpbICAxNDEuMjcxNjMxXSAzNzRlZSBpcyAyNDRmNzAwMCENClsgIDE0MS4yNzM0ODld
IDM3NGVmIGlzIDI0NGY4MDAwIQ0KWyAgMTQxLjI3NTI5OV0gMzhjODggaXMgMjQyNTEwMDAh
DQpbICAxNDEuMjc3MTQzXSAzOGM4OSBpcyAyNDI1MjAwMCENClsgIDE0MS4yNzg5ODddIDM4
YzhhIGlzIDI0MjUzMDAwIQ0KWyAgMTQxLjI4MDgxOF0gMzhjOGIgaXMgMjQyNTQwMDAhDQpb
ICAxNDEuMjgyNjQ1XSAzODNmNCBpcyAyNDQ2ODAwMCENClsgIDE0MS4yODQ0ODJdIDM4M2Y1
IGlzIDI0MzFiMDAwIQ0KWyAgMTQxLjI4NjMyMV0gMzgzZjYgaXMgMjQzMWMwMDAhDQpbICAx
NDEuMjg4MTY0XSAzODNmNyBpcyAyNDI0ZjAwMCENClsgIDE0MS4yOTAwMDRdIDM2YzBmIGlz
IDI0MjUwMDAwIQ0KWyAgMTQxLjI5MTkwM10gM1sgIDE0My40MTgyNDddIDM5Mjk5IGlzIDIz
MzI0MDAwIQ0KWyAgMTQzLjQyMDYwN10gMzkyOWEgaXMgMjMzMjMwMDAhDQpbICAxNDMuNDIy
ODQ1XSAzOTI5YiBpcyAyMzMyMjAwMCENClsgIDE0My40MjUyNTVdIDM5MjljIGlzIDIzMzIx
MDAwIQ0KWyAgMTQzLjQyODgzNV0gMzkyOWQgaXMgMjMzMjAwMDAhDQpbICAxNDMuNDMxMTIz
XSAzOTI5ZSBpcyAyMzMxZjAwMCENClsgIDE0My40MzM4ODVdIDM5MjlmIGlzIDIzMzFlMDAw
IQ0KWyAgMTQzLjQ0NTczMF0gMzhjOTAgaXMgMjMzMWQwMDAhDQpbICAxNDMuNDUzNjQ2XSAz
OGM5MSBpcyAyMzMxYzAwMCENClsgIDE0My40NTU4MTddIDM4YzkyIGlzIDIzMzFiMDAwIQ0K
WyAgMTQzLjQ1ODE0OV0gMzhjOTMgaXMgMjMzMWEwMDAhDQpbICAxNDMuNDYwMzgyXSAzOGM5
NCBpcyAyMzMxOTAwMCENClsgIDE0My40NjI2NTJdIDM3YmVkIGlzIDIzMzE4MDAwIQ0KWyAg
MTQzLjQ3MjYzMl0gMzdiZWUgaXMgMjMzMTcwMDAhDQpbICAxNDMuNDc0ODE1XSAzOGM5NSBp
cyAyMzMxNjAwMCENClsgIDE0My40ODE3OTddIDM3YmVmIGlzIDIzMzE1MDAwIQ0KWyAgMTQz
LjQ4NjI4NF0gMzhjOTYgaXMgMjMzMTQwMDAhDQpbICAxNDMuNDk4OTQ3XSAzOGM5NyBpcyAy
MzMxMzAwMCENClsgIDE0My41MDkzMDNdIDM4Yzk4IGlzIDIzMzEyMDAwIQ0KWyAgMTQzLjUy
NTg3NV0gMzhjOTkgaXMgMjMzMTEwMDAhDQpbICAxNDMuNTI4MjI0XSAzNzU0MCBpcyAyMzMx
MDAwMCENClsgIDE0My41NDQyNzddIDM4YzlhIGlzIDIzMzBmMDAwIQ0KWyAgMTQzLjU0NzEx
Ml0gMzc1NDEgaXMgMjMzMGUwMDAhDQpbICAxNDMuNTYyMjY4XSAzOGM5YiBpcyAyMzMwZDAw
MCENClsgIDE0My41NzMyNTddIDM4YzljIGlzIDIzMzBjMDAwIQ0KWyAgMTQzLjU4MzQ3NF0g
MzhjOWQgaXMgMjMzMGIwMDAhDQpbICAxNDMuNTg1NzE0XSAzOGM5ZSBpcyAyMzMwYTAwMCEN
ClsgIDE0My41OTAyMDRdIDM4YzlmIGlzIDIzMzA5MDAwIQ0KWyAgMTQzLjU5MzkzM10gMzY1
ZTAgaXMgMjMzMDgwMDAhDQpbICAxNDMuNjAyNzQ4XSAzNjVlMSBpcyAyMzMwNzAwMCENClsg
IDE0My42MjY4ODNdIDM2NWUyIGlzIDIzMzA2MDAwIQ0KWyAgMTQzLjYzNDA1OF0gMzc1NDIg
aXMgMjMzMDUwMDAhDQpbICAxNDMuNjYxMDUzXSAzNjVlMyBpcyAyMzIwNDAwMCENClsgIDE0
My42NzI5NDJdIDM3NTQzIGlzIDIzMjAzMDAwIQ0KWyAgMTQzLjY4MjYzMV0gMzc1NDQgaXMg
MjMyMDIwMDAhDQpbICAxNDMuNjg1MDUwXSAzNjVlNCBpcyAyMzIwMTAwMCENClsgIDE0My42
OTA3NzBdIDM2NWU1IGlzIDIzMjAwMDAwIQ0KWyAgMTQzLjY5OTIzNl0gMzY1ZTYgaXMgMjMx
ZDUwMDAhDQpbICAxNDMuNzAyODEwXSAzNzU0NSBpcyAyMzFkNjAwMCENClsgIDE0My43MjYw
MzddIDM2NWU3IGlzIDIzMWQ3MDAwIQ0KWyAgMTQzLjczNDUyMF0gMzc1NDYgaXMgMjMxZDgw
MDAhDQpbICAxNDMuNzQxOTI4XSAzNjVlOCBpcyAyMzFkOTAwMCENClsgIDE0My43NDcyMzVd
IDM2NWU5IGlzIDIzMWRhMDAwIQ0KWyAgMTQzLjc2NjE1MV0gMzY1ZWEgaXMgMjMxZGIwMDAh
DQpbICAxNDMuNzY4NjM0XSAzNzU0NyBpcyAyMzFkYzAwMCENClsgIDE0My43NzUxMTVdIDM2
NWViIGlzIDIzMWRkMDAwIQ0KWyAgMTQzLjc4NTg4NV0gMzY1ZWMgaXMgMjMxZGUwMDAhDQpb
ICAxNDMuNzg4MzczXSAzNjVlZCBpcyAyMzFlNTAwMCENClsgIDE0My43OTIxMzddIDM2NWVl
IGlzIDIzMWZmMDAwIQ0KWyAgMTQzLjc5NTExMV0gMzY1ZWYgaXMgMjMxZjcwMDAhDQpbICAx
NDMuNzk3OTA3XSAzNmNhMCBpcyAyMzFmZTAwMCENClsgIDE0My44MDQ2MTFdIDM2Y2ExIGlz
IDIzMWZkMDAwIQ0KWyAgMTQzLjgxMjQ3NF0gMzZjYTIgaXMgMjMxZjAwMDAhDQpbICAxNDMu
ODIyNDQwXSAzNmNhMyBpcyAyMzFlZjAwMCENClsgIDE0My44MjUyMDddIDM3NTQ4IGlzIDIz
MWVlMDAwIQ0KWyAgMTQzLjgyNzcyOV0gMzZjYTQgaXMgMjMxZWMwMDAhDQpbICAxNDMuODMw
MTI3XSAzNmNhNSBpcyAyMzFlOTAwMCENClsgIDE0My44NDA3MzldIDM2Y2E3IGlzIDIzMWU4
MDAwIQ0KWyAgMTQzLjg1ODkxN10gMzZjYTggaXMgMjMxZWIwMDAhDQpbICAxNDMuODYyNjcz
XSAzNmNhNiBpcyAyMzFkZjAwMCENClsgIDE0My44NjU0NjRdIDM2Y2E5IGlzIDIzMWUwMDAw
IQ0KWyAgMTQzLjg2ODA4MF0gMzZjYWEgaXMgMjMxZTQwMDAhDQpbICAxNDMuODcxOTkzXSAz
NmNhYiBpcyAyMzFlYTAwMCENClsgIDE0My44NzQ0MTJdIDM2Y2FjIGlzIDIzMWYxMDAwIQ0K
WyAgMTQzLjg3Njc5OF0gMzZjYWQgaXMgMjMxZjIwMDAhDQpbICAxNDMuODgwNDEwXSAzNmNh
ZSBpcyAyMzFlNjAwMCENClsgIDE0My44ODM1MDldIDM2Y2FmIGlzIDIzMWU3MDAwIQ0KWyAg
MTQzLjg4NzM1Nl0gMzkxZDAgaXMgMjM0MjYwMDAhDQpbICAxNDMuOTAwOTY2XSAzOTFkMSBp
cyAyMzFmODAwMCENClsgIDE0My45MDMzMDZdIDM5MWQyIGlzIDIzMWY5MDAwIQ0KWyAgMTQz
LjkwNzI2Ml0gMzkxZDMgaXMgMjJhMTYwMDAhDQpbICAxNDMuOTEwNTU2XSAzOTFkNCBpcyAy
MzQzNTAwMCENClsgIDE0My45MTQ4ODFdIDM5MWQ1IGlzIDIyYTE1MDAwIQ0KWyAgMTQzLjkx
NzQ5NF0gMzkxZDYgaXMgMjMxZTMwMDAhDQpbICAxNDMuOTQwNjg4XSAzOTFkNyBpcyAyNDI5
YTAwMCENClsgIDE0My45NDMwMjldIDM3NTQ5IGlzIDIzNDM3MDAwIQ0KWyAgMTQzLjk1NzE1
MV0gMzkxZDggaXMgMjMxZjUwMDAhDQpbICAxNDMuOTU5NTI2XSAzOTFkOSBpcyAyMzFmNDAw
MCENClsgIDE0My45NjMxNjddIDM5MWRhIGlzIDIzMWYzMDAwIQ0KWyAgMTQzLjk2NTY3OV0g
MzkxZGIgaXMgMjMxZDQwMDAhDQpbICAxNDMuOTY4MTY2XSAzOTFkYyBpcyAyMzFkMzAwMCEN
ClsgIDE0My45NzgxNTZdIDM5MWRkIGlzIDIzMWQyMDAwIQ0KWyAgMTQzLjk4ODAyM10gMzkx
ZGUgaXMgMjMxZDEwMDAhDQpbICAxNDQuMDAwMjQ2XSAzOTFkZiBpcyAyMzFkMDAwMCENClsg
IDE0NC4wMDY4NzRdIDM3NGIwIGlzIDIzMWNmMDAwIQ0KWyAgMTQ0LjAwOTI2Nl0gMzc0YjEg
aXMgMjMxY2UwMDAhDQpbICAxNDQuMDExODE2XSAzNzRiMiBpcyAyMzFjZDAwMCENClsgIDE0
NC4wMjE1ODRdIDM3NGIzIGlzIDIzMWNjMDAwIQ0KWyAgMTQ0LjAyNDI0NV0gMzc0YjQgaXMg
MjMxY2IwMDAhDQpbICAxNDQuMDI2NTg4XSAzNzRiNSBpcyAyMzFjYTAwMCENClsgIDE0NC4w
MjkxMTZdIDM3NGI2IGlzIDIzMWM5MDAwIQ0KWyAgMTQ0LjAzMTU1N10gMzc0YjcgaXMgMjMx
YzgwMDAhDQpbICAxNDQuMDM0MDIwXSAzNzRiOCBpcyAyMzFjNzAwMCENClsgIDE0NC4wNDU5
MzddIDM3NGI5IGlzIDIzMWM2MDAwIQ0KWyAgMTQ0LjA0ODM4NF0gMzc0YmEgaXMgMjMxYzUw
MDAhDQpbICAxNDQuMDUyMTEwXSAzNzRiYiBpcyAyMzFjNDAwMCENClsgIDE0NC4wNTQ1Njhd
IDM3NGJjIGlzIDIzMWMzMDAwIQ0KWyAgMTQ0LjA2MjIzNV0gMzc0YmQgaXMgMjMxYzIwMDAh
DQpbICAxNDQuMDgxNDMzXSAzNzU0YSBpcyAyMzFjMTAwMCENClsgIDE0NC4wODU2MzRdIDM3
NTRiIGlzIDIzMWMwMDAwIQ0KWyAgMTQ0LjA5NDQ3N10gMzc0YmUgaXMgMjMxYmYwMDAhDQpb
ICAxNDQuMTExOTUwXSAzNzU0YyBpcyAyMzFiZTAwMCENClsgIDE0NC4xMjMzNDJdIDM3NGJm
IGlzIDIzMWIzMDAwIQ0KWyAgMTQ0LjEyNTQ1Ml0gMzkxODAgaXMgMjMxYjQwMDAhDQpbICAx
NDQuMTI3NDQwXSAzOTE4MSBpcyAyMzFiNTAwMCENClsgIDE0NC4xMjkzNTVdIDM5MTgyIGlz
IDIzMWI2MDAwIQ0KWyAgMTQ0LjEzMTIxMF0gMzkxODMgaXMgMjMxYjcwMDAhDQpbICAxNDQu
MTMzMDI5XSAzOTE4NCBpcyAyMzFiODAwMCENClsgIDE0NC4xMzQ4MjFdIDM5MTg1IGlzIDIz
MWI5MDAwIQ0KWyAgMTQ0LjEzNjU5OV0gMzkxODYgaXMgMjMxYmEwMDAhDQpbICAxNDQuMTM4
Mzc0XSAzOTE4NyBpcyAyMzFiYjAwMCENClsgIDE0NC4xNDAxNjBdIDM5MTg4IGlzIDIzMWJj
MDAwIQ0KWyAgMTQ0LjE0MTkxOV0gMzkxODkgaXMgMjMxYmQwMDAhDQpbICAxNDQuMTQ0MTc3
XSAzOGM0ZiBpcyAyMzE5MzAwMCENClsgIDE0NC4xNDU5ODNdIDM2NTcwIGlzIDIzMTk0MDAw
IQ0KWyAgMTQ0LjE0Nzc5N10gMzY1NzEgaXMgMjMxOTUwMDAhDQpbICAxNDQuMTQ5NTg4XSAz
NjU3MiBpcyAyMzE5NjAwMCENClsgIDE0NC4xNTEzNjldIDM2NTczIGlzIDIzMTk3MDAwIQ0K
WyAgMTQ0LjE1MzE1Nl0gMzY1NzQgaXMgMjMxOTgwMDAhDQpbICAxNDQuMTU0OTQxXSAzNjU3
NSBpcyAyMzE5OTAwMCENClsgIDE0NC4xNTY3NDRdIDM2NTc2IGlzIDIzMTlhMDAwIQ0KWyAg
MTQ0LjE1ODUwOF0gMzY1NzcgaXMgMjMxOWIwMDAhDQpbICAxNDQuMTYwMjg3XSAzNjU3OCBp
cyAyMzE5YzAwMCENClsgIDE0NC4xNjIwNjldIDM2NTc5IGlzIDIzMTlkMDAwIQ0KWyAgMTQ0
LjE2Mzg0OF0gMzY1N2EgaXMgMjMxODgwMDAhDQpbICAxNDQuMTY1NjI5XSAzNjU3YiBpcyAy
MzE4OTAwMCENClsgIDE0NC4xNjc0MDhdIDM2NTdjIGlzIDIzMThhMDAwIQ0KWyAgMTQ0LjE2
OTE4NV0gMzY1N2QgaXMgMjMxOGIwMDAhDQpbICAxNDQuMTcwOTU5XSAzNjU3ZSBpcyAyMzE4
YzAwMCENClsgIDE0NC4xNzI3MThdIDM2NTdmIGlzIDIzMThkMDAwIQ0KWyAgMTQ0LjE3NDQ5
Nl0gMzc2MTAgaXMgMjMxOGUwMDAhDQpbICAxNDQuMTc2MjY2XSAzNzYxMSBpcyAyMzE4ZjAw
MCENClsgIDE0NC4xNzgwMzldIDM3NjEyIGlzIDIzMTkwMDAwIQ0KWyAgMTQ0LjE3OTc2M10g
Mzc2MTMgaXMgMjMxOTEwMDAhDQpbICAxNDQuMTgxNDk5XSAzNzYxNCBpcyAyMzE5MjAwMCEN
ClsgIDE0NC4xODMyMDFdIDM3NjE2IGlzIDIzOGZlMDAwIQ0KWyAgMTQ0LjE4NDkzNV0gMzc2
MTcgaXMgMjM4ZmYwMDAhDQpbICAxNDQuMTg2NjY5XSAzNzYxOCBpcyAyMzkwMDAwMCENClsg
IDE0NC4xODg0MDhdIDM3NjE5IGlzIDIzOTAxMDAwIQ0KWyAgMTQ0LjE5MDE2M10gMzc2MWEg
aXMgMjM5MDIwMDAhDQpbICAxNDQuMTkxOTAwXSAzNzYxYiBpcyAyMzkwMzAwMCENClsgIDE0
NC4xOTM2NTFdIDM3NjFjIGlzIDIzOTA0MDAwIQ0KWyAgMTQ0LjE5NTQwM10gMzc2MWQgaXMg
MjMxODUwMDAhDQpbICAxNDQuMTk3MTU5XSAzNzYxZSBpcyAyMzE4NjAwMCENClsgIDE0NC4x
OTg5MTddIDM3NjFmIGlzIDIzMTg3MDAwIQ0KWyAgMTQ0LjIwMDY1MV0gMzkxOGEgaXMgMjMx
YTgwMDAhDQpbICAxNDQuMjAyNDAzXSAzOTE4YiBpcyAyMzFhOTAwMCENClsgIDE0NC4yMDQx
NTNdIDM5MThjIGlzIDIzMWFhMDAwIQ0KWyAgMTQ0LjIwNTg4M10gMzkxOGQgaXMgMjMxYWIw
MDAhDQpbICAxNDQuMjA3NjMxXSAzOTE4ZSBpcyAyMzFhYzAwMCENClsgIDE0NC4yMDkzNTBd
IDM5MThmIGlzIDIzMWFkMDAwIQ0KWyAgMTQ0LjIxMTEwMF0gMzhjNDAgaXMgMjMxYWUwMDAh
DQpbICAxNDQuMjEyODQyXSAzOGM0MSBpcyAyMzFhZjAwMCENClsgIDE0NC4yMTQ2MTNdIDM4
YzQyIGlzIDIzMWIwMDAwIQ0KWyAgMTQ0LjIxNjM1NF0gMzhjNDMgaXMgMjMxYjEwMDAhDQpb
ICAxNDQuMjE4MTExXSAzOGM0NCBpcyAyMzFiMjAwMCENClsgIDE0NC4yMTk4NjNdIDM4YzQ1
IGlzIDIzMTllMDAwIQ0KWyAgMTQ0LjIyMTYyMF0gMzhjNDYgaXMgMjMxOWYwMDAhDQpbICAx
NDQuMjIzMzk5XSAzOGM0NyBpcyAyMzFhMDAwMCENClsgIDE0NC4yMjUxNTJdIDM4YzQ4IGlz
IDIzMWExMDAwIQ0KWyAgMTQ0LjIyNjkxM10gMzhjNDkgaXMgMjMxYTIwMDAhDQpbICAxNDQu
MjI4Njc3XSAzOGM0YSBpcyAyMzFhMzAwMCENClsgIDE0NC4yMzA0MjFdIDM4YzRiIGlzIDIz
MWE0MDAwIQ0KWyAgMTQ0LjIzMjE4MF0gMzhjNGMgaXMgMjMxYTUwMDAhDQpbICAxNDQuMjMz
OTI4XSAzOGM0ZCBpcyAyMzFhNjAwMCENClsgIDE0NC4yMzU2ODBdIDM4YzRlIGlzIDIzMWE3
MDAwIQ0KWyAgMTQ0LjIzODc0M10gMzY1Y2IgaXMgMjM4ZTgwMDAhDQpbICAxNDQuMjQwNjAy
XSAzNjVjYyBpcyAyMzhlOTAwMCENClsgIDE0NC4yNDIzODVdIDM2NWNkIGlzIDIzOGVhMDAw
IQ0KWyAgMTQ0LjI0NDE3NV0gMzY1Y2UgaXMgMjM4ZWIwMDAhDQpbICAxNDQuMjQ1OTIzXSAz
NjVjZiBpcyAyMzhlYzAwMCENClsgIDE0NC4yNDc2NzZdIDM4Y2UwIGlzIDIzOGVkMDAwIQ0K
WyAgMTQ0LjI0OTQ2NV0gMzhjZTEgaXMgMjM4ZWUwMDAhDQpbICAxNDQuMjUxMjM1XSAzOGNl
MiBpcyAyMzhlZjAwMCENClsgIDE0NC4yNTI5OTBdIDM4Y2UzIGlzIDIzOGYwMDAwIQ0KWyAg
MTQ0LjI1NDc1NF0gMzhjZTQgaXMgMjM4ZjEwMDAhDQpbICAxNDQuMjU2NTE1XSAzOGNlNSBp
cyAyMzhmMjAwMCENClsgIDE0NC4yNTg3NDhdIDM4Y2U2IGlzIDIzOGRlMDAwIQ0KWyAgMTQ0
LjI2MDUyM10gMzhjZTcgaXMgMjM4ZGYwMDAhDQpbICAxNDQuMjYyMjU0XSAzOGNlOCBpcyAy
MzhlMDAwMCENClsgIDE0NC4yNjQwMTRdIDM4Y2U5IGlzIDIzOGUxMDAwIQ0KWyAgMTQ0LjI2
NTc2NF0gMzhjZWEgaXMgMjM4ZTIwMDAhDQpbICAxNDQuMjY3NTExXSAzOGNlYiBpcyAyMzhl
MzAwMCENClsgIDE0NC4yNjkyNzldIDM4Y2VjIGlzIDIzOGU0MDAwIQ0KWyAgMTQ0LjI3MTAw
OV0gMzhjZWQgaXMgMjM4ZTUwMDAhDQpbICAxNDQuMjcyNzEzXSAzOGNlZSBpcyAyMzhlNjAw
MCENClsgIDE0NC4yNzQ0NTJdIDM4Y2VmIGlzIDIzOGU3MDAwIQ0KWyAgMTQ0LjI3NjE1N10g
MzZmYWIgaXMgMjM4YzgwMDAhDQpbICAxNDQuMjc3OTA3XSAzNmZhYyBpcyAyMzhjOTAwMCEN
ClsgIDE0NC4yNzk2MTJdIDM2ZmFkIGlzIDIzOGNhMDAwIQ0KWyAgMTQ0LjI4MTM0NV0gMzZm
YWUgaXMgMjM4Y2IwMDAhDQpbICAxNDQuMjgzMDQ5XSAzNmZhZiBpcyAyMzhjYzAwMCENClsg
IDE0NC4yODQ3NjddIDM2ZmIwIGlzIDIzOGNkMDAwIQ0KWyAgMTQ0LjI4NjQ4OF0gMzZmYjEg
aXMgMjM4Y2UwMDAhDQpbICAxNDQuMjg4MjA1XSAzNmZiMiBpcyAyMzhjZjAwMCENClsgIDE0
NC4yODk5MjddIDM2ZmIzIGlzIDIzOGQwMDAwIQ0KWyAgMTQ0LjI5MTY0NF0gMzZmYjQgaXMg
MjM4ZDEwMDAhDQpbICAxNDQuMjkzMzUxXSAzNmZiNSBpcyAyMzhkMjAwMCENClsgIDE0NC4y
OTUwNjBdIDM2ZmEwIGlzIDIzOGQzMDAwIQ0KWyAgMTQ0LjI5Njc1M10gMzZmYTEgaXMgMjM4
ZDQwMDAhDQpbICAxNDQuMjk4NDQ4XSAzNmZhMiBpcyAyMzhkNTAwMCENClsgIDE0NC4zMDAx
NDZdIDM2ZmEzIGlzIDIzOGQ2MDAwIQ0KWyAgMTQ0LjMwMTgzN10gMzZmYTQgaXMgMjM4ZDcw
MDAhDQpbICAxNDQuMzAzNTQxXSAzNmZhNSBpcyAyMzhkODAwMCENClsgIDE0NC4zMDUyMTRd
IDM2ZmE2IGlzIDIzOGQ5MDAwIQ0KWyAgMTQ0LjMwNjkxNl0gMzZmYTcgaXMgMjM4ZGEwMDAh
DQpbICAxNDQuMzA4NTc3XSAzNmZhOCBpcyAyMzhkYjAwMCENClsgIDE0NC4zMTAyNjddIDM2
ZmE5IGlzIDIzOGRjMDAwIQ0KWyAgMTQ0LjMxMTkzMF0gMzZmYWEgaXMgMjM4ZGQwMDAhDQpb
ICAxNDQuMzEzNjAwXSAzNmZiNiBpcyAyMzhiZTAwMCENClsgIDE0NC4zMTUyNzJdIDM2ZmI3
IGlzIDIzOGJmMDAwIQ0KWyAgMTQ0LjMxNjkzNF0gMzZmYjggaXMgMjM4YzAwMDAhDQpbICAx
NDQuMzE4NjEwXSAzNmZiOSBpcyAyMzhjMTAwMCENClsgIDE0NC4zMjAyOTFdIDM2ZmJhIGlz
IDIzOGMyMDAwIQ0KWyAgMTQ0LjMyMTk2NF0gMzZmYmIgaXMgMjM4YzMwMDAhDQpbICAxNDQu
MzIzNjY3XSAzNmZiYyBpcyAyMzhjNDAwMCENClsgIDE0NC4zMjUzMzRdIDM2ZmJkIGlzIDIz
OGM1MDAwIQ0KWyAgMTQ0LjMyNzAzMF0gMzZmYmUgaXMgMjM4YzYwMDAhDQpbICAxNDQuMzI4
NjkyXSAzNmZiZiBpcyAyMzhjNzAwMCENClsgIDE0NC4zMzAzNDldIDM2NWMwIGlzIDIzOGYz
MDAwIQ0KWyAgMTQ0LjMzMjAzOF0gMzY1YzEgaXMgMjM4ZjQwMDAhDQpbICAxNDQuMzMzNzI1
XSAzNjVjMiBpcyAyMzhmNTAwMCENClsgIDE0NC4zMzU0MDZdIDM2NWMzIGlzIDIzOGY2MDAw
IQ0KWyAgMTQ0LjMzNzA5M10gMzY1YzQgaXMgMjM4ZjcwMDAhDQpbICAxNDQuMzM4NzYwXSAz
NjVjNSBpcyAyMzhmODAwMCENClsgIDE0NC4zNDA0NTddIDM2NWM2IGlzIDIzOGY5MDAwIQ0K
WyAgMTQ0LjM0MjEzMl0gMzY1YzcgaXMgMjM4ZmEwMDAhDQpbICAxNDQuMzQzODc0XSAzNjVj
OCBpcyAyMzhmYjAwMCENClsgIDE0NC4zNDU1MzVdIDM2NWM5IGlzIDIzOGZjMDAwIQ0KWyAg
MTQ0LjM0NzIxMl0gMzY1Y2EgaXMgMjM4ZmQwMDAhDQpbICAxNDQuMzU0MjE1XSAzODJkNyBp
cyAyMzhiZDAwMCENClsgIDE0NC4zNjY1NDVdIDM4Y2MwIGlzIDIzOGJjMDAwIQ0KWyAgMTQ0
LjM3NjUwM10gMzhjYzEgaXMgMjM4YmIwMDAhDQpbICAxNDQuMzg0MDA1XSAzOGNjMiBpcyAy
MzhiYTAwMCENClsgIDE0NC4zODYxMjFdIDM4Y2MzIGlzIDIzOGI5MDAwIQ0KWyAgMTQ0LjM4
ODM5MF0gMzhjYzQgaXMgMjM4YjgwMDAhDQpbICAxNDQuMzkwNjEwXSAzOGNjNSBpcyAyMzhi
NzAwMCENClsgIDE0NC4zOTI3MTNdIDM4Y2M2IGlzIDIzOGI2MDAwIQ0KWyAgMTQ0LjM5NDk5
Nl0gMzhjYzcgaXMgMjM4YjUwMDAhDQpbICAxNDQuMzk3MTExXSAzOGNjOCBpcyAyMzhiNDAw
MCENClsgIDE0NC4zOTkyMzBdIDM4Y2M5IGlzIDIzOGIzMDAwIQ0KWyAgMTQ0LjQwMTQ5Ml0g
MzhjY2EgaXMgMjM4YjIwMDAhDQpbICAxNDQuNDAzNjAzXSAzOGNjYiBpcyAyMzhiMTAwMCEN
ClsgIDE0NC40MDU2NzZdIDM4Y2NjIGlzIDIzOGIwMDAwIQ0KWyAgMTQ0LjQwNzgwNV0gMzc1
NGQgaXMgMjM4YWYwMDAhDQpbICAxNDQuNDA5OTA1XSAzOGNjZCBpcyAyMzhhZTAwMCENClsg
IDE0NC40MTIwNDFdIDM4Y2NmIGlzIDIzOGFkMDAwIQ0KWyAgMTQ0LjQxNzUxM10gMzhjZDAg
aXMgMjM4YWMwMDAhDQpbICAxNDQuNDI3MzExXSAzOGNkMSBpcyAyMzhhYjAwMCENClsgIDE0
NC40MzQ5MzldIDM2NjAzIGlzIDIzOGFhMDAwIQ0KWyAgMTQ0LjQ0MzQ1M10gMzY2MDQgaXMg
MjM4YTkwMDAhDQpbICAxNDQuNDQ1NTM0XSAzOGNkMiBpcyAyMzhhODAwMCENClsgIDE0NC40
NTUwNzddIDM4Y2QzIGlzIDIzOGE3MDAwIQ0KWyAgMTQ0LjQ1NzM0OV0gMzhjZDQgaXMgMjM4
YTYwMDAhDQpbICAxNDQuNDU5NTA3XSAzOGNkNSBpcyAyMzhhNTAwMCENClsgIDE0NC40NjE4
NDldIDM4Y2Q2IGlzIDIzOGE0MDAwIQ0KWyAgMTQ0LjQ2NDA5OF0gMzhjZDcgaXMgMjM4YTMw
MDAhDQpbICAxNDQuNDcxNTc5XSAzOGNkOCBpcyAyMzhhMjAwMCENClsgIDE0NC40NzY1MjJd
IDM4Y2Q5IGlzIDIzOGExMDAwIQ0KWyAgMTQ0LjQ5MjQ5OV0gMzhjZGEgaXMgMjM4YTAwMDAh
DQpbICAxNDQuNTA2NjI2XSAzNjYwNSBpcyAyMzg5ZjAwMCENClsgIDE0NC41MDg5MzRdIDM4
Y2RiIGlzIDIzODllMDAwIQ0KWyAgMTQ0LjUxNjU4OV0gMzhjZGMgaXMgMjM4OWQwMDAhDQpb
ICAxNDQuNTIzNDkwXSAzOGNkZCBpcyAyMzg5YzAwMCENClsgIDE0NC41MzcyNjBdIDM4Y2Rl
IGlzIDIzODliMDAwIQ0KWyAgMTQ0LjUzOTQ5Ml0gMzY2MDYgaXMgMjM4OWEwMDAhDQpbICAx
NDQuNTQzMjcwXSAzOGNkZiBpcyAyMzg5OTAwMCENClsgIDE0NC41NDU2MjFdIDM2NjAwIGlz
IDIzODk4MDAwIQ0KWyAgMTQ0LjU1MzI4Nl0gMzY2MDEgaXMgMjM4OTcwMDAhDQpbICAxNDQu
NTY4MTYwXSAzNjYwMiBpcyAyMzg5NjAwMCENClsgIDE0NC41NzIwMzBdIDM2NjIyIGlzIDIz
ODk1MDAwIQ0KWyAgMTQ0LjU3NDk1MV0gMzY2MjMgaXMgMjM4OTQwMDAhDQpbICAxNDQuNTk1
NTM3XSAzNjYyNCBpcyAyMzg5MzAwMCENClsgIDE0NC42MDE3MDhdIDM2NjA3IGlzIDIzODky
MDAwIQ0KWyAgMTQ0LjYwNDY5Nl0gMzY2MjUgaXMgMjM4OTEwMDAhDQpbICAxNDQuNjExMjAw
XSAzNjYyNiBpcyAyMzg5MDAwMCENClsgIDE0NC42MTc5MjVdIDM2NjI3IGlzIDIzODhmMDAw
IQ0KWyAgMTQ0LjYyNDY3NF0gMzY2MjggaXMgMjM4OGUwMDAhDQpbICAxNDQuNjI2OTg1XSAz
NjYyOSBpcyAyMzg4ZDAwMCENClsgIDE0NC42MjkyMjNdIDM2NjJhIGlzIDIzODhjMDAwIQ0K
WyAgMTQ0LjYzMTU1NF0gMzY2MDggaXMgMjM4OGIwMDAhDQpbICAxNDQuNjMzODI1XSAzNjYy
YiBpcyAyMzg4YTAwMCENClsgIDE0NC42MzYxMzRdIDM2NjA5IGlzIDIzODg5MDAwIQ0KWyAg
MTQ0LjYzODM5M10gMzY2MmMgaXMgMjM4ODgwMDAhDQpbICAxNDQuNjQwNjcyXSAzNjYwYSBp
cyAyMzg4NzAwMCENClsgIDE0NC42NDI5NzNdIDM2NjBiIGlzIDIzODg2MDAwIQ0KWyAgMTQ0
LjY0NTMyNl0gMzY2MmQgaXMgMjM4ODUwMDAhDQpbICAxNDQuNjQ3Njg5XSAzNjYyZSBpcyAy
NDkwNDAwMCENClsgIDE0NC42NDk5NzldIDM2NjJmIGlzIDI0OTAzMDAwIQ0KWyAgMTQ0LjY1
MjI5OF0gMzY2MzAgaXMgMjQ5MDIwMDAhDQpbICAxNDQuNjU0NjM0XSAzNjYzMSBpcyAyNDkw
MTAwMCENClsgIDE0NC42NTY5MjZdIDM2NjMyIGlzIDI0OTAwMDAwIQ0KWyAgMTQ0LjY1OTE0
Nl0gMzY2MzMgaXMgMjQ4ZmYwMDAhDQpbICAxNDQuNjYxNDI1XSAzNjYwYyBpcyAyNDhmZTAw
MCENClsgIDE0NC43MDI2NDJdIDM2NjM0IGlzIDI0OGZkMDAwIQ0KWyAgMTQ0LjcwNTIyOF0g
MzY2MGQgaXMgMjQ4YmUwMDAhDQpbICAxNDQuNzIwMTAxXSAzNjYwZSBpcyAyNDhiZjAwMCEN
ClsgIDE0NC43MjI1MDZdIDM2NjBmIGlzIDI0OGMwMDAwIQ0KWyAgMTQ0LjcyNDc0OF0gMzY2
MTAgaXMgMjQ4YzEwMDAhDQpbICAxNDQuNzQxMTQxXSAzNjYzNSBpcyAyNDhjMjAwMCENClsg
IDE0NC43NTU1MDddIDM2NjExIGlzIDI0OGMzMDAwIQ0KWyAgMTQ0Ljc3OTAzNF0gMzY2MzYg
aXMgMjQ4YzQwMDAhDQpbICAxNDQuNzgxNDI3XSAzNjYxMiBpcyAyNDhjODAwMCENClsgIDE0
NC43ODMyNzJdIDM2NjM3IGlzIDI0OGM3MDAwIQ0KWyAgMTQ0Ljc4NTE0MV0gMzY2MzggaXMg
MjQ4YzYwMDAhDQpbICAxNDQuNzg3MDY1XSAzNjYzOSBpcyAyNDhjNTAwMCENClsgIDE0NC44
MjcwMTFdIDM2NjNhIGlzIDI0OGM5MDAwIQ0KWyAgMTQ0Ljg2NzM0N10gMzY2M2IgaXMgMjQ4
Y2EwMDAhDQpbICAxNDQuODc2ODQwXSAzNjYzYyBpcyAyNDhjYjAwMCENClsgIDE0NC44ODU0
NjddIDM3OGNjIGlzIDI0OGNjMDAwIQ0KWyAgMTQ0Ljg5MDI5N10gMzY2M2QgaXMgMjQ4Y2Qw
MDAhDQpbICAxNDQuOTAwMjM3XSAzNjYzZSBpcyAyNDhjZTAwMCENClsgIDE0NC45MDMzMDdd
IDM2NjNmIGlzIDI0OGNmMDAwIQ0KWyAgMTQ0LjkwNTY3Nl0gMzY2NDAgaXMgMjQ4ZDAwMDAh
DQpbICAxNDQuOTE0MDcxXSAzNjY0MSBpcyAyNDhkMTAwMCENClsgIDE0NC45MjUwNzNdIDM2
NjQyIGlzIDI0OGQyMDAwIQ0KWyAgMTQ0LjkzMDU5OF0gMzY2NDMgaXMgMjQ4ZDMwMDAhDQpb
ICAxNDQuOTMyNzk2XSAzNjY0NCBpcyAyNDhkNDAwMCENClsgIDE0NC45MzY5NDZdIDM2NjQ1
IGlzIDI0OGQ1MDAwIQ0KWyAgMTQ0Ljk0NzExNl0gMzY2NDYgaXMgMjQ4ZDYwMDAhDQpbICAx
NDQuOTU0NTg4XSAzOTNlZSBpcyAyNDhkNzAwMCENClsgIDE0NC45NjA2NDNdIDM2NjQ4IGlz
IDI0OGQ4MDAwIQ0KWyAgMTQ0Ljk4MjEyOV0gMzY2NDkgaXMgMjQ4ZDkwMDAhDQpbICAxNDQu
OTg0NDgzXSAzNjYxMyBpcyAyNDhlODAwMCENClsgIDE0NC45ODYzMDddIDM2NjRhIGlzIDI0
OGY3MDAwIQ0KWyAgMTQ0Ljk4ODEzOF0gMzY2NGIgaXMgMjQ4ZGIwMDAhDQpbICAxNDQuOTg5
OTUyXSAzNjY0YyBpcyAyNDhkYTAwMCENClsgIDE0NS4wMDQ2MjNdIDM2NjE0IGlzIDI0OGU5
MDAwIQ0KWyAgMTQ1LjAxNTI3OF0gMzY2MTUgaXMgMjQ4ZTcwMDAhDQpbICAxNDUuMDE3NDk1
XSAzNjY0ZCBpcyAyNDhlNjAwMCENClsgIDE0NS4wMTk3MTBdIDM2NjRlIGlzIDI0OGVjMDAw
IQ0KWyAgMTQ1LjAyMjEwNV0gMzY2NGYgaXMgMjQ4ZWQwMDAhDQpbICAxNDUuMDI0MzkwXSAz
NjY1MCBpcyAyNDhlZTAwMCENClsgIDE0NS4wMzQyNDVdIDM2NjUxIGlzIDI0OGVmMDAwIQ0K
WyAgMTQ1LjAzNjQ0Ml0gMzY2NTIgaXMgMjQ4ZjEwMDAhDQpbICAxNDUuMDM4Nzk0XSAzNjY1
NCBpcyAyNDhmMzAwMCENClsgIDE0NS4wNDA5NzZdIDM2NjU1IGlzIDI0OGY0MDAwIQ0KWyAg
MTQ1LjA0MzE2MV0gMzY2NTYgaXMgMjQ4ZjIwMDAhDQpbICAxNDUuMDQ1NDk5XSAzNjY1NyBp
cyAyNDhkYzAwMCENClsgIDE0NS4wNDc4MDJdIDM2NjU4IGlzIDI0OGZjMDAwIQ0KWyAgMTQ1
LjA1NDYzNF0gMzY2NTkgaXMgMjQ4ZjgwMDAhDQpbICAxNDUuMDcwMzg3XSAzNjY1YSBpcyAy
NDhlYjAwMCENClsgIDE0NS4wNzcwNTldIDM2NjViIGlzIDI0OGVhMDAwIQ0KWyAgMTQ1LjA3
OTg5Nl0gMzY2NWMgaXMgMjQ4ZjYwMDAhDQpbICAxNDUuMDg0NDkyXSAzNjY1ZCBpcyAyNDhm
NTAwMCENClsgIDE0NS4wOTM3MjFdIDM2NjVlIGlzIDIzMWVkMDAwIQ0KWyAgMTQ1LjEwMzE0
OF0gMzY2NWYgaXMgMjQ4ZTEwMDAhDQpbICAxNDUuMTA1NDA1XSAzNjY2MCBpcyAyNDhlMjAw
MCENClsgIDE0NS4xMDg1MTJdIDM2NjYxIGlzIDI0M2I0MDAwIQ0KWyAgMTQ1LjExOTkwMF0g
MzY2NjIgaXMgMjMxZmEwMDAhDQpbICAxNDUuMTI3MzQ3XSAzNjYxNiBpcyAyNDI2YzAwMCEN
ClsgIDE0NS4xMzE1ODBdIDM2NjYzIGlzIDI0OGY5MDAwIQ0KWyAgMTQ1LjE0MzA2NF0gMzY2
NjQgaXMgMjMxZmMwMDAhDQpbICAxNDUuMTQ5MDYwXSAzNjY2NSBpcyAyMzFmYjAwMCENClsg
IDE0NS4xNTg2MDhdIDM2NjY2IGlzIDI0OGJkMDAwIQ0KWyAgMTQ1LjE2ODQ0MF0gMzY2Njcg
aXMgMjQ4ZTAwMDAhDQpbICAxNDUuMTc3NzE5XSAzNjY2OCBpcyAyNDhkZjAwMCENClsgIDE0
NS4xODE0NjBdIDM2NjY5IGlzIDI0OGRlMDAwIQ0KWyAgMTQ1LjE5MDUwN10gMzY2NmEgaXMg
MjQ4ZGQwMDAhDQpbICAxNDUuMTk3NzI5XSAzNjY2YiBpcyAyNDhiYzAwMCENClsgIDE0NS4y
MDAxODFdIDM2NjZjIGlzIDI0OGJiMDAwIQ0KWyAgMTQ1LjIwMjY4M10gMzY2NmQgaXMgMjQ4
YmEwMDAhDQpbICAxNDUuMjA5MDE5XSAzNjY2ZSBpcyAyNDhiOTAwMCENClsgIDE0NS4yMTEy
OTRdIDM2NjE3IGlzIDI0OGI4MDAwIQ0KWyAgMTQ1LjIxMzYwNl0gMzY2MTggaXMgMjQ4Yjcw
MDAhDQpbICAxNDUuMjE3ODE2XSAzNjY2ZiBpcyAyNDhiNjAwMCENClsgIDE0NS4yMjIzOTRd
IDM2NjE5IGlzIDI0OGI1MDAwIQ0KWyAgMTQ1LjIzNzQ2M10gMzY2NzAgaXMgMjQ4YjQwMDAh
DQpbICAxNDUuMjQ1NjEzXSAzNjY3MSBpcyAyNDhiMzAwMCENClsgIDE0NS4yNjAxOTNdIDM2
NjcyIGlzIDI0OGIyMDAwIQ0KWyAgMTQ1LjI4MTM3N10gMzY2NzMgaXMgMjQ4YjEwMDAhDQpb
ICAxNDUuMjgzNjA3XSAzNjYxYSBpcyAyNDhiMDAwMCENClsgIDE0NS4yODYwMDNdIDM2Njc0
IGlzIDI0OGFmMDAwIQ0KWyAgMTQ1LjI4ODI5MF0gMzY2MWIgaXMgMjQ4YWUwMDAhDQpbICAx
NDUuMjkwNTg4XSAzNjY3NSBpcyAyNDhhZDAwMCENClsgIDE0NS4yOTI4OThdIDM2NjFjIGlz
IDI0OGFjMDAwIQ0KWyAgMTQ1LjI5NTE4N10gMzY2NzYgaXMgMjQ4YWIwMDAhDQpbICAxNDUu
MzAwOTI0XSAzNjYxZCBpcyAyNDhhYTAwMCENClsgIDE0NS4zMDMyMDVdIDM2NjFlIGlzIDI0
OGE5MDAwIQ0KWyAgMTQ1LjMxNDg4NF0gMzY2NzcgaXMgMjQ4YTgwMDAhDQpbICAxNDUuMzMw
MjczXSAzNjYxZiBpcyAyNDhhNzAwMCENClsgIDE0NS4zMzI1MjddIDM2NjIwIGlzIDI0OGE2
MDAwIQ0KWyAgMTQ1LjMzNjU0Nl0gMzY2NzggaXMgMjQ4YTUwMDAhDQpbICAxNDUuMzQwMjM0
XSAzNjYyMSBpcyAyNDhhNDAwMCENClsgIDE0NS4zNDMxNThdIDM2NjdmIGlzIDI0OGEzMDAw
IQ0KWyAgMTQ1LjM0NjgyNV0gMzY2NzkgaXMgMjQ4YTIwMDAhDQpbICAxNDUuMzQ5MDQzXSAz
NjY4MCBpcyAyNDhhMTAwMCENClsgIDE0NS4zNTYyOTBdIDM2NjdhIGlzIDI0OGEwMDAwIQ0K
WyAgMTQ1LjM2Njc3MF0gMzY2ODEgaXMgMjQ4OWYwMDAhDQpbICAxNDUuMzcwNDg4XSAzNjY4
MiBpcyAyNDg5ZTAwMCENClsgIDE0NS4zNzc0NDhdIDM2NjgzIGlzIDI0ODlkMDAwIQ0KWyAg
MTQ1LjM4MDgyMV0gMzY2N2IgaXMgMjQ4OWMwMDAhDQpbICAxNDUuMzkxMjIyXSAzNjY3YyBp
cyAyNDg5YjAwMCENClsgIDE0NS4zOTUwNjhdIDM2NjdkIGlzIDI0ODlhMDAwIQ0KWyAgMTQ1
LjQwODQwMV0gMzY2N2UgaXMgMjQ4OTkwMDAhDQpbICAxNDUuNDExNzQwXSAzNjY4NCBpcyAy
NDg5ODAwMCENClsgIDE0NS40MTYyODRdIDM2NjllIGlzIDI0ODk3MDAwIQ0KWyAgMTQ1LjQx
ODk4OV0gMzY2OWYgaXMgMjQ4OTYwMDAhDQpbICAxNDUuNDI2NTEzXSAzNjZhMCBpcyAyNDg5
NTAwMCENClsgIDE0NS40MzEwNzBdIDM2NmExIGlzIDI0ODk0MDAwIQ0KWyAgMTQ1LjQzNTMx
Nl0gMzY2YTIgaXMgMjQ4OTMwMDAhDQpbICAxNDUuNDM4NjUzXSAzNjZhMyBpcyAyNDg5MjAw
MCENClsgIDE0NS40NDEyMTBdIDM2NmE0IGlzIDI0ODkxMDAwIQ0KWyAgMTQ1LjQ0NDQ1N10g
MzY2YTYgaXMgMjQ4OTAwMDAhDQpbICAxNDUuNDUwMjU2XSAzNjZhNyBpcyAyNDg4ZjAwMCEN
ClsgIDE0NS40NTc4MjJdIDM2NmE4IGlzIDI0ODhlMDAwIQ0KWyAgMTQ1LjQ4MjE2NV0gMzY2
YTkgaXMgMjQ4OGQwMDAhDQpbICAxNDUuNDg0NzI2XSAzNjY4NSBpcyAyNDg4OTAwMCENClsg
IDE0NS40ODY1MjFdIDM2NmFhIGlzIDI0ODhhMDAwIQ0KWyAgMTQ1LjQ4ODMyMF0gMzY2YWIg
aXMgMjQ4OGIwMDAhDQpbICAxNDUuNDkwMTAwXSAzNjZhYyBpcyAyNDg4YzAwMCENClsgIDE0
NS41MDkxODddIDM2NmFkIGlzIDI0ODg4MDAwIQ0KWyAgMTQ1LjUxNzYwOF0gMzY2ODYgaXMg
MjQ4ODcwMDAhDQpbICAxNDUuNTI4MDIyXSAzNjZhZSBpcyAyNDg4NjAwMCENClsgIDE0NS41
MzIwMDldIDM2NmFmIGlzIDI0ODg1MDAwIQ0KWyAgMTQ1LjU0MDgxMl0gMzY2YjAgaXMgMjQ4
ODQwMDAhDQpbICAxNDUuNTUzMDQyXSAzNjZiMSBpcyAyNDg4MzAwMCENClsgIDE0NS41NjM1
MDRdIDM2NmIyIGlzIDI0ODgyMDAwIQ0KWyAgMTQ1LjU2NzYzNF0gMzY2YjMgaXMgMjQ4ODEw
MDAhDQpbICAxNDUuNTc1MjM0XSAzNjZiNCBpcyAyNDg4MDAwMCENClsgIDE0NS41NzkwNDNd
IDM2NmI1IGlzIDI0ODdmMDAwIQ0KWyAgMTQ1LjU5NDkyNF0gMzY2YjYgaXMgMjQ4N2UwMDAh
DQpbICAxNDUuNTk3MDg3XSAzNjY4NyBpcyAyNDg3ZDAwMCENClsgIDE0NS41OTkyMTZdIDM2
NmI3IGlzIDI0ODdjMDAwIQ0KWyAgMTQ1LjYxNDg1N10gMzY2YjggaXMgMjQ4N2IwMDAhDQpb
ICAxNDUuNjIxNDg1XSAzNjZiOSBpcyAyNDg3YTAwMCENClsgIDE0NS42MjUzNTZdIDM2NmJh
IGlzIDI0ODc5MDAwIQ0KWyAgMTQ1LjYzMDc5NF0gMzY2YmIgaXMgMjQ4NzgwMDAhDQpbICAx
NDUuNjQzNTgxXSAzNjZiYyBpcyAyNDg3NzAwMCENClsgIDE0NS42NDc5OTZdIDM2NmJkIGlz
IDI0ODc2MDAwIQ0KWyAgMTQ1LjY1MTE4M10gMzY2YmUgaXMgMjQ4NzUwMDAhDQpbICAxNDUu
NjY2MDMyXSAzNjZiZiBpcyAyNDg3NDAwMCENClsgIDE0NS42Njg1OTFdIDM2Njg4IGlzIDI0
ODczMDAwIQ0KWyAgMTQ1LjY3MTY1Nl0gMzY2YzAgaXMgMjQ4NzIwMDAhDQpbICAxNDUuNjcz
OTE2XSAzNjZjMSBpcyAyNDg3MTAwMCENClsgIDE0NS42NzYwNTNdIDM2NmMyIGlzIDI0ODcw
MDAwIQ0KWyAgMTQ1LjY3OTg5OV0gMzY2YzMgaXMgMjQ4NmYwMDAhDQpbICAxNDUuNjgyMTM3
XSAzNjZjNCBpcyAyNDg2ZTAwMCENClsgIDE0NS42ODUyMjFdIDM2NmM1IGlzIDI0ODZkMDAw
IQ0KWyAgMTQ1LjY4Nzk2MF0gMzY2YzYgaXMgMjQ4NmMwMDAhDQpbICAxNDUuNjkxNDA0XSAz
NjZjNyBpcyAyNDg2YjAwMCENClsgIDE0NS42OTQ2MzJdIDM2NmM4IGlzIDI0ODZhMDAwIQ0K
WyAgMTQ1LjY5NzM3Ml0gMzY2YzkgaXMgMjQ4NjkwMDAhDQpbICAxNDUuNzAwNzA5XSAzNjZj
YSBpcyAyNDg2ODAwMCENClsgIDE0NS43MDI4MzldIDM2Njg5IGlzIDI0ODY3MDAwIQ0KWyAg
MTQ1LjcwNTEyMl0gMzY2Y2IgaXMgMjQ4NjYwMDAhDQpbICAxNDUuNzE4NzI3XSAzNjZjYyBp
cyAyNDg2NTAwMCENClsgIDE0NS43MjA5NTJdIDM2NjhhIGlzIDI0ODQ0MDAwIQ0KWyAgMTQ1
LjcyNTYxNV0gMzY2Y2QgaXMgMjQ4NDUwMDAhDQpbICAxNDUuNzI3ODUxXSAzNjZjZSBpcyAy
NDg0YzAwMCENClsgIDE0NS43MzAwMzBdIDM2NmNmIGlzIDI0ODViMDAwIQ0KWyAgMTQ1Ljcz
NDEzNF0gMzY2ZDAgaXMgMjQ4NWEwMDAhDQpbICAxNDUuNzM3NzQ5XSAzNjZkMSBpcyAyNDg1
YzAwMCENClsgIDE0NS43Mzk5MDNdIDM2NmQyIGlzIDI0ODVkMDAwIQ0KWyAgMTQ1Ljc0Mjky
MF0gMzY2ZDMgaXMgMjQ4NTcwMDAhDQpbICAxNDUuNzQ1MTU0XSAzNjZkNCBpcyAyNDg1NjAw
MCENClsgIDE0NS43NDc0MDhdIDM2NmQ1IGlzIDI0ODU1MDAwIQ0KWyAgMTQ1Ljc1NTk0OF0g
MzY2ZDYgaXMgMjQ4NTQwMDAhDQpbICAxNDUuNzU4NjExXSAzNjZkNyBpcyAyNDg1MjAwMCEN
ClsgIDE0NS43NjE3NjBdIDM2NmQ4IGlzIDI0ODU4MDAwIQ0KWyAgMTQ1Ljc2Mzk5NV0gMzY2
ZDkgaXMgMjQ4NGYwMDAhDQpbICAxNDUuNzY5MTkwXSAzNjZkYSBpcyAyNDg1MTAwMCENClsg
IDE0NS43NzE0MzNdIDM2NmRiIGlzIDI0ODQ2MDAwIQ0KWyAgMTQ1Ljc3MzYwMl0gMzY2ZGMg
aXMgMjQ4NDcwMDAhDQpbICAxNDUuNzc1ODM5XSAzNjZkZCBpcyAyNDg1MDAwMCENClsgIDE0
NS43Nzg4NzZdIDM2NjhiIGlzIDI0ODRiMDAwIQ0KWyAgMTQ1Ljc4MTAxNV0gMzY2ZGUgaXMg
MjQ4NTkwMDAhDQpbICAxNDUuNzk3NDMyXSAzNjY4YyBpcyAyNDg0ZDAwMCENClsgIDE0NS43
OTk1ODhdIDM2NjhkIGlzIDI0ODRlMDAwIQ0KWyAgMTQ1LjgwMjc1M10gMzY2ZGYgaXMgMjQ4
ZjAwMDAhDQpbICAxNDUuODA1MDk4XSAzNjZlMCBpcyAyNDg2MjAwMCENClsgIDE0NS44MDg0
NjldIDM2NmUxIGlzIDI0ODYxMDAwIQ0KWyAgMTQ1LjgxMjc5OF0gMzY2ZTIgaXMgMjQzOGQw
MDAhDQpbICAxNDUuODE1MTE0XSAzNjZlMyBpcyAyNDhlMzAwMCENClsgIDE0NS44MTg5Njld
IDM2NmU0IGlzIDI0NGM5MDAwIQ0KWyAgMTQ1LjgyMTI5Nl0gMzY2ZTUgaXMgMjQ4NGEwMDAh
DQpbICAxNDUuODIzNTY1XSAzNjZlNiBpcyAyNDRjMjAwMCENClsgIDE0NS44MjkxODRdIDM2
NmU3IGlzIDI0ODQzMDAwIQ0KWyAgMTQ1LjgzMjY4MV0gMzY2ZTggaXMgMjQ4NjQwMDAhDQpb
ICAxNDUuODM5MDU5XSAzNjY4ZSBpcyAyNDg2MzAwMCENClsgIDE0NS44NDEzMTVdIDM2Njhm
IGlzIDI0ODQyMDAwIQ0KWyAgMTQ1Ljg0NDAzMF0gMzY2OTAgaXMgMjQ4NDEwMDAhDQpbICAx
NDUuODQ3MzA4XSAzNjZlOSBpcyAyNDg0MDAwMCENClsgIDE0NS44NDk1NjJdIDM2NmVhIGlz
IDI0ODNmMDAwIQ0KWyAgMTQ1Ljg1MjA5MV0gMzY2ZWIgaXMgMjQ4M2UwMDAhDQpbICAxNDUu
ODU0NDc3XSAzNjZlYyBpcyAyNDgzZDAwMCENClsgIDE0NS44NTc4OTVdIDM2NmVkIGlzIDI0
ODNjMDAwIQ0KWyAgMTQ1Ljg2MDE4M10gMzY2ZWUgaXMgMjQ4M2IwMDAhDQpbICAxNDUuODY0
MDI0XSAzWyAgMTQ3Ljk5MzU3M10gMzM0ZTIgaXMgMjQ4NWUwMDAhDQpbICAxNDcuOTk3NzE2
XSAzMzRlMyBpcyAyNDczMTAwMCENClsgIDE0OC4wMDE5ODddIDMzNGU0IGlzIDI0NjUyMDAw
IQ0KWyAgMTQ4LjAwNDQxMV0gMzM0ZTUgaXMgMjQ2NTEwMDAhDQpbICAxNDguMDA2ODY4XSAz
MzRlNiBpcyAyNDY1MDAwMCENClsgIDE0OC4wMTcwNzBdIDMzNGU3IGlzIDI0NjRmMDAwIQ0K
WyAgMTQ4LjAyMDIwNl0gMzM0ZTggaXMgMjQ2MzAwMDAhDQpbICAxNDguMDIyNzUxXSAzMzRl
OSBpcyAyNDYyZjAwMCENClsgIDE0OC4wMzMzNjFdIDM2N2FjIGlzIDI0NjJlMDAwIQ0KWyAg
MTQ4LjAzNjYzMF0gMzM0ZWEgaXMgMjQ2MmQwMDAhDQpbICAxNDguMDM5MjQyXSAzNjdhZCBp
cyAyNDYyYzAwMCENClsgIDE0OC4wNDIxMjVdIDM2N2FlIGlzIDI0NjJiMDAwIQ0KWyAgMTQ4
LjA0NDU4Ml0gMzY3YWYgaXMgMjQ2MmEwMDAhDQpbICAxNDguMDQ3ODYzXSAzNjdiMCBpcyAy
NDYyOTAwMCENClsgIDE0OC4wNTAzNjldIDMzNGViIGlzIDI0NjI4MDAwIQ0KWyAgMTQ4LjA1
Mjg2Ml0gMzM0ZWMgaXMgMjQ2MjcwMDAhDQpbICAxNDguMDU2Mjg3XSAzMzRlZCBpcyAyNDYy
NjAwMCENClsgIDE0OC4wNTg5OTBdIDMzNGVlIGlzIDI0NjI1MDAwIQ0KWyAgMTQ4LjA2MTQ0
OV0gMzM0ZWYgaXMgMjQ2MjQwMDAhDQpbICAxNDguMDY2MDYwXSAzMzRmMCBpcyAyNDYyMzAw
MCENClsgIDE0OC4wNjg1MDBdIDMzNGYxIGlzIDI0NjIyMDAwIQ0KWyAgMTQ4LjA3MDkyMl0g
MzM0ZjIgaXMgMjQ2MjEwMDAhDQpbICAxNDguMDgxMzIyXSAzMzRmMyBpcyAyNDYyMDAwMCEN
ClsgIDE0OC4wODU4NzNdIDMzNGY0IGlzIDI0NjFmMDAwIQ0KWyAgMTQ4LjA5MzEwOF0gMzM0
ZjUgaXMgMjQ2MWUwMDAhDQpbICAxNDguMDk5MzM3XSAzNjdiMSBpcyAyNDYxZDAwMCENClsg
IDE0OC4xMTMxMDVdIDMzNGY2IGlzIDI0NjFjMDAwIQ0KWyAgMTQ4LjEyNzI3OF0gMzY3YjIg
aXMgMjQ2MWIwMDAhDQpbICAxNDguMTI5Njg1XSAzNjdiMyBpcyAyNDYxYTAwMCENClsgIDE0
OC4xNDAwMDddIDMzNGY3IGlzIDI0NjE5MDAwIQ0KWyAgMTQ4LjE0NzI3OF0gMzY3YjQgaXMg
MjQ2MTgwMDAhDQpbICAxNDguMTU3NDg5XSAzMzUwMCBpcyAyNDYxNzAwMCENClsgIDE0OC4x
NjQwMjldIDMzNGY4IGlzIDI0NjE2MDAwIQ0KWyAgMTQ4LjE3MTk2MV0gMzM0ZjkgaXMgMjQ2
MTUwMDAhDQpbICAxNDguMTc2Njk3XSAzMzRmYSBpcyAyNDYxNDAwMCENClsgIDE0OC4xODY4
MzddIDMzNGZiIGlzIDI0NjEzMDAwIQ0KWyAgMTQ4LjE5NDAxNF0gMzM0ZmMgaXMgMjQ2MGIw
MDAhDQpbICAxNDguMTk1OTI3XSAzMzUwMSBpcyAyNDYwYzAwMCENClsgIDE0OC4xOTc4MzNd
IDMzNTAyIGlzIDI0NjBkMDAwIQ0KWyAgMTQ4LjE5OTcxMF0gMzM1MDMgaXMgMjQ2MGUwMDAh
DQpbICAxNDguMjAxNjExXSAzMzUwNCBpcyAyNDYwZjAwMCENClsgIDE0OC4yMDM0NzldIDMz
NTA1IGlzIDI0NjEwMDAwIQ0KWyAgMTQ4LjIwNTMzM10gMzM1MDYgaXMgMjQ2MTEwMDAhDQpb
ICAxNDguMjA3MTgzXSAzMzUwNyBpcyAyNDYxMjAwMCENClsgIDE0OC4yMTUyMDZdIDMzNTA4
IGlzIDI0NjBhMDAwIQ0KWyAgMTQ4LjIxOTYxNV0gMzM0ZmQgaXMgMjQ2MDkwMDAhDQpbICAx
NDguMjIyOTIxXSAzMzUyOCBpcyAyNDVmMzAwMCENClsgIDE0OC4yMjQ4NDNdIDMzNTI5IGlz
IDI0NWY0MDAwIQ0KWyAgMTQ4LjIyNjczOF0gMzM1MmEgaXMgMjQ1ZjUwMDAhDQpbICAxNDgu
MjI4NTk4XSAzMzUyYiBpcyAyNDVmNjAwMCENClsgIDE0OC4yMzA0ODVdIDMzNTJjIGlzIDI0
NWY3MDAwIQ0KWyAgMTQ4LjIzMjMzNV0gMzM1MmQgaXMgMjQ1ZjgwMDAhDQpbICAxNDguMjM0
MjE4XSAzMzUyZSBpcyAyNDVmOTAwMCENClsgIDE0OC4yMzYwNjFdIDMzNTJmIGlzIDI0NWZh
MDAwIQ0KWyAgMTQ4LjIzNzk0NF0gMzM1MzAgaXMgMjQ1ZmIwMDAhDQpbICAxNDguMjM5Nzkz
XSAzMzUzMSBpcyAyNDVmYzAwMCENClsgIDE0OC4yNDE2NzZdIDMzNTMyIGlzIDI0NWZkMDAw
IQ0KWyAgMTQ4LjI0NDA4N10gMzM1MzQgaXMgMjQ1ZTkwMDAhDQpbICAxNDguMjQ1OTE3XSAz
MzUzNSBpcyAyNDVlYTAwMCENClsgIDE0OC4yNDc3MjVdIDMzNTM2IGlzIDI0NWViMDAwIQ0K
WyAgMTQ4LjI0OTU1Nl0gMzM1MzcgaXMgMjQ1ZWMwMDAhDQpbICAxNDguMjUxMzU1XSAzMzUz
OCBpcyAyNDVlZDAwMCENClsgIDE0OC4yNTMwOTddIDMzNTM5IGlzIDI0NWVlMDAwIQ0KWyAg
MTQ4LjI1NDg1OV0gMzM1M2EgaXMgMjQ1ZWYwMDAhDQpbICAxNDguMjU2NTY5XSAzMzUzYiBp
cyAyNDVmMDAwMCENClsgIDE0OC4yNTgzMDddIDMzNTNjIGlzIDI0NWYxMDAwIQ0KWyAgMTQ4
LjI2MDAxMl0gMzM1M2QgaXMgMjQ1ZjIwMDAhDQpbICAxNDguMjYxNzQ2XSAzMzUzZiBpcyAy
NDVkYzAwMCENClsgIDE0OC4yNjM0OTRdIDMzNTQwIGlzIDI0NWRkMDAwIQ0KWyAgMTQ4LjI2
NTE5OF0gMzM1NDEgaXMgMjQ1ZGUwMDAhDQpbICAxNDguMjY2OTMxXSAzMzU0MiBpcyAyNDVk
ZjAwMCENClsgIDE0OC4yNjg2MzJdIDMzNTQzIGlzIDI0NWUwMDAwIQ0KWyAgMTQ4LjI3MDM3
OV0gMzM1NDQgaXMgMjQ1ZTEwMDAhDQpbICAxNDguMjcyMDg1XSAzMzU0NSBpcyAyNDVlMjAw
MCENClsgIDE0OC4yNzM3ODldIDMzNTQ2IGlzIDI0NWUzMDAwIQ0KWyAgMTQ4LjI3NTQ5Nl0g
MzM1NDcgaXMgMjQ1ZTQwMDAhDQpbICAxNDguMjc3MTg4XSAzMzU0OCBpcyAyNDVlNTAwMCEN
ClsgIDE0OC4yNzg4NjldIDMzNTQ5IGlzIDI0NWU2MDAwIQ0KWyAgMTQ4LjI4MDUyMV0gMzM1
M2UgaXMgMjQ1ZTcwMDAhDQpbICAxNDguMjgyMTcyXSAzMzU1NSBpcyAyNDVjYTAwMCENClsg
IDE0OC4yODM4NjNdIDMzNTU2IGlzIDI0NWNiMDAwIQ0KWyAgMTQ4LjI4NTUzMF0gMzM1NTcg
aXMgMjQ1Y2MwMDAhDQpbICAxNDguMjg3MjE5XSAzMzU1OCBpcyAyNDVjZDAwMCENClsgIDE0
OC4yODg4ODZdIDMzNTU5IGlzIDI0NWNlMDAwIQ0KWyAgMTQ4LjI5MDU2Nl0gMzM1NWEgaXMg
MjQ1Y2YwMDAhDQpbICAxNDguMjkyMjUwXSAzMzU1YiBpcyAyNDVkMDAwMCENClsgIDE0OC4y
OTM5MzFdIDMzNTRhIGlzIDI0NWQxMDAwIQ0KWyAgMTQ4LjI5NTYxN10gMzM1NGIgaXMgMjQ1
ZDIwMDAhDQpbICAxNDguMjk3Mjk4XSAzMzU0YyBpcyAyNDVkMzAwMCENClsgIDE0OC4yOTg5
NTldIDMzNTRkIGlzIDI0NWQ0MDAwIQ0KWyAgMTQ4LjMwMDY1Nl0gMzM1NGUgaXMgMjQ1ZDUw
MDAhDQpbICAxNDguMzAyMzI5XSAzMzU0ZiBpcyAyNDVkNjAwMCENClsgIDE0OC4zMDQwMzFd
IDMzNTUwIGlzIDI0NWQ3MDAwIQ0KWyAgMTQ4LjMwNTcwOV0gMzM1NTEgaXMgMjQ1ZDgwMDAh
DQpbICAxNDguMzA3NDAwXSAzMzU1MiBpcyAyNDVkOTAwMCENClsgIDE0OC4zMDkwODldIDMz
NTUzIGlzIDI0NWRhMDAwIQ0KWyAgMTQ4LjMxMDc3NV0gMzM1NTQgaXMgMjQ1ZGIwMDAhDQpb
ICAxNDguMzEyNDcwXSAzMzRmZSBpcyAyNDVmZTAwMCENClsgIDE0OC4zMTQxNjhdIDMzNGZm
IGlzIDI0NWZmMDAwIQ0KWyAgMTQ4LjMxNTg0N10gMzM1MWYgaXMgMjQ2MDAwMDAhDQpbICAx
NDguMzE3NTY3XSAzMzUyMCBpcyAyNDYwMTAwMCENClsgIDE0OC4zMTkyNjJdIDMzNTIxIGlz
IDI0NjAyMDAwIQ0KWyAgMTQ4LjMyMDk4Ml0gMzM1MjIgaXMgMjQ2MDMwMDAhDQpbICAxNDgu
MzIyNjczXSAzMzUyMyBpcyAyNDYwNDAwMCENClsgIDE0OC4zMjQzNzBdIDMzNTI0IGlzIDI0
NjA1MDAwIQ0KWyAgMTQ4LjMyNjA2NV0gMzM1MjUgaXMgMjQ2MDYwMDAhDQpbICAxNDguMzI3
NzYzXSAzMzUyNiBpcyAyNDYwNzAwMCENClsgIDE0OC4zMjk0NThdIDMzNTI3IGlzIDI0NjA4
MDAwIQ0KWyAgMTQ4LjMzMTI1NV0gMzM1MzMgaXMgMjQ1YzkwMDAhDQpbICAxNDguMzMzNzk5
XSAzMzUwYSBpcyAyNDViZjAwMCENClsgIDE0OC4zMzU1NTRdIDMzNTBiIGlzIDI0NWMwMDAw
IQ0KWyAgMTQ4LjMzNzI4Ml0gMzM1MGMgaXMgMjQ1YzEwMDAhDQpbICAxNDguMzM5MDA0XSAz
MzUwZCBpcyAyNDVjMjAwMCENClsgIDE0OC4zNDA3MTBdIDMzNTBlIGlzIDI0NWMzMDAwIQ0K
WyAgMTQ4LjM0MjQyM10gMzM1MGYgaXMgMjQ1YzQwMDAhDQpbICAxNDguMzQ0MTgxXSAzMzUx
MCBpcyAyNDVjNTAwMCENClsgIDE0OC4zNDU4OTldIDMzNTExIGlzIDI0NWM2MDAwIQ0KWyAg
MTQ4LjM0NzYxMF0gMzM1MTIgaXMgMjQ1YzcwMDAhDQpbICAxNDguMzQ5MzAxXSAzMzUxMyBp
cyAyNDVjODAwMCENClsgIDE0OC4zNTEzMDRdIDMzNTA5IGlzIDI0NWE4MDAwIQ0KWyAgMTQ4
LjM1MzAyMF0gMzM1MTQgaXMgMjQ1YjMwMDAhDQpbICAxNDguMzU0NzY5XSAzMzUxNSBpcyAy
NDViNDAwMCENClsgIDE0OC4zNTY0NzddIDMzNTE2IGlzIDI0NWI1MDAwIQ0KWyAgMTQ4LjM1
ODIxOF0gMzM1MTcgaXMgMjQ1YjYwMDAhDQpbICAxNDguMzU5OTIwXSAzMzUxOCBpcyAyNDVi
NzAwMCENClsgIDE0OC4zNjE2MzNdIDMzNTE5IGlzIDI0NWI4MDAwIQ0KWyAgMTQ4LjM2MzM5
Ml0gMzM1MWEgaXMgMjQ1YjkwMDAhDQpbICAxNDguMzY1MTA1XSAzMzUxYiBpcyAyNDViYTAw
MCENClsgIDE0OC4zNjY4MzhdIDMzNTFjIGlzIDI0NWJiMDAwIQ0KWyAgMTQ4LjM2ODUzM10g
MzM1MWQgaXMgMjQ1YmMwMDAhDQpbICAxNDguMzcwMjQ0XSAzMzUxZSBpcyAyNDViZDAwMCEN
ClsgIDE0OC4zNzE5MzBdIDMzNTVkIGlzIDI0NWE5MDAwIQ0KWyAgMTQ4LjM3MzYyMl0gMzM1
NWUgaXMgMjQ1YWEwMDAhDQpbICAxNDguMzc1MzIyXSAzMzU1ZiBpcyAyNDVhYjAwMCENClsg
IDE0OC4zNzcwMDldIDMzNTYwIGlzIDI0NWFjMDAwIQ0KWyAgMTQ4LjM3ODcwMl0gMzM1NjEg
aXMgMjQ1YWQwMDAhDQpbICAxNDguMzgwMzk0XSAzMzU2MiBpcyAyNDVhZTAwMCENClsgIDE0
OC4zODIwNzldIDMzNTYzIGlzIDI0NWFmMDAwIQ0KWyAgMTQ4LjM4MzgwMF0gMzM1NjQgaXMg
MjQ1YjAwMDAhDQpbICAxNDguMzg1NDk2XSAzMzU2NSBpcyAyNDViMTAwMCENClsgIDE0OC4z
ODcyMDNdIDMzNTY2IGlzIDI0NWIyMDAwIQ0KWyAgMTQ4LjM4OTI1N10gMzM1NjcgaXMgMjQ1
YTcwMDAhDQpbICAxNDguMzkxNzczXSAzMzU2OCBpcyAyNDU5YzAwMCENClsgIDE0OC4zOTM0
NjldIDMzNTVjIGlzIDI0NTlkMDAwIQ0KWyAgMTQ4LjM5NTE0OF0gMzM1N2MgaXMgMjQ1OWUw
MDAhDQpbICAxNDguMzk2ODUzXSAzMzU3ZCBpcyAyNDU5ZjAwMCENClsgIDE0OC4zOTg1MzJd
IDMzNTdlIGlzIDI0NWEwMDAwIQ0KWyAgMTQ4LjQwMDIzNl0gMzM1N2YgaXMgMjQ1YTEwMDAh
DQpbICAxNDguNDAxOTE2XSAzMzU4MCBpcyAyNDVhMjAwMCENClsgIDE0OC40MDM2MDldIDMz
NTgxIGlzIDI0NWEzMDAwIQ0KWyAgMTQ4LjQwNTMwMV0gMzM1ODIgaXMgMjQ1YTQwMDAhDQpb
ICAxNDguNDA2OTg3XSAzMzU4MyBpcyAyNDVhNTAwMCENClsgIDE0OC40MDg2NjZdIDMzNTg0
IGlzIDI0NWE2MDAwIQ0KWyAgMTQ4LjQxMDYyNV0gMzM1OTAgaXMgMjQ1OGEwMDAhDQpbICAx
NDguNDEyMzU1XSAzMzU5MSBpcyAyNDU4YjAwMCENClsgIDE0OC40MTQwNjldIDMzNTkyIGlz
IDI0NThjMDAwIQ0KWyAgMTQ4LjQxNTc0OF0gMzM1OTMgaXMgMjQ1OGQwMDAhDQpbICAxNDgu
NDE3NDY1XSAzMzU5NCBpcyAyNDU4ZTAwMCENClsgIDE0OC40MTkxMzhdIDMzNTk1IGlzIDI0
NThmMDAwIQ0KWyAgMTQ4LjQyMDg0Nl0gMzM1OTYgaXMgMjQ1OTAwMDAhDQpbICAxNDguNDIy
NTMwXSAzMzU5NyBpcyAyNDU4OTAwMCENClsgIDE0OC40MjQyMzhdIDMzNTk4IGlzIDI0NTg4
MDAwIQ0KWyAgMTQ4LjQyNTkzOF0gMzM1ODUgaXMgMjQ1OTEwMDAhDQpbICAxNDguNDI3NjI4
XSAzMzU4NiBpcyAyNDU5MjAwMCENClsgIDE0OC40MjkzMjhdIDMzNTg3IGlzIDI0NTkzMDAw
IQ0KWyAgMTQ4LjQzMDk5OF0gMzM1ODggaXMgMjQ1OTQwMDAhDQpbICAxNDguNDMyNjQ3XSAz
MzU4OSBpcyAyNDU5NTAwMCENClsgIDE0OC40MzQzMzNdIDMzNThhIGlzIDI0NTk2MDAwIQ0K
WyAgMTQ4LjQzNTk4Ml0gMzM1OGIgaXMgMjQ1OTcwMDAhDQpbICAxNDguNDM3NjYzXSAzMzU4
YyBpcyAyNDU5ODAwMCENClsgIDE0OC40MzkzMDZdIDMzNThkIGlzIDI0NTk5MDAwIQ0KWyAg
MTQ4LjQ0MDk2NF0gMzM1OGUgaXMgMjQ1OWEwMDAhDQpbICAxNDguNDQyNjMwXSAzMzU4ZiBp
cyAyNDU5YjAwMCENClsgIDE0OC40NTg1MzBdIDMzNTk5IGlzIDI0ZDdkMDAwIQ0KWyAgMTQ4
LjQ2MDI2NV0gMzM1OWEgaXMgMjRkN2UwMDAhDQpbICAxNDguNDYxOTY5XSAzMzU5YiBpcyAy
NGQ3ZjAwMCENClsgIDE0OC40NjM2MzFdIDMzNTljIGlzIDI0ZDgwMDAwIQ0KWyAgMTQ4LjQ2
NTI4MV0gMzM1OWQgaXMgMjRkODEwMDAhDQpbICAxNDguNDY2OTUxXSAzMzU5ZSBpcyAyNGQ4
MjAwMCENClsgIDE0OC40Njg1NzhdIDMzNTlmIGlzIDI0ZDgzMDAwIQ0KWyAgMTQ4LjQ3MDI0
N10gMzM1YTAgaXMgMjRkODQwMDAhDQpbICAxNDguNDcxODg4XSAzMzVhMSBpcyAyNDU4NTAw
MCENClsgIDE0OC40NzM1NjBdIDMzNWEyIGlzIDI0NTg2MDAwIQ0KWyAgMTQ4LjQ3NTIyOV0g
MzM1YTMgaXMgMjQ1ODcwMDAhDQpbICAxNDguNDc3MTc5XSAzMzViOSBpcyAyNGQ2NzAwMCEN
ClsgIDE0OC40Nzg4NDddIDMzNWE0IGlzIDI0ZDcyMDAwIQ0KWyAgMTQ4LjQ4MDU0M10gMzM1
YTUgaXMgMjRkNzMwMDAhDQpbICAxNDguNDgyMjA5XSAzMzVhNiBpcyAyNGQ3NDAwMCENClsg
IDE0OC40ODM5MDldIDMzNWE3IGlzIDI0ZDc1MDAwIQ0KWyAgMTQ4LjQ4NTU2Ml0gMzM1YTgg
aXMgMjRkNzYwMDAhDQpbICAxNDguNDg3MjUwXSAzMzVhOSBpcyAyNGQ3NzAwMCENClsgIDE0
OC40ODg4OTJdIDMzNWFhIGlzIDI0ZDc4MDAwIQ0KWyAgMTQ4LjQ5MDU0Nl0gMzM1YWIgaXMg
MjRkNzkwMDAhDQpbICAxNDguNDkyMjExXSAzMzVhYyBpcyAyNGQ3YTAwMCENClsgIDE0OC40
OTM4NzddIDMzNWFkIGlzIDI0ZDdiMDAwIQ0KWyAgMTQ4LjQ5NTU0Nl0gMzM1YWUgaXMgMjRk
N2MwMDAhDQpbICAxNDguNDk3MjI5XSAzMzVhZiBpcyAyNGQ2ODAwMCENClsgIDE0OC40OTg4
OTldIDMzNWIwIGlzIDI0ZDY5MDAwIQ0KWyAgMTQ4LjUwMDYwNF0gMzM1YjEgaXMgMjRkNmEw
MDAhDQpbICAxNDguNTAyMjg2XSAzMzViMiBpcyAyNGQ2YjAwMCENClsgIDE0OC41MDQwMDNd
IDMzNWIzIGlzIDI0ZDZjMDAwIQ0KWyAgMTQ4LjUwNTY4NF0gMzM1YjQgaXMgMjRkNmQwMDAh
DQpbICAxNDguNTA3Mzg1XSAzMzViNSBpcyAyNGQ2ZTAwMCENClsgIDE0OC41MDkwNzddIDMz
NWI2IGlzIDI0ZDZmMDAwIQ0KWyAgMTQ4LjUxMDc1OV0gMzM1YjcgaXMgMjRkNzAwMDAhDQpb
ICAxNDguNTEyNDQ0XSAzMzViOCBpcyAyNGQ3MTAwMCENClsgIDE0OC41MTU3MTFdIDMzNTcz
IGlzIDI0ZDUxMDAwIQ0KWyAgMTQ4LjUxNzU2Ml0gMzM1NzQgaXMgMjRkNTIwMDAhDQpbICAx
NDguNTE5MjUwXSAzMzU3NSBpcyAyNGQ1MzAwMCENClsgIDE0OC41MjA5NzRdIDMzNTc2IGlz
IDI0ZDU0MDAwIQ0KWyAgMTQ4LjUyMjY3OV0gMzM1NzcgaXMgMjRkNTUwMDAhDQpbICAxNDgu
NTI0NDA0XSAzMzU3OCBpcyAyNGQ1NjAwMCENClsgIDE0OC41MjYwODBdIDMzNTc5IGlzIDI0
ZDU3MDAwIQ0KWyAgMTQ4LjUyNzc2Ml0gMzM1N2EgaXMgMjRkNTgwMDAhDQpbICAxNDguNTI5
NDYzXSAzMzU3YiBpcyAyNGQ1OTAwMCENClsgIDE0OC41MzExNDBdIDMzNWQ5IGlzIDI0ZDVh
MDAwIQ0KWyAgMTQ4LjUzMjgxOV0gMzM1ZGEgaXMgMjRkNWIwMDAhDQpbICAxNDguNTM0NDkx
XSAzMzVkYiBpcyAyNGQ0NzAwMCENClsgIDE0OC41MzYxNDldIDMzNWRjIGlzIDI0ZDQ4MDAw
IQ0KWyAgMTQ4LjUzNzg0MV0gMzM1ZGQgaXMgMjRkNDkwMDAhDQpbICAxNDguNTM5NTA1XSAz
MzVkZSBpcyAyNGQ0YTAwMCENClsgIDE0OC41NDEyMDJdIDMzNWRmIGlzIDI0ZDRiMDAwIQ0K
WyAgMTQ4LjU0Mjg2Nl0gMzM1ZTAgaXMgMjRkNGMwMDAhDQpbICAxNDguNTQ0NTU3XSAzMzVl
MSBpcyAyNGQ0ZDAwMCENClsgIDE0OC41NDYyMzhdIDMzNWUyIGlzIDI0ZDRlMDAwIQ0KWyAg
MTQ4LjU0NzkyMF0gMzM1ZTMgaXMgMjRkNGYwMDAhDQpbICAxNDguNTQ5NjA3XSAzMzVlNCBp
cyAyNGQ1MDAwMCENClsgIDE0OC41NTI5MjhdIDMzNWY5IGlzIDI0ZDA3MDAwIQ0KWyAgMTQ4
LjU1NDczMV0gMzM1ZjggaXMgMjRkMDgwMDAhDQpbICAxNDguNTU2NDE0XSAzMzVmNyBpcyAy
NGQwOTAwMCENClsgIDE0OC41NTgxMTZdIDMzNWY2IGlzIDI0ZDBhMDAwIQ0KWyAgMTQ4LjU1
OTc3N10gMzM1ZjUgaXMgMjRkMGIwMDAhDQpbICAxNDguNTYxNDU1XSAzMzVmNCBpcyAyNGQw
YzAwMCENClsgIDE0OC41NjMxMzhdIDMzNWYzIGlzIDI0ZDBkMDAwIQ0KWyAgMTQ4LjU2NDgy
N10gMzM1ZjIgaXMgMjRkMGUwMDAhDQpbICAxNDguNTY2NTE2XSAzMzVmMSBpcyAyNGQwZjAw
MCENClsgIDE0OC41NjgxOTBdIDMzNWYwIGlzIDI0ZDEwMDAwIQ0KWyAgMTQ4LjU2OTg1N10g
MzM1ZWYgaXMgMjRkMTEwMDAhDQpbICAxNDguNTcxNTU0XSAzMzVlZSBpcyAyNGQxMjAwMCEN
ClsgIDE0OC41NzMyMjBdIDMzNWVkIGlzIDI0ZDEzMDAwIQ0KWyAgMTQ4LjU3NDkxOF0gMzM1
ZWMgaXMgMjRkMTQwMDAhDQpbICAxNDguNTc2NTc5XSAzMzVlYiBpcyAyNGQxNTAwMCENClsg
IDE0OC41NzgyNjBdIDMzNWVhIGlzIDI0ZDE2MDAwIQ0KWyAgMTQ4LjU3OTk0M10gMzM1ZTkg
aXMgMjRkMTcwMDAhDQpbICAxNDguNTgxNjI0XSAzMzVlOCBpcyAyNGQxODAwMCENClsgIDE0
OC41ODMzMTRdIDMzNWU3IGlzIDI0ZDE5MDAwIQ0KWyAgMTQ4LjU4NTAwMV0gMzM1ZTYgaXMg
MjRkMWEwMDAhDQpbICAxNDguNTg2Njc3XSAzMzVlNSBpcyAyNGQxYjAwMCENClsgIDE0OC41
ODk4OThdIDMzNWJhIGlzIDI0Y2RjMDAwIQ0KWyAgMTQ4LjU5MTY0M10gMzM1NjkgaXMgMjRj
ZGQwMDAhDQpbICAxNDguNTkzMzY4XSAzMzU2YSBpcyAyNGNkZTAwMCENClsgIDE0OC41OTUx
MDhdIDMzNTZiIGlzIDI0Y2RmMDAwIQ0KWyAgMTQ4LjU5Njg0M10gMzM1NmMgaXMgMjRjZTAw
MDAhDQpbICAxNDguNTk4NTQ1XSAzMzU2ZCBpcyAyNGNlMTAwMCENClsgIDE0OC42MDAyNjJd
IDMzNTZlIGlzIDI0Y2UyMDAwIQ0KWyAgMTQ4LjYwMTk2NV0gMzM1NmYgaXMgMjRjZTMwMDAh
DQpbICAxNDguNjAzNzA0XSAzMzU3MCBpcyAyNGNlNDAwMCENClsgIDE0OC42MDU0MTZdIDMz
NTcxIGlzIDI0Y2U1MDAwIQ0KWyAgMTQ4LjYwNzEzMF0gMzM1NzIgaXMgMjRjZTYwMDAhDQpb
ICAxNDguNjA4ODQwXSAzMzYwNCBpcyAyNGNkMTAwMCENClsgIDE0OC42MTA1MzldIDMzNjAz
IGlzIDI0Y2QyMDAwIQ0KWyAgMTQ4LjYxMjI0MF0gMzM2MDIgaXMgMjRjZDMwMDAhDQpbICAx
NDguNjEzOTQ0XSAzMzYwMSBpcyAyNGNkNDAwMCENClsgIDE0OC42MTU2MjhdIDMzNjAwIGlz
IDI0Y2Q1MDAwIQ0KWyAgMTQ4LjYxNzMzOF0gMzM1ZmYgaXMgMjRjZDYwMDAhDQpbICAxNDgu
NjE5MDIzXSAzMzVmZSBpcyAyNGNkNzAwMCENClsgIDE0OC42MjA3MzhdIDMzNWZkIGlzIDI0
Y2Q4MDAwIQ0KWyAgMTQ4LjYyMjQyOV0gMzM1ZmMgaXMgMjRjZDkwMDAhDQpbICAxNDguNjI0
MTQyXSAzMzVmYiBpcyAyNGNkYTAwMCENClsgIDE0OC42MjU4MjBdIDMzNWZhIGlzIDI0Y2Ri
MDAwIQ0KWyAgMTQ4LjYyOTM0OV0gMzM2MTcgaXMgMjRjODcwMDAhDQpbICAxNDguNjMxMjA5
XSAzMzVkOCBpcyAyNGM4ODAwMCENClsgIDE0OC42MzI5NzFdIDMzNWQ3IGlzIDI0Yzg5MDAw
IQ0KWyAgMTQ4LjYzNDcxM10gMzM1ZDYgaXMgMjRjOGEwMDAhDQpbICAxNDguNjM2NDMxXSAz
MzVkNSBpcyAyNGM4YjAwMCENClsgIDE0OC42MzgxOTFdIDMzNWQ0IGlzIDI0YzhjMDAwIQ0K
WyAgMTQ4LjYzOTg5OV0gMzM1ZDMgaXMgMjRjOGQwMDAhDQpbICAxNDguNjQxNjQyXSAzMzVk
MiBpcyAyNGM4ZTAwMCENClsgIDE0OC42NDMzNTZdIDMzNWQxIGlzIDI0YzhmMDAwIQ0KWyAg
MTQ4LjY0NTEwM10gMzM1ZDAgaXMgMjRjOTAwMDAhDQpbICAxNDguNjQ2ODE1XSAzMzVjZiBp
cyAyNGM5YzAwMCENClsgIDE0OC42NDg1MjBdIDMzNWNlIGlzIDI0YzlkMDAwIQ0KWyAgMTQ4
LjY1MDI1Ml0gMzM1Y2QgaXMgMjRjOWUwMDAhDQpbICAxNDguNjUxOTQ4XSAzMzVjYyBpcyAy
NGM5ZjAwMCENClsgIDE0OC42NTM2NjddIDMzNWNiIGlzIDI0Y2EwMDAwIQ0KWyAgMTQ4LjY1
NTM2OV0gMzM1Y2EgaXMgMjRjYTEwMDAhDQpbICAxNDguNjU3MDY3XSAzMzVjOSBpcyAyNGNh
MjAwMCENClsgIDE0OC42NTg3NjhdIDMzNWM4IGlzIDI0Y2EzMDAwIQ0KWyAgMTQ4LjY2MDQ1
NV0gMzM1YzcgaXMgMjRjYTQwMDAhDQpbICAxNDguNjYyMTQ4XSAzMzVjNiBpcyAyNGNhNTAw
MCENClsgIDE0OC42NjM4NDJdIDMzNWM1IGlzIDI0Y2E2MDAwIQ0KWyAgMTQ4LjY2NTUwM10g
MzM1YzQgaXMgMjRjOTEwMDAhDQpbICAxNDguNjY3MTkzXSAzMzVjMyBpcyAyNGM5MjAwMCEN
ClsgIDE0OC42Njg4NTBdIDMzNWMyIGlzIDI0YzkzMDAwIQ0KWyAgMTQ4LjY3MDU0Ml0gMzM1
YzEgaXMgMjRjOTQwMDAhDQpbICAxNDguNjcyMjA4XSAzMzVjMCBpcyAyNGM5NTAwMCENClsg
IDE0OC42NzM4ODVdIDMzNWJmIGlzIDI0Yzk2MDAwIQ0KWyAgMTQ4LjY3NTU2OF0gMzM1YmUg
aXMgMjRjOTcwMDAhDQpbICAxNDguNjc3MjQzXSAzMzViZCBpcyAyNGM5ODAwMCENClsgIDE0
OC42Nzg5MjBdIDMzNWJjIGlzIDI0Yzk5MDAwIQ0KWyAgMTQ4LjY4MDU5NV0gMzM1YmIgaXMg
MjRjOWEwMDBbICAxNTAuODA3ODkxXSAzMzhjYiBpcyAyNTBhMzAwMCENClsgIDE1MC44MDk1
NjNdIDMzOGNjIGlzIDI1MGEyMDAwIQ0KWyAgMTUwLjgxMTI2M10gMzM4Y2QgaXMgMjUwYTEw
MDAhDQpbICAxNTAuODEyOTIzXSAzMzhjZSBpcyAyNTBhMDAwMCENClsgIDE1MC44MTQ1Nzhd
IDMzOGNmIGlzIDI1MDlmMDAwIQ0KWyAgMTUwLjgxNzg0Nl0gMzM4ZDAgaXMgMjUwYjQwMDAh
DQpbICAxNTAuODE5NDkyXSAzMzhkMSBpcyAyNTBiMzAwMCENClsgIDE1MC44MjExNjhdIDMz
OGQyIGlzIDI1MGIyMDAwIQ0KWyAgMTUwLjgyMjgxOF0gMzM4ZDMgaXMgMjUwYjEwMDAhDQpb
ICAxNTAuODI0NDgxXSAzMzhkNCBpcyAyNTBiMDAwMCENClsgIDE1MC44MjYxNDddIDMzOGQ1
IGlzIDI1MGFmMDAwIQ0KWyAgMTUwLjgyNzg4OF0gMzM4ZDYgaXMgMjUwYWUwMDAhDQpbICAx
NTAuODI5NTYxXSAzMzhkNyBpcyAyNTBhZDAwMCENClsgIDE1MC44MzEyMzRdIDMzOGQ4IGlz
IDI1MGFjMDAwIQ0KWyAgMTUwLjgzMjkwMV0gMzM4ZDkgaXMgMjUwYWIwMDAhDQpbICAxNTAu
ODM0NTk4XSAzMzhkYSBpcyAyNTBhYTAwMCENClsgIDE1MC44MzYyNTldIDMzOGRiIGlzIDI1
MGNjMDAwIQ0KWyAgMTUwLjgzNzk1MV0gMzM4ZGMgaXMgMjUwYzYwMDAhDQpbICAxNTAuODM5
NjA2XSAzMzhkZCBpcyAyNTBjNzAwMCENClsgIDE1MC44NDEyNzddIDMzOGRlIGlzIDI1MGM5
MDAwIQ0KWyAgMTUwLjg0Mjk1NF0gMzM4ZGYgaXMgMjUwYzgwMDAhDQpbICAxNTAuODQ0Njc0
XSAzMzhlMCBpcyAyNTBkNzAwMCENClsgIDE1MC44NDYzNTFdIDMzOGUxIGlzIDI1MGI4MDAw
IQ0KWyAgMTUwLjg0ODAzNF0gMzM4ZTIgaXMgMjUwYjcwMDAhDQpbICAxNTAuODQ5NzE2XSAz
MzhlMyBpcyAyNTBiNjAwMCENClsgIDE1MC44NTE0MDRdIDMzOTAzIGlzIDI1MGI1MDAwIQ0K
WyAgMTUwLjg1MzIxMV0gMzM4ZTggaXMgMjUwY2QwMDAhDQpbICAxNTAuODczOTcwXSAzMzky
YSBpcyAyNTA5NzAwMCENClsgIDE1MC44NzU3MTNdIDMzOGU5IGlzIDI1MGNhMDAwIQ0KWyAg
MTUwLjg3NzQ2NV0gMzM4ZWEgaXMgMjUwY2IwMDAhDQpbICAxNTAuODc5MjAzXSAzMzhlYiBp
cyAyNTBkMjAwMCENClsgIDE1MC44ODA5NTZdIDMzOGVjIGlzIDI1MGQ4MDAwIQ0KWyAgMTUw
Ljg4MjY4OV0gMzM4ZWQgaXMgMjUwYmEwMDAhDQpbICAxNTAuODg0NDY0XSAzMzhlZSBpcyAy
NTBiOTAwMCENClsgIDE1MC44ODYyMDldIDMzOGVmIGlzIDI1MGQxMDAwIQ0KWyAgMTUwLjg4
ODAwMV0gMzM4ZjAgaXMgMjUwZDQwMDAhDQpbICAxNTAuODg5NzUzXSAzMzhmMSBpcyAyNTBk
MzAwMCENClsgIDE1MC44OTE1MjddIDMzOGYyIGlzIDI1MGQwMDAwIQ0KWyAgMTUwLjg5MzI3
Ml0gMzM4ZjMgaXMgMjUwY2UwMDAhDQpbICAxNTAuODk1MDM3XSAzMzhmNCBpcyAyNTA5ZTAw
MCENClsgIDE1MC44OTY4MjRdIDMzOGY1IGlzIDI0ODUzMDAwIQ0KWyAgMTUwLjg5ODU5MV0g
MzM4ZjYgaXMgMjUwYzEwMDAhDQpbICAxNTAuOTAwNDA2XSAzMzhmNyBpcyAyNGJjODAwMCEN
ClsgIDE1MC45MDIyMDhdIDMzOGY4IGlzIDI0OWJiMDAwIQ0KWyAgMTUwLjkwNDA1MV0gMzM4
ZjkgaXMgMjQ4NDgwMDAhDQpbICAxNTAuOTA1ODY2XSAzMzhmYSBpcyAyNTBjMjAwMCENClsg
IDE1MC45MDc3MTVdIDMzOGZiIGlzIDI0NjQwMDAwIQ0KWyAgMTUwLjkwOTU4Nl0gMzM4ZmMg
aXMgMjQ5YmMwMDAhDQpbICAxNTAuOTExNDUyXSAzMzhmZCBpcyAyNTBkNTAwMCENClsgIDE1
MC45MTMzNDhdIDMzOGZlIGlzIDI1MGQ2MDAwIQ0KWyAgMTUwLjkxNTI0M10gMzM4ZmYgaXMg
MjUwOTgwMDAhDQpbICAxNTAuOTE3MTQ5XSAzMzkwMCBpcyAyNTA5OTAwMCENClsgIDE1MC45
MTkwMjldIDMzOTAxIGlzIDI1MDlhMDAwIQ0KWyAgMTUwLjkyMDkyOF0gMzM5MDIgaXMgMjUw
OWIwMDAhDQpbICAxNTAuOTIyNzkxXSAzMzkyNCBpcyAyNTA5YzAwMCENClsgIDE1MC45MjQ2
ODhdIDMzOTI1IGlzIDI1MGJkMDAwIQ0KWyAgMTUwLjkyNjU2M10gMzM5MjYgaXMgMjUwYmUw
MDAhDQpbICAxNTAuOTI4NDM5XSAzMzkyNyBpcyAyNTBiZjAwMCENClsgIDE1MC45MzAzMTdd
IDMzOTI4IGlzIDI1MGMwMDAwIQ0KWyAgMTUwLjkzMjE1N10gMzM5MjkgaXMgMjUwOWQwMDAh
DQpbICAxNTAuOTQwMTEwXSAzMzkwNCBpcyAyNTA4YzAwMCENClsgIDE1MC45NDIwMjhdIDMz
OTJiIGlzIDI1MDhkMDAwIQ0KWyAgMTUwLjk0Mzk0M10gMzM5MmMgaXMgMjUwOGUwMDAhDQpb
ICAxNTAuOTQ1ODMzXSAzMzkyZCBpcyAyNTA4ZjAwMCENClsgIDE1MC45NDc2NjZdIDMzOTJl
IGlzIDI1MDkwMDAwIQ0KWyAgMTUwLjk0OTQ5MF0gMzM5MmYgaXMgMjUwOTEwMDAhDQpbICAx
NTAuOTUxMzM5XSAzMzkzMCBpcyAyNTA5MjAwMCENClsgIDE1MC45NTMxNjhdIDMzOTMxIGlz
IDI1MDkzMDAwIQ0KWyAgMTUwLjk1NTAyOF0gMzM5MzIgaXMgMjUwOTQwMDAhDQpbICAxNTAu
OTU2ODYxXSAzMzkzMyBpcyAyNTA5NTAwMCENClsgIDE1MC45NTg2ODhdIDMzOTM0IGlzIDI1
MDk2MDAwIQ0KWyAgMTUwLjk2MDc1Nl0gMzM5MzYgaXMgMjUwODIwMDAhDQpbICAxNTAuOTYy
NTkxXSAzMzkzNyBpcyAyNTA4MzAwMCENClsgIDE1MC45NjQ0MTVdIDMzOTM4IGlzIDI1MDg0
MDAwIQ0KWyAgMTUwLjk2NjIxNV0gMzM5MzkgaXMgMjUwODUwMDAhDQpbICAxNTAuOTY3OTg2
XSAzMzkzYSBpcyAyNTA4NjAwMCENClsgIDE1MC45Njk3NDVdIDMzOTNiIGlzIDI1MDg3MDAw
IQ0KWyAgMTUwLjk3MTUxNV0gMzM5M2MgaXMgMjUwODgwMDAhDQpbICAxNTAuOTczMjQ2XSAz
MzkzZCBpcyAyNTA4OTAwMCENClsgIDE1MC45NzQ5NzhdIDMzOTNlIGlzIDI1MDhhMDAwIQ0K
WyAgMTUwLjk3NjY2NF0gMzM5M2YgaXMgMjUwOGIwMDAhDQpbICAxNTAuOTc4MzYzXSAzMzk0
MCBpcyAyNTA3NzAwMCENClsgIDE1MC45ODAwODNdIDMzOTQxIGlzIDI1MDc4MDAwIQ0KWyAg
MTUwLjk4MTc2Ml0gMzM5NDIgaXMgMjUwNzkwMDAhDQpbICAxNTAuOTgzNDcyXSAzMzk0MyBp
cyAyNTA3YTAwMCENClsgIDE1MC45ODUxNjFdIDMzOTQ0IGlzIDI1MDdiMDAwIQ0KWyAgMTUw
Ljk4Njg1MV0gMzM5NDUgaXMgMjUwN2MwMDAhDQpbICAxNTAuOTg4NTMwXSAzMzk0NiBpcyAy
NTA3ZDAwMCENClsgIDE1MC45OTAyMTJdIDMzOTQ3IGlzIDI1MDdlMDAwIQ0KWyAgMTUwLjk5
MTg4NV0gMzM5NDggaXMgMjUwN2YwMDAhDQpbICAxNTAuOTkzNTQzXSAzMzk0OSBpcyAyNTA4
MDAwMCENClsgIDE1MC45OTU1NDRdIDMzOTM1IGlzIDI1MDU2MDAwIQ0KWyAgMTUwLjk5NzI0
MF0gMzM5NGEgaXMgMjUwNmMwMDAhDQpbICAxNTAuOTk4ODkwXSAzMzk0YiBpcyAyNTA2ZDAw
MCENClsgIDE1MS4wMDA1ODJdIDMzOTRjIGlzIDI1MDZlMDAwIQ0KWyAgMTUxLjAwMjI0OV0g
MzM5NGQgaXMgMjUwNmYwMDAhDQpbICAxNTEuMDAzOTQ0XSAzMzk0ZSBpcyAyNTA3MDAwMCEN
ClsgIDE1MS4wMDU2MDddIDMzOTRmIGlzIDI1MDcxMDAwIQ0KWyAgMTUxLjAwNzI2Nl0gMzM5
NTAgaXMgMjUwNzIwMDAhDQpbICAxNTEuMDA4OTU3XSAzMzk1MSBpcyAyNTA3MzAwMCENClsg
IDE1MS4wMTA2MjldIDMzOTUyIGlzIDI1MDc0MDAwIQ0KWyAgMTUxLjAxMjMwNF0gMzM5NTMg
aXMgMjUwNzUwMDAhDQpbICAxNTEuMDEzOTgwXSAzMzk1NCBpcyAyNTA3NjAwMCENClsgIDE1
MS4wMTU2MjhdIDMzOTU1IGlzIDI1MDYxMDAwIQ0KWyAgMTUxLjAxNzMxNl0gMzM5NTYgaXMg
MjUwNjIwMDAhDQpbICAxNTEuMDE4OTY5XSAzMzk1NyBpcyAyNTA2MzAwMCENClsgIDE1MS4w
MjA2NjhdIDMzOTU4IGlzIDI1MDY0MDAwIQ0KWyAgMTUxLjAyMjMzMV0gMzM5NTkgaXMgMjUw
NjUwMDAhDQpbICAxNTEuMDI0MDEzXSAzMzk1YSBpcyAyNTA2NjAwMCENClsgIDE1MS4wMjU2
OTZdIDMzOTViIGlzIDI1MDY3MDAwIQ0KWyAgMTUxLjAyNzM3OF0gMzM5NWMgaXMgMjUwNjgw
MDAhDQpbICAxNTEuMDI5MDY1XSAzMzk1ZCBpcyAyNTA2OTAwMCENClsgIDE1MS4wMzA3NDFd
IDMzOTVlIGlzIDI1MDZhMDAwIQ0KWyAgMTUxLjAzMjQwMl0gMzM5NWYgaXMgMjUwNmIwMDAh
DQpbICAxNTEuMDM0MDkyXSAzMzk2MCBpcyAyNTA1NzAwMCENClsgIDE1MS4wMzU3NjBdIDMz
OTYxIGlzIDI1MDU4MDAwIQ0KWyAgMTUxLjAzNzQ2M10gMzM5NjQgaXMgMjUwNTkwMDAhDQpb
ICAxNTEuMDM5MTMwXSAzMzk2NSBpcyAyNTA1YTAwMCENClsgIDE1MS4wNDA4MTddIDMzOTY2
IGlzIDI1MDViMDAwIQ0KWyAgMTUxLjA0MjUxMl0gMzM5NjcgaXMgMjUwNWMwMDAhDQpbICAx
NTEuMDQ0MTkyXSAzMzk2OCBpcyAyNTA1ZDAwMCENClsgIDE1MS4wNDU4NzFdIDMzOTY5IGlz
IDI1MDVlMDAwIQ0KWyAgMTUxLjA0NzU0MF0gMzM5NmEgaXMgMjUwNWYwMDAhDQpbICAxNTEu
MDQ5MTk3XSAzMzk2YiBpcyAyNTA2MDAwMCENClsgIDE1MS4wNTI0NjZdIDMzOTgxIGlzIDI1
MDM2MDAwIQ0KWyAgMTUxLjA1NDI0MV0gMzM5ODIgaXMgMjUwMzcwMDAhDQpbICAxNTEuMDU1
OTMyXSAzMzk4MyBpcyAyNTAzODAwMCENClsgIDE1MS4wNTc2MjNdIDMzOTg0IGlzIDI1MDM5
MDAwIQ0KWyAgMTUxLjA1OTMxMl0gMzM5ODUgaXMgMjUwM2EwMDAhDQpbICAxNTEuMDYwOTk1
XSAzMzk4NiBpcyAyNTAzYjAwMCENClsgIDE1MS4wNjI2ODVdIDMzOTg3IGlzIDI1MDNjMDAw
IQ0KWyAgMTUxLjA2NDM2M10gMzM5ODggaXMgMjUwM2QwMDAhDQpbICAxNTEuMDY2MDU3XSAz
Mzk4OSBpcyAyNTAzZTAwMCENClsgIDE1MS4wNjc3MjddIDMzOThhIGlzIDI1MDNmMDAwIQ0K
WyAgMTUxLjA2OTQwMF0gMzM5MDUgaXMgMjUwNGIwMDAhDQpbICAxNTEuMDcxMDgxXSAzMzk2
YyBpcyAyNTA0YzAwMCENClsgIDE1MS4wNzI3NDNdIDMzOTZkIGlzIDI1MDRkMDAwIQ0KWyAg
MTUxLjA3NDQzNF0gMzM5NmUgaXMgMjUwNGUwMDAhDQpbICAxNTEuMDc2MDk1XSAzMzk2ZiBp
cyAyNTA0ZjAwMCENClsgIDE1MS4wNzc3NzBdIDMzOTcwIGlzIDI1MDUwMDAwIQ0KWyAgMTUx
LjA3OTQ2MF0gMzM5NzEgaXMgMjUwNTEwMDAhDQpbICAxNTEuMDgxMTQyXSAzMzk3MiBpcyAy
NTA1MjAwMCENClsgIDE1MS4wODI4MzBdIDMzOTczIGlzIDI1MDUzMDAwIQ0KWyAgMTUxLjA4
NDUxN10gMzM5NzQgaXMgMjUwNTQwMDAhDQpbICAxNTEuMDg2MTg0XSAzMzk3NSBpcyAyNTA1
NTAwMCENClsgIDE1MS4wODc4ODJdIDMzOTc2IGlzIDI1MDQwMDAwIQ0KWyAgMTUxLjA4OTU0
NF0gMzM5NzcgaXMgMjUwNDEwMDAhDQpbICAxNTEuMDkxMjM1XSAzMzk3OCBpcyAyNTA0MjAw
MCENClsgIDE1MS4wOTI5MDddIDMzOTc5IGlzIDI1MDQzMDAwIQ0KWyAgMTUxLjA5NDU5NV0g
MzM5N2EgaXMgMjUwNDQwMDAhDQpbICAxNTEuMDk2Mjg2XSAzMzk3YiBpcyAyNTA0NTAwMCEN
ClsgIDE1MS4wOTc5NzNdIDMzOTdjIGlzIDI1MDQ2MDAwIQ0KWyAgMTUxLjA5OTY2OF0gMzM5
N2QgaXMgMjUwNDcwMDAhDQpbICAxNTEuMTAxMzYwXSAzMzk3ZSBpcyAyNTA0ODAwMCENClsg
IDE1MS4xMDMwNDVdIDMzOTdmIGlzIDI1MDQ5MDAwIQ0KWyAgMTUxLjEwNDc1NV0gMzM5ODAg
aXMgMjUwNGEwMDAhDQpbICAxNTEuMTA3NjE1XSAzMzlhZCBpcyAyNTAwMDAwMCENClsgIDE1
MS4xMDkzNzNdIDMzOTA2IGlzIDI1MDAxMDAwIQ0KWyAgMTUxLjExMTA5OV0gMzM5MDcgaXMg
MjUwMDIwMDAhDQpbICAxNTEuMTEyODE1XSAzMzkwOCBpcyAyNTAwMzAwMCENClsgIDE1MS4x
MTQ1MjFdIDMzOTA5IGlzIDI1MDA0MDAwIQ0KWyAgMTUxLjExNjIzMF0gMzM5MGEgaXMgMjUw
MDUwMDAhDQpbICAxNTEuMTE3OTQwXSAzMzkwYiBpcyAyNTAwNjAwMCENClsgIDE1MS4xMTk2
MjRdIDMzOTBjIGlzIDI1MDA3MDAwIQ0KWyAgMTUxLjEyMTM1M10gMzM5MGQgaXMgMjUwMDgw
MDAhDQpbICAxNTEuMTIzMDQ5XSAzMzkwZSBpcyAyNTAwOTAwMCENClsgIDE1MS4xMjQ3NzBd
IDMzOTBmIGlzIDI1MDBhMDAwIQ0KWyAgMTUxLjEyNjQ0NV0gMzM5OGIgaXMgMjUwMmIwMDAh
DQpbICAxNTEuMTI4MTM4XSAzMzk4YyBpcyAyNTAyYzAwMCENClsgIDE1MS4xMjk4NTVdIDMz
OThkIGlzIDI1MDJkMDAwIQ0KWyAgMTUxLjEzMTU0Ml0gMzM5OGUgaXMgMjUwMmUwMDAhDQpb
ICAxNTEuMTMzMjI1XSAzMzk4ZiBpcyAyNTAyZjAwMCENClsgIDE1MS4xMzQ5MTJdIDMzOTkw
IGlzIDI1MDMwMDAwIQ0KWyAgMTUxLjEzNjU5Ml0gMzM5OTEgaXMgMjUwMzEwMDAhDQpbICAx
NTEuMTM4Mjk1XSAzMzk5MiBpcyAyNTAzMjAwMCENClsgIDE1MS4xMzk5NjJdIDMzOTkzIGlz
IDI1MDMzMDAwIQ0KWyAgMTUxLjE0MTY2MF0gMzM5OTQgaXMgMjUwMzQwMDAhDQpbICAxNTEu
MTQzMzI3XSAzMzk5NSBpcyAyNTAzNTAwMCENClsgIDE1MS4xNDUwMDhdIDMzOWExIGlzIDI1
MDE2MDAwIQ0KWyAgMTUxLjE0NjY5Nl0gMzM5YTQgaXMgMjUwMTcwMDAhDQpbICAxNTEuMTQ4
MzgzXSAzMzlhNSBpcyAyNTAxODAwMCENClsgIDE1MS4xNTAwODhdIDMzOWE2IGlzIDI1MDE5
MDAwIQ0KWyAgMTUxLjE1MTc2MF0gMzM5YTcgaXMgMjUwMWEwMDAhDQpbICAxNTEuMTUzNDYx
XSAzMzlhOCBpcyAyNTAxYjAwMCENClsgIDE1MS4xNTUxMjhdIDMzOWE5IGlzIDI1MDFjMDAw
IQ0KWyAgMTUxLjE1NjgwNV0gMzM5YWEgaXMgMjUwMWQwMDAhDQpbICAxNTEuMTU4NDgyXSAz
MzlhYiBpcyAyNTAxZTAwMCENClsgIDE1MS4xNjAxNTddIDMzOWFjIGlzIDI1MDFmMDAwIQ0K
WyAgMTUxLjE2MTgzM10gMzM5YTAgaXMgMjUwMGIwMDAhDQpbICAxNTEuMTYzNTA3XSAzMzk5
ZiBpcyAyNTAwYzAwMCENClsgIDE1MS4xNjUxNjldIDMzOTllIGlzIDI1MDBkMDAwIQ0KWyAg
MTUxLjE2Njg2MV0gMzM5OWQgaXMgMjUwMGUwMDAhDQpbICAxNTEuMTY4NTE2XSAzMzk5YyBp
cyAyNTAwZjAwMCENClsgIDE1MS4xNzAyMDFdIDMzOTliIGlzIDI1MDEwMDAwIQ0KWyAgMTUx
LjE3MTg3M10gMzM5OWEgaXMgMjUwMTEwMDAhDQpbICAxNTEuMTczNTYwXSAzMzk5OSBpcyAy
NTAxMjAwMCENClsgIDE1MS4xNzUyNDNdIDMzOTk4IGlzIDI1MDEzMDAwIQ0KWyAgMTUxLjE3
NjkyNl0gMzM5OTcgaXMgMjUwMTQwMDAhDQpbICAxNTEuMTc4NjA3XSAzMzk5NiBpcyAyNTAx
NTAwMCENClsgIDE1MS4xODE5MzldIDMzOWI5IGlzIDI0ZmQ2MDAwIQ0KWyAgMTUxLjE4Mzcy
MF0gMzM5YmEgaXMgMjRmZDcwMDAhDQpbICAxNTEuMTg1NDE4XSAzMzliYiBpcyAyNGZkODAw
MCENClsgIDE1MS4xODcxNTNdIDMzOWJjIGlzIDI0ZmQ5MDAwIQ0KWyAgMTUxLjE4ODg1NF0g
MzM5YmQgaXMgMjRmZGEwMDAhDQpbICAxNTEuMTkwNTM4XSAzMzliZSBpcyAyNGZkYjAwMCEN
ClsgIDE1MS4xOTIyMzldIDMzOWJmIGlzIDI0ZmRjMDAwIQ0KWyAgMTUxLjE5MzkzM10gMzM5
YzAgaXMgMjRmZGQwMDAhDQpbICAxNTEuMTk1NjU1XSAzMzljMSBpcyAyNGZkZTAwMCENClsg
IDE1MS4xOTczNzNdIDMzOWMyIGlzIDI0ZmRmMDAwIQ0KWyAgMTUxLjE5OTA1N10gMzM5MWEg
aXMgMjRmZWIwMDAhDQpbICAxNTEuMjAwNzczXSAzMzkxOSBpcyAyNGZlYzAwMCENClsgIDE1
MS4yMDI0NzBdIDMzOTE4IGlzIDI0ZmVkMDAwIQ0KWyAgMTUxLjIwNDE4Nl0gMzM5MTcgaXMg
MjRmZWUwMDAhDQpbICAxNTEuMjA1ODc4XSAzMzkxNiBpcyAyNGZlZjAwMCENClsgIDE1MS4y
MDc2MDldIDMzOTE1IGlzIDI0ZmYwMDAwIQ0KWyAgMTUxLjIwOTMyN10gMzM5MTQgaXMgMjRm
ZjEwMDAhDQpbICAxNTEuMjExMDMyXSAzMzkxMyBpcyAyNGZmMjAwMCENClsgIDE1MS4yMTI3
NDVdIDMzOTEyIGlzIDI0ZmYzMDAwIQ0KWyAgMTUxLjIxNDQ1NF0gMzM5MTEgaXMgMjRmZjQw
MDAhDQpbICAxNTEuMjE2MTYyXSAzMzkxMCBpcyAyNGZmNTAwMCENClsgIDE1MS4yMTc4NjBd
IDMzOWFlIGlzIDI0ZmUwMDAwIQ0KWyAgMTUxLjIxOTU0NF0gMzM5YWYgaXMgMjRmZTEwMDAh
DQpbICAxNTEuMjIxMjU5XSAzMzliMCBpcyAyNGZlMjAwMCENClsgIDE1MS4yMjI5NjBdIDMz
OWIxIGlzIDI0ZmUzMDAwIQ0KWyAgMTUxLjIyNDY5Ml0gMzM5YjIgaXMgMjRmZTQwMDAhDQpb
ICAxNTEuMjI2MzgzXSAzMzliMyBpcyAyNGZlNTAwMCENClsgIDE1MS4yMjgwODddIDMzOWI0
IGlzIDI0ZmU2MDAwIQ0KWyAgMTUxLjIyOTc4OF0gMzM5YjUgaXMgMjRmZTcwMDAhDQpbICAx
NTEuMjMxNDgxXSAzMzliNiBpcyAyNGZlODAwMCENClsgIDE1MS4yMzMxNzZdIDMzOWI3IGlz
IDI0ZmU5MDAwIQ0KWyAgMTUxLjIzNDg2N10gMzM5YjggaXMgMjRmZWEwMDAhDQpbICAxNTEu
MjM3NjcxXSAzMzllMyBpcyAyNGZhMDAwMCENClsgIDE1MS4yMzk0MTFdIDMzOTFiIGlzIDI0
ZmExMDAwIQ0KWyAgMTUxLjI0MTE0M10gMzM5MWMgaXMgMjRmYTIwMDAhDQpbICAxNTEuMjQy
ODIyXSAzMzkxZCBpcyAyNGZhMzAwMCENClsgIDE1MS4yNDQ1MjJdIDMzOTFlIGlzIDI0ZmE0
MDAwIQ0KWyAgMTUxLjI0NjIxNV0gMzM5MWYgaXMgMjRmYTUwMDAhDQpbICAxNTEuMjQ3ODk5
XSAzMzkyMCBpcyAyNGZhNjAwMCENClsgIDE1MS4yNDk2MDVdIDMzOTIxIGlzIDI0ZmE3MDAw
IQ0KWyAgMTUxLjI1MTI5NF0gMzNhMDEgaXMgMjRmYTgwMDAhDQpbICAxNTEuMjUyOTc1XSAz
M2EwMiBpcyAyNGZhOTAwMCENClsgIDE1MS4yNTQ2NzldIDMzYTAzIGlzIDI0ZmFhMDAwIQ0K
WyAgMTUxLjI1NjMzNF0gMzM5Y2UgaXMgMjRmYzAwMDAhDQpbICAxNTEuMjU4MDQ1XSAzMzlj
ZiBpcyAyNGZjMTAwMCENClsgIDE1MS4yNTk3MjFdIDMzOWQwIGlzIDI0ZmMyMDAwIQ0KWyAg
MTUxLjI2MTQyMV0gMzM5ZDEgaXMgMjRmYzMwMDAhDQpbICAxNTEuMjYzMTA3XSAzMzlkMiBp
cyAyNGZjNDAwMCENClsgIDE1MS4yNjQ3OTVdIDMzOWQzIGlzIDI0ZmM1MDAwIQ0KWyAgMTUx
LjI2NjQ3N10gMzM5ZDQgaXMgMjRmYzYwMDAhDQpbICAxNTEuMjY4MTYxXSAzMzlkNSBpcyAy
NGZjNzAwMCENClsgIDE1MS4yNjk4ODVdIDMzOWQ2IGlzIDI0ZmM4MDAwIQ0KWyAgMTUxLjI3
MTU2MV0gMzM5ZDcgaXMgMjRmYzkwMDAhDQpbICAxNTEuMjczMjIyXSAzMzlkOCBpcyAyNGZj
YTAwMCENClsgIDE1MS4yNzQ5MTRdIDMzOWQ5IGlzIDI0ZmI2MDAwIQ0KWyAgMTUxLjI3NjU3
MF0gMzM5ZGEgaXMgMjRmYjcwMDAhDQpbICAxNTEuMjc4MjU0XSAzMzlkYiBpcyAyNGZiODAw
MCENClsgIDE1MS4yNzk5MTBdIDMzOWRjIGlzIDI0ZmI5MDAwIQ0KWyAgMTUxLjI4MTU3OV0g
MzM5ZGQgaXMgMjRmYmEwMDAhDQpbICAxNTEuMjgzMjYyXSAzMzlkZSBpcyAyNGZiYjAwMCEN
ClsgIDE1MS4yODQ5NDldIDMzOWRmIGlzIDI0ZmJjMDAwIQ0KWyAgMTUxLjI4NjYzN10gMzM5
ZTAgaXMgMjRmYmQwMDAhDQpbICAxNTEuMjg4MzI4XSAzMzllMSBpcyAyNGZiZTAwMCENClsg
IDE1MS4yOTAwMDddIDMzOWUyIGlzIDI0ZmJmMDAwIQ0KWyAgMTUxLjI5MTcxMV0gMzM5Y2Qg
aXMgMjRmYWIwMDAhDQpbICAxNTEuMjkzNDA5XSAzMzljYyBpcyAyNGZhYzAwMCENClsgIDE1
MS4yOTUxMDJdIDMzOWNiIGlzIDI0ZmFkMDAwIQ0KWyAgMTUxLjI5Njc5MV0gMzM5Y2EgaXMg
MjRmYWUwMDAhDQpbICAxNTEuMjk4NDc1XSAzMzljOSBpcyAyNGZhZjAwMCENClsgIDE1MS4z
MDAxODldIDMzOWM4IGlzIDI0ZmIwMDAwIQ0KWyAgMTUxLjMwMTg4NV0gMzM5YzcgaXMgMjRm
YjEwMDAhDQpbICAxNTEuMzAzNjA1XSAzMzljNiBpcyAyNGZiMjAwMCENClsgIDE1MS4zMDUy
NzhdIDMzOWM1IGlzIDI0ZmIzMDAwIQ0KWyAgMTUxLjMwNjk2Nl0gMzM5YzQgaXMgMjRmYjQw
MDAhDQpbICAxNTEuMzA4NjYyXSAzMzljMyBpcyAyNGZiNTAwMCENClsgIDE1MS4zMTE5Nzdd
IDMzOWVmIGlzIDI0Zjc2MDAwIQ0KWyAgMTUxLjMxMzczMF0gMzM5ZjAgaXMgMjRmNzcwMDAh
DQpbICAxNTEuMzE1NDE1XSAzMzlmMSBpcyAyNGY3ODAwMCENClsgIDE1MS4zMTcxNThdIDMz
OWYyIGlzIDI0Zjc5MDAwIQ0KWyAgMTUxLjMxODg0OV0gMzM5ZjMgaXMgMjRmN2EwMDAhDQpb
ICAxNTEuMzIwNTY4XSAzMzlmNCBpcyAyNGY3YjAwMCENClsgIDE1MS4zMjIyNjRdIDMzOWY1
IGlzIDI0ZjdjMDAwIQ0KWyAgMTUxLjMyMzk4Ml0gMzM5ZjYgaXMgMjRmN2QwMDAhDQpbICAx
NTEuMzI1Njc1XSAzMzlmNyBpcyBbICAxNTMuNDU2MDEyXSAzM2JmMCBpcyAyNTU0ZjAwMCEN
ClsgIDE1My40NjI4MTRdIDMzYmYxIGlzIDI1NTRlMDAwIQ0KWyAgMTUzLjQ3MDk1M10gMzNi
ZjIgaXMgMjU1NGQwMDAhDQpbICAxNTMuNDk5NTI0XSAzM2JmMyBpcyAyNTU0YzAwMCENClsg
IDE1My41MTgyMTddIDMzYmQyIGlzIDI1NTRiMDAwIQ0KWyAgMTUzLjUyMDU5N10gMzNiZDMg
aXMgMjU1NDcwMDAhDQpbICAxNTMuNTIyMzk1XSAzM2JmNCBpcyAyNTU0ODAwMCENClsgIDE1
My41MjQyMDFdIDMzYmY1IGlzIDI1NTQ5MDAwIQ0KWyAgMTUzLjUyNTk5Ml0gMzNiZjYgaXMg
MjU1NGEwMDAhDQpbICAxNTMuNTM0OTU5XSAzM2MxMiBpcyAyNTU0NjAwMCENClsgIDE1My41
NDQ2NTFdIDMzYzEzIGlzIDI1NTQ1MDAwIQ0KWyAgMTUzLjU0Njg5M10gMzNjMTQgaXMgMjU1
NDQwMDAhDQpbICAxNTMuNTUzNzI3XSAzM2JmNyBpcyAyNTU0MzAwMCENClsgIDE1My41NzQ0
NDJdIDMzYmY4IGlzIDI1NTQyMDAwIQ0KWyAgMTUzLjU3ODg0NF0gMzNjMTUgaXMgMjU1NDEw
MDAhDQpbICAxNTMuNTg5NDUwXSAzM2JmOSBpcyAyNTU0MDAwMCENClsgIDE1My41OTk4NzRd
IDMzYzE2IGlzIDI1NTNmMDAwIQ0KWyAgMTUzLjYwNzM1OF0gMzNiZmEgaXMgMjU1M2UwMDAh
DQpbICAxNTMuNjA5NjE2XSAzM2JmYiBpcyAyNTUzZDAwMCENClsgIDE1My42MjQ4NjNdIDMz
YmZjIGlzIDI1NTNjMDAwIQ0KWyAgMTUzLjYzNjIxNF0gMzNjMTcgaXMgMjU1M2IwMDAhDQpb
ICAxNTMuNjQ4MDM3XSAzM2MxOCBpcyAyNTUzYTAwMCENClsgIDE1My42NTgxMjVdIDMzYmZk
IGlzIDI1NTM5MDAwIQ0KWyAgMTUzLjY2Mjg2MF0gMzNiZmUgaXMgMjU1MzgwMDAhDQpbICAx
NTMuNjczMjEyXSAzM2JmZiBpcyAyNTUzNzAwMCENClsgIDE1My42NzY2OTRdIDMzYzAwIGlz
IDI1NTM2MDAwIQ0KWyAgMTUzLjY4NDk1OF0gMzNjMDEgaXMgMjU1MzUwMDAhDQpbICAxNTMu
NjkyMDM5XSAzM2MwMiBpcyAyNTUzNDAwMCENClsgIDE1My43MDMxODldIDMzYzAzIGlzIDI1
NTMzMDAwIQ0KWyAgMTUzLjcyMzI1MV0gMzNjMDQgaXMgMjU1MzIwMDAhDQpbICAxNTMuNzMw
ODU4XSAzM2MxOSBpcyAyNTUzMTAwMCENClsgIDE1My43MzMxODZdIDMzYzA1IGlzIDI1NTMw
MDAwIQ0KWyAgMTUzLjc0ODk3NF0gMzNjMDYgaXMgMjU1MmYwMDAhDQpbICAxNTMuNzUyOTQy
XSAzM2MwNyBpcyAyNTUyZTAwMCENClsgIDE1My43NTUzMjJdIDMzYzA4IGlzIDI1NTJkMDAw
IQ0KWyAgMTUzLjc1NzY4MF0gMzNjMDkgaXMgMjU1MmMwMDAhDQpbICAxNTMuNzU5OTIyXSAz
M2MwYSBpcyAyNTUyYjAwMCENClsgIDE1My43NjIzNDddIDMzYzBiIGlzIDI1NTJhMDAwIQ0K
WyAgMTUzLjc2NDY5N10gMzNjMGMgaXMgMjU1MjkwMDAhDQpbICAxNTMuNzY5OTQzXSAzM2Mw
ZCBpcyAyNTUyODAwMCENClsgIDE1My43OTA4OThdIDMzYzBlIGlzIDI1NTI3MDAwIQ0KWyAg
MTUzLjc5NTkxNl0gMzNjMWEgaXMgMjU0ZmQwMDAhDQpbICAxNTMuNzk4MzM2XSAzM2MwZiBp
cyAyNTRmZTAwMCENClsgIDE1My44MDU4NjFdIDMzYzEwIGlzIDI1NGZmMDAwIQ0KWyAgMTUz
LjgxMzAzNV0gMzNjMTEgaXMgMjU1MDAwMDAhDQpbICAxNTMuODIwNDUyXSAzM2MzMSBpcyAy
NTUwMTAwMCENClsgIDE1My44MjcwODFdIDMzYzMyIGlzIDI1NTAyMDAwIQ0KWyAgMTUzLjgz
MzExN10gMzNjMzMgaXMgMjU1MDMwMDAhDQpbICAxNTMuODM3OTIzXSAzM2MzNCBpcyAyNTUw
NDAwMCENClsgIDE1My44NDQ2NDNdIDMzYzM1IGlzIDI1NTA1MDAwIQ0KWyAgMTUzLjg0Njk2
NV0gMzNjMzYgaXMgMjU1MGMwMDAhDQpbICAxNTMuODY1NDc0XSAzM2MzNyBpcyAyNTUxZjAw
MCENClsgIDE1My44NzQ4MTRdIDMzYzFiIGlzIDI1NTE3MDAwIQ0KWyAgMTUzLjg3NjYxMF0g
MzNjMWMgaXMgMjU1MjUwMDAhDQpbICAxNTMuODc4NDIwXSAzM2MxZCBpcyAyNTUyNjAwMCEN
ClsgIDE1My44ODAyMDJdIDMzYzFlIGlzIDI1NTFhMDAwIQ0KWyAgMTUzLjkwMDY4NV0gMzNj
MWYgaXMgMjU1MTYwMDAhDQpbICAxNTMuOTE4NjM5XSAzM2MyMCBpcyAyNTUxNTAwMCENClsg
IDE1My45MzQ0NzBdIDMzYzIxIGlzIDI1NTE0MDAwIQ0KWyAgMTUzLjk0NzAxNl0gMzNjMjIg
aXMgMjU1MTIwMDAhDQpbICAxNTMuOTU1MjQ4XSAzM2MzOCBpcyAyNTUxODAwMCENClsgIDE1
My45NTc1NzddIDMzYzM5IGlzIDI1NTBmMDAwIQ0KWyAgMTUzLjk3MTI0N10gMzNjM2EgaXMg
MjU1MTEwMDAhDQpbICAxNTMuOTc3NzU4XSAzM2MzYiBpcyAyNTUwNjAwMCENClsgIDE1My45
Nzk5NzFdIDMzYzIzIGlzIDI1NTA3MDAwIQ0KWyAgMTUzLjk5MDA2MF0gMzNjM2MgaXMgMjU1
MTAwMDAhDQpbICAxNTMuOTkyMzAyXSAzM2MzZCBpcyAyNTUwYjAwMCENClsgIDE1My45OTQ2
ODhdIDMzYzNlIGlzIDI1NTE5MDAwIQ0KWyAgMTU0LjAxMzUyNF0gMzNjM2YgaXMgMjU1MGQw
MDAhDQpbICAxNTQuMDQwNDI1XSAzM2MyNCBpcyAyNTUwZTAwMCENClsgIDE1NC4wNDY1NzRd
IDMzYzI1IGlzIDI0ZTI2MDAwIQ0KWyAgMTU0LjA2MjM5MV0gMzNjMjYgaXMgMjRlMTkwMDAh
DQpbICAxNTQuMDY0MzIxXSAzM2M0MCBpcyAyNDlhMDAwMCENClsgIDE1NC4wNjYxODFdIDMz
YzQxIGlzIDI1NTIxMDAwIQ0KWyAgMTU0LjA2ODA2Ml0gMzNjNDIgaXMgMjU1MjAwMDAhDQpb
ICAxNTQuMDgwMTA0XSAzM2M0MyBpcyAyNGJjNzAwMCENClsgIDE1NC4wODIzMzFdIDMzYzQ0
IGlzIDI1NTBhMDAwIQ0KWyAgMTU0LjEwMjEwM10gMzNjNDUgaXMgMjQ2M2UwMDAhDQpbICAx
NTQuMTEyNDg3XSAzM2MyNyBpcyAyNTUxYzAwMCENClsgIDE1NC4xMTQ0NTZdIDMzYzQ2IGlz
IDI1NTFkMDAwIQ0KWyAgMTU0LjExNjM2N10gMzNjNDcgaXMgMjU1MWUwMDAhDQpbICAxNTQu
MTE4Mjg3XSAzM2M0OCBpcyAyNGUxYjAwMCENClsgIDE1NC4xMjA2MTJdIDMzYzQ5IGlzIDI1
NTFiMDAwIQ0KWyAgMTU0LjEyMjkzOV0gMzNjNGEgaXMgMjRiYzQwMDAhDQpbICAxNTQuMTI1
MzAxXSAzM2M0YiBpcyAyNGJjMzAwMCENClsgIDE1NC4xMjc2MzZdIDMzYzI4IGlzIDI1NGZh
MDAwIQ0KWyAgMTU0LjEzNDg4OV0gMzNjMjkgaXMgMjU0ZjkwMDAhDQpbICAxNTQuMTM3Mzky
XSAzM2M0YyBpcyAyNTRmODAwMCENClsgIDE1NC4xMzk3NjRdIDMzYzRkIGlzIDI1NGY3MDAw
IQ0KWyAgMTU0LjE2Mzk2NF0gMzNjNGUgaXMgMjU0ZjYwMDAhDQpbICAxNTQuMTY2MzE5XSAz
M2MyYSBpcyAyNTRmNTAwMCENClsgIDE1NC4xNzc1NjddIDMzYzRmIGlzIDI1NGY0MDAwIQ0K
WyAgMTU0LjE3OTk0Ml0gMzNjNTAgaXMgMjU0ZjMwMDAhDQpbICAxNTQuMTkwMDAzXSAzM2M1
MSBpcyAyNTRmMjAwMCENClsgIDE1NC4xOTI0ODZdIDMzYzUyIGlzIDI1NGYxMDAwIQ0KWyAg
MTU0LjE5NDk1Nl0gMzNjNTMgaXMgMjU0ZjAwMDAhDQpbICAxNTQuMTk3NDAxXSAzM2M1NCBp
cyAyNTRlZjAwMCENClsgIDE1NC4xOTk3NDBdIDMzYzU1IGlzIDI1NGVlMDAwIQ0KWyAgMTU0
LjIwMjIzMF0gMzNjNTYgaXMgMjU0ZWQwMDAhDQpbICAxNTQuMjM3NjEwXSAzM2M1NyBpcyAy
NTRlYzAwMCENClsgIDE1NC4yMzk5MTNdIDMzYzU4IGlzIDI1NGViMDAwIQ0KWyAgMTU0LjI0
MjM2N10gMzNjNTkgaXMgMjU0ZWEwMDAhDQpbICAxNTQuMjQ0NzQ0XSAzM2M1YSBpcyAyNTRl
OTAwMCENClsgIDE1NC4yNDY5MjVdIDMzYzViIGlzIDI1NGU4MDAwIQ0KWyAgMTU0LjI2Njk4
OV0gMzNjNWMgaXMgMjU0ZTcwMDAhDQpbICAxNTQuMjY5MjQ4XSAzM2MyYiBpcyAyNTRlNjAw
MCENClsgIDE1NC4yOTYzNDhdIDMzYzVkIGlzIDI1NGU1MDAwIQ0KWyAgMTU0LjMwMTQwM10g
MzNjMmMgaXMgMjU0ZTQwMDAhDQpbICAxNTQuMzAzODExXSAzM2MyZCBpcyAyNTRlMzAwMCEN
ClsgIDE1NC4zMDYwMDldIDMzYzVlIGlzIDI1NGUyMDAwIQ0KWyAgMTU0LjMzMDMzOV0gMzNj
NWYgaXMgMjU0ZTEwMDAhDQpbICAxNTQuMzQxODEwXSAzM2MyZSBpcyAyNTRlMDAwMCENClsg
IDE1NC4zNjI0MzhdIDMzYzYwIGlzIDI1NGRmMDAwIQ0KWyAgMTU0LjM3MjQwOF0gMzNjMmYg
aXMgMjU0ZGUwMDAhDQpbICAxNTQuMzc2ODEyXSAzM2M2MSBpcyAyNTRkZDAwMCENClsgIDE1
NC4zODY5NjldIDMzYzYyIGlzIDI1NGRjMDAwIQ0KWyAgMTU0LjM5NzY0MV0gMzNjNjMgaXMg
MjU0ZGIwMDAhDQpbICAxNTQuNDEzMzU3XSAzM2M2NCBpcyAyNTRkYTAwMCENClsgIDE1NC40
MjYwMTRdIDMzYzY1IGlzIDI1NGQ5MDAwIQ0KWyAgMTU0LjQyODI4OV0gMzNjNjYgaXMgMjU0
ZDgwMDAhDQpbICAxNTQuNDM4NDI3XSAzM2M2NyBpcyAyNTRkNzAwMCENClsgIDE1NC40NDQy
MzhdIDMzYzY4IGlzIDI1NGQ2MDAwIQ0KWyAgMTU0LjQ2NDMyOV0gMzNjNjkgaXMgMjU0ZDUw
MDAhDQpbICAxNTQuNDY2NTE5XSAzM2MzMCBpcyAyNTRkNDAwMCENClsgIDE1NC40NzM0OThd
IDMzYzZhIGlzIDI1NGQzMDAwIQ0KWyAgMTU0LjQ4MTg5OF0gMzNjNmIgaXMgMjU0ZDIwMDAh
DQpbICAxNTQuNDg0MTQ4XSAzM2M2YyBpcyAyNTRkMTAwMCENClsgIDE1NC40OTM5MjldIDMz
YzZkIGlzIDI1NGQwMDAwIQ0KWyAgMTU0LjUwMDQyMV0gMzNjNmUgaXMgMjU0Y2YwMDAhDQpb
ICAxNTQuNTA5ODg5XSAzM2M3MCBpcyAyNTRjZTAwMCENClsgIDE1NC41MTIxODZdIDMzYzhl
IGlzIDI1NGNkMDAwIQ0KWyAgMTU0LjUxNDQ2NV0gMzNjNzEgaXMgMjU0Y2MwMDAhDQpbICAx
NTQuNTE2NjYwXSAzM2M3MiBpcyAyNTRjYjAwMCENClsgIDE1NC41MTg5MjNdIDMzYzczIGlz
IDI1NGNhMDAwIQ0KWyAgMTU0LjUyMTIyMV0gMzNjNzQgaXMgMjU0YzkwMDAhDQpbICAxNTQu
NTIzNDc5XSAzM2M3NSBpcyAyNTRjODAwMCENClsgIDE1NC41NDE1MzJdIDMzYzc3IGlzIDI1
NGM3MDAwIQ0KWyAgMTU0LjU0MzYzOV0gMzNjNzYgaXMgMjU0YzYwMDAhDQpbICAxNTQuNTQ1
OTI0XSAzM2M3OCBpcyAyNTRjNTAwMCENClsgIDE1NC41NDgwOTRdIDMzYzhmIGlzIDI1NGM0
MDAwIQ0KWyAgMTU0LjU1MDI4NF0gMzNjNzkgaXMgMjU0YzMwMDAhDQpbICAxNTQuNTUyNTU3
XSAzM2M3YSBpcyAyNTRjMjAwMCENClsgIDE1NC41NTU2NDZdIDMzYzkwIGlzIDI1NGMxMDAw
IQ0KWyAgMTU0LjU1Nzc5NV0gMzNjN2IgaXMgMjU0YzAwMDAhDQpbICAxNTQuNTU5OTM5XSAz
M2M5MSBpcyAyNTRiZjAwMCENClsgIDE1NC41NjIwOTldIDMzYzdjIGlzIDI1NGJlMDAwIQ0K
WyAgMTU0LjU2NDIzNl0gMzNjOTIgaXMgMjU0YmQwMDAhDQpbICAxNTQuNTY2NDE2XSAzM2M5
MyBpcyAyNTRiYzAwMCENClsgIDE1NC41Njg1NDddIDMzYzdkIGlzIDI1NGJiMDAwIQ0KWyAg
MTU0LjU3MDY2MF0gMzNjOTQgaXMgMjU0YmEwMDAhDQpbICAxNTQuNTcyODA2XSAzM2M5NSBp
cyAyNTRiOTAwMCENClsgIDE1NC41NzQ5ODNdIDMzYzdlIGlzIDI1NGI4MDAwIQ0KWyAgMTU0
LjYwNjE1Nl0gMzNjN2YgaXMgMjU0YjcwMDAhDQpbICAxNTQuNjA4MzI1XSAzM2M5NiBpcyAy
NTRiNjAwMCENClsgIDE1NC42MTA0ODFdIDMzYzk3IGlzIDI1NGI1MDAwIQ0KWyAgMTU0LjYx
MjY1Nl0gMzNjOTggaXMgMjU0YjQwMDAhDQpbICAxNTQuNjE0ODIyXSAzM2M4MCBpcyAyNTRi
MzAwMCENClsgIDE1NC42MTY5MzddIDMzYzk5IGlzIDI1NGIyMDAwIQ0KWyAgMTU0LjY3NTAw
Ml0gMzNjODEgaXMgMjU0YjEwMDAhDQpbICAxNTQuNjc3MTc0XSAzM2M5YSBpcyAyNTRiMDAw
MCENClsgIDE1NC42ODU3MTBdIDMzYzliIGlzIDI1NGFmMDAwIQ0KWyAgMTU0LjY4ODAwNV0g
MzNjODIgaXMgMjU0YWUwMDAhDQpbICAxNTQuNjkwMjM3XSAzM2M4MyBpcyAyNTRhZDAwMCEN
ClsgIDE1NC42OTI0MTBdIDMzYzg0IGlzIDI1NGFjMDAwIQ0KWyAgMTU0LjY5NDYxMl0gMzNj
ODUgaXMgMjU0YWIwMDAhDQpbICAxNTQuNzAwNDc1XSAzM2M5YyBpcyAyNTRhYTAwMCENClsg
IDE1NC43MDI3MDNdIDMzYzg2IGlzIDI1NGE5MDAwIQ0KWyAgMTU0LjcwNTA4NV0gMzNjODcg
aXMgMjU0YTgwMDAhDQpbICAxNTQuNzA3NDEzXSAzM2M4OCBpcyAyNTRhNzAwMCENClsgIDE1
NC43MjY4OTBdIDMzYzg5IGlzIDI1NGE2MDAwIQ0KWyAgMTU0LjczOTk5M10gMzNjOWQgaXMg
MjU0YTUwMDAhDQpbICAxNTQuNzU3MzY4XSAzM2M4YSBpcyAyNTRhNDAwMCENClsgIDE1NC43
NzkxNjZdIDMzYzllIGlzIDI1NGEzMDAwIQ0KWyAgMTU0Ljc5MjgxNl0gMzNjOWYgaXMgMjU0
YTIwMDAhDQpbICAxNTQuODAzOTI2XSAzM2M4YyBpcyAyNTRhMTAwMCENClsgIDE1NC44MDcw
NjddIDMzYzhkIGlzIDI1NDYyMDAwIQ0KWyAgMTU0LjgyNzU5Nl0gMzNjYWQgaXMgMjU0NjMw
MDAhDQpbICAxNTQuODMxNTQ5XSAzM2NhMCBpcyAyNTQ2NDAwMCENClsgIDE1NC44MzM3NjFd
IDMzY2FlIGlzIDI1NDY1MDAwIQ0KWyAgMTU0Ljg0Mzk5OV0gMzNjYWYgaXMgMjU0NjYwMDAh
DQpbICAxNTQuODg2MzAyXSAzM2NiMSBpcyAyNTQ2NzAwMCENClsgIDE1NC45MTE4MTJdIDMz
Y2IyIGlzIDI1NDY4MDAwIQ0KWyAgMTU0LjkzMDUzNF0gMzNjYjMgaXMgMjU0NjkwMDAhDQpb
ICAxNTQuOTUzNzM3XSAzM2NiNCBpcyAyNTQ2YTAwMCENClsgIDE1NC45NTU5NzhdIDM2NGVj
IGlzIDI1NDZiMDAwIQ0KWyAgMTU0Ljk2MjM3Nl0gMzNjYjYgaXMgMjU0NmMwMDAhDQpbICAx
NTQuOTcwNTkwXSAzM2NiNyBpcyAyNTQ2ZDAwMCENClsgIDE1NC45ODI4NjBdIDMzY2I4IGlz
IDI1NDZlMDAwIQ0KWyAgMTU0Ljk4ODQyNF0gMzNjYjkgaXMgMjU0NmYwMDAhDQpbICAxNTQu
OTkyNjQ3XSAzM2NiYSBpcyAyNTQ3MDAwMCENClsgIDE1NS4wMTQ0NjRdIDMzY2JiIGlzIDI1
NDcxMDAwIQ0KWyAgMTU1LjAxNjc4NV0gMzNjOGIgaXMgMjU0NzIwMDAhDQpbICAxNTUuMDMx
MzA5XSAzM2NiZCBpcyAyNTQ3MzAwMCENClsgIDE1NS4wNDA1MDhdIDMzY2JlIGlzIDI1NDc0
MDAwIQ0KWyAgMTU1LjA0Mzk1N10gMzNjYmYgaXMgMjU0NzUwMDAhDQpbICAxNTUuMDY1MDE4
XSAzM2NjMCBpcyAyNTQ3NjAwMCENClsgIDE1NS4wNjczNzldIDMzY2JjIGlzIDI1NDc3MDAw
IQ0KWyAgMTU1LjA4MjMwOF0gMzNjYzEgaXMgMjU0NzgwMDAhDQpbICAxNTUuMDkxMjMyXSAz
NzZiMiBpcyAyNTQ3OTAwMCENClsgIDE1NS4wOTc0NTRdIDMzY2MyIGlzIDI1NDdhMDAwIQ0K
WyAgMTU1LjA5OTc0Ml0gMzNjYzMgaXMgMjU0N2IwMDAhDQpbICAxNTUuMTA3ODIzXSAzM2Nj
NCBpcyAyNTQ3YzAwMCENClsgIDE1NS4xMTAxMzNdIDMzY2M1IGlzIDI1NDdkMDAwIQ0KWyAg
MTU1LjExMjQ5Ml0gMzNjYzYgaXMgMjU0N2UwMDAhDQpbICAxNTUuMTIzMTYzXSAzM2NjNyBp
cyAyNTQ3ZjAwMCENClsgIDE1NS4xMjY2MzJdIDMzY2ExIGlzIDI1NDliMDAwIQ0KWyAgMTU1
LjEzMDE2OF0gMzNjYTIgaXMgMjU0OGMwMDAhDQpbICAxNTUuMTU1MTA0XSAzM2NhMyBpcyAy
NTQ4ZDAwMCENClsgIDE1NS4xNzE0NDBdIDMzY2E0IGlzIDI1NDhiMDAwIQ0KWyAgMTU1LjE3
MzkyM10gMzNjYTUgaXMgMjU0OTIwMDAhDQpbICAxNTUuMTc1Nzc2XSAzM2NjOCBpcyAyNTQ5
MTAwMCENClsgIDE1NS4xNzc2NThdIDMzY2M5IGlzIDI1NDkwMDAwIQ0KWyAgMTU1LjE3OTQ5
MV0gMzNjY2EgaXMgMjU0OGEwMDAhDQpbICAxNTUuMTk5NDM1XSAzM2NhNiBpcyAyNTQ5MzAw
MCENClsgIDE1NS4yMjg2MjJdIDMzY2E3IGlzIDI1NDk1MDAwIQ0KWyAgMTU1LjI1OTI2MV0g
MzNjYTggaXMgMjU0OGYwMDAhDQpbICAxNTUuMjkwMDg1XSAzM2NhOSBpcyAyNTQ5ODAwMCEN
ClsgIDE1NS4zMDM1ODFdIDMzY2FiIGlzIDI1NDk2MDAwIQ0KWyAgMTU1LjMzNzg1Nl0gMzNj
YWMgaXMgMjU0ODAwMDAhDQpbICAxNTUuMzU2NTQ3XSAzM2NjYyBpcyAyNTQ4ZTAwMCENClsg
IDE1NS4zNTg0NzFdIDMzY2NiIGlzIDI1NDljMDAwIQ0KWyAgMTU1LjM2MDM1OF0gMzNjZWIg
aXMgMjU0OTcwMDAhDQpbICAxNTUuMzYyMTkwXSAzM2NlYyBpcyAyNTRhMDAwMCENClsgIDE1
NS4zOTAzOTRdIDMzY2NkIGlzIDI1NDlhMDAwIQ0KWyAgMTU1LjQwODIxNl0gMzNjY2UgaXMg
MjU0OTkwMDAhDQpbICAxNTUuNDE1NTA3XSAzM2NlZCBpcyAyNTUxMzAwMCENClsgIDE1NS40
MzQzNDBdIDMzY2VlIGlzIDI1NDg1MDAwIQ0KWyAgMTU1LjQ0MDYxNl0gMzNjZWYgaXMgMjU0
ODYwMDAhDQpbICAxNTUuNDQyOTc5XSAzM2NmMCBpcyAyNTBiYjAwMCENClsgIDE1NS40Njg4
MzNdIDMzY2YxIGlzIDI1NTIyMDAwIQ0KWyAgMTU1LjQ3MTI2M10gMzNjY2YgaXMgMjUwYmMw
MDAhDQpbICAxNTUuNDkwNzgxXSAzM2NmMiBpcyAyNTQ5ZDAwMCENClsgIDE1NS40OTQ4MzBd
IDMzY2YzIGlzIDI0ZTFhMDAwIQ0KWyAgMTU1LjQ5ODM0OV0gMzNjZjQgaXMgMjU1MjQwMDAh
DQpbICAxNTUuNTAwODM2XSAzM2NmNSBpcyAyNTUyMzAwMCENClsgIDE1NS41MTE3MzFdIDMz
Y2Y2IGlzIDI1NDYxMDAwIQ0KWyAgMTU1LjUzMDE5MV0gMzNjZjcgaXMgMjU0ZmMwMDAhDQpb
ICAxNTUuNTM0MTE4XSAzM2NkMCBpcyAyNTRmYjAwMCENClsgIDE1NS41Mzg2NDRdIDMzY2Y4
IGlzIDI1NDVlMDAwIQ0KWyAgMTU1LjU0NDgyNV0gMzNjZjkgaXMgMjU0NWQwMDAhDQpbICAx
NTUuNTQ5NzIyXSAzM2NmYSBpcyAyNTQ4NDAwMCENClsgIDE1NS41NTI0ODNdIDMzY2ZiIGlz
IDI1NDgzMDAwIQ0KWyAgMTU1LjU1NDk2OF0gMzNjZmMgaXMgMjU0ODIwMDAhDQpbICAxNTUu
NTY0NzgzXSAzM2NmZCBpcyAyNTQ4MTAwMCENClsgIDE1NS41ODA3ODFdIDMzY2ZlIGlzIDI1
NDVjMDAwIQ0KWyAgMTU1LjU4NzI2OF0gMzNjZDEgaXMgMjU0NWIwMDAhDQpbICAxNTUuNjA5
Nzg5XSAzM2NmZiBpcyAyNTQ1YTAwMCENClsgIDE1NS42MjAyMzRdIDMzY2QyIGlzIDI1NDU5
MDAwIQ0KWyAgMTU1LjYyMjY0MF0gMzNkMDAgaXMgMjU0NTgwMDAhDQpbICAxNTUuNjU3Nzkx
XSAzM2QwMSBpcyAyNTQ1NzAwMCENClsgIDE1NS42ODk3NjZdIDMzY2QzIGlzIDI1NDU2MDAw
IQ0KWyAgMTU1LjY5OTgwOF0gMzNjZDQgaXMgMjU0NTUwMDAhDQpbICAxNTUuNzI4Nzk5XSAz
M2QwMiBpcyAyNTQ1NDAwMCENClsgIDE1NS43NDE0NTNdIDMzY2Q1IGlzIDI1NDQ5MDAwIQ0K
WyAgMTU1Ljc0MzY3Ml0gMzNkMDMgaXMgMjU0NGEwMDAhDQpbICAxNTUuNzQ1NzEzXSAzM2Qw
NCBpcyAyNTQ0YjAwMCENClsgIDE1NS43NDc3NTldIDMzZDA1IGlzIDI1NDRjMDAwIQ0KWyAg
MTU1Ljc0OTY4NV0gMzNkMDYgaXMgMjU0NGQwMDAhDQpbICAxNTUuNzUxNjMwXSAzM2QwNyBp
cyAyNTQ0ZTAwMCENClsgIDE1NS43NTM1NTddIDMzZDA4IGlzIDI1NDRmMDAwIQ0KWyAgMTU1
Ljc1NTQ1Nl0gMzNkMDkgaXMgMjU0NTAwMDAhDQpbICAxNTUuNzU3MzQyXSAzM2QwYSBpcyAy
NTQ1MTAwMCENClsgIDE1NS43NTkyMDZdIDMzZDBiIGlzIDI1NDUyMDAwIQ0KWyAgMTU1Ljc2
MTA0OV0gMzNkMGMgaXMgMjU0NTMwMDAhDQpbICAxNTUuNzYyOTQwXSAzM2QxOCBpcyAyNTQz
NDAwMCENClsgIDE1NS43NjQ3OTFdIDMzZDE5IGlzIDI1NDM1MDAwIQ0KWyAgMTU1Ljc2NjU5
MV0gMzNkMWEgaXMgMjU0MzYwMDAhDQpbICAxNTUuNzY4Mzk4XSAzM2QxYiBpcyAyNTQzNzAw
MCENClsgIDE1NS43NzAxNzZdIDMzZDFjIGlzIDI1NDM4MDAwIQ0KWyAgMTU1Ljc3MTk1NV0g
MzNkMWQgaXMgMjU0MzkwMDAhDQpbICAxNTUuNzczNzI0XSAzM2QxZSBpcyAyNTQzYTAwMCEN
ClsgIDE1NS43NzU0ODNdIDMzZDFmIGlzIDI1NDNiMDAwIQ0KWyAgMTU1Ljc3NzI0Nl0gMzNk
MjAgaXMgMjU0M2MwMDAhDQpbICAxNTUuNzc4OTkyXSAzM2QyMSBpcyAyNTQzZDAwMCENClsg
IDE1NS43ODExNzhdIDMzZDIyIGlzIDI1NDI5MDAwIQ0KWyAgMTU1Ljc4Mjk1Nl0gMzNkMjMg
aXMgMjU0MmEwMDAhDQpbICAxNTUuNzg0NzU3XSAzM2QyNCBpcyAyNTQyYjAwMCENClsgIDE1
NS43ODY1MDJdIDMzZDI1IGlzIDI1NDJjMDAwIQ0KWyAgMTU1Ljc4ODI2NV0gMzNkMjYgaXMg
MjU0MmQwMDAhDQpbICAxNTUuNzg5OTgyXSAzM2QyNyBpcyAyNTQyZTAwMCENClsgIDE1NS43
OTE3MDZdIDMzZDI4IGlzIDI1NDJmMDAwIQ0KWyAgMTU1Ljc5MzQ0Nl0gMzNkMjkgaXMgMjU0
MzAwMDAhDQpbICAxNTUuNzk1MTQwXSAzM2QyYSBpcyAyNTQzMTAwMCENClsgIDE1NS43OTY4
NjJdIDMzZDJiIGlzIDI1NDMyMDAwIQ0KWyAgMTU1Ljc5ODUyNl0gMzNkMmMgaXMgMjU0MzMw
MDAhDQpbICAxNTUuODAwMjAwXSAzM2QyZCBpcyAyNTQxZTAwMCENClsgIDE1NS44MDE4NDdd
IDMzZDJlIGlzIDI1NDFmMDAwIQ0KWyAgMTU1LjgwMzUxNF0gMzNkMmYgaXMgMjU0MjAwMDAh
DQpbICAxNTUuODA1MTg5XSAzM2QzMCBpcyAyNTQyMTAwMCENClsgIDE1NS44MDY4NzFdIDMz
ZDMxIGlzIDI1NDIyMDAwIQ0KWyAgMTU1LjgwODU1MF0gMzNkMzIgaXMgMjU0MjMwMDAhDQpb
ICAxNTUuODEwMjM0XSAzM2QzMyBpcyAyNTQyNDAwMCENClsgIDE1NS44MTE5MDJdIDMzZDM0
IGlzIDI1NDI1MDAwIQ0KWyAgMTU1LjgxMzYwMF0gMzNkMzUgaXMgMjU0MjYwMDAhDQpbICAx
NTUuODE1MjYxXSAzM2QzNiBpcyAyNTQyNzAwMCENClsgIDE1NS44MTY5NDVdIDMzZDM3IGlz
IDI1NDI4MDAwIQ0KWyAgMTU1LjgxODU5NV0gMzNkMzggaXMgMjU0MTQwMDAhDQpbICAxNTUu
ODIwMjU4XSAzM2QzOSBpcyAyNTQxNTAwMCENClsgIDE1NS44MjE5NDFdIDMzZDNhIGlzIDI1
NDE2MDAwIQ0KWyAgMTU1LjgyMzYyOV0gMzNkM2IgaXMgMjU0MTcwMDAhDQpbICAxNTUuODI1
MzEwXSAzM2QzYyBpcyAyNTQxODAwMCENClsgIDE1NS44MjY5OTFdIDMzZDNkIGlzIDI1NDE5
MDAwIQ0KWyAgMTU1LjgyODY1OV0gMzNkM2UgaXMgMjU0MWEwMDAhDQpbICAxNTUuODMwMzU2
XSAzM2QzZiBpcyAyNTQxYjAwMCENClsgIDE1NS44MzIwMTddIDMzZDQwIGlzIDI1NDFjMDAw
IQ0KWyAgMTU1LjgzMzcxMV0gMzNkNDEgaXMgMjU0MWQwMDAhDQpbICAxNTUuODM1MzYxXSAz
M2QwZCBpcyAyNTQzZTAwMCENClsgIDE1NS44MzcwMzBdIDMzZDBlIGlzIDI1NDNmMDAwIQ0K
WyAgMTU1LjgzODcwN10gMzNkMGYgaXMgMjU0NDAwMDAhDQpbICAxNTUuODQwMzg4XSAzM2Qx
MCBpcyAyNTQ0MTAwMCENClsgIDE1NS44NDIwODRdIDMzZDExIGlzIDI1NDQyMDAwIQ0KWyAg
MTU1Ljg0MzgxNV0gMzNkMTIgaXMgMjU0NDMwMDAhDQpbICAxNTUuODQ1NDgyXSAzM2QxMyBp
cyAyNTQ0NDAwMCENClsgIDE1NS44NDcxNzldIDMzZDE0IGlzIDI1NDQ1MDAwIQ0KWyAgMTU1
Ljg0ODg1M10gMzNkMTUgaXMgMjU0NDYwMDAhDQpbICAxNTUuODUwNTU2XSAzM2QxNiBpcyAy
NTQ0NzAwMCENClsgIDE1NS44NTIyMjldIDMzZDE3IGlzIDI1NDQ4MDAwIQ0KWyAgMTU1Ljg1
NTYwMV0gMzNkNWEgaXMgMjUzZjQwMDAhDQpbICAxNTUuODU3MzcyXSAzM2Q1YiBpcyAyNTNm
NTAwMCENClsgIDE1NS44NTkwNjhdIDMzZDVjIGlzIDI1M2Y2MDAwIQ0KWyAgMTU1Ljg2MDc2
OF0gMzNkNWQgaXMgMjUzZjcwMDAhDQpbICAxNTUuODYyNDM2XSAzM2Q1ZSBpcyAyNTNmODAw
MCENClsgIDE1NS44NjQxMzldIDMzZDVmIGlzIDI1M2Y5MDAwIQ0KWyAgMTU1Ljg2NTc5NV0g
MzNkNjAgaXMgMjUzZmEwMDAhDQpbICAxNTUuODY3NDgxXSAzM2Q2MSBpcyAyNTNmYjAwMCEN
ClsgIDE1NS44NjkxNTldIDMzZDYyIGlzIDI1M2ZjMDAwIQ0KWyAgMTU1Ljg3MDg1MV0gMzNk
NjMgaXMgMjUzZmQwMDAhDQpbICAxNTUuODcyNTA5XSAzM2Q0MiBpcyAyNTQwOTAwMCENClsg
IDE1NS44NzQyMDNdIDMzZDQzIGlzIDI1NDBhMDAwIQ0KWyAgMTU1Ljg3NTg4NF0gMzNkNDQg
aXMgMjU0MGIwMDAhDQpbICAxNTUuODc3NTY2XSAzM2Q0NSBpcyAyNTQwYzAwMCENClsgIDE1
NS44NzkyNDZdIDMzZDQ2IGlzIDI1NDBkMDAwIQ0KWyAgMTU1Ljg4MDkyM10gMzNkNDcgaXMg
MjU0MGUwMDAhDQpbICAxNTUuODgyNTg3XSAzM2Q0YSBpcyAyNTQwZjAwMCENClsgIDE1NS44
ODQyODddIDMzZDRiIGlzIDI1NDEwMDAwIQ0KWyAgMTU1Ljg4NTk0NV0gMzNkNGMgaXMgMjU0
MTEwMDAhDQpbICAxNTUuODg3NjMwXSAzM2Q0ZCBpcyAyNTQxMjAwMCENClsgIDE1NS44ODky
OTZdIDMzZDRlIGlzIDI1NDEzMDAwIQ0KWyAgMTU1Ljg5MDk2MF0gMzNkNGYgaXMgMjUzZmUw
MDAhDQpbICAxNTUuODkyNjQzXSAzM2Q1MCBpcyAyNTNmZjAwMCENClsgIDE1NS44OTQzMjVd
IDMzZDUxIGlzIDI1NDAwMDAwIQ0KWyAgMTU1Ljg5NjAwN10gMzNkNTIgaXMgMjU0MDEwMDAh
DQpbICAxNTUuODk3NjkzXSAzM2Q1MyBpcyAyNTQwMjAwMCENClsgIDE1NS44OTkzNjhdIDMz
ZDU0IGlzIDI1NDAzMDAwIQ0KWyAgMTU1LjkwMTA3MF0gMzNkNTUgaXMgMjU0MDQwMDAhDQpb
ICAxNTUuOTAyNzUzXSAzM2Q1NiBpcyAyNTQwNTAwMCENClsgIDE1NS45MDQ0NjldIDMzZDU3
IGlzIDI1NDA2MDAwIQ0KWyAgMTU1LjkwNjE1Ml0gMzNkNTggaXMgMjU0MDcwMDAhDQpbICAx
NTUuOTA3ODUwXSAzM2Q1OSBpcyAyNTQwODAwMCENClsgIDE1NS45MTA0NTldIDMzZDZmIGlz
IDI1M2RlMDAwIQ0KWyAgMTU1LjkxMjE1OF0gMzNkNzAgaXMgMjUzZGYwMDAhDQpbICAxNTUu
OTE0MTA0XSAzM2Q3MSBpcyAyNTNlMDAwMCENClsgIDE1NS45MTU4MDZdIDMzZDcyIGlzIDI1
M2UxMDAwIQ0KWyAgMTU1LjkxNzU0Ml0gMzNkNzMgaXMgMjUzZTIwMDAhDQpbICAxNTUuOTE5
MjQ3XSAzM2Q3NCBpcyAyNTNlMzAwMCENClsgIDE1NS45MjA5NzFdIDMzZDc1IGlzIDI1M2U0
MDAwIQ0KWyAgMTU1LjkyMjY2Ml0gMzNkNzYgaXMgMjUzZTUwMDAhDQpbICAxNTUuOTI0MzY0
XSAzM2Q3NyBpcyAyNTNlNjAwMCENClsgIDE1NS45MjYwODNdIDMzZDc4IGlzIDI1M2U3MDAw
IQ0KWyAgMTU1LjkyNzc2MV0gMzNkNzkgaXMgMjUzZTgwMDAhDQpbICAxNTUuOTI5NDY3XSAz
M2Q3YSBpcyAyNTNkNDAwMCENClsgIDE1NS45MzExNDJdIDMzZDdiIGlzIDI1M2Q1MDAwIQ0K
WyAgMTU1LjkzMjgwOV0gMzNkN2MgaXMgMjUzZDYwMDAhDQpbICAxNTUuOTM0NTE0XSAzM2Q3
ZCBpcyAyNTNkNzAwMCENClsgIDE1NS45MzYxODFdIDMzZDdlIGlzIDI1M2Q4MDAwIQ0KWyAg
MTU1LjkzNzg4Ml0gMzNkN2YgaXMgMjUzZDkwMDAhDQpbICAxNTUuOTM5NTQ5XSAzM2Q4MCBp
cyAyNTNkYTAwMCENClsgIDE1NS45NDEyMzddIDMzZDgxIGlzIDI1M2RiMDAwIQ0KWyAgMTU1
Ljk0MjkzMV0gMzNkODIgaXMgMjUzZGMwMDAhDQpbICAxNTUuOTQ0NjE5XSAzM2Q4MyBpcyAy
NTNkZDAwMCENClsgIDE1NS45NDYyOTFdIDMzZDZlIGlzIDI1M2I4MDAwIQ0KWyAgMTU1Ljk0
Nzk2Nl0gMzNkNmQgaXMgMjUzYjEwMDAhDQpbICAxNTUuOTQ5NjE2XSAzM2Q2YyBpcyAyNTNi
MDAwMCENClsgIDE1NS45NTEyOTFdIDMzZDZiIGlzIDI1M2FmMDAwIQ0KWyAgMTU1Ljk1Mjk0
Nl0gMzNkNmEgaXMgMjUzYWUwMDAhDQpbICAxNTUuOTU0NjMzXSAzM2Q2OSBpcyAyNTNhZDAw
MCENClsgIDE1NS45NTYyNzZdIDMzZDY4IGlzIDI1M2FjMDAwIQ0KWyAgMTU1Ljk1NzkzNF0g
MzNkNjcgaXMgMjUzYWIwMDAhDQpbICAxNTUuOTU5NTk1XSAzM2Q2NiBpcyAyNTNhYTAwMCEN
ClsgIDE1NS45NjEyNTJdIDMzZDY1IGlzIDI1M2E5MDAwIQ0KWyAgMTU1Ljk2MjkyNF0gMzNk
NjQgaXMgMjUzYTgwMDAhDQpbICAxNTUuOTY1Nzg3XSAzM2NkZiBpcyAyNTNjODAwMCENClsg
IDE1NS45Njc2NjZdIDMzY2RlIGlzIDI1M2M5MDAwIQ0KWyAgMTU1Ljk2OTMxOF0gMzNjZGQg
aXMgMjUzY2EwMDAhDQpbICAxNTUuOTcxMDA1XSAzM2NkYyBpcyAyNTNhNzAwMCENClsgIDE1
NS45NzI2NzJdIDMzY2RiIGlzIDI0ZTlkMDAwIQ0KWyAgMTU1Ljk3NDM4MV0gMzNjZGEgaXMg
MjQ4ZmEwMDAhDQpbICAxNTUuOTc2MDkyXSAzM2NkOSBpcyAyNTNiNjAwMCENClsgIDE1NS45
Nzc4MjBdIDMzY2Q4IGlzIDI0ZTljMDAwIQ0KWyAgMTU1Ljk3OTU3M10gMzNjZDcgaXMgMjU0
ODcwMDAhDQpbICAxNTUuOTgxMzQwXSAzM2NkNiBpcyAyNTNjYjAwMCENClsgIDE1NS45ODMx
MTBdIDMzZDg0IGlzIDI1M2NkMDAwIQ0KWyAgMTU1Ljk4NDkxOV0gMzNjZWEgaXMgMjUzOWQw
MDAhDQpbICAxNTUuOTg2Njk1XSAzM2NlOSBpcyAyNTM5ZTAwMCENClsgIDE1NS45ODg1MDNd
IDMzY2U4IGlzIDI1MzlmMDAwIQ0KWyAgMTU1Ljk5MDI5NV0gMzNjZTcgaXMgMjUzYTAwMDAh
DQpbICAxNTUuOTkyMDk5XSAzM2NlNiBpcyAyNTNhMTAwMCENClsgIDE1NS45OTM5MDNdIDMz
Y2U1IGlzIDI1M2EyMDAwIQ0KWyAgMTU1Ljk5NTY5OV0gMzNjZTQgaXMgMjUzYTMwMDAhDQpb
ICAxNTUuOTk3NDkwXSAzM2NlMyBpcyAyNTNhNDAwMCENClsgIDE1NS45OTkyNjZdIDMzY2Uy
IGlzIDI1M2E1MDAwIQ0KWyAgMTU2LjAwMTA3NF0gMzNjZTEgaXMgMjUzYTYwMDAhDQpbICAx
NTYuMDAyODU2XSAzM2NlMCBpcyAyNTNjNzAwMCENClsgIDE1Ni4wMDQ5NTBdIDMzZDk0IGlz
IDI1Mzg4MDAwIQ0KWyAgMTU2LjAwNjc3OV0gMzNkOTUgaXMgMjUzODkwMDAhDQpbICAxNTYu
MDA4NTg5XSAzM2Q5NiBpcyAyNTM4YTAwMCENClsgIDE1Ni4wMTAzOTNdIDMzZDk3IGlzIDI1
MzhiMDAwIQ0KWyAgMTU2LjAxMjE4Nl0gMzNkOTggaXMgMjUzOGMwMDAhDQpbICAxNTYuMDE0
MDEyXSAzM2Q5OSBpcyAyNTM4ZDAwMCENClsgIDE1Ni4wMTU4MDVdIDMzZDlhIGlzIDI1Mzhl
MDAwIQ0KWyAgMTU2LjAxNzYzMF0gMzNkOWIgaXMgMjUzOGYwMDAhDQpbICAxNTYuMDE5NDE3
XSAzM2Q5YyBpcyAyNTM5MDAwMCENClsgIDE1Ni4wMjEyNDJdIDMzZDlkIGlzIDI1MzkxMDAw
IQ0KWyAgMTU2LjAyMzAyOV0gMzNkOWUgaXMgMjUzOTIwMDAhDQpbICAxNTYuMDI0ODQ3XSAz
M2Q4YSBpcyAyNTM5MzAwMCENClsgIDE1Ni4wMjY2NDBdIDMzZDhiIGlzIDI1Mzk0MDAwIQ0K
WyAgMTU2LjAyODQzMF0gMzNkOGMgaXMgMjUzOTUwMDAhDQpbICAxNTYuMDMwMjE2XSAzM2Q4
ZCBpcyAyNTM5NjAwMCENClsgIDE1Ni4wMzE5NjNdIDMzZDhlIGlzIDI1Mzk3MDAwIQ0KWyAg
MTU2LjAzMzcyM10gMzNkOGYgaXMgMjUzOTgwMDAhDQpbICAxNTYuMDM1NDMwXSAzM2Q5MCBp
cyAyNTM5OTAwMCENClsgIDE1Ni4wMzcxNDBdIDMzZDkxIGlzIDI1MzlhMDAwIQ0KWyAgMTU2
LjAzODgyOV0gMzNkOTIgaXMgMjUzOWIwMDAhDQpbICAxNTYuMDQwNTEwXSAzM2Q5MyBpcyAy
NTM5YzAwMCENClsgIDE1Ni4wNDIxOTNdIDMzZDlmIGlzIDI1MzdkMDAwIQ0KWyAgMTU2LjA0
Mzg4MF0gMzNkYTAgaXMgMjUzN2UwMDAhDQpbICAxNTYuMDQ1NTcyXSAzM2RhMSBpcyAyNTM3
ZjAwMCENClsgIDE1Ni4wNDcyNTNdIDMzZGEyIGlzIDI1MzgwMDAwIQ0KWyAgMTU2LjA0ODkz
Ml0gMzNkYTMgaXMgMjUzODEwMDAhDQpbICAxNTYuMDUwNjQyXSAzM2RhNCBpcyAyNTM4MjAw
MCENClsgIDE1Ni4wNTIzMjBdIDMzZGE1IGlzIDI1MzgzMDAwIQ0KWyAgMTU2LjA1NDAzM10g
MzNkYTYgaXMgMjUzODQwMDAhDQpbICAxNTYuMDU1NzE3XSAzM2RhNyBpcyAyNTM4NTAwMCEN
ClsgIDE1Ni4wNTczOTldIDMzZGE4IGlzIDI1Mzg2MDAwIQ0KWyAgMTU2LjA1OTA3Nl0gMzNk
YTkgaXMgMjUzODcwMDAhDQpbICAxNTYuMDYwNzQxXSAzM2RhYyBpcyAyNTM3MzAwMCENClsg
IDE1Ni4wNjI0MTVdIDMzZGFkIGlzIDI1Mzc0MDAwIQ0KWyAgMTU2LjA2NDA5N10gMzNkYWUg
aXMgMjUzNzUwMDAhDQpbICAxNTYuMDY1NzU4XSAzM2RhZiBpcyAyNTM3NjAwMCENClsgIDE1
Ni4wNjc0NDldIDMzZGIwIGlzIDI1Mzc3MDAwIQ0KWyAgMTU2LjA2OTExN10gMzNkYjEgaXMg
MjUzNzgwMDAhDQpbICAxNTYuMDcwODEzXSAzM2RiMiBpcyAyNTM3OTAwMCENClsgIDE1Ni4w
NzI0ODBdIDMzZGIzIGlzIDI1MzdhMDAwIQ0KWyAgMTU2LjA3NDE1Nl0gMzNkYjQgaXMgMjUz
N2IwMDAhDQpbICAxNTYuMDc1ODI4XSAzM2RiNSBpcyAyNTM3YzAwMCENClsgIDE1Ni4wNzkx
NDVdIDMzZGRjIGlzIDI1MzUzMDAwIQ0KWyAgMTU2LjA4MDg5NV0gMzNkZGQgaXMgMjUzNTQw
MDAhDQpbICAxNTYuMDgyNTc1XSAzM2RkZSBpcyAyNTM1NTAwMCENClsgIDE1Ni4wODQyOTdd
IDMzZGRmIGlzIDI1MzU2MDAwIQ0KWyAgMTU2LjA4NTk3MF0gMzNkZTAgaXMgMjUzNTcwMDAh
DQpbICAxNTYuMDg3Njc1XSAzM2RlMSBpcyAyNTM1ODAwMCENClsgIDE1Ni4wODkzNjRdIDMz
ZGUyIGlzIDI1MzU5MDAwIQ0KWyAgMTU2LjA5MTA0OV0gMzNkZTMgaXMgMjUzNWEwMDAhDQpb
ICAxNTYuMDkyNzQxXSAzM2RlNCBpcyAyNTM1YjAwMCENClsgIDE1Ni4wOTQ0MzBdIDMzZGU1
IGlzIDI1MzVjMDAwIQ0KWyAgMTU2LjA5NjExN10gMzNkYjYgaXMgMjUzNjgwMDAhDQpbICAx
NTYuMDk3ODA0XSAzM2Q4NSBpcyAyNTM2OTAwMCENClsgIDE1Ni4wOTk0NzRdIDMzZDg2IGlz
IDI1MzZhMDAwIQ0KWyAgMTU2LjEwMTE3NF0gMzNkODcgaXMgMjUzNmIwMDAhDQpbICAxNTYu
MTAyODMyXSAzM2RjYSBpcyAyNTM2YzAwMCENClsgIDE1Ni4xMDQ1MzFdIDMzZGNiIGlzIDI1
MzZkMDAwIQ0KWyAgMTU2LjEwNjE5MF0gMzNkY2MgaXMgMjUzNmUwMDAhDQpbICAxNTYuMTA3
ODY3XSAzM2RjZCBpcyAyNTM2ZjAwMCENClsgIDE1Ni4xMDk1NDddIDMzZGNlIGlzIDI1Mzcw
MDAwIQ0KWyAgMTU2LjExMTIxOF0gMzNkY2YgaXMgMjUzNzEwMDAhDQpbICAxNTYuMTEyODk2
XSAzM2RkMCBpcyAyNTM3MjAwMCENClsgIDE1Ni4xMTQ1NzddIDMzZGQxIGlzIDI1MzVkMDAw
IQ0KWyAgMTU2LjExNjI1OV0gMzNkZDIgaXMgMjUzNWUwMDAhDQpbICAxNTYuMTE3OTM0XSAz
M2RkMyBpcyAyNTM1ZjAwMCENClsgIDE1Ni4xMTk1OTZdIDMzZGQ0IGlzIDI1MzYwMDAwIQ0K
WyAgMTU2LjEyMTI5NF0gMzNkZDUgaXMgMjUzNjEwMDAhDQpbICAxNTYuMTIyOTU1XSAzM2Rk
NiBpcyAyNTM2MjAwMCENClsgIDE1Ni4xMjQ2NDVdIDMzZGQ3IGlzIDI1MzYzMDAwIQ0KWyAg
MTU2LjEyNjMwMF0gMzNkZDggaXMgMjUzNjQwMDAhDQpbICAxNTYuMTI3OTcwXSAzM2RkOSBp
cyAyNTM2NTAwMCENClsgIDE1Ni4xMjk2MzddIDMzZGRhIGlzIDI1MzY2MDAwIQ0KWyAgMTU2
LjEzMTMwMl0gMzNkZGIgaXMgMjUzNjcwMDAhDQpbICAxNTYuMTMzOTg0XSAzM2RmMSBpcyAy
NTMzZDAwMCENClsgIDE1Ni4xMzU2NzBdIDMzZGYyIGlzIDI1MzNlMDAwIQ0KWyAgMTU2LjEz
NzQwMF0gMzNkZjMgaXMgMjUzM2YwMDAhDQpbICAxNTYuMTM5MTI0XSAzM2RmNCBpcyAyNTM0
MDAwMCENClsgIDE1Ni4xNDA4MTZdIDMzZGY1IGlzIDI1MzQxMDAwIQ0KWyAgMTU2LjE0MjUy
MF0gMzNkZjYgaXMgMjUzNDIwMDAhDQpbICAxNTYuMTQ0MjE0XSAzM2RmNyBpcyAyNTM0MzAw
MCENClsgIDE1Ni4xNDU5MTNdIDMzZGY4IGlzIDI1MzQ0MDAwIQ0KWyAgMTU2LjE0NzYwNl0g
MzNkZjkgaXMgMjUzNDUwMDAhDQpbICAxNTYuMTQ5Mjg5XSAzM2RmYSBpcyAyNTM0NjAwMCEN
ClsgIDE1Ni4xNTA5NzddIDMzZGZiIGlzIDI1MzQ3MDAwIQ0KWyAgMTU2LjE1MjYzMF0gMzNk
ZmMgaXMgMjUzMzMwMDAhDQpbICAxNTYuMTU0MzMxXSAzM2RmZCBpcyAyNTMzNDAwMCENClsg
IDE1Ni4xNTU5OTBdIDMzZGZlIGlzIDI1MzM1MDAwIQ0KWyAgMTU2LjE1NzY2MV0gMzNkZmYg
aXMgMjUzMzYwMDAhDQpbICAxNTYuMTU5MzM2XSAzM2UwMCBpcyAyNTMzNzAwMCENClsgIDE1
Ni4xNjEwMjVdIDMzZTAxIGlzIDI1MzM4MDAwIQ0KWyAgMTU2LjE2MjcxN10gMzNlMDIgaXMg
MjUzMzkwMDAhDQpbICAxNTYuMTY0NDE0XSAzM2UwMyBpcyAyNTMzYTAwMCENClsgIDE1Ni4x
NjYwNzhdIDMzZTA0IGlzIDI1MzNiMDAwIQ0KWyAgMTU2LjE2Nzc3MV0gMzNlMDUgaXMgMjUz
M2MwMDAhDQpbICAxNTYuMTY5NDI0XSAzM2RmMCBpcyAyNTMyODAwMCENClsgIDE1Ni4xNzEx
MTZdIDMzZGVmIGlzIDI1MzI5MDAwIQ0KWyAgMTU2LjE3Mjc4OV0gMzNkZWUgaXMgMjUzMmEw
MDAhDQpbICAxNTYuMTc0NDcxXSAzM2RlZCBpcyAyNTMyYjAwMCENClsgIDE1Ni4xNzYxNTFd
IDMzZGVjIGlzIDI1MzJjMDAwIQ0KWyAgMTU2LjE3NzgyNl0gMzNkZWIgaXMgMjUzMmQwMDAh
DQpbICAxNTYuMTc5NTA5XSAzM2RlYSBpcyAyNTMyZTAwMCENClsgIDE1Ni4xODExOTFdIDMz
ZGU5IGlzIDI1MzJmMDAwIQ0KWyAgMTU2LjE4Mjg4NF0gMzNkZTggaXMgMjUzMzAwMDAhDQpb
ICAxNTYuMTg0NTgyXSAzM2RlNyBpcyAyNTMzMTAwMCENClsgIDE1Ni4xODYyNTVdIDMzZGU2
IGlzIDI1MzMyMDAwIQ0KWyAgMTU2LjE4ODkzMV0gMzNkYzEgaXMgMjUzMTMwMDAhDQpbICAx
NTYuMTkwNjU5XSAzM2RjMiBpcyAyNTMxNDAwMCENClsgIDE1Ni4xOTIzODFdIDMzZGMzIGlz
IDI1MzE1MDAwIQ0KWyAgMTU2LjE5NDA5Nl0gMzNkYzQgaXMgMjUzMTYwMDAhDQpbICAxNTYu
MTk1ODA3XSAzM2RjNSBpcyAyNTMxNzAwMCENClsgIDE1Ni4xOTc1MDJdIDMzZGM2IGlzIDI1
MzE4MDAwIQ0KWyAgMTU2LjE5OTE4MV0gMzNkYzcgaXMgMjUzMTkwMDAhDQpbICAxNTYuMjAw
ODkzXSAzM2RjOCBpcyAyNTMxYTAwMCENClsgIDE1Ni4yMDI2MDddIDMzZGM5IGlzIDI1MzFi
MDAwIQ0KWyAgMTU2LjIwNDMzOF0gMzNlMDggaXMgMjUzMWMwMDAhDQpbICAxNTYuMjA2MDM5
XSAzM2RjMCBpcyAyNTMwODAwMCENClsgIDE1Ni4yMDc3NTZdIDMzZGJmIGlzIDI1MzA5MDAw
IQ0KWyAgMTU2LjIwOTUwMF0gMzNkYmUgaXMgMjUzMFsgIDE1OC4zMzYxOTddIDMzZjhlIGlz
IDI1OTc5MDAwIQ0KWyAgMTU4LjMzNzkwM10gMzNmOGYgaXMgMjU5N2EwMDAhDQpbICAxNTgu
MzM5NTgxXSAzM2Y5MCBpcyAyNTk3YjAwMCENClsgIDE1OC4zNDEyODJdIDMzZjkxIGlzIDI1
OTdjMDAwIQ0KWyAgMTU4LjM0Mjk5MF0gMzNmOTIgaXMgMjU5N2QwMDAhDQpbICAxNTguMzQ0
NjkyXSAzM2Y5MyBpcyAyNTk3ZTAwMCENClsgIDE1OC4zNDY0MDVdIDMzZjk0IGlzIDI1OTdm
MDAwIQ0KWyAgMTU4LjM0ODEwNl0gMzNmOTUgaXMgMjU5ODAwMDAhDQpbICAxNTguMzQ5Nzkx
XSAzM2Y5NiBpcyAyNTk4MTAwMCENClsgIDE1OC4zNTE1MDhdIDMzZjk3IGlzIDI1OTgyMDAw
IQ0KWyAgMTU4LjM2MDM4MV0gMzNmYjcgaXMgMjU5NDMwMDAhDQpbICAxNTguMzYyMTIzXSAz
M2ZiOCBpcyAyNTk0NDAwMCENClsgIDE1OC4zNjM4NTldIDMzZmI5IGlzIDI1OTQ1MDAwIQ0K
WyAgMTU4LjM2NTYwM10gMzNmYmEgaXMgMjU5NDYwMDAhDQpbICAxNTguMzY3MzY4XSAzM2Zi
YiBpcyAyNTk0NzAwMCENClsgIDE1OC4zNjkwNzJdIDMzZmJjIGlzIDI1OTQ4MDAwIQ0KWyAg
MTU4LjM3MDc4OF0gMzNmYmQgaXMgMjU5NDkwMDAhDQpbICAxNTguMzcyNTAzXSAzM2ZiZSBp
cyAyNTk0YTAwMCENClsgIDE1OC4zNzQyMDldIDMzZmJmIGlzIDI1OTRiMDAwIQ0KWyAgMTU4
LjM3NTkwOV0gMzNmYzAgaXMgMjU5NGMwMDAhDQpbICAxNTguMzc3NjAxXSAzM2ZjMSBpcyAy
NTk0ZDAwMCENClsgIDE1OC4zNzk2NTBdIDMzZmNjIGlzIDI1OTIzMDAwIQ0KWyAgMTU4LjM4
MTMyOF0gMzNmY2QgaXMgMjU5MjQwMDAhDQpbICAxNTguMzgyOTg4XSAzM2ZjZSBpcyAyNTky
NTAwMCENClsgIDE1OC4zODQ2NzVdIDMzZmNmIGlzIDI1OTI2MDAwIQ0KWyAgMTU4LjM4NjMy
OF0gMzNmZDAgaXMgMjU5MjcwMDAhDQpbICAxNTguMzg4MDE5XSAzM2ZkMSBpcyAyNTkyODAw
MCENClsgIDE1OC4zODk2NzldIDMzZmQyIGlzIDI1OTI5MDAwIQ0KWyAgMTU4LjM5MTM0Nl0g
MzNmZDMgaXMgMjU5MmEwMDAhDQpbICAxNTguMzkzMDEwXSAzM2ZkNCBpcyAyNTkyYjAwMCEN
ClsgIDE1OC4zOTQ2NzNdIDMzZmQ1IGlzIDI1OTJjMDAwIQ0KWyAgMTU4LjM5NjMzNl0gMzNm
ZDYgaXMgMjU5MmQwMDAhDQpbICAxNTguMzk3OTg3XSAzM2ZkNyBpcyAyNTkxOTAwMCENClsg
IDE1OC4zOTk2MjhdIDMzZmQ4IGlzIDI1OTFhMDAwIQ0KWyAgMTU4LjQwMTI5Nl0gMzNmZDkg
aXMgMjU5MWIwMDAhDQpbICAxNTguNDAyOTQ0XSAzM2ZkYyBpcyAyNTkxYzAwMCENClsgIDE1
OC40MDQ2MjJdIDMzZmRkIGlzIDI1OTFkMDAwIQ0KWyAgMTU4LjQwNjI3NV0gMzNmZGUgaXMg
MjU5MWUwMDAhDQpbICAxNTguNDA3OTQzXSAzM2ZkZiBpcyAyNTkxZjAwMCENClsgIDE1OC40
MDk2MThdIDMzZmUwIGlzIDI1OTIwMDAwIQ0KWyAgMTU4LjQxMTI5MV0gMzNmZTEgaXMgMjU5
MjEwMDAhDQpbICAxNTguNDEyOTY5XSAzM2ZlMiBpcyAyNTkyMjAwMCENClsgIDE1OC40MTQ2
MzBdIDMzZmI2IGlzIDI1OTJlMDAwIQ0KWyAgMTU4LjQxNjI4NF0gMzNmYjUgaXMgMjU5MmYw
MDAhDQpbICAxNTguNDE3OTY4XSAzM2ZiNCBpcyAyNTkzMDAwMCENClsgIDE1OC40MTk2Mjld
IDMzZmIzIGlzIDI1OTMxMDAwIQ0KWyAgMTU4LjQyMTMxN10gMzNmYjIgaXMgMjU5MzIwMDAh
DQpbICAxNTguNDIyOTg0XSAzM2ZiMSBpcyAyNTkzMzAwMCENClsgIDE1OC40MjQ2NTZdIDMz
ZmIwIGlzIDI1OTM0MDAwIQ0KWyAgMTU4LjQyNjMzM10gMzNmYWYgaXMgMjU5MzUwMDAhDQpb
ICAxNTguNDI4MDE3XSAzM2ZhZSBpcyAyNTkzNjAwMCENClsgIDE1OC40Mjk3MTJdIDMzZmFk
IGlzIDI1OTM3MDAwIQ0KWyAgMTU4LjQzMTQwMl0gMzNmNzggaXMgMjU5MzgwMDAhDQpbICAx
NTguNDMzMDg3XSAzM2ZjMiBpcyAyNTkzOTAwMCENClsgIDE1OC40MzQ3OTldIDMzZmMzIGlz
IDI1OTNhMDAwIQ0KWyAgMTU4LjQzNjQ4OF0gMzNmYzQgaXMgMjU5M2IwMDAhDQpbICAxNTgu
NDM4MjEzXSAzM2ZjNSBpcyAyNTkzYzAwMCENClsgIDE1OC40Mzk4OTddIDMzZmM2IGlzIDI1
OTNkMDAwIQ0KWyAgMTU4LjQ0MTU5M10gMzNmYzcgaXMgMjU5M2UwMDAhDQpbICAxNTguNDQz
Mjk5XSAzM2ZjOCBpcyAyNTkzZjAwMCENClsgIDE1OC40NDQ5ODldIDMzZmM5IGlzIDI1OTQw
MDAwIQ0KWyAgMTU4LjQ0NjY4NF0gMzNmY2EgaXMgMjU5NDEwMDAhDQpbICAxNTguNDQ4MzY3
XSAzM2ZjYiBpcyAyNTk0MjAwMCENClsgIDE1OC40NTg3OTRdIDMzZmVlIGlzIDI1OTAzMDAw
IQ0KWyAgMTU4LjQ2MDYxNV0gMzNmZWYgaXMgMjU5MDQwMDAhDQpbICAxNTguNDYyMzMxXSAz
M2ZmMCBpcyAyNTkwNTAwMCENClsgIDE1OC40NjQwOTldIDMzZmYxIGlzIDI1OTA2MDAwIQ0K
WyAgMTU4LjQ2NTc3N10gMzNmZjIgaXMgMjU5MDcwMDAhDQpbICAxNTguNDY3NDg2XSAzM2Zm
MyBpcyAyNTkwODAwMCENClsgIDE1OC40NjkxNzJdIDMzZmY0IGlzIDI1OTA5MDAwIQ0KWyAg
MTU4LjQ3MDg4OF0gMzNmZjUgaXMgMjU5MGEwMDAhDQpbICAxNTguNDcyNTYzXSAzM2ZmNiBp
cyAyNTkwYjAwMCENClsgIDE1OC40NzQyNDldIDMzZmY3IGlzIDI1OTBjMDAwIQ0KWyAgMTU4
LjQ3NTkzNF0gMzNmZjggaXMgMjU5MGQwMDAhDQpbICAxNTguNDc4NDQ0XSAzM2ZmOSBpcyAy
NThmOTAwMCENClsgIDE1OC40ODAxNTZdIDMzZmZhIGlzIDI1OGZhMDAwIQ0KWyAgMTU4LjQ4
MTg3NV0gMzNmZmIgaXMgMjU4ZmIwMDAhDQpbICAxNTguNDgzNjYyXSAzM2ZmYyBpcyAyNThm
YzAwMCENClsgIDE1OC40ODUzMjddIDMzZmZkIGlzIDI1OGZkMDAwIQ0KWyAgMTU4LjQ4NzAx
MF0gMzNmZmUgaXMgMjU4ZmUwMDAhDQpbICAxNTguNDg4Njk0XSAzM2ZmZiBpcyAyNThmZjAw
MCENClsgIDE1OC40OTAzNzBdIDMyMDAwIGlzIDI1OTAwMDAwIQ0KWyAgMTU4LjQ5MjA3Nl0g
MzIwMDEgaXMgMjU5MDEwMDAhDQpbICAxNTguNDkzNzc2XSAzMjAwMiBpcyAyNTkwMjAwMCEN
ClsgIDE1OC40OTYxOTNdIDMyMDAzIGlzIDI1OGFlMDAwIQ0KWyAgMTU4LjQ5Nzg5Nl0gMzIw
MDQgaXMgMjU4YWYwMDAhDQpbICAxNTguNDk5NTY4XSAzMjAwNSBpcyAyNThiMDAwMCENClsg
IDE1OC41MDEyNzZdIDMyMDA2IGlzIDI1OGIxMDAwIQ0KWyAgMTU4LjUwMjk2Nl0gMzIwMDcg
aXMgMjU4YjIwMDAhDQpbICAxNTguNTA0NjgwXSAzMjAwOCBpcyAyNThiMzAwMCENClsgIDE1
OC41MDYzNjNdIDMyMDA5IGlzIDI1OGI0MDAwIQ0KWyAgMTU4LjUwODA2NF0gMzIwMGEgaXMg
MjU4YjUwMDAhDQpbICAxNTguNTA5Nzc3XSAzMjAwYiBpcyAyNThiNjAwMCENClsgIDE1OC41
MTE0NzhdIDMyMDBjIGlzIDI1OGI3MDAwIQ0KWyAgMTU4LjUxMzE4NF0gMzIwMGQgaXMgMjU4
YjgwMDAhDQpbICAxNTguNTE0ODc1XSAzM2ZlMyBpcyAyNThjMzAwMCENClsgIDE1OC41MTY1
NzBdIDMzZmU0IGlzIDI1OGM0MDAwIQ0KWyAgMTU4LjUxODI4Ml0gMzNmZTUgaXMgMjU4YzUw
MDAhDQpbICAxNTguNTE5OTY2XSAzM2ZlNiBpcyAyNThjNjAwMCENClsgIDE1OC41MjE2Nzld
IDMzZmU3IGlzIDI1OGM3MDAwIQ0KWyAgMTU4LjUyMzM4MV0gMzNmZTggaXMgMjU4YzgwMDAh
DQpbICAxNTguNTI1MDg2XSAzM2ZlOSBpcyAyNThjOTAwMCENClsgIDE1OC41MjY3NzddIDMz
ZmVhIGlzIDI1OGNhMDAwIQ0KWyAgMTU4LjUyODQ1NV0gMzNmZWIgaXMgMjU4Y2IwMDAhDQpb
ICAxNTguNTMwMTYyXSAzM2ZlYyBpcyAyNThjYzAwMCENClsgIDE1OC41MzE4NDZdIDMzZmVk
IGlzIDI1OGNkMDAwIQ0KWyAgMTU4LjUzMzU1MV0gMzIwMTcgaXMgMjU4YjkwMDAhDQpbICAx
NTguNTM1MjQ2XSAzMjAxNiBpcyAyNThiYTAwMCENClsgIDE1OC41MzY5NTRdIDMyMDE1IGlz
IDI1OGJiMDAwIQ0KWyAgMTU4LjUzODY2NV0gMzIwMTQgaXMgMjU4YmMwMDAhDQpbICAxNTgu
NTQwMzczXSAzMjAxMyBpcyAyNThiZDAwMCENClsgIDE1OC41NDIwOTBdIDMyMDEyIGlzIDI1
OGJlMDAwIQ0KWyAgMTU4LjU0MzgwNF0gMzIwMTEgaXMgMjU4YmYwMDAhDQpbICAxNTguNTQ1
NDcwXSAzMjAxMCBpcyAyNThjMDAwMCENClsgIDE1OC41NDcxNzVdIDMyMDBmIGlzIDI1OGMx
MDAwIQ0KWyAgMTU4LjU0ODg2NV0gMzIwMGUgaXMgMjU4YzIwMDAhDQpbICAxNTguNTUxMjU0
XSAzMjAxZiBpcyAyNTg4ZTAwMCENClsgIDE1OC41NTMwMThdIDMyMDFlIGlzIDI1ODhmMDAw
IQ0KWyAgMTU4LjU1NDc0M10gMzIwMWQgaXMgMjU4OTAwMDAhDQpbICAxNTguNTU2NDI3XSAz
MjAxYyBpcyAyNTg5MTAwMCENClsgIDE1OC41NTgxMzNdIDMyMDFiIGlzIDI1ODkyMDAwIQ0K
WyAgMTU4LjU1OTgzOV0gMzIwMWEgaXMgMjU4OTMwMDAhDQpbICAxNTguNTYxNTM1XSAzMjAx
OSBpcyAyNTg5NDAwMCENClsgIDE1OC41NjMyNDFdIDMzZjdiIGlzIDI1ODk1MDAwIQ0KWyAg
MTU4LjU2NDk1OF0gMzNmN2EgaXMgMjU4OTYwMDAhDQpbICAxNTguNTY2NjgwXSAzM2Y3OSBp
cyAyNTg5NzAwMCENClsgIDE1OC41NjgzOTldIDMyMDE4IGlzIDI1ODk4MDAwIQ0KWyAgMTU4
LjU3MDEyNV0gMzIwMjAgaXMgMjU4OTkwMDAhDQpbICAxNTguNTcxODYwXSAzMjAyMSBpcyAy
NTg5YTAwMCENClsgIDE1OC41NzM1ODldIDMyMDIyIGlzIDI1ODliMDAwIQ0KWyAgMTU4LjU3
NTMyNF0gMzIwMjMgaXMgMjU4OWMwMDAhDQpbICAxNTguNTc3MDQ5XSAzMjAyNCBpcyAyNTg5
ZDAwMCENClsgIDE1OC41Nzg3NjJdIDMyMDI1IGlzIDI1ODllMDAwIQ0KWyAgMTU4LjU4MDUw
OV0gMzIwMjYgaXMgMjU4OWYwMDAhDQpbICAxNTguNTgyMjMzXSAzMjAyNyBpcyAyNThhMDAw
MCENClsgIDE1OC41ODM5OTFdIDMyMDI4IGlzIDI1OGExMDAwIQ0KWyAgMTU4LjU4NTcxNV0g
MzIwMjkgaXMgMjU4YTIwMDAhDQpbICAxNTguNTg4NjM4XSAzMjA0YyBpcyAyNTg2MzAwMCEN
ClsgIDE1OC41OTAzNzddIDMyMDRiIGlzIDI1ODY0MDAwIQ0KWyAgMTU4LjU5MjExMV0gMzIw
NGEgaXMgMjU4NjUwMDAhDQpbICAxNTguNTkzODQ3XSAzMjA0OSBpcyAyNTg2NjAwMCENClsg
IDE1OC41OTU1NzNdIDMyMDQ4IGlzIDI1ODY3MDAwIQ0KWyAgMTU4LjU5NzMxNV0gMzIwNDcg
aXMgMjU4NjgwMDAhDQpbICAxNTguNTk5MDI3XSAzMjA0NiBpcyAyNTg2OTAwMCENClsgIDE1
OC42MDA3NjhdIDMyMDQ1IGlzIDI1ODZhMDAwIQ0KWyAgMTU4LjYwMjQ4Nl0gMzIwNDQgaXMg
MjU4NmIwMDAhDQpbICAxNTguNjA0MjMyXSAzMjA0MyBpcyAyNTg2YzAwMCENClsgIDE1OC42
MDU5NTZdIDMyMDQyIGlzIDI1ODZkMDAwIQ0KWyAgMTU4LjYwNzY3NF0gMzIwNDEgaXMgMjU4
NmUwMDAhDQpbICAxNTguNjA5NDEwXSAzMjA0MCBpcyAyNTg2ZjAwMCENClsgIDE1OC42MTEx
MjZdIDMyMDNmIGlzIDI1ODcwMDAwIQ0KWyAgMTU4LjYxMjg2MV0gMzIwM2UgaXMgMjU4NzEw
MDAhDQpbICAxNTguNjE0NTkzXSAzMjAzZCBpcyAyNTg3MjAwMCENClsgIDE1OC42MTYzMTdd
IDMyMDNjIGlzIDI1ODczMDAwIQ0KWyAgMTU4LjYxODA2OV0gMzIwM2IgaXMgMjU4NzQwMDAh
DQpbICAxNTguNjE5Nzc1XSAzMjAzYSBpcyAyNTg3NTAwMCENClsgIDE1OC42MjE1MTBdIDMy
MDM5IGlzIDI1ODc2MDAwIQ0KWyAgMTU4LjYyMzIyMl0gMzIwMzggaXMgMjU4NzcwMDAhDQpb
ICAxNTguNjI0OTQ1XSAzMjAyYSBpcyAyNTg3ODAwMCENClsgIDE1OC42MjY5NTJdIDMyMDYx
IGlzIDI1ODQzMDAwIQ0KWyAgMTU4LjYyODY2MF0gMzIwNjIgaXMgMjU4NDQwMDAhDQpbICAx
NTguNjMwMzg3XSAzMjA2MyBpcyAyNTg0NTAwMCENClsgIDE1OC42MzIwODhdIDMyMDY0IGlz
IDI1ODQ2MDAwIQ0KWyAgMTU4LjYzMzgxMl0gMzIwNjUgaXMgMjU4NDcwMDAhDQpbICAxNTgu
NjM1NTA2XSAzMjA2NiBpcyAyNTg0ODAwMCENClsgIDE1OC42MzcyMDldIDMyMDY3IGlzIDI1
ODQ5MDAwIQ0KWyAgMTU4LjYzODkwMF0gMzIwNjggaXMgMjU4NGEwMDAhDQpbICAxNTguNjQw
NTg1XSAzMjA2OSBpcyAyNTg0YjAwMCENClsgIDE1OC42NDIyNzldIDMyMDZhIGlzIDI1ODRj
MDAwIQ0KWyAgMTU4LjY0Mzk1N10gMzIwNmIgaXMgMjU4NGQwMDAhDQpbICAxNTguNjQ1NjMy
XSAzMjA2YyBpcyAyNTgzOTAwMCENClsgIDE1OC42NDczMTBdIDMyMDZkIGlzIDI1ODNhMDAw
IQ0KWyAgMTU4LjY0ODk3OV0gMzIwNmUgaXMgMjU4M2IwMDAhDQpbICAxNTguNjUwNjc0XSAz
MjA2ZiBpcyAyNTgzYzAwMCENClsgIDE1OC42NTIzNDBdIDMyMDcwIGlzIDI1ODNkMDAwIQ0K
WyAgMTU4LjY1NDAzOV0gMzIwNzEgaXMgMjU4M2UwMDAhDQpbICAxNTguNjU1Njk5XSAzMjA3
MiBpcyAyNTgzZjAwMCENClsgIDE1OC42NTczNjhdIDMyMDczIGlzIDI1ODQwMDAwIQ0KWyAg
MTU4LjY1OTA0NV0gMzIwNzQgaXMgMjU4NDEwMDAhDQpbICAxNTguNjYwNzE4XSAzMjA3NSBp
cyAyNTg0MjAwMCENClsgIDE1OC42NjIzOTldIDMyMDM1IGlzIDI1ODRlMDAwIQ0KWyAgMTU4
LjY2NDA3N10gMzIwMzYgaXMgMjU4NGYwMDAhDQpbICAxNTguNjY1NzI2XSAzMjAzNyBpcyAy
NTg1MDAwMCENClsgIDE1OC42Njc0MTBdIDMyMDU3IGlzIDI1ODUxMDAwIQ0KWyAgMTU4LjY2
OTA2Nl0gMzIwNWEgaXMgMjU4NTIwMDAhDQpbICAxNTguNjcwNzQ3XSAzMjA1YiBpcyAyNTg1
MzAwMCENClsgIDE1OC42NzI0MDhdIDMyMDVjIGlzIDI1ODU0MDAwIQ0KWyAgMTU4LjY3NDA4
MF0gMzIwNWQgaXMgMjU4NTUwMDAhDQpbICAxNTguNjc1NzUxXSAzMjA1ZSBpcyAyNTg1NjAw
MCENClsgIDE1OC42Nzc0MTldIDMyMDVmIGlzIDI1ODU3MDAwIQ0KWyAgMTU4LjY3OTA4Ml0g
MzIwNjAgaXMgMjU4NTgwMDAhDQpbICAxNTguNjgwNzQ0XSAzMjAyYiBpcyAyNTg1OTAwMCEN
ClsgIDE1OC42ODI0MDRdIDMyMDJjIGlzIDI1ODVhMDAwIQ0KWyAgMTU4LjY4NDA4Ml0gMzIw
MmQgaXMgMjU4NWIwMDAhDQpbICAxNTguNjg1NzM3XSAzMjAyZSBpcyAyNTg1YzAwMCENClsg
IDE1OC42ODc0MTldIDMyMDJmIGlzIDI1ODVkMDAwIQ0KWyAgMTU4LjY4OTA3NF0gMzIwMzAg
aXMgMjU4NWUwMDAhDQpbICAxNTguNjkwNzUyXSAzMjAzMSBpcyAyNTg1ZjAwMCENClsgIDE1
OC42OTI0NDVdIDMyMDMyIGlzIDI1ODYwMDAwIQ0KWyAgMTU4LjY5NDEzNV0gMzIwMzMgaXMg
MjU4NjEwMDAhDQpbICAxNTguNjk1ODI0XSAzMjAzNCBpcyAyNTg2MjAwMCENClsgIDE1OC42
OTg2MjNdIDMyMDgxIGlzIDI1ODIzMDAwIQ0KWyAgMTU4LjcwMDMzN10gMzIwODIgaXMgMjU4
MjQwMDAhDQpbICAxNTguNzAyMDIxXSAzMjA4MyBpcyAyNTgyNTAwMCENClsgIDE1OC43MDM3
MTldIDMyMDg0IGlzIDI1ODI2MDAwIQ0KWyAgMTU4LjcwNTQyMF0gMzIwODUgaXMgMjU4Mjcw
MDAhDQpbICAxNTguNzA3MTEyXSAzMjA4NiBpcyAyNTgyODAwMCENClsgIDE1OC43MDg4MTVd
IDMyMDg3IGlzIDI1ODI5MDAwIQ0KWyAgMTU4LjcxMDUxM10gMzIwODggaXMgMjU4MmEwMDAh
DQpbICAxNTguNzEyMjAzXSAzMjA4OSBpcyAyNTgyYjAwMCENClsgIDE1OC43MTM4ODhdIDMy
MDhhIGlzIDI1ODJjMDAwIQ0KWyAgMTU4LjcxNTU1NF0gMzIwOGIgaXMgMjU4MmQwMDAhDQpb
ICAxNTguNzE3MjQ5XSAzMjA3NiBpcyAyNTgyZTAwMCENClsgIDE1OC43MTg5MTldIDMyMDc3
IGlzIDI1ODJmMDAwIQ0KWyAgMTU4LjcyMDYwN10gMzIwNzggaXMgMjU4MzAwMDAhDQpbICAx
NTguNzIyMjc3XSAzMjA3OSBpcyAyNTgzMTAwMCENClsgIDE1OC43MjM5NTddIDMyMDdhIGlz
IDI1ODMyMDAwIQ0KWyAgMTU4LjcyNTYyOF0gMzIwN2IgaXMgMjU4MzMwMDAhDQpbICAxNTgu
NzI3Mjk2XSAzMjA3YyBpcyAyNTgzNDAwMCENClsgIDE1OC43Mjg5NzBdIDMyMDdkIGlzIDI1
ODM1MDAwIQ0KWyAgMTU4LjczMDYzMl0gMzIwN2UgaXMgMjU4MzYwMDAhDQpbICAxNTguNzMy
Mjg2XSAzMjA3ZiBpcyAyNTgzNzAwMCENClsgIDE1OC43MzM5NjRdIDMyMDgwIGlzIDI1ODM4
MDAwIQ0KWyAgMTU4LjczNTg5NF0gMzIwYTEgaXMgMjU4MDMwMDAhDQpbICAxNTguNzM3NTg5
XSAzMjBhMiBpcyAyNTgwNDAwMCENClsgIDE1OC43MzkyNDVdIDMyMGEzIGlzIDI1ODA1MDAw
IQ0KWyAgMTU4Ljc0MDkxM10gMzIwYTQgaXMgMjU4MDYwMDAhDQpbICAxNTguNzQyNTkwXSAz
MjBhNSBpcyAyNTgwNzAwMCENClsgIDE1OC43NDQyNTddIDMyMGE2IGlzIDI1ODA4MDAwIQ0K
WyAgMTU4Ljc0NTkyMl0gMzIwYTcgaXMgMjU4MDkwMDAhDQpbICAxNTguNzQ3NTc4XSAzMjBh
OCBpcyAyNTgwYTAwMCENClsgIDE1OC43NDkyMjhdIDMyMGE5IGlzIDI1ODBiMDAwIQ0KWyAg
MTU4Ljc1MDkwMV0gMzIwYWEgaXMgMjU4MGMwMDAhDQpbICAxNTguNzUyNTQ0XSAzMjBhYiBp
cyAyNTgwZDAwMCENClsgIDE1OC43NTQyMDRdIDMyMGFjIGlzIDI1N2Y5MDAwIQ0KWyAgMTU4
Ljc1NTg0Ml0gMzIwYWQgaXMgMjU3ZmEwMDAhDQpbICAxNTguNzU3NDkyXSAzMjBhZSBpcyAy
NTdmYjAwMCENClsgIDE1OC43NTkxNDFdIDMyMGFmIGlzIDI1N2ZjMDAwIQ0KWyAgMTU4Ljc2
MDc4NF0gMzIwYjAgaXMgMjU3ZmQwMDAhDQpbICAxNTguNzYyNDUwXSAzMjBiMSBpcyAyNTdm
ZTAwMCENClsgIDE1OC43NjQxMTFdIDMyMGIyIGlzIDI1N2ZmMDAwIQ0KWyAgMTU4Ljc2NTc2
Nl0gMzIwYjMgaXMgMjU4MDAwMDAhDQpbICAxNTguNzY3NDYwXSAzMjBiNCBpcyAyNTgwMTAw
MCENClsgIDE1OC43NjkxMjNdIDMyMGI1IGlzIDI1ODAyMDAwIQ0KWyAgMTU4Ljc3MDgwN10g
MzIwOTYgaXMgMjU4MGUwMDAhDQpbICAxNTguNzcyNDc5XSAzMjA5NyBpcyAyNTgwZjAwMCEN
ClsgIDE1OC43NzQxNTFdIDMyMDk4IGlzIDI1ODEwMDAwIQ0KWyAgMTU4Ljc3NTg0MF0gMzIw
OTkgaXMgMjU4MTEwMDAhDQpbICAxNTguNzc3NTI5XSAzMjA5YSBpcyAyNTgxMjAwMCENClsg
IDE1OC43NzkyMjRdIDMyMDliIGlzIDI1ODEzMDAwIQ0KWyAgMTU4Ljc4MDkwOF0gMzIwOWMg
aXMgMjU4MTQwMDAhDQpbICAxNTguNzgyNTg2XSAzMjA5ZCBpcyAyNTgxNTAwMCENClsgIDE1
OC43ODQyODddIDMyMDllIGlzIDI1ODE2MDAwIQ0KWyAgMTU4Ljc4NTk1M10gMzIwOWYgaXMg
MjU4MTcwMDAhDQpbICAxNTguNzg3NjQzXSAzMjBhMCBpcyAyNTgxODAwMCENClsgIDE1OC43
ODkyOThdIDMyMDhjIGlzIDI1ODE5MDAwIQ0KWyAgMTU4Ljc5MDk3MV0gMzIwOGQgaXMgMjU4
MWEwMDAhDQpbICAxNTguNzkyNjU0XSAzMjA4ZSBpcyAyNTgxYjAwMCENClsgIDE1OC43OTQz
MjZdIDMyMDhmIGlzIDI1ODFjMDAwIQ0KWyAgMTU4Ljc5NjAwNF0gMzIwOTAgaXMgMjU4MWQw
MDAhDQpbICAxNTguNzk3Njg0XSAzMjA5MSBpcyAyNTgxZTAwMCENClsgIDE1OC43OTkzNDVd
IDMyMDkyIGlzIDI1ODFmMDAwIQ0KWyAgMTU4LjgwMTAzNF0gMzIwOTMgaXMgMjU4MjAwMDAh
DQpbICAxNTguODAyNzE4XSAzMjA5NCBpcyAyNTgyMTAwMCENClsgIDE1OC44MDQ0MjRdIDMy
MDk1IGlzIDI1ODIyMDAwIQ0KWyAgMTU4LjgyNTA3Nl0gMzIwYjYgaXMgMjU3ZWUwMDAhDQpb
ICAxNTguODI2ODA5XSAzMjBiNyBpcyAyNTdlZjAwMCENClsgIDE1OC44Mjg1MjldIDMyMGI4
IGlzIDI1N2YwMDAwIQ0KWyAgMTU4LjgzMDI3Nl0gMzIwYjkgaXMgMjU3ZjEwMDAhDQpbICAx
NTguODMxOTg2XSAzMjBiYSBpcyAyNTdmMjAwMCENClsgIDE1OC44MzM3MTRdIDMyMGJiIGlz
IDI1N2YzMDAwIQ0KWyAgMTU4LjgzNTQ2MF0gMzIwYmMgaXMgMjU3ZjQwMDAhDQpbICAxNTgu
ODM3MTk0XSAzMjBiZCBpcyAyNTdmNTAwMCENClsgIDE1OC44Mzg4NzddIDMyMGJlIGlzIDI1
N2Y2MDAwIQ0KWyAgMTU4Ljg0MDU4NF0gMzIwYmYgaXMgMjU3ZjcwMDAhDQpbICAxNTguODQy
MjkzXSAzMjBjMCBpcyAyNTdmODAwMCENClsgIDE1OC44NDQyODRdIDMyMGMyIGlzIDI1N2U0
MDAwIQ0KWyAgMTU4Ljg0NTk5Ml0gMzIwYzMgaXMgMjU3ZTUwMDAhDQpbICAxNTguODQ3Njk1
XSAzMjBjNCBpcyAyNTdlNjAwMCENClsgIDE1OC44NDkzOTVdIDMyMGM1IGlzIDI1N2U3MDAw
IQ0KWyAgMTU4Ljg1MTA3N10gMzIwYzYgaXMgMjU3ZTgwMDAhDQpbICAxNTguODUyNzUzXSAz
MjBjNyBpcyAyNTdlOTAwMCENClsgIDE1OC44NTQ0NTVdIDMyMGM4IGlzIFsgIDE2MC45ODMy
OTRdIDMxY2JlIGlzIDI1ZmM4MDAwIQ0KWyAgMTYwLjk4NTA0OF0gMzFjYmYgaXMgMjVmYzkw
MDAhDQpbICAxNjAuOTg2NzcwXSAzMWM3ZiBpcyAyNWZkNTAwMCENClsgIDE2MC45ODg0Nzdd
IDMxYzgwIGlzIDI1ZmQ2MDAwIQ0KWyAgMTYwLjk5MDE4M10gMzFjODEgaXMgMjVmZDcwMDAh
DQpbICAxNjAuOTkxODk0XSAzMWM4MiBpcyAyNWZkODAwMCENClsgIDE2MC45OTM2MDNdIDMx
Y2E0IGlzIDI1ZmQ5MDAwIQ0KWyAgMTYwLjk5NTMwNV0gMzFjYTUgaXMgMjVmZGEwMDAhDQpb
ICAxNjAuOTk3MDI1XSAzMWNhNiBpcyAyNWZkYjAwMCENClsgIDE2MC45OTg3MDldIDMxY2E3
IGlzIDI1ZmRjMDAwIQ0KWyAgMTYxLjAwMDQwNV0gMzFjYTggaXMgMjVmZGQwMDAhDQpbICAx
NjEuMDAyMDg5XSAzMWNhOSBpcyAyNWZkZTAwMCENClsgIDE2MS4wMDM3OTRdIDMxY2FhIGlz
IDI1ZmRmMDAwIQ0KWyAgMTYxLjAwNTQ3N10gMzFjODkgaXMgMjYwMGEwMDAhDQpbICAxNjEu
MDA3MTc1XSAzMWM4OCBpcyAyNWZlNzAwMCENClsgIDE2MS4wMDg4ODhdIDMxYzg3IGlzIDI1
M2I0MDAwIQ0KWyAgMTYxLjAxMDYxMF0gMzFjODYgaXMgMjYwMDQwMDAhDQpbICAxNjEuMDEy
MzQwXSAzMWM4MyBpcyAyNTI2OTAwMCENClsgIDE2MS4wMTQxMDVdIDMyM2M2IGlzIDI2MTgx
MDAwIQ0KWyAgMTYxLjAxNTg2NF0gMzIzYzUgaXMgMjYwMGIwMDAhDQpbICAxNjEuMDE3Njcx
XSAzMjNjNCBpcyAyNjAwZDAwMCENClsgIDE2MS4wMTk0NDhdIDMyM2MzIGlzIDI2MDBjMDAw
IQ0KWyAgMTYxLjAyMTI1NF0gMzIzYzIgaXMgMjU1OGQwMDAhDQpbICAxNjEuMDIzMDUzXSAz
MjNjMSBpcyAyNjAyMDAwMCENClsgIDE2MS4wMjkyNDhdIDMxY2MxIGlzIDI1ZmI1MDAwIQ0K
WyAgMTYxLjAzMTI2MV0gMzFjYzIgaXMgMjVmYjYwMDAhDQpbICAxNjEuMDMzMTQ0XSAzMWNj
MyBpcyAyNWZiNzAwMCENClsgIDE2MS4wMzUwNDFdIDMxY2M0IGlzIDI1ZmI4MDAwIQ0KWyAg
MTYxLjAzNjg3NV0gMzFjYzUgaXMgMjVmYjkwMDAhDQpbICAxNjEuMDM4NzA3XSAzMWNjNiBp
cyAyNWZiYTAwMCENClsgIDE2MS4wNDA1NDNdIDMxY2M3IGlzIDI1ZmJiMDAwIQ0KWyAgMTYx
LjA0MjM3Nl0gMzFjYzggaXMgMjVmYmMwMDAhDQpbICAxNjEuMDQ0MjA3XSAzMWNjOSBpcyAy
NWZiZDAwMCENClsgIDE2MS4wNDYwMzhdIDMxY2NhIGlzIDI1ZmJlMDAwIQ0KWyAgMTYxLjA0
Nzg2M10gMzFjY2IgaXMgMjVmYmYwMDAhDQpbICAxNjEuMDUwMjM5XSAzMWNlMSBpcyAyNWY5
NTAwMCENClsgIDE2MS4wNTIwODVdIDMxY2UyIGlzIDI1Zjk2MDAwIQ0KWyAgMTYxLjA1Mzkz
NV0gMzFjZTMgaXMgMjVmOTcwMDAhDQpbICAxNjEuMDU1Nzg1XSAzMWNlNCBpcyAyNWY5ODAw
MCENClsgIDE2MS4wNTc2MjddIDMxY2U1IGlzIDI1Zjk5MDAwIQ0KWyAgMTYxLjA1OTQ5MF0g
MzFjZTYgaXMgMjVmOWEwMDAhDQpbICAxNjEuMDYxMzI4XSAzMWNlNyBpcyAyNWY5YjAwMCEN
ClsgIDE2MS4wNjMxNzldIDMxY2U4IGlzIDI1ZjljMDAwIQ0KWyAgMTYxLjA2NTAxM10gMzFj
ZTkgaXMgMjVmOWQwMDAhDQpbICAxNjEuMDY2ODgwXSAzMWNlYSBpcyAyNWY5ZTAwMCENClsg
IDE2MS4wNjg2ODNdIDMxY2ViIGlzIDI1ZjlmMDAwIQ0KWyAgMTYxLjA3MDQ4M10gMzFjZWMg
aXMgMjVmOGEwMDAhDQpbICAxNjEuMDcyMjY4XSAzMWNlZCBpcyAyNWY4YjAwMCENClsgIDE2
MS4wNzQwMjRdIDMxY2VlIGlzIDI1ZjhjMDAwIQ0KWyAgMTYxLjA3NTc3OV0gMzFjZWYgaXMg
MjVmOGQwMDAhDQpbICAxNjEuMDc3NDg5XSAzMWNmMCBpcyAyNWY4ZTAwMCENClsgIDE2MS4w
NzkxOThdIDMxY2YxIGlzIDI1ZjhmMDAwIQ0KWyAgMTYxLjA4MDg5OF0gMzFjZjIgaXMgMjVm
OTAwMDAhDQpbICAxNjEuMDgyNTg0XSAzMWNmMyBpcyAyNWY5MTAwMCENClsgIDE2MS4wODQy
ODRdIDMxY2Y0IGlzIDI1ZjkyMDAwIQ0KWyAgMTYxLjA4NTkyMl0gMzFjZjUgaXMgMjVmOTMw
MDAhDQpbICAxNjEuMDg3NTc2XSAzMWNmNiBpcyAyNWY5NDAwMCENClsgIDE2MS4wODkxOTJd
IDMxY2Y3IGlzIDI1ZjgwMDAwIQ0KWyAgMTYxLjA5MDgyN10gMzFjZjggaXMgMjVmODEwMDAh
DQpbICAxNjEuMDkyNDg1XSAzMWNmOSBpcyAyNWY4MjAwMCENClsgIDE2MS4wOTQxMzNdIDMx
Y2ZhIGlzIDI1ZjgzMDAwIQ0KWyAgMTYxLjA5NTc5N10gMzFjZmIgaXMgMjVmODQwMDAhDQpb
ICAxNjEuMDk3NDM4XSAzMWNmYyBpcyAyNWY4NTAwMCENClsgIDE2MS4wOTkwNjRdIDMxY2Zk
IGlzIDI1Zjg2MDAwIQ0KWyAgMTYxLjEwMDczMF0gMzFjZmUgaXMgMjVmODcwMDAhDQpbICAx
NjEuMTAyMzY4XSAzMWNmZiBpcyAyNWY4ODAwMCENClsgIDE2MS4xMDQwMjBdIDMxZDAwIGlz
IDI1Zjg5MDAwIQ0KWyAgMTYxLjEwNTY3N10gMzFjY2MgaXMgMjVmYWEwMDAhDQpbICAxNjEu
MTA3MzQxXSAzMWNjZCBpcyAyNWZhYjAwMCENClsgIDE2MS4xMDkwMjJdIDMxY2NlIGlzIDI1
ZmFjMDAwIQ0KWyAgMTYxLjExMDY5OF0gMzFjY2YgaXMgMjVmYWQwMDAhDQpbICAxNjEuMTEy
MzY1XSAzMWNkMCBpcyAyNWZhZTAwMCENClsgIDE2MS4xMTQwNzddIDMxY2QxIGlzIDI1ZmFm
MDAwIQ0KWyAgMTYxLjExNTc0NF0gMzFjZDIgaXMgMjVmYjAwMDAhDQpbICAxNjEuMTE3NDU2
XSAzMWNkMyBpcyAyNWZiMTAwMCENClsgIDE2MS4xMTkxMjhdIDMxY2Q0IGlzIDI1ZmIyMDAw
IQ0KWyAgMTYxLjEyMDgzOV0gMzFjZDUgaXMgMjVmYjMwMDAhDQpbICAxNjEuMTIyNTI0XSAz
MWNkNiBpcyAyNWZiNDAwMCENClsgIDE2MS4xMjQyMjNdIDMxY2Q3IGlzIDI1ZmEwMDAwIQ0K
WyAgMTYxLjEyNTkzMl0gMzFjZDggaXMgMjVmYTEwMDAhDQpbICAxNjEuMTI3NjMwXSAzMWNk
OSBpcyAyNWZhMjAwMCENClsgIDE2MS4xMjkzMzRdIDMxY2RhIGlzIDI1ZmEzMDAwIQ0KWyAg
MTYxLjEzMTAyMF0gMzFjZGIgaXMgMjVmYTQwMDAhDQpbICAxNjEuMTMyNzAwXSAzMWNkYyBp
cyAyNWZhNTAwMCENClsgIDE2MS4xMzQ0MTJdIDMxY2RkIGlzIDI1ZmE2MDAwIQ0KWyAgMTYx
LjEzNjA4NF0gMzFjZGUgaXMgMjVmYTcwMDAhDQpbICAxNjEuMTM3ODA3XSAzMWNkZiBpcyAy
NWZhODAwMCENClsgIDE2MS4xMzk0OTFdIDMxY2UwIGlzIDI1ZmE5MDAwIQ0KWyAgMTYxLjE0
MjgxM10gMzFjOTMgaXMgMjVmNmEwMDAhDQpbICAxNjEuMTQ0ODAwXSAzMWM5NCBpcyAyNWY2
YjAwMCENClsgIDE2MS4xNDY1MjBdIDMxYzk1IGlzIDI1ZjZjMDAwIQ0KWyAgMTYxLjE0ODIz
MF0gMzFjOTYgaXMgMjVmNmQwMDAhDQpbICAxNjEuMTQ5OTM3XSAzMWM5NyBpcyAyNWY2ZTAw
MCENClsgIDE2MS4xNTE2NDVdIDMxYzk4IGlzIDI1ZjZmMDAwIQ0KWyAgMTYxLjE1MzM0NV0g
MzFjOTkgaXMgMjVmNzAwMDAhDQpbICAxNjEuMTU1MDY1XSAzMWM5YSBpcyAyNWY3MTAwMCEN
ClsgIDE2MS4xNTY3NjFdIDMxYzliIGlzIDI1ZjcyMDAwIQ0KWyAgMTYxLjE1ODQ0NV0gMzFj
OWMgaXMgMjVmNzMwMDAhDQpbICAxNjEuMTYwMTA2XSAzMWM5ZCBpcyAyNWY3NDAwMCENClsg
IDE2MS4xNjE3NDRdIDMxYzllIGlzIDI1ZjYwMDAwIQ0KWyAgMTYxLjE2MzQyNF0gMzFjOWYg
aXMgMjVmNjEwMDAhDQpbICAxNjEuMTY1MDYyXSAzMWNhMCBpcyAyNWY2MjAwMCENClsgIDE2
MS4xNjY3NDJdIDMxY2ExIGlzIDI1ZjYzMDAwIQ0KWyAgMTYxLjE2ODM2OF0gMzFjYTIgaXMg
MjVmNjQwMDAhDQpbICAxNjEuMTcwMDAxXSAzMWNhMyBpcyAyNWY2NTAwMCENClsgIDE2MS4x
NzE2NDddIDMxZDIyIGlzIDI1ZjY2MDAwIQ0KWyAgMTYxLjE3MzI3M10gMzFkMjMgaXMgMjVm
NjcwMDAhDQpbICAxNjEuMTc0OTI4XSAzMWQyNCBpcyAyNWY2ODAwMCENClsgIDE2MS4xNzY1
NDhdIDMxZDI1IGlzIDI1ZjY5MDAwIQ0KWyAgMTYxLjE3OTU0N10gMzFkMzAgaXMgMjVmMmEw
MDAhDQpbICAxNjEuMTgxMzg2XSAzMWQyZiBpcyAyNWYyYjAwMCENClsgIDE2MS4xODMwMTNd
IDMxZDJlIGlzIDI1ZjJjMDAwIQ0KWyAgMTYxLjE4NDY3OV0gMzFkMmQgaXMgMjVmMmQwMDAh
DQpbICAxNjEuMTg2MzE3XSAzMWQyYyBpcyAyNWYyZTAwMCENClsgIDE2MS4xODc5ODNdIDMx
ZDJiIGlzIDI1ZjJmMDAwIQ0KWyAgMTYxLjE4OTYyMl0gMzFkMmEgaXMgMjVmMzAwMDAhDQpb
ICAxNjEuMTkxMjgxXSAzMWQyOSBpcyAyNWYzMTAwMCENClsgIDE2MS4xOTI5NDZdIDMxZDI4
IGlzIDI1ZjMyMDAwIQ0KWyAgMTYxLjE5NDYxMF0gMzFkMjcgaXMgMjVmMzMwMDAhDQpbICAx
NjEuMTk2MjY5XSAzMWQyNiBpcyAyNWYzNDAwMCENClsgIDE2MS4xOTgxOTZdIDMxYzkyIGlz
IDI1ZjE1MDAwIQ0KWyAgMTYxLjE5OTg3Ml0gMzFjOTEgaXMgMjVmMTYwMDAhDQpbICAxNjEu
MjAxNTQ0XSAzMWM5MCBpcyAyNWYxNzAwMCENClsgIDE2MS4yMDMyMTddIDMxYzhmIGlzIDI1
ZjE4MDAwIQ0KWyAgMTYxLjIwNDkzM10gMzFjOGUgaXMgMjVmMTkwMDAhDQpbICAxNjEuMjA2
NjExXSAzMWM4ZCBpcyAyNWYxYTAwMCENClsgIDE2MS4yMDgzMjRdIDMxYzhjIGlzIDI1ZjFi
MDAwIQ0KWyAgMTYxLjIxMDAxNl0gMzFjOGIgaXMgMjVmMWMwMDAhDQpbICAxNjEuMjExNzMy
XSAzMWM4YSBpcyAyNWYxZDAwMCENClsgIDE2MS4yMTM0NjVdIDMxZDAxIGlzIDI1ZjFlMDAw
IQ0KWyAgMTYxLjIxNTE3Ml0gMzFkMDQgaXMgMjVmMWYwMDAhDQpbICAxNjEuMjE2OTAzXSAz
MWQzYiBpcyAyNWYwYTAwMCENClsgIDE2MS4yMTg2MjJdIDMxZDNjIGlzIDI1ZjBiMDAwIQ0K
WyAgMTYxLjIyMDM1MF0gMzFkM2QgaXMgMjVmMGMwMDAhDQpbICAxNjEuMjIyMDkxXSAzMWQz
ZSBpcyAyNWYwZDAwMCENClsgIDE2MS4yMjM4MzBdIDMxZDNmIGlzIDI1ZjBlMDAwIQ0KWyAg
MTYxLjIyNTU2NF0gMzFkNDAgaXMgMjVmMGYwMDAhDQpbICAxNjEuMjI3MjkyXSAzMWQ0MSBp
cyAyNWYxMDAwMCENClsgIDE2MS4yMjkwMjZdIDMxZDQyIGlzIDI1ZjExMDAwIQ0KWyAgMTYx
LjIzMDc2MF0gMzFkNDMgaXMgMjVmMTIwMDAhDQpbICAxNjEuMjMyNDkwXSAzMWQ0NCBpcyAy
NWYxMzAwMCENClsgIDE2MS4yMzQyNDNdIDMxZDQ1IGlzIDI1ZjE0MDAwIQ0KWyAgMTYxLjIz
NTk1NV0gMzFkM2EgaXMgMjVmMjAwMDAhDQpbICAxNjEuMjM3NzA5XSAzMWQzOSBpcyAyNWYy
MTAwMCENClsgIDE2MS4yMzk0MzVdIDMxZDM4IGlzIDI1ZjIyMDAwIQ0KWyAgMTYxLjI0MTE3
NF0gMzFkMzcgaXMgMjVmMjMwMDAhDQpbICAxNjEuMjQyOTIwXSAzMWQzNiBpcyAyNWYyNDAw
MCENClsgIDE2MS4yNDQ2NThdIDMxZDM1IGlzIDI1ZjI1MDAwIQ0KWyAgMTYxLjI0NjM5Ml0g
MzFkMzQgaXMgMjVmMjYwMDAhDQpbICAxNjEuMjQ4MTI1XSAzMWQzMyBpcyAyNWYyNzAwMCEN
ClsgIDE2MS4yNDk4NTldIDMxZDMyIGlzIDI1ZjI4MDAwIQ0KWyAgMTYxLjI1MTU5M10gMzFk
MzEgaXMgMjVmMjkwMDAhDQpbICAxNjEuMjUzMzAwXSAzMWQ0NiBpcyAyNWYwMDAwMCENClsg
IDE2MS4yNTUwNDldIDMxZDQ3IGlzIDI1ZjAxMDAwIQ0KWyAgMTYxLjI1Njc3Ml0gMzFkNDgg
aXMgMjVmMDIwMDAhDQpbICAxNjEuMjU4NDg5XSAzMWQ0OSBpcyAyNWYwMzAwMCENClsgIDE2
MS4yNjAyMDVdIDMxZDRhIGlzIDI1ZjA0MDAwIQ0KWyAgMTYxLjI2MTkxMl0gMzFkNGIgaXMg
MjVmMDUwMDAhDQpbICAxNjEuMjYzNjQ5XSAzMWQ0YyBpcyAyNWYwNjAwMCENClsgIDE2MS4y
NjUzNTFdIDMxZDRkIGlzIDI1ZjA3MDAwIQ0KWyAgMTYxLjI2NzA4Ml0gMzFkNGUgaXMgMjVm
MDgwMDAhDQpbICAxNjEuMjY4NzczXSAzMWQ0ZiBpcyAyNWYwOTAwMCENClsgIDE2MS4yNzE2
OTddIDMxZDUxIGlzIDI1ZWY1MDAwIQ0KWyAgMTYxLjI3MzQyMl0gMzFkNTIgaXMgMjVlZjYw
MDAhDQpbICAxNjEuMjc1MTQwXSAzMWQ1MyBpcyAyNWVmNzAwMCENClsgIDE2MS4yNzY5ODNd
IDMxZDU0IGlzIDI1ZWY4MDAwIQ0KWyAgMTYxLjI3ODY3OV0gMzFkNTUgaXMgMjVlZjkwMDAh
DQpbICAxNjEuMjgwNDM4XSAzMWQ1NiBpcyAyNWVmYTAwMCENClsgIDE2MS4yODIxMzVdIDMx
ZDU3IGlzIDI1ZWZiMDAwIQ0KWyAgMTYxLjI4Mzg1MF0gMzFkNTggaXMgMjVlZmMwMDAhDQpb
ICAxNjEuMjg1NTM0XSAzMWQ1OSBpcyAyNWVmZDAwMCENClsgIDE2MS4yODcyNThdIDMxZDVh
IGlzIDI1ZWZlMDAwIQ0KWyAgMTYxLjI4ODk0NF0gMzFkNWIgaXMgMjVlZmYwMDAhDQpbICAx
NjEuMjkwNjQ0XSAzMWQ1YyBpcyAyNWVlYTAwMCENClsgIDE2MS4yOTIzMzNdIDMxZDVkIGlz
IDI1ZWViMDAwIQ0KWyAgMTYxLjI5NDAyMF0gMzFkNWUgaXMgMjVlZWMwMDAhDQpbICAxNjEu
Mjk1NzA3XSAzMWQ1ZiBpcyAyNWVlZDAwMCENClsgIDE2MS4yOTczODddIDMxZDYwIGlzIDI1
ZWVlMDAwIQ0KWyAgMTYxLjI5OTA3NF0gMzFkNjEgaXMgMjVlZWYwMDAhDQpbICAxNjEuMzAw
Nzk3XSAzMWQ2MiBpcyAyNWVmMDAwMCENClsgIDE2MS4zMDI0ODFdIDMxZDYzIGlzIDI1ZWYx
MDAwIQ0KWyAgMTYxLjMwNDE5N10gMzFkNjQgaXMgMjVlZjIwMDAhDQpbICAxNjEuMzA1ODgx
XSAzMWQ2NSBpcyAyNWVmMzAwMCENClsgIDE2MS4zMDc1NzRdIDMxZDY2IGlzIDI1ZWY0MDAw
IQ0KWyAgMTYxLjMxMDQxMF0gMzFkNjggaXMgMjVlZTEwMDAhDQpbICAxNjEuMzEyMTQxXSAz
MWQ2OSBpcyAyNWVlMjAwMCENClsgIDE2MS4zMTM4NDldIDMxZDZhIGlzIDI1ZWUzMDAwIQ0K
WyAgMTYxLjMxNTUzM10gMzFkNmIgaXMgMjVlZTQwMDAhDQpbICAxNjEuMzE3MjY5XSAzMWQ2
YyBpcyAyNWVlNTAwMCENClsgIDE2MS4zMTg5NTZdIDMxZDZkIGlzIDI1ZWU2MDAwIQ0KWyAg
MTYxLjMyMDY3OV0gMzFkNmUgaXMgMjVlZTcwMDAhDQpbICAxNjEuMzIyMzY0XSAzMWQ2ZiBp
cyAyNWVlODAwMCENClsgIDE2MS4zMjQwNjFdIDMxZDcwIGlzIDI1ZWU5MDAwIQ0KWyAgMTYx
LjM0MTk4OV0gMzFkN2MgaXMgMjVlYjUwMDAhDQpbICAxNjEuMzQzNzUwXSAzMWQ5MCBpcyAy
NWViNjAwMCENClsgIDE2MS4zNDU0NDRdIDMxZDhmIGlzIDI1ZWI3MDAwIQ0KWyAgMTYxLjM0
NzE2MV0gMzFkOGUgaXMgMjVlYjgwMDAhDQpbICAxNjEuMzQ4ODkwXSAzMWQ4ZCBpcyAyNWVi
OTAwMCENClsgIDE2MS4zNTA2MzFdIDMxZDhjIGlzIDI1ZWJhMDAwIQ0KWyAgMTYxLjM1MjMw
OV0gMzFkOGIgaXMgMjVlYmIwMDAhDQpbICAxNjEuMzU0MDI1XSAzMWQ4YSBpcyAyNWViYzAw
MCENClsgIDE2MS4zNTU3MDddIDMxZDg5IGlzIDI1ZWJkMDAwIQ0KWyAgMTYxLjM1NzU4N10g
MzFkODggaXMgMjVlYmUwMDAhDQpbICAxNjEuMzU5MjgxXSAzMWQ4NyBpcyAyNWViZjAwMCEN
ClsgIDE2MS4zNjEwOTVdIDMxZDcxIGlzIDI1ZWFhMDAwIQ0KWyAgMTYxLjM2Mjg1N10gMzFk
ODYgaXMgMjVlYWIwMDAhDQpbICAxNjEuMzY0NTgzXSAzMWQ4NSBpcyAyNWVhYzAwMCENClsg
IDE2MS4zNjYyOTFdIDMxZDg0IGlzIDI1ZWFkMDAwIQ0KWyAgMTYxLjM2ODAwM10gMzFkODMg
aXMgMjVlYWUwMDAhDQpbICAxNjEuMzY5NzAyXSAzMWQ4MiBpcyAyNWVhZjAwMCENClsgIDE2
MS4zNzE0NDhdIDMxZDgxIGlzIDI1ZWIwMDAwIQ0KWyAgMTYxLjM3MzEyOV0gMzFkODAgaXMg
MjVlYjEwMDAhDQpbICAxNjEuMzc0ODM4XSAzMWQ3ZiBpcyAyNWViMjAwMCENClsgIDE2MS4z
NzY1MjJdIDMxZDdlIGlzIDI1ZWIzMDAwIQ0KWyAgMTYxLjM3ODIyNF0gMzFkN2QgaXMgMjVl
YjQwMDAhDQpbICAxNjEuMzgwMTM5XSAzMWQ2NyBpcyAyNWU5ZjAwMCENClsgIDE2MS4zODE4
NTBdIDMxZDdiIGlzIDI1ZWEwMDAwIQ0KWyAgMTYxLjM4MzU5OV0gMzFkN2EgaXMgMjVlYTEw
MDAhDQpbICAxNjEuMzg1MzE0XSAzMWQ3OSBpcyAyNWVhMjAwMCENClsgIDE2MS4zODcwNjNd
IDMxZDc4IGlzIDI1ZWEzMDAwIQ0KWyAgMTYxLjM4ODc4N10gMzFkNzcgaXMgMjVlYTQwMDAh
DQpbICAxNjEuMzkwNTA5XSAzMWQ3NiBpcyAyNWVhNTAwMCENClsgIDE2MS4zOTIyNDldIDMx
ZDc1IGlzIDI1ZWE2MDAwIQ0KWyAgMTYxLjM5Mzk2OF0gMzFkNzQgaXMgMjVlYTcwMDAhDQpb
ICAxNjEuMzk1NzAzXSAzMWQ3MyBpcyAyNWVhODAwMCENClsgIDE2MS4zOTc0MDhdIDMxZDcy
IGlzIDI1ZWE5MDAwIQ0KWyAgMTYxLjQxMTA0MV0gMzFkNTAgaXMgMjVlOWUwMDAhDQpbICAx
NjEuNDIwNDUwXSAzMWQ5MSBpcyAyNWU5ZDAwMCENClsgIDE2MS40Mjc1MTBdIDMxZDA1IGlz
IDI1ZTljMDAwIQ0KWyAgMTYxLjQzMDAzN10gMzFkMDYgaXMgMjVlOWIwMDAhDQpbICAxNjEu
NDMyMzU0XSAzMWQwNyBpcyAyNWU5YTAwMCENClsgIDE2MS40MzQ1MjVdIDMxZDA4IGlzIDI1
ZTk5MDAwIQ0KWyAgMTYxLjQzNjY3MF0gMzFkMDkgaXMgMjVlOTgwMDAhDQpbICAxNjEuNDM5
MDU0XSAzMWQwYSBpcyAyNWU5NzAwMCENClsgIDE2MS40NDEyMDddIDMxZDBiIGlzIDI1ZTk2
MDAwIQ0KWyAgMTYxLjQ0MzM2MV0gMzFkMGMgaXMgMjVlOTUwMDAhDQpbICAxNjEuNDQ1NzM3
XSAzMWQwZCBpcyAyNWU5NDAwMCENClsgIDE2MS40NDc4NzRdIDMxZDBlIGlzIDI1ZTkzMDAw
IQ0KWyAgMTYxLjQ1MDAyM10gMzFkMGYgaXMgMjVlOTIwMDAhDQpbICAxNjEuNDU2OTI0XSAz
MWQxMCBpcyAyNWU5MTAwMCENClsgIDE2MS40NTkwNzNdIDMxZDExIGlzIDI1ZTkwMDAwIQ0K
WyAgMTYxLjQ3MjE2NV0gMzFkMTIgaXMgMjVlOGYwMDAhDQpbICAxNjEuNDc0NDYzXSAzMWQ5
MiBpcyAyNWU4ZTAwMCENClsgIDE2MS40NzY1OTldIDMxZDEzIGlzIDI1ZThkMDAwIQ0KWyAg
MTYxLjQ3ODk4N10gMzFkMTQgaXMgMjVlOGMwMDAhDQpbICAxNjEuNDk0MTIzXSAzMWQxNSBp
cyAyNWU4YjAwMCENClsgIDE2MS41MDM3NjBdIDMxZDE2IGlzIDI1ZThhMDAwIQ0KWyAgMTYx
LjUwOTkwM10gMzFkMTcgaXMgMjVlODkwMDAhDQpbICAxNjEuNTIxNDAwXSAzMWQxOCBpcyAy
NWU4ODAwMCENClsgIDE2MS41MzAyODhdIDMxZDE5IGlzIDI1ZTg3MDAwIQ0KWyAgMTYxLjU0
MTAzMF0gMzFkMWEgaXMgMjVlODYwMDAhDQpbICAxNjEuNTQ1NDAzXSAzMWQxYyBpcyAyNWU4
NTAwMCENClsgIDE2MS41NTQ4MzVdIDMxZDFkIGlzIDI1ZTg0MDAwIQ0KWyAgMTYxLjU3NTg4
Ml0gMzFkMWUgaXMgMjVlODMwMDAhDQpbICAxNjEuNTg4MDM0XSAzMWQxZiBpcyAyNWU4MjAw
MCENClsgIDE2MS42MDM4NzFdIDMxZDIwIGlzIDI1ZTgxMDAwIQ0KWyAgMTYxLjYzNDk1Nl0g
MzFkMjEgaXMgMjVlODAwMDAhDQpbICAxNjEuNjczODgxXSAzMWQ5MyBpcyAyNWU3ZjAwMCEN
ClsgIDE2MS42ODQxNTJdIDMxZDk0IGlzIDI1ZTdlMDAwIQ0KWyAgMTYxLjY4NjMyOV0gMzFk
OWUgaXMgMjVlN2QwMDAhDQpbICAxNjEuNzA4MzYyXSAzMWQ5ZiBpcyAyNWU3YzAwMCENClsg
IDE2MS43MTUzNjNdIDMxZDk1IGlzIDI1ZTdiMDAwIQ0KWyAgMTYxLjcxNzY2Ml0gMzFkYTAg
aXMgMjVlN2EwMDAhDQpbICAxNjEuNzI2NDE3XSAzMWRhMSBpcyAyNWU3OTAwMCENClsgIDE2
MS43Mjg3MjhdIDMxZGEyIGlzIDI1ZTc4MDAwIQ0KWyAgMTYxLjc2NTI4MV0gMzFkYTMgaXMg
MjVlNzcwMDAhDQpbICAxNjEuNzY3NTg0XSAzMWQ5NiBpcyAyNWU3NjAwMCENClsgIDE2MS43
NzExNzZdIDMxZGE0IGlzIDI1ZTc1MDAwIQ0KWyAgMTYxLjc4NjYxOF0gMzFkYTUgaXMgMjVl
NzQwMDAhDQpbICAxNjEuODA1NjE2XSAzMWQ5NyBpcyAyNWU3MzAwMCENClsgIDE2MS44MjI2
ODhdIDMxZGE2IGlzIDI1ZTcyMDAwIQ0KWyAgMTYxLjgyNTAxOV0gMzFkOTggaXMgMjVlNzEw
MDAhDQpbICAxNjEuODI3MzE4XSAzMWRhNyBpcyAyNWU3MDAwMCENClsgIDE2MS44Mjk1MjFd
IDMxZGE4IGlzIDI1ZTZmMDAwIQ0KWyAgMTYxLjgzMTg4Nl0gMzFkYTkgaXMgMjVlNmUwMDAh
DQpbICAxNjEuODM0MjA5XSAzMWRhYSBpcyAyNWU2ZDAwMCENClsgIDE2MS44NDI1MTddIDMx
ZGFiIGlzIDI1ZTZjMDAwIQ0KWyAgMTYxLjg0NDkwOF0gMzFkYWMgaXMgMjVlNmIwMDAhDQpb
ICAxNjEuODUzMDMxXSAzMWRhZCBpcyAyNWU2YTAwMCENClsgIDE2MS44NTUzMjhdIDMxZGFl
IGlzIDI1ZTY5MDAwIQ0KWyAgMTYxLjg1NzY0OV0gMzFkYWYgaXMgMjVlNjgwMDAhDQpbICAx
NjEuODY3ODAxXSAzMWRiMCBpcyAyNWU2NzAwMCENClsgIDE2MS44ODI5ODVdIDMxZGIxIGlz
IDI1ZTM2MDAwIQ0KWyAgMTYxLjg5ODExOF0gMzFkOTkgaXMgMjVlMzcwMDAhDQpbICAxNjEu
OTE3NzMzXSAzMWQ5YSBpcyAyNWUzODAwMCENClsgIDE2MS45MTk5NjNdIDMxZGIyIGlzIDI1
ZTM5MDAwIQ0KWyAgMTYxLjkyNjgwNl0gMzFkYjMgaXMgMjVlM2EwMDAhDQpbICAxNjEuOTM5
NjIwXSAzMWRiNCBpcyAyNWUzYjAwMCENClsgIDE2MS45NDE5NjNdIDMxZGI1IGlzIDI1ZTNj
MDAwIQ0KWyAgMTYxLjk0NDI2Ml0gMzFkYjYgaXMgMjVlM2QwMDAhDQpbICAxNjEuOTQ5NDM4
XSAzMWRiNyBpcyAyNWUzZTAwMCENClsgIDE2MS45NTE3MjFdIDMxZGI4IGlzIDI1ZTNmMDAw
IQ0KWyAgMTYxLjk2MzY4OV0gMzFkYjkgaXMgMjVlNDAwMDAhDQpbICAxNjEuOTcyODY2XSAz
MWRiYSBpcyAyNWU0MTAwMCENClsgIDE2MS45NzUyMTVdIDMxZGJiIGlzIDI1ZTQyMDAwIQ0K
WyAgMTYxLjk3NzUyMV0gMzFkYmMgaXMgMjVlNDMwMDAhDQpbICAxNjEuOTkyNzI4XSAzMWRi
ZCBpcyAyNWU0NDAwMCENClsgIDE2MS45OTUwNTBdIDMxZDliIGlzIDI1ZTQ1MDAwIQ0KWyAg
MTYxLjk5NzM1Nl0gMzFkYmUgaXMgMjVlNDYwMDAhDQpbICAxNjEuOTk5NTU1XSAzMWRiZiBp
cyAyNWU0ZDAwMCENClsgIDE2Mi4wMDE4OTZdIDMxZGMwIGlzIDI1ZTVmMDAwIQ0KWyAgMTYy
LjAwNDIxNl0gMzFkYzEgaXMgMjVlNjAwMDAhDQpbICAxNjIuMDA2NDAzXSAzMWRjMiBpcyAy
NWU1ZTAwMCENClsgIDE2Mi4wMDg3ODFdIDMxZGMzIGlzIDI1ZTVkMDAwIQ0KWyAgMTYyLjAx
MTA4OF0gMzFkYzQgaXMgMjVlNjMwMDAhDQpbICAxNjIuMDIyNTM4XSAzMWRjNSBpcyAyNWU2
NDAwMCENClsgIDE2Mi4wMjQ4NjNdIDMxZGM2IGlzIDI1ZTY1MDAwIQ0KWyAgMTYyLjAyNzA2
N10gMzFkYzcgaXMgMjVlNTQwMDAhDQpbICAxNjIuMDMzNDg3XSAzMWRjOCBpcyAyNWU1MTAw
MCENClsgIDE2Mi4wNjk0NDJdIDMxZGM5IGlzIDI1ZTUwMDAwIQ0KWyAgMTYyLjA3MTczNV0g
MzFkOWMgaXMgMjVlNTMwMDAhDQpbICAxNjIuMDg0NjU4XSAzMWRjYSBpcyAyNWU0NzAwMCEN
ClsgIDE2Mi4wODcwMzVdIDMxZGNiIGlzIDI1ZTQ4MDAwIQ0KWyAgMTYyLjExNjcwMF0gMzFk
Y2MgaXMgMjVlNGMwMDAhDQpbICAxNjIuMTE4OTk4XSAzMWQ5ZCBpcyAyNWU1MjAwMCENClsg
IDE2Mi4xMjEzMjldIDMxZGNkIGlzIDI1ZTYyMDAwIQ0KWyAgMTYyLjEyMzY0Nl0gMzFkY2Ug
aXMgMjVlNjEwMDAhDQpbICAxNjIuMTM0NzQ0XSAzMWRjZiBpcyAyNWU0ZTAwMCENClsgIDE2
Mi4xMzY5MTJdIDMxZGQwIGlzIDI1ZTRmMDAwIQ0KWyAgMTYyLjEzOTIxM10gMzFkZDEgaXMg
MjYwMGYwMDAhDQpbICAxNjIuMTQ4OTk5XSAzMWRkYyBpcyAyNTc5YTAwMCENClsgIDE2Mi4x
NTk1MDBdIDMxZGQyIGlzIDI1ZTM1MDAwIQ0KWyAgMTYyLjE2MTM1M10gMzFkZGQgaXMgMjYw
MTAwMDAhDQpbICAxNjIuMTYzMTczXSAzMWRkZSBpcyAyMzRjYTAwMCENClsgIDE2Mi4xNjUw
MzVdIDMxZGRmIGlzIDI1ZTRiMDAwIQ0KWyAgMTYyLjE2Njg4Nl0gMzFkZTAgaXMgMjUzZDAw
MDAhDQpbICAxNjIuMTY4NzM2XSAzMWRlMSBpcyAyNjAwZTAwMCENClsgIDE2Mi4xNzA2MzJd
IDMxZGUyIGlzIDI1MWYwMDAwIQ0KWyAgMTYyLjE3MjUwOV0gMzFkZTMgaXMgMjVlNTkwMDAh
DQpbICAxNjIuMTc1NDA0XSAzMWRmMCBpcyAyNWUyOTAwMCENClsgIDE2Mi4xNzczMjddIDMx
ZGYxIGlzIDI1ZTJhMDAwIQ0KWyAgMTYyLjE3OTIzNF0gMzFkZjIgaXMgMjVlMmIwMDAhDQpb
ICAxNjIuMTgxMTE5XSAzMWRmMyBpcyAyNWUyYzAwMCENClsgIDE2Mi4xODMwMDFdIDMxZGY0
IGlzIDI1ZTJkMDAwIQ0KWyAgMTYyLjE4NDg4MV0gMzFkZTUgaXMgMjVlMmUwMDAhDQpbICAx
NjIuMTg2Nzc3XSAzMWRlNiBpcyAyNWUyZjAwMCENClsgIDE2Mi4xODg2MzRdIDMxZGU3IGlz
IDI1ZTMwMDAwIQ0KWyAgMTYyLjE5MDUyOF0gMzFkZTggaXMgMjVlNTUwMDAhDQpbICAxNjIu
MTkyMzk2XSAzMWRlOSBpcyAyNWU1NjAwMCENClsgIDE2Mi4xOTQyOTNdIDMxZGVhIGlzIDI1
ZTU3MDAwIQ0KWyAgMTYyLjE5NjE1OF0gMzFkZWIgaXMgMjVlNTgwMDAhDQpbICAxNjIuMTk4
MDM2XSAzMWRlYyBpcyAyNWUzMTAwMCENClsgIDE2Mi4xOTk5MDldIDMxZGVkIGlzIDI1ZTMy
MDAwIQ0KWyAgMTYyLjIwMTc2M10gMzFkZWUgaXMgMjU0NWYwMDAhDQpbICAxNjIuMjAzNjU3
XSAzMWRlZiBpcyAyNTQ2MDAwMCENClsgIDE2Mi4yMDY5MjddIDMxZGZiIGlzIDI1ZTEzMDAw
IQ0KWyAgMTYyLjIwODgzNV0gMzFkZmMgaXMgMjVlMTQwMDAhDQpbICAxNjIuMjEwNzYxXSAz
MWRmZCBpcyAyNWUxNTAwMCENClsgIDE2Mi4yMTI2MzldIDMxZGZlIGlzIDI1ZTE2MDAwIQ0K
WyAgMTYyLjIxNDUzMF0gMzFkZmYgaXMgMjVlMTcwMDAhDQpbICAxNjIuMjE2NDE3XSAzMWUw
MCBpcyAyNWUxODAwMCENClsgIDE2Mi4yMTgyODddIDMxZTAxIGlzIDI1ZTE5MDAwIQ0KWyAg
MTYyLjIyMDE2MV0gMzFlMDIgaXMgMjVlMWEwMDAhDQpbICAxNjIuMjIxOTc5XSAzMWUwMyBp
cyAyNWUxYjAwMCENClsgIDE2Mi4yMjM4MThdIDMxZTA0IGlzIDI1ZTFjMDAwIQ0KWyAgMTYy
LjIyNTYwOV0gMzFlMDUgaXMgMjVlMWQwMDAhDQpbICAxNjIuMjI3ODQ2XSAzMWUwNiBpcyAy
NWUwOTAwMCENClsgIDE2Mi4yMjk2MTZdIDMxZTA3IGlzIDI1ZTBhMDAwIQ0KWyAgMTYyLjIz
MTM4OV0gMzFlMDggaXMgMjVlMGIwMDAhDQpbICAxNjIuMjMzMTMxXSAzMWUwOSBpcyAyNWUw
YzAwMCENClsgIDE2Mi4yMzQ4NTJdIDMxZTBhIGlzIDI1ZTBkMDAwIQ0KWyAgMTYyLjIzNjYw
WyAgMTY0LjM2Mzk4NV0gMzE5YmYgaXMgMjY4ZmYwMDAhDQpbICAxNjQuMzY1NjgzXSAzMTlh
NiBpcyAyNjhlYjAwMCENClsgIDE2NC4zNjczODNdIDMxOWE1IGlzIDI2OGVjMDAwIQ0KWyAg
MTY0LjM2OTA1MV0gMzE5YTQgaXMgMjY4ZWQwMDAhDQpbICAxNjQuMzcwNzQ5XSAzMTlhMyBp
cyAyNjhlZTAwMCENClsgIDE2NC4zNzI0MjFdIDMxOWEyIGlzIDI2OGVmMDAwIQ0KWyAgMTY0
LjM3NDEyMl0gMzE5YTEgaXMgMjY4ZjAwMDAhDQpbICAxNjQuMzc1Nzg0XSAzMTlhMCBpcyAy
NjhmMTAwMCENClsgIDE2NC4zNzc0NTldIDMxOTlmIGlzIDI2OGYyMDAwIQ0KWyAgMTY0LjM3
OTE0Ml0gMzE5OWUgaXMgMjY4ZjMwMDAhDQpbICAxNjQuMzgwODI0XSAzMTk5ZCBpcyAyNjhm
NDAwMCENClsgIDE2NC4zODI1MTBdIDMxOTljIGlzIDI2OGY1MDAwIQ0KWyAgMTY0LjM4NTg1
MV0gMzE5ZWIgaXMgMjY4YjYwMDAhDQpbICAxNjQuMzg3NjIyXSAzMTllYyBpcyAyNjhiNzAw
MCENClsgIDE2NC4zODkzMTRdIDMxOWVkIGlzIDI2OGI4MDAwIQ0KWyAgMTY0LjM5MTAzNV0g
MzE5ZWUgaXMgMjY4YjkwMDAhDQpbICAxNjQuMzkyNzIwXSAzMTllZiBpcyAyNjhiYTAwMCEN
ClsgIDE2NC4zOTQ0MThdIDMxOWYwIGlzIDI2OGJiMDAwIQ0KWyAgMTY0LjM5NjE0NF0gMzE5
ZjEgaXMgMjY4YmMwMDAhDQpbICAxNjQuMzk3ODM4XSAzMTlmMiBpcyAyNjhiZDAwMCENClsg
IDE2NC4zOTk1NTFdIDMxOWYzIGlzIDI2OGJlMDAwIQ0KWyAgMTY0LjQwMTI0Nl0gMzE5ZjQg
aXMgMjY4YmYwMDAhDQpbICAxNjQuNDAyOTQzXSAzMTlkZiBpcyAyNjhjYjAwMCENClsgIDE2
NC40MDQ2ODRdIDMxOWRlIGlzIDI2OGNjMDAwIQ0KWyAgMTY0LjQwNjM4NF0gMzE5ZGQgaXMg
MjY4Y2QwMDAhDQpbICAxNjQuNDA4MDk4XSAzMTlkYyBpcyAyNjhjZTAwMCENClsgIDE2NC40
MDk3OTNdIDMxOWRiIGlzIDI2OGNmMDAwIQ0KWyAgMTY0LjQxMTQ5M10gMzE5ZGEgaXMgMjY4
ZDAwMDAhDQpbICAxNjQuNDEzMTU0XSAzMTlkOSBpcyAyNjhkMTAwMCENClsgIDE2NC40MTQ4
MzBdIDMxOWQ4IGlzIDI2OGQyMDAwIQ0KWyAgMTY0LjQxNjUxMV0gMzE5ZDcgaXMgMjY4ZDMw
MDAhDQpbICAxNjQuNDE4MTgwXSAzMTlkNiBpcyAyNjhkNDAwMCENClsgIDE2NC40MTk4NjJd
IDMxOWQ1IGlzIDI2OGQ1MDAwIQ0KWyAgMTY0LjQyMTUyNV0gMzE5YzEgaXMgMjY4YzAwMDAh
DQpbICAxNjQuNDIzMjAzXSAzMTljMiBpcyAyNjhjMTAwMCENClsgIDE2NC40MjQ5MjFdIDMx
OWMzIGlzIDI2OGMyMDAwIQ0KWyAgMTY0LjQyNjU5NF0gMzE5YzQgaXMgMjY4YzMwMDAhDQpb
ICAxNjQuNDI4MzA2XSAzMTljNSBpcyAyNjhjNDAwMCENClsgIDE2NC40Mjk5ODBdIDMxOWM2
IGlzIDI2OGM1MDAwIQ0KWyAgMTY0LjQzMTY2N10gMzE5YzcgaXMgMjY4YzYwMDAhDQpbICAx
NjQuNDMzMzY1XSAzMTljOCBpcyAyNjhjNzAwMCENClsgIDE2NC40MzUwNDZdIDMxOWM5IGlz
IDI2OGM4MDAwIQ0KWyAgMTY0LjQzNjc1NF0gMzE5Y2EgaXMgMjY4YzkwMDAhDQpbICAxNjQu
NDM4NDE1XSAzMTljYiBpcyAyNjhjYTAwMCENClsgIDE2NC40NDEyMjNdIDMxYTAwIGlzIDI2
OGEwMDAwIQ0KWyAgMTY0LjQ0Mjk3OV0gMzFhMDEgaXMgMjY4YTEwMDAhDQpbICAxNjQuNDQ0
NzAwXSAzMWEwMiBpcyAyNjhhMjAwMCENClsgIDE2NC40NDYzODFdIDMxYTAzIGlzIDI2OGEz
MDAwIQ0KWyAgMTY0LjQ0ODA3NV0gMzFhMDQgaXMgMjY4YTQwMDAhDQpbICAxNjQuNDQ5Nzgx
XSAzMWEwNSBpcyAyNjhhNTAwMCENClsgIDE2NC40NTE0NjVdIDMxYTA2IGlzIDI2OGE2MDAw
IQ0KWyAgMTY0LjQ1MzE3Nl0gMzFhMDcgaXMgMjY4YTcwMDAhDQpbICAxNjQuNDU0ODY0XSAz
MWEwOCBpcyAyNjhhODAwMCENClsgIDE2NC40NTY1MzJdIDMxYTA5IGlzIDI2OGE5MDAwIQ0K
WyAgMTY0LjQ1ODIyOV0gMzFhMGEgaXMgMjY4YWEwMDAhDQpbICAxNjQuNDU5OTA4XSAzMWEw
YiBpcyAyNjg5NjAwMCENClsgIDE2NC40NjE2MjJdIDMxYTBjIGlzIDI2ODk3MDAwIQ0KWyAg
MTY0LjQ2MzMxNl0gMzFhMGQgaXMgMjY4OTgwMDAhDQpbICAxNjQuNDY1MDE2XSAzMWEwZSBp
cyAyNjg5OTAwMCENClsgIDE2NC40NjY3NDFdIDMxYTBmIGlzIDI2ODlhMDAwIQ0KWyAgMTY0
LjQ2ODQyMF0gMzFhMTAgaXMgMjY4OWIwMDAhDQpbICAxNjQuNDcwMTQyXSAzMWExMSBpcyAy
Njg5YzAwMCENClsgIDE2NC40NzE4MjBdIDMxYTEyIGlzIDI2ODlkMDAwIQ0KWyAgMTY0LjQ3
MzUxMl0gMzFhMTMgaXMgMjY4OWUwMDAhDQpbICAxNjQuNDc1MjA2XSAzMWExNCBpcyAyNjg5
ZjAwMCENClsgIDE2NC40NzY4ODJdIDMxOWZmIGlzIDI2ODhiMDAwIQ0KWyAgMTY0LjQ3ODU3
N10gMzE5ZmUgaXMgMjY4OGMwMDAhDQpbICAxNjQuNDgwMjY5XSAzMTlmZCBpcyAyNjg4ZDAw
MCENClsgIDE2NC40ODE5NTNdIDMxOWZjIGlzIDI2ODhlMDAwIQ0KWyAgMTY0LjQ4MzY2OF0g
MzE5ZmIgaXMgMjY4OGYwMDAhDQpbICAxNjQuNDg1MzUyXSAzMTlmYSBpcyAyNjg5MDAwMCEN
ClsgIDE2NC40ODcwNjddIDMxOWY5IGlzIDI2ODkxMDAwIQ0KWyAgMTY0LjQ4ODc1OF0gMzE5
ZjggaXMgMjY4OTIwMDAhDQpbICAxNjQuNDkwNDc2XSAzMTlmNyBpcyAyNjg5MzAwMCENClsg
IDE2NC40OTIxNzFdIDMxOWY2IGlzIDI2ODk0MDAwIQ0KWyAgMTY0LjQ5Mzg3NV0gMzE5ZjUg
aXMgMjY4OTUwMDAhDQpbICAxNjQuNDk2NDc0XSAzMTllOSBpcyAyNjg2YjAwMCENClsgIDE2
NC40OTgyMTNdIDMxOWU4IGlzIDI2ODZjMDAwIQ0KWyAgMTY0LjQ5OTkyMF0gMzE5ZTcgaXMg
MjY4NmQwMDAhDQpbICAxNjQuNTAxNjEyXSAzMTllNiBpcyAyNjg2ZTAwMCENClsgIDE2NC41
MDMzMjhdIDMxOWU1IGlzIDI2ODZmMDAwIQ0KWyAgMTY0LjUwNTA0M10gMzE5ZTQgaXMgMjY4
NzAwMDAhDQpbICAxNjQuNTA2NzYyXSAzMTllMyBpcyAyNjg3MTAwMCENClsgIDE2NC41MDg0
NzhdIDMxOWUyIGlzIDI2ODcyMDAwIQ0KWyAgMTY0LjUxMDE5MF0gMzE5ZTEgaXMgMjY4NzMw
MDAhDQpbICAxNjQuNTExOTA0XSAzMTllMCBpcyAyNjg3NDAwMCENClsgIDE2NC41MTM2MDld
IDMxYTE1IGlzIDI2ODc1MDAwIQ0KWyAgMTY0LjUxNTMyM10gMzE5ZWEgaXMgMjY4NzYwMDAh
DQpbICAxNjQuNTE3MDQxXSAzMWEyOSBpcyAyNjg3NzAwMCENClsgIDE2NC41MTg3NTBdIDMx
YTJhIGlzIDI2ODc4MDAwIQ0KWyAgMTY0LjUyMDUxNl0gMzFhMmIgaXMgMjY4NzkwMDAhDQpb
ICAxNjQuNTIyMjM4XSAzMWEyYyBpcyAyNjg3YTAwMCENClsgIDE2NC41MjM5OTZdIDMxYTJk
IGlzIDI2ODdiMDAwIQ0KWyAgMTY0LjUyNTcwOF0gMzFhMmUgaXMgMjY4N2MwMDAhDQpbICAx
NjQuNTI3NDM2XSAzMWEyZiBpcyAyNjg3ZDAwMCENClsgIDE2NC41MjkxNzhdIDMxYTMwIGlz
IDI2ODdlMDAwIQ0KWyAgMTY0LjUzMDkwNV0gMzFhMzEgaXMgMjY4N2YwMDAhDQpbICAxNjQu
NTMzNTk0XSAzMWEyMCBpcyAyNjg1NjAwMCENClsgIDE2NC41MzU1MTddIDMxYTIxIGlzIDI2
ODU3MDAwIQ0KWyAgMTY0LjUzNzM2NF0gMzFhMjIgaXMgMjY4NTgwMDAhDQpbICAxNjQuNTM5
MjI4XSAzMWEyMyBpcyAyNjg1OTAwMCENClsgIDE2NC41NDExNjRdIDMxYTI0IGlzIDI2ODVh
MDAwIQ0KWyAgMTY0LjU0MzAyMl0gMzFhMjUgaXMgMjY4NWIwMDAhDQpbICAxNjQuNTQ0OTI0
XSAzMWEyNiBpcyAyNjg1YzAwMCENClsgIDE2NC41NDY2NzhdIDMxYTI3IGlzIDI2ODVkMDAw
IQ0KWyAgMTY0LjU0ODQwOV0gMzFhMjggaXMgMjY4NWUwMDAhDQpbICAxNjQuNTUwMTU3XSAz
MWE0OCBpcyAyNjg1ZjAwMCENClsgIDE2NC41Nzg2NzBdIDMxYTNkIGlzIDI2ODQwMDAwIQ0K
WyAgMTY0LjU4MDQyMF0gMzFhM2UgaXMgMjY4NDEwMDAhDQpbICAxNjQuNTgyMjM3XSAzMWEz
ZiBpcyAyNjg0MjAwMCENClsgIDE2NC41ODQwNzddIDMxYTQwIGlzIDI2ODQzMDAwIQ0KWyAg
MTY0LjU4NTc4N10gMzFhNDEgaXMgMjY4NDQwMDAhDQpbICAxNjQuNTg3NTMxXSAzMWE0MiBp
cyAyNjg0NTAwMCENClsgIDE2NC41ODkyMzJdIDMxYTQzIGlzIDI2ODQ2MDAwIQ0KWyAgMTY0
LjU5MDk2NV0gMzFhNDQgaXMgMjY4NDcwMDAhDQpbICAxNjQuNTkyNjY0XSAzMWE0NSBpcyAy
Njg0ODAwMCENClsgIDE2NC41OTQ0MzldIDMxYTQ2IGlzIDI2ODQ5MDAwIQ0KWyAgMTY0LjU5
NjEyNl0gMzFhNDcgaXMgMjY4NGEwMDAhDQpbICAxNjQuNTk4MjU5XSAzMWE3MiBpcyAyNjgy
MDAwMCENClsgIDE2NC41OTk5NzRdIDMxYTRhIGlzIDI2ODIxMDAwIQ0KWyAgMTY0LjYwMTY3
Nl0gMzFhNGIgaXMgMjY4MjIwMDAhDQpbICAxNjQuNjAzMzk1XSAzMWE0YyBpcyAyNjgyMzAw
MCENClsgIDE2NC42MDUwNzBdIDMxYTRkIGlzIDI2ODI0MDAwIQ0KWyAgMTY0LjYwNjc2NV0g
MzFhNGUgaXMgMjY4MjUwMDAhDQpbICAxNjQuNjA4NDU5XSAzMWE0ZiBpcyAyNjgyNjAwMCEN
ClsgIDE2NC42MTAxNTVdIDMxYTUwIGlzIDI2ODI3MDAwIQ0KWyAgMTY0LjYxMTg0OV0gMzFh
NTEgaXMgMjY4MjgwMDAhDQpbICAxNjQuNjEzNTM2XSAzMWE1MiBpcyAyNjgyOTAwMCENClsg
IDE2NC42MTUyMTddIDMxYTUzIGlzIDI2ODJhMDAwIQ0KWyAgMTY0LjYxNjg4N10gMzFhNTQg
aXMgMjY4MTYwMDAhDQpbICAxNjQuNjE4NTQ4XSAzMWE1NSBpcyAyNjgxNzAwMCENClsgIDE2
NC42MjAyNDBdIDMxYTU2IGlzIDI2ODE4MDAwIQ0KWyAgMTY0LjYyMTkwMV0gMzFhNTcgaXMg
MjY4MTkwMDAhDQpbICAxNjQuNjIzNTg1XSAzMWE1OCBpcyAyNjgxYTAwMCENClsgIDE2NC42
MjUyNDBdIDMxYTU5IGlzIDI2ODFiMDAwIQ0KWyAgMTY0LjYyNjkxN10gMzFhNWEgaXMgMjY4
MWMwMDAhDQpbICAxNjQuNjI4NTk0XSAzMWE1YiBpcyAyNjgxZDAwMCENClsgIDE2NC42MzAy
NzBdIDMxYTVjIGlzIDI2ODFlMDAwIQ0KWyAgMTY0LjYzMTk0NV0gMzFhNWQgaXMgMjY4MWYw
MDAhDQpbICAxNjQuNjMzNjAxXSAzMWEzMiBpcyAyNjgyYjAwMCENClsgIDE2NC42MzUyNTdd
IDMxYTE2IGlzIDI2ODJjMDAwIQ0KWyAgMTY0LjYzNjk0OF0gMzFhMTcgaXMgMjY4MmQwMDAh
DQpbICAxNjQuNjM4NjExXSAzMWExOCBpcyAyNjgyZTAwMCENClsgIDE2NC42NDAzMDZdIDMx
YTE5IGlzIDI2ODJmMDAwIQ0KWyAgMTY0LjY0MTk3OV0gMzFhMWEgaXMgMjY4MzAwMDAhDQpb
ICAxNjQuNjQzNjc3XSAzMWExYiBpcyAyNjgzMTAwMCENClsgIDE2NC42NDUzNjVdIDMxYTFj
IGlzIDI2ODMyMDAwIQ0KWyAgMTY0LjY0NzA1OF0gMzFhMWQgaXMgMjY4MzMwMDAhDQpbICAx
NjQuNjQ4NzUyXSAzMWExZSBpcyAyNjgzNDAwMCENClsgIDE2NC42NTA0MzldIDMxYTFmIGlz
IDI2ODM1MDAwIQ0KWyAgMTY0LjY1MjEwNF0gMzFhNjcgaXMgMjY4MzYwMDAhDQpbICAxNjQu
NjUzODAyXSAzMWE2OCBpcyAyNjgzNzAwMCENClsgIDE2NC42NTU0NTddIDMxYTY5IGlzIDI2
ODM4MDAwIQ0KWyAgMTY0LjY1NzE0M10gMzFhNmEgaXMgMjY4MzkwMDAhDQpbICAxNjQuNjU4
Nzk4XSAzMWE2YiBpcyAyNjgzYTAwMCENClsgIDE2NC42NjA0NjhdIDMxYTZjIGlzIDI2ODNi
MDAwIQ0KWyAgMTY0LjY2MjE0MF0gMzFhNmQgaXMgMjY4M2MwMDAhDQpbICAxNjQuNjYzODA0
XSAzMWE2ZSBpcyAyNjgzZDAwMCENClsgIDE2NC42NjU0NzBdIDMxYTZmIGlzIDI2ODNlMDAw
IQ0KWyAgMTY0LjY2NzEzNl0gMzFhNzAgaXMgMjY4M2YwMDAhDQpbICAxNjQuNjcwNDIwXSAz
MWE5MiBpcyAyNjdmNjAwMCENClsgIDE2NC42NzIxNTBdIDMxYTkzIGlzIDI2N2Y3MDAwIQ0K
WyAgMTY0LjY3Mzg4OF0gMzFhOTQgaXMgMjY3ZjgwMDAhDQpbICAxNjQuNjc1NTgyXSAzMWE5
NSBpcyAyNjdmOTAwMCENClsgIDE2NC42NzcyNzZdIDMxYTk2IGlzIDI2N2ZhMDAwIQ0KWyAg
MTY0LjY3ODk4MV0gMzFhOTcgaXMgMjY3ZmIwMDAhDQpbICAxNjQuNjgwNjcxXSAzMWE5OCBp
cyAyNjdmYzAwMCENClsgIDE2NC42ODIzNzZdIDMxYTk5IGlzIDI2N2ZkMDAwIQ0KWyAgMTY0
LjY4NDA1OV0gMzFhOWEgaXMgMjY3ZmUwMDAhDQpbICAxNjQuNjg1NzM1XSAzMWE5YiBpcyAy
NjdmZjAwMCENClsgIDE2NC42ODc0NDRdIDMxYTczIGlzIDI2ODBiMDAwIQ0KWyAgMTY0LjY4
OTEzM10gMzFhNWUgaXMgMjY4MGMwMDAhDQpbICAxNjQuNjkwODM2XSAzMWE1ZiBpcyAyNjgw
ZDAwMCENClsgIDE2NC42OTI0OTddIDMxYTYwIGlzIDI2ODBlMDAwIQ0KWyAgMTY0LjY5NDIw
NF0gMzFhNjEgaXMgMjY4MGYwMDAhDQpbICAxNjQuNjk1ODY0XSAzMWE2MiBpcyAyNjgxMDAw
MCENClsgIDE2NC42OTc1MzNdIDMxYTYzIGlzIDI2ODExMDAwIQ0KWyAgMTY0LjY5OTIyMF0g
MzFhNjQgaXMgMjY4MTIwMDAhDQpbICAxNjQuNzAwODk2XSAzMWE2NSBpcyAyNjgxMzAwMCEN
ClsgIDE2NC43MDI1OTNdIDMxYTY2IGlzIDI2ODE0MDAwIQ0KWyAgMTY0LjcwNDI4MF0gMzFh
ODYgaXMgMjY4MTUwMDAhDQpbICAxNjQuNzA1OTQ3XSAzMWE4NyBpcyAyNjgwMDAwMCENClsg
IDE2NC43MDc2NTFdIDMxYTg4IGlzIDI2ODAxMDAwIQ0KWyAgMTY0LjcwOTMyNV0gMzFhODkg
aXMgMjY4MDIwMDAhDQpbICAxNjQuNzExMDM3XSAzMWE4YSBpcyAyNjgwMzAwMCENClsgIDE2
NC43MTI3MTZdIDMxYThiIGlzIDI2ODA0MDAwIQ0KWyAgMTY0LjcxNDQwOF0gMzFhOGMgaXMg
MjY4MDUwMDAhDQpbICAxNjQuNzE2MTExXSAzMWE4ZCBpcyAyNjgwNjAwMCENClsgIDE2NC43
MTc4MDNdIDMxYThlIGlzIDI2ODA3MDAwIQ0KWyAgMTY0LjcxOTUwNl0gMzFhOGYgaXMgMjY4
MDgwMDAhDQpbICAxNjQuNzIxMTkzXSAzMWE5MCBpcyAyNjgwOTAwMCENClsgIDE2NC43MjI4
NzBdIDMxYTkxIGlzIDI2ODBhMDAwIQ0KWyAgMTY0LjcyNTU4MV0gMzFhYTkgaXMgMjY3ZTAw
MDAhDQpbICAxNjQuNzI3Mzc3XSAzMWFhYSBpcyAyNjdlMTAwMCENClsgIDE2NC43MjkwOTZd
IDMxYWFiIGlzIDI2N2UyMDAwIQ0KWyAgMTY0LjczMDgxNV0gMzFhYWMgaXMgMjY3ZTMwMDAh
DQpbICAxNjQuNzMyNTQyXSAzMWFhZCBpcyAyNjdlNDAwMCENClsgIDE2NC43MzQyNjddIDMx
YWFlIGlzIDI2N2U1MDAwIQ0KWyAgMTY0LjczNjA2MF0gMzFhYWYgaXMgMjY3ZTYwMDAhDQpb
ICAxNjQuNzM3NzgzXSAzMWFiMCBpcyAyNjdlNzAwMCENClsgIDE2NC43Mzk0OTFdIDMxYWIx
IGlzIDI2N2U4MDAwIQ0KWyAgMTY0Ljc0MTI0MV0gMzFhYjIgaXMgMjY3ZTkwMDAhDQpbICAx
NjQuNzQyOTMxXSAzMWFiMyBpcyAyNjdlYTAwMCENClsgIDE2NC43NDQ2NTRdIDMxYWI0IGlz
IDI2N2Q2MDAwIQ0KWyAgMTY0Ljc0NjMzOF0gMzFhYjUgaXMgMjY3ZDcwMDAhDQpbICAxNjQu
NzQ4MDI5XSAzMWFiNiBpcyAyNjdkODAwMCENClsgIDE2NC43NDk3NDBdIDMxYWI3IGlzIDI2
N2Q5MDAwIQ0KWyAgMTY0Ljc1MTQyMl0gMzFhYjggaXMgMjY3ZGEwMDAhDQpbICAxNjQuNzUz
MTExXSAzMWFiOSBpcyAyNjdkYjAwMCENClsgIDE2NC43NTQ3OThdIDMxYWJhIGlzIDI2N2Rj
MDAwIQ0KWyAgMTY0Ljc1NjQ1OV0gMzFhYmIgaXMgMjY3ZGQwMDAhDQpbICAxNjQuNzU4MTU3
XSAzMWFiYyBpcyAyNjdkZTAwMCENClsgIDE2NC43NTk4MThdIDMxYWJkIGlzIDI2N2RmMDAw
IQ0KWyAgMTY0Ljc2MTUwNF0gMzFhYTggaXMgMjY3Y2IwMDAhDQpbICAxNjQuNzYzMTc3XSAz
MWFhNSBpcyAyNjdjYzAwMCENClsgIDE2NC43NjQ4NjRdIDMxYWE0IGlzIDI2N2NkMDAwIQ0K
WyAgMTY0Ljc2NjU0Nl0gMzFhYTMgaXMgMjY3Y2UwMDAhDQpbICAxNjQuNzY4MjI4XSAzMWFh
MiBpcyAyNjdjZjAwMCENClsgIDE2NC43Njk5MTJdIDMxYWExIGlzIDI2N2QwMDAwIQ0KWyAg
MTY0Ljc3MTYwMF0gMzFhYTAgaXMgMjY3ZDEwMDAhDQpbICAxNjQuNzczMjkyXSAzMWE5ZiBp
cyAyNjdkMjAwMCENClsgIDE2NC43NzQ5OTZdIDMxYTllIGlzIDI2N2QzMDAwIQ0KWyAgMTY0
Ljc3NjY2OV0gMzFhOWQgaXMgMjY3ZDQwMDAhDQpbICAxNjQuNzc4MzczXSAzMWE5YyBpcyAy
NjdkNTAwMCENClsgIDE2NC43ODA2MjJdIDMxYTdlIGlzIDI2N2I2MDAwIQ0KWyAgMTY0Ljc4
MjM2NF0gMzFhN2YgaXMgMjY3YjcwMDAhDQpbICAxNjQuNzg0MDc5XSAzMWE4MCBpcyAyNjdi
ODAwMCENClsgIDE2NC43ODU3OTldIDMxYTgxIGlzIDI2N2I5MDAwIQ0KWyAgMTY0Ljc4NzQ4
OF0gMzFhODIgaXMgMjY3YmEwMDAhDQpbICAxNjQuNzg5MTgyXSAzMWE4MyBpcyAyNjdiYjAw
MCENClsgIDE2NC43OTA4OTddIDMxYTg0IGlzIDI2N2JjMDAwIQ0KWyAgMTY0Ljc5MjU3N10g
MzFhODUgaXMgMjY3YmQwMDAhDQpbICAxNjQuNzk0Mjg1XSAzMWFjNiBpcyAyNjdiZTAwMCEN
ClsgIDE2NC43OTU5ODJdIDMxYWM3IGlzIDI2N2JmMDAwIQ0KWyAgMTY0LjgwMzIxMl0gMzFh
YzggaXMgMjY3YTAwMDAhDQpbICAxNjQuODA0OTE2XSAzMWFiZiBpcyAyNjdhMTAwMCENClsg
IDE2NC44MDY2MDRdIDMxYWMwIGlzIDI2N2EyMDAwIQ0KWyAgMTY0LjgwODQ1MV0gMzFhYzEg
aXMgMjY3YTMwMDAhDQpbICAxNjQuODEwMTY0XSAzMWFjMiBpcyAyNjdhNDAwMCENClsgIDE2
NC44MTE4NjFdIDMxYWMzIGlzIDI2N2E1MDAwIQ0KWyAgMTY0LjgxMzU1Nl0gMzFhYzQgaXMg
MjY3YTYwMDAhDQpbICAxNjQuODE1MjQ4XSAzMWFjNSBpcyAyNjdhNzAwMCENClsgIDE2NC44
MTY5NDJdIDMxYWU1IGlzIDI2N2E4MDAwIQ0KWyAgMTY0LjgxODYyMF0gMzFhZTYgaXMgMjY3
YTkwMDAhDQpbICAxNjQuODIwMzMxXSAzMWFlNyBpcyAyNjdhYTAwMCENClsgIDE2NC44MjIx
MThdIDMxYWU5IGlzIDI2Nzk3MDAwIQ0KWyAgMTY0LjgyMzg0N10gMzFhZWEgaXMgMjY3OTgw
MDAhDQpbICAxNjQuODI1NTE3XSAzMWFlYiBpcyAyNjc5OTAwMCENClsgIDE2NC44MjcyMDBd
IDMxYWVjIGlzIDI2NzlhMDAwIQ0KWyAgMTY0LjgyODg5Ml0gMzFhZWQgaXMgMjY3OWIwMDAh
DQpbICAxNjQuODMwNTY4XSAzMWFlZSBpcyAyNjc5YzAwMCENClsgIDE2NC44MzIyNTRdIDMx
YWVmIGlzIDI2NzlkMDAwIQ0KWyAgMTY0LjgzMzkyNV0gMzFhZjAgaXMgMjY3OWUwMDAhDQpb
ICAxNjQuODM1NTg5XSAzMWFmMSBpcyAyNjc5ZjAwMCENClsgIDE2NC44NTgyNzVdIDMxYWQz
IGlzIDI2Nzc2MDAwIQ0KWyAgMTY0Ljg1OTk2NF0gMzFhZDQgaXMgMjY3NzcwMDAhDQpbICAx
NjQuODYxNjY3XSAzMWFkNSBpcyAyNjc3ODAwMCENClsgIDE2NC44NjMzMzFdIDMxYWQ2IGlz
IDI2Nzc5MDAwIQ0KWyAgMTY0Ljg2NTAyN10gMzFhZDcgaXMgMjY3N2EwMDAhDQpbICAxNjQu
ODY2NzQ0XSAzMWFkOCBpcyAyNjc3YjAwMCENClsgIDE2NC44Njg0MTRdIDMxYWQ5IGlzIDI2
NzdjMDAwIQ0KWyAgMTY0Ljg3MDExNl0gMzFhZGEgaXMgMjY3N2QwMDAhDQpbICAxNjQuODcx
Nzc1XSAzMWFkYiBpcyAyNjc3ZTAwMCENClsgIDE2NC44NzM0NzZdIDMxYWRjIGlzIDI2Nzdm
MDAwIQ0KWyAgMTY0Ljg3NTEyOF0gMzFhYmUgaXMgMjY3OGIwMDAhDQpbICAxNjQuODc2ODE2
XSAzMWE3NCBpcyAyNjc4YzAwMCENClsgIDE2NC44Nzg0OThdIDMxYTc1IGlzIDI2NzhkMDAw
IQ0KWyAgMTY0Ljg4MDE4MV0gMzFhNzYgaXMgMjY3OGUwMDAhDQpbICAxNjQuODgxODYxXSAz
MWE3NyBpcyAyNjc4ZjAwMCENClsgIDE2NC44ODM1MzhdIDMxYTc4IGlzIDI2NzkwMDAwIQ0K
WyAgMTY0Ljg4NTE5Nl0gMzFhNzkgaXMgMjY3OTEwMDAhDQpbICAxNjQuODg2ODk1XSAzMWE3
YSBpcyAyNjc5MjAwMCENClsgIDE2NC44ODg1NTZdIDMxYTdiIGlzIDI2NzkzMDAwIQ0KWyAg
MTY0Ljg5MDI0OV0gMzFhN2MgaXMgMjY3OTQwMDAhDQpbICAxNjQuODkxOTE3XSAzMWE3ZCBp
cyAyNjc5NTAwMCENClsgIDE2NC44OTM2MDhdIDMxYWYyIGlzIDI2NzgwMDAwIQ0KWyAgMTY0
Ljg5NTMwMF0gMzFhYzkgaXMgMjY3ODEwMDAhDQpbICAxNjQuODk2OTg5XSAzMWFjYSBpcyAy
Njc4MjAwMCENClsgIDE2NC44OTg2NzddIDMxYWNiIGlzIDI2NzgzMDAwIQ0KWyAgMTY0Ljkw
MDM2M10gMzFhY2MgaXMgMjY3ODQwMDAhDQpbICAxNjQuOTAyMDQ3XSAzMWFjZCBpcyAyNjc4
NTAwMCENClsgIDE2NC45MDM3NjNdIDMxYWNlIGlzIDI2Nzg2MDAwIQ0KWyAgMTY0LjkwNTQ0
MV0gMzFhY2YgaXMgMjY3ODcwMDAhDQpbICAxNjQuOTA3MTUwXSAzMWFkMCBpcyAyNjc4ODAw
MCENClsgIDE2NC45MDg4MzBdIDMxYWQxIGlzIDI2Nzg5MDAwIQ0KWyAgMTY0LjkxMDUzM10g
MzFhZDIgaXMgMjY3OFsgIDE2Ny4wMzk5MjBdIDMxNjgyIGlzIDI2YTMxMDAwIQ0KWyAgMTY3
LjA0MTYxN10gMzE2ODEgaXMgMjZhMzAwMDAhDQpbICAxNjcuMDQzMjk1XSAzMTY4MCBpcyAy
NmE0ZDAwMCENClsgIDE2Ny4wNDUwMTBdIDMxNjdmIGlzIDI2YTRmMDAwIQ0KWyAgMTY3LjA0
NjY5M10gMzE2N2UgaXMgMjZhNGUwMDAhDQpbICAxNjcuMDQ5MjYwXSAzMTY2OCBpcyAyNmEx
MzAwMCENClsgIDE2Ny4wNTA5OTZdIDMxNjY5IGlzIDI2YTE0MDAwIQ0KWyAgMTY3LjA1Mjcw
MF0gMzE2NmEgaXMgMjZhMTUwMDAhDQpbICAxNjcuMDU0NDM5XSAzMTY2YiBpcyAyNmExNjAw
MCENClsgIDE2Ny4wNTYxNDddIDMxNjZjIGlzIDI2YTE3MDAwIQ0KWyAgMTY3LjA1NzkwM10g
MzE2NmQgaXMgMjZhMTgwMDAhDQpbICAxNjcuMDU5NjAyXSAzMTY2ZSBpcyAyNmEzOTAwMCEN
ClsgIDE2Ny4wNjEzMzNdIDMxNjZmIGlzIDI2YTNhMDAwIQ0KWyAgMTY3LjA2MzAzMl0gMzE2
NzAgaXMgMjZhM2IwMDAhDQpbICAxNjcuMDY0NzQyXSAzMTY3MSBpcyAyNmEzYzAwMCENClsg
IDE2Ny4wNjY0NjVdIDMxNjY3IGlzIDI2YTA4MDAwIQ0KWyAgMTY3LjA2ODE4NF0gMzE2NjYg
aXMgMjZhMDkwMDAhDQpbICAxNjcuMDY5OTI3XSAzMTY2NSBpcyAyNmEwYTAwMCENClsgIDE2
Ny4wNzE2MzddIDMxNjY0IGlzIDI2YTBiMDAwIQ0KWyAgMTY3LjA3MzMzM10gMzE2NjMgaXMg
MjZhMGMwMDAhDQpbICAxNjcuMDc1MDYyXSAzMTY2MiBpcyAyNmEwZDAwMCENClsgIDE2Ny4w
NzY3NjBdIDMxNjYxIGlzIDI2YTBlMDAwIQ0KWyAgMTY3LjA3ODQ3MF0gMzE2NjAgaXMgMjZh
MGYwMDAhDQpbICAxNjcuMDgwMTYyXSAzMTY1ZiBpcyAyNmExMDAwMCENClsgIDE2Ny4wODE4
NThdIDMxNjVlIGlzIDI2YTExMDAwIQ0KWyAgMTY3LjA4MzU5M10gMzE2OWUgaXMgMjZhMTIw
MDAhDQpbICAxNjcuMDg2MTM5XSAzMTZhOSBpcyAyNjlmMzAwMCENClsgIDE2Ny4wODc5NzNd
IDMxNmFhIGlzIDI2OWY0MDAwIQ0KWyAgMTY3LjA4OTY5Nl0gMzE2YWIgaXMgMjY5ZjUwMDAh
DQpbICAxNjcuMDkxNDMxXSAzMTZhYyBpcyAyNjlmNjAwMCENClsgIDE2Ny4wOTMxNDJdIDMx
NmFkIGlzIDI2OWY3MDAwIQ0KWyAgMTY3LjA5NDkzNl0gMzE2YWUgaXMgMjY5ZjgwMDAhDQpb
ICAxNjcuMDk2NjQ3XSAzMTZhZiBpcyAyNjlmOTAwMCENClsgIDE2Ny4wOTgzNTNdIDMxNmIw
IGlzIDI2OWZhMDAwIQ0KWyAgMTY3LjEwMDA4OF0gMzE2YjEgaXMgMjY5ZmIwMDAhDQpbICAx
NjcuMTAxNzg5XSAzMTZiMiBpcyAyNjlmYzAwMCENClsgIDE2Ny4xMDM1MzFdIDMxNmE4IGlz
IDI2OWU4MDAwIQ0KWyAgMTY3LjEwNTIzNl0gMzE2YTcgaXMgMjY5ZTkwMDAhDQpbICAxNjcu
MTA2OTM5XSAzMTZhNiBpcyAyNjllYTAwMCENClsgIDE2Ny4xMDg2MzZdIDMxNmE1IGlzIDI2
OWViMDAwIQ0KWyAgMTY3LjExMDMyN10gMzE2YTQgaXMgMjY5ZWMwMDAhDQpbICAxNjcuMTEy
MDEwXSAzMTZhMyBpcyAyNjllZDAwMCENClsgIDE2Ny4xMTM2OTFdIDMxNmEyIGlzIDI2OWVl
MDAwIQ0KWyAgMTY3LjExNTM3M10gMzE2YTEgaXMgMjY5ZWYwMDAhDQpbICAxNjcuMTE3MDQ4
XSAzMTZhMCBpcyAyNjlmMDAwMCENClsgIDE2Ny4xMTg3MTRdIDMxNjlmIGlzIDI2OWYxMDAw
IQ0KWyAgMTY3LjEyMDQyM10gMzE2NzIgaXMgMjY5ZjIwMDAhDQpbICAxNjcuMTIzODIzXSAz
MTZiNCBpcyAyNjliMzAwMCENClsgIDE2Ny4xMjU1NTJdIDMxNmI1IGlzIDI2OWI0MDAwIQ0K
WyAgMTY3LjEyNzI3OV0gMzE2ZDUgaXMgMjY5YjUwMDAhDQpbICAxNjcuMTI5MDA3XSAzMTZk
NiBpcyAyNjliNjAwMCENClsgIDE2Ny4xMzA3MjddIDMxNmQ3IGlzIDI2OWI3MDAwIQ0KWyAg
MTY3LjEzMjQ1MV0gMzE2ZDggaXMgMjY5YjgwMDAhDQpbICAxNjcuMTM0MTYyXSAzMTZkOSBp
cyAyNjliOTAwMCENClsgIDE2Ny4xMzU4NzFdIDMxNmRhIGlzIDI2OWJhMDAwIQ0KWyAgMTY3
LjEzNzYwN10gMzE2ZGIgaXMgMjY5YmIwMDAhDQpbICAxNjcuMTM5Mjk4XSAzMTZkYyBpcyAy
NjliYzAwMCENClsgIDE2Ny4xNDEwMzJdIDMxNmJjIGlzIDI2OWM4MDAwIQ0KWyAgMTY3LjE0
MjcxOF0gMzE2YmIgaXMgMjY5YzkwMDAhDQpbICAxNjcuMTQ0NDM4XSAzMTZiYSBpcyAyNjlj
YTAwMCENClsgIDE2Ny4xNDYxMTddIDMxNmI5IGlzIDI2OWNiMDAwIQ0KWyAgMTY3LjE0Nzgw
OF0gMzE2YjggaXMgMjY5Y2MwMDAhDQpbICAxNjcuMTQ5NTIzXSAzMTZiNyBpcyAyNjljZDAw
MCENClsgIDE2Ny4xNTExOThdIDMxNmI2IGlzIDI2OWNlMDAwIQ0KWyAgMTY3LjE1Mjg5MV0g
MzE2NzUgaXMgMjY5Y2YwMDAhDQpbICAxNjcuMTU0NTY2XSAzMTY3NCBpcyAyNjlkMDAwMCEN
ClsgIDE2Ny4xNTYyMjFdIDMxNjczIGlzIDI2OWQxMDAwIQ0KWyAgMTY3LjE1NzkyMl0gMzE2
YjMgaXMgMjY5ZDIwMDAhDQpbICAxNjcuMTU5NTY1XSAzMTZjNyBpcyAyNjliZDAwMCENClsg
IDE2Ny4xNjEyNjRdIDMxNmM2IGlzIDI2OWJlMDAwIQ0KWyAgMTY3LjE2MjkzMl0gMzE2YzUg
aXMgMjY5YmYwMDAhDQpbICAxNjcuMTY0NjE5XSAzMTZjNCBpcyAyNjljMDAwMCENClsgIDE2
Ny4xNjYzMTZdIDMxNmMzIGlzIDI2OWMxMDAwIQ0KWyAgMTY3LjE2Nzk5Nl0gMzE2YzIgaXMg
MjY5YzIwMDAhDQpbICAxNjcuMTY5NjgzXSAzMTZjMSBpcyAyNjljMzAwMCENClsgIDE2Ny4x
NzEzNThdIDMxNmMwIGlzIDI2OWM0MDAwIQ0KWyAgMTY3LjE3MzAyMF0gMzE2YmYgaXMgMjY5
YzUwMDAhDQpbICAxNjcuMTc0NzE5XSAzMTZiZSBpcyAyNjljNjAwMCENClsgIDE2Ny4xNzYz
NjldIDMxNmJkIGlzIDI2OWM3MDAwIQ0KWyAgMTY3LjE3OTA4OV0gMzE2ZTggaXMgMjY5OWQw
MDAhDQpbICAxNjcuMTgwODQ5XSAzMTZlOSBpcyAyNjk5ZTAwMCENClsgIDE2Ny4xODI1MzZd
IDMxNmVhIGlzIDI2OTlmMDAwIQ0KWyAgMTY3LjE4NDIyMF0gMzE2ZWIgaXMgMjY5YTAwMDAh
DQpbICAxNjcuMTg1ODg2XSAzMTZlYyBpcyAyNjlhMTAwMCENClsgIDE2Ny4xODc1OTJdIDMx
NmVkIGlzIDI2OWEyMDAwIQ0KWyAgMTY3LjE4OTI3MF0gMzE2ZWUgaXMgMjY5YTMwMDAhDQpb
ICAxNjcuMTkwOTY1XSAzMTZlZiBpcyAyNjlhNDAwMCENClsgIDE2Ny4xOTI2MzBdIDMxNmYw
IGlzIDI2OWE1MDAwIQ0KWyAgMTY3LjE5NDMxOF0gMzE2ZjEgaXMgMjY5YTYwMDAhDQpbICAx
NjcuMTk1OTg2XSAzMTZmMiBpcyAyNjlhNzAwMCENClsgIDE2Ny4xOTc2NjNdIDMxNmYzIGlz
IDI2OTkzMDAwIQ0KWyAgMTY3LjE5OTM0OV0gMzE2ZjYgaXMgMjY5OTQwMDAhDQpbICAxNjcu
MjAxMDM4XSAzMTZmNyBpcyAyNjk5NTAwMCENClsgIDE2Ny4yMDI3MzRdIDMxNmY4IGlzIDI2
OTk2MDAwIQ0KWyAgMTY3LjIwNDQyOF0gMzE2ZjkgaXMgMjY5OTcwMDAhDQpbICAxNjcuMjA2
MDk4XSAzMTZmYSBpcyAyNjk5ODAwMCENClsgIDE2Ny4yMDc3OTZdIDMxNmZiIGlzIDI2OTk5
MDAwIQ0KWyAgMTY3LjIwOTQ1N10gMzE2ZmMgaXMgMjY5OWEwMDAhDQpbICAxNjcuMjExMTM2
XSAzMTZmZCBpcyAyNjk5YjAwMCENClsgIDE2Ny4yMTI3OTddIDMxNmZlIGlzIDI2OTljMDAw
IQ0KWyAgMTY3LjIxNDQ2MV0gMzE2ZTcgaXMgMjY5ODgwMDAhDQpbICAxNjcuMjE2MTM4XSAz
MTZlNiBpcyAyNjk4OTAwMCENClsgIDE2Ny4yMTc4MTNdIDMxNmU1IGlzIDI2OThhMDAwIQ0K
WyAgMTY3LjIxOTQ4M10gMzE2ZTQgaXMgMjY5OGIwMDAhDQpbICAxNjcuMjIxMTU0XSAzMTZl
MyBpcyAyNjk4YzAwMCENClsgIDE2Ny4yMjI4MjFdIDMxNmUyIGlzIDI2OThkMDAwIQ0KWyAg
MTY3LjIyNDUxOF0gMzE2ZTEgaXMgMjY5OGUwMDAhDQpbICAxNjcuMjI2MTc5XSAzMTZlMCBp
cyAyNjk4ZjAwMCENClsgIDE2Ny4yMjc4NjJdIDMxNmRmIGlzIDI2OTkwMDAwIQ0KWyAgMTY3
LjIyOTUzMF0gMzE2ZGUgaXMgMjY5OTEwMDAhDQpbICAxNjcuMjMxMjE4XSAzMTZkZCBpcyAy
Njk5MjAwMCENClsgIDE2Ny4yMzM4MzRdIDMxNmQxIGlzIDI3MTY4MDAwIQ0KWyAgMTY3LjIz
NTU2M10gMzE2ZDAgaXMgMjcxNjkwMDAhDQpbICAxNjcuMjM3MzExXSAzMTZjZiBpcyAyNzE2
YTAwMCENClsgIDE2Ny4yMzkwMTNdIDMxNmNlIGlzIDI3MTZiMDAwIQ0KWyAgMTY3LjI0MDc2
NF0gMzE2Y2QgaXMgMjcxNmMwMDAhDQpbICAxNjcuMjQyNDY2XSAzMTZjYyBpcyAyNzE2ZDAw
MCENClsgIDE2Ny4yNDQxNzddIDMxNmNiIGlzIDI3MTZlMDAwIQ0KWyAgMTY3LjI0NTg5M10g
MzE2Y2EgaXMgMjcxNmYwMDAhDQpbICAxNjcuMjQ3NTk2XSAzMTZjOSBpcyAyNzE3MDAwMCEN
ClsgIDE2Ny4yNDkzMTddIDMxNmM4IGlzIDI3MTcxMDAwIQ0KWyAgMTY3LjI1MTAxNl0gMzE2
ZmYgaXMgMjcxNzIwMDAhDQpbICAxNjcuMjUyNzE3XSAzMTZkMiBpcyAyNzE3MzAwMCENClsg
IDE2Ny4yNTQ0MTJdIDMxNmQzIGlzIDI3MTc0MDAwIQ0KWyAgMTY3LjI1NjA3Ml0gMzE2ZDQg
aXMgMjcxNzUwMDAhDQpbICAxNjcuMjU3Nzc0XSAzMTcxNSBpcyAyNzE3NjAwMCENClsgIDE2
Ny4yNTk0MzhdIDMxNzE2IGlzIDI3MTc3MDAwIQ0KWyAgMTY3LjI2MTE1MV0gMzE3MTcgaXMg
MjcxNzgwMDAhDQpbICAxNjcuMjYyODMyXSAzMTcxOCBpcyAyNzE3OTAwMCENClsgIDE2Ny4y
NjQ1MzRdIDMxNzE5IGlzIDI3MTdhMDAwIQ0KWyAgMTY3LjI2NjIzMF0gMzE3MWEgaXMgMjcx
N2IwMDAhDQpbICAxNjcuMjY3OTEyXSAzMTcxYiBpcyAyNzE3YzAwMCENClsgIDE2Ny4yNzA0
NzhdIDMxNzBhIGlzIDI3MTUzMDAwIQ0KWyAgMTY3LjI3MjI5N10gMzE3MGIgaXMgMjcxNTQw
MDAhDQpbICAxNjcuMjc0MDQ0XSAzMTcwYyBpcyAyNzE1NTAwMCENClsgIDE2Ny4yNzU3Mjld
IDMxNzBkIGlzIDI3MTU2MDAwIQ0KWyAgMTY3LjI3NzQzOF0gMzE3MGUgaXMgMjcxNTcwMDAh
DQpbICAxNjcuMjc5MTMzXSAzMTcwZiBpcyAyNzE1ODAwMCENClsgIDE2Ny4yODA4MThdIDMx
NzEwIGlzIDI3MTU5MDAwIQ0KWyAgMTY3LjI4MjUyN10gMzE3MTEgaXMgMjcxNWEwMDAhDQpb
ICAxNjcuMjg0MjIwXSAzMTcxMiBpcyAyNzE1YjAwMCENClsgIDE2Ny4yODU5MTBdIDMxNzEz
IGlzIDI3MTVjMDAwIQ0KWyAgMTY3LjI4NzU5M10gMzE3MDkgaXMgMjcxNDgwMDAhDQpbICAx
NjcuMjg5MjU5XSAzMTcwOCBpcyAyNzE0OTAwMCENClsgIDE2Ny4yOTA5MjhdIDMxNzA3IGlz
IDI3MTRhMDAwIQ0KWyAgMTY3LjI5MjU2Nl0gMzE3MDYgaXMgMjcxNGIwMDAhDQpbICAxNjcu
Mjk0MjM4XSAzMTcwNSBpcyAyNzE0YzAwMCENClsgIDE2Ny4yOTU4NzZdIDMxNzA0IGlzIDI3
MTRkMDAwIQ0KWyAgMTY3LjI5NzUzM10gMzE3MDMgaXMgMjcxNGUwMDAhDQpbICAxNjcuMjk5
MTkzXSAzMTcwMiBpcyAyNzE0ZjAwMCENClsgIDE2Ny4zMDA4NDddIDMxNzAxIGlzIDI3MTUw
MDAwIQ0KWyAgMTY3LjMwMjUwMl0gMzE3MDAgaXMgMjcxNTEwMDAhDQpbICAxNjcuMzA0MTg2
XSAzMTcxYyBpcyAyNzE1MjAwMCENClsgIDE2Ny4zMDc1NjddIDMxNzM0IGlzIDI3MTEzMDAw
IQ0KWyAgMTY3LjMwOTI5NF0gMzE3MzUgaXMgMjcxMTQwMDAhDQpbICAxNjcuMzExMDQxXSAz
MTczNiBpcyAyNzExNTAwMCENClsgIDE2Ny4zMTI3MzhdIDMxNzM3IGlzIDI3MTE2MDAwIQ0K
WyAgMTY3LjMxNDQ0NF0gMzE3MzggaXMgMjcxMTcwMDAhDQpbICAxNjcuMzE2MTYyXSAzMTcz
OSBpcyAyNzExODAwMCENClsgIDE2Ny4zMTc4NjVdIDMxNzNhIGlzIDI3MTE5MDAwIQ0KWyAg
MTY3LjMxOTU2MV0gMzE3M2IgaXMgMjcxMWEwMDAhDQpbICAxNjcuMzIxMjU3XSAzMTczYyBp
cyAyNzExYjAwMCENClsgIDE2Ny4zMjI5NDhdIDMxNzNkIGlzIDI3MTFjMDAwIQ0KWyAgMTY3
LjMyNDY3Nl0gMzE3MjYgaXMgMjcxMjgwMDAhDQpbICAxNjcuMzI2MzYwXSAzMTcyNSBpcyAy
NzEyOTAwMCENClsgIDE2Ny4zMjgwODddIDMxNzI0IGlzIDI3MTJhMDAwIQ0KWyAgMTY3LjMy
OTc4OF0gMzE3MjMgaXMgMjcxMmIwMDAhDQpbICAxNjcuMzMxNDY3XSAzMTcyMiBpcyAyNzEy
YzAwMCENClsgIDE2Ny4zMzMxNjVdIDMxNzIxIGlzIDI3MTJkMDAwIQ0KWyAgMTY3LjMzNDg1
Ml0gMzE3MjAgaXMgMjcxMmUwMDAhDQpbICAxNjcuMzM2NTM5XSAzMTcxZiBpcyAyNzEyZjAw
MCENClsgIDE2Ny4zMzgyMjFdIDMxNzFlIGlzIDI3MTMwMDAwIQ0KWyAgMTY3LjMzOTg5OV0g
MzE3MWQgaXMgMjcxMzEwMDAhDQpbICAxNjcuMzQxNjIyXSAzMTcxNCBpcyAyNzEzMjAwMCEN
ClsgIDE2Ny4zNDMzMDFdIDMxNzMxIGlzIDI3MTFkMDAwIQ0KWyAgMTY3LjM0NTAzMF0gMzE3
MzAgaXMgMjcxMWUwMDAhDQpbICAxNjcuMzQ2NzM2XSAzMTcyZiBpcyAyNzExZjAwMCENClsg
IDE2Ny4zNDg0NDZdIDMxNzJlIGlzIDI3MTIwMDAwIQ0KWyAgMTY3LjM1MDE0NV0gMzE3MmQg
aXMgMjcxMjEwMDAhDQpbICAxNjcuMzUxODM5XSAzMTcyYyBpcyAyNzEyMjAwMCENClsgIDE2
Ny4zNTM1NjNdIDMxNzJiIGlzIDI3MTIzMDAwIQ0KWyAgMTY3LjM1NTI1M10gMzE3MmEgaXMg
MjcxMjQwMDAhDQpbICAxNjcuMzU2OTU4XSAzMTcyOSBpcyAyNzEyNTAwMCENClsgIDE2Ny4z
NTg2MTldIDMxNzI4IGlzIDI3MTI2MDAwIQ0KWyAgMTY3LjM2MDI4OF0gMzE3MjcgaXMgMjcx
MjcwMDAhDQpbICAxNjcuMzYzMDU4XSAzMTc0OCBpcyAyNzBlODAwMCENClsgIDE2Ny4zNjQ4
NDBdIDMxNzQ3IGlzIDI3MGU5MDAwIQ0KWyAgMTY3LjM2NjUyNV0gMzE3NDYgaXMgMjcwZWEw
MDAhDQpbICAxNjcuMzY4MjE5XSAzMTc0NSBpcyAyNzBlYjAwMCENClsgIDE2Ny4zNjk5MjJd
IDMxNzQ0IGlzIDI3MGVjMDAwIQ0KWyAgMTY3LjM3MTYwMl0gMzE3NDMgaXMgMjcwZWQwMDAh
DQpbICAxNjcuMzczMjg5XSAzMTc0MiBpcyAyNzBlZTAwMCENClsgIDE2Ny4zNzQ5OTVdIDMx
NzQxIGlzIDI3MGVmMDAwIQ0KWyAgMTY3LjM3NjY2OF0gMzE3NDAgaXMgMjcwZjAwMDAhDQpb
ICAxNjcuMzc4MzkwXSAzMTczZiBpcyAyNzBmMTAwMCENClsgIDE2Ny4zODAwODJdIDMxNzNl
IGlzIDI3MGYyMDAwIQ0KWyAgMTY3LjM4MTc4NV0gMzE3NDkgaXMgMjcwZmQwMDAhDQpbICAx
NjcuMzgzNDcyXSAzMTc0YSBpcyAyNzBmZTAwMCENClsgIDE2Ny4zODUxNTZdIDMxNzRiIGlz
IDI3MGZmMDAwIQ0KWyAgMTY3LjM4Njg3N10gMzE3NGMgaXMgMjcxMDAwMDAhDQpbICAxNjcu
Mzg4NTY0XSAzMTc0ZCBpcyAyNzEwMTAwMCENClsgIDE2Ny4zOTAyOTVdIDMxNzRlIGlzIDI3
MTAyMDAwIQ0KWyAgMTY3LjM5MTk4MV0gMzE3NGYgaXMgMjcxMDMwMDAhDQpbICAxNjcuMzkz
NjczXSAzMTc1MCBpcyAyNzEwNDAwMCENClsgIDE2Ny4zOTUzNzRdIDMxNzUxIGlzIDI3MTA1
MDAwIQ0KWyAgMTY3LjM5NzA2MF0gMzE3NTIgaXMgMjcxMDYwMDAhDQpbICAxNjcuMzk4NzM3
XSAzMTc1MyBpcyAyNzEwNzAwMCENClsgIDE2Ny40MDA0MTJdIDMxNzU0IGlzIDI3MGYzMDAw
IQ0KWyAgMTY3LjQwMjA5Nl0gMzE3NTUgaXMgMjcwZjQwMDAhDQpbICAxNjcuNDAzODEwXSAz
MTc1NiBpcyAyNzBmNTAwMCENClsgIDE2Ny40MDU0OTRdIDMxNzU3IGlzIDI3MGY2MDAwIQ0K
WyAgMTY3LjQwNzIwOF0gMzE3NTggaXMgMjcwZjcwMDAhDQpbICAxNjcuNDA4ODkzXSAzMTc1
OSBpcyAyNzBmODAwMCENClsgIDE2Ny40MTA1OTZdIDMxNzVhIGlzIDI3MGY5MDAwIQ0KWyAg
MTY3LjQxMjMwOV0gMzE3NWIgaXMgMjcwZmEwMDAhDQpbICAxNjcuNDE0MDE4XSAzMTc1YyBp
cyAyNzBmYjAwMCENClsgIDE2Ny40MTU3MjNdIDMxNzVkIGlzIDI3MGZjMDAwIQ0KWyAgMTY3
LjQxNzQxNV0gMzE3NWUgaXMgMjcwZGQwMDAhDQpbICAxNjcuNDE5MTEzXSAzMTczMiBpcyAy
NzBkZTAwMCENClsgIDE2Ny40MjA4MTJdIDMxNzMzIGlzIDI3MGRmMDAwIQ0KWyAgMTY3LjQy
MjQ5Nl0gMzE3NzQgaXMgMjcwZTAwMDAhDQpbICAxNjcuNDI0MjIyXSAzMTc3NSBpcyAyNzBl
MTAwMCENClsgIDE2Ny40MjU5MThdIDMxNzc2IGlzIDI3MGUyMDAwIQ0KWyAgMTY3LjQyNzY0
MV0gMzE3NzcgaXMgMjcwZTMwMDAhDQpbICAxNjcuNDI5MzM3XSAzMTc3OCBpcyAyNzBlNDAw
MCENClsgIDE2Ny40MzEwNDJdIDMxNzc5IGlzIDI3MGU1MDAwIQ0KWyAgMTY3LjQzMjc0OF0g
MzE3N2EgaXMgMjcwZTYwMDAhDQpbICAxNjcuNDM0NDM4XSAzMTc3YiBpcyAyNzBlNzAwMCEN
ClsgIDE2Ny40MzYxMjddIDMxNzdjIGlzIDI3MGQzMDAwIQ0KWyAgMTY3LjQzNzgxOV0gMzE3
N2QgaXMgMjcwZDQwMDAhDQpbICAxNjcuNDM5NDk3XSAzMTc3ZSBpcyAyNzBkNTAwMCENClsg
IDE2Ny40NDExOTRdIDMxNzdmIGlzIDI3MGQ2MDAwIQ0KWyAgMTY3LjQ0Mjg2MV0gMzE3ODAg
aXMgMjcwZDcwMDAhDQpbICAxNjcuNDQ0NTU3XSAzMTc4MSBpcyAyNzBkODAwMCENClsgIDE2
Ny40NDYyMjRdIDMxNzgyIGlzIDI3MGQ5MDAwIQ0KWyAgMTY3LjQ0Nzg5OF0gMzE3ODMgaXMg
MjcwZGEwMDAhDQpbICAxNjcuNDQ5NTgyXSAzMTc4NCBpcyAyNzBkYjAwMCENClsgIDE2Ny40
NTEyNjNdIDMxNzg1IGlzIDI3MGRjMDAwIQ0KWyAgMTY3LjQ1NjE4M10gMzE3NWYgaXMgMjcw
YzgwMDAhDQpbICAxNjcuNDU4MDAzXSAzMTc2MCBpcyAyNzBjOTAwMCENClsgIDE2Ny40NTk2
NTldIDMxNzYxIGlzIDI3MGNhMDAwIQ0KWyAgMTY3LjQ2MTM0OV0gMzE3NjIgaXMgMjcwY2Iw
MDAhDQpbICAxNjcuNDYzMDA1XSAzMTc2MyBpcyAyNzBjYzAwMCENClsgIDE2Ny40NjQ2Nzhd
IDMxNzY0IGlzIDI3MGNkMDAwIQ0KWyAgMTY3LjQ2NjM1MF0gMzE3NjUgaXMgMjcwY2UwMDAh
DQpbICAxNjcuNDY4MDE5XSAzMTc2NiBpcyAyNzBjZjAwMCENClsgIDE2Ny40Njk2OTJdIDMx
NzY3IGlzIDI3MGQwMDAwIQ0KWyAgMTY3LjQ3MTM2N10gMzE3NjggaXMgMjcwZDEwMDAhDQpb
ICAxNjcuNDczMDM0XSAzMTc2OSBpcyAyNzBkMjAwMCENClsgIDE2Ny40NzQ3MjZdIDMxNzZh
IGlzIDI3MGJkMDAwIQ0KWyAgMTY3LjQ3NjM5M10gMzE3NmIgaXMgMjcwYmUwMDAhDQpbICAx
NjcuNDc4MDkxXSAzMTc2YyBpcyAyNzBiZjAwMCENClsgIDE2Ny40Nzk3NDBdIDMxNzZkIGlz
IDI3MGMwMDAwIQ0KWyAgMTY3LjQ4MTQyNV0gMzE3NmUgaXMgMjcwYzEwMDAhDQpbICAxNjcu
NDgzMDg2XSAzMTc2ZiBpcyAyNzBjMjAwMCENClsgIDE2Ny40ODQ3NjFdIDMxNzcwIGlzIDI3
MGMzMDAwIQ0KWyAgMTY3LjQ4NjQ0Nl0gMzE3NzEgaXMgMjcwYzQwMDAhDQpbICAxNjcuNDg4
MTIxXSAzMTc5MyBpcyAyNzBjNTAwMCENClsgIDE2Ny40ODk4MDldIDMxNzk0IGlzIDI3MGM2
MDAwIQ0KWyAgMTY3LjQ5MTUwMV0gMzE3OTUgaXMgMjcwYzcwMDAhDQpbICAxNjcuNDkzMTc0
XSAzMTc5NiBpcyAyNzBiMzAwMCENClsgIDE2Ny40OTQ4ODNdIDMxNzk3IGlzIDI3MGI0MDAw
IQ0KWyAgMTY3LjQ5NjU2MV0gMzE3OTggaXMgMjcwYjUwMDAhDQpbICAxNjcuNDk4MjY4XSAz
MTc5OSBpcyAyNzBiNjAwMCENClsgIDE2Ny40OTk5MzVdIDMxNzlhIGlzIDI3MGI3MDAwIQ0K
WyAgMTY3LjUwMTYxN10gMzE3OWIgaXMgMjcwYjgwMDAhDQpbICAxNjcuNTAzMzEyXSAzMTc5
YyBpcyAyNzBiOTAwMCENClsgIDE2Ny41MDQ5OTldIDMxNzlkIGlzIDI3MGJhMDAwIQ0KWyAg
MTY3LjUwNjY4Nl0gMzE3OWUgaXMgMjcwYmIwMDAhDQpbICAxNjcuNTA4MzY3XSAzMTc5ZiBp
cyAyNzBiYzAwMCENClsgIDE2Ny41MTAxNjldIDMxN2EwIGlzIDI3MGFiMDAwIQ0KWyAgMTY3
LjUxMTg5N10gMzE3YTEgaXMgMjcwYWMwMDAhDQpbICAxNjcuNTEzNjA0XSAzMTdhMiBpcyAy
NzBhZDAwMCENClsgIDE2Ny41MTUzMTZdIDMxN2EzIGlzIDI3MGFlMDAwIQ0KWyAgMTY3LjUx
NzAxMF0gMzE3YTQgaXMgMjcwYWYwMDAhDQpbICAxNjcuNTE4Njg5XSAzMTdhNSBpcyAyNzBi
MDAwMCENClsgIDE2Ny41MjA0MTddIDMxN2E2IGlzIDI3MGIxMDAwIQ0KWyAgMTY3LjUyMjEx
N10gMzE3YTcgaXMgMjcwYjIwMDAhDQpbICAxNjcuNTI0Nzk3XSAzMTdiNCBpcyAyNzA5YjAw
MCENClsgIDE2Ny41MjY0NzJdIDMxN2I1WyAgMTY5LjY2MTkyMF0gMzBjM2EgaXMgMjcyM2Yw
MDAhDQpbICAxNjkuNjYzNjYxXSAzMGM2YSBpcyAyNzI0MDAwMCENClsgIDE2OS42NjU0MTVd
IDMwYzZiIGlzIDI3MjQxMDAwIQ0KWyAgMTY5LjY2NzE4NF0gMzBjNmMgaXMgMjcyNDIwMDAh
DQpbICAxNjkuNjY4ODc0XSAzMGM2ZCBpcyAyNzI0MzAwMCENClsgIDE2OS42NzA1ODVdIDMw
YzZlIGlzIDI3MjQ0MDAwIQ0KWyAgMTY5LjY3MjI0M10gMzBjNmYgaXMgMjcyNDUwMDAhDQpb
ICAxNjkuNjczOTg2XSAzMGM3MCBpcyAyNzI0NjAwMCENClsgIDE2OS42NzU2NThdIDMwYzcx
IGlzIDI3MjQ3MDAwIQ0KWyAgMTY5LjY3NzM0OV0gMzBjNzIgaXMgMjcyNDgwMDAhDQpbICAx
NjkuNjc5MDQ0XSAzMGM3MyBpcyAyNzI0OTAwMCENClsgIDE2OS42ODEwOThdIDMwYzdlIGlz
IDI3MjJhMDAwIQ0KWyAgMTY5LjY4Mjc5Ml0gMzBjMzAgaXMgMjcyMmIwMDAhDQpbICAxNjku
Njg0NDcwXSAzMGMzMSBpcyAyNzIyYzAwMCENClsgIDE2OS42ODYxMTldIDMwYzMyIGlzIDI3
MjJkMDAwIQ0KWyAgMTY5LjY4NzgxMF0gMzBjMzMgaXMgMjcyMmUwMDAhDQpbICAxNjkuNjg5
NDU3XSAzMGMzNCBpcyAyNzIyZjAwMCENClsgIDE2OS42OTExMzBdIDMwYzM1IGlzIDI3MjMw
MDAwIQ0KWyAgMTY5LjY5Mjc3NV0gMzBjMzYgaXMgMjcyMzEwMDAhDQpbICAxNjkuNjk0NDMz
XSAzMGMzNyBpcyAyNzIzMjAwMCENClsgIDE2OS42OTYxMDldIDMwYzM4IGlzIDI3MjMzMDAw
IQ0KWyAgMTY5LjY5Nzc3M10gMzBjMzkgaXMgMjcyMzQwMDAhDQpbICAxNjkuNjk5NDUzXSAz
MGM3ZiBpcyAyNzIxZjAwMCENClsgIDE2OS43MDExMThdIDMwYzgwIGlzIDI3MjIwMDAwIQ0K
WyAgMTY5LjcwMjc5MF0gMzBjODEgaXMgMjcyMjEwMDAhDQpbICAxNjkuNzA0NTA4XSAzMGM4
MiBpcyAyNzIyMjAwMCENClsgIDE2OS43MDYxOTNdIDMwYzgzIGlzIDI3MjIzMDAwIQ0KWyAg
MTY5LjcwNzkxNl0gMzBjODQgaXMgMjcyMjQwMDAhDQpbICAxNjkuNzA5NTg5XSAzMGM4NSBp
cyAyNzIyNTAwMCENClsgIDE2OS43MTEzMDddIDMwYzg2IGlzIDI3MjI2MDAwIQ0KWyAgMTY5
LjcxMjk5MV0gMzBjODcgaXMgMjcyMjcwMDAhDQpbICAxNjkuNzE0Njk1XSAzMGM4OCBpcyAy
NzIyODAwMCENClsgIDE2OS43MTYzODhdIDMwYzg5IGlzIDI3MjI5MDAwIQ0KWyAgMTY5Ljcx
ODA2M10gMzBjOGEgaXMgMjcyMTQwMDAhDQpbICAxNjkuNzE5NzU2XSAzMGM3NCBpcyAyNzIz
NTAwMCENClsgIDE2OS43MjE0NDhdIDMwYzc1IGlzIDI3MjM2MDAwIQ0KWyAgMTY5LjcyMzEz
OV0gMzBjNzYgaXMgMjcyMzcwMDAhDQpbICAxNjkuNzI0ODYyXSAzMGM3NyBpcyAyNzIzODAw
MCENClsgIDE2OS43MjY1NDhdIDMwYzc4IGlzIDI3MjM5MDAwIQ0KWyAgMTY5LjcyODI2NV0g
MzBjNzkgaXMgMjcyM2EwMDAhDQpbICAxNjkuNzI5OTQ0XSAzMGM3YSBpcyAyNzIzYjAwMCEN
ClsgIDE2OS43MzE2MzddIDMwYzdiIGlzIDI3MjNjMDAwIQ0KWyAgMTY5LjczMzM1Ml0gMzBj
N2MgaXMgMjcyM2QwMDAhDQpbICAxNjkuNzM1MDUwXSAzMGM3ZCBpcyAyNzIzZTAwMCENClsg
IDE2OS43NTgyNzNdIDMwYzNjIGlzIDI3MjEzMDAwIQ0KWyAgMTY5Ljc4MzIwN10gMzBjM2Qg
aXMgMjcyMTIwMDAhDQpbICAxNjkuNzg1MzUxXSAzMGMzYiBpcyAyNzIxMTAwMCENClsgIDE2
OS43ODc1MDRdIDMwYzk0IGlzIDI3MjEwMDAwIQ0KWyAgMTY5LjgyMzc4NF0gMzBjOTUgaXMg
MjcyMGYwMDAhDQpbICAxNjkuODI1OTM5XSAzMGM5NiBpcyAyNzIwZTAwMCENClsgIDE2OS44
MjgxMjldIDMwYzk3IGlzIDI3MjBkMDAwIQ0KWyAgMTY5LjgzMjE2NF0gMzBjOTggaXMgMjcy
MGMwMDAhDQpbICAxNjkuODM0MzAzXSAzMGM5OSBpcyAyNzIwYjAwMCENClsgIDE2OS44NDU3
MzVdIDMwYzlhIGlzIDI3MjBhMDAwIQ0KWyAgMTY5Ljg2NjQ3MV0gMzBjOWIgaXMgMjcyMDkw
MDAhDQpbICAxNjkuODgxMTk1XSAzNzUyMCBpcyAyNzIwODAwMCENClsgIDE2OS44ODcxNzhd
IDM4MmRlIGlzIDI3MjA3MDAwIQ0KWyAgMTY5Ljg4OTMyOF0gMzBjOWMgaXMgMjcyMDYwMDAh
DQpbICAxNjkuODkxNTEyXSAzMGM5ZCBpcyAyNzIwNTAwMCENClsgIDE2OS45MzUyNTVdIDMw
YzllIGlzIDI3MjA0MDAwIQ0KWyAgMTY5LjkzODU3OF0gMzBjOWYgaXMgMjcxZTAwMDAhDQpb
ICAxNjkuOTQwODg2XSAzNjRmZSBpcyAyNzFlMTAwMCENClsgIDE2OS45NDQ3MDldIDMwY2Fj
IGlzIDI3MWQ5MDAwIQ0KWyAgMTY5Ljk0NjUzNV0gMzBjYWQgaXMgMjcxZGEwMDAhDQpbICAx
NjkuOTQ4MzkwXSAzMGNhZSBpcyAyNzFkYjAwMCENClsgIDE2OS45NTAyMTZdIDMwY2FmIGlz
IDI3MWRjMDAwIQ0KWyAgMTY5Ljk1MjAxM10gMzBjYjAgaXMgMjcxZGYwMDAhDQpbICAxNjku
OTUzODQwXSAzMGNiMSBpcyAyNzQyNTAwMCENClsgIDE2OS45NTU2NDJdIDMwY2IyIGlzIDI3
NDNlMDAwIQ0KWyAgMTY5Ljk1NzQ4MF0gMzBjYjMgaXMgMjcxZmUwMDAhDQpbICAxNjkuOTU5
Mjg4XSAzMGNiNCBpcyAyNzFlNjAwMCENClsgIDE2OS45NjExMzFdIDMwY2I1IGlzIDI3MWU1
MDAwIQ0KWyAgMTY5Ljk2Mjk0NF0gMzBjYjYgaXMgMjcxZmQwMDAhDQpbICAxNjkuOTY0Nzc3
XSAzMGNhMCBpcyAyNzFmMTAwMCENClsgIDE2OS45NjY2MTNdIDM3YTBmIGlzIDI3MWYzMDAw
IQ0KWyAgMTY5Ljk2ODQ3M10gMzBjM2UgaXMgMjcxZjQwMDAhDQpbICAxNjkuOTcwMzQ2XSAz
MGNiZCBpcyAyNzFmNTAwMCENClsgIDE2OS45NzIxOTFdIDMwY2JlIGlzIDI3MWZiMDAwIQ0K
WyAgMTY5Ljk3NDA2OF0gMzBjYmYgaXMgMjcxZmEwMDAhDQpbICAxNjkuOTc1OTA3XSAzMGNj
MCBpcyAyNzFmODAwMCENClsgIDE2OS45Nzc3NzJdIDMwY2MxIGlzIDI3MWY5MDAwIQ0KWyAg
MTY5Ljk3OTYwNV0gMzBjYzIgaXMgMjcxZWEwMDAhDQpbICAxNjkuOTgxNDY0XSAzMGNjMyBp
cyAyNzFlMzAwMCENClsgIDE2OS45ODMzMzFdIDMwY2M0IGlzIDI3MWUyMDAwIQ0KWyAgMTY5
Ljk4NTE5N10gMzBjYTEgaXMgMjcxZWMwMDAhDQpbICAxNjkuOTg3MDc5XSAzMGNhMiBpcyAy
NzFlYjAwMCENClsgIDE2OS45ODg5MjZdIDMwY2EzIGlzIDI3MWY3MDAwIQ0KWyAgMTY5Ljk5
MDc4NF0gMzBjYTQgaXMgMjcxZjYwMDAhDQpbICAxNjkuOTkyNjA2XSAzMGNhNSBpcyAyNzFl
ZjAwMCENClsgIDE2OS45OTQ0NTNdIDMwY2E2IGlzIDI3MWU5MDAwIQ0KWyAgMTY5Ljk5NjI2
NF0gMzBjYTcgaXMgMjcxZTQwMDAhDQpbICAxNjkuOTk4MDc3XSAzMGNhOCBpcyAyNzFmYzAw
MCENClsgIDE2OS45OTk4ODZdIDMwY2E5IGlzIDI3MWYwMDAwIQ0KWyAgMTcwLjAwMTY3MF0g
MzBjYWEgaXMgMjcxZWQwMDAhDQpbICAxNzAuMDAzNDc4XSAzMGNhYiBpcyAyNzFlZTAwMCEN
ClsgIDE3MC4wMDYxMzNdIDMwY2UxIGlzIDI3MWNhMDAwIQ0KWyAgMTcwLjAwODA4NF0gMzBj
ZTIgaXMgMjcxY2IwMDAhDQpbICAxNzAuMDA5ODkzXSAzMGNlMyBpcyAyNzFjYzAwMCENClsg
IDE3MC4wMTE3MjldIDMwY2U0IGlzIDI3MWNkMDAwIQ0KWyAgMTcwLjAxMzUzNl0gMzBjZTAg
aXMgMjZjODkwMDAhDQpbICAxNzAuMDE1MzYyXSAzMGNkZiBpcyAyNzQzMTAwMCENClsgIDE3
MC4wMTcxOTBdIDMwY2RlIGlzIDI3MjAxMDAwIQ0KWyAgMTcwLjAxOTAzOV0gMzBjZGQgaXMg
MjcyMDMwMDAhDQpbICAxNzAuMDIwODY2XSAzMGNkYyBpcyAyNzIwMjAwMCENClsgIDE3MC4w
MjI2ODNdIDMwY2JjIGlzIDI3NDMyMDAwIQ0KWyAgMTcwLjAyNDU0M10gMzBjYmIgaXMgMjcx
YzUwMDAhDQpbICAxNzAuMDI2MzQ5XSAzMGNiYSBpcyAyNzFjNjAwMCENClsgIDE3MC4wMjgx
NzJdIDMwY2I5IGlzIDI3MWM3MDAwIQ0KWyAgMTcwLjAyOTk2NV0gMzBjYjggaXMgMjcxYzgw
MDAhDQpbICAxNzAuMDMxNzY4XSAzMGNiNyBpcyAyNzFjOTAwMCENClsgIDE3MC4wMzUwOThd
IDMwY2NlIGlzIDI3MWE3MDAwIQ0KWyAgMTcwLjAzNjkzOF0gMzBjY2QgaXMgMjcxYTgwMDAh
DQpbICAxNzAuMDM4NzA4XSAzMGNjYyBpcyAyNzFhOTAwMCENClsgIDE3MC4wNDA1MDVdIDMw
Y2NiIGlzIDI3MWFhMDAwIQ0KWyAgMTcwLjA0MjI1OF0gMzBjY2EgaXMgMjcxYWIwMDAhDQpb
ICAxNzAuMDQ0MDM4XSAzMGNjOSBpcyAyNzFhYzAwMCENClsgIDE3MC4wNDU4MDldIDMwY2M4
IGlzIDI3MWFkMDAwIQ0KWyAgMTcwLjA0NzU4OV0gMzBjYzcgaXMgMjcxYWUwMDAhDQpbICAx
NzAuMDQ5MzU1XSAzMGNjNiBpcyAyNzFhZjAwMCENClsgIDE3MC4wNTEwOTBdIDMwY2M1IGlz
IDI3MWIwMDAwIQ0KWyAgMTcwLjA1MjgyOF0gMzBjZTUgaXMgMjcxYjEwMDAhDQpbICAxNzAu
MDU0NTc1XSAzMGNkOSBpcyAyNzE5YzAwMCENClsgIDE3MC4wNTYzMDldIDMwY2Q4IGlzIDI3
MTlkMDAwIQ0KWyAgMTcwLjA1ODA3Ml0gMzBjZDcgaXMgMjcxOWUwMDAhDQpbICAxNzAuMDU5
Nzk5XSAzMGNkNiBpcyAyNzE5ZjAwMCENClsgIDE3MC4wNjE1MzNdIDMwY2Q1IGlzIDI3MWEw
MDAwIQ0KWyAgMTcwLjA2MzI0OF0gMzBjZDQgaXMgMjcxYTEwMDAhDQpbICAxNzAuMDY0OTg4
XSAzMGNkMyBpcyAyNzFhMjAwMCENClsgIDE3MC4wNjY2ODZdIDMwY2QyIGlzIDI3MWEzMDAw
IQ0KWyAgMTcwLjA2ODM5OF0gMzBjZDEgaXMgMjcxYTQwMDAhDQpbICAxNzAuMDcwMTIyXSAz
MGNkMCBpcyAyNzFhNTAwMCENClsgIDE3MC4wNzE3OTRdIDMwY2NmIGlzIDI3MWE2MDAwIQ0K
WyAgMTcwLjA3NDM0Nl0gMzBjZTYgaXMgMjcxOTIwMDAhDQpbICAxNzAuMDc2MTQ1XSAzMGNl
NyBpcyAyNzE5MzAwMCENClsgIDE3MC4wNzc4NzhdIDMwY2U4IGlzIDI3MTk0MDAwIQ0KWyAg
MTcwLjA3OTU0Ml0gMzBjZTkgaXMgMjcxOTUwMDAhDQpbICAxNzAuMDgxMjEzXSAzMGNlYSBp
cyAyNzE5NjAwMCENClsgIDE3MC4wODI4OTZdIDMwY2ViIGlzIDI3MTk3MDAwIQ0KWyAgMTcw
LjA4NDU3N10gMzBjZWMgaXMgMjcxOTgwMDAhDQpbICAxNzAuMDg2MjY0XSAzMGNlZCBpcyAy
NzE5OTAwMCENClsgIDE3MC4wODc5MzZdIDMwY2VlIGlzIDI3MTlhMDAwIQ0KWyAgMTcwLjA4
OTYwOV0gMzBjZWYgaXMgMjcxOWIwMDAhDQpbICAxNzAuMDkyOTg5XSAzMGQwOCBpcyAyNzkz
MjAwMCENClsgIDE3MC4wOTQ3NDFdIDMwZDA5IGlzIDI3OTMzMDAwIQ0KWyAgMTcwLjA5NjQy
M10gMzBkMGEgaXMgMjc5MzQwMDAhDQpbICAxNzAuMDk4MTQwXSAzMGQwYiBpcyAyNzkzNTAw
MCENClsgIDE3MC4wOTk4MjFdIDMwZDBjIGlzIDI3OTM2MDAwIQ0KWyAgMTcwLjEwMTUzMl0g
MzBkMGQgaXMgMjc5MzcwMDAhDQpbICAxNzAuMTAzMjQ4XSAzMGQwZSBpcyAyNzkzODAwMCEN
ClsgIDE3MC4xMDQ5NzRdIDMwZDBmIGlzIDI3OTM5MDAwIQ0KWyAgMTcwLjEwNjY5NV0gMzBk
MTAgaXMgMjc5M2EwMDAhDQpbICAxNzAuMTA4NDEzXSAzMGQxMSBpcyAyNzkzYjAwMCENClsg
IDE3MC4xMTAxMzJdIDMwY2YwIGlzIDI3OTQ3MDAwIQ0KWyAgMTcwLjExMTg1NV0gMzBjZjEg
aXMgMjc5NDgwMDAhDQpbICAxNzAuMTEzNTc2XSAzMGNmMiBpcyAyNzk0OTAwMCENClsgIDE3
MC4xMTUzMDFdIDMwY2YzIGlzIDI3OTRhMDAwIQ0KWyAgMTcwLjExNzAyMl0gMzBjZjQgaXMg
Mjc5NGIwMDAhDQpbICAxNzAuMTE4NzE4XSAzMGNmNSBpcyAyNzk0YzAwMCENClsgIDE3MC4x
MjA0NDRdIDMwY2Y2IGlzIDI3OTRkMDAwIQ0KWyAgMTcwLjEyMjE1M10gMzBjZjcgaXMgMjc5
NGUwMDAhDQpbICAxNzAuMTIzODk2XSAzMGNmOCBpcyAyNzk0ZjAwMCENClsgIDE3MC4xMjU2
MTBdIDMwY2Y5IGlzIDI3OTUwMDAwIQ0KWyAgMTcwLjEyNzM1MV0gMzBjZmEgaXMgMjc5NTEw
MDAhDQpbICAxNzAuMTI5MDYwXSAzMGNmYiBpcyAyNzkzYzAwMCENClsgIDE3MC4xMzA3NzVd
IDMwY2ZlIGlzIDI3OTNkMDAwIQ0KWyAgMTcwLjEzMjUwNV0gMzBjZmYgaXMgMjc5M2UwMDAh
DQpbICAxNzAuMTM0MjI3XSAzMGQwMCBpcyAyNzkzZjAwMCENClsgIDE3MC4xMzU5NjFdIDMw
ZDAxIGlzIDI3OTQwMDAwIQ0KWyAgMTcwLjEzNzY5NV0gMzBkMDIgaXMgMjc5NDEwMDAhDQpb
ICAxNzAuMTM5NDEzXSAzMGQwMyBpcyAyNzk0MjAwMCENClsgIDE3MC4xNDExNjRdIDMwZDA0
IGlzIDI3OTQzMDAwIQ0KWyAgMTcwLjE0Mjg4OV0gMzBkMDUgaXMgMjc5NDQwMDAhDQpbICAx
NzAuMTQ0NjQ1XSAzMGQwNiBpcyAyNzk0NTAwMCENClsgIDE3MC4xNDYzNjldIDMwZDA3IGlz
IDI3OTQ2MDAwIQ0KWyAgMTcwLjE0OTMxMV0gMzBkMzIgaXMgMjc4ZmMwMDAhDQpbICAxNzAu
MTUxMTI4XSAzMGNkYSBpcyAyNzhmZDAwMCENClsgIDE3MC4xNTI5MTRdIDMwY2RiIGlzIDI3
OGZlMDAwIQ0KWyAgMTcwLjE1NDY3OV0gMzBkM2IgaXMgMjc4ZmYwMDAhDQpbICAxNzAuMTU2
NDUzXSAzMGQzYyBpcyAyNzkwMDAwMCENClsgIDE3MC4xNTgyMTZdIDMwZDNkIGlzIDI3OTAx
MDAwIQ0KWyAgMTcwLjE1OTk2NF0gMzBkM2UgaXMgMjc5MDIwMDAhDQpbICAxNzAuMTYxNzQ4
XSAzMGQzZiBpcyAyNzkwMzAwMCENClsgIDE3MC4xNjM1MTVdIDMwZDQwIGlzIDI3OTA0MDAw
IQ0KWyAgMTcwLjE2NTMwNF0gMzBkNDEgaXMgMjc5MDUwMDAhDQpbICAxNzAuMTY3MDQ0XSAz
MGQ0MiBpcyAyNzkwNjAwMCENClsgIDE3MC4xNjg4MTNdIDMwZDEyIGlzIDI3OTI3MDAwIQ0K
WyAgMTcwLjE3MDU0N10gMzBkMTMgaXMgMjc5MjgwMDAhDQpbICAxNzAuMTcyMjcxXSAzMGQx
NCBpcyAyNzkyOTAwMCENClsgIDE3MC4xNzQwMzRdIDMwZDE1IGlzIDI3OTJhMDAwIQ0KWyAg
MTcwLjE3NTc1OV0gMzBkMTYgaXMgMjc5MmIwMDAhDQpbICAxNzAuMTc3NTE3XSAzMGQxNyBp
cyAyNzkyYzAwMCENClsgIDE3MC4xNzkyMzddIDMwZDE4IGlzIDI3OTJkMDAwIQ0KWyAgMTcw
LjE4MDk2NF0gMzBkMTkgaXMgMjc5MmUwMDAhDQpbICAxNzAuMTgyNzAyXSAzMGQxYSBpcyAy
NzkyZjAwMCENClsgIDE3MC4xODQ0MjhdIDMwZDFiIGlzIDI3OTMwMDAwIQ0KWyAgMTcwLjE4
NjE2Nl0gMzBkMWMgaXMgMjc5MzEwMDAhDQpbICAxNzAuMTg3ODg3XSAzMGQyOCBpcyAyNzkx
MjAwMCENClsgIDE3MC4xODk2MzldIDMwZDI5IGlzIDI3OTEzMDAwIQ0KWyAgMTcwLjE5MTM2
NV0gMzBkMmEgaXMgMjc5MTQwMDAhDQpbICAxNzAuMTkzMDc4XSAzMGQyYiBpcyAyNzkxNTAw
MCENClsgIDE3MC4xOTQ4MjldIDMwZDJjIGlzIDI3OTE2MDAwIQ0KWyAgMTcwLjE5NjU0Ml0g
MzBkMmQgaXMgMjc5MTcwMDAhDQpbICAxNzAuMTk4Mjg4XSAzMGQyZSBpcyAyNzkxODAwMCEN
ClsgIDE3MC4xOTk5OTZdIDMwZDJmIGlzIDI3OTE5MDAwIQ0KWyAgMTcwLjIwMTcxN10gMzBk
MzAgaXMgMjc5MWEwMDAhDQpbICAxNzAuMjAzNDgwXSAzMGQzMSBpcyAyNzkxYjAwMCENClsg
IDE3MC4yMDUxOTRdIDMwZDI3IGlzIDI3OTA3MDAwIQ0KWyAgMTcwLjIwNjkzOF0gMzBkMjYg
aXMgMjc5MDgwMDAhDQpbICAxNzAuMjA4NjQ3XSAzMGQyNSBpcyAyNzkwOTAwMCENClsgIDE3
MC4yMTAzODddIDMwZDI0IGlzIDI3OTBhMDAwIQ0KWyAgMTcwLjIxMjA3N10gMzBkMjMgaXMg
Mjc5MGIwMDAhDQpbICAxNzAuMjEzNzc1XSAzMGQyMiBpcyAyNzkwYzAwMCENClsgIDE3MC4y
MTU0NzhdIDMwZDIxIGlzIDI3OTBkMDAwIQ0KWyAgMTcwLjIxNzE1OF0gMzBkMjAgaXMgMjc5
MGUwMDAhDQpbICAxNzAuMjE4ODM5XSAzMGQxZiBpcyAyNzkwZjAwMCENClsgIDE3MC4yMjA1
MTRdIDMwZDFlIGlzIDI3OTEwMDAwIQ0KWyAgMTcwLjIyMjE5Ml0gMzBkMWQgaXMgMjc5MTEw
MDAhDQpbICAxNzAuMjI1NDUzXSAzMGQ0ZCBpcyAyNzhlNzAwMCENClsgIDE3MC4yMjcyMDld
IDMwZDRjIGlzIDI3OGU4MDAwIQ0KWyAgMTcwLjIyODkyMV0gMzBkNGIgaXMgMjc4ZTkwMDAh
DQpbICAxNzAuMjMwNjQ2XSAzMGQ0YSBpcyAyNzhlYTAwMCENClsgIDE3MC4yMzIzNzddIDMw
ZDQ5IGlzIDI3OGViMDAwIQ0KWyAgMTcwLjIzNDA5MF0gMzBkNDggaXMgMjc4ZWMwMDAhDQpb
ICAxNzAuMjM1ODE5XSAzMGQ0NyBpcyAyNzhlZDAwMCENClsgIDE3MC4yMzc1MzBdIDMwZDQ2
IGlzIDI3OGVlMDAwIQ0KWyAgMTcwLjIzOTIyNl0gMzBkNDUgaXMgMjc4ZWYwMDAhDQpbICAx
NzAuMjQwOTYwXSAzMGQ0NCBpcyAyNzhmMDAwMCENClsgIDE3MC4yNDI2NjJdIDMwZDQzIGlz
IDI3OGYxMDAwIQ0KWyAgMTcwLjI0NDM4Ml0gMzBkMzMgaXMgMjc4ZGMwMDAhDQpbICAxNzAu
MjQ2MDY4XSAzMGQzNCBpcyAyNzhkZDAwMCENClsgIDE3MC4yNDc3NTZdIDMwZDM1IGlzIDI3
OGRlMDAwIQ0KWyAgMTcwLjI0OTQ2NV0gMzBkMzYgaXMgMjc4ZGYwMDAhDQpbICAxNzAuMjUx
MTQ2XSAzMGQzNyBpcyAyNzhlMDAwMCENClsgIDE3MC4yNTI4NDFdIDMwZDM4IGlzIDI3OGUx
MDAwIQ0KWyAgMTcwLjI1NDUyOV0gMzBkMzkgaXMgMjc4ZTIwMDAhDQpbICAxNzAuMjU2MjE3
XSAzMGQzYSBpcyAyNzhlMzAwMCENClsgIDE3MC4yNTc4ODddIDMwZDVhIGlzIDI3OGU0MDAw
IQ0KWyAgMTcwLjI1OTUzNl0gMzBkNWIgaXMgMjc4ZTUwMDAhDQpbICAxNzAuMjYxMjA1XSAz
MGQ1YyBpcyAyNzhlNjAwMCENClsgIDE3MC4yNjMyNjldIDMwZDY3IGlzIDI3OGM3MDAwIQ0K
WyAgMTcwLjI2NTAwMF0gMzBkNjggaXMgMjc4YzgwMDAhDQpbICAxNzAuMjY2NjYyXSAzMGQ2
OSBpcyAyNzhjOTAwMCENClsgIDE3MC4yNjgzNDFdIDMwZDZhIGlzIDI3OGNhMDAwIQ0KWyAg
MTcwLjI3MDA2M10gMzBkNmIgaXMgMjc4Y2IwMDAhDQpbICAxNzAuMjcxNzk4XSAzMGQ2YyBp
cyAyNzhjYzAwMCENClsgIDE3MC4yNzM1MzRdIDMwZDZkIGlzIDI3OGNkMDAwIQ0KWyAgMTcw
LjI3NTIyN10gMzBkNmUgaXMgMjc4Y2UwMDAhDQpbICAxNzAuMjc2OTM3XSAzMGQ2ZiBpcyAy
NzhjZjAwMCENClsgIDE3MC4yNzg2MDZdIDMwZDcwIGlzIDI3OGQwMDAwIQ0KWyAgMTcwLjI4
MDI4M10gMzBkNzEgaXMgMjc4ZDEwMDAhDQpbICAxNzAuMjgxOTgyXSAzMGQ3MiBpcyAyNzhi
YzAwMCENClsgIDE3MC4yODM2NzNdIDMwZDczIGlzIDI3OGJkMDAwIQ0KWyAgMTcwLjI4NTM3
NF0gMzBkNzQgaXMgMjc4YmUwMDAhDQpbICAxNzAuMjg3MDQ1XSAzMGQ3NSBpcyAyNzhiZjAw
MCENClsgIDE3MC4yODg3MTFdIDMwZDc2IGlzIDI3OGMwMDAwIQ0KWyAgMTcwLjI5MDQyMl0g
MzBkNzcgaXMgMjc4YzEwMDAhDQpbICAxNzAuMjkyMDgzXSAzMGQ3OCBpcyAyNzhjMjAwMCEN
ClsgIDE3MC4yOTM3ODRdIDMwZDc5IGlzIDI3OGMzMDAwIQ0KWyAgMTcwLjI5NTQyN10gMzBk
N2EgaXMgMjc4YzQwMDAhDQpbICAxNzAuMjk3MDkwXSAzMGQ3YiBpcyAyNzhjNTAwMCENClsg
IDE3MC4yOTg3NjZdIDMwZDdjIGlzIDI3OGM2MDAwIQ0KWyAgMTcwLjMwMDQzMF0gMzBkN2Qg
aXMgMjc4YjIwMDAhDQpbICAxNzAuMzAyMTIxXSAzMGQ3ZSBpcyAyNzhiMzAwMCENClsgIDE3
MC4zMDM4MDNdIDMwZDdmIGlzIDI3OGI0MDAwIQ0KWyAgMTcwLjMwNTQ1OF0gMzBkODAgaXMg
Mjc4YjUwMDAhDQpbICAxNzAuMzA3MTYzXSAzMGQ4MSBpcyAyNzhiNjAwMCENClsgIDE3MC4z
MDg4MzJdIDMwZDgyIGlzIDI3OGI3MDAwIQ0KWyAgMTcwLjMxMDUzN10gMzBkODMgaXMgMjc4
YjgwMDAhDQpbICAxNzAuMzEyMjEwXSAzMGQ4NCBpcyAyNzhiOTAwMCENClsgIDE3MC4zMTM4
OTddIDMwZDg1IGlzIDI3OGJhMDAwIQ0KWyAgMTcwLjMxNTU4OF0gMzBkODYgaXMgMjc4YmIw
MDAhDQpbICAxNzAuMzE3MjY0XSAzMGQ1ZCBpcyAyNzhkMjAwMCENClsgIDE3MC4zMTg5NjJd
IDMwZDVlIGlzIDI3OGQzMDAwIQ0KWyAgMTcwLjMyMDY0M10gMzBkNWYgaXMgMjc4ZDQwMDAh
DQpbICAxNzAuMzIyMzE2XSAzMGQ2MCBpcyAyNzhkNTAwMCENClsgIDE3MC4zMjQwMjldIDMw
ZDYxIGlzIDI3OGQ2MDAwIQ0KWyAgMTcwLjMyNTcwMV0gMzBkNjIgaXMgMjc4ZDcwMDAhDQpb
ICAxNzAuMzI3NDEzXSAzMGQ2MyBpcyAyNzhkODAwMCENClsgIDE3MC4zMjkwODhdIDMwZDY0
IGlzIDI3OGQ5MDAwIQ0KWyAgMTcwLjMzMDc3OV0gMzBkNjUgaXMgMjc4ZGEwMDAhDQpbICAx
NzAuMzMyNDc3XSAzMGQ2NiBpcyAyNzhkYjAwMCENClsgIDE3MC4zMzU3NTRdIDMwZDlkIGlz
IDI3ODkyMDAwIQ0KWyAgMTcwLjMzNzUwMV0gMzBkOWUgaXMgMjc4OTMwMDAhDQpbICAxNzAu
MzM5MTk2XSAzMGQ5ZiBpcyAyNzg5NDAwMCENClsgIDE3MC4zNDA5MjldIDMwZGEwIGlzIDI3
ODk1MDAwIQ0KWyAgMTcwLjM0MjYzMl0gMzBkYTEgaXMgMjc4OTYwMDAhDQpbICAxNzAuMzQ0
MzY0XSAzMGRhMiBpcyAyNzg5NzAwMCENClsgIDE3MC4zNDYwNjNdIDMwZGEzIGlzIDI3ODk4
MDAwIQ0KWyAgMTcwLjM0Nzc3OF0gMzBkYTQgaXMgMjc4OTkwMDAhDQpbICAxNzAuMzQ5NDg0
XSAzMGRhNSBpcyAyNzg5YTAwMCENClsgIDE3MC4zNTExODVdIDMwZGE2IGlzIDI3ODliMDAw
IQ0KWyAgMTcwLjM1Mjg4M10gMzBkOTIgaXMgMjc4OWMwMDAhDQpbICAxNzAuMzU0NTgzXSAz
MGQ5MyBpcyAyNzg5ZDAwMCENClsgIDE3MC4zNTYyNTFdIDMwZDk0IGlzIDI3ODllMDAwIQ0K
WyAgMTcwLjM1NzkyMl0gMzBkOTUgaXMgMjc4OWYwMDAhDQpbICAxNzAuMzU5NTc1XSAzMGQ5
NiBpcyAyNzhhMDAwMCENClsgIDE3MC4zNjEyNjNdIDMwZDk3IGlzIDI3OGExMDAwIQ0KWyAg
MTcwLjM2MjkyMV0gMzBkOTggaXMgMjc4YTIwMDAhDQpbICAxNzAuMzY0NjE0XSAzMGQ5OSBp
cyAyNzhhMzAwMCENClsgIDE3MC4zNjYyNzNdIDMwZDlhIGlzIDI3OGE0MDAwIQ0KWyAgMTcw
LjM2Nzk1MF0gMzBkOWIgaXMgMjc4YTUwMDAhDQpbICAxNzAuMzY5NjMwXSAzMGQ5YyBpcyAy
NzhhNjAwMCENClsgIDE3MC4zNzI0ODNdIDMwZGJlIGlzIDI3ODVjMDAwIQ0KWyAgMTcwLjM3
NDI4MF0gMzBkNGUgaXMgMjc4NWQwMDAhDQpbICAxNzAuMzc1OTY2XSAzWyAgMTcyLjUwNTEw
NF0gMzA1ZTMgaXMgMjdiYjIwMDAhDQpbICAxNzIuNTA2Nzk1XSAzMDVlNCBpcyAyN2JiMzAw
MCENClsgIDE3Mi41MDg1MThdIDMwNWU1IGlzIDI3YmI0MDAwIQ0KWyAgMTcyLjUxMDI3Ml0g
MzA1ZTYgaXMgMjdiYjUwMDAhDQpbICAxNzIuNTExOTU3XSAzMDVlNyBpcyAyN2JiNjAwMCEN
ClsgIDE3Mi41MTM2NDFdIDMwNWU4IGlzIDI3YmI3MDAwIQ0KWyAgMTcyLjUxNTMxN10gMzA1
ZTkgaXMgMjdiYjgwMDAhDQpbICAxNzIuNTE2OTk3XSAzMDVlYSBpcyAyN2JiOTAwMCENClsg
IDE3Mi41MTg2NTNdIDMwNWViIGlzIDI3YmJhMDAwIQ0KWyAgMTcyLjUyMDY3Ml0gMzA1ZjYg
aXMgMjdiOTAwMDAhDQpbICAxNzIuNTIyMzQwXSAzMDVmNyBpcyAyN2I5MTAwMCENClsgIDE3
Mi41MjQwMzRdIDMwNWY4IGlzIDI3YjkyMDAwIQ0KWyAgMTcyLjUyNTY4NF0gMzA1ZjkgaXMg
MjdiOTMwMDAhDQpbICAxNzIuNTI3MzQ0XSAzMDVmYSBpcyAyN2I5NDAwMCENClsgIDE3Mi41
MjkwMjNdIDMwNWZiIGlzIDI3Yjk1MDAwIQ0KWyAgMTcyLjUzMDY4NV0gMzA1ZmMgaXMgMjdi
OTYwMDAhDQpbICAxNzIuNTMyMzU4XSAzMDVmZCBpcyAyN2I5NzAwMCENClsgIDE3Mi41MzQw
MjddIDMwNWZlIGlzIDI3Yjk4MDAwIQ0KWyAgMTcyLjUzNTY3Nl0gMzA1ZmYgaXMgMjdiOTkw
MDAhDQpbICAxNzIuNTM3MzU1XSAzMDYwMCBpcyAyN2I5YTAwMCENClsgIDE3Mi41MzkwMTBd
IDMwNjAxIGlzIDI3Yjg2MDAwIQ0KWyAgMTcyLjU0MDcwMF0gMzA2MDIgaXMgMjdiODcwMDAh
DQpbICAxNzIuNTQyMzYwXSAzMDYwMyBpcyAyN2I4ODAwMCENClsgIDE3Mi41NDQwMzBdIDMw
NjA0IGlzIDI3Yjg5MDAwIQ0KWyAgMTcyLjU0NTY4OV0gMzA2MDUgaXMgMjdiOGEwMDAhDQpb
ICAxNzIuNTQ3MzQ1XSAzMDYwNiBpcyAyN2I4YjAwMCENClsgIDE3Mi41NDkwMDVdIDMwNjA3
IGlzIDI3YjhjMDAwIQ0KWyAgMTcyLjU1MDY1Nl0gMzA2MDggaXMgMjdiOGQwMDAhDQpbICAx
NzIuNTUyMzA1XSAzMDYwOSBpcyAyN2I4ZTAwMCENClsgIDE3Mi41NTM5ODRdIDMwNjBhIGlz
IDI3YjhmMDAwIQ0KWyAgMTcyLjU1NTYxNl0gMzA1ZTAgaXMgMjdiOWIwMDAhDQpbICAxNzIu
NTU3Mjk1XSAzMDVkZiBpcyAyN2I5YzAwMCENClsgIDE3Mi41NTg5NDldIDMwNWRlIGlzIDI3
YjlkMDAwIQ0KWyAgMTcyLjU2MDYxN10gMzA1ZGQgaXMgMjdiOWUwMDAhDQpbICAxNzIuNTYy
Mjk1XSAzMDVkYyBpcyAyN2I5ZjAwMCENClsgIDE3Mi41NjM5NjRdIDMwNWRiIGlzIDI3YmEw
MDAwIQ0KWyAgMTcyLjU2NTY0MV0gMzA1ZGEgaXMgMjdiYTEwMDAhDQpbICAxNzIuNTY3MzE0
XSAzMDVkOSBpcyAyN2JhMjAwMCENClsgIDE3Mi41Njg5NzZdIDMwNWQ4IGlzIDI3YmEzMDAw
IQ0KWyAgMTcyLjU3MDY3Ml0gMzA1ZDcgaXMgMjdiYTQwMDAhDQpbICAxNzIuNTcyMzM4XSAz
MDVkNiBpcyAyN2JhNTAwMCENClsgIDE3Mi41NzQwMjVdIDMwNWVjIGlzIDI3YmE2MDAwIQ0K
WyAgMTcyLjU3NTY4NV0gMzA1ZWQgaXMgMjdiYTcwMDAhDQpbICAxNzIuNTc3MzUzXSAzMDVl
ZSBpcyAyN2JhODAwMCENClsgIDE3Mi41NzkwMzBdIDMwNWVmIGlzIDI3YmE5MDAwIQ0KWyAg
MTcyLjU4MDcxMl0gMzA1ZjAgaXMgMjdiYWEwMDAhDQpbICAxNzIuNTgyNDA3XSAzMDVmMSBp
cyAyN2JhYjAwMCENClsgIDE3Mi41ODQwOTNdIDMwNWYyIGlzIDI3YmFjMDAwIQ0KWyAgMTcy
LjU4NTc4MF0gMzA1ZjMgaXMgMjdiYWQwMDAhDQpbICAxNzIuNTg3NDY1XSAzMDVmNCBpcyAy
N2JhZTAwMCENClsgIDE3Mi41ODkxMzhdIDMwNWY1IGlzIDI3YmFmMDAwIQ0KWyAgMTcyLjU5
MjAxM10gMzA1OTkgaXMgMjdiNzAwMDAhDQpbICAxNzIuNTkzNzI1XSAzMDU5YSBpcyAyN2I3
MTAwMCENClsgIDE3Mi41OTU0MTRdIDMwNTliIGlzIDI3YjcyMDAwIQ0KWyAgMTcyLjU5NzEx
M10gMzA1OWMgaXMgMjdiNzMwMDAhDQpbICAxNzIuNTk4ODA4XSAzMDU5ZCBpcyAyN2I3NDAw
MCENClsgIDE3Mi42MDA1MDBdIDMwNTllIGlzIDI3Yjc1MDAwIQ0KWyAgMTcyLjYwMjE4M10g
MzA1OWYgaXMgMjdiNzYwMDAhDQpbICAxNzIuNjAzOTAzXSAzMDVhMCBpcyAyN2I3NzAwMCEN
ClsgIDE3Mi42MDU1ODddIDMwNWExIGlzIDI3Yjc4MDAwIQ0KWyAgMTcyLjYwNzMwMl0gMzA1
YTIgaXMgMjdiNzkwMDAhDQpbICAxNzIuNjA4OTk5XSAzMDVhMyBpcyAyN2I3YTAwMCENClsg
IDE3Mi42MTA2OTldIDMwNjBjIGlzIDI3YjdiMDAwIQ0KWyAgMTcyLjYxMjM2NV0gMzA2MGIg
aXMgMjdiN2MwMDAhDQpbICAxNzIuNjE0MDQ2XSAzMDU5MCBpcyAyN2I3ZDAwMCENClsgIDE3
Mi42MTU3MzVdIDMwNTkxIGlzIDI3YjdlMDAwIQ0KWyAgMTcyLjYxNzQyM10gMzA1OTIgaXMg
MjdiN2YwMDAhDQpbICAxNzIuNjE5MTA0XSAzMDU5MyBpcyAyN2I4MDAwMCENClsgIDE3Mi42
MjA3OTBdIDMwNTk0IGlzIDI3YjgxMDAwIQ0KWyAgMTcyLjYyMjQ2OV0gMzA1OTUgaXMgMjdi
ODIwMDAhDQpbICAxNzIuNjI0MTc3XSAzMDU5NiBpcyAyN2I4MzAwMCENClsgIDE3Mi42MjU4
NTVdIDMwNTk3IGlzIDI3Yjg0MDAwIQ0KWyAgMTcyLjYyNzU2Ml0gMzA1OTggaXMgMjdiODUw
MDAhDQpbICAxNzIuNjI5NjYzXSAzMDYzNSBpcyAyN2I1MDAwMCENClsgIDE3Mi42MzE0Mjhd
IDMwNjM2IGlzIDI3YjUxMDAwIQ0KWyAgMTcyLjYzMzE1N10gMzA2MzcgaXMgMjdiNTIwMDAh
DQpbICAxNzIuNjM0ODgzXSAzMDYzOCBpcyAyN2I1MzAwMCENClsgIDE3Mi42MzY1OTVdIDMw
NjM5IGlzIDI3YjU0MDAwIQ0KWyAgMTcyLjYzODMxMF0gMzA2M2EgaXMgMjdiNTUwMDAhDQpb
ICAxNzIuNjQwMDIxXSAzMDYzYiBpcyAyN2I1NjAwMCENClsgIDE3Mi42NDE3MzNdIDMwNjNj
IGlzIDI3YjU3MDAwIQ0KWyAgMTcyLjY0MzQ1Nl0gMzA2M2QgaXMgMjdiNTgwMDAhDQpbICAx
NzIuNjQ1MTgzXSAzMDYzZSBpcyAyN2I1OTAwMCENClsgIDE3Mi42NDY4ODZdIDMwNjNmIGlz
IDI3YjVhMDAwIQ0KWyAgMTcyLjY0ODU4MF0gMzA2MmEgaXMgMjdiNWIwMDAhDQpbICAxNzIu
NjUwMjgwXSAzMDYyYiBpcyAyN2I1YzAwMCENClsgIDE3Mi42NTE5NDddIDMwNjJjIGlzIDI3
YjVkMDAwIQ0KWyAgMTcyLjY1MzY0Nl0gMzA2MmQgaXMgMjdiNWUwMDAhDQpbICAxNzIuNjU1
MzAxXSAzMDYyZSBpcyAyN2I1ZjAwMCENClsgIDE3Mi42NTY5ODddIDMwNjJmIGlzIDI3YjYw
MDAwIQ0KWyAgMTcyLjY1ODY0OF0gMzA2MzAgaXMgMjdiNjEwMDAhDQpbICAxNzIuNjYwMzMw
XSAzMDYzMSBpcyAyN2I2MjAwMCENClsgIDE3Mi42NjIwMjBdIDMwNjMyIGlzIDI3YjYzMDAw
IQ0KWyAgMTcyLjY2MzcwMl0gMzA2MzMgaXMgMjdiNjQwMDAhDQpbICAxNzIuNjY1Mzc5XSAz
MDYzNCBpcyAyN2I2NTAwMCENClsgIDE3Mi42NjcwNTVdIDMwNjQwIGlzIDI3YjQ2MDAwIQ0K
WyAgMTcyLjY2ODcxN10gMzA2NDEgaXMgMjdiNDcwMDAhDQpbICAxNzIuNjcwNDA4XSAzMDY0
NCBpcyAyN2I0ODAwMCENClsgIDE3Mi42NzIwNzVdIDMwNjQ1IGlzIDI3YjQ5MDAwIQ0KWyAg
MTcyLjY3Mzc2N10gMzA2NDYgaXMgMjdiNGEwMDAhDQpbICAxNzIuNjc1NDIzXSAzMDY0NyBp
cyAyN2I0YjAwMCENClsgIDE3Mi42NzcwOTNdIDMwNjQ4IGlzIDI3YjRjMDAwIQ0KWyAgMTcy
LjY3ODc1OV0gMzA2NDkgaXMgMjdiNGQwMDAhDQpbICAxNzIuNjgwNDIzXSAzMDY0YSBpcyAy
N2I0ZTAwMCENClsgIDE3Mi42ODIwOTRdIDMwNjRiIGlzIDI3YjRmMDAwIQ0KWyAgMTcyLjY4
Mzc1NF0gMzA1YTQgaXMgMjdiNjYwMDAhDQpbICAxNzIuNjg1NDA0XSAzMDVhNSBpcyAyN2I2
NzAwMCENClsgIDE3Mi42ODcwNzldIDMwNWE2IGlzIDI3YjY4MDAwIQ0KWyAgMTcyLjY4ODcy
M10gMzA2MjMgaXMgMjdiNjkwMDAhDQpbICAxNzIuNjkwNDA5XSAzMDYyNCBpcyAyN2I2YTAw
MCENClsgIDE3Mi42OTIwNzBdIDMwNjI1IGlzIDI3YjZiMDAwIQ0KWyAgMTcyLjY5Mzc0MV0g
MzA2MjYgaXMgMjdiNmMwMDAhDQpbICAxNzIuNjk1NDEzXSAzMDYyNyBpcyAyN2I2ZDAwMCEN
ClsgIDE3Mi42OTcwODJdIDMwNjI4IGlzIDI3YjZlMDAwIQ0KWyAgMTcyLjY5ODc1NF0gMzA2
MjkgaXMgMjdiNmYwMDAhDQpbICAxNzIuNzAyMDIxXSAzMDY2MiBpcyAyN2IyNjAwMCENClsg
IDE3Mi43MDM4MTFdIDMwNjYzIGlzIDI3YjI3MDAwIQ0KWyAgMTcyLjcwNTUwOV0gMzA2NjQg
aXMgMjdiMjgwMDAhDQpbICAxNzIuNzA3MjQ3XSAzMDY2NSBpcyAyN2IyOTAwMCENClsgIDE3
Mi43MDg5NjJdIDMwNjY2IGlzIDI3YjJhMDAwIQ0KWyAgMTcyLjcxMDcwNl0gMzA2NjcgaXMg
MjdiMmIwMDAhDQpbICAxNzIuNzEyNDA5XSAzMDY2OCBpcyAyN2IyYzAwMCENClsgIDE3Mi43
MTQxMTddIDMwNjY5IGlzIDI3YjJkMDAwIQ0KWyAgMTcyLjcxNTgyN10gMzA2NmEgaXMgMjdi
MmUwMDAhDQpbICAxNzIuNzE3NTIzXSAzMDY2YiBpcyAyN2IyZjAwMCENClsgIDE3Mi43MTky
MjddIDMwNjRjIGlzIDI3YjNiMDAwIQ0KWyAgMTcyLjcyMDkzMF0gMzA2NGQgaXMgMjdiM2Mw
MDAhDQpbICAxNzIuNzIyNjA4XSAzMDY0ZSBpcyAyN2IzZDAwMCENClsgIDE3Mi43MjQzNDBd
IDMwNjRmIGlzIDI3YjNlMDAwIQ0KWyAgMTcyLjcyNjAxM10gMzA2NTAgaXMgMjdiM2YwMDAh
DQpbICAxNzIuNzI3NzI4XSAzMDY1MSBpcyAyN2I0MDAwMCENClsgIDE3Mi43Mjk0MjddIDMw
NjUyIGlzIDI3YjQxMDAwIQ0KWyAgMTcyLjczMTEwOV0gMzA2NTMgaXMgMjdiNDIwMDAhDQpb
ICAxNzIuNzMyODA0XSAzMDY1NCBpcyAyN2I0MzAwMCENClsgIDE3Mi43MzQ0ODldIDMwNjU1
IGlzIDI3YjQ0MDAwIQ0KWyAgMTcyLjczNjE3Ml0gMzA2NTYgaXMgMjdiNDUwMDAhDQpbICAx
NzIuNzM3ODU0XSAzMDY1NyBpcyAyN2IzMDAwMCENClsgIDE3Mi43Mzk1MTVdIDMwNjU4IGlz
IDI3YjMxMDAwIQ0KWyAgMTcyLjc0MTIxMl0gMzA2NTkgaXMgMjdiMzIwMDAhDQpbICAxNzIu
NzQyODc4XSAzMDY1YSBpcyAyN2IzMzAwMCENClsgIDE3Mi43NDQ1NjJdIDMwNjViIGlzIDI3
YjM0MDAwIQ0KWyAgMTcyLjc0NjIxMV0gMzA2NWMgaXMgMjdiMzUwMDAhDQpbICAxNzIuNzQ3
ODc1XSAzMDY1ZCBpcyAyN2IzNjAwMCENClsgIDE3Mi43NDk1NDFdIDMwNjVlIGlzIDI3YjM3
MDAwIQ0KWyAgMTcyLjc1MTIwNV0gMzA2NWYgaXMgMjdiMzgwMDAhDQpbICAxNzIuNzUyODc2
XSAzMDY2MCBpcyAyN2IzOTAwMCENClsgIDE3Mi43NTQ1NTFdIDMwNjYxIGlzIDI3YjNhMDAw
IQ0KWyAgMTcyLjc1NzQwOF0gMzA2OGMgaXMgMjdhZjAwMDAhDQpbICAxNzIuNzU5MDg1XSAz
MDYwZCBpcyAyN2FmMTAwMCENClsgIDE3Mi43NjA3OTRdIDMwNjBlIGlzIDI3YWYyMDAwIQ0K
WyAgMTcyLjc2MjU0Ml0gMzA2MGYgaXMgMjdhZjMwMDAhDQpbICAxNzIuNzY0MjU2XSAzMDYx
MCBpcyAyN2FmNDAwMCENClsgIDE3Mi43NjU5NjddIDMwNjExIGlzIDI3YWY1MDAwIQ0KWyAg
MTcyLjc2NzY3OF0gMzA2MTIgaXMgMjdhZjYwMDAhDQpbICAxNzIuNzY5Mzk2XSAzMDYxMyBp
cyAyN2FmNzAwMCENClsgIDE3Mi43NzExMDJdIDMwNjE0IGlzIDI3YWY4MDAwIQ0KWyAgMTcy
Ljc3MjgwMV0gMzA2MTUgaXMgMjdhZjkwMDAhDQpbICAxNzIuNzc0NTI2XSAzMDYxNiBpcyAy
N2FmYTAwMCENClsgIDE3Mi43NzYyMDhdIDMwNjc3IGlzIDI3YjEwMDAwIQ0KWyAgMTcyLjc3
Nzk0M10gMzA2NzggaXMgMjdiMTEwMDAhDQpbICAxNzIuNzc5NjQwXSAzMDY3OSBpcyAyN2Ix
MjAwMCENClsgIDE3Mi43ODEzNjFdIDMwNjdhIGlzIDI3YjEzMDAwIQ0KWyAgMTcyLjc4MzA0
OF0gMzA2N2IgaXMgMjdiMTQwMDAhDQpbICAxNzIuNzg0NzYxXSAzMDY3YyBpcyAyN2IxNTAw
MCENClsgIDE3Mi43ODY0NjZdIDMwNjdkIGlzIDI3YjE2MDAwIQ0KWyAgMTcyLjc4ODE3Ml0g
MzA2N2UgaXMgMjdiMTcwMDAhDQpbICAxNzIuNzg5ODgwXSAzMDY3ZiBpcyAyN2IxODAwMCEN
ClsgIDE3Mi43OTE1NzldIDMwNjgwIGlzIDI3YjE5MDAwIQ0KWyAgMTcyLjc5MzI2OV0gMzA2
ODEgaXMgMjdiMWEwMDAhDQpbICAxNzIuNzk0OTg2XSAzMDY4MiBpcyAyN2IwNjAwMCENClsg
IDE3Mi43OTY2NzVdIDMwNjgzIGlzIDI3YjA3MDAwIQ0KWyAgMTcyLjc5ODM5Nl0gMzA2ODQg
aXMgMjdiMDgwMDAhDQpbICAxNzIuODAwMTAyXSAzMDY4NSBpcyAyN2IwOTAwMCENClsgIDE3
Mi44MDE4MDNdIDMwNjg2IGlzIDI3YjBhMDAwIQ0KWyAgMTcyLjgwMzUzMF0gMzA2ODcgaXMg
MjdiMGIwMDAhDQpbICAxNzIuODA1MjI3XSAzMDY4OCBpcyAyN2IwYzAwMCENClsgIDE3Mi44
MDY5NDldIDMwNjg5IGlzIDI3YjBkMDAwIQ0KWyAgMTcyLjgwODYzNF0gMzA2OGEgaXMgMjdi
MGUwMDAhDQpbICAxNzIuODEwMzMyXSAzMDY4YiBpcyAyN2IwZjAwMCENClsgIDE3Mi44MTIw
MTFdIDMwNjc2IGlzIDI3YWZiMDAwIQ0KWyAgMTcyLjgxMzcwNF0gMzA2NzUgaXMgMjdhZmMw
MDAhDQpbICAxNzIuODE1MzkyXSAzMDY3NCBpcyAyN2FmZDAwMCENClsgIDE3Mi44MTcwODFd
IDMwNjczIGlzIDI3YWZlMDAwIQ0KWyAgMTcyLjgxODc2Ml0gMzA2NzIgaXMgMjdhZmYwMDAh
DQpbICAxNzIuODIwNDQzXSAzMDY3MSBpcyAyN2IwMDAwMCENClsgIDE3Mi44MjIxMjddIDMw
NjcwIGlzIDI3YjAxMDAwIQ0KWyAgMTcyLjgyMzg0Ml0gMzA2NmYgaXMgMjdiMDIwMDAhDQpb
ICAxNzIuODI1NTI3XSAzMDY2ZSBpcyAyN2IwMzAwMCENClsgIDE3Mi44MjcyNDVdIDMwNjZk
IGlzIDI3YjA0MDAwIQ0KWyAgMTcyLjgyODkzNl0gMzA2NmMgaXMgMjdiMDUwMDAhDQpbICAx
NzIuODMyMzMwXSAzMDY5OCBpcyAyN2FjNjAwMCENClsgIDE3Mi44MzQxMTVdIDMwNjk5IGlz
IDI3YWM3MDAwIQ0KWyAgMTcyLjgzNTg0OF0gMzA2OWEgaXMgMjdhYzgwMDAhDQpbICAxNzIu
ODM3NTY5XSAzMDY5YiBpcyAyN2FjOTAwMCENClsgIDE3Mi44MzkyNzJdIDMwNjljIGlzIDI3
YWNhMDAwIQ0KWyAgMTcyLjg0MTAxN10gMzA2OWQgaXMgMjdhY2IwMDAhDQpbICAxNzIuODQy
NzMxXSAzMDY5ZSBpcyAyN2FjYzAwMCENClsgIDE3Mi44NDQ0ODhdIDMwNjlmIGlzIDI3YWNk
MDAwIQ0KWyAgMTcyLjg0NjIwOV0gMzA2YTAgaXMgMjdhY2UwMDAhDQpbICAxNzIuODQ3OTUw
XSAzMDZhMSBpcyAyN2FjZjAwMCENClsgIDE3Mi44NDk2NzBdIDMwNjIxIGlzIDI3YWRiMDAw
IQ0KWyAgMTcyLjg1MTM4MV0gMzA2MjAgaXMgMjdhZGMwMDAhDQpbICAxNzIuODUzMDk4XSAz
MDYxZiBpcyAyN2FkZDAwMCENClsgIDE3Mi44NTQ4MTldIDMwNjFlIGlzIDI3YWRlMDAwIQ0K
WyAgMTcyLjg1NjUzMl0gMzA2MWQgaXMgMjdhZGYwMDAhDQpbICAxNzIuODU4MjQ5XSAzMDYx
YyBpcyAyN2FlMDAwMCENClsgIDE3Mi44NTk5NTZdIDMwNjFiIGlzIDI3YWUxMDAwIQ0KWyAg
MTcyLjg2MTY5NF0gMzA2MWEgaXMgMjdhZTIwMDAhDQpbICAxNzIuODYzNDIxXSAzMDYxOSBp
cyAyN2FlMzAwMCENClsgIDE3Mi44NjUxNTBdIDMwNjE4IGlzIDI3YWU0MDAwIQ0KWyAgMTcy
Ljg2Njg3N10gMzA2MTcgaXMgMjdhZTUwMDAhDQpbICAxNzIuODY4NTk1XSAzMDY4ZCBpcyAy
N2FkMDAwMCENClsgIDE3Mi44NzAzMTddIDMwNjhlIGlzIDI3YWQxMDAwIQ0KWyAgMTcyLjg3
MjAyOV0gMzA2OGYgaXMgMjdhZDIwMDAhDQpbICAxNzIuODczNzcyXSAzMDY5MCBpcyAyN2Fk
MzAwMCENClsgIDE3Mi44NzU0OTFdIDMwNjkxIGlzIDI3YWQ0MDAwIQ0KWyAgMTcyLjg3NzIy
MF0gMzA2OTIgaXMgMjdhZDUwMDAhDQpbICAxNzIuODc4OTIyXSAzMDY5MyBpcyAyN2FkNjAw
MCENClsgIDE3Mi44ODA2MjZdIDMwNjk0IGlzIDI3YWQ3MDAwIQ0KWyAgMTcyLjg4MjMzMV0g
MzA2OTUgaXMgMjdhZDgwMDAhDQpbICAxNzIuODg0MDM1XSAzMDY5NiBpcyAyN2FkOTAwMCEN
ClsgIDE3Mi44ODU3MzVdIDMwNjk3IGlzIDI3YWRhMDAwIQ0KWyAgMTcyLjg4ODM4N10gMzA2
YWQgaXMgMjdhYjAwMDAhDQpbICAxNzIuODkwMTI0XSAzMDZhZSBpcyAyN2FiMTAwMCENClsg
IDE3Mi44OTE4MDldIDMwNmFmIGlzIDI3YWIyMDAwIQ0KWyAgMTcyLjg5MzUwNV0gMzA2YjAg
aXMgMjdhYjMwMDAhDQpbICAxNzIuODk1MjA3XSAzMDZiMSBpcyAyN2FiNDAwMCENClsgIDE3
Mi44OTY5MjRdIDMwNmIyIGlzIDI3YWI1MDAwIQ0KWyAgMTcyLjg5ODYyM10gMzA2YjMgaXMg
MjdhYjYwMDAhDQpbICAxNzIuOTAwMzAxXSAzMDZiNCBpcyAyN2FiNzAwMCENClsgIDE3Mi45
MDIwMTFdIDMwNmI1IGlzIDI3YWI4MDAwIQ0KWyAgMTcyLjkwMzY5MV0gMzA2YjYgaXMgMjdh
YjkwMDAhDQpbICAxNzIuOTA1MzU0XSAzMDZiNyBpcyAyN2FiYTAwMCENClsgIDE3Mi45MDcw
NDVdIDMwNmI4IGlzIDI3YWE2MDAwIQ0KWyAgMTcyLjkwODcxM10gMzA2YjkgaXMgMjdhYTcw
MDAhDQpbICAxNzIuOTEwNDAyXSAzMDZiYSBpcyAyN2FhODAwMCENClsgIDE3Mi45MTIwNzdd
IDMwNmJiIGlzIDI3YWE5MDAwIQ0KWyAgMTcyLjkxMzc0Ml0gMzA2YmMgaXMgMjdhYWEwMDAh
DQpbICAxNzIuOTE1NDA1XSAzMDZiZCBpcyAyN2FhYjAwMCENClsgIDE3Mi45MTcwNTddIDMw
NmJlIGlzIDI3YWFjMDAwIQ0KWyAgMTcyLjkxODcyOV0gMzA2YmYgaXMgMjdhYWQwMDAhDQpb
ICAxNzIuOTIwMzgyXSAzMDZjMCBpcyAyN2FhZTAwMCENClsgIDE3Mi45MjIwMzFdIDMwNmMx
IGlzIDI3YWFmMDAwIQ0KWyAgMTcyLjkyMzcwMF0gMzA2YzIgaXMgMjdhOTAwMDAhDQpbICAx
NzIuOTI1MzU1XSAzMGZjNiBpcyAyN2E5MTAwMCENClsgIDE3Mi45MjcwMzBdIDMwNjIyIGlz
IDI3YTkyMDAwIQ0KWyAgMTcyLjkyODY4MV0gMzA2ZGYgaXMgMjdhOTMwMDAhDQpbICAxNzIu
OTMwMzUwXSAzMDZlMCBpcyAyN2E5NDAwMCENClsgIDE3Mi45MzIwNTFdIDMwNmUxIGlzIDI3
YTk1MDAwIQ0KWyAgMTcyLjkzMzczNF0gMzA2ZTIgaXMgMjdhOTYwMDAhDQpbICAxNzIuOTM1
NDE3XSAzMDZlMyBpcyAyN2E5NzAwMCENClsgIDE3Mi45MzcwOTddIDMwNmU0IGlzIDI3YTk4
MDAwIQ0KWyAgMTcyLjkzODc4Ml0gMzA2ZTUgaXMgMjdhOTkwMDAhDQpbICAxNzIuOTQwNDkz
XSAzMDZlNiBpcyAyN2E5YTAwMCENClsgIDE3Mi45NDQ5MjVdIDMwNmU3IGlzIDI3YTg2MDAw
IQ0KWyAgMTcyLjk0NjU5OV0gMzA2ZTggaXMgMjdhODcwMDAhDQpbICAxNzIuOTQ4MzA2XSAz
MDZlOSBpcyAyN2E4ODAwMCENClsgIDE3Mi45NDk5ODBdIDMwNmVhIGlzIDI3YTg5MDAwIQ0K
WyAgMTcyLjk1MTY3NF0gMzA2ZWIgaXMgMjdhOGEwMDAhDQpbICAxNzIuOTUzMzkwXSAzMDZl
YyBpcyAyN2E4YjAwMCENClsgIDE3Mi45NTUwODFdIDMwNmVkIGlzIDI3YThjMDAwIQ0KWyAg
MTcyLjk1Njc5MF0gMzA2ZWUgaXMgMjdhOGQwMDAhDQpbICAxNzIuOTU4NDc0XSAzMDZlZiBp
cyAyN2E4ZTAwMCENClsgIDE3Mi45NjAzMzZdIDMwNmYwIGlzIDI3YThmMDAwIQ0KWyAgMTcy
Ljk2MjQ3N10gMzA3MDAgaXMgMjdhNDkwMDAhDQpbICAxNzIuOTY0MjQ2XSAzMDcwMSBpcyAy
N2E0YTAwMCENClsgIDE3Mi45NjU5ODFdIDMwNzAyIGlzIDI3YTRiMDAwIQ0KWyAgMTcyLjk2
NzcxNF0gMzA3MDMgaXMgMjdhNGMwMDAhDQpbICAxNzIuOTY5NDYwXSAzMDcwNCBpcyAyN2E0
ZDAwMCENClsgIDE3Mi45NzExOThdIDMwNzA1IGlzIDI3YTRlMDAwIQ0KWyAgMTcyLjk3Mjk1
M10gMzA3MDYgaXMgMjdhNGYwMDAhDQpbICAxNzIuOTc0NjkyXSAzMDcwNyBpcyAyN2E1MDAw
MCENClsgIDE3Mi45NzY0MTddIDMwNzA4IGlzIDI3YTUxMDAwIQ0KWyAgMTcyLjk3ODE2NV0g
MzA3MDkgaXMgMjdhNTIwMDAhDQpbICAxNzIuOTc5ODgyXSAzMDcwYSBpcyAyN2E1MzAwMCEN
ClsgIDE3Mi45ODE2MzRdIDMwNzBiIGlzIDI3YTNlMDAwIQ0KWyAgMTcyLjk4MzM0OF0gMzA3
MGMgaXMgMjdhM2YwMDAhDQpbICAxNzIuOTg1MDkzXSAzMDcwZCBpcyAyN2E0MDAwMCENClsg
IDE3Mi45ODY4MTVdIDMwNzBlIGlzIFsgIDE3NS4xMTM2NDNdIDMwMWJiIGlzIDI3ZjdkMDAw
IQ0KWyAgMTc1LjExNTM3NF0gMzAxYmMgaXMgMjdmN2YwMDAhDQpbICAxNzUuMTE3MDk1XSAz
MDFiZCBpcyAyN2Y3ZTAwMCENClsgIDE3NS4xMTg4MDhdIDMwMWJlIGlzIDI3ZjZlMDAwIQ0K
WyAgMTc1LjEyMDgxOF0gMzAxYmYgaXMgMjcxYzIwMDAhDQpbICAxNzUuMTIyNDk2XSAzMDE3
YiBpcyAyN2Y2YzAwMCENClsgIDE3NS4xMjQyMjVdIDMwMTdjIGlzIDI3NzYwMDAwIQ0KWyAg
MTc1LjEyNTkyOV0gMzAxN2QgaXMgMjgxNjIwMDAhDQpbICAxNzUuMTI3NzQ0XSAzMDE3ZSBp
cyAyN2Y3NjAwMCENClsgIDE3NS4xMjk0NjVdIDMwMTdmIGlzIDI3Zjc4MDAwIQ0KWyAgMTc1
LjEzMTIwMF0gMzAxODAgaXMgMjdmNzcwMDAhDQpbICAxNzUuMTMyOTQxXSAzMDE4MSBpcyAy
ODE1NjAwMCENClsgIDE3NS4xMzQ3MDVdIDMwMWE5IGlzIDI3ZjcwMDAwIQ0KWyAgMTc1LjEz
NjQ5M10gMzAxYTggaXMgMjdmNmYwMDAhDQpbICAxNzUuMTM4Mjc4XSAzMDFhNyBpcyAyN2Y4
MDAwMCENClsgIDE3NS4xNDAwODJdIDMwMTgyIGlzIDI3ZjRkMDAwIQ0KWyAgMTc1LjE0MTg2
NF0gMzAxODMgaXMgMjdmNGUwMDAhDQpbICAxNzUuMTQzNjYwXSAzMDE4NCBpcyAyN2Y0ZjAw
MCENClsgIDE3NS4xNDU0NTRdIDMwMTg1IGlzIDI3ZjUwMDAwIQ0KWyAgMTc1LjE0NzI0NF0g
MzAxODYgaXMgMjdmNzEwMDAhDQpbICAxNzUuMTQ5MDQ0XSAzMDE4NyBpcyAyN2Y3MjAwMCEN
ClsgIDE3NS4xNTA4MjJdIDMwMTg4IGlzIDI3ZjczMDAwIQ0KWyAgMTc1LjE1MjYxM10gMzAx
ODkgaXMgMjdmNzQwMDAhDQpbICAxNzUuMTU0Mzk3XSAzMDE4YSBpcyAyN2Y1MTAwMCENClsg
IDE3NS4xNTYxNzRdIDMwMThiIGlzIDI3ZjUyMDAwIQ0KWyAgMTc1LjE1Nzk2OF0gMzAxOGMg
aXMgMjgxNjAwMDAhDQpbICAxNzUuMTU5NzQ0XSAzMDE4ZCBpcyAyN2Y0YjAwMCENClsgIDE3
NS4xNjE1NjhdIDMwMThlIGlzIDI3ZjRjMDAwIQ0KWyAgMTc1LjE2MzM4M10gMzAxYTYgaXMg
MjdmODEwMDAhDQpbICAxNzUuMTY1MjA5XSAzMDFhNSBpcyAyN2Y4ODAwMCENClsgIDE3NS4x
NjcwMjhdIDMwMWE0IGlzIDI3ZjZkMDAwIQ0KWyAgMTc1LjE2ODg0MF0gMzAxYTMgaXMgMjdm
NjkwMDAhDQpbICAxNzUuMTcwNjgxXSAzMDFhMiBpcyAyN2Y2ODAwMCENClsgIDE3NS4xNzI0
OThdIDMwMWExIGlzIDI3Zjg3MDAwIQ0KWyAgMTc1LjE3NDM1MV0gMzAxYTAgaXMgMjdmNzUw
MDAhDQpbICAxNzUuMTc2MzA1XSAzMDFhYSBpcyAyN2Y0YTAwMCENClsgIDE3NS4xODM3NTNd
IDMwMWMwIGlzIDI3ZjQ5MDAwIQ0KWyAgMTc1LjE5NDY2N10gMzAxOGYgaXMgMjdmNDgwMDAh
DQpbICAxNzUuMjA0MzYyXSAzMDFjMSBpcyAyN2Y0NzAwMCENClsgIDE3NS4yMTIzMTldIDMw
MWMyIGlzIDI3ZjQ2MDAwIQ0KWyAgMTc1LjIxNzI5NV0gMzAxYzMgaXMgMjdmNDUwMDAhDQpb
ICAxNzUuMjIxMzgwXSAzMDFjNCBpcyAyN2Y0NDAwMCENClsgIDE3NS4yMjQ5MDddIDMwMWM1
IGlzIDI3ZjQzMDAwIQ0KWyAgMTc1LjIyNzEyM10gMzAxYzYgaXMgMjdmNDIwMDAhDQpbICAx
NzUuMjM1NDMyXSAzMDFjNyBpcyAyN2Y0MTAwMCENClsgIDE3NS4yNDU5NDZdIDMwMWM4IGlz
IDI3ZjQwMDAwIQ0KWyAgMTc1LjI0ODk0NV0gMzAxYzkgaXMgMjdmM2YwMDAhDQpbICAxNzUu
MjUxMzgxXSAzMDFjYSBpcyAyN2YzZTAwMCENClsgIDE3NS4yNTM2MzVdIDMwMWNiIGlzIDI3
ZjNkMDAwIQ0KWyAgMTc1LjI1ODYyOV0gMzAxY2MgaXMgMjdmM2MwMDAhDQpbICAxNzUuMjYx
ODc4XSAzMDFjZCBpcyAyN2YzYjAwMCENClsgIDE3NS4yNzc4MzldIDMwMWNlIGlzIDI3ZjNh
MDAwIQ0KWyAgMTc1LjI4NzE3OV0gMzAxOTAgaXMgMjdmMzkwMDAhDQpbICAxNzUuMjkxMTU2
XSAzMDFjZiBpcyAyN2YzODAwMCENClsgIDE3NS4yOTMzNDJdIDMwMWQwIGlzIDI3ZjM3MDAw
IQ0KWyAgMTc1LjI5OTkyOF0gMzAxZDEgaXMgMjdmMzYwMDAhDQpbICAxNzUuMzA3NDY0XSAz
MDFkMiBpcyAyN2YzNTAwMCENClsgIDE3NS4zMTI1MDVdIDMwMWQzIGlzIDI3ZjM0MDAwIQ0K
WyAgMTc1LjMxNTYwNV0gMzAxZDQgaXMgMjdmMzMwMDAhDQpbICAxNzUuMzE3NzYxXSAzMDFk
NSBpcyAyN2YzMjAwMCENClsgIDE3NS4zMjA1NzhdIDMwMWQ2IGlzIDI3ZjMxMDAwIQ0KWyAg
MTc1LjMyNzI4MV0gMzAxZDcgaXMgMjdmMzAwMDAhDQpbICAxNzUuMzMwODA4XSAzMDFkOCBp
cyAyN2YyZjAwMCENClsgIDE3NS4zMzc5NjddIDMwMWQ5IGlzIDI3ZjJlMDAwIQ0KWyAgMTc1
LjM0MTY3Ml0gMzAxZGEgaXMgMjdmMmQwMDAhDQpbICAxNzUuMzQ5MDAzXSAzMDFkYiBpcyAy
N2YyYzAwMCENClsgIDE3NS4zNTExNjZdIDMwMWRjIGlzIDI3ZjJiMDAwIQ0KWyAgMTc1LjM1
MzMyN10gMzAxZGQgaXMgMjdmMmEwMDAhDQpbICAxNzUuMzc0NjE5XSAzMDFkZSBpcyAyN2Yy
OTAwMCENClsgIDE3NS4zODM0MjFdIDMwMWVlIGlzIDI3ZjI4MDAwIQ0KWyAgMTc1LjM4NTU0
Nl0gMzAxZGYgaXMgMjdmMjcwMDAhDQpbICAxNzUuMzg3NzIyXSAzMDFlMCBpcyAyN2YyNjAw
MCENClsgIDE3NS4zOTE1NjBdIDMwMWUxIGlzIDI3ZjI1MDAwIQ0KWyAgMTc1LjM5NDgwOF0g
MzAxZTIgaXMgMjdmMjQwMDAhDQpbICAxNzUuMzk5MDQ3XSAzMDFlMyBpcyAyN2YyMzAwMCEN
ClsgIDE3NS40MDIxNTNdIDMwMWU0IGlzIDI3ZjIyMDAwIQ0KWyAgMTc1LjQwODE1MV0gMzAx
ZTUgaXMgMjdmMjEwMDAhDQpbICAxNzUuNDE3MzA4XSAzMDFlNiBpcyAyN2YyMDAwMCENClsg
IDE3NS40MTk0NzZdIDMwMWU3IGlzIDI3ZjFmMDAwIQ0KWyAgMTc1LjQyMTYxNl0gMzAxZTgg
aXMgMjdmMWUwMDAhDQpbICAxNzUuNDI1MTgxXSAzMDFlOSBpcyAyN2YxZDAwMCENClsgIDE3
NS40Mjg5NzBdIDMwMWVhIGlzIDI3ZjFjMDAwIQ0KWyAgMTc1LjQzMTk1OF0gMzAxZWIgaXMg
MjdmMWIwMDAhDQpbICAxNzUuNDM2NTAwXSAzMDFlYyBpcyAyN2YxYTAwMCENClsgIDE3NS40
NDIyNjVdIDMwMWVkIGlzIDI3ZjE5MDAwIQ0KWyAgMTc1LjQ0Nzg3MV0gMzAyMGQgaXMgMjdm
MTgwMDAhDQpbICAxNzUuNDYwODkzXSAzMDIwZSBpcyAyN2YxNzAwMCENClsgIDE3NS40NzE0
ODBdIDMwMjBmIGlzIDI3ZjE2MDAwIQ0KWyAgMTc1LjQ3OTkzNF0gMzAxZWYgaXMgMjdmMTUw
MDAhDQpbICAxNzUuNDgyOTA1XSAzMDIxMCBpcyAyN2YxNDAwMCENClsgIDE3NS40ODY5MDRd
IDMwMjExIGlzIDI3ZjEzMDAwIQ0KWyAgMTc1LjQ5MTk2MV0gMzAyMTIgaXMgMjdmMTIwMDAh
DQpbICAxNzUuNDk3NjY3XSAzMDIxMyBpcyAyN2YxMTAwMCENClsgIDE3NS40OTk4MzBdIDMw
MjE0IGlzIDI3ZjEwMDAwIQ0KWyAgMTc1LjUwMjE4NF0gMzAyMTUgaXMgMjdmMGYwMDAhDQpb
ICAxNzUuNTA3MDAyXSAzMDIxNiBpcyAyN2YwZTAwMCENClsgIDE3NS41MTAxOTddIDMwMjE3
IGlzIDI3ZjBkMDAwIQ0KWyAgMTc1LjUxNDU3M10gMzAyMTggaXMgMjdmMGMwMDAhDQpbICAx
NzUuNTIwMTQyXSAzMDFmMCBpcyAyN2YwYjAwMCENClsgIDE3NS41MjcwMDddIDMwMjE5IGlz
IDI3ZjBhMDAwIQ0KWyAgMTc1LjUzMTc5NF0gMzAyMWEgaXMgMjdmMDkwMDAhDQpbICAxNzUu
NTQxMDk5XSAzMDIxYiBpcyAyN2YwODAwMCENClsgIDE3NS41NTUzMDZdIDMwMjFjIGlzIDI3
ZjA3MDAwIQ0KWyAgMTc1LjU1OTA2M10gMzAyMWQgaXMgMjdmMDYwMDAhDQpbICAxNzUuNTYy
NTY5XSAzMDIxZSBpcyAyN2YwNTAwMCENClsgIDE3NS41NjQ3MzNdIDMwMjFmIGlzIDI3ZjA0
MDAwIQ0KWyAgMTc1LjU3NTQ4Nl0gMzAyMjAgaXMgMjdmMDMwMDAhDQpbICAxNzUuNTc5NjY1
XSAzMDIyMSBpcyAyN2YwMjAwMCENClsgIDE3NS41ODI2NzBdIDMwMjIyIGlzIDI3ZjAxMDAw
IQ0KWyAgMTc1LjU5MTQ0OF0gMzAyMjMgaXMgMjdmMDAwMDAhDQpbICAxNzUuNjAyNTE5XSAz
MDIyNCBpcyAyN2VmZjAwMCENClsgIDE3NS42MDQ3MDJdIDMwMjI1IGlzIDI3ZWZlMDAwIQ0K
WyAgMTc1LjYxNzMyM10gMzAyMjYgaXMgMjdlZmQwMDAhDQpbICAxNzUuNjIzODI3XSAzMDIy
NyBpcyAyN2VmYzAwMCENClsgIDE3NS42MzAyNTFdIDMwMjI4IGlzIDI3ZWZiMDAwIQ0KWyAg
MTc1LjYzMjQ5Ml0gMzAyMjkgaXMgMjdlZmEwMDAhDQpbICAxNzUuNjM4MjIzXSAzMDIyYSBp
cyAyN2VmOTAwMCENClsgIDE3NS42NDA0MjhdIDMwMjJiIGlzIDI3ZWY4MDAwIQ0KWyAgMTc1
LjY0NDA5NF0gMzAyMmMgaXMgMjdlZjcwMDAhDQpbICAxNzUuNjQ3NzM2XSAzMDIyZCBpcyAy
N2VmNjAwMCENClsgIDE3NS42NTU4MDBdIDMwMjJlIGlzIDI3ZWY1MDAwIQ0KWyAgMTc1LjY2
MDMyNl0gMzAyMmYgaXMgMjdlZjQwMDAhDQpbICAxNzUuNjcxMDcxXSAzMDIzMSBpcyAyN2Vm
MjAwMCENClsgIDE3NS42NzMyOTBdIDMwMjMyIGlzIDI3ZWYxMDAwIQ0KWyAgMTc1LjY3Nzg2
N10gMzAyMzMgaXMgMjdlZjAwMDAhDQpbICAxNzUuNjg1NjkyXSAzMDFmMSBpcyAyN2VlZjAw
MCENClsgIDE3NS42ODgxMjNdIDMwMjM0IGlzIDI3ZWVlMDAwIQ0KWyAgMTc1LjY5OTA2NF0g
MzAyMzUgaXMgMjdlZWQwMDAhDQpbICAxNzUuNzEwMjAyXSAzMDIzNiBpcyAyN2VlYzAwMCEN
ClsgIDE3NS43MTI0MjVdIDMwMjM3IGlzIDI3ZWViMDAwIQ0KWyAgMTc1LjcxNDczN10gMzAy
MzggaXMgMjdlZWEwMDAhDQpbICAxNzUuNzE3NTQ1XSAzMDIzOSBpcyAyN2VlOTAwMCENClsg
IDE3NS43MTk3OTldIDMwMjNhIGlzIDI3ZWU4MDAwIQ0KWyAgMTc1LjcyMTk5N10gMzAyM2Ig
aXMgMjdlZTcwMDAhDQpbICAxNzUuNzI3MjI0XSAzMDIzYyBpcyAyN2VlNjAwMCENClsgIDE3
NS43MzA1NjldIDMwMjNkIGlzIDI3ZWU1MDAwIQ0KWyAgMTc1Ljc0MTg3MF0gMzAyM2UgaXMg
MjdlZTQwMDAhDQpbICAxNzUuNzUyNjk0XSAzMDIzZiBpcyAyN2VlMzAwMCENClsgIDE3NS43
NTUzMDNdIDMwMjQwIGlzIDI3ZWUyMDAwIQ0KWyAgMTc1Ljc1NzUyM10gMzAyNDEgaXMgMjdl
ZTEwMDAhDQpbICAxNzUuNzYxMzgxXSAzMDI0MiBpcyAyN2VlMDAwMCENClsgIDE3NS43NjM1
MThdIDMwMjQzIGlzIDI3ZWRmMDAwIQ0KWyAgMTc1Ljc2NTgwNV0gMzAyNDQgaXMgMjdlZGUw
MDAhDQpbICAxNzUuNzcwNjQxXSAzMDFmMiBpcyAyN2VkZDAwMCENClsgIDE3NS43NzI4NDhd
IDMwMjQ1IGlzIDI3ZWRjMDAwIQ0KWyAgMTc1Ljc3NTAxMl0gMzAyNDYgaXMgMjdlZGIwMDAh
DQpbICAxNzUuNzg0MTc1XSAzMDFmMyBpcyAyN2VkYTAwMCENClsgIDE3NS43ODgwMjVdIDMw
MWY0IGlzIDI3ZWQ5MDAwIQ0KWyAgMTc1Ljc5NTcxNF0gMzAyNDcgaXMgMjdlZDgwMDAhDQpb
ICAxNzUuODEyMjQ2XSAzMDI0OCBpcyAyN2VkNzAwMCENClsgIDE3NS44MjQwMjddIDMwMjQ5
IGlzIDI3ZWQ2MDAwIQ0KWyAgMTc1LjgyNjI2NV0gMzAyNGEgaXMgMjdlZDUwMDAhDQpbICAx
NzUuODI4NTA0XSAzMDI0YiBpcyAyN2VkNDAwMCENClsgIDE3NS44MzUwNjFdIDMwMjRjIGlz
IDI3ZWQzMDAwIQ0KWyAgMTc1LjgzODA0OF0gMzAyNGQgaXMgMjdlZDIwMDAhDQpbICAxNzUu
ODQyNTg2XSAzMDI0ZSBpcyAyN2VkMTAwMCENClsgIDE3NS44NDgyNjNdIDMwMjRmIGlzIDI3
ZWQwMDAwIQ0KWyAgMTc1Ljg1MzAwMV0gMzAyNTAgaXMgMjdlY2YwMDAhDQpbICAxNzUuODU4
MzA3XSAzMDI1MSBpcyAyN2VjZTAwMCENClsgIDE3NS44NzMzNjNdIDMwMjUyIGlzIDI3ZWNk
MDAwIQ0KWyAgMTc1Ljg4MDUxMV0gMzAyNTMgaXMgMjdlY2MwMDAhDQpbICAxNzUuODg0MDM1
XSAzMDI1NCBpcyAyN2VjYjAwMCENClsgIDE3NS44ODYyMzJdIDMwMjU1IGlzIDI3ZWNhMDAw
IQ0KWyAgMTc1Ljg4ODQxMF0gMzAyNTYgaXMgMjdlYzkwMDAhDQpbICAxNzUuODkxMjgxXSAz
MDI1NyBpcyAyN2VjODAwMCENClsgIDE3NS44OTg5NzRdIDMwMjU4IGlzIDI3ZWM3MDAwIQ0K
WyAgMTc1LjkwMTE2NF0gMzAyNTkgaXMgMjdlYzYwMDAhDQpbICAxNzUuOTEwMTY2XSAzMDI1
YSBpcyAyN2VjNTAwMCENClsgIDE3NS45MTUxMDldIDMwMjViIGlzIDI3ZWM0MDAwIQ0KWyAg
MTc1LjkyNDc4NF0gMzAyNWMgaXMgMjdlYzMwMDAhDQpbICAxNzUuOTI2OTY5XSAzMDI1ZCBp
cyAyN2VjMjAwMCENClsgIDE3NS45NDA4MTldIDMwMjVlIGlzIDI3ZWMxMDAwIQ0KWyAgMTc1
Ljk0NDc5M10gMzAyNWYgaXMgMjdlYzAwMDAhDQpbICAxNzUuOTQ5MDYwXSAzMDI2MCBpcyAy
N2ViZjAwMCENClsgIDE3NS45NTE4NThdIDMwMjYxIGlzIDI3ZWJlMDAwIQ0KWyAgMTc1Ljk1
NzY2OF0gMzAyNjIgaXMgMjdlYmQwMDAhDQpbICAxNzUuOTY0MDY0XSAzMDI2MyBpcyAyN2Vi
YzAwMCENClsgIDE3NS45NzgyOTFdIDMwMjY0IGlzIDI3ZWJiMDAwIQ0KWyAgMTc1Ljk4MDQz
NF0gMzAyNjUgaXMgMjdlYmEwMDAhDQpbICAxNzUuOTg1OTA1XSAzMDI2NiBpcyAyN2ViOTAw
MCENClsgIDE3NS45ODg2MTZdIDMwMjY3IGlzIDI3ZWI4MDAwIQ0KWyAgMTc1Ljk5ODI5Nl0g
MzAyNjggaXMgMjdlYjcwMDAhDQpbICAxNzYuMDAwNTA0XSAzMDI2OSBpcyAyN2U3YTAwMCEN
ClsgIDE3Ni4wMDI2NzJdIDMwMjZhIGlzIDI3ZTdiMDAwIQ0KWyAgMTc2LjAwNjM1N10gMzAy
NmIgaXMgMjdlN2MwMDAhDQpbICAxNzYuMDEwMDg4XSAzMDI2YyBpcyAyN2U3ZDAwMCENClsg
IDE3Ni4wMTIxNjZdIDMwMjZkIGlzIDI3ZTdlMDAwIQ0KWyAgMTc2LjAxNTg2Ml0gMzAyNmUg
aXMgMjdlN2YwMDAhDQpbICAxNzYuMDMwMzI5XSAzMDI2ZiBpcyAyN2U4MDAwMCENClsgIDE3
Ni4wMzM4MDBdIDMwMWY1IGlzIDI3ZTgxMDAwIQ0KWyAgMTc2LjAzODEzMV0gMzAyNzAgaXMg
MjdlODIwMDAhDQpbICAxNzYuMDQ0NzQwXSAzMDI3MSBpcyAyN2U4MzAwMCENClsgIDE3Ni4w
NDgyNjddIDMwMjcyIGlzIDI3ZTg0MDAwIQ0KWyAgMTc2LjA1MDQxOF0gMzAyNzMgaXMgMjdl
ODUwMDAhDQpbICAxNzYuMDU4MjI1XSAzMDI3NCBpcyAyN2U4NjAwMCENClsgIDE3Ni4wNjQ1
OTddIDMwMjc1IGlzIDI3ZTg3MDAwIQ0KWyAgMTc2LjA2ODI0M10gMzAyNzYgaXMgMjdlODgw
MDAhDQpbICAxNzYuMDcxNDAwXSAzMDI3NyBpcyAyN2U4OTAwMCENClsgIDE3Ni4wNzUwOTdd
IDMwMjc4IGlzIDI3ZThhMDAwIQ0KWyAgMTc2LjA4MjQzMF0gMzAyNzkgaXMgMjdlOGIwMDAh
DQpbICAxNzYuMDg1NTA3XSAzMDI3YSBpcyAyN2U4YzAwMCENClsgIDE3Ni4wOTUzODRdIDMw
MjdiIGlzIDI3ZThkMDAwIQ0KWyAgMTc2LjA5OTc1OF0gMzAyN2MgaXMgMjdlOGUwMDAhDQpb
ICAxNzYuMTAyOTI0XSAzMDI3ZCBpcyAyN2U4ZjAwMCENClsgIDE3Ni4xMTE3MDFdIDMwMjdl
IGlzIDI3ZTkwMDAwIQ0KWyAgMTc2LjExNDc3NV0gMzAyN2YgaXMgMjdlOTEwMDAhDQpbICAx
NzYuMTE3Mjk4XSAzMDI4MCBpcyAyN2U5MjAwMCENClsgIDE3Ni4xMjA1NzldIDMwMjgxIGlz
IDI3ZTkzMDAwIQ0KWyAgMTc2LjEyNjY0Ml0gMzAyODIgaXMgMjdlOTQwMDAhDQpbICAxNzYu
MTI4ODIyXSAzMDI4MyBpcyAyN2U5NTAwMCENClsgIDE3Ni4xMzI4MTFdIDMwMjg0IGlzIDI3
ZWIzMDAwIQ0KWyAgMTc2LjEzNTAyM10gMzAyODUgaXMgMjdlYTQwMDAhDQpbICAxNzYuMTQx
MDQzXSAzMDI4NiBpcyAyN2VhNTAwMCENClsgIDE3Ni4xNDMyNDBdIDMwMjg3IGlzIDI3ZWEz
MDAwIQ0KWyAgMTc2LjE3NTQzNV0gMzAyODggaXMgMjdlYTIwMDAhDQpbICAxNzYuMTc3NjA5
XSAzMDFmNiBpcyAyN2VhODAwMCENClsgIDE3Ni4xODExNzNdIDMwMjg5IGlzIDI3ZWE5MDAw
IQ0KWyAgMTc2LjE4MzM0MF0gMzAyOGEgaXMgMjdlYWEwMDAhDQpbICAxNzYuMTg1NTUxXSAz
MDI4YiBpcyAyN2VhYjAwMCENClsgIDE3Ni4xODc3MjldIDMwMjhjIGlzIDI3ZWFkMDAwIQ0K
WyAgMTc2LjE5MTk2M10gMzAyOGQgaXMgMjdlYTcwMDAhDQpbICAxNzYuMTk0MTM4XSAzMDI4
ZSBpcyAyN2ViMDAwMCENClsgIDE3Ni4xOTYyNzhdIDMwMjhmIGlzIDI3ZWFlMDAwIQ0KWyAg
MTc2LjIwMzkyNF0gMzAyOTAgaXMgMjdlOTYwMDAhDQpbICAxNzYuMjA2MTE4XSAzMDFmNyBp
cyAyN2U5NzAwMCENClsgIDE3Ni4yMDgzMDhdIDMwMjkxIGlzIDI3ZWFmMDAwIQ0KWyAgMTc2
LjIxMDUyMF0gMzAyOTIgaXMgMjdlYjQwMDAhDQpbICAxNzYuMjEyNzA4XSAzMDI5MyBpcyAy
N2VhNjAwMCENClsgIDE3Ni4yMTQ5NDJdIDMwMjk0IGlzIDI3ZWIyMDAwIQ0KWyAgMTc2LjIx
NzEyOV0gMzAyOTUgaXMgMjdlYjEwMDAhDQpbICAxNzYuMjE5MzQ1XSAzMDI5NiBpcyAyN2Y4
NTAwMCENClsgIDE3Ni4yMjE1NzRdIDMwMjk3IGlzIDI3ZTlkMDAwIQ0KWyAgMTc2LjIyMzgw
MF0gMzAyOTggaXMgMjdlOWUwMDAhDQpbICAxNzYuMjI2MDQ3XSAzMDI5OSBpcyAyN2M5MjAw
MCENClsgIDE3Ni4yMjgyODVdIDMwMjlhIGlzIDI3Zjc5MDAwIQ0KWyAgMTc2LjIzMDUxM10g
MzAyOWIgaXMgMjdjOTMwMDAhDQpbICAxNzYuMjMyNzM3XSAzMDI5YyBpcyAyN2ViNTAwMCEN
ClsgIDE3Ni4yMzQ5NzldIDMwMjlkIGlzIDI4MTYxMDAwIQ0KWyAgMTc2LjIzNzIzMF0gMzAy
OWUgaXMgMjdlNzkwMDAhDQpbICAxNzYuMjM5NTExXSAzMDI5ZiBpcyAyN2U5YzAwMCENClsg
IDE3Ni4yNDE3NzJdIDMwMmEwIGlzIDI3ZTliMDAwIQ0KWyAgMTc2LjI0ODg0Ml0gMzAyYTEg
aXMgMjdlOWEwMDAhDQpbICAxNzYuMjU4NjU0XSAzMDJhMiBpcyAyN2U5OTAwMCENClsgIDE3
Ni4yNjA5NTJdIDMwMWY4IGlzIDI3ZTc4MDAwIQ0KWyAgMTc2LjI2MzIzN10gMzAyYTMgaXMg
MjdlNzcwMDAhDQpbICAxNzYuMjY5OTI4XSAzMDJhNCBpcyAyN2U3NjAwMCENClsgIDE3Ni4y
NzIzMTBdIDMwMmE1IGlzIDI3ZTc1MDAwIQ0KWyAgMTc2LjI3NDYyNF0gMzAyYTYgaXMgMjdl
NzQwMDAhDQpbICAxNzYuMjc2ODc3XSAzMDJhNyBpcyAyN2U3MzAwMCENClsgIDE3Ni4yNzky
ODNdIDMwMmE4IGlzIDI3ZTcyMDAwIQ0KWyAgMTc2LjI4MTYxN10gMzAxZjkgaXMgMjdlNzEw
MDAhDQpbICAxNzYuMjgzOTA1XSAzMDJhOSBpcyAyN2U3MDAwMCENClsgIDE3Ni4yODYyMzld
IDMwMWZhIGlzIDI3ZTZmMDAwIQ0KWyAgMTc2LjI5MjU2MF0gMzAyYWEgaXMgMjdlNmUwMDAh
DQpbICAxNzYuMjk0ODkwXSAzMDFmYiBpcyAyN2U2ZDAwMCENClsgIDE3Ni4yOTcxOTBdIDMw
MWZjIGlzIDI3ZTZjMDAwIQ0KWyAgMTc2LjI5OTQ5Ml0gMzAxZmQgaXMgMjdlNmIwMDAhDQpb
ICAxNzYuMzAxNzU2XSAzMDJhYiBpcyAyN2U2YTAwMCENClsgIDE3Ni4zMDQwMjldIDMwMWZl
IGlzIDI3ZTY5MDAwIQ0KWyAgMTc2LjMyMTgzOV0gMzAxZmYgaXMgMjdlNjIwMDAhDQpbICAx
NzYuMzIzNzIzXSAzMDIwMCBpcyAyN2U2MzAwMCENClsgIDE3Ni4zMjU2NzhdIDMwMjAxIGlz
IDI3ZTY0MDAwIQ0KWyAgMTc2LjMyNzYzN10gMzAyMDIgaXMgMjdlNjUwMDAhDQpbICAxNzYu
MzI5NDcwXSAzMDIwMyBpcyAyN2U2NjAwMCENClsgIDE3Ni4zMzEzMzldIDMwMjA0IGlzIDI3
ZTY3MDAwIQ0KWyAgMTc2LjMzMzE3MV0gMzAyMDUgaXMgMjdlNjgwMDAhDQpbICAxNzYuMzM1
NDI2XSAzMDJkNiBpcyAyN2U0MTAwMCENClsgIDE3Ni4zMzcyNzRdIDMwMmQ3IGlzIDI3ZTQy
MDAwIQ0KWyAgMTc2LjMzOTA5NF0gMzAyZDggaXMgMjdlNDMwMDAhDQpbICAxNzYuMzQwODk0
XSAzMDJkOSBpcyAyN2U0NDAwMCENClsgIDE3Ni4zNDI2NzBdIDMwMmRhIGlzIDI3ZTQ1MDAw
IQ0KWyAgMTc2LjM0NDQ5Nl0gMzAyZGIgaXMgMjdlNDYwMDAhDQpbICAxNzYuMzQ2MjM1XSAz
MDJkYyBpcyAyN2U0NzAwMCENClsgIDE3Ni4zNDgwMTddIDMwMmRkIGlzIDI3ZTQ4MDAwIQ0K
WyAgMTc2LjM0OTc2OV0gMzAyZGUgaXMgMjdlNDkwMDAhDQpbICAxNzYuMzUxNTI1XSAzMDJk
ZiBpcyAyN2U0YTAwMCENClsgIDE3Ni4zNTMyNDVdIDMwMmUwIGlzIDI3ZTRiMDAwIQ0KWyAg
MTc2LjM1NDk5M10gMzAyZTEgaXMgMjdlM2EwMDAhDQpbICAxNzYuMzU2NzI5XSAzMDJlMiBp
cyAyN2UzYjAwMCENClsgIDE3Ni4zNTg0NDhdIDMwMmUzIGlzIDI3ZTNjMDAwIQ0KWyAgMTc2
LjM2MDE5OF0gMzAyZTQgaXMgMjdlM2QwMDAhDQpbICAxNzYuMzYxOTE4XSAzMDJlNSBpcyAy
N2UzZTAwMCENClsgIDE3Ni4zNjM2NDVdIDMwMmU2IGlzIDI3ZTNmMDAwIQ0KWyAgMTc2LjM2
NTMzNF0gMzAyZTcgaXMgMjdlNDAwMDAhDQpbICAxNzYuMzY3MDI3XSAzMDIwNiBpcyAyN2U1
NzAwMCENClsgIDE3Ni4zNjg3MjNdIDMwMjA3IGlzIDI3ZTU4MDAwIQ0KWyAgMTc2LjM3MDQw
NV0gMzAyMDggaXMgMjdlNTkwMDAhDQpbICAxNzYuMzcyMTA2XSAzMDIwOSBpcyAyN2U1YTAw
MCENClsgIDE3Ni4zNzM4MDVdIDMwMjBhIGlzIDI3ZTViMDAwIQ0KWyAgMTc2LjM3NTQ2MF0g
MzAyMGIgaXMgMjdlNWMwMDAhDQpbICAxNzYuMzc3MTM1XSAzMDIwYyBpcyAyN2U1ZDAwMCEN
ClsgIDE3Ni4zNzg3NzldIDMwMmM3IGlzIDI3ZTVlMDAwIQ0KWyAgMTc2LjM4MDQ0OF0gMzAy
YzggaXMgMjdlNWYwMDAhDQpbICAxNzYuMzgyMDkzXSAzMDJjOSBpcyAyN2U2MDAwMCENClsg
IDE3Ni4zODM3NjNdIDMwMmNhIGlzIDI3ZTYxMDAwIQ0KWyAgMTc2LjM4NTQzMF0gMzAyY2Ig
aXMgMjdlNGMwMDAhDQpbICAxNzYuMzg3MDkzXSAzMDJjYyBpcyAyN2U0ZDAwMCENClsgIDE3
Ni4zODg3NjFdIDMwMmNkIGlzIDI3ZTRlMDAwIQ0KWyAgMTc2LjM5MDQxM10gMzAyY2UgaXMg
MjdlNGYwMDAhDQpbICAxNzYuMzkyMDU4XSAzMDJjZiBpcyAyN2U1MDAwMCENClsgIDE3Ni4z
OTM3NDVdIDMwMmQwIGlzIDI3ZTUxMDAwIQ0KWyAgMTc2LjM5NTQxMl0gMzAyZDEgaXMgMjdl
NTIwMDAhDQpbICAxNzYuMzk3MTEwXSAzMDJkMiBpcyAyN2U1MzAwMCENClsgIDE3Ni4zOTg3
NzFdIDMwMmQzIGlzIDI3ZTU0MDAwIQ0KWyAgMTc2LjQwMDQ2N10gMzAyZDQgaXMgMjdlNTUw
MDAhDQpbICAxNzYuNDAyMTQxXSAzMDJkNSBpcyAyN2U1NjAwMCENClsgIDE3Ni40MDUwMDZd
IDMwMmVhIGlzIDI3ZTJmMDAwIQ0KWyAgMTc2LjQwNjkyMV0gMzAyZWIgaXMgMjdlMzAwMDAh
DQpbICAxNzYuNDA4NjA3XSAzMDJlYyBpcyAyN2UzMTAwMCENClsgIDE3Ni40MTAzMjBdIDMw
MmVkIGlzIDI3ZTMyMDAwIQ0KWyAgMTc2LjQxMjAwN10gMzAyZWUgaXMgMjdlMzMwMDAhDQpb
ICAxNzYuNDEzNzI2XSAzMDJlZiBpcyAyN2UzNDAwMCENClsgIDE3Ni40MTU0MTBdIDMwMmYw
IGlzIDI3ZTM1MDAwIQ0KWyAgMTc2LjQxNzEzNV0gMzAyZjEgaXMgMjdlMzYwMDAhDQpbICAx
NzYuNDE4ODMxXSAzMDJmMiBpcyAyN2UzNzAwMCENClsgIDE3Ni40MjA1MjldIDMwMmYzIGlz
IDI3ZTM4MDAwIQ0KWyAgMTc2LjQyMjIyNl0gMzAyZjQgaXMgMjdlMzkwMDAhDQpbICAxNzYu
NDIzOTIyXSAzMDJmNSBpcyAyN2UyNDAwMCENClsgIDE3Ni40MjU2MDldIDMwMmY2IGlzIDI3
ZTI1MDAwIQ0KWyAgMTc2LjQyNzMwMl0gMzAyZjcgaXMgMjdlMjYwMDAhDQpbICAxNzYuNDI4
OTgxXSAzMDJmOCBpcyAyN2UyNzAwMCENClsgIDE3Ni40MzA2OTJdIDMwMmY5IGlzIDI3ZTI4
MDAwIQ0KWyAgMTc2LjQzMjM3N10gMzAyZmEgaXMgMjdlMjkwMDAhDQpbICAxNzYuNDM0MDgz
XSAzMDJmYiBpcyAyN2UyYTAwMCENClsgIDE3Ni40MzU3NTVdIDMwMmZjIGlzIDI3ZTJiMDAw
IQ0KWyAgMTc2LjQzNzQzNl0gMzAyZmQgaXMgMjdlMmMwMDAhDQpbICAxNzYuNDM5MTI1XSAz
MDJmZSBpcyAyN2UyZDAwMCENClsgIDE3Ni40NDA4MDZdIDMwMmZmIGlzIDI3ZTJlMDAwIQ0K
WyAgMTc2LjQ0MjU1Ml0gMzAzMjAgaXMgMjdkZmEwMDAhDQpbICAxNzYuNDQ0MjkwXSAzMDMy
MSBpcyAyN2RmYjAwMCENClsgIDE3Ni40NDYwMDFdIDMwMzIyIGlzIDI3ZGZjMDAwIQ0KWyAg
MTc2LjQ0Nzc0MF0gMzAzMjMgaXMgMjdkZmQwMDAhDQpbICAxNzYuNDQ5NDUwXSAzMDMyNCBp
cyAyN2RmZTAwMCENClsgIDE3Ni40NTExODBdIDMwMzI1IGlzIDI3ZGZmMDAwIQ0KWyAgMTc2
LjQ1Mjg3OF0gMzAzMjYgaXMgMjdlMDAwMDAhDQpbICAxNzYuNDU0NjA0XSAzMDMyNyBpcyAy
N2UwMTAwMCENClsgIDE3Ni40NTYyOTddIDMwMzI4IGlzIDI3ZTAyMDAwIQ0KWyAgMTc2LjQ1
Nzk5N10gMzAzMjkgaXMgMjdlMDMwMDAhDQpbICAxNzYuNDU5OTM1XSAzMDMwYSBpcyAyN2Uw
ZjAwMCENClsgIDE3Ni40NjE2MTddIDMwMzBiIGlzIDI3ZTEwMDAwIQ0KWyAgMTc2LjQ2MzI5
Nl0gMzAzMGMgaXMgMjdlMTEwMDAhDQpbICAxNzYuNDY0OTY4XSAzMDMwZCBpcyAyN2UxMjAw
MCENClsgIDE3Ni40NjY2MjNdIDMwMzBlIGlzIDI3ZTEzMDAwIQ0KWyAgMTc2LjQ2ODMxMF0g
MzAzMGYgaXMgMjdlMTQwMDAhDQpbICAxNzYuNDY5OTY5XSAzMDMxMCBpcyAyN2UxNTAwMCEN
ClsgIDE3Ni40NzE2NjJdIDMwMzExIGlzIDI3ZTE2MDAwIQ0KWyAgMTc2LjQ3MzMyOF0gMzAz
MTIgaXMgMjdlMTcwMDAhDQpbICAxNzYuNDc1MDA2XSAzMDMxMyBpcyAyN2UxODAwMCENClsg
IDE3Ni40NzY2ODZdIDMwMzE0IGlzIDI3ZTE5MDAwIQ0KWyAgMTc2LjQ3ODM2M10gMzAzMDAg
aXMgMjdlMWEwMDAhDQpbICAxNzYuNDgwMDY0XSAzMDMwMSBpcyAyN2UxYjAwMCENClsgIDE3
Ni40ODE3MzRdIDMwMzAyIGlzIDI3ZTFjMDAwIQ0KWyAgMTc2LjQ4MzQxN10gMzAzMDMgaXMg
MjdlMWQwMDAhDQpbICAxNzYuNDg1MDkyXSAzMDMwNCBpcyAyN2UxZTAwMCENClsgIDE3Ni40
ODY3NjldIDMwMzA1IGlzIDI3ZTFmMDAwIQ0KWyAgMTc2LjQ4ODQ0M10gMzAzMDYgaXMgMjdl
MjAwMDAhDQpbICAxNzYuNDkwMTI3XSAzMDMwNyBpcyAyN2UyMTAwMCENClsgIDE3Ni40OTE3
OTRdIDMwMzA4IGlzIDI3ZTIyMDAwIQ0KWyAgMTc2LjQ5MzQ5M10gMzAzMDkgaXMgMjdlMjMw
MDAhDQpbICAxNzYuNDk1MTQ4XSAzMDMxNSBpcyAyN2UwNDAwMCENClsgIDE3Ni40OTY4MjNd
IDMwMzE2IGlzIDI3ZTA1MDAwIQ0KWyAgMTc2LjQ5ODQ2N10gMzAzMTcgaXMgMjdlMDYwMDAh
DQpbICAxNzYuNTAwMTI1XSAzMDMxOCBpcyAyN2UwNzAwMCENClsgIDE3Ni41MDE3OTddIDMw
MzE5IGlzIDI3ZTA4MDAwIQ0KWyAgMTc2LjUwMzQ3M10gMzAzMWEgaXMgMjdlMDkwMDAhDQpb
ICAxNzYuNTA1MTUxXSAzMDMxYiBpcyAyN2UwYTAwMCENClsgIDE3Ni41MDY4MTNdIDMwMzFj
IGlzIDI3ZTBiMDAwIQ0KWyAgMTc2LjUwODQ2Ml0gMzAzMWQgaXMgMjdlMGMwMDAhDQpbICAx
NzYuNTEwMTQ0XSAzMDMxZSBpcyAyN2UwZDAwMCENClsgIDE3Ni41MTE4MTFdIDMwMzFmIGlz
IDI3ZTBlMDAwIQ0KWyAgMTc2LjUxNDg4MV0gMzAzMmEgaXMgMjdkZWYwMDAhDQpbICAxNzYu
NTE2NTY4XSAzMDJlOSBpcyAyN2RmMDAwMCENClsgIDE3Ni41MTgzMDJdIDMwMmU4IGlzIDI3
ZGYxMDAwIQ0KWyAgMTc2LjUyMDAxN10gMzAyYWMgaXMgMjdkZjIwMDAhDQpbICAxNzYuNTIx
NzY1XSAzMDJhZCBpcyAyN2RmMzAwMCENClsgIDE3Ni41MjM1MDZdIDMwMmFlIGlzIDI3ZGY0
MDAwIQ0KWyAgMTc2LjUyNTIwMl0gMzAyYWYgaXMgMjdkZjUwMDAhDQpbICAxNzYuNTI2OTM1
XSAzMDJiMCBpcyAyN2RmNjAwMCENClsgIDE3Ni41Mjg2MzNdIDMwMmIxIGlzIFsgIDE3OC42
NTk5NjJdIDJmZTM2IGlzIDI4MjdhMDAwIQ0KWyAgMTc4LjY2MjE1Nl0gMmZlMzcgaXMgMjgy
NzkwMDAhDQpbICAxNzguNjY0NDY1XSAyZmUzOCBpcyAyODI3ODAwMCENClsgIDE3OC42NjY2
NDFdIDJmZTM5IGlzIDI4Mjc3MDAwIQ0KWyAgMTc4LjY2OTAwNF0gMmZlM2EgaXMgMjgyNzYw
MDAhDQpbICAxNzguNjcxMjgxXSAyZmUzYiBpcyAyODI3NTAwMCENClsgIDE3OC42NzM1MjZd
IDJmZTNjIGlzIDI4Mjc0MDAwIQ0KWyAgMTc4LjY4MTIzNV0gMmZlM2QgaXMgMjgyNzMwMDAh
DQpbICAxNzguNjkxOTkyXSAyZmUzZSBpcyAyODI3MjAwMCENClsgIDE3OC43MDI5NTldIDJm
ZTNmIGlzIDI4MjcxMDAwIQ0KWyAgMTc4LjcwNTI4OV0gMmZlNDAgaXMgMjgyNzAwMDAhDQpb
ICAxNzguNzA3NTkxXSAyZmU0MSBpcyAyODI2ZjAwMCENClsgIDE3OC43NDI4NTldIDJmZTQy
IGlzIDI4MjZlMDAwIQ0KWyAgMTc4Ljc0NTE5Ml0gMmZlNDMgaXMgMjgyNmQwMDAhDQpbICAx
NzguNzQ3NDg5XSAyZmU0NCBpcyAyODI2YzAwMCENClsgIDE3OC43NDk2NjJdIDJmZTQ1IGlz
IDI4MjZiMDAwIQ0KWyAgMTc4Ljc1MjAzMF0gMmZlNDYgaXMgMjgyNmEwMDAhDQpbICAxNzgu
NzU2MDQzXSAyZmU0NyBpcyAyODI2OTAwMCENClsgIDE3OC43NTgzMzhdIDJmZTJhIGlzIDI4
MjY4MDAwIQ0KWyAgMTc4Ljc2MDYyM10gMmZlNDggaXMgMjgyNjcwMDAhDQpbICAxNzguNzYy
ODAyXSAyZmU0OSBpcyAyODI2NjAwMCENClsgIDE3OC43NjUxNzFdIDJmZTRhIGlzIDI4MjY1
MDAwIQ0KWyAgMTc4Ljc2NzQ1MF0gMmZlNGIgaXMgMjgyNjQwMDAhDQpbICAxNzguNzY5NjQy
XSAyZmU0YyBpcyAyODI2MzAwMCENClsgIDE3OC43NzE5ODhdIDJmZTRkIGlzIDI4MjYyMDAw
IQ0KWyAgMTc4Ljc3NDI1MF0gMmZlNGUgaXMgMjgyNjEwMDAhDQpbICAxNzguNzc2NDE5XSAy
ZmU0ZiBpcyAyODI2MDAwMCENClsgIDE3OC43Nzg3MjZdIDJmZTUwIGlzIDI4MjVmMDAwIQ0K
WyAgMTc4Ljc4MDk2NV0gMmZlNTEgaXMgMjgyNWUwMDAhDQpbICAxNzguNzgzMDg3XSAyZmU1
MiBpcyAyODI1ZDAwMCENClsgIDE3OC43ODU0MTZdIDJmZTUzIGlzIDI4MjVjMDAwIQ0KWyAg
MTc4Ljc4NzYyMF0gMmZlNTQgaXMgMjgyNWIwMDAhDQpbICAxNzguNzg5NzY1XSAyZmU1NSBp
cyAyODI1YTAwMCENClsgIDE3OC43OTIwNTldIDJmZTU2IGlzIDI4MjU5MDAwIQ0KWyAgMTc4
Ljc5NDI3OF0gMmZlNTcgaXMgMjgyNTgwMDAhDQpbICAxNzguNzk2Mzg2XSAyZmU1OSBpcyAy
ODI1NzAwMCENClsgIDE3OC44MDQwMTRdIDJmZTVhIGlzIDI4MjU2MDAwIQ0KWyAgMTc4Ljgx
NzEyOF0gMmZlNWIgaXMgMjgyNTUwMDAhDQpbICAxNzguODE5MzEzXSAyZmUyYiBpcyAyODI1
NDAwMCENClsgIDE3OC44MjE2MzhdIDJmZTVjIGlzIDI4MjUzMDAwIQ0KWyAgMTc4LjgzMDI1
M10gMmZlNWQgaXMgMjgyNTIwMDAhDQpbICAxNzguODMyNDE1XSAyZmU1ZSBpcyAyODI1MTAw
MCENClsgIDE3OC44MzQ3NDldIDJmZTVmIGlzIDI4MjUwMDAwIQ0KWyAgMTc4LjgzNjkwN10g
MmZlNjAgaXMgMjgyNGYwMDAhDQpbICAxNzguODM5MDg2XSAyZmU2MSBpcyAyODI0ZTAwMCEN
ClsgIDE3OC44NDEyMjNdIDJmZTYyIGlzIDI4MjRkMDAwIQ0KWyAgMTc4Ljg0OTk3MF0gMmZl
MmMgaXMgMjgyNGMwMDAhDQpbICAxNzguODUyMjg0XSAyZmU2MyBpcyAyODI0YjAwMCENClsg
IDE3OC44NTQ1NjFdIDJmZTY0IGlzIDI4MjRhMDAwIQ0KWyAgMTc4Ljg1NzEyN10gMmZlNjUg
aXMgMjgyNDgwMDAhDQpbICAxNzguODc5OTkxXSAyZmU2NiBpcyAyODI0NzAwMCENClsgIDE3
OC45MDE2ODFdIDJmZTJkIGlzIDI4MjQ2MDAwIQ0KWyAgMTc4LjkxMzgzMV0gMmZlMmUgaXMg
MjgyNDUwMDAhDQpbICAxNzguOTIzNzQyXSAyZmU2NyBpcyAyODI0NDAwMCENClsgIDE3OC45
MjU5MTddIDJmZTY4IGlzIDI4MjQzMDAwIQ0KWyAgMTc4LjkzNzM1Nl0gMmZlNjkgaXMgMjgy
NDIwMDAhDQpbICAxNzguOTM5NTY1XSAyZmU2YSBpcyAyODI0MTAwMCENClsgIDE3OC45NDYy
MzldIDJmZTZiIGlzIDI4MjQwMDAwIQ0KWyAgMTc4Ljk0ODU0N10gMmZlMmYgaXMgMjgyM2Yw
MDAhDQpbICAxNzguOTc4NDk0XSAyZmU2YyBpcyAyODIzZTAwMCENClsgIDE3OC45ODA4MTRd
IDJmZTMwIGlzIDI4MjNkMDAwIQ0KWyAgMTc4Ljk4Mjk4OF0gMmZlNmQgaXMgMjgyM2MwMDAh
DQpbICAxNzguOTg1Mzc0XSAyZmU2ZSBpcyAyODIzYjAwMCENClsgIDE3OC45ODc2NjJdIDJm
ZTZmIGlzIDI4MjNhMDAwIQ0KWyAgMTc4Ljk4OTg4NF0gMmZlNzAgaXMgMjgyMzkwMDAhDQpb
ICAxNzguOTkyMjczXSAyZmU3MSBpcyAyODIzODAwMCENClsgIDE3OC45OTQ1ODBdIDJmZTcy
IGlzIDI4MjM3MDAwIQ0KWyAgMTc4Ljk5NjgxN10gMmZlNzMgaXMgMjgyMzYwMDAhDQpbICAx
NzguOTk5MDA5XSAyZmU3NCBpcyAyODIzNTAwMCENClsgIDE3OS4wMDEyNjFdIDJmZTc1IGlz
IDI4MjM0MDAwIQ0KWyAgMTc5LjAwMzQ5Ml0gMmZlNzYgaXMgMjgyMzMwMDAhDQpbICAxNzku
MDA1NzEyXSAyZmU3NyBpcyAyODIzMjAwMCENClsgIDE3OS4wMDc5NDVdIDJmZTc4IGlzIDI4
MjMxMDAwIQ0KWyAgMTc5LjAxMDE3MF0gMmZlNzkgaXMgMjgyMzAwMDAhDQpbICAxNzkuMDEy
MzQ1XSAyZmU3YSBpcyAyODIyZjAwMCENClsgIDE3OS4wMTQ1NjhdIDJmZTdiIGlzIDI4MjJl
MDAwIQ0KWyAgMTc5LjAxOTg4MF0gMmZlN2MgaXMgMjgyMmQwMDAhDQpbICAxNzkuMDIzNjk0
XSAyZmUzMSBpcyAyODFmZjAwMCENClsgIDE3OS4wMjU5MThdIDJmZTMyIGlzIDI4MjAwMDAw
IQ0KWyAgMTc5LjAyODA4Nl0gMmZlN2QgaXMgMjgyMDEwMDAhDQpbICAxNzkuMDMwMjYyXSAy
ZmU5MCBpcyAyODIwMjAwMCENClsgIDE3OS4wMzI1NzRdIDJmZTdlIGlzIDI4MjAzMDAwIQ0K
WyAgMTc5LjAzNDgyMV0gMmZlOTEgaXMgMjgyMDQwMDAhDQpbICAxNzkuMDM2OTU0XSAyZmU3
ZiBpcyAyODIwNTAwMCENClsgIDE3OS4wNDMwNDNdIDJmZTgwIGlzIDI4MjA2MDAwIQ0KWyAg
MTc5LjA0NTMyM10gMmZlOTIgaXMgMjgyMDcwMDAhDQpbICAxNzkuMDQ3NTU5XSAyZmU5MyBp
cyAyODIwODAwMCENClsgIDE3OS4wNTQ4ODhdIDJmZTk0IGlzIDI4MjA5MDAwIQ0KWyAgMTc5
LjA1NzEzMF0gMmZlODEgaXMgMjgyMGEwMDAhDQpbICAxNzkuMDU5MzYxXSAyZmU4MiBpcyAy
ODIwYjAwMCENClsgIDE3OS4wNjE2OTVdIDJmZTgzIGlzIDI4MjEyMDAwIQ0KWyAgMTc5LjA2
Mzk5Nl0gMmZlODQgaXMgMjgyMjkwMDAhDQpbICAxNzkuMDY2MTg2XSAyZmU4NSBpcyAyODIy
YTAwMCENClsgIDE3OS4wNjg1MjNdIDJmZTg2IGlzIDI4MjI4MDAwIQ0KWyAgMTc5LjA3MDc4
M10gMmZlODcgaXMgMjgyMjcwMDAhDQpbICAxNzkuMDcyOTg0XSAyZmU4OCBpcyAyODIyMTAw
MCENClsgIDE3OS4wNzUyNzNdIDJmZTg5IGlzIDI4MjFjMDAwIQ0KWyAgMTc5LjA3NzU0NF0g
MmZlOGEgaXMgMjgyMWIwMDAhDQpbICAxNzkuMDc5NzA1XSAyZmU4YiBpcyAyODIxYTAwMCEN
ClsgIDE3OS4wODIwMDhdIDJmZThjIGlzIDI4MjE5MDAwIQ0KWyAgMTc5LjA4NDI4NF0gMmZl
OGQgaXMgMjgyMTcwMDAhDQpbICAxNzkuMDg2NDI5XSAyZmU4ZSBpcyAyODIyYzAwMCENClsg
IDE3OS4wODg3NzVdIDJmZThmIGlzIDI4MjE1MDAwIQ0KWyAgMTc5LjA5MDk5N10gMmZlYWYg
aXMgMjgyMTEwMDAhDQpbICAxNzkuMTAyODAwXSAyZmViMCBpcyAyODIwYzAwMCENClsgIDE3
OS4xMDUxNDBdIDJmZTk1IGlzIDI4MjBkMDAwIQ0KWyAgMTc5LjEwNzQzOF0gMmZlYjEgaXMg
MjgyMTYwMDAhDQpbICAxNzkuMTA5Njc2XSAyZmViMiBpcyAyODIyYjAwMCENClsgIDE3OS4x
MTIwNTldIDJmZWIzIGlzIDI4MjEzMDAwIQ0KWyAgMTc5LjExNDM5NF0gMmZlYjQgaXMgMjgy
MTQwMDAhDQpbICAxNzkuMTE2NTc0XSAyZmViNSBpcyAyODM4YTAwMCENClsgIDE3OS4xMTg5
NjBdIDJmZWI2IGlzIDI4MjIyMDAwIQ0KWyAgMTc5LjEyMTI3MV0gMmZlYjcgaXMgMjgyMjMw
MDAhDQpbICAxNzkuMTIzNDg5XSAyZmViOCBpcyAyN2ViNjAwMCENClsgIDE3OS4xMjU3MTFd
IDJmZWI5IGlzIDI4Mzk4MDAwIQ0KWyAgMTc5LjEyNzk4Ml0gMmZlYmEgaXMgMjgxNGEwMDAh
DQpbICAxNzkuMTMwMTc3XSAyZmViYiBpcyAyODIxMDAwMCENClsgIDE3OS4xMzI1MjBdIDJm
ZWJjIGlzIDI4NDUyMDAwIQ0KWyAgMTc5LjEzNDgwM10gMmZlOTYgaXMgMjg0MmMwMDAhDQpb
ICAxNzkuMTM3MDQyXSAyZmViZCBpcyAyODQyYjAwMCENClsgIDE3OS4xMzkyOTRdIDJmZWJl
IGlzIDI4MjIwMDAwIQ0KWyAgMTc5LjE0MTY1OF0gMmZlYmYgaXMgMjgyMWYwMDAhDQpbICAx
NzkuMTQzOTkxXSAyZmVjMCBpcyAyODIxZTAwMCENClsgIDE3OS4xNDYyMjhdIDJmZWMxIGlz
IDI4MjFkMDAwIQ0KWyAgMTc5LjE0ODU4MV0gMmZlYzIgaXMgMjgxZmMwMDAhDQpbICAxNzku
MTUwOTE4XSAyZmVjMyBpcyAyODFmYjAwMCENClsgIDE3OS4xNjA0OTddIDJmZWM0IGlzIDI4
MWZhMDAwIQ0KWyAgMTc5LjE2MjkxNV0gMmZlOTcgaXMgMjgxZjkwMDAhDQpbICAxNzkuMTc0
ODUzXSAyZmVjNSBpcyAyODFmODAwMCENClsgIDE3OS4xNzcyOTddIDJmZWM2IGlzIDI4MWY3
MDAwIQ0KWyAgMTc5LjE3OTU4OF0gMmZlYzcgaXMgMjgxZjYwMDAhDQpbICAxNzkuMTkxMjM3
XSAyZmVjOCBpcyAyODFmNTAwMCENClsgIDE3OS4xOTM2MTZdIDJmZTk4IGlzIDI4MWY0MDAw
IQ0KWyAgMTc5LjE5NjAzNF0gMmZlYzkgaXMgMjgxZjMwMDAhDQpbICAxNzkuMTk4MzUyXSAy
ZmU5OSBpcyAyODFmMjAwMCENClsgIDE3OS4yMDA2NTldIDJmZWNhIGlzIDI4MWYxMDAwIQ0K
WyAgMTc5LjIwMjk0OF0gMmZlOWEgaXMgMjgxZjAwMDAhDQpbICAxNzkuMjEzNTczXSAyZmVj
YiBpcyAyODFlZjAwMCENClsgIDE3OS4yMTU4NjhdIDJmZTliIGlzIDI4MWVlMDAwIQ0KWyAg
MTc5LjIxODE2NF0gMmZlY2MgaXMgMjgxZWQwMDAhDQpbICAxNzkuMjIwNDU4XSAyZmU5YyBp
cyAyODFlYzAwMCENClsgIDE3OS4yMjI3NjFdIDJmZWNkIGlzIDI4MWViMDAwIQ0KWyAgMTc5
LjIyNTIyNV0gMmZlY2UgaXMgMjgxZWEwMDAhDQpbICAxNzkuMjI3NTgyXSAyZmVjZiBpcyAy
ODFlOTAwMCENClsgIDE3OS4yMzQzNjFdIDJmZWQwIGlzIDI4MWU4MDAwIQ0KWyAgMTc5LjIz
NzA5MV0gMmZlOWQgaXMgMjgxZTYwMDAhDQpbICAxNzkuMjM5MzQ4XSAyZmVkMSBpcyAyODFl
NTAwMCENClsgIDE3OS4yNDE1NjFdIDJmZWQyIGlzIDI4MWU0MDAwIQ0KWyAgMTc5LjI0Mzc5
Ml0gMmZlOWUgaXMgMjgxZTMwMDAhDQpbICAxNzkuMjQ2MDI4XSAyZmU5ZiBpcyAyODFlMjAw
MCENClsgIDE3OS4yNDgyODNdIDJmZWQzIGlzIDI4MWUxMDAwIQ0KWyAgMTc5LjI1MDU2MV0g
MmZlZDQgaXMgMjgxZTAwMDAhDQpbICAxNzkuMjUyNzQ3XSAyZmVkNSBpcyAyODFkZjAwMCEN
ClsgIDE3OS4yNTUwMjldIDJmZWQ2IGlzIDI4MWRlMDAwIQ0KWyAgMTc5LjI1NzI2M10gMmZl
ZDcgaXMgMjgxZGQwMDAhDQpbICAxNzkuMjY4MjA5XSAyZmVkOCBpcyAyODFkYzAwMCENClsg
IDE3OS4yNzA0MDhdIDJmZWEwIGlzIDI4MWRiMDAwIQ0KWyAgMTc5LjI3MjY1NV0gMmZlZDkg
aXMgMjgxZGEwMDAhDQpbICAxNzkuMjc1MDQwXSAyZmVkYSBpcyAyODFkOTAwMCENClsgIDE3
OS4yNzcxODZdIDJmZWExIGlzIDI4MWQ4MDAwIQ0KWyAgMTc5LjI3OTM3Nl0gMmZlYTIgaXMg
MjgxZDcwMDAhDQpbICAxNzkuMjgxNTk2XSAyZmVkYiBpcyAyODFkNjAwMCENClsgIDE3OS4y
ODM4NTRdIDJmZWRjIGlzIDI4MWQ1MDAwIQ0KWyAgMTc5LjI4NjAwNV0gMmZlZGQgaXMgMjgx
ZDQwMDAhDQpbICAxNzkuMjg4MjQwXSAyZmVkZSBpcyAyODFkMzAwMCENClsgIDE3OS4yOTAz
ODldIDJmZWRmIGlzIDI4MWQyMDAwIQ0KWyAgMTc5LjI5MjU3MF0gMmZlZTAgaXMgMjgxZDEw
MDAhDQpbICAxNzkuMjk0ODI5XSAyZmVlMSBpcyAyODFkMDAwMCENClsgIDE3OS4yOTY5NTRd
IDJmZWUyIGlzIDI4MWNmMDAwIQ0KWyAgMTc5LjI5OTE4NF0gMmZlZTMgaXMgMjgxY2UwMDAh
DQpbICAxNzkuMzAxMzY5XSAyZmVhMyBpcyAyODFjZDAwMCENClsgIDE3OS4zMDM1MjRdIDJm
ZWU0IGlzIDI4MWNjMDAwIQ0KWyAgMTc5LjMxMTE1MF0gMmZlZTUgaXMgMjgxY2IwMDAhDQpb
ICAxNzkuMzEzMzQzXSAyZmVhNCBpcyAyODFjYTAwMCENClsgIDE3OS4zMTU2NDVdIDJmZWU2
IGlzIDI4MWM5MDAwIQ0KWyAgMTc5LjMxNzkzMV0gMmZlZTcgaXMgMjgxYzgwMDAhDQpbICAx
NzkuMzIwNDEzXSAyZmVlOSBpcyAyODFjNjAwMCENClsgIDE3OS4zMjI1OTddIDJmZWVhIGlz
IDI4MWM1MDAwIQ0KWyAgMTc5LjMyNDY5OF0gMmZlZWIgaXMgMjgxYzQwMDAhDQpbICAxNzku
MzI2ODkyXSAyZmVhNSBpcyAyODFjMzAwMCENClsgIDE3OS4zMjkwMjBdIDJmZWVjIGlzIDI4
MWMyMDAwIQ0KWyAgMTc5LjMzMTIwNl0gMmZlZWQgaXMgMjgxYzEwMDAhDQpbICAxNzkuMzQx
OTAyXSAyZmVlZSBpcyAyODFjMDAwMCENClsgIDE3OS4zNDQxNDldIDJmZWVmIGlzIDI4MWJm
MDAwIQ0KWyAgMTc5LjM0NjQyMV0gMmZlZjAgaXMgMjgxYmUwMDAhDQpbICAxNzkuMzQ4NzAx
XSAyZmVmMSBpcyAyODFiZDAwMCENClsgIDE3OS4zNTA5NDhdIDJmZWYyIGlzIDI4MWJjMDAw
IQ0KWyAgMTc5LjM1MzA3Nl0gMmZlZjMgaXMgMjgxYmIwMDAhDQpbICAxNzkuMzU1NDAwXSAy
ZmVmNCBpcyAyODFiYTAwMCENClsgIDE3OS4zNTc2MjddIDJmZWY1IGlzIDI4MWI5MDAwIQ0K
WyAgMTc5LjM1OTc3Ml0gMmZlZjYgaXMgMjgxYjgwMDAhDQpbICAxNzkuMzYyMDU2XSAyZmVm
NyBpcyAyODFiNzAwMCENClsgIDE3OS4zNjQzMTZdIDJmZWY4IGlzIDI4MWI2MDAwIQ0KWyAg
MTc5LjM2NjQxN10gMmZlZjkgaXMgMjgxYjUwMDAhDQpbICAxNzkuNDEyMzk3XSAyZmVmYSBp
cyAyODFiNDAwMCENClsgIDE3OS40MTQ2MjBdIDJmZWE2IGlzIDI4MWIzMDAwIQ0KWyAgMTc5
LjQxNzExMl0gMmZlZmIgaXMgMjgxYjEwMDAhDQpbICAxNzkuNDE5MjMxXSAyZmVmYyBpcyAy
ODFiMDAwMCENClsgIDE3OS40MjEzNDVdIDJmZWZkIGlzIDI4MWFmMDAwIQ0KWyAgMTc5LjQy
MzUxM10gMmZlYTcgaXMgMjgxYWUwMDAhDQpbICAxNzkuNDI1NjcyXSAyZmVmZSBpcyAyODFh
ZDAwMCENClsgIDE3OS40Mjc4NjFdIDJmZWZmIGlzIDI4MWFjMDAwIQ0KWyAgMTc5LjQzMDAx
NV0gMmZmMDAgaXMgMjgxYWIwMDAhDQpbICAxNzkuNDMyMjEwXSAyZmYwMSBpcyAyODFhYTAw
MCENClsgIDE3OS40MzQ0MDRdIDJmZjAyIGlzIDI4MWE5MDAwIQ0KWyAgMTc5LjQzNjUyM10g
MmZmMDMgaXMgMjgxYTgwMDAhDQpbICAxNzkuNDM4NzE3XSAyZmYwNCBpcyAyODFhNzAwMCEN
ClsgIDE3OS40NDA4ODddIDJmZjA1IGlzIDI4MWE2MDAwIQ0KWyAgMTc5LjQ0MzAyNV0gMmZm
MDYgaXMgMjgxYTUwMDAhDQpbICAxNzkuNDQ1MTk2XSAyZmYwNyBpcyAyODFhNDAwMCENClsg
IDE3OS40NTA0MTFdIDJmZjA4IGlzIDI4MWEzMDAwIQ0KWyAgMTc5LjQ2OTc3M10gMmZmMDkg
aXMgMjgxOTgwMDAhDQpbICAxNzkuNDcxNzM3XSAyZmYwYSBpcyAyODE5OTAwMCENClsgIDE3
OS40NzM0OTddIDJmZjBiIGlzIDI4MTlhMDAwIQ0KWyAgMTc5LjQ3NTI2M10gMmZmMGMgaXMg
MjgxOWIwMDAhDQpbICAxNzkuNDc3MDI5XSAyZmYwZCBpcyAyODE5YzAwMCENClsgIDE3OS40
Nzg3MTFdIDJmZjBlIGlzIDI4MTlkMDAwIQ0KWyAgMTc5LjQ4MDQ0Nl0gMmZmMGYgaXMgMjgx
OWUwMDAhDQpbICAxNzkuNDgyMTMzXSAyZmYxMCBpcyAyODE5ZjAwMCENClsgIDE3OS40ODM4
NzJdIDJmZjExIGlzIDI4MWEwMDAwIQ0KWyAgMTc5LjQ4NTU3M10gMmZmMTIgaXMgMjgxYTEw
MDAhDQpbICAxNzkuNDg3MzEwXSAyZmYxMyBpcyAyODFhMjAwMCENClsgIDE3OS40ODkwNjld
IDJmZjFmIGlzIDI4OTgzMDAwIQ0KWyAgMTc5LjQ5MDgxMF0gMmZmMjAgaXMgMjg5ODQwMDAh
DQpbICAxNzkuNDkyNTY5XSAyZmYyMSBpcyAyODE4NTAwMCENClsgIDE3OS40OTQzMjJdIDJm
ZjIyIGlzIDI4MTg2MDAwIQ0KWyAgMTc5LjQ5NjA3OV0gMmZmMjMgaXMgMjgxODcwMDAhDQpb
ICAxNzkuNDk3ODIzXSAyZmYyNCBpcyAyODE4ODAwMCENClsgIDE3OS40OTk1NDJdIDJmZjI1
IGlzIDI4MTg5MDAwIQ0KWyAgMTc5LjUwMTI5Nl0gMmZmMjYgaXMgMjgxOGEwMDAhDQpbICAx
NzkuNTAzMDE4XSAyZmYyNyBpcyAyODE4YjAwMCENClsgIDE3OS41MDQ3NzVdIDJmZjI4IGlz
IDI4MThjMDAwIQ0KWyAgMTc5LjUwNjg1OF0gMmZmMjkgaXMgMjg5NzgwMDAhDQpbICAxNzku
NTA4NjA1XSAyZmYyYSBpcyAyODk3OTAwMCENClsgIDE3OS41MTAzNDddIDJmZjJiIGlzIDI4
OTdhMDAwIQ0KWyAgMTc5LjUxMjA3MF0gMmZmMmMgaXMgMjg5N2IwMDAhDQpbICAxNzkuNTEz
ODIwXSAyZmYyZCBpcyAyODk3YzAwMCENClsgIDE3OS41MTU1MzFdIDJmZjJlIGlzIDI4OTdk
MDAwIQ0KWyAgMTc5LjUxNzI4MF0gMmZmMmYgaXMgMjg5N2UwMDAhDQpbICAxNzkuNTE4OTg3
XSAyZmYzMCBpcyAyODk3ZjAwMCENClsgIDE3OS41MjA3NjNdIDJmZjMxIGlzIDI4OTgwMDAw
IQ0KWyAgMTc5LjUyMjQ5MV0gMmZmMzIgaXMgMjg5ODEwMDAhDQpbICAxNzkuNTI0MjE1XSAy
ZmYzMyBpcyAyODk4MjAwMCENClsgIDE3OS41MjU5NDRdIDJmZjM0IGlzIDI4OTZkMDAwIQ0K
WyAgMTc5LjUyNzY2MV0gMmZmMzUgaXMgMjg5NmUwMDAhDQpbICAxNzkuNTI5NDE2XSAyZmYz
NiBpcyAyODk2ZjAwMCENClsgIDE3OS41MzExMzJdIDJmZjM3IGlzIDI4OTcwMDAwIQ0KWyAg
MTc5LjUzMjg0NV0gMmZmMzggaXMgMjg5NzEwMDAhDQpbICAxNzkuNTM0NTk4XSAyZmYzOSBp
cyAyODk3MjAwMCENClsgIDE3OS41MzYzMDVdIDJmZjNhIGlzIDI4OTczMDAwIQ0KWyAgMTc5
LjUzODA0N10gMmZmM2IgaXMgMjg5NzQwMDAhDQpbICAxNzkuNTM5NzQyXSAyZmYzYyBpcyAy
ODk3NTAwMCENClsgIDE3OS41NDE0NzZdIDJmZjNkIGlzIDI4OTc2MDAwIQ0KWyAgMTc5LjU0
MzE3N10gMmZmM2UgaXMgMjg5NzcwMDAhDQpbICAxNzkuNTQ0ODc2XSAyZmYzZiBpcyAyODk2
MzAwMCENClsgIDE3OS41NDY1NzRdIDJmZjQwIGlzIDI4OTY0MDAwIQ0KWyAgMTc5LjU0ODI1
NV0gMmZmNDEgaXMgMjg5NjUwMDAhDQpbICAxNzkuNTQ5OTQ4XSAyZmY0MiBpcyAyODk2NjAw
MCENClsgIDE3OS41NTE2MjldIDJmZjQzIGlzIDI4OTY3MDAwIQ0KWyAgMTc5LjU1MzMwMl0g
MmZmNDQgaXMgMjg5NjgwMDAhDQpbICAxNzkuNTU1MDE0XSAyZmY0NSBpcyAyODk2OTAwMCEN
ClsgIDE3OS41NTY2NzVdIDJmZjQ2IGlzIDI4OTZhMDAwIQ0KWyAgMTc5LjU1ODM3Nl0gMmZm
NDcgaXMgMjg5NmIwMDAhDQpbICAxNzkuNTYwMDMxXSAyZmY0OCBpcyAyODk2YzAwMCENClsg
IDE3OS41NjE2OTVdIDJmZjE0IGlzIDI4MThkMDAwIQ0KWyAgMTc5LjU2MzQwMl0gMmZmMTUg
aXMgMjgxOGUwMDAhDQpbICAxNzkuNTY1MDY0XSAyZmYxNiBpcyAyODE4ZjAwMCENClsgIDE3
OS41NjY3NjRdIDJmZjE3IGlzIDI4MTkwMDAwIQ0KWyAgMTc5LjU2ODQyNl0gMmZmMTggaXMg
MjgxOTEwMDAhDQpbICAxNzkuNTcwMTAzXSAyZmYxOSBpcyAyODE5MjAwMCENClsgIDE3OS41
NzE3OTZdIDJmZjFhIGlzIDI4MTkzMDAwIQ0KWyAgMTc5LjU3MzQ3N10gMmZmMWIgaXMgMjgx
OTQwMDAhDQpbICAxNzkuNTc1MTU4XSAyZmYxYyBpcyAyODE5NTAwMCENClsgIDE3OS41NzY4
MjddIDJmZjFkIGlzIDI4MTk2MDAwIQ0KWyAgMTc5LjU3ODQ4Ml0gMmZmMWUgaXMgMjgxOTcw
MDAhDQpbICAxNzkuNTkzODcxXSAyZmY0OSBpcyAyODk1ODAwMCENClsgIDE3OS41OTU1NzNd
IDJmZjRjIGlzIDI4OTU5MDAwIQ0KWyAgMTc5LjU5NzI2M10gMmZmNGQgaXMgMjg5NWEwMDAh
DQpbICAxNzkuNTk4OTEzXSAyZmY0ZSBpcyAyODk1YjAwMCENClsgIDE3OS42MDA2MDVdIDJm
ZjRmIGlzIDI4OTVjMDAwIQ0KWyAgMTc5LjYwMjI5MV0gMmZmNTAgaXMgMjg5NWQwMDAhDQpb
ICAxNzkuNjA0MDAwXSAyZmY1MSBpcyAyODk1ZTAwMCENClsgIDE3OS42MDU2NjRdIDJmZjUy
IGlzIDI4OTVmMDAwIQ0KWyAgMTc5LjYwNzM0OF0gMmZmNTMgaXMgMjg5NjAwMDAhDQpbICAx
NzkuNjA5MDQzXSAyZmY1NCBpcyAyODk2MTAwMCENClsgIDE3OS42MTA3MjddIDJmZjU1IGlz
IDI4OTYyMDAwIQ0KWyAgMTc5LjYxMjQyNV0gMmZmNTYgaXMgMjg5NGQwMDAhDQpbICAxNzku
NjE0MTE1XSAyZmY1NyBpcyAyODk0ZTAwMCENClsgIDE3OS42MTU3ODNdIDJmZjU4IGlzIDI4
OTRmMDAwIQ0KWyAgMTc5LjYxNzQ5Ml0gMmZmNTkgaXMgMjg5NTAwMDAhDQpbICAxNzkuNjE5
MTYwXSAyZmY1YSBpcyAyODk1MTAwMCENClsgIDE3OS42MjA4NzBdIDJmZjViIGlzIDI4OTUy
MDAwIQ0KWyAgMTc5LjYyMjUzOF0gMmZmNWMgaXMgMjg5NTMwMDAhDQpbICAxNzkuNjI0MjIz
XSAyZmY1ZCBpcyAyODk1NDAwMCENClsgIDE3OS42MjU5MjNdIDJmZjVlIGlzIDI4OTU1MDAw
IQ0KWyAgMTc5LjYyNzU5NV0gMmZmNWYgaXMgMjg5NTYwMDAhDQpbICAxNzkuNjI5MjY2XSAy
ZmY2MCBpcyAyODk1NzAwMCENClsgIDE3OS42MzA5MjRdIDJmZjYxIGlzIDI4OTQzMDAwIQ0K
WyAgMTc5LjYzMjU4MF0gMmZmNjIgaXMgMjg5NDQwMDAhDQpbICAxNzkuNjM0Mjc4XSAyZmY2
MyBpcyAyODk0NTAwMCENClsgIDE3OS42MzU5NDFdIDJmZjY0IGlzIDI4OTQ2MDAwIQ0KWyAg
MTc5LjYzNzYzNV0gMmZmNjUgaXMgMjg5NDcwMDAhDQpbICAxNzkuNjM5MjkxXSAyZmY2NiBp
cyAyODk0ODAwMCENClsgIDE3OS42NDA5NjFdIDJmZjY3IGlzIDI4OTQ5MDAwIQ0KWyAgMTc5
LjY0MjY0MV0gMmZmNjggaXMgMjg5NGEwMDAhDQpbICAxNzkuNjQ0MzA1XSAyZmY2OSBpcyAy
ODk0YjAwMCENClsgIDE3OS42NDU5ODFdIDJmZjZhIGlzIDI4OTRjMDAwIQ0KWyAgMTc5LjY0
NzcyNV0gMmZmNmIgaXMgMjg5NDIwMDAhDQpbICAxNzkuNjcyNDE4XSAyZmVhOCBpcyAyODk0
MTAwMCENClsgIDE3OS42NzcyMDRdIDJmZWE5IGlzIDI4OTQwMDAwIQ0KWyAgMTc5LjY4Mjg5
Ml0gMmZmNmMgaXMgMjg5M2YwMDAhDQpbICAxNzkuNjg2MTA0XSAyZmY2ZCBpcyAyODkzZTAw
MCENClsgIDE3OS42ODgzMzhdIDJmZjZlIGlzIDI4OTNkMDAwIQ0KWyAgMTc5LjY5NzUwNV0g
MmZmNmYgaXMgMjg5M2MwMDAhDQpbICAxNzkuNzAyNzcxXSAyZmY3MCBpcyAyODkzYjAwMCEN
ClsgIDE3OS43MDQ5MjhdIDJmZjcxIGlzIDI4OTNhMDAwIQ0KWyAgMTc5LjcxNDIzMF0gMmZm
NzIgaXMgMjg5MzkwMDAhDQpbICAxNzkuNzI2NDAwXSAyZmY3MyBpcyAyODkzODAwMCENClsg
IDE3OS43Mjg4NjNdIDJmZjc0IGlzIDI4OTM3MDAwIQ0KWyAgMTc5LjczMzQ2N10gMmZmNzUg
aXMgMjg5MzYwMDAhDQpbICAxNzkuNzM4ODA1XSAyZmY3NiBpcyAyODkzNTAwMCENClsgIDE3
OS43NTMwMjRdIDJmZWFhIGlzIDI4OTM0MDAwIQ0KWyAgMTc5Ljc3MjUwNV0gMmZlYWIgaXMg
Mjg5MzMwMDAhDQpbICAxNzkuNzc0NzgzXSAyZmY3NyBpcyAyODkzMjAwMCENClsgIDE3OS43
ODE5NjFdIDJmZjc5IGlzIDI4OTMxMDAwIQ0KWyAgMTc5Ljc4NjI4OF0gMmZmN2EgaXMgMjg5
MzAwMDAhDQpbICAxNzkuNzkxOTY5XSAyZmY3YiBpcyAyODkyZjAwMCENClsgIDE3OS43OTUz
MjFdIDJmZjdjIGlzIDI4OTJlMDAwIQ0KWyAgMTc5Ljc5NzYwNF0gMmZmN2QgaXMgMjg5MmQw
MDAhDQpbICAxNzkuODA1MTUwXSAyZmY3ZSBpcyAyODkyYzAwMCENClsgIDE3OS44MTY4NDBd
IDJmZjdmIGlzIDI4OTJiMDAwIQ0KWyAgMTc5LjgzMDUwOF0gMmZmODAgaXMgMjg5MmEwMDAh
DQpbICAxNzkuODMzODUxXSAyZmY4MSBpcyAyODkyOTAwMCENClsgIDE3OS44NDE0OTldIDJm
ZjgyIGlzIDI4OTI4MDAwIQ0KWyAgMTc5Ljg0Nzk0OF0gMmZmODMgaXMgMjg5MjcwMDAhDQpb
ICAxNzkuODUyOTUwXSAyZmY4NCBpcyAyODkyNjAwMCENClsgIDE3OS44NTYyODZdIDJmZjg1
IGlzIDI4OTI1MDAwIQ0KWyAgMTc5Ljg3NzQ3NV0gMmZmODYgaXMgMjg5MjQwMDAhDQpbICAx
NzkuODgwNzA5XSAyZmY4NyBpcyAyODkyMzAwMCENClsgIDE3OS44OTQ2MzhdIDJmZjg4IGlz
IDI4OTIyMDAwIQ0KWyAgMTc5Ljg5NjkwOF0gMmZmODkgaXMgMjg5MjEwMDAhDQpbICAxNzku
ODk5MTU0XSAyZmY4YSBpcyAyODkyMDAwMCENClsgIDE3OS45MDEzMjddIDJmZjhiIGlzIDI4
OTFmMDAwIQ0KWyAgMTc5LjkwMzU1N10gMzc2N2QgaXMgMjg5MWUwMDAhDQpbICAxNzkuOTA1
NzczXSAyZmY4ZCBpcyAyODkxZDAwMCENClsgIDE3OS45MTQwNjRdIDJmZjhlIGlzIDI4OTFj
MDAwIQ0KWyAgMTc5LjkxNjMxM10gMmZmNzggaXMgMjg5MWIwMDAhDQpbICAxNzkuOTE4NTIx
XSAyZmY4ZiBpcyAyODkxYTAwMCENClsgIDE3OS45MjA3NTRdIDM3ODExIGlzIDI4OTE5MDAw
IQ0KWyAgMTc5LjkyMzAxMF0gMmZlYWMgaXMgMjg5MTgwMDAhDQpbICAxNzkuOTI1Mjg3XSAy
ZmY5MCBpcyAyODkxNzAwMCENClsgIDE3OS45Mjc1NTZdIDJmZWFkIGlzIDI4OTE2MDAwIQ0K
WyAgMTc5LjkzODMzNl0gMmZlYWUgaXMgMjg5MTUwMDAhDQpbICAxNzkuOTQ2NDI3XSAyZmY5
MSBpcyAyODkxNDAwMCENClsgIDE3OS45NDg4NTRdIDJmZjkyIGlzIDI4OTEzMDAwIQ0KWyAg
MTc5Ljk1MTI2Ml0gMmZmOTMgaXMgMjg5MTIwMDAhDQpbICAxNzkuOTUzNTE3XSAyZmY5NCBp
cyAyODkxMTAwMCENClsgIDE3OS45NTU4ODVdIDJmZjk1IGlzIDI4OTEwMDAwIQ0KWyAgMTc5
Ljk1ODE4NF0gMmZmYWEgaXMgMjg5MGYwMDAhDQpbICAxNzkuOTYwNDUwXSAyZmY5NiBpcyAy
ODkwZTAwMCENClsgIDE3OS45NjI3NTFdIDJmZmFiIGlzIDI4OTBkMDAwIQ0KWyAgMTc5Ljk2
NTAwOV0gMmZmOTcgaXMgMjg5MGMwMDAhDQpbICAxNzkuOTY3Mjk0XSAyZmZhYyBpcyAyODkw
YjAwMCENClsgIDE3OS45NzIwODJdIDJmZmFkIGlzIDI4OTBhMDAwIQ0KWyAgMTc5Ljk3NDQw
Ml0gMmZmOTggaXMgMjg5MDkwMDAhDQpbICAxNzkuOTc2NjQ3XSAyZmY5OSBpcyAyODkwODAw
MCENClsgIDE3OS45NzkwNTRdIDJmZjlhIGlzIDI4OTA3MDAwIQ0KWyAgMTc5Ljk4MTM2MF0g
MmZmOWIgaXMgMjg5MDYwMDAhDQpbICAxNzkuOTgzNTg4XSAyZmY5YyBpcyAyODkwNTAwMFsg
IDE4Mi4xMjI2NTFdIDJmYTRiIGlzIDI4NWFmMDAwIQ0KWyAgMTgyLjEyNDkwNF0gMmZhNGMg
aXMgMjg1YjAwMDAhDQpbICAxODIuMTI3MTA2XSAyZmE1YyBpcyAyODViMTAwMCENClsgIDE4
Mi4xMjkzNjBdIDJmYTVkIGlzIDI4NWIyMDAwIQ0KWyAgMTgyLjEzMTU2NF0gMmZhNGQgaXMg
Mjg1YjMwMDAhDQpbICAxODIuMTMzNzU4XSAyZmE1ZSBpcyAyODViYTAwMCENClsgIDE4Mi4x
MzU5NTVdIDJmYTVmIGlzIDI4NWNlMDAwIQ0KWyAgMTgyLjEzODIyNl0gMmZhNGUgaXMgMjg1
Y2YwMDAhDQpbICAxODIuMTQwNDIzXSAyZmE0ZiBpcyAyODVjZDAwMCENClsgIDE4Mi4xNDI2
MzVdIDJmYTUwIGlzIDI4NWNjMDAwIQ0KWyAgMTgyLjE0NDk3Nl0gMmZhNTEgaXMgMjg1ZDIw
MDAhDQpbICAxODIuMTQ3MjcwXSAyZmE1MiBpcyAyODVkMzAwMCENClsgIDE4Mi4xNDk0MzRd
IDJmYTUzIGlzIDI4NWQ0MDAwIQ0KWyAgMTgyLjE1MTcxN10gMmZhNTQgaXMgMjg1ZDUwMDAh
DQpbICAxODIuMTUzOTEzXSAyZmE1NSBpcyAyODVjNTAwMCENClsgIDE4Mi4xNTYwNDNdIDJm
YTU2IGlzIDI4NWJmMDAwIQ0KWyAgMTgyLjE2NjczMl0gMmZhNzYgaXMgMjg1ZDEwMDAhDQpb
ICAxODIuMTY4ODk0XSAyZmE2MCBpcyAyODViZDAwMCENClsgIDE4Mi4xNzEyNDddIDJmYTc3
IGlzIDI4NWI5MDAwIQ0KWyAgMTgyLjE3Mzc4NV0gMmZhNzggaXMgMjg1YjUwMDAhDQpbICAx
ODIuMTc1OTY3XSAyZmE3OSBpcyAyODViZTAwMCENClsgIDE4Mi4xNzgwOTldIDJmYTdhIGlz
IDI4NWQwMDAwIQ0KWyAgMTgyLjE4MDIyNF0gMmZhNjEgaXMgMjg1YmIwMDAhDQpbICAxODIu
MTgyNDY4XSAyZmE3YiBpcyAyODViYzAwMCENClsgIDE4Mi4xODQ2NjNdIDJmYTYyIGlzIDI4
NzBmMDAwIQ0KWyAgMTgyLjE4Njg2MV0gMmZhN2MgaXMgMjg1YzcwMDAhDQpbICAxODIuMTg5
MDc2XSAyZmE3ZCBpcyAyODVjODAwMCENClsgIDE4Mi4xOTEyMzhdIDJmYTdlIGlzIDI4NWM2
MDAwIQ0KWyAgMTgyLjE5MzQ4NV0gMmZhNjMgaXMgMjg3MWQwMDAhDQpbICAxODIuMjAyMzg1
XSAyZmE4MCBpcyAyODM4MDAwMCENClsgIDE4Mi4yMDQ3MDRdIDJmYTgxIGlzIDI4NWI4MDAw
IQ0KWyAgMTgyLjIwNjk1OF0gMmZhODIgaXMgMjgzODEwMDAhDQpbICAxODIuMjA5MzAzXSAy
ZmE4MyBpcyAyODE0YjAwMCENClsgIDE4Mi4yMTE1NDhdIDJmYTdmIGlzIDI4NzFmMDAwIQ0K
WyAgMTgyLjIxODg3NF0gMmZhODQgaXMgMjg1YTIwMDAhDQpbICAxODIuMjI1NTkzXSAyZmE2
NCBpcyAyODVhMTAwMCENClsgIDE4Mi4yMjc4NjldIDJmYTY1IGlzIDI4NWM0MDAwIQ0KWyAg
MTgyLjIzMDIwNV0gMmZhNjYgaXMgMjg1YzMwMDAhDQpbICAxODIuMjMyNDkyXSAyZmE4NSBp
cyAyODVjMjAwMCENClsgIDE4Mi4yMzQ3OTJdIDJmYTg2IGlzIDI4NWMxMDAwIQ0KWyAgMTgy
LjIzNzEwNV0gMmZhNjcgaXMgMjg1YTAwMDAhDQpbICAxODIuMjQ3OTI0XSAyZmE4NyBpcyAy
ODU5ZjAwMCENClsgIDE4Mi4yNTAyODRdIDJmYTg4IGlzIDI4NTllMDAwIQ0KWyAgMTgyLjI1
MjY2N10gMmZhODkgaXMgMjg1OWQwMDAhDQpbICAxODIuMjU0OTgwXSAyZmE2OCBpcyAyODU5
YzAwMCENClsgIDE4Mi4yNTcyNDJdIDJmYThhIGlzIDI4NTliMDAwIQ0KWyAgMTgyLjI1OTU2
OF0gMmZhNjkgaXMgMjg1OWEwMDAhDQpbICAxODIuMjYyMjEzXSAyZmE4YiBpcyAyODU5ODAw
MCENClsgIDE4Mi4yNjQ0OTZdIDJmYTZiIGlzIDI4NTk3MDAwIQ0KWyAgMTgyLjI2Njg1NF0g
MmZhNmMgaXMgMjg1OTYwMDAhDQpbICAxODIuMjY5MTI4XSAyZmE4YyBpcyAyODU5NTAwMCEN
ClsgIDE4Mi4yNzE0NDddIDJmYThkIGlzIDI4NTk0MDAwIQ0KWyAgMTgyLjI4MTQ0NF0gMmZh
OGUgaXMgMjg1OTMwMDAhDQpbICAxODIuMzEwODQ2XSAyZmE4ZiBpcyAyODU5MjAwMCENClsg
IDE4Mi4zMTMxNDBdIDJmYTZkIGlzIDI4NTkxMDAwIQ0KWyAgMTgyLjMxNTU0NF0gMmZhOTAg
aXMgMjg1OTAwMDAhDQpbICAxODIuMzE3OTA0XSAyZmE5MSBpcyAyODU4ZjAwMCENClsgIDE4
Mi4zMjA1MjddIDJmYTkyIGlzIDI4NThkMDAwIQ0KWyAgMTgyLjMyMjc3NF0gMmZhOTMgaXMg
Mjg1OGMwMDAhDQpbICAxODIuMzMwMzE0XSAyZmE5NCBpcyAyODU4YjAwMCENClsgIDE4Mi4z
MzI1MzhdIDJmYTZlIGlzIDI4NThhMDAwIQ0KWyAgMTgyLjMzNDc1Ml0gMmZhOTUgaXMgMjg1
ODkwMDAhDQpbICAxODIuMzM2OTA1XSAyZmE2ZiBpcyAyODU4ODAwMCENClsgIDE4Mi4zMzkx
OTFdIDJmYTk2IGlzIDI4NTg3MDAwIQ0KWyAgMTgyLjM0MTQxNF0gMmZhNzAgaXMgMjg1ODYw
MDAhDQpbICAxODIuMzQzNjY4XSAyZmE5NyBpcyAyODU4NTAwMCENClsgIDE4Mi4zNDU5MTld
IDJmYTk4IGlzIDI4ZDg0MDAwIQ0KWyAgMTgyLjM0ODEwMF0gMmZhNzEgaXMgMjhkODMwMDAh
DQpbICAxODIuMzUwMjkxXSAyZmE5OSBpcyAyOGQ4MjAwMCENClsgIDE4Mi4zNTI1NDldIDJm
YTlhIGlzIDI4ZDgxMDAwIQ0KWyAgMTgyLjM1NDc1NV0gMmZhNzIgaXMgMjhkODAwMDAhDQpb
ICAxODIuMzU2ODYzXSAyZmE5YiBpcyAyOGQ3ZjAwMCENClsgIDE4Mi4zOTM1OTNdIDJmYTlj
IGlzIDI4ZDdlMDAwIQ0KWyAgMTgyLjM5NTgwMl0gMmZhNzMgaXMgMjhkN2QwMDAhDQpbICAx
ODIuMzk3OTYwXSAyZmE5ZCBpcyAyOGQ3YzAwMCENClsgIDE4Mi40MDAyMDFdIDJmYTc0IGlz
IDI4ZDdiMDAwIQ0KWyAgMTgyLjQwMjM5NF0gMmZhOWUgaXMgMjhkN2EwMDAhDQpbICAxODIu
NDA0NjA3XSAyZmE5ZiBpcyAyOGQ3OTAwMCENClsgIDE4Mi40MDY4MzZdIDJmYTc1IGlzIDI4
ZDc4MDAwIQ0KWyAgMTgyLjQwOTAzOV0gMmZhYTAgaXMgMjhkNzcwMDAhDQpbICAxODIuNDEx
Mjc1XSAyZmFhMSBpcyAyOGQ3NjAwMCENClsgIDE4Mi40MTM1MjBdIDJmYWEyIGlzIDI4ZDc1
MDAwIQ0KWyAgMTgyLjQxNTcxM10gMmZhYTMgaXMgMjhkNzQwMDAhDQpbICAxODIuNDE3OTcz
XSAyZmFhNCBpcyAyOGQ3MzAwMCENClsgIDE4Mi40MjAyMDRdIDJmYWE1IGlzIDI4ZDcyMDAw
IQ0KWyAgMTgyLjQyMjM4NV0gMmZhYTYgaXMgMjhkNzEwMDAhDQpbICAxODIuNDM5Mzc1XSAy
ZmFhNyBpcyAyOGQ2NjAwMCENClsgIDE4Mi40NDEzNjhdIDJmYWE4IGlzIDI4ZDY3MDAwIQ0K
WyAgMTgyLjQ0MzIwMl0gMmZhYTkgaXMgMjhkNjgwMDAhDQpbICAxODIuNDQ1MDg2XSAyZmFh
YSBpcyAyOGQ2OTAwMCENClsgIDE4Mi40NDY4NjBdIDJmYWFiIGlzIDI4ZDZhMDAwIQ0KWyAg
MTgyLjQ0ODYxMl0gMmZhYWMgaXMgMjhkNmIwMDAhDQpbICAxODIuNDUwNDExXSAyZmFhZCBp
cyAyOGQ2YzAwMCENClsgIDE4Mi40NTIxNDldIDJmYWFlIGlzIDI4ZDZkMDAwIQ0KWyAgMTgy
LjQ1MzkyN10gMmZhYWYgaXMgMjhkNmUwMDAhDQpbICAxODIuNDU1NjU1XSAyZmFiMCBpcyAy
OGQ2ZjAwMCENClsgIDE4Mi40NTc0MjJdIDJmYWIxIGlzIDI4ZDcwMDAwIQ0KWyAgMTgyLjQ1
OTIwM10gMmZhYjIgaXMgMjhkNWIwMDAhDQpbICAxODIuNDYwOTYxXSAyZmFiMyBpcyAyOGQ1
YzAwMCENClsgIDE4Mi40NjI3MDldIDJmYWI0IGlzIDI4ZDVkMDAwIQ0KWyAgMTgyLjQ2NDQ0
MV0gMmZhYjUgaXMgMjhkNWUwMDAhDQpbICAxODIuNDY2MTY3XSAyZmFiNiBpcyAyOGQ1ZjAw
MCENClsgIDE4Mi40Njc4OTFdIDJmYWI3IGlzIDI4ZDYwMDAwIQ0KWyAgMTgyLjQ2OTU5MV0g
MmZhYjggaXMgMjhkNjEwMDAhDQpbICAxODIuNDcxMzE1XSAyZmFiOSBpcyAyOGQ2MjAwMCEN
ClsgIDE4Mi40NzMwMDJdIDJmYWJhIGlzIDI4ZDYzMDAwIQ0KWyAgMTgyLjQ3NDcyMl0gMmZh
YmIgaXMgMjhkNjQwMDAhDQpbICAxODIuNDc2MzgwXSAyZmFiYyBpcyAyOGQ2NTAwMCENClsg
IDE4Mi40Nzg0NDVdIDJmYWJkIGlzIDI4ZDUxMDAwIQ0KWyAgMTgyLjQ4MDE0Nl0gMmZhYmUg
aXMgMjhkNTIwMDAhDQpbICAxODIuNDgxNzk5XSAyZmFiZiBpcyAyOGQ1MzAwMCENClsgIDE4
Mi40ODM0OTldIDJmYWMwIGlzIDI4ZDU0MDAwIQ0KWyAgMTgyLjQ4NTE0MF0gMmZhYzEgaXMg
MjhkNTUwMDAhDQpbICAxODIuNDg2ODI0XSAyZmFjMiBpcyAyOGQ1NjAwMCENClsgIDE4Mi40
ODg0NjZdIDJmYWMzIGlzIDI4ZDU3MDAwIQ0KWyAgMTgyLjQ5MDEzN10gMmZhYzQgaXMgMjhk
NTgwMDAhDQpbICAxODIuNDkxODEwXSAyZmFjNSBpcyAyOGQ1OTAwMCENClsgIDE4Mi40OTM0
NzVdIDJmYWM2IGlzIDI4ZDVhMDAwIQ0KWyAgMTgyLjQ5NTE0OF0gMmZhYzcgaXMgMjhkNDYw
MDAhDQpbICAxODIuNDk2ODE4XSAyZmFjOCBpcyAyOGQ0NzAwMCENClsgIDE4Mi40OTg0NjVd
IDJmYWM5IGlzIDI4ZDQ4MDAwIQ0KWyAgMTgyLjUwMDE1N10gMmZhY2EgaXMgMjhkNDkwMDAh
DQpbICAxODIuNTAxODE2XSAyZmFjYiBpcyAyOGQ0YTAwMCENClsgIDE4Mi41MDM1MThdIDJm
YWNjIGlzIDI4ZDRiMDAwIQ0KWyAgMTgyLjUwNTE2OV0gMmZhY2QgaXMgMjhkNGMwMDAhDQpb
ICAxODIuNTA2ODQwXSAyZmFjZSBpcyAyOGQ0ZDAwMCENClsgIDE4Mi41MDg1MjBdIDJmYWNm
IGlzIDI4ZDRlMDAwIQ0KWyAgMTgyLjUxMDE4Ml0gMmZhZDAgaXMgMjhkNGYwMDAhDQpbICAx
ODIuNTExODUxXSAyZmFkMSBpcyAyOGQ1MDAwMCENClsgIDE4Mi41MTM1MDldIDJmYWQyIGlz
IDI4ZDNiMDAwIQ0KWyAgMTgyLjUxNTE1Ml0gMmZhZDMgaXMgMjhkM2MwMDAhDQpbICAxODIu
NTE2ODM5XSAyZmFkNCBpcyAyOGQzZDAwMCENClsgIDE4Mi41MTg0ODNdIDJmYWQ1IGlzIDI4
ZDNlMDAwIQ0KWyAgMTgyLjUyMDE2N10gMmZhZDYgaXMgMjhkM2YwMDAhDQpbICAxODIuNTIx
ODExXSAyZmFkNyBpcyAyOGQ0MDAwMCENClsgIDE4Mi41MjM0ODZdIDJmYWQ4IGlzIDI4ZDQx
MDAwIQ0KWyAgMTgyLjUyNTE2N10gMmZhZDkgaXMgMjhkNDIwMDAhDQpbICAxODIuNTI2ODM1
XSAyZmFkYSBpcyAyOGQ0MzAwMCENClsgIDE4Mi41Mjg1MjJdIDJmYWRiIGlzIDI4ZDQ0MDAw
IQ0KWyAgMTgyLjUzMDE5OV0gMmZhZGMgaXMgMjhkNDUwMDAhDQpbICAxODIuNTMxODYxXSAy
ZmFkZCBpcyAyOGQzMTAwMCENClsgIDE4Mi41MzM1NjddIDJmYWRlIGlzIDI4ZDMyMDAwIQ0K
WyAgMTgyLjUzNTIyOF0gMmZhZGYgaXMgMjhkMzMwMDAhDQpbICAxODIuNTM2OTMzXSAyZmFl
MCBpcyAyOGQzNDAwMCENClsgIDE4Mi41Mzg2MDddIDJmYWUxIGlzIDI4ZDM1MDAwIQ0KWyAg
MTgyLjU0MDI5NF0gMmZhZTIgaXMgMjhkMzYwMDAhDQpbICAxODIuNTQxOTk3XSAyZmFlMyBp
cyAyOGQzNzAwMCENClsgIDE4Mi41NDM2NzhdIDJmYWU0IGlzIDI4ZDM4MDAwIQ0KWyAgMTgy
LjU0NTM3MF0gMmZhZTUgaXMgMjhkMzkwMDAhDQpbICAxODIuNTQ3MDQ1XSAyZmFlNiBpcyAy
OGQzYTAwMCENClsgIDE4Mi41NTAzMzNdIDJmYWZmIGlzIDI4ZDExMDAwIQ0KWyAgMTgyLjU1
MjA2M10gMmZiMDAgaXMgMjhkMTIwMDAhDQpbICAxODIuNTUzODExXSAyZmIwMSBpcyAyOGQx
MzAwMCENClsgIDE4Mi41NTU0OTVdIDJmYjAyIGlzIDI4ZDE0MDAwIQ0KWyAgMTgyLjU1NzE5
OF0gMmZiMDMgaXMgMjhkMTUwMDAhDQpbICAxODIuNTU4ODk5XSAyZmIwNCBpcyAyOGQxNjAw
MCENClsgIDE4Mi41NjA1OTddIDJmYjA1IGlzIDI4ZDE3MDAwIQ0KWyAgMTgyLjU2MjMwM10g
MmZiMDYgaXMgMjhkMTgwMDAhDQpbICAxODIuNTYzOTk4XSAyZmIwNyBpcyAyOGQxOTAwMCEN
ClsgIDE4Mi41NjU2ODldIDJmYjA4IGlzIDI4ZDFhMDAwIQ0KWyAgMTgyLjU2NzM3M10gMmZh
ZTcgaXMgMjhkMjYwMDAhDQpbICAxODIuNTY5MDY4XSAyZmFlOCBpcyAyOGQyNzAwMCENClsg
IDE4Mi41NzA3NjZdIDJmYWU5IGlzIDI4ZDI4MDAwIQ0KWyAgMTgyLjU3MjQzMl0gMmZhZWEg
aXMgMjhkMjkwMDAhDQpbICAxODIuNTc0MTI4XSAyZmFlYiBpcyAyOGQyYTAwMCENClsgIDE4
Mi41NzU3ODhdIDJmYWVjIGlzIDI4ZDJiMDAwIQ0KWyAgMTgyLjU3NzQ1Ml0gMmZhZWQgaXMg
MjhkMmMwMDAhDQpbICAxODIuNTc5MTE5XSAyZmFlZSBpcyAyOGQyZDAwMCENClsgIDE4Mi41
ODA3ODNdIDJmYWVmIGlzIDI4ZDJlMDAwIQ0KWyAgMTgyLjU4MjQ1M10gMmZhZjAgaXMgMjhk
MmYwMDAhDQpbICAxODIuNTg0MTI1XSAyZmFmMSBpcyAyOGQzMDAwMCENClsgIDE4Mi41ODU3
ODBdIDJmYWY0IGlzIDI4ZDFiMDAwIQ0KWyAgMTgyLjU4NzQ2N10gMmZhZjUgaXMgMjhkMWMw
MDAhDQpbICAxODIuNTg5MTI4XSAyZmFmNiBpcyAyOGQxZDAwMCENClsgIDE4Mi41OTA4MThd
IDJmYWY3IGlzIDI4ZDFlMDAwIQ0KWyAgMTgyLjU5MjQ3M10gMmZhZjggaXMgMjhkMWYwMDAh
DQpbICAxODIuNTk0MTQzXSAyZmFmOSBpcyAyOGQyMDAwMCENClsgIDE4Mi41OTU4MTZdIDJm
YWZhIGlzIDI4ZDIxMDAwIQ0KWyAgMTgyLjU5NzQ4Nl0gMmZhZmIgaXMgMjhkMjIwMDAhDQpb
ICAxODIuNTk5MTUwXSAyZmFmYyBpcyAyOGQyMzAwMCENClsgIDE4Mi42MDA4MjRdIDJmYWZk
IGlzIDI4ZDI0MDAwIQ0KWyAgMTgyLjYwMjQ5MV0gMmZhZmUgaXMgMjhkMjUwMDAhDQpbICAx
ODIuNjA1MTUwXSAyZmIxNCBpcyAyOGNmYjAwMCENClsgIDE4Mi42MDY4NjJdIDJmYjE1IGlz
IDI4Y2ZjMDAwIQ0KWyAgMTgyLjYwODU3N10gMmZiMTYgaXMgMjhjZmQwMDAhDQpbICAxODIu
NjEwMjc5XSAyZmIxNyBpcyAyOGNmZTAwMCENClsgIDE4Mi42MTIwMzldIDJmYjE4IGlzIDI4
Y2ZmMDAwIQ0KWyAgMTgyLjYxMzgwN10gMmZiMTkgaXMgMjhkMDAwMDAhDQpbICAxODIuNjE1
NTM5XSAyZmIxYSBpcyAyOGQwMTAwMCENClsgIDE4Mi42MTcyNDddIDJmYjFiIGlzIDI4ZDAy
MDAwIQ0KWyAgMTgyLjYxODk0M10gMmZiMWMgaXMgMjhkMDMwMDAhDQpbICAxODIuNjIwNjc1
XSAyZmIxZCBpcyAyOGQwNDAwMCENClsgIDE4Mi42MjIzNjNdIDJmYjFlIGlzIDI4ZDA1MDAw
IQ0KWyAgMTgyLjYyNDA3N10gMmZiMWYgaXMgMjhjZjEwMDAhDQpbICAxODIuNjI1Nzg1XSAy
ZmIyMCBpcyAyOGNmMjAwMCENClsgIDE4Mi42Mjc0OTFdIDJmYjIxIGlzIDI4Y2YzMDAwIQ0K
WyAgMTgyLjYyOTIyOF0gMmZiMjIgaXMgMjhjZjQwMDAhDQpbICAxODIuNjMwOTM0XSAyZmIy
MyBpcyAyOGNmNTAwMCENClsgIDE4Mi42MzI2NTRdIDJmYjI0IGlzIDI4Y2Y2MDAwIQ0KWyAg
MTgyLjYzNDM1OF0gMmZiMjUgaXMgMjhjZjcwMDAhDQpbICAxODIuNjM2MDM2XSAyZmIyNiBp
cyAyOGNmODAwMCENClsgIDE4Mi42Mzc3NTNdIDJmYjI3IGlzIDI4Y2Y5MDAwIQ0KWyAgMTgy
LjYzOTQyNl0gMmZiMjggaXMgMjhjZmEwMDAhDQpbICAxODIuNjQxMTM0XSAyZmIxMyBpcyAy
OGNlNjAwMCENClsgIDE4Mi42NDI4MThdIDJmYjEyIGlzIDI4Y2U3MDAwIQ0KWyAgMTgyLjY0
NDUxNl0gMmZiMTEgaXMgMjhjZTgwMDAhDQpbICAxODIuNjQ2MjIwXSAyZmIxMCBpcyAyOGNl
OTAwMCENClsgIDE4Mi42NDc5MTJdIDJmYjBmIGlzIDI4Y2VhMDAwIQ0KWyAgMTgyLjY0OTYy
Ml0gMmZiMGUgaXMgMjhjZWIwMDAhDQpbICAxODIuNjUxMzE2XSAyZmIwZCBpcyAyOGNlYzAw
MCENClsgIDE4Mi42NTMwMzFdIDJmYjBjIGlzIDI4Y2VkMDAwIQ0KWyAgMTgyLjY1NDczNV0g
MmZiMGIgaXMgMjhjZWUwMDAhDQpbICAxODIuNjU2NDA4XSAyZmIwYSBpcyAyOGNlZjAwMCEN
ClsgIDE4Mi42NTgxMTldIDJmYjA5IGlzIDI4Y2YwMDAwIQ0KWyAgMTgyLjY2MDY5OV0gMmZi
M2IgaXMgMjhjYzYwMDAhDQpbICAxODIuNjYyNDQxXSAyZmIzYSBpcyAyOGNjNzAwMCENClsg
IDE4Mi42NjQxMzddIDJmYjM5IGlzIDI4Y2M4MDAwIQ0KWyAgMTgyLjY2NTg0MV0gMmZiMzgg
aXMgMjhjYzkwMDAhDQpbICAxODIuNjY3NTQyXSAyZmIzNyBpcyAyOGNjYTAwMCENClsgIDE4
Mi42NjkyMjVdIDJmYjM2IGlzIDI4Y2NiMDAwIQ0KWyAgMTgyLjY3MDk0N10gMmZiMzUgaXMg
MjhjY2MwMDAhDQpbICAxODIuNjcyNjI5XSAyZmIzNCBpcyAyOGNjZDAwMCENClsgIDE4Mi42
NzQzNDNdIDJmYjMzIGlzIDI4Y2NlMDAwIQ0KWyAgMTgyLjY3NjAxNl0gMmZiMzIgaXMgMjhj
Y2YwMDAhDQpbICAxODIuNjc3NzAwXSAyZmIyOSBpcyAyOGNkMDAwMCENClsgIDE4Mi42Nzkz
OTBdIDJmYjNjIGlzIDI4Y2QxMDAwIQ0KWyAgMTgyLjY4MTA3Nl0gMmZiM2QgaXMgMjhjZDIw
MDAhDQpbICAxODIuNjgyNzgyXSAyZmIzZSBpcyAyOGNkMzAwMCENClsgIDE4Mi42ODQ0NjZd
IDJmYjNmIGlzIDI4Y2Q0MDAwIQ0KWyAgMTgyLjY4NjEzM10gMmZiNDAgaXMgMjhjZDUwMDAh
DQpbICAxODIuNjg3ODQ4XSAyZmI0MSBpcyAyOGNkNjAwMCENClsgIDE4Mi42ODk1NDddIDJm
YjQyIGlzIDI4Y2Q3MDAwIQ0KWyAgMTgyLjY5MTI0Nl0gMmZiNDMgaXMgMjhjZDgwMDAhDQpb
ICAxODIuNjkyOTEyXSAyZmI0NCBpcyAyOGNkOTAwMCENClsgIDE4Mi42OTQ2MDhdIDJmYjQ1
IGlzIDI4Y2RhMDAwIQ0KWyAgMTgyLjY5NzE0M10gMmZiNTMgaXMgMjhjYjEwMDAhDQpbICAx
ODIuNjk4OTUwXSAyZmI1NCBpcyAyOGNiMjAwMCENClsgIDE4Mi43MDA2NjRdIDJmYjU1IGlz
IDI4Y2IzMDAwIQ0KWyAgMTgyLjcwMjM1NV0gMmZiNTYgaXMgMjhjYjQwMDAhDQpbICAxODIu
NzA0MDgwXSAyZmI1NyBpcyAyOGNiNTAwMCENClsgIDE4Mi43MDU3NzldIDJmYjU4IGlzIDI4
Y2I2MDAwIQ0KWyAgMTgyLjcwNzUwMF0gMmZiNTkgaXMgMjhjYjcwMDAhDQpbICAxODIuNzA5
MjA0XSAyZmI1YSBpcyAyOGNiODAwMCENClsgIDE4Mi43MTA5MDBdIDJmYjViIGlzIDI4Y2I5
MDAwIQ0KWyAgMTgyLjcxMjYwMV0gMmZiNWMgaXMgMjhjYmEwMDAhDQpbICAxODIuNzE0Mjg0
XSAyZmI1MiBpcyAyOGNhNjAwMCENClsgIDE4Mi43MTU5NjhdIDJmYjUxIGlzIDI4Y2E3MDAw
IQ0KWyAgMTgyLjcxNzY0NV0gMmZiMzEgaXMgMjhjYTgwMDAhDQpbICAxODIuNzE5MzAzXSAy
ZmIzMCBpcyAyOGNhOTAwMCENClsgIDE4Mi43MjEwMDhdIDJmYjJmIGlzIDI4Y2FhMDAwIQ0K
WyAgMTgyLjcyMjY3OF0gMmZiMmUgaXMgMjhjYWIwMDAhDQpbICAxODIuNzI0Mzg2XSAyZmIy
ZCBpcyAyOGNhYzAwMCENClsgIDE4Mi43MjYwNDVdIDJmYjJjIGlzIDI4Y2FkMDAwIQ0KWyAg
MTgyLjcyNzcyM10gMmZiMmIgaXMgMjhjYWUwMDAhDQpbICAxODIuNzI5NDEzXSAyZmIyYSBp
cyAyOGNhZjAwMCENClsgIDE4Mi43MzEwNzldIDJmYjQ2IGlzIDI4Y2IwMDAwIQ0KWyAgMTgy
LjczNDQ2Nl0gMmZiNWUgaXMgMjhjNzEwMDAhDQpbICAxODIuNzM2MTk2XSAyZmI1ZiBpcyAy
OGM3MjAwMCENClsgIDE4Mi43Mzc4OTFdIDJmYjYwIGlzIDI4YzczMDAwIQ0KWyAgMTgyLjcz
OTU2MF0gMmZiNjEgaXMgMjhjNzQwMDAhDQpbICAxODIuNzQxMjY5XSAyZmI2MiBpcyAyOGM3
NTAwMCENClsgIDE4Mi43NDI5MzldIDJmYjYzIGlzIDI4Yzc2MDAwIQ0KWyAgMTgyLjc0NDYy
OV0gMmZiNjQgaXMgMjhjNzcwMDAhDQpbICAxODIuNzQ2Mjg1XSAyZmI2NSBpcyAyOGM3ODAw
MCENClsgIDE4Mi43NDc5NDldIDJmYjY2IGlzIDI4Yzc5MDAwIQ0KWyAgMTgyLjc0OTYzNF0g
MmZiNjcgaXMgMjhjN2EwMDAhDQpbICAxODIuNzUxMzAxXSAyZmI1MCBpcyAyOGM4NjAwMCEN
ClsgIDE4Mi43NTI5NjddIDJmYjRmIGlzIDI4Yzg3MDAwIQ0KWyAgMTgyLjc1NDY0NF0gMmZi
NGUgaXMgMjhjODgwMDAhDQpbICAxODIuNzU2MjkwXSAyZmI0ZCBpcyAyOGM4OTAwMCENClsg
IDE4Mi43NTc5NzFdIDJmYjRjIGlzIDI4YzhhMDAwIQ0KWyAgMTgyLjc1OTYxOV0gMmZiNGIg
aXMgMjhjOGIwMDAhDQpbICAxODIuNzYxMjk5XSAyZmI0YSBpcyAyOGM4YzAwMCENClsgIDE4
Mi43NjI5NDddIDJmYjQ5IGlzIDI4YzhkMDAwIQ0KWyAgMTgyLjc2NDYxOF0gMmZiNDggaXMg
MjhjOGUwMDAhDQpbICAxODIuNzY2Mjg3XSAyZmI0NyBpcyAyOGM4ZjAwMCENClsgIDE4Mi43
Njc5NjRdIDJmYjVkIGlzIDI4YzkwMDAwIQ0KWyAgMTgyLjc2OTY0OF0gMmZiN2EgaXMgMjhj
N2IwMDAhDQpbICAxODIuNzcxMzM2XSAyZmI3OSBpcyAyOGM3YzAwMCENClsgIDE4Mi43NzMw
MTRdIDJmYjc4IGlzIDI4YzdkMDAwIQ0KWyAgMTgyLjc3NDcyM10gMmZiNzcgaXMgMjhjN2Uw
MDAhDQpbICAxODIuNzc2Mzk1XSAyZmI3NiBpcyAyOGM3ZjAwMCENClsgIDE4Mi43NzgxMDRd
IDJmYjc1IGlzIDI4YzgwMDAwIQ0KWyAgMTgyLjc3OTc4OV0gMmZiNzQgaXMgMjhjODEwMDAh
DQpbICAxODIuNzgxNDg4XSAyZmI3MyBpcyAyOGM4MjAwMCENClsgIDE4Mi43ODMxODhdIDJm
YjcyIGlzIDI4YzgzMDAwIQ0KWyAgMTgyLjc4NDg4MV0gMmZiNzEgaXMgMjhjODQwMDAhDQpb
ICAxODIuNzg2NTUyXSAyZmI3MCBpcyAyOGM4NTAwMCENClsgIDE4Mi43ODkyMTVdIDJmYjky
IGlzIDI4YzViMDAwIQ0KWyAgMTgyLjc5MDk2MF0gMmZiOTMgaXMgMjhjNWMwMDAhDQpbICAx
ODIuNzkyNjQwXSAyZmI5NCBpcyAyOGM1ZDAwMCENClsgIDE4Mi43OTQzMjRdIDJmYjk1IGlz
IDI4YzVlMDAwIQ0KWyAgMTgyLjc5NjA4Nl0gMmZiOTYgaXMgMjhjNWYwMDAhDQpbICAxODIu
Nzk3Nzc2XSAyZmI5NyBpcyAyOGM2MDAwMCENClsgIDE4Mi43OTk0OTZdIDJmYjk4IGlzIDI4
YzYxMDAwIQ0KWyAgMTgyLjgwMTE4OF0gMmZiOTkgaXMgMjhjNjIwMDAhDQpbICAxODIuODAy
OTA0XSAyZmI5YSBpcyAyOGM2MzAwMCENClsgIDE4Mi44MDQ2MDVdIDJmYjliIGlzIDI4YzY0
MDAwIQ0KWyAgMTgyLjgwNjI4MV0gMmZiOWMgaXMgMjhjNjUwMDAhDQpbICAxODIuODA3OTc4
XSAyZmI5ZCBpcyAyOGM1MTAwMCENClsgIDE4Mi44MDk2NjBdIDJmYjllIGlzIDI4YzUyMDAw
IQ0KWyAgMTgyLjgxMTM1Nl0gMmZiOWYgaXMgMjhjNTMwMDAhDQpbICAxODIuOFsgIDE4NC45
NDA4ODhdIDJmNmI3IGlzIDI5MGYyMDAwIQ0KWyAgMTg0Ljk0MzE3MF0gMmY2YjggaXMgMjkw
ZjEwMDAhDQpbICAxODQuOTQ1NDU1XSAyZjZiOSBpcyAyOTBmMDAwMCENClsgIDE4NC45NDc3
MzBdIDJmNmJhIGlzIDI5MGVmMDAwIQ0KWyAgMTg0Ljk0OTk2Ml0gMmY2YmIgaXMgMjkwZWUw
MDAhDQpbICAxODQuOTUyMjE4XSAyZjZiYyBpcyAyOTBlZDAwMCENClsgIDE4NC45NTQ0ODBd
IDJmNmJkIGlzIDI5MGVjMDAwIQ0KWyAgMTg0Ljk1NjY5NV0gMmY2YmUgaXMgMjkwZWIwMDAh
DQpbICAxODQuOTU4OTczXSAyZjZiZiBpcyAyOTBlYTAwMCENClsgIDE4NC45NjEyMTldIDJm
NmMwIGlzIDI5MGU5MDAwIQ0KWyAgMTg0Ljk2MzQ4MV0gMmY2YzEgaXMgMjkwZTgwMDAhDQpb
ICAxODQuOTY1Njg1XSAyZjZjMiBpcyAyOTBlNzAwMCENClsgIDE4NC45NzQzNjZdIDJmNmMz
IGlzIDI5MGU2MDAwIQ0KWyAgMTg0Ljk3NjU0Nl0gMmY1ZGMgaXMgMjkwZTUwMDAhDQpbICAx
ODQuOTc4NzIwXSAyZjZjNCBpcyAyOTBlNDAwMCENClsgIDE4NC45ODA4NTBdIDJmNWRkIGlz
IDI5MGUzMDAwIQ0KWyAgMTg0Ljk4MzA3NV0gMmY1ZGUgaXMgMjkwZTIwMDAhDQpbICAxODQu
OTg1MjE0XSAyZjZjNSBpcyAyOTBlMTAwMCENClsgIDE4NC45OTYwNTNdIDJmNWRmIGlzIDI5
MGUwMDAwIQ0KWyAgMTg0Ljk5ODIzNl0gMmY2ZGEgaXMgMjkwZGYwMDAhDQpbICAxODUuMDAw
NDI2XSAyZjZkYiBpcyAyOTBkZTAwMCENClsgIDE4NS4wMDI2NTNdIDJmNmRjIGlzIDI5MGRk
MDAwIQ0KWyAgMTg1LjAwNDg2N10gMmY2YzYgaXMgMjkwZGMwMDAhDQpbICAxODUuMDA3MTA5
XSAyZjZkZCBpcyAyOTBkYjAwMCENClsgIDE4NS4wMDkzNzZdIDJmNmM3IGlzIDI5MGRhMDAw
IQ0KWyAgMTg1LjAyMDM4NV0gMmY2YzggaXMgMjkwZDkwMDAhDQpbICAxODUuMDIyNjE1XSAy
ZjZjOSBpcyAyOTBkODAwMCENClsgIDE4NS4wMjQ4ODFdIDJmNmNhIGlzIDI5MGQ3MDAwIQ0K
WyAgMTg1LjAzMjgwMF0gMmY2Y2IgaXMgMjkwZDUwMDAhDQpbICAxODUuMDM0OTkxXSAyZjZj
YyBpcyAyOTBkNDAwMCENClsgIDE4NS4wNDAwNjJdIDJmNmNkIGlzIDI5MGQzMDAwIQ0KWyAg
MTg1LjA0Mzk5NF0gMmY2ZGUgaXMgMjkwZDIwMDAhDQpbICAxODUuMDQ2MjEwXSAyZjZjZSBp
cyAyOTBkMTAwMCENClsgIDE4NS4wNDg0MjFdIDJmNmNmIGlzIDI5MGQwMDAwIQ0KWyAgMTg1
LjA1MjA5OV0gMmY2ZDAgaXMgMjkwY2YwMDAhDQpbICAxODUuMDU0MzIwXSAyZjZkMSBpcyAy
OTBjZTAwMCENClsgIDE4NS4wNjM4NTJdIDJmNmQyIGlzIDI5MGNkMDAwIQ0KWyAgMTg1LjA2
NjA3NF0gMmY2ZDMgaXMgMjkwY2MwMDAhDQpbICAxODUuMDY4MjgxXSAyZjZkNCBpcyAyOTBj
YjAwMCENClsgIDE4NS4wNzA1MDddIDJmNmQ1IGlzIDI5MGNhMDAwIQ0KWyAgMTg1LjA3MjY5
N10gMmY2ZDYgaXMgMjkwYzkwMDAhDQpbICAxODUuMDc0OTI3XSAyZjZkNyBpcyAyOTBjODAw
MCENClsgIDE4NS4wNzcxMjJdIDJmNmQ4IGlzIDI5MGM3MDAwIQ0KWyAgMTg1LjA4NjM2MF0g
MmY2ZDkgaXMgMjkwOGQwMDAhDQpbICAxODUuMDg4NjQ5XSAyZjZkZiBpcyAyOTA4ZTAwMCEN
ClsgIDE4NS4wOTA4NTldIDJmNmY5IGlzIDI5MDhmMDAwIQ0KWyAgMTg1LjA5MzAzOF0gMmY2
ZmEgaXMgMjkwOTAwMDAhDQpbICAxODUuMDk1Mjc0XSAyZjZmYiBpcyAyOTA5MTAwMCENClsg
IDE4NS4wOTc0MzddIDJmNmZjIGlzIDI5MDkyMDAwIQ0KWyAgMTg1LjA5OTYyNV0gMmY2ZTAg
aXMgMjkwOTMwMDAhDQpbICAxODUuMTA3MDgzXSAyZjZmZCBpcyAyOTA5NDAwMCENClsgIDE4
NS4xMDkyNzhdIDJmNmUxIGlzIDI5MDk1MDAwIQ0KWyAgMTg1LjExNDY3Nl0gMmY2ZmUgaXMg
MjkwOTYwMDAhDQpbICAxODUuMTE2OTAwXSAyZjZlMiBpcyAyOTA5NzAwMCENClsgIDE4NS4x
MTkwNjBdIDJmNmZmIGlzIDI5MDk4MDAwIQ0KWyAgMTg1LjEyMTIxOV0gMmY3MDAgaXMgMjkw
OTkwMDAhDQpbICAxODUuMTI3ODg5XSAyZjcwMSBpcyAyOTA5YjAwMCENClsgIDE4NS4xMzA0
NTJdIDJmNzAyIGlzIDI5MDlkMDAwIQ0KWyAgMTg1LjEzMjYxM10gMmY3MDMgaXMgMjkwOWUw
MDAhDQpbICAxODUuMTM0NzY5XSAyZjcwNCBpcyAyOTA5ZjAwMCENClsgIDE4NS4xMzY5MDBd
IDJmNmU0IGlzIDI5MGEwMDAwIQ0KWyAgMTg1LjEzOTE2NF0gMmY3MDUgaXMgMjkwYTEwMDAh
DQpbICAxODUuMTQxMzg4XSAyZjZlNSBpcyAyOTBhMjAwMCENClsgIDE4NS4xNDM1MTJdIDJm
NzA2IGlzIDI5MGEzMDAwIQ0KWyAgMTg1LjE0NTgwOF0gMmY3MDcgaXMgMjkwYTQwMDAhDQpb
ICAxODUuMTQ4MDIzXSAyZjZlNiBpcyAyOTBhNTAwMCENClsgIDE4NS4xNTAxNzddIDJmNzA4
IGlzIDI5MGM2MDAwIQ0KWyAgMTg1LjE1Njc3NF0gMmY3MDkgaXMgMjkwYjcwMDAhDQpbICAx
ODUuMTY3ODk2XSAyZjZlNyBpcyAyOTBiODAwMCENClsgIDE4NS4xNzAxOTRdIDJmNmU4IGlz
IDI5MGI2MDAwIQ0KWyAgMTg1LjE3MjQzNV0gMmY3MGEgaXMgMjkwYjUwMDAhDQpbICAxODUu
MTc0Njg0XSAyZjcwYiBpcyAyOTBiYjAwMCENClsgIDE4NS4xNzY4NjFdIDJmNmU5IGlzIDI5
MGJjMDAwIQ0KWyAgMTg1LjE3OTIxM10gMmY3MGMgaXMgMjkwYmQwMDAhDQpbICAxODUuMTgx
NTA4XSAyZjZlYSBpcyAyOTBiZTAwMCENClsgIDE4NS4xODM3ODNdIDJmNzBkIGlzIDI5MGMw
MDAwIQ0KWyAgMTg1LjE4NjA4M10gMmY2ZWIgaXMgMjkwYzIwMDAhDQpbICAxODUuMTg4Mzg1
XSAyZjcwZSBpcyAyOTBjMzAwMCENClsgIDE4NS4xOTA2NTZdIDJmNmVjIGlzIDI5MGMxMDAw
IQ0KWyAgMTg1LjE5Mjk2Nl0gMmY2ZWQgaXMgMjkwYTYwMDAhDQpbICAxODUuMTk1Mjk3XSAy
ZjcwZiBpcyAyOTBhNzAwMCENClsgIDE4NS4xOTc3OTJdIDJmNzEwIGlzIDI5MGFmMDAwIQ0K
WyAgMTg1LjIwMDEzMF0gMmY2ZWUgaXMgMjkwYmEwMDAhDQpbICAxODUuMjAyNDM4XSAyZjcx
MSBpcyAyOTBiOTAwMCENClsgIDE4NS4yMDQ3ODJdIDJmNzEyIGlzIDI5MGM1MDAwIQ0KWyAg
MTg1LjIwNzA2Nl0gMmY3MTMgaXMgMjkwYzQwMDAhDQpbICAxODUuMjA5NDAxXSAyZjcxNCBp
cyAyODlmZTAwMCENClsgIDE4NS4yMTE3MzVdIDJmNzE1IGlzIDI5MGIwMDAwIQ0KWyAgMTg1
LjIxNDA4Nl0gMmY3MTYgaXMgMjkwYjEwMDAhDQpbICAxODUuMjE2NDQwXSAyZjcxNyBpcyAy
ODcwMzAwMCENClsgIDE4NS4yMTg3OTFdIDJmNzE4IGlzIDI4YTA4MDAwIQ0KWyAgMTg1LjIy
MTE4NF0gMmY3MTkgaXMgMjg3MDQwMDAhDQpbICAxODUuMjIzNTA2XSAyZjcxYSBpcyAyOTBh
YTAwMCENClsgIDE4NS4yMjc1NzJdIDJmNzQyIGlzIDI5MDcyMDAwIQ0KWyAgMTg1LjIyOTU2
Nl0gMmY3NDMgaXMgMjkwNzMwMDAhDQpbICAxODUuMjMxNTAwXSAyZjc0NCBpcyAyOTA3NDAw
MCENClsgIDE4NS4yMzM0NDldIDJmNzQ1IGlzIDI5MDc1MDAwIQ0KWyAgMTg1LjIzNTM0N10g
MmY3NDYgaXMgMjkwNzYwMDAhDQpbICAxODUuMjM3MjU0XSAyZjc0NyBpcyAyOTA3NzAwMCEN
ClsgIDE4NS4yMzkxMjNdIDJmNzQ4IGlzIDI5MDc4MDAwIQ0KWyAgMTg1LjI0MTAxM10gMmY3
NDkgaXMgMjkwNzkwMDAhDQpbICAxODUuMjQyODY0XSAyZjc0YSBpcyAyOTA3YTAwMCENClsg
IDE4NS4yNDQ4MTFdIDJmNzRiIGlzIDI5MDdiMDAwIQ0KWyAgMTg1LjI0NjY0N10gMmY3Mzcg
aXMgMjkwN2MwMDAhDQpbICAxODUuMjQ4NDkwXSAyZjczOCBpcyAyOTA3ZDAwMCENClsgIDE4
NS4yNTAzNTBdIDJmNzM5IGlzIDI5MDdlMDAwIQ0KWyAgMTg1LjI1MjE0OV0gMmY3M2EgaXMg
MjkwN2YwMDAhDQpbICAxODUuMjUzOTcyXSAyZjczYiBpcyAyOTA4MDAwMCENClsgIDE4NS4y
NTU3NTldIDJmNzNjIGlzIDI5MDgxMDAwIQ0KWyAgMTg1LjI1NzU4MV0gMmY3M2QgaXMgMjkw
ODIwMDAhDQpbICAxODUuMjU5MzQ2XSAyZjczZSBpcyAyOTA4MzAwMCENClsgIDE4NS4yNjEx
MjRdIDJmNzNmIGlzIDI5MDg0MDAwIQ0KWyAgMTg1LjI2MjkwOF0gMmY3NDAgaXMgMjkwODUw
MDAhDQpbICAxODUuMjY0Njg3XSAyZjc0MSBpcyAyOTA4NjAwMCENClsgIDE4NS4yNjY1MDRd
IDJmNmY4IGlzIDI5MDY3MDAwIQ0KWyAgMTg1LjI2ODMwMF0gMmY2ZjcgaXMgMjkwNjgwMDAh
DQpbICAxODUuMjcwMTA3XSAyZjZmNiBpcyAyOTA2OTAwMCENClsgIDE4NS4yNzE4NTVdIDJm
NmY1IGlzIDI5MDZhMDAwIQ0KWyAgMTg1LjI3MzY1MV0gMmY2ZjQgaXMgMjkwNmIwMDAhDQpb
ICAxODUuMjc1Mzc4XSAyZjZmMyBpcyAyOTA2YzAwMCENClsgIDE4NS4yNzcwOTBdIDJmNmYy
IGlzIDI5MDZkMDAwIQ0KWyAgMTg1LjI3ODgwMl0gMmY2ZjEgaXMgMjkwNmUwMDAhDQpbICAx
ODUuMjgwNDkwXSAyZjZmMCBpcyAyOTA2ZjAwMCENClsgIDE4NS4yODIxODNdIDJmNmVmIGlz
IDI5MDcwMDAwIQ0KWyAgMTg1LjI4Mzg3M10gMmY3MWIgaXMgMjkwNzEwMDAhDQpbICAxODUu
Mjg2NDI4XSAyZjc2MiBpcyAyOTA0NzAwMCENClsgIDE4NS4yODgxODldIDJmNzYzIGlzIDI5
MDQ4MDAwIQ0KWyAgMTg1LjI4OTg4Nl0gMmY3NjQgaXMgMjkwNDkwMDAhDQpbICAxODUuMjkx
NjE0XSAyZjc2NSBpcyAyOTA0YTAwMCENClsgIDE4NS4yOTMzMDRdIDJmNzY2IGlzIDI5MDRi
MDAwIQ0KWyAgMTg1LjI5NTAyOV0gMmY3NjcgaXMgMjkwNGMwMDAhDQpbICAxODUuMjk2NzM0
XSAyZjc2OCBpcyAyOTA0ZDAwMCENClsgIDE4NS4yOTg0MTldIDJmNzY5IGlzIDI5MDRlMDAw
IQ0KWyAgMTg1LjMwMDE0OF0gMmY3NmEgaXMgMjkwNGYwMDAhDQpbICAxODUuMzAxODU5XSAy
Zjc2YiBpcyAyOTA1MDAwMCENClsgIDE4NS4zMDM1OTddIDJmNzZjIGlzIDI5MDUxMDAwIQ0K
WyAgMTg1LjMwNTI5OV0gMmY3NGMgaXMgMjkwNWMwMDAhDQpbICAxODUuMzA3MDMwXSAyZjc0
ZCBpcyAyOTA1ZDAwMCENClsgIDE4NS4zMDg3NDJdIDJmNzRlIGlzIDI5MDVlMDAwIQ0KWyAg
MTg1LjMxMDQzNF0gMmY3NGYgaXMgMjkwNWYwMDAhDQpbICAxODUuMzEyMTQzXSAyZjc1MCBp
cyAyOTA2MDAwMCENClsgIDE4NS4zMTM4NTNdIDJmNzUxIGlzIDI5MDYxMDAwIQ0KWyAgMTg1
LjMxNTU2OV0gMmY3NTIgaXMgMjkwNjIwMDAhDQpbICAxODUuMzE3MjcxXSAyZjc1MyBpcyAy
OTA2MzAwMCENClsgIDE4NS4zMTg5NDldIDJmNzU0IGlzIDI5MDY0MDAwIQ0KWyAgMTg1LjMy
MDY2N10gMmY3NTUgaXMgMjkwNjUwMDAhDQpbICAxODUuMzIyMzMzXSAyZjc1NiBpcyAyOTA2
NjAwMCENClsgIDE4NS4zMjQwNDZdIDJmNzU3IGlzIDI5MDUyMDAwIQ0KWyAgMTg1LjMyNTcy
NF0gMmY3NTggaXMgMjkwNTMwMDAhDQpbICAxODUuMzI3NDE1XSAyZjc1OSBpcyAyOTA1NDAw
MCENClsgIDE4NS4zMjkxMjVdIDJmNzVhIGlzIDI5MDU1MDAwIQ0KWyAgMTg1LjMzMDgxOF0g
MmY3NWIgaXMgMjkwNTYwMDAhDQpbICAxODUuMzMyNTI3XSAyZjc1YyBpcyAyOTA1NzAwMCEN
ClsgIDE4NS4zMzQyMjZdIDJmNzVkIGlzIDI5MDU4MDAwIQ0KWyAgMTg1LjMzNTg5OF0gMmY3
NWUgaXMgMjkwNTkwMDAhDQpbICAxODUuMzM3NTk4XSAyZjc1ZiBpcyAyOTA1YTAwMCENClsg
IDE4NS4zMzkyNDFdIDJmNzYwIGlzIDI5MDViMDAwIQ0KWyAgMTg1LjM0MjYxNV0gMmY3NjEg
aXMgMjkwMTIwMDAhDQpbICAxODUuMzQ0MzU1XSAyZjcxYyBpcyAyOTAxMzAwMCENClsgIDE4
NS4zNDYwNDldIDJmNzFkIGlzIDI5MDE0MDAwIQ0KWyAgMTg1LjM0NzcyM10gMmY3MWUgaXMg
MjkwMTUwMDAhDQpbICAxODUuMzQ5NDE3XSAyZjcxZiBpcyAyOTAxNjAwMCENClsgIDE4NS4z
NTExMTFdIDJmNzIwIGlzIDI5MDE3MDAwIQ0KWyAgMTg1LjM1MjgxOV0gMmY3MjEgaXMgMjkw
MTgwMDAhDQpbICAxODUuMzU0NTE0XSAyZjcyMiBpcyAyOTAxOTAwMCENClsgIDE4NS4zNTYx
NjRdIDJmNzIzIGlzIDI5MDFhMDAwIQ0KWyAgMTg1LjM1NzgzN10gMmY3MjQgaXMgMjkwMWIw
MDAhDQpbICAxODUuMzU5NDc3XSAyZjc3NyBpcyAyOTAyNzAwMCENClsgIDE4NS4zNjExNTFd
IDJmNzc2IGlzIDI5MDI4MDAwIQ0KWyAgMTg1LjM2MjgwN10gMmY3NzUgaXMgMjkwMjkwMDAh
DQpbICAxODUuMzY0NDgwXSAyZjc3NCBpcyAyOTAyYTAwMCENClsgIDE4NS4zNjYxNTZdIDJm
NzczIGlzIDI5MDJiMDAwIQ0KWyAgMTg1LjM2NzgwM10gMmY3NzIgaXMgMjkwMmMwMDAhDQpb
ICAxODUuMzY5NDc4XSAyZjc3MSBpcyAyOTAyZDAwMCENClsgIDE4NS4zNzExMjVdIDJmNzcw
IGlzIDI5MDJlMDAwIQ0KWyAgMTg1LjM3Mjc2M10gMmY3NmYgaXMgMjkwMmYwMDAhDQpbICAx
ODUuMzc0NDM2XSAyZjc2ZSBpcyAyOTAzMDAwMCENClsgIDE4NS4zNzYwODBdIDJmNzZkIGlz
IDI5MDMxMDAwIQ0KWyAgMTg1LjM3Nzc1NV0gMmY3ODIgaXMgMjkwMWMwMDAhDQpbICAxODUu
Mzc5NDA2XSAyZjc4MSBpcyAyOTAxZDAwMCENClsgIDE4NS4zODEwNjldIDJmNzgwIGlzIDI5
MDFlMDAwIQ0KWyAgMTg1LjM4Mjc0MV0gMmY3N2YgaXMgMjkwMWYwMDAhDQpbICAxODUuMzg0
NDIzXSAyZjc3ZSBpcyAyOTAyMDAwMCENClsgIDE4NS4zODYxMDRdIDJmNzdkIGlzIDI5MDIx
MDAwIQ0KWyAgMTg1LjM4Nzc4NF0gMmY3N2MgaXMgMjkwMjIwMDAhDQpbICAxODUuMzg5NDUz
XSAyZjc3YiBpcyAyOTAyMzAwMCENClsgIDE4NS4zOTExNTBdIDJmNzdhIGlzIDI5MDI0MDAw
IQ0KWyAgMTg1LjM5MjgyOF0gMmY3NzkgaXMgMjkwMjUwMDAhDQpbICAxODUuMzk0NTI5XSAy
Zjc3OCBpcyAyOTAyNjAwMCENClsgIDE4NS4zOTczNzVdIDJmN2EyIGlzIDI4ZmRjMDAwIQ0K
WyAgMTg1LjM5OTE3MF0gMmY3ODMgaXMgMjhmZGQwMDAhDQpbICAxODUuNDAwODk1XSAyZjc4
NCBpcyAyOGZkZTAwMCENClsgIDE4NS40MDI2MDddIDJmNzg1IGlzIDI4ZmRmMDAwIQ0KWyAg
MTg1LjQwNDM1MV0gMmY3ODYgaXMgMjhmZTAwMDAhDQpbICAxODUuNDA2MDU1XSAyZjc4NyBp
cyAyOGZlMTAwMCENClsgIDE4NS40MDc3OTJdIDJmNzg4IGlzIDI4ZmUyMDAwIQ0KWyAgMTg1
LjQwOTUxMV0gMmY3ODkgaXMgMjhmZTMwMDAhDQpbICAxODUuNDExMjYxXSAyZjc4YSBpcyAy
OGZlNDAwMCENClsgIDE4NS40MTI5NjVdIDJmNzhiIGlzIDI4ZmU1MDAwIQ0KWyAgMTg1LjQx
NDY3OF0gMmY3OGMgaXMgMjhmZTYwMDAhDQpbICAxODUuNDE2MzkxXSAyZjc5OCBpcyAyOGZm
MjAwMCENClsgIDE4NS40MTgxMDldIDJmNzk5IGlzIDI4ZmYzMDAwIQ0KWyAgMTg1LjQxOTgz
M10gMmY3OWEgaXMgMjhmZjQwMDAhDQpbICAxODUuNDIxNTUyXSAyZjc5YiBpcyAyOGZmNTAw
MCENClsgIDE4NS40MjMyNTZdIDJmNzljIGlzIDI4ZmY2MDAwIQ0KWyAgMTg1LjQyNTAwMF0g
MmY3OWQgaXMgMjhmZjcwMDAhDQpbICAxODUuNDI2Njk1XSAyZjc5ZSBpcyAyOGZmODAwMCEN
ClsgIDE4NS40Mjg0MjZdIDJmNzlmIGlzIDI4ZmY5MDAwIQ0KWyAgMTg1LjQzMDEyOV0gMmY3
YTAgaXMgMjhmZmEwMDAhDQpbICAxODUuNDMxODM4XSAyZjdhMSBpcyAyOGZmYjAwMCENClsg
IDE4NS40MzM1MjJdIDJmNzMwIGlzIDI4ZmZjMDAwIQ0KWyAgMTg1LjQzNTIwMV0gMmY3MzEg
aXMgMjhmZmQwMDAhDQpbICAxODUuNDM2OTEzXSAyZjczMiBpcyAyOGZmZTAwMCENClsgIDE4
NS40Mzg1ODBdIDJmNzMzIGlzIDI4ZmZmMDAwIQ0KWyAgMTg1LjQ0MDI4MF0gMmY3MzQgaXMg
MjkwMDAwMDAhDQpbICAxODUuNDQxOTUzXSAyZjczNSBpcyAyOTAwMTAwMCENClsgIDE4NS40
NDM2NDVdIDJmNzM2IGlzIDI5MDAyMDAwIQ0KWyAgMTg1LjQ0NTM1MF0gMmY3OTQgaXMgMjkw
MDMwMDAhDQpbICAxODUuNDQ3MDQ4XSAyZjc5NSBpcyAyOTAwNDAwMCENClsgIDE4NS40NDg3
NThdIDJmNzk2IGlzIDI5MDA1MDAwIQ0KWyAgMTg1LjQ1MDQ1N10gMmY3OTcgaXMgMjkwMDYw
MDAhDQpbICAxODUuNDUyMTE4XSAyZjcyZiBpcyAyOGZlNzAwMCENClsgIDE4NS40NTM4NDFd
IDJmNzJlIGlzIDI4ZmU4MDAwIQ0KWyAgMTg1LjQ1NTUxNF0gMmY3MmQgaXMgMjhmZTkwMDAh
DQpbICAxODUuNDU3MjI3XSAyZjcyYyBpcyAyOGZlYTAwMCENClsgIDE4NS40NTg4OTRdIDJm
NzJiIGlzIDI4ZmViMDAwIQ0KWyAgMTg1LjQ2MDU4MV0gMmY3MmEgaXMgMjhmZWMwMDAhDQpb
ICAxODUuNDYyMjg0XSAyZjcyOSBpcyAyOGZlZDAwMCENClsgIDE4NS40NjM5NzFdIDJmNzI4
IGlzIDI4ZmVlMDAwIQ0KWyAgMTg1LjQ2NTY2OV0gMmY3MjcgaXMgMjhmZWYwMDAhDQpbICAx
ODUuNDY3MzYyXSAyZjcyNiBpcyAyOGZmMDAwMCENClsgIDE4NS40NjkwNDFdIDJmNzI1IGlz
IDI4ZmYxMDAwIQ0KWyAgMTg1LjQ3MjM0Nl0gMmY3YjYgaXMgMjhmYzcwMDAhDQpbICAxODUu
NDc0MDk5XSAyZjdiNSBpcyAyOGZjODAwMCENClsgIDE4NS40NzU3OTldIDJmN2I0IGlzIDI4
ZmM5MDAwIQ0KWyAgMTg1LjQ3NzQ4Ml0gMmY3YjMgaXMgMjhmY2EwMDAhDQpbICAxODUuNDc5
MjA0XSAyZjc5MyBpcyAyOGZjYjAwMCENClsgIDE4NS40ODA5MDFdIDJmNzkyIGlzIDI4ZmNj
MDAwIQ0KWyAgMTg1LjQ4MjYwNV0gMmY3OTEgaXMgMjhmY2QwMDAhDQpbICAxODUuNDg0Mjg4
XSAyZjc5MCBpcyAyOGZjZTAwMCENClsgIDE4NS40ODU5NzldIDJmNzhmIGlzIDI4ZmNmMDAw
IQ0KWyAgMTg1LjQ4NzY3MF0gMmY3OGUgaXMgMjhmZDAwMDAhDQpbICAxODUuNDg5MzUzXSAy
Zjc4ZCBpcyAyOGZkMTAwMCENClsgIDE4NS40OTEwMzddIDJmN2EzIGlzIDI4ZmJjMDAwIQ0K
WyAgMTg1LjQ5MjcxMV0gMmY3YTQgaXMgMjhmYmQwMDAhDQpbICAxODUuNDk0NDEyXSAyZjdh
NSBpcyAyOGZiZTAwMCENClsgIDE4NS40OTYwNjhdIDJmN2E2IGlzIDI4ZmJmMDAwIQ0KWyAg
MTg1LjQ5NzczNl0gMmY3YTcgaXMgMjhmYzAwMDAhDQpbICAxODUuNDk5NDE0XSAyZjdhOCBp
cyAyOGZjMTAwMCENClsgIDE4NS41MDEwODVdIDJmN2E5IGlzIDI4ZmMyMDAwIQ0KWyAgMTg1
LjUwMjc2Nl0gMmY3YWEgaXMgMjhmYzMwMDAhDQpbICAxODUuNTA0NDUxXSAyZjdhYiBpcyAy
OGZjNDAwMCENClsgIDE4NS41MDYxMjNdIDJmN2FjIGlzIDI4ZmM1MDAwIQ0KWyAgMTg1LjUw
NzgwNF0gMmY3YWQgaXMgMjhmYzYwMDAhDQpbICAxODUuNTA5NzAyXSAyZjdkNyBpcyAyOGZh
NzAwMCENClsgIDE4NS41MTE0MzhdIDJmN2Q4IGlzIDI4ZmE4MDAwIQ0KWyAgMTg1LjUxMzEy
MF0gMmY3ZDkgaXMgMjhmYTkwMDAhDQpbICAxODUuNTE0ODA2XSAyZjdkYSBpcyAyOGZhYTAw
MCENClsgIDE4NS41MTY0OTldIDJmN2RiIGlzIDI4ZmFiMDAwIQ0KWyAgMTg1LjUxODE4OF0g
MmY3ZGMgaXMgMjhmYWMwMDAhDQpbICAxODUuNTE5OTk2XSAyZjdkZCBpcyAyOGZhZDAwMCEN
ClsgIDE4NS41MjE3MDJdIDJmN2RlIGlzIDI4ZmFlMDAwIQ0KWyAgMTg1LjUyMzQzMV0gMmY3
ZGYgaXMgMjhmYWYwMDAhDQpbICAxODUuNTI1MTEyXSAyZjdlMCBpcyAyOGZiMDAwMCENClsg
IDE4NS41MjY4MDNdIDJmN2UxIGlzIDI4ZmIxMDAwIQ0KWyAgMTg1LjUyODUwOF0gMmY3YWUg
aXMgMjhmYjIwMDAhDQpbICAxODUuNTMwMjE5XSAyZjdhZiBpcyAyOGZiMzAwMCENClsgIDE4
NS41MzE5MjldIDJmN2IwIGlzIDI4ZmI0MDAwIQ0KWyAgMTg1LjUzMzYyNl0gMmY3YjEgaXMg
MjhmYjUwMDAhDQpbICAxODUuNTM1MzA1XSAyZjdiMiBpcyAyOGZiNjAwMCENClsgIDE4NS41
MzcwMjhdIDJmN2QyIGlzIDI4ZmI3MDAwIQ0KWyAgMTg1LjUzODcxMl0gMmY3ZDMgaXMgMjhm
YjgwMDAhDQpbICAxODUuNTQwNDMxXSAyZjdkNCBpcyAyOGZiOTAwMCENClsgIDE4NS41NDIx
MTVdIDJmN2Q1IGlzIDI4ZmJhMDAwIQ0KWyAgMTg1LjU0MzgxM10gMmY3ZDYgaXMgMjhmYmIw
MDAhDQpbICAxODUuNTQ2NDYwXSAyZjdlMyBpcyAyOGY5MDAwMCENClsgIDE4NS41NDgyMDNd
IDJmN2UyIGlzIDI4ZjkxMDAwIQ0KWyAgMTg1LjU0OTkyMl0gMmY3ZWUgaXMgMjhmODUwMDAh
DQpbICAxODUuNTUxNjMwXSAyZjdlZCBpcyAyOGY4NjAwMCENClsgIDE4NS41NTMzNTJdIDJm
N2VjIGlzIDI4Zjg3MDAwIQ0KWyAgMTg1LjU1NTA3MV0gMmY3ZWIgaXMgMjhmODgwMDAhDQpb
ICAxODUuNTU2Nzk5XSAyZjdlYSBpcyAyOGY4OTAwMCENClsgIDE4NS41NTg0NzVdIDJmN2U5
IGlzIDI4ZjhhMDAwIQ0KWyAgMTg1LjU2MDE2OV0gMmY3ZTggaXMgMjhmOGIwMDAhDQpbICAx
ODUuNTYxODg0XSAyZjdlNyBpcyAyOGY4YzAwMCENClsgIDE4NS41NjM1ODRdIDJmN2U2IGlz
IDI4ZjhkMDAwIQ0KWyAgMTg1LjU2NTI5MV0gMmY3ZTUgaXMgMjhmOGUwMDAhDQpbICAxODUu
NTY2OTc2XSAyZjdlNCBpcyAyOGY4ZjAwMCENClsgIDE4NS41Njg5MzldIDJmN2Y5IGlzIDI4
ZjdhMDAwIQ0KWyAgMTg1LjU3MDY5NV0gMmY3ZmEgaXMgMjhmN2IwMDAhDQpbICAxODUuNTcy
MzgzXSAyZjdmYiBpcyAyOGY3YzAwMCENClsgIDE4NS41NzQxMDBdIDJmN2Y4IGlzIDI4Zjdk
MDAwIQ0KWyAgMTg1LjU3NTc4MV0gMmY3ZjcgaXMgMjhmN2UwMDAhDQpbICAxODUuNTc3NDkw
XSAyZjdmNiBpcyAyOGY3ZjAwMCENClsgIDE4NS41NzkxNjNdIDJmN2Y1IGlzIDI4ZjgwMDAw
IQ0KWyAgMTg1LjU4MDg0OV0gMmY3ZjQgaXMgMjhmODEwMDAhDQpbICAxODcuNzA5Nzg4XSAy
ZjJkYiBpcyAyOTMxODAwMCENClsgIDE4Ny43MTE5NjNdIDJmMzUwIGlzIDI5MzE3MDAwIQ0K
WyAgMTg3LjcxNDE0MV0gMmYyZGMgaXMgMjkzMTYwMDAhDQpbICAxODcuNzE2NDA3XSAyZjJk
ZCBpcyAyOTMxNTAwMCENClsgIDE4Ny43MTg2NDhdIDJmMzUxIGlzIDI5MzE0MDAwIQ0KWyAg
MTg3LjcyMDkxMV0gMmYzNTIgaXMgMjkzMTMwMDAhDQpbICAxODcuNzIzMTMwXSAyZjM1MyBp
cyAyOTMxMjAwMCENClsgIDE4Ny43MjUzODddIDJmMzU0IGlzIDI5MzExMDAwIQ0KWyAgMTg3
LjcyNzYzOF0gMmYzNTUgaXMgMjkzMTAwMDAhDQpbICAxODcuNzI5ODY1XSAyZjM1NiBpcyAy
OTMwZjAwMCENClsgIDE4Ny43MzIwODhdIDJmMzU3IGlzIDI5MzBlMDAwIQ0KWyAgMTg3Ljcz
NDM0MF0gMmYzNTggaXMgMjkzMGQwMDAhDQpbICAxODcuNzM2NTQ2XSAyZjM1OSBpcyAyOTMw
YzAwMCENClsgIDE4Ny43Mzg3NjddIDJmMzVhIGlzIDI5MzBiMDAwIQ0KWyAgMTg3Ljc0MTAx
OV0gMmYzNWIgaXMgMjkzMGEwMDAhDQpbICAxODcuNzQzMjE3XSAyZjM1YyBpcyAyOTMwOTAw
MCENClsgIDE4Ny43NTIzODNdIDJmMzVkIGlzIDI5MzA4MDAwIQ0KWyAgMTg3Ljc1NDU2N10g
MmYyZGUgaXMgMjkzMDcwMDAhDQpbICAxODcuNzU2NzkxXSAyZjJkZiBpcyAyOTMwNjAwMCEN
ClsgIDE4Ny43NTkwMDVdIDJmMzVlIGlzIDI5MzA1MDAwIQ0KWyAgMTg3Ljc2MTEyNV0gMmYz
NWYgaXMgMjkzMDQwMDAhDQpbICAxODcuNzYzMzYwXSAyZjJlMCBpcyAyOTMwMzAwMCENClsg
IDE4Ny43Njk1NjhdIDJmMzYwIGlzIDI5MzAyMDAwIQ0KWyAgMTg3Ljc3MTc2N10gMmYyZTEg
aXMgMjkzMDEwMDAhDQpbICAxODcuNzczOTM1XSAyZjJlMiBpcyAyOTMwMDAwMCENClsgIDE4
Ny43NzYxNDJdIDJmMzdlIGlzIDI5MmZmMDAwIQ0KWyAgMTg3Ljc3ODI5MV0gMmYzNjEgaXMg
MjkyZmUwMDAhDQpbICAxODcuNzgwNDc3XSAyZjM3ZiBpcyAyOTJmZDAwMCENClsgIDE4Ny43
ODI3MjVdIDJmMzgwIGlzIDI5MmZjMDAwIQ0KWyAgMTg3Ljc4NDkxNV0gMmYzNjIgaXMgMjky
ZmIwMDAhDQpbICAxODcuNzg3MjAzXSAyZjM4MSBpcyAyOTJmYTAwMCENClsgIDE4Ny43ODk0
MTJdIDJmMzYzIGlzIDI5MmY5MDAwIQ0KWyAgMTg3Ljc5MTY1MF0gMmYzNjQgaXMgMjkyZjgw
MDAhDQpbICAxODcuNzkzODY0XSAyZjM2NSBpcyAyOTJmNzAwMCENClsgIDE4Ny43OTYwNjZd
IDJmMzY2IGlzIDI5MmY2MDAwIQ0KWyAgMTg3LjgwMjIzMF0gMmYzNjcgaXMgMjkyZjUwMDAh
DQpbICAxODcuODA0Mzk2XSAyZjM4MiBpcyAyOTJmNDAwMCENClsgIDE4Ny44MDY1ODZdIDJm
MzgzIGlzIDI5MmYzMDAwIQ0KWyAgMTg3LjgwODczOV0gMmYzNjggaXMgMjkyZjIwMDAhDQpb
ICAxODcuODE2OTM2XSAyZjM4NCBpcyAyOTJmMTAwMCENClsgIDE4Ny44MTkxMjFdIDJmMzg1
IGlzIDI5MmYwMDAwIQ0KWyAgMTg3LjgyMTI3M10gMmYzNjkgaXMgMjkyZWYwMDAhDQpbICAx
ODcuODM4NTgyXSAyZjM4NiBpcyAyOTJlNDAwMCENClsgIDE4Ny44NDA0NjhdIDJmMzZhIGlz
IDI5MmU1MDAwIQ0KWyAgMTg3Ljg0MjM0OF0gMmYzNmIgaXMgMjkyZTYwMDAhDQpbICAxODcu
ODQ0MjY5XSAyZjM2YyBpcyAyOTJlNzAwMCENClsgIDE4Ny44NDYwNzBdIDJmMzZkIGlzIDI5
MmU4MDAwIQ0KWyAgMTg3Ljg0Nzg4Ml0gMmYzNmUgaXMgMjkyZTkwMDAhDQpbICAxODcuODQ5
Njg2XSAyZjM2ZiBpcyAyOTJlYTAwMCENClsgIDE4Ny44NTE0NzZdIDJmMzcwIGlzIDI5MmVi
MDAwIQ0KWyAgMTg3Ljg1MzI2NV0gMmYzNzEgaXMgMjkyZWMwMDAhDQpbICAxODcuODU1MDQ2
XSAyZjM3MiBpcyAyOTJlZDAwMCENClsgIDE4Ny44NTY4MzBdIDJmMzczIGlzIDI5MmVlMDAw
IQ0KWyAgMTg3Ljg1ODY1MV0gMmYzOWUgaXMgMjkyY2YwMDAhDQpbICAxODcuODYwNDUyXSAy
ZjM5ZiBpcyAyOTJkMDAwMCENClsgIDE4Ny44NjIyMzRdIDJmM2EwIGlzIDI5MmQxMDAwIQ0K
WyAgMTg3Ljg2NDAxOV0gMmYzYTEgaXMgMjkyZDIwMDAhDQpbICAxODcuODY1Nzc1XSAyZjNh
MiBpcyAyOTJkMzAwMCENClsgIDE4Ny44Njc1MjhdIDJmM2EzIGlzIDI5MmQ0MDAwIQ0KWyAg
MTg3Ljg2OTI1Ml0gMmYzYTQgaXMgMjkyZDUwMDAhDQpbICAxODcuODcxMDAzXSAyZjNhNSBp
cyAyOTJkNjAwMCENClsgIDE4Ny44NzI3MjZdIDJmM2E2IGlzIDI5MmQ3MDAwIQ0KWyAgMTg3
Ljg3NDQ3N10gMmYzYTcgaXMgMjkyZDgwMDAhDQpbICAxODcuODc2NTg4XSAyZjNhOCBpcyAy
OTJjNDAwMCENClsgIDE4Ny44NzgzNTRdIDJmM2E5IGlzIDI5MmM1MDAwIQ0KWyAgMTg3Ljg4
MDA4N10gMmYzYWEgaXMgMjkyYzYwMDAhDQpbICAxODcuODgxODA5XSAyZjNhYiBpcyAyOTJj
NzAwMCENClsgIDE4Ny44ODM1NTNdIDJmM2FjIGlzIDI5MmM4MDAwIQ0KWyAgMTg3Ljg4NTI1
OF0gMmYzYWQgaXMgMjkyYzkwMDAhDQpbICAxODcuODg2OTk4XSAyZjNhZSBpcyAyOTJjYTAw
MCENClsgIDE4Ny44ODg2OTNdIDJmM2FmIGlzIDI5MmNiMDAwIQ0KWyAgMTg3Ljg5MDQwN10g
MmYzYjAgaXMgMjkyY2MwMDAhDQpbICAxODcuODkyMTAwXSAyZjNiMSBpcyAyOTJjZDAwMCEN
ClsgIDE4Ny44OTM3ODhdIDJmM2IyIGlzIDI5MmNlMDAwIQ0KWyAgMTg3Ljg5NTQ2Ml0gMmYz
YjMgaXMgMjkyYjkwMDAhDQpbICAxODcuODk3MTM0XSAyZjNiNCBpcyAyOTJiYTAwMCENClsg
IDE4Ny44OTg4MDddIDJmM2I1IGlzIDI5MmJiMDAwIQ0KWyAgMTg3LjkwMDQ4NF0gMmYzYjYg
aXMgMjkyYmMwMDAhDQpbICAxODcuOTAyMTU0XSAyZjNiNyBpcyAyOTJiZDAwMCENClsgIDE4
Ny45MDM4NTNdIDJmM2I4IGlzIDI5MmJlMDAwIQ0KWyAgMTg3LjkwNTUxNl0gMmYzYjkgaXMg
MjkyYmYwMDAhDQpbICAxODcuOTA3MjEwXSAyZjNiYSBpcyAyOTJjMDAwMCENClsgIDE4Ny45
MDg4NzRdIDJmM2JiIGlzIDI5MmMxMDAwIQ0KWyAgMTg3LjkxMDU0NF0gMmYzYmUgaXMgMjky
YzIwMDAhDQpbICAxODcuOTEyMjE1XSAyZjNiZiBpcyAyOTJjMzAwMCENClsgIDE4Ny45MTM4
NzNdIDJmM2MwIGlzIDI5MmFmMDAwIQ0KWyAgMTg3LjkxNTUzN10gMmYzYzEgaXMgMjkyYjAw
MDAhDQpbICAxODcuOTE3MjAxXSAyZjNjMiBpcyAyOTJiMTAwMCENClsgIDE4Ny45MTg4NTFd
IDJmM2MzIGlzIDI5MmIyMDAwIQ0KWyAgMTg3LjkyMDUyNV0gMmYzYzQgaXMgMjkyYjMwMDAh
DQpbICAxODcuOTIyMTc1XSAyZjNjNSBpcyAyOTJiNDAwMCENClsgIDE4Ny45MjM4NDddIDJm
M2M2IGlzIDI5MmI1MDAwIQ0KWyAgMTg3LjkyNTQ4NV0gMmYzYzcgaXMgMjkyYjYwMDAhDQpb
ICAxODcuOTI3MTM3XSAyZjNjOCBpcyAyOTJiNzAwMCENClsgIDE4Ny45Mjg3OTJdIDJmM2M5
IGlzIDI5MmI4MDAwIQ0KWyAgMTg3LjkzMDQzOV0gMmYzNzQgaXMgMjkyZDkwMDAhDQpbICAx
ODcuOTMyMTAzXSAyZjM3NSBpcyAyOTJkYTAwMCENClsgIDE4Ny45MzM3NjBdIDJmMzc2IGlz
IDI5MmRiMDAwIQ0KWyAgMTg3LjkzNTQwM10gMmYzNzcgaXMgMjkyZGMwMDAhDQpbICAxODcu
OTM3MDgxXSAyZjM3OCBpcyAyOTJkZDAwMCENClsgIDE4Ny45Mzg3MzFdIDJmMzc5IGlzIDI5
MmRlMDAwIQ0KWyAgMTg3Ljk0MDQwOV0gMmYzN2EgaXMgMjkyZGYwMDAhDQpbICAxODcuOTQy
MDcwXSAyZjM3YiBpcyAyOTJlMDAwMCENClsgIDE4Ny45NDM3NDBdIDJmMzdjIGlzIDI5MmUx
MDAwIQ0KWyAgMTg3Ljk0NTQxMV0gMmYzN2QgaXMgMjkyZTIwMDAhDQpbICAxODcuOTQ3MDgw
XSAyZjM5ZCBpcyAyOTJlMzAwMCENClsgIDE4Ny45NDk2NTFdIDJmMzg3IGlzIDI5MmE0MDAw
IQ0KWyAgMTg3Ljk1MTM4OF0gMmYzY2EgaXMgMjkyYTUwMDAhDQpbICAxODcuOTUzMDk2XSAy
ZjNjYiBpcyAyOTJhNjAwMCENClsgIDE4Ny45NTQ3ODFdIDJmM2NjIGlzIDI5MmE3MDAwIQ0K
WyAgMTg3Ljk1NjQ2OV0gMmYzY2QgaXMgMjkyYTgwMDAhDQpbICAxODcuOTU4MTk1XSAyZjNj
ZSBpcyAyOTJhOTAwMCENClsgIDE4Ny45NTk4ODldIDJmM2NmIGlzIDI5MmFhMDAwIQ0KWyAg
MTg3Ljk2MTYxMF0gMmYzZDAgaXMgMjkyYWIwMDAhDQpbICAxODcuOTYzMzA3XSAyZjNkMSBp
cyAyOTJhYzAwMCENClsgIDE4Ny45NjUwMTNdIDJmM2QyIGlzIDI5MmFkMDAwIQ0KWyAgMTg3
Ljk2Njc1NF0gMmYzZDMgaXMgMjkyYWUwMDAhDQpbICAxODcuOTY4NzE0XSAyZjNkZiBpcyAy
OTI4ZjAwMCENClsgIDE4Ny45NzA0NDhdIDJmM2UwIGlzIDI5MjkwMDAwIQ0KWyAgMTg3Ljk3
MjE0OF0gMmYzZTEgaXMgMjkyOTEwMDAhDQpbICAxODcuOTczODYwXSAyZjNlMiBpcyAyOTI5
MjAwMCENClsgIDE4Ny45NzU1MzhdIDJmM2UzIGlzIDI5MjkzMDAwIQ0KWyAgMTg3Ljk3NzIz
M10gMmYzZTQgaXMgMjkyOTQwMDAhDQpbICAxODcuOTc4OTI5XSAyZjNlNSBpcyAyOTI5NTAw
MCENClsgIDE4Ny45ODA2MTddIDJmM2U2IGlzIDI5Mjk2MDAwIQ0KWyAgMTg3Ljk4MjMyNl0g
MmYzZTcgaXMgMjkyOTcwMDAhDQpbICAxODcuOTg0MDIwXSAyZjNlOCBpcyAyOTI5ODAwMCEN
ClsgIDE4Ny45ODU2ODJdIDJmM2U5IGlzIDI5MjhlMDAwIQ0KWyAgMTg3Ljk4NzM3Nl0gMmYz
ZDQgaXMgMjkyOTkwMDAhDQpbICAxODcuOTg5MDcxXSAyZjNkNSBpcyAyOTI5YTAwMCENClsg
IDE4Ny45OTA3NjJdIDJmM2Q2IGlzIDI5MjliMDAwIQ0KWyAgMTg3Ljk5MjQyOV0gMmYzZDcg
aXMgMjkyOWMwMDAhDQpbICAxODcuOTk0MTE3XSAyZjNkOCBpcyAyOTI5ZDAwMCENClsgIDE4
Ny45OTU4MDBdIDJmM2Q5IGlzIDI5MjllMDAwIQ0KWyAgMTg3Ljk5NzQ3Nl0gMmYzZGEgaXMg
MjkyOWYwMDAhDQpbICAxODcuOTk5MTYwXSAyZjNkYiBpcyAyOTJhMDAwMCENClsgIDE4OC4w
MDA4NDZdIDJmM2RjIGlzIDI5MmExMDAwIQ0KWyAgMTg4LjAwMjUzNl0gMmYzZGQgaXMgMjky
YTIwMDAhDQpbICAxODguMDA0MjM5XSAyZjNkZSBpcyAyOTJhMzAwMCENClsgIDE4OC4wMDYy
ODJdIDJmM2VhIGlzIDI5MjhkMDAwIQ0KWyAgMTg4LjAwODQwN10gMmYzZWIgaXMgMjkyOGMw
MDAhDQpbICAxODguMDEwNTAxXSAyZjNlYyBpcyAyOTI4YjAwMCENClsgIDE4OC4wMTI2MDRd
IDJmM2VkIGlzIDI5MjhhMDAwIQ0KWyAgMTg4LjAxNDY4Nl0gMmYzZWUgaXMgMjkyODkwMDAh
DQpbICAxODguMDMyNzIxXSAyZjNlZiBpcyAyOTI4ODAwMCENClsgIDE4OC4wMzQ4MDZdIDJm
M2YwIGlzIDI5Mjg3MDAwIQ0KWyAgMTg4LjAzNjkwM10gMmYzZjEgaXMgMjkyODYwMDAhDQpb
ICAxODguMDM4OTMyXSAyZjNmMiBpcyAyOTI4NTAwMCENClsgIDE4OC4wNDEwMzhdIDJmMzg4
IGlzIDI5Mjg0MDAwIQ0KWyAgMTg4LjA0MzExOF0gMmYzZjMgaXMgMjkyODMwMDAhDQpbICAx
ODguMDQ1MTc4XSAyZjNmNCBpcyAyOTI4MjAwMCENClsgIDE4OC4wNDcyMTFdIDJmMzg5IGlz
IDI5MjgxMDAwIQ0KWyAgMTg4LjA0OTMxM10gMmYzOGEgaXMgMjkyODAwMDAhDQpbICAxODgu
MDU4MTE3XSAyZjNmNSBpcyAyOTI3ZjAwMCENClsgIDE4OC4wNjAyMjNdIDJmMzhiIGlzIDI5
MjdlMDAwIQ0KWyAgMTg4LjA2MjI4M10gMmYzZjYgaXMgMjkyN2QwMDAhDQpbICAxODguMDY0
Mzc4XSAyZjNmNyBpcyAyOTI3YzAwMCENClsgIDE4OC4wNjY0NjNdIDJmM2Y4IGlzIDI5Mjdi
MDAwIQ0KWyAgMTg4LjA2ODU3OV0gMmYzZjkgaXMgMjkyN2EwMDAhDQpbICAxODguMDcwNjY3
XSAyZjNmYSBpcyAyOTI3OTAwMCENClsgIDE4OC4wNzI3NDZdIDJmM2ZiIGlzIDI5Mjc4MDAw
IQ0KWyAgMTg4LjA3NDgzMV0gMmYzZmMgaXMgMjkyNzcwMDAhDQpbICAxODguMDc2OTA1XSAy
ZjNmZCBpcyAyOTI3NjAwMCENClsgIDE4OC4wNzg5MjFdIDJmM2ZlIGlzIDI5Mjc1MDAwIQ0K
WyAgMTg4LjA4MTAwN10gMmYzOGQgaXMgMjkyNzQwMDAhDQpbICAxODguMDgzMDk2XSAyZjNm
ZiBpcyAyOTI3MzAwMCENClsgIDE4OC4wODUxNTZdIDJlYzAwIGlzIDI5MjcyMDAwIQ0KWyAg
MTg4LjA4NzIzNV0gMmYzOGUgaXMgMjkyNzEwMDAhDQpbICAxODguMDg5MzMxXSAyZjM4ZiBp
cyAyOTI3MDAwMCENClsgIDE4OC4wOTEzOTBdIDJlYzAxIGlzIDI5MjZmMDAwIQ0KWyAgMTg4
LjA5MzU3N10gMmYzOTAgaXMgMjkyNmUwMDAhDQpbICAxODguMDk1NzE4XSAyZWMwMiBpcyAy
OTI2ZDAwMCENClsgIDE4OC4wOTc4ODBdIDJlYzAzIGlzIDI5MjZjMDAwIQ0KWyAgMTg4LjEw
MDA0OV0gMmVjMDQgaXMgMjkyNmIwMDAhDQpbICAxODguMTAyMjA2XSAyZWMwNSBpcyAyOTI2
YTAwMCENClsgIDE4OC4xMDQ0MDRdIDJlYzA2IGlzIDI5MjY5MDAwIQ0KWyAgMTg4LjEwNjU1
NF0gMmVjMDcgaXMgMjkyNjgwMDAhDQpbICAxODguMTA4NzcyXSAyZWMwOCBpcyAyOTI2NzAw
MCENClsgIDE4OC4xMTM0ODRdIDJlYzA5IGlzIDI5MjQxMDAwIQ0KWyAgMTg4LjExNTczOF0g
MmYzOTEgaXMgMjkyNDIwMDAhDQpbICAxODguMTE3OTE0XSAyZWMwYSBpcyAyOTI0MzAwMCEN
ClsgIDE4OC4xMjAxODJdIDJmMzkyIGlzIDI5MjQ0MDAwIQ0KWyAgMTg4LjEyNjAxMl0gMmVj
MGIgaXMgMjkyNDUwMDAhDQpbICAxODguMTI4MjYyXSAyZjM5MyBpcyAyOTI0YzAwMCENClsg
IDE4OC4xMzA1MjNdIDJlYzBjIGlzIDI5MjViMDAwIQ0KWyAgMTg4LjEzMjgwN10gMmVjMGQg
aXMgMjkyNWEwMDAhDQpbICAxODguMTM1MDUxXSAyZWMwZSBpcyAyOTI1YzAwMCENClsgIDE4
OC4xMzczMzVdIDJlYzBmIGlzIDI5MjVkMDAwIQ0KWyAgMTg4LjEzOTU4MV0gMmVjMTAgaXMg
MjkyNTcwMDAhDQpbICAxODguMTQxODUyXSAyZWMxMSBpcyAyOTI1NjAwMCENClsgIDE4OC4x
NDQxMzRdIDJlYzEyIGlzIDI5MjU1MDAwIQ0KWyAgMTg4LjE0NjM5OV0gMmVjMTMgaXMgMjky
NTQwMDAhDQpbICAxODguMTQ4NjU1XSAyZWMxNCBpcyAyOTI1MzAwMCENClsgIDE4OC4xNTA5
MzJdIDJlYzE1IGlzIDI5MjUxMDAwIQ0KWyAgMTg4LjE1MzIwNl0gMmVjMTYgaXMgMjkyNTgw
MDAhDQpbICAxODguMTU1NDg2XSAyZWMxNyBpcyAyOTI0ZjAwMCENClsgIDE4OC4xNTc3ODBd
IDJlYzE4IGlzIDI5MjRiMDAwIQ0KWyAgMTg4LjE2MDA1OV0gMmVjMTkgaXMgMjkyNWUwMDAh
DQpbICAxODguMTYyMzM3XSAyZWMxYSBpcyAyOTI0NjAwMCENClsgIDE4OC4xNjQ2MDBdIDJl
YzFiIGlzIDI5MjUwMDAwIQ0KWyAgMTg4LjE2NjkxM10gMmVjMWMgaXMgMjkyNTkwMDAhDQpb
ICAxODguMTY5MTE1XSAyZWMxZCBpcyAyOTI0ZDAwMCENClsgIDE4OC4xODE5NzJdIDJmMzk0
IGlzIDI5MjRlMDAwIQ0KWyAgMTg4LjE4NDE3NF0gMmYzOTUgaXMgMjkzOGEwMDAhDQpbICAx
ODguMTg2NDQwXSAyZjM5NiBpcyAyOTI2NDAwMCENClsgIDE4OC4xODg2MzZdIDJlYzFlIGlz
IDI5MjY1MDAwIQ0KWyAgMTg4LjE5MDg5M10gMmYzOTcgaXMgMjg5ZjQwMDAhDQpbICAxODgu
MTkzMTkyXSAyZjM5OCBpcyAyOTM3ZDAwMCENClsgIDE4OC4xOTU1MDldIDJlYzFmIGlzIDI4
OWY1MDAwIQ0KWyAgMTg4LjE5NzkxMV0gMmYzOTkgaXMgMjkyNGEwMDAhDQpbICAxODguMjAw
MzAxXSAyZWMyMCBpcyAyOGU0NjAwMCENClsgIDE4OC4yMDI3MDZdIDJlYzIxIGlzIDI5Mzdm
MDAwIQ0KWyAgMTg4LjIwNTEwMl0gMmVjMjIgaXMgMjkyNjIwMDAhDQpbICAxODguMjA3NDkz
XSAyZWMyMyBpcyAyOTI2MTAwMCENClsgIDE4OC4yMDk4NTldIDJlYzI0IGlzIDI5MjYwMDAw
IQ0KWyAgMTg4LjIxMjIxOF0gMmVjMjUgaXMgMjkyNWYwMDAhDQpbICAxODguMjE0NTUxXSAy
ZWMyNiBpcyAyODFmZTAwMCENClsgIDE4OC4yMTY5MTRdIDJlYzI3IGlzIDI4MWZkMDAwIQ0K
WyAgMTg4LjIxOTIyNl0gMmVjMjggaXMgMjkyM2UwMDAhDQpbICAxODguMjIxNTkyXSAyZjM5
YSBpcyAyOTIzZDAwMCENClsgIDE4OC4yMzA3ODddIDJlYzI5IGlzIDI5MjNjMDAwIQ0KWyAg
MTg4LjIzMzIxNF0gMmYzOWIgaXMgMjkyM2IwMDAhDQpbICAxODguMjQ5NTQxXSAyZWMyYSBp
cyAyOTIzYTAwMCENClsgIDE4OC4yNTE5NzNdIDJmMzljIGlzIDI5MjM5MDAwIQ0KWyAgMTg4
LjI1NDQzOV0gMmVjM2EgaXMgMjkyMzgwMDAhDQpbICAxODguMjU2OTQ5XSAyZWMzYiBpcyAy
OTIzNzAwMCENClsgIDE4OC4yNTkzNTZdIDJlYzJiIGlzIDI5MjM2MDAwIQ0KWyAgMTg4LjI2
ODA4MV0gMmVjM2MgaXMgMjkyMzUwMDAhDQpbICAxODguMjcwNTgzXSAyZWMyYyBpcyAyOTIz
NDAwMCENClsgIDE4OC4yNzMxMDNdIDJlYzNkIGlzIDI5MjMzMDAwIQ0KWyAgMTg4LjI3NTU2
NV0gMmVjMmQgaXMgMjkyMzIwMDAhDQpbICAxODguMjc4MDI1XSAyZWMzZSBpcyAyOTIzMTAw
MCENClsgIDE4OC4yODA0NThdIDJlYzNmIGlzIDI5MjMwMDAwIQ0KWyAgMTg4LjI4Mjk1Ml0g
MmVjNDAgaXMgMjkyMmYwMDAhDQpbICAxODguMjg1MzgyXSAyZWMyZSBpcyAyOTIyZTAwMCEN
ClsgIDE4OC4yODc4ODldIDJlYzQxIGlzIDI5MjJkMDAwIQ0KWyAgMTg4LjI5MzI2MV0gMmVj
MmYgaXMgMjkyMmMwMDAhDQpbICAxODguMjk1NzA4XSAyZWM0MiBpcyAyOTIyYjAwMCENClsg
IDE4OC4yOTgwOTFdIDJlYzMwIGlzIDI5MjJhMDAwIQ0KWyAgMTg4LjMwMDQ3NV0gMmVjMzEg
aXMgMjkyMjkwMDAhDQpbICAxODguMzAyODQ2XSAyZWMzMiBpcyAyOTIyODAwMCENClsgIDE4
OC4zMDUxNzFdIDJlYzMzIGlzIDI5MjI3MDAwIQ0KWyAgMTg4LjMwNzQ3OF0gMmVjMzQgaXMg
MjkyMjYwMDAhDQpbICAxODguMzA5NzQ2XSAyZWMzNSBpcyAyOTIyNTAwMCENClsgIDE4OC4z
MTIwMjldIDJlYzM2IGlzIDI5MjI0MDAwIQ0KWyAgMTg4LjMxNDMxNF0gMmVjMzcgaXMgMjky
MjMwMDAhDQpbICAxODguMzE2NTk1XSAyZWMzOCBpcyAyOTIyMjAwMCENClsgIDE4OC4zMTg3
OTldIDJlYzM5IGlzIDI5MjIxMDAwIQ0KWyAgMTg4LjMyMTA2Ml0gMmVjNTkgaXMgMjkyMjAw
MDAhDQpbICAxODguMzIzMjkyXSAyZWM1YSBpcyAyOTIxZjAwMCENClsgIDE4OC4zMjU1MTdd
IDJlYzViIGlzIDI5MjFlMDAwIQ0KWyAgMTg4LjMyNzg2MV0gMmVjNWMgaXMgMjkyMWQwMDAh
DQpbICAxODguMzMwMDU5XSAyZWM0MyBpcyAyOTIxYzAwMCENClsgIDE4OC4zMzIyNTJdIDJl
YzVkIGlzIDI5MjFiMDAwIQ0KWyAgMTg4LjMzNDQyMV0gMmVjNWUgaXMgMjkyMWEwMDAhDQpb
ICAxODguMzM2NTY4XSAyZWM1ZiBpcyAyOTIxOTAwMCENClsgIDE4OC4zMzg2OTRdIDJlYzYw
IGlzIDI5MjE4MDAwIQ0KWyAgMTg4LjM0MDg1MV0gMmVjNjEgaXMgMjkyMTcwMDAhDQpbICAx
ODguMzQyOTc3XSAyZWM2MiBpcyAyOTIxNjAwMCENClsgIDE4OC4zNDUxNjldIDJlYzYzIGlz
IDI5MjE1MDAwIQ0KWyAgMTg4LjM1MTYzOF0gMmVjNjQgaXMgMjkyMTQwMDAhDQpbICAxODgu
MzUzNzk2XSAyZWM2NSBpcyAyOTIxMzAwMCENClsgIDE4OC4zNTU5MThdIDJlYzY2IGlzIDI5
MjEyMDAwIQ0KWyAgMTg4LjM1ODA2Ml0gMmVjNjcgaXMgMjkyMTEwMDAhDQpbICAxODguMzk1
Njg4XSAyZWM2OCBpcyAyOTIxMDAwMCENClsgIDE4OC4zOTc4MjNdIDJlYzQ0IGlzIDI5MjBm
MDAwIQ0KWyAgMTg4LjM5OTk2Ml0gMmVjNjkgaXMgMjkyMGUwMDAhDQpbICAxODguNDExODky
XSAyZWM2YSBpcyAyOTIwZDAwMCENClsgIDE4OC40MTQwMjRdIDJlYzZiIGlzIDI5MjBjMDAw
IQ0KWyAgMTg4LjQxNjE3OV0gMmVjNmMgaXMgMjkyMGIwMDAhDQpbICAxODguNDUxMDc4XSAy
ZWM2ZCBpcyAyOTIwYTAwMCENClsgIDE4OC40NTMyMTddIDJlYzZlIGlzIDI5MjA5MDAwIQ0K
WyAgMTg4LjQ1NTMxOF0gMmVjNmYgaXMgMjkyMDgwMDAhDQpbICAxODguNDU3NDQwXSAyZWM3
MCBpcyAyOTIwNzAwMCENClsgIDE4OC40NTk1NjBdIDJlYzcxIGlzIDI5MjA2MDAwIQ0KWyAg
MTg4LjQ2NTE1MF0gMmVjNzIgaXMgMjkyMDUwMDAhDQpbICAxODguNDY3MjY5XSAyZWM3MyBp
cyAyOTIwNDAwMCENClsgIDE4OC40NjkzOTNdIDJlYzc0IGlzIDI5MjAzMDAwIQ0KWyAgMTg4
LjQ3MTQ5N10gMmVjNzUgaXMgMjkyMDIwMDAhDQpbICAxODguNDczNjMwXSAyZWM3NiBpcyAy
OTIwMTAwMCENClsgIDE4OC40NzU3NDJdIDJlYzc3IGlzIDI5MjAwMDAwIQ0KWyAgMTg4LjQ4
NjQyNF0gMmVjNzggaXMgMjkxZmYwMDAhDQpbICAxODguNDg4NTUyXSAyZWM3OSBpcyAyOTFm
ZTAwMCENClsgIDE4OC40OTA2ODFdIDJlYzdhIGlzIDI5MWZkMDAwIQ0KWyAgMTg4LjQ5NjM4
OV0gMmVjN2IgaXMgMjkxZmMwMDAhDQpbICAxODguNDk4NjQzXSAyZWM0NSBpcyAyOTFmYjAw
MCENClsgIDE4OC41MDA4NzNdIDJlYzdjIGlzIDI5MWZhMDAwIQ0KWyAgMTg4LjUwMzAwNF0g
MmVjN2QgaXMgMjkxZjkwMDAhDQpbICAxODguNTA1MzI5XSAyZWM3ZSBpcyAyOTFmODAwMCEN
ClsgIDE4OC41MDc1NzBdIDJlYzdmIGlzIDI5MWY3MDAwIQ0KWyAgMTg4LjUwOTY5NV0gMmVj
ODAgaXMgMjkxZjYwMDAhDQpbICAxODguNTExOTkxXSAyZWM4MSBpcyAyOTFmNTAwMCENClsg
IDE4OC41MTQyMTddIDJlYzgyIGlzIDI5MWY0MDAwIQ0KWyAgMTg4LjUxNjM0NV0gMmVjODMg
aXMgMjkxZjMwMDAhDQpbICAxODguNTE4NjM4XSAyZWM4NCBpcyAyOTFmMjAwMCENClsgIDE4
OC41MjA4NjJdIDJlYzg1IGlzIDI5MWYxMDAwIQ0KWyAgMTg4LjUyMjk4MF0gMmVjODYgaXMg
MjkxZjAwMDAhDQpbICAxODguNTI1MjU2XSAyZWM4NyBpcyAyOTFlZjAwMCENClsgIDE4OC41
Mjc0ODNdIDJlYzg4IGlzIDI5MWVlMDAwIQ0KWyAgMTg4LjUyOTU3OF0gMmVjODkgaXMgMjkx
ZWQwMDAhDQpbICAxODguNTMxODYyXSAyZWM4YSBpcyAyOTFlYzAwMCENClsgIDE4OC41MzQw
NDJdIDJlYzhiIGlzIDI5MWViMDAwIQ0KWyAgMTg4LjUzNjE0OV0gMmVjOGMgaXMgMjkxZWEw
MDAhDQpbICAxODguNTM4NDE0XSAyZWM4ZCBpcyAyOTFlOTAwMCENClsgIDE4OC41NDA2MDhd
IDJlYzhmIGlzIDI5MWU4MDAwIQ0KWyAgMTg4LjU0MjY5OF0gMmVjOTAgaXMgMjkxZTcwMDAh
DQpbICAxODguNTQ0OTI5XSAyZWM5MSBpcyAyOTFlNjAwMCENClsgIDE4OC41NDk1MjFdIDJl
YzkyIGlzIDI5MWU1MDAwIQ0KWyAgMTg4LjU1MTY3Nl0gMmVjNDYgaXMgMjkxZTQwMDAhDQpb
ICAxODguNTUzODM3XSAyZWM5MyBpcyAyOTFlMzAwMCENClsgIDE4OC41NTU5MzhdIDJlYzk0
IGlzIDI5MWUyMDAwIQ0KWyAgMTg4LjU1ODE0OV0gMmVjOTUgaXMgMjkxZTEwMDAhDQpbICAx
ODguNTYwMjA1XSAyZWM5NiBpcyAyOTFlMDAwMCENClsgIDE4OC41NjI0MDRdIDJlYzk3IGlz
IDI5MWRmMDAwIQ0KWyAgMTg4LjU2NDUwM10gMmVjNDcgaXMgMjkxZGUwMDAhDQpbICAxODgu
NTY2NTY2XSAyZWM5OCBpcyAyOTFkZDAwMCENClsgIDE4OC41Njg2MTVdIDJlYzk5IGlzIDI5
MWRjMDAwIQ0KWyAgMTg4LjU3MDY2MV0gMmVjNDggaXMgMjkxZGIwMDAhDQpbICAxODguNTcy
NzQ2XSAyZWM0OSBpcyAyOTFkYTAwMCENClsgIDE4OC41NzQ3NzldIDJlYzlhWyAgMTkwLjcw
MTc1N10gMmU4YjIgaXMgMjlkMGUwMDAhDQpbICAxOTAuNzAzNDg2XSAyZThiMyBpcyAyOWQw
ZjAwMCENClsgIDE5MC43MDUxNzZdIDJlOGI0IGlzIDI5ZDEwMDAwIQ0KWyAgMTkwLjcwNjg5
MV0gMmU4YjUgaXMgMjlkMTEwMDAhDQpbICAxOTAuNzA4NTY0XSAyZTg5ZiBpcyAyOWQxMjAw
MCENClsgIDE5MC43MTAyNTVdIDJlOGEyIGlzIDI5ZDEzMDAwIQ0KWyAgMTkwLjcxMTk2N10g
MmU4YTMgaXMgMjlkMTQwMDAhDQpbICAxOTAuNzEzNjczXSAyZThhNCBpcyAyOWQxNTAwMCEN
ClsgIDE5MC43MTUzNjhdIDJlOGE1IGlzIDI5ZDE2MDAwIQ0KWyAgMTkwLjcxNzA1OF0gMmU4
YTYgaXMgMjlkMTcwMDAhDQpbICAxOTAuNzE4NzMxXSAyZThhNyBpcyAyOWQxODAwMCENClsg
IDE5MC43MjA0NDRdIDJlOGE4IGlzIDI5ZDE5MDAwIQ0KWyAgMTkwLjcyMjEzMl0gMmU4YTkg
aXMgMjlkMWEwMDAhDQpbICAxOTAuNzIzODUxXSAyZThhYSBpcyAyOWQxYjAwMCENClsgIDE5
MC43Mzg1NzFdIDJlOGNiIGlzIDI5Y2U3MDAwIQ0KWyAgMTkwLjc0MDI4N10gMmU4Y2MgaXMg
MjljZTgwMDAhDQpbICAxOTAuNzQxOTc3XSAyZThjZCBpcyAyOWNlOTAwMCENClsgIDE5MC43
NDM3NDldIDJlOGNlIGlzIDI5Y2VhMDAwIQ0KWyAgMTkwLjc0NTQ1MF0gMmU4Y2YgaXMgMjlj
ZWIwMDAhDQpbICAxOTAuNzQ3MTQ5XSAyZThkMCBpcyAyOWNlYzAwMCENClsgIDE5MC43NDg4
NjRdIDJlOGQxIGlzIDI5Y2VkMDAwIQ0KWyAgMTkwLjc1MDU4NV0gMmU4ZDIgaXMgMjljZWUw
MDAhDQpbICAxOTAuNzUyMjk1XSAyZThkMyBpcyAyOWNlZjAwMCENClsgIDE5MC43NTQwMzNd
IDJlOGQ0IGlzIDI5Y2YwMDAwIQ0KWyAgMTkwLjc1NTc0M10gMmU4ZDUgaXMgMjljZjEwMDAh
DQpbICAxOTAuNzU3NDYyXSAyZThkNiBpcyAyOWNkYzAwMCENClsgIDE5MC43NTkxNTBdIDJl
OGQ3IGlzIDI5Y2RkMDAwIQ0KWyAgMTkwLjc2MDg2OF0gMmU4ZDggaXMgMjljZGUwMDAhDQpb
ICAxOTAuNzYyNTYwXSAyZThkOSBpcyAyOWNkZjAwMCENClsgIDE5MC43NjQyNjNdIDJlOGRh
IGlzIDI5Y2UwMDAwIQ0KWyAgMTkwLjc2NTk2MF0gMmU4ZGIgaXMgMjljZTEwMDAhDQpbICAx
OTAuNzY3NjQwXSAyZThkYyBpcyAyOWNlMjAwMCENClsgIDE5MC43NjkzMjBdIDJlOGRkIGlz
IDI5Y2UzMDAwIQ0KWyAgMTkwLjc3MDk4M10gMmU4ZGUgaXMgMjljZTQwMDAhDQpbICAxOTAu
NzcyNjM4XSAyZThkZiBpcyAyOWNlNTAwMCENClsgIDE5MC43NzQzMjFdIDJlOGUwIGlzIDI5
Y2U2MDAwIQ0KWyAgMTkwLjc3NTk3Nl0gMmU4ZTEgaXMgMjljZDIwMDAhDQpbICAxOTAuNzc3
NjUxXSAyZThlMiBpcyAyOWNkMzAwMCENClsgIDE5MC43NzkzMDJdIDJlOGUzIGlzIDI5Y2Q0
MDAwIQ0KWyAgMTkwLjc4MDk2M10gMmU4ZTQgaXMgMjljZDUwMDAhDQpbICAxOTAuNzgyNjM0
XSAyZThlNSBpcyAyOWNkNjAwMCENClsgIDE5MC43ODQzMDddIDJlOGU2IGlzIDI5Y2Q3MDAw
IQ0KWyAgMTkwLjc4NTk4Ml0gMmU4ZTcgaXMgMjljZDgwMDAhDQpbICAxOTAuNzg3NjQ5XSAy
ZThlOCBpcyAyOWNkOTAwMCENClsgIDE5MC43ODkzMDVdIDJlOGU5IGlzIDI5Y2RhMDAwIQ0K
WyAgMTkwLjc5MDk4OV0gMmU4ZWEgaXMgMjljZGIwMDAhDQpbICAxOTAuNzkyNzA3XSAyZThl
YiBpcyAyOWNkMTAwMCENClsgIDE5MC43OTQ3MTVdIDJlOGVjIGlzIDI5Y2QwMDAwIQ0KWyAg
MTkwLjgwMjY0NV0gMmU4MWQgaXMgMjljY2YwMDAhDQpbICAxOTAuODA0NjcxXSAyZThlZCBp
cyAyOWNjZTAwMCENClsgIDE5MC44MDY2ODddIDJlOGVlIGlzIDI5Y2NkMDAwIQ0KWyAgMTkw
LjgwODc5M10gMmU4ZWYgaXMgMjljY2MwMDAhDQpbICAxOTAuODEwODk2XSAyZThmMCBpcyAy
OWNjYjAwMCENClsgIDE5MC44MTI5MjFdIDJlOGYxIGlzIDI5Y2NhMDAwIQ0KWyAgMTkwLjgx
NTEwMl0gMmU4ZjIgaXMgMjljYzkwMDAhDQpbICAxOTAuODE3MTkzXSAyZThmMyBpcyAyOWNj
ODAwMCENClsgIDE5MC44MTkyMTVdIDJlOGY0IGlzIDI5Y2M3MDAwIQ0KWyAgMTkwLjgyMTM4
MV0gMmU4ZjUgaXMgMjljYzYwMDAhDQpbICAxOTAuODIzNzA0XSAyZThmNiBpcyAyOWNjNDAw
MCENClsgIDE5MC44MjU3MTBdIDJlOGY3IGlzIDI5Y2MzMDAwIQ0KWyAgMTkwLjgyNzcwN10g
MmU4ZjggaXMgMjljYzIwMDAhDQpbICAxOTAuODI5NzE5XSAyZTgxZSBpcyAyOWNjMTAwMCEN
ClsgIDE5MC44MzE3MzBdIDJlODFmIGlzIDI5Y2MwMDAwIQ0KWyAgMTkwLjgzMzcyMF0gMmU4
ZjkgaXMgMjljYmYwMDAhDQpbICAxOTAuODM1NzQ3XSAyZThmYSBpcyAyOWNiZTAwMCENClsg
IDE5MC44NDY0MDJdIDJlOGZiIGlzIDI5Y2JkMDAwIQ0KWyAgMTkwLjg0ODQ0OF0gMmU4MjAg
aXMgMjljYmMwMDAhDQpbICAxOTAuODUwNjAwXSAyZThmYyBpcyAyOWNiYjAwMCENClsgIDE5
MC44NTI2MzddIDJlOGZkIGlzIDI5Y2JhMDAwIQ0KWyAgMTkwLjg1NDgzNF0gMmU4ZmUgaXMg
MjljYjkwMDAhDQpbICAxOTAuODU2ODg4XSAyZThmZiBpcyAyOWNiODAwMCENClsgIDE5MC44
NTg4NjhdIDJlOTAwIGlzIDI5Y2I3MDAwIQ0KWyAgMTkwLjg2MDg5M10gMmU4MjEgaXMgMjlj
YjYwMDAhDQpbICAxOTAuODYyOTI2XSAyZTkwMSBpcyAyOWNiNTAwMCENClsgIDE5MC44NjQ5
NDhdIDJlOTAyIGlzIDI5Y2I0MDAwIQ0KWyAgMTkwLjg2NjkyOV0gMmU5MDMgaXMgMjljYjMw
MDAhDQpbICAxOTAuODY4OTExXSAyZTgyMiBpcyAyOWNiMjAwMCENClsgIDE5MC44NzA5NDld
IDJlODIzIGlzIDI5Y2IxMDAwIQ0KWyAgMTkwLjg3Mjk3OF0gMmU5MDQgaXMgMjljYjAwMDAh
DQpbICAxOTAuODc1MDE3XSAyZTkwNSBpcyAyOWNhZjAwMCENClsgIDE5MC44ODk0NjVdIDJl
OTA2IGlzIDI5Y2FlMDAwIQ0KWyAgMTkwLjg5MTUyM10gMmU5MWUgaXMgMjljYWQwMDAhDQpb
ICAxOTAuODkzNTcwXSAyZTkwNyBpcyAyOWNhYzAwMCENClsgIDE5MC44OTU1OTddIDJlOTA4
IGlzIDI5Y2FiMDAwIQ0KWyAgMTkwLjg5NzY0NV0gMmU5MWYgaXMgMjljYWEwMDAhDQpbICAx
OTAuODk5NzEyXSAyZTkwOSBpcyAyOWNhOTAwMCENClsgIDE5MC45MDE3NTNdIDJlOTBhIGlz
IDI5Y2E4MDAwIQ0KWyAgMTkwLjkwMzc4OV0gMmU5MGIgaXMgMjljYTcwMDAhDQpbICAxOTAu
OTA1ODU2XSAyZTkyMCBpcyAyOWNhNjAwMCENClsgIDE5MC45MDc5MjFdIDJlOTBjIGlzIDI5
Y2E1MDAwIQ0KWyAgMTkwLjkwOTkzMF0gMmU5MGQgaXMgMjljYTQwMDAhDQpbICAxOTAuOTEy
MDEzXSAyZTkyMSBpcyAyOWNhMzAwMCENClsgIDE5MC45MjI2MDddIDJlOTBlIGlzIDI5Y2Ey
MDAwIQ0KWyAgMTkwLjkyNDcwNl0gMmU5MGYgaXMgMjljYTEwMDAhDQpbICAxOTAuOTI2Nzk3
XSAyZTkxMCBpcyAyOWNhMDAwMCENClsgIDE5MC45Mjg5MDNdIDJlOTExIGlzIDI5YzlmMDAw
IQ0KWyAgMTkwLjkzMTAxNF0gMmU5MTIgaXMgMjljOWUwMDAhDQpbICAxOTAuOTQwMTcwXSAy
ZTkyMiBpcyAyOWM5ZDAwMCENClsgIDE5MC45NDIyNzNdIDJlOTIzIGlzIDI5YzljMDAwIQ0K
WyAgMTkwLjk0NDUyOV0gMmU5MTMgaXMgMjljOWIwMDAhDQpbICAxOTAuOTQ2NjA3XSAyZTkx
NCBpcyAyOWM5YTAwMCENClsgIDE5MC45NDg4NzRdIDJlOTE1IGlzIDI5Yzk5MDAwIQ0KWyAg
MTkwLjk1MDk3NV0gMmU5MTcgaXMgMjljOTgwMDAhDQpbICAxOTAuOTUzMDg4XSAyZTkxOCBp
cyAyOWM5NzAwMCENClsgIDE5MC45NTUzMzZdIDJlOTE5IGlzIDI5Yzk2MDAwIQ0KWyAgMTkw
Ljk1NzUxOF0gMmU5MWEgaXMgMjljOTUwMDAhDQpbICAxOTAuOTU5NTk3XSAyZTkxYiBpcyAy
OWM5NDAwMCENClsgIDE5MC45NjE4ODJdIDJlOTFjIGlzIDI5YzkzMDAwIQ0KWyAgMTkwLjk2
NDA2M10gMmU5MWQgaXMgMjljOTIwMDAhDQpbICAxOTAuOTY2MTQ3XSAyZTkzZCBpcyAyOWM5
MTAwMCENClsgIDE5MC45NjgzNzVdIDJlOTNlIGlzIDI5YzkwMDAwIQ0KWyAgMTkwLjk3MDUw
Nl0gMmU5M2YgaXMgMjljOGYwMDAhDQpbICAxOTAuOTcyNTQxXSAyZTk0MCBpcyAyOWM4ZTAw
MCENClsgIDE5MC45NzQ3MTddIDJlOTQxIGlzIDI5YzhkMDAwIQ0KWyAgMTkwLjk3NzA5OF0g
MmU5NDIgaXMgMjljOGIwMDAhDQpbICAxOTAuOTc5MTM3XSAyZTk0MyBpcyAyOWM4YTAwMCEN
ClsgIDE5MC45ODUyMjVdIDJlOTQ0IGlzIDI5Yzg5MDAwIQ0KWyAgMTkwLjk4NzI5MF0gMmU5
MjQgaXMgMjljODgwMDAhDQpbICAxOTAuOTg5MzI4XSAyZTkyNSBpcyAyOWM4NzAwMCENClsg
IDE5MC45OTEzOTFdIDJlOTQ1IGlzIDI5Yzg2MDAwIQ0KWyAgMTkwLjk5Mzc3Nl0gMmU5MjYg
aXMgMjljODQwMDAhDQpbICAxOTAuOTk1ODEwXSAyZTk0NiBpcyAyOWM4MzAwMCENClsgIDE5
MC45OTc4ODNdIDJlOTQ3IGlzIDI5YzgyMDAwIQ0KWyAgMTkwLjk5OTg4Nl0gMmU5NDggaXMg
MjljODEwMDAhDQpbICAxOTEuMDAxOTEzXSAyZTk0OSBpcyAyOWM4MDAwMCENClsgIDE5MS4w
MDM5ODJdIDJlOTRhIGlzIDI5YzdmMDAwIQ0KWyAgMTkxLjAwNjAwNV0gMmU5NGIgaXMgMjlj
N2UwMDAhDQpbICAxOTEuMDA4MDczXSAyZTk0YyBpcyAyOWM3ZDAwMCENClsgIDE5MS4wMTA0
MzBdIDJlOTRkIGlzIDI5YzdiMDAwIQ0KWyAgMTkxLjAxMjQ0MV0gMmU5NGUgaXMgMjljN2Ew
MDAhDQpbICAxOTEuMDE0NDg1XSAyZTk0ZiBpcyAyOWM3OTAwMCENClsgIDE5MS4wMTY1MDBd
IDJlOTUwIGlzIDI5Yzc4MDAwIQ0KWyAgMTkxLjAxODU0Ml0gMmU5NTEgaXMgMjljNzcwMDAh
DQpbICAxOTEuMDIwNTgzXSAyZTk1MiBpcyAyOWM3NjAwMCENClsgIDE5MS4wMjI1ODJdIDJl
OTUzIGlzIDI5Yzc1MDAwIQ0KWyAgMTkxLjAyNDYyMl0gMmU5NTQgaXMgMjljNzQwMDAhDQpb
ICAxOTEuMDI2NjA1XSAyZTk1NSBpcyAyOWM3MzAwMCENClsgIDE5MS4wMjg2MzVdIDJlOTU2
IGlzIDI5YzcyMDAwIQ0KWyAgMTkxLjAzMDYyOF0gMmU5NTcgaXMgMjljNzEwMDAhDQpbICAx
OTEuMDMyNjA0XSAyZTk1OCBpcyAyOWM3MDAwMCENClsgIDE5MS4wNDQxOThdIDJlOTU5IGlz
IDI5YzZmMDAwIQ0KWyAgMTkxLjA0NjE4MF0gMmU5MjcgaXMgMjljNmUwMDAhDQpbICAxOTEu
MDQ4MTgxXSAyZTk1YSBpcyAyOWM2ZDAwMCENClsgIDE5MS4wNTAyMTFdIDJlOTI4IGlzIDI5
YzZjMDAwIQ0KWyAgMTkxLjA1MjE5MV0gMmU5NWIgaXMgMjljNmIwMDAhDQpbICAxOTEuMDU0
MTk4XSAyZTk1YyBpcyAyOWM2YTAwMCENClsgIDE5MS4wNTYxODRdIDJlOTI5IGlzIDI5YzY5
MDAwIQ0KWyAgMTkxLjA1ODIxMV0gMmU5NWQgaXMgMjljNjgwMDAhDQpbICAxOTEuMDYwMjE0
XSAyZTk1ZSBpcyAyOWM2NzAwMCENClsgIDE5MS4wNjIyMTNdIDJlOTVmIGlzIDI5YzY2MDAw
IQ0KWyAgMTkxLjA2NDIxOV0gMmU5NjAgaXMgMjljNjUwMDAhDQpbICAxOTEuMDY2MTk0XSAy
ZTk2MSBpcyAyOWM2NDAwMCENClsgIDE5MS4wNjgxOThdIDJlOTYyIGlzIDI5YzYzMDAwIQ0K
WyAgMTkxLjA3MDE1OF0gMmU5NjMgaXMgMjljNjIwMDAhDQpbICAxOTEuMDcyMTk3XSAyZTk2
NCBpcyAyOWM2MTAwMCENClsgIDE5MS4wNzQxNjBdIDJlOTJhIGlzIDI5YzYwMDAwIQ0KWyAg
MTkxLjA3NjA2M10gMmU5NjUgaXMgMjljNWYwMDAhDQpbICAxOTEuMDc4MDE1XSAyZTk2NiBp
cyAyOWM1ZTAwMCENClsgIDE5MS4wNzk5MTldIDJlOTY3IGlzIDI5YzVkMDAwIQ0KWyAgMTkx
LjA4MTg3MV0gMmU5NjggaXMgMjljNWMwMDAhDQpbICAxOTEuMDgzODAwXSAyZTk2OSBpcyAy
OWM1YjAwMCENClsgIDE5MS4wODU3MThdIDJlOTZhIGlzIDI5YzVhMDAwIQ0KWyAgMTkxLjA4
NzY1Nl0gMmU5NmIgaXMgMjljNTkwMDAhDQpbICAxOTEuMTA0MDIzXSAyZTk2YyBpcyAyOWM1
ODAwMCENClsgIDE5MS4xMDU5NTldIDJlOTJiIGlzIDI5YzU3MDAwIQ0KWyAgMTkxLjEwODAy
N10gMmU5NmQgaXMgMjljNTYwMDAhDQpbICAxOTEuMTEwMDEyXSAyZTk2ZSBpcyAyOWM1NTAw
MCENClsgIDE5MS4xMTIxOTBdIDJlOTZmIGlzIDI5YzU0MDAwIQ0KWyAgMTkxLjExNDI3N10g
MmU5NzAgaXMgMjljNTMwMDAhDQpbICAxOTEuMTE2Mjk1XSAyZTk3MSBpcyAyOWM1MjAwMCEN
ClsgIDE5MS4xMTg0NTBdIDJlOTcyIGlzIDI5YzUxMDAwIQ0KWyAgMTkxLjEyMDU3M10gMmU5
NzMgaXMgMjljNTAwMDAhDQpbICAxOTEuMTIyNTU5XSAyZTk3NCBpcyAyOWM0ZjAwMCENClsg
IDE5MS4xMjQ3MzNdIDJlOTc1IGlzIDI5YzRlMDAwIQ0KWyAgMTkxLjEyNzA2OV0gMmU5NzYg
aXMgMjljNGMwMDAhDQpbICAxOTEuMTI5MDU0XSAyZTk3NyBpcyAyOWM0YjAwMCENClsgIDE5
MS4xMzEwNjFdIDJlOTc4IGlzIDI5YzRhMDAwIQ0KWyAgMTkxLjEzMzA0MF0gMmU5NzkgaXMg
MjljNDkwMDAhDQpbICAxOTEuMTM1MDQ1XSAyZTk3YSBpcyAyOWM0ODAwMCENClsgIDE5MS4x
Mzg2MTddIDJlOTdiIGlzIDI5YzE0MDAwIQ0KWyAgMTkxLjE0MDcwMl0gMmU5MmMgaXMgMjlj
MTUwMDAhDQpbICAxOTEuMTQyNjk5XSAyZTk3YyBpcyAyOWMxNjAwMCENClsgIDE5MS4xNDQ4
MzRdIDJlOTdkIGlzIDI5YzE3MDAwIQ0KWyAgMTkxLjE0Njg1N10gMmU5N2UgaXMgMjljMTgw
MDAhDQpbICAxOTEuMTQ4ODc2XSAyZTk3ZiBpcyAyOWMxOTAwMCENClsgIDE5MS4xNTA4OTFd
IDJlOTgwIGlzIDI5YzFhMDAwIQ0KWyAgMTkxLjE1MjkyN10gMmU5MmQgaXMgMjljMWIwMDAh
DQpbICAxOTEuMTU0OTg1XSAyZTk4MSBpcyAyOWMxYzAwMCENClsgIDE5MS4xNTcwMTNdIDJl
OTgyIGlzIDI5YzFkMDAwIQ0KWyAgMTkxLjE1OTAzMl0gMmU5ODMgaXMgMjljMWUwMDAhDQpb
ICAxOTEuMTYxMTk0XSAyZTk4NCBpcyAyOWMxZjAwMCENClsgIDE5MS4xNjMyMDBdIDJlOTg1
IGlzIDI5YzIwMDAwIQ0KWyAgMTkxLjE2NTM3MF0gMmU5ODYgaXMgMjljMjEwMDAhDQpbICAx
OTEuMTY3NDYzXSAyZTk4NyBpcyAyOWMyMjAwMCENClsgIDE5MS4xNjk1MTVdIDJlOTg4IGlz
IDI5YzIzMDAwIQ0KWyAgMTkxLjE3MTY1NF0gMmU5ODkgaXMgMjljMjQwMDAhDQpbICAxOTEu
MTczNjg1XSAyZTk4YSBpcyAyOWMyNTAwMCENClsgIDE5MS4xNzU2ODFdIDJlOThiIGlzIDI5
YzJjMDAwIQ0KWyAgMTkxLjE3NzgxMl0gMmU5OGMgaXMgMjljM2YwMDAhDQpbICAxOTEuMTc5
ODA3XSAyZTk4ZCBpcyAyOWM0MDAwMCENClsgIDE5MS4xOTU2MDVdIDJlOThlIGlzIDI5YzNl
MDAwIQ0KWyAgMTkxLjE5NzcyOF0gMmU5MmUgaXMgMjljM2QwMDAhDQpbICAxOTEuMTk5NzU0
XSAyZTk4ZiBpcyAyOWM0MzAwMCENClsgIDE5MS4yMDE5MTJdIDJlOTkwIGlzIDI5YzQ0MDAw
IQ0KWyAgMTkxLjIwNDAyOF0gMmU5OTEgaXMgMjljNDUwMDAhDQpbICAxOTEuMjA2MDU4XSAy
ZTk5MiBpcyAyOWM0NjAwMCENClsgIDE5MS4yMDkyOTRdIDJlOTkzIGlzIDI5YzQ3MDAwIQ0K
WyAgMTkxLjIxMTQ0Nl0gMmU5OTQgaXMgMjljMzEwMDAhDQpbICAxOTEuMjEzNDk5XSAyZTk5
NSBpcyAyOWM0MjAwMCENClsgIDE5MS4yMTU1NTRdIDJlOTk2IGlzIDI5YzJmMDAwIQ0KWyAg
MTkxLjIxNzYyN10gMmU5OTcgaXMgMjljM2MwMDAhDQpbICAxOTEuMjE5NzExXSAyZTkyZiBp
cyAyOWMyNjAwMCENClsgIDE5MS4yMjE3ODhdIDJlOTk4IGlzIDI5YzMwMDAwIQ0KWyAgMTkx
LjIyMzkwMF0gMmU5MzAgaXMgMjljMmIwMDAhDQpbICAxOTEuMjMwNzcyXSAyZTkzMSBpcyAy
OWM0MTAwMCENClsgIDE5MS4yMzI5MDVdIDJlOTk5IGlzIDI5YzJkMDAwIQ0KWyAgMTkxLjIz
NTE5MF0gMmU5OWEgaXMgMjljMmUwMDAhDQpbICAxOTEuMjM3NDExXSAyZTk5YiBpcyAyOTVm
OTAwMCENClsgIDE5MS4yMzk1NDddIDJlOTljIGlzIDI5YzM4MDAwIQ0KWyAgMTkxLjI0MTgz
MV0gMmU5OWQgaXMgMjljMzkwMDAhDQpbICAxOTEuMjQ0MDg3XSAyZTk5ZSBpcyAyOWMzNzAw
MCENClsgIDE5MS4yNDYyMzVdIDJlOTlmIGlzIDI5NWVjMDAwIQ0KWyAgMTkxLjI1NzgwN10g
MmU5YTAgaXMgMjkzOTUwMDAhDQpbICAxOTEuMjU5OTgyXSAyZTkzMiBpcyAyOWMyYTAwMCEN
ClsgIDE5MS4yNjg4NjNdIDJlOWExIGlzIDI5MGE5MDAwIQ0KWyAgMTkxLjI3MTMxNV0gMmU5
YTIgaXMgMjk4NTgwMDAhDQpbICAxOTEuMjczNTQyXSAyZTlhMyBpcyAyOWMxMzAwMCENClsg
IDE5MS4yNzU4ODddIDJlOWE0IGlzIDI5YzM2MDAwIQ0KWyAgMTkxLjI3ODE2N10gMmU5MzMg
aXMgMjljMzUwMDAhDQpbICAxOTEuMjg1NDIzXSAyZTlhNSBpcyAyOWMzNDAwMCENClsgIDE5
MS4yODc3MTldIDJlOTM0IGlzIDI5YzMzMDAwIQ0KWyAgMTkxLjI5MDAwN10gMmU5MzUgaXMg
MjljMTIwMDAhDQpbICAxOTEuMjkyMjkxXSAyZTlhNiBpcyAyOWMxMTAwMCENClsgIDE5MS4y
OTQ2MDhdIDJlOTM2IGlzIDI5YzEwMDAwIQ0KWyAgMTkxLjI5NjkzMF0gMmU5MzcgaXMgMjlj
MGYwMDAhDQpbICAxOTEuMjk5MzE3XSAyZTlhNyBpcyAyOWMwZTAwMCENClsgIDE5MS4zMDE2
MDBdIDJlOTM4IGlzIDI5YzBkMDAwIQ0KWyAgMTkxLjMwMzkwNF0gMmU5YTggaXMgMjljMGMw
MDAhDQpbICAxOTEuMzIwNTA1XSAyZTkzOSBpcyAyOWMwYjAwMCENClsgIDE5MS4zMjI4MjFd
IDJlOTNhIGlzIDI5YzBhMDAwIQ0KWyAgMTkxLjMyNTI5NV0gMmU5YTkgaXMgMjljMDkwMDAh
DQpbICAxOTEuMzI3NzAxXSAyZTlhYSBpcyAyOWMwODAwMCENClsgIDE5MS4zMjk5ODRdIDJl
OWFiIGlzIDI5YzA3MDAwIQ0KWyAgMTkxLjMzMjQyM10gMmU5YWMgaXMgMjljMDYwMDAhDQpb
ICAxOTEuMzM0NzkyXSAyZTlhZSBpcyAyOWMwNTAwMCENClsgIDE5MS4zMzcwNjldIDJlOWFm
IGlzIDI5YzA0MDAwIQ0KWyAgMTkxLjMzOTMxMV0gMmU5YjAgaXMgMjljMDMwMDAhDQpbICAx
OTEuMzQxNzA4XSAyZTliMSBpcyAyOWMwMjAwMCENClsgIDE5MS4zNDQwMjJdIDJlOWIyIGlz
IDI5YzAxMDAwIQ0KWyAgMTkxLjM0NjM5OV0gMmU5YjMgaXMgMjljMDAwMDAhDQpbICAxOTEu
MzQ4Njg2XSAyZTkzYiBpcyAyOWJmZjAwMCENClsgIDE5MS4zNTA5MzhdIDJlOWI0IGlzIDI5
YmZlMDAwIQ0KWyAgMTkxLjM1MzE3MF0gMmU5YjUgaXMgMjliZmQwMDAhDQpbICAxOTEuMzU1
NDA3XSAyZTliNiBpcyAyOWJmYzAwMCENClsgIDE5MS4zNTc2MzNdIDJlOWI3IGlzIDI5YmZi
MDAwIQ0KWyAgMTkxLjM1OTc5NF0gMmU5YjggaXMgMjliZmEwMDAhDQpbICAxOTEuMzc3NjE2
XSAyZTliOSBpcyAyOWJmOTAwMCENClsgIDE5MS4zNzk3NjNdIDJlOWJhIGlzIDI5YmY4MDAw
IQ0KWyAgMTkxLjM4MTkyMl0gMmU5YmIgaXMgMjliZjcwMDAhDQpbICAxOTEuMzg0MDY3XSAy
ZTkzYyBpcyAyOWJmNjAwMCENClsgIDE5MS4zODYyMjZdIDJlOWQ4IGlzIDI5YmY1MDAwIQ0K
WyAgMTkxLjM4ODM2OV0gMmU5YmMgaXMgMjliZjQwMDAhDQpbICAxOTEuMzkwNTU4XSAyZTlk
OSBpcyAyOWJmMzAwMCENClsgIDE5MS4zOTI2OTZdIDJlOWRhIGlzIDI5YmYyMDAwIQ0KWyAg
MTkxLjM5NDg4NV0gMmU5YmQgaXMgMjliZjEwMDAhDQpbICAxOTEuMzk3MDM4XSAyZTliZSBp
cyAyOWJmMDAwMCENClsgIDE5MS4zOTkxODldIDJlOWJmIGlzIDI5YmVmMDAwIQ0KWyAgMTkx
LjQwMTUyMF0gMmU5YzAgaXMgMjliZWUwMDAhDQpbICAxOTEuNDExNTQ4XSAyZTljMSBpcyAy
OWJlZDAwMCENClsgIDE5MS40MTM3MDddIDJlOWRiIGlzIDI5YmVjMDAwIQ0KWyAgMTkxLjQx
NTg2Nl0gMmU5YzIgaXMgMjliZWIwMDAhDQpbICAxOTEuNDE4MTY3XSAyZTljMyBpcyAyOWJl
YTAwMCENClsgIDE5MS40MjAyMjhdIDJlOWM0IGlzIDI5YmU5MDAwIQ0KWyAgMTkxLjQyMjQ3
Nl0gMmU5YzUgaXMgMjliZTgwMDAhDQpbICAxOTEuNDI0NjM0XSAyZTlkYyBpcyAyOWJlNzAw
MCENClsgIDE5MS40MjY4MTJdIDJlOWM2IGlzIDI5YmU2MDAwIQ0KWyAgMTkxLjQyODk2OF0g
MmU5YzcgaXMgMjliZTUwMDAhDQpbICAxOTEuNDMxMTQ3XSAyZTljOCBpcyAyOWJlNDAwMCEN
ClsgIDE5MS40MzMzMDZdIDJlOWRkIGlzIDI5YmUzMDAwIQ0KWyAgMTkxLjQzNTQ5MV0gMmU5
YzkgaXMgMjliZTIwMDAhDQpbICAxOTEuNDM3Njg4XSAyZTlkZSBpcyAyOWJlMTAwMCENClsg
IDE5MS40NDM0MzFdIDJlOWNhIGlzIDI5YmUwMDAwIQ0KWyAgMTkxLjQ0NTU0OF0gMmU5Y2Ig
aXMgMjliZGYwMDAhDQpbICAxOTEuNDQ3ODc5XSAyZTljYyBpcyAyOWJkZTAwMCENClsgIDE5
MS40NTAwMjNdIDJlOWNkIGlzIDI5YmRkMDAwIQ0KWyAgMTkxLjQ1MjM2Ml0gMmU5Y2UgaXMg
MjliZGMwMDAhDQpbICAxOTEuNDU0NjIzXSAyZTljZiBpcyAyOWJkYjAwMCENClsgIDE5MS40
NTY3OTldIDJlOWQwIGlzIDI5YmRhMDAwIQ0KWyAgMTkxLjQ1ODk1M10gMmU5ZDEgaXMgMjli
ZDkwMDAhDQpbICAxOTEuNTA0OTUzXSAyZTlkMiBpcyAyOWJkODAwMCENClsgIDE5MS41MDcx
MzhdIDJlOWRmIGlzIDI5YmQ3MDAwIQ0KWyAgMTkxLjUwOTI3OV0gMmU5ZTAgaXMgMjliZDYw
MDAhDQpbICAxOTEuNTExNDQ3XSAyZTlkMyBpcyAyOWJkNTAwMCENClsgIDE5MS41MTM2MjVd
IDJlOWUxIGlzIDI5YmQ0MDAwIQ0KWyAgMTkxLjUxNTg3NF0gMmU5ZDQgaXMgMjliZDMwMDAh
DQpbICAxOTEuNTE4MDEzXSAyZTllMiBpcyAyOWJkMjAwMCENClsgIDE5MS41MjAxNjVdIDJl
OWQ1IGlzIDI5YmQxMDAwIQ0KWyAgMTkxLjUyMzI1Nl0gMmVhMDAgaXMgMjliYmIwMDAhDQpb
ICAxOTEuNTI1MDUwXSAyZWEwMSBpcyAyOWJiYzAwMCENClsgIDE5MS41MjY4MzhdIDJlYTAy
IGlzIDI5YmJkMDAwIQ0KWyAgMTkxLjUyODU4OV0gMmVhMDMgaXMgMjliYmUwMDAhDQpbICAx
OTEuNTMwMzUzXSAyZWEwNCBpcyAyOWJiZjAwMCENClsgIDE5MS41MzIxMTBdIDJlYTA1IGlz
IDI5YmMwMDAwIQ0KWyAgMTkxLjUzMzg4Ml0gMmVhMDYgaXMgMjliYzEwMDAhDQpbICAxOTEu
NTM1NjQ5XSAyZWEwNyBpcyAyOWJjMjAwMCENClsgIDE5MS41Mzc0MTZdIDJlYTA4IGlzIDI5
YmMzMDAwIQ0KWyAgMTkxLjUzOTE3N10gMmVhMDkgaXMgMjliYzQwMDAhDQpbICAxOTEuNTQw
OTMzXSAyZWEwYSBpcyAyOWJjNTAwMCENClsgIDE5MS41NDMxMzJdIDJlYTBiIGlzIDI5YmIx
MDAwIQ0KWyAgMTkxLjU0NDkwMl0gMmVhMGMgaXMgMjliYjIwMDAhDQpbICAxOTEuNTQ2NjMw
XSAyZWEwZCBpcyAyOWJiMzAwMCENClsgIDE5MS41NDgzODVdIDJlYTBlIGlzIDI5YmI0MDAw
IQ0KWyAgMTkxLjU1MDExOV0gMmVhMGYgaXMgMjliYjUwMDAhDQpbICAxOTEuNTUxODQ4XSAy
ZWExMCBpcyAyOWJiNjAwMCENClsgIDE5MS41NTM1NzVdIDJlYTExIGlzIDI5YmI3MDAwIQ0K
WyAgMTkxLjU1NTI4NV0gMmVhMTIgaXMgMjliYjgwMDAhDQpbICAxOTEuNTU3MDE2XSAyZWEx
MyBpcyAyOWJiOTAwMCENClsgIDE5MS41NTg3MTVdIDJlYTE0IGlzIDI5YmJhMDAwIQ0KWyAg
MTkxLjU2MDQ0MV0gMmVhMTUgaXMgMjliYTYwMDAhDQpbICAxOTEuNTYyMTQwXSAyZWExOFsg
IDE5My42OTY4MTRdIDJlNWVjIGlzIDI5ZWUxMDAwIQ0KWyAgMTkzLjY5ODkxNl0gMmU1YWIg
aXMgMjllZTAwMDAhDQpbICAxOTMuNzAxMDA1XSAyZTVlZCBpcyAyOWVkZjAwMCENClsgIDE5
My43MDMxMzFdIDJlNWFjIGlzIDI5ZWRlMDAwIQ0KWyAgMTkzLjcwNTI0OF0gMmU1ZWUgaXMg
MjllZGQwMDAhDQpbICAxOTMuNzA3Mzg2XSAyZTVhZCBpcyAyOWVkYzAwMCENClsgIDE5My43
MDk0ODNdIDJlNWFlIGlzIDI5ZWRiMDAwIQ0KWyAgMTkzLjcxMTYxN10gMmU1ZWYgaXMgMjll
ZGEwMDAhDQpbICAxOTMuNzEzNzIyXSAyZTVmMCBpcyAyOWVkOTAwMCENClsgIDE5My43MTU4
NDRdIDJlNWYxIGlzIDI5ZWQ4MDAwIQ0KWyAgMTkzLjcxODA2MF0gMmU1ZjIgaXMgMjllZDcw
MDAhDQpbICAxOTMuNzIwMjAyXSAyZTVmMyBpcyAyOWVkNjAwMCENClsgIDE5My43MjIzMTRd
IDJlNWY0IGlzIDI5ZWQ1MDAwIQ0KWyAgMTkzLjcyNDQ3NV0gMmU1ZjUgaXMgMjllZDQwMDAh
DQpbICAxOTMuNzI2NTczXSAyZTVmNiBpcyAyOWVkMzAwMCENClsgIDE5My43Mjg3MTZdIDJl
NWY3IGlzIDI5ZWQyMDAwIQ0KWyAgMTkzLjczMDg0MF0gMmU1ZjggaXMgMjllZDEwMDAhDQpb
ICAxOTMuNzMyOTYwXSAyZTVmOSBpcyAyOWVkMDAwMCENClsgIDE5My43Mzk4MDBdIDJlNWZh
IGlzIDI5ZWNmMDAwIQ0KWyAgMTkzLjc0MTg5N10gMmU1YWYgaXMgMjllY2UwMDAhDQpbICAx
OTMuNzQ0MDAwXSAyZTViMCBpcyAyOWVjZDAwMCENClsgIDE5My43NDYwODldIDJlNWIxIGlz
IDI5ZWNjMDAwIQ0KWyAgMTkzLjc0ODE4OF0gMmU1ZmIgaXMgMjllY2IwMDAhDQpbICAxOTMu
NzUwMjI4XSAyZTViMiBpcyAyOWVjYTAwMCENClsgIDE5My43NTIzMDBdIDJlNWZjIGlzIDI5
ZWM5MDAwIQ0KWyAgMTkzLjc1NDQ4M10gMmU1ZmQgaXMgMjllYzgwMDAhDQpbICAxOTMuNzU2
NTYxXSAyZTVmZSBpcyAyOWVjNzAwMCENClsgIDE5My43Njc1NzhdIDJlNWZmIGlzIDI5ZWM2
MDAwIQ0KWyAgMTkzLjc2OTcwMF0gMmU2MDAgaXMgMjllYzUwMDAhDQpbICAxOTMuNzcxOTcx
XSAyZTYwMSBpcyAyOWVjNDAwMCENClsgIDE5My43NzQyMDddIDJlNjAyIGlzIDI5ZWMzMDAw
IQ0KWyAgMTkzLjc3NjMyNV0gMmU2MDMgaXMgMjllYzIwMDAhDQpbICAxOTMuNzg0MDExXSAy
ZTYwNCBpcyAyOWVjMTAwMCENClsgIDE5My43ODYxNDVdIDJlNjA1IGlzIDI5ZWMwMDAwIQ0K
WyAgMTkzLjc4ODM5NV0gMmU2MDYgaXMgMjllYmYwMDAhDQpbICAxOTMuNzkwNjAxXSAyZTYw
NyBpcyAyOWViZTAwMCENClsgIDE5My43OTI2ODNdIDJlNjA4IGlzIDI5ZWJkMDAwIQ0KWyAg
MTkzLjc5NDkyMV0gMmU2MDkgaXMgMjllYmMwMDAhDQpbICAxOTMuNzk2OTkxXSAyZTYwYSBp
cyAyOWViYjAwMCENClsgIDE5My43OTkwMjVdIDJlNjBiIGlzIDI5ZWJhMDAwIQ0KWyAgMTkz
LjgxNDE5OV0gMmU1YjMgaXMgMjllYjkwMDAhDQpbICAxOTMuODE2MjgwXSAyZTViNCBpcyAy
OWViODAwMCENClsgIDE5My44MTgzNzldIDJlNjBjIGlzIDI5ZWI3MDAwIQ0KWyAgMTkzLjgy
MDQ3N10gMmU1YjUgaXMgMjllYjYwMDAhDQpbICAxOTMuODIyNTY3XSAyZTViNiBpcyAyOWVi
NTAwMCENClsgIDE5My44MjQ2NzFdIDJlNjBkIGlzIDI5ZWI0MDAwIQ0KWyAgMTkzLjgyNjgx
Ml0gMmU1YjcgaXMgMjllYjMwMDAhDQpbICAxOTMuODI4OTMzXSAyZTYwZSBpcyAyOWViMjAw
MCENClsgIDE5My44MzEwOTVdIDJlNjBmIGlzIDI5ZWIxMDAwIQ0KWyAgMTkzLjgzMzIyMV0g
MmU2MTAgaXMgMjllYjAwMDAhDQpbICAxOTMuODM1NDA2XSAyZTYxMSBpcyAyOWVhZjAwMCEN
ClsgIDE5My44Mzc1ODhdIDJlNjEyIGlzIDI5ZWFlMDAwIQ0KWyAgMTkzLjgzOTcxOV0gMmU2
MTMgaXMgMjllYWQwMDAhDQpbICAxOTMuODQxOTA0XSAyZTYxNCBpcyAyOWVhYzAwMCENClsg
IDE5My44NDQxODRdIDJlNjE1IGlzIDI5ZWFiMDAwIQ0KWyAgMTkzLjg0NjMxMV0gMmU2MTYg
aXMgMjllYWEwMDAhDQpbICAxOTMuODQ4NDk1XSAyZTYxNyBpcyAyOWVhOTAwMCENClsgIDE5
My44NjIzNTldIDJlNjE4IGlzIDI5ZWE4MDAwIQ0KWyAgMTkzLjg2NDQ3Nl0gMmU2MTkgaXMg
MjllYTcwMDAhDQpbICAxOTMuODY2NTg4XSAyZTViOCBpcyAyOWVhNjAwMCENClsgIDE5My44
Njg4NzZdIDJlNjFhIGlzIDI5ZWE1MDAwIQ0KWyAgMTkzLjg3MTAxOF0gMmU1YjkgaXMgMjll
YTQwMDAhDQpbICAxOTMuODczMTk3XSAyZTViYSBpcyAyOWVhMzAwMCENClsgIDE5My44NzUz
NjldIDJlNjFiIGlzIDI5ZWEyMDAwIQ0KWyAgMTkzLjg3NzU2OV0gMmU1YmIgaXMgMjllYTEw
MDAhDQpbICAxOTMuODc5NzIxXSAyZTYxYyBpcyAyOWVhMDAwMCENClsgIDE5My44ODE5NTBd
IDJlNjFkIGlzIDI5ZTlmMDAwIQ0KWyAgMTkzLjg4NDE1OF0gMmU2MWUgaXMgMjllOWUwMDAh
DQpbICAxOTMuODg2MzM2XSAyZTYxZiBpcyAyOWU5ZDAwMCENClsgIDE5My44ODg1NTFdIDJl
NjIwIGlzIDI5ZTljMDAwIQ0KWyAgMTkzLjg5MDc1M10gMmU2MjEgaXMgMjllOWIwMDAhDQpb
ICAxOTMuODkyOTE1XSAyZTYyMiBpcyAyOWU5YTAwMCENClsgIDE5My44OTUxMDVdIDJlNjIz
IGlzIDI5ZTk5MDAwIQ0KWyAgMTkzLjkwNjExMV0gMmU2MjQgaXMgMjllOTgwMDAhDQpbICAx
OTMuOTA4MjQ4XSAyZTViYyBpcyAyOWU5NzAwMCENClsgIDE5My45MTA0MzJdIDJlNWJkIGlz
IDI5ZTk2MDAwIQ0KWyAgMTkzLjkxMjYwNV0gMmU1YmUgaXMgMjllOTUwMDAhDQpbICAxOTMu
OTE0NzkyXSAyZTYyNSBpcyAyOWU5NDAwMCENClsgIDE5My45MTY4OTFdIDJlNWJmIGlzIDI5
ZTkzMDAwIQ0KWyAgMTkzLjkxOTE1NV0gMmU2MjYgaXMgMjllOTIwMDAhDQpbICAxOTMuOTIx
MzIxXSAyZTVjMCBpcyAyOWU5MTAwMCENClsgIDE5My45MjM1MjVdIDJlNjI3IGlzIDI5ZTkw
MDAwIQ0KWyAgMTkzLjkyNTY5OF0gMmU2MjggaXMgMjllOGYwMDAhDQpbICAxOTMuOTI3ODg4
XSAyZTYyOSBpcyAyOWU4ZTAwMCENClsgIDE5My45MzAwMjNdIDJlNWMxIGlzIDI5ZThkMDAw
IQ0KWyAgMTkzLjkzMjUyMl0gMmU2MmEgaXMgMjllODUwMDAhDQpbICAxOTMuOTM0MzMzXSAy
ZTVjMiBpcyAyOWU4NjAwMCENClsgIDE5My45MzYxNDhdIDJlNWMzIGlzIDI5ZTg3MDAwIQ0K
WyAgMTkzLjkzNzk2N10gMmU2NDAgaXMgMjllODgwMDAhDQpbICAxOTMuOTM5Nzg4XSAyZTY0
MSBpcyAyOWU4OTAwMCENClsgIDE5My45NDE2MDVdIDJlNjQyIGlzIDI5ZThhMDAwIQ0KWyAg
MTkzLjk0MzQzMV0gMmU2NDMgaXMgMjllOGIwMDAhDQpbICAxOTMuOTQ1MjE5XSAyZTY0NCBp
cyAyOWU4YzAwMCENClsgIDE5My45NDc5MTVdIDJlNjM1IGlzIDI5ZTc1MDAwIQ0KWyAgMTkz
Ljk0OTcwM10gMmU2MzYgaXMgMjllNzYwMDAhDQpbICAxOTMuOTUxNTAxXSAyZTYzNyBpcyAy
OWU3NzAwMCENClsgIDE5My45NTMyNzFdIDJlNjM4IGlzIDI5ZTc4MDAwIQ0KWyAgMTkzLjk1
NTA0Ml0gMmU2MzkgaXMgMjllNzkwMDAhDQpbICAxOTMuOTU2ODEzXSAyZTY0NSBpcyAyOWU3
YTAwMCENClsgIDE5My45NTg1NjZdIDJlNjJiIGlzIDI5ZTdiMDAwIQ0KWyAgMTkzLjk2MDM1
M10gMmU2MmMgaXMgMjllN2MwMDAhDQpbICAxOTMuOTYyMTExXSAyZTYyZCBpcyAyOWU3ZDAw
MCENClsgIDE5My45NjM4ODNdIDJlNjJlIGlzIDI5ZTdlMDAwIQ0KWyAgMTkzLjk2NTY1OF0g
MmU2MmYgaXMgMjllN2YwMDAhDQpbICAxOTMuOTY3NDM0XSAyZTYzMCBpcyAyOWU4MDAwMCEN
ClsgIDE5My45NjkyMjBdIDJlNjMxIGlzIDI5ZTgxMDAwIQ0KWyAgMTkzLjk3MDk5MF0gMmU2
MzIgaXMgMjllODIwMDAhDQpbICAxOTMuOTcyNzU5XSAyZTYzMyBpcyAyOWU4MzAwMCENClsg
IDE5My45NzQ1MjZdIDJlNjM0IGlzIDI5ZTg0MDAwIQ0KWyAgMTkzLjk3NzI3OF0gMmU2M2Eg
aXMgMjllNmEwMDAhDQpbICAxOTMuOTc5MDIxXSAyZTYzYiBpcyAyOWU2YjAwMCENClsgIDE5
My45ODA3ODNdIDJlNjNjIGlzIDI5ZTZjMDAwIQ0KWyAgMTkzLjk4MjUwM10gMmU2M2QgaXMg
MjllNmQwMDAhDQpbICAxOTMuOTg0MjIzXSAyZTYzZSBpcyAyOWU2ZTAwMCENClsgIDE5My45
ODU5MzRdIDJlNjNmIGlzIDI5ZTZmMDAwIQ0KWyAgMTkzLjk4NzY0N10gMmU2NWYgaXMgMjll
NzAwMDAhDQpbICAxOTMuOTg5MzU1XSAyZTY2MCBpcyAyOWU3MTAwMCENClsgIDE5My45OTEw
NTZdIDJlNjYxIGlzIDI5ZTcyMDAwIQ0KWyAgMTkzLjk5MjczNV0gMmU2NjIgaXMgMjllNzMw
MDAhDQpbICAxOTMuOTk0NDQzXSAyZTY2MyBpcyAyOWU3NDAwMCENClsgIDE5My45OTYzMzdd
IDJlNjZmIGlzIDI5ZTU1MDAwIQ0KWyAgMTkzLjk5ODEwNV0gMmU2NzAgaXMgMjllNTYwMDAh
DQpbICAxOTMuOTk5NzgwXSAyZTY3MSBpcyAyOWU1NzAwMCENClsgIDE5NC4wMDE0ODJdIDJl
NjcyIGlzIDI5ZTU4MDAwIQ0KWyAgMTk0LjAwMzE2NV0gMmU2NzMgaXMgMjllNTkwMDAhDQpb
ICAxOTQuMDA0ODU4XSAyZTY3NCBpcyAyOWU1YTAwMCENClsgIDE5NC4wMDY1NTNdIDJlNjc1
IGlzIDI5ZTViMDAwIQ0KWyAgMTk0LjAwODIzN10gMmU2NzYgaXMgMjllNWMwMDAhDQpbICAx
OTQuMDA5OTQyXSAyZTY3NyBpcyAyOWU1ZDAwMCENClsgIDE5NC4wMTE2MzJdIDJlNjc4IGlz
IDI5ZTVlMDAwIQ0KWyAgMTk0LjAxMzMwNV0gMmU2NzkgaXMgMjllNGEwMDAhDQpbICAxOTQu
MDE1MDA2XSAyZTY3YSBpcyAyOWU0YjAwMCENClsgIDE5NC4wMTY2NjddIDJlNjdiIGlzIDI5
ZTRjMDAwIQ0KWyAgMTk0LjAxODM1NF0gMmU2N2MgaXMgMjllNGQwMDAhDQpbICAxOTQuMDIw
MDE0XSAyZTY3ZCBpcyAyOWU0ZTAwMCENClsgIDE5NC4wMjE2ODddIDJlNjdlIGlzIDI5ZTRm
MDAwIQ0KWyAgMTk0LjAyMzM1Ml0gMmU2N2YgaXMgMjllNTAwMDAhDQpbICAxOTQuMDI1MDE5
XSAyZTY4MCBpcyAyOWU1MTAwMCENClsgIDE5NC4wMjY2OTZdIDJlNjgxIGlzIDI5ZTUyMDAw
IQ0KWyAgMTk0LjAyODM2OF0gMmU2ODIgaXMgMjllNTMwMDAhDQpbICAxOTQuMDMwMDMwXSAy
ZTY4MyBpcyAyOWU1NDAwMCENClsgIDE5NC4wMzE3MjBdIDJlNjY0IGlzIDI5ZTVmMDAwIQ0K
WyAgMTk0LjAzMzM5M10gMmU2NjUgaXMgMjllNjAwMDAhDQpbICAxOTQuMDM1MDcyXSAyZTY2
NiBpcyAyOWU2MTAwMCENClsgIDE5NC4wMzY3NTFdIDJlNjY3IGlzIDI5ZTYyMDAwIQ0KWyAg
MTk0LjAzODQyM10gMmU2NjggaXMgMjllNjMwMDAhDQpbICAxOTQuMDQwMTIzXSAyZTY2OSBp
cyAyOWU2NDAwMCENClsgIDE5NC4wNDE3ODNdIDJlNjZhIGlzIDI5ZTY1MDAwIQ0KWyAgMTk0
LjA0MzQ2MF0gMmU2NmIgaXMgMjllNjYwMDAhDQpbICAxOTQuMDQ1MTEwXSAyZTY2YyBpcyAy
OWU2NzAwMCENClsgIDE5NC4wNDY3NjVdIDJlNjZkIGlzIDI5ZTY4MDAwIQ0KWyAgMTk0LjA0
ODQyNV0gMmU2NmUgaXMgMjllNjkwMDAhDQpbICAxOTQuMDUxNTM4XSAyZTY5OSBpcyAyOWUx
NTAwMCENClsgIDE5NC4wNTMyNjldIDJlNjlhIGlzIDI5ZTE2MDAwIQ0KWyAgMTk0LjA1NDkz
Nl0gMmU2OWIgaXMgMjllMTcwMDAhDQpbICAxOTQuMDU2NTg0XSAyZTY5YyBpcyAyOWUxODAw
MCENClsgIDE5NC4wNTgyMzFdIDJlNjlkIGlzIDI5ZTE5MDAwIQ0KWyAgMTk0LjA1OTg3N10g
MmU2YTAgaXMgMjllMWEwMDAhDQpbICAxOTQuMDYxNTMzXSAyZTZhMSBpcyAyOWUxYjAwMCEN
ClsgIDE5NC4wNjMxODJdIDJlNmEyIGlzIDI5ZTFjMDAwIQ0KWyAgMTk0LjA2NDg2Ml0gMmU2
YTMgaXMgMjllMWQwMDAhDQpbICAxOTQuMDY2NTA1XSAyZTZhNCBpcyAyOWUxZTAwMCENClsg
IDE5NC4wNjgxNjldIDJlNjQ2IGlzIDI5ZTFmMDAwIQ0KWyAgMTk0LjA2OTgyMF0gMmU2OTgg
aXMgMjllMjAwMDAhDQpbICAxOTQuMDcxNDkzXSAyZTY5NyBpcyAyOWUyMTAwMCENClsgIDE5
NC4wNzMxNzVdIDJlNjk2IGlzIDI5ZTIyMDAwIQ0KWyAgMTk0LjA3NDg1NF0gMmU2OTUgaXMg
MjllMjMwMDAhDQpbICAxOTQuMDc2NTM1XSAyZTY5NCBpcyAyOWUyNDAwMCENClsgIDE5NC4w
NzgyMDhdIDJlNjkzIGlzIDI5ZTI1MDAwIQ0KWyAgMTk0LjA3OTg2M10gMmU2OTIgaXMgMjll
MjYwMDAhDQpbICAxOTQuMDgxNTQ3XSAyZTY5MSBpcyAyOWUyNzAwMCENClsgIDE5NC4wODMy
MDhdIDJlNjkwIGlzIDI5ZTI4MDAwIQ0KWyAgMTk0LjA4NDg5MF0gMmU2OGYgaXMgMjllMjkw
MDAhDQpbICAxOTQuMDg3NDI0XSAyZTY4ZSBpcyAyOWRlYTAwMCENClsgIDE5NC4wODkxNzFd
IDJlNjhkIGlzIDI5ZGViMDAwIQ0KWyAgMTk0LjA5MDg1Nl0gMmU2OGMgaXMgMjlkZWMwMDAh
DQpbICAxOTQuMDkyNTI4XSAyZTY4YiBpcyAyOWRlZDAwMCENClsgIDE5NC4wOTQyNzRdIDJl
NjhhIGlzIDI5ZGVlMDAwIQ0KWyAgMTk0LjA5NTk1NF0gMmU2ODkgaXMgMjlkZWYwMDAhDQpb
ICAxOTQuMDk3NjYxXSAyZTY4OCBpcyAyOWRmMDAwMCENClsgIDE5NC4wOTkzNzVdIDJlNjg3
IGlzIDI5ZGYxMDAwIQ0KWyAgMTk0LjEwMTA3OV0gMmU2ODYgaXMgMjlkZjIwMDAhDQpbICAx
OTQuMTAyNzkxXSAyZTY4NSBpcyAyOWRmMzAwMCENClsgIDE5NC4xMDQ1MDddIDJlNjg0IGlz
IDI5ZGY0MDAwIQ0KWyAgMTk0LjEwNjM5OV0gMmU2NWIgaXMgMjlkZDQwMDAhDQpbICAxOTQu
MTA4MTA1XSAyZTY1MCBpcyAyOWRkZjAwMCENClsgIDE5NC4xMDk4MTBdIDJlNjRmIGlzIDI5
ZGUwMDAwIQ0KWyAgMTk0LjExMTUyM10gMmU2NGUgaXMgMjlkZTEwMDAhDQpbICAxOTQuMTEz
MjMxXSAyZTY0ZCBpcyAyOWRlMjAwMCENClsgIDE5NC4xMTQ5NjFdIDJlNjRjIGlzIDI5ZGUz
MDAwIQ0KWyAgMTk0LjExNjY1MF0gMmU2NGIgaXMgMjlkZTQwMDAhDQpbICAxOTQuMTE4MzY5
XSAyZTY0YSBpcyAyOWRlNTAwMCENClsgIDE5NC4xMjAwNzZdIDJlNjQ5IGlzIDI5ZGU2MDAw
IQ0KWyAgMTk0LjEyMTc3N10gMmU2NDggaXMgMjlkZTcwMDAhDQpbICAxOTQuMTIzNDk2XSAy
ZTY0NyBpcyAyOWRlODAwMCENClsgIDE5NC4xMjUxNzRdIDJlNmE1IGlzIDI5ZGU5MDAwIQ0K
WyAgMTk0LjEyNjg4MF0gMmU2NWEgaXMgMjlkZDUwMDAhDQpbICAxOTQuMTI4NTY5XSAyZTY1
OSBpcyAyOWRkNjAwMCENClsgIDE5NC4xMzAyNzJdIDJlNjU4IGlzIDI5ZGQ3MDAwIQ0KWyAg
MTk0LjEzMTk4M10gMmU2NTcgaXMgMjlkZDgwMDAhDQpbICAxOTQuMTMzNjkxXSAyZTY1NiBp
cyAyOWRkOTAwMCENClsgIDE5NC4xMzU0MDNdIDJlNjU1IGlzIDI5ZGRhMDAwIQ0KWyAgMTk0
LjEzNzEwNV0gMmU2NTQgaXMgMjlkZGIwMDAhDQpbICAxOTQuMTM4ODAzXSAyZTY1MyBpcyAy
OWRkYzAwMCENClsgIDE5NC4xNDA0ODhdIDJlNjUyIGlzIDI5ZGRkMDAwIQ0KWyAgMTk0LjE0
MjE1NF0gMmU2NTEgaXMgMjlkZGUwMDAhDQpbICAxOTQuMTQ0MTc0XSAyZTZhNiBpcyAyOWRk
MzAwMCENClsgIDE5NC4xNDYyMDFdIDJlNjVjIGlzIDI5ZGQyMDAwIQ0KWyAgMTk0LjE0OTc5
MF0gMmU2YTcgaXMgMjlkZDEwMDAhDQpbICAxOTQuMTU5MzY3XSAyZTY1ZCBpcyAyOWRkMDAw
MCENClsgIDE5NC4xNjE1MThdIDJlNmE4IGlzIDI5ZGNmMDAwIQ0KWyAgMTk0LjE2MzUzNF0g
MmU2YTkgaXMgMjlkY2UwMDAhDQpbICAxOTQuMTY3ODY4XSAyZTZhYSBpcyAyOWRhYjAwMCEN
ClsgIDE5NC4xNjk5ODNdIDJlNjVlIGlzIDI5ZGFjMDAwIQ0KWyAgMTk0LjE4MDA2NF0gMmU2
YWIgaXMgMjlkYWQwMDAhDQpbICAxOTQuMTgyMjI3XSAyZTZiZSBpcyAyOWRhZTAwMCENClsg
IDE5NC4xODQ0NTJdIDJlNmFjIGlzIDI5ZGI1MDAwIQ0KWyAgMTk0LjE4NjU3NF0gMmU2YWQg
aXMgMjlkYzQwMDAhDQpbICAxOTQuMjM4MTg5XSAyZTZhZSBpcyAyOWRjMzAwMCENClsgIDE5
NC4yNDAzMDZdIDJlNmFmIGlzIDI5ZGM1MDAwIQ0KWyAgMTk0LjI0MjM4NV0gMmU2YjAgaXMg
MjlkYzYwMDAhDQpbICAxOTQuMjQ0NTI0XSAyZTZiZiBpcyAyOWRjMDAwMCENClsgIDE5NC4y
NDY2NTFdIDJlNmIxIGlzIDI5ZGJmMDAwIQ0KWyAgMTk0LjI1Mjc4NV0gMmU2YjIgaXMgMjlk
YmUwMDAhDQpbICAxOTQuMjU0OTMxXSAyZTZiMyBpcyAyOWRiZDAwMCENClsgIDE5NC4yNjAy
NDZdIDJlNmI0IGlzIDI5ZGJiMDAwIQ0KWyAgMTk0LjI2MjM1N10gMmU2YzAgaXMgMjlkYzEw
MDAhDQpbICAxOTQuMjY3MDgzXSAyZTZjMSBpcyAyOWRiODAwMCENClsgIDE5NC4yNjkyMzNd
IDJlNmI1IGlzIDI5ZGJhMDAwIQ0KWyAgMTk0LjI3MTU0MF0gMmU2YjYgaXMgMjlkYWYwMDAh
DQpbICAxOTQuMjczNzU0XSAyZTZiNyBpcyAyOWRiMDAwMCENClsgIDE5NC4yNzU5MDldIDJl
NmI4IGlzIDI5ZGI5MDAwIQ0KWyAgMTk0LjI3ODI3MV0gMmU2YjkgaXMgMjlkYjQwMDAhDQpb
ICAxOTQuMjgwNTMwXSAyZTZiYSBpcyAyOWRjMjAwMCENClsgIDE5NC4yODI3MDFdIDJlNmJi
IGlzIDI5ZGI2MDAwIQ0KWyAgMTk0LjI4NTA0OF0gMmU2YmMgaXMgMjlkYjcwMDAhDQpbICAx
OTQuMjg3MzI3XSAyZTZiZCBpcyAyYTAxMDAwMCENClsgIDE5NC4yODk1MDddIDJlNmRlIGlz
IDI5ZGNjMDAwIQ0KWyAgMTk0LjI5MTgyMl0gMmU2ZGYgaXMgMjlkY2QwMDAhDQpbICAxOTQu
Mjk0MTA2XSAyZTZlMCBpcyAyOTVkYjAwMCENClsgIDE5NC4yOTYzMDNdIDJlNmUxIGlzIDJh
MDFiMDAwIQ0KWyAgMTk0LjI5ODY0MF0gMmU2ZTIgaXMgMjk1ZGMwMDAhDQpbICAxOTQuMzA2
OTM4XSAyZTZlMyBpcyAyOWRiMzAwMCENClsgIDE5NC4zMDkxNjhdIDJlNmMyIGlzIDI5YWM2
MDAwIQ0KWyAgMTk0LjMxMTUzMl0gMmU2ZTQgaXMgMjlkY2EwMDAhDQpbICAxOTQuMzEzODU5
XSAyZTZlNSBpcyAyOWRjOTAwMCENClsgIDE5NC4zMTYwODldIDJlNmU2IGlzIDI5ZGFhMDAw
IQ0KWyAgMTk0LjMxODQ2MV0gMmU2ZTcgaXMgMjlkYTkwMDAhDQpbICAxOTQuMzIwNzU1XSAy
ZTZlOCBpcyAyOWRhODAwMCENClsgIDE5NC4zMjI5ODhdIDJlNmU5IGlzIDI5ZGE3MDAwIQ0K
WyAgMTk0LjMyNTMxOV0gMmU2ZWEgaXMgMjlkYTYwMDAhDQpbICAxOTQuMzI3NjA4XSAyZTZl
YiBpcyAyOWRhNTAwMCENClsgIDE5NC4zMjk3OTNdIDJlNmVjIGlzIDI5ZGE0MDAwIQ0KWyAg
MTk0LjMzMjEyM10gMmU2ZWQgaXMgMjlkYTMwMDAhDQpbICAxOTQuMzM0NDAxXSAyZTZlZSBp
cyAyOWRhMjAwMCENClsgIDE5NC4zMzY1ODddIDJlNmVmIGlzIDI5ZGExMDAwIQ0KWyAgMTk0
LjMzODkxNV0gMmU2ZjAgaXMgMjlkYTAwMDAhDQpbICAxOTQuMzQxMTc4XSAyZTZmMSBpcyAy
OWQ5ZjAwMCENClsgIDE5NC4zNDM3ODhdIDJlNmYyIGlzIDI5ZDlkMDAwIQ0KWyAgMTk0LjM0
NTk3NF0gMmU2ZjMgaXMgMjlkOWMwMDAhDQpbICAxOTQuMzQ5NTQ0XSAyZTZmNCBpcyAyOWQ5
YjAwMCENClsgIDE5NC4zNTE3MzldIDJlNmMzIGlzIDI5ZDlhMDAwIQ0KWyAgMTk0LjM1Mzky
OV0gMmU2YzUgaXMgMjlkOTkwMDAhDQpbICAxOTQuMzU2MTE0XSAyZTZjNiBpcyAyOWQ5ODAw
MCENClsgIDE5NC4zNTgyOTBdIDJlNmY1IGlzIDI5ZDk3MDAwIQ0KWyAgMTk0LjM2MDQ3MV0g
MmU2YzcgaXMgMjlkOTYwMDAhDQpbICAxOTQuMzYyNjQxXSAyZTZjOCBpcyAyOWQ5NTAwMCEN
ClsgIDE5NC4zNjQ4NTFdIDJlNmY2IGlzIDI5ZDk0MDAwIQ0KWyAgMTk0LjM2NjkzNl0gMmU2
ZjcgaXMgMjlkOTMwMDAhDQpbICAxOTQuMzY5MDU5XSAyZTZmOCBpcyAyOWQ5MjAwMCENClsg
IDE5NC4zNzEyOTJdIDJlNmY5IGlzIDI5ZDkxMDAwIQ0KWyAgMTk0LjM3Mzc3MV0gMmU2ZmEg
aXMgMjlkOGYwMDAhDQpbICAxOTQuMzc1ODg0XSAyZTZmYiBpcyAyOWQ4ZTAwMCENClsgIDE5
NC4zNzgwMTJdIDJlNmZjIGlzIDI5ZDhkMDAwIQ0KWyAgMTk0LjM4MDQyMF0gMmU2ZmQgaXMg
MjlkOGIwMDAhDQpbICAxOTQuMzgyNDg2XSAyZTZmZSBpcyAyOWQ4YTAwMCENClsgIDE5NC4z
ODQ1NzNdIDJlNmZmIGlzIDI5ZDg5MDAwIQ0KWyAgMTk0LjM4NjYwNF0gMmU3MDAgaXMgMjlk
ODgwMDAhDQpbICAxOTQuMzg4Njk0XSAyZTcwMSBpcyAyOWQ4NzAwMCENClsgIDE5NC4zOTA3
NTddIDJlNzAyIGlzIDI5ZDg2MDAwIQ0KWyAgMTk0LjM5Mjc4OV0gMmU3MDMgaXMgMjlkODUw
MDAhDQpbICAxOTQuMzk0ODU0XSAyZTcwNCBpcyAyYTU4NDAwMCENClsgIDE5NC4zOTY4ODJd
IDJlNzA1IGlzIDJhNTgzMDAwIQ0KWyAgMTk0LjM5ODg4OF0gMmU3MDYgaXMgMmE1ODIwMDAh
DQpbICAxOTQuNDExNzYzXSAyZTZjOSBpcyAyYTU4MTAwMCENClsgIDE5NC40MTM4NTddIDJl
NmNhIGlzIDJhNTgwMDAwIQ0KWyAgMTk0LjQxNTkzM10gMmU2Y2IgaXMgMmE1N2YwMDAhDQpb
ICAxOTQuNDE4MDQ1XSAyZTcwNyBpcyAyYTU3ZTAwMCENClsgIDE5NC40MjAxNjNdIDJlNmNj
IGlzIDJhNTdkMDAwIQ0KWyAgMTk0LjQyMjI3MV0gMmU3MDggaXMgMmE1N2MwMDAhDQpbICAx
OTQuNDI0Mzk0XSAyZTcwOSBpcyAyYTU3YjAwMCENClsgIDE5NC40MjY1MjRdIDJlNmNkIGlz
IDJhNTdhMDAwIQ0KWyAgMTk0LjQyODY4Ml0gMmU3MGEgaXMgMmE1NzkwMDAhDQpbICAxOTQu
NDQwOTkxXSAyZTcwYiBpcyAyYTU3ODAwMCENClsgIDE5NC40NDMxMzJdIDJlNzBjIGlzIDJh
NTc3MDAwIQ0KWyAgMTk0LjQ0NTI4M10gMmU3MGQgaXMgMmE1NzYwMDAhDQpbICAxOTQuNDQ3
NDM3XSAyZTZjZSBpcyAyYTU3NTAwMCENClsgIDE5NC40NDk1NzddIDJlNmNmIGlzIDJhNTc0
MDAwIQ0KWyAgMTk0LjQ1MTczOV0gMmU3MGUgaXMgMmE1NzMwMDAhDQpbICAxOTQuNDUzODc5
XSAyZTZkMCBpcyAyYTU3MjAwMCENClsgIDE5NC40NTYwNDldIDJlNmQxIGlzIDJhNTcxMDAw
IQ0KWyAgMTk0LjQ1ODI0MV0gMmU3MGYgaXMgMmE1NzAwMDAhDQpbICAxOTQuNDYwNDA2XSAy
ZTcxMCBpcyAyYTU2ZjAwMCENClsgIDE5NC40NjI1NThdIDJlNzExIGlzIDJhNTZlMDAwIQ0K
WyAgMTk0LjQ2NTAzNF0gMmU3MTIgaXMgMmE1NmQwMDAhDQpbICAxOTQuNDY3Mjc4XSAyZTZk
MiBpcyAyYTU2YzAwMCENClsgIDE5NC40Njk0MDddIDJlNzEzIGlzIDJhNTZiMDAwIQ0KWyAg
MTk0LjQ3MTY3OF0gMmU3MTQgaXMgMmE1NmEwMDAhDQpbICAxOTQuNDczOTAxXSAyZTcxNSBp
cyAyYTU2OTAwMCENClsgIDE5NC40NzYwNTFdIDJlNzE2IGlzIDJhNTY4MDAwIQ0KWyAgMTk0
LjQ3ODMyMF0gMmU3MTcgaXMgMmE1NjcwMDAhDQpbICAxOTQuNDgwNTQ3XSAyZTcxOFsgIDE5
Ni42MDkyNzldIDJlMjM1IGlzIDJhMWU3MDAwIQ0KWyAgMTk2LjYxMTA5Ml0gMmUyMzYgaXMg
MmExZTgwMDAhDQpbICAxOTYuNjEyODY1XSAyZTIzNyBpcyAyYTFlOTAwMCENClsgIDE5Ni42
MTQ2NjBdIDJlMjM4IGlzIDJhMWVhMDAwIQ0KWyAgMTk2LjYxNjQwNF0gMmUyMzkgaXMgMmEx
ZWIwMDAhDQpbICAxOTYuNjE4MTg2XSAyZTIzYSBpcyAyYTFlYzAwMCENClsgIDE5Ni42MjAx
OTRdIDJlMjNjIGlzIDJhMWQ4MDAwIQ0KWyAgMTk2LjYyMTk0OV0gMmUyM2QgaXMgMmExZDkw
MDAhDQpbICAxOTYuNjIzNzI2XSAyZTIzZSBpcyAyYTFkYTAwMCENClsgIDE5Ni42MjU0NzFd
IDJlMjNmIGlzIDJhMWRiMDAwIQ0KWyAgMTk2LjYyNzI0OV0gMmUyNDAgaXMgMmExZGMwMDAh
DQpbICAxOTYuNjI5MDAxXSAyZTI0MSBpcyAyYTFkZDAwMCENClsgIDE5Ni42MzA3NzBdIDJl
MjQyIGlzIDJhMWRlMDAwIQ0KWyAgMTk2LjYzMjUxNV0gMmUyNDMgaXMgMmExZGYwMDAhDQpb
ICAxOTYuNjM0MjcwXSAyZTI0NCBpcyAyYTFlMDAwMCENClsgIDE5Ni42MzYwMjhdIDJlMjQ1
IGlzIDJhMWUxMDAwIQ0KWyAgMTk2LjYzNzc3Ml0gMmUyNDYgaXMgMmExZDYwMDAhDQpbICAx
OTYuNjM5NjE3XSAyZTIzYiBpcyAyYTFkNTAwMCENClsgIDE5Ni42NDE3NTddIDJlMjQ3IGlz
IDJhMWQ0MDAwIQ0KWyAgMTk2LjY1MTQwN10gMmUyNDggaXMgMmExZDAwMDAhDQpbICAxOTYu
NjUzMTM4XSAyZTI0OSBpcyAyYTFkMTAwMCENClsgIDE5Ni42NTQ4NzRdIDJlMjRhIGlzIDJh
MWQyMDAwIQ0KWyAgMTk2LjY1NjYwMF0gMmUyNGIgaXMgMmExZDMwMDAhDQpbICAxOTYuNjY5
MTE5XSAyZTFjMiBpcyAyYTFjZjAwMCENClsgIDE5Ni42NzE0NDddIDJlMWMzIGlzIDJhMWNi
MDAwIQ0KWyAgMTk2LjY3MzIwMV0gMmUyNGMgaXMgMmExY2MwMDAhDQpbICAxOTYuNjc0OTQw
XSAyZTI0ZCBpcyAyYTFjZDAwMCENClsgIDE5Ni42NzY2NTVdIDJlMjRlIGlzIDJhMWNlMDAw
IQ0KWyAgMTk2LjY3ODcyN10gMmUxYzQgaXMgMmExY2EwMDAhDQpbICAxOTYuNjkyODQxXSAy
ZTFjNSBpcyAyYTFjNjAwMCENClsgIDE5Ni42OTQ3MzhdIDJlMjRmIGlzIDJhMWM3MDAwIQ0K
WyAgMTk2LjY5NjQ2Nl0gMmUyNTAgaXMgMmExYzgwMDAhDQpbICAxOTYuNjk4MjQyXSAyZTI1
MSBpcyAyYTFjOTAwMCENClsgIDE5Ni43MDAzNDldIDJlMjUyIGlzIDJhMWM1MDAwIQ0KWyAg
MTk2LjcwMjQ4Ml0gMmUyNTMgaXMgMmExYzQwMDAhDQpbICAxOTYuNzA0NzY4XSAyZTI1NCBp
cyAyYTFjMzAwMCENClsgIDE5Ni43MDY5MTFdIDJlMjU1IGlzIDJhMWMyMDAwIQ0KWyAgMTk2
LjcwOTAxMl0gMmUyNTYgaXMgMmExYzEwMDAhDQpbICAxOTYuNzExMTU4XSAyZTFjNiBpcyAy
YTFjMDAwMCENClsgIDE5Ni43MTMyODddIDJlMjU3IGlzIDJhMWJmMDAwIQ0KWyAgMTk2Ljcx
NTYxOV0gMmUyNTggaXMgMmExYmUwMDAhDQpbICAxOTYuNzE3NzgzXSAyZTI1OSBpcyAyYTFi
ZDAwMCENClsgIDE5Ni43MzA3ODRdIDJlMjVhIGlzIDJhMWI0MDAwIQ0KWyAgMTk2LjczMjU3
OV0gMmUyNWIgaXMgMmExYjUwMDAhDQpbICAxOTYuNzM0NDg2XSAyZTI1YyBpcyAyYTFiNjAw
MCENClsgIDE5Ni43MzYyNDNdIDJlMjVkIGlzIDJhMWI3MDAwIQ0KWyAgMTk2LjczNzk5Nl0g
MmUyNWUgaXMgMmExYjgwMDAhDQpbICAxOTYuNzM5NzQ2XSAyZTI1ZiBpcyAyYTFiOTAwMCEN
ClsgIDE5Ni43NDE0ODldIDJlMjYwIGlzIDJhMWJhMDAwIQ0KWyAgMTk2Ljc0MzIzM10gMmUy
NjEgaXMgMmExYmIwMDAhDQpbICAxOTYuNzQ0OTcxXSAyZTI2MiBpcyAyYTFiYzAwMCENClsg
IDE5Ni43NDY4ODFdIDJlMjYzIGlzIDJhMWE5MDAwIQ0KWyAgMTk2Ljc0ODY0MV0gMmUyNjQg
aXMgMmExYWEwMDAhDQpbICAxOTYuNzUwMzgwXSAyZTI2NSBpcyAyYTFhYjAwMCENClsgIDE5
Ni43NTIxMjBdIDJlMjY2IGlzIDJhMWFjMDAwIQ0KWyAgMTk2Ljc1MzgyN10gMmUyNjcgaXMg
MmExYWQwMDAhDQpbICAxOTYuNzU1NTI0XSAyZTI2OCBpcyAyYTFhZTAwMCENClsgIDE5Ni43
NTcyMDJdIDJlMjY5IGlzIDJhMWFmMDAwIQ0KWyAgMTk2Ljc1ODg3MF0gMmUyNmEgaXMgMmEx
YjAwMDAhDQpbICAxOTYuNzYwNTcwXSAyZTI2YiBpcyAyYTFiMTAwMCENClsgIDE5Ni43NjIy
MjZdIDJlMjZjIGlzIDJhMWIyMDAwIQ0KWyAgMTk2Ljc2MzkwMl0gMmUyNmQgaXMgMmExYjMw
MDAhDQpbICAxOTYuNzY1NTQwXSAyZTI2ZSBpcyAyYTFhNjAwMCENClsgIDE5Ni43NjcxODld
IDJlMjZmIGlzIDJhMWE3MDAwIQ0KWyAgMTk2Ljc2ODg0NF0gMmUyNzAgaXMgMmExYTgwMDAh
DQpbICAxOTYuNzcwODMxXSAyZTI3MSBpcyAyYTFhNTAwMCENClsgIDE5Ni43NzI4NTRdIDJl
MjcyIGlzIDJhMWE0MDAwIQ0KWyAgMTk2Ljc3NDk4NV0gMmUyNzMgaXMgMmExYTMwMDAhDQpb
ICAxOTYuNzc3MDE3XSAyZTI3NCBpcyAyYTFhMjAwMCENClsgIDE5Ni43ODQ5NzFdIDJlMjc1
IGlzIDJhMTllMDAwIQ0KWyAgMTk2Ljc4NjYxOV0gMmUyNzYgaXMgMmExOWYwMDAhDQpbICAx
OTYuNzg4MjU1XSAyZTI3NyBpcyAyYTFhMDAwMCENClsgIDE5Ni43ODk4OTldIDJlMjc4IGlz
IDJhMWExMDAwIQ0KWyAgMTk2Ljc5MTg3OV0gMmUxYzcgaXMgMmExOWQwMDAhDQpbICAxOTYu
NzkzOTExXSAyZTFjOCBpcyAyYTE5YzAwMCENClsgIDE5Ni43OTU5MzRdIDJlMjc5IGlzIDJh
MTliMDAwIQ0KWyAgMTk2Ljc5ODEwN10gMmUyN2EgaXMgMmExOWEwMDAhDQpbICAxOTYuODA5
MTkyXSAyZTI3YiBpcyAyYTE5NjAwMCENClsgIDE5Ni44MTA5MzFdIDJlMjdjIGlzIDJhMTk3
MDAwIQ0KWyAgMTk2LjgxMjYwMl0gMmUyN2QgaXMgMmExOTgwMDAhDQpbICAxOTYuODE0MzAw
XSAyZTI3ZSBpcyAyYTE5OTAwMCENClsgIDE5Ni44MTYzMjBdIDJlMjdmIGlzIDJhMTk1MDAw
IQ0KWyAgMTk2LjgxODM2OF0gMmUyODAgaXMgMmExOTQwMDAhDQpbICAxOTYuODIwNDg0XSAy
ZTI4MSBpcyAyYTE5MzAwMCENClsgIDE5Ni44MjI1NTldIDJlMjgzIGlzIDJhMTkyMDAwIQ0K
WyAgMTk2LjgyOTkyMl0gMmUyODIgaXMgMmExOGUwMDAhDQpbICAxOTYuODMxNjYxXSAyZTJh
MiBpcyAyYTE4ZjAwMCENClsgIDE5Ni44MzMzMzFdIDJlMmEzIGlzIDJhMTkwMDAwIQ0KWyAg
MTk2LjgzNTA0Nl0gMmUyYTQgaXMgMmExOTEwMDAhDQpbICAxOTYuODM3MDg4XSAyZTJhNSBp
cyAyYTE4ZDAwMCENClsgIDE5Ni44NDgwODBdIDJlMmE2IGlzIDJhMThjMDAwIQ0KWyAgMTk2
Ljg1MDE4N10gMmUyYTcgaXMgMmExOGIwMDAhDQpbICAxOTYuODUyNDc5XSAyZTJhOCBpcyAy
YTE4NzAwMCENClsgIDE5Ni44NTQxNzldIDJlMmE5IGlzIDJhMTg4MDAwIQ0KWyAgMTk2Ljg1
NTg0OF0gMmUyYWEgaXMgMmExODkwMDAhDQpbICAxOTYuODU3NTIyXSAyZTJhYiBpcyAyYTE4
YTAwMCENClsgIDE5Ni44NjAxNTFdIDJlMmFjIGlzIDJhOTdjMDAwIQ0KWyAgMTk2Ljg2MTgx
OF0gMmUyYWQgaXMgMmE5N2QwMDAhDQpbICAxOTYuODYzNTIxXSAyZTJhZSBpcyAyYTk3ZTAw
MCENClsgIDE5Ni44NjUxOTFdIDJlMmFmIGlzIDJhOTdmMDAwIQ0KWyAgMTk2Ljg2Njg3MF0g
MmUyYjAgaXMgMmE5ODAwMDAhDQpbICAxOTYuODY4NjMwXSAyZTJiMSBpcyAyYTk4MTAwMCEN
ClsgIDE5Ni44NzAzMTFdIDJlMmIyIGlzIDJhOTgyMDAwIQ0KWyAgMTk2Ljg3MTk4MF0gMmUy
YjMgaXMgMmE5ODMwMDAhDQpbICAxOTYuODczNjUwXSAyZTJiNCBpcyAyYTk4NDAwMCENClsg
IDE5Ni44NzUyODhdIDJlMmI1IGlzIDJhMTg1MDAwIQ0KWyAgMTk2Ljg3Njk2M10gMmUyYjYg
aXMgMmExODYwMDAhDQpbICAxOTYuODc4NzEwXSAyZTJjNCBpcyAyYTk2ZjAwMCENClsgIDE5
Ni44ODAzOTldIDJlMmM1IGlzIDJhOTcwMDAwIQ0KWyAgMTk2Ljg4MjA2MF0gMmUyYjcgaXMg
MmE5NzEwMDAhDQpbICAxOTYuODgzNzM0XSAyZTJiOCBpcyAyYTk3MjAwMCENClsgIDE5Ni44
ODU0MTFdIDJlMmI5IGlzIDJhOTczMDAwIQ0KWyAgMTk2Ljg4NzA5MF0gMmUyYmEgaXMgMmE5
NzQwMDAhDQpbICAxOTYuODg4NzkxXSAyZTJiYiBpcyAyYTk3NTAwMCENClsgIDE5Ni44OTA0
ODJdIDJlMmJjIGlzIDJhOTc2MDAwIQ0KWyAgMTk2Ljg5MjE1N10gMmUyYmQgaXMgMmE5Nzcw
MDAhDQpbICAxOTYuODkzODY2XSAyZTJiZSBpcyAyYTk3ODAwMCENClsgIDE5Ni44OTU1MzVd
IDJlMmJmIGlzIDJhOTc5MDAwIQ0KWyAgMTk2Ljg5NzIzM10gMmUyYzAgaXMgMmE5N2EwMDAh
DQpbICAxOTYuODk4ODk3XSAyZTJjMSBpcyAyYTk3YjAwMCENClsgIDE5Ni45MDA5MzFdIDJl
MmM2IGlzIDJhOTZlMDAwIQ0KWyAgMTk2LjkwMzE4OV0gMmUyODQgaXMgMmE5NmEwMDAhDQpb
ICAxOTYuOTA0OTE0XSAyZTJjNyBpcyAyYTk2YjAwMCENClsgIDE5Ni45MDY2MjldIDJlMmM4
IGlzIDJhOTZjMDAwIQ0KWyAgMTk2LjkwODM0OF0gMmUyYzkgaXMgMmE5NmQwMDAhDQpbICAx
OTYuOTEwNDQ3XSAyZTJjYSBpcyAyYTk2OTAwMCENClsgIDE5Ni45MTI3MjVdIDJlMmNiIGlz
IDJhOTY1MDAwIQ0KWyAgMTk2LjkxNDUyNl0gMmUyY2MgaXMgMmE5NjYwMDAhDQpbICAxOTYu
OTE2MjEzXSAyZTJjZCBpcyAyYTk2NzAwMCENClsgIDE5Ni45MTc5NDBdIDJlMmNlIGlzIDJh
OTY4MDAwIQ0KWyAgMTk2LjkxOTk4MF0gMmUyY2YgaXMgMmE5NjQwMDAhDQpbICAxOTYuOTIy
MjY0XSAyZTJkMCBpcyAyYTk2MDAwMCENClsgIDE5Ni45MjQwOTZdIDJlMmQxIGlzIDJhOTYx
MDAwIQ0KWyAgMTk2LjkyNTc4NF0gMmUyZDIgaXMgMmE5NjIwMDAhDQpbICAxOTYuOTI3NTA1
XSAyZTJkMyBpcyAyYTk2MzAwMCENClsgIDE5Ni45Mjk1MjNdIDJlMmQ0IGlzIDJhOTVmMDAw
IQ0KWyAgMTk2LjkzMTc1OV0gMmUyZDUgaXMgMmE5NWIwMDAhDQpbICAxOTYuOTMzNTUyXSAy
ZTJkNiBpcyAyYTk1YzAwMCENClsgIDE5Ni45MzUyNDddIDJlMmQ3IGlzIDJhOTVkMDAwIQ0K
WyAgMTk2LjkzNjkyNl0gMmUyZDggaXMgMmE5NWUwMDAhDQpbICAxOTYuOTM4OTM2XSAyZTJk
OSBpcyAyYTk1YTAwMCENClsgIDE5Ni45NDExNDBdIDJlMmRhIGlzIDJhOTU2MDAwIQ0KWyAg
MTk2Ljk0MjgwOV0gMmUyZGIgaXMgMmE5NTcwMDAhDQpbICAxOTYuOTQ0NDYzXSAyZTJkYyBp
cyAyYTk1ODAwMCENClsgIDE5Ni45NDYxMDFdIDJlMmRkIGlzIDJhOTU5MDAwIQ0KWyAgMTk2
Ljk0ODEyOV0gMmUyZGYgaXMgMmE5NTUwMDAhDQpbICAxOTYuOTUwMzExXSAyZTJlMCBpcyAy
YTk1MTAwMCENClsgIDE5Ni45NTE5ODFdIDJlMmUxIGlzIDJhOTUyMDAwIQ0KWyAgMTk2Ljk1
MzYzNF0gMmUyZTIgaXMgMmE5NTMwMDAhDQpbICAxOTYuOTU1Mjg2XSAyZTJlMyBpcyAyYTk1
NDAwMCENClsgIDE5Ni45NTc3NTRdIDJlMmU0IGlzIDJhOTQ2MDAwIQ0KWyAgMTk2Ljk1OTQ3
OF0gMmUyZTUgaXMgMmE5NDcwMDAhDQpbICAxOTYuOTYxMTIyXSAyZTJlNiBpcyAyYTk0ODAw
MCENClsgIDE5Ni45NjI3NDhdIDJlMmU3IGlzIDJhOTQ5MDAwIQ0KWyAgMTk2Ljk2NDQwMV0g
MmUyZTggaXMgMmE5NGEwMDAhDQpbICAxOTYuOTY2MDIxXSAyZTJlOSBpcyAyYTk0YjAwMCEN
ClsgIDE5Ni45Njc2NjJdIDJlMmVhIGlzIDJhOTRjMDAwIQ0KWyAgMTk2Ljk2OTI3OF0gMmUy
ZWIgaXMgMmE5NGQwMDAhDQpbICAxOTYuOTcwOTA2XSAyZTJlYyBpcyAyYTk0ZTAwMCENClsg
IDE5Ni45NzI1NDhdIDJlMmVkIGlzIDJhOTRmMDAwIQ0KWyAgMTk2Ljk3NDE4Nl0gMmUyZWUg
aXMgMmE5NTAwMDAhDQpbICAxOTYuOTc1OTcxXSAyZTJlZiBpcyAyYTkzYjAwMCENClsgIDE5
Ni45Nzc2MzldIDJlMmYwIGlzIDJhOTNjMDAwIQ0KWyAgMTk2Ljk3OTI4M10gMmUyZjEgaXMg
MmE5M2QwMDAhDQpbICAxOTYuOTgwOTU2XSAyZTJmMiBpcyAyYTkzZTAwMCENClsgIDE5Ni45
ODI2MDZdIDJlMmYzIGlzIDJhOTNmMDAwIQ0KWyAgMTk2Ljk4NDI3Nl0gMmUyZjQgaXMgMmE5
NDAwMDAhDQpbICAxOTYuOTg1OTE5XSAyZTJmNSBpcyAyYTk0MTAwMCENClsgIDE5Ni45ODc1
NzBdIDJlMmY2IGlzIDJhOTQyMDAwIQ0KWyAgMTk2Ljk4OTIzMV0gMmUyZjcgaXMgMmE5NDMw
MDAhDQpbICAxOTYuOTkwODg3XSAyZTJmOCBpcyAyYTk0NDAwMCENClsgIDE5Ni45OTI1NTFd
IDJlMmY5IGlzIDJhOTQ1MDAwIQ0KWyAgMTk2Ljk5NDIyM10gMmUyZmEgaXMgMmE5MzkwMDAh
DQpbICAxOTYuOTk1ODg0XSAyZTJmYiBpcyAyYTkzYTAwMCENClsgIDE5Ni45OTg4OTVdIDJl
Mjk5IGlzIDJhOTE5MDAwIQ0KWyAgMTk3LjAwMDcxNl0gMmUyOWEgaXMgMmE5MWEwMDAhDQpb
ICAxOTcuMDAyNDE3XSAyZTI5YiBpcyAyYTkxYjAwMCENClsgIDE5Ny4wMDQxMTVdIDJlMjlj
IGlzIDJhOTFjMDAwIQ0KWyAgMTk3LjAwNTc5OF0gMmUyOWQgaXMgMmE5MWQwMDAhDQpbICAx
OTcuMDA3NTE4XSAyZTI5ZSBpcyAyYTkxZTAwMCENClsgIDE5Ny4wMDkyODhdIDJlMjlmIGlz
IDJhOTFmMDAwIQ0KWyAgMTk3LjAxMDk3Ml0gMmUyYTAgaXMgMmE5MjAwMDAhDQpbICAxOTcu
MDEyNjQ3XSAyZTJhMSBpcyAyYTkyMTAwMCENClsgIDE5Ny4wMTQzNjBdIDJlMzAxIGlzIDJh
OTIyMDAwIQ0KWyAgMTk3LjAxNjAzNV0gMmUzMDIgaXMgMmE5MjMwMDAhDQpbICAxOTcuMDE3
NzQxXSAyZTJmYyBpcyAyYTkyZjAwMCENClsgIDE5Ny4wMTk0MjldIDJlMjg1IGlzIDJhOTMw
MDAwIQ0KWyAgMTk3LjAyMTE1MF0gMmUyODYgaXMgMmE5MzEwMDAhDQpbICAxOTcuMDIyODc2
XSAyZTI4NyBpcyAyYTkzMjAwMCENClsgIDE5Ny4wMjQ2MDJdIDJlMjg4IGlzIDJhOTMzMDAw
IQ0KWyAgMTk3LjAyNjMyMl0gMmUyODkgaXMgMmE5MzQwMDAhDQpbICAxOTcuMDI4MDM3XSAy
ZTI4YSBpcyAyYTkzNTAwMCENClsgIDE5Ny4wMjk3MzZdIDJlMjhiIGlzIDJhOTM2MDAwIQ0K
WyAgMTk3LjAzMTQ0M10gMmUyOGMgaXMgMmE5MzcwMDAhDQpbICAxOTcuMDMzMTIxXSAyZTI4
ZCBpcyAyYTkzODAwMCENClsgIDE5Ny4wMzUxMTJdIDJlMzAzIGlzIDJhOTBlMDAwIQ0KWyAg
MTk3LjAzNjgxN10gMmUzMDQgaXMgMmE5MGYwMDAhDQpbICAxOTcuMDM4NTE1XSAyZTMwNSBp
cyAyYTkxMDAwMCENClsgIDE5Ny4wNDAyMTNdIDJlMzA2IGlzIDJhOTExMDAwIQ0KWyAgMTk3
LjA0MTg5N10gMmUzMDcgaXMgMmE5MTIwMDAhDQpbICAxOTcuMDQzNjA5XSAyZTMwOCBpcyAy
YTkxMzAwMCENClsgIDE5Ny4wNDUyOTNdIDJlMzA5IGlzIDJhOTE0MDAwIQ0KWyAgMTk3LjA0
Njk5OV0gMmUzMGEgaXMgMmE5MTUwMDAhDQpbICAxOTcuMDQ4NjcyXSAyZTMwYiBpcyAyYTkx
NjAwMCENClsgIDE5Ny4wNTAzNTFdIDJlMzBjIGlzIDJhOTE3MDAwIQ0KWyAgMTk3LjA1MjA0
MF0gMmUzMGQgaXMgMmE5MTgwMDAhDQpbICAxOTcuMDUzNzIwXSAyZTMwZSBpcyAyYTkwMzAw
MCENClsgIDE5Ny4wNTUzODZdIDJlMzBmIGlzIDJhOTA0MDAwIQ0KWyAgMTk3LjA1NzA1Ml0g
MmUzMTAgaXMgMmE5MDUwMDAhDQpbICAxOTcuMDU4NzE5XSAyZTMxMSBpcyAyYTkwNjAwMCEN
ClsgIDE5Ny4wNjA0MTVdIDJlMzEyIGlzIDJhOTA3MDAwIQ0KWyAgMTk3LjA2MjA4OF0gMmUz
MTMgaXMgMmE5MDgwMDAhDQpbICAxOTcuMDYzNzk0XSAyZTMxNCBpcyAyYTkwOTAwMCENClsg
IDE5Ny4wNjU0NTVdIDJlMzE1IGlzIDJhOTBhMDAwIQ0KWyAgMTk3LjA2NzEyN10gMmUzMTYg
aXMgMmE5MGIwMDAhDQpbICAxOTcuMDY4Nzk5XSAyZTMxNyBpcyAyYTkwYzAwMCENClsgIDE5
Ny4wNzA0NjddIDJlMzE4IGlzIDJhOTBkMDAwIQ0KWyAgMTk3LjA3MjEzM10gMmUzMTkgaXMg
MmE4ZmQwMDAhDQpbICAxOTcuMDczNzg4XSAyZTMxYSBpcyAyYThmZTAwMCENClsgIDE5Ny4w
NzU0MjVdIDJlMzFiIGlzIDJhOGZmMDAwIQ0KWyAgMTk3LjA3NzA5MV0gMmUzMWMgaXMgMmE5
MDAwMDAhDQpbICAxOTcuMDc4NzQxXSAyZTMxZCBpcyAyYTkwMTAwMCENClsgIDE5Ny4wODA0
MTldIDJlMzFlIGlzIDJhOTAyMDAwIQ0KWyAgMTk3LjA4MjA3NF0gMmUzMWYgaXMgMmE4ZmMw
MDAhDQpbICAxOTcuMDgzNzU4XSAyZTI4ZSBpcyAyYTkyNDAwMCENClsgIDE5Ny4wODU0NjRd
IDJlMjhmIGlzIDJhOTI1MDAwIQ0KWyAgMTk3LjA4NzE2NV0gMmUyOTAgaXMgMmE5MjYwMDAh
DQpbICAxOTcuMDg4ODYxXSAyZTI5MSBpcyAyYTkyNzAwMCENClsgIDE5Ny4wOTA1NTFdIDJl
MjkyIGlzIDJhOTI4MDAwIQ0KWyAgMTk3LjA5MjIyOV0gMmUyOTMgaXMgMmE5MjkwMDAhDQpb
ICAxOTcuMDkzOTgwXSAyZTI5NCBpcyAyYTkyYTAwMCENClsgIDE5Ny4wOTU2NThdIDJlMjk1
IGlzIDJhOTJiMDAwIQ0KWyAgMTk3LjA5NzM2NV0gMmUyOTYgaXMgMmE5MmMwMDAhDQpbICAx
OTcuMDk5MDQzXSAyZTI5NyBpcyAyYTkyZDAwMCENClsgIDE5Ny4xMDA3NTRdIDJlMjk4IGlz
IDJhOTJlMDAwIQ0KWyAgMTk3LjEwMjc4NV0gMmUzMjAgaXMgMmE4ZmIwMDAhDQpbICAxOTcu
MTA0ODk5XSAyZTJmZCBpcyAyYThmYTAwMCENClsgIDE5Ny4xMDY5NDhdIDJlMzIxIGlzIDJh
OGY5MDAwIQ0KWyAgMTk3LjEwOTA1OV0gMmUyZmUgaXMgMmE4ZjgwMDAhDQpbICAxOTcuMTEx
MzA4XSAyZTJmZiBpcyAyYThmNzAwMCENClsgIDE5Ny4xMTM0NTZdIDJlMzAwIGlzIDJhOGY2
MDAwIQ0KWyAgMTk3LjExNTU4OF0gMmUzM2YgaXMgMmE4ZjUwMDAhDQpbICAxOTcuMTE3Njkx
XSAyZTM0MCBpcyAyYThmNDAwMCENClsgIDE5Ny4xMTk4MDBdIDJlMzQxIGlzIDJhOGYzMDAw
IQ0KWyAgMTk3LjEyMTk1NV0gMmUzMjIgaXMgMmE4ZjIwMDAhDQpbICAxOTcuMTI0MDgyXSAy
ZTM0MiBpcyAyYThmMTAwMCENClsgIDE5Ny4xMzE2MTldIDJlMzRlIGlzIDJhOGU1MDAwIQ0K
WyAgMTk3LjEzMzQ1OF0gMmUzNDMgaXMgMmE4ZTYwMDAhDQpbICAxOTcuMTM1MjU2XSAyZTM0
NCBpcyAyYThlNzAwMCENClsgIDE5Ny4xMzcwNDNdIDJlMzQ1IGlzIDJhOGU4MDAwIQ0KWyAg
MTk3LjEzODgzMV0gMmUzNDYgaXMgMmE4ZTkwMDAhDQpbICAxOTcuMTQwNjE1XSAyZTM0NyBp
cyAyYThlYTAwMCENClsgIDE5Ny4xNDIzOTNdIDJlMzQ4IGlzIDJhOGViMDAwIQ0KWyAgMTk3
LjE0NDE3NV0gMmUzNDkgaXMgMmE4ZWMwMDAhDQpbICAxOTcuMTQ1OTM5XSAyZTM0YSBpcyAy
YThlZDAwMCENClsgIDE5Ny4xNDc3MjBdIDJlMzRiIGlzIDJhOGVlMDAwIQ0KWyAgMTk3LjE0
OTQ1MV0gMmUzNGMgaXMgMmE4ZWYwMDAhDQpbICAxOTcuMTUxMjEwXSAyZTM0ZCBpcyAyYThm
MDAwMCENClsgIDE5Ny4xNTMyOTVdIDJlMzRmIGlzIDJhOGU0MDAwIQ0KWyAgMTk3LjE1NTYw
Nl0gMmUzNTAgaXMgMmE4ZTAwMDAhDQpbICAxOTcuMTU3NDczXSAyZTM1MSBpcyAyYThlMTAw
MCENClsgIDE5Ny4xNTkyNDJdIDJlMzUyIGlzIDJhOGUyMDAwIQ0KWyAgMTk3LjE2MTAxNF0g
MmUzNTMgaXMgMmE4ZTMwMDAhDQpbICAxOTcuMTYzNDk1XSAyZTM1YyBpcyAyYThkNzAwMCEN
ClsgIDE5Ny4xNjUyNzBdIDJlMzU0IGlzIDJhOGQ4MDAwIQ0KWyAgMTk3LjE2NzA1Ml0gMmUz
NTUgaXMgMmE4ZDkwMDAhDQpbICAxOTcuMTY4ODIyXSAyZTM1NiBpcyAyYThkYTAwMCENClsg
IDE5Ny4xNzA1NjVdIDJlMzU3IGlzIDJhOGRiMDAwIQ0KWyAgMTk3LjE3MjMwNV0gMmUzNTgg
aXMgMmE4ZGMwMDAhDQpbICAxOTcuMTc0MDI0XSAyZTM1OSBpcyAyYThkZDAwMCENClsgIDE5
Ny4xNzU3MzRdIDJlMzVhIGlzIDJhOGRlMDAwIQ0KWyAgMTk3LjE3NzQyOV0gMmUzNWIgaXMg
MmE4ZGYwMDAhDQpbICAxOTcuMTg3NDI1XSAyZTM1ZCBpcyAyYThkMjAwMCENClsgIDE5Ny4x
ODkxNTNdIDJlMzVlIGlzIDJhOGQzMDAwIQ0KWyAgMTk3LjE5MDgyNV0gMmUzNWYgaXMgMmE4
ZDQwMDAhDQpbICAxOTcuMTkyNDk4XSAyZTM2MCBpcyAyYThkNTAwMCENClsgIDE5Ny4xOTQx
NjddIDJlMzYxIGlzIDJhOGQ2MDAwIQ0KWyAgMTk3LjE5NTk2MV0gMmUzNjMgaXMgMmE4Y2Qw
MDAhDQpbICAxOTcuMTk3NjQyXSAyZTM2NCBpcyAyYThjZTAwMCENClsgIDE5Ny4xOTkyODFd
IDJlMzY1IGlzIDJhOGNmMDAwIQ0KWyAgMTk3LjIwMDk1Nl0gMmUzNjYgaXMgMmE4ZDAwMDAh
DQpbICAxOTcuMjAyNjE4XSAyZTM2NyBpcyAyYThkMTAwMCENClsgIDE5Ny4yMDQzNzNdIDJl
MzYyIGlzIDJhOGNiMDAwIQ0KWyAgMTk3LjIxNjc0OF0gMmUzNjggaXMgMmE4OTYwMDAhDQpb
ICAxOTcuMjE4NDU0XSAyZTM2OSBpcyAyYTg5NTAwMCENClsgIDE5Ny4yMjAxNTJdIDJlMzZh
IGlzIDJhODk0MDAwIQ0KWyAgMTk3LjIyMTg0NV0gMmUzNmIgaXMgMmE4OTMwMDAhDQpbICAx
OTcuMjI0MjgzXSAyZTM2YyBpcyAyYTg5ZTAwMCENClsgIDE5Ny4yMjU5OTBdIDJlMzZkIGlz
IDJhODlkMDAwIQ0KWyAgMTk3LjIyNzY3N10gMmUzNmUgaXMgMmE4OWMwMDAhDQpbICAxOTcu
MjI5MzQzXSAyZTM2ZiBpcyAyYTg5YjAwMCENClsgIDE5Ny4yMzEwNDFdIDJlMzcwIGlzIDJh
ODlhMDAwIQ0KWyAgMTk3LjIzMjcwNV0gMmUzNzEgaXMgMmE4OTkwMDAhDQpbICAxOTcuMjM0
NDAyXSAyZTM3MiBpcyAyYTg5ODAwMCENClsgIDE5Ny4yWyAgMTk5LjM3Mjg1N10gMmRlZmYg
aXMgMmFkMGUwMDAhDQpbICAxOTkuMzc0NjY0XSAyZGYwMCBpcyAyYWQyZjAwMCENClsgIDE5
OS4zNzY0MjNdIDJkZjAxIGlzIDJhZDMwMDAwIQ0KWyAgMTk5LjM3ODE5Ml0gMmRmMDIgaXMg
MmFkMzEwMDAhDQpbICAxOTkuMzg1MTA1XSAyZGYwMyBpcyAyYWQwZDAwMCENClsgIDE5OS4z
ODcyODBdIDJkZjA0IGlzIDJhZDBjMDAwIQ0KWyAgMTk5LjM4OTQzOV0gMmRmMDUgaXMgMmFk
MGIwMDAhDQpbICAxOTkuMzkxNTg2XSAyZGYwNiBpcyAyYWQwYTAwMCENClsgIDE5OS40MDQx
OTFdIDJkZjEyIGlzIDJhY2ZlMDAwIQ0KWyAgMTk5LjQwNTk3OF0gMmRmMDcgaXMgMmFjZmYw
MDAhDQpbICAxOTkuNDA3NzY2XSAyZGYwOCBpcyAyYWQwMDAwMCENClsgIDE5OS40MDk1NjFd
IDJkZjA5IGlzIDJhZDAxMDAwIQ0KWyAgMTk5LjQxMTM2NF0gMmRmMGEgaXMgMmFkMDIwMDAh
DQpbICAxOTkuNDEzMTQ0XSAyZGYwYiBpcyAyYWQwMzAwMCENClsgIDE5OS40MTQ5NDZdIDJk
ZjBjIGlzIDJhZDA0MDAwIQ0KWyAgMTk5LjQxNjcyNl0gMmRmMGQgaXMgMmFkMDUwMDAhDQpb
ICAxOTkuNDE4NDkzXSAyZGYwZSBpcyAyYWQwNjAwMCENClsgIDE5OS40MjAyNTldIDJkZjBm
IGlzIDJhZDA3MDAwIQ0KWyAgMTk5LjQyMjAyNV0gMmRmMTAgaXMgMmFkMDgwMDAhDQpbICAx
OTkuNDIzODAyXSAyZGYxMSBpcyAyYWQwOTAwMCENClsgIDE5OS40MjU5MjBdIDJkZjEzIGlz
IDJhY2ZkMDAwIQ0KWyAgMTk5LjQyODExMF0gMmRmMTQgaXMgMmFjZmMwMDAhDQpbICAxOTku
NDMwMTQ2XSAyZGU5OCBpcyAyYWNmYjAwMCENClsgIDE5OS40MzI2NDBdIDJkZjE1IGlzIDJh
Y2ZhMDAwIQ0KWyAgMTk5LjQzNDgwM10gMmRmMTYgaXMgMmFjZjkwMDAhDQpbICAxOTkuNDM2
OTQ2XSAyZGYxNyBpcyAyYWNmODAwMCENClsgIDE5OS40MzkwNzRdIDJkZjE4IGlzIDJhY2Y3
MDAwIQ0KWyAgMTk5LjQ0MTIwOV0gMmRmMTkgaXMgMmFjZjYwMDAhDQpbICAxOTkuNDQzMzM5
XSAyZGYxYSBpcyAyYWNmNTAwMCENClsgIDE5OS40NDU0OTldIDJkZjFiIGlzIDJhY2Y0MDAw
IQ0KWyAgMTk5LjQ0NzYyNl0gMmRmMWMgaXMgMmFjZjMwMDAhDQpbICAxOTkuNDUzNjAyXSAy
ZGYxZCBpcyAyYWNmMjAwMCENClsgIDE5OS40NTU2OTZdIDJkZjFlIGlzIDJhY2YxMDAwIQ0K
WyAgMTk5LjQ2NjgxMV0gMmRmMWYgaXMgMmFjZWQwMDAhDQpbICAxOTkuNDY4NTI3XSAyZGYy
MCBpcyAyYWNlZTAwMCENClsgIDE5OS40NzAyNTVdIDJkZjIxIGlzIDJhY2VmMDAwIQ0KWyAg
MTk5LjQ3MTk3MF0gMmRmMjIgaXMgMmFjZjAwMDAhDQpbICAxOTkuNDc0MDU0XSAyZGU5OSBp
cyAyYWNlYzAwMCENClsgIDE5OS40NzYxODNdIDJkZTlhIGlzIDJhY2ViMDAwIQ0KWyAgMTk5
LjQ3ODMxNl0gMmRmMjMgaXMgMmFjZWEwMDAhDQpbICAxOTkuNDg2OTExXSAyZGU5YiBpcyAy
YWNlNjAwMCENClsgIDE5OS40ODg2NDZdIDJkZjI0IGlzIDJhY2U3MDAwIQ0KWyAgMTk5LjQ5
MDM2OV0gMmRmMjUgaXMgMmFjZTgwMDAhDQpbICAxOTkuNDkyMDg3XSAyZGYyNiBpcyAyYWNl
OTAwMCENClsgIDE5OS40OTQxOThdIDJkZTljIGlzIDJhY2U1MDAwIQ0KWyAgMTk5LjUwMTM2
NF0gMmRlOWQgaXMgMmFjZTQwMDAhDQpbICAxOTkuNTAzODEwXSAyZGYyNyBpcyAyYWNlMzAw
MCENClsgIDE5OS41MDU5OTNdIDJkZjI4IGlzIDJhY2UyMDAwIQ0KWyAgMTk5LjUwODE4Ml0g
MmRmMjkgaXMgMmFjZTEwMDAhDQpbICAxOTkuNTEwOTcxXSAyZGYzNSBpcyAyYWNkNTAwMCEN
ClsgIDE5OS41MTI3NjFdIDJkZjJhIGlzIDJhY2Q2MDAwIQ0KWyAgMTk5LjUxNDU3Ml0gMmRm
MmIgaXMgMmFjZDcwMDAhDQpbICAxOTkuNTE2MzM0XSAyZGYyYyBpcyAyYWNkODAwMCENClsg
IDE5OS41MTgxNDBdIDJkZjJkIGlzIDJhY2Q5MDAwIQ0KWyAgMTk5LjUxOTg5OF0gMmRmMmUg
aXMgMmFjZGEwMDAhDQpbICAxOTkuNTIxNjY3XSAyZGYyZiBpcyAyYWNkYjAwMCENClsgIDE5
OS41MjM0NjJdIDJkZjMwIGlzIDJhY2RjMDAwIQ0KWyAgMTk5LjUyNTIxOF0gMmRmMzEgaXMg
MmFjZGQwMDAhDQpbICAxOTkuNTI3MDA3XSAyZGYzMiBpcyAyYWNkZTAwMCENClsgIDE5OS41
Mjg3NjBdIDJkZjMzIGlzIDJhY2RmMDAwIQ0KWyAgMTk5LjUzMDU0OF0gMmRmMzQgaXMgMmFj
ZTAwMDAhDQpbICAxOTkuNjY1NjQyXSAyZGY1OCBpcyAyYWNkNDAwMCENClsgIDE5OS42NzI0
MjBdIDJkZjU5IGlzIDJhY2QzMDAwIQ0KWyAgMTk5LjY3NDc0Nl0gMmRmNWEgaXMgMmFjZDIw
MDAhDQpbICAxOTkuNjc3MTI5XSAyZGY1YiBpcyAyYWNjZTAwMCENClsgIDE5OS42Nzg5NDBd
IDJkZjVjIGlzIDJhY2NmMDAwIQ0KWyAgMTk5LjY4MDc2OF0gMmRmNWQgaXMgMmFjZDAwMDAh
DQpbICAxOTkuNjgyNTY2XSAyZGY1ZSBpcyAyYWNkMTAwMCENClsgIDE5OS43MDIzMTJdIDMx
YTNiIGlzIDJhY2M2MDAwIQ0KWyAgMTk5LjcwNDE0OV0gMzFhM2EgaXMgMmFjYzcwMDAhDQpb
ICAxOTkuNzA1OTY4XSAzMWEzOSBpcyAyYWNjODAwMCENClsgIDE5OS43MDc3ODBdIDMxYTM4
IGlzIDJhY2M5MDAwIQ0KWyAgMTk5LjcwOTU3N10gMzFhMzcgaXMgMmFjY2EwMDAhDQpbICAx
OTkuNzExMzYzXSAzMWEzNiBpcyAyYWNjYjAwMCENClsgIDE5OS43MTMxNDZdIDMxYTM1IGlz
IDJhY2NjMDAwIQ0KWyAgMTk5LjcxNDkzMF0gMzFhMzQgaXMgMmFjY2QwMDAhDQpbICAxOTku
NzI2NTM4XSAzMWEzMyBpcyAyYWNjNTAwMCENClsgIDE5OS43MzM0MTBdIDJkZjVmIGlzIDJh
Y2M0MDAwIQ0KWyAgMTk5LjczOTYwMl0gMmRmNzAgaXMgMmFjYzMwMDAhDQpbICAxOTkuNzQy
MDE5XSAyZGY3MSBpcyAyYWNiZjAwMCENClsgIDE5OS43NDM4ODFdIDJkZjcyIGlzIDJhY2Mw
MDAwIQ0KWyAgMTk5Ljc0NTY0OV0gMmRmNzMgaXMgMmFjYzEwMDAhDQpbICAxOTkuNzQ3NDU3
XSAyZGY3NCBpcyAyYWNjMjAwMCENClsgIDE5OS43NjMzMzZdIDJkZjc1IGlzIDJhY2JlMDAw
IQ0KWyAgMTk5Ljc2NTgwMl0gMmRmNzggaXMgMmFjYmEwMDAhDQpbICAxOTkuNzY3NjYzXSAy
ZGY3OSBpcyAyYWNiYjAwMCENClsgIDE5OS43Njk0NDVdIDJkZjdhIGlzIDJhY2JjMDAwIQ0K
WyAgMTk5Ljc3MTMyOV0gMmRmN2IgaXMgMmFjYmQwMDAhDQpbICAxOTkuODI2MTk1XSAzMWE0
OSBpcyAyYWNiMjAwMCENClsgIDE5OS44MjgxMTddIDM5M2I2IGlzIDJhY2IzMDAwIQ0KWyAg
MTk5LjgyOTk2Ml0gMzZlNDYgaXMgMmFjYjQwMDAhDQpbICAxOTkuODMxODI0XSAzN2IzZiBp
cyAyYWNiNTAwMCENClsgIDE5OS44MzM2OTVdIDM2ZDZmIGlzIDJhY2I2MDAwIQ0KWyAgMTk5
LjgzNTU1NF0gMzhjYmMgaXMgMmFjYjcwMDAhDQpbICAxOTkuODM3NDI3XSAyZGU5ZSBpcyAy
YWNiODAwMCENClsgIDE5OS44MzkzMjBdIDJkZTlmIGlzIDJhY2I5MDAwIQ0KWyAgMTk5Ljg0
MTIwNV0gMmRlYTAgaXMgMmFjYTcwMDAhDQpbICAxOTkuODQzMTQyXSAyZGVhMSBpcyAyYWNh
ODAwMCENClsgIDE5OS44NDUwOTBdIDJkZWEyIGlzIDJhY2E5MDAwIQ0KWyAgMTk5Ljg0NzAw
Ml0gMmRlYTMgaXMgMmFjYWEwMDAhDQpbICAxOTkuODQ4ODQ1XSAyZGVhNCBpcyAyYWNhYjAw
MCENClsgIDE5OS44NTA3MTBdIDJkZjhlIGlzIDJhY2FjMDAwIQ0KWyAgMTk5Ljg1MjU2Ml0g
MmRmOGYgaXMgMmFjYWQwMDAhDQpbICAxOTkuODU0NDI3XSAyZGY5MCBpcyAyYWNhZTAwMCEN
ClsgIDE5OS44NTYzMDJdIDJkZjkxIGlzIDJhY2FmMDAwIQ0KWyAgMTk5Ljg1ODE2OF0gMmRm
OTIgaXMgMmFjYjAwMDAhDQpbICAxOTkuODYwMDU2XSAyZGY5MyBpcyAyYWNiMTAwMCENClsg
IDE5OS44NjE5MThdIDJkZjk0IGlzIDJhY2EyMDAwIQ0KWyAgMTk5Ljg2MzgxOV0gMmRmOTUg
aXMgMmFjYTMwMDAhDQpbICAxOTkuODY1NjUyXSAyZGY5NiBpcyAyYWNhNDAwMCENClsgIDE5
OS44Njc1MDldIDJkZjk3IGlzIDJhY2E1MDAwIQ0KWyAgMTk5Ljg2OTMyN10gMmRmOTggaXMg
MmFjYTYwMDAhDQpbICAxOTkuODcyMTkxXSAyZTc0YyBpcyAyYWM5NzAwMCENClsgIDE5OS44
NzQwNTJdIDJkZjc2IGlzIDJhYzk4MDAwIQ0KWyAgMTk5Ljg3NTkyNl0gMmRmNzcgaXMgMmFj
OTkwMDAhDQpbICAxOTkuODc3NzkwXSAyZTdhNyBpcyAyYWM5YTAwMCENClsgIDE5OS44Nzk2
NjJdIDJkZjdjIGlzIDJhYzliMDAwIQ0KWyAgMTk5Ljg4MTU1MF0gMmRmN2QgaXMgMmFjOWMw
MDAhDQpbICAxOTkuODgzNDQ3XSAyZGY3ZSBpcyAyYWM5ZDAwMCENClsgIDE5OS44ODUzMzhd
IDJkZjdmIGlzIDJhYzllMDAwIQ0KWyAgMTk5Ljg4NzE4OV0gMmRmODAgaXMgMmFjOWYwMDAh
DQpbICAxOTkuODg5MDU0XSAyZGY4MSBpcyAyYWNhMDAwMCENClsgIDE5OS44OTA4OTZdIDJk
ZjgyIGlzIDJhY2ExMDAwIQ0KWyAgMTk5Ljg5MzIxNF0gMmRmODMgaXMgMmFjNjMwMDAhDQpb
ICAxOTkuODk1MDQzXSAyZGY4YiBpcyAyYWM4NDAwMCENClsgIDE5OS44OTY4NzFdIDJkZjhj
IGlzIDJhYzg1MDAwIQ0KWyAgMTk5Ljg5ODY0Ml0gMmRmOGQgaXMgMmFjODYwMDAhDQpbICAx
OTkuOTAwNDQ2XSAyZGZhZCBpcyAyYWM4NzAwMCENClsgIDE5OS45MDIyMTBdIDJkZmFlIGlz
IDJhYzg4MDAwIQ0KWyAgMTk5LjkwMzk5MF0gMmRmYWYgaXMgMmFjODkwMDAhDQpbICAxOTku
OTA1NzY1XSAyZGZiMCBpcyAyYWM4YTAwMCENClsgIDE5OS45MDc1NDhdIDJkZmIxIGlzIDJh
YzhiMDAwIQ0KWyAgMTk5LjkwOTMzNl0gMmRmYjIgaXMgMmFjOGMwMDAhDQpbICAxOTkuOTEx
MTAzXSAyZGZiMyBpcyAyYWM4ZDAwMCENClsgIDE5OS45MTI4NzZdIDJkZmI0IGlzIDJhYzhl
MDAwIQ0KWyAgMTk5LjkxNDY0Ml0gMmRmYjUgaXMgMmFjNzkwMDAhDQpbICAxOTkuOTE2NDAw
XSAyZGZiNiBpcyAyYWM3YTAwMCENClsgIDE5OS45MTgxODNdIDJkZmI3IGlzIDJhYzdiMDAw
IQ0KWyAgMTk5LjkxOTkzMF0gMmRmYjggaXMgMmFjN2MwMDAhDQpbICAxOTkuOTIxNzAxXSAy
ZGZiOSBpcyAyYWM3ZDAwMCENClsgIDE5OS45MjM0NjldIDJkZmJhIGlzIDJhYzdlMDAwIQ0K
WyAgMTk5LjkyNTIyNF0gMmRmYmIgaXMgMmFjN2YwMDAhDQpbICAxOTkuOTI3MDA0XSAyZGZi
YyBpcyAyYWM4MDAwMCENClsgIDE5OS45Mjg3NThdIDJkZmJkIGlzIDJhYzgxMDAwIQ0KWyAg
MTk5LjkzMDUxMV0gMmRmYmUgaXMgMmFjODIwMDAhDQpbICAxOTkuOTMyMjIzXSAyZGZiZiBp
cyAyYWM4MzAwMCENClsgIDE5OS45MzM5NjZdIDJkZmMwIGlzIDJhYzc2MDAwIQ0KWyAgMTk5
LjkzNTY3OF0gMmRmYzEgaXMgMmFjNzcwMDAhDQpbICAxOTkuOTM3MzkwXSAyZGZjMiBpcyAy
YWM3ODAwMCENClsgIDE5OS45MzkwOTddIDJkZmMzIGlzIDJhYzZiMDAwIQ0KWyAgMTk5Ljk0
MDgwMF0gMmRmYzQgaXMgMmFjNmMwMDAhDQpbICAxOTkuOTQyNTEyXSAyZGZjNSBpcyAyYWM2
ZDAwMCENClsgIDE5OS45NDQyMTVdIDJkZmM2IGlzIDJhYzZlMDAwIQ0KWyAgMTk5Ljk0NTg5
M10gMmRmYzcgaXMgMmFjNmYwMDAhDQpbICAxOTkuOTQ3NTk0XSAyZGZjOCBpcyAyYWM3MDAw
MCENClsgIDE5OS45NDkyNjFdIDJkZmM5IGlzIDJhYzcxMDAwIQ0KWyAgMTk5Ljk1MDk1Ml0g
MmRmY2EgaXMgMmFjNzIwMDAhDQpbICAxOTkuOTUyNjE4XSAyZGZjYiBpcyAyYWM3MzAwMCEN
ClsgIDE5OS45NTQzMDBdIDJkZmNlIGlzIDJhYzc0MDAwIQ0KWyAgMTk5Ljk1NTk3N10gMmRm
Y2YgaXMgMmFjNzUwMDAhDQpbICAxOTkuOTU3NjUwXSAyZGZkMCBpcyAyYWM2NDAwMCENClsg
IDE5OS45NTkzNDVdIDJkZmQxIGlzIDJhYzY1MDAwIQ0KWyAgMTk5Ljk2MTAzMF0gMmRmZDIg
aXMgMmFjNjYwMDAhDQpbICAxOTkuOTYyNzIzXSAyZGZkMyBpcyAyYWM2NzAwMCENClsgIDE5
OS45NjQ0MTVdIDJkZmQ0IGlzIDJhYzY4MDAwIQ0KWyAgMTk5Ljk2NjA4N10gMmRmZDUgaXMg
MmFjNjkwMDAhDQpbICAxOTkuOTY3Nzg4XSAyZGZkNiBpcyAyYWM2YTAwMCENClsgIDE5OS45
Njk0NDldIDJkZjg0IGlzIDJhYzkwMDAwIQ0KWyAgMTk5Ljk3MTE0OF0gMmRmODUgaXMgMmFj
OTEwMDAhDQpbICAxOTkuOTcyODIxXSAyZGY4NiBpcyAyYWM5MjAwMCENClsgIDE5OS45NzQ1
MDhdIDJkZjg3IGlzIDJhYzkzMDAwIQ0KWyAgMTk5Ljk3NjE5MV0gMmRmODggaXMgMmFjOTQw
MDAhDQpbICAxOTkuOTc3ODcxXSAyZGY4OSBpcyAyYWM5NTAwMCENClsgIDE5OS45Nzk1NDVd
IDJkZjhhIGlzIDJhYzk2MDAwIQ0KWyAgMTk5Ljk4MTU3NF0gMmRmOTkgaXMgMmFjNjIwMDAh
DQpbICAxOTkuOTgzNjM4XSAyZGY5YSBpcyAyYWM2MTAwMCENClsgIDE5OS45ODU2ODZdIDM2
ZGVkIGlzIDJhYzYwMDAwIQ0KWyAgMTk5Ljk4Nzc2Nl0gMmRmZDcgaXMgMmFjNWYwMDAhDQpb
ICAxOTkuOTg5ODUxXSAyZGZkOCBpcyAyYWM1ZTAwMCENClsgIDE5OS45OTE5MzNdIDJkZmQ5
IGlzIDJhYzVkMDAwIQ0KWyAgMTk5Ljk5NDAwNF0gMmRmZGEgaXMgMmFjNWMwMDAhDQpbICAx
OTkuOTk2MDgzXSAyZGZkYiBpcyAyYWM1YjAwMCENClsgIDIwMC4wMTM1MDldIDJkZmRjIGlz
IDJhYzUwMDAwIQ0KWyAgMjAwLjAxNTI4MV0gMmRmZGQgaXMgMmFjNTEwMDAhDQpbICAyMDAu
MDE3MDQ1XSAyZGZkZSBpcyAyYWM1MjAwMCENClsgIDIwMC4wMTg3NzJdIDJkZmRmIGlzIDJh
YzUzMDAwIQ0KWyAgMjAwLjAyMDUyM10gMmRmZTAgaXMgMmFjNTQwMDAhDQpbICAyMDAuMDIy
Mjc4XSAyZGZlMSBpcyAyYWM1NTAwMCENClsgIDIwMC4wMjQwMjhdIDJkZmUyIGlzIDJhYzU2
MDAwIQ0KWyAgMjAwLjAyNTc3M10gMmRmZTMgaXMgMmFjNTcwMDAhDQpbICAyMDAuMDI3NTE3
XSAyZGZlNCBpcyAyYWM1ODAwMCENClsgIDIwMC4wMjkyNjFdIDJkZmU1IGlzIDJhYzU5MDAw
IQ0KWyAgMjAwLjAzMDk5NV0gMmRmZTYgaXMgMmFjNWEwMDAhDQpbICAyMDAuMDMyODE4XSAy
ZGZlNyBpcyAyYWM0ZTAwMCENClsgIDIwMC4wNDI3OTVdIDJkZmU4IGlzIDJhYzRjMDAwIQ0K
WyAgMjAwLjA0NjM2OV0gMmRmOWIgaXMgMmFjNGIwMDAhDQpbICAyMDAuMDQ4NTUwXSAyZGZl
OSBpcyAyYWM0YTAwMCENClsgIDIwMC4wNTU5NTFdIDJkZmVhIGlzIDJhYzQ5MDAwIQ0KWyAg
MjAwLjA1ODEzOF0gMmRmZWIgaXMgMmFjNDgwMDAhDQpbICAyMDAuMDYwMzM1XSAyZGZlYyBp
cyAyYWM0NzAwMCENClsgIDIwMC4wNjI1NDJdIDJkZmVkIGlzIDJhYzQ2MDAwIQ0KWyAgMjAw
LjA2NDY3NV0gMmRmOWMgaXMgMmFjNDUwMDAhDQpbICAyMDAuMTA1NzYyXSAyZGY5ZCBpcyAy
YWM0NDAwMCENClsgIDIwMC4xMTU0MzVdIDJkZmVlIGlzIDJhYzQzMDAwIQ0KWyAgMjAwLjEx
ODc0Ml0gMmRmZWYgaXMgMmFjNDIwMDAhDQpbICAyMDAuMTI4MDI5XSAyZGZmMCBpcyAyYWM0
MTAwMCENClsgIDIwMC4xNDI3ODZdIDJkZmYxIGlzIDJhYzNmMDAwIQ0KWyAgMjAwLjE0NDU3
NF0gMmRmZjIgaXMgMmFjNDAwMDAhDQpbICAyMDAuMTU0NjI3XSAyZGZmNCBpcyAyYWMzNjAw
MCENClsgIDIwMC4xNTYzNjRdIDJkZjllIGlzIDJhYzM3MDAwIQ0KWyAgMjAwLjE1ODEyNV0g
MmRmOWYgaXMgMmFjMzgwMDAhDQpbICAyMDAuMTU5ODg2XSAyZGZhMCBpcyAyYWMzOTAwMCEN
ClsgIDIwMC4xNjE2NDVdIDJkZmExIGlzIDJhYzNhMDAwIQ0KWyAgMjAwLjE2MzQ0MV0gMmRm
YTIgaXMgMmFjM2IwMDAhDQpbICAyMDAuMTY1MTU3XSAyZGZhMyBpcyAyYWMzYzAwMCENClsg
IDIwMC4xNjcwMjldIDJkZmYzIGlzIDJhYzNkMDAwIQ0KWyAgMjAwLjE2ODg2OV0gMmRmYTQg
aXMgMmFjMzUwMDAhDQpbICAyMDAuMTcxMDA2XSAyZGZmNSBpcyAyYWMzNDAwMCENClsgIDIw
MC4xNzMxNjRdIDJkZmE1IGlzIDJhYzMzMDAwIQ0KWyAgMjAwLjE3NTM0Nl0gMmRmZjYgaXMg
MmFjMzIwMDAhDQpbICAyMDAuMTc3NTA5XSAyZGZmNyBpcyAyYWMzMTAwMCENClsgIDIwMC4x
Nzk3MDJdIDJkZmY4IGlzIDJhYzMwMDAwIQ0KWyAgMjAwLjE4MTk0M10gMmRmZmEgaXMgMmFj
MmYwMDAhDQpbICAyMDAuMTg0MTI1XSAyZGZmYiBpcyAyYWMyZTAwMCENClsgIDIwMC4xODYy
ODhdIDJkZmZjIGlzIDJhYzJkMDAwIQ0KWyAgMjAwLjE4ODQ3M10gMmRmZmQgaXMgMmFjMmMw
MDAhDQpbICAyMDAuMTkwNjM5XSAyZGZmZSBpcyAyYWMyYjAwMCENClsgIDIwMC4xOTI3OTNd
IDJkZmZmIGlzIDJhYzJhMDAwIQ0KWyAgMjAwLjE5OTU5NF0gMmQ4MDAgaXMgMmFjMjkwMDAh
DQpbICAyMDAuMjAxNzgzXSAyZDgwMSBpcyAyYWMyODAwMCENClsgIDIwMC4yMDQyOThdIDJk
ODAyIGlzIDJhYzI2MDAwIQ0KWyAgMjAwLjIxNzU4M10gMmQ4MDMgaXMgMmFjMjUwMDAhDQpb
ICAyMDAuMjE5NzU3XSAyZDgwNCBpcyAyYWMyNDAwMCENClsgIDIwMC4yMjE5ODBdIDJkODA1
IGlzIDJhYzIzMDAwIQ0KWyAgMjAwLjIyNTE1Ml0gMmQ4MDYgaXMgMmFiZjkwMDAhDQpbICAy
MDAuMjI3MzE1XSAyZGZmOSBpcyAyYWJmYTAwMCENClsgIDIwMC4yMjk2MTldIDJkZmE2IGlz
IDJhYmZiMDAwIQ0KWyAgMjAwLjIzMTkzN10gMmQ4MDcgaXMgMmFiZmYwMDAhDQpbICAyMDAu
MjMzNzQyXSAyZGZhNyBpcyAyYWJmZTAwMCENClsgIDIwMC4yMzU0ODhdIDJkZmE4IGlzIDJh
YmZkMDAwIQ0KWyAgMjAwLjIzNzI3OF0gMmRmYTkgaXMgMmFiZmMwMDAhDQpbICAyMDAuMjM5
NDE0XSAyZGZhYSBpcyAyYWMwMDAwMCENClsgIDIwMC4yNDE3MzJdIDJkODA4IGlzIDJhYzIy
MDAwIQ0KWyAgMjAwLjI0MzUyM10gMmRmYWIgaXMgMmFjMDkwMDAhDQpbICAyMDAuMjQ1Mjky
XSAyZGZhYyBpcyAyYWMwMjAwMCENClsgIDIwMC4yNDcxMThdIDJkODBjIGlzIDJhYzAxMDAw
IQ0KWyAgMjAwLjI3MzY2MF0gMmQ4MGQgaXMgMmFjMWIwMDAhDQpbICAyMDAuMjc2MDc5XSAy
ZDgwOSBpcyAyYWMxMzAwMCENClsgIDIwMC4yNzc5NTZdIDJkODBhIGlzIDJhYzE0MDAwIQ0K
WyAgMjAwLjI3OTc2NV0gMmQ4MGIgaXMgMmFjMjAwMDAhDQpbICAyMDAuMjgxNTc4XSAyZDgy
YiBpcyAyYWMyMTAwMCENClsgIDIwMC4yODM3OThdIDJkODJjIGlzIDJhYzEyMDAwIQ0KWyAg
MjAwLjI4OTcxNV0gMmQ4MmQgaXMgMmFjMTEwMDAhDQpbICAyMDAuMzAwMjE5XSAyZDgyZSBp
cyAyYWMxMDAwMCENClsgIDIwMC4zMDI0NDJdIDJkODJmIGlzIDJhYzBlMDAwIQ0KWyAgMjAw
LjMwNTU3N10gMmQ4MzAgaXMgMmFjMTUwMDAhDQpbICAyMDAuMzA3OTU3XSAyZDgzMSBpcyAy
YWMwNDAwMCENClsgIDIwMC4zMDk3OTldIDJkODMyIGlzIDJhYzAzMDAwIQ0KWyAgMjAwLjMx
MTYxNF0gMmQ4MzMgaXMgMmFjMDgwMDAhDQpbICAyMDAuMzEzNDYyXSAyZDgzNCBpcyAyYWMw
YzAwMCENClsgIDIwMC4zMTU2NDFdIDJkODM1IGlzIDJhYzBkMDAwIQ0KWyAgMjAwLjMxNzg3
MV0gMmQ4MzYgaXMgMmFjMTYwMDAhDQpbICAyMDAuMzIwMjU3XSAyZDgwZSBpcyAyYThhYzAw
MCENClsgIDIwMC4zMjIwODRdIDJkODM3IGlzIDJhZDQ0MDAwIQ0KWyAgMjAwLjMyMzkzMF0g
MmQ4MzggaXMgMmFjMGIwMDAhDQpbICAyMDAuMzI1NzY2XSAyZDgzOSBpcyAyYWMwYTAwMCEN
ClsgIDIwMC4zMjgwMDVdIDJkODNiIGlzIDJhYzFjMDAwIQ0KWyAgMjAwLjMzODgxMl0gMmQ4
M2MgaXMgMmFjMDcwMDAhDQpbICAyMDAuMzQwNjkzXSAyZDgzZCBpcyAyOWRiMjAwMCENClsg
IDIwMC4zNDI1MjRdIDJkODNlIGlzIDJhZDM2MDAwIQ0KWyAgMjAwLjM0NDQyNV0gMmQ4M2Yg
aXMgMmEyNTQwMDAhDQpbICAyMDAuMzQ5ODgyXSAyZDg0MCBpcyAyYWQzODAwMCENClsgIDIw
MC4zNTIxNzRdIDJkODQxIGlzIDJhZDM3MDAwIQ0KWyAgMjAwLjM1NDYxMl0gMmQ4NDIgaXMg
MmFjMTcwMDAhDQpbICAyMDAuMzU2NDUyXSAyZDg0MyBpcyAyYWMxODAwMCENClsgIDIwMC4z
NTgyOTNdIDJkODQ0IGlzIDJhYzE5MDAwIQ0KWyAgMjAwLjM2MDEyMl0gMmQ4NDUgaXMgMmFj
MWEwMDAhDQpbICAyMDAuMzYyMzEyXSAyZDg0NiBpcyAyYWJmODAwMCENClsgIDIwMC4zNjQ1
NDVdIDJkODNhIGlzIDJhYmY3MDAwIQ0KWyAgMjAwLjM2Njk0NF0gMmQ4MGYgaXMgMmFiZjMw
MDAhDQpbICAyMDAuMzY4NzU2XSAyZDg0OCBpcyAyYWJmNDAwMCENClsgIDIwMC4zNzA2MDFd
IDJkODQ5IGlzIDJhYmY1MDAwIQ0KWyAgMjAwLjM3MjQwNF0gMmQ4NGEgaXMgMmFiZjYwMDAh
DQpbICAyMDAuMzgyOTA1XSAyZDg0YyBpcyAyYWJmMjAwMCENClsgIDIwMC4zODUxNTFdIDJk
ODRkIGlzIDJhYmYxMDAwIQ0KWyAgMjAwLjM4NzM3OV0gMmQ4NGUgaXMgMmFiZjAwMDAhDQpb
ICAyMDAuMzg5NTkzXSAyZDg0ZiBpcyAyYWJlZjAwMCENClsgIDIwMC4zOTE5NjZdIDJkODRi
IGlzIDJhYmViMDAwIQ0KWyAgMjAwLjM5MzgyMV0gMmQ4NTAgaXMgMmFiZWMwMDAhDQpbICAy
MDAuMzk1NjI3XSAyZDg1MSBpcyAyYWJlZDAwMCENClsgIDIwMC4zOTc0MzNdIDJkODUyIGlz
IDJhYmVlMDAwIQ0KWyAgMjAwLjQwMzk2NF0gMmQ4NTMgaXMgMmFiZWEwMDAhDQpbICAyMDAu
NDA2MjE1XSAyZDg1NCBpcyAyYWJlOTAwMCENClsgIDIwMC40MDg2MTldIDJkODU1IGlzIDJh
YmU1MDAwIQ0KWyAgMjAwLjQxMDQ1Nl0gMmQ4NTYgaXMgMmFiZTYwMDAhDQpbICAyMDAuNDEy
MjIyXSAyZDg1NyBpcyAyYWJlNzAwMCENClsgIDIwMC40MTM5ODhdIDJkODU4IGlzIDJhYmU4
MDAwIQ0KWyAgMjAwLjQxNjU0Ml0gMmQ4NjEgaXMgMmFiZGMwMDAhDQpbICAyMDAuNDE4MzE5
XSAyZDg1OSBpcyAyYWJkZDAwMCENClsgIDIwMC40MjAwOTBdIDJkODVhIGlzIDJhYmRlMDAw
IQ0KWyAgMjAwLjQyMTgzNl0gMmQ4NWIgaXMgMmFiZGYwMDAhDQpbICAyMDAuNDIzNTcyXSAy
ZDg1YyBpcyAyYWJlMDAwMCENClsgIDIwMC40MjUzMDVdIDJkODVkIGlzIDJhYmUxMDAwIQ0K
WyAgMjAwLjQyNzAyMl0gMmQ4NWUgaXMgMmFiZTIwMDAhDQpbICAyMDAuNDI4NzMyXSAyZDg1
ZiBpcyAyYWJlMzAwMCENClsgIDIwMC40MzA0MzFdIDJkODYwIGlzIDJhYmU0MDAwIQ0KWyAg
MjAwLjQzMjY0MF0gMmQ4NjIgaXMgMmFiZDgwMDAhDQpbICAyMDAuNDM0Mzc2XSAyZDg2MyBp
cyAyYWJkOTAwMCENClsgIDIwMC40MzYwNjZdIDJkODY0IGlzIDJhYmRhMDAwIQ0KWyAgMjAw
LjQzNzc4MV0gMmQ4NjUgaXMgMmFiZGIwMDAhDQpbICAyMDAuNDM5ODM1XSAyZDg2NiBpcyAy
YWJkNzAwMCENClsgIDIwMC40NDIwNTVdIDJkODY3IGlzIDJhYmQzMDAwIQ0KWyAgMjAwLjQ0
Mzc4NF0gMmQ4MTAgaXMgMmFiZDQwMDAhDQpbICAyMDAuNDQ1NDY2XSAyZDgxMSBpcyAyYWJk
NTAwMCENClsgIDIwMC40NDcxNTddIDJkODEyIGlzIDJhYmQ2MDAwIQ0KWyAgMjAwLjQ0OTIy
Ml0gMmQ4NjggaXMgMmFiZDIwMDAhDQpbICAyMDAuNDY4NDM5XSAyZDg2OSBpcyAyYWJkMTAw
MCENClsgIDIwMC40NzA1NjNdIDJkODE0IGlzIDJhYmQwMDAwIQ0KWyAgMjAwLjQ3MjcwOF0g
MmQ4MTUgaXMgMmFiY2YwMDAhDQpbICAyMDAuNDc0ODQwXSAyZDg2YSBpcyAyYWJjZTAwMCEN
ClsgIDIwMC40NzY5ODNdIDJkODE2IGlzIDJhYmNkMDAwIQ0KWyAgMjAwLjQ4MTQ3N10gMmQ4
NmIgaXMgMmFiY2MwMDAhDQpbICAyMDAuNDgzNjQwXSAyZDg2YyBpcyAyYWJjYjAwMCENClsg
IDIwMC40ODU3NzJdIDJkODZkIGlzIDJhYmNhMDAwIQ0KWyAgMjAwLjQ4Nzk0OV0gMmQ4NmUg
aXMgMmFiYzkwMDAhDQpbICAyMDAuNDkwMjU1XSAyZDg2ZiBpcyAyYWJjNTAwMCENClsgIDIw
MC40OTIwMjJdIDJkODcwIGlzIDJhYmM2MDAwIQ0KWyAgMjAwLjQ5Mzc3NF0gMmQ4NzEgaXMg
MmFiYzcwMDAhDQpbICAyMDAuNDk1NTMwXSAyZDg3MiBpcyAyYWJjODAwMCENClsgIDIwMC40
OTc2NDldIDJkODc0IGlzIDJhYmM0MDAwIQ0KWyAgMjAwLjUwMzgyNF0gMmQ4NzUgaXMgMmFi
YzMwMDAhDQpbICAyMDAuNTA4NDI5XSAyZDg3NiBpcyAyYWJjMjAwMCENClsgIDIwMC41MTA3
MzRdIDJkODc3IGlzIDJhYmJlMDAwIQ0KWyAgMjAwLjUxMjQ3OF0gMmQ4NzggaXMgMmFiYmYw
MDAhDQpbICAyMDAuNTE0MjExXSAyZDg3OSBpcyAyYWJjMDAwMCENClsgIDIwMC41MTU5Mjdd
IDJkODdhIGlzIDJhYmMxMDAwIQ0KWyAgMjAwLjUxODA2MV0gMmQ4NzMgaXMgMmFiYmQwMDAh
DQpbICAyMDAuNTI1MDc5XSAyZDgxNyBpcyAyYWJiYzAwMCENClsgIDIwMC41MzIwNzBdIDJk
ODdiIGlzIDJhYmJiMDAwIQ0KWyAgMjAwLjUzNTE0M10gMmQ4N2MgaXMgMmFiYmEwMDAhDQpb
ICAyMDAuNTM3MzE4XSAyZDg3ZCBpcyAyYWJiOTAwMCENClsgIDIwMC41Mzk1NDRdIDJkODdl
IGlzIDJhYmI4MDAwIQ0KWyAgMjAwLjU0MTg5Nl0gMmQ4N2YgaXMgMmFiYjQwMDAhDQpbICAy
MDAuNTQzNzAxXSAyZDg4MCBpcyAyYWJiNTAwMCENClsgIDIwMC41NDU0NTFdIDJkODgxIGlz
IDJhYmI2MDAwIQ0KWyAgMjAwLjU0NzIwNV0gMmQ4ODIgaXMgMmFiYjcwMDAhDQpbICAyMDAu
NTQ5NzgzXSAyZDg4MyBpcyAyYWJhOTAwMCENClsgIDIwMC41NTE2MTNdIDJkODg0IGlzIDJh
YmFhMDAwIQ0KWyAgMjAwLjU1MzMzN10gMmQ4ODUgaXMgMmFiYWIwMDAhDQpbICAyMDAuNTU1
MDg4XSAyZDg4NiBpcyAyYWJhYzAwMCENClsgIDIwMC41NTY4MTddIDJkODg3IGlzIDJhYmFk
MDAwIQ0KWyAgMjAwLjU1ODUzMl0gMmQ4ODggaXMgMmFiYWUwMDAhDQpbICAyMDAuNTYwMjQ0
XSAyZDg4OSBpcyAyYWJhZjAwMCENClsgIDIwMC41NjE5NDldIDJkODhhIGlzIDJhYmIwMDAw
IQ0KWyAgMjAwLjU2MzY1NV0gMmQ4OGIgaXMgMmFiYjEwMDAhDQpbICAyMDAuNTY1MzQyXSAy
ZDg4YyBpcyAyYWJiMjAwMCENClsgIDIwMi42OTU0ODFdIDJkYjhkIGlzIDJiMDg3MDAwIQ0K
WyAgMjAyLjY5NzE4OF0gMmRiOGUgaXMgMmIwODgwMDAhDQpbICAyMDIuNzA4OTEyXSAyZGJh
ZSBpcyAyYjA4NDAwMCENClsgIDIwMi43MTY3ODFdIDJkYmFmIGlzIDJiMDgwMDAwIQ0KWyAg
MjAyLjcxODQ3Ml0gMmRiYjAgaXMgMmIwODEwMDAhDQpbICAyMDIuNzIwMTczXSAyZGJiMSBp
cyAyYjA4MjAwMCENClsgIDIwMi43MjE4NjZdIDJkYmIyIGlzIDJiMDgzMDAwIQ0KWyAgMjAy
LjczMjA0Ml0gMmRiOWIgaXMgMmIwNzgwMDAhDQpbICAyMDIuNzMzNzc1XSAyZGI5YyBpcyAy
YjA3OTAwMCENClsgIDIwMi43MzU1MTldIDJkYjlkIGlzIDJiMDdhMDAwIQ0KWyAgMjAyLjcz
NzIzOF0gMmRiOWUgaXMgMmIwN2IwMDAhDQpbICAyMDIuNzM4OTU0XSAyZGI5ZiBpcyAyYjA3
YzAwMCENClsgIDIwMi43NDA2NjZdIDJkYmEwIGlzIDJiMDdkMDAwIQ0KWyAgMjAyLjc0MjM4
OF0gMmRiYTEgaXMgMmIwN2UwMDAhDQpbICAyMDIuNzQ0MTY1XSAyZGJhMiBpcyAyYjA3ZjAw
MCENClsgIDIwMi43NDYxNjZdIDJkYmNlIGlzIDJiMDY5MDAwIQ0KWyAgMjAyLjc0NzkxM10g
MmRiY2YgaXMgMmIwNmEwMDAhDQpbICAyMDIuNzQ5NjE0XSAyZGJkMCBpcyAyYjA2YjAwMCEN
ClsgIDIwMi43NTEzNDFdIDJkYmQxIGlzIDJiMDZjMDAwIQ0KWyAgMjAyLjc1MzA0MV0gMmRi
YTMgaXMgMmIwNmQwMDAhDQpbICAyMDIuNzU0NzcwXSAyZGJhNCBpcyAyYjA2ZTAwMCENClsg
IDIwMi43NTY0NThdIDJkYmE1IGlzIDJiMDZmMDAwIQ0KWyAgMjAyLjc1ODE2NV0gMmRiYTYg
aXMgMmIwNzAwMDAhDQpbICAyMDIuNzU5ODc0XSAyZGJhNyBpcyAyYjA3MTAwMCENClsgIDIw
Mi43NjE1ODZdIDJkYmE4IGlzIDJiMDcyMDAwIQ0KWyAgMjAyLjc2MzI5OF0gMmRiYTkgaXMg
MmIwNzMwMDAhDQpbICAyMDIuNzY1MDE2XSAyZGJhYSBpcyAyYjA3NDAwMCENClsgIDIwMi43
NjY3MzhdIDJkYmFiIGlzIDJiMDc1MDAwIQ0KWyAgMjAyLjc2ODQxOV0gMmRiYWMgaXMgMmIw
NzYwMDAhDQpbICAyMDIuNzcwMTIwXSAyZGJhZCBpcyAyYjA3NzAwMCENClsgIDIwMi43NzE5
MzNdIDJkYmNkIGlzIDJiMDY3MDAwIQ0KWyAgMjAyLjc3NDA5OF0gMmRiZDIgaXMgMmIwNjYw
MDAhDQpbICAyMDIuNzc2MjY4XSAyZGJiMyBpcyAyYjA2NTAwMCENClsgIDIwMi43ODM1MTRd
IDJkYmI0IGlzIDJiMDY0MDAwIQ0KWyAgMjAyLjc4NTY2Ml0gMmRiZDMgaXMgMmIwNjMwMDAh
DQpbICAyMDIuNzkzNzcyXSAyZGJiNSBpcyAyYjA2MjAwMCENClsgIDIwMi44MDEzODRdIDJk
YmQ0IGlzIDJiMDVlMDAwIQ0KWyAgMjAyLjgwMzExN10gMmRiYjYgaXMgMmIwNWYwMDAhDQpb
ICAyMDIuODA0ODc4XSAyZGJiNyBpcyAyYjA2MDAwMCENClsgIDIwMi44MDY1ODldIDJkYmI4
IGlzIDJiMDYxMDAwIQ0KWyAgMjAyLjgwOTA2M10gMmRiZDUgaXMgMmIwNTYwMDAhDQpbICAy
MDIuODEwODIxXSAyZGJkNiBpcyAyYjA1NzAwMCENClsgIDIwMi44MTI1NjRdIDJkYmQ3IGlz
IDJiMDU4MDAwIQ0KWyAgMjAyLjgxNDMxNl0gMmRiZDggaXMgMmIwNTkwMDAhDQpbICAyMDIu
ODE2MDMyXSAyZGJkOSBpcyAyYjA1YTAwMCENClsgIDIwMi44MTc3ODVdIDJkYmRhIGlzIDJi
MDViMDAwIQ0KWyAgMjAyLjgxOTUwMl0gMmRiZGIgaXMgMmIwNWMwMDAhDQpbICAyMDIuODIx
MjUzXSAyZGJkYyBpcyAyYjA1ZDAwMCENClsgIDIwMi44MjMzNThdIDJkYmRkIGlzIDJiMDU1
MDAwIQ0KWyAgMjAyLjgzMjQxNF0gMmRiYjkgaXMgMmIwNTQwMDAhDQpbICAyMDIuODM0NTk2
XSAyZGJiYSBpcyAyYjA1MzAwMCENClsgIDIwMi44MzY5MjZdIDJkYmJiIGlzIDJiMDRmMDAw
IQ0KWyAgMjAyLjgzODY3OF0gMmRiYmMgaXMgMmIwNTAwMDAhDQpbICAyMDIuODQwNDI1XSAy
ZGJiZCBpcyAyYjA1MTAwMCENClsgIDIwMi44NDIxNzFdIDJkYmJlIGlzIDJiMDUyMDAwIQ0K
WyAgMjAyLjg0NDM1Nl0gMmRiYmYgaXMgMmIwNGUwMDAhDQpbICAyMDIuODU0NDMwXSAyZGJj
YiBpcyAyYjA0MjAwMCENClsgIDIwMi44NTYxNzddIDJkYmMwIGlzIDJiMDQzMDAwIQ0KWyAg
MjAyLjg1NzkzM10gMmRiYzEgaXMgMmIwNDQwMDAhDQpbICAyMDIuODU5Njg1XSAyZGJjMiBp
cyAyYjA0NTAwMCENClsgIDIwMi44NjE0MzhdIDJkYmMzIGlzIDJiMDQ2MDAwIQ0KWyAgMjAy
Ljg2MzE5MV0gMmRiYzQgaXMgMmIwNDcwMDAhDQpbICAyMDIuODY0OTQwXSAyZGJjNSBpcyAy
YjA0ODAwMCENClsgIDIwMi44NjY2ODVdIDJkYmM2IGlzIDJiMDQ5MDAwIQ0KWyAgMjAyLjg2
ODQyN10gMmRiYzcgaXMgMmIwNGEwMDAhDQpbICAyMDIuODcwMTY4XSAyZGJjOCBpcyAyYjA0
YjAwMCENClsgIDIwMi44NzE5MDhdIDJkYmM5IGlzIDJiMDRjMDAwIQ0KWyAgMjAyLjg3MzYz
NV0gMmRiY2EgaXMgMmIwNGQwMDAhDQpbICAyMDIuODc1NzI5XSAyZGJjYyBpcyAyYjA0MTAw
MCENClsgIDIwMi44Nzc4NDJdIDJkYmVjIGlzIDJiMDQwMDAwIQ0KWyAgMjAyLjg3OTk2Ml0g
MmRiZWQgaXMgMmIwM2YwMDAhDQpbICAyMDIuODgyMDU3XSAyZGJlZSBpcyAyYjAzZTAwMCEN
ClsgIDIwMi44OTAxNThdIDJkYmVmIGlzIDJiMDNkMDAwIQ0KWyAgMjAyLjg5MjI3NV0gMmRi
ZjAgaXMgMmIwM2MwMDAhDQpbICAyMDIuODk0Mzc5XSAyZGJmMSBpcyAyYjAzYjAwMCENClsg
IDIwMi45MDM2ODBdIDJkYmZkIGlzIDJiMDJmMDAwIQ0KWyAgMjAyLjkwNTM5Ml0gMmRiZjIg
aXMgMmIwMzAwMDAhDQpbICAyMDIuOTA3MTAxXSAyZGJmMyBpcyAyYjAzMTAwMCENClsgIDIw
Mi45MDg4MTZdIDJkYmY0IGlzIDJiMDMyMDAwIQ0KWyAgMjAyLjkxMDUyMV0gMmRiZjUgaXMg
MmIwMzMwMDAhDQpbICAyMDIuOTEyMjMzXSAyZGJmNiBpcyAyYjAzNDAwMCENClsgIDIwMi45
MTM5MzNdIDJkYmY3IGlzIDJiMDM1MDAwIQ0KWyAgMjAyLjkxNTYwNl0gMmRiZjggaXMgMmIw
MzYwMDAhDQpbICAyMDIuOTE3MzEzXSAyZGJmOSBpcyAyYjAzNzAwMCENClsgIDIwMi45MTg5
ODFdIDJkYmZhIGlzIDJiMDM4MDAwIQ0KWyAgMjAyLjkyMDY3M10gMmRiZmIgaXMgMmIwMzkw
MDAhDQpbICAyMDIuOTIyMzQxXSAyZGJmYyBpcyAyYjAzYTAwMCENClsgIDIwMi45MjQzNzld
IDJkYmRlIGlzIDJiMDJlMDAwIQ0KWyAgMjAyLjkyNjQ5MV0gMmRiZGYgaXMgMmIwMmQwMDAh
DQpbICAyMDIuOTI4NzU1XSAyZGJmZSBpcyAyYjAyOTAwMCENClsgIDIwMi45MzA0NjFdIDJk
YmUwIGlzIDJiMDJhMDAwIQ0KWyAgMjAyLjkzMjE0MF0gMmRiZTEgaXMgMmIwMmIwMDAhDQpb
ICAyMDIuOTMzODQ3XSAyZGJlMiBpcyAyYjAyYzAwMCENClsgIDIwMi45MzU5MDFdIDJkYmUz
IGlzIDJiMDI4MDAwIQ0KWyAgMjAyLjkzNzk3Ml0gMmRiZmYgaXMgMmIwMjcwMDAhDQpbICAy
MDIuOTQwMTAyXSAyZGJlNCBpcyAyYjAyNjAwMCENClsgIDIwMi45NDIyMTRdIDJkNDAwIGlz
IDJiMDI1MDAwIQ0KWyAgMjAyLjk0NDI3OV0gMmQ0MDEgaXMgMmIwMjQwMDAhDQpbICAyMDIu
OTQ2NDEwXSAyZGJlNSBpcyAyYjAyMzAwMCENClsgIDIwMi45NDg1MzhdIDJkNDAyIGlzIDJi
MDIyMDAwIQ0KWyAgMjAyLjk1ODcxMl0gMmQ0MDMgaXMgMmIwMWUwMDAhDQpbICAyMDIuOTYw
NDQ3XSAyZDQwNCBpcyAyYjAxZjAwMCENClsgIDIwMi45NjIxNzRdIDJkNDA1IGlzIDJiMDIw
MDAwIQ0KWyAgMjAyLjk2MzkwNl0gMmQ0MDYgaXMgMmIwMjEwMDAhDQpbICAyMDIuOTY2NTMw
XSAyZDQwNyBpcyAyYjAxMzAwMCENClsgIDIwMi45NjgyNjNdIDJkNDA4IGlzIDJiMDE0MDAw
IQ0KWyAgMjAyLjk2OTk5MF0gMmQ0MDkgaXMgMmIwMTUwMDAhDQpbICAyMDIuOTcxODExXSAy
ZDQwYSBpcyAyYjAxNjAwMCENClsgIDIwMi45NzM1MzZdIDJkNDBiIGlzIDJiMDE3MDAwIQ0K
WyAgMjAyLjk3NTI1NV0gMmQ0MGMgaXMgMmIwMTgwMDAhDQpbICAyMDIuOTc2OTc5XSAyZDQw
ZCBpcyAyYjAxOTAwMCENClsgIDIwMi45Nzg2OTNdIDJkNDBlIGlzIDJiMDFhMDAwIQ0KWyAg
MjAyLjk4MDQwNV0gMmQ0MGYgaXMgMmIwMWIwMDAhDQpbICAyMDIuOTgyMTE5XSAyZDQxMCBp
cyAyYjAxYzAwMCENClsgIDIwMi45ODM4NzFdIDJkNDExIGlzIDJiMDFkMDAwIQ0KWyAgMjAy
Ljk4NzMzOV0gMmQ0MjggaXMgMmFmZTcwMDAhDQpbICAyMDIuOTg5MTIwXSAyZDQyOSBpcyAy
YWZlODAwMCENClsgIDIwMi45OTA4ODZdIDJkNDJjIGlzIDJhZmU5MDAwIQ0KWyAgMjAyLjk5
MjY1Nl0gMmQ0MmQgaXMgMmFmZWEwMDAhDQpbICAyMDIuOTk0NDExXSAyZDQyZSBpcyAyYWZl
YjAwMCENClsgIDIwMi45OTYxNzBdIDJkNDJmIGlzIDJhZmVjMDAwIQ0KWyAgMjAyLjk5Nzk0
NV0gMmQ0MzAgaXMgMmFmZWQwMDAhDQpbICAyMDIuOTk5Njk5XSAyZDQzMSBpcyAyYWZlZTAw
MCENClsgIDIwMy4wMDE0MzldIDJkNDMyIGlzIDJhZmVmMDAwIQ0KWyAgMjAzLjAwMzE4N10g
MmQ0MWMgaXMgMmFmZmIwMDAhDQpbICAyMDMuMDA0OTc1XSAyZDQxYiBpcyAyYWZmYzAwMCEN
ClsgIDIwMy4wMDY3NjJdIDJkNDFhIGlzIDJhZmZkMDAwIQ0KWyAgMjAzLjAwODU0MV0gMmQ0
MTkgaXMgMmFmZmUwMDAhDQpbICAyMDMuMDEwMzAzXSAyZDQxOCBpcyAyYWZmZjAwMCENClsg
IDIwMy4wMTIwNjBdIDJkNDE3IGlzIDJiMDAwMDAwIQ0KWyAgMjAzLjAxMzgyM10gMmQ0MTYg
aXMgMmIwMDEwMDAhDQpbICAyMDMuMDE1NTU5XSAyZDQxNSBpcyAyYjAwMjAwMCENClsgIDIw
My4wMTczMjFdIDJkNDE0IGlzIDJiMDAzMDAwIQ0KWyAgMjAzLjAxOTA0NV0gMmQ0MTMgaXMg
MmIwMDQwMDAhDQpbICAyMDMuMDIwNzk1XSAyZDQxMiBpcyAyYjAwNTAwMCENClsgIDIwMy4w
MjI1MTNdIDJkNDFmIGlzIDJhZmYwMDAwIQ0KWyAgMjAzLjAyNDI1OV0gMmQ0MjAgaXMgMmFm
ZjEwMDAhDQpbICAyMDMuMDI2MDExXSAyZDQyMSBpcyAyYWZmMjAwMCENClsgIDIwMy4wMjc3
NjFdIDJkNDIyIGlzIDJhZmYzMDAwIQ0KWyAgMjAzLjAyOTUwM10gMmQ0MjMgaXMgMmFmZjQw
MDAhDQpbICAyMDMuMDMxMjQxXSAyZDQyNCBpcyAyYWZmNTAwMCENClsgIDIwMy4wMzI5ODdd
IDJkNDI1IGlzIDJhZmY2MDAwIQ0KWyAgMjAzLjAzNDczMF0gMmQ0MjYgaXMgMmFmZjcwMDAh
DQpbICAyMDMuMDM2NDYwXSAyZDQyNyBpcyAyYWZmODAwMCENClsgIDIwMy4wMzgyMDhdIDJk
NDFlIGlzIDJhZmY5MDAwIQ0KWyAgMjAzLjAzOTkyN10gMmQ0MWQgaXMgMmFmZmEwMDAhDQpb
ICAyMDMuMDQyMDEyXSAyZDQzZSBpcyAyYWZkMTAwMCENClsgIDIwMy4wNDM3OTVdIDJkNDNm
IGlzIDJhZmQyMDAwIQ0KWyAgMjAzLjA0NTU1Ml0gMmQ0NDAgaXMgMmFmZDMwMDAhDQpbICAy
MDMuMDQ3Mjg4XSAyZDQ0MSBpcyAyYWZkNDAwMCENClsgIDIwMy4wNDkwMzFdIDJkNDQyIGlz
IDJhZmQ1MDAwIQ0KWyAgMjAzLjA1MDc5N10gMmQ0NDMgaXMgMmFmZDYwMDAhDQpbICAyMDMu
MDUyNTM0XSAyZDQ0NCBpcyAyYWZkNzAwMCENClsgIDIwMy4wNTQzMDhdIDJkNDQ1IGlzIDJh
ZmQ4MDAwIQ0KWyAgMjAzLjA1NjAzOF0gMmQ0NDYgaXMgMmFmZDkwMDAhDQpbICAyMDMuMDU3
Nzc3XSAyZDQ0NyBpcyAyYWZkYTAwMCENClsgIDIwMy4wNTk0NzldIDJkNDQ4IGlzIDJhZmRi
MDAwIQ0KWyAgMjAzLjA2MTE4NF0gMmQ0NDkgaXMgMmFmYzcwMDAhDQpbICAyMDMuMDYyOTI1
XSAyZDQ0YSBpcyAyYWZjODAwMCENClsgIDIwMy4wNjQ2NTFdIDJkNDRiIGlzIDJhZmM5MDAw
IQ0KWyAgMjAzLjA2NjM3Nl0gMmQ0NGMgaXMgMmFmY2EwMDAhDQpbICAyMDMuMDY4MDcxXSAy
ZDQ0ZCBpcyAyYWZjYjAwMCENClsgIDIwMy4wNjk3NjVdIDJkNDRlIGlzIDJhZmNjMDAwIQ0K
WyAgMjAzLjA3MTQ2Ml0gMmQ0NGYgaXMgMmFmY2QwMDAhDQpbICAyMDMuMDczMTI5XSAyZDQ1
MCBpcyAyYWZjZTAwMCENClsgIDIwMy4wNzQ4MzJdIDJkNDUxIGlzIDJhZmNmMDAwIQ0KWyAg
MjAzLjA3NjUwNV0gMmQ0NTIgaXMgMmFmZDAwMDAhDQpbICAyMDMuMDc4MTgxXSAyZDQzMyBp
cyAyYWZkYzAwMCENClsgIDIwMy4wNzk4NThdIDJkNDM0IGlzIDJhZmRkMDAwIQ0KWyAgMjAz
LjA4MTUzM10gMmQ0MzUgaXMgMmFmZGUwMDAhDQpbICAyMDMuMDgzMjIyXSAyZDQzNiBpcyAy
YWZkZjAwMCENClsgIDIwMy4wODQ5MTFdIDJkNDM3IGlzIDJhZmUwMDAwIQ0KWyAgMjAzLjA4
NjU4NF0gMmQ0MzggaXMgMmFmZTEwMDAhDQpbICAyMDMuMDg4Mjg3XSAyZDQzOSBpcyAyYWZl
MjAwMCENClsgIDIwMy4wODk5NTVdIDJkNDNhIGlzIDJhZmUzMDAwIQ0KWyAgMjAzLjA5MTY1
N10gMmQ0M2IgaXMgMmFmZTQwMDAhDQpbICAyMDMuMDkzMzI0XSAyZDQzYyBpcyAyYWZlNTAw
MCENClsgIDIwMy4wOTUwNDldIDJkNDNkIGlzIDJhZmU2MDAwIQ0KWyAgMjAzLjA5OTkxN10g
MmQ0NTMgaXMgMmFmYzYwMDAhDQpbICAyMDMuMTAyMDE2XSAyZDQ1NCBpcyAyYWZjNTAwMCEN
ClsgIDIwMy4xMDczODVdIDJkNDU1IGlzIDJhZmM0MDAwIQ0KWyAgMjAzLjEwOTQ5Ml0gMmRi
ZTYgaXMgMmFmYzMwMDAhDQpbICAyMDMuMTExNTc3XSAyZDQ1NiBpcyAyYWZjMjAwMCENClsg
IDIwMy4xMTM2ODRdIDJkNDU3IGlzIDJhZmMxMDAwIQ0KWyAgMjAzLjEyMTk4OV0gMmQ0NTgg
aXMgMmFmYmQwMDAhDQpbICAyMDMuMTIzNzE3XSAyZDQ1OSBpcyAyYWZiZTAwMCENClsgIDIw
My4xMjU0MTddIDJkNDVhIGlzIDJhZmJmMDAwIQ0KWyAgMjAzLjEyNzEwOV0gMmQ0NWIgaXMg
MmFmYzAwMDAhDQpbICAyMDMuMTI5MTk3XSAyZDQ1YyBpcyAyYWZiYzAwMCENClsgIDIwMy4x
MzM2MDddIDJkNDVkIGlzIDJhZmJiMDAwIQ0KWyAgMjAzLjEzNTcxNF0gMmQ0NWUgaXMgMmFm
YmEwMDAhDQpbICAyMDMuMTM3ODM3XSAyZDQ1ZiBpcyAyYWZiOTAwMCENClsgIDIwMy4xMzk5
MzNdIDJkNDYwIGlzIDJhZmI4MDAwIQ0KWyAgMjAzLjE0MjA1OF0gMmQ0NjEgaXMgMmFmYjcw
MDAhDQpbICAyMDMuMTUyMjg0XSAyZDQ2MiBpcyAyYWZiNjAwMCENClsgIDIwMy4xNTQ4NTFd
IDJkNDYzIGlzIDJhZmI1MDAwIQ0KWyAgMjAzLjE1Njk1OV0gMmQ0NjQgaXMgMmFmYjQwMDAh
DQpbICAyMDMuMTY3NTAzXSAyZDQ2NSBpcyAyYWZiMDAwMCENClsgIDIwMy4xNjkyMDFdIDJk
NDY2IGlzIDJhZmIxMDAwIQ0KWyAgMjAzLjE3MDkwNF0gMmQ0NjcgaXMgMmFmYjIwMDAhDQpb
ICAyMDMuMTcyNTY4XSAyZDQ2OCBpcyAyYWZiMzAwMCENClsgIDIwMy4xNzQ2MThdIDJkYmU3
IGlzIDJhZmFmMDAwIQ0KWyAgMjAzLjE3Njk2Ml0gMmRiZTggaXMgMmFmYWIwMDAhDQpbICAy
MDMuMTc4NjQ5XSAyZDQ2OSBpcyAyYWZhYzAwMCENClsgIDIwMy4xODAzNTFdIDJkNDZhIGlz
IDJhZmFkMDAwIQ0KWyAgMjAzLjE4MjAzOF0gMmQ0NmIgaXMgMmFmYWUwMDAhDQpbICAyMDMu
MTg0MTU3XSAyZDQ2ZCBpcyAyYWZhYTAwMCENClsgIDIwMy4xODY1MDhdIDJkNDZlIGlzIDJh
ZmE2MDAwIQ0KWyAgMjAzLjE4ODI4OV0gMmQ0NmYgaXMgMmFmYTcwMDAhDQpbICAyMDMuMTg5
OTc5XSAyZDQ3MCBpcyAyYWZhODAwMCENClsgIDIwMy4xOTE3MDNdIDJkNDcxIGlzIDJhZmE5
MDAwIQ0KWyAgMjAzLjIwMjQ2MF0gMmQ0NzIgaXMgMmFmOWIwMDAhDQpbICAyMDMuMjA0MjAy
XSAyZDQ3MyBpcyAyYWY5YzAwMCENClsgIDIwMy4yMDU5MjhdIDJkNDc0IGlzIDJhZjlkMDAw
IQ0KWyAgMjAzLjIwNzY0MF0gMmQ0NzUgaXMgMmFmOWUwMDAhDQpbICAyMDMuMjA5MzQ2XSAy
ZDQ3NiBpcyAyYWY5ZjAwMCENClsgIDIwMy4yMTEwMzJdIDJkNDc3IGlzIDJhZmEwMDAwIQ0K
WyAgMjAzLjIxMjcyNF0gMmQ0NzggaXMgMmFmYTEwMDAhDQpbICAyMDMuMjE0NDMwXSAyZDQ3
OSBpcyAyYWZhMjAwMCENClsgIDIwMy4yMTYxMjVdIDJkNDdhIGlzIDJhZmEzMDAwIQ0KWyAg
MjAzLjIxNzg0NV0gMmQ0N2IgaXMgMmFmYTQwMDAhDQpbICAyMDMuMjE5NTIzXSAyZDQ3YyBp
cyAyYWZhNTAwMCENClsgIDIwMy4yMjQyNzldIDJkNDdkIGlzIDJhZjkwMDAwIQ0KWyAgMjAz
LjIyNTk2OV0gMmQ0N2UgaXMgMmFmOTEwMDAhDQpbICAyMDMuMjI3NjcxXSAyZDQ3ZiBpcyAy
YWY5MjAwMCENClsgIDIwMy4yMjkzNzBdIDJkNDgwIGlzIDJhZjkzMDAwIQ0KWyAgMjAzLjIz
MTE0OV0gMmQ0ODEgaXMgMmFmOTQwMDAhDQpbICAyMDMuMjMyODQ1XSAyZDQ4MiBpcyAyYWY5
NTAwMCENClsgIDIwMy4yMzQ1MzhdIDJkNDgzIGlzIDJhZjk2MDAwIQ0KWyAgMjAzLjIzNjIx
MV0gMmQ0ODQgaXMgMmFmOTcwMDAhDQpbICAyMDMuMjM3OTIzXSAyZDQ4NSBpcyAyYWY5ODAw
MCENClsgIDIwMy4yMzk2MDNdIDJkNDg2IGlzIDJhZjk5MDAwIQ0KWyAgMjAzLjI0MTMwNl0g
MmQ0ODcgaXMgMmFmOWEwMDAhDQpbICAyMDMuMjQzMDg4XSAyZDQ4OCBpcyAyYWY4ZTAwMCEN
ClsgIDIwMy4yNDQ4MTNdIDJkNDg5IGlzIDJhZjhmMDAwIQ0KWyAgMjAzLjI1MzI0MV0gMmQ0
OGIgaXMgMmFmOGQwMDAhDQpbICAyMDMuMjU5MjM2XSAyZDQ4YSBpcyAyYWY1ZjAwMCENClsg
IDIwMy4yNjEzNTVdIDJkNDhjIGlzIDJhZjYwMDAwIQ0KWyAgMjAzLjI2MzQ4OF0gMmQ0OGQg
aXMgMmFmNjEwMDAhDQpbICAyMDMuMjY1NzA0XSAyZDQ4ZSBpcyAyYWY2NDAwMCENClsgIDIw
My4yNjc0NTJdIDJkNDhmIGlzIDJhZjYzMDAwIQ0KWyAgMjAzLjI2OTE0MV0gMmQ0OTAgaXMg
MmFmNjIwMDAhDQpbICAyMDMuMjcxMDMyXSAyZDQ5MiBpcyAyYWY2YjAwMCENClsgIDIwMy4y
NzI2OTFdIDJkNDkzIGlzIDJhZjZhMDAwIQ0KWyAgMjAzLjI3NDQzMl0gMmQ0OTQgaXMgMmFm
NjkwMDAhDQpbICAyMDMuMjc2MDk0XSAyZDQ5NSBpcyAyYWY2ODAwMCENClsgIDIwMy4yNzc3
NzVdIDJkNDk2IGlzIDJhZjY3MDAwIQ0KWyAgMjAzLjI3OTQ1NV0gMmQ0OTcgaXMgMmFmNjYw
MDAhDQpbICAyMDMuMjgxMTIxXSAyZDQ5OCBpcyAyYWY2NTAwMCENClsgIDIwMy4yODI4OThd
IDJkNDkxIGlzIDJhZjZkMDAwIQ0KWyAgMjAzLjI4NzM5MV0gMmQ0OWEgaXMgMmFmNzQwMDAh
DQpbICAyMDMuMjg5NDg0XSAyZDQ5YiBpcyAyYWY4NzAwMCENClsgIDIwMy4yOTE2MTNdIDJk
NDljIGlzIDJhZjg4MDAwIQ0KWyAgMjAzLjI5MzcyOV0gMmQ0OWQgaXMgMmFmODYwMDAhDQpb
ICAyMDMuMjk1ODI0XSAyZDQ5ZSBpcyAyYWY4NTAwMCENClsgIDIwMy4yOTgwMDBdIDJkNGEw
IGlzIDJhZjhiMDAwIQ0KWyAgMjAzLjMwMDE0MV0gMmQ0YTEgaXMgMmFmOGMwMDAhDQpbICAy
MDMuMzA0NDExXSAyZDRhMiBpcyAyYWY4MTAwMCENClsgIDIwMy4zMTU1NDZdIDJkNGEzIGlz
IDJhZjdhMDAwIQ0KWyAgMjAzLjMxNzMwOV0gMmQ0YTQgaXMgMmFmNzcwMDAhDQpbICAyMDMu
MzE4OTkzXSAyZDRhNSBpcyAyYWY3ODAwMCENClsgIDIwMy4zMjA3MTddIDJkNGE2IGlzIDJh
ZjdiMDAwIQ0KWyAgMjAzLjMyMjc5NV0gMmQ0YTcgaXMgMmFmODQwMDAhDQpbICAyMDMuMzI2
NDg2XSAyZDRhOCBpcyAyYWY2ZTAwMCENClsgIDIwMy4zMjg2MjFdIDJkNDlmIGlzIDJhZjcz
MDAwIQ0KWyAgMjAzLjMzMDgwNF0gMmQ0OTkgaXMgMmFmNzkwMDAhDQpbICAyMDMuMzMyOTU4
XSAyZDQ2YyBpcyAyYWY4YTAwMCENClsgIDIwMy4zNDM0NzBdIDJkNGE5IGlzIDJhZjg5MDAw
IQ0KWyAgMjAzLjM0NTY0M10gMmRiZTkgaXMgMmFmNzUwMDAhDQpbICAyMDMuMzU0NDcxXSAy
ZDRhYSBpcyAyYWY3NjAwMCENClsgIDIwMy4zNTY4NDJdIDJkNGFiIGlzIDJiMTI0MDAwIQ0K
WyAgMjAzLjM1OTA0NV0gMmQ0YWMgaXMgMmFkMmQwMDAhDQpbICAyMDMuMzYxMjQzXSAyZDRh
ZCBpcyAyYTZjOTAwMCENClsgIDIwMy4zNjM1MTBdIDJkYmVhIGlzIDJhYzFmMDAwIQ0KWyAg
MjAzLjM3MDQwN10gMmQ0YWUgaXMgMmIxMGUwMDAhDQpbICAyMDMuMzcyMjQ4XSAyZDRhZiBp
cyAyYWY3MjAwMCENClsgIDIwMy4zNzQxMjhdIDJkNGIwIGlzIDJiMTE4MDAwIQ0KWyAgMjAz
LjM3NTk4OF0gMmQ0YjEgaXMgMmIxMTcwMDAhDQpbICAyMDMuMzc4MjM0XSAyZGJlYiBpcyAy
YWY1ZTAwMCENClsgIDIwMy4zODA1MzFdIDJkNGM3IGlzIDJhZjVkMDAwIQ0KWyAgMjAzLjM4
Mjg4Ml0gMmQ0YzggaXMgMmFmODAwMDAhDQpbICAyMDMuMzkxMjQ1XSAyZDRiMiBpcyAyYWY1
YzAwMCENClsgIDIwMy4zOTMxNzhdIDJkNGM5IGlzIDJhZjdkMDAwIQ0KWyAgMjAzLjM5NTE0
NF0gMmQ0Y2EgaXMgMmFmN2UwMDAhDQpbICAyMDMuMzk3MDc3XSAyZDRjYiBpcyAyYWY3ZjAw
MCENClsgIDIwMy4zOTkzOTVdIDJkNGNjIGlzIDJhZjViMDAwIQ0KWyAgMjAzLjQwMTczM10g
MmQ0YjMgaXMgMmFmNWEwMDAhDQpbICAyMDMuNDA0MTAzXSAyZDRjZCBpcyAyYWY1OTAwMCEN
ClsgIDIwMy40MDY4MDJdIDJkNGNlIGlzIDJhZjU1MDAwIQ0KWyAgMjAzLjQwODc0Nl0gMmQ0
YjQgaXMgMmFmNTYwMDAhDQpbICAyMDMuNDEwNjg2XSAyZDRiNSBpcyAyYWY1NzAwMCENClsg
IDIwMy40MTI2MTddIDJkNGI2IGlzIDJhZjU4MDAwIQ0KWyAgMjAzLjQxNDg3M10gMmQ0Yjcg
aXMgMmFmNTQwMDAhDQpbICAyMDMuNDI0MDIxXSAyZDRjZiBpcyAyYWY1MDAwMCENClsgIDIw
My40MjU5NDFdIDJkNGI4IGlzIDJhZjUxMDAwIQ0KWyAgMjAzLjQyNzg2NF0gMmQ0YjkgaXMg
MmFmNTIwMDAhDQpbICAyMDMuNDI5Nzc0XSAyZDRiYSBpcyAyYWY1MzAwMCENClsgIDIwMy40
NDA1NThdIDJkNGQwIGlzIDJhZjRmMDAwIQ0KWyAgMjAzLjQ0MzAxN10gMmQ0ZDEgaXMgMmFm
NGIwMDAhDQpbICAyMDMuNDQ0OTMzXSAyZDRiYiBpcyAyYWY0YzAwMCENClsgIDIwMy40NDY4
MjFdIDJkNGJjIGlzIDJhZjRkMDAwIQ0KWyAgMjAzLjQ0ODY4MF0gMmQ0YmQgaXMgMmFmNGUw
MDAhDQpbICAyMDMuNDUxNTM0XSAyZDRiZSBpcyAyYWY0MDAwMCENClsgIDIwMy40NTM0NTdd
IDJkNGJmIGlzIDJhZjQxMDAwIQ0KWyAgMjAzLjQ1NTI4MV0gMmQ0YzAgaXMgMmFmNDIwMDAh
DQpbICAyMDMuNDU3MTI2XSAyZDRjMSBpcyAyYWY0MzAwMCENClsgIDIwMy40NTg4OThdIDJk
NGMyIGlzIDJhZjQ0MDAwIQ0KWyAgMjAzLjQ2MDY2OV0gMmQ0YzMgaXMgMmFmNDUwMDAhDQpb
ICAyMDMuNDYyNDI5XSAyZDRjNCBpcyAyYWY0NjAwMCENClsgIDIwMy40NjQxODZdIDJkNGM1
IGlzIDJhZjRbICAyMDUuNjAwMTg5XSAyZDAyMiBpcyAyYjNlYzAwMCENClsgIDIwNS42MDE5
MjBdIDJkMDIzIGlzIDJiM2VkMDAwIQ0KWyAgMjA1LjYwMzY1OV0gMmQwMjQgaXMgMmIzZWUw
MDAhDQpbICAyMDUuNjA1Mzc0XSAyZDAyNSBpcyAyYjNlZjAwMCENClsgIDIwNS42MDc0NTZd
IDJkMDAxIGlzIDJiM2ViMDAwIQ0KWyAgMjA1LjYwOTYzM10gMmQwMDIgaXMgMmIzZWEwMDAh
DQpbICAyMDUuNjExNzUwXSAyZDAyNiBpcyAyYjNlOTAwMCENClsgIDIwNS42MTM5MDFdIDJk
MDI3IGlzIDJiM2U4MDAwIQ0KWyAgMjA1LjYxNTk4OF0gMmQwMjggaXMgMmIzZTcwMDAhDQpb
ICAyMDUuNjE4MTQzXSAyZDAwMyBpcyAyYjNlNjAwMCENClsgIDIwNS42MjAyNzZdIDJkMDI5
IGlzIDJiM2U1MDAwIQ0KWyAgMjA1LjYyMjM2MF0gMmQwMmEgaXMgMmIzZTQwMDAhDQpbICAy
MDUuNjI1OTU1XSAyZDAwNCBpcyAyYjNlMDAwMCENClsgIDIwNS42Mjc2OTJdIDJkMDJiIGlz
IDJiM2UxMDAwIQ0KWyAgMjA1LjYyOTQyOF0gMmQwMmMgaXMgMmIzZTIwMDAhDQpbICAyMDUu
NjMxMTc4XSAyZDAyZCBpcyAyYjNlMzAwMCENClsgIDIwNS42MzMyODVdIDJkMDJlIGlzIDJi
M2RmMDAwIQ0KWyAgMjA1LjYzNTU1M10gMmQwMmYgaXMgMmIzZGIwMDAhDQpbICAyMDUuNjM3
Mjc4XSAyZDAwNSBpcyAyYjNkYzAwMCENClsgIDIwNS42Mzg5NjldIDJkMDA2IGlzIDJiM2Rk
MDAwIQ0KWyAgMjA1LjY0MDY4Ml0gMmQwMDcgaXMgMmIzZGUwMDAhDQpbICAyMDUuNjQzMTQ2
XSAyZDAwOCBpcyAyYjNkMzAwMCENClsgIDIwNS42NDQ4OTFdIDJkMDMwIGlzIDJiM2Q0MDAw
IQ0KWyAgMjA1LjY0NjYxNF0gMmQwMzEgaXMgMmIzZDUwMDAhDQpbICAyMDUuNjQ4MzM1XSAy
ZDAzMiBpcyAyYjNkNjAwMCENClsgIDIwNS42NTAxMDBdIDJkMDMzIGlzIDJiM2Q3MDAwIQ0K
WyAgMjA1LjY1MTgzMl0gMmQwMzQgaXMgMmIzZDgwMDAhDQpbICAyMDUuNjUzNjEwXSAyZDAz
NSBpcyAyYjNkOTAwMCENClsgIDIwNS42NTUzMTldIDJkMDM2IGlzIDJiM2RhMDAwIQ0KWyAg
MjA1LjY1Nzk4MF0gMmQwNDEgaXMgMmIzYjgwMDAhDQpbICAyMDUuNjU5NzI0XSAyZDA0MCBp
cyAyYjNiOTAwMCENClsgIDIwNS42NjE0ODNdIDJkMDNmIGlzIDJiM2JhMDAwIQ0KWyAgMjA1
LjY2MzIxOF0gMmQwM2UgaXMgMmIzYmIwMDAhDQpbICAyMDUuNjY0OTQ5XSAyZDAzZCBpcyAy
YjNiYzAwMCENClsgIDIwNS42NjY2ODVdIDJkMDNjIGlzIDJiM2JkMDAwIQ0KWyAgMjA1LjY2
ODQyMF0gMmQwM2IgaXMgMmIzYmUwMDAhDQpbICAyMDUuNjcwMTU1XSAyZDAzYSBpcyAyYjNi
ZjAwMCENClsgIDIwNS42NzE4NzldIDJkMDM5IGlzIDJiM2MwMDAwIQ0KWyAgMjA1LjY3MzU5
NV0gMmQwMzggaXMgMmIzYzEwMDAhDQpbICAyMDUuNjc1MzEzXSAyZDAzNyBpcyAyYjNjMjAw
MCENClsgIDIwNS42NzcwMzZdIDJkMDQzIGlzIDJiM2MzMDAwIQ0KWyAgMjA1LjY3ODc1OF0g
MmQwNDQgaXMgMmIzYzQwMDAhDQpbICAyMDUuNjgwNDY4XSAyZDA0NSBpcyAyYjNjNTAwMCEN
ClsgIDIwNS42ODIxNjNdIDJkMDQ2IGlzIDJiM2M2MDAwIQ0KWyAgMjA1LjY4Mzg3OF0gMmQw
NDcgaXMgMmIzYzcwMDAhDQpbICAyMDUuNjg2NDEwXSAyZDA1NiBpcyAyYjNhMzAwMCENClsg
IDIwNS42ODgyNTJdIDJkMDU3IGlzIDJiM2E0MDAwIQ0KWyAgMjA1LjY4OTk4NF0gMmQwNTgg
aXMgMmIzYTUwMDAhDQpbICAyMDUuNjkxNzIxXSAyZDA1OSBpcyAyYjNhNjAwMCENClsgIDIw
NS42OTM0NDhdIDJkMDVhIGlzIDJiM2E3MDAwIQ0KWyAgMjA1LjY5NTE0NF0gMmQwNWIgaXMg
MmIzYTgwMDAhDQpbICAyMDUuNjk2ODc5XSAyZDA1YyBpcyAyYjNhOTAwMCENClsgIDIwNS42
OTg1NjNdIDJkMDVkIGlzIDJiM2FhMDAwIQ0KWyAgMjA1LjcwMDI4Ml0gMmQwNWUgaXMgMmIz
YWIwMDAhDQpbICAyMDUuNzAxOTgzXSAyZDA1ZiBpcyAyYjNhYzAwMCENClsgIDIwNS43MDM3
MDBdIDJkMDU1IGlzIDJiMzk4MDAwIQ0KWyAgMjA1LjcwNTM4Ml0gMmQwNTQgaXMgMmIzOTkw
MDAhDQpbICAyMDUuNzA3MDg4XSAyZDA1MyBpcyAyYjM5YTAwMCENClsgIDIwNS43MDg4MTJd
IDJkMDUyIGlzIDJiMzliMDAwIQ0KWyAgMjA1LjcxMDQ5Ml0gMmQwNGYgaXMgMmIzOWMwMDAh
DQpbICAyMDUuNzEyMTg3XSAyZDA0ZSBpcyAyYjM5ZDAwMCENClsgIDIwNS43MTM4NjhdIDJk
MDRkIGlzIDJiMzllMDAwIQ0KWyAgMjA1LjcxNTUzNF0gMmQwNGMgaXMgMmIzOWYwMDAhDQpb
ICAyMDUuNzE3MjIxXSAyZDA0YiBpcyAyYjNhMDAwMCENClsgIDIwNS43MTg4ODJdIDJkMDRh
IGlzIDJiM2ExMDAwIQ0KWyAgMjA1LjcyMDU3M10gMmQwNDkgaXMgMmIzYTIwMDAhDQpbICAy
MDUuNzMxNjc4XSAyZDAxMSBpcyAyYjM3ODAwMCENClsgIDIwNS43MzM1NzhdIDJkMDEwIGlz
IDJiMzc5MDAwIQ0KWyAgMjA1LjczNTI3NF0gMmQwMGYgaXMgMmIzN2EwMDAhDQpbICAyMDUu
NzM2OTkzXSAyZDAwZSBpcyAyYjM3YjAwMCENClsgIDIwNS43Mzg2OTJdIDJkMDBkIGlzIDJi
MzdjMDAwIQ0KWyAgMjA1Ljc0MDM1OF0gMmQwMGMgaXMgMmIzN2QwMDAhDQpbICAyMDUuNzQy
MDI1XSAyZDAwYiBpcyAyYjM3ZTAwMCENClsgIDIwNS43NDM2OTNdIDJkMDBhIGlzIDJiMzdm
MDAwIQ0KWyAgMjA1Ljc0NTM1N10gMmQwMDkgaXMgMmIzODAwMDAhDQpbICAyMDUuNzQ3MDMy
XSAyZDA0OCBpcyAyYjM4MTAwMCENClsgIDIwNS43NDg3MDBdIDJkMDYwIGlzIDJiMzgyMDAw
IQ0KWyAgMjA1Ljc1MDc1MF0gMmQwNjEgaXMgMmIzNjMwMDAhDQpbICAyMDUuNzUyNDY2XSAy
ZDA2MiBpcyAyYjM2NDAwMCENClsgIDIwNS43NTQxNjhdIDJkMDYzIGlzIDJiMzY1MDAwIQ0K
WyAgMjA1Ljc1NTgxOF0gMmQwNjQgaXMgMmIzNjYwMDAhDQpbICAyMDUuNzU3NDc2XSAyZDA2
NSBpcyAyYjM2NzAwMCENClsgIDIwNS43NTkxNDJdIDJkMDY2IGlzIDJiMzY4MDAwIQ0KWyAg
MjA1Ljc2MDgwN10gMmQwNjcgaXMgMmIzNjkwMDAhDQpbICAyMDUuNzYyNDc5XSAyZDA2OCBp
cyAyYjM2YTAwMCENClsgIDIwNS43NjQxMzddIDJkMDY5IGlzIDJiMzZiMDAwIQ0KWyAgMjA1
Ljc2NTc4Nl0gMmQwNmEgaXMgMmIzNmMwMDAhDQpbICAyMDUuNzY3NDYwXSAyZDA2YiBpcyAy
YjM1ODAwMCENClsgIDIwNS43NjkxMTBdIDJkMDZjIGlzIDJiMzU5MDAwIQ0KWyAgMjA1Ljc3
MDc4OV0gMmQwNmQgaXMgMmIzNWEwMDAhDQpbICAyMDUuNzcyNDQ1XSAyZDA2ZSBpcyAyYjM1
YjAwMCENClsgIDIwNS43NzQxMDhdIDJkMDZmIGlzIDJiMzVjMDAwIQ0KWyAgMjA1Ljc3NTc3
NF0gMmQwNzAgaXMgMmIzNWQwMDAhDQpbICAyMDUuNzc3NDQzXSAyZDA5MCBpcyAyYjM1ZTAw
MCENClsgIDIwNS43NzkxMTRdIDJkMDkxIGlzIDJiMzVmMDAwIQ0KWyAgMjA1Ljc4MDc3N10g
MmQwOTIgaXMgMmIzNjAwMDAhDQpbICAyMDUuNzgyNDM5XSAyZDA5MyBpcyAyYjM2MTAwMCEN
ClsgIDIwNS43ODQxMjRdIDJkMDk0IGlzIDJiMzYyMDAwIQ0KWyAgMjA1Ljc4NTc2OF0gMmQw
OTUgaXMgMmIzNGQwMDAhDQpbICAyMDUuNzg3NDU5XSAyZDA5NiBpcyAyYjM0ZTAwMCENClsg
IDIwNS43ODkxMjBdIDJkMDk3IGlzIDJiMzRmMDAwIQ0KWyAgMjA1Ljc5MDc5NV0gMmQwOTgg
aXMgMmIzNTAwMDAhDQpbICAyMDUuNzkyNDkxXSAyZDA5OSBpcyAyYjM1MTAwMCENClsgIDIw
NS43OTQxNzJdIDJkMDlhIGlzIDJiMzUyMDAwIQ0KWyAgMjA1Ljc5NTg1NV0gMmQwOWIgaXMg
MmIzNTMwMDAhDQpbICAyMDUuNzk3NTM1XSAyZDA5YyBpcyAyYjM1NDAwMCENClsgIDIwNS43
OTkyMDVdIDJkMDlkIGlzIDJiMzU1MDAwIQ0KWyAgMjA1LjgwMDg2Ml0gMmQwOWUgaXMgMmIz
NTYwMDAhDQpbICAyMDUuODAyNTEyXSAyZDA5ZiBpcyAyYjM1NzAwMCENClsgIDIwNS44MDQx
ODZdIDJkMGEwIGlzIDJiMzQzMDAwIQ0KWyAgMjA1LjgwNTg0MV0gMmQwYTEgaXMgMmIzNDQw
MDAhDQpbICAyMDUuODA3NTI5XSAyZDBhMiBpcyAyYjM0NTAwMCENClsgIDIwNS44MDkxOTdd
IDJkMGEzIGlzIDJiMzQ2MDAwIQ0KWyAgMjA1LjgxMDg3N10gMmQwYTQgaXMgMmIzNDcwMDAh
DQpbICAyMDUuODEyNTYxXSAyZDBhNSBpcyAyYjM0ODAwMCENClsgIDIwNS44MTQyMzZdIDJk
MGE2IGlzIDJiMzQ5MDAwIQ0KWyAgMjA1LjgxNTkxMV0gMmQwYTcgaXMgMmIzNGEwMDAhDQpb
ICAyMDUuODE3NTg1XSAyZDBhOCBpcyAyYjM0YjAwMCENClsgIDIwNS44MTkyNDddIDJkMGE5
IGlzIDJiMzRjMDAwIQ0KWyAgMjA1LjgyMDkzMV0gMmQwN2IgaXMgMmIzNmQwMDAhDQpbICAy
MDUuODIyNjExXSAyZDA3YSBpcyAyYjM2ZTAwMCENClsgIDIwNS44MjQzMDVdIDJkMDc5IGlz
IDJiMzZmMDAwIQ0KWyAgMjA1LjgyNTk3MV0gMmQwNzggaXMgMmIzNzAwMDAhDQpbICAyMDUu
ODI3NjU3XSAyZDA3NyBpcyAyYjM3MTAwMCENClsgIDIwNS44MjkzNDFdIDJkMDc2IGlzIDJi
MzcyMDAwIQ0KWyAgMjA1LjgzMTAyMV0gMmQwNzUgaXMgMmIzNzMwMDAhDQpbICAyMDUuODMy
NzAzXSAyZDA3NCBpcyAyYjM3NDAwMCENClsgIDIwNS44MzQzNzBdIDJkMDczIGlzIDJiMzc1
MDAwIQ0KWyAgMjA1LjgzNjAyNV0gMmQwNzIgaXMgMmIzNzYwMDAhDQpbICAyMDUuODM3NzEw
XSAyZDA3MSBpcyAyYjM3NzAwMCENClsgIDIwNS44NDEwMDBdIDJkMGMzIGlzIDJiMzIzMDAw
IQ0KWyAgMjA1Ljg0MjcyNl0gMmQwYzQgaXMgMmIzMjQwMDAhDQpbICAyMDUuODQ0NDQyXSAy
ZDBjNSBpcyAyYjMyNTAwMCENClsgIDIwNS44NDYxMjBdIDJkMGM2IGlzIDJiMzI2MDAwIQ0K
WyAgMjA1Ljg0NzgwNV0gMmQwYzcgaXMgMmIzMjcwMDAhDQpbICAyMDUuODQ5NTA0XSAyZDBj
OCBpcyAyYjMyODAwMCENClsgIDIwNS44NTExNzZdIDJkMGM5IGlzIDJiMzI5MDAwIQ0KWyAg
MjA1Ljg1Mjg1OV0gMmQwY2EgaXMgMmIzMmEwMDAhDQpbICAyMDUuODU0NTY0XSAyZDBjYiBp
cyAyYjMyYjAwMCENClsgIDIwNS44NTYyMzFdIDJkMGNjIGlzIDJiMzJjMDAwIQ0KWyAgMjA1
Ljg1NzkzMl0gMmQwYWIgaXMgMmIzMzgwMDAhDQpbICAyMDUuODU5NTk4XSAyZDBhYyBpcyAy
YjMzOTAwMCENClsgIDIwNS44NjEyNzVdIDJkMGFkIGlzIDJiMzNhMDAwIQ0KWyAgMjA1Ljg2
Mjk3M10gMmQwYWUgaXMgMmIzM2IwMDAhDQpbICAyMDUuODY0NjQ5XSAyZDBhZiBpcyAyYjMz
YzAwMCENClsgIDIwNS44NjYzMzNdIDJkMGIyIGlzIDJiMzNkMDAwIQ0KWyAgMjA1Ljg2ODAx
Nl0gMmQwYjMgaXMgMmIzM2UwMDAhDQpbICAyMDUuODY5NzA1XSAyZDBiNCBpcyAyYjMzZjAw
MCENClsgIDIwNS44NzEzOTZdIDJkMGI1IGlzIDJiMzQwMDAwIQ0KWyAgMjA1Ljg3MzA2OV0g
MmQwYjYgaXMgMmIzNDEwMDAhDQpbICAyMDUuODc0NzcyXSAyZDBiNyBpcyAyYjM0MjAwMCEN
ClsgIDIwNS44NzY0MjddIDJkMGI4IGlzIDJiMzJkMDAwIQ0KWyAgMjA1Ljg3ODEwOF0gMmQw
YjkgaXMgMmIzMmUwMDAhDQpbICAyMDUuODc5NzkxXSAyZDBiYSBpcyAyYjMyZjAwMCENClsg
IDIwNS44ODE0NjZdIDJkMGJiIGlzIDJiMzMwMDAwIQ0KWyAgMjA1Ljg4MzE1Nl0gMmQwYmMg
aXMgMmIzMzEwMDAhDQpbICAyMDUuODg0ODM2XSAyZDBiZCBpcyAyYjMzMjAwMCENClsgIDIw
NS44ODY0OThdIDJkMGJlIGlzIDJiMzMzMDAwIQ0KWyAgMjA1Ljg4ODE4OV0gMmQwYmYgaXMg
MmIzMzQwMDAhDQpbICAyMDUuODg5ODUyXSAyZDBjMCBpcyAyYjMzNTAwMCENClsgIDIwNS44
OTE1NDhdIDJkMGMxIGlzIDJiMzM2MDAwIQ0KWyAgMjA1Ljg5MzIyMF0gMmQwYzIgaXMgMmIz
MzcwMDAhDQpbICAyMDUuODk2MTMzXSAyZDBlZCBpcyAyYjJlZDAwMCENClsgIDIwNS44OTc5
MjZdIDJkMGFhIGlzIDJiMmVlMDAwIQ0KWyAgMjA1Ljg5OTY1Nl0gMmQwN2MgaXMgMmIyZWYw
MDAhDQpbICAyMDUuOTAxMzc2XSAyZDA3ZCBpcyAyYjJmMDAwMCENClsgIDIwNS45MDMwODVd
IDJkMDdlIGlzIDJiMmYxMDAwIQ0KWyAgMjA1LjkwNDgzN10gMmQwN2YgaXMgMmIyZjIwMDAh
DQpbICAyMDUuOTA2NTQ1XSAyZDA4MCBpcyAyYjJmMzAwMCENClsgIDIwNS45MDgzMTBdIDJk
MDgxIGlzIDJiMmY0MDAwIQ0KWyAgMjA1LjkxMDA1NF0gMmQwODIgaXMgMmIyZjUwMDAhDQpb
ICAyMDUuOTExNzgwXSAyZDA4MyBpcyAyYjJmNjAwMCENClsgIDIwNS45MTM1MDNdIDJkMDg0
IGlzIDJiMmY3MDAwIQ0KWyAgMjA1LjkxNTIwN10gMmQwZDggaXMgMmIzMGQwMDAhDQpbICAy
MDUuOTE2OTUyXSAyZDBkOSBpcyAyYjMwZTAwMCENClsgIDIwNS45MTg2NjhdIDJkMGRhIGlz
IDJiMzBmMDAwIQ0KWyAgMjA1LjkyMDQxOF0gMmQwZGIgaXMgMmIzMTAwMDAhDQpbICAyMDUu
OTIyMTM2XSAyZDBkYyBpcyAyYjMxMTAwMCENClsgIDIwNS45MjM4NjldIDJkMGRkIGlzIDJi
MzEyMDAwIQ0KWyAgMjA1LjkyNTYwM10gMmQwZGUgaXMgMmIzMTMwMDAhDQpbICAyMDUuOTI3
MzI2XSAyZDBkZiBpcyAyYjMxNDAwMCENClsgIDIwNS45MjkwNTJdIDJkMGUwIGlzIDJiMzE1
MDAwIQ0KWyAgMjA1LjkzMDc3Ml0gMmQwZTEgaXMgMmIzMTYwMDAhDQpbICAyMDUuOTMyNDg5
XSAyZDBlMiBpcyAyYjMxNzAwMCENClsgIDIwNS45MzQyMDRdIDJkMGUzIGlzIDJiMzAzMDAw
IQ0KWyAgMjA1LjkzNTkxMV0gMmQwZTQgaXMgMmIzMDQwMDAhDQpbICAyMDUuOTM3NjQxXSAy
ZDBlNSBpcyAyYjMwNTAwMCENClsgIDIwNS45MzkzMzZdIDJkMGU2IGlzIDJiMzA2MDAwIQ0K
WyAgMjA1Ljk0MTA2N10gMmQwZTcgaXMgMmIzMDcwMDAhDQpbICAyMDUuOTQyNzc1XSAyZDBl
OCBpcyAyYjMwODAwMCENClsgIDIwNS45NDQ0OTddIDJkMGU5IGlzIDJiMzA5MDAwIQ0KWyAg
MjA1Ljk0NjIxNF0gMmQwZWEgaXMgMmIzMGEwMDAhDQpbICAyMDUuOTQ3OTIzXSAyZDBlYiBp
cyAyYjMwYjAwMCENClsgIDIwNS45NDk2MzZdIDJkMGVjIGlzIDJiMzBjMDAwIQ0KWyAgMjA1
Ljk1MTMyOF0gMmQwZDcgaXMgMmIyZjgwMDAhDQpbICAyMDUuOTUzMDI1XSAyZDBkNiBpcyAy
YjJmOTAwMCENClsgIDIwNS45NTQ3NDRdIDJkMGQ1IGlzIDJiMmZhMDAwIQ0KWyAgMjA1Ljk1
NjQyM10gMmQwZDQgaXMgMmIyZmIwMDAhDQpbICAyMDUuOTU4MTMxXSAyZDBkMyBpcyAyYjJm
YzAwMCENClsgIDIwNS45NTk4MTBdIDJkMGQyIGlzIDJiMmZkMDAwIQ0KWyAgMjA1Ljk2MTUx
MF0gMmQwZDEgaXMgMmIyZmUwMDAhDQpbICAyMDUuOTYzMTc4XSAyZDBkMCBpcyAyYjJmZjAw
MCENClsgIDIwNS45NjQ4NTNdIDJkMGNmIGlzIDJiMzAwMDAwIQ0KWyAgMjA1Ljk2NjU0N10g
MmQwY2UgaXMgMmIzMDEwMDAhDQpbICAyMDUuOTY4MjM5XSAyZDBjZCBpcyAyYjMwMjAwMCEN
ClsgIDIwNS45NzE1OTRdIDJkMGY5IGlzIDJiMmMzMDAwIQ0KWyAgMjA1Ljk3MzMzNF0gMmQw
ZmEgaXMgMmIyYzQwMDAhDQpbICAyMDUuOTc1MDY4XSAyZDBmYiBpcyAyYjJjNTAwMCENClsg
IDIwNS45NzY3NzhdIDJkMGZjIGlzIDJiMmM2MDAwIQ0KWyAgMjA1Ljk3ODQ4MV0gMmQwZmQg
aXMgMmIyYzcwMDAhDQpbICAyMDUuOTgwMTc2XSAyZDBmZSBpcyAyYjJjODAwMCENClsgIDIw
NS45ODE4NzZdIDJkMGZmIGlzIDJiMmM5MDAwIQ0KWyAgMjA1Ljk4MzYwMl0gMmQxMDAgaXMg
MmIyY2EwMDAhDQpbICAyMDUuOTg1Mjg2XSAyZDEwMSBpcyAyYjJjYjAwMCENClsgIDIwNS45
ODcwMDJdIDJkMTAyIGlzIDJiMmNjMDAwIQ0KWyAgMjA1Ljk4ODY5MV0gMmQwOGYgaXMgMmIy
ZDgwMDAhDQpbICAyMDUuOTkwNDA1XSAyZDA4ZSBpcyAyYjJkOTAwMCENClsgIDIwNS45OTIx
MTJdIDJkMDhkIGlzIDJiMmRhMDAwIQ0KWyAgMjA1Ljk5MzgyMV0gMmQwOGMgaXMgMmIyZGIw
MDAhDQpbICAyMDUuOTk1NTM0XSAyZDA4YiBpcyAyYjJkYzAwMCENClsgIDIwNS45OTcyMzdd
IDJkMDhhIGlzIDJiMmRkMDAwIQ0KWyAgMjA1Ljk5ODkzNl0gMmQwODkgaXMgMmIyZGUwMDAh
DQpbICAyMDYuMDAwNjI5XSAyZDA4OCBpcyAyYjJkZjAwMCENClsgIDIwNi4wMDIzMjRdIDJk
MDg3IGlzIDJiMmUwMDAwIQ0KWyAgMjA2LjAwNDA1MF0gMmQwODYgaXMgMmIyZTEwMDAhDQpb
ICAyMDYuMDA1NzQ1XSAyZDA4NSBpcyAyYjJlMjAwMCENClsgIDIwNi4wMDc0NDZdIDJkMGVl
IGlzIDJiMmNkMDAwIQ0KWyAgMjA2LjAwOTEzMl0gMmQwZWYgaXMgMmIyY2UwMDAhDQpbICAy
MDYuMDEwODMwXSAyZDBmMCBpcyAyYjJjZjAwMCENClsgIDIwNi4wMTI1MzZdIDJkMGYxIGlz
IDJiMmQwMDAwIQ0KWyAgMjA2LjAxNDIzOV0gMmQwZjIgaXMgMmIyZDEwMDAhDQpbICAyMDYu
MDE1OTQwXSAyZDBmMyBpcyAyYjJkMjAwMCENClsgIDIwNi4wMTc2NDNdIDJkMGY0IGlzIDJi
MmQzMDAwIQ0KWyAgMjA2LjAxOTMyN10gMmQwZjUgaXMgMmIyZDQwMDAhDQpbICAyMDYuMDIx
MDI0XSAyZDBmNiBpcyAyYjJkNTAwMCENClsgIDIwNi4wMjI2OTFdIDJkMGY3IGlzIDJiMmQ2
MDAwIQ0KWyAgMjA2LjAyNDM4OF0gMmQwZjggaXMgMmIyZDcwMDAhDQpbICAyMDYuMDI2OTYw
XSAyZDExMCBpcyAyYjJhZDAwMCENClsgIDIwNi4wMjg2ODJdIDJkMTExIGlzIDJiMmFlMDAw
IQ0KWyAgMjA2LjAzMDM4NF0gMmQxMTIgaXMgMmIyYWYwMDAhDQpbICAyMDYuMDMyMDY5XSAy
ZDExMyBpcyAyYjJiMDAwMCENClsgIDIwNi4wMzM3OTNdIDJkMTE0IGlzIDJiMmIxMDAwIQ0K
WyAgMjA2LjAzNTQ3OF0gMmQxMTUgaXMgMmIyYjIwMDAhDQpbICAyMDYuMDM3MjA4XSAyZDEx
NiBpcyAyYjJiMzAwMCENClsgIDIwNi4wMzkwMDldIDJkMTE3IGlzIDJiMmI0MDAwIQ0KWyAg
MjA2LjA0MDczN10gMmQxMTggaXMgMmIyYjUwMDAhDQpbICAyMDYuMDQyNDE4XSAyZDExOSBp
cyAyYjJiNjAwMCENClsgIDIwNi4wNDQwOTRdIDJkMTFhIGlzIDJiMmI3MDAwIQ0KWyAgMjA2
LjA0NTc3NF0gMmQxMWIgaXMgMmIyYTMwMDAhDQpbICAyMDYuMDQ3NDQwXSAyZDExYyBpcyAy
YjJhNDAwMCENClsgIDIwNi4wNDkxMjddIDJkMTFkIGlzIDJiMmE1MDAwIQ0KWyAgMjA2LjA1
MDc4Nl0gMmQxMWUgaXMgMmIyYTYwMDAhDQpbICAyMDYuMDUyNDQyXSAyZDExZiBpcyAyYjJh
NzAwMCENClsgIDIwNi4wNTQxMzNdIDJkMTIwIGlzIDJiMmE4MDAwIQ0KWyAgMjA2LjA1NTc4
M10gMmQxMjEgaXMgMmIyYTkwMDAhDQpbICAyMDYuMDU3NDU5XSAyZDEyMiBpcyAyYjJhYTAw
MCENClsgIDIwNi4wNTkxMDJdIDJkMTIzIGlzIDJiMmFiMDAwIQ0KWyAgMjA2LjA2MDc2MF0g
MmQxMjQgaXMgMmIyYWMwMDAhDQpbICAyMDYuMDYyNzAxXSAyZDEwZCBpcyAyYjI5ODAwMCEN
ClsgIDIwNi4wNjQ0MDFdIDJkMTBjIGlzIDJiMjk5MDAwIQ0KWyAgMjA2LjA2NjA2Ml0gMmQx
MGIgaXMgMmIyOWEwMDAhDQpbICAyMDYuMDY3NzE3XSAyZDEwYSBpcyAyYjI5YjAwMCENClsg
IDIwNi4wNjkzNzldIDJkMTA5IGlzIDJiMjljMDAwIQ0KWyAgMjA2LjA3MTA1NF0gMmQxMDgg
aXMgMmIyOWQwMDAhDQpbICAyMDYuMDcyNzIzXSAyZDEwNyBpcyAyYjI5ZTAwMCENClsgIDIw
Ni4wNzQ0MTldIDJkMTA2IGlzIDJiMjlmMDAwIQ0KWyAgMjA2LjA3NjA4MV0gMmQxMDUgaXMg
MmIyYTAwMDAhDQpbICAyMDYuMDc3NzU2XSAyZDEwNCBpcyAyYjJhMTAwMCENClsgIDIwNi4w
Nzk0NDJdIDJkMTAzIGlzIDJiMmEyMDAwIQ0KWyAgMjA2LjA4MTEwMV0gMmQxMjUgaXMgMmIy
OGQwMDAhDQpbICAyMDYuMDgyNzkzXSAyZDEyZiBpcyAyYjI4ZTAwMCENClsgIDIwNi4wODQ0
NzldIDJkMTMwIGlzIDJiMjhmMDAwIQ0KWyAgMjA2LjA4NjE0Nl0gMmQxMzEgaXMgMmIyOTAw
MDAhDQpbICAyMDYuMDg3ODQ0XSAyZDEzMiBpcyAyYjI5MTAwMCENClsgIDIwNi4wODk1Mjhd
IDJkMTMzIGlzIDJiMjkyMDAwIQ0KWyAgMjA2LjA5MTIyMF0gMmQxMzQgaXMgMmIyOTMwMDAh
DQpbICAyMDYuMDkyODg3XSAyZDEzNSBpcyAyYjI5NDAwMCENClsgIDIwNi4wOTQ1NzhdIDJk
MTM2IGlzIDJiMjk1MDAwIQ0KWyAgMjA2LjA5NjI0Nl0gMmQxMzcgaXMgMmIyOTYwMDAhDQpb
ICAyMDYuMDk3OTI2XSAyZDEzOCBpcyAyYjI5NzAwMCENClsgIDIwNi4wOTk1OTldIDJkMTM5
IGlzIDJiMjgzMDAwIQ0KWyAgMjA2LjEwMTI3NF0gMmQxM2EgaXMgMmIyOFsgIDIwOC4yMzI0
NzddIDJjODVhIGlzIDJiYjVmMDAwIQ0KWyAgMjA4LjIzNDcyNF0gMmM4NGIgaXMgMmJiNWIw
MDAhDQpbICAyMDguMjM2Mzk3XSAyYzg0YyBpcyAyYmI1YzAwMCENClsgIDIwOC4yMzgwODVd
IDJjODRkIGlzIDJiYjVkMDAwIQ0KWyAgMjA4LjIzOTc0MV0gMmM4NGUgaXMgMmJiNWUwMDAh
DQpbICAyMDguMjQxNzgxXSAyYzg1YyBpcyAyYmI1YTAwMCENClsgIDIwOC4yNDM4ODhdIDJj
ODVkIGlzIDJiYjU5MDAwIQ0KWyAgMjA4LjI0NTk2M10gMmM4NGYgaXMgMmJiNTgwMDAhDQpb
ICAyMDguMjQ4MDgyXSAyYzg1MCBpcyAyYmI1NzAwMCENClsgIDIwOC4yNTIyNTBdIDJjODUx
IGlzIDJiYjU2MDAwIQ0KWyAgMjA4LjI1NDMzOV0gMmM4NTIgaXMgMmJiNTUwMDAhDQpbICAy
MDguMjU2NDE4XSAyYzg1MyBpcyAyYmI1NDAwMCENClsgIDIwOC4yNTg0OTldIDJjODU1IGlz
IDJiYjUzMDAwIQ0KWyAgMjA4LjI2MDU2N10gMmM4NTYgaXMgMmJiNTIwMDAhDQpbICAyMDgu
MjYyNjQ0XSAyYzg3NiBpcyAyYmI1MTAwMCENClsgIDIwOC4yNjQ3MTBdIDJjODc3IGlzIDJi
YjUwMDAwIQ0KWyAgMjA4LjI2NjgxMV0gMmM4NzggaXMgMmJiNGYwMDAhDQpbICAyMDguMjY4
ODYxXSAyYzg3OSBpcyAyYmI0ZTAwMCENClsgIDIwOC4yNzA5NzFdIDJjODdhIGlzIDJiYjRk
MDAwIQ0KWyAgMjA4LjI3MzAyOF0gMmM4N2IgaXMgMmJiNGMwMDAhDQpbICAyMDguMjgwODM0
XSAyYzg3YyBpcyAyYmI0ODAwMCENClsgIDIwOC4yODI0NzJdIDJjODdkIGlzIDJiYjQ5MDAw
IQ0KWyAgMjA4LjI4NDEzNV0gMmM4N2UgaXMgMmJiNGEwMDAhDQpbICAyMDguMjg1NzYxXSAy
Yzg3ZiBpcyAyYmI0YjAwMCENClsgIDIwOC4yODc3NzNdIDJjODVlIGlzIDJiYjQ3MDAwIQ0K
WyAgMjA4LjI4OTgzMV0gMmM4NWYgaXMgMmJiNDYwMDAhDQpbICAyMDguMjkxODU0XSAyYzg4
MCBpcyAyYmI0NTAwMCENClsgIDIwOC4yOTM4OTZdIDJjODYwIGlzIDJiYjQ0MDAwIQ0KWyAg
MjA4LjI5NjU4NF0gMmM4NjEgaXMgMmJiMDQwMDAhDQpbICAyMDguMjk4NjM4XSAyYzg2MiBp
cyAyYmIwNTAwMCENClsgIDIwOC4zMDA3OTVdIDJjODYzIGlzIDJiYjA2MDAwIQ0KWyAgMjA4
LjMwNTc5N10gMmM4ODEgaXMgMmJiMGEwMDAhDQpbICAyMDguMzA3NDkyXSAyYzg4MiBpcyAy
YmIwOTAwMCENClsgIDIwOC4zMDkxMzZdIDJjODgzIGlzIDJiYjA4MDAwIQ0KWyAgMjA4LjMx
MDc4NF0gMmM4ODQgaXMgMmJiMDcwMDAhDQpbICAyMDguMzEzMzA2XSAyYzg4NSBpcyAyYmIx
NTAwMCENClsgIDIwOC4zMTUxOTddIDJjODg2IGlzIDJiYjE0MDAwIQ0KWyAgMjA4LjMxNjg5
NV0gMmM4ODcgaXMgMmJiMTMwMDAhDQpbICAyMDguMzE4NTM2XSAyYzg4OCBpcyAyYmIxMjAw
MCENClsgIDIwOC4zMjAyMDJdIDJjODg5IGlzIDJiYjExMDAwIQ0KWyAgMjA4LjMyMTgzNF0g
MmM4OGEgaXMgMmJiMTAwMDAhDQpbICAyMDguMzIzNDc1XSAyYzg4YiBpcyAyYmIwZjAwMCEN
ClsgIDIwOC4zMjUxMjVdIDJjODhjIGlzIDJiYjBlMDAwIQ0KWyAgMjA4LjMyNjc2NV0gMmM4
OGQgaXMgMmJiMGQwMDAhDQpbICAyMDguMzI4MzkxXSAyYzg4ZSBpcyAyYmIwYzAwMCENClsg
IDIwOC4zMzAwMjhdIDJjODhmIGlzIDJiYjBiMDAwIQ0KWyAgMjA4LjMzMTcxNF0gMmM4OTAg
aXMgMmJiMjAwMDAhDQpbICAyMDguMzMzNDE5XSAyYzg5MSBpcyAyYmIxZjAwMCENClsgIDIw
OC4zMzUwODFdIDJjODkyIGlzIDJiYjFlMDAwIQ0KWyAgMjA4LjMzNjc1N10gMmM4OTMgaXMg
MmJiMWQwMDAhDQpbICAyMDguMzM4NDM0XSAyYzg5NCBpcyAyYmIxYzAwMCENClsgIDIwOC4z
NDAxMDVdIDJjODk1IGlzIDJiYjFiMDAwIQ0KWyAgMjA4LjM0MTc4NF0gMmM4OTYgaXMgMmJi
MWEwMDAhDQpbICAyMDguMzQzNDU1XSAyYzg5NyBpcyAyYmIxOTAwMCENClsgIDIwOC4zNDUx
NDddIDJjODk4IGlzIDJiYjE4MDAwIQ0KWyAgMjA4LjM0NjgxOF0gMmM4OTkgaXMgMmJiMTcw
MDAhDQpbICAyMDguMzQ4NDc5XSAyYzg5YSBpcyAyYmIxNjAwMCENClsgIDIwOC4zNTAyODJd
IDJjODliIGlzIDJiYjNlMDAwIQ0KWyAgMjA4LjM1MTk2Nl0gMmM4OWMgaXMgMmJiMjEwMDAh
DQpbICAyMDguMzU0MDkxXSAyYzg2NSBpcyAyYmIyZjAwMCENClsgIDIwOC4zNTYyMDZdIDJj
ODY2IGlzIDJiYjMwMDAwIQ0KWyAgMjA4LjM2NzE0Ml0gMmM4NjQgaXMgMmJiMmUwMDAhDQpb
ICAyMDguMzY5MjkyXSAyYzg2NyBpcyAyYmIyZDAwMCENClsgIDIwOC4zNzgyMjhdIDJjODll
IGlzIDJiYjM3MDAwIQ0KWyAgMjA4LjM3OTk1OF0gMmM4NjggaXMgMmJiMzUwMDAhDQpbICAy
MDguMzgxNjgzXSAyYzg2OSBpcyAyYmIzNDAwMCENClsgIDIwOC4zODM0MjRdIDJjODZhIGlz
IDJiYjMzMDAwIQ0KWyAgMjA4LjM5MDgxOF0gMmM4NmIgaXMgMmJiM2EwMDAhDQpbICAyMDgu
MzkyOTc1XSAyYzg5ZiBpcyAyYmIzYjAwMCENClsgIDIwOC4zOTUxNTBdIDJjOGEwIGlzIDJi
YjM4MDAwIQ0KWyAgMjA4LjQwOTE2M10gMmM4YTEgaXMgMmJiMjIwMDAhDQpbICAyMDguNDE2
MzUzXSAyYzhhMiBpcyAyYmIzMjAwMCENClsgIDIwOC40MTgxNDZdIDJjOGEzIGlzIDJiYjM5
MDAwIQ0KWyAgMjA4LjQxOTg2Ml0gMmM4YTQgaXMgMmJiM2YwMDAhDQpbICAyMDguNDIxNjI3
XSAyYzhhNSBpcyAyYmI0MzAwMCENClsgIDIwOC40MjQwODRdIDJjOGE2IGlzIDJiYzlkMDAw
IQ0KWyAgMjA4LjQyNTg1M10gMmM4YTcgaXMgMmJiMjcwMDAhDQpbICAyMDguNDI3NjMxXSAy
YzhhOCBpcyAyYmIyOTAwMCENClsgIDIwOC40MjkzOTRdIDJjOGE5IGlzIDJiYjI4MDAwIQ0K
WyAgMjA4LjQzMTE2MF0gMmM4YWEgaXMgMmJjYWEwMDAhDQpbICAyMDguNDMyOTM3XSAyYzhh
YiBpcyAyYmIzYzAwMCENClsgIDIwOC40MzQ3MjldIDJjOGFjIGlzIDJiYjNkMDAwIQ0KWyAg
MjA4LjQzNjU1M10gMmM4YWQgaXMgMmJiMzEwMDAhDQpbICAyMDguNDM4NDc1XSAyYzhhZSBp
cyAyYTI2YjAwMCENClsgIDIwOC40NDk4ODldIDJjODZjIGlzIDJiYjQwMDAwIQ0KWyAgMjA4
LjQ3MDAxOF0gMmM4NmQgaXMgMmFkYTQwMDAhDQpbICAyMDguNDc2OTAwXSAyYzhhZiBpcyAy
YmM5ZjAwMCENClsgIDIwOC40NzkyMTNdIDJjOGIwIGlzIDJiYjAzMDAwIQ0KWyAgMjA4LjQ4
MTU0OV0gMmM4YjEgaXMgMmJiMjYwMDAhDQpbICAyMDguNDg0ODA0XSAyYzhiMiBpcyAyYmIy
NTAwMCENClsgIDIwOC40ODcxMjhdIDJjOGIzIGlzIDJiYjI0MDAwIQ0KWyAgMjA4LjUyOTM5
Ml0gMmM4YjQgaXMgMmJiMjMwMDAhDQpbICAyMDguNTQ2OTg3XSAyYzhiNSBpcyAyYjFjYzAw
MCENClsgIDIwOC41NzAyNDhdIDJjOGI2IGlzIDJiMWNiMDAwIQ0KWyAgMjA4LjU3MzgzNV0g
MmM4YjcgaXMgMmJiMDAwMDAhDQpbICAyMDguNTc2MTgwXSAyYzhiOCBpcyAyYmFmZjAwMCEN
ClsgIDIwOC41Nzg1NTVdIDJjOGI5IGlzIDJiYWZlMDAwIQ0KWyAgMjA4LjU4MDg4OV0gMmM4
YmEgaXMgMmJhZmQwMDAhDQpbICAyMDguNTgzMjM2XSAyYzhiYiBpcyAyYmFmYzAwMCENClsg
IDIwOC41ODYxMDFdIDJjOGJjIGlzIDJiYWYxMDAwIQ0KWyAgMjA4LjU4ODA3OV0gMmM4YmQg
aXMgMmJhZjIwMDAhDQpbICAyMDguNTg5OTY2XSAyYzhiZSBpcyAyYmFmMzAwMCENClsgIDIw
OC41OTE4ODBdIDJjOGJmIGlzIDJiYWY0MDAwIQ0KWyAgMjA4LjU5MzgzMl0gMmM4YzAgaXMg
MmJhZjUwMDAhDQpbICAyMDguNTk1NzI4XSAyYzhjMSBpcyAyYmFmNjAwMCENClsgIDIwOC41
OTc2MjRdIDJjOGMyIGlzIDJiYWY3MDAwIQ0KWyAgMjA4LjU5OTUwMV0gMmM4YzMgaXMgMmJh
ZjgwMDAhDQpbICAyMDguNjAxMzY4XSAyYzhjNCBpcyAyYmFmOTAwMCENClsgIDIwOC42MDMy
MzFdIDJjOGM1IGlzIDJiYWZhMDAwIQ0KWyAgMjA4LjYwNTEwMF0gMmM4YzYgaXMgMmJhZmIw
MDAhDQpbICAyMDguNjA2OTY5XSAyYzhjNyBpcyAyYmFmMDAwMCENClsgIDIwOC42MTA0NDRd
IDJjOGRmIGlzIDJiYWQwMDAwIQ0KWyAgMjA4LjYxMjM0MV0gMmM4ZTAgaXMgMmJhZDEwMDAh
DQpbICAyMDguNjE0MjAxXSAyYzhlMSBpcyAyYmFkMjAwMCENClsgIDIwOC42MTYwNjldIDJj
OGUyIGlzIDJiYWQzMDAwIQ0KWyAgMjA4LjYxNzkwM10gMmM4ZTMgaXMgMmJhZDQwMDAhDQpb
ICAyMDguNjE5NzA2XSAyYzhlNCBpcyAyYmFkNTAwMCENClsgIDIwOC42MjE0NzRdIDJjOGU1
IGlzIDJiYWQ2MDAwIQ0KWyAgMjA4LjYyMzIyMF0gMmM4ZTYgaXMgMmJhZDcwMDAhDQpbICAy
MDguNjI0OTcwXSAyYzhlNyBpcyAyYmFkODAwMCENClsgIDIwOC42MjY2ODddIDJjOGU4IGlz
IDJiYWQ5MDAwIQ0KWyAgMjA4LjYyODQyMF0gMmM4YzggaXMgMmJhZTUwMDAhDQpbICAyMDgu
NjMwMTUzXSAyYzhjOSBpcyAyYmFlNjAwMCENClsgIDIwOC42MzE4NTBdIDJjOGNhIGlzIDJi
YWU3MDAwIQ0KWyAgMjA4LjYzMzU1Ml0gMmM4Y2IgaXMgMmJhZTgwMDAhDQpbICAyMDguNjM1
MjEzXSAyYzhjYyBpcyAyYmFlOTAwMCENClsgIDIwOC42MzY4OTNdIDJjOGNkIGlzIDJiYWVh
MDAwIQ0KWyAgMjA4LjYzODUyNV0gMmM4Y2UgaXMgMmJhZWIwMDAhDQpbICAyMDguNjQwMTcx
XSAyYzhjZiBpcyAyYmFlYzAwMCENClsgIDIwOC42NDE4MjBdIDJjOGQwIGlzIDJiYWVkMDAw
IQ0KWyAgMjA4LjY0MzQ3Ml0gMmM4ZDEgaXMgMmJhZWUwMDAhDQpbICAyMDguNjQ1MTI2XSAy
YzhkMiBpcyAyYmFlZjAwMCENClsgIDIwOC42NDY3NzddIDJjOGQzIGlzIDJiYWRhMDAwIQ0K
WyAgMjA4LjY0ODQyMF0gMmM4ZDQgaXMgMmJhZGIwMDAhDQpbICAyMDguNjUwMDg5XSAyYzhk
NSBpcyAyYmFkYzAwMCENClsgIDIwOC42NTE3MzNdIDJjOGQ2IGlzIDJiYWRkMDAwIQ0KWyAg
MjA4LjY1MzQwOF0gMmM4ZDcgaXMgMmJhZGUwMDAhDQpbICAyMDguNjU1MDU3XSAyYzhkOCBp
cyAyYmFkZjAwMCENClsgIDIwOC42NTY3MjFdIDJjOGQ5IGlzIDJiYWUwMDAwIQ0KWyAgMjA4
LjY1ODM4MF0gMmM4ZGEgaXMgMmJhZTEwMDAhDQpbICAyMDguNjYwMDIzXSAyYzhkYiBpcyAy
YmFlMjAwMCENClsgIDIwOC42NjE3MDNdIDJjOGRjIGlzIDJiYWUzMDAwIQ0KWyAgMjA4LjY2
MzM0OF0gMmM4ZGQgaXMgMmJhZTQwMDAhDQpbICAyMDguNjY1MzA0XSAyYzhmNiBpcyAyYmFi
OTAwMCENClsgIDIwOC42NjcwMTVdIDJjOGY3IGlzIDJiYWJhMDAwIQ0KWyAgMjA4LjY2ODY3
M10gMmM4ZjggaXMgMmJhYmIwMDAhDQpbICAyMDguNjcwMzc2XSAyYzhmOSBpcyAyYmFiYzAw
MCENClsgIDIwOC42NzIwNDFdIDJjOGZhIGlzIDJiYWJkMDAwIQ0KWyAgMjA4LjY3MzcyMl0g
MmM4ZmIgaXMgMmJhYmUwMDAhDQpbICAyMDguNjc1Mzg5XSAyYzhmYyBpcyAyYmFiZjAwMCEN
ClsgIDIwOC42NzcwNTRdIDJjOGZkIGlzIDJiYWMwMDAwIQ0KWyAgMjA4LjY3ODc0Nl0gMmM4
ZmUgaXMgMmJhYzEwMDAhDQpbICAyMDguNjgwNDI0XSAyYzhmZiBpcyAyYmFjMjAwMCENClsg
IDIwOC42ODIxMjRdIDJjOTAwIGlzIDJiYWMzMDAwIQ0KWyAgMjA4LjY4Mzc5NV0gMmM5MDEg
aXMgMmJhYjgwMDAhDQpbICAyMDguNjg1NDcwXSAyYzhkZSBpcyAyYmFiNzAwMCENClsgIDIw
OC42ODcxOTVdIDJjOGU5IGlzIDJiYWM0MDAwIQ0KWyAgMjA4LjY4ODkxMl0gMmM4ZWEgaXMg
MmJhYzUwMDAhDQpbICAyMDguNjkwNjM3XSAyYzhlYiBpcyAyYmFjNjAwMCENClsgIDIwOC42
OTIzMzldIDJjOGVjIGlzIDJiYWM3MDAwIQ0KWyAgMjA4LjY5NDA0M10gMmM4ZWQgaXMgMmJh
YzgwMDAhDQpbICAyMDguNjk1NzQ1XSAyYzhlZSBpcyAyYmFjOTAwMCENClsgIDIwOC42OTc0
NDFdIDJjOGVmIGlzIDJiYWNhMDAwIQ0KWyAgMjA4LjY5OTEyOV0gMmM4ZjAgaXMgMmJhY2Iw
MDAhDQpbICAyMDguNzAwODE2XSAyYzhmMSBpcyAyYmFjYzAwMCENClsgIDIwOC43MDI1MDFd
IDJjOGY0IGlzIDJiYWNkMDAwIQ0KWyAgMjA4LjcwNDIwOV0gMmM4ZjUgaXMgMmJhY2UwMDAh
DQpbICAyMDguNzM0MzY3XSAyYzkwMiBpcyAyYmFiMzAwMCENClsgIDIwOC43MzYwNzddIDJj
OTAzIGlzIDJiYWI0MDAwIQ0KWyAgMjA4LjczNzgwNF0gMmM5MDQgaXMgMmJhYjUwMDAhDQpb
ICAyMDguNzM5NDg1XSAyYzkwNSBpcyAyYmFiNjAwMCENClsgIDIwOC43NDIwNDNdIDJjOTEz
IGlzIDJiYWFhMDAwIQ0KWyAgMjA4Ljc0MzgzNV0gMmM4NmUgaXMgMmJhYWIwMDAhDQpbICAy
MDguNzQ1NTYyXSAyYzg2ZiBpcyAyYmFhYzAwMCENClsgIDIwOC43NDczMDJdIDJjODcwIGlz
IDJiYWFkMDAwIQ0KWyAgMjA4Ljc0OTAyNV0gMmM4NzEgaXMgMmJhYWUwMDAhDQpbICAyMDgu
NzUwNzQ5XSAyYzg3MiBpcyAyYmFhZjAwMCENClsgIDIwOC43NTI0NThdIDJjODczIGlzIDJi
YWIwMDAwIQ0KWyAgMjA4Ljc1NDIxMF0gMmM4NzQgaXMgMmJhYjEwMDAhDQpbICAyMDguNzU1
OTI3XSAyYzg3NSBpcyAyYmFiMjAwMCENClsgIDIwOC43NzM1MjFdIDJjOTE0IGlzIDJiYWE5
MDAwIQ0KWyAgMjA4Ljc3OTc1OV0gMmM5MTUgaXMgMmJhYTgwMDAhDQpbICAyMDguNzgxOTE1
XSAyYzkwNiBpcyAyYmFhNzAwMCENClsgIDIwOC43ODQ3MDJdIDJjOTA3IGlzIDJiYWE2MDAw
IQ0KWyAgMjA4Ljc4Njg5MF0gMmM5MDggaXMgMmJhYTUwMDAhDQpbICAyMDguODA1NDIzXSAy
YzkwOSBpcyAyYmFhNDAwMCENClsgIDIwOC44MTY1NDhdIDJjOTE2IGlzIDJiYWEzMDAwIQ0K
WyAgMjA4LjgxODcyOF0gMmM5MGEgaXMgMmJhYTIwMDAhDQpbICAyMDguODI3NTk1XSAyYzkw
YiBpcyAyYmFhMTAwMCENClsgIDIwOC44NDUwMzhdIDJjOTBjIGlzIDJiYWEwMDAwIQ0KWyAg
MjA4Ljg1NDE4OV0gMmM5MGQgaXMgMmJhOWYwMDAhDQpbICAyMDguODU2NTI1XSAyYzkxNyBp
cyAyYmE5ZTAwMCENClsgIDIwOC44NjgyMzNdIDJjOTE4IGlzIDJiYTlkMDAwIQ0KWyAgMjA4
Ljg4MjY5M10gMmM5MGUgaXMgMmJhOWMwMDAhDQpbICAyMDguODg0OTAyXSAyYzkwZiBpcyAy
YmE5YjAwMCENClsgIDIwOC44OTg5NjJdIDJjOTEwIGlzIDJiYTlhMDAwIQ0KWyAgMjA4Ljkw
MTE2OF0gMmM5MTkgaXMgMmJhOTkwMDAhDQpbICAyMDguOTAzNzg0XSAyYzkxMSBpcyAyYmE5
NzAwMCENClsgIDIwOC45MTgyNTVdIDJjOTEyIGlzIDJiYTk2MDAwIQ0KWyAgMjA4LjkyMDQ3
M10gMmM5MzIgaXMgMmJhOTUwMDAhDQpbICAyMDguOTIyNjgwXSAyYzkzMyBpcyAyYmE5NDAw
MCENClsgIDIwOC45MzAwMDhdIDJjOTM0IGlzIDJiYTkzMDAwIQ0KWyAgMjA4LjkzMjIzN10g
MmM5MzUgaXMgMmJhOTIwMDAhDQpbICAyMDguOTM0NDE4XSAyYzkzNiBpcyAyYmE5MTAwMCEN
ClsgIDIwOC45MzY2MDFdIDJjOTM3IGlzIDJiYTkwMDAwIQ0KWyAgMjA4LjkzODgwM10gMmM5
MzggaXMgMmJhOGYwMDAhDQpbICAyMDguOTQxMDA0XSAyYzkzOSBpcyAyYmE4ZTAwMCENClsg
IDIwOC45NDMxODVdIDJjOTNhIGlzIDJiYThkMDAwIQ0KWyAgMjA4Ljk0NzQyNl0gMmM5M2Ig
aXMgMmJhOGMwMDAhDQpbICAyMDguOTQ5NjE4XSAyYzkzYyBpcyAyYmE4YjAwMCENClsgIDIw
OC45NTE4MTFdIDJjOTNkIGlzIDJiYThhMDAwIQ0KWyAgMjA4Ljk1Mzk5OF0gMmM5M2UgaXMg
MmJhODkwMDAhDQpbICAyMDguOTU2MTUxXSAyYzkzZiBpcyAyYmE4ODAwMCENClsgIDIwOC45
NTgzNDRdIDJjOTQwIGlzIDJiYTg3MDAwIQ0KWyAgMjA4Ljk2MDUxOF0gMmM5NDEgaXMgMmJh
ODYwMDAhDQpbICAyMDguOTYyNjc0XSAyYzk0MiBpcyAyYmE4NTAwMCENClsgIDIwOC45NjQ4
NTBdIDJjOTQzIGlzIDJiYTg0MDAwIQ0KWyAgMjA4Ljk2NzAxM10gMmM5NDQgaXMgMmJhODMw
MDAhDQpbICAyMDguOTY5MTQ2XSAyYzk0NSBpcyAyYmE4MjAwMCENClsgIDIwOC45NzEyODld
IDJjOTQ2IGlzIDJiYTgxMDAwIQ0KWyAgMjA4Ljk3MzQ0NF0gMmM5MWEgaXMgMmJhODAwMDAh
DQpbICAyMDguOTc1NTUyXSAyYzk0NyBpcyAyYmE3ZjAwMCENClsgIDIwOC45Nzc3MzVdIDJj
OTQ4IGlzIDJiYTdlMDAwIQ0KWyAgMjA4Ljk4MzI1OF0gMmM5NDkgaXMgMmJhN2EwMDAhDQpb
ICAyMDguOTg1MDAyXSAyYzk0YSBpcyAyYmE3YjAwMCENClsgIDIwOC45ODY3MjRdIDJjOTRi
IGlzIDJiYTdjMDAwIQ0KWyAgMjA4Ljk4ODQxMF0gMmM5NGMgaXMgMmJhN2QwMDAhDQpbICAy
MDguOTkwNDY1XSAyYzkxYiBpcyAyYmE3OTAwMCENClsgIDIwOC45OTI1ODldIDJjOTFjIGlz
IDJiYTc4MDAwIQ0KWyAgMjA4Ljk5NDY3MF0gMmM5NGQgaXMgMmJhNzcwMDAhDQpbICAyMDku
MDA1NzAwXSAyYzkxZCBpcyAyYmE3MzAwMCENClsgIDIwOS4wMDc0NjFdIDJjOTRlIGlzIDJi
YTc0MDAwIQ0KWyAgMjA5LjAwOTE2Nl0gMmM5NGYgaXMgMmJhNzUwMDAhDQpbICAyMDkuMDEw
ODk1XSAyYzk1MCBpcyAyYmE3NjAwMCENClsgIDIwOS4wMjcxMTJdIDJjOTUxIGlzIDJiYTY4
MDAwIQ0KWyAgMjA5LjAyODkwMF0gMmM5NTIgaXMgMmJhNjkwMDAhDQpbICAyMDkuMDMwNjM1
XSAyYzk1MyBpcyAyYmE2YTAwMCENClsgIDIwOS4wMzIzNjddIDJjOTU0IGlzIDJiYTZiMDAw
IQ0KWyAgMjA5LjAzNDEwNl0gMmM5NTUgaXMgMmJhNmMwMDAhDQpbICAyMDkuMDM1ODM2XSAy
Yzk1NiBpcyAyYmE2ZDAwMCENClsgIDIwOS4wMzc1NjddIDJjOTU3IGlzIDJiYTZlMDAwIQ0K
WyAgMjA5LjAzOTI3N10gMmM5NTggaXMgMmJhNmYwMDAhDQpbICAyMDkuMDQxMDE3XSAyYzk1
OSBpcyAyYmE3MDAwMCENClsgIDIwOS4wNDI3MjhdIDJjOTVhIGlzIDJiYTcxMDAwIQ0KWyAg
MjA5LjA0NDQ3NF0gMmM5NWIgaXMgMmJhNzIwMDAhDQpbICAyMDkuMDQ2NDM0XSAyYzk2MyBp
cyAyYmE1YzAwMCENClsgIDIwOS4wNDgxODRdIDJjOTY0IGlzIDJiYTVkMDAwIQ0KWyAgMjA5
LjA0OTg4OF0gMmM5NjUgaXMgMmJhNWUwMDAhDQpbICAyMDkuMDUxNTk3XSAyYzk2NiBpcyAy
YmE1ZjAwMCENClsgIDIwOS4wNTMzMTVdIDJjOTY3IGlzIDJiYTYwMDAwIQ0KWyAgMjA5LjA1
NTA1M10gMmM5NjggaXMgMmJhNjEwMDAhDQpbICAyMDkuMDU2Nzg5XSAyYzk1ZSBpcyAyYmE2
MzAwMCENClsgIDIwOS4wNTg1MDldIDJjOTVmIGlzIDJiYTY0MDAwIQ0KWyAgMjA5LjA2MDIx
MV0gMmM5NjAgaXMgMmJhNjUwMDAhDQpbICAyMDkuMDYxOTIzXSAyYzk2MSBpcyAyYmE2NjAw
MCENClsgIDIwOS4wNjM2MjJdIDJjOTYyIGlzIDJiYTY3MDAwIQ0KWyAgMjA5LjA2NTQzM10g
MmM5NWQgaXMgMmJhNWIwMDAhDQpbICAyMDkuMDc1MTE3XSAyYzk2OSBpcyAyYmE1YTAwMCEN
ClsgIDIwOS4wNzc0MDhdIDJjOTZhIGlzIDJiYTU2MDAwIQ0KWyAgMjA5LjA3OTExMV0gMmM5
MWUgaXMgMmJhNTcwMDAhDQpbICAyMDkuMDgwODM5XSAyYzkxZiBpcyAyYmE1ODAwMCENClsg
IDIwOS4wODI1NjZdIDJjOTIwIGlzIDJiYTU5MDAwIQ0KWyAgMjA5LjA4NTAzM10gMmM5MjIg
aXMgMmJhNGUwMDAhDQpbICAyMDkuMDg2ODU5XSAyYzkyMyBpcyAyYmE0ZjAwMCENClsgIDIw
OS4wODg1NzJdIDJjOTI0IGlzIDJiYTUwMDAwIQ0KWyAgMjA5LjA5MDMwOF0gMmM5MjUgaXMg
MmJhNTEwMDAhDQpbICAyMDkuMDkxOTkwXSAyYzkyNiBpcyAyYmE1MjAwMCENClsgIDIwOS4w
OTM3NDhdIDJjOTI3IGlzIDJiYTUzMDAwIQ0KWyAgMjA5LjA5NTQ0MF0gMmM5MjggaXMgMmJh
NTQwMDAhDQpbICAyMDkuMDk3MTMwXSAyYzkyOSBpcyAyYmE1NTAwMCENClsgIDIwOS4wOTg5
NzldIDJjOTczIGlzIDJiYTNlMDAwIQ0KWyAgMjA5LjEwMDY5NF0gMmM5NzQgaXMgMmJhM2Yw
MDAhDQpbICAyMDkuMTAyNDAyXSAyYzk3NSBpcyAyYmE0MDAwMCENClsgIDIwOS4xMDQxMjdd
IDJjOTc2IGlzIDJiYTQxMDAwIQ0KWyAgMjA5LjEwNTgyNl0gMmM5NzcgaXMgMmJhNDIwMDAh
DQpbICAyMDkuMTA3NTUyXSAyYzkyYSBpcyAyYmE0MzAwMCENClsgIDIwOS4xMDkyNTJdIDJj
OTJiIGlzIDJiYTQ0MDAwIQ0KWyAgMjA5LjExMDk3NF0gMmM5MmMgaXMgMmJhNDUwMDAhDQpb
ICAyMDkuMTEyNjczXSAyYzkyZCBpcyAyYmE0NjAwMCENClsgIDIwOS4xMTQzOTFdIDJjOTJl
IGlzIDJiYTQ3MDAwIQ0KWyAgMjA5LjExNjEwMF0gMmM5MmYgaXMgMmJhNDgwMDAhDQpbICAy
MDkuMTE3ODA2XSAyYzkzMCBpcyAyYmE0OTAwMCENClsgIDIwOS4xMTk1MDldIDJjOTMxIGlz
IDJiYTRhMDAwIQ0KWyAgMjA5LjEyMTIwM10gMmM5NzAgaXMgMmJhNGIwMDAhDQpbICAyMDku
MTIyODkwXSAyYzk3MSBpcyAyYmE0YzAwMCENClsgIDIwOS4xMjQ2MDFdIDJjOTcyIGlzIDJi
YTRkMDAwIQ0KWyAgMjA5LjEyNjY2MF0gMmM5NzggaXMgMmJhM2QwMDAhDQpbICAyMDkuMTI4
OTQ5XSAyYzk3OSBpcyAyYmEzOTAwMCENClsgIDIwOS4xMzA2OTZdIDJjOTIxIGlzIDJiYTNh
MDAwIQ0KWyAgMjA5LjEzMjQwMV0gMmM5NmIgaXMgMmJhM2IwMDAhDQpbICAyMDkuMTM0MTEy
XSAyYzk2YyBpcyAyYmEzYzAwMCENClsgIDIwOS4xNjg5OTddIDJjOTZkIGlzIDJiYTJlMDAw
IQ0KWyAgMjA5LjE3MDc2MV0gMmM5NmUgaXMgMmJhMmYwMDAhDQpbICAyMDkuMTcyNDQ3XSAy
Yzk2ZiBpcyAyYmEzMDAwMCENClsgIDIwOS4xNzQxNjFdIDJjOThmIGlzIDJiYTMxMDAwIQ0K
WyAgMjA5LjE3NTgzN10gMmM5OTAgaXMgMmJhMzIwMDAhDQpbICAyMDkuMTc3NTQ5XSAyYzk5
MSBpcyAyYmEzMzAwMCENClsgIDIwOS4xNzkyNjVdIDJjOTkyIGlzIDJiYTM0MDAwIQ0KWyAg
MjA5LjE4MDk2MV0gMmM5OTMgaXMgMmJhMzUwMDAhDQpbICAyMDkuMTgyNjQ4XSAyYzk5NCBp
cyAyYmEzNjAwMCENClsgIDIwOS4xODQzNDhdIDJjOTk1IGlzIDJiYTM3MDAwIQ0KWyAgMjA5
LjE4NjAzNF0gMmM5OTYgaXMgMmJhMzgwMDAhDQpbICAyMDkuMTg3OTQxXSAyYzlhMiBpcyAy
YmEyMTAwMCENClsgIDIwOS4xODk2MzFdIDJjOWEzIGlzIDJiYTIyMDAwIQ0KWyAgMjA5LjE5
MTMyOF0gMmM5OTggaXMgMmJhMjQwMDAhDQpbICAyMDkuMTkyOTk2XSAyYzk5OSBpcyAyYmEy
NTAwMCENClsgIDIwOS4xOTQ3MDZdIDJjOTlhIGlzIDJiYTI2MDAwIQ0KWyAgMjA5LjE5NjM2
N10gMmM5OWIgaXMgMmJhMjcwMDAhDQpbICAyMDkuMTk4MDYzXSAyYzk5YyBpcyAyYmEyODAw
MCENClsgIDIwOS4xOTk3MzNdIDJjOTlkIGlzIDJiYTI5MDAwIQ0KWyAgMjA5LjIwMTQwNF0g
MmM5OWUgaXMgMmJhMmEwMDAhDQpbICAyMDkuMjAzMDkzXSAyYzk5ZiBpcyAyYmEyYjAwMCEN
ClsgIDIwOS4yMDQ3NzddIDJjOWEwIGlzIDJiYTJjMDAwIQ0KWyAgMjA5LjIwNjQ3MF0gMmM5
YTEgaXMgMmJhMmQwMDAhDQpbICAyMDkuMjA4MjY2XSAyYzk5NyBpcyAyYmEyMDAwMCENClsg
IDIwOS4yMTA2MDRdIDJjOWE0IGlzIDJiYTFjMDAwIQ0KWyAgMjA5LjIxMjMxNl0gMmM5YTUg
aXMgMmJhMWQwMDAhDQpbICAyMDkuMjE0MDQzXSAyYzlhNiBpcyAyYmExZTAwMCENClsgIDIw
OS4yMTU3NzBdIDJjOWE3IGlzIDJiYTFmMDAwIQ0KWyAgMjA5LjIyNDMwOV0gMmM5N2EgaXMg
MmJhMTQwMDAhDQpbICAyMDkuMjI2MDM3XSAyYzk3YiBpcyAyYmExNTAwMCENClsgIDIwOS4y
Mjc3OTldIDJjOTdjIGlzIDJiYTE2MDAwIQ0KWyAgMjA5LjIyOTU1Ml0gMmM5N2QgaXMgMmJh
MTcwMDAhDQpbICAyMDkuMjMxMzM4XSAyYzk3ZSBpcyAyYmExODAwMCENClsgIDIwOS4yMzMw
MTldIDJjOTdmIGlzIDJiYTE5MDAwIQ0KWyAgMjA5LjIzNDcxMF0gMmM5ODAgaXMgMmJhMWEw
MDAhDQpbICAyMDkuMjM2Mzk2XSAyYzk4MSBpcyAyYmExYjAwMCENClsgIDIwOS4yNDEwODNd
IDJjOThjIGlzIDJiOWY5MDAwIQ0KWyAgMjA5LjI0Mjg1MV0gMmM5OGIgaXMgMmI5ZmEwMDAh
DQpbICAyMDkuMjQ0NTgzXSAyYzk4YSBpcyAyYjlmYjAwMCENClsgIDIwOS4yNDYyNjVdIDJj
OTg5IGlzIDJiOWZjMDAwIQ0KWyAgMjA5LjI0Nzk4MV0gMmM5ODggaXMgMmI5ZmQwMDAhDQpb
ICAyMDkuMjQ5NzI2XSAyYzk4NyBpcyAyYjlmZTAwMCENClsgIDIwOS4yNTE0MzNdIDJjOTg2
IGlzIDJiOWZmMDAwIQ0KWyAgMjA5LjI1MzEzM10gMmM5ODUgaXMgMmJhMDAwMDAhDQpbICAy
MDkuMjU0ODM4XSAyYzk4NCBpcyAyYmEwMTAwMCENClsgIDIwOS4yNTY2MThdIDJjOTgzIGlz
IDJiYTAyMDAwWyAgMjExLjQwNjk0N10gMmM0MjcgaXMgMmJmMmUwMDAhDQpbICAyMTEuNDA4
NjYyXSAyYzQyOCBpcyAyYmYzMDAwMCENClsgIDIxMS40MTAzNTldIDJjNDI5IGlzIDJiZjJm
MDAwIQ0KWyAgMjExLjQxMjA5MF0gMmM0MmEgaXMgMmJmMTgwMDAhDQpbICAyMTEuNDEzNzkz
XSAyYzQyYiBpcyAyYmYxMTAwMCENClsgIDIxMS40MTU0ODRdIDJjNDJjIGlzIDJiZjEwMDAw
IQ0KWyAgMjExLjQxNzE3Ml0gMmM0MmQgaXMgMmJmMGYwMDAhDQpbICAyMTEuNDE4ODUzXSAy
YzQyZSBpcyAyYmYwZTAwMCENClsgIDIxMS40MjA1NjVdIDJjNDJmIGlzIDJiZjBkMDAwIQ0K
WyAgMjExLjQyMjI1Ml0gMmM0MzAgaXMgMmJmMGMwMDAhDQpbICAyMTEuNDIzOTgwXSAyYzQz
MSBpcyAyYmYwYjAwMCENClsgIDIxMS40MjU4MjldIDJjNDNkIGlzIDJiZjFjMDAwIQ0KWyAg
MjExLjQyNzU2MF0gMmM0M2UgaXMgMmJmMzIwMDAhDQpbICAyMTEuNDI5Mzk5XSAyYzQzMiBp
cyAyYmYxZDAwMCENClsgIDIxMS40MzExMjddIDJjNDMzIGlzIDJiZjEyMDAwIQ0KWyAgMjEx
LjQzMjg0NF0gMmM0MzQgaXMgMmJmMmMwMDAhDQpbICAyMTEuNDM0NTYxXSAyYzQzNSBpcyAy
YmYxZTAwMCENClsgIDIxMS40MzYyODNdIDJjNDM2IGlzIDJiZjFiMDAwIQ0KWyAgMjExLjQz
ODAwNF0gMmM0MzcgaXMgMmJmMTcwMDAhDQpbICAyMTEuNDM5NzExXSAyYzQzOCBpcyAyYmYx
ZjAwMCENClsgIDIxMS40NDE0NTBdIDJjNDM5IGlzIDJiZjIxMDAwIQ0KWyAgMjExLjQ0MzE2
M10gMmM0M2EgaXMgMmJmMjIwMDAhDQpbICAyMTEuNDQ0OTQ0XSAyYzQzYiBpcyAyYmYyNzAw
MCENClsgIDIxMS40NDY2NjNdIDJjNDNjIGlzIDJiZjJkMDAwIQ0KWyAgMjExLjQ0OTUzNF0g
MmM0ODEgaXMgMmJlZWEwMDAhDQpbICAyMTEuNDUxMzA5XSAyYzQ4MiBpcyAyYmVlYjAwMCEN
ClsgIDIxMS40NTMxMjddIDJjNDgzIGlzIDJiZWVjMDAwIQ0KWyAgMjExLjQ1NDg5Ml0gMmM0
ODQgaXMgMmJlZWQwMDAhDQpbICAyMTEuNDU2Njc4XSAyYzQ4NSBpcyAyYmVlZTAwMCENClsg
IDIxMS40NTg0NTddIDJjNDg2IGlzIDJiZWVmMDAwIQ0KWyAgMjExLjQ2MDIyMl0gMmM0ODcg
aXMgMmJlZjAwMDAhDQpbICAyMTEuNDYxOTkyXSAyYzQ4OCBpcyAyYmVmMTAwMCENClsgIDIx
MS40NjM3NzVdIDJjNDg5IGlzIDJiZWYyMDAwIQ0KWyAgMjExLjQ2NTUxN10gMmM0OGEgaXMg
MmJlZjMwMDAhDQpbICAyMTEuNDY3MjQ0XSAyYzQ4YiBpcyAyYmVmNDAwMCENClsgIDIxMS40
Njg5NTJdIDJjNDhjIGlzIDJiZWRmMDAwIQ0KWyAgMjExLjQ3MDcwNV0gMmM0OGQgaXMgMmJl
ZTAwMDAhDQpbICAyMTEuNDcyNDM1XSAyYzQ4ZSBpcyAyYmVlMTAwMCENClsgIDIxMS40NzQx
ODRdIDJjNDhmIGlzIDJiZWUyMDAwIQ0KWyAgMjExLjQ3NTkwM10gMmM0OTAgaXMgMmJlZTMw
MDAhDQpbICAyMTEuNDc3NjU0XSAyYzQ5MSBpcyAyYmVlNDAwMCENClsgIDIxMS40NzkzNjdd
IDJjNDkyIGlzIDJiZWU1MDAwIQ0KWyAgMjExLjQ4MTA5NF0gMmM0OTMgaXMgMmJlZTYwMDAh
DQpbICAyMTEuNDgyODIzXSAyYzQ5NCBpcyAyYmVlNzAwMCENClsgIDIxMS40ODQ1NDRdIDJj
NDk1IGlzIDJiZWU4MDAwIQ0KWyAgMjExLjQ4NjI2MV0gMmM0OTYgaXMgMmJlZTkwMDAhDQpb
ICAyMTEuNDg3OTcxXSAyYzQ5NyBpcyAyYmVkNjAwMCENClsgIDIxMS40ODk2NjJdIDJjNDk4
IGlzIDJiZWQ3MDAwIQ0KWyAgMjExLjQ5MTM3N10gMmM0OTkgaXMgMmJlZDgwMDAhDQpbICAy
MTEuNDkzMDY3XSAyYzQ5YSBpcyAyYmVkOTAwMCENClsgIDIxMS40OTQ3ODFdIDJjNDliIGlz
IDJiZWRhMDAwIQ0KWyAgMjExLjQ5NjQ2NV0gMmM0OWUgaXMgMmJlZGIwMDAhDQpbICAyMTEu
NDk4MTUxXSAyYzQ5ZiBpcyAyYmVkYzAwMCENClsgIDIxMS40OTk4NDBdIDJjNGEwIGlzIDJi
ZWRkMDAwIQ0KWyAgMjExLjUwMTUzM10gMmM0YTEgaXMgMmJlZGUwMDAhDQpbICAyMTEuNTAz
NjA4XSAyYzQ2YiBpcyAyYmYwMDAwMCENClsgIDIxMS41MDUzMTJdIDJjNDZjIGlzIDJiZjAx
MDAwIQ0KWyAgMjExLjUwNzAzOV0gMmM0NmQgaXMgMmJmMDIwMDAhDQpbICAyMTEuNTA4NzM3
XSAyYzQ2ZSBpcyAyYmYwMzAwMCENClsgIDIxMS41MTA0NjVdIDJjNDZmIGlzIDJiZjA0MDAw
IQ0KWyAgMjExLjUxMjE3N10gMmM0NzAgaXMgMmJmMjMwMDAhDQpbICAyMTEuNTEzODk1XSAy
YzQ3MSBpcyAyYmYyNDAwMCENClsgIDIxMS41MTU2MDhdIDJjNDcyIGlzIDJiZjI1MDAwIQ0K
WyAgMjExLjUxNzMyMV0gMmM0NzMgaXMgMmJmMjYwMDAhDQpbICAyMTEuNTE5MDIzXSAyYzQ3
NCBpcyAyYmZlNTAwMCENClsgIDIxMS41MjA3NjddIDJjNDc1IGlzIDJiZmU2MDAwIQ0KWyAg
MjExLjUyMjQ3NV0gMmM0NzYgaXMgMmJlZjUwMDAhDQpbICAyMTEuNTI0MjE0XSAyYzQ3NyBp
cyAyYmVmNjAwMCENClsgIDIxMS41MjU5MTZdIDJjNDc4IGlzIDJiZWY3MDAwIQ0KWyAgMjEx
LjUyNzY0M10gMmM0NzkgaXMgMmJlZjgwMDAhDQpbICAyMTEuNTI5MzYyXSAyYzQ3YSBpcyAy
YmVmOTAwMCENClsgIDIxMS41MzEwNjBdIDJjNDdiIGlzIDJiZWZhMDAwIQ0KWyAgMjExLjUz
Mjc2MF0gMmM0N2MgaXMgMmJlZmIwMDAhDQpbICAyMTEuNTM0NDQ4XSAyYzQ3ZCBpcyAyYmVm
YzAwMCENClsgIDIxMS41MzYxMjldIDJjNDdlIGlzIDJiZWZkMDAwIQ0KWyAgMjExLjUzNzgx
Ml0gMmM0N2YgaXMgMmJlZmUwMDAhDQpbICAyMTEuNTM5NDc5XSAyYzQ4MCBpcyAyYmVmZjAw
MCENClsgIDIxMS41NDExODNdIDJjNDYwIGlzIDJiOTk3MDAwIQ0KWyAgMjExLjU0Mjg3Ml0g
MmM0NjEgaXMgMmJmMTYwMDAhDQpbICAyMTEuNTQ0NjA1XSAyYzQ2MiBpcyAyYjFkZDAwMCEN
ClsgIDIxMS41NDYzMTRdIDJjNDYzIGlzIDJiZmU0MDAwIQ0KWyAgMjExLjU0ODA1M10gMmM0
NjQgaXMgMmJjYjUwMDAhDQpbICAyMTEuNTQ5ODA3XSAyYzQ2NSBpcyAyYmYyOTAwMCENClsg
IDIxMS41NTE1NzBdIDJjNDY2IGlzIDJiZjI4MDAwIQ0KWyAgMjExLjU1MzMzOV0gMmM0Njcg
aXMgMmJmZjAwMDAhDQpbICAyMTEuNTU1MTA2XSAyYzQ2OCBpcyAyYmYxYTAwMCENClsgIDIx
MS41NTY4ODRdIDJjNDY5IGlzIDJiZjE5MDAwIQ0KWyAgMjExLjU1ODYxNF0gMmM0NmEgaXMg
MmJmMzEwMDAhDQpbICAyMTEuNTYwNzQ0XSAyYzRhMiBpcyAyYmVkNTAwMCENClsgIDIxMS41
NzIzNzVdIDJjNGEzIGlzIDJiZWQ0MDAwIQ0KWyAgMjExLjU4NTEwOF0gMmM0YTQgaXMgMmJl
ZDMwMDAhDQpbICAyMTEuNTg3MzU5XSAyYzRhNSBpcyAyYmVkMjAwMCENClsgIDIxMS41ODk1
NjFdIDJjNDVmIGlzIDJiZWQxMDAwIQ0KWyAgMjExLjU5MTc2Ml0gMmM0NWUgaXMgMmJlZDAw
MDAhDQpbICAyMTEuNTk0MDIwXSAyYzQ1MSBpcyAyYmVjZjAwMCENClsgIDIxMS41OTYyMjVd
IDJjNDUyIGlzIDJiZWNlMDAwIQ0KWyAgMjExLjU5ODQxMl0gMmM0NTMgaXMgMmJlY2QwMDAh
DQpbICAyMTEuNjAwNjM4XSAyYzRhNiBpcyAyYmVjYzAwMCENClsgIDIxMS42MDI4NDNdIDJj
NDU0IGlzIDJiZWNiMDAwIQ0KWyAgMjExLjYwNTA4OV0gMmM0NTUgaXMgMmJlY2EwMDAhDQpb
ICAyMTEuNjU1ODAwXSAyYzRjMCBpcyAyYmViZTAwMCENClsgIDIxMS42NTc3MDNdIDJjNDU2
IGlzIDJiZWJmMDAwIQ0KWyAgMjExLjY1OTQ4NF0gMmM0NTcgaXMgMmJlYzAwMDAhDQpbICAy
MTEuNjYxMzEzXSAyYzQ1OCBpcyAyYmVjMTAwMCENClsgIDIxMS42NjMxMTVdIDJjNDU5IGlz
IDJiZWMyMDAwIQ0KWyAgMjExLjY2NDk0NV0gMmM0NWEgaXMgMmJlYzMwMDAhDQpbICAyMTEu
NjY2NzU1XSAyYzQ1YiBpcyAyYmVjNDAwMCENClsgIDIxMS42Njg1NDBdIDJjNDVjIGlzIDJi
ZWM1MDAwIQ0KWyAgMjExLjY3MDM1Nl0gMmM0NWQgaXMgMmJlYzYwMDAhDQpbICAyMTEuNjcy
MTI1XSAyYzRiZCBpcyAyYmVjNzAwMCENClsgIDIxMS42NzM5MTZdIDJjNGJlIGlzIDJiZWM4
MDAwIQ0KWyAgMjExLjY3NTY2MV0gMmM0YmYgaXMgMmJlYzkwMDAhDQpbICAyMTEuNjc4Mjcy
XSAyYzRjMSBpcyAyYmViMzAwMCENClsgIDIxMS42ODAxODNdIDJjNGE3IGlzIDJiZWI0MDAw
IQ0KWyAgMjExLjY4MTkzN10gMmM0YTggaXMgMmJlYjUwMDAhDQpbICAyMTEuNjgzNjg1XSAy
YzRhOSBpcyAyYmViNjAwMCENClsgIDIxMS42ODU0MDddIDJjNGFhIGlzIDJiZWI3MDAwIQ0K
WyAgMjExLjY4NzE2M10gMmM0YWIgaXMgMmJlYjgwMDAhDQpbICAyMTEuNjg4ODg2XSAyYzRh
YyBpcyAyYmViOTAwMCENClsgIDIxMS42OTA2MjldIDJjNGFkIGlzIDJiZWJhMDAwIQ0KWyAg
MjExLjY5MjMzMV0gMmM0YWUgaXMgMmJlYmIwMDAhDQpbICAyMTEuNjk0MDU1XSAyYzRhZiBp
cyAyYmViYzAwMCENClsgIDIxMS42OTU3NDRdIDJjNGIwIGlzIDJiZWJkMDAwIQ0KWyAgMjEx
LjY5NzY0OF0gMmM0YjIgaXMgMmJlYTkwMDAhDQpbICAyMTEuNjk5MzkyXSAyYzRiMyBpcyAy
YmVhYTAwMCENClsgIDIxMS43MDExMDJdIDJjNGI0IGlzIDJiZWFiMDAwIQ0KWyAgMjExLjcw
MjgwOV0gMmM0YjUgaXMgMmJlYWMwMDAhDQpbICAyMTEuNzA0NTE2XSAyYzRiNiBpcyAyYmVh
ZDAwMCENClsgIDIxMS43MDYyMDZdIDJjNGI3IGlzIDJiZWFlMDAwIQ0KWyAgMjExLjcwNzkw
Ml0gMmM0YjggaXMgMmJlYWYwMDAhDQpbICAyMTEuNzA5NTU5XSAyYzRiOSBpcyAyYmViMDAw
MCENClsgIDIxMS43MTEyNTFdIDJjNGJhIGlzIDJiZWIxMDAwIQ0KWyAgMjExLjcxMjkwMV0g
MmM0YmIgaXMgMmJlYjIwMDAhDQpbICAyMTEuNzE0NTU4XSAyYzRiYyBpcyAyYmVhNjAwMCEN
ClsgIDIxMS43MTYyMTddIDJjNGRjIGlzIDJiZWE3MDAwIQ0KWyAgMjExLjcxNzk1OF0gMmM0
YjEgaXMgMmJlYTUwMDAhDQpbICAyMTEuNzIwMDg3XSAyYzRkZSBpcyAyYmVhNDAwMCENClsg
IDIxMS43MzAwMTNdIDJjNGRkIGlzIDJiZWEwMDAwIQ0KWyAgMjExLjczMTc1MV0gMmM0YzIg
aXMgMmJlYTEwMDAhDQpbICAyMTEuNzMzNDQ4XSAyYzRjMyBpcyAyYmVhMjAwMCENClsgIDIx
MS43MzUxMTVdIDJjNGM0IGlzIDJiZWEzMDAwIQ0KWyAgMjExLjc0NTQ4Nl0gMmM0ZGYgaXMg
MmJlOTgwMDAhDQpbICAyMTEuNzQ3MTk4XSAyYzRlMCBpcyAyYmU5OTAwMCENClsgIDIxMS43
NDg5MDddIDJjNGUxIGlzIDJiZTlhMDAwIQ0KWyAgMjExLjc1MDYwN10gMmM0ZTIgaXMgMmJl
OWIwMDAhDQpbICAyMTEuNzUyMjgxXSAyYzRlMyBpcyAyYmU5YzAwMCENClsgIDIxMS43NTM5
NTldIDJjNGU0IGlzIDJiZTlkMDAwIQ0KWyAgMjExLjc1NTYxN10gMmM0ZTUgaXMgMmJlOWUw
MDAhDQpbICAyMTEuNzU3MzExXSAyYzRlNiBpcyAyYmU5ZjAwMCENClsgIDIxMS43NTkzNDRd
IDJjNGU3IGlzIDJiZTk3MDAwIQ0KWyAgMjExLjc2MTQyN10gMmM0YzUgaXMgMmJlOTYwMDAh
DQpbICAyMTEuNzYzNTUzXSAyYzRlOCBpcyAyYmU5NTAwMCENClsgIDIxMS43NjU2NjhdIDJj
NGM2IGlzIDJiZTk0MDAwIQ0KWyAgMjExLjc2Nzc0Ml0gMmM0YzcgaXMgMmJlOTMwMDAhDQpb
ICAyMTEuODAwNjI3XSAyYzRlOSBpcyAyYmU4ODAwMCENClsgIDIxMS44MDIzNzRdIDJjNGM4
IGlzIDJiZTg5MDAwIQ0KWyAgMjExLjgwNDA4OF0gMmM0YzkgaXMgMmJlOGEwMDAhDQpbICAy
MTEuODA1NzY5XSAyYzRjYSBpcyAyYmU4YjAwMCENClsgIDIxMS44MDc0OTZdIDJjNGNiIGlz
IDJiZThjMDAwIQ0KWyAgMjExLjgwOTE4NV0gMmM0Y2MgaXMgMmJlOGQwMDAhDQpbICAyMTEu
ODEwOTEzXSAyYzRjZCBpcyAyYmU4ZTAwMCENClsgIDIxMS44MTI2MjBdIDJjNGNlIGlzIDJi
ZThmMDAwIQ0KWyAgMjExLjgxNDMzN10gMmM0Y2YgaXMgMmJlOTAwMDAhDQpbICAyMTEuODE2
MDU4XSAyYzRkMCBpcyAyYmU5MTAwMCENClsgIDIxMS44MTc3OTJdIDJjNGQxIGlzIDJiZTky
MDAwIQ0KWyAgMjExLjgxOTYzMV0gMmM0ZDIgaXMgMmJlODYwMDAhDQpbICAyMTEuODM5NzM2
XSAyYzRkMyBpcyAyYmU4NTAwMCENClsgIDIxMS44NTM1NDddIDJjNGVhIGlzIDJiZTg0MDAw
IQ0KWyAgMjExLjg1ODI4MV0gMmM0ZDUgaXMgMmJlODMwMDAhDQpbICAyMTEuODY1OTAxXSAy
YzRkNCBpcyAyYmU4MTAwMCENClsgIDIxMS44NzU2OTNdIDJjNGQ2IGlzIDJiZTdkMDAwIQ0K
WyAgMjExLjg3NzQ5NV0gMmM0ZDcgaXMgMmJlN2UwMDAhDQpbICAyMTEuODc5MjA2XSAyYzRk
OCBpcyAyYmU3ZjAwMCENClsgIDIxMS44ODA5MzBdIDJjNGQ5IGlzIDJiZTgwMDAwIQ0KWyAg
MjExLjkxMTA5OF0gMmM0ZGEgaXMgMmJlNzIwMDAhDQpbICAyMTEuOTEyODIzXSAyYzRkYiBp
cyAyYmU3MzAwMCENClsgIDIxMS45MTQ1ODhdIDJjNGZiIGlzIDJiZTc0MDAwIQ0KWyAgMjEx
LjkxNjMxNV0gMmM0ZmMgaXMgMmJlNzUwMDAhDQpbICAyMTEuOTE4MTc0XSAyYzRmZCBpcyAy
YmU3NjAwMCENClsgIDIxMS45MTk5MjBdIDJjNGZlIGlzIDJiZTc3MDAwIQ0KWyAgMjExLjky
MTY3NF0gMmM0ZmYgaXMgMmJlNzgwMDAhDQpbICAyMTEuOTIzNDYxXSAyYzUwMCBpcyAyYmU3
OTAwMCENClsgIDIxMS45MjUyMDZdIDJjNTAxIGlzIDJiZTdhMDAwIQ0KWyAgMjExLjkyNjk3
OF0gMmM1MDIgaXMgMmJlN2IwMDAhDQpbICAyMTEuOTI4NzE0XSAyYzUwMyBpcyAyYmU3YzAw
MCENClsgIDIxMS45NDAwNDldIDJjNTA0IGlzIDJiZTcwMDAwIQ0KWyAgMjExLjk0MjMzNl0g
MmM1MDUgaXMgMmJlNmMwMDAhDQpbICAyMTEuOTQ0MDkzXSAyYzRlYiBpcyAyYmU2ZDAwMCEN
ClsgIDIxMS45NDU4MThdIDJjNGVjIGlzIDJiZTZlMDAwIQ0KWyAgMjExLjk0NzU2MV0gMmM0
ZWQgaXMgMmJlNmYwMDAhDQpbICAyMTEuOTQ5Njk2XSAyYzRlZSBpcyAyYmU2YjAwMCENClsg
IDIxMS45NjgyNDhdIDJjNTA2IGlzIDJiZTZhMDAwIQ0KWyAgMjExLjk4MDM3NF0gMmM0ZWYg
aXMgMmJlNjkwMDAhDQpbICAyMTEuOTg4MzM0XSAyYzRmMCBpcyAyYmU2ODAwMCENClsgIDIx
MS45OTA1NDJdIDJjNGYxIGlzIDJiZTY3MDAwIQ0KWyAgMjExLjk5MjcxN10gMmM1MDcgaXMg
MmJlNjYwMDAhDQpbICAyMTEuOTk0OTI1XSAyYzUwOCBpcyAyYmU2NTAwMCENClsgIDIxMS45
OTcxMjldIDJjNTA5IGlzIDJiZTY0MDAwIQ0KWyAgMjEyLjAwMTAwNl0gMmM1MGEgaXMgMmJl
NjMwMDAhDQpbICAyMTIuMDE0MjYxXSAyYzUwYiBpcyAyYmU2MjAwMCENClsgIDIxMi4wMjUx
MjRdIDJjNGYyIGlzIDJiZTYxMDAwIQ0KWyAgMjEyLjA0NjgyOV0gMmM0ZjMgaXMgMmJlNWQw
MDAhDQpbICAyMTIuMDQ4NjM4XSAyYzUwYyBpcyAyYmU1ZTAwMCENClsgIDIxMi4wNTA0NTVd
IDJjNTBkIGlzIDJiZTVmMDAwIQ0KWyAgMjEyLjA1MjI2OV0gMmM1MGUgaXMgMmJlNjAwMDAh
DQpbICAyMTIuMDU1MzE1XSAyYzRmNCBpcyAyYmU1NTAwMCENClsgIDIxMi4wNTcxNTNdIDJj
NGY1IGlzIDJiZTU2MDAwIQ0KWyAgMjEyLjA1ODk0NV0gMmM0ZjYgaXMgMmJlNTcwMDAhDQpb
ICAyMTIuMDYwNzczXSAyYzRmNyBpcyAyYmU1ODAwMCENClsgIDIxMi4wNjI2MzddIDJjNGY4
IGlzIDJiZTU5MDAwIQ0KWyAgMjEyLjA2NDQ4MV0gMmM0ZjkgaXMgMmJlNWEwMDAhDQpbICAy
MTIuMDY2Mjc4XSAyYzRmYSBpcyAyYmU1YjAwMCENClsgIDIxMi4wNjgxMjZdIDJjNTFhIGlz
IDJiZTVjMDAwIQ0KWyAgMjEyLjA3MDcyNV0gMmM1MjYgaXMgMmJlNDUwMDAhDQpbICAyMTIu
MDcyNTcyXSAyYzUyNyBpcyAyYmU0NjAwMCENClsgIDIxMi4wNzQ0MDNdIDJjNTI4IGlzIDJi
ZTQ3MDAwIQ0KWyAgMjEyLjA3NjIwOV0gMmM1MjkgaXMgMmJlNDgwMDAhDQpbICAyMTIuMDc4
MDUxXSAyYzUyYSBpcyAyYmU0OTAwMCENClsgIDIxMi4wODA3MDNdIDJjNTFiIGlzIDJiZTFh
MDAwIQ0KWyAgMjEyLjA4MjU3NF0gMmM1MWMgaXMgMmJlMWIwMDAhDQpbICAyMTIuMDg0Mzg1
XSAyYzUxZCBpcyAyYmUxYzAwMCENClsgIDIxMi4wODYxODNdIDJjNTFlIGlzIDJiZTFkMDAw
IQ0KWyAgMjEyLjA4Nzk3N10gMmM1MWYgaXMgMmJlMWUwMDAhDQpbICAyMTIuMDg5NzYzXSAy
YzUyMCBpcyAyYmUxZjAwMCENClsgIDIxMi4wOTE1MzJdIDJjNTIxIGlzIDJiZTIwMDAwIQ0K
WyAgMjEyLjA5MzMxNl0gMmM1MjIgaXMgMmJlMjEwMDAhDQpbICAyMTIuMDk1MTQ5XSAyYzUy
MyBpcyAyYmUyMjAwMCENClsgIDIxMi4wOTY5MjBdIDJjNTI0IGlzIDJiZTIzMDAwIQ0KWyAg
MjEyLjA5ODY4N10gMmM1MjUgaXMgMmJlMjQwMDAhDQpbICAyMTIuMTAwNDYyXSAyYzUyYiBp
cyAyYmUyZjAwMCENClsgIDIxMi4xMDIyMjldIDJjNTBmIGlzIDJiZTMwMDAwIQ0KWyAgMjEy
LjEwNDAwNl0gMmM1MTAgaXMgMmJlMzEwMDAhDQpbICAyMTIuMTA1NzY1XSAyYzUxMSBpcyAy
YmUzMjAwMCENClsgIDIxMi4xMDc1MjFdIDJjNTEyIGlzIDJiZTMzMDAwIQ0KWyAgMjEyLjEw
OTI1NV0gMmM1MTMgaXMgMmJlMzQwMDAhDQpbICAyMTIuMTExMDA1XSAyYzUxNCBpcyAyYmUz
NTAwMCENClsgIDIxMi4xMTI3MThdIDJjNTE1IGlzIDJiZTM2MDAwIQ0KWyAgMjEyLjExNDQ0
NF0gMmM1MTYgaXMgMmJlMzcwMDAhDQpbICAyMTIuMTE2MTQwXSAyYzUxNyBpcyAyYmUzODAw
MCENClsgIDIxMi4xMTc4NDRdIDJjNTE4IGlzIDJiZTM5MDAwIQ0KWyAgMjEyLjExOTUzOF0g
MmM1MTkgaXMgMmJlMjUwMDAhDQpbICAyMTIuMTIxMjM2XSAyYzUzOSBpcyAyYmUyNjAwMCEN
ClsgIDIxMi4xMjI5MzddIDJjNTNhIGlzIDJiZTI3MDAwIQ0KWyAgMjEyLjEyNDYzMF0gMmM1
M2IgaXMgMmJlMjgwMDAhDQpbICAyMTIuMTI2Mjk3XSAyYzUzYyBpcyAyYmUyOTAwMCENClsg
IDIxMi4xMjc5ODJdIDJjNTNkIGlzIDJiZTJhMDAwIQ0KWyAgMjEyLjEyOTYzOF0gMmM1M2Ug
aXMgMmJlMmIwMDAhDQpbICAyMTIuMTMxMzIzXSAyYzUzZiBpcyAyYmUyYzAwMCENClsgIDIx
Mi4xMzI5OTBdIDJjNTQwIGlzIDJiZTJkMDAwIQ0KWyAgMjEyLjEzNDY3N10gMmM1NDEgaXMg
MmJlMmUwMDAhDQpbICAyMTIuMTM4MDU4XSAyYzU0MiBpcyAyYmRkYTAwMCENClsgIDIxMi4x
Mzk5MDldIDJjNTJjIGlzIDJiZGRiMDAwIQ0KWyAgMjEyLjE0MTYyM10gMmM1MmQgaXMgMmJk
ZGMwMDAhDQpbICAyMTIuMTQzMzQzXSAyYzUyZSBpcyAyYmRkZDAwMCENClsgIDIxMi4xNDUw
NjldIDJjNTJmIGlzIDJiZGRlMDAwIQ0KWyAgMjEyLjE0Njc2NF0gMmM1MzAgaXMgMmJkZGYw
MDAhDQpbICAyMTIuMTQ4NDU0XSAyYzUzMSBpcyAyYmRlMDAwMCENClsgIDIxMi4xNTAxNTVd
IDJjNTMyIGlzIDJiZGUxMDAwIQ0KWyAgMjEyLjE1MTgzNV0gMmM1MzMgaXMgMmJkZTIwMDAh
DQpbICAyMTIuMTUzNTEyXSAyYzUzNCBpcyAyYmRlMzAwMCENClsgIDIxMi4xNTUxNzBdIDJj
NTM1IGlzIDJiZGU0MDAwIQ0KWyAgMjEyLjE1Njg1MF0gMmM1NWYgaXMgMmJkZWYwMDAhDQpb
ICAyMTIuMTU4NDg1XSAyYzU1ZSBpcyAyYmRmMDAwMCENClsgIDIxMi4xNjAxNTNdIDJjNTVk
IGlzIDJiZGYxMDAwIQ0KWyAgMjEyLjE2MTc5M10gMmM1NWMgaXMgMmJkZjIwMDAhDQpbICAy
MTIuMTYzNDQ2XSAyYzU1YiBpcyAyYmRmMzAwMCENClsgIDIxMi4xNjUwOTddIDJjNTVhIGlz
IDJiZGY0MDAwIQ0KWyAgMjEyLjE2Njc1MV0gMmM1NTkgaXMgMmJkZjUwMDAhDQpbICAyMTIu
MTY4NDAwXSAyYzU1OCBpcyAyYmRmNjAwMCENClsgIDIxMi4xNzAwNTZdIDJjNTM4IGlzIDJi
ZGY3MDAwIQ0KWyAgMjEyLjE3MTY5OV0gMmM1MzcgaXMgMmJkZjgwMDAhDQpbICAyMTIuMTcz
MzgwXSAyYzUzNiBpcyAyYmRmOTAwMCENClsgIDIxMi4xNzUzNjJdIDJjNTc3IGlzIDJiZGM1
MDAwIQ0KWyAgMjEyLjE3NzA5Ml0gMmM1N2EgaXMgMmJkYzYwMDAhDQpbICAyMTIuMTc4NzYy
XSAyYzU3YiBpcyAyYmRjNzAwMCENClsgIDIxMi4xODA0NTVdIDJjNTdjIGlzIDJiZGM4MDAw
IQ0KWyAgMjEyLjE4MjEzOF0gMmM1N2QgaXMgMmJkYzkwMDAhDQpbICAyMTIuMTgzODE3XSAy
YzU3ZSBpcyAyYmRjYTAwMCENClsgIDIxMi4xODU1MDldIDJjNTdmIGlzIDJiZGNiMDAwIQ0K
WyAgMjEyLjE4NzE4MF0gMmM1ODAgaXMgMmJkY2MwMDAhDQpbICAyMTIuMTg4ODYxXSAyYzU4
MSBpcyAyYmRjZDAwMCENClsgIDIxMi4xOTA1NTBdIDJjNTgyIGlzIDJiZGNlMDAwIQ0KWyAg
MjEyLjE5MjE5N10gMmM1NDMgaXMgMmJkZTUwMDAhDQpbICAyMTIuMTkzODg2XSAyYzU0NCBp
cyAyYmRlNjAwMCENClsgIDIxMi4xOTU1MzJdIDJjNTQ1IGlzIDJiZGU3MDAwIQ0KWyAgMjEy
LjE5NzIwNF0gMmM1NDYgaXMgMmJkZTgwMDAhDQpbICAyMTIuMTk4ODczXSAyYzU0NyBpcyAy
YmRlOTAwMCENClsgIDIxMi4yMDA1NDVdIDJjNTQ4IGlzIDJiZGVhMDAwIQ0KWyAgMjEyLjIw
MjIyNV0gMmM1NDkgaXMgMmJkZWIwMDAhDQpbICAyMTIuMjAzOTAzXSAyYzU0YSBpcyAyYmRl
YzAwMCENClsgIDIxMi4yMDU1ODRdIDJjNTRiIGlzIDJiZGVkMDAwIQ0KWyAgMjEyLjIwNzI2
Nl0gMmM1NGMgaXMgMmJkZWUwMDAhDQpbICAyMTIuMjA4OTM2XSAyYzU0ZCBpcyAyYmRjZjAw
MCENClsgIDIxMi4yMTA2MzNdIDJjNTRlIGlzIDJiZGQwMDAwIQ0KWyAgMjEyLjIxMjI5NV0g
MmM1NGYgaXMgMmJkZDEwMDAhDQpbICAyMTIuMjEzOTgxXSAyYzU1MCBpcyAyYmRkMjAwMCEN
ClsgIDIxMi4yMTU2NDhdIDJjNTUxIGlzIDJiZGQzMDAwIQ0KWyAgMjEyLjIxNzMyOV0gMmM1
NTIgaXMgMmJkZDQwMDAhDQpbICAyMTIuMjE5MDEyXSAyYzU1MyBpcyAyYmRkNTAwMCENClsg
IDIxMi4yMjA2OTNdIDJjNTU0IGlzIDJiZGQ2MDAwIQ0KWyAgMjEyLjIyMjM4MF0gMmM1NTUg
aXMgMmJkZDcwMDAhDQpbICAyMTIuMjI0MDYyXSAyYzU1NiBpcyAyYmRkODAwMCENClsgIDIx
Mi4yMjU3MjldIDJjNTU3IGlzIDJiZGQ5MDAwIQ0KWyAgMjEyLjIyOTAzNF0gMmM1OTggaXMg
MmJkYTUwMDAhDQpbICAyMTIuMjMwNzk1XSAyYzU5OSBpcyAyYmRhNjAwMCENClsgIDIxMi4y
MzI0OTJdIDJjNTlhIGlzIDJiZGE3MDAwIQ0KWyAgMjEyLjIzNDIyMV0gMmM1OWIgaXMgMmJk
YTgwMDAhDQpbICAyMTIuMjM1OTI5XSAyYzU5YyBpcyAyYmRhOTAwMCENClsgIDIxMi4yMzc2
MjNdIDJjNTlkIGlzIDJiZGFhMDAwIQ0KWyAgMjEyLjIzOTMxOF0gMmM1OWUgaXMgMmJkYWIw
MDAhDQpbICAyMTIuMjQxMDA5XSAyYzU5ZiBpcyAyYmRhYzAwMCENClsgIDIxMi4yNDI2ODld
IDJjNWEwIGlzIDJiZGFkMDAwIQ0KWyAgMjEyLjI0NDQxMV0gMmM1YTEgaXMgMmJkYWUwMDAh
DQpbICAyMTIuMjQ2MDg0XSAyYzU2MCBpcyAyYmRiYTAwMCENClsgIDIxMi4yNDc3ODJdIDJj
NTgzIGlzIDJiZGJiMDAwIQ0KWyAgMjEyLjI0OTQ3Ml0gMmM1ODQgaXMgMmJkYmMwMDAhDQpb
ICAyMTIuMjUxMTQyXSAyYzU4NSBpcyAyYmRiZDAwMCENClsgIDIxMi4yNTI4MTRdIDJjNTg2
IGlzIDJiZGJlMDAwIQ0KWyAgMjEyLjI1NDQ4M10gMmM1ODcgaXMgMmJkYmYwMDAhDQpbICAy
MTIuMjU2MTQzXSAyYzU4OCBpcyAyYmRjMDAwMCENClsgIDIxMi4yNTc4MDZdIDJbICAyMTQu
MzgzOTE2XSAyYzEzNyBpcyAyYzE5ODAwMCENClsgIDIxNC4zODU1ODddIDJjMTM4IGlzIDJj
MTk5MDAwIQ0KWyAgMjE0LjM4NzI1N10gMmMxMzkgaXMgMmMxOWEwMDAhDQpbICAyMTQuMzg4
OTEzXSAyYzEzYSBpcyAyYzE5YjAwMCENClsgIDIxNC4zOTA1OTldIDJjMTNiIGlzIDJjMTlj
MDAwIQ0KWyAgMjE0LjM5MjI2MV0gMmMxM2MgaXMgMmMxOWQwMDAhDQpbICAyMTQuMzkzOTUw
XSAyYzEzZCBpcyAyYzE5ZTAwMCENClsgIDIxNC4zOTU2MDldIDJjMTQwIGlzIDJjMTlmMDAw
IQ0KWyAgMjE0LjM5NzI3NF0gMmMxMGEgaXMgMmMxOGIwMDAhDQpbICAyMTQuMzk4OTUxXSAy
YzEwYiBpcyAyYzE4YzAwMCENClsgIDIxNC40MDA2MjddIDJjMTBjIGlzIDJjMThkMDAwIQ0K
WyAgMjE0LjQwMjMxNF0gMmMxMGQgaXMgMmMxOGUwMDAhDQpbICAyMTQuNDA0MDAxXSAyYzEw
ZSBpcyAyYzE4ZjAwMCENClsgIDIxNC40MDU2NjNdIDJjMTBmIGlzIDJjMTkwMDAwIQ0KWyAg
MjE0LjQwNzM2N10gMmMxMTAgaXMgMmMxOTEwMDAhDQpbICAyMTQuNDA5MDQwXSAyYzExMSBp
cyAyYzE5MjAwMCENClsgIDIxNC40MTA3NDJdIDJjMTEyIGlzIDJjMTkzMDAwIQ0KWyAgMjE0
LjQxMjQxNV0gMmMxMTMgaXMgMmMxOTQwMDAhDQpbICAyMTQuNDE0MTAyXSAyYzExNCBpcyAy
YzE5NTAwMCENClsgIDIxNC40MTU5ODBdIDJjMGY1IGlzIDJjOTc3MDAwIQ0KWyAgMjE0LjQx
Nzc0NF0gMmMwZjYgaXMgMmM5NzgwMDAhDQpbICAyMTQuNDE5NDYzXSAyYzBmNyBpcyAyYzk3
OTAwMCENClsgIDIxNC40MjExODRdIDJjMGY4IGlzIDJjOTdhMDAwIQ0KWyAgMjE0LjQyMjkx
Ml0gMmMwZjkgaXMgMmM5N2IwMDAhDQpbICAyMTQuNDI0NjM4XSAyYzBmYSBpcyAyYzk3YzAw
MCENClsgIDIxNC40MjYzNDZdIDJjMGZiIGlzIDJjOTdkMDAwIQ0KWyAgMjE0LjQyODA3OF0g
MmMwZmMgaXMgMmM5N2UwMDAhDQpbICAyMTQuNDI5Nzk3XSAyYzBmZCBpcyAyYzk3ZjAwMCEN
ClsgIDIxNC40MzE2NzldIDJjMGY0IGlzIDJjOTc1MDAwIQ0KWyAgMjE0LjQ0MDMyMF0gMmMw
ZmUgaXMgMmM5NmUwMDAhDQpbICAyMTQuNDQyNDU4XSAyYzE0MiBpcyAyYzk1ZjAwMCENClsg
IDIxNC40NDQ2MzVdIDJjMTQzIGlzIDJjOTYwMDAwIQ0KWyAgMjE0LjQ0NjgyN10gMmMxNDQg
aXMgMmM5NWUwMDAhDQpbICAyMTQuNDQ4OTk5XSAyYzE0NSBpcyAyYzk1ZDAwMCENClsgIDIx
NC40NjcwNDhdIDJjMTQ2IGlzIDJjOTYzMDAwIQ0KWyAgMjE0LjQ3ODI5NF0gMmMxNTEgaXMg
MmM5NjEwMDAhDQpbICAyMTQuNDgwMTIzXSAyYzBmZiBpcyAyYzk2ZjAwMCENClsgIDIxNC40
ODE5MTRdIDJjMTQ3IGlzIDJjOTZhMDAwIQ0KWyAgMjE0LjQ4MzcyNV0gMmMxNDggaXMgMmM5
NzMwMDAhDQpbICAyMTQuNDg1NTI2XSAyYzE0OSBpcyAyYzk3NDAwMCENClsgIDIxNC40ODcz
MTNdIDJjMTRhIGlzIDJjOTY5MDAwIQ0KWyAgMjE0LjQ4OTA4OV0gMmMxNGIgaXMgMmM5NmIw
MDAhDQpbICAyMTQuNDkwODg3XSAyYzE0YyBpcyAyYzk2MjAwMCENClsgIDIxNC40OTI2NDld
IDJjMTRkIGlzIDJjOTY4MDAwIQ0KWyAgMjE0LjQ5NDQ0N10gMmMxNGUgaXMgMmM5NjYwMDAh
DQpbICAyMTQuNDk2MTk4XSAyYzE0ZiBpcyAyYzk2NTAwMCENClsgIDIxNC40OTc5ODJdIDJj
MTUwIGlzIDJjOTY0MDAwIQ0KWyAgMjE0LjUxNDAzOV0gMmMxNWQgaXMgMmM5NTYwMDAhDQpb
ICAyMTQuNTE1ODg0XSAyYzE1ZSBpcyAyYzk1NzAwMCENClsgIDIxNC41MTc2OTBdIDJjMTUy
IGlzIDJhNDI4MDAwIQ0KWyAgMjE0LjUxOTQ5OF0gMmMxNTMgaXMgMmFkYmYwMDAhDQpbICAy
MTQuNTIxMjkyXSAyYzE1NCBpcyAyYzk3MDAwMCENClsgIDIxNC41MjMxMDBdIDJjMTU1IGlz
IDJiZmZiMDAwIQ0KWyAgMjE0LjUyNDkyNl0gMmMxNTYgaXMgMmMzYzcwMDAhDQpbICAyMTQu
NTI2NzY3XSAyYzE1NyBpcyAyYmZmYzAwMCENClsgIDIxNC41Mjg2MjFdIDJjMTU4IGlzIDJj
OTU5MDAwIQ0KWyAgMjE0LjUzMDQ5N10gMmMxNTkgaXMgMmM5NTgwMDAhDQpbICAyMTQuNTMy
NDE1XSAyYzE1YSBpcyAyYzNjODAwMCENClsgIDIxNC41MzQyOTddIDJjMTViIGlzIDJjOTZj
MDAwIQ0KWyAgMjE0LjUzNjE4Nl0gMmMxNWMgaXMgMmM5NmQwMDAhDQpbICAyMTQuNTM4Mjc0
XSAyYzE2OSBpcyAyYzk0YjAwMCENClsgIDIxNC41NDAxOTFdIDJjMTVmIGlzIDJjOTRjMDAw
IQ0KWyAgMjE0LjU0MjA1MV0gMmMxNjAgaXMgMmM5NGQwMDAhDQpbICAyMTQuNTQzOTQzXSAy
YzE2MSBpcyAyYzk0ZTAwMCENClsgIDIxNC41NDU3OTNdIDJjMTYyIGlzIDJjOTRmMDAwIQ0K
WyAgMjE0LjU0NzY1NV0gMmMxNjMgaXMgMmM5NTAwMDAhDQpbICAyMTQuNTQ5NTA1XSAyYzE2
NCBpcyAyYzk1MzAwMCENClsgIDIxNC41NTEzMzddIDJjMTY1IGlzIDJjOTU0MDAwIQ0KWyAg
MjE0LjU1MzE1OF0gMmMxNjYgaXMgMmJiMDEwMDAhDQpbICAyMTQuNTU0OTg0XSAyYzE2NyBp
cyAyYmIwMjAwMCENClsgIDIxNC41NTY4MjZdIDJjMTY4IGlzIDJjOTU1MDAwIQ0KWyAgMjE0
LjU1OTE3N10gMmMxN2UgaXMgMmM5NDcwMDAhDQpbICAyMTQuNTYxMDUzXSAyYzE2YSBpcyAy
Yzk0ODAwMCENClsgIDIxNC41NjI4OThdIDJjMTZiIGlzIDJjOTQ5MDAwIQ0KWyAgMjE0LjU2
NDc3OV0gMmMxNmMgaXMgMmM5NGEwMDAhDQpbICAyMTQuNTY3Mzg3XSAyYzE2ZCBpcyAyYzkz
ZjAwMCENClsgIDIxNC41NjkzMDFdIDJjMTZlIGlzIDJjOTQwMDAwIQ0KWyAgMjE0LjU3MTE4
NV0gMmMxNmYgaXMgMmM5NDEwMDAhDQpbICAyMTQuNTczMDcxXSAyYzE3MCBpcyAyYzk0MjAw
MCENClsgIDIxNC41NzQ5NThdIDJjMTcxIGlzIDJjOTQzMDAwIQ0KWyAgMjE0LjU3Njg1OV0g
MmMxNzIgaXMgMmM5NDQwMDAhDQpbICAyMTQuNTc4NjkzXSAyYzE3MyBpcyAyYzk0NTAwMCEN
ClsgIDIxNC41ODA1MzBdIDJjMTc0IGlzIDJjOTQ2MDAwIQ0KWyAgMjE0LjU4MzE1NF0gMmMx
OWYgaXMgMmM5MmYwMDAhDQpbICAyMTQuNTg1MDIzXSAyYzFhMCBpcyAyYzkzMDAwMCENClsg
IDIxNC41ODY4OTddIDJjMWExIGlzIDJjOTMxMDAwIQ0KWyAgMjE0LjU4ODY4NF0gMmMxYTIg
aXMgMmM5MzIwMDAhDQpbICAyMTQuNTkwNDgzXSAyYzFhMyBpcyAyYzkzMzAwMCENClsgIDIx
NC41OTIyNDBdIDJjMTllIGlzIDJjOTI0MDAwIQ0KWyAgMjE0LjU5NDEwMl0gMmMxOWQgaXMg
MmM5MjUwMDAhDQpbICAyMTQuNTk1ODYxXSAyYzE3ZCBpcyAyYzkyNjAwMCENClsgIDIxNC41
OTc2NTFdIDJjMTdjIGlzIDJjOTI3MDAwIQ0KWyAgMjE0LjU5OTM5MF0gMmMxN2IgaXMgMmM5
MjgwMDAhDQpbICAyMTQuNjAxMTM3XSAyYzE3YSBpcyAyYzkyOTAwMCENClsgIDIxNC42MDI4
OTNdIDJjMTc5IGlzIDJjOTJhMDAwIQ0KWyAgMjE0LjYwNDY1MF0gMmMxNzggaXMgMmM5MmIw
MDAhDQpbICAyMTQuNjA2NDEzXSAyYzE3NyBpcyAyYzkyYzAwMCENClsgIDIxNC42MDgxNzFd
IDJjMTc2IGlzIDJjOTJkMDAwIQ0KWyAgMjE0LjYwOTkyMV0gMmMxNzUgaXMgMmM5MmUwMDAh
DQpbICAyMTQuNjEyNTU3XSAyYzE4OSBpcyAyYzkwZjAwMCENClsgIDIxNC42MTQzNzBdIDJj
MThhIGlzIDJjOTEwMDAwIQ0KWyAgMjE0LjYxNjEyN10gMmMxOGIgaXMgMmM5MTEwMDAhDQpb
ICAyMTQuNjE3ODc1XSAyYzE4YyBpcyAyYzkxMjAwMCENClsgIDIxNC42MTk2MTFdIDJjMThk
IGlzIDJjOTEzMDAwIQ0KWyAgMjE0LjYyMTMzMF0gMmMxOGUgaXMgMmM5MTQwMDAhDQpbICAy
MTQuNjIzMDYxXSAyYzE4ZiBpcyAyYzkxNTAwMCENClsgIDIxNC42MjQ3ODRdIDJjMTkwIGlz
IDJjOTE2MDAwIQ0KWyAgMjE0LjYyNjUwNl0gMmMxOTEgaXMgMmM5MTcwMDAhDQpbICAyMTQu
NjI4MjQ1XSAyYzE5MiBpcyAyYzkxODAwMCENClsgIDIxNC42Mjk5NjldIDJjMTg4IGlzIDJj
OTA0MDAwIQ0KWyAgMjE0LjYzMTcwMV0gMmMxODcgaXMgMmM5MDUwMDAhDQpbICAyMTQuNjMz
NDIyXSAyYzE4NiBpcyAyYzkwNjAwMCENClsgIDIxNC42MzUxNTBdIDJjMTg1IGlzIDJjOTA3
MDAwIQ0KWyAgMjE0LjYzNjg3N10gMmMxODQgaXMgMmM5MDgwMDAhDQpbICAyMTQuNjM4NTg1
XSAyYzE4MyBpcyAyYzkwOTAwMCENClsgIDIxNC42NDAzMTFdIDJjMTgyIGlzIDJjOTBhMDAw
IQ0KWyAgMjE0LjY0MjAwMl0gMmMxODEgaXMgMmM5MGIwMDAhDQpbICAyMTQuNjQzNzI0XSAy
YzE4MCBpcyAyYzkwYzAwMCENClsgIDIxNC42NDU0MTRdIDJjMTdmIGlzIDJjOTBkMDAwIQ0K
WyAgMjE0LjY0NzExOV0gMmMxYTQgaXMgMmM5MGUwMDAhDQpbICAyMTQuNjQ5NzQxXSAyYzFh
ZiBpcyAyYzhlZjAwMCENClsgIDIxNC42NTE0OTRdIDJjMWIwIGlzIDJjOGYwMDAwIQ0KWyAg
MjE0LjY1MzIzOV0gMmMxYjEgaXMgMmM4ZjEwMDAhDQpbICAyMTQuNjU1MDA0XSAyYzFiMiBp
cyAyYzhmMjAwMCENClsgIDIxNC42NTY4NTFdIDJjMWIzIGlzIDJjOGYzMDAwIQ0KWyAgMjE0
LjY1ODU3M10gMmMxYjQgaXMgMmM4ZjQwMDAhDQpbICAyMTQuNjYwMzIzXSAyYzFiNSBpcyAy
YzhmNTAwMCENClsgIDIxNC42NjIwNDVdIDJjMWI2IGlzIDJjOGY2MDAwIQ0KWyAgMjE0LjY2
Mzc4M10gMmMxYjcgaXMgMmM4ZjcwMDAhDQpbICAyMTQuNjY1NTI0XSAyYzFiOCBpcyAyYzhm
ODAwMCENClsgIDIxNC42NjcyNTRdIDJjMWFlIGlzIDJjOGU0MDAwIQ0KWyAgMjE0LjY2OTAw
NF0gMmMxYWQgaXMgMmM4ZTUwMDAhDQpbICAyMTQuNjcwNzAyXSAyYzFhYyBpcyAyYzhlNjAw
MCENClsgIDIxNC42NzIzODZdIDJjMWFiIGlzIDJjOGU3MDAwIQ0KWyAgMjE0LjY3NDEwMF0g
MmMxYWEgaXMgMmM4ZTgwMDAhDQpbICAyMTQuNjc1Nzg0XSAyYzFhOSBpcyAyYzhlOTAwMCEN
ClsgIDIxNC42Nzc0OTNdIDJjMWE4IGlzIDJjOGVhMDAwIQ0KWyAgMjE0LjY3OTE3Ml0gMmMx
YTcgaXMgMmM4ZWIwMDAhDQpbICAyMTQuNjgwODczXSAyYzFhNiBpcyAyYzhlYzAwMCENClsg
IDIxNC42ODI1NDVdIDJjMWE1IGlzIDJjOGVkMDAwIQ0KWyAgMjE0LjY4NDIzMV0gMmMxOTMg
aXMgMmM4ZWUwMDAhDQpbICAyMTQuNjg3NjI0XSAyYzFiYSBpcyAyYzhhZjAwMCENClsgIDIx
NC42ODkzNDldIDJjMWJiIGlzIDJjOGIwMDAwIQ0KWyAgMjE0LjY5MTA1NV0gMmMxZGQgaXMg
MmM4YjEwMDAhDQpbICAyMTQuNjkyNzU5XSAyYzFkZSBpcyAyYzhiMjAwMCENClsgIDIxNC42
OTQ0ODJdIDJjMWRmIGlzIDJjOGIzMDAwIQ0KWyAgMjE0LjY5NjE4Nl0gMmMxZTAgaXMgMmM4
YjQwMDAhDQpbICAyMTQuNjk3OTEyXSAyYzFlMSBpcyAyYzhiNTAwMCENClsgIDIxNC42OTk2
MDJdIDJjMWUyIGlzIDJjOGI2MDAwIQ0KWyAgMjE0LjcwMTMxOV0gMmMxZTMgaXMgMmM4Yjcw
MDAhDQpbICAyMTQuNzAzMDQ0XSAyYzFlNCBpcyAyYzhiODAwMCENClsgIDIxNC43MDQ3NTld
IDJjMWJlIGlzIDJjOGM0MDAwIQ0KWyAgMjE0LjcwNjQ5MF0gMmMxOWMgaXMgMmM4YzUwMDAh
DQpbICAyMTQuNzA4MTk3XSAyYzE5YiBpcyAyYzhjNjAwMCENClsgIDIxNC43MDk5MDddIDJj
MTlhIGlzIDJjOGM3MDAwIQ0KWyAgMjE0LjcxMTU4M10gMmMxOTkgaXMgMmM4YzgwMDAhDQpb
ICAyMTQuNzEzMjUxXSAyYzE5OCBpcyAyYzhjOTAwMCENClsgIDIxNC43MTQ5NDhdIDJjMTk3
IGlzIDJjOGNhMDAwIQ0KWyAgMjE0LjcxNjYxNl0gMmMxOTYgaXMgMmM4Y2IwMDAhDQpbICAy
MTQuNzE4MzEyXSAyYzE5NSBpcyAyYzhjYzAwMCENClsgIDIxNC43MTk5NzNdIDJjMTk0IGlz
IDJjOGNkMDAwIQ0KWyAgMjE0LjcyMTY0OV0gMmMxYjkgaXMgMmM4Y2UwMDAhDQpbICAyMTQu
NzIzMzM0XSAyYzFjOSBpcyAyYzhiOTAwMCENClsgIDIxNC43MjUwMjddIDJjMWM4IGlzIDJj
OGJhMDAwIQ0KWyAgMjE0LjcyNjc0MF0gMmMxYzcgaXMgMmM4YmIwMDAhDQpbICAyMTQuNzI4
NDE5XSAyYzFjNiBpcyAyYzhiYzAwMCENClsgIDIxNC43MzAxMTJdIDJjMWM1IGlzIDJjOGJk
MDAwIQ0KWyAgMjE0LjczMTgwN10gMmMxYzQgaXMgMmM4YmUwMDAhDQpbICAyMTQuNzMzNTAw
XSAyYzFjMyBpcyAyYzhiZjAwMCENClsgIDIxNC43MzUxODhdIDJjMWMyIGlzIDJjOGMwMDAw
IQ0KWyAgMjE0LjczNjg4MF0gMmMxYzEgaXMgMmM4YzEwMDAhDQpbICAyMTQuNzM4NTUyXSAy
YzFjMCBpcyAyYzhjMjAwMCENClsgIDIxNC43NDAyNTBdIDJjMWJmIGlzIDJjOGMzMDAwIQ0K
WyAgMjE0Ljc0MzAxMV0gMmMxZjEgaXMgMmM4OWEwMDAhDQpbICAyMTQuNzQ0NzkyXSAyYzFm
MiBpcyAyYzg5YjAwMCENClsgIDIxNC43NDY0NjFdIDJjMWYzIGlzIDJjODljMDAwIQ0KWyAg
MjE0Ljc0ODE3Ml0gMmMxZjQgaXMgMmM4OWQwMDAhDQpbICAyMTQuNzQ5ODU2XSAyYzFmNSBp
cyAyYzg5ZTAwMCENClsgIDIxNC43NTE1NjNdIDJjMWY2IGlzIDJjODlmMDAwIQ0KWyAgMjE0
Ljc1MzI1MV0gMmMxZjcgaXMgMmM4YTAwMDAhDQpbICAyMTQuNzU1MTg5XSAyYzFmOCBpcyAy
YzhhMTAwMCENClsgIDIxNC43NTY5MTFdIDJjMWY5IGlzIDJjOGEyMDAwIQ0KWyAgMjE0Ljc1
ODU5MF0gMmMxZmEgaXMgMmM4YTMwMDAhDQpbICAyMTQuNzYwMjk2XSAyYzFmYiBpcyAyYzg4
ZjAwMCENClsgIDIxNC43NjE5NzNdIDJjMWZlIGlzIDJjODkwMDAwIQ0KWyAgMjE0Ljc2MzY2
OV0gMmMxZmYgaXMgMmM4OTEwMDAhDQpbICAyMTQuNzY1NDQ4XSAyYzIwMCBpcyAyYzg5MjAw
MCENClsgIDIxNC43NjcxNjBdIDJjMjAxIGlzIDJjODkzMDAwIQ0KWyAgMjE0Ljc2ODg5MV0g
MmMyMDIgaXMgMmM4OTQwMDAhDQpbICAyMTQuNzcwNTg0XSAyYzIwMyBpcyAyYzg5NTAwMCEN
ClsgIDIxNC43NzIyNjhdIDJjMjA0IGlzIDJjODk2MDAwIQ0KWyAgMjE0Ljc3Mzk4OF0gMmMy
MDUgaXMgMmM4OTcwMDAhDQpbICAyMTQuNzc1NjcyXSAyYzIwNiBpcyAyYzg5ODAwMCENClsg
IDIxNC43NzczNzVdIDJjMWVmIGlzIDJjODg0MDAwIQ0KWyAgMjE0Ljc3OTA1NF0gMmMxZWUg
aXMgMmM4ODUwMDAhDQpbICAyMTQuNzgwNzYwXSAyYzFlZCBpcyAyYzg4NjAwMCENClsgIDIx
NC43ODI0ODNdIDJjMWVjIGlzIDJjODg3MDAwIQ0KWyAgMjE0Ljc4NDIwN10gMmMxZWIgaXMg
MmM4ODgwMDAhDQpbICAyMTQuNzg1OTA3XSAyYzFlYSBpcyAyYzg4OTAwMCENClsgIDIxNC43
ODc1OTVdIDJjMWU5IGlzIDJjODhhMDAwIQ0KWyAgMjE0Ljc4OTI5MV0gMmMxZTggaXMgMmM4
OGIwMDAhDQpbICAyMTQuNzkwOTk3XSAyYzFlNyBpcyAyYzg4YzAwMCENClsgIDIxNC43OTI2
NzBdIDJjMWU2IGlzIDJjODhkMDAwIQ0KWyAgMjE0Ljc5NDM3M10gMmMxZTUgaXMgMmM4OGUw
MDAhDQpbICAyMTQuNzk2MzMzXSAyYzFmMCBpcyAyYzg2ZjAwMCENClsgIDIxNC43OTgwNTFd
IDJjMjA3IGlzIDJjODdlMDAwIQ0KWyAgMjE0Ljc5OTczMV0gMmMxY2EgaXMgMmM4N2YwMDAh
DQpbICAyMTQuODAxNDQ2XSAyYzFjYiBpcyAyYzg4MDAwMCENClsgIDIxNC44MDMxNDldIDJj
MWNjIGlzIDJjODgxMDAwIQ0KWyAgMjE0LjgwNDg1NF0gMmMxY2QgaXMgMmM4ODIwMDAhDQpb
ICAyMTQuODA2NTcwXSAyYzFjZSBpcyAyYzg4MzAwMCENClsgIDIxNC44MDgyNzNdIDJjMWRh
IGlzIDJjODcwMDAwIQ0KWyAgMjE0LjgwOTk4OF0gMmMxZGIgaXMgMmM4NzEwMDAhDQpbICAy
MTQuODExNjg4XSAyYzFkYyBpcyAyYzg3MjAwMCENClsgIDIxNC44MTMzODddIDJjMWNmIGlz
IDJjODczMDAwIQ0KWyAgMjE0LjgxNTA3M10gMmMxZDAgaXMgMmM4NzQwMDAhDQpbICAyMTQu
ODE2NzYxXSAyYzFkMSBpcyAyYzg3NTAwMCENClsgIDIxNC44MTg0NDddIDJjMWQyIGlzIDJj
ODc2MDAwIQ0KWyAgMjE0LjgyMDEyNV0gMmMxZDMgaXMgMmM4NzcwMDAhDQpbICAyMTQuODIx
Nzg4XSAyYzFkNCBpcyAyYzg3ODAwMCENClsgIDIxNC44MjM0ODhdIDJjMWQ1IGlzIDJjODc5
MDAwIQ0KWyAgMjE0LjgyNTEzNV0gMmMxZDYgaXMgMmM4N2EwMDAhDQpbICAyMTQuODI2ODE4
XSAyYzFkNyBpcyAyYzg3YjAwMCENClsgIDIxNC44Mjg0NzBdIDJjMWQ4IGlzIDJjODdjMDAw
IQ0KWyAgMjE0LjgzMDE0MV0gMmMxZDkgaXMgMmM4N2QwMDAhDQpbICAyMTQuODMyMzM5XSAz
NmQ1MSBpcyAyYzg2YjAwMCENClsgIDIxNC44MzQwODVdIDJjMjFkIGlzIDJjODZjMDAwIQ0K
WyAgMjE0LjgzNTgxMl0gMmMyMWUgaXMgMmM4NmQwMDAhDQpbICAyMTQuODM3NTMxXSAyYzIx
ZiBpcyAyYzg2ZTAwMCENClsgIDIxNC44NDAwMDldIDJjMjIwIGlzIDJjODYzMDAwIQ0KWyAg
MjE0Ljg0MTgzOV0gMzc2NzggaXMgMmM4NjQwMDAhDQpbICAyMTQuODQzNjg1XSAzNmRlYyBp
cyAyYzg2NTAwMCENClsgIDIxNC44NDU0NTBdIDJjMjA4IGlzIDJjODY2MDAwIQ0KWyAgMjE0
Ljg0NzI2OV0gMmMyMDkgaXMgMmM4NjcwMDAhDQpbICAyMTQuODQ5MDY4XSAyYzIwYSBpcyAy
Yzg2ODAwMCENClsgIDIxNC44NTA4NjZdIDJjMjBiIGlzIDJjODY5MDAwIQ0KWyAgMjE0Ljg1
MjY2M10gMmMyMGMgaXMgMmM4NmEwMDAhDQpbICAyMTQuODU1MzU2XSAyYzIxNyBpcyAyYzg0
ODAwMCENClsgIDIxNC44NTcxNzNdIDJjMjE2IGlzIDJjODQ5MDAwIQ0KWyAgMjE0Ljg1ODkx
OF0gMmMyMTUgaXMgMmM4NGEwMDAhDQpbICAyMTQuODYwNzA2XSAyYzIxNCBpcyAyYzg0YjAw
MCENClsgIDIxNC44NjI0NjJdIDJjMjEzIGlzIDJjODRjMDAwIQ0KWyAgMjE0Ljg2NDI1NF0g
MmMyMTIgaXMgMmM4NGQwMDAhDQpbICAyMTQuODY2MDA1XSAyYzIxMSBpcyAyYzg0ZTAwMCEN
ClsgIDIxNC44Njc3ODNdIDJjMjEwIGlzIDJjODRmMDAwIQ0KWyAgMjE0Ljg2OTU1OF0gMmMy
MGYgaXMgMmM4NTAwMDAhDQpbICAyMTQuODcxMzQ1XSAyYzIwZSBpcyAyYzg1MTAwMCENClsg
IDIxNC44NzMxMzFdIDJjMjBkIGlzIDJjODUyMDAwIQ0KWyAgMjE0Ljg3NTgyNl0gMmMyMTgg
aXMgMmM4MjgwMDAhDQpbICAyMTQuODc3NjY4XSAyYzIxOSBpcyAyYzgyOTAwMCENClsgIDIx
NC44Nzk0NDJdIDJjMjFhIGlzIDJjODJhMDAwIQ0KWyAgMjE0Ljg4MTI1Nl0gMmMyMWIgaXMg
MmM4MmIwMDAhDQpbICAyMTQuODgzMDQ3XSAyYzIxYyBpcyAyYzgyYzAwMCENClsgIDIxNC44
ODQ4NzRdIDJjMjQxIGlzIDJjODJkMDAwIQ0KWyAgMjE0Ljg4NjY3MV0gMmMyNDAgaXMgMmM4
MmUwMDAhDQpbICAyMTQuODg4NDc5XSAyYzIzZiBpcyAyYzgyZjAwMCENClsgIDIxNC44OTAz
MDFdIDJjMjNlIGlzIDJjODMwMDAwIQ0KWyAgMjE0Ljg5MjA2Nl0gMmMyM2QgaXMgMmM4MzEw
MDAhDQpbICAyMTQuODkzODM4XSAyYzIzYyBpcyAyYzgzMjAwMCENClsgIDIxNC44OTU1ODBd
IDJjMjQyIGlzIDJjODMzMDAwIQ0KWyAgMjE0Ljg5NzM1Nl0gMmMyNDMgaXMgMmM4MzQwMDAh
DQpbICAyMTQuODk5MDkyXSAyYzI0NCBpcyAyYzgzNTAwMCENClsgIDIxNC45MDA4MjRdIDJj
MjQ1IGlzIDJjODM2MDAwIQ0KWyAgMjE0LjkwMjU1NF0gMmMyNDYgaXMgMmM4MzcwMDAhDQpb
ICAyMTQuOTA0MjUxXSAyYzI0NyBpcyAyYzgzODAwMCENClsgIDIxNC45MDU5NDZdIDJjMjQ4
IGlzIDJjODM5MDAwIQ0KWyAgMjE0LjkwNzY0Ml0gMmMyNDkgaXMgMmM4M2EwMDAhDQpbICAy
MTQuOTA5MzIxXSAyYzI0YSBpcyAyYzgzYjAwMCENClsgIDIxNC45MTEwMzZdIDJjMjRiIGlz
IDJjODNjMDAwIQ0KWyAgMjE0LjkxMzYxNV0gMmMyNTggaXMgMmM4MTMwMDAhDQpbICAyMTQu
OTE1NDQzXSAyYzI1OSBpcyAyYzgxNDAwMCENClsgIDIxNC45MTcxNzldIDJjMjVhIGlzIDJj
ODE1MDAwIQ0KWyAgMjE0LjkxODkwMl0gMmMyNWIgaXMgMmM4MTYwMDAhDQpbICAyMTQuOTIw
NjEzXSAyYzI1YyBpcyAyYzgxNzAwMCENClsgIDIxNC45MjIzMzhdIDJjMjVkIGlzIDJjODE4
MDAwIQ0KWyAgMjE0LjkyNDA2MF0gMmMyNWUgaXMgMmM4MTkwMDAhDQpbICAyMTQuOTI1NzYy
XSAyYzI1ZiBpcyAyYzgxYTAwMCENClsgIDIxNC45Mjc0ODNdIDJjMjYwIGlzIDJjODFiMDAw
IQ0KWyAgMjE0LjkyOTE3OF0gMmMyNjEgaXMgMmM4MWMwMDAhDQpbICAyMTQuOTMwODg5XSAy
YzI1NyBpcyAyYzgwODAwMCENClsgIDIxNC45MzI1NzFdIDJjMjU2IGlzIDJjODA5MDAwIQ0K
WyAgMjE0LjkzNDI3MV0gMmMyNTUgaXMgMmM4MGEwMDAhDQpbICAyMTQuOTM1OTU3XSAyYzI1
NCBpcyAyYzgwYjAwMCENClsgIDIxNC45Mzc2MzldIDJjMjUzIGlzIDJjODBjMDAwIQ0KWyAg
MjE0LjkzOTMyMF0gMmMyNTIgaXMgMmM4MGQwMDAhDQpbICAyMTQuOTQwOTk2XSAyYzI1MSBp
cyAyYzgwZTAwMCENClsgIDIxNC45NDI2NjZdIDJjMjUwIGlzIDJjODBmMDAwIQ0KWyAgMlsg
IDIxNy4wNzIwMzFdIDJiZWRjIGlzIDJjYTI3MDAwIQ0KWyAgMjE3LjA3Mzc5OV0gMmJlZGQg
aXMgMmNhMjgwMDAhDQpbICAyMTcuMDc1NDg4XSAyYmVkZSBpcyAyY2EyOTAwMCENClsgIDIx
Ny4wNzcxOTVdIDJiZWRmIGlzIDJjYTJhMDAwIQ0KWyAgMjE3LjA3ODg3OF0gMmJlZTAgaXMg
MmNhMmIwMDAhDQpbICAyMTcuMDgwNTY1XSAyYmVlMSBpcyAyY2EyYzAwMCENClsgIDIxNy4w
ODIyNjldIDJiZWUyIGlzIDJjYTJkMDAwIQ0KWyAgMjE3LjA4Mzk2N10gMmJlZTMgaXMgMmNh
MmUwMDAhDQpbICAyMTcuMDg1NjY1XSAyYmVlNCBpcyAyY2EyZjAwMCENClsgIDIxNy4wODcz
MjRdIDJiZWU1IGlzIDJjYTFiMDAwIQ0KWyAgMjE3LjA4ODk5MF0gMmJlZTYgaXMgMmNhMWMw
MDAhDQpbICAyMTcuMDkwNjY0XSAyYmVlNyBpcyAyY2ExZDAwMCENClsgIDIxNy4wOTIzMTRd
IDJiZjA3IGlzIDJjYTFlMDAwIQ0KWyAgMjE3LjA5NDA0Ml0gMmJmMDggaXMgMmNhMWYwMDAh
DQpbICAyMTcuMDk1Njg2XSAyYmYwOSBpcyAyY2EyMDAwMCENClsgIDIxNy4wOTczNDRdIDJi
ZjBhIGlzIDJjYTIxMDAwIQ0KWyAgMjE3LjA5OTAwNl0gMmJmMGIgaXMgMmNhMjIwMDAhDQpb
ICAyMTcuMTAwNjY5XSAyYmYwYyBpcyAyY2EyMzAwMCENClsgIDIxNy4xMDIzNDZdIDJiZjBk
IGlzIDJjYTI0MDAwIQ0KWyAgMjE3LjEwNDcxMF0gMmJmMGUgaXMgMmNhMDUwMDAhDQpbICAy
MTcuMTA2MzgzXSAyYmYwZiBpcyAyY2EwNjAwMCENClsgIDIxNy4xMDgwNTZdIDJiZjEwIGlz
IDJjYTA3MDAwIQ0KWyAgMjE3LjEwOTcxOF0gMmJmMTEgaXMgMmNhMDgwMDAhDQpbICAyMTcu
MTExNDA5XSAyYmYxMiBpcyAyY2EwOTAwMCENClsgIDIxNy4xMTMwODJdIDJiZjEzIGlzIDJj
YTBhMDAwIQ0KWyAgMjE3LjExNDg4OF0gMmJmMTQgaXMgMmNhMGIwMDAhDQpbICAyMTcuMTE2
NTYwXSAyYmYxNSBpcyAyY2EwYzAwMCENClsgIDIxNy4xMTgyNDRdIDJiZjE2IGlzIDJjYTBk
MDAwIQ0KWyAgMjE3LjExOTkyN10gMmJmMTcgaXMgMmNhMGUwMDAhDQpbICAyMTcuMTIxNjA2
XSAyYmYxOCBpcyAyY2EwZjAwMCENClsgIDIxNy4xMjMyODNdIDJiZjE5IGlzIDJjOWZiMDAw
IQ0KWyAgMjE3LjEyNDk3MF0gMmJmMWEgaXMgMmM5ZmMwMDAhDQpbICAyMTcuMTI2NjQzXSAy
YmYxYiBpcyAyYzlmZDAwMCENClsgIDIxNy4xMjgzNDddIDJiZjFjIGlzIDJjOWZlMDAwIQ0K
WyAgMjE3LjEzMDAxNV0gMmJmMWQgaXMgMmM5ZmYwMDAhDQpbICAyMTcuMTMxNzE4XSAyYmYx
ZSBpcyAyY2EwMDAwMCENClsgIDIxNy4xMzM0MDVdIDJiZjFmIGlzIDJjYTAxMDAwIQ0KWyAg
MjE3LjEzNTA3Ml0gMmJmMjAgaXMgMmNhMDIwMDAhDQpbICAyMTcuMTM2Nzc5XSAyYmYyMSBp
cyAyY2EwMzAwMCENClsgIDIxNy4xMzg0NTldIDJiZjIyIGlzIDJjYTA0MDAwIQ0KWyAgMjE3
LjE0MTE0NV0gMmJlZDkgaXMgMmM5ZDAwMDAhDQpbICAyMTcuMTQyODUwXSAyYmVkOCBpcyAy
YzlkMTAwMCENClsgIDIxNy4xNDQ2NjJdIDJiZWQ3IGlzIDJjOWQyMDAwIQ0KWyAgMjE3LjE0
NjM5Nl0gMmJlZDYgaXMgMmM5ZDMwMDAhDQpbICAyMTcuMTQ4MTI1XSAyYmVkNSBpcyAyYzlk
NDAwMCENClsgIDIxNy4xNDk4MjJdIDJiZWQ0IGlzIDJjOWQ1MDAwIQ0KWyAgMjE3LjE1MTUy
NF0gMmJlZDMgaXMgMmM5ZDYwMDAhDQpbICAyMTcuMTUzMjI1XSAyYmVkMiBpcyAyYzlkNzAw
MCENClsgIDIxNy4xNTQ5MTddIDJiZWQxIGlzIDJjOWQ4MDAwIQ0KWyAgMjE3LjE1NjYwMF0g
MmJlZDAgaXMgMmM5ZDkwMDAhDQpbICAyMTcuMTU4MjgzXSAyYmVlYyBpcyAyYzlkYTAwMCEN
ClsgIDIxNy4xNjA4MjRdIDJiZjM3IGlzIDJjOWJiMDAwIQ0KWyAgMjE3LjE2MjU2MV0gMmJm
MzYgaXMgMmM5YmMwMDAhDQpbICAyMTcuMTY0MjczXSAyYmYzNSBpcyAyYzliZDAwMCENClsg
IDIxNy4xNjU5ODBdIDJiZjM0IGlzIDJjOWJlMDAwIQ0KWyAgMjE3LjE2NzY5NV0gMmJmMzMg
aXMgMmM5YmYwMDAhDQpbICAyMTcuMTY5NDI2XSAyYmYzMiBpcyAyYzljMDAwMCENClsgIDIx
Ny4xNzExMzldIDJiZjMxIGlzIDJjOWMxMDAwIQ0KWyAgMjE3LjE3Mjg2MV0gMmJmMzAgaXMg
MmM5YzIwMDAhDQpbICAyMTcuMTc0NTc4XSAyYmYyZiBpcyAyYzljMzAwMCENClsgIDIxNy4x
NzYyOTNdIDJiZjJlIGlzIDJjOWM0MDAwIQ0KWyAgMjE3LjE3ODAzNV0gMmJmMjMgaXMgMmM5
YjAwMDAhDQpbICAyMTcuMTc5NzQ2XSAyYmYyNCBpcyAyYzliMTAwMCENClsgIDIxNy4xODE0
NzNdIDJiZjI1IGlzIDJjOWIyMDAwIQ0KWyAgMjE3LjE4MzE4MV0gMmJmMjYgaXMgMmM5YjMw
MDAhDQpbICAyMTcuMTg0OTA1XSAyYmYyNyBpcyAyYzliNDAwMCENClsgIDIxNy4xODY2MzBd
IDJiZjI4IGlzIDJjOWI1MDAwIQ0KWyAgMjE3LjE4ODM0OV0gMmJmMjkgaXMgMmM5YjYwMDAh
DQpbICAyMTcuMTkwMDkwXSAyYmYyYSBpcyAyYzliNzAwMCENClsgIDIxNy4xOTE3NzldIDJi
ZjJiIGlzIDJjOWI4MDAwIQ0KWyAgMjE3LjE5MzUwNF0gMmJmMmMgaXMgMmM5YjkwMDAhDQpb
ICAyMTcuMTk1MjA2XSAyYmYyZCBpcyAyYzliYTAwMCENClsgIDIxNy4xOTc3ODhdIDJiZWY3
IGlzIDJjOTliMDAwIQ0KWyAgMjE3LjE5OTU4OF0gMmJlZjggaXMgMmM5OWMwMDAhDQpbICAy
MTcuMjAxMzEwXSAyYmVmOSBpcyAyYzk5ZDAwMCENClsgIDIxNy4yMDMwMzJdIDJiZWZhIGlz
IDJjOTllMDAwIQ0KWyAgMjE3LjIwNDc1Ml0gMmJlZmIgaXMgMmM5OWYwMDAhDQpbICAyMTcu
MjA2NDczXSAyYmVmYyBpcyAyYzlhMDAwMCENClsgIDIxNy4yMDgxODVdIDJiZWZkIGlzIDJj
OWExMDAwIQ0KWyAgMjE3LjIwOTkwNF0gMmJlZmUgaXMgMmM5YTIwMDAhDQpbICAyMTcuMjEx
NjQxXSAyYmVmZiBpcyAyYzlhMzAwMCENClsgIDIxNy4yMTMzNDZdIDJiZjAwIGlzIDJjOWE0
MDAwIQ0KWyAgMjE3LjIxNTA4Nl0gMmJlZjYgaXMgMmM5OTAwMDAhDQpbICAyMTcuMjE2Nzk4
XSAyYmVmNSBpcyAyYzk5MTAwMCENClsgIDIxNy4yMTg1MDVdIDJiZWY0IGlzIDJjOTkyMDAw
IQ0KWyAgMjE3LjIyMDIxOF0gMmJlZjMgaXMgMmM5OTMwMDAhDQpbICAyMTcuMjIxOTE3XSAy
YmVmMiBpcyAyYzk5NDAwMCENClsgIDIxNy4yMjM2NDVdIDJiZWYxIGlzIDJjOTk1MDAwIQ0K
WyAgMjE3LjIyNTMzMl0gMmJlZjAgaXMgMmM5OTYwMDAhDQpbICAyMTcuMjI3MDQ4XSAyYmVl
ZiBpcyAyYzk5NzAwMCENClsgIDIxNy4yMjg3NDRdIDJiZWVlIGlzIDJjOTk4MDAwIQ0KWyAg
MjE3LjIzMDQzNF0gMmJlZWQgaXMgMmM5OTkwMDAhDQpbICAyMTcuMjMyMTIzXSAyYmYzOCBp
cyAyYzk5YTAwMCENClsgIDIxNy4yMzU1ODBdIDJiZjAyIGlzIDJkMTViMDAwIQ0KWyAgMjE3
LjIzNzMzOF0gMmJmMDMgaXMgMmQxNWMwMDAhDQpbICAyMTcuMjM5MDY0XSAyYmYwNCBpcyAy
ZDE1ZDAwMCENClsgIDIxNy4yNDA4MDZdIDJiZjA1IGlzIDJkMTVlMDAwIQ0KWyAgMjE3LjI0
MjUyMF0gMmJmMDYgaXMgMmQxNWYwMDAhDQpbICAyMTcuMjQ0MjU5XSAyYmY2NiBpcyAyZDE2
MDAwMCENClsgIDIxNy4yNDU5ODBdIDJiZjY3IGlzIDJkMTYxMDAwIQ0KWyAgMjE3LjI0Nzcx
OF0gMmJmNjggaXMgMmQxNjIwMDAhDQpbICAyMTcuMjQ5NDQyXSAyYmY2OSBpcyAyZDE2MzAw
MCENClsgIDIxNy4yNTExNjZdIDJiZjZhIGlzIDJkMTY0MDAwIQ0KWyAgMjE3LjI1Mjg5N10g
MmJmMDEgaXMgMmQxNTAwMDAhDQpbICAyMTcuMjU0NjI2XSAyYmYzOSBpcyAyZDE1MTAwMCEN
ClsgIDIxNy4yNTYzNzFdIDJiZjNhIGlzIDJkMTUyMDAwIQ0KWyAgMjE3LjI1ODEwNl0gMmJm
M2IgaXMgMmQxNTMwMDAhDQpbICAyMTcuMjU5ODIyXSAyYmYzYyBpcyAyZDE1NDAwMCENClsg
IDIxNy4yNjE1NzldIDJiZjNkIGlzIDJkMTU1MDAwIQ0KWyAgMjE3LjI2MzMwMV0gMmJmM2Ug
aXMgMmQxNTYwMDAhDQpbICAyMTcuMjY1MDYxXSAyYmYzZiBpcyAyZDE1NzAwMCENClsgIDIx
Ny4yNjY3OTddIDJiZjQwIGlzIDJkMTU4MDAwIQ0KWyAgMjE3LjI2ODUyN10gMmJmNDEgaXMg
MmQxNTkwMDAhDQpbICAyMTcuMjcwMjUxXSAyYmY0MiBpcyAyZDE1YTAwMCENClsgIDIxNy4y
NzE5NDddIDJiZjZiIGlzIDJkMTQ1MDAwIQ0KWyAgMjE3LjI3MzY4NV0gMmJmNmMgaXMgMmQx
NDYwMDAhDQpbICAyMTcuMjc1NDMwXSAyYmY2ZCBpcyAyZDE0NzAwMCENClsgIDIxNy4yNzcx
NjNdIDJiZjZlIGlzIDJkMTQ4MDAwIQ0KWyAgMjE3LjI3ODg3MF0gMmJmNmYgaXMgMmQxNDkw
MDAhDQpbICAyMTcuMjgwNTkxXSAyYmY3MCBpcyAyZDE0YTAwMCENClsgIDIxNy4yODIzMjZd
IDJiZjcxIGlzIDJkMTRiMDAwIQ0KWyAgMjE3LjI4NDA1M10gMmJmNzIgaXMgMmQxNGMwMDAh
DQpbICAyMTcuMjg1NzkwXSAyYmY3MyBpcyAyZDE0ZDAwMCENClsgIDIxNy4yODc1MjNdIDJi
Zjc0IGlzIDJkMTRlMDAwIQ0KWyAgMjE3LjI4OTI0Nl0gMmJmNzUgaXMgMmQxNGYwMDAhDQpb
ICAyMTcuMjkwOTQ0XSAyYmY0ZiBpcyAyZDE2NTAwMCENClsgIDIxNy4yOTI2NDBdIDJiZjRl
IGlzIDJkMTY2MDAwIQ0KWyAgMjE3LjI5NDM2MV0gMmJmNGQgaXMgMmQxNjcwMDAhDQpbICAy
MTcuMjk2MDQ3XSAyYmY0YyBpcyAyZDE2ODAwMCENClsgIDIxNy4yOTc3NTldIDJiZjRiIGlz
IDJkMTY5MDAwIQ0KWyAgMjE3LjI5OTQzOF0gMmJmNGEgaXMgMmQxNmEwMDAhDQpbICAyMTcu
MzAxMTMwXSAyYmY0OSBpcyAyZDE2YjAwMCENClsgIDIxNy4zMDI4MzFdIDJiZjQ4IGlzIDJk
MTZjMDAwIQ0KWyAgMjE3LjMwNDUyM10gMmJmNDUgaXMgMmQxNmQwMDAhDQpbICAyMTcuMzA2
MjEyXSAyYmY0NCBpcyAyZDE2ZTAwMCENClsgIDIxNy4zMDc4ODddIDJiZjQzIGlzIDJkMTZm
MDAwIQ0KWyAgMjE3LjMwOTU0NF0gMmJmNzYgaXMgMmQxM2IwMDAhDQpbICAyMTcuMzExMjQx
XSAyYmY3NyBpcyAyZDEzYzAwMCENClsgIDIxNy4zMTI5MDldIDJiZjc4IGlzIDJkMTNkMDAw
IQ0KWyAgMjE3LjMxNDYwNl0gMmJmNzkgaXMgMmQxM2UwMDAhDQpbICAyMTcuMzE2MjYzXSAy
YmY3YSBpcyAyZDEzZjAwMCENClsgIDIxNy4zMTc5MzJdIDJiZjdiIGlzIDJkMTQwMDAwIQ0K
WyAgMjE3LjMxOTYxNl0gMmJmN2MgaXMgMmQxNDEwMDAhDQpbICAyMTcuMzIxMjkxXSAyYmY3
ZCBpcyAyZDE0MjAwMCENClsgIDIxNy4zMjI5ODBdIDJiZjdlIGlzIDJkMTQzMDAwIQ0KWyAg
MjE3LjMyNDY2M10gMmJmN2YgaXMgMmQxNDQwMDAhDQpbICAyMTcuMzMxNTUzXSAyYmY4MCBp
cyAyZDEzYTAwMCENClsgIDIxNy4zMzU1NTddIDJiZjUwIGlzIDJkMTM2MDAwIQ0KWyAgMjE3
LjMzNzI5NF0gMmJmODEgaXMgMmQxMzcwMDAhDQpbICAyMTcuMzM4OTY5XSAyYmY4MiBpcyAy
ZDEzODAwMCENClsgIDIxNy4zNDA2ODZdIDJiZjgzIGlzIDJkMTM5MDAwIQ0KWyAgMjE3LjM0
MzA2N10gMmJmODQgaXMgMmQxMmUwMDAhDQpbICAyMTcuMzQ0ODgwXSAyYmY4NSBpcyAyZDEy
ZjAwMCENClsgIDIxNy4zNDY1NjNdIDJiZjg2IGlzIDJkMTMwMDAwIQ0KWyAgMjE3LjM0ODQ2
MF0gMmJmODcgaXMgMmQxMzEwMDAhDQpbICAyMTcuMzUwMjEwXSAyYmY4OCBpcyAyZDEzMjAw
MCENClsgIDIxNy4zNTE4OTJdIDJiZjg5IGlzIDJkMTMzMDAwIQ0KWyAgMjE3LjM1MzU2NV0g
MmJmOGEgaXMgMmQxMzQwMDAhDQpbICAyMTcuMzU1MjIzXSAyYmY4YiBpcyAyZDEzNTAwMCEN
ClsgIDIxNy4zNTc3MTddIDJiZjk3IGlzIDJkMTFlMDAwIQ0KWyAgMjE3LjM1OTQwMl0gMmJm
OTggaXMgMmQxMWYwMDAhDQpbICAyMTcuMzYxMTExXSAyYmY5OSBpcyAyZDEyMDAwMCENClsg
IDIxNy4zNjI4MzddIDJiZjlhIGlzIDJkMTIxMDAwIQ0KWyAgMjE3LjM2NDY0N10gMmJmOWIg
aXMgMmQxMjIwMDAhDQpbICAyMTcuMzY2NDY5XSAyYmY5NSBpcyAyZDExNDAwMCENClsgIDIx
Ny4zNjgyMTNdIDJiZjk0IGlzIDJkMTE1MDAwIQ0KWyAgMjE3LjM2OTkxNV0gMmJmOTMgaXMg
MmQxMTYwMDAhDQpbICAyMTcuMzcxNjE4XSAyYmY5MiBpcyAyZDExNzAwMCENClsgIDIxNy4z
NzMzMDddIDJiZjkxIGlzIDJkMTE4MDAwIQ0KWyAgMjE3LjM3NDk5MF0gMmJmOTAgaXMgMmQx
MTkwMDAhDQpbICAyMTcuMzc2NjgwXSAyYmY4ZiBpcyAyZDExYTAwMCENClsgIDIxNy4zNzgz
NzRdIDJiZjhlIGlzIDJkMTFiMDAwIQ0KWyAgMjE3LjM4MDA4NV0gMmJmOGQgaXMgMmQxMWMw
MDAhDQpbICAyMTcuMzgxNzgyXSAyYmY4YyBpcyAyZDExZDAwMCENClsgIDIxNy4zODM3MzJd
IDJiZjk2IGlzIDJkMGZkMDAwIQ0KWyAgMjE3LjM4NTQxOF0gMmJmOWMgaXMgMmQxMDgwMDAh
DQpbICAyMTcuMzg3MTA2XSAyYmY1MSBpcyAyZDEwOTAwMCENClsgIDIxNy4zODg3ODhdIDJi
ZjUyIGlzIDJkMTBhMDAwIQ0KWyAgMjE3LjM5MDQ4OV0gMmJmNTMgaXMgMmQxMGIwMDAhDQpb
ICAyMTcuMzkyMTY1XSAyYmY1NCBpcyAyZDEwYzAwMCENClsgIDIxNy4zOTM4NjldIDJiZjU1
IGlzIDJkMTBkMDAwIQ0KWyAgMjE3LjM5NTUzM10gMmJmNTYgaXMgMmQxMGUwMDAhDQpbICAy
MTcuMzk3MjA5XSAyYmY1NyBpcyAyZDEwZjAwMCENClsgIDIxNy4zOTg4ODBdIDJiZjU4IGlz
IDJkMTEwMDAwIQ0KWyAgMjE3LjQwMDU1Nl0gMmJmNTkgaXMgMmQxMTEwMDAhDQpbICAyMTcu
NDAyMjM3XSAyYmY1YSBpcyAyZDExMjAwMCENClsgIDIxNy40MDM5MjRdIDJiZjViIGlzIDJk
MGZlMDAwIQ0KWyAgMjE3LjQwNTYyMF0gMmJmNWMgaXMgMmQwZmYwMDAhDQpbICAyMTcuNDA3
MzEzXSAyYmY1ZCBpcyAyZDEwMDAwMCENClsgIDIxNy40MDkwMDZdIDJiZjVlIGlzIDJkMTAx
MDAwIQ0KWyAgMjE3LjQxMDcyMV0gMmJmNWYgaXMgMmQxMDIwMDAhDQpbICAyMTcuNDEyMzk5
XSAyYmY2MCBpcyAyZDEwMzAwMCENClsgIDIxNy40MTQxMTJdIDJiZjYxIGlzIDJkMTA0MDAw
IQ0KWyAgMjE3LjQxNTc4NV0gMmJmNjIgaXMgMmQxMDUwMDAhDQpbICAyMTcuNDE3NDcwXSAy
YmY2MyBpcyAyZDEwNjAwMCENClsgIDIxNy40MTkxNjZdIDJiZjY0IGlzIDJkMTA3MDAwIQ0K
WyAgMjE3LjQyMTQwOV0gMmJmYTQgaXMgMmQwZTUwMDAhDQpbICAyMTcuNDIzMTI3XSAyYmY2
NSBpcyAyZDBkZTAwMCENClsgIDIxNy40MjQ4NTRdIDJiZjlkIGlzIDJkMGRkMDAwIQ0KWyAg
MjE3LjQyNjU4MV0gMmJmOWUgaXMgMmQwZGMwMDAhDQpbICAyMTcuNDM4NTcwXSAyYmZhNSBp
cyAyZDBlZDAwMCENClsgIDIxNy40NDAzMzZdIDJiZmE2IGlzIDJkMGVlMDAwIQ0KWyAgMjE3
LjQ0MjA2Nl0gMmJmYTcgaXMgMmQwZWYwMDAhDQpbICAyMTcuNDQzODIyXSAyYmZhOCBpcyAy
ZDBmMDAwMCENClsgIDIxNy40NDU1NDZdIDJiZmE5IGlzIDJkMGY2MDAwIQ0KWyAgMjE3LjQ0
NzQ1OV0gMmJmYWEgaXMgMmQwZjUwMDAhDQpbICAyMTcuNDQ5MjAxXSAyYmZhYiBpcyAyZDBm
MzAwMCENClsgIDIxNy40NTA5NDRdIDJiZmFjIGlzIDJkMGY0MDAwIQ0KWyAgMjE3LjQ1NDQ0
Ml0gMmJmYzQgaXMgMmQwYzIwMDAhDQpbICAyMTcuNDU2MjA5XSAyYmZjNSBpcyAyZDBjMzAw
MCENClsgIDIxNy40NTc5NjVdIDJiZmM2IGlzIDJkMGM0MDAwIQ0KWyAgMjE3LjQ1OTcwN10g
MmJmYzcgaXMgMmQwYzUwMDAhDQpbICAyMTcuNDYxNDYwXSAyYmZjOCBpcyAyZDBjNjAwMCEN
ClsgIDIxNy40NjMyMDBdIDJiZmM5IGlzIDJkMGM3MDAwIQ0KWyAgMjE3LjQ2NDk2OF0gMmJm
Y2EgaXMgMmQwYzgwMDAhDQpbICAyMTcuNDY2NzE5XSAyYmZjYiBpcyAyZDBjOTAwMCENClsg
IDIxNy40Njg0NTFdIDJiZmNjIGlzIDJkMGNhMDAwIQ0KWyAgMjE3LjQ3MDE4N10gMmJmY2Qg
aXMgMmQwY2IwMDAhDQpbICAyMTcuNDcxODk3XSAyYmY5ZiBpcyAyZDBjYzAwMCENClsgIDIx
Ny40NzM2NDddIDJiZmEwIGlzIDJkMGNkMDAwIQ0KWyAgMjE3LjQ3NTM1Ml0gMmJmYTEgaXMg
MmQwY2UwMDAhDQpbICAyMTcuNDc3MDkzXSAyYmZhMiBpcyAyZDBjZjAwMCENClsgIDIxNy40
Nzg3OTJdIDJiZmEzIGlzIDJkMGQwMDAwIQ0KWyAgMjE3LjQ4MDUxOF0gMmJmYzMgaXMgMmQw
ZDEwMDAhDQpbICAyMTcuNDgyMjE3XSAyYmZiNyBpcyAyZDBkMjAwMCENClsgIDIxNy40ODM5
MzRdIDJiZmI2IGlzIDJkMGQzMDAwIQ0KWyAgMjE3LjQ4NTY1MF0gMmJmYjUgaXMgMmQwZDQw
MDAhDQpbICAyMTcuNDg3MzY4XSAyYmZiNCBpcyAyZDBkNTAwMCENClsgIDIxNy40ODkwNzFd
IDJiZmIzIGlzIDJkMGQ2MDAwIQ0KWyAgMjE3LjQ5MzM0M10gMmJmZDkgaXMgMmQwYTIwMDAh
DQpbICAyMTcuNDk1MTI5XSAyYmZkYSBpcyAyZDBhMzAwMCENClsgIDIxNy40OTY5NjJdIDJi
ZmRiIGlzIDJkMGE0MDAwIQ0KWyAgMjE3LjQ5ODY1OF0gMmJmZGMgaXMgMmQwYTUwMDAhDQpb
ICAyMTcuNTAwMzU1XSAyYmZkZCBpcyAyZDBhNjAwMCENClsgIDIxNy41MDIwNjVdIDJiZmRl
IGlzIDJkMGE3MDAwIQ0KWyAgMjE3LjUwMzc1M10gMmJmZGYgaXMgMmQwYTgwMDAhDQpbICAy
MTcuNTA1NDQ5XSAyYmZlMCBpcyAyZDBhOTAwMCENClsgIDIxNy41MDcxNTZdIDJiZmUxIGlz
IDJkMGFhMDAwIQ0KWyAgMjE3LjUwODg1MV0gMmJmZTIgaXMgMmQwYWIwMDAhDQpbICAyMTcu
NTEwOTU3XSAyYmZiMiBpcyAyZDA5NzAwMCENClsgIDIxNy41MTI2NDFdIDJiZmIxIGlzIDJk
MDk4MDAwIQ0KWyAgMjE3LjUxNDM0OV0gMmJmYjAgaXMgMmQwOTkwMDAhDQpbICAyMTcuNTE2
MDEyXSAyYmZhZiBpcyAyZDA5YTAwMCENClsgIDIxNy41MTc2OTJdIDJiZmFlIGlzIDJkMDli
MDAwIQ0KWyAgMjE3LjUxOTM2Ml0gMmJmYWQgaXMgMmQwOWMwMDAhDQpbICAyMTcuNTIxMDQ1
XSAyYmZiYyBpcyAyZDA5ZDAwMCENClsgIDIxNy41MjI3MjhdIDJiZmJiIGlzIDJkMDllMDAw
IQ0KWyAgMjE3LjUyNDQwNV0gMmJmYmEgaXMgMmQwOWYwMDAhDQpbICAyMTcuNTI2MDgwXSAy
YmZiOSBpcyAyZDBhMDAwMCENClsgIDIxNy41Mjc3NzVdIDJiZmI4IGlzIDJkMGExMDAwIQ0K
WyAgMjE3LjUyOTQ1OF0gMmJmZTMgaXMgMmQwOGMwMDAhDQpbICAyMTcuNTMxMTU3XSAyYmZi
ZCBpcyAyZDA4ZDAwMCENClsgIDIxNy41MzI4MjldIDJiZmJlIGlzIDJkMDhlMDAwIQ0KWyAg
MjE3LjUzNDUxNV0gMmJmYmYgaXMgMmQwOGYwMDAhDQpbICAyMTcuNTM2MjA1XSAyYmZjMCBp
cyAyZDA5MDAwMCENClsgIDIxNy41Mzc4OTNdIDJiZmMxIGlzIDJkMDkxMDAwIQ0KWyAgMjE3
LjUzOTU4M10gMmJmYzIgaXMgMmQwOTIwMDAhDQpbICAyMTcuNTQxMjY1XSAyYjgwMSBpcyAy
ZDA5MzAwMCENClsgIDIxNy41NDI5NjRdIDJiODAyIGlzIDJkMDk0MDAwIQ0KWyAgMjE3LjU0
NDY1N10gMmI4MDMgaXMgMmQwOTUwMDAhDQpbICAyMTcuNTQ2MzM1XSAyYjgwNCBpcyAyZDA5
NjAwMCENClsgIDIxNy41NDgwMjhdIDJiODA1IGlzIDJkMDgyMDAwIQ0KWyAgMjE3LjU0OTY5
Nl0gMmI4MDYgaXMgMmQwODMwMDAhDQpbICAyMTcuNTUxMzkyXSAyYjgwNyBpcyAyZDA4NDAw
MCENClsgIDIxNy41NTMwNThdIDJiODA4IGlzIDJkMDg1MDAwIQ0KWyAgMjE3LjU1NDczM10g
MmI4MDkgaXMgMmQwODYwMDAhDQpbICAyMTcuNTU2NDE2XSAyYjgwYSBpcyAyZDA4NzAwMCEN
ClsgIDIxNy41NTgwOTldIDJiODBiIGlzIDJkMDg4MDAwIQ0KWyAgMjE3LjU1OTc3NF0gMmI4
MGMgaXMgMmQwODkwMDAhDQpbICAyMTcuNTYxNDUwXSAyYjgwZCBpcyAyZDA4YTAwMCENClsg
IDIxNy41NjMxMjNdIDJiODBlIGlzIDJkMDhiMDAwIQ0KWyAgMjE3LjU2NDgxOV0gMmJmY2Ug
aXMgMmQwYWMwMDAhDQpbICAyMTcuNTY2NDk4XSAyYmZjZiBpcyAyZDBhZDAwMCENClsgIDIx
Ny41NjgyMTNdIDJiZmQwIGlzIDJkMGFlMDAwIQ0KWyAgMjE3LjU2OTg5OF0gMmJmZDEgaXMg
MmQwYWYwMDAhDQpbICAyMTcuNTcxNjAzXSAyYmZkMiBpcyAyZDBiMDAwMCENClsgIDIxNy41
NzMzMjddIDJiZmQzIGlzIDJkMGIxMDAwIQ0KWyAgMjE3LjU3NTAzN10gMmJmZDQgaXMgMmQw
YjIwMDAhDQpbICAyMTcuNTc2NzYwXSAyYmZkNSBpcyAyZDBiMzAwMCENClsgIDIxNy41Nzg0
NDldIDJiZmQ2IGlzIDJkMGI0MDAwIQ0KWyAgMjE3LjU4MDE0OF0gMmJmZDcgaXMgMmQwYjUw
MDAhDQpbICAyMTcuNTgxODQ5XSAyYmZkOCBpcyAyZDBiWyAgMjE5LjcwOTEwNl0gMmI0ZDUg
aXMgMmQyMjkwMDAhDQpbICAyMTkuNzEwODEzXSAyYjRkNCBpcyAyZDIyYTAwMCENClsgIDIx
OS43MTI5NjFdIDJiNGI1IGlzIDJkMjBiMDAwIQ0KWyAgMjE5LjcxNDcxNF0gMmI0YjYgaXMg
MmQyMGMwMDAhDQpbICAyMTkuNzE2NDIwXSAyYjRiNyBpcyAyZDIwZDAwMCENClsgIDIxOS43
MTgxMzldIDJiNGI4IGlzIDJkMjBlMDAwIQ0KWyAgMjE5LjcxOTg2MF0gMmI0YjkgaXMgMmQy
MGYwMDAhDQpbICAyMTkuNzIxNTY4XSAyYjRiYSBpcyAyZDIxMDAwMCENClsgIDIxOS43MjMy
ODRdIDJiNGJiIGlzIDJkMjExMDAwIQ0KWyAgMjE5LjcyNDk5MF0gMmI0YmMgaXMgMmQyMTIw
MDAhDQpbICAyMTkuNzI2Njg5XSAyYjRiZCBpcyAyZDIxMzAwMCENClsgIDIxOS43Mjg0MTdd
IDJiNGJlIGlzIDJkMjE0MDAwIQ0KWyAgMjE5LjczMDEyMl0gMmI0Y2EgaXMgMmQxZjUwMDAh
DQpbICAyMTkuNzMxODM5XSAyYjRjYiBpcyAyZDFmNjAwMCENClsgIDIxOS43MzM1NTVdIDJi
NGNjIGlzIDJkMWY3MDAwIQ0KWyAgMjE5LjczNTI2Ml0gMmI0Y2QgaXMgMmQxZjgwMDAhDQpb
ICAyMTkuNzM2OTYxXSAyYjRlZCBpcyAyZDFmOTAwMCENClsgIDIxOS43Mzg2MzddIDJiNGYw
IGlzIDJkMWZhMDAwIQ0KWyAgMjE5Ljc0MDM1M10gMmI0ZjEgaXMgMmQxZmIwMDAhDQpbICAy
MTkuNzQyMDM2XSAyYjRmMiBpcyAyZDFmYzAwMCENClsgIDIxOS43NDM3NDVdIDJiNGYzIGlz
IDJkMWZkMDAwIQ0KWyAgMjE5Ljc0NTQyNl0gMmI0ZjQgaXMgMmQxZmUwMDAhDQpbICAyMTku
NzQ3MTE5XSAyYjRmNSBpcyAyZDFmZjAwMCENClsgIDIxOS43NDg4MTFdIDJiNGY2IGlzIDJk
MWViMDAwIQ0KWyAgMjE5Ljc1MDQ5OF0gMmI0ZjcgaXMgMmQxZWMwMDAhDQpbICAyMTkuNzUy
MTkzXSAyYjRmOCBpcyAyZDFlZDAwMCENClsgIDIxOS43NTM4NzldIDJiNGY5IGlzIDJkMWVl
MDAwIQ0KWyAgMjE5Ljc1NTUzOV0gMmI0ZmEgaXMgMmQxZWYwMDAhDQpbICAyMTkuNzU3MjI0
XSAyYjRmYiBpcyAyZDFmMDAwMCENClsgIDIxOS43NTg4ODVdIDJiNGZjIGlzIDJkMWYxMDAw
IQ0KWyAgMjE5Ljc2MDU4NF0gMmI0ZmQgaXMgMmQxZjIwMDAhDQpbICAyMTkuNzYyMjUxXSAy
YjRmZSBpcyAyZDFmMzAwMCENClsgIDIxOS43NjM5MzddIDJiNGZmIGlzIDJkMWY0MDAwIQ0K
WyAgMjE5Ljc2NTY4MV0gMmI0YmYgaXMgMmQyMDAwMDAhDQpbICAyMTkuNzY3MzY0XSAyYjRj
MCBpcyAyZDIwMTAwMCENClsgIDIxOS43NjkwNTRdIDJiNGMxIGlzIDJkMjAyMDAwIQ0KWyAg
MjE5Ljc3MDczNV0gMmI0YzIgaXMgMmQyMDMwMDAhDQpbICAyMTkuNzcyNDA3XSAyYjRjMyBp
cyAyZDIwNDAwMCENClsgIDIxOS43NzQxMTFdIDJiNGM0IGlzIDJkMjA1MDAwIQ0KWyAgMjE5
Ljc3NTc3N10gMmI0YzUgaXMgMmQyMDYwMDAhDQpbICAyMTkuNzc3NDc1XSAyYjRjNiBpcyAy
ZDIwNzAwMCENClsgIDIxOS43NzkxMzZdIDJiNGM3IGlzIDJkMjA4MDAwIQ0KWyAgMjE5Ljc4
MDgxMV0gMmI0YzggaXMgMmQyMDkwMDAhDQpbICAyMTkuNzgyNTMzXSAyYjRjOSBpcyAyZDIw
YTAwMCENClsgIDIxOS43ODQyMThdIDJiNGFmIGlzIDJkMjE1MDAwIQ0KWyAgMjE5Ljc4NTg5
MF0gMmI0YjAgaXMgMmQyMTYwMDAhDQpbICAyMTkuNzg3NTY1XSAyYjRiMSBpcyAyZDIxNzAw
MCENClsgIDIxOS43ODkyMjddIDJiNGIyIGlzIDJkMjE4MDAwIQ0KWyAgMjE5Ljc5MDk0OF0g
MmI0YjMgaXMgMmQyMTkwMDAhDQpbICAyMTkuNzkyNjE2XSAyYjRiNCBpcyAyZDIxYTAwMCEN
ClsgIDIxOS43OTQzMDddIDJiNGUzIGlzIDJkMjFiMDAwIQ0KWyAgMjE5Ljc5NTk3NF0gMmI0
ZTIgaXMgMmQyMWMwMDAhDQpbICAyMTkuNzk3NjY5XSAyYjRlMSBpcyAyZDIxZDAwMCENClsg
IDIxOS43OTkzMzZdIDJiNGUwIGlzIDJkMjFlMDAwIQ0KWyAgMjE5LjgwMTAxNl0gMmI0ZGYg
aXMgMmQyMWYwMDAhDQpbICAyMTkuODE5NDk1XSAzN2U4YSBpcyAyZDFlMDAwMCENClsgIDIx
OS44MjEyOTVdIDM2ZGY5IGlzIDJkMWUxMDAwIQ0KWyAgMjE5LjgyMzA0N10gMzdmOTcgaXMg
MmQxZTIwMDAhDQpbICAyMTkuODI0ODEyXSAyYjUwMCBpcyAyZDFlMzAwMCENClsgIDIxOS44
MjY1ODhdIDJiNTAxIGlzIDJkMWU0MDAwIQ0KWyAgMjE5LjgyODM4OV0gMmI1MDIgaXMgMmQx
ZTUwMDAhDQpbICAyMTkuODMwMjcyXSAyYjUwMyBpcyAyZDFlNjAwMCENClsgIDIxOS44MzIx
NDBdIDJiNTA0IGlzIDJkMWU3MDAwIQ0KWyAgMjE5LjgzMzkzM10gMmI1MDUgaXMgMmQxZTgw
MDAhDQpbICAyMTkuODM1NzIzXSAyYjUwNiBpcyAyZDFlOTAwMCENClsgIDIxOS44Mzc0OTld
IDJiNTA3IGlzIDJkMWVhMDAwIQ0KWyAgMjE5LjgzOTY4NF0gMmI1MTMgaXMgMmQxY2IwMDAh
DQpbICAyMTkuODQxNDk3XSAyYjUxNCBpcyAyZDFjYzAwMCENClsgIDIxOS44NDMyNjddIDJi
NTE1IGlzIDJkMWNkMDAwIQ0KWyAgMjE5Ljg0NTA4N10gMmI1MTYgaXMgMmQxY2UwMDAhDQpb
ICAyMTkuODQ2ODY3XSAyYjUxNyBpcyAyZDFjZjAwMCENClsgIDIxOS44NDg2NDVdIDJiNTE4
IGlzIDJkMWQwMDAwIQ0KWyAgMjE5Ljg1MDQyN10gMmI1MTkgaXMgMmQxZDEwMDAhDQpbICAy
MTkuODUyMjIxXSAyYjUxYSBpcyAyZDFkMjAwMCENClsgIDIxOS44NTM5OTddIDJiNTFiIGlz
IDJkMWQzMDAwIQ0KWyAgMjE5Ljg1NTc1M10gMmI1MWMgaXMgMmQxZDQwMDAhDQpbICAyMTku
ODU3NTQ3XSAyYjUxZCBpcyAyZDFjMDAwMCENClsgIDIxOS44NTkyOTFdIDJiNTFlIGlzIDJk
MWMxMDAwIQ0KWyAgMjE5Ljg2MTA4MF0gMmI1MWYgaXMgMmQxYzIwMDAhDQpbICAyMTkuODYy
ODMxXSAyYjUyMCBpcyAyZDFjMzAwMCENClsgIDIxOS44NjQ2MjddIDJiNTIxIGlzIDJkMWM0
MDAwIQ0KWyAgMjE5Ljg2NjM3OF0gMmI1MjIgaXMgMmQxYzUwMDAhDQpbICAyMTkuODY4MTQz
XSAyYjUyMyBpcyAyZDFjNjAwMCENClsgIDIxOS44Njk5MjBdIDJiNTI0IGlzIDJkMWM3MDAw
IQ0KWyAgMjE5Ljg3MTY3Nl0gMmI1MjUgaXMgMmQxYzgwMDAhDQpbICAyMTkuODczNDY1XSAy
YjUyNiBpcyAyZDFjOTAwMCENClsgIDIxOS44NzUyMDFdIDJiNTI3IGlzIDJkMWNhMDAwIQ0K
WyAgMjE5Ljg3NjkzN10gMmI1MjggaXMgMmQxYjUwMDAhDQpbICAyMTkuODc4NjI2XSAyYjUy
OSBpcyAyZDFiNjAwMCENClsgIDIxOS44ODAzMTNdIDJiNTJhIGlzIDJkMWI3MDAwIQ0KWyAg
MjE5Ljg4MTk5M10gMmI1MmIgaXMgMmQxYjgwMDAhDQpbICAyMTkuODgzNjU3XSAyYjUyYyBp
cyAyZDFiOTAwMCENClsgIDIxOS44ODUzMzddIDJiNTJkIGlzIDJkMWJhMDAwIQ0KWyAgMjE5
Ljg4Njk5Nl0gMmI1MmUgaXMgMmQxYmIwMDAhDQpbICAyMTkuODg4NjQwXSAyYjUyZiBpcyAy
ZDFiYzAwMCENClsgIDIxOS44OTAzMjNdIDJiNTMwIGlzIDJkMWJkMDAwIQ0KWyAgMjE5Ljg5
MTk4NF0gMmI1MzEgaXMgMmQxYmUwMDAhDQpbICAyMTkuODkzNjg0XSAyYjUzMiBpcyAyZDFi
ZjAwMCENClsgIDIxOS44OTUzMjNdIDJiNTA4IGlzIDJkMWQ1MDAwIQ0KWyAgMjE5Ljg5Njk4
MV0gMmI1MDkgaXMgMmQxZDYwMDAhDQpbICAyMTkuODk4NjU2XSAyYjUwYSBpcyAyZDFkNzAw
MCENClsgIDIxOS45MDAzMjZdIDJiNTBiIGlzIDJkMWQ4MDAwIQ0KWyAgMjE5LjkwMjAxOF0g
MmI1MGMgaXMgMmQxZDkwMDAhDQpbICAyMTkuOTAzNjk0XSAyYjUwZCBpcyAyZDFkYTAwMCEN
ClsgIDIxOS45MDUzNDldIDJiNTBlIGlzIDJkMWRiMDAwIQ0KWyAgMjE5LjkwNzA1MF0gMmI1
MGYgaXMgMmQxZGMwMDAhDQpbICAyMTkuOTA4NzExXSAyYjUxMCBpcyAyZDFkZDAwMCENClsg
IDIxOS45MTA0MThdIDJiNTExIGlzIDJkMWRlMDAwIQ0KWyAgMjE5LjkxMjA3OV0gMmI1MTIg
aXMgMmQxZGYwMDAhDQpbICAyMTkuOTE1NTkzXSAyYjRlNSBpcyAyZDE5NjAwMCENClsgIDIx
OS45MTczNDhdIDJiNGU2IGlzIDJkMTk3MDAwIQ0KWyAgMjE5LjkxOTEwM10gMmI0ZTcgaXMg
MmQxOTgwMDAhDQpbICAyMTkuOTIwNzk2XSAyYjRlOCBpcyAyZDE5OTAwMCENClsgIDIxOS45
MjI1MDFdIDJiNGU5IGlzIDJkMTlhMDAwIQ0KWyAgMjE5LjkyNDE5OV0gMmI0ZWEgaXMgMmQx
OWIwMDAhDQpbICAyMTkuOTI1OTI4XSAyYjRlYiBpcyAyZDE5YzAwMCENClsgIDIxOS45Mjc3
MTNdIDJiNGVjIGlzIDJkMTlkMDAwIQ0KWyAgMjE5LjkyOTQxMl0gMmI1NGMgaXMgMmQxOWUw
MDAhDQpbICAyMTkuOTMxMTE5XSAyYjU0ZCBpcyAyZDE5ZjAwMCENClsgIDIxOS45MzI3ODRd
IDJiNTRlIGlzIDJkMThiMDAwIQ0KWyAgMjE5LjkzNDQ3OF0gMmI1NGYgaXMgMmQxOGMwMDAh
DQpbICAyMTkuOTM2MTU4XSAyYjU1MCBpcyAyZDE4ZDAwMCENClsgIDIxOS45Mzc4NTJdIDJi
NTUxIGlzIDJkMThlMDAwIQ0KWyAgMjE5LjkzOTUzMl0gMmI1NTIgaXMgMmQxOGYwMDAhDQpb
ICAyMTkuOTQxMjE1XSAyYjU1MyBpcyAyZDE5MDAwMCENClsgIDIxOS45NDI4OTJdIDJiNTU0
IGlzIDJkMTkxMDAwIQ0KWyAgMjE5Ljk0NDYwNF0gMmI1NTUgaXMgMmQxOTIwMDAhDQpbICAy
MTkuOTQ2MjY4XSAyYjU1NiBpcyAyZDE5MzAwMCENClsgIDIxOS45NDc5NjddIDJiNTU3IGlz
IDJkMTk0MDAwIQ0KWyAgMjE5Ljk1MDAwMV0gMmI0ZTQgaXMgMmQ5NmIwMDAhDQpbICAyMTku
OTUxNzcyXSAyYjUzMyBpcyAyZDk4MDAwMCENClsgIDIxOS45NTM1MDhdIDJiNTM0IGlzIDJk
OTgxMDAwIQ0KWyAgMjE5Ljk1NTIyMl0gMmI1MzUgaXMgMmQ5ODIwMDAhDQpbICAyMTkuOTU2
OTY0XSAyYjUzNiBpcyAyZDk4MzAwMCENClsgIDIxOS45NTg2NzNdIDJiNTM3IGlzIDJkOTg0
MDAwIQ0KWyAgMjE5Ljk2MDQxNV0gMmI1MzggaXMgMmQxODUwMDAhDQpbICAyMTkuOTYyMTQz
XSAyYjUzOSBpcyAyZDE4NjAwMCENClsgIDIxOS45NjM4ODFdIDJiNTNhIGlzIDJkMTg3MDAw
IQ0KWyAgMjE5Ljk2NTYyMF0gMmI1M2IgaXMgMmQxODgwMDAhDQpbICAyMTkuOTY3MzQzXSAy
YjUzYyBpcyAyZDE4OTAwMCENClsgIDIxOS45NjkwOThdIDJiNTNkIGlzIDJkMThhMDAwIQ0K
WyAgMjE5Ljk3MDc5Nl0gMmI1NTggaXMgMmQ5NzgwMDAhDQpbICAyMTkuOTcyNTIzXSAyYjU1
OSBpcyAyZDk3OTAwMCENClsgIDIxOS45NzQyMzhdIDJiNTVhIGlzIDJkOTdhMDAwIQ0KWyAg
MjE5Ljk3NTkzM10gMmI1NWIgaXMgMmQ5N2IwMDAhDQpbICAyMTkuOTc3NjYzXSAyYjU1YyBp
cyAyZDk3YzAwMCENClsgIDIxOS45NzkzNDddIDJiNTVkIGlzIDJkOTdkMDAwIQ0KWyAgMjE5
Ljk4MTA3MF0gMmI1NWUgaXMgMmQ5N2UwMDAhDQpbICAyMTkuOTgyNzYwXSAyYjU1ZiBpcyAy
ZDk3ZjAwMCENClsgIDIxOS45ODQ0NThdIDJiNTZiIGlzIDJkOTZjMDAwIQ0KWyAgMjE5Ljk4
NjE3N10gMmI1NjAgaXMgMmQ5NmQwMDAhDQpbICAyMTkuOTg3ODgyXSAyYjU2MSBpcyAyZDk2
ZTAwMCENClsgIDIxOS45ODk1OThdIDJiNTYyIGlzIDJkOTZmMDAwIQ0KWyAgMjE5Ljk5MTMw
MV0gMmI1NjMgaXMgMmQ5NzAwMDAhDQpbICAyMTkuOTkzMDA4XSAyYjU2NCBpcyAyZDk3MTAw
MCENClsgIDIxOS45OTQ3NTVdIDJiNTY1IGlzIDJkOTcyMDAwIQ0KWyAgMjE5Ljk5NjQ1MF0g
MmI1NjYgaXMgMmQ5NzMwMDAhDQpbICAyMTkuOTk4MTgwXSAyYjU2NyBpcyAyZDk3NDAwMCEN
ClsgIDIxOS45OTk4NjRdIDJiNTY4IGlzIDJkOTc1MDAwIQ0KWyAgMjIwLjAwMTU4Nl0gMmI1
NjkgaXMgMmQ5NzYwMDAhDQpbICAyMjAuMDAzMzAwXSAyYjU2YSBpcyAyZDk3NzAwMCENClsg
IDIyMC4wMDU1MzJdIDJiNTNmIGlzIDJkOTY3MDAwIQ0KWyAgMjIwLjAwNzMxNV0gMmI1NDAg
aXMgMmQ5NjgwMDAhDQpbICAyMjAuMDA5MDE3XSAyYjU0MSBpcyAyZDk2OTAwMCENClsgIDIy
MC4wMTA3NDVdIDJiNTQyIGlzIDJkOTZhMDAwIQ0KWyAgMjIwLjAxMzg5NV0gMmI1NDMgaXMg
MmQ5NWYwMDAhDQpbICAyMjAuMDE1NTg1XSAyYjU0NCBpcyAyZDk2MDAwMCENClsgIDIyMC4w
MTcyNzhdIDJiNTQ1IGlzIDJkOTYxMDAwIQ0KWyAgMjIwLjAxODk5MV0gMmI1NDYgaXMgMmQ5
NjIwMDAhDQpbICAyMjAuMDIwNjg1XSAyYjU0NyBpcyAyZDk2MzAwMCENClsgIDIyMC4wMjIz
OTRdIDJiNTQ4IGlzIDJkOTY0MDAwIQ0KWyAgMjIwLjAyNDA5OV0gMmI1NDkgaXMgMmQ5NjUw
MDAhDQpbICAyMjAuMDI1Nzc4XSAyYjU0YSBpcyAyZDk2NjAwMCENClsgIDIyMC4wMjgyNjFd
IDJiNTc2IGlzIDJkOTRmMDAwIQ0KWyAgMjIwLjAyOTk1NF0gMmI1NzcgaXMgMmQ5NTAwMDAh
DQpbICAyMjAuMDMxNjYwXSAyYjU3OCBpcyAyZDk1MTAwMCENClsgIDIyMC4wMzMzNDBdIDJi
NTc5IGlzIDJkOTUyMDAwIQ0KWyAgMjIwLjAzNTA0OF0gMmI1N2EgaXMgMmQ5NTMwMDAhDQpb
ICAyMjAuMDM4NDc1XSAyYjU3YyBpcyAyZDkzOTAwMCENClsgIDIyMC4wNDAyNDBdIDJiNTdk
IGlzIDJkOTNhMDAwIQ0KWyAgMjIwLjA0MTk1OV0gMmI1N2UgaXMgMmQ5M2IwMDAhDQpbICAy
MjAuMDQzNzA0XSAyYjU3ZiBpcyAyZDkzYzAwMCENClsgIDIyMC4wNDUzNzddIDJiNTgwIGlz
IDJkOTNkMDAwIQ0KWyAgMjIwLjA0NzA3Ml0gMmI1ODEgaXMgMmQ5M2UwMDAhDQpbICAyMjAu
MDQ4NzYxXSAyYjU4MiBpcyAyZDkzZjAwMCENClsgIDIyMC4wNTA0NDBdIDJiNTgzIGlzIDJk
OTQwMDAwIQ0KWyAgMjIwLjA1MjEzNl0gMmI1ODQgaXMgMmQ5NDEwMDAhDQpbICAyMjAuMDUz
ODMwXSAyYjU4NSBpcyAyZDk0MjAwMCENClsgIDIyMC4wNTU1MjJdIDJiNTg2IGlzIDJkOTQz
MDAwIQ0KWyAgMjIwLjA1NzY0MF0gMmI1OTEgaXMgMmQ5MTkwMDAhDQpbICAyMjAuMDU5MzUx
XSAyYjU5MiBpcyAyZDkxYTAwMCENClsgIDIyMC4wNjEwODRdIDJiNTkzIGlzIDJkOTFiMDAw
IQ0KWyAgMjIwLjA2Mjc4NF0gMmI1OTQgaXMgMmQ5MWMwMDAhDQpbICAyMjAuMDY0NTAzXSAy
YjU5NSBpcyAyZDkxZDAwMCENClsgIDIyMC4wNjYxNzBdIDJiNTk2IGlzIDJkOTFlMDAwIQ0K
WyAgMjIwLjA2Nzg1M10gMmI1OTcgaXMgMmQ5MWYwMDAhDQpbICAyMjAuMDY5NTU3XSAyYjU5
OCBpcyAyZDkyMDAwMCENClsgIDIyMC4wNzEyMzRdIDJiNTk5IGlzIDJkOTIxMDAwIQ0KWyAg
MjIwLjA3MjkyNF0gMmI1OWEgaXMgMmQ5MjIwMDAhDQpbICAyMjAuMDc0NjAwXSAyYjU5YiBp
cyAyZDkyMzAwMCENClsgIDIyMC4wNzYyNThdIDJiNTljIGlzIDJkOTBmMDAwIQ0KWyAgMjIw
LjA3Nzk2MV0gMmI1OWQgaXMgMmQ5MTAwMDAhDQpbICAyMjAuMDc5NjI1XSAyYjU5ZSBpcyAy
ZDkxMTAwMCENClsgIDIyMC4wODEzMzldIDJiNTlmIGlzIDJkOTEyMDAwIQ0KWyAgMjIwLjA4
MzAxNF0gMmI1YTAgaXMgMmQ5MTMwMDAhDQpbICAyMjAuMDg0NzI5XSAyYjVhMSBpcyAyZDkx
NDAwMCENClsgIDIyMC4wODYzOTNdIDJiNWEyIGlzIDJkOTE1MDAwIQ0KWyAgMjIwLjA4ODA3
M10gMmI1YTMgaXMgMmQ5MTYwMDAhDQpbICAyMjAuMDg5NzYzXSAyYjVhNCBpcyAyZDkxNzAw
MCENClsgIDIyMC4wOTE0MzJdIDJiNWE1IGlzIDJkOTE4MDAwIQ0KWyAgMjIwLjA5MzExMl0g
MmI1M2UgaXMgMmQ5MjQwMDAhDQpbICAyMjAuMDk0NzgyXSAyYjU2YyBpcyAyZDkyNTAwMCEN
ClsgIDIyMC4wOTY0NDRdIDJiNTZkIGlzIDJkOTI2MDAwIQ0KWyAgMjIwLjA5ODEzOV0gMmI1
NmUgaXMgMmQ5MjcwMDAhDQpbICAyMjAuMDk5Nzg5XSAyYjU2ZiBpcyAyZDkyODAwMCENClsg
IDIyMC4xMDE0NzddIDJiNTcwIGlzIDJkOTI5MDAwIQ0KWyAgMjIwLjEwMzE0NF0gMmI1NzEg
aXMgMmQ5MmEwMDAhDQpbICAyMjAuMTA0ODEzXSAyYjU3MiBpcyAyZDkyYjAwMCENClsgIDIy
MC4xMDY0OTRdIDJiNTczIGlzIDJkOTJjMDAwIQ0KWyAgMjIwLjEwODE2OV0gMmI1NzQgaXMg
MmQ5MmQwMDAhDQpbICAyMjAuMTA5ODU2XSAyYjU3NSBpcyAyZDkyZTAwMCENClsgIDIyMC4x
MTE1MjBdIDJiNTg3IGlzIDJkOTJmMDAwIQ0KWyAgMjIwLjExMzE4MV0gMmI1ODggaXMgMmQ5
MzAwMDAhDQpbICAyMjAuMTE0ODgxXSAyYjU4OSBpcyAyZDkzMTAwMCENClsgIDIyMC4xMTY1
NDJdIDJiNThhIGlzIDJkOTMyMDAwIQ0KWyAgMjIwLjExODI0NF0gMmI1OGIgaXMgMmQ5MzMw
MDAhDQpbICAyMjAuMTE5ODk4XSAyYjU4YyBpcyAyZDkzNDAwMCENClsgIDIyMC4xMjE1Njhd
IDJiNThkIGlzIDJkOTM1MDAwIQ0KWyAgMjIwLjEyMzI0OF0gMmI1OGUgaXMgMmQ5MzYwMDAh
DQpbICAyMjAuMTI0OTA1XSAyYjU4ZiBpcyAyZDkzNzAwMCENClsgIDIyMC4xMjY1NzldIDJi
NTkwIGlzIDJkOTM4MDAwIQ0KWyAgMjIwLjEyOTg2OF0gMmI1YjEgaXMgMmQ4ZjkwMDAhDQpb
ICAyMjAuMTMxNzIwXSAyYjViMiBpcyAyZDhmYTAwMCENClsgIDIyMC4xMzM0MzNdIDJiNWIz
IGlzIDJkOGZiMDAwIQ0KWyAgMjIwLjEzNTEzN10gMmI1YjQgaXMgMmQ4ZmMwMDAhDQpbICAy
MjAuMTM2ODE5XSAyYjViNSBpcyAyZDhmZDAwMCENClsgIDIyMC4xMzg0OTBdIDJiNWI2IGlz
IDJkOGZlMDAwIQ0KWyAgMjIwLjE0MDE5NV0gMmI1YjcgaXMgMmQ4ZmYwMDAhDQpbICAyMjAu
MTQxODU2XSAyYjViOCBpcyAyZDkwMDAwMCENClsgIDIyMC4xNDM1NzJdIDJiNWI5IGlzIDJk
OTAxMDAwIQ0KWyAgMjIwLjE0NTI1N10gMmI1YmEgaXMgMmQ5MDIwMDAhDQpbICAyMjAuMTQ2
OTQ0XSAyYjViYiBpcyAyZDkwMzAwMCENClsgIDIyMC4xNDg2NDVdIDJiNWJjIGlzIDJkOGVm
MDAwIQ0KWyAgMjIwLjE1MDM0MV0gMmI1YmQgaXMgMmQ4ZjAwMDAhDQpbICAyMjAuMTUyMDI5
XSAyYjViZSBpcyAyZDhmMTAwMCENClsgIDIyMC4xNTM3MTZdIDJiNWJmIGlzIDJkOGYyMDAw
IQ0KWyAgMjIwLjE1NTQwOV0gMmI1YzAgaXMgMmQ4ZjMwMDAhDQpbICAyMjAuMTU3MDg5XSAy
YjVjMSBpcyAyZDhmNDAwMCENClsgIDIyMC4xNTg3NTFdIDJiNWMyIGlzIDJkOGY1MDAwIQ0K
WyAgMjIwLjE2MDQ0Ml0gMmI1YzMgaXMgMmQ4ZjYwMDAhDQpbICAyMjAuMTYyMTA5XSAyYjVj
NCBpcyAyZDhmNzAwMCENClsgIDIyMC4xNjM4MDRdIDJiNWM1IGlzIDJkOGY4MDAwIQ0KWyAg
MjIwLjE2NzE0OV0gMmI1ZGEgaXMgMmQ4YWYwMDAhDQpbICAyMjAuMTY4OTIwXSAyYjVkOSBp
cyAyZDhiMDAwMCENClsgIDIyMC4xNzA2MDVdIDJiNWQ4IGlzIDJkOGIxMDAwIQ0KWyAgMjIw
LjE3MjI5N10gMmI1ZDcgaXMgMmQ4YjIwMDAhDQpbICAyMjAuMTczOTk3XSAyYjVkNiBpcyAy
ZDhiMzAwMCENClsgIDIyMC4xNzU2NzBdIDJiNWQ1IGlzIDJkOGI0MDAwIQ0KWyAgMjIwLjE3
NzM3NF0gMmI1ZDQgaXMgMmQ4YjUwMDAhDQpbICAyMjAuMTc5MDQwXSAyYjVkMyBpcyAyZDhi
NjAwMCENClsgIDIyMC4xODA3NDNdIDJiNWQyIGlzIDJkOGI3MDAwIQ0KWyAgMjIwLjE4MjQx
Nl0gMmI1ZDEgaXMgMmQ4YjgwMDAhDQpbICAyMjAuMTg0MDk4XSAyYjVkMCBpcyAyZDhiOTAw
MCENClsgIDIyMC4xODU3NjRdIDJiNWNmIGlzIDJkOGJhMDAwIQ0KWyAgMjIwLjE4NzQyOF0g
MmI1Y2UgaXMgMmQ4YmIwMDAhDQpbICAyMjAuMTg5MDk1XSAyYjVjZCBpcyAyZDhiYzAwMCEN
ClsgIDIyMC4xOTA3NjRdIDJiNWNjIGlzIDJkOGJkMDAwIQ0KWyAgMjIwLjE5MjQyNV0gMmI1
Y2IgaXMgMmQ4YmUwMDAhDQpbICAyMjAuMTk0MTE3XSAyYjVjYSBpcyAyZDhiZjAwMCENClsg
IDIyMC4xOTU3NzhdIDJiNWM5IGlzIDJkOGMwMDAwIQ0KWyAgMjIwLjE5NzQ2NV0gMmI1Yzgg
aXMgMmQ4YzEwMDAhDQpbICAyMjAuMTk5MTE5XSAyYjVjNyBpcyAyZDhjMjAwMCENClsgIDIy
MC4yMDA3ODhdIDJiNWM2IGlzIDJkOGMzMDAwIQ0KWyAgMjIwLjIwNDA1N10gMmI1YTYgaXMg
MmQ4ODQwMDAhDQpbICAyMjAuMjA1NzkyXSAyYjVhNyBpcyAyZDg4NTAwMCENClsgIDIyMC4y
MDc1MDNdIDJiNWE4IGlzIDJkODg2MDAwIQ0KWyAgMjIwLjIwOTE5OF0gMmI1YTkgaXMgMmQ4
ODcwMDAhDQpbICAyMjAuMjEwOTA5XSAyYjVhYSBpcyAyZDg4ODAwMCENClsgIDIyMC4yMTI1
ODJdIDJiNWFiIGlzIDJkODg5MDAwIQ0KWyAgMjIwLjIxNDMxNV0gMmI1YWMgaXMgMmQ4OGEw
MDAhDQpbICAyMjAuMjE1OTk0XSAyYjVhZCBpcyAyZDg4YjAwMCENClsgIDIyMC4yMTc2NzVd
IDJiNWFlIGlzIDJkODhbICAyMjIuMzUyOTQxXSAyYjEwZiBpcyAyZGNmMzAwMCENClsgIDIy
Mi4zNTUwODddIDJiMTEwIGlzIDJkY2YyMDAwIQ0KWyAgMjIyLjM2MDE4MV0gMmIxMTEgaXMg
MmRjZjEwMDAhDQpbICAyMjIuMzYyMzUyXSAyYjExMiBpcyAyZGNmMDAwMCENClsgIDIyMi4z
NzM0MTJdIDJiMTEzIGlzIDJkY2VmMDAwIQ0KWyAgMjIyLjM3NTU1OV0gMmIxMTQgaXMgMmRj
ZWUwMDAhDQpbICAyMjIuMzc4ODg0XSAyYjExNSBpcyAyZGNlZDAwMCENClsgIDIyMi4zODEw
MDRdIDJiMTE2IGlzIDJkY2VjMDAwIQ0KWyAgMjIyLjM5MDg5Nl0gMmIxMzYgaXMgMmRjZWIw
MDAhDQpbICAyMjIuMzkzMDY2XSAyYjExYiBpcyAyZGNlYTAwMCENClsgIDIyMi40MDM4ODhd
IDJiMTM3IGlzIDJkY2U5MDAwIQ0KWyAgMjIyLjQwNjA3OV0gMmIxMzggaXMgMmRjZTgwMDAh
DQpbICAyMjIuNDE3MjcwXSAyYjEzOSBpcyAyZGNlNzAwMCENClsgIDIyMi40MTk1NTFdIDJi
MTFjIGlzIDJkY2U2MDAwIQ0KWyAgMjIyLjQyMTY3OF0gMmIxM2IgaXMgMmRjZTUwMDAhDQpb
ICAyMjIuNDI1MjA3XSAyYjEzYyBpcyAyZGNiZTAwMCENClsgIDIyMi40Mjc0MjJdIDJiMTNk
IGlzIDJkY2JmMDAwIQ0KWyAgMjIyLjQyOTU5OV0gMmIxMWQgaXMgMmRjYzAwMDAhDQpbICAy
MjIuNDMyMDEzXSAyYjExZSBpcyAyZGNjMTAwMCENClsgIDIyMi40MzQyOThdIDJiMTFmIGlz
IDJkY2MyMDAwIQ0KWyAgMjIyLjQzNjQ0M10gMmIxMjAgaXMgMmRjYzkwMDAhDQpbICAyMjIu
NDM4NTkzXSAyYjEzZSBpcyAyZGNkODAwMCENClsgIDIyMi40NDA4MTJdIDJiMTNmIGlzIDJk
Y2Q3MDAwIQ0KWyAgMjIyLjQ0MjkxNV0gMmIxMjEgaXMgMmRjZDkwMDAhDQpbICAyMjIuNDQ1
MTU3XSAyYjEyMiBpcyAyZGNkYTAwMCENClsgIDIyMi40NDczNzNdIDJiMTIzIGlzIDJkY2Q0
MDAwIQ0KWyAgMjIyLjQ0OTQ4NF0gMmIxMjQgaXMgMmRjZDMwMDAhDQpbICAyMjIuNDUxNjUw
XSAyYjEyNSBpcyAyZGNkMjAwMCENClsgIDIyMi40NTM4NjBdIDJiMTI2IGlzIDJkY2QxMDAw
IQ0KWyAgMjIyLjQ1NTkzNl0gMmIxMjcgaXMgMmRjY2YwMDAhDQpbICAyMjIuNDU4MTA2XSAy
YjEyOCBpcyAyZGNkNTAwMCENClsgIDIyMi40NjAyNDBdIDJiMTI5IGlzIDJkY2NjMDAwIQ0K
WyAgMjIyLjQ2MjM3MV0gMmIxMmEgaXMgMmRjYzgwMDAhDQpbICAyMjIuNDY0NTM2XSAyYjE0
MCBpcyAyZGNjMzAwMCENClsgIDIyMi40NjY2MzNdIDJiMTJiIGlzIDJkY2M0MDAwIQ0KWyAg
MjIyLjQ2ODc2Nl0gMmIxMmMgaXMgMmRjY2QwMDAhDQpbICAyMjIuNDcwODU1XSAyYjE0MSBp
cyAyZGNjZTAwMCENClsgIDIyMi40NzMwMzldIDJiMTQyIGlzIDJkY2Q2MDAwIQ0KWyAgMjIy
LjQ3NTE1OF0gMmIxMmQgaXMgMmRjY2EwMDAhDQpbICAyMjIuNDc3Mzg3XSAyYjE0MyBpcyAy
ZGNjYjAwMCENClsgIDIyMi40Nzk0OTNdIDJiMTJlIGlzIDJkNWU2MDAwIQ0KWyAgMjIyLjQ4
MTczMF0gMmIxMmYgaXMgMmRjZTIwMDAhDQpbICAyMjIuNTAxMjc1XSAyYjEzMCBpcyA3YTI0
MTAwMCENClsgIDIyMi41MTU0NjFdIDJiMTQ1IGlzIDdhMjBmMDAwIQ0KWyAgMjIyLjUyNDUy
OV0gMmIxNDYgaXMgN2EyMGYwMDAhDQpbICAyMjIuNTQ2MDUwXSAyYjE0NyBpcyA3OGY3NDAw
MCENClsgIDIyMi41NDc5MTNdIDJiMTQ4IGlzIDc4Zjc1MDAwIQ0KWyAgMjIyLjU0OTczMF0g
MmIxNDkgaXMgNzhmNzYwMDAhDQpbICAyMjIuNTgyMDIxXSAyYjE0YiBpcyA3YTY1ZjAwMCEN
ClsgIDIyMi41ODM4ODVdIDJiMTRjIGlzIDdhNjkxMDAwIQ0KWyAgMjIyLjYyNzM3MF0gMmIx
NGQgaXMgN2E2YTAwMDAhDQpbICAyMjIuNzU5NTI3XSAyYjE0ZSBpcyAyMTY4MDAwMCENClsg
IDIyMi43NjU1MzRdIDJiMTRmIGlzIDc5NDllMDAwIQ0KWyAgMjIyLjc5NjA4OF0gMmIxNTAg
aXMgN2E2MTAwMDAhDQpbICAyMjIuODEyMDg1XSAyYjE1MSBpcyAyMTYzNTAwMCENClsgIDIy
Mi44MjE2MTJdIDJiMTUyIGlzIDc4ZDMwMDAwIQ0KWyAgMjIyLjg1NTI3NF0gMmIxNTMgaXMg
N2EwNmEwMDAhDQpbICAyMjIuODczMTA3XSAyYjE1NCBpcyA3OGYwMDAwMCENClsgIDIyMi44
ODkyODddIDJiMTU1IGlzIDIxNWFhMDAwIQ0KWyAgMjIyLjg5NjUxMF0gMmIxNTggaXMgN2E3
MWMwMDAhDQpbICAyMjIuODk4NjAzXSAyYjE1OSBpcyAyMWU0MzAwMCENClsgIDIyMi45MDA2
OTNdIDJiMTVhIGlzIDc5NDY3MDAwIQ0KWyAgMjIyLjkwMzI0NV0gMmIxNWIgaXMgN2E2MjMw
MDAhDQpbICAyMjIuOTEwNTgyXSAyYjEzMSBpcyA3OGNlNzAwMCENClsgIDIyMi45Mzk0OTRd
IDJiMTVjIGlzIDIxYTQzMDAwIQ0KWyAgMjIyLjk0NjA2Nl0gMmIxNWQgaXMgN2E3NDMwMDAh
DQpbICAyMjIuOTQ4Mjc5XSAyYjEzMiBpcyA3OGNlMzAwMCENClsgIDIyMi45Njk2MjldIDJi
MTMzIGlzIDc4ZjFjMDAwIQ0KWyAgMjIyLjk3MTg3M10gMmIxNWUgaXMgMjFlMzIwMDAhDQpb
ICAyMjIuOTc0MTIzXSAyYjE1ZiBpcyAyMTYyNzAwMCENClsgIDIyMi45NzYzNTRdIDJiMTYw
IGlzIDdhNmIzMDAwIQ0KWyAgMjIyLjk4MzA3NF0gMmIxNjIgaXMgNzhkMzQwMDAhDQpbICAy
MjIuOTg1NTE0XSAyYjE2MyBpcyA3OTZjZjAwMCENClsgIDIyMi45ODc3ODBdIDJiMTY0IGlz
IDIxOGIxMDAwIQ0KWyAgMjIyLjk5MDAyN10gMmIxNjUgaXMgNzhjZGMwMDAhDQpbICAyMjIu
OTkyMjc1XSAyYjE2NiBpcyAyMWU0ZDAwMCENClsgIDIyMi45OTQ1NTldIDJiMTY3IGlzIDdh
NjQ2MDAwIQ0KWyAgMjIyLjk5NjgzNF0gMmIxNjggaXMgNzhmNGIwMDAhDQpbICAyMjIuOTk5
MDg2XSAyYjE2OSBpcyAyMWE0MjAwMCENClsgIDIyMy4wMDEzODldIDJiMTZhIGlzIDIxNWIx
MDAwIQ0KWyAgMjIzLjAwMzY4MF0gMmIxNmIgaXMgMjE2MGUwMDAhDQpbICAyMjMuMDA1OTY1
XSAyYjE2YyBpcyA3OGY0YzAwMCENClsgIDIyMy4wMDgzNDhdIDJiMTZkIGlzIDIxYTNkMDAw
IQ0KWyAgMjIzLjAxMDY3MV0gMmIxNmUgaXMgN2E3NDQwMDAhDQpbICAyMjMuMDEyOTQ5XSAy
YjE2ZiBpcyA3YTc0MTAwMCENClsgIDIyMy4wMTUyMzJdIDJiMTcwIGlzIDdhNjIxMDAwIQ0K
WyAgMjIzLjAxNzUwNV0gMmIxNzEgaXMgN2EwNTEwMDAhDQpbICAyMjMuMDE5NzMxXSAyYjE3
MiBpcyAyMWRlNDAwMCENClsgIDIyMy4wMjE5ODhdIDJiMTczIGlzIDIxNWQ5MDAwIQ0KWyAg
MjIzLjAyNTI5NF0gMmIxMzQgaXMgMjFlMmEwMDAhDQpbICAyMjMuMDI3NjExXSAyYjEzNSBp
cyA3OGYwZjAwMCENClsgIDIyMy4wMjk4NTZdIDJiMTc2IGlzIDc4ZjMxMDAwIQ0KWyAgMjIz
LjAzMjEwNF0gMmIxNzcgaXMgNzhmNTEwMDAhDQpbICAyMjMuMDM0MzUyXSAyYjE3OCBpcyA3
OTQ5YjAwMCENClsgIDIyMy4wMzY1NDRdIDJiMTc5IGlzIDc5NDY5MDAwIQ0KWyAgMjIzLjAz
ODc0OF0gMmIxN2EgaXMgNzhlZDgwMDAhDQpbICAyMjMuMDQwOTEzXSAyYjE3YiBpcyA3OGVl
NzAwMCENClsgIDIyMy4wNDMwNzhdIDJiMTdjIGlzIDc4ZjA3MDAwIQ0KWyAgMjIzLjA0NTIy
NF0gMmIxN2QgaXMgNzhkMDMwMDAhDQpbICAyMjMuMDQ3MzkyXSAyYjE3ZSBpcyAyMTY0ZjAw
MCENClsgIDIyMy4wNDk4ODJdIDJiMTdmIGlzIDc4ZDNjMDAwIQ0KWyAgMjIzLjA1MjA2NF0g
MmIxODAgaXMgNzhlZGUwMDAhDQpbICAyMjMuMDU0MjEyXSAyYjE4MSBpcyA3OTRhMTAwMCEN
ClsgIDIyMy4wNTYzNDldIDJiMTgyIGlzIDc4ZjAzMDAwIQ0KWyAgMjIzLjA1ODUwNl0gMmIx
ODMgaXMgMjFlNTUwMDAhDQpbICAyMjMuMDYwNjcwXSAyYjE4NCBpcyA3OGYwYTAwMCENClsg
IDIyMy4wNjI3OThdIDJiMTg1IGlzIDc4ZWQ3MDAwIQ0KWyAgMjIzLjA2NDk0Ml0gMmIxODYg
aXMgNzhlZGEwMDAhDQpbICAyMjMuMDY3MDYyXSAyYjE4NyBpcyAyMWE1MzAwMCENClsgIDIy
My4wNjkyMDldIDJiMTg4IGlzIDIxYTRmMDAwIQ0KWyAgMjIzLjA3MTMwNV0gMmIxODkgaXMg
NzhlZGQwMDAhDQpbICAyMjMuMDczNDE4XSAyYjE4YSBpcyA3OGVkNTAwMCENClsgIDIyMy4w
NzU0OTVdIDJiMThiIGlzIDc4ZjRmMDAwIQ0KWyAgMjIzLjA3NzU4NF0gMmIxOGMgaXMgMjE2
NDcwMDAhDQpbICAyMjMuMDc5NjM4XSAyYjE4ZCBpcyAyMTkwMjAwMCENClsgIDIyMy4wODE3
MDRdIDJiMThlIGlzIDdhNjNjMDAwIQ0KWyAgMjIzLjA4Mzc4NV0gMmIxOGYgaXMgMjE2NzEw
MDAhDQpbICAyMjMuMDg1ODY2XSAyYjE5MCBpcyA3OGQzZjAwMCENClsgIDIyMy4wODc5Njdd
IDJiMTkxIGlzIDIxOGIwMDAwIQ0KWyAgMjIzLjA5MDA4MV0gMmIxOTIgaXMgN2E2NDEwMDAh
DQpbICAyMjMuMDkyMTc0XSAyYjE5MyBpcyA3YTczYzAwMCENClsgIDIyMy4wOTQzNDFdIDJi
MTk0IGlzIDdhNzNkMDAwIQ0KWyAgMjIzLjA5NjQwNl0gMmIxOTUgaXMgMjFlMjcwMDAhDQpb
ICAyMjMuMDk4NTEzXSAyYjE3NCBpcyAyMWUyNjAwMCENClsgIDIyMy4xMDA2MDRdIDJiMTYx
IGlzIDc4ZjNmMDAwIQ0KWyAgMjIzLjEwNzg5MV0gMmIxNzUgaXMgNzk0OTQwMDAhDQpbICAy
MjMuMTEwMTYyXSAyYjE5NiBpcyA3OTQ5NTAwMCENClsgIDIyMy4xMTIyNzldIDJiMTk3IGlz
IDdhNjM4MDAwIQ0KWyAgMjIzLjExNDQzOF0gMmIxOTggaXMgN2E2MzkwMDAhDQpbICAyMjMu
MTE2NTU0XSAyYjE5OSBpcyA3YTY1NjAwMCENClsgIDIyMy4xMTg3MDVdIDJiMTlhIGlzIDdh
NjU3MDAwIQ0KWyAgMjIzLjEyMDgxNF0gMmIxOWIgaXMgN2E2NTIwMDAhDQpbICAyMjMuMTIy
OTEyXSAyYjE5YyBpcyA3YTY1MzAwMCENClsgIDIyMy4xMjQ5ODBdIDJiMTlkIGlzIDIxNjYz
MDAwIQ0KWyAgMjIzLjEyNzA1Ml0gMmIxOWUgaXMgMjE2NjQwMDAhDQpbICAyMjMuMTI5MDc4
XSAyYjE5ZiBpcyA3YTY0MDAwMCENClsgIDIyMy4xMzExODhdIDJiMWEwIGlzIDIxYTcxMDAw
IQ0KWyAgMjIzLjEzMzIxM10gMmIxYTEgaXMgMjFhNzIwMDAhDQpbICAyMjMuMTM1MjQ4XSAy
YjFhMiBpcyAyMWU1YjAwMCENClsgIDIyMy4xMzcyNzFdIDJiMWEzIGlzIDIxZTVjMDAwIQ0K
WyAgMjIzLjEzOTI3Ml0gMmIxYTQgaXMgNzk0YjIwMDAhDQpbICAyMjMuMTQxMjc2XSAyYjFh
NSBpcyA3OTRiMzAwMCENClsgIDIyMy4xNDQ3MDddIDJiMWE2IGlzIDc4ZjI3MDAwIQ0KWyAg
MjIzLjE0Njc2NF0gMmIxYTcgaXMgNzhlZTgwMDAhDQpbICAyMjMuMTU0MzUyXSAyYjFhOCBp
cyA3OGVlOTAwMCENClsgIDIyMy4xNTY0MDNdIDJiMWE5IGlzIDc4ZWVhMDAwIQ0KWyAgMjIz
LjE1ODM4NF0gMmIxYWEgaXMgNzhmM2MwMDAhDQpbICAyMjMuMTYwMzU1XSAyYjFhYiBpcyAy
MWEyNjAwMCENClsgIDIyMy4xNjIzNjRdIDJiMWFjIGlzIDIxYTI1MDAwIQ0KWyAgMjIzLjE2
NDM1NV0gMmIxYWQgaXMgNzhmNDEwMDAhDQpbICAyMjMuMTY2MjcwXSAyYjFhZSBpcyA3OGY0
MDAwMCENClsgIDIyMy4xNjgxODhdIDJiMWFmIGlzIDc4ZjUzMDAwIQ0KWyAgMjIzLjE3MDA4
OF0gMmIxYjAgaXMgNzhmNTIwMDAhDQpbICAyMjMuMTcxOTg1XSAyYjFiMSBpcyA3OGVkMTAw
MCENClsgIDIyMy4xNzM4NjJdIDJiMWIyIGlzIDc4ZWQwMDAwIQ0KWyAgMjIzLjE3NjIwNl0g
MmIxZDEgaXMgNzhlZTEwMDAhDQpbICAyMjMuMTc4MDczXSAyYjFkMiBpcyA3OGVlMjAwMCEN
ClsgIDIyMy4xNzk4OTldIDJiMWQzIGlzIDc4ZWUzMDAwIQ0KWyAgMjIzLjE4MTcxN10gMmIx
ZDYgaXMgNzhmNDQwMDAhDQpbICAyMjMuMTgzNTM0XSAyYjFkNyBpcyA3OGY0NTAwMCENClsg
IDIyMy4xODUzNDhdIDJiMWQ4IGlzIDc4ZjQ2MDAwIQ0KWyAgMjIzLjE4NzE1N10gMmIxZDkg
aXMgNzhmNDcwMDAhDQpbICAyMjMuMTg4OTgxXSAyYjFkYSBpcyAyMWEyMTAwMCENClsgIDIy
My4xOTA4MDhdIDJiMWRiIGlzIDIxYTIyMDAwIQ0KWyAgMjIzLjE5MjY2MV0gMmIxZGMgaXMg
MjFhMjMwMDAhDQpbICAyMjMuMTk0NTExXSAyYjFkZCBpcyAyMWEyNDAwMCENClsgIDIyMy4x
OTYzNDJdIDJiMWRlIGlzIDIxYTE4MDAwIQ0KWyAgMjIzLjE5ODE3MV0gMmIxZGYgaXMgMjFh
MTkwMDAhDQpbICAyMjMuMTk5OTU1XSAyYjFlMCBpcyAyMWExYTAwMCENClsgIDIyMy4yMDE3
NzhdIDJiMWUxIGlzIDIxYTFiMDAwIQ0KWyAgMjIzLjIwMzYwMF0gMmIxZTIgaXMgMjFhMWMw
MDAhDQpbICAyMjMuMjA1NDM0XSAyYjFlMyBpcyA3OGYxMDAwMCENClsgIDIyMy4yMDcyNTBd
IDJiMWU0IGlzIDc4ZjExMDAwIQ0KWyAgMjIzLjIwOTEwMV0gMmIxZTUgaXMgNzhmMTIwMDAh
DQpbICAyMjMuMjEwODk4XSAyYjFlNiBpcyA3OGYxMzAwMCENClsgIDIyMy4yMTI2ODBdIDJi
MWU3IGlzIDc4ZWUwMDAwIQ0KWyAgMjIzLjIxNDQ5OV0gMmIxYzYgaXMgNzhmNzgwMDAhDQpb
ICAyMjMuMjE2MzA0XSAyYjFjNyBpcyA3OGY3OTAwMCENClsgIDIyMy4yMTgxMjhdIDJiMWM4
IGlzIDc4ZjdhMDAwIQ0KWyAgMjIzLjIxOTkwMF0gMmIxYzkgaXMgNzhmN2IwMDAhDQpbICAy
MjMuMjIxNzA4XSAyYjFjYSBpcyA3OGYyMDAwMCENClsgIDIyMy4yMjM0ODhdIDJiMWNiIGlz
IDc4ZjIxMDAwIQ0KWyAgMjIzLjIyNTI0N10gMmIxY2MgaXMgNzhmMjIwMDAhDQpbICAyMjMu
MjI3MDMwXSAyYjFjZCBpcyA3OGYyMzAwMCENClsgIDIyMy4yMjg3ODVdIDJiMWNlIGlzIDc4
ZjI0MDAwIQ0KWyAgMjIzLjIzMDU2M10gMmIxY2YgaXMgNzhmMjUwMDAhDQpbICAyMjMuMjMy
MzE2XSAyYjFkMCBpcyA3OGYyNjAwMCENClsgIDIyMy4yMzQwOTNdIDJiMWIzIGlzIDIxYTIw
MDAwIQ0KWyAgMjIzLjIzNTg2NF0gMmIxYjQgaXMgMjFhMWYwMDAhDQpbICAyMjMuMjM3NjU0
XSAyYjFiNSBpcyA3OGYyZjAwMCENClsgIDIyMy4yMzk0NDJdIDJiMWI2IGlzIDc4ZjJlMDAw
IQ0KWyAgMjIzLjI0MTIyN10gMmIxYjcgaXMgNzhmMmQwMDAhDQpbICAyMjMuMjQzMDIwXSAy
YjFiOCBpcyA3OGYyYzAwMCENClsgIDIyMy4yNDQ4MDVdIDJiMWI5IGlzIDIxYTcwMDAwIQ0K
WyAgMjIzLjI0NjU5Ml0gMmIxYmEgaXMgMjFhNmYwMDAhDQpbICAyMjMuMjQ4Mzc2XSAyYjFi
YiBpcyAyMWE2ZTAwMCENClsgIDIyMy4yNTAxNjRdIDJiMWJjIGlzIDIxYTZkMDAwIQ0KWyAg
MjIzLjI1MTk2Ml0gMmIxYmQgaXMgMjFhNGMwMDAhDQpbICAyMjMuMjUzNzUyXSAyYjFiZSBp
cyAyMWE0YjAwMCENClsgIDIyMy4yNTU1MzldIDJiMWJmIGlzIDIxYTRhMDAwIQ0KWyAgMjIz
LjI1NzMxOF0gMmIxYzAgaXMgMjFhNDkwMDAhDQpbICAyMjMuMjU5MDk0XSAyYjFjMSBpcyA3
OGVmZjAwMCENClsgIDIyMy4yNjA4OTBdIDJiMWMyIGlzIDc4ZWZlMDAwIQ0KWyAgMjIzLjI2
MjY1NV0gMmIxYzMgaXMgNzhlZmQwMDAhDQpbICAyMjMuMjY0NDUwXSAyYjFjNCBpcyA3OGVm
YzAwMCENClsgIDIyMy4yNjYyMTBdIDJiMWM1IGlzIDc4ZWViMDAwIQ0KWyAgMjIzLjI3NjYx
NV0gMmIxZjQgaXMgNzhmMWEwMDAhDQpbICAyMjMuMjc4NDM1XSAyYjFmNSBpcyA3OGYxYjAw
MCENClsgIDIyMy4yODAyMzBdIDJiMWY2IGlzIDIxYTE1MDAwIQ0KWyAgMjIzLjI4MTk5MF0g
MmIxZTggaXMgMjFhMTYwMDAhDQpbICAyMjMuMjg0NDI2XSAyYjFmNyBpcyA3OGYzNzAwMCEN
ClsgIDIyMy4yODYyMTldIDJiMWU5IGlzIDc4ZjE1MDAwIQ0KWyAgMjIzLjI4ODA1Nl0gMmIx
ZWEgaXMgNzhmMTYwMDAhDQpbICAyMjMuMjg5ODY4XSAyYjFlYiBpcyA3OGYxNzAwMCENClsg
IDIyMy4yOTE3MDRdIDJiMWVjIGlzIDc4ZjE4MDAwIQ0KWyAgMjIzLjI5MzU0MF0gMmIxZWQg
aXMgNzhmMTkwMDAhDQpbICAyMjMuMzAxMzYxXSAyYjFlZSBpcyA3OGYzNjAwMCENClsgIDIy
My4zMDMxODZdIDJiMWVmIGlzIDIxNWNkMDAwIQ0KWyAgMjIzLjMwNTA1MF0gMmIxZjAgaXMg
Nzk0OGIwMDAhDQpbICAyMjMuMzA2OTA2XSAyYjFmMSBpcyAyMThhZDAwMCENClsgIDIyMy4z
MDkyOThdIDJiMWYyIGlzIDc5NDkyMDAwIQ0KWyAgMjIzLjMxMTE4OF0gMmIxZjMgaXMgNzhm
MzkwMDAhDQpbICAyMjMuMzEzMDgxXSAyYjIxMyBpcyA3OGYyOTAwMCENClsgIDIyMy4zMTQ5
ODldIDJiMjE0IGlzIDc4ZDQ4MDAwIQ0KWyAgMjIzLjM0NTIyOF0gMmIyMTUgaXMgN2E2NzQw
MDAhDQpbICAyMjMuMzU5OTA5XSAyYjFmOCBpcyA3OGNmNTAwMCENClsgIDIyMy4zODEwMDNd
IDJiMWY5IGlzIDc4ZjM1MDAwIQ0KWyAgMjIzLjM4Mjk1MF0gMmIxZmEgaXMgNzhmMzQwMDAh
DQpbICAyMjMuMzg0OTEwXSAyYjFmYiBpcyAyMWUyYzAwMCENClsgIDIyMy4zODY4NjJdIDJi
MWZjIGlzIDIxZTJiMDAwIQ0KWyAgMjIzLjM4OTYwOV0gMmIxZmQgaXMgMjFhMTEwMDAhDQpb
ICAyMjMuMzkxNTc4XSAyYjIxNiBpcyAyMWEwYzAwMCENClsgIDIyMy4zOTM1NzddIDJiMjE3
IGlzIDIxYTBiMDAwIQ0KWyAgMjIzLjM5NTUwMl0gMmIyMTggaXMgMjFhMGEwMDAhDQpbICAy
MjMuMzk3NDY2XSAyYjIxOSBpcyAyMWEwOTAwMCENClsgIDIyMy4zOTkzODNdIDJiMjFhIGlz
IDIxYTA4MDAwIQ0KWyAgMjIzLjQwMTM0Ml0gMmIyMWIgaXMgMjFhMDcwMDAhDQpbICAyMjMu
NDAzMjcwXSAyYjIxYyBpcyAyMWEwNjAwMCENClsgIDIyMy40MDU2ODBdIDJiMjFkIGlzIDc4
ZDAxMDAwIQ0KWyAgMjIzLjQyNDAzNl0gMmIyMWUgaXMgNzhmNmMwMDAhDQpbICAyMjMuNDI2
MDA0XSAyYjFmZSBpcyA3OGY2ZDAwMCENClsgIDIyMy40Mjc5NTddIDJiMWZmIGlzIDc4ZjZm
MDAwIQ0KWyAgMjIzLjQyOTg4Nl0gMmIyMDAgaXMgNzhmNmUwMDAhDQpbICAyMjMuNDMyNTA3
XSAyYjIwMSBpcyA3OGVmNjAwMCENClsgIDIyMy40MzQ1MDVdIDJiMjFmIGlzIDc4ZWY3MDAw
IQ0KWyAgMjIzLjQzNjQyNl0gMmIyMjAgaXMgNzhlZjgwMDAhDQpbICAyMjMuNDM4Mzg1XSAy
YjIyMSBpcyA3OGVmOTAwMCENClsgIDIyMy40NDAzMzFdIDJiMjIyIGlzIDc4ZWZhMDAwIQ0K
WyAgMjIzLjQ0MjI0OF0gMmIyMjMgaXMgNzhlZmIwMDAhDQpbICAyMjMuNDQ4NTI0XSAyYjIy
NCBpcyAyMWU3ODAwMCENClsgIDIyMy40NTA0OTldIDJiMjAyIGlzIDIxYTEyMDAwIQ0KWyAg
MjIzLjQ1MjM2Nl0gMmIyMDMgaXMgN2E2MjYwMDAhDQpbICAyMjMuNDU0Mjg0XSAyYjIwNCBp
cyA3YTY3ZDAwMCENClsgIDIyMy40NTY4MDBdIDJiMjA1IGlzIDc4ZjgzMDAwIQ0KWyAgMjIz
LjQ1ODcwMV0gMmIyMjUgaXMgN2E2NjYwMDAhDQpbICAyMjMuNDYwNjA1XSAyYjIyNiBpcyAy
MWE0NTAwMCENClsgIDIyMy40NjI0ODNdIDJiMjI3IGlzIDc4ZjcxMDAwIQ0KWyAgMjIzLjQ5
NjEyOV0gMmIyMjggaXMgMjE2NTUwMDAhDQpbICAyMjMuNTA5OTI5XSAyYjIwNiBpcyA3YTYy
ZDAwMCENClsgIDIyMy41MTE4OTBdIDJiMjA3IGlzIDc4Y2VjMDAwIQ0KWyAgMjIzLjUxMzg2
Nl0gMmIyMDggaXMgNzk0YTMwMDAhDQpbICAyMjMuNTE1ODAyXSAyYjIwOSBpcyA3YTY1MTAw
MCENClsgIDIyMy41MTgzODddIDJiMjBhIGlzIDIxOGE1MDAwIQ0KWyAgMjIzLjUyMDM1N10g
MmIyMjkgaXMgMjFhMGQwMDAhDQpbICAyMjMuNTIyMzQzXSAyYjIyYSBpcyA3OGYzYTAwMCEN
ClsgIDIyMy41MjQzODBdIDJiMjJiIGlzIDIxNjFjMDAwIQ0KWyAgMjIzLjUzNDI1M10gMmIy
MmMgaXMgNzhmNjAwMDAhDQpbICAyMjMuNTM2Mjc2XSAyYjIyZCBpcyA3OGY1ZjAwMCENClsg
IDIyMy41Mzg0MjNdIDJiMjJlIGlzIDc4ZjVlMDAwIQ0KWyAgMjIzLjU0MDUwNl0gMmIyMmYg
aXMgNzhmNWQwMDAhDQpbICAyMjMuNTQ5NDIwXSAyYjIzMCBpcyA3OGY2NDAwMCENClsgIDIy
My41NTE1MjhdIDJiMjMxIGlzIDc4ZjYzMDAwIQ0KWyAgMjIzLjU1MzU1OV0gMmIyMzIgaXMg
NzhmNjIwMDAhDQpbICAyMjMuNTU1NTg2XSAyYjIzMyBpcyA3OGY2MTAwMCENClsgIDIyMy41
NTg0MjVdIDJiMjNkIGlzIDc4ZWYxMDAwIQ0KWyAgMjIzLjU2MDQ0NF0gMmIyM2UgaXMgNzhl
ZjAwMDAhDQpbICAyMjMuNTYyNDM1XSAyYjIzZiBpcyA3OGVlZjAwMCENClsgIDIyMy41NjQ0
MjldIDJiMjQwIGlzIDc4ZWVlMDAwIQ0KWyAgMjIzLjU2NjM5OV0gMmIyNDEgaXMgNzhlZWQw
MDAhDQpbICAyMjMuNTY4Mzk3XSAyYjIzNSBpcyA3OGVlYzAwMCENClsgIDIyMy41NzAzODJd
IDJiMjM2IGlzIDc4ZjZiMDAwIQ0KWyAgMjIzLjU3MjM1MF0gMmIyMzcgaXMgNzhmNmEwMDAh
DQpbICAyMjMuNTc0MjkyXSAyYjIzOCBpcyA3OGY2OTAwMCENClsgIDIyMy41NzYyMDhdIDJi
MjM5IGlzIDc4ZjY4MDAwIQ0KWyAgMjIzLjU3ODExNV0gMmIyM2EgaXMgNzhmNjcwMDAhDQpb
ICAyMjMuNTgwMDA1XSAyYjIzYiBpcyA3OGY2NjAwMCENClsgIDIyMy41ODE4ODNdIDJiMjNj
IGlzIDc4ZjY1MDAwIQ0KWyAgMjIzLjU4NDI2MV0gMmIyNDIgaXMgN2E2YzAwMDAhDQpbICAy
MjMuNTg2MTE2XSAyYjIwYiBpcyA3OGVmMjAwMCENClsgIDIyMy42MDcxMzddIDJiMjBjIGlz
IDc5MmJhMDAwIQ0KWyAgMjIzLjYzNTAxOV0gMmIyMGQgaXMgN2E2MjIwMDAhDQpbICAyMjMu
NjM2OTQxXSAyYjIwZSBpcyA3OGZiNDAwMCENClsgIDIyMy42Mzg4MTRdIDJiMjBmIGlzIDc4
ZmI5MDAwIQ0KWyAgMjIzLjY0MDY3NV0gMmIyMTAgaXMgNzhmYzAwMDAhDQpbICAyMjMuNjQ2
MTc5XSAyYjIxMSBpcyA3OGZjODAwMCENClsgIDIyMy42NDgxNDVdIDJiMjQzIGlzIDc4Zjkz
MDAwIQ0KWyAgMjIzLjY0OTk4M10gMmIyNDQgaXMgNzhmYWQwMDAhDQpbICAyMjMuNjUxNzg1
XSAyYjI0NSBpcyA3OGY5YTAwMCENClsgIDIyMy42NTM1NzFdIDJiMjQ2IGlzIDIxYTA1MDAw
IQ0KWyAgMjIzLjY1NTM4M10gMmIyNDcgaXMgNzhmYjAwMDAhDQpbICAyMjMuNjU3MjA5XSAy
YjI0OCBpcyA3OGZiMTAwMCENClsgIDIyMy42NTkwMzddIDJiMjQ5IGlzIDc4ZmIyMDAwIQ0K
WyAgMjIzLjY2MDkzNV0gMmIyNGEgaXMgNzhmOTQwMDAhDQpbICAyMjMuNjYyNzYwXSAyYjI0
YiBpcyA3OGY5MDAwMCENClsgIDIyMy42NjQ1ODRdIDJiMjRjIGlzIDc4ZmFhMDAwIQ0KWyAg
MjIzLjcyMDU0OV0gMmIyNGQgaXMgNzhmYmMwMDAhDQpbICAyMjMuNzM5Mzc0XSAyYjIxMiBp
cyA3OGY4OTAwMCENClsgIDIyMy43ODEzMjldIDJiMjUxIGlzIDdhMGFlMDAwIQ0KWyAgMjIz
Ljc4MzI1N10gMmIyNTIgaXMgNzhmYzEwMDAhDQpbICAyMjMuNzg1MTU5XSAyYjI1MyBpcyAy
MWU3YTAwMCENClsgIDIyMy43ODcxMDRdIDJiMjU0IGlzIDdhNjBkMDAwIQ0KWyAgMjIzLjc4
OTc1NF0gMmIyNTUgaXMgMjE1YWQwMDAhDQpbICAyMjMuNzkxNzIwXSAyYjI0ZSBpcyAyMTVj
YTAwMCENClsgIDIyMy43OTM2ODJdIDJiMjRmIGlzIDc4ZmFiMDAwIQ0KWyAgMjIzLjc5NTY2
MF0gMmIyNTAgaXMgNzk0Y2IwMDAhDQpbICAyMjMuNzk3NjY0XSAyYjI3MCBpcyA3YTY5ZDAw
MCENClsgIDIyMy43OTk2NjRdIDJiMjcxIGlzIDc5NDRlMDAwIQ0KWyAgMjIzLjgwMTY2N10g
MmIyNzIgaXMgMjE1YjIwMDAhDQpbICAyMjMuODAzNzA4XSAyYjI3MyBpcyA3OGZiODAwMCEN
ClsgIDIyMy44MjI1MjZdIDJiMjc0IGlzIDc4ZWNlMDAwIQ0KWyAgMjIzLjg0MTYxN10gMmIy
NTYgaXMgMjE4ZmMwMDAhDQpbICAyMjMuODQzNzQ0XSAyYjI1NyBpcyAyMWEwZjAwMCENClsg
IDIyMy44NDU3NzddIDJiMjU4IGlzIDdhMDkxMDAwIQ0KWyAgMjIzLjg0NzgyNl0gMmIyNTkg
aXMgN2E3M2UwMDAhDQpbICAyMjMuODUwNzQ5XSAyYjI1YSBpcyAyMWUxMTAwMCENClsgIDIy
My44NTI3NzVdIDJiMjc1IGlzIDc4ZWRmMDAwIQ0KWyAgMjIzLjg1NDk0N10gMmIyNzYgaXMg
Nzk0ODUwMDAhDQpbICAyMjMuODU3MDM1XSAyYjI3NyBpcyA3OTRiNTAwMCENClsgIDIyMy44
NTkxMDFdIDJiMjc4IGlzIDdhNjRlMDAwIQ0KWyAgMjIzLjg2MTE4M10gMmIyNzkgaXMgNzhm
NWMwMDAhDQpbICAyMjMuODYzMjU2XSAyYjI3YSBpcyAyMWU0MTAwMCENClsgIDIyMy44NjUz
MzBdIDJiMjdiIGlzIDc4Zjk1MDAwIQ0KWyAgMjIzLjg2NzQ0NV0gMmIyN2MgaXMgNzhmMjgw
MDAhDQpbICAyMjMuODc1OTExXSAyYjI3ZSBpcyA3YTYxNDAwMCENClsgIDIyMy44NzgwNzNd
IDJiMjdmIGlzIDdhNjFiMDAwIQ0KWyAgMjIzLjg4MDIxMF0gMmIyODAgaXMgNzhmOTIwMDAh
DQpbICAyMjMuODgyMzMzXSAyYjI3ZCBpcyA3OGYwNTAwMCENClsgIDIyMy44OTM0NTldIDJi
Mjg5IGlzIDdhNmJmMDAwIQ0KWyAgMjIzLjg5NTYxN10gMmIyODEgaXMgN2E2MTYwMDAhDQpb
ICAyMjMuODk3NzczXSAyYjI4MiBpcyA3OGZiMzAwMCENClsgIDIyMy44OTk5MTBdIDJiMjgz
IGlzIDc5NDg4MDAwIQ0KWyAgMjIzLjkwMjA1Nl0gMmIyODQgaXMgNzhkMDgwMDAhDQpbICAy
MjMuOTA0MjMwXSAyYjI4NSBpcyAyMWUxNDAwMCENClsgIDIyMy45MDYzNjZdIDJiMjg2IGlz
IDdhNjEzMDAwIQ0KWyAgMjIzLjkwODU0NF0gMmIyODcgaXMgNzhmYjUwMDAhDQpbICAyMjMu
OTEwNzAzXSAyYjI4OCBpcyA3YTBiNzAwMCENClsgIDIyMy45MjIyMjBdIDJiMjhhIGlzIDIx
ZTVmMDAwIQ0KWyAgMjIzLjkzNTAxNl0gMmIyOGIgaXMgNzhmYjcwMDAhDQpbICAyMjMuOTM3
MjgyXSAyYjI1YiBpcyA3OGZiNjAwMCENClsgIDIyMy45Mzk0NTRdIDJiMjVjIGlzIDc5Mjhm
MDAwIQ0KWyAgMjIzLjk1NTY1M10gMmIyNWQgaXMgNzkyOTMwMDAhDQpbICAyMjMuOTU3ODY1
XSAyYjI1ZSBpcyA3OTI5MjAwMCENClsgIDIyMy45NTk5OTBdIDJiMjVmIGlzIDc5MjkxMDAw
IQ0KWyAgMjIzLjk2MjE0N10gMmIyNjAgaXMgNzkyOTAwMDAhDQpbICAyMjMuOTY0ODAzXSAy
YjI2MSBpcyA3OGZhNjAwMCENClsgIDIyMy45NjY5NjJdIDJiMjhjIGlzIDc4ZmE1MDAwIQ0K
WyAgMjIzLjk2OTA1NF0gMmIyOGQgaXMgNzhmYTQwMDAhDQpbICAyMjMuOTg0MTg1XSAyYjI4
ZSBpcyA3OTJjODAwMCENClsgIDIyMy45ODYyODFdIDJiMjYyIGlzIDc5MmM3MDAwIQ0KWyAg
MjIzLjk4ODQwNF0gMmIyNjMgaXMgNzkyYzYwMDAhDQpbICAyMjMuOTkwNDkzXSAyYjI2NCBp
cyA3OTJjNTAwMCENClsgIDIyMy45OTMwOTNdIDJiMjY1IGlzIDc4ZmM3MDAwIQ0KWyAgMjIz
Ljk5NTE2Ml0gMmIyOGYgaXMgNzhmNTYwMDAhDQpbICAyMjMuOTk3MjAwXSAyYjI5MCBpcyA3
OTJjOTAwMCENClsgIDIyNC4wMDM5NzZdIDJiMjkxIGlzIDc5MmI4MDAwIQ0KWyAgMjI0LjAw
NjAyNF0gMmIyNjYgaXMgNzhmYTEwMDAhDQpbICAyMjQuMDA4MTE1XSAyYjI2NyBpcyA3OGZh
MzAwMCENClsgIDIyNC4wMTAxNjRdIDJiMjY4IGlzIDc4ZmE3MDAwIQ0KWyAgMjI0LjAxMjk4
MV0gMmIyNjkgaXMgNzkyYjUwMDAhDQpbICAyMjQuMDE1MTc3XSAyYjI5MiBpcyA3OTJiNjAw
MCENClsgIDIyNC4wMTcyMTddIDJiMjkzIGlzIDc5MmI3MDAwIQ0KWyAgMjI0LjAxOTE5Ml0g
MmIyOTQgaXMgMjFlNGMwMDAhDQpbICAyMjQuMDIxMjEzXSAyYjI5NSBpcyA3OGY3ZDAwMCEN
ClsgIDIyNC4wMjMyMDJdIDJiMjk2IGlzIDc4ZjhmMDAwIQ0KWyAgMjI0LjAyNTIwMV0gMmIy
OTcgaXMgNzhmYTIwMDAhDQpbICAyMjQuMDI3MTYxXSAyYjI5OCBpcyA3OTJiNDAwMCENClsg
IDIyNC4wMjkyNTVdIDJiMjk5IGlzIDc5Mjk3MDAwIQ0KWyAgMjI0LjAzMTI0NV0gMmIyOWEg
aXMgNzkyOTgwMDAhDQpbICAyMjQuMDMzMTg4XSAyYjI5YiBpcyA3OTI5OTAwMCENClsgIDIy
NC4wMzUwNzVdIDJiMjljIGlzIDc5MjlhMDAwIQ0KWyAgMjI0LjAzNjk5MV0gMmIyOWQgaXMg
NzkyYWYwMDAhDQpbICAyMjQuMDM4ODUwXSAyYjI5ZSBpcyA3OGY5YzAwMCENClsgIDIyNC4w
NDA3MjldIDJiMjlmIGlzIDc4ZjlmMDAwIQ0KWyAgMjI0LjA0MjYzOF0gMmIyYTAgaXMgNzhm
YTAwMDAhDQpbICAyMjQuMDQ0NTM0XSAyYjJhMSBpcyA3OGZjNTAwMCENClsgIDIyNC4wNTMy
MDFdIDJiMmEzIGlzIDc4ZmNiMDAwIQ0KWyAgMjI0LjA1NTEyNV0gMmIyYTIgaXMgNzhmODUw
MDAhDQpbICAyMjQuMDU3MDE1XSAyYjI2YSBpcyA3OGQxMjAwMCENClsgIDIyNC4wNTg5MjNd
IDJiMjZiIGlzIDc5Mjk2MDAwIQ0KWyAgMjI0LjA2MTM3MV0gMmIyYTUgaXMgNzhlZjQwMDAh
DQpbICAyMjQuMDYzMzAyXSAyYjJhNiBpcyA3OGY5OTAwMCENClsgIDIyNC4wNjUyMjldIDJi
MjZjIGlzIDc4ZjU3MDAwIQ0KWyAgMjI0LjA2NzE5Nl0gMmIyYTQgaXMgNzhmYmEwMDAhDQpb
ICAyMjQuMDY5NjcyXSAyYjJhNyBpcyA3OGZhZTAwMCENClsgIDIyNC4wNzE2NDVdIDJiMmE4
IGlzIDc4ZmE5MDAwIQ0KWyAgMjI0LjA3MzU2OV0gMmIyYTkgaXMgNzhmOWQwMDAhDQpbICAy
MjQuMDc1NDU3XSAyYjJhYSBpcyA3OGY5ZTAwMCENClsgIDIyNC4wNzc3NDZdIDJiMmFiIGlz
IDc5Mjg2MDAwIQ0KWyAgMjI0LjA5MjQ4MF0gMmIyYWMgaXMgNzkyOGEwMDAhDQpbICAyMjQu
MDk0NDYwXSAyYjI2ZCBpcyA3OTI4OTAwMCENClsgIDIyNC4wOTYzMjZdIDJiMjZlIGlzIDc5
Mjg4MDAwIQ0KWyAgMjI0LjA5ODE5NV0gMmIyNmYgaXMgNzkyODcwMDAhDQpbICAyMjQuMTA5
MDczXSAyYjJhZSBpcyA3OTJhMjAwMCENClsgIDIyNC4xMTA5NTBdIDJiMmFkIGlzIDc5MmEx
MDAwIQ0KWyAgMjI0LjExMjg0OF0gMmIyY2QgaXMgNzkyYTAwMDAhDQpbICAyMjQuMTE0NzAy
XSAyYjJjZSBpcyA3OTI5ZjAwMCENClsgIDIyNC4xMTY1NTVdIDJiMmNmIGlzIDc5MjllMDAw
IQ0KWyAgMjI0LjExODQwNF0gMmIyZDAgaXMgNzkyOWQwMDAhDQpbICAyMjQuMTIwMjY2XSAy
YjJkMSBpcyA3OTI5YzAwMCENClsgIDIyNC4xMjIxMDNdIDJiMmQyIGlzIDc5MjhiMDAwIQ0K
WyAgMjI0LjEyNDA3Ml0gMmIyZDMgaXMgNzkyYTYwMDAhDQpbICAyMjQuMTI1OTM4XSAyYjJk
NCBpcyA3OTJhNTAwMCENClsgIDIyNC4xMjc4MDldIDJiMmQ1IGlzIDc5MmE0MDAwIQ0KWyAg
MjI0LjEyOTY1OF0gMmIyZDYgaXMgNzkyYTMwMDAhDQpbICAyMjQuMTQxODMyXSAyYjJhZiBp
cyA3OTI2OTAwMCENClsgIDIyNC4xNDM2NzddIDJiMmQ3IGlzIDc5MjY4MDAwIQ0KWyAgMjI0
LjE0NTUyMl0gMmIyZDggaXMgNzkyNjcwMDAhDQpbICAyMjQuMTUyNDI5XSAyYjJkOSBpcyA3
OTI2YTAwMCENClsgIDIyNC4xNTQ0NDddIDJiMmRhIGlzIDc5MjZiMDAwIQ0KWyAgMjI0LjE1
NzU1OV0gMmIyZGIgaXMgNzkyNmQwMDAhDQpbICAyMjQuMTU5NDAyXSAyYjJkYyBpcyA3OTI2
YzAwMFsgIDIyNi4yODY1ODNdIDJhZTAyIGlzIDc4YzkwMDAwIQ0KWyAgMjI2LjI4ODM1Nl0g
MmFlMDMgaXMgNzhjOTEwMDAhDQpbICAyMjYuMjkwMDk1XSAyYWUwNCBpcyA3OGM5MjAwMCEN
ClsgIDIyNi4yOTE4MjJdIDJhZTA1IGlzIDc4YzkzMDAwIQ0KWyAgMjI2LjI5MzU0OF0gMmFl
MDYgaXMgNzhjOTQwMDAhDQpbICAyMjYuMjk1Mjk4XSAyYWUwNyBpcyA3OGM5NTAwMCENClsg
IDIyNi4yOTcwMzldIDJhZTA4IGlzIDc4Yzk2MDAwIQ0KWyAgMjI2LjI5ODk2MF0gMmFlMTQg
aXMgNzhjYTIwMDAhDQpbICAyMjYuMzAwNzA5XSAyYWUxNSBpcyA3OGNhMzAwMCENClsgIDIy
Ni4zMDI0MTldIDJhZTE4IGlzIDc4Y2E0MDAwIQ0KWyAgMjI2LjMwNDE1Nl0gMmFlMTkgaXMg
NzhjYTUwMDAhDQpbICAyMjYuMzA1ODYwXSAyYWUxYSBpcyA3OGNhNjAwMCENClsgIDIyNi4z
MDc1ODBdIDJhZTFiIGlzIDc4Y2E3MDAwIQ0KWyAgMjI2LjMwOTI5N10gMmFlMWMgaXMgNzhj
YTgwMDAhDQpbICAyMjYuMzExMDEyXSAyYWUxZCBpcyA3OGNhOTAwMCENClsgIDIyNi4zMTI3
MzJdIDJhZTFlIGlzIDc4Y2FhMDAwIQ0KWyAgMjI2LjMxNDQ0OV0gMmFlMWYgaXMgNzhjYWIw
MDAhDQpbICAyMjYuMzE2MTUyXSAyYWUyMCBpcyA3OGNjMzAwMCENClsgIDIyNi4zMTc4OTZd
IDJhZTA5IGlzIDc4Yzk3MDAwIQ0KWyAgMjI2LjMxOTU4OF0gMmFlMGEgaXMgNzhjOTgwMDAh
DQpbICAyMjYuMzIxMzE0XSAyYWUwYiBpcyA3OGM5OTAwMCENClsgIDIyNi4zMjMwMThdIDJh
ZTBjIGlzIDc4YzlhMDAwIQ0KWyAgMjI2LjMyNDc0OF0gMmFlMGQgaXMgNzhjOWIwMDAhDQpb
ICAyMjYuMzI2NDQwXSAyYWUwZSBpcyA3OGM5YzAwMCENClsgIDIyNi4zMjgxNDNdIDJhZTBm
IGlzIDc4YzlkMDAwIQ0KWyAgMjI2LjMyOTg1Ml0gMmFlMTAgaXMgNzhjOWUwMDAhDQpbICAy
MjYuMzMxNTQzXSAyYWUxMSBpcyA3OGM5ZjAwMCENClsgIDIyNi4zMzMyNDFdIDJhZTEyIGlz
IDc4Y2EwMDAwIQ0KWyAgMjI2LjMzNDkzOF0gMmFlMTMgaXMgNzhjYTEwMDAhDQpbICAyMjYu
MzUxOTE2XSAyYWUyMSBpcyA3OGM3ODAwMCENClsgIDIyNi4zNTM2MTNdIDJhZTIyIGlzIDc4
Yzc3MDAwIQ0KWyAgMjI2LjM1NTM4N10gMmFlMjMgaXMgNzhjNzYwMDAhDQpbICAyMjYuMzU3
MDcwXSAyYWUyNCBpcyA3OGM3NTAwMCENClsgIDIyNi4zNTg3NDVdIDJhZTI1IGlzIDc4Yzc0
MDAwIQ0KWyAgMjI2LjM2MDQxOF0gMmFlMjYgaXMgNzhjNzMwMDAhDQpbICAyMjYuMzYyMDkx
XSAyYWUyNyBpcyA3OGM3MjAwMCENClsgIDIyNi4zNjM3NjVdIDJhZTI4IGlzIDc4YzcxMDAw
IQ0KWyAgMjI2LjM2NTQzMF0gMmFlMjkgaXMgNzhjNzAwMDAhDQpbICAyMjYuMzY3MTI4XSAy
YWUyYSBpcyA3OGM2ZjAwMCENClsgIDIyNi4zNjg3OTJdIDJhZTJiIGlzIDc4YzZlMDAwIQ0K
WyAgMjI2LjM3MDYwMV0gMmFlMmMgaXMgNzhjODMwMDAhDQpbICAyMjYuMzcyMjYzXSAyYWUy
ZCBpcyA3OGM4MjAwMCENClsgIDIyNi4zNzM5NDBdIDJhZTJlIGlzIDc4YzgxMDAwIQ0KWyAg
MjI2LjM3NTYxOF0gMmFlMmYgaXMgNzhjODAwMDAhDQpbICAyMjYuMzc3Mjk3XSAyYWUzMCBp
cyA3OGM3ZjAwMCENClsgIDIyNi4zNzg5ODldIDJhZTMxIGlzIDc4YzdlMDAwIQ0KWyAgMjI2
LjM4MDY3M10gMmFlMzIgaXMgNzhjN2QwMDAhDQpbICAyMjYuMzgyMzU3XSAyYWUzMyBpcyA3
OGM3YzAwMCENClsgIDIyNi4zODQwNjldIDJhZTM0IGlzIDc4YzdiMDAwIQ0KWyAgMjI2LjM4
NTc0M10gMmFlMzUgaXMgNzhjN2EwMDAhDQpbICAyMjYuMzg3NDMxXSAyYWUzNiBpcyA3OGM3
OTAwMCENClsgIDIyNi4zODkwOTRdIDJhZTM3IGlzIDc4YzZkMDAwIQ0KWyAgMjI2LjM5MDc2
N10gMmFlMzggaXMgNzhjODkwMDAhDQpbICAyMjYuMzkyNDYwXSAyYWUzOSBpcyA3OGM4ODAw
MCENClsgIDIyNi4zOTQxNTFdIDJhZTNhIGlzIDc4Yzg3MDAwIQ0KWyAgMjI2LjM5NTg1MV0g
MmFlM2IgaXMgNzhjODYwMDAhDQpbICAyMjYuMzk3NTQxXSAyYWUzYyBpcyA3OGM4NTAwMCEN
ClsgIDIyNi4zOTkyMDddIDJhZTNkIGlzIDc4Yzg0MDAwIQ0KWyAgMjI2LjQwMTIzN10gMmFl
M2UgaXMgNzhjYzQwMDAhDQpbICAyMjYuNDIyMjI0XSAyYWUzZiBpcyAyMTZkMTAwMCENClsg
IDIyNi40MjM5NDVdIDJhZTQwIGlzIDIxNmQyMDAwIQ0KWyAgMjI2LjQyNTY3OV0gMmFlNDEg
aXMgMjE2Y2IwMDAhDQpbICAyMjYuNDI3NDI0XSAyYWU0MiBpcyAyMTZjYzAwMCENClsgIDIy
Ni40MjkxMzddIDJhZTQzIGlzIDIxZjVmMDAwIQ0KWyAgMjI2LjQzMDg2MF0gMmFlNDQgaXMg
MjFmNjAwMDAhDQpbICAyMjYuNDMyNTc2XSAyYWU0NSBpcyAyMWY1ZTAwMCENClsgIDIyNi40
MzQzMjhdIDJhZTQ2IGlzIDIxZjgwMDAwIQ0KWyAgMjI2LjQzNjA1MV0gMmFlNDcgaXMgMjFm
N2YwMDAhDQpbICAyMjYuNDM3ODEyXSAyYWU0OCBpcyAyMWY2NjAwMCENClsgIDIyNi40Mzk1
NDVdIDJhZTQ5IGlzIDIxZjY1MDAwIQ0KWyAgMjI2LjQ0MTUzMl0gMmFlNTUgaXMgNzhjNWYw
MDAhDQpbICAyMjYuNDQzMjkwXSAyYWU1NiBpcyA3OGM2MDAwMCENClsgIDIyNi40NDUwNjZd
IDJhZTU3IGlzIDc4YzYxMDAwIQ0KWyAgMjI2LjQ0Njg1MF0gMmFlNTggaXMgNzhjNjIwMDAh
DQpbICAyMjYuNDQ4NjAwXSAyYWU1OSBpcyA3OGM2MzAwMCENClsgIDIyNi40NTAzNzldIDJh
ZTVhIGlzIDc4YzY0MDAwIQ0KWyAgMjI2LjQ1MjExN10gMmFlNWIgaXMgNzhjNjUwMDAhDQpb
ICAyMjYuNDUzODg2XSAyYWU1YyBpcyA3OGM2NjAwMCENClsgIDIyNi40NTU2MjBdIDJhZTVk
IGlzIDc4YzY3MDAwIQ0KWyAgMjI2LjQ1NzM2OV0gMmFlNWUgaXMgNzhjNjgwMDAhDQpbICAy
MjYuNDU5MTE5XSAyYWU0YSBpcyA3OGM2OTAwMCENClsgIDIyNi40NjA4NjhdIDJhZTRiIGlz
IDc4YzZhMDAwIQ0KWyAgMjI2LjQ2MjYyM10gMmFlNGMgaXMgNzhjNmIwMDAhDQpbICAyMjYu
NDY0MzcxXSAyYWU0ZCBpcyA3OGM1ODAwMCENClsgIDIyNi40NjYxMTRdIDJhZTRlIGlzIDc4
YzU5MDAwIQ0KWyAgMjI2LjQ2Nzg2Ml0gMmFlNGYgaXMgNzhjNWEwMDAhDQpbICAyMjYuNDY5
NjAwXSAyYWU1MCBpcyA3OGM1YjAwMCENClsgIDIyNi40NzEzNzZdIDJhZTUxIGlzIDc4YzRj
MDAwIQ0KWyAgMjI2LjQ3MzE0MV0gMmFlNTIgaXMgNzhjNGQwMDAhDQpbICAyMjYuNDc0OTM0
XSAyYWU1MyBpcyAyMTZjNTAwMCENClsgIDIyNi40NzY3MzRdIDJhZTU0IGlzIDIxNmM2MDAw
IQ0KWyAgMjI2LjQ5MDQ4N10gMmFlNWYgaXMgNzhjNDQwMDAhDQpbICAyMjYuNDkyMjg2XSAy
YWU2MCBpcyA3OGM0NTAwMCENClsgIDIyNi40OTQyMzVdIDJhZTYxIGlzIDc4YzQ2MDAwIQ0K
WyAgMjI2LjQ5NjAyMV0gMmFlNjIgaXMgNzhjNDcwMDAhDQpbICAyMjYuNDk3Nzk3XSAyYWU2
MyBpcyA3OGM0ODAwMCENClsgIDIyNi40OTk1NTZdIDJhZTY0IGlzIDc4YzQ5MDAwIQ0KWyAg
MjI2LjUwMTMxNl0gMmFlNjUgaXMgNzhjNGEwMDAhDQpbICAyMjYuNTAzMDU1XSAyYWU2NiBp
cyA3OGM0YjAwMCENClsgIDIyNi41MDQ4MjBdIDJhZTY3IGlzIDc4YzVjMDAwIQ0KWyAgMjI2
LjUwNjU1NV0gMmFlNjggaXMgNzhjNWQwMDAhDQpbICAyMjYuNTA4MzIwXSAyYWU2OSBpcyA3
OGM1ZTAwMCENClsgIDIyNi41MTk4MTRdIDJhZTc0IGlzIDc4YzI3MDAwIQ0KWyAgMjI2LjUy
MTY3N10gMmFlNzMgaXMgNzhjMjgwMDAhDQpbICAyMjYuNTIzNDEyXSAyYWU3MiBpcyA3OGMy
OTAwMCENClsgIDIyNi41MjUxNDhdIDJhZTcxIGlzIDc4YzJhMDAwIQ0KWyAgMjI2LjUyNjg4
N10gMmFlNzAgaXMgNzhjMmIwMDAhDQpbICAyMjYuNTI4NjE5XSAyYWU2ZiBpcyA3OGMzMDAw
MCENClsgIDIyNi41MzAzNzJdIDJhZTZlIGlzIDc4YzMxMDAwIQ0KWyAgMjI2LjUzMjEwOF0g
MmFlNmQgaXMgNzhjMzIwMDAhDQpbICAyMjYuNTMzODc0XSAyYWU2YyBpcyA3OGMzMzAwMCEN
ClsgIDIyNi41MzU2MTJdIDJhZTZiIGlzIDc4YzM0MDAwIQ0KWyAgMjI2LjUzNzM4MF0gMmFl
NmEgaXMgNzhjMzUwMDAhDQpbICAyMjYuNTM5MjcyXSAyYWU3OCBpcyA3OGMxYzAwMCENClsg
IDIyNi41NDEwNDhdIDJhZTc5IGlzIDc4YzFkMDAwIQ0KWyAgMjI2LjU0Mjc5MV0gMmFlN2Eg
aXMgNzhjMWUwMDAhDQpbICAyMjYuNTQ0NTQ4XSAyYWU3YiBpcyA3OGMxZjAwMCENClsgIDIy
Ni41NDYzMDddIDJhZTdjIGlzIDc4YzIwMDAwIQ0KWyAgMjI2LjU0ODA2M10gMmFlN2QgaXMg
NzhjMjEwMDAhDQpbICAyMjYuNTQ5ODE4XSAyYWU3ZSBpcyA3OGMyMjAwMCENClsgIDIyNi41
NTE1NjhdIDJhZTdmIGlzIDc4YzIzMDAwIQ0KWyAgMjI2LjU1MzI3OF0gMmFlNzcgaXMgNzhj
MjQwMDAhDQpbICAyMjYuNTU1MDI4XSAyYWU3NiBpcyA3OGMyNTAwMCENClsgIDIyNi41NTY3
MjZdIDJhZTc1IGlzIDc4YzI2MDAwIQ0KWyAgMjI2LjU1ODQxOF0gMmFlODAgaXMgNzhjMTkw
MDAhDQpbICAyMjYuNTYwMTI3XSAyYWU4MSBpcyA3OGMxYTAwMCENClsgIDIyNi41NjE4NDBd
IDJhZTgyIGlzIDc4YzFiMDAwIQ0KWyAgMjI2LjU2NzIzNV0gMmFkZDcgaXMgNzhjMTMwMDAh
DQpbICAyMjYuNTY4OTYzXSAyYWU4MyBpcyA3OGMxNDAwMCENClsgIDIyNi41NzA3MjFdIDJh
ZTg0IGlzIDc4YzE1MDAwIQ0KWyAgMjI2LjU3MjQ0Ml0gMmFlODUgaXMgNzhjMTYwMDAhDQpb
ICAyMjYuNTc0MTc5XSAyYWU4NiBpcyA3OGMxNzAwMCENClsgIDIyNi41NzU5MTNdIDJhZTg3
IGlzIDc4YzE4MDAwIQ0KWyAgMjI2LjU4MjIwMV0gMmFlODggaXMgNzhjMTIwMDAhDQpbICAy
MjYuNTkzNDUyXSAyYWU5NCBpcyA3OGMxMTAwMCENClsgIDIyNi42MTkzNzFdIDJhZTk1IGlz
IDc4YmNmMDAwIQ0KWyAgMjI2LjYyMjAzNV0gMmFlODkgaXMgNzhiZGEwMDAhDQpbICAyMjYu
NjIzOTkwXSAyYWU5NiBpcyA3OGJkOTAwMCENClsgIDIyNi42MjU3NjVdIDJhZTk3IGlzIDc4
YmQ4MDAwIQ0KWyAgMjI2LjYyNzUzMF0gMmFlOTggaXMgNzhiZDcwMDAhDQpbICAyMjYuNjI5
Mjg4XSAyYWU5OSBpcyA3OGJkNjAwMCENClsgIDIyNi42MzEwNDRdIDJhZTlhIGlzIDc4YmQ1
MDAwIQ0KWyAgMjI2LjYzMjgwM10gMmFlOWIgaXMgNzhiZDQwMDAhDQpbICAyMjYuNjM0NTY1
XSAyYWU5YyBpcyA3OGJkMzAwMCENClsgIDIyNi42MzYzNTFdIDJhZTlkIGlzIDc4YmQyMDAw
IQ0KWyAgMjI2LjYzODEyMV0gMmFlOWUgaXMgNzhiZDEwMDAhDQpbICAyMjYuNjM5ODQzXSAy
YWU5ZiBpcyA3OGJkMDAwMCENClsgIDIyNi42NDE4MjJdIDJhZWE5IGlzIDc4YmY3MDAwIQ0K
WyAgMjI2LjY0MzU4M10gMmFlYWEgaXMgNzhiZjgwMDAhDQpbICAyMjYuNjQ1MzI3XSAyYWVh
YiBpcyA3OGJmOTAwMCENClsgIDIyNi42NDcwNzNdIDJhZWFjIGlzIDc4YzBjMDAwIQ0KWyAg
MjI2LjY0ODgxN10gMmFlYWQgaXMgNzhiZWEwMDAhDQpbICAyMjYuNjUwNTkzXSAyYWVhZSBp
cyA3OGJlOTAwMCENClsgIDIyNi42NTIzNTNdIDJhZWFmIGlzIDc4YmU4MDAwIQ0KWyAgMjI2
LjY1NDE0MF0gMmFlYjAgaXMgNzhiZTcwMDAhDQpbICAyMjYuNjU1OTEwXSAyYWViMSBpcyA3
OGJlNjAwMCENClsgIDIyNi42NTc2OTBdIDJhZWIyIGlzIDc4YmU1MDAwIQ0KWyAgMjI2LjY1
OTQzMV0gMmFlYjMgaXMgNzhiZTQwMDAhDQpbICAyMjYuNjYxMTg0XSAyYWVhMCBpcyA3OGJl
MzAwMCENClsgIDIyNi42NjI5NDJdIDJhZWExIGlzIDc4YmUyMDAwIQ0KWyAgMjI2LjY2NDY4
NF0gMmFlYTIgaXMgNzhiZTEwMDAhDQpbICAyMjYuNjY2NDI1XSAyYWVhMyBpcyA3OGJlMDAw
MCENClsgIDIyNi42NjgxNjFdIDJhZWE0IGlzIDc4YmRmMDAwIQ0KWyAgMjI2LjY2OTkxMl0g
MmFlYTUgaXMgNzhiZGUwMDAhDQpbICAyMjYuNjcxNjU0XSAyYWVhNiBpcyA3OGJkZDAwMCEN
ClsgIDIyNi42NzMzOTVdIDJhZWE3IGlzIDc4YmRjMDAwIQ0KWyAgMjI2LjY3NTEzMF0gMmFl
YTggaXMgNzhiZGIwMDAhDQpbICAyMjYuNjc3NTc1XSAyYWViNCBpcyA3OGMwMzAwMCENClsg
IDIyNi42NzkzMzNdIDJhZWI1IGlzIDc4YmZlMDAwIQ0KWyAgMjI2LjY4MTA1NF0gMmFlYjYg
aXMgNzhiZmYwMDAhDQpbICAyMjYuNjgyNzc4XSAyYWViNyBpcyA3OGMwMDAwMCENClsgIDIy
Ni42ODQ1MTJdIDJhZWI4IGlzIDc4YmYwMDAwIQ0KWyAgMjI2LjY4NjIzN10gMmFlYjkgaXMg
NzhiZWQwMDAhDQpbICAyMjYuNjg3OTg5XSAyYWViYSBpcyA3OGJlZTAwMCENClsgIDIyNi42
ODk3MTRdIDJhZWJiIGlzIDc4YmVmMDAwIQ0KWyAgMjI2LjY5MTQ2Nl0gMmFlYmMgaXMgNzhi
ZjEwMDAhDQpbICAyMjYuNjkzMjAyXSAyYWViZCBpcyA3OGJmNDAwMCENClsgIDIyNi42OTQ5
NzBdIDJhZWJlIGlzIDc4YmY1MDAwIQ0KWyAgMjI2LjY5Njg5NV0gMmFlYzcgaXMgNzhjMDQw
MDAhDQpbICAyMjYuNzEwMjg0XSAyYWVjMiBpcyA3OTVjYTAwMCENClsgIDIyNi43MTIwODNd
IDJhZWMxIGlzIDc5NWNiMDAwIQ0KWyAgMjI2LjcxMzg3OV0gMmFlYzAgaXMgNzhiY2MwMDAh
DQpbICAyMjYuNzE1NjczXSAyYWViZiBpcyA3OGJjZDAwMCENClsgIDIyNi43MTk0NDVdIDJh
ZWMzIGlzIDc5NWMyMDAwIQ0KWyAgMjI2LjcyMTI2NV0gMmFlYzQgaXMgNzk1YzMwMDAhDQpb
ICAyMjYuNzIzMDQ0XSAyYWVjNSBpcyA3OTVjNDAwMCENClsgIDIyNi43MjQ4NTVdIDJhZWM2
IGlzIDc5NWM1MDAwIQ0KWyAgMjI2LjcyODU5Ml0gMmFlYzggaXMgNzk1YzEwMDAhDQpbICAy
MjYuNzMyNzQ5XSAyYWVjOSBpcyA3OTVjMDAwMCENClsgIDIyNi43Mzg0MjVdIDJhZWNhIGlz
IDc5NWJmMDAwIQ0KWyAgMjI2Ljc0MDkyMV0gMmFlY2IgaXMgNzk1YmUwMDAhDQpbICAyMjYu
NzQzMDYyXSAyYWVjYyBpcyA3OTViZDAwMCENClsgIDIyNi43NDUyMjddIDJhZWNkIGlzIDc5
NWJjMDAwIQ0KWyAgMjI2Ljc0OTc2NV0gMmFlY2UgaXMgNzk1YmIwMDAhDQpbICAyMjYuNzUx
OTEwXSAyYWVjZiBpcyA3OTViYTAwMCENClsgIDIyNi43NTQwNjZdIDJhZWQxIGlzIDc5NWI5
MDAwIQ0KWyAgMjI2Ljc1NjAxNF0gMmFlZDUgaXMgNzk1YjgwMDAhDQpbICAyMjYuNzY1OTQ5
XSAyYWVkNCBpcyA3OTViNjAwMCENClsgIDIyNi43NzYzOThdIDJhZWQ2IGlzIDc5NWIyMDAw
IQ0KWyAgMjI2Ljc3ODM1OF0gMmFlZDcgaXMgNzk1YjMwMDAhDQpbICAyMjYuNzgwMTM1XSAy
YWVkOCBpcyA3OTViNDAwMCENClsgIDIyNi43ODE4ODVdIDJhZWQ5IGlzIDc5NWI1MDAwIQ0K
WyAgMjI2Ljc4NTYzMF0gMmFlZGEgaXMgNzk1YjEwMDAhDQpbICAyMjYuNzg5Nzg1XSAyYWVk
YiBpcyA3OGMwNTAwMCENClsgIDIyNi43OTk2MjRdIDJhZWRjIGlzIDc5NWFmMDAwIQ0KWyAg
MjI2LjgxMzQxNF0gMmFlZGQgaXMgNzk1YWUwMDAhDQpbICAyMjYuODE1NTI4XSAyYWVkZSBp
cyA3OTVhZDAwMCENClsgIDIyNi44MTc4MzZdIDJhZWRmIGlzIDc5NWFjMDAwIQ0KWyAgMjI2
LjgxOTk1Ml0gMmFlZTAgaXMgNzk1YWIwMDAhDQpbICAyMjYuODIyMDc3XSAyYWVlMSBpcyA3
OTVhYTAwMCENClsgIDIyNi44MjQ1OTVdIDJhZWViIGlzIDc5NWE5MDAwIQ0KWyAgMjI2Ljgy
NjMxNV0gMmFlZTcgaXMgNzk1YTEwMDAhDQpbICAyMjYuODI4MDcxXSAyYWVlOCBpcyA3OTVh
MjAwMCENClsgIDIyNi44Mjk3NzddIDJhZWU5IGlzIDc5NWEzMDAwIQ0KWyAgMjI2LjgzMTQ5
OF0gMmFlZWEgaXMgNzk1YTQwMDAhDQpbICAyMjYuODMzMjAzXSAyYWVlMyBpcyA3OTVhODAw
MCENClsgIDIyNi44MzQ5MDddIDJhZWU0IGlzIDc5NWE1MDAwIQ0KWyAgMjI2LjgzNjYwM10g
MmFlZTUgaXMgNzk1YTYwMDAhDQpbICAyMjYuODM4Mjk2XSAyYWVlNiBpcyA3OTVhNzAwMCEN
ClsgIDIyNi44NDM3MzBdIDJhZWVjIGlzIDIxNzdjMDAwIQ0KWyAgMjI2Ljg2NDcyMV0gMmFl
ZTIgaXMgNzk1NmUwMDAhDQpbICAyMjYuODY2NDc1XSAyYWVkMCBpcyA3OTU4ODAwMCENClsg
IDIyNi44NzE3OTRdIDJhZThhIGlzIDc5NTljMDAwIQ0KWyAgMjI2Ljg4NDQzNV0gMmFlOGIg
aXMgNzk1NjEwMDAhDQpbICAyMjYuOTAyNzExXSAyYWU4YyBpcyA3OTU0ZDAwMCENClsgIDIy
Ni45Mzc2ODRdIDJhZThkIGlzIDc5NTU0MDAwIQ0KWyAgMjI2Ljk0MTc1NV0gMmFlOGUgaXMg
Nzk1NTMwMDAhDQpbICAyMjYuOTYyNjQ2XSAyYWU5MSBpcyAyMTVlYjAwMCENClsgIDIyNi45
NjQ2MzZdIDJhZTkwIGlzIDc5NTNiMDAwIQ0KWyAgMjI2Ljk2NjQ2M10gMmFlOGYgaXMgNzk1
NDEwMDAhDQpbICAyMjYuOTY4MzAxXSAyYWVmMyBpcyAyMTZiMDAwMCENClsgIDIyNi45NzAy
MDBdIDJhZTkzIGlzIDIxZTY5MDAwIQ0KWyAgMjI2Ljk3MjI4OV0gMmFlZjQgaXMgNzk1OGMw
MDAhDQpbICAyMjYuOTc0MjQ3XSAyYWVmNSBpcyA3OTUzYTAwMCENClsgIDIyNi45NzYxMzdd
IDJhZTkyIGlzIDc5NTNlMDAwIQ0KWyAgMjI2Ljk3ODA0NV0gMmFlZjYgaXMgNzk1M2QwMDAh
DQpbICAyMjcuMDA3NTMwXSAyYWVlZCBpcyA3OTU2YzAwMCENClsgIDIyNy4wMDk0MzddIDJh
ZWY3IGlzIDc5NTY3MDAwIQ0KWyAgMjI3LjAxMTM2MF0gMmFlZjggaXMgNzk1OGIwMDAhDQpb
ICAyMjcuMDEzMjUyXSAyYWVmOSBpcyAyMTZkNzAwMCENClsgIDIyNy4wMTU4MTBdIDJhZWZi
IGlzIDc5NTM4MDAwIQ0KWyAgMjI3LjAxNzc3NF0gMmFlZmMgaXMgNzk1ODUwMDAhDQpbICAy
MjcuMDE5NzI0XSAyYWVmZCBpcyA3OTU2NTAwMCENClsgIDIyNy4wMjE2ODZdIDJhZWZlIGlz
IDc5NThlMDAwIQ0KWyAgMjI3LjAyMzY3Nl0gMmFlZmYgaXMgNzk1M2YwMDAhDQpbICAyMjcu
MDI1NjE1XSAyYWYwMCBpcyA3OTU4MTAwMCENClsgIDIyNy4wMjgxNzBdIDJhZjAxIGlzIDc5
NTFkMDAwIQ0KWyAgMjI3LjA1Mjg2NF0gMmFlZmEgaXMgNzhjZGIwMDAhDQpbICAyMjcuMDY5
MDQ5XSAyYWYwMiBpcyA3OTUyMzAwMCENClsgIDIyNy4wNzY2ODZdIDJhZjAzIGlzIDc5NTBl
MDAwIQ0KWyAgMjI3LjA5MDY2NV0gMmFmMDQgaXMgNzk1MWEwMDAhDQpbICAyMjcuMTE1ODA3
XSAyYWYwNSBpcyA3OTU3MTAwMCENClsgIDIyNy4xMTc5MDhdIDJhZjA2IGlzIDc4YzU2MDAw
IQ0KWyAgMjI3LjExOTk2MF0gMmFmMDcgaXMgMjE3NzkwMDAhDQpbICAyMjcuMTIyMDAyXSAy
YWYwOCBpcyAyMTc4MDAwMCENClsgIDIyNy4xMjQ1NTddIDJhZjA5IGlzIDc4Y2M5MDAwIQ0K
WyAgMjI3LjUwNDEzNV0gMmFmMTMgaXMgMjFlNjEwMDAhDQpbICAyMjcuNTA2MzQwXSAyYWYx
NCBpcyA3OTIyMjAwMCENClsgIDIyNy41MDg0MjZdIDJhZjE1IGlzIDc5MjBlMDAwIQ0KWyAg
MjI3LjUxMDUwOF0gMmFmMTYgaXMgNzkyYzEwMDAhDQpbICAyMjcuNTEyNTU4XSAyYWYxNyBp
cyA3OTI3YjAwMCENClsgIDIyNy41MjQyOTFdIDJhZjIxIGlzIDIxNmQ4MDAwIQ0KWyAgMjI3
LjUyNjMzM10gMmFmMjIgaXMgNzkyMWMwMDAhDQpbICAyMjcuNTI4NDIyXSAyYWYwZSBpcyA3
YTYzZjAwMCENClsgIDIyNy41MzA1MDFdIDJhZjBkIGlzIDIxODg1MDAwIQ0KWyAgMjI3LjUz
MjU5Nl0gMmFlZWUgaXMgNzkyMWYwMDAhDQpbICAyMjcuNTM0NzI0XSAyYWYwYSBpcyA3OTIw
ZDAwMCENClsgIDIyNy41MzY4ODBdIDJhZjBjIGlzIDc5MjEwMDAwIQ0KWyAgMjI3LjUzODk3
Nl0gMmFmMTggaXMgNzkxZjkwMDAhDQpbICAyMjcuNTQxMTI3XSAyYWYxMSBpcyA3OTFmYTAw
MCENClsgIDIyNy41NDMyMzRdIDJhZjEyIGlzIDc5MjQ2MDAwIQ0KWyAgMjI3LjU0NTM2Nl0g
MmFmMTAgaXMgMjFhNGQwMDAhDQpbICAyMjcuNTQ3NDc2XSAyYWYwZiBpcyA3OTI4ZTAwMCEN
ClsgIDIyNy41NDk2MDZdIDJhZjBiIGlzIDc5MjBjMDAwIQ0KWyAgMjI3LjU1MTczOF0gMmFm
MWEgaXMgNzkyMGYwMDAhDQpbICAyMjcuNTUzODg2XSAyYWYxOSBpcyAyMWExMDAwMCENClsg
IDIyNy41NTYwNDZdIDJhZjFkIGlzIDc5NTJhMDAwIQ0KWyAgMjI3LjU1ODIxMV0gMmFmMWUg
aXMgNzhiZWIwMDAhDQpbICAyMjcuNTYwNDA1XSAyYWYxZiBpcyA3OTU5ZDAwMCENClsgIDIy
Ny41NjI1NTVdIDJhZjIwIGlzIDIxNzdjMDAwIQ0KWyAgMjI4LjEyNjY1NF0gMmFmMjMgaXMg
NzhmODIwMDAhDQpbICAyMjguNDIxOTYwXSAyYWYyNCBpcyA3YTBkNDAwMCENClsgIDIyOC40
MjU1NDhdIDJhZjI1IGlzIDJkY2ZiMDAwIQ0KWyAgMjI4LjQyNzgwMV0gMmFlZWYgaXMgN2E2
YjgwMDAhDQpbICAyMjguNDMwMDYyXSAyYWVmMCBpcyAyMWUwMDAwMCENClsgIDIyOC40MzIy
OTFdIDJhZWYxIGlzIDIxZGZmMDAwIQ0KWyAgMjI4LjQzNDU1NF0gMmFlZjIgaXMgMmRjYzIw
MDAhDQpbICAyMjguNDM2ODA0XSAyYWYzMSBpcyA3YTI0MTAwMCENClsgIDIyOC40MzkwMzhd
IDJhZjMyIGlzIDJkY2MxMDAwIQ0KWyAgMjI4LjQ0MTI2OV0gMmFmMzMgaXMgN2EyMGYwMDAh
DQpbICAyMjguNDQzNTQwXSAyYWYzNCBpcyA3YTZjODAwMCENClsgIDIyOC40NDU3NzRdIDJh
ZjM1IGlzIDI2ZWFmMDAwIQ0KWyAgMjI4LjQ0ODA3Ml0gMmFmMzYgaXMgMjZlYjAwMDAhDQpb
ICAyMjguNDUwNzA0XSAyYWY0MiBpcyAyNGRmZjAwMCENClsgIDIyOC40NTI5NjddIDJhZjQz
IGlzIDI0ZTAwMDAwIQ0KWyAgMjI4LjQ1NTMyOV0gMmFmNDQgaXMgNzk2ZmIwMDAhDQpbICAy
MjguNDU3NTgwXSAyYWY0NSBpcyAyMWRlZDAwMCENClsgIDIyOC40NTk4MjddIDJhZjQ2IGlz
IDJiNDg5MDAwIQ0KWyAgMjI4LjQ2MjA4MF0gMmFmNDcgaXMgMjUyNjgwMDAhDQpbICAyMjgu
NDY0MzY0XSAyYWY0OCBpcyAyZGNmNTAwMCENClsgIDIyOC40NjY2MDNdIDJhZjQ5IGlzIDI1
ZGI3MDAwIQ0KWyAgMjI4LjQ2ODkwNl0gMmFmNGEgaXMgMmRjZjQwMDAhDQpbICAyMjguNDcx
MTU5XSAyYWY0YiBpcyAyNTMwNDAwMCENClsgIDIyOC40NzM0MjhdIDJhZjRjIGlzIDI0ZGZk
MDAwIQ0KWyAgMjI4LjQ3NTY3NV0gMmFmNGQgaXMgMjU0NjUwMDAhDQpbICAyMjguNDc3OTM4
XSAyYWY0ZSBpcyAyZGNmOTAwMCENClsgIDIyOC40ODAyMjRdIDJhZjRmIGlzIDI1NTM2MDAw
IQ0KWyAgMjI4LjQ4MjQ3OV0gMmFmNTAgaXMgMjRlMTgwMDAhDQpbICAyMjguNDg0NzcwXSAy
YWY1MSBpcyAyNGUyNDAwMCENClsgIDIyOC40ODcwMjhdIDJhZjUyIGlzIDI0ZTBkMDAwIQ0K
WyAgMjI4LjQ4OTI3MV0gMmFmNTMgaXMgNzk2ZjcwMDAhDQpbICAyMjguNDkxNTQ5XSAyYWY1
NCBpcyAyMWUzZjAwMCENClsgIDIyOC40OTM4MjhdIDJhZjU1IGlzIDc5MjU4MDAwIQ0KWyAg
MjI4LjQ5NjA0OV0gMmFmNTYgaXMgNzk0NzcwMDAhDQpbICAyMjguNDk4MjkwXSAyYWY1NyBp
cyAyYWU1YTAwMCENClsgIDIyOC41MDA1MTddIDJhZjU4IGlzIDI0ZTIyMDAwIQ0KWyAgMjI4
LjUwMjcwM10gMmFmNTkgaXMgMmI0OGQwMDAhDQpbICAyMjguNTA0OTI0XSAyYWY1YSBpcyAy
NTFiMDAwMCENClsgIDIyOC41MDcxMzJdIDJhZjViIGlzIDI1MjA1MDAwIQ0KWyAgMjI4LjUw
OTMyM10gMmFmNWMgaXMgMmRjZmEwMDAhDQpbICAyMjguNTExNTEyXSAyYWY1ZCBpcyAyNTQ2
NDAwMCENClsgIDIyOC41MTM3MzddIDJhZjVlIGlzIDJkY2Y3MDAwIQ0KWyAgMjI4LjUxNTky
M10gMmFmMzcgaXMgMjRlMDMwMDAhDQpbICAyMjguNTE4MTI5XSAyYWYzOCBpcyAyNGRmZTAw
MCENClsgIDIyOC41MjAzMjVdIDJhZjM5IGlzIDJkY2ZjMDAwIQ0KWyAgMjI4LjUyMjUwMl0g
MmFmM2EgaXMgMjRlMDIwMDAhDQpbICAyMjguNTI0Njg0XSAyYWYzYiBpcyA3YTIyODAwMCEN
ClsgIDIyOC41MjY4ODVdIDJhZjNjIGlzIDIxZGVlMDAwIQ0KWyAgMjI4LjUyOTA0OF0gMmFm
M2QgaXMgMmRjYzkwMDAhDQpbICAyMjguNTMxMjQxXSAyYWYzZSBpcyAyN2E5ZDAwMCENClsg
IDIyOC41MzM0MTNdIDJhZjNmIGlzIDI3YzljMDAwIQ0KWyAgMjI4LjUzNTU3NF0gMmFmNDAg
aXMgMmRjZDgwMDAhDQpbICAyMjguNTM3NzM0XSAyYWY0MSBpcyAyZGNmZDAwMCENClsgIDIy
OC41NTc5MzRdIDJiMzZmIGlzIDI2ZTdkMDAwIQ0KWyAgMjU4LjU3MjI2MF0gMmFmMmIgaXMg
Nzk2ZjcwMDAhDQpbICAyNTguNTc0NTMyXSAyYWYyYyBpcyAyNTMwNDAwMCENClsgIDI1OC41
NzY3NTBdIDJhZjJkIGlzIDc5NmZiMDAwIQ0KWyAgMjU4LjU3ODk0N10gMmFmMmUgaXMgMjFk
ZWUwMDAhDQpbICAyNTguNTgxMTUwXSAyYWYyZiBpcyAyNTUzNjAwMCENClsgIDI1OC41ODMz
NDldIDJhZjMwIGlzIDJhZTVhMDAwIQ0KWyAgMjU4LjU4NTU3NF0gMmIxNTYgaXMgMjUyMDUw
MDAhDQpbICAyNTguNTg3ODQ2XSAyYjE1NyBpcyAyZGNmYTAwMCENClsgIDI1OC41OTAxNTld
IDJhZjkwIGlzIDJkY2ZiMDAwIQ0KWyAgMjU4LjU5MjQyNl0gMmFmOTEgaXMgMjUyNjgwMDAh
DQpbICAyNTguNjAxMTE3XSAyYWY5MiBpcyAyNTFiMDAwMCENClsgIDI1OC42MDMzOTldIDJh
Zjk0IGlzIDJiNDhkMDAwIQ0KWyAgMjU4LjYwNTYzN10gMmIzNjcgaXMgMmI0ODkwMDAhDQpb
ICAyNTguNjA3ODgzXSAyYWY2YyBpcyAyZGNmOTAwMCENClsgIDI1OC42MTAxMjRdIDJhZjZi
IGlzIDI1NDY0MDAwIQ0KWyAgMjU4LjYxMjM2Nl0gMmFmNjYgaXMgMjU0NjUwMDAhDQpbICAy
NTguNjE0NTk5XSAyYWY2NSBpcyAyZGNmNzAwMCENClsgIDI1OC42MTY4NDVdIDJhZjYzIGlz
IDJkY2Y0MDAwIQ0KWyAgMjU4LjYxOTAzNV0gMmFmNjQgaXMgMmRjZjUwMDAhDQpbICAyNTgu
NjIxMjM0XSAyYWY2MiBpcyAyNWRiNzAwMCENClsgIDI1OC42MjM0MTJdIDJhZjFiIGlzIDdh
NmM4MDAwIQ0KWyAgMjU4LjYyNTYxM10gMmFmNWYgaXMgMjFlMDAwMDAhDQpbICAyNTguNjI3
ODI0XSAyYWYxYyBpcyAyMWRmZjAwMCENClsgIDI1OC42MzAwNTRdIDJhZjYwIGlzIDJkY2My
MDAwIQ0KWyAgMjU4LjYzMjI1Ml0gMmFmNjEgaXMgMmRjYzEwMDAhDQpbICAyNTguNjM0NDU1
XSAyYWYyOSBpcyAyN2E5ZDAwMCENClsgIDI1OC42MzY2MjhdIDJhZjI4IGlzIDI3YzljMDAw
IQ0KWyAgMjU4LjYzODgyMF0gMmFmMjcgaXMgMmRjZDgwMDAhDQpbICAyNTguNjQwOTk4XSAy
YWYyNiBpcyAyZGNjOTAwMCENClsgIDI1OC42NDMxNzFdIDJhZjJhIGlzIDc5MjU4MDAwIQ0K
WyAgMjU4LjY0NTQ4OF0gMmFmOTYgaXMgMjFlM2YwMDAhDQpbICAyODcuMDQ1MjM5XSAyYWY3
NyBpcyAyMTdiYTAwMCENClsgIDI4Ny4wNDc2MjVdIDJhZjk3IGlzIDIxNWY5MDAwIQ0KWyAg
Mjg3LjA0OTgwM10gMmFmOTggaXMgN2E2MTkwMDAhDQpbICAyODcuMDUxOTk5XSAyYWY5OSBp
cyA3OTU4YTAwMCENClsgIDI4Ny4wNTQ4MzRdIDJhZjlhIGlzIDdhNjVlMDAwIQ0KWyAgMjg3
LjA1NzIyNl0gMmFmNzggaXMgNzk1OTAwMDAhDQpbICAyODcuMDU5Mzc0XSAyYWY3OSBpcyA3
OGY4ODAwMCENClsgIDI4Ny4wNjE1NDRdIDJhZjdhIGlzIDc5MjE4MDAwIQ0KWyAgMjg3LjA2
MzY5NF0gMmFmN2IgaXMgMjE2NjIwMDAhDQpbICAyODcuMDY1ODMyXSAyYWY3YyBpcyA3OTU1
MjAwMCENClsgIDI4Ny4wNjgwNjJdIDJhZjdkIGlzIDIxZjYxMDAwIQ0KWyAgMjg3LjA3MDIy
M10gMmFmN2UgaXMgMjE3NzgwMDAhDQpbICAyODcuMDcyMzMzXSAyYWY3ZiBpcyA3YTc0ODAw
MCENClsgIDI4Ny4wNzQ0NjRdIDJhZjgwIGlzIDc5NTc4MDAwIQ0KWyAgMjg3LjA3NjU1OF0g
MmFmODEgaXMgNzkyMjEwMDAhDQpbICAyODcuMDc4NjcxXSAyYWY4MiBpcyA3YTc0NzAwMCEN
ClsgIDI4Ny4wODA4MDBdIDJhZjgzIGlzIDIxNjAxMDAwIQ0KWyAgMjg3LjA4MjkxMF0gMmFm
ODQgaXMgMjE1ZGEwMDAhDQpbICAyODcuMDg1MDU5XSAyYWY4NSBpcyAyMTVmNDAwMCENClsg
IDI4Ny4wODcyMDNdIDJhZjg2IGlzIDc4ZjgxMDAwIQ0KWyAgMjg3LjA4OTM1MV0gMmFmODcg
aXMgMjE5ZGQwMDAhDQpbICAyODcuMDkxOTQ4XSAyYWY4OSBpcyA3OTU3NTAwMCENClsgIDI4
Ny4wOTQxNjJdIDJhZjhhIGlzIDc4ZmM0MDAwIQ0KWyAgOTE0LjM0MzQ2N10gMmFmOGIgaXMg
Nzk1NjMwMDAhDQpbICA5MTQuMzU5OTI0XSAyYWZhYiBpcyA3OTUwZjAwMCENClsgIDkxNC4z
NzE5NTldIDM3NGZhIGlzIDIxNWQ2MDAwIQ0KWyAgOTE0LjM4OTE5M10gMzdkZmEgaXMgNzk1
N2QwMDAhDQpbICA5MTQuMzkyMTcxXSAyYWZhMiBpcyA3OTU3YzAwMCENClsgIDkxNC4zOTUx
NDZdIDM5MTAwIGlzIDc5NTU3MDAwIQ0KWyAgOTE0LjM5ODExMF0gMmFmYWEgaXMgNzk1NTYw
MDAhDQpbICA5MTQuNDA5MDIzXSAyYWZhYyBpcyA3OTU2ZDAwMCENClsgIDkxNC40MTIwOTFd
IDJhZmEwIGlzIDc4YzUzMDAwIQ0KWyAgOTE0LjQxNTA2M10gMzc1MGYgaXMgNzhjNTEwMDAh
DQpbICA5MTQuNDE4MDM4XSAzNmY4MSBpcyAyMTc3NzAwMCENClsgIDkxNC40MjEwNDZdIDM3
ZWQwIGlzIDc5NTg0MDAwIQ0KWyAgOTE0LjQyNDA0Nl0gMzY1MTUgaXMgNzk1OWIwMDAhDQpb
ICA5MTQuNDI3MDM4XSAzN2U5YyBpcyA3OTUxYjAwMCENClsgIDkxNC40MzAwMjRdIDM2NTMx
IGlzIDc5NTI3MDAwIQ0KWyAgOTE0LjQzMzM2MF0gMzhjMmQgaXMgNzk0ODEwMDAhDQpbICA5
MTQuNDM2Mzg4XSAzNzg2ZCBpcyA3YTY4MjAwMCENClsgIDkxNC40Mzk0MDZdIDM3NjJkIGlz
IDc5NWEwMDAwIQ0KWyAgOTE0LjQ0MjQ1M10gMzZlYjggaXMgNzk1NWYwMDAhDQpbICA5MTQu
NDQ1NDc5XSAyYWY4ZCBpcyAyMTVkNzAwMCENClsgIDkxNC40NDg1MzRdIDM3ZTVjIGlzIDc5
NTU1MDAwIQ0KWyAgOTE0LjQ1MTYxNF0gMzdlOGIgaXMgNzk1OTYwMDAhDQpbICA5MTQuNDU0
NjY1XSAzNmViOSBpcyA3OTU0NTAwMCENClsgIDkxNC40NTc3MDhdIDM2NGZkIGlzIDIxNmFk
MDAwIQ0KWyAgOTE0LjQ2MDc5N10gMzY0M2MgaXMgNzk1NWMwMDAhDQpbICA5MTQuNDYzODk0
XSAzNmUzZSBpcyA3OTUyNTAwMCENClsgIDkxNC40NjY5NTNdIDM2ZTNmIGlzIDc5NTY4MDAw
IQ0KWyAgOTE0LjQ3MDAwNl0gMzhkMTMgaXMgNzk1NjkwMDAhDQpbICA5MTQuNDczMTYyXSAy
YWZhZCBpcyA3OTUxODAwMCENClsgIDkxNC40NzYyMDRdIDJhZjhjIGlzIDc5NTE5MDAwIQ0K
WyAgOTE0LjQ3OTA1M10gMzgzMzggaXMgNzk1MjQwMDAhDQpbICA5MTQuNTcwMzIzXSAzN2Vk
MSBpcyA3OTU3MjAwMCENClsgIDkxNC41NzI4NzNdIDJhZmE2IGlzIDc5NTczMDAwIQ0KWyAg
OTE0LjU3NTIxMF0gMmFmYTcgaXMgNzk1MjAwMDAhDQpbICA5MTQuNTc3NTI4XSAyYWZhOCBp
cyA3OTUyMTAwMCENClsgIDkxNC41ODAyMzRdIDM5MmExIGlzIDc5NTA0MDAwIQ0KWyAgOTE5
LjQyMTkzMV0gMmFmYTkgaXMgMjRlMjIwMDAhDQpbICA5MTkuNDI0MzAyXSAzNzZhMCBpcyAy
NGUwZDAwMCENClsgIDkxOS40MjY2MTFdIDJhZmE0IGlzIDI2ZTdjMDAwIQ0KWyAgOTE5LjQ2
Mzc0NV0gMmFmYTUgaXMgNzk0ZTkwMDAhDQpbICA5MjQuNTkyMTM0XSAyYWY5ZSBpcyA3OTUw
MzAwMCENClsgIDkyNC42MjQ4OTZdIDJhZjlmIGlzIDc5NGUzMDAwIQ0KWyAgOTI0LjYyNzI1
OV0gMzc3M2MgaXMgNzk0ZTQwMDAhDQpbICA5MjQuNjI5NTgxXSAyYWY5YyBpcyA3OTRlNTAw
MCENClsgIDkyNC42NTkxNzFdIDM5MGNhIGlzIDc5NGUyMDAwIQ0KWyAgOTI0LjY4MjUzMl0g
MmFmYTMgaXMgNzk0ZGUwMDAhDQpbICA5MjQuNjg0OTQxXSAzODE5MCBpcyA3OTRkZjAwMCEN
ClsgIDkyNC42ODczMTJdIDM4MTkxIGlzIDc5NGUwMDAwIQ0KWyAgOTI0LjY4OTY0NV0gM2Ey
NGUgaXMgNzk0ZTEwMDAhDQpbICA5MjQuNjkyNzM4XSAzYTI0ZiBpcyA3OTRkNjAwMCENClsg
IDkyNC42OTUxMjhdIDM4NDlhIGlzIDc5NGQ3MDAwIQ0KWyAgOTI0LjY5NzQ0NV0gMzg0OWIg
aXMgNzk0ZDgwMDAhDQpbICA5MjQuNjk5NjgxXSAzYTIwMiBpcyA3OTRkOTAwMCENClsgIDky
NC43MDE5NTldIDNhMjAzIGlzIDc5NGRhMDAwIQ0KWyAgOTI0LjcwNDIyMF0gM2EyMGEgaXMg
Nzk0ZGIwMDAhDQpbICA5MjQuNzA2NDQyXSAzYTIwYiBpcyA3OTRkYzAwMCENClsgIDkyNC43
MDg2NDBdIDM4MTlhIGlzIDc5NGRkMDAwIQ0KWyAgOTI0LjcxMDg2MV0gMzgxOWIgaXMgNzk0
ZDUwMDAhDQpbICA5MjQuNzEzNTAxXSAzYTMwYyBpcyA3OTRkMzAwMCENClsgIDkyNC43MTU3
MjFdIDNhMzBkIGlzIDc5NGQ0MDAwIQ0KWyAgOTI0LjcxODMwOV0gMzgyMDEgaXMgNzk0ZDIw
MDAhDQpbICA5MjQuNzIwODc1XSAzODE5YyBpcyA3OTRkMTAwMCENClsgIDkyNC43NDM3NzFd
IDM4MTlkIGlzIDc5NGNmMDAwIQ0KWyAgOTI0Ljc0NTkwMF0gMmFmYWUgaXMgNzk0ZDAwMDAh
DQpbICA5MjQuNzU1Mzc0XSAzODIwMCBpcyA3OTZjNjAwMCENClsgIDkyNC43NTc1NzhdIDJh
ZmFmIGlzIDc5NGNkMDAwIQ0KWyAgOTI0Ljc1OTc1Nl0gMmFmYjAgaXMgNzk0Y2UwMDAhDQpb
ICA5MjQuNzYyNDg2XSAyYWZiMSBpcyA3OTZjMjAwMCENClsgIDkyNC43NjQ2NDNdIDJhZmIy
IGlzIDc5NmMzMDAwIQ0KWyAgOTI0Ljc2Njc1M10gMmFmYjMgaXMgNzk2YzQwMDAhDQpbICA5
MjQuNzY4ODIzXSAyYWZiNCBpcyA3OTZjNTAwMCENClsgIDkyNC43NzEyNDVdIDJhZmI1IGlz
IDc5NmMxMDAwIQ0KWyAgOTI0Ljc4MTQ1M10gMmFmYjYgaXMgNzk2YzAwMDAhDQpbICA5Mjgu
MDg0OTk4XSAyYWZiNyBpcyA3OTZiZjAwMCENClsgIDkyOC4wODg1NjVdIDJhZjg4IGlzIDc5
NmJlMDAwIQ0KWyAgOTI4LjA5MTA1MV0gMmFmOWIgaXMgNzk2YmQwMDAhDQpbICA5MjguMTA1
NzY0XSAzNmU4NiBpcyA3OTZiYzAwMCENClsgIDkyOC4xMTcyNTddIDM4YzU0IGlzIDc5NmI4
MDAwIQ0KWyAgOTI4LjEzMTAyNV0gMmFmZTcgaXMgNzk2YWMwMDAhDQpbICA5MjguMTMzMDA0
XSAyYWZlOCBpcyA3OTZhYjAwMCENClsgIDkyOC4xMzQ5OTFdIDJhZmU5IGlzIDIxNmRiMDAw
IQ0KWyAgOTI4LjEzNzAxM10gMmFmZWEgaXMgNzk1OTUwMDAhDQpbICA5MjguMTM4OTk1XSAy
YWZlYiBpcyA3OTU2NjAwMCENClsgIDkyOC4xNDA5ODFdIDJhZmVjIGlzIDIxOWMxMDAwIQ0K
WyAgOTI4LjE0Mjk2N10gMmFmZWQgaXMgNzk2ZWEwMDAhDQpbICA5MjguMTQ1MDg0XSAyYWZl
ZSBpcyA3OTZiMzAwMCENClsgIDkyOC4xNDcxMjhdIDJhZmVmIGlzIDdhNWU2MDAwIQ0KWyAg
OTI4LjE0OTEyOV0gMmFmZjAgaXMgNzk2YWUwMDAhDQpbICA5MjguMTUxMTY3XSAyYWZmMSBp
cyA3OTQ0ZDAwMCENClsgIDkyOC4xNTMxNzJdIDJhZmYyIGlzIDc5NTZmMDAwIQ0KWyAgOTI4
LjE1NTIwN10gMmFmZjMgaXMgNzhjNTUwMDAhDQpbICA5MjguMTU3ODE2XSAyYWZmNCBpcyA3
OTZhNjAwMCENClsgIDkyOC4xNTk5MzBdIDJhZmY1IGlzIDc5NmE3MDAwIQ0KWyAgOTI4LjE2
MTk3Nl0gMmFmZjYgaXMgMjE2YzMwMDAhDQpbICA5MjguMTY0MDM4XSAyYWZmNyBpcyA3OTUw
MDAwMCENClsgIDkyOC4xNjYwNTZdIDJhZmY4IGlzIDc5NmQxMDAwIQ0KWyAgOTI4LjE2ODE4
Ml0gMmFmZjkgaXMgNzk1OGQwMDAhDQpbICA5MjguMTcwMTkzXSAyYWZmYSBpcyAyMWU0YTAw
MCENClsgIDkyOC4xNzIyMDRdIDJhZmZiIGlzIDc5NTcwMDAwIQ0KWyAgOTI4LjE3NDIzNF0g
MmFmZmMgaXMgNzk1MzkwMDAhDQpbICA5MjguMTc2MjU0XSAyYWZmZCBpcyA3OTUzYzAwMCEN
ClsgIDkyOC4xNzgyNzFdIDJhZmZlIGlzIDc5NTU4MDAwIQ0KWyAgOTI4LjE4MDMxMV0gMmFm
ZmYgaXMgNzk1OTEwMDAhDQpbICA5MjguMTgyMzE1XSAyYTQwMCBpcyAyMTVmMDAwMCENClsg
IDkyOC4xODQzNzJdIDJhNDAxIGlzIDIxZjYzMDAwIQ0KWyAgOTI4LjE4NjM4MV0gMmE0MDIg
aXMgMjE2Y2QwMDAhDQpbICA5MjguMTg4NDI1XSAyYTQwMyBpcyA3OTU0YjAwMCENClsgIDky
OC4yMDAzMzddIDJhNDA0IGlzIDc5NjliMDAwIQ0KWyAgOTI4LjIwMjQwNF0gMmE0MDYgaXMg
Nzk2OWMwMDAhDQpbICA5MjguMjA0NTEwXSAyYTQwNyBpcyA3OTY5ZDAwMCENClsgIDkyOC4y
MDY0NjZdIDJhNDA4IGlzIDc5NjllMDAwIQ0KWyAgOTI4LjIwODQ2M10gMmE0MDkgaXMgNzk2
OWYwMDAhDQpbICA5MjguMjEwNDI3XSAyYTQwYSBpcyA3OTZhMDAwMCENClsgIDkyOC4yMTIz
MzldIDJhNDBiIGlzIDc5NmExMDAwIQ0KWyAgOTI4LjIxNDI4MF0gMmE0MGMgaXMgNzk2YTIw
MDAhDQpbICA5MjguMjE2MTY0XSAyYTQwZCBpcyA3OTZhMzAwMCENClsgIDkyOC4yMTgwNjVd
IDJhNDBlIGlzIDc5NmE0MDAwIQ0KWyAgOTI4LjIxOTkxOV0gMmE0MGYgaXMgNzk2YTUwMDAh
DQpbICA5MjguMjIyMzU0XSAyYTQxOCBpcyA3OTY5ODAwMCENClsgIDkyOC4yMjQyNDVdIDJh
NDE5IGlzIDc5Njk5MDAwIQ0KWyAgOTI4LjIyNjA5Ml0gMmE0MWEgaXMgNzk2OWEwMDAhDQpb
ICA5MjguMjI4MTcyXSAyYTQxNyBpcyA3OTY3NDAwMCENClsgIDkyOC4yMzAwMjZdIDJhNDE2
IGlzIDc5Njc1MDAwIQ0KWyAgOTI4LjIzMTgyMl0gMmE0MTUgaXMgNzk2NzYwMDAhDQpbICA5
MjguMjMzNjQ3XSAyYTQxNCBpcyA3OTY3NzAwMCENClsgIDkyOC4yMzU0MjBdIDJhNDEzIGlz
IDc5Njc4MDAwIQ0KWyAgOTI4LjIzNzE5MF0gMmE0MTIgaXMgNzk2NzkwMDAhDQpbICA5Mjgu
MjM4OTQ1XSAyYTQxMSBpcyA3OTY3YTAwMCENClsgIDkyOC4yNDA2OTBdIDJhNDEwIGlzIDc5
NjdiMDAwIQ0KWyAgOTI4LjI0MjQxOF0gMmE0MjQgaXMgNzk2N2MwMDAhDQpbICA5MjguMjQ0
MTI5XSAyYTQyMyBpcyA3OTY3ZDAwMCENClsgIDkyOC4yNDU4MjhdIDJhNDIyIGlzIDc5Njdl
MDAwIQ0KWyAgOTI4LjI0NzU2N10gMmE0MjEgaXMgNzk2N2YwMDAhDQpbICA5MjguMjQ5Mjc3
XSAyYTQyMCBpcyA3OTY4MDAwMCENClsgIDkyOC4yNTEwMDRdIDJhNDFmIGlzIDc5NjgxMDAw
IQ0KWyAgOTI4LjI1MjY5Nl0gMmE0MWUgaXMgNzk2ODIwMDAhDQpbICA5MjguMjU0NDA5XSAy
YTQxZCBpcyA3OTY4MzAwMCENClsgIDkyOC4yNTYwODddIDJhNDFjIGlzIDc5Njg0MDAwIQ0K
WyAgOTI4LjI1Nzc1N10gMmE0MWIgaXMgNzk2ODUwMDAhDQpbICA5MjguMjYwMjIyXSAyYTQw
NSBpcyA3OTY1ZjAwMCENClsgIDkyOC4yNjE5NDddIDJhNDI1IGlzIDc5NjYwMDAwIQ0KWyAg
OTI4LjI2MzY3M10gMmE0MjYgaXMgNzk2NjEwMDAhDQpbICA5MjguMjY1MzQxXSAyYTQyNyBp
cyA3OTY2MjAwMCENClsgIDkyOC4yNjcwNjNdIDJhNDI4IGlzIDc5NjYzMDAwIQ0KWyAgOTI4
LjI2ODczOF0gMmE0MjkgaXMgNzk2NjQwMDAhDQpbICA5MjguMjcwNDM0XSAyYTQyYSBpcyA3
OTY2NTAwMCENClsgIDkyOC4yNzIxMzNdIDJhNDJiIGlzIDc5NjY2MDAwIQ0KWyAgOTI4LjI3
MzgxOF0gMmE0MmMgaXMgNzk2NjcwMDAhDQpbICA5MjguMjc1NTE2XSAyYTQyZCBpcyA3OTY2
ODAwMCENClsgIDkyOC4yNzczMDBdIDJhNDJlIGlzIDc5NjY5MDAwIQ0KWyAgOTI4LjI3ODk0
Ml0gMmE0MmYgaXMgNzk2NmEwMDAhDQpbICA5MjguMjgwNjIxXSAyYTQzMCBpcyA3OTY2YjAw
MCENClsgIDkyOC4yODIyNzJdIDJhNDMxIGlzIDc5NjZjMDAwIQ0KWyAgOTI4LjI4Mzk1OF0g
MmE0MzIgaXMgNzk2NmQwMDAhDQpbICA5MjguMjg1NjAyXSAyYTQzMyBpcyA3OTY2ZTAwMCEN
ClsgIDkyOC4yODcyNzBdIDJhNDM0IGlzIDc5NjZmMDAwIQ0KWyAgOTI4LjI4ODk0NF0gMmE0
MzUgaXMgNzk2NzAwMDAhDQpbICA5MjguMjkwNjIyXSAyYTQzNiBpcyA3OTY3MTAwMCENClsg
IDkyOC4yOTIzMDhdIDJhNDM3IGlzIDc5NjcyMDAwIQ0KWyAgOTI4LjI5Mzk5OF0gMmE0Mzgg
aXMgNzk2NzMwMDAhDQpbICA5MjguMjk5MjcwXSAyYTQzOSBpcyA3OTY1NDAwMCENClsgIDky
OC4zMDEwNDhdIDJhNDNhIGlzIDc5NjU1MDAwIQ0KWyAgOTI4LjMwMjcyNF0gMmE0M2IgaXMg
Nzk2NTYwMDAhDQpbICA5MjguMzA0NDQxXSAyYTQzYyBpcyA3OTY1NzAwMCENClsgIDkyOC4z
MDYxMThdIDJhNDNkIGlzIDc5NjU4MDAwIQ0KWyAgOTI4LjMwNzgxN10gMmE0M2UgaXMgNzk2
NTkwMDAhDQpbICA5MjguMzA5NDk0XSAyYTQzZiBpcyA3OTY1YTAwMCENClsgIDkyOC4zMTEx
NzNdIDJhNDQwIGlzIDc5NjViMDAwIQ0KWyAgOTI4LjMxMjg1OV0gMmE0NDEgaXMgNzk2NWMw
MDAhDQpbICA5MjguMzE0NTQ4XSAyYTQ0MiBpcyA3OTY1ZDAwMCENClsgIDkyOC4zMTYyMjVd
IDJhNDQzIGlzIDc5NjVlMDAwIQ0KWyAgOTI4LjMxODEzMF0gMmE0NDQgaXMgNzk2NDkwMDAh
DQpbICA5MjguMzE5Nzk2XSAyYTQ0NSBpcyA3OTY0YTAwMCENClsgIDkyOC4zMjE0OThdIDJh
NDQ2IGlzIDc5NjRiMDAwIQ0KWyAgOTI4LjMyMzE1OF0gMmE0NDcgaXMgNzk2NGMwMDAhDQpb
ICA5MjguMzI0ODMwXSAyYTQ0OCBpcyA3OTY0ZDAwMCENClsgIDkyOC4zMjY0OTldIDJhNDQ5
IGlzIDc5NjRlMDAwIQ0KWyAgOTI4LjMyODE3MF0gMmE0NGEgaXMgNzk2NGYwMDAhDQpbICA5
MjguMzI5ODQ2XSAyYTQ0YiBpcyA3OTY1MDAwMCENClsgIDkyOC4zMzE1MjhdIDJhNDRjIGlz
IDc5NjUxMDAwIQ0KWyAgOTI4LjMzMzIwNl0gMmE0NGQgaXMgNzk2NTIwMDAhDQpbICA5Mjgu
MzM0OTE0XSAyYTQ0ZSBpcyA3OTY1MzAwMCENClsgIDkyOC4zMzY1OTBdIDJhNDRmIGlzIDc5
NjQ2MDAwIQ0KWyAgOTI4LjMzODMzMV0gMmE0NTAgaXMgNzk2NDcwMDAhDQpbICA5MjguMzQw
MDI1XSAyYTQ1MSBpcyA3OTY0ODAwMCENClsgIDkyOC4zNTMwNDFdIDJhNDUyIGlzIDc5NjI2
MDAwIQ0KWyAgOTI4LjM1NDc5M10gMmE0NTMgaXMgNzk2MjcwMDAhDQpbICA5MjguMzU2NDg0
XSAyYTQ1NCBpcyA3OTYyODAwMCENClsgIDkyOC4zNTgxOThdIDJhNDU1IGlzIDc5NjI5MDAw
IQ0KWyAgOTI4LjM1OTg4Nl0gMmE0NTYgaXMgNzk2MmEwMDAhDQpbICA5MjguMzYxNTgyXSAy
YTQ1NyBpcyA3OTYyYjAwMCENClsgIDkyOC4zNjMyNzldIDJhNDU4IGlzIDc5NjQ1MDAwIQ0K
WyAgOTI4LjM3MTMwOF0gMmE0NTkgaXMgNzk2MjUwMDAhDQpbICA5MjguMzg0NDA2XSAyYWY5
ZCBpcyA3OTVmMTAwMCENClsgIDkyOC4zODYxMjNdIDJhNDVhIGlzIDc5NWYwMDAwIQ0KWyAg
OTI4LjM4Nzg3NV0gMmE0NWIgaXMgNzk1ZWYwMDAhDQpbICA5MjguMzg5NTk0XSAyYTQ1YyBp
cyA3OTVlZTAwMCENClsgIDkyOC4zOTE4NTldIDJhNDVlIGlzIDc5NWY1MDAwIQ0KWyAgOTI4
LjM5MzYyNl0gMmE0NWYgaXMgNzk1ZjQwMDAhDQpbICA5MjguMzk1MzUwXSAyYTQ2MCBpcyA3
OTVmMzAwMCENClsgIDkyOC4zOTcxMzZdIDJhNDYxIGlzIDc5NWYyMDAwIQ0KWyAgOTI4LjQw
NTUxMF0gMmE0NjIgaXMgNzk1Y2YwMDAhDQpbICA5MjguNDE2ODMzXSAyYTQ1ZCBpcyA3OTVk
MDAwMCENClsgIDkyOC40MzI5NjZdIDJhNDYzIGlzIDc5NWQ0MDAwIQ0KWyAgOTI4LjQzNDgy
N10gMmE0NjQgaXMgNzk1ZDMwMDAhDQpbICA5MjguNDM2NTk3XSAyYTQ2NSBpcyA3OTVkMjAw
MCENClsgIDkyOC40Mzg0MTFdIDJhNDY2IGlzIDc5NWQxMDAwIQ0KWyAgOTI4LjQ0MDc4M10g
MmE0NjcgaXMgNzk1ZDkwMDAhDQpbICA5MjguNDQyNTc3XSAzNmU4NyBpcyA3OTVkODAwMCEN
ClsgIDkyOC40NDQ0MDNdIDM5MzE0IGlzIDc5NWQ3MDAwIQ0KWyAgOTI4LjQ0NjIzOV0gMzkz
MTUgaXMgNzk1ZDYwMDAhDQpbICA5MjguNDQ4MDY2XSAyYWZjYyBpcyA3OTVkNTAwMCENClsg
IDkyOC40NjI2NTFdIDJhZmNkIGlzIDc5NWRiMDAwIQ0KWyAgOTI4LjQ2NDUwNl0gMmFmY2Ug
aXMgNzk1ZGEwMDAhDQpbICA5MjguNDc4MTA3XSAyYWZjZiBpcyA3OTVkZDAwMCENClsgIDky
OC40Nzk5NDJdIDJhZmQwIGlzIDc5NWRjMDAwIQ0KWyAgOTI4LjQ4OTAyOV0gMmE0NjggaXMg
Nzk1ZGUwMDAhDQpbICA5MjguNDk5MDU4XSAyYWZkMSBpcyA3OTVkZjAwMCENClsgIDkzMy40
MjIwOTJdIDJhZmQyIGlzIDdhMjQxMDAwIQ0KWyAgOTMzLjQyMzk5NV0gMzgyYjkgaXMgMmRj
ZjkwMDAhDQpbICA5MzMuNDI1OTA2XSAzNzczZSBpcyA3OTZmNzAwMCENClsgIDkzMy40Mjc4
NTZdIDJhNDgxIGlzIDIxZGVkMDAwIQ0KWyAgOTMzLjQyOTgzOF0gMmE0NjkgaXMgMjRlMjIw
MDAhDQpbICA5MzMuNDMxODMzXSAyYTQ2YSBpcyAyMWI3NzAwMCENClsgIDkzMy40NDMwNDJd
IDJhNDZiIGlzIDIxYjc2MDAwIQ0KWyAgOTQxLjgwODI4Nl0gMmFmZDMgaXMgNzk1ZGQwMDAh
DQpbICA5NDEuODEwMzQzXSAyYTQ2ZiBpcyA3OTVkYzAwMCENClsgIDk0NC4zMjg2MTldIDJh
NDZlIGlzIDc4YmViMDAwIQ0KWyAgOTQ0LjMzMDcwOV0gMmE0NmMgaXMgNzkxZmIwMDAhDQpb
ICA5NDcuNDIyMjcyXSAyYTQ3MCBpcyAyNGUyMjAwMCENClsgIDk0Ny40MjQ0NTVdIDJhNDcx
IGlzIDc5NmY3MDAwIQ0KWyAgOTQ3LjQyNjYwMl0gMmE0NzIgaXMgMjFkZWQwMDAhDQpbICA5
NDcuNDI4Nzk1XSAyYTQ3MyBpcyA3YTI0MTAwMCENClsgIDk0Ny40MzA5NjRdIDJhNDc0IGlz
IDJkY2VkMDAwIQ0KWyAgOTQ3LjQzMzE0OF0gMmE0NzUgaXMgN2EyMGYwMDAhDQpbICA5NDcu
NDM1MzM1XSAyYTQ3NiBpcyAyNmQyYzAwMCENClsgIDk0Ny40Mzc1NzNdIDJhNDc3IGlzIDc4
Y2YyMDAwIQ0KWyAgOTQ3LjQ0NzUzN10gMmE0NzggaXMgMjE5YzMwMDAhDQpbICA5NTQuMzI5
NTUwXSAzNzZjNiBpcyAyNmQyYzAwMCENClsgIDk1NC4zMzE4ODBdIDJhNDc5IGlzIDdhMjQx
MDAwIQ0KWyAgOTU0LjMzNDI0M10gMzhjZjUgaXMgN2EyMGYwMDAhDQpbICA5NTQuMzM2NTkx
XSAyYTQ3YSBpcyAyMWRlZDAwMCENClsgIDk1NC4zMzg5ODZdIDJhNDdiIGlzIDI0ZTBkMDAw
IQ0KWyAgOTU0LjM0MTQyN10gMmE0N2MgaXMgMjRlMjIwMDAhDQpbICA5NTQuMzQzODczXSAy
YTQ3ZCBpcyA3OTZmNzAwMCENClsgIDk1NC4zNDYyODRdIDJhNDdlIGlzIDJkY2Y5MDAwIQ0K
WyAgOTU0LjM0ODczMV0gMmE0N2YgaXMgMmRjZWQwMDAhDQpbICA5NTkuMzI4ODc1XSAzN2Yy
NiBpcyA3OTZiYzAwMCENClsgIDk1OS4zMzEzNjNdIDM2NDYwIGlzIDIxNzdjMDAwIQ0KWyAg
OTU5LjMzMzk0NV0gMzdiY2EgaXMgNzhmMWUwMDAhDQpbICA5NTkuMzM2NTA5XSAzNzY3YyBp
cyAyMTllYTAwMCENClsgIDk1OS4zMzkwMjVdIDM3ZTFjIGlzIDIxNjA0MDAwIQ0K
------------0CA04210C17B3F3A8
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

------------0CA04210C17B3F3A8--



From xen-devel-bounces@lists.xen.org Tue Sep 04 18:22:40 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Sep 2012 18:22: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 1T8xlV-0007TY-OG; Tue, 04 Sep 2012 18:22:21 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <misiu.godfrey@gmail.com>) id 1T8xlU-0007TT-8x
	for xen-devel@lists.xen.org; Tue, 04 Sep 2012 18:22:20 +0000
Received: from [85.158.143.35:12827] by server-3.bemta-4.messagelabs.com id
	DA/FF-08232-BD646405; Tue, 04 Sep 2012 18:22:19 +0000
X-Env-Sender: misiu.godfrey@gmail.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1346782927!5608153!1
X-Originating-IP: [74.125.82.51]
X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_10_20,HTML_MESSAGE,
	RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15062 invoked from network); 4 Sep 2012 18:22:07 -0000
Received: from mail-wg0-f51.google.com (HELO mail-wg0-f51.google.com)
	(74.125.82.51)
	by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Sep 2012 18:22:07 -0000
Received: by wgbed3 with SMTP id ed3so4074440wgb.32
	for <xen-devel@lists.xen.org>; Tue, 04 Sep 2012 11:22:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:date:x-google-sender-auth:message-id:subject
	:from:to:content-type;
	bh=s4yHHQpe5aG9LOpaYRKAmvabczvdaCz+ICqDuWxtcTE=;
	b=N4nLKeJJ0sxYx40Zp9gjKIqI8Yrq+tSHL2nJZhMc1OTu1LL7byx1Wjt3Id3wZ0OGLr
	fu7Q/yINH5goROdwHKMOZXHU6uBqYhbDR1zymi7FHwc6Aft3bXMfZxtvdQMBRzEQ2oaD
	s62YTdT5MrukRCsPwfLMYfhFvc/KkAna8JDJ0GZIX7IsPQkk5ggqgl6lkEqAuzJenhIn
	VUZVt8BIqtzQwEVsf++oBuL7d8FBuaYEvXk7P8L88do016M+xchD7lmVZD0cXmfUqjqG
	IXrgo/Mdg/Nn/F4UJgzPWNpL8IbLdHEfegXVsFFZEAj0N1OYDF8Ll+Gg29DkPeVyT0Q7
	fMlQ==
MIME-Version: 1.0
Received: by 10.180.81.165 with SMTP id b5mr32354861wiy.17.1346782927224; Tue,
	04 Sep 2012 11:22:07 -0700 (PDT)
Received: by 10.194.13.7 with HTTP; Tue, 4 Sep 2012 11:22:07 -0700 (PDT)
Date: Tue, 4 Sep 2012 14:22:07 -0400
X-Google-Sender-Auth: ey-aa0YgwH7-qd1bO3XihsffoyQ
Message-ID: <CAMVU=QgzjT1daB5_zfoP2amtbvWX3X5XZKE6Bj1eX-tTDY=xSQ@mail.gmail.com>
From: misiu godfrey <godfrey@cs.queensu.ca>
To: xen-devel <xen-devel@lists.xen.org>
Subject: [Xen-devel] additional domain.c memory allocation causes "xm
	create" to fail
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============3412232264033068740=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============3412232264033068740==
Content-Type: multipart/alternative; boundary=f46d044304eef7810404c8e45502

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

Hello Xen Developers,

I am currently attempting an experiment to modify Xen in such a way that it
will flush the L2 cache every time it performs a context switch.  Thus far
I have implemented my code inside the __context_switch() function, of
domain.c (xen/arch/x86/domain.c), and while my modifications work fine for
memory allocations of up to 512KB, it fails whenever I increase this to 1MB.

Specifically, when the memory buffer is increased to 1MB, the machine will
force a hard reset whenever xm tries to create a new domain.  When I try to
create a new domain (a sparse squeeze install, Dom0 is running Ubuntu
12.04) it gets as far as completing the scripts/init-bottom call before it
crashes, which makes me think it is going down during the following init
call.

I have narrowed down the section of code that is failing.  The curious
thing is that the failure threshold seems to be dependent on the number of
iterations in the loop, rather than the specific amount of memory (i.e. 1MB
of memory will work when 'i' is incremented by 128 rather than 64, whereas
512KB of memory will work when 'i' is 64):

  cache_mem_size = 1048576;  // Size of L2 cache
  cache_mem = xmalloc_array(char,cache_mem_size);

  for (i=0;i<cache_mem_size;i+=64)
    cache_mem[i] += 1;

  xfree(cache_mem);

If anyone has a suggestion as to what may be causing this failure, or
insight into the runtime limitations of this section of the architecture,
kernel, or scheduler, I would appreciate the information.

Thanks,

-Misiu

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

Hello Xen Developers,<div><br></div><div>I am currently attempting an exper=
iment to modify Xen in such a way that it will flush the L2 cache every tim=
e it performs a context switch. =A0Thus far I have implemented my code insi=
de the __context_switch() function, of domain.c (xen/arch/x86/domain.c), an=
d while my modifications work fine for memory allocations of up to 512KB, i=
t fails whenever I increase this to 1MB.</div>

<div><br></div><div>Specifically, when the memory buffer is increased to 1M=
B, the machine will force a hard reset whenever xm tries to create a new do=
main. =A0When I try to create a new domain (a sparse squeeze install, Dom0 =
is running Ubuntu 12.04) it gets as far as completing the scripts/init-bott=
om call before it crashes, which makes me think it is going down during the=
 following init call.</div>

<div><br></div><div>I have narrowed down the section of code that is failin=
g. =A0The curious thing is that the failure threshold seems to be dependent=
 on the number of iterations in the loop, rather than the specific amount o=
f memory (i.e. 1MB of memory will work when &#39;i&#39; is incremented by 1=
28 rather than 64, whereas 512KB of memory will work when &#39;i&#39; is 64=
):</div>

<div><br></div><div>=A0 cache_mem_size =3D 1048576; =A0// Size of L2 cache<=
/div><div>=A0 cache_mem =3D xmalloc_array(char,cache_mem_size);</div><div><=
br></div><div>=A0 for (i=3D0;i&lt;cache_mem_size;i+=3D64)</div><div>=A0 =A0=
 cache_mem[i] +=3D 1;</div>

<div><br></div><div>=A0 xfree(cache_mem);</div><div><br></div><div>If anyon=
e has a suggestion as to what may be causing this failure, or insight into =
the runtime limitations of this section of the architecture, kernel, or sch=
eduler, I would appreciate the information.</div>
<div><br></div><div>Thanks,</div><div><br></div><div>-Misiu=A0</div>

--f46d044304eef7810404c8e45502--


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

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

--===============3412232264033068740==--


From xen-devel-bounces@lists.xen.org Tue Sep 04 18:22:40 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Sep 2012 18:22: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 1T8xlV-0007TY-OG; Tue, 04 Sep 2012 18:22:21 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <misiu.godfrey@gmail.com>) id 1T8xlU-0007TT-8x
	for xen-devel@lists.xen.org; Tue, 04 Sep 2012 18:22:20 +0000
Received: from [85.158.143.35:12827] by server-3.bemta-4.messagelabs.com id
	DA/FF-08232-BD646405; Tue, 04 Sep 2012 18:22:19 +0000
X-Env-Sender: misiu.godfrey@gmail.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1346782927!5608153!1
X-Originating-IP: [74.125.82.51]
X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_10_20,HTML_MESSAGE,
	RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15062 invoked from network); 4 Sep 2012 18:22:07 -0000
Received: from mail-wg0-f51.google.com (HELO mail-wg0-f51.google.com)
	(74.125.82.51)
	by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Sep 2012 18:22:07 -0000
Received: by wgbed3 with SMTP id ed3so4074440wgb.32
	for <xen-devel@lists.xen.org>; Tue, 04 Sep 2012 11:22:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:date:x-google-sender-auth:message-id:subject
	:from:to:content-type;
	bh=s4yHHQpe5aG9LOpaYRKAmvabczvdaCz+ICqDuWxtcTE=;
	b=N4nLKeJJ0sxYx40Zp9gjKIqI8Yrq+tSHL2nJZhMc1OTu1LL7byx1Wjt3Id3wZ0OGLr
	fu7Q/yINH5goROdwHKMOZXHU6uBqYhbDR1zymi7FHwc6Aft3bXMfZxtvdQMBRzEQ2oaD
	s62YTdT5MrukRCsPwfLMYfhFvc/KkAna8JDJ0GZIX7IsPQkk5ggqgl6lkEqAuzJenhIn
	VUZVt8BIqtzQwEVsf++oBuL7d8FBuaYEvXk7P8L88do016M+xchD7lmVZD0cXmfUqjqG
	IXrgo/Mdg/Nn/F4UJgzPWNpL8IbLdHEfegXVsFFZEAj0N1OYDF8Ll+Gg29DkPeVyT0Q7
	fMlQ==
MIME-Version: 1.0
Received: by 10.180.81.165 with SMTP id b5mr32354861wiy.17.1346782927224; Tue,
	04 Sep 2012 11:22:07 -0700 (PDT)
Received: by 10.194.13.7 with HTTP; Tue, 4 Sep 2012 11:22:07 -0700 (PDT)
Date: Tue, 4 Sep 2012 14:22:07 -0400
X-Google-Sender-Auth: ey-aa0YgwH7-qd1bO3XihsffoyQ
Message-ID: <CAMVU=QgzjT1daB5_zfoP2amtbvWX3X5XZKE6Bj1eX-tTDY=xSQ@mail.gmail.com>
From: misiu godfrey <godfrey@cs.queensu.ca>
To: xen-devel <xen-devel@lists.xen.org>
Subject: [Xen-devel] additional domain.c memory allocation causes "xm
	create" to fail
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============3412232264033068740=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============3412232264033068740==
Content-Type: multipart/alternative; boundary=f46d044304eef7810404c8e45502

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

Hello Xen Developers,

I am currently attempting an experiment to modify Xen in such a way that it
will flush the L2 cache every time it performs a context switch.  Thus far
I have implemented my code inside the __context_switch() function, of
domain.c (xen/arch/x86/domain.c), and while my modifications work fine for
memory allocations of up to 512KB, it fails whenever I increase this to 1MB.

Specifically, when the memory buffer is increased to 1MB, the machine will
force a hard reset whenever xm tries to create a new domain.  When I try to
create a new domain (a sparse squeeze install, Dom0 is running Ubuntu
12.04) it gets as far as completing the scripts/init-bottom call before it
crashes, which makes me think it is going down during the following init
call.

I have narrowed down the section of code that is failing.  The curious
thing is that the failure threshold seems to be dependent on the number of
iterations in the loop, rather than the specific amount of memory (i.e. 1MB
of memory will work when 'i' is incremented by 128 rather than 64, whereas
512KB of memory will work when 'i' is 64):

  cache_mem_size = 1048576;  // Size of L2 cache
  cache_mem = xmalloc_array(char,cache_mem_size);

  for (i=0;i<cache_mem_size;i+=64)
    cache_mem[i] += 1;

  xfree(cache_mem);

If anyone has a suggestion as to what may be causing this failure, or
insight into the runtime limitations of this section of the architecture,
kernel, or scheduler, I would appreciate the information.

Thanks,

-Misiu

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

Hello Xen Developers,<div><br></div><div>I am currently attempting an exper=
iment to modify Xen in such a way that it will flush the L2 cache every tim=
e it performs a context switch. =A0Thus far I have implemented my code insi=
de the __context_switch() function, of domain.c (xen/arch/x86/domain.c), an=
d while my modifications work fine for memory allocations of up to 512KB, i=
t fails whenever I increase this to 1MB.</div>

<div><br></div><div>Specifically, when the memory buffer is increased to 1M=
B, the machine will force a hard reset whenever xm tries to create a new do=
main. =A0When I try to create a new domain (a sparse squeeze install, Dom0 =
is running Ubuntu 12.04) it gets as far as completing the scripts/init-bott=
om call before it crashes, which makes me think it is going down during the=
 following init call.</div>

<div><br></div><div>I have narrowed down the section of code that is failin=
g. =A0The curious thing is that the failure threshold seems to be dependent=
 on the number of iterations in the loop, rather than the specific amount o=
f memory (i.e. 1MB of memory will work when &#39;i&#39; is incremented by 1=
28 rather than 64, whereas 512KB of memory will work when &#39;i&#39; is 64=
):</div>

<div><br></div><div>=A0 cache_mem_size =3D 1048576; =A0// Size of L2 cache<=
/div><div>=A0 cache_mem =3D xmalloc_array(char,cache_mem_size);</div><div><=
br></div><div>=A0 for (i=3D0;i&lt;cache_mem_size;i+=3D64)</div><div>=A0 =A0=
 cache_mem[i] +=3D 1;</div>

<div><br></div><div>=A0 xfree(cache_mem);</div><div><br></div><div>If anyon=
e has a suggestion as to what may be causing this failure, or insight into =
the runtime limitations of this section of the architecture, kernel, or sch=
eduler, I would appreciate the information.</div>
<div><br></div><div>Thanks,</div><div><br></div><div>-Misiu=A0</div>

--f46d044304eef7810404c8e45502--


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

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

--===============3412232264033068740==--


From xen-devel-bounces@lists.xen.org Tue Sep 04 18:33:35 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Sep 2012 18: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 1T8xw3-0007eS-VU; Tue, 04 Sep 2012 18:33:15 +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 1T8xw2-0007eN-GY
	for xen-devel@lists.xen.org; Tue, 04 Sep 2012 18:33:14 +0000
Received: from [85.158.143.35:62945] by server-1.bemta-4.messagelabs.com id
	09/7F-12504-96946405; Tue, 04 Sep 2012 18:33:13 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1346783591!15281889!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNjg0OTY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27634 invoked from network); 4 Sep 2012 18:33:13 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-13.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Sep 2012 18:33:13 -0000
X-IronPort-AV: E=Sophos;i="4.80,368,1344211200"; d="scan'208";a="36737263"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Sep 2012 18:32:52 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Tue, 4 Sep 2012 14:32:52 -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 1T8xvg-0002Pb-2c;
	Tue, 04 Sep 2012 19:32:52 +0100
Message-ID: <50464954.5030207@citrix.com>
Date: Tue, 4 Sep 2012 19:32:52 +0100
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:14.0) Gecko/20120714 Thunderbird/14.0
MIME-Version: 1.0
To: misiu godfrey <godfrey@cs.queensu.ca>
References: <CAMVU=QgzjT1daB5_zfoP2amtbvWX3X5XZKE6Bj1eX-tTDY=xSQ@mail.gmail.com>
In-Reply-To: <CAMVU=QgzjT1daB5_zfoP2amtbvWX3X5XZKE6Bj1eX-tTDY=xSQ@mail.gmail.com>
X-Enigmail-Version: 1.4.4
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] additional domain.c memory allocation causes "xm
 create" to fail
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/09/12 19:22, misiu godfrey wrote:
> Hello Xen Developers,
>
> I am currently attempting an experiment to modify Xen in such a way
> that it will flush the L2 cache every time it performs a context switch.

For what purpose?  There was once a bug which caused this to happen and
it caused Xen to slow to a glacial pace.  We got bored of debugging HVM
domains after several hours and the BIOS has still not loaded the
bootloader.

>  Thus far I have implemented my code inside the __context_switch()
> function, of domain.c (xen/arch/x86/domain.c), and while my
> modifications work fine for memory allocations of up to 512KB, it
> fails whenever I increase this to 1MB.
>
> Specifically, when the memory buffer is increased to 1MB, the machine
> will force a hard reset whenever xm tries to create a new domain.
>  When I try to create a new domain (a sparse squeeze install, Dom0 is
> running Ubuntu 12.04) it gets as far as completing the
> scripts/init-bottom call before it crashes, which makes me think it is
> going down during the following init call.
>
> I have narrowed down the section of code that is failing.  The curious
> thing is that the failure threshold seems to be dependent on the
> number of iterations in the loop, rather than the specific amount of
> memory (i.e. 1MB of memory will work when 'i' is incremented by 128
> rather than 64, whereas 512KB of memory will work when 'i' is 64):
>
>   cache_mem_size = 1048576;  // Size of L2 cache
>   cache_mem = xmalloc_array(char,cache_mem_size);

You don't check the return value, so what happens when the allocation
fails?  I would say that calling *alloc() is not a sensible thing to be
doing in __context_switch() anyway, as you are sitting doing a long
operation while in a critical section of Xen code.

>
>   for (i=0;i<cache_mem_size;i+=64)
>     cache_mem[i] += 1;
>
>   xfree(cache_mem);

Furthermore, this algorithm has no guarantee to clear the L2 cache.  In
fact is almost certainly will not.

>
> If anyone has a suggestion as to what may be causing this failure, or
> insight into the runtime limitations of this section of the
> architecture, kernel, or scheduler, I would appreciate the information.
>
> Thanks,
>
> -Misiu 

-- 
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 Sep 04 18:33:35 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Sep 2012 18: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 1T8xw3-0007eS-VU; Tue, 04 Sep 2012 18:33:15 +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 1T8xw2-0007eN-GY
	for xen-devel@lists.xen.org; Tue, 04 Sep 2012 18:33:14 +0000
Received: from [85.158.143.35:62945] by server-1.bemta-4.messagelabs.com id
	09/7F-12504-96946405; Tue, 04 Sep 2012 18:33:13 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1346783591!15281889!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNjg0OTY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27634 invoked from network); 4 Sep 2012 18:33:13 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-13.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Sep 2012 18:33:13 -0000
X-IronPort-AV: E=Sophos;i="4.80,368,1344211200"; d="scan'208";a="36737263"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Sep 2012 18:32:52 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Tue, 4 Sep 2012 14:32:52 -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 1T8xvg-0002Pb-2c;
	Tue, 04 Sep 2012 19:32:52 +0100
Message-ID: <50464954.5030207@citrix.com>
Date: Tue, 4 Sep 2012 19:32:52 +0100
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:14.0) Gecko/20120714 Thunderbird/14.0
MIME-Version: 1.0
To: misiu godfrey <godfrey@cs.queensu.ca>
References: <CAMVU=QgzjT1daB5_zfoP2amtbvWX3X5XZKE6Bj1eX-tTDY=xSQ@mail.gmail.com>
In-Reply-To: <CAMVU=QgzjT1daB5_zfoP2amtbvWX3X5XZKE6Bj1eX-tTDY=xSQ@mail.gmail.com>
X-Enigmail-Version: 1.4.4
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] additional domain.c memory allocation causes "xm
 create" to fail
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/09/12 19:22, misiu godfrey wrote:
> Hello Xen Developers,
>
> I am currently attempting an experiment to modify Xen in such a way
> that it will flush the L2 cache every time it performs a context switch.

For what purpose?  There was once a bug which caused this to happen and
it caused Xen to slow to a glacial pace.  We got bored of debugging HVM
domains after several hours and the BIOS has still not loaded the
bootloader.

>  Thus far I have implemented my code inside the __context_switch()
> function, of domain.c (xen/arch/x86/domain.c), and while my
> modifications work fine for memory allocations of up to 512KB, it
> fails whenever I increase this to 1MB.
>
> Specifically, when the memory buffer is increased to 1MB, the machine
> will force a hard reset whenever xm tries to create a new domain.
>  When I try to create a new domain (a sparse squeeze install, Dom0 is
> running Ubuntu 12.04) it gets as far as completing the
> scripts/init-bottom call before it crashes, which makes me think it is
> going down during the following init call.
>
> I have narrowed down the section of code that is failing.  The curious
> thing is that the failure threshold seems to be dependent on the
> number of iterations in the loop, rather than the specific amount of
> memory (i.e. 1MB of memory will work when 'i' is incremented by 128
> rather than 64, whereas 512KB of memory will work when 'i' is 64):
>
>   cache_mem_size = 1048576;  // Size of L2 cache
>   cache_mem = xmalloc_array(char,cache_mem_size);

You don't check the return value, so what happens when the allocation
fails?  I would say that calling *alloc() is not a sensible thing to be
doing in __context_switch() anyway, as you are sitting doing a long
operation while in a critical section of Xen code.

>
>   for (i=0;i<cache_mem_size;i+=64)
>     cache_mem[i] += 1;
>
>   xfree(cache_mem);

Furthermore, this algorithm has no guarantee to clear the L2 cache.  In
fact is almost certainly will not.

>
> If anyone has a suggestion as to what may be causing this failure, or
> insight into the runtime limitations of this section of the
> architecture, kernel, or scheduler, I would appreciate the information.
>
> Thanks,
>
> -Misiu 

-- 
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 Sep 04 18:33:44 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Sep 2012 18: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 1T8xwF-0007f6-CF; Tue, 04 Sep 2012 18:33:27 +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 1T8xwD-0007eh-KJ
	for xen-devel@lists.xen.org; Tue, 04 Sep 2012 18:33:25 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1346783597!2649111!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDczNjI0OQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1851 invoked from network); 4 Sep 2012 18:33:18 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-14.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 4 Sep 2012 18:33: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 q84IXBe6029356
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 4 Sep 2012 18:33:12 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
	q84IXA0d024618
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 4 Sep 2012 18:33:10 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
	q84IX9jZ008000; Tue, 4 Sep 2012 13:33:09 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 04 Sep 2012 11:33:09 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 1C385402BA; Tue,  4 Sep 2012 14:22:41 -0400 (EDT)
Date: Tue, 4 Sep 2012 14:22:41 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Ben Guthro <ben@guthro.net>
Message-ID: <20120904182241.GC10379@phenom.dumpdata.com>
References: <1136369816.20120904183757@eikelenboom.it>
	<20120904163347.GH23361@phenom.dumpdata.com>
	<143844933.20120904191941@eikelenboom.it>
	<CAOvdn6U_yHgtZwv9MWazdLbd3NLq3pwGXnZY5sL2UVBhV_FUoQ@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAOvdn6U_yHgtZwv9MWazdLbd3NLq3pwGXnZY5sL2UVBhV_FUoQ@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: Sander Eikelenboom <linux@eikelenboom.it>, robert.phillips@citrix.com,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] dom0 linux 3.6.0-rc4,
 crash due to ballooning althoug dom0_mem=X, max:X set
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Sep 04, 2012 at 02:07:11PM -0400, Ben Guthro wrote:
> We ran into the same issue, in newer kernels - but had not yet
> submitted this fix.
> 
> One of the developers here came up with a fix (attached, and CC'ed
> here) that fixes an issue where the p2m code reuses a structure member
> where it shouldn't.
> The patch adds a new "old_mfn"  member to the gnttab_map_grant_ref
> structure, instead of re-using  dev_bus_addr.

Wow. So that implies the m2p code had some new wonkiness in it.

Perhaps this b9e0d95c041ca2d7ad297ee37c2e9cfab67a188f
or
0930bba674e248b921ea659b036ff02564e5a5f4

both courtesy of Stefano (who is on vacation this week :-())
are at fault?

Would it be possible to revert one of them (or both) and see if the
issues disappear?

> 
> 
> If this also works for you, I can re-submit it with a Signed-off-by
> line, if you prefer, Konrad.
> 
> Ben
> 
> 
> On Tue, Sep 4, 2012 at 1:19 PM, Sander Eikelenboom <linux@eikelenboom.it> wrote:
> >
> > Tuesday, September 4, 2012, 6:33:47 PM, you wrote:
> >
> >> On Tue, Sep 04, 2012 at 06:37:57PM +0200, Sander Eikelenboom wrote:
> >>> Hi Konrad,
> >>>
> >>> This seems to happen only on a intel machine i'm trying to setup as a development machine (haven't seen it on my amd).
> >>> It boots fine, i have dom0_mem=1024M,max:1024M set, the machine has 2G of mem.
> >
> >> Is this only with Xen 4.2? As, does Xen 4.1 work?
> >>>
> >>> Dom0 and guest kernel are 3.6.0-rc4 with config:
> >
> >> If you back out:
> >
> >> f393387d160211f60398d58463a7e65
> >> Author: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> >> Date:   Fri Aug 17 16:43:28 2012 -0400
> >
> >>     xen/setup: Fix one-off error when adding for-balloon PFNs to the P2M.
> >
> >> Do you see this bug? (Either with Xen 4.1 or Xen 4.2)?
> >
> > With c96aae1f7f393387d160211f60398d58463a7e65 reverted i still see this bug (with Xen 4.2).
> >
> > Will use the debug patch you mailed and send back the results ...
> >
> >
> >>> [*] Xen memory balloon driver
> >>> [*]   Scrub pages before returning them to system
> >>>
> >>> From http://wiki.xen.org/wiki/Do%EF%BB%BFm0_Memory_%E2%80%94_Where_It_Has_Not_Gone , I thought this should be okay
> >>>
> >>> But when trying to start a PV guest with 512MB mem, the machine (dom0) crashes with the stacktrace below (complete serial-log.txt attached).
> >>>
> >>> From the:
> >>> "mapping kernel into physical memory
> >>> about to get started..."
> >>>
> >>> I would almost say it's trying to reload dom0 ?
> >>>
> >>>
> >>> [  897.161119] device vif1.0 entered promiscuous mode
> >>> mapping kernel into physical memory
> >>> about to get started...
> >>> [  897.696619] xen_bridge: port 1(vif1.0) entered forwarding state
> >>> [  897.716219] xen_bridge: port 1(vif1.0) entered forwarding state
> >>> [  898.129465] ------------[ cut here ]------------
> >>> [  898.132209] kernel BUG at drivers/xen/balloon.c:359!
> >>> [  898.132209] invalid opcode: 0000 [#1] PREEMPT SMP
> >
> >
> >
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xen.org
> > http://lists.xen.org/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 Sep 04 18:33:44 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Sep 2012 18: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 1T8xwF-0007f6-CF; Tue, 04 Sep 2012 18:33:27 +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 1T8xwD-0007eh-KJ
	for xen-devel@lists.xen.org; Tue, 04 Sep 2012 18:33:25 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1346783597!2649111!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDczNjI0OQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1851 invoked from network); 4 Sep 2012 18:33:18 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-14.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 4 Sep 2012 18:33: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 q84IXBe6029356
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 4 Sep 2012 18:33:12 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
	q84IXA0d024618
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 4 Sep 2012 18:33:10 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
	q84IX9jZ008000; Tue, 4 Sep 2012 13:33:09 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 04 Sep 2012 11:33:09 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 1C385402BA; Tue,  4 Sep 2012 14:22:41 -0400 (EDT)
Date: Tue, 4 Sep 2012 14:22:41 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Ben Guthro <ben@guthro.net>
Message-ID: <20120904182241.GC10379@phenom.dumpdata.com>
References: <1136369816.20120904183757@eikelenboom.it>
	<20120904163347.GH23361@phenom.dumpdata.com>
	<143844933.20120904191941@eikelenboom.it>
	<CAOvdn6U_yHgtZwv9MWazdLbd3NLq3pwGXnZY5sL2UVBhV_FUoQ@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAOvdn6U_yHgtZwv9MWazdLbd3NLq3pwGXnZY5sL2UVBhV_FUoQ@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: Sander Eikelenboom <linux@eikelenboom.it>, robert.phillips@citrix.com,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] dom0 linux 3.6.0-rc4,
 crash due to ballooning althoug dom0_mem=X, max:X set
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Sep 04, 2012 at 02:07:11PM -0400, Ben Guthro wrote:
> We ran into the same issue, in newer kernels - but had not yet
> submitted this fix.
> 
> One of the developers here came up with a fix (attached, and CC'ed
> here) that fixes an issue where the p2m code reuses a structure member
> where it shouldn't.
> The patch adds a new "old_mfn"  member to the gnttab_map_grant_ref
> structure, instead of re-using  dev_bus_addr.

Wow. So that implies the m2p code had some new wonkiness in it.

Perhaps this b9e0d95c041ca2d7ad297ee37c2e9cfab67a188f
or
0930bba674e248b921ea659b036ff02564e5a5f4

both courtesy of Stefano (who is on vacation this week :-())
are at fault?

Would it be possible to revert one of them (or both) and see if the
issues disappear?

> 
> 
> If this also works for you, I can re-submit it with a Signed-off-by
> line, if you prefer, Konrad.
> 
> Ben
> 
> 
> On Tue, Sep 4, 2012 at 1:19 PM, Sander Eikelenboom <linux@eikelenboom.it> wrote:
> >
> > Tuesday, September 4, 2012, 6:33:47 PM, you wrote:
> >
> >> On Tue, Sep 04, 2012 at 06:37:57PM +0200, Sander Eikelenboom wrote:
> >>> Hi Konrad,
> >>>
> >>> This seems to happen only on a intel machine i'm trying to setup as a development machine (haven't seen it on my amd).
> >>> It boots fine, i have dom0_mem=1024M,max:1024M set, the machine has 2G of mem.
> >
> >> Is this only with Xen 4.2? As, does Xen 4.1 work?
> >>>
> >>> Dom0 and guest kernel are 3.6.0-rc4 with config:
> >
> >> If you back out:
> >
> >> f393387d160211f60398d58463a7e65
> >> Author: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> >> Date:   Fri Aug 17 16:43:28 2012 -0400
> >
> >>     xen/setup: Fix one-off error when adding for-balloon PFNs to the P2M.
> >
> >> Do you see this bug? (Either with Xen 4.1 or Xen 4.2)?
> >
> > With c96aae1f7f393387d160211f60398d58463a7e65 reverted i still see this bug (with Xen 4.2).
> >
> > Will use the debug patch you mailed and send back the results ...
> >
> >
> >>> [*] Xen memory balloon driver
> >>> [*]   Scrub pages before returning them to system
> >>>
> >>> From http://wiki.xen.org/wiki/Do%EF%BB%BFm0_Memory_%E2%80%94_Where_It_Has_Not_Gone , I thought this should be okay
> >>>
> >>> But when trying to start a PV guest with 512MB mem, the machine (dom0) crashes with the stacktrace below (complete serial-log.txt attached).
> >>>
> >>> From the:
> >>> "mapping kernel into physical memory
> >>> about to get started..."
> >>>
> >>> I would almost say it's trying to reload dom0 ?
> >>>
> >>>
> >>> [  897.161119] device vif1.0 entered promiscuous mode
> >>> mapping kernel into physical memory
> >>> about to get started...
> >>> [  897.696619] xen_bridge: port 1(vif1.0) entered forwarding state
> >>> [  897.716219] xen_bridge: port 1(vif1.0) entered forwarding state
> >>> [  898.129465] ------------[ cut here ]------------
> >>> [  898.132209] kernel BUG at drivers/xen/balloon.c:359!
> >>> [  898.132209] invalid opcode: 0000 [#1] PREEMPT SMP
> >
> >
> >
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xen.org
> > http://lists.xen.org/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 Sep 04 18:57:50 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Sep 2012 18: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 1T8yJa-0007y8-GG; Tue, 04 Sep 2012 18:57:34 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <linux@eikelenboom.it>) id 1T8yJZ-0007y3-A6
	for xen-devel@lists.xen.org; Tue, 04 Sep 2012 18:57:33 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-15.tower-27.messagelabs.com!1346785037!2582633!1
X-Originating-IP: [188.40.164.121]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16867 invoked from network); 4 Sep 2012 18:57:19 -0000
Received: from static.121.164.40.188.clients.your-server.de (HELO
	smtp.eikelenboom.it) (188.40.164.121)
	by server-15.tower-27.messagelabs.com with AES256-SHA encrypted SMTP;
	4 Sep 2012 18:57:19 -0000
Received: from 128-64-ftth.onsneteindhoven.nl ([88.159.64.128]:57241
	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 1T8yGD-0000Pz-0j; Tue, 04 Sep 2012 20:54:05 +0200
Date: Tue, 4 Sep 2012 20:57:11 +0200
From: Sander Eikelenboom <linux@eikelenboom.it>
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <291108522.20120904205711@eikelenboom.it>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
In-Reply-To: <20120904182241.GC10379@phenom.dumpdata.com>
References: <1136369816.20120904183757@eikelenboom.it>
	<20120904163347.GH23361@phenom.dumpdata.com>
	<143844933.20120904191941@eikelenboom.it>
	<CAOvdn6U_yHgtZwv9MWazdLbd3NLq3pwGXnZY5sL2UVBhV_FUoQ@mail.gmail.com>
	<20120904182241.GC10379@phenom.dumpdata.com>
MIME-Version: 1.0
Cc: robert.phillips@citrix.com, Ben Guthro <ben@guthro.net>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] dom0 linux 3.6.0-rc4,
	crash due to ballooning althoug dom0_mem=X, max:X 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


Tuesday, September 4, 2012, 8:22:41 PM, you wrote:

> On Tue, Sep 04, 2012 at 02:07:11PM -0400, Ben Guthro wrote:
>> We ran into the same issue, in newer kernels - but had not yet
>> submitted this fix.
>> 
>> One of the developers here came up with a fix (attached, and CC'ed
>> here) that fixes an issue where the p2m code reuses a structure member
>> where it shouldn't.
>> The patch adds a new "old_mfn"  member to the gnttab_map_grant_ref
>> structure, instead of re-using  dev_bus_addr.

> Wow. So that implies the m2p code had some new wonkiness in it.

> Perhaps this b9e0d95c041ca2d7ad297ee37c2e9cfab67a188f
> or
> 0930bba674e248b921ea659b036ff02564e5a5f4

> both courtesy of Stefano (who is on vacation this week :-())
> are at fault?

> Would it be possible to revert one of them (or both) and see if the
> issues disappear?

reverting b9e0d95c041ca2d7ad297ee37c2e9cfab67a188f didn't help

reverting 0930bba674e248b921ea659b036ff02564e5a5f4 didn't work out due to a lot of merge conflicts :S

>> 
>> 
>> If this also works for you, I can re-submit it with a Signed-off-by
>> line, if you prefer, Konrad.
>> 
>> Ben
>> 
>> 
>> On Tue, Sep 4, 2012 at 1:19 PM, Sander Eikelenboom <linux@eikelenboom.it> wrote:
>> >
>> > Tuesday, September 4, 2012, 6:33:47 PM, you wrote:
>> >
>> >> On Tue, Sep 04, 2012 at 06:37:57PM +0200, Sander Eikelenboom wrote:
>> >>> Hi Konrad,
>> >>>
>> >>> This seems to happen only on a intel machine i'm trying to setup as a development machine (haven't seen it on my amd).
>> >>> It boots fine, i have dom0_mem=1024M,max:1024M set, the machine has 2G of mem.
>> >
>> >> Is this only with Xen 4.2? As, does Xen 4.1 work?
>> >>>
>> >>> Dom0 and guest kernel are 3.6.0-rc4 with config:
>> >
>> >> If you back out:
>> >
>> >> f393387d160211f60398d58463a7e65
>> >> Author: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
>> >> Date:   Fri Aug 17 16:43:28 2012 -0400
>> >
>> >>     xen/setup: Fix one-off error when adding for-balloon PFNs to the P2M.
>> >
>> >> Do you see this bug? (Either with Xen 4.1 or Xen 4.2)?
>> >
>> > With c96aae1f7f393387d160211f60398d58463a7e65 reverted i still see this bug (with Xen 4.2).
>> >
>> > Will use the debug patch you mailed and send back the results ...
>> >
>> >
>> >>> [*] Xen memory balloon driver
>> >>> [*]   Scrub pages before returning them to system
>> >>>
>> >>> From http://wiki.xen.org/wiki/Do%EF%BB%BFm0_Memory_%E2%80%94_Where_It_Has_Not_Gone , I thought this should be okay
>> >>>
>> >>> But when trying to start a PV guest with 512MB mem, the machine (dom0) crashes with the stacktrace below (complete serial-log.txt attached).
>> >>>
>> >>> From the:
>> >>> "mapping kernel into physical memory
>> >>> about to get started..."
>> >>>
>> >>> I would almost say it's trying to reload dom0 ?
>> >>>
>> >>>
>> >>> [  897.161119] device vif1.0 entered promiscuous mode
>> >>> mapping kernel into physical memory
>> >>> about to get started...
>> >>> [  897.696619] xen_bridge: port 1(vif1.0) entered forwarding state
>> >>> [  897.716219] xen_bridge: port 1(vif1.0) entered forwarding state
>> >>> [  898.129465] ------------[ cut here ]------------
>> >>> [  898.132209] kernel BUG at drivers/xen/balloon.c:359!
>> >>> [  898.132209] invalid opcode: 0000 [#1] PREEMPT SMP
>> >
>> >
>> >
>> > _______________________________________________
>> > Xen-devel mailing list
>> > Xen-devel@lists.xen.org
>> > http://lists.xen.org/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 Sep 04 18:57:50 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Sep 2012 18: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 1T8yJa-0007y8-GG; Tue, 04 Sep 2012 18:57:34 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <linux@eikelenboom.it>) id 1T8yJZ-0007y3-A6
	for xen-devel@lists.xen.org; Tue, 04 Sep 2012 18:57:33 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-15.tower-27.messagelabs.com!1346785037!2582633!1
X-Originating-IP: [188.40.164.121]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16867 invoked from network); 4 Sep 2012 18:57:19 -0000
Received: from static.121.164.40.188.clients.your-server.de (HELO
	smtp.eikelenboom.it) (188.40.164.121)
	by server-15.tower-27.messagelabs.com with AES256-SHA encrypted SMTP;
	4 Sep 2012 18:57:19 -0000
Received: from 128-64-ftth.onsneteindhoven.nl ([88.159.64.128]:57241
	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 1T8yGD-0000Pz-0j; Tue, 04 Sep 2012 20:54:05 +0200
Date: Tue, 4 Sep 2012 20:57:11 +0200
From: Sander Eikelenboom <linux@eikelenboom.it>
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <291108522.20120904205711@eikelenboom.it>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
In-Reply-To: <20120904182241.GC10379@phenom.dumpdata.com>
References: <1136369816.20120904183757@eikelenboom.it>
	<20120904163347.GH23361@phenom.dumpdata.com>
	<143844933.20120904191941@eikelenboom.it>
	<CAOvdn6U_yHgtZwv9MWazdLbd3NLq3pwGXnZY5sL2UVBhV_FUoQ@mail.gmail.com>
	<20120904182241.GC10379@phenom.dumpdata.com>
MIME-Version: 1.0
Cc: robert.phillips@citrix.com, Ben Guthro <ben@guthro.net>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] dom0 linux 3.6.0-rc4,
	crash due to ballooning althoug dom0_mem=X, max:X 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


Tuesday, September 4, 2012, 8:22:41 PM, you wrote:

> On Tue, Sep 04, 2012 at 02:07:11PM -0400, Ben Guthro wrote:
>> We ran into the same issue, in newer kernels - but had not yet
>> submitted this fix.
>> 
>> One of the developers here came up with a fix (attached, and CC'ed
>> here) that fixes an issue where the p2m code reuses a structure member
>> where it shouldn't.
>> The patch adds a new "old_mfn"  member to the gnttab_map_grant_ref
>> structure, instead of re-using  dev_bus_addr.

> Wow. So that implies the m2p code had some new wonkiness in it.

> Perhaps this b9e0d95c041ca2d7ad297ee37c2e9cfab67a188f
> or
> 0930bba674e248b921ea659b036ff02564e5a5f4

> both courtesy of Stefano (who is on vacation this week :-())
> are at fault?

> Would it be possible to revert one of them (or both) and see if the
> issues disappear?

reverting b9e0d95c041ca2d7ad297ee37c2e9cfab67a188f didn't help

reverting 0930bba674e248b921ea659b036ff02564e5a5f4 didn't work out due to a lot of merge conflicts :S

>> 
>> 
>> If this also works for you, I can re-submit it with a Signed-off-by
>> line, if you prefer, Konrad.
>> 
>> Ben
>> 
>> 
>> On Tue, Sep 4, 2012 at 1:19 PM, Sander Eikelenboom <linux@eikelenboom.it> wrote:
>> >
>> > Tuesday, September 4, 2012, 6:33:47 PM, you wrote:
>> >
>> >> On Tue, Sep 04, 2012 at 06:37:57PM +0200, Sander Eikelenboom wrote:
>> >>> Hi Konrad,
>> >>>
>> >>> This seems to happen only on a intel machine i'm trying to setup as a development machine (haven't seen it on my amd).
>> >>> It boots fine, i have dom0_mem=1024M,max:1024M set, the machine has 2G of mem.
>> >
>> >> Is this only with Xen 4.2? As, does Xen 4.1 work?
>> >>>
>> >>> Dom0 and guest kernel are 3.6.0-rc4 with config:
>> >
>> >> If you back out:
>> >
>> >> f393387d160211f60398d58463a7e65
>> >> Author: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
>> >> Date:   Fri Aug 17 16:43:28 2012 -0400
>> >
>> >>     xen/setup: Fix one-off error when adding for-balloon PFNs to the P2M.
>> >
>> >> Do you see this bug? (Either with Xen 4.1 or Xen 4.2)?
>> >
>> > With c96aae1f7f393387d160211f60398d58463a7e65 reverted i still see this bug (with Xen 4.2).
>> >
>> > Will use the debug patch you mailed and send back the results ...
>> >
>> >
>> >>> [*] Xen memory balloon driver
>> >>> [*]   Scrub pages before returning them to system
>> >>>
>> >>> From http://wiki.xen.org/wiki/Do%EF%BB%BFm0_Memory_%E2%80%94_Where_It_Has_Not_Gone , I thought this should be okay
>> >>>
>> >>> But when trying to start a PV guest with 512MB mem, the machine (dom0) crashes with the stacktrace below (complete serial-log.txt attached).
>> >>>
>> >>> From the:
>> >>> "mapping kernel into physical memory
>> >>> about to get started..."
>> >>>
>> >>> I would almost say it's trying to reload dom0 ?
>> >>>
>> >>>
>> >>> [  897.161119] device vif1.0 entered promiscuous mode
>> >>> mapping kernel into physical memory
>> >>> about to get started...
>> >>> [  897.696619] xen_bridge: port 1(vif1.0) entered forwarding state
>> >>> [  897.716219] xen_bridge: port 1(vif1.0) entered forwarding state
>> >>> [  898.129465] ------------[ cut here ]------------
>> >>> [  898.132209] kernel BUG at drivers/xen/balloon.c:359!
>> >>> [  898.132209] invalid opcode: 0000 [#1] PREEMPT SMP
>> >
>> >
>> >
>> > _______________________________________________
>> > Xen-devel mailing list
>> > Xen-devel@lists.xen.org
>> > http://lists.xen.org/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 Sep 04 19:02:16 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Sep 2012 19:02:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T8yNu-00088S-9O; Tue, 04 Sep 2012 19:02:02 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <linux@eikelenboom.it>) id 1T8yNt-00088F-Dt
	for xen-devel@lists.xen.org; Tue, 04 Sep 2012 19:02:01 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-8.tower-27.messagelabs.com!1346785315!9540963!1
X-Originating-IP: [188.40.164.121]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31280 invoked from network); 4 Sep 2012 19:01:55 -0000
Received: from static.121.164.40.188.clients.your-server.de (HELO
	smtp.eikelenboom.it) (188.40.164.121)
	by server-8.tower-27.messagelabs.com with AES256-SHA encrypted SMTP;
	4 Sep 2012 19:01:55 -0000
Received: from 128-64-ftth.onsneteindhoven.nl ([88.159.64.128]:57243
	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 1T8yKk-0000RT-C5; Tue, 04 Sep 2012 20:58:46 +0200
Date: Tue, 4 Sep 2012 21:01:53 +0200
From: Sander Eikelenboom <linux@eikelenboom.it>
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <1129561405.20120904210153@eikelenboom.it>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
In-Reply-To: <20120904175841.GA10379@phenom.dumpdata.com>
References: <1136369816.20120904183757@eikelenboom.it>
	<20120904163903.GI23361@phenom.dumpdata.com>
	<8328705.20120904200241@eikelenboom.it>
	<20120904175841.GA10379@phenom.dumpdata.com>
MIME-Version: 1.0
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] dom0 linux 3.6.0-rc4,
	crash due to ballooning althoug dom0_mem=X, max:X 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


Tuesday, September 4, 2012, 7:58:41 PM, you wrote:

> On Tue, Sep 04, 2012 at 08:02:41PM +0200, Sander Eikelenboom wrote:
>> 
>> Tuesday, September 4, 2012, 6:39:03 PM, you wrote:
>> 
>> > On Tue, Sep 04, 2012 at 06:37:57PM +0200, Sander Eikelenboom wrote:
>> >> Hi Konrad,
>> >> 
>> >> This seems to happen only on a intel machine i'm trying to setup as a development machine (haven't seen it on my amd).
>> >> It boots fine, i have dom0_mem=1024M,max:1024M set, the machine has 2G of mem.
>> >> 
>> >> Dom0 and guest kernel are 3.6.0-rc4 with config:
>> >> [*] Xen memory balloon driver
>> >> [*]   Scrub pages before returning them to system
>> 
>> > Can you also try this patch out and provide the full log (bootup and such). Thanks!
>> 
>> After applying this patch and due to the removal of the BUG_ON the domU boots and is reachable by SSH.
>> Serial log attached.

> Wow. That is a lot of .. And if you use Xen 4.1 it works fine?

Uhmm don't know, didn't use this machine for a while, doing things like writing a master thesis :)
Upgraded xen and kernel from 2.6.36 kernel and xen 4.0something to 3.6.0-rc4 and 4.2-rc4

Trying to make it work and try to make some xen patches :-p
But i seem to be stumbling over quite a lot of things with both machines(amd and intel) while going to xen 4.2 (and from xm to xl)


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

From xen-devel-bounces@lists.xen.org Tue Sep 04 19:02:16 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Sep 2012 19:02:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T8yNu-00088S-9O; Tue, 04 Sep 2012 19:02:02 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <linux@eikelenboom.it>) id 1T8yNt-00088F-Dt
	for xen-devel@lists.xen.org; Tue, 04 Sep 2012 19:02:01 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-8.tower-27.messagelabs.com!1346785315!9540963!1
X-Originating-IP: [188.40.164.121]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31280 invoked from network); 4 Sep 2012 19:01:55 -0000
Received: from static.121.164.40.188.clients.your-server.de (HELO
	smtp.eikelenboom.it) (188.40.164.121)
	by server-8.tower-27.messagelabs.com with AES256-SHA encrypted SMTP;
	4 Sep 2012 19:01:55 -0000
Received: from 128-64-ftth.onsneteindhoven.nl ([88.159.64.128]:57243
	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 1T8yKk-0000RT-C5; Tue, 04 Sep 2012 20:58:46 +0200
Date: Tue, 4 Sep 2012 21:01:53 +0200
From: Sander Eikelenboom <linux@eikelenboom.it>
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <1129561405.20120904210153@eikelenboom.it>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
In-Reply-To: <20120904175841.GA10379@phenom.dumpdata.com>
References: <1136369816.20120904183757@eikelenboom.it>
	<20120904163903.GI23361@phenom.dumpdata.com>
	<8328705.20120904200241@eikelenboom.it>
	<20120904175841.GA10379@phenom.dumpdata.com>
MIME-Version: 1.0
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] dom0 linux 3.6.0-rc4,
	crash due to ballooning althoug dom0_mem=X, max:X 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


Tuesday, September 4, 2012, 7:58:41 PM, you wrote:

> On Tue, Sep 04, 2012 at 08:02:41PM +0200, Sander Eikelenboom wrote:
>> 
>> Tuesday, September 4, 2012, 6:39:03 PM, you wrote:
>> 
>> > On Tue, Sep 04, 2012 at 06:37:57PM +0200, Sander Eikelenboom wrote:
>> >> Hi Konrad,
>> >> 
>> >> This seems to happen only on a intel machine i'm trying to setup as a development machine (haven't seen it on my amd).
>> >> It boots fine, i have dom0_mem=1024M,max:1024M set, the machine has 2G of mem.
>> >> 
>> >> Dom0 and guest kernel are 3.6.0-rc4 with config:
>> >> [*] Xen memory balloon driver
>> >> [*]   Scrub pages before returning them to system
>> 
>> > Can you also try this patch out and provide the full log (bootup and such). Thanks!
>> 
>> After applying this patch and due to the removal of the BUG_ON the domU boots and is reachable by SSH.
>> Serial log attached.

> Wow. That is a lot of .. And if you use Xen 4.1 it works fine?

Uhmm don't know, didn't use this machine for a while, doing things like writing a master thesis :)
Upgraded xen and kernel from 2.6.36 kernel and xen 4.0something to 3.6.0-rc4 and 4.2-rc4

Trying to make it work and try to make some xen patches :-p
But i seem to be stumbling over quite a lot of things with both machines(amd and intel) while going to xen 4.2 (and from xm to xl)


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

From xen-devel-bounces@lists.xen.org Tue Sep 04 19:12:56 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Sep 2012 19:12:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T8yY8-0008KX-E5; Tue, 04 Sep 2012 19:12:36 +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 1T8yY6-0008KS-Iu
	for xen-devel@lists.xen.org; Tue, 04 Sep 2012 19:12:34 +0000
Received: from [85.158.139.83:50763] by server-10.bemta-5.messagelabs.com id
	DC/60-10969-1A256405; Tue, 04 Sep 2012 19:12:33 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-2.tower-182.messagelabs.com!1346785950!28544961!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA1MDA5NDY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29573 invoked from network); 4 Sep 2012 19:12:30 -0000
Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25)
	by server-2.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 4 Sep 2012 19:12: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 D5ABD1A3C;
	Tue,  4 Sep 2012 22:12:29 +0300 (EEST)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id 3D4C92005D; Tue,  4 Sep 2012 22:12:29 +0300 (EEST)
Date: Tue, 4 Sep 2012 22:12:29 +0300
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120904191229.GH8912@reaktio.net>
References: <20120902053549.GF8912@reaktio.net>
	<1346667053.25864.21.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1346667053.25864.21.camel@zakaz.uk.xensource.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] [PATCH] xl.cfg: gfx_passthru documentation
 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 Mon, Sep 03, 2012 at 11:10:53AM +0100, Ian Campbell wrote:
> On Sun, 2012-09-02 at 06:35 +0100, Pasi K=E4rkk=E4inen wrote:
> > Hello,
> > =

> > xl.cfg.pod.5 documentation improvements:
> > =

> > - gfx_passthru: Document gfx_passthru makes the GPU become primary in t=
he guest
> >   and other generic info about gfx_passthru.
> > =

> > =

> > Signed-off-by: Pasi K=E4rkk=E4inen <pasik@iki.fi>
> > --- docs/man/xl.cfg.pod.5.orig1 2012-09-02 07:16:39.316782158 +0300
> > +++ docs/man/xl.cfg.pod.5       2012-09-02 08:26:40.081639087 +0300
> > @@ -968,7 +968,43 @@
> >  =

> >  =3Ditem B<gfx_passthru=3DBOOLEAN>
> >  =

> > -Enable graphics device PCI passthrough. XXX which device is passed thr=
ough ?
> > +Enable graphics device PCI passthrough. This option makes the passthru
> > +graphics card become primary graphics card in the VM,
> =

> The option is slightly misnamed then I guess, a better name would have
> been gfx_passthru_primary? oh well, we are stuck with it now.
> =


Yeah.. I think earlier gfx_passthru wasn't a boolean, but an integer, to ch=
oose the mode.

> (Am I alone in thinking that "thru" is a horrible alternative to
> through?)
> =


:) =


> >  so the Qemu emulated =

> > +graphics adapter is disabled, and the VNC console for the VM won't have
> > +any graphics output. All graphics output, including boot time Qemu BIOS
> > +messages from the VM, will go to the physical outputs of the passed th=
ru
> > +physical graphics card.
> > +
> > +Graphics card PCI device to passthru is chosen with B<pci> option, =

> > +exactly in the same way as normal Xen PCI device passthru/assignment i=
s done. =

> > +Note that gfx_passthru doesn't do any kind of sharing
> > +of the GPU, so you can only assign the GPU to one single VM at a time.
> > +
> > +gfx_passthru also enables various legacy VGA memory ranges, BARs, MMIO=
s, =

> > +and ioports to be passed thru to the VM, since those are required
> > +for correct operation of things like VGA BIOS, text mode, VBE, etc.
> > +
> > +Enabling gfx_passthru option also copies the physical graphics card =

> > +video bios to the guest memory, and executes the vbios in the guest =

> =

> "BIOS" and (I expect) "VBIOS"?
> =


video bios =3D=3D vbios, or did you ask something else? =



> > +to get the graphics card initialized.
> > +
> > +Most graphics adapters require vendor specific tweaks for properly
> > +working graphics passthru. Xen currently includes necessary tweaks
> > +for Intel IGD (Integrated Graphics Device) GPUs.  =

> > +
> > +Support for AMD/Nvidia gfx_passthru is not yet merged to Xen,
> > +but there are out-of-tree patches available.
> =

> If there is a comprehensive list of supported/not-supported devices on
> the wiki then I think a reference here would be more useful than these
> two brief paragraphs.
> =


We have a list, but it's not up-to-date unfortunately:
http://wiki.xen.org/wiki/XenVGAPassthroughTestedAdapters


> In particular the second isn't very useful without links and those tend
> to become out of date in docs IME, I would tend to omit this from here
> and instead include them in the wiki where they can be kept up to date
>

Ok. I'll fix that, and add a link to:
http://wiki.xen.org/wiki/XenVGAPassthrough


> (or better yet somebody could finally submit the patches for inclusion).
> =


Indeed. I was talking to both AMD and Nvidia engineers at XenSummit NA 2012,
and there's some hope for them to do some work on this stuff :) =


And I volunteered earlier for this aswell, but so far I've been way too bus=
y with other things :(


> > +gfx_passthru is currently only supported with the qemu-xen-traditional
> > +device-model. Upstream qemu-xen device-model currently doesn't have
> > +support for gfx_passthru.
> > +
> > +Note that some graphics adapters (AMD/ATI cards, for example) don't
> > +necessarily require gfx_passthru option, so you can use the normal
> > +Xen PCI passthru to assign the graphics card as a secondary graphics c=
ard
> > +to the VM. Qemu emulated graphics card stays as the primary graphics c=
ard, =

> > +and you get VNC output from the Qemu-emulated primary adapter.
> > +
> >  =

> >  =3Ditem B<nomigrate=3DBOOLEAN>
> > =

> =



-- Pasi



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

From xen-devel-bounces@lists.xen.org Tue Sep 04 19:12:56 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Sep 2012 19:12:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T8yY8-0008KX-E5; Tue, 04 Sep 2012 19:12:36 +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 1T8yY6-0008KS-Iu
	for xen-devel@lists.xen.org; Tue, 04 Sep 2012 19:12:34 +0000
Received: from [85.158.139.83:50763] by server-10.bemta-5.messagelabs.com id
	DC/60-10969-1A256405; Tue, 04 Sep 2012 19:12:33 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-2.tower-182.messagelabs.com!1346785950!28544961!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA1MDA5NDY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29573 invoked from network); 4 Sep 2012 19:12:30 -0000
Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25)
	by server-2.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 4 Sep 2012 19:12: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 D5ABD1A3C;
	Tue,  4 Sep 2012 22:12:29 +0300 (EEST)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id 3D4C92005D; Tue,  4 Sep 2012 22:12:29 +0300 (EEST)
Date: Tue, 4 Sep 2012 22:12:29 +0300
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120904191229.GH8912@reaktio.net>
References: <20120902053549.GF8912@reaktio.net>
	<1346667053.25864.21.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1346667053.25864.21.camel@zakaz.uk.xensource.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] [PATCH] xl.cfg: gfx_passthru documentation
 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 Mon, Sep 03, 2012 at 11:10:53AM +0100, Ian Campbell wrote:
> On Sun, 2012-09-02 at 06:35 +0100, Pasi K=E4rkk=E4inen wrote:
> > Hello,
> > =

> > xl.cfg.pod.5 documentation improvements:
> > =

> > - gfx_passthru: Document gfx_passthru makes the GPU become primary in t=
he guest
> >   and other generic info about gfx_passthru.
> > =

> > =

> > Signed-off-by: Pasi K=E4rkk=E4inen <pasik@iki.fi>
> > --- docs/man/xl.cfg.pod.5.orig1 2012-09-02 07:16:39.316782158 +0300
> > +++ docs/man/xl.cfg.pod.5       2012-09-02 08:26:40.081639087 +0300
> > @@ -968,7 +968,43 @@
> >  =

> >  =3Ditem B<gfx_passthru=3DBOOLEAN>
> >  =

> > -Enable graphics device PCI passthrough. XXX which device is passed thr=
ough ?
> > +Enable graphics device PCI passthrough. This option makes the passthru
> > +graphics card become primary graphics card in the VM,
> =

> The option is slightly misnamed then I guess, a better name would have
> been gfx_passthru_primary? oh well, we are stuck with it now.
> =


Yeah.. I think earlier gfx_passthru wasn't a boolean, but an integer, to ch=
oose the mode.

> (Am I alone in thinking that "thru" is a horrible alternative to
> through?)
> =


:) =


> >  so the Qemu emulated =

> > +graphics adapter is disabled, and the VNC console for the VM won't have
> > +any graphics output. All graphics output, including boot time Qemu BIOS
> > +messages from the VM, will go to the physical outputs of the passed th=
ru
> > +physical graphics card.
> > +
> > +Graphics card PCI device to passthru is chosen with B<pci> option, =

> > +exactly in the same way as normal Xen PCI device passthru/assignment i=
s done. =

> > +Note that gfx_passthru doesn't do any kind of sharing
> > +of the GPU, so you can only assign the GPU to one single VM at a time.
> > +
> > +gfx_passthru also enables various legacy VGA memory ranges, BARs, MMIO=
s, =

> > +and ioports to be passed thru to the VM, since those are required
> > +for correct operation of things like VGA BIOS, text mode, VBE, etc.
> > +
> > +Enabling gfx_passthru option also copies the physical graphics card =

> > +video bios to the guest memory, and executes the vbios in the guest =

> =

> "BIOS" and (I expect) "VBIOS"?
> =


video bios =3D=3D vbios, or did you ask something else? =



> > +to get the graphics card initialized.
> > +
> > +Most graphics adapters require vendor specific tweaks for properly
> > +working graphics passthru. Xen currently includes necessary tweaks
> > +for Intel IGD (Integrated Graphics Device) GPUs.  =

> > +
> > +Support for AMD/Nvidia gfx_passthru is not yet merged to Xen,
> > +but there are out-of-tree patches available.
> =

> If there is a comprehensive list of supported/not-supported devices on
> the wiki then I think a reference here would be more useful than these
> two brief paragraphs.
> =


We have a list, but it's not up-to-date unfortunately:
http://wiki.xen.org/wiki/XenVGAPassthroughTestedAdapters


> In particular the second isn't very useful without links and those tend
> to become out of date in docs IME, I would tend to omit this from here
> and instead include them in the wiki where they can be kept up to date
>

Ok. I'll fix that, and add a link to:
http://wiki.xen.org/wiki/XenVGAPassthrough


> (or better yet somebody could finally submit the patches for inclusion).
> =


Indeed. I was talking to both AMD and Nvidia engineers at XenSummit NA 2012,
and there's some hope for them to do some work on this stuff :) =


And I volunteered earlier for this aswell, but so far I've been way too bus=
y with other things :(


> > +gfx_passthru is currently only supported with the qemu-xen-traditional
> > +device-model. Upstream qemu-xen device-model currently doesn't have
> > +support for gfx_passthru.
> > +
> > +Note that some graphics adapters (AMD/ATI cards, for example) don't
> > +necessarily require gfx_passthru option, so you can use the normal
> > +Xen PCI passthru to assign the graphics card as a secondary graphics c=
ard
> > +to the VM. Qemu emulated graphics card stays as the primary graphics c=
ard, =

> > +and you get VNC output from the Qemu-emulated primary adapter.
> > +
> >  =

> >  =3Ditem B<nomigrate=3DBOOLEAN>
> > =

> =



-- Pasi



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

From xen-devel-bounces@lists.xen.org Tue Sep 04 19:35:41 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Sep 2012 19:35:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T8yu5-00007Y-Hc; Tue, 04 Sep 2012 19:35:17 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <linux@eikelenboom.it>) id 1T8yu3-00007Q-GM
	for xen-devel@lists.xen.org; Tue, 04 Sep 2012 19:35:15 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-12.tower-27.messagelabs.com!1346787302!9563650!1
X-Originating-IP: [188.40.164.121]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25725 invoked from network); 4 Sep 2012 19:35:03 -0000
Received: from static.121.164.40.188.clients.your-server.de (HELO
	smtp.eikelenboom.it) (188.40.164.121)
	by server-12.tower-27.messagelabs.com with AES256-SHA encrypted SMTP;
	4 Sep 2012 19:35:03 -0000
Received: from 128-64-ftth.onsneteindhoven.nl ([88.159.64.128]:57834
	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 1T8yqn-0000ad-8T; Tue, 04 Sep 2012 21:31:53 +0200
Date: Tue, 4 Sep 2012 21:34:59 +0200
From: Sander Eikelenboom <linux@eikelenboom.it>
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <1813712325.20120904213459@eikelenboom.it>
To: Ben Guthro <ben@guthro.net>
In-Reply-To: <CAOvdn6U_yHgtZwv9MWazdLbd3NLq3pwGXnZY5sL2UVBhV_FUoQ@mail.gmail.com>
References: <1136369816.20120904183757@eikelenboom.it>
	<20120904163347.GH23361@phenom.dumpdata.com>
	<143844933.20120904191941@eikelenboom.it>
	<CAOvdn6U_yHgtZwv9MWazdLbd3NLq3pwGXnZY5sL2UVBhV_FUoQ@mail.gmail.com>
MIME-Version: 1.0
Cc: xen-devel@lists.xen.org, robert.phillips@citrix.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] dom0 linux 3.6.0-rc4,
	crash due to ballooning althoug dom0_mem=X, max:X 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


Tuesday, September 4, 2012, 8:07:11 PM, you wrote:

> We ran into the same issue, in newer kernels - but had not yet
> submitted this fix.

> One of the developers here came up with a fix (attached, and CC'ed
> here) that fixes an issue where the p2m code reuses a structure member
> where it shouldn't.
> The patch adds a new "old_mfn"  member to the gnttab_map_grant_ref
> structure, instead of re-using  dev_bus_addr.


> If this also works for you, I can re-submit it with a Signed-off-by
> line, if you prefer, Konrad.

Hi Ben,

This patch doesn't work for me:

When starting the PV-guest i get:

(XEN) [2012-09-04 20:31:37] grant_table.c:499:d0 Bad flags in grant map op (68b69070).
(XEN) [2012-09-04 20:31:37] grant_table.c:499:d0 Bad flags in grant map op (0).
(XEN) [2012-09-04 20:31:37] grant_table.c:499:d0 Bad flags in grant map op (0).


and from the dom0 kernel:

[  374.425727] BUG: unable to handle kernel paging request at ffff8800fffd9078
[  374.428901] IP: [<ffffffff81336e4e>] gnttab_map_refs+0x14e/0x270
[  374.428901] PGD 1e0c067 PUD 0
[  374.428901] Oops: 0000 [#1] PREEMPT SMP
[  374.428901] Modules linked in:
[  374.428901] CPU 0
[  374.428901] Pid: 4308, comm: qemu-system-i38 Not tainted 3.6.0-rc4-20120830+ #70 System manufacturer System Product Name/P5Q-EM DO
[  374.428901] RIP: e030:[<ffffffff81336e4e>]  [<ffffffff81336e4e>] gnttab_map_refs+0x14e/0x270
[  374.428901] RSP: e02b:ffff88002f185ca8  EFLAGS: 00010206
[  374.428901] RAX: ffff880000000000 RBX: ffff88001471cf00 RCX: 00000000fffd9078
[  374.428901] RDX: 0000000000000050 RSI: 40000000000fffd9 RDI: 00003ffffffff000
[  374.428901] RBP: ffff88002f185d08 R08: 0000000000000078 R09: 0000000000000000
[  374.428901] R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000004
[  374.428901] R13: ffff88001471c480 R14: 0000000000000002 R15: 0000000000000002
[  374.428901] FS:  00007f6def9f2740(0000) GS:ffff88003fc00000(0000) knlGS:0000000000000000
[  374.428901] CS:  e033 DS: 0000 ES: 0000 CR0: 000000008005003b
[  374.428901] CR2: ffff8800fffd9078 CR3: 000000002d30e000 CR4: 0000000000042660
[  374.428901] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[  374.428901] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[  374.428901] Process qemu-system-i38 (pid: 4308, threadinfo ffff88002f184000, task ffff8800376f1040)
[  374.428901] Stack:
[  374.428901]  ffffffffffffffff 0000000000000050 00000000fffd9078 00000000000fffd9
[  374.428901]  0000000001000000 ffff8800382135a0 ffff88002f185d08 ffff880038211960
[  374.428901]  ffff88002f11d2c0 0000000000000004 0000000000000003 0000000000000001
[  374.428901] Call Trace:
[  374.428901]  [<ffffffff8134212e>] gntdev_mmap+0x20e/0x520
[  374.428901]  [<ffffffff8111c502>] ? mmap_region+0x312/0x5a0
[  374.428901]  [<ffffffff810ae0a0>] ? lockdep_trace_alloc+0xa0/0x130
[  374.428901]  [<ffffffff8111c5be>] mmap_region+0x3ce/0x5a0
[  374.428901]  [<ffffffff8111c9e0>] do_mmap_pgoff+0x250/0x350
[  374.428901]  [<ffffffff81109e88>] vm_mmap_pgoff+0x68/0x90
[  374.428901]  [<ffffffff8111a5b2>] sys_mmap_pgoff+0x152/0x170
[  374.428901]  [<ffffffff812b29be>] ? trace_hardirqs_on_thunk+0x3a/0x3f
[  374.428901]  [<ffffffff81011f29>] sys_mmap+0x29/0x30
[  374.428901]  [<ffffffff8184b939>] system_call_fastpath+0x16/0x1b
[  374.428901] Code: 0f 84 e7 00 00 00 48 89 f1 48 c1 e1 0c 41 81 e0 ff 0f 00 00 48 b8 00 00 00 00 00 88 ff ff 48 bf 00 f0 ff ff ff 3f 00 00 4c 01 c1 <48> 23 3c 01 48 c1 ef 0c 49 8d 54 15 00 4d 85 ed b8 00 00 00 00
[  374.428901] RIP  [<ffffffff81336e4e>] gnttab_map_refs+0x14e/0x270
[  374.428901]  RSP <ffff88002f185ca8>
[  374.428901] CR2: ffff8800fffd9078
[  374.428901] ---[ end trace 0e0a5a49f6503c0a ]---



> Ben


> On Tue, Sep 4, 2012 at 1:19 PM, Sander Eikelenboom <linux@eikelenboom.it> wrote:
>>
>> Tuesday, September 4, 2012, 6:33:47 PM, you wrote:
>>
>>> On Tue, Sep 04, 2012 at 06:37:57PM +0200, Sander Eikelenboom wrote:
>>>> Hi Konrad,
>>>>
>>>> This seems to happen only on a intel machine i'm trying to setup as a development machine (haven't seen it on my amd).
>>>> It boots fine, i have dom0_mem=1024M,max:1024M set, the machine has 2G of mem.
>>
>>> Is this only with Xen 4.2? As, does Xen 4.1 work?
>>>>
>>>> Dom0 and guest kernel are 3.6.0-rc4 with config:
>>
>>> If you back out:
>>
>>> f393387d160211f60398d58463a7e65
>>> Author: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
>>> Date:   Fri Aug 17 16:43:28 2012 -0400
>>
>>>     xen/setup: Fix one-off error when adding for-balloon PFNs to the P2M.
>>
>>> Do you see this bug? (Either with Xen 4.1 or Xen 4.2)?
>>
>> With c96aae1f7f393387d160211f60398d58463a7e65 reverted i still see this bug (with Xen 4.2).
>>
>> Will use the debug patch you mailed and send back the results ...
>>
>>
>>>> [*] Xen memory balloon driver
>>>> [*]   Scrub pages before returning them to system
>>>>
>>>> From http://wiki.xen.org/wiki/Do%EF%BB%BFm0_Memory_%E2%80%94_Where_It_Has_Not_Gone , I thought this should be okay
>>>>
>>>> But when trying to start a PV guest with 512MB mem, the machine (dom0) crashes with the stacktrace below (complete serial-log.txt attached).
>>>>
>>>> From the:
>>>> "mapping kernel into physical memory
>>>> about to get started..."
>>>>
>>>> I would almost say it's trying to reload dom0 ?
>>>>
>>>>
>>>> [  897.161119] device vif1.0 entered promiscuous mode
>>>> mapping kernel into physical memory
>>>> about to get started...
>>>> [  897.696619] xen_bridge: port 1(vif1.0) entered forwarding state
>>>> [  897.716219] xen_bridge: port 1(vif1.0) entered forwarding state
>>>> [  898.129465] ------------[ cut here ]------------
>>>> [  898.132209] kernel BUG at drivers/xen/balloon.c:359!
>>>> [  898.132209] invalid opcode: 0000 [#1] PREEMPT SMP
>>
>>
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xen.org
>> http://lists.xen.org/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 Sep 04 19:35:41 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Sep 2012 19:35:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T8yu5-00007Y-Hc; Tue, 04 Sep 2012 19:35:17 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <linux@eikelenboom.it>) id 1T8yu3-00007Q-GM
	for xen-devel@lists.xen.org; Tue, 04 Sep 2012 19:35:15 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-12.tower-27.messagelabs.com!1346787302!9563650!1
X-Originating-IP: [188.40.164.121]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25725 invoked from network); 4 Sep 2012 19:35:03 -0000
Received: from static.121.164.40.188.clients.your-server.de (HELO
	smtp.eikelenboom.it) (188.40.164.121)
	by server-12.tower-27.messagelabs.com with AES256-SHA encrypted SMTP;
	4 Sep 2012 19:35:03 -0000
Received: from 128-64-ftth.onsneteindhoven.nl ([88.159.64.128]:57834
	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 1T8yqn-0000ad-8T; Tue, 04 Sep 2012 21:31:53 +0200
Date: Tue, 4 Sep 2012 21:34:59 +0200
From: Sander Eikelenboom <linux@eikelenboom.it>
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <1813712325.20120904213459@eikelenboom.it>
To: Ben Guthro <ben@guthro.net>
In-Reply-To: <CAOvdn6U_yHgtZwv9MWazdLbd3NLq3pwGXnZY5sL2UVBhV_FUoQ@mail.gmail.com>
References: <1136369816.20120904183757@eikelenboom.it>
	<20120904163347.GH23361@phenom.dumpdata.com>
	<143844933.20120904191941@eikelenboom.it>
	<CAOvdn6U_yHgtZwv9MWazdLbd3NLq3pwGXnZY5sL2UVBhV_FUoQ@mail.gmail.com>
MIME-Version: 1.0
Cc: xen-devel@lists.xen.org, robert.phillips@citrix.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] dom0 linux 3.6.0-rc4,
	crash due to ballooning althoug dom0_mem=X, max:X 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


Tuesday, September 4, 2012, 8:07:11 PM, you wrote:

> We ran into the same issue, in newer kernels - but had not yet
> submitted this fix.

> One of the developers here came up with a fix (attached, and CC'ed
> here) that fixes an issue where the p2m code reuses a structure member
> where it shouldn't.
> The patch adds a new "old_mfn"  member to the gnttab_map_grant_ref
> structure, instead of re-using  dev_bus_addr.


> If this also works for you, I can re-submit it with a Signed-off-by
> line, if you prefer, Konrad.

Hi Ben,

This patch doesn't work for me:

When starting the PV-guest i get:

(XEN) [2012-09-04 20:31:37] grant_table.c:499:d0 Bad flags in grant map op (68b69070).
(XEN) [2012-09-04 20:31:37] grant_table.c:499:d0 Bad flags in grant map op (0).
(XEN) [2012-09-04 20:31:37] grant_table.c:499:d0 Bad flags in grant map op (0).


and from the dom0 kernel:

[  374.425727] BUG: unable to handle kernel paging request at ffff8800fffd9078
[  374.428901] IP: [<ffffffff81336e4e>] gnttab_map_refs+0x14e/0x270
[  374.428901] PGD 1e0c067 PUD 0
[  374.428901] Oops: 0000 [#1] PREEMPT SMP
[  374.428901] Modules linked in:
[  374.428901] CPU 0
[  374.428901] Pid: 4308, comm: qemu-system-i38 Not tainted 3.6.0-rc4-20120830+ #70 System manufacturer System Product Name/P5Q-EM DO
[  374.428901] RIP: e030:[<ffffffff81336e4e>]  [<ffffffff81336e4e>] gnttab_map_refs+0x14e/0x270
[  374.428901] RSP: e02b:ffff88002f185ca8  EFLAGS: 00010206
[  374.428901] RAX: ffff880000000000 RBX: ffff88001471cf00 RCX: 00000000fffd9078
[  374.428901] RDX: 0000000000000050 RSI: 40000000000fffd9 RDI: 00003ffffffff000
[  374.428901] RBP: ffff88002f185d08 R08: 0000000000000078 R09: 0000000000000000
[  374.428901] R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000004
[  374.428901] R13: ffff88001471c480 R14: 0000000000000002 R15: 0000000000000002
[  374.428901] FS:  00007f6def9f2740(0000) GS:ffff88003fc00000(0000) knlGS:0000000000000000
[  374.428901] CS:  e033 DS: 0000 ES: 0000 CR0: 000000008005003b
[  374.428901] CR2: ffff8800fffd9078 CR3: 000000002d30e000 CR4: 0000000000042660
[  374.428901] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[  374.428901] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[  374.428901] Process qemu-system-i38 (pid: 4308, threadinfo ffff88002f184000, task ffff8800376f1040)
[  374.428901] Stack:
[  374.428901]  ffffffffffffffff 0000000000000050 00000000fffd9078 00000000000fffd9
[  374.428901]  0000000001000000 ffff8800382135a0 ffff88002f185d08 ffff880038211960
[  374.428901]  ffff88002f11d2c0 0000000000000004 0000000000000003 0000000000000001
[  374.428901] Call Trace:
[  374.428901]  [<ffffffff8134212e>] gntdev_mmap+0x20e/0x520
[  374.428901]  [<ffffffff8111c502>] ? mmap_region+0x312/0x5a0
[  374.428901]  [<ffffffff810ae0a0>] ? lockdep_trace_alloc+0xa0/0x130
[  374.428901]  [<ffffffff8111c5be>] mmap_region+0x3ce/0x5a0
[  374.428901]  [<ffffffff8111c9e0>] do_mmap_pgoff+0x250/0x350
[  374.428901]  [<ffffffff81109e88>] vm_mmap_pgoff+0x68/0x90
[  374.428901]  [<ffffffff8111a5b2>] sys_mmap_pgoff+0x152/0x170
[  374.428901]  [<ffffffff812b29be>] ? trace_hardirqs_on_thunk+0x3a/0x3f
[  374.428901]  [<ffffffff81011f29>] sys_mmap+0x29/0x30
[  374.428901]  [<ffffffff8184b939>] system_call_fastpath+0x16/0x1b
[  374.428901] Code: 0f 84 e7 00 00 00 48 89 f1 48 c1 e1 0c 41 81 e0 ff 0f 00 00 48 b8 00 00 00 00 00 88 ff ff 48 bf 00 f0 ff ff ff 3f 00 00 4c 01 c1 <48> 23 3c 01 48 c1 ef 0c 49 8d 54 15 00 4d 85 ed b8 00 00 00 00
[  374.428901] RIP  [<ffffffff81336e4e>] gnttab_map_refs+0x14e/0x270
[  374.428901]  RSP <ffff88002f185ca8>
[  374.428901] CR2: ffff8800fffd9078
[  374.428901] ---[ end trace 0e0a5a49f6503c0a ]---



> Ben


> On Tue, Sep 4, 2012 at 1:19 PM, Sander Eikelenboom <linux@eikelenboom.it> wrote:
>>
>> Tuesday, September 4, 2012, 6:33:47 PM, you wrote:
>>
>>> On Tue, Sep 04, 2012 at 06:37:57PM +0200, Sander Eikelenboom wrote:
>>>> Hi Konrad,
>>>>
>>>> This seems to happen only on a intel machine i'm trying to setup as a development machine (haven't seen it on my amd).
>>>> It boots fine, i have dom0_mem=1024M,max:1024M set, the machine has 2G of mem.
>>
>>> Is this only with Xen 4.2? As, does Xen 4.1 work?
>>>>
>>>> Dom0 and guest kernel are 3.6.0-rc4 with config:
>>
>>> If you back out:
>>
>>> f393387d160211f60398d58463a7e65
>>> Author: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
>>> Date:   Fri Aug 17 16:43:28 2012 -0400
>>
>>>     xen/setup: Fix one-off error when adding for-balloon PFNs to the P2M.
>>
>>> Do you see this bug? (Either with Xen 4.1 or Xen 4.2)?
>>
>> With c96aae1f7f393387d160211f60398d58463a7e65 reverted i still see this bug (with Xen 4.2).
>>
>> Will use the debug patch you mailed and send back the results ...
>>
>>
>>>> [*] Xen memory balloon driver
>>>> [*]   Scrub pages before returning them to system
>>>>
>>>> From http://wiki.xen.org/wiki/Do%EF%BB%BFm0_Memory_%E2%80%94_Where_It_Has_Not_Gone , I thought this should be okay
>>>>
>>>> But when trying to start a PV guest with 512MB mem, the machine (dom0) crashes with the stacktrace below (complete serial-log.txt attached).
>>>>
>>>> From the:
>>>> "mapping kernel into physical memory
>>>> about to get started..."
>>>>
>>>> I would almost say it's trying to reload dom0 ?
>>>>
>>>>
>>>> [  897.161119] device vif1.0 entered promiscuous mode
>>>> mapping kernel into physical memory
>>>> about to get started...
>>>> [  897.696619] xen_bridge: port 1(vif1.0) entered forwarding state
>>>> [  897.716219] xen_bridge: port 1(vif1.0) entered forwarding state
>>>> [  898.129465] ------------[ cut here ]------------
>>>> [  898.132209] kernel BUG at drivers/xen/balloon.c:359!
>>>> [  898.132209] invalid opcode: 0000 [#1] PREEMPT SMP
>>
>>
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xen.org
>> http://lists.xen.org/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 Sep 04 19:45:32 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Sep 2012 19: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 1T8z3c-0000HQ-K7; Tue, 04 Sep 2012 19:45:08 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <misiu.godfrey@gmail.com>) id 1T8z3a-0000HL-Tq
	for xen-devel@lists.xen.org; Tue, 04 Sep 2012 19:45:07 +0000
X-Env-Sender: misiu.godfrey@gmail.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1346787900!2753530!1
X-Originating-IP: [74.125.82.51]
X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_20_30,HTML_MESSAGE,
	RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20821 invoked from network); 4 Sep 2012 19:45:00 -0000
Received: from mail-wg0-f51.google.com (HELO mail-wg0-f51.google.com)
	(74.125.82.51)
	by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Sep 2012 19:45:00 -0000
Received: by wgbed3 with SMTP id ed3so4148474wgb.32
	for <xen-devel@lists.xen.org>; Tue, 04 Sep 2012 12:45: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=UfXXQILUfAxcAgPNyS+twGUdPxPxzc71YgMZisUjeDk=;
	b=HAX6ftG0SIydYP7AzlxYLJsNSzwxr1VfauUaBBL0cBpydPfW6W8hAbfGzbH/Zg7uNq
	sjDdGWFeI0vHBOnuGLx+o3E9WsUthg9jOjYpW8rTDbsItl8jRFVk+l9jxdOZslc0SvC1
	X/cERejxhE2gYUf2kUcHfxGufgOLf6h8PkS1SXNsrKTVIVFHVQWQnQeD2xx4D8W6URaa
	l0PCHsQfeoM/UvwllUgGbRsRWCQ1fHNTNu4JcvSItuPjIRO+AhY0RPumuF1oVZK04VRo
	u4C8Ns9z3/IKLJlsT4ICrJgkdJipnO6I9U/A/G5kXITjam7dJVP+6sgS4lIZ9sCmmy20
	rWfw==
MIME-Version: 1.0
Received: by 10.216.208.104 with SMTP id p82mr12269211weo.119.1346787900382;
	Tue, 04 Sep 2012 12:45:00 -0700 (PDT)
Received: by 10.194.13.7 with HTTP; Tue, 4 Sep 2012 12:45:00 -0700 (PDT)
In-Reply-To: <50464954.5030207@citrix.com>
References: <CAMVU=QgzjT1daB5_zfoP2amtbvWX3X5XZKE6Bj1eX-tTDY=xSQ@mail.gmail.com>
	<50464954.5030207@citrix.com>
Date: Tue, 4 Sep 2012 15:45:00 -0400
X-Google-Sender-Auth: Eonsa7QSWZUUoJlyownXlDyGU2k
Message-ID: <CAMVU=QgJG=cNH69-kKdWULzV6n2kRrn=d78n75NKuMM_9VXQ9w@mail.gmail.com>
From: misiu godfrey <godfrey@cs.queensu.ca>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] additional domain.c memory allocation causes "xm
 create" to fail
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0173812192847604894=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============0173812192847604894==
Content-Type: multipart/alternative; boundary=0016e6db7ca663dfe204c8e57efa

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

> For what purpose?  There was once a bug which caused this to happen and
> it caused Xen to slow to a glacial pace.  We got bored of debugging HVM
> domains after several hours and the BIOS has still not loaded the
> bootloader.
>

I'm working on an experiment to do with cache-based side channels in Cloud
environments.  Part of it involves measuring the effect of flushing the
cache every time there is a VM switch.

You don't check the return value, so what happens when the allocation
> fails?  I would say that calling *alloc() is not a sensible thing to be
> doing in __context_switch() anyway, as you are sitting doing a long
> operation while in a critical section of Xen code.
>

Unfortunately, I can chalk that up to my inexperience with C programming.
 Thanks for pointing that out.

As for the sensibility of the plan, it is still in rather early stages and
not as robust as I would like it.  As I get more working I was planning on
leaving the memory buffer permanently allocated so as not to spend time
managing it in a critical section.  If you have a suggestion for a more
practical solution I'm all ears.

Furthermore, this algorithm has no guarantee to clear the L2 cache.  In
> fact is almost certainly will not.
>

This is the code that has worked in all of my prior experiments and has
been ratified by others I have worked with.  Are you sure it wouldn't work?
 While, for simplicity's sake, I have removed portions of the code designed
to prevent pre-fetching and perhaps left out something important, my
understanding of cache-coloring, however, would still imply that the data
in the cache should be dirty, or flushed after this loop terminates.

Perhaps I have misused the term "flush".  My objective is to make each
cache line dirty, or flush it to main memory.

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

<div><br></div><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote"=
 style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Fo=
r what purpose? =A0There was once a bug which caused this to happen and<br>
it caused Xen to slow to a glacial pace. =A0We got bored of debugging HVM<b=
r>
domains after several hours and the BIOS has still not loaded the<br>
bootloader.<br>
<div></div></blockquote><div><br></div><div>I&#39;m working on an experimen=
t to do with cache-based side channels in Cloud environments. =A0Part of it=
 involves measuring the effect of flushing the cache every time there is a =
VM switch.</div>

<div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex=
;border-left:1px #ccc solid;padding-left:1ex">You don&#39;t check the retur=
n value, so what happens when the allocation<br>
fails? =A0I would say that calling *alloc() is not a sensible thing to be<b=
r>
doing in __context_switch() anyway, as you are sitting doing a long<br>
operation while in a critical section of Xen code.<br></blockquote><div><br=
></div><div>Unfortunately, I can chalk that up to my=A0inexperience=A0with =
C programming. =A0Thanks for pointing that out.</div><div><br></div><div>As=
 for the sensibility of the plan, it is still in rather early stages and no=
t as robust as I would like it. =A0As I get more working I was planning on =
leaving the memory buffer permanently allocated so as not to spend time man=
aging it in a critical section. =A0If you have a suggestion for a more prac=
tical solution I&#39;m all ears.</div>

<div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex=
;border-left:1px #ccc solid;padding-left:1ex">Furthermore, this algorithm h=
as no guarantee to clear the L2 cache. =A0In<br>
fact is almost certainly will not.<br></blockquote><div><br></div><div>This=
 is the code that has worked in all of my prior experiments and has been ra=
tified by others I have worked with. =A0Are you sure it wouldn&#39;t work? =
=A0While, for simplicity&#39;s sake, I have removed portions of the code de=
signed to prevent=A0pre-fetching and perhaps left out something important, =
my understanding of cache-coloring, however, would still imply that the dat=
a in the cache should be dirty, or flushed after this loop terminates.</div=
>

<div><br></div><div>Perhaps I have misused the term &quot;flush&quot;. =A0M=
y objective is to make each cache line dirty, or flush it to main memory.</=
div></div>

--0016e6db7ca663dfe204c8e57efa--


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

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

--===============0173812192847604894==--


From xen-devel-bounces@lists.xen.org Tue Sep 04 19:45:32 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Sep 2012 19: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 1T8z3c-0000HQ-K7; Tue, 04 Sep 2012 19:45:08 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <misiu.godfrey@gmail.com>) id 1T8z3a-0000HL-Tq
	for xen-devel@lists.xen.org; Tue, 04 Sep 2012 19:45:07 +0000
X-Env-Sender: misiu.godfrey@gmail.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1346787900!2753530!1
X-Originating-IP: [74.125.82.51]
X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_20_30,HTML_MESSAGE,
	RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20821 invoked from network); 4 Sep 2012 19:45:00 -0000
Received: from mail-wg0-f51.google.com (HELO mail-wg0-f51.google.com)
	(74.125.82.51)
	by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Sep 2012 19:45:00 -0000
Received: by wgbed3 with SMTP id ed3so4148474wgb.32
	for <xen-devel@lists.xen.org>; Tue, 04 Sep 2012 12:45: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=UfXXQILUfAxcAgPNyS+twGUdPxPxzc71YgMZisUjeDk=;
	b=HAX6ftG0SIydYP7AzlxYLJsNSzwxr1VfauUaBBL0cBpydPfW6W8hAbfGzbH/Zg7uNq
	sjDdGWFeI0vHBOnuGLx+o3E9WsUthg9jOjYpW8rTDbsItl8jRFVk+l9jxdOZslc0SvC1
	X/cERejxhE2gYUf2kUcHfxGufgOLf6h8PkS1SXNsrKTVIVFHVQWQnQeD2xx4D8W6URaa
	l0PCHsQfeoM/UvwllUgGbRsRWCQ1fHNTNu4JcvSItuPjIRO+AhY0RPumuF1oVZK04VRo
	u4C8Ns9z3/IKLJlsT4ICrJgkdJipnO6I9U/A/G5kXITjam7dJVP+6sgS4lIZ9sCmmy20
	rWfw==
MIME-Version: 1.0
Received: by 10.216.208.104 with SMTP id p82mr12269211weo.119.1346787900382;
	Tue, 04 Sep 2012 12:45:00 -0700 (PDT)
Received: by 10.194.13.7 with HTTP; Tue, 4 Sep 2012 12:45:00 -0700 (PDT)
In-Reply-To: <50464954.5030207@citrix.com>
References: <CAMVU=QgzjT1daB5_zfoP2amtbvWX3X5XZKE6Bj1eX-tTDY=xSQ@mail.gmail.com>
	<50464954.5030207@citrix.com>
Date: Tue, 4 Sep 2012 15:45:00 -0400
X-Google-Sender-Auth: Eonsa7QSWZUUoJlyownXlDyGU2k
Message-ID: <CAMVU=QgJG=cNH69-kKdWULzV6n2kRrn=d78n75NKuMM_9VXQ9w@mail.gmail.com>
From: misiu godfrey <godfrey@cs.queensu.ca>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] additional domain.c memory allocation causes "xm
 create" to fail
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0173812192847604894=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============0173812192847604894==
Content-Type: multipart/alternative; boundary=0016e6db7ca663dfe204c8e57efa

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

> For what purpose?  There was once a bug which caused this to happen and
> it caused Xen to slow to a glacial pace.  We got bored of debugging HVM
> domains after several hours and the BIOS has still not loaded the
> bootloader.
>

I'm working on an experiment to do with cache-based side channels in Cloud
environments.  Part of it involves measuring the effect of flushing the
cache every time there is a VM switch.

You don't check the return value, so what happens when the allocation
> fails?  I would say that calling *alloc() is not a sensible thing to be
> doing in __context_switch() anyway, as you are sitting doing a long
> operation while in a critical section of Xen code.
>

Unfortunately, I can chalk that up to my inexperience with C programming.
 Thanks for pointing that out.

As for the sensibility of the plan, it is still in rather early stages and
not as robust as I would like it.  As I get more working I was planning on
leaving the memory buffer permanently allocated so as not to spend time
managing it in a critical section.  If you have a suggestion for a more
practical solution I'm all ears.

Furthermore, this algorithm has no guarantee to clear the L2 cache.  In
> fact is almost certainly will not.
>

This is the code that has worked in all of my prior experiments and has
been ratified by others I have worked with.  Are you sure it wouldn't work?
 While, for simplicity's sake, I have removed portions of the code designed
to prevent pre-fetching and perhaps left out something important, my
understanding of cache-coloring, however, would still imply that the data
in the cache should be dirty, or flushed after this loop terminates.

Perhaps I have misused the term "flush".  My objective is to make each
cache line dirty, or flush it to main memory.

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

<div><br></div><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote"=
 style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Fo=
r what purpose? =A0There was once a bug which caused this to happen and<br>
it caused Xen to slow to a glacial pace. =A0We got bored of debugging HVM<b=
r>
domains after several hours and the BIOS has still not loaded the<br>
bootloader.<br>
<div></div></blockquote><div><br></div><div>I&#39;m working on an experimen=
t to do with cache-based side channels in Cloud environments. =A0Part of it=
 involves measuring the effect of flushing the cache every time there is a =
VM switch.</div>

<div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex=
;border-left:1px #ccc solid;padding-left:1ex">You don&#39;t check the retur=
n value, so what happens when the allocation<br>
fails? =A0I would say that calling *alloc() is not a sensible thing to be<b=
r>
doing in __context_switch() anyway, as you are sitting doing a long<br>
operation while in a critical section of Xen code.<br></blockquote><div><br=
></div><div>Unfortunately, I can chalk that up to my=A0inexperience=A0with =
C programming. =A0Thanks for pointing that out.</div><div><br></div><div>As=
 for the sensibility of the plan, it is still in rather early stages and no=
t as robust as I would like it. =A0As I get more working I was planning on =
leaving the memory buffer permanently allocated so as not to spend time man=
aging it in a critical section. =A0If you have a suggestion for a more prac=
tical solution I&#39;m all ears.</div>

<div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex=
;border-left:1px #ccc solid;padding-left:1ex">Furthermore, this algorithm h=
as no guarantee to clear the L2 cache. =A0In<br>
fact is almost certainly will not.<br></blockquote><div><br></div><div>This=
 is the code that has worked in all of my prior experiments and has been ra=
tified by others I have worked with. =A0Are you sure it wouldn&#39;t work? =
=A0While, for simplicity&#39;s sake, I have removed portions of the code de=
signed to prevent=A0pre-fetching and perhaps left out something important, =
my understanding of cache-coloring, however, would still imply that the dat=
a in the cache should be dirty, or flushed after this loop terminates.</div=
>

<div><br></div><div>Perhaps I have misused the term &quot;flush&quot;. =A0M=
y objective is to make each cache line dirty, or flush it to main memory.</=
div></div>

--0016e6db7ca663dfe204c8e57efa--


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

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

--===============0173812192847604894==--


From xen-devel-bounces@lists.xen.org Tue Sep 04 20:11:58 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Sep 2012 20: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 1T8zT9-0000YK-TD; Tue, 04 Sep 2012 20:11:31 +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 1T8zT8-0000YF-Nx
	for xen-devel@lists.xen.org; Tue, 04 Sep 2012 20:11:31 +0000
Received: from [85.158.139.83:23005] by server-9.bemta-5.messagelabs.com id
	52/C8-20529-17066405; Tue, 04 Sep 2012 20:11:29 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1346789487!24617476!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNzY0OTI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20018 invoked from network); 4 Sep 2012 20:11:29 -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;
	4 Sep 2012 20:11:29 -0000
X-IronPort-AV: E=Sophos;i="4.80,369,1344211200"; 
	d="scan'208,217";a="207067163"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Sep 2012 20:11:27 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Tue, 4 Sep 2012 16:11:26 -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 1T8zT4-00042w-MF;
	Tue, 04 Sep 2012 21:11:26 +0100
Message-ID: <5046606E.9080908@citrix.com>
Date: Tue, 4 Sep 2012 21:11:26 +0100
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:14.0) Gecko/20120714 Thunderbird/14.0
MIME-Version: 1.0
To: misiu godfrey <godfrey@cs.queensu.ca>
References: <CAMVU=QgzjT1daB5_zfoP2amtbvWX3X5XZKE6Bj1eX-tTDY=xSQ@mail.gmail.com>
	<50464954.5030207@citrix.com>
	<CAMVU=QgJG=cNH69-kKdWULzV6n2kRrn=d78n75NKuMM_9VXQ9w@mail.gmail.com>
In-Reply-To: <CAMVU=QgJG=cNH69-kKdWULzV6n2kRrn=d78n75NKuMM_9VXQ9w@mail.gmail.com>
X-Enigmail-Version: 1.4.4
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] additional domain.c memory allocation causes "xm
 create" to fail
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============4479523484154043251=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============4479523484154043251==
Content-Type: multipart/alternative;
	boundary="------------070007080202050205030503"

--------------070007080202050205030503
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit


On 04/09/12 20:45, misiu godfrey wrote:
>
>     For what purpose?  There was once a bug which caused this to
>     happen and
>     it caused Xen to slow to a glacial pace.  We got bored of
>     debugging HVM
>     domains after several hours and the BIOS has still not loaded the
>     bootloader.
>
>
> I'm working on an experiment to do with cache-based side channels in
> Cloud environments.  Part of it involves measuring the effect of
> flushing the cache every time there is a VM switch.

Ok.  My suspicion is that it will be unreasonably slow, although should
not be the glacial pace we saw with the bug (which was flushing the L2
cache on every instruction).

>
>     You don't check the return value, so what happens when the allocation
>     fails?  I would say that calling *alloc() is not a sensible thing
>     to be
>     doing in __context_switch() anyway, as you are sitting doing a long
>     operation while in a critical section of Xen code.
>
>
> Unfortunately, I can chalk that up to my inexperience with C
> programming.  Thanks for pointing that out.
>
> As for the sensibility of the plan, it is still in rather early stages
> and not as robust as I would like it.  As I get more working I was
> planning on leaving the memory buffer permanently allocated so as not
> to spend time managing it in a critical section.  If you have a
> suggestion for a more practical solution I'm all ears.
>
>     Furthermore, this algorithm has no guarantee to clear the L2
>     cache.  In
>     fact is almost certainly will not.
>
>
> This is the code that has worked in all of my prior experiments and
> has been ratified by others I have worked with.  Are you sure it
> wouldn't work?  While, for simplicity's sake, I have removed portions
> of the code designed to prevent pre-fetching and perhaps left out
> something important, my understanding of cache-coloring, however,
> would still imply that the data in the cache should be dirty, or
> flushed after this loop terminates.
>
> Perhaps I have misused the term "flush".  My objective is to make each
> cache line dirty, or flush it to main memory.

"flush" is the correct term.

However, the structure of caches work against you.  With a set
associative cache, you have no control over which of the sets gets used
for your cache line.  So on an N way set associate cache, your worst
case may only dirty 1/N of the actual lines in the cache.

After that, your L1 cache inclusion policy is going to affect how you
dirty your L2 cache, as well as whether you have joined caches or split
instruction and data caches.

Furthermore, on newer processes, multiple cores may share an L2 or L3
cache, and context switches are unlike to occur at exactly the same time
on each core, meaning that a context switch on one core is going to
(attempt to) nuke the L2 cache of the VM which is in mid run on another
core.  Conversely, even executing the loop trying to dirty the cache
will mean that you dont get all of it, and having another core executing
on the same L2 cache means it will pull its data back during your
dirtying loop.

-- 
Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
T: +44 (0)1223 225 900, http://www.citrix.com


--------------070007080202050205030503
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">
    <br>
    <div class="moz-cite-prefix">On 04/09/12 20:45, misiu godfrey wrote:<br>
    </div>
    <blockquote
cite="mid:CAMVU=QgJG=cNH69-kKdWULzV6n2kRrn=d78n75NKuMM_9VXQ9w@mail.gmail.com"
      type="cite">
      <div><br>
      </div>
      <div class="gmail_quote">
        <blockquote class="gmail_quote" style="margin:0 0 0
          .8ex;border-left:1px #ccc solid;padding-left:1ex">For what
          purpose? &nbsp;There was once a bug which caused this to happen and<br>
          it caused Xen to slow to a glacial pace. &nbsp;We got bored of
          debugging HVM<br>
          domains after several hours and the BIOS has still not loaded
          the<br>
          bootloader.<br>
        </blockquote>
        <div><br>
        </div>
        <div>I'm working on an experiment to do with cache-based side
          channels in Cloud environments. &nbsp;Part of it involves measuring
          the effect of flushing the cache every time there is a VM
          switch.</div>
      </div>
    </blockquote>
    <br>
    Ok.&nbsp; My suspicion is that it will be unreasonably slow, although
    should not be the glacial pace we saw with the bug (which was
    flushing the L2 cache on every instruction).<br>
    <br>
    <blockquote
cite="mid:CAMVU=QgJG=cNH69-kKdWULzV6n2kRrn=d78n75NKuMM_9VXQ9w@mail.gmail.com"
      type="cite">
      <div class="gmail_quote">
        <div><br>
        </div>
        <blockquote class="gmail_quote" style="margin:0 0 0
          .8ex;border-left:1px #ccc solid;padding-left:1ex">You don't
          check the return value, so what happens when the allocation<br>
          fails? &nbsp;I would say that calling *alloc() is not a sensible
          thing to be<br>
          doing in __context_switch() anyway, as you are sitting doing a
          long<br>
          operation while in a critical section of Xen code.<br>
        </blockquote>
        <div><br>
        </div>
        <div>Unfortunately, I can chalk that up to my&nbsp;inexperience&nbsp;with
          C programming. &nbsp;Thanks for pointing that out.</div>
        <div><br>
        </div>
        <div>As for the sensibility of the plan, it is still in rather
          early stages and not as robust as I would like it. &nbsp;As I get
          more working I was planning on leaving the memory buffer
          permanently allocated so as not to spend time managing it in a
          critical section. &nbsp;If you have a suggestion for a more
          practical solution I'm all ears.</div>
        <div><br>
        </div>
        <blockquote class="gmail_quote" style="margin:0 0 0
          .8ex;border-left:1px #ccc solid;padding-left:1ex">Furthermore,
          this algorithm has no guarantee to clear the L2 cache. &nbsp;In<br>
          fact is almost certainly will not.<br>
        </blockquote>
        <div><br>
        </div>
        <div>This is the code that has worked in all of my prior
          experiments and has been ratified by others I have worked
          with. &nbsp;Are you sure it wouldn't work? &nbsp;While, for simplicity's
          sake, I have removed portions of the code designed to
          prevent&nbsp;pre-fetching and perhaps left out something important,
          my understanding of cache-coloring, however, would still imply
          that the data in the cache should be dirty, or flushed after
          this loop terminates.</div>
        <div><br>
        </div>
        <div>Perhaps I have misused the term "flush". &nbsp;My objective is
          to make each cache line dirty, or flush it to main memory.</div>
      </div>
    </blockquote>
    <br>
    "flush" is the correct term.<br>
    <br>
    However, the structure of caches work against you.&nbsp; With a set
    associative cache, you have no control over which of the sets gets
    used for your cache line.&nbsp; So on an N way set associate cache, your
    worst case may only dirty 1/N of the actual lines in the cache.<br>
    <br>
    After that, your L1 cache inclusion policy is going to affect how
    you dirty your L2 cache, as well as whether you have joined caches
    or split instruction and data caches.<br>
    <br>
    Furthermore, on newer processes, multiple cores may share an L2 or
    L3 cache, and context switches are unlike to occur at exactly the
    same time on each core, meaning that a context switch on one core is
    going to (attempt to) nuke the L2 cache of the VM which is in mid
    run on another core.&nbsp; Conversely, even executing the loop trying to
    dirty the cache will mean that you dont get all of it, and having
    another core executing on the same L2 cache means it will pull its
    data back during your dirtying loop.<br>
    <br>
    <pre class="moz-signature" cols="72">-- 
Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
T: +44 (0)1223 225 900, <a class="moz-txt-link-freetext" href="http://www.citrix.com">http://www.citrix.com</a></pre>
  </body>
</html>

--------------070007080202050205030503--


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

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

--===============4479523484154043251==--


From xen-devel-bounces@lists.xen.org Tue Sep 04 20:11:58 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Sep 2012 20: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 1T8zT9-0000YK-TD; Tue, 04 Sep 2012 20:11:31 +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 1T8zT8-0000YF-Nx
	for xen-devel@lists.xen.org; Tue, 04 Sep 2012 20:11:31 +0000
Received: from [85.158.139.83:23005] by server-9.bemta-5.messagelabs.com id
	52/C8-20529-17066405; Tue, 04 Sep 2012 20:11:29 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1346789487!24617476!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNzY0OTI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20018 invoked from network); 4 Sep 2012 20:11:29 -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;
	4 Sep 2012 20:11:29 -0000
X-IronPort-AV: E=Sophos;i="4.80,369,1344211200"; 
	d="scan'208,217";a="207067163"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Sep 2012 20:11:27 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Tue, 4 Sep 2012 16:11:26 -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 1T8zT4-00042w-MF;
	Tue, 04 Sep 2012 21:11:26 +0100
Message-ID: <5046606E.9080908@citrix.com>
Date: Tue, 4 Sep 2012 21:11:26 +0100
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:14.0) Gecko/20120714 Thunderbird/14.0
MIME-Version: 1.0
To: misiu godfrey <godfrey@cs.queensu.ca>
References: <CAMVU=QgzjT1daB5_zfoP2amtbvWX3X5XZKE6Bj1eX-tTDY=xSQ@mail.gmail.com>
	<50464954.5030207@citrix.com>
	<CAMVU=QgJG=cNH69-kKdWULzV6n2kRrn=d78n75NKuMM_9VXQ9w@mail.gmail.com>
In-Reply-To: <CAMVU=QgJG=cNH69-kKdWULzV6n2kRrn=d78n75NKuMM_9VXQ9w@mail.gmail.com>
X-Enigmail-Version: 1.4.4
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] additional domain.c memory allocation causes "xm
 create" to fail
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============4479523484154043251=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============4479523484154043251==
Content-Type: multipart/alternative;
	boundary="------------070007080202050205030503"

--------------070007080202050205030503
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit


On 04/09/12 20:45, misiu godfrey wrote:
>
>     For what purpose?  There was once a bug which caused this to
>     happen and
>     it caused Xen to slow to a glacial pace.  We got bored of
>     debugging HVM
>     domains after several hours and the BIOS has still not loaded the
>     bootloader.
>
>
> I'm working on an experiment to do with cache-based side channels in
> Cloud environments.  Part of it involves measuring the effect of
> flushing the cache every time there is a VM switch.

Ok.  My suspicion is that it will be unreasonably slow, although should
not be the glacial pace we saw with the bug (which was flushing the L2
cache on every instruction).

>
>     You don't check the return value, so what happens when the allocation
>     fails?  I would say that calling *alloc() is not a sensible thing
>     to be
>     doing in __context_switch() anyway, as you are sitting doing a long
>     operation while in a critical section of Xen code.
>
>
> Unfortunately, I can chalk that up to my inexperience with C
> programming.  Thanks for pointing that out.
>
> As for the sensibility of the plan, it is still in rather early stages
> and not as robust as I would like it.  As I get more working I was
> planning on leaving the memory buffer permanently allocated so as not
> to spend time managing it in a critical section.  If you have a
> suggestion for a more practical solution I'm all ears.
>
>     Furthermore, this algorithm has no guarantee to clear the L2
>     cache.  In
>     fact is almost certainly will not.
>
>
> This is the code that has worked in all of my prior experiments and
> has been ratified by others I have worked with.  Are you sure it
> wouldn't work?  While, for simplicity's sake, I have removed portions
> of the code designed to prevent pre-fetching and perhaps left out
> something important, my understanding of cache-coloring, however,
> would still imply that the data in the cache should be dirty, or
> flushed after this loop terminates.
>
> Perhaps I have misused the term "flush".  My objective is to make each
> cache line dirty, or flush it to main memory.

"flush" is the correct term.

However, the structure of caches work against you.  With a set
associative cache, you have no control over which of the sets gets used
for your cache line.  So on an N way set associate cache, your worst
case may only dirty 1/N of the actual lines in the cache.

After that, your L1 cache inclusion policy is going to affect how you
dirty your L2 cache, as well as whether you have joined caches or split
instruction and data caches.

Furthermore, on newer processes, multiple cores may share an L2 or L3
cache, and context switches are unlike to occur at exactly the same time
on each core, meaning that a context switch on one core is going to
(attempt to) nuke the L2 cache of the VM which is in mid run on another
core.  Conversely, even executing the loop trying to dirty the cache
will mean that you dont get all of it, and having another core executing
on the same L2 cache means it will pull its data back during your
dirtying loop.

-- 
Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
T: +44 (0)1223 225 900, http://www.citrix.com


--------------070007080202050205030503
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">
    <br>
    <div class="moz-cite-prefix">On 04/09/12 20:45, misiu godfrey wrote:<br>
    </div>
    <blockquote
cite="mid:CAMVU=QgJG=cNH69-kKdWULzV6n2kRrn=d78n75NKuMM_9VXQ9w@mail.gmail.com"
      type="cite">
      <div><br>
      </div>
      <div class="gmail_quote">
        <blockquote class="gmail_quote" style="margin:0 0 0
          .8ex;border-left:1px #ccc solid;padding-left:1ex">For what
          purpose? &nbsp;There was once a bug which caused this to happen and<br>
          it caused Xen to slow to a glacial pace. &nbsp;We got bored of
          debugging HVM<br>
          domains after several hours and the BIOS has still not loaded
          the<br>
          bootloader.<br>
        </blockquote>
        <div><br>
        </div>
        <div>I'm working on an experiment to do with cache-based side
          channels in Cloud environments. &nbsp;Part of it involves measuring
          the effect of flushing the cache every time there is a VM
          switch.</div>
      </div>
    </blockquote>
    <br>
    Ok.&nbsp; My suspicion is that it will be unreasonably slow, although
    should not be the glacial pace we saw with the bug (which was
    flushing the L2 cache on every instruction).<br>
    <br>
    <blockquote
cite="mid:CAMVU=QgJG=cNH69-kKdWULzV6n2kRrn=d78n75NKuMM_9VXQ9w@mail.gmail.com"
      type="cite">
      <div class="gmail_quote">
        <div><br>
        </div>
        <blockquote class="gmail_quote" style="margin:0 0 0
          .8ex;border-left:1px #ccc solid;padding-left:1ex">You don't
          check the return value, so what happens when the allocation<br>
          fails? &nbsp;I would say that calling *alloc() is not a sensible
          thing to be<br>
          doing in __context_switch() anyway, as you are sitting doing a
          long<br>
          operation while in a critical section of Xen code.<br>
        </blockquote>
        <div><br>
        </div>
        <div>Unfortunately, I can chalk that up to my&nbsp;inexperience&nbsp;with
          C programming. &nbsp;Thanks for pointing that out.</div>
        <div><br>
        </div>
        <div>As for the sensibility of the plan, it is still in rather
          early stages and not as robust as I would like it. &nbsp;As I get
          more working I was planning on leaving the memory buffer
          permanently allocated so as not to spend time managing it in a
          critical section. &nbsp;If you have a suggestion for a more
          practical solution I'm all ears.</div>
        <div><br>
        </div>
        <blockquote class="gmail_quote" style="margin:0 0 0
          .8ex;border-left:1px #ccc solid;padding-left:1ex">Furthermore,
          this algorithm has no guarantee to clear the L2 cache. &nbsp;In<br>
          fact is almost certainly will not.<br>
        </blockquote>
        <div><br>
        </div>
        <div>This is the code that has worked in all of my prior
          experiments and has been ratified by others I have worked
          with. &nbsp;Are you sure it wouldn't work? &nbsp;While, for simplicity's
          sake, I have removed portions of the code designed to
          prevent&nbsp;pre-fetching and perhaps left out something important,
          my understanding of cache-coloring, however, would still imply
          that the data in the cache should be dirty, or flushed after
          this loop terminates.</div>
        <div><br>
        </div>
        <div>Perhaps I have misused the term "flush". &nbsp;My objective is
          to make each cache line dirty, or flush it to main memory.</div>
      </div>
    </blockquote>
    <br>
    "flush" is the correct term.<br>
    <br>
    However, the structure of caches work against you.&nbsp; With a set
    associative cache, you have no control over which of the sets gets
    used for your cache line.&nbsp; So on an N way set associate cache, your
    worst case may only dirty 1/N of the actual lines in the cache.<br>
    <br>
    After that, your L1 cache inclusion policy is going to affect how
    you dirty your L2 cache, as well as whether you have joined caches
    or split instruction and data caches.<br>
    <br>
    Furthermore, on newer processes, multiple cores may share an L2 or
    L3 cache, and context switches are unlike to occur at exactly the
    same time on each core, meaning that a context switch on one core is
    going to (attempt to) nuke the L2 cache of the VM which is in mid
    run on another core.&nbsp; Conversely, even executing the loop trying to
    dirty the cache will mean that you dont get all of it, and having
    another core executing on the same L2 cache means it will pull its
    data back during your dirtying loop.<br>
    <br>
    <pre class="moz-signature" cols="72">-- 
Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
T: +44 (0)1223 225 900, <a class="moz-txt-link-freetext" href="http://www.citrix.com">http://www.citrix.com</a></pre>
  </body>
</html>

--------------070007080202050205030503--


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

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

--===============4479523484154043251==--


From xen-devel-bounces@lists.xen.org Tue Sep 04 20:14:20 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Sep 2012 20:14:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T8zVX-0000ds-F7; Tue, 04 Sep 2012 20:13:59 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <linux@eikelenboom.it>) id 1T8zVV-0000dm-No
	for xen-devel@lists.xen.org; Tue, 04 Sep 2012 20:13:57 +0000
Received: from [85.158.138.51:16078] by server-2.bemta-3.messagelabs.com id
	B5/E6-04862-40166405; Tue, 04 Sep 2012 20:13:56 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-5.tower-174.messagelabs.com!1346789636!28711492!1
X-Originating-IP: [188.40.164.121]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29168 invoked from network); 4 Sep 2012 20:13:56 -0000
Received: from static.121.164.40.188.clients.your-server.de (HELO
	smtp.eikelenboom.it) (188.40.164.121)
	by server-5.tower-174.messagelabs.com with AES256-SHA encrypted SMTP;
	4 Sep 2012 20:13:56 -0000
Received: from 128-64-ftth.onsneteindhoven.nl ([88.159.64.128]:58190
	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 1T8zSR-0000lu-1q; Tue, 04 Sep 2012 22:10:47 +0200
Date: Tue, 4 Sep 2012 22:13:53 +0200
From: Sander Eikelenboom <linux@eikelenboom.it>
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <1905408737.20120904221353@eikelenboom.it>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
In-Reply-To: <20120904175841.GA10379@phenom.dumpdata.com>
References: <1136369816.20120904183757@eikelenboom.it>
	<20120904163903.GI23361@phenom.dumpdata.com>
	<8328705.20120904200241@eikelenboom.it>
	<20120904175841.GA10379@phenom.dumpdata.com>
MIME-Version: 1.0
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] dom0 linux 3.6.0-rc4,
	crash due to ballooning althoug dom0_mem=X, max:X 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


Tuesday, September 4, 2012, 7:58:41 PM, you wrote:

> On Tue, Sep 04, 2012 at 08:02:41PM +0200, Sander Eikelenboom wrote:
>> 
>> Tuesday, September 4, 2012, 6:39:03 PM, you wrote:
>> 
>> > On Tue, Sep 04, 2012 at 06:37:57PM +0200, Sander Eikelenboom wrote:
>> >> Hi Konrad,
>> >> 
>> >> This seems to happen only on a intel machine i'm trying to setup as a development machine (haven't seen it on my amd).
>> >> It boots fine, i have dom0_mem=1024M,max:1024M set, the machine has 2G of mem.
>> >> 
>> >> Dom0 and guest kernel are 3.6.0-rc4 with config:
>> >> [*] Xen memory balloon driver
>> >> [*]   Scrub pages before returning them to system
>> 
>> > Can you also try this patch out and provide the full log (bootup and such). Thanks!
>> 
>> After applying this patch and due to the removal of the BUG_ON the domU boots and is reachable by SSH.
>> Serial log attached.

> Wow. That is a lot of .. And if you use Xen 4.1 it works fine?

Ok 3.5.3 crashes as well .. will see what xen 4.1.3 does with both kernels on this machine ...


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

From xen-devel-bounces@lists.xen.org Tue Sep 04 20:14:20 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Sep 2012 20:14:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T8zVX-0000ds-F7; Tue, 04 Sep 2012 20:13:59 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <linux@eikelenboom.it>) id 1T8zVV-0000dm-No
	for xen-devel@lists.xen.org; Tue, 04 Sep 2012 20:13:57 +0000
Received: from [85.158.138.51:16078] by server-2.bemta-3.messagelabs.com id
	B5/E6-04862-40166405; Tue, 04 Sep 2012 20:13:56 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-5.tower-174.messagelabs.com!1346789636!28711492!1
X-Originating-IP: [188.40.164.121]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29168 invoked from network); 4 Sep 2012 20:13:56 -0000
Received: from static.121.164.40.188.clients.your-server.de (HELO
	smtp.eikelenboom.it) (188.40.164.121)
	by server-5.tower-174.messagelabs.com with AES256-SHA encrypted SMTP;
	4 Sep 2012 20:13:56 -0000
Received: from 128-64-ftth.onsneteindhoven.nl ([88.159.64.128]:58190
	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 1T8zSR-0000lu-1q; Tue, 04 Sep 2012 22:10:47 +0200
Date: Tue, 4 Sep 2012 22:13:53 +0200
From: Sander Eikelenboom <linux@eikelenboom.it>
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <1905408737.20120904221353@eikelenboom.it>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
In-Reply-To: <20120904175841.GA10379@phenom.dumpdata.com>
References: <1136369816.20120904183757@eikelenboom.it>
	<20120904163903.GI23361@phenom.dumpdata.com>
	<8328705.20120904200241@eikelenboom.it>
	<20120904175841.GA10379@phenom.dumpdata.com>
MIME-Version: 1.0
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] dom0 linux 3.6.0-rc4,
	crash due to ballooning althoug dom0_mem=X, max:X 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


Tuesday, September 4, 2012, 7:58:41 PM, you wrote:

> On Tue, Sep 04, 2012 at 08:02:41PM +0200, Sander Eikelenboom wrote:
>> 
>> Tuesday, September 4, 2012, 6:39:03 PM, you wrote:
>> 
>> > On Tue, Sep 04, 2012 at 06:37:57PM +0200, Sander Eikelenboom wrote:
>> >> Hi Konrad,
>> >> 
>> >> This seems to happen only on a intel machine i'm trying to setup as a development machine (haven't seen it on my amd).
>> >> It boots fine, i have dom0_mem=1024M,max:1024M set, the machine has 2G of mem.
>> >> 
>> >> Dom0 and guest kernel are 3.6.0-rc4 with config:
>> >> [*] Xen memory balloon driver
>> >> [*]   Scrub pages before returning them to system
>> 
>> > Can you also try this patch out and provide the full log (bootup and such). Thanks!
>> 
>> After applying this patch and due to the removal of the BUG_ON the domU boots and is reachable by SSH.
>> Serial log attached.

> Wow. That is a lot of .. And if you use Xen 4.1 it works fine?

Ok 3.5.3 crashes as well .. will see what xen 4.1.3 does with both kernels on this machine ...


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

From xen-devel-bounces@lists.xen.org Tue Sep 04 20:28:11 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Sep 2012 20:28: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 1T8zix-0000t0-3L; Tue, 04 Sep 2012 20:27: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 1T8ziv-0000sv-3C
	for xen-devel@lists.xensource.com; Tue, 04 Sep 2012 20:27:49 +0000
Received: from [85.158.143.35:58920] by server-1.bemta-4.messagelabs.com id
	A9/3D-12504-44466405; Tue, 04 Sep 2012 20:27:48 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1346790466!12214865!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDczNjI0OQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10183 invoked from network); 4 Sep 2012 20:27:47 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-7.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 4 Sep 2012 20:27:47 -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 q84KRhNl021791
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 4 Sep 2012 20:27:44 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
	q84KRgBr015363
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 4 Sep 2012 20:27:43 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
	q84KRggr029725; Tue, 4 Sep 2012 15:27:42 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 04 Sep 2012 13:27:42 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 935B5402BA; Tue,  4 Sep 2012 16:17:15 -0400 (EDT)
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: linux-kernel@vger.kernel.org
Date: Tue,  4 Sep 2012 16:17:14 -0400
Message-Id: <1346789834-30618-1-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.7.7.6
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: xen-devel@lists.xensource.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: [Xen-devel] [PATCH] xen/p2m: Fix one by off error in checking the
	P2M tree directory.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 would the full P2M top directory from 0->MAX_DOMAIN_PAGES (inclusive).

Which meant that if the kernel was compiled with MAX_DOMAIN_PAGES=512
we would try to use the 512th entry. Fortunately for us the p2m_top_index
has a check for this:

 BUG_ON(pfn >= MAX_P2M_PFN);

which we hit and saw this:

(XEN) domain_crash_sync called from entry.S
(XEN) Domain 0 (vcpu#0) crashed on cpu#0:
(XEN) ----[ Xen-4.1.2-OVM  x86_64  debug=n  Tainted:    C ]----
(XEN) CPU:    0
(XEN) RIP:    e033:[<ffffffff819cadeb>]
(XEN) RFLAGS: 0000000000000212   EM: 1   CONTEXT: pv guest
(XEN) rax: ffffffff81db5000   rbx: ffffffff81db4000   rcx: 0000000000000000
(XEN) rdx: 0000000000480211   rsi: 0000000000000000   rdi: ffffffff81db4000
(XEN) rbp: ffffffff81793db8   rsp: ffffffff81793d38   r8:  0000000008000000
(XEN) r9:  4000000000000000   r10: 0000000000000000   r11: ffffffff81db7000
(XEN) r12: 0000000000000ff8   r13: ffffffff81df1ff8   r14: ffffffff81db6000
(XEN) r15: 0000000000000ff8   cr0: 000000008005003b   cr4: 00000000000026f0
(XEN) cr3: 0000000661795000   cr2: 0000000000000000

Fixes-Oracle-Bug: 14570662
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 arch/x86/xen/p2m.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/arch/x86/xen/p2m.c b/arch/x86/xen/p2m.c
index 0bfaf5b..af11f00 100644
--- a/arch/x86/xen/p2m.c
+++ b/arch/x86/xen/p2m.c
@@ -695,7 +695,7 @@ bool __init early_can_reuse_p2m_middle(unsigned long set_pfn, unsigned long set_
 	if (p2m_index(set_pfn))
 		return false;
 
-	for (pfn = 0; pfn <= MAX_DOMAIN_PAGES; pfn += P2M_PER_PAGE) {
+	for (pfn = 0; pfn < MAX_DOMAIN_PAGES; pfn += P2M_PER_PAGE) {
 		topidx = p2m_top_index(pfn);
 
 		if (!p2m_top[topidx])
-- 
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 Sep 04 20:28:11 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Sep 2012 20:28: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 1T8zix-0000t0-3L; Tue, 04 Sep 2012 20:27: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 1T8ziv-0000sv-3C
	for xen-devel@lists.xensource.com; Tue, 04 Sep 2012 20:27:49 +0000
Received: from [85.158.143.35:58920] by server-1.bemta-4.messagelabs.com id
	A9/3D-12504-44466405; Tue, 04 Sep 2012 20:27:48 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1346790466!12214865!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDczNjI0OQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10183 invoked from network); 4 Sep 2012 20:27:47 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-7.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 4 Sep 2012 20:27:47 -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 q84KRhNl021791
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 4 Sep 2012 20:27:44 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
	q84KRgBr015363
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 4 Sep 2012 20:27:43 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
	q84KRggr029725; Tue, 4 Sep 2012 15:27:42 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 04 Sep 2012 13:27:42 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 935B5402BA; Tue,  4 Sep 2012 16:17:15 -0400 (EDT)
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: linux-kernel@vger.kernel.org
Date: Tue,  4 Sep 2012 16:17:14 -0400
Message-Id: <1346789834-30618-1-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.7.7.6
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: xen-devel@lists.xensource.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: [Xen-devel] [PATCH] xen/p2m: Fix one by off error in checking the
	P2M tree directory.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 would the full P2M top directory from 0->MAX_DOMAIN_PAGES (inclusive).

Which meant that if the kernel was compiled with MAX_DOMAIN_PAGES=512
we would try to use the 512th entry. Fortunately for us the p2m_top_index
has a check for this:

 BUG_ON(pfn >= MAX_P2M_PFN);

which we hit and saw this:

(XEN) domain_crash_sync called from entry.S
(XEN) Domain 0 (vcpu#0) crashed on cpu#0:
(XEN) ----[ Xen-4.1.2-OVM  x86_64  debug=n  Tainted:    C ]----
(XEN) CPU:    0
(XEN) RIP:    e033:[<ffffffff819cadeb>]
(XEN) RFLAGS: 0000000000000212   EM: 1   CONTEXT: pv guest
(XEN) rax: ffffffff81db5000   rbx: ffffffff81db4000   rcx: 0000000000000000
(XEN) rdx: 0000000000480211   rsi: 0000000000000000   rdi: ffffffff81db4000
(XEN) rbp: ffffffff81793db8   rsp: ffffffff81793d38   r8:  0000000008000000
(XEN) r9:  4000000000000000   r10: 0000000000000000   r11: ffffffff81db7000
(XEN) r12: 0000000000000ff8   r13: ffffffff81df1ff8   r14: ffffffff81db6000
(XEN) r15: 0000000000000ff8   cr0: 000000008005003b   cr4: 00000000000026f0
(XEN) cr3: 0000000661795000   cr2: 0000000000000000

Fixes-Oracle-Bug: 14570662
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 arch/x86/xen/p2m.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/arch/x86/xen/p2m.c b/arch/x86/xen/p2m.c
index 0bfaf5b..af11f00 100644
--- a/arch/x86/xen/p2m.c
+++ b/arch/x86/xen/p2m.c
@@ -695,7 +695,7 @@ bool __init early_can_reuse_p2m_middle(unsigned long set_pfn, unsigned long set_
 	if (p2m_index(set_pfn))
 		return false;
 
-	for (pfn = 0; pfn <= MAX_DOMAIN_PAGES; pfn += P2M_PER_PAGE) {
+	for (pfn = 0; pfn < MAX_DOMAIN_PAGES; pfn += P2M_PER_PAGE) {
 		topidx = p2m_top_index(pfn);
 
 		if (!p2m_top[topidx])
-- 
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 Sep 04 20:35:37 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Sep 2012 20:35:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T8zqC-00013w-0f; Tue, 04 Sep 2012 20:35:20 +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 1T8zqA-00013r-Ll
	for xen-devel@lists.xen.org; Tue, 04 Sep 2012 20:35:18 +0000
Received: from [85.158.143.99:43395] by server-2.bemta-4.messagelabs.com id
	D4/83-21239-60666405; Tue, 04 Sep 2012 20:35:18 +0000
X-Env-Sender: dan.magenheimer@oracle.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1346790915!22143352!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDczNjI0OQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18682 invoked from network); 4 Sep 2012 20:35:17 -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; 4 Sep 2012 20:35:17 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q84KY8gl028059
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 4 Sep 2012 20:34:09 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
	q84KY7ju026176
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 4 Sep 2012 20:34:07 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
	q84KY6rY001633; Tue, 4 Sep 2012 15:34:06 -0500
MIME-Version: 1.0
Message-ID: <4ade5954-2365-4c33-b667-4dd9410fb37d@default>
Date: Tue, 4 Sep 2012 13:33:25 -0700 (PDT)
From: Dan Magenheimer <dan.magenheimer@oracle.com>
To: M A Young <m.a.young@durham.ac.uk>
References: <e927526f-b096-43da-a3b1-57d84daea825@default>
	<20120831211325.GB20594@localhost.localdomain>
	<da3e1ce8-0fcf-4c6f-88f9-cea859fe9ec1@default>
	<20120831222157.GA21232@localhost.localdomain>
	<6dc36215-ef4a-4677-b0d5-7913a5ebb5f3@default>
	<alpine.DEB.2.00.1209011213370.6523@procyon.dur.ac.uk>
In-Reply-To: <alpine.DEB.2.00.1209011213370.6523@procyon.dur.ac.uk>
X-Priority: 3
X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.7  (607090) [OL
	12.0.6661.5003 (x86)]
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: Konrad Wilk <konrad.wilk@oracle.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] xend/xm on 4.1/4.2 on Fedora (FC17)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> From: M A Young [mailto:m.a.young@durham.ac.uk]
> Subject: Re: [Xen-devel] xend/xm on 4.1/4.2 on Fedora (FC17)
> =

> On Fri, 31 Aug 2012, Dan Magenheimer wrote:
> =

> >> From: Konrad Rzeszutek Wilk
> >> Sent: Friday, August 31, 2012 4:22 PM
> >> To: Dan Magenheimer
> >> Cc: Pasi K=E4rkk=E4inen; xen-devel@lists.xen.org
> >> Subject: Re: xend/xm on 4.1/4.2 on Fedora (FC17)
> >>
> >> On Fri, Aug 31, 2012 at 02:16:18PM -0700, Dan Magenheimer wrote:
> >>>> From: Konrad Rzeszutek Wilk
> >>>> Subject: Re: xend/xm on 4.1/4.2 on Fedora (FC17)
> >>>>
> >>>> On Fri, Aug 31, 2012 at 02:08:49PM -0700, Dan Magenheimer wrote:
> >>>>> Is there a how-to for starting/running xm/xend on Fedora (FC17)?
> >>>>> Is it different for Xen 4.1 and 4.2?
> >>>>>
> >>>>> I did find this:
> >>>>> http://wiki.xen.org/wiki/Xen_Common_Problems#Starting_xend_fails.3F
> >>>>> but it doesn't seem to help.  And this:
> >>>>> http://wiki.xen.org/wiki/Fedora_Host_Installation
> >>>>> only addresses xl.
> >>>>>
> >>>>> I expect I need to do something manually to start xencommons or
> >>>>> something like that but obvious things don't seem to work,
> >>>>
> >>>> How are you running this? When you boot up does it work? Or is this =
not
> >>>> working after your restart xend couple of times?
> >>>>
> >>>>> and I'm not a FC17 expert at all.
> >>>>
> >>>> service xend start
> >>>>
> >>>> But you also need to enable it if it wasn't enabled using systemd.
> >>>> The syntax was something like (look at
> >>>> http://fedoraproject.org/wiki/SysVinit_to_Systemd_Cheatsheet)
> >>>>
> >>>> systemctl enable xend.service
> >>>>
> >>>> (thought it might not be called xend but something else).
> >>>
> >>> That was one of the obvious things I tried, but it fails to start :-/
> >>
> >> Are you running in graphical mode? If so see if there are some weird
> >> SELinux warnings.
> >
> > SELinux is disabled.  But yes, I am booting in graphical mode.
> >
> > Hmmm... manually running "/usr/sbin/xend start" seems to work though.
> > I guess that is all I need as I can start it in /etc/rc.d/rc.local.
> =

> Strange, it is usually selinux that breaks xend. If you run
> systemctl status xend.service
> it should give you some indication of what went wrong.
> =

> Note that
> systemctl enable xend.service
> enables xend on boot (it is off by default in the package because xend is
> being deprecated), to start it by hand you need
> systemctl start xend.service

Hi Michael --

Thanks much for your response!

"systemctl start xend.service" failed, "systemctl status xend.service"
revealed only very cryptic information... that's why I asked for
help, assuming that others might know if there was some missing magic.

In any case, since manual "/usr/sbin/xend start" works, I will
try to reproduce the systemctl issue sometime on a future install.

Thanks,
Dan

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

From xen-devel-bounces@lists.xen.org Tue Sep 04 20:35:37 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Sep 2012 20:35:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T8zqC-00013w-0f; Tue, 04 Sep 2012 20:35:20 +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 1T8zqA-00013r-Ll
	for xen-devel@lists.xen.org; Tue, 04 Sep 2012 20:35:18 +0000
Received: from [85.158.143.99:43395] by server-2.bemta-4.messagelabs.com id
	D4/83-21239-60666405; Tue, 04 Sep 2012 20:35:18 +0000
X-Env-Sender: dan.magenheimer@oracle.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1346790915!22143352!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDczNjI0OQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18682 invoked from network); 4 Sep 2012 20:35:17 -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; 4 Sep 2012 20:35:17 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q84KY8gl028059
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 4 Sep 2012 20:34:09 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
	q84KY7ju026176
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 4 Sep 2012 20:34:07 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
	q84KY6rY001633; Tue, 4 Sep 2012 15:34:06 -0500
MIME-Version: 1.0
Message-ID: <4ade5954-2365-4c33-b667-4dd9410fb37d@default>
Date: Tue, 4 Sep 2012 13:33:25 -0700 (PDT)
From: Dan Magenheimer <dan.magenheimer@oracle.com>
To: M A Young <m.a.young@durham.ac.uk>
References: <e927526f-b096-43da-a3b1-57d84daea825@default>
	<20120831211325.GB20594@localhost.localdomain>
	<da3e1ce8-0fcf-4c6f-88f9-cea859fe9ec1@default>
	<20120831222157.GA21232@localhost.localdomain>
	<6dc36215-ef4a-4677-b0d5-7913a5ebb5f3@default>
	<alpine.DEB.2.00.1209011213370.6523@procyon.dur.ac.uk>
In-Reply-To: <alpine.DEB.2.00.1209011213370.6523@procyon.dur.ac.uk>
X-Priority: 3
X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.7  (607090) [OL
	12.0.6661.5003 (x86)]
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: Konrad Wilk <konrad.wilk@oracle.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] xend/xm on 4.1/4.2 on Fedora (FC17)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> From: M A Young [mailto:m.a.young@durham.ac.uk]
> Subject: Re: [Xen-devel] xend/xm on 4.1/4.2 on Fedora (FC17)
> =

> On Fri, 31 Aug 2012, Dan Magenheimer wrote:
> =

> >> From: Konrad Rzeszutek Wilk
> >> Sent: Friday, August 31, 2012 4:22 PM
> >> To: Dan Magenheimer
> >> Cc: Pasi K=E4rkk=E4inen; xen-devel@lists.xen.org
> >> Subject: Re: xend/xm on 4.1/4.2 on Fedora (FC17)
> >>
> >> On Fri, Aug 31, 2012 at 02:16:18PM -0700, Dan Magenheimer wrote:
> >>>> From: Konrad Rzeszutek Wilk
> >>>> Subject: Re: xend/xm on 4.1/4.2 on Fedora (FC17)
> >>>>
> >>>> On Fri, Aug 31, 2012 at 02:08:49PM -0700, Dan Magenheimer wrote:
> >>>>> Is there a how-to for starting/running xm/xend on Fedora (FC17)?
> >>>>> Is it different for Xen 4.1 and 4.2?
> >>>>>
> >>>>> I did find this:
> >>>>> http://wiki.xen.org/wiki/Xen_Common_Problems#Starting_xend_fails.3F
> >>>>> but it doesn't seem to help.  And this:
> >>>>> http://wiki.xen.org/wiki/Fedora_Host_Installation
> >>>>> only addresses xl.
> >>>>>
> >>>>> I expect I need to do something manually to start xencommons or
> >>>>> something like that but obvious things don't seem to work,
> >>>>
> >>>> How are you running this? When you boot up does it work? Or is this =
not
> >>>> working after your restart xend couple of times?
> >>>>
> >>>>> and I'm not a FC17 expert at all.
> >>>>
> >>>> service xend start
> >>>>
> >>>> But you also need to enable it if it wasn't enabled using systemd.
> >>>> The syntax was something like (look at
> >>>> http://fedoraproject.org/wiki/SysVinit_to_Systemd_Cheatsheet)
> >>>>
> >>>> systemctl enable xend.service
> >>>>
> >>>> (thought it might not be called xend but something else).
> >>>
> >>> That was one of the obvious things I tried, but it fails to start :-/
> >>
> >> Are you running in graphical mode? If so see if there are some weird
> >> SELinux warnings.
> >
> > SELinux is disabled.  But yes, I am booting in graphical mode.
> >
> > Hmmm... manually running "/usr/sbin/xend start" seems to work though.
> > I guess that is all I need as I can start it in /etc/rc.d/rc.local.
> =

> Strange, it is usually selinux that breaks xend. If you run
> systemctl status xend.service
> it should give you some indication of what went wrong.
> =

> Note that
> systemctl enable xend.service
> enables xend on boot (it is off by default in the package because xend is
> being deprecated), to start it by hand you need
> systemctl start xend.service

Hi Michael --

Thanks much for your response!

"systemctl start xend.service" failed, "systemctl status xend.service"
revealed only very cryptic information... that's why I asked for
help, assuming that others might know if there was some missing magic.

In any case, since manual "/usr/sbin/xend start" works, I will
try to reproduce the systemctl issue sometime on a future install.

Thanks,
Dan

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

From xen-devel-bounces@lists.xen.org Tue Sep 04 20:46:52 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Sep 2012 20:46:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9013-0001Dg-7b; Tue, 04 Sep 2012 20:46:33 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <robert.phillips@citrix.com>) id 1T8ziY-0000sa-DJ
	for xen-devel@lists.xen.org; Tue, 04 Sep 2012 20:27:26 +0000
Received: from [85.158.139.83:15797] by server-4.bemta-5.messagelabs.com id
	0A/C6-23042-D2466405; Tue, 04 Sep 2012 20:27:25 +0000
X-Env-Sender: robert.phillips@citrix.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1346790443!17292686!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNzY0OTI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1678 invoked from network); 4 Sep 2012 20:27:24 -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;
	4 Sep 2012 20:27:24 -0000
X-IronPort-AV: E=Sophos;i="4.80,369,1344211200"; d="scan'208";a="207069554"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Sep 2012 20:27:22 +0000
Received: from FTLPMAILBOX02.citrite.net ([10.13.98.210]) by
	FTLPMAILMX01.citrite.net ([10.13.107.65]) with mapi;
	Tue, 4 Sep 2012 16:27:21 -0400
From: Robert Phillips <robert.phillips@citrix.com>
To: Sander Eikelenboom <linux@eikelenboom.it>, Ben Guthro <ben@guthro.net>
Date: Tue, 4 Sep 2012 16:27:20 -0400
Thread-Topic: [Xen-devel] dom0 linux 3.6.0-rc4, crash due to ballooning
	althoug dom0_mem=X, max:X set
Thread-Index: Ac2K1GHx3o4s+CLyTruDezLHXF+CzQABD0vw
Message-ID: <048EAD622912254A9DEA24C1734613C18C864C3C5D@FTLPMAILBOX02.citrite.net>
References: <1136369816.20120904183757@eikelenboom.it>
	<20120904163347.GH23361@phenom.dumpdata.com>
	<143844933.20120904191941@eikelenboom.it>
	<CAOvdn6U_yHgtZwv9MWazdLbd3NLq3pwGXnZY5sL2UVBhV_FUoQ@mail.gmail.com>
	<1813712325.20120904213459@eikelenboom.it>
In-Reply-To: <1813712325.20120904213459@eikelenboom.it>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
X-Mailman-Approved-At: Tue, 04 Sep 2012 20:46:31 +0000
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] dom0 linux 3.6.0-rc4,
 crash due to ballooning althoug dom0_mem=X, max:X 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

Ben,

You have asked me to provide the rationale behind the gnttab_old_mfn patch, which you emailed to Sander earlier today. 
Here are my findings.

I found that xen_blkbk_map() in drivers/block/xen-blkback/blkback.c has changed from our previous version.  It now calls gnttab_map_refs() in drivers/xen/grant-table.c.

That function first calls HYPERVISOR_grant_table_op(GNTTABOP_map_grant_ref, ... ) and then calls m2p_add_override() in p2m.c
which is where I made my change.

The unpatched code was saving the pfn's old mfn in kmap_op->dev_bus_addr.  

kmap_op is of type struct gnttab_map_grant_ref.  That data type is used to record grant table mappings so later they can be unmapped correctly.

The problem with saving the old mfn in kmap_op->dev_bus_addr is that it is later overwritten by __gnttab_map_grant_ref() in xen/common/grant_table.c

Since the storage holding the old mfn got overwritten, the unmapping was being done incorrectly.  The balloon code detected that and bugged at drivers/xen/balloon.c:359

My patch simply adds another member called old_mfn to struct gnttab_map_grant_ref rather than trying to overload dev_bus_addr.

I don't know if Sander's bug is the same or related.  The BUG_ON at drivers/xen/balloon.c:359 is quite general.  It simply asserts that we are not trying to re-map a valid mapping.

-- Robert Phillips


-----Original Message-----
From: Sander Eikelenboom [mailto:linux@eikelenboom.it] 
Sent: Tuesday, September 04, 2012 3:35 PM
To: Ben Guthro
Cc: Konrad Rzeszutek Wilk; xen-devel@lists.xen.org; Robert Phillips
Subject: Re: [Xen-devel] dom0 linux 3.6.0-rc4, crash due to ballooning althoug dom0_mem=X, max:X set


Tuesday, September 4, 2012, 8:07:11 PM, you wrote:

> We ran into the same issue, in newer kernels - but had not yet
> submitted this fix.

> One of the developers here came up with a fix (attached, and CC'ed
> here) that fixes an issue where the p2m code reuses a structure member
> where it shouldn't.
> The patch adds a new "old_mfn"  member to the gnttab_map_grant_ref
> structure, instead of re-using  dev_bus_addr.


> If this also works for you, I can re-submit it with a Signed-off-by
> line, if you prefer, Konrad.

Hi Ben,

This patch doesn't work for me:

When starting the PV-guest i get:

(XEN) [2012-09-04 20:31:37] grant_table.c:499:d0 Bad flags in grant map op (68b69070).
(XEN) [2012-09-04 20:31:37] grant_table.c:499:d0 Bad flags in grant map op (0).
(XEN) [2012-09-04 20:31:37] grant_table.c:499:d0 Bad flags in grant map op (0).


and from the dom0 kernel:

[  374.425727] BUG: unable to handle kernel paging request at ffff8800fffd9078
[  374.428901] IP: [<ffffffff81336e4e>] gnttab_map_refs+0x14e/0x270
[  374.428901] PGD 1e0c067 PUD 0
[  374.428901] Oops: 0000 [#1] PREEMPT SMP
[  374.428901] Modules linked in:
[  374.428901] CPU 0
[  374.428901] Pid: 4308, comm: qemu-system-i38 Not tainted 3.6.0-rc4-20120830+ #70 System manufacturer System Product Name/P5Q-EM DO
[  374.428901] RIP: e030:[<ffffffff81336e4e>]  [<ffffffff81336e4e>] gnttab_map_refs+0x14e/0x270
[  374.428901] RSP: e02b:ffff88002f185ca8  EFLAGS: 00010206
[  374.428901] RAX: ffff880000000000 RBX: ffff88001471cf00 RCX: 00000000fffd9078
[  374.428901] RDX: 0000000000000050 RSI: 40000000000fffd9 RDI: 00003ffffffff000
[  374.428901] RBP: ffff88002f185d08 R08: 0000000000000078 R09: 0000000000000000
[  374.428901] R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000004
[  374.428901] R13: ffff88001471c480 R14: 0000000000000002 R15: 0000000000000002
[  374.428901] FS:  00007f6def9f2740(0000) GS:ffff88003fc00000(0000) knlGS:0000000000000000
[  374.428901] CS:  e033 DS: 0000 ES: 0000 CR0: 000000008005003b
[  374.428901] CR2: ffff8800fffd9078 CR3: 000000002d30e000 CR4: 0000000000042660
[  374.428901] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[  374.428901] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[  374.428901] Process qemu-system-i38 (pid: 4308, threadinfo ffff88002f184000, task ffff8800376f1040)
[  374.428901] Stack:
[  374.428901]  ffffffffffffffff 0000000000000050 00000000fffd9078 00000000000fffd9
[  374.428901]  0000000001000000 ffff8800382135a0 ffff88002f185d08 ffff880038211960
[  374.428901]  ffff88002f11d2c0 0000000000000004 0000000000000003 0000000000000001
[  374.428901] Call Trace:
[  374.428901]  [<ffffffff8134212e>] gntdev_mmap+0x20e/0x520
[  374.428901]  [<ffffffff8111c502>] ? mmap_region+0x312/0x5a0
[  374.428901]  [<ffffffff810ae0a0>] ? lockdep_trace_alloc+0xa0/0x130
[  374.428901]  [<ffffffff8111c5be>] mmap_region+0x3ce/0x5a0
[  374.428901]  [<ffffffff8111c9e0>] do_mmap_pgoff+0x250/0x350
[  374.428901]  [<ffffffff81109e88>] vm_mmap_pgoff+0x68/0x90
[  374.428901]  [<ffffffff8111a5b2>] sys_mmap_pgoff+0x152/0x170
[  374.428901]  [<ffffffff812b29be>] ? trace_hardirqs_on_thunk+0x3a/0x3f
[  374.428901]  [<ffffffff81011f29>] sys_mmap+0x29/0x30
[  374.428901]  [<ffffffff8184b939>] system_call_fastpath+0x16/0x1b
[  374.428901] Code: 0f 84 e7 00 00 00 48 89 f1 48 c1 e1 0c 41 81 e0 ff 0f 00 00 48 b8 00 00 00 00 00 88 ff ff 48 bf 00 f0 ff ff ff 3f 00 00 4c 01 c1 <48> 23 3c 01 48 c1 ef 0c 49 8d 54 15 00 4d 85 ed b8 00 00 00 00
[  374.428901] RIP  [<ffffffff81336e4e>] gnttab_map_refs+0x14e/0x270
[  374.428901]  RSP <ffff88002f185ca8>
[  374.428901] CR2: ffff8800fffd9078
[  374.428901] ---[ end trace 0e0a5a49f6503c0a ]---



> Ben


> On Tue, Sep 4, 2012 at 1:19 PM, Sander Eikelenboom <linux@eikelenboom.it> wrote:
>>
>> Tuesday, September 4, 2012, 6:33:47 PM, you wrote:
>>
>>> On Tue, Sep 04, 2012 at 06:37:57PM +0200, Sander Eikelenboom wrote:
>>>> Hi Konrad,
>>>>
>>>> This seems to happen only on a intel machine i'm trying to setup as a development machine (haven't seen it on my amd).
>>>> It boots fine, i have dom0_mem=1024M,max:1024M set, the machine has 2G of mem.
>>
>>> Is this only with Xen 4.2? As, does Xen 4.1 work?
>>>>
>>>> Dom0 and guest kernel are 3.6.0-rc4 with config:
>>
>>> If you back out:
>>
>>> f393387d160211f60398d58463a7e65
>>> Author: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
>>> Date:   Fri Aug 17 16:43:28 2012 -0400
>>
>>>     xen/setup: Fix one-off error when adding for-balloon PFNs to the P2M.
>>
>>> Do you see this bug? (Either with Xen 4.1 or Xen 4.2)?
>>
>> With c96aae1f7f393387d160211f60398d58463a7e65 reverted i still see this bug (with Xen 4.2).
>>
>> Will use the debug patch you mailed and send back the results ...
>>
>>
>>>> [*] Xen memory balloon driver
>>>> [*]   Scrub pages before returning them to system
>>>>
>>>> From http://wiki.xen.org/wiki/Do%EF%BB%BFm0_Memory_%E2%80%94_Where_It_Has_Not_Gone , I thought this should be okay
>>>>
>>>> But when trying to start a PV guest with 512MB mem, the machine (dom0) crashes with the stacktrace below (complete serial-log.txt attached).
>>>>
>>>> From the:
>>>> "mapping kernel into physical memory
>>>> about to get started..."
>>>>
>>>> I would almost say it's trying to reload dom0 ?
>>>>
>>>>
>>>> [  897.161119] device vif1.0 entered promiscuous mode
>>>> mapping kernel into physical memory
>>>> about to get started...
>>>> [  897.696619] xen_bridge: port 1(vif1.0) entered forwarding state
>>>> [  897.716219] xen_bridge: port 1(vif1.0) entered forwarding state
>>>> [  898.129465] ------------[ cut here ]------------
>>>> [  898.132209] kernel BUG at drivers/xen/balloon.c:359!
>>>> [  898.132209] invalid opcode: 0000 [#1] PREEMPT SMP
>>
>>
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xen.org
>> http://lists.xen.org/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 Sep 04 20:46:52 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Sep 2012 20:46:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9013-0001Dg-7b; Tue, 04 Sep 2012 20:46:33 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <robert.phillips@citrix.com>) id 1T8ziY-0000sa-DJ
	for xen-devel@lists.xen.org; Tue, 04 Sep 2012 20:27:26 +0000
Received: from [85.158.139.83:15797] by server-4.bemta-5.messagelabs.com id
	0A/C6-23042-D2466405; Tue, 04 Sep 2012 20:27:25 +0000
X-Env-Sender: robert.phillips@citrix.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1346790443!17292686!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNzY0OTI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1678 invoked from network); 4 Sep 2012 20:27:24 -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;
	4 Sep 2012 20:27:24 -0000
X-IronPort-AV: E=Sophos;i="4.80,369,1344211200"; d="scan'208";a="207069554"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Sep 2012 20:27:22 +0000
Received: from FTLPMAILBOX02.citrite.net ([10.13.98.210]) by
	FTLPMAILMX01.citrite.net ([10.13.107.65]) with mapi;
	Tue, 4 Sep 2012 16:27:21 -0400
From: Robert Phillips <robert.phillips@citrix.com>
To: Sander Eikelenboom <linux@eikelenboom.it>, Ben Guthro <ben@guthro.net>
Date: Tue, 4 Sep 2012 16:27:20 -0400
Thread-Topic: [Xen-devel] dom0 linux 3.6.0-rc4, crash due to ballooning
	althoug dom0_mem=X, max:X set
Thread-Index: Ac2K1GHx3o4s+CLyTruDezLHXF+CzQABD0vw
Message-ID: <048EAD622912254A9DEA24C1734613C18C864C3C5D@FTLPMAILBOX02.citrite.net>
References: <1136369816.20120904183757@eikelenboom.it>
	<20120904163347.GH23361@phenom.dumpdata.com>
	<143844933.20120904191941@eikelenboom.it>
	<CAOvdn6U_yHgtZwv9MWazdLbd3NLq3pwGXnZY5sL2UVBhV_FUoQ@mail.gmail.com>
	<1813712325.20120904213459@eikelenboom.it>
In-Reply-To: <1813712325.20120904213459@eikelenboom.it>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
X-Mailman-Approved-At: Tue, 04 Sep 2012 20:46:31 +0000
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] dom0 linux 3.6.0-rc4,
 crash due to ballooning althoug dom0_mem=X, max:X 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

Ben,

You have asked me to provide the rationale behind the gnttab_old_mfn patch, which you emailed to Sander earlier today. 
Here are my findings.

I found that xen_blkbk_map() in drivers/block/xen-blkback/blkback.c has changed from our previous version.  It now calls gnttab_map_refs() in drivers/xen/grant-table.c.

That function first calls HYPERVISOR_grant_table_op(GNTTABOP_map_grant_ref, ... ) and then calls m2p_add_override() in p2m.c
which is where I made my change.

The unpatched code was saving the pfn's old mfn in kmap_op->dev_bus_addr.  

kmap_op is of type struct gnttab_map_grant_ref.  That data type is used to record grant table mappings so later they can be unmapped correctly.

The problem with saving the old mfn in kmap_op->dev_bus_addr is that it is later overwritten by __gnttab_map_grant_ref() in xen/common/grant_table.c

Since the storage holding the old mfn got overwritten, the unmapping was being done incorrectly.  The balloon code detected that and bugged at drivers/xen/balloon.c:359

My patch simply adds another member called old_mfn to struct gnttab_map_grant_ref rather than trying to overload dev_bus_addr.

I don't know if Sander's bug is the same or related.  The BUG_ON at drivers/xen/balloon.c:359 is quite general.  It simply asserts that we are not trying to re-map a valid mapping.

-- Robert Phillips


-----Original Message-----
From: Sander Eikelenboom [mailto:linux@eikelenboom.it] 
Sent: Tuesday, September 04, 2012 3:35 PM
To: Ben Guthro
Cc: Konrad Rzeszutek Wilk; xen-devel@lists.xen.org; Robert Phillips
Subject: Re: [Xen-devel] dom0 linux 3.6.0-rc4, crash due to ballooning althoug dom0_mem=X, max:X set


Tuesday, September 4, 2012, 8:07:11 PM, you wrote:

> We ran into the same issue, in newer kernels - but had not yet
> submitted this fix.

> One of the developers here came up with a fix (attached, and CC'ed
> here) that fixes an issue where the p2m code reuses a structure member
> where it shouldn't.
> The patch adds a new "old_mfn"  member to the gnttab_map_grant_ref
> structure, instead of re-using  dev_bus_addr.


> If this also works for you, I can re-submit it with a Signed-off-by
> line, if you prefer, Konrad.

Hi Ben,

This patch doesn't work for me:

When starting the PV-guest i get:

(XEN) [2012-09-04 20:31:37] grant_table.c:499:d0 Bad flags in grant map op (68b69070).
(XEN) [2012-09-04 20:31:37] grant_table.c:499:d0 Bad flags in grant map op (0).
(XEN) [2012-09-04 20:31:37] grant_table.c:499:d0 Bad flags in grant map op (0).


and from the dom0 kernel:

[  374.425727] BUG: unable to handle kernel paging request at ffff8800fffd9078
[  374.428901] IP: [<ffffffff81336e4e>] gnttab_map_refs+0x14e/0x270
[  374.428901] PGD 1e0c067 PUD 0
[  374.428901] Oops: 0000 [#1] PREEMPT SMP
[  374.428901] Modules linked in:
[  374.428901] CPU 0
[  374.428901] Pid: 4308, comm: qemu-system-i38 Not tainted 3.6.0-rc4-20120830+ #70 System manufacturer System Product Name/P5Q-EM DO
[  374.428901] RIP: e030:[<ffffffff81336e4e>]  [<ffffffff81336e4e>] gnttab_map_refs+0x14e/0x270
[  374.428901] RSP: e02b:ffff88002f185ca8  EFLAGS: 00010206
[  374.428901] RAX: ffff880000000000 RBX: ffff88001471cf00 RCX: 00000000fffd9078
[  374.428901] RDX: 0000000000000050 RSI: 40000000000fffd9 RDI: 00003ffffffff000
[  374.428901] RBP: ffff88002f185d08 R08: 0000000000000078 R09: 0000000000000000
[  374.428901] R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000004
[  374.428901] R13: ffff88001471c480 R14: 0000000000000002 R15: 0000000000000002
[  374.428901] FS:  00007f6def9f2740(0000) GS:ffff88003fc00000(0000) knlGS:0000000000000000
[  374.428901] CS:  e033 DS: 0000 ES: 0000 CR0: 000000008005003b
[  374.428901] CR2: ffff8800fffd9078 CR3: 000000002d30e000 CR4: 0000000000042660
[  374.428901] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[  374.428901] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[  374.428901] Process qemu-system-i38 (pid: 4308, threadinfo ffff88002f184000, task ffff8800376f1040)
[  374.428901] Stack:
[  374.428901]  ffffffffffffffff 0000000000000050 00000000fffd9078 00000000000fffd9
[  374.428901]  0000000001000000 ffff8800382135a0 ffff88002f185d08 ffff880038211960
[  374.428901]  ffff88002f11d2c0 0000000000000004 0000000000000003 0000000000000001
[  374.428901] Call Trace:
[  374.428901]  [<ffffffff8134212e>] gntdev_mmap+0x20e/0x520
[  374.428901]  [<ffffffff8111c502>] ? mmap_region+0x312/0x5a0
[  374.428901]  [<ffffffff810ae0a0>] ? lockdep_trace_alloc+0xa0/0x130
[  374.428901]  [<ffffffff8111c5be>] mmap_region+0x3ce/0x5a0
[  374.428901]  [<ffffffff8111c9e0>] do_mmap_pgoff+0x250/0x350
[  374.428901]  [<ffffffff81109e88>] vm_mmap_pgoff+0x68/0x90
[  374.428901]  [<ffffffff8111a5b2>] sys_mmap_pgoff+0x152/0x170
[  374.428901]  [<ffffffff812b29be>] ? trace_hardirqs_on_thunk+0x3a/0x3f
[  374.428901]  [<ffffffff81011f29>] sys_mmap+0x29/0x30
[  374.428901]  [<ffffffff8184b939>] system_call_fastpath+0x16/0x1b
[  374.428901] Code: 0f 84 e7 00 00 00 48 89 f1 48 c1 e1 0c 41 81 e0 ff 0f 00 00 48 b8 00 00 00 00 00 88 ff ff 48 bf 00 f0 ff ff ff 3f 00 00 4c 01 c1 <48> 23 3c 01 48 c1 ef 0c 49 8d 54 15 00 4d 85 ed b8 00 00 00 00
[  374.428901] RIP  [<ffffffff81336e4e>] gnttab_map_refs+0x14e/0x270
[  374.428901]  RSP <ffff88002f185ca8>
[  374.428901] CR2: ffff8800fffd9078
[  374.428901] ---[ end trace 0e0a5a49f6503c0a ]---



> Ben


> On Tue, Sep 4, 2012 at 1:19 PM, Sander Eikelenboom <linux@eikelenboom.it> wrote:
>>
>> Tuesday, September 4, 2012, 6:33:47 PM, you wrote:
>>
>>> On Tue, Sep 04, 2012 at 06:37:57PM +0200, Sander Eikelenboom wrote:
>>>> Hi Konrad,
>>>>
>>>> This seems to happen only on a intel machine i'm trying to setup as a development machine (haven't seen it on my amd).
>>>> It boots fine, i have dom0_mem=1024M,max:1024M set, the machine has 2G of mem.
>>
>>> Is this only with Xen 4.2? As, does Xen 4.1 work?
>>>>
>>>> Dom0 and guest kernel are 3.6.0-rc4 with config:
>>
>>> If you back out:
>>
>>> f393387d160211f60398d58463a7e65
>>> Author: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
>>> Date:   Fri Aug 17 16:43:28 2012 -0400
>>
>>>     xen/setup: Fix one-off error when adding for-balloon PFNs to the P2M.
>>
>>> Do you see this bug? (Either with Xen 4.1 or Xen 4.2)?
>>
>> With c96aae1f7f393387d160211f60398d58463a7e65 reverted i still see this bug (with Xen 4.2).
>>
>> Will use the debug patch you mailed and send back the results ...
>>
>>
>>>> [*] Xen memory balloon driver
>>>> [*]   Scrub pages before returning them to system
>>>>
>>>> From http://wiki.xen.org/wiki/Do%EF%BB%BFm0_Memory_%E2%80%94_Where_It_Has_Not_Gone , I thought this should be okay
>>>>
>>>> But when trying to start a PV guest with 512MB mem, the machine (dom0) crashes with the stacktrace below (complete serial-log.txt attached).
>>>>
>>>> From the:
>>>> "mapping kernel into physical memory
>>>> about to get started..."
>>>>
>>>> I would almost say it's trying to reload dom0 ?
>>>>
>>>>
>>>> [  897.161119] device vif1.0 entered promiscuous mode
>>>> mapping kernel into physical memory
>>>> about to get started...
>>>> [  897.696619] xen_bridge: port 1(vif1.0) entered forwarding state
>>>> [  897.716219] xen_bridge: port 1(vif1.0) entered forwarding state
>>>> [  898.129465] ------------[ cut here ]------------
>>>> [  898.132209] kernel BUG at drivers/xen/balloon.c:359!
>>>> [  898.132209] invalid opcode: 0000 [#1] PREEMPT SMP
>>
>>
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xen.org
>> http://lists.xen.org/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 Sep 04 20:53:50 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Sep 2012 20:53:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T907n-0001NC-4T; Tue, 04 Sep 2012 20:53:31 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <misiu.godfrey@gmail.com>) id 1T907k-0001N6-SA
	for xen-devel@lists.xen.org; Tue, 04 Sep 2012 20:53:29 +0000
X-Env-Sender: misiu.godfrey@gmail.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1346792002!6152386!1
X-Originating-IP: [74.125.82.173]
X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_10_20,HTML_MESSAGE,
	RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22122 invoked from network); 4 Sep 2012 20:53:22 -0000
Received: from mail-we0-f173.google.com (HELO mail-we0-f173.google.com)
	(74.125.82.173)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Sep 2012 20:53:22 -0000
Received: by weyz53 with SMTP id z53so4767803wey.32
	for <xen-devel@lists.xen.org>; Tue, 04 Sep 2012 13:53:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
	bh=BnZ8F8DxQ1GniQNM0RTOAvKtN3HyvrqWRK5SZlS8Deg=;
	b=VA+O8xn1RQu3tBJmhb9qYqq3bszXreGbPBm8qyiMKFcm5Dm05vicAJZOj/1Kmc8p6a
	Ak41fNtnJn9tp6uzvvY0c6BS8OsrzJM59o7TJDrQzOHQvRf3XWNvtIakioTdkxZXXJhv
	PJvQTWylFt/kj+GVryD7tT12HcpLcii0G3me2i5QJTK1Ozpob8pOyUVeLM3p50CkGiMu
	AWQa8i8+mpbEiB1C/t73pXmJenKp8GDB+6hu7Yb7hLz8r08lfbjGEsRxkRUgPuD6VQOv
	UmgVxNeXzGb8ThFWnKF7FMp/QEgnTAp4xmjzGDltCVP04ImjLxvPhA6pWmyUwJKc+NEy
	acqw==
MIME-Version: 1.0
Received: by 10.216.194.143 with SMTP id m15mr12456179wen.128.1346792001595;
	Tue, 04 Sep 2012 13:53:21 -0700 (PDT)
Received: by 10.194.13.7 with HTTP; Tue, 4 Sep 2012 13:53:20 -0700 (PDT)
In-Reply-To: <5046606E.9080908@citrix.com>
References: <CAMVU=QgzjT1daB5_zfoP2amtbvWX3X5XZKE6Bj1eX-tTDY=xSQ@mail.gmail.com>
	<50464954.5030207@citrix.com>
	<CAMVU=QgJG=cNH69-kKdWULzV6n2kRrn=d78n75NKuMM_9VXQ9w@mail.gmail.com>
	<5046606E.9080908@citrix.com>
Date: Tue, 4 Sep 2012 16:53:20 -0400
X-Google-Sender-Auth: n995MOubHPvaawJCbDNa8cWNE5Q
Message-ID: <CAMVU=QgrX+n5gHuP+a5UzM1MbYJBv2b5BFJbLLhDwOL+8zgnog@mail.gmail.com>
From: misiu godfrey <godfrey@cs.queensu.ca>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] additional domain.c memory allocation causes "xm
 create" to fail
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============7170334805161095836=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============7170334805161095836==
Content-Type: multipart/alternative; boundary=0016e6da2e7fd7697304c8e672cb

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

> "flush" is the correct term.
>
> However, the structure of caches work against you.  With a set associative
> cache, you have no control over which of the sets gets used for your cache
> line.  So on an N way set associate cache, your worst case may only dirty
> 1/N of the actual lines in the cache.
>
> After that, your L1 cache inclusion policy is going to affect how you
> dirty your L2 cache, as well as whether you have joined caches or split
> instruction and data caches.
>
> Furthermore, on newer processes, multiple cores may share an L2 or L3
> cache, and context switches are unlike to occur at exactly the same time on
> each core, meaning that a context switch on one core is going to (attempt
> to) nuke the L2 cache of the VM which is in mid run on another core.
> Conversely, even executing the loop trying to dirty the cache will mean
> that you dont get all of it, and having another core executing on the same
> L2 cache means it will pull its data back during your dirtying loop.
>

I have some more robust code that takes account of the set-associativity of
the cache, code that I originally thought was going to be superfluous in
this situation.  Now that I have managed to execute this basic loop I can
address a more complex environment with a set-associative.  Currently, I
don't need to worry about an L3 cache because my test machine has no shared
cache between cores (nothing higher than an L2).  Although I will keep this
in mind, as it will need to be addressed once I get beyond the proof of
concept.

Anyway, validating the xmalloc return value seems to have addressed my
problem, although the log I am printing to seems to imply that xmalloc is
never failing.  I'll look further into it once I get more things working.
 Thanks a lot for your advice, Andrew.  Sorry my problem ended up being so
trivial.

-Misiu

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

<br><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"m=
argin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor=
=3D"#FFFFFF" text=3D"#000000">
    &quot;flush&quot; is the correct term.<br>
    <br>
    However, the structure of caches work against you.=A0 With a set
    associative cache, you have no control over which of the sets gets
    used for your cache line.=A0 So on an N way set associate cache, your
    worst case may only dirty 1/N of the actual lines in the cache.<br>
    <br>
    After that, your L1 cache inclusion policy is going to affect how
    you dirty your L2 cache, as well as whether you have joined caches
    or split instruction and data caches.<br>
    <br>
    Furthermore, on newer processes, multiple cores may share an L2 or
    L3 cache, and context switches are unlike to occur at exactly the
    same time on each core, meaning that a context switch on one core is
    going to (attempt to) nuke the L2 cache of the VM which is in mid
    run on another core.=A0 Conversely, even executing the loop trying to
    dirty the cache will mean that you dont get all of it, and having
    another core executing on the same L2 cache means it will pull its
    data back during your dirtying loop.</div></blockquote><div><br></div><=
div>I have some more robust code that takes account of the set-associativit=
y of the cache, code that I originally thought was going to be superfluous =
in this situation. =A0Now that I have managed to execute this basic loop I =
can address a more complex environment with a set-associative. =A0Currently=
, I don&#39;t need to worry about an L3 cache because my test machine has n=
o shared cache between cores (nothing higher than an L2). =A0Although I wil=
l keep this in mind, as it will need to be addressed once I get beyond the =
proof of concept.</div>
<div><br></div><div>Anyway, validating the xmalloc return value seems to ha=
ve addressed my problem, although the log I am printing to seems to imply t=
hat xmalloc is never failing. =A0I&#39;ll look further into it once I get m=
ore things working. =A0Thanks a lot for your advice, Andrew. =A0Sorry my pr=
oblem ended up being so trivial.</div>
<div><br></div><div>-Misiu</div><div><br></div></div>

--0016e6da2e7fd7697304c8e672cb--


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

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

--===============7170334805161095836==--


From xen-devel-bounces@lists.xen.org Tue Sep 04 20:53:50 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Sep 2012 20:53:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T907n-0001NC-4T; Tue, 04 Sep 2012 20:53:31 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <misiu.godfrey@gmail.com>) id 1T907k-0001N6-SA
	for xen-devel@lists.xen.org; Tue, 04 Sep 2012 20:53:29 +0000
X-Env-Sender: misiu.godfrey@gmail.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1346792002!6152386!1
X-Originating-IP: [74.125.82.173]
X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_10_20,HTML_MESSAGE,
	RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22122 invoked from network); 4 Sep 2012 20:53:22 -0000
Received: from mail-we0-f173.google.com (HELO mail-we0-f173.google.com)
	(74.125.82.173)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Sep 2012 20:53:22 -0000
Received: by weyz53 with SMTP id z53so4767803wey.32
	for <xen-devel@lists.xen.org>; Tue, 04 Sep 2012 13:53:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
	bh=BnZ8F8DxQ1GniQNM0RTOAvKtN3HyvrqWRK5SZlS8Deg=;
	b=VA+O8xn1RQu3tBJmhb9qYqq3bszXreGbPBm8qyiMKFcm5Dm05vicAJZOj/1Kmc8p6a
	Ak41fNtnJn9tp6uzvvY0c6BS8OsrzJM59o7TJDrQzOHQvRf3XWNvtIakioTdkxZXXJhv
	PJvQTWylFt/kj+GVryD7tT12HcpLcii0G3me2i5QJTK1Ozpob8pOyUVeLM3p50CkGiMu
	AWQa8i8+mpbEiB1C/t73pXmJenKp8GDB+6hu7Yb7hLz8r08lfbjGEsRxkRUgPuD6VQOv
	UmgVxNeXzGb8ThFWnKF7FMp/QEgnTAp4xmjzGDltCVP04ImjLxvPhA6pWmyUwJKc+NEy
	acqw==
MIME-Version: 1.0
Received: by 10.216.194.143 with SMTP id m15mr12456179wen.128.1346792001595;
	Tue, 04 Sep 2012 13:53:21 -0700 (PDT)
Received: by 10.194.13.7 with HTTP; Tue, 4 Sep 2012 13:53:20 -0700 (PDT)
In-Reply-To: <5046606E.9080908@citrix.com>
References: <CAMVU=QgzjT1daB5_zfoP2amtbvWX3X5XZKE6Bj1eX-tTDY=xSQ@mail.gmail.com>
	<50464954.5030207@citrix.com>
	<CAMVU=QgJG=cNH69-kKdWULzV6n2kRrn=d78n75NKuMM_9VXQ9w@mail.gmail.com>
	<5046606E.9080908@citrix.com>
Date: Tue, 4 Sep 2012 16:53:20 -0400
X-Google-Sender-Auth: n995MOubHPvaawJCbDNa8cWNE5Q
Message-ID: <CAMVU=QgrX+n5gHuP+a5UzM1MbYJBv2b5BFJbLLhDwOL+8zgnog@mail.gmail.com>
From: misiu godfrey <godfrey@cs.queensu.ca>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] additional domain.c memory allocation causes "xm
 create" to fail
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============7170334805161095836=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============7170334805161095836==
Content-Type: multipart/alternative; boundary=0016e6da2e7fd7697304c8e672cb

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

> "flush" is the correct term.
>
> However, the structure of caches work against you.  With a set associative
> cache, you have no control over which of the sets gets used for your cache
> line.  So on an N way set associate cache, your worst case may only dirty
> 1/N of the actual lines in the cache.
>
> After that, your L1 cache inclusion policy is going to affect how you
> dirty your L2 cache, as well as whether you have joined caches or split
> instruction and data caches.
>
> Furthermore, on newer processes, multiple cores may share an L2 or L3
> cache, and context switches are unlike to occur at exactly the same time on
> each core, meaning that a context switch on one core is going to (attempt
> to) nuke the L2 cache of the VM which is in mid run on another core.
> Conversely, even executing the loop trying to dirty the cache will mean
> that you dont get all of it, and having another core executing on the same
> L2 cache means it will pull its data back during your dirtying loop.
>

I have some more robust code that takes account of the set-associativity of
the cache, code that I originally thought was going to be superfluous in
this situation.  Now that I have managed to execute this basic loop I can
address a more complex environment with a set-associative.  Currently, I
don't need to worry about an L3 cache because my test machine has no shared
cache between cores (nothing higher than an L2).  Although I will keep this
in mind, as it will need to be addressed once I get beyond the proof of
concept.

Anyway, validating the xmalloc return value seems to have addressed my
problem, although the log I am printing to seems to imply that xmalloc is
never failing.  I'll look further into it once I get more things working.
 Thanks a lot for your advice, Andrew.  Sorry my problem ended up being so
trivial.

-Misiu

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

<br><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"m=
argin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor=
=3D"#FFFFFF" text=3D"#000000">
    &quot;flush&quot; is the correct term.<br>
    <br>
    However, the structure of caches work against you.=A0 With a set
    associative cache, you have no control over which of the sets gets
    used for your cache line.=A0 So on an N way set associate cache, your
    worst case may only dirty 1/N of the actual lines in the cache.<br>
    <br>
    After that, your L1 cache inclusion policy is going to affect how
    you dirty your L2 cache, as well as whether you have joined caches
    or split instruction and data caches.<br>
    <br>
    Furthermore, on newer processes, multiple cores may share an L2 or
    L3 cache, and context switches are unlike to occur at exactly the
    same time on each core, meaning that a context switch on one core is
    going to (attempt to) nuke the L2 cache of the VM which is in mid
    run on another core.=A0 Conversely, even executing the loop trying to
    dirty the cache will mean that you dont get all of it, and having
    another core executing on the same L2 cache means it will pull its
    data back during your dirtying loop.</div></blockquote><div><br></div><=
div>I have some more robust code that takes account of the set-associativit=
y of the cache, code that I originally thought was going to be superfluous =
in this situation. =A0Now that I have managed to execute this basic loop I =
can address a more complex environment with a set-associative. =A0Currently=
, I don&#39;t need to worry about an L3 cache because my test machine has n=
o shared cache between cores (nothing higher than an L2). =A0Although I wil=
l keep this in mind, as it will need to be addressed once I get beyond the =
proof of concept.</div>
<div><br></div><div>Anyway, validating the xmalloc return value seems to ha=
ve addressed my problem, although the log I am printing to seems to imply t=
hat xmalloc is never failing. =A0I&#39;ll look further into it once I get m=
ore things working. =A0Thanks a lot for your advice, Andrew. =A0Sorry my pr=
oblem ended up being so trivial.</div>
<div><br></div><div>-Misiu</div><div><br></div></div>

--0016e6da2e7fd7697304c8e672cb--


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

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

--===============7170334805161095836==--


From xen-devel-bounces@lists.xen.org Tue Sep 04 20:55:25 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Sep 2012 20:55:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T909K-0001Rm-LG; Tue, 04 Sep 2012 20:55:06 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1T909I-0001Rd-QW
	for xen-devel@lists.xensource.com; Tue, 04 Sep 2012 20:55:05 +0000
Received: from [85.158.143.99:32428] by server-1.bemta-4.messagelabs.com id
	A5/CD-12504-8AA66405; Tue, 04 Sep 2012 20:55:04 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1346792101!18757031!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzI3MDk2\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21638 invoked from network); 4 Sep 2012 20:55:03 -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; 4 Sep 2012 20:55:03 -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 q84Kt0sH000900
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 4 Sep 2012 20:55:01 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q84Ksx9s027661
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 4 Sep 2012 20:55:00 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
	q84KsxtR015545; Tue, 4 Sep 2012 15:54:59 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 04 Sep 2012 13:54:59 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 93449402C1; Tue,  4 Sep 2012 16:44:31 -0400 (EDT)
Date: Tue, 4 Sep 2012 16:44:31 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: linux-kernel@vger.kernel.org
Message-ID: <20120904204431.GA3155@phenom.dumpdata.com>
References: <1346789834-30618-1-git-send-email-konrad.wilk@oracle.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1346789834-30618-1-git-send-email-konrad.wilk@oracle.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] xen/p2m: Fix one by off error in checking
 the P2M tree directory.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Sep 04, 2012 at 04:17:14PM -0400, Konrad Rzeszutek Wilk wrote:
> We would the full P2M top directory from 0->MAX_DOMAIN_PAGES (inclusive).

.. We would traverse the full P2M top directory (from 0->MAX_DOMAIN_PAGES
inclusive) when trying to figure out whether we can re-use some of the
P2M middle leafs.

> 
> Which meant that if the kernel was compiled with MAX_DOMAIN_PAGES=512
> we would try to use the 512th entry. Fortunately for us the p2m_top_index
> has a check for this:
> 
>  BUG_ON(pfn >= MAX_P2M_PFN);
> 
> which we hit and saw this:
> 
> (XEN) domain_crash_sync called from entry.S
> (XEN) Domain 0 (vcpu#0) crashed on cpu#0:
> (XEN) ----[ Xen-4.1.2-OVM  x86_64  debug=n  Tainted:    C ]----
> (XEN) CPU:    0
> (XEN) RIP:    e033:[<ffffffff819cadeb>]
> (XEN) RFLAGS: 0000000000000212   EM: 1   CONTEXT: pv guest
> (XEN) rax: ffffffff81db5000   rbx: ffffffff81db4000   rcx: 0000000000000000
> (XEN) rdx: 0000000000480211   rsi: 0000000000000000   rdi: ffffffff81db4000
> (XEN) rbp: ffffffff81793db8   rsp: ffffffff81793d38   r8:  0000000008000000
> (XEN) r9:  4000000000000000   r10: 0000000000000000   r11: ffffffff81db7000
> (XEN) r12: 0000000000000ff8   r13: ffffffff81df1ff8   r14: ffffffff81db6000
> (XEN) r15: 0000000000000ff8   cr0: 000000008005003b   cr4: 00000000000026f0
> (XEN) cr3: 0000000661795000   cr2: 0000000000000000
> 
> Fixes-Oracle-Bug: 14570662
> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> ---
>  arch/x86/xen/p2m.c |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/arch/x86/xen/p2m.c b/arch/x86/xen/p2m.c
> index 0bfaf5b..af11f00 100644
> --- a/arch/x86/xen/p2m.c
> +++ b/arch/x86/xen/p2m.c
> @@ -695,7 +695,7 @@ bool __init early_can_reuse_p2m_middle(unsigned long set_pfn, unsigned long set_
>  	if (p2m_index(set_pfn))
>  		return false;
>  
> -	for (pfn = 0; pfn <= MAX_DOMAIN_PAGES; pfn += P2M_PER_PAGE) {
> +	for (pfn = 0; pfn < MAX_DOMAIN_PAGES; pfn += P2M_PER_PAGE) {
>  		topidx = p2m_top_index(pfn);
>  
>  		if (!p2m_top[topidx])
> -- 
> 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 Sep 04 20:55:25 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Sep 2012 20:55:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T909K-0001Rm-LG; Tue, 04 Sep 2012 20:55:06 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1T909I-0001Rd-QW
	for xen-devel@lists.xensource.com; Tue, 04 Sep 2012 20:55:05 +0000
Received: from [85.158.143.99:32428] by server-1.bemta-4.messagelabs.com id
	A5/CD-12504-8AA66405; Tue, 04 Sep 2012 20:55:04 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1346792101!18757031!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzI3MDk2\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21638 invoked from network); 4 Sep 2012 20:55:03 -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; 4 Sep 2012 20:55:03 -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 q84Kt0sH000900
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 4 Sep 2012 20:55:01 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q84Ksx9s027661
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 4 Sep 2012 20:55:00 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
	q84KsxtR015545; Tue, 4 Sep 2012 15:54:59 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 04 Sep 2012 13:54:59 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 93449402C1; Tue,  4 Sep 2012 16:44:31 -0400 (EDT)
Date: Tue, 4 Sep 2012 16:44:31 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: linux-kernel@vger.kernel.org
Message-ID: <20120904204431.GA3155@phenom.dumpdata.com>
References: <1346789834-30618-1-git-send-email-konrad.wilk@oracle.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1346789834-30618-1-git-send-email-konrad.wilk@oracle.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] xen/p2m: Fix one by off error in checking
 the P2M tree directory.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Sep 04, 2012 at 04:17:14PM -0400, Konrad Rzeszutek Wilk wrote:
> We would the full P2M top directory from 0->MAX_DOMAIN_PAGES (inclusive).

.. We would traverse the full P2M top directory (from 0->MAX_DOMAIN_PAGES
inclusive) when trying to figure out whether we can re-use some of the
P2M middle leafs.

> 
> Which meant that if the kernel was compiled with MAX_DOMAIN_PAGES=512
> we would try to use the 512th entry. Fortunately for us the p2m_top_index
> has a check for this:
> 
>  BUG_ON(pfn >= MAX_P2M_PFN);
> 
> which we hit and saw this:
> 
> (XEN) domain_crash_sync called from entry.S
> (XEN) Domain 0 (vcpu#0) crashed on cpu#0:
> (XEN) ----[ Xen-4.1.2-OVM  x86_64  debug=n  Tainted:    C ]----
> (XEN) CPU:    0
> (XEN) RIP:    e033:[<ffffffff819cadeb>]
> (XEN) RFLAGS: 0000000000000212   EM: 1   CONTEXT: pv guest
> (XEN) rax: ffffffff81db5000   rbx: ffffffff81db4000   rcx: 0000000000000000
> (XEN) rdx: 0000000000480211   rsi: 0000000000000000   rdi: ffffffff81db4000
> (XEN) rbp: ffffffff81793db8   rsp: ffffffff81793d38   r8:  0000000008000000
> (XEN) r9:  4000000000000000   r10: 0000000000000000   r11: ffffffff81db7000
> (XEN) r12: 0000000000000ff8   r13: ffffffff81df1ff8   r14: ffffffff81db6000
> (XEN) r15: 0000000000000ff8   cr0: 000000008005003b   cr4: 00000000000026f0
> (XEN) cr3: 0000000661795000   cr2: 0000000000000000
> 
> Fixes-Oracle-Bug: 14570662
> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> ---
>  arch/x86/xen/p2m.c |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/arch/x86/xen/p2m.c b/arch/x86/xen/p2m.c
> index 0bfaf5b..af11f00 100644
> --- a/arch/x86/xen/p2m.c
> +++ b/arch/x86/xen/p2m.c
> @@ -695,7 +695,7 @@ bool __init early_can_reuse_p2m_middle(unsigned long set_pfn, unsigned long set_
>  	if (p2m_index(set_pfn))
>  		return false;
>  
> -	for (pfn = 0; pfn <= MAX_DOMAIN_PAGES; pfn += P2M_PER_PAGE) {
> +	for (pfn = 0; pfn < MAX_DOMAIN_PAGES; pfn += P2M_PER_PAGE) {
>  		topidx = p2m_top_index(pfn);
>  
>  		if (!p2m_top[topidx])
> -- 
> 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 Sep 04 21:24:25 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Sep 2012 21:24:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T90bK-0001nl-K2; Tue, 04 Sep 2012 21:24:02 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <linux@eikelenboom.it>) id 1T90bI-0001ng-QK
	for xen-devel@lists.xen.org; Tue, 04 Sep 2012 21:24:01 +0000
Received: from [85.158.139.83:39120] by server-1.bemta-5.messagelabs.com id
	84/C3-32692-07176405; Tue, 04 Sep 2012 21:24:00 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-2.tower-182.messagelabs.com!1346793839!28557546!1
X-Originating-IP: [188.40.164.121]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30284 invoked from network); 4 Sep 2012 21:23:59 -0000
Received: from static.121.164.40.188.clients.your-server.de (HELO
	smtp.eikelenboom.it) (188.40.164.121)
	by server-2.tower-182.messagelabs.com with AES256-SHA encrypted SMTP;
	4 Sep 2012 21:23:59 -0000
Received: from 128-64-ftth.onsneteindhoven.nl ([88.159.64.128]:58310
	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 1T90YE-00015A-FF; Tue, 04 Sep 2012 23:20:50 +0200
Date: Tue, 4 Sep 2012 23:23:56 +0200
From: Sander Eikelenboom <linux@eikelenboom.it>
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <3985573.20120904232356@eikelenboom.it>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
In-Reply-To: <20120904175841.GA10379@phenom.dumpdata.com>
References: <1136369816.20120904183757@eikelenboom.it>
	<20120904163903.GI23361@phenom.dumpdata.com>
	<8328705.20120904200241@eikelenboom.it>
	<20120904175841.GA10379@phenom.dumpdata.com>
MIME-Version: 1.0
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] dom0 linux 3.6.0-rc4,
	crash due to ballooning althoug dom0_mem=X, max:X 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


Tuesday, September 4, 2012, 7:58:41 PM, you wrote:

> On Tue, Sep 04, 2012 at 08:02:41PM +0200, Sander Eikelenboom wrote:
>> 
>> Tuesday, September 4, 2012, 6:39:03 PM, you wrote:
>> 
>> > On Tue, Sep 04, 2012 at 06:37:57PM +0200, Sander Eikelenboom wrote:
>> >> Hi Konrad,
>> >> 
>> >> This seems to happen only on a intel machine i'm trying to setup as a development machine (haven't seen it on my amd).
>> >> It boots fine, i have dom0_mem=1024M,max:1024M set, the machine has 2G of mem.
>> >> 
>> >> Dom0 and guest kernel are 3.6.0-rc4 with config:
>> >> [*] Xen memory balloon driver
>> >> [*]   Scrub pages before returning them to system
>> 
>> > Can you also try this patch out and provide the full log (bootup and such). Thanks!
>> 
>> After applying this patch and due to the removal of the BUG_ON the domU boots and is reachable by SSH.
>> Serial log attached.

> Wow. That is a lot of .. And if you use Xen 4.1 it works fine?

Ok .. to sum it up after todays compile day :-p

- xen-4.2.0-rc4-pre + linux 3.6-rc4 -> BUG_ON on start PV guest
- xen-4.2.0-rc4-pre + linux 3.5.3   -> BUG_ON on start PV guest
- xen-4.1.4-pre     + linux 3.5.3   -> BUG_ON on start PV guest
- xen-4.1.4-pre     + linux 3.4.1   -> Works OK
- xen-4.2.0-rc4-pre + linux 3.6-rc4 -> Works, BUG_ON removed by patch (http://lists.xen.org/archives/html/xen-devel/2012-09/msg00142.html)




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

From xen-devel-bounces@lists.xen.org Tue Sep 04 21:24:25 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Sep 2012 21:24:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T90bK-0001nl-K2; Tue, 04 Sep 2012 21:24:02 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <linux@eikelenboom.it>) id 1T90bI-0001ng-QK
	for xen-devel@lists.xen.org; Tue, 04 Sep 2012 21:24:01 +0000
Received: from [85.158.139.83:39120] by server-1.bemta-5.messagelabs.com id
	84/C3-32692-07176405; Tue, 04 Sep 2012 21:24:00 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-2.tower-182.messagelabs.com!1346793839!28557546!1
X-Originating-IP: [188.40.164.121]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30284 invoked from network); 4 Sep 2012 21:23:59 -0000
Received: from static.121.164.40.188.clients.your-server.de (HELO
	smtp.eikelenboom.it) (188.40.164.121)
	by server-2.tower-182.messagelabs.com with AES256-SHA encrypted SMTP;
	4 Sep 2012 21:23:59 -0000
Received: from 128-64-ftth.onsneteindhoven.nl ([88.159.64.128]:58310
	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 1T90YE-00015A-FF; Tue, 04 Sep 2012 23:20:50 +0200
Date: Tue, 4 Sep 2012 23:23:56 +0200
From: Sander Eikelenboom <linux@eikelenboom.it>
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <3985573.20120904232356@eikelenboom.it>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
In-Reply-To: <20120904175841.GA10379@phenom.dumpdata.com>
References: <1136369816.20120904183757@eikelenboom.it>
	<20120904163903.GI23361@phenom.dumpdata.com>
	<8328705.20120904200241@eikelenboom.it>
	<20120904175841.GA10379@phenom.dumpdata.com>
MIME-Version: 1.0
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] dom0 linux 3.6.0-rc4,
	crash due to ballooning althoug dom0_mem=X, max:X 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


Tuesday, September 4, 2012, 7:58:41 PM, you wrote:

> On Tue, Sep 04, 2012 at 08:02:41PM +0200, Sander Eikelenboom wrote:
>> 
>> Tuesday, September 4, 2012, 6:39:03 PM, you wrote:
>> 
>> > On Tue, Sep 04, 2012 at 06:37:57PM +0200, Sander Eikelenboom wrote:
>> >> Hi Konrad,
>> >> 
>> >> This seems to happen only on a intel machine i'm trying to setup as a development machine (haven't seen it on my amd).
>> >> It boots fine, i have dom0_mem=1024M,max:1024M set, the machine has 2G of mem.
>> >> 
>> >> Dom0 and guest kernel are 3.6.0-rc4 with config:
>> >> [*] Xen memory balloon driver
>> >> [*]   Scrub pages before returning them to system
>> 
>> > Can you also try this patch out and provide the full log (bootup and such). Thanks!
>> 
>> After applying this patch and due to the removal of the BUG_ON the domU boots and is reachable by SSH.
>> Serial log attached.

> Wow. That is a lot of .. And if you use Xen 4.1 it works fine?

Ok .. to sum it up after todays compile day :-p

- xen-4.2.0-rc4-pre + linux 3.6-rc4 -> BUG_ON on start PV guest
- xen-4.2.0-rc4-pre + linux 3.5.3   -> BUG_ON on start PV guest
- xen-4.1.4-pre     + linux 3.5.3   -> BUG_ON on start PV guest
- xen-4.1.4-pre     + linux 3.4.1   -> Works OK
- xen-4.2.0-rc4-pre + linux 3.6-rc4 -> Works, BUG_ON removed by patch (http://lists.xen.org/archives/html/xen-devel/2012-09/msg00142.html)




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

From xen-devel-bounces@lists.xen.org Tue Sep 04 21:26:55 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Sep 2012 21: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 1T90dn-0001tx-6B; Tue, 04 Sep 2012 21:26:35 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dan.magenheimer@oracle.com>) id 1T90dl-0001tr-5i
	for xen-devel@lists.xen.org; Tue, 04 Sep 2012 21:26:33 +0000
Received: from [85.158.139.83:53312] by server-11.bemta-5.messagelabs.com id
	26/1F-24658-80276405; Tue, 04 Sep 2012 21:26:32 +0000
X-Env-Sender: dan.magenheimer@oracle.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1346793990!24624428!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzI5MDMy\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22997 invoked from network); 4 Sep 2012 21:26:31 -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; 4 Sep 2012 21:26:31 -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 q84LQSIu031730
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 4 Sep 2012 21:26:29 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
	q84LQSGZ028626
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 4 Sep 2012 21:26:28 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
	q84LQRlD031115; Tue, 4 Sep 2012 16:26:27 -0500
MIME-Version: 1.0
Message-ID: <f24f5494-5b64-4872-a830-c44859461a9d@default>
Date: Tue, 4 Sep 2012 14:25:46 -0700 (PDT)
From: Dan Magenheimer <dan.magenheimer@oracle.com>
To: xen-devel@lists.xen.org, keir@xen.org
X-Priority: 3
X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.7  (607090) [OL
	12.0.6661.5003 (x86)]
Content-Type: multipart/mixed;
	boundary="__134679398768762311abhmt111.oracle.com"
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: Kurt Hackel <kurt.hackel@oracle.com>, Konrad Wilk <konrad.wilk@oracle.com>
Subject: [Xen-devel] [PATCH] tmem: fixup 2010 cleanup patch that breaks tmem
	save/restore
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--__134679398768762311abhmt111.oracle.com
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable

20918:a3fa6d444b25 "Fix domain reference leaks" (in Feb 2010, by Jan)
does some cleanup in addition to the leak fixes.  Unfortunately, that
cleanup inadvertently resulted in an incorrect fallthrough in a switch
statement which breaks tmem save/restore.

That broken patch was apparently applied to 4.0-testing and 4.1-testing
so those are broken as well.

What is the process now for requesting back-patches to 4.0 and 4.1?

(Side note: This does not by itself entirely fix save/restore in 4.2.)

Signed-off-by: Dan Magenheimer <dan.magenheimer@oracle.com>

diff -r 1dfbae8dd282 xen/common/tmem.c
--- a/xen/common/tmem.c=09Fri Aug 31 11:13:49 2012 +0100
+++ b/xen/common/tmem.c=09Tue Sep 04 15:17:29 2012 -0600
@@ -2404,6 +2404,7 @@ static NOINLINE int tmemc_save_subop(int
         *uuid++ =3D pool->uuid[0];
         *uuid =3D pool->uuid[1];
         rc =3D 0;
+        break;
     case TMEMC_SAVE_END:
         client->live_migrating =3D 0;
         if ( !list_empty(&client->persistent_invalidated_list) )
@@ -2412,6 +2413,7 @@ static NOINLINE int tmemc_save_subop(int
                 pgp_free_from_inv_list(client,pgp);
         client->frozen =3D client->was_frozen;
         rc =3D 0;
+        break;
     }
     return rc;
 }

--__134679398768762311abhmt111.oracle.com
Content-Type: application/octet-stream;
 name="tmem-fix-switch-in-tmemsave.patch"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="tmem-fix-switch-in-tmemsave.patch"

ZGlmZiAtciAxZGZiYWU4ZGQyODIgeGVuL2NvbW1vbi90bWVtLmMKLS0tIGEveGVuL2NvbW1vbi90
bWVtLmMJRnJpIEF1ZyAzMSAxMToxMzo0OSAyMDEyICswMTAwCisrKyBiL3hlbi9jb21tb24vdG1l
bS5jCVR1ZSBTZXAgMDQgMTU6MTc6MjkgMjAxMiAtMDYwMApAQCAtMjQwNCw2ICsyNDA0LDcgQEAg
c3RhdGljIE5PSU5MSU5FIGludCB0bWVtY19zYXZlX3N1Ym9wKGludAogICAgICAgICAqdXVpZCsr
ID0gcG9vbC0+dXVpZFswXTsKICAgICAgICAgKnV1aWQgPSBwb29sLT51dWlkWzFdOwogICAgICAg
ICByYyA9IDA7CisgICAgICAgIGJyZWFrOwogICAgIGNhc2UgVE1FTUNfU0FWRV9FTkQ6CiAgICAg
ICAgIGNsaWVudC0+bGl2ZV9taWdyYXRpbmcgPSAwOwogICAgICAgICBpZiAoICFsaXN0X2VtcHR5
KCZjbGllbnQtPnBlcnNpc3RlbnRfaW52YWxpZGF0ZWRfbGlzdCkgKQpAQCAtMjQxMiw2ICsyNDEz
LDcgQEAgc3RhdGljIE5PSU5MSU5FIGludCB0bWVtY19zYXZlX3N1Ym9wKGludAogICAgICAgICAg
ICAgICAgIHBncF9mcmVlX2Zyb21faW52X2xpc3QoY2xpZW50LHBncCk7CiAgICAgICAgIGNsaWVu
dC0+ZnJvemVuID0gY2xpZW50LT53YXNfZnJvemVuOwogICAgICAgICByYyA9IDA7CisgICAgICAg
IGJyZWFrOwogICAgIH0KICAgICByZXR1cm4gcmM7CiB9Cg==
--__134679398768762311abhmt111.oracle.com
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--__134679398768762311abhmt111.oracle.com--


From xen-devel-bounces@lists.xen.org Tue Sep 04 21:26:55 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Sep 2012 21: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 1T90dn-0001tx-6B; Tue, 04 Sep 2012 21:26:35 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dan.magenheimer@oracle.com>) id 1T90dl-0001tr-5i
	for xen-devel@lists.xen.org; Tue, 04 Sep 2012 21:26:33 +0000
Received: from [85.158.139.83:53312] by server-11.bemta-5.messagelabs.com id
	26/1F-24658-80276405; Tue, 04 Sep 2012 21:26:32 +0000
X-Env-Sender: dan.magenheimer@oracle.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1346793990!24624428!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzI5MDMy\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22997 invoked from network); 4 Sep 2012 21:26:31 -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; 4 Sep 2012 21:26:31 -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 q84LQSIu031730
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 4 Sep 2012 21:26:29 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
	q84LQSGZ028626
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 4 Sep 2012 21:26:28 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
	q84LQRlD031115; Tue, 4 Sep 2012 16:26:27 -0500
MIME-Version: 1.0
Message-ID: <f24f5494-5b64-4872-a830-c44859461a9d@default>
Date: Tue, 4 Sep 2012 14:25:46 -0700 (PDT)
From: Dan Magenheimer <dan.magenheimer@oracle.com>
To: xen-devel@lists.xen.org, keir@xen.org
X-Priority: 3
X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.7  (607090) [OL
	12.0.6661.5003 (x86)]
Content-Type: multipart/mixed;
	boundary="__134679398768762311abhmt111.oracle.com"
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: Kurt Hackel <kurt.hackel@oracle.com>, Konrad Wilk <konrad.wilk@oracle.com>
Subject: [Xen-devel] [PATCH] tmem: fixup 2010 cleanup patch that breaks tmem
	save/restore
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--__134679398768762311abhmt111.oracle.com
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable

20918:a3fa6d444b25 "Fix domain reference leaks" (in Feb 2010, by Jan)
does some cleanup in addition to the leak fixes.  Unfortunately, that
cleanup inadvertently resulted in an incorrect fallthrough in a switch
statement which breaks tmem save/restore.

That broken patch was apparently applied to 4.0-testing and 4.1-testing
so those are broken as well.

What is the process now for requesting back-patches to 4.0 and 4.1?

(Side note: This does not by itself entirely fix save/restore in 4.2.)

Signed-off-by: Dan Magenheimer <dan.magenheimer@oracle.com>

diff -r 1dfbae8dd282 xen/common/tmem.c
--- a/xen/common/tmem.c=09Fri Aug 31 11:13:49 2012 +0100
+++ b/xen/common/tmem.c=09Tue Sep 04 15:17:29 2012 -0600
@@ -2404,6 +2404,7 @@ static NOINLINE int tmemc_save_subop(int
         *uuid++ =3D pool->uuid[0];
         *uuid =3D pool->uuid[1];
         rc =3D 0;
+        break;
     case TMEMC_SAVE_END:
         client->live_migrating =3D 0;
         if ( !list_empty(&client->persistent_invalidated_list) )
@@ -2412,6 +2413,7 @@ static NOINLINE int tmemc_save_subop(int
                 pgp_free_from_inv_list(client,pgp);
         client->frozen =3D client->was_frozen;
         rc =3D 0;
+        break;
     }
     return rc;
 }

--__134679398768762311abhmt111.oracle.com
Content-Type: application/octet-stream;
 name="tmem-fix-switch-in-tmemsave.patch"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="tmem-fix-switch-in-tmemsave.patch"

ZGlmZiAtciAxZGZiYWU4ZGQyODIgeGVuL2NvbW1vbi90bWVtLmMKLS0tIGEveGVuL2NvbW1vbi90
bWVtLmMJRnJpIEF1ZyAzMSAxMToxMzo0OSAyMDEyICswMTAwCisrKyBiL3hlbi9jb21tb24vdG1l
bS5jCVR1ZSBTZXAgMDQgMTU6MTc6MjkgMjAxMiAtMDYwMApAQCAtMjQwNCw2ICsyNDA0LDcgQEAg
c3RhdGljIE5PSU5MSU5FIGludCB0bWVtY19zYXZlX3N1Ym9wKGludAogICAgICAgICAqdXVpZCsr
ID0gcG9vbC0+dXVpZFswXTsKICAgICAgICAgKnV1aWQgPSBwb29sLT51dWlkWzFdOwogICAgICAg
ICByYyA9IDA7CisgICAgICAgIGJyZWFrOwogICAgIGNhc2UgVE1FTUNfU0FWRV9FTkQ6CiAgICAg
ICAgIGNsaWVudC0+bGl2ZV9taWdyYXRpbmcgPSAwOwogICAgICAgICBpZiAoICFsaXN0X2VtcHR5
KCZjbGllbnQtPnBlcnNpc3RlbnRfaW52YWxpZGF0ZWRfbGlzdCkgKQpAQCAtMjQxMiw2ICsyNDEz
LDcgQEAgc3RhdGljIE5PSU5MSU5FIGludCB0bWVtY19zYXZlX3N1Ym9wKGludAogICAgICAgICAg
ICAgICAgIHBncF9mcmVlX2Zyb21faW52X2xpc3QoY2xpZW50LHBncCk7CiAgICAgICAgIGNsaWVu
dC0+ZnJvemVuID0gY2xpZW50LT53YXNfZnJvemVuOwogICAgICAgICByYyA9IDA7CisgICAgICAg
IGJyZWFrOwogICAgIH0KICAgICByZXR1cm4gcmM7CiB9Cg==
--__134679398768762311abhmt111.oracle.com
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--__134679398768762311abhmt111.oracle.com--


From xen-devel-bounces@lists.xen.org Tue Sep 04 22:01:30 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Sep 2012 22: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 1T91B1-0002OR-FT; Tue, 04 Sep 2012 22: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.Jackson@eu.citrix.com>) id 1T91B0-0002Nt-7p
	for xen-devel@lists.xensource.com; Tue, 04 Sep 2012 22:00:54 +0000
Received: from [85.158.143.99:8217] by server-1.bemta-4.messagelabs.com id
	FD/2E-12504-51A76405; Tue, 04 Sep 2012 22:00:53 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1346796052!28560749!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTE4NjM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6081 invoked from network); 4 Sep 2012 22:00:52 -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;
	4 Sep 2012 22:00:52 -0000
X-IronPort-AV: E=Sophos;i="4.80,369,1344211200"; d="scan'208";a="14344596"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Sep 2012 22:00: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.279.1; Tue, 4 Sep 2012 23:00: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 1T91Ax-00052R-Ss;
	Tue, 04 Sep 2012 22:00:51 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1T91Ax-0004QN-Jc;
	Tue, 04 Sep 2012 23:00:51 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-13645-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Tue, 4 Sep 2012 23:00:51 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13645: 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 13645 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13645/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin 12 guest-saverestore.2      fail blocked in 13643
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail like 13643
 test-i386-i386-xl-qemuu-winxpsp3  9 guest-localmigrate         fail like 13643
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail like 13643

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

version targeted for testing:
 xen                  9dc729b75595
baseline version:
 xen                  1dfbae8dd282

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@citrix.com>
  Christoph Egger <Christoph.Egger@amd.com>
  Dan Magenheimer <dan.magenheimer@oracle.com>
  Dieter Bloms <dieter@bloms.de>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Jan Beulich <jbeulich@suse.de>
  Keir Fraser <keir@xen.org>
  Pasi K?rkk?inen <pasik@iki.fi>
------------------------------------------------------------

jobs:
 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                                 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                                     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=9dc729b75595
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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 9dc729b75595
+ branch=xen-unstable
+ revision=9dc729b75595
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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 9dc729b75595 ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg
pushing to ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg
searching for changes
remote: adding changesets
remote: adding manifests
remote: adding file changes
remote: added 11 changesets with 24 changes to 22 files

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

From xen-devel-bounces@lists.xen.org Tue Sep 04 22:01:30 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Sep 2012 22: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 1T91B1-0002OR-FT; Tue, 04 Sep 2012 22: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.Jackson@eu.citrix.com>) id 1T91B0-0002Nt-7p
	for xen-devel@lists.xensource.com; Tue, 04 Sep 2012 22:00:54 +0000
Received: from [85.158.143.99:8217] by server-1.bemta-4.messagelabs.com id
	FD/2E-12504-51A76405; Tue, 04 Sep 2012 22:00:53 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1346796052!28560749!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTE4NjM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6081 invoked from network); 4 Sep 2012 22:00:52 -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;
	4 Sep 2012 22:00:52 -0000
X-IronPort-AV: E=Sophos;i="4.80,369,1344211200"; d="scan'208";a="14344596"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Sep 2012 22:00: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.279.1; Tue, 4 Sep 2012 23:00: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 1T91Ax-00052R-Ss;
	Tue, 04 Sep 2012 22:00:51 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1T91Ax-0004QN-Jc;
	Tue, 04 Sep 2012 23:00:51 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-13645-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Tue, 4 Sep 2012 23:00:51 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13645: 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 13645 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13645/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin 12 guest-saverestore.2      fail blocked in 13643
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail like 13643
 test-i386-i386-xl-qemuu-winxpsp3  9 guest-localmigrate         fail like 13643
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail like 13643

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

version targeted for testing:
 xen                  9dc729b75595
baseline version:
 xen                  1dfbae8dd282

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@citrix.com>
  Christoph Egger <Christoph.Egger@amd.com>
  Dan Magenheimer <dan.magenheimer@oracle.com>
  Dieter Bloms <dieter@bloms.de>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Jan Beulich <jbeulich@suse.de>
  Keir Fraser <keir@xen.org>
  Pasi K?rkk?inen <pasik@iki.fi>
------------------------------------------------------------

jobs:
 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                                 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                                     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=9dc729b75595
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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 9dc729b75595
+ branch=xen-unstable
+ revision=9dc729b75595
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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 9dc729b75595 ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg
pushing to ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg
searching for changes
remote: adding changesets
remote: adding manifests
remote: adding file changes
remote: added 11 changesets with 24 changes to 22 files

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

From xen-devel-bounces@lists.xen.org Tue Sep 04 23:57:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Sep 2012 23:57:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T92yx-00030N-JJ; Tue, 04 Sep 2012 23:56:35 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mukesh.rathor@oracle.com>) id 1T92yw-00030I-Bp
	for Xen-devel@lists.xensource.com; Tue, 04 Sep 2012 23:56:34 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1346802987!6166912!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzI3MDk2\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14482 invoked from network); 4 Sep 2012 23:56:28 -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; 4 Sep 2012 23:56:28 -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 q84NuOvX014087
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 4 Sep 2012 23:56:25 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
	q84NuNsL023490
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 4 Sep 2012 23:56:24 GMT
Received: from abhmt105.oracle.com (abhmt105.oracle.com [141.146.116.57])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q84NuNq8025405; Tue, 4 Sep 2012 18:56:23 -0500
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 04 Sep 2012 16:56:23 -0700
Date: Tue, 4 Sep 2012 16:56:22 -0700
From: Mukesh Rathor <mukesh.rathor@oracle.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120904165622.73bdf81c@mantra.us.oracle.com>
In-Reply-To: <1345193780.30865.109.camel@zakaz.uk.xensource.com>
References: <20120815180131.24aaa5ce@mantra.us.oracle.com>
	<1345193780.30865.109.camel@zakaz.uk.xensource.com>
Organization: Oracle Corporation
X-Mailer: Claws Mail 3.7.6 (GTK+ 2.18.9; x86_64-redhat-linux-gnu)
Mime-Version: 1.0
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: "Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [[RFC PATCH 2/8]: PVH: changes related to initial
 boot and irq rewiring
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 17 Aug 2012 09:56:20 +0100
Ian Campbell <Ian.Campbell@citrix.com> wrote:

> 
> [...]
> > diff --git a/arch/x86/xen/irq.c b/arch/x86/xen/irq.c
> > index 1573376..7c7dfd1 100644
> > --- a/arch/x86/xen/irq.c
> > +++ b/arch/x86/xen/irq.c
> > @@ -100,6 +100,10 @@ PV_CALLEE_SAVE_REGS_THUNK(xen_irq_enable);
> >  
> >  static void xen_safe_halt(void)
> >  {
> > +	/* so event channel can be delivered to us, since in HVM
> > container */
> > +	if (xen_pvh_domain())
> > +		local_irq_enable();
> > +
> >  	/* Blocking includes an implicit local_irq_enable(). */
> 
> So this comment isn't true for a PVH guest? Why not? Should it be?
> 
> I'm half wondering if we couldn't use native_safe_halt here, IIRC both
> SVN and VTd handle "sti; hlt" in a sensible way on the hypervisor side
> by calling hvm_hlt

I was able to change it to use native_safe_halt. 



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

From xen-devel-bounces@lists.xen.org Tue Sep 04 23:57:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 04 Sep 2012 23:57:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T92yx-00030N-JJ; Tue, 04 Sep 2012 23:56:35 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mukesh.rathor@oracle.com>) id 1T92yw-00030I-Bp
	for Xen-devel@lists.xensource.com; Tue, 04 Sep 2012 23:56:34 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1346802987!6166912!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzI3MDk2\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14482 invoked from network); 4 Sep 2012 23:56:28 -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; 4 Sep 2012 23:56:28 -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 q84NuOvX014087
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 4 Sep 2012 23:56:25 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
	q84NuNsL023490
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 4 Sep 2012 23:56:24 GMT
Received: from abhmt105.oracle.com (abhmt105.oracle.com [141.146.116.57])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q84NuNq8025405; Tue, 4 Sep 2012 18:56:23 -0500
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 04 Sep 2012 16:56:23 -0700
Date: Tue, 4 Sep 2012 16:56:22 -0700
From: Mukesh Rathor <mukesh.rathor@oracle.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120904165622.73bdf81c@mantra.us.oracle.com>
In-Reply-To: <1345193780.30865.109.camel@zakaz.uk.xensource.com>
References: <20120815180131.24aaa5ce@mantra.us.oracle.com>
	<1345193780.30865.109.camel@zakaz.uk.xensource.com>
Organization: Oracle Corporation
X-Mailer: Claws Mail 3.7.6 (GTK+ 2.18.9; x86_64-redhat-linux-gnu)
Mime-Version: 1.0
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: "Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [[RFC PATCH 2/8]: PVH: changes related to initial
 boot and irq rewiring
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 17 Aug 2012 09:56:20 +0100
Ian Campbell <Ian.Campbell@citrix.com> wrote:

> 
> [...]
> > diff --git a/arch/x86/xen/irq.c b/arch/x86/xen/irq.c
> > index 1573376..7c7dfd1 100644
> > --- a/arch/x86/xen/irq.c
> > +++ b/arch/x86/xen/irq.c
> > @@ -100,6 +100,10 @@ PV_CALLEE_SAVE_REGS_THUNK(xen_irq_enable);
> >  
> >  static void xen_safe_halt(void)
> >  {
> > +	/* so event channel can be delivered to us, since in HVM
> > container */
> > +	if (xen_pvh_domain())
> > +		local_irq_enable();
> > +
> >  	/* Blocking includes an implicit local_irq_enable(). */
> 
> So this comment isn't true for a PVH guest? Why not? Should it be?
> 
> I'm half wondering if we couldn't use native_safe_halt here, IIRC both
> SVN and VTd handle "sti; hlt" in a sensible way on the hypervisor side
> by calling hvm_hlt

I was able to change it to use native_safe_halt. 



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

From xen-devel-bounces@lists.xen.org Wed Sep 05 01:02:30 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Sep 2012 01:02:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T940N-0005cG-Tp; Wed, 05 Sep 2012 01:02:07 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1T940L-0005J7-SR
	for xen-devel@lists.xensource.com; Wed, 05 Sep 2012 01:02:06 +0000
Received: from [85.158.143.99:7560] by server-3.bemta-4.messagelabs.com id
	2F/56-08232-D84A6405; Wed, 05 Sep 2012 01:02:05 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1346806924!27971880!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTE4NjM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27951 invoked from network); 5 Sep 2012 01:02:04 -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;
	5 Sep 2012 01:02:04 -0000
X-IronPort-AV: E=Sophos;i="4.80,371,1344211200"; d="scan'208";a="14346208"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Sep 2012 01:02: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.279.1; Wed, 5 Sep 2012 02: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 1T940J-0006Td-OB;
	Wed, 05 Sep 2012 01: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 1T940J-0003pa-IV;
	Wed, 05 Sep 2012 02:02:03 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-13646-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 5 Sep 2012 02:02:03 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.1-testing test] 13646: 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 13646 xen-4.1-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13646/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-pcipt-intel  8 debian-fixup                fail like 13581
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 13581

Tests which did not succeed, but are not blocking:
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-i386-qemuu-rhel6hvm-amd 11 leak-check/check         fail never pass
 test-amd64-i386-rhel6hvm-intel 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-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 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-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 13 guest-stop             fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-i386-i386-xl-qemuu-winxpsp3 13 guest-stop                 fail never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  d28a9ba889c0
baseline version:
 xen                  1225aff05dd2

------------------------------------------------------------
People who touched revisions under test:
  Gianluca Guida <gianluca.guida@citrix.com>
  Jan Beulich <jbeulich@novell.com>
  Jan Beulich <jbeulich@suse.com>
  Keir Fraser <keir@xen.org>
  Laszlo Ersek <lersek@redhat.com>
  Liu, Jinsong <jinsong.liu@intel.com>
  Tim Deegan <tim@xen.org>
  Wei Wang <wei.wang2@amd.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


Pushing revision :

+ branch=xen-4.1-testing
+ revision=d28a9ba889c0
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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 d28a9ba889c0
+ branch=xen-4.1-testing
+ revision=d28a9ba889c0
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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 d28a9ba889c0 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 12 changesets with 28 changes to 27 files

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

From xen-devel-bounces@lists.xen.org Wed Sep 05 01:02:30 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Sep 2012 01:02:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T940N-0005cG-Tp; Wed, 05 Sep 2012 01:02:07 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1T940L-0005J7-SR
	for xen-devel@lists.xensource.com; Wed, 05 Sep 2012 01:02:06 +0000
Received: from [85.158.143.99:7560] by server-3.bemta-4.messagelabs.com id
	2F/56-08232-D84A6405; Wed, 05 Sep 2012 01:02:05 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1346806924!27971880!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTE4NjM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27951 invoked from network); 5 Sep 2012 01:02:04 -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;
	5 Sep 2012 01:02:04 -0000
X-IronPort-AV: E=Sophos;i="4.80,371,1344211200"; d="scan'208";a="14346208"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Sep 2012 01:02: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.279.1; Wed, 5 Sep 2012 02: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 1T940J-0006Td-OB;
	Wed, 05 Sep 2012 01: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 1T940J-0003pa-IV;
	Wed, 05 Sep 2012 02:02:03 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-13646-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 5 Sep 2012 02:02:03 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.1-testing test] 13646: 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 13646 xen-4.1-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13646/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-pcipt-intel  8 debian-fixup                fail like 13581
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 13581

Tests which did not succeed, but are not blocking:
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-i386-qemuu-rhel6hvm-amd 11 leak-check/check         fail never pass
 test-amd64-i386-rhel6hvm-intel 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-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 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-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 13 guest-stop             fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-i386-i386-xl-qemuu-winxpsp3 13 guest-stop                 fail never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  d28a9ba889c0
baseline version:
 xen                  1225aff05dd2

------------------------------------------------------------
People who touched revisions under test:
  Gianluca Guida <gianluca.guida@citrix.com>
  Jan Beulich <jbeulich@novell.com>
  Jan Beulich <jbeulich@suse.com>
  Keir Fraser <keir@xen.org>
  Laszlo Ersek <lersek@redhat.com>
  Liu, Jinsong <jinsong.liu@intel.com>
  Tim Deegan <tim@xen.org>
  Wei Wang <wei.wang2@amd.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


Pushing revision :

+ branch=xen-4.1-testing
+ revision=d28a9ba889c0
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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 d28a9ba889c0
+ branch=xen-4.1-testing
+ revision=d28a9ba889c0
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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 d28a9ba889c0 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 12 changesets with 28 changes to 27 files

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

From xen-devel-bounces@lists.xen.org Wed Sep 05 02:52:07 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Sep 2012 02:52:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T95iL-0000FL-N1; Wed, 05 Sep 2012 02:51:37 +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 1T95iJ-0000FC-GQ; Wed, 05 Sep 2012 02:51:35 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-11.tower-27.messagelabs.com!1346813488!2787250!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA1MDIwMTE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18652 invoked from network); 5 Sep 2012 02:51:29 -0000
Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25)
	by server-11.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 5 Sep 2012 02:51:29 -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 2836B11CE;
	Wed,  5 Sep 2012 05:51:28 +0300 (EEST)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id 0241E2005D; Wed,  5 Sep 2012 05:51:28 +0300 (EEST)
Date: Wed, 5 Sep 2012 05:51:27 +0300
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120905025127.GI8912@reaktio.net>
References: <1346665360.25864.2.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1346665360.25864.2.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: xen-users <xen-users@lists.xen.org>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.2.0 Release Plan / TODO
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Sep 03, 2012 at 10:42:40AM +0100, Ian Campbell wrote:
> 
> tools, nice to have:
> 
>     * xl compatibility with xm:
> 


          * xl support for "monitor" command. I don't see it mentioned in xl.cfg docs.
            (the command to enable/disable access to the per-vm Qemu monitor/console 
             from VNC, which is usually accessed with ctrl-alt-2).


-- Pasi


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

From xen-devel-bounces@lists.xen.org Wed Sep 05 02:52:07 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Sep 2012 02:52:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T95iL-0000FL-N1; Wed, 05 Sep 2012 02:51:37 +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 1T95iJ-0000FC-GQ; Wed, 05 Sep 2012 02:51:35 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-11.tower-27.messagelabs.com!1346813488!2787250!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA1MDIwMTE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18652 invoked from network); 5 Sep 2012 02:51:29 -0000
Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25)
	by server-11.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 5 Sep 2012 02:51:29 -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 2836B11CE;
	Wed,  5 Sep 2012 05:51:28 +0300 (EEST)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id 0241E2005D; Wed,  5 Sep 2012 05:51:28 +0300 (EEST)
Date: Wed, 5 Sep 2012 05:51:27 +0300
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120905025127.GI8912@reaktio.net>
References: <1346665360.25864.2.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1346665360.25864.2.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: xen-users <xen-users@lists.xen.org>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.2.0 Release Plan / TODO
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Sep 03, 2012 at 10:42:40AM +0100, Ian Campbell wrote:
> 
> tools, nice to have:
> 
>     * xl compatibility with xm:
> 


          * xl support for "monitor" command. I don't see it mentioned in xl.cfg docs.
            (the command to enable/disable access to the per-vm Qemu monitor/console 
             from VNC, which is usually accessed with ctrl-alt-2).


-- Pasi


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

From xen-devel-bounces@lists.xen.org Wed Sep 05 03:01:11 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Sep 2012 03: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 1T95rA-0000ew-JD; Wed, 05 Sep 2012 03:00:44 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dongxiao.xu@intel.com>) id 1T95r9-0000eq-8x
	for xen-devel@lists.xen.org; Wed, 05 Sep 2012 03:00:43 +0000
Received: from [85.158.138.51:22989] by server-7.bemta-3.messagelabs.com id
	CF/4F-32000-850C6405; Wed, 05 Sep 2012 03:00:40 +0000
X-Env-Sender: dongxiao.xu@intel.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1346814037!20585346!1
X-Originating-IP: [143.182.124.37]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMzcgPT4gMTk0OTMy\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10635 invoked from network); 5 Sep 2012 03:00:39 -0000
Received: from mga14.intel.com (HELO mga14.intel.com) (143.182.124.37)
	by server-3.tower-174.messagelabs.com with SMTP;
	5 Sep 2012 03:00:39 -0000
Received: from azsmga001.ch.intel.com ([10.2.17.19])
	by azsmga102.ch.intel.com with ESMTP; 04 Sep 2012 20:00:37 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.80,371,1344236400"; d="scan'208";a="188881319"
Received: from fmsmsx106.amr.corp.intel.com ([10.19.9.37])
	by azsmga001.ch.intel.com with ESMTP; 04 Sep 2012 20:00:37 -0700
Received: from fmsmsx151.amr.corp.intel.com (10.19.17.220) by
	FMSMSX106.amr.corp.intel.com (10.19.9.37) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Tue, 4 Sep 2012 20:00:36 -0700
Received: from shsmsx101.ccr.corp.intel.com (10.239.4.153) by
	FMSMSX151.amr.corp.intel.com (10.19.17.220) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Tue, 4 Sep 2012 20:00:36 -0700
Received: from shsmsx102.ccr.corp.intel.com ([169.254.2.92]) by
	SHSMSX101.ccr.corp.intel.com ([169.254.1.239]) with mapi id
	14.01.0355.002; Wed, 5 Sep 2012 11:00:34 +0800
From: "Xu, Dongxiao" <dongxiao.xu@intel.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Thread-Topic: [Xen-devel] [PATCH v2] QEMU/helper2.c: Fix multiply issue for
	int and uint types
Thread-Index: AQHNhHdrsXuOhAVdY0qodBlTqsyjTpd7G+uQ
Date: Wed, 5 Sep 2012 03:00:34 +0000
Message-ID: <40776A41FC278F40B59438AD47D147A90FE2A19E@SHSMSX102.ccr.corp.intel.com>
References: <40776A41FC278F40B59438AD47D147A90FE17D93@SHSMSX102.ccr.corp.intel.com>
	<alpine.DEB.2.02.1208201621330.15568@kaball.uk.xensource.com>
	<40776A41FC278F40B59438AD47D147A90FE1D78C@SHSMSX102.ccr.corp.intel.com>
	<alpine.DEB.2.02.1208241220400.15568@kaball.uk.xensource.com>
	<40776A41FC278F40B59438AD47D147A90FE1F771@SHSMSX102.ccr.corp.intel.com>
	<alpine.DEB.2.02.1208271812020.15568@kaball.uk.xensource.com>
In-Reply-To: <alpine.DEB.2.02.1208271812020.15568@kaball.uk.xensource.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>, "Keir \(Xen.org\)" <keir@xen.org>,
	Jan Beulich <JBeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v2] QEMU/helper2.c: Fix multiply issue for
 int and uint types
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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: Tuesday, August 28, 2012 1:14 AM
> To: Xu, Dongxiao
> Cc: Stefano Stabellini; Keir (Xen.org); Jan Beulich; Ian Jackson;
> xen-devel@lists.xen.org
> Subject: RE: [Xen-devel] [PATCH v2] QEMU/helper2.c: Fix multiply issue for int
> and uint types
> 
> On Mon, 27 Aug 2012, Xu, Dongxiao wrote:
> > > -----Original Message-----
> > > From: Stefano Stabellini [mailto:stefano.stabellini@eu.citrix.com]
> > > Sent: Friday, August 24, 2012 7:25 PM
> > > To: Xu, Dongxiao
> > > Cc: Stefano Stabellini; Keir (Xen.org); Jan Beulich; Ian Jackson;
> > > xen-devel@lists.xen.org
> > > Subject: RE: [Xen-devel] [PATCH v2] QEMU/helper2.c: Fix multiply
> > > issue for int and uint types
> > >
> > >
> > > I can only speak for qemu-upstream-unstable, but I'll certainly
> > > backport the int/uint fix as soon as it gets accepted in QEMU upstream.
> > >
> > > Regarding the other patches, if any of them are for
> > > qemu-upstream-unstable, I am going to backport them only if they are
> bugfixes.
> >
> > It seems that the int/uint patch is already merged by Anthony L, see commit
> b100fcfe4966aa41d4d6908d0c4c510bcf8f82dd.
> 
> Thanks for letting me know.
> I am current away on a conference but I'll try to get the backport done by the
> end of the week nonetheless.

Hi Stefano,

It seems that the patch is still not in qemu-xen repo, could you help to backport it?

Thanks,
Dongxiao

> 
> 
> > Sorry I have been running away from Xen list for a long time and not familiar
> with the current rules.
> > For QEMU bug fixes, is it the regulation that patch developer need to fix the
> QEMU upstream, and Stefano will be in charge to backport it? Or patch
> developer needs to fix both?
> 
> That's right: fix needs to be upstream first then I'll backport it.

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

From xen-devel-bounces@lists.xen.org Wed Sep 05 03:01:11 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Sep 2012 03: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 1T95rA-0000ew-JD; Wed, 05 Sep 2012 03:00:44 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dongxiao.xu@intel.com>) id 1T95r9-0000eq-8x
	for xen-devel@lists.xen.org; Wed, 05 Sep 2012 03:00:43 +0000
Received: from [85.158.138.51:22989] by server-7.bemta-3.messagelabs.com id
	CF/4F-32000-850C6405; Wed, 05 Sep 2012 03:00:40 +0000
X-Env-Sender: dongxiao.xu@intel.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1346814037!20585346!1
X-Originating-IP: [143.182.124.37]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMzcgPT4gMTk0OTMy\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10635 invoked from network); 5 Sep 2012 03:00:39 -0000
Received: from mga14.intel.com (HELO mga14.intel.com) (143.182.124.37)
	by server-3.tower-174.messagelabs.com with SMTP;
	5 Sep 2012 03:00:39 -0000
Received: from azsmga001.ch.intel.com ([10.2.17.19])
	by azsmga102.ch.intel.com with ESMTP; 04 Sep 2012 20:00:37 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.80,371,1344236400"; d="scan'208";a="188881319"
Received: from fmsmsx106.amr.corp.intel.com ([10.19.9.37])
	by azsmga001.ch.intel.com with ESMTP; 04 Sep 2012 20:00:37 -0700
Received: from fmsmsx151.amr.corp.intel.com (10.19.17.220) by
	FMSMSX106.amr.corp.intel.com (10.19.9.37) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Tue, 4 Sep 2012 20:00:36 -0700
Received: from shsmsx101.ccr.corp.intel.com (10.239.4.153) by
	FMSMSX151.amr.corp.intel.com (10.19.17.220) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Tue, 4 Sep 2012 20:00:36 -0700
Received: from shsmsx102.ccr.corp.intel.com ([169.254.2.92]) by
	SHSMSX101.ccr.corp.intel.com ([169.254.1.239]) with mapi id
	14.01.0355.002; Wed, 5 Sep 2012 11:00:34 +0800
From: "Xu, Dongxiao" <dongxiao.xu@intel.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Thread-Topic: [Xen-devel] [PATCH v2] QEMU/helper2.c: Fix multiply issue for
	int and uint types
Thread-Index: AQHNhHdrsXuOhAVdY0qodBlTqsyjTpd7G+uQ
Date: Wed, 5 Sep 2012 03:00:34 +0000
Message-ID: <40776A41FC278F40B59438AD47D147A90FE2A19E@SHSMSX102.ccr.corp.intel.com>
References: <40776A41FC278F40B59438AD47D147A90FE17D93@SHSMSX102.ccr.corp.intel.com>
	<alpine.DEB.2.02.1208201621330.15568@kaball.uk.xensource.com>
	<40776A41FC278F40B59438AD47D147A90FE1D78C@SHSMSX102.ccr.corp.intel.com>
	<alpine.DEB.2.02.1208241220400.15568@kaball.uk.xensource.com>
	<40776A41FC278F40B59438AD47D147A90FE1F771@SHSMSX102.ccr.corp.intel.com>
	<alpine.DEB.2.02.1208271812020.15568@kaball.uk.xensource.com>
In-Reply-To: <alpine.DEB.2.02.1208271812020.15568@kaball.uk.xensource.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>, "Keir \(Xen.org\)" <keir@xen.org>,
	Jan Beulich <JBeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v2] QEMU/helper2.c: Fix multiply issue for
 int and uint types
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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: Tuesday, August 28, 2012 1:14 AM
> To: Xu, Dongxiao
> Cc: Stefano Stabellini; Keir (Xen.org); Jan Beulich; Ian Jackson;
> xen-devel@lists.xen.org
> Subject: RE: [Xen-devel] [PATCH v2] QEMU/helper2.c: Fix multiply issue for int
> and uint types
> 
> On Mon, 27 Aug 2012, Xu, Dongxiao wrote:
> > > -----Original Message-----
> > > From: Stefano Stabellini [mailto:stefano.stabellini@eu.citrix.com]
> > > Sent: Friday, August 24, 2012 7:25 PM
> > > To: Xu, Dongxiao
> > > Cc: Stefano Stabellini; Keir (Xen.org); Jan Beulich; Ian Jackson;
> > > xen-devel@lists.xen.org
> > > Subject: RE: [Xen-devel] [PATCH v2] QEMU/helper2.c: Fix multiply
> > > issue for int and uint types
> > >
> > >
> > > I can only speak for qemu-upstream-unstable, but I'll certainly
> > > backport the int/uint fix as soon as it gets accepted in QEMU upstream.
> > >
> > > Regarding the other patches, if any of them are for
> > > qemu-upstream-unstable, I am going to backport them only if they are
> bugfixes.
> >
> > It seems that the int/uint patch is already merged by Anthony L, see commit
> b100fcfe4966aa41d4d6908d0c4c510bcf8f82dd.
> 
> Thanks for letting me know.
> I am current away on a conference but I'll try to get the backport done by the
> end of the week nonetheless.

Hi Stefano,

It seems that the patch is still not in qemu-xen repo, could you help to backport it?

Thanks,
Dongxiao

> 
> 
> > Sorry I have been running away from Xen list for a long time and not familiar
> with the current rules.
> > For QEMU bug fixes, is it the regulation that patch developer need to fix the
> QEMU upstream, and Stefano will be in charge to backport it? Or patch
> developer needs to fix both?
> 
> That's right: fix needs to be upstream first then I'll backport it.

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

From xen-devel-bounces@lists.xen.org Wed Sep 05 03:03:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Sep 2012 03:03:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T95t5-0000l4-3M; Wed, 05 Sep 2012 03:02:43 +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 1T95t3-0000kt-NT
	for xen-devel@lists.xen.org; Wed, 05 Sep 2012 03:02:41 +0000
Received: from [85.158.143.99:25155] by server-2.bemta-4.messagelabs.com id
	80/6F-21239-1D0C6405; Wed, 05 Sep 2012 03:02:41 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-16.tower-216.messagelabs.com!1346814160!17357569!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA1MDIwMTE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15126 invoked from network); 5 Sep 2012 03:02:40 -0000
Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25)
	by server-16.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 5 Sep 2012 03:02:40 -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 9F7EA2A18;
	Wed,  5 Sep 2012 06:02:39 +0300 (EEST)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id 630A22005D; Wed,  5 Sep 2012 06:02:39 +0300 (EEST)
Date: Wed, 5 Sep 2012 06:02:39 +0300
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: xen-devel@lists.xen.org
Message-ID: <20120905030239.GJ8912@reaktio.net>
MIME-Version: 1.0
Content-Disposition: inline
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: Roger Pau Monne <roger.pau@citrix.com>
Subject: [Xen-devel] Xen 4.2 (missing) pygrub support for ext4 on
 rhel5/centos5 e4fsprogs..
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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,

Roger: If I didn't mix up people we had a chat about this at XenSummit :) 
so here's some info about the ext4 stuff on rhel5/centos5.

# yum search e4fsprogs
e4fsprogs.x86_64 : Utilities for managing the fourth extended (ext4) filesystem
e4fsprogs-devel.i386 : Ext4 filesystem-specific static libraries and headers
e4fsprogs-devel.x86_64 : Ext4 filesystem-specific static libraries and headers
e4fsprogs-libs.i386 : Ext4 filesystem-specific static libraries and headers
e4fsprogs-libs.x86_64 : Ext4 filesystem-specific static libraries and headers

# rpm -ql e4fsprogs-libs.i386
/lib/libe4p.so.2
/lib/libe4p.so.2.3
/lib/libext4fs.so.2
/lib/libext4fs.so.2.4

# rpm -ql e4fsprogs-libs.x86_64
/lib64/libe4p.so.2
/lib64/libe4p.so.2.3
/lib64/libext4fs.so.2
/lib64/libext4fs.so.2.4

# rpm -ql e4fsprogs-devel.i386
/usr/include/e4p
/usr/include/e4p/e2p.h
/usr/include/ext4fs
/usr/include/ext4fs/bitops.h
/usr/include/ext4fs/ext2_err.h
/usr/include/ext4fs/ext2_ext_attr.h
/usr/include/ext4fs/ext2_fs.h
/usr/include/ext4fs/ext2_io.h
/usr/include/ext4fs/ext2_types-i386.h
/usr/include/ext4fs/ext2_types.h
/usr/include/ext4fs/ext2fs.h
/usr/include/ext4fs/ext3_extents.h
/usr/include/ext4fs/tdb.h
/usr/lib/libe4p.a
/usr/lib/libe4p.so
/usr/lib/libext4fs.a
/usr/lib/libext4fs.so
/usr/lib/pkgconfig/e4p.pc
/usr/lib/pkgconfig/ext4fs.pc
/usr/share/info/libext4fs.info.gz

# rpm -ql e4fsprogs-devel.x86_64
/usr/include/e4p
/usr/include/e4p/e2p.h
/usr/include/ext4fs
/usr/include/ext4fs/bitops.h
/usr/include/ext4fs/ext2_err.h
/usr/include/ext4fs/ext2_ext_attr.h
/usr/include/ext4fs/ext2_fs.h
/usr/include/ext4fs/ext2_io.h
/usr/include/ext4fs/ext2_types-x86_64.h
/usr/include/ext4fs/ext2_types.h
/usr/include/ext4fs/ext2fs.h
/usr/include/ext4fs/ext3_extents.h
/usr/include/ext4fs/tdb.h
/usr/lib64/libe4p.a
/usr/lib64/libe4p.so
/usr/lib64/libext4fs.a
/usr/lib64/libext4fs.so
/usr/lib64/pkgconfig/e4p.pc
/usr/lib64/pkgconfig/ext4fs.pc
/usr/share/info/libext4fs.info.gz


And then some info about the included files in the stock rhel5/centos5 Xen rpms (Xen 3.1.2),
where pygrub does support ext4 using e4fsprogs-libs:


# rpm -ql xen-libs | grep fsimage
/usr/lib64/fs/ext2fs-lib/fsimage.so
/usr/lib64/fs/fat/fsimage.so
/usr/lib64/fs/iso9660/fsimage.so
/usr/lib64/fs/reiserfs/fsimage.so
/usr/lib64/fs/ufs/fsimage.so
/usr/lib64/libfsimage.so.1.0
/usr/lib64/libfsimage.so.1.0.0
/usr/lib/fs/ext2fs-lib/fsimage.so
/usr/lib/fs/fat/fsimage.so
/usr/lib/fs/iso9660/fsimage.so
/usr/lib/fs/reiserfs/fsimage.so
/usr/lib/fs/ufs/fsimage.so
/usr/lib/libfsimage.so.1.0
/usr/lib/libfsimage.so.1.0.0

# ldd /usr/lib/fs/ext2fs-lib/fsimage.so
        linux-gate.so.1 =>  (0xffffe000)
        libfsimage.so.1.0 => /usr/lib/libfsimage.so.1.0 (0xf7f09000)
        libext4fs.so.2 => /lib/libext4fs.so.2 (0xf7edb000)
        libc.so.6 => /lib/libc.so.6 (0xf7d82000)
        libpthread.so.0 => /lib/libpthread.so.0 (0xf7d68000)
        libcom_err.so.2 => /lib/libcom_err.so.2 (0xf7d64000)
        /lib/ld-linux.so.2 (0x00778000)


# ldd /usr/lib64/fs/ext2fs-lib/fsimage.so
        linux-vdso.so.1 =>  (0x00007fff9cffd000)
        libfsimage.so.1.0 => /usr/lib64/libfsimage.so.1.0 (0x00002adbbef0e000)
        libext4fs.so.2 => /lib64/libext4fs.so.2 (0x00002adbbf111000)
        libc.so.6 => /lib64/libc.so.6 (0x00002adbbf340000)
        libpthread.so.0 => /lib64/libpthread.so.0 (0x00002adbbf697000)
        libcom_err.so.2 => /lib64/libcom_err.so.2 (0x00002adbbf8b2000)
        /lib64/ld-linux-x86-64.so.2 (0x00000039dce00000)

So el5 stock Xen rpms provide ext2fs-lib/fsimage.so, which is linked against libext4fs.so.2,
and pygrub loads/uses fsimage.so.


Can you guys please post the patch/hack you're currently using with XenServer/XCP,
so we can decide what'd be the best way to get Xen 4.2 pygrub supporting ext4 also on el5 ? 


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 Sep 05 03:03:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Sep 2012 03:03:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T95t5-0000l4-3M; Wed, 05 Sep 2012 03:02:43 +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 1T95t3-0000kt-NT
	for xen-devel@lists.xen.org; Wed, 05 Sep 2012 03:02:41 +0000
Received: from [85.158.143.99:25155] by server-2.bemta-4.messagelabs.com id
	80/6F-21239-1D0C6405; Wed, 05 Sep 2012 03:02:41 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-16.tower-216.messagelabs.com!1346814160!17357569!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA1MDIwMTE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15126 invoked from network); 5 Sep 2012 03:02:40 -0000
Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25)
	by server-16.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 5 Sep 2012 03:02:40 -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 9F7EA2A18;
	Wed,  5 Sep 2012 06:02:39 +0300 (EEST)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id 630A22005D; Wed,  5 Sep 2012 06:02:39 +0300 (EEST)
Date: Wed, 5 Sep 2012 06:02:39 +0300
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: xen-devel@lists.xen.org
Message-ID: <20120905030239.GJ8912@reaktio.net>
MIME-Version: 1.0
Content-Disposition: inline
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: Roger Pau Monne <roger.pau@citrix.com>
Subject: [Xen-devel] Xen 4.2 (missing) pygrub support for ext4 on
 rhel5/centos5 e4fsprogs..
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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,

Roger: If I didn't mix up people we had a chat about this at XenSummit :) 
so here's some info about the ext4 stuff on rhel5/centos5.

# yum search e4fsprogs
e4fsprogs.x86_64 : Utilities for managing the fourth extended (ext4) filesystem
e4fsprogs-devel.i386 : Ext4 filesystem-specific static libraries and headers
e4fsprogs-devel.x86_64 : Ext4 filesystem-specific static libraries and headers
e4fsprogs-libs.i386 : Ext4 filesystem-specific static libraries and headers
e4fsprogs-libs.x86_64 : Ext4 filesystem-specific static libraries and headers

# rpm -ql e4fsprogs-libs.i386
/lib/libe4p.so.2
/lib/libe4p.so.2.3
/lib/libext4fs.so.2
/lib/libext4fs.so.2.4

# rpm -ql e4fsprogs-libs.x86_64
/lib64/libe4p.so.2
/lib64/libe4p.so.2.3
/lib64/libext4fs.so.2
/lib64/libext4fs.so.2.4

# rpm -ql e4fsprogs-devel.i386
/usr/include/e4p
/usr/include/e4p/e2p.h
/usr/include/ext4fs
/usr/include/ext4fs/bitops.h
/usr/include/ext4fs/ext2_err.h
/usr/include/ext4fs/ext2_ext_attr.h
/usr/include/ext4fs/ext2_fs.h
/usr/include/ext4fs/ext2_io.h
/usr/include/ext4fs/ext2_types-i386.h
/usr/include/ext4fs/ext2_types.h
/usr/include/ext4fs/ext2fs.h
/usr/include/ext4fs/ext3_extents.h
/usr/include/ext4fs/tdb.h
/usr/lib/libe4p.a
/usr/lib/libe4p.so
/usr/lib/libext4fs.a
/usr/lib/libext4fs.so
/usr/lib/pkgconfig/e4p.pc
/usr/lib/pkgconfig/ext4fs.pc
/usr/share/info/libext4fs.info.gz

# rpm -ql e4fsprogs-devel.x86_64
/usr/include/e4p
/usr/include/e4p/e2p.h
/usr/include/ext4fs
/usr/include/ext4fs/bitops.h
/usr/include/ext4fs/ext2_err.h
/usr/include/ext4fs/ext2_ext_attr.h
/usr/include/ext4fs/ext2_fs.h
/usr/include/ext4fs/ext2_io.h
/usr/include/ext4fs/ext2_types-x86_64.h
/usr/include/ext4fs/ext2_types.h
/usr/include/ext4fs/ext2fs.h
/usr/include/ext4fs/ext3_extents.h
/usr/include/ext4fs/tdb.h
/usr/lib64/libe4p.a
/usr/lib64/libe4p.so
/usr/lib64/libext4fs.a
/usr/lib64/libext4fs.so
/usr/lib64/pkgconfig/e4p.pc
/usr/lib64/pkgconfig/ext4fs.pc
/usr/share/info/libext4fs.info.gz


And then some info about the included files in the stock rhel5/centos5 Xen rpms (Xen 3.1.2),
where pygrub does support ext4 using e4fsprogs-libs:


# rpm -ql xen-libs | grep fsimage
/usr/lib64/fs/ext2fs-lib/fsimage.so
/usr/lib64/fs/fat/fsimage.so
/usr/lib64/fs/iso9660/fsimage.so
/usr/lib64/fs/reiserfs/fsimage.so
/usr/lib64/fs/ufs/fsimage.so
/usr/lib64/libfsimage.so.1.0
/usr/lib64/libfsimage.so.1.0.0
/usr/lib/fs/ext2fs-lib/fsimage.so
/usr/lib/fs/fat/fsimage.so
/usr/lib/fs/iso9660/fsimage.so
/usr/lib/fs/reiserfs/fsimage.so
/usr/lib/fs/ufs/fsimage.so
/usr/lib/libfsimage.so.1.0
/usr/lib/libfsimage.so.1.0.0

# ldd /usr/lib/fs/ext2fs-lib/fsimage.so
        linux-gate.so.1 =>  (0xffffe000)
        libfsimage.so.1.0 => /usr/lib/libfsimage.so.1.0 (0xf7f09000)
        libext4fs.so.2 => /lib/libext4fs.so.2 (0xf7edb000)
        libc.so.6 => /lib/libc.so.6 (0xf7d82000)
        libpthread.so.0 => /lib/libpthread.so.0 (0xf7d68000)
        libcom_err.so.2 => /lib/libcom_err.so.2 (0xf7d64000)
        /lib/ld-linux.so.2 (0x00778000)


# ldd /usr/lib64/fs/ext2fs-lib/fsimage.so
        linux-vdso.so.1 =>  (0x00007fff9cffd000)
        libfsimage.so.1.0 => /usr/lib64/libfsimage.so.1.0 (0x00002adbbef0e000)
        libext4fs.so.2 => /lib64/libext4fs.so.2 (0x00002adbbf111000)
        libc.so.6 => /lib64/libc.so.6 (0x00002adbbf340000)
        libpthread.so.0 => /lib64/libpthread.so.0 (0x00002adbbf697000)
        libcom_err.so.2 => /lib64/libcom_err.so.2 (0x00002adbbf8b2000)
        /lib64/ld-linux-x86-64.so.2 (0x00000039dce00000)

So el5 stock Xen rpms provide ext2fs-lib/fsimage.so, which is linked against libext4fs.so.2,
and pygrub loads/uses fsimage.so.


Can you guys please post the patch/hack you're currently using with XenServer/XCP,
so we can decide what'd be the best way to get Xen 4.2 pygrub supporting ext4 also on el5 ? 


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 Sep 05 04:42:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Sep 2012 04:42:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T97RV-0001cP-63; Wed, 05 Sep 2012 04:42: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 1T97RT-0001cK-Sh
	for xen-devel@lists.xensource.com; Wed, 05 Sep 2012 04:42:20 +0000
Received: from [85.158.139.83:21860] by server-10.bemta-5.messagelabs.com id
	39/84-10969-B28D6405; Wed, 05 Sep 2012 04:42:19 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1346820138!25880272!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTE4NjM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19286 invoked from network); 5 Sep 2012 04:42:18 -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 Sep 2012 04:42:18 -0000
X-IronPort-AV: E=Sophos;i="4.80,372,1344211200"; d="scan'208";a="14347494"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Sep 2012 04:41: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.279.1; Wed, 5 Sep 2012 05:41: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 1T97Qu-0007u1-S5;
	Wed, 05 Sep 2012 04:41:44 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1T97Qu-0001GY-Mv;
	Wed, 05 Sep 2012 05:41:44 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-13647-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 5 Sep 2012 05:41:44 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13647: 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 13647 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13647/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore           fail pass in 13645

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail like 13645
 test-i386-i386-xl-qemuu-winxpsp3  9 guest-localmigrate         fail like 13645
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail like 13645
 test-amd64-amd64-xl-sedf-pin 12 guest-saverestore.2 fail in 13645 blocked in 13647

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

version targeted for testing:
 xen                  9dc729b75595
baseline version:
 xen                  9dc729b75595

jobs:
 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                                 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                                     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 Sep 05 04:42:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Sep 2012 04:42:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T97RV-0001cP-63; Wed, 05 Sep 2012 04:42: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 1T97RT-0001cK-Sh
	for xen-devel@lists.xensource.com; Wed, 05 Sep 2012 04:42:20 +0000
Received: from [85.158.139.83:21860] by server-10.bemta-5.messagelabs.com id
	39/84-10969-B28D6405; Wed, 05 Sep 2012 04:42:19 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1346820138!25880272!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTE4NjM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19286 invoked from network); 5 Sep 2012 04:42:18 -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 Sep 2012 04:42:18 -0000
X-IronPort-AV: E=Sophos;i="4.80,372,1344211200"; d="scan'208";a="14347494"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Sep 2012 04:41: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.279.1; Wed, 5 Sep 2012 05:41: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 1T97Qu-0007u1-S5;
	Wed, 05 Sep 2012 04:41:44 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1T97Qu-0001GY-Mv;
	Wed, 05 Sep 2012 05:41:44 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-13647-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 5 Sep 2012 05:41:44 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13647: 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 13647 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13647/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore           fail pass in 13645

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail like 13645
 test-i386-i386-xl-qemuu-winxpsp3  9 guest-localmigrate         fail like 13645
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail like 13645
 test-amd64-amd64-xl-sedf-pin 12 guest-saverestore.2 fail in 13645 blocked in 13647

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

version targeted for testing:
 xen                  9dc729b75595
baseline version:
 xen                  9dc729b75595

jobs:
 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                                 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                                     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 Sep 05 08:34:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Sep 2012 08:34:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9B3A-0004ex-Hx; Wed, 05 Sep 2012 08:33: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 1T9B39-0004es-80
	for xen-devel@lists.xen.org; Wed, 05 Sep 2012 08:33:27 +0000
Received: from [85.158.138.51:11803] by server-9.bemta-3.messagelabs.com id
	1E/41-15390-65E07405; Wed, 05 Sep 2012 08:33:26 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1346834002!19820524!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTE4NjM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21121 invoked from network); 5 Sep 2012 08:33:23 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Sep 2012 08:33:23 -0000
X-IronPort-AV: E=Sophos;i="4.80,372,1344211200"; d="scan'208";a="14350946"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Sep 2012 08:33: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.279.1; Wed, 5 Sep 2012
	09:33:22 +0100
Message-ID: <1346834000.17325.4.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, 5 Sep 2012 09:33:20 +0100
In-Reply-To: <20120904191229.GH8912@reaktio.net>
References: <20120902053549.GF8912@reaktio.net>
	<1346667053.25864.21.camel@zakaz.uk.xensource.com>
	<20120904191229.GH8912@reaktio.net>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] xl.cfg: gfx_passthru documentation
 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="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gVHVlLCAyMDEyLTA5LTA0IGF0IDIwOjEyICswMTAwLCBQYXNpIEvDpHJra8OkaW5lbiB3cm90
ZToKPiBPbiBNb24sIFNlcCAwMywgMjAxMiBhdCAxMToxMDo1M0FNICswMTAwLCBJYW4gQ2FtcGJl
bGwgd3JvdGU6Cj4gPiBPbiBTdW4sIDIwMTItMDktMDIgYXQgMDY6MzUgKzAxMDAsIFBhc2kgS8Ok
cmtrw6RpbmVuIHdyb3RlOgo+ID4gPiBIZWxsbywKPiA+ID4gCj4gPiA+IHhsLmNmZy5wb2QuNSBk
b2N1bWVudGF0aW9uIGltcHJvdmVtZW50czoKPiA+ID4gCj4gPiA+IC0gZ2Z4X3Bhc3N0aHJ1OiBE
b2N1bWVudCBnZnhfcGFzc3RocnUgbWFrZXMgdGhlIEdQVSBiZWNvbWUgcHJpbWFyeSBpbiB0aGUg
Z3Vlc3QKPiA+ID4gICBhbmQgb3RoZXIgZ2VuZXJpYyBpbmZvIGFib3V0IGdmeF9wYXNzdGhydS4K
PiA+ID4gCj4gPiA+IAo+ID4gPiBTaWduZWQtb2ZmLWJ5OiBQYXNpIEvDpHJra8OkaW5lbiA8cGFz
aWtAaWtpLmZpPgo+ID4gPiAtLS0gZG9jcy9tYW4veGwuY2ZnLnBvZC41Lm9yaWcxIDIwMTItMDkt
MDIgMDc6MTY6MzkuMzE2NzgyMTU4ICswMzAwCj4gPiA+ICsrKyBkb2NzL21hbi94bC5jZmcucG9k
LjUgICAgICAgMjAxMi0wOS0wMiAwODoyNjo0MC4wODE2MzkwODcgKzAzMDAKPiA+ID4gQEAgLTk2
OCw3ICs5NjgsNDMgQEAKPiA+ID4gIAo+ID4gPiAgPWl0ZW0gQjxnZnhfcGFzc3RocnU9Qk9PTEVB
Tj4KPiA+ID4gIAo+ID4gPiAtRW5hYmxlIGdyYXBoaWNzIGRldmljZSBQQ0kgcGFzc3Rocm91Z2gu
IFhYWCB3aGljaCBkZXZpY2UgaXMgcGFzc2VkIHRocm91Z2ggPwo+ID4gPiArRW5hYmxlIGdyYXBo
aWNzIGRldmljZSBQQ0kgcGFzc3Rocm91Z2guIFRoaXMgb3B0aW9uIG1ha2VzIHRoZSBwYXNzdGhy
dQo+ID4gPiArZ3JhcGhpY3MgY2FyZCBiZWNvbWUgcHJpbWFyeSBncmFwaGljcyBjYXJkIGluIHRo
ZSBWTSwKPiA+IAo+ID4gVGhlIG9wdGlvbiBpcyBzbGlnaHRseSBtaXNuYW1lZCB0aGVuIEkgZ3Vl
c3MsIGEgYmV0dGVyIG5hbWUgd291bGQgaGF2ZQo+ID4gYmVlbiBnZnhfcGFzc3RocnVfcHJpbWFy
eT8gb2ggd2VsbCwgd2UgYXJlIHN0dWNrIHdpdGggaXQgbm93Lgo+ID4gCj4gCj4gWWVhaC4uIEkg
dGhpbmsgZWFybGllciBnZnhfcGFzc3RocnUgd2Fzbid0IGEgYm9vbGVhbiwgYnV0IGFuIGludGVn
ZXIsIHRvIGNob29zZSB0aGUgbW9kZS4KCk9oLCBkbyB5b3UgaGFwcGVuIHRvIGtub3cgd2hhdCB0
aGUgbWVhbmluZ3Mgd2VyZT8KCj4gPiA+ICBzbyB0aGUgUWVtdSBlbXVsYXRlZCAKPiA+ID4gK2dy
YXBoaWNzIGFkYXB0ZXIgaXMgZGlzYWJsZWQsIGFuZCB0aGUgVk5DIGNvbnNvbGUgZm9yIHRoZSBW
TSB3b24ndCBoYXZlCj4gPiA+ICthbnkgZ3JhcGhpY3Mgb3V0cHV0LiBBbGwgZ3JhcGhpY3Mgb3V0
cHV0LCBpbmNsdWRpbmcgYm9vdCB0aW1lIFFlbXUgQklPUwo+ID4gPiArbWVzc2FnZXMgZnJvbSB0
aGUgVk0sIHdpbGwgZ28gdG8gdGhlIHBoeXNpY2FsIG91dHB1dHMgb2YgdGhlIHBhc3NlZCB0aHJ1
Cj4gPiA+ICtwaHlzaWNhbCBncmFwaGljcyBjYXJkLgo+ID4gPiArCj4gPiA+ICtHcmFwaGljcyBj
YXJkIFBDSSBkZXZpY2UgdG8gcGFzc3RocnUgaXMgY2hvc2VuIHdpdGggQjxwY2k+IG9wdGlvbiwg
Cj4gPiA+ICtleGFjdGx5IGluIHRoZSBzYW1lIHdheSBhcyBub3JtYWwgWGVuIFBDSSBkZXZpY2Ug
cGFzc3RocnUvYXNzaWdubWVudCBpcyBkb25lLiAKPiA+ID4gK05vdGUgdGhhdCBnZnhfcGFzc3Ro
cnUgZG9lc24ndCBkbyBhbnkga2luZCBvZiBzaGFyaW5nCj4gPiA+ICtvZiB0aGUgR1BVLCBzbyB5
b3UgY2FuIG9ubHkgYXNzaWduIHRoZSBHUFUgdG8gb25lIHNpbmdsZSBWTSBhdCBhIHRpbWUuCj4g
PiA+ICsKPiA+ID4gK2dmeF9wYXNzdGhydSBhbHNvIGVuYWJsZXMgdmFyaW91cyBsZWdhY3kgVkdB
IG1lbW9yeSByYW5nZXMsIEJBUnMsIE1NSU9zLCAKPiA+ID4gK2FuZCBpb3BvcnRzIHRvIGJlIHBh
c3NlZCB0aHJ1IHRvIHRoZSBWTSwgc2luY2UgdGhvc2UgYXJlIHJlcXVpcmVkCj4gPiA+ICtmb3Ig
Y29ycmVjdCBvcGVyYXRpb24gb2YgdGhpbmdzIGxpa2UgVkdBIEJJT1MsIHRleHQgbW9kZSwgVkJF
LCBldGMuCj4gPiA+ICsKPiA+ID4gK0VuYWJsaW5nIGdmeF9wYXNzdGhydSBvcHRpb24gYWxzbyBj
b3BpZXMgdGhlIHBoeXNpY2FsIGdyYXBoaWNzIGNhcmQgCj4gPiA+ICt2aWRlbyBiaW9zIHRvIHRo
ZSBndWVzdCBtZW1vcnksIGFuZCBleGVjdXRlcyB0aGUgdmJpb3MgaW4gdGhlIGd1ZXN0IAo+ID4g
Cj4gPiAiQklPUyIgYW5kIChJIGV4cGVjdCkgIlZCSU9TIj8KPiA+IAo+IAo+IHZpZGVvIGJpb3Mg
PT0gdmJpb3MsIG9yIGRpZCB5b3UgYXNrIHNvbWV0aGluZyBlbHNlPyAKCkkgd2FzIGp1c3QgY29t
bWVudGluZyBvbiB0aGUgY2FwaXRhbGlzYXRpb24gZGlmZmVyaW5nIGZyb20gb3RoZXIKbWVudGlv
bnMgb2YgdGhlIEJJT1MuCgo+ID4gPiArdG8gZ2V0IHRoZSBncmFwaGljcyBjYXJkIGluaXRpYWxp
emVkLgo+ID4gPiArCj4gPiA+ICtNb3N0IGdyYXBoaWNzIGFkYXB0ZXJzIHJlcXVpcmUgdmVuZG9y
IHNwZWNpZmljIHR3ZWFrcyBmb3IgcHJvcGVybHkKPiA+ID4gK3dvcmtpbmcgZ3JhcGhpY3MgcGFz
c3RocnUuIFhlbiBjdXJyZW50bHkgaW5jbHVkZXMgbmVjZXNzYXJ5IHR3ZWFrcwo+ID4gPiArZm9y
IEludGVsIElHRCAoSW50ZWdyYXRlZCBHcmFwaGljcyBEZXZpY2UpIEdQVXMuICAKPiA+ID4gKwo+
ID4gPiArU3VwcG9ydCBmb3IgQU1EL052aWRpYSBnZnhfcGFzc3RocnUgaXMgbm90IHlldCBtZXJn
ZWQgdG8gWGVuLAo+ID4gPiArYnV0IHRoZXJlIGFyZSBvdXQtb2YtdHJlZSBwYXRjaGVzIGF2YWls
YWJsZS4KPiA+IAo+ID4gSWYgdGhlcmUgaXMgYSBjb21wcmVoZW5zaXZlIGxpc3Qgb2Ygc3VwcG9y
dGVkL25vdC1zdXBwb3J0ZWQgZGV2aWNlcyBvbgo+ID4gdGhlIHdpa2kgdGhlbiBJIHRoaW5rIGEg
cmVmZXJlbmNlIGhlcmUgd291bGQgYmUgbW9yZSB1c2VmdWwgdGhhbiB0aGVzZQo+ID4gdHdvIGJy
aWVmIHBhcmFncmFwaHMuCj4gPiAKPiAKPiBXZSBoYXZlIGEgbGlzdCwgYnV0IGl0J3Mgbm90IHVw
LXRvLWRhdGUgdW5mb3J0dW5hdGVseToKPiBodHRwOi8vd2lraS54ZW4ub3JnL3dpa2kvWGVuVkdB
UGFzc3Rocm91Z2hUZXN0ZWRBZGFwdGVycwoKSSB0aGluayBpdCBpcyB3b3J0aCByZWZlcmVuY2lu
ZyBpdCwgYW5kIHBlcmhhcHMgYWRkaW5nIGEgbm90ZSB0byB0aGUKcGFnZSBpdHNlbGYgcmVnYXJk
aW5nIGl0cyBmcmVzaG5lc3MgKGFuZCB0aGVuIHdvcmtpbmcgdG8gaW1wcm92ZSBpdCwgb2YKY291
cnNlIDstKSkKCj4gPiBJbiBwYXJ0aWN1bGFyIHRoZSBzZWNvbmQgaXNuJ3QgdmVyeSB1c2VmdWwg
d2l0aG91dCBsaW5rcyBhbmQgdGhvc2UgdGVuZAo+ID4gdG8gYmVjb21lIG91dCBvZiBkYXRlIGlu
IGRvY3MgSU1FLCBJIHdvdWxkIHRlbmQgdG8gb21pdCB0aGlzIGZyb20gaGVyZQo+ID4gYW5kIGlu
c3RlYWQgaW5jbHVkZSB0aGVtIGluIHRoZSB3aWtpIHdoZXJlIHRoZXkgY2FuIGJlIGtlcHQgdXAg
dG8gZGF0ZQo+ID4KPiAKPiBPay4gSSdsbCBmaXggdGhhdCwgYW5kIGFkZCBhIGxpbmsgdG86Cj4g
aHR0cDovL3dpa2kueGVuLm9yZy93aWtpL1hlblZHQVBhc3N0aHJvdWdoCgpUaGFua3MuCgpJYW4u
CgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRl
dmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwOi8vbGlzdHMueGVu
Lm9yZy94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xen.org Wed Sep 05 08:34:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Sep 2012 08:34:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9B3A-0004ex-Hx; Wed, 05 Sep 2012 08:33: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 1T9B39-0004es-80
	for xen-devel@lists.xen.org; Wed, 05 Sep 2012 08:33:27 +0000
Received: from [85.158.138.51:11803] by server-9.bemta-3.messagelabs.com id
	1E/41-15390-65E07405; Wed, 05 Sep 2012 08:33:26 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1346834002!19820524!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTE4NjM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21121 invoked from network); 5 Sep 2012 08:33:23 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Sep 2012 08:33:23 -0000
X-IronPort-AV: E=Sophos;i="4.80,372,1344211200"; d="scan'208";a="14350946"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Sep 2012 08:33: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.279.1; Wed, 5 Sep 2012
	09:33:22 +0100
Message-ID: <1346834000.17325.4.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, 5 Sep 2012 09:33:20 +0100
In-Reply-To: <20120904191229.GH8912@reaktio.net>
References: <20120902053549.GF8912@reaktio.net>
	<1346667053.25864.21.camel@zakaz.uk.xensource.com>
	<20120904191229.GH8912@reaktio.net>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] xl.cfg: gfx_passthru documentation
 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="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gVHVlLCAyMDEyLTA5LTA0IGF0IDIwOjEyICswMTAwLCBQYXNpIEvDpHJra8OkaW5lbiB3cm90
ZToKPiBPbiBNb24sIFNlcCAwMywgMjAxMiBhdCAxMToxMDo1M0FNICswMTAwLCBJYW4gQ2FtcGJl
bGwgd3JvdGU6Cj4gPiBPbiBTdW4sIDIwMTItMDktMDIgYXQgMDY6MzUgKzAxMDAsIFBhc2kgS8Ok
cmtrw6RpbmVuIHdyb3RlOgo+ID4gPiBIZWxsbywKPiA+ID4gCj4gPiA+IHhsLmNmZy5wb2QuNSBk
b2N1bWVudGF0aW9uIGltcHJvdmVtZW50czoKPiA+ID4gCj4gPiA+IC0gZ2Z4X3Bhc3N0aHJ1OiBE
b2N1bWVudCBnZnhfcGFzc3RocnUgbWFrZXMgdGhlIEdQVSBiZWNvbWUgcHJpbWFyeSBpbiB0aGUg
Z3Vlc3QKPiA+ID4gICBhbmQgb3RoZXIgZ2VuZXJpYyBpbmZvIGFib3V0IGdmeF9wYXNzdGhydS4K
PiA+ID4gCj4gPiA+IAo+ID4gPiBTaWduZWQtb2ZmLWJ5OiBQYXNpIEvDpHJra8OkaW5lbiA8cGFz
aWtAaWtpLmZpPgo+ID4gPiAtLS0gZG9jcy9tYW4veGwuY2ZnLnBvZC41Lm9yaWcxIDIwMTItMDkt
MDIgMDc6MTY6MzkuMzE2NzgyMTU4ICswMzAwCj4gPiA+ICsrKyBkb2NzL21hbi94bC5jZmcucG9k
LjUgICAgICAgMjAxMi0wOS0wMiAwODoyNjo0MC4wODE2MzkwODcgKzAzMDAKPiA+ID4gQEAgLTk2
OCw3ICs5NjgsNDMgQEAKPiA+ID4gIAo+ID4gPiAgPWl0ZW0gQjxnZnhfcGFzc3RocnU9Qk9PTEVB
Tj4KPiA+ID4gIAo+ID4gPiAtRW5hYmxlIGdyYXBoaWNzIGRldmljZSBQQ0kgcGFzc3Rocm91Z2gu
IFhYWCB3aGljaCBkZXZpY2UgaXMgcGFzc2VkIHRocm91Z2ggPwo+ID4gPiArRW5hYmxlIGdyYXBo
aWNzIGRldmljZSBQQ0kgcGFzc3Rocm91Z2guIFRoaXMgb3B0aW9uIG1ha2VzIHRoZSBwYXNzdGhy
dQo+ID4gPiArZ3JhcGhpY3MgY2FyZCBiZWNvbWUgcHJpbWFyeSBncmFwaGljcyBjYXJkIGluIHRo
ZSBWTSwKPiA+IAo+ID4gVGhlIG9wdGlvbiBpcyBzbGlnaHRseSBtaXNuYW1lZCB0aGVuIEkgZ3Vl
c3MsIGEgYmV0dGVyIG5hbWUgd291bGQgaGF2ZQo+ID4gYmVlbiBnZnhfcGFzc3RocnVfcHJpbWFy
eT8gb2ggd2VsbCwgd2UgYXJlIHN0dWNrIHdpdGggaXQgbm93Lgo+ID4gCj4gCj4gWWVhaC4uIEkg
dGhpbmsgZWFybGllciBnZnhfcGFzc3RocnUgd2Fzbid0IGEgYm9vbGVhbiwgYnV0IGFuIGludGVn
ZXIsIHRvIGNob29zZSB0aGUgbW9kZS4KCk9oLCBkbyB5b3UgaGFwcGVuIHRvIGtub3cgd2hhdCB0
aGUgbWVhbmluZ3Mgd2VyZT8KCj4gPiA+ICBzbyB0aGUgUWVtdSBlbXVsYXRlZCAKPiA+ID4gK2dy
YXBoaWNzIGFkYXB0ZXIgaXMgZGlzYWJsZWQsIGFuZCB0aGUgVk5DIGNvbnNvbGUgZm9yIHRoZSBW
TSB3b24ndCBoYXZlCj4gPiA+ICthbnkgZ3JhcGhpY3Mgb3V0cHV0LiBBbGwgZ3JhcGhpY3Mgb3V0
cHV0LCBpbmNsdWRpbmcgYm9vdCB0aW1lIFFlbXUgQklPUwo+ID4gPiArbWVzc2FnZXMgZnJvbSB0
aGUgVk0sIHdpbGwgZ28gdG8gdGhlIHBoeXNpY2FsIG91dHB1dHMgb2YgdGhlIHBhc3NlZCB0aHJ1
Cj4gPiA+ICtwaHlzaWNhbCBncmFwaGljcyBjYXJkLgo+ID4gPiArCj4gPiA+ICtHcmFwaGljcyBj
YXJkIFBDSSBkZXZpY2UgdG8gcGFzc3RocnUgaXMgY2hvc2VuIHdpdGggQjxwY2k+IG9wdGlvbiwg
Cj4gPiA+ICtleGFjdGx5IGluIHRoZSBzYW1lIHdheSBhcyBub3JtYWwgWGVuIFBDSSBkZXZpY2Ug
cGFzc3RocnUvYXNzaWdubWVudCBpcyBkb25lLiAKPiA+ID4gK05vdGUgdGhhdCBnZnhfcGFzc3Ro
cnUgZG9lc24ndCBkbyBhbnkga2luZCBvZiBzaGFyaW5nCj4gPiA+ICtvZiB0aGUgR1BVLCBzbyB5
b3UgY2FuIG9ubHkgYXNzaWduIHRoZSBHUFUgdG8gb25lIHNpbmdsZSBWTSBhdCBhIHRpbWUuCj4g
PiA+ICsKPiA+ID4gK2dmeF9wYXNzdGhydSBhbHNvIGVuYWJsZXMgdmFyaW91cyBsZWdhY3kgVkdB
IG1lbW9yeSByYW5nZXMsIEJBUnMsIE1NSU9zLCAKPiA+ID4gK2FuZCBpb3BvcnRzIHRvIGJlIHBh
c3NlZCB0aHJ1IHRvIHRoZSBWTSwgc2luY2UgdGhvc2UgYXJlIHJlcXVpcmVkCj4gPiA+ICtmb3Ig
Y29ycmVjdCBvcGVyYXRpb24gb2YgdGhpbmdzIGxpa2UgVkdBIEJJT1MsIHRleHQgbW9kZSwgVkJF
LCBldGMuCj4gPiA+ICsKPiA+ID4gK0VuYWJsaW5nIGdmeF9wYXNzdGhydSBvcHRpb24gYWxzbyBj
b3BpZXMgdGhlIHBoeXNpY2FsIGdyYXBoaWNzIGNhcmQgCj4gPiA+ICt2aWRlbyBiaW9zIHRvIHRo
ZSBndWVzdCBtZW1vcnksIGFuZCBleGVjdXRlcyB0aGUgdmJpb3MgaW4gdGhlIGd1ZXN0IAo+ID4g
Cj4gPiAiQklPUyIgYW5kIChJIGV4cGVjdCkgIlZCSU9TIj8KPiA+IAo+IAo+IHZpZGVvIGJpb3Mg
PT0gdmJpb3MsIG9yIGRpZCB5b3UgYXNrIHNvbWV0aGluZyBlbHNlPyAKCkkgd2FzIGp1c3QgY29t
bWVudGluZyBvbiB0aGUgY2FwaXRhbGlzYXRpb24gZGlmZmVyaW5nIGZyb20gb3RoZXIKbWVudGlv
bnMgb2YgdGhlIEJJT1MuCgo+ID4gPiArdG8gZ2V0IHRoZSBncmFwaGljcyBjYXJkIGluaXRpYWxp
emVkLgo+ID4gPiArCj4gPiA+ICtNb3N0IGdyYXBoaWNzIGFkYXB0ZXJzIHJlcXVpcmUgdmVuZG9y
IHNwZWNpZmljIHR3ZWFrcyBmb3IgcHJvcGVybHkKPiA+ID4gK3dvcmtpbmcgZ3JhcGhpY3MgcGFz
c3RocnUuIFhlbiBjdXJyZW50bHkgaW5jbHVkZXMgbmVjZXNzYXJ5IHR3ZWFrcwo+ID4gPiArZm9y
IEludGVsIElHRCAoSW50ZWdyYXRlZCBHcmFwaGljcyBEZXZpY2UpIEdQVXMuICAKPiA+ID4gKwo+
ID4gPiArU3VwcG9ydCBmb3IgQU1EL052aWRpYSBnZnhfcGFzc3RocnUgaXMgbm90IHlldCBtZXJn
ZWQgdG8gWGVuLAo+ID4gPiArYnV0IHRoZXJlIGFyZSBvdXQtb2YtdHJlZSBwYXRjaGVzIGF2YWls
YWJsZS4KPiA+IAo+ID4gSWYgdGhlcmUgaXMgYSBjb21wcmVoZW5zaXZlIGxpc3Qgb2Ygc3VwcG9y
dGVkL25vdC1zdXBwb3J0ZWQgZGV2aWNlcyBvbgo+ID4gdGhlIHdpa2kgdGhlbiBJIHRoaW5rIGEg
cmVmZXJlbmNlIGhlcmUgd291bGQgYmUgbW9yZSB1c2VmdWwgdGhhbiB0aGVzZQo+ID4gdHdvIGJy
aWVmIHBhcmFncmFwaHMuCj4gPiAKPiAKPiBXZSBoYXZlIGEgbGlzdCwgYnV0IGl0J3Mgbm90IHVw
LXRvLWRhdGUgdW5mb3J0dW5hdGVseToKPiBodHRwOi8vd2lraS54ZW4ub3JnL3dpa2kvWGVuVkdB
UGFzc3Rocm91Z2hUZXN0ZWRBZGFwdGVycwoKSSB0aGluayBpdCBpcyB3b3J0aCByZWZlcmVuY2lu
ZyBpdCwgYW5kIHBlcmhhcHMgYWRkaW5nIGEgbm90ZSB0byB0aGUKcGFnZSBpdHNlbGYgcmVnYXJk
aW5nIGl0cyBmcmVzaG5lc3MgKGFuZCB0aGVuIHdvcmtpbmcgdG8gaW1wcm92ZSBpdCwgb2YKY291
cnNlIDstKSkKCj4gPiBJbiBwYXJ0aWN1bGFyIHRoZSBzZWNvbmQgaXNuJ3QgdmVyeSB1c2VmdWwg
d2l0aG91dCBsaW5rcyBhbmQgdGhvc2UgdGVuZAo+ID4gdG8gYmVjb21lIG91dCBvZiBkYXRlIGlu
IGRvY3MgSU1FLCBJIHdvdWxkIHRlbmQgdG8gb21pdCB0aGlzIGZyb20gaGVyZQo+ID4gYW5kIGlu
c3RlYWQgaW5jbHVkZSB0aGVtIGluIHRoZSB3aWtpIHdoZXJlIHRoZXkgY2FuIGJlIGtlcHQgdXAg
dG8gZGF0ZQo+ID4KPiAKPiBPay4gSSdsbCBmaXggdGhhdCwgYW5kIGFkZCBhIGxpbmsgdG86Cj4g
aHR0cDovL3dpa2kueGVuLm9yZy93aWtpL1hlblZHQVBhc3N0aHJvdWdoCgpUaGFua3MuCgpJYW4u
CgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRl
dmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwOi8vbGlzdHMueGVu
Lm9yZy94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xen.org Wed Sep 05 08:35:20 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Sep 2012 08:35:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9B4T-0004iZ-1C; Wed, 05 Sep 2012 08:34:49 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1T9B4R-0004iO-QA
	for xen-devel@lists.xen.org; Wed, 05 Sep 2012 08:34:47 +0000
Received: from [85.158.143.35:52425] by server-1.bemta-4.messagelabs.com id
	4B/B6-12504-7AE07405; Wed, 05 Sep 2012 08:34:47 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1346834086!16794240!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTE4NjM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28914 invoked from network); 5 Sep 2012 08:34:46 -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;
	5 Sep 2012 08:34:46 -0000
X-IronPort-AV: E=Sophos;i="4.80,372,1344211200"; d="scan'208";a="14350974"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Sep 2012 08: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.279.1; Wed, 5 Sep 2012
	09:34:29 +0100
Message-ID: <1346834067.17325.5.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, 5 Sep 2012 09:34:27 +0100
In-Reply-To: <20120905025127.GI8912@reaktio.net>
References: <1346665360.25864.2.camel@zakaz.uk.xensource.com>
	<20120905025127.GI8912@reaktio.net>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: xen-users <xen-users@lists.xen.org>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.2.0 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

T24gV2VkLCAyMDEyLTA5LTA1IGF0IDAzOjUxICswMTAwLCBQYXNpIEvDpHJra8OkaW5lbiB3cm90
ZToKPiBPbiBNb24sIFNlcCAwMywgMjAxMiBhdCAxMDo0Mjo0MEFNICswMTAwLCBJYW4gQ2FtcGJl
bGwgd3JvdGU6Cj4gPiAKPiA+IHRvb2xzLCBuaWNlIHRvIGhhdmU6Cj4gPiAKPiA+ICAgICAqIHhs
IGNvbXBhdGliaWxpdHkgd2l0aCB4bToKPiA+IAo+ICAgICAgICAgICAqIHhsIHN1cHBvcnQgZm9y
ICJtb25pdG9yIiBjb21tYW5kLiBJIGRvbid0IHNlZSBpdCBtZW50aW9uZWQgaW4geGwuY2ZnIGRv
Y3MuCj4gICAgICAgICAgICAgKHRoZSBjb21tYW5kIHRvIGVuYWJsZS9kaXNhYmxlIGFjY2VzcyB0
byB0aGUgcGVyLXZtIFFlbXUgbW9uaXRvci9jb25zb2xlIAo+ICAgICAgICAgICAgICBmcm9tIFZO
Qywgd2hpY2ggaXMgdXN1YWxseSBhY2Nlc3NlZCB3aXRoIGN0cmwtYWx0LTIpLgoKSSBjYW4ndCBz
ZWUgdGhhdCBoYXBwZW5pbmcgZm9yIDQuMi4wIG5vdyBJJ20gYWZyYWlkLiBQcm9iYWJseSBiZXN0
IHRvCmJyaW5nIGl0IHVwIHdpdGggR2VvcmdlIGluIHRoZSA0LjMgdGhyZWFkLiBJdCBtaWdodCBi
ZSBhIGNhbmRpZGF0ZSBmb3IKNC4yLjEgZGVwZW5kaW5nIG9uIHRoZSBzaXplIG9mIHRoZSBwYXRj
aC4KCklhbi4KCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
XwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW4ub3JnCmh0dHA6Ly9s
aXN0cy54ZW4ub3JnL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xen.org Wed Sep 05 08:35:20 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Sep 2012 08:35:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9B4T-0004iZ-1C; Wed, 05 Sep 2012 08:34:49 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1T9B4R-0004iO-QA
	for xen-devel@lists.xen.org; Wed, 05 Sep 2012 08:34:47 +0000
Received: from [85.158.143.35:52425] by server-1.bemta-4.messagelabs.com id
	4B/B6-12504-7AE07405; Wed, 05 Sep 2012 08:34:47 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1346834086!16794240!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTE4NjM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28914 invoked from network); 5 Sep 2012 08:34:46 -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;
	5 Sep 2012 08:34:46 -0000
X-IronPort-AV: E=Sophos;i="4.80,372,1344211200"; d="scan'208";a="14350974"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Sep 2012 08: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.279.1; Wed, 5 Sep 2012
	09:34:29 +0100
Message-ID: <1346834067.17325.5.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, 5 Sep 2012 09:34:27 +0100
In-Reply-To: <20120905025127.GI8912@reaktio.net>
References: <1346665360.25864.2.camel@zakaz.uk.xensource.com>
	<20120905025127.GI8912@reaktio.net>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: xen-users <xen-users@lists.xen.org>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.2.0 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

T24gV2VkLCAyMDEyLTA5LTA1IGF0IDAzOjUxICswMTAwLCBQYXNpIEvDpHJra8OkaW5lbiB3cm90
ZToKPiBPbiBNb24sIFNlcCAwMywgMjAxMiBhdCAxMDo0Mjo0MEFNICswMTAwLCBJYW4gQ2FtcGJl
bGwgd3JvdGU6Cj4gPiAKPiA+IHRvb2xzLCBuaWNlIHRvIGhhdmU6Cj4gPiAKPiA+ICAgICAqIHhs
IGNvbXBhdGliaWxpdHkgd2l0aCB4bToKPiA+IAo+ICAgICAgICAgICAqIHhsIHN1cHBvcnQgZm9y
ICJtb25pdG9yIiBjb21tYW5kLiBJIGRvbid0IHNlZSBpdCBtZW50aW9uZWQgaW4geGwuY2ZnIGRv
Y3MuCj4gICAgICAgICAgICAgKHRoZSBjb21tYW5kIHRvIGVuYWJsZS9kaXNhYmxlIGFjY2VzcyB0
byB0aGUgcGVyLXZtIFFlbXUgbW9uaXRvci9jb25zb2xlIAo+ICAgICAgICAgICAgICBmcm9tIFZO
Qywgd2hpY2ggaXMgdXN1YWxseSBhY2Nlc3NlZCB3aXRoIGN0cmwtYWx0LTIpLgoKSSBjYW4ndCBz
ZWUgdGhhdCBoYXBwZW5pbmcgZm9yIDQuMi4wIG5vdyBJJ20gYWZyYWlkLiBQcm9iYWJseSBiZXN0
IHRvCmJyaW5nIGl0IHVwIHdpdGggR2VvcmdlIGluIHRoZSA0LjMgdGhyZWFkLiBJdCBtaWdodCBi
ZSBhIGNhbmRpZGF0ZSBmb3IKNC4yLjEgZGVwZW5kaW5nIG9uIHRoZSBzaXplIG9mIHRoZSBwYXRj
aC4KCklhbi4KCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
XwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW4ub3JnCmh0dHA6Ly9s
aXN0cy54ZW4ub3JnL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xen.org Wed Sep 05 08:39:50 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Sep 2012 08:39: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 1T9B8v-00058W-Gl; Wed, 05 Sep 2012 08:39:25 +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 1T9B8t-00058F-RS
	for xen-devel@lists.xen.org; Wed, 05 Sep 2012 08:39:23 +0000
Received: from [85.158.143.99:37878] by server-1.bemta-4.messagelabs.com id
	A5/60-12504-BBF07405; Wed, 05 Sep 2012 08:39:23 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-16.tower-216.messagelabs.com!1346834362!17405276!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA1MDIwMTE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3503 invoked from network); 5 Sep 2012 08:39:22 -0000
Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25)
	by server-16.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 5 Sep 2012 08:39:22 -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 B535D1179;
	Wed,  5 Sep 2012 11:39:21 +0300 (EEST)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id 6FE0B2005D; Wed,  5 Sep 2012 11:39:21 +0300 (EEST)
Date: Wed, 5 Sep 2012 11:39:21 +0300
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120905083921.GL8912@reaktio.net>
References: <1346665360.25864.2.camel@zakaz.uk.xensource.com>
	<20120905025127.GI8912@reaktio.net>
	<1346834067.17325.5.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1346834067.17325.5.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: xen-users <xen-users@lists.xen.org>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.2.0 Release Plan / TODO
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Sep 05, 2012 at 09:34:27AM +0100, Ian Campbell wrote:
> On Wed, 2012-09-05 at 03:51 +0100, Pasi K=E4rkk=E4inen wrote:
> > On Mon, Sep 03, 2012 at 10:42:40AM +0100, Ian Campbell wrote:
> > > =

> > > tools, nice to have:
> > > =

> > >     * xl compatibility with xm:
> > > =

> >           * xl support for "monitor" command. I don't see it mentioned =
in xl.cfg docs.
> >             (the command to enable/disable access to the per-vm Qemu mo=
nitor/console =

> >              from VNC, which is usually accessed with ctrl-alt-2).
> =

> I can't see that happening for 4.2.0 now I'm afraid. Probably best to
> bring it up with George in the 4.3 thread. It might be a candidate for
> 4.2.1 depending on the size of the patch.
> =


Yep. If "monitor2 is enabled as a default (I'm not sure about that), then i=
t's a security issue.. =

User having a VNC session to the console of the VM can run Qemu commands, s=
o for example map .iso files from dom0 etc..

-- Pasi


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

From xen-devel-bounces@lists.xen.org Wed Sep 05 08:39:50 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Sep 2012 08:39: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 1T9B8v-00058W-Gl; Wed, 05 Sep 2012 08:39:25 +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 1T9B8t-00058F-RS
	for xen-devel@lists.xen.org; Wed, 05 Sep 2012 08:39:23 +0000
Received: from [85.158.143.99:37878] by server-1.bemta-4.messagelabs.com id
	A5/60-12504-BBF07405; Wed, 05 Sep 2012 08:39:23 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-16.tower-216.messagelabs.com!1346834362!17405276!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA1MDIwMTE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3503 invoked from network); 5 Sep 2012 08:39:22 -0000
Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25)
	by server-16.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 5 Sep 2012 08:39:22 -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 B535D1179;
	Wed,  5 Sep 2012 11:39:21 +0300 (EEST)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id 6FE0B2005D; Wed,  5 Sep 2012 11:39:21 +0300 (EEST)
Date: Wed, 5 Sep 2012 11:39:21 +0300
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120905083921.GL8912@reaktio.net>
References: <1346665360.25864.2.camel@zakaz.uk.xensource.com>
	<20120905025127.GI8912@reaktio.net>
	<1346834067.17325.5.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1346834067.17325.5.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: xen-users <xen-users@lists.xen.org>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.2.0 Release Plan / TODO
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Sep 05, 2012 at 09:34:27AM +0100, Ian Campbell wrote:
> On Wed, 2012-09-05 at 03:51 +0100, Pasi K=E4rkk=E4inen wrote:
> > On Mon, Sep 03, 2012 at 10:42:40AM +0100, Ian Campbell wrote:
> > > =

> > > tools, nice to have:
> > > =

> > >     * xl compatibility with xm:
> > > =

> >           * xl support for "monitor" command. I don't see it mentioned =
in xl.cfg docs.
> >             (the command to enable/disable access to the per-vm Qemu mo=
nitor/console =

> >              from VNC, which is usually accessed with ctrl-alt-2).
> =

> I can't see that happening for 4.2.0 now I'm afraid. Probably best to
> bring it up with George in the 4.3 thread. It might be a candidate for
> 4.2.1 depending on the size of the patch.
> =


Yep. If "monitor2 is enabled as a default (I'm not sure about that), then i=
t's a security issue.. =

User having a VNC session to the console of the VM can run Qemu commands, s=
o for example map .iso files from dom0 etc..

-- Pasi


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

From xen-devel-bounces@lists.xen.org Wed Sep 05 08:52:49 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Sep 2012 08: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 1T9BLR-0005m3-EI; Wed, 05 Sep 2012 08:52:21 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <linux@eikelenboom.it>) id 1T9BLP-0005lr-UE
	for xen-devel@lists.xen.org; Wed, 05 Sep 2012 08:52:20 +0000
Received: from [85.158.138.51:40444] by server-3.bemta-3.messagelabs.com id
	8D/68-21322-3C217405; Wed, 05 Sep 2012 08:52:19 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-11.tower-174.messagelabs.com!1346835132!28715162!1
X-Originating-IP: [188.40.164.121]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8004 invoked from network); 5 Sep 2012 08:52:12 -0000
Received: from static.121.164.40.188.clients.your-server.de (HELO
	smtp.eikelenboom.it) (188.40.164.121)
	by server-11.tower-174.messagelabs.com with AES256-SHA encrypted SMTP;
	5 Sep 2012 08:52:12 -0000
Received: from 128-64-ftth.onsneteindhoven.nl ([88.159.64.128]:51391
	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 1T9BHu-0007LZ-8N; Wed, 05 Sep 2012 10:48:42 +0200
Date: Wed, 5 Sep 2012 10:51:46 +0200
From: Sander Eikelenboom <linux@eikelenboom.it>
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <102157590.20120905105146@eikelenboom.it>
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1346834067.17325.5.camel@zakaz.uk.xensource.com>
References: <1346665360.25864.2.camel@zakaz.uk.xensource.com>
	<20120905025127.GI8912@reaktio.net>
	<1346834067.17325.5.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: xen-users <xen-users@lists.xen.org>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.2.0 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

DQpXZWRuZXNkYXksIFNlcHRlbWJlciA1LCAyMDEyLCAxMDozNDoyNyBBTSwgeW91IHdyb3RlOgoK
PiBPbiBXZWQsIDIwMTItMDktMDUgYXQgMDM6NTEgKzAxMDAsIFBhc2kgS8Okcmtrw6RpbmVuIHdy
b3RlOgo+PiBPbiBNb24sIFNlcCAwMywgMjAxMiBhdCAxMDo0Mjo0MEFNICswMTAwLCBJYW4gQ2Ft
cGJlbGwgd3JvdGU6Cj4+ID4gCj4+ID4gdG9vbHMsIG5pY2UgdG8gaGF2ZToKPj4gPiAKPj4gPiAg
ICAgKiB4bCBjb21wYXRpYmlsaXR5IHdpdGggeG06Cj4+ID4gCj4+ICAgICAgICAgICAqIHhsIHN1
cHBvcnQgZm9yICJtb25pdG9yIiBjb21tYW5kLiBJIGRvbid0IHNlZSBpdCBtZW50aW9uZWQgaW4g
eGwuY2ZnIGRvY3MuCj4+ICAgICAgICAgICAgICh0aGUgY29tbWFuZCB0byBlbmFibGUvZGlzYWJs
ZSBhY2Nlc3MgdG8gdGhlIHBlci12bSBRZW11IG1vbml0b3IvY29uc29sZSAKPj4gICAgICAgICAg
ICAgIGZyb20gVk5DLCB3aGljaCBpcyB1c3VhbGx5IGFjY2Vzc2VkIHdpdGggY3RybC1hbHQtMiku
Cgo+IEkgY2FuJ3Qgc2VlIHRoYXQgaGFwcGVuaW5nIGZvciA0LjIuMCBub3cgSSdtIGFmcmFpZC4g
UHJvYmFibHkgYmVzdCB0bwo+IGJyaW5nIGl0IHVwIHdpdGggR2VvcmdlIGluIHRoZSA0LjMgdGhy
ZWFkLiBJdCBtaWdodCBiZSBhIGNhbmRpZGF0ZSBmb3IKPiA0LjIuMSBkZXBlbmRpbmcgb24gdGhl
IHNpemUgb2YgdGhlIHBhdGNoLgoKSSBoYXZlIHRoZSBmZWVsaW5nIHRoZXJlIGFyZSBzdGlsbCBx
dWl0ZSBzb21lIG9wdGlvbnMgbWlzc2luZyBmcm9tIHhsID8KQW5kIHNpbmNlIHhtIHdpbGwgYmUg
Zm9ybWFsbHkgZGVwcmVjYXRlZCBwZXJoYXBzIHRoaXMgdXJnZXMgZm9yIGEgbGliZXJhbCB2aWV3
IG9uIGJhY2twb3J0aW5nIGNhbmRpZGF0ZXMuCgpIYXZpbmcgdG8gd2FpdCBhIGZ1bGwgcmVsZWFz
ZSBjeWNsZSBmb3IgY29tcGF0aWJpbGl0eSBzdHVmZiBkb2Vzbid0IHNlZW0gdmVyeSBhdHRyYWN0
aXZlIGFuZCBtaWdodCBtYWtlIHBlb3BsZSBza2lwIDQuMi54IGFsdG9nZXRoZXIuCgpJIGhhdmUg
anVzdCBzdGFydGVkIG9uIHRoZSBzaHV0ZG93biBvcHRpb24sIHNvIGhvcGVmdWxseSB0aGF0IGNh
biBiZSBvZmYgdGhlIGxpc3QgdG9kYXkgOi0pCkFuZCBkbyBpdCBmb3IgeGwgcmVib290IHRvbywg
aXQgYWxzbyBsYWNrcyB0aGUgIi1hIiBvcHRpb24uCgpBZnRlciB0aGF0IHBlcmhhcHMgdHJ5IHRv
IG1ha2UgYSBjb21wYXJpc29uIGJldHdlZW4geG0gYW5kIHhsIHRvIHNlZSB3aGF0J3Mgc3RpbGwg
bGFja2luZyBpbiB0ZXJtcyBvZiBjb21wYXRpYmlsaXR5IGFuZCBzZWUgd2hhdCB3b3VsZCBiZSBu
aWNlIHRvIGhhdmUgaW1wbGVtZW50ZWQsIGFuZCB3aGF0IGNhbiBwZXJoYXBzIGJlIGxlZnQgb3V0
LgoKLS0KU2FuZGVyCgo+IElhbi4KCgoKCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fXwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54
ZW4ub3JnCmh0dHA6Ly9saXN0cy54ZW4ub3JnL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xen.org Wed Sep 05 08:52:49 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Sep 2012 08: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 1T9BLR-0005m3-EI; Wed, 05 Sep 2012 08:52:21 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <linux@eikelenboom.it>) id 1T9BLP-0005lr-UE
	for xen-devel@lists.xen.org; Wed, 05 Sep 2012 08:52:20 +0000
Received: from [85.158.138.51:40444] by server-3.bemta-3.messagelabs.com id
	8D/68-21322-3C217405; Wed, 05 Sep 2012 08:52:19 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-11.tower-174.messagelabs.com!1346835132!28715162!1
X-Originating-IP: [188.40.164.121]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8004 invoked from network); 5 Sep 2012 08:52:12 -0000
Received: from static.121.164.40.188.clients.your-server.de (HELO
	smtp.eikelenboom.it) (188.40.164.121)
	by server-11.tower-174.messagelabs.com with AES256-SHA encrypted SMTP;
	5 Sep 2012 08:52:12 -0000
Received: from 128-64-ftth.onsneteindhoven.nl ([88.159.64.128]:51391
	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 1T9BHu-0007LZ-8N; Wed, 05 Sep 2012 10:48:42 +0200
Date: Wed, 5 Sep 2012 10:51:46 +0200
From: Sander Eikelenboom <linux@eikelenboom.it>
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <102157590.20120905105146@eikelenboom.it>
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1346834067.17325.5.camel@zakaz.uk.xensource.com>
References: <1346665360.25864.2.camel@zakaz.uk.xensource.com>
	<20120905025127.GI8912@reaktio.net>
	<1346834067.17325.5.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: xen-users <xen-users@lists.xen.org>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.2.0 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

DQpXZWRuZXNkYXksIFNlcHRlbWJlciA1LCAyMDEyLCAxMDozNDoyNyBBTSwgeW91IHdyb3RlOgoK
PiBPbiBXZWQsIDIwMTItMDktMDUgYXQgMDM6NTEgKzAxMDAsIFBhc2kgS8Okcmtrw6RpbmVuIHdy
b3RlOgo+PiBPbiBNb24sIFNlcCAwMywgMjAxMiBhdCAxMDo0Mjo0MEFNICswMTAwLCBJYW4gQ2Ft
cGJlbGwgd3JvdGU6Cj4+ID4gCj4+ID4gdG9vbHMsIG5pY2UgdG8gaGF2ZToKPj4gPiAKPj4gPiAg
ICAgKiB4bCBjb21wYXRpYmlsaXR5IHdpdGggeG06Cj4+ID4gCj4+ICAgICAgICAgICAqIHhsIHN1
cHBvcnQgZm9yICJtb25pdG9yIiBjb21tYW5kLiBJIGRvbid0IHNlZSBpdCBtZW50aW9uZWQgaW4g
eGwuY2ZnIGRvY3MuCj4+ICAgICAgICAgICAgICh0aGUgY29tbWFuZCB0byBlbmFibGUvZGlzYWJs
ZSBhY2Nlc3MgdG8gdGhlIHBlci12bSBRZW11IG1vbml0b3IvY29uc29sZSAKPj4gICAgICAgICAg
ICAgIGZyb20gVk5DLCB3aGljaCBpcyB1c3VhbGx5IGFjY2Vzc2VkIHdpdGggY3RybC1hbHQtMiku
Cgo+IEkgY2FuJ3Qgc2VlIHRoYXQgaGFwcGVuaW5nIGZvciA0LjIuMCBub3cgSSdtIGFmcmFpZC4g
UHJvYmFibHkgYmVzdCB0bwo+IGJyaW5nIGl0IHVwIHdpdGggR2VvcmdlIGluIHRoZSA0LjMgdGhy
ZWFkLiBJdCBtaWdodCBiZSBhIGNhbmRpZGF0ZSBmb3IKPiA0LjIuMSBkZXBlbmRpbmcgb24gdGhl
IHNpemUgb2YgdGhlIHBhdGNoLgoKSSBoYXZlIHRoZSBmZWVsaW5nIHRoZXJlIGFyZSBzdGlsbCBx
dWl0ZSBzb21lIG9wdGlvbnMgbWlzc2luZyBmcm9tIHhsID8KQW5kIHNpbmNlIHhtIHdpbGwgYmUg
Zm9ybWFsbHkgZGVwcmVjYXRlZCBwZXJoYXBzIHRoaXMgdXJnZXMgZm9yIGEgbGliZXJhbCB2aWV3
IG9uIGJhY2twb3J0aW5nIGNhbmRpZGF0ZXMuCgpIYXZpbmcgdG8gd2FpdCBhIGZ1bGwgcmVsZWFz
ZSBjeWNsZSBmb3IgY29tcGF0aWJpbGl0eSBzdHVmZiBkb2Vzbid0IHNlZW0gdmVyeSBhdHRyYWN0
aXZlIGFuZCBtaWdodCBtYWtlIHBlb3BsZSBza2lwIDQuMi54IGFsdG9nZXRoZXIuCgpJIGhhdmUg
anVzdCBzdGFydGVkIG9uIHRoZSBzaHV0ZG93biBvcHRpb24sIHNvIGhvcGVmdWxseSB0aGF0IGNh
biBiZSBvZmYgdGhlIGxpc3QgdG9kYXkgOi0pCkFuZCBkbyBpdCBmb3IgeGwgcmVib290IHRvbywg
aXQgYWxzbyBsYWNrcyB0aGUgIi1hIiBvcHRpb24uCgpBZnRlciB0aGF0IHBlcmhhcHMgdHJ5IHRv
IG1ha2UgYSBjb21wYXJpc29uIGJldHdlZW4geG0gYW5kIHhsIHRvIHNlZSB3aGF0J3Mgc3RpbGwg
bGFja2luZyBpbiB0ZXJtcyBvZiBjb21wYXRpYmlsaXR5IGFuZCBzZWUgd2hhdCB3b3VsZCBiZSBu
aWNlIHRvIGhhdmUgaW1wbGVtZW50ZWQsIGFuZCB3aGF0IGNhbiBwZXJoYXBzIGJlIGxlZnQgb3V0
LgoKLS0KU2FuZGVyCgo+IElhbi4KCgoKCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fXwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54
ZW4ub3JnCmh0dHA6Ly9saXN0cy54ZW4ub3JnL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xen.org Wed Sep 05 09:06:24 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Sep 2012 09: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 1T9BYb-0006GY-Hl; Wed, 05 Sep 2012 09:05:57 +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 1T9BYa-0006GS-3N
	for xen-devel@lists.xen.org; Wed, 05 Sep 2012 09:05:56 +0000
Received: from [85.158.143.35:58056] by server-2.bemta-4.messagelabs.com id
	D2/CD-21239-3F517405; Wed, 05 Sep 2012 09:05:55 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1346835951!16800594!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNjg4NDA=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21783 invoked from network); 5 Sep 2012 09:05:53 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-14.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Sep 2012 09:05:53 -0000
X-IronPort-AV: E=Sophos;i="4.80,372,1344211200"; d="scan'208";a="36806333"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Sep 2012 09:05:51 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 5 Sep 2012 05:05:50 -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 1T9BYU-0007Jt-Es	for
	xen-devel@lists.xen.org; Wed, 05 Sep 2012 10:05:50 +0100
Message-ID: <504715EE.2070606@citrix.com>
Date: Wed, 5 Sep 2012 10:05:50 +0100
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:14.0) Gecko/20120714 Thunderbird/14.0
MIME-Version: 1.0
To: xen-devel@lists.xen.org
References: <20120905030239.GJ8912@reaktio.net>
In-Reply-To: <20120905030239.GJ8912@reaktio.net>
X-Enigmail-Version: 1.4.4
Content-Type: multipart/mixed; boundary="------------070909050506070504080108"
Subject: Re: [Xen-devel] Xen 4.2 (missing) pygrub support for ext4 on
 rhel5/centos5 e4fsprogs..
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--------------070909050506070504080108
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit

On 05/09/12 04:02, Pasi Kärkkäinen wrote:
> Hello,
>
> Roger: If I didn't mix up people we had a chat about this at XenSummit :) 
> so here's some info about the ext4 stuff on rhel5/centos5.
>
> # yum search e4fsprogs
> e4fsprogs.x86_64 : Utilities for managing the fourth extended (ext4) filesystem
> e4fsprogs-devel.i386 : Ext4 filesystem-specific static libraries and headers
> e4fsprogs-devel.x86_64 : Ext4 filesystem-specific static libraries and headers
> e4fsprogs-libs.i386 : Ext4 filesystem-specific static libraries and headers
> e4fsprogs-libs.x86_64 : Ext4 filesystem-specific static libraries and headers
>
> # rpm -ql e4fsprogs-libs.i386
> /lib/libe4p.so.2
> /lib/libe4p.so.2.3
> /lib/libext4fs.so.2
> /lib/libext4fs.so.2.4
>
> # rpm -ql e4fsprogs-libs.x86_64
> /lib64/libe4p.so.2
> /lib64/libe4p.so.2.3
> /lib64/libext4fs.so.2
> /lib64/libext4fs.so.2.4
>
> # rpm -ql e4fsprogs-devel.i386
> /usr/include/e4p
> /usr/include/e4p/e2p.h
> /usr/include/ext4fs
> /usr/include/ext4fs/bitops.h
> /usr/include/ext4fs/ext2_err.h
> /usr/include/ext4fs/ext2_ext_attr.h
> /usr/include/ext4fs/ext2_fs.h
> /usr/include/ext4fs/ext2_io.h
> /usr/include/ext4fs/ext2_types-i386.h
> /usr/include/ext4fs/ext2_types.h
> /usr/include/ext4fs/ext2fs.h
> /usr/include/ext4fs/ext3_extents.h
> /usr/include/ext4fs/tdb.h
> /usr/lib/libe4p.a
> /usr/lib/libe4p.so
> /usr/lib/libext4fs.a
> /usr/lib/libext4fs.so
> /usr/lib/pkgconfig/e4p.pc
> /usr/lib/pkgconfig/ext4fs.pc
> /usr/share/info/libext4fs.info.gz
>
> # rpm -ql e4fsprogs-devel.x86_64
> /usr/include/e4p
> /usr/include/e4p/e2p.h
> /usr/include/ext4fs
> /usr/include/ext4fs/bitops.h
> /usr/include/ext4fs/ext2_err.h
> /usr/include/ext4fs/ext2_ext_attr.h
> /usr/include/ext4fs/ext2_fs.h
> /usr/include/ext4fs/ext2_io.h
> /usr/include/ext4fs/ext2_types-x86_64.h
> /usr/include/ext4fs/ext2_types.h
> /usr/include/ext4fs/ext2fs.h
> /usr/include/ext4fs/ext3_extents.h
> /usr/include/ext4fs/tdb.h
> /usr/lib64/libe4p.a
> /usr/lib64/libe4p.so
> /usr/lib64/libext4fs.a
> /usr/lib64/libext4fs.so
> /usr/lib64/pkgconfig/e4p.pc
> /usr/lib64/pkgconfig/ext4fs.pc
> /usr/share/info/libext4fs.info.gz
>
>
> And then some info about the included files in the stock rhel5/centos5 Xen rpms (Xen 3.1.2),
> where pygrub does support ext4 using e4fsprogs-libs:
>
>
> # rpm -ql xen-libs | grep fsimage
> /usr/lib64/fs/ext2fs-lib/fsimage.so
> /usr/lib64/fs/fat/fsimage.so
> /usr/lib64/fs/iso9660/fsimage.so
> /usr/lib64/fs/reiserfs/fsimage.so
> /usr/lib64/fs/ufs/fsimage.so
> /usr/lib64/libfsimage.so.1.0
> /usr/lib64/libfsimage.so.1.0.0
> /usr/lib/fs/ext2fs-lib/fsimage.so
> /usr/lib/fs/fat/fsimage.so
> /usr/lib/fs/iso9660/fsimage.so
> /usr/lib/fs/reiserfs/fsimage.so
> /usr/lib/fs/ufs/fsimage.so
> /usr/lib/libfsimage.so.1.0
> /usr/lib/libfsimage.so.1.0.0
>
> # ldd /usr/lib/fs/ext2fs-lib/fsimage.so
>         linux-gate.so.1 =>  (0xffffe000)
>         libfsimage.so.1.0 => /usr/lib/libfsimage.so.1.0 (0xf7f09000)
>         libext4fs.so.2 => /lib/libext4fs.so.2 (0xf7edb000)
>         libc.so.6 => /lib/libc.so.6 (0xf7d82000)
>         libpthread.so.0 => /lib/libpthread.so.0 (0xf7d68000)
>         libcom_err.so.2 => /lib/libcom_err.so.2 (0xf7d64000)
>         /lib/ld-linux.so.2 (0x00778000)
>
>
> # ldd /usr/lib64/fs/ext2fs-lib/fsimage.so
>         linux-vdso.so.1 =>  (0x00007fff9cffd000)
>         libfsimage.so.1.0 => /usr/lib64/libfsimage.so.1.0 (0x00002adbbef0e000)
>         libext4fs.so.2 => /lib64/libext4fs.so.2 (0x00002adbbf111000)
>         libc.so.6 => /lib64/libc.so.6 (0x00002adbbf340000)
>         libpthread.so.0 => /lib64/libpthread.so.0 (0x00002adbbf697000)
>         libcom_err.so.2 => /lib64/libcom_err.so.2 (0x00002adbbf8b2000)
>         /lib64/ld-linux-x86-64.so.2 (0x00000039dce00000)
>
> So el5 stock Xen rpms provide ext2fs-lib/fsimage.so, which is linked against libext4fs.so.2,
> and pygrub loads/uses fsimage.so.
>
>
> Can you guys please post the patch/hack you're currently using with XenServer/XCP,
> so we can decide what'd be the best way to get Xen 4.2 pygrub supporting ext4 also on el5 ? 

Attached, but it is very brutal as far as hacks go, and not suitable for
upstreaming in its current form.

~Andrew

>
>
> Thanks,
>
> -- Pasi
>
>
> _______________________________________________
> 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


--------------070909050506070504080108
Content-Type: text/x-patch; name="centos5-libe4fs-hack.patch"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="centos5-libe4fs-hack.patch"

# HG changeset patch
# Parent d341f05a3640a1f4cd92f7b8eefb4d221c13b408
Work around RHEL5's ext2fs/ext4fs split.

We need to link against a new enough version of libext2fs to be able to
read ext4 partitions.  This is only needed because RHEL5 puts the latest
ext2 libs in their own directory.  Other distros (and other RHELs) work
fine already.

This a hard-hack; a proper fix would add the check to configure.  This
patch can be simply removed when we move to Centos 6.

diff --git a/tools/libfsimage/ext2fs-lib/Makefile b/tools/libfsimage/ext2fs-lib/Makefile
--- a/tools/libfsimage/ext2fs-lib/Makefile
+++ b/tools/libfsimage/ext2fs-lib/Makefile
@@ -4,7 +4,7 @@ LIB_SRCS-y = ext2fs-lib.c
 
 FS = ext2fs-lib
 
-FS_LIBDEPS = -lext2fs
+FS_LIBDEPS = -lext4fs
 
 .PHONY: all
 all: fs-all
diff --git a/tools/libfsimage/ext2fs-lib/ext2fs-lib.c b/tools/libfsimage/ext2fs-lib/ext2fs-lib.c
--- a/tools/libfsimage/ext2fs-lib/ext2fs-lib.c
+++ b/tools/libfsimage/ext2fs-lib/ext2fs-lib.c
@@ -22,7 +22,7 @@
  */
 
 #include <fsimage_plugin.h>
-#include <ext2fs/ext2fs.h>
+#include <ext4fs/ext2fs.h>
 #include <errno.h>
 #include <inttypes.h>
 

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

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

--------------070909050506070504080108--


From xen-devel-bounces@lists.xen.org Wed Sep 05 09:06:24 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Sep 2012 09: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 1T9BYb-0006GY-Hl; Wed, 05 Sep 2012 09:05:57 +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 1T9BYa-0006GS-3N
	for xen-devel@lists.xen.org; Wed, 05 Sep 2012 09:05:56 +0000
Received: from [85.158.143.35:58056] by server-2.bemta-4.messagelabs.com id
	D2/CD-21239-3F517405; Wed, 05 Sep 2012 09:05:55 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1346835951!16800594!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNjg4NDA=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21783 invoked from network); 5 Sep 2012 09:05:53 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-14.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Sep 2012 09:05:53 -0000
X-IronPort-AV: E=Sophos;i="4.80,372,1344211200"; d="scan'208";a="36806333"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Sep 2012 09:05:51 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 5 Sep 2012 05:05:50 -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 1T9BYU-0007Jt-Es	for
	xen-devel@lists.xen.org; Wed, 05 Sep 2012 10:05:50 +0100
Message-ID: <504715EE.2070606@citrix.com>
Date: Wed, 5 Sep 2012 10:05:50 +0100
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:14.0) Gecko/20120714 Thunderbird/14.0
MIME-Version: 1.0
To: xen-devel@lists.xen.org
References: <20120905030239.GJ8912@reaktio.net>
In-Reply-To: <20120905030239.GJ8912@reaktio.net>
X-Enigmail-Version: 1.4.4
Content-Type: multipart/mixed; boundary="------------070909050506070504080108"
Subject: Re: [Xen-devel] Xen 4.2 (missing) pygrub support for ext4 on
 rhel5/centos5 e4fsprogs..
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--------------070909050506070504080108
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit

On 05/09/12 04:02, Pasi Kärkkäinen wrote:
> Hello,
>
> Roger: If I didn't mix up people we had a chat about this at XenSummit :) 
> so here's some info about the ext4 stuff on rhel5/centos5.
>
> # yum search e4fsprogs
> e4fsprogs.x86_64 : Utilities for managing the fourth extended (ext4) filesystem
> e4fsprogs-devel.i386 : Ext4 filesystem-specific static libraries and headers
> e4fsprogs-devel.x86_64 : Ext4 filesystem-specific static libraries and headers
> e4fsprogs-libs.i386 : Ext4 filesystem-specific static libraries and headers
> e4fsprogs-libs.x86_64 : Ext4 filesystem-specific static libraries and headers
>
> # rpm -ql e4fsprogs-libs.i386
> /lib/libe4p.so.2
> /lib/libe4p.so.2.3
> /lib/libext4fs.so.2
> /lib/libext4fs.so.2.4
>
> # rpm -ql e4fsprogs-libs.x86_64
> /lib64/libe4p.so.2
> /lib64/libe4p.so.2.3
> /lib64/libext4fs.so.2
> /lib64/libext4fs.so.2.4
>
> # rpm -ql e4fsprogs-devel.i386
> /usr/include/e4p
> /usr/include/e4p/e2p.h
> /usr/include/ext4fs
> /usr/include/ext4fs/bitops.h
> /usr/include/ext4fs/ext2_err.h
> /usr/include/ext4fs/ext2_ext_attr.h
> /usr/include/ext4fs/ext2_fs.h
> /usr/include/ext4fs/ext2_io.h
> /usr/include/ext4fs/ext2_types-i386.h
> /usr/include/ext4fs/ext2_types.h
> /usr/include/ext4fs/ext2fs.h
> /usr/include/ext4fs/ext3_extents.h
> /usr/include/ext4fs/tdb.h
> /usr/lib/libe4p.a
> /usr/lib/libe4p.so
> /usr/lib/libext4fs.a
> /usr/lib/libext4fs.so
> /usr/lib/pkgconfig/e4p.pc
> /usr/lib/pkgconfig/ext4fs.pc
> /usr/share/info/libext4fs.info.gz
>
> # rpm -ql e4fsprogs-devel.x86_64
> /usr/include/e4p
> /usr/include/e4p/e2p.h
> /usr/include/ext4fs
> /usr/include/ext4fs/bitops.h
> /usr/include/ext4fs/ext2_err.h
> /usr/include/ext4fs/ext2_ext_attr.h
> /usr/include/ext4fs/ext2_fs.h
> /usr/include/ext4fs/ext2_io.h
> /usr/include/ext4fs/ext2_types-x86_64.h
> /usr/include/ext4fs/ext2_types.h
> /usr/include/ext4fs/ext2fs.h
> /usr/include/ext4fs/ext3_extents.h
> /usr/include/ext4fs/tdb.h
> /usr/lib64/libe4p.a
> /usr/lib64/libe4p.so
> /usr/lib64/libext4fs.a
> /usr/lib64/libext4fs.so
> /usr/lib64/pkgconfig/e4p.pc
> /usr/lib64/pkgconfig/ext4fs.pc
> /usr/share/info/libext4fs.info.gz
>
>
> And then some info about the included files in the stock rhel5/centos5 Xen rpms (Xen 3.1.2),
> where pygrub does support ext4 using e4fsprogs-libs:
>
>
> # rpm -ql xen-libs | grep fsimage
> /usr/lib64/fs/ext2fs-lib/fsimage.so
> /usr/lib64/fs/fat/fsimage.so
> /usr/lib64/fs/iso9660/fsimage.so
> /usr/lib64/fs/reiserfs/fsimage.so
> /usr/lib64/fs/ufs/fsimage.so
> /usr/lib64/libfsimage.so.1.0
> /usr/lib64/libfsimage.so.1.0.0
> /usr/lib/fs/ext2fs-lib/fsimage.so
> /usr/lib/fs/fat/fsimage.so
> /usr/lib/fs/iso9660/fsimage.so
> /usr/lib/fs/reiserfs/fsimage.so
> /usr/lib/fs/ufs/fsimage.so
> /usr/lib/libfsimage.so.1.0
> /usr/lib/libfsimage.so.1.0.0
>
> # ldd /usr/lib/fs/ext2fs-lib/fsimage.so
>         linux-gate.so.1 =>  (0xffffe000)
>         libfsimage.so.1.0 => /usr/lib/libfsimage.so.1.0 (0xf7f09000)
>         libext4fs.so.2 => /lib/libext4fs.so.2 (0xf7edb000)
>         libc.so.6 => /lib/libc.so.6 (0xf7d82000)
>         libpthread.so.0 => /lib/libpthread.so.0 (0xf7d68000)
>         libcom_err.so.2 => /lib/libcom_err.so.2 (0xf7d64000)
>         /lib/ld-linux.so.2 (0x00778000)
>
>
> # ldd /usr/lib64/fs/ext2fs-lib/fsimage.so
>         linux-vdso.so.1 =>  (0x00007fff9cffd000)
>         libfsimage.so.1.0 => /usr/lib64/libfsimage.so.1.0 (0x00002adbbef0e000)
>         libext4fs.so.2 => /lib64/libext4fs.so.2 (0x00002adbbf111000)
>         libc.so.6 => /lib64/libc.so.6 (0x00002adbbf340000)
>         libpthread.so.0 => /lib64/libpthread.so.0 (0x00002adbbf697000)
>         libcom_err.so.2 => /lib64/libcom_err.so.2 (0x00002adbbf8b2000)
>         /lib64/ld-linux-x86-64.so.2 (0x00000039dce00000)
>
> So el5 stock Xen rpms provide ext2fs-lib/fsimage.so, which is linked against libext4fs.so.2,
> and pygrub loads/uses fsimage.so.
>
>
> Can you guys please post the patch/hack you're currently using with XenServer/XCP,
> so we can decide what'd be the best way to get Xen 4.2 pygrub supporting ext4 also on el5 ? 

Attached, but it is very brutal as far as hacks go, and not suitable for
upstreaming in its current form.

~Andrew

>
>
> Thanks,
>
> -- Pasi
>
>
> _______________________________________________
> 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


--------------070909050506070504080108
Content-Type: text/x-patch; name="centos5-libe4fs-hack.patch"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="centos5-libe4fs-hack.patch"

# HG changeset patch
# Parent d341f05a3640a1f4cd92f7b8eefb4d221c13b408
Work around RHEL5's ext2fs/ext4fs split.

We need to link against a new enough version of libext2fs to be able to
read ext4 partitions.  This is only needed because RHEL5 puts the latest
ext2 libs in their own directory.  Other distros (and other RHELs) work
fine already.

This a hard-hack; a proper fix would add the check to configure.  This
patch can be simply removed when we move to Centos 6.

diff --git a/tools/libfsimage/ext2fs-lib/Makefile b/tools/libfsimage/ext2fs-lib/Makefile
--- a/tools/libfsimage/ext2fs-lib/Makefile
+++ b/tools/libfsimage/ext2fs-lib/Makefile
@@ -4,7 +4,7 @@ LIB_SRCS-y = ext2fs-lib.c
 
 FS = ext2fs-lib
 
-FS_LIBDEPS = -lext2fs
+FS_LIBDEPS = -lext4fs
 
 .PHONY: all
 all: fs-all
diff --git a/tools/libfsimage/ext2fs-lib/ext2fs-lib.c b/tools/libfsimage/ext2fs-lib/ext2fs-lib.c
--- a/tools/libfsimage/ext2fs-lib/ext2fs-lib.c
+++ b/tools/libfsimage/ext2fs-lib/ext2fs-lib.c
@@ -22,7 +22,7 @@
  */
 
 #include <fsimage_plugin.h>
-#include <ext2fs/ext2fs.h>
+#include <ext4fs/ext2fs.h>
 #include <errno.h>
 #include <inttypes.h>
 

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

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

--------------070909050506070504080108--


From xen-devel-bounces@lists.xen.org Wed Sep 05 09:21:25 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Sep 2012 09:21: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 1T9BnE-0006TH-1Q; Wed, 05 Sep 2012 09:21:04 +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 1T9BnC-0006T9-Qf; Wed, 05 Sep 2012 09:21:03 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1346836561!6228563!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTE5ODY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28716 invoked from network); 5 Sep 2012 09:16:02 -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;
	5 Sep 2012 09:16:02 -0000
X-IronPort-AV: E=Sophos;i="4.80,372,1344211200"; d="scan'208";a="14352240"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Sep 2012 09:15: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.279.1; Wed, 5 Sep 2012
	10:15:39 +0100
Message-ID: <1346836538.17325.32.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Sander Eikelenboom <linux@eikelenboom.it>
Date: Wed, 5 Sep 2012 10:15:38 +0100
In-Reply-To: <102157590.20120905105146@eikelenboom.it>
References: <1346665360.25864.2.camel@zakaz.uk.xensource.com>
	<20120905025127.GI8912@reaktio.net>
	<1346834067.17325.5.camel@zakaz.uk.xensource.com>
	<102157590.20120905105146@eikelenboom.it>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: xen-users <xen-users@lists.xen.org>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.2.0 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

T24gV2VkLCAyMDEyLTA5LTA1IGF0IDA5OjUxICswMTAwLCBTYW5kZXIgRWlrZWxlbmJvb20gd3Jv
dGU6Cj4gV2VkbmVzZGF5LCBTZXB0ZW1iZXIgNSwgMjAxMiwgMTA6MzQ6MjcgQU0sIHlvdSB3cm90
ZToKPiAKPiA+IE9uIFdlZCwgMjAxMi0wOS0wNSBhdCAwMzo1MSArMDEwMCwgUGFzaSBLw6Rya2vD
pGluZW4gd3JvdGU6Cj4gPj4gT24gTW9uLCBTZXAgMDMsIDIwMTIgYXQgMTA6NDI6NDBBTSArMDEw
MCwgSWFuIENhbXBiZWxsIHdyb3RlOgo+ID4+ID4gCj4gPj4gPiB0b29scywgbmljZSB0byBoYXZl
Ogo+ID4+ID4gCj4gPj4gPiAgICAgKiB4bCBjb21wYXRpYmlsaXR5IHdpdGggeG06Cj4gPj4gPiAK
PiA+PiAgICAgICAgICAgKiB4bCBzdXBwb3J0IGZvciAibW9uaXRvciIgY29tbWFuZC4gSSBkb24n
dCBzZWUgaXQgbWVudGlvbmVkIGluIHhsLmNmZyBkb2NzLgo+ID4+ICAgICAgICAgICAgICh0aGUg
Y29tbWFuZCB0byBlbmFibGUvZGlzYWJsZSBhY2Nlc3MgdG8gdGhlIHBlci12bSBRZW11IG1vbml0
b3IvY29uc29sZSAKPiA+PiAgICAgICAgICAgICAgZnJvbSBWTkMsIHdoaWNoIGlzIHVzdWFsbHkg
YWNjZXNzZWQgd2l0aCBjdHJsLWFsdC0yKS4KPiAKPiA+IEkgY2FuJ3Qgc2VlIHRoYXQgaGFwcGVu
aW5nIGZvciA0LjIuMCBub3cgSSdtIGFmcmFpZC4gUHJvYmFibHkgYmVzdCB0bwo+ID4gYnJpbmcg
aXQgdXAgd2l0aCBHZW9yZ2UgaW4gdGhlIDQuMyB0aHJlYWQuIEl0IG1pZ2h0IGJlIGEgY2FuZGlk
YXRlIGZvcgo+ID4gNC4yLjEgZGVwZW5kaW5nIG9uIHRoZSBzaXplIG9mIHRoZSBwYXRjaC4KPiAK
PiBJIGhhdmUgdGhlIGZlZWxpbmcgdGhlcmUgYXJlIHN0aWxsIHF1aXRlIHNvbWUgb3B0aW9ucyBt
aXNzaW5nIGZyb20geGwgPwo+IEFuZCBzaW5jZSB4bSB3aWxsIGJlIGZvcm1hbGx5IGRlcHJlY2F0
ZWQgcGVyaGFwcyB0aGlzIHVyZ2VzIGZvciBhIGxpYmVyYWwgdmlldyBvbiBiYWNrcG9ydGluZyBj
YW5kaWRhdGVzLgo+IAo+IEhhdmluZyB0byB3YWl0IGEgZnVsbCByZWxlYXNlIGN5Y2xlIGZvciBj
b21wYXRpYmlsaXR5IHN0dWZmIGRvZXNuJ3QKPiBzZWVtIHZlcnkgYXR0cmFjdGl2ZSBhbmQgbWln
aHQgbWFrZSBwZW9wbGUgc2tpcCA0LjIueCBhbHRvZ2V0aGVyLgoKV2UgaGF2ZSBwcmV0dHkgbXVj
aCBhZ3JlZWQgdGhhdCBmb3IgYXQgbGVhc3QgNC4yLjEgKGFuZCBwZXJoYXBzIGxhdGVyCjQuMi54
IHRvbykgd2Ugd2lsbCB0YWtlIGEgc2xpZ2h0bHkgbW9yZSBsaWJlcmFsIHRoYW4gdXN1YWwgYXBw
cm9hY2ggdG8KYmFja3BvcnRzIHdoaWNoIGltcHJvdmUgeGwncyBmZWF0dXJlIHBhcml0eSB3aXRo
IHhlbmQuCgo+IEkgaGF2ZSBqdXN0IHN0YXJ0ZWQgb24gdGhlIHNodXRkb3duIG9wdGlvbiwgc28g
aG9wZWZ1bGx5IHRoYXQgY2FuIGJlIG9mZiB0aGUgbGlzdCB0b2RheSA6LSkKPiBBbmQgZG8gaXQg
Zm9yIHhsIHJlYm9vdCB0b28sIGl0IGFsc28gbGFja3MgdGhlICItYSIgb3B0aW9uLgoKR3JlYXQg
dGhhbmtzLgoKPiBBZnRlciB0aGF0IHBlcmhhcHMgdHJ5IHRvIG1ha2UgYSBjb21wYXJpc29uIGJl
dHdlZW4geG0gYW5kIHhsIHRvIHNlZQo+IHdoYXQncyBzdGlsbCBsYWNraW5nIGluIHRlcm1zIG9m
IGNvbXBhdGliaWxpdHkgYW5kIHNlZSB3aGF0IHdvdWxkIGJlCj4gbmljZSB0byBoYXZlIGltcGxl
bWVudGVkLCBhbmQgd2hhdCBjYW4gcGVyaGFwcyBiZSBsZWZ0IG91dC4KClRoYXQgd291bGQgYmUg
Z3JlYXQuIE91ciBwcmlvcml0eSB3b3VsZCBiZSB0byBpbXBsZW1lbnQgZmVhdHVyZXMgd2hpY2gK
cGVvcGxlIGFjdHVhbGx5IHVzZSBpbiBwcmFjdGljZS4KCgoKX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2
ZWxAbGlzdHMueGVuLm9yZwpodHRwOi8vbGlzdHMueGVuLm9yZy94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xen.org Wed Sep 05 09:21:25 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Sep 2012 09:21: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 1T9BnE-0006TH-1Q; Wed, 05 Sep 2012 09:21:04 +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 1T9BnC-0006T9-Qf; Wed, 05 Sep 2012 09:21:03 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1346836561!6228563!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTE5ODY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28716 invoked from network); 5 Sep 2012 09:16:02 -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;
	5 Sep 2012 09:16:02 -0000
X-IronPort-AV: E=Sophos;i="4.80,372,1344211200"; d="scan'208";a="14352240"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Sep 2012 09:15: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.279.1; Wed, 5 Sep 2012
	10:15:39 +0100
Message-ID: <1346836538.17325.32.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Sander Eikelenboom <linux@eikelenboom.it>
Date: Wed, 5 Sep 2012 10:15:38 +0100
In-Reply-To: <102157590.20120905105146@eikelenboom.it>
References: <1346665360.25864.2.camel@zakaz.uk.xensource.com>
	<20120905025127.GI8912@reaktio.net>
	<1346834067.17325.5.camel@zakaz.uk.xensource.com>
	<102157590.20120905105146@eikelenboom.it>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: xen-users <xen-users@lists.xen.org>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.2.0 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

T24gV2VkLCAyMDEyLTA5LTA1IGF0IDA5OjUxICswMTAwLCBTYW5kZXIgRWlrZWxlbmJvb20gd3Jv
dGU6Cj4gV2VkbmVzZGF5LCBTZXB0ZW1iZXIgNSwgMjAxMiwgMTA6MzQ6MjcgQU0sIHlvdSB3cm90
ZToKPiAKPiA+IE9uIFdlZCwgMjAxMi0wOS0wNSBhdCAwMzo1MSArMDEwMCwgUGFzaSBLw6Rya2vD
pGluZW4gd3JvdGU6Cj4gPj4gT24gTW9uLCBTZXAgMDMsIDIwMTIgYXQgMTA6NDI6NDBBTSArMDEw
MCwgSWFuIENhbXBiZWxsIHdyb3RlOgo+ID4+ID4gCj4gPj4gPiB0b29scywgbmljZSB0byBoYXZl
Ogo+ID4+ID4gCj4gPj4gPiAgICAgKiB4bCBjb21wYXRpYmlsaXR5IHdpdGggeG06Cj4gPj4gPiAK
PiA+PiAgICAgICAgICAgKiB4bCBzdXBwb3J0IGZvciAibW9uaXRvciIgY29tbWFuZC4gSSBkb24n
dCBzZWUgaXQgbWVudGlvbmVkIGluIHhsLmNmZyBkb2NzLgo+ID4+ICAgICAgICAgICAgICh0aGUg
Y29tbWFuZCB0byBlbmFibGUvZGlzYWJsZSBhY2Nlc3MgdG8gdGhlIHBlci12bSBRZW11IG1vbml0
b3IvY29uc29sZSAKPiA+PiAgICAgICAgICAgICAgZnJvbSBWTkMsIHdoaWNoIGlzIHVzdWFsbHkg
YWNjZXNzZWQgd2l0aCBjdHJsLWFsdC0yKS4KPiAKPiA+IEkgY2FuJ3Qgc2VlIHRoYXQgaGFwcGVu
aW5nIGZvciA0LjIuMCBub3cgSSdtIGFmcmFpZC4gUHJvYmFibHkgYmVzdCB0bwo+ID4gYnJpbmcg
aXQgdXAgd2l0aCBHZW9yZ2UgaW4gdGhlIDQuMyB0aHJlYWQuIEl0IG1pZ2h0IGJlIGEgY2FuZGlk
YXRlIGZvcgo+ID4gNC4yLjEgZGVwZW5kaW5nIG9uIHRoZSBzaXplIG9mIHRoZSBwYXRjaC4KPiAK
PiBJIGhhdmUgdGhlIGZlZWxpbmcgdGhlcmUgYXJlIHN0aWxsIHF1aXRlIHNvbWUgb3B0aW9ucyBt
aXNzaW5nIGZyb20geGwgPwo+IEFuZCBzaW5jZSB4bSB3aWxsIGJlIGZvcm1hbGx5IGRlcHJlY2F0
ZWQgcGVyaGFwcyB0aGlzIHVyZ2VzIGZvciBhIGxpYmVyYWwgdmlldyBvbiBiYWNrcG9ydGluZyBj
YW5kaWRhdGVzLgo+IAo+IEhhdmluZyB0byB3YWl0IGEgZnVsbCByZWxlYXNlIGN5Y2xlIGZvciBj
b21wYXRpYmlsaXR5IHN0dWZmIGRvZXNuJ3QKPiBzZWVtIHZlcnkgYXR0cmFjdGl2ZSBhbmQgbWln
aHQgbWFrZSBwZW9wbGUgc2tpcCA0LjIueCBhbHRvZ2V0aGVyLgoKV2UgaGF2ZSBwcmV0dHkgbXVj
aCBhZ3JlZWQgdGhhdCBmb3IgYXQgbGVhc3QgNC4yLjEgKGFuZCBwZXJoYXBzIGxhdGVyCjQuMi54
IHRvbykgd2Ugd2lsbCB0YWtlIGEgc2xpZ2h0bHkgbW9yZSBsaWJlcmFsIHRoYW4gdXN1YWwgYXBw
cm9hY2ggdG8KYmFja3BvcnRzIHdoaWNoIGltcHJvdmUgeGwncyBmZWF0dXJlIHBhcml0eSB3aXRo
IHhlbmQuCgo+IEkgaGF2ZSBqdXN0IHN0YXJ0ZWQgb24gdGhlIHNodXRkb3duIG9wdGlvbiwgc28g
aG9wZWZ1bGx5IHRoYXQgY2FuIGJlIG9mZiB0aGUgbGlzdCB0b2RheSA6LSkKPiBBbmQgZG8gaXQg
Zm9yIHhsIHJlYm9vdCB0b28sIGl0IGFsc28gbGFja3MgdGhlICItYSIgb3B0aW9uLgoKR3JlYXQg
dGhhbmtzLgoKPiBBZnRlciB0aGF0IHBlcmhhcHMgdHJ5IHRvIG1ha2UgYSBjb21wYXJpc29uIGJl
dHdlZW4geG0gYW5kIHhsIHRvIHNlZQo+IHdoYXQncyBzdGlsbCBsYWNraW5nIGluIHRlcm1zIG9m
IGNvbXBhdGliaWxpdHkgYW5kIHNlZSB3aGF0IHdvdWxkIGJlCj4gbmljZSB0byBoYXZlIGltcGxl
bWVudGVkLCBhbmQgd2hhdCBjYW4gcGVyaGFwcyBiZSBsZWZ0IG91dC4KClRoYXQgd291bGQgYmUg
Z3JlYXQuIE91ciBwcmlvcml0eSB3b3VsZCBiZSB0byBpbXBsZW1lbnQgZmVhdHVyZXMgd2hpY2gK
cGVvcGxlIGFjdHVhbGx5IHVzZSBpbiBwcmFjdGljZS4KCgoKX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2
ZWxAbGlzdHMueGVuLm9yZwpodHRwOi8vbGlzdHMueGVuLm9yZy94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xen.org Wed Sep 05 09:25:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Sep 2012 09:25:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9Br2-0006mx-Ao; Wed, 05 Sep 2012 09:25: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 1T9Br0-0006me-3x
	for xen-devel@lists.xen.org; Wed, 05 Sep 2012 09:24:58 +0000
Received: from [85.158.138.51:42449] by server-8.bemta-3.messagelabs.com id
	8B/22-24700-76A17405; Wed, 05 Sep 2012 09:24:55 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1346837094!10051547!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTE5ODY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11259 invoked from network); 5 Sep 2012 09:24:55 -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;
	5 Sep 2012 09:24:55 -0000
X-IronPort-AV: E=Sophos;i="4.80,372,1344211200"; d="scan'208";a="14352546"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Sep 2012 09:24:54 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Wed, 5 Sep 2012
	10:24:54 +0100
Message-ID: <1346837093.17325.38.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, 5 Sep 2012 10:24:53 +0100
In-Reply-To: <20120905083921.GL8912@reaktio.net>
References: <1346665360.25864.2.camel@zakaz.uk.xensource.com>
	<20120905025127.GI8912@reaktio.net>
	<1346834067.17325.5.camel@zakaz.uk.xensource.com>
	<20120905083921.GL8912@reaktio.net>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: xen-users <xen-users@lists.xen.org>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.2.0 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

T24gV2VkLCAyMDEyLTA5LTA1IGF0IDA5OjM5ICswMTAwLCBQYXNpIEvDpHJra8OkaW5lbiB3cm90
ZToKPiBPbiBXZWQsIFNlcCAwNSwgMjAxMiBhdCAwOTozNDoyN0FNICswMTAwLCBJYW4gQ2FtcGJl
bGwgd3JvdGU6Cj4gPiBPbiBXZWQsIDIwMTItMDktMDUgYXQgMDM6NTEgKzAxMDAsIFBhc2kgS8Ok
cmtrw6RpbmVuIHdyb3RlOgo+ID4gPiBPbiBNb24sIFNlcCAwMywgMjAxMiBhdCAxMDo0Mjo0MEFN
ICswMTAwLCBJYW4gQ2FtcGJlbGwgd3JvdGU6Cj4gPiA+ID4gCj4gPiA+ID4gdG9vbHMsIG5pY2Ug
dG8gaGF2ZToKPiA+ID4gPiAKPiA+ID4gPiAgICAgKiB4bCBjb21wYXRpYmlsaXR5IHdpdGggeG06
Cj4gPiA+ID4gCj4gPiA+ICAgICAgICAgICAqIHhsIHN1cHBvcnQgZm9yICJtb25pdG9yIiBjb21t
YW5kLiBJIGRvbid0IHNlZSBpdCBtZW50aW9uZWQgaW4geGwuY2ZnIGRvY3MuCj4gPiA+ICAgICAg
ICAgICAgICh0aGUgY29tbWFuZCB0byBlbmFibGUvZGlzYWJsZSBhY2Nlc3MgdG8gdGhlIHBlci12
bSBRZW11IG1vbml0b3IvY29uc29sZSAKPiA+ID4gICAgICAgICAgICAgIGZyb20gVk5DLCB3aGlj
aCBpcyB1c3VhbGx5IGFjY2Vzc2VkIHdpdGggY3RybC1hbHQtMikuCj4gPiAKPiA+IEkgY2FuJ3Qg
c2VlIHRoYXQgaGFwcGVuaW5nIGZvciA0LjIuMCBub3cgSSdtIGFmcmFpZC4gUHJvYmFibHkgYmVz
dCB0bwo+ID4gYnJpbmcgaXQgdXAgd2l0aCBHZW9yZ2UgaW4gdGhlIDQuMyB0aHJlYWQuIEl0IG1p
Z2h0IGJlIGEgY2FuZGlkYXRlIGZvcgo+ID4gNC4yLjEgZGVwZW5kaW5nIG9uIHRoZSBzaXplIG9m
IHRoZSBwYXRjaC4KPiA+IAo+IAo+IFllcC4gSWYgIm1vbml0b3IyIGlzIGVuYWJsZWQgYXMgYSBk
ZWZhdWx0IChJJ20gbm90IHN1cmUgYWJvdXQgdGhhdCksIHRoZW4gaXQncyBhIHNlY3VyaXR5IGlz
c3VlLi4gCgpSaWdodCwgd2UgKmRlZmluaXRlbHkqIG5lZWQgdG8gbWFrZSBzdXJlIHRoaXMgaXMg
bm90IHRoZSBjYXNlIGJlZm9yZQo0LjIuMC4gSSBjb25zaWRlciB0aGlzIGFzcGVjdCBvZiBtb25p
dG9yIHN1cHBvcnQgYSBibG9ja2VyLgoKPiBVc2VyIGhhdmluZyBhIFZOQyBzZXNzaW9uIHRvIHRo
ZSBjb25zb2xlIG9mIHRoZSBWTSBjYW4gcnVuIFFlbXUKPiBjb21tYW5kcywgc28gZm9yIGV4YW1w
bGUgbWFwIC5pc28gZmlsZXMgZnJvbSBkb20wIGV0Yy4uCgpJYW4uCgoKX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApY
ZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwOi8vbGlzdHMueGVuLm9yZy94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xen.org Wed Sep 05 09:25:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Sep 2012 09:25:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9Br2-0006mx-Ao; Wed, 05 Sep 2012 09:25: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 1T9Br0-0006me-3x
	for xen-devel@lists.xen.org; Wed, 05 Sep 2012 09:24:58 +0000
Received: from [85.158.138.51:42449] by server-8.bemta-3.messagelabs.com id
	8B/22-24700-76A17405; Wed, 05 Sep 2012 09:24:55 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1346837094!10051547!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTE5ODY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11259 invoked from network); 5 Sep 2012 09:24:55 -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;
	5 Sep 2012 09:24:55 -0000
X-IronPort-AV: E=Sophos;i="4.80,372,1344211200"; d="scan'208";a="14352546"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Sep 2012 09:24:54 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Wed, 5 Sep 2012
	10:24:54 +0100
Message-ID: <1346837093.17325.38.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, 5 Sep 2012 10:24:53 +0100
In-Reply-To: <20120905083921.GL8912@reaktio.net>
References: <1346665360.25864.2.camel@zakaz.uk.xensource.com>
	<20120905025127.GI8912@reaktio.net>
	<1346834067.17325.5.camel@zakaz.uk.xensource.com>
	<20120905083921.GL8912@reaktio.net>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: xen-users <xen-users@lists.xen.org>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.2.0 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

T24gV2VkLCAyMDEyLTA5LTA1IGF0IDA5OjM5ICswMTAwLCBQYXNpIEvDpHJra8OkaW5lbiB3cm90
ZToKPiBPbiBXZWQsIFNlcCAwNSwgMjAxMiBhdCAwOTozNDoyN0FNICswMTAwLCBJYW4gQ2FtcGJl
bGwgd3JvdGU6Cj4gPiBPbiBXZWQsIDIwMTItMDktMDUgYXQgMDM6NTEgKzAxMDAsIFBhc2kgS8Ok
cmtrw6RpbmVuIHdyb3RlOgo+ID4gPiBPbiBNb24sIFNlcCAwMywgMjAxMiBhdCAxMDo0Mjo0MEFN
ICswMTAwLCBJYW4gQ2FtcGJlbGwgd3JvdGU6Cj4gPiA+ID4gCj4gPiA+ID4gdG9vbHMsIG5pY2Ug
dG8gaGF2ZToKPiA+ID4gPiAKPiA+ID4gPiAgICAgKiB4bCBjb21wYXRpYmlsaXR5IHdpdGggeG06
Cj4gPiA+ID4gCj4gPiA+ICAgICAgICAgICAqIHhsIHN1cHBvcnQgZm9yICJtb25pdG9yIiBjb21t
YW5kLiBJIGRvbid0IHNlZSBpdCBtZW50aW9uZWQgaW4geGwuY2ZnIGRvY3MuCj4gPiA+ICAgICAg
ICAgICAgICh0aGUgY29tbWFuZCB0byBlbmFibGUvZGlzYWJsZSBhY2Nlc3MgdG8gdGhlIHBlci12
bSBRZW11IG1vbml0b3IvY29uc29sZSAKPiA+ID4gICAgICAgICAgICAgIGZyb20gVk5DLCB3aGlj
aCBpcyB1c3VhbGx5IGFjY2Vzc2VkIHdpdGggY3RybC1hbHQtMikuCj4gPiAKPiA+IEkgY2FuJ3Qg
c2VlIHRoYXQgaGFwcGVuaW5nIGZvciA0LjIuMCBub3cgSSdtIGFmcmFpZC4gUHJvYmFibHkgYmVz
dCB0bwo+ID4gYnJpbmcgaXQgdXAgd2l0aCBHZW9yZ2UgaW4gdGhlIDQuMyB0aHJlYWQuIEl0IG1p
Z2h0IGJlIGEgY2FuZGlkYXRlIGZvcgo+ID4gNC4yLjEgZGVwZW5kaW5nIG9uIHRoZSBzaXplIG9m
IHRoZSBwYXRjaC4KPiA+IAo+IAo+IFllcC4gSWYgIm1vbml0b3IyIGlzIGVuYWJsZWQgYXMgYSBk
ZWZhdWx0IChJJ20gbm90IHN1cmUgYWJvdXQgdGhhdCksIHRoZW4gaXQncyBhIHNlY3VyaXR5IGlz
c3VlLi4gCgpSaWdodCwgd2UgKmRlZmluaXRlbHkqIG5lZWQgdG8gbWFrZSBzdXJlIHRoaXMgaXMg
bm90IHRoZSBjYXNlIGJlZm9yZQo0LjIuMC4gSSBjb25zaWRlciB0aGlzIGFzcGVjdCBvZiBtb25p
dG9yIHN1cHBvcnQgYSBibG9ja2VyLgoKPiBVc2VyIGhhdmluZyBhIFZOQyBzZXNzaW9uIHRvIHRo
ZSBjb25zb2xlIG9mIHRoZSBWTSBjYW4gcnVuIFFlbXUKPiBjb21tYW5kcywgc28gZm9yIGV4YW1w
bGUgbWFwIC5pc28gZmlsZXMgZnJvbSBkb20wIGV0Yy4uCgpJYW4uCgoKX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApY
ZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwOi8vbGlzdHMueGVuLm9yZy94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xen.org Wed Sep 05 09:41:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Sep 2012 09:41:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9C6B-0007R2-H8; Wed, 05 Sep 2012 09:40:39 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1T9C6A-0007Qt-Re
	for xen-devel@lists.xen.org; Wed, 05 Sep 2012 09:40:39 +0000
Received: from [85.158.139.83:61115] by server-11.bemta-5.messagelabs.com id
	1F/C8-24658-51E17405; Wed, 05 Sep 2012 09:40:37 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1346837936!28122186!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTE5ODY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19268 invoked from network); 5 Sep 2012 09:38:57 -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;
	5 Sep 2012 09:38:57 -0000
X-IronPort-AV: E=Sophos;i="4.80,372,1344211200"; d="scan'208";a="14353051"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Sep 2012 09:38: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.279.1; Wed, 5 Sep 2012 10:38: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
	1T9C4K-0001aP-6p; Wed, 05 Sep 2012 09:38:44 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1T9C4K-0003Su-2p;
	Wed, 05 Sep 2012 10:38:44 +0100
Date: Wed, 5 Sep 2012 10:38:44 +0100
Message-ID: <E1T9C4K-0003Su-2p@mariner.uk.xensource.com>
Content-Type: multipart/mixed; boundary="=separator"; charset="utf-8"
MIME-Version: 1.0
X-Mailer: MIME-tools 5.428 (Entity 5.428)
To: xen-announce@lists.xen.org, xen-devel@lists.xen.org,
	xen-users@lists.xen.org, oss-security@lists.openwall.com
From: Xen.org security team <security@xen.org>
Cc: "Xen.org security team" <security@xen.org>
Subject: [Xen-devel] Xen Security Advisory 12 (CVE-2012-3494) - hypercall
 set_debugreg vulnerability
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--=separator
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

            Xen Security Advisory CVE-2012-3494 / XSA-12
                             version 3

	      hypercall set_debugreg vulnerability

UPDATES IN VERSION 3
====================

Public release.

ISSUE DESCRIPTION
=================

set_debugreg allows writes to reserved bits of the DR7 debug control
register on x86-64.

IMPACT
======

A malicious guest can cause the host to crash, leading to a DoS.

If the vulnerable hypervisor is run on future hardware, the impact of
the vulnerability might be widened depending on the future assignment
of the currently-reserved debug register bits.

VULNERABLE SYSTEMS
==================

All systems running 64-bit paravirtualised guests.

The vulnerability dates back to at least Xen 4.0.  4.0, 4.1, the 4.2
RCs, and xen-unstable.hg are all vulnerable.

MITIGATION
==========

This issue can be mitigated by ensuring (inside the guest) that the
kernel is trustworthy, or by running only 32-bit or HVM guests.

RESOLUTION
==========

Applying the appropriate attached patch will resolve the issue.

PATCH INFORMATION
=================

The attached patch resolves this issue:

 Xen unstable, 4.1 and 4.0		xsa12-all.patch

$ sha256sum xsa12-all.patch
2415ee133e28b1c848c5ae3ce766cc2a67009bad8d026879030a6511b85dbc13  xsa12-all.patch
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iQEcBAEBAgAGBQJQRx0+AAoJEIP+FMlX6CvZnMAH/0fcm9nfiChokydCyqXgdKtJ
U2NqeqKzEP6emwLE+cvc+2EBP40fiBXsNATVdXc6Vx15eyzSMfJD3ndYF9OaKMVH
MVP6KU/tyK1G/9WgQK9PHBj/Kzp8hwrY0Qw45od7z+R7XMGieLH9l1O1xwkNCYDw
R8Xy2GI9IqsXLNpwy3BFYSyGYIX9o8/aBx4ZxHCV8H0OYUWv5hDGZZVXPDqGm11c
N+qmUaPV2QlW8Aoww1SiwW5E+/CpyJT5+awEMgZ4IOHPbCBXJfyXbw4aMM2q5Soe
mStqvPKL4H10SahaygdjxO+e4NqCHao0rYUXXpUr+aikIXvEearukp3FezR5IUE=
=/LmZ
-----END PGP SIGNATURE-----

--=separator
Content-Type: application/octet-stream; name="xsa12-all.patch"
Content-Disposition: attachment; filename="xsa12-all.patch"
Content-Transfer-Encoding: base64

eGVuOiBwcmV2ZW50IGEgNjQgYml0IGd1ZXN0IHNldHRpbmcgcmVzZXJ2ZWQg
Yml0cyBpbiBEUjcKClRoZSB1cHBlciAzMiBiaXRzIG9mIHRoaXMgcmVnaXN0
ZXIgYXJlIHJlc2VydmVkIGFuZCBzaG91bGQgYmUgd3JpdHRlbiBhcwp6ZXJv
LgoKVGhpcyBpcyBYU0EtMTIgLyBDVkUtMjAxMi0zNDk0CgpTaWduZWQtb2Zm
LWJ5OiBKYW4gQmV1bGljaCA8amJldWxpY2hAc3VzZS5jb20+ClJldmlld2Vk
LWJ5OiBJYW4gQ2FtcGJlbGwgPGlhbi5jYW1wYmVsbEBjaXRyaXguY29tPgoK
ZGlmZiAtciAzNTNiYzA4MDFiMTEgeGVuL2luY2x1ZGUvYXNtLXg4Ni9kZWJ1
Z3JlZy5oCi0tLSBhL3hlbi9pbmNsdWRlL2FzbS14ODYvZGVidWdyZWcuaAlN
b24gQXVnIDA2IDEyOjI4OjAzIDIwMTIgKzAxMDAKKysrIGIveGVuL2luY2x1
ZGUvYXNtLXg4Ni9kZWJ1Z3JlZy5oCVdlZCBBdWcgMTUgMTI6MDA6MjEgMjAx
MiArMDEwMApAQCAtNTgsNyArNTgsNyBAQAogICAgV2UgY2FuIHNsb3cgdGhl
IGluc3RydWN0aW9uIHBpcGVsaW5lIGZvciBpbnN0cnVjdGlvbnMgY29taW5n
IHZpYSB0aGUKICAgIGdkdCBvciB0aGUgbGR0IGlmIHdlIHdhbnQgdG8uICBJ
IGFtIG5vdCBzdXJlIHdoeSB0aGlzIGlzIGFuIGFkdmFudGFnZSAqLwogCi0j
ZGVmaW5lIERSX0NPTlRST0xfUkVTRVJWRURfWkVSTyAoMHgwMDAwZDgwMHVs
KSAvKiBSZXNlcnZlZCwgcmVhZCBhcyB6ZXJvICovCisjZGVmaW5lIERSX0NP
TlRST0xfUkVTRVJWRURfWkVSTyAofjB4ZmZmZjI3ZmZ1bCkgLyogUmVzZXJ2
ZWQsIHJlYWQgYXMgemVybyAqLwogI2RlZmluZSBEUl9DT05UUk9MX1JFU0VS
VkVEX09ORSAgKDB4MDAwMDA0MDB1bCkgLyogUmVzZXJ2ZWQsIHJlYWQgYXMg
b25lICovCiAjZGVmaW5lIERSX0xPQ0FMX0VYQUNUX0VOQUJMRSAgICAoMHgw
MDAwMDEwMHVsKSAvKiBMb2NhbCBleGFjdCBlbmFibGUgKi8KICNkZWZpbmUg
RFJfR0xPQkFMX0VYQUNUX0VOQUJMRSAgICgweDAwMDAwMjAwdWwpIC8qIEds
b2JhbCBleGFjdCBlbmFibGUgKi8K

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

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

--=separator--


From xen-devel-bounces@lists.xen.org Wed Sep 05 09:41:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Sep 2012 09:41:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9C6B-0007R2-H8; Wed, 05 Sep 2012 09:40:39 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1T9C6A-0007Qt-Re
	for xen-devel@lists.xen.org; Wed, 05 Sep 2012 09:40:39 +0000
Received: from [85.158.139.83:61115] by server-11.bemta-5.messagelabs.com id
	1F/C8-24658-51E17405; Wed, 05 Sep 2012 09:40:37 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1346837936!28122186!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTE5ODY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19268 invoked from network); 5 Sep 2012 09:38:57 -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;
	5 Sep 2012 09:38:57 -0000
X-IronPort-AV: E=Sophos;i="4.80,372,1344211200"; d="scan'208";a="14353051"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Sep 2012 09:38: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.279.1; Wed, 5 Sep 2012 10:38: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
	1T9C4K-0001aP-6p; Wed, 05 Sep 2012 09:38:44 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1T9C4K-0003Su-2p;
	Wed, 05 Sep 2012 10:38:44 +0100
Date: Wed, 5 Sep 2012 10:38:44 +0100
Message-ID: <E1T9C4K-0003Su-2p@mariner.uk.xensource.com>
Content-Type: multipart/mixed; boundary="=separator"; charset="utf-8"
MIME-Version: 1.0
X-Mailer: MIME-tools 5.428 (Entity 5.428)
To: xen-announce@lists.xen.org, xen-devel@lists.xen.org,
	xen-users@lists.xen.org, oss-security@lists.openwall.com
From: Xen.org security team <security@xen.org>
Cc: "Xen.org security team" <security@xen.org>
Subject: [Xen-devel] Xen Security Advisory 12 (CVE-2012-3494) - hypercall
 set_debugreg vulnerability
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--=separator
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

            Xen Security Advisory CVE-2012-3494 / XSA-12
                             version 3

	      hypercall set_debugreg vulnerability

UPDATES IN VERSION 3
====================

Public release.

ISSUE DESCRIPTION
=================

set_debugreg allows writes to reserved bits of the DR7 debug control
register on x86-64.

IMPACT
======

A malicious guest can cause the host to crash, leading to a DoS.

If the vulnerable hypervisor is run on future hardware, the impact of
the vulnerability might be widened depending on the future assignment
of the currently-reserved debug register bits.

VULNERABLE SYSTEMS
==================

All systems running 64-bit paravirtualised guests.

The vulnerability dates back to at least Xen 4.0.  4.0, 4.1, the 4.2
RCs, and xen-unstable.hg are all vulnerable.

MITIGATION
==========

This issue can be mitigated by ensuring (inside the guest) that the
kernel is trustworthy, or by running only 32-bit or HVM guests.

RESOLUTION
==========

Applying the appropriate attached patch will resolve the issue.

PATCH INFORMATION
=================

The attached patch resolves this issue:

 Xen unstable, 4.1 and 4.0		xsa12-all.patch

$ sha256sum xsa12-all.patch
2415ee133e28b1c848c5ae3ce766cc2a67009bad8d026879030a6511b85dbc13  xsa12-all.patch
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iQEcBAEBAgAGBQJQRx0+AAoJEIP+FMlX6CvZnMAH/0fcm9nfiChokydCyqXgdKtJ
U2NqeqKzEP6emwLE+cvc+2EBP40fiBXsNATVdXc6Vx15eyzSMfJD3ndYF9OaKMVH
MVP6KU/tyK1G/9WgQK9PHBj/Kzp8hwrY0Qw45od7z+R7XMGieLH9l1O1xwkNCYDw
R8Xy2GI9IqsXLNpwy3BFYSyGYIX9o8/aBx4ZxHCV8H0OYUWv5hDGZZVXPDqGm11c
N+qmUaPV2QlW8Aoww1SiwW5E+/CpyJT5+awEMgZ4IOHPbCBXJfyXbw4aMM2q5Soe
mStqvPKL4H10SahaygdjxO+e4NqCHao0rYUXXpUr+aikIXvEearukp3FezR5IUE=
=/LmZ
-----END PGP SIGNATURE-----

--=separator
Content-Type: application/octet-stream; name="xsa12-all.patch"
Content-Disposition: attachment; filename="xsa12-all.patch"
Content-Transfer-Encoding: base64

eGVuOiBwcmV2ZW50IGEgNjQgYml0IGd1ZXN0IHNldHRpbmcgcmVzZXJ2ZWQg
Yml0cyBpbiBEUjcKClRoZSB1cHBlciAzMiBiaXRzIG9mIHRoaXMgcmVnaXN0
ZXIgYXJlIHJlc2VydmVkIGFuZCBzaG91bGQgYmUgd3JpdHRlbiBhcwp6ZXJv
LgoKVGhpcyBpcyBYU0EtMTIgLyBDVkUtMjAxMi0zNDk0CgpTaWduZWQtb2Zm
LWJ5OiBKYW4gQmV1bGljaCA8amJldWxpY2hAc3VzZS5jb20+ClJldmlld2Vk
LWJ5OiBJYW4gQ2FtcGJlbGwgPGlhbi5jYW1wYmVsbEBjaXRyaXguY29tPgoK
ZGlmZiAtciAzNTNiYzA4MDFiMTEgeGVuL2luY2x1ZGUvYXNtLXg4Ni9kZWJ1
Z3JlZy5oCi0tLSBhL3hlbi9pbmNsdWRlL2FzbS14ODYvZGVidWdyZWcuaAlN
b24gQXVnIDA2IDEyOjI4OjAzIDIwMTIgKzAxMDAKKysrIGIveGVuL2luY2x1
ZGUvYXNtLXg4Ni9kZWJ1Z3JlZy5oCVdlZCBBdWcgMTUgMTI6MDA6MjEgMjAx
MiArMDEwMApAQCAtNTgsNyArNTgsNyBAQAogICAgV2UgY2FuIHNsb3cgdGhl
IGluc3RydWN0aW9uIHBpcGVsaW5lIGZvciBpbnN0cnVjdGlvbnMgY29taW5n
IHZpYSB0aGUKICAgIGdkdCBvciB0aGUgbGR0IGlmIHdlIHdhbnQgdG8uICBJ
IGFtIG5vdCBzdXJlIHdoeSB0aGlzIGlzIGFuIGFkdmFudGFnZSAqLwogCi0j
ZGVmaW5lIERSX0NPTlRST0xfUkVTRVJWRURfWkVSTyAoMHgwMDAwZDgwMHVs
KSAvKiBSZXNlcnZlZCwgcmVhZCBhcyB6ZXJvICovCisjZGVmaW5lIERSX0NP
TlRST0xfUkVTRVJWRURfWkVSTyAofjB4ZmZmZjI3ZmZ1bCkgLyogUmVzZXJ2
ZWQsIHJlYWQgYXMgemVybyAqLwogI2RlZmluZSBEUl9DT05UUk9MX1JFU0VS
VkVEX09ORSAgKDB4MDAwMDA0MDB1bCkgLyogUmVzZXJ2ZWQsIHJlYWQgYXMg
b25lICovCiAjZGVmaW5lIERSX0xPQ0FMX0VYQUNUX0VOQUJMRSAgICAoMHgw
MDAwMDEwMHVsKSAvKiBMb2NhbCBleGFjdCBlbmFibGUgKi8KICNkZWZpbmUg
RFJfR0xPQkFMX0VYQUNUX0VOQUJMRSAgICgweDAwMDAwMjAwdWwpIC8qIEds
b2JhbCBleGFjdCBlbmFibGUgKi8K

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

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

--=separator--


From xen-devel-bounces@lists.xen.org Wed Sep 05 09:49:28 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Sep 2012 09:49: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 1T9CES-0007pO-43; Wed, 05 Sep 2012 09:49:12 +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 1T9CEQ-0007pH-QN
	for xen-devel@lists.xen.org; Wed, 05 Sep 2012 09:49:11 +0000
Received: from [85.158.143.99:15563] by server-1.bemta-4.messagelabs.com id
	9A/2E-12504-61027405; Wed, 05 Sep 2012 09:49:10 +0000
X-Env-Sender: jonnyt@abpni.co.uk
X-Msg-Ref: server-14.tower-216.messagelabs.com!1346838549!19005758!1
X-Originating-IP: [109.200.19.114]
X-SpamReason: No, hits=0.0 required=7.0 tests=SUBJECT_EXCESS_QP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6214 invoked from network); 5 Sep 2012 09:49:09 -0000
Received: from edge1.gosport.uk.abpni.net (HELO
	mail1.gosport.uk.corp.abpni.net) (109.200.19.114)
	by server-14.tower-216.messagelabs.com with SMTP;
	5 Sep 2012 09:49:09 -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 260DF5A0006
	for <xen-devel@lists.xen.org>; Wed,  5 Sep 2012 10:48:35 +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 AVUIfUaPiAIZ for <xen-devel@lists.xen.org>;
	Wed,  5 Sep 2012 10:48:31 +0100 (BST)
Received: from mail.abpni.co.uk (unknown [10.87.17.3])
	by mail1.gosport.uk.corp.abpni.net (Postfix) with ESMTPA id 9DDBD5A0005
	for <xen-devel@lists.xen.org>; Wed,  5 Sep 2012 10:48:31 +0100 (BST)
MIME-Version: 1.0
Date: Wed, 05 Sep 2012 10:49:02 +0100
From: Jonathan Tripathy <jonnyt@abpni.co.uk>
To: <xen-devel@lists.xen.org>
In-Reply-To: <E1T9C4K-0003Su-2p@mariner.uk.xensource.com>
References: <E1T9C4K-0003Su-2p@mariner.uk.xensource.com>
Message-ID: <4cb9d7f220dd459c1554c6b5d9e2ed73@abpni.co.uk>
X-Sender: jonnyt@abpni.co.uk
User-Agent: Roundcube Webmail/0.6
Subject: Re: [Xen-devel]
 =?utf-8?q?Xen_Security_Advisory_12_=28CVE-2012-3494?=
 =?utf-8?q?=29_-_hypercall_set=5Fdebugreg_vulnerability?=
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Is Xen 3.4.x vulnerable?

Thanks

On 05.09.2012 10:38, Xen.org security team wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>             Xen Security Advisory CVE-2012-3494 / XSA-12
>                              version 3
>
> 	      hypercall set_debugreg vulnerability
>
> UPDATES IN VERSION 3
> ====================
>
> Public release.
>
> ISSUE DESCRIPTION
> =================
>
> set_debugreg allows writes to reserved bits of the DR7 debug control
> register on x86-64.
>
> IMPACT
> ======
>
> A malicious guest can cause the host to crash, leading to a DoS.
>
> If the vulnerable hypervisor is run on future hardware, the impact of
> the vulnerability might be widened depending on the future assignment
> of the currently-reserved debug register bits.
>
> VULNERABLE SYSTEMS
> ==================
>
> All systems running 64-bit paravirtualised guests.
>
> The vulnerability dates back to at least Xen 4.0.  4.0, 4.1, the 4.2
> RCs, and xen-unstable.hg are all vulnerable.
>
> MITIGATION
> ==========
>
> This issue can be mitigated by ensuring (inside the guest) that the
> kernel is trustworthy, or by running only 32-bit or HVM guests.
>
> RESOLUTION
> ==========
>
> Applying the appropriate attached patch will resolve the issue.
>
> PATCH INFORMATION
> =================
>
> The attached patch resolves this issue:
>
>  Xen unstable, 4.1 and 4.0		xsa12-all.patch
>
> $ sha256sum xsa12-all.patch
> 2415ee133e28b1c848c5ae3ce766cc2a67009bad8d026879030a6511b85dbc13
> xsa12-all.patch
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (GNU/Linux)
>
> iQEcBAEBAgAGBQJQRx0+AAoJEIP+FMlX6CvZnMAH/0fcm9nfiChokydCyqXgdKtJ
> U2NqeqKzEP6emwLE+cvc+2EBP40fiBXsNATVdXc6Vx15eyzSMfJD3ndYF9OaKMVH
> MVP6KU/tyK1G/9WgQK9PHBj/Kzp8hwrY0Qw45od7z+R7XMGieLH9l1O1xwkNCYDw
> R8Xy2GI9IqsXLNpwy3BFYSyGYIX9o8/aBx4ZxHCV8H0OYUWv5hDGZZVXPDqGm11c
> N+qmUaPV2QlW8Aoww1SiwW5E+/CpyJT5+awEMgZ4IOHPbCBXJfyXbw4aMM2q5Soe
> mStqvPKL4H10SahaygdjxO+e4NqCHao0rYUXXpUr+aikIXvEearukp3FezR5IUE=
> =/LmZ
> -----END PGP SIGNATURE-----


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

From xen-devel-bounces@lists.xen.org Wed Sep 05 09:49:28 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Sep 2012 09:49: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 1T9CES-0007pO-43; Wed, 05 Sep 2012 09:49:12 +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 1T9CEQ-0007pH-QN
	for xen-devel@lists.xen.org; Wed, 05 Sep 2012 09:49:11 +0000
Received: from [85.158.143.99:15563] by server-1.bemta-4.messagelabs.com id
	9A/2E-12504-61027405; Wed, 05 Sep 2012 09:49:10 +0000
X-Env-Sender: jonnyt@abpni.co.uk
X-Msg-Ref: server-14.tower-216.messagelabs.com!1346838549!19005758!1
X-Originating-IP: [109.200.19.114]
X-SpamReason: No, hits=0.0 required=7.0 tests=SUBJECT_EXCESS_QP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6214 invoked from network); 5 Sep 2012 09:49:09 -0000
Received: from edge1.gosport.uk.abpni.net (HELO
	mail1.gosport.uk.corp.abpni.net) (109.200.19.114)
	by server-14.tower-216.messagelabs.com with SMTP;
	5 Sep 2012 09:49:09 -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 260DF5A0006
	for <xen-devel@lists.xen.org>; Wed,  5 Sep 2012 10:48:35 +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 AVUIfUaPiAIZ for <xen-devel@lists.xen.org>;
	Wed,  5 Sep 2012 10:48:31 +0100 (BST)
Received: from mail.abpni.co.uk (unknown [10.87.17.3])
	by mail1.gosport.uk.corp.abpni.net (Postfix) with ESMTPA id 9DDBD5A0005
	for <xen-devel@lists.xen.org>; Wed,  5 Sep 2012 10:48:31 +0100 (BST)
MIME-Version: 1.0
Date: Wed, 05 Sep 2012 10:49:02 +0100
From: Jonathan Tripathy <jonnyt@abpni.co.uk>
To: <xen-devel@lists.xen.org>
In-Reply-To: <E1T9C4K-0003Su-2p@mariner.uk.xensource.com>
References: <E1T9C4K-0003Su-2p@mariner.uk.xensource.com>
Message-ID: <4cb9d7f220dd459c1554c6b5d9e2ed73@abpni.co.uk>
X-Sender: jonnyt@abpni.co.uk
User-Agent: Roundcube Webmail/0.6
Subject: Re: [Xen-devel]
 =?utf-8?q?Xen_Security_Advisory_12_=28CVE-2012-3494?=
 =?utf-8?q?=29_-_hypercall_set=5Fdebugreg_vulnerability?=
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Is Xen 3.4.x vulnerable?

Thanks

On 05.09.2012 10:38, Xen.org security team wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>             Xen Security Advisory CVE-2012-3494 / XSA-12
>                              version 3
>
> 	      hypercall set_debugreg vulnerability
>
> UPDATES IN VERSION 3
> ====================
>
> Public release.
>
> ISSUE DESCRIPTION
> =================
>
> set_debugreg allows writes to reserved bits of the DR7 debug control
> register on x86-64.
>
> IMPACT
> ======
>
> A malicious guest can cause the host to crash, leading to a DoS.
>
> If the vulnerable hypervisor is run on future hardware, the impact of
> the vulnerability might be widened depending on the future assignment
> of the currently-reserved debug register bits.
>
> VULNERABLE SYSTEMS
> ==================
>
> All systems running 64-bit paravirtualised guests.
>
> The vulnerability dates back to at least Xen 4.0.  4.0, 4.1, the 4.2
> RCs, and xen-unstable.hg are all vulnerable.
>
> MITIGATION
> ==========
>
> This issue can be mitigated by ensuring (inside the guest) that the
> kernel is trustworthy, or by running only 32-bit or HVM guests.
>
> RESOLUTION
> ==========
>
> Applying the appropriate attached patch will resolve the issue.
>
> PATCH INFORMATION
> =================
>
> The attached patch resolves this issue:
>
>  Xen unstable, 4.1 and 4.0		xsa12-all.patch
>
> $ sha256sum xsa12-all.patch
> 2415ee133e28b1c848c5ae3ce766cc2a67009bad8d026879030a6511b85dbc13
> xsa12-all.patch
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (GNU/Linux)
>
> iQEcBAEBAgAGBQJQRx0+AAoJEIP+FMlX6CvZnMAH/0fcm9nfiChokydCyqXgdKtJ
> U2NqeqKzEP6emwLE+cvc+2EBP40fiBXsNATVdXc6Vx15eyzSMfJD3ndYF9OaKMVH
> MVP6KU/tyK1G/9WgQK9PHBj/Kzp8hwrY0Qw45od7z+R7XMGieLH9l1O1xwkNCYDw
> R8Xy2GI9IqsXLNpwy3BFYSyGYIX9o8/aBx4ZxHCV8H0OYUWv5hDGZZVXPDqGm11c
> N+qmUaPV2QlW8Aoww1SiwW5E+/CpyJT5+awEMgZ4IOHPbCBXJfyXbw4aMM2q5Soe
> mStqvPKL4H10SahaygdjxO+e4NqCHao0rYUXXpUr+aikIXvEearukp3FezR5IUE=
> =/LmZ
> -----END PGP SIGNATURE-----


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

From xen-devel-bounces@lists.xen.org Wed Sep 05 09:52:42 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Sep 2012 09:52:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9CHX-00081E-Tn; Wed, 05 Sep 2012 09:52:23 +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 1T9CHW-000816-Sq
	for xen-devel@lists.xen.org; Wed, 05 Sep 2012 09:52:23 +0000
Received: from [85.158.138.51:3489] by server-9.bemta-3.messagelabs.com id
	0B/37-15390-5D027405; Wed, 05 Sep 2012 09:52:21 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1346838732!24693551!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNzY4NTA=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2675 invoked from network); 5 Sep 2012 09:52:14 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-10.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Sep 2012 09:52:14 -0000
X-IronPort-AV: E=Sophos;i="4.80,372,1344211200"; 
	d="scan'208,217";a="207118374"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Sep 2012 09:52:12 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 5 Sep 2012 05:52:12 -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 1T9CHM-00083Q-0v	for
	xen-devel@lists.xen.org; Wed, 05 Sep 2012 10:52:12 +0100
Message-ID: <504720CB.8060906@citrix.com>
Date: Wed, 5 Sep 2012 10:52:11 +0100
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:14.0) Gecko/20120714 Thunderbird/14.0
MIME-Version: 1.0
To: xen-devel@lists.xen.org
References: <E1T9C4K-0003Su-2p@mariner.uk.xensource.com>
	<4cb9d7f220dd459c1554c6b5d9e2ed73@abpni.co.uk>
In-Reply-To: <4cb9d7f220dd459c1554c6b5d9e2ed73@abpni.co.uk>
X-Enigmail-Version: 1.4.4
Subject: Re: [Xen-devel] Xen Security Advisory 12 (CVE-2012-3494) -
 hypercall set_debugreg vulnerability
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============3577610866476055842=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============3577610866476055842==
Content-Type: multipart/alternative;
	boundary="------------070103020307040001070608"

--------------070103020307040001070608
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit


On 05/09/12 10:49, Jonathan Tripathy wrote:
> Is Xen 3.4.x vulnerable?
>
> Thanks

Yes - Vulnerable (tested and fixed) all the way back as far as Xen-3.2
(which is the earliest version that XenServer still creates security
fixes for)

~Andrew

>
> On 05.09.2012 10:38, Xen.org security team wrote:
> Xen Security Advisory CVE-2012-3494 / XSA-12
> version 3
>
> hypercall set_debugreg vulnerability
>
> UPDATES IN VERSION 3
> ====================
>
> Public release.
>
> ISSUE DESCRIPTION
> =================
>
> set_debugreg allows writes to reserved bits of the DR7 debug control
> register on x86-64.
>
> IMPACT
> ======
>
> A malicious guest can cause the host to crash, leading to a DoS.
>
> If the vulnerable hypervisor is run on future hardware, the impact of
> the vulnerability might be widened depending on the future assignment
> of the currently-reserved debug register bits.
>
> VULNERABLE SYSTEMS
> ==================
>
> All systems running 64-bit paravirtualised guests.
>
> The vulnerability dates back to at least Xen 4.0. 4.0, 4.1, the 4.2
> RCs, and xen-unstable.hg are all vulnerable.
>
> MITIGATION
> ==========
>
> This issue can be mitigated by ensuring (inside the guest) that the
> kernel is trustworthy, or by running only 32-bit or HVM guests.
>
> RESOLUTION
> ==========
>
> Applying the appropriate attached patch will resolve the issue.
>
> PATCH INFORMATION
> =================
>
> The attached patch resolves this issue:
>
> Xen unstable, 4.1 and 4.0 xsa12-all.patch
>
> $ sha256sum xsa12-all.patch
> 2415ee133e28b1c848c5ae3ce766cc2a67009bad8d026879030a6511b85dbc13
> xsa12-all.patch
>
>
> _______________________________________________
> 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


--------------070103020307040001070608
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">
    <br>
    On 05/09/12 10:49, Jonathan Tripathy wrote:<br>
    <span style="white-space: pre;">&gt; Is Xen 3.4.x vulnerable?<br>
      &gt;<br>
      &gt; Thanks</span><br>
    <br>
    Yes - Vulnerable (tested and fixed) all the way back as far as
    Xen-3.2 (which is the earliest version that XenServer still creates
    security fixes for)<br>
    <br>
    ~Andrew<br>
    <br>
    <span style="white-space: pre;">&gt;<br>
      &gt; On 05.09.2012 10:38, Xen.org security team wrote:<br>
      &gt; Xen Security Advisory CVE-2012-3494 / XSA-12<br>
      &gt; version 3<br>
      &gt;<br>
      &gt; hypercall set_debugreg vulnerability<br>
      &gt;<br>
      &gt; UPDATES IN VERSION 3<br>
      &gt; ====================<br>
      &gt;<br>
      &gt; Public release.<br>
      &gt;<br>
      &gt; ISSUE DESCRIPTION<br>
      &gt; =================<br>
      &gt;<br>
      &gt; set_debugreg allows writes to reserved bits of the DR7 debug
      control<br>
      &gt; register on x86-64.<br>
      &gt;<br>
      &gt; IMPACT<br>
      &gt; ======<br>
      &gt;<br>
      &gt; A malicious guest can cause the host to crash, leading to a
      DoS.<br>
      &gt;<br>
      &gt; If the vulnerable hypervisor is run on future hardware, the
      impact of<br>
      &gt; the vulnerability might be widened depending on the future
      assignment<br>
      &gt; of the currently-reserved debug register bits.<br>
      &gt;<br>
      &gt; VULNERABLE SYSTEMS<br>
      &gt; ==================<br>
      &gt;<br>
      &gt; All systems running 64-bit paravirtualised guests.<br>
      &gt;<br>
      &gt; The vulnerability dates back to at least Xen 4.0. 4.0, 4.1,
      the 4.2<br>
      &gt; RCs, and xen-unstable.hg are all vulnerable.<br>
      &gt;<br>
      &gt; MITIGATION<br>
      &gt; ==========<br>
      &gt;<br>
      &gt; This issue can be mitigated by ensuring (inside the guest)
      that the<br>
      &gt; kernel is trustworthy, or by running only 32-bit or HVM
      guests.<br>
      &gt;<br>
      &gt; RESOLUTION<br>
      &gt; ==========<br>
      &gt;<br>
      &gt; Applying the appropriate attached patch will resolve the
      issue.<br>
      &gt;<br>
      &gt; PATCH INFORMATION<br>
      &gt; =================<br>
      &gt;<br>
      &gt; The attached patch resolves this issue:<br>
      &gt;<br>
      &gt; Xen unstable, 4.1 and 4.0 xsa12-all.patch<br>
      &gt;<br>
      &gt; $ sha256sum xsa12-all.patch<br>
      &gt;
      2415ee133e28b1c848c5ae3ce766cc2a67009bad8d026879030a6511b85dbc13<br>
      &gt; xsa12-all.patch<br>
      &gt;<br>
      &gt;<br>
      &gt; _______________________________________________<br>
      &gt; Xen-devel mailing list<br>
      &gt; <a class="moz-txt-link-abbreviated" href="mailto:Xen-devel@lists.xen.org">Xen-devel@lists.xen.org</a><br>
      &gt; <a class="moz-txt-link-freetext" href="http://lists.xen.org/xen-devel">http://lists.xen.org/xen-devel</a></span><br>
    <br>
    -- <br>
    Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer<br>
    T: +44 (0)1223 225 900, <a class="moz-txt-link-freetext" href="http://www.citrix.com">http://www.citrix.com</a><br>
    <br>
  </body>
</html>

--------------070103020307040001070608--


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

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

--===============3577610866476055842==--


From xen-devel-bounces@lists.xen.org Wed Sep 05 09:52:42 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Sep 2012 09:52:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9CHX-00081E-Tn; Wed, 05 Sep 2012 09:52:23 +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 1T9CHW-000816-Sq
	for xen-devel@lists.xen.org; Wed, 05 Sep 2012 09:52:23 +0000
Received: from [85.158.138.51:3489] by server-9.bemta-3.messagelabs.com id
	0B/37-15390-5D027405; Wed, 05 Sep 2012 09:52:21 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1346838732!24693551!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNzY4NTA=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2675 invoked from network); 5 Sep 2012 09:52:14 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-10.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Sep 2012 09:52:14 -0000
X-IronPort-AV: E=Sophos;i="4.80,372,1344211200"; 
	d="scan'208,217";a="207118374"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Sep 2012 09:52:12 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 5 Sep 2012 05:52:12 -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 1T9CHM-00083Q-0v	for
	xen-devel@lists.xen.org; Wed, 05 Sep 2012 10:52:12 +0100
Message-ID: <504720CB.8060906@citrix.com>
Date: Wed, 5 Sep 2012 10:52:11 +0100
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:14.0) Gecko/20120714 Thunderbird/14.0
MIME-Version: 1.0
To: xen-devel@lists.xen.org
References: <E1T9C4K-0003Su-2p@mariner.uk.xensource.com>
	<4cb9d7f220dd459c1554c6b5d9e2ed73@abpni.co.uk>
In-Reply-To: <4cb9d7f220dd459c1554c6b5d9e2ed73@abpni.co.uk>
X-Enigmail-Version: 1.4.4
Subject: Re: [Xen-devel] Xen Security Advisory 12 (CVE-2012-3494) -
 hypercall set_debugreg vulnerability
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============3577610866476055842=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============3577610866476055842==
Content-Type: multipart/alternative;
	boundary="------------070103020307040001070608"

--------------070103020307040001070608
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit


On 05/09/12 10:49, Jonathan Tripathy wrote:
> Is Xen 3.4.x vulnerable?
>
> Thanks

Yes - Vulnerable (tested and fixed) all the way back as far as Xen-3.2
(which is the earliest version that XenServer still creates security
fixes for)

~Andrew

>
> On 05.09.2012 10:38, Xen.org security team wrote:
> Xen Security Advisory CVE-2012-3494 / XSA-12
> version 3
>
> hypercall set_debugreg vulnerability
>
> UPDATES IN VERSION 3
> ====================
>
> Public release.
>
> ISSUE DESCRIPTION
> =================
>
> set_debugreg allows writes to reserved bits of the DR7 debug control
> register on x86-64.
>
> IMPACT
> ======
>
> A malicious guest can cause the host to crash, leading to a DoS.
>
> If the vulnerable hypervisor is run on future hardware, the impact of
> the vulnerability might be widened depending on the future assignment
> of the currently-reserved debug register bits.
>
> VULNERABLE SYSTEMS
> ==================
>
> All systems running 64-bit paravirtualised guests.
>
> The vulnerability dates back to at least Xen 4.0. 4.0, 4.1, the 4.2
> RCs, and xen-unstable.hg are all vulnerable.
>
> MITIGATION
> ==========
>
> This issue can be mitigated by ensuring (inside the guest) that the
> kernel is trustworthy, or by running only 32-bit or HVM guests.
>
> RESOLUTION
> ==========
>
> Applying the appropriate attached patch will resolve the issue.
>
> PATCH INFORMATION
> =================
>
> The attached patch resolves this issue:
>
> Xen unstable, 4.1 and 4.0 xsa12-all.patch
>
> $ sha256sum xsa12-all.patch
> 2415ee133e28b1c848c5ae3ce766cc2a67009bad8d026879030a6511b85dbc13
> xsa12-all.patch
>
>
> _______________________________________________
> 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


--------------070103020307040001070608
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">
    <br>
    On 05/09/12 10:49, Jonathan Tripathy wrote:<br>
    <span style="white-space: pre;">&gt; Is Xen 3.4.x vulnerable?<br>
      &gt;<br>
      &gt; Thanks</span><br>
    <br>
    Yes - Vulnerable (tested and fixed) all the way back as far as
    Xen-3.2 (which is the earliest version that XenServer still creates
    security fixes for)<br>
    <br>
    ~Andrew<br>
    <br>
    <span style="white-space: pre;">&gt;<br>
      &gt; On 05.09.2012 10:38, Xen.org security team wrote:<br>
      &gt; Xen Security Advisory CVE-2012-3494 / XSA-12<br>
      &gt; version 3<br>
      &gt;<br>
      &gt; hypercall set_debugreg vulnerability<br>
      &gt;<br>
      &gt; UPDATES IN VERSION 3<br>
      &gt; ====================<br>
      &gt;<br>
      &gt; Public release.<br>
      &gt;<br>
      &gt; ISSUE DESCRIPTION<br>
      &gt; =================<br>
      &gt;<br>
      &gt; set_debugreg allows writes to reserved bits of the DR7 debug
      control<br>
      &gt; register on x86-64.<br>
      &gt;<br>
      &gt; IMPACT<br>
      &gt; ======<br>
      &gt;<br>
      &gt; A malicious guest can cause the host to crash, leading to a
      DoS.<br>
      &gt;<br>
      &gt; If the vulnerable hypervisor is run on future hardware, the
      impact of<br>
      &gt; the vulnerability might be widened depending on the future
      assignment<br>
      &gt; of the currently-reserved debug register bits.<br>
      &gt;<br>
      &gt; VULNERABLE SYSTEMS<br>
      &gt; ==================<br>
      &gt;<br>
      &gt; All systems running 64-bit paravirtualised guests.<br>
      &gt;<br>
      &gt; The vulnerability dates back to at least Xen 4.0. 4.0, 4.1,
      the 4.2<br>
      &gt; RCs, and xen-unstable.hg are all vulnerable.<br>
      &gt;<br>
      &gt; MITIGATION<br>
      &gt; ==========<br>
      &gt;<br>
      &gt; This issue can be mitigated by ensuring (inside the guest)
      that the<br>
      &gt; kernel is trustworthy, or by running only 32-bit or HVM
      guests.<br>
      &gt;<br>
      &gt; RESOLUTION<br>
      &gt; ==========<br>
      &gt;<br>
      &gt; Applying the appropriate attached patch will resolve the
      issue.<br>
      &gt;<br>
      &gt; PATCH INFORMATION<br>
      &gt; =================<br>
      &gt;<br>
      &gt; The attached patch resolves this issue:<br>
      &gt;<br>
      &gt; Xen unstable, 4.1 and 4.0 xsa12-all.patch<br>
      &gt;<br>
      &gt; $ sha256sum xsa12-all.patch<br>
      &gt;
      2415ee133e28b1c848c5ae3ce766cc2a67009bad8d026879030a6511b85dbc13<br>
      &gt; xsa12-all.patch<br>
      &gt;<br>
      &gt;<br>
      &gt; _______________________________________________<br>
      &gt; Xen-devel mailing list<br>
      &gt; <a class="moz-txt-link-abbreviated" href="mailto:Xen-devel@lists.xen.org">Xen-devel@lists.xen.org</a><br>
      &gt; <a class="moz-txt-link-freetext" href="http://lists.xen.org/xen-devel">http://lists.xen.org/xen-devel</a></span><br>
    <br>
    -- <br>
    Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer<br>
    T: +44 (0)1223 225 900, <a class="moz-txt-link-freetext" href="http://www.citrix.com">http://www.citrix.com</a><br>
    <br>
  </body>
</html>

--------------070103020307040001070608--


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

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

--===============3577610866476055842==--


From xen-devel-bounces@lists.xen.org Wed Sep 05 09:56:38 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Sep 2012 09: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 1T9CLR-0008Do-Jd; Wed, 05 Sep 2012 09:56:25 +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 1T9CLQ-0008Dg-F0
	for xen-devel@lists.xen.org; Wed, 05 Sep 2012 09:56:24 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1346838978!8836025!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQwMzE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1242 invoked from network); 5 Sep 2012 09:56:18 -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;
	5 Sep 2012 09:56:18 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 05 Sep 2012 10:56:17 +0100
Message-Id: <50473E170200007800098B7F@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 05 Sep 2012 10:57:11 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Jonathan Tripathy" <jonnyt@abpni.co.uk>
References: <E1T9C4K-0003Su-2p@mariner.uk.xensource.com>
	<4cb9d7f220dd459c1554c6b5d9e2ed73@abpni.co.uk>
In-Reply-To: <4cb9d7f220dd459c1554c6b5d9e2ed73@abpni.co.uk>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Xen Security Advisory 12 (CVE-2012-3494) -
 hypercall set_debugreg vulnerability
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.09.12 at 11:49, Jonathan Tripathy <jonnyt@abpni.co.uk> wrote:
> Is Xen 3.4.x vulnerable?

All versions supporting x86-64 are vulnerable afaict (checked back
to 3.2.x, but I suppose even 3.0.x would be affected).

Jan


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

From xen-devel-bounces@lists.xen.org Wed Sep 05 09:56:38 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Sep 2012 09: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 1T9CLR-0008Do-Jd; Wed, 05 Sep 2012 09:56:25 +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 1T9CLQ-0008Dg-F0
	for xen-devel@lists.xen.org; Wed, 05 Sep 2012 09:56:24 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1346838978!8836025!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQwMzE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1242 invoked from network); 5 Sep 2012 09:56:18 -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;
	5 Sep 2012 09:56:18 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 05 Sep 2012 10:56:17 +0100
Message-Id: <50473E170200007800098B7F@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 05 Sep 2012 10:57:11 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Jonathan Tripathy" <jonnyt@abpni.co.uk>
References: <E1T9C4K-0003Su-2p@mariner.uk.xensource.com>
	<4cb9d7f220dd459c1554c6b5d9e2ed73@abpni.co.uk>
In-Reply-To: <4cb9d7f220dd459c1554c6b5d9e2ed73@abpni.co.uk>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Xen Security Advisory 12 (CVE-2012-3494) -
 hypercall set_debugreg vulnerability
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.09.12 at 11:49, Jonathan Tripathy <jonnyt@abpni.co.uk> wrote:
> Is Xen 3.4.x vulnerable?

All versions supporting x86-64 are vulnerable afaict (checked back
to 3.2.x, but I suppose even 3.0.x would be affected).

Jan


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

From xen-devel-bounces@lists.xen.org Wed Sep 05 10:02:09 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Sep 2012 10: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 1T9CQl-0008S7-Cn; Wed, 05 Sep 2012 10:01: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 1T9CQj-0008Rw-Eo
	for xen-devel@lists.xensource.com; Wed, 05 Sep 2012 10:01:53 +0000
Received: from [85.158.138.51:30925] by server-9.bemta-3.messagelabs.com id
	F1/75-15390-01327405; Wed, 05 Sep 2012 10:01:52 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1346839310!26976412!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTE5ODY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15611 invoked from network); 5 Sep 2012 10:01:51 -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;
	5 Sep 2012 10:01:51 -0000
X-IronPort-AV: E=Sophos;i="4.80,372,1344211200"; d="scan'208";a="14353747"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Sep 2012 10:01: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.279.1; Wed, 5 Sep 2012 11:01:49 +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 1T9CQf-0001nV-Pj;
	Wed, 05 Sep 2012 10:01:49 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1T9CQf-0006Cx-PB;
	Wed, 05 Sep 2012 11:01:49 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-13648-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 5 Sep 2012 11:01:49 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13648: 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 13648 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13648/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-win       8 guest-saverestore           fail pass in 13647

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore            fail   like 13647
 test-i386-i386-xl-qemuu-winxpsp3  9 guest-localmigrate         fail like 13647
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail like 13647
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail like 13647

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

version targeted for testing:
 xen                  9dc729b75595
baseline version:
 xen                  9dc729b75595

jobs:
 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                                 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                                     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 Sep 05 10:02:09 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Sep 2012 10: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 1T9CQl-0008S7-Cn; Wed, 05 Sep 2012 10:01: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 1T9CQj-0008Rw-Eo
	for xen-devel@lists.xensource.com; Wed, 05 Sep 2012 10:01:53 +0000
Received: from [85.158.138.51:30925] by server-9.bemta-3.messagelabs.com id
	F1/75-15390-01327405; Wed, 05 Sep 2012 10:01:52 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1346839310!26976412!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTE5ODY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15611 invoked from network); 5 Sep 2012 10:01:51 -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;
	5 Sep 2012 10:01:51 -0000
X-IronPort-AV: E=Sophos;i="4.80,372,1344211200"; d="scan'208";a="14353747"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Sep 2012 10:01: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.279.1; Wed, 5 Sep 2012 11:01:49 +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 1T9CQf-0001nV-Pj;
	Wed, 05 Sep 2012 10:01:49 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1T9CQf-0006Cx-PB;
	Wed, 05 Sep 2012 11:01:49 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-13648-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 5 Sep 2012 11:01:49 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13648: 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 13648 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13648/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-win       8 guest-saverestore           fail pass in 13647

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore            fail   like 13647
 test-i386-i386-xl-qemuu-winxpsp3  9 guest-localmigrate         fail like 13647
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail like 13647
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail like 13647

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

version targeted for testing:
 xen                  9dc729b75595
baseline version:
 xen                  9dc729b75595

jobs:
 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                                 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                                     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 Sep 05 10:13:33 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Sep 2012 10:13: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 1T9Cbl-0000Ws-8L; Wed, 05 Sep 2012 10:13:17 +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 1T9Cbk-0000WS-9S
	for xen-devel@lists.xen.org; Wed, 05 Sep 2012 10:13:16 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1346839990!8968957!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQwMzE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6174 invoked from network); 5 Sep 2012 10:13:10 -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;
	5 Sep 2012 10:13:10 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 05 Sep 2012 11:13:09 +0100
Message-Id: <5047420A0200007800098BB1@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 05 Sep 2012 11:14:02 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Sander Eikelenboom" <linux@eikelenboom.it>
References: <40501859.20120902104331@eikelenboom.it>
	<CC6932C2.3D99D%keir.xen@gmail.com>
	<217459398.20120902171441@eikelenboom.it> <5044CAD7.8030800@amd.com>
	<1144695277.20120904184345@eikelenboom.it>
In-Reply-To: <1144695277.20120904184345@eikelenboom.it>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Wei Wang <wei.wang2@amd.com>, Keir Fraser <keir.xen@gmail.com>,
	Santosh Jodh <Santosh.Jodh@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Using debug-key 'o:  Dump IOMMU p2m table,
 locks up machine
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.09.12 at 18:43, Sander Eikelenboom <linux@eikelenboom.it> wrote:
>> Did you also update xen tools accordingly? Sometime I also saw a few 
>> IO_PAGE_FAULTs came from nic if my tools version and HV version did not 
>> match. But using recent 4.2 and corresponding xl, my tests went well.
>> BTW: You could also try iommu=no-sharept to see if it helps.
> 
> Tried it and it doesn't help.
> I now even got a "xl dmesg" which shows a IO_PAGE_FAULT occuring very early, 
> before any toolstack or guest can be involved:
> 
> (XEN) [2012-09-04 15:51:17] AMD-Vi: Setup I/O page table: device id = 0x0a05, 
> root table = 0x24d84b000, domain = 0, paging mode = 3
> (XEN) [2012-09-04 15:51:17] AMD-Vi: Setup I/O page table: device id = 0x0a06, 
> root table = 0x24d84b000, domain = 0, paging mode = 3
> (XEN) [2012-09-04 15:51:17] AMD-Vi: Setup I/O page table: device id = 0x0a07, 
> root table = 0x24d84b000, domain = 0, paging mode = 3
> (XEN) [2012-09-04 15:51:17] AMD-Vi: Setup I/O page table: device id = 0x0b00, 
> root table = 0x24d84b000, domain = 0, paging mode = 3
> (XEN) [2012-09-04 15:51:17] Scrubbing Free RAM: 
> ...........................<0>AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 
> 0x0a06, fault address = 0xc2c2c2c0

Looks like use of uninitialized memory (assuming you're using a
debug hypervisor, that's the pattern scrub_one_page() puts
there). But it's unclear to me what device should be doing any
I/O at that point (and even if one does, how it would get the
bad address loaded). What is 0a:00.6?

Jan


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

From xen-devel-bounces@lists.xen.org Wed Sep 05 10:13:33 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Sep 2012 10:13: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 1T9Cbl-0000Ws-8L; Wed, 05 Sep 2012 10:13:17 +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 1T9Cbk-0000WS-9S
	for xen-devel@lists.xen.org; Wed, 05 Sep 2012 10:13:16 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1346839990!8968957!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQwMzE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6174 invoked from network); 5 Sep 2012 10:13:10 -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;
	5 Sep 2012 10:13:10 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 05 Sep 2012 11:13:09 +0100
Message-Id: <5047420A0200007800098BB1@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 05 Sep 2012 11:14:02 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Sander Eikelenboom" <linux@eikelenboom.it>
References: <40501859.20120902104331@eikelenboom.it>
	<CC6932C2.3D99D%keir.xen@gmail.com>
	<217459398.20120902171441@eikelenboom.it> <5044CAD7.8030800@amd.com>
	<1144695277.20120904184345@eikelenboom.it>
In-Reply-To: <1144695277.20120904184345@eikelenboom.it>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Wei Wang <wei.wang2@amd.com>, Keir Fraser <keir.xen@gmail.com>,
	Santosh Jodh <Santosh.Jodh@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Using debug-key 'o:  Dump IOMMU p2m table,
 locks up machine
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.09.12 at 18:43, Sander Eikelenboom <linux@eikelenboom.it> wrote:
>> Did you also update xen tools accordingly? Sometime I also saw a few 
>> IO_PAGE_FAULTs came from nic if my tools version and HV version did not 
>> match. But using recent 4.2 and corresponding xl, my tests went well.
>> BTW: You could also try iommu=no-sharept to see if it helps.
> 
> Tried it and it doesn't help.
> I now even got a "xl dmesg" which shows a IO_PAGE_FAULT occuring very early, 
> before any toolstack or guest can be involved:
> 
> (XEN) [2012-09-04 15:51:17] AMD-Vi: Setup I/O page table: device id = 0x0a05, 
> root table = 0x24d84b000, domain = 0, paging mode = 3
> (XEN) [2012-09-04 15:51:17] AMD-Vi: Setup I/O page table: device id = 0x0a06, 
> root table = 0x24d84b000, domain = 0, paging mode = 3
> (XEN) [2012-09-04 15:51:17] AMD-Vi: Setup I/O page table: device id = 0x0a07, 
> root table = 0x24d84b000, domain = 0, paging mode = 3
> (XEN) [2012-09-04 15:51:17] AMD-Vi: Setup I/O page table: device id = 0x0b00, 
> root table = 0x24d84b000, domain = 0, paging mode = 3
> (XEN) [2012-09-04 15:51:17] Scrubbing Free RAM: 
> ...........................<0>AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 
> 0x0a06, fault address = 0xc2c2c2c0

Looks like use of uninitialized memory (assuming you're using a
debug hypervisor, that's the pattern scrub_one_page() puts
there). But it's unclear to me what device should be doing any
I/O at that point (and even if one does, how it would get the
bad address loaded). What is 0a:00.6?

Jan


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

From xen-devel-bounces@lists.xen.org Wed Sep 05 10:14:27 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Sep 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 1T9Ccd-0000dA-QE; Wed, 05 Sep 2012 10:14: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 1T9Ccb-0000c6-IO; Wed, 05 Sep 2012 10:14:09 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1346840028!8841583!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTE5ODY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32669 invoked from network); 5 Sep 2012 10:13:50 -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;
	5 Sep 2012 10:13:50 -0000
X-IronPort-AV: E=Sophos;i="4.80,372,1344211200"; d="scan'208";a="14354132"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Sep 2012 10:13: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.279.1; Wed, 5 Sep 2012 11:13: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
	1T9Cbz-0001sP-5Y; Wed, 05 Sep 2012 10:13:31 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1T9Cbz-0003ZK-24;
	Wed, 05 Sep 2012 11:13:31 +0100
Date: Wed, 5 Sep 2012 11:13:31 +0100
Message-ID: <E1T9Cbz-0003ZK-24@mariner.uk.xensource.com>
Content-Type: multipart/mixed; boundary="=separator"; charset="utf-8"
MIME-Version: 1.0
X-Mailer: MIME-tools 5.428 (Entity 5.428)
To: xen-announce@lists.xen.org, xen-devel@lists.xen.org,
	xen-users@lists.xen.org, oss-security@lists.openwall.com
From: Xen.org security team <security@xen.org>
Cc: "Xen.org security team" <security@xen.org>
Subject: [Xen-devel] Xen Security Advisory 13 (CVE-2012-3495) - hypercall
 physdev_get_free_pirq vulnerability
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--=separator
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

            Xen Security Advisory CVE-2012-3495 / XSA-13
                             version 3

           hypercall physdev_get_free_pirq vulnerability

UPDATES IN VERSION 3
====================

Public release.  Credit Matthew Daley.

ISSUE DESCRIPTION
=================

PHYSDEVOP_get_free_pirq does not check that its call to get_free_pirq
succeeded, and if it fails will use the error code as an array index.

IMPACT
======

A malicious guest might be able to cause the host to crash, leading to
a DoS, depending on the exact memory layout.  Privilege escalation is
a theoretical possibility which cannot be ruled out, but is considered
unlikely.

VULNERABLE SYSTEMS
==================

All Xen systems.

Xen 4.1 is vulnerable.  Other versions of Xen are not vulnerable.

MITIGATION
==========

This issue can be mitigated by ensuring (inside the guest) that the
kernel is trustworthy and avoiding situations where something might
repeatedly cause the attempted allocation of a physical irq.

RESOLUTION
==========

Applying the appropriate attached patch will resolve the issue.

CREDIT
======

Thanks to Matthew Daley for finding this vulnerability (and that in
XSA-12) and notifying the Xen.org security team.

PATCH INFORMATION
=================

The attached patches resolve this issue

  Xen 4.1, 4.1.x                           xsa13-xen-4.1.patch

$ sha256sum xsa13-*.patch
ad6e3e40ff56c7c25a94d8d9763d4b49f07802b90b4362ddbe4c86bf285c1239  xsa13-xen-4.1.patch
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iQEcBAEBAgAGBQJQRyVqAAoJEIP+FMlX6CvZjrcH/A0xq4dTMtJpUc1WHyUi2aXd
5ap+AA8w0XHLdosXnbxnsTCSsAdkUeBlPkqZAoGxrCGYrzP83T0cPrz8qjzN64KE
Jaei9prTk7VFHa9aAz3OqFYjYd/d21CxI4goGJ4Z0tygys4lmkDeex2kEAj5dq7b
0FLj6aIAVFYI3mWMztx4poOrz/BSCMk1YtrV5hZaY8i7Y6nhaOsPISveS0Dv4FPm
YDGc93ykhOwEWCNqWFQGVndRihgUWQIUcb7f2SUfOC/FvbcJHGlP4Aojl4LUePqM
bi/CR9cPESr7x1+1vcGUZybXALsRMBCJPrx1td3OCgqx8bwAbsQIszuFaWTtajY=
=s7wG
-----END PGP SIGNATURE-----

--=separator
Content-Type: application/octet-stream; name="xsa13-xen-4.1.patch"
Content-Disposition: attachment; filename="xsa13-xen-4.1.patch"
Content-Transfer-Encoding: base64

eGVuOiBoYW5kbGUgb3V0LW9mLXBpcnEgY29uZGl0aW9uIGNvcnJlY3RseSBp
biBQSFlTREVWT1BfZ2V0X2ZyZWVfcGlycQoKVGhpcyBpcyBYU0EtMTMgLyBD
VkUtMjAxMi0zNDk1CgpTaWduZWQtb2ZmLWJ5OiBJYW4gQ2FtcGJlbGwgPGlh
bi5jYW1wYmVsbEBjaXRyaXguY29tPgpTaWduZWQtb2ZmLWJ5OiBKYW4gQmV1
bGljaCA8SkJldWxpY2hAc3VzZS5jb20+CgpkaWZmIC1yIDEyMjVhZmYwNWRk
MiB4ZW4vYXJjaC94ODYvcGh5c2Rldi5jCi0tLSBhL3hlbi9hcmNoL3g4Ni9w
aHlzZGV2LmMJVGh1IEF1ZyAwOSAxNjo0ODowNyAyMDEyICswMTAwCisrKyBi
L3hlbi9hcmNoL3g4Ni9waHlzZGV2LmMJVGh1IEF1ZyAxNiAxMTowNzozNiAy
MDEyICswMTAwCkBAIC01ODcsMTEgKzU4NywxNiBAQCByZXRfdCBkb19waHlz
ZGV2X29wKGludCBjbWQsIFhFTl9HVUVTVF9ICiAgICAgICAgICAgICBicmVh
azsKIAogICAgICAgICBzcGluX2xvY2soJmQtPmV2ZW50X2xvY2spOwotICAg
ICAgICBvdXQucGlycSA9IGdldF9mcmVlX3BpcnEoZCwgb3V0LnR5cGUsIDAp
OwotICAgICAgICBkLT5hcmNoLnBpcnFfaXJxW291dC5waXJxXSA9IFBJUlFf
QUxMT0NBVEVEOworICAgICAgICByZXQgPSBnZXRfZnJlZV9waXJxKGQsIG91
dC50eXBlLCAwKTsKKyAgICAgICAgaWYgKCByZXQgPj0gMCApCisgICAgICAg
ICAgICBkLT5hcmNoLnBpcnFfaXJxW3JldF0gPSBQSVJRX0FMTE9DQVRFRDsK
ICAgICAgICAgc3Bpbl91bmxvY2soJmQtPmV2ZW50X2xvY2spOwogCi0gICAg
ICAgIHJldCA9IGNvcHlfdG9fZ3Vlc3QoYXJnLCAmb3V0LCAxKSA/IC1FRkFV
TFQgOiAwOworICAgICAgICBpZiAoIHJldCA+PSAwICkKKyAgICAgICAgewor
ICAgICAgICAgICAgb3V0LnBpcnEgPSByZXQ7CisgICAgICAgICAgICByZXQg
PSBjb3B5X3RvX2d1ZXN0KGFyZywgJm91dCwgMSkgPyAtRUZBVUxUIDogMDsK
KyAgICAgICAgfQogCiAgICAgICAgIHJjdV91bmxvY2tfZG9tYWluKGQpOwog
ICAgICAgICBicmVhazsK

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

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

--=separator--


From xen-devel-bounces@lists.xen.org Wed Sep 05 10:14:27 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Sep 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 1T9Ccd-0000dA-QE; Wed, 05 Sep 2012 10:14: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 1T9Ccb-0000c6-IO; Wed, 05 Sep 2012 10:14:09 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1346840028!8841583!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTE5ODY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32669 invoked from network); 5 Sep 2012 10:13:50 -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;
	5 Sep 2012 10:13:50 -0000
X-IronPort-AV: E=Sophos;i="4.80,372,1344211200"; d="scan'208";a="14354132"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Sep 2012 10:13: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.279.1; Wed, 5 Sep 2012 11:13: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
	1T9Cbz-0001sP-5Y; Wed, 05 Sep 2012 10:13:31 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1T9Cbz-0003ZK-24;
	Wed, 05 Sep 2012 11:13:31 +0100
Date: Wed, 5 Sep 2012 11:13:31 +0100
Message-ID: <E1T9Cbz-0003ZK-24@mariner.uk.xensource.com>
Content-Type: multipart/mixed; boundary="=separator"; charset="utf-8"
MIME-Version: 1.0
X-Mailer: MIME-tools 5.428 (Entity 5.428)
To: xen-announce@lists.xen.org, xen-devel@lists.xen.org,
	xen-users@lists.xen.org, oss-security@lists.openwall.com
From: Xen.org security team <security@xen.org>
Cc: "Xen.org security team" <security@xen.org>
Subject: [Xen-devel] Xen Security Advisory 13 (CVE-2012-3495) - hypercall
 physdev_get_free_pirq vulnerability
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--=separator
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

            Xen Security Advisory CVE-2012-3495 / XSA-13
                             version 3

           hypercall physdev_get_free_pirq vulnerability

UPDATES IN VERSION 3
====================

Public release.  Credit Matthew Daley.

ISSUE DESCRIPTION
=================

PHYSDEVOP_get_free_pirq does not check that its call to get_free_pirq
succeeded, and if it fails will use the error code as an array index.

IMPACT
======

A malicious guest might be able to cause the host to crash, leading to
a DoS, depending on the exact memory layout.  Privilege escalation is
a theoretical possibility which cannot be ruled out, but is considered
unlikely.

VULNERABLE SYSTEMS
==================

All Xen systems.

Xen 4.1 is vulnerable.  Other versions of Xen are not vulnerable.

MITIGATION
==========

This issue can be mitigated by ensuring (inside the guest) that the
kernel is trustworthy and avoiding situations where something might
repeatedly cause the attempted allocation of a physical irq.

RESOLUTION
==========

Applying the appropriate attached patch will resolve the issue.

CREDIT
======

Thanks to Matthew Daley for finding this vulnerability (and that in
XSA-12) and notifying the Xen.org security team.

PATCH INFORMATION
=================

The attached patches resolve this issue

  Xen 4.1, 4.1.x                           xsa13-xen-4.1.patch

$ sha256sum xsa13-*.patch
ad6e3e40ff56c7c25a94d8d9763d4b49f07802b90b4362ddbe4c86bf285c1239  xsa13-xen-4.1.patch
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iQEcBAEBAgAGBQJQRyVqAAoJEIP+FMlX6CvZjrcH/A0xq4dTMtJpUc1WHyUi2aXd
5ap+AA8w0XHLdosXnbxnsTCSsAdkUeBlPkqZAoGxrCGYrzP83T0cPrz8qjzN64KE
Jaei9prTk7VFHa9aAz3OqFYjYd/d21CxI4goGJ4Z0tygys4lmkDeex2kEAj5dq7b
0FLj6aIAVFYI3mWMztx4poOrz/BSCMk1YtrV5hZaY8i7Y6nhaOsPISveS0Dv4FPm
YDGc93ykhOwEWCNqWFQGVndRihgUWQIUcb7f2SUfOC/FvbcJHGlP4Aojl4LUePqM
bi/CR9cPESr7x1+1vcGUZybXALsRMBCJPrx1td3OCgqx8bwAbsQIszuFaWTtajY=
=s7wG
-----END PGP SIGNATURE-----

--=separator
Content-Type: application/octet-stream; name="xsa13-xen-4.1.patch"
Content-Disposition: attachment; filename="xsa13-xen-4.1.patch"
Content-Transfer-Encoding: base64

eGVuOiBoYW5kbGUgb3V0LW9mLXBpcnEgY29uZGl0aW9uIGNvcnJlY3RseSBp
biBQSFlTREVWT1BfZ2V0X2ZyZWVfcGlycQoKVGhpcyBpcyBYU0EtMTMgLyBD
VkUtMjAxMi0zNDk1CgpTaWduZWQtb2ZmLWJ5OiBJYW4gQ2FtcGJlbGwgPGlh
bi5jYW1wYmVsbEBjaXRyaXguY29tPgpTaWduZWQtb2ZmLWJ5OiBKYW4gQmV1
bGljaCA8SkJldWxpY2hAc3VzZS5jb20+CgpkaWZmIC1yIDEyMjVhZmYwNWRk
MiB4ZW4vYXJjaC94ODYvcGh5c2Rldi5jCi0tLSBhL3hlbi9hcmNoL3g4Ni9w
aHlzZGV2LmMJVGh1IEF1ZyAwOSAxNjo0ODowNyAyMDEyICswMTAwCisrKyBi
L3hlbi9hcmNoL3g4Ni9waHlzZGV2LmMJVGh1IEF1ZyAxNiAxMTowNzozNiAy
MDEyICswMTAwCkBAIC01ODcsMTEgKzU4NywxNiBAQCByZXRfdCBkb19waHlz
ZGV2X29wKGludCBjbWQsIFhFTl9HVUVTVF9ICiAgICAgICAgICAgICBicmVh
azsKIAogICAgICAgICBzcGluX2xvY2soJmQtPmV2ZW50X2xvY2spOwotICAg
ICAgICBvdXQucGlycSA9IGdldF9mcmVlX3BpcnEoZCwgb3V0LnR5cGUsIDAp
OwotICAgICAgICBkLT5hcmNoLnBpcnFfaXJxW291dC5waXJxXSA9IFBJUlFf
QUxMT0NBVEVEOworICAgICAgICByZXQgPSBnZXRfZnJlZV9waXJxKGQsIG91
dC50eXBlLCAwKTsKKyAgICAgICAgaWYgKCByZXQgPj0gMCApCisgICAgICAg
ICAgICBkLT5hcmNoLnBpcnFfaXJxW3JldF0gPSBQSVJRX0FMTE9DQVRFRDsK
ICAgICAgICAgc3Bpbl91bmxvY2soJmQtPmV2ZW50X2xvY2spOwogCi0gICAg
ICAgIHJldCA9IGNvcHlfdG9fZ3Vlc3QoYXJnLCAmb3V0LCAxKSA/IC1FRkFV
TFQgOiAwOworICAgICAgICBpZiAoIHJldCA+PSAwICkKKyAgICAgICAgewor
ICAgICAgICAgICAgb3V0LnBpcnEgPSByZXQ7CisgICAgICAgICAgICByZXQg
PSBjb3B5X3RvX2d1ZXN0KGFyZywgJm91dCwgMSkgPyAtRUZBVUxUIDogMDsK
KyAgICAgICAgfQogCiAgICAgICAgIHJjdV91bmxvY2tfZG9tYWluKGQpOwog
ICAgICAgICBicmVhazsK

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

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

--=separator--


From xen-devel-bounces@lists.xen.org Wed Sep 05 10:26:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Sep 2012 10:26:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9Cny-0001qI-Qh; Wed, 05 Sep 2012 10:25:54 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <linux@eikelenboom.it>) id 1T9Cnx-0001q5-B7
	for xen-devel@lists.xen.org; Wed, 05 Sep 2012 10:25:53 +0000
Received: from [85.158.138.51:7027] by server-5.bemta-3.messagelabs.com id
	86/23-13133-0B827405; Wed, 05 Sep 2012 10:25:52 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-3.tower-174.messagelabs.com!1346840748!20668791!1
X-Originating-IP: [188.40.164.121]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2762 invoked from network); 5 Sep 2012 10:25:48 -0000
Received: from static.121.164.40.188.clients.your-server.de (HELO
	smtp.eikelenboom.it) (188.40.164.121)
	by server-3.tower-174.messagelabs.com with AES256-SHA encrypted SMTP;
	5 Sep 2012 10:25:48 -0000
Received: from 128-64-ftth.onsneteindhoven.nl ([88.159.64.128]:51861
	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 1T9Cko-0007m8-4A; Wed, 05 Sep 2012 12:22:38 +0200
Date: Wed, 5 Sep 2012 12:25:42 +0200
From: Sander Eikelenboom <linux@eikelenboom.it>
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <348297741.20120905122542@eikelenboom.it>
To: "Jan Beulich" <JBeulich@suse.com>
In-Reply-To: <5047420A0200007800098BB1@nat28.tlf.novell.com>
References: <40501859.20120902104331@eikelenboom.it>
	<CC6932C2.3D99D%keir.xen@gmail.com>
	<217459398.20120902171441@eikelenboom.it>
	<5044CAD7.8030800@amd.com>
	<1144695277.20120904184345@eikelenboom.it>
	<5047420A0200007800098BB1@nat28.tlf.novell.com>
MIME-Version: 1.0
Cc: Wei Wang <wei.wang2@amd.com>, Keir Fraser <keir.xen@gmail.com>,
	Santosh Jodh <Santosh.Jodh@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Using debug-key 'o:  Dump IOMMU p2m table,
	locks up machine
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-15"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


Wednesday, September 5, 2012, 12:14:02 PM, you wrote:

>>>> On 04.09.12 at 18:43, Sander Eikelenboom <linux@eikelenboom.it> wrote:
>>> Did you also update xen tools accordingly? Sometime I also saw a few =

>>> IO_PAGE_FAULTs came from nic if my tools version and HV version did not =

>>> match. But using recent 4.2 and corresponding xl, my tests went well.
>>> BTW: You could also try iommu=3Dno-sharept to see if it helps.
>> =

>> Tried it and it doesn't help.
>> I now even got a "xl dmesg" which shows a IO_PAGE_FAULT occuring very ea=
rly, =

>> before any toolstack or guest can be involved:
>> =

>> (XEN) [2012-09-04 15:51:17] AMD-Vi: Setup I/O page table: device id =3D =
0x0a05, =

>> root table =3D 0x24d84b000, domain =3D 0, paging mode =3D 3
>> (XEN) [2012-09-04 15:51:17] AMD-Vi: Setup I/O page table: device id =3D =
0x0a06, =

>> root table =3D 0x24d84b000, domain =3D 0, paging mode =3D 3
>> (XEN) [2012-09-04 15:51:17] AMD-Vi: Setup I/O page table: device id =3D =
0x0a07, =

>> root table =3D 0x24d84b000, domain =3D 0, paging mode =3D 3
>> (XEN) [2012-09-04 15:51:17] AMD-Vi: Setup I/O page table: device id =3D =
0x0b00, =

>> root table =3D 0x24d84b000, domain =3D 0, paging mode =3D 3
>> (XEN) [2012-09-04 15:51:17] Scrubbing Free RAM: =

>> ...........................<0>AMD-Vi: IO_PAGE_FAULT: domain =3D 0, devic=
e id =3D =

>> 0x0a06, fault address =3D 0xc2c2c2c0

> Looks like use of uninitialized memory (assuming you're using a
> debug hypervisor, that's the pattern scrub_one_page() puts
> there). But it's unclear to me what device should be doing any
> I/O at that point (and even if one does, how it would get the
> bad address loaded). What is 0a:00.6?

since 4.2-rc4 is still unstable it has debug=3Dy for what i know, so yes.
This particular IO_PAGE_FAULT happened before the kernel loads, so the kern=
el and pciback shouldn't be causing the issue one would say.
With pciback i'm hiding 03:06.0, 04:00.*, 05:00.0, 0a:00.* and 07:00.0 at b=
oot.

Is there any code i could add to get more info where it comes from ?


00:00.0 Host bridge: ATI Technologies Inc RD890 Northbridge only single slo=
t PCI-e GFX Hydra part (rev 02)
00:00.2 Generic system peripheral [0806]: ATI Technologies Inc RD990 I/O Me=
mory Management Unit (IOMMU)
00:02.0 PCI bridge: ATI Technologies Inc RD890 PCI to PCI bridge (PCI expre=
ss gpp port B)
00:03.0 PCI bridge: ATI Technologies Inc RD890 PCI to PCI bridge (PCI expre=
ss gpp port C)
00:05.0 PCI bridge: ATI Technologies Inc RD890 PCI to PCI bridge (PCI expre=
ss gpp port E)
00:06.0 PCI bridge: ATI Technologies Inc RD890 PCI to PCI bridge (PCI expre=
ss gpp port F)
00:0a.0 PCI bridge: ATI Technologies Inc RD890 PCI to PCI bridge (external =
gfx1 port A)
00:0b.0 PCI bridge: ATI Technologies Inc RD890 PCI to PCI bridge (NB-SB lin=
k)
00:0c.0 PCI bridge: ATI Technologies Inc Device 5a20
00:0d.0 PCI bridge: ATI Technologies Inc RD890 PCI to PCI bridge (external =
gfx1 port B)
00:11.0 SATA controller: ATI Technologies Inc SB7x0/SB8x0/SB9x0 SATA Contro=
ller [AHCI mode] (rev 40)
00:12.0 USB controller: ATI Technologies Inc SB7x0/SB8x0/SB9x0 USB OHCI0 Co=
ntroller
00:12.2 USB controller: ATI Technologies Inc SB7x0/SB8x0/SB9x0 USB EHCI Con=
troller
00:13.0 USB controller: ATI Technologies Inc SB7x0/SB8x0/SB9x0 USB OHCI0 Co=
ntroller
00:13.2 USB controller: ATI Technologies Inc SB7x0/SB8x0/SB9x0 USB EHCI Con=
troller
00:14.0 SMBus: ATI Technologies Inc SBx00 SMBus Controller (rev 41)
00:14.3 ISA bridge: ATI Technologies Inc SB7x0/SB8x0/SB9x0 LPC host control=
ler (rev 40)
00:14.4 PCI bridge: ATI Technologies Inc SBx00 PCI to PCI Bridge (rev 40)
00:14.5 USB controller: ATI Technologies Inc SB7x0/SB8x0/SB9x0 USB OHCI2 Co=
ntroller
00:15.0 PCI bridge: ATI Technologies Inc SB700/SB800/SB900 PCI to PCI bridg=
e (PCIE port 0)
00:16.0 USB controller: ATI Technologies Inc SB7x0/SB8x0/SB9x0 USB OHCI0 Co=
ntroller
00:16.2 USB controller: ATI Technologies Inc SB7x0/SB8x0/SB9x0 USB EHCI Con=
troller
00:18.0 Host bridge: Advanced Micro Devices [AMD] Family 10h Processor Hype=
rTransport Configuration
00:18.1 Host bridge: Advanced Micro Devices [AMD] Family 10h Processor Addr=
ess Map
00:18.2 Host bridge: Advanced Micro Devices [AMD] Family 10h Processor DRAM=
 Controller
00:18.3 Host bridge: Advanced Micro Devices [AMD] Family 10h Processor Misc=
ellaneous Control
00:18.4 Host bridge: Advanced Micro Devices [AMD] Family 10h Processor Link=
 Control
03:06.0 Multimedia audio controller: C-Media Electronics Inc CM8738 (rev 10)
04:00.0 USB controller: NetMos Technology MCS9990 PCIe to 4=E2Port USB 2.0 =
Host Controller
04:00.1 USB controller: NetMos Technology MCS9990 PCIe to 4=E2Port USB 2.0 =
Host Controller
04:00.2 USB controller: NetMos Technology MCS9990 PCIe to 4=E2Port USB 2.0 =
Host Controller
04:00.3 USB controller: NetMos Technology MCS9990 PCIe to 4=E2Port USB 2.0 =
Host Controller
04:00.4 USB controller: NetMos Technology MCS9990 PCIe to 4=E2Port USB 2.0 =
Host Controller
04:00.5 USB controller: NetMos Technology MCS9990 PCIe to 4=E2Port USB 2.0 =
Host Controller
04:00.6 USB controller: NetMos Technology MCS9990 PCIe to 4=E2Port USB 2.0 =
Host Controller
04:00.7 USB controller: NetMos Technology MCS9990 PCIe to 4=E2Port USB 2.0 =
Host Controller
05:00.0 Multimedia video controller: Conexant Systems, Inc. CX25850
06:00.0 VGA compatible controller: ATI Technologies Inc RV620 LE [Radeon HD=
 3450]
06:00.1 Audio device: ATI Technologies Inc RV620 Audio device [Radeon HD 34=
xx Series]
07:00.0 Multimedia video controller: Conexant Systems, Inc. Device 8210
08:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168B =
PCI Express Gigabit Ethernet controller (rev 03)
09:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168B =
PCI Express Gigabit Ethernet controller (rev 03)
0a:00.0 USB controller: NetMos Technology MCS9990 PCIe to 4=E2Port USB 2.0 =
Host Controller
0a:00.1 USB controller: NetMos Technology MCS9990 PCIe to 4=E2Port USB 2.0 =
Host Controller
0a:00.2 USB controller: NetMos Technology MCS9990 PCIe to 4=E2Port USB 2.0 =
Host Controller
0a:00.3 USB controller: NetMos Technology MCS9990 PCIe to 4=E2Port USB 2.0 =
Host Controller
0a:00.4 USB controller: NetMos Technology MCS9990 PCIe to 4=E2Port USB 2.0 =
Host Controller
0a:00.5 USB controller: NetMos Technology MCS9990 PCIe to 4=E2Port USB 2.0 =
Host Controller
0a:00.6 USB controller: NetMos Technology MCS9990 PCIe to 4=E2Port USB 2.0 =
Host Controller
0a:00.7 USB controller: NetMos Technology MCS9990 PCIe to 4=E2Port USB 2.0 =
Host Controller
0b:00.0 VGA compatible controller: nVidia Corporation G98 [GeForce 8400 GS]=
 (rev a1)







> Jan




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

From xen-devel-bounces@lists.xen.org Wed Sep 05 10:26:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Sep 2012 10:26:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9Cny-0001qI-Qh; Wed, 05 Sep 2012 10:25:54 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <linux@eikelenboom.it>) id 1T9Cnx-0001q5-B7
	for xen-devel@lists.xen.org; Wed, 05 Sep 2012 10:25:53 +0000
Received: from [85.158.138.51:7027] by server-5.bemta-3.messagelabs.com id
	86/23-13133-0B827405; Wed, 05 Sep 2012 10:25:52 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-3.tower-174.messagelabs.com!1346840748!20668791!1
X-Originating-IP: [188.40.164.121]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2762 invoked from network); 5 Sep 2012 10:25:48 -0000
Received: from static.121.164.40.188.clients.your-server.de (HELO
	smtp.eikelenboom.it) (188.40.164.121)
	by server-3.tower-174.messagelabs.com with AES256-SHA encrypted SMTP;
	5 Sep 2012 10:25:48 -0000
Received: from 128-64-ftth.onsneteindhoven.nl ([88.159.64.128]:51861
	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 1T9Cko-0007m8-4A; Wed, 05 Sep 2012 12:22:38 +0200
Date: Wed, 5 Sep 2012 12:25:42 +0200
From: Sander Eikelenboom <linux@eikelenboom.it>
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <348297741.20120905122542@eikelenboom.it>
To: "Jan Beulich" <JBeulich@suse.com>
In-Reply-To: <5047420A0200007800098BB1@nat28.tlf.novell.com>
References: <40501859.20120902104331@eikelenboom.it>
	<CC6932C2.3D99D%keir.xen@gmail.com>
	<217459398.20120902171441@eikelenboom.it>
	<5044CAD7.8030800@amd.com>
	<1144695277.20120904184345@eikelenboom.it>
	<5047420A0200007800098BB1@nat28.tlf.novell.com>
MIME-Version: 1.0
Cc: Wei Wang <wei.wang2@amd.com>, Keir Fraser <keir.xen@gmail.com>,
	Santosh Jodh <Santosh.Jodh@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Using debug-key 'o:  Dump IOMMU p2m table,
	locks up machine
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-15"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


Wednesday, September 5, 2012, 12:14:02 PM, you wrote:

>>>> On 04.09.12 at 18:43, Sander Eikelenboom <linux@eikelenboom.it> wrote:
>>> Did you also update xen tools accordingly? Sometime I also saw a few =

>>> IO_PAGE_FAULTs came from nic if my tools version and HV version did not =

>>> match. But using recent 4.2 and corresponding xl, my tests went well.
>>> BTW: You could also try iommu=3Dno-sharept to see if it helps.
>> =

>> Tried it and it doesn't help.
>> I now even got a "xl dmesg" which shows a IO_PAGE_FAULT occuring very ea=
rly, =

>> before any toolstack or guest can be involved:
>> =

>> (XEN) [2012-09-04 15:51:17] AMD-Vi: Setup I/O page table: device id =3D =
0x0a05, =

>> root table =3D 0x24d84b000, domain =3D 0, paging mode =3D 3
>> (XEN) [2012-09-04 15:51:17] AMD-Vi: Setup I/O page table: device id =3D =
0x0a06, =

>> root table =3D 0x24d84b000, domain =3D 0, paging mode =3D 3
>> (XEN) [2012-09-04 15:51:17] AMD-Vi: Setup I/O page table: device id =3D =
0x0a07, =

>> root table =3D 0x24d84b000, domain =3D 0, paging mode =3D 3
>> (XEN) [2012-09-04 15:51:17] AMD-Vi: Setup I/O page table: device id =3D =
0x0b00, =

>> root table =3D 0x24d84b000, domain =3D 0, paging mode =3D 3
>> (XEN) [2012-09-04 15:51:17] Scrubbing Free RAM: =

>> ...........................<0>AMD-Vi: IO_PAGE_FAULT: domain =3D 0, devic=
e id =3D =

>> 0x0a06, fault address =3D 0xc2c2c2c0

> Looks like use of uninitialized memory (assuming you're using a
> debug hypervisor, that's the pattern scrub_one_page() puts
> there). But it's unclear to me what device should be doing any
> I/O at that point (and even if one does, how it would get the
> bad address loaded). What is 0a:00.6?

since 4.2-rc4 is still unstable it has debug=3Dy for what i know, so yes.
This particular IO_PAGE_FAULT happened before the kernel loads, so the kern=
el and pciback shouldn't be causing the issue one would say.
With pciback i'm hiding 03:06.0, 04:00.*, 05:00.0, 0a:00.* and 07:00.0 at b=
oot.

Is there any code i could add to get more info where it comes from ?


00:00.0 Host bridge: ATI Technologies Inc RD890 Northbridge only single slo=
t PCI-e GFX Hydra part (rev 02)
00:00.2 Generic system peripheral [0806]: ATI Technologies Inc RD990 I/O Me=
mory Management Unit (IOMMU)
00:02.0 PCI bridge: ATI Technologies Inc RD890 PCI to PCI bridge (PCI expre=
ss gpp port B)
00:03.0 PCI bridge: ATI Technologies Inc RD890 PCI to PCI bridge (PCI expre=
ss gpp port C)
00:05.0 PCI bridge: ATI Technologies Inc RD890 PCI to PCI bridge (PCI expre=
ss gpp port E)
00:06.0 PCI bridge: ATI Technologies Inc RD890 PCI to PCI bridge (PCI expre=
ss gpp port F)
00:0a.0 PCI bridge: ATI Technologies Inc RD890 PCI to PCI bridge (external =
gfx1 port A)
00:0b.0 PCI bridge: ATI Technologies Inc RD890 PCI to PCI bridge (NB-SB lin=
k)
00:0c.0 PCI bridge: ATI Technologies Inc Device 5a20
00:0d.0 PCI bridge: ATI Technologies Inc RD890 PCI to PCI bridge (external =
gfx1 port B)
00:11.0 SATA controller: ATI Technologies Inc SB7x0/SB8x0/SB9x0 SATA Contro=
ller [AHCI mode] (rev 40)
00:12.0 USB controller: ATI Technologies Inc SB7x0/SB8x0/SB9x0 USB OHCI0 Co=
ntroller
00:12.2 USB controller: ATI Technologies Inc SB7x0/SB8x0/SB9x0 USB EHCI Con=
troller
00:13.0 USB controller: ATI Technologies Inc SB7x0/SB8x0/SB9x0 USB OHCI0 Co=
ntroller
00:13.2 USB controller: ATI Technologies Inc SB7x0/SB8x0/SB9x0 USB EHCI Con=
troller
00:14.0 SMBus: ATI Technologies Inc SBx00 SMBus Controller (rev 41)
00:14.3 ISA bridge: ATI Technologies Inc SB7x0/SB8x0/SB9x0 LPC host control=
ler (rev 40)
00:14.4 PCI bridge: ATI Technologies Inc SBx00 PCI to PCI Bridge (rev 40)
00:14.5 USB controller: ATI Technologies Inc SB7x0/SB8x0/SB9x0 USB OHCI2 Co=
ntroller
00:15.0 PCI bridge: ATI Technologies Inc SB700/SB800/SB900 PCI to PCI bridg=
e (PCIE port 0)
00:16.0 USB controller: ATI Technologies Inc SB7x0/SB8x0/SB9x0 USB OHCI0 Co=
ntroller
00:16.2 USB controller: ATI Technologies Inc SB7x0/SB8x0/SB9x0 USB EHCI Con=
troller
00:18.0 Host bridge: Advanced Micro Devices [AMD] Family 10h Processor Hype=
rTransport Configuration
00:18.1 Host bridge: Advanced Micro Devices [AMD] Family 10h Processor Addr=
ess Map
00:18.2 Host bridge: Advanced Micro Devices [AMD] Family 10h Processor DRAM=
 Controller
00:18.3 Host bridge: Advanced Micro Devices [AMD] Family 10h Processor Misc=
ellaneous Control
00:18.4 Host bridge: Advanced Micro Devices [AMD] Family 10h Processor Link=
 Control
03:06.0 Multimedia audio controller: C-Media Electronics Inc CM8738 (rev 10)
04:00.0 USB controller: NetMos Technology MCS9990 PCIe to 4=E2Port USB 2.0 =
Host Controller
04:00.1 USB controller: NetMos Technology MCS9990 PCIe to 4=E2Port USB 2.0 =
Host Controller
04:00.2 USB controller: NetMos Technology MCS9990 PCIe to 4=E2Port USB 2.0 =
Host Controller
04:00.3 USB controller: NetMos Technology MCS9990 PCIe to 4=E2Port USB 2.0 =
Host Controller
04:00.4 USB controller: NetMos Technology MCS9990 PCIe to 4=E2Port USB 2.0 =
Host Controller
04:00.5 USB controller: NetMos Technology MCS9990 PCIe to 4=E2Port USB 2.0 =
Host Controller
04:00.6 USB controller: NetMos Technology MCS9990 PCIe to 4=E2Port USB 2.0 =
Host Controller
04:00.7 USB controller: NetMos Technology MCS9990 PCIe to 4=E2Port USB 2.0 =
Host Controller
05:00.0 Multimedia video controller: Conexant Systems, Inc. CX25850
06:00.0 VGA compatible controller: ATI Technologies Inc RV620 LE [Radeon HD=
 3450]
06:00.1 Audio device: ATI Technologies Inc RV620 Audio device [Radeon HD 34=
xx Series]
07:00.0 Multimedia video controller: Conexant Systems, Inc. Device 8210
08:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168B =
PCI Express Gigabit Ethernet controller (rev 03)
09:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168B =
PCI Express Gigabit Ethernet controller (rev 03)
0a:00.0 USB controller: NetMos Technology MCS9990 PCIe to 4=E2Port USB 2.0 =
Host Controller
0a:00.1 USB controller: NetMos Technology MCS9990 PCIe to 4=E2Port USB 2.0 =
Host Controller
0a:00.2 USB controller: NetMos Technology MCS9990 PCIe to 4=E2Port USB 2.0 =
Host Controller
0a:00.3 USB controller: NetMos Technology MCS9990 PCIe to 4=E2Port USB 2.0 =
Host Controller
0a:00.4 USB controller: NetMos Technology MCS9990 PCIe to 4=E2Port USB 2.0 =
Host Controller
0a:00.5 USB controller: NetMos Technology MCS9990 PCIe to 4=E2Port USB 2.0 =
Host Controller
0a:00.6 USB controller: NetMos Technology MCS9990 PCIe to 4=E2Port USB 2.0 =
Host Controller
0a:00.7 USB controller: NetMos Technology MCS9990 PCIe to 4=E2Port USB 2.0 =
Host Controller
0b:00.0 VGA compatible controller: nVidia Corporation G98 [GeForce 8400 GS]=
 (rev a1)







> Jan




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

From xen-devel-bounces@lists.xen.org Wed Sep 05 10:41:01 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Sep 2012 10:41:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9D2M-0002EP-NN; Wed, 05 Sep 2012 10:40:46 +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 1T9D2K-0002EI-T7
	for xen-devel@lists.xen.org; Wed, 05 Sep 2012 10:40:45 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1346841578!8974456!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQwMzE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11911 invoked from network); 5 Sep 2012 10:39:38 -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;
	5 Sep 2012 10:39:38 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 05 Sep 2012 11:39:38 +0100
Message-Id: <5047483F0200007800098C18@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 05 Sep 2012 11:40:31 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Sander Eikelenboom" <linux@eikelenboom.it>
References: <40501859.20120902104331@eikelenboom.it>
	<CC6932C2.3D99D%keir.xen@gmail.com>
	<217459398.20120902171441@eikelenboom.it> <5044CAD7.8030800@amd.com>
	<1144695277.20120904184345@eikelenboom.it>
	<5047420A0200007800098BB1@nat28.tlf.novell.com>
	<348297741.20120905122542@eikelenboom.it>
In-Reply-To: <348297741.20120905122542@eikelenboom.it>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Wei Wang <wei.wang2@amd.com>, Keir Fraser <keir.xen@gmail.com>,
	Santosh Jodh <Santosh.Jodh@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Using debug-key 'o:  Dump IOMMU p2m table,
 locks up machine
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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+IE9uIDA1LjA5LjEyIGF0IDEyOjI1LCBTYW5kZXIgRWlrZWxlbmJvb20gPGxpbnV4QGVpa2Vs
ZW5ib29tLml0PiB3cm90ZToKPiBXZWRuZXNkYXksIFNlcHRlbWJlciA1LCAyMDEyLCAxMjoxNDow
MiBQTSwgeW91IHdyb3RlOgo+Pj4+PiBPbiAwNC4wOS4xMiBhdCAxODo0MywgU2FuZGVyIEVpa2Vs
ZW5ib29tIDxsaW51eEBlaWtlbGVuYm9vbS5pdD4gd3JvdGU6Cj4+PiAuLi4uLi4uLi4uLi4uLi4u
Li4uLi4uLi4uLi48MD5BTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBp
ZCA9IAo+Pj4gMHgwYTA2LCBmYXVsdCBhZGRyZXNzID0gMHhjMmMyYzJjMAo+IAo+PiBMb29rcyBs
aWtlIHVzZSBvZiB1bmluaXRpYWxpemVkIG1lbW9yeSAoYXNzdW1pbmcgeW91J3JlIHVzaW5nIGEK
Pj4gZGVidWcgaHlwZXJ2aXNvciwgdGhhdCdzIHRoZSBwYXR0ZXJuIHNjcnViX29uZV9wYWdlKCkg
cHV0cwo+PiB0aGVyZSkuIEJ1dCBpdCdzIHVuY2xlYXIgdG8gbWUgd2hhdCBkZXZpY2Ugc2hvdWxk
IGJlIGRvaW5nIGFueQo+PiBJL08gYXQgdGhhdCBwb2ludCAoYW5kIGV2ZW4gaWYgb25lIGRvZXMs
IGhvdyBpdCB3b3VsZCBnZXQgdGhlCj4+IGJhZCBhZGRyZXNzIGxvYWRlZCkuIFdoYXQgaXMgMGE6
MDAuNj8KPiAKPiBzaW5jZSA0LjItcmM0IGlzIHN0aWxsIHVuc3RhYmxlIGl0IGhhcyBkZWJ1Zz15
IGZvciB3aGF0IGkga25vdywgc28geWVzLgo+IFRoaXMgcGFydGljdWxhciBJT19QQUdFX0ZBVUxU
IGhhcHBlbmVkIGJlZm9yZSB0aGUga2VybmVsIGxvYWRzLCBzbyB0aGUgCj4ga2VybmVsIGFuZCBw
Y2liYWNrIHNob3VsZG4ndCBiZSBjYXVzaW5nIHRoZSBpc3N1ZSBvbmUgd291bGQgc2F5Lgo+IFdp
dGggcGNpYmFjayBpJ20gaGlkaW5nIDAzOjA2LjAsIDA0OjAwLiosIDA1OjAwLjAsIDBhOjAwLiog
YW5kIDA3OjAwLjAgYXQgCj4gYm9vdC4KPiAKPiBJcyB0aGVyZSBhbnkgY29kZSBpIGNvdWxkIGFk
ZCB0byBnZXQgbW9yZSBpbmZvIHdoZXJlIGl0IGNvbWVzIGZyb20gPwoKSGFyZGx5LCBzaW5jZSB0
aG9zZSBhY2Nlc3NlcyBhcmUgYXN5bmNocm9ub3VzIHRvIHdoYXQgdGhlIENQVXMKZG8uIEJ1dCAu
Li4KCj4gMGE6MDAuNiBVU0IgY29udHJvbGxlcjogTmV0TW9zIFRlY2hub2xvZ3kgTUNTOTk5MCBQ
Q0llIHRvIDTDolBvcnQgVVNCIDIuMCBIb3N0IENvbnRyb2xsZXIKCi4uLiBhcmUgeW91ciBrZXli
b2FyZC9tb3VzZSBwZXJoYXBzIGNvbm5lY3RlZCB0byB0aGlzIG9uZT8gSW4Kd2hpY2ggY2FzZSBJ
J2Qgc3VwcG9zZSB0aGUgMToxIHRhYmxlcyBzZXQgdXAgZm9yIERvbTAgbWlnaHQgbm90CmJlIGNv
bXBsZXRlLiBXZWk/CgpKYW4KCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbi5vcmcK
aHR0cDovL2xpc3RzLnhlbi5vcmcveGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Wed Sep 05 10:41:01 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Sep 2012 10:41:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9D2M-0002EP-NN; Wed, 05 Sep 2012 10:40:46 +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 1T9D2K-0002EI-T7
	for xen-devel@lists.xen.org; Wed, 05 Sep 2012 10:40:45 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1346841578!8974456!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQwMzE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11911 invoked from network); 5 Sep 2012 10:39:38 -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;
	5 Sep 2012 10:39:38 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 05 Sep 2012 11:39:38 +0100
Message-Id: <5047483F0200007800098C18@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 05 Sep 2012 11:40:31 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Sander Eikelenboom" <linux@eikelenboom.it>
References: <40501859.20120902104331@eikelenboom.it>
	<CC6932C2.3D99D%keir.xen@gmail.com>
	<217459398.20120902171441@eikelenboom.it> <5044CAD7.8030800@amd.com>
	<1144695277.20120904184345@eikelenboom.it>
	<5047420A0200007800098BB1@nat28.tlf.novell.com>
	<348297741.20120905122542@eikelenboom.it>
In-Reply-To: <348297741.20120905122542@eikelenboom.it>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Wei Wang <wei.wang2@amd.com>, Keir Fraser <keir.xen@gmail.com>,
	Santosh Jodh <Santosh.Jodh@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Using debug-key 'o:  Dump IOMMU p2m table,
 locks up machine
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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+IE9uIDA1LjA5LjEyIGF0IDEyOjI1LCBTYW5kZXIgRWlrZWxlbmJvb20gPGxpbnV4QGVpa2Vs
ZW5ib29tLml0PiB3cm90ZToKPiBXZWRuZXNkYXksIFNlcHRlbWJlciA1LCAyMDEyLCAxMjoxNDow
MiBQTSwgeW91IHdyb3RlOgo+Pj4+PiBPbiAwNC4wOS4xMiBhdCAxODo0MywgU2FuZGVyIEVpa2Vs
ZW5ib29tIDxsaW51eEBlaWtlbGVuYm9vbS5pdD4gd3JvdGU6Cj4+PiAuLi4uLi4uLi4uLi4uLi4u
Li4uLi4uLi4uLi48MD5BTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBp
ZCA9IAo+Pj4gMHgwYTA2LCBmYXVsdCBhZGRyZXNzID0gMHhjMmMyYzJjMAo+IAo+PiBMb29rcyBs
aWtlIHVzZSBvZiB1bmluaXRpYWxpemVkIG1lbW9yeSAoYXNzdW1pbmcgeW91J3JlIHVzaW5nIGEK
Pj4gZGVidWcgaHlwZXJ2aXNvciwgdGhhdCdzIHRoZSBwYXR0ZXJuIHNjcnViX29uZV9wYWdlKCkg
cHV0cwo+PiB0aGVyZSkuIEJ1dCBpdCdzIHVuY2xlYXIgdG8gbWUgd2hhdCBkZXZpY2Ugc2hvdWxk
IGJlIGRvaW5nIGFueQo+PiBJL08gYXQgdGhhdCBwb2ludCAoYW5kIGV2ZW4gaWYgb25lIGRvZXMs
IGhvdyBpdCB3b3VsZCBnZXQgdGhlCj4+IGJhZCBhZGRyZXNzIGxvYWRlZCkuIFdoYXQgaXMgMGE6
MDAuNj8KPiAKPiBzaW5jZSA0LjItcmM0IGlzIHN0aWxsIHVuc3RhYmxlIGl0IGhhcyBkZWJ1Zz15
IGZvciB3aGF0IGkga25vdywgc28geWVzLgo+IFRoaXMgcGFydGljdWxhciBJT19QQUdFX0ZBVUxU
IGhhcHBlbmVkIGJlZm9yZSB0aGUga2VybmVsIGxvYWRzLCBzbyB0aGUgCj4ga2VybmVsIGFuZCBw
Y2liYWNrIHNob3VsZG4ndCBiZSBjYXVzaW5nIHRoZSBpc3N1ZSBvbmUgd291bGQgc2F5Lgo+IFdp
dGggcGNpYmFjayBpJ20gaGlkaW5nIDAzOjA2LjAsIDA0OjAwLiosIDA1OjAwLjAsIDBhOjAwLiog
YW5kIDA3OjAwLjAgYXQgCj4gYm9vdC4KPiAKPiBJcyB0aGVyZSBhbnkgY29kZSBpIGNvdWxkIGFk
ZCB0byBnZXQgbW9yZSBpbmZvIHdoZXJlIGl0IGNvbWVzIGZyb20gPwoKSGFyZGx5LCBzaW5jZSB0
aG9zZSBhY2Nlc3NlcyBhcmUgYXN5bmNocm9ub3VzIHRvIHdoYXQgdGhlIENQVXMKZG8uIEJ1dCAu
Li4KCj4gMGE6MDAuNiBVU0IgY29udHJvbGxlcjogTmV0TW9zIFRlY2hub2xvZ3kgTUNTOTk5MCBQ
Q0llIHRvIDTDolBvcnQgVVNCIDIuMCBIb3N0IENvbnRyb2xsZXIKCi4uLiBhcmUgeW91ciBrZXli
b2FyZC9tb3VzZSBwZXJoYXBzIGNvbm5lY3RlZCB0byB0aGlzIG9uZT8gSW4Kd2hpY2ggY2FzZSBJ
J2Qgc3VwcG9zZSB0aGUgMToxIHRhYmxlcyBzZXQgdXAgZm9yIERvbTAgbWlnaHQgbm90CmJlIGNv
bXBsZXRlLiBXZWk/CgpKYW4KCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbi5vcmcK
aHR0cDovL2xpc3RzLnhlbi5vcmcveGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Wed Sep 05 10:44:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Sep 2012 10:44:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9D5R-0002LI-AZ; Wed, 05 Sep 2012 10:43:57 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <linux@eikelenboom.it>) id 1T9D5Q-0002LD-KQ
	for xen-devel@lists.xen.org; Wed, 05 Sep 2012 10:43:56 +0000
Received: from [85.158.143.99:25501] by server-1.bemta-4.messagelabs.com id
	12/ED-12504-BEC27405; Wed, 05 Sep 2012 10:43:55 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-13.tower-216.messagelabs.com!1346841835!27734160!1
X-Originating-IP: [188.40.164.121]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 922 invoked from network); 5 Sep 2012 10:43:55 -0000
Received: from static.121.164.40.188.clients.your-server.de (HELO
	smtp.eikelenboom.it) (188.40.164.121)
	by server-13.tower-216.messagelabs.com with AES256-SHA encrypted SMTP;
	5 Sep 2012 10:43:55 -0000
Received: from 128-64-ftth.onsneteindhoven.nl ([88.159.64.128]:51874
	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 1T9D2L-0007rX-U9; Wed, 05 Sep 2012 12:40:46 +0200
Date: Wed, 5 Sep 2012 12:43:50 +0200
From: Sander Eikelenboom <linux@eikelenboom.it>
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <475752135.20120905124350@eikelenboom.it>
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1346413938.27277.196.camel@zakaz.uk.xensource.com>
References: <885821548.20120831124902@eikelenboom.it>
	<1346410506.27277.179.camel@zakaz.uk.xensource.com>
	<1342800738.20120831133238@eikelenboom.it>
	<1346413938.27277.196.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] xl / xend feature parity: Missing '-a' option for
	xl 'shutdown' to shutdown all 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


Friday, August 31, 2012, 1:52:18 PM, you wrote:

> On Fri, 2012-08-31 at 12:32 +0100, Sander Eikelenboom wrote:
>> Friday, August 31, 2012, 12:55:06 PM, you wrote:
>> 
>> > On Fri, 2012-08-31 at 11:49 +0100, Sander Eikelenboom wrote:
>> >> Hi All,
>> >> 
>> >> Is there any reason why xl doesn't support the '-a' option for
>> >> shutdown,  to shutdown all domains ?
>> 
>> > I'd never heard of it for one thing ;-)
>> 
>> > It should be a reasonably easy patch -- I can give some pointers if you
>> > are interested.
>> 
>> > Ian.
>> 
>> Could give it a try, although my C skills are virtually non existent :-)
>> So every pointer could be handy !
> [...]
>>      - Implement the '-a' option

> In the case where -a is given you want to call libxl_list_domain, then
> loop over the list and finally call libxl_dominfo_list_free.

> main_list() might be a handy reference although its semantics are subtly
> different (it effective assumes -a if you don't give a domain, which you
> don't want for shutdown!)

> vcpulist() might also be a handy reference.

>>      - Update docs that '-a' is supported

> This should be the easiest bit ;-)

Yes it seems to be ...
Just hit another thing i'm wondering about ...

The docs say you have to supply a domain_id as argument.
But if you supply a domain_name instead it works as well.

But what if i'm stupid enough to give my domain a number as name (which seems to be allowed/possible)
In that case i can't shut it down by name:

serveerstertje:~# xl list
Name                                        ID   Mem VCPUs      State   Time(s)
Domain-0                                     0  1024     6     r-----   22318.7
media                                       12   256     1     -b----      73.0
webproxy                                    14   768     5     -b----   41385.2
www                                         15   507     2     -b----     670.8
13                                          17   256     1     -b----       3.2

13                                          17   256     1     -b----       3.2
serveerstertje:~# xl shutdown 13
13 is an invalid domain identifier (rc=-6)



> You also want to update xl_cmdtable.c to include the new option in xl
> help etc.

>>      - Find out what "--halt" / "-H" did .. and perhaps implement that as well

> tools/python/xen/xm/shutdown.py says
>         gopts.opt('halt', short='H',
>                   fn=set_true, default=0,
>                   use='Shutdown without reboot.')

> which I guess means shutdown on xm can behave like xm reboot. Later on
> it does:
>     if opts.vals.halt:
>         return 'halt'
>     elif opts.vals.reboot:
>         return 'reboot'
>     else:
>         return 'poweroff'

> i.e.
>         xm shutdown -H -> "halt"
>         xm shutdown -R -> "reboot"
>         xm shutdown    -> "poweroff"

> Linux in a guest treats "halt" and "poweroff" identically.

> So I think --halt/-H is pointless and you can remove it from the
> defaults.

>>      - Change /etc/default to use the short option format, so it will work for both xm and xl

> In principal it is possible for xl to support long options too (see e.g.
> main_create, but changing the default would be OK for 4.2 IMHO.

> Thanks for looking into this.

> Ian.




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

From xen-devel-bounces@lists.xen.org Wed Sep 05 10:44:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Sep 2012 10:44:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9D5R-0002LI-AZ; Wed, 05 Sep 2012 10:43:57 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <linux@eikelenboom.it>) id 1T9D5Q-0002LD-KQ
	for xen-devel@lists.xen.org; Wed, 05 Sep 2012 10:43:56 +0000
Received: from [85.158.143.99:25501] by server-1.bemta-4.messagelabs.com id
	12/ED-12504-BEC27405; Wed, 05 Sep 2012 10:43:55 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-13.tower-216.messagelabs.com!1346841835!27734160!1
X-Originating-IP: [188.40.164.121]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 922 invoked from network); 5 Sep 2012 10:43:55 -0000
Received: from static.121.164.40.188.clients.your-server.de (HELO
	smtp.eikelenboom.it) (188.40.164.121)
	by server-13.tower-216.messagelabs.com with AES256-SHA encrypted SMTP;
	5 Sep 2012 10:43:55 -0000
Received: from 128-64-ftth.onsneteindhoven.nl ([88.159.64.128]:51874
	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 1T9D2L-0007rX-U9; Wed, 05 Sep 2012 12:40:46 +0200
Date: Wed, 5 Sep 2012 12:43:50 +0200
From: Sander Eikelenboom <linux@eikelenboom.it>
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <475752135.20120905124350@eikelenboom.it>
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1346413938.27277.196.camel@zakaz.uk.xensource.com>
References: <885821548.20120831124902@eikelenboom.it>
	<1346410506.27277.179.camel@zakaz.uk.xensource.com>
	<1342800738.20120831133238@eikelenboom.it>
	<1346413938.27277.196.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] xl / xend feature parity: Missing '-a' option for
	xl 'shutdown' to shutdown all 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


Friday, August 31, 2012, 1:52:18 PM, you wrote:

> On Fri, 2012-08-31 at 12:32 +0100, Sander Eikelenboom wrote:
>> Friday, August 31, 2012, 12:55:06 PM, you wrote:
>> 
>> > On Fri, 2012-08-31 at 11:49 +0100, Sander Eikelenboom wrote:
>> >> Hi All,
>> >> 
>> >> Is there any reason why xl doesn't support the '-a' option for
>> >> shutdown,  to shutdown all domains ?
>> 
>> > I'd never heard of it for one thing ;-)
>> 
>> > It should be a reasonably easy patch -- I can give some pointers if you
>> > are interested.
>> 
>> > Ian.
>> 
>> Could give it a try, although my C skills are virtually non existent :-)
>> So every pointer could be handy !
> [...]
>>      - Implement the '-a' option

> In the case where -a is given you want to call libxl_list_domain, then
> loop over the list and finally call libxl_dominfo_list_free.

> main_list() might be a handy reference although its semantics are subtly
> different (it effective assumes -a if you don't give a domain, which you
> don't want for shutdown!)

> vcpulist() might also be a handy reference.

>>      - Update docs that '-a' is supported

> This should be the easiest bit ;-)

Yes it seems to be ...
Just hit another thing i'm wondering about ...

The docs say you have to supply a domain_id as argument.
But if you supply a domain_name instead it works as well.

But what if i'm stupid enough to give my domain a number as name (which seems to be allowed/possible)
In that case i can't shut it down by name:

serveerstertje:~# xl list
Name                                        ID   Mem VCPUs      State   Time(s)
Domain-0                                     0  1024     6     r-----   22318.7
media                                       12   256     1     -b----      73.0
webproxy                                    14   768     5     -b----   41385.2
www                                         15   507     2     -b----     670.8
13                                          17   256     1     -b----       3.2

13                                          17   256     1     -b----       3.2
serveerstertje:~# xl shutdown 13
13 is an invalid domain identifier (rc=-6)



> You also want to update xl_cmdtable.c to include the new option in xl
> help etc.

>>      - Find out what "--halt" / "-H" did .. and perhaps implement that as well

> tools/python/xen/xm/shutdown.py says
>         gopts.opt('halt', short='H',
>                   fn=set_true, default=0,
>                   use='Shutdown without reboot.')

> which I guess means shutdown on xm can behave like xm reboot. Later on
> it does:
>     if opts.vals.halt:
>         return 'halt'
>     elif opts.vals.reboot:
>         return 'reboot'
>     else:
>         return 'poweroff'

> i.e.
>         xm shutdown -H -> "halt"
>         xm shutdown -R -> "reboot"
>         xm shutdown    -> "poweroff"

> Linux in a guest treats "halt" and "poweroff" identically.

> So I think --halt/-H is pointless and you can remove it from the
> defaults.

>>      - Change /etc/default to use the short option format, so it will work for both xm and xl

> In principal it is possible for xl to support long options too (see e.g.
> main_create, but changing the default would be OK for 4.2 IMHO.

> Thanks for looking into this.

> Ian.




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

From xen-devel-bounces@lists.xen.org Wed Sep 05 10:48:33 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Sep 2012 10: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 1T9D9d-0002iW-OR; Wed, 05 Sep 2012 10:48:17 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <linux@eikelenboom.it>) id 1T9D9c-0002iO-5N
	for xen-devel@lists.xen.org; Wed, 05 Sep 2012 10:48:16 +0000
Received: from [85.158.139.83:60036] by server-6.bemta-5.messagelabs.com id
	0A/69-21336-FED27405; Wed, 05 Sep 2012 10:48:15 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-11.tower-182.messagelabs.com!1346842094!21455358!1
X-Originating-IP: [188.40.164.121]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5596 invoked from network); 5 Sep 2012 10:48:14 -0000
Received: from static.121.164.40.188.clients.your-server.de (HELO
	smtp.eikelenboom.it) (188.40.164.121)
	by server-11.tower-182.messagelabs.com with AES256-SHA encrypted SMTP;
	5 Sep 2012 10:48:14 -0000
Received: from 128-64-ftth.onsneteindhoven.nl ([88.159.64.128]:51876
	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 1T9D6X-0007si-Cj; Wed, 05 Sep 2012 12:45:05 +0200
Date: Wed, 5 Sep 2012 12:48:10 +0200
From: Sander Eikelenboom <linux@eikelenboom.it>
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <88861335.20120905124810@eikelenboom.it>
To: "Jan Beulich" <JBeulich@suse.com>
In-Reply-To: <5047483F0200007800098C18@nat28.tlf.novell.com>
References: <40501859.20120902104331@eikelenboom.it>
	<CC6932C2.3D99D%keir.xen@gmail.com>
	<217459398.20120902171441@eikelenboom.it>
	<5044CAD7.8030800@amd.com>
	<1144695277.20120904184345@eikelenboom.it>
	<5047420A0200007800098BB1@nat28.tlf.novell.com>
	<348297741.20120905122542@eikelenboom.it>
	<5047483F0200007800098C18@nat28.tlf.novell.com>
MIME-Version: 1.0
Cc: Wei Wang <wei.wang2@amd.com>, Keir Fraser <keir.xen@gmail.com>,
	Santosh Jodh <Santosh.Jodh@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Using debug-key 'o:  Dump IOMMU p2m table,
	locks up machine
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

DQpXZWRuZXNkYXksIFNlcHRlbWJlciA1LCAyMDEyLCAxMjo0MDozMSBQTSwgeW91IHdyb3RlOgoK
Pj4+PiBPbiAwNS4wOS4xMiBhdCAxMjoyNSwgU2FuZGVyIEVpa2VsZW5ib29tIDxsaW51eEBlaWtl
bGVuYm9vbS5pdD4gd3JvdGU6Cj4+IFdlZG5lc2RheSwgU2VwdGVtYmVyIDUsIDIwMTIsIDEyOjE0
OjAyIFBNLCB5b3Ugd3JvdGU6Cj4+Pj4+PiBPbiAwNC4wOS4xMiBhdCAxODo0MywgU2FuZGVyIEVp
a2VsZW5ib29tIDxsaW51eEBlaWtlbGVuYm9vbS5pdD4gd3JvdGU6Cj4+Pj4gLi4uLi4uLi4uLi4u
Li4uLi4uLi4uLi4uLi4uPDA+QU1ELVZpOiBJT19QQUdFX0ZBVUxUOiBkb21haW4gPSAwLCBkZXZp
Y2UgaWQgPSAKPj4+PiAweDBhMDYsIGZhdWx0IGFkZHJlc3MgPSAweGMyYzJjMmMwCj4+IAo+Pj4g
TG9va3MgbGlrZSB1c2Ugb2YgdW5pbml0aWFsaXplZCBtZW1vcnkgKGFzc3VtaW5nIHlvdSdyZSB1
c2luZyBhCj4+PiBkZWJ1ZyBoeXBlcnZpc29yLCB0aGF0J3MgdGhlIHBhdHRlcm4gc2NydWJfb25l
X3BhZ2UoKSBwdXRzCj4+PiB0aGVyZSkuIEJ1dCBpdCdzIHVuY2xlYXIgdG8gbWUgd2hhdCBkZXZp
Y2Ugc2hvdWxkIGJlIGRvaW5nIGFueQo+Pj4gSS9PIGF0IHRoYXQgcG9pbnQgKGFuZCBldmVuIGlm
IG9uZSBkb2VzLCBob3cgaXQgd291bGQgZ2V0IHRoZQo+Pj4gYmFkIGFkZHJlc3MgbG9hZGVkKS4g
V2hhdCBpcyAwYTowMC42Pwo+PiAKPj4gc2luY2UgNC4yLXJjNCBpcyBzdGlsbCB1bnN0YWJsZSBp
dCBoYXMgZGVidWc9eSBmb3Igd2hhdCBpIGtub3csIHNvIHllcy4KPj4gVGhpcyBwYXJ0aWN1bGFy
IElPX1BBR0VfRkFVTFQgaGFwcGVuZWQgYmVmb3JlIHRoZSBrZXJuZWwgbG9hZHMsIHNvIHRoZSAK
Pj4ga2VybmVsIGFuZCBwY2liYWNrIHNob3VsZG4ndCBiZSBjYXVzaW5nIHRoZSBpc3N1ZSBvbmUg
d291bGQgc2F5Lgo+PiBXaXRoIHBjaWJhY2sgaSdtIGhpZGluZyAwMzowNi4wLCAwNDowMC4qLCAw
NTowMC4wLCAwYTowMC4qIGFuZCAwNzowMC4wIGF0IAo+PiBib290Lgo+PiAKPj4gSXMgdGhlcmUg
YW55IGNvZGUgaSBjb3VsZCBhZGQgdG8gZ2V0IG1vcmUgaW5mbyB3aGVyZSBpdCBjb21lcyBmcm9t
ID8KCj4gSGFyZGx5LCBzaW5jZSB0aG9zZSBhY2Nlc3NlcyBhcmUgYXN5bmNocm9ub3VzIHRvIHdo
YXQgdGhlIENQVXMKPiBkby4gQnV0IC4uLgoKPj4gMGE6MDAuNiBVU0IgY29udHJvbGxlcjogTmV0
TW9zIFRlY2hub2xvZ3kgTUNTOTk5MCBQQ0llIHRvIDTDolBvcnQgVVNCIDIuMCBIb3N0IENvbnRy
b2xsZXIKCj4gLi4uIGFyZSB5b3VyIGtleWJvYXJkL21vdXNlIHBlcmhhcHMgY29ubmVjdGVkIHRv
IHRoaXMgb25lPyBJbgo+IHdoaWNoIGNhc2UgSSdkIHN1cHBvc2UgdGhlIDE6MSB0YWJsZXMgc2V0
IHVwIGZvciBEb20wIG1pZ2h0IG5vdAo+IGJlIGNvbXBsZXRlLiBXZWk/CgpOb3BlIHRoaXMgbWFj
aGluZSBpcyBydW5uaW5nIHdpdGhvdXQgYW55IGtleWJvYXJkL21vdXNlLCB0aGUgVVNCIGNvbnRy
b2xsZXIgYXQgcHJlc2VudCBoYXMgb25seSBvbmUgZGV2aWNlIGNvbm5lY3RlZCB0byBpdDoKaW4g
dGhlIHB2IGd1ZXN0IGxzdXNiOgpCdXMgMDA3IERldmljZSAwMDI6IElEIDEwY2Y6NTUwMCBWZWxs
ZW1hbiBDb21wb25lbnRzLCBJbmMuIDgwNTUgRXhwZXJpbWVudCBJbnRlcmZhY2UgQm9hcmQgKGFk
ZHJlc3M9MCkKCkFuZCBhcyBpIHNhaWQsIHRoZSBoYXJkd2FyZSBkaWRuJ3QgY2hhbmdlIGJldHdl
ZW4gbXkgc3dpdGNoIGZyb20geGVuLTQuMS4zIHRvIHhlbi00LjIuCgpCdXQgaSB3aWxsIHJldmVy
dCB0byA0LjEgYW5kIHNlZSBpZiBpIGNhbiBzcG90IGFueSBkaWZmZXJlbmNlIGluIHhsIGRtZXNn
IGJldHdlZW4gdGhlIHR3by4KCgo+IEphbgoKCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fXwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0
cy54ZW4ub3JnCmh0dHA6Ly9saXN0cy54ZW4ub3JnL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xen.org Wed Sep 05 10:48:33 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Sep 2012 10: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 1T9D9d-0002iW-OR; Wed, 05 Sep 2012 10:48:17 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <linux@eikelenboom.it>) id 1T9D9c-0002iO-5N
	for xen-devel@lists.xen.org; Wed, 05 Sep 2012 10:48:16 +0000
Received: from [85.158.139.83:60036] by server-6.bemta-5.messagelabs.com id
	0A/69-21336-FED27405; Wed, 05 Sep 2012 10:48:15 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-11.tower-182.messagelabs.com!1346842094!21455358!1
X-Originating-IP: [188.40.164.121]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5596 invoked from network); 5 Sep 2012 10:48:14 -0000
Received: from static.121.164.40.188.clients.your-server.de (HELO
	smtp.eikelenboom.it) (188.40.164.121)
	by server-11.tower-182.messagelabs.com with AES256-SHA encrypted SMTP;
	5 Sep 2012 10:48:14 -0000
Received: from 128-64-ftth.onsneteindhoven.nl ([88.159.64.128]:51876
	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 1T9D6X-0007si-Cj; Wed, 05 Sep 2012 12:45:05 +0200
Date: Wed, 5 Sep 2012 12:48:10 +0200
From: Sander Eikelenboom <linux@eikelenboom.it>
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <88861335.20120905124810@eikelenboom.it>
To: "Jan Beulich" <JBeulich@suse.com>
In-Reply-To: <5047483F0200007800098C18@nat28.tlf.novell.com>
References: <40501859.20120902104331@eikelenboom.it>
	<CC6932C2.3D99D%keir.xen@gmail.com>
	<217459398.20120902171441@eikelenboom.it>
	<5044CAD7.8030800@amd.com>
	<1144695277.20120904184345@eikelenboom.it>
	<5047420A0200007800098BB1@nat28.tlf.novell.com>
	<348297741.20120905122542@eikelenboom.it>
	<5047483F0200007800098C18@nat28.tlf.novell.com>
MIME-Version: 1.0
Cc: Wei Wang <wei.wang2@amd.com>, Keir Fraser <keir.xen@gmail.com>,
	Santosh Jodh <Santosh.Jodh@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Using debug-key 'o:  Dump IOMMU p2m table,
	locks up machine
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

DQpXZWRuZXNkYXksIFNlcHRlbWJlciA1LCAyMDEyLCAxMjo0MDozMSBQTSwgeW91IHdyb3RlOgoK
Pj4+PiBPbiAwNS4wOS4xMiBhdCAxMjoyNSwgU2FuZGVyIEVpa2VsZW5ib29tIDxsaW51eEBlaWtl
bGVuYm9vbS5pdD4gd3JvdGU6Cj4+IFdlZG5lc2RheSwgU2VwdGVtYmVyIDUsIDIwMTIsIDEyOjE0
OjAyIFBNLCB5b3Ugd3JvdGU6Cj4+Pj4+PiBPbiAwNC4wOS4xMiBhdCAxODo0MywgU2FuZGVyIEVp
a2VsZW5ib29tIDxsaW51eEBlaWtlbGVuYm9vbS5pdD4gd3JvdGU6Cj4+Pj4gLi4uLi4uLi4uLi4u
Li4uLi4uLi4uLi4uLi4uPDA+QU1ELVZpOiBJT19QQUdFX0ZBVUxUOiBkb21haW4gPSAwLCBkZXZp
Y2UgaWQgPSAKPj4+PiAweDBhMDYsIGZhdWx0IGFkZHJlc3MgPSAweGMyYzJjMmMwCj4+IAo+Pj4g
TG9va3MgbGlrZSB1c2Ugb2YgdW5pbml0aWFsaXplZCBtZW1vcnkgKGFzc3VtaW5nIHlvdSdyZSB1
c2luZyBhCj4+PiBkZWJ1ZyBoeXBlcnZpc29yLCB0aGF0J3MgdGhlIHBhdHRlcm4gc2NydWJfb25l
X3BhZ2UoKSBwdXRzCj4+PiB0aGVyZSkuIEJ1dCBpdCdzIHVuY2xlYXIgdG8gbWUgd2hhdCBkZXZp
Y2Ugc2hvdWxkIGJlIGRvaW5nIGFueQo+Pj4gSS9PIGF0IHRoYXQgcG9pbnQgKGFuZCBldmVuIGlm
IG9uZSBkb2VzLCBob3cgaXQgd291bGQgZ2V0IHRoZQo+Pj4gYmFkIGFkZHJlc3MgbG9hZGVkKS4g
V2hhdCBpcyAwYTowMC42Pwo+PiAKPj4gc2luY2UgNC4yLXJjNCBpcyBzdGlsbCB1bnN0YWJsZSBp
dCBoYXMgZGVidWc9eSBmb3Igd2hhdCBpIGtub3csIHNvIHllcy4KPj4gVGhpcyBwYXJ0aWN1bGFy
IElPX1BBR0VfRkFVTFQgaGFwcGVuZWQgYmVmb3JlIHRoZSBrZXJuZWwgbG9hZHMsIHNvIHRoZSAK
Pj4ga2VybmVsIGFuZCBwY2liYWNrIHNob3VsZG4ndCBiZSBjYXVzaW5nIHRoZSBpc3N1ZSBvbmUg
d291bGQgc2F5Lgo+PiBXaXRoIHBjaWJhY2sgaSdtIGhpZGluZyAwMzowNi4wLCAwNDowMC4qLCAw
NTowMC4wLCAwYTowMC4qIGFuZCAwNzowMC4wIGF0IAo+PiBib290Lgo+PiAKPj4gSXMgdGhlcmUg
YW55IGNvZGUgaSBjb3VsZCBhZGQgdG8gZ2V0IG1vcmUgaW5mbyB3aGVyZSBpdCBjb21lcyBmcm9t
ID8KCj4gSGFyZGx5LCBzaW5jZSB0aG9zZSBhY2Nlc3NlcyBhcmUgYXN5bmNocm9ub3VzIHRvIHdo
YXQgdGhlIENQVXMKPiBkby4gQnV0IC4uLgoKPj4gMGE6MDAuNiBVU0IgY29udHJvbGxlcjogTmV0
TW9zIFRlY2hub2xvZ3kgTUNTOTk5MCBQQ0llIHRvIDTDolBvcnQgVVNCIDIuMCBIb3N0IENvbnRy
b2xsZXIKCj4gLi4uIGFyZSB5b3VyIGtleWJvYXJkL21vdXNlIHBlcmhhcHMgY29ubmVjdGVkIHRv
IHRoaXMgb25lPyBJbgo+IHdoaWNoIGNhc2UgSSdkIHN1cHBvc2UgdGhlIDE6MSB0YWJsZXMgc2V0
IHVwIGZvciBEb20wIG1pZ2h0IG5vdAo+IGJlIGNvbXBsZXRlLiBXZWk/CgpOb3BlIHRoaXMgbWFj
aGluZSBpcyBydW5uaW5nIHdpdGhvdXQgYW55IGtleWJvYXJkL21vdXNlLCB0aGUgVVNCIGNvbnRy
b2xsZXIgYXQgcHJlc2VudCBoYXMgb25seSBvbmUgZGV2aWNlIGNvbm5lY3RlZCB0byBpdDoKaW4g
dGhlIHB2IGd1ZXN0IGxzdXNiOgpCdXMgMDA3IERldmljZSAwMDI6IElEIDEwY2Y6NTUwMCBWZWxs
ZW1hbiBDb21wb25lbnRzLCBJbmMuIDgwNTUgRXhwZXJpbWVudCBJbnRlcmZhY2UgQm9hcmQgKGFk
ZHJlc3M9MCkKCkFuZCBhcyBpIHNhaWQsIHRoZSBoYXJkd2FyZSBkaWRuJ3QgY2hhbmdlIGJldHdl
ZW4gbXkgc3dpdGNoIGZyb20geGVuLTQuMS4zIHRvIHhlbi00LjIuCgpCdXQgaSB3aWxsIHJldmVy
dCB0byA0LjEgYW5kIHNlZSBpZiBpIGNhbiBzcG90IGFueSBkaWZmZXJlbmNlIGluIHhsIGRtZXNn
IGJldHdlZW4gdGhlIHR3by4KCgo+IEphbgoKCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fXwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0
cy54ZW4ub3JnCmh0dHA6Ly9saXN0cy54ZW4ub3JnL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xen.org Wed Sep 05 10:52:24 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Sep 2012 10:52:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9DDQ-0002wq-6V; Wed, 05 Sep 2012 10:52: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 1T9DDO-0002wg-Cv
	for xen-devel@lists.xen.org; Wed, 05 Sep 2012 10:52:10 +0000
Received: from [85.158.143.99:28069] by server-3.bemta-4.messagelabs.com id
	41/F5-08232-9DE27405; Wed, 05 Sep 2012 10:52:09 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1346842321!27736475!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTE5ODY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11070 invoked from network); 5 Sep 2012 10:52:06 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Sep 2012 10:52:06 -0000
X-IronPort-AV: E=Sophos;i="4.80,372,1344211200"; d="scan'208";a="14355352"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Sep 2012 10:52: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.279.1; Wed, 5 Sep 2012
	11:52:01 +0100
Message-ID: <1346842320.17325.68.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Sander Eikelenboom <linux@eikelenboom.it>
Date: Wed, 5 Sep 2012 11:52:00 +0100
In-Reply-To: <475752135.20120905124350@eikelenboom.it>
References: <885821548.20120831124902@eikelenboom.it>
	<1346410506.27277.179.camel@zakaz.uk.xensource.com>
	<1342800738.20120831133238@eikelenboom.it>
	<1346413938.27277.196.camel@zakaz.uk.xensource.com>
	<475752135.20120905124350@eikelenboom.it>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] xl / xend feature parity: Missing '-a' option for
 xl 'shutdown' to shutdown all domains
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-09-05 at 11:43 +0100, Sander Eikelenboom wrote:
> The docs say you have to supply a domain_id as argument.
> But if you supply a domain_name instead it works as well.

xl(1) says "domain-id is the numeric domain id, or the domain name
(which will be internally translated to domain id)"

> But what if i'm stupid enough to give my domain a number as name (which seems to be allowed/possible)


> In that case i can't shut it down by name:
> 
> serveerstertje:~# xl list
> Name                                        ID   Mem VCPUs      State   Time(s)
> Domain-0                                     0  1024     6     r-----   22318.7
> media                                       12   256     1     -b----      73.0
> webproxy                                    14   768     5     -b----   41385.2
> www                                         15   507     2     -b----     670.8
> 13                                          17   256     1     -b----       3.2
> 
> 13                                          17   256     1     -b----       3.2
> serveerstertje:~# xl shutdown 13
> 13 is an invalid domain identifier (rc=-6)

I think this is a case of Don't Do That Then. If you want a patch to the
manpage clarifying that users should avoid purely numeric domain names
that would be nice.



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

From xen-devel-bounces@lists.xen.org Wed Sep 05 10:52:24 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Sep 2012 10:52:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9DDQ-0002wq-6V; Wed, 05 Sep 2012 10:52: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 1T9DDO-0002wg-Cv
	for xen-devel@lists.xen.org; Wed, 05 Sep 2012 10:52:10 +0000
Received: from [85.158.143.99:28069] by server-3.bemta-4.messagelabs.com id
	41/F5-08232-9DE27405; Wed, 05 Sep 2012 10:52:09 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1346842321!27736475!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTE5ODY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11070 invoked from network); 5 Sep 2012 10:52:06 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Sep 2012 10:52:06 -0000
X-IronPort-AV: E=Sophos;i="4.80,372,1344211200"; d="scan'208";a="14355352"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Sep 2012 10:52: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.279.1; Wed, 5 Sep 2012
	11:52:01 +0100
Message-ID: <1346842320.17325.68.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Sander Eikelenboom <linux@eikelenboom.it>
Date: Wed, 5 Sep 2012 11:52:00 +0100
In-Reply-To: <475752135.20120905124350@eikelenboom.it>
References: <885821548.20120831124902@eikelenboom.it>
	<1346410506.27277.179.camel@zakaz.uk.xensource.com>
	<1342800738.20120831133238@eikelenboom.it>
	<1346413938.27277.196.camel@zakaz.uk.xensource.com>
	<475752135.20120905124350@eikelenboom.it>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] xl / xend feature parity: Missing '-a' option for
 xl 'shutdown' to shutdown all domains
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-09-05 at 11:43 +0100, Sander Eikelenboom wrote:
> The docs say you have to supply a domain_id as argument.
> But if you supply a domain_name instead it works as well.

xl(1) says "domain-id is the numeric domain id, or the domain name
(which will be internally translated to domain id)"

> But what if i'm stupid enough to give my domain a number as name (which seems to be allowed/possible)


> In that case i can't shut it down by name:
> 
> serveerstertje:~# xl list
> Name                                        ID   Mem VCPUs      State   Time(s)
> Domain-0                                     0  1024     6     r-----   22318.7
> media                                       12   256     1     -b----      73.0
> webproxy                                    14   768     5     -b----   41385.2
> www                                         15   507     2     -b----     670.8
> 13                                          17   256     1     -b----       3.2
> 
> 13                                          17   256     1     -b----       3.2
> serveerstertje:~# xl shutdown 13
> 13 is an invalid domain identifier (rc=-6)

I think this is a case of Don't Do That Then. If you want a patch to the
manpage clarifying that users should avoid purely numeric domain names
that would be nice.



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

From xen-devel-bounces@lists.xen.org Wed Sep 05 10:55:50 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Sep 2012 10:55:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9DGl-0003Nd-JO; Wed, 05 Sep 2012 10:55:39 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <linux@eikelenboom.it>) id 1T9DGj-0003NI-Rz
	for xen-devel@lists.xen.org; Wed, 05 Sep 2012 10:55:38 +0000
Received: from [85.158.138.51:16429] by server-2.bemta-3.messagelabs.com id
	25/4C-04862-9AF27405; Wed, 05 Sep 2012 10:55:37 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-6.tower-174.messagelabs.com!1346842534!20727770!1
X-Originating-IP: [188.40.164.121]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14168 invoked from network); 5 Sep 2012 10:55:35 -0000
Received: from static.121.164.40.188.clients.your-server.de (HELO
	smtp.eikelenboom.it) (188.40.164.121)
	by server-6.tower-174.messagelabs.com with AES256-SHA encrypted SMTP;
	5 Sep 2012 10:55:35 -0000
Received: from 128-64-ftth.onsneteindhoven.nl ([88.159.64.128]:51879
	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 1T9DDe-0007v3-Ce; Wed, 05 Sep 2012 12:52:26 +0200
Date: Wed, 5 Sep 2012 12:55:31 +0200
From: Sander Eikelenboom <linux@eikelenboom.it>
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <117308334.20120905125531@eikelenboom.it>
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1346842320.17325.68.camel@zakaz.uk.xensource.com>
References: <885821548.20120831124902@eikelenboom.it>
	<1346410506.27277.179.camel@zakaz.uk.xensource.com>
	<1342800738.20120831133238@eikelenboom.it>
	<1346413938.27277.196.camel@zakaz.uk.xensource.com>
	<475752135.20120905124350@eikelenboom.it>
	<1346842320.17325.68.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] xl / xend feature parity: Missing '-a' option for
	xl 'shutdown' to shutdown all 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


Wednesday, September 5, 2012, 12:52:00 PM, you wrote:

> On Wed, 2012-09-05 at 11:43 +0100, Sander Eikelenboom wrote:
>> The docs say you have to supply a domain_id as argument.
>> But if you supply a domain_name instead it works as well.

> xl(1) says "domain-id is the numeric domain id, or the domain name
> (which will be internally translated to domain id)"

>> But what if i'm stupid enough to give my domain a number as name (which seems to be allowed/possible)


>> In that case i can't shut it down by name:
>> 
>> serveerstertje:~# xl list
>> Name                                        ID   Mem VCPUs      State   Time(s)
>> Domain-0                                     0  1024     6     r-----   22318.7
>> media                                       12   256     1     -b----      73.0
>> webproxy                                    14   768     5     -b----   41385.2
>> www                                         15   507     2     -b----     670.8
>> 13                                          17   256     1     -b----       3.2
>> 
>> 13                                          17   256     1     -b----       3.2
>> serveerstertje:~# xl shutdown 13
>> 13 is an invalid domain identifier (rc=-6)

> I think this is a case of Don't Do That Then. If you want a patch to the
> manpage clarifying that users should avoid purely numeric domain names
> that would be nice.

How acceptable would it be to make that explicit and enforce that policy on domain creation ?





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

From xen-devel-bounces@lists.xen.org Wed Sep 05 10:55:50 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Sep 2012 10:55:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9DGl-0003Nd-JO; Wed, 05 Sep 2012 10:55:39 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <linux@eikelenboom.it>) id 1T9DGj-0003NI-Rz
	for xen-devel@lists.xen.org; Wed, 05 Sep 2012 10:55:38 +0000
Received: from [85.158.138.51:16429] by server-2.bemta-3.messagelabs.com id
	25/4C-04862-9AF27405; Wed, 05 Sep 2012 10:55:37 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-6.tower-174.messagelabs.com!1346842534!20727770!1
X-Originating-IP: [188.40.164.121]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14168 invoked from network); 5 Sep 2012 10:55:35 -0000
Received: from static.121.164.40.188.clients.your-server.de (HELO
	smtp.eikelenboom.it) (188.40.164.121)
	by server-6.tower-174.messagelabs.com with AES256-SHA encrypted SMTP;
	5 Sep 2012 10:55:35 -0000
Received: from 128-64-ftth.onsneteindhoven.nl ([88.159.64.128]:51879
	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 1T9DDe-0007v3-Ce; Wed, 05 Sep 2012 12:52:26 +0200
Date: Wed, 5 Sep 2012 12:55:31 +0200
From: Sander Eikelenboom <linux@eikelenboom.it>
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <117308334.20120905125531@eikelenboom.it>
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1346842320.17325.68.camel@zakaz.uk.xensource.com>
References: <885821548.20120831124902@eikelenboom.it>
	<1346410506.27277.179.camel@zakaz.uk.xensource.com>
	<1342800738.20120831133238@eikelenboom.it>
	<1346413938.27277.196.camel@zakaz.uk.xensource.com>
	<475752135.20120905124350@eikelenboom.it>
	<1346842320.17325.68.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] xl / xend feature parity: Missing '-a' option for
	xl 'shutdown' to shutdown all 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


Wednesday, September 5, 2012, 12:52:00 PM, you wrote:

> On Wed, 2012-09-05 at 11:43 +0100, Sander Eikelenboom wrote:
>> The docs say you have to supply a domain_id as argument.
>> But if you supply a domain_name instead it works as well.

> xl(1) says "domain-id is the numeric domain id, or the domain name
> (which will be internally translated to domain id)"

>> But what if i'm stupid enough to give my domain a number as name (which seems to be allowed/possible)


>> In that case i can't shut it down by name:
>> 
>> serveerstertje:~# xl list
>> Name                                        ID   Mem VCPUs      State   Time(s)
>> Domain-0                                     0  1024     6     r-----   22318.7
>> media                                       12   256     1     -b----      73.0
>> webproxy                                    14   768     5     -b----   41385.2
>> www                                         15   507     2     -b----     670.8
>> 13                                          17   256     1     -b----       3.2
>> 
>> 13                                          17   256     1     -b----       3.2
>> serveerstertje:~# xl shutdown 13
>> 13 is an invalid domain identifier (rc=-6)

> I think this is a case of Don't Do That Then. If you want a patch to the
> manpage clarifying that users should avoid purely numeric domain names
> that would be nice.

How acceptable would it be to make that explicit and enforce that policy on domain creation ?





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

From xen-devel-bounces@lists.xen.org Wed Sep 05 10:57:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Sep 2012 10: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 1T9DHq-0003bZ-2v; Wed, 05 Sep 2012 10:56:46 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <iwj@xenbits.xen.org>) id 1T9D0n-0002DK-19
	for xen-devel@lists.xen.org; Wed, 05 Sep 2012 10:39:09 +0000
Received: from [85.158.143.35:39618] by server-3.bemta-4.messagelabs.com id
	68/1C-08232-BCB27405; Wed, 05 Sep 2012 10:39:07 +0000
X-Env-Sender: iwj@xenbits.xen.org
X-Msg-Ref: server-4.tower-21.messagelabs.com!1346841534!6292152!1
X-Originating-IP: [50.57.168.107]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28614 invoked from network); 5 Sep 2012 10:38:59 -0000
Received: from mail.xen.org (HELO mail.xen.org) (50.57.168.107)
	by server-4.tower-21.messagelabs.com with AES256-SHA encrypted SMTP;
	5 Sep 2012 10:38:59 -0000
Received: from xenbits.xen.org ([50.57.170.242])
	by mail.xen.org with esmtp (Exim 4.72)
	(envelope-from <iwj@xenbits.xen.org>)
	id 1T9D0R-0000nI-AY; Wed, 05 Sep 2012 10:38:47 +0000
Received: from iwj by xenbits.xen.org with local (Exim 4.72)
	(envelope-from <iwj@xenbits.xen.org>)
	id 1T9D0R-0004Zb-5d; Wed, 05 Sep 2012 10:38:47 +0000
Date: Wed, 05 Sep 2012 10:38:47 +0000
Message-Id: <E1T9D0R-0004Zb-5d@xenbits.xen.org>
Content-Type: multipart/mixed; boundary="=separator"; charset="utf-8"
Content-Transfer-Encoding: binary
MIME-Version: 1.0
X-Mailer: MIME-tools 5.428 (Entity 5.428)
To: xen-announce@lists.xen.org, xen-devel@lists.xen.org,
	xen-users@lists.xen.org, oss-security@lists.openwall.com
From: Xen.org security team <security@xen.org>
X-Mailman-Approved-At: Wed, 05 Sep 2012 10:56:44 +0000
Cc: "Xen.org security team" <security@xen.org>
Subject: [Xen-devel] Xen Security Advisory 14 (CVE-2012-3496) -
 XENMEM_populate_physmap DoS vulnerability
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--=separator
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

            Xen Security Advisory CVE-2012-3496 / XSA-14
                             version 3

           XENMEM_populate_physmap DoS vulnerability

UPDATES IN VERSION 3
====================

Public release.  Credit Matthew Daley.

ISSUE DESCRIPTION
=================

XENMEM_populate_physmap can be called with invalid flags.  By calling
it with MEMF_populate_on_demand flag set, a BUG can be triggered if a
translating paging mode is not being used.

IMPACT
======

A malicious guest kernel can crash the host.

VULNERABLE SYSTEMS
==================

All Xen systems running PV guests.  Systems running only HVM guests
are not vulnerable.

The vulnerability dates back to at least Xen 4.0.  4.0, 4.1, the 4.2
RCs, and xen-unstable.hg are all vulnerable.

MITIGATION
==========

This issue can be mitigated by ensuring that the guest kernel is
trustworthy or by running only HVM guests.

RESOLUTION
==========

Applying the appropriate attached patch will resolve the issue.

CREDIT
======

Thanks to Matthew Daley for finding this vulnerability (and that in
XSA-12) and notifying the Xen.org security team.

PATCH INFORMATION
=================

The attached patches resolve this issue

 xen-unstable                                xsa14-unstable.patch
 Xen 4.1, 4.1.x, 4.0, 4.0.x, 3.4 and 3.4.x   xsa14-xen-3.4-and-4.x.patch

$ sha256sum xsa14-*.patch
7a2e119b114708420c3484ecc338c7a198097f40e0d38854756dfa69c4c859a8  xsa14-unstable.patch
41a1ee1da7e990dc93b75fad0d46b66a2bda472e9aa288c91d1dc5d15d2c2012  xsa14-xen-3.4-and-4.x.patch
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iQEcBAEBAgAGBQJQRyVAAAoJEIP+FMlX6CvZF0IH/RV88Xqc9SdwrDZ7w6uwsRt+
2keNPNyDBYxoYeqEqP9q/zICmxEqHMk/1zvSksimuIoiblliYQPHcJjhYhiBA8aX
tarL2byKK+AE/1xvgh1BZiizCR6UV33Zi2PNdB3aaLizh82+70Lbx4ZtDg3zCpEo
cvXGyMrNwzxMS+7ORuBAC9gtMke3sBeLua4KvGMhuByDIbW+9/7124YSGo30vFa3
VHmZ8995ishkSQyzgvZVLMQ+y2G1GofUqa4gPRcNoMCULKGGkqJCyHPZfuAOY+w+
0Cy/WDIE1HZd6DIn+09IoHe+StkyPgqYkai+QYwxS+JW/vpns82fpsAtmOF64tg=
=EONA
-----END PGP SIGNATURE-----

--=separator
Content-Type: application/octet-stream; name="xsa14-unstable.patch"
Content-Disposition: attachment; filename="xsa14-unstable.patch"
Content-Transfer-Encoding: base64

eGVuOiBEb24ndCBCVUdfT04oKSBQb0Qgb3BlcmF0aW9ucyBvbiBhIG5vbi10
cmFuc2xhdGVkIGd1ZXN0LgoKVGhpcyBpcyBYU0EtMTQgLyBDVkUtMjAxMi0z
NDk2CgpTaWduZWQtb2ZmLWJ5OiBUaW0gRGVlZ2FuIDx0aW1AeGVuLm9yZz4K
UmV2aWV3ZWQtYnk6IElhbiBDYW1wYmVsbCA8aWFuLmNhbXBiZWxsQGNpdHJp
eC5jb20+ClRlc3RlZC1ieTogSWFuIENhbXBiZWxsIDxpYW4uY2FtcGJlbGxA
Y2l0cml4LmNvbT4KCmRpZmYgLXIgMzUzYmMwODAxYjExIHhlbi9hcmNoL3g4
Ni9tbS9wMm0tcG9kLmMKLS0tIGEveGVuL2FyY2gveDg2L21tL3AybS1wb2Qu
YwlNb24gQXVnIDA2IDEyOjI4OjAzIDIwMTIgKzAxMDAKKysrIGIveGVuL2Fy
Y2gveDg2L21tL3AybS1wb2QuYwlXZWQgQXVnIDE1IDEyOjA2OjQzIDIwMTIg
KzAxMDAKQEAgLTExMTcsNyArMTExNyw4IEBAIGd1ZXN0X3BoeXNtYXBfbWFy
a19wb3B1bGF0ZV9vbl9kZW1hbmQoc3QKICAgICBtZm5fdCBvbWZuOwogICAg
IGludCByYyA9IDA7CiAKLSAgICBCVUdfT04oIXBhZ2luZ19tb2RlX3RyYW5z
bGF0ZShkKSk7CisgICAgaWYgKCAhcGFnaW5nX21vZGVfdHJhbnNsYXRlKGQp
ICkKKyAgICAgICAgcmV0dXJuIC1FSU5WQUw7CiAKICAgICByYyA9IHAybV9n
Zm5fY2hlY2tfbGltaXQoZCwgZ2ZuLCBvcmRlcik7CiAgICAgaWYgKCByYyAh
PSAwICkK

--=separator
Content-Type: application/octet-stream; name="xsa14-xen-3.4-and-4.x.patch"
Content-Disposition: attachment; filename="xsa14-xen-3.4-and-4.x.patch"
Content-Transfer-Encoding: base64

eGVuOiBEb24ndCBCVUdfT04oKSBQb0Qgb3BlcmF0aW9ucyBvbiBhIG5vbi10
cmFuc2xhdGVkIGd1ZXN0LgoKVGhpcyBpcyBYU0EtMTQgLyBDVkUtMjAxMi0z
NDk2CgpTaWduZWQtb2ZmLWJ5OiBUaW0gRGVlZ2FuIDx0aW1AeGVuLm9yZz4K
UmV2aWV3ZWQtYnk6IElhbiBDYW1wYmVsbCA8aWFuLmNhbXBiZWxsQGNpdHJp
eC5jb20+ClRlc3RlZC1ieTogSWFuIENhbXBiZWxsIDxpYW4uY2FtcGJlbGxA
Y2l0cml4LmNvbT4KCmRpZmYgLXIgMTIyNWFmZjA1ZGQyIHhlbi9hcmNoL3g4
Ni9tbS9wMm0uYwotLS0gYS94ZW4vYXJjaC94ODYvbW0vcDJtLmMJVGh1IEF1
ZyAwOSAxNjo0ODowNyAyMDEyICswMTAwCisrKyBiL3hlbi9hcmNoL3g4Ni9t
bS9wMm0uYwlXZWQgQXVnIDE1IDEyOjEwOjMzIDIwMTIgKzAxMDAKQEAgLTI0
MTQsNyArMjQxNCw4IEBAIGd1ZXN0X3BoeXNtYXBfbWFya19wb3B1bGF0ZV9v
bl9kZW1hbmQoc3QKICAgICBpbnQgcG9kX2NvdW50ID0gMDsKICAgICBpbnQg
cmMgPSAwOwogCi0gICAgQlVHX09OKCFwYWdpbmdfbW9kZV90cmFuc2xhdGUo
ZCkpOworICAgIGlmICggIXBhZ2luZ19tb2RlX3RyYW5zbGF0ZShkKSApCisg
ICAgICAgIHJldHVybiAtRUlOVkFMOwogCiAgICAgcmMgPSBnZm5fY2hlY2tf
bGltaXQoZCwgZ2ZuLCBvcmRlcik7CiAgICAgaWYgKCByYyAhPSAwICkK

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

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

--=separator--


From xen-devel-bounces@lists.xen.org Wed Sep 05 10:57:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Sep 2012 10: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 1T9DHq-0003bZ-2v; Wed, 05 Sep 2012 10:56:46 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <iwj@xenbits.xen.org>) id 1T9D0n-0002DK-19
	for xen-devel@lists.xen.org; Wed, 05 Sep 2012 10:39:09 +0000
Received: from [85.158.143.35:39618] by server-3.bemta-4.messagelabs.com id
	68/1C-08232-BCB27405; Wed, 05 Sep 2012 10:39:07 +0000
X-Env-Sender: iwj@xenbits.xen.org
X-Msg-Ref: server-4.tower-21.messagelabs.com!1346841534!6292152!1
X-Originating-IP: [50.57.168.107]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28614 invoked from network); 5 Sep 2012 10:38:59 -0000
Received: from mail.xen.org (HELO mail.xen.org) (50.57.168.107)
	by server-4.tower-21.messagelabs.com with AES256-SHA encrypted SMTP;
	5 Sep 2012 10:38:59 -0000
Received: from xenbits.xen.org ([50.57.170.242])
	by mail.xen.org with esmtp (Exim 4.72)
	(envelope-from <iwj@xenbits.xen.org>)
	id 1T9D0R-0000nI-AY; Wed, 05 Sep 2012 10:38:47 +0000
Received: from iwj by xenbits.xen.org with local (Exim 4.72)
	(envelope-from <iwj@xenbits.xen.org>)
	id 1T9D0R-0004Zb-5d; Wed, 05 Sep 2012 10:38:47 +0000
Date: Wed, 05 Sep 2012 10:38:47 +0000
Message-Id: <E1T9D0R-0004Zb-5d@xenbits.xen.org>
Content-Type: multipart/mixed; boundary="=separator"; charset="utf-8"
Content-Transfer-Encoding: binary
MIME-Version: 1.0
X-Mailer: MIME-tools 5.428 (Entity 5.428)
To: xen-announce@lists.xen.org, xen-devel@lists.xen.org,
	xen-users@lists.xen.org, oss-security@lists.openwall.com
From: Xen.org security team <security@xen.org>
X-Mailman-Approved-At: Wed, 05 Sep 2012 10:56:44 +0000
Cc: "Xen.org security team" <security@xen.org>
Subject: [Xen-devel] Xen Security Advisory 14 (CVE-2012-3496) -
 XENMEM_populate_physmap DoS vulnerability
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--=separator
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

            Xen Security Advisory CVE-2012-3496 / XSA-14
                             version 3

           XENMEM_populate_physmap DoS vulnerability

UPDATES IN VERSION 3
====================

Public release.  Credit Matthew Daley.

ISSUE DESCRIPTION
=================

XENMEM_populate_physmap can be called with invalid flags.  By calling
it with MEMF_populate_on_demand flag set, a BUG can be triggered if a
translating paging mode is not being used.

IMPACT
======

A malicious guest kernel can crash the host.

VULNERABLE SYSTEMS
==================

All Xen systems running PV guests.  Systems running only HVM guests
are not vulnerable.

The vulnerability dates back to at least Xen 4.0.  4.0, 4.1, the 4.2
RCs, and xen-unstable.hg are all vulnerable.

MITIGATION
==========

This issue can be mitigated by ensuring that the guest kernel is
trustworthy or by running only HVM guests.

RESOLUTION
==========

Applying the appropriate attached patch will resolve the issue.

CREDIT
======

Thanks to Matthew Daley for finding this vulnerability (and that in
XSA-12) and notifying the Xen.org security team.

PATCH INFORMATION
=================

The attached patches resolve this issue

 xen-unstable                                xsa14-unstable.patch
 Xen 4.1, 4.1.x, 4.0, 4.0.x, 3.4 and 3.4.x   xsa14-xen-3.4-and-4.x.patch

$ sha256sum xsa14-*.patch
7a2e119b114708420c3484ecc338c7a198097f40e0d38854756dfa69c4c859a8  xsa14-unstable.patch
41a1ee1da7e990dc93b75fad0d46b66a2bda472e9aa288c91d1dc5d15d2c2012  xsa14-xen-3.4-and-4.x.patch
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iQEcBAEBAgAGBQJQRyVAAAoJEIP+FMlX6CvZF0IH/RV88Xqc9SdwrDZ7w6uwsRt+
2keNPNyDBYxoYeqEqP9q/zICmxEqHMk/1zvSksimuIoiblliYQPHcJjhYhiBA8aX
tarL2byKK+AE/1xvgh1BZiizCR6UV33Zi2PNdB3aaLizh82+70Lbx4ZtDg3zCpEo
cvXGyMrNwzxMS+7ORuBAC9gtMke3sBeLua4KvGMhuByDIbW+9/7124YSGo30vFa3
VHmZ8995ishkSQyzgvZVLMQ+y2G1GofUqa4gPRcNoMCULKGGkqJCyHPZfuAOY+w+
0Cy/WDIE1HZd6DIn+09IoHe+StkyPgqYkai+QYwxS+JW/vpns82fpsAtmOF64tg=
=EONA
-----END PGP SIGNATURE-----

--=separator
Content-Type: application/octet-stream; name="xsa14-unstable.patch"
Content-Disposition: attachment; filename="xsa14-unstable.patch"
Content-Transfer-Encoding: base64

eGVuOiBEb24ndCBCVUdfT04oKSBQb0Qgb3BlcmF0aW9ucyBvbiBhIG5vbi10
cmFuc2xhdGVkIGd1ZXN0LgoKVGhpcyBpcyBYU0EtMTQgLyBDVkUtMjAxMi0z
NDk2CgpTaWduZWQtb2ZmLWJ5OiBUaW0gRGVlZ2FuIDx0aW1AeGVuLm9yZz4K
UmV2aWV3ZWQtYnk6IElhbiBDYW1wYmVsbCA8aWFuLmNhbXBiZWxsQGNpdHJp
eC5jb20+ClRlc3RlZC1ieTogSWFuIENhbXBiZWxsIDxpYW4uY2FtcGJlbGxA
Y2l0cml4LmNvbT4KCmRpZmYgLXIgMzUzYmMwODAxYjExIHhlbi9hcmNoL3g4
Ni9tbS9wMm0tcG9kLmMKLS0tIGEveGVuL2FyY2gveDg2L21tL3AybS1wb2Qu
YwlNb24gQXVnIDA2IDEyOjI4OjAzIDIwMTIgKzAxMDAKKysrIGIveGVuL2Fy
Y2gveDg2L21tL3AybS1wb2QuYwlXZWQgQXVnIDE1IDEyOjA2OjQzIDIwMTIg
KzAxMDAKQEAgLTExMTcsNyArMTExNyw4IEBAIGd1ZXN0X3BoeXNtYXBfbWFy
a19wb3B1bGF0ZV9vbl9kZW1hbmQoc3QKICAgICBtZm5fdCBvbWZuOwogICAg
IGludCByYyA9IDA7CiAKLSAgICBCVUdfT04oIXBhZ2luZ19tb2RlX3RyYW5z
bGF0ZShkKSk7CisgICAgaWYgKCAhcGFnaW5nX21vZGVfdHJhbnNsYXRlKGQp
ICkKKyAgICAgICAgcmV0dXJuIC1FSU5WQUw7CiAKICAgICByYyA9IHAybV9n
Zm5fY2hlY2tfbGltaXQoZCwgZ2ZuLCBvcmRlcik7CiAgICAgaWYgKCByYyAh
PSAwICkK

--=separator
Content-Type: application/octet-stream; name="xsa14-xen-3.4-and-4.x.patch"
Content-Disposition: attachment; filename="xsa14-xen-3.4-and-4.x.patch"
Content-Transfer-Encoding: base64

eGVuOiBEb24ndCBCVUdfT04oKSBQb0Qgb3BlcmF0aW9ucyBvbiBhIG5vbi10
cmFuc2xhdGVkIGd1ZXN0LgoKVGhpcyBpcyBYU0EtMTQgLyBDVkUtMjAxMi0z
NDk2CgpTaWduZWQtb2ZmLWJ5OiBUaW0gRGVlZ2FuIDx0aW1AeGVuLm9yZz4K
UmV2aWV3ZWQtYnk6IElhbiBDYW1wYmVsbCA8aWFuLmNhbXBiZWxsQGNpdHJp
eC5jb20+ClRlc3RlZC1ieTogSWFuIENhbXBiZWxsIDxpYW4uY2FtcGJlbGxA
Y2l0cml4LmNvbT4KCmRpZmYgLXIgMTIyNWFmZjA1ZGQyIHhlbi9hcmNoL3g4
Ni9tbS9wMm0uYwotLS0gYS94ZW4vYXJjaC94ODYvbW0vcDJtLmMJVGh1IEF1
ZyAwOSAxNjo0ODowNyAyMDEyICswMTAwCisrKyBiL3hlbi9hcmNoL3g4Ni9t
bS9wMm0uYwlXZWQgQXVnIDE1IDEyOjEwOjMzIDIwMTIgKzAxMDAKQEAgLTI0
MTQsNyArMjQxNCw4IEBAIGd1ZXN0X3BoeXNtYXBfbWFya19wb3B1bGF0ZV9v
bl9kZW1hbmQoc3QKICAgICBpbnQgcG9kX2NvdW50ID0gMDsKICAgICBpbnQg
cmMgPSAwOwogCi0gICAgQlVHX09OKCFwYWdpbmdfbW9kZV90cmFuc2xhdGUo
ZCkpOworICAgIGlmICggIXBhZ2luZ19tb2RlX3RyYW5zbGF0ZShkKSApCisg
ICAgICAgIHJldHVybiAtRUlOVkFMOwogCiAgICAgcmMgPSBnZm5fY2hlY2tf
bGltaXQoZCwgZ2ZuLCBvcmRlcik7CiAgICAgaWYgKCByYyAhPSAwICkK

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

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

--=separator--


From xen-devel-bounces@lists.xen.org Wed Sep 05 11:00:39 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Sep 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 1T9DLQ-000492-QJ; Wed, 05 Sep 2012 11:00: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 1T9DLP-00048t-G5
	for xen-devel@lists.xen.org; Wed, 05 Sep 2012 11:00:27 +0000
Received: from [85.158.143.99:34280] by server-2.bemta-4.messagelabs.com id
	34/5F-21239-AC037405; Wed, 05 Sep 2012 11:00:26 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1346842823!18872875!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTE5ODY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8901 invoked from network); 5 Sep 2012 11:00:24 -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;
	5 Sep 2012 11:00:24 -0000
X-IronPort-AV: E=Sophos;i="4.80,372,1344211200"; d="scan'208";a="14355589"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Sep 2012 11:00:23 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Wed, 5 Sep 2012
	12:00:23 +0100
Message-ID: <1346842822.17325.69.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Sander Eikelenboom <linux@eikelenboom.it>
Date: Wed, 5 Sep 2012 12:00:22 +0100
In-Reply-To: <117308334.20120905125531@eikelenboom.it>
References: <885821548.20120831124902@eikelenboom.it>
	<1346410506.27277.179.camel@zakaz.uk.xensource.com>
	<1342800738.20120831133238@eikelenboom.it>
	<1346413938.27277.196.camel@zakaz.uk.xensource.com>
	<475752135.20120905124350@eikelenboom.it>
	<1346842320.17325.68.camel@zakaz.uk.xensource.com>
	<117308334.20120905125531@eikelenboom.it>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] xl / xend feature parity: Missing '-a' option for
 xl 'shutdown' to shutdown all domains
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-09-05 at 11:55 +0100, Sander Eikelenboom wrote:
> Wednesday, September 5, 2012, 12:52:00 PM, you wrote:
> 
> > On Wed, 2012-09-05 at 11:43 +0100, Sander Eikelenboom wrote:
> >> The docs say you have to supply a domain_id as argument.
> >> But if you supply a domain_name instead it works as well.
> 
> > xl(1) says "domain-id is the numeric domain id, or the domain name
> > (which will be internally translated to domain id)"
> 
> >> But what if i'm stupid enough to give my domain a number as name (which seems to be allowed/possible)
> 
> 
> >> In that case i can't shut it down by name:
> >> 
> >> serveerstertje:~# xl list
> >> Name                                        ID   Mem VCPUs      State   Time(s)
> >> Domain-0                                     0  1024     6     r-----   22318.7
> >> media                                       12   256     1     -b----      73.0
> >> webproxy                                    14   768     5     -b----   41385.2
> >> www                                         15   507     2     -b----     670.8
> >> 13                                          17   256     1     -b----       3.2
> >> 
> >> 13                                          17   256     1     -b----       3.2
> >> serveerstertje:~# xl shutdown 13
> >> 13 is an invalid domain identifier (rc=-6)
> 
> > I think this is a case of Don't Do That Then. If you want a patch to the
> > manpage clarifying that users should avoid purely numeric domain names
> > that would be nice.
> 
> How acceptable would it be to make that explicit and enforce that policy on domain creation ?

I wouldn't object, but perhaps for 4.3 at this stage?

It can be documented before it is enforced though.


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

From xen-devel-bounces@lists.xen.org Wed Sep 05 11:00:39 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Sep 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 1T9DLQ-000492-QJ; Wed, 05 Sep 2012 11:00: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 1T9DLP-00048t-G5
	for xen-devel@lists.xen.org; Wed, 05 Sep 2012 11:00:27 +0000
Received: from [85.158.143.99:34280] by server-2.bemta-4.messagelabs.com id
	34/5F-21239-AC037405; Wed, 05 Sep 2012 11:00:26 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1346842823!18872875!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTE5ODY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8901 invoked from network); 5 Sep 2012 11:00:24 -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;
	5 Sep 2012 11:00:24 -0000
X-IronPort-AV: E=Sophos;i="4.80,372,1344211200"; d="scan'208";a="14355589"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Sep 2012 11:00:23 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Wed, 5 Sep 2012
	12:00:23 +0100
Message-ID: <1346842822.17325.69.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Sander Eikelenboom <linux@eikelenboom.it>
Date: Wed, 5 Sep 2012 12:00:22 +0100
In-Reply-To: <117308334.20120905125531@eikelenboom.it>
References: <885821548.20120831124902@eikelenboom.it>
	<1346410506.27277.179.camel@zakaz.uk.xensource.com>
	<1342800738.20120831133238@eikelenboom.it>
	<1346413938.27277.196.camel@zakaz.uk.xensource.com>
	<475752135.20120905124350@eikelenboom.it>
	<1346842320.17325.68.camel@zakaz.uk.xensource.com>
	<117308334.20120905125531@eikelenboom.it>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] xl / xend feature parity: Missing '-a' option for
 xl 'shutdown' to shutdown all domains
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-09-05 at 11:55 +0100, Sander Eikelenboom wrote:
> Wednesday, September 5, 2012, 12:52:00 PM, you wrote:
> 
> > On Wed, 2012-09-05 at 11:43 +0100, Sander Eikelenboom wrote:
> >> The docs say you have to supply a domain_id as argument.
> >> But if you supply a domain_name instead it works as well.
> 
> > xl(1) says "domain-id is the numeric domain id, or the domain name
> > (which will be internally translated to domain id)"
> 
> >> But what if i'm stupid enough to give my domain a number as name (which seems to be allowed/possible)
> 
> 
> >> In that case i can't shut it down by name:
> >> 
> >> serveerstertje:~# xl list
> >> Name                                        ID   Mem VCPUs      State   Time(s)
> >> Domain-0                                     0  1024     6     r-----   22318.7
> >> media                                       12   256     1     -b----      73.0
> >> webproxy                                    14   768     5     -b----   41385.2
> >> www                                         15   507     2     -b----     670.8
> >> 13                                          17   256     1     -b----       3.2
> >> 
> >> 13                                          17   256     1     -b----       3.2
> >> serveerstertje:~# xl shutdown 13
> >> 13 is an invalid domain identifier (rc=-6)
> 
> > I think this is a case of Don't Do That Then. If you want a patch to the
> > manpage clarifying that users should avoid purely numeric domain names
> > that would be nice.
> 
> How acceptable would it be to make that explicit and enforce that policy on domain creation ?

I wouldn't object, but perhaps for 4.3 at this stage?

It can be documented before it is enforced though.


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

From xen-devel-bounces@lists.xen.org Wed Sep 05 11:13:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Sep 2012 11:13: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 1T9DXb-0004sq-Fw; Wed, 05 Sep 2012 11:13:03 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <iwj@xenbits.xen.org>) id 1T9DVc-0004hj-4X
	for xen-devel@lists.xen.org; Wed, 05 Sep 2012 11:11:00 +0000
Received: from [85.158.143.99:60864] by server-1.bemta-4.messagelabs.com id
	10/C3-12504-24337405; Wed, 05 Sep 2012 11:10:58 +0000
X-Env-Sender: iwj@xenbits.xen.org
X-Msg-Ref: server-11.tower-216.messagelabs.com!1346843448!21117190!1
X-Originating-IP: [50.57.168.107]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19330 invoked from network); 5 Sep 2012 11:10:50 -0000
Received: from mail.xen.org (HELO mail.xen.org) (50.57.168.107)
	by server-11.tower-216.messagelabs.com with AES256-SHA encrypted SMTP;
	5 Sep 2012 11:10:50 -0000
Received: from xenbits.xen.org ([50.57.170.242])
	by mail.xen.org with esmtp (Exim 4.72)
	(envelope-from <iwj@xenbits.xen.org>)
	id 1T9DVJ-0001Az-MN; Wed, 05 Sep 2012 11:10:41 +0000
Received: from iwj by xenbits.xen.org with local (Exim 4.72)
	(envelope-from <iwj@xenbits.xen.org>)
	id 1T9DVJ-0005Jh-0F; Wed, 05 Sep 2012 11:10:41 +0000
Date: Wed, 05 Sep 2012 11:10:41 +0000
Message-Id: <E1T9DVJ-0005Jh-0F@xenbits.xen.org>
Content-Type: multipart/mixed; boundary="=separator"; charset="utf-8"
Content-Transfer-Encoding: binary
MIME-Version: 1.0
X-Mailer: MIME-tools 5.428 (Entity 5.428)
To: xen-announce@lists.xen.org, xen-devel@lists.xen.org,
	xen-users@lists.xen.org, oss-security@lists.openwall.com
From: Xen.org security team <security@xen.org>
X-Mailman-Approved-At: Wed, 05 Sep 2012 11:13:02 +0000
Cc: "Xen.org security team" <security@xen.org>
Subject: [Xen-devel] Xen Security Advisory 15 (CVE-2012-3497) - multiple
 TMEM hypercall vulnerabilities
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--=separator
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

            Xen Security Advisory CVE-2012-3497 / XSA-15
                         version 2

              multiple TMEM hypercall vulnerabilities

UPDATES IN VERSION 2
====================

Public release.  Credit Matthew Daley.

ISSUE DESCRIPTION
=================

Several sub-operations of the Transcendent Memory (TMEM) hypercall
either do not correctly validate their inputs, do not correctly
validate the privilege of the calling guest, or have other
security-relevant bugs.

A full list of the vulnerabilities in the TMEM system is not available
at present.

IMPACT
======

An unprivileged guest can overwrite hypervisor owned memory with the
content of their choosing allowing them to escalate their privilege to
that of the host.

In addition an unprivileged guest can also crash the hypervisor,
leading to a Denial of Service attack.

VULNERABLE SYSTEMS
==================

ONLY installations where "tmem" is specified on the hypervisor command
line are vulnerable.  Most Xen installations do not do so.

All versions of Xen from 4.0 onward which have TMEM enabled and are
running guests with untrusted administrators are vulnerable.

Although we consider it unlikely, we have not been able to rule out
the possibility that an malicious unprivileged user could exploit
these issues via a trusted TMEM-aware kernel.  Therefore all
administrators are advised to disable TMEM even if all guest kernels
are controlled and trusted.

MITIGATION
==========

Only systems which have TMEM enabled at boot time are affected by this
issue.  By default TMEM is disabled unless it is explicitly enabled
via the hypervisor command line option "tmem".

TMEM has been described by its maintainers as a technology preview,
and is therefore not supported by them for use in production systems.

Pending a full security audit of the code, the Xen.org security team
recommends that Xen users do not enable TMEM.

RESOLUTION
==========

Work is ongoing, by the community maintainers for TMEM, to patch the
specific bugs as they are found.  This includes both the multiple
vulnerabilities initially reported to the Xen.org security team, and
multiple further vulnerabilities which have been discovered since then
during our ad-hoc code inspection.

At the time of writing, a complete set of fixes even for known issues
is not available.

PROCESS FOR TMEM VULNERABILITIES
================================

Until TMEM has gained production maturity, the Xen.org security team
intends (subject of course to the permission of anyone disclosing to
us) to handle these and future TMEM vulnerabilities in public, as if
they were normal non-security-related bugs.

We therefore intend that currently-known vulnerabilities will be
publicly disclosed on the xen-devel mailing list, as normal bug
reports, at the expiry of the XSA-15 embargo.  In the meantime the
list below may be helpful.

Xen.org security team will ensure, on expiry of the embargo, that the
documentation reflects TMEM's technology preview status.

CREDIT
======

Thanks to Matthew Daley for finding these vulnerabilities (and that in
XSA-12) and notifying the Xen.org security team.

LIST OF KNOWN VULNERABILITIES
=============================

**NOTE** that this is unlikely to be a complete list of problems.

**NOTE** that after publication of this advisory, after the embargo
ends, the advisory will no longer be updated to extend this list of
vulnerabilities.  See `Process for TMEM vulnerabilities', above.


Multiple tmem save-related control ops do not check for NULL
clients:

      TMEMC_SAVE_GET_CLIENT_WEIGHT, TMEMC_SAVE_GET_CLIENT_CAP,
      TMEMC_SAVE_GET_CLIENT_FLAGS and TMEMC_SAVE_END do not check
      that the cli_id used to find the client is valid, and can
      hence dereference a NULL client. This allows a malicious
      guest to crash the host (DoS), or, in the case of
      TMEMC_SAVE_END, memory corruption (DoS or worse).

Multiple tmem save-related control ops do not check guest output
buffer pointers:

      The functions tmemc_save_get_next_page,
      tmemc_save_get_next_inv and the TMEMC_SAVE_GET_POOL_UUID
      subop do not check incoming guest output buffer pointers,
      and do not use ie. copy_to_guest. A malicious guest can
      crash the host or cause memory corruption (DoS / code
      execution).

Multiple tmem ops do not check for negative pool IDs:

      The functions tmemc_save_get_next_page,
      tmemc_restore_put_page and tmemc_restore_flush_page do not
      check for negative pool IDs, allowing (at least) memory
      corruption.

do_tmem_destroy_pool does not check for invalid pool IDs:

      The function do_tmem_destroy_pool does not check for invalid
      pool IDs, allowing a malicious guest to crash the host or
      corrupt host memory (DoS / code execution).

do_tmem_control's privilege check is commented out:

      This allows any guest access to control stack operations
      (many of which themselves do not have adequate argument
      checking).

tmh_copy_from_client and tmh_copy_to_client have an integer
overflow vulnerability:

      This can corrupt host memory.

do_tmem_get()'s bad_copy error path leaves a spinlock held:

      The next operation on the same object will hang the CPU.
      This is a host DoS.

do_tmem_op has at least one error path with broken locking checks:

      This is a host DoS or worse.

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

iQEcBAEBAgAGBQJQRyVDAAoJEIP+FMlX6CvZZSEH/11RvLycH5Qm0rkmWb16iuRU
s9xmGDxGr6LDGLLYenp7RDc6FU7xjFxNeMhziIWckic2f0V1UtEqxiTHViEeOsOu
AQfiwrUaaSf+fwcDqt07bb6gTynxyqS+faLKpk4bq89tKK1318JlxWN2gRtEW5g9
KEo7Bt/O0hYuIJBlBWnH48OHPzGSrwVaw51NLt0oPqiWp4w3ObLRhVttKB7VWJlw
OQR9hSStVWhKR68VUBd/LpTZTkX/Hn5qwhX6ltgQ10RW1n4cF2pvebiKu6CtePCl
JVBJgn/4ZmaT1joJ8SpX/BONnLt0KHNrublB6vO++1m+7+lBA5qXL38gg4jl48E=
=yP/R
-----END PGP SIGNATURE-----

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

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

--=separator--


From xen-devel-bounces@lists.xen.org Wed Sep 05 11:13:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Sep 2012 11:13: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 1T9DXb-0004sq-Fw; Wed, 05 Sep 2012 11:13:03 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <iwj@xenbits.xen.org>) id 1T9DVc-0004hj-4X
	for xen-devel@lists.xen.org; Wed, 05 Sep 2012 11:11:00 +0000
Received: from [85.158.143.99:60864] by server-1.bemta-4.messagelabs.com id
	10/C3-12504-24337405; Wed, 05 Sep 2012 11:10:58 +0000
X-Env-Sender: iwj@xenbits.xen.org
X-Msg-Ref: server-11.tower-216.messagelabs.com!1346843448!21117190!1
X-Originating-IP: [50.57.168.107]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19330 invoked from network); 5 Sep 2012 11:10:50 -0000
Received: from mail.xen.org (HELO mail.xen.org) (50.57.168.107)
	by server-11.tower-216.messagelabs.com with AES256-SHA encrypted SMTP;
	5 Sep 2012 11:10:50 -0000
Received: from xenbits.xen.org ([50.57.170.242])
	by mail.xen.org with esmtp (Exim 4.72)
	(envelope-from <iwj@xenbits.xen.org>)
	id 1T9DVJ-0001Az-MN; Wed, 05 Sep 2012 11:10:41 +0000
Received: from iwj by xenbits.xen.org with local (Exim 4.72)
	(envelope-from <iwj@xenbits.xen.org>)
	id 1T9DVJ-0005Jh-0F; Wed, 05 Sep 2012 11:10:41 +0000
Date: Wed, 05 Sep 2012 11:10:41 +0000
Message-Id: <E1T9DVJ-0005Jh-0F@xenbits.xen.org>
Content-Type: multipart/mixed; boundary="=separator"; charset="utf-8"
Content-Transfer-Encoding: binary
MIME-Version: 1.0
X-Mailer: MIME-tools 5.428 (Entity 5.428)
To: xen-announce@lists.xen.org, xen-devel@lists.xen.org,
	xen-users@lists.xen.org, oss-security@lists.openwall.com
From: Xen.org security team <security@xen.org>
X-Mailman-Approved-At: Wed, 05 Sep 2012 11:13:02 +0000
Cc: "Xen.org security team" <security@xen.org>
Subject: [Xen-devel] Xen Security Advisory 15 (CVE-2012-3497) - multiple
 TMEM hypercall vulnerabilities
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--=separator
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

            Xen Security Advisory CVE-2012-3497 / XSA-15
                         version 2

              multiple TMEM hypercall vulnerabilities

UPDATES IN VERSION 2
====================

Public release.  Credit Matthew Daley.

ISSUE DESCRIPTION
=================

Several sub-operations of the Transcendent Memory (TMEM) hypercall
either do not correctly validate their inputs, do not correctly
validate the privilege of the calling guest, or have other
security-relevant bugs.

A full list of the vulnerabilities in the TMEM system is not available
at present.

IMPACT
======

An unprivileged guest can overwrite hypervisor owned memory with the
content of their choosing allowing them to escalate their privilege to
that of the host.

In addition an unprivileged guest can also crash the hypervisor,
leading to a Denial of Service attack.

VULNERABLE SYSTEMS
==================

ONLY installations where "tmem" is specified on the hypervisor command
line are vulnerable.  Most Xen installations do not do so.

All versions of Xen from 4.0 onward which have TMEM enabled and are
running guests with untrusted administrators are vulnerable.

Although we consider it unlikely, we have not been able to rule out
the possibility that an malicious unprivileged user could exploit
these issues via a trusted TMEM-aware kernel.  Therefore all
administrators are advised to disable TMEM even if all guest kernels
are controlled and trusted.

MITIGATION
==========

Only systems which have TMEM enabled at boot time are affected by this
issue.  By default TMEM is disabled unless it is explicitly enabled
via the hypervisor command line option "tmem".

TMEM has been described by its maintainers as a technology preview,
and is therefore not supported by them for use in production systems.

Pending a full security audit of the code, the Xen.org security team
recommends that Xen users do not enable TMEM.

RESOLUTION
==========

Work is ongoing, by the community maintainers for TMEM, to patch the
specific bugs as they are found.  This includes both the multiple
vulnerabilities initially reported to the Xen.org security team, and
multiple further vulnerabilities which have been discovered since then
during our ad-hoc code inspection.

At the time of writing, a complete set of fixes even for known issues
is not available.

PROCESS FOR TMEM VULNERABILITIES
================================

Until TMEM has gained production maturity, the Xen.org security team
intends (subject of course to the permission of anyone disclosing to
us) to handle these and future TMEM vulnerabilities in public, as if
they were normal non-security-related bugs.

We therefore intend that currently-known vulnerabilities will be
publicly disclosed on the xen-devel mailing list, as normal bug
reports, at the expiry of the XSA-15 embargo.  In the meantime the
list below may be helpful.

Xen.org security team will ensure, on expiry of the embargo, that the
documentation reflects TMEM's technology preview status.

CREDIT
======

Thanks to Matthew Daley for finding these vulnerabilities (and that in
XSA-12) and notifying the Xen.org security team.

LIST OF KNOWN VULNERABILITIES
=============================

**NOTE** that this is unlikely to be a complete list of problems.

**NOTE** that after publication of this advisory, after the embargo
ends, the advisory will no longer be updated to extend this list of
vulnerabilities.  See `Process for TMEM vulnerabilities', above.


Multiple tmem save-related control ops do not check for NULL
clients:

      TMEMC_SAVE_GET_CLIENT_WEIGHT, TMEMC_SAVE_GET_CLIENT_CAP,
      TMEMC_SAVE_GET_CLIENT_FLAGS and TMEMC_SAVE_END do not check
      that the cli_id used to find the client is valid, and can
      hence dereference a NULL client. This allows a malicious
      guest to crash the host (DoS), or, in the case of
      TMEMC_SAVE_END, memory corruption (DoS or worse).

Multiple tmem save-related control ops do not check guest output
buffer pointers:

      The functions tmemc_save_get_next_page,
      tmemc_save_get_next_inv and the TMEMC_SAVE_GET_POOL_UUID
      subop do not check incoming guest output buffer pointers,
      and do not use ie. copy_to_guest. A malicious guest can
      crash the host or cause memory corruption (DoS / code
      execution).

Multiple tmem ops do not check for negative pool IDs:

      The functions tmemc_save_get_next_page,
      tmemc_restore_put_page and tmemc_restore_flush_page do not
      check for negative pool IDs, allowing (at least) memory
      corruption.

do_tmem_destroy_pool does not check for invalid pool IDs:

      The function do_tmem_destroy_pool does not check for invalid
      pool IDs, allowing a malicious guest to crash the host or
      corrupt host memory (DoS / code execution).

do_tmem_control's privilege check is commented out:

      This allows any guest access to control stack operations
      (many of which themselves do not have adequate argument
      checking).

tmh_copy_from_client and tmh_copy_to_client have an integer
overflow vulnerability:

      This can corrupt host memory.

do_tmem_get()'s bad_copy error path leaves a spinlock held:

      The next operation on the same object will hang the CPU.
      This is a host DoS.

do_tmem_op has at least one error path with broken locking checks:

      This is a host DoS or worse.

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

iQEcBAEBAgAGBQJQRyVDAAoJEIP+FMlX6CvZZSEH/11RvLycH5Qm0rkmWb16iuRU
s9xmGDxGr6LDGLLYenp7RDc6FU7xjFxNeMhziIWckic2f0V1UtEqxiTHViEeOsOu
AQfiwrUaaSf+fwcDqt07bb6gTynxyqS+faLKpk4bq89tKK1318JlxWN2gRtEW5g9
KEo7Bt/O0hYuIJBlBWnH48OHPzGSrwVaw51NLt0oPqiWp4w3ObLRhVttKB7VWJlw
OQR9hSStVWhKR68VUBd/LpTZTkX/Hn5qwhX6ltgQ10RW1n4cF2pvebiKu6CtePCl
JVBJgn/4ZmaT1joJ8SpX/BONnLt0KHNrublB6vO++1m+7+lBA5qXL38gg4jl48E=
=yP/R
-----END PGP SIGNATURE-----

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

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

--=separator--


From xen-devel-bounces@lists.xen.org Wed Sep 05 11:13:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Sep 2012 11:13: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 1T9DXb-0004t6-SF; Wed, 05 Sep 2012 11:13:03 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <iwj@xenbits.xen.org>) id 1T9DXP-0004qz-PO
	for xen-devel@lists.xen.org; Wed, 05 Sep 2012 11:12:52 +0000
Received: from [85.158.139.83:19732] by server-6.bemta-5.messagelabs.com id
	B1/42-21336-2B337405; Wed, 05 Sep 2012 11:12:50 +0000
X-Env-Sender: iwj@xenbits.xen.org
X-Msg-Ref: server-11.tower-182.messagelabs.com!1346843568!21461727!1
X-Originating-IP: [50.57.168.107]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22577 invoked from network); 5 Sep 2012 11:12:49 -0000
Received: from mail.xen.org (HELO mail.xen.org) (50.57.168.107)
	by server-11.tower-182.messagelabs.com with AES256-SHA encrypted SMTP;
	5 Sep 2012 11:12:49 -0000
Received: from xenbits.xen.org ([50.57.170.242])
	by mail.xen.org with esmtp (Exim 4.72)
	(envelope-from <iwj@xenbits.xen.org>)
	id 1T9DXH-0001Cf-UU; Wed, 05 Sep 2012 11:12:43 +0000
Received: from iwj by xenbits.xen.org with local (Exim 4.72)
	(envelope-from <iwj@xenbits.xen.org>)
	id 1T9DXH-0005Qg-SS; Wed, 05 Sep 2012 11:12:43 +0000
Date: Wed, 05 Sep 2012 11:12:43 +0000
Message-Id: <E1T9DXH-0005Qg-SS@xenbits.xen.org>
Content-Type: multipart/mixed; boundary="=separator"; charset="utf-8"
Content-Transfer-Encoding: binary
MIME-Version: 1.0
X-Mailer: MIME-tools 5.428 (Entity 5.428)
To: xen-announce@lists.xen.org, xen-devel@lists.xen.org,
	xen-users@lists.xen.org, oss-security@lists.openwall.com
From: Xen.org security team <security@xen.org>
X-Mailman-Approved-At: Wed, 05 Sep 2012 11:13:02 +0000
Cc: "Xen.org security team" <security@xen.org>
Subject: [Xen-devel] Xen Security Advisory 16 (CVE-2012-3498) -
 PHYSDEVOP_map_pirq index vulnerability
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--=separator
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

            Xen Security Advisory CVE-2012-3498 / XSA-16
                             version 3

               PHYSDEVOP_map_pirq index vulnerability

UPDATES IN VERSION 3
====================

Public release.  Credit Matthew Daley.

ISSUE DESCRIPTION
=================

PHYSDEVOP_map_pirq with MAP_PIRQ_TYPE_GSI does not range check
map->index.

IMPACT
======

A malicious HVM guest kernel can crash the host.  It might also be
able to read hypervisor or guest memory.

VULNERABLE SYSTEMS
==================

All Xen systems running HVM guests.  PV guests are not vulnerable.

The vulnerability dates back to Xen 4.1.  Xen 4.0 is not vulnerable.
4.1, the 4.2 RCs, and xen-unstable.hg are vulnerable.

MITIGATION
==========

This issue can be mitigated by ensuring that the guest kernel is
trustworthy, or by running only PV guests.

RESOLUTION
==========

Applying the appropriate attached patch will resolve the issue.

CREDIT
======

Thanks to Matthew Daley for finding this vulnerability (and that in
XSA-12) and notifying the Xen.org security team.

PATCH INFORMATION
=================

The attached patches resolve this issue

  Xen unstable                                  xsa16-unstable.patch
  Xen 4.1, 4.1.x                                xsa16-xen-4.1.patch

$ sha256sum xsa16-*.patch
f8db42898620112c8e77bf116645d650b3671d4ccc49adcad09c7b4591d55cab  xsa16-unstable.patch
4b76d554b23977443209e45d3a2404d63695eb3020ff87a8e16e5e25cbddff31  xsa16-xen-4.1.patch
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iQEcBAEBAgAGBQJQRyVFAAoJEIP+FMlX6CvZkqkH/2k5sdGWVThawtjkpTfx8L3T
d0QnlJYstbvGxNkRvaafj32jApGkHWwr/Rd4w1MPxXXJOU6bmXjKKXAugVj0wl5Z
PZeVtek46S3sSNCavLH7kL1SVZoCikEH2+kv9edGhKOXxO3C+8FkM+HvoZU7tQco
ppUhEfINP9WidXlWSEmK2nhZdvrLW7KeqHTQmwx6AC1mUE0YdaF2oTZRPyOgRwIx
quYJ3hLiQiQD3eUV56iqNO19/D4jpPibBG33yurdzahRivuLTb7XD+QfKfEDZ1WC
SVqIRJha84QBjHLTtPIgmjyF8ysUXnPLol1NTxpIBFX98OCw9Ery0Zic/poFjcc=
=7hrh
-----END PGP SIGNATURE-----

--=separator
Content-Type: application/octet-stream; name="xsa16-unstable.patch"
Content-Disposition: attachment; filename="xsa16-unstable.patch"
Content-Transfer-Encoding: base64

eDg2L3B2aHZtOiBwcm9wZXJseSByYW5nZS1jaGVjayBQSFlTREVWT1BfbWFw
X3BpcnEvTUFQX1BJUlFfVFlQRV9HU0kKClRoaXMgaXMgYmVpbmcgdXNlZCBh
cyBhIGFycmF5IGluZGV4LCBhbmQgaGVuY2UgbXVzdCBiZSB2YWxpZGF0ZWQg
YmVmb3JlCnVzZS4KClRoaXMgaXMgWFNBLTE2IC8gQ1ZFLTIwMTItMzQ5OC4K
ClNpZ25lZC1vZmYtYnk6IEphbiBCZXVsaWNoIDxqYmV1bGljaEBzdXNlLmNv
bT4KCi0tLSBhL3hlbi9hcmNoL3g4Ni9waHlzZGV2LmMKKysrIGIveGVuL2Fy
Y2gveDg2L3BoeXNkZXYuYwpAQCAtNDMsMTEgKzQzLDE4IEBAIHN0YXRpYyBp
bnQgcGh5c2Rldl9odm1fbWFwX3BpcnEoCiAgICAgICAgIHN0cnVjdCBodm1f
Z2lycV9kcGNpX21hcHBpbmcgKmdpcnE7CiAgICAgICAgIHVpbnQzMl90IG1h
Y2hpbmVfZ3NpID0gMDsKIAorICAgICAgICBpZiAoICppbmRleCA8IDAgfHwg
KmluZGV4ID49IE5SX0hWTV9JUlFTICkKKyAgICAgICAgeworICAgICAgICAg
ICAgcmV0ID0gLUVJTlZBTDsKKyAgICAgICAgICAgIGJyZWFrOworICAgICAg
ICB9CisKICAgICAgICAgLyogZmluZCB0aGUgbWFjaGluZSBnc2kgY29ycmVz
cG9uZGluZyB0byB0aGUKICAgICAgICAgICogZW11bGF0ZWQgZ3NpICovCiAg
ICAgICAgIGh2bV9pcnFfZHBjaSA9IGRvbWFpbl9nZXRfaXJxX2RwY2koZCk7
CiAgICAgICAgIGlmICggaHZtX2lycV9kcGNpICkKICAgICAgICAgeworICAg
ICAgICAgICAgQlVJTERfQlVHX09OKEFSUkFZX1NJWkUoaHZtX2lycV9kcGNp
LT5naXJxKSA8IE5SX0hWTV9JUlFTKTsKICAgICAgICAgICAgIGxpc3RfZm9y
X2VhY2hfZW50cnkgKCBnaXJxLAogICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICZodm1faXJxX2RwY2ktPmdpcnFbKmluZGV4XSwKICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBsaXN0ICkK

--=separator
Content-Type: application/octet-stream; name="xsa16-xen-4.1.patch"
Content-Disposition: attachment; filename="xsa16-xen-4.1.patch"
Content-Transfer-Encoding: base64

eDg2L3B2aHZtOiBwcm9wZXJseSByYW5nZS1jaGVjayBQSFlTREVWT1BfbWFw
X3BpcnEvTUFQX1BJUlFfVFlQRV9HU0kKClRoaXMgaXMgYmVpbmcgdXNlZCBh
cyBhIGFycmF5IGluZGV4LCBhbmQgaGVuY2UgbXVzdCBiZSB2YWxpZGF0ZWQg
YmVmb3JlCnVzZS4KClRoaXMgaXMgWFNBLTE2IC8gQ1ZFLTIwMTItMzQ5OC4K
ClNpZ25lZC1vZmYtYnk6IEphbiBCZXVsaWNoIDxqYmV1bGljaEBzdXNlLmNv
bT4KCmRpZmYgLXIgMTIyNWFmZjA1ZGQyIHhlbi9hcmNoL3g4Ni9waHlzZGV2
LmMKLS0tIGEveGVuL2FyY2gveDg2L3BoeXNkZXYuYwlUaHUgQXVnIDA5IDE2
OjQ4OjA3IDIwMTIgKzAxMDAKKysrIGIveGVuL2FyY2gveDg2L3BoeXNkZXYu
YwlUaHUgQXVnIDE2IDEzOjAzOjM2IDIwMTIgKzAxMDAKQEAgLTQwLDExICs0
MCwxOCBAQCBzdGF0aWMgaW50IHBoeXNkZXZfaHZtX21hcF9waXJxKAogICAg
ICAgICBzdHJ1Y3QgaHZtX2dpcnFfZHBjaV9tYXBwaW5nICpnaXJxOwogICAg
ICAgICB1aW50MzJfdCBtYWNoaW5lX2dzaSA9IDA7CiAKKyAgICAgICAgaWYg
KCBtYXAtPmluZGV4IDwgMCB8fCBtYXAtPmluZGV4ID49IE5SX0hWTV9JUlFT
ICkKKyAgICAgICAgeworICAgICAgICAgICAgcmV0ID0gLUVJTlZBTDsKKyAg
ICAgICAgICAgIGJyZWFrOworICAgICAgICB9CisKICAgICAgICAgLyogZmlu
ZCB0aGUgbWFjaGluZSBnc2kgY29ycmVzcG9uZGluZyB0byB0aGUKICAgICAg
ICAgICogZW11bGF0ZWQgZ3NpICovCiAgICAgICAgIGh2bV9pcnFfZHBjaSA9
IGRvbWFpbl9nZXRfaXJxX2RwY2koZCk7CiAgICAgICAgIGlmICggaHZtX2ly
cV9kcGNpICkKICAgICAgICAgeworICAgICAgICAgICAgQlVJTERfQlVHX09O
KEFSUkFZX1NJWkUoaHZtX2lycV9kcGNpLT5naXJxKSA8IE5SX0hWTV9JUlFT
KTsKICAgICAgICAgICAgIGxpc3RfZm9yX2VhY2hfZW50cnkgKCBnaXJxLAog
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICZodm1faXJxX2Rw
Y2ktPmdpcnFbbWFwLT5pbmRleF0sCiAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgbGlzdCApCg==

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

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

--=separator--


From xen-devel-bounces@lists.xen.org Wed Sep 05 11:13:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Sep 2012 11:13: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 1T9DXb-0004t6-SF; Wed, 05 Sep 2012 11:13:03 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <iwj@xenbits.xen.org>) id 1T9DXP-0004qz-PO
	for xen-devel@lists.xen.org; Wed, 05 Sep 2012 11:12:52 +0000
Received: from [85.158.139.83:19732] by server-6.bemta-5.messagelabs.com id
	B1/42-21336-2B337405; Wed, 05 Sep 2012 11:12:50 +0000
X-Env-Sender: iwj@xenbits.xen.org
X-Msg-Ref: server-11.tower-182.messagelabs.com!1346843568!21461727!1
X-Originating-IP: [50.57.168.107]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22577 invoked from network); 5 Sep 2012 11:12:49 -0000
Received: from mail.xen.org (HELO mail.xen.org) (50.57.168.107)
	by server-11.tower-182.messagelabs.com with AES256-SHA encrypted SMTP;
	5 Sep 2012 11:12:49 -0000
Received: from xenbits.xen.org ([50.57.170.242])
	by mail.xen.org with esmtp (Exim 4.72)
	(envelope-from <iwj@xenbits.xen.org>)
	id 1T9DXH-0001Cf-UU; Wed, 05 Sep 2012 11:12:43 +0000
Received: from iwj by xenbits.xen.org with local (Exim 4.72)
	(envelope-from <iwj@xenbits.xen.org>)
	id 1T9DXH-0005Qg-SS; Wed, 05 Sep 2012 11:12:43 +0000
Date: Wed, 05 Sep 2012 11:12:43 +0000
Message-Id: <E1T9DXH-0005Qg-SS@xenbits.xen.org>
Content-Type: multipart/mixed; boundary="=separator"; charset="utf-8"
Content-Transfer-Encoding: binary
MIME-Version: 1.0
X-Mailer: MIME-tools 5.428 (Entity 5.428)
To: xen-announce@lists.xen.org, xen-devel@lists.xen.org,
	xen-users@lists.xen.org, oss-security@lists.openwall.com
From: Xen.org security team <security@xen.org>
X-Mailman-Approved-At: Wed, 05 Sep 2012 11:13:02 +0000
Cc: "Xen.org security team" <security@xen.org>
Subject: [Xen-devel] Xen Security Advisory 16 (CVE-2012-3498) -
 PHYSDEVOP_map_pirq index vulnerability
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--=separator
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

            Xen Security Advisory CVE-2012-3498 / XSA-16
                             version 3

               PHYSDEVOP_map_pirq index vulnerability

UPDATES IN VERSION 3
====================

Public release.  Credit Matthew Daley.

ISSUE DESCRIPTION
=================

PHYSDEVOP_map_pirq with MAP_PIRQ_TYPE_GSI does not range check
map->index.

IMPACT
======

A malicious HVM guest kernel can crash the host.  It might also be
able to read hypervisor or guest memory.

VULNERABLE SYSTEMS
==================

All Xen systems running HVM guests.  PV guests are not vulnerable.

The vulnerability dates back to Xen 4.1.  Xen 4.0 is not vulnerable.
4.1, the 4.2 RCs, and xen-unstable.hg are vulnerable.

MITIGATION
==========

This issue can be mitigated by ensuring that the guest kernel is
trustworthy, or by running only PV guests.

RESOLUTION
==========

Applying the appropriate attached patch will resolve the issue.

CREDIT
======

Thanks to Matthew Daley for finding this vulnerability (and that in
XSA-12) and notifying the Xen.org security team.

PATCH INFORMATION
=================

The attached patches resolve this issue

  Xen unstable                                  xsa16-unstable.patch
  Xen 4.1, 4.1.x                                xsa16-xen-4.1.patch

$ sha256sum xsa16-*.patch
f8db42898620112c8e77bf116645d650b3671d4ccc49adcad09c7b4591d55cab  xsa16-unstable.patch
4b76d554b23977443209e45d3a2404d63695eb3020ff87a8e16e5e25cbddff31  xsa16-xen-4.1.patch
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iQEcBAEBAgAGBQJQRyVFAAoJEIP+FMlX6CvZkqkH/2k5sdGWVThawtjkpTfx8L3T
d0QnlJYstbvGxNkRvaafj32jApGkHWwr/Rd4w1MPxXXJOU6bmXjKKXAugVj0wl5Z
PZeVtek46S3sSNCavLH7kL1SVZoCikEH2+kv9edGhKOXxO3C+8FkM+HvoZU7tQco
ppUhEfINP9WidXlWSEmK2nhZdvrLW7KeqHTQmwx6AC1mUE0YdaF2oTZRPyOgRwIx
quYJ3hLiQiQD3eUV56iqNO19/D4jpPibBG33yurdzahRivuLTb7XD+QfKfEDZ1WC
SVqIRJha84QBjHLTtPIgmjyF8ysUXnPLol1NTxpIBFX98OCw9Ery0Zic/poFjcc=
=7hrh
-----END PGP SIGNATURE-----

--=separator
Content-Type: application/octet-stream; name="xsa16-unstable.patch"
Content-Disposition: attachment; filename="xsa16-unstable.patch"
Content-Transfer-Encoding: base64

eDg2L3B2aHZtOiBwcm9wZXJseSByYW5nZS1jaGVjayBQSFlTREVWT1BfbWFw
X3BpcnEvTUFQX1BJUlFfVFlQRV9HU0kKClRoaXMgaXMgYmVpbmcgdXNlZCBh
cyBhIGFycmF5IGluZGV4LCBhbmQgaGVuY2UgbXVzdCBiZSB2YWxpZGF0ZWQg
YmVmb3JlCnVzZS4KClRoaXMgaXMgWFNBLTE2IC8gQ1ZFLTIwMTItMzQ5OC4K
ClNpZ25lZC1vZmYtYnk6IEphbiBCZXVsaWNoIDxqYmV1bGljaEBzdXNlLmNv
bT4KCi0tLSBhL3hlbi9hcmNoL3g4Ni9waHlzZGV2LmMKKysrIGIveGVuL2Fy
Y2gveDg2L3BoeXNkZXYuYwpAQCAtNDMsMTEgKzQzLDE4IEBAIHN0YXRpYyBp
bnQgcGh5c2Rldl9odm1fbWFwX3BpcnEoCiAgICAgICAgIHN0cnVjdCBodm1f
Z2lycV9kcGNpX21hcHBpbmcgKmdpcnE7CiAgICAgICAgIHVpbnQzMl90IG1h
Y2hpbmVfZ3NpID0gMDsKIAorICAgICAgICBpZiAoICppbmRleCA8IDAgfHwg
KmluZGV4ID49IE5SX0hWTV9JUlFTICkKKyAgICAgICAgeworICAgICAgICAg
ICAgcmV0ID0gLUVJTlZBTDsKKyAgICAgICAgICAgIGJyZWFrOworICAgICAg
ICB9CisKICAgICAgICAgLyogZmluZCB0aGUgbWFjaGluZSBnc2kgY29ycmVz
cG9uZGluZyB0byB0aGUKICAgICAgICAgICogZW11bGF0ZWQgZ3NpICovCiAg
ICAgICAgIGh2bV9pcnFfZHBjaSA9IGRvbWFpbl9nZXRfaXJxX2RwY2koZCk7
CiAgICAgICAgIGlmICggaHZtX2lycV9kcGNpICkKICAgICAgICAgeworICAg
ICAgICAgICAgQlVJTERfQlVHX09OKEFSUkFZX1NJWkUoaHZtX2lycV9kcGNp
LT5naXJxKSA8IE5SX0hWTV9JUlFTKTsKICAgICAgICAgICAgIGxpc3RfZm9y
X2VhY2hfZW50cnkgKCBnaXJxLAogICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICZodm1faXJxX2RwY2ktPmdpcnFbKmluZGV4XSwKICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBsaXN0ICkK

--=separator
Content-Type: application/octet-stream; name="xsa16-xen-4.1.patch"
Content-Disposition: attachment; filename="xsa16-xen-4.1.patch"
Content-Transfer-Encoding: base64

eDg2L3B2aHZtOiBwcm9wZXJseSByYW5nZS1jaGVjayBQSFlTREVWT1BfbWFw
X3BpcnEvTUFQX1BJUlFfVFlQRV9HU0kKClRoaXMgaXMgYmVpbmcgdXNlZCBh
cyBhIGFycmF5IGluZGV4LCBhbmQgaGVuY2UgbXVzdCBiZSB2YWxpZGF0ZWQg
YmVmb3JlCnVzZS4KClRoaXMgaXMgWFNBLTE2IC8gQ1ZFLTIwMTItMzQ5OC4K
ClNpZ25lZC1vZmYtYnk6IEphbiBCZXVsaWNoIDxqYmV1bGljaEBzdXNlLmNv
bT4KCmRpZmYgLXIgMTIyNWFmZjA1ZGQyIHhlbi9hcmNoL3g4Ni9waHlzZGV2
LmMKLS0tIGEveGVuL2FyY2gveDg2L3BoeXNkZXYuYwlUaHUgQXVnIDA5IDE2
OjQ4OjA3IDIwMTIgKzAxMDAKKysrIGIveGVuL2FyY2gveDg2L3BoeXNkZXYu
YwlUaHUgQXVnIDE2IDEzOjAzOjM2IDIwMTIgKzAxMDAKQEAgLTQwLDExICs0
MCwxOCBAQCBzdGF0aWMgaW50IHBoeXNkZXZfaHZtX21hcF9waXJxKAogICAg
ICAgICBzdHJ1Y3QgaHZtX2dpcnFfZHBjaV9tYXBwaW5nICpnaXJxOwogICAg
ICAgICB1aW50MzJfdCBtYWNoaW5lX2dzaSA9IDA7CiAKKyAgICAgICAgaWYg
KCBtYXAtPmluZGV4IDwgMCB8fCBtYXAtPmluZGV4ID49IE5SX0hWTV9JUlFT
ICkKKyAgICAgICAgeworICAgICAgICAgICAgcmV0ID0gLUVJTlZBTDsKKyAg
ICAgICAgICAgIGJyZWFrOworICAgICAgICB9CisKICAgICAgICAgLyogZmlu
ZCB0aGUgbWFjaGluZSBnc2kgY29ycmVzcG9uZGluZyB0byB0aGUKICAgICAg
ICAgICogZW11bGF0ZWQgZ3NpICovCiAgICAgICAgIGh2bV9pcnFfZHBjaSA9
IGRvbWFpbl9nZXRfaXJxX2RwY2koZCk7CiAgICAgICAgIGlmICggaHZtX2ly
cV9kcGNpICkKICAgICAgICAgeworICAgICAgICAgICAgQlVJTERfQlVHX09O
KEFSUkFZX1NJWkUoaHZtX2lycV9kcGNpLT5naXJxKSA8IE5SX0hWTV9JUlFT
KTsKICAgICAgICAgICAgIGxpc3RfZm9yX2VhY2hfZW50cnkgKCBnaXJxLAog
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICZodm1faXJxX2Rw
Y2ktPmdpcnFbbWFwLT5pbmRleF0sCiAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgbGlzdCApCg==

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

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

--=separator--


From xen-devel-bounces@lists.xen.org Wed Sep 05 11:16:42 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Sep 2012 11: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 1T9Day-0005E2-NM; Wed, 05 Sep 2012 11:16:32 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <iwj@xenbits.xen.org>)
	id 1T9DYt-000551-Ug; Wed, 05 Sep 2012 11:14:24 +0000
X-Env-Sender: iwj@xenbits.xen.org
X-Msg-Ref: server-15.tower-27.messagelabs.com!1346843656!2698197!1
X-Originating-IP: [50.57.168.107]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31598 invoked from network); 5 Sep 2012 11:14:17 -0000
Received: from mail.xen.org (HELO mail.xen.org) (50.57.168.107)
	by server-15.tower-27.messagelabs.com with AES256-SHA encrypted SMTP;
	5 Sep 2012 11:14:17 -0000
Received: from xenbits.xen.org ([50.57.170.242])
	by mail.xen.org with esmtp (Exim 4.72)
	(envelope-from <iwj@xenbits.xen.org>)
	id 1T9DYh-0001EZ-BG; Wed, 05 Sep 2012 11:14:11 +0000
Received: from iwj by xenbits.xen.org with local (Exim 4.72)
	(envelope-from <iwj@xenbits.xen.org>)
	id 1T9DYh-0005Tm-0t; Wed, 05 Sep 2012 11:14:11 +0000
Date: Wed, 05 Sep 2012 11:14:11 +0000
Message-Id: <E1T9DYh-0005Tm-0t@xenbits.xen.org>
Content-Type: multipart/mixed; boundary="=separator"; charset="utf-8"
Content-Transfer-Encoding: binary
MIME-Version: 1.0
X-Mailer: MIME-tools 5.428 (Entity 5.428)
To: xen-announce@lists.xen.org, xen-devel@lists.xen.org,
	xen-users@lists.xen.org, oss-security@lists.openwall.com
From: Xen.org security team <security@xen.org>
X-Mailman-Approved-At: Wed, 05 Sep 2012 11:16:30 +0000
Cc: "Xen.org security team" <security@xen.org>
Subject: [Xen-devel] Xen Security Advisory 18 (CVE-2012-3516) - grant table
 entry swaps have inadequate bounds 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>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--=separator
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

            Xen Security Advisory CVE-2012-3516 / XSA-18
                           version 2

       grant table entry swaps have inadequate bounds checking

UPDATES IN VERSION 2
====================

Public release.

ISSUE DESCRIPTION
=================

The grant table hypercall's GNTTABOP_swap_grant_ref sub-operation does
not perform adequate checks on the input grant references.

IMPACT
======

A malicious guest kernel or administrator can crash the host.

It may be possible for an attacker to swap a valid grant reference,
which they control, with an invalid one allowing them to write
abitrary values to hypervisor memory. This could potentially lead to a
privilege escalation.

VULNERABLE SYSTEMS
==================

Xen-unstable, including Xen 4.2 release candidates are vulnerable to
this issue.

Xen 4.1 and earlier do not include this hypercall and are therefore
not vulnerable.

MITIGATION
==========

The only mitigation is not to run guests which have untrusted
administrators.

RESOLUTION
==========

Applying the attached patch will resolve the issue.

PATCH INFORMATION
=================

The attached patch resolves this issue

    Xen unstable                               xsa18-unstable.patch

$ sha256sum xsa18-unstable.patch
ad354a1964fc52b0e48d405514156935cc8dfcb5bdaee307e3e74afcc0ca8914  xsa18-unstable.patch
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iQEcBAEBAgAGBQJQRzP3AAoJEIP+FMlX6CvZ350H/jfmrx6a1pNYF3KYtVVIXu1y
ZERi/qxji162XGvB+7gdq+IdhLYAeWXRFF309U1FwcRxaQJPRAT024q6Hs+ITr9i
L7OnSP9s+UHT4251X3UlOnEfQyKF6NKJIYbamQbfVIvVPdUtNLj4SKYqxlvjyyc3
DpqiARD5f9+i7OkcojvhXszlbMgbpSQ8TYCW5De0dTkZgKQYq2hRuYf/1hmZ1lJt
vFEkTCFxO7uxoH6gulyuEjszDYFAUmE3xdxKbT11mIkwnS1wfgp4Ob5H0ioSDNJo
oOxqt4KsuNXHDW/B8QlxnQejKBL0INtmOjh7GMox4bvxg4gP57ZlDweC2lkR37c=
=dD8C
-----END PGP SIGNATURE-----

--=separator
Content-Type: application/octet-stream; name="xsa18-unstable.patch"
Content-Disposition: attachment; filename="xsa18-unstable.patch"
Content-Transfer-Encoding: base64

eGVuL2dudHRhYjogVmFsaWRhdGUgaW5wdXQgdG8gR05UVEFCT1Bfc3dhcF9n
cmFudF9yZWYKCnhlbi11bnN0YWJsZSBjL3MgMjQ1NDg6ZDExNTg0NGViZmJi
IGludHJvZHVjZXMgYSBuZXcgR05UVEFCT1AgdG8gc3dhcApncmFudCByZWZz
LiAgSG93ZXZlciwgaXQgZmFpbHMgdG8gdmFsaWRhdGUgdGhlIHR3byByZWZz
IHBhc3NlZCBmcm9tCnRoZSBndWVzdC4KClRoZSByZXN1bHQgaXMgdGhhdCBw
YXNzaW5nIG91dC1vZi1yYW5nZSByZWZzIGNhbiBjYXVzZSBYZW4gdG8gcmVh
ZApwYXN0IHRoZSBlbmQgb2YgdGhlIGdyYW50X3RhYmxlLT5hY3RpdmVbXSBh
cnJheSwgYW5kIGRlZmVyZW5jZQp3aGF0ZXZlciBpdCBmaW5kcy4gIFR5cGlj
YWxseSwgdGhpcyByZXN1bHRzIGluIFhlbiB0cnlpbmcgdG8gZGVmZXJlbmNl
CmEgbG93IHBvaW50ZXIgYW5kIGZhaWwgd2l0aCBhIHBhZ2UtZmF1bHQuCgpB
cyB0aGlzIGh5cGVyY2FsbCBjYW4gYmUgaXNzdWVkIGJ5IGFuIHVucHJpdmls
ZWdlZCBndWVzdCwgdGhpcyBpcyBhCkRlbmlhbCBvZiBTZXJ2aWNlIGFnYWlu
c3QgWGVuLgoKU2lnbmVkLW9mZi1ieTogQW5kcmV3IENvb3BlciA8YW5kcmV3
LmNvb3BlcjNAY2l0cml4LmNvbT4KQWNrZWQtYnk6IFBhdWwgRHVycmFudCA8
cGF1bC5kdXJyYW50QGNpdHJpeC5jb20+CgpkaWZmIC0tZ2l0IGEveGVuL2Nv
bW1vbi9ncmFudF90YWJsZS5jIGIveGVuL2NvbW1vbi9ncmFudF90YWJsZS5j
CmluZGV4IDk5NjFlODMuLjMyZGUyOTUgMTAwNjQ0Ci0tLSBhL3hlbi9jb21t
b24vZ3JhbnRfdGFibGUuYworKysgYi94ZW4vY29tbW9uL2dyYW50X3RhYmxl
LmMKQEAgLTIzMjgsNiArMjMyOCwxMiBAQCBfX2dudHRhYl9zd2FwX2dyYW50
X3JlZihncmFudF9yZWZfdCByZWZfYSwgZ3JhbnRfcmVmX3QgcmVmX2IpCiAK
ICAgICBzcGluX2xvY2soJmd0LT5sb2NrKTsKIAorICAgIC8qIEJvdW5kcyBj
aGVjayBvbiB0aGUgZ3JhbnQgcmVmcyAqLworICAgIGlmICggdW5saWtlbHko
cmVmX2EgPj0gbnJfZ3JhbnRfZW50cmllcyhkLT5ncmFudF90YWJsZSkpKQor
ICAgICAgICBQSU5fRkFJTChvdXQsIEdOVFNUX2JhZF9nbnRyZWYsICJCYWQg
cmVmLWEgKCVkKS5cbiIsIHJlZl9hKTsKKyAgICBpZiAoIHVubGlrZWx5KHJl
Zl9iID49IG5yX2dyYW50X2VudHJpZXMoZC0+Z3JhbnRfdGFibGUpKSkKKyAg
ICAgICAgUElOX0ZBSUwob3V0LCBHTlRTVF9iYWRfZ250cmVmLCAiQmFkIHJl
Zi1iICglZCkuXG4iLCByZWZfYik7CisKICAgICBhY3QgPSAmYWN0aXZlX2Vu
dHJ5KGd0LCByZWZfYSk7CiAgICAgaWYgKCBhY3QtPnBpbiApCiAgICAgICAg
IFBJTl9GQUlMKG91dCwgR05UU1RfZWFnYWluLCAicmVmIGEgJWxkIGJ1c3lc
biIsIChsb25nKXJlZl9hKTsK

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

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

--=separator--


From xen-devel-bounces@lists.xen.org Wed Sep 05 11:16:42 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Sep 2012 11: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 1T9Day-0005E2-NM; Wed, 05 Sep 2012 11:16:32 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <iwj@xenbits.xen.org>)
	id 1T9DYt-000551-Ug; Wed, 05 Sep 2012 11:14:24 +0000
X-Env-Sender: iwj@xenbits.xen.org
X-Msg-Ref: server-15.tower-27.messagelabs.com!1346843656!2698197!1
X-Originating-IP: [50.57.168.107]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31598 invoked from network); 5 Sep 2012 11:14:17 -0000
Received: from mail.xen.org (HELO mail.xen.org) (50.57.168.107)
	by server-15.tower-27.messagelabs.com with AES256-SHA encrypted SMTP;
	5 Sep 2012 11:14:17 -0000
Received: from xenbits.xen.org ([50.57.170.242])
	by mail.xen.org with esmtp (Exim 4.72)
	(envelope-from <iwj@xenbits.xen.org>)
	id 1T9DYh-0001EZ-BG; Wed, 05 Sep 2012 11:14:11 +0000
Received: from iwj by xenbits.xen.org with local (Exim 4.72)
	(envelope-from <iwj@xenbits.xen.org>)
	id 1T9DYh-0005Tm-0t; Wed, 05 Sep 2012 11:14:11 +0000
Date: Wed, 05 Sep 2012 11:14:11 +0000
Message-Id: <E1T9DYh-0005Tm-0t@xenbits.xen.org>
Content-Type: multipart/mixed; boundary="=separator"; charset="utf-8"
Content-Transfer-Encoding: binary
MIME-Version: 1.0
X-Mailer: MIME-tools 5.428 (Entity 5.428)
To: xen-announce@lists.xen.org, xen-devel@lists.xen.org,
	xen-users@lists.xen.org, oss-security@lists.openwall.com
From: Xen.org security team <security@xen.org>
X-Mailman-Approved-At: Wed, 05 Sep 2012 11:16:30 +0000
Cc: "Xen.org security team" <security@xen.org>
Subject: [Xen-devel] Xen Security Advisory 18 (CVE-2012-3516) - grant table
 entry swaps have inadequate bounds 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>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--=separator
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

            Xen Security Advisory CVE-2012-3516 / XSA-18
                           version 2

       grant table entry swaps have inadequate bounds checking

UPDATES IN VERSION 2
====================

Public release.

ISSUE DESCRIPTION
=================

The grant table hypercall's GNTTABOP_swap_grant_ref sub-operation does
not perform adequate checks on the input grant references.

IMPACT
======

A malicious guest kernel or administrator can crash the host.

It may be possible for an attacker to swap a valid grant reference,
which they control, with an invalid one allowing them to write
abitrary values to hypervisor memory. This could potentially lead to a
privilege escalation.

VULNERABLE SYSTEMS
==================

Xen-unstable, including Xen 4.2 release candidates are vulnerable to
this issue.

Xen 4.1 and earlier do not include this hypercall and are therefore
not vulnerable.

MITIGATION
==========

The only mitigation is not to run guests which have untrusted
administrators.

RESOLUTION
==========

Applying the attached patch will resolve the issue.

PATCH INFORMATION
=================

The attached patch resolves this issue

    Xen unstable                               xsa18-unstable.patch

$ sha256sum xsa18-unstable.patch
ad354a1964fc52b0e48d405514156935cc8dfcb5bdaee307e3e74afcc0ca8914  xsa18-unstable.patch
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iQEcBAEBAgAGBQJQRzP3AAoJEIP+FMlX6CvZ350H/jfmrx6a1pNYF3KYtVVIXu1y
ZERi/qxji162XGvB+7gdq+IdhLYAeWXRFF309U1FwcRxaQJPRAT024q6Hs+ITr9i
L7OnSP9s+UHT4251X3UlOnEfQyKF6NKJIYbamQbfVIvVPdUtNLj4SKYqxlvjyyc3
DpqiARD5f9+i7OkcojvhXszlbMgbpSQ8TYCW5De0dTkZgKQYq2hRuYf/1hmZ1lJt
vFEkTCFxO7uxoH6gulyuEjszDYFAUmE3xdxKbT11mIkwnS1wfgp4Ob5H0ioSDNJo
oOxqt4KsuNXHDW/B8QlxnQejKBL0INtmOjh7GMox4bvxg4gP57ZlDweC2lkR37c=
=dD8C
-----END PGP SIGNATURE-----

--=separator
Content-Type: application/octet-stream; name="xsa18-unstable.patch"
Content-Disposition: attachment; filename="xsa18-unstable.patch"
Content-Transfer-Encoding: base64

eGVuL2dudHRhYjogVmFsaWRhdGUgaW5wdXQgdG8gR05UVEFCT1Bfc3dhcF9n
cmFudF9yZWYKCnhlbi11bnN0YWJsZSBjL3MgMjQ1NDg6ZDExNTg0NGViZmJi
IGludHJvZHVjZXMgYSBuZXcgR05UVEFCT1AgdG8gc3dhcApncmFudCByZWZz
LiAgSG93ZXZlciwgaXQgZmFpbHMgdG8gdmFsaWRhdGUgdGhlIHR3byByZWZz
IHBhc3NlZCBmcm9tCnRoZSBndWVzdC4KClRoZSByZXN1bHQgaXMgdGhhdCBw
YXNzaW5nIG91dC1vZi1yYW5nZSByZWZzIGNhbiBjYXVzZSBYZW4gdG8gcmVh
ZApwYXN0IHRoZSBlbmQgb2YgdGhlIGdyYW50X3RhYmxlLT5hY3RpdmVbXSBh
cnJheSwgYW5kIGRlZmVyZW5jZQp3aGF0ZXZlciBpdCBmaW5kcy4gIFR5cGlj
YWxseSwgdGhpcyByZXN1bHRzIGluIFhlbiB0cnlpbmcgdG8gZGVmZXJlbmNl
CmEgbG93IHBvaW50ZXIgYW5kIGZhaWwgd2l0aCBhIHBhZ2UtZmF1bHQuCgpB
cyB0aGlzIGh5cGVyY2FsbCBjYW4gYmUgaXNzdWVkIGJ5IGFuIHVucHJpdmls
ZWdlZCBndWVzdCwgdGhpcyBpcyBhCkRlbmlhbCBvZiBTZXJ2aWNlIGFnYWlu
c3QgWGVuLgoKU2lnbmVkLW9mZi1ieTogQW5kcmV3IENvb3BlciA8YW5kcmV3
LmNvb3BlcjNAY2l0cml4LmNvbT4KQWNrZWQtYnk6IFBhdWwgRHVycmFudCA8
cGF1bC5kdXJyYW50QGNpdHJpeC5jb20+CgpkaWZmIC0tZ2l0IGEveGVuL2Nv
bW1vbi9ncmFudF90YWJsZS5jIGIveGVuL2NvbW1vbi9ncmFudF90YWJsZS5j
CmluZGV4IDk5NjFlODMuLjMyZGUyOTUgMTAwNjQ0Ci0tLSBhL3hlbi9jb21t
b24vZ3JhbnRfdGFibGUuYworKysgYi94ZW4vY29tbW9uL2dyYW50X3RhYmxl
LmMKQEAgLTIzMjgsNiArMjMyOCwxMiBAQCBfX2dudHRhYl9zd2FwX2dyYW50
X3JlZihncmFudF9yZWZfdCByZWZfYSwgZ3JhbnRfcmVmX3QgcmVmX2IpCiAK
ICAgICBzcGluX2xvY2soJmd0LT5sb2NrKTsKIAorICAgIC8qIEJvdW5kcyBj
aGVjayBvbiB0aGUgZ3JhbnQgcmVmcyAqLworICAgIGlmICggdW5saWtlbHko
cmVmX2EgPj0gbnJfZ3JhbnRfZW50cmllcyhkLT5ncmFudF90YWJsZSkpKQor
ICAgICAgICBQSU5fRkFJTChvdXQsIEdOVFNUX2JhZF9nbnRyZWYsICJCYWQg
cmVmLWEgKCVkKS5cbiIsIHJlZl9hKTsKKyAgICBpZiAoIHVubGlrZWx5KHJl
Zl9iID49IG5yX2dyYW50X2VudHJpZXMoZC0+Z3JhbnRfdGFibGUpKSkKKyAg
ICAgICAgUElOX0ZBSUwob3V0LCBHTlRTVF9iYWRfZ250cmVmLCAiQmFkIHJl
Zi1iICglZCkuXG4iLCByZWZfYik7CisKICAgICBhY3QgPSAmYWN0aXZlX2Vu
dHJ5KGd0LCByZWZfYSk7CiAgICAgaWYgKCBhY3QtPnBpbiApCiAgICAgICAg
IFBJTl9GQUlMKG91dCwgR05UU1RfZWFnYWluLCAicmVmIGEgJWxkIGJ1c3lc
biIsIChsb25nKXJlZl9hKTsK

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

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

--=separator--


From xen-devel-bounces@lists.xen.org Wed Sep 05 11:16:44 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Sep 2012 11:16:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9Day-0005Dr-9W; Wed, 05 Sep 2012 11:16:32 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <iwj@xenbits.xen.org>)
	id 1T9DYi-00053C-Vt; Wed, 05 Sep 2012 11:14:13 +0000
X-Env-Sender: iwj@xenbits.xen.org
X-Msg-Ref: server-5.tower-27.messagelabs.com!1346843573!6253309!1
X-Originating-IP: [50.57.168.107]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16021 invoked from network); 5 Sep 2012 11:12:55 -0000
Received: from mail.xen.org (HELO mail.xen.org) (50.57.168.107)
	by server-5.tower-27.messagelabs.com with AES256-SHA encrypted SMTP;
	5 Sep 2012 11:12:55 -0000
Received: from xenbits.xen.org ([50.57.170.242])
	by mail.xen.org with esmtp (Exim 4.72)
	(envelope-from <iwj@xenbits.xen.org>)
	id 1T9DXL-0001Cr-Dg; Wed, 05 Sep 2012 11:12:47 +0000
Received: from iwj by xenbits.xen.org with local (Exim 4.72)
	(envelope-from <iwj@xenbits.xen.org>)
	id 1T9DXL-0005Qu-97; Wed, 05 Sep 2012 11:12:47 +0000
Date: Wed, 05 Sep 2012 11:12:47 +0000
Message-Id: <E1T9DXL-0005Qu-97@xenbits.xen.org>
Content-Type: multipart/mixed; boundary="=separator"; charset="utf-8"
Content-Transfer-Encoding: binary
MIME-Version: 1.0
X-Mailer: MIME-tools 5.428 (Entity 5.428)
To: xen-announce@lists.xen.org, xen-devel@lists.xen.org,
	xen-users@lists.xen.org, oss-security@lists.openwall.com
From: Xen.org security team <security@xen.org>
X-Mailman-Approved-At: Wed, 05 Sep 2012 11:16:30 +0000
Cc: "Xen.org security team" <security@xen.org>
Subject: [Xen-devel] Xen Security Advisory 17 (CVE-2012-3515) - Qemu VT100
 emulation vulnerability
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--=separator
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

            Xen Security Advisory CVE-2012-3515 / XSA-17
                           version 2

               Qemu VT100 emulation vulnerability

UPDATES IN VERSION 2
====================

Public release.

ISSUE DESCRIPTION
=================

The device model used by fully virtualised (HVM) domains, qemu, does
not properly handle escape VT100 sequences when emulating certain
devices with a virtual console backend.

IMPACT
======

An attacker who has sufficient privilege to access a vulnerable device
within a guest can overwrite portions of the device model's address
space. This can allow them to escalate their privileges to that of the
device model process.

VULNERABLE SYSTEMS
==================

All Xen systems running HVM guests are potentially vulnerable to this
depending on the specific guest configuration. The default
configuration is vulnerable.

Guests using either the traditional "qemu-xen" or upstream qemu device
models are vulnerable.

MITIGATION
==========

This issue can be avoided by only running PV guests or by configuring
HVM guests to not use the virtual console('vc') backend for any device.

For serial devices specify in your guest configuration:
     serial = 'none'
in your guest configuration.

For parallel port devices the syntax is toolstack specific.
For xend specify in your guest configuration:
     parallel = 'none'
For xl specify in your guest configuration:
     xl: device_model_args = ['-parallel', 'none']

In both cases the default is to use the vulnerable 'vc' mode.

You can confirm whether or not you are vulnerable by pressing
Ctrl-Alt-<N> (for digit N) while connected to either the VNC or SDL
console. If you are able to switch to a window displaying "serial" or
"parallel" then you are vulnerable.

The issue can also be mitigated by enabling the stub domain device
model. In this case the attacked can only potentially gain control of
the stub domain and not of the entire system.

To enable stub domains specify in your guest configuration:
    device_model = "stubdom-dm"

RESOLUTION
==========

Applying the appropriate attached patch(es) will resolve the issue.

PATCH INFORMATION
=================

The attached patches resolve this issue

Traditional qemu tree
   Xen 4.0, 4.1 and unstable         xsa17-qemu-xen-traditional-all.patch

Upstream qemu tree (present in unstable only)
   Xen unstable                      xsa17-qemu-xen-unstable.patch

$ sha256sum xsa17-*.patch
60215322d3fbbc2054dfc160a20d9e0811af88487c4edc2f6ea81dcd5cedf039  xsa17-qemu-xen-traditional-all.patch
7b4bb59e7757080e7806a8b8eeb6b78fa0ffdfbfb28a7a379f7edff285bffd88  xsa17-qemu-xen-unstable.patch
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iQEcBAEBAgAGBQJQRx1PAAoJEIP+FMlX6CvZUqUH/jeAAvQnoBp6YKzm78XSnnmk
GI2C/LhH0xqR3wFoEmWeMsiO4lrGrASX6T31NTvHa8sOtFqlNpTfRhwQybwYR3aa
cz9/4y2a54hD95P1nVmPF0PddmSP47QSpRdCj0projq1UGxIdwEhkNeSoM8h7dXO
MegqZClsvJMKd8XEcjBF5Qg7u9vLrXilCx5+It7XNE31Jxpkr/fozBb7FnNtDGJj
s4RN/UDU4Pu68XyZ7Dc5xEFdJW48tz4BIlxxXavILBRFSE1VEf7Gc8H9CsUtBPWB
C/LCUjpHkAOmqdgFhiLnZ2u+2s79U0dtPDJMNmqaGgWH+AqGkU9Nq8XXODTyY9k=
=gnuE
-----END PGP SIGNATURE-----

--=separator
Content-Type: application/octet-stream;
 name="xsa17-qemu-xen-traditional-all.patch"
Content-Disposition: attachment;
 filename="xsa17-qemu-xen-traditional-all.patch"
Content-Transfer-Encoding: base64

Y29uc29sZTogYm91bmRzIGNoZWNrIHdoZW5ldmVyIGNoYW5naW5nIHRoZSBj
dXJzb3IgZHVlIHRvIGFuIGVzY2FwZSBjb2RlCgpUaGlzIGlzIFhTQS0xNyAv
IENWRS0yMDEyLTM1MTUKClNpZ25lZC1vZmYtYnk6IElhbiBDYW1wYmVsbCA8
aWFuLmNhbXBiZWxsQGNpdHJpeC5jb20+CgpkaWZmIC0tZ2l0IGEvY29uc29s
ZS5jIGIvY29uc29sZS5jCmluZGV4IDVlNmUzZDAuLjk5ODRkNmYgMTAwNjQ0
Ci0tLSBhL2NvbnNvbGUuYworKysgYi9jb25zb2xlLmMKQEAgLTc5NCw2ICs3
OTQsMjYgQEAgc3RhdGljIHZvaWQgY29uc29sZV9jbGVhcl94eShUZXh0Q29u
c29sZSAqcywgaW50IHgsIGludCB5KQogICAgIHVwZGF0ZV94eShzLCB4LCB5
KTsKIH0KIAorLyogc2V0IGN1cnNvciwgY2hlY2tpbmcgYm91bmRzICovCitz
dGF0aWMgdm9pZCBzZXRfY3Vyc29yKFRleHRDb25zb2xlICpzLCBpbnQgeCwg
aW50IHkpCit7CisgICAgaWYgKHggPCAwKSB7CisgICAgICAgIHggPSAwOwor
ICAgIH0KKyAgICBpZiAoeSA8IDApIHsKKyAgICAgICAgeSA9IDA7CisgICAg
fQorICAgIGlmICh5ID49IHMtPmhlaWdodCkgeworICAgICAgICB5ID0gcy0+
aGVpZ2h0IC0gMTsKKyAgICB9CisgICAgaWYgKHggPj0gcy0+d2lkdGgpIHsK
KyAgICAgICAgeCA9IHMtPndpZHRoIC0gMTsKKyAgICB9CisKKyAgICBzLT54
ID0geDsKKyAgICBzLT55ID0geTsKK30KKwogc3RhdGljIHZvaWQgY29uc29s
ZV9wdXRjaGFyKFRleHRDb25zb2xlICpzLCBpbnQgY2gpCiB7CiAgICAgVGV4
dENlbGwgKmM7CkBAIC04NjksNyArODg5LDggQEAgc3RhdGljIHZvaWQgY29u
c29sZV9wdXRjaGFyKFRleHRDb25zb2xlICpzLCBpbnQgY2gpCiAgICAgICAg
ICAgICAgICAgICAgIHMtPmVzY19wYXJhbXNbcy0+bmJfZXNjX3BhcmFtc10g
KiAxMCArIGNoIC0gJzAnOwogICAgICAgICAgICAgfQogICAgICAgICB9IGVs
c2UgewotICAgICAgICAgICAgcy0+bmJfZXNjX3BhcmFtcysrOworICAgICAg
ICAgICAgaWYgKHMtPm5iX2VzY19wYXJhbXMgPCBNQVhfRVNDX1BBUkFNUykK
KyAgICAgICAgICAgICAgICBzLT5uYl9lc2NfcGFyYW1zKys7CiAgICAgICAg
ICAgICBpZiAoY2ggPT0gJzsnKQogICAgICAgICAgICAgICAgIGJyZWFrOwog
I2lmZGVmIERFQlVHX0NPTlNPTEUKQEAgLTg4Myw1OSArOTA0LDM3IEBAIHN0
YXRpYyB2b2lkIGNvbnNvbGVfcHV0Y2hhcihUZXh0Q29uc29sZSAqcywgaW50
IGNoKQogICAgICAgICAgICAgICAgIGlmIChzLT5lc2NfcGFyYW1zWzBdID09
IDApIHsKICAgICAgICAgICAgICAgICAgICAgcy0+ZXNjX3BhcmFtc1swXSA9
IDE7CiAgICAgICAgICAgICAgICAgfQotICAgICAgICAgICAgICAgIHMtPnkg
LT0gcy0+ZXNjX3BhcmFtc1swXTsKLSAgICAgICAgICAgICAgICBpZiAocy0+
eSA8IDApIHsKLSAgICAgICAgICAgICAgICAgICAgcy0+eSA9IDA7Ci0gICAg
ICAgICAgICAgICAgfQorICAgICAgICAgICAgICAgIHNldF9jdXJzb3Iocywg
cy0+eCwgcy0+eSAtIHMtPmVzY19wYXJhbXNbMF0pOwogICAgICAgICAgICAg
ICAgIGJyZWFrOwogICAgICAgICAgICAgY2FzZSAnQic6CiAgICAgICAgICAg
ICAgICAgLyogbW92ZSBjdXJzb3IgZG93biAqLwogICAgICAgICAgICAgICAg
IGlmIChzLT5lc2NfcGFyYW1zWzBdID09IDApIHsKICAgICAgICAgICAgICAg
ICAgICAgcy0+ZXNjX3BhcmFtc1swXSA9IDE7CiAgICAgICAgICAgICAgICAg
fQotICAgICAgICAgICAgICAgIHMtPnkgKz0gcy0+ZXNjX3BhcmFtc1swXTsK
LSAgICAgICAgICAgICAgICBpZiAocy0+eSA+PSBzLT5oZWlnaHQpIHsKLSAg
ICAgICAgICAgICAgICAgICAgcy0+eSA9IHMtPmhlaWdodCAtIDE7Ci0gICAg
ICAgICAgICAgICAgfQorICAgICAgICAgICAgICAgIHNldF9jdXJzb3Iocywg
cy0+eCwgcy0+eSArIHMtPmVzY19wYXJhbXNbMF0pOwogICAgICAgICAgICAg
ICAgIGJyZWFrOwogICAgICAgICAgICAgY2FzZSAnQyc6CiAgICAgICAgICAg
ICAgICAgLyogbW92ZSBjdXJzb3IgcmlnaHQgKi8KICAgICAgICAgICAgICAg
ICBpZiAocy0+ZXNjX3BhcmFtc1swXSA9PSAwKSB7CiAgICAgICAgICAgICAg
ICAgICAgIHMtPmVzY19wYXJhbXNbMF0gPSAxOwogICAgICAgICAgICAgICAg
IH0KLSAgICAgICAgICAgICAgICBzLT54ICs9IHMtPmVzY19wYXJhbXNbMF07
Ci0gICAgICAgICAgICAgICAgaWYgKHMtPnggPj0gcy0+d2lkdGgpIHsKLSAg
ICAgICAgICAgICAgICAgICAgcy0+eCA9IHMtPndpZHRoIC0gMTsKLSAgICAg
ICAgICAgICAgICB9CisgICAgICAgICAgICAgICAgc2V0X2N1cnNvcihzLCBz
LT54ICsgcy0+ZXNjX3BhcmFtc1swXSwgcy0+eSk7CiAgICAgICAgICAgICAg
ICAgYnJlYWs7CiAgICAgICAgICAgICBjYXNlICdEJzoKICAgICAgICAgICAg
ICAgICAvKiBtb3ZlIGN1cnNvciBsZWZ0ICovCiAgICAgICAgICAgICAgICAg
aWYgKHMtPmVzY19wYXJhbXNbMF0gPT0gMCkgewogICAgICAgICAgICAgICAg
ICAgICBzLT5lc2NfcGFyYW1zWzBdID0gMTsKICAgICAgICAgICAgICAgICB9
Ci0gICAgICAgICAgICAgICAgcy0+eCAtPSBzLT5lc2NfcGFyYW1zWzBdOwot
ICAgICAgICAgICAgICAgIGlmIChzLT54IDwgMCkgewotICAgICAgICAgICAg
ICAgICAgICBzLT54ID0gMDsKLSAgICAgICAgICAgICAgICB9CisgICAgICAg
ICAgICAgICAgc2V0X2N1cnNvcihzLCBzLT54IC0gcy0+ZXNjX3BhcmFtc1sw
XSwgcy0+eSk7CiAgICAgICAgICAgICAgICAgYnJlYWs7CiAgICAgICAgICAg
ICBjYXNlICdHJzoKICAgICAgICAgICAgICAgICAvKiBtb3ZlIGN1cnNvciB0
byBjb2x1bW4gKi8KLSAgICAgICAgICAgICAgICBzLT54ID0gcy0+ZXNjX3Bh
cmFtc1swXSAtIDE7Ci0gICAgICAgICAgICAgICAgaWYgKHMtPnggPCAwKSB7
Ci0gICAgICAgICAgICAgICAgICAgIHMtPnggPSAwOwotICAgICAgICAgICAg
ICAgIH0KKyAgICAgICAgICAgICAgICBzZXRfY3Vyc29yKHMsIHMtPmVzY19w
YXJhbXNbMF0gLSAxLCBzLT55KTsKICAgICAgICAgICAgICAgICBicmVhazsK
ICAgICAgICAgICAgIGNhc2UgJ2YnOgogICAgICAgICAgICAgY2FzZSAnSCc6
CiAgICAgICAgICAgICAgICAgLyogbW92ZSBjdXJzb3IgdG8gcm93LCBjb2x1
bW4gKi8KLSAgICAgICAgICAgICAgICBzLT54ID0gcy0+ZXNjX3BhcmFtc1sx
XSAtIDE7Ci0gICAgICAgICAgICAgICAgaWYgKHMtPnggPCAwKSB7Ci0gICAg
ICAgICAgICAgICAgICAgIHMtPnggPSAwOwotICAgICAgICAgICAgICAgIH0K
LSAgICAgICAgICAgICAgICBzLT55ID0gcy0+ZXNjX3BhcmFtc1swXSAtIDE7
Ci0gICAgICAgICAgICAgICAgaWYgKHMtPnkgPCAwKSB7Ci0gICAgICAgICAg
ICAgICAgICAgIHMtPnkgPSAwOwotICAgICAgICAgICAgICAgIH0KKyAgICAg
ICAgICAgICAgICBzZXRfY3Vyc29yKHMsIHMtPmVzY19wYXJhbXNbMV0gLSAx
LCBzLT5lc2NfcGFyYW1zWzBdIC0gMSk7CiAgICAgICAgICAgICAgICAgYnJl
YWs7CiAgICAgICAgICAgICBjYXNlICdKJzoKICAgICAgICAgICAgICAgICBz
d2l0Y2ggKHMtPmVzY19wYXJhbXNbMF0pIHsK

--=separator
Content-Type: application/octet-stream; name="xsa17-qemu-xen-unstable.patch"
Content-Disposition: attachment; filename="xsa17-qemu-xen-unstable.patch"
Content-Transfer-Encoding: base64

Y29uc29sZTogYm91bmRzIGNoZWNrIHdoZW5ldmVyIGNoYW5naW5nIHRoZSBj
dXJzb3IgZHVlIHRvIGFuIGVzY2FwZSBjb2RlCgpUaGlzIGlzIFhTQS0xNyAv
IENWRS0yMDEyLTM1MTUKClNpZ25lZC1vZmYtYnk6IElhbiBDYW1wYmVsbCA8
aWFuLmNhbXBiZWxsQGNpdHJpeC5jb20+CgpkaWZmIC0tZ2l0IGEvY29uc29s
ZS5jIGIvY29uc29sZS5jCmluZGV4IGVkNmE2NTMuLmJmYWQzNjAgMTAwNjQ0
Ci0tLSBhL2NvbnNvbGUuYworKysgYi9jb25zb2xlLmMKQEAgLTg0MSw2ICs4
NDEsMjYgQEAgc3RhdGljIHZvaWQgY29uc29sZV9jbGVhcl94eShUZXh0Q29u
c29sZSAqcywgaW50IHgsIGludCB5KQogICAgIHVwZGF0ZV94eShzLCB4LCB5
KTsKIH0KIAorLyogc2V0IGN1cnNvciwgY2hlY2tpbmcgYm91bmRzICovCitz
dGF0aWMgdm9pZCBzZXRfY3Vyc29yKFRleHRDb25zb2xlICpzLCBpbnQgeCwg
aW50IHkpCit7CisgICAgaWYgKHggPCAwKSB7CisgICAgICAgIHggPSAwOwor
ICAgIH0KKyAgICBpZiAoeSA8IDApIHsKKyAgICAgICAgeSA9IDA7CisgICAg
fQorICAgIGlmICh5ID49IHMtPmhlaWdodCkgeworICAgICAgICB5ID0gcy0+
aGVpZ2h0IC0gMTsKKyAgICB9CisgICAgaWYgKHggPj0gcy0+d2lkdGgpIHsK
KyAgICAgICAgeCA9IHMtPndpZHRoIC0gMTsKKyAgICB9CisKKyAgICBzLT54
ID0geDsKKyAgICBzLT55ID0geTsKK30KKwogc3RhdGljIHZvaWQgY29uc29s
ZV9wdXRjaGFyKFRleHRDb25zb2xlICpzLCBpbnQgY2gpCiB7CiAgICAgVGV4
dENlbGwgKmM7CkBAIC05MTIsNyArOTMyLDggQEAgc3RhdGljIHZvaWQgY29u
c29sZV9wdXRjaGFyKFRleHRDb25zb2xlICpzLCBpbnQgY2gpCiAgICAgICAg
ICAgICAgICAgICAgIHMtPmVzY19wYXJhbXNbcy0+bmJfZXNjX3BhcmFtc10g
KiAxMCArIGNoIC0gJzAnOwogICAgICAgICAgICAgfQogICAgICAgICB9IGVs
c2UgewotICAgICAgICAgICAgcy0+bmJfZXNjX3BhcmFtcysrOworICAgICAg
ICAgICAgaWYgKHMtPm5iX2VzY19wYXJhbXMgPCBNQVhfRVNDX1BBUkFNUykK
KyAgICAgICAgICAgICAgICBzLT5uYl9lc2NfcGFyYW1zKys7CiAgICAgICAg
ICAgICBpZiAoY2ggPT0gJzsnKQogICAgICAgICAgICAgICAgIGJyZWFrOwog
I2lmZGVmIERFQlVHX0NPTlNPTEUKQEAgLTkyNiw1OSArOTQ3LDM3IEBAIHN0
YXRpYyB2b2lkIGNvbnNvbGVfcHV0Y2hhcihUZXh0Q29uc29sZSAqcywgaW50
IGNoKQogICAgICAgICAgICAgICAgIGlmIChzLT5lc2NfcGFyYW1zWzBdID09
IDApIHsKICAgICAgICAgICAgICAgICAgICAgcy0+ZXNjX3BhcmFtc1swXSA9
IDE7CiAgICAgICAgICAgICAgICAgfQotICAgICAgICAgICAgICAgIHMtPnkg
LT0gcy0+ZXNjX3BhcmFtc1swXTsKLSAgICAgICAgICAgICAgICBpZiAocy0+
eSA8IDApIHsKLSAgICAgICAgICAgICAgICAgICAgcy0+eSA9IDA7Ci0gICAg
ICAgICAgICAgICAgfQorICAgICAgICAgICAgICAgIHNldF9jdXJzb3Iocywg
cy0+eCwgcy0+eSAtIHMtPmVzY19wYXJhbXNbMF0pOwogICAgICAgICAgICAg
ICAgIGJyZWFrOwogICAgICAgICAgICAgY2FzZSAnQic6CiAgICAgICAgICAg
ICAgICAgLyogbW92ZSBjdXJzb3IgZG93biAqLwogICAgICAgICAgICAgICAg
IGlmIChzLT5lc2NfcGFyYW1zWzBdID09IDApIHsKICAgICAgICAgICAgICAg
ICAgICAgcy0+ZXNjX3BhcmFtc1swXSA9IDE7CiAgICAgICAgICAgICAgICAg
fQotICAgICAgICAgICAgICAgIHMtPnkgKz0gcy0+ZXNjX3BhcmFtc1swXTsK
LSAgICAgICAgICAgICAgICBpZiAocy0+eSA+PSBzLT5oZWlnaHQpIHsKLSAg
ICAgICAgICAgICAgICAgICAgcy0+eSA9IHMtPmhlaWdodCAtIDE7Ci0gICAg
ICAgICAgICAgICAgfQorICAgICAgICAgICAgICAgIHNldF9jdXJzb3Iocywg
cy0+eCwgcy0+eSArIHMtPmVzY19wYXJhbXNbMF0pOwogICAgICAgICAgICAg
ICAgIGJyZWFrOwogICAgICAgICAgICAgY2FzZSAnQyc6CiAgICAgICAgICAg
ICAgICAgLyogbW92ZSBjdXJzb3IgcmlnaHQgKi8KICAgICAgICAgICAgICAg
ICBpZiAocy0+ZXNjX3BhcmFtc1swXSA9PSAwKSB7CiAgICAgICAgICAgICAg
ICAgICAgIHMtPmVzY19wYXJhbXNbMF0gPSAxOwogICAgICAgICAgICAgICAg
IH0KLSAgICAgICAgICAgICAgICBzLT54ICs9IHMtPmVzY19wYXJhbXNbMF07
Ci0gICAgICAgICAgICAgICAgaWYgKHMtPnggPj0gcy0+d2lkdGgpIHsKLSAg
ICAgICAgICAgICAgICAgICAgcy0+eCA9IHMtPndpZHRoIC0gMTsKLSAgICAg
ICAgICAgICAgICB9CisgICAgICAgICAgICAgICAgc2V0X2N1cnNvcihzLCBz
LT54ICsgcy0+ZXNjX3BhcmFtc1swXSwgcy0+eSk7CiAgICAgICAgICAgICAg
ICAgYnJlYWs7CiAgICAgICAgICAgICBjYXNlICdEJzoKICAgICAgICAgICAg
ICAgICAvKiBtb3ZlIGN1cnNvciBsZWZ0ICovCiAgICAgICAgICAgICAgICAg
aWYgKHMtPmVzY19wYXJhbXNbMF0gPT0gMCkgewogICAgICAgICAgICAgICAg
ICAgICBzLT5lc2NfcGFyYW1zWzBdID0gMTsKICAgICAgICAgICAgICAgICB9
Ci0gICAgICAgICAgICAgICAgcy0+eCAtPSBzLT5lc2NfcGFyYW1zWzBdOwot
ICAgICAgICAgICAgICAgIGlmIChzLT54IDwgMCkgewotICAgICAgICAgICAg
ICAgICAgICBzLT54ID0gMDsKLSAgICAgICAgICAgICAgICB9CisgICAgICAg
ICAgICAgICAgc2V0X2N1cnNvcihzLCBzLT54IC0gcy0+ZXNjX3BhcmFtc1sw
XSwgcy0+eSk7CiAgICAgICAgICAgICAgICAgYnJlYWs7CiAgICAgICAgICAg
ICBjYXNlICdHJzoKICAgICAgICAgICAgICAgICAvKiBtb3ZlIGN1cnNvciB0
byBjb2x1bW4gKi8KLSAgICAgICAgICAgICAgICBzLT54ID0gcy0+ZXNjX3Bh
cmFtc1swXSAtIDE7Ci0gICAgICAgICAgICAgICAgaWYgKHMtPnggPCAwKSB7
Ci0gICAgICAgICAgICAgICAgICAgIHMtPnggPSAwOwotICAgICAgICAgICAg
ICAgIH0KKyAgICAgICAgICAgICAgICBzZXRfY3Vyc29yKHMsIHMtPmVzY19w
YXJhbXNbMF0gLSAxLCBzLT55KTsKICAgICAgICAgICAgICAgICBicmVhazsK
ICAgICAgICAgICAgIGNhc2UgJ2YnOgogICAgICAgICAgICAgY2FzZSAnSCc6
CiAgICAgICAgICAgICAgICAgLyogbW92ZSBjdXJzb3IgdG8gcm93LCBjb2x1
bW4gKi8KLSAgICAgICAgICAgICAgICBzLT54ID0gcy0+ZXNjX3BhcmFtc1sx
XSAtIDE7Ci0gICAgICAgICAgICAgICAgaWYgKHMtPnggPCAwKSB7Ci0gICAg
ICAgICAgICAgICAgICAgIHMtPnggPSAwOwotICAgICAgICAgICAgICAgIH0K
LSAgICAgICAgICAgICAgICBzLT55ID0gcy0+ZXNjX3BhcmFtc1swXSAtIDE7
Ci0gICAgICAgICAgICAgICAgaWYgKHMtPnkgPCAwKSB7Ci0gICAgICAgICAg
ICAgICAgICAgIHMtPnkgPSAwOwotICAgICAgICAgICAgICAgIH0KKyAgICAg
ICAgICAgICAgICBzZXRfY3Vyc29yKHMsIHMtPmVzY19wYXJhbXNbMV0gLSAx
LCBzLT5lc2NfcGFyYW1zWzBdIC0gMSk7CiAgICAgICAgICAgICAgICAgYnJl
YWs7CiAgICAgICAgICAgICBjYXNlICdKJzoKICAgICAgICAgICAgICAgICBz
d2l0Y2ggKHMtPmVzY19wYXJhbXNbMF0pIHsK

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

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

--=separator--


From xen-devel-bounces@lists.xen.org Wed Sep 05 11:16:44 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Sep 2012 11:16:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9Day-0005Dr-9W; Wed, 05 Sep 2012 11:16:32 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <iwj@xenbits.xen.org>)
	id 1T9DYi-00053C-Vt; Wed, 05 Sep 2012 11:14:13 +0000
X-Env-Sender: iwj@xenbits.xen.org
X-Msg-Ref: server-5.tower-27.messagelabs.com!1346843573!6253309!1
X-Originating-IP: [50.57.168.107]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16021 invoked from network); 5 Sep 2012 11:12:55 -0000
Received: from mail.xen.org (HELO mail.xen.org) (50.57.168.107)
	by server-5.tower-27.messagelabs.com with AES256-SHA encrypted SMTP;
	5 Sep 2012 11:12:55 -0000
Received: from xenbits.xen.org ([50.57.170.242])
	by mail.xen.org with esmtp (Exim 4.72)
	(envelope-from <iwj@xenbits.xen.org>)
	id 1T9DXL-0001Cr-Dg; Wed, 05 Sep 2012 11:12:47 +0000
Received: from iwj by xenbits.xen.org with local (Exim 4.72)
	(envelope-from <iwj@xenbits.xen.org>)
	id 1T9DXL-0005Qu-97; Wed, 05 Sep 2012 11:12:47 +0000
Date: Wed, 05 Sep 2012 11:12:47 +0000
Message-Id: <E1T9DXL-0005Qu-97@xenbits.xen.org>
Content-Type: multipart/mixed; boundary="=separator"; charset="utf-8"
Content-Transfer-Encoding: binary
MIME-Version: 1.0
X-Mailer: MIME-tools 5.428 (Entity 5.428)
To: xen-announce@lists.xen.org, xen-devel@lists.xen.org,
	xen-users@lists.xen.org, oss-security@lists.openwall.com
From: Xen.org security team <security@xen.org>
X-Mailman-Approved-At: Wed, 05 Sep 2012 11:16:30 +0000
Cc: "Xen.org security team" <security@xen.org>
Subject: [Xen-devel] Xen Security Advisory 17 (CVE-2012-3515) - Qemu VT100
 emulation vulnerability
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--=separator
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

            Xen Security Advisory CVE-2012-3515 / XSA-17
                           version 2

               Qemu VT100 emulation vulnerability

UPDATES IN VERSION 2
====================

Public release.

ISSUE DESCRIPTION
=================

The device model used by fully virtualised (HVM) domains, qemu, does
not properly handle escape VT100 sequences when emulating certain
devices with a virtual console backend.

IMPACT
======

An attacker who has sufficient privilege to access a vulnerable device
within a guest can overwrite portions of the device model's address
space. This can allow them to escalate their privileges to that of the
device model process.

VULNERABLE SYSTEMS
==================

All Xen systems running HVM guests are potentially vulnerable to this
depending on the specific guest configuration. The default
configuration is vulnerable.

Guests using either the traditional "qemu-xen" or upstream qemu device
models are vulnerable.

MITIGATION
==========

This issue can be avoided by only running PV guests or by configuring
HVM guests to not use the virtual console('vc') backend for any device.

For serial devices specify in your guest configuration:
     serial = 'none'
in your guest configuration.

For parallel port devices the syntax is toolstack specific.
For xend specify in your guest configuration:
     parallel = 'none'
For xl specify in your guest configuration:
     xl: device_model_args = ['-parallel', 'none']

In both cases the default is to use the vulnerable 'vc' mode.

You can confirm whether or not you are vulnerable by pressing
Ctrl-Alt-<N> (for digit N) while connected to either the VNC or SDL
console. If you are able to switch to a window displaying "serial" or
"parallel" then you are vulnerable.

The issue can also be mitigated by enabling the stub domain device
model. In this case the attacked can only potentially gain control of
the stub domain and not of the entire system.

To enable stub domains specify in your guest configuration:
    device_model = "stubdom-dm"

RESOLUTION
==========

Applying the appropriate attached patch(es) will resolve the issue.

PATCH INFORMATION
=================

The attached patches resolve this issue

Traditional qemu tree
   Xen 4.0, 4.1 and unstable         xsa17-qemu-xen-traditional-all.patch

Upstream qemu tree (present in unstable only)
   Xen unstable                      xsa17-qemu-xen-unstable.patch

$ sha256sum xsa17-*.patch
60215322d3fbbc2054dfc160a20d9e0811af88487c4edc2f6ea81dcd5cedf039  xsa17-qemu-xen-traditional-all.patch
7b4bb59e7757080e7806a8b8eeb6b78fa0ffdfbfb28a7a379f7edff285bffd88  xsa17-qemu-xen-unstable.patch
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iQEcBAEBAgAGBQJQRx1PAAoJEIP+FMlX6CvZUqUH/jeAAvQnoBp6YKzm78XSnnmk
GI2C/LhH0xqR3wFoEmWeMsiO4lrGrASX6T31NTvHa8sOtFqlNpTfRhwQybwYR3aa
cz9/4y2a54hD95P1nVmPF0PddmSP47QSpRdCj0projq1UGxIdwEhkNeSoM8h7dXO
MegqZClsvJMKd8XEcjBF5Qg7u9vLrXilCx5+It7XNE31Jxpkr/fozBb7FnNtDGJj
s4RN/UDU4Pu68XyZ7Dc5xEFdJW48tz4BIlxxXavILBRFSE1VEf7Gc8H9CsUtBPWB
C/LCUjpHkAOmqdgFhiLnZ2u+2s79U0dtPDJMNmqaGgWH+AqGkU9Nq8XXODTyY9k=
=gnuE
-----END PGP SIGNATURE-----

--=separator
Content-Type: application/octet-stream;
 name="xsa17-qemu-xen-traditional-all.patch"
Content-Disposition: attachment;
 filename="xsa17-qemu-xen-traditional-all.patch"
Content-Transfer-Encoding: base64

Y29uc29sZTogYm91bmRzIGNoZWNrIHdoZW5ldmVyIGNoYW5naW5nIHRoZSBj
dXJzb3IgZHVlIHRvIGFuIGVzY2FwZSBjb2RlCgpUaGlzIGlzIFhTQS0xNyAv
IENWRS0yMDEyLTM1MTUKClNpZ25lZC1vZmYtYnk6IElhbiBDYW1wYmVsbCA8
aWFuLmNhbXBiZWxsQGNpdHJpeC5jb20+CgpkaWZmIC0tZ2l0IGEvY29uc29s
ZS5jIGIvY29uc29sZS5jCmluZGV4IDVlNmUzZDAuLjk5ODRkNmYgMTAwNjQ0
Ci0tLSBhL2NvbnNvbGUuYworKysgYi9jb25zb2xlLmMKQEAgLTc5NCw2ICs3
OTQsMjYgQEAgc3RhdGljIHZvaWQgY29uc29sZV9jbGVhcl94eShUZXh0Q29u
c29sZSAqcywgaW50IHgsIGludCB5KQogICAgIHVwZGF0ZV94eShzLCB4LCB5
KTsKIH0KIAorLyogc2V0IGN1cnNvciwgY2hlY2tpbmcgYm91bmRzICovCitz
dGF0aWMgdm9pZCBzZXRfY3Vyc29yKFRleHRDb25zb2xlICpzLCBpbnQgeCwg
aW50IHkpCit7CisgICAgaWYgKHggPCAwKSB7CisgICAgICAgIHggPSAwOwor
ICAgIH0KKyAgICBpZiAoeSA8IDApIHsKKyAgICAgICAgeSA9IDA7CisgICAg
fQorICAgIGlmICh5ID49IHMtPmhlaWdodCkgeworICAgICAgICB5ID0gcy0+
aGVpZ2h0IC0gMTsKKyAgICB9CisgICAgaWYgKHggPj0gcy0+d2lkdGgpIHsK
KyAgICAgICAgeCA9IHMtPndpZHRoIC0gMTsKKyAgICB9CisKKyAgICBzLT54
ID0geDsKKyAgICBzLT55ID0geTsKK30KKwogc3RhdGljIHZvaWQgY29uc29s
ZV9wdXRjaGFyKFRleHRDb25zb2xlICpzLCBpbnQgY2gpCiB7CiAgICAgVGV4
dENlbGwgKmM7CkBAIC04NjksNyArODg5LDggQEAgc3RhdGljIHZvaWQgY29u
c29sZV9wdXRjaGFyKFRleHRDb25zb2xlICpzLCBpbnQgY2gpCiAgICAgICAg
ICAgICAgICAgICAgIHMtPmVzY19wYXJhbXNbcy0+bmJfZXNjX3BhcmFtc10g
KiAxMCArIGNoIC0gJzAnOwogICAgICAgICAgICAgfQogICAgICAgICB9IGVs
c2UgewotICAgICAgICAgICAgcy0+bmJfZXNjX3BhcmFtcysrOworICAgICAg
ICAgICAgaWYgKHMtPm5iX2VzY19wYXJhbXMgPCBNQVhfRVNDX1BBUkFNUykK
KyAgICAgICAgICAgICAgICBzLT5uYl9lc2NfcGFyYW1zKys7CiAgICAgICAg
ICAgICBpZiAoY2ggPT0gJzsnKQogICAgICAgICAgICAgICAgIGJyZWFrOwog
I2lmZGVmIERFQlVHX0NPTlNPTEUKQEAgLTg4Myw1OSArOTA0LDM3IEBAIHN0
YXRpYyB2b2lkIGNvbnNvbGVfcHV0Y2hhcihUZXh0Q29uc29sZSAqcywgaW50
IGNoKQogICAgICAgICAgICAgICAgIGlmIChzLT5lc2NfcGFyYW1zWzBdID09
IDApIHsKICAgICAgICAgICAgICAgICAgICAgcy0+ZXNjX3BhcmFtc1swXSA9
IDE7CiAgICAgICAgICAgICAgICAgfQotICAgICAgICAgICAgICAgIHMtPnkg
LT0gcy0+ZXNjX3BhcmFtc1swXTsKLSAgICAgICAgICAgICAgICBpZiAocy0+
eSA8IDApIHsKLSAgICAgICAgICAgICAgICAgICAgcy0+eSA9IDA7Ci0gICAg
ICAgICAgICAgICAgfQorICAgICAgICAgICAgICAgIHNldF9jdXJzb3Iocywg
cy0+eCwgcy0+eSAtIHMtPmVzY19wYXJhbXNbMF0pOwogICAgICAgICAgICAg
ICAgIGJyZWFrOwogICAgICAgICAgICAgY2FzZSAnQic6CiAgICAgICAgICAg
ICAgICAgLyogbW92ZSBjdXJzb3IgZG93biAqLwogICAgICAgICAgICAgICAg
IGlmIChzLT5lc2NfcGFyYW1zWzBdID09IDApIHsKICAgICAgICAgICAgICAg
ICAgICAgcy0+ZXNjX3BhcmFtc1swXSA9IDE7CiAgICAgICAgICAgICAgICAg
fQotICAgICAgICAgICAgICAgIHMtPnkgKz0gcy0+ZXNjX3BhcmFtc1swXTsK
LSAgICAgICAgICAgICAgICBpZiAocy0+eSA+PSBzLT5oZWlnaHQpIHsKLSAg
ICAgICAgICAgICAgICAgICAgcy0+eSA9IHMtPmhlaWdodCAtIDE7Ci0gICAg
ICAgICAgICAgICAgfQorICAgICAgICAgICAgICAgIHNldF9jdXJzb3Iocywg
cy0+eCwgcy0+eSArIHMtPmVzY19wYXJhbXNbMF0pOwogICAgICAgICAgICAg
ICAgIGJyZWFrOwogICAgICAgICAgICAgY2FzZSAnQyc6CiAgICAgICAgICAg
ICAgICAgLyogbW92ZSBjdXJzb3IgcmlnaHQgKi8KICAgICAgICAgICAgICAg
ICBpZiAocy0+ZXNjX3BhcmFtc1swXSA9PSAwKSB7CiAgICAgICAgICAgICAg
ICAgICAgIHMtPmVzY19wYXJhbXNbMF0gPSAxOwogICAgICAgICAgICAgICAg
IH0KLSAgICAgICAgICAgICAgICBzLT54ICs9IHMtPmVzY19wYXJhbXNbMF07
Ci0gICAgICAgICAgICAgICAgaWYgKHMtPnggPj0gcy0+d2lkdGgpIHsKLSAg
ICAgICAgICAgICAgICAgICAgcy0+eCA9IHMtPndpZHRoIC0gMTsKLSAgICAg
ICAgICAgICAgICB9CisgICAgICAgICAgICAgICAgc2V0X2N1cnNvcihzLCBz
LT54ICsgcy0+ZXNjX3BhcmFtc1swXSwgcy0+eSk7CiAgICAgICAgICAgICAg
ICAgYnJlYWs7CiAgICAgICAgICAgICBjYXNlICdEJzoKICAgICAgICAgICAg
ICAgICAvKiBtb3ZlIGN1cnNvciBsZWZ0ICovCiAgICAgICAgICAgICAgICAg
aWYgKHMtPmVzY19wYXJhbXNbMF0gPT0gMCkgewogICAgICAgICAgICAgICAg
ICAgICBzLT5lc2NfcGFyYW1zWzBdID0gMTsKICAgICAgICAgICAgICAgICB9
Ci0gICAgICAgICAgICAgICAgcy0+eCAtPSBzLT5lc2NfcGFyYW1zWzBdOwot
ICAgICAgICAgICAgICAgIGlmIChzLT54IDwgMCkgewotICAgICAgICAgICAg
ICAgICAgICBzLT54ID0gMDsKLSAgICAgICAgICAgICAgICB9CisgICAgICAg
ICAgICAgICAgc2V0X2N1cnNvcihzLCBzLT54IC0gcy0+ZXNjX3BhcmFtc1sw
XSwgcy0+eSk7CiAgICAgICAgICAgICAgICAgYnJlYWs7CiAgICAgICAgICAg
ICBjYXNlICdHJzoKICAgICAgICAgICAgICAgICAvKiBtb3ZlIGN1cnNvciB0
byBjb2x1bW4gKi8KLSAgICAgICAgICAgICAgICBzLT54ID0gcy0+ZXNjX3Bh
cmFtc1swXSAtIDE7Ci0gICAgICAgICAgICAgICAgaWYgKHMtPnggPCAwKSB7
Ci0gICAgICAgICAgICAgICAgICAgIHMtPnggPSAwOwotICAgICAgICAgICAg
ICAgIH0KKyAgICAgICAgICAgICAgICBzZXRfY3Vyc29yKHMsIHMtPmVzY19w
YXJhbXNbMF0gLSAxLCBzLT55KTsKICAgICAgICAgICAgICAgICBicmVhazsK
ICAgICAgICAgICAgIGNhc2UgJ2YnOgogICAgICAgICAgICAgY2FzZSAnSCc6
CiAgICAgICAgICAgICAgICAgLyogbW92ZSBjdXJzb3IgdG8gcm93LCBjb2x1
bW4gKi8KLSAgICAgICAgICAgICAgICBzLT54ID0gcy0+ZXNjX3BhcmFtc1sx
XSAtIDE7Ci0gICAgICAgICAgICAgICAgaWYgKHMtPnggPCAwKSB7Ci0gICAg
ICAgICAgICAgICAgICAgIHMtPnggPSAwOwotICAgICAgICAgICAgICAgIH0K
LSAgICAgICAgICAgICAgICBzLT55ID0gcy0+ZXNjX3BhcmFtc1swXSAtIDE7
Ci0gICAgICAgICAgICAgICAgaWYgKHMtPnkgPCAwKSB7Ci0gICAgICAgICAg
ICAgICAgICAgIHMtPnkgPSAwOwotICAgICAgICAgICAgICAgIH0KKyAgICAg
ICAgICAgICAgICBzZXRfY3Vyc29yKHMsIHMtPmVzY19wYXJhbXNbMV0gLSAx
LCBzLT5lc2NfcGFyYW1zWzBdIC0gMSk7CiAgICAgICAgICAgICAgICAgYnJl
YWs7CiAgICAgICAgICAgICBjYXNlICdKJzoKICAgICAgICAgICAgICAgICBz
d2l0Y2ggKHMtPmVzY19wYXJhbXNbMF0pIHsK

--=separator
Content-Type: application/octet-stream; name="xsa17-qemu-xen-unstable.patch"
Content-Disposition: attachment; filename="xsa17-qemu-xen-unstable.patch"
Content-Transfer-Encoding: base64

Y29uc29sZTogYm91bmRzIGNoZWNrIHdoZW5ldmVyIGNoYW5naW5nIHRoZSBj
dXJzb3IgZHVlIHRvIGFuIGVzY2FwZSBjb2RlCgpUaGlzIGlzIFhTQS0xNyAv
IENWRS0yMDEyLTM1MTUKClNpZ25lZC1vZmYtYnk6IElhbiBDYW1wYmVsbCA8
aWFuLmNhbXBiZWxsQGNpdHJpeC5jb20+CgpkaWZmIC0tZ2l0IGEvY29uc29s
ZS5jIGIvY29uc29sZS5jCmluZGV4IGVkNmE2NTMuLmJmYWQzNjAgMTAwNjQ0
Ci0tLSBhL2NvbnNvbGUuYworKysgYi9jb25zb2xlLmMKQEAgLTg0MSw2ICs4
NDEsMjYgQEAgc3RhdGljIHZvaWQgY29uc29sZV9jbGVhcl94eShUZXh0Q29u
c29sZSAqcywgaW50IHgsIGludCB5KQogICAgIHVwZGF0ZV94eShzLCB4LCB5
KTsKIH0KIAorLyogc2V0IGN1cnNvciwgY2hlY2tpbmcgYm91bmRzICovCitz
dGF0aWMgdm9pZCBzZXRfY3Vyc29yKFRleHRDb25zb2xlICpzLCBpbnQgeCwg
aW50IHkpCit7CisgICAgaWYgKHggPCAwKSB7CisgICAgICAgIHggPSAwOwor
ICAgIH0KKyAgICBpZiAoeSA8IDApIHsKKyAgICAgICAgeSA9IDA7CisgICAg
fQorICAgIGlmICh5ID49IHMtPmhlaWdodCkgeworICAgICAgICB5ID0gcy0+
aGVpZ2h0IC0gMTsKKyAgICB9CisgICAgaWYgKHggPj0gcy0+d2lkdGgpIHsK
KyAgICAgICAgeCA9IHMtPndpZHRoIC0gMTsKKyAgICB9CisKKyAgICBzLT54
ID0geDsKKyAgICBzLT55ID0geTsKK30KKwogc3RhdGljIHZvaWQgY29uc29s
ZV9wdXRjaGFyKFRleHRDb25zb2xlICpzLCBpbnQgY2gpCiB7CiAgICAgVGV4
dENlbGwgKmM7CkBAIC05MTIsNyArOTMyLDggQEAgc3RhdGljIHZvaWQgY29u
c29sZV9wdXRjaGFyKFRleHRDb25zb2xlICpzLCBpbnQgY2gpCiAgICAgICAg
ICAgICAgICAgICAgIHMtPmVzY19wYXJhbXNbcy0+bmJfZXNjX3BhcmFtc10g
KiAxMCArIGNoIC0gJzAnOwogICAgICAgICAgICAgfQogICAgICAgICB9IGVs
c2UgewotICAgICAgICAgICAgcy0+bmJfZXNjX3BhcmFtcysrOworICAgICAg
ICAgICAgaWYgKHMtPm5iX2VzY19wYXJhbXMgPCBNQVhfRVNDX1BBUkFNUykK
KyAgICAgICAgICAgICAgICBzLT5uYl9lc2NfcGFyYW1zKys7CiAgICAgICAg
ICAgICBpZiAoY2ggPT0gJzsnKQogICAgICAgICAgICAgICAgIGJyZWFrOwog
I2lmZGVmIERFQlVHX0NPTlNPTEUKQEAgLTkyNiw1OSArOTQ3LDM3IEBAIHN0
YXRpYyB2b2lkIGNvbnNvbGVfcHV0Y2hhcihUZXh0Q29uc29sZSAqcywgaW50
IGNoKQogICAgICAgICAgICAgICAgIGlmIChzLT5lc2NfcGFyYW1zWzBdID09
IDApIHsKICAgICAgICAgICAgICAgICAgICAgcy0+ZXNjX3BhcmFtc1swXSA9
IDE7CiAgICAgICAgICAgICAgICAgfQotICAgICAgICAgICAgICAgIHMtPnkg
LT0gcy0+ZXNjX3BhcmFtc1swXTsKLSAgICAgICAgICAgICAgICBpZiAocy0+
eSA8IDApIHsKLSAgICAgICAgICAgICAgICAgICAgcy0+eSA9IDA7Ci0gICAg
ICAgICAgICAgICAgfQorICAgICAgICAgICAgICAgIHNldF9jdXJzb3Iocywg
cy0+eCwgcy0+eSAtIHMtPmVzY19wYXJhbXNbMF0pOwogICAgICAgICAgICAg
ICAgIGJyZWFrOwogICAgICAgICAgICAgY2FzZSAnQic6CiAgICAgICAgICAg
ICAgICAgLyogbW92ZSBjdXJzb3IgZG93biAqLwogICAgICAgICAgICAgICAg
IGlmIChzLT5lc2NfcGFyYW1zWzBdID09IDApIHsKICAgICAgICAgICAgICAg
ICAgICAgcy0+ZXNjX3BhcmFtc1swXSA9IDE7CiAgICAgICAgICAgICAgICAg
fQotICAgICAgICAgICAgICAgIHMtPnkgKz0gcy0+ZXNjX3BhcmFtc1swXTsK
LSAgICAgICAgICAgICAgICBpZiAocy0+eSA+PSBzLT5oZWlnaHQpIHsKLSAg
ICAgICAgICAgICAgICAgICAgcy0+eSA9IHMtPmhlaWdodCAtIDE7Ci0gICAg
ICAgICAgICAgICAgfQorICAgICAgICAgICAgICAgIHNldF9jdXJzb3Iocywg
cy0+eCwgcy0+eSArIHMtPmVzY19wYXJhbXNbMF0pOwogICAgICAgICAgICAg
ICAgIGJyZWFrOwogICAgICAgICAgICAgY2FzZSAnQyc6CiAgICAgICAgICAg
ICAgICAgLyogbW92ZSBjdXJzb3IgcmlnaHQgKi8KICAgICAgICAgICAgICAg
ICBpZiAocy0+ZXNjX3BhcmFtc1swXSA9PSAwKSB7CiAgICAgICAgICAgICAg
ICAgICAgIHMtPmVzY19wYXJhbXNbMF0gPSAxOwogICAgICAgICAgICAgICAg
IH0KLSAgICAgICAgICAgICAgICBzLT54ICs9IHMtPmVzY19wYXJhbXNbMF07
Ci0gICAgICAgICAgICAgICAgaWYgKHMtPnggPj0gcy0+d2lkdGgpIHsKLSAg
ICAgICAgICAgICAgICAgICAgcy0+eCA9IHMtPndpZHRoIC0gMTsKLSAgICAg
ICAgICAgICAgICB9CisgICAgICAgICAgICAgICAgc2V0X2N1cnNvcihzLCBz
LT54ICsgcy0+ZXNjX3BhcmFtc1swXSwgcy0+eSk7CiAgICAgICAgICAgICAg
ICAgYnJlYWs7CiAgICAgICAgICAgICBjYXNlICdEJzoKICAgICAgICAgICAg
ICAgICAvKiBtb3ZlIGN1cnNvciBsZWZ0ICovCiAgICAgICAgICAgICAgICAg
aWYgKHMtPmVzY19wYXJhbXNbMF0gPT0gMCkgewogICAgICAgICAgICAgICAg
ICAgICBzLT5lc2NfcGFyYW1zWzBdID0gMTsKICAgICAgICAgICAgICAgICB9
Ci0gICAgICAgICAgICAgICAgcy0+eCAtPSBzLT5lc2NfcGFyYW1zWzBdOwot
ICAgICAgICAgICAgICAgIGlmIChzLT54IDwgMCkgewotICAgICAgICAgICAg
ICAgICAgICBzLT54ID0gMDsKLSAgICAgICAgICAgICAgICB9CisgICAgICAg
ICAgICAgICAgc2V0X2N1cnNvcihzLCBzLT54IC0gcy0+ZXNjX3BhcmFtc1sw
XSwgcy0+eSk7CiAgICAgICAgICAgICAgICAgYnJlYWs7CiAgICAgICAgICAg
ICBjYXNlICdHJzoKICAgICAgICAgICAgICAgICAvKiBtb3ZlIGN1cnNvciB0
byBjb2x1bW4gKi8KLSAgICAgICAgICAgICAgICBzLT54ID0gcy0+ZXNjX3Bh
cmFtc1swXSAtIDE7Ci0gICAgICAgICAgICAgICAgaWYgKHMtPnggPCAwKSB7
Ci0gICAgICAgICAgICAgICAgICAgIHMtPnggPSAwOwotICAgICAgICAgICAg
ICAgIH0KKyAgICAgICAgICAgICAgICBzZXRfY3Vyc29yKHMsIHMtPmVzY19w
YXJhbXNbMF0gLSAxLCBzLT55KTsKICAgICAgICAgICAgICAgICBicmVhazsK
ICAgICAgICAgICAgIGNhc2UgJ2YnOgogICAgICAgICAgICAgY2FzZSAnSCc6
CiAgICAgICAgICAgICAgICAgLyogbW92ZSBjdXJzb3IgdG8gcm93LCBjb2x1
bW4gKi8KLSAgICAgICAgICAgICAgICBzLT54ID0gcy0+ZXNjX3BhcmFtc1sx
XSAtIDE7Ci0gICAgICAgICAgICAgICAgaWYgKHMtPnggPCAwKSB7Ci0gICAg
ICAgICAgICAgICAgICAgIHMtPnggPSAwOwotICAgICAgICAgICAgICAgIH0K
LSAgICAgICAgICAgICAgICBzLT55ID0gcy0+ZXNjX3BhcmFtc1swXSAtIDE7
Ci0gICAgICAgICAgICAgICAgaWYgKHMtPnkgPCAwKSB7Ci0gICAgICAgICAg
ICAgICAgICAgIHMtPnkgPSAwOwotICAgICAgICAgICAgICAgIH0KKyAgICAg
ICAgICAgICAgICBzZXRfY3Vyc29yKHMsIHMtPmVzY19wYXJhbXNbMV0gLSAx
LCBzLT5lc2NfcGFyYW1zWzBdIC0gMSk7CiAgICAgICAgICAgICAgICAgYnJl
YWs7CiAgICAgICAgICAgICBjYXNlICdKJzoKICAgICAgICAgICAgICAgICBz
d2l0Y2ggKHMtPmVzY19wYXJhbXNbMF0pIHsK

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

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

--=separator--


From xen-devel-bounces@lists.xen.org Wed Sep 05 11:33:02 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Sep 2012 11: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 1T9Dqj-0000xI-Qi; Wed, 05 Sep 2012 11:32: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 1T9Dqi-0000xA-Qk
	for xen-devel@lists.xen.org; Wed, 05 Sep 2012 11:32:49 +0000
Received: from [85.158.138.51:49108] by server-8.bemta-3.messagelabs.com id
	47/30-24700-F5837405; Wed, 05 Sep 2012 11:32:47 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1346844764!28758449!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQwMzE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28366 invoked from network); 5 Sep 2012 11:32:44 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-11.tower-174.messagelabs.com with SMTP;
	5 Sep 2012 11:32:44 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 05 Sep 2012 12:32:44 +0100
Message-Id: <504754B10200007800098D08@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 05 Sep 2012 12:33:37 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Dan Magenheimer" <dan.magenheimer@oracle.com>
References: <f24f5494-5b64-4872-a830-c44859461a9d@default>
In-Reply-To: <f24f5494-5b64-4872-a830-c44859461a9d@default>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Kurt Hackel <kurt.hackel@oracle.com>, Konrad Wilk <konrad.wilk@oracle.com>,
	keir@xen.org, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] tmem: fixup 2010 cleanup patch that breaks
 tmem save/restore
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.09.12 at 23:25, Dan Magenheimer <dan.magenheimer@oracle.com> wrote:
> 20918:a3fa6d444b25 "Fix domain reference leaks" (in Feb 2010, by Jan)
> does some cleanup in addition to the leak fixes.  Unfortunately, that
> cleanup inadvertently resulted in an incorrect fallthrough in a switch
> statement which breaks tmem save/restore.

Oh, I'm sorry for that. We had spotted these missing breaks in
the course of the XSA-15 investigations too, so I'm having a
similar patch pending (deferred its posting until after the
publishing of that advisory). I'd prefer the security ones to go in
first, and this one (or mine, which has some more cleanup in it)
on top. If it's going to be yours, then it would need re-basing, as
the security patches will break the context of the first hunk.

> That broken patch was apparently applied to 4.0-testing and 4.1-testing
> so those are broken as well.

The patch actually went in before 4.0.0-rc3, i.e. before
4.0-testing got branched off.

> What is the process now for requesting back-patches to 4.0 and 4.1?

Unless someone steps up to maintain the 4.0 tree, it'll be
considered dead with the release of 4.2.

For 4.1, I'll be making sure to apply it there too once it comes
through the unstable stage testing.

> (Side note: This does not by itself entirely fix save/restore in 4.2.)
> 
> Signed-off-by: Dan Magenheimer <dan.magenheimer@oracle.com>

With the above, in any case

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

Jan

> diff -r 1dfbae8dd282 xen/common/tmem.c
> --- a/xen/common/tmem.c	Fri Aug 31 11:13:49 2012 +0100
> +++ b/xen/common/tmem.c	Tue Sep 04 15:17:29 2012 -0600
> @@ -2404,6 +2404,7 @@ static NOINLINE int tmemc_save_subop(int
>          *uuid++ = pool->uuid[0];
>          *uuid = pool->uuid[1];
>          rc = 0;
> +        break;
>      case TMEMC_SAVE_END:
>          client->live_migrating = 0;
>          if ( !list_empty(&client->persistent_invalidated_list) )
> @@ -2412,6 +2413,7 @@ static NOINLINE int tmemc_save_subop(int
>                  pgp_free_from_inv_list(client,pgp);
>          client->frozen = client->was_frozen;
>          rc = 0;
> +        break;
>      }
>      return rc;
>  }




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

From xen-devel-bounces@lists.xen.org Wed Sep 05 11:33:02 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Sep 2012 11: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 1T9Dqj-0000xI-Qi; Wed, 05 Sep 2012 11:32: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 1T9Dqi-0000xA-Qk
	for xen-devel@lists.xen.org; Wed, 05 Sep 2012 11:32:49 +0000
Received: from [85.158.138.51:49108] by server-8.bemta-3.messagelabs.com id
	47/30-24700-F5837405; Wed, 05 Sep 2012 11:32:47 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1346844764!28758449!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQwMzE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28366 invoked from network); 5 Sep 2012 11:32:44 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-11.tower-174.messagelabs.com with SMTP;
	5 Sep 2012 11:32:44 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 05 Sep 2012 12:32:44 +0100
Message-Id: <504754B10200007800098D08@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 05 Sep 2012 12:33:37 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Dan Magenheimer" <dan.magenheimer@oracle.com>
References: <f24f5494-5b64-4872-a830-c44859461a9d@default>
In-Reply-To: <f24f5494-5b64-4872-a830-c44859461a9d@default>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Kurt Hackel <kurt.hackel@oracle.com>, Konrad Wilk <konrad.wilk@oracle.com>,
	keir@xen.org, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] tmem: fixup 2010 cleanup patch that breaks
 tmem save/restore
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.09.12 at 23:25, Dan Magenheimer <dan.magenheimer@oracle.com> wrote:
> 20918:a3fa6d444b25 "Fix domain reference leaks" (in Feb 2010, by Jan)
> does some cleanup in addition to the leak fixes.  Unfortunately, that
> cleanup inadvertently resulted in an incorrect fallthrough in a switch
> statement which breaks tmem save/restore.

Oh, I'm sorry for that. We had spotted these missing breaks in
the course of the XSA-15 investigations too, so I'm having a
similar patch pending (deferred its posting until after the
publishing of that advisory). I'd prefer the security ones to go in
first, and this one (or mine, which has some more cleanup in it)
on top. If it's going to be yours, then it would need re-basing, as
the security patches will break the context of the first hunk.

> That broken patch was apparently applied to 4.0-testing and 4.1-testing
> so those are broken as well.

The patch actually went in before 4.0.0-rc3, i.e. before
4.0-testing got branched off.

> What is the process now for requesting back-patches to 4.0 and 4.1?

Unless someone steps up to maintain the 4.0 tree, it'll be
considered dead with the release of 4.2.

For 4.1, I'll be making sure to apply it there too once it comes
through the unstable stage testing.

> (Side note: This does not by itself entirely fix save/restore in 4.2.)
> 
> Signed-off-by: Dan Magenheimer <dan.magenheimer@oracle.com>

With the above, in any case

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

Jan

> diff -r 1dfbae8dd282 xen/common/tmem.c
> --- a/xen/common/tmem.c	Fri Aug 31 11:13:49 2012 +0100
> +++ b/xen/common/tmem.c	Tue Sep 04 15:17:29 2012 -0600
> @@ -2404,6 +2404,7 @@ static NOINLINE int tmemc_save_subop(int
>          *uuid++ = pool->uuid[0];
>          *uuid = pool->uuid[1];
>          rc = 0;
> +        break;
>      case TMEMC_SAVE_END:
>          client->live_migrating = 0;
>          if ( !list_empty(&client->persistent_invalidated_list) )
> @@ -2412,6 +2413,7 @@ static NOINLINE int tmemc_save_subop(int
>                  pgp_free_from_inv_list(client,pgp);
>          client->frozen = client->was_frozen;
>          rc = 0;
> +        break;
>      }
>      return rc;
>  }




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

From xen-devel-bounces@lists.xen.org Wed Sep 05 11:40:54 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Sep 2012 11:40:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9DyH-0001Gi-Cz; Wed, 05 Sep 2012 11:40: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 1T9DyF-0001Gc-Hs
	for xen-devel@lists.xen.org; Wed, 05 Sep 2012 11:40:35 +0000
Received: from [85.158.138.51:6876] by server-11.bemta-3.messagelabs.com id
	0E/C6-30250-23A37405; Wed, 05 Sep 2012 11:40:34 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1346845233!28724073!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQwMzE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4872 invoked from network); 5 Sep 2012 11:40:33 -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;
	5 Sep 2012 11:40:33 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 05 Sep 2012 12:40:32 +0100
Message-Id: <504756850200007800098D1A@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 05 Sep 2012 12:41:25 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Sander Eikelenboom" <linux@eikelenboom.it>
References: <40501859.20120902104331@eikelenboom.it>
	<CC6932C2.3D99D%keir.xen@gmail.com>
	<217459398.20120902171441@eikelenboom.it> <5044CAD7.8030800@amd.com>
	<1144695277.20120904184345@eikelenboom.it>
	<5047420A0200007800098BB1@nat28.tlf.novell.com>
	<348297741.20120905122542@eikelenboom.it>
	<5047483F0200007800098C18@nat28.tlf.novell.com>
	<88861335.20120905124810@eikelenboom.it>
In-Reply-To: <88861335.20120905124810@eikelenboom.it>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Wei Wang <wei.wang2@amd.com>, Keir Fraser <keir.xen@gmail.com>,
	Santosh Jodh <Santosh.Jodh@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Using debug-key 'o:  Dump IOMMU p2m table,
 locks up machine
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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+IE9uIDA1LjA5LjEyIGF0IDEyOjQ4LCBTYW5kZXIgRWlrZWxlbmJvb20gPGxpbnV4QGVpa2Vs
ZW5ib29tLml0PiB3cm90ZToKCj4gV2VkbmVzZGF5LCBTZXB0ZW1iZXIgNSwgMjAxMiwgMTI6NDA6
MzEgUE0sIHlvdSB3cm90ZToKPiAKPj4+Pj4gT24gMDUuMDkuMTIgYXQgMTI6MjUsIFNhbmRlciBF
aWtlbGVuYm9vbSA8bGludXhAZWlrZWxlbmJvb20uaXQ+IHdyb3RlOgo+Pj4gV2VkbmVzZGF5LCBT
ZXB0ZW1iZXIgNSwgMjAxMiwgMTI6MTQ6MDIgUE0sIHlvdSB3cm90ZToKPj4+Pj4+PiBPbiAwNC4w
OS4xMiBhdCAxODo0MywgU2FuZGVyIEVpa2VsZW5ib29tIDxsaW51eEBlaWtlbGVuYm9vbS5pdD4g
d3JvdGU6Cj4+Pj4+IC4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjwwPkFNRC1WaTogSU9fUEFH
RV9GQVVMVDogZG9tYWluID0gMCwgZGV2aWNlIGlkID0gCj4+Pj4+IDB4MGEwNiwgZmF1bHQgYWRk
cmVzcyA9IDB4YzJjMmMyYzAKPj4+IAo+Pj4+IExvb2tzIGxpa2UgdXNlIG9mIHVuaW5pdGlhbGl6
ZWQgbWVtb3J5IChhc3N1bWluZyB5b3UncmUgdXNpbmcgYQo+Pj4+IGRlYnVnIGh5cGVydmlzb3Is
IHRoYXQncyB0aGUgcGF0dGVybiBzY3J1Yl9vbmVfcGFnZSgpIHB1dHMKPj4+PiB0aGVyZSkuIEJ1
dCBpdCdzIHVuY2xlYXIgdG8gbWUgd2hhdCBkZXZpY2Ugc2hvdWxkIGJlIGRvaW5nIGFueQo+Pj4+
IEkvTyBhdCB0aGF0IHBvaW50IChhbmQgZXZlbiBpZiBvbmUgZG9lcywgaG93IGl0IHdvdWxkIGdl
dCB0aGUKPj4+PiBiYWQgYWRkcmVzcyBsb2FkZWQpLiBXaGF0IGlzIDBhOjAwLjY/Cj4+PiAKPj4+
IHNpbmNlIDQuMi1yYzQgaXMgc3RpbGwgdW5zdGFibGUgaXQgaGFzIGRlYnVnPXkgZm9yIHdoYXQg
aSBrbm93LCBzbyB5ZXMuCj4+PiBUaGlzIHBhcnRpY3VsYXIgSU9fUEFHRV9GQVVMVCBoYXBwZW5l
ZCBiZWZvcmUgdGhlIGtlcm5lbCBsb2Fkcywgc28gdGhlIAo+Pj4ga2VybmVsIGFuZCBwY2liYWNr
IHNob3VsZG4ndCBiZSBjYXVzaW5nIHRoZSBpc3N1ZSBvbmUgd291bGQgc2F5Lgo+Pj4gV2l0aCBw
Y2liYWNrIGknbSBoaWRpbmcgMDM6MDYuMCwgMDQ6MDAuKiwgMDU6MDAuMCwgMGE6MDAuKiBhbmQg
MDc6MDAuMCBhdCAKPj4+IGJvb3QuCj4+PiAKPj4+IElzIHRoZXJlIGFueSBjb2RlIGkgY291bGQg
YWRkIHRvIGdldCBtb3JlIGluZm8gd2hlcmUgaXQgY29tZXMgZnJvbSA/Cj4gCj4+IEhhcmRseSwg
c2luY2UgdGhvc2UgYWNjZXNzZXMgYXJlIGFzeW5jaHJvbm91cyB0byB3aGF0IHRoZSBDUFVzCj4+
IGRvLiBCdXQgLi4uCj4gCj4+PiAwYTowMC42IFVTQiBjb250cm9sbGVyOiBOZXRNb3MgVGVjaG5v
bG9neSBNQ1M5OTkwIFBDSWUgdG8gNMOiUG9ydCBVU0IgMi4wIAo+IEhvc3QgQ29udHJvbGxlcgo+
IAo+PiAuLi4gYXJlIHlvdXIga2V5Ym9hcmQvbW91c2UgcGVyaGFwcyBjb25uZWN0ZWQgdG8gdGhp
cyBvbmU/IEluCj4+IHdoaWNoIGNhc2UgSSdkIHN1cHBvc2UgdGhlIDE6MSB0YWJsZXMgc2V0IHVw
IGZvciBEb20wIG1pZ2h0IG5vdAo+PiBiZSBjb21wbGV0ZS4gV2VpPwo+IAo+IE5vcGUgdGhpcyBt
YWNoaW5lIGlzIHJ1bm5pbmcgd2l0aG91dCBhbnkga2V5Ym9hcmQvbW91c2UsIHRoZSBVU0IgY29u
dHJvbGxlciAKPiBhdCBwcmVzZW50IGhhcyBvbmx5IG9uZSBkZXZpY2UgY29ubmVjdGVkIHRvIGl0
Ogo+IGluIHRoZSBwdiBndWVzdCBsc3VzYjoKPiBCdXMgMDA3IERldmljZSAwMDI6IElEIDEwY2Y6
NTUwMCBWZWxsZW1hbiBDb21wb25lbnRzLCBJbmMuIDgwNTUgRXhwZXJpbWVudCAKPiBJbnRlcmZh
Y2UgQm9hcmQgKGFkZHJlc3M9MCkKCkFuZCB0aGlzIGlzIG5vdCBieSBjaGFuY2UgaGFuZ2luZyBv
ZmYgdGhlIGNvbnRyb2xsZXIgdGhhdCB0aGUgZmF1bHQKd2FzIHJlcG9ydGVkIGZvcj8KCj4gQW5k
IGFzIGkgc2FpZCwgdGhlIGhhcmR3YXJlIGRpZG4ndCBjaGFuZ2UgYmV0d2VlbiBteSBzd2l0Y2gg
ZnJvbSB4ZW4tNC4xLjMgCj4gdG8geGVuLTQuMi4KCkkgdW5kZXJzdGFuZCB0aGF0LCBidXQgdGhl
IHByb2JsZW0gaGVyZSBzaG93ZWQgdXAgb25seSBhZnRlcgp0b2dnbGluZyB0aGUgcGFnZSB0YWJs
ZSBzaGFyaW5nIG9wdGlvbiBpaXJjLgoKSmFuCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fXwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0
cy54ZW4ub3JnCmh0dHA6Ly9saXN0cy54ZW4ub3JnL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xen.org Wed Sep 05 11:40:54 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Sep 2012 11:40:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9DyH-0001Gi-Cz; Wed, 05 Sep 2012 11:40: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 1T9DyF-0001Gc-Hs
	for xen-devel@lists.xen.org; Wed, 05 Sep 2012 11:40:35 +0000
Received: from [85.158.138.51:6876] by server-11.bemta-3.messagelabs.com id
	0E/C6-30250-23A37405; Wed, 05 Sep 2012 11:40:34 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1346845233!28724073!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQwMzE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4872 invoked from network); 5 Sep 2012 11:40:33 -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;
	5 Sep 2012 11:40:33 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 05 Sep 2012 12:40:32 +0100
Message-Id: <504756850200007800098D1A@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 05 Sep 2012 12:41:25 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Sander Eikelenboom" <linux@eikelenboom.it>
References: <40501859.20120902104331@eikelenboom.it>
	<CC6932C2.3D99D%keir.xen@gmail.com>
	<217459398.20120902171441@eikelenboom.it> <5044CAD7.8030800@amd.com>
	<1144695277.20120904184345@eikelenboom.it>
	<5047420A0200007800098BB1@nat28.tlf.novell.com>
	<348297741.20120905122542@eikelenboom.it>
	<5047483F0200007800098C18@nat28.tlf.novell.com>
	<88861335.20120905124810@eikelenboom.it>
In-Reply-To: <88861335.20120905124810@eikelenboom.it>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Wei Wang <wei.wang2@amd.com>, Keir Fraser <keir.xen@gmail.com>,
	Santosh Jodh <Santosh.Jodh@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Using debug-key 'o:  Dump IOMMU p2m table,
 locks up machine
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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+IE9uIDA1LjA5LjEyIGF0IDEyOjQ4LCBTYW5kZXIgRWlrZWxlbmJvb20gPGxpbnV4QGVpa2Vs
ZW5ib29tLml0PiB3cm90ZToKCj4gV2VkbmVzZGF5LCBTZXB0ZW1iZXIgNSwgMjAxMiwgMTI6NDA6
MzEgUE0sIHlvdSB3cm90ZToKPiAKPj4+Pj4gT24gMDUuMDkuMTIgYXQgMTI6MjUsIFNhbmRlciBF
aWtlbGVuYm9vbSA8bGludXhAZWlrZWxlbmJvb20uaXQ+IHdyb3RlOgo+Pj4gV2VkbmVzZGF5LCBT
ZXB0ZW1iZXIgNSwgMjAxMiwgMTI6MTQ6MDIgUE0sIHlvdSB3cm90ZToKPj4+Pj4+PiBPbiAwNC4w
OS4xMiBhdCAxODo0MywgU2FuZGVyIEVpa2VsZW5ib29tIDxsaW51eEBlaWtlbGVuYm9vbS5pdD4g
d3JvdGU6Cj4+Pj4+IC4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjwwPkFNRC1WaTogSU9fUEFH
RV9GQVVMVDogZG9tYWluID0gMCwgZGV2aWNlIGlkID0gCj4+Pj4+IDB4MGEwNiwgZmF1bHQgYWRk
cmVzcyA9IDB4YzJjMmMyYzAKPj4+IAo+Pj4+IExvb2tzIGxpa2UgdXNlIG9mIHVuaW5pdGlhbGl6
ZWQgbWVtb3J5IChhc3N1bWluZyB5b3UncmUgdXNpbmcgYQo+Pj4+IGRlYnVnIGh5cGVydmlzb3Is
IHRoYXQncyB0aGUgcGF0dGVybiBzY3J1Yl9vbmVfcGFnZSgpIHB1dHMKPj4+PiB0aGVyZSkuIEJ1
dCBpdCdzIHVuY2xlYXIgdG8gbWUgd2hhdCBkZXZpY2Ugc2hvdWxkIGJlIGRvaW5nIGFueQo+Pj4+
IEkvTyBhdCB0aGF0IHBvaW50IChhbmQgZXZlbiBpZiBvbmUgZG9lcywgaG93IGl0IHdvdWxkIGdl
dCB0aGUKPj4+PiBiYWQgYWRkcmVzcyBsb2FkZWQpLiBXaGF0IGlzIDBhOjAwLjY/Cj4+PiAKPj4+
IHNpbmNlIDQuMi1yYzQgaXMgc3RpbGwgdW5zdGFibGUgaXQgaGFzIGRlYnVnPXkgZm9yIHdoYXQg
aSBrbm93LCBzbyB5ZXMuCj4+PiBUaGlzIHBhcnRpY3VsYXIgSU9fUEFHRV9GQVVMVCBoYXBwZW5l
ZCBiZWZvcmUgdGhlIGtlcm5lbCBsb2Fkcywgc28gdGhlIAo+Pj4ga2VybmVsIGFuZCBwY2liYWNr
IHNob3VsZG4ndCBiZSBjYXVzaW5nIHRoZSBpc3N1ZSBvbmUgd291bGQgc2F5Lgo+Pj4gV2l0aCBw
Y2liYWNrIGknbSBoaWRpbmcgMDM6MDYuMCwgMDQ6MDAuKiwgMDU6MDAuMCwgMGE6MDAuKiBhbmQg
MDc6MDAuMCBhdCAKPj4+IGJvb3QuCj4+PiAKPj4+IElzIHRoZXJlIGFueSBjb2RlIGkgY291bGQg
YWRkIHRvIGdldCBtb3JlIGluZm8gd2hlcmUgaXQgY29tZXMgZnJvbSA/Cj4gCj4+IEhhcmRseSwg
c2luY2UgdGhvc2UgYWNjZXNzZXMgYXJlIGFzeW5jaHJvbm91cyB0byB3aGF0IHRoZSBDUFVzCj4+
IGRvLiBCdXQgLi4uCj4gCj4+PiAwYTowMC42IFVTQiBjb250cm9sbGVyOiBOZXRNb3MgVGVjaG5v
bG9neSBNQ1M5OTkwIFBDSWUgdG8gNMOiUG9ydCBVU0IgMi4wIAo+IEhvc3QgQ29udHJvbGxlcgo+
IAo+PiAuLi4gYXJlIHlvdXIga2V5Ym9hcmQvbW91c2UgcGVyaGFwcyBjb25uZWN0ZWQgdG8gdGhp
cyBvbmU/IEluCj4+IHdoaWNoIGNhc2UgSSdkIHN1cHBvc2UgdGhlIDE6MSB0YWJsZXMgc2V0IHVw
IGZvciBEb20wIG1pZ2h0IG5vdAo+PiBiZSBjb21wbGV0ZS4gV2VpPwo+IAo+IE5vcGUgdGhpcyBt
YWNoaW5lIGlzIHJ1bm5pbmcgd2l0aG91dCBhbnkga2V5Ym9hcmQvbW91c2UsIHRoZSBVU0IgY29u
dHJvbGxlciAKPiBhdCBwcmVzZW50IGhhcyBvbmx5IG9uZSBkZXZpY2UgY29ubmVjdGVkIHRvIGl0
Ogo+IGluIHRoZSBwdiBndWVzdCBsc3VzYjoKPiBCdXMgMDA3IERldmljZSAwMDI6IElEIDEwY2Y6
NTUwMCBWZWxsZW1hbiBDb21wb25lbnRzLCBJbmMuIDgwNTUgRXhwZXJpbWVudCAKPiBJbnRlcmZh
Y2UgQm9hcmQgKGFkZHJlc3M9MCkKCkFuZCB0aGlzIGlzIG5vdCBieSBjaGFuY2UgaGFuZ2luZyBv
ZmYgdGhlIGNvbnRyb2xsZXIgdGhhdCB0aGUgZmF1bHQKd2FzIHJlcG9ydGVkIGZvcj8KCj4gQW5k
IGFzIGkgc2FpZCwgdGhlIGhhcmR3YXJlIGRpZG4ndCBjaGFuZ2UgYmV0d2VlbiBteSBzd2l0Y2gg
ZnJvbSB4ZW4tNC4xLjMgCj4gdG8geGVuLTQuMi4KCkkgdW5kZXJzdGFuZCB0aGF0LCBidXQgdGhl
IHByb2JsZW0gaGVyZSBzaG93ZWQgdXAgb25seSBhZnRlcgp0b2dnbGluZyB0aGUgcGFnZSB0YWJs
ZSBzaGFyaW5nIG9wdGlvbiBpaXJjLgoKSmFuCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fXwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0
cy54ZW4ub3JnCmh0dHA6Ly9saXN0cy54ZW4ub3JnL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xen.org Wed Sep 05 12:04:33 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Sep 2012 12:04: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 1T9EL3-0002GY-Ku; Wed, 05 Sep 2012 12:04:09 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <roger.pau@citrix.com>) id 1T9EL2-0002Fr-HG
	for xen-devel@lists.xen.org; Wed, 05 Sep 2012 12:04:08 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1346846630!8595099!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTE5ODY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19581 invoked from network); 5 Sep 2012 12:03:52 -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;
	5 Sep 2012 12:03:52 -0000
X-IronPort-AV: E=Sophos;i="4.80,374,1344211200"; d="scan'208";a="14357040"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Sep 2012 12:03:47 +0000
Received: from Roger-2.local.net (10.31.3.233) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Wed, 5 Sep 2012
	13:03:47 +0100
From: Roger Pau Monne <roger.pau@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Wed, 5 Sep 2012 14:03:22 +0200
Message-ID: <1346846602-1109-1-git-send-email-roger.pau@citrix.com>
X-Mailer: git-send-email 1.7.7.5 (Apple Git-26)
In-Reply-To: <20120905030239.GJ8912@reaktio.net>
References: <20120905030239.GJ8912@reaktio.net>
MIME-Version: 1.0
Cc: Roger Pau Monne <roger.pau@citrix.com>
Subject: [Xen-devel] [PATCH] libfsimage: add ext4 support for CentOS 5.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

CentOS 5.x forked e2fs ext4 support into a different package called
e4fs, and so headers and library names changed from ext2fs to ext4fs.
Check if ext4fs/ext2fs.h and -lext4fs work, and use that instead of
ext2fs to build libfsimage. This patch assumes that if the ext4fs
library is present it should always be used instead of ext2fs.

This patch includes a rework of the ext2fs check, a new ext4fs check
and a minor modification in libfsimage to use the correct library.

Signed-off-by: Roger Pau Monne <roger.pau@citrix.com>
---
Please re-run autogen.sh after applying
---
 config/Tools.mk.in                       |    2 +-
 tools/config.h.in                        |    3 +++
 tools/configure.ac                       |    4 ++--
 tools/libfsimage/Makefile                |    2 +-
 tools/libfsimage/ext2fs-lib/Makefile     |    5 ++++-
 tools/libfsimage/ext2fs-lib/ext2fs-lib.c |    5 ++++-
 tools/m4/extfs.m4                        |   20 ++++++++++++++++++++
 7 files changed, 35 insertions(+), 6 deletions(-)
 create mode 100644 tools/m4/extfs.m4

diff --git a/config/Tools.mk.in b/config/Tools.mk.in
index 8a52bcc..0859b36 100644
--- a/config/Tools.mk.in
+++ b/config/Tools.mk.in
@@ -56,5 +56,5 @@ CONFIG_SYSTEM_LIBAIO:= @system_aio@
 ZLIB                := @zlib@
 CONFIG_LIBICONV     := @libiconv@
 CONFIG_GCRYPT       := @libgcrypt@
-CONFIG_EXT2FS       := @libext2fs@
+EXTFS_LIBS          := @EXTFS_LIBS@
 CURSES_LIBS         := @CURSES_LIBS@
diff --git a/tools/config.h.in b/tools/config.h.in
index bc1ed10..ab726f6 100644
--- a/tools/config.h.in
+++ b/tools/config.h.in
@@ -45,6 +45,9 @@
 /* libutil header file name */
 #undef INCLUDE_LIBUTIL_H
 
+/* e2fs/e4fs header file name */
+#undef INCLUDE_EXTFS_H
+
 /* Define to the address where bug reports for this package should be sent. */
 #undef PACKAGE_BUGREPORT
 
diff --git a/tools/configure.ac b/tools/configure.ac
index bb497cc..938bc8b 100644
--- a/tools/configure.ac
+++ b/tools/configure.ac
@@ -35,6 +35,7 @@ m4_include([m4/pkg.m4])
 m4_include([m4/curses.m4])
 m4_include([m4/pthread.m4])
 m4_include([m4/ptyfuncs.m4])
+m4_include([m4/extfs.m4])
 
 # Enable/disable options
 AX_ARG_DEFAULT_DISABLE([githttp], [Download GIT repositories via HTTP])
@@ -138,8 +139,7 @@ AC_SUBST(zlib)
 AC_CHECK_LIB([aio], [io_setup], [system_aio="y"], [system_aio="n"])
 AC_SUBST(system_aio)
 AC_CHECK_LIB([crypto], [MD5], [], [AC_MSG_ERROR([Could not find libcrypto])])
-AC_CHECK_LIB([ext2fs], [ext2fs_open2], [libext2fs="y"], [libext2fs="n"])
-AC_SUBST(libext2fs)
+AX_CHECK_EXTFS
 AC_CHECK_LIB([gcrypt], [gcry_md_hash_buffer], [libgcrypt="y"], [libgcrypt="n"])
 AC_SUBST(libgcrypt)
 AX_CHECK_PTHREAD
diff --git a/tools/libfsimage/Makefile b/tools/libfsimage/Makefile
index 5a506f3..69fd18a 100644
--- a/tools/libfsimage/Makefile
+++ b/tools/libfsimage/Makefile
@@ -3,7 +3,7 @@ include $(XEN_ROOT)/tools/Rules.mk
 
 SUBDIRS-y = common ufs reiserfs iso9660 fat zfs
 SUBDIRS-$(CONFIG_X86) += xfs
-ifeq ($(CONFIG_EXT2FS), y)
+ifneq ($(EXTFS_LIBS), )
     SUBDIRS-y += ext2fs-lib
 else
     SUBDIRS-y += ext2fs
diff --git a/tools/libfsimage/ext2fs-lib/Makefile b/tools/libfsimage/ext2fs-lib/Makefile
index 142207f..671fbff 100644
--- a/tools/libfsimage/ext2fs-lib/Makefile
+++ b/tools/libfsimage/ext2fs-lib/Makefile
@@ -4,7 +4,10 @@ LIB_SRCS-y = ext2fs-lib.c
 
 FS = ext2fs-lib
 
-FS_LIBDEPS = -lext2fs
+FS_LIBDEPS = $(EXTFS_LIBS)
+
+# Include configure output (config.h) to headers search path
+CFLAGS += -I$(XEN_ROOT)/tools
 
 .PHONY: all
 all: fs-all
diff --git a/tools/libfsimage/ext2fs-lib/ext2fs-lib.c b/tools/libfsimage/ext2fs-lib/ext2fs-lib.c
index 36a27dc..ed47146 100644
--- a/tools/libfsimage/ext2fs-lib/ext2fs-lib.c
+++ b/tools/libfsimage/ext2fs-lib/ext2fs-lib.c
@@ -21,8 +21,11 @@
  * Use is subject to license terms.
  */
 
+/* Include output from configure */
+#include <config.h>
+
 #include <fsimage_plugin.h>
-#include <ext2fs/ext2fs.h>
+#include INCLUDE_EXTFS_H
 #include <errno.h>
 #include <inttypes.h>
 
diff --git a/tools/m4/extfs.m4 b/tools/m4/extfs.m4
new file mode 100644
index 0000000..7309da9
--- /dev/null
+++ b/tools/m4/extfs.m4
@@ -0,0 +1,20 @@
+AC_DEFUN([AX_CHECK_EXTFS], [
+AC_CHECK_HEADER([ext2fs/ext2fs.h], [
+AC_CHECK_LIB([ext2fs], [ext2fs_open2], [
+    AC_DEFINE([INCLUDE_EXTFS_H], [<ext2fs/ext2fs.h>],
+              [Define extfs header to use])
+    EXTFS_LIBS="-lext2fs"
+])
+])
+dnl This is a temporary hack for CentOS 5.x, which split the ext4 support
+dnl of ext2fs in a different package. Once CentOS 5.x is no longer supported
+dnl we can remove this.
+AC_CHECK_HEADER([ext4fs/ext2fs.h], [
+AC_CHECK_LIB([ext4fs], [ext2fs_open2], [
+    AC_DEFINE([INCLUDE_EXTFS_H], [<ext4fs/ext2fs.h>],
+              [Define extfs header to use])
+    EXTFS_LIBS="-lext4fs"
+])
+])
+AC_SUBST(EXTFS_LIBS)
+])
-- 
1.7.7.5 (Apple Git-26)


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

From xen-devel-bounces@lists.xen.org Wed Sep 05 12:04:33 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Sep 2012 12:04: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 1T9EL3-0002GY-Ku; Wed, 05 Sep 2012 12:04:09 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <roger.pau@citrix.com>) id 1T9EL2-0002Fr-HG
	for xen-devel@lists.xen.org; Wed, 05 Sep 2012 12:04:08 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1346846630!8595099!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTE5ODY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19581 invoked from network); 5 Sep 2012 12:03:52 -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;
	5 Sep 2012 12:03:52 -0000
X-IronPort-AV: E=Sophos;i="4.80,374,1344211200"; d="scan'208";a="14357040"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Sep 2012 12:03:47 +0000
Received: from Roger-2.local.net (10.31.3.233) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Wed, 5 Sep 2012
	13:03:47 +0100
From: Roger Pau Monne <roger.pau@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Wed, 5 Sep 2012 14:03:22 +0200
Message-ID: <1346846602-1109-1-git-send-email-roger.pau@citrix.com>
X-Mailer: git-send-email 1.7.7.5 (Apple Git-26)
In-Reply-To: <20120905030239.GJ8912@reaktio.net>
References: <20120905030239.GJ8912@reaktio.net>
MIME-Version: 1.0
Cc: Roger Pau Monne <roger.pau@citrix.com>
Subject: [Xen-devel] [PATCH] libfsimage: add ext4 support for CentOS 5.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

CentOS 5.x forked e2fs ext4 support into a different package called
e4fs, and so headers and library names changed from ext2fs to ext4fs.
Check if ext4fs/ext2fs.h and -lext4fs work, and use that instead of
ext2fs to build libfsimage. This patch assumes that if the ext4fs
library is present it should always be used instead of ext2fs.

This patch includes a rework of the ext2fs check, a new ext4fs check
and a minor modification in libfsimage to use the correct library.

Signed-off-by: Roger Pau Monne <roger.pau@citrix.com>
---
Please re-run autogen.sh after applying
---
 config/Tools.mk.in                       |    2 +-
 tools/config.h.in                        |    3 +++
 tools/configure.ac                       |    4 ++--
 tools/libfsimage/Makefile                |    2 +-
 tools/libfsimage/ext2fs-lib/Makefile     |    5 ++++-
 tools/libfsimage/ext2fs-lib/ext2fs-lib.c |    5 ++++-
 tools/m4/extfs.m4                        |   20 ++++++++++++++++++++
 7 files changed, 35 insertions(+), 6 deletions(-)
 create mode 100644 tools/m4/extfs.m4

diff --git a/config/Tools.mk.in b/config/Tools.mk.in
index 8a52bcc..0859b36 100644
--- a/config/Tools.mk.in
+++ b/config/Tools.mk.in
@@ -56,5 +56,5 @@ CONFIG_SYSTEM_LIBAIO:= @system_aio@
 ZLIB                := @zlib@
 CONFIG_LIBICONV     := @libiconv@
 CONFIG_GCRYPT       := @libgcrypt@
-CONFIG_EXT2FS       := @libext2fs@
+EXTFS_LIBS          := @EXTFS_LIBS@
 CURSES_LIBS         := @CURSES_LIBS@
diff --git a/tools/config.h.in b/tools/config.h.in
index bc1ed10..ab726f6 100644
--- a/tools/config.h.in
+++ b/tools/config.h.in
@@ -45,6 +45,9 @@
 /* libutil header file name */
 #undef INCLUDE_LIBUTIL_H
 
+/* e2fs/e4fs header file name */
+#undef INCLUDE_EXTFS_H
+
 /* Define to the address where bug reports for this package should be sent. */
 #undef PACKAGE_BUGREPORT
 
diff --git a/tools/configure.ac b/tools/configure.ac
index bb497cc..938bc8b 100644
--- a/tools/configure.ac
+++ b/tools/configure.ac
@@ -35,6 +35,7 @@ m4_include([m4/pkg.m4])
 m4_include([m4/curses.m4])
 m4_include([m4/pthread.m4])
 m4_include([m4/ptyfuncs.m4])
+m4_include([m4/extfs.m4])
 
 # Enable/disable options
 AX_ARG_DEFAULT_DISABLE([githttp], [Download GIT repositories via HTTP])
@@ -138,8 +139,7 @@ AC_SUBST(zlib)
 AC_CHECK_LIB([aio], [io_setup], [system_aio="y"], [system_aio="n"])
 AC_SUBST(system_aio)
 AC_CHECK_LIB([crypto], [MD5], [], [AC_MSG_ERROR([Could not find libcrypto])])
-AC_CHECK_LIB([ext2fs], [ext2fs_open2], [libext2fs="y"], [libext2fs="n"])
-AC_SUBST(libext2fs)
+AX_CHECK_EXTFS
 AC_CHECK_LIB([gcrypt], [gcry_md_hash_buffer], [libgcrypt="y"], [libgcrypt="n"])
 AC_SUBST(libgcrypt)
 AX_CHECK_PTHREAD
diff --git a/tools/libfsimage/Makefile b/tools/libfsimage/Makefile
index 5a506f3..69fd18a 100644
--- a/tools/libfsimage/Makefile
+++ b/tools/libfsimage/Makefile
@@ -3,7 +3,7 @@ include $(XEN_ROOT)/tools/Rules.mk
 
 SUBDIRS-y = common ufs reiserfs iso9660 fat zfs
 SUBDIRS-$(CONFIG_X86) += xfs
-ifeq ($(CONFIG_EXT2FS), y)
+ifneq ($(EXTFS_LIBS), )
     SUBDIRS-y += ext2fs-lib
 else
     SUBDIRS-y += ext2fs
diff --git a/tools/libfsimage/ext2fs-lib/Makefile b/tools/libfsimage/ext2fs-lib/Makefile
index 142207f..671fbff 100644
--- a/tools/libfsimage/ext2fs-lib/Makefile
+++ b/tools/libfsimage/ext2fs-lib/Makefile
@@ -4,7 +4,10 @@ LIB_SRCS-y = ext2fs-lib.c
 
 FS = ext2fs-lib
 
-FS_LIBDEPS = -lext2fs
+FS_LIBDEPS = $(EXTFS_LIBS)
+
+# Include configure output (config.h) to headers search path
+CFLAGS += -I$(XEN_ROOT)/tools
 
 .PHONY: all
 all: fs-all
diff --git a/tools/libfsimage/ext2fs-lib/ext2fs-lib.c b/tools/libfsimage/ext2fs-lib/ext2fs-lib.c
index 36a27dc..ed47146 100644
--- a/tools/libfsimage/ext2fs-lib/ext2fs-lib.c
+++ b/tools/libfsimage/ext2fs-lib/ext2fs-lib.c
@@ -21,8 +21,11 @@
  * Use is subject to license terms.
  */
 
+/* Include output from configure */
+#include <config.h>
+
 #include <fsimage_plugin.h>
-#include <ext2fs/ext2fs.h>
+#include INCLUDE_EXTFS_H
 #include <errno.h>
 #include <inttypes.h>
 
diff --git a/tools/m4/extfs.m4 b/tools/m4/extfs.m4
new file mode 100644
index 0000000..7309da9
--- /dev/null
+++ b/tools/m4/extfs.m4
@@ -0,0 +1,20 @@
+AC_DEFUN([AX_CHECK_EXTFS], [
+AC_CHECK_HEADER([ext2fs/ext2fs.h], [
+AC_CHECK_LIB([ext2fs], [ext2fs_open2], [
+    AC_DEFINE([INCLUDE_EXTFS_H], [<ext2fs/ext2fs.h>],
+              [Define extfs header to use])
+    EXTFS_LIBS="-lext2fs"
+])
+])
+dnl This is a temporary hack for CentOS 5.x, which split the ext4 support
+dnl of ext2fs in a different package. Once CentOS 5.x is no longer supported
+dnl we can remove this.
+AC_CHECK_HEADER([ext4fs/ext2fs.h], [
+AC_CHECK_LIB([ext4fs], [ext2fs_open2], [
+    AC_DEFINE([INCLUDE_EXTFS_H], [<ext4fs/ext2fs.h>],
+              [Define extfs header to use])
+    EXTFS_LIBS="-lext4fs"
+])
+])
+AC_SUBST(EXTFS_LIBS)
+])
-- 
1.7.7.5 (Apple Git-26)


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

From xen-devel-bounces@lists.xen.org Wed Sep 05 12:12:29 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Sep 2012 12:12: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 1T9ESr-0002h3-Jp; Wed, 05 Sep 2012 12:12:13 +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 1T9ESq-0002gt-1L
	for xen-devel@lists.xen.org; Wed, 05 Sep 2012 12:12:12 +0000
Received: from [85.158.143.35:57916] by server-3.bemta-4.messagelabs.com id
	1E/86-08232-B9147405; Wed, 05 Sep 2012 12:12:11 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-9.tower-21.messagelabs.com!1346847120!5732020!1
X-Originating-IP: [188.40.164.121]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12279 invoked from network); 5 Sep 2012 12:12:09 -0000
Received: from static.121.164.40.188.clients.your-server.de (HELO
	smtp.eikelenboom.it) (188.40.164.121)
	by server-9.tower-21.messagelabs.com with AES256-SHA encrypted SMTP;
	5 Sep 2012 12:12:09 -0000
Received: from 128-64-ftth.onsneteindhoven.nl ([88.159.64.128]:52179
	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 1T9EPa-0008GL-IU; Wed, 05 Sep 2012 14:08:50 +0200
Date: Wed, 5 Sep 2012 14:11:55 +0200
From: Sander Eikelenboom <linux@eikelenboom.it>
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <814436011.20120905141155@eikelenboom.it>
To: "Jan Beulich" <JBeulich@suse.com>
In-Reply-To: <504756850200007800098D1A@nat28.tlf.novell.com>
References: <40501859.20120902104331@eikelenboom.it>
	<CC6932C2.3D99D%keir.xen@gmail.com>
	<217459398.20120902171441@eikelenboom.it>
	<5044CAD7.8030800@amd.com>
	<1144695277.20120904184345@eikelenboom.it>
	<5047420A0200007800098BB1@nat28.tlf.novell.com>
	<348297741.20120905122542@eikelenboom.it>
	<5047483F0200007800098C18@nat28.tlf.novell.com>
	<88861335.20120905124810@eikelenboom.it>
	<504756850200007800098D1A@nat28.tlf.novell.com>
MIME-Version: 1.0
Cc: Wei Wang <wei.wang2@amd.com>, Keir Fraser <keir.xen@gmail.com>,
	Santosh Jodh <Santosh.Jodh@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Using debug-key 'o:  Dump IOMMU p2m table,
	locks up machine
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

DQpXZWRuZXNkYXksIFNlcHRlbWJlciA1LCAyMDEyLCAxOjQxOjI1IFBNLCB5b3Ugd3JvdGU6Cgo+
Pj4+IE9uIDA1LjA5LjEyIGF0IDEyOjQ4LCBTYW5kZXIgRWlrZWxlbmJvb20gPGxpbnV4QGVpa2Vs
ZW5ib29tLml0PiB3cm90ZToKCj4+IFdlZG5lc2RheSwgU2VwdGVtYmVyIDUsIDIwMTIsIDEyOjQw
OjMxIFBNLCB5b3Ugd3JvdGU6Cj4+IAo+Pj4+Pj4gT24gMDUuMDkuMTIgYXQgMTI6MjUsIFNhbmRl
ciBFaWtlbGVuYm9vbSA8bGludXhAZWlrZWxlbmJvb20uaXQ+IHdyb3RlOgo+Pj4+IFdlZG5lc2Rh
eSwgU2VwdGVtYmVyIDUsIDIwMTIsIDEyOjE0OjAyIFBNLCB5b3Ugd3JvdGU6Cj4+Pj4+Pj4+IE9u
IDA0LjA5LjEyIGF0IDE4OjQzLCBTYW5kZXIgRWlrZWxlbmJvb20gPGxpbnV4QGVpa2VsZW5ib29t
Lml0PiB3cm90ZToKPj4+Pj4+IC4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjwwPkFNRC1WaTog
SU9fUEFHRV9GQVVMVDogZG9tYWluID0gMCwgZGV2aWNlIGlkID0gCj4+Pj4+PiAweDBhMDYsIGZh
dWx0IGFkZHJlc3MgPSAweGMyYzJjMmMwCj4+Pj4gCj4+Pj4+IExvb2tzIGxpa2UgdXNlIG9mIHVu
aW5pdGlhbGl6ZWQgbWVtb3J5IChhc3N1bWluZyB5b3UncmUgdXNpbmcgYQo+Pj4+PiBkZWJ1ZyBo
eXBlcnZpc29yLCB0aGF0J3MgdGhlIHBhdHRlcm4gc2NydWJfb25lX3BhZ2UoKSBwdXRzCj4+Pj4+
IHRoZXJlKS4gQnV0IGl0J3MgdW5jbGVhciB0byBtZSB3aGF0IGRldmljZSBzaG91bGQgYmUgZG9p
bmcgYW55Cj4+Pj4+IEkvTyBhdCB0aGF0IHBvaW50IChhbmQgZXZlbiBpZiBvbmUgZG9lcywgaG93
IGl0IHdvdWxkIGdldCB0aGUKPj4+Pj4gYmFkIGFkZHJlc3MgbG9hZGVkKS4gV2hhdCBpcyAwYTow
MC42Pwo+Pj4+IAo+Pj4+IHNpbmNlIDQuMi1yYzQgaXMgc3RpbGwgdW5zdGFibGUgaXQgaGFzIGRl
YnVnPXkgZm9yIHdoYXQgaSBrbm93LCBzbyB5ZXMuCj4+Pj4gVGhpcyBwYXJ0aWN1bGFyIElPX1BB
R0VfRkFVTFQgaGFwcGVuZWQgYmVmb3JlIHRoZSBrZXJuZWwgbG9hZHMsIHNvIHRoZSAKPj4+PiBr
ZXJuZWwgYW5kIHBjaWJhY2sgc2hvdWxkbid0IGJlIGNhdXNpbmcgdGhlIGlzc3VlIG9uZSB3b3Vs
ZCBzYXkuCj4+Pj4gV2l0aCBwY2liYWNrIGknbSBoaWRpbmcgMDM6MDYuMCwgMDQ6MDAuKiwgMDU6
MDAuMCwgMGE6MDAuKiBhbmQgMDc6MDAuMCBhdCAKPj4+PiBib290Lgo+Pj4+IAo+Pj4+IElzIHRo
ZXJlIGFueSBjb2RlIGkgY291bGQgYWRkIHRvIGdldCBtb3JlIGluZm8gd2hlcmUgaXQgY29tZXMg
ZnJvbSA/Cj4+IAo+Pj4gSGFyZGx5LCBzaW5jZSB0aG9zZSBhY2Nlc3NlcyBhcmUgYXN5bmNocm9u
b3VzIHRvIHdoYXQgdGhlIENQVXMKPj4+IGRvLiBCdXQgLi4uCj4+IAo+Pj4+IDBhOjAwLjYgVVNC
IGNvbnRyb2xsZXI6IE5ldE1vcyBUZWNobm9sb2d5IE1DUzk5OTAgUENJZSB0byA0w6JQb3J0IFVT
QiAyLjAgCj4+IEhvc3QgQ29udHJvbGxlcgo+PiAKPj4+IC4uLiBhcmUgeW91ciBrZXlib2FyZC9t
b3VzZSBwZXJoYXBzIGNvbm5lY3RlZCB0byB0aGlzIG9uZT8gSW4KPj4+IHdoaWNoIGNhc2UgSSdk
IHN1cHBvc2UgdGhlIDE6MSB0YWJsZXMgc2V0IHVwIGZvciBEb20wIG1pZ2h0IG5vdAo+Pj4gYmUg
Y29tcGxldGUuIFdlaT8KPj4gCj4+IE5vcGUgdGhpcyBtYWNoaW5lIGlzIHJ1bm5pbmcgd2l0aG91
dCBhbnkga2V5Ym9hcmQvbW91c2UsIHRoZSBVU0IgY29udHJvbGxlciAKPj4gYXQgcHJlc2VudCBo
YXMgb25seSBvbmUgZGV2aWNlIGNvbm5lY3RlZCB0byBpdDoKPj4gaW4gdGhlIHB2IGd1ZXN0IGxz
dXNiOgo+PiBCdXMgMDA3IERldmljZSAwMDI6IElEIDEwY2Y6NTUwMCBWZWxsZW1hbiBDb21wb25l
bnRzLCBJbmMuIDgwNTUgRXhwZXJpbWVudCAKPj4gSW50ZXJmYWNlIEJvYXJkIChhZGRyZXNzPTAp
Cgo+IEFuZCB0aGlzIGlzIG5vdCBieSBjaGFuY2UgaGFuZ2luZyBvZmYgdGhlIGNvbnRyb2xsZXIg
dGhhdCB0aGUgZmF1bHQKPiB3YXMgcmVwb3J0ZWQgZm9yPwoKWWVzIGJ1dCBpIGFsc28gZ2V0IGZh
dWx0cyBmb3IgdGhlIDA3OjAwLjAgbGF0ZXIgb24gYm9vdGluZy4KCj4+IEFuZCBhcyBpIHNhaWQs
IHRoZSBoYXJkd2FyZSBkaWRuJ3QgY2hhbmdlIGJldHdlZW4gbXkgc3dpdGNoIGZyb20geGVuLTQu
MS4zIAo+PiB0byB4ZW4tNC4yLgoKPiBJIHVuZGVyc3RhbmQgdGhhdCwgYnV0IHRoZSBwcm9ibGVt
IGhlcmUgc2hvd2VkIHVwIG9ubHkgYWZ0ZXIKPiB0b2dnbGluZyB0aGUgcGFnZSB0YWJsZSBzaGFy
aW5nIG9wdGlvbiBpaXJjLgoKWW91IG1lYW4gdGhhdCB0aGUgZmF1bHQgb2NjdXJyaW5nIHRoaXMg
ZWFybHkgZHVyaW5nIGJvb3QsIG9ubHkgaGFwcGVuZWQgYWZ0ZXIgZW5hYmxpbmcgdGhlICJpb21t
dT1uby1zaGFyZXB0IiA/ClRoYXQncyBjb3JyZWN0IGFsdGhvdWdoIGl0J3Mgbm90IGNsZWFyIGlm
IHRoYXQgaXMgY29pbmNpZGVuY2Ugb3Igbm90LgoKPiBKYW4KCgoKX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4t
ZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwOi8vbGlzdHMueGVuLm9yZy94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xen.org Wed Sep 05 12:12:29 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Sep 2012 12:12: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 1T9ESr-0002h3-Jp; Wed, 05 Sep 2012 12:12:13 +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 1T9ESq-0002gt-1L
	for xen-devel@lists.xen.org; Wed, 05 Sep 2012 12:12:12 +0000
Received: from [85.158.143.35:57916] by server-3.bemta-4.messagelabs.com id
	1E/86-08232-B9147405; Wed, 05 Sep 2012 12:12:11 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-9.tower-21.messagelabs.com!1346847120!5732020!1
X-Originating-IP: [188.40.164.121]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12279 invoked from network); 5 Sep 2012 12:12:09 -0000
Received: from static.121.164.40.188.clients.your-server.de (HELO
	smtp.eikelenboom.it) (188.40.164.121)
	by server-9.tower-21.messagelabs.com with AES256-SHA encrypted SMTP;
	5 Sep 2012 12:12:09 -0000
Received: from 128-64-ftth.onsneteindhoven.nl ([88.159.64.128]:52179
	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 1T9EPa-0008GL-IU; Wed, 05 Sep 2012 14:08:50 +0200
Date: Wed, 5 Sep 2012 14:11:55 +0200
From: Sander Eikelenboom <linux@eikelenboom.it>
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <814436011.20120905141155@eikelenboom.it>
To: "Jan Beulich" <JBeulich@suse.com>
In-Reply-To: <504756850200007800098D1A@nat28.tlf.novell.com>
References: <40501859.20120902104331@eikelenboom.it>
	<CC6932C2.3D99D%keir.xen@gmail.com>
	<217459398.20120902171441@eikelenboom.it>
	<5044CAD7.8030800@amd.com>
	<1144695277.20120904184345@eikelenboom.it>
	<5047420A0200007800098BB1@nat28.tlf.novell.com>
	<348297741.20120905122542@eikelenboom.it>
	<5047483F0200007800098C18@nat28.tlf.novell.com>
	<88861335.20120905124810@eikelenboom.it>
	<504756850200007800098D1A@nat28.tlf.novell.com>
MIME-Version: 1.0
Cc: Wei Wang <wei.wang2@amd.com>, Keir Fraser <keir.xen@gmail.com>,
	Santosh Jodh <Santosh.Jodh@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Using debug-key 'o:  Dump IOMMU p2m table,
	locks up machine
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

DQpXZWRuZXNkYXksIFNlcHRlbWJlciA1LCAyMDEyLCAxOjQxOjI1IFBNLCB5b3Ugd3JvdGU6Cgo+
Pj4+IE9uIDA1LjA5LjEyIGF0IDEyOjQ4LCBTYW5kZXIgRWlrZWxlbmJvb20gPGxpbnV4QGVpa2Vs
ZW5ib29tLml0PiB3cm90ZToKCj4+IFdlZG5lc2RheSwgU2VwdGVtYmVyIDUsIDIwMTIsIDEyOjQw
OjMxIFBNLCB5b3Ugd3JvdGU6Cj4+IAo+Pj4+Pj4gT24gMDUuMDkuMTIgYXQgMTI6MjUsIFNhbmRl
ciBFaWtlbGVuYm9vbSA8bGludXhAZWlrZWxlbmJvb20uaXQ+IHdyb3RlOgo+Pj4+IFdlZG5lc2Rh
eSwgU2VwdGVtYmVyIDUsIDIwMTIsIDEyOjE0OjAyIFBNLCB5b3Ugd3JvdGU6Cj4+Pj4+Pj4+IE9u
IDA0LjA5LjEyIGF0IDE4OjQzLCBTYW5kZXIgRWlrZWxlbmJvb20gPGxpbnV4QGVpa2VsZW5ib29t
Lml0PiB3cm90ZToKPj4+Pj4+IC4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjwwPkFNRC1WaTog
SU9fUEFHRV9GQVVMVDogZG9tYWluID0gMCwgZGV2aWNlIGlkID0gCj4+Pj4+PiAweDBhMDYsIGZh
dWx0IGFkZHJlc3MgPSAweGMyYzJjMmMwCj4+Pj4gCj4+Pj4+IExvb2tzIGxpa2UgdXNlIG9mIHVu
aW5pdGlhbGl6ZWQgbWVtb3J5IChhc3N1bWluZyB5b3UncmUgdXNpbmcgYQo+Pj4+PiBkZWJ1ZyBo
eXBlcnZpc29yLCB0aGF0J3MgdGhlIHBhdHRlcm4gc2NydWJfb25lX3BhZ2UoKSBwdXRzCj4+Pj4+
IHRoZXJlKS4gQnV0IGl0J3MgdW5jbGVhciB0byBtZSB3aGF0IGRldmljZSBzaG91bGQgYmUgZG9p
bmcgYW55Cj4+Pj4+IEkvTyBhdCB0aGF0IHBvaW50IChhbmQgZXZlbiBpZiBvbmUgZG9lcywgaG93
IGl0IHdvdWxkIGdldCB0aGUKPj4+Pj4gYmFkIGFkZHJlc3MgbG9hZGVkKS4gV2hhdCBpcyAwYTow
MC42Pwo+Pj4+IAo+Pj4+IHNpbmNlIDQuMi1yYzQgaXMgc3RpbGwgdW5zdGFibGUgaXQgaGFzIGRl
YnVnPXkgZm9yIHdoYXQgaSBrbm93LCBzbyB5ZXMuCj4+Pj4gVGhpcyBwYXJ0aWN1bGFyIElPX1BB
R0VfRkFVTFQgaGFwcGVuZWQgYmVmb3JlIHRoZSBrZXJuZWwgbG9hZHMsIHNvIHRoZSAKPj4+PiBr
ZXJuZWwgYW5kIHBjaWJhY2sgc2hvdWxkbid0IGJlIGNhdXNpbmcgdGhlIGlzc3VlIG9uZSB3b3Vs
ZCBzYXkuCj4+Pj4gV2l0aCBwY2liYWNrIGknbSBoaWRpbmcgMDM6MDYuMCwgMDQ6MDAuKiwgMDU6
MDAuMCwgMGE6MDAuKiBhbmQgMDc6MDAuMCBhdCAKPj4+PiBib290Lgo+Pj4+IAo+Pj4+IElzIHRo
ZXJlIGFueSBjb2RlIGkgY291bGQgYWRkIHRvIGdldCBtb3JlIGluZm8gd2hlcmUgaXQgY29tZXMg
ZnJvbSA/Cj4+IAo+Pj4gSGFyZGx5LCBzaW5jZSB0aG9zZSBhY2Nlc3NlcyBhcmUgYXN5bmNocm9u
b3VzIHRvIHdoYXQgdGhlIENQVXMKPj4+IGRvLiBCdXQgLi4uCj4+IAo+Pj4+IDBhOjAwLjYgVVNC
IGNvbnRyb2xsZXI6IE5ldE1vcyBUZWNobm9sb2d5IE1DUzk5OTAgUENJZSB0byA0w6JQb3J0IFVT
QiAyLjAgCj4+IEhvc3QgQ29udHJvbGxlcgo+PiAKPj4+IC4uLiBhcmUgeW91ciBrZXlib2FyZC9t
b3VzZSBwZXJoYXBzIGNvbm5lY3RlZCB0byB0aGlzIG9uZT8gSW4KPj4+IHdoaWNoIGNhc2UgSSdk
IHN1cHBvc2UgdGhlIDE6MSB0YWJsZXMgc2V0IHVwIGZvciBEb20wIG1pZ2h0IG5vdAo+Pj4gYmUg
Y29tcGxldGUuIFdlaT8KPj4gCj4+IE5vcGUgdGhpcyBtYWNoaW5lIGlzIHJ1bm5pbmcgd2l0aG91
dCBhbnkga2V5Ym9hcmQvbW91c2UsIHRoZSBVU0IgY29udHJvbGxlciAKPj4gYXQgcHJlc2VudCBo
YXMgb25seSBvbmUgZGV2aWNlIGNvbm5lY3RlZCB0byBpdDoKPj4gaW4gdGhlIHB2IGd1ZXN0IGxz
dXNiOgo+PiBCdXMgMDA3IERldmljZSAwMDI6IElEIDEwY2Y6NTUwMCBWZWxsZW1hbiBDb21wb25l
bnRzLCBJbmMuIDgwNTUgRXhwZXJpbWVudCAKPj4gSW50ZXJmYWNlIEJvYXJkIChhZGRyZXNzPTAp
Cgo+IEFuZCB0aGlzIGlzIG5vdCBieSBjaGFuY2UgaGFuZ2luZyBvZmYgdGhlIGNvbnRyb2xsZXIg
dGhhdCB0aGUgZmF1bHQKPiB3YXMgcmVwb3J0ZWQgZm9yPwoKWWVzIGJ1dCBpIGFsc28gZ2V0IGZh
dWx0cyBmb3IgdGhlIDA3OjAwLjAgbGF0ZXIgb24gYm9vdGluZy4KCj4+IEFuZCBhcyBpIHNhaWQs
IHRoZSBoYXJkd2FyZSBkaWRuJ3QgY2hhbmdlIGJldHdlZW4gbXkgc3dpdGNoIGZyb20geGVuLTQu
MS4zIAo+PiB0byB4ZW4tNC4yLgoKPiBJIHVuZGVyc3RhbmQgdGhhdCwgYnV0IHRoZSBwcm9ibGVt
IGhlcmUgc2hvd2VkIHVwIG9ubHkgYWZ0ZXIKPiB0b2dnbGluZyB0aGUgcGFnZSB0YWJsZSBzaGFy
aW5nIG9wdGlvbiBpaXJjLgoKWW91IG1lYW4gdGhhdCB0aGUgZmF1bHQgb2NjdXJyaW5nIHRoaXMg
ZWFybHkgZHVyaW5nIGJvb3QsIG9ubHkgaGFwcGVuZWQgYWZ0ZXIgZW5hYmxpbmcgdGhlICJpb21t
dT1uby1zaGFyZXB0IiA/ClRoYXQncyBjb3JyZWN0IGFsdGhvdWdoIGl0J3Mgbm90IGNsZWFyIGlm
IHRoYXQgaXMgY29pbmNpZGVuY2Ugb3Igbm90LgoKPiBKYW4KCgoKX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4t
ZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwOi8vbGlzdHMueGVuLm9yZy94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xen.org Wed Sep 05 12:22:42 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Sep 2012 12: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 1T9Ech-00030D-4k; Wed, 05 Sep 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 <JBeulich@suse.com>) id 1T9Ecf-000305-PT
	for xen-devel@lists.xen.org; Wed, 05 Sep 2012 12:22:21 +0000
Received: from [85.158.143.99:5273] by server-1.bemta-4.messagelabs.com id
	41/C8-12504-DF347405; Wed, 05 Sep 2012 12:22:21 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1346847735!28085554!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQwMzE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19456 invoked from network); 5 Sep 2012 12:22:15 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-3.tower-216.messagelabs.com with SMTP;
	5 Sep 2012 12:22:15 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 05 Sep 2012 13:22:15 +0100
Message-Id: <504760480200007800098D68@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 05 Sep 2012 13:23:04 +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 0/2] PHYSDEVOP_get_free_pirq adjustments
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Issues noticed during recent fixing of security problems.

1: x86: drop "index" parameter from get_free_pirq()
2: x86: fix RCU locking in PHYSDEVOP_get_free_pirq

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


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

From xen-devel-bounces@lists.xen.org Wed Sep 05 12:22:42 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Sep 2012 12: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 1T9Ech-00030D-4k; Wed, 05 Sep 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 <JBeulich@suse.com>) id 1T9Ecf-000305-PT
	for xen-devel@lists.xen.org; Wed, 05 Sep 2012 12:22:21 +0000
Received: from [85.158.143.99:5273] by server-1.bemta-4.messagelabs.com id
	41/C8-12504-DF347405; Wed, 05 Sep 2012 12:22:21 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1346847735!28085554!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQwMzE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19456 invoked from network); 5 Sep 2012 12:22:15 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-3.tower-216.messagelabs.com with SMTP;
	5 Sep 2012 12:22:15 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 05 Sep 2012 13:22:15 +0100
Message-Id: <504760480200007800098D68@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 05 Sep 2012 13:23:04 +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 0/2] PHYSDEVOP_get_free_pirq adjustments
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Issues noticed during recent fixing of security problems.

1: x86: drop "index" parameter from get_free_pirq()
2: x86: fix RCU locking in PHYSDEVOP_get_free_pirq

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


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

From xen-devel-bounces@lists.xen.org Wed Sep 05 12:24:25 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Sep 2012 12:24:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9EeJ-00035L-MV; Wed, 05 Sep 2012 12:24: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 1T9EeI-00035D-97
	for xen-devel@lists.xen.org; Wed, 05 Sep 2012 12:24:02 +0000
Received: from [85.158.143.99:27199] by server-3.bemta-4.messagelabs.com id
	65/7C-08232-16447405; Wed, 05 Sep 2012 12:24:01 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1346847837!22273977!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQwMzE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11469 invoked from network); 5 Sep 2012 12:24:00 -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;
	5 Sep 2012 12:24:00 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 05 Sep 2012 13:23:57 +0100
Message-Id: <504760B20200007800098D6C@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 05 Sep 2012 13:24:50 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__PartB988A382.0__="
Subject: [Xen-devel] [PATCH 1/2] x86: drop "index" parameter from
	get_free_pirq()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<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.

--=__PartB988A382.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

It's unused.

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

--- a/xen/arch/x86/irq.c
+++ b/xen/arch/x86/irq.c
@@ -1816,7 +1816,7 @@ static inline bool_t is_free_pirq(const=20
         pirq->arch.hvm.emuirq =3D=3D IRQ_UNBOUND));
 }
=20
-int get_free_pirq(struct domain *d, int type, int index)
+int get_free_pirq(struct domain *d, int type)
 {
     int i;
=20
--- a/xen/arch/x86/physdev.c
+++ b/xen/arch/x86/physdev.c
@@ -71,7 +71,7 @@ static int physdev_hvm_map_pirq(
         else
         {
             if ( *pirq < 0 )
-                *pirq =3D get_free_pirq(d, type, *index);
+                *pirq =3D get_free_pirq(d, type);
             ret =3D map_domain_emuirq_pirq(d, *pirq, *index);
         }
         break;
@@ -187,7 +187,7 @@ int physdev_map_pirq(domid_t domid, int=20
         }
         else
         {
-            pirq =3D get_free_pirq(d, type, *index);
+            pirq =3D get_free_pirq(d, type);
             if ( pirq < 0 )
             {
                 dprintk(XENLOG_G_ERR, "dom%d: no free pirq\n", d->domain_i=
d);
@@ -705,7 +705,7 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_H
             break;
=20
         spin_lock(&d->event_lock);
-        ret =3D get_free_pirq(d, out.type, 0);
+        ret =3D get_free_pirq(d, out.type);
         if ( ret >=3D 0 )
         {
             struct pirq *info =3D pirq_get_info(d, ret);
--- a/xen/include/asm-x86/irq.h
+++ b/xen/include/asm-x86/irq.h
@@ -136,7 +136,7 @@ int pirq_shared(struct domain *d , int i
 int map_domain_pirq(struct domain *d, int pirq, int irq, int type,
                            void *data);
 int unmap_domain_pirq(struct domain *d, int pirq);
-int get_free_pirq(struct domain *d, int type, int index);
+int get_free_pirq(struct domain *d, int type);
 void free_domain_pirqs(struct domain *d);
 int map_domain_emuirq_pirq(struct domain *d, int pirq, int irq);
 int unmap_domain_pirq_emuirq(struct domain *d, int pirq);




--=__PartB988A382.0__=
Content-Type: text/plain; name="x86-get_free_pirq-drop-index.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="x86-get_free_pirq-drop-index.patch"

x86: drop "index" parameter from get_free_pirq()=0A=0AIt's unused.=0A=0ASig=
ned-off-by: Jan Beulich <jbeulich@suse.com>=0A=0A--- a/xen/arch/x86/irq.c=
=0A+++ b/xen/arch/x86/irq.c=0A@@ -1816,7 +1816,7 @@ static inline bool_t =
is_free_pirq(const =0A         pirq->arch.hvm.emuirq =3D=3D IRQ_UNBOUND));=
=0A }=0A =0A-int get_free_pirq(struct domain *d, int type, int index)=0A+in=
t get_free_pirq(struct domain *d, int type)=0A {=0A     int i;=0A =0A--- =
a/xen/arch/x86/physdev.c=0A+++ b/xen/arch/x86/physdev.c=0A@@ -71,7 +71,7 =
@@ static int physdev_hvm_map_pirq(=0A         else=0A         {=0A        =
     if ( *pirq < 0 )=0A-                *pirq =3D get_free_pirq(d, type, =
*index);=0A+                *pirq =3D get_free_pirq(d, type);=0A           =
  ret =3D map_domain_emuirq_pirq(d, *pirq, *index);=0A         }=0A        =
 break;=0A@@ -187,7 +187,7 @@ int physdev_map_pirq(domid_t domid, int =0A  =
       }=0A         else=0A         {=0A-            pirq =3D get_free_pirq=
(d, type, *index);=0A+            pirq =3D get_free_pirq(d, type);=0A      =
       if ( pirq < 0 )=0A             {=0A                 dprintk(XENLOG_G=
_ERR, "dom%d: no free pirq\n", d->domain_id);=0A@@ -705,7 +705,7 @@ ret_t =
do_physdev_op(int cmd, XEN_GUEST_H=0A             break;=0A =0A         =
spin_lock(&d->event_lock);=0A-        ret =3D get_free_pirq(d, out.type, =
0);=0A+        ret =3D get_free_pirq(d, out.type);=0A         if ( ret =
>=3D 0 )=0A         {=0A             struct pirq *info =3D pirq_get_info(d,=
 ret);=0A--- a/xen/include/asm-x86/irq.h=0A+++ b/xen/include/asm-x86/irq.h=
=0A@@ -136,7 +136,7 @@ int pirq_shared(struct domain *d , int i=0A int =
map_domain_pirq(struct domain *d, int pirq, int irq, int type,=0A          =
                  void *data);=0A int unmap_domain_pirq(struct domain *d, =
int pirq);=0A-int get_free_pirq(struct domain *d, int type, int index);=0A+=
int get_free_pirq(struct domain *d, int type);=0A void free_domain_pirqs(st=
ruct domain *d);=0A int map_domain_emuirq_pirq(struct domain *d, int pirq, =
int irq);=0A int unmap_domain_pirq_emuirq(struct domain *d, int pirq);=0A
--=__PartB988A382.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

--=__PartB988A382.0__=--


From xen-devel-bounces@lists.xen.org Wed Sep 05 12:24:25 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Sep 2012 12:24:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9EeJ-00035L-MV; Wed, 05 Sep 2012 12:24: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 1T9EeI-00035D-97
	for xen-devel@lists.xen.org; Wed, 05 Sep 2012 12:24:02 +0000
Received: from [85.158.143.99:27199] by server-3.bemta-4.messagelabs.com id
	65/7C-08232-16447405; Wed, 05 Sep 2012 12:24:01 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1346847837!22273977!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQwMzE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11469 invoked from network); 5 Sep 2012 12:24:00 -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;
	5 Sep 2012 12:24:00 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 05 Sep 2012 13:23:57 +0100
Message-Id: <504760B20200007800098D6C@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 05 Sep 2012 13:24:50 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__PartB988A382.0__="
Subject: [Xen-devel] [PATCH 1/2] x86: drop "index" parameter from
	get_free_pirq()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<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.

--=__PartB988A382.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

It's unused.

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

--- a/xen/arch/x86/irq.c
+++ b/xen/arch/x86/irq.c
@@ -1816,7 +1816,7 @@ static inline bool_t is_free_pirq(const=20
         pirq->arch.hvm.emuirq =3D=3D IRQ_UNBOUND));
 }
=20
-int get_free_pirq(struct domain *d, int type, int index)
+int get_free_pirq(struct domain *d, int type)
 {
     int i;
=20
--- a/xen/arch/x86/physdev.c
+++ b/xen/arch/x86/physdev.c
@@ -71,7 +71,7 @@ static int physdev_hvm_map_pirq(
         else
         {
             if ( *pirq < 0 )
-                *pirq =3D get_free_pirq(d, type, *index);
+                *pirq =3D get_free_pirq(d, type);
             ret =3D map_domain_emuirq_pirq(d, *pirq, *index);
         }
         break;
@@ -187,7 +187,7 @@ int physdev_map_pirq(domid_t domid, int=20
         }
         else
         {
-            pirq =3D get_free_pirq(d, type, *index);
+            pirq =3D get_free_pirq(d, type);
             if ( pirq < 0 )
             {
                 dprintk(XENLOG_G_ERR, "dom%d: no free pirq\n", d->domain_i=
d);
@@ -705,7 +705,7 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_H
             break;
=20
         spin_lock(&d->event_lock);
-        ret =3D get_free_pirq(d, out.type, 0);
+        ret =3D get_free_pirq(d, out.type);
         if ( ret >=3D 0 )
         {
             struct pirq *info =3D pirq_get_info(d, ret);
--- a/xen/include/asm-x86/irq.h
+++ b/xen/include/asm-x86/irq.h
@@ -136,7 +136,7 @@ int pirq_shared(struct domain *d , int i
 int map_domain_pirq(struct domain *d, int pirq, int irq, int type,
                            void *data);
 int unmap_domain_pirq(struct domain *d, int pirq);
-int get_free_pirq(struct domain *d, int type, int index);
+int get_free_pirq(struct domain *d, int type);
 void free_domain_pirqs(struct domain *d);
 int map_domain_emuirq_pirq(struct domain *d, int pirq, int irq);
 int unmap_domain_pirq_emuirq(struct domain *d, int pirq);




--=__PartB988A382.0__=
Content-Type: text/plain; name="x86-get_free_pirq-drop-index.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="x86-get_free_pirq-drop-index.patch"

x86: drop "index" parameter from get_free_pirq()=0A=0AIt's unused.=0A=0ASig=
ned-off-by: Jan Beulich <jbeulich@suse.com>=0A=0A--- a/xen/arch/x86/irq.c=
=0A+++ b/xen/arch/x86/irq.c=0A@@ -1816,7 +1816,7 @@ static inline bool_t =
is_free_pirq(const =0A         pirq->arch.hvm.emuirq =3D=3D IRQ_UNBOUND));=
=0A }=0A =0A-int get_free_pirq(struct domain *d, int type, int index)=0A+in=
t get_free_pirq(struct domain *d, int type)=0A {=0A     int i;=0A =0A--- =
a/xen/arch/x86/physdev.c=0A+++ b/xen/arch/x86/physdev.c=0A@@ -71,7 +71,7 =
@@ static int physdev_hvm_map_pirq(=0A         else=0A         {=0A        =
     if ( *pirq < 0 )=0A-                *pirq =3D get_free_pirq(d, type, =
*index);=0A+                *pirq =3D get_free_pirq(d, type);=0A           =
  ret =3D map_domain_emuirq_pirq(d, *pirq, *index);=0A         }=0A        =
 break;=0A@@ -187,7 +187,7 @@ int physdev_map_pirq(domid_t domid, int =0A  =
       }=0A         else=0A         {=0A-            pirq =3D get_free_pirq=
(d, type, *index);=0A+            pirq =3D get_free_pirq(d, type);=0A      =
       if ( pirq < 0 )=0A             {=0A                 dprintk(XENLOG_G=
_ERR, "dom%d: no free pirq\n", d->domain_id);=0A@@ -705,7 +705,7 @@ ret_t =
do_physdev_op(int cmd, XEN_GUEST_H=0A             break;=0A =0A         =
spin_lock(&d->event_lock);=0A-        ret =3D get_free_pirq(d, out.type, =
0);=0A+        ret =3D get_free_pirq(d, out.type);=0A         if ( ret =
>=3D 0 )=0A         {=0A             struct pirq *info =3D pirq_get_info(d,=
 ret);=0A--- a/xen/include/asm-x86/irq.h=0A+++ b/xen/include/asm-x86/irq.h=
=0A@@ -136,7 +136,7 @@ int pirq_shared(struct domain *d , int i=0A int =
map_domain_pirq(struct domain *d, int pirq, int irq, int type,=0A          =
                  void *data);=0A int unmap_domain_pirq(struct domain *d, =
int pirq);=0A-int get_free_pirq(struct domain *d, int type, int index);=0A+=
int get_free_pirq(struct domain *d, int type);=0A void free_domain_pirqs(st=
ruct domain *d);=0A int map_domain_emuirq_pirq(struct domain *d, int pirq, =
int irq);=0A int unmap_domain_pirq_emuirq(struct domain *d, int pirq);=0A
--=__PartB988A382.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

--=__PartB988A382.0__=--


From xen-devel-bounces@lists.xen.org Wed Sep 05 12:25:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Sep 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 1T9Ef3-00038s-4E; Wed, 05 Sep 2012 12:24: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 1T9Ef1-00038l-JJ
	for xen-devel@lists.xen.org; Wed, 05 Sep 2012 12:24:47 +0000
Received: from [85.158.143.99:58632] by server-3.bemta-4.messagelabs.com id
	9F/DD-08232-E8447405; Wed, 05 Sep 2012 12:24:46 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1346847885!21135627!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQwMzE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24383 invoked from network); 5 Sep 2012 12:24:46 -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;
	5 Sep 2012 12:24:46 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 05 Sep 2012 13:24:46 +0100
Message-Id: <504760D00200007800098D70@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 05 Sep 2012 13:25:20 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part9BAA81A0.0__="
Subject: [Xen-devel] [PATCH 2/2] x86: fix RCU locking in
	PHYSDEVOP_get_free_pirq
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<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.

--=__Part9BAA81A0.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Apart from properly pairing locks with unlocks, also reduce the lock
scope - no need to do the copy_{from,to}_guest()-s inside the protected
region.

I actually wonder whether the RCU locks are needed here at all.

Reported-by: Tim Deegan <tim@xen.org>
Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/arch/x86/physdev.c
+++ b/xen/arch/x86/physdev.c
@@ -698,13 +698,13 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_H
         struct physdev_get_free_pirq out;
         struct domain *d;
=20
-        d =3D rcu_lock_current_domain();
-       =20
         ret =3D -EFAULT;
         if ( copy_from_guest(&out, arg, 1) !=3D 0 )
             break;
=20
+        d =3D rcu_lock_current_domain();
         spin_lock(&d->event_lock);
+
         ret =3D get_free_pirq(d, out.type);
         if ( ret >=3D 0 )
         {
@@ -715,7 +715,9 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_H
             else
                 ret =3D -ENOMEM;
         }
+
         spin_unlock(&d->event_lock);
+        rcu_unlock_domain(d);
=20
         if ( ret >=3D 0 )
         {
@@ -723,7 +725,6 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_H
             ret =3D copy_to_guest(arg, &out, 1) ? -EFAULT : 0;
         }
=20
-        rcu_unlock_domain(d);
         break;
     }
     default:




--=__Part9BAA81A0.0__=
Content-Type: text/plain; name="x86-get_free_pirq-rcu.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="x86-get_free_pirq-rcu.patch"

x86: fix RCU locking in PHYSDEVOP_get_free_pirq=0A=0AApart from properly =
pairing locks with unlocks, also reduce the lock=0Ascope - no need to do =
the copy_{from,to}_guest()-s inside the protected=0Aregion.=0A=0AI =
actually wonder whether the RCU locks are needed here at all.=0A=0AReported=
-by: Tim Deegan <tim@xen.org>=0ASigned-off-by: Jan Beulich <jbeulich@suse.c=
om>=0A=0A--- a/xen/arch/x86/physdev.c=0A+++ b/xen/arch/x86/physdev.c=0A@@ =
-698,13 +698,13 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_H=0A         =
struct physdev_get_free_pirq out;=0A         struct domain *d;=0A =0A-     =
   d =3D rcu_lock_current_domain();=0A-        =0A         ret =3D =
-EFAULT;=0A         if ( copy_from_guest(&out, arg, 1) !=3D 0 )=0A         =
    break;=0A =0A+        d =3D rcu_lock_current_domain();=0A         =
spin_lock(&d->event_lock);=0A+=0A         ret =3D get_free_pirq(d, =
out.type);=0A         if ( ret >=3D 0 )=0A         {=0A@@ -715,7 +715,9 @@ =
ret_t do_physdev_op(int cmd, XEN_GUEST_H=0A             else=0A            =
     ret =3D -ENOMEM;=0A         }=0A+=0A         spin_unlock(&d->event_loc=
k);=0A+        rcu_unlock_domain(d);=0A =0A         if ( ret >=3D 0 )=0A   =
      {=0A@@ -723,7 +725,6 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_H=0A  =
           ret =3D copy_to_guest(arg, &out, 1) ? -EFAULT : 0;=0A         =
}=0A =0A-        rcu_unlock_domain(d);=0A         break;=0A     }=0A     =
default:=0A
--=__Part9BAA81A0.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

--=__Part9BAA81A0.0__=--


From xen-devel-bounces@lists.xen.org Wed Sep 05 12:25:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Sep 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 1T9Ef3-00038s-4E; Wed, 05 Sep 2012 12:24: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 1T9Ef1-00038l-JJ
	for xen-devel@lists.xen.org; Wed, 05 Sep 2012 12:24:47 +0000
Received: from [85.158.143.99:58632] by server-3.bemta-4.messagelabs.com id
	9F/DD-08232-E8447405; Wed, 05 Sep 2012 12:24:46 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1346847885!21135627!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQwMzE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24383 invoked from network); 5 Sep 2012 12:24:46 -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;
	5 Sep 2012 12:24:46 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 05 Sep 2012 13:24:46 +0100
Message-Id: <504760D00200007800098D70@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 05 Sep 2012 13:25:20 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part9BAA81A0.0__="
Subject: [Xen-devel] [PATCH 2/2] x86: fix RCU locking in
	PHYSDEVOP_get_free_pirq
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<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.

--=__Part9BAA81A0.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Apart from properly pairing locks with unlocks, also reduce the lock
scope - no need to do the copy_{from,to}_guest()-s inside the protected
region.

I actually wonder whether the RCU locks are needed here at all.

Reported-by: Tim Deegan <tim@xen.org>
Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/arch/x86/physdev.c
+++ b/xen/arch/x86/physdev.c
@@ -698,13 +698,13 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_H
         struct physdev_get_free_pirq out;
         struct domain *d;
=20
-        d =3D rcu_lock_current_domain();
-       =20
         ret =3D -EFAULT;
         if ( copy_from_guest(&out, arg, 1) !=3D 0 )
             break;
=20
+        d =3D rcu_lock_current_domain();
         spin_lock(&d->event_lock);
+
         ret =3D get_free_pirq(d, out.type);
         if ( ret >=3D 0 )
         {
@@ -715,7 +715,9 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_H
             else
                 ret =3D -ENOMEM;
         }
+
         spin_unlock(&d->event_lock);
+        rcu_unlock_domain(d);
=20
         if ( ret >=3D 0 )
         {
@@ -723,7 +725,6 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_H
             ret =3D copy_to_guest(arg, &out, 1) ? -EFAULT : 0;
         }
=20
-        rcu_unlock_domain(d);
         break;
     }
     default:




--=__Part9BAA81A0.0__=
Content-Type: text/plain; name="x86-get_free_pirq-rcu.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="x86-get_free_pirq-rcu.patch"

x86: fix RCU locking in PHYSDEVOP_get_free_pirq=0A=0AApart from properly =
pairing locks with unlocks, also reduce the lock=0Ascope - no need to do =
the copy_{from,to}_guest()-s inside the protected=0Aregion.=0A=0AI =
actually wonder whether the RCU locks are needed here at all.=0A=0AReported=
-by: Tim Deegan <tim@xen.org>=0ASigned-off-by: Jan Beulich <jbeulich@suse.c=
om>=0A=0A--- a/xen/arch/x86/physdev.c=0A+++ b/xen/arch/x86/physdev.c=0A@@ =
-698,13 +698,13 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_H=0A         =
struct physdev_get_free_pirq out;=0A         struct domain *d;=0A =0A-     =
   d =3D rcu_lock_current_domain();=0A-        =0A         ret =3D =
-EFAULT;=0A         if ( copy_from_guest(&out, arg, 1) !=3D 0 )=0A         =
    break;=0A =0A+        d =3D rcu_lock_current_domain();=0A         =
spin_lock(&d->event_lock);=0A+=0A         ret =3D get_free_pirq(d, =
out.type);=0A         if ( ret >=3D 0 )=0A         {=0A@@ -715,7 +715,9 @@ =
ret_t do_physdev_op(int cmd, XEN_GUEST_H=0A             else=0A            =
     ret =3D -ENOMEM;=0A         }=0A+=0A         spin_unlock(&d->event_loc=
k);=0A+        rcu_unlock_domain(d);=0A =0A         if ( ret >=3D 0 )=0A   =
      {=0A@@ -723,7 +725,6 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_H=0A  =
           ret =3D copy_to_guest(arg, &out, 1) ? -EFAULT : 0;=0A         =
}=0A =0A-        rcu_unlock_domain(d);=0A         break;=0A     }=0A     =
default:=0A
--=__Part9BAA81A0.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

--=__Part9BAA81A0.0__=--


From xen-devel-bounces@lists.xen.org Wed Sep 05 12:29:50 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Sep 2012 12: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 1T9Ejg-0003X6-Gt; Wed, 05 Sep 2012 12:29:36 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <lists+xen@internecto.net>) id 1T9Eje-0003Wq-UN
	for xen-devel@lists.xen.org; Wed, 05 Sep 2012 12:29:35 +0000
Received: from [85.158.139.83:46048] by server-12.bemta-5.messagelabs.com id
	6D/C8-18300-EA547405; Wed, 05 Sep 2012 12:29:34 +0000
X-Env-Sender: lists+xen@internecto.net
X-Msg-Ref: server-14.tower-182.messagelabs.com!1346848173!24434037!1
X-Originating-IP: [176.9.245.29]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5676 invoked from network); 5 Sep 2012 12:29:33 -0000
Received: from polaris.internecto.net (HELO mx1.internecto.net) (176.9.245.29)
	by server-14.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 5 Sep 2012 12:29:33 -0000
Received: from localhost (localhost [127.0.0.1])
	by mx1.internecto.net (Postfix) with ESMTP id 1BF8CA0086;
	Wed,  5 Sep 2012 12:29:33 +0000 (UTC)
X-Virus-Scanned: Debian amavisd-new at mail.internecto.net
Received: from mx1.internecto.net ([127.0.0.1])
	by localhost (mail.polaris.internecto.net [127.0.0.1]) (amavisd-new,
	port 10024)
	with ESMTP id zUzAdXIgRS3m; Wed,  5 Sep 2012 12:29:32 +0000 (UTC)
Received: from internecto.net (5ED4FDEB.cm-7-5d.dynamic.ziggo.nl
	[94.212.253.235])
	(using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits))
	(Client did not present a certificate)
	(Authenticated sender: lists@internecto.net)
	by mx1.internecto.net (Postfix) with ESMTPSA id 7DD66A0058;
	Wed,  5 Sep 2012 12:29:32 +0000 (UTC)
Date: Wed, 5 Sep 2012 14:29:31 +0200
From: Mark van Dijk <lists+xen@internecto.net>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120905142931.4d8a5109@internecto.net>
In-Reply-To: <1346665360.25864.2.camel@zakaz.uk.xensource.com>
References: <1346665360.25864.2.camel@zakaz.uk.xensource.com>
Organization: Internecto SIS
X-Mailer: Claws Mail 3.8.0 (GTK+ 2.24.10; x86_64-pc-linux-gnu)
Mime-Version: 1.0
Cc: xen-users@lists.xen.org, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [Xen-users] Xen 4.2.0 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

Quoting Ian Campbell's message from 03 sep 2012:
>    * [CHECK] More formally deprecate xm/xend. Manpage patches already
>      in tree. Needs release noting and communication around -rc1 to
>      remind people to test xl. (DONE)

I'm just wondering if it's properly stated somewhere that the 'vfb' line
in a VM's config has been replaced with things like:

vnc=1
vnclisten="0.0.0.0"
vncdisplay="10"

This reminds me of a few things I found with regards to VNC just now,
while testing the upstream qemu with Xen (both master and version
1.1-stable).

1) While the above syntax, it is also possible to have
'vnclisten="0.0.0.0:10"'. They do the same i.e. open a listening VNC
port on port 5910. 

But imho the term vncdisplay is a bit vague. I realise 'display' refers
to a display port. However, I suspect that not everyone understands it
just means the tcp listening port. Perhaps it would be better to just
use the latter and deprecate/remove the vncdisplay line?
'vnclisten="0.0.0.0:10"' is more common anyway, right?

2) With upstream qemu it seems that the highest possible number for both
syntaxes is 99. In other words, it looks like upstream qemu 'suddenly'
enforces the VNC ports to be between 5900 and 5999.

It's just a matter of taste probably but I really dislike this new
restriction. I also dislike using iptables -t nat -j REDIRECT to
redirect another port number to the actual (59xx) VNC port. How do you
guys feel about this?

Oh, just a small disclaimer --  i'm not saying this should all be
settled before 4.2 though it's probably wise to at least state
somewhere that 'the vfb line is deprecated with xl'. And it's all up
to Ian c.s. anyway ;)

-- 
Stay in touch,
Mark van Dijk.                ,---------------------------------
-----------------------------'         Wed Sep 05 12:27 UTC 2012
Today is Pungenday, the 29th day of Bureaucracy in the YOLD 3178

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

From xen-devel-bounces@lists.xen.org Wed Sep 05 12:29:50 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Sep 2012 12: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 1T9Ejg-0003X6-Gt; Wed, 05 Sep 2012 12:29:36 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <lists+xen@internecto.net>) id 1T9Eje-0003Wq-UN
	for xen-devel@lists.xen.org; Wed, 05 Sep 2012 12:29:35 +0000
Received: from [85.158.139.83:46048] by server-12.bemta-5.messagelabs.com id
	6D/C8-18300-EA547405; Wed, 05 Sep 2012 12:29:34 +0000
X-Env-Sender: lists+xen@internecto.net
X-Msg-Ref: server-14.tower-182.messagelabs.com!1346848173!24434037!1
X-Originating-IP: [176.9.245.29]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5676 invoked from network); 5 Sep 2012 12:29:33 -0000
Received: from polaris.internecto.net (HELO mx1.internecto.net) (176.9.245.29)
	by server-14.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 5 Sep 2012 12:29:33 -0000
Received: from localhost (localhost [127.0.0.1])
	by mx1.internecto.net (Postfix) with ESMTP id 1BF8CA0086;
	Wed,  5 Sep 2012 12:29:33 +0000 (UTC)
X-Virus-Scanned: Debian amavisd-new at mail.internecto.net
Received: from mx1.internecto.net ([127.0.0.1])
	by localhost (mail.polaris.internecto.net [127.0.0.1]) (amavisd-new,
	port 10024)
	with ESMTP id zUzAdXIgRS3m; Wed,  5 Sep 2012 12:29:32 +0000 (UTC)
Received: from internecto.net (5ED4FDEB.cm-7-5d.dynamic.ziggo.nl
	[94.212.253.235])
	(using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits))
	(Client did not present a certificate)
	(Authenticated sender: lists@internecto.net)
	by mx1.internecto.net (Postfix) with ESMTPSA id 7DD66A0058;
	Wed,  5 Sep 2012 12:29:32 +0000 (UTC)
Date: Wed, 5 Sep 2012 14:29:31 +0200
From: Mark van Dijk <lists+xen@internecto.net>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120905142931.4d8a5109@internecto.net>
In-Reply-To: <1346665360.25864.2.camel@zakaz.uk.xensource.com>
References: <1346665360.25864.2.camel@zakaz.uk.xensource.com>
Organization: Internecto SIS
X-Mailer: Claws Mail 3.8.0 (GTK+ 2.24.10; x86_64-pc-linux-gnu)
Mime-Version: 1.0
Cc: xen-users@lists.xen.org, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [Xen-users] Xen 4.2.0 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

Quoting Ian Campbell's message from 03 sep 2012:
>    * [CHECK] More formally deprecate xm/xend. Manpage patches already
>      in tree. Needs release noting and communication around -rc1 to
>      remind people to test xl. (DONE)

I'm just wondering if it's properly stated somewhere that the 'vfb' line
in a VM's config has been replaced with things like:

vnc=1
vnclisten="0.0.0.0"
vncdisplay="10"

This reminds me of a few things I found with regards to VNC just now,
while testing the upstream qemu with Xen (both master and version
1.1-stable).

1) While the above syntax, it is also possible to have
'vnclisten="0.0.0.0:10"'. They do the same i.e. open a listening VNC
port on port 5910. 

But imho the term vncdisplay is a bit vague. I realise 'display' refers
to a display port. However, I suspect that not everyone understands it
just means the tcp listening port. Perhaps it would be better to just
use the latter and deprecate/remove the vncdisplay line?
'vnclisten="0.0.0.0:10"' is more common anyway, right?

2) With upstream qemu it seems that the highest possible number for both
syntaxes is 99. In other words, it looks like upstream qemu 'suddenly'
enforces the VNC ports to be between 5900 and 5999.

It's just a matter of taste probably but I really dislike this new
restriction. I also dislike using iptables -t nat -j REDIRECT to
redirect another port number to the actual (59xx) VNC port. How do you
guys feel about this?

Oh, just a small disclaimer --  i'm not saying this should all be
settled before 4.2 though it's probably wise to at least state
somewhere that 'the vfb line is deprecated with xl'. And it's all up
to Ian c.s. anyway ;)

-- 
Stay in touch,
Mark van Dijk.                ,---------------------------------
-----------------------------'         Wed Sep 05 12:27 UTC 2012
Today is Pungenday, the 29th day of Bureaucracy in the YOLD 3178

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

From xen-devel-bounces@lists.xen.org Wed Sep 05 12:29:59 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Sep 2012 12:29: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 1T9Ejs-0003ZQ-QA; Wed, 05 Sep 2012 12:29:48 +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 1T9Ejr-0003Z6-Kj
	for xen-devel@lists.xen.org; Wed, 05 Sep 2012 12:29:47 +0000
Received: from [85.158.139.83:47421] by server-1.bemta-5.messagelabs.com id
	1E/E4-32692-AB547405; Wed, 05 Sep 2012 12:29:46 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1346848184!28473142!1
X-Originating-IP: [65.55.88.12]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1195 invoked from network); 5 Sep 2012 12:29:46 -0000
Received: from tx2ehsobe002.messaging.microsoft.com (HELO
	tx2outboundpool.messaging.microsoft.com) (65.55.88.12)
	by server-5.tower-182.messagelabs.com with AES128-SHA encrypted SMTP;
	5 Sep 2012 12:29:46 -0000
Received: from mail146-tx2-R.bigfish.com (10.9.14.242) by
	TX2EHSOBE003.bigfish.com (10.9.40.23) with Microsoft SMTP Server id
	14.1.225.23; Wed, 5 Sep 2012 12:29:44 +0000
Received: from mail146-tx2 (localhost [127.0.0.1])	by
	mail146-tx2-R.bigfish.com (Postfix) with ESMTP id 1375C2007A;
	Wed,  5 Sep 2012 12:29:44 +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: -6
X-BigFish: VPS-6(zzbb2dI98dI9371I936eI1432I4015Izz1202hzzz2dh668h839hd25he5bhf0ah107ah1155h)
Received: from mail146-tx2 (localhost.localdomain [127.0.0.1]) by mail146-tx2
	(MessageSwitch) id 1346848181907016_4561;
	Wed,  5 Sep 2012 12:29:41 +0000 (UTC)
Received: from TX2EHSMHS021.bigfish.com (unknown [10.9.14.244])	by
	mail146-tx2.bigfish.com (Postfix) with ESMTP id CF6594C0043;
	Wed,  5 Sep 2012 12:29:41 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	TX2EHSMHS021.bigfish.com (10.9.99.121) with Microsoft SMTP Server id
	14.1.225.23; Wed, 5 Sep 2012 12:29:41 +0000
X-WSS-ID: 0M9VMPE-01-5GJ-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 22A201028098;	Wed,  5 Sep 2012 07:29:37 -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, 5 Sep 2012 07:29:50 -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, 5 Sep 2012 07:29:38 -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, 5 Sep 2012
	08:29: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 DA53A49C0D5; Wed,  5 Sep 2012
	13:29:35 +0100 (BST)
Message-ID: <504745F4.5060906@amd.com>
Date: Wed, 5 Sep 2012 14:30: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: Sander Eikelenboom <linux@eikelenboom.it>
References: <40501859.20120902104331@eikelenboom.it>
	<CC6932C2.3D99D%keir.xen@gmail.com>
	<217459398.20120902171441@eikelenboom.it>
	<5044CAD7.8030800@amd.com>
	<1144695277.20120904184345@eikelenboom.it>
In-Reply-To: <1144695277.20120904184345@eikelenboom.it>
X-OriginatorOrg: amd.com
Cc: Keir Fraser <keir.xen@gmail.com>, Jan Beulich <JBeulich@suse.com>,
	Santosh Jodh <Santosh.Jodh@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Using debug-key 'o:  Dump IOMMU p2m table,
 locks up machine
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 09/04/2012 06:43 PM, Sander Eikelenboom wrote:
> Hello Wei,
> >
> Tried it and it doesn't help.
> I now even got a "xl dmesg" which shows a IO_PAGE_FAULT occuring very early, before any toolstack or guest can be involved:
>
> (XEN) [2012-09-04 15:51:17] AMD-Vi: Setup I/O page table: device id = 0x0a05, root table = 0x24d84b000, domain = 0, paging mode = 3
> (XEN) [2012-09-04 15:51:17] AMD-Vi: Setup I/O page table: device id = 0x0a06, root table = 0x24d84b000, domain = 0, paging mode = 3
> (XEN) [2012-09-04 15:51:17] AMD-Vi: Setup I/O page table: device id = 0x0a07, root table = 0x24d84b000, domain = 0, paging mode = 3
> (XEN) [2012-09-04 15:51:17] AMD-Vi: Setup I/O page table: device id = 0x0b00, root table = 0x24d84b000, domain = 0, paging mode = 3
> (XEN) [2012-09-04 15:51:17] Scrubbing Free RAM: ...........................<0>AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0a06, fault address = 0xc2c2c2c0


you have dom0_mem=1024M, so you could try to remove this line any see if 
it disappears. It would also be helpful to provide a lspci output from 
your system.

Thanks,
Wei

> (XEN) [2012-09-04 15:51:18] ............................................done.
> (XEN) [2012-09-04 15:51:19] Initial low memory virq threshold set at 0x4000 pages.
> (XEN) [2012-09-04 15:51:19] Std. Loglevel: All
> (XEN) [2012-09-04 15:51:19] Guest Loglevel: All
> (XEN) [2012-09-04 15:51:19] Xen is relinquishing VGA console.
>
>
> Complete dmesg attached.
>
>> Thanks,
>> Wei
>
>>>>    -- Keir
>>>
>>>>>
>>>>>
>>>>>>    -- Keir
>>>>>
>>>
>>>
>>>
>>>
>>>
>>>
>
>
>
>
>
>



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

From xen-devel-bounces@lists.xen.org Wed Sep 05 12:29:59 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Sep 2012 12:29: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 1T9Ejs-0003ZQ-QA; Wed, 05 Sep 2012 12:29:48 +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 1T9Ejr-0003Z6-Kj
	for xen-devel@lists.xen.org; Wed, 05 Sep 2012 12:29:47 +0000
Received: from [85.158.139.83:47421] by server-1.bemta-5.messagelabs.com id
	1E/E4-32692-AB547405; Wed, 05 Sep 2012 12:29:46 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1346848184!28473142!1
X-Originating-IP: [65.55.88.12]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1195 invoked from network); 5 Sep 2012 12:29:46 -0000
Received: from tx2ehsobe002.messaging.microsoft.com (HELO
	tx2outboundpool.messaging.microsoft.com) (65.55.88.12)
	by server-5.tower-182.messagelabs.com with AES128-SHA encrypted SMTP;
	5 Sep 2012 12:29:46 -0000
Received: from mail146-tx2-R.bigfish.com (10.9.14.242) by
	TX2EHSOBE003.bigfish.com (10.9.40.23) with Microsoft SMTP Server id
	14.1.225.23; Wed, 5 Sep 2012 12:29:44 +0000
Received: from mail146-tx2 (localhost [127.0.0.1])	by
	mail146-tx2-R.bigfish.com (Postfix) with ESMTP id 1375C2007A;
	Wed,  5 Sep 2012 12:29:44 +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: -6
X-BigFish: VPS-6(zzbb2dI98dI9371I936eI1432I4015Izz1202hzzz2dh668h839hd25he5bhf0ah107ah1155h)
Received: from mail146-tx2 (localhost.localdomain [127.0.0.1]) by mail146-tx2
	(MessageSwitch) id 1346848181907016_4561;
	Wed,  5 Sep 2012 12:29:41 +0000 (UTC)
Received: from TX2EHSMHS021.bigfish.com (unknown [10.9.14.244])	by
	mail146-tx2.bigfish.com (Postfix) with ESMTP id CF6594C0043;
	Wed,  5 Sep 2012 12:29:41 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	TX2EHSMHS021.bigfish.com (10.9.99.121) with Microsoft SMTP Server id
	14.1.225.23; Wed, 5 Sep 2012 12:29:41 +0000
X-WSS-ID: 0M9VMPE-01-5GJ-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 22A201028098;	Wed,  5 Sep 2012 07:29:37 -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, 5 Sep 2012 07:29:50 -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, 5 Sep 2012 07:29:38 -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, 5 Sep 2012
	08:29: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 DA53A49C0D5; Wed,  5 Sep 2012
	13:29:35 +0100 (BST)
Message-ID: <504745F4.5060906@amd.com>
Date: Wed, 5 Sep 2012 14:30: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: Sander Eikelenboom <linux@eikelenboom.it>
References: <40501859.20120902104331@eikelenboom.it>
	<CC6932C2.3D99D%keir.xen@gmail.com>
	<217459398.20120902171441@eikelenboom.it>
	<5044CAD7.8030800@amd.com>
	<1144695277.20120904184345@eikelenboom.it>
In-Reply-To: <1144695277.20120904184345@eikelenboom.it>
X-OriginatorOrg: amd.com
Cc: Keir Fraser <keir.xen@gmail.com>, Jan Beulich <JBeulich@suse.com>,
	Santosh Jodh <Santosh.Jodh@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Using debug-key 'o:  Dump IOMMU p2m table,
 locks up machine
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 09/04/2012 06:43 PM, Sander Eikelenboom wrote:
> Hello Wei,
> >
> Tried it and it doesn't help.
> I now even got a "xl dmesg" which shows a IO_PAGE_FAULT occuring very early, before any toolstack or guest can be involved:
>
> (XEN) [2012-09-04 15:51:17] AMD-Vi: Setup I/O page table: device id = 0x0a05, root table = 0x24d84b000, domain = 0, paging mode = 3
> (XEN) [2012-09-04 15:51:17] AMD-Vi: Setup I/O page table: device id = 0x0a06, root table = 0x24d84b000, domain = 0, paging mode = 3
> (XEN) [2012-09-04 15:51:17] AMD-Vi: Setup I/O page table: device id = 0x0a07, root table = 0x24d84b000, domain = 0, paging mode = 3
> (XEN) [2012-09-04 15:51:17] AMD-Vi: Setup I/O page table: device id = 0x0b00, root table = 0x24d84b000, domain = 0, paging mode = 3
> (XEN) [2012-09-04 15:51:17] Scrubbing Free RAM: ...........................<0>AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0a06, fault address = 0xc2c2c2c0


you have dom0_mem=1024M, so you could try to remove this line any see if 
it disappears. It would also be helpful to provide a lspci output from 
your system.

Thanks,
Wei

> (XEN) [2012-09-04 15:51:18] ............................................done.
> (XEN) [2012-09-04 15:51:19] Initial low memory virq threshold set at 0x4000 pages.
> (XEN) [2012-09-04 15:51:19] Std. Loglevel: All
> (XEN) [2012-09-04 15:51:19] Guest Loglevel: All
> (XEN) [2012-09-04 15:51:19] Xen is relinquishing VGA console.
>
>
> Complete dmesg attached.
>
>> Thanks,
>> Wei
>
>>>>    -- Keir
>>>
>>>>>
>>>>>
>>>>>>    -- Keir
>>>>>
>>>
>>>
>>>
>>>
>>>
>>>
>
>
>
>
>
>



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

From xen-devel-bounces@lists.xen.org Wed Sep 05 12:32:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Sep 2012 12:32:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9EmZ-00041x-DV; Wed, 05 Sep 2012 12:32:35 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1T9EmY-00041f-0G
	for xen-devel@lists.xen.org; Wed, 05 Sep 2012 12:32:34 +0000
Received: from [85.158.143.35:42861] by server-1.bemta-4.messagelabs.com id
	39/9B-12504-16647405; Wed, 05 Sep 2012 12:32:33 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1346848352!12334042!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQwMzE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29926 invoked from network); 5 Sep 2012 12:32:32 -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;
	5 Sep 2012 12:32:32 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 05 Sep 2012 13:32:33 +0100
Message-Id: <504762B50200007800098D92@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 05 Sep 2012 13:33:25 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
Mime-Version: 1.0
Content-Disposition: inline
Cc: dan.magenheimer@oracle.com, Zhenzhong Duan <zhenzhong.duan@oracle.com>
Subject: [Xen-devel] [PATCH 00/11] various tmem adjustments (mostly XSA-15
	related)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

01: tmem: only allow tmem control operations from privileged domains
02: tmem: consistently make pool_id a uint32_t
03: tmem: check the pool_id is valid when destroying a tmem pool
04: tmem: check for a valid client ("domain") in the save subops
05: tmem: don't access guest memory without using the accessors intended for this
06: tmem: detect arithmetic overflow in tmh_copy_{from,to}_client()
07: tmem: properly drop lock on error path in do_tmem_get()
08: tmem: properly drop lock on error path in do_tmem_op()
09: tmem: reduce severity of log messages
10: tmem: fixup 2010 cleanup patch that breaks tmem save/restore
11: tmem: cleanup


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

From xen-devel-bounces@lists.xen.org Wed Sep 05 12:32:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Sep 2012 12:32:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9EmZ-00041x-DV; Wed, 05 Sep 2012 12:32:35 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1T9EmY-00041f-0G
	for xen-devel@lists.xen.org; Wed, 05 Sep 2012 12:32:34 +0000
Received: from [85.158.143.35:42861] by server-1.bemta-4.messagelabs.com id
	39/9B-12504-16647405; Wed, 05 Sep 2012 12:32:33 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1346848352!12334042!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQwMzE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29926 invoked from network); 5 Sep 2012 12:32:32 -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;
	5 Sep 2012 12:32:32 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 05 Sep 2012 13:32:33 +0100
Message-Id: <504762B50200007800098D92@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 05 Sep 2012 13:33:25 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
Mime-Version: 1.0
Content-Disposition: inline
Cc: dan.magenheimer@oracle.com, Zhenzhong Duan <zhenzhong.duan@oracle.com>
Subject: [Xen-devel] [PATCH 00/11] various tmem adjustments (mostly XSA-15
	related)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

01: tmem: only allow tmem control operations from privileged domains
02: tmem: consistently make pool_id a uint32_t
03: tmem: check the pool_id is valid when destroying a tmem pool
04: tmem: check for a valid client ("domain") in the save subops
05: tmem: don't access guest memory without using the accessors intended for this
06: tmem: detect arithmetic overflow in tmh_copy_{from,to}_client()
07: tmem: properly drop lock on error path in do_tmem_get()
08: tmem: properly drop lock on error path in do_tmem_op()
09: tmem: reduce severity of log messages
10: tmem: fixup 2010 cleanup patch that breaks tmem save/restore
11: tmem: cleanup


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

From xen-devel-bounces@lists.xen.org Wed Sep 05 12:33:19 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Sep 2012 12:33:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9En6-00048q-RQ; Wed, 05 Sep 2012 12:33: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 1T9En6-00048d-8d
	for xen-devel@lists.xen.org; Wed, 05 Sep 2012 12:33:08 +0000
Received: from [85.158.143.35:44007] by server-3.bemta-4.messagelabs.com id
	15/3E-08232-38647405; Wed, 05 Sep 2012 12:33:07 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1346848386!13409840!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQwMzE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11237 invoked from network); 5 Sep 2012 12:33:07 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-3.tower-21.messagelabs.com with SMTP;
	5 Sep 2012 12:33:07 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 05 Sep 2012 13:33:07 +0100
Message-Id: <504762D80200007800098D95@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 05 Sep 2012 13:34:00 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
Mime-Version: 1.0
Content-Disposition: inline
Cc: dan.magenheimer@oracle.com, Zhenzhong Duan <zhenzhong.duan@oracle.com>
Subject: [Xen-devel] [PATCH 01/11] tmem: only allow tmem control operations
 from privileged 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

This is part of XSA-15 / CVE-2012-3497.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/common/tmem.c
+++ b/xen/common/tmem.c
@@ -2541,10 +2541,8 @@ static NOINLINE int do_tmem_control(stru
     OID *oidp = (OID *)(&op->u.ctrl.oid[0]);
 
     if (!tmh_current_is_privileged())
-    {
-        /* don't fail... mystery: sometimes dom0 fails here */
-        /* return -EPERM; */
-    }
+        return -EPERM;
+
     switch(subop)
     {
     case TMEMC_THAW:




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

From xen-devel-bounces@lists.xen.org Wed Sep 05 12:33:19 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Sep 2012 12:33:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9En6-00048q-RQ; Wed, 05 Sep 2012 12:33: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 1T9En6-00048d-8d
	for xen-devel@lists.xen.org; Wed, 05 Sep 2012 12:33:08 +0000
Received: from [85.158.143.35:44007] by server-3.bemta-4.messagelabs.com id
	15/3E-08232-38647405; Wed, 05 Sep 2012 12:33:07 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1346848386!13409840!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQwMzE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11237 invoked from network); 5 Sep 2012 12:33:07 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-3.tower-21.messagelabs.com with SMTP;
	5 Sep 2012 12:33:07 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 05 Sep 2012 13:33:07 +0100
Message-Id: <504762D80200007800098D95@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 05 Sep 2012 13:34:00 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
Mime-Version: 1.0
Content-Disposition: inline
Cc: dan.magenheimer@oracle.com, Zhenzhong Duan <zhenzhong.duan@oracle.com>
Subject: [Xen-devel] [PATCH 01/11] tmem: only allow tmem control operations
 from privileged 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

This is part of XSA-15 / CVE-2012-3497.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/common/tmem.c
+++ b/xen/common/tmem.c
@@ -2541,10 +2541,8 @@ static NOINLINE int do_tmem_control(stru
     OID *oidp = (OID *)(&op->u.ctrl.oid[0]);
 
     if (!tmh_current_is_privileged())
-    {
-        /* don't fail... mystery: sometimes dom0 fails here */
-        /* return -EPERM; */
-    }
+        return -EPERM;
+
     switch(subop)
     {
     case TMEMC_THAW:




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

From xen-devel-bounces@lists.xen.org Wed Sep 05 12:33:55 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Sep 2012 12:33:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9Enh-0004Fb-8u; Wed, 05 Sep 2012 12:33: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 1T9Enf-0004FD-E9
	for xen-devel@lists.xen.org; Wed, 05 Sep 2012 12:33:43 +0000
Received: from [85.158.143.35:51678] by server-1.bemta-4.messagelabs.com id
	3C/0E-12504-5A647405; Wed, 05 Sep 2012 12:33:41 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1346848417!12334316!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQwMzE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2268 invoked from network); 5 Sep 2012 12:33:37 -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;
	5 Sep 2012 12:33:37 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 05 Sep 2012 13:33:38 +0100
Message-Id: <504762F60200007800098D99@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 05 Sep 2012 13:34:30 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__PartFFCEE5C6.0__="
Cc: dan.magenheimer@oracle.com, Zhenzhong Duan <zhenzhong.duan@oracle.com>
Subject: [Xen-devel] [PATCH 02/11] tmem: consistently make pool_id a uint32_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

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.

--=__PartFFCEE5C6.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Treating it as an int could allow a malicious guest to provide a
negative pool_Id, by passing the MAX_POOLS_PER_DOMAIN limit check and
allowing access to the negative offsets of the pool array.

This is part of XSA-15 / CVE-2012-3497.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/common/tmem.c
+++ b/xen/common/tmem.c
@@ -2417,7 +2417,7 @@ static NOINLINE int tmemc_save_subop(int
     return rc;
 }
=20
-static NOINLINE int tmemc_save_get_next_page(int cli_id, int pool_id,
+static NOINLINE int tmemc_save_get_next_page(int cli_id, uint32_t =
pool_id,
                         tmem_cli_va_t buf, uint32_t bufsize)
 {
     client_t *client =3D tmh_client_from_cli_id(cli_id);
@@ -2509,7 +2509,7 @@ out:
     return ret;
 }
=20
-static int tmemc_restore_put_page(int cli_id, int pool_id, OID *oidp,
+static int tmemc_restore_put_page(int cli_id, uint32_t pool_id, OID =
*oidp,
                       uint32_t index, tmem_cli_va_t buf, uint32_t =
bufsize)
 {
     client_t *client =3D tmh_client_from_cli_id(cli_id);
@@ -2521,7 +2521,7 @@ static int tmemc_restore_put_page(int cl
     return do_tmem_put(pool,oidp,index,0,0,0,bufsize,buf.p);
 }
=20
-static int tmemc_restore_flush_page(int cli_id, int pool_id, OID *oidp,
+static int tmemc_restore_flush_page(int cli_id, uint32_t pool_id, OID =
*oidp,
                         uint32_t index)
 {
     client_t *client =3D tmh_client_from_cli_id(cli_id);




--=__PartFFCEE5C6.0__=
Content-Type: application/octet-stream; name="tmem-xsa-15-2"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="tmem-xsa-15-2"

dG1lbTogY29uc2lzdGVudGx5IG1ha2UgcG9vbF9pZCBhIHVpbnQzMl90CgpUcmVhdGluZyBpdCBh
cyBhbiBpbnQgY291bGQgYWxsb3cgYSBtYWxpY2lvdXMgZ3Vlc3QgdG8gcHJvdmlkZSBhCm5lZ2F0
aXZlIHBvb2xfSWQsIGJ5IHBhc3NpbmcgdGhlIE1BWF9QT09MU19QRVJfRE9NQUlOIGxpbWl0IGNo
ZWNrIGFuZAphbGxvd2luZyBhY2Nlc3MgdG8gdGhlIG5lZ2F0aXZlIG9mZnNldHMgb2YgdGhlIHBv
b2wgYXJyYXkuCgpUaGlzIGlzIHBhcnQgb2YgWFNBLTE1IC8gQ1ZFLTIwMTItMzQ5Ny4KClNpZ25l
ZC1vZmYtYnk6IElhbiBDYW1wYmVsbCA8aWFuLmNhbXBiZWxsQGNpdHJpeC5jb20+CkFja2VkLWJ5
OiBKYW4gQmV1bGljaCA8amJldWxpY2hAc3VzZS5jb20+CgotLS0gYS94ZW4vY29tbW9uL3RtZW0u
YworKysgYi94ZW4vY29tbW9uL3RtZW0uYwpAQCAtMjQxNyw3ICsyNDE3LDcgQEAgc3RhdGljIE5P
SU5MSU5FIGludCB0bWVtY19zYXZlX3N1Ym9wKGludAogICAgIHJldHVybiByYzsKIH0KIAotc3Rh
dGljIE5PSU5MSU5FIGludCB0bWVtY19zYXZlX2dldF9uZXh0X3BhZ2UoaW50IGNsaV9pZCwgaW50
IHBvb2xfaWQsCitzdGF0aWMgTk9JTkxJTkUgaW50IHRtZW1jX3NhdmVfZ2V0X25leHRfcGFnZShp
bnQgY2xpX2lkLCB1aW50MzJfdCBwb29sX2lkLAogICAgICAgICAgICAgICAgICAgICAgICAgdG1l
bV9jbGlfdmFfdCBidWYsIHVpbnQzMl90IGJ1ZnNpemUpCiB7CiAgICAgY2xpZW50X3QgKmNsaWVu
dCA9IHRtaF9jbGllbnRfZnJvbV9jbGlfaWQoY2xpX2lkKTsKQEAgLTI1MDksNyArMjUwOSw3IEBA
IG91dDoKICAgICByZXR1cm4gcmV0OwogfQogCi1zdGF0aWMgaW50IHRtZW1jX3Jlc3RvcmVfcHV0
X3BhZ2UoaW50IGNsaV9pZCwgaW50IHBvb2xfaWQsIE9JRCAqb2lkcCwKK3N0YXRpYyBpbnQgdG1l
bWNfcmVzdG9yZV9wdXRfcGFnZShpbnQgY2xpX2lkLCB1aW50MzJfdCBwb29sX2lkLCBPSUQgKm9p
ZHAsCiAgICAgICAgICAgICAgICAgICAgICAgdWludDMyX3QgaW5kZXgsIHRtZW1fY2xpX3ZhX3Qg
YnVmLCB1aW50MzJfdCBidWZzaXplKQogewogICAgIGNsaWVudF90ICpjbGllbnQgPSB0bWhfY2xp
ZW50X2Zyb21fY2xpX2lkKGNsaV9pZCk7CkBAIC0yNTIxLDcgKzI1MjEsNyBAQCBzdGF0aWMgaW50
IHRtZW1jX3Jlc3RvcmVfcHV0X3BhZ2UoaW50IGNsCiAgICAgcmV0dXJuIGRvX3RtZW1fcHV0KHBv
b2wsb2lkcCxpbmRleCwwLDAsMCxidWZzaXplLGJ1Zi5wKTsKIH0KIAotc3RhdGljIGludCB0bWVt
Y19yZXN0b3JlX2ZsdXNoX3BhZ2UoaW50IGNsaV9pZCwgaW50IHBvb2xfaWQsIE9JRCAqb2lkcCwK
K3N0YXRpYyBpbnQgdG1lbWNfcmVzdG9yZV9mbHVzaF9wYWdlKGludCBjbGlfaWQsIHVpbnQzMl90
IHBvb2xfaWQsIE9JRCAqb2lkcCwKICAgICAgICAgICAgICAgICAgICAgICAgIHVpbnQzMl90IGlu
ZGV4KQogewogICAgIGNsaWVudF90ICpjbGllbnQgPSB0bWhfY2xpZW50X2Zyb21fY2xpX2lkKGNs
aV9pZCk7Cg==

--=__PartFFCEE5C6.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

--=__PartFFCEE5C6.0__=--


From xen-devel-bounces@lists.xen.org Wed Sep 05 12:33:55 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Sep 2012 12:33:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9Enh-0004Fb-8u; Wed, 05 Sep 2012 12:33: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 1T9Enf-0004FD-E9
	for xen-devel@lists.xen.org; Wed, 05 Sep 2012 12:33:43 +0000
Received: from [85.158.143.35:51678] by server-1.bemta-4.messagelabs.com id
	3C/0E-12504-5A647405; Wed, 05 Sep 2012 12:33:41 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1346848417!12334316!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQwMzE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2268 invoked from network); 5 Sep 2012 12:33:37 -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;
	5 Sep 2012 12:33:37 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 05 Sep 2012 13:33:38 +0100
Message-Id: <504762F60200007800098D99@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 05 Sep 2012 13:34:30 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__PartFFCEE5C6.0__="
Cc: dan.magenheimer@oracle.com, Zhenzhong Duan <zhenzhong.duan@oracle.com>
Subject: [Xen-devel] [PATCH 02/11] tmem: consistently make pool_id a uint32_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

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.

--=__PartFFCEE5C6.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Treating it as an int could allow a malicious guest to provide a
negative pool_Id, by passing the MAX_POOLS_PER_DOMAIN limit check and
allowing access to the negative offsets of the pool array.

This is part of XSA-15 / CVE-2012-3497.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/common/tmem.c
+++ b/xen/common/tmem.c
@@ -2417,7 +2417,7 @@ static NOINLINE int tmemc_save_subop(int
     return rc;
 }
=20
-static NOINLINE int tmemc_save_get_next_page(int cli_id, int pool_id,
+static NOINLINE int tmemc_save_get_next_page(int cli_id, uint32_t =
pool_id,
                         tmem_cli_va_t buf, uint32_t bufsize)
 {
     client_t *client =3D tmh_client_from_cli_id(cli_id);
@@ -2509,7 +2509,7 @@ out:
     return ret;
 }
=20
-static int tmemc_restore_put_page(int cli_id, int pool_id, OID *oidp,
+static int tmemc_restore_put_page(int cli_id, uint32_t pool_id, OID =
*oidp,
                       uint32_t index, tmem_cli_va_t buf, uint32_t =
bufsize)
 {
     client_t *client =3D tmh_client_from_cli_id(cli_id);
@@ -2521,7 +2521,7 @@ static int tmemc_restore_put_page(int cl
     return do_tmem_put(pool,oidp,index,0,0,0,bufsize,buf.p);
 }
=20
-static int tmemc_restore_flush_page(int cli_id, int pool_id, OID *oidp,
+static int tmemc_restore_flush_page(int cli_id, uint32_t pool_id, OID =
*oidp,
                         uint32_t index)
 {
     client_t *client =3D tmh_client_from_cli_id(cli_id);




--=__PartFFCEE5C6.0__=
Content-Type: application/octet-stream; name="tmem-xsa-15-2"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="tmem-xsa-15-2"

dG1lbTogY29uc2lzdGVudGx5IG1ha2UgcG9vbF9pZCBhIHVpbnQzMl90CgpUcmVhdGluZyBpdCBh
cyBhbiBpbnQgY291bGQgYWxsb3cgYSBtYWxpY2lvdXMgZ3Vlc3QgdG8gcHJvdmlkZSBhCm5lZ2F0
aXZlIHBvb2xfSWQsIGJ5IHBhc3NpbmcgdGhlIE1BWF9QT09MU19QRVJfRE9NQUlOIGxpbWl0IGNo
ZWNrIGFuZAphbGxvd2luZyBhY2Nlc3MgdG8gdGhlIG5lZ2F0aXZlIG9mZnNldHMgb2YgdGhlIHBv
b2wgYXJyYXkuCgpUaGlzIGlzIHBhcnQgb2YgWFNBLTE1IC8gQ1ZFLTIwMTItMzQ5Ny4KClNpZ25l
ZC1vZmYtYnk6IElhbiBDYW1wYmVsbCA8aWFuLmNhbXBiZWxsQGNpdHJpeC5jb20+CkFja2VkLWJ5
OiBKYW4gQmV1bGljaCA8amJldWxpY2hAc3VzZS5jb20+CgotLS0gYS94ZW4vY29tbW9uL3RtZW0u
YworKysgYi94ZW4vY29tbW9uL3RtZW0uYwpAQCAtMjQxNyw3ICsyNDE3LDcgQEAgc3RhdGljIE5P
SU5MSU5FIGludCB0bWVtY19zYXZlX3N1Ym9wKGludAogICAgIHJldHVybiByYzsKIH0KIAotc3Rh
dGljIE5PSU5MSU5FIGludCB0bWVtY19zYXZlX2dldF9uZXh0X3BhZ2UoaW50IGNsaV9pZCwgaW50
IHBvb2xfaWQsCitzdGF0aWMgTk9JTkxJTkUgaW50IHRtZW1jX3NhdmVfZ2V0X25leHRfcGFnZShp
bnQgY2xpX2lkLCB1aW50MzJfdCBwb29sX2lkLAogICAgICAgICAgICAgICAgICAgICAgICAgdG1l
bV9jbGlfdmFfdCBidWYsIHVpbnQzMl90IGJ1ZnNpemUpCiB7CiAgICAgY2xpZW50X3QgKmNsaWVu
dCA9IHRtaF9jbGllbnRfZnJvbV9jbGlfaWQoY2xpX2lkKTsKQEAgLTI1MDksNyArMjUwOSw3IEBA
IG91dDoKICAgICByZXR1cm4gcmV0OwogfQogCi1zdGF0aWMgaW50IHRtZW1jX3Jlc3RvcmVfcHV0
X3BhZ2UoaW50IGNsaV9pZCwgaW50IHBvb2xfaWQsIE9JRCAqb2lkcCwKK3N0YXRpYyBpbnQgdG1l
bWNfcmVzdG9yZV9wdXRfcGFnZShpbnQgY2xpX2lkLCB1aW50MzJfdCBwb29sX2lkLCBPSUQgKm9p
ZHAsCiAgICAgICAgICAgICAgICAgICAgICAgdWludDMyX3QgaW5kZXgsIHRtZW1fY2xpX3ZhX3Qg
YnVmLCB1aW50MzJfdCBidWZzaXplKQogewogICAgIGNsaWVudF90ICpjbGllbnQgPSB0bWhfY2xp
ZW50X2Zyb21fY2xpX2lkKGNsaV9pZCk7CkBAIC0yNTIxLDcgKzI1MjEsNyBAQCBzdGF0aWMgaW50
IHRtZW1jX3Jlc3RvcmVfcHV0X3BhZ2UoaW50IGNsCiAgICAgcmV0dXJuIGRvX3RtZW1fcHV0KHBv
b2wsb2lkcCxpbmRleCwwLDAsMCxidWZzaXplLGJ1Zi5wKTsKIH0KIAotc3RhdGljIGludCB0bWVt
Y19yZXN0b3JlX2ZsdXNoX3BhZ2UoaW50IGNsaV9pZCwgaW50IHBvb2xfaWQsIE9JRCAqb2lkcCwK
K3N0YXRpYyBpbnQgdG1lbWNfcmVzdG9yZV9mbHVzaF9wYWdlKGludCBjbGlfaWQsIHVpbnQzMl90
IHBvb2xfaWQsIE9JRCAqb2lkcCwKICAgICAgICAgICAgICAgICAgICAgICAgIHVpbnQzMl90IGlu
ZGV4KQogewogICAgIGNsaWVudF90ICpjbGllbnQgPSB0bWhfY2xpZW50X2Zyb21fY2xpX2lkKGNs
aV9pZCk7Cg==

--=__PartFFCEE5C6.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

--=__PartFFCEE5C6.0__=--


From xen-devel-bounces@lists.xen.org Wed Sep 05 12:33:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Sep 2012 12: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 1T9Enl-0004GT-Md; Wed, 05 Sep 2012 12:33:49 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1T9Enj-0004FI-Pm
	for xen-devel@lists.xen.org; Wed, 05 Sep 2012 12:33:47 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1346848411!9690454!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-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18346 invoked from network); 5 Sep 2012 12:33:32 -0000
Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com)
	(74.125.83.45)
	by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Sep 2012 12:33:32 -0000
Received: by eeke53 with SMTP id e53so231752eek.32
	for <xen-devel@lists.xen.org>; Wed, 05 Sep 2012 05:33:31 -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=GWFmKfd6hEALCVjz1eqXhj1j7XIcj888ii85ilMQC44=;
	b=nDjcv+Dt4xkcp4XrMenps4kreyc0az18zuBT8CfwrLOXkF3IvyAT0DSvmFFofzVW78
	UMjc6uByPZC+3zskKd/u/hxC4OWh5OHqrJWXLe2y/quUlUgadF2aTy57sgCuPe0pZcB/
	fnNKy+wZhdN8zBTx/RxG9gTLoZ2MgW6BL8AVtFvRqmO1b2l1C8rIZTeUjEnWQGV1+zdu
	6b+qcetvO30uQ21PMTkrFlZMKEAmTTYsOvJ0/QsiylGgMbDoZTm2qDWUtvyr/SRyi3+5
	SOO2AfJjE0R7sTK5cis+dzRxlJS7nPBXE0IW7R/bJi2dHh0a54R7EFbTGDJrjBZDnpta
	bDmw==
Received: by 10.14.213.137 with SMTP id a9mr30437790eep.38.1346848411787;
	Wed, 05 Sep 2012 05:33:31 -0700 (PDT)
Received: from [192.168.1.69] (host86-184-74-117.range86-184.btcentralplus.com.
	[86.184.74.117])
	by mx.google.com with ESMTPS id k49sm3897793een.4.2012.09.05.05.33.27
	(version=SSLv3 cipher=OTHER); Wed, 05 Sep 2012 05:33:31 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Wed, 05 Sep 2012 13:33:25 +0100
From: Keir Fraser <keir.xen@gmail.com>
To: Jan Beulich <JBeulich@suse.com>,
	xen-devel <xen-devel@lists.xen.org>
Message-ID: <CC6D0525.3DCAE%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [PATCH 2/2] x86: fix RCU locking in
	PHYSDEVOP_get_free_pirq
Thread-Index: Ac2LYqS1Cxubn2Lxl0KfsUDHUfqn3A==
In-Reply-To: <504760D00200007800098D70@nat28.tlf.novell.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] [PATCH 2/2] x86: fix RCU locking in
 PHYSDEVOP_get_free_pirq
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/09/2012 13:25, "Jan Beulich" <JBeulich@suse.com> wrote:

> Apart from properly pairing locks with unlocks, also reduce the lock
> scope - no need to do the copy_{from,to}_guest()-s inside the protected
> region.
> 
> I actually wonder whether the RCU locks are needed here at all.

If it's a path that only acts on current domain, then no.

 -- Keir

> Reported-by: Tim Deegan <tim@xen.org>
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> 
> --- a/xen/arch/x86/physdev.c
> +++ b/xen/arch/x86/physdev.c
> @@ -698,13 +698,13 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_H
>          struct physdev_get_free_pirq out;
>          struct domain *d;
>  
> -        d = rcu_lock_current_domain();
> -        
>          ret = -EFAULT;
>          if ( copy_from_guest(&out, arg, 1) != 0 )
>              break;
>  
> +        d = rcu_lock_current_domain();
>          spin_lock(&d->event_lock);
> +
>          ret = get_free_pirq(d, out.type);
>          if ( ret >= 0 )
>          {
> @@ -715,7 +715,9 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_H
>              else
>                  ret = -ENOMEM;
>          }
> +
>          spin_unlock(&d->event_lock);
> +        rcu_unlock_domain(d);
>  
>          if ( ret >= 0 )
>          {
> @@ -723,7 +725,6 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_H
>              ret = copy_to_guest(arg, &out, 1) ? -EFAULT : 0;
>          }
>  
> -        rcu_unlock_domain(d);
>          break;
>      }
>      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 Sep 05 12:33:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Sep 2012 12: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 1T9Enl-0004GT-Md; Wed, 05 Sep 2012 12:33:49 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1T9Enj-0004FI-Pm
	for xen-devel@lists.xen.org; Wed, 05 Sep 2012 12:33:47 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1346848411!9690454!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-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18346 invoked from network); 5 Sep 2012 12:33:32 -0000
Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com)
	(74.125.83.45)
	by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Sep 2012 12:33:32 -0000
Received: by eeke53 with SMTP id e53so231752eek.32
	for <xen-devel@lists.xen.org>; Wed, 05 Sep 2012 05:33:31 -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=GWFmKfd6hEALCVjz1eqXhj1j7XIcj888ii85ilMQC44=;
	b=nDjcv+Dt4xkcp4XrMenps4kreyc0az18zuBT8CfwrLOXkF3IvyAT0DSvmFFofzVW78
	UMjc6uByPZC+3zskKd/u/hxC4OWh5OHqrJWXLe2y/quUlUgadF2aTy57sgCuPe0pZcB/
	fnNKy+wZhdN8zBTx/RxG9gTLoZ2MgW6BL8AVtFvRqmO1b2l1C8rIZTeUjEnWQGV1+zdu
	6b+qcetvO30uQ21PMTkrFlZMKEAmTTYsOvJ0/QsiylGgMbDoZTm2qDWUtvyr/SRyi3+5
	SOO2AfJjE0R7sTK5cis+dzRxlJS7nPBXE0IW7R/bJi2dHh0a54R7EFbTGDJrjBZDnpta
	bDmw==
Received: by 10.14.213.137 with SMTP id a9mr30437790eep.38.1346848411787;
	Wed, 05 Sep 2012 05:33:31 -0700 (PDT)
Received: from [192.168.1.69] (host86-184-74-117.range86-184.btcentralplus.com.
	[86.184.74.117])
	by mx.google.com with ESMTPS id k49sm3897793een.4.2012.09.05.05.33.27
	(version=SSLv3 cipher=OTHER); Wed, 05 Sep 2012 05:33:31 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Wed, 05 Sep 2012 13:33:25 +0100
From: Keir Fraser <keir.xen@gmail.com>
To: Jan Beulich <JBeulich@suse.com>,
	xen-devel <xen-devel@lists.xen.org>
Message-ID: <CC6D0525.3DCAE%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [PATCH 2/2] x86: fix RCU locking in
	PHYSDEVOP_get_free_pirq
Thread-Index: Ac2LYqS1Cxubn2Lxl0KfsUDHUfqn3A==
In-Reply-To: <504760D00200007800098D70@nat28.tlf.novell.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] [PATCH 2/2] x86: fix RCU locking in
 PHYSDEVOP_get_free_pirq
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/09/2012 13:25, "Jan Beulich" <JBeulich@suse.com> wrote:

> Apart from properly pairing locks with unlocks, also reduce the lock
> scope - no need to do the copy_{from,to}_guest()-s inside the protected
> region.
> 
> I actually wonder whether the RCU locks are needed here at all.

If it's a path that only acts on current domain, then no.

 -- Keir

> Reported-by: Tim Deegan <tim@xen.org>
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> 
> --- a/xen/arch/x86/physdev.c
> +++ b/xen/arch/x86/physdev.c
> @@ -698,13 +698,13 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_H
>          struct physdev_get_free_pirq out;
>          struct domain *d;
>  
> -        d = rcu_lock_current_domain();
> -        
>          ret = -EFAULT;
>          if ( copy_from_guest(&out, arg, 1) != 0 )
>              break;
>  
> +        d = rcu_lock_current_domain();
>          spin_lock(&d->event_lock);
> +
>          ret = get_free_pirq(d, out.type);
>          if ( ret >= 0 )
>          {
> @@ -715,7 +715,9 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_H
>              else
>                  ret = -ENOMEM;
>          }
> +
>          spin_unlock(&d->event_lock);
> +        rcu_unlock_domain(d);
>  
>          if ( ret >= 0 )
>          {
> @@ -723,7 +725,6 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_H
>              ret = copy_to_guest(arg, &out, 1) ? -EFAULT : 0;
>          }
>  
> -        rcu_unlock_domain(d);
>          break;
>      }
>      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 Sep 05 12:33:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Sep 2012 12: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 1T9Enm-0004Gm-4e; Wed, 05 Sep 2012 12:33:50 +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 1T9Enl-0004GK-Gf
	for xen-devel@lists.xen.org; Wed, 05 Sep 2012 12:33:49 +0000
Received: from [85.158.139.83:38828] by server-1.bemta-5.messagelabs.com id
	E4/DD-32692-CA647405; Wed, 05 Sep 2012 12:33:48 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1346848428!28618664!1
X-Originating-IP: [209.85.215.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-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32595 invoked from network); 5 Sep 2012 12:33:48 -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;
	5 Sep 2012 12:33:48 -0000
Received: by eaac13 with SMTP id c13so181920eaa.32
	for <xen-devel@lists.xen.org>; Wed, 05 Sep 2012 05:33:48 -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=8k+EQF+/ah+OIdbSfyj0iNuwxoEdjVDChTjBwSUJM8M=;
	b=T9NXTREdinfjvxn/IFVS7GCK89NLxticsrJq6+mq3h5oel3RH7tZmevpyRhbY6XpeN
	BYy7wfWw3SHXMMEpYfCCmVIUdrRZLmsoYkxTfc3rdXt95/qRR4049yyS45QlRGOkMlTR
	cOkLFCEpnbU/dytJgqjWawbHJVYzYOMUADv1/4MSQMhvItWO+ONspiY43qF85VK65Qj5
	YZbioxGXANbtf0ptNo8JuNxThli7LR9em8JPimjHGKjsead6lDKrSlM9IA/QBAjj6XfH
	ok+owYie33ux3KnME9UBV64hOoaF6x7mlAVmTlneeytPuGcc8tmrGTusOzOezJJWRWXn
	AOrA==
Received: by 10.14.224.73 with SMTP id w49mr18461709eep.37.1346848428127;
	Wed, 05 Sep 2012 05:33:48 -0700 (PDT)
Received: from [192.168.1.69] (host86-184-74-117.range86-184.btcentralplus.com.
	[86.184.74.117])
	by mx.google.com with ESMTPS id u47sm3869956eeo.9.2012.09.05.05.33.46
	(version=SSLv3 cipher=OTHER); Wed, 05 Sep 2012 05:33:47 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Wed, 05 Sep 2012 13:33:43 +0100
From: Keir Fraser <keir.xen@gmail.com>
To: Jan Beulich <JBeulich@suse.com>,
	xen-devel <xen-devel@lists.xen.org>
Message-ID: <CC6D0537.3DCAF%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [PATCH 0/2] PHYSDEVOP_get_free_pirq adjustments
Thread-Index: Ac2LYq9vCzYRP32gX0GLmDjbeB6+yA==
In-Reply-To: <504760480200007800098D68@nat28.tlf.novell.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] [PATCH 0/2] PHYSDEVOP_get_free_pirq adjustments
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 05/09/2012 13:23, "Jan Beulich" <JBeulich@suse.com> wrote:

> Issues noticed during recent fixing of security problems.
> 
> 1: x86: drop "index" parameter from get_free_pirq()
> 2: x86: fix RCU locking in PHYSDEVOP_get_free_pirq
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Acked-by: Keir Fraser <keir@xen.org>

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



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

From xen-devel-bounces@lists.xen.org Wed Sep 05 12:33:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Sep 2012 12: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 1T9Enm-0004Gm-4e; Wed, 05 Sep 2012 12:33:50 +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 1T9Enl-0004GK-Gf
	for xen-devel@lists.xen.org; Wed, 05 Sep 2012 12:33:49 +0000
Received: from [85.158.139.83:38828] by server-1.bemta-5.messagelabs.com id
	E4/DD-32692-CA647405; Wed, 05 Sep 2012 12:33:48 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1346848428!28618664!1
X-Originating-IP: [209.85.215.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-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32595 invoked from network); 5 Sep 2012 12:33:48 -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;
	5 Sep 2012 12:33:48 -0000
Received: by eaac13 with SMTP id c13so181920eaa.32
	for <xen-devel@lists.xen.org>; Wed, 05 Sep 2012 05:33:48 -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=8k+EQF+/ah+OIdbSfyj0iNuwxoEdjVDChTjBwSUJM8M=;
	b=T9NXTREdinfjvxn/IFVS7GCK89NLxticsrJq6+mq3h5oel3RH7tZmevpyRhbY6XpeN
	BYy7wfWw3SHXMMEpYfCCmVIUdrRZLmsoYkxTfc3rdXt95/qRR4049yyS45QlRGOkMlTR
	cOkLFCEpnbU/dytJgqjWawbHJVYzYOMUADv1/4MSQMhvItWO+ONspiY43qF85VK65Qj5
	YZbioxGXANbtf0ptNo8JuNxThli7LR9em8JPimjHGKjsead6lDKrSlM9IA/QBAjj6XfH
	ok+owYie33ux3KnME9UBV64hOoaF6x7mlAVmTlneeytPuGcc8tmrGTusOzOezJJWRWXn
	AOrA==
Received: by 10.14.224.73 with SMTP id w49mr18461709eep.37.1346848428127;
	Wed, 05 Sep 2012 05:33:48 -0700 (PDT)
Received: from [192.168.1.69] (host86-184-74-117.range86-184.btcentralplus.com.
	[86.184.74.117])
	by mx.google.com with ESMTPS id u47sm3869956eeo.9.2012.09.05.05.33.46
	(version=SSLv3 cipher=OTHER); Wed, 05 Sep 2012 05:33:47 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Wed, 05 Sep 2012 13:33:43 +0100
From: Keir Fraser <keir.xen@gmail.com>
To: Jan Beulich <JBeulich@suse.com>,
	xen-devel <xen-devel@lists.xen.org>
Message-ID: <CC6D0537.3DCAF%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [PATCH 0/2] PHYSDEVOP_get_free_pirq adjustments
Thread-Index: Ac2LYq9vCzYRP32gX0GLmDjbeB6+yA==
In-Reply-To: <504760480200007800098D68@nat28.tlf.novell.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] [PATCH 0/2] PHYSDEVOP_get_free_pirq adjustments
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 05/09/2012 13:23, "Jan Beulich" <JBeulich@suse.com> wrote:

> Issues noticed during recent fixing of security problems.
> 
> 1: x86: drop "index" parameter from get_free_pirq()
> 2: x86: fix RCU locking in PHYSDEVOP_get_free_pirq
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Acked-by: Keir Fraser <keir@xen.org>

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



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

From xen-devel-bounces@lists.xen.org Wed Sep 05 12:34:43 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Sep 2012 12:34:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9EoX-0004VV-JW; Wed, 05 Sep 2012 12:34:37 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1T9EoW-0004Ux-H4
	for xen-devel@lists.xen.org; Wed, 05 Sep 2012 12:34:36 +0000
Received: from [85.158.143.35:61631] by server-2.bemta-4.messagelabs.com id
	E9/12-21239-BD647405; Wed, 05 Sep 2012 12:34:35 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1346848475!16768902!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQwMzE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29185 invoked from network); 5 Sep 2012 12:34:35 -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;
	5 Sep 2012 12:34:35 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 05 Sep 2012 13:34:36 +0100
Message-Id: <504763140200007800098D9D@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 05 Sep 2012 13:35:00 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__PartDDECC7E4.0__="
Cc: dan.magenheimer@oracle.com, Zhenzhong Duan <zhenzhong.duan@oracle.com>
Subject: [Xen-devel] [PATCH 03/11] tmem: check the pool_id is valid when
 destroying a tmem pool
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<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.

--=__PartDDECC7E4.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

This is part of XSA-15 / CVE-2012-3497.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/common/tmem.c
+++ b/xen/common/tmem.c
@@ -1870,6 +1870,8 @@ static NOINLINE int do_tmem_destroy_pool
=20
     if ( client->pools =3D=3D NULL )
         return 0;
+    if ( pool_id >=3D MAX_POOLS_PER_DOMAIN )
+        return 0;
     if ( (pool =3D client->pools[pool_id]) =3D=3D NULL )
         return 0;
     client->pools[pool_id] =3D NULL;




--=__PartDDECC7E4.0__=
Content-Type: application/octet-stream; name="tmem-xsa-15-3"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="tmem-xsa-15-3"

dG1lbTogY2hlY2sgdGhlIHBvb2xfaWQgaXMgdmFsaWQgd2hlbiBkZXN0cm95aW5nIGEgdG1lbSBw
b29sCgpUaGlzIGlzIHBhcnQgb2YgWFNBLTE1IC8gQ1ZFLTIwMTItMzQ5Ny4KClNpZ25lZC1vZmYt
Ynk6IElhbiBDYW1wYmVsbCA8aWFuLmNhbXBiZWxsQGNpdHJpeC5jb20+CkFja2VkLWJ5OiBKYW4g
QmV1bGljaCA8amJldWxpY2hAc3VzZS5jb20+CgotLS0gYS94ZW4vY29tbW9uL3RtZW0uYworKysg
Yi94ZW4vY29tbW9uL3RtZW0uYwpAQCAtMTg3MCw2ICsxODcwLDggQEAgc3RhdGljIE5PSU5MSU5F
IGludCBkb190bWVtX2Rlc3Ryb3lfcG9vbAogCiAgICAgaWYgKCBjbGllbnQtPnBvb2xzID09IE5V
TEwgKQogICAgICAgICByZXR1cm4gMDsKKyAgICBpZiAoIHBvb2xfaWQgPj0gTUFYX1BPT0xTX1BF
Ul9ET01BSU4gKQorICAgICAgICByZXR1cm4gMDsKICAgICBpZiAoIChwb29sID0gY2xpZW50LT5w
b29sc1twb29sX2lkXSkgPT0gTlVMTCApCiAgICAgICAgIHJldHVybiAwOwogICAgIGNsaWVudC0+
cG9vbHNbcG9vbF9pZF0gPSBOVUxMOwo=

--=__PartDDECC7E4.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

--=__PartDDECC7E4.0__=--


From xen-devel-bounces@lists.xen.org Wed Sep 05 12:34:43 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Sep 2012 12:34:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9EoX-0004VV-JW; Wed, 05 Sep 2012 12:34:37 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1T9EoW-0004Ux-H4
	for xen-devel@lists.xen.org; Wed, 05 Sep 2012 12:34:36 +0000
Received: from [85.158.143.35:61631] by server-2.bemta-4.messagelabs.com id
	E9/12-21239-BD647405; Wed, 05 Sep 2012 12:34:35 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1346848475!16768902!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQwMzE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29185 invoked from network); 5 Sep 2012 12:34:35 -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;
	5 Sep 2012 12:34:35 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 05 Sep 2012 13:34:36 +0100
Message-Id: <504763140200007800098D9D@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 05 Sep 2012 13:35:00 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__PartDDECC7E4.0__="
Cc: dan.magenheimer@oracle.com, Zhenzhong Duan <zhenzhong.duan@oracle.com>
Subject: [Xen-devel] [PATCH 03/11] tmem: check the pool_id is valid when
 destroying a tmem pool
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<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.

--=__PartDDECC7E4.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

This is part of XSA-15 / CVE-2012-3497.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/common/tmem.c
+++ b/xen/common/tmem.c
@@ -1870,6 +1870,8 @@ static NOINLINE int do_tmem_destroy_pool
=20
     if ( client->pools =3D=3D NULL )
         return 0;
+    if ( pool_id >=3D MAX_POOLS_PER_DOMAIN )
+        return 0;
     if ( (pool =3D client->pools[pool_id]) =3D=3D NULL )
         return 0;
     client->pools[pool_id] =3D NULL;




--=__PartDDECC7E4.0__=
Content-Type: application/octet-stream; name="tmem-xsa-15-3"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="tmem-xsa-15-3"

dG1lbTogY2hlY2sgdGhlIHBvb2xfaWQgaXMgdmFsaWQgd2hlbiBkZXN0cm95aW5nIGEgdG1lbSBw
b29sCgpUaGlzIGlzIHBhcnQgb2YgWFNBLTE1IC8gQ1ZFLTIwMTItMzQ5Ny4KClNpZ25lZC1vZmYt
Ynk6IElhbiBDYW1wYmVsbCA8aWFuLmNhbXBiZWxsQGNpdHJpeC5jb20+CkFja2VkLWJ5OiBKYW4g
QmV1bGljaCA8amJldWxpY2hAc3VzZS5jb20+CgotLS0gYS94ZW4vY29tbW9uL3RtZW0uYworKysg
Yi94ZW4vY29tbW9uL3RtZW0uYwpAQCAtMTg3MCw2ICsxODcwLDggQEAgc3RhdGljIE5PSU5MSU5F
IGludCBkb190bWVtX2Rlc3Ryb3lfcG9vbAogCiAgICAgaWYgKCBjbGllbnQtPnBvb2xzID09IE5V
TEwgKQogICAgICAgICByZXR1cm4gMDsKKyAgICBpZiAoIHBvb2xfaWQgPj0gTUFYX1BPT0xTX1BF
Ul9ET01BSU4gKQorICAgICAgICByZXR1cm4gMDsKICAgICBpZiAoIChwb29sID0gY2xpZW50LT5w
b29sc1twb29sX2lkXSkgPT0gTlVMTCApCiAgICAgICAgIHJldHVybiAwOwogICAgIGNsaWVudC0+
cG9vbHNbcG9vbF9pZF0gPSBOVUxMOwo=

--=__PartDDECC7E4.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

--=__PartDDECC7E4.0__=--


From xen-devel-bounces@lists.xen.org Wed Sep 05 12:34:53 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Sep 2012 12: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 1T9Eoi-0004ZR-1N; Wed, 05 Sep 2012 12:34: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 1T9Eog-0004Yr-RJ
	for xen-devel@lists.xen.org; Wed, 05 Sep 2012 12:34:47 +0000
Received: from [85.158.143.35:58058] by server-2.bemta-4.messagelabs.com id
	9F/62-21239-6E647405; Wed, 05 Sep 2012 12:34:46 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1346848485!11632237!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQwMzE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23539 invoked from network); 5 Sep 2012 12:34:45 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-11.tower-21.messagelabs.com with SMTP;
	5 Sep 2012 12:34:45 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 05 Sep 2012 13:34:46 +0100
Message-Id: <5047633A0200007800098DCD@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 05 Sep 2012 13:35:38 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part3203280A.0__="
Cc: dan.magenheimer@oracle.com, Zhenzhong Duan <zhenzhong.duan@oracle.com>
Subject: [Xen-devel] [PATCH 04/11] tmem: check for a valid client ("domain")
 in the save subops
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<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.

--=__Part3203280A.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

This is part of XSA-15 / CVE-2012-3497.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/common/tmem.c
+++ b/xen/common/tmem.c
@@ -2379,12 +2379,18 @@ static NOINLINE int tmemc_save_subop(int
         rc =3D MAX_POOLS_PER_DOMAIN;
         break;
     case TMEMC_SAVE_GET_CLIENT_WEIGHT:
+        if ( client =3D=3D NULL )
+            break;
         rc =3D client->weight =3D=3D -1 ? -2 : client->weight;
         break;
     case TMEMC_SAVE_GET_CLIENT_CAP:
+        if ( client =3D=3D NULL )
+            break;
         rc =3D client->cap =3D=3D -1 ? -2 : client->cap;
         break;
     case TMEMC_SAVE_GET_CLIENT_FLAGS:
+        if ( client =3D=3D NULL )
+            break;
         rc =3D (client->compress ? TMEM_CLIENT_COMPRESS : 0 ) |
              (client->was_frozen ? TMEM_CLIENT_FROZEN : 0 );
         break;
@@ -2408,6 +2414,8 @@ static NOINLINE int tmemc_save_subop(int
         *uuid =3D pool->uuid[1];
         rc =3D 0;
     case TMEMC_SAVE_END:
+        if ( client =3D=3D NULL )
+            break;
         client->live_migrating =3D 0;
         if ( !list_empty(&client->persistent_invalidated_list) )
             list_for_each_entry_safe(pgp,pgp2,




--=__Part3203280A.0__=
Content-Type: application/octet-stream; name="tmem-xsa-15-4"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="tmem-xsa-15-4"

dG1lbTogY2hlY2sgZm9yIGEgdmFsaWQgY2xpZW50ICgiZG9tYWluIikgaW4gdGhlIHNhdmUgc3Vi
b3BzCgpUaGlzIGlzIHBhcnQgb2YgWFNBLTE1IC8gQ1ZFLTIwMTItMzQ5Ny4KClNpZ25lZC1vZmYt
Ynk6IElhbiBDYW1wYmVsbCA8aWFuLmNhbXBiZWxsQGNpdHJpeC5jb20+CkFja2VkLWJ5OiBKYW4g
QmV1bGljaCA8amJldWxpY2hAc3VzZS5jb20+CgotLS0gYS94ZW4vY29tbW9uL3RtZW0uYworKysg
Yi94ZW4vY29tbW9uL3RtZW0uYwpAQCAtMjM3OSwxMiArMjM3OSwxOCBAQCBzdGF0aWMgTk9JTkxJ
TkUgaW50IHRtZW1jX3NhdmVfc3Vib3AoaW50CiAgICAgICAgIHJjID0gTUFYX1BPT0xTX1BFUl9E
T01BSU47CiAgICAgICAgIGJyZWFrOwogICAgIGNhc2UgVE1FTUNfU0FWRV9HRVRfQ0xJRU5UX1dF
SUdIVDoKKyAgICAgICAgaWYgKCBjbGllbnQgPT0gTlVMTCApCisgICAgICAgICAgICBicmVhazsK
ICAgICAgICAgcmMgPSBjbGllbnQtPndlaWdodCA9PSAtMSA/IC0yIDogY2xpZW50LT53ZWlnaHQ7
CiAgICAgICAgIGJyZWFrOwogICAgIGNhc2UgVE1FTUNfU0FWRV9HRVRfQ0xJRU5UX0NBUDoKKyAg
ICAgICAgaWYgKCBjbGllbnQgPT0gTlVMTCApCisgICAgICAgICAgICBicmVhazsKICAgICAgICAg
cmMgPSBjbGllbnQtPmNhcCA9PSAtMSA/IC0yIDogY2xpZW50LT5jYXA7CiAgICAgICAgIGJyZWFr
OwogICAgIGNhc2UgVE1FTUNfU0FWRV9HRVRfQ0xJRU5UX0ZMQUdTOgorICAgICAgICBpZiAoIGNs
aWVudCA9PSBOVUxMICkKKyAgICAgICAgICAgIGJyZWFrOwogICAgICAgICByYyA9IChjbGllbnQt
PmNvbXByZXNzID8gVE1FTV9DTElFTlRfQ09NUFJFU1MgOiAwICkgfAogICAgICAgICAgICAgIChj
bGllbnQtPndhc19mcm96ZW4gPyBUTUVNX0NMSUVOVF9GUk9aRU4gOiAwICk7CiAgICAgICAgIGJy
ZWFrOwpAQCAtMjQwOCw2ICsyNDE0LDggQEAgc3RhdGljIE5PSU5MSU5FIGludCB0bWVtY19zYXZl
X3N1Ym9wKGludAogICAgICAgICAqdXVpZCA9IHBvb2wtPnV1aWRbMV07CiAgICAgICAgIHJjID0g
MDsKICAgICBjYXNlIFRNRU1DX1NBVkVfRU5EOgorICAgICAgICBpZiAoIGNsaWVudCA9PSBOVUxM
ICkKKyAgICAgICAgICAgIGJyZWFrOwogICAgICAgICBjbGllbnQtPmxpdmVfbWlncmF0aW5nID0g
MDsKICAgICAgICAgaWYgKCAhbGlzdF9lbXB0eSgmY2xpZW50LT5wZXJzaXN0ZW50X2ludmFsaWRh
dGVkX2xpc3QpICkKICAgICAgICAgICAgIGxpc3RfZm9yX2VhY2hfZW50cnlfc2FmZShwZ3AscGdw
MiwK

--=__Part3203280A.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

--=__Part3203280A.0__=--


From xen-devel-bounces@lists.xen.org Wed Sep 05 12:34:53 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Sep 2012 12: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 1T9Eoi-0004ZR-1N; Wed, 05 Sep 2012 12:34: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 1T9Eog-0004Yr-RJ
	for xen-devel@lists.xen.org; Wed, 05 Sep 2012 12:34:47 +0000
Received: from [85.158.143.35:58058] by server-2.bemta-4.messagelabs.com id
	9F/62-21239-6E647405; Wed, 05 Sep 2012 12:34:46 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1346848485!11632237!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQwMzE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23539 invoked from network); 5 Sep 2012 12:34:45 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-11.tower-21.messagelabs.com with SMTP;
	5 Sep 2012 12:34:45 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 05 Sep 2012 13:34:46 +0100
Message-Id: <5047633A0200007800098DCD@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 05 Sep 2012 13:35:38 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part3203280A.0__="
Cc: dan.magenheimer@oracle.com, Zhenzhong Duan <zhenzhong.duan@oracle.com>
Subject: [Xen-devel] [PATCH 04/11] tmem: check for a valid client ("domain")
 in the save subops
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<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.

--=__Part3203280A.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

This is part of XSA-15 / CVE-2012-3497.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/common/tmem.c
+++ b/xen/common/tmem.c
@@ -2379,12 +2379,18 @@ static NOINLINE int tmemc_save_subop(int
         rc =3D MAX_POOLS_PER_DOMAIN;
         break;
     case TMEMC_SAVE_GET_CLIENT_WEIGHT:
+        if ( client =3D=3D NULL )
+            break;
         rc =3D client->weight =3D=3D -1 ? -2 : client->weight;
         break;
     case TMEMC_SAVE_GET_CLIENT_CAP:
+        if ( client =3D=3D NULL )
+            break;
         rc =3D client->cap =3D=3D -1 ? -2 : client->cap;
         break;
     case TMEMC_SAVE_GET_CLIENT_FLAGS:
+        if ( client =3D=3D NULL )
+            break;
         rc =3D (client->compress ? TMEM_CLIENT_COMPRESS : 0 ) |
              (client->was_frozen ? TMEM_CLIENT_FROZEN : 0 );
         break;
@@ -2408,6 +2414,8 @@ static NOINLINE int tmemc_save_subop(int
         *uuid =3D pool->uuid[1];
         rc =3D 0;
     case TMEMC_SAVE_END:
+        if ( client =3D=3D NULL )
+            break;
         client->live_migrating =3D 0;
         if ( !list_empty(&client->persistent_invalidated_list) )
             list_for_each_entry_safe(pgp,pgp2,




--=__Part3203280A.0__=
Content-Type: application/octet-stream; name="tmem-xsa-15-4"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="tmem-xsa-15-4"

dG1lbTogY2hlY2sgZm9yIGEgdmFsaWQgY2xpZW50ICgiZG9tYWluIikgaW4gdGhlIHNhdmUgc3Vi
b3BzCgpUaGlzIGlzIHBhcnQgb2YgWFNBLTE1IC8gQ1ZFLTIwMTItMzQ5Ny4KClNpZ25lZC1vZmYt
Ynk6IElhbiBDYW1wYmVsbCA8aWFuLmNhbXBiZWxsQGNpdHJpeC5jb20+CkFja2VkLWJ5OiBKYW4g
QmV1bGljaCA8amJldWxpY2hAc3VzZS5jb20+CgotLS0gYS94ZW4vY29tbW9uL3RtZW0uYworKysg
Yi94ZW4vY29tbW9uL3RtZW0uYwpAQCAtMjM3OSwxMiArMjM3OSwxOCBAQCBzdGF0aWMgTk9JTkxJ
TkUgaW50IHRtZW1jX3NhdmVfc3Vib3AoaW50CiAgICAgICAgIHJjID0gTUFYX1BPT0xTX1BFUl9E
T01BSU47CiAgICAgICAgIGJyZWFrOwogICAgIGNhc2UgVE1FTUNfU0FWRV9HRVRfQ0xJRU5UX1dF
SUdIVDoKKyAgICAgICAgaWYgKCBjbGllbnQgPT0gTlVMTCApCisgICAgICAgICAgICBicmVhazsK
ICAgICAgICAgcmMgPSBjbGllbnQtPndlaWdodCA9PSAtMSA/IC0yIDogY2xpZW50LT53ZWlnaHQ7
CiAgICAgICAgIGJyZWFrOwogICAgIGNhc2UgVE1FTUNfU0FWRV9HRVRfQ0xJRU5UX0NBUDoKKyAg
ICAgICAgaWYgKCBjbGllbnQgPT0gTlVMTCApCisgICAgICAgICAgICBicmVhazsKICAgICAgICAg
cmMgPSBjbGllbnQtPmNhcCA9PSAtMSA/IC0yIDogY2xpZW50LT5jYXA7CiAgICAgICAgIGJyZWFr
OwogICAgIGNhc2UgVE1FTUNfU0FWRV9HRVRfQ0xJRU5UX0ZMQUdTOgorICAgICAgICBpZiAoIGNs
aWVudCA9PSBOVUxMICkKKyAgICAgICAgICAgIGJyZWFrOwogICAgICAgICByYyA9IChjbGllbnQt
PmNvbXByZXNzID8gVE1FTV9DTElFTlRfQ09NUFJFU1MgOiAwICkgfAogICAgICAgICAgICAgIChj
bGllbnQtPndhc19mcm96ZW4gPyBUTUVNX0NMSUVOVF9GUk9aRU4gOiAwICk7CiAgICAgICAgIGJy
ZWFrOwpAQCAtMjQwOCw2ICsyNDE0LDggQEAgc3RhdGljIE5PSU5MSU5FIGludCB0bWVtY19zYXZl
X3N1Ym9wKGludAogICAgICAgICAqdXVpZCA9IHBvb2wtPnV1aWRbMV07CiAgICAgICAgIHJjID0g
MDsKICAgICBjYXNlIFRNRU1DX1NBVkVfRU5EOgorICAgICAgICBpZiAoIGNsaWVudCA9PSBOVUxM
ICkKKyAgICAgICAgICAgIGJyZWFrOwogICAgICAgICBjbGllbnQtPmxpdmVfbWlncmF0aW5nID0g
MDsKICAgICAgICAgaWYgKCAhbGlzdF9lbXB0eSgmY2xpZW50LT5wZXJzaXN0ZW50X2ludmFsaWRh
dGVkX2xpc3QpICkKICAgICAgICAgICAgIGxpc3RfZm9yX2VhY2hfZW50cnlfc2FmZShwZ3AscGdw
MiwK

--=__Part3203280A.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

--=__Part3203280A.0__=--


From xen-devel-bounces@lists.xen.org Wed Sep 05 12:36:25 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Sep 2012 12:36:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9EqB-00051U-Q2; Wed, 05 Sep 2012 12:36:19 +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 1T9EqA-000517-Ga
	for xen-devel@lists.xen.org; Wed, 05 Sep 2012 12:36:18 +0000
Received: from [85.158.138.51:53318] by server-10.bemta-3.messagelabs.com id
	0E/3E-10411-14747405; Wed, 05 Sep 2012 12:36:17 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1346848575!20754161!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNzY4NTA=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11506 invoked from network); 5 Sep 2012 12:36:17 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-6.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Sep 2012 12:36:17 -0000
X-IronPort-AV: E=Sophos;i="4.80,374,1344211200"; d="scan'208";a="207131495"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Sep 2012 12:36:15 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 5 Sep 2012 08:36:14 -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 1T9Eq6-0002LB-My;
	Wed, 05 Sep 2012 13:36:14 +0100
Message-ID: <5047473E.1020701@citrix.com>
Date: Wed, 5 Sep 2012 13:36:14 +0100
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:14.0) Gecko/20120714 Thunderbird/14.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <504760B20200007800098D6C@nat28.tlf.novell.com>
In-Reply-To: <504760B20200007800098D6C@nat28.tlf.novell.com>
X-Enigmail-Version: 1.4.4
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 1/2] x86: drop "index" parameter from
	get_free_pirq()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/09/12 13:24, Jan Beulich wrote:
> It's unused.
>
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
>
> --- a/xen/arch/x86/irq.c
> +++ b/xen/arch/x86/irq.c
> @@ -1816,7 +1816,7 @@ static inline bool_t is_free_pirq(const 
>          pirq->arch.hvm.emuirq == IRQ_UNBOUND));
>  }
>  
> -int get_free_pirq(struct domain *d, int type, int index)
> +int get_free_pirq(struct domain *d, int type)
>  {
>      int i;
>  
> --- a/xen/arch/x86/physdev.c
> +++ b/xen/arch/x86/physdev.c
> @@ -71,7 +71,7 @@ static int physdev_hvm_map_pirq(
>          else
>          {
>              if ( *pirq < 0 )
> -                *pirq = get_free_pirq(d, type, *index);
> +                *pirq = get_free_pirq(d, type);
>              ret = map_domain_emuirq_pirq(d, *pirq, *index);


Relatedly (and I had already noticed this but not got round to making a
patch because of other more urgent bugs)

You still have a chance here of passing an error into
map_domain_emuirq_pirq, in the pirq value.  This is not a security issue
as map_domain_emuirq_pirq does range check pirq, but may turn into a
problem if the implementation of map_domain_emuirq_pirq changes.  I
would say that for correctness sake, physdev_hvm_map_pirq() should range
check get_free_pirq(), even if this will lead to a double range check of
the value.

~Andrew

>          }
>          break;
> @@ -187,7 +187,7 @@ int physdev_map_pirq(domid_t domid, int 
>          }
>          else
>          {
> -            pirq = get_free_pirq(d, type, *index);
> +            pirq = get_free_pirq(d, type);
>              if ( pirq < 0 )
>              {
>                  dprintk(XENLOG_G_ERR, "dom%d: no free pirq\n", d->domain_id);
> @@ -705,7 +705,7 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_H
>              break;
>  
>          spin_lock(&d->event_lock);
> -        ret = get_free_pirq(d, out.type, 0);
> +        ret = get_free_pirq(d, out.type);
>          if ( ret >= 0 )
>          {
>              struct pirq *info = pirq_get_info(d, ret);
> --- a/xen/include/asm-x86/irq.h
> +++ b/xen/include/asm-x86/irq.h
> @@ -136,7 +136,7 @@ int pirq_shared(struct domain *d , int i
>  int map_domain_pirq(struct domain *d, int pirq, int irq, int type,
>                             void *data);
>  int unmap_domain_pirq(struct domain *d, int pirq);
> -int get_free_pirq(struct domain *d, int type, int index);
> +int get_free_pirq(struct domain *d, int type);
>  void free_domain_pirqs(struct domain *d);
>  int map_domain_emuirq_pirq(struct domain *d, int pirq, int irq);
>  int unmap_domain_pirq_emuirq(struct domain *d, int pirq);
>
>
>

-- 
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 Sep 05 12:36:25 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Sep 2012 12:36:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9EqB-00051U-Q2; Wed, 05 Sep 2012 12:36:19 +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 1T9EqA-000517-Ga
	for xen-devel@lists.xen.org; Wed, 05 Sep 2012 12:36:18 +0000
Received: from [85.158.138.51:53318] by server-10.bemta-3.messagelabs.com id
	0E/3E-10411-14747405; Wed, 05 Sep 2012 12:36:17 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1346848575!20754161!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNzY4NTA=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11506 invoked from network); 5 Sep 2012 12:36:17 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-6.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Sep 2012 12:36:17 -0000
X-IronPort-AV: E=Sophos;i="4.80,374,1344211200"; d="scan'208";a="207131495"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Sep 2012 12:36:15 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 5 Sep 2012 08:36:14 -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 1T9Eq6-0002LB-My;
	Wed, 05 Sep 2012 13:36:14 +0100
Message-ID: <5047473E.1020701@citrix.com>
Date: Wed, 5 Sep 2012 13:36:14 +0100
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:14.0) Gecko/20120714 Thunderbird/14.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <504760B20200007800098D6C@nat28.tlf.novell.com>
In-Reply-To: <504760B20200007800098D6C@nat28.tlf.novell.com>
X-Enigmail-Version: 1.4.4
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 1/2] x86: drop "index" parameter from
	get_free_pirq()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/09/12 13:24, Jan Beulich wrote:
> It's unused.
>
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
>
> --- a/xen/arch/x86/irq.c
> +++ b/xen/arch/x86/irq.c
> @@ -1816,7 +1816,7 @@ static inline bool_t is_free_pirq(const 
>          pirq->arch.hvm.emuirq == IRQ_UNBOUND));
>  }
>  
> -int get_free_pirq(struct domain *d, int type, int index)
> +int get_free_pirq(struct domain *d, int type)
>  {
>      int i;
>  
> --- a/xen/arch/x86/physdev.c
> +++ b/xen/arch/x86/physdev.c
> @@ -71,7 +71,7 @@ static int physdev_hvm_map_pirq(
>          else
>          {
>              if ( *pirq < 0 )
> -                *pirq = get_free_pirq(d, type, *index);
> +                *pirq = get_free_pirq(d, type);
>              ret = map_domain_emuirq_pirq(d, *pirq, *index);


Relatedly (and I had already noticed this but not got round to making a
patch because of other more urgent bugs)

You still have a chance here of passing an error into
map_domain_emuirq_pirq, in the pirq value.  This is not a security issue
as map_domain_emuirq_pirq does range check pirq, but may turn into a
problem if the implementation of map_domain_emuirq_pirq changes.  I
would say that for correctness sake, physdev_hvm_map_pirq() should range
check get_free_pirq(), even if this will lead to a double range check of
the value.

~Andrew

>          }
>          break;
> @@ -187,7 +187,7 @@ int physdev_map_pirq(domid_t domid, int 
>          }
>          else
>          {
> -            pirq = get_free_pirq(d, type, *index);
> +            pirq = get_free_pirq(d, type);
>              if ( pirq < 0 )
>              {
>                  dprintk(XENLOG_G_ERR, "dom%d: no free pirq\n", d->domain_id);
> @@ -705,7 +705,7 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_H
>              break;
>  
>          spin_lock(&d->event_lock);
> -        ret = get_free_pirq(d, out.type, 0);
> +        ret = get_free_pirq(d, out.type);
>          if ( ret >= 0 )
>          {
>              struct pirq *info = pirq_get_info(d, ret);
> --- a/xen/include/asm-x86/irq.h
> +++ b/xen/include/asm-x86/irq.h
> @@ -136,7 +136,7 @@ int pirq_shared(struct domain *d , int i
>  int map_domain_pirq(struct domain *d, int pirq, int irq, int type,
>                             void *data);
>  int unmap_domain_pirq(struct domain *d, int pirq);
> -int get_free_pirq(struct domain *d, int type, int index);
> +int get_free_pirq(struct domain *d, int type);
>  void free_domain_pirqs(struct domain *d);
>  int map_domain_emuirq_pirq(struct domain *d, int pirq, int irq);
>  int unmap_domain_pirq_emuirq(struct domain *d, int pirq);
>
>
>

-- 
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 Sep 05 12:37:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Sep 2012 12:37:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9Eqq-0005Bg-AC; Wed, 05 Sep 2012 12:37:00 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1T9Eqo-0005BC-Ge
	for xen-devel@lists.xen.org; Wed, 05 Sep 2012 12:36:59 +0000
Received: from [85.158.143.35:9958] by server-2.bemta-4.messagelabs.com id
	15/36-21239-96747405; Wed, 05 Sep 2012 12:36:57 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1346848595!13410630!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQwMzE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26056 invoked from network); 5 Sep 2012 12:36:35 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-3.tower-21.messagelabs.com with SMTP;
	5 Sep 2012 12:36:35 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 05 Sep 2012 13:36:33 +0100
Message-Id: <5047639E0200007800098DD1@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 05 Sep 2012 13:37:18 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part56674C6E.0__="
Cc: dan.magenheimer@oracle.com, Zhenzhong Duan <zhenzhong.duan@oracle.com>
Subject: [Xen-devel] [PATCH 05/11] tmem: don't access guest memory without
 using the accessors intended for this
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<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.

--=__Part56674C6E.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

This is not permitted, not even for buffers coming from Dom0 (and it
would also break the moment Dom0 runs in HVM mode). An implication from
the changes here is that tmh_copy_page() can't be used anymore for
control operations calling tmh_copy_{from,to}_client() (as those pass
the buffer by virtual address rather than MFN).

Note that tmemc_save_get_next_page() previously didn't set the returned
handle's pool_id field, while the new code does. It need to be
confirmed that this is not a problem (otherwise the copy-out operation
will require further tmh_...() abstractions to be added).

Further note that the patch removes (rather than adjusts) an invalid
call to unmap_domain_page() (no matching map_domain_page()) from
tmh_compress_from_client() and adds a missing one to an error return
path in tmh_copy_from_client().

Finally note that the patch adds a previously missing return statement
to cli_get_page() (without which that function could de-reference a
NULL pointer, triggerable from guest mode).

This is part of XSA-15 / CVE-2012-3497.

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

--- a/xen/common/tmem.c
+++ b/xen/common/tmem.c
@@ -388,11 +388,13 @@ static NOINLINE int pcd_copy_to_client(t
     pcd =3D pgp->pcd;
     if ( pgp->size < PAGE_SIZE && pgp->size !=3D 0 &&
          pcd->size < PAGE_SIZE && pcd->size !=3D 0 )
-        ret =3D tmh_decompress_to_client(cmfn, pcd->cdata, pcd->size, =
NULL);
+        ret =3D tmh_decompress_to_client(cmfn, pcd->cdata, pcd->size,
+                                       tmh_cli_buf_null);
     else if ( tmh_tze_enabled() && pcd->size < PAGE_SIZE )
         ret =3D tmh_copy_tze_to_client(cmfn, pcd->tze, pcd->size);
     else
-        ret =3D tmh_copy_to_client(cmfn, pcd->pfp, 0, 0, PAGE_SIZE, =
NULL);
+        ret =3D tmh_copy_to_client(cmfn, pcd->pfp, 0, 0, PAGE_SIZE,
+                                 tmh_cli_buf_null);
     tmem_read_unlock(&pcd_tree_rwlocks[firstbyte]);
     return ret;
 }
@@ -1444,7 +1446,7 @@ static inline void tmem_ensure_avail_pag
 /************ TMEM CORE OPERATIONS ************************************/
=20
 static NOINLINE int do_tmem_put_compress(pgp_t *pgp, tmem_cli_mfn_t cmfn,
-                                         void *cva)
+                                         tmem_cli_va_t clibuf)
 {
     void *dst, *p;
     size_t size;
@@ -1463,7 +1465,7 @@ static NOINLINE int do_tmem_put_compress
     if ( pgp->pfp !=3D NULL )
         pgp_free_data(pgp, pgp->us.obj->pool);
     START_CYC_COUNTER(compress);
-    ret =3D tmh_compress_from_client(cmfn, &dst, &size, cva);
+    ret =3D tmh_compress_from_client(cmfn, &dst, &size, clibuf);
     if ( (ret =3D=3D -EFAULT) || (ret =3D=3D 0) )
         goto out;
     else if ( (size =3D=3D 0) || (size >=3D tmem_subpage_maxsize()) ) {
@@ -1490,7 +1492,8 @@ out:
 }
=20
 static NOINLINE int do_tmem_dup_put(pgp_t *pgp, tmem_cli_mfn_t cmfn,
-       pagesize_t tmem_offset, pagesize_t pfn_offset, pagesize_t len, =
void *cva)
+       pagesize_t tmem_offset, pagesize_t pfn_offset, pagesize_t len,
+       tmem_cli_va_t clibuf)
 {
     pool_t *pool;
     obj_t *obj;
@@ -1512,7 +1515,7 @@ static NOINLINE int do_tmem_dup_put(pgp_
     /* can we successfully manipulate pgp to change out the data? */
     if ( len !=3D 0 && client->compress && pgp->size !=3D 0 )
     {
-        ret =3D do_tmem_put_compress(pgp,cmfn,cva);
+        ret =3D do_tmem_put_compress(pgp, cmfn, clibuf);
         if ( ret =3D=3D 1 )
             goto done;
         else if ( ret =3D=3D 0 )
@@ -1530,7 +1533,8 @@ copy_uncompressed:
         goto failed_dup;
     pgp->size =3D 0;
     /* tmh_copy_from_client properly handles len=3D=3D0 and offsets !=3D =
0 */
-    ret =3D tmh_copy_from_client(pgp->pfp,cmfn,tmem_offset,pfn_offset,len,=
0);
+    ret =3D tmh_copy_from_client(pgp->pfp, cmfn, tmem_offset, pfn_offset, =
len,
+                               tmh_cli_buf_null);
     if ( ret =3D=3D -EFAULT )
         goto bad_copy;
     if ( tmh_dedup_enabled() && !is_persistent(pool) )
@@ -1582,7 +1586,7 @@ cleanup:
 static NOINLINE int do_tmem_put(pool_t *pool,
               OID *oidp, uint32_t index,
               tmem_cli_mfn_t cmfn, pagesize_t tmem_offset,
-              pagesize_t pfn_offset, pagesize_t len, void *cva)
+              pagesize_t pfn_offset, pagesize_t len, tmem_cli_va_t =
clibuf)
 {
     obj_t *obj =3D NULL, *objfound =3D NULL, *objnew =3D NULL;
     pgp_t *pgp =3D NULL, *pgpdel =3D NULL;
@@ -1596,7 +1600,8 @@ static NOINLINE int do_tmem_put(pool_t *
     {
         ASSERT_SPINLOCK(&objfound->obj_spinlock);
         if ((pgp =3D pgp_lookup_in_obj(objfound, index)) !=3D NULL)
-            return do_tmem_dup_put(pgp,cmfn,tmem_offset,pfn_offset,len,cva=
);
+            return do_tmem_dup_put(pgp, cmfn, tmem_offset, pfn_offset, =
len,
+                                   clibuf);
     }
=20
     /* no puts allowed into a frozen pool (except dup puts) */
@@ -1631,7 +1636,7 @@ static NOINLINE int do_tmem_put(pool_t *
     if ( len !=3D 0 && client->compress )
     {
         ASSERT(pgp->pfp =3D=3D NULL);
-        ret =3D do_tmem_put_compress(pgp,cmfn,cva);
+        ret =3D do_tmem_put_compress(pgp, cmfn, clibuf);
         if ( ret =3D=3D 1 )
             goto insert_page;
         if ( ret =3D=3D -ENOMEM )
@@ -1655,7 +1660,8 @@ copy_uncompressed:
         goto delete_and_free;
     }
     /* tmh_copy_from_client properly handles len=3D=3D0 (TMEM_NEW_PAGE) =
*/
-    ret =3D tmh_copy_from_client(pgp->pfp,cmfn,tmem_offset,pfn_offset,len,=
cva);
+    ret =3D tmh_copy_from_client(pgp->pfp, cmfn, tmem_offset, pfn_offset, =
len,
+                               clibuf);
     if ( ret =3D=3D -EFAULT )
         goto bad_copy;
     if ( tmh_dedup_enabled() && !is_persistent(pool) )
@@ -1725,12 +1731,13 @@ free:
=20
 static NOINLINE int do_tmem_get(pool_t *pool, OID *oidp, uint32_t index,
               tmem_cli_mfn_t cmfn, pagesize_t tmem_offset,
-              pagesize_t pfn_offset, pagesize_t len, void *cva)
+              pagesize_t pfn_offset, pagesize_t len, tmem_cli_va_t =
clibuf)
 {
     obj_t *obj;
     pgp_t *pgp;
     client_t *client =3D pool->client;
     DECL_LOCAL_CYC_COUNTER(decompress);
+    int rc =3D -EFAULT;
=20
     if ( !_atomic_read(pool->pgp_count) )
         return -EEMPTY;
@@ -1755,16 +1762,18 @@ static NOINLINE int do_tmem_get(pool_t *
     if ( tmh_dedup_enabled() && !is_persistent(pool) &&
               pgp->firstbyte !=3D NOT_SHAREABLE )
     {
-        if ( pcd_copy_to_client(cmfn, pgp) =3D=3D -EFAULT )
+        rc =3D pcd_copy_to_client(cmfn, pgp);
+        if ( rc <=3D 0 )
             goto bad_copy;
     } else if ( pgp->size !=3D 0 ) {
         START_CYC_COUNTER(decompress);
-        if ( tmh_decompress_to_client(cmfn, pgp->cdata,
-                                      pgp->size, cva) =3D=3D -EFAULT )
+        rc =3D tmh_decompress_to_client(cmfn, pgp->cdata,
+                                      pgp->size, clibuf);
+        if ( rc <=3D 0 )
             goto bad_copy;
         END_CYC_COUNTER(decompress);
     } else if ( tmh_copy_to_client(cmfn, pgp->pfp, tmem_offset,
-                                 pfn_offset, len, cva) =3D=3D -EFAULT)
+                                 pfn_offset, len, clibuf) =3D=3D -EFAULT)
         goto bad_copy;
     if ( is_ephemeral(pool) )
     {
@@ -1804,8 +1813,7 @@ static NOINLINE int do_tmem_get(pool_t *
 bad_copy:
     /* this should only happen if the client passed a bad mfn */
     failed_copies++;
-    return -EFAULT;
-
+    return rc;
 }
=20
 static NOINLINE int do_tmem_flush_page(pool_t *pool, OID *oidp, uint32_t =
index)
@@ -2345,7 +2353,6 @@ static NOINLINE int tmemc_save_subop(int
     pool_t *pool =3D (client =3D=3D NULL || pool_id >=3D MAX_POOLS_PER_DOM=
AIN)
                    ? NULL : client->pools[pool_id];
     uint32_t p;
-    uint64_t *uuid;
     pgp_t *pgp, *pgp2;
     int rc =3D -1;
=20
@@ -2409,9 +2416,7 @@ static NOINLINE int tmemc_save_subop(int
     case TMEMC_SAVE_GET_POOL_UUID:
          if ( pool =3D=3D NULL )
              break;
-        uuid =3D (uint64_t *)buf.p;
-        *uuid++ =3D pool->uuid[0];
-        *uuid =3D pool->uuid[1];
+        tmh_copy_to_client_buf(buf, pool->uuid, 2);
         rc =3D 0;
     case TMEMC_SAVE_END:
         if ( client =3D=3D NULL )
@@ -2436,7 +2441,7 @@ static NOINLINE int tmemc_save_get_next_
     pgp_t *pgp;
     OID oid;
     int ret =3D 0;
-    struct tmem_handle *h;
+    struct tmem_handle h;
     unsigned int pagesize =3D 1 << (pool->pageshift+12);
=20
     if ( pool =3D=3D NULL || is_ephemeral(pool) )
@@ -2467,11 +2472,13 @@ static NOINLINE int tmemc_save_get_next_
                          pgp_t,us.pool_pers_pages);
     pool->cur_pgp =3D pgp;
     oid =3D pgp->us.obj->oid;
-    h =3D (struct tmem_handle *)buf.p;
-    *(OID *)&h->oid[0] =3D oid;
-    h->index =3D pgp->index;
-    buf.p =3D (void *)(h+1);
-    ret =3D do_tmem_get(pool, &oid, h->index,0,0,0,pagesize,buf.p);
+    h.pool_id =3D pool_id;
+    BUILD_BUG_ON(sizeof(h.oid) !=3D sizeof(oid));
+    memcpy(h.oid, oid.oid, sizeof(h.oid));
+    h.index =3D pgp->index;
+    tmh_copy_to_client_buf(buf, &h, 1);
+    tmh_client_buf_add(buf, sizeof(h));
+    ret =3D do_tmem_get(pool, &oid, pgp->index, 0, 0, 0, pagesize, buf);
=20
 out:
     tmem_spin_unlock(&pers_lists_spinlock);
@@ -2483,7 +2490,7 @@ static NOINLINE int tmemc_save_get_next_
 {
     client_t *client =3D tmh_client_from_cli_id(cli_id);
     pgp_t *pgp;
-    struct tmem_handle *h;
+    struct tmem_handle h;
     int ret =3D 0;
=20
     if ( client =3D=3D NULL )
@@ -2509,10 +2516,11 @@ static NOINLINE int tmemc_save_get_next_
                          pgp_t,client_inv_pages);
         client->cur_pgp =3D pgp;
     }
-    h =3D (struct tmem_handle *)buf.p;
-    h->pool_id =3D pgp->pool_id;
-    *(OID *)&h->oid =3D pgp->inv_oid;
-    h->index =3D pgp->index;
+    h.pool_id =3D pgp->pool_id;
+    BUILD_BUG_ON(sizeof(h.oid) !=3D sizeof(pgp->inv_oid));
+    memcpy(h.oid, pgp->inv_oid.oid, sizeof(h.oid));
+    h.index =3D pgp->index;
+    tmh_copy_to_client_buf(buf, &h, 1);
     ret =3D 1;
 out:
     tmem_spin_unlock(&pers_lists_spinlock);
@@ -2528,7 +2536,7 @@ static int tmemc_restore_put_page(int cl
=20
     if ( pool =3D=3D NULL )
         return -1;
-    return do_tmem_put(pool,oidp,index,0,0,0,bufsize,buf.p);
+    return do_tmem_put(pool, oidp, index, 0, 0, 0, bufsize, buf);
 }
=20
 static int tmemc_restore_flush_page(int cli_id, uint32_t pool_id, OID =
*oidp,
@@ -2732,19 +2740,19 @@ EXPORT long do_tmem_op(tmem_cli_op_t uop
         break;
     case TMEM_NEW_PAGE:
         tmem_ensure_avail_pages();
-        rc =3D do_tmem_put(pool, oidp,
-                         op.u.gen.index, op.u.gen.cmfn, 0, 0, 0, NULL);
+        rc =3D do_tmem_put(pool, oidp, op.u.gen.index, op.u.gen.cmfn, 0, =
0, 0,
+                         tmh_cli_buf_null);
         break;
     case TMEM_PUT_PAGE:
         tmem_ensure_avail_pages();
-        rc =3D do_tmem_put(pool, oidp,
-                    op.u.gen.index, op.u.gen.cmfn, 0, 0, PAGE_SIZE, =
NULL);
+        rc =3D do_tmem_put(pool, oidp, op.u.gen.index, op.u.gen.cmfn, 0, =
0,
+                         PAGE_SIZE, tmh_cli_buf_null);
         if (rc =3D=3D 1) succ_put =3D 1;
         else non_succ_put =3D 1;
         break;
     case TMEM_GET_PAGE:
         rc =3D do_tmem_get(pool, oidp, op.u.gen.index, op.u.gen.cmfn,
-                         0, 0, PAGE_SIZE, 0);
+                         0, 0, PAGE_SIZE, tmh_cli_buf_null);
         if (rc =3D=3D 1) succ_get =3D 1;
         else non_succ_get =3D 1;
         break;
@@ -2763,13 +2771,13 @@ EXPORT long do_tmem_op(tmem_cli_op_t uop
     case TMEM_READ:
         rc =3D do_tmem_get(pool, oidp, op.u.gen.index, op.u.gen.cmfn,
                          op.u.gen.tmem_offset, op.u.gen.pfn_offset,
-                         op.u.gen.len,0);
+                         op.u.gen.len, tmh_cli_buf_null);
         break;
     case TMEM_WRITE:
         rc =3D do_tmem_put(pool, oidp,
                          op.u.gen.index, op.u.gen.cmfn,
                          op.u.gen.tmem_offset, op.u.gen.pfn_offset,
-                         op.u.gen.len, NULL);
+                         op.u.gen.len, tmh_cli_buf_null);
         break;
     case TMEM_XCHG:
         /* need to hold global lock to ensure xchg is atomic */
--- a/xen/common/tmem_xen.c
+++ b/xen/common/tmem_xen.c
@@ -51,6 +51,7 @@ DECL_CYC_COUNTER(pg_copy);
 #define LZO_DSTMEM_PAGES 2
 static DEFINE_PER_CPU_READ_MOSTLY(unsigned char *, workmem);
 static DEFINE_PER_CPU_READ_MOSTLY(unsigned char *, dstmem);
+static DEFINE_PER_CPU_READ_MOSTLY(void *, scratch_page);
=20
 #ifdef COMPARE_COPY_PAGE_SSE2
 #include <asm/flushtlb.h>  /* REMOVE ME AFTER TEST */
@@ -115,6 +116,7 @@ static inline void *cli_get_page(tmem_cl
     {
         if ( page )
             put_page(page);
+        return NULL;
     }
=20
     if ( cli_write && !get_page_type(page, PGT_writable_page) )
@@ -144,12 +146,12 @@ static inline void cli_put_page(tmem_cli
=20
 EXPORT int tmh_copy_from_client(pfp_t *pfp,
     tmem_cli_mfn_t cmfn, pagesize_t tmem_offset,
-    pagesize_t pfn_offset, pagesize_t len, void *cli_va)
+    pagesize_t pfn_offset, pagesize_t len, tmem_cli_va_t clibuf)
 {
     unsigned long tmem_mfn, cli_mfn =3D 0;
-    void *tmem_va;
+    char *tmem_va, *cli_va =3D NULL;
     pfp_t *cli_pfp =3D NULL;
-    bool_t tmemc =3D cli_va !=3D NULL; /* if true, cli_va is control-op =
buffer */
+    int rc =3D 1;
=20
     ASSERT(pfp !=3D NULL);
     tmem_mfn =3D page_to_mfn(pfp);
@@ -160,62 +162,76 @@ EXPORT int tmh_copy_from_client(pfp_t *p
         unmap_domain_page(tmem_va);
         return 1;
     }
-    if ( !tmemc )
+    if ( guest_handle_is_null(clibuf) )
     {
         cli_va =3D cli_get_page(cmfn, &cli_mfn, &cli_pfp, 0);
         if ( cli_va =3D=3D NULL )
+        {
+            unmap_domain_page(tmem_va);
             return -EFAULT;
+        }
     }
     mb();
-    if (len =3D=3D PAGE_SIZE && !tmem_offset && !pfn_offset)
+    if ( len =3D=3D PAGE_SIZE && !tmem_offset && !pfn_offset && cli_va )
         tmh_copy_page(tmem_va, cli_va);
     else if ( (tmem_offset+len <=3D PAGE_SIZE) &&
               (pfn_offset+len <=3D PAGE_SIZE) )
-        memcpy((char *)tmem_va+tmem_offset,(char *)cli_va+pfn_offset,len);=

-    if ( !tmemc )
+    {
+        if ( cli_va )
+            memcpy(tmem_va + tmem_offset, cli_va + pfn_offset, len);
+        else if ( copy_from_guest_offset(tmem_va + tmem_offset, clibuf,
+                                         pfn_offset, len) )
+            rc =3D -EFAULT;
+    }
+    if ( cli_va )
         cli_put_page(cmfn, cli_va, cli_pfp, cli_mfn, 0);
     unmap_domain_page(tmem_va);
-    return 1;
+    return rc;
 }
=20
 EXPORT int tmh_compress_from_client(tmem_cli_mfn_t cmfn,
-    void **out_va, size_t *out_len, void *cli_va)
+    void **out_va, size_t *out_len, tmem_cli_va_t clibuf)
 {
     int ret =3D 0;
     unsigned char *dmem =3D this_cpu(dstmem);
     unsigned char *wmem =3D this_cpu(workmem);
+    char *scratch =3D this_cpu(scratch_page);
     pfp_t *cli_pfp =3D NULL;
     unsigned long cli_mfn =3D 0;
-    bool_t tmemc =3D cli_va !=3D NULL; /* if true, cli_va is control-op =
buffer */
+    void *cli_va =3D NULL;
=20
     if ( dmem =3D=3D NULL || wmem =3D=3D NULL )
         return 0;  /* no buffer, so can't compress */
-    if ( !tmemc )
+    if ( guest_handle_is_null(clibuf) )
     {
         cli_va =3D cli_get_page(cmfn, &cli_mfn, &cli_pfp, 0);
         if ( cli_va =3D=3D NULL )
             return -EFAULT;
     }
+    else if ( !scratch )
+        return 0;
+    else if ( copy_from_guest(scratch, clibuf, PAGE_SIZE) )
+        return -EFAULT;
     mb();
-    ret =3D lzo1x_1_compress(cli_va, PAGE_SIZE, dmem, out_len, wmem);
+    ret =3D lzo1x_1_compress(cli_va ?: scratch, PAGE_SIZE, dmem, out_len, =
wmem);
     ASSERT(ret =3D=3D LZO_E_OK);
     *out_va =3D dmem;
-    if ( !tmemc )
+    if ( cli_va )
         cli_put_page(cmfn, cli_va, cli_pfp, cli_mfn, 0);
-    unmap_domain_page(cli_va);
     return 1;
 }
=20
 EXPORT int tmh_copy_to_client(tmem_cli_mfn_t cmfn, pfp_t *pfp,
-    pagesize_t tmem_offset, pagesize_t pfn_offset, pagesize_t len, void =
*cli_va)
+    pagesize_t tmem_offset, pagesize_t pfn_offset, pagesize_t len,
+    tmem_cli_va_t clibuf)
 {
     unsigned long tmem_mfn, cli_mfn =3D 0;
-    void *tmem_va;
+    char *tmem_va, *cli_va =3D NULL;
     pfp_t *cli_pfp =3D NULL;
-    bool_t tmemc =3D cli_va !=3D NULL; /* if true, cli_va is control-op =
buffer */
+    int rc =3D 1;
=20
     ASSERT(pfp !=3D NULL);
-    if ( !tmemc )
+    if ( guest_handle_is_null(clibuf) )
     {
         cli_va =3D cli_get_page(cmfn, &cli_mfn, &cli_pfp, 1);
         if ( cli_va =3D=3D NULL )
@@ -223,37 +239,48 @@ EXPORT int tmh_copy_to_client(tmem_cli_m
     }
     tmem_mfn =3D page_to_mfn(pfp);
     tmem_va =3D map_domain_page(tmem_mfn);
-    if (len =3D=3D PAGE_SIZE && !tmem_offset && !pfn_offset)
+    if ( len =3D=3D PAGE_SIZE && !tmem_offset && !pfn_offset && cli_va )
         tmh_copy_page(cli_va, tmem_va);
     else if ( (tmem_offset+len <=3D PAGE_SIZE) && (pfn_offset+len <=3D =
PAGE_SIZE) )
-        memcpy((char *)cli_va+pfn_offset,(char *)tmem_va+tmem_offset,len);=

+    {
+        if ( cli_va )
+            memcpy(cli_va + pfn_offset, tmem_va + tmem_offset, len);
+        else if ( copy_to_guest_offset(clibuf, pfn_offset,
+                                       tmem_va + tmem_offset, len) )
+            rc =3D -EFAULT;
+    }
     unmap_domain_page(tmem_va);
-    if ( !tmemc )
+    if ( cli_va )
         cli_put_page(cmfn, cli_va, cli_pfp, cli_mfn, 1);
     mb();
-    return 1;
+    return rc;
 }
=20
 EXPORT int tmh_decompress_to_client(tmem_cli_mfn_t cmfn, void *tmem_va,
-                                    size_t size, void *cli_va)
+                                    size_t size, tmem_cli_va_t clibuf)
 {
     unsigned long cli_mfn =3D 0;
     pfp_t *cli_pfp =3D NULL;
+    void *cli_va =3D NULL;
+    char *scratch =3D this_cpu(scratch_page);
     size_t out_len =3D PAGE_SIZE;
-    bool_t tmemc =3D cli_va !=3D NULL; /* if true, cli_va is control-op =
buffer */
     int ret;
=20
-    if ( !tmemc )
+    if ( guest_handle_is_null(clibuf) )
     {
         cli_va =3D cli_get_page(cmfn, &cli_mfn, &cli_pfp, 1);
         if ( cli_va =3D=3D NULL )
             return -EFAULT;
     }
-    ret =3D lzo1x_decompress_safe(tmem_va, size, cli_va, &out_len);
+    else if ( !scratch )
+        return 0;
+    ret =3D lzo1x_decompress_safe(tmem_va, size, cli_va ?: scratch, =
&out_len);
     ASSERT(ret =3D=3D LZO_E_OK);
     ASSERT(out_len =3D=3D PAGE_SIZE);
-    if ( !tmemc )
+    if ( cli_va )
         cli_put_page(cmfn, cli_va, cli_pfp, cli_mfn, 1);
+    else if ( copy_to_guest(clibuf, scratch, PAGE_SIZE) )
+        return -EFAULT;
     mb();
     return 1;
 }
@@ -423,6 +450,11 @@ static int cpu_callback(
             struct page_info *p =3D alloc_domheap_pages(0, workmem_order, =
0);
             per_cpu(workmem, cpu) =3D p ? page_to_virt(p) : NULL;
         }
+        if ( per_cpu(scratch_page, cpu) =3D=3D NULL )
+        {
+            struct page_info *p =3D alloc_domheap_page(NULL, 0);
+            per_cpu(scratch_page, cpu) =3D p ? page_to_virt(p) : NULL;
+        }
         break;
     }
     case CPU_DEAD:
@@ -439,6 +471,11 @@ static int cpu_callback(
             free_domheap_pages(p, workmem_order);
             per_cpu(workmem, cpu) =3D NULL;
         }
+        if ( per_cpu(scratch_page, cpu) !=3D NULL )
+        {
+            free_domheap_page(virt_to_page(per_cpu(scratch_page, cpu)));
+            per_cpu(scratch_page, cpu) =3D NULL;
+        }
         break;
     }
     default:
--- a/xen/include/xen/tmem_xen.h
+++ b/xen/include/xen/tmem_xen.h
@@ -482,27 +482,33 @@ static inline int tmh_get_tmemop_from_cl
     return copy_from_guest(op, uops, 1);
 }
=20
+#define tmh_cli_buf_null guest_handle_from_ptr(NULL, char)
+
 static inline void tmh_copy_to_client_buf_offset(tmem_cli_va_t clibuf, =
int off,
                                            char *tmembuf, int len)
 {
     copy_to_guest_offset(clibuf,off,tmembuf,len);
 }
=20
+#define tmh_copy_to_client_buf(clibuf, tmembuf, cnt) \
+    copy_to_guest(guest_handle_cast(clibuf, void), tmembuf, cnt)
+
+#define tmh_client_buf_add guest_handle_add_offset
+
 #define TMH_CLI_ID_NULL ((cli_id_t)((domid_t)-1L))
=20
 #define tmh_cli_id_str "domid"
 #define tmh_client_str "domain"
=20
-extern int tmh_decompress_to_client(tmem_cli_mfn_t,void*,size_t,void*);
+int tmh_decompress_to_client(tmem_cli_mfn_t, void *, size_t, tmem_cli_va_t=
);
=20
-extern int tmh_compress_from_client(tmem_cli_mfn_t,void**,size_t =
*,void*);
+int tmh_compress_from_client(tmem_cli_mfn_t, void **, size_t *, tmem_cli_v=
a_t);
=20
-extern int tmh_copy_from_client(pfp_t *pfp,
-    tmem_cli_mfn_t cmfn, pagesize_t tmem_offset,
-    pagesize_t pfn_offset, pagesize_t len, void *cva);
+int tmh_copy_from_client(pfp_t *, tmem_cli_mfn_t, pagesize_t tmem_offset,
+    pagesize_t pfn_offset, pagesize_t len, tmem_cli_va_t);
=20
-extern int tmh_copy_to_client(tmem_cli_mfn_t cmfn, pfp_t *pfp,
-    pagesize_t tmem_offset, pagesize_t pfn_offset, pagesize_t len, void =
*cva);
+int tmh_copy_to_client(tmem_cli_mfn_t, pfp_t *, pagesize_t tmem_offset,
+    pagesize_t pfn_offset, pagesize_t len, tmem_cli_va_t);
=20
 extern int tmh_copy_tze_to_client(tmem_cli_mfn_t cmfn, void *tmem_va, =
pagesize_t len);
=20



--=__Part56674C6E.0__=
Content-Type: text/plain; name="tmem-xsa-15-5.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="tmem-xsa-15-5.patch"

tmem: don't access guest memory without using the accessors intended for =
this=0A=0AThis is not permitted, not even for buffers coming from Dom0 =
(and it=0Awould also break the moment Dom0 runs in HVM mode). An implicatio=
n from=0Athe changes here is that tmh_copy_page() can't be used anymore =
for=0Acontrol operations calling tmh_copy_{from,to}_client() (as those =
pass=0Athe buffer by virtual address rather than MFN).=0A=0ANote that =
tmemc_save_get_next_page() previously didn't set the returned=0Ahandle's =
pool_id field, while the new code does. It need to be=0Aconfirmed that =
this is not a problem (otherwise the copy-out operation=0Awill require =
further tmh_...() abstractions to be added).=0A=0AFurther note that the =
patch removes (rather than adjusts) an invalid=0Acall to unmap_domain_page(=
) (no matching map_domain_page()) from=0Atmh_compress_from_client() and =
adds a missing one to an error return=0Apath in tmh_copy_from_client().=0A=
=0AFinally note that the patch adds a previously missing return =
statement=0Ato cli_get_page() (without which that function could de-referen=
ce a=0ANULL pointer, triggerable from guest mode).=0A=0AThis is part of =
XSA-15 / CVE-2012-3497.=0A=0ASigned-off-by: Jan Beulich <jbeulich@suse.com>=
=0A=0A--- a/xen/common/tmem.c=0A+++ b/xen/common/tmem.c=0A@@ -388,11 =
+388,13 @@ static NOINLINE int pcd_copy_to_client(t=0A     pcd =3D =
pgp->pcd;=0A     if ( pgp->size < PAGE_SIZE && pgp->size !=3D 0 &&=0A      =
    pcd->size < PAGE_SIZE && pcd->size !=3D 0 )=0A-        ret =3D =
tmh_decompress_to_client(cmfn, pcd->cdata, pcd->size, NULL);=0A+        =
ret =3D tmh_decompress_to_client(cmfn, pcd->cdata, pcd->size,=0A+          =
                             tmh_cli_buf_null);=0A     else if ( tmh_tze_en=
abled() && pcd->size < PAGE_SIZE )=0A         ret =3D tmh_copy_tze_to_clien=
t(cmfn, pcd->tze, pcd->size);=0A     else=0A-        ret =3D tmh_copy_to_cl=
ient(cmfn, pcd->pfp, 0, 0, PAGE_SIZE, NULL);=0A+        ret =3D tmh_copy_to=
_client(cmfn, pcd->pfp, 0, 0, PAGE_SIZE,=0A+                               =
  tmh_cli_buf_null);=0A     tmem_read_unlock(&pcd_tree_rwlocks[firstbyte]);=
=0A     return ret;=0A }=0A@@ -1444,7 +1446,7 @@ static inline void =
tmem_ensure_avail_pag=0A /************ TMEM CORE OPERATIONS ***************=
*********************/=0A =0A static NOINLINE int do_tmem_put_compress(pgp_=
t *pgp, tmem_cli_mfn_t cmfn,=0A-                                         =
void *cva)=0A+                                         tmem_cli_va_t =
clibuf)=0A {=0A     void *dst, *p;=0A     size_t size;=0A@@ -1463,7 =
+1465,7 @@ static NOINLINE int do_tmem_put_compress=0A     if ( pgp->pfp =
!=3D NULL )=0A         pgp_free_data(pgp, pgp->us.obj->pool);=0A     =
START_CYC_COUNTER(compress);=0A-    ret =3D tmh_compress_from_client(cmfn, =
&dst, &size, cva);=0A+    ret =3D tmh_compress_from_client(cmfn, &dst, =
&size, clibuf);=0A     if ( (ret =3D=3D -EFAULT) || (ret =3D=3D 0) )=0A    =
     goto out;=0A     else if ( (size =3D=3D 0) || (size >=3D tmem_subpage_=
maxsize()) ) {=0A@@ -1490,7 +1492,8 @@ out:=0A }=0A =0A static NOINLINE =
int do_tmem_dup_put(pgp_t *pgp, tmem_cli_mfn_t cmfn,=0A-       pagesize_t =
tmem_offset, pagesize_t pfn_offset, pagesize_t len, void *cva)=0A+       =
pagesize_t tmem_offset, pagesize_t pfn_offset, pagesize_t len,=0A+       =
tmem_cli_va_t clibuf)=0A {=0A     pool_t *pool;=0A     obj_t *obj;=0A@@ =
-1512,7 +1515,7 @@ static NOINLINE int do_tmem_dup_put(pgp_=0A     /* can =
we successfully manipulate pgp to change out the data? */=0A     if ( len =
!=3D 0 && client->compress && pgp->size !=3D 0 )=0A     {=0A-        ret =
=3D do_tmem_put_compress(pgp,cmfn,cva);=0A+        ret =3D do_tmem_put_comp=
ress(pgp, cmfn, clibuf);=0A         if ( ret =3D=3D 1 )=0A             =
goto done;=0A         else if ( ret =3D=3D 0 )=0A@@ -1530,7 +1533,8 @@ =
copy_uncompressed:=0A         goto failed_dup;=0A     pgp->size =3D 0;=0A  =
   /* tmh_copy_from_client properly handles len=3D=3D0 and offsets !=3D 0 =
*/=0A-    ret =3D tmh_copy_from_client(pgp->pfp,cmfn,tmem_offset,pfn_offset=
,len,0);=0A+    ret =3D tmh_copy_from_client(pgp->pfp, cmfn, tmem_offset, =
pfn_offset, len,=0A+                               tmh_cli_buf_null);=0A   =
  if ( ret =3D=3D -EFAULT )=0A         goto bad_copy;=0A     if ( =
tmh_dedup_enabled() && !is_persistent(pool) )=0A@@ -1582,7 +1586,7 @@ =
cleanup:=0A static NOINLINE int do_tmem_put(pool_t *pool,=0A               =
OID *oidp, uint32_t index,=0A               tmem_cli_mfn_t cmfn, pagesize_t=
 tmem_offset,=0A-              pagesize_t pfn_offset, pagesize_t len, void =
*cva)=0A+              pagesize_t pfn_offset, pagesize_t len, tmem_cli_va_t=
 clibuf)=0A {=0A     obj_t *obj =3D NULL, *objfound =3D NULL, *objnew =3D =
NULL;=0A     pgp_t *pgp =3D NULL, *pgpdel =3D NULL;=0A@@ -1596,7 +1600,8 =
@@ static NOINLINE int do_tmem_put(pool_t *=0A     {=0A         ASSERT_SPIN=
LOCK(&objfound->obj_spinlock);=0A         if ((pgp =3D pgp_lookup_in_obj(ob=
jfound, index)) !=3D NULL)=0A-            return do_tmem_dup_put(pgp,cmfn,t=
mem_offset,pfn_offset,len,cva);=0A+            return do_tmem_dup_put(pgp, =
cmfn, tmem_offset, pfn_offset, len,=0A+                                   =
clibuf);=0A     }=0A =0A     /* no puts allowed into a frozen pool (except =
dup puts) */=0A@@ -1631,7 +1636,7 @@ static NOINLINE int do_tmem_put(pool_t=
 *=0A     if ( len !=3D 0 && client->compress )=0A     {=0A         =
ASSERT(pgp->pfp =3D=3D NULL);=0A-        ret =3D do_tmem_put_compress(pgp,c=
mfn,cva);=0A+        ret =3D do_tmem_put_compress(pgp, cmfn, clibuf);=0A   =
      if ( ret =3D=3D 1 )=0A             goto insert_page;=0A         if ( =
ret =3D=3D -ENOMEM )=0A@@ -1655,7 +1660,8 @@ copy_uncompressed:=0A         =
goto delete_and_free;=0A     }=0A     /* tmh_copy_from_client properly =
handles len=3D=3D0 (TMEM_NEW_PAGE) */=0A-    ret =3D tmh_copy_from_client(p=
gp->pfp,cmfn,tmem_offset,pfn_offset,len,cva);=0A+    ret =3D tmh_copy_from_=
client(pgp->pfp, cmfn, tmem_offset, pfn_offset, len,=0A+                   =
            clibuf);=0A     if ( ret =3D=3D -EFAULT )=0A         goto =
bad_copy;=0A     if ( tmh_dedup_enabled() && !is_persistent(pool) )=0A@@ =
-1725,12 +1731,13 @@ free:=0A =0A static NOINLINE int do_tmem_get(pool_t =
*pool, OID *oidp, uint32_t index,=0A               tmem_cli_mfn_t cmfn, =
pagesize_t tmem_offset,=0A-              pagesize_t pfn_offset, pagesize_t =
len, void *cva)=0A+              pagesize_t pfn_offset, pagesize_t len, =
tmem_cli_va_t clibuf)=0A {=0A     obj_t *obj;=0A     pgp_t *pgp;=0A     =
client_t *client =3D pool->client;=0A     DECL_LOCAL_CYC_COUNTER(decompress=
);=0A+    int rc =3D -EFAULT;=0A =0A     if ( !_atomic_read(pool->pgp_count=
) )=0A         return -EEMPTY;=0A@@ -1755,16 +1762,18 @@ static NOINLINE =
int do_tmem_get(pool_t *=0A     if ( tmh_dedup_enabled() && !is_persistent(=
pool) &&=0A               pgp->firstbyte !=3D NOT_SHAREABLE )=0A     {=0A- =
       if ( pcd_copy_to_client(cmfn, pgp) =3D=3D -EFAULT )=0A+        rc =
=3D pcd_copy_to_client(cmfn, pgp);=0A+        if ( rc <=3D 0 )=0A          =
   goto bad_copy;=0A     } else if ( pgp->size !=3D 0 ) {=0A         =
START_CYC_COUNTER(decompress);=0A-        if ( tmh_decompress_to_client(cmf=
n, pgp->cdata,=0A-                                      pgp->size, cva) =
=3D=3D -EFAULT )=0A+        rc =3D tmh_decompress_to_client(cmfn, =
pgp->cdata,=0A+                                      pgp->size, clibuf);=0A=
+        if ( rc <=3D 0 )=0A             goto bad_copy;=0A         =
END_CYC_COUNTER(decompress);=0A     } else if ( tmh_copy_to_client(cmfn, =
pgp->pfp, tmem_offset,=0A-                                 pfn_offset, =
len, cva) =3D=3D -EFAULT)=0A+                                 pfn_offset, =
len, clibuf) =3D=3D -EFAULT)=0A         goto bad_copy;=0A     if ( =
is_ephemeral(pool) )=0A     {=0A@@ -1804,8 +1813,7 @@ static NOINLINE int =
do_tmem_get(pool_t *=0A bad_copy:=0A     /* this should only happen if the =
client passed a bad mfn */=0A     failed_copies++;=0A-    return =
-EFAULT;=0A-=0A+    return rc;=0A }=0A =0A static NOINLINE int do_tmem_flus=
h_page(pool_t *pool, OID *oidp, uint32_t index)=0A@@ -2345,7 +2353,6 @@ =
static NOINLINE int tmemc_save_subop(int=0A     pool_t *pool =3D (client =
=3D=3D NULL || pool_id >=3D MAX_POOLS_PER_DOMAIN)=0A                    ? =
NULL : client->pools[pool_id];=0A     uint32_t p;=0A-    uint64_t =
*uuid;=0A     pgp_t *pgp, *pgp2;=0A     int rc =3D -1;=0A =0A@@ -2409,9 =
+2416,7 @@ static NOINLINE int tmemc_save_subop(int=0A     case TMEMC_SAVE_=
GET_POOL_UUID:=0A          if ( pool =3D=3D NULL )=0A              =
break;=0A-        uuid =3D (uint64_t *)buf.p;=0A-        *uuid++ =3D =
pool->uuid[0];=0A-        *uuid =3D pool->uuid[1];=0A+        tmh_copy_to_c=
lient_buf(buf, pool->uuid, 2);=0A         rc =3D 0;=0A     case TMEMC_SAVE_=
END:=0A         if ( client =3D=3D NULL )=0A@@ -2436,7 +2441,7 @@ static =
NOINLINE int tmemc_save_get_next_=0A     pgp_t *pgp;=0A     OID oid;=0A    =
 int ret =3D 0;=0A-    struct tmem_handle *h;=0A+    struct tmem_handle =
h;=0A     unsigned int pagesize =3D 1 << (pool->pageshift+12);=0A =0A     =
if ( pool =3D=3D NULL || is_ephemeral(pool) )=0A@@ -2467,11 +2472,13 @@ =
static NOINLINE int tmemc_save_get_next_=0A                          =
pgp_t,us.pool_pers_pages);=0A     pool->cur_pgp =3D pgp;=0A     oid =3D =
pgp->us.obj->oid;=0A-    h =3D (struct tmem_handle *)buf.p;=0A-    *(OID =
*)&h->oid[0] =3D oid;=0A-    h->index =3D pgp->index;=0A-    buf.p =3D =
(void *)(h+1);=0A-    ret =3D do_tmem_get(pool, &oid, h->index,0,0,0,pagesi=
ze,buf.p);=0A+    h.pool_id =3D pool_id;=0A+    BUILD_BUG_ON(sizeof(h.oid) =
!=3D sizeof(oid));=0A+    memcpy(h.oid, oid.oid, sizeof(h.oid));=0A+    =
h.index =3D pgp->index;=0A+    tmh_copy_to_client_buf(buf, &h, 1);=0A+    =
tmh_client_buf_add(buf, sizeof(h));=0A+    ret =3D do_tmem_get(pool, &oid, =
pgp->index, 0, 0, 0, pagesize, buf);=0A =0A out:=0A     tmem_spin_unlock(&p=
ers_lists_spinlock);=0A@@ -2483,7 +2490,7 @@ static NOINLINE int tmemc_save=
_get_next_=0A {=0A     client_t *client =3D tmh_client_from_cli_id(cli_id);=
=0A     pgp_t *pgp;=0A-    struct tmem_handle *h;=0A+    struct tmem_handle=
 h;=0A     int ret =3D 0;=0A =0A     if ( client =3D=3D NULL )=0A@@ =
-2509,10 +2516,11 @@ static NOINLINE int tmemc_save_get_next_=0A           =
               pgp_t,client_inv_pages);=0A         client->cur_pgp =3D =
pgp;=0A     }=0A-    h =3D (struct tmem_handle *)buf.p;=0A-    h->pool_id =
=3D pgp->pool_id;=0A-    *(OID *)&h->oid =3D pgp->inv_oid;=0A-    h->index =
=3D pgp->index;=0A+    h.pool_id =3D pgp->pool_id;=0A+    BUILD_BUG_ON(size=
of(h.oid) !=3D sizeof(pgp->inv_oid));=0A+    memcpy(h.oid, pgp->inv_oid.oid=
, sizeof(h.oid));=0A+    h.index =3D pgp->index;=0A+    tmh_copy_to_client_=
buf(buf, &h, 1);=0A     ret =3D 1;=0A out:=0A     tmem_spin_unlock(&pers_li=
sts_spinlock);=0A@@ -2528,7 +2536,7 @@ static int tmemc_restore_put_page(in=
t cl=0A =0A     if ( pool =3D=3D NULL )=0A         return -1;=0A-    =
return do_tmem_put(pool,oidp,index,0,0,0,bufsize,buf.p);=0A+    return =
do_tmem_put(pool, oidp, index, 0, 0, 0, bufsize, buf);=0A }=0A =0A static =
int tmemc_restore_flush_page(int cli_id, uint32_t pool_id, OID *oidp,=0A@@ =
-2732,19 +2740,19 @@ EXPORT long do_tmem_op(tmem_cli_op_t uop=0A         =
break;=0A     case TMEM_NEW_PAGE:=0A         tmem_ensure_avail_pages();=0A-=
        rc =3D do_tmem_put(pool, oidp,=0A-                         =
op.u.gen.index, op.u.gen.cmfn, 0, 0, 0, NULL);=0A+        rc =3D do_tmem_pu=
t(pool, oidp, op.u.gen.index, op.u.gen.cmfn, 0, 0, 0,=0A+                  =
       tmh_cli_buf_null);=0A         break;=0A     case TMEM_PUT_PAGE:=0A  =
       tmem_ensure_avail_pages();=0A-        rc =3D do_tmem_put(pool, =
oidp,=0A-                    op.u.gen.index, op.u.gen.cmfn, 0, 0, =
PAGE_SIZE, NULL);=0A+        rc =3D do_tmem_put(pool, oidp, op.u.gen.index,=
 op.u.gen.cmfn, 0, 0,=0A+                         PAGE_SIZE, tmh_cli_buf_nu=
ll);=0A         if (rc =3D=3D 1) succ_put =3D 1;=0A         else non_succ_p=
ut =3D 1;=0A         break;=0A     case TMEM_GET_PAGE:=0A         rc =3D =
do_tmem_get(pool, oidp, op.u.gen.index, op.u.gen.cmfn,=0A-                 =
        0, 0, PAGE_SIZE, 0);=0A+                         0, 0, PAGE_SIZE, =
tmh_cli_buf_null);=0A         if (rc =3D=3D 1) succ_get =3D 1;=0A         =
else non_succ_get =3D 1;=0A         break;=0A@@ -2763,13 +2771,13 @@ =
EXPORT long do_tmem_op(tmem_cli_op_t uop=0A     case TMEM_READ:=0A         =
rc =3D do_tmem_get(pool, oidp, op.u.gen.index, op.u.gen.cmfn,=0A           =
               op.u.gen.tmem_offset, op.u.gen.pfn_offset,=0A-              =
           op.u.gen.len,0);=0A+                         op.u.gen.len, =
tmh_cli_buf_null);=0A         break;=0A     case TMEM_WRITE:=0A         rc =
=3D do_tmem_put(pool, oidp,=0A                          op.u.gen.index, =
op.u.gen.cmfn,=0A                          op.u.gen.tmem_offset, op.u.gen.p=
fn_offset,=0A-                         op.u.gen.len, NULL);=0A+            =
             op.u.gen.len, tmh_cli_buf_null);=0A         break;=0A     =
case TMEM_XCHG:=0A         /* need to hold global lock to ensure xchg is =
atomic */=0A--- a/xen/common/tmem_xen.c=0A+++ b/xen/common/tmem_xen.c=0A@@ =
-51,6 +51,7 @@ DECL_CYC_COUNTER(pg_copy);=0A #define LZO_DSTMEM_PAGES 2=0A =
static DEFINE_PER_CPU_READ_MOSTLY(unsigned char *, workmem);=0A static =
DEFINE_PER_CPU_READ_MOSTLY(unsigned char *, dstmem);=0A+static DEFINE_PER_C=
PU_READ_MOSTLY(void *, scratch_page);=0A =0A #ifdef COMPARE_COPY_PAGE_SSE2=
=0A #include <asm/flushtlb.h>  /* REMOVE ME AFTER TEST */=0A@@ -115,6 =
+116,7 @@ static inline void *cli_get_page(tmem_cl=0A     {=0A         if =
( page )=0A             put_page(page);=0A+        return NULL;=0A     =
}=0A =0A     if ( cli_write && !get_page_type(page, PGT_writable_page) =
)=0A@@ -144,12 +146,12 @@ static inline void cli_put_page(tmem_cli=0A =0A =
EXPORT int tmh_copy_from_client(pfp_t *pfp,=0A     tmem_cli_mfn_t cmfn, =
pagesize_t tmem_offset,=0A-    pagesize_t pfn_offset, pagesize_t len, void =
*cli_va)=0A+    pagesize_t pfn_offset, pagesize_t len, tmem_cli_va_t =
clibuf)=0A {=0A     unsigned long tmem_mfn, cli_mfn =3D 0;=0A-    void =
*tmem_va;=0A+    char *tmem_va, *cli_va =3D NULL;=0A     pfp_t *cli_pfp =
=3D NULL;=0A-    bool_t tmemc =3D cli_va !=3D NULL; /* if true, cli_va is =
control-op buffer */=0A+    int rc =3D 1;=0A =0A     ASSERT(pfp !=3D =
NULL);=0A     tmem_mfn =3D page_to_mfn(pfp);=0A@@ -160,62 +162,76 @@ =
EXPORT int tmh_copy_from_client(pfp_t *p=0A         unmap_domain_page(tmem_=
va);=0A         return 1;=0A     }=0A-    if ( !tmemc )=0A+    if ( =
guest_handle_is_null(clibuf) )=0A     {=0A         cli_va =3D cli_get_page(=
cmfn, &cli_mfn, &cli_pfp, 0);=0A         if ( cli_va =3D=3D NULL )=0A+     =
   {=0A+            unmap_domain_page(tmem_va);=0A             return =
-EFAULT;=0A+        }=0A     }=0A     mb();=0A-    if (len =3D=3D =
PAGE_SIZE && !tmem_offset && !pfn_offset)=0A+    if ( len =3D=3D PAGE_SIZE =
&& !tmem_offset && !pfn_offset && cli_va )=0A         tmh_copy_page(tmem_va=
, cli_va);=0A     else if ( (tmem_offset+len <=3D PAGE_SIZE) &&=0A         =
      (pfn_offset+len <=3D PAGE_SIZE) )=0A-        memcpy((char *)tmem_va+t=
mem_offset,(char *)cli_va+pfn_offset,len);=0A-    if ( !tmemc )=0A+    =
{=0A+        if ( cli_va )=0A+            memcpy(tmem_va + tmem_offset, =
cli_va + pfn_offset, len);=0A+        else if ( copy_from_guest_offset(tmem=
_va + tmem_offset, clibuf,=0A+                                         =
pfn_offset, len) )=0A+            rc =3D -EFAULT;=0A+    }=0A+    if ( =
cli_va )=0A         cli_put_page(cmfn, cli_va, cli_pfp, cli_mfn, 0);=0A    =
 unmap_domain_page(tmem_va);=0A-    return 1;=0A+    return rc;=0A }=0A =
=0A EXPORT int tmh_compress_from_client(tmem_cli_mfn_t cmfn,=0A-    void =
**out_va, size_t *out_len, void *cli_va)=0A+    void **out_va, size_t =
*out_len, tmem_cli_va_t clibuf)=0A {=0A     int ret =3D 0;=0A     unsigned =
char *dmem =3D this_cpu(dstmem);=0A     unsigned char *wmem =3D this_cpu(wo=
rkmem);=0A+    char *scratch =3D this_cpu(scratch_page);=0A     pfp_t =
*cli_pfp =3D NULL;=0A     unsigned long cli_mfn =3D 0;=0A-    bool_t tmemc =
=3D cli_va !=3D NULL; /* if true, cli_va is control-op buffer */=0A+    =
void *cli_va =3D NULL;=0A =0A     if ( dmem =3D=3D NULL || wmem =3D=3D =
NULL )=0A         return 0;  /* no buffer, so can't compress */=0A-    if =
( !tmemc )=0A+    if ( guest_handle_is_null(clibuf) )=0A     {=0A         =
cli_va =3D cli_get_page(cmfn, &cli_mfn, &cli_pfp, 0);=0A         if ( =
cli_va =3D=3D NULL )=0A             return -EFAULT;=0A     }=0A+    else =
if ( !scratch )=0A+        return 0;=0A+    else if ( copy_from_guest(scrat=
ch, clibuf, PAGE_SIZE) )=0A+        return -EFAULT;=0A     mb();=0A-    =
ret =3D lzo1x_1_compress(cli_va, PAGE_SIZE, dmem, out_len, wmem);=0A+    =
ret =3D lzo1x_1_compress(cli_va ?: scratch, PAGE_SIZE, dmem, out_len, =
wmem);=0A     ASSERT(ret =3D=3D LZO_E_OK);=0A     *out_va =3D dmem;=0A-    =
if ( !tmemc )=0A+    if ( cli_va )=0A         cli_put_page(cmfn, cli_va, =
cli_pfp, cli_mfn, 0);=0A-    unmap_domain_page(cli_va);=0A     return =
1;=0A }=0A =0A EXPORT int tmh_copy_to_client(tmem_cli_mfn_t cmfn, pfp_t =
*pfp,=0A-    pagesize_t tmem_offset, pagesize_t pfn_offset, pagesize_t =
len, void *cli_va)=0A+    pagesize_t tmem_offset, pagesize_t pfn_offset, =
pagesize_t len,=0A+    tmem_cli_va_t clibuf)=0A {=0A     unsigned long =
tmem_mfn, cli_mfn =3D 0;=0A-    void *tmem_va;=0A+    char *tmem_va, =
*cli_va =3D NULL;=0A     pfp_t *cli_pfp =3D NULL;=0A-    bool_t tmemc =3D =
cli_va !=3D NULL; /* if true, cli_va is control-op buffer */=0A+    int rc =
=3D 1;=0A =0A     ASSERT(pfp !=3D NULL);=0A-    if ( !tmemc )=0A+    if ( =
guest_handle_is_null(clibuf) )=0A     {=0A         cli_va =3D cli_get_page(=
cmfn, &cli_mfn, &cli_pfp, 1);=0A         if ( cli_va =3D=3D NULL )=0A@@ =
-223,37 +239,48 @@ EXPORT int tmh_copy_to_client(tmem_cli_m=0A     }=0A    =
 tmem_mfn =3D page_to_mfn(pfp);=0A     tmem_va =3D map_domain_page(tmem_mfn=
);=0A-    if (len =3D=3D PAGE_SIZE && !tmem_offset && !pfn_offset)=0A+    =
if ( len =3D=3D PAGE_SIZE && !tmem_offset && !pfn_offset && cli_va )=0A    =
     tmh_copy_page(cli_va, tmem_va);=0A     else if ( (tmem_offset+len =
<=3D PAGE_SIZE) && (pfn_offset+len <=3D PAGE_SIZE) )=0A-        memcpy((cha=
r *)cli_va+pfn_offset,(char *)tmem_va+tmem_offset,len);=0A+    {=0A+       =
 if ( cli_va )=0A+            memcpy(cli_va + pfn_offset, tmem_va + =
tmem_offset, len);=0A+        else if ( copy_to_guest_offset(clibuf, =
pfn_offset,=0A+                                       tmem_va + tmem_offset=
, len) )=0A+            rc =3D -EFAULT;=0A+    }=0A     unmap_domain_page(t=
mem_va);=0A-    if ( !tmemc )=0A+    if ( cli_va )=0A         cli_put_page(=
cmfn, cli_va, cli_pfp, cli_mfn, 1);=0A     mb();=0A-    return 1;=0A+    =
return rc;=0A }=0A =0A EXPORT int tmh_decompress_to_client(tmem_cli_mfn_t =
cmfn, void *tmem_va,=0A-                                    size_t size, =
void *cli_va)=0A+                                    size_t size, =
tmem_cli_va_t clibuf)=0A {=0A     unsigned long cli_mfn =3D 0;=0A     =
pfp_t *cli_pfp =3D NULL;=0A+    void *cli_va =3D NULL;=0A+    char =
*scratch =3D this_cpu(scratch_page);=0A     size_t out_len =3D PAGE_SIZE;=
=0A-    bool_t tmemc =3D cli_va !=3D NULL; /* if true, cli_va is control-op=
 buffer */=0A     int ret;=0A =0A-    if ( !tmemc )=0A+    if ( guest_handl=
e_is_null(clibuf) )=0A     {=0A         cli_va =3D cli_get_page(cmfn, =
&cli_mfn, &cli_pfp, 1);=0A         if ( cli_va =3D=3D NULL )=0A            =
 return -EFAULT;=0A     }=0A-    ret =3D lzo1x_decompress_safe(tmem_va, =
size, cli_va, &out_len);=0A+    else if ( !scratch )=0A+        return =
0;=0A+    ret =3D lzo1x_decompress_safe(tmem_va, size, cli_va ?: scratch, =
&out_len);=0A     ASSERT(ret =3D=3D LZO_E_OK);=0A     ASSERT(out_len =
=3D=3D PAGE_SIZE);=0A-    if ( !tmemc )=0A+    if ( cli_va )=0A         =
cli_put_page(cmfn, cli_va, cli_pfp, cli_mfn, 1);=0A+    else if ( =
copy_to_guest(clibuf, scratch, PAGE_SIZE) )=0A+        return -EFAULT;=0A  =
   mb();=0A     return 1;=0A }=0A@@ -423,6 +450,11 @@ static int cpu_callba=
ck(=0A             struct page_info *p =3D alloc_domheap_pages(0, =
workmem_order, 0);=0A             per_cpu(workmem, cpu) =3D p ? page_to_vir=
t(p) : NULL;=0A         }=0A+        if ( per_cpu(scratch_page, cpu) =
=3D=3D NULL )=0A+        {=0A+            struct page_info *p =3D =
alloc_domheap_page(NULL, 0);=0A+            per_cpu(scratch_page, cpu) =3D =
p ? page_to_virt(p) : NULL;=0A+        }=0A         break;=0A     }=0A     =
case CPU_DEAD:=0A@@ -439,6 +471,11 @@ static int cpu_callback(=0A          =
   free_domheap_pages(p, workmem_order);=0A             per_cpu(workmem, =
cpu) =3D NULL;=0A         }=0A+        if ( per_cpu(scratch_page, cpu) =
!=3D NULL )=0A+        {=0A+            free_domheap_page(virt_to_page(per_=
cpu(scratch_page, cpu)));=0A+            per_cpu(scratch_page, cpu) =3D =
NULL;=0A+        }=0A         break;=0A     }=0A     default:=0A--- =
a/xen/include/xen/tmem_xen.h=0A+++ b/xen/include/xen/tmem_xen.h=0A@@ =
-482,27 +482,33 @@ static inline int tmh_get_tmemop_from_cl=0A     return =
copy_from_guest(op, uops, 1);=0A }=0A =0A+#define tmh_cli_buf_null =
guest_handle_from_ptr(NULL, char)=0A+=0A static inline void tmh_copy_to_cli=
ent_buf_offset(tmem_cli_va_t clibuf, int off,=0A                           =
                 char *tmembuf, int len)=0A {=0A     copy_to_guest_offset(c=
libuf,off,tmembuf,len);=0A }=0A =0A+#define tmh_copy_to_client_buf(clibuf, =
tmembuf, cnt) \=0A+    copy_to_guest(guest_handle_cast(clibuf, void), =
tmembuf, cnt)=0A+=0A+#define tmh_client_buf_add guest_handle_add_offset=0A+=
=0A #define TMH_CLI_ID_NULL ((cli_id_t)((domid_t)-1L))=0A =0A #define =
tmh_cli_id_str "domid"=0A #define tmh_client_str "domain"=0A =0A-extern =
int tmh_decompress_to_client(tmem_cli_mfn_t,void*,size_t,void*);=0A+int =
tmh_decompress_to_client(tmem_cli_mfn_t, void *, size_t, tmem_cli_va_t);=0A=
 =0A-extern int tmh_compress_from_client(tmem_cli_mfn_t,void**,size_t =
*,void*);=0A+int tmh_compress_from_client(tmem_cli_mfn_t, void **, size_t =
*, tmem_cli_va_t);=0A =0A-extern int tmh_copy_from_client(pfp_t *pfp,=0A-  =
  tmem_cli_mfn_t cmfn, pagesize_t tmem_offset,=0A-    pagesize_t pfn_offset=
, pagesize_t len, void *cva);=0A+int tmh_copy_from_client(pfp_t *, =
tmem_cli_mfn_t, pagesize_t tmem_offset,=0A+    pagesize_t pfn_offset, =
pagesize_t len, tmem_cli_va_t);=0A =0A-extern int tmh_copy_to_client(tmem_c=
li_mfn_t cmfn, pfp_t *pfp,=0A-    pagesize_t tmem_offset, pagesize_t =
pfn_offset, pagesize_t len, void *cva);=0A+int tmh_copy_to_client(tmem_cli_=
mfn_t, pfp_t *, pagesize_t tmem_offset,=0A+    pagesize_t pfn_offset, =
pagesize_t len, tmem_cli_va_t);=0A =0A extern int tmh_copy_tze_to_client(tm=
em_cli_mfn_t cmfn, void *tmem_va, pagesize_t len);=0A =0A
--=__Part56674C6E.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

--=__Part56674C6E.0__=--


From xen-devel-bounces@lists.xen.org Wed Sep 05 12:37:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Sep 2012 12:37:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9Eqq-0005Bg-AC; Wed, 05 Sep 2012 12:37:00 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1T9Eqo-0005BC-Ge
	for xen-devel@lists.xen.org; Wed, 05 Sep 2012 12:36:59 +0000
Received: from [85.158.143.35:9958] by server-2.bemta-4.messagelabs.com id
	15/36-21239-96747405; Wed, 05 Sep 2012 12:36:57 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1346848595!13410630!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQwMzE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26056 invoked from network); 5 Sep 2012 12:36:35 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-3.tower-21.messagelabs.com with SMTP;
	5 Sep 2012 12:36:35 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 05 Sep 2012 13:36:33 +0100
Message-Id: <5047639E0200007800098DD1@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 05 Sep 2012 13:37:18 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part56674C6E.0__="
Cc: dan.magenheimer@oracle.com, Zhenzhong Duan <zhenzhong.duan@oracle.com>
Subject: [Xen-devel] [PATCH 05/11] tmem: don't access guest memory without
 using the accessors intended for this
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<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.

--=__Part56674C6E.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

This is not permitted, not even for buffers coming from Dom0 (and it
would also break the moment Dom0 runs in HVM mode). An implication from
the changes here is that tmh_copy_page() can't be used anymore for
control operations calling tmh_copy_{from,to}_client() (as those pass
the buffer by virtual address rather than MFN).

Note that tmemc_save_get_next_page() previously didn't set the returned
handle's pool_id field, while the new code does. It need to be
confirmed that this is not a problem (otherwise the copy-out operation
will require further tmh_...() abstractions to be added).

Further note that the patch removes (rather than adjusts) an invalid
call to unmap_domain_page() (no matching map_domain_page()) from
tmh_compress_from_client() and adds a missing one to an error return
path in tmh_copy_from_client().

Finally note that the patch adds a previously missing return statement
to cli_get_page() (without which that function could de-reference a
NULL pointer, triggerable from guest mode).

This is part of XSA-15 / CVE-2012-3497.

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

--- a/xen/common/tmem.c
+++ b/xen/common/tmem.c
@@ -388,11 +388,13 @@ static NOINLINE int pcd_copy_to_client(t
     pcd =3D pgp->pcd;
     if ( pgp->size < PAGE_SIZE && pgp->size !=3D 0 &&
          pcd->size < PAGE_SIZE && pcd->size !=3D 0 )
-        ret =3D tmh_decompress_to_client(cmfn, pcd->cdata, pcd->size, =
NULL);
+        ret =3D tmh_decompress_to_client(cmfn, pcd->cdata, pcd->size,
+                                       tmh_cli_buf_null);
     else if ( tmh_tze_enabled() && pcd->size < PAGE_SIZE )
         ret =3D tmh_copy_tze_to_client(cmfn, pcd->tze, pcd->size);
     else
-        ret =3D tmh_copy_to_client(cmfn, pcd->pfp, 0, 0, PAGE_SIZE, =
NULL);
+        ret =3D tmh_copy_to_client(cmfn, pcd->pfp, 0, 0, PAGE_SIZE,
+                                 tmh_cli_buf_null);
     tmem_read_unlock(&pcd_tree_rwlocks[firstbyte]);
     return ret;
 }
@@ -1444,7 +1446,7 @@ static inline void tmem_ensure_avail_pag
 /************ TMEM CORE OPERATIONS ************************************/
=20
 static NOINLINE int do_tmem_put_compress(pgp_t *pgp, tmem_cli_mfn_t cmfn,
-                                         void *cva)
+                                         tmem_cli_va_t clibuf)
 {
     void *dst, *p;
     size_t size;
@@ -1463,7 +1465,7 @@ static NOINLINE int do_tmem_put_compress
     if ( pgp->pfp !=3D NULL )
         pgp_free_data(pgp, pgp->us.obj->pool);
     START_CYC_COUNTER(compress);
-    ret =3D tmh_compress_from_client(cmfn, &dst, &size, cva);
+    ret =3D tmh_compress_from_client(cmfn, &dst, &size, clibuf);
     if ( (ret =3D=3D -EFAULT) || (ret =3D=3D 0) )
         goto out;
     else if ( (size =3D=3D 0) || (size >=3D tmem_subpage_maxsize()) ) {
@@ -1490,7 +1492,8 @@ out:
 }
=20
 static NOINLINE int do_tmem_dup_put(pgp_t *pgp, tmem_cli_mfn_t cmfn,
-       pagesize_t tmem_offset, pagesize_t pfn_offset, pagesize_t len, =
void *cva)
+       pagesize_t tmem_offset, pagesize_t pfn_offset, pagesize_t len,
+       tmem_cli_va_t clibuf)
 {
     pool_t *pool;
     obj_t *obj;
@@ -1512,7 +1515,7 @@ static NOINLINE int do_tmem_dup_put(pgp_
     /* can we successfully manipulate pgp to change out the data? */
     if ( len !=3D 0 && client->compress && pgp->size !=3D 0 )
     {
-        ret =3D do_tmem_put_compress(pgp,cmfn,cva);
+        ret =3D do_tmem_put_compress(pgp, cmfn, clibuf);
         if ( ret =3D=3D 1 )
             goto done;
         else if ( ret =3D=3D 0 )
@@ -1530,7 +1533,8 @@ copy_uncompressed:
         goto failed_dup;
     pgp->size =3D 0;
     /* tmh_copy_from_client properly handles len=3D=3D0 and offsets !=3D =
0 */
-    ret =3D tmh_copy_from_client(pgp->pfp,cmfn,tmem_offset,pfn_offset,len,=
0);
+    ret =3D tmh_copy_from_client(pgp->pfp, cmfn, tmem_offset, pfn_offset, =
len,
+                               tmh_cli_buf_null);
     if ( ret =3D=3D -EFAULT )
         goto bad_copy;
     if ( tmh_dedup_enabled() && !is_persistent(pool) )
@@ -1582,7 +1586,7 @@ cleanup:
 static NOINLINE int do_tmem_put(pool_t *pool,
               OID *oidp, uint32_t index,
               tmem_cli_mfn_t cmfn, pagesize_t tmem_offset,
-              pagesize_t pfn_offset, pagesize_t len, void *cva)
+              pagesize_t pfn_offset, pagesize_t len, tmem_cli_va_t =
clibuf)
 {
     obj_t *obj =3D NULL, *objfound =3D NULL, *objnew =3D NULL;
     pgp_t *pgp =3D NULL, *pgpdel =3D NULL;
@@ -1596,7 +1600,8 @@ static NOINLINE int do_tmem_put(pool_t *
     {
         ASSERT_SPINLOCK(&objfound->obj_spinlock);
         if ((pgp =3D pgp_lookup_in_obj(objfound, index)) !=3D NULL)
-            return do_tmem_dup_put(pgp,cmfn,tmem_offset,pfn_offset,len,cva=
);
+            return do_tmem_dup_put(pgp, cmfn, tmem_offset, pfn_offset, =
len,
+                                   clibuf);
     }
=20
     /* no puts allowed into a frozen pool (except dup puts) */
@@ -1631,7 +1636,7 @@ static NOINLINE int do_tmem_put(pool_t *
     if ( len !=3D 0 && client->compress )
     {
         ASSERT(pgp->pfp =3D=3D NULL);
-        ret =3D do_tmem_put_compress(pgp,cmfn,cva);
+        ret =3D do_tmem_put_compress(pgp, cmfn, clibuf);
         if ( ret =3D=3D 1 )
             goto insert_page;
         if ( ret =3D=3D -ENOMEM )
@@ -1655,7 +1660,8 @@ copy_uncompressed:
         goto delete_and_free;
     }
     /* tmh_copy_from_client properly handles len=3D=3D0 (TMEM_NEW_PAGE) =
*/
-    ret =3D tmh_copy_from_client(pgp->pfp,cmfn,tmem_offset,pfn_offset,len,=
cva);
+    ret =3D tmh_copy_from_client(pgp->pfp, cmfn, tmem_offset, pfn_offset, =
len,
+                               clibuf);
     if ( ret =3D=3D -EFAULT )
         goto bad_copy;
     if ( tmh_dedup_enabled() && !is_persistent(pool) )
@@ -1725,12 +1731,13 @@ free:
=20
 static NOINLINE int do_tmem_get(pool_t *pool, OID *oidp, uint32_t index,
               tmem_cli_mfn_t cmfn, pagesize_t tmem_offset,
-              pagesize_t pfn_offset, pagesize_t len, void *cva)
+              pagesize_t pfn_offset, pagesize_t len, tmem_cli_va_t =
clibuf)
 {
     obj_t *obj;
     pgp_t *pgp;
     client_t *client =3D pool->client;
     DECL_LOCAL_CYC_COUNTER(decompress);
+    int rc =3D -EFAULT;
=20
     if ( !_atomic_read(pool->pgp_count) )
         return -EEMPTY;
@@ -1755,16 +1762,18 @@ static NOINLINE int do_tmem_get(pool_t *
     if ( tmh_dedup_enabled() && !is_persistent(pool) &&
               pgp->firstbyte !=3D NOT_SHAREABLE )
     {
-        if ( pcd_copy_to_client(cmfn, pgp) =3D=3D -EFAULT )
+        rc =3D pcd_copy_to_client(cmfn, pgp);
+        if ( rc <=3D 0 )
             goto bad_copy;
     } else if ( pgp->size !=3D 0 ) {
         START_CYC_COUNTER(decompress);
-        if ( tmh_decompress_to_client(cmfn, pgp->cdata,
-                                      pgp->size, cva) =3D=3D -EFAULT )
+        rc =3D tmh_decompress_to_client(cmfn, pgp->cdata,
+                                      pgp->size, clibuf);
+        if ( rc <=3D 0 )
             goto bad_copy;
         END_CYC_COUNTER(decompress);
     } else if ( tmh_copy_to_client(cmfn, pgp->pfp, tmem_offset,
-                                 pfn_offset, len, cva) =3D=3D -EFAULT)
+                                 pfn_offset, len, clibuf) =3D=3D -EFAULT)
         goto bad_copy;
     if ( is_ephemeral(pool) )
     {
@@ -1804,8 +1813,7 @@ static NOINLINE int do_tmem_get(pool_t *
 bad_copy:
     /* this should only happen if the client passed a bad mfn */
     failed_copies++;
-    return -EFAULT;
-
+    return rc;
 }
=20
 static NOINLINE int do_tmem_flush_page(pool_t *pool, OID *oidp, uint32_t =
index)
@@ -2345,7 +2353,6 @@ static NOINLINE int tmemc_save_subop(int
     pool_t *pool =3D (client =3D=3D NULL || pool_id >=3D MAX_POOLS_PER_DOM=
AIN)
                    ? NULL : client->pools[pool_id];
     uint32_t p;
-    uint64_t *uuid;
     pgp_t *pgp, *pgp2;
     int rc =3D -1;
=20
@@ -2409,9 +2416,7 @@ static NOINLINE int tmemc_save_subop(int
     case TMEMC_SAVE_GET_POOL_UUID:
          if ( pool =3D=3D NULL )
              break;
-        uuid =3D (uint64_t *)buf.p;
-        *uuid++ =3D pool->uuid[0];
-        *uuid =3D pool->uuid[1];
+        tmh_copy_to_client_buf(buf, pool->uuid, 2);
         rc =3D 0;
     case TMEMC_SAVE_END:
         if ( client =3D=3D NULL )
@@ -2436,7 +2441,7 @@ static NOINLINE int tmemc_save_get_next_
     pgp_t *pgp;
     OID oid;
     int ret =3D 0;
-    struct tmem_handle *h;
+    struct tmem_handle h;
     unsigned int pagesize =3D 1 << (pool->pageshift+12);
=20
     if ( pool =3D=3D NULL || is_ephemeral(pool) )
@@ -2467,11 +2472,13 @@ static NOINLINE int tmemc_save_get_next_
                          pgp_t,us.pool_pers_pages);
     pool->cur_pgp =3D pgp;
     oid =3D pgp->us.obj->oid;
-    h =3D (struct tmem_handle *)buf.p;
-    *(OID *)&h->oid[0] =3D oid;
-    h->index =3D pgp->index;
-    buf.p =3D (void *)(h+1);
-    ret =3D do_tmem_get(pool, &oid, h->index,0,0,0,pagesize,buf.p);
+    h.pool_id =3D pool_id;
+    BUILD_BUG_ON(sizeof(h.oid) !=3D sizeof(oid));
+    memcpy(h.oid, oid.oid, sizeof(h.oid));
+    h.index =3D pgp->index;
+    tmh_copy_to_client_buf(buf, &h, 1);
+    tmh_client_buf_add(buf, sizeof(h));
+    ret =3D do_tmem_get(pool, &oid, pgp->index, 0, 0, 0, pagesize, buf);
=20
 out:
     tmem_spin_unlock(&pers_lists_spinlock);
@@ -2483,7 +2490,7 @@ static NOINLINE int tmemc_save_get_next_
 {
     client_t *client =3D tmh_client_from_cli_id(cli_id);
     pgp_t *pgp;
-    struct tmem_handle *h;
+    struct tmem_handle h;
     int ret =3D 0;
=20
     if ( client =3D=3D NULL )
@@ -2509,10 +2516,11 @@ static NOINLINE int tmemc_save_get_next_
                          pgp_t,client_inv_pages);
         client->cur_pgp =3D pgp;
     }
-    h =3D (struct tmem_handle *)buf.p;
-    h->pool_id =3D pgp->pool_id;
-    *(OID *)&h->oid =3D pgp->inv_oid;
-    h->index =3D pgp->index;
+    h.pool_id =3D pgp->pool_id;
+    BUILD_BUG_ON(sizeof(h.oid) !=3D sizeof(pgp->inv_oid));
+    memcpy(h.oid, pgp->inv_oid.oid, sizeof(h.oid));
+    h.index =3D pgp->index;
+    tmh_copy_to_client_buf(buf, &h, 1);
     ret =3D 1;
 out:
     tmem_spin_unlock(&pers_lists_spinlock);
@@ -2528,7 +2536,7 @@ static int tmemc_restore_put_page(int cl
=20
     if ( pool =3D=3D NULL )
         return -1;
-    return do_tmem_put(pool,oidp,index,0,0,0,bufsize,buf.p);
+    return do_tmem_put(pool, oidp, index, 0, 0, 0, bufsize, buf);
 }
=20
 static int tmemc_restore_flush_page(int cli_id, uint32_t pool_id, OID =
*oidp,
@@ -2732,19 +2740,19 @@ EXPORT long do_tmem_op(tmem_cli_op_t uop
         break;
     case TMEM_NEW_PAGE:
         tmem_ensure_avail_pages();
-        rc =3D do_tmem_put(pool, oidp,
-                         op.u.gen.index, op.u.gen.cmfn, 0, 0, 0, NULL);
+        rc =3D do_tmem_put(pool, oidp, op.u.gen.index, op.u.gen.cmfn, 0, =
0, 0,
+                         tmh_cli_buf_null);
         break;
     case TMEM_PUT_PAGE:
         tmem_ensure_avail_pages();
-        rc =3D do_tmem_put(pool, oidp,
-                    op.u.gen.index, op.u.gen.cmfn, 0, 0, PAGE_SIZE, =
NULL);
+        rc =3D do_tmem_put(pool, oidp, op.u.gen.index, op.u.gen.cmfn, 0, =
0,
+                         PAGE_SIZE, tmh_cli_buf_null);
         if (rc =3D=3D 1) succ_put =3D 1;
         else non_succ_put =3D 1;
         break;
     case TMEM_GET_PAGE:
         rc =3D do_tmem_get(pool, oidp, op.u.gen.index, op.u.gen.cmfn,
-                         0, 0, PAGE_SIZE, 0);
+                         0, 0, PAGE_SIZE, tmh_cli_buf_null);
         if (rc =3D=3D 1) succ_get =3D 1;
         else non_succ_get =3D 1;
         break;
@@ -2763,13 +2771,13 @@ EXPORT long do_tmem_op(tmem_cli_op_t uop
     case TMEM_READ:
         rc =3D do_tmem_get(pool, oidp, op.u.gen.index, op.u.gen.cmfn,
                          op.u.gen.tmem_offset, op.u.gen.pfn_offset,
-                         op.u.gen.len,0);
+                         op.u.gen.len, tmh_cli_buf_null);
         break;
     case TMEM_WRITE:
         rc =3D do_tmem_put(pool, oidp,
                          op.u.gen.index, op.u.gen.cmfn,
                          op.u.gen.tmem_offset, op.u.gen.pfn_offset,
-                         op.u.gen.len, NULL);
+                         op.u.gen.len, tmh_cli_buf_null);
         break;
     case TMEM_XCHG:
         /* need to hold global lock to ensure xchg is atomic */
--- a/xen/common/tmem_xen.c
+++ b/xen/common/tmem_xen.c
@@ -51,6 +51,7 @@ DECL_CYC_COUNTER(pg_copy);
 #define LZO_DSTMEM_PAGES 2
 static DEFINE_PER_CPU_READ_MOSTLY(unsigned char *, workmem);
 static DEFINE_PER_CPU_READ_MOSTLY(unsigned char *, dstmem);
+static DEFINE_PER_CPU_READ_MOSTLY(void *, scratch_page);
=20
 #ifdef COMPARE_COPY_PAGE_SSE2
 #include <asm/flushtlb.h>  /* REMOVE ME AFTER TEST */
@@ -115,6 +116,7 @@ static inline void *cli_get_page(tmem_cl
     {
         if ( page )
             put_page(page);
+        return NULL;
     }
=20
     if ( cli_write && !get_page_type(page, PGT_writable_page) )
@@ -144,12 +146,12 @@ static inline void cli_put_page(tmem_cli
=20
 EXPORT int tmh_copy_from_client(pfp_t *pfp,
     tmem_cli_mfn_t cmfn, pagesize_t tmem_offset,
-    pagesize_t pfn_offset, pagesize_t len, void *cli_va)
+    pagesize_t pfn_offset, pagesize_t len, tmem_cli_va_t clibuf)
 {
     unsigned long tmem_mfn, cli_mfn =3D 0;
-    void *tmem_va;
+    char *tmem_va, *cli_va =3D NULL;
     pfp_t *cli_pfp =3D NULL;
-    bool_t tmemc =3D cli_va !=3D NULL; /* if true, cli_va is control-op =
buffer */
+    int rc =3D 1;
=20
     ASSERT(pfp !=3D NULL);
     tmem_mfn =3D page_to_mfn(pfp);
@@ -160,62 +162,76 @@ EXPORT int tmh_copy_from_client(pfp_t *p
         unmap_domain_page(tmem_va);
         return 1;
     }
-    if ( !tmemc )
+    if ( guest_handle_is_null(clibuf) )
     {
         cli_va =3D cli_get_page(cmfn, &cli_mfn, &cli_pfp, 0);
         if ( cli_va =3D=3D NULL )
+        {
+            unmap_domain_page(tmem_va);
             return -EFAULT;
+        }
     }
     mb();
-    if (len =3D=3D PAGE_SIZE && !tmem_offset && !pfn_offset)
+    if ( len =3D=3D PAGE_SIZE && !tmem_offset && !pfn_offset && cli_va )
         tmh_copy_page(tmem_va, cli_va);
     else if ( (tmem_offset+len <=3D PAGE_SIZE) &&
               (pfn_offset+len <=3D PAGE_SIZE) )
-        memcpy((char *)tmem_va+tmem_offset,(char *)cli_va+pfn_offset,len);=

-    if ( !tmemc )
+    {
+        if ( cli_va )
+            memcpy(tmem_va + tmem_offset, cli_va + pfn_offset, len);
+        else if ( copy_from_guest_offset(tmem_va + tmem_offset, clibuf,
+                                         pfn_offset, len) )
+            rc =3D -EFAULT;
+    }
+    if ( cli_va )
         cli_put_page(cmfn, cli_va, cli_pfp, cli_mfn, 0);
     unmap_domain_page(tmem_va);
-    return 1;
+    return rc;
 }
=20
 EXPORT int tmh_compress_from_client(tmem_cli_mfn_t cmfn,
-    void **out_va, size_t *out_len, void *cli_va)
+    void **out_va, size_t *out_len, tmem_cli_va_t clibuf)
 {
     int ret =3D 0;
     unsigned char *dmem =3D this_cpu(dstmem);
     unsigned char *wmem =3D this_cpu(workmem);
+    char *scratch =3D this_cpu(scratch_page);
     pfp_t *cli_pfp =3D NULL;
     unsigned long cli_mfn =3D 0;
-    bool_t tmemc =3D cli_va !=3D NULL; /* if true, cli_va is control-op =
buffer */
+    void *cli_va =3D NULL;
=20
     if ( dmem =3D=3D NULL || wmem =3D=3D NULL )
         return 0;  /* no buffer, so can't compress */
-    if ( !tmemc )
+    if ( guest_handle_is_null(clibuf) )
     {
         cli_va =3D cli_get_page(cmfn, &cli_mfn, &cli_pfp, 0);
         if ( cli_va =3D=3D NULL )
             return -EFAULT;
     }
+    else if ( !scratch )
+        return 0;
+    else if ( copy_from_guest(scratch, clibuf, PAGE_SIZE) )
+        return -EFAULT;
     mb();
-    ret =3D lzo1x_1_compress(cli_va, PAGE_SIZE, dmem, out_len, wmem);
+    ret =3D lzo1x_1_compress(cli_va ?: scratch, PAGE_SIZE, dmem, out_len, =
wmem);
     ASSERT(ret =3D=3D LZO_E_OK);
     *out_va =3D dmem;
-    if ( !tmemc )
+    if ( cli_va )
         cli_put_page(cmfn, cli_va, cli_pfp, cli_mfn, 0);
-    unmap_domain_page(cli_va);
     return 1;
 }
=20
 EXPORT int tmh_copy_to_client(tmem_cli_mfn_t cmfn, pfp_t *pfp,
-    pagesize_t tmem_offset, pagesize_t pfn_offset, pagesize_t len, void =
*cli_va)
+    pagesize_t tmem_offset, pagesize_t pfn_offset, pagesize_t len,
+    tmem_cli_va_t clibuf)
 {
     unsigned long tmem_mfn, cli_mfn =3D 0;
-    void *tmem_va;
+    char *tmem_va, *cli_va =3D NULL;
     pfp_t *cli_pfp =3D NULL;
-    bool_t tmemc =3D cli_va !=3D NULL; /* if true, cli_va is control-op =
buffer */
+    int rc =3D 1;
=20
     ASSERT(pfp !=3D NULL);
-    if ( !tmemc )
+    if ( guest_handle_is_null(clibuf) )
     {
         cli_va =3D cli_get_page(cmfn, &cli_mfn, &cli_pfp, 1);
         if ( cli_va =3D=3D NULL )
@@ -223,37 +239,48 @@ EXPORT int tmh_copy_to_client(tmem_cli_m
     }
     tmem_mfn =3D page_to_mfn(pfp);
     tmem_va =3D map_domain_page(tmem_mfn);
-    if (len =3D=3D PAGE_SIZE && !tmem_offset && !pfn_offset)
+    if ( len =3D=3D PAGE_SIZE && !tmem_offset && !pfn_offset && cli_va )
         tmh_copy_page(cli_va, tmem_va);
     else if ( (tmem_offset+len <=3D PAGE_SIZE) && (pfn_offset+len <=3D =
PAGE_SIZE) )
-        memcpy((char *)cli_va+pfn_offset,(char *)tmem_va+tmem_offset,len);=

+    {
+        if ( cli_va )
+            memcpy(cli_va + pfn_offset, tmem_va + tmem_offset, len);
+        else if ( copy_to_guest_offset(clibuf, pfn_offset,
+                                       tmem_va + tmem_offset, len) )
+            rc =3D -EFAULT;
+    }
     unmap_domain_page(tmem_va);
-    if ( !tmemc )
+    if ( cli_va )
         cli_put_page(cmfn, cli_va, cli_pfp, cli_mfn, 1);
     mb();
-    return 1;
+    return rc;
 }
=20
 EXPORT int tmh_decompress_to_client(tmem_cli_mfn_t cmfn, void *tmem_va,
-                                    size_t size, void *cli_va)
+                                    size_t size, tmem_cli_va_t clibuf)
 {
     unsigned long cli_mfn =3D 0;
     pfp_t *cli_pfp =3D NULL;
+    void *cli_va =3D NULL;
+    char *scratch =3D this_cpu(scratch_page);
     size_t out_len =3D PAGE_SIZE;
-    bool_t tmemc =3D cli_va !=3D NULL; /* if true, cli_va is control-op =
buffer */
     int ret;
=20
-    if ( !tmemc )
+    if ( guest_handle_is_null(clibuf) )
     {
         cli_va =3D cli_get_page(cmfn, &cli_mfn, &cli_pfp, 1);
         if ( cli_va =3D=3D NULL )
             return -EFAULT;
     }
-    ret =3D lzo1x_decompress_safe(tmem_va, size, cli_va, &out_len);
+    else if ( !scratch )
+        return 0;
+    ret =3D lzo1x_decompress_safe(tmem_va, size, cli_va ?: scratch, =
&out_len);
     ASSERT(ret =3D=3D LZO_E_OK);
     ASSERT(out_len =3D=3D PAGE_SIZE);
-    if ( !tmemc )
+    if ( cli_va )
         cli_put_page(cmfn, cli_va, cli_pfp, cli_mfn, 1);
+    else if ( copy_to_guest(clibuf, scratch, PAGE_SIZE) )
+        return -EFAULT;
     mb();
     return 1;
 }
@@ -423,6 +450,11 @@ static int cpu_callback(
             struct page_info *p =3D alloc_domheap_pages(0, workmem_order, =
0);
             per_cpu(workmem, cpu) =3D p ? page_to_virt(p) : NULL;
         }
+        if ( per_cpu(scratch_page, cpu) =3D=3D NULL )
+        {
+            struct page_info *p =3D alloc_domheap_page(NULL, 0);
+            per_cpu(scratch_page, cpu) =3D p ? page_to_virt(p) : NULL;
+        }
         break;
     }
     case CPU_DEAD:
@@ -439,6 +471,11 @@ static int cpu_callback(
             free_domheap_pages(p, workmem_order);
             per_cpu(workmem, cpu) =3D NULL;
         }
+        if ( per_cpu(scratch_page, cpu) !=3D NULL )
+        {
+            free_domheap_page(virt_to_page(per_cpu(scratch_page, cpu)));
+            per_cpu(scratch_page, cpu) =3D NULL;
+        }
         break;
     }
     default:
--- a/xen/include/xen/tmem_xen.h
+++ b/xen/include/xen/tmem_xen.h
@@ -482,27 +482,33 @@ static inline int tmh_get_tmemop_from_cl
     return copy_from_guest(op, uops, 1);
 }
=20
+#define tmh_cli_buf_null guest_handle_from_ptr(NULL, char)
+
 static inline void tmh_copy_to_client_buf_offset(tmem_cli_va_t clibuf, =
int off,
                                            char *tmembuf, int len)
 {
     copy_to_guest_offset(clibuf,off,tmembuf,len);
 }
=20
+#define tmh_copy_to_client_buf(clibuf, tmembuf, cnt) \
+    copy_to_guest(guest_handle_cast(clibuf, void), tmembuf, cnt)
+
+#define tmh_client_buf_add guest_handle_add_offset
+
 #define TMH_CLI_ID_NULL ((cli_id_t)((domid_t)-1L))
=20
 #define tmh_cli_id_str "domid"
 #define tmh_client_str "domain"
=20
-extern int tmh_decompress_to_client(tmem_cli_mfn_t,void*,size_t,void*);
+int tmh_decompress_to_client(tmem_cli_mfn_t, void *, size_t, tmem_cli_va_t=
);
=20
-extern int tmh_compress_from_client(tmem_cli_mfn_t,void**,size_t =
*,void*);
+int tmh_compress_from_client(tmem_cli_mfn_t, void **, size_t *, tmem_cli_v=
a_t);
=20
-extern int tmh_copy_from_client(pfp_t *pfp,
-    tmem_cli_mfn_t cmfn, pagesize_t tmem_offset,
-    pagesize_t pfn_offset, pagesize_t len, void *cva);
+int tmh_copy_from_client(pfp_t *, tmem_cli_mfn_t, pagesize_t tmem_offset,
+    pagesize_t pfn_offset, pagesize_t len, tmem_cli_va_t);
=20
-extern int tmh_copy_to_client(tmem_cli_mfn_t cmfn, pfp_t *pfp,
-    pagesize_t tmem_offset, pagesize_t pfn_offset, pagesize_t len, void =
*cva);
+int tmh_copy_to_client(tmem_cli_mfn_t, pfp_t *, pagesize_t tmem_offset,
+    pagesize_t pfn_offset, pagesize_t len, tmem_cli_va_t);
=20
 extern int tmh_copy_tze_to_client(tmem_cli_mfn_t cmfn, void *tmem_va, =
pagesize_t len);
=20



--=__Part56674C6E.0__=
Content-Type: text/plain; name="tmem-xsa-15-5.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="tmem-xsa-15-5.patch"

tmem: don't access guest memory without using the accessors intended for =
this=0A=0AThis is not permitted, not even for buffers coming from Dom0 =
(and it=0Awould also break the moment Dom0 runs in HVM mode). An implicatio=
n from=0Athe changes here is that tmh_copy_page() can't be used anymore =
for=0Acontrol operations calling tmh_copy_{from,to}_client() (as those =
pass=0Athe buffer by virtual address rather than MFN).=0A=0ANote that =
tmemc_save_get_next_page() previously didn't set the returned=0Ahandle's =
pool_id field, while the new code does. It need to be=0Aconfirmed that =
this is not a problem (otherwise the copy-out operation=0Awill require =
further tmh_...() abstractions to be added).=0A=0AFurther note that the =
patch removes (rather than adjusts) an invalid=0Acall to unmap_domain_page(=
) (no matching map_domain_page()) from=0Atmh_compress_from_client() and =
adds a missing one to an error return=0Apath in tmh_copy_from_client().=0A=
=0AFinally note that the patch adds a previously missing return =
statement=0Ato cli_get_page() (without which that function could de-referen=
ce a=0ANULL pointer, triggerable from guest mode).=0A=0AThis is part of =
XSA-15 / CVE-2012-3497.=0A=0ASigned-off-by: Jan Beulich <jbeulich@suse.com>=
=0A=0A--- a/xen/common/tmem.c=0A+++ b/xen/common/tmem.c=0A@@ -388,11 =
+388,13 @@ static NOINLINE int pcd_copy_to_client(t=0A     pcd =3D =
pgp->pcd;=0A     if ( pgp->size < PAGE_SIZE && pgp->size !=3D 0 &&=0A      =
    pcd->size < PAGE_SIZE && pcd->size !=3D 0 )=0A-        ret =3D =
tmh_decompress_to_client(cmfn, pcd->cdata, pcd->size, NULL);=0A+        =
ret =3D tmh_decompress_to_client(cmfn, pcd->cdata, pcd->size,=0A+          =
                             tmh_cli_buf_null);=0A     else if ( tmh_tze_en=
abled() && pcd->size < PAGE_SIZE )=0A         ret =3D tmh_copy_tze_to_clien=
t(cmfn, pcd->tze, pcd->size);=0A     else=0A-        ret =3D tmh_copy_to_cl=
ient(cmfn, pcd->pfp, 0, 0, PAGE_SIZE, NULL);=0A+        ret =3D tmh_copy_to=
_client(cmfn, pcd->pfp, 0, 0, PAGE_SIZE,=0A+                               =
  tmh_cli_buf_null);=0A     tmem_read_unlock(&pcd_tree_rwlocks[firstbyte]);=
=0A     return ret;=0A }=0A@@ -1444,7 +1446,7 @@ static inline void =
tmem_ensure_avail_pag=0A /************ TMEM CORE OPERATIONS ***************=
*********************/=0A =0A static NOINLINE int do_tmem_put_compress(pgp_=
t *pgp, tmem_cli_mfn_t cmfn,=0A-                                         =
void *cva)=0A+                                         tmem_cli_va_t =
clibuf)=0A {=0A     void *dst, *p;=0A     size_t size;=0A@@ -1463,7 =
+1465,7 @@ static NOINLINE int do_tmem_put_compress=0A     if ( pgp->pfp =
!=3D NULL )=0A         pgp_free_data(pgp, pgp->us.obj->pool);=0A     =
START_CYC_COUNTER(compress);=0A-    ret =3D tmh_compress_from_client(cmfn, =
&dst, &size, cva);=0A+    ret =3D tmh_compress_from_client(cmfn, &dst, =
&size, clibuf);=0A     if ( (ret =3D=3D -EFAULT) || (ret =3D=3D 0) )=0A    =
     goto out;=0A     else if ( (size =3D=3D 0) || (size >=3D tmem_subpage_=
maxsize()) ) {=0A@@ -1490,7 +1492,8 @@ out:=0A }=0A =0A static NOINLINE =
int do_tmem_dup_put(pgp_t *pgp, tmem_cli_mfn_t cmfn,=0A-       pagesize_t =
tmem_offset, pagesize_t pfn_offset, pagesize_t len, void *cva)=0A+       =
pagesize_t tmem_offset, pagesize_t pfn_offset, pagesize_t len,=0A+       =
tmem_cli_va_t clibuf)=0A {=0A     pool_t *pool;=0A     obj_t *obj;=0A@@ =
-1512,7 +1515,7 @@ static NOINLINE int do_tmem_dup_put(pgp_=0A     /* can =
we successfully manipulate pgp to change out the data? */=0A     if ( len =
!=3D 0 && client->compress && pgp->size !=3D 0 )=0A     {=0A-        ret =
=3D do_tmem_put_compress(pgp,cmfn,cva);=0A+        ret =3D do_tmem_put_comp=
ress(pgp, cmfn, clibuf);=0A         if ( ret =3D=3D 1 )=0A             =
goto done;=0A         else if ( ret =3D=3D 0 )=0A@@ -1530,7 +1533,8 @@ =
copy_uncompressed:=0A         goto failed_dup;=0A     pgp->size =3D 0;=0A  =
   /* tmh_copy_from_client properly handles len=3D=3D0 and offsets !=3D 0 =
*/=0A-    ret =3D tmh_copy_from_client(pgp->pfp,cmfn,tmem_offset,pfn_offset=
,len,0);=0A+    ret =3D tmh_copy_from_client(pgp->pfp, cmfn, tmem_offset, =
pfn_offset, len,=0A+                               tmh_cli_buf_null);=0A   =
  if ( ret =3D=3D -EFAULT )=0A         goto bad_copy;=0A     if ( =
tmh_dedup_enabled() && !is_persistent(pool) )=0A@@ -1582,7 +1586,7 @@ =
cleanup:=0A static NOINLINE int do_tmem_put(pool_t *pool,=0A               =
OID *oidp, uint32_t index,=0A               tmem_cli_mfn_t cmfn, pagesize_t=
 tmem_offset,=0A-              pagesize_t pfn_offset, pagesize_t len, void =
*cva)=0A+              pagesize_t pfn_offset, pagesize_t len, tmem_cli_va_t=
 clibuf)=0A {=0A     obj_t *obj =3D NULL, *objfound =3D NULL, *objnew =3D =
NULL;=0A     pgp_t *pgp =3D NULL, *pgpdel =3D NULL;=0A@@ -1596,7 +1600,8 =
@@ static NOINLINE int do_tmem_put(pool_t *=0A     {=0A         ASSERT_SPIN=
LOCK(&objfound->obj_spinlock);=0A         if ((pgp =3D pgp_lookup_in_obj(ob=
jfound, index)) !=3D NULL)=0A-            return do_tmem_dup_put(pgp,cmfn,t=
mem_offset,pfn_offset,len,cva);=0A+            return do_tmem_dup_put(pgp, =
cmfn, tmem_offset, pfn_offset, len,=0A+                                   =
clibuf);=0A     }=0A =0A     /* no puts allowed into a frozen pool (except =
dup puts) */=0A@@ -1631,7 +1636,7 @@ static NOINLINE int do_tmem_put(pool_t=
 *=0A     if ( len !=3D 0 && client->compress )=0A     {=0A         =
ASSERT(pgp->pfp =3D=3D NULL);=0A-        ret =3D do_tmem_put_compress(pgp,c=
mfn,cva);=0A+        ret =3D do_tmem_put_compress(pgp, cmfn, clibuf);=0A   =
      if ( ret =3D=3D 1 )=0A             goto insert_page;=0A         if ( =
ret =3D=3D -ENOMEM )=0A@@ -1655,7 +1660,8 @@ copy_uncompressed:=0A         =
goto delete_and_free;=0A     }=0A     /* tmh_copy_from_client properly =
handles len=3D=3D0 (TMEM_NEW_PAGE) */=0A-    ret =3D tmh_copy_from_client(p=
gp->pfp,cmfn,tmem_offset,pfn_offset,len,cva);=0A+    ret =3D tmh_copy_from_=
client(pgp->pfp, cmfn, tmem_offset, pfn_offset, len,=0A+                   =
            clibuf);=0A     if ( ret =3D=3D -EFAULT )=0A         goto =
bad_copy;=0A     if ( tmh_dedup_enabled() && !is_persistent(pool) )=0A@@ =
-1725,12 +1731,13 @@ free:=0A =0A static NOINLINE int do_tmem_get(pool_t =
*pool, OID *oidp, uint32_t index,=0A               tmem_cli_mfn_t cmfn, =
pagesize_t tmem_offset,=0A-              pagesize_t pfn_offset, pagesize_t =
len, void *cva)=0A+              pagesize_t pfn_offset, pagesize_t len, =
tmem_cli_va_t clibuf)=0A {=0A     obj_t *obj;=0A     pgp_t *pgp;=0A     =
client_t *client =3D pool->client;=0A     DECL_LOCAL_CYC_COUNTER(decompress=
);=0A+    int rc =3D -EFAULT;=0A =0A     if ( !_atomic_read(pool->pgp_count=
) )=0A         return -EEMPTY;=0A@@ -1755,16 +1762,18 @@ static NOINLINE =
int do_tmem_get(pool_t *=0A     if ( tmh_dedup_enabled() && !is_persistent(=
pool) &&=0A               pgp->firstbyte !=3D NOT_SHAREABLE )=0A     {=0A- =
       if ( pcd_copy_to_client(cmfn, pgp) =3D=3D -EFAULT )=0A+        rc =
=3D pcd_copy_to_client(cmfn, pgp);=0A+        if ( rc <=3D 0 )=0A          =
   goto bad_copy;=0A     } else if ( pgp->size !=3D 0 ) {=0A         =
START_CYC_COUNTER(decompress);=0A-        if ( tmh_decompress_to_client(cmf=
n, pgp->cdata,=0A-                                      pgp->size, cva) =
=3D=3D -EFAULT )=0A+        rc =3D tmh_decompress_to_client(cmfn, =
pgp->cdata,=0A+                                      pgp->size, clibuf);=0A=
+        if ( rc <=3D 0 )=0A             goto bad_copy;=0A         =
END_CYC_COUNTER(decompress);=0A     } else if ( tmh_copy_to_client(cmfn, =
pgp->pfp, tmem_offset,=0A-                                 pfn_offset, =
len, cva) =3D=3D -EFAULT)=0A+                                 pfn_offset, =
len, clibuf) =3D=3D -EFAULT)=0A         goto bad_copy;=0A     if ( =
is_ephemeral(pool) )=0A     {=0A@@ -1804,8 +1813,7 @@ static NOINLINE int =
do_tmem_get(pool_t *=0A bad_copy:=0A     /* this should only happen if the =
client passed a bad mfn */=0A     failed_copies++;=0A-    return =
-EFAULT;=0A-=0A+    return rc;=0A }=0A =0A static NOINLINE int do_tmem_flus=
h_page(pool_t *pool, OID *oidp, uint32_t index)=0A@@ -2345,7 +2353,6 @@ =
static NOINLINE int tmemc_save_subop(int=0A     pool_t *pool =3D (client =
=3D=3D NULL || pool_id >=3D MAX_POOLS_PER_DOMAIN)=0A                    ? =
NULL : client->pools[pool_id];=0A     uint32_t p;=0A-    uint64_t =
*uuid;=0A     pgp_t *pgp, *pgp2;=0A     int rc =3D -1;=0A =0A@@ -2409,9 =
+2416,7 @@ static NOINLINE int tmemc_save_subop(int=0A     case TMEMC_SAVE_=
GET_POOL_UUID:=0A          if ( pool =3D=3D NULL )=0A              =
break;=0A-        uuid =3D (uint64_t *)buf.p;=0A-        *uuid++ =3D =
pool->uuid[0];=0A-        *uuid =3D pool->uuid[1];=0A+        tmh_copy_to_c=
lient_buf(buf, pool->uuid, 2);=0A         rc =3D 0;=0A     case TMEMC_SAVE_=
END:=0A         if ( client =3D=3D NULL )=0A@@ -2436,7 +2441,7 @@ static =
NOINLINE int tmemc_save_get_next_=0A     pgp_t *pgp;=0A     OID oid;=0A    =
 int ret =3D 0;=0A-    struct tmem_handle *h;=0A+    struct tmem_handle =
h;=0A     unsigned int pagesize =3D 1 << (pool->pageshift+12);=0A =0A     =
if ( pool =3D=3D NULL || is_ephemeral(pool) )=0A@@ -2467,11 +2472,13 @@ =
static NOINLINE int tmemc_save_get_next_=0A                          =
pgp_t,us.pool_pers_pages);=0A     pool->cur_pgp =3D pgp;=0A     oid =3D =
pgp->us.obj->oid;=0A-    h =3D (struct tmem_handle *)buf.p;=0A-    *(OID =
*)&h->oid[0] =3D oid;=0A-    h->index =3D pgp->index;=0A-    buf.p =3D =
(void *)(h+1);=0A-    ret =3D do_tmem_get(pool, &oid, h->index,0,0,0,pagesi=
ze,buf.p);=0A+    h.pool_id =3D pool_id;=0A+    BUILD_BUG_ON(sizeof(h.oid) =
!=3D sizeof(oid));=0A+    memcpy(h.oid, oid.oid, sizeof(h.oid));=0A+    =
h.index =3D pgp->index;=0A+    tmh_copy_to_client_buf(buf, &h, 1);=0A+    =
tmh_client_buf_add(buf, sizeof(h));=0A+    ret =3D do_tmem_get(pool, &oid, =
pgp->index, 0, 0, 0, pagesize, buf);=0A =0A out:=0A     tmem_spin_unlock(&p=
ers_lists_spinlock);=0A@@ -2483,7 +2490,7 @@ static NOINLINE int tmemc_save=
_get_next_=0A {=0A     client_t *client =3D tmh_client_from_cli_id(cli_id);=
=0A     pgp_t *pgp;=0A-    struct tmem_handle *h;=0A+    struct tmem_handle=
 h;=0A     int ret =3D 0;=0A =0A     if ( client =3D=3D NULL )=0A@@ =
-2509,10 +2516,11 @@ static NOINLINE int tmemc_save_get_next_=0A           =
               pgp_t,client_inv_pages);=0A         client->cur_pgp =3D =
pgp;=0A     }=0A-    h =3D (struct tmem_handle *)buf.p;=0A-    h->pool_id =
=3D pgp->pool_id;=0A-    *(OID *)&h->oid =3D pgp->inv_oid;=0A-    h->index =
=3D pgp->index;=0A+    h.pool_id =3D pgp->pool_id;=0A+    BUILD_BUG_ON(size=
of(h.oid) !=3D sizeof(pgp->inv_oid));=0A+    memcpy(h.oid, pgp->inv_oid.oid=
, sizeof(h.oid));=0A+    h.index =3D pgp->index;=0A+    tmh_copy_to_client_=
buf(buf, &h, 1);=0A     ret =3D 1;=0A out:=0A     tmem_spin_unlock(&pers_li=
sts_spinlock);=0A@@ -2528,7 +2536,7 @@ static int tmemc_restore_put_page(in=
t cl=0A =0A     if ( pool =3D=3D NULL )=0A         return -1;=0A-    =
return do_tmem_put(pool,oidp,index,0,0,0,bufsize,buf.p);=0A+    return =
do_tmem_put(pool, oidp, index, 0, 0, 0, bufsize, buf);=0A }=0A =0A static =
int tmemc_restore_flush_page(int cli_id, uint32_t pool_id, OID *oidp,=0A@@ =
-2732,19 +2740,19 @@ EXPORT long do_tmem_op(tmem_cli_op_t uop=0A         =
break;=0A     case TMEM_NEW_PAGE:=0A         tmem_ensure_avail_pages();=0A-=
        rc =3D do_tmem_put(pool, oidp,=0A-                         =
op.u.gen.index, op.u.gen.cmfn, 0, 0, 0, NULL);=0A+        rc =3D do_tmem_pu=
t(pool, oidp, op.u.gen.index, op.u.gen.cmfn, 0, 0, 0,=0A+                  =
       tmh_cli_buf_null);=0A         break;=0A     case TMEM_PUT_PAGE:=0A  =
       tmem_ensure_avail_pages();=0A-        rc =3D do_tmem_put(pool, =
oidp,=0A-                    op.u.gen.index, op.u.gen.cmfn, 0, 0, =
PAGE_SIZE, NULL);=0A+        rc =3D do_tmem_put(pool, oidp, op.u.gen.index,=
 op.u.gen.cmfn, 0, 0,=0A+                         PAGE_SIZE, tmh_cli_buf_nu=
ll);=0A         if (rc =3D=3D 1) succ_put =3D 1;=0A         else non_succ_p=
ut =3D 1;=0A         break;=0A     case TMEM_GET_PAGE:=0A         rc =3D =
do_tmem_get(pool, oidp, op.u.gen.index, op.u.gen.cmfn,=0A-                 =
        0, 0, PAGE_SIZE, 0);=0A+                         0, 0, PAGE_SIZE, =
tmh_cli_buf_null);=0A         if (rc =3D=3D 1) succ_get =3D 1;=0A         =
else non_succ_get =3D 1;=0A         break;=0A@@ -2763,13 +2771,13 @@ =
EXPORT long do_tmem_op(tmem_cli_op_t uop=0A     case TMEM_READ:=0A         =
rc =3D do_tmem_get(pool, oidp, op.u.gen.index, op.u.gen.cmfn,=0A           =
               op.u.gen.tmem_offset, op.u.gen.pfn_offset,=0A-              =
           op.u.gen.len,0);=0A+                         op.u.gen.len, =
tmh_cli_buf_null);=0A         break;=0A     case TMEM_WRITE:=0A         rc =
=3D do_tmem_put(pool, oidp,=0A                          op.u.gen.index, =
op.u.gen.cmfn,=0A                          op.u.gen.tmem_offset, op.u.gen.p=
fn_offset,=0A-                         op.u.gen.len, NULL);=0A+            =
             op.u.gen.len, tmh_cli_buf_null);=0A         break;=0A     =
case TMEM_XCHG:=0A         /* need to hold global lock to ensure xchg is =
atomic */=0A--- a/xen/common/tmem_xen.c=0A+++ b/xen/common/tmem_xen.c=0A@@ =
-51,6 +51,7 @@ DECL_CYC_COUNTER(pg_copy);=0A #define LZO_DSTMEM_PAGES 2=0A =
static DEFINE_PER_CPU_READ_MOSTLY(unsigned char *, workmem);=0A static =
DEFINE_PER_CPU_READ_MOSTLY(unsigned char *, dstmem);=0A+static DEFINE_PER_C=
PU_READ_MOSTLY(void *, scratch_page);=0A =0A #ifdef COMPARE_COPY_PAGE_SSE2=
=0A #include <asm/flushtlb.h>  /* REMOVE ME AFTER TEST */=0A@@ -115,6 =
+116,7 @@ static inline void *cli_get_page(tmem_cl=0A     {=0A         if =
( page )=0A             put_page(page);=0A+        return NULL;=0A     =
}=0A =0A     if ( cli_write && !get_page_type(page, PGT_writable_page) =
)=0A@@ -144,12 +146,12 @@ static inline void cli_put_page(tmem_cli=0A =0A =
EXPORT int tmh_copy_from_client(pfp_t *pfp,=0A     tmem_cli_mfn_t cmfn, =
pagesize_t tmem_offset,=0A-    pagesize_t pfn_offset, pagesize_t len, void =
*cli_va)=0A+    pagesize_t pfn_offset, pagesize_t len, tmem_cli_va_t =
clibuf)=0A {=0A     unsigned long tmem_mfn, cli_mfn =3D 0;=0A-    void =
*tmem_va;=0A+    char *tmem_va, *cli_va =3D NULL;=0A     pfp_t *cli_pfp =
=3D NULL;=0A-    bool_t tmemc =3D cli_va !=3D NULL; /* if true, cli_va is =
control-op buffer */=0A+    int rc =3D 1;=0A =0A     ASSERT(pfp !=3D =
NULL);=0A     tmem_mfn =3D page_to_mfn(pfp);=0A@@ -160,62 +162,76 @@ =
EXPORT int tmh_copy_from_client(pfp_t *p=0A         unmap_domain_page(tmem_=
va);=0A         return 1;=0A     }=0A-    if ( !tmemc )=0A+    if ( =
guest_handle_is_null(clibuf) )=0A     {=0A         cli_va =3D cli_get_page(=
cmfn, &cli_mfn, &cli_pfp, 0);=0A         if ( cli_va =3D=3D NULL )=0A+     =
   {=0A+            unmap_domain_page(tmem_va);=0A             return =
-EFAULT;=0A+        }=0A     }=0A     mb();=0A-    if (len =3D=3D =
PAGE_SIZE && !tmem_offset && !pfn_offset)=0A+    if ( len =3D=3D PAGE_SIZE =
&& !tmem_offset && !pfn_offset && cli_va )=0A         tmh_copy_page(tmem_va=
, cli_va);=0A     else if ( (tmem_offset+len <=3D PAGE_SIZE) &&=0A         =
      (pfn_offset+len <=3D PAGE_SIZE) )=0A-        memcpy((char *)tmem_va+t=
mem_offset,(char *)cli_va+pfn_offset,len);=0A-    if ( !tmemc )=0A+    =
{=0A+        if ( cli_va )=0A+            memcpy(tmem_va + tmem_offset, =
cli_va + pfn_offset, len);=0A+        else if ( copy_from_guest_offset(tmem=
_va + tmem_offset, clibuf,=0A+                                         =
pfn_offset, len) )=0A+            rc =3D -EFAULT;=0A+    }=0A+    if ( =
cli_va )=0A         cli_put_page(cmfn, cli_va, cli_pfp, cli_mfn, 0);=0A    =
 unmap_domain_page(tmem_va);=0A-    return 1;=0A+    return rc;=0A }=0A =
=0A EXPORT int tmh_compress_from_client(tmem_cli_mfn_t cmfn,=0A-    void =
**out_va, size_t *out_len, void *cli_va)=0A+    void **out_va, size_t =
*out_len, tmem_cli_va_t clibuf)=0A {=0A     int ret =3D 0;=0A     unsigned =
char *dmem =3D this_cpu(dstmem);=0A     unsigned char *wmem =3D this_cpu(wo=
rkmem);=0A+    char *scratch =3D this_cpu(scratch_page);=0A     pfp_t =
*cli_pfp =3D NULL;=0A     unsigned long cli_mfn =3D 0;=0A-    bool_t tmemc =
=3D cli_va !=3D NULL; /* if true, cli_va is control-op buffer */=0A+    =
void *cli_va =3D NULL;=0A =0A     if ( dmem =3D=3D NULL || wmem =3D=3D =
NULL )=0A         return 0;  /* no buffer, so can't compress */=0A-    if =
( !tmemc )=0A+    if ( guest_handle_is_null(clibuf) )=0A     {=0A         =
cli_va =3D cli_get_page(cmfn, &cli_mfn, &cli_pfp, 0);=0A         if ( =
cli_va =3D=3D NULL )=0A             return -EFAULT;=0A     }=0A+    else =
if ( !scratch )=0A+        return 0;=0A+    else if ( copy_from_guest(scrat=
ch, clibuf, PAGE_SIZE) )=0A+        return -EFAULT;=0A     mb();=0A-    =
ret =3D lzo1x_1_compress(cli_va, PAGE_SIZE, dmem, out_len, wmem);=0A+    =
ret =3D lzo1x_1_compress(cli_va ?: scratch, PAGE_SIZE, dmem, out_len, =
wmem);=0A     ASSERT(ret =3D=3D LZO_E_OK);=0A     *out_va =3D dmem;=0A-    =
if ( !tmemc )=0A+    if ( cli_va )=0A         cli_put_page(cmfn, cli_va, =
cli_pfp, cli_mfn, 0);=0A-    unmap_domain_page(cli_va);=0A     return =
1;=0A }=0A =0A EXPORT int tmh_copy_to_client(tmem_cli_mfn_t cmfn, pfp_t =
*pfp,=0A-    pagesize_t tmem_offset, pagesize_t pfn_offset, pagesize_t =
len, void *cli_va)=0A+    pagesize_t tmem_offset, pagesize_t pfn_offset, =
pagesize_t len,=0A+    tmem_cli_va_t clibuf)=0A {=0A     unsigned long =
tmem_mfn, cli_mfn =3D 0;=0A-    void *tmem_va;=0A+    char *tmem_va, =
*cli_va =3D NULL;=0A     pfp_t *cli_pfp =3D NULL;=0A-    bool_t tmemc =3D =
cli_va !=3D NULL; /* if true, cli_va is control-op buffer */=0A+    int rc =
=3D 1;=0A =0A     ASSERT(pfp !=3D NULL);=0A-    if ( !tmemc )=0A+    if ( =
guest_handle_is_null(clibuf) )=0A     {=0A         cli_va =3D cli_get_page(=
cmfn, &cli_mfn, &cli_pfp, 1);=0A         if ( cli_va =3D=3D NULL )=0A@@ =
-223,37 +239,48 @@ EXPORT int tmh_copy_to_client(tmem_cli_m=0A     }=0A    =
 tmem_mfn =3D page_to_mfn(pfp);=0A     tmem_va =3D map_domain_page(tmem_mfn=
);=0A-    if (len =3D=3D PAGE_SIZE && !tmem_offset && !pfn_offset)=0A+    =
if ( len =3D=3D PAGE_SIZE && !tmem_offset && !pfn_offset && cli_va )=0A    =
     tmh_copy_page(cli_va, tmem_va);=0A     else if ( (tmem_offset+len =
<=3D PAGE_SIZE) && (pfn_offset+len <=3D PAGE_SIZE) )=0A-        memcpy((cha=
r *)cli_va+pfn_offset,(char *)tmem_va+tmem_offset,len);=0A+    {=0A+       =
 if ( cli_va )=0A+            memcpy(cli_va + pfn_offset, tmem_va + =
tmem_offset, len);=0A+        else if ( copy_to_guest_offset(clibuf, =
pfn_offset,=0A+                                       tmem_va + tmem_offset=
, len) )=0A+            rc =3D -EFAULT;=0A+    }=0A     unmap_domain_page(t=
mem_va);=0A-    if ( !tmemc )=0A+    if ( cli_va )=0A         cli_put_page(=
cmfn, cli_va, cli_pfp, cli_mfn, 1);=0A     mb();=0A-    return 1;=0A+    =
return rc;=0A }=0A =0A EXPORT int tmh_decompress_to_client(tmem_cli_mfn_t =
cmfn, void *tmem_va,=0A-                                    size_t size, =
void *cli_va)=0A+                                    size_t size, =
tmem_cli_va_t clibuf)=0A {=0A     unsigned long cli_mfn =3D 0;=0A     =
pfp_t *cli_pfp =3D NULL;=0A+    void *cli_va =3D NULL;=0A+    char =
*scratch =3D this_cpu(scratch_page);=0A     size_t out_len =3D PAGE_SIZE;=
=0A-    bool_t tmemc =3D cli_va !=3D NULL; /* if true, cli_va is control-op=
 buffer */=0A     int ret;=0A =0A-    if ( !tmemc )=0A+    if ( guest_handl=
e_is_null(clibuf) )=0A     {=0A         cli_va =3D cli_get_page(cmfn, =
&cli_mfn, &cli_pfp, 1);=0A         if ( cli_va =3D=3D NULL )=0A            =
 return -EFAULT;=0A     }=0A-    ret =3D lzo1x_decompress_safe(tmem_va, =
size, cli_va, &out_len);=0A+    else if ( !scratch )=0A+        return =
0;=0A+    ret =3D lzo1x_decompress_safe(tmem_va, size, cli_va ?: scratch, =
&out_len);=0A     ASSERT(ret =3D=3D LZO_E_OK);=0A     ASSERT(out_len =
=3D=3D PAGE_SIZE);=0A-    if ( !tmemc )=0A+    if ( cli_va )=0A         =
cli_put_page(cmfn, cli_va, cli_pfp, cli_mfn, 1);=0A+    else if ( =
copy_to_guest(clibuf, scratch, PAGE_SIZE) )=0A+        return -EFAULT;=0A  =
   mb();=0A     return 1;=0A }=0A@@ -423,6 +450,11 @@ static int cpu_callba=
ck(=0A             struct page_info *p =3D alloc_domheap_pages(0, =
workmem_order, 0);=0A             per_cpu(workmem, cpu) =3D p ? page_to_vir=
t(p) : NULL;=0A         }=0A+        if ( per_cpu(scratch_page, cpu) =
=3D=3D NULL )=0A+        {=0A+            struct page_info *p =3D =
alloc_domheap_page(NULL, 0);=0A+            per_cpu(scratch_page, cpu) =3D =
p ? page_to_virt(p) : NULL;=0A+        }=0A         break;=0A     }=0A     =
case CPU_DEAD:=0A@@ -439,6 +471,11 @@ static int cpu_callback(=0A          =
   free_domheap_pages(p, workmem_order);=0A             per_cpu(workmem, =
cpu) =3D NULL;=0A         }=0A+        if ( per_cpu(scratch_page, cpu) =
!=3D NULL )=0A+        {=0A+            free_domheap_page(virt_to_page(per_=
cpu(scratch_page, cpu)));=0A+            per_cpu(scratch_page, cpu) =3D =
NULL;=0A+        }=0A         break;=0A     }=0A     default:=0A--- =
a/xen/include/xen/tmem_xen.h=0A+++ b/xen/include/xen/tmem_xen.h=0A@@ =
-482,27 +482,33 @@ static inline int tmh_get_tmemop_from_cl=0A     return =
copy_from_guest(op, uops, 1);=0A }=0A =0A+#define tmh_cli_buf_null =
guest_handle_from_ptr(NULL, char)=0A+=0A static inline void tmh_copy_to_cli=
ent_buf_offset(tmem_cli_va_t clibuf, int off,=0A                           =
                 char *tmembuf, int len)=0A {=0A     copy_to_guest_offset(c=
libuf,off,tmembuf,len);=0A }=0A =0A+#define tmh_copy_to_client_buf(clibuf, =
tmembuf, cnt) \=0A+    copy_to_guest(guest_handle_cast(clibuf, void), =
tmembuf, cnt)=0A+=0A+#define tmh_client_buf_add guest_handle_add_offset=0A+=
=0A #define TMH_CLI_ID_NULL ((cli_id_t)((domid_t)-1L))=0A =0A #define =
tmh_cli_id_str "domid"=0A #define tmh_client_str "domain"=0A =0A-extern =
int tmh_decompress_to_client(tmem_cli_mfn_t,void*,size_t,void*);=0A+int =
tmh_decompress_to_client(tmem_cli_mfn_t, void *, size_t, tmem_cli_va_t);=0A=
 =0A-extern int tmh_compress_from_client(tmem_cli_mfn_t,void**,size_t =
*,void*);=0A+int tmh_compress_from_client(tmem_cli_mfn_t, void **, size_t =
*, tmem_cli_va_t);=0A =0A-extern int tmh_copy_from_client(pfp_t *pfp,=0A-  =
  tmem_cli_mfn_t cmfn, pagesize_t tmem_offset,=0A-    pagesize_t pfn_offset=
, pagesize_t len, void *cva);=0A+int tmh_copy_from_client(pfp_t *, =
tmem_cli_mfn_t, pagesize_t tmem_offset,=0A+    pagesize_t pfn_offset, =
pagesize_t len, tmem_cli_va_t);=0A =0A-extern int tmh_copy_to_client(tmem_c=
li_mfn_t cmfn, pfp_t *pfp,=0A-    pagesize_t tmem_offset, pagesize_t =
pfn_offset, pagesize_t len, void *cva);=0A+int tmh_copy_to_client(tmem_cli_=
mfn_t, pfp_t *, pagesize_t tmem_offset,=0A+    pagesize_t pfn_offset, =
pagesize_t len, tmem_cli_va_t);=0A =0A extern int tmh_copy_tze_to_client(tm=
em_cli_mfn_t cmfn, void *tmem_va, pagesize_t len);=0A =0A
--=__Part56674C6E.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

--=__Part56674C6E.0__=--


From xen-devel-bounces@lists.xen.org Wed Sep 05 12:37:20 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Sep 2012 12:37:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9Er6-0005Gp-24; Wed, 05 Sep 2012 12:37: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 1T9Er4-0005GJ-Fp
	for xen-devel@lists.xen.org; Wed, 05 Sep 2012 12:37:14 +0000
Received: from [85.158.143.35:10765] by server-1.bemta-4.messagelabs.com id
	52/64-12504-97747405; Wed, 05 Sep 2012 12:37:13 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1346848625!16845610!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQwMzE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5068 invoked from network); 5 Sep 2012 12:37:05 -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;
	5 Sep 2012 12:37:05 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 05 Sep 2012 13:37:05 +0100
Message-Id: <504763C60200007800098DD5@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 05 Sep 2012 13:37: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="=__Part8EBF94B6.0__="
Cc: dan.magenheimer@oracle.com, Zhenzhong Duan <zhenzhong.duan@oracle.com>
Subject: [Xen-devel] [PATCH 06/11] tmem: detect arithmetic overflow in
 tmh_copy_{from, to}_client()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<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.

--=__Part8EBF94B6.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

This implies adjusting callers to deal with errors other than -EFAULT
and removing some comments which would otherwise become stale.

This is part of XSA-15 / CVE-2012-3497.

Reported-by: Tim Deegan <tim@xen.org>
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Dan Magenheimer <dan.magenheimer@oracle.com>

--- a/xen/common/tmem.c
+++ b/xen/common/tmem.c
@@ -1535,7 +1535,7 @@ copy_uncompressed:
     /* tmh_copy_from_client properly handles len=3D=3D0 and offsets !=3D =
0 */
     ret =3D tmh_copy_from_client(pgp->pfp, cmfn, tmem_offset, pfn_offset, =
len,
                                tmh_cli_buf_null);
-    if ( ret =3D=3D -EFAULT )
+    if ( ret < 0 )
         goto bad_copy;
     if ( tmh_dedup_enabled() && !is_persistent(pool) )
     {
@@ -1556,9 +1556,7 @@ done:
     return 1;
=20
 bad_copy:
-    /* this should only happen if the client passed a bad mfn */
     failed_copies++;
-    ret =3D -EFAULT;
     goto cleanup;
=20
 failed_dup:
@@ -1662,7 +1660,7 @@ copy_uncompressed:
     /* tmh_copy_from_client properly handles len=3D=3D0 (TMEM_NEW_PAGE) =
*/
     ret =3D tmh_copy_from_client(pgp->pfp, cmfn, tmem_offset, pfn_offset, =
len,
                                clibuf);
-    if ( ret =3D=3D -EFAULT )
+    if ( ret < 0 )
         goto bad_copy;
     if ( tmh_dedup_enabled() && !is_persistent(pool) )
     {
@@ -1702,8 +1700,6 @@ insert_page:
     return 1;
=20
 bad_copy:
-    /* this should only happen if the client passed a bad mfn */
-    ret =3D -EFAULT;
     failed_copies++;
=20
 delete_and_free:
@@ -1737,7 +1733,7 @@ static NOINLINE int do_tmem_get(pool_t *
     pgp_t *pgp;
     client_t *client =3D pool->client;
     DECL_LOCAL_CYC_COUNTER(decompress);
-    int rc =3D -EFAULT;
+    int rc;
=20
     if ( !_atomic_read(pool->pgp_count) )
         return -EEMPTY;
@@ -1761,20 +1757,20 @@ static NOINLINE int do_tmem_get(pool_t *
     ASSERT(pgp->size !=3D -1);
     if ( tmh_dedup_enabled() && !is_persistent(pool) &&
               pgp->firstbyte !=3D NOT_SHAREABLE )
-    {
         rc =3D pcd_copy_to_client(cmfn, pgp);
-        if ( rc <=3D 0 )
-            goto bad_copy;
-    } else if ( pgp->size !=3D 0 ) {
+    else if ( pgp->size !=3D 0 )
+    {
         START_CYC_COUNTER(decompress);
         rc =3D tmh_decompress_to_client(cmfn, pgp->cdata,
                                       pgp->size, clibuf);
-        if ( rc <=3D 0 )
-            goto bad_copy;
         END_CYC_COUNTER(decompress);
-    } else if ( tmh_copy_to_client(cmfn, pgp->pfp, tmem_offset,
-                                 pfn_offset, len, clibuf) =3D=3D -EFAULT)
+    }
+    else
+        rc =3D tmh_copy_to_client(cmfn, pgp->pfp, tmem_offset,
+                                pfn_offset, len, clibuf);
+    if ( rc <=3D 0 )
         goto bad_copy;
+
     if ( is_ephemeral(pool) )
     {
         if ( is_private(pool) )
@@ -1811,7 +1807,6 @@ static NOINLINE int do_tmem_get(pool_t *
     return 1;
=20
 bad_copy:
-    /* this should only happen if the client passed a bad mfn */
     failed_copies++;
     return rc;
 }
--- a/xen/common/tmem_xen.c
+++ b/xen/common/tmem_xen.c
@@ -153,6 +153,8 @@ EXPORT int tmh_copy_from_client(pfp_t *p
     pfp_t *cli_pfp =3D NULL;
     int rc =3D 1;
=20
+    if ( tmem_offset > PAGE_SIZE || pfn_offset > PAGE_SIZE || len > =
PAGE_SIZE )
+        return -EINVAL;
     ASSERT(pfp !=3D NULL);
     tmem_mfn =3D page_to_mfn(pfp);
     tmem_va =3D map_domain_page(tmem_mfn);
@@ -183,6 +185,8 @@ EXPORT int tmh_copy_from_client(pfp_t *p
                                          pfn_offset, len) )
             rc =3D -EFAULT;
     }
+    else if ( len )
+        rc =3D -EINVAL;
     if ( cli_va )
         cli_put_page(cmfn, cli_va, cli_pfp, cli_mfn, 0);
     unmap_domain_page(tmem_va);
@@ -230,6 +234,8 @@ EXPORT int tmh_copy_to_client(tmem_cli_m
     pfp_t *cli_pfp =3D NULL;
     int rc =3D 1;
=20
+    if ( tmem_offset > PAGE_SIZE || pfn_offset > PAGE_SIZE || len > =
PAGE_SIZE )
+        return -EINVAL;
     ASSERT(pfp !=3D NULL);
     if ( guest_handle_is_null(clibuf) )
     {
@@ -249,6 +255,8 @@ EXPORT int tmh_copy_to_client(tmem_cli_m
                                        tmem_va + tmem_offset, len) )
             rc =3D -EFAULT;
     }
+    else if ( len )
+        rc =3D -EINVAL;
     unmap_domain_page(tmem_va);
     if ( cli_va )
         cli_put_page(cmfn, cli_va, cli_pfp, cli_mfn, 1);



--=__Part8EBF94B6.0__=
Content-Type: text/plain; name="tmem-xsa-15-6.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="tmem-xsa-15-6.patch"

tmem: detect arithmetic overflow in tmh_copy_{from,to}_client()=0A=0AThis =
implies adjusting callers to deal with errors other than -EFAULT=0Aand =
removing some comments which would otherwise become stale.=0A=0AThis is =
part of XSA-15 / CVE-2012-3497.=0A=0AReported-by: Tim Deegan <tim@xen.org>=
=0ASigned-off-by: Jan Beulich <jbeulich@suse.com>=0AAcked-by: Dan =
Magenheimer <dan.magenheimer@oracle.com>=0A=0A--- a/xen/common/tmem.c=0A+++=
 b/xen/common/tmem.c=0A@@ -1535,7 +1535,7 @@ copy_uncompressed:=0A     /* =
tmh_copy_from_client properly handles len=3D=3D0 and offsets !=3D 0 */=0A  =
   ret =3D tmh_copy_from_client(pgp->pfp, cmfn, tmem_offset, pfn_offset, =
len,=0A                                tmh_cli_buf_null);=0A-    if ( ret =
=3D=3D -EFAULT )=0A+    if ( ret < 0 )=0A         goto bad_copy;=0A     if =
( tmh_dedup_enabled() && !is_persistent(pool) )=0A     {=0A@@ -1556,9 =
+1556,7 @@ done:=0A     return 1;=0A =0A bad_copy:=0A-    /* this should =
only happen if the client passed a bad mfn */=0A     failed_copies++;=0A-  =
  ret =3D -EFAULT;=0A     goto cleanup;=0A =0A failed_dup:=0A@@ -1662,7 =
+1660,7 @@ copy_uncompressed:=0A     /* tmh_copy_from_client properly =
handles len=3D=3D0 (TMEM_NEW_PAGE) */=0A     ret =3D tmh_copy_from_client(p=
gp->pfp, cmfn, tmem_offset, pfn_offset, len,=0A                            =
    clibuf);=0A-    if ( ret =3D=3D -EFAULT )=0A+    if ( ret < 0 )=0A     =
    goto bad_copy;=0A     if ( tmh_dedup_enabled() && !is_persistent(pool) =
)=0A     {=0A@@ -1702,8 +1700,6 @@ insert_page:=0A     return 1;=0A =0A =
bad_copy:=0A-    /* this should only happen if the client passed a bad mfn =
*/=0A-    ret =3D -EFAULT;=0A     failed_copies++;=0A =0A delete_and_free:=
=0A@@ -1737,7 +1733,7 @@ static NOINLINE int do_tmem_get(pool_t *=0A     =
pgp_t *pgp;=0A     client_t *client =3D pool->client;=0A     DECL_LOCAL_CYC=
_COUNTER(decompress);=0A-    int rc =3D -EFAULT;=0A+    int rc;=0A =0A     =
if ( !_atomic_read(pool->pgp_count) )=0A         return -EEMPTY;=0A@@ =
-1761,20 +1757,20 @@ static NOINLINE int do_tmem_get(pool_t *=0A     =
ASSERT(pgp->size !=3D -1);=0A     if ( tmh_dedup_enabled() && !is_persisten=
t(pool) &&=0A               pgp->firstbyte !=3D NOT_SHAREABLE )=0A-    =
{=0A         rc =3D pcd_copy_to_client(cmfn, pgp);=0A-        if ( rc <=3D =
0 )=0A-            goto bad_copy;=0A-    } else if ( pgp->size !=3D 0 ) =
{=0A+    else if ( pgp->size !=3D 0 )=0A+    {=0A         START_CYC_COUNTER=
(decompress);=0A         rc =3D tmh_decompress_to_client(cmfn, pgp->cdata,=
=0A                                       pgp->size, clibuf);=0A-        =
if ( rc <=3D 0 )=0A-            goto bad_copy;=0A         END_CYC_COUNTER(d=
ecompress);=0A-    } else if ( tmh_copy_to_client(cmfn, pgp->pfp, =
tmem_offset,=0A-                                 pfn_offset, len, clibuf) =
=3D=3D -EFAULT)=0A+    }=0A+    else=0A+        rc =3D tmh_copy_to_client(c=
mfn, pgp->pfp, tmem_offset,=0A+                                pfn_offset, =
len, clibuf);=0A+    if ( rc <=3D 0 )=0A         goto bad_copy;=0A+=0A     =
if ( is_ephemeral(pool) )=0A     {=0A         if ( is_private(pool) )=0A@@ =
-1811,7 +1807,6 @@ static NOINLINE int do_tmem_get(pool_t *=0A     return =
1;=0A =0A bad_copy:=0A-    /* this should only happen if the client passed =
a bad mfn */=0A     failed_copies++;=0A     return rc;=0A }=0A--- =
a/xen/common/tmem_xen.c=0A+++ b/xen/common/tmem_xen.c=0A@@ -153,6 +153,8 =
@@ EXPORT int tmh_copy_from_client(pfp_t *p=0A     pfp_t *cli_pfp =3D =
NULL;=0A     int rc =3D 1;=0A =0A+    if ( tmem_offset > PAGE_SIZE || =
pfn_offset > PAGE_SIZE || len > PAGE_SIZE )=0A+        return -EINVAL;=0A  =
   ASSERT(pfp !=3D NULL);=0A     tmem_mfn =3D page_to_mfn(pfp);=0A     =
tmem_va =3D map_domain_page(tmem_mfn);=0A@@ -183,6 +185,8 @@ EXPORT int =
tmh_copy_from_client(pfp_t *p=0A                                          =
pfn_offset, len) )=0A             rc =3D -EFAULT;=0A     }=0A+    else if =
( len )=0A+        rc =3D -EINVAL;=0A     if ( cli_va )=0A         =
cli_put_page(cmfn, cli_va, cli_pfp, cli_mfn, 0);=0A     unmap_domain_page(t=
mem_va);=0A@@ -230,6 +234,8 @@ EXPORT int tmh_copy_to_client(tmem_cli_m=0A =
    pfp_t *cli_pfp =3D NULL;=0A     int rc =3D 1;=0A =0A+    if ( =
tmem_offset > PAGE_SIZE || pfn_offset > PAGE_SIZE || len > PAGE_SIZE )=0A+ =
       return -EINVAL;=0A     ASSERT(pfp !=3D NULL);=0A     if ( guest_hand=
le_is_null(clibuf) )=0A     {=0A@@ -249,6 +255,8 @@ EXPORT int tmh_copy_to_=
client(tmem_cli_m=0A                                        tmem_va + =
tmem_offset, len) )=0A             rc =3D -EFAULT;=0A     }=0A+    else if =
( len )=0A+        rc =3D -EINVAL;=0A     unmap_domain_page(tmem_va);=0A   =
  if ( cli_va )=0A         cli_put_page(cmfn, cli_va, cli_pfp, cli_mfn, =
1);=0A
--=__Part8EBF94B6.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

--=__Part8EBF94B6.0__=--


From xen-devel-bounces@lists.xen.org Wed Sep 05 12:37:20 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Sep 2012 12:37:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9Er6-0005Gp-24; Wed, 05 Sep 2012 12:37: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 1T9Er4-0005GJ-Fp
	for xen-devel@lists.xen.org; Wed, 05 Sep 2012 12:37:14 +0000
Received: from [85.158.143.35:10765] by server-1.bemta-4.messagelabs.com id
	52/64-12504-97747405; Wed, 05 Sep 2012 12:37:13 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1346848625!16845610!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQwMzE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5068 invoked from network); 5 Sep 2012 12:37:05 -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;
	5 Sep 2012 12:37:05 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 05 Sep 2012 13:37:05 +0100
Message-Id: <504763C60200007800098DD5@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 05 Sep 2012 13:37: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="=__Part8EBF94B6.0__="
Cc: dan.magenheimer@oracle.com, Zhenzhong Duan <zhenzhong.duan@oracle.com>
Subject: [Xen-devel] [PATCH 06/11] tmem: detect arithmetic overflow in
 tmh_copy_{from, to}_client()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<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.

--=__Part8EBF94B6.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

This implies adjusting callers to deal with errors other than -EFAULT
and removing some comments which would otherwise become stale.

This is part of XSA-15 / CVE-2012-3497.

Reported-by: Tim Deegan <tim@xen.org>
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Dan Magenheimer <dan.magenheimer@oracle.com>

--- a/xen/common/tmem.c
+++ b/xen/common/tmem.c
@@ -1535,7 +1535,7 @@ copy_uncompressed:
     /* tmh_copy_from_client properly handles len=3D=3D0 and offsets !=3D =
0 */
     ret =3D tmh_copy_from_client(pgp->pfp, cmfn, tmem_offset, pfn_offset, =
len,
                                tmh_cli_buf_null);
-    if ( ret =3D=3D -EFAULT )
+    if ( ret < 0 )
         goto bad_copy;
     if ( tmh_dedup_enabled() && !is_persistent(pool) )
     {
@@ -1556,9 +1556,7 @@ done:
     return 1;
=20
 bad_copy:
-    /* this should only happen if the client passed a bad mfn */
     failed_copies++;
-    ret =3D -EFAULT;
     goto cleanup;
=20
 failed_dup:
@@ -1662,7 +1660,7 @@ copy_uncompressed:
     /* tmh_copy_from_client properly handles len=3D=3D0 (TMEM_NEW_PAGE) =
*/
     ret =3D tmh_copy_from_client(pgp->pfp, cmfn, tmem_offset, pfn_offset, =
len,
                                clibuf);
-    if ( ret =3D=3D -EFAULT )
+    if ( ret < 0 )
         goto bad_copy;
     if ( tmh_dedup_enabled() && !is_persistent(pool) )
     {
@@ -1702,8 +1700,6 @@ insert_page:
     return 1;
=20
 bad_copy:
-    /* this should only happen if the client passed a bad mfn */
-    ret =3D -EFAULT;
     failed_copies++;
=20
 delete_and_free:
@@ -1737,7 +1733,7 @@ static NOINLINE int do_tmem_get(pool_t *
     pgp_t *pgp;
     client_t *client =3D pool->client;
     DECL_LOCAL_CYC_COUNTER(decompress);
-    int rc =3D -EFAULT;
+    int rc;
=20
     if ( !_atomic_read(pool->pgp_count) )
         return -EEMPTY;
@@ -1761,20 +1757,20 @@ static NOINLINE int do_tmem_get(pool_t *
     ASSERT(pgp->size !=3D -1);
     if ( tmh_dedup_enabled() && !is_persistent(pool) &&
               pgp->firstbyte !=3D NOT_SHAREABLE )
-    {
         rc =3D pcd_copy_to_client(cmfn, pgp);
-        if ( rc <=3D 0 )
-            goto bad_copy;
-    } else if ( pgp->size !=3D 0 ) {
+    else if ( pgp->size !=3D 0 )
+    {
         START_CYC_COUNTER(decompress);
         rc =3D tmh_decompress_to_client(cmfn, pgp->cdata,
                                       pgp->size, clibuf);
-        if ( rc <=3D 0 )
-            goto bad_copy;
         END_CYC_COUNTER(decompress);
-    } else if ( tmh_copy_to_client(cmfn, pgp->pfp, tmem_offset,
-                                 pfn_offset, len, clibuf) =3D=3D -EFAULT)
+    }
+    else
+        rc =3D tmh_copy_to_client(cmfn, pgp->pfp, tmem_offset,
+                                pfn_offset, len, clibuf);
+    if ( rc <=3D 0 )
         goto bad_copy;
+
     if ( is_ephemeral(pool) )
     {
         if ( is_private(pool) )
@@ -1811,7 +1807,6 @@ static NOINLINE int do_tmem_get(pool_t *
     return 1;
=20
 bad_copy:
-    /* this should only happen if the client passed a bad mfn */
     failed_copies++;
     return rc;
 }
--- a/xen/common/tmem_xen.c
+++ b/xen/common/tmem_xen.c
@@ -153,6 +153,8 @@ EXPORT int tmh_copy_from_client(pfp_t *p
     pfp_t *cli_pfp =3D NULL;
     int rc =3D 1;
=20
+    if ( tmem_offset > PAGE_SIZE || pfn_offset > PAGE_SIZE || len > =
PAGE_SIZE )
+        return -EINVAL;
     ASSERT(pfp !=3D NULL);
     tmem_mfn =3D page_to_mfn(pfp);
     tmem_va =3D map_domain_page(tmem_mfn);
@@ -183,6 +185,8 @@ EXPORT int tmh_copy_from_client(pfp_t *p
                                          pfn_offset, len) )
             rc =3D -EFAULT;
     }
+    else if ( len )
+        rc =3D -EINVAL;
     if ( cli_va )
         cli_put_page(cmfn, cli_va, cli_pfp, cli_mfn, 0);
     unmap_domain_page(tmem_va);
@@ -230,6 +234,8 @@ EXPORT int tmh_copy_to_client(tmem_cli_m
     pfp_t *cli_pfp =3D NULL;
     int rc =3D 1;
=20
+    if ( tmem_offset > PAGE_SIZE || pfn_offset > PAGE_SIZE || len > =
PAGE_SIZE )
+        return -EINVAL;
     ASSERT(pfp !=3D NULL);
     if ( guest_handle_is_null(clibuf) )
     {
@@ -249,6 +255,8 @@ EXPORT int tmh_copy_to_client(tmem_cli_m
                                        tmem_va + tmem_offset, len) )
             rc =3D -EFAULT;
     }
+    else if ( len )
+        rc =3D -EINVAL;
     unmap_domain_page(tmem_va);
     if ( cli_va )
         cli_put_page(cmfn, cli_va, cli_pfp, cli_mfn, 1);



--=__Part8EBF94B6.0__=
Content-Type: text/plain; name="tmem-xsa-15-6.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="tmem-xsa-15-6.patch"

tmem: detect arithmetic overflow in tmh_copy_{from,to}_client()=0A=0AThis =
implies adjusting callers to deal with errors other than -EFAULT=0Aand =
removing some comments which would otherwise become stale.=0A=0AThis is =
part of XSA-15 / CVE-2012-3497.=0A=0AReported-by: Tim Deegan <tim@xen.org>=
=0ASigned-off-by: Jan Beulich <jbeulich@suse.com>=0AAcked-by: Dan =
Magenheimer <dan.magenheimer@oracle.com>=0A=0A--- a/xen/common/tmem.c=0A+++=
 b/xen/common/tmem.c=0A@@ -1535,7 +1535,7 @@ copy_uncompressed:=0A     /* =
tmh_copy_from_client properly handles len=3D=3D0 and offsets !=3D 0 */=0A  =
   ret =3D tmh_copy_from_client(pgp->pfp, cmfn, tmem_offset, pfn_offset, =
len,=0A                                tmh_cli_buf_null);=0A-    if ( ret =
=3D=3D -EFAULT )=0A+    if ( ret < 0 )=0A         goto bad_copy;=0A     if =
( tmh_dedup_enabled() && !is_persistent(pool) )=0A     {=0A@@ -1556,9 =
+1556,7 @@ done:=0A     return 1;=0A =0A bad_copy:=0A-    /* this should =
only happen if the client passed a bad mfn */=0A     failed_copies++;=0A-  =
  ret =3D -EFAULT;=0A     goto cleanup;=0A =0A failed_dup:=0A@@ -1662,7 =
+1660,7 @@ copy_uncompressed:=0A     /* tmh_copy_from_client properly =
handles len=3D=3D0 (TMEM_NEW_PAGE) */=0A     ret =3D tmh_copy_from_client(p=
gp->pfp, cmfn, tmem_offset, pfn_offset, len,=0A                            =
    clibuf);=0A-    if ( ret =3D=3D -EFAULT )=0A+    if ( ret < 0 )=0A     =
    goto bad_copy;=0A     if ( tmh_dedup_enabled() && !is_persistent(pool) =
)=0A     {=0A@@ -1702,8 +1700,6 @@ insert_page:=0A     return 1;=0A =0A =
bad_copy:=0A-    /* this should only happen if the client passed a bad mfn =
*/=0A-    ret =3D -EFAULT;=0A     failed_copies++;=0A =0A delete_and_free:=
=0A@@ -1737,7 +1733,7 @@ static NOINLINE int do_tmem_get(pool_t *=0A     =
pgp_t *pgp;=0A     client_t *client =3D pool->client;=0A     DECL_LOCAL_CYC=
_COUNTER(decompress);=0A-    int rc =3D -EFAULT;=0A+    int rc;=0A =0A     =
if ( !_atomic_read(pool->pgp_count) )=0A         return -EEMPTY;=0A@@ =
-1761,20 +1757,20 @@ static NOINLINE int do_tmem_get(pool_t *=0A     =
ASSERT(pgp->size !=3D -1);=0A     if ( tmh_dedup_enabled() && !is_persisten=
t(pool) &&=0A               pgp->firstbyte !=3D NOT_SHAREABLE )=0A-    =
{=0A         rc =3D pcd_copy_to_client(cmfn, pgp);=0A-        if ( rc <=3D =
0 )=0A-            goto bad_copy;=0A-    } else if ( pgp->size !=3D 0 ) =
{=0A+    else if ( pgp->size !=3D 0 )=0A+    {=0A         START_CYC_COUNTER=
(decompress);=0A         rc =3D tmh_decompress_to_client(cmfn, pgp->cdata,=
=0A                                       pgp->size, clibuf);=0A-        =
if ( rc <=3D 0 )=0A-            goto bad_copy;=0A         END_CYC_COUNTER(d=
ecompress);=0A-    } else if ( tmh_copy_to_client(cmfn, pgp->pfp, =
tmem_offset,=0A-                                 pfn_offset, len, clibuf) =
=3D=3D -EFAULT)=0A+    }=0A+    else=0A+        rc =3D tmh_copy_to_client(c=
mfn, pgp->pfp, tmem_offset,=0A+                                pfn_offset, =
len, clibuf);=0A+    if ( rc <=3D 0 )=0A         goto bad_copy;=0A+=0A     =
if ( is_ephemeral(pool) )=0A     {=0A         if ( is_private(pool) )=0A@@ =
-1811,7 +1807,6 @@ static NOINLINE int do_tmem_get(pool_t *=0A     return =
1;=0A =0A bad_copy:=0A-    /* this should only happen if the client passed =
a bad mfn */=0A     failed_copies++;=0A     return rc;=0A }=0A--- =
a/xen/common/tmem_xen.c=0A+++ b/xen/common/tmem_xen.c=0A@@ -153,6 +153,8 =
@@ EXPORT int tmh_copy_from_client(pfp_t *p=0A     pfp_t *cli_pfp =3D =
NULL;=0A     int rc =3D 1;=0A =0A+    if ( tmem_offset > PAGE_SIZE || =
pfn_offset > PAGE_SIZE || len > PAGE_SIZE )=0A+        return -EINVAL;=0A  =
   ASSERT(pfp !=3D NULL);=0A     tmem_mfn =3D page_to_mfn(pfp);=0A     =
tmem_va =3D map_domain_page(tmem_mfn);=0A@@ -183,6 +185,8 @@ EXPORT int =
tmh_copy_from_client(pfp_t *p=0A                                          =
pfn_offset, len) )=0A             rc =3D -EFAULT;=0A     }=0A+    else if =
( len )=0A+        rc =3D -EINVAL;=0A     if ( cli_va )=0A         =
cli_put_page(cmfn, cli_va, cli_pfp, cli_mfn, 0);=0A     unmap_domain_page(t=
mem_va);=0A@@ -230,6 +234,8 @@ EXPORT int tmh_copy_to_client(tmem_cli_m=0A =
    pfp_t *cli_pfp =3D NULL;=0A     int rc =3D 1;=0A =0A+    if ( =
tmem_offset > PAGE_SIZE || pfn_offset > PAGE_SIZE || len > PAGE_SIZE )=0A+ =
       return -EINVAL;=0A     ASSERT(pfp !=3D NULL);=0A     if ( guest_hand=
le_is_null(clibuf) )=0A     {=0A@@ -249,6 +255,8 @@ EXPORT int tmh_copy_to_=
client(tmem_cli_m=0A                                        tmem_va + =
tmem_offset, len) )=0A             rc =3D -EFAULT;=0A     }=0A+    else if =
( len )=0A+        rc =3D -EINVAL;=0A     unmap_domain_page(tmem_va);=0A   =
  if ( cli_va )=0A         cli_put_page(cmfn, cli_va, cli_pfp, cli_mfn, =
1);=0A
--=__Part8EBF94B6.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

--=__Part8EBF94B6.0__=--


From xen-devel-bounces@lists.xen.org Wed Sep 05 12:37:45 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Sep 2012 12:37:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9ErU-0005P1-GK; Wed, 05 Sep 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 1T9ErT-0005OT-F6
	for xen-devel@lists.xen.org; Wed, 05 Sep 2012 12:37:39 +0000
Received: from [85.158.143.99:26335] by server-1.bemta-4.messagelabs.com id
	11/35-12504-29747405; Wed, 05 Sep 2012 12:37:38 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1346848658!21643619!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQwMzE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17113 invoked from network); 5 Sep 2012 12:37:38 -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;
	5 Sep 2012 12:37:38 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 05 Sep 2012 13:37:38 +0100
Message-Id: <504763E70200007800098DD9@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 05 Sep 2012 13:38: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="=__PartEFDEF5D7.0__="
Cc: dan.magenheimer@oracle.com, Zhenzhong Duan <zhenzhong.duan@oracle.com>
Subject: [Xen-devel] [PATCH 07/11] tmem: properly drop lock on error path in
 do_tmem_get()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
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.

--=__PartEFDEF5D7.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Also remove a bogus assertion.

This is part of XSA-15 / CVE-2012-3497.

Reported-by: Tim Deegan <tim@xen.org>
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Dan Magenheimer <dan.magenheimer@oracle.com>

--- a/xen/common/tmem.c
+++ b/xen/common/tmem.c
@@ -1790,7 +1790,6 @@ static NOINLINE int do_tmem_get(pool_t *
             list_del(&pgp->us.client_eph_pages);
             list_add_tail(&pgp->us.client_eph_pages,&client->ephemeral_pag=
e_list);
             tmem_spin_unlock(&eph_lists_spinlock);
-            ASSERT(obj !=3D NULL);
             obj->last_client =3D tmh_get_cli_id_from_current();
         }
     }
@@ -1807,6 +1806,8 @@ static NOINLINE int do_tmem_get(pool_t *
     return 1;
=20
 bad_copy:
+    obj->no_evict =3D 0;
+    tmem_spin_unlock(&obj->obj_spinlock);
     failed_copies++;
     return rc;
 }




--=__PartEFDEF5D7.0__=
Content-Type: text/plain; name="tmem-xsa-15-7.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="tmem-xsa-15-7.patch"

tmem: properly drop lock on error path in do_tmem_get()=0A=0AAlso remove a =
bogus assertion.=0A=0AThis is part of XSA-15 / CVE-2012-3497.=0A=0AReported=
-by: Tim Deegan <tim@xen.org>=0ASigned-off-by: Jan Beulich <jbeulich@suse.c=
om>=0AAcked-by: Dan Magenheimer <dan.magenheimer@oracle.com>=0A=0A--- =
a/xen/common/tmem.c=0A+++ b/xen/common/tmem.c=0A@@ -1790,7 +1790,6 @@ =
static NOINLINE int do_tmem_get(pool_t *=0A             list_del(&pgp->us.c=
lient_eph_pages);=0A             list_add_tail(&pgp->us.client_eph_pages,&c=
lient->ephemeral_page_list);=0A             tmem_spin_unlock(&eph_lists_spi=
nlock);=0A-            ASSERT(obj !=3D NULL);=0A             obj->last_clie=
nt =3D tmh_get_cli_id_from_current();=0A         }=0A     }=0A@@ -1807,6 =
+1806,8 @@ static NOINLINE int do_tmem_get(pool_t *=0A     return 1;=0A =
=0A bad_copy:=0A+    obj->no_evict =3D 0;=0A+    tmem_spin_unlock(&obj->obj=
_spinlock);=0A     failed_copies++;=0A     return rc;=0A }=0A
--=__PartEFDEF5D7.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

--=__PartEFDEF5D7.0__=--


From xen-devel-bounces@lists.xen.org Wed Sep 05 12:37:45 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Sep 2012 12:37:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9ErU-0005P1-GK; Wed, 05 Sep 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 1T9ErT-0005OT-F6
	for xen-devel@lists.xen.org; Wed, 05 Sep 2012 12:37:39 +0000
Received: from [85.158.143.99:26335] by server-1.bemta-4.messagelabs.com id
	11/35-12504-29747405; Wed, 05 Sep 2012 12:37:38 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1346848658!21643619!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQwMzE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17113 invoked from network); 5 Sep 2012 12:37:38 -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;
	5 Sep 2012 12:37:38 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 05 Sep 2012 13:37:38 +0100
Message-Id: <504763E70200007800098DD9@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 05 Sep 2012 13:38: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="=__PartEFDEF5D7.0__="
Cc: dan.magenheimer@oracle.com, Zhenzhong Duan <zhenzhong.duan@oracle.com>
Subject: [Xen-devel] [PATCH 07/11] tmem: properly drop lock on error path in
 do_tmem_get()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
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.

--=__PartEFDEF5D7.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Also remove a bogus assertion.

This is part of XSA-15 / CVE-2012-3497.

Reported-by: Tim Deegan <tim@xen.org>
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Dan Magenheimer <dan.magenheimer@oracle.com>

--- a/xen/common/tmem.c
+++ b/xen/common/tmem.c
@@ -1790,7 +1790,6 @@ static NOINLINE int do_tmem_get(pool_t *
             list_del(&pgp->us.client_eph_pages);
             list_add_tail(&pgp->us.client_eph_pages,&client->ephemeral_pag=
e_list);
             tmem_spin_unlock(&eph_lists_spinlock);
-            ASSERT(obj !=3D NULL);
             obj->last_client =3D tmh_get_cli_id_from_current();
         }
     }
@@ -1807,6 +1806,8 @@ static NOINLINE int do_tmem_get(pool_t *
     return 1;
=20
 bad_copy:
+    obj->no_evict =3D 0;
+    tmem_spin_unlock(&obj->obj_spinlock);
     failed_copies++;
     return rc;
 }




--=__PartEFDEF5D7.0__=
Content-Type: text/plain; name="tmem-xsa-15-7.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="tmem-xsa-15-7.patch"

tmem: properly drop lock on error path in do_tmem_get()=0A=0AAlso remove a =
bogus assertion.=0A=0AThis is part of XSA-15 / CVE-2012-3497.=0A=0AReported=
-by: Tim Deegan <tim@xen.org>=0ASigned-off-by: Jan Beulich <jbeulich@suse.c=
om>=0AAcked-by: Dan Magenheimer <dan.magenheimer@oracle.com>=0A=0A--- =
a/xen/common/tmem.c=0A+++ b/xen/common/tmem.c=0A@@ -1790,7 +1790,6 @@ =
static NOINLINE int do_tmem_get(pool_t *=0A             list_del(&pgp->us.c=
lient_eph_pages);=0A             list_add_tail(&pgp->us.client_eph_pages,&c=
lient->ephemeral_page_list);=0A             tmem_spin_unlock(&eph_lists_spi=
nlock);=0A-            ASSERT(obj !=3D NULL);=0A             obj->last_clie=
nt =3D tmh_get_cli_id_from_current();=0A         }=0A     }=0A@@ -1807,6 =
+1806,8 @@ static NOINLINE int do_tmem_get(pool_t *=0A     return 1;=0A =
=0A bad_copy:=0A+    obj->no_evict =3D 0;=0A+    tmem_spin_unlock(&obj->obj=
_spinlock);=0A     failed_copies++;=0A     return rc;=0A }=0A
--=__PartEFDEF5D7.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

--=__PartEFDEF5D7.0__=--


From xen-devel-bounces@lists.xen.org Wed Sep 05 12:38:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Sep 2012 12: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 1T9Erx-0005Yt-V1; Wed, 05 Sep 2012 12:38:09 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1T9Erv-0005Y6-QT
	for xen-devel@lists.xen.org; Wed, 05 Sep 2012 12:38:08 +0000
Received: from [85.158.143.99:32592] by server-3.bemta-4.messagelabs.com id
	64/B7-08232-FA747405; Wed, 05 Sep 2012 12:38:07 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1346848686!21138410!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQwMzE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21689 invoked from network); 5 Sep 2012 12:38:06 -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;
	5 Sep 2012 12:38:06 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 05 Sep 2012 13:38:06 +0100
Message-Id: <504764040200007800098DDD@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 05 Sep 2012 13:39:00 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__PartCCFDD6F4.0__="
Cc: dan.magenheimer@oracle.com, Zhenzhong Duan <zhenzhong.duan@oracle.com>
Subject: [Xen-devel] [PATCH 08/11] tmem: properly drop lock on error path in
 do_tmem_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>
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.

--=__PartCCFDD6F4.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

This is part of XSA-15 / CVE-2012-3497.

Reported-by: Tim Deegan <tim@xen.org>
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Dan Magenheimer <dan.magenheimer@oracle.com>

--- a/xen/common/tmem.c
+++ b/xen/common/tmem.c
@@ -2659,13 +2659,19 @@ EXPORT long do_tmem_op(tmem_cli_op_t uop
     if ( client !=3D NULL && tmh_client_is_dying(client) )
     {
         rc =3D -ENODEV;
-        goto out;
+        if ( tmh_lock_all )
+            goto out;
+ simple_error:
+        errored_tmem_ops++;
+        return rc;
     }
=20
     if ( unlikely(tmh_get_tmemop_from_client(&op, uops) !=3D 0) )
     {
         printk("tmem: can't get tmem struct from %s\n",client_str);
         rc =3D -EFAULT;
+        if ( !tmh_lock_all )
+            goto simple_error;
         goto out;
     }
=20




--=__PartCCFDD6F4.0__=
Content-Type: text/plain; name="tmem-xsa-15-8.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="tmem-xsa-15-8.patch"

tmem: properly drop lock on error path in do_tmem_op()=0A=0AThis is part =
of XSA-15 / CVE-2012-3497.=0A=0AReported-by: Tim Deegan <tim@xen.org>=0ASig=
ned-off-by: Jan Beulich <jbeulich@suse.com>=0AAcked-by: Dan Magenheimer =
<dan.magenheimer@oracle.com>=0A=0A--- a/xen/common/tmem.c=0A+++ b/xen/commo=
n/tmem.c=0A@@ -2659,13 +2659,19 @@ EXPORT long do_tmem_op(tmem_cli_op_t =
uop=0A     if ( client !=3D NULL && tmh_client_is_dying(client) )=0A     =
{=0A         rc =3D -ENODEV;=0A-        goto out;=0A+        if ( =
tmh_lock_all )=0A+            goto out;=0A+ simple_error:=0A+        =
errored_tmem_ops++;=0A+        return rc;=0A     }=0A =0A     if ( =
unlikely(tmh_get_tmemop_from_client(&op, uops) !=3D 0) )=0A     {=0A       =
  printk("tmem: can't get tmem struct from %s\n",client_str);=0A         =
rc =3D -EFAULT;=0A+        if ( !tmh_lock_all )=0A+            goto =
simple_error;=0A         goto out;=0A     }=0A =0A
--=__PartCCFDD6F4.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

--=__PartCCFDD6F4.0__=--


From xen-devel-bounces@lists.xen.org Wed Sep 05 12:38:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Sep 2012 12: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 1T9Erx-0005Yt-V1; Wed, 05 Sep 2012 12:38:09 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1T9Erv-0005Y6-QT
	for xen-devel@lists.xen.org; Wed, 05 Sep 2012 12:38:08 +0000
Received: from [85.158.143.99:32592] by server-3.bemta-4.messagelabs.com id
	64/B7-08232-FA747405; Wed, 05 Sep 2012 12:38:07 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1346848686!21138410!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQwMzE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21689 invoked from network); 5 Sep 2012 12:38:06 -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;
	5 Sep 2012 12:38:06 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 05 Sep 2012 13:38:06 +0100
Message-Id: <504764040200007800098DDD@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 05 Sep 2012 13:39:00 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__PartCCFDD6F4.0__="
Cc: dan.magenheimer@oracle.com, Zhenzhong Duan <zhenzhong.duan@oracle.com>
Subject: [Xen-devel] [PATCH 08/11] tmem: properly drop lock on error path in
 do_tmem_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>
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.

--=__PartCCFDD6F4.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

This is part of XSA-15 / CVE-2012-3497.

Reported-by: Tim Deegan <tim@xen.org>
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Dan Magenheimer <dan.magenheimer@oracle.com>

--- a/xen/common/tmem.c
+++ b/xen/common/tmem.c
@@ -2659,13 +2659,19 @@ EXPORT long do_tmem_op(tmem_cli_op_t uop
     if ( client !=3D NULL && tmh_client_is_dying(client) )
     {
         rc =3D -ENODEV;
-        goto out;
+        if ( tmh_lock_all )
+            goto out;
+ simple_error:
+        errored_tmem_ops++;
+        return rc;
     }
=20
     if ( unlikely(tmh_get_tmemop_from_client(&op, uops) !=3D 0) )
     {
         printk("tmem: can't get tmem struct from %s\n",client_str);
         rc =3D -EFAULT;
+        if ( !tmh_lock_all )
+            goto simple_error;
         goto out;
     }
=20




--=__PartCCFDD6F4.0__=
Content-Type: text/plain; name="tmem-xsa-15-8.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="tmem-xsa-15-8.patch"

tmem: properly drop lock on error path in do_tmem_op()=0A=0AThis is part =
of XSA-15 / CVE-2012-3497.=0A=0AReported-by: Tim Deegan <tim@xen.org>=0ASig=
ned-off-by: Jan Beulich <jbeulich@suse.com>=0AAcked-by: Dan Magenheimer =
<dan.magenheimer@oracle.com>=0A=0A--- a/xen/common/tmem.c=0A+++ b/xen/commo=
n/tmem.c=0A@@ -2659,13 +2659,19 @@ EXPORT long do_tmem_op(tmem_cli_op_t =
uop=0A     if ( client !=3D NULL && tmh_client_is_dying(client) )=0A     =
{=0A         rc =3D -ENODEV;=0A-        goto out;=0A+        if ( =
tmh_lock_all )=0A+            goto out;=0A+ simple_error:=0A+        =
errored_tmem_ops++;=0A+        return rc;=0A     }=0A =0A     if ( =
unlikely(tmh_get_tmemop_from_client(&op, uops) !=3D 0) )=0A     {=0A       =
  printk("tmem: can't get tmem struct from %s\n",client_str);=0A         =
rc =3D -EFAULT;=0A+        if ( !tmh_lock_all )=0A+            goto =
simple_error;=0A         goto out;=0A     }=0A =0A
--=__PartCCFDD6F4.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

--=__PartCCFDD6F4.0__=--


From xen-devel-bounces@lists.xen.org Wed Sep 05 12:38:49 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Sep 2012 12:38:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9EsW-0005kJ-JT; Wed, 05 Sep 2012 12:38:44 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1T9EsV-0005jw-P6
	for xen-devel@lists.xen.org; Wed, 05 Sep 2012 12:38:43 +0000
Received: from [85.158.143.99:52739] by server-3.bemta-4.messagelabs.com id
	FC/E8-08232-3D747405; Wed, 05 Sep 2012 12:38:43 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1346848722!18896470!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQwMzE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30409 invoked from network); 5 Sep 2012 12:38:42 -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;
	5 Sep 2012 12:38:42 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 05 Sep 2012 13:38:42 +0100
Message-Id: <504764270200007800098DE1@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 05 Sep 2012 13:39:35 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part20113A17.0__="
Cc: dan.magenheimer@oracle.com, Zhenzhong Duan <zhenzhong.duan@oracle.com>
Subject: [Xen-devel] [PATCH 09/11] tmem: reduce severity of log messages
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

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.

--=__Part20113A17.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Otherwise they can be used by a guest to spam the hypervisor log with
all settings at their defaults.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Dan Magenheimer <dan.magenheimer@oracle.com>

--- a/xen/common/tmem.c
+++ b/xen/common/tmem.c
@@ -16,6 +16,7 @@
=20
 #ifdef __XEN__
 #include <xen/tmem_xen.h> /* host-specific (eg Xen) code goes here */
+#define printk(fmt, args...) gdprintk(XENLOG_INFO, fmt, ##args)
 #endif
=20
 #include <xen/tmem.h>




--=__Part20113A17.0__=
Content-Type: text/plain; name="tmem-xsa-15-9.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="tmem-xsa-15-9.patch"

tmem: reduce severity of log messages=0A=0AOtherwise they can be used by a =
guest to spam the hypervisor log with=0Aall settings at their defaults.=0A=
=0ASigned-off-by: Jan Beulich <jbeulich@suse.com>=0AAcked-by: Dan =
Magenheimer <dan.magenheimer@oracle.com>=0A=0A--- a/xen/common/tmem.c=0A+++=
 b/xen/common/tmem.c=0A@@ -16,6 +16,7 @@=0A =0A #ifdef __XEN__=0A #include =
<xen/tmem_xen.h> /* host-specific (eg Xen) code goes here */=0A+#define =
printk(fmt, args...) gdprintk(XENLOG_INFO, fmt, ##args)=0A #endif=0A =0A =
#include <xen/tmem.h>=0A
--=__Part20113A17.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

--=__Part20113A17.0__=--


From xen-devel-bounces@lists.xen.org Wed Sep 05 12:38:49 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Sep 2012 12:38:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9EsW-0005kJ-JT; Wed, 05 Sep 2012 12:38:44 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1T9EsV-0005jw-P6
	for xen-devel@lists.xen.org; Wed, 05 Sep 2012 12:38:43 +0000
Received: from [85.158.143.99:52739] by server-3.bemta-4.messagelabs.com id
	FC/E8-08232-3D747405; Wed, 05 Sep 2012 12:38:43 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1346848722!18896470!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQwMzE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30409 invoked from network); 5 Sep 2012 12:38:42 -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;
	5 Sep 2012 12:38:42 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 05 Sep 2012 13:38:42 +0100
Message-Id: <504764270200007800098DE1@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 05 Sep 2012 13:39:35 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part20113A17.0__="
Cc: dan.magenheimer@oracle.com, Zhenzhong Duan <zhenzhong.duan@oracle.com>
Subject: [Xen-devel] [PATCH 09/11] tmem: reduce severity of log messages
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

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.

--=__Part20113A17.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Otherwise they can be used by a guest to spam the hypervisor log with
all settings at their defaults.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Dan Magenheimer <dan.magenheimer@oracle.com>

--- a/xen/common/tmem.c
+++ b/xen/common/tmem.c
@@ -16,6 +16,7 @@
=20
 #ifdef __XEN__
 #include <xen/tmem_xen.h> /* host-specific (eg Xen) code goes here */
+#define printk(fmt, args...) gdprintk(XENLOG_INFO, fmt, ##args)
 #endif
=20
 #include <xen/tmem.h>




--=__Part20113A17.0__=
Content-Type: text/plain; name="tmem-xsa-15-9.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="tmem-xsa-15-9.patch"

tmem: reduce severity of log messages=0A=0AOtherwise they can be used by a =
guest to spam the hypervisor log with=0Aall settings at their defaults.=0A=
=0ASigned-off-by: Jan Beulich <jbeulich@suse.com>=0AAcked-by: Dan =
Magenheimer <dan.magenheimer@oracle.com>=0A=0A--- a/xen/common/tmem.c=0A+++=
 b/xen/common/tmem.c=0A@@ -16,6 +16,7 @@=0A =0A #ifdef __XEN__=0A #include =
<xen/tmem_xen.h> /* host-specific (eg Xen) code goes here */=0A+#define =
printk(fmt, args...) gdprintk(XENLOG_INFO, fmt, ##args)=0A #endif=0A =0A =
#include <xen/tmem.h>=0A
--=__Part20113A17.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

--=__Part20113A17.0__=--


From xen-devel-bounces@lists.xen.org Wed Sep 05 12:39:32 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Sep 2012 12:39:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9EtF-0005yc-3V; Wed, 05 Sep 2012 12:39: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 1T9EtD-0005y8-Rj
	for xen-devel@lists.xen.org; Wed, 05 Sep 2012 12:39:28 +0000
Received: from [85.158.143.99:58351] by server-1.bemta-4.messagelabs.com id
	EE/48-12504-FF747405; Wed, 05 Sep 2012 12:39:27 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1346848764!23389206!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQwMzE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31154 invoked from network); 5 Sep 2012 12:39:25 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-4.tower-216.messagelabs.com with SMTP;
	5 Sep 2012 12:39:25 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 05 Sep 2012 13:39:25 +0100
Message-Id: <504764510200007800098DE5@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 05 Sep 2012 13:40:17 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part16270C21.0__="
Cc: dan.magenheimer@oracle.com, Zhenzhong Duan <zhenzhong.duan@oracle.com>
Subject: [Xen-devel] [PATCH 10/11] tmem: fixup 2010 cleanup patch that
 breaks tmem save/restore
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<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.

--=__Part16270C21.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

20918:a3fa6d444b25 "Fix domain reference leaks" (in Feb 2010, by Jan)
does some cleanup in addition to the leak fixes.  Unfortunately, that
cleanup inadvertently resulted in an incorrect fallthrough in a switch
statement which breaks tmem save/restore.

That broken patch was apparently applied to 4.0-testing and 4.1-testing
so those are broken as well.

What is the process now for requesting back-patches to 4.0 and 4.1?

(Side note: This does not by itself entirely fix save/restore in 4.2.)

Signed-off-by: Dan Magenheimer <dan.magenheimer@oracle.com>
Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/common/tmem.c
+++ b/xen/common/tmem.c
@@ -2415,6 +2415,7 @@ static NOINLINE int tmemc_save_subop(int
              break;
         tmh_copy_to_client_buf(buf, pool->uuid, 2);
         rc =3D 0;
+        break;
     case TMEMC_SAVE_END:
         if ( client =3D=3D NULL )
             break;
@@ -2425,6 +2426,7 @@ static NOINLINE int tmemc_save_subop(int
                 pgp_free_from_inv_list(client,pgp);
         client->frozen =3D client->was_frozen;
         rc =3D 0;
+        break;
     }
     return rc;
 }




--=__Part16270C21.0__=
Content-Type: application/octet-stream; name="tmem-missing-break"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="tmem-missing-break"

dG1lbTogZml4dXAgMjAxMCBjbGVhbnVwIHBhdGNoIHRoYXQgYnJlYWtzIHRtZW0gc2F2ZS9yZXN0
b3JlCgoyMDkxODphM2ZhNmQ0NDRiMjUgIkZpeCBkb21haW4gcmVmZXJlbmNlIGxlYWtzIiAoaW4g
RmViIDIwMTAsIGJ5IEphbikKZG9lcyBzb21lIGNsZWFudXAgaW4gYWRkaXRpb24gdG8gdGhlIGxl
YWsgZml4ZXMuICBVbmZvcnR1bmF0ZWx5LCB0aGF0CmNsZWFudXAgaW5hZHZlcnRlbnRseSByZXN1
bHRlZCBpbiBhbiBpbmNvcnJlY3QgZmFsbHRocm91Z2ggaW4gYSBzd2l0Y2gKc3RhdGVtZW50IHdo
aWNoIGJyZWFrcyB0bWVtIHNhdmUvcmVzdG9yZS4KClRoYXQgYnJva2VuIHBhdGNoIHdhcyBhcHBh
cmVudGx5IGFwcGxpZWQgdG8gNC4wLXRlc3RpbmcgYW5kIDQuMS10ZXN0aW5nCnNvIHRob3NlIGFy
ZSBicm9rZW4gYXMgd2VsbC4KCldoYXQgaXMgdGhlIHByb2Nlc3Mgbm93IGZvciByZXF1ZXN0aW5n
IGJhY2stcGF0Y2hlcyB0byA0LjAgYW5kIDQuMT8KCihTaWRlIG5vdGU6IFRoaXMgZG9lcyBub3Qg
YnkgaXRzZWxmIGVudGlyZWx5IGZpeCBzYXZlL3Jlc3RvcmUgaW4gNC4yLikKClNpZ25lZC1vZmYt
Ynk6IERhbiBNYWdlbmhlaW1lciA8ZGFuLm1hZ2VuaGVpbWVyQG9yYWNsZS5jb20+ClNpZ25lZC1v
ZmYtYnk6IEphbiBCZXVsaWNoIDxqYmV1bGljaEBzdXNlLmNvbT4KCi0tLSBhL3hlbi9jb21tb24v
dG1lbS5jCisrKyBiL3hlbi9jb21tb24vdG1lbS5jCkBAIC0yNDE1LDYgKzI0MTUsNyBAQCBzdGF0
aWMgTk9JTkxJTkUgaW50IHRtZW1jX3NhdmVfc3Vib3AoaW50CiAgICAgICAgICAgICAgYnJlYWs7
CiAgICAgICAgIHRtaF9jb3B5X3RvX2NsaWVudF9idWYoYnVmLCBwb29sLT51dWlkLCAyKTsKICAg
ICAgICAgcmMgPSAwOworICAgICAgICBicmVhazsKICAgICBjYXNlIFRNRU1DX1NBVkVfRU5EOgog
ICAgICAgICBpZiAoIGNsaWVudCA9PSBOVUxMICkKICAgICAgICAgICAgIGJyZWFrOwpAQCAtMjQy
NSw2ICsyNDI2LDcgQEAgc3RhdGljIE5PSU5MSU5FIGludCB0bWVtY19zYXZlX3N1Ym9wKGludAog
ICAgICAgICAgICAgICAgIHBncF9mcmVlX2Zyb21faW52X2xpc3QoY2xpZW50LHBncCk7CiAgICAg
ICAgIGNsaWVudC0+ZnJvemVuID0gY2xpZW50LT53YXNfZnJvemVuOwogICAgICAgICByYyA9IDA7
CisgICAgICAgIGJyZWFrOwogICAgIH0KICAgICByZXR1cm4gcmM7CiB9Cg==

--=__Part16270C21.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

--=__Part16270C21.0__=--


From xen-devel-bounces@lists.xen.org Wed Sep 05 12:39:32 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Sep 2012 12:39:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9EtF-0005yc-3V; Wed, 05 Sep 2012 12:39: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 1T9EtD-0005y8-Rj
	for xen-devel@lists.xen.org; Wed, 05 Sep 2012 12:39:28 +0000
Received: from [85.158.143.99:58351] by server-1.bemta-4.messagelabs.com id
	EE/48-12504-FF747405; Wed, 05 Sep 2012 12:39:27 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1346848764!23389206!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQwMzE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31154 invoked from network); 5 Sep 2012 12:39:25 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-4.tower-216.messagelabs.com with SMTP;
	5 Sep 2012 12:39:25 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 05 Sep 2012 13:39:25 +0100
Message-Id: <504764510200007800098DE5@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 05 Sep 2012 13:40:17 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part16270C21.0__="
Cc: dan.magenheimer@oracle.com, Zhenzhong Duan <zhenzhong.duan@oracle.com>
Subject: [Xen-devel] [PATCH 10/11] tmem: fixup 2010 cleanup patch that
 breaks tmem save/restore
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<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.

--=__Part16270C21.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

20918:a3fa6d444b25 "Fix domain reference leaks" (in Feb 2010, by Jan)
does some cleanup in addition to the leak fixes.  Unfortunately, that
cleanup inadvertently resulted in an incorrect fallthrough in a switch
statement which breaks tmem save/restore.

That broken patch was apparently applied to 4.0-testing and 4.1-testing
so those are broken as well.

What is the process now for requesting back-patches to 4.0 and 4.1?

(Side note: This does not by itself entirely fix save/restore in 4.2.)

Signed-off-by: Dan Magenheimer <dan.magenheimer@oracle.com>
Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/common/tmem.c
+++ b/xen/common/tmem.c
@@ -2415,6 +2415,7 @@ static NOINLINE int tmemc_save_subop(int
              break;
         tmh_copy_to_client_buf(buf, pool->uuid, 2);
         rc =3D 0;
+        break;
     case TMEMC_SAVE_END:
         if ( client =3D=3D NULL )
             break;
@@ -2425,6 +2426,7 @@ static NOINLINE int tmemc_save_subop(int
                 pgp_free_from_inv_list(client,pgp);
         client->frozen =3D client->was_frozen;
         rc =3D 0;
+        break;
     }
     return rc;
 }




--=__Part16270C21.0__=
Content-Type: application/octet-stream; name="tmem-missing-break"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="tmem-missing-break"

dG1lbTogZml4dXAgMjAxMCBjbGVhbnVwIHBhdGNoIHRoYXQgYnJlYWtzIHRtZW0gc2F2ZS9yZXN0
b3JlCgoyMDkxODphM2ZhNmQ0NDRiMjUgIkZpeCBkb21haW4gcmVmZXJlbmNlIGxlYWtzIiAoaW4g
RmViIDIwMTAsIGJ5IEphbikKZG9lcyBzb21lIGNsZWFudXAgaW4gYWRkaXRpb24gdG8gdGhlIGxl
YWsgZml4ZXMuICBVbmZvcnR1bmF0ZWx5LCB0aGF0CmNsZWFudXAgaW5hZHZlcnRlbnRseSByZXN1
bHRlZCBpbiBhbiBpbmNvcnJlY3QgZmFsbHRocm91Z2ggaW4gYSBzd2l0Y2gKc3RhdGVtZW50IHdo
aWNoIGJyZWFrcyB0bWVtIHNhdmUvcmVzdG9yZS4KClRoYXQgYnJva2VuIHBhdGNoIHdhcyBhcHBh
cmVudGx5IGFwcGxpZWQgdG8gNC4wLXRlc3RpbmcgYW5kIDQuMS10ZXN0aW5nCnNvIHRob3NlIGFy
ZSBicm9rZW4gYXMgd2VsbC4KCldoYXQgaXMgdGhlIHByb2Nlc3Mgbm93IGZvciByZXF1ZXN0aW5n
IGJhY2stcGF0Y2hlcyB0byA0LjAgYW5kIDQuMT8KCihTaWRlIG5vdGU6IFRoaXMgZG9lcyBub3Qg
YnkgaXRzZWxmIGVudGlyZWx5IGZpeCBzYXZlL3Jlc3RvcmUgaW4gNC4yLikKClNpZ25lZC1vZmYt
Ynk6IERhbiBNYWdlbmhlaW1lciA8ZGFuLm1hZ2VuaGVpbWVyQG9yYWNsZS5jb20+ClNpZ25lZC1v
ZmYtYnk6IEphbiBCZXVsaWNoIDxqYmV1bGljaEBzdXNlLmNvbT4KCi0tLSBhL3hlbi9jb21tb24v
dG1lbS5jCisrKyBiL3hlbi9jb21tb24vdG1lbS5jCkBAIC0yNDE1LDYgKzI0MTUsNyBAQCBzdGF0
aWMgTk9JTkxJTkUgaW50IHRtZW1jX3NhdmVfc3Vib3AoaW50CiAgICAgICAgICAgICAgYnJlYWs7
CiAgICAgICAgIHRtaF9jb3B5X3RvX2NsaWVudF9idWYoYnVmLCBwb29sLT51dWlkLCAyKTsKICAg
ICAgICAgcmMgPSAwOworICAgICAgICBicmVhazsKICAgICBjYXNlIFRNRU1DX1NBVkVfRU5EOgog
ICAgICAgICBpZiAoIGNsaWVudCA9PSBOVUxMICkKICAgICAgICAgICAgIGJyZWFrOwpAQCAtMjQy
NSw2ICsyNDI2LDcgQEAgc3RhdGljIE5PSU5MSU5FIGludCB0bWVtY19zYXZlX3N1Ym9wKGludAog
ICAgICAgICAgICAgICAgIHBncF9mcmVlX2Zyb21faW52X2xpc3QoY2xpZW50LHBncCk7CiAgICAg
ICAgIGNsaWVudC0+ZnJvemVuID0gY2xpZW50LT53YXNfZnJvemVuOwogICAgICAgICByYyA9IDA7
CisgICAgICAgIGJyZWFrOwogICAgIH0KICAgICByZXR1cm4gcmM7CiB9Cg==

--=__Part16270C21.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

--=__Part16270C21.0__=--


From xen-devel-bounces@lists.xen.org Wed Sep 05 12:40:29 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Sep 2012 12:40:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9Eu6-0006Dy-JW; Wed, 05 Sep 2012 12:40:22 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1T9Eu5-0006DU-2f
	for xen-devel@lists.xen.org; Wed, 05 Sep 2012 12:40:21 +0000
Received: from [85.158.143.99:62808] by server-2.bemta-4.messagelabs.com id
	EE/1C-21239-33847405; Wed, 05 Sep 2012 12:40:19 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1346848814!23427796!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQwMzE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21830 invoked from network); 5 Sep 2012 12:40:14 -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;
	5 Sep 2012 12:40:14 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 05 Sep 2012 13:40:14 +0100
Message-Id: <504764820200007800098E55@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 05 Sep 2012 13:41:06 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part45745F72.0__="
Cc: dan.magenheimer@oracle.com, Zhenzhong Duan <zhenzhong.duan@oracle.com>
Subject: [Xen-devel] [PATCH 11/11] tmem: 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>
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.

--=__Part45745F72.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

- one more case of checking for a specific rather than any error
- drop no longer needed first parameter from cli_put_page()
- drop a redundant cast

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

--- a/xen/common/tmem.c
+++ b/xen/common/tmem.c
@@ -1467,7 +1467,7 @@ static NOINLINE int do_tmem_put_compress
         pgp_free_data(pgp, pgp->us.obj->pool);
     START_CYC_COUNTER(compress);
     ret =3D tmh_compress_from_client(cmfn, &dst, &size, clibuf);
-    if ( (ret =3D=3D -EFAULT) || (ret =3D=3D 0) )
+    if ( ret <=3D 0 )
         goto out;
     else if ( (size =3D=3D 0) || (size >=3D tmem_subpage_maxsize()) ) {
         ret =3D 0;
--- a/xen/common/tmem_xen.c
+++ b/xen/common/tmem_xen.c
@@ -97,7 +97,7 @@ static inline void *cli_get_page(tmem_cl
     return NULL;
 }
=20
-static inline void cli_put_page(tmem_cli_mfn_t cmfn, void *cli_va, pfp_t =
*cli_pfp,
+static inline void cli_put_page(void *cli_va, pfp_t *cli_pfp,
                                 unsigned long cli_mfn, bool_t mark_dirty)
 {
     ASSERT(0);
@@ -126,20 +126,20 @@ static inline void *cli_get_page(tmem_cl
     }
=20
     *pcli_mfn =3D page_to_mfn(page);
-    *pcli_pfp =3D (pfp_t *)page;
+    *pcli_pfp =3D page;
     return map_domain_page(*pcli_mfn);
 }
=20
-static inline void cli_put_page(tmem_cli_mfn_t cmfn, void *cli_va, pfp_t =
*cli_pfp,
+static inline void cli_put_page(void *cli_va, pfp_t *cli_pfp,
                                 unsigned long cli_mfn, bool_t mark_dirty)
 {
     if ( mark_dirty )
     {
-        put_page_and_type((struct page_info *)cli_pfp);
+        put_page_and_type(cli_pfp);
         paging_mark_dirty(current->domain,cli_mfn);
     }
     else
-        put_page((struct page_info *)cli_pfp);
+        put_page(cli_pfp);
     unmap_domain_page(cli_va);
 }
 #endif
@@ -188,7 +188,7 @@ EXPORT int tmh_copy_from_client(pfp_t *p
     else if ( len )
         rc =3D -EINVAL;
     if ( cli_va )
-        cli_put_page(cmfn, cli_va, cli_pfp, cli_mfn, 0);
+        cli_put_page(cli_va, cli_pfp, cli_mfn, 0);
     unmap_domain_page(tmem_va);
     return rc;
 }
@@ -221,7 +221,7 @@ EXPORT int tmh_compress_from_client(tmem
     ASSERT(ret =3D=3D LZO_E_OK);
     *out_va =3D dmem;
     if ( cli_va )
-        cli_put_page(cmfn, cli_va, cli_pfp, cli_mfn, 0);
+        cli_put_page(cli_va, cli_pfp, cli_mfn, 0);
     return 1;
 }
=20
@@ -259,7 +259,7 @@ EXPORT int tmh_copy_to_client(tmem_cli_m
         rc =3D -EINVAL;
     unmap_domain_page(tmem_va);
     if ( cli_va )
-        cli_put_page(cmfn, cli_va, cli_pfp, cli_mfn, 1);
+        cli_put_page(cli_va, cli_pfp, cli_mfn, 1);
     mb();
     return rc;
 }
@@ -286,7 +286,7 @@ EXPORT int tmh_decompress_to_client(tmem
     ASSERT(ret =3D=3D LZO_E_OK);
     ASSERT(out_len =3D=3D PAGE_SIZE);
     if ( cli_va )
-        cli_put_page(cmfn, cli_va, cli_pfp, cli_mfn, 1);
+        cli_put_page(cli_va, cli_pfp, cli_mfn, 1);
     else if ( copy_to_guest(clibuf, scratch, PAGE_SIZE) )
         return -EFAULT;
     mb();
@@ -310,7 +310,7 @@ EXPORT int tmh_copy_tze_to_client(tmem_c
         memcpy((char *)cli_va,(char *)tmem_va,len);
     if ( len < PAGE_SIZE )
         memset((char *)cli_va+len,0,PAGE_SIZE-len);
-    cli_put_page(cmfn, cli_va, cli_pfp, cli_mfn, 1);
+    cli_put_page(cli_va, cli_pfp, cli_mfn, 1);
     mb();
     return 1;
 }




--=__Part45745F72.0__=
Content-Type: text/plain; name="tmem-cleanup.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="tmem-cleanup.patch"

tmem: cleanup=0A=0A- one more case of checking for a specific rather than =
any error=0A- drop no longer needed first parameter from cli_put_page()=0A-=
 drop a redundant cast=0A=0ASigned-off-by: Jan Beulich <jbeulich@suse.com>=
=0A=0A--- a/xen/common/tmem.c=0A+++ b/xen/common/tmem.c=0A@@ -1467,7 =
+1467,7 @@ static NOINLINE int do_tmem_put_compress=0A         pgp_free_dat=
a(pgp, pgp->us.obj->pool);=0A     START_CYC_COUNTER(compress);=0A     ret =
=3D tmh_compress_from_client(cmfn, &dst, &size, clibuf);=0A-    if ( (ret =
=3D=3D -EFAULT) || (ret =3D=3D 0) )=0A+    if ( ret <=3D 0 )=0A         =
goto out;=0A     else if ( (size =3D=3D 0) || (size >=3D tmem_subpage_maxsi=
ze()) ) {=0A         ret =3D 0;=0A--- a/xen/common/tmem_xen.c=0A+++ =
b/xen/common/tmem_xen.c=0A@@ -97,7 +97,7 @@ static inline void *cli_get_pag=
e(tmem_cl=0A     return NULL;=0A }=0A =0A-static inline void cli_put_page(t=
mem_cli_mfn_t cmfn, void *cli_va, pfp_t *cli_pfp,=0A+static inline void =
cli_put_page(void *cli_va, pfp_t *cli_pfp,=0A                              =
   unsigned long cli_mfn, bool_t mark_dirty)=0A {=0A     ASSERT(0);=0A@@ =
-126,20 +126,20 @@ static inline void *cli_get_page(tmem_cl=0A     }=0A =
=0A     *pcli_mfn =3D page_to_mfn(page);=0A-    *pcli_pfp =3D (pfp_t =
*)page;=0A+    *pcli_pfp =3D page;=0A     return map_domain_page(*pcli_mfn)=
;=0A }=0A =0A-static inline void cli_put_page(tmem_cli_mfn_t cmfn, void =
*cli_va, pfp_t *cli_pfp,=0A+static inline void cli_put_page(void *cli_va, =
pfp_t *cli_pfp,=0A                                 unsigned long cli_mfn, =
bool_t mark_dirty)=0A {=0A     if ( mark_dirty )=0A     {=0A-        =
put_page_and_type((struct page_info *)cli_pfp);=0A+        put_page_and_typ=
e(cli_pfp);=0A         paging_mark_dirty(current->domain,cli_mfn);=0A     =
}=0A     else=0A-        put_page((struct page_info *)cli_pfp);=0A+        =
put_page(cli_pfp);=0A     unmap_domain_page(cli_va);=0A }=0A #endif=0A@@ =
-188,7 +188,7 @@ EXPORT int tmh_copy_from_client(pfp_t *p=0A     else if ( =
len )=0A         rc =3D -EINVAL;=0A     if ( cli_va )=0A-        cli_put_pa=
ge(cmfn, cli_va, cli_pfp, cli_mfn, 0);=0A+        cli_put_page(cli_va, =
cli_pfp, cli_mfn, 0);=0A     unmap_domain_page(tmem_va);=0A     return =
rc;=0A }=0A@@ -221,7 +221,7 @@ EXPORT int tmh_compress_from_client(tmem=0A =
    ASSERT(ret =3D=3D LZO_E_OK);=0A     *out_va =3D dmem;=0A     if ( =
cli_va )=0A-        cli_put_page(cmfn, cli_va, cli_pfp, cli_mfn, 0);=0A+   =
     cli_put_page(cli_va, cli_pfp, cli_mfn, 0);=0A     return 1;=0A }=0A =
=0A@@ -259,7 +259,7 @@ EXPORT int tmh_copy_to_client(tmem_cli_m=0A         =
rc =3D -EINVAL;=0A     unmap_domain_page(tmem_va);=0A     if ( cli_va =
)=0A-        cli_put_page(cmfn, cli_va, cli_pfp, cli_mfn, 1);=0A+        =
cli_put_page(cli_va, cli_pfp, cli_mfn, 1);=0A     mb();=0A     return =
rc;=0A }=0A@@ -286,7 +286,7 @@ EXPORT int tmh_decompress_to_client(tmem=0A =
    ASSERT(ret =3D=3D LZO_E_OK);=0A     ASSERT(out_len =3D=3D PAGE_SIZE);=
=0A     if ( cli_va )=0A-        cli_put_page(cmfn, cli_va, cli_pfp, =
cli_mfn, 1);=0A+        cli_put_page(cli_va, cli_pfp, cli_mfn, 1);=0A     =
else if ( copy_to_guest(clibuf, scratch, PAGE_SIZE) )=0A         return =
-EFAULT;=0A     mb();=0A@@ -310,7 +310,7 @@ EXPORT int tmh_copy_tze_to_clie=
nt(tmem_c=0A         memcpy((char *)cli_va,(char *)tmem_va,len);=0A     if =
( len < PAGE_SIZE )=0A         memset((char *)cli_va+len,0,PAGE_SIZE-len);=
=0A-    cli_put_page(cmfn, cli_va, cli_pfp, cli_mfn, 1);=0A+    cli_put_pag=
e(cli_va, cli_pfp, cli_mfn, 1);=0A     mb();=0A     return 1;=0A }=0A
--=__Part45745F72.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

--=__Part45745F72.0__=--


From xen-devel-bounces@lists.xen.org Wed Sep 05 12:40:29 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Sep 2012 12:40:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9Eu6-0006Dy-JW; Wed, 05 Sep 2012 12:40:22 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1T9Eu5-0006DU-2f
	for xen-devel@lists.xen.org; Wed, 05 Sep 2012 12:40:21 +0000
Received: from [85.158.143.99:62808] by server-2.bemta-4.messagelabs.com id
	EE/1C-21239-33847405; Wed, 05 Sep 2012 12:40:19 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1346848814!23427796!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQwMzE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21830 invoked from network); 5 Sep 2012 12:40:14 -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;
	5 Sep 2012 12:40:14 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 05 Sep 2012 13:40:14 +0100
Message-Id: <504764820200007800098E55@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 05 Sep 2012 13:41:06 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part45745F72.0__="
Cc: dan.magenheimer@oracle.com, Zhenzhong Duan <zhenzhong.duan@oracle.com>
Subject: [Xen-devel] [PATCH 11/11] tmem: 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>
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.

--=__Part45745F72.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

- one more case of checking for a specific rather than any error
- drop no longer needed first parameter from cli_put_page()
- drop a redundant cast

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

--- a/xen/common/tmem.c
+++ b/xen/common/tmem.c
@@ -1467,7 +1467,7 @@ static NOINLINE int do_tmem_put_compress
         pgp_free_data(pgp, pgp->us.obj->pool);
     START_CYC_COUNTER(compress);
     ret =3D tmh_compress_from_client(cmfn, &dst, &size, clibuf);
-    if ( (ret =3D=3D -EFAULT) || (ret =3D=3D 0) )
+    if ( ret <=3D 0 )
         goto out;
     else if ( (size =3D=3D 0) || (size >=3D tmem_subpage_maxsize()) ) {
         ret =3D 0;
--- a/xen/common/tmem_xen.c
+++ b/xen/common/tmem_xen.c
@@ -97,7 +97,7 @@ static inline void *cli_get_page(tmem_cl
     return NULL;
 }
=20
-static inline void cli_put_page(tmem_cli_mfn_t cmfn, void *cli_va, pfp_t =
*cli_pfp,
+static inline void cli_put_page(void *cli_va, pfp_t *cli_pfp,
                                 unsigned long cli_mfn, bool_t mark_dirty)
 {
     ASSERT(0);
@@ -126,20 +126,20 @@ static inline void *cli_get_page(tmem_cl
     }
=20
     *pcli_mfn =3D page_to_mfn(page);
-    *pcli_pfp =3D (pfp_t *)page;
+    *pcli_pfp =3D page;
     return map_domain_page(*pcli_mfn);
 }
=20
-static inline void cli_put_page(tmem_cli_mfn_t cmfn, void *cli_va, pfp_t =
*cli_pfp,
+static inline void cli_put_page(void *cli_va, pfp_t *cli_pfp,
                                 unsigned long cli_mfn, bool_t mark_dirty)
 {
     if ( mark_dirty )
     {
-        put_page_and_type((struct page_info *)cli_pfp);
+        put_page_and_type(cli_pfp);
         paging_mark_dirty(current->domain,cli_mfn);
     }
     else
-        put_page((struct page_info *)cli_pfp);
+        put_page(cli_pfp);
     unmap_domain_page(cli_va);
 }
 #endif
@@ -188,7 +188,7 @@ EXPORT int tmh_copy_from_client(pfp_t *p
     else if ( len )
         rc =3D -EINVAL;
     if ( cli_va )
-        cli_put_page(cmfn, cli_va, cli_pfp, cli_mfn, 0);
+        cli_put_page(cli_va, cli_pfp, cli_mfn, 0);
     unmap_domain_page(tmem_va);
     return rc;
 }
@@ -221,7 +221,7 @@ EXPORT int tmh_compress_from_client(tmem
     ASSERT(ret =3D=3D LZO_E_OK);
     *out_va =3D dmem;
     if ( cli_va )
-        cli_put_page(cmfn, cli_va, cli_pfp, cli_mfn, 0);
+        cli_put_page(cli_va, cli_pfp, cli_mfn, 0);
     return 1;
 }
=20
@@ -259,7 +259,7 @@ EXPORT int tmh_copy_to_client(tmem_cli_m
         rc =3D -EINVAL;
     unmap_domain_page(tmem_va);
     if ( cli_va )
-        cli_put_page(cmfn, cli_va, cli_pfp, cli_mfn, 1);
+        cli_put_page(cli_va, cli_pfp, cli_mfn, 1);
     mb();
     return rc;
 }
@@ -286,7 +286,7 @@ EXPORT int tmh_decompress_to_client(tmem
     ASSERT(ret =3D=3D LZO_E_OK);
     ASSERT(out_len =3D=3D PAGE_SIZE);
     if ( cli_va )
-        cli_put_page(cmfn, cli_va, cli_pfp, cli_mfn, 1);
+        cli_put_page(cli_va, cli_pfp, cli_mfn, 1);
     else if ( copy_to_guest(clibuf, scratch, PAGE_SIZE) )
         return -EFAULT;
     mb();
@@ -310,7 +310,7 @@ EXPORT int tmh_copy_tze_to_client(tmem_c
         memcpy((char *)cli_va,(char *)tmem_va,len);
     if ( len < PAGE_SIZE )
         memset((char *)cli_va+len,0,PAGE_SIZE-len);
-    cli_put_page(cmfn, cli_va, cli_pfp, cli_mfn, 1);
+    cli_put_page(cli_va, cli_pfp, cli_mfn, 1);
     mb();
     return 1;
 }




--=__Part45745F72.0__=
Content-Type: text/plain; name="tmem-cleanup.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="tmem-cleanup.patch"

tmem: cleanup=0A=0A- one more case of checking for a specific rather than =
any error=0A- drop no longer needed first parameter from cli_put_page()=0A-=
 drop a redundant cast=0A=0ASigned-off-by: Jan Beulich <jbeulich@suse.com>=
=0A=0A--- a/xen/common/tmem.c=0A+++ b/xen/common/tmem.c=0A@@ -1467,7 =
+1467,7 @@ static NOINLINE int do_tmem_put_compress=0A         pgp_free_dat=
a(pgp, pgp->us.obj->pool);=0A     START_CYC_COUNTER(compress);=0A     ret =
=3D tmh_compress_from_client(cmfn, &dst, &size, clibuf);=0A-    if ( (ret =
=3D=3D -EFAULT) || (ret =3D=3D 0) )=0A+    if ( ret <=3D 0 )=0A         =
goto out;=0A     else if ( (size =3D=3D 0) || (size >=3D tmem_subpage_maxsi=
ze()) ) {=0A         ret =3D 0;=0A--- a/xen/common/tmem_xen.c=0A+++ =
b/xen/common/tmem_xen.c=0A@@ -97,7 +97,7 @@ static inline void *cli_get_pag=
e(tmem_cl=0A     return NULL;=0A }=0A =0A-static inline void cli_put_page(t=
mem_cli_mfn_t cmfn, void *cli_va, pfp_t *cli_pfp,=0A+static inline void =
cli_put_page(void *cli_va, pfp_t *cli_pfp,=0A                              =
   unsigned long cli_mfn, bool_t mark_dirty)=0A {=0A     ASSERT(0);=0A@@ =
-126,20 +126,20 @@ static inline void *cli_get_page(tmem_cl=0A     }=0A =
=0A     *pcli_mfn =3D page_to_mfn(page);=0A-    *pcli_pfp =3D (pfp_t =
*)page;=0A+    *pcli_pfp =3D page;=0A     return map_domain_page(*pcli_mfn)=
;=0A }=0A =0A-static inline void cli_put_page(tmem_cli_mfn_t cmfn, void =
*cli_va, pfp_t *cli_pfp,=0A+static inline void cli_put_page(void *cli_va, =
pfp_t *cli_pfp,=0A                                 unsigned long cli_mfn, =
bool_t mark_dirty)=0A {=0A     if ( mark_dirty )=0A     {=0A-        =
put_page_and_type((struct page_info *)cli_pfp);=0A+        put_page_and_typ=
e(cli_pfp);=0A         paging_mark_dirty(current->domain,cli_mfn);=0A     =
}=0A     else=0A-        put_page((struct page_info *)cli_pfp);=0A+        =
put_page(cli_pfp);=0A     unmap_domain_page(cli_va);=0A }=0A #endif=0A@@ =
-188,7 +188,7 @@ EXPORT int tmh_copy_from_client(pfp_t *p=0A     else if ( =
len )=0A         rc =3D -EINVAL;=0A     if ( cli_va )=0A-        cli_put_pa=
ge(cmfn, cli_va, cli_pfp, cli_mfn, 0);=0A+        cli_put_page(cli_va, =
cli_pfp, cli_mfn, 0);=0A     unmap_domain_page(tmem_va);=0A     return =
rc;=0A }=0A@@ -221,7 +221,7 @@ EXPORT int tmh_compress_from_client(tmem=0A =
    ASSERT(ret =3D=3D LZO_E_OK);=0A     *out_va =3D dmem;=0A     if ( =
cli_va )=0A-        cli_put_page(cmfn, cli_va, cli_pfp, cli_mfn, 0);=0A+   =
     cli_put_page(cli_va, cli_pfp, cli_mfn, 0);=0A     return 1;=0A }=0A =
=0A@@ -259,7 +259,7 @@ EXPORT int tmh_copy_to_client(tmem_cli_m=0A         =
rc =3D -EINVAL;=0A     unmap_domain_page(tmem_va);=0A     if ( cli_va =
)=0A-        cli_put_page(cmfn, cli_va, cli_pfp, cli_mfn, 1);=0A+        =
cli_put_page(cli_va, cli_pfp, cli_mfn, 1);=0A     mb();=0A     return =
rc;=0A }=0A@@ -286,7 +286,7 @@ EXPORT int tmh_decompress_to_client(tmem=0A =
    ASSERT(ret =3D=3D LZO_E_OK);=0A     ASSERT(out_len =3D=3D PAGE_SIZE);=
=0A     if ( cli_va )=0A-        cli_put_page(cmfn, cli_va, cli_pfp, =
cli_mfn, 1);=0A+        cli_put_page(cli_va, cli_pfp, cli_mfn, 1);=0A     =
else if ( copy_to_guest(clibuf, scratch, PAGE_SIZE) )=0A         return =
-EFAULT;=0A     mb();=0A@@ -310,7 +310,7 @@ EXPORT int tmh_copy_tze_to_clie=
nt(tmem_c=0A         memcpy((char *)cli_va,(char *)tmem_va,len);=0A     if =
( len < PAGE_SIZE )=0A         memset((char *)cli_va+len,0,PAGE_SIZE-len);=
=0A-    cli_put_page(cmfn, cli_va, cli_pfp, cli_mfn, 1);=0A+    cli_put_pag=
e(cli_va, cli_pfp, cli_mfn, 1);=0A     mb();=0A     return 1;=0A }=0A
--=__Part45745F72.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

--=__Part45745F72.0__=--


From xen-devel-bounces@lists.xen.org Wed Sep 05 12:43:21 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Sep 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 1T9Ews-0006fp-Ew; Wed, 05 Sep 2012 12:43: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 1T9Ewq-0006fX-T7
	for xen-devel@lists.xen.org; Wed, 05 Sep 2012 12:43:12 +0000
Received: from [85.158.143.99:38296] by server-2.bemta-4.messagelabs.com id
	22/D1-21239-0E847405; Wed, 05 Sep 2012 12:43:12 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1346848989!23342257!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQwMzE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7755 invoked from network); 5 Sep 2012 12:43:09 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-2.tower-216.messagelabs.com with SMTP;
	5 Sep 2012 12:43:09 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 05 Sep 2012 13:43:09 +0100
Message-Id: <504765310200007800098E5A@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 05 Sep 2012 13:44:01 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Andrew Cooper" <andrew.cooper3@citrix.com>
References: <504760B20200007800098D6C@nat28.tlf.novell.com>
	<5047473E.1020701@citrix.com>
In-Reply-To: <5047473E.1020701@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 1/2] x86: drop "index" parameter from
 get_free_pirq()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.09.12 at 14:36, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
> On 05/09/12 13:24, Jan Beulich wrote:
>> @@ -71,7 +71,7 @@ static int physdev_hvm_map_pirq(
>>          else
>>          {
>>              if ( *pirq < 0 )
>> -                *pirq = get_free_pirq(d, type, *index);
>> +                *pirq = get_free_pirq(d, type);
>>              ret = map_domain_emuirq_pirq(d, *pirq, *index);
> 
> 
> Relatedly (and I had already noticed this but not got round to making a
> patch because of other more urgent bugs)
> 
> You still have a chance here of passing an error into
> map_domain_emuirq_pirq, in the pirq value.  This is not a security issue
> as map_domain_emuirq_pirq does range check pirq, but may turn into a
> problem if the implementation of map_domain_emuirq_pirq changes.  I
> would say that for correctness sake, physdev_hvm_map_pirq() should range
> check get_free_pirq(), even if this will lead to a double range check of
> the value.

Yes, that would be more clean.

Jan


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

From xen-devel-bounces@lists.xen.org Wed Sep 05 12:43:21 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Sep 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 1T9Ews-0006fp-Ew; Wed, 05 Sep 2012 12:43: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 1T9Ewq-0006fX-T7
	for xen-devel@lists.xen.org; Wed, 05 Sep 2012 12:43:12 +0000
Received: from [85.158.143.99:38296] by server-2.bemta-4.messagelabs.com id
	22/D1-21239-0E847405; Wed, 05 Sep 2012 12:43:12 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1346848989!23342257!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQwMzE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7755 invoked from network); 5 Sep 2012 12:43:09 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-2.tower-216.messagelabs.com with SMTP;
	5 Sep 2012 12:43:09 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 05 Sep 2012 13:43:09 +0100
Message-Id: <504765310200007800098E5A@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 05 Sep 2012 13:44:01 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Andrew Cooper" <andrew.cooper3@citrix.com>
References: <504760B20200007800098D6C@nat28.tlf.novell.com>
	<5047473E.1020701@citrix.com>
In-Reply-To: <5047473E.1020701@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 1/2] x86: drop "index" parameter from
 get_free_pirq()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.09.12 at 14:36, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
> On 05/09/12 13:24, Jan Beulich wrote:
>> @@ -71,7 +71,7 @@ static int physdev_hvm_map_pirq(
>>          else
>>          {
>>              if ( *pirq < 0 )
>> -                *pirq = get_free_pirq(d, type, *index);
>> +                *pirq = get_free_pirq(d, type);
>>              ret = map_domain_emuirq_pirq(d, *pirq, *index);
> 
> 
> Relatedly (and I had already noticed this but not got round to making a
> patch because of other more urgent bugs)
> 
> You still have a chance here of passing an error into
> map_domain_emuirq_pirq, in the pirq value.  This is not a security issue
> as map_domain_emuirq_pirq does range check pirq, but may turn into a
> problem if the implementation of map_domain_emuirq_pirq changes.  I
> would say that for correctness sake, physdev_hvm_map_pirq() should range
> check get_free_pirq(), even if this will lead to a double range check of
> the value.

Yes, that would be more clean.

Jan


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

From xen-devel-bounces@lists.xen.org Wed Sep 05 12:44:45 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Sep 2012 12: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 1T9EyC-0006oz-Ua; Wed, 05 Sep 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 1T9EyA-0006oe-Tf
	for xen-devel@lists.xen.org; Wed, 05 Sep 2012 12:44:35 +0000
Received: from [85.158.143.99:56982] by server-2.bemta-4.messagelabs.com id
	94/84-21239-23947405; Wed, 05 Sep 2012 12:44:34 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1346849073!23428940!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQwMzE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11322 invoked from network); 5 Sep 2012 12:44:33 -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;
	5 Sep 2012 12:44:33 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 05 Sep 2012 13:44:34 +0100
Message-Id: <504765830200007800098E5D@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 05 Sep 2012 13:45:23 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Keir Fraser" <keir.xen@gmail.com>, "xen-devel" <xen-devel@lists.xen.org>
References: <504760D00200007800098D70@nat28.tlf.novell.com>
	<CC6D0525.3DCAE%keir.xen@gmail.com>
In-Reply-To: <CC6D0525.3DCAE%keir.xen@gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
Subject: Re: [Xen-devel] [PATCH 2/2] x86: fix RCU locking in
 PHYSDEVOP_get_free_pirq
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.09.12 at 14:33, Keir Fraser <keir.xen@gmail.com> wrote:
> On 05/09/2012 13:25, "Jan Beulich" <JBeulich@suse.com> wrote:
> 
>> Apart from properly pairing locks with unlocks, also reduce the lock
>> scope - no need to do the copy_{from,to}_guest()-s inside the protected
>> region.
>> 
>> I actually wonder whether the RCU locks are needed here at all.
> 
> If it's a path that only acts on current domain, then no.

So for what case does rcu_lock_current_domain() then exist 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 Sep 05 12:44:45 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Sep 2012 12: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 1T9EyC-0006oz-Ua; Wed, 05 Sep 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 1T9EyA-0006oe-Tf
	for xen-devel@lists.xen.org; Wed, 05 Sep 2012 12:44:35 +0000
Received: from [85.158.143.99:56982] by server-2.bemta-4.messagelabs.com id
	94/84-21239-23947405; Wed, 05 Sep 2012 12:44:34 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1346849073!23428940!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQwMzE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11322 invoked from network); 5 Sep 2012 12:44:33 -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;
	5 Sep 2012 12:44:33 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 05 Sep 2012 13:44:34 +0100
Message-Id: <504765830200007800098E5D@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 05 Sep 2012 13:45:23 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Keir Fraser" <keir.xen@gmail.com>, "xen-devel" <xen-devel@lists.xen.org>
References: <504760D00200007800098D70@nat28.tlf.novell.com>
	<CC6D0525.3DCAE%keir.xen@gmail.com>
In-Reply-To: <CC6D0525.3DCAE%keir.xen@gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
Subject: Re: [Xen-devel] [PATCH 2/2] x86: fix RCU locking in
 PHYSDEVOP_get_free_pirq
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.09.12 at 14:33, Keir Fraser <keir.xen@gmail.com> wrote:
> On 05/09/2012 13:25, "Jan Beulich" <JBeulich@suse.com> wrote:
> 
>> Apart from properly pairing locks with unlocks, also reduce the lock
>> scope - no need to do the copy_{from,to}_guest()-s inside the protected
>> region.
>> 
>> I actually wonder whether the RCU locks are needed here at all.
> 
> If it's a path that only acts on current domain, then no.

So for what case does rcu_lock_current_domain() then exist 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 Sep 05 12:47:50 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Sep 2012 12:47:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9F1C-00074m-71; Wed, 05 Sep 2012 12:47:42 +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 1T9F1A-00074P-J8
	for xen-devel@lists.xen.org; Wed, 05 Sep 2012 12:47:40 +0000
Received: from [85.158.143.35:51371] by server-3.bemta-4.messagelabs.com id
	6E/1B-08232-BE947405; Wed, 05 Sep 2012 12:47:39 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1346849246!13498778!1
X-Originating-IP: [213.199.154.205]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5096 invoked from network); 5 Sep 2012 12:47:26 -0000
Received: from am1ehsobe002.messaging.microsoft.com (HELO
	am1outboundpool.messaging.microsoft.com) (213.199.154.205)
	by server-8.tower-21.messagelabs.com with AES128-SHA encrypted SMTP;
	5 Sep 2012 12:47:26 -0000
Received: from mail115-am1-R.bigfish.com (10.3.201.245) by
	AM1EHSOBE008.bigfish.com (10.3.204.28) with Microsoft SMTP Server id
	14.1.225.23; Wed, 5 Sep 2012 12:47:26 +0000
Received: from mail115-am1 (localhost [127.0.0.1])	by
	mail115-am1-R.bigfish.com (Postfix) with ESMTP id 5A3251A0084;
	Wed,  5 Sep 2012 12:47: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: -5
X-BigFish: VPS-5(zzbb2dI98dI9371Ic89bh1432I4015Izz1202hzzz2dh668h839hd25he5bhf0ah107ah1155h)
Received: from mail115-am1 (localhost.localdomain [127.0.0.1]) by mail115-am1
	(MessageSwitch) id 1346849244373150_18965;
	Wed,  5 Sep 2012 12:47:24 +0000 (UTC)
Received: from AM1EHSMHS004.bigfish.com (unknown [10.3.201.227])	by
	mail115-am1.bigfish.com (Postfix) with ESMTP id 4E7B0180047;
	Wed,  5 Sep 2012 12:47:24 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	AM1EHSMHS004.bigfish.com (10.3.207.104) with Microsoft SMTP Server id
	14.1.225.23; Wed, 5 Sep 2012 12:47:22 +0000
X-WSS-ID: 0M9VNIS-02-3CN-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 20879C8119;	Wed,  5 Sep 2012 07:47:15 -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;
	Wed, 5 Sep 2012 07:47:31 -0500
Received: from storexhtp01.amd.com (172.24.4.3) by sausexdag04.amd.com
	(163.181.55.4) with Microsoft SMTP Server (TLS) id 14.1.323.3;
	Wed, 5 Sep 2012 07:47:11 -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, 5 Sep 2012
	08:47:09 -0400
Received: from [165.204.15.57] (gran.osrc.amd.com [165.204.15.57])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id C764B49C0D5; Wed,  5 Sep 2012
	13:47:08 +0100 (BST)
Message-ID: <50474A11.6050601@amd.com>
Date: Wed, 5 Sep 2012 14:48:17 +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: Sander Eikelenboom <linux@eikelenboom.it>
References: <40501859.20120902104331@eikelenboom.it>
	<CC6932C2.3D99D%keir.xen@gmail.com>
	<217459398.20120902171441@eikelenboom.it>
	<5044CAD7.8030800@amd.com>
	<1144695277.20120904184345@eikelenboom.it>
	<5047420A0200007800098BB1@nat28.tlf.novell.com>
	<348297741.20120905122542@eikelenboom.it>
In-Reply-To: <348297741.20120905122542@eikelenboom.it>
X-OriginatorOrg: amd.com
Cc: Keir Fraser <keir.xen@gmail.com>, Santosh Jodh <Santosh.Jodh@citrix.com>,
	Jan Beulich <JBeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Using debug-key 'o:  Dump IOMMU p2m table,
 locks up machine
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="iso-8859-15"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

OK, I got your lspci info, please find my answer inline.

On 09/05/2012 12:25 PM, Sander Eikelenboom wrote:

>
> 00:00.0 Host bridge: ATI Technologies Inc RD890 Northbridge only single s=
lot PCI-e GFX Hydra part (rev 02)
> 00:00.2 Generic system peripheral [0806]: ATI Technologies Inc RD990 I/O =
Memory Management Unit (IOMMU)
> 00:02.0 PCI bridge: ATI Technologies Inc RD890 PCI to PCI bridge (PCI exp=
ress gpp port B)
> 00:03.0 PCI bridge: ATI Technologies Inc RD890 PCI to PCI bridge (PCI exp=
ress gpp port C)
> 00:05.0 PCI bridge: ATI Technologies Inc RD890 PCI to PCI bridge (PCI exp=
ress gpp port E)
> 00:06.0 PCI bridge: ATI Technologies Inc RD890 PCI to PCI bridge (PCI exp=
ress gpp port F)
> 00:0a.0 PCI bridge: ATI Technologies Inc RD890 PCI to PCI bridge (externa=
l gfx1 port A)
> 00:0b.0 PCI bridge: ATI Technologies Inc RD890 PCI to PCI bridge (NB-SB l=
ink)
> 00:0c.0 PCI bridge: ATI Technologies Inc Device 5a20
> 00:0d.0 PCI bridge: ATI Technologies Inc RD890 PCI to PCI bridge (externa=
l gfx1 port B)
> 00:11.0 SATA controller: ATI Technologies Inc SB7x0/SB8x0/SB9x0 SATA Cont=
roller [AHCI mode] (rev 40)
> 00:12.0 USB controller: ATI Technologies Inc SB7x0/SB8x0/SB9x0 USB OHCI0 =
Controller
> 00:12.2 USB controller: ATI Technologies Inc SB7x0/SB8x0/SB9x0 USB EHCI C=
ontroller
> 00:13.0 USB controller: ATI Technologies Inc SB7x0/SB8x0/SB9x0 USB OHCI0 =
Controller
> 00:13.2 USB controller: ATI Technologies Inc SB7x0/SB8x0/SB9x0 USB EHCI C=
ontroller
> 00:14.0 SMBus: ATI Technologies Inc SBx00 SMBus Controller (rev 41)
> 00:14.3 ISA bridge: ATI Technologies Inc SB7x0/SB8x0/SB9x0 LPC host contr=
oller (rev 40)
> 00:14.4 PCI bridge: ATI Technologies Inc SBx00 PCI to PCI Bridge (rev 40)
> 00:14.5 USB controller: ATI Technologies Inc SB7x0/SB8x0/SB9x0 USB OHCI2 =
Controller
> 00:15.0 PCI bridge: ATI Technologies Inc SB700/SB800/SB900 PCI to PCI bri=
dge (PCIE port 0)
> 00:16.0 USB controller: ATI Technologies Inc SB7x0/SB8x0/SB9x0 USB OHCI0 =
Controller
> 00:16.2 USB controller: ATI Technologies Inc SB7x0/SB8x0/SB9x0 USB EHCI C=
ontroller
> 00:18.0 Host bridge: Advanced Micro Devices [AMD] Family 10h Processor Hy=
perTransport Configuration
> 00:18.1 Host bridge: Advanced Micro Devices [AMD] Family 10h Processor Ad=
dress Map
> 00:18.2 Host bridge: Advanced Micro Devices [AMD] Family 10h Processor DR=
AM Controller
> 00:18.3 Host bridge: Advanced Micro Devices [AMD] Family 10h Processor Mi=
scellaneous Control
> 00:18.4 Host bridge: Advanced Micro Devices [AMD] Family 10h Processor Li=
nk Control
> 03:06.0 Multimedia audio controller: C-Media Electronics Inc CM8738 (rev =
10)
> 04:00.0 USB controller: NetMos Technology MCS9990 PCIe to 4=E2Port USB 2.=
0 Host Controller
> 04:00.1 USB controller: NetMos Technology MCS9990 PCIe to 4=E2Port USB 2.=
0 Host Controller
> 04:00.2 USB controller: NetMos Technology MCS9990 PCIe to 4=E2Port USB 2.=
0 Host Controller
> 04:00.3 USB controller: NetMos Technology MCS9990 PCIe to 4=E2Port USB 2.=
0 Host Controller
> 04:00.4 USB controller: NetMos Technology MCS9990 PCIe to 4=E2Port USB 2.=
0 Host Controller
> 04:00.5 USB controller: NetMos Technology MCS9990 PCIe to 4=E2Port USB 2.=
0 Host Controller
> 04:00.6 USB controller: NetMos Technology MCS9990 PCIe to 4=E2Port USB 2.=
0 Host Controller
> 04:00.7 USB controller: NetMos Technology MCS9990 PCIe to 4=E2Port USB 2.=
0 Host Controller
> 05:00.0 Multimedia video controller: Conexant Systems, Inc. CX25850
> 06:00.0 VGA compatible controller: ATI Technologies Inc RV620 LE [Radeon =
HD 3450]
> 06:00.1 Audio device: ATI Technologies Inc RV620 Audio device [Radeon HD =
34xx Series]
> 07:00.0 Multimedia video controller: Conexant Systems, Inc. Device 8210

What kind of device is it, is it a graphic card? Is there any firmware =

running on this device? Some firmwares like vbios might have bad =

assumption of address space. And how many memory the guest has? Could =

you attach a lspci -vvv output from your guest?

Thanks,
Wei

> 08:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168=
B PCI Express Gigabit Ethernet controller (rev 03)
> 09:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168=
B PCI Express Gigabit Ethernet controller (rev 03)
> 0a:00.0 USB controller: NetMos Technology MCS9990 PCIe to 4=E2Port USB 2.=
0 Host Controller
> 0a:00.1 USB controller: NetMos Technology MCS9990 PCIe to 4=E2Port USB 2.=
0 Host Controller
> 0a:00.2 USB controller: NetMos Technology MCS9990 PCIe to 4=E2Port USB 2.=
0 Host Controller
> 0a:00.3 USB controller: NetMos Technology MCS9990 PCIe to 4=E2Port USB 2.=
0 Host Controller
> 0a:00.4 USB controller: NetMos Technology MCS9990 PCIe to 4=E2Port USB 2.=
0 Host Controller
> 0a:00.5 USB controller: NetMos Technology MCS9990 PCIe to 4=E2Port USB 2.=
0 Host Controller
> 0a:00.6 USB controller: NetMos Technology MCS9990 PCIe to 4=E2Port USB 2.=
0 Host Controller
> 0a:00.7 USB controller: NetMos Technology MCS9990 PCIe to 4=E2Port USB 2.=
0 Host Controller
> 0b:00.0 VGA compatible controller: nVidia Corporation G98 [GeForce 8400 G=
S] (rev a1)
>
>
>
>
>
>
>
>> Jan
>
>
>
>



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

From xen-devel-bounces@lists.xen.org Wed Sep 05 12:47:50 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Sep 2012 12:47:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9F1C-00074m-71; Wed, 05 Sep 2012 12:47:42 +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 1T9F1A-00074P-J8
	for xen-devel@lists.xen.org; Wed, 05 Sep 2012 12:47:40 +0000
Received: from [85.158.143.35:51371] by server-3.bemta-4.messagelabs.com id
	6E/1B-08232-BE947405; Wed, 05 Sep 2012 12:47:39 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1346849246!13498778!1
X-Originating-IP: [213.199.154.205]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5096 invoked from network); 5 Sep 2012 12:47:26 -0000
Received: from am1ehsobe002.messaging.microsoft.com (HELO
	am1outboundpool.messaging.microsoft.com) (213.199.154.205)
	by server-8.tower-21.messagelabs.com with AES128-SHA encrypted SMTP;
	5 Sep 2012 12:47:26 -0000
Received: from mail115-am1-R.bigfish.com (10.3.201.245) by
	AM1EHSOBE008.bigfish.com (10.3.204.28) with Microsoft SMTP Server id
	14.1.225.23; Wed, 5 Sep 2012 12:47:26 +0000
Received: from mail115-am1 (localhost [127.0.0.1])	by
	mail115-am1-R.bigfish.com (Postfix) with ESMTP id 5A3251A0084;
	Wed,  5 Sep 2012 12:47: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: -5
X-BigFish: VPS-5(zzbb2dI98dI9371Ic89bh1432I4015Izz1202hzzz2dh668h839hd25he5bhf0ah107ah1155h)
Received: from mail115-am1 (localhost.localdomain [127.0.0.1]) by mail115-am1
	(MessageSwitch) id 1346849244373150_18965;
	Wed,  5 Sep 2012 12:47:24 +0000 (UTC)
Received: from AM1EHSMHS004.bigfish.com (unknown [10.3.201.227])	by
	mail115-am1.bigfish.com (Postfix) with ESMTP id 4E7B0180047;
	Wed,  5 Sep 2012 12:47:24 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	AM1EHSMHS004.bigfish.com (10.3.207.104) with Microsoft SMTP Server id
	14.1.225.23; Wed, 5 Sep 2012 12:47:22 +0000
X-WSS-ID: 0M9VNIS-02-3CN-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 20879C8119;	Wed,  5 Sep 2012 07:47:15 -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;
	Wed, 5 Sep 2012 07:47:31 -0500
Received: from storexhtp01.amd.com (172.24.4.3) by sausexdag04.amd.com
	(163.181.55.4) with Microsoft SMTP Server (TLS) id 14.1.323.3;
	Wed, 5 Sep 2012 07:47:11 -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, 5 Sep 2012
	08:47:09 -0400
Received: from [165.204.15.57] (gran.osrc.amd.com [165.204.15.57])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id C764B49C0D5; Wed,  5 Sep 2012
	13:47:08 +0100 (BST)
Message-ID: <50474A11.6050601@amd.com>
Date: Wed, 5 Sep 2012 14:48:17 +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: Sander Eikelenboom <linux@eikelenboom.it>
References: <40501859.20120902104331@eikelenboom.it>
	<CC6932C2.3D99D%keir.xen@gmail.com>
	<217459398.20120902171441@eikelenboom.it>
	<5044CAD7.8030800@amd.com>
	<1144695277.20120904184345@eikelenboom.it>
	<5047420A0200007800098BB1@nat28.tlf.novell.com>
	<348297741.20120905122542@eikelenboom.it>
In-Reply-To: <348297741.20120905122542@eikelenboom.it>
X-OriginatorOrg: amd.com
Cc: Keir Fraser <keir.xen@gmail.com>, Santosh Jodh <Santosh.Jodh@citrix.com>,
	Jan Beulich <JBeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Using debug-key 'o:  Dump IOMMU p2m table,
 locks up machine
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="iso-8859-15"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

OK, I got your lspci info, please find my answer inline.

On 09/05/2012 12:25 PM, Sander Eikelenboom wrote:

>
> 00:00.0 Host bridge: ATI Technologies Inc RD890 Northbridge only single s=
lot PCI-e GFX Hydra part (rev 02)
> 00:00.2 Generic system peripheral [0806]: ATI Technologies Inc RD990 I/O =
Memory Management Unit (IOMMU)
> 00:02.0 PCI bridge: ATI Technologies Inc RD890 PCI to PCI bridge (PCI exp=
ress gpp port B)
> 00:03.0 PCI bridge: ATI Technologies Inc RD890 PCI to PCI bridge (PCI exp=
ress gpp port C)
> 00:05.0 PCI bridge: ATI Technologies Inc RD890 PCI to PCI bridge (PCI exp=
ress gpp port E)
> 00:06.0 PCI bridge: ATI Technologies Inc RD890 PCI to PCI bridge (PCI exp=
ress gpp port F)
> 00:0a.0 PCI bridge: ATI Technologies Inc RD890 PCI to PCI bridge (externa=
l gfx1 port A)
> 00:0b.0 PCI bridge: ATI Technologies Inc RD890 PCI to PCI bridge (NB-SB l=
ink)
> 00:0c.0 PCI bridge: ATI Technologies Inc Device 5a20
> 00:0d.0 PCI bridge: ATI Technologies Inc RD890 PCI to PCI bridge (externa=
l gfx1 port B)
> 00:11.0 SATA controller: ATI Technologies Inc SB7x0/SB8x0/SB9x0 SATA Cont=
roller [AHCI mode] (rev 40)
> 00:12.0 USB controller: ATI Technologies Inc SB7x0/SB8x0/SB9x0 USB OHCI0 =
Controller
> 00:12.2 USB controller: ATI Technologies Inc SB7x0/SB8x0/SB9x0 USB EHCI C=
ontroller
> 00:13.0 USB controller: ATI Technologies Inc SB7x0/SB8x0/SB9x0 USB OHCI0 =
Controller
> 00:13.2 USB controller: ATI Technologies Inc SB7x0/SB8x0/SB9x0 USB EHCI C=
ontroller
> 00:14.0 SMBus: ATI Technologies Inc SBx00 SMBus Controller (rev 41)
> 00:14.3 ISA bridge: ATI Technologies Inc SB7x0/SB8x0/SB9x0 LPC host contr=
oller (rev 40)
> 00:14.4 PCI bridge: ATI Technologies Inc SBx00 PCI to PCI Bridge (rev 40)
> 00:14.5 USB controller: ATI Technologies Inc SB7x0/SB8x0/SB9x0 USB OHCI2 =
Controller
> 00:15.0 PCI bridge: ATI Technologies Inc SB700/SB800/SB900 PCI to PCI bri=
dge (PCIE port 0)
> 00:16.0 USB controller: ATI Technologies Inc SB7x0/SB8x0/SB9x0 USB OHCI0 =
Controller
> 00:16.2 USB controller: ATI Technologies Inc SB7x0/SB8x0/SB9x0 USB EHCI C=
ontroller
> 00:18.0 Host bridge: Advanced Micro Devices [AMD] Family 10h Processor Hy=
perTransport Configuration
> 00:18.1 Host bridge: Advanced Micro Devices [AMD] Family 10h Processor Ad=
dress Map
> 00:18.2 Host bridge: Advanced Micro Devices [AMD] Family 10h Processor DR=
AM Controller
> 00:18.3 Host bridge: Advanced Micro Devices [AMD] Family 10h Processor Mi=
scellaneous Control
> 00:18.4 Host bridge: Advanced Micro Devices [AMD] Family 10h Processor Li=
nk Control
> 03:06.0 Multimedia audio controller: C-Media Electronics Inc CM8738 (rev =
10)
> 04:00.0 USB controller: NetMos Technology MCS9990 PCIe to 4=E2Port USB 2.=
0 Host Controller
> 04:00.1 USB controller: NetMos Technology MCS9990 PCIe to 4=E2Port USB 2.=
0 Host Controller
> 04:00.2 USB controller: NetMos Technology MCS9990 PCIe to 4=E2Port USB 2.=
0 Host Controller
> 04:00.3 USB controller: NetMos Technology MCS9990 PCIe to 4=E2Port USB 2.=
0 Host Controller
> 04:00.4 USB controller: NetMos Technology MCS9990 PCIe to 4=E2Port USB 2.=
0 Host Controller
> 04:00.5 USB controller: NetMos Technology MCS9990 PCIe to 4=E2Port USB 2.=
0 Host Controller
> 04:00.6 USB controller: NetMos Technology MCS9990 PCIe to 4=E2Port USB 2.=
0 Host Controller
> 04:00.7 USB controller: NetMos Technology MCS9990 PCIe to 4=E2Port USB 2.=
0 Host Controller
> 05:00.0 Multimedia video controller: Conexant Systems, Inc. CX25850
> 06:00.0 VGA compatible controller: ATI Technologies Inc RV620 LE [Radeon =
HD 3450]
> 06:00.1 Audio device: ATI Technologies Inc RV620 Audio device [Radeon HD =
34xx Series]
> 07:00.0 Multimedia video controller: Conexant Systems, Inc. Device 8210

What kind of device is it, is it a graphic card? Is there any firmware =

running on this device? Some firmwares like vbios might have bad =

assumption of address space. And how many memory the guest has? Could =

you attach a lspci -vvv output from your guest?

Thanks,
Wei

> 08:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168=
B PCI Express Gigabit Ethernet controller (rev 03)
> 09:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168=
B PCI Express Gigabit Ethernet controller (rev 03)
> 0a:00.0 USB controller: NetMos Technology MCS9990 PCIe to 4=E2Port USB 2.=
0 Host Controller
> 0a:00.1 USB controller: NetMos Technology MCS9990 PCIe to 4=E2Port USB 2.=
0 Host Controller
> 0a:00.2 USB controller: NetMos Technology MCS9990 PCIe to 4=E2Port USB 2.=
0 Host Controller
> 0a:00.3 USB controller: NetMos Technology MCS9990 PCIe to 4=E2Port USB 2.=
0 Host Controller
> 0a:00.4 USB controller: NetMos Technology MCS9990 PCIe to 4=E2Port USB 2.=
0 Host Controller
> 0a:00.5 USB controller: NetMos Technology MCS9990 PCIe to 4=E2Port USB 2.=
0 Host Controller
> 0a:00.6 USB controller: NetMos Technology MCS9990 PCIe to 4=E2Port USB 2.=
0 Host Controller
> 0a:00.7 USB controller: NetMos Technology MCS9990 PCIe to 4=E2Port USB 2.=
0 Host Controller
> 0b:00.0 VGA compatible controller: nVidia Corporation G98 [GeForce 8400 G=
S] (rev a1)
>
>
>
>
>
>
>
>> Jan
>
>
>
>



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

From xen-devel-bounces@lists.xen.org Wed Sep 05 13:13:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Sep 2012 13: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 1T9FPr-00081e-IL; Wed, 05 Sep 2012 13:13:11 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <stefano.panella@citrix.com>) id 1T9FPp-00081W-Bu
	for xen-devel@lists.xensource.com; Wed, 05 Sep 2012 13:13:10 +0000
Received: from [85.158.138.51:41975] by server-8.bemta-3.messagelabs.com id
	04/0D-24700-4EF47405; Wed, 05 Sep 2012 13:13:08 +0000
X-Env-Sender: stefano.panella@citrix.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1346850786!24748120!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTE5ODY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12209 invoked from network); 5 Sep 2012 13:13:07 -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;
	5 Sep 2012 13:13:07 -0000
X-IronPort-AV: E=Sophos;i="4.80,374,1344211200"; d="scan'208";a="14359213"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Sep 2012 13:13: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.279.1; Wed, 5 Sep 2012 14:13:03 +0100
Received: from slimey.cam.xci-test.com ([10.80.249.177])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<stefano.panella@citrix.com>)	id 1T9FPj-0003Yl-Bq;
	Wed, 05 Sep 2012 13:13:03 +0000
Message-ID: <50474FDE.6030005@citrix.com>
Date: Wed, 5 Sep 2012 14:13:02 +0100
From: Stefano Panella <stefano.panella@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:14.0) Gecko/20120714 Thunderbird/14.0
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
References: <1346407072-6405-1-git-send-email-stefano.panella@citrix.com>
	<5040B249.4000306@citrix.com>
	<20120831164010.GA18929@localhost.localdomain>
	<50460B2E.3020200@citrix.com>
	<20120904143731.GC23361@phenom.dumpdata.com>
	<50461654.5040901@citrix.com> <50461A59.2050504@citrix.com>
	<50462FFE.7070100@citrix.com>
	<20120904164028.GJ23361@phenom.dumpdata.com>
In-Reply-To: <20120904164028.GJ23361@phenom.dumpdata.com>
Cc: "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 1/1] XEN: Use correct masking in
	xen_swiotlb_alloc_coherent.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 09/04/2012 05:40 PM, Konrad Rzeszutek Wilk wrote:
> On Tue, Sep 04, 2012 at 05:44:46PM +0100, David Vrabel wrote:
>> On 04/09/12 16:12, Stefano Panella wrote:
>>> On 09/04/2012 03:55 PM, David Vrabel wrote:
>>>> On 04/09/12 15:37, Konrad Rzeszutek Wilk wrote:
>>>>> On Tue, Sep 04, 2012 at 03:07:42PM +0100, Stefano Panella wrote:
>>>>>> So if hwdev->coherent_dma_mask is set to 0xffffffffffffffff our
>>>>>> dma_mask will
>>>>>> be u64 set to 0xffffffffffffffff even if we set it to
>>>>>> DMA_BIT_MASK(32) previously.
>>>>> That is what I was missing. Let me include that in the git commit and
>>>>> also
>>>>> put this patch on the stable tree.
>>>> Note that this appears to be a work around for a bug in the sound system
>>>> or Intel HDA device driver which is incorrectly truncating a dma_addr_t
>>>> to a u32.  So by ensuring a DMA_BIT_MASK(32) when the dma_addr_t is
>>>> truncated it still works.
>>>>
>>>> David
>>> Sorry David, I am not completely sure I understand your argument in
>>> favour of a bug in the
>>> sound system or Intel HDA device driver. Could you please elaborate more
>>> in detail about this?
>> The HDA driver claims to support 64-bit DMA addresses, so it should be
>> perfectly fine for the Xen DMA mapping/allocation functions to return
>> DMA addresses > 4 GiB.  For most devices this seems to work just fine.
>>
>> I think that somewhere between the buffer being mapped or allocated and
>> the address being programmed into the hardware, the 64-bit dma_addr_t
>> value is being truncated to 32 bits giving an invalid DMA address.
>>
>> The patch would avoid this by setting the DMA mask to 32-bit and only
>> returning DMA address < 4 GiB which can quite happily be stuffed into a
>> u32 without losing bits.
>>
>> I think it would be useful (without the patch applied) to print the DMA
>> addresses returned by the allocate/mapping functions and the address
>> programmed into the hardware.  It will be easily to spot if it got
>> truncated or not.
> Just enable DMA debug API (CONFIG_DEBUG_DMA_API) and use this fancy module:
>
>
> /*
>   *
>   * This program is free software; you can redistribute it and/or modify
>   * it under the terms of the GNU General Public License v2.0 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.
>   */
>
> #include <linux/module.h>
> #include <linux/string.h>
> #include <linux/types.h>
> #include <linux/init.h>
> #include <linux/stat.h>
> #include <linux/err.h>
> #include <linux/ctype.h>
> #include <linux/slab.h>
> #include <linux/limits.h>
> #include <linux/device.h>
> #include <linux/pci.h>
> #include <linux/blkdev.h>
> #include <linux/device.h>
>
> #include <linux/init.h>
> #include <linux/mm.h>
> #include <linux/fcntl.h>
> #include <linux/slab.h>
> #include <linux/kmod.h>
> #include <linux/major.h>
> #include <linux/highmem.h>
> #include <linux/blkdev.h>
> #include <linux/module.h>
> #include <linux/blkpg.h>
> #include <linux/buffer_head.h>
> #include <linux/mpage.h>
> #include <linux/mount.h>
> #include <linux/uio.h>
> #include <linux/namei.h>
> #include <asm/uaccess.h>
>
> #include <linux/pagemap.h>
> #include <linux/pagevec.h>
>
> #include <linux/dma-debug.h>
>
> #define DUMP_DMA_FUN  "0.1"
>
> MODULE_AUTHOR("Konrad Rzeszutek Wilk <konrad@virtualiron>");
> MODULE_DESCRIPTION("dump dma");
> MODULE_LICENSE("GPL");
> MODULE_VERSION(DUMP_DMA_FUN);
>
> static int __init dump_dma_init(void)
> {
> 	debug_dma_dump_mappings(NULL);
> 	return 0;
> }
>
> static void __exit dump_dma_exit(void)
> {
> }
>
> module_init(dump_dma_init);
> module_exit(dump_dma_exit);
>> David
Hi,
I have just tried to load the dump_dma module, can you observe anything 
from it?

[ 2471.933377] e1000e 0000:00:19.0: single idx 0 P=11d54040 D=21d800040 
L=5f2 DMA_FROM_DEVICE
[ 2471.933380] e1000e 0000:00:19.0: single idx 0 P=11d54740 D=21d800740 
L=5f2 DMA_FROM_DEVICE
[ 2471.933382] e1000e 0000:00:19.0: single idx 4 P=11d5d040 D=21d809040 
L=5f2 DMA_FROM_DEVICE
[ 2471.933384] e1000e 0000:00:19.0: single idx 4 P=11d5d880 D=21d809880 
L=5f2 DMA_FROM_DEVICE
[ 2471.933385] e1000e 0000:00:19.0: single idx 5 P=11d5f040 D=21d80b040 
L=5f2 DMA_FROM_DEVICE
[ 2471.933387] e1000e 0000:00:19.0: single idx 5 P=11d5f740 D=21d80b740 
L=5f2 DMA_FROM_DEVICE
[ 2471.933388] e1000e 0000:00:19.0: single idx 8 P=11d64040 D=21d810040 
L=5f2 DMA_FROM_DEVICE
[ 2471.933390] e1000e 0000:00:19.0: single idx 8 P=11d64740 D=21d810740 
L=5f2 DMA_FROM_DEVICE
[ 2471.933392] e1000e 0000:00:19.0: single idx 21 P=11d7e7c0 D=21d82a7c0 
L=5f2 DMA_FROM_DEVICE
[ 2471.933393] e1000e 0000:00:19.0: single idx 22 P=11d81900 D=21d82d900 
L=5f2 DMA_FROM_DEVICE
[ 2471.933395] e1000e 0000:00:19.0: single idx 23 P=11d82940 D=21d82e940 
L=5f2 DMA_FROM_DEVICE
[ 2471.933396] e1000e 0000:00:19.0: single idx 28 P=1258d040 D=21e039040 
L=5f2 DMA_FROM_DEVICE
[ 2471.933398] e1000e 0000:00:19.0: single idx 33 P=11d96040 D=21d842040 
L=5f2 DMA_FROM_DEVICE
[ 2471.933400] e1000e 0000:00:19.0: single idx 33 P=12596040 D=21e042040 
L=5f2 DMA_FROM_DEVICE
[ 2471.933401] e1000e 0000:00:19.0: single idx 34 P=12599900 D=21e045900 
L=5f2 DMA_FROM_DEVICE
[ 2471.933403] e1000e 0000:00:19.0: single idx 36 P=11d9d040 D=21d849040 
L=5f2 DMA_FROM_DEVICE
[ 2471.933404] e1000e 0000:00:19.0: single idx 36 P=11d9d880 D=21d849880 
L=5f2 DMA_FROM_DEVICE
[ 2471.933406] e1000e 0000:00:19.0: single idx 39 P=125a2040 D=21e04e040 
L=5f2 DMA_FROM_DEVICE
[ 2471.933407] e1000e 0000:00:19.0: single idx 47 P=11db2040 D=21d85e040 
L=5f2 DMA_FROM_DEVICE
[ 2471.933409] e1000e 0000:00:19.0: single idx 49 P=125b6040 D=21e062040 
L=5f2 DMA_FROM_DEVICE
[ 2471.933410] e1000e 0000:00:19.0: single idx 49 P=125b6740 D=21e062740 
L=5f2 DMA_FROM_DEVICE
[ 2471.933412] e1000e 0000:00:19.0: single idx 50 P=125b8040 D=21e064040 
L=5f2 DMA_FROM_DEVICE
[ 2471.933413] e1000e 0000:00:19.0: single idx 51 P=11dba2c0 D=21d8662c0 
L=5f2 DMA_FROM_DEVICE
[ 2471.933415] e1000e 0000:00:19.0: single idx 57 P=11dc7900 D=21d873900 
L=5f2 DMA_FROM_DEVICE
[ 2471.933417] snd_hda_intel 0000:00:1b.0: coherent idx 58 P=11dc8000 
D=21d874000 L=1000 DMA_BIDIRECTIONAL
[ 2471.933419] e1000e 0000:00:19.0: single idx 59 P=11dca040 D=21d876040 
L=5f2 DMA_FROM_DEVICE
[ 2471.933420] e1000e 0000:00:19.0: single idx 59 P=11dca740 D=21d876740 
L=5f2 DMA_FROM_DEVICE
[ 2471.933422] e1000e 0000:00:19.0: single idx 60 P=11dcc040 D=21d878040 
L=5f2 DMA_FROM_DEVICE
[ 2471.933423] e1000e 0000:00:19.0: single idx 60 P=11dcc740 D=21d878740 
L=5f2 DMA_FROM_DEVICE
[ 2471.933425] e1000e 0000:00:19.0: single idx 60 P=11dcd040 D=21d879040 
L=5f2 DMA_FROM_DEVICE
[ 2471.933426] e1000e 0000:00:19.0: single idx 61 P=11dce040 D=21d87a040 
L=5f2 DMA_FROM_DEVICE
[ 2471.933428] e1000e 0000:00:19.0: single idx 61 P=11dce880 D=21d87a880 
L=5f2 DMA_FROM_DEVICE
[ 2471.933429] e1000e 0000:00:19.0: single idx 61 P=11dcf040 D=21d87b040 
L=5f2 DMA_FROM_DEVICE
[ 2471.933431] e1000e 0000:00:19.0: single idx 61 P=11dcf740 D=21d87b740 
L=5f2 DMA_FROM_DEVICE
[ 2471.933432] e1000e 0000:00:19.0: single idx 63 P=125d3040 D=21e07f040 
L=5f2 DMA_FROM_DEVICE
[ 2471.933434] e1000e 0000:00:19.0: single idx 63 P=125d3880 D=21e07f880 
L=5f2 DMA_FROM_DEVICE
[ 2471.933435] e1000e 0000:00:19.0: single idx 70 P=11de0040 D=21d88c040 
L=5f2 DMA_FROM_DEVICE
[ 2471.933437] e1000e 0000:00:19.0: single idx 71 P=2e43d040 D=3208e040 
L=5f2 DMA_FROM_DEVICE
[ 2471.933438] e1000e 0000:00:19.0: single idx 76 P=11dec900 D=21d898900 
L=5f2 DMA_FROM_DEVICE
[ 2471.933440] e1000e 0000:00:19.0: single idx 79 P=125f2240 D=21e09e240 
L=5f2 DMA_FROM_DEVICE
[ 2471.933442] e1000e 0000:00:19.0: single idx 85 P=125fe040 D=21e0aa040 
L=5f2 DMA_FROM_DEVICE
[ 2471.933443] e1000e 0000:00:19.0: single idx 85 P=125fe740 D=21e0aa740 
L=5f2 DMA_FROM_DEVICE
[ 2471.933445] e1000e 0000:00:19.0: single idx 91 P=11e0a840 D=21d8b6840 
L=5f2 DMA_FROM_DEVICE
[ 2471.933446] e1000e 0000:00:19.0: single idx 91 P=11e0a040 D=21d8b6040 
L=5f2 DMA_FROM_DEVICE
[ 2471.933448] e1000e 0000:00:19.0: single idx 94 P=12610040 D=21e0bc040 
L=5f2 DMA_FROM_DEVICE
[ 2471.933449] e1000e 0000:00:19.0: single idx 94 P=12610740 D=21e0bc740 
L=5f2 DMA_FROM_DEVICE
[ 2471.933451] snd_hda_intel 0000:00:1b.0: coherent idx 102 P=11e21000 
D=21d8cd000 L=1000 DMA_BIDIRECTIONAL
[ 2471.933453] e1000e 0000:00:19.0: single idx 104 P=12624040 
D=21e0d0040 L=5f2 DMA_FROM_DEVICE
[ 2471.933454] e1000e 0000:00:19.0: single idx 105 P=11e27040 
D=21d8d3040 L=5f2 DMA_FROM_DEVICE
[ 2471.933456] e1000e 0000:00:19.0: single idx 106 P=11e29040 
D=21d8d5040 L=5f2 DMA_FROM_DEVICE
[ 2471.933459] e1000e 0000:00:19.0: single idx 108 P=1262d900 
D=21e0d9900 L=5f2 DMA_FROM_DEVICE
[ 2471.933460] e1000e 0000:00:19.0: single idx 113 P=11e37880 
D=21d8e3880 L=5f2 DMA_FROM_DEVICE
[ 2471.933462] e1000e 0000:00:19.0: single idx 114 P=11e39040 
D=21d8e5040 L=5f2 DMA_FROM_DEVICE
[ 2471.933463] e1000e 0000:00:19.0: single idx 121 P=12647040 
D=21e0f3040 L=5f2 DMA_FROM_DEVICE
[ 2471.933465] e1000e 0000:00:19.0: single idx 121 P=12647740 
D=21e0f3740 L=5f2 DMA_FROM_DEVICE
[ 2471.933467] snd_hda_intel 0000:00:1b.0: coherent idx 126 P=11e51000 
D=21d8fd000 L=1000 DMA_BIDIRECTIONAL
[ 2471.933468] e1000e 0000:00:19.0: single idx 126 P=11e50040 
D=21d8fc040 L=5f2 DMA_FROM_DEVICE
[ 2471.933470] e1000e 0000:00:19.0: single idx 127 P=12653040 
D=21e0ff040 L=5f2 DMA_FROM_DEVICE
[ 2471.933471] e1000e 0000:00:19.0: single idx 127 P=11e53840 
D=21d8ff840 L=5f2 DMA_FROM_DEVICE
[ 2471.933473] e1000e 0000:00:19.0: single idx 133 P=11e5f040 
D=21d90b040 L=5f2 DMA_FROM_DEVICE
[ 2471.933474] e1000e 0000:00:19.0: single idx 139 P=11e6b040 
D=21d917040 L=5f2 DMA_FROM_DEVICE
[ 2471.933476] e1000e 0000:00:19.0: single idx 139 P=11e6b880 
D=21d917880 L=5f2 DMA_FROM_DEVICE
[ 2471.933478] e1000e 0000:00:19.0: single idx 143 P=11e73040 
D=21d91f040 L=5f2 DMA_FROM_DEVICE
[ 2471.933479] e1000e 0000:00:19.0: single idx 145 P=11e76040 
D=21d922040 L=5f2 DMA_FROM_DEVICE
[ 2471.933480] e1000e 0000:00:19.0: single idx 146 P=11e78040 
D=21d924040 L=5f2 DMA_FROM_DEVICE
[ 2471.933482] e1000e 0000:00:19.0: single idx 147 P=11e7b900 
D=21d927900 L=5f2 DMA_FROM_DEVICE
[ 2471.933483] e1000e 0000:00:19.0: single idx 148 P=11e7c040 
D=21d928040 L=5f2 DMA_FROM_DEVICE
[ 2471.933485] e1000e 0000:00:19.0: single idx 148 P=2e5a2040 D=32129040 
L=5f2 DMA_FROM_DEVICE
[ 2471.933487] e1000e 0000:00:19.0: single idx 148 P=2e5a2740 D=32129740 
L=5f2 DMA_FROM_DEVICE
[ 2471.933488] e1000e 0000:00:19.0: single idx 154 P=12689040 
D=21e135040 L=5f2 DMA_FROM_DEVICE
[ 2471.933490] e1000e 0000:00:19.0: single idx 154 P=11e89040 
D=21d935040 L=5f2 DMA_FROM_DEVICE
[ 2471.933491] e1000e 0000:00:19.0: single idx 156 P=2e593180 D=32138180 
L=5f2 DMA_FROM_DEVICE
[ 2471.933493] e1000e 0000:00:19.0: single idx 161 P=11e97740 
D=21d943740 L=5f2 DMA_FROM_DEVICE
[ 2471.933494] e1000e 0000:00:19.0: single idx 170 P=126a8040 
D=21e154040 L=5f2 DMA_FROM_DEVICE
[ 2471.933496] snd_hda_intel 0000:00:1b.0: coherent idx 185 P=11ec7000 
D=21d973000 L=1000 DMA_BIDIRECTIONAL
[ 2471.933498] e1000e 0000:00:19.0: single idx 190 P=126d1040 
D=21e17d040 L=5f2 DMA_FROM_DEVICE
[ 2471.933499] e1000e 0000:00:19.0: single idx 193 P=126d6040 
D=21e182040 L=5f2 DMA_FROM_DEVICE
[ 2471.933501] e1000e 0000:00:19.0: single idx 193 P=126d6740 
D=21e182740 L=5f2 DMA_FROM_DEVICE
[ 2471.933502] e1000e 0000:00:19.0: single idx 193 P=11ed7040 
D=21d983040 L=5f2 DMA_FROM_DEVICE
[ 2471.933504] e1000e 0000:00:19.0: single idx 193 P=11ed7880 
D=21d983880 L=5f2 DMA_FROM_DEVICE
[ 2471.933505] snd_hda_intel 0000:00:1b.0: coherent idx 195 P=11eda000 
D=21d986000 L=1000 DMA_BIDIRECTIONAL
[ 2471.933507] e1000e 0000:00:19.0: single idx 196 P=126dd7c0 
D=21e1897c0 L=5f2 DMA_FROM_DEVICE
[ 2471.933508] e1000e 0000:00:19.0: single idx 197 P=11edf880 
D=21d98b880 L=5f2 DMA_FROM_DEVICE
[ 2471.933510] e1000e 0000:00:19.0: single idx 197 P=126de740 
D=21e18a740 L=5f2 DMA_FROM_DEVICE
[ 2471.933512] e1000e 0000:00:19.0: coherent idx 203 P=126ea000 
D=21e196000 L=2000 DMA_BIDIRECTIONAL
[ 2471.933513] e1000e 0000:00:19.0: single idx 206 P=126f0040 
D=21e19c040 L=5f2 DMA_FROM_DEVICE
[ 2471.933515] e1000e 0000:00:19.0: single idx 210 P=11ef8040 
D=21d9a4040 L=5f2 DMA_FROM_DEVICE
[ 2471.933516] e1000e 0000:00:19.0: single idx 211 P=11efb840 
D=21d9a7840 L=5f2 DMA_FROM_DEVICE
[ 2471.933518] e1000e 0000:00:19.0: single idx 211 P=11efb040 
D=21d9a7040 L=5f2 DMA_FROM_DEVICE
[ 2471.933519] e1000e 0000:00:19.0: single idx 213 P=11eff180 
D=21d9ab180 L=5f2 DMA_FROM_DEVICE
[ 2471.933521] e1000e 0000:00:19.0: single idx 215 P=11f03180 
D=21d9af180 L=5f2 DMA_FROM_DEVICE
[ 2471.933522] e1000e 0000:00:19.0: single idx 215 P=11f03880 
D=21d9af880 L=5f2 DMA_FROM_DEVICE
[ 2471.933524] e1000e 0000:00:19.0: single idx 215 P=12703040 
D=21e1af040 L=5f2 DMA_FROM_DEVICE
[ 2471.933525] e1000e 0000:00:19.0: single idx 215 P=12703740 
D=21e1af740 L=5f2 DMA_FROM_DEVICE
[ 2471.933527] e1000e 0000:00:19.0: single idx 222 P=12711040 
D=21e1bd040 L=5f2 DMA_FROM_DEVICE
[ 2471.933528] e1000e 0000:00:19.0: single idx 226 P=11f19040 
D=21d9c5040 L=5f2 DMA_FROM_DEVICE
[ 2471.933530] e1000e 0000:00:19.0: single idx 226 P=11f19880 
D=21d9c5880 L=5f2 DMA_FROM_DEVICE
[ 2471.933531] e1000e 0000:00:19.0: single idx 233 P=11f27040 
D=21d9d3040 L=5f2 DMA_FROM_DEVICE
[ 2471.933533] e1000e 0000:00:19.0: single idx 238 P=12731400 
D=21e1dd400 L=5f2 DMA_FROM_DEVICE
[ 2471.933535] ehci_hcd 0000:00:1a.0: single idx 240 P=12631f20 D=1e1800 
L=1 DMA_FROM_DEVICE
[ 2471.933536] e1000e 0000:00:19.0: single idx 245 P=1273e180 
D=21e1ea180 L=5f2 DMA_FROM_DEVICE
[ 2471.933538] e1000e 0000:00:19.0: single idx 246 P=11f41040 
D=21d9ed040 L=5f2 DMA_FROM_DEVICE
[ 2471.933539] e1000e 0000:00:19.0: single idx 247 P=12742040 
D=21e1ee040 L=5f2 DMA_FROM_DEVICE
[ 2471.933541] e1000e 0000:00:19.0: single idx 249 P=12746840 
D=21e1f2840 L=5f2 DMA_FROM_DEVICE
[ 2471.933542] e1000e 0000:00:19.0: single idx 258 P=12759040 
D=21e205040 L=5f2 DMA_FROM_DEVICE
[ 2471.933544] e1000e 0000:00:19.0: single idx 270 P=127712c0 
D=21e21d2c0 L=5f2 DMA_FROM_DEVICE
[ 2471.933546] e1000e 0000:00:19.0: single idx 271 P=12772040 
D=21e21e040 L=5f2 DMA_FROM_DEVICE
[ 2471.933547] e1000e 0000:00:19.0: single idx 271 P=12773180 
D=21e21f180 L=5f2 DMA_FROM_DEVICE
[ 2471.933549] e1000e 0000:00:19.0: single idx 273 P=12776040 
D=21e222040 L=5f2 DMA_FROM_DEVICE
[ 2471.933550] e1000e 0000:00:19.0: single idx 280 P=12784040 
D=21e230040 L=5f2 DMA_FROM_DEVICE
[ 2471.933552] e1000e 0000:00:19.0: single idx 280 P=12784880 
D=21e230880 L=5f2 DMA_FROM_DEVICE
[ 2471.933554] e1000e 0000:00:19.0: single idx 284 P=1278c900 
D=21e238900 L=5f2 DMA_FROM_DEVICE
[ 2471.933555] e1000e 0000:00:19.0: single idx 286 P=12790040 
D=21e23c040 L=5f2 DMA_FROM_DEVICE
[ 2471.933557] e1000e 0000:00:19.0: single idx 286 P=12790880 
D=21e23c880 L=5f2 DMA_FROM_DEVICE
[ 2471.933558] e1000e 0000:00:19.0: single idx 299 P=127aa040 
D=21e256040 L=5f2 DMA_FROM_DEVICE
[ 2471.933560] e1000e 0000:00:19.0: single idx 299 P=127ab040 
D=21e257040 L=5f2 DMA_FROM_DEVICE
[ 2471.933561] e1000e 0000:00:19.0: single idx 299 P=127ab740 
D=21e257740 L=5f2 DMA_FROM_DEVICE
[ 2471.933563] e1000e 0000:00:19.0: single idx 307 P=127ba040 
D=21e266040 L=5f2 DMA_FROM_DEVICE
[ 2471.933565] e1000e 0000:00:19.0: single idx 313 P=127c7840 
D=21e273840 L=5f2 DMA_FROM_DEVICE
[ 2471.933566] e1000e 0000:00:19.0: single idx 313 P=127c7040 
D=21e273040 L=5f2 DMA_FROM_DEVICE
[ 2471.933568] e1000e 0000:00:19.0: single idx 324 P=127dd040 
D=21e289040 L=5f2 DMA_FROM_DEVICE
[ 2471.933569] e1000e 0000:00:19.0: single idx 334 P=127f0180 
D=21e29c180 L=5f2 DMA_FROM_DEVICE
[ 2471.933571] e1000e 0000:00:19.0: single idx 334 P=127f0880 
D=21e29c880 L=5f2 DMA_FROM_DEVICE
[ 2471.933572] e1000e 0000:00:19.0: single idx 336 P=127f4840 
D=21e2a0840 L=5f2 DMA_FROM_DEVICE
[ 2471.933574] e1000e 0000:00:19.0: single idx 342 P=12000040 
D=21daac040 L=5f2 DMA_FROM_DEVICE
[ 2471.933576] e1000e 0000:00:19.0: single idx 342 P=12000740 
D=21daac740 L=5f2 DMA_FROM_DEVICE
[ 2471.933578] e1000e 0000:00:19.0: single idx 370 P=12039040 
D=21dae5040 L=5f2 DMA_FROM_DEVICE
[ 2471.933579] e1000e 0000:00:19.0: single idx 371 P=1203a040 
D=21dae6040 L=5f2 DMA_FROM_DEVICE
[ 2471.933581] e1000e 0000:00:19.0: single idx 371 P=1203a880 
D=21dae6880 L=5f2 DMA_FROM_DEVICE
[ 2471.933582] e1000e 0000:00:19.0: single idx 375 P=12043880 
D=21daef880 L=5f2 DMA_FROM_DEVICE
[ 2471.933584] e1000e 0000:00:19.0: single idx 386 P=12058180 
D=21db04180 L=5f2 DMA_FROM_DEVICE
[ 2471.933586] e1000e 0000:00:19.0: single idx 393 P=12067540 
D=21db13540 L=5f2 DMA_FROM_DEVICE
[ 2471.933587] e1000e 0000:00:19.0: single idx 395 P=1206a7c0 
D=21db167c0 L=5f2 DMA_FROM_DEVICE
[ 2471.933589] e1000e 0000:00:19.0: single idx 396 P=1206c880 
D=21db18880 L=5f2 DMA_FROM_DEVICE
[ 2471.933590] e1000e 0000:00:19.0: single idx 408 P=12084180 
D=21db30180 L=5f2 DMA_FROM_DEVICE
[ 2471.933592] e1000e 0000:00:19.0: single idx 431 P=118b3740 
D=21d35f740 L=5f2 DMA_FROM_DEVICE
[ 2471.933594] e1000e 0000:00:19.0: single idx 434 P=118b9900 
D=21d365900 L=5f2 DMA_FROM_DEVICE
[ 2471.933596] snd_hda_intel 0000:00:1b.0: coherent idx 436 P=120bc000 
D=21db68000 L=1000 DMA_BIDIRECTIONAL
[ 2471.933597] e1000e 0000:00:19.0: single idx 436 P=118bd040 
D=21d369040 L=5f2 DMA_FROM_DEVICE
[ 2471.933599] e1000e 0000:00:19.0: single idx 458 P=120e8040 
D=21db94040 L=5f2 DMA_FROM_DEVICE
[ 2471.933600] e1000e 0000:00:19.0: single idx 458 P=120e8740 
D=21db94740 L=5f2 DMA_FROM_DEVICE
[ 2471.933602] e1000e 0000:00:19.0: single idx 459 P=120eb040 
D=21db97040 L=5f2 DMA_FROM_DEVICE
[ 2471.933603] e1000e 0000:00:19.0: single idx 459 P=120eb880 
D=21db97880 L=5f2 DMA_FROM_DEVICE
[ 2471.933605] snd_hda_intel 0000:00:1b.0: coherent idx 462 P=118f0000 
D=21d39c000 L=10000 DMA_BIDIRECTIONAL
[ 2471.933607] snd_hda_intel 0000:00:1b.0: coherent idx 470 P=11900000 
D=21d3ac000 L=10000 DMA_BIDIRECTIONAL
[ 2471.933608] e1000e 0000:00:19.0: single idx 470 P=12101040 
D=21dbad040 L=5f2 DMA_FROM_DEVICE
[ 2471.933610] e1000e 0000:00:19.0: single idx 470 P=12101880 
D=21dbad880 L=5f2 DMA_FROM_DEVICE
[ 2471.933612] snd_hda_intel 0000:00:1b.0: coherent idx 478 P=11910000 
D=21d3bc000 L=10000 DMA_BIDIRECTIONAL
[ 2471.933613] snd_hda_intel 0000:00:1b.0: coherent idx 486 P=11920000 
D=21d3cc000 L=10000 DMA_BIDIRECTIONAL
[ 2471.933615] snd_hda_intel 0000:00:1b.0: coherent idx 494 P=11930000 
D=21d3dc000 L=10000 DMA_BIDIRECTIONAL
[ 2471.933617] e1000e 0000:00:19.0: single idx 498 P=12139040 
D=21dbe5040 L=5f2 DMA_FROM_DEVICE
[ 2471.933618] e1000e 0000:00:19.0: single idx 502 P=11940040 
D=21d3ec040 L=5f2 DMA_FROM_DEVICE
[ 2471.933620] e1000e 0000:00:19.0: single idx 503 P=11942040 
D=21d3ee040 L=5f2 DMA_FROM_DEVICE
[ 2471.933621] e1000e 0000:00:19.0: single idx 503 P=11943740 
D=21d3ef740 L=5f2 DMA_FROM_DEVICE
[ 2471.933623] e1000e 0000:00:19.0: single idx 508 P=1214c040 
D=21dbf8040 L=5f2 DMA_FROM_DEVICE
[ 2471.933624] e1000e 0000:00:19.0: single idx 508 P=1214c940 
D=21dbf8940 L=5f2 DMA_FROM_DEVICE
[ 2471.933626] e1000e 0000:00:19.0: single idx 524 P=1196c840 
D=21d418840 L=5f2 DMA_FROM_DEVICE
[ 2471.933628] e1000e 0000:00:19.0: single idx 530 P=11978040 
D=21d424040 L=5f2 DMA_FROM_DEVICE
[ 2471.933629] e1000e 0000:00:19.0: single idx 536 P=11984040 
D=21d430040 L=5f2 DMA_FROM_DEVICE
[ 2471.933631] e1000e 0000:00:19.0: single idx 537 P=11986040 
D=21d432040 L=5f2 DMA_FROM_DEVICE
[ 2471.933632] e1000e 0000:00:19.0: single idx 540 P=1218c680 
D=21dc38680 L=5f2 DMA_FROM_DEVICE
[ 2471.933634] e1000e 0000:00:19.0: single idx 545 P=12196180 
D=21dc42180 L=5f2 DMA_FROM_DEVICE
[ 2471.933635] e1000e 0000:00:19.0: single idx 546 P=11998040 
D=21d444040 L=5f2 DMA_FROM_DEVICE
[ 2471.933637] e1000e 0000:00:19.0: single idx 548 P=1199d040 
D=21d449040 L=5f2 DMA_FROM_DEVICE
[ 2471.933639] e1000e 0000:00:19.0: single idx 554 P=119a8400 
D=21d454400 L=5f2 DMA_FROM_DEVICE
[ 2471.933640] e1000e 0000:00:19.0: single idx 557 P=119af040 
D=21d45b040 L=5f2 DMA_FROM_DEVICE
[ 2471.933642] e1000e 0000:00:19.0: single idx 565 P=121bf180 
D=21dc6b180 L=5f2 DMA_FROM_DEVICE
[ 2471.933643] e1000e 0000:00:19.0: single idx 579 P=119db240 
D=21d487240 L=5f2 DMA_FROM_DEVICE
[ 2471.933646] ahci 0000:00:1f.2: coherent idx 582 P=121e0000 
D=21dc8c000 L=16500 DMA_BIDIRECTIONAL
[ 2471.933648] ahci 0000:00:1f.2: coherent idx 598 P=12200000 
D=21dcac000 L=16500 DMA_BIDIRECTIONAL
[ 2471.933649] e1000e 0000:00:19.0: single idx 600 P=11a04040 
D=21d4b0040 L=5f2 DMA_FROM_DEVICE
[ 2471.933651] e1000e 0000:00:19.0: single idx 600 P=11a04880 
D=21d4b0880 L=5f2 DMA_FROM_DEVICE
[ 2471.933652] e1000e 0000:00:19.0: single idx 605 P=11a0e040 
D=21d4ba040 L=5f2 DMA_FROM_DEVICE
[ 2471.933654] e1000e 0000:00:19.0: single idx 609 P=11a17040 
D=21d4c3040 L=5f2 DMA_FROM_DEVICE
[ 2471.933655] e1000e 0000:00:19.0: single idx 609 P=11a17740 
D=21d4c3740 L=5f2 DMA_FROM_DEVICE
[ 2471.933657] ahci 0000:00:1f.2: coherent idx 614 P=12220000 
D=21dccc000 L=16500 DMA_BIDIRECTIONAL
[ 2471.933658] e1000e 0000:00:19.0: single idx 616 P=11a25040 
D=21d4d1040 L=5f2 DMA_FROM_DEVICE
[ 2471.933660] e1000e 0000:00:19.0: single idx 617 P=11a26040 
D=21d4d2040 L=5f2 DMA_FROM_DEVICE
[ 2471.933661] e1000e 0000:00:19.0: single idx 622 P=11a31740 
D=21d4dd740 L=5f2 DMA_FROM_DEVICE
[ 2471.933663] e1000e 0000:00:19.0: single idx 632 P=11a44180 
D=21d4f0180 L=5f2 DMA_FROM_DEVICE
[ 2471.933665] e1000e 0000:00:19.0: single idx 634 P=122492c0 
D=21dcf52c0 L=5f2 DMA_FROM_DEVICE
[ 2471.933666] e1000e 0000:00:19.0: single idx 636 P=11a4d040 
D=21d4f9040 L=5f2 DMA_FROM_DEVICE
[ 2471.933668] e1000e 0000:00:19.0: single idx 636 P=11a4d740 
D=21d4f9740 L=5f2 DMA_FROM_DEVICE
[ 2471.933669] e1000e 0000:00:19.0: single idx 645 P=11a5f400 
D=21d50b400 L=5f2 DMA_FROM_DEVICE
[ 2471.933671] e1000e 0000:00:19.0: single idx 647 P=12263040 
D=21dd0f040 L=5f2 DMA_FROM_DEVICE
[ 2471.933672] e1000e 0000:00:19.0: single idx 647 P=12263740 
D=21dd0f740 L=5f2 DMA_FROM_DEVICE
[ 2471.933674] e1000e 0000:00:19.0: single idx 648 P=12264900 
D=21dd10900 L=5f2 DMA_FROM_DEVICE
[ 2471.933675] e1000e 0000:00:19.0: single idx 651 P=11a6a040 
D=21d516040 L=5f2 DMA_FROM_DEVICE
[ 2471.933677] e1000e 0000:00:19.0: single idx 654 P=12270440 
D=21dd1c440 L=5f2 DMA_FROM_DEVICE
[ 2471.933679] e1000e 0000:00:19.0: single idx 663 P=11a83040 
D=21d52f040 L=5f2 DMA_FROM_DEVICE
[ 2471.933680] e1000e 0000:00:19.0: single idx 663 P=11a83740 
D=21d52f740 L=5f2 DMA_FROM_DEVICE
[ 2471.933682] snd_hda_intel 0000:00:1b.0: coherent idx 675 P=1229b000 
D=21dd47000 L=1000 DMA_BIDIRECTIONAL
[ 2471.933683] e1000e 0000:00:19.0: single idx 677 P=11a9f040 
D=21d54b040 L=5f2 DMA_FROM_DEVICE
[ 2471.933685] e1000e 0000:00:19.0: single idx 677 P=11a9f740 
D=21d54b740 L=5f2 DMA_FROM_DEVICE
[ 2471.933686] e1000e 0000:00:19.0: single idx 678 P=11aa0040 
D=21d54c040 L=5f2 DMA_FROM_DEVICE
[ 2471.933688] e1000e 0000:00:19.0: single idx 678 P=11aa0740 
D=21d54c740 L=5f2 DMA_FROM_DEVICE
[ 2471.933690] e1000e 0000:00:19.0: single idx 683 P=122ab040 
D=21dd57040 L=5f2 DMA_FROM_DEVICE
[ 2471.933691] e1000e 0000:00:19.0: single idx 685 P=11aaf040 
D=21d55b040 L=5f2 DMA_FROM_DEVICE
[ 2471.933693] e1000e 0000:00:19.0: single idx 687 P=122b22c0 
D=21dd5e2c0 L=5f2 DMA_FROM_DEVICE
[ 2471.933694] e1000e 0000:00:19.0: single idx 688 P=11ab5840 
D=21d561840 L=5f2 DMA_FROM_DEVICE
[ 2471.933696] e1000e 0000:00:19.0: single idx 688 P=11ab5040 
D=21d561040 L=5f2 DMA_FROM_DEVICE
[ 2471.933697] e1000e 0000:00:19.0: single idx 688 P=11ab4040 
D=21d560040 L=5f2 DMA_FROM_DEVICE
[ 2471.933698] e1000e 0000:00:19.0: single idx 688 P=11ab4880 
D=21d560880 L=5f2 DMA_FROM_DEVICE
[ 2471.933700] e1000e 0000:00:19.0: single idx 690 P=11ab9040 
D=21d565040 L=5f2 DMA_FROM_DEVICE
[ 2471.933702] e1000e 0000:00:19.0: single idx 702 P=122d1840 
D=21dd7d840 L=5f2 DMA_FROM_DEVICE
[ 2471.933703] e1000e 0000:00:19.0: single idx 703 P=122d3040 
D=21dd7f040 L=5f2 DMA_FROM_DEVICE
[ 2471.933705] e1000e 0000:00:19.0: single idx 703 P=11ad3740 
D=21d57f740 L=5f2 DMA_FROM_DEVICE
[ 2471.933706] e1000e 0000:00:19.0: single idx 711 P=11ae3400 
D=21d58f400 L=5f2 DMA_FROM_DEVICE
[ 2471.933708] e1000e 0000:00:19.0: single idx 715 P=122ea040 
D=21dd96040 L=5f2 DMA_FROM_DEVICE
[ 2471.933709] e1000e 0000:00:19.0: single idx 716 P=11aed040 
D=21d599040 L=5f2 DMA_FROM_DEVICE
[ 2471.933711] e1000e 0000:00:19.0: single idx 719 P=122f2740 
D=21dd9e740 L=5f2 DMA_FROM_DEVICE
[ 2471.933712] e1000e 0000:00:19.0: single idx 722 P=122f9040 
D=21dda5040 L=5f2 DMA_FROM_DEVICE
[ 2471.933714] e1000e 0000:00:19.0: single idx 722 P=122f8040 
D=21dda4040 L=5f2 DMA_FROM_DEVICE
[ 2471.933715] e1000e 0000:00:19.0: single idx 722 P=122f8880 
D=21dda4880 L=5f2 DMA_FROM_DEVICE
[ 2471.933717] e1000e 0000:00:19.0: single idx 744 P=12324540 
D=21ddd0540 L=5f2 DMA_FROM_DEVICE
[ 2471.933719] e1000e 0000:00:19.0: single idx 747 P=1232a040 
D=21ddd6040 L=5f2 DMA_FROM_DEVICE
[ 2471.933720] e1000e 0000:00:19.0: single idx 747 P=1232a740 
D=21ddd6740 L=5f2 DMA_FROM_DEVICE
[ 2471.933722] ehci_hcd 0000:00:1d.0: coherent idx 752 P=1267e000 
D=325e1000 L=1000 DMA_BIDIRECTIONAL
[ 2471.933724] ehci_hcd 0000:00:1d.0: coherent idx 752 P=125af000 
D=325e0000 L=1000 DMA_BIDIRECTIONAL
[ 2471.933725] ehci_hcd 0000:00:1a.0: coherent idx 753 P=1266f000 
D=325e3000 L=1000 DMA_BIDIRECTIONAL
[ 2471.933727] ehci_hcd 0000:00:1d.0: coherent idx 753 P=120a3000 
D=325e2000 L=1000 DMA_BIDIRECTIONAL
[ 2471.933728] e1000e 0000:00:19.0: single idx 753 P=12336740 
D=21dde2740 L=5f2 DMA_FROM_DEVICE
[ 2471.933730] ehci_hcd 0000:00:1a.0: coherent idx 754 P=125ad000 
D=325e5000 L=1000 DMA_BIDIRECTIONAL
[ 2471.933731] ehci_hcd 0000:00:1a.0: coherent idx 754 P=12097000 
D=325e4000 L=1000 DMA_BIDIRECTIONAL
[ 2471.933733] e1000e 0000:00:19.0: single idx 755 P=1233b900 
D=21dde7900 L=5f2 DMA_FROM_DEVICE
[ 2471.933735] xhci_hcd 0000:00:14.0: coherent idx 756 P=126cd000 
D=365e9000 L=1000 DMA_BIDIRECTIONAL
[ 2471.933736] xhci_hcd 0000:00:14.0: coherent idx 756 P=120c1000 
D=365e8000 L=1000 DMA_BIDIRECTIONAL
[ 2471.933738] xhci_hcd 0000:00:14.0: coherent idx 757 P=12164000 
D=365eb000 L=80 DMA_BIDIRECTIONAL
[ 2471.933739] xhci_hcd 0000:00:14.0: coherent idx 757 P=1262e000 
D=365ea000 L=1000 DMA_BIDIRECTIONAL
[ 2471.933741] xhci_hcd 0000:00:14.0: coherent idx 758 P=1266b000 
D=365ed000 L=1000 DMA_BIDIRECTIONAL
[ 2471.933742] xhci_hcd 0000:00:14.0: coherent idx 758 P=12163000 
D=365ec000 L=10 DMA_BIDIRECTIONAL
[ 2471.933744] xhci_hcd 0000:00:14.0: coherent idx 759 P=12633000 
D=365ef000 L=808 DMA_BIDIRECTIONAL
[ 2471.933745] xhci_hcd 0000:00:14.0: coherent idx 759 P=12720000 
D=365ee000 L=1000 DMA_BIDIRECTIONAL
[ 2471.933747] xhci_hcd 0000:00:14.0: coherent idx 761 P=1263e000 
D=365f3000 L=1000 DMA_BIDIRECTIONAL
[ 2471.933749] xhci_hcd 0000:00:14.0: coherent idx 762 P=1268e000 
D=365f5000 L=1000 DMA_BIDIRECTIONAL
[ 2471.933750] xhci_hcd 0000:00:14.0: coherent idx 762 P=120c2000 
D=365f4000 L=1000 DMA_BIDIRECTIONAL
[ 2471.933752] xhci_hcd 0000:00:14.0: coherent idx 763 P=127d6000 
D=365f7000 L=1000 DMA_BIDIRECTIONAL
[ 2471.933753] xhci_hcd 0000:00:14.0: coherent idx 763 P=127d7000 
D=365f6000 L=1000 DMA_BIDIRECTIONAL
[ 2471.933755] xhci_hcd 0000:00:14.0: coherent idx 764 P=127d0000 
D=365f9000 L=1000 DMA_BIDIRECTIONAL
[ 2471.933756] xhci_hcd 0000:00:14.0: coherent idx 764 P=12148000 
D=365f8000 L=1000 DMA_BIDIRECTIONAL
[ 2471.933758] e1000e 0000:00:19.0: single idx 764 P=1234c400 
D=21ddf8400 L=5f2 DMA_FROM_DEVICE
[ 2471.933759] xhci_hcd 0000:00:14.0: coherent idx 765 P=12160000 
D=365fb000 L=1000 DMA_BIDIRECTIONAL
[ 2471.933761] xhci_hcd 0000:00:14.0: coherent idx 765 P=120fe000 
D=365fa000 L=1000 DMA_BIDIRECTIONAL
[ 2471.933762] xhci_hcd 0000:00:14.0: coherent idx 766 P=12162000 
D=365fd000 L=1000 DMA_BIDIRECTIONAL
[ 2471.933764] xhci_hcd 0000:00:14.0: coherent idx 766 P=1217b000 
D=365fc000 L=1000 DMA_BIDIRECTIONAL
[ 2471.933765] xhci_hcd 0000:00:14.0: coherent idx 767 P=125cb000 
D=365ff000 L=1000 DMA_BIDIRECTIONAL
[ 2471.933767] xhci_hcd 0000:00:14.0: coherent idx 767 P=12748000 
D=365fe000 L=1000 DMA_BIDIRECTIONAL
[ 2471.933769] e1000e 0000:00:19.0: single idx 783 P=12373400 
D=21de1f400 L=5f2 DMA_FROM_DEVICE
[ 2471.933770] e1000e 0000:00:19.0: single idx 793 P=12386840 
D=21de32840 L=5f2 DMA_FROM_DEVICE
[ 2471.933772] e1000e 0000:00:19.0: single idx 794 P=12388840 
D=21de34840 L=5f2 DMA_FROM_DEVICE
[ 2471.933773] e1000e 0000:00:19.0: single idx 794 P=12389740 
D=21de35740 L=5f2 DMA_FROM_DEVICE
[ 2471.933775] e1000e 0000:00:19.0: single idx 797 P=1238f040 
D=21de3b040 L=5f2 DMA_FROM_DEVICE
[ 2471.933776] e1000e 0000:00:19.0: single idx 797 P=1238f880 
D=21de3b880 L=5f2 DMA_FROM_DEVICE
[ 2471.933778] e1000e 0000:00:19.0: single idx 801 P=12397040 
D=21de43040 L=5f2 DMA_FROM_DEVICE
[ 2471.933779] e1000e 0000:00:19.0: single idx 801 P=12397880 
D=21de43880 L=5f2 DMA_FROM_DEVICE
[ 2471.933781] e1000e 0000:00:19.0: single idx 812 P=123ac040 
D=21de58040 L=5f2 DMA_FROM_DEVICE
[ 2471.933783] e1000e 0000:00:19.0: single idx 814 P=123b0040 
D=21de5c040 L=5f2 DMA_FROM_DEVICE
[ 2471.933784] snd_hda_intel 0000:00:1b.0: coherent idx 817 P=123b6000 
D=21de62000 L=1000 DMA_BIDIRECTIONAL
[ 2471.933786] snd_hda_intel 0000:00:1b.0: coherent idx 821 P=123be000 
D=21de6a000 L=1000 DMA_BIDIRECTIONAL
[ 2471.933787] e1000e 0000:00:19.0: single idx 823 P=123c2740 
D=21de6e740 L=5f2 DMA_FROM_DEVICE
[ 2471.933789] e1000e 0000:00:19.0: single idx 843 P=123ea500 
D=21de96500 L=5f2 DMA_FROM_DEVICE
[ 2471.933791] e1000e 0000:00:19.0: single idx 844 P=123ed900 
D=21de99900 L=5f2 DMA_FROM_DEVICE
[ 2471.933792] e1000e 0000:00:19.0: single idx 845 P=123ef740 
D=21de9b740 L=5f2 DMA_FROM_DEVICE
[ 2471.933794] e1000e 0000:00:19.0: single idx 847 P=123f3740 
D=21de9f740 L=5f2 DMA_FROM_DEVICE
[ 2471.933795] e1000e 0000:00:19.0: single idx 848 P=123f5040 
D=21dea1040 L=5f2 DMA_FROM_DEVICE
[ 2471.933797] e1000e 0000:00:19.0: single idx 848 P=123f5880 
D=21dea1880 L=5f2 DMA_FROM_DEVICE
[ 2471.933798] e1000e 0000:00:19.0: single idx 851 P=123fa7c0 
D=21dea67c0 L=5f2 DMA_FROM_DEVICE
[ 2471.933800] e1000e 0000:00:19.0: coherent idx 855 P=11c02000 
D=21d6ae000 L=1000 DMA_BIDIRECTIONAL
[ 2471.933802] e1000e 0000:00:19.0: single idx 865 P=11c16040 
D=21d6c2040 L=5f2 DMA_FROM_DEVICE
[ 2471.933803] e1000e 0000:00:19.0: single idx 870 P=11c21540 
D=21d6cd540 L=5f2 DMA_FROM_DEVICE
[ 2471.933805] e1000e 0000:00:19.0: single idx 871 P=11c23840 
D=21d6cf840 L=5f2 DMA_FROM_DEVICE
[ 2471.933806] e1000e 0000:00:19.0: single idx 871 P=11c23040 
D=21d6cf040 L=5f2 DMA_FROM_DEVICE
[ 2471.933808] e1000e 0000:00:19.0: single idx 885 P=11c3e840 
D=21d6ea840 L=5f2 DMA_FROM_DEVICE
[ 2471.933809] e1000e 0000:00:19.0: single idx 885 P=11c3e040 
D=21d6ea040 L=5f2 DMA_FROM_DEVICE
[ 2471.933811] e1000e 0000:00:19.0: single idx 889 P=11c46180 
D=21d6f2180 L=5f2 DMA_FROM_DEVICE
[ 2471.933813] e1000e 0000:00:19.0: single idx 893 P=11c4e040 
D=21d6fa040 L=5f2 DMA_FROM_DEVICE
[ 2471.933814] e1000e 0000:00:19.0: single idx 897 P=11c56040 
D=21d702040 L=5f2 DMA_FROM_DEVICE
[ 2471.933816] e1000e 0000:00:19.0: single idx 902 P=12460040 
D=21df0c040 L=5f2 DMA_FROM_DEVICE
[ 2471.933817] e1000e 0000:00:19.0: single idx 902 P=12460740 
D=21df0c740 L=5f2 DMA_FROM_DEVICE
[ 2471.933819] e1000e 0000:00:19.0: single idx 910 P=11c71900 
D=21d71d900 L=5f2 DMA_FROM_DEVICE
[ 2471.933820] e1000e 0000:00:19.0: single idx 911 P=11c73180 
D=21d71f180 L=5f2 DMA_FROM_DEVICE
[ 2471.933822] e1000e 0000:00:19.0: single idx 916 P=11c7d7c0 
D=21d7297c0 L=5f2 DMA_FROM_DEVICE
[ 2471.933824] e1000e 0000:00:19.0: single idx 926 P=11c90040 
D=21d73c040 L=5f2 DMA_FROM_DEVICE
[ 2471.933825] e1000e 0000:00:19.0: single idx 931 P=11c9b040 
D=21d747040 L=5f2 DMA_FROM_DEVICE
[ 2471.933827] e1000e 0000:00:19.0: single idx 939 P=11caa040 
D=21d756040 L=5f2 DMA_FROM_DEVICE
[ 2471.933828] e1000e 0000:00:19.0: single idx 939 P=11caa740 
D=21d756740 L=5f2 DMA_FROM_DEVICE
[ 2471.933830] e1000e 0000:00:19.0: single idx 940 P=11cac400 
D=21d758400 L=5f2 DMA_FROM_DEVICE
[ 2471.933831] snd_hda_intel 0000:00:1b.0: coherent idx 941 P=11caf000 
D=21d75b000 L=1000 DMA_BIDIRECTIONAL
[ 2471.933833] e1000e 0000:00:19.0: single idx 953 P=11cc7040 
D=21d773040 L=5f2 DMA_FROM_DEVICE
[ 2471.933835] e1000e 0000:00:19.0: single idx 960 P=11cd5040 
D=21d781040 L=5f2 DMA_FROM_DEVICE
[ 2471.933836] e1000e 0000:00:19.0: single idx 960 P=11cd5880 
D=21d781880 L=5f2 DMA_FROM_DEVICE
[ 2471.933838] e1000e 0000:00:19.0: single idx 968 P=11ce5900 
D=21d791900 L=5f2 DMA_FROM_DEVICE
[ 2471.933839] e1000e 0000:00:19.0: single idx 972 P=11cec840 
D=21d798840 L=5f2 DMA_FROM_DEVICE
[ 2471.933841] e1000e 0000:00:19.0: single idx 972 P=11ced040 
D=21d799040 L=5f2 DMA_FROM_DEVICE
[ 2471.933843] e1000e 0000:00:19.0: single idx 978 P=11cf8040 
D=21d7a4040 L=5f2 DMA_FROM_DEVICE
[ 2471.933844] e1000e 0000:00:19.0: single idx 992 P=12514040 
D=21dfc0040 L=5f2 DMA_FROM_DEVICE
[ 2471.933846] e1000e 0000:00:19.0: single idx 992 P=12514880 
D=21dfc0880 L=5f2 DMA_FROM_DEVICE
[ 2471.933847] e1000e 0000:00:19.0: single idx 992 P=11d14880 
D=21d7c0880 L=5f2 DMA_FROM_DEVICE
[ 2471.933849] e1000e 0000:00:19.0: single idx 998 P=11d20040 
D=21d7cc040 L=5f2 DMA_FROM_DEVICE
[ 2471.933850] e1000e 0000:00:19.0: single idx 1003 P=11d2a040 
D=21d7d6040 L=5f2 DMA_FROM_DEVICE
[ 2471.933852] e1000e 0000:00:19.0: single idx 1008 P=12535040 
D=21dfe1040 L=5f2 DMA_FROM_DEVICE
[ 2471.933854] e1000e 0000:00:19.0: single idx 1009 P=12536040 
D=21dfe2040 L=5f2 DMA_FROM_DEVICE
[ 2471.933855] e1000e 0000:00:19.0: single idx 1009 P=12536880 
D=21dfe2880 L=5f2 DMA_FROM_DEVICE

Regards,

Stefano


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

From xen-devel-bounces@lists.xen.org Wed Sep 05 13:13:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Sep 2012 13: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 1T9FPr-00081e-IL; Wed, 05 Sep 2012 13:13:11 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <stefano.panella@citrix.com>) id 1T9FPp-00081W-Bu
	for xen-devel@lists.xensource.com; Wed, 05 Sep 2012 13:13:10 +0000
Received: from [85.158.138.51:41975] by server-8.bemta-3.messagelabs.com id
	04/0D-24700-4EF47405; Wed, 05 Sep 2012 13:13:08 +0000
X-Env-Sender: stefano.panella@citrix.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1346850786!24748120!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTE5ODY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12209 invoked from network); 5 Sep 2012 13:13:07 -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;
	5 Sep 2012 13:13:07 -0000
X-IronPort-AV: E=Sophos;i="4.80,374,1344211200"; d="scan'208";a="14359213"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Sep 2012 13:13: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.279.1; Wed, 5 Sep 2012 14:13:03 +0100
Received: from slimey.cam.xci-test.com ([10.80.249.177])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<stefano.panella@citrix.com>)	id 1T9FPj-0003Yl-Bq;
	Wed, 05 Sep 2012 13:13:03 +0000
Message-ID: <50474FDE.6030005@citrix.com>
Date: Wed, 5 Sep 2012 14:13:02 +0100
From: Stefano Panella <stefano.panella@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:14.0) Gecko/20120714 Thunderbird/14.0
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
References: <1346407072-6405-1-git-send-email-stefano.panella@citrix.com>
	<5040B249.4000306@citrix.com>
	<20120831164010.GA18929@localhost.localdomain>
	<50460B2E.3020200@citrix.com>
	<20120904143731.GC23361@phenom.dumpdata.com>
	<50461654.5040901@citrix.com> <50461A59.2050504@citrix.com>
	<50462FFE.7070100@citrix.com>
	<20120904164028.GJ23361@phenom.dumpdata.com>
In-Reply-To: <20120904164028.GJ23361@phenom.dumpdata.com>
Cc: "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 1/1] XEN: Use correct masking in
	xen_swiotlb_alloc_coherent.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 09/04/2012 05:40 PM, Konrad Rzeszutek Wilk wrote:
> On Tue, Sep 04, 2012 at 05:44:46PM +0100, David Vrabel wrote:
>> On 04/09/12 16:12, Stefano Panella wrote:
>>> On 09/04/2012 03:55 PM, David Vrabel wrote:
>>>> On 04/09/12 15:37, Konrad Rzeszutek Wilk wrote:
>>>>> On Tue, Sep 04, 2012 at 03:07:42PM +0100, Stefano Panella wrote:
>>>>>> So if hwdev->coherent_dma_mask is set to 0xffffffffffffffff our
>>>>>> dma_mask will
>>>>>> be u64 set to 0xffffffffffffffff even if we set it to
>>>>>> DMA_BIT_MASK(32) previously.
>>>>> That is what I was missing. Let me include that in the git commit and
>>>>> also
>>>>> put this patch on the stable tree.
>>>> Note that this appears to be a work around for a bug in the sound system
>>>> or Intel HDA device driver which is incorrectly truncating a dma_addr_t
>>>> to a u32.  So by ensuring a DMA_BIT_MASK(32) when the dma_addr_t is
>>>> truncated it still works.
>>>>
>>>> David
>>> Sorry David, I am not completely sure I understand your argument in
>>> favour of a bug in the
>>> sound system or Intel HDA device driver. Could you please elaborate more
>>> in detail about this?
>> The HDA driver claims to support 64-bit DMA addresses, so it should be
>> perfectly fine for the Xen DMA mapping/allocation functions to return
>> DMA addresses > 4 GiB.  For most devices this seems to work just fine.
>>
>> I think that somewhere between the buffer being mapped or allocated and
>> the address being programmed into the hardware, the 64-bit dma_addr_t
>> value is being truncated to 32 bits giving an invalid DMA address.
>>
>> The patch would avoid this by setting the DMA mask to 32-bit and only
>> returning DMA address < 4 GiB which can quite happily be stuffed into a
>> u32 without losing bits.
>>
>> I think it would be useful (without the patch applied) to print the DMA
>> addresses returned by the allocate/mapping functions and the address
>> programmed into the hardware.  It will be easily to spot if it got
>> truncated or not.
> Just enable DMA debug API (CONFIG_DEBUG_DMA_API) and use this fancy module:
>
>
> /*
>   *
>   * This program is free software; you can redistribute it and/or modify
>   * it under the terms of the GNU General Public License v2.0 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.
>   */
>
> #include <linux/module.h>
> #include <linux/string.h>
> #include <linux/types.h>
> #include <linux/init.h>
> #include <linux/stat.h>
> #include <linux/err.h>
> #include <linux/ctype.h>
> #include <linux/slab.h>
> #include <linux/limits.h>
> #include <linux/device.h>
> #include <linux/pci.h>
> #include <linux/blkdev.h>
> #include <linux/device.h>
>
> #include <linux/init.h>
> #include <linux/mm.h>
> #include <linux/fcntl.h>
> #include <linux/slab.h>
> #include <linux/kmod.h>
> #include <linux/major.h>
> #include <linux/highmem.h>
> #include <linux/blkdev.h>
> #include <linux/module.h>
> #include <linux/blkpg.h>
> #include <linux/buffer_head.h>
> #include <linux/mpage.h>
> #include <linux/mount.h>
> #include <linux/uio.h>
> #include <linux/namei.h>
> #include <asm/uaccess.h>
>
> #include <linux/pagemap.h>
> #include <linux/pagevec.h>
>
> #include <linux/dma-debug.h>
>
> #define DUMP_DMA_FUN  "0.1"
>
> MODULE_AUTHOR("Konrad Rzeszutek Wilk <konrad@virtualiron>");
> MODULE_DESCRIPTION("dump dma");
> MODULE_LICENSE("GPL");
> MODULE_VERSION(DUMP_DMA_FUN);
>
> static int __init dump_dma_init(void)
> {
> 	debug_dma_dump_mappings(NULL);
> 	return 0;
> }
>
> static void __exit dump_dma_exit(void)
> {
> }
>
> module_init(dump_dma_init);
> module_exit(dump_dma_exit);
>> David
Hi,
I have just tried to load the dump_dma module, can you observe anything 
from it?

[ 2471.933377] e1000e 0000:00:19.0: single idx 0 P=11d54040 D=21d800040 
L=5f2 DMA_FROM_DEVICE
[ 2471.933380] e1000e 0000:00:19.0: single idx 0 P=11d54740 D=21d800740 
L=5f2 DMA_FROM_DEVICE
[ 2471.933382] e1000e 0000:00:19.0: single idx 4 P=11d5d040 D=21d809040 
L=5f2 DMA_FROM_DEVICE
[ 2471.933384] e1000e 0000:00:19.0: single idx 4 P=11d5d880 D=21d809880 
L=5f2 DMA_FROM_DEVICE
[ 2471.933385] e1000e 0000:00:19.0: single idx 5 P=11d5f040 D=21d80b040 
L=5f2 DMA_FROM_DEVICE
[ 2471.933387] e1000e 0000:00:19.0: single idx 5 P=11d5f740 D=21d80b740 
L=5f2 DMA_FROM_DEVICE
[ 2471.933388] e1000e 0000:00:19.0: single idx 8 P=11d64040 D=21d810040 
L=5f2 DMA_FROM_DEVICE
[ 2471.933390] e1000e 0000:00:19.0: single idx 8 P=11d64740 D=21d810740 
L=5f2 DMA_FROM_DEVICE
[ 2471.933392] e1000e 0000:00:19.0: single idx 21 P=11d7e7c0 D=21d82a7c0 
L=5f2 DMA_FROM_DEVICE
[ 2471.933393] e1000e 0000:00:19.0: single idx 22 P=11d81900 D=21d82d900 
L=5f2 DMA_FROM_DEVICE
[ 2471.933395] e1000e 0000:00:19.0: single idx 23 P=11d82940 D=21d82e940 
L=5f2 DMA_FROM_DEVICE
[ 2471.933396] e1000e 0000:00:19.0: single idx 28 P=1258d040 D=21e039040 
L=5f2 DMA_FROM_DEVICE
[ 2471.933398] e1000e 0000:00:19.0: single idx 33 P=11d96040 D=21d842040 
L=5f2 DMA_FROM_DEVICE
[ 2471.933400] e1000e 0000:00:19.0: single idx 33 P=12596040 D=21e042040 
L=5f2 DMA_FROM_DEVICE
[ 2471.933401] e1000e 0000:00:19.0: single idx 34 P=12599900 D=21e045900 
L=5f2 DMA_FROM_DEVICE
[ 2471.933403] e1000e 0000:00:19.0: single idx 36 P=11d9d040 D=21d849040 
L=5f2 DMA_FROM_DEVICE
[ 2471.933404] e1000e 0000:00:19.0: single idx 36 P=11d9d880 D=21d849880 
L=5f2 DMA_FROM_DEVICE
[ 2471.933406] e1000e 0000:00:19.0: single idx 39 P=125a2040 D=21e04e040 
L=5f2 DMA_FROM_DEVICE
[ 2471.933407] e1000e 0000:00:19.0: single idx 47 P=11db2040 D=21d85e040 
L=5f2 DMA_FROM_DEVICE
[ 2471.933409] e1000e 0000:00:19.0: single idx 49 P=125b6040 D=21e062040 
L=5f2 DMA_FROM_DEVICE
[ 2471.933410] e1000e 0000:00:19.0: single idx 49 P=125b6740 D=21e062740 
L=5f2 DMA_FROM_DEVICE
[ 2471.933412] e1000e 0000:00:19.0: single idx 50 P=125b8040 D=21e064040 
L=5f2 DMA_FROM_DEVICE
[ 2471.933413] e1000e 0000:00:19.0: single idx 51 P=11dba2c0 D=21d8662c0 
L=5f2 DMA_FROM_DEVICE
[ 2471.933415] e1000e 0000:00:19.0: single idx 57 P=11dc7900 D=21d873900 
L=5f2 DMA_FROM_DEVICE
[ 2471.933417] snd_hda_intel 0000:00:1b.0: coherent idx 58 P=11dc8000 
D=21d874000 L=1000 DMA_BIDIRECTIONAL
[ 2471.933419] e1000e 0000:00:19.0: single idx 59 P=11dca040 D=21d876040 
L=5f2 DMA_FROM_DEVICE
[ 2471.933420] e1000e 0000:00:19.0: single idx 59 P=11dca740 D=21d876740 
L=5f2 DMA_FROM_DEVICE
[ 2471.933422] e1000e 0000:00:19.0: single idx 60 P=11dcc040 D=21d878040 
L=5f2 DMA_FROM_DEVICE
[ 2471.933423] e1000e 0000:00:19.0: single idx 60 P=11dcc740 D=21d878740 
L=5f2 DMA_FROM_DEVICE
[ 2471.933425] e1000e 0000:00:19.0: single idx 60 P=11dcd040 D=21d879040 
L=5f2 DMA_FROM_DEVICE
[ 2471.933426] e1000e 0000:00:19.0: single idx 61 P=11dce040 D=21d87a040 
L=5f2 DMA_FROM_DEVICE
[ 2471.933428] e1000e 0000:00:19.0: single idx 61 P=11dce880 D=21d87a880 
L=5f2 DMA_FROM_DEVICE
[ 2471.933429] e1000e 0000:00:19.0: single idx 61 P=11dcf040 D=21d87b040 
L=5f2 DMA_FROM_DEVICE
[ 2471.933431] e1000e 0000:00:19.0: single idx 61 P=11dcf740 D=21d87b740 
L=5f2 DMA_FROM_DEVICE
[ 2471.933432] e1000e 0000:00:19.0: single idx 63 P=125d3040 D=21e07f040 
L=5f2 DMA_FROM_DEVICE
[ 2471.933434] e1000e 0000:00:19.0: single idx 63 P=125d3880 D=21e07f880 
L=5f2 DMA_FROM_DEVICE
[ 2471.933435] e1000e 0000:00:19.0: single idx 70 P=11de0040 D=21d88c040 
L=5f2 DMA_FROM_DEVICE
[ 2471.933437] e1000e 0000:00:19.0: single idx 71 P=2e43d040 D=3208e040 
L=5f2 DMA_FROM_DEVICE
[ 2471.933438] e1000e 0000:00:19.0: single idx 76 P=11dec900 D=21d898900 
L=5f2 DMA_FROM_DEVICE
[ 2471.933440] e1000e 0000:00:19.0: single idx 79 P=125f2240 D=21e09e240 
L=5f2 DMA_FROM_DEVICE
[ 2471.933442] e1000e 0000:00:19.0: single idx 85 P=125fe040 D=21e0aa040 
L=5f2 DMA_FROM_DEVICE
[ 2471.933443] e1000e 0000:00:19.0: single idx 85 P=125fe740 D=21e0aa740 
L=5f2 DMA_FROM_DEVICE
[ 2471.933445] e1000e 0000:00:19.0: single idx 91 P=11e0a840 D=21d8b6840 
L=5f2 DMA_FROM_DEVICE
[ 2471.933446] e1000e 0000:00:19.0: single idx 91 P=11e0a040 D=21d8b6040 
L=5f2 DMA_FROM_DEVICE
[ 2471.933448] e1000e 0000:00:19.0: single idx 94 P=12610040 D=21e0bc040 
L=5f2 DMA_FROM_DEVICE
[ 2471.933449] e1000e 0000:00:19.0: single idx 94 P=12610740 D=21e0bc740 
L=5f2 DMA_FROM_DEVICE
[ 2471.933451] snd_hda_intel 0000:00:1b.0: coherent idx 102 P=11e21000 
D=21d8cd000 L=1000 DMA_BIDIRECTIONAL
[ 2471.933453] e1000e 0000:00:19.0: single idx 104 P=12624040 
D=21e0d0040 L=5f2 DMA_FROM_DEVICE
[ 2471.933454] e1000e 0000:00:19.0: single idx 105 P=11e27040 
D=21d8d3040 L=5f2 DMA_FROM_DEVICE
[ 2471.933456] e1000e 0000:00:19.0: single idx 106 P=11e29040 
D=21d8d5040 L=5f2 DMA_FROM_DEVICE
[ 2471.933459] e1000e 0000:00:19.0: single idx 108 P=1262d900 
D=21e0d9900 L=5f2 DMA_FROM_DEVICE
[ 2471.933460] e1000e 0000:00:19.0: single idx 113 P=11e37880 
D=21d8e3880 L=5f2 DMA_FROM_DEVICE
[ 2471.933462] e1000e 0000:00:19.0: single idx 114 P=11e39040 
D=21d8e5040 L=5f2 DMA_FROM_DEVICE
[ 2471.933463] e1000e 0000:00:19.0: single idx 121 P=12647040 
D=21e0f3040 L=5f2 DMA_FROM_DEVICE
[ 2471.933465] e1000e 0000:00:19.0: single idx 121 P=12647740 
D=21e0f3740 L=5f2 DMA_FROM_DEVICE
[ 2471.933467] snd_hda_intel 0000:00:1b.0: coherent idx 126 P=11e51000 
D=21d8fd000 L=1000 DMA_BIDIRECTIONAL
[ 2471.933468] e1000e 0000:00:19.0: single idx 126 P=11e50040 
D=21d8fc040 L=5f2 DMA_FROM_DEVICE
[ 2471.933470] e1000e 0000:00:19.0: single idx 127 P=12653040 
D=21e0ff040 L=5f2 DMA_FROM_DEVICE
[ 2471.933471] e1000e 0000:00:19.0: single idx 127 P=11e53840 
D=21d8ff840 L=5f2 DMA_FROM_DEVICE
[ 2471.933473] e1000e 0000:00:19.0: single idx 133 P=11e5f040 
D=21d90b040 L=5f2 DMA_FROM_DEVICE
[ 2471.933474] e1000e 0000:00:19.0: single idx 139 P=11e6b040 
D=21d917040 L=5f2 DMA_FROM_DEVICE
[ 2471.933476] e1000e 0000:00:19.0: single idx 139 P=11e6b880 
D=21d917880 L=5f2 DMA_FROM_DEVICE
[ 2471.933478] e1000e 0000:00:19.0: single idx 143 P=11e73040 
D=21d91f040 L=5f2 DMA_FROM_DEVICE
[ 2471.933479] e1000e 0000:00:19.0: single idx 145 P=11e76040 
D=21d922040 L=5f2 DMA_FROM_DEVICE
[ 2471.933480] e1000e 0000:00:19.0: single idx 146 P=11e78040 
D=21d924040 L=5f2 DMA_FROM_DEVICE
[ 2471.933482] e1000e 0000:00:19.0: single idx 147 P=11e7b900 
D=21d927900 L=5f2 DMA_FROM_DEVICE
[ 2471.933483] e1000e 0000:00:19.0: single idx 148 P=11e7c040 
D=21d928040 L=5f2 DMA_FROM_DEVICE
[ 2471.933485] e1000e 0000:00:19.0: single idx 148 P=2e5a2040 D=32129040 
L=5f2 DMA_FROM_DEVICE
[ 2471.933487] e1000e 0000:00:19.0: single idx 148 P=2e5a2740 D=32129740 
L=5f2 DMA_FROM_DEVICE
[ 2471.933488] e1000e 0000:00:19.0: single idx 154 P=12689040 
D=21e135040 L=5f2 DMA_FROM_DEVICE
[ 2471.933490] e1000e 0000:00:19.0: single idx 154 P=11e89040 
D=21d935040 L=5f2 DMA_FROM_DEVICE
[ 2471.933491] e1000e 0000:00:19.0: single idx 156 P=2e593180 D=32138180 
L=5f2 DMA_FROM_DEVICE
[ 2471.933493] e1000e 0000:00:19.0: single idx 161 P=11e97740 
D=21d943740 L=5f2 DMA_FROM_DEVICE
[ 2471.933494] e1000e 0000:00:19.0: single idx 170 P=126a8040 
D=21e154040 L=5f2 DMA_FROM_DEVICE
[ 2471.933496] snd_hda_intel 0000:00:1b.0: coherent idx 185 P=11ec7000 
D=21d973000 L=1000 DMA_BIDIRECTIONAL
[ 2471.933498] e1000e 0000:00:19.0: single idx 190 P=126d1040 
D=21e17d040 L=5f2 DMA_FROM_DEVICE
[ 2471.933499] e1000e 0000:00:19.0: single idx 193 P=126d6040 
D=21e182040 L=5f2 DMA_FROM_DEVICE
[ 2471.933501] e1000e 0000:00:19.0: single idx 193 P=126d6740 
D=21e182740 L=5f2 DMA_FROM_DEVICE
[ 2471.933502] e1000e 0000:00:19.0: single idx 193 P=11ed7040 
D=21d983040 L=5f2 DMA_FROM_DEVICE
[ 2471.933504] e1000e 0000:00:19.0: single idx 193 P=11ed7880 
D=21d983880 L=5f2 DMA_FROM_DEVICE
[ 2471.933505] snd_hda_intel 0000:00:1b.0: coherent idx 195 P=11eda000 
D=21d986000 L=1000 DMA_BIDIRECTIONAL
[ 2471.933507] e1000e 0000:00:19.0: single idx 196 P=126dd7c0 
D=21e1897c0 L=5f2 DMA_FROM_DEVICE
[ 2471.933508] e1000e 0000:00:19.0: single idx 197 P=11edf880 
D=21d98b880 L=5f2 DMA_FROM_DEVICE
[ 2471.933510] e1000e 0000:00:19.0: single idx 197 P=126de740 
D=21e18a740 L=5f2 DMA_FROM_DEVICE
[ 2471.933512] e1000e 0000:00:19.0: coherent idx 203 P=126ea000 
D=21e196000 L=2000 DMA_BIDIRECTIONAL
[ 2471.933513] e1000e 0000:00:19.0: single idx 206 P=126f0040 
D=21e19c040 L=5f2 DMA_FROM_DEVICE
[ 2471.933515] e1000e 0000:00:19.0: single idx 210 P=11ef8040 
D=21d9a4040 L=5f2 DMA_FROM_DEVICE
[ 2471.933516] e1000e 0000:00:19.0: single idx 211 P=11efb840 
D=21d9a7840 L=5f2 DMA_FROM_DEVICE
[ 2471.933518] e1000e 0000:00:19.0: single idx 211 P=11efb040 
D=21d9a7040 L=5f2 DMA_FROM_DEVICE
[ 2471.933519] e1000e 0000:00:19.0: single idx 213 P=11eff180 
D=21d9ab180 L=5f2 DMA_FROM_DEVICE
[ 2471.933521] e1000e 0000:00:19.0: single idx 215 P=11f03180 
D=21d9af180 L=5f2 DMA_FROM_DEVICE
[ 2471.933522] e1000e 0000:00:19.0: single idx 215 P=11f03880 
D=21d9af880 L=5f2 DMA_FROM_DEVICE
[ 2471.933524] e1000e 0000:00:19.0: single idx 215 P=12703040 
D=21e1af040 L=5f2 DMA_FROM_DEVICE
[ 2471.933525] e1000e 0000:00:19.0: single idx 215 P=12703740 
D=21e1af740 L=5f2 DMA_FROM_DEVICE
[ 2471.933527] e1000e 0000:00:19.0: single idx 222 P=12711040 
D=21e1bd040 L=5f2 DMA_FROM_DEVICE
[ 2471.933528] e1000e 0000:00:19.0: single idx 226 P=11f19040 
D=21d9c5040 L=5f2 DMA_FROM_DEVICE
[ 2471.933530] e1000e 0000:00:19.0: single idx 226 P=11f19880 
D=21d9c5880 L=5f2 DMA_FROM_DEVICE
[ 2471.933531] e1000e 0000:00:19.0: single idx 233 P=11f27040 
D=21d9d3040 L=5f2 DMA_FROM_DEVICE
[ 2471.933533] e1000e 0000:00:19.0: single idx 238 P=12731400 
D=21e1dd400 L=5f2 DMA_FROM_DEVICE
[ 2471.933535] ehci_hcd 0000:00:1a.0: single idx 240 P=12631f20 D=1e1800 
L=1 DMA_FROM_DEVICE
[ 2471.933536] e1000e 0000:00:19.0: single idx 245 P=1273e180 
D=21e1ea180 L=5f2 DMA_FROM_DEVICE
[ 2471.933538] e1000e 0000:00:19.0: single idx 246 P=11f41040 
D=21d9ed040 L=5f2 DMA_FROM_DEVICE
[ 2471.933539] e1000e 0000:00:19.0: single idx 247 P=12742040 
D=21e1ee040 L=5f2 DMA_FROM_DEVICE
[ 2471.933541] e1000e 0000:00:19.0: single idx 249 P=12746840 
D=21e1f2840 L=5f2 DMA_FROM_DEVICE
[ 2471.933542] e1000e 0000:00:19.0: single idx 258 P=12759040 
D=21e205040 L=5f2 DMA_FROM_DEVICE
[ 2471.933544] e1000e 0000:00:19.0: single idx 270 P=127712c0 
D=21e21d2c0 L=5f2 DMA_FROM_DEVICE
[ 2471.933546] e1000e 0000:00:19.0: single idx 271 P=12772040 
D=21e21e040 L=5f2 DMA_FROM_DEVICE
[ 2471.933547] e1000e 0000:00:19.0: single idx 271 P=12773180 
D=21e21f180 L=5f2 DMA_FROM_DEVICE
[ 2471.933549] e1000e 0000:00:19.0: single idx 273 P=12776040 
D=21e222040 L=5f2 DMA_FROM_DEVICE
[ 2471.933550] e1000e 0000:00:19.0: single idx 280 P=12784040 
D=21e230040 L=5f2 DMA_FROM_DEVICE
[ 2471.933552] e1000e 0000:00:19.0: single idx 280 P=12784880 
D=21e230880 L=5f2 DMA_FROM_DEVICE
[ 2471.933554] e1000e 0000:00:19.0: single idx 284 P=1278c900 
D=21e238900 L=5f2 DMA_FROM_DEVICE
[ 2471.933555] e1000e 0000:00:19.0: single idx 286 P=12790040 
D=21e23c040 L=5f2 DMA_FROM_DEVICE
[ 2471.933557] e1000e 0000:00:19.0: single idx 286 P=12790880 
D=21e23c880 L=5f2 DMA_FROM_DEVICE
[ 2471.933558] e1000e 0000:00:19.0: single idx 299 P=127aa040 
D=21e256040 L=5f2 DMA_FROM_DEVICE
[ 2471.933560] e1000e 0000:00:19.0: single idx 299 P=127ab040 
D=21e257040 L=5f2 DMA_FROM_DEVICE
[ 2471.933561] e1000e 0000:00:19.0: single idx 299 P=127ab740 
D=21e257740 L=5f2 DMA_FROM_DEVICE
[ 2471.933563] e1000e 0000:00:19.0: single idx 307 P=127ba040 
D=21e266040 L=5f2 DMA_FROM_DEVICE
[ 2471.933565] e1000e 0000:00:19.0: single idx 313 P=127c7840 
D=21e273840 L=5f2 DMA_FROM_DEVICE
[ 2471.933566] e1000e 0000:00:19.0: single idx 313 P=127c7040 
D=21e273040 L=5f2 DMA_FROM_DEVICE
[ 2471.933568] e1000e 0000:00:19.0: single idx 324 P=127dd040 
D=21e289040 L=5f2 DMA_FROM_DEVICE
[ 2471.933569] e1000e 0000:00:19.0: single idx 334 P=127f0180 
D=21e29c180 L=5f2 DMA_FROM_DEVICE
[ 2471.933571] e1000e 0000:00:19.0: single idx 334 P=127f0880 
D=21e29c880 L=5f2 DMA_FROM_DEVICE
[ 2471.933572] e1000e 0000:00:19.0: single idx 336 P=127f4840 
D=21e2a0840 L=5f2 DMA_FROM_DEVICE
[ 2471.933574] e1000e 0000:00:19.0: single idx 342 P=12000040 
D=21daac040 L=5f2 DMA_FROM_DEVICE
[ 2471.933576] e1000e 0000:00:19.0: single idx 342 P=12000740 
D=21daac740 L=5f2 DMA_FROM_DEVICE
[ 2471.933578] e1000e 0000:00:19.0: single idx 370 P=12039040 
D=21dae5040 L=5f2 DMA_FROM_DEVICE
[ 2471.933579] e1000e 0000:00:19.0: single idx 371 P=1203a040 
D=21dae6040 L=5f2 DMA_FROM_DEVICE
[ 2471.933581] e1000e 0000:00:19.0: single idx 371 P=1203a880 
D=21dae6880 L=5f2 DMA_FROM_DEVICE
[ 2471.933582] e1000e 0000:00:19.0: single idx 375 P=12043880 
D=21daef880 L=5f2 DMA_FROM_DEVICE
[ 2471.933584] e1000e 0000:00:19.0: single idx 386 P=12058180 
D=21db04180 L=5f2 DMA_FROM_DEVICE
[ 2471.933586] e1000e 0000:00:19.0: single idx 393 P=12067540 
D=21db13540 L=5f2 DMA_FROM_DEVICE
[ 2471.933587] e1000e 0000:00:19.0: single idx 395 P=1206a7c0 
D=21db167c0 L=5f2 DMA_FROM_DEVICE
[ 2471.933589] e1000e 0000:00:19.0: single idx 396 P=1206c880 
D=21db18880 L=5f2 DMA_FROM_DEVICE
[ 2471.933590] e1000e 0000:00:19.0: single idx 408 P=12084180 
D=21db30180 L=5f2 DMA_FROM_DEVICE
[ 2471.933592] e1000e 0000:00:19.0: single idx 431 P=118b3740 
D=21d35f740 L=5f2 DMA_FROM_DEVICE
[ 2471.933594] e1000e 0000:00:19.0: single idx 434 P=118b9900 
D=21d365900 L=5f2 DMA_FROM_DEVICE
[ 2471.933596] snd_hda_intel 0000:00:1b.0: coherent idx 436 P=120bc000 
D=21db68000 L=1000 DMA_BIDIRECTIONAL
[ 2471.933597] e1000e 0000:00:19.0: single idx 436 P=118bd040 
D=21d369040 L=5f2 DMA_FROM_DEVICE
[ 2471.933599] e1000e 0000:00:19.0: single idx 458 P=120e8040 
D=21db94040 L=5f2 DMA_FROM_DEVICE
[ 2471.933600] e1000e 0000:00:19.0: single idx 458 P=120e8740 
D=21db94740 L=5f2 DMA_FROM_DEVICE
[ 2471.933602] e1000e 0000:00:19.0: single idx 459 P=120eb040 
D=21db97040 L=5f2 DMA_FROM_DEVICE
[ 2471.933603] e1000e 0000:00:19.0: single idx 459 P=120eb880 
D=21db97880 L=5f2 DMA_FROM_DEVICE
[ 2471.933605] snd_hda_intel 0000:00:1b.0: coherent idx 462 P=118f0000 
D=21d39c000 L=10000 DMA_BIDIRECTIONAL
[ 2471.933607] snd_hda_intel 0000:00:1b.0: coherent idx 470 P=11900000 
D=21d3ac000 L=10000 DMA_BIDIRECTIONAL
[ 2471.933608] e1000e 0000:00:19.0: single idx 470 P=12101040 
D=21dbad040 L=5f2 DMA_FROM_DEVICE
[ 2471.933610] e1000e 0000:00:19.0: single idx 470 P=12101880 
D=21dbad880 L=5f2 DMA_FROM_DEVICE
[ 2471.933612] snd_hda_intel 0000:00:1b.0: coherent idx 478 P=11910000 
D=21d3bc000 L=10000 DMA_BIDIRECTIONAL
[ 2471.933613] snd_hda_intel 0000:00:1b.0: coherent idx 486 P=11920000 
D=21d3cc000 L=10000 DMA_BIDIRECTIONAL
[ 2471.933615] snd_hda_intel 0000:00:1b.0: coherent idx 494 P=11930000 
D=21d3dc000 L=10000 DMA_BIDIRECTIONAL
[ 2471.933617] e1000e 0000:00:19.0: single idx 498 P=12139040 
D=21dbe5040 L=5f2 DMA_FROM_DEVICE
[ 2471.933618] e1000e 0000:00:19.0: single idx 502 P=11940040 
D=21d3ec040 L=5f2 DMA_FROM_DEVICE
[ 2471.933620] e1000e 0000:00:19.0: single idx 503 P=11942040 
D=21d3ee040 L=5f2 DMA_FROM_DEVICE
[ 2471.933621] e1000e 0000:00:19.0: single idx 503 P=11943740 
D=21d3ef740 L=5f2 DMA_FROM_DEVICE
[ 2471.933623] e1000e 0000:00:19.0: single idx 508 P=1214c040 
D=21dbf8040 L=5f2 DMA_FROM_DEVICE
[ 2471.933624] e1000e 0000:00:19.0: single idx 508 P=1214c940 
D=21dbf8940 L=5f2 DMA_FROM_DEVICE
[ 2471.933626] e1000e 0000:00:19.0: single idx 524 P=1196c840 
D=21d418840 L=5f2 DMA_FROM_DEVICE
[ 2471.933628] e1000e 0000:00:19.0: single idx 530 P=11978040 
D=21d424040 L=5f2 DMA_FROM_DEVICE
[ 2471.933629] e1000e 0000:00:19.0: single idx 536 P=11984040 
D=21d430040 L=5f2 DMA_FROM_DEVICE
[ 2471.933631] e1000e 0000:00:19.0: single idx 537 P=11986040 
D=21d432040 L=5f2 DMA_FROM_DEVICE
[ 2471.933632] e1000e 0000:00:19.0: single idx 540 P=1218c680 
D=21dc38680 L=5f2 DMA_FROM_DEVICE
[ 2471.933634] e1000e 0000:00:19.0: single idx 545 P=12196180 
D=21dc42180 L=5f2 DMA_FROM_DEVICE
[ 2471.933635] e1000e 0000:00:19.0: single idx 546 P=11998040 
D=21d444040 L=5f2 DMA_FROM_DEVICE
[ 2471.933637] e1000e 0000:00:19.0: single idx 548 P=1199d040 
D=21d449040 L=5f2 DMA_FROM_DEVICE
[ 2471.933639] e1000e 0000:00:19.0: single idx 554 P=119a8400 
D=21d454400 L=5f2 DMA_FROM_DEVICE
[ 2471.933640] e1000e 0000:00:19.0: single idx 557 P=119af040 
D=21d45b040 L=5f2 DMA_FROM_DEVICE
[ 2471.933642] e1000e 0000:00:19.0: single idx 565 P=121bf180 
D=21dc6b180 L=5f2 DMA_FROM_DEVICE
[ 2471.933643] e1000e 0000:00:19.0: single idx 579 P=119db240 
D=21d487240 L=5f2 DMA_FROM_DEVICE
[ 2471.933646] ahci 0000:00:1f.2: coherent idx 582 P=121e0000 
D=21dc8c000 L=16500 DMA_BIDIRECTIONAL
[ 2471.933648] ahci 0000:00:1f.2: coherent idx 598 P=12200000 
D=21dcac000 L=16500 DMA_BIDIRECTIONAL
[ 2471.933649] e1000e 0000:00:19.0: single idx 600 P=11a04040 
D=21d4b0040 L=5f2 DMA_FROM_DEVICE
[ 2471.933651] e1000e 0000:00:19.0: single idx 600 P=11a04880 
D=21d4b0880 L=5f2 DMA_FROM_DEVICE
[ 2471.933652] e1000e 0000:00:19.0: single idx 605 P=11a0e040 
D=21d4ba040 L=5f2 DMA_FROM_DEVICE
[ 2471.933654] e1000e 0000:00:19.0: single idx 609 P=11a17040 
D=21d4c3040 L=5f2 DMA_FROM_DEVICE
[ 2471.933655] e1000e 0000:00:19.0: single idx 609 P=11a17740 
D=21d4c3740 L=5f2 DMA_FROM_DEVICE
[ 2471.933657] ahci 0000:00:1f.2: coherent idx 614 P=12220000 
D=21dccc000 L=16500 DMA_BIDIRECTIONAL
[ 2471.933658] e1000e 0000:00:19.0: single idx 616 P=11a25040 
D=21d4d1040 L=5f2 DMA_FROM_DEVICE
[ 2471.933660] e1000e 0000:00:19.0: single idx 617 P=11a26040 
D=21d4d2040 L=5f2 DMA_FROM_DEVICE
[ 2471.933661] e1000e 0000:00:19.0: single idx 622 P=11a31740 
D=21d4dd740 L=5f2 DMA_FROM_DEVICE
[ 2471.933663] e1000e 0000:00:19.0: single idx 632 P=11a44180 
D=21d4f0180 L=5f2 DMA_FROM_DEVICE
[ 2471.933665] e1000e 0000:00:19.0: single idx 634 P=122492c0 
D=21dcf52c0 L=5f2 DMA_FROM_DEVICE
[ 2471.933666] e1000e 0000:00:19.0: single idx 636 P=11a4d040 
D=21d4f9040 L=5f2 DMA_FROM_DEVICE
[ 2471.933668] e1000e 0000:00:19.0: single idx 636 P=11a4d740 
D=21d4f9740 L=5f2 DMA_FROM_DEVICE
[ 2471.933669] e1000e 0000:00:19.0: single idx 645 P=11a5f400 
D=21d50b400 L=5f2 DMA_FROM_DEVICE
[ 2471.933671] e1000e 0000:00:19.0: single idx 647 P=12263040 
D=21dd0f040 L=5f2 DMA_FROM_DEVICE
[ 2471.933672] e1000e 0000:00:19.0: single idx 647 P=12263740 
D=21dd0f740 L=5f2 DMA_FROM_DEVICE
[ 2471.933674] e1000e 0000:00:19.0: single idx 648 P=12264900 
D=21dd10900 L=5f2 DMA_FROM_DEVICE
[ 2471.933675] e1000e 0000:00:19.0: single idx 651 P=11a6a040 
D=21d516040 L=5f2 DMA_FROM_DEVICE
[ 2471.933677] e1000e 0000:00:19.0: single idx 654 P=12270440 
D=21dd1c440 L=5f2 DMA_FROM_DEVICE
[ 2471.933679] e1000e 0000:00:19.0: single idx 663 P=11a83040 
D=21d52f040 L=5f2 DMA_FROM_DEVICE
[ 2471.933680] e1000e 0000:00:19.0: single idx 663 P=11a83740 
D=21d52f740 L=5f2 DMA_FROM_DEVICE
[ 2471.933682] snd_hda_intel 0000:00:1b.0: coherent idx 675 P=1229b000 
D=21dd47000 L=1000 DMA_BIDIRECTIONAL
[ 2471.933683] e1000e 0000:00:19.0: single idx 677 P=11a9f040 
D=21d54b040 L=5f2 DMA_FROM_DEVICE
[ 2471.933685] e1000e 0000:00:19.0: single idx 677 P=11a9f740 
D=21d54b740 L=5f2 DMA_FROM_DEVICE
[ 2471.933686] e1000e 0000:00:19.0: single idx 678 P=11aa0040 
D=21d54c040 L=5f2 DMA_FROM_DEVICE
[ 2471.933688] e1000e 0000:00:19.0: single idx 678 P=11aa0740 
D=21d54c740 L=5f2 DMA_FROM_DEVICE
[ 2471.933690] e1000e 0000:00:19.0: single idx 683 P=122ab040 
D=21dd57040 L=5f2 DMA_FROM_DEVICE
[ 2471.933691] e1000e 0000:00:19.0: single idx 685 P=11aaf040 
D=21d55b040 L=5f2 DMA_FROM_DEVICE
[ 2471.933693] e1000e 0000:00:19.0: single idx 687 P=122b22c0 
D=21dd5e2c0 L=5f2 DMA_FROM_DEVICE
[ 2471.933694] e1000e 0000:00:19.0: single idx 688 P=11ab5840 
D=21d561840 L=5f2 DMA_FROM_DEVICE
[ 2471.933696] e1000e 0000:00:19.0: single idx 688 P=11ab5040 
D=21d561040 L=5f2 DMA_FROM_DEVICE
[ 2471.933697] e1000e 0000:00:19.0: single idx 688 P=11ab4040 
D=21d560040 L=5f2 DMA_FROM_DEVICE
[ 2471.933698] e1000e 0000:00:19.0: single idx 688 P=11ab4880 
D=21d560880 L=5f2 DMA_FROM_DEVICE
[ 2471.933700] e1000e 0000:00:19.0: single idx 690 P=11ab9040 
D=21d565040 L=5f2 DMA_FROM_DEVICE
[ 2471.933702] e1000e 0000:00:19.0: single idx 702 P=122d1840 
D=21dd7d840 L=5f2 DMA_FROM_DEVICE
[ 2471.933703] e1000e 0000:00:19.0: single idx 703 P=122d3040 
D=21dd7f040 L=5f2 DMA_FROM_DEVICE
[ 2471.933705] e1000e 0000:00:19.0: single idx 703 P=11ad3740 
D=21d57f740 L=5f2 DMA_FROM_DEVICE
[ 2471.933706] e1000e 0000:00:19.0: single idx 711 P=11ae3400 
D=21d58f400 L=5f2 DMA_FROM_DEVICE
[ 2471.933708] e1000e 0000:00:19.0: single idx 715 P=122ea040 
D=21dd96040 L=5f2 DMA_FROM_DEVICE
[ 2471.933709] e1000e 0000:00:19.0: single idx 716 P=11aed040 
D=21d599040 L=5f2 DMA_FROM_DEVICE
[ 2471.933711] e1000e 0000:00:19.0: single idx 719 P=122f2740 
D=21dd9e740 L=5f2 DMA_FROM_DEVICE
[ 2471.933712] e1000e 0000:00:19.0: single idx 722 P=122f9040 
D=21dda5040 L=5f2 DMA_FROM_DEVICE
[ 2471.933714] e1000e 0000:00:19.0: single idx 722 P=122f8040 
D=21dda4040 L=5f2 DMA_FROM_DEVICE
[ 2471.933715] e1000e 0000:00:19.0: single idx 722 P=122f8880 
D=21dda4880 L=5f2 DMA_FROM_DEVICE
[ 2471.933717] e1000e 0000:00:19.0: single idx 744 P=12324540 
D=21ddd0540 L=5f2 DMA_FROM_DEVICE
[ 2471.933719] e1000e 0000:00:19.0: single idx 747 P=1232a040 
D=21ddd6040 L=5f2 DMA_FROM_DEVICE
[ 2471.933720] e1000e 0000:00:19.0: single idx 747 P=1232a740 
D=21ddd6740 L=5f2 DMA_FROM_DEVICE
[ 2471.933722] ehci_hcd 0000:00:1d.0: coherent idx 752 P=1267e000 
D=325e1000 L=1000 DMA_BIDIRECTIONAL
[ 2471.933724] ehci_hcd 0000:00:1d.0: coherent idx 752 P=125af000 
D=325e0000 L=1000 DMA_BIDIRECTIONAL
[ 2471.933725] ehci_hcd 0000:00:1a.0: coherent idx 753 P=1266f000 
D=325e3000 L=1000 DMA_BIDIRECTIONAL
[ 2471.933727] ehci_hcd 0000:00:1d.0: coherent idx 753 P=120a3000 
D=325e2000 L=1000 DMA_BIDIRECTIONAL
[ 2471.933728] e1000e 0000:00:19.0: single idx 753 P=12336740 
D=21dde2740 L=5f2 DMA_FROM_DEVICE
[ 2471.933730] ehci_hcd 0000:00:1a.0: coherent idx 754 P=125ad000 
D=325e5000 L=1000 DMA_BIDIRECTIONAL
[ 2471.933731] ehci_hcd 0000:00:1a.0: coherent idx 754 P=12097000 
D=325e4000 L=1000 DMA_BIDIRECTIONAL
[ 2471.933733] e1000e 0000:00:19.0: single idx 755 P=1233b900 
D=21dde7900 L=5f2 DMA_FROM_DEVICE
[ 2471.933735] xhci_hcd 0000:00:14.0: coherent idx 756 P=126cd000 
D=365e9000 L=1000 DMA_BIDIRECTIONAL
[ 2471.933736] xhci_hcd 0000:00:14.0: coherent idx 756 P=120c1000 
D=365e8000 L=1000 DMA_BIDIRECTIONAL
[ 2471.933738] xhci_hcd 0000:00:14.0: coherent idx 757 P=12164000 
D=365eb000 L=80 DMA_BIDIRECTIONAL
[ 2471.933739] xhci_hcd 0000:00:14.0: coherent idx 757 P=1262e000 
D=365ea000 L=1000 DMA_BIDIRECTIONAL
[ 2471.933741] xhci_hcd 0000:00:14.0: coherent idx 758 P=1266b000 
D=365ed000 L=1000 DMA_BIDIRECTIONAL
[ 2471.933742] xhci_hcd 0000:00:14.0: coherent idx 758 P=12163000 
D=365ec000 L=10 DMA_BIDIRECTIONAL
[ 2471.933744] xhci_hcd 0000:00:14.0: coherent idx 759 P=12633000 
D=365ef000 L=808 DMA_BIDIRECTIONAL
[ 2471.933745] xhci_hcd 0000:00:14.0: coherent idx 759 P=12720000 
D=365ee000 L=1000 DMA_BIDIRECTIONAL
[ 2471.933747] xhci_hcd 0000:00:14.0: coherent idx 761 P=1263e000 
D=365f3000 L=1000 DMA_BIDIRECTIONAL
[ 2471.933749] xhci_hcd 0000:00:14.0: coherent idx 762 P=1268e000 
D=365f5000 L=1000 DMA_BIDIRECTIONAL
[ 2471.933750] xhci_hcd 0000:00:14.0: coherent idx 762 P=120c2000 
D=365f4000 L=1000 DMA_BIDIRECTIONAL
[ 2471.933752] xhci_hcd 0000:00:14.0: coherent idx 763 P=127d6000 
D=365f7000 L=1000 DMA_BIDIRECTIONAL
[ 2471.933753] xhci_hcd 0000:00:14.0: coherent idx 763 P=127d7000 
D=365f6000 L=1000 DMA_BIDIRECTIONAL
[ 2471.933755] xhci_hcd 0000:00:14.0: coherent idx 764 P=127d0000 
D=365f9000 L=1000 DMA_BIDIRECTIONAL
[ 2471.933756] xhci_hcd 0000:00:14.0: coherent idx 764 P=12148000 
D=365f8000 L=1000 DMA_BIDIRECTIONAL
[ 2471.933758] e1000e 0000:00:19.0: single idx 764 P=1234c400 
D=21ddf8400 L=5f2 DMA_FROM_DEVICE
[ 2471.933759] xhci_hcd 0000:00:14.0: coherent idx 765 P=12160000 
D=365fb000 L=1000 DMA_BIDIRECTIONAL
[ 2471.933761] xhci_hcd 0000:00:14.0: coherent idx 765 P=120fe000 
D=365fa000 L=1000 DMA_BIDIRECTIONAL
[ 2471.933762] xhci_hcd 0000:00:14.0: coherent idx 766 P=12162000 
D=365fd000 L=1000 DMA_BIDIRECTIONAL
[ 2471.933764] xhci_hcd 0000:00:14.0: coherent idx 766 P=1217b000 
D=365fc000 L=1000 DMA_BIDIRECTIONAL
[ 2471.933765] xhci_hcd 0000:00:14.0: coherent idx 767 P=125cb000 
D=365ff000 L=1000 DMA_BIDIRECTIONAL
[ 2471.933767] xhci_hcd 0000:00:14.0: coherent idx 767 P=12748000 
D=365fe000 L=1000 DMA_BIDIRECTIONAL
[ 2471.933769] e1000e 0000:00:19.0: single idx 783 P=12373400 
D=21de1f400 L=5f2 DMA_FROM_DEVICE
[ 2471.933770] e1000e 0000:00:19.0: single idx 793 P=12386840 
D=21de32840 L=5f2 DMA_FROM_DEVICE
[ 2471.933772] e1000e 0000:00:19.0: single idx 794 P=12388840 
D=21de34840 L=5f2 DMA_FROM_DEVICE
[ 2471.933773] e1000e 0000:00:19.0: single idx 794 P=12389740 
D=21de35740 L=5f2 DMA_FROM_DEVICE
[ 2471.933775] e1000e 0000:00:19.0: single idx 797 P=1238f040 
D=21de3b040 L=5f2 DMA_FROM_DEVICE
[ 2471.933776] e1000e 0000:00:19.0: single idx 797 P=1238f880 
D=21de3b880 L=5f2 DMA_FROM_DEVICE
[ 2471.933778] e1000e 0000:00:19.0: single idx 801 P=12397040 
D=21de43040 L=5f2 DMA_FROM_DEVICE
[ 2471.933779] e1000e 0000:00:19.0: single idx 801 P=12397880 
D=21de43880 L=5f2 DMA_FROM_DEVICE
[ 2471.933781] e1000e 0000:00:19.0: single idx 812 P=123ac040 
D=21de58040 L=5f2 DMA_FROM_DEVICE
[ 2471.933783] e1000e 0000:00:19.0: single idx 814 P=123b0040 
D=21de5c040 L=5f2 DMA_FROM_DEVICE
[ 2471.933784] snd_hda_intel 0000:00:1b.0: coherent idx 817 P=123b6000 
D=21de62000 L=1000 DMA_BIDIRECTIONAL
[ 2471.933786] snd_hda_intel 0000:00:1b.0: coherent idx 821 P=123be000 
D=21de6a000 L=1000 DMA_BIDIRECTIONAL
[ 2471.933787] e1000e 0000:00:19.0: single idx 823 P=123c2740 
D=21de6e740 L=5f2 DMA_FROM_DEVICE
[ 2471.933789] e1000e 0000:00:19.0: single idx 843 P=123ea500 
D=21de96500 L=5f2 DMA_FROM_DEVICE
[ 2471.933791] e1000e 0000:00:19.0: single idx 844 P=123ed900 
D=21de99900 L=5f2 DMA_FROM_DEVICE
[ 2471.933792] e1000e 0000:00:19.0: single idx 845 P=123ef740 
D=21de9b740 L=5f2 DMA_FROM_DEVICE
[ 2471.933794] e1000e 0000:00:19.0: single idx 847 P=123f3740 
D=21de9f740 L=5f2 DMA_FROM_DEVICE
[ 2471.933795] e1000e 0000:00:19.0: single idx 848 P=123f5040 
D=21dea1040 L=5f2 DMA_FROM_DEVICE
[ 2471.933797] e1000e 0000:00:19.0: single idx 848 P=123f5880 
D=21dea1880 L=5f2 DMA_FROM_DEVICE
[ 2471.933798] e1000e 0000:00:19.0: single idx 851 P=123fa7c0 
D=21dea67c0 L=5f2 DMA_FROM_DEVICE
[ 2471.933800] e1000e 0000:00:19.0: coherent idx 855 P=11c02000 
D=21d6ae000 L=1000 DMA_BIDIRECTIONAL
[ 2471.933802] e1000e 0000:00:19.0: single idx 865 P=11c16040 
D=21d6c2040 L=5f2 DMA_FROM_DEVICE
[ 2471.933803] e1000e 0000:00:19.0: single idx 870 P=11c21540 
D=21d6cd540 L=5f2 DMA_FROM_DEVICE
[ 2471.933805] e1000e 0000:00:19.0: single idx 871 P=11c23840 
D=21d6cf840 L=5f2 DMA_FROM_DEVICE
[ 2471.933806] e1000e 0000:00:19.0: single idx 871 P=11c23040 
D=21d6cf040 L=5f2 DMA_FROM_DEVICE
[ 2471.933808] e1000e 0000:00:19.0: single idx 885 P=11c3e840 
D=21d6ea840 L=5f2 DMA_FROM_DEVICE
[ 2471.933809] e1000e 0000:00:19.0: single idx 885 P=11c3e040 
D=21d6ea040 L=5f2 DMA_FROM_DEVICE
[ 2471.933811] e1000e 0000:00:19.0: single idx 889 P=11c46180 
D=21d6f2180 L=5f2 DMA_FROM_DEVICE
[ 2471.933813] e1000e 0000:00:19.0: single idx 893 P=11c4e040 
D=21d6fa040 L=5f2 DMA_FROM_DEVICE
[ 2471.933814] e1000e 0000:00:19.0: single idx 897 P=11c56040 
D=21d702040 L=5f2 DMA_FROM_DEVICE
[ 2471.933816] e1000e 0000:00:19.0: single idx 902 P=12460040 
D=21df0c040 L=5f2 DMA_FROM_DEVICE
[ 2471.933817] e1000e 0000:00:19.0: single idx 902 P=12460740 
D=21df0c740 L=5f2 DMA_FROM_DEVICE
[ 2471.933819] e1000e 0000:00:19.0: single idx 910 P=11c71900 
D=21d71d900 L=5f2 DMA_FROM_DEVICE
[ 2471.933820] e1000e 0000:00:19.0: single idx 911 P=11c73180 
D=21d71f180 L=5f2 DMA_FROM_DEVICE
[ 2471.933822] e1000e 0000:00:19.0: single idx 916 P=11c7d7c0 
D=21d7297c0 L=5f2 DMA_FROM_DEVICE
[ 2471.933824] e1000e 0000:00:19.0: single idx 926 P=11c90040 
D=21d73c040 L=5f2 DMA_FROM_DEVICE
[ 2471.933825] e1000e 0000:00:19.0: single idx 931 P=11c9b040 
D=21d747040 L=5f2 DMA_FROM_DEVICE
[ 2471.933827] e1000e 0000:00:19.0: single idx 939 P=11caa040 
D=21d756040 L=5f2 DMA_FROM_DEVICE
[ 2471.933828] e1000e 0000:00:19.0: single idx 939 P=11caa740 
D=21d756740 L=5f2 DMA_FROM_DEVICE
[ 2471.933830] e1000e 0000:00:19.0: single idx 940 P=11cac400 
D=21d758400 L=5f2 DMA_FROM_DEVICE
[ 2471.933831] snd_hda_intel 0000:00:1b.0: coherent idx 941 P=11caf000 
D=21d75b000 L=1000 DMA_BIDIRECTIONAL
[ 2471.933833] e1000e 0000:00:19.0: single idx 953 P=11cc7040 
D=21d773040 L=5f2 DMA_FROM_DEVICE
[ 2471.933835] e1000e 0000:00:19.0: single idx 960 P=11cd5040 
D=21d781040 L=5f2 DMA_FROM_DEVICE
[ 2471.933836] e1000e 0000:00:19.0: single idx 960 P=11cd5880 
D=21d781880 L=5f2 DMA_FROM_DEVICE
[ 2471.933838] e1000e 0000:00:19.0: single idx 968 P=11ce5900 
D=21d791900 L=5f2 DMA_FROM_DEVICE
[ 2471.933839] e1000e 0000:00:19.0: single idx 972 P=11cec840 
D=21d798840 L=5f2 DMA_FROM_DEVICE
[ 2471.933841] e1000e 0000:00:19.0: single idx 972 P=11ced040 
D=21d799040 L=5f2 DMA_FROM_DEVICE
[ 2471.933843] e1000e 0000:00:19.0: single idx 978 P=11cf8040 
D=21d7a4040 L=5f2 DMA_FROM_DEVICE
[ 2471.933844] e1000e 0000:00:19.0: single idx 992 P=12514040 
D=21dfc0040 L=5f2 DMA_FROM_DEVICE
[ 2471.933846] e1000e 0000:00:19.0: single idx 992 P=12514880 
D=21dfc0880 L=5f2 DMA_FROM_DEVICE
[ 2471.933847] e1000e 0000:00:19.0: single idx 992 P=11d14880 
D=21d7c0880 L=5f2 DMA_FROM_DEVICE
[ 2471.933849] e1000e 0000:00:19.0: single idx 998 P=11d20040 
D=21d7cc040 L=5f2 DMA_FROM_DEVICE
[ 2471.933850] e1000e 0000:00:19.0: single idx 1003 P=11d2a040 
D=21d7d6040 L=5f2 DMA_FROM_DEVICE
[ 2471.933852] e1000e 0000:00:19.0: single idx 1008 P=12535040 
D=21dfe1040 L=5f2 DMA_FROM_DEVICE
[ 2471.933854] e1000e 0000:00:19.0: single idx 1009 P=12536040 
D=21dfe2040 L=5f2 DMA_FROM_DEVICE
[ 2471.933855] e1000e 0000:00:19.0: single idx 1009 P=12536880 
D=21dfe2880 L=5f2 DMA_FROM_DEVICE

Regards,

Stefano


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

From xen-devel-bounces@lists.xen.org Wed Sep 05 13:24:06 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Sep 2012 13: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 1T9Fa7-0008HU-Tt; Wed, 05 Sep 2012 13:23:47 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1T9Fa6-0008HO-5c
	for xen-devel@lists.xen.org; Wed, 05 Sep 2012 13:23:46 +0000
Received: from [85.158.143.35:34130] by server-3.bemta-4.messagelabs.com id
	E7/36-08232-16257405; Wed, 05 Sep 2012 13:23:45 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1346851424!15422519!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQwMzE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19214 invoked from network); 5 Sep 2012 13:23:45 -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;
	5 Sep 2012 13:23:45 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 05 Sep 2012 14:23:45 +0100
Message-Id: <50476EB60200007800098EBD@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 05 Sep 2012 14:24:38 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Dan Magenheimer" <dan.magenheimer@oracle.com>
References: <76edd759-ceca-4fb5-b411-1e598137afd8@default>
In-Reply-To: <76edd759-ceca-4fb5-b411-1e598137afd8@default>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Konrad Wilk <konrad.wilk@oracle.com>, keir@xen.org,
	Zhenzhong Duan <zhenzhong.duan@oracle.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] [FOR 4.2] tmem: add matching unlock for an
 about-to-be-destroyed object
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.08.12 at 21:58, Dan Magenheimer <dan.magenheimer@oracle.com> wrote:
> A 4.2 changeset forces a preempt_disable/enable with
> every lock/unlock.
> 
> Tmem has dynamically allocated "objects" that contain a
> lock.  The lock is held when the object is destroyed.
> No reason to unlock something that's about to be destroyed!
> But with the preempt_enable/disable in the generic locking code,
> and the fact that do_softirq ASSERTs that preempt_count
> must be zero, a crash occurs soon after any object is
> destroyed.
> 
> So force lock to be released before destroying objects.

We had noticed this oddity during XSA-15 processing too.
What's the purpose of holding a lock on a to be destroyed
object anyway? One would expect a lock of a containing
entity to be held for that purpose (or really just while
taking the object off whatever data structure it can be
looked up through), which would eliminate the need for
locking the object itself. That lock generally appears to be
pool_rwlock, but in several places that one gets acquired
_after_ checking pgp_count to be zero - how is it being
guaranteed that this count doesn't increase between the
check and the lock being acquired?

Jan


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

From xen-devel-bounces@lists.xen.org Wed Sep 05 13:24:06 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Sep 2012 13: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 1T9Fa7-0008HU-Tt; Wed, 05 Sep 2012 13:23:47 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1T9Fa6-0008HO-5c
	for xen-devel@lists.xen.org; Wed, 05 Sep 2012 13:23:46 +0000
Received: from [85.158.143.35:34130] by server-3.bemta-4.messagelabs.com id
	E7/36-08232-16257405; Wed, 05 Sep 2012 13:23:45 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1346851424!15422519!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQwMzE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19214 invoked from network); 5 Sep 2012 13:23:45 -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;
	5 Sep 2012 13:23:45 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 05 Sep 2012 14:23:45 +0100
Message-Id: <50476EB60200007800098EBD@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 05 Sep 2012 14:24:38 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Dan Magenheimer" <dan.magenheimer@oracle.com>
References: <76edd759-ceca-4fb5-b411-1e598137afd8@default>
In-Reply-To: <76edd759-ceca-4fb5-b411-1e598137afd8@default>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Konrad Wilk <konrad.wilk@oracle.com>, keir@xen.org,
	Zhenzhong Duan <zhenzhong.duan@oracle.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] [FOR 4.2] tmem: add matching unlock for an
 about-to-be-destroyed object
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.08.12 at 21:58, Dan Magenheimer <dan.magenheimer@oracle.com> wrote:
> A 4.2 changeset forces a preempt_disable/enable with
> every lock/unlock.
> 
> Tmem has dynamically allocated "objects" that contain a
> lock.  The lock is held when the object is destroyed.
> No reason to unlock something that's about to be destroyed!
> But with the preempt_enable/disable in the generic locking code,
> and the fact that do_softirq ASSERTs that preempt_count
> must be zero, a crash occurs soon after any object is
> destroyed.
> 
> So force lock to be released before destroying objects.

We had noticed this oddity during XSA-15 processing too.
What's the purpose of holding a lock on a to be destroyed
object anyway? One would expect a lock of a containing
entity to be held for that purpose (or really just while
taking the object off whatever data structure it can be
looked up through), which would eliminate the need for
locking the object itself. That lock generally appears to be
pool_rwlock, but in several places that one gets acquired
_after_ checking pgp_count to be zero - how is it being
guaranteed that this count doesn't increase between the
check and the lock being acquired?

Jan


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

From xen-devel-bounces@lists.xen.org Wed Sep 05 13:29:54 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Sep 2012 13:29: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 1T9Ffk-0000E7-CD; Wed, 05 Sep 2012 13:29:36 +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 1T9Ffj-0000Dx-0Y
	for xen-devel@lists.xen.org; Wed, 05 Sep 2012 13:29:35 +0000
Received: from [85.158.138.51:34413] by server-2.bemta-3.messagelabs.com id
	E2/44-04862-EB357405; Wed, 05 Sep 2012 13:29:34 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1346851772!22451235!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDczODkxOA==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29694 invoked from network); 5 Sep 2012 13:29:33 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-14.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 5 Sep 2012 13:29:33 -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 q85DTSPR016290
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 5 Sep 2012 13:29:28 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
	q85DTRIu025997
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 5 Sep 2012 13:29:27 GMT
Received: from abhmt101.oracle.com (abhmt101.oracle.com [141.146.116.53])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q85DTQHL010082; Wed, 5 Sep 2012 08:29:26 -0500
Received: from localhost.localdomain (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 05 Sep 2012 06:29:26 -0700
Date: Wed, 5 Sep 2012 09:29:21 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: ronghui.duan@intel.com, justing@spectralogic.com,
	donald.d.dugger@intel.com, JBeulich@suse.com, xen-devel@lists.xen.org
Message-ID: <20120905132920.GA5792@localhost.localdomain>
MIME-Version: 1.0
Content-Disposition: inline
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Subject: [Xen-devel] Block ring protocol (segment expansion, multi-page,
	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

Please correct me if I a got something wrong.

About two or three years ago Citrix (and Red Hat I think?) posted a
multi-page extension protocol (max-ring-page-order, max-ring-pages
and ring-page-order and ring-pages)-
which never got upstream (needed just to be rebased on the driver that
went in the kernel I think?).

Then about a year ago SpectraLogic started enhancing the FreeBSD variant
of blkback - and realized what Ronghui also did - that the just doing a
multi-page extension is not enough. The issue was that if one just
expanded to a ring composed of two pages, 1/4 of the page was wasted b/c
of the segment is constrained to 11.

Justin (SpectraLogic) came up with a protocol enh were the existing
blkif protocol is the same, but the BLKIF_MAX_SEGMENTS_PER_REQUEST
is negotitated via max-request-segments. And then there is the
max-request-size which rolls the segment size and the size of the ring
to give you an idea of what is the biggest I/O you can fit on a ring in
a single transaction. This solves the wastage problem and expands the
ring.

Ronghui did something similar, but instead of re-using the existing
blkif structure he split them in two. One ring is for
blkif_request_header (which has the segments ripped out), and the other
is for just for blkif_request_segments. Solves the wastage and also
allows to expand the ring.

The three major outstanding issues that exists with the current protocol
that I know of are:
 - We split up the I/O requests. This ends up eating a lot of CPU
   cycles.
 - We might have huge I/O requests. Justin mentioned 1MB single I/Os -
   and to fit that on a ring it has to be .. well, be able to fit 256
   segments. Jan mentioned 256kB for SCSI - since the protocol
   extensions here could very well be carried over.
 - concurrent usage. If we have more than 4 VBDs blkback suffers when it
   tries to get a page as there is a "global" pool shared across all
   guests instead of being something 'per guest' or 'per VBD'.

So.. Ronghui - I am curious to why you choosen the path of making two
seperate rings? Was the mechanism that Justin came up not really that
good or was this just easier to implement?

Thanks.

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

From xen-devel-bounces@lists.xen.org Wed Sep 05 13:29:54 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Sep 2012 13:29: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 1T9Ffk-0000E7-CD; Wed, 05 Sep 2012 13:29:36 +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 1T9Ffj-0000Dx-0Y
	for xen-devel@lists.xen.org; Wed, 05 Sep 2012 13:29:35 +0000
Received: from [85.158.138.51:34413] by server-2.bemta-3.messagelabs.com id
	E2/44-04862-EB357405; Wed, 05 Sep 2012 13:29:34 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1346851772!22451235!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDczODkxOA==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29694 invoked from network); 5 Sep 2012 13:29:33 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-14.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 5 Sep 2012 13:29:33 -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 q85DTSPR016290
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 5 Sep 2012 13:29:28 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
	q85DTRIu025997
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 5 Sep 2012 13:29:27 GMT
Received: from abhmt101.oracle.com (abhmt101.oracle.com [141.146.116.53])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q85DTQHL010082; Wed, 5 Sep 2012 08:29:26 -0500
Received: from localhost.localdomain (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 05 Sep 2012 06:29:26 -0700
Date: Wed, 5 Sep 2012 09:29:21 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: ronghui.duan@intel.com, justing@spectralogic.com,
	donald.d.dugger@intel.com, JBeulich@suse.com, xen-devel@lists.xen.org
Message-ID: <20120905132920.GA5792@localhost.localdomain>
MIME-Version: 1.0
Content-Disposition: inline
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Subject: [Xen-devel] Block ring protocol (segment expansion, multi-page,
	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

Please correct me if I a got something wrong.

About two or three years ago Citrix (and Red Hat I think?) posted a
multi-page extension protocol (max-ring-page-order, max-ring-pages
and ring-page-order and ring-pages)-
which never got upstream (needed just to be rebased on the driver that
went in the kernel I think?).

Then about a year ago SpectraLogic started enhancing the FreeBSD variant
of blkback - and realized what Ronghui also did - that the just doing a
multi-page extension is not enough. The issue was that if one just
expanded to a ring composed of two pages, 1/4 of the page was wasted b/c
of the segment is constrained to 11.

Justin (SpectraLogic) came up with a protocol enh were the existing
blkif protocol is the same, but the BLKIF_MAX_SEGMENTS_PER_REQUEST
is negotitated via max-request-segments. And then there is the
max-request-size which rolls the segment size and the size of the ring
to give you an idea of what is the biggest I/O you can fit on a ring in
a single transaction. This solves the wastage problem and expands the
ring.

Ronghui did something similar, but instead of re-using the existing
blkif structure he split them in two. One ring is for
blkif_request_header (which has the segments ripped out), and the other
is for just for blkif_request_segments. Solves the wastage and also
allows to expand the ring.

The three major outstanding issues that exists with the current protocol
that I know of are:
 - We split up the I/O requests. This ends up eating a lot of CPU
   cycles.
 - We might have huge I/O requests. Justin mentioned 1MB single I/Os -
   and to fit that on a ring it has to be .. well, be able to fit 256
   segments. Jan mentioned 256kB for SCSI - since the protocol
   extensions here could very well be carried over.
 - concurrent usage. If we have more than 4 VBDs blkback suffers when it
   tries to get a page as there is a "global" pool shared across all
   guests instead of being something 'per guest' or 'per VBD'.

So.. Ronghui - I am curious to why you choosen the path of making two
seperate rings? Was the mechanism that Justin came up not really that
good or was this just easier to implement?

Thanks.

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

From xen-devel-bounces@lists.xen.org Wed Sep 05 13:36:02 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Sep 2012 13:36:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9Flg-0000Tq-E2; Wed, 05 Sep 2012 13:35:44 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <rjw@sisk.pl>)
	id 1T9Fle-0000Tl-Fs
	for xen-devel@lists.xensource.com; Wed, 05 Sep 2012 13:35:42 +0000
Received: from [85.158.143.35:14252] by server-1.bemta-4.messagelabs.com id
	13/E8-12504-D2557405; Wed, 05 Sep 2012 13:35:41 +0000
X-Env-Sender: rjw@sisk.pl
X-Msg-Ref: server-7.tower-21.messagelabs.com!1346852140!12349608!1
X-Originating-IP: [193.178.161.156]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5289 invoked from network); 5 Sep 2012 13:35:40 -0000
Received: from ogre.sisk.pl (HELO ogre.sisk.pl) (193.178.161.156)
	by server-7.tower-21.messagelabs.com with SMTP;
	5 Sep 2012 13:35:40 -0000
Received: from localhost (localhost.localdomain [127.0.0.1])
	by ogre.sisk.pl (Postfix) with ESMTP id 49E891DD013;
	Wed,  5 Sep 2012 15:39:35 +0200 (CEST)
Received: from ogre.sisk.pl ([127.0.0.1])
	by localhost (ogre.sisk.pl [127.0.0.1]) (amavisd-new,
	port 10024) with ESMTP
	id 27899-06; Wed,  5 Sep 2012 15:39:26 +0200 (CEST)
Received: from ferrari.rjw.lan (89-67-90-11.dynamic.chello.pl [89.67.90.11])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by ogre.sisk.pl (Postfix) with ESMTP id 8005A1DCF60;
	Wed,  5 Sep 2012 15:39:26 +0200 (CEST)
From: "Rafael J. Wysocki" <rjw@sisk.pl>
To: Daniel Lezcano <daniel.lezcano@linaro.org>
Date: Wed, 5 Sep 2012 15:41:58 +0200
User-Agent: KMail/1.13.6 (Linux/3.6.0-rc3+; KDE/4.6.0; x86_64; ; )
References: <1343164349-28550-1-git-send-email-daniel.lezcano@linaro.org>
	<50410811.70500@linaro.org> <201209010754.58999.rjw@sisk.pl>
In-Reply-To: <201209010754.58999.rjw@sisk.pl>
MIME-Version: 1.0
Message-Id: <201209051541.58909.rjw@sisk.pl>
X-Virus-Scanned: amavisd-new at ogre.sisk.pl using MkS_Vir for Linux
Cc: xen-devel@lists.xensource.com, linaro-dev@lists.linaro.org,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	linux-pm@vger.kernel.org, patches@linaro.org,
	linux-acpi@vger.kernel.org, lenb@kernel.org
Subject: Re: [Xen-devel] [PATCH] acpi : remove power from acpi_processor_cx
	structure
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Saturday, September 01, 2012, Rafael J. Wysocki wrote:
> On Friday, August 31, 2012, Daniel Lezcano wrote:
> > On 07/24/2012 11:06 PM, Konrad Rzeszutek Wilk wrote:
> > > On Tue, Jul 24, 2012 at 11:12:29PM +0200, Daniel Lezcano wrote:
> > >> Remove the power field as it is not used.
> > >>
> > >> Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
> > >> Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> > > Acked.
> > 
> > Hi Rafael,
> > 
> > I did not see this patch going in. Is it possible to merge it ?
> 
> I think so.  I'll take care of it when I get back from LinuxCon/Plumbers Conf.
> (early next week).

Applied to the linux-next branch of the linux-pm.git tree as v3.7 material.

Are there any other patches you want me to consider for v3.7?

Rafael

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

From xen-devel-bounces@lists.xen.org Wed Sep 05 13:36:02 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Sep 2012 13:36:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9Flg-0000Tq-E2; Wed, 05 Sep 2012 13:35:44 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <rjw@sisk.pl>)
	id 1T9Fle-0000Tl-Fs
	for xen-devel@lists.xensource.com; Wed, 05 Sep 2012 13:35:42 +0000
Received: from [85.158.143.35:14252] by server-1.bemta-4.messagelabs.com id
	13/E8-12504-D2557405; Wed, 05 Sep 2012 13:35:41 +0000
X-Env-Sender: rjw@sisk.pl
X-Msg-Ref: server-7.tower-21.messagelabs.com!1346852140!12349608!1
X-Originating-IP: [193.178.161.156]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5289 invoked from network); 5 Sep 2012 13:35:40 -0000
Received: from ogre.sisk.pl (HELO ogre.sisk.pl) (193.178.161.156)
	by server-7.tower-21.messagelabs.com with SMTP;
	5 Sep 2012 13:35:40 -0000
Received: from localhost (localhost.localdomain [127.0.0.1])
	by ogre.sisk.pl (Postfix) with ESMTP id 49E891DD013;
	Wed,  5 Sep 2012 15:39:35 +0200 (CEST)
Received: from ogre.sisk.pl ([127.0.0.1])
	by localhost (ogre.sisk.pl [127.0.0.1]) (amavisd-new,
	port 10024) with ESMTP
	id 27899-06; Wed,  5 Sep 2012 15:39:26 +0200 (CEST)
Received: from ferrari.rjw.lan (89-67-90-11.dynamic.chello.pl [89.67.90.11])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by ogre.sisk.pl (Postfix) with ESMTP id 8005A1DCF60;
	Wed,  5 Sep 2012 15:39:26 +0200 (CEST)
From: "Rafael J. Wysocki" <rjw@sisk.pl>
To: Daniel Lezcano <daniel.lezcano@linaro.org>
Date: Wed, 5 Sep 2012 15:41:58 +0200
User-Agent: KMail/1.13.6 (Linux/3.6.0-rc3+; KDE/4.6.0; x86_64; ; )
References: <1343164349-28550-1-git-send-email-daniel.lezcano@linaro.org>
	<50410811.70500@linaro.org> <201209010754.58999.rjw@sisk.pl>
In-Reply-To: <201209010754.58999.rjw@sisk.pl>
MIME-Version: 1.0
Message-Id: <201209051541.58909.rjw@sisk.pl>
X-Virus-Scanned: amavisd-new at ogre.sisk.pl using MkS_Vir for Linux
Cc: xen-devel@lists.xensource.com, linaro-dev@lists.linaro.org,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	linux-pm@vger.kernel.org, patches@linaro.org,
	linux-acpi@vger.kernel.org, lenb@kernel.org
Subject: Re: [Xen-devel] [PATCH] acpi : remove power from acpi_processor_cx
	structure
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Saturday, September 01, 2012, Rafael J. Wysocki wrote:
> On Friday, August 31, 2012, Daniel Lezcano wrote:
> > On 07/24/2012 11:06 PM, Konrad Rzeszutek Wilk wrote:
> > > On Tue, Jul 24, 2012 at 11:12:29PM +0200, Daniel Lezcano wrote:
> > >> Remove the power field as it is not used.
> > >>
> > >> Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
> > >> Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> > > Acked.
> > 
> > Hi Rafael,
> > 
> > I did not see this patch going in. Is it possible to merge it ?
> 
> I think so.  I'll take care of it when I get back from LinuxCon/Plumbers Conf.
> (early next week).

Applied to the linux-next branch of the linux-pm.git tree as v3.7 material.

Are there any other patches you want me to consider for v3.7?

Rafael

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

From xen-devel-bounces@lists.xen.org Wed Sep 05 13:53:52 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Sep 2012 13:53:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9G2q-0000qS-31; Wed, 05 Sep 2012 13:53:28 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1T9G2o-0000qN-VM
	for xen-devel@lists.xen.org; Wed, 05 Sep 2012 13:53:27 +0000
Received: from [85.158.143.99:27097] by server-1.bemta-4.messagelabs.com id
	47/9B-12504-65957405; Wed, 05 Sep 2012 13:53:26 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1346853202!21663924!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-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16325 invoked from network); 5 Sep 2012 13:53:25 -0000
Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com)
	(74.125.83.45)
	by server-6.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Sep 2012 13:53:25 -0000
Received: by eeke53 with SMTP id e53so278638eek.32
	for <xen-devel@lists.xen.org>; Wed, 05 Sep 2012 06:53:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=user-agent:date:subject:from:to:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=os+J1BMFXdm2tQxfyOP9RscbV+Mw1L2nqHqvZHJ/gu0=;
	b=aIIo8lmpB6THWImCp1S61DzdL+/FBWcoSgk1oiHGPTgTgWamHXfazwU0Yc0FpTk6RY
	Vmf6kuEwec8WOvAti0xiVpCmGoZ6UaHZSgYtdCDYEA39RYDShgrGKNJ94v9e51v69BNI
	gxuhu7lVLvXNrF70IW9ZzQhPNAOpxgVL6eFzS+RW8HRH8G4IzRswmqUNtl6VPZa2uYbR
	5+0g2j2BR4oJwkTf3EsmalsTVM6r7DC/Xz+scLX/txS7XCmdUUZQISUc/is5dpkHjYDd
	Hev3H8OmjJeq8JxTJ+SP/7afMYWidYTgFfeRLrMPjKzO9ZO0Q+9TDQ6WIynRBSA7TRyt
	2eYg==
Received: by 10.14.213.137 with SMTP id a9mr30740665eep.38.1346853202566;
	Wed, 05 Sep 2012 06:53:22 -0700 (PDT)
Received: from [192.168.1.69] (host86-184-74-117.range86-184.btcentralplus.com.
	[86.184.74.117])
	by mx.google.com with ESMTPS id k49sm4499604een.4.2012.09.05.06.53.21
	(version=SSLv3 cipher=OTHER); Wed, 05 Sep 2012 06:53:21 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Wed, 05 Sep 2012 14:53:18 +0100
From: Keir Fraser <keir.xen@gmail.com>
To: Jan Beulich <JBeulich@suse.com>,
	xen-devel <xen-devel@lists.xen.org>
Message-ID: <CC6D17DE.3DCD9%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [PATCH 2/2] x86: fix RCU locking in
	PHYSDEVOP_get_free_pirq
Thread-Index: Ac2Lbc2OuHITTc8slEqe9PECGRCCAA==
In-Reply-To: <504765830200007800098E5D@nat28.tlf.novell.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] [PATCH 2/2] x86: fix RCU locking in
 PHYSDEVOP_get_free_pirq
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/09/2012 13:45, "Jan Beulich" <JBeulich@suse.com> wrote:

>>> Apart from properly pairing locks with unlocks, also reduce the lock
>>> scope - no need to do the copy_{from,to}_guest()-s inside the protected
>>> region.
>>> 
>>> I actually wonder whether the RCU locks are needed here at all.
>> 
>> If it's a path that only acts on current domain, then no.
> 
> So for what case does rcu_lock_current_domain() then exist at all?

To match an unconditional rcu_unlock_domain() on exit paths, for operations
which can either be on current->domain or on a rcu_lock_domain_by_id().

 -- Keir



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

From xen-devel-bounces@lists.xen.org Wed Sep 05 13:53:52 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Sep 2012 13:53:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9G2q-0000qS-31; Wed, 05 Sep 2012 13:53:28 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1T9G2o-0000qN-VM
	for xen-devel@lists.xen.org; Wed, 05 Sep 2012 13:53:27 +0000
Received: from [85.158.143.99:27097] by server-1.bemta-4.messagelabs.com id
	47/9B-12504-65957405; Wed, 05 Sep 2012 13:53:26 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1346853202!21663924!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-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16325 invoked from network); 5 Sep 2012 13:53:25 -0000
Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com)
	(74.125.83.45)
	by server-6.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Sep 2012 13:53:25 -0000
Received: by eeke53 with SMTP id e53so278638eek.32
	for <xen-devel@lists.xen.org>; Wed, 05 Sep 2012 06:53:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=user-agent:date:subject:from:to:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=os+J1BMFXdm2tQxfyOP9RscbV+Mw1L2nqHqvZHJ/gu0=;
	b=aIIo8lmpB6THWImCp1S61DzdL+/FBWcoSgk1oiHGPTgTgWamHXfazwU0Yc0FpTk6RY
	Vmf6kuEwec8WOvAti0xiVpCmGoZ6UaHZSgYtdCDYEA39RYDShgrGKNJ94v9e51v69BNI
	gxuhu7lVLvXNrF70IW9ZzQhPNAOpxgVL6eFzS+RW8HRH8G4IzRswmqUNtl6VPZa2uYbR
	5+0g2j2BR4oJwkTf3EsmalsTVM6r7DC/Xz+scLX/txS7XCmdUUZQISUc/is5dpkHjYDd
	Hev3H8OmjJeq8JxTJ+SP/7afMYWidYTgFfeRLrMPjKzO9ZO0Q+9TDQ6WIynRBSA7TRyt
	2eYg==
Received: by 10.14.213.137 with SMTP id a9mr30740665eep.38.1346853202566;
	Wed, 05 Sep 2012 06:53:22 -0700 (PDT)
Received: from [192.168.1.69] (host86-184-74-117.range86-184.btcentralplus.com.
	[86.184.74.117])
	by mx.google.com with ESMTPS id k49sm4499604een.4.2012.09.05.06.53.21
	(version=SSLv3 cipher=OTHER); Wed, 05 Sep 2012 06:53:21 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Wed, 05 Sep 2012 14:53:18 +0100
From: Keir Fraser <keir.xen@gmail.com>
To: Jan Beulich <JBeulich@suse.com>,
	xen-devel <xen-devel@lists.xen.org>
Message-ID: <CC6D17DE.3DCD9%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [PATCH 2/2] x86: fix RCU locking in
	PHYSDEVOP_get_free_pirq
Thread-Index: Ac2Lbc2OuHITTc8slEqe9PECGRCCAA==
In-Reply-To: <504765830200007800098E5D@nat28.tlf.novell.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] [PATCH 2/2] x86: fix RCU locking in
 PHYSDEVOP_get_free_pirq
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/09/2012 13:45, "Jan Beulich" <JBeulich@suse.com> wrote:

>>> Apart from properly pairing locks with unlocks, also reduce the lock
>>> scope - no need to do the copy_{from,to}_guest()-s inside the protected
>>> region.
>>> 
>>> I actually wonder whether the RCU locks are needed here at all.
>> 
>> If it's a path that only acts on current domain, then no.
> 
> So for what case does rcu_lock_current_domain() then exist at all?

To match an unconditional rcu_unlock_domain() on exit paths, for operations
which can either be on current->domain or on a rcu_lock_domain_by_id().

 -- Keir



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

From xen-devel-bounces@lists.xen.org Wed Sep 05 14:15:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Sep 2012 14:15:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9GNW-0001My-Gy; Wed, 05 Sep 2012 14:14:50 +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 1T9GNU-0001Mp-9g
	for xen-devel@lists.xen.org; Wed, 05 Sep 2012 14:14:48 +0000
Received: from [85.158.143.99:2399] by server-2.bemta-4.messagelabs.com id
	E4/58-21239-75E57405; Wed, 05 Sep 2012 14:14:47 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1346854485!18921199!1
X-Originating-IP: [216.32.180.186]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18313 invoked from network); 5 Sep 2012 14:14:46 -0000
Received: from co1ehsobe003.messaging.microsoft.com (HELO
	co1outboundpool.messaging.microsoft.com) (216.32.180.186)
	by server-8.tower-216.messagelabs.com with AES128-SHA encrypted SMTP;
	5 Sep 2012 14:14:46 -0000
Received: from mail110-co1-R.bigfish.com (10.243.78.239) by
	CO1EHSOBE016.bigfish.com (10.243.66.79) with Microsoft SMTP Server id
	14.1.225.23; Wed, 5 Sep 2012 14:14:44 +0000
Received: from mail110-co1 (localhost [127.0.0.1])	by
	mail110-co1-R.bigfish.com (Postfix) with ESMTP id B92EA3A0097;
	Wed,  5 Sep 2012 14:14: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: -5
X-BigFish: VPS-5(zzbb2dI98dI9371Ic89bh1432I4015Izz1202hzzz2dh668h839h93fhd25he5bhf0ah107ah1155h)
Received: from mail110-co1 (localhost.localdomain [127.0.0.1]) by mail110-co1
	(MessageSwitch) id 1346854482986326_27761;
	Wed,  5 Sep 2012 14:14:42 +0000 (UTC)
Received: from CO1EHSMHS016.bigfish.com (unknown [10.243.78.239])	by
	mail110-co1.bigfish.com (Postfix) with ESMTP id E39B1C800BD;
	Wed,  5 Sep 2012 14:14:42 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	CO1EHSMHS016.bigfish.com (10.243.66.26) with Microsoft SMTP Server id
	14.1.225.23; Wed, 5 Sep 2012 14:14:41 +0000
X-WSS-ID: 0M9VRKB-02-3IV-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 20211C811F;	Wed,  5 Sep 2012 09:14:34 -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;
	Wed, 5 Sep 2012 09:14:51 -0500
Received: from storexhtp02.amd.com (172.24.4.4) by sausexdag03.amd.com
	(163.181.55.3) with Microsoft SMTP Server (TLS) id 14.1.323.3;
	Wed, 5 Sep 2012 09:14: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; Wed, 5 Sep 2012
	10:14:37 -0400
Received: from [165.204.15.57] (gran.osrc.amd.com [165.204.15.57])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id EABCC49C0D5; Wed,  5 Sep 2012
	15:14:32 +0100 (BST)
Message-ID: <50475E8D.2090709@amd.com>
Date: Wed, 5 Sep 2012 16:15:41 +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: <40501859.20120902104331@eikelenboom.it>
	<CC6932C2.3D99D%keir.xen@gmail.com>
	<217459398.20120902171441@eikelenboom.it>
	<5044CAD7.8030800@amd.com>
	<1144695277.20120904184345@eikelenboom.it>
	<5047420A0200007800098BB1@nat28.tlf.novell.com>
	<348297741.20120905122542@eikelenboom.it>
	<5047483F0200007800098C18@nat28.tlf.novell.com>
In-Reply-To: <5047483F0200007800098C18@nat28.tlf.novell.com>
X-OriginatorOrg: amd.com
Cc: Sander Eikelenboom <linux@eikelenboom.it>, Keir Fraser <keir.xen@gmail.com>,
	Santosh Jodh <Santosh.Jodh@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Using debug-key 'o:  Dump IOMMU p2m table,
 locks up machine
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
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

T24gMDkvMDUvMjAxMiAxMjo0MCBQTSwgSmFuIEJldWxpY2ggd3JvdGU6Cj4+Pj4gT24gMDUuMDku
MTIgYXQgMTI6MjUsIFNhbmRlciBFaWtlbGVuYm9vbTxsaW51eEBlaWtlbGVuYm9vbS5pdD4gIHdy
b3RlOgo+PiBXZWRuZXNkYXksIFNlcHRlbWJlciA1LCAyMDEyLCAxMjoxNDowMiBQTSwgeW91IHdy
b3RlOgo+Pj4+Pj4gT24gMDQuMDkuMTIgYXQgMTg6NDMsIFNhbmRlciBFaWtlbGVuYm9vbTxsaW51
eEBlaWtlbGVuYm9vbS5pdD4gIHdyb3RlOgo+Pj4+IC4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u
LjwwPkFNRC1WaTogSU9fUEFHRV9GQVVMVDogZG9tYWluID0gMCwgZGV2aWNlIGlkID0KPj4+PiAw
eDBhMDYsIGZhdWx0IGFkZHJlc3MgPSAweGMyYzJjMmMwCj4+Cj4+PiBMb29rcyBsaWtlIHVzZSBv
ZiB1bmluaXRpYWxpemVkIG1lbW9yeSAoYXNzdW1pbmcgeW91J3JlIHVzaW5nIGEKPj4+IGRlYnVn
IGh5cGVydmlzb3IsIHRoYXQncyB0aGUgcGF0dGVybiBzY3J1Yl9vbmVfcGFnZSgpIHB1dHMKPj4+
IHRoZXJlKS4gQnV0IGl0J3MgdW5jbGVhciB0byBtZSB3aGF0IGRldmljZSBzaG91bGQgYmUgZG9p
bmcgYW55Cj4+PiBJL08gYXQgdGhhdCBwb2ludCAoYW5kIGV2ZW4gaWYgb25lIGRvZXMsIGhvdyBp
dCB3b3VsZCBnZXQgdGhlCj4+PiBiYWQgYWRkcmVzcyBsb2FkZWQpLiBXaGF0IGlzIDBhOjAwLjY/
Cj4+Cj4+IHNpbmNlIDQuMi1yYzQgaXMgc3RpbGwgdW5zdGFibGUgaXQgaGFzIGRlYnVnPXkgZm9y
IHdoYXQgaSBrbm93LCBzbyB5ZXMuCj4+IFRoaXMgcGFydGljdWxhciBJT19QQUdFX0ZBVUxUIGhh
cHBlbmVkIGJlZm9yZSB0aGUga2VybmVsIGxvYWRzLCBzbyB0aGUKPj4ga2VybmVsIGFuZCBwY2li
YWNrIHNob3VsZG4ndCBiZSBjYXVzaW5nIHRoZSBpc3N1ZSBvbmUgd291bGQgc2F5Lgo+PiBXaXRo
IHBjaWJhY2sgaSdtIGhpZGluZyAwMzowNi4wLCAwNDowMC4qLCAwNTowMC4wLCAwYTowMC4qIGFu
ZCAwNzowMC4wIGF0Cj4+IGJvb3QuCj4+Cj4+IElzIHRoZXJlIGFueSBjb2RlIGkgY291bGQgYWRk
IHRvIGdldCBtb3JlIGluZm8gd2hlcmUgaXQgY29tZXMgZnJvbSA/Cj4KPiBIYXJkbHksIHNpbmNl
IHRob3NlIGFjY2Vzc2VzIGFyZSBhc3luY2hyb25vdXMgdG8gd2hhdCB0aGUgQ1BVcwo+IGRvLiBC
dXQgLi4uCj4KPj4gMGE6MDAuNiBVU0IgY29udHJvbGxlcjogTmV0TW9zIFRlY2hub2xvZ3kgTUNT
OTk5MCBQQ0llIHRvIDTDolBvcnQgVVNCIDIuMCBIb3N0IENvbnRyb2xsZXIKPgo+IC4uLiBhcmUg
eW91ciBrZXlib2FyZC9tb3VzZSBwZXJoYXBzIGNvbm5lY3RlZCB0byB0aGlzIG9uZT8gSW4KPiB3
aGljaCBjYXNlIEknZCBzdXBwb3NlIHRoZSAxOjEgdGFibGVzIHNldCB1cCBmb3IgRG9tMCBtaWdo
dCBub3QKPiBiZSBjb21wbGV0ZS4gV2VpPwoKSSBjaGVja2VkIHRoaXMgb24gbXkgbWFjaGluZSB1
c2luZyAnbycga2V5IGFuZCBpdCBoYXMgYmVlbiBtYXBwZWQgYXMgYSAKMk1CIGZyYW1lIHNlZTog
Z2ZuOiAwMDBjMmMwMCAgbWZuOiAwMDBjMmMwMC4gQnV0IG1heWJlIEkgaGF2ZSBubyBkZXZpY2Ug
CmFjY2VzcyB0byB0aGlzIGFkZHJlc3MuLi4gQW5vdGhlciBwb3NzaWJpbGl0eSBpcyBpbnRlcnJ1
cHQgbWVzc2FnZS4gNC4xIApkb2VzIG5vdCBzaG93IElPX1BBR0VfRkFVTFQgZm9yIGludGVycnVw
dHMsIGJ1dCA0LjIgZG9lcyAoY2hhbmdlc2V0IAoyMzE5OTpkYmQ5OGFiMmY4N2YpLiBJIHdpbGwg
c2VuZCBhIHBhdGNoIHRvIGR1bXAgZmxhZ3MgZnJvbSBJT19QQUdFX0ZBVUxULgoKVGhhbmtzLApX
ZWkKCj4gSmFuCj4KCgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRw
Oi8vbGlzdHMueGVuLm9yZy94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xen.org Wed Sep 05 14:15:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Sep 2012 14:15:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9GNW-0001My-Gy; Wed, 05 Sep 2012 14:14:50 +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 1T9GNU-0001Mp-9g
	for xen-devel@lists.xen.org; Wed, 05 Sep 2012 14:14:48 +0000
Received: from [85.158.143.99:2399] by server-2.bemta-4.messagelabs.com id
	E4/58-21239-75E57405; Wed, 05 Sep 2012 14:14:47 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1346854485!18921199!1
X-Originating-IP: [216.32.180.186]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18313 invoked from network); 5 Sep 2012 14:14:46 -0000
Received: from co1ehsobe003.messaging.microsoft.com (HELO
	co1outboundpool.messaging.microsoft.com) (216.32.180.186)
	by server-8.tower-216.messagelabs.com with AES128-SHA encrypted SMTP;
	5 Sep 2012 14:14:46 -0000
Received: from mail110-co1-R.bigfish.com (10.243.78.239) by
	CO1EHSOBE016.bigfish.com (10.243.66.79) with Microsoft SMTP Server id
	14.1.225.23; Wed, 5 Sep 2012 14:14:44 +0000
Received: from mail110-co1 (localhost [127.0.0.1])	by
	mail110-co1-R.bigfish.com (Postfix) with ESMTP id B92EA3A0097;
	Wed,  5 Sep 2012 14:14: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: -5
X-BigFish: VPS-5(zzbb2dI98dI9371Ic89bh1432I4015Izz1202hzzz2dh668h839h93fhd25he5bhf0ah107ah1155h)
Received: from mail110-co1 (localhost.localdomain [127.0.0.1]) by mail110-co1
	(MessageSwitch) id 1346854482986326_27761;
	Wed,  5 Sep 2012 14:14:42 +0000 (UTC)
Received: from CO1EHSMHS016.bigfish.com (unknown [10.243.78.239])	by
	mail110-co1.bigfish.com (Postfix) with ESMTP id E39B1C800BD;
	Wed,  5 Sep 2012 14:14:42 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	CO1EHSMHS016.bigfish.com (10.243.66.26) with Microsoft SMTP Server id
	14.1.225.23; Wed, 5 Sep 2012 14:14:41 +0000
X-WSS-ID: 0M9VRKB-02-3IV-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 20211C811F;	Wed,  5 Sep 2012 09:14:34 -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;
	Wed, 5 Sep 2012 09:14:51 -0500
Received: from storexhtp02.amd.com (172.24.4.4) by sausexdag03.amd.com
	(163.181.55.3) with Microsoft SMTP Server (TLS) id 14.1.323.3;
	Wed, 5 Sep 2012 09:14: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; Wed, 5 Sep 2012
	10:14:37 -0400
Received: from [165.204.15.57] (gran.osrc.amd.com [165.204.15.57])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id EABCC49C0D5; Wed,  5 Sep 2012
	15:14:32 +0100 (BST)
Message-ID: <50475E8D.2090709@amd.com>
Date: Wed, 5 Sep 2012 16:15:41 +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: <40501859.20120902104331@eikelenboom.it>
	<CC6932C2.3D99D%keir.xen@gmail.com>
	<217459398.20120902171441@eikelenboom.it>
	<5044CAD7.8030800@amd.com>
	<1144695277.20120904184345@eikelenboom.it>
	<5047420A0200007800098BB1@nat28.tlf.novell.com>
	<348297741.20120905122542@eikelenboom.it>
	<5047483F0200007800098C18@nat28.tlf.novell.com>
In-Reply-To: <5047483F0200007800098C18@nat28.tlf.novell.com>
X-OriginatorOrg: amd.com
Cc: Sander Eikelenboom <linux@eikelenboom.it>, Keir Fraser <keir.xen@gmail.com>,
	Santosh Jodh <Santosh.Jodh@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Using debug-key 'o:  Dump IOMMU p2m table,
 locks up machine
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
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

T24gMDkvMDUvMjAxMiAxMjo0MCBQTSwgSmFuIEJldWxpY2ggd3JvdGU6Cj4+Pj4gT24gMDUuMDku
MTIgYXQgMTI6MjUsIFNhbmRlciBFaWtlbGVuYm9vbTxsaW51eEBlaWtlbGVuYm9vbS5pdD4gIHdy
b3RlOgo+PiBXZWRuZXNkYXksIFNlcHRlbWJlciA1LCAyMDEyLCAxMjoxNDowMiBQTSwgeW91IHdy
b3RlOgo+Pj4+Pj4gT24gMDQuMDkuMTIgYXQgMTg6NDMsIFNhbmRlciBFaWtlbGVuYm9vbTxsaW51
eEBlaWtlbGVuYm9vbS5pdD4gIHdyb3RlOgo+Pj4+IC4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u
LjwwPkFNRC1WaTogSU9fUEFHRV9GQVVMVDogZG9tYWluID0gMCwgZGV2aWNlIGlkID0KPj4+PiAw
eDBhMDYsIGZhdWx0IGFkZHJlc3MgPSAweGMyYzJjMmMwCj4+Cj4+PiBMb29rcyBsaWtlIHVzZSBv
ZiB1bmluaXRpYWxpemVkIG1lbW9yeSAoYXNzdW1pbmcgeW91J3JlIHVzaW5nIGEKPj4+IGRlYnVn
IGh5cGVydmlzb3IsIHRoYXQncyB0aGUgcGF0dGVybiBzY3J1Yl9vbmVfcGFnZSgpIHB1dHMKPj4+
IHRoZXJlKS4gQnV0IGl0J3MgdW5jbGVhciB0byBtZSB3aGF0IGRldmljZSBzaG91bGQgYmUgZG9p
bmcgYW55Cj4+PiBJL08gYXQgdGhhdCBwb2ludCAoYW5kIGV2ZW4gaWYgb25lIGRvZXMsIGhvdyBp
dCB3b3VsZCBnZXQgdGhlCj4+PiBiYWQgYWRkcmVzcyBsb2FkZWQpLiBXaGF0IGlzIDBhOjAwLjY/
Cj4+Cj4+IHNpbmNlIDQuMi1yYzQgaXMgc3RpbGwgdW5zdGFibGUgaXQgaGFzIGRlYnVnPXkgZm9y
IHdoYXQgaSBrbm93LCBzbyB5ZXMuCj4+IFRoaXMgcGFydGljdWxhciBJT19QQUdFX0ZBVUxUIGhh
cHBlbmVkIGJlZm9yZSB0aGUga2VybmVsIGxvYWRzLCBzbyB0aGUKPj4ga2VybmVsIGFuZCBwY2li
YWNrIHNob3VsZG4ndCBiZSBjYXVzaW5nIHRoZSBpc3N1ZSBvbmUgd291bGQgc2F5Lgo+PiBXaXRo
IHBjaWJhY2sgaSdtIGhpZGluZyAwMzowNi4wLCAwNDowMC4qLCAwNTowMC4wLCAwYTowMC4qIGFu
ZCAwNzowMC4wIGF0Cj4+IGJvb3QuCj4+Cj4+IElzIHRoZXJlIGFueSBjb2RlIGkgY291bGQgYWRk
IHRvIGdldCBtb3JlIGluZm8gd2hlcmUgaXQgY29tZXMgZnJvbSA/Cj4KPiBIYXJkbHksIHNpbmNl
IHRob3NlIGFjY2Vzc2VzIGFyZSBhc3luY2hyb25vdXMgdG8gd2hhdCB0aGUgQ1BVcwo+IGRvLiBC
dXQgLi4uCj4KPj4gMGE6MDAuNiBVU0IgY29udHJvbGxlcjogTmV0TW9zIFRlY2hub2xvZ3kgTUNT
OTk5MCBQQ0llIHRvIDTDolBvcnQgVVNCIDIuMCBIb3N0IENvbnRyb2xsZXIKPgo+IC4uLiBhcmUg
eW91ciBrZXlib2FyZC9tb3VzZSBwZXJoYXBzIGNvbm5lY3RlZCB0byB0aGlzIG9uZT8gSW4KPiB3
aGljaCBjYXNlIEknZCBzdXBwb3NlIHRoZSAxOjEgdGFibGVzIHNldCB1cCBmb3IgRG9tMCBtaWdo
dCBub3QKPiBiZSBjb21wbGV0ZS4gV2VpPwoKSSBjaGVja2VkIHRoaXMgb24gbXkgbWFjaGluZSB1
c2luZyAnbycga2V5IGFuZCBpdCBoYXMgYmVlbiBtYXBwZWQgYXMgYSAKMk1CIGZyYW1lIHNlZTog
Z2ZuOiAwMDBjMmMwMCAgbWZuOiAwMDBjMmMwMC4gQnV0IG1heWJlIEkgaGF2ZSBubyBkZXZpY2Ug
CmFjY2VzcyB0byB0aGlzIGFkZHJlc3MuLi4gQW5vdGhlciBwb3NzaWJpbGl0eSBpcyBpbnRlcnJ1
cHQgbWVzc2FnZS4gNC4xIApkb2VzIG5vdCBzaG93IElPX1BBR0VfRkFVTFQgZm9yIGludGVycnVw
dHMsIGJ1dCA0LjIgZG9lcyAoY2hhbmdlc2V0IAoyMzE5OTpkYmQ5OGFiMmY4N2YpLiBJIHdpbGwg
c2VuZCBhIHBhdGNoIHRvIGR1bXAgZmxhZ3MgZnJvbSBJT19QQUdFX0ZBVUxULgoKVGhhbmtzLApX
ZWkKCj4gSmFuCj4KCgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRw
Oi8vbGlzdHMueGVuLm9yZy94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xen.org Wed Sep 05 14:17:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Sep 2012 14:17:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9GPV-0001U6-27; Wed, 05 Sep 2012 14:16:53 +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 1T9GPT-0001Ts-If
	for xen-devel@lists.xen.org; Wed, 05 Sep 2012 14:16:51 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1346854598!8619041!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzI4NDYw\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27817 invoked from network); 5 Sep 2012 14:16:40 -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 Sep 2012 14:16:40 -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 q85EGWrL020067
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 5 Sep 2012 14:16: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
	q85EGVBU025820
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 5 Sep 2012 14:16:31 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
	q85EGVrR019423; Wed, 5 Sep 2012 09:16:31 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 05 Sep 2012 07:16:31 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 176C9402C1; Wed,  5 Sep 2012 10:06:01 -0400 (EDT)
Date: Wed, 5 Sep 2012 10:06:01 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Robert Phillips <robert.phillips@citrix.com>
Message-ID: <20120905140600.GA5844@phenom.dumpdata.com>
References: <1136369816.20120904183757@eikelenboom.it>
	<20120904163347.GH23361@phenom.dumpdata.com>
	<143844933.20120904191941@eikelenboom.it>
	<CAOvdn6U_yHgtZwv9MWazdLbd3NLq3pwGXnZY5sL2UVBhV_FUoQ@mail.gmail.com>
	<1813712325.20120904213459@eikelenboom.it>
	<048EAD622912254A9DEA24C1734613C18C864C3C5D@FTLPMAILBOX02.citrite.net>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <048EAD622912254A9DEA24C1734613C18C864C3C5D@FTLPMAILBOX02.citrite.net>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: Sander Eikelenboom <linux@eikelenboom.it>, Ben Guthro <ben@guthro.net>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] dom0 linux 3.6.0-rc4,
 crash due to ballooning althoug dom0_mem=X, max:X set
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Sep 04, 2012 at 04:27:20PM -0400, Robert Phillips wrote:
> Ben,
> 
> You have asked me to provide the rationale behind the gnttab_old_mfn patch, which you emailed to Sander earlier today. 
> Here are my findings.
> 
> I found that xen_blkbk_map() in drivers/block/xen-blkback/blkback.c has changed from our previous version.  It now calls gnttab_map_refs() in drivers/xen/grant-table.c.
> 
> That function first calls HYPERVISOR_grant_table_op(GNTTABOP_map_grant_ref, ... ) and then calls m2p_add_override() in p2m.c

And HYPERVISOR_grant_table_op .. would populate map_ops[i].bus_addr with the machine address..

> which is where I made my change.
> 
> The unpatched code was saving the pfn's old mfn in kmap_op->dev_bus_addr.  
> 
> kmap_op is of type struct gnttab_map_grant_ref.  That data type is used to record grant table mappings so later they can be unmapped correctly.

Right, but the blkback makes a distinction by passing NULL as kmap_op, which means it should
use the old mechanism. Meaning that once the hypercall is done, the map_ops[i].bus_addr is not
used anymore..

> 
> The problem with saving the old mfn in kmap_op->dev_bus_addr is that it is later overwritten by __gnttab_map_grant_ref() in xen/common/grant_table.c

Uh, so the problem of saving the old mfn in dev_bus_addr has been there for a long long time then?
Even before this patch set?
> 
> Since the storage holding the old mfn got overwritten, the unmapping was being done incorrectly.  The balloon code detected that and bugged at drivers/xen/balloon.c:359
> 

Hmm, I believe the storage for holding the old mfn was/is page->index.


> My patch simply adds another member called old_mfn to struct gnttab_map_grant_ref rather than trying to overload dev_bus_addr.
> 
> I don't know if Sander's bug is the same or related.  The BUG_ON at drivers/xen/balloon.c:359 is quite general.  It simply asserts that we are not trying to re-map a valid mapping.

Right. Somehow he ends up with valid mappings where there should be none. And lots of them.
> 
> -- Robert Phillips
> 
> 
> -----Original Message-----
> From: Sander Eikelenboom [mailto:linux@eikelenboom.it] 
> Sent: Tuesday, September 04, 2012 3:35 PM
> To: Ben Guthro
> Cc: Konrad Rzeszutek Wilk; xen-devel@lists.xen.org; Robert Phillips
> Subject: Re: [Xen-devel] dom0 linux 3.6.0-rc4, crash due to ballooning althoug dom0_mem=X, max:X set
> 
> 
> Tuesday, September 4, 2012, 8:07:11 PM, you wrote:
> 
> > We ran into the same issue, in newer kernels - but had not yet
> > submitted this fix.
> 
> > One of the developers here came up with a fix (attached, and CC'ed
> > here) that fixes an issue where the p2m code reuses a structure member
> > where it shouldn't.
> > The patch adds a new "old_mfn"  member to the gnttab_map_grant_ref
> > structure, instead of re-using  dev_bus_addr.
> 
> 
> > If this also works for you, I can re-submit it with a Signed-off-by
> > line, if you prefer, Konrad.
> 
> Hi Ben,
> 
> This patch doesn't work for me:
> 
> When starting the PV-guest i get:
> 
> (XEN) [2012-09-04 20:31:37] grant_table.c:499:d0 Bad flags in grant map op (68b69070).
> (XEN) [2012-09-04 20:31:37] grant_table.c:499:d0 Bad flags in grant map op (0).
> (XEN) [2012-09-04 20:31:37] grant_table.c:499:d0 Bad flags in grant map op (0).
> 
> 
> and from the dom0 kernel:
> 
> [  374.425727] BUG: unable to handle kernel paging request at ffff8800fffd9078
> [  374.428901] IP: [<ffffffff81336e4e>] gnttab_map_refs+0x14e/0x270
> [  374.428901] PGD 1e0c067 PUD 0
> [  374.428901] Oops: 0000 [#1] PREEMPT SMP
> [  374.428901] Modules linked in:
> [  374.428901] CPU 0
> [  374.428901] Pid: 4308, comm: qemu-system-i38 Not tainted 3.6.0-rc4-20120830+ #70 System manufacturer System Product Name/P5Q-EM DO
> [  374.428901] RIP: e030:[<ffffffff81336e4e>]  [<ffffffff81336e4e>] gnttab_map_refs+0x14e/0x270
> [  374.428901] RSP: e02b:ffff88002f185ca8  EFLAGS: 00010206
> [  374.428901] RAX: ffff880000000000 RBX: ffff88001471cf00 RCX: 00000000fffd9078
> [  374.428901] RDX: 0000000000000050 RSI: 40000000000fffd9 RDI: 00003ffffffff000
> [  374.428901] RBP: ffff88002f185d08 R08: 0000000000000078 R09: 0000000000000000
> [  374.428901] R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000004
> [  374.428901] R13: ffff88001471c480 R14: 0000000000000002 R15: 0000000000000002
> [  374.428901] FS:  00007f6def9f2740(0000) GS:ffff88003fc00000(0000) knlGS:0000000000000000
> [  374.428901] CS:  e033 DS: 0000 ES: 0000 CR0: 000000008005003b
> [  374.428901] CR2: ffff8800fffd9078 CR3: 000000002d30e000 CR4: 0000000000042660
> [  374.428901] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> [  374.428901] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
> [  374.428901] Process qemu-system-i38 (pid: 4308, threadinfo ffff88002f184000, task ffff8800376f1040)
> [  374.428901] Stack:
> [  374.428901]  ffffffffffffffff 0000000000000050 00000000fffd9078 00000000000fffd9
> [  374.428901]  0000000001000000 ffff8800382135a0 ffff88002f185d08 ffff880038211960
> [  374.428901]  ffff88002f11d2c0 0000000000000004 0000000000000003 0000000000000001
> [  374.428901] Call Trace:
> [  374.428901]  [<ffffffff8134212e>] gntdev_mmap+0x20e/0x520
> [  374.428901]  [<ffffffff8111c502>] ? mmap_region+0x312/0x5a0
> [  374.428901]  [<ffffffff810ae0a0>] ? lockdep_trace_alloc+0xa0/0x130
> [  374.428901]  [<ffffffff8111c5be>] mmap_region+0x3ce/0x5a0
> [  374.428901]  [<ffffffff8111c9e0>] do_mmap_pgoff+0x250/0x350
> [  374.428901]  [<ffffffff81109e88>] vm_mmap_pgoff+0x68/0x90
> [  374.428901]  [<ffffffff8111a5b2>] sys_mmap_pgoff+0x152/0x170
> [  374.428901]  [<ffffffff812b29be>] ? trace_hardirqs_on_thunk+0x3a/0x3f
> [  374.428901]  [<ffffffff81011f29>] sys_mmap+0x29/0x30
> [  374.428901]  [<ffffffff8184b939>] system_call_fastpath+0x16/0x1b
> [  374.428901] Code: 0f 84 e7 00 00 00 48 89 f1 48 c1 e1 0c 41 81 e0 ff 0f 00 00 48 b8 00 00 00 00 00 88 ff ff 48 bf 00 f0 ff ff ff 3f 00 00 4c 01 c1 <48> 23 3c 01 48 c1 ef 0c 49 8d 54 15 00 4d 85 ed b8 00 00 00 00
> [  374.428901] RIP  [<ffffffff81336e4e>] gnttab_map_refs+0x14e/0x270
> [  374.428901]  RSP <ffff88002f185ca8>
> [  374.428901] CR2: ffff8800fffd9078
> [  374.428901] ---[ end trace 0e0a5a49f6503c0a ]---
> 
> 
> 
> > Ben
> 
> 
> > On Tue, Sep 4, 2012 at 1:19 PM, Sander Eikelenboom <linux@eikelenboom.it> wrote:
> >>
> >> Tuesday, September 4, 2012, 6:33:47 PM, you wrote:
> >>
> >>> On Tue, Sep 04, 2012 at 06:37:57PM +0200, Sander Eikelenboom wrote:
> >>>> Hi Konrad,
> >>>>
> >>>> This seems to happen only on a intel machine i'm trying to setup as a development machine (haven't seen it on my amd).
> >>>> It boots fine, i have dom0_mem=1024M,max:1024M set, the machine has 2G of mem.
> >>
> >>> Is this only with Xen 4.2? As, does Xen 4.1 work?
> >>>>
> >>>> Dom0 and guest kernel are 3.6.0-rc4 with config:
> >>
> >>> If you back out:
> >>
> >>> f393387d160211f60398d58463a7e65
> >>> Author: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> >>> Date:   Fri Aug 17 16:43:28 2012 -0400
> >>
> >>>     xen/setup: Fix one-off error when adding for-balloon PFNs to the P2M.
> >>
> >>> Do you see this bug? (Either with Xen 4.1 or Xen 4.2)?
> >>
> >> With c96aae1f7f393387d160211f60398d58463a7e65 reverted i still see this bug (with Xen 4.2).
> >>
> >> Will use the debug patch you mailed and send back the results ...
> >>
> >>
> >>>> [*] Xen memory balloon driver
> >>>> [*]   Scrub pages before returning them to system
> >>>>
> >>>> From http://wiki.xen.org/wiki/Do%EF%BB%BFm0_Memory_%E2%80%94_Where_It_Has_Not_Gone , I thought this should be okay
> >>>>
> >>>> But when trying to start a PV guest with 512MB mem, the machine (dom0) crashes with the stacktrace below (complete serial-log.txt attached).
> >>>>
> >>>> From the:
> >>>> "mapping kernel into physical memory
> >>>> about to get started..."
> >>>>
> >>>> I would almost say it's trying to reload dom0 ?
> >>>>
> >>>>
> >>>> [  897.161119] device vif1.0 entered promiscuous mode
> >>>> mapping kernel into physical memory
> >>>> about to get started...
> >>>> [  897.696619] xen_bridge: port 1(vif1.0) entered forwarding state
> >>>> [  897.716219] xen_bridge: port 1(vif1.0) entered forwarding state
> >>>> [  898.129465] ------------[ cut here ]------------
> >>>> [  898.132209] kernel BUG at drivers/xen/balloon.c:359!
> >>>> [  898.132209] invalid opcode: 0000 [#1] PREEMPT SMP
> >>
> >>
> >>
> >> _______________________________________________
> >> Xen-devel mailing list
> >> Xen-devel@lists.xen.org
> >> http://lists.xen.org/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 Sep 05 14:17:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Sep 2012 14:17:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9GPV-0001U6-27; Wed, 05 Sep 2012 14:16:53 +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 1T9GPT-0001Ts-If
	for xen-devel@lists.xen.org; Wed, 05 Sep 2012 14:16:51 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1346854598!8619041!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzI4NDYw\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27817 invoked from network); 5 Sep 2012 14:16:40 -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 Sep 2012 14:16:40 -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 q85EGWrL020067
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 5 Sep 2012 14:16: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
	q85EGVBU025820
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 5 Sep 2012 14:16:31 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
	q85EGVrR019423; Wed, 5 Sep 2012 09:16:31 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 05 Sep 2012 07:16:31 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 176C9402C1; Wed,  5 Sep 2012 10:06:01 -0400 (EDT)
Date: Wed, 5 Sep 2012 10:06:01 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Robert Phillips <robert.phillips@citrix.com>
Message-ID: <20120905140600.GA5844@phenom.dumpdata.com>
References: <1136369816.20120904183757@eikelenboom.it>
	<20120904163347.GH23361@phenom.dumpdata.com>
	<143844933.20120904191941@eikelenboom.it>
	<CAOvdn6U_yHgtZwv9MWazdLbd3NLq3pwGXnZY5sL2UVBhV_FUoQ@mail.gmail.com>
	<1813712325.20120904213459@eikelenboom.it>
	<048EAD622912254A9DEA24C1734613C18C864C3C5D@FTLPMAILBOX02.citrite.net>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <048EAD622912254A9DEA24C1734613C18C864C3C5D@FTLPMAILBOX02.citrite.net>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: Sander Eikelenboom <linux@eikelenboom.it>, Ben Guthro <ben@guthro.net>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] dom0 linux 3.6.0-rc4,
 crash due to ballooning althoug dom0_mem=X, max:X set
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Sep 04, 2012 at 04:27:20PM -0400, Robert Phillips wrote:
> Ben,
> 
> You have asked me to provide the rationale behind the gnttab_old_mfn patch, which you emailed to Sander earlier today. 
> Here are my findings.
> 
> I found that xen_blkbk_map() in drivers/block/xen-blkback/blkback.c has changed from our previous version.  It now calls gnttab_map_refs() in drivers/xen/grant-table.c.
> 
> That function first calls HYPERVISOR_grant_table_op(GNTTABOP_map_grant_ref, ... ) and then calls m2p_add_override() in p2m.c

And HYPERVISOR_grant_table_op .. would populate map_ops[i].bus_addr with the machine address..

> which is where I made my change.
> 
> The unpatched code was saving the pfn's old mfn in kmap_op->dev_bus_addr.  
> 
> kmap_op is of type struct gnttab_map_grant_ref.  That data type is used to record grant table mappings so later they can be unmapped correctly.

Right, but the blkback makes a distinction by passing NULL as kmap_op, which means it should
use the old mechanism. Meaning that once the hypercall is done, the map_ops[i].bus_addr is not
used anymore..

> 
> The problem with saving the old mfn in kmap_op->dev_bus_addr is that it is later overwritten by __gnttab_map_grant_ref() in xen/common/grant_table.c

Uh, so the problem of saving the old mfn in dev_bus_addr has been there for a long long time then?
Even before this patch set?
> 
> Since the storage holding the old mfn got overwritten, the unmapping was being done incorrectly.  The balloon code detected that and bugged at drivers/xen/balloon.c:359
> 

Hmm, I believe the storage for holding the old mfn was/is page->index.


> My patch simply adds another member called old_mfn to struct gnttab_map_grant_ref rather than trying to overload dev_bus_addr.
> 
> I don't know if Sander's bug is the same or related.  The BUG_ON at drivers/xen/balloon.c:359 is quite general.  It simply asserts that we are not trying to re-map a valid mapping.

Right. Somehow he ends up with valid mappings where there should be none. And lots of them.
> 
> -- Robert Phillips
> 
> 
> -----Original Message-----
> From: Sander Eikelenboom [mailto:linux@eikelenboom.it] 
> Sent: Tuesday, September 04, 2012 3:35 PM
> To: Ben Guthro
> Cc: Konrad Rzeszutek Wilk; xen-devel@lists.xen.org; Robert Phillips
> Subject: Re: [Xen-devel] dom0 linux 3.6.0-rc4, crash due to ballooning althoug dom0_mem=X, max:X set
> 
> 
> Tuesday, September 4, 2012, 8:07:11 PM, you wrote:
> 
> > We ran into the same issue, in newer kernels - but had not yet
> > submitted this fix.
> 
> > One of the developers here came up with a fix (attached, and CC'ed
> > here) that fixes an issue where the p2m code reuses a structure member
> > where it shouldn't.
> > The patch adds a new "old_mfn"  member to the gnttab_map_grant_ref
> > structure, instead of re-using  dev_bus_addr.
> 
> 
> > If this also works for you, I can re-submit it with a Signed-off-by
> > line, if you prefer, Konrad.
> 
> Hi Ben,
> 
> This patch doesn't work for me:
> 
> When starting the PV-guest i get:
> 
> (XEN) [2012-09-04 20:31:37] grant_table.c:499:d0 Bad flags in grant map op (68b69070).
> (XEN) [2012-09-04 20:31:37] grant_table.c:499:d0 Bad flags in grant map op (0).
> (XEN) [2012-09-04 20:31:37] grant_table.c:499:d0 Bad flags in grant map op (0).
> 
> 
> and from the dom0 kernel:
> 
> [  374.425727] BUG: unable to handle kernel paging request at ffff8800fffd9078
> [  374.428901] IP: [<ffffffff81336e4e>] gnttab_map_refs+0x14e/0x270
> [  374.428901] PGD 1e0c067 PUD 0
> [  374.428901] Oops: 0000 [#1] PREEMPT SMP
> [  374.428901] Modules linked in:
> [  374.428901] CPU 0
> [  374.428901] Pid: 4308, comm: qemu-system-i38 Not tainted 3.6.0-rc4-20120830+ #70 System manufacturer System Product Name/P5Q-EM DO
> [  374.428901] RIP: e030:[<ffffffff81336e4e>]  [<ffffffff81336e4e>] gnttab_map_refs+0x14e/0x270
> [  374.428901] RSP: e02b:ffff88002f185ca8  EFLAGS: 00010206
> [  374.428901] RAX: ffff880000000000 RBX: ffff88001471cf00 RCX: 00000000fffd9078
> [  374.428901] RDX: 0000000000000050 RSI: 40000000000fffd9 RDI: 00003ffffffff000
> [  374.428901] RBP: ffff88002f185d08 R08: 0000000000000078 R09: 0000000000000000
> [  374.428901] R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000004
> [  374.428901] R13: ffff88001471c480 R14: 0000000000000002 R15: 0000000000000002
> [  374.428901] FS:  00007f6def9f2740(0000) GS:ffff88003fc00000(0000) knlGS:0000000000000000
> [  374.428901] CS:  e033 DS: 0000 ES: 0000 CR0: 000000008005003b
> [  374.428901] CR2: ffff8800fffd9078 CR3: 000000002d30e000 CR4: 0000000000042660
> [  374.428901] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> [  374.428901] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
> [  374.428901] Process qemu-system-i38 (pid: 4308, threadinfo ffff88002f184000, task ffff8800376f1040)
> [  374.428901] Stack:
> [  374.428901]  ffffffffffffffff 0000000000000050 00000000fffd9078 00000000000fffd9
> [  374.428901]  0000000001000000 ffff8800382135a0 ffff88002f185d08 ffff880038211960
> [  374.428901]  ffff88002f11d2c0 0000000000000004 0000000000000003 0000000000000001
> [  374.428901] Call Trace:
> [  374.428901]  [<ffffffff8134212e>] gntdev_mmap+0x20e/0x520
> [  374.428901]  [<ffffffff8111c502>] ? mmap_region+0x312/0x5a0
> [  374.428901]  [<ffffffff810ae0a0>] ? lockdep_trace_alloc+0xa0/0x130
> [  374.428901]  [<ffffffff8111c5be>] mmap_region+0x3ce/0x5a0
> [  374.428901]  [<ffffffff8111c9e0>] do_mmap_pgoff+0x250/0x350
> [  374.428901]  [<ffffffff81109e88>] vm_mmap_pgoff+0x68/0x90
> [  374.428901]  [<ffffffff8111a5b2>] sys_mmap_pgoff+0x152/0x170
> [  374.428901]  [<ffffffff812b29be>] ? trace_hardirqs_on_thunk+0x3a/0x3f
> [  374.428901]  [<ffffffff81011f29>] sys_mmap+0x29/0x30
> [  374.428901]  [<ffffffff8184b939>] system_call_fastpath+0x16/0x1b
> [  374.428901] Code: 0f 84 e7 00 00 00 48 89 f1 48 c1 e1 0c 41 81 e0 ff 0f 00 00 48 b8 00 00 00 00 00 88 ff ff 48 bf 00 f0 ff ff ff 3f 00 00 4c 01 c1 <48> 23 3c 01 48 c1 ef 0c 49 8d 54 15 00 4d 85 ed b8 00 00 00 00
> [  374.428901] RIP  [<ffffffff81336e4e>] gnttab_map_refs+0x14e/0x270
> [  374.428901]  RSP <ffff88002f185ca8>
> [  374.428901] CR2: ffff8800fffd9078
> [  374.428901] ---[ end trace 0e0a5a49f6503c0a ]---
> 
> 
> 
> > Ben
> 
> 
> > On Tue, Sep 4, 2012 at 1:19 PM, Sander Eikelenboom <linux@eikelenboom.it> wrote:
> >>
> >> Tuesday, September 4, 2012, 6:33:47 PM, you wrote:
> >>
> >>> On Tue, Sep 04, 2012 at 06:37:57PM +0200, Sander Eikelenboom wrote:
> >>>> Hi Konrad,
> >>>>
> >>>> This seems to happen only on a intel machine i'm trying to setup as a development machine (haven't seen it on my amd).
> >>>> It boots fine, i have dom0_mem=1024M,max:1024M set, the machine has 2G of mem.
> >>
> >>> Is this only with Xen 4.2? As, does Xen 4.1 work?
> >>>>
> >>>> Dom0 and guest kernel are 3.6.0-rc4 with config:
> >>
> >>> If you back out:
> >>
> >>> f393387d160211f60398d58463a7e65
> >>> Author: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> >>> Date:   Fri Aug 17 16:43:28 2012 -0400
> >>
> >>>     xen/setup: Fix one-off error when adding for-balloon PFNs to the P2M.
> >>
> >>> Do you see this bug? (Either with Xen 4.1 or Xen 4.2)?
> >>
> >> With c96aae1f7f393387d160211f60398d58463a7e65 reverted i still see this bug (with Xen 4.2).
> >>
> >> Will use the debug patch you mailed and send back the results ...
> >>
> >>
> >>>> [*] Xen memory balloon driver
> >>>> [*]   Scrub pages before returning them to system
> >>>>
> >>>> From http://wiki.xen.org/wiki/Do%EF%BB%BFm0_Memory_%E2%80%94_Where_It_Has_Not_Gone , I thought this should be okay
> >>>>
> >>>> But when trying to start a PV guest with 512MB mem, the machine (dom0) crashes with the stacktrace below (complete serial-log.txt attached).
> >>>>
> >>>> From the:
> >>>> "mapping kernel into physical memory
> >>>> about to get started..."
> >>>>
> >>>> I would almost say it's trying to reload dom0 ?
> >>>>
> >>>>
> >>>> [  897.161119] device vif1.0 entered promiscuous mode
> >>>> mapping kernel into physical memory
> >>>> about to get started...
> >>>> [  897.696619] xen_bridge: port 1(vif1.0) entered forwarding state
> >>>> [  897.716219] xen_bridge: port 1(vif1.0) entered forwarding state
> >>>> [  898.129465] ------------[ cut here ]------------
> >>>> [  898.132209] kernel BUG at drivers/xen/balloon.c:359!
> >>>> [  898.132209] invalid opcode: 0000 [#1] PREEMPT SMP
> >>
> >>
> >>
> >> _______________________________________________
> >> Xen-devel mailing list
> >> Xen-devel@lists.xen.org
> >> http://lists.xen.org/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 Sep 05 14:39:29 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Sep 2012 14:39:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9Gkq-0001t0-F2; Wed, 05 Sep 2012 14:38:56 +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 1T9Gko-0001sv-Sl
	for xen-devel@lists.xen.org; Wed, 05 Sep 2012 14:38:55 +0000
Received: from [85.158.143.99:35616] by server-1.bemta-4.messagelabs.com id
	D4/E6-12504-DF367405; Wed, 05 Sep 2012 14:38:53 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-11.tower-216.messagelabs.com!1346855932!21168419!1
X-Originating-IP: [188.40.164.121]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13233 invoked from network); 5 Sep 2012 14:38:53 -0000
Received: from static.121.164.40.188.clients.your-server.de (HELO
	smtp.eikelenboom.it) (188.40.164.121)
	by server-11.tower-216.messagelabs.com with AES256-SHA encrypted SMTP;
	5 Sep 2012 14:38:53 -0000
Received: from 128-64-ftth.onsneteindhoven.nl ([88.159.64.128]:52270
	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 1T9Ghj-0000WS-VQ; Wed, 05 Sep 2012 16:35:44 +0200
Date: Wed, 5 Sep 2012 16:38:48 +0200
From: Sander Eikelenboom <linux@eikelenboom.it>
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <1014998302.20120905163848@eikelenboom.it>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
In-Reply-To: <20120905140600.GA5844@phenom.dumpdata.com>
References: <1136369816.20120904183757@eikelenboom.it>
	<20120904163347.GH23361@phenom.dumpdata.com>
	<143844933.20120904191941@eikelenboom.it>
	<CAOvdn6U_yHgtZwv9MWazdLbd3NLq3pwGXnZY5sL2UVBhV_FUoQ@mail.gmail.com>
	<1813712325.20120904213459@eikelenboom.it>
	<048EAD622912254A9DEA24C1734613C18C864C3C5D@FTLPMAILBOX02.citrite.net>
	<20120905140600.GA5844@phenom.dumpdata.com>
MIME-Version: 1.0
Cc: Robert Phillips <robert.phillips@citrix.com>, Ben Guthro <ben@guthro.net>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] dom0 linux 3.6.0-rc4,
	crash due to ballooning althoug dom0_mem=X, max:X 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


Wednesday, September 5, 2012, 4:06:01 PM, you wrote:

> On Tue, Sep 04, 2012 at 04:27:20PM -0400, Robert Phillips wrote:
>> Ben,
>> 
>> You have asked me to provide the rationale behind the gnttab_old_mfn patch, which you emailed to Sander earlier today. 
>> Here are my findings.
>> 
>> I found that xen_blkbk_map() in drivers/block/xen-blkback/blkback.c has changed from our previous version.  It now calls gnttab_map_refs() in drivers/xen/grant-table.c.
>> 
>> That function first calls HYPERVISOR_grant_table_op(GNTTABOP_map_grant_ref, ... ) and then calls m2p_add_override() in p2m.c

> And HYPERVISOR_grant_table_op .. would populate map_ops[i].bus_addr with the machine address..

>> which is where I made my change.
>> 
>> The unpatched code was saving the pfn's old mfn in kmap_op->dev_bus_addr.  
>> 
>> kmap_op is of type struct gnttab_map_grant_ref.  That data type is used to record grant table mappings so later they can be unmapped correctly.

> Right, but the blkback makes a distinction by passing NULL as kmap_op, which means it should
> use the old mechanism. Meaning that once the hypercall is done, the map_ops[i].bus_addr is not
> used anymore..

>> 
>> The problem with saving the old mfn in kmap_op->dev_bus_addr is that it is later overwritten by __gnttab_map_grant_ref() in xen/common/grant_table.c

> Uh, so the problem of saving the old mfn in dev_bus_addr has been there for a long long time then?
> Even before this patch set?
>> 
>> Since the storage holding the old mfn got overwritten, the unmapping was being done incorrectly.  The balloon code detected that and bugged at drivers/xen/balloon.c:359
>> 

> Hmm, I believe the storage for holding the old mfn was/is page->index.


>> My patch simply adds another member called old_mfn to struct gnttab_map_grant_ref rather than trying to overload dev_bus_addr.
>> 
>> I don't know if Sander's bug is the same or related.  The BUG_ON at drivers/xen/balloon.c:359 is quite general.  It simply asserts that we are not trying to re-map a valid mapping.

> Right. Somehow he ends up with valid mappings where there should be none. And lots of them.

It's something between kernel v3.4.1 and v3.5.3, haven't had time to narrow it down yet.
Any suggestions for specific commits i could try to quickly bisect this one ?


>> 
>> -- Robert Phillips
>> 
>> 
>> -----Original Message-----
>> From: Sander Eikelenboom [mailto:linux@eikelenboom.it] 
>> Sent: Tuesday, September 04, 2012 3:35 PM
>> To: Ben Guthro
>> Cc: Konrad Rzeszutek Wilk; xen-devel@lists.xen.org; Robert Phillips
>> Subject: Re: [Xen-devel] dom0 linux 3.6.0-rc4, crash due to ballooning althoug dom0_mem=X, max:X set
>> 
>> 
>> Tuesday, September 4, 2012, 8:07:11 PM, you wrote:
>> 
>> > We ran into the same issue, in newer kernels - but had not yet
>> > submitted this fix.
>> 
>> > One of the developers here came up with a fix (attached, and CC'ed
>> > here) that fixes an issue where the p2m code reuses a structure member
>> > where it shouldn't.
>> > The patch adds a new "old_mfn"  member to the gnttab_map_grant_ref
>> > structure, instead of re-using  dev_bus_addr.
>> 
>> 
>> > If this also works for you, I can re-submit it with a Signed-off-by
>> > line, if you prefer, Konrad.
>> 
>> Hi Ben,
>> 
>> This patch doesn't work for me:
>> 
>> When starting the PV-guest i get:
>> 
>> (XEN) [2012-09-04 20:31:37] grant_table.c:499:d0 Bad flags in grant map op (68b69070).
>> (XEN) [2012-09-04 20:31:37] grant_table.c:499:d0 Bad flags in grant map op (0).
>> (XEN) [2012-09-04 20:31:37] grant_table.c:499:d0 Bad flags in grant map op (0).
>> 
>> 
>> and from the dom0 kernel:
>> 
>> [  374.425727] BUG: unable to handle kernel paging request at ffff8800fffd9078
>> [  374.428901] IP: [<ffffffff81336e4e>] gnttab_map_refs+0x14e/0x270
>> [  374.428901] PGD 1e0c067 PUD 0
>> [  374.428901] Oops: 0000 [#1] PREEMPT SMP
>> [  374.428901] Modules linked in:
>> [  374.428901] CPU 0
>> [  374.428901] Pid: 4308, comm: qemu-system-i38 Not tainted 3.6.0-rc4-20120830+ #70 System manufacturer System Product Name/P5Q-EM DO
>> [  374.428901] RIP: e030:[<ffffffff81336e4e>]  [<ffffffff81336e4e>] gnttab_map_refs+0x14e/0x270
>> [  374.428901] RSP: e02b:ffff88002f185ca8  EFLAGS: 00010206
>> [  374.428901] RAX: ffff880000000000 RBX: ffff88001471cf00 RCX: 00000000fffd9078
>> [  374.428901] RDX: 0000000000000050 RSI: 40000000000fffd9 RDI: 00003ffffffff000
>> [  374.428901] RBP: ffff88002f185d08 R08: 0000000000000078 R09: 0000000000000000
>> [  374.428901] R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000004
>> [  374.428901] R13: ffff88001471c480 R14: 0000000000000002 R15: 0000000000000002
>> [  374.428901] FS:  00007f6def9f2740(0000) GS:ffff88003fc00000(0000) knlGS:0000000000000000
>> [  374.428901] CS:  e033 DS: 0000 ES: 0000 CR0: 000000008005003b
>> [  374.428901] CR2: ffff8800fffd9078 CR3: 000000002d30e000 CR4: 0000000000042660
>> [  374.428901] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
>> [  374.428901] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
>> [  374.428901] Process qemu-system-i38 (pid: 4308, threadinfo ffff88002f184000, task ffff8800376f1040)
>> [  374.428901] Stack:
>> [  374.428901]  ffffffffffffffff 0000000000000050 00000000fffd9078 00000000000fffd9
>> [  374.428901]  0000000001000000 ffff8800382135a0 ffff88002f185d08 ffff880038211960
>> [  374.428901]  ffff88002f11d2c0 0000000000000004 0000000000000003 0000000000000001
>> [  374.428901] Call Trace:
>> [  374.428901]  [<ffffffff8134212e>] gntdev_mmap+0x20e/0x520
>> [  374.428901]  [<ffffffff8111c502>] ? mmap_region+0x312/0x5a0
>> [  374.428901]  [<ffffffff810ae0a0>] ? lockdep_trace_alloc+0xa0/0x130
>> [  374.428901]  [<ffffffff8111c5be>] mmap_region+0x3ce/0x5a0
>> [  374.428901]  [<ffffffff8111c9e0>] do_mmap_pgoff+0x250/0x350
>> [  374.428901]  [<ffffffff81109e88>] vm_mmap_pgoff+0x68/0x90
>> [  374.428901]  [<ffffffff8111a5b2>] sys_mmap_pgoff+0x152/0x170
>> [  374.428901]  [<ffffffff812b29be>] ? trace_hardirqs_on_thunk+0x3a/0x3f
>> [  374.428901]  [<ffffffff81011f29>] sys_mmap+0x29/0x30
>> [  374.428901]  [<ffffffff8184b939>] system_call_fastpath+0x16/0x1b
>> [  374.428901] Code: 0f 84 e7 00 00 00 48 89 f1 48 c1 e1 0c 41 81 e0 ff 0f 00 00 48 b8 00 00 00 00 00 88 ff ff 48 bf 00 f0 ff ff ff 3f 00 00 4c 01 c1 <48> 23 3c 01 48 c1 ef 0c 49 8d 54 15 00 4d 85 ed b8 00 00 00 00
>> [  374.428901] RIP  [<ffffffff81336e4e>] gnttab_map_refs+0x14e/0x270
>> [  374.428901]  RSP <ffff88002f185ca8>
>> [  374.428901] CR2: ffff8800fffd9078
>> [  374.428901] ---[ end trace 0e0a5a49f6503c0a ]---
>> 
>> 
>> 
>> > Ben
>> 
>> 
>> > On Tue, Sep 4, 2012 at 1:19 PM, Sander Eikelenboom <linux@eikelenboom.it> wrote:
>> >>
>> >> Tuesday, September 4, 2012, 6:33:47 PM, you wrote:
>> >>
>> >>> On Tue, Sep 04, 2012 at 06:37:57PM +0200, Sander Eikelenboom wrote:
>> >>>> Hi Konrad,
>> >>>>
>> >>>> This seems to happen only on a intel machine i'm trying to setup as a development machine (haven't seen it on my amd).
>> >>>> It boots fine, i have dom0_mem=1024M,max:1024M set, the machine has 2G of mem.
>> >>
>> >>> Is this only with Xen 4.2? As, does Xen 4.1 work?
>> >>>>
>> >>>> Dom0 and guest kernel are 3.6.0-rc4 with config:
>> >>
>> >>> If you back out:
>> >>
>> >>> f393387d160211f60398d58463a7e65
>> >>> Author: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
>> >>> Date:   Fri Aug 17 16:43:28 2012 -0400
>> >>
>> >>>     xen/setup: Fix one-off error when adding for-balloon PFNs to the P2M.
>> >>
>> >>> Do you see this bug? (Either with Xen 4.1 or Xen 4.2)?
>> >>
>> >> With c96aae1f7f393387d160211f60398d58463a7e65 reverted i still see this bug (with Xen 4.2).
>> >>
>> >> Will use the debug patch you mailed and send back the results ...
>> >>
>> >>
>> >>>> [*] Xen memory balloon driver
>> >>>> [*]   Scrub pages before returning them to system
>> >>>>
>> >>>> From http://wiki.xen.org/wiki/Do%EF%BB%BFm0_Memory_%E2%80%94_Where_It_Has_Not_Gone , I thought this should be okay
>> >>>>
>> >>>> But when trying to start a PV guest with 512MB mem, the machine (dom0) crashes with the stacktrace below (complete serial-log.txt attached).
>> >>>>
>> >>>> From the:
>> >>>> "mapping kernel into physical memory
>> >>>> about to get started..."
>> >>>>
>> >>>> I would almost say it's trying to reload dom0 ?
>> >>>>
>> >>>>
>> >>>> [  897.161119] device vif1.0 entered promiscuous mode
>> >>>> mapping kernel into physical memory
>> >>>> about to get started...
>> >>>> [  897.696619] xen_bridge: port 1(vif1.0) entered forwarding state
>> >>>> [  897.716219] xen_bridge: port 1(vif1.0) entered forwarding state
>> >>>> [  898.129465] ------------[ cut here ]------------
>> >>>> [  898.132209] kernel BUG at drivers/xen/balloon.c:359!
>> >>>> [  898.132209] invalid opcode: 0000 [#1] PREEMPT SMP
>> >>
>> >>
>> >>
>> >> _______________________________________________
>> >> Xen-devel mailing list
>> >> Xen-devel@lists.xen.org
>> >> http://lists.xen.org/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 Sep 05 14:39:29 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Sep 2012 14:39:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9Gkq-0001t0-F2; Wed, 05 Sep 2012 14:38:56 +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 1T9Gko-0001sv-Sl
	for xen-devel@lists.xen.org; Wed, 05 Sep 2012 14:38:55 +0000
Received: from [85.158.143.99:35616] by server-1.bemta-4.messagelabs.com id
	D4/E6-12504-DF367405; Wed, 05 Sep 2012 14:38:53 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-11.tower-216.messagelabs.com!1346855932!21168419!1
X-Originating-IP: [188.40.164.121]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13233 invoked from network); 5 Sep 2012 14:38:53 -0000
Received: from static.121.164.40.188.clients.your-server.de (HELO
	smtp.eikelenboom.it) (188.40.164.121)
	by server-11.tower-216.messagelabs.com with AES256-SHA encrypted SMTP;
	5 Sep 2012 14:38:53 -0000
Received: from 128-64-ftth.onsneteindhoven.nl ([88.159.64.128]:52270
	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 1T9Ghj-0000WS-VQ; Wed, 05 Sep 2012 16:35:44 +0200
Date: Wed, 5 Sep 2012 16:38:48 +0200
From: Sander Eikelenboom <linux@eikelenboom.it>
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <1014998302.20120905163848@eikelenboom.it>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
In-Reply-To: <20120905140600.GA5844@phenom.dumpdata.com>
References: <1136369816.20120904183757@eikelenboom.it>
	<20120904163347.GH23361@phenom.dumpdata.com>
	<143844933.20120904191941@eikelenboom.it>
	<CAOvdn6U_yHgtZwv9MWazdLbd3NLq3pwGXnZY5sL2UVBhV_FUoQ@mail.gmail.com>
	<1813712325.20120904213459@eikelenboom.it>
	<048EAD622912254A9DEA24C1734613C18C864C3C5D@FTLPMAILBOX02.citrite.net>
	<20120905140600.GA5844@phenom.dumpdata.com>
MIME-Version: 1.0
Cc: Robert Phillips <robert.phillips@citrix.com>, Ben Guthro <ben@guthro.net>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] dom0 linux 3.6.0-rc4,
	crash due to ballooning althoug dom0_mem=X, max:X 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


Wednesday, September 5, 2012, 4:06:01 PM, you wrote:

> On Tue, Sep 04, 2012 at 04:27:20PM -0400, Robert Phillips wrote:
>> Ben,
>> 
>> You have asked me to provide the rationale behind the gnttab_old_mfn patch, which you emailed to Sander earlier today. 
>> Here are my findings.
>> 
>> I found that xen_blkbk_map() in drivers/block/xen-blkback/blkback.c has changed from our previous version.  It now calls gnttab_map_refs() in drivers/xen/grant-table.c.
>> 
>> That function first calls HYPERVISOR_grant_table_op(GNTTABOP_map_grant_ref, ... ) and then calls m2p_add_override() in p2m.c

> And HYPERVISOR_grant_table_op .. would populate map_ops[i].bus_addr with the machine address..

>> which is where I made my change.
>> 
>> The unpatched code was saving the pfn's old mfn in kmap_op->dev_bus_addr.  
>> 
>> kmap_op is of type struct gnttab_map_grant_ref.  That data type is used to record grant table mappings so later they can be unmapped correctly.

> Right, but the blkback makes a distinction by passing NULL as kmap_op, which means it should
> use the old mechanism. Meaning that once the hypercall is done, the map_ops[i].bus_addr is not
> used anymore..

>> 
>> The problem with saving the old mfn in kmap_op->dev_bus_addr is that it is later overwritten by __gnttab_map_grant_ref() in xen/common/grant_table.c

> Uh, so the problem of saving the old mfn in dev_bus_addr has been there for a long long time then?
> Even before this patch set?
>> 
>> Since the storage holding the old mfn got overwritten, the unmapping was being done incorrectly.  The balloon code detected that and bugged at drivers/xen/balloon.c:359
>> 

> Hmm, I believe the storage for holding the old mfn was/is page->index.


>> My patch simply adds another member called old_mfn to struct gnttab_map_grant_ref rather than trying to overload dev_bus_addr.
>> 
>> I don't know if Sander's bug is the same or related.  The BUG_ON at drivers/xen/balloon.c:359 is quite general.  It simply asserts that we are not trying to re-map a valid mapping.

> Right. Somehow he ends up with valid mappings where there should be none. And lots of them.

It's something between kernel v3.4.1 and v3.5.3, haven't had time to narrow it down yet.
Any suggestions for specific commits i could try to quickly bisect this one ?


>> 
>> -- Robert Phillips
>> 
>> 
>> -----Original Message-----
>> From: Sander Eikelenboom [mailto:linux@eikelenboom.it] 
>> Sent: Tuesday, September 04, 2012 3:35 PM
>> To: Ben Guthro
>> Cc: Konrad Rzeszutek Wilk; xen-devel@lists.xen.org; Robert Phillips
>> Subject: Re: [Xen-devel] dom0 linux 3.6.0-rc4, crash due to ballooning althoug dom0_mem=X, max:X set
>> 
>> 
>> Tuesday, September 4, 2012, 8:07:11 PM, you wrote:
>> 
>> > We ran into the same issue, in newer kernels - but had not yet
>> > submitted this fix.
>> 
>> > One of the developers here came up with a fix (attached, and CC'ed
>> > here) that fixes an issue where the p2m code reuses a structure member
>> > where it shouldn't.
>> > The patch adds a new "old_mfn"  member to the gnttab_map_grant_ref
>> > structure, instead of re-using  dev_bus_addr.
>> 
>> 
>> > If this also works for you, I can re-submit it with a Signed-off-by
>> > line, if you prefer, Konrad.
>> 
>> Hi Ben,
>> 
>> This patch doesn't work for me:
>> 
>> When starting the PV-guest i get:
>> 
>> (XEN) [2012-09-04 20:31:37] grant_table.c:499:d0 Bad flags in grant map op (68b69070).
>> (XEN) [2012-09-04 20:31:37] grant_table.c:499:d0 Bad flags in grant map op (0).
>> (XEN) [2012-09-04 20:31:37] grant_table.c:499:d0 Bad flags in grant map op (0).
>> 
>> 
>> and from the dom0 kernel:
>> 
>> [  374.425727] BUG: unable to handle kernel paging request at ffff8800fffd9078
>> [  374.428901] IP: [<ffffffff81336e4e>] gnttab_map_refs+0x14e/0x270
>> [  374.428901] PGD 1e0c067 PUD 0
>> [  374.428901] Oops: 0000 [#1] PREEMPT SMP
>> [  374.428901] Modules linked in:
>> [  374.428901] CPU 0
>> [  374.428901] Pid: 4308, comm: qemu-system-i38 Not tainted 3.6.0-rc4-20120830+ #70 System manufacturer System Product Name/P5Q-EM DO
>> [  374.428901] RIP: e030:[<ffffffff81336e4e>]  [<ffffffff81336e4e>] gnttab_map_refs+0x14e/0x270
>> [  374.428901] RSP: e02b:ffff88002f185ca8  EFLAGS: 00010206
>> [  374.428901] RAX: ffff880000000000 RBX: ffff88001471cf00 RCX: 00000000fffd9078
>> [  374.428901] RDX: 0000000000000050 RSI: 40000000000fffd9 RDI: 00003ffffffff000
>> [  374.428901] RBP: ffff88002f185d08 R08: 0000000000000078 R09: 0000000000000000
>> [  374.428901] R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000004
>> [  374.428901] R13: ffff88001471c480 R14: 0000000000000002 R15: 0000000000000002
>> [  374.428901] FS:  00007f6def9f2740(0000) GS:ffff88003fc00000(0000) knlGS:0000000000000000
>> [  374.428901] CS:  e033 DS: 0000 ES: 0000 CR0: 000000008005003b
>> [  374.428901] CR2: ffff8800fffd9078 CR3: 000000002d30e000 CR4: 0000000000042660
>> [  374.428901] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
>> [  374.428901] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
>> [  374.428901] Process qemu-system-i38 (pid: 4308, threadinfo ffff88002f184000, task ffff8800376f1040)
>> [  374.428901] Stack:
>> [  374.428901]  ffffffffffffffff 0000000000000050 00000000fffd9078 00000000000fffd9
>> [  374.428901]  0000000001000000 ffff8800382135a0 ffff88002f185d08 ffff880038211960
>> [  374.428901]  ffff88002f11d2c0 0000000000000004 0000000000000003 0000000000000001
>> [  374.428901] Call Trace:
>> [  374.428901]  [<ffffffff8134212e>] gntdev_mmap+0x20e/0x520
>> [  374.428901]  [<ffffffff8111c502>] ? mmap_region+0x312/0x5a0
>> [  374.428901]  [<ffffffff810ae0a0>] ? lockdep_trace_alloc+0xa0/0x130
>> [  374.428901]  [<ffffffff8111c5be>] mmap_region+0x3ce/0x5a0
>> [  374.428901]  [<ffffffff8111c9e0>] do_mmap_pgoff+0x250/0x350
>> [  374.428901]  [<ffffffff81109e88>] vm_mmap_pgoff+0x68/0x90
>> [  374.428901]  [<ffffffff8111a5b2>] sys_mmap_pgoff+0x152/0x170
>> [  374.428901]  [<ffffffff812b29be>] ? trace_hardirqs_on_thunk+0x3a/0x3f
>> [  374.428901]  [<ffffffff81011f29>] sys_mmap+0x29/0x30
>> [  374.428901]  [<ffffffff8184b939>] system_call_fastpath+0x16/0x1b
>> [  374.428901] Code: 0f 84 e7 00 00 00 48 89 f1 48 c1 e1 0c 41 81 e0 ff 0f 00 00 48 b8 00 00 00 00 00 88 ff ff 48 bf 00 f0 ff ff ff 3f 00 00 4c 01 c1 <48> 23 3c 01 48 c1 ef 0c 49 8d 54 15 00 4d 85 ed b8 00 00 00 00
>> [  374.428901] RIP  [<ffffffff81336e4e>] gnttab_map_refs+0x14e/0x270
>> [  374.428901]  RSP <ffff88002f185ca8>
>> [  374.428901] CR2: ffff8800fffd9078
>> [  374.428901] ---[ end trace 0e0a5a49f6503c0a ]---
>> 
>> 
>> 
>> > Ben
>> 
>> 
>> > On Tue, Sep 4, 2012 at 1:19 PM, Sander Eikelenboom <linux@eikelenboom.it> wrote:
>> >>
>> >> Tuesday, September 4, 2012, 6:33:47 PM, you wrote:
>> >>
>> >>> On Tue, Sep 04, 2012 at 06:37:57PM +0200, Sander Eikelenboom wrote:
>> >>>> Hi Konrad,
>> >>>>
>> >>>> This seems to happen only on a intel machine i'm trying to setup as a development machine (haven't seen it on my amd).
>> >>>> It boots fine, i have dom0_mem=1024M,max:1024M set, the machine has 2G of mem.
>> >>
>> >>> Is this only with Xen 4.2? As, does Xen 4.1 work?
>> >>>>
>> >>>> Dom0 and guest kernel are 3.6.0-rc4 with config:
>> >>
>> >>> If you back out:
>> >>
>> >>> f393387d160211f60398d58463a7e65
>> >>> Author: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
>> >>> Date:   Fri Aug 17 16:43:28 2012 -0400
>> >>
>> >>>     xen/setup: Fix one-off error when adding for-balloon PFNs to the P2M.
>> >>
>> >>> Do you see this bug? (Either with Xen 4.1 or Xen 4.2)?
>> >>
>> >> With c96aae1f7f393387d160211f60398d58463a7e65 reverted i still see this bug (with Xen 4.2).
>> >>
>> >> Will use the debug patch you mailed and send back the results ...
>> >>
>> >>
>> >>>> [*] Xen memory balloon driver
>> >>>> [*]   Scrub pages before returning them to system
>> >>>>
>> >>>> From http://wiki.xen.org/wiki/Do%EF%BB%BFm0_Memory_%E2%80%94_Where_It_Has_Not_Gone , I thought this should be okay
>> >>>>
>> >>>> But when trying to start a PV guest with 512MB mem, the machine (dom0) crashes with the stacktrace below (complete serial-log.txt attached).
>> >>>>
>> >>>> From the:
>> >>>> "mapping kernel into physical memory
>> >>>> about to get started..."
>> >>>>
>> >>>> I would almost say it's trying to reload dom0 ?
>> >>>>
>> >>>>
>> >>>> [  897.161119] device vif1.0 entered promiscuous mode
>> >>>> mapping kernel into physical memory
>> >>>> about to get started...
>> >>>> [  897.696619] xen_bridge: port 1(vif1.0) entered forwarding state
>> >>>> [  897.716219] xen_bridge: port 1(vif1.0) entered forwarding state
>> >>>> [  898.129465] ------------[ cut here ]------------
>> >>>> [  898.132209] kernel BUG at drivers/xen/balloon.c:359!
>> >>>> [  898.132209] invalid opcode: 0000 [#1] PREEMPT SMP
>> >>
>> >>
>> >>
>> >> _______________________________________________
>> >> Xen-devel mailing list
>> >> Xen-devel@lists.xen.org
>> >> http://lists.xen.org/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 Sep 05 14:42:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Sep 2012 14:42: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 1T9Gnc-00021z-6C; Wed, 05 Sep 2012 14:41:48 +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 1T9Gnb-00021q-0d
	for xen-devel@lists.xensource.com; Wed, 05 Sep 2012 14:41:47 +0000
Received: from [85.158.143.99:26498] by server-1.bemta-4.messagelabs.com id
	53/5D-12504-AA467405; Wed, 05 Sep 2012 14:41:46 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1346856104!22308946!1
X-Originating-IP: [65.55.88.11]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14978 invoked from network); 5 Sep 2012 14:41:45 -0000
Received: from tx2ehsobe001.messaging.microsoft.com (HELO
	tx2outboundpool.messaging.microsoft.com) (65.55.88.11)
	by server-10.tower-216.messagelabs.com with AES128-SHA encrypted SMTP;
	5 Sep 2012 14:41:45 -0000
Received: from mail206-tx2-R.bigfish.com (10.9.14.253) by
	TX2EHSOBE004.bigfish.com (10.9.40.24) with Microsoft SMTP Server id
	14.1.225.23; Wed, 5 Sep 2012 14:41:43 +0000
Received: from mail206-tx2 (localhost [127.0.0.1])	by
	mail206-tx2-R.bigfish.com (Postfix) with ESMTP id 9F7A7D0012A;
	Wed,  5 Sep 2012 14:41:43 +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(zzc85dh4015Izz1202hzz8275bhz2dh668h839hd25he5bhf0ah107ah34h1155h)
Received: from mail206-tx2 (localhost.localdomain [127.0.0.1]) by mail206-tx2
	(MessageSwitch) id 1346856100979229_13074;
	Wed,  5 Sep 2012 14:41:40 +0000 (UTC)
Received: from TX2EHSMHS043.bigfish.com (unknown [10.9.14.251])	by
	mail206-tx2.bigfish.com (Postfix) with ESMTP id E1F6F30004C;
	Wed,  5 Sep 2012 14:41:40 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	TX2EHSMHS043.bigfish.com (10.9.99.143) with Microsoft SMTP Server id
	14.1.225.23; Wed, 5 Sep 2012 14:41:38 +0000
X-WSS-ID: 0M9VSTC-01-0RE-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 28F1D10280FF;	Wed,  5 Sep 2012 09:41:36 -0500 (CDT)
Received: from SAUSEXDAG01.amd.com (163.181.55.1) by sausexedgep01.amd.com
	(163.181.36.54) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Wed, 5 Sep 2012 09:41:49 -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;
	Wed, 5 Sep 2012 09:41:35 -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, 5 Sep 2012
	10:41:34 -0400
Received: from [165.204.15.57] (gran.osrc.amd.com [165.204.15.57])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id E321D49C0D5; Wed,  5 Sep 2012
	15:41:33 +0100 (BST)
Message-ID: <504764E2.4000809@amd.com>
Date: Wed, 5 Sep 2012 16:42:42 +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>, "xen-devel@lists.xensource.com"
	<xen-devel@lists.xensource.com>, Sander Eikelenboom <linux@eikelenboom.it>
Content-Type: multipart/mixed; boundary="------------080609010503000509030908"
X-OriginatorOrg: amd.com
Subject: [Xen-devel] [PATCH] amd iommu: Dump flags of IO page faults
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--------------080609010503000509030908
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit

Hi Jan,
Attached patch dumps io page fault flags. The flags show the reason of 
the fault and tell us if this is an unmapped interrupt fault or a DMA fault.

Thanks,
Wei

signed-off-by: Wei Wang <wei.wang2@amd.com>


--------------080609010503000509030908
Content-Type: text/x-patch; name="iommu_flags.patch"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="iommu_flags.patch"
Content-Description: iommu_flags.patch

diff -r 4746414def65 xen/drivers/passthrough/amd/iommu_init.c
--- a/xen/drivers/passthrough/amd/iommu_init.c	Mon Sep 03 09:40:38 2012 +0200
+++ b/xen/drivers/passthrough/amd/iommu_init.c	Wed Sep 05 16:35:23 2012 +0200
@@ -564,7 +564,7 @@ static hw_irq_controller iommu_msi_type 
 
 static void parse_event_log_entry(struct amd_iommu *iommu, u32 entry[])
 {
-    u16 domain_id, device_id, bdf, cword;
+    u16 domain_id, device_id, bdf, cword, flags;
     u32 code;
     u64 *addr;
     int count = 0;
@@ -609,11 +609,14 @@ static void parse_event_log_entry(struct
         domain_id = get_field_from_reg_u32(entry[1],
                                            IOMMU_EVENT_DOMAIN_ID_MASK,
                                            IOMMU_EVENT_DOMAIN_ID_SHIFT);
+        flags = get_field_from_reg_u32(entry[1],
+                                       IOMMU_EVENT_FLAGS_MASK,
+                                       IOMMU_EVENT_FLAGS_SHIFT);
         addr= (u64*) (entry + 2);
         printk(XENLOG_ERR "AMD-Vi: "
                "%s: domain = %d, device id = 0x%04x, "
-               "fault address = 0x%"PRIx64"\n",
-               event_str[code-1], domain_id, device_id, *addr);
+               "fault address = 0x%"PRIx64", flags = 0x%03x\n",
+               event_str[code-1], domain_id, device_id, *addr, flags);
 
         /* Tell the device to stop DMAing; we can't rely on the guest to
          * control it for us. */
diff -r 4746414def65 xen/include/asm-x86/hvm/svm/amd-iommu-defs.h
--- a/xen/include/asm-x86/hvm/svm/amd-iommu-defs.h	Mon Sep 03 09:40:38 2012 +0200
+++ b/xen/include/asm-x86/hvm/svm/amd-iommu-defs.h	Wed Sep 05 16:35:23 2012 +0200
@@ -283,6 +283,8 @@
 #define IOMMU_EVENT_DOMAIN_ID_SHIFT          0
 #define IOMMU_EVENT_DEVICE_ID_MASK           0x0000FFFF
 #define IOMMU_EVENT_DEVICE_ID_SHIFT          0
+#define IOMMU_EVENT_FLAGS_SHIFT              16
+#define IOMMU_EVENT_FLAGS_MASK               0x0FFF0000
 
 /* PPR Log */
 #define IOMMU_PPR_LOG_ENTRY_SIZE                        16

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

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

--------------080609010503000509030908--


From xen-devel-bounces@lists.xen.org Wed Sep 05 14:42:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Sep 2012 14:42: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 1T9Gnc-00021z-6C; Wed, 05 Sep 2012 14:41:48 +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 1T9Gnb-00021q-0d
	for xen-devel@lists.xensource.com; Wed, 05 Sep 2012 14:41:47 +0000
Received: from [85.158.143.99:26498] by server-1.bemta-4.messagelabs.com id
	53/5D-12504-AA467405; Wed, 05 Sep 2012 14:41:46 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1346856104!22308946!1
X-Originating-IP: [65.55.88.11]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14978 invoked from network); 5 Sep 2012 14:41:45 -0000
Received: from tx2ehsobe001.messaging.microsoft.com (HELO
	tx2outboundpool.messaging.microsoft.com) (65.55.88.11)
	by server-10.tower-216.messagelabs.com with AES128-SHA encrypted SMTP;
	5 Sep 2012 14:41:45 -0000
Received: from mail206-tx2-R.bigfish.com (10.9.14.253) by
	TX2EHSOBE004.bigfish.com (10.9.40.24) with Microsoft SMTP Server id
	14.1.225.23; Wed, 5 Sep 2012 14:41:43 +0000
Received: from mail206-tx2 (localhost [127.0.0.1])	by
	mail206-tx2-R.bigfish.com (Postfix) with ESMTP id 9F7A7D0012A;
	Wed,  5 Sep 2012 14:41:43 +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(zzc85dh4015Izz1202hzz8275bhz2dh668h839hd25he5bhf0ah107ah34h1155h)
Received: from mail206-tx2 (localhost.localdomain [127.0.0.1]) by mail206-tx2
	(MessageSwitch) id 1346856100979229_13074;
	Wed,  5 Sep 2012 14:41:40 +0000 (UTC)
Received: from TX2EHSMHS043.bigfish.com (unknown [10.9.14.251])	by
	mail206-tx2.bigfish.com (Postfix) with ESMTP id E1F6F30004C;
	Wed,  5 Sep 2012 14:41:40 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	TX2EHSMHS043.bigfish.com (10.9.99.143) with Microsoft SMTP Server id
	14.1.225.23; Wed, 5 Sep 2012 14:41:38 +0000
X-WSS-ID: 0M9VSTC-01-0RE-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 28F1D10280FF;	Wed,  5 Sep 2012 09:41:36 -0500 (CDT)
Received: from SAUSEXDAG01.amd.com (163.181.55.1) by sausexedgep01.amd.com
	(163.181.36.54) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Wed, 5 Sep 2012 09:41:49 -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;
	Wed, 5 Sep 2012 09:41:35 -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, 5 Sep 2012
	10:41:34 -0400
Received: from [165.204.15.57] (gran.osrc.amd.com [165.204.15.57])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id E321D49C0D5; Wed,  5 Sep 2012
	15:41:33 +0100 (BST)
Message-ID: <504764E2.4000809@amd.com>
Date: Wed, 5 Sep 2012 16:42:42 +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>, "xen-devel@lists.xensource.com"
	<xen-devel@lists.xensource.com>, Sander Eikelenboom <linux@eikelenboom.it>
Content-Type: multipart/mixed; boundary="------------080609010503000509030908"
X-OriginatorOrg: amd.com
Subject: [Xen-devel] [PATCH] amd iommu: Dump flags of IO page faults
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--------------080609010503000509030908
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit

Hi Jan,
Attached patch dumps io page fault flags. The flags show the reason of 
the fault and tell us if this is an unmapped interrupt fault or a DMA fault.

Thanks,
Wei

signed-off-by: Wei Wang <wei.wang2@amd.com>


--------------080609010503000509030908
Content-Type: text/x-patch; name="iommu_flags.patch"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="iommu_flags.patch"
Content-Description: iommu_flags.patch

diff -r 4746414def65 xen/drivers/passthrough/amd/iommu_init.c
--- a/xen/drivers/passthrough/amd/iommu_init.c	Mon Sep 03 09:40:38 2012 +0200
+++ b/xen/drivers/passthrough/amd/iommu_init.c	Wed Sep 05 16:35:23 2012 +0200
@@ -564,7 +564,7 @@ static hw_irq_controller iommu_msi_type 
 
 static void parse_event_log_entry(struct amd_iommu *iommu, u32 entry[])
 {
-    u16 domain_id, device_id, bdf, cword;
+    u16 domain_id, device_id, bdf, cword, flags;
     u32 code;
     u64 *addr;
     int count = 0;
@@ -609,11 +609,14 @@ static void parse_event_log_entry(struct
         domain_id = get_field_from_reg_u32(entry[1],
                                            IOMMU_EVENT_DOMAIN_ID_MASK,
                                            IOMMU_EVENT_DOMAIN_ID_SHIFT);
+        flags = get_field_from_reg_u32(entry[1],
+                                       IOMMU_EVENT_FLAGS_MASK,
+                                       IOMMU_EVENT_FLAGS_SHIFT);
         addr= (u64*) (entry + 2);
         printk(XENLOG_ERR "AMD-Vi: "
                "%s: domain = %d, device id = 0x%04x, "
-               "fault address = 0x%"PRIx64"\n",
-               event_str[code-1], domain_id, device_id, *addr);
+               "fault address = 0x%"PRIx64", flags = 0x%03x\n",
+               event_str[code-1], domain_id, device_id, *addr, flags);
 
         /* Tell the device to stop DMAing; we can't rely on the guest to
          * control it for us. */
diff -r 4746414def65 xen/include/asm-x86/hvm/svm/amd-iommu-defs.h
--- a/xen/include/asm-x86/hvm/svm/amd-iommu-defs.h	Mon Sep 03 09:40:38 2012 +0200
+++ b/xen/include/asm-x86/hvm/svm/amd-iommu-defs.h	Wed Sep 05 16:35:23 2012 +0200
@@ -283,6 +283,8 @@
 #define IOMMU_EVENT_DOMAIN_ID_SHIFT          0
 #define IOMMU_EVENT_DEVICE_ID_MASK           0x0000FFFF
 #define IOMMU_EVENT_DEVICE_ID_SHIFT          0
+#define IOMMU_EVENT_FLAGS_SHIFT              16
+#define IOMMU_EVENT_FLAGS_MASK               0x0FFF0000
 
 /* PPR Log */
 #define IOMMU_PPR_LOG_ENTRY_SIZE                        16

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

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

--------------080609010503000509030908--


From xen-devel-bounces@lists.xen.org Wed Sep 05 14:44:32 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Sep 2012 14:44: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 1T9Gpf-0002Bx-NT; Wed, 05 Sep 2012 14:43:55 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1T9Gpe-0002Bn-KT
	for xen-devel@lists.xensource.com; Wed, 05 Sep 2012 14:43:54 +0000
Received: from [85.158.138.51:20807] by server-11.bemta-3.messagelabs.com id
	60/3D-30250-92567405; Wed, 05 Sep 2012 14:43:53 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1346856231!24774393!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDczODkxOA==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24404 invoked from network); 5 Sep 2012 14:43:53 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-10.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 5 Sep 2012 14:43:53 -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 q85EhnYC010947
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 5 Sep 2012 14:43:50 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q85EhnNg020597
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 5 Sep 2012 14:43:49 GMT
Received: from abhmt104.oracle.com (abhmt104.oracle.com [141.146.116.56])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q85Ehm6e005227; Wed, 5 Sep 2012 09:43:48 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 05 Sep 2012 07:43:48 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id F0573402C1; Wed,  5 Sep 2012 10:33:18 -0400 (EDT)
Date: Wed, 5 Sep 2012 10:33:18 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Stefano Panella <stefano.panella@citrix.com>
Message-ID: <20120905143318.GA6908@phenom.dumpdata.com>
References: <1346407072-6405-1-git-send-email-stefano.panella@citrix.com>
	<5040B249.4000306@citrix.com>
	<20120831164010.GA18929@localhost.localdomain>
	<50460B2E.3020200@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <50460B2E.3020200@citrix.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	David Vrabel <david.vrabel@citrix.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [Xen-devel] [PATCH 1/1] XEN: Use correct masking in
 xen_swiotlb_alloc_coherent.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Sep 04, 2012 at 03:07:42PM +0100, Stefano Panella wrote:
> On 08/31/2012 05:40 PM, Konrad Rzeszutek Wilk wrote:
> >On Fri, Aug 31, 2012 at 01:47:05PM +0100, David Vrabel wrote:
> >>On 31/08/12 10:57, Stefano Panella wrote:
> >>>When running 32-bit pvops-dom0 and a driver tries to allocate a coherent
> >>>DMA-memory the xen swiotlb-implementation returned memory beyond 4GB.
> >>>
> >>>This caused for example not working sound on a system with 4 GB and a 64-bit
> >>>compatible sound-card with sets the DMA-mask to 64bit.
> >>>
> >>>On bare-metal and the forward-ported xen-dom0 patches from OpenSuse a coherent
> >>>DMA-memory is always allocated inside the 32-bit address-range by calling
> >>>dma_alloc_coherent_mask.
> >>We should have the same behaviour under Xen as bare metal so:
> >>
> >>Acked-By: David Vrabel <david.vrabel@citrix.com>
> >>
> >>This does limit the DMA mask to 32-bits by passing it through an
> >>unsigned long, which seems a bit sneaky...
> >so is the issue that we are not casting it from 'u64' to 'u32'
> >(unsigned long) on 32-bit?
> 
> Yes. I do not completely understand why but I think on 32-bit kernel we need to cast dma_mask to u32. This is done automatically using dma_alloc_coherent_mask()

OK, patch applied. I altered the git commit description a bit and
changed the author to  Ronny Hegewald <ronny.hegewald@online.de>.

Also added it on stable@vger.kernel.org

Thanks for tracking this down.

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

From xen-devel-bounces@lists.xen.org Wed Sep 05 14:44:32 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Sep 2012 14:44: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 1T9Gpf-0002Bx-NT; Wed, 05 Sep 2012 14:43:55 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1T9Gpe-0002Bn-KT
	for xen-devel@lists.xensource.com; Wed, 05 Sep 2012 14:43:54 +0000
Received: from [85.158.138.51:20807] by server-11.bemta-3.messagelabs.com id
	60/3D-30250-92567405; Wed, 05 Sep 2012 14:43:53 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1346856231!24774393!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDczODkxOA==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24404 invoked from network); 5 Sep 2012 14:43:53 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-10.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 5 Sep 2012 14:43:53 -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 q85EhnYC010947
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 5 Sep 2012 14:43:50 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q85EhnNg020597
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 5 Sep 2012 14:43:49 GMT
Received: from abhmt104.oracle.com (abhmt104.oracle.com [141.146.116.56])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q85Ehm6e005227; Wed, 5 Sep 2012 09:43:48 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 05 Sep 2012 07:43:48 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id F0573402C1; Wed,  5 Sep 2012 10:33:18 -0400 (EDT)
Date: Wed, 5 Sep 2012 10:33:18 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Stefano Panella <stefano.panella@citrix.com>
Message-ID: <20120905143318.GA6908@phenom.dumpdata.com>
References: <1346407072-6405-1-git-send-email-stefano.panella@citrix.com>
	<5040B249.4000306@citrix.com>
	<20120831164010.GA18929@localhost.localdomain>
	<50460B2E.3020200@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <50460B2E.3020200@citrix.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	David Vrabel <david.vrabel@citrix.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [Xen-devel] [PATCH 1/1] XEN: Use correct masking in
 xen_swiotlb_alloc_coherent.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Sep 04, 2012 at 03:07:42PM +0100, Stefano Panella wrote:
> On 08/31/2012 05:40 PM, Konrad Rzeszutek Wilk wrote:
> >On Fri, Aug 31, 2012 at 01:47:05PM +0100, David Vrabel wrote:
> >>On 31/08/12 10:57, Stefano Panella wrote:
> >>>When running 32-bit pvops-dom0 and a driver tries to allocate a coherent
> >>>DMA-memory the xen swiotlb-implementation returned memory beyond 4GB.
> >>>
> >>>This caused for example not working sound on a system with 4 GB and a 64-bit
> >>>compatible sound-card with sets the DMA-mask to 64bit.
> >>>
> >>>On bare-metal and the forward-ported xen-dom0 patches from OpenSuse a coherent
> >>>DMA-memory is always allocated inside the 32-bit address-range by calling
> >>>dma_alloc_coherent_mask.
> >>We should have the same behaviour under Xen as bare metal so:
> >>
> >>Acked-By: David Vrabel <david.vrabel@citrix.com>
> >>
> >>This does limit the DMA mask to 32-bits by passing it through an
> >>unsigned long, which seems a bit sneaky...
> >so is the issue that we are not casting it from 'u64' to 'u32'
> >(unsigned long) on 32-bit?
> 
> Yes. I do not completely understand why but I think on 32-bit kernel we need to cast dma_mask to u32. This is done automatically using dma_alloc_coherent_mask()

OK, patch applied. I altered the git commit description a bit and
changed the author to  Ronny Hegewald <ronny.hegewald@online.de>.

Also added it on stable@vger.kernel.org

Thanks for tracking this down.

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

From xen-devel-bounces@lists.xen.org Wed Sep 05 14:46:35 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Sep 2012 14:46:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9Grp-0002KF-An; Wed, 05 Sep 2012 14:46:09 +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 1T9Grn-0002Jm-Ik
	for xen-devel@lists.xen.org; Wed, 05 Sep 2012 14:46:07 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1346856361!4110028!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTE5ODY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14519 invoked from network); 5 Sep 2012 14:46:01 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Sep 2012 14:46:01 -0000
X-IronPort-AV: E=Sophos;i="4.80,374,1344211200"; d="scan'208";a="14361812"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Sep 2012 14:46: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.279.1; Wed, 5 Sep 2012 15:46: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
	1T9Grg-0004DZ-E0; Wed, 05 Sep 2012 14:46:00 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1T9Grg-000421-AG;
	Wed, 05 Sep 2012 15:46:00 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20551.26024.217179.594711@mariner.uk.xensource.com>
Date: Wed, 5 Sep 2012 15:46:00 +0100
To: Ian Campbell <ian.campbell@citrix.com>
In-Reply-To: <99b7a5af9b3059bac273.1346676538@cosworth.uk.xensource.com>
References: <99b7a5af9b3059bac273.1346676538@cosworth.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Andres Lagar-Cavilla <andreslc@gridcentric.ca>,
	"Tim \(Xen.org\)" <tim@xen.org>,
	Stefano Panella <stefano.panella@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] libxl: handle errors from xc_sharing_* info
	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 ("[PATCH] libxl: handle errors from xc_sharing_* info functions"):
> I don't have a 32 bit system handy, so tested on x86_64 with a libxc
> hacked to return -ENOSYS and -EINVAL.
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

> -    physinfo->sharing_freed_pages = xc_sharing_freed_pages(ctx->xch);
> -    physinfo->sharing_used_frames = xc_sharing_used_frames(ctx->xch);
> +    l = xc_sharing_freed_pages(ctx->xch);
> +    if ( l < 0 && l != -ENOSYS ) {
> +        LIBXL__LOG_ERRNOVAL(ctx, LIBXL__LOG_ERROR, l,
> +                            "getting sharing freed pages");
> +        return ERROR_FAIL;
> +    }
> +    physinfo->sharing_freed_pages = (l == -ENOSYS) ? 0 : l;

Although you do like doing this the convoluted way.  What would have
been wrong with
   if (l == -ENOSYS) {
       l = 0;
   } else if (l < 0) {
       LOG...
       return ERROR_FAIL;
   }
? :-)

Ian.

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

From xen-devel-bounces@lists.xen.org Wed Sep 05 14:46:35 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Sep 2012 14:46:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9Grp-0002KF-An; Wed, 05 Sep 2012 14:46:09 +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 1T9Grn-0002Jm-Ik
	for xen-devel@lists.xen.org; Wed, 05 Sep 2012 14:46:07 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1346856361!4110028!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTE5ODY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14519 invoked from network); 5 Sep 2012 14:46:01 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Sep 2012 14:46:01 -0000
X-IronPort-AV: E=Sophos;i="4.80,374,1344211200"; d="scan'208";a="14361812"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Sep 2012 14:46: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.279.1; Wed, 5 Sep 2012 15:46: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
	1T9Grg-0004DZ-E0; Wed, 05 Sep 2012 14:46:00 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1T9Grg-000421-AG;
	Wed, 05 Sep 2012 15:46:00 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20551.26024.217179.594711@mariner.uk.xensource.com>
Date: Wed, 5 Sep 2012 15:46:00 +0100
To: Ian Campbell <ian.campbell@citrix.com>
In-Reply-To: <99b7a5af9b3059bac273.1346676538@cosworth.uk.xensource.com>
References: <99b7a5af9b3059bac273.1346676538@cosworth.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Andres Lagar-Cavilla <andreslc@gridcentric.ca>,
	"Tim \(Xen.org\)" <tim@xen.org>,
	Stefano Panella <stefano.panella@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] libxl: handle errors from xc_sharing_* info
	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 ("[PATCH] libxl: handle errors from xc_sharing_* info functions"):
> I don't have a 32 bit system handy, so tested on x86_64 with a libxc
> hacked to return -ENOSYS and -EINVAL.
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

> -    physinfo->sharing_freed_pages = xc_sharing_freed_pages(ctx->xch);
> -    physinfo->sharing_used_frames = xc_sharing_used_frames(ctx->xch);
> +    l = xc_sharing_freed_pages(ctx->xch);
> +    if ( l < 0 && l != -ENOSYS ) {
> +        LIBXL__LOG_ERRNOVAL(ctx, LIBXL__LOG_ERROR, l,
> +                            "getting sharing freed pages");
> +        return ERROR_FAIL;
> +    }
> +    physinfo->sharing_freed_pages = (l == -ENOSYS) ? 0 : l;

Although you do like doing this the convoluted way.  What would have
been wrong with
   if (l == -ENOSYS) {
       l = 0;
   } else if (l < 0) {
       LOG...
       return ERROR_FAIL;
   }
? :-)

Ian.

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

From xen-devel-bounces@lists.xen.org Wed Sep 05 14:53:11 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Sep 2012 14:53: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 1T9Gy4-0002ZN-5G; Wed, 05 Sep 2012 14:52: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 1T9Gy2-0002ZH-FL
	for xen-devel@lists.xen.org; Wed, 05 Sep 2012 14:52:34 +0000
Received: from [85.158.143.99:26330] by server-2.bemta-4.messagelabs.com id
	C6/4F-21239-13767405; Wed, 05 Sep 2012 14:52:33 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1346856752!17498893!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTE5ODY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14827 invoked from network); 5 Sep 2012 14:52:33 -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 Sep 2012 14:52:33 -0000
X-IronPort-AV: E=Sophos;i="4.80,374,1344211200"; d="scan'208";a="14361951"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Sep 2012 14:52: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.279.1; Wed, 5 Sep 2012
	15:52:32 +0100
Message-ID: <1346856750.17325.110.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Wed, 5 Sep 2012 15:52:30 +0100
In-Reply-To: <20551.26024.217179.594711@mariner.uk.xensource.com>
References: <99b7a5af9b3059bac273.1346676538@cosworth.uk.xensource.com>
	<20551.26024.217179.594711@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Andres Lagar-Cavilla <andreslc@gridcentric.ca>,
	"Tim \(Xen.org\)" <tim@xen.org>, Stefano
	Panella <stefano.panella@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] libxl: handle errors from xc_sharing_* info
	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, 2012-09-05 at 15:46 +0100, Ian Jackson wrote:
> Ian Campbell writes ("[PATCH] libxl: handle errors from xc_sharing_* info functions"):
> > I don't have a 32 bit system handy, so tested on x86_64 with a libxc
> > hacked to return -ENOSYS and -EINVAL.
> > 
> > Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> 
> Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
> 
> > -    physinfo->sharing_freed_pages = xc_sharing_freed_pages(ctx->xch);
> > -    physinfo->sharing_used_frames = xc_sharing_used_frames(ctx->xch);
> > +    l = xc_sharing_freed_pages(ctx->xch);
> > +    if ( l < 0 && l != -ENOSYS ) {
> > +        LIBXL__LOG_ERRNOVAL(ctx, LIBXL__LOG_ERROR, l,
> > +                            "getting sharing freed pages");
> > +        return ERROR_FAIL;
> > +    }
> > +    physinfo->sharing_freed_pages = (l == -ENOSYS) ? 0 : l;
> 
> Although you do like doing this the convoluted way.  What would have
> been wrong with
>    if (l == -ENOSYS) {
>        l = 0;
>    } else if (l < 0) {
>        LOG...
>        return ERROR_FAIL;
>    }
> ? :-)

Nothing, just in a particular frame of mind I guess.

I'll respin with this approach, it's less mad.



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

From xen-devel-bounces@lists.xen.org Wed Sep 05 14:53:11 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Sep 2012 14:53: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 1T9Gy4-0002ZN-5G; Wed, 05 Sep 2012 14:52: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 1T9Gy2-0002ZH-FL
	for xen-devel@lists.xen.org; Wed, 05 Sep 2012 14:52:34 +0000
Received: from [85.158.143.99:26330] by server-2.bemta-4.messagelabs.com id
	C6/4F-21239-13767405; Wed, 05 Sep 2012 14:52:33 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1346856752!17498893!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTE5ODY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14827 invoked from network); 5 Sep 2012 14:52:33 -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 Sep 2012 14:52:33 -0000
X-IronPort-AV: E=Sophos;i="4.80,374,1344211200"; d="scan'208";a="14361951"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Sep 2012 14:52: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.279.1; Wed, 5 Sep 2012
	15:52:32 +0100
Message-ID: <1346856750.17325.110.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Wed, 5 Sep 2012 15:52:30 +0100
In-Reply-To: <20551.26024.217179.594711@mariner.uk.xensource.com>
References: <99b7a5af9b3059bac273.1346676538@cosworth.uk.xensource.com>
	<20551.26024.217179.594711@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Andres Lagar-Cavilla <andreslc@gridcentric.ca>,
	"Tim \(Xen.org\)" <tim@xen.org>, Stefano
	Panella <stefano.panella@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] libxl: handle errors from xc_sharing_* info
	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, 2012-09-05 at 15:46 +0100, Ian Jackson wrote:
> Ian Campbell writes ("[PATCH] libxl: handle errors from xc_sharing_* info functions"):
> > I don't have a 32 bit system handy, so tested on x86_64 with a libxc
> > hacked to return -ENOSYS and -EINVAL.
> > 
> > Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> 
> Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
> 
> > -    physinfo->sharing_freed_pages = xc_sharing_freed_pages(ctx->xch);
> > -    physinfo->sharing_used_frames = xc_sharing_used_frames(ctx->xch);
> > +    l = xc_sharing_freed_pages(ctx->xch);
> > +    if ( l < 0 && l != -ENOSYS ) {
> > +        LIBXL__LOG_ERRNOVAL(ctx, LIBXL__LOG_ERROR, l,
> > +                            "getting sharing freed pages");
> > +        return ERROR_FAIL;
> > +    }
> > +    physinfo->sharing_freed_pages = (l == -ENOSYS) ? 0 : l;
> 
> Although you do like doing this the convoluted way.  What would have
> been wrong with
>    if (l == -ENOSYS) {
>        l = 0;
>    } else if (l < 0) {
>        LOG...
>        return ERROR_FAIL;
>    }
> ? :-)

Nothing, just in a particular frame of mind I guess.

I'll respin with this approach, it's less mad.



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

From xen-devel-bounces@lists.xen.org Wed Sep 05 15:05:10 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Sep 2012 15:05:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9H9e-0002qO-8H; Wed, 05 Sep 2012 15:04:34 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1T9H9d-0002qI-CO
	for xen-devel@lists.xen.org; Wed, 05 Sep 2012 15:04:33 +0000
Received: from [85.158.138.51:62518] by server-10.bemta-3.messagelabs.com id
	96/BC-10411-00A67405; Wed, 05 Sep 2012 15:04:32 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1346857471!28875897!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQwMzE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18055 invoked from network); 5 Sep 2012 15:04:31 -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;
	5 Sep 2012 15:04:31 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 05 Sep 2012 16:05:00 +0100
Message-Id: <504786530200007800098F6E@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 05 Sep 2012 16:05:23 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Wei Wang" <wei.wang2@amd.com>
References: <40501859.20120902104331@eikelenboom.it>
	<CC6932C2.3D99D%keir.xen@gmail.com>
	<217459398.20120902171441@eikelenboom.it> <5044CAD7.8030800@amd.com>
	<1144695277.20120904184345@eikelenboom.it>
	<5047420A0200007800098BB1@nat28.tlf.novell.com>
	<348297741.20120905122542@eikelenboom.it>
	<5047483F0200007800098C18@nat28.tlf.novell.com>
	<50475E8D.2090709@amd.com>
In-Reply-To: <50475E8D.2090709@amd.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Sander Eikelenboom <linux@eikelenboom.it>, Keir Fraser <keir.xen@gmail.com>,
	Santosh Jodh <Santosh.Jodh@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Using debug-key 'o:  Dump IOMMU p2m table,
 locks up machine
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.09.12 at 16:15, Wei Wang <wei.wang2@amd.com> wrote:
> I checked this on my machine using 'o' key and it has been mapped as a 
> 2MB frame see: gfn: 000c2c00  mfn: 000c2c00. But maybe I have no device 

Obviously he won't have gfn c2c00 and alike since he's using
dom0_mem=1G - you should probably try that too. But even then
I wouldn't expect you to see anything, as you also need a
babbling device.

> access to this address... Another possibility is interrupt message. 4.1 
> does not show IO_PAGE_FAULT for interrupts, but 4.2 does (changeset 
> 23199:dbd98ab2f87f). I will send a patch to dump flags from IO_PAGE_FAULT.

Yes, that might help a little further.

Jan


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

From xen-devel-bounces@lists.xen.org Wed Sep 05 15:05:10 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Sep 2012 15:05:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9H9e-0002qO-8H; Wed, 05 Sep 2012 15:04:34 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1T9H9d-0002qI-CO
	for xen-devel@lists.xen.org; Wed, 05 Sep 2012 15:04:33 +0000
Received: from [85.158.138.51:62518] by server-10.bemta-3.messagelabs.com id
	96/BC-10411-00A67405; Wed, 05 Sep 2012 15:04:32 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1346857471!28875897!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQwMzE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18055 invoked from network); 5 Sep 2012 15:04:31 -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;
	5 Sep 2012 15:04:31 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 05 Sep 2012 16:05:00 +0100
Message-Id: <504786530200007800098F6E@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 05 Sep 2012 16:05:23 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Wei Wang" <wei.wang2@amd.com>
References: <40501859.20120902104331@eikelenboom.it>
	<CC6932C2.3D99D%keir.xen@gmail.com>
	<217459398.20120902171441@eikelenboom.it> <5044CAD7.8030800@amd.com>
	<1144695277.20120904184345@eikelenboom.it>
	<5047420A0200007800098BB1@nat28.tlf.novell.com>
	<348297741.20120905122542@eikelenboom.it>
	<5047483F0200007800098C18@nat28.tlf.novell.com>
	<50475E8D.2090709@amd.com>
In-Reply-To: <50475E8D.2090709@amd.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Sander Eikelenboom <linux@eikelenboom.it>, Keir Fraser <keir.xen@gmail.com>,
	Santosh Jodh <Santosh.Jodh@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Using debug-key 'o:  Dump IOMMU p2m table,
 locks up machine
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.09.12 at 16:15, Wei Wang <wei.wang2@amd.com> wrote:
> I checked this on my machine using 'o' key and it has been mapped as a 
> 2MB frame see: gfn: 000c2c00  mfn: 000c2c00. But maybe I have no device 

Obviously he won't have gfn c2c00 and alike since he's using
dom0_mem=1G - you should probably try that too. But even then
I wouldn't expect you to see anything, as you also need a
babbling device.

> access to this address... Another possibility is interrupt message. 4.1 
> does not show IO_PAGE_FAULT for interrupts, but 4.2 does (changeset 
> 23199:dbd98ab2f87f). I will send a patch to dump flags from IO_PAGE_FAULT.

Yes, that might help a little further.

Jan


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

From xen-devel-bounces@lists.xen.org Wed Sep 05 15:06:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Sep 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 1T9HAa-0002w1-Mt; Wed, 05 Sep 2012 15:05:32 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <karthick.k11@gmail.com>) id 1T9HAY-0002vG-IL
	for xen-devel@lists.xen.org; Wed, 05 Sep 2012 15:05:30 +0000
X-Env-Sender: karthick.k11@gmail.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1346857523!8628576!1
X-Originating-IP: [74.125.82.51]
X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16219 invoked from network); 5 Sep 2012 15:05:24 -0000
Received: from mail-wg0-f51.google.com (HELO mail-wg0-f51.google.com)
	(74.125.82.51)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Sep 2012 15:05:24 -0000
Received: by wgbed3 with SMTP id ed3so491455wgb.32
	for <xen-devel@lists.xen.org>; Wed, 05 Sep 2012 08:05: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=Kjs8VIHuLFRjxISx06Ii9hWkXKTh9wDHxVxWz74F1E8=;
	b=bfg+lpmpiAl22BlNehRr0aNYXlBmsiiFX5zkCmUE+0oFS2jQr4IB6aOU0sSwFeW5sk
	MZDRNFEKdDqZf1AcVJJnPWKzS+/S5h+GZMoJyTiSr846pzyuS9E5gjnFwODkgrw4PD+0
	85UMrmKmDCkzUVDYptzADU3GLEZRY/zIClbtUj8IpDrT7O4EvXCTDyr7ctDyN9x1udpO
	ZwEpUXsfrhAyv+UfuHVpO9JJDtYcVXhobdcdgLgpJIm535H0XgZJaoYnXwtVKzN34p6J
	d3igA9XkIW0U8yHPdbob74IO1CXaFDW88LLvIVSI8x2zV7S8Tx68Qaapadd0vpFkEqh3
	Z3ZQ==
Received: by 10.180.99.196 with SMTP id es4mr38799566wib.18.1346857523720;
	Wed, 05 Sep 2012 08:05:23 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.180.107.7 with HTTP; Wed, 5 Sep 2012 08:05:02 -0700 (PDT)
From: Karthick K <karthick.k11@gmail.com>
Date: Wed, 5 Sep 2012 20:35:02 +0530
Message-ID: <CA+w2MSc5vW-0N2pxG5JE+i8YLg2-=e3T0F0QDS7Ab8e7c7w2ew@mail.gmail.com>
To: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Xen Security Advisory 12 (CVE-2012-3494) -
 hypercall set_debugreg vulnerability (Andrew Cooper)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1936657652435422726=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============1936657652435422726==
Content-Type: multipart/alternative; boundary=f46d0442837043b2f104c8f5b42a

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

Hi,

How I test about this vulnerability?

Can you give steps to check it? If possible please can you provide for
other vulnerabilities too?

Thanks!

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

<div>Hi,<br></div><div><br></div><div>How I test about this vulnerability?=
=A0</div><div><br></div><div>Can you give steps to check it? If possible pl=
ease can you provide for other vulnerabilities too?</div><div><br></div><di=
v>

Thanks!</div><div><br></div>

--f46d0442837043b2f104c8f5b42a--


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

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

--===============1936657652435422726==--


From xen-devel-bounces@lists.xen.org Wed Sep 05 15:06:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Sep 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 1T9HAa-0002w1-Mt; Wed, 05 Sep 2012 15:05:32 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <karthick.k11@gmail.com>) id 1T9HAY-0002vG-IL
	for xen-devel@lists.xen.org; Wed, 05 Sep 2012 15:05:30 +0000
X-Env-Sender: karthick.k11@gmail.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1346857523!8628576!1
X-Originating-IP: [74.125.82.51]
X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16219 invoked from network); 5 Sep 2012 15:05:24 -0000
Received: from mail-wg0-f51.google.com (HELO mail-wg0-f51.google.com)
	(74.125.82.51)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Sep 2012 15:05:24 -0000
Received: by wgbed3 with SMTP id ed3so491455wgb.32
	for <xen-devel@lists.xen.org>; Wed, 05 Sep 2012 08:05: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=Kjs8VIHuLFRjxISx06Ii9hWkXKTh9wDHxVxWz74F1E8=;
	b=bfg+lpmpiAl22BlNehRr0aNYXlBmsiiFX5zkCmUE+0oFS2jQr4IB6aOU0sSwFeW5sk
	MZDRNFEKdDqZf1AcVJJnPWKzS+/S5h+GZMoJyTiSr846pzyuS9E5gjnFwODkgrw4PD+0
	85UMrmKmDCkzUVDYptzADU3GLEZRY/zIClbtUj8IpDrT7O4EvXCTDyr7ctDyN9x1udpO
	ZwEpUXsfrhAyv+UfuHVpO9JJDtYcVXhobdcdgLgpJIm535H0XgZJaoYnXwtVKzN34p6J
	d3igA9XkIW0U8yHPdbob74IO1CXaFDW88LLvIVSI8x2zV7S8Tx68Qaapadd0vpFkEqh3
	Z3ZQ==
Received: by 10.180.99.196 with SMTP id es4mr38799566wib.18.1346857523720;
	Wed, 05 Sep 2012 08:05:23 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.180.107.7 with HTTP; Wed, 5 Sep 2012 08:05:02 -0700 (PDT)
From: Karthick K <karthick.k11@gmail.com>
Date: Wed, 5 Sep 2012 20:35:02 +0530
Message-ID: <CA+w2MSc5vW-0N2pxG5JE+i8YLg2-=e3T0F0QDS7Ab8e7c7w2ew@mail.gmail.com>
To: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Xen Security Advisory 12 (CVE-2012-3494) -
 hypercall set_debugreg vulnerability (Andrew Cooper)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1936657652435422726=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============1936657652435422726==
Content-Type: multipart/alternative; boundary=f46d0442837043b2f104c8f5b42a

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

Hi,

How I test about this vulnerability?

Can you give steps to check it? If possible please can you provide for
other vulnerabilities too?

Thanks!

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

<div>Hi,<br></div><div><br></div><div>How I test about this vulnerability?=
=A0</div><div><br></div><div>Can you give steps to check it? If possible pl=
ease can you provide for other vulnerabilities too?</div><div><br></div><di=
v>

Thanks!</div><div><br></div>

--f46d0442837043b2f104c8f5b42a--


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

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

--===============1936657652435422726==--


From xen-devel-bounces@lists.xen.org Wed Sep 05 15:30:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Sep 2012 15:30:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9HXr-0003g5-Sx; Wed, 05 Sep 2012 15:29:35 +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 1T9HXq-0003fx-7w; Wed, 05 Sep 2012 15:29:34 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-7.tower-27.messagelabs.com!1346858967!2038421!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA1MDI2OTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1212 invoked from network); 5 Sep 2012 15:29:28 -0000
Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25)
	by server-7.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 5 Sep 2012 15:29:28 -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 3A2941265;
	Wed,  5 Sep 2012 18:29:26 +0300 (EEST)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id 690E62005D; Wed,  5 Sep 2012 18:29:26 +0300 (EEST)
Date: Wed, 5 Sep 2012 18:29:26 +0300
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120905152926.GM8912@reaktio.net>
References: <1346665360.25864.2.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1346665360.25864.2.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: xen-users <xen-users@lists.xen.org>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.2.0 Release Plan / TODO
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Sep 03, 2012 at 10:42:40AM +0100, Ian Campbell wrote:
> 
> tools, nice to have:
> 

      * pygrub support for ext4 on rhel5/centos5.
        Roger already sent a patch for this.


-- Pasi


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

From xen-devel-bounces@lists.xen.org Wed Sep 05 15:30:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Sep 2012 15:30:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9HXr-0003g5-Sx; Wed, 05 Sep 2012 15:29:35 +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 1T9HXq-0003fx-7w; Wed, 05 Sep 2012 15:29:34 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-7.tower-27.messagelabs.com!1346858967!2038421!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA1MDI2OTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1212 invoked from network); 5 Sep 2012 15:29:28 -0000
Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25)
	by server-7.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 5 Sep 2012 15:29:28 -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 3A2941265;
	Wed,  5 Sep 2012 18:29:26 +0300 (EEST)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id 690E62005D; Wed,  5 Sep 2012 18:29:26 +0300 (EEST)
Date: Wed, 5 Sep 2012 18:29:26 +0300
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120905152926.GM8912@reaktio.net>
References: <1346665360.25864.2.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1346665360.25864.2.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: xen-users <xen-users@lists.xen.org>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.2.0 Release Plan / TODO
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Sep 03, 2012 at 10:42:40AM +0100, Ian Campbell wrote:
> 
> tools, nice to have:
> 

      * pygrub support for ext4 on rhel5/centos5.
        Roger already sent a patch for this.


-- Pasi


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

From xen-devel-bounces@lists.xen.org Wed Sep 05 16:02:54 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Sep 2012 16:02:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9I3f-0004ov-H8; Wed, 05 Sep 2012 16:02:27 +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 1T9I3d-0004oq-LG
	for Xen-devel@lists.xensource.com; Wed, 05 Sep 2012 16:02:25 +0000
Received: from [85.158.139.83:27797] by server-3.bemta-5.messagelabs.com id
	1F/2A-21836-09777405; Wed, 05 Sep 2012 16:02:24 +0000
X-Env-Sender: ben.guthro@gmail.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1346860934!28737288!1
X-Originating-IP: [209.85.212.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9515 invoked from network); 5 Sep 2012 16:02:15 -0000
Received: from mail-vb0-f43.google.com (HELO mail-vb0-f43.google.com)
	(209.85.212.43)
	by server-3.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Sep 2012 16:02:15 -0000
Received: by vbbfq11 with SMTP id fq11so345993vbb.30
	for <Xen-devel@lists.xensource.com>;
	Wed, 05 Sep 2012 09:02:14 -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=oAVzanNb7h+cHMd+QUmurTUz8vPO8nr2A1A1wQxWXv0=;
	b=h209ebsT5fI9HWjXYou3XdEFpQMAOFaIQlK+bJPwrHy7V2Tz6VRIjFqlJH0r1Inlgq
	y9Jgs886bFSWJYVlDtAxgr+VohCZA84ILNIzeSlLxLT53+PG0t/IkH/n//75Hh95sEZg
	G2gIb7Nab2YgkHIAYtMJcNRmLXHgt144LLuGlzr3Vsuzd64arujn/w4VI1LJkmTg7hYa
	Tpie9rQ+Wp11LUude7OpPVrXYnGHtAOTwTRc68MHfY77+0nvJC4QBx7+xznAcZ0OyY35
	NfeErUbpZaQpEBi93y3wXASx5e4La6qhY63YuELoC1/nR72HU1yO9OZ8z2HILuWcLF/K
	mOXg==
MIME-Version: 1.0
Received: by 10.58.211.71 with SMTP id na7mr21610516vec.39.1346860934202; Wed,
	05 Sep 2012 09:02:14 -0700 (PDT)
Received: by 10.58.28.180 with HTTP; Wed, 5 Sep 2012 09:02:13 -0700 (PDT)
In-Reply-To: <20120829144125.25a5eb3e@mantra.us.oracle.com>
References: <20120829143512.7c579fb1@mantra.us.oracle.com>
	<20120829144125.25a5eb3e@mantra.us.oracle.com>
Date: Wed, 5 Sep 2012 12:02:13 -0400
X-Google-Sender-Auth: Cz2F9IWRdigTDhs6ZeESSjM9zGM
Message-ID: <CAOvdn6UPzBncAU7Wi3PNPaMX6DRXkg8Bb92fJN8i5VdYciuEgg@mail.gmail.com>
From: Ben Guthro <ben@guthro.net>
To: Mukesh Rathor <mukesh.rathor@oracle.com>
Cc: "Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
	msw@amazon.com
Subject: Re: [Xen-devel] xen debugger (kdb/xdb/hdb) patch for c/s 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

FYI - I applied this against the tip, and turned it on (and debug off)
- but I get link errors:

ld    -melf_x86_64  -T xen.lds -N prelink.o \
	    /data/home/bguthro/dev/orc-newdev.git/orc-xen/xen-4.2/xen/common/symbols-dummy.o
-o /data/home/bguthro/dev/orc-newdev.git/orc-xen/xen-4.2/xen/.xen-syms.0
prelink.o: In function `kdb_cmdf_f':
/data/home/bguthro/dev/orc-newdev.git/orc-xen/xen-4.2/xen/kdb/kdb_cmds.c:510:
undefined reference to `show_trace'
/data/home/bguthro/dev/orc-newdev.git/orc-xen/xen-4.2/xen/kdb/kdb_cmds.c:510:(.text+0x11f6b9):
relocation truncated to fit: R_X86_64_PC32 against undefined symbol
`show_trace'
ld: /data/home/bguthro/dev/orc-newdev.git/orc-xen/xen-4.2/xen/.xen-syms.0:
hidden symbol `show_trace' isn't defined
ld: final link failed: Bad value
make[5]: *** [/data/home/bguthro/dev/orc-newdev.git/orc-xen/xen-4.2/xen/xen-syms]
Error 1
make[5]: Leaving directory
`/data/home/bguthro/dev/orc-newdev.git/orc-xen/xen-4.2/xen/arch/x86'
make[4]: *** [/data/home/bguthro/dev/orc-newdev.git/orc-xen/xen-4.2/xen/xen]
Error 2




On Wed, Aug 29, 2012 at 5:41 PM, Mukesh Rathor <mukesh.rathor@oracle.com> wrote:
> On Wed, 29 Aug 2012 14:35:12 -0700
> Mukesh Rathor <mukesh.rathor@oracle.com> wrote:
>
>
>>
>> Anyways, attaching patch that is cleaned up of my debug code that I
>> accidentally left in prev posting. Should apply cleanly to c/s 25467.
>
> really attaching this time :).
>

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

From xen-devel-bounces@lists.xen.org Wed Sep 05 16:02:54 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Sep 2012 16:02:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9I3f-0004ov-H8; Wed, 05 Sep 2012 16:02:27 +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 1T9I3d-0004oq-LG
	for Xen-devel@lists.xensource.com; Wed, 05 Sep 2012 16:02:25 +0000
Received: from [85.158.139.83:27797] by server-3.bemta-5.messagelabs.com id
	1F/2A-21836-09777405; Wed, 05 Sep 2012 16:02:24 +0000
X-Env-Sender: ben.guthro@gmail.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1346860934!28737288!1
X-Originating-IP: [209.85.212.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9515 invoked from network); 5 Sep 2012 16:02:15 -0000
Received: from mail-vb0-f43.google.com (HELO mail-vb0-f43.google.com)
	(209.85.212.43)
	by server-3.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Sep 2012 16:02:15 -0000
Received: by vbbfq11 with SMTP id fq11so345993vbb.30
	for <Xen-devel@lists.xensource.com>;
	Wed, 05 Sep 2012 09:02:14 -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=oAVzanNb7h+cHMd+QUmurTUz8vPO8nr2A1A1wQxWXv0=;
	b=h209ebsT5fI9HWjXYou3XdEFpQMAOFaIQlK+bJPwrHy7V2Tz6VRIjFqlJH0r1Inlgq
	y9Jgs886bFSWJYVlDtAxgr+VohCZA84ILNIzeSlLxLT53+PG0t/IkH/n//75Hh95sEZg
	G2gIb7Nab2YgkHIAYtMJcNRmLXHgt144LLuGlzr3Vsuzd64arujn/w4VI1LJkmTg7hYa
	Tpie9rQ+Wp11LUude7OpPVrXYnGHtAOTwTRc68MHfY77+0nvJC4QBx7+xznAcZ0OyY35
	NfeErUbpZaQpEBi93y3wXASx5e4La6qhY63YuELoC1/nR72HU1yO9OZ8z2HILuWcLF/K
	mOXg==
MIME-Version: 1.0
Received: by 10.58.211.71 with SMTP id na7mr21610516vec.39.1346860934202; Wed,
	05 Sep 2012 09:02:14 -0700 (PDT)
Received: by 10.58.28.180 with HTTP; Wed, 5 Sep 2012 09:02:13 -0700 (PDT)
In-Reply-To: <20120829144125.25a5eb3e@mantra.us.oracle.com>
References: <20120829143512.7c579fb1@mantra.us.oracle.com>
	<20120829144125.25a5eb3e@mantra.us.oracle.com>
Date: Wed, 5 Sep 2012 12:02:13 -0400
X-Google-Sender-Auth: Cz2F9IWRdigTDhs6ZeESSjM9zGM
Message-ID: <CAOvdn6UPzBncAU7Wi3PNPaMX6DRXkg8Bb92fJN8i5VdYciuEgg@mail.gmail.com>
From: Ben Guthro <ben@guthro.net>
To: Mukesh Rathor <mukesh.rathor@oracle.com>
Cc: "Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
	msw@amazon.com
Subject: Re: [Xen-devel] xen debugger (kdb/xdb/hdb) patch for c/s 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

FYI - I applied this against the tip, and turned it on (and debug off)
- but I get link errors:

ld    -melf_x86_64  -T xen.lds -N prelink.o \
	    /data/home/bguthro/dev/orc-newdev.git/orc-xen/xen-4.2/xen/common/symbols-dummy.o
-o /data/home/bguthro/dev/orc-newdev.git/orc-xen/xen-4.2/xen/.xen-syms.0
prelink.o: In function `kdb_cmdf_f':
/data/home/bguthro/dev/orc-newdev.git/orc-xen/xen-4.2/xen/kdb/kdb_cmds.c:510:
undefined reference to `show_trace'
/data/home/bguthro/dev/orc-newdev.git/orc-xen/xen-4.2/xen/kdb/kdb_cmds.c:510:(.text+0x11f6b9):
relocation truncated to fit: R_X86_64_PC32 against undefined symbol
`show_trace'
ld: /data/home/bguthro/dev/orc-newdev.git/orc-xen/xen-4.2/xen/.xen-syms.0:
hidden symbol `show_trace' isn't defined
ld: final link failed: Bad value
make[5]: *** [/data/home/bguthro/dev/orc-newdev.git/orc-xen/xen-4.2/xen/xen-syms]
Error 1
make[5]: Leaving directory
`/data/home/bguthro/dev/orc-newdev.git/orc-xen/xen-4.2/xen/arch/x86'
make[4]: *** [/data/home/bguthro/dev/orc-newdev.git/orc-xen/xen-4.2/xen/xen]
Error 2




On Wed, Aug 29, 2012 at 5:41 PM, Mukesh Rathor <mukesh.rathor@oracle.com> wrote:
> On Wed, 29 Aug 2012 14:35:12 -0700
> Mukesh Rathor <mukesh.rathor@oracle.com> wrote:
>
>
>>
>> Anyways, attaching patch that is cleaned up of my debug code that I
>> accidentally left in prev posting. Should apply cleanly to c/s 25467.
>
> really attaching this time :).
>

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

From xen-devel-bounces@lists.xen.org Wed Sep 05 16:28:43 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Sep 2012 16:28:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9ISe-00058X-VY; Wed, 05 Sep 2012 16:28:16 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1T9ISd-00058S-E7
	for xen-devel@lists.xensource.com; Wed, 05 Sep 2012 16:28:15 +0000
Received: from [85.158.138.51:41760] by server-2.bemta-3.messagelabs.com id
	E9/9B-04862-E9D77405; Wed, 05 Sep 2012 16:28:14 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1346862492!19951357!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzI4NDYw\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18227 invoked from network); 5 Sep 2012 16:28:13 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-7.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 5 Sep 2012 16:28:13 -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 q85GS8xh022065
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 5 Sep 2012 16:28:09 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q85GS7YL011243
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 5 Sep 2012 16:28:08 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
	q85GS78H029909; Wed, 5 Sep 2012 11:28:07 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 05 Sep 2012 09:28:07 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 689EB402C1; Wed,  5 Sep 2012 12:17:37 -0400 (EDT)
Date: Wed, 5 Sep 2012 12:17:37 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Andres Lagar-Cavilla <andreslc@gridcentric.ca>
Message-ID: <20120905161737.GB11949@phenom.dumpdata.com>
References: <1346331492-15027-1-git-send-email-david.vrabel@citrix.com>
	<1346331492-15027-3-git-send-email-david.vrabel@citrix.com>
	<DDCE284F-9506-4EF4-88BB-CF6A04D98A2F@gridcentric.ca>
	<5040B762.3060402@citrix.com>
	<6000F56A-3346-482A-8250-AE21AAE3DD12@gridcentric.ca>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <6000F56A-3346-482A-8250-AE21AAE3DD12@gridcentric.ca>
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, David Vrabel <david.vrabel@citrix.com>
Subject: Re: [Xen-devel] [PATCH 2/2] xen/privcmd: add PRIVCMD_MMAPBATCH_V2
 ioctl
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Aug 31, 2012 at 09:13:44AM -0400, Andres Lagar-Cavilla wrote:
> 
> On Aug 31, 2012, at 9:08 AM, David Vrabel wrote:
> 
> > On 30/08/12 19:32, Andres Lagar-Cavilla wrote:
> >> Second repost of my version, heavily based on David's. 
> > 
> > Doing another allocation that may be larger than a page (and its
> > associated additional error paths) seems to me to be a hammer to crack
> > the (admittedly bit wonky) casting nut.
> > 
> > That said, it's up to Konrad which version he prefers.
> 
> Yeah absolutely.

This one (with the comments) looks nicer. 
> 
> > 
> > There are also some minor improvements you could make if you respin this
> > patch.
> > 
> >> Complementary to this patch, on the xen tree I intend to add
> >> PRIVCMD_MMAPBATCH_*_ERROR into the libxc header files, and remove
> >> XEN_DOMCTL_PFINFO_PAGEDTAB from domctl.h
> > 
> > Yes, a good idea.  There's no correspondence between the ioctl's error
> > reporting values and the DOMCTL_PFINFO flags.
> > 
> >> commit 3f40e8d79b7e032527ee207a97499ddbc81ca12b
> >> Author: Andres Lagar-Cavilla <andres@lagarcavilla.org>
> >> Date:   Thu Aug 30 12:23:33 2012 -0400
> >> 
> >>    xen/privcmd: add PRIVCMD_MMAPBATCH_V2 ioctl
> >> 
> >>    PRIVCMD_MMAPBATCH_V2 extends PRIVCMD_MMAPBATCH with an additional
> >>    field for reporting the error code for every frame that could not be
> >>    mapped.  libxc prefers PRIVCMD_MMAPBATCH_V2 over PRIVCMD_MMAPBATCH.
> >> 
> >>    Also expand PRIVCMD_MMAPBATCH to return appropriate error-encoding top nibble
> >>    in the mfn array.
> >> 
> >>    Signed-off-by: David Vrabel <david.vrabel@citrix.com>
> >>    Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
> > [...]
> >> -static long privcmd_ioctl_mmap_batch(void __user *udata)
> >> +static long privcmd_ioctl_mmap_batch(void __user *udata, int version)
> >> {
> >> 	int ret;
> >> -	struct privcmd_mmapbatch m;
> >> +	struct privcmd_mmapbatch_v2 m;
> >> 	struct mm_struct *mm = current->mm;
> >> 	struct vm_area_struct *vma;
> >> 	unsigned long nr_pages;
> >> 	LIST_HEAD(pagelist);
> >> +	int *err_array;
> > 
> > int *err_array = NULL;
> > 
> > and you could avoid the additional jump label as kfree(NULL) is safe.
> 
> Didn't know, great.
> 
> > 
> >> 	struct mmap_batch_state state;
> >> 
> >> 	if (!xen_initial_domain())
> >> 		return -EPERM;
> >> 
> >> -	if (copy_from_user(&m, udata, sizeof(m)))
> >> -		return -EFAULT;
> >> +	switch (version) {
> >> +	case 1:
> >> +		if (copy_from_user(&m, udata, sizeof(struct privcmd_mmapbatch)))
> >> +			return -EFAULT;
> >> +		/* Returns per-frame error in m.arr. */
> >> +		m.err = NULL;
> >> +		if (!access_ok(VERIFY_WRITE, m.arr, m.num * sizeof(*m.arr)))
> >> +			return -EFAULT;
> >> +		break;
> >> +	case 2:
> >> +		if (copy_from_user(&m, udata, sizeof(struct privcmd_mmapbatch_v2)))
> >> +			return -EFAULT;
> >> +		/* Returns per-frame error code in m.err. */
> >> +		if (!access_ok(VERIFY_WRITE, m.err, m.num * (sizeof(*m.err))))
> >> +			return -EFAULT;
> >> +		break;
> >> +	default:
> >> +		return -EINVAL;
> >> +	}
> >> 
> >> 	nr_pages = m.num;
> >> 	if ((m.num <= 0) || (nr_pages > (LONG_MAX >> PAGE_SHIFT)))
> >> 		return -EINVAL;
> >> 
> >> -	ret = gather_array(&pagelist, m.num, sizeof(xen_pfn_t),
> >> -			   m.arr);
> >> +	ret = gather_array(&pagelist, m.num, sizeof(xen_pfn_t), m.arr);
> >> 
> >> 	if (ret || list_empty(&pagelist))
> >> -		goto out;
> >> +		goto out_no_err_array;
> >> +
> >> +	err_array = kmalloc_array(m.num, sizeof(int), GFP_KERNEL);
> > 
> > kcalloc() (see below).
> > 
> >> +	if (err_array == NULL)
> >> +	{
> > 
> > Style: if (err_array == NULL) {
> > 
> >> +	if (state.global_error) {
> >> +		int efault;
> >> +
> >> +		if (state.global_error == -ENOENT)
> >> +			ret = -ENOENT;
> >> +
> >> +		/* Write back errors in second pass. */
> >> +		state.user_mfn = (xen_pfn_t *)m.arr;
> >> +		state.user_err = m.err;
> >> +		state.err      = err_array;
> >> +		efault = traverse_pages(m.num, sizeof(xen_pfn_t),
> >> +					 &pagelist, mmap_return_errors, &state);
> >> +		if (efault)
> >> +			ret = efault;
> >> +	} else if (m.err)
> >> +		ret = __clear_user(m.err, m.num * sizeof(*m.err));
> > 
> > Since you have an array of errors already there's no need to iterate
> > through all the MFNs again for V2.  A simple copy_to_user() is
> > sufficient provided err_array was zeroed with kcalloc().
> I can kcalloc for extra paranoia, but the code will set all error slots, and is guaranteed to not jump over anything. I +1 the shortcut you outline below. Re-spin coming.
> Andres
> > 
> > if (m.err)
> >    ret = __copy_to_user(m.err, err_array, m.num * sizeof(*m.err));
> > else {
> >    /* Write back errors in second pass. */
> >    state.user_mfn = (xen_pfn_t *)m.arr;
> >    state.user_err = m.err;
> >    state.err      = err_array;
> >    ret = traverse_pages(m.num, sizeof(xen_pfn_t),
> >            &pagelist, mmap_return_errors, &state);
> > }
> > 
> > if (ret == 0 && state.global_error == -ENOENT)
> >    ret = -ENOENT;
> > 
> > David

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

From xen-devel-bounces@lists.xen.org Wed Sep 05 16:28:43 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Sep 2012 16:28:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9ISe-00058X-VY; Wed, 05 Sep 2012 16:28:16 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1T9ISd-00058S-E7
	for xen-devel@lists.xensource.com; Wed, 05 Sep 2012 16:28:15 +0000
Received: from [85.158.138.51:41760] by server-2.bemta-3.messagelabs.com id
	E9/9B-04862-E9D77405; Wed, 05 Sep 2012 16:28:14 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1346862492!19951357!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzI4NDYw\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18227 invoked from network); 5 Sep 2012 16:28:13 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-7.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 5 Sep 2012 16:28:13 -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 q85GS8xh022065
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 5 Sep 2012 16:28:09 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q85GS7YL011243
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 5 Sep 2012 16:28:08 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
	q85GS78H029909; Wed, 5 Sep 2012 11:28:07 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 05 Sep 2012 09:28:07 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 689EB402C1; Wed,  5 Sep 2012 12:17:37 -0400 (EDT)
Date: Wed, 5 Sep 2012 12:17:37 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Andres Lagar-Cavilla <andreslc@gridcentric.ca>
Message-ID: <20120905161737.GB11949@phenom.dumpdata.com>
References: <1346331492-15027-1-git-send-email-david.vrabel@citrix.com>
	<1346331492-15027-3-git-send-email-david.vrabel@citrix.com>
	<DDCE284F-9506-4EF4-88BB-CF6A04D98A2F@gridcentric.ca>
	<5040B762.3060402@citrix.com>
	<6000F56A-3346-482A-8250-AE21AAE3DD12@gridcentric.ca>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <6000F56A-3346-482A-8250-AE21AAE3DD12@gridcentric.ca>
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, David Vrabel <david.vrabel@citrix.com>
Subject: Re: [Xen-devel] [PATCH 2/2] xen/privcmd: add PRIVCMD_MMAPBATCH_V2
 ioctl
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Aug 31, 2012 at 09:13:44AM -0400, Andres Lagar-Cavilla wrote:
> 
> On Aug 31, 2012, at 9:08 AM, David Vrabel wrote:
> 
> > On 30/08/12 19:32, Andres Lagar-Cavilla wrote:
> >> Second repost of my version, heavily based on David's. 
> > 
> > Doing another allocation that may be larger than a page (and its
> > associated additional error paths) seems to me to be a hammer to crack
> > the (admittedly bit wonky) casting nut.
> > 
> > That said, it's up to Konrad which version he prefers.
> 
> Yeah absolutely.

This one (with the comments) looks nicer. 
> 
> > 
> > There are also some minor improvements you could make if you respin this
> > patch.
> > 
> >> Complementary to this patch, on the xen tree I intend to add
> >> PRIVCMD_MMAPBATCH_*_ERROR into the libxc header files, and remove
> >> XEN_DOMCTL_PFINFO_PAGEDTAB from domctl.h
> > 
> > Yes, a good idea.  There's no correspondence between the ioctl's error
> > reporting values and the DOMCTL_PFINFO flags.
> > 
> >> commit 3f40e8d79b7e032527ee207a97499ddbc81ca12b
> >> Author: Andres Lagar-Cavilla <andres@lagarcavilla.org>
> >> Date:   Thu Aug 30 12:23:33 2012 -0400
> >> 
> >>    xen/privcmd: add PRIVCMD_MMAPBATCH_V2 ioctl
> >> 
> >>    PRIVCMD_MMAPBATCH_V2 extends PRIVCMD_MMAPBATCH with an additional
> >>    field for reporting the error code for every frame that could not be
> >>    mapped.  libxc prefers PRIVCMD_MMAPBATCH_V2 over PRIVCMD_MMAPBATCH.
> >> 
> >>    Also expand PRIVCMD_MMAPBATCH to return appropriate error-encoding top nibble
> >>    in the mfn array.
> >> 
> >>    Signed-off-by: David Vrabel <david.vrabel@citrix.com>
> >>    Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
> > [...]
> >> -static long privcmd_ioctl_mmap_batch(void __user *udata)
> >> +static long privcmd_ioctl_mmap_batch(void __user *udata, int version)
> >> {
> >> 	int ret;
> >> -	struct privcmd_mmapbatch m;
> >> +	struct privcmd_mmapbatch_v2 m;
> >> 	struct mm_struct *mm = current->mm;
> >> 	struct vm_area_struct *vma;
> >> 	unsigned long nr_pages;
> >> 	LIST_HEAD(pagelist);
> >> +	int *err_array;
> > 
> > int *err_array = NULL;
> > 
> > and you could avoid the additional jump label as kfree(NULL) is safe.
> 
> Didn't know, great.
> 
> > 
> >> 	struct mmap_batch_state state;
> >> 
> >> 	if (!xen_initial_domain())
> >> 		return -EPERM;
> >> 
> >> -	if (copy_from_user(&m, udata, sizeof(m)))
> >> -		return -EFAULT;
> >> +	switch (version) {
> >> +	case 1:
> >> +		if (copy_from_user(&m, udata, sizeof(struct privcmd_mmapbatch)))
> >> +			return -EFAULT;
> >> +		/* Returns per-frame error in m.arr. */
> >> +		m.err = NULL;
> >> +		if (!access_ok(VERIFY_WRITE, m.arr, m.num * sizeof(*m.arr)))
> >> +			return -EFAULT;
> >> +		break;
> >> +	case 2:
> >> +		if (copy_from_user(&m, udata, sizeof(struct privcmd_mmapbatch_v2)))
> >> +			return -EFAULT;
> >> +		/* Returns per-frame error code in m.err. */
> >> +		if (!access_ok(VERIFY_WRITE, m.err, m.num * (sizeof(*m.err))))
> >> +			return -EFAULT;
> >> +		break;
> >> +	default:
> >> +		return -EINVAL;
> >> +	}
> >> 
> >> 	nr_pages = m.num;
> >> 	if ((m.num <= 0) || (nr_pages > (LONG_MAX >> PAGE_SHIFT)))
> >> 		return -EINVAL;
> >> 
> >> -	ret = gather_array(&pagelist, m.num, sizeof(xen_pfn_t),
> >> -			   m.arr);
> >> +	ret = gather_array(&pagelist, m.num, sizeof(xen_pfn_t), m.arr);
> >> 
> >> 	if (ret || list_empty(&pagelist))
> >> -		goto out;
> >> +		goto out_no_err_array;
> >> +
> >> +	err_array = kmalloc_array(m.num, sizeof(int), GFP_KERNEL);
> > 
> > kcalloc() (see below).
> > 
> >> +	if (err_array == NULL)
> >> +	{
> > 
> > Style: if (err_array == NULL) {
> > 
> >> +	if (state.global_error) {
> >> +		int efault;
> >> +
> >> +		if (state.global_error == -ENOENT)
> >> +			ret = -ENOENT;
> >> +
> >> +		/* Write back errors in second pass. */
> >> +		state.user_mfn = (xen_pfn_t *)m.arr;
> >> +		state.user_err = m.err;
> >> +		state.err      = err_array;
> >> +		efault = traverse_pages(m.num, sizeof(xen_pfn_t),
> >> +					 &pagelist, mmap_return_errors, &state);
> >> +		if (efault)
> >> +			ret = efault;
> >> +	} else if (m.err)
> >> +		ret = __clear_user(m.err, m.num * sizeof(*m.err));
> > 
> > Since you have an array of errors already there's no need to iterate
> > through all the MFNs again for V2.  A simple copy_to_user() is
> > sufficient provided err_array was zeroed with kcalloc().
> I can kcalloc for extra paranoia, but the code will set all error slots, and is guaranteed to not jump over anything. I +1 the shortcut you outline below. Re-spin coming.
> Andres
> > 
> > if (m.err)
> >    ret = __copy_to_user(m.err, err_array, m.num * sizeof(*m.err));
> > else {
> >    /* Write back errors in second pass. */
> >    state.user_mfn = (xen_pfn_t *)m.arr;
> >    state.user_err = m.err;
> >    state.err      = err_array;
> >    ret = traverse_pages(m.num, sizeof(xen_pfn_t),
> >            &pagelist, mmap_return_errors, &state);
> > }
> > 
> > if (ret == 0 && state.global_error == -ENOENT)
> >    ret = -ENOENT;
> > 
> > David

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

From xen-devel-bounces@lists.xen.org Wed Sep 05 16:33:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Sep 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 1T9IWi-0005GN-MC; Wed, 05 Sep 2012 16:32:28 +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 1T9IWg-0005GG-RP
	for xen-devel@lists.xensource.com; Wed, 05 Sep 2012 16:32:27 +0000
Received: from [85.158.139.83:11300] by server-9.bemta-5.messagelabs.com id
	1A/11-20529-99E77405; Wed, 05 Sep 2012 16:32:25 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1346862743!24810506!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzI4NDYw\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19652 invoked from network); 5 Sep 2012 16:32:24 -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; 5 Sep 2012 16:32:24 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q85GWKjl026567
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 5 Sep 2012 16:32:21 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q85GWIk0011993
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 5 Sep 2012 16:32:19 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
	q85GWIlC004636; Wed, 5 Sep 2012 11:32:18 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 05 Sep 2012 09:32:18 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 9473C402C1; Wed,  5 Sep 2012 12:21:48 -0400 (EDT)
Date: Wed, 5 Sep 2012 12:21:48 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Andres Lagar-Cavilla <andreslc@gridcentric.ca>
Message-ID: <20120905162148.GC11949@phenom.dumpdata.com>
References: <1346331492-15027-1-git-send-email-david.vrabel@citrix.com>
	<1346331492-15027-3-git-send-email-david.vrabel@citrix.com>
	<C989BE9D-E520-4D04-9028-6CE6CC765E76@gridcentric.ca>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <C989BE9D-E520-4D04-9028-6CE6CC765E76@gridcentric.ca>
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, David Vrabel <david.vrabel@citrix.com>
Subject: Re: [Xen-devel] [PATCH 2/2] xen/privcmd: add PRIVCMD_MMAPBATCH_V2
	ioctl
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Aug 31, 2012 at 09:59:30AM -0400, Andres Lagar-Cavilla wrote:
> Re-spin of alternative patch after David's feedback.
> Thanks
> Andres

applied. fixed some whitespace issues.
> 
> commit ab351a5cef1797935b083c2f6e72800a8949c515
> Author: Andres Lagar-Cavilla <andres@lagarcavilla.org>
> Date:   Thu Aug 30 12:23:33 2012 -0400
> 
>     xen/privcmd: add PRIVCMD_MMAPBATCH_V2 ioctl
>     
>     PRIVCMD_MMAPBATCH_V2 extends PRIVCMD_MMAPBATCH with an additional
>     field for reporting the error code for every frame that could not be
>     mapped.  libxc prefers PRIVCMD_MMAPBATCH_V2 over PRIVCMD_MMAPBATCH.
>     
>     Also expand PRIVCMD_MMAPBATCH to return appropriate error-encoding top nibble
>     in the mfn array.
>     
>     Signed-off-by: David Vrabel <david.vrabel@citrix.com>
>     Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
> 
> diff --git a/drivers/xen/privcmd.c b/drivers/xen/privcmd.c
> index 85226cb..5386f20 100644
> --- a/drivers/xen/privcmd.c
> +++ b/drivers/xen/privcmd.c
> @@ -76,7 +76,7 @@ static void free_page_list(struct list_head *pages)
>   */
>  static int gather_array(struct list_head *pagelist,
>  			unsigned nelem, size_t size,
> -			void __user *data)
> +			const void __user *data)
>  {
>  	unsigned pageidx;
>  	void *pagedata;
> @@ -246,61 +246,117 @@ struct mmap_batch_state {
>  	domid_t domain;
>  	unsigned long va;
>  	struct vm_area_struct *vma;
> -	int err;
> -
> -	xen_pfn_t __user *user;
> +	/* A tristate: 
> +	 *      0 for no errors
> +	 *      1 if at least one error has happened (and no
> +	 *          -ENOENT errors have happened)
> +	 *      -ENOENT if at least 1 -ENOENT has happened.
> +	 */
> +	int global_error;
> +	/* An array for individual errors */
> +	int *err;
> +
> +	/* User-space mfn array to store errors in the second pass for V1. */
> +	xen_pfn_t __user *user_mfn;
>  };
>  
>  static int mmap_batch_fn(void *data, void *state)
>  {
>  	xen_pfn_t *mfnp = data;
>  	struct mmap_batch_state *st = state;
> +	int ret;
>  
> -	if (xen_remap_domain_mfn_range(st->vma, st->va & PAGE_MASK, *mfnp, 1,
> -				       st->vma->vm_page_prot, st->domain) < 0) {
> -		*mfnp |= 0xf0000000U;
> -		st->err++;
> +	ret = xen_remap_domain_mfn_range(st->vma, st->va & PAGE_MASK, *mfnp, 1,
> +					 st->vma->vm_page_prot, st->domain);
> +
> +	/* Store error code for second pass. */
> +	*(st->err++) = ret;
> +
> +	/* And see if it affects the global_error. */
> +	if (ret < 0) {
> +		if (ret == -ENOENT)
> +			st->global_error = -ENOENT;
> +		else {
> +			/* Record that at least one error has happened. */
> +			if (st->global_error == 0)
> +				st->global_error = 1;
> +		}
>  	}
>  	st->va += PAGE_SIZE;
>  
>  	return 0;
>  }
>  
> -static int mmap_return_errors(void *data, void *state)
> +static int mmap_return_errors_v1(void *data, void *state)
>  {
>  	xen_pfn_t *mfnp = data;
>  	struct mmap_batch_state *st = state;
> -
> -	return put_user(*mfnp, st->user++);
> +	int err = *(st->err++);
> +
> +	/*
> +	 * V1 encodes the error codes in the 32bit top nibble of the 
> +	 * mfn (with its known limitations vis-a-vis 64 bit callers).
> +	 */
> +	*mfnp |= (err == -ENOENT) ?
> +				PRIVCMD_MMAPBATCH_PAGED_ERROR :
> +				PRIVCMD_MMAPBATCH_MFN_ERROR;
> +	return __put_user(*mfnp, st->user_mfn++);
>  }
>  
>  static struct vm_operations_struct privcmd_vm_ops;
>  
> -static long privcmd_ioctl_mmap_batch(void __user *udata)
> +static long privcmd_ioctl_mmap_batch(void __user *udata, int version)
>  {
>  	int ret;
> -	struct privcmd_mmapbatch m;
> +	struct privcmd_mmapbatch_v2 m;
>  	struct mm_struct *mm = current->mm;
>  	struct vm_area_struct *vma;
>  	unsigned long nr_pages;
>  	LIST_HEAD(pagelist);
> +	int *err_array = NULL;
>  	struct mmap_batch_state state;
>  
>  	if (!xen_initial_domain())
>  		return -EPERM;
>  
> -	if (copy_from_user(&m, udata, sizeof(m)))
> -		return -EFAULT;
> +	switch (version) {
> +	case 1:
> +		if (copy_from_user(&m, udata, sizeof(struct privcmd_mmapbatch)))
> +			return -EFAULT;
> +		/* Returns per-frame error in m.arr. */
> +		m.err = NULL;
> +		if (!access_ok(VERIFY_WRITE, m.arr, m.num * sizeof(*m.arr)))
> +			return -EFAULT;
> +		break;
> +	case 2:
> +		if (copy_from_user(&m, udata, sizeof(struct privcmd_mmapbatch_v2)))
> +			return -EFAULT;
> +		/* Returns per-frame error code in m.err. */
> +		if (!access_ok(VERIFY_WRITE, m.err, m.num * (sizeof(*m.err))))
> +			return -EFAULT;
> +		break;
> +	default:
> +		return -EINVAL;
> +	}
>  
>  	nr_pages = m.num;
>  	if ((m.num <= 0) || (nr_pages > (LONG_MAX >> PAGE_SHIFT)))
>  		return -EINVAL;
>  
> -	ret = gather_array(&pagelist, m.num, sizeof(xen_pfn_t),
> -			   m.arr);
> +	ret = gather_array(&pagelist, m.num, sizeof(xen_pfn_t), m.arr);
> +
> +	if (ret)
> +		goto out;
> +	if (list_empty(&pagelist)) {
> +		ret = -EINVAL;
> +		goto out;
> +    }
>  
> -	if (ret || list_empty(&pagelist))
> +	err_array = kcalloc(m.num, sizeof(int), GFP_KERNEL);
> +	if (err_array == NULL) {
> +		ret = -ENOMEM;
>  		goto out;
> +	}
>  
>  	down_write(&mm->mmap_sem);
>  
> @@ -315,24 +371,34 @@ static long privcmd_ioctl_mmap_batch(void __user *udata)
>  		goto out;
>  	}
>  
> -	state.domain = m.dom;
> -	state.vma = vma;
> -	state.va = m.addr;
> -	state.err = 0;
> +	state.domain        = m.dom;
> +	state.vma           = vma;
> +	state.va            = m.addr;
> +	state.global_error  = 0;
> +	state.err           = err_array;
>  
> -	ret = traverse_pages(m.num, sizeof(xen_pfn_t),
> -			     &pagelist, mmap_batch_fn, &state);
> +	/* mmap_batch_fn guarantees ret == 0 */
> +	BUG_ON(traverse_pages(m.num, sizeof(xen_pfn_t),
> +			     &pagelist, mmap_batch_fn, &state));
>  
>  	up_write(&mm->mmap_sem);
>  
> -	if (state.err > 0) {
> -		state.user = m.arr;
> +	if (state.global_error && (version == 1)) {
> +		/* Write back errors in second pass. */
> +		state.user_mfn = (xen_pfn_t *)m.arr;
> +		state.err      = err_array;
>  		ret = traverse_pages(m.num, sizeof(xen_pfn_t),
> -			       &pagelist,
> -			       mmap_return_errors, &state);
> -	}
> +					 &pagelist, mmap_return_errors_v1, &state);
> +	} else
> +		ret = __copy_to_user(m.err, err_array, m.num * sizeof(int));
> +
> +    /* If we have not had any EFAULT-like global errors then set the global
> +     * error to -ENOENT if necessary. */
> +    if ((ret == 0) && (state.global_error == -ENOENT))
> +        ret = -ENOENT;
>  
>  out:
> +	kfree(err_array);
>  	free_page_list(&pagelist);
>  
>  	return ret;
> @@ -354,7 +420,11 @@ static long privcmd_ioctl(struct file *file,
>  		break;
>  
>  	case IOCTL_PRIVCMD_MMAPBATCH:
> -		ret = privcmd_ioctl_mmap_batch(udata);
> +		ret = privcmd_ioctl_mmap_batch(udata, 1);
> +		break;
> +
> +	case IOCTL_PRIVCMD_MMAPBATCH_V2:
> +		ret = privcmd_ioctl_mmap_batch(udata, 2);
>  		break;
>  
>  	default:
> diff --git a/include/xen/privcmd.h b/include/xen/privcmd.h
> index 45c1aa1..a853168 100644
> --- a/include/xen/privcmd.h
> +++ b/include/xen/privcmd.h
> @@ -58,13 +58,33 @@ struct privcmd_mmapbatch {
>  	int num;     /* number of pages to populate */
>  	domid_t dom; /* target domain */
>  	__u64 addr;  /* virtual address */
> -	xen_pfn_t __user *arr; /* array of mfns - top nibble set on err */
> +	xen_pfn_t __user *arr; /* array of mfns - or'd with
> +				  PRIVCMD_MMAPBATCH_*_ERROR on err */
> +};
> +
> +#define PRIVCMD_MMAPBATCH_MFN_ERROR     0xf0000000U
> +#define PRIVCMD_MMAPBATCH_PAGED_ERROR   0x80000000U
> +
> +struct privcmd_mmapbatch_v2 {
> +	unsigned int num; /* number of pages to populate */
> +	domid_t dom;      /* target domain */
> +	__u64 addr;       /* virtual address */
> +	const xen_pfn_t __user *arr; /* array of mfns */
> +	int __user *err;  /* array of error codes */
>  };
>  
>  /*
>   * @cmd: IOCTL_PRIVCMD_HYPERCALL
>   * @arg: &privcmd_hypercall_t
>   * Return: Value returned from execution of the specified hypercall.
> + *
> + * @cmd: IOCTL_PRIVCMD_MMAPBATCH_V2
> + * @arg: &struct privcmd_mmapbatch_v2
> + * Return: 0 on success (i.e., arg->err contains valid error codes for
> + * each frame).  On an error other than a failed frame remap, -1 is
> + * returned and errno is set to EINVAL, EFAULT etc.  As an exception,
> + * if the operation was otherwise successful but any frame failed with
> + * -ENOENT, then -1 is returned and errno is set to ENOENT.
>   */
>  #define IOCTL_PRIVCMD_HYPERCALL					\
>  	_IOC(_IOC_NONE, 'P', 0, sizeof(struct privcmd_hypercall))
> @@ -72,5 +92,7 @@ struct privcmd_mmapbatch {
>  	_IOC(_IOC_NONE, 'P', 2, sizeof(struct privcmd_mmap))
>  #define IOCTL_PRIVCMD_MMAPBATCH					\
>  	_IOC(_IOC_NONE, 'P', 3, sizeof(struct privcmd_mmapbatch))
> +#define IOCTL_PRIVCMD_MMAPBATCH_V2				\
> +	_IOC(_IOC_NONE, 'P', 4, sizeof(struct privcmd_mmapbatch_v2))
>  
>  #endif /* __LINUX_PUBLIC_PRIVCMD_H__ */
> 
> On Aug 30, 2012, at 8:58 AM, David Vrabel wrote:
> 
> > From: David Vrabel <david.vrabel@citrix.com>
> > 
> > PRIVCMD_MMAPBATCH_V2 extends PRIVCMD_MMAPBATCH with an additional
> > field for reporting the error code for every frame that could not be
> > mapped.  libxc prefers PRIVCMD_MMAPBATCH_V2 over PRIVCMD_MMAPBATCH.
> > 
> > Signed-off-by: David Vrabel <david.vrabel@citrix.com>
> > ---
> > drivers/xen/privcmd.c |   99 +++++++++++++++++++++++++++++++++++++++---------
> > include/xen/privcmd.h |   23 +++++++++++-
> > 2 files changed, 102 insertions(+), 20 deletions(-)
> > 
> > diff --git a/drivers/xen/privcmd.c b/drivers/xen/privcmd.c
> > index ccee0f1..c0e89e7 100644
> > --- a/drivers/xen/privcmd.c
> > +++ b/drivers/xen/privcmd.c
> > @@ -76,7 +76,7 @@ static void free_page_list(struct list_head *pages)
> >  */
> > static int gather_array(struct list_head *pagelist,
> > 			unsigned nelem, size_t size,
> > -			void __user *data)
> > +			const void __user *data)
> > {
> > 	unsigned pageidx;
> > 	void *pagedata;
> > @@ -248,18 +248,37 @@ struct mmap_batch_state {
> > 	struct vm_area_struct *vma;
> > 	int err;
> > 
> > -	xen_pfn_t __user *user;
> > +	xen_pfn_t __user *user_mfn;
> > +	int __user *user_err;
> > };
> > 
> > static int mmap_batch_fn(void *data, void *state)
> > {
> > 	xen_pfn_t *mfnp = data;
> > 	struct mmap_batch_state *st = state;
> > +	int ret;
> > 
> > -	if (xen_remap_domain_mfn_range(st->vma, st->va & PAGE_MASK, *mfnp, 1,
> > -				       st->vma->vm_page_prot, st->domain) < 0) {
> > -		*mfnp |= 0xf0000000U;
> > -		st->err++;
> > +	ret = xen_remap_domain_mfn_range(st->vma, st->va & PAGE_MASK, *mfnp, 1,
> > +					 st->vma->vm_page_prot, st->domain);
> > +	if (ret < 0) {
> > +		/*
> > +		 * Error reporting is a mess but userspace relies on
> > +		 * it behaving this way.
> > +		 *
> > +		 * V2 needs to a) return the result of each frame's
> > +		 * remap; and b) return -ENOENT if any frame failed
> > +		 * with -ENOENT.
> > +		 *
> > +		 * In this first pass the error code is saved by
> > +		 * overwriting the mfn and an error is indicated in
> > +		 * st->err.
> > +		 *
> > +		 * The second pass by mmap_return_errors() will write
> > +		 * the error codes to user space and get the right
> > +		 * ioctl return value.
> > +		 */
> > +		*(int *)mfnp = ret;
> > +		st->err = ret;
> > 	}
> > 	st->va += PAGE_SIZE;
> > 
> > @@ -270,16 +289,33 @@ static int mmap_return_errors(void *data, void *state)
> > {
> > 	xen_pfn_t *mfnp = data;
> > 	struct mmap_batch_state *st = state;
> > +	int ret;
> > +
> > +	if (st->user_err) {
> > +		int err = *(int *)mfnp;
> > +
> > +		if (err == -ENOENT)
> > +			st->err = err;
> > 
> > -	return put_user(*mfnp, st->user++);
> > +		return __put_user(err, st->user_err++);
> > +	} else {
> > +		xen_pfn_t mfn;
> > +
> > +		ret = __get_user(mfn, st->user_mfn);
> > +		if (ret < 0)
> > +			return ret;
> > +
> > +		mfn |= PRIVCMD_MMAPBATCH_MFN_ERROR;
> > +		return __put_user(mfn, st->user_mfn++);
> > +	}
> > }
> > 
> > static struct vm_operations_struct privcmd_vm_ops;
> > 
> > -static long privcmd_ioctl_mmap_batch(void __user *udata)
> > +static long privcmd_ioctl_mmap_batch(void __user *udata, int version)
> > {
> > 	int ret;
> > -	struct privcmd_mmapbatch m;
> > +	struct privcmd_mmapbatch_v2 m;
> > 	struct mm_struct *mm = current->mm;
> > 	struct vm_area_struct *vma;
> > 	unsigned long nr_pages;
> > @@ -289,15 +325,31 @@ static long privcmd_ioctl_mmap_batch(void __user *udata)
> > 	if (!xen_initial_domain())
> > 		return -EPERM;
> > 
> > -	if (copy_from_user(&m, udata, sizeof(m)))
> > -		return -EFAULT;
> > +	switch (version) {
> > +	case 1:
> > +		if (copy_from_user(&m, udata, sizeof(struct privcmd_mmapbatch)))
> > +			return -EFAULT;
> > +		/* Returns per-frame error in m.arr. */
> > +		m.err = NULL;
> > +		if (!access_ok(VERIFY_WRITE, m.arr, m.num * sizeof(*m.arr)))
> > +			return -EFAULT;
> > +		break;
> > +	case 2:
> > +		if (copy_from_user(&m, udata, sizeof(struct privcmd_mmapbatch_v2)))
> > +			return -EFAULT;
> > +		/* Returns per-frame error code in m.err. */
> > +		if (!access_ok(VERIFY_WRITE, m.err, m.num * (sizeof(*m.err))))
> > +			return -EFAULT;
> > +		break;
> > +	default:
> > +		return -EINVAL;
> > +	}
> > 
> > 	nr_pages = m.num;
> > 	if ((m.num <= 0) || (nr_pages > (LONG_MAX >> PAGE_SHIFT)))
> > 		return -EINVAL;
> > 
> > -	ret = gather_array(&pagelist, m.num, sizeof(xen_pfn_t),
> > -			   m.arr);
> > +	ret = gather_array(&pagelist, m.num, sizeof(xen_pfn_t), m.arr);
> > 
> > 	if (ret || list_empty(&pagelist))
> > 		goto out;
> > @@ -325,12 +377,17 @@ static long privcmd_ioctl_mmap_batch(void __user *udata)
> > 
> > 	up_write(&mm->mmap_sem);
> > 
> > -	if (state.err > 0) {
> > -		state.user = m.arr;
> > +	if (state.err) {
> > +		state.err = 0;
> > +		state.user_mfn = (xen_pfn_t *)m.arr;
> > +		state.user_err = m.err;
> > 		ret = traverse_pages(m.num, sizeof(xen_pfn_t),
> > -			       &pagelist,
> > -			       mmap_return_errors, &state);
> > -	}
> > +				     &pagelist,
> > +				     mmap_return_errors, &state);
> > +		if (ret >= 0)
> > +			ret = state.err;
> > +	} else if (m.err)
> > +		__clear_user(m.err, m.num * sizeof(*m.err));
> > 
> > out:
> > 	free_page_list(&pagelist);
> > @@ -354,7 +411,11 @@ static long privcmd_ioctl(struct file *file,
> > 		break;
> > 
> > 	case IOCTL_PRIVCMD_MMAPBATCH:
> > -		ret = privcmd_ioctl_mmap_batch(udata);
> > +		ret = privcmd_ioctl_mmap_batch(udata, 1);
> > +		break;
> > +
> > +	case IOCTL_PRIVCMD_MMAPBATCH_V2:
> > +		ret = privcmd_ioctl_mmap_batch(udata, 2);
> > 		break;
> > 
> > 	default:
> > diff --git a/include/xen/privcmd.h b/include/xen/privcmd.h
> > index 17857fb..f60d75c 100644
> > --- a/include/xen/privcmd.h
> > +++ b/include/xen/privcmd.h
> > @@ -59,13 +59,32 @@ struct privcmd_mmapbatch {
> > 	int num;     /* number of pages to populate */
> > 	domid_t dom; /* target domain */
> > 	__u64 addr;  /* virtual address */
> > -	xen_pfn_t __user *arr; /* array of mfns - top nibble set on err */
> > +	xen_pfn_t __user *arr; /* array of mfns - or'd with
> > +				  PRIVCMD_MMAPBATCH_MFN_ERROR on err */
> > +};
> > +
> > +#define PRIVCMD_MMAPBATCH_MFN_ERROR 0xf0000000U
> > +
> > +struct privcmd_mmapbatch_v2 {
> > +	unsigned int num; /* number of pages to populate */
> > +	domid_t dom;      /* target domain */
> > +	__u64 addr;       /* virtual address */
> > +	const xen_pfn_t __user *arr; /* array of mfns */
> > +	int __user *err;  /* array of error codes */
> > };
> > 
> > /*
> >  * @cmd: IOCTL_PRIVCMD_HYPERCALL
> >  * @arg: &privcmd_hypercall_t
> >  * Return: Value returned from execution of the specified hypercall.
> > + *
> > + * @cmd: IOCTL_PRIVCMD_MMAPBATCH_V2
> > + * @arg: &struct privcmd_mmapbatch_v2
> > + * Return: 0 on success (i.e., arg->err contains valid error codes for
> > + * each frame).  On an error other than a failed frame remap, -1 is
> > + * returned and errno is set to EINVAL, EFAULT etc.  As an exception,
> > + * if the operation was otherwise successful but any frame failed with
> > + * -ENOENT, then -1 is returned and errno is set to ENOENT.
> >  */
> > #define IOCTL_PRIVCMD_HYPERCALL					\
> > 	_IOC(_IOC_NONE, 'P', 0, sizeof(struct privcmd_hypercall))
> > @@ -73,5 +92,7 @@ struct privcmd_mmapbatch {
> > 	_IOC(_IOC_NONE, 'P', 2, sizeof(struct privcmd_mmap))
> > #define IOCTL_PRIVCMD_MMAPBATCH					\
> > 	_IOC(_IOC_NONE, 'P', 3, sizeof(struct privcmd_mmapbatch))
> > +#define IOCTL_PRIVCMD_MMAPBATCH_V2				\
> > +	_IOC(_IOC_NONE, 'P', 4, sizeof(struct privcmd_mmapbatch_v2))
> > 
> > #endif /* __LINUX_PUBLIC_PRIVCMD_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 Wed Sep 05 16:33:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Sep 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 1T9IWi-0005GN-MC; Wed, 05 Sep 2012 16:32:28 +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 1T9IWg-0005GG-RP
	for xen-devel@lists.xensource.com; Wed, 05 Sep 2012 16:32:27 +0000
Received: from [85.158.139.83:11300] by server-9.bemta-5.messagelabs.com id
	1A/11-20529-99E77405; Wed, 05 Sep 2012 16:32:25 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1346862743!24810506!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzI4NDYw\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19652 invoked from network); 5 Sep 2012 16:32:24 -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; 5 Sep 2012 16:32:24 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q85GWKjl026567
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 5 Sep 2012 16:32:21 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q85GWIk0011993
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 5 Sep 2012 16:32:19 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
	q85GWIlC004636; Wed, 5 Sep 2012 11:32:18 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 05 Sep 2012 09:32:18 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 9473C402C1; Wed,  5 Sep 2012 12:21:48 -0400 (EDT)
Date: Wed, 5 Sep 2012 12:21:48 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Andres Lagar-Cavilla <andreslc@gridcentric.ca>
Message-ID: <20120905162148.GC11949@phenom.dumpdata.com>
References: <1346331492-15027-1-git-send-email-david.vrabel@citrix.com>
	<1346331492-15027-3-git-send-email-david.vrabel@citrix.com>
	<C989BE9D-E520-4D04-9028-6CE6CC765E76@gridcentric.ca>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <C989BE9D-E520-4D04-9028-6CE6CC765E76@gridcentric.ca>
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, David Vrabel <david.vrabel@citrix.com>
Subject: Re: [Xen-devel] [PATCH 2/2] xen/privcmd: add PRIVCMD_MMAPBATCH_V2
	ioctl
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Aug 31, 2012 at 09:59:30AM -0400, Andres Lagar-Cavilla wrote:
> Re-spin of alternative patch after David's feedback.
> Thanks
> Andres

applied. fixed some whitespace issues.
> 
> commit ab351a5cef1797935b083c2f6e72800a8949c515
> Author: Andres Lagar-Cavilla <andres@lagarcavilla.org>
> Date:   Thu Aug 30 12:23:33 2012 -0400
> 
>     xen/privcmd: add PRIVCMD_MMAPBATCH_V2 ioctl
>     
>     PRIVCMD_MMAPBATCH_V2 extends PRIVCMD_MMAPBATCH with an additional
>     field for reporting the error code for every frame that could not be
>     mapped.  libxc prefers PRIVCMD_MMAPBATCH_V2 over PRIVCMD_MMAPBATCH.
>     
>     Also expand PRIVCMD_MMAPBATCH to return appropriate error-encoding top nibble
>     in the mfn array.
>     
>     Signed-off-by: David Vrabel <david.vrabel@citrix.com>
>     Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
> 
> diff --git a/drivers/xen/privcmd.c b/drivers/xen/privcmd.c
> index 85226cb..5386f20 100644
> --- a/drivers/xen/privcmd.c
> +++ b/drivers/xen/privcmd.c
> @@ -76,7 +76,7 @@ static void free_page_list(struct list_head *pages)
>   */
>  static int gather_array(struct list_head *pagelist,
>  			unsigned nelem, size_t size,
> -			void __user *data)
> +			const void __user *data)
>  {
>  	unsigned pageidx;
>  	void *pagedata;
> @@ -246,61 +246,117 @@ struct mmap_batch_state {
>  	domid_t domain;
>  	unsigned long va;
>  	struct vm_area_struct *vma;
> -	int err;
> -
> -	xen_pfn_t __user *user;
> +	/* A tristate: 
> +	 *      0 for no errors
> +	 *      1 if at least one error has happened (and no
> +	 *          -ENOENT errors have happened)
> +	 *      -ENOENT if at least 1 -ENOENT has happened.
> +	 */
> +	int global_error;
> +	/* An array for individual errors */
> +	int *err;
> +
> +	/* User-space mfn array to store errors in the second pass for V1. */
> +	xen_pfn_t __user *user_mfn;
>  };
>  
>  static int mmap_batch_fn(void *data, void *state)
>  {
>  	xen_pfn_t *mfnp = data;
>  	struct mmap_batch_state *st = state;
> +	int ret;
>  
> -	if (xen_remap_domain_mfn_range(st->vma, st->va & PAGE_MASK, *mfnp, 1,
> -				       st->vma->vm_page_prot, st->domain) < 0) {
> -		*mfnp |= 0xf0000000U;
> -		st->err++;
> +	ret = xen_remap_domain_mfn_range(st->vma, st->va & PAGE_MASK, *mfnp, 1,
> +					 st->vma->vm_page_prot, st->domain);
> +
> +	/* Store error code for second pass. */
> +	*(st->err++) = ret;
> +
> +	/* And see if it affects the global_error. */
> +	if (ret < 0) {
> +		if (ret == -ENOENT)
> +			st->global_error = -ENOENT;
> +		else {
> +			/* Record that at least one error has happened. */
> +			if (st->global_error == 0)
> +				st->global_error = 1;
> +		}
>  	}
>  	st->va += PAGE_SIZE;
>  
>  	return 0;
>  }
>  
> -static int mmap_return_errors(void *data, void *state)
> +static int mmap_return_errors_v1(void *data, void *state)
>  {
>  	xen_pfn_t *mfnp = data;
>  	struct mmap_batch_state *st = state;
> -
> -	return put_user(*mfnp, st->user++);
> +	int err = *(st->err++);
> +
> +	/*
> +	 * V1 encodes the error codes in the 32bit top nibble of the 
> +	 * mfn (with its known limitations vis-a-vis 64 bit callers).
> +	 */
> +	*mfnp |= (err == -ENOENT) ?
> +				PRIVCMD_MMAPBATCH_PAGED_ERROR :
> +				PRIVCMD_MMAPBATCH_MFN_ERROR;
> +	return __put_user(*mfnp, st->user_mfn++);
>  }
>  
>  static struct vm_operations_struct privcmd_vm_ops;
>  
> -static long privcmd_ioctl_mmap_batch(void __user *udata)
> +static long privcmd_ioctl_mmap_batch(void __user *udata, int version)
>  {
>  	int ret;
> -	struct privcmd_mmapbatch m;
> +	struct privcmd_mmapbatch_v2 m;
>  	struct mm_struct *mm = current->mm;
>  	struct vm_area_struct *vma;
>  	unsigned long nr_pages;
>  	LIST_HEAD(pagelist);
> +	int *err_array = NULL;
>  	struct mmap_batch_state state;
>  
>  	if (!xen_initial_domain())
>  		return -EPERM;
>  
> -	if (copy_from_user(&m, udata, sizeof(m)))
> -		return -EFAULT;
> +	switch (version) {
> +	case 1:
> +		if (copy_from_user(&m, udata, sizeof(struct privcmd_mmapbatch)))
> +			return -EFAULT;
> +		/* Returns per-frame error in m.arr. */
> +		m.err = NULL;
> +		if (!access_ok(VERIFY_WRITE, m.arr, m.num * sizeof(*m.arr)))
> +			return -EFAULT;
> +		break;
> +	case 2:
> +		if (copy_from_user(&m, udata, sizeof(struct privcmd_mmapbatch_v2)))
> +			return -EFAULT;
> +		/* Returns per-frame error code in m.err. */
> +		if (!access_ok(VERIFY_WRITE, m.err, m.num * (sizeof(*m.err))))
> +			return -EFAULT;
> +		break;
> +	default:
> +		return -EINVAL;
> +	}
>  
>  	nr_pages = m.num;
>  	if ((m.num <= 0) || (nr_pages > (LONG_MAX >> PAGE_SHIFT)))
>  		return -EINVAL;
>  
> -	ret = gather_array(&pagelist, m.num, sizeof(xen_pfn_t),
> -			   m.arr);
> +	ret = gather_array(&pagelist, m.num, sizeof(xen_pfn_t), m.arr);
> +
> +	if (ret)
> +		goto out;
> +	if (list_empty(&pagelist)) {
> +		ret = -EINVAL;
> +		goto out;
> +    }
>  
> -	if (ret || list_empty(&pagelist))
> +	err_array = kcalloc(m.num, sizeof(int), GFP_KERNEL);
> +	if (err_array == NULL) {
> +		ret = -ENOMEM;
>  		goto out;
> +	}
>  
>  	down_write(&mm->mmap_sem);
>  
> @@ -315,24 +371,34 @@ static long privcmd_ioctl_mmap_batch(void __user *udata)
>  		goto out;
>  	}
>  
> -	state.domain = m.dom;
> -	state.vma = vma;
> -	state.va = m.addr;
> -	state.err = 0;
> +	state.domain        = m.dom;
> +	state.vma           = vma;
> +	state.va            = m.addr;
> +	state.global_error  = 0;
> +	state.err           = err_array;
>  
> -	ret = traverse_pages(m.num, sizeof(xen_pfn_t),
> -			     &pagelist, mmap_batch_fn, &state);
> +	/* mmap_batch_fn guarantees ret == 0 */
> +	BUG_ON(traverse_pages(m.num, sizeof(xen_pfn_t),
> +			     &pagelist, mmap_batch_fn, &state));
>  
>  	up_write(&mm->mmap_sem);
>  
> -	if (state.err > 0) {
> -		state.user = m.arr;
> +	if (state.global_error && (version == 1)) {
> +		/* Write back errors in second pass. */
> +		state.user_mfn = (xen_pfn_t *)m.arr;
> +		state.err      = err_array;
>  		ret = traverse_pages(m.num, sizeof(xen_pfn_t),
> -			       &pagelist,
> -			       mmap_return_errors, &state);
> -	}
> +					 &pagelist, mmap_return_errors_v1, &state);
> +	} else
> +		ret = __copy_to_user(m.err, err_array, m.num * sizeof(int));
> +
> +    /* If we have not had any EFAULT-like global errors then set the global
> +     * error to -ENOENT if necessary. */
> +    if ((ret == 0) && (state.global_error == -ENOENT))
> +        ret = -ENOENT;
>  
>  out:
> +	kfree(err_array);
>  	free_page_list(&pagelist);
>  
>  	return ret;
> @@ -354,7 +420,11 @@ static long privcmd_ioctl(struct file *file,
>  		break;
>  
>  	case IOCTL_PRIVCMD_MMAPBATCH:
> -		ret = privcmd_ioctl_mmap_batch(udata);
> +		ret = privcmd_ioctl_mmap_batch(udata, 1);
> +		break;
> +
> +	case IOCTL_PRIVCMD_MMAPBATCH_V2:
> +		ret = privcmd_ioctl_mmap_batch(udata, 2);
>  		break;
>  
>  	default:
> diff --git a/include/xen/privcmd.h b/include/xen/privcmd.h
> index 45c1aa1..a853168 100644
> --- a/include/xen/privcmd.h
> +++ b/include/xen/privcmd.h
> @@ -58,13 +58,33 @@ struct privcmd_mmapbatch {
>  	int num;     /* number of pages to populate */
>  	domid_t dom; /* target domain */
>  	__u64 addr;  /* virtual address */
> -	xen_pfn_t __user *arr; /* array of mfns - top nibble set on err */
> +	xen_pfn_t __user *arr; /* array of mfns - or'd with
> +				  PRIVCMD_MMAPBATCH_*_ERROR on err */
> +};
> +
> +#define PRIVCMD_MMAPBATCH_MFN_ERROR     0xf0000000U
> +#define PRIVCMD_MMAPBATCH_PAGED_ERROR   0x80000000U
> +
> +struct privcmd_mmapbatch_v2 {
> +	unsigned int num; /* number of pages to populate */
> +	domid_t dom;      /* target domain */
> +	__u64 addr;       /* virtual address */
> +	const xen_pfn_t __user *arr; /* array of mfns */
> +	int __user *err;  /* array of error codes */
>  };
>  
>  /*
>   * @cmd: IOCTL_PRIVCMD_HYPERCALL
>   * @arg: &privcmd_hypercall_t
>   * Return: Value returned from execution of the specified hypercall.
> + *
> + * @cmd: IOCTL_PRIVCMD_MMAPBATCH_V2
> + * @arg: &struct privcmd_mmapbatch_v2
> + * Return: 0 on success (i.e., arg->err contains valid error codes for
> + * each frame).  On an error other than a failed frame remap, -1 is
> + * returned and errno is set to EINVAL, EFAULT etc.  As an exception,
> + * if the operation was otherwise successful but any frame failed with
> + * -ENOENT, then -1 is returned and errno is set to ENOENT.
>   */
>  #define IOCTL_PRIVCMD_HYPERCALL					\
>  	_IOC(_IOC_NONE, 'P', 0, sizeof(struct privcmd_hypercall))
> @@ -72,5 +92,7 @@ struct privcmd_mmapbatch {
>  	_IOC(_IOC_NONE, 'P', 2, sizeof(struct privcmd_mmap))
>  #define IOCTL_PRIVCMD_MMAPBATCH					\
>  	_IOC(_IOC_NONE, 'P', 3, sizeof(struct privcmd_mmapbatch))
> +#define IOCTL_PRIVCMD_MMAPBATCH_V2				\
> +	_IOC(_IOC_NONE, 'P', 4, sizeof(struct privcmd_mmapbatch_v2))
>  
>  #endif /* __LINUX_PUBLIC_PRIVCMD_H__ */
> 
> On Aug 30, 2012, at 8:58 AM, David Vrabel wrote:
> 
> > From: David Vrabel <david.vrabel@citrix.com>
> > 
> > PRIVCMD_MMAPBATCH_V2 extends PRIVCMD_MMAPBATCH with an additional
> > field for reporting the error code for every frame that could not be
> > mapped.  libxc prefers PRIVCMD_MMAPBATCH_V2 over PRIVCMD_MMAPBATCH.
> > 
> > Signed-off-by: David Vrabel <david.vrabel@citrix.com>
> > ---
> > drivers/xen/privcmd.c |   99 +++++++++++++++++++++++++++++++++++++++---------
> > include/xen/privcmd.h |   23 +++++++++++-
> > 2 files changed, 102 insertions(+), 20 deletions(-)
> > 
> > diff --git a/drivers/xen/privcmd.c b/drivers/xen/privcmd.c
> > index ccee0f1..c0e89e7 100644
> > --- a/drivers/xen/privcmd.c
> > +++ b/drivers/xen/privcmd.c
> > @@ -76,7 +76,7 @@ static void free_page_list(struct list_head *pages)
> >  */
> > static int gather_array(struct list_head *pagelist,
> > 			unsigned nelem, size_t size,
> > -			void __user *data)
> > +			const void __user *data)
> > {
> > 	unsigned pageidx;
> > 	void *pagedata;
> > @@ -248,18 +248,37 @@ struct mmap_batch_state {
> > 	struct vm_area_struct *vma;
> > 	int err;
> > 
> > -	xen_pfn_t __user *user;
> > +	xen_pfn_t __user *user_mfn;
> > +	int __user *user_err;
> > };
> > 
> > static int mmap_batch_fn(void *data, void *state)
> > {
> > 	xen_pfn_t *mfnp = data;
> > 	struct mmap_batch_state *st = state;
> > +	int ret;
> > 
> > -	if (xen_remap_domain_mfn_range(st->vma, st->va & PAGE_MASK, *mfnp, 1,
> > -				       st->vma->vm_page_prot, st->domain) < 0) {
> > -		*mfnp |= 0xf0000000U;
> > -		st->err++;
> > +	ret = xen_remap_domain_mfn_range(st->vma, st->va & PAGE_MASK, *mfnp, 1,
> > +					 st->vma->vm_page_prot, st->domain);
> > +	if (ret < 0) {
> > +		/*
> > +		 * Error reporting is a mess but userspace relies on
> > +		 * it behaving this way.
> > +		 *
> > +		 * V2 needs to a) return the result of each frame's
> > +		 * remap; and b) return -ENOENT if any frame failed
> > +		 * with -ENOENT.
> > +		 *
> > +		 * In this first pass the error code is saved by
> > +		 * overwriting the mfn and an error is indicated in
> > +		 * st->err.
> > +		 *
> > +		 * The second pass by mmap_return_errors() will write
> > +		 * the error codes to user space and get the right
> > +		 * ioctl return value.
> > +		 */
> > +		*(int *)mfnp = ret;
> > +		st->err = ret;
> > 	}
> > 	st->va += PAGE_SIZE;
> > 
> > @@ -270,16 +289,33 @@ static int mmap_return_errors(void *data, void *state)
> > {
> > 	xen_pfn_t *mfnp = data;
> > 	struct mmap_batch_state *st = state;
> > +	int ret;
> > +
> > +	if (st->user_err) {
> > +		int err = *(int *)mfnp;
> > +
> > +		if (err == -ENOENT)
> > +			st->err = err;
> > 
> > -	return put_user(*mfnp, st->user++);
> > +		return __put_user(err, st->user_err++);
> > +	} else {
> > +		xen_pfn_t mfn;
> > +
> > +		ret = __get_user(mfn, st->user_mfn);
> > +		if (ret < 0)
> > +			return ret;
> > +
> > +		mfn |= PRIVCMD_MMAPBATCH_MFN_ERROR;
> > +		return __put_user(mfn, st->user_mfn++);
> > +	}
> > }
> > 
> > static struct vm_operations_struct privcmd_vm_ops;
> > 
> > -static long privcmd_ioctl_mmap_batch(void __user *udata)
> > +static long privcmd_ioctl_mmap_batch(void __user *udata, int version)
> > {
> > 	int ret;
> > -	struct privcmd_mmapbatch m;
> > +	struct privcmd_mmapbatch_v2 m;
> > 	struct mm_struct *mm = current->mm;
> > 	struct vm_area_struct *vma;
> > 	unsigned long nr_pages;
> > @@ -289,15 +325,31 @@ static long privcmd_ioctl_mmap_batch(void __user *udata)
> > 	if (!xen_initial_domain())
> > 		return -EPERM;
> > 
> > -	if (copy_from_user(&m, udata, sizeof(m)))
> > -		return -EFAULT;
> > +	switch (version) {
> > +	case 1:
> > +		if (copy_from_user(&m, udata, sizeof(struct privcmd_mmapbatch)))
> > +			return -EFAULT;
> > +		/* Returns per-frame error in m.arr. */
> > +		m.err = NULL;
> > +		if (!access_ok(VERIFY_WRITE, m.arr, m.num * sizeof(*m.arr)))
> > +			return -EFAULT;
> > +		break;
> > +	case 2:
> > +		if (copy_from_user(&m, udata, sizeof(struct privcmd_mmapbatch_v2)))
> > +			return -EFAULT;
> > +		/* Returns per-frame error code in m.err. */
> > +		if (!access_ok(VERIFY_WRITE, m.err, m.num * (sizeof(*m.err))))
> > +			return -EFAULT;
> > +		break;
> > +	default:
> > +		return -EINVAL;
> > +	}
> > 
> > 	nr_pages = m.num;
> > 	if ((m.num <= 0) || (nr_pages > (LONG_MAX >> PAGE_SHIFT)))
> > 		return -EINVAL;
> > 
> > -	ret = gather_array(&pagelist, m.num, sizeof(xen_pfn_t),
> > -			   m.arr);
> > +	ret = gather_array(&pagelist, m.num, sizeof(xen_pfn_t), m.arr);
> > 
> > 	if (ret || list_empty(&pagelist))
> > 		goto out;
> > @@ -325,12 +377,17 @@ static long privcmd_ioctl_mmap_batch(void __user *udata)
> > 
> > 	up_write(&mm->mmap_sem);
> > 
> > -	if (state.err > 0) {
> > -		state.user = m.arr;
> > +	if (state.err) {
> > +		state.err = 0;
> > +		state.user_mfn = (xen_pfn_t *)m.arr;
> > +		state.user_err = m.err;
> > 		ret = traverse_pages(m.num, sizeof(xen_pfn_t),
> > -			       &pagelist,
> > -			       mmap_return_errors, &state);
> > -	}
> > +				     &pagelist,
> > +				     mmap_return_errors, &state);
> > +		if (ret >= 0)
> > +			ret = state.err;
> > +	} else if (m.err)
> > +		__clear_user(m.err, m.num * sizeof(*m.err));
> > 
> > out:
> > 	free_page_list(&pagelist);
> > @@ -354,7 +411,11 @@ static long privcmd_ioctl(struct file *file,
> > 		break;
> > 
> > 	case IOCTL_PRIVCMD_MMAPBATCH:
> > -		ret = privcmd_ioctl_mmap_batch(udata);
> > +		ret = privcmd_ioctl_mmap_batch(udata, 1);
> > +		break;
> > +
> > +	case IOCTL_PRIVCMD_MMAPBATCH_V2:
> > +		ret = privcmd_ioctl_mmap_batch(udata, 2);
> > 		break;
> > 
> > 	default:
> > diff --git a/include/xen/privcmd.h b/include/xen/privcmd.h
> > index 17857fb..f60d75c 100644
> > --- a/include/xen/privcmd.h
> > +++ b/include/xen/privcmd.h
> > @@ -59,13 +59,32 @@ struct privcmd_mmapbatch {
> > 	int num;     /* number of pages to populate */
> > 	domid_t dom; /* target domain */
> > 	__u64 addr;  /* virtual address */
> > -	xen_pfn_t __user *arr; /* array of mfns - top nibble set on err */
> > +	xen_pfn_t __user *arr; /* array of mfns - or'd with
> > +				  PRIVCMD_MMAPBATCH_MFN_ERROR on err */
> > +};
> > +
> > +#define PRIVCMD_MMAPBATCH_MFN_ERROR 0xf0000000U
> > +
> > +struct privcmd_mmapbatch_v2 {
> > +	unsigned int num; /* number of pages to populate */
> > +	domid_t dom;      /* target domain */
> > +	__u64 addr;       /* virtual address */
> > +	const xen_pfn_t __user *arr; /* array of mfns */
> > +	int __user *err;  /* array of error codes */
> > };
> > 
> > /*
> >  * @cmd: IOCTL_PRIVCMD_HYPERCALL
> >  * @arg: &privcmd_hypercall_t
> >  * Return: Value returned from execution of the specified hypercall.
> > + *
> > + * @cmd: IOCTL_PRIVCMD_MMAPBATCH_V2
> > + * @arg: &struct privcmd_mmapbatch_v2
> > + * Return: 0 on success (i.e., arg->err contains valid error codes for
> > + * each frame).  On an error other than a failed frame remap, -1 is
> > + * returned and errno is set to EINVAL, EFAULT etc.  As an exception,
> > + * if the operation was otherwise successful but any frame failed with
> > + * -ENOENT, then -1 is returned and errno is set to ENOENT.
> >  */
> > #define IOCTL_PRIVCMD_HYPERCALL					\
> > 	_IOC(_IOC_NONE, 'P', 0, sizeof(struct privcmd_hypercall))
> > @@ -73,5 +92,7 @@ struct privcmd_mmapbatch {
> > 	_IOC(_IOC_NONE, 'P', 2, sizeof(struct privcmd_mmap))
> > #define IOCTL_PRIVCMD_MMAPBATCH					\
> > 	_IOC(_IOC_NONE, 'P', 3, sizeof(struct privcmd_mmapbatch))
> > +#define IOCTL_PRIVCMD_MMAPBATCH_V2				\
> > +	_IOC(_IOC_NONE, 'P', 4, sizeof(struct privcmd_mmapbatch_v2))
> > 
> > #endif /* __LINUX_PUBLIC_PRIVCMD_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 Wed Sep 05 16:36:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Sep 2012 16: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 1T9IaY-0005Yw-H3; Wed, 05 Sep 2012 16:36:26 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <thanos.makatos@citrix.com>) id 1T9IaW-0005Yd-69
	for xen-devel@lists.xensource.com; Wed, 05 Sep 2012 16:36:24 +0000
X-Env-Sender: thanos.makatos@citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1346862977!9693703!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTE5ODY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9084 invoked from network); 5 Sep 2012 16:36:17 -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;
	5 Sep 2012 16:36:17 -0000
X-IronPort-AV: E=Sophos;i="4.80,375,1344211200"; d="scan'208";a="14364620"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Sep 2012 16:36:11 +0000
Received: from [127.0.1.1] (10.80.3.216) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Wed, 5 Sep 2012
	17:36:11 +0100
MIME-Version: 1.0
X-Mercurial-Node: f32959a0c14799617f7f9817ec16da7dab4a64b4
Message-ID: <f32959a0c14799617f7f.1346862971@makatos-desktop>
User-Agent: Mercurial-patchbomb/2.0.2
Date: Wed, 5 Sep 2012 17:36:11 +0100
From: Thanos Makatos <thanos.makatos@citrix.com>
To: <xen-devel@lists.xensource.com>
Cc: thanos.makatos@citrix.com
Subject: [Xen-devel] [PATCH] use spaces instead of tabs in vim
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Tell vim to use spaces instead of tabs for all files residing under
xen-unstable.hg. Must open files from the top-level directory, otherwise it
doesn't work.

Signed-off-by: Thanos Makatos <thanos.makatos@citrix.com>

diff -r 9dc729b75595 -r f32959a0c147 .vimrc
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/.vimrc	Wed Sep 05 17:29:54 2012 +0100
@@ -0,0 +1,8 @@
+" Makes vim use spaces instead of tabs for all files under xen-unstable.hg.
+" Caveat: files must be opened from the top-level directory for it to work.
+" Must set the following in your ~/.vimrc:
+" set exrc
+" set secure
+set tabstop=4
+set shiftwidth=4
+set expandtab 

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

From xen-devel-bounces@lists.xen.org Wed Sep 05 16:36:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Sep 2012 16: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 1T9IaY-0005Yw-H3; Wed, 05 Sep 2012 16:36:26 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <thanos.makatos@citrix.com>) id 1T9IaW-0005Yd-69
	for xen-devel@lists.xensource.com; Wed, 05 Sep 2012 16:36:24 +0000
X-Env-Sender: thanos.makatos@citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1346862977!9693703!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTE5ODY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9084 invoked from network); 5 Sep 2012 16:36:17 -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;
	5 Sep 2012 16:36:17 -0000
X-IronPort-AV: E=Sophos;i="4.80,375,1344211200"; d="scan'208";a="14364620"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Sep 2012 16:36:11 +0000
Received: from [127.0.1.1] (10.80.3.216) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Wed, 5 Sep 2012
	17:36:11 +0100
MIME-Version: 1.0
X-Mercurial-Node: f32959a0c14799617f7f9817ec16da7dab4a64b4
Message-ID: <f32959a0c14799617f7f.1346862971@makatos-desktop>
User-Agent: Mercurial-patchbomb/2.0.2
Date: Wed, 5 Sep 2012 17:36:11 +0100
From: Thanos Makatos <thanos.makatos@citrix.com>
To: <xen-devel@lists.xensource.com>
Cc: thanos.makatos@citrix.com
Subject: [Xen-devel] [PATCH] use spaces instead of tabs in vim
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Tell vim to use spaces instead of tabs for all files residing under
xen-unstable.hg. Must open files from the top-level directory, otherwise it
doesn't work.

Signed-off-by: Thanos Makatos <thanos.makatos@citrix.com>

diff -r 9dc729b75595 -r f32959a0c147 .vimrc
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/.vimrc	Wed Sep 05 17:29:54 2012 +0100
@@ -0,0 +1,8 @@
+" Makes vim use spaces instead of tabs for all files under xen-unstable.hg.
+" Caveat: files must be opened from the top-level directory for it to work.
+" Must set the following in your ~/.vimrc:
+" set exrc
+" set secure
+set tabstop=4
+set shiftwidth=4
+set expandtab 

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

From xen-devel-bounces@lists.xen.org Wed Sep 05 16:38:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Sep 2012 16: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 1T9Ic0-0005gi-LJ; Wed, 05 Sep 2012 16:37:56 +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 1T9Ibz-0005gU-AX
	for xen-devel@lists.xen.org; Wed, 05 Sep 2012 16:37:55 +0000
Received: from [85.158.143.35:54779] by server-2.bemta-4.messagelabs.com id
	90/52-21239-2EF77405; Wed, 05 Sep 2012 16:37:54 +0000
X-Env-Sender: dan.magenheimer@oracle.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1346863072!5892675!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzI4NDYw\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20570 invoked from network); 5 Sep 2012 16:37:54 -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; 5 Sep 2012 16:37:54 -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 q85GbpaK032562
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 5 Sep 2012 16:37:52 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
	q85GbpiD019055
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 5 Sep 2012 16:37:51 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
	q85Gbpxf008799; Wed, 5 Sep 2012 11:37:51 -0500
MIME-Version: 1.0
Message-ID: <ece4f196-e34e-47f5-869f-9994503e4c18@default>
Date: Wed, 5 Sep 2012 09:37:08 -0700 (PDT)
From: Dan Magenheimer <dan.magenheimer@oracle.com>
To: Jan Beulich <JBeulich@suse.com>, xen-devel <xen-devel@lists.xen.org>
References: <504762B50200007800098D92@nat28.tlf.novell.com>
In-Reply-To: <504762B50200007800098D92@nat28.tlf.novell.com>
X-Priority: 3
X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.7  (607090) [OL
	12.0.6661.5003 (x86)]
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: Kurt Hackel <kurt.hackel@oracle.com>,
	Zhenzhong Duan <zhenzhong.duan@oracle.com>,
	Konrad Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH 00/11] various tmem adjustments (mostly
	XSA-15 related)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> From: Jan Beulich [mailto:JBeulich@suse.com]
> Sent: Wednesday, September 05, 2012 6:33 AM
> To: xen-devel
> Cc: Dan Magenheimer; Zhenzhong Duan
> Subject: [PATCH 00/11] various tmem adjustments (mostly XSA-15 related)
> 
> 01: tmem: only allow tmem control operations from privileged domains
> 02: tmem: consistently make pool_id a uint32_t
> 03: tmem: check the pool_id is valid when destroying a tmem pool
> 04: tmem: check for a valid client ("domain") in the save subops
> 05: tmem: don't access guest memory without using the accessors intended for this
> 06: tmem: detect arithmetic overflow in tmh_copy_{from,to}_client()
> 07: tmem: properly drop lock on error path in do_tmem_get()
> 08: tmem: properly drop lock on error path in do_tmem_op()
> 09: tmem: reduce severity of log messages
> 10: tmem: fixup 2010 cleanup patch that breaks tmem save/restore
> 11: tmem: cleanup

Thanks Jan and Ian for providing these patches!

Summary: All not already acked by me will be acked by me individually
shortly (with original cc list).  Some comments on PATCH 5/11 but still acked.

Keir or Jan (or whoever is applying the patches), a heads-up would
be appreciated to me and this cc list when this patchset is applied
to -staging or any other Xen tree.

Thanks,
Dan


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

From xen-devel-bounces@lists.xen.org Wed Sep 05 16:38:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Sep 2012 16: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 1T9Ic0-0005gi-LJ; Wed, 05 Sep 2012 16:37:56 +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 1T9Ibz-0005gU-AX
	for xen-devel@lists.xen.org; Wed, 05 Sep 2012 16:37:55 +0000
Received: from [85.158.143.35:54779] by server-2.bemta-4.messagelabs.com id
	90/52-21239-2EF77405; Wed, 05 Sep 2012 16:37:54 +0000
X-Env-Sender: dan.magenheimer@oracle.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1346863072!5892675!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzI4NDYw\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20570 invoked from network); 5 Sep 2012 16:37:54 -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; 5 Sep 2012 16:37:54 -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 q85GbpaK032562
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 5 Sep 2012 16:37:52 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
	q85GbpiD019055
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 5 Sep 2012 16:37:51 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
	q85Gbpxf008799; Wed, 5 Sep 2012 11:37:51 -0500
MIME-Version: 1.0
Message-ID: <ece4f196-e34e-47f5-869f-9994503e4c18@default>
Date: Wed, 5 Sep 2012 09:37:08 -0700 (PDT)
From: Dan Magenheimer <dan.magenheimer@oracle.com>
To: Jan Beulich <JBeulich@suse.com>, xen-devel <xen-devel@lists.xen.org>
References: <504762B50200007800098D92@nat28.tlf.novell.com>
In-Reply-To: <504762B50200007800098D92@nat28.tlf.novell.com>
X-Priority: 3
X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.7  (607090) [OL
	12.0.6661.5003 (x86)]
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: Kurt Hackel <kurt.hackel@oracle.com>,
	Zhenzhong Duan <zhenzhong.duan@oracle.com>,
	Konrad Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH 00/11] various tmem adjustments (mostly
	XSA-15 related)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> From: Jan Beulich [mailto:JBeulich@suse.com]
> Sent: Wednesday, September 05, 2012 6:33 AM
> To: xen-devel
> Cc: Dan Magenheimer; Zhenzhong Duan
> Subject: [PATCH 00/11] various tmem adjustments (mostly XSA-15 related)
> 
> 01: tmem: only allow tmem control operations from privileged domains
> 02: tmem: consistently make pool_id a uint32_t
> 03: tmem: check the pool_id is valid when destroying a tmem pool
> 04: tmem: check for a valid client ("domain") in the save subops
> 05: tmem: don't access guest memory without using the accessors intended for this
> 06: tmem: detect arithmetic overflow in tmh_copy_{from,to}_client()
> 07: tmem: properly drop lock on error path in do_tmem_get()
> 08: tmem: properly drop lock on error path in do_tmem_op()
> 09: tmem: reduce severity of log messages
> 10: tmem: fixup 2010 cleanup patch that breaks tmem save/restore
> 11: tmem: cleanup

Thanks Jan and Ian for providing these patches!

Summary: All not already acked by me will be acked by me individually
shortly (with original cc list).  Some comments on PATCH 5/11 but still acked.

Keir or Jan (or whoever is applying the patches), a heads-up would
be appreciated to me and this cc list when this patchset is applied
to -staging or any other Xen tree.

Thanks,
Dan


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

From xen-devel-bounces@lists.xen.org Wed Sep 05 16:38:29 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Sep 2012 16: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 1T9IcL-0005l9-2A; Wed, 05 Sep 2012 16:38:17 +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 1T9IcK-0005jc-81
	for xen-devel@lists.xen.org; Wed, 05 Sep 2012 16:38:16 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1346863088!4129793!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDczODkxOA==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16586 invoked from network); 5 Sep 2012 16:38:10 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-6.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 5 Sep 2012 16:38:10 -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 q85Gc251022284
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 5 Sep 2012 16:38:04 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q85Gc1cU020973
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 5 Sep 2012 16:38:01 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
	q85Gc13d004674; Wed, 5 Sep 2012 11:38:01 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 05 Sep 2012 09:38:01 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 5EF8E402C1; Wed,  5 Sep 2012 12:27:31 -0400 (EDT)
Date: Wed, 5 Sep 2012 12:27:31 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: David Vrabel <david.vrabel@citrix.com>
Message-ID: <20120905162731.GD11949@phenom.dumpdata.com>
References: <1346086287-17674-1-git-send-email-andres@lagarcavilla.org>
	<5040CAEA.7000600@citrix.com>
	<160CC375-2682-4CBF-B1EC-06A9F3E49A40@gridcentric.ca>
	<A976B10C-58BE-4660-89E9-A8F85CAB5F19@gmail.com>
	<5040E210.2060702@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <5040E210.2060702@citrix.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: Andres Lagar-Cavilla <andreslc@gridcentric.ca>,
	Andres Lagar-Cavilla <andres.lagarcavilla@gmail.com>,
	"andres@lagarcavilla.org" <andres@lagarcavilla.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] Xen backend support for paged out grant
 targets.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Aug 31, 2012 at 05:10:56PM +0100, David Vrabel wrote:
> On 31/08/12 16:42, Andres Lagar-Cavilla wrote:
> > Actually acted upon your feedback ipso facto:
> > 
> > commit d5fab912caa1f0cf6be0a6773f502d3417a207b6
> > Author: Andres Lagar-Cavilla <andres@lagarcavilla.org>
> > Date:   Sun Aug 26 09:45:57 2012 -0400
> > 
> >     Xen backend support for paged out grant targets.
> 
> This looks mostly fine expect for the #define instead of inline functions.
> 
> > +#define gnttab_map_grant_no_eagain(_gop)                                    \
> 
> This name tripped me up previously. As I read this as:
> 
> gnttab_map_grant_no_[retries_for]_eagain().
> 
> Perhaps gnttab_map_grant_with_retries() ? Or similar?

gnttab_map_grant_retry ?

Besides that, it looks good to me. Ian Campbell needs to Ack so that
David Miller (the network maintainer) can pick it up. Please CC them
both and also LKML.
> 
> David

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

From xen-devel-bounces@lists.xen.org Wed Sep 05 16:38:29 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Sep 2012 16: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 1T9IcL-0005l9-2A; Wed, 05 Sep 2012 16:38:17 +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 1T9IcK-0005jc-81
	for xen-devel@lists.xen.org; Wed, 05 Sep 2012 16:38:16 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1346863088!4129793!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDczODkxOA==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16586 invoked from network); 5 Sep 2012 16:38:10 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-6.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 5 Sep 2012 16:38:10 -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 q85Gc251022284
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 5 Sep 2012 16:38:04 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q85Gc1cU020973
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 5 Sep 2012 16:38:01 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
	q85Gc13d004674; Wed, 5 Sep 2012 11:38:01 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 05 Sep 2012 09:38:01 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 5EF8E402C1; Wed,  5 Sep 2012 12:27:31 -0400 (EDT)
Date: Wed, 5 Sep 2012 12:27:31 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: David Vrabel <david.vrabel@citrix.com>
Message-ID: <20120905162731.GD11949@phenom.dumpdata.com>
References: <1346086287-17674-1-git-send-email-andres@lagarcavilla.org>
	<5040CAEA.7000600@citrix.com>
	<160CC375-2682-4CBF-B1EC-06A9F3E49A40@gridcentric.ca>
	<A976B10C-58BE-4660-89E9-A8F85CAB5F19@gmail.com>
	<5040E210.2060702@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <5040E210.2060702@citrix.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: Andres Lagar-Cavilla <andreslc@gridcentric.ca>,
	Andres Lagar-Cavilla <andres.lagarcavilla@gmail.com>,
	"andres@lagarcavilla.org" <andres@lagarcavilla.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] Xen backend support for paged out grant
 targets.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Aug 31, 2012 at 05:10:56PM +0100, David Vrabel wrote:
> On 31/08/12 16:42, Andres Lagar-Cavilla wrote:
> > Actually acted upon your feedback ipso facto:
> > 
> > commit d5fab912caa1f0cf6be0a6773f502d3417a207b6
> > Author: Andres Lagar-Cavilla <andres@lagarcavilla.org>
> > Date:   Sun Aug 26 09:45:57 2012 -0400
> > 
> >     Xen backend support for paged out grant targets.
> 
> This looks mostly fine expect for the #define instead of inline functions.
> 
> > +#define gnttab_map_grant_no_eagain(_gop)                                    \
> 
> This name tripped me up previously. As I read this as:
> 
> gnttab_map_grant_no_[retries_for]_eagain().
> 
> Perhaps gnttab_map_grant_with_retries() ? Or similar?

gnttab_map_grant_retry ?

Besides that, it looks good to me. Ian Campbell needs to Ack so that
David Miller (the network maintainer) can pick it up. Please CC them
both and also LKML.
> 
> David

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

From xen-devel-bounces@lists.xen.org Wed Sep 05 16:38:49 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Sep 2012 16:38:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9Icb-0005oe-FV; Wed, 05 Sep 2012 16:38:33 +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 1T9Ica-0005oG-4z
	for xen-devel@lists.xen.org; Wed, 05 Sep 2012 16:38:32 +0000
Received: from [85.158.143.35:58275] by server-2.bemta-4.messagelabs.com id
	E3/23-21239-70087405; Wed, 05 Sep 2012 16:38:31 +0000
X-Env-Sender: dan.magenheimer@oracle.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1346863109!13460337!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDczODkxOA==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3531 invoked from network); 5 Sep 2012 16:38:30 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-3.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 5 Sep 2012 16:38:30 -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 q85GcRe5022687
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 5 Sep 2012 16:38:28 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
	q85GcQxG023943
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 5 Sep 2012 16:38: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
	q85GcQ23005366; Wed, 5 Sep 2012 11:38:26 -0500
MIME-Version: 1.0
Message-ID: <58f71e31-7634-47f0-9bbc-43e3d72de94d@default>
Date: Wed, 5 Sep 2012 09:37:44 -0700 (PDT)
From: Dan Magenheimer <dan.magenheimer@oracle.com>
To: Jan Beulich <JBeulich@suse.com>, xen-devel <xen-devel@lists.xen.org>
References: <504762D80200007800098D95@nat28.tlf.novell.com>
In-Reply-To: <504762D80200007800098D95@nat28.tlf.novell.com>
X-Priority: 3
X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.7  (607090) [OL
	12.0.6661.5003 (x86)]
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: Zhenzhong Duan <zhenzhong.duan@oracle.com>
Subject: Re: [Xen-devel] [PATCH 01/11] tmem: only allow tmem control
 operations from privileged 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

> From: Jan Beulich [mailto:JBeulich@suse.com]
> Sent: Wednesday, September 05, 2012 6:34 AM
> To: xen-devel
> Cc: Dan Magenheimer; Zhenzhong Duan
> Subject: [PATCH 01/11] tmem: only allow tmem control operations from privileged domains
> 
> This is part of XSA-15 / CVE-2012-3497.
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> Acked-by: Jan Beulich <jbeulich@suse.com>

Acked-by: Dan Magenheimer <dan.magenheimer@oracle.com>
 
> --- a/xen/common/tmem.c
> +++ b/xen/common/tmem.c
> @@ -2541,10 +2541,8 @@ static NOINLINE int do_tmem_control(stru
>      OID *oidp = (OID *)(&op->u.ctrl.oid[0]);
> 
>      if (!tmh_current_is_privileged())
> -    {
> -        /* don't fail... mystery: sometimes dom0 fails here */
> -        /* return -EPERM; */
> -    }
> +        return -EPERM;
> +
>      switch(subop)
>      {
>      case TMEMC_THAW:
> 
> 
> 

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

From xen-devel-bounces@lists.xen.org Wed Sep 05 16:38:49 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Sep 2012 16:38:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9Icb-0005oe-FV; Wed, 05 Sep 2012 16:38:33 +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 1T9Ica-0005oG-4z
	for xen-devel@lists.xen.org; Wed, 05 Sep 2012 16:38:32 +0000
Received: from [85.158.143.35:58275] by server-2.bemta-4.messagelabs.com id
	E3/23-21239-70087405; Wed, 05 Sep 2012 16:38:31 +0000
X-Env-Sender: dan.magenheimer@oracle.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1346863109!13460337!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDczODkxOA==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3531 invoked from network); 5 Sep 2012 16:38:30 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-3.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 5 Sep 2012 16:38:30 -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 q85GcRe5022687
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 5 Sep 2012 16:38:28 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
	q85GcQxG023943
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 5 Sep 2012 16:38: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
	q85GcQ23005366; Wed, 5 Sep 2012 11:38:26 -0500
MIME-Version: 1.0
Message-ID: <58f71e31-7634-47f0-9bbc-43e3d72de94d@default>
Date: Wed, 5 Sep 2012 09:37:44 -0700 (PDT)
From: Dan Magenheimer <dan.magenheimer@oracle.com>
To: Jan Beulich <JBeulich@suse.com>, xen-devel <xen-devel@lists.xen.org>
References: <504762D80200007800098D95@nat28.tlf.novell.com>
In-Reply-To: <504762D80200007800098D95@nat28.tlf.novell.com>
X-Priority: 3
X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.7  (607090) [OL
	12.0.6661.5003 (x86)]
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: Zhenzhong Duan <zhenzhong.duan@oracle.com>
Subject: Re: [Xen-devel] [PATCH 01/11] tmem: only allow tmem control
 operations from privileged 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

> From: Jan Beulich [mailto:JBeulich@suse.com]
> Sent: Wednesday, September 05, 2012 6:34 AM
> To: xen-devel
> Cc: Dan Magenheimer; Zhenzhong Duan
> Subject: [PATCH 01/11] tmem: only allow tmem control operations from privileged domains
> 
> This is part of XSA-15 / CVE-2012-3497.
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> Acked-by: Jan Beulich <jbeulich@suse.com>

Acked-by: Dan Magenheimer <dan.magenheimer@oracle.com>
 
> --- a/xen/common/tmem.c
> +++ b/xen/common/tmem.c
> @@ -2541,10 +2541,8 @@ static NOINLINE int do_tmem_control(stru
>      OID *oidp = (OID *)(&op->u.ctrl.oid[0]);
> 
>      if (!tmh_current_is_privileged())
> -    {
> -        /* don't fail... mystery: sometimes dom0 fails here */
> -        /* return -EPERM; */
> -    }
> +        return -EPERM;
> +
>      switch(subop)
>      {
>      case TMEMC_THAW:
> 
> 
> 

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

From xen-devel-bounces@lists.xen.org Wed Sep 05 16:39:10 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Sep 2012 16: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 1T9Id0-0005v6-Sx; Wed, 05 Sep 2012 16:38:59 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dan.magenheimer@oracle.com>) id 1T9Icz-0005uT-6O
	for xen-devel@lists.xen.org; Wed, 05 Sep 2012 16:38:57 +0000
Received: from [85.158.138.51:59107] by server-11.bemta-3.messagelabs.com id
	FE/6B-30250-02087405; Wed, 05 Sep 2012 16:38:56 +0000
X-Env-Sender: dan.magenheimer@oracle.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1346863133!28754954!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDczODkxOA==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23904 invoked from network); 5 Sep 2012 16:38:55 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-16.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 5 Sep 2012 16:38:55 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q85GcpQR023003
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 5 Sep 2012 16:38: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
	q85GcoQD002620
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 5 Sep 2012 16:38: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
	q85GcoXk005177; Wed, 5 Sep 2012 11:38:50 -0500
MIME-Version: 1.0
Message-ID: <13d73bcf-4b61-42b7-87f4-66303e6c4d99@default>
Date: Wed, 5 Sep 2012 09:38:08 -0700 (PDT)
From: Dan Magenheimer <dan.magenheimer@oracle.com>
To: Jan Beulich <JBeulich@suse.com>, xen-devel <xen-devel@lists.xen.org>
References: <504762F60200007800098D99@nat28.tlf.novell.com>
In-Reply-To: <504762F60200007800098D99@nat28.tlf.novell.com>
X-Priority: 3
X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.7  (607090) [OL
	12.0.6661.5003 (x86)]
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: Zhenzhong Duan <zhenzhong.duan@oracle.com>
Subject: Re: [Xen-devel] [PATCH 02/11] tmem: consistently make pool_id a
	uint32_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

> From: Jan Beulich [mailto:JBeulich@suse.com]
> Sent: Wednesday, September 05, 2012 6:35 AM
> To: xen-devel
> Cc: Dan Magenheimer; Zhenzhong Duan
> Subject: [PATCH 02/11] tmem: consistently make pool_id a uint32_t
> 
> Treating it as an int could allow a malicious guest to provide a
> negative pool_Id, by passing the MAX_POOLS_PER_DOMAIN limit check and
> allowing access to the negative offsets of the pool array.
> 
> This is part of XSA-15 / CVE-2012-3497.
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> Acked-by: Jan Beulich <jbeulich@suse.com>

Acked-by: Dan Magenheimer <dan.magenheimer@oracle.com>

 
> --- a/xen/common/tmem.c
> +++ b/xen/common/tmem.c
> @@ -2417,7 +2417,7 @@ static NOINLINE int tmemc_save_subop(int
>      return rc;
>  }
> 
> -static NOINLINE int tmemc_save_get_next_page(int cli_id, int pool_id,
> +static NOINLINE int tmemc_save_get_next_page(int cli_id, uint32_t pool_id,
>                          tmem_cli_va_t buf, uint32_t bufsize)
>  {
>      client_t *client = tmh_client_from_cli_id(cli_id);
> @@ -2509,7 +2509,7 @@ out:
>      return ret;
>  }
> 
> -static int tmemc_restore_put_page(int cli_id, int pool_id, OID *oidp,
> +static int tmemc_restore_put_page(int cli_id, uint32_t pool_id, OID *oidp,
>                        uint32_t index, tmem_cli_va_t buf, uint32_t bufsize)
>  {
>      client_t *client = tmh_client_from_cli_id(cli_id);
> @@ -2521,7 +2521,7 @@ static int tmemc_restore_put_page(int cl
>      return do_tmem_put(pool,oidp,index,0,0,0,bufsize,buf.p);
>  }
> 
> -static int tmemc_restore_flush_page(int cli_id, int pool_id, OID *oidp,
> +static int tmemc_restore_flush_page(int cli_id, uint32_t pool_id, OID *oidp,
>                          uint32_t index)
>  {
>      client_t *client = tmh_client_from_cli_id(cli_id);
> 
> 
> 

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

From xen-devel-bounces@lists.xen.org Wed Sep 05 16:39:10 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Sep 2012 16: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 1T9Id0-0005v6-Sx; Wed, 05 Sep 2012 16:38:59 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dan.magenheimer@oracle.com>) id 1T9Icz-0005uT-6O
	for xen-devel@lists.xen.org; Wed, 05 Sep 2012 16:38:57 +0000
Received: from [85.158.138.51:59107] by server-11.bemta-3.messagelabs.com id
	FE/6B-30250-02087405; Wed, 05 Sep 2012 16:38:56 +0000
X-Env-Sender: dan.magenheimer@oracle.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1346863133!28754954!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDczODkxOA==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23904 invoked from network); 5 Sep 2012 16:38:55 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-16.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 5 Sep 2012 16:38:55 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q85GcpQR023003
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 5 Sep 2012 16:38: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
	q85GcoQD002620
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 5 Sep 2012 16:38: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
	q85GcoXk005177; Wed, 5 Sep 2012 11:38:50 -0500
MIME-Version: 1.0
Message-ID: <13d73bcf-4b61-42b7-87f4-66303e6c4d99@default>
Date: Wed, 5 Sep 2012 09:38:08 -0700 (PDT)
From: Dan Magenheimer <dan.magenheimer@oracle.com>
To: Jan Beulich <JBeulich@suse.com>, xen-devel <xen-devel@lists.xen.org>
References: <504762F60200007800098D99@nat28.tlf.novell.com>
In-Reply-To: <504762F60200007800098D99@nat28.tlf.novell.com>
X-Priority: 3
X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.7  (607090) [OL
	12.0.6661.5003 (x86)]
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: Zhenzhong Duan <zhenzhong.duan@oracle.com>
Subject: Re: [Xen-devel] [PATCH 02/11] tmem: consistently make pool_id a
	uint32_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

> From: Jan Beulich [mailto:JBeulich@suse.com]
> Sent: Wednesday, September 05, 2012 6:35 AM
> To: xen-devel
> Cc: Dan Magenheimer; Zhenzhong Duan
> Subject: [PATCH 02/11] tmem: consistently make pool_id a uint32_t
> 
> Treating it as an int could allow a malicious guest to provide a
> negative pool_Id, by passing the MAX_POOLS_PER_DOMAIN limit check and
> allowing access to the negative offsets of the pool array.
> 
> This is part of XSA-15 / CVE-2012-3497.
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> Acked-by: Jan Beulich <jbeulich@suse.com>

Acked-by: Dan Magenheimer <dan.magenheimer@oracle.com>

 
> --- a/xen/common/tmem.c
> +++ b/xen/common/tmem.c
> @@ -2417,7 +2417,7 @@ static NOINLINE int tmemc_save_subop(int
>      return rc;
>  }
> 
> -static NOINLINE int tmemc_save_get_next_page(int cli_id, int pool_id,
> +static NOINLINE int tmemc_save_get_next_page(int cli_id, uint32_t pool_id,
>                          tmem_cli_va_t buf, uint32_t bufsize)
>  {
>      client_t *client = tmh_client_from_cli_id(cli_id);
> @@ -2509,7 +2509,7 @@ out:
>      return ret;
>  }
> 
> -static int tmemc_restore_put_page(int cli_id, int pool_id, OID *oidp,
> +static int tmemc_restore_put_page(int cli_id, uint32_t pool_id, OID *oidp,
>                        uint32_t index, tmem_cli_va_t buf, uint32_t bufsize)
>  {
>      client_t *client = tmh_client_from_cli_id(cli_id);
> @@ -2521,7 +2521,7 @@ static int tmemc_restore_put_page(int cl
>      return do_tmem_put(pool,oidp,index,0,0,0,bufsize,buf.p);
>  }
> 
> -static int tmemc_restore_flush_page(int cli_id, int pool_id, OID *oidp,
> +static int tmemc_restore_flush_page(int cli_id, uint32_t pool_id, OID *oidp,
>                          uint32_t index)
>  {
>      client_t *client = tmh_client_from_cli_id(cli_id);
> 
> 
> 

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

From xen-devel-bounces@lists.xen.org Wed Sep 05 16:39:44 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Sep 2012 16: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 1T9IdX-00064g-Iv; Wed, 05 Sep 2012 16:39:31 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dan.magenheimer@oracle.com>) id 1T9IdW-00064U-VJ
	for xen-devel@lists.xen.org; Wed, 05 Sep 2012 16:39:31 +0000
Received: from [85.158.138.51:63582] by server-8.bemta-3.messagelabs.com id
	DB/61-24700-24087405; Wed, 05 Sep 2012 16:39:30 +0000
X-Env-Sender: dan.magenheimer@oracle.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1346863168!24801588!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzI4NDYw\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7762 invoked from network); 5 Sep 2012 16:39:29 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-10.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 5 Sep 2012 16:39:29 -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 q85GdRjQ001821
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 5 Sep 2012 16:39:27 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
	q85GdQ02025794
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 5 Sep 2012 16:39:26 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
	q85GdP8u006057; Wed, 5 Sep 2012 11:39:26 -0500
MIME-Version: 1.0
Message-ID: <eb070831-137e-4021-9bde-ffbf6ce07558@default>
Date: Wed, 5 Sep 2012 09:38:43 -0700 (PDT)
From: Dan Magenheimer <dan.magenheimer@oracle.com>
To: Jan Beulich <JBeulich@suse.com>, xen-devel <xen-devel@lists.xen.org>
References: <504763140200007800098D9D@nat28.tlf.novell.com>
In-Reply-To: <504763140200007800098D9D@nat28.tlf.novell.com>
X-Priority: 3
X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.7  (607090) [OL
	12.0.6661.5003 (x86)]
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: Zhenzhong Duan <zhenzhong.duan@oracle.com>
Subject: Re: [Xen-devel] [PATCH 03/11] tmem: check the pool_id is valid when
 destroying a tmem pool
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> From: Jan Beulich [mailto:JBeulich@suse.com]
> Sent: Wednesday, September 05, 2012 6:35 AM
> To: xen-devel
> Cc: Dan Magenheimer; Zhenzhong Duan
> Subject: [PATCH 03/11] tmem: check the pool_id is valid when destroying a tmem pool
> 
> This is part of XSA-15 / CVE-2012-3497.
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> Acked-by: Jan Beulich <jbeulich@suse.com>

Acked-by: Dan Magenheimer <dan.magenheimer@oracle.com>

> --- a/xen/common/tmem.c
> +++ b/xen/common/tmem.c
> @@ -1870,6 +1870,8 @@ static NOINLINE int do_tmem_destroy_pool
> 
>      if ( client->pools == NULL )
>          return 0;
> +    if ( pool_id >= MAX_POOLS_PER_DOMAIN )
> +        return 0;
>      if ( (pool = client->pools[pool_id]) == NULL )
>          return 0;
>      client->pools[pool_id] = NULL;
> 
> 
> 

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

From xen-devel-bounces@lists.xen.org Wed Sep 05 16:39:44 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Sep 2012 16: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 1T9IdX-00064g-Iv; Wed, 05 Sep 2012 16:39:31 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dan.magenheimer@oracle.com>) id 1T9IdW-00064U-VJ
	for xen-devel@lists.xen.org; Wed, 05 Sep 2012 16:39:31 +0000
Received: from [85.158.138.51:63582] by server-8.bemta-3.messagelabs.com id
	DB/61-24700-24087405; Wed, 05 Sep 2012 16:39:30 +0000
X-Env-Sender: dan.magenheimer@oracle.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1346863168!24801588!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzI4NDYw\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7762 invoked from network); 5 Sep 2012 16:39:29 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-10.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 5 Sep 2012 16:39:29 -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 q85GdRjQ001821
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 5 Sep 2012 16:39:27 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
	q85GdQ02025794
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 5 Sep 2012 16:39:26 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
	q85GdP8u006057; Wed, 5 Sep 2012 11:39:26 -0500
MIME-Version: 1.0
Message-ID: <eb070831-137e-4021-9bde-ffbf6ce07558@default>
Date: Wed, 5 Sep 2012 09:38:43 -0700 (PDT)
From: Dan Magenheimer <dan.magenheimer@oracle.com>
To: Jan Beulich <JBeulich@suse.com>, xen-devel <xen-devel@lists.xen.org>
References: <504763140200007800098D9D@nat28.tlf.novell.com>
In-Reply-To: <504763140200007800098D9D@nat28.tlf.novell.com>
X-Priority: 3
X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.7  (607090) [OL
	12.0.6661.5003 (x86)]
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: Zhenzhong Duan <zhenzhong.duan@oracle.com>
Subject: Re: [Xen-devel] [PATCH 03/11] tmem: check the pool_id is valid when
 destroying a tmem pool
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> From: Jan Beulich [mailto:JBeulich@suse.com]
> Sent: Wednesday, September 05, 2012 6:35 AM
> To: xen-devel
> Cc: Dan Magenheimer; Zhenzhong Duan
> Subject: [PATCH 03/11] tmem: check the pool_id is valid when destroying a tmem pool
> 
> This is part of XSA-15 / CVE-2012-3497.
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> Acked-by: Jan Beulich <jbeulich@suse.com>

Acked-by: Dan Magenheimer <dan.magenheimer@oracle.com>

> --- a/xen/common/tmem.c
> +++ b/xen/common/tmem.c
> @@ -1870,6 +1870,8 @@ static NOINLINE int do_tmem_destroy_pool
> 
>      if ( client->pools == NULL )
>          return 0;
> +    if ( pool_id >= MAX_POOLS_PER_DOMAIN )
> +        return 0;
>      if ( (pool = client->pools[pool_id]) == NULL )
>          return 0;
>      client->pools[pool_id] = NULL;
> 
> 
> 

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

From xen-devel-bounces@lists.xen.org Wed Sep 05 16:40:01 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Sep 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 1T9Idt-0006Ak-0Q; Wed, 05 Sep 2012 16:39:53 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dan.magenheimer@oracle.com>) id 1T9Idr-0006A9-Qf
	for xen-devel@lists.xen.org; Wed, 05 Sep 2012 16:39:52 +0000
Received: from [85.158.138.51:65015] by server-9.bemta-3.messagelabs.com id
	35/A6-15390-65087405; Wed, 05 Sep 2012 16:39:50 +0000
X-Env-Sender: dan.magenheimer@oracle.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1346863188!28802008!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDczODkxOA==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15368 invoked from network); 5 Sep 2012 16:39:50 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-8.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 5 Sep 2012 16:39:50 -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 q85Gdl0f024045
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 5 Sep 2012 16:39:48 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
	q85Gdlil022207
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 5 Sep 2012 16:39:47 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
	q85GdlSh010120; Wed, 5 Sep 2012 11:39:47 -0500
MIME-Version: 1.0
Message-ID: <bc1a0f67-c2a5-41d4-ae18-be90bce48230@default>
Date: Wed, 5 Sep 2012 09:39:05 -0700 (PDT)
From: Dan Magenheimer <dan.magenheimer@oracle.com>
To: Jan Beulich <JBeulich@suse.com>, xen-devel <xen-devel@lists.xen.org>
References: <5047633A0200007800098DCD@nat28.tlf.novell.com>
In-Reply-To: <5047633A0200007800098DCD@nat28.tlf.novell.com>
X-Priority: 3
X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.7  (607090) [OL
	12.0.6661.5003 (x86)]
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: Zhenzhong Duan <zhenzhong.duan@oracle.com>
Subject: Re: [Xen-devel] [PATCH 04/11] tmem: check for a valid client
 ("domain") in the save subops
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> From: Jan Beulich [mailto:JBeulich@suse.com]
> Sent: Wednesday, September 05, 2012 6:36 AM
> To: xen-devel
> Cc: Dan Magenheimer; Zhenzhong Duan
> Subject: [PATCH 04/11] tmem: check for a valid client ("domain") in the save subops
> 
> This is part of XSA-15 / CVE-2012-3497.
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> Acked-by: Jan Beulich <jbeulich@suse.com>

Acked-by: Dan Magenheimer <dan.magenheimer@oracle.com>
 
> --- a/xen/common/tmem.c
> +++ b/xen/common/tmem.c
> @@ -2379,12 +2379,18 @@ static NOINLINE int tmemc_save_subop(int
>          rc = MAX_POOLS_PER_DOMAIN;
>          break;
>      case TMEMC_SAVE_GET_CLIENT_WEIGHT:
> +        if ( client == NULL )
> +            break;
>          rc = client->weight == -1 ? -2 : client->weight;
>          break;
>      case TMEMC_SAVE_GET_CLIENT_CAP:
> +        if ( client == NULL )
> +            break;
>          rc = client->cap == -1 ? -2 : client->cap;
>          break;
>      case TMEMC_SAVE_GET_CLIENT_FLAGS:
> +        if ( client == NULL )
> +            break;
>          rc = (client->compress ? TMEM_CLIENT_COMPRESS : 0 ) |
>               (client->was_frozen ? TMEM_CLIENT_FROZEN : 0 );
>          break;
> @@ -2408,6 +2414,8 @@ static NOINLINE int tmemc_save_subop(int
>          *uuid = pool->uuid[1];
>          rc = 0;
>      case TMEMC_SAVE_END:
> +        if ( client == NULL )
> +            break;
>          client->live_migrating = 0;
>          if ( !list_empty(&client->persistent_invalidated_list) )
>              list_for_each_entry_safe(pgp,pgp2,
> 
> 
> 

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

From xen-devel-bounces@lists.xen.org Wed Sep 05 16:40:01 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Sep 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 1T9Idt-0006Ak-0Q; Wed, 05 Sep 2012 16:39:53 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dan.magenheimer@oracle.com>) id 1T9Idr-0006A9-Qf
	for xen-devel@lists.xen.org; Wed, 05 Sep 2012 16:39:52 +0000
Received: from [85.158.138.51:65015] by server-9.bemta-3.messagelabs.com id
	35/A6-15390-65087405; Wed, 05 Sep 2012 16:39:50 +0000
X-Env-Sender: dan.magenheimer@oracle.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1346863188!28802008!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDczODkxOA==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15368 invoked from network); 5 Sep 2012 16:39:50 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-8.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 5 Sep 2012 16:39:50 -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 q85Gdl0f024045
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 5 Sep 2012 16:39:48 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
	q85Gdlil022207
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 5 Sep 2012 16:39:47 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
	q85GdlSh010120; Wed, 5 Sep 2012 11:39:47 -0500
MIME-Version: 1.0
Message-ID: <bc1a0f67-c2a5-41d4-ae18-be90bce48230@default>
Date: Wed, 5 Sep 2012 09:39:05 -0700 (PDT)
From: Dan Magenheimer <dan.magenheimer@oracle.com>
To: Jan Beulich <JBeulich@suse.com>, xen-devel <xen-devel@lists.xen.org>
References: <5047633A0200007800098DCD@nat28.tlf.novell.com>
In-Reply-To: <5047633A0200007800098DCD@nat28.tlf.novell.com>
X-Priority: 3
X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.7  (607090) [OL
	12.0.6661.5003 (x86)]
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: Zhenzhong Duan <zhenzhong.duan@oracle.com>
Subject: Re: [Xen-devel] [PATCH 04/11] tmem: check for a valid client
 ("domain") in the save subops
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> From: Jan Beulich [mailto:JBeulich@suse.com]
> Sent: Wednesday, September 05, 2012 6:36 AM
> To: xen-devel
> Cc: Dan Magenheimer; Zhenzhong Duan
> Subject: [PATCH 04/11] tmem: check for a valid client ("domain") in the save subops
> 
> This is part of XSA-15 / CVE-2012-3497.
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> Acked-by: Jan Beulich <jbeulich@suse.com>

Acked-by: Dan Magenheimer <dan.magenheimer@oracle.com>
 
> --- a/xen/common/tmem.c
> +++ b/xen/common/tmem.c
> @@ -2379,12 +2379,18 @@ static NOINLINE int tmemc_save_subop(int
>          rc = MAX_POOLS_PER_DOMAIN;
>          break;
>      case TMEMC_SAVE_GET_CLIENT_WEIGHT:
> +        if ( client == NULL )
> +            break;
>          rc = client->weight == -1 ? -2 : client->weight;
>          break;
>      case TMEMC_SAVE_GET_CLIENT_CAP:
> +        if ( client == NULL )
> +            break;
>          rc = client->cap == -1 ? -2 : client->cap;
>          break;
>      case TMEMC_SAVE_GET_CLIENT_FLAGS:
> +        if ( client == NULL )
> +            break;
>          rc = (client->compress ? TMEM_CLIENT_COMPRESS : 0 ) |
>               (client->was_frozen ? TMEM_CLIENT_FROZEN : 0 );
>          break;
> @@ -2408,6 +2414,8 @@ static NOINLINE int tmemc_save_subop(int
>          *uuid = pool->uuid[1];
>          rc = 0;
>      case TMEMC_SAVE_END:
> +        if ( client == NULL )
> +            break;
>          client->live_migrating = 0;
>          if ( !list_empty(&client->persistent_invalidated_list) )
>              list_for_each_entry_safe(pgp,pgp2,
> 
> 
> 

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

From xen-devel-bounces@lists.xen.org Wed Sep 05 16:40:42 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Sep 2012 16:40:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9IeU-0006Ld-Ek; Wed, 05 Sep 2012 16:40:30 +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 1T9IeS-0006L6-Vm
	for xen-devel@lists.xen.org; Wed, 05 Sep 2012 16:40:29 +0000
Received: from [85.158.143.99:44098] by server-3.bemta-4.messagelabs.com id
	B5/FA-08232-C7087405; Wed, 05 Sep 2012 16:40:28 +0000
X-Env-Sender: dan.magenheimer@oracle.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1346863217!17521560!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDczODkxOA==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14504 invoked from network); 5 Sep 2012 16:40:27 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-16.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 5 Sep 2012 16:40:27 -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 q85GeEMT024650
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 5 Sep 2012 16:40:15 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q85GeDuu027143
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 5 Sep 2012 16:40:14 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
	q85GeDJ6010488; Wed, 5 Sep 2012 11:40:13 -0500
MIME-Version: 1.0
Message-ID: <cdf65571-4b4e-4e0e-ab29-fd05f503fbe7@default>
Date: Wed, 5 Sep 2012 09:39:31 -0700 (PDT)
From: Dan Magenheimer <dan.magenheimer@oracle.com>
To: Jan Beulich <JBeulich@suse.com>, xen-devel <xen-devel@lists.xen.org>
References: <504764820200007800098E55@nat28.tlf.novell.com>
In-Reply-To: <504764820200007800098E55@nat28.tlf.novell.com>
X-Priority: 3
X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.7  (607090) [OL
	12.0.6661.5003 (x86)]
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: Zhenzhong Duan <zhenzhong.duan@oracle.com>
Subject: Re: [Xen-devel] [PATCH 11/11] tmem: 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

> From: Jan Beulich [mailto:JBeulich@suse.com]
> Sent: Wednesday, September 05, 2012 6:41 AM
> To: xen-devel
> Cc: Dan Magenheimer; Zhenzhong Duan
> Subject: [PATCH 11/11] tmem: cleanup
> 
> - one more case of checking for a specific rather than any error
> - drop no longer needed first parameter from cli_put_page()
> - drop a redundant cast
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Acked-by: Dan Magenheimer <dan.magenheimer@oracle.com>

> --- a/xen/common/tmem.c
> +++ b/xen/common/tmem.c
> @@ -1467,7 +1467,7 @@ static NOINLINE int do_tmem_put_compress
>          pgp_free_data(pgp, pgp->us.obj->pool);
>      START_CYC_COUNTER(compress);
>      ret = tmh_compress_from_client(cmfn, &dst, &size, clibuf);
> -    if ( (ret == -EFAULT) || (ret == 0) )
> +    if ( ret <= 0 )
>          goto out;
>      else if ( (size == 0) || (size >= tmem_subpage_maxsize()) ) {
>          ret = 0;
> --- a/xen/common/tmem_xen.c
> +++ b/xen/common/tmem_xen.c
> @@ -97,7 +97,7 @@ static inline void *cli_get_page(tmem_cl
>      return NULL;
>  }
> 
> -static inline void cli_put_page(tmem_cli_mfn_t cmfn, void *cli_va, pfp_t *cli_pfp,
> +static inline void cli_put_page(void *cli_va, pfp_t *cli_pfp,
>                                  unsigned long cli_mfn, bool_t mark_dirty)
>  {
>      ASSERT(0);
> @@ -126,20 +126,20 @@ static inline void *cli_get_page(tmem_cl
>      }
> 
>      *pcli_mfn = page_to_mfn(page);
> -    *pcli_pfp = (pfp_t *)page;
> +    *pcli_pfp = page;
>      return map_domain_page(*pcli_mfn);
>  }
> 
> -static inline void cli_put_page(tmem_cli_mfn_t cmfn, void *cli_va, pfp_t *cli_pfp,
> +static inline void cli_put_page(void *cli_va, pfp_t *cli_pfp,
>                                  unsigned long cli_mfn, bool_t mark_dirty)
>  {
>      if ( mark_dirty )
>      {
> -        put_page_and_type((struct page_info *)cli_pfp);
> +        put_page_and_type(cli_pfp);
>          paging_mark_dirty(current->domain,cli_mfn);
>      }
>      else
> -        put_page((struct page_info *)cli_pfp);
> +        put_page(cli_pfp);
>      unmap_domain_page(cli_va);
>  }
>  #endif
> @@ -188,7 +188,7 @@ EXPORT int tmh_copy_from_client(pfp_t *p
>      else if ( len )
>          rc = -EINVAL;
>      if ( cli_va )
> -        cli_put_page(cmfn, cli_va, cli_pfp, cli_mfn, 0);
> +        cli_put_page(cli_va, cli_pfp, cli_mfn, 0);
>      unmap_domain_page(tmem_va);
>      return rc;
>  }
> @@ -221,7 +221,7 @@ EXPORT int tmh_compress_from_client(tmem
>      ASSERT(ret == LZO_E_OK);
>      *out_va = dmem;
>      if ( cli_va )
> -        cli_put_page(cmfn, cli_va, cli_pfp, cli_mfn, 0);
> +        cli_put_page(cli_va, cli_pfp, cli_mfn, 0);
>      return 1;
>  }
> 
> @@ -259,7 +259,7 @@ EXPORT int tmh_copy_to_client(tmem_cli_m
>          rc = -EINVAL;
>      unmap_domain_page(tmem_va);
>      if ( cli_va )
> -        cli_put_page(cmfn, cli_va, cli_pfp, cli_mfn, 1);
> +        cli_put_page(cli_va, cli_pfp, cli_mfn, 1);
>      mb();
>      return rc;
>  }
> @@ -286,7 +286,7 @@ EXPORT int tmh_decompress_to_client(tmem
>      ASSERT(ret == LZO_E_OK);
>      ASSERT(out_len == PAGE_SIZE);
>      if ( cli_va )
> -        cli_put_page(cmfn, cli_va, cli_pfp, cli_mfn, 1);
> +        cli_put_page(cli_va, cli_pfp, cli_mfn, 1);
>      else if ( copy_to_guest(clibuf, scratch, PAGE_SIZE) )
>          return -EFAULT;
>      mb();
> @@ -310,7 +310,7 @@ EXPORT int tmh_copy_tze_to_client(tmem_c
>          memcpy((char *)cli_va,(char *)tmem_va,len);
>      if ( len < PAGE_SIZE )
>          memset((char *)cli_va+len,0,PAGE_SIZE-len);
> -    cli_put_page(cmfn, cli_va, cli_pfp, cli_mfn, 1);
> +    cli_put_page(cli_va, cli_pfp, cli_mfn, 1);
>      mb();
>      return 1;
>  }
> 
> 
> 

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

From xen-devel-bounces@lists.xen.org Wed Sep 05 16:40:42 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Sep 2012 16:40:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9IeU-0006Ld-Ek; Wed, 05 Sep 2012 16:40:30 +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 1T9IeS-0006L6-Vm
	for xen-devel@lists.xen.org; Wed, 05 Sep 2012 16:40:29 +0000
Received: from [85.158.143.99:44098] by server-3.bemta-4.messagelabs.com id
	B5/FA-08232-C7087405; Wed, 05 Sep 2012 16:40:28 +0000
X-Env-Sender: dan.magenheimer@oracle.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1346863217!17521560!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDczODkxOA==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14504 invoked from network); 5 Sep 2012 16:40:27 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-16.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 5 Sep 2012 16:40:27 -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 q85GeEMT024650
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 5 Sep 2012 16:40:15 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q85GeDuu027143
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 5 Sep 2012 16:40:14 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
	q85GeDJ6010488; Wed, 5 Sep 2012 11:40:13 -0500
MIME-Version: 1.0
Message-ID: <cdf65571-4b4e-4e0e-ab29-fd05f503fbe7@default>
Date: Wed, 5 Sep 2012 09:39:31 -0700 (PDT)
From: Dan Magenheimer <dan.magenheimer@oracle.com>
To: Jan Beulich <JBeulich@suse.com>, xen-devel <xen-devel@lists.xen.org>
References: <504764820200007800098E55@nat28.tlf.novell.com>
In-Reply-To: <504764820200007800098E55@nat28.tlf.novell.com>
X-Priority: 3
X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.7  (607090) [OL
	12.0.6661.5003 (x86)]
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: Zhenzhong Duan <zhenzhong.duan@oracle.com>
Subject: Re: [Xen-devel] [PATCH 11/11] tmem: 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

> From: Jan Beulich [mailto:JBeulich@suse.com]
> Sent: Wednesday, September 05, 2012 6:41 AM
> To: xen-devel
> Cc: Dan Magenheimer; Zhenzhong Duan
> Subject: [PATCH 11/11] tmem: cleanup
> 
> - one more case of checking for a specific rather than any error
> - drop no longer needed first parameter from cli_put_page()
> - drop a redundant cast
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Acked-by: Dan Magenheimer <dan.magenheimer@oracle.com>

> --- a/xen/common/tmem.c
> +++ b/xen/common/tmem.c
> @@ -1467,7 +1467,7 @@ static NOINLINE int do_tmem_put_compress
>          pgp_free_data(pgp, pgp->us.obj->pool);
>      START_CYC_COUNTER(compress);
>      ret = tmh_compress_from_client(cmfn, &dst, &size, clibuf);
> -    if ( (ret == -EFAULT) || (ret == 0) )
> +    if ( ret <= 0 )
>          goto out;
>      else if ( (size == 0) || (size >= tmem_subpage_maxsize()) ) {
>          ret = 0;
> --- a/xen/common/tmem_xen.c
> +++ b/xen/common/tmem_xen.c
> @@ -97,7 +97,7 @@ static inline void *cli_get_page(tmem_cl
>      return NULL;
>  }
> 
> -static inline void cli_put_page(tmem_cli_mfn_t cmfn, void *cli_va, pfp_t *cli_pfp,
> +static inline void cli_put_page(void *cli_va, pfp_t *cli_pfp,
>                                  unsigned long cli_mfn, bool_t mark_dirty)
>  {
>      ASSERT(0);
> @@ -126,20 +126,20 @@ static inline void *cli_get_page(tmem_cl
>      }
> 
>      *pcli_mfn = page_to_mfn(page);
> -    *pcli_pfp = (pfp_t *)page;
> +    *pcli_pfp = page;
>      return map_domain_page(*pcli_mfn);
>  }
> 
> -static inline void cli_put_page(tmem_cli_mfn_t cmfn, void *cli_va, pfp_t *cli_pfp,
> +static inline void cli_put_page(void *cli_va, pfp_t *cli_pfp,
>                                  unsigned long cli_mfn, bool_t mark_dirty)
>  {
>      if ( mark_dirty )
>      {
> -        put_page_and_type((struct page_info *)cli_pfp);
> +        put_page_and_type(cli_pfp);
>          paging_mark_dirty(current->domain,cli_mfn);
>      }
>      else
> -        put_page((struct page_info *)cli_pfp);
> +        put_page(cli_pfp);
>      unmap_domain_page(cli_va);
>  }
>  #endif
> @@ -188,7 +188,7 @@ EXPORT int tmh_copy_from_client(pfp_t *p
>      else if ( len )
>          rc = -EINVAL;
>      if ( cli_va )
> -        cli_put_page(cmfn, cli_va, cli_pfp, cli_mfn, 0);
> +        cli_put_page(cli_va, cli_pfp, cli_mfn, 0);
>      unmap_domain_page(tmem_va);
>      return rc;
>  }
> @@ -221,7 +221,7 @@ EXPORT int tmh_compress_from_client(tmem
>      ASSERT(ret == LZO_E_OK);
>      *out_va = dmem;
>      if ( cli_va )
> -        cli_put_page(cmfn, cli_va, cli_pfp, cli_mfn, 0);
> +        cli_put_page(cli_va, cli_pfp, cli_mfn, 0);
>      return 1;
>  }
> 
> @@ -259,7 +259,7 @@ EXPORT int tmh_copy_to_client(tmem_cli_m
>          rc = -EINVAL;
>      unmap_domain_page(tmem_va);
>      if ( cli_va )
> -        cli_put_page(cmfn, cli_va, cli_pfp, cli_mfn, 1);
> +        cli_put_page(cli_va, cli_pfp, cli_mfn, 1);
>      mb();
>      return rc;
>  }
> @@ -286,7 +286,7 @@ EXPORT int tmh_decompress_to_client(tmem
>      ASSERT(ret == LZO_E_OK);
>      ASSERT(out_len == PAGE_SIZE);
>      if ( cli_va )
> -        cli_put_page(cmfn, cli_va, cli_pfp, cli_mfn, 1);
> +        cli_put_page(cli_va, cli_pfp, cli_mfn, 1);
>      else if ( copy_to_guest(clibuf, scratch, PAGE_SIZE) )
>          return -EFAULT;
>      mb();
> @@ -310,7 +310,7 @@ EXPORT int tmh_copy_tze_to_client(tmem_c
>          memcpy((char *)cli_va,(char *)tmem_va,len);
>      if ( len < PAGE_SIZE )
>          memset((char *)cli_va+len,0,PAGE_SIZE-len);
> -    cli_put_page(cmfn, cli_va, cli_pfp, cli_mfn, 1);
> +    cli_put_page(cli_va, cli_pfp, cli_mfn, 1);
>      mb();
>      return 1;
>  }
> 
> 
> 

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

From xen-devel-bounces@lists.xen.org Wed Sep 05 16:51:37 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Sep 2012 16: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 1T9Ip3-00073u-P6; Wed, 05 Sep 2012 16:51:25 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dan.magenheimer@oracle.com>) id 1T9Ip2-00073p-QO
	for xen-devel@lists.xen.org; Wed, 05 Sep 2012 16:51:25 +0000
X-Env-Sender: dan.magenheimer@oracle.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1346863876!2051358!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzI4NDYw\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11692 invoked from network); 5 Sep 2012 16:51:17 -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 Sep 2012 16:51: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 q85GpEv6014753
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 5 Sep 2012 16:51:15 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q85GpDmG020134
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 5 Sep 2012 16:51:14 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
	q85GpDvS018393; Wed, 5 Sep 2012 11:51:13 -0500
MIME-Version: 1.0
Message-ID: <c0ecf9e3-e9d1-4fc8-8427-88aff3441c33@default>
Date: Wed, 5 Sep 2012 09:50:31 -0700 (PDT)
From: Dan Magenheimer <dan.magenheimer@oracle.com>
To: Jan Beulich <JBeulich@suse.com>, xen-devel <xen-devel@lists.xen.org>
References: <5047639E0200007800098DD1@nat28.tlf.novell.com>
In-Reply-To: <5047639E0200007800098DD1@nat28.tlf.novell.com>
X-Priority: 3
X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.7  (607090) [OL
	12.0.6661.5003 (x86)]
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: Zhenzhong Duan <zhenzhong.duan@oracle.com>,
	Konrad Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH 05/11] tmem: don't access guest memory
 without using the accessors intended for this
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> From: Jan Beulich [mailto:JBeulich@suse.com]
> Sent: Wednesday, September 05, 2012 6:37 AM
> To: xen-devel
> Cc: Dan Magenheimer; Zhenzhong Duan
> Subject: [PATCH 05/11] tmem: don't access guest memory without using the accessors intended for this
> 
> This is not permitted, not even for buffers coming from Dom0 (and it
> would also break the moment Dom0 runs in HVM mode). An implication from
> the changes here is that tmh_copy_page() can't be used anymore for
> control operations calling tmh_copy_{from,to}_client() (as those pass
> the buffer by virtual address rather than MFN).
> 
> Note that tmemc_save_get_next_page() previously didn't set the returned
> handle's pool_id field, while the new code does. It need to be
> confirmed that this is not a problem (otherwise the copy-out operation
> will require further tmh_...() abstractions to be added).
> 
> Further note that the patch removes (rather than adjusts) an invalid
> call to unmap_domain_page() (no matching map_domain_page()) from
> tmh_compress_from_client() and adds a missing one to an error return
> path in tmh_copy_from_client().
> 
> Finally note that the patch adds a previously missing return statement
> to cli_get_page() (without which that function could de-reference a
> NULL pointer, triggerable from guest mode).
> 
> This is part of XSA-15 / CVE-2012-3497.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

I'm a bit baffled by all the unrelated changes and cleanups, but
they all appear to be valid fixes and, most importantly, the
related security issues appear to be resolved.

I'm also unable right now to plumb the depths of the guest copying
macros so will have to trust Jan's good judgement.  One point in
particular, it's difficult to determine if the following line is
copying two bytes (wrong) or two uint64_t's (correct).

> +        tmh_copy_to_client_buf(buf, pool->uuid, 2);

Last, this patch almost certainly breaks save/restore/migration of
tmem-enabled guests, but that functionality (which once worked
fine) has apparently been broken for awhile.  So let's go
with this new code and fix save/restore/migration on top of it.

Acked-by: Dan Magenheimer <dan.magenheimer@oracle.com>

(no further comments in the code, so patch elided)

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

From xen-devel-bounces@lists.xen.org Wed Sep 05 16:51:37 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Sep 2012 16: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 1T9Ip3-00073u-P6; Wed, 05 Sep 2012 16:51:25 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dan.magenheimer@oracle.com>) id 1T9Ip2-00073p-QO
	for xen-devel@lists.xen.org; Wed, 05 Sep 2012 16:51:25 +0000
X-Env-Sender: dan.magenheimer@oracle.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1346863876!2051358!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzI4NDYw\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11692 invoked from network); 5 Sep 2012 16:51:17 -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 Sep 2012 16:51: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 q85GpEv6014753
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 5 Sep 2012 16:51:15 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q85GpDmG020134
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 5 Sep 2012 16:51:14 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
	q85GpDvS018393; Wed, 5 Sep 2012 11:51:13 -0500
MIME-Version: 1.0
Message-ID: <c0ecf9e3-e9d1-4fc8-8427-88aff3441c33@default>
Date: Wed, 5 Sep 2012 09:50:31 -0700 (PDT)
From: Dan Magenheimer <dan.magenheimer@oracle.com>
To: Jan Beulich <JBeulich@suse.com>, xen-devel <xen-devel@lists.xen.org>
References: <5047639E0200007800098DD1@nat28.tlf.novell.com>
In-Reply-To: <5047639E0200007800098DD1@nat28.tlf.novell.com>
X-Priority: 3
X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.7  (607090) [OL
	12.0.6661.5003 (x86)]
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: Zhenzhong Duan <zhenzhong.duan@oracle.com>,
	Konrad Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH 05/11] tmem: don't access guest memory
 without using the accessors intended for this
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> From: Jan Beulich [mailto:JBeulich@suse.com]
> Sent: Wednesday, September 05, 2012 6:37 AM
> To: xen-devel
> Cc: Dan Magenheimer; Zhenzhong Duan
> Subject: [PATCH 05/11] tmem: don't access guest memory without using the accessors intended for this
> 
> This is not permitted, not even for buffers coming from Dom0 (and it
> would also break the moment Dom0 runs in HVM mode). An implication from
> the changes here is that tmh_copy_page() can't be used anymore for
> control operations calling tmh_copy_{from,to}_client() (as those pass
> the buffer by virtual address rather than MFN).
> 
> Note that tmemc_save_get_next_page() previously didn't set the returned
> handle's pool_id field, while the new code does. It need to be
> confirmed that this is not a problem (otherwise the copy-out operation
> will require further tmh_...() abstractions to be added).
> 
> Further note that the patch removes (rather than adjusts) an invalid
> call to unmap_domain_page() (no matching map_domain_page()) from
> tmh_compress_from_client() and adds a missing one to an error return
> path in tmh_copy_from_client().
> 
> Finally note that the patch adds a previously missing return statement
> to cli_get_page() (without which that function could de-reference a
> NULL pointer, triggerable from guest mode).
> 
> This is part of XSA-15 / CVE-2012-3497.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

I'm a bit baffled by all the unrelated changes and cleanups, but
they all appear to be valid fixes and, most importantly, the
related security issues appear to be resolved.

I'm also unable right now to plumb the depths of the guest copying
macros so will have to trust Jan's good judgement.  One point in
particular, it's difficult to determine if the following line is
copying two bytes (wrong) or two uint64_t's (correct).

> +        tmh_copy_to_client_buf(buf, pool->uuid, 2);

Last, this patch almost certainly breaks save/restore/migration of
tmem-enabled guests, but that functionality (which once worked
fine) has apparently been broken for awhile.  So let's go
with this new code and fix save/restore/migration on top of it.

Acked-by: Dan Magenheimer <dan.magenheimer@oracle.com>

(no further comments in the code, so patch elided)

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

From xen-devel-bounces@lists.xen.org Wed Sep 05 17:03:27 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Sep 2012 17: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 1T9J0S-0007Mc-Hx; Wed, 05 Sep 2012 17:03:12 +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 1T9J0Q-0007MX-KZ
	for xen-devel@lists.xen.org; Wed, 05 Sep 2012 17:03:10 +0000
Received: from [85.158.143.99:24069] by server-3.bemta-4.messagelabs.com id
	8D/54-08232-DC587405; Wed, 05 Sep 2012 17:03:09 +0000
X-Env-Sender: dan.magenheimer@oracle.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1346864587!23486135!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzI4NDYw\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25081 invoked from network); 5 Sep 2012 17:03:09 -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; 5 Sep 2012 17:03:09 -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 q85H35wS027338
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 5 Sep 2012 17:03:06 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
	q85H34Eh015026
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 5 Sep 2012 17:03:05 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
	q85H34Yl027374; Wed, 5 Sep 2012 12:03:04 -0500
MIME-Version: 1.0
Message-ID: <d3111957-961a-4b78-8e59-85ba8b7e03e1@default>
Date: Wed, 5 Sep 2012 10:02:21 -0700 (PDT)
From: Dan Magenheimer <dan.magenheimer@oracle.com>
To: Jan Beulich <JBeulich@suse.com>
References: <76edd759-ceca-4fb5-b411-1e598137afd8@default>
	<50476EB60200007800098EBD@nat28.tlf.novell.com>
In-Reply-To: <50476EB60200007800098EBD@nat28.tlf.novell.com>
X-Priority: 3
X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.7  (607090) [OL
	12.0.6661.5003 (x86)]
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: Konrad Wilk <konrad.wilk@oracle.com>, keir@xen.org,
	Zhenzhong Duan <zhenzhong.duan@oracle.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] [FOR 4.2] tmem: add matching unlock for an
 about-to-be-destroyed object
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> From: Jan Beulich [mailto:JBeulich@suse.com]
> Sent: Wednesday, September 05, 2012 7:25 AM
> To: Dan Magenheimer
> Cc: xen-devel@lists.xen.org; Konrad Wilk; Zhenzhong Duan; keir@xen.org
> Subject: Re: [Xen-devel] [PATCH] [FOR 4.2] tmem: add matching unlock for an about-to-be-destroyed
> object
> 
> >>> On 31.08.12 at 21:58, Dan Magenheimer <dan.magenheimer@oracle.com> wrote:
> > A 4.2 changeset forces a preempt_disable/enable with
> > every lock/unlock.
> >
> > Tmem has dynamically allocated "objects" that contain a
> > lock.  The lock is held when the object is destroyed.
> > No reason to unlock something that's about to be destroyed!
> > But with the preempt_enable/disable in the generic locking code,
> > and the fact that do_softirq ASSERTs that preempt_count
> > must be zero, a crash occurs soon after any object is
> > destroyed.
> >
> > So force lock to be released before destroying objects.
> 
> We had noticed this oddity during XSA-15 processing too.
> What's the purpose of holding a lock on a to be destroyed
> object anyway? One would expect a lock of a containing
> entity to be held for that purpose (or really just while
> taking the object off whatever data structure it can be
> looked up through), which would eliminate the need for
> locking the object itself. That lock generally appears to be
> pool_rwlock, but in several places that one gets acquired
> _after_ checking pgp_count to be zero - how is it being
> guaranteed that this count doesn't increase between the
> check and the lock being acquired?

The flush_object code needs to obj_find the object before
it can destroy it and a successful obj_find takes the
lock.

Pushing the lock down to the object level was a misguided
attempt to maximize concurrency, especially for early
versions of persistent pools (frontswap) where the number of
objects was small (one per swap device).

I do agree that the tmem locking model deserves a complete rewrite.
The locking model of the similar code in upstream Linux
(which model was originally suggested by Jeremy Fitzhardinge)
is almost certainly superior and less buggy, though probably
slightly less concurrent.  The linux version probably should
be "back ported" into Xen now.

Dan

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

From xen-devel-bounces@lists.xen.org Wed Sep 05 17:03:27 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Sep 2012 17: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 1T9J0S-0007Mc-Hx; Wed, 05 Sep 2012 17:03:12 +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 1T9J0Q-0007MX-KZ
	for xen-devel@lists.xen.org; Wed, 05 Sep 2012 17:03:10 +0000
Received: from [85.158.143.99:24069] by server-3.bemta-4.messagelabs.com id
	8D/54-08232-DC587405; Wed, 05 Sep 2012 17:03:09 +0000
X-Env-Sender: dan.magenheimer@oracle.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1346864587!23486135!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzI4NDYw\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25081 invoked from network); 5 Sep 2012 17:03:09 -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; 5 Sep 2012 17:03:09 -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 q85H35wS027338
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 5 Sep 2012 17:03:06 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
	q85H34Eh015026
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 5 Sep 2012 17:03:05 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
	q85H34Yl027374; Wed, 5 Sep 2012 12:03:04 -0500
MIME-Version: 1.0
Message-ID: <d3111957-961a-4b78-8e59-85ba8b7e03e1@default>
Date: Wed, 5 Sep 2012 10:02:21 -0700 (PDT)
From: Dan Magenheimer <dan.magenheimer@oracle.com>
To: Jan Beulich <JBeulich@suse.com>
References: <76edd759-ceca-4fb5-b411-1e598137afd8@default>
	<50476EB60200007800098EBD@nat28.tlf.novell.com>
In-Reply-To: <50476EB60200007800098EBD@nat28.tlf.novell.com>
X-Priority: 3
X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.7  (607090) [OL
	12.0.6661.5003 (x86)]
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: Konrad Wilk <konrad.wilk@oracle.com>, keir@xen.org,
	Zhenzhong Duan <zhenzhong.duan@oracle.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] [FOR 4.2] tmem: add matching unlock for an
 about-to-be-destroyed object
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> From: Jan Beulich [mailto:JBeulich@suse.com]
> Sent: Wednesday, September 05, 2012 7:25 AM
> To: Dan Magenheimer
> Cc: xen-devel@lists.xen.org; Konrad Wilk; Zhenzhong Duan; keir@xen.org
> Subject: Re: [Xen-devel] [PATCH] [FOR 4.2] tmem: add matching unlock for an about-to-be-destroyed
> object
> 
> >>> On 31.08.12 at 21:58, Dan Magenheimer <dan.magenheimer@oracle.com> wrote:
> > A 4.2 changeset forces a preempt_disable/enable with
> > every lock/unlock.
> >
> > Tmem has dynamically allocated "objects" that contain a
> > lock.  The lock is held when the object is destroyed.
> > No reason to unlock something that's about to be destroyed!
> > But with the preempt_enable/disable in the generic locking code,
> > and the fact that do_softirq ASSERTs that preempt_count
> > must be zero, a crash occurs soon after any object is
> > destroyed.
> >
> > So force lock to be released before destroying objects.
> 
> We had noticed this oddity during XSA-15 processing too.
> What's the purpose of holding a lock on a to be destroyed
> object anyway? One would expect a lock of a containing
> entity to be held for that purpose (or really just while
> taking the object off whatever data structure it can be
> looked up through), which would eliminate the need for
> locking the object itself. That lock generally appears to be
> pool_rwlock, but in several places that one gets acquired
> _after_ checking pgp_count to be zero - how is it being
> guaranteed that this count doesn't increase between the
> check and the lock being acquired?

The flush_object code needs to obj_find the object before
it can destroy it and a successful obj_find takes the
lock.

Pushing the lock down to the object level was a misguided
attempt to maximize concurrency, especially for early
versions of persistent pools (frontswap) where the number of
objects was small (one per swap device).

I do agree that the tmem locking model deserves a complete rewrite.
The locking model of the similar code in upstream Linux
(which model was originally suggested by Jeremy Fitzhardinge)
is almost certainly superior and less buggy, though probably
slightly less concurrent.  The linux version probably should
be "back ported" into Xen now.

Dan

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

From xen-devel-bounces@lists.xen.org Wed Sep 05 17:06:24 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Sep 2012 17: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 1T9J3L-0007Sw-6h; Wed, 05 Sep 2012 17:06:11 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1T9J3K-0007Sg-5P
	for xen-devel@lists.xen.org; Wed, 05 Sep 2012 17:06:10 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-4.tower-27.messagelabs.com!1346864731!9170374!1
X-Originating-IP: [63.239.67.9]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12580 invoked from network); 5 Sep 2012 17:05:31 -0000
Received: from emvm-gh1-uea08.nsa.gov (HELO nsa.gov) (63.239.67.9)
	by server-4.tower-27.messagelabs.com with SMTP;
	5 Sep 2012 17:05:31 -0000
X-TM-IMSS-Message-ID: <16110ab1000c1715@nsa.gov>
Received: from tarius.tycho.ncsc.mil ([144.51.3.1]) by nsa.gov ([63.239.67.9])
	with ESMTP (TREND IMSS SMTP Service 7.1) id 16110ab1000c1715 ;
	Wed, 5 Sep 2012 13:05:30 -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 q85H5LxL029489; 
	Wed, 5 Sep 2012 13:05:21 -0400
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: Ian.Campbell@citrix.com
Date: Wed,  5 Sep 2012 13:05:13 -0400
Message-Id: <1346864713-28732-1-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.11.4
In-Reply-To: <1346400260.27277.93.camel@zakaz.uk.xensource.com>
References: <1346400260.27277.93.camel@zakaz.uk.xensource.com>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>, Ian.Jackson@eu.citrix.com,
	xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH v2] libxl: Support backend domain ID for disks
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Allow specification of backend domains for disks, either in the config
file or via xl block-attach. This functionality was supported in xend
(via an optional command line parameter to block-attach), so should also
be supported with libxl.

In order to support named backend domains like network-attach, a valid
libxl_ctx must now be passed to xlu_cfg_init.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>

---

This patch does not include the changes to tools/libxl/libxlu_disk_l.c
and tools/libxl/libxlu_disk_l.h because the diffs contain unrelated
changes due to different generator versions.

 docs/misc/xl-disk-configuration.txt | 12 ++++++++++++
 tools/libxl/libxlu_cfg.c            |  4 +++-
 tools/libxl/libxlu_disk_l.l         |  9 +++++++++
 tools/libxl/libxlu_internal.h       |  1 +
 tools/libxl/libxlutil.h             |  3 ++-
 tools/libxl/xl.c                    |  2 +-
 tools/libxl/xl_cmdimpl.c            | 20 +++++++++-----------
 7 files changed, 37 insertions(+), 14 deletions(-)

diff --git a/docs/misc/xl-disk-configuration.txt b/docs/misc/xl-disk-configuration.txt
index 86c16be..5bd456d 100644
--- a/docs/misc/xl-disk-configuration.txt
+++ b/docs/misc/xl-disk-configuration.txt
@@ -139,6 +139,18 @@ cdrom
 Convenience alias for "devtype=cdrom".
 
 
+backend=<domain-name>
+---------------------
+
+Description:           Designates a backend domain for the device
+Supported values:      Valid domain names
+Mandatory:             No
+
+Specifies the backend domain which this device should attach to. This
+defaults to domain 0. Specifying another domain requires setting up a
+driver domain which is outside the scope of this document.
+
+
 backendtype=<backend-type>
 --------------------------
 
diff --git a/tools/libxl/libxlu_cfg.c b/tools/libxl/libxlu_cfg.c
index 22adcb0..1d086b4 100644
--- a/tools/libxl/libxlu_cfg.c
+++ b/tools/libxl/libxlu_cfg.c
@@ -25,13 +25,15 @@
 #include "libxlu_cfg_l.h"
 #include "libxlu_cfg_i.h"
 
-XLU_Config *xlu_cfg_init(FILE *report, const char *report_source) {
+XLU_Config *xlu_cfg_init(FILE *report, const char *report_source,
+                         libxl_ctx *ctx) {
     XLU_Config *cfg;
 
     cfg= malloc(sizeof(*cfg));
     if (!cfg) return 0;
 
     cfg->report= report;
+    cfg->ctx = ctx;
     cfg->config_source= strdup(report_source);
     if (!cfg->config_source) { free(cfg); return 0; }
 
diff --git a/tools/libxl/libxlu_disk_l.l b/tools/libxl/libxlu_disk_l.l
index bee16a1..8cfc16e 100644
--- a/tools/libxl/libxlu_disk_l.l
+++ b/tools/libxl/libxlu_disk_l.l
@@ -33,6 +33,7 @@
 
 %{
 #include "libxlu_disk_i.h"
+#include "libxl_utils.h"
 
 #define YY_NO_INPUT
 
@@ -113,6 +114,13 @@ static void setbackendtype(DiskParseContext *dpc, const char *str) {
     else xlu__disk_err(dpc,str,"unknown value for backendtype");
 }
 
+/* Sets ->backend_domid from the string. */
+static void setbackend(DiskParseContext *dpc, const char *str) {
+    if (libxl_name_to_domid(dpc->cfg->ctx, str, &dpc->disk->backend_domid)) {
+        xlu__disk_err(dpc,str,"unknown domain for backend");
+    }
+}
+
 #define DEPRECATE(usewhatinstead) /* not currently reported */
 
 /* Handles a vdev positional parameter which includes a devtype. */
@@ -168,6 +176,7 @@ devtype=disk,?	{ DPC->disk->is_cdrom = 0; }
 devtype=[^,]*,?	{ xlu__disk_err(DPC,yytext,"unknown value for type"); }
 
 access=[^,]*,?	{ STRIP(','); setaccess(DPC, FROMEQUALS); }
+backend=[^,]*,? { STRIP(','); setbackend(DPC,FROMEQUALS); }
 backendtype=[^,]*,? { STRIP(','); setbackendtype(DPC,FROMEQUALS); }
 
 vdev=[^,]*,?	{ STRIP(','); SAVESTRING("vdev", vdev, FROMEQUALS); }
diff --git a/tools/libxl/libxlu_internal.h b/tools/libxl/libxlu_internal.h
index 7579158..5a9cf6d 100644
--- a/tools/libxl/libxlu_internal.h
+++ b/tools/libxl/libxlu_internal.h
@@ -39,6 +39,7 @@ struct XLU_Config {
     XLU_ConfigSetting *settings;
     FILE *report;
     char *config_source;
+    libxl_ctx *ctx;
 };
 
 typedef struct {
diff --git a/tools/libxl/libxlutil.h b/tools/libxl/libxlutil.h
index 0333e55..1de23e7 100644
--- a/tools/libxl/libxlutil.h
+++ b/tools/libxl/libxlutil.h
@@ -24,7 +24,8 @@
 typedef struct XLU_Config XLU_Config;
 typedef struct XLU_ConfigList XLU_ConfigList;
 
-XLU_Config *xlu_cfg_init(FILE *report, const char *report_filename);
+XLU_Config *xlu_cfg_init(FILE *report, const char *report_filename,
+                         libxl_ctx *ctx);
   /* 0 means we got ENOMEM. */
   /* report_filename is copied; report is saved and must remain valid
    *  until the Config is destroyed. */
diff --git a/tools/libxl/xl.c b/tools/libxl/xl.c
index f31e836..32a5c32 100644
--- a/tools/libxl/xl.c
+++ b/tools/libxl/xl.c
@@ -56,7 +56,7 @@ static void parse_global_config(const char *configfile,
     int e;
     const char *buf;
 
-    config = xlu_cfg_init(stderr, configfile);
+    config = xlu_cfg_init(stderr, configfile, ctx);
     if (!config) {
         fprintf(stderr, "Failed to allocate for configuration\n");
         exit(1);
diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index 2d6ab97..eaebbeb 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -427,7 +427,7 @@ static void parse_disk_config_multistring(XLU_Config **config,
     libxl_device_disk_init(disk);
 
     if (!*config) {
-        *config = xlu_cfg_init(stderr, "command line");
+        *config = xlu_cfg_init(stderr, "command line", ctx);
         if (!*config) { perror("xlu_cfg_init"); exit(-1); }
     }
 
@@ -583,7 +583,7 @@ static void parse_config_data(const char *config_source,
     libxl_domain_create_info *c_info = &d_config->c_info;
     libxl_domain_build_info *b_info = &d_config->b_info;
 
-    config= xlu_cfg_init(stderr, config_source);
+    config= xlu_cfg_init(stderr, config_source, ctx);
     if (!config) {
         fprintf(stderr, "Failed to allocate for configuration\n");
         exit(1);
@@ -2473,7 +2473,7 @@ static void pcidetach(const char *dom, const char *bdf, int force)
 
     libxl_device_pci_init(&pcidev);
     
-    config = xlu_cfg_init(stderr, "command line");
+    config = xlu_cfg_init(stderr, "command line", ctx);
     if (!config) { perror("xlu_cfg_inig"); exit(-1); }
 
     if (xlu_pci_parse_bdf(config, &pcidev, bdf)) {
@@ -2520,7 +2520,7 @@ static void pciattach(const char *dom, const char *bdf, const char *vs)
 
     libxl_device_pci_init(&pcidev);
 
-    config = xlu_cfg_init(stderr, "command line");
+    config = xlu_cfg_init(stderr, "command line", ctx);
     if (!config) { perror("xlu_cfg_inig"); exit(-1); }
 
     if (xlu_pci_parse_bdf(config, &pcidev, bdf)) {
@@ -2586,7 +2586,7 @@ static void pciassignable_add(const char *bdf, int rebind)
 
     libxl_device_pci_init(&pcidev);
 
-    config = xlu_cfg_init(stderr, "command line");
+    config = xlu_cfg_init(stderr, "command line", ctx);
     if (!config) { perror("xlu_cfg_init"); exit(-1); }
 
     if (xlu_pci_parse_bdf(config, &pcidev, bdf)) {
@@ -2624,7 +2624,7 @@ static void pciassignable_remove(const char *bdf, int rebind)
 
     libxl_device_pci_init(&pcidev);
 
-    config = xlu_cfg_init(stderr, "command line");
+    config = xlu_cfg_init(stderr, "command line", ctx);
     if (!config) { perror("xlu_cfg_init"); exit(-1); }
 
     if (xlu_pci_parse_bdf(config, &pcidev, bdf)) {
@@ -5321,7 +5321,7 @@ int main_networkattach(int argc, char **argv)
         return 1;
     }
 
-    config= xlu_cfg_init(stderr, "command line");
+    config= xlu_cfg_init(stderr, "command line", ctx);
     if (!config) {
         fprintf(stderr, "Failed to allocate for configuration\n");
         return 1;
@@ -5467,7 +5467,7 @@ int main_networkdetach(int argc, char **argv)
 int main_blockattach(int argc, char **argv)
 {
     int opt;
-    uint32_t fe_domid, be_domid = 0;
+    uint32_t fe_domid;
     libxl_device_disk disk = { 0 };
     XLU_Config *config = 0;
 
@@ -5483,8 +5483,6 @@ int main_blockattach(int argc, char **argv)
     parse_disk_config_multistring
         (&config, argc-optind, (const char* const*)argv + optind, &disk);
 
-    disk.backend_domid = be_domid;
-
     if (dryrun_only) {
         char *json = libxl_device_disk_to_json(ctx, &disk);
         printf("disk: %s\n", json);
@@ -6078,7 +6076,7 @@ int main_cpupoolcreate(int argc, char **argv)
         config_len += strlen(extra_config) + 1;
     }
 
-    config = xlu_cfg_init(stderr, config_src);
+    config = xlu_cfg_init(stderr, config_src, ctx);
     if (!config) {
         fprintf(stderr, "Failed to allocate for configuration\n");
         goto out;
-- 
1.7.11.4


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

From xen-devel-bounces@lists.xen.org Wed Sep 05 17:06:24 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Sep 2012 17: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 1T9J3L-0007Sw-6h; Wed, 05 Sep 2012 17:06:11 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1T9J3K-0007Sg-5P
	for xen-devel@lists.xen.org; Wed, 05 Sep 2012 17:06:10 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-4.tower-27.messagelabs.com!1346864731!9170374!1
X-Originating-IP: [63.239.67.9]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12580 invoked from network); 5 Sep 2012 17:05:31 -0000
Received: from emvm-gh1-uea08.nsa.gov (HELO nsa.gov) (63.239.67.9)
	by server-4.tower-27.messagelabs.com with SMTP;
	5 Sep 2012 17:05:31 -0000
X-TM-IMSS-Message-ID: <16110ab1000c1715@nsa.gov>
Received: from tarius.tycho.ncsc.mil ([144.51.3.1]) by nsa.gov ([63.239.67.9])
	with ESMTP (TREND IMSS SMTP Service 7.1) id 16110ab1000c1715 ;
	Wed, 5 Sep 2012 13:05:30 -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 q85H5LxL029489; 
	Wed, 5 Sep 2012 13:05:21 -0400
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: Ian.Campbell@citrix.com
Date: Wed,  5 Sep 2012 13:05:13 -0400
Message-Id: <1346864713-28732-1-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.11.4
In-Reply-To: <1346400260.27277.93.camel@zakaz.uk.xensource.com>
References: <1346400260.27277.93.camel@zakaz.uk.xensource.com>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>, Ian.Jackson@eu.citrix.com,
	xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH v2] libxl: Support backend domain ID for disks
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Allow specification of backend domains for disks, either in the config
file or via xl block-attach. This functionality was supported in xend
(via an optional command line parameter to block-attach), so should also
be supported with libxl.

In order to support named backend domains like network-attach, a valid
libxl_ctx must now be passed to xlu_cfg_init.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>

---

This patch does not include the changes to tools/libxl/libxlu_disk_l.c
and tools/libxl/libxlu_disk_l.h because the diffs contain unrelated
changes due to different generator versions.

 docs/misc/xl-disk-configuration.txt | 12 ++++++++++++
 tools/libxl/libxlu_cfg.c            |  4 +++-
 tools/libxl/libxlu_disk_l.l         |  9 +++++++++
 tools/libxl/libxlu_internal.h       |  1 +
 tools/libxl/libxlutil.h             |  3 ++-
 tools/libxl/xl.c                    |  2 +-
 tools/libxl/xl_cmdimpl.c            | 20 +++++++++-----------
 7 files changed, 37 insertions(+), 14 deletions(-)

diff --git a/docs/misc/xl-disk-configuration.txt b/docs/misc/xl-disk-configuration.txt
index 86c16be..5bd456d 100644
--- a/docs/misc/xl-disk-configuration.txt
+++ b/docs/misc/xl-disk-configuration.txt
@@ -139,6 +139,18 @@ cdrom
 Convenience alias for "devtype=cdrom".
 
 
+backend=<domain-name>
+---------------------
+
+Description:           Designates a backend domain for the device
+Supported values:      Valid domain names
+Mandatory:             No
+
+Specifies the backend domain which this device should attach to. This
+defaults to domain 0. Specifying another domain requires setting up a
+driver domain which is outside the scope of this document.
+
+
 backendtype=<backend-type>
 --------------------------
 
diff --git a/tools/libxl/libxlu_cfg.c b/tools/libxl/libxlu_cfg.c
index 22adcb0..1d086b4 100644
--- a/tools/libxl/libxlu_cfg.c
+++ b/tools/libxl/libxlu_cfg.c
@@ -25,13 +25,15 @@
 #include "libxlu_cfg_l.h"
 #include "libxlu_cfg_i.h"
 
-XLU_Config *xlu_cfg_init(FILE *report, const char *report_source) {
+XLU_Config *xlu_cfg_init(FILE *report, const char *report_source,
+                         libxl_ctx *ctx) {
     XLU_Config *cfg;
 
     cfg= malloc(sizeof(*cfg));
     if (!cfg) return 0;
 
     cfg->report= report;
+    cfg->ctx = ctx;
     cfg->config_source= strdup(report_source);
     if (!cfg->config_source) { free(cfg); return 0; }
 
diff --git a/tools/libxl/libxlu_disk_l.l b/tools/libxl/libxlu_disk_l.l
index bee16a1..8cfc16e 100644
--- a/tools/libxl/libxlu_disk_l.l
+++ b/tools/libxl/libxlu_disk_l.l
@@ -33,6 +33,7 @@
 
 %{
 #include "libxlu_disk_i.h"
+#include "libxl_utils.h"
 
 #define YY_NO_INPUT
 
@@ -113,6 +114,13 @@ static void setbackendtype(DiskParseContext *dpc, const char *str) {
     else xlu__disk_err(dpc,str,"unknown value for backendtype");
 }
 
+/* Sets ->backend_domid from the string. */
+static void setbackend(DiskParseContext *dpc, const char *str) {
+    if (libxl_name_to_domid(dpc->cfg->ctx, str, &dpc->disk->backend_domid)) {
+        xlu__disk_err(dpc,str,"unknown domain for backend");
+    }
+}
+
 #define DEPRECATE(usewhatinstead) /* not currently reported */
 
 /* Handles a vdev positional parameter which includes a devtype. */
@@ -168,6 +176,7 @@ devtype=disk,?	{ DPC->disk->is_cdrom = 0; }
 devtype=[^,]*,?	{ xlu__disk_err(DPC,yytext,"unknown value for type"); }
 
 access=[^,]*,?	{ STRIP(','); setaccess(DPC, FROMEQUALS); }
+backend=[^,]*,? { STRIP(','); setbackend(DPC,FROMEQUALS); }
 backendtype=[^,]*,? { STRIP(','); setbackendtype(DPC,FROMEQUALS); }
 
 vdev=[^,]*,?	{ STRIP(','); SAVESTRING("vdev", vdev, FROMEQUALS); }
diff --git a/tools/libxl/libxlu_internal.h b/tools/libxl/libxlu_internal.h
index 7579158..5a9cf6d 100644
--- a/tools/libxl/libxlu_internal.h
+++ b/tools/libxl/libxlu_internal.h
@@ -39,6 +39,7 @@ struct XLU_Config {
     XLU_ConfigSetting *settings;
     FILE *report;
     char *config_source;
+    libxl_ctx *ctx;
 };
 
 typedef struct {
diff --git a/tools/libxl/libxlutil.h b/tools/libxl/libxlutil.h
index 0333e55..1de23e7 100644
--- a/tools/libxl/libxlutil.h
+++ b/tools/libxl/libxlutil.h
@@ -24,7 +24,8 @@
 typedef struct XLU_Config XLU_Config;
 typedef struct XLU_ConfigList XLU_ConfigList;
 
-XLU_Config *xlu_cfg_init(FILE *report, const char *report_filename);
+XLU_Config *xlu_cfg_init(FILE *report, const char *report_filename,
+                         libxl_ctx *ctx);
   /* 0 means we got ENOMEM. */
   /* report_filename is copied; report is saved and must remain valid
    *  until the Config is destroyed. */
diff --git a/tools/libxl/xl.c b/tools/libxl/xl.c
index f31e836..32a5c32 100644
--- a/tools/libxl/xl.c
+++ b/tools/libxl/xl.c
@@ -56,7 +56,7 @@ static void parse_global_config(const char *configfile,
     int e;
     const char *buf;
 
-    config = xlu_cfg_init(stderr, configfile);
+    config = xlu_cfg_init(stderr, configfile, ctx);
     if (!config) {
         fprintf(stderr, "Failed to allocate for configuration\n");
         exit(1);
diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index 2d6ab97..eaebbeb 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -427,7 +427,7 @@ static void parse_disk_config_multistring(XLU_Config **config,
     libxl_device_disk_init(disk);
 
     if (!*config) {
-        *config = xlu_cfg_init(stderr, "command line");
+        *config = xlu_cfg_init(stderr, "command line", ctx);
         if (!*config) { perror("xlu_cfg_init"); exit(-1); }
     }
 
@@ -583,7 +583,7 @@ static void parse_config_data(const char *config_source,
     libxl_domain_create_info *c_info = &d_config->c_info;
     libxl_domain_build_info *b_info = &d_config->b_info;
 
-    config= xlu_cfg_init(stderr, config_source);
+    config= xlu_cfg_init(stderr, config_source, ctx);
     if (!config) {
         fprintf(stderr, "Failed to allocate for configuration\n");
         exit(1);
@@ -2473,7 +2473,7 @@ static void pcidetach(const char *dom, const char *bdf, int force)
 
     libxl_device_pci_init(&pcidev);
     
-    config = xlu_cfg_init(stderr, "command line");
+    config = xlu_cfg_init(stderr, "command line", ctx);
     if (!config) { perror("xlu_cfg_inig"); exit(-1); }
 
     if (xlu_pci_parse_bdf(config, &pcidev, bdf)) {
@@ -2520,7 +2520,7 @@ static void pciattach(const char *dom, const char *bdf, const char *vs)
 
     libxl_device_pci_init(&pcidev);
 
-    config = xlu_cfg_init(stderr, "command line");
+    config = xlu_cfg_init(stderr, "command line", ctx);
     if (!config) { perror("xlu_cfg_inig"); exit(-1); }
 
     if (xlu_pci_parse_bdf(config, &pcidev, bdf)) {
@@ -2586,7 +2586,7 @@ static void pciassignable_add(const char *bdf, int rebind)
 
     libxl_device_pci_init(&pcidev);
 
-    config = xlu_cfg_init(stderr, "command line");
+    config = xlu_cfg_init(stderr, "command line", ctx);
     if (!config) { perror("xlu_cfg_init"); exit(-1); }
 
     if (xlu_pci_parse_bdf(config, &pcidev, bdf)) {
@@ -2624,7 +2624,7 @@ static void pciassignable_remove(const char *bdf, int rebind)
 
     libxl_device_pci_init(&pcidev);
 
-    config = xlu_cfg_init(stderr, "command line");
+    config = xlu_cfg_init(stderr, "command line", ctx);
     if (!config) { perror("xlu_cfg_init"); exit(-1); }
 
     if (xlu_pci_parse_bdf(config, &pcidev, bdf)) {
@@ -5321,7 +5321,7 @@ int main_networkattach(int argc, char **argv)
         return 1;
     }
 
-    config= xlu_cfg_init(stderr, "command line");
+    config= xlu_cfg_init(stderr, "command line", ctx);
     if (!config) {
         fprintf(stderr, "Failed to allocate for configuration\n");
         return 1;
@@ -5467,7 +5467,7 @@ int main_networkdetach(int argc, char **argv)
 int main_blockattach(int argc, char **argv)
 {
     int opt;
-    uint32_t fe_domid, be_domid = 0;
+    uint32_t fe_domid;
     libxl_device_disk disk = { 0 };
     XLU_Config *config = 0;
 
@@ -5483,8 +5483,6 @@ int main_blockattach(int argc, char **argv)
     parse_disk_config_multistring
         (&config, argc-optind, (const char* const*)argv + optind, &disk);
 
-    disk.backend_domid = be_domid;
-
     if (dryrun_only) {
         char *json = libxl_device_disk_to_json(ctx, &disk);
         printf("disk: %s\n", json);
@@ -6078,7 +6076,7 @@ int main_cpupoolcreate(int argc, char **argv)
         config_len += strlen(extra_config) + 1;
     }
 
-    config = xlu_cfg_init(stderr, config_src);
+    config = xlu_cfg_init(stderr, config_src, ctx);
     if (!config) {
         fprintf(stderr, "Failed to allocate for configuration\n");
         goto out;
-- 
1.7.11.4


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

From xen-devel-bounces@lists.xen.org Wed Sep 05 17:09:54 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Sep 2012 17: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 1T9J6h-0007fW-QI; Wed, 05 Sep 2012 17:09:39 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andreslc@gridcentric.ca>) id 1T9J6g-0007fN-5W
	for xen-devel@lists.xensource.com; Wed, 05 Sep 2012 17:09:38 +0000
Received: from [85.158.143.99:58075] by server-2.bemta-4.messagelabs.com id
	B9/55-21239-15787405; Wed, 05 Sep 2012 17:09:37 +0000
X-Env-Sender: andreslc@gridcentric.ca
X-Msg-Ref: server-3.tower-216.messagelabs.com!1346864974!28149743!1
X-Originating-IP: [209.85.223.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18507 invoked from network); 5 Sep 2012 17:09:36 -0000
Received: from mail-ie0-f171.google.com (HELO mail-ie0-f171.google.com)
	(209.85.223.171)
	by server-3.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Sep 2012 17:09:36 -0000
Received: by ieje14 with SMTP id e14so1916775iej.30
	for <xen-devel@lists.xensource.com>;
	Wed, 05 Sep 2012 10:09:34 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=subject:mime-version:content-type:from:in-reply-to:date:cc
	:content-transfer-encoding:message-id:references:to:x-mailer
	:x-gm-message-state;
	bh=MlQu0+ve5HpKPlI4fNUxBrbFZfqFldMS9yiGUDN4/os=;
	b=ciJ6gnCXLSpeBWiVRyB2qhSpetZ7c4NHnjzq3TIcShEXRIXaL/La29D2YniqId7kFf
	uIsbUuyl5LXk2uXxWWmeDe0Ib3y1iu5iOGdt+lB03EmRHYROl4ca1uMzfi8gXVNdZF6S
	dYNItV7XBd7ZVixAQwsi6p3DkM/Nj9YsAJQ2P8934KGyX/gCuYQWSjSXwkXLzb7zxhXb
	+emogrXjd2uIQO0VfEBK2TJYZsLf5JPeSty375rUfv6ko9LKKERr9dLI+HdvngTP82qT
	HfcfmWw/gXHifG0ahdnb6hl3BgmB7YwWnWdLZoDRs5/wk1o7b+GHGI0YsL6h5pkLFKWh
	B9jw==
Received: by 10.50.47.129 with SMTP id d1mr19146619ign.45.1346864974496;
	Wed, 05 Sep 2012 10:09:34 -0700 (PDT)
Received: from [192.168.7.210] ([206.223.182.18])
	by mx.google.com with ESMTPS id
	hz10sm16671526igc.12.2012.09.05.10.09.32
	(version=TLSv1/SSLv3 cipher=OTHER);
	Wed, 05 Sep 2012 10:09:33 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1278)
From: Andres Lagar-Cavilla <andreslc@gridcentric.ca>
In-Reply-To: <20120905162148.GC11949@phenom.dumpdata.com>
Date: Wed, 5 Sep 2012 13:09:32 -0400
Message-Id: <939BE993-572C-4D83-8F04-E6B9D6EE3E92@gridcentric.ca>
References: <1346331492-15027-1-git-send-email-david.vrabel@citrix.com>
	<1346331492-15027-3-git-send-email-david.vrabel@citrix.com>
	<C989BE9D-E520-4D04-9028-6CE6CC765E76@gridcentric.ca>
	<20120905162148.GC11949@phenom.dumpdata.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
X-Mailer: Apple Mail (2.1278)
X-Gm-Message-State: ALoCoQlz5SxjHQD8iBNhPIUS84snNWt68fNlPrjY5NHHnDr2q78R6EPGvxNRYVsUJuS2nFNb1j2e
Cc: Andres Lagar-Cavilla <andreslc@gridcentric.ca>,
	xen-devel@lists.xensource.com, David Vrabel <david.vrabel@citrix.com>
Subject: Re: [Xen-devel] [PATCH 2/2] xen/privcmd: add PRIVCMD_MMAPBATCH_V2
	ioctl
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Super. To which branch are you applying these now? (n00b question but have to ask)
Andres
On Sep 5, 2012, at 12:21 PM, Konrad Rzeszutek Wilk wrote:

> On Fri, Aug 31, 2012 at 09:59:30AM -0400, Andres Lagar-Cavilla wrote:
>> Re-spin of alternative patch after David's feedback.
>> Thanks
>> Andres
> 
> applied. fixed some whitespace issues.
>> 
>> commit ab351a5cef1797935b083c2f6e72800a8949c515
>> Author: Andres Lagar-Cavilla <andres@lagarcavilla.org>
>> Date:   Thu Aug 30 12:23:33 2012 -0400
>> 
>>    xen/privcmd: add PRIVCMD_MMAPBATCH_V2 ioctl
>> 
>>    PRIVCMD_MMAPBATCH_V2 extends PRIVCMD_MMAPBATCH with an additional
>>    field for reporting the error code for every frame that could not be
>>    mapped.  libxc prefers PRIVCMD_MMAPBATCH_V2 over PRIVCMD_MMAPBATCH.
>> 
>>    Also expand PRIVCMD_MMAPBATCH to return appropriate error-encoding top nibble
>>    in the mfn array.
>> 
>>    Signed-off-by: David Vrabel <david.vrabel@citrix.com>
>>    Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
>> 
>> diff --git a/drivers/xen/privcmd.c b/drivers/xen/privcmd.c
>> index 85226cb..5386f20 100644
>> --- a/drivers/xen/privcmd.c
>> +++ b/drivers/xen/privcmd.c
>> @@ -76,7 +76,7 @@ static void free_page_list(struct list_head *pages)
>>  */
>> static int gather_array(struct list_head *pagelist,
>> 			unsigned nelem, size_t size,
>> -			void __user *data)
>> +			const void __user *data)
>> {
>> 	unsigned pageidx;
>> 	void *pagedata;
>> @@ -246,61 +246,117 @@ struct mmap_batch_state {
>> 	domid_t domain;
>> 	unsigned long va;
>> 	struct vm_area_struct *vma;
>> -	int err;
>> -
>> -	xen_pfn_t __user *user;
>> +	/* A tristate: 
>> +	 *      0 for no errors
>> +	 *      1 if at least one error has happened (and no
>> +	 *          -ENOENT errors have happened)
>> +	 *      -ENOENT if at least 1 -ENOENT has happened.
>> +	 */
>> +	int global_error;
>> +	/* An array for individual errors */
>> +	int *err;
>> +
>> +	/* User-space mfn array to store errors in the second pass for V1. */
>> +	xen_pfn_t __user *user_mfn;
>> };
>> 
>> static int mmap_batch_fn(void *data, void *state)
>> {
>> 	xen_pfn_t *mfnp = data;
>> 	struct mmap_batch_state *st = state;
>> +	int ret;
>> 
>> -	if (xen_remap_domain_mfn_range(st->vma, st->va & PAGE_MASK, *mfnp, 1,
>> -				       st->vma->vm_page_prot, st->domain) < 0) {
>> -		*mfnp |= 0xf0000000U;
>> -		st->err++;
>> +	ret = xen_remap_domain_mfn_range(st->vma, st->va & PAGE_MASK, *mfnp, 1,
>> +					 st->vma->vm_page_prot, st->domain);
>> +
>> +	/* Store error code for second pass. */
>> +	*(st->err++) = ret;
>> +
>> +	/* And see if it affects the global_error. */
>> +	if (ret < 0) {
>> +		if (ret == -ENOENT)
>> +			st->global_error = -ENOENT;
>> +		else {
>> +			/* Record that at least one error has happened. */
>> +			if (st->global_error == 0)
>> +				st->global_error = 1;
>> +		}
>> 	}
>> 	st->va += PAGE_SIZE;
>> 
>> 	return 0;
>> }
>> 
>> -static int mmap_return_errors(void *data, void *state)
>> +static int mmap_return_errors_v1(void *data, void *state)
>> {
>> 	xen_pfn_t *mfnp = data;
>> 	struct mmap_batch_state *st = state;
>> -
>> -	return put_user(*mfnp, st->user++);
>> +	int err = *(st->err++);
>> +
>> +	/*
>> +	 * V1 encodes the error codes in the 32bit top nibble of the 
>> +	 * mfn (with its known limitations vis-a-vis 64 bit callers).
>> +	 */
>> +	*mfnp |= (err == -ENOENT) ?
>> +				PRIVCMD_MMAPBATCH_PAGED_ERROR :
>> +				PRIVCMD_MMAPBATCH_MFN_ERROR;
>> +	return __put_user(*mfnp, st->user_mfn++);
>> }
>> 
>> static struct vm_operations_struct privcmd_vm_ops;
>> 
>> -static long privcmd_ioctl_mmap_batch(void __user *udata)
>> +static long privcmd_ioctl_mmap_batch(void __user *udata, int version)
>> {
>> 	int ret;
>> -	struct privcmd_mmapbatch m;
>> +	struct privcmd_mmapbatch_v2 m;
>> 	struct mm_struct *mm = current->mm;
>> 	struct vm_area_struct *vma;
>> 	unsigned long nr_pages;
>> 	LIST_HEAD(pagelist);
>> +	int *err_array = NULL;
>> 	struct mmap_batch_state state;
>> 
>> 	if (!xen_initial_domain())
>> 		return -EPERM;
>> 
>> -	if (copy_from_user(&m, udata, sizeof(m)))
>> -		return -EFAULT;
>> +	switch (version) {
>> +	case 1:
>> +		if (copy_from_user(&m, udata, sizeof(struct privcmd_mmapbatch)))
>> +			return -EFAULT;
>> +		/* Returns per-frame error in m.arr. */
>> +		m.err = NULL;
>> +		if (!access_ok(VERIFY_WRITE, m.arr, m.num * sizeof(*m.arr)))
>> +			return -EFAULT;
>> +		break;
>> +	case 2:
>> +		if (copy_from_user(&m, udata, sizeof(struct privcmd_mmapbatch_v2)))
>> +			return -EFAULT;
>> +		/* Returns per-frame error code in m.err. */
>> +		if (!access_ok(VERIFY_WRITE, m.err, m.num * (sizeof(*m.err))))
>> +			return -EFAULT;
>> +		break;
>> +	default:
>> +		return -EINVAL;
>> +	}
>> 
>> 	nr_pages = m.num;
>> 	if ((m.num <= 0) || (nr_pages > (LONG_MAX >> PAGE_SHIFT)))
>> 		return -EINVAL;
>> 
>> -	ret = gather_array(&pagelist, m.num, sizeof(xen_pfn_t),
>> -			   m.arr);
>> +	ret = gather_array(&pagelist, m.num, sizeof(xen_pfn_t), m.arr);
>> +
>> +	if (ret)
>> +		goto out;
>> +	if (list_empty(&pagelist)) {
>> +		ret = -EINVAL;
>> +		goto out;
>> +    }
>> 
>> -	if (ret || list_empty(&pagelist))
>> +	err_array = kcalloc(m.num, sizeof(int), GFP_KERNEL);
>> +	if (err_array == NULL) {
>> +		ret = -ENOMEM;
>> 		goto out;
>> +	}
>> 
>> 	down_write(&mm->mmap_sem);
>> 
>> @@ -315,24 +371,34 @@ static long privcmd_ioctl_mmap_batch(void __user *udata)
>> 		goto out;
>> 	}
>> 
>> -	state.domain = m.dom;
>> -	state.vma = vma;
>> -	state.va = m.addr;
>> -	state.err = 0;
>> +	state.domain        = m.dom;
>> +	state.vma           = vma;
>> +	state.va            = m.addr;
>> +	state.global_error  = 0;
>> +	state.err           = err_array;
>> 
>> -	ret = traverse_pages(m.num, sizeof(xen_pfn_t),
>> -			     &pagelist, mmap_batch_fn, &state);
>> +	/* mmap_batch_fn guarantees ret == 0 */
>> +	BUG_ON(traverse_pages(m.num, sizeof(xen_pfn_t),
>> +			     &pagelist, mmap_batch_fn, &state));
>> 
>> 	up_write(&mm->mmap_sem);
>> 
>> -	if (state.err > 0) {
>> -		state.user = m.arr;
>> +	if (state.global_error && (version == 1)) {
>> +		/* Write back errors in second pass. */
>> +		state.user_mfn = (xen_pfn_t *)m.arr;
>> +		state.err      = err_array;
>> 		ret = traverse_pages(m.num, sizeof(xen_pfn_t),
>> -			       &pagelist,
>> -			       mmap_return_errors, &state);
>> -	}
>> +					 &pagelist, mmap_return_errors_v1, &state);
>> +	} else
>> +		ret = __copy_to_user(m.err, err_array, m.num * sizeof(int));
>> +
>> +    /* If we have not had any EFAULT-like global errors then set the global
>> +     * error to -ENOENT if necessary. */
>> +    if ((ret == 0) && (state.global_error == -ENOENT))
>> +        ret = -ENOENT;
>> 
>> out:
>> +	kfree(err_array);
>> 	free_page_list(&pagelist);
>> 
>> 	return ret;
>> @@ -354,7 +420,11 @@ static long privcmd_ioctl(struct file *file,
>> 		break;
>> 
>> 	case IOCTL_PRIVCMD_MMAPBATCH:
>> -		ret = privcmd_ioctl_mmap_batch(udata);
>> +		ret = privcmd_ioctl_mmap_batch(udata, 1);
>> +		break;
>> +
>> +	case IOCTL_PRIVCMD_MMAPBATCH_V2:
>> +		ret = privcmd_ioctl_mmap_batch(udata, 2);
>> 		break;
>> 
>> 	default:
>> diff --git a/include/xen/privcmd.h b/include/xen/privcmd.h
>> index 45c1aa1..a853168 100644
>> --- a/include/xen/privcmd.h
>> +++ b/include/xen/privcmd.h
>> @@ -58,13 +58,33 @@ struct privcmd_mmapbatch {
>> 	int num;     /* number of pages to populate */
>> 	domid_t dom; /* target domain */
>> 	__u64 addr;  /* virtual address */
>> -	xen_pfn_t __user *arr; /* array of mfns - top nibble set on err */
>> +	xen_pfn_t __user *arr; /* array of mfns - or'd with
>> +				  PRIVCMD_MMAPBATCH_*_ERROR on err */
>> +};
>> +
>> +#define PRIVCMD_MMAPBATCH_MFN_ERROR     0xf0000000U
>> +#define PRIVCMD_MMAPBATCH_PAGED_ERROR   0x80000000U
>> +
>> +struct privcmd_mmapbatch_v2 {
>> +	unsigned int num; /* number of pages to populate */
>> +	domid_t dom;      /* target domain */
>> +	__u64 addr;       /* virtual address */
>> +	const xen_pfn_t __user *arr; /* array of mfns */
>> +	int __user *err;  /* array of error codes */
>> };
>> 
>> /*
>>  * @cmd: IOCTL_PRIVCMD_HYPERCALL
>>  * @arg: &privcmd_hypercall_t
>>  * Return: Value returned from execution of the specified hypercall.
>> + *
>> + * @cmd: IOCTL_PRIVCMD_MMAPBATCH_V2
>> + * @arg: &struct privcmd_mmapbatch_v2
>> + * Return: 0 on success (i.e., arg->err contains valid error codes for
>> + * each frame).  On an error other than a failed frame remap, -1 is
>> + * returned and errno is set to EINVAL, EFAULT etc.  As an exception,
>> + * if the operation was otherwise successful but any frame failed with
>> + * -ENOENT, then -1 is returned and errno is set to ENOENT.
>>  */
>> #define IOCTL_PRIVCMD_HYPERCALL					\
>> 	_IOC(_IOC_NONE, 'P', 0, sizeof(struct privcmd_hypercall))
>> @@ -72,5 +92,7 @@ struct privcmd_mmapbatch {
>> 	_IOC(_IOC_NONE, 'P', 2, sizeof(struct privcmd_mmap))
>> #define IOCTL_PRIVCMD_MMAPBATCH					\
>> 	_IOC(_IOC_NONE, 'P', 3, sizeof(struct privcmd_mmapbatch))
>> +#define IOCTL_PRIVCMD_MMAPBATCH_V2				\
>> +	_IOC(_IOC_NONE, 'P', 4, sizeof(struct privcmd_mmapbatch_v2))
>> 
>> #endif /* __LINUX_PUBLIC_PRIVCMD_H__ */
>> 
>> On Aug 30, 2012, at 8:58 AM, David Vrabel wrote:
>> 
>>> From: David Vrabel <david.vrabel@citrix.com>
>>> 
>>> PRIVCMD_MMAPBATCH_V2 extends PRIVCMD_MMAPBATCH with an additional
>>> field for reporting the error code for every frame that could not be
>>> mapped.  libxc prefers PRIVCMD_MMAPBATCH_V2 over PRIVCMD_MMAPBATCH.
>>> 
>>> Signed-off-by: David Vrabel <david.vrabel@citrix.com>
>>> ---
>>> drivers/xen/privcmd.c |   99 +++++++++++++++++++++++++++++++++++++++---------
>>> include/xen/privcmd.h |   23 +++++++++++-
>>> 2 files changed, 102 insertions(+), 20 deletions(-)
>>> 
>>> diff --git a/drivers/xen/privcmd.c b/drivers/xen/privcmd.c
>>> index ccee0f1..c0e89e7 100644
>>> --- a/drivers/xen/privcmd.c
>>> +++ b/drivers/xen/privcmd.c
>>> @@ -76,7 +76,7 @@ static void free_page_list(struct list_head *pages)
>>> */
>>> static int gather_array(struct list_head *pagelist,
>>> 			unsigned nelem, size_t size,
>>> -			void __user *data)
>>> +			const void __user *data)
>>> {
>>> 	unsigned pageidx;
>>> 	void *pagedata;
>>> @@ -248,18 +248,37 @@ struct mmap_batch_state {
>>> 	struct vm_area_struct *vma;
>>> 	int err;
>>> 
>>> -	xen_pfn_t __user *user;
>>> +	xen_pfn_t __user *user_mfn;
>>> +	int __user *user_err;
>>> };
>>> 
>>> static int mmap_batch_fn(void *data, void *state)
>>> {
>>> 	xen_pfn_t *mfnp = data;
>>> 	struct mmap_batch_state *st = state;
>>> +	int ret;
>>> 
>>> -	if (xen_remap_domain_mfn_range(st->vma, st->va & PAGE_MASK, *mfnp, 1,
>>> -				       st->vma->vm_page_prot, st->domain) < 0) {
>>> -		*mfnp |= 0xf0000000U;
>>> -		st->err++;
>>> +	ret = xen_remap_domain_mfn_range(st->vma, st->va & PAGE_MASK, *mfnp, 1,
>>> +					 st->vma->vm_page_prot, st->domain);
>>> +	if (ret < 0) {
>>> +		/*
>>> +		 * Error reporting is a mess but userspace relies on
>>> +		 * it behaving this way.
>>> +		 *
>>> +		 * V2 needs to a) return the result of each frame's
>>> +		 * remap; and b) return -ENOENT if any frame failed
>>> +		 * with -ENOENT.
>>> +		 *
>>> +		 * In this first pass the error code is saved by
>>> +		 * overwriting the mfn and an error is indicated in
>>> +		 * st->err.
>>> +		 *
>>> +		 * The second pass by mmap_return_errors() will write
>>> +		 * the error codes to user space and get the right
>>> +		 * ioctl return value.
>>> +		 */
>>> +		*(int *)mfnp = ret;
>>> +		st->err = ret;
>>> 	}
>>> 	st->va += PAGE_SIZE;
>>> 
>>> @@ -270,16 +289,33 @@ static int mmap_return_errors(void *data, void *state)
>>> {
>>> 	xen_pfn_t *mfnp = data;
>>> 	struct mmap_batch_state *st = state;
>>> +	int ret;
>>> +
>>> +	if (st->user_err) {
>>> +		int err = *(int *)mfnp;
>>> +
>>> +		if (err == -ENOENT)
>>> +			st->err = err;
>>> 
>>> -	return put_user(*mfnp, st->user++);
>>> +		return __put_user(err, st->user_err++);
>>> +	} else {
>>> +		xen_pfn_t mfn;
>>> +
>>> +		ret = __get_user(mfn, st->user_mfn);
>>> +		if (ret < 0)
>>> +			return ret;
>>> +
>>> +		mfn |= PRIVCMD_MMAPBATCH_MFN_ERROR;
>>> +		return __put_user(mfn, st->user_mfn++);
>>> +	}
>>> }
>>> 
>>> static struct vm_operations_struct privcmd_vm_ops;
>>> 
>>> -static long privcmd_ioctl_mmap_batch(void __user *udata)
>>> +static long privcmd_ioctl_mmap_batch(void __user *udata, int version)
>>> {
>>> 	int ret;
>>> -	struct privcmd_mmapbatch m;
>>> +	struct privcmd_mmapbatch_v2 m;
>>> 	struct mm_struct *mm = current->mm;
>>> 	struct vm_area_struct *vma;
>>> 	unsigned long nr_pages;
>>> @@ -289,15 +325,31 @@ static long privcmd_ioctl_mmap_batch(void __user *udata)
>>> 	if (!xen_initial_domain())
>>> 		return -EPERM;
>>> 
>>> -	if (copy_from_user(&m, udata, sizeof(m)))
>>> -		return -EFAULT;
>>> +	switch (version) {
>>> +	case 1:
>>> +		if (copy_from_user(&m, udata, sizeof(struct privcmd_mmapbatch)))
>>> +			return -EFAULT;
>>> +		/* Returns per-frame error in m.arr. */
>>> +		m.err = NULL;
>>> +		if (!access_ok(VERIFY_WRITE, m.arr, m.num * sizeof(*m.arr)))
>>> +			return -EFAULT;
>>> +		break;
>>> +	case 2:
>>> +		if (copy_from_user(&m, udata, sizeof(struct privcmd_mmapbatch_v2)))
>>> +			return -EFAULT;
>>> +		/* Returns per-frame error code in m.err. */
>>> +		if (!access_ok(VERIFY_WRITE, m.err, m.num * (sizeof(*m.err))))
>>> +			return -EFAULT;
>>> +		break;
>>> +	default:
>>> +		return -EINVAL;
>>> +	}
>>> 
>>> 	nr_pages = m.num;
>>> 	if ((m.num <= 0) || (nr_pages > (LONG_MAX >> PAGE_SHIFT)))
>>> 		return -EINVAL;
>>> 
>>> -	ret = gather_array(&pagelist, m.num, sizeof(xen_pfn_t),
>>> -			   m.arr);
>>> +	ret = gather_array(&pagelist, m.num, sizeof(xen_pfn_t), m.arr);
>>> 
>>> 	if (ret || list_empty(&pagelist))
>>> 		goto out;
>>> @@ -325,12 +377,17 @@ static long privcmd_ioctl_mmap_batch(void __user *udata)
>>> 
>>> 	up_write(&mm->mmap_sem);
>>> 
>>> -	if (state.err > 0) {
>>> -		state.user = m.arr;
>>> +	if (state.err) {
>>> +		state.err = 0;
>>> +		state.user_mfn = (xen_pfn_t *)m.arr;
>>> +		state.user_err = m.err;
>>> 		ret = traverse_pages(m.num, sizeof(xen_pfn_t),
>>> -			       &pagelist,
>>> -			       mmap_return_errors, &state);
>>> -	}
>>> +				     &pagelist,
>>> +				     mmap_return_errors, &state);
>>> +		if (ret >= 0)
>>> +			ret = state.err;
>>> +	} else if (m.err)
>>> +		__clear_user(m.err, m.num * sizeof(*m.err));
>>> 
>>> out:
>>> 	free_page_list(&pagelist);
>>> @@ -354,7 +411,11 @@ static long privcmd_ioctl(struct file *file,
>>> 		break;
>>> 
>>> 	case IOCTL_PRIVCMD_MMAPBATCH:
>>> -		ret = privcmd_ioctl_mmap_batch(udata);
>>> +		ret = privcmd_ioctl_mmap_batch(udata, 1);
>>> +		break;
>>> +
>>> +	case IOCTL_PRIVCMD_MMAPBATCH_V2:
>>> +		ret = privcmd_ioctl_mmap_batch(udata, 2);
>>> 		break;
>>> 
>>> 	default:
>>> diff --git a/include/xen/privcmd.h b/include/xen/privcmd.h
>>> index 17857fb..f60d75c 100644
>>> --- a/include/xen/privcmd.h
>>> +++ b/include/xen/privcmd.h
>>> @@ -59,13 +59,32 @@ struct privcmd_mmapbatch {
>>> 	int num;     /* number of pages to populate */
>>> 	domid_t dom; /* target domain */
>>> 	__u64 addr;  /* virtual address */
>>> -	xen_pfn_t __user *arr; /* array of mfns - top nibble set on err */
>>> +	xen_pfn_t __user *arr; /* array of mfns - or'd with
>>> +				  PRIVCMD_MMAPBATCH_MFN_ERROR on err */
>>> +};
>>> +
>>> +#define PRIVCMD_MMAPBATCH_MFN_ERROR 0xf0000000U
>>> +
>>> +struct privcmd_mmapbatch_v2 {
>>> +	unsigned int num; /* number of pages to populate */
>>> +	domid_t dom;      /* target domain */
>>> +	__u64 addr;       /* virtual address */
>>> +	const xen_pfn_t __user *arr; /* array of mfns */
>>> +	int __user *err;  /* array of error codes */
>>> };
>>> 
>>> /*
>>> * @cmd: IOCTL_PRIVCMD_HYPERCALL
>>> * @arg: &privcmd_hypercall_t
>>> * Return: Value returned from execution of the specified hypercall.
>>> + *
>>> + * @cmd: IOCTL_PRIVCMD_MMAPBATCH_V2
>>> + * @arg: &struct privcmd_mmapbatch_v2
>>> + * Return: 0 on success (i.e., arg->err contains valid error codes for
>>> + * each frame).  On an error other than a failed frame remap, -1 is
>>> + * returned and errno is set to EINVAL, EFAULT etc.  As an exception,
>>> + * if the operation was otherwise successful but any frame failed with
>>> + * -ENOENT, then -1 is returned and errno is set to ENOENT.
>>> */
>>> #define IOCTL_PRIVCMD_HYPERCALL					\
>>> 	_IOC(_IOC_NONE, 'P', 0, sizeof(struct privcmd_hypercall))
>>> @@ -73,5 +92,7 @@ struct privcmd_mmapbatch {
>>> 	_IOC(_IOC_NONE, 'P', 2, sizeof(struct privcmd_mmap))
>>> #define IOCTL_PRIVCMD_MMAPBATCH					\
>>> 	_IOC(_IOC_NONE, 'P', 3, sizeof(struct privcmd_mmapbatch))
>>> +#define IOCTL_PRIVCMD_MMAPBATCH_V2				\
>>> +	_IOC(_IOC_NONE, 'P', 4, sizeof(struct privcmd_mmapbatch_v2))
>>> 
>>> #endif /* __LINUX_PUBLIC_PRIVCMD_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 Wed Sep 05 17:09:54 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Sep 2012 17: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 1T9J6h-0007fW-QI; Wed, 05 Sep 2012 17:09:39 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andreslc@gridcentric.ca>) id 1T9J6g-0007fN-5W
	for xen-devel@lists.xensource.com; Wed, 05 Sep 2012 17:09:38 +0000
Received: from [85.158.143.99:58075] by server-2.bemta-4.messagelabs.com id
	B9/55-21239-15787405; Wed, 05 Sep 2012 17:09:37 +0000
X-Env-Sender: andreslc@gridcentric.ca
X-Msg-Ref: server-3.tower-216.messagelabs.com!1346864974!28149743!1
X-Originating-IP: [209.85.223.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18507 invoked from network); 5 Sep 2012 17:09:36 -0000
Received: from mail-ie0-f171.google.com (HELO mail-ie0-f171.google.com)
	(209.85.223.171)
	by server-3.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Sep 2012 17:09:36 -0000
Received: by ieje14 with SMTP id e14so1916775iej.30
	for <xen-devel@lists.xensource.com>;
	Wed, 05 Sep 2012 10:09:34 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=subject:mime-version:content-type:from:in-reply-to:date:cc
	:content-transfer-encoding:message-id:references:to:x-mailer
	:x-gm-message-state;
	bh=MlQu0+ve5HpKPlI4fNUxBrbFZfqFldMS9yiGUDN4/os=;
	b=ciJ6gnCXLSpeBWiVRyB2qhSpetZ7c4NHnjzq3TIcShEXRIXaL/La29D2YniqId7kFf
	uIsbUuyl5LXk2uXxWWmeDe0Ib3y1iu5iOGdt+lB03EmRHYROl4ca1uMzfi8gXVNdZF6S
	dYNItV7XBd7ZVixAQwsi6p3DkM/Nj9YsAJQ2P8934KGyX/gCuYQWSjSXwkXLzb7zxhXb
	+emogrXjd2uIQO0VfEBK2TJYZsLf5JPeSty375rUfv6ko9LKKERr9dLI+HdvngTP82qT
	HfcfmWw/gXHifG0ahdnb6hl3BgmB7YwWnWdLZoDRs5/wk1o7b+GHGI0YsL6h5pkLFKWh
	B9jw==
Received: by 10.50.47.129 with SMTP id d1mr19146619ign.45.1346864974496;
	Wed, 05 Sep 2012 10:09:34 -0700 (PDT)
Received: from [192.168.7.210] ([206.223.182.18])
	by mx.google.com with ESMTPS id
	hz10sm16671526igc.12.2012.09.05.10.09.32
	(version=TLSv1/SSLv3 cipher=OTHER);
	Wed, 05 Sep 2012 10:09:33 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1278)
From: Andres Lagar-Cavilla <andreslc@gridcentric.ca>
In-Reply-To: <20120905162148.GC11949@phenom.dumpdata.com>
Date: Wed, 5 Sep 2012 13:09:32 -0400
Message-Id: <939BE993-572C-4D83-8F04-E6B9D6EE3E92@gridcentric.ca>
References: <1346331492-15027-1-git-send-email-david.vrabel@citrix.com>
	<1346331492-15027-3-git-send-email-david.vrabel@citrix.com>
	<C989BE9D-E520-4D04-9028-6CE6CC765E76@gridcentric.ca>
	<20120905162148.GC11949@phenom.dumpdata.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
X-Mailer: Apple Mail (2.1278)
X-Gm-Message-State: ALoCoQlz5SxjHQD8iBNhPIUS84snNWt68fNlPrjY5NHHnDr2q78R6EPGvxNRYVsUJuS2nFNb1j2e
Cc: Andres Lagar-Cavilla <andreslc@gridcentric.ca>,
	xen-devel@lists.xensource.com, David Vrabel <david.vrabel@citrix.com>
Subject: Re: [Xen-devel] [PATCH 2/2] xen/privcmd: add PRIVCMD_MMAPBATCH_V2
	ioctl
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Super. To which branch are you applying these now? (n00b question but have to ask)
Andres
On Sep 5, 2012, at 12:21 PM, Konrad Rzeszutek Wilk wrote:

> On Fri, Aug 31, 2012 at 09:59:30AM -0400, Andres Lagar-Cavilla wrote:
>> Re-spin of alternative patch after David's feedback.
>> Thanks
>> Andres
> 
> applied. fixed some whitespace issues.
>> 
>> commit ab351a5cef1797935b083c2f6e72800a8949c515
>> Author: Andres Lagar-Cavilla <andres@lagarcavilla.org>
>> Date:   Thu Aug 30 12:23:33 2012 -0400
>> 
>>    xen/privcmd: add PRIVCMD_MMAPBATCH_V2 ioctl
>> 
>>    PRIVCMD_MMAPBATCH_V2 extends PRIVCMD_MMAPBATCH with an additional
>>    field for reporting the error code for every frame that could not be
>>    mapped.  libxc prefers PRIVCMD_MMAPBATCH_V2 over PRIVCMD_MMAPBATCH.
>> 
>>    Also expand PRIVCMD_MMAPBATCH to return appropriate error-encoding top nibble
>>    in the mfn array.
>> 
>>    Signed-off-by: David Vrabel <david.vrabel@citrix.com>
>>    Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
>> 
>> diff --git a/drivers/xen/privcmd.c b/drivers/xen/privcmd.c
>> index 85226cb..5386f20 100644
>> --- a/drivers/xen/privcmd.c
>> +++ b/drivers/xen/privcmd.c
>> @@ -76,7 +76,7 @@ static void free_page_list(struct list_head *pages)
>>  */
>> static int gather_array(struct list_head *pagelist,
>> 			unsigned nelem, size_t size,
>> -			void __user *data)
>> +			const void __user *data)
>> {
>> 	unsigned pageidx;
>> 	void *pagedata;
>> @@ -246,61 +246,117 @@ struct mmap_batch_state {
>> 	domid_t domain;
>> 	unsigned long va;
>> 	struct vm_area_struct *vma;
>> -	int err;
>> -
>> -	xen_pfn_t __user *user;
>> +	/* A tristate: 
>> +	 *      0 for no errors
>> +	 *      1 if at least one error has happened (and no
>> +	 *          -ENOENT errors have happened)
>> +	 *      -ENOENT if at least 1 -ENOENT has happened.
>> +	 */
>> +	int global_error;
>> +	/* An array for individual errors */
>> +	int *err;
>> +
>> +	/* User-space mfn array to store errors in the second pass for V1. */
>> +	xen_pfn_t __user *user_mfn;
>> };
>> 
>> static int mmap_batch_fn(void *data, void *state)
>> {
>> 	xen_pfn_t *mfnp = data;
>> 	struct mmap_batch_state *st = state;
>> +	int ret;
>> 
>> -	if (xen_remap_domain_mfn_range(st->vma, st->va & PAGE_MASK, *mfnp, 1,
>> -				       st->vma->vm_page_prot, st->domain) < 0) {
>> -		*mfnp |= 0xf0000000U;
>> -		st->err++;
>> +	ret = xen_remap_domain_mfn_range(st->vma, st->va & PAGE_MASK, *mfnp, 1,
>> +					 st->vma->vm_page_prot, st->domain);
>> +
>> +	/* Store error code for second pass. */
>> +	*(st->err++) = ret;
>> +
>> +	/* And see if it affects the global_error. */
>> +	if (ret < 0) {
>> +		if (ret == -ENOENT)
>> +			st->global_error = -ENOENT;
>> +		else {
>> +			/* Record that at least one error has happened. */
>> +			if (st->global_error == 0)
>> +				st->global_error = 1;
>> +		}
>> 	}
>> 	st->va += PAGE_SIZE;
>> 
>> 	return 0;
>> }
>> 
>> -static int mmap_return_errors(void *data, void *state)
>> +static int mmap_return_errors_v1(void *data, void *state)
>> {
>> 	xen_pfn_t *mfnp = data;
>> 	struct mmap_batch_state *st = state;
>> -
>> -	return put_user(*mfnp, st->user++);
>> +	int err = *(st->err++);
>> +
>> +	/*
>> +	 * V1 encodes the error codes in the 32bit top nibble of the 
>> +	 * mfn (with its known limitations vis-a-vis 64 bit callers).
>> +	 */
>> +	*mfnp |= (err == -ENOENT) ?
>> +				PRIVCMD_MMAPBATCH_PAGED_ERROR :
>> +				PRIVCMD_MMAPBATCH_MFN_ERROR;
>> +	return __put_user(*mfnp, st->user_mfn++);
>> }
>> 
>> static struct vm_operations_struct privcmd_vm_ops;
>> 
>> -static long privcmd_ioctl_mmap_batch(void __user *udata)
>> +static long privcmd_ioctl_mmap_batch(void __user *udata, int version)
>> {
>> 	int ret;
>> -	struct privcmd_mmapbatch m;
>> +	struct privcmd_mmapbatch_v2 m;
>> 	struct mm_struct *mm = current->mm;
>> 	struct vm_area_struct *vma;
>> 	unsigned long nr_pages;
>> 	LIST_HEAD(pagelist);
>> +	int *err_array = NULL;
>> 	struct mmap_batch_state state;
>> 
>> 	if (!xen_initial_domain())
>> 		return -EPERM;
>> 
>> -	if (copy_from_user(&m, udata, sizeof(m)))
>> -		return -EFAULT;
>> +	switch (version) {
>> +	case 1:
>> +		if (copy_from_user(&m, udata, sizeof(struct privcmd_mmapbatch)))
>> +			return -EFAULT;
>> +		/* Returns per-frame error in m.arr. */
>> +		m.err = NULL;
>> +		if (!access_ok(VERIFY_WRITE, m.arr, m.num * sizeof(*m.arr)))
>> +			return -EFAULT;
>> +		break;
>> +	case 2:
>> +		if (copy_from_user(&m, udata, sizeof(struct privcmd_mmapbatch_v2)))
>> +			return -EFAULT;
>> +		/* Returns per-frame error code in m.err. */
>> +		if (!access_ok(VERIFY_WRITE, m.err, m.num * (sizeof(*m.err))))
>> +			return -EFAULT;
>> +		break;
>> +	default:
>> +		return -EINVAL;
>> +	}
>> 
>> 	nr_pages = m.num;
>> 	if ((m.num <= 0) || (nr_pages > (LONG_MAX >> PAGE_SHIFT)))
>> 		return -EINVAL;
>> 
>> -	ret = gather_array(&pagelist, m.num, sizeof(xen_pfn_t),
>> -			   m.arr);
>> +	ret = gather_array(&pagelist, m.num, sizeof(xen_pfn_t), m.arr);
>> +
>> +	if (ret)
>> +		goto out;
>> +	if (list_empty(&pagelist)) {
>> +		ret = -EINVAL;
>> +		goto out;
>> +    }
>> 
>> -	if (ret || list_empty(&pagelist))
>> +	err_array = kcalloc(m.num, sizeof(int), GFP_KERNEL);
>> +	if (err_array == NULL) {
>> +		ret = -ENOMEM;
>> 		goto out;
>> +	}
>> 
>> 	down_write(&mm->mmap_sem);
>> 
>> @@ -315,24 +371,34 @@ static long privcmd_ioctl_mmap_batch(void __user *udata)
>> 		goto out;
>> 	}
>> 
>> -	state.domain = m.dom;
>> -	state.vma = vma;
>> -	state.va = m.addr;
>> -	state.err = 0;
>> +	state.domain        = m.dom;
>> +	state.vma           = vma;
>> +	state.va            = m.addr;
>> +	state.global_error  = 0;
>> +	state.err           = err_array;
>> 
>> -	ret = traverse_pages(m.num, sizeof(xen_pfn_t),
>> -			     &pagelist, mmap_batch_fn, &state);
>> +	/* mmap_batch_fn guarantees ret == 0 */
>> +	BUG_ON(traverse_pages(m.num, sizeof(xen_pfn_t),
>> +			     &pagelist, mmap_batch_fn, &state));
>> 
>> 	up_write(&mm->mmap_sem);
>> 
>> -	if (state.err > 0) {
>> -		state.user = m.arr;
>> +	if (state.global_error && (version == 1)) {
>> +		/* Write back errors in second pass. */
>> +		state.user_mfn = (xen_pfn_t *)m.arr;
>> +		state.err      = err_array;
>> 		ret = traverse_pages(m.num, sizeof(xen_pfn_t),
>> -			       &pagelist,
>> -			       mmap_return_errors, &state);
>> -	}
>> +					 &pagelist, mmap_return_errors_v1, &state);
>> +	} else
>> +		ret = __copy_to_user(m.err, err_array, m.num * sizeof(int));
>> +
>> +    /* If we have not had any EFAULT-like global errors then set the global
>> +     * error to -ENOENT if necessary. */
>> +    if ((ret == 0) && (state.global_error == -ENOENT))
>> +        ret = -ENOENT;
>> 
>> out:
>> +	kfree(err_array);
>> 	free_page_list(&pagelist);
>> 
>> 	return ret;
>> @@ -354,7 +420,11 @@ static long privcmd_ioctl(struct file *file,
>> 		break;
>> 
>> 	case IOCTL_PRIVCMD_MMAPBATCH:
>> -		ret = privcmd_ioctl_mmap_batch(udata);
>> +		ret = privcmd_ioctl_mmap_batch(udata, 1);
>> +		break;
>> +
>> +	case IOCTL_PRIVCMD_MMAPBATCH_V2:
>> +		ret = privcmd_ioctl_mmap_batch(udata, 2);
>> 		break;
>> 
>> 	default:
>> diff --git a/include/xen/privcmd.h b/include/xen/privcmd.h
>> index 45c1aa1..a853168 100644
>> --- a/include/xen/privcmd.h
>> +++ b/include/xen/privcmd.h
>> @@ -58,13 +58,33 @@ struct privcmd_mmapbatch {
>> 	int num;     /* number of pages to populate */
>> 	domid_t dom; /* target domain */
>> 	__u64 addr;  /* virtual address */
>> -	xen_pfn_t __user *arr; /* array of mfns - top nibble set on err */
>> +	xen_pfn_t __user *arr; /* array of mfns - or'd with
>> +				  PRIVCMD_MMAPBATCH_*_ERROR on err */
>> +};
>> +
>> +#define PRIVCMD_MMAPBATCH_MFN_ERROR     0xf0000000U
>> +#define PRIVCMD_MMAPBATCH_PAGED_ERROR   0x80000000U
>> +
>> +struct privcmd_mmapbatch_v2 {
>> +	unsigned int num; /* number of pages to populate */
>> +	domid_t dom;      /* target domain */
>> +	__u64 addr;       /* virtual address */
>> +	const xen_pfn_t __user *arr; /* array of mfns */
>> +	int __user *err;  /* array of error codes */
>> };
>> 
>> /*
>>  * @cmd: IOCTL_PRIVCMD_HYPERCALL
>>  * @arg: &privcmd_hypercall_t
>>  * Return: Value returned from execution of the specified hypercall.
>> + *
>> + * @cmd: IOCTL_PRIVCMD_MMAPBATCH_V2
>> + * @arg: &struct privcmd_mmapbatch_v2
>> + * Return: 0 on success (i.e., arg->err contains valid error codes for
>> + * each frame).  On an error other than a failed frame remap, -1 is
>> + * returned and errno is set to EINVAL, EFAULT etc.  As an exception,
>> + * if the operation was otherwise successful but any frame failed with
>> + * -ENOENT, then -1 is returned and errno is set to ENOENT.
>>  */
>> #define IOCTL_PRIVCMD_HYPERCALL					\
>> 	_IOC(_IOC_NONE, 'P', 0, sizeof(struct privcmd_hypercall))
>> @@ -72,5 +92,7 @@ struct privcmd_mmapbatch {
>> 	_IOC(_IOC_NONE, 'P', 2, sizeof(struct privcmd_mmap))
>> #define IOCTL_PRIVCMD_MMAPBATCH					\
>> 	_IOC(_IOC_NONE, 'P', 3, sizeof(struct privcmd_mmapbatch))
>> +#define IOCTL_PRIVCMD_MMAPBATCH_V2				\
>> +	_IOC(_IOC_NONE, 'P', 4, sizeof(struct privcmd_mmapbatch_v2))
>> 
>> #endif /* __LINUX_PUBLIC_PRIVCMD_H__ */
>> 
>> On Aug 30, 2012, at 8:58 AM, David Vrabel wrote:
>> 
>>> From: David Vrabel <david.vrabel@citrix.com>
>>> 
>>> PRIVCMD_MMAPBATCH_V2 extends PRIVCMD_MMAPBATCH with an additional
>>> field for reporting the error code for every frame that could not be
>>> mapped.  libxc prefers PRIVCMD_MMAPBATCH_V2 over PRIVCMD_MMAPBATCH.
>>> 
>>> Signed-off-by: David Vrabel <david.vrabel@citrix.com>
>>> ---
>>> drivers/xen/privcmd.c |   99 +++++++++++++++++++++++++++++++++++++++---------
>>> include/xen/privcmd.h |   23 +++++++++++-
>>> 2 files changed, 102 insertions(+), 20 deletions(-)
>>> 
>>> diff --git a/drivers/xen/privcmd.c b/drivers/xen/privcmd.c
>>> index ccee0f1..c0e89e7 100644
>>> --- a/drivers/xen/privcmd.c
>>> +++ b/drivers/xen/privcmd.c
>>> @@ -76,7 +76,7 @@ static void free_page_list(struct list_head *pages)
>>> */
>>> static int gather_array(struct list_head *pagelist,
>>> 			unsigned nelem, size_t size,
>>> -			void __user *data)
>>> +			const void __user *data)
>>> {
>>> 	unsigned pageidx;
>>> 	void *pagedata;
>>> @@ -248,18 +248,37 @@ struct mmap_batch_state {
>>> 	struct vm_area_struct *vma;
>>> 	int err;
>>> 
>>> -	xen_pfn_t __user *user;
>>> +	xen_pfn_t __user *user_mfn;
>>> +	int __user *user_err;
>>> };
>>> 
>>> static int mmap_batch_fn(void *data, void *state)
>>> {
>>> 	xen_pfn_t *mfnp = data;
>>> 	struct mmap_batch_state *st = state;
>>> +	int ret;
>>> 
>>> -	if (xen_remap_domain_mfn_range(st->vma, st->va & PAGE_MASK, *mfnp, 1,
>>> -				       st->vma->vm_page_prot, st->domain) < 0) {
>>> -		*mfnp |= 0xf0000000U;
>>> -		st->err++;
>>> +	ret = xen_remap_domain_mfn_range(st->vma, st->va & PAGE_MASK, *mfnp, 1,
>>> +					 st->vma->vm_page_prot, st->domain);
>>> +	if (ret < 0) {
>>> +		/*
>>> +		 * Error reporting is a mess but userspace relies on
>>> +		 * it behaving this way.
>>> +		 *
>>> +		 * V2 needs to a) return the result of each frame's
>>> +		 * remap; and b) return -ENOENT if any frame failed
>>> +		 * with -ENOENT.
>>> +		 *
>>> +		 * In this first pass the error code is saved by
>>> +		 * overwriting the mfn and an error is indicated in
>>> +		 * st->err.
>>> +		 *
>>> +		 * The second pass by mmap_return_errors() will write
>>> +		 * the error codes to user space and get the right
>>> +		 * ioctl return value.
>>> +		 */
>>> +		*(int *)mfnp = ret;
>>> +		st->err = ret;
>>> 	}
>>> 	st->va += PAGE_SIZE;
>>> 
>>> @@ -270,16 +289,33 @@ static int mmap_return_errors(void *data, void *state)
>>> {
>>> 	xen_pfn_t *mfnp = data;
>>> 	struct mmap_batch_state *st = state;
>>> +	int ret;
>>> +
>>> +	if (st->user_err) {
>>> +		int err = *(int *)mfnp;
>>> +
>>> +		if (err == -ENOENT)
>>> +			st->err = err;
>>> 
>>> -	return put_user(*mfnp, st->user++);
>>> +		return __put_user(err, st->user_err++);
>>> +	} else {
>>> +		xen_pfn_t mfn;
>>> +
>>> +		ret = __get_user(mfn, st->user_mfn);
>>> +		if (ret < 0)
>>> +			return ret;
>>> +
>>> +		mfn |= PRIVCMD_MMAPBATCH_MFN_ERROR;
>>> +		return __put_user(mfn, st->user_mfn++);
>>> +	}
>>> }
>>> 
>>> static struct vm_operations_struct privcmd_vm_ops;
>>> 
>>> -static long privcmd_ioctl_mmap_batch(void __user *udata)
>>> +static long privcmd_ioctl_mmap_batch(void __user *udata, int version)
>>> {
>>> 	int ret;
>>> -	struct privcmd_mmapbatch m;
>>> +	struct privcmd_mmapbatch_v2 m;
>>> 	struct mm_struct *mm = current->mm;
>>> 	struct vm_area_struct *vma;
>>> 	unsigned long nr_pages;
>>> @@ -289,15 +325,31 @@ static long privcmd_ioctl_mmap_batch(void __user *udata)
>>> 	if (!xen_initial_domain())
>>> 		return -EPERM;
>>> 
>>> -	if (copy_from_user(&m, udata, sizeof(m)))
>>> -		return -EFAULT;
>>> +	switch (version) {
>>> +	case 1:
>>> +		if (copy_from_user(&m, udata, sizeof(struct privcmd_mmapbatch)))
>>> +			return -EFAULT;
>>> +		/* Returns per-frame error in m.arr. */
>>> +		m.err = NULL;
>>> +		if (!access_ok(VERIFY_WRITE, m.arr, m.num * sizeof(*m.arr)))
>>> +			return -EFAULT;
>>> +		break;
>>> +	case 2:
>>> +		if (copy_from_user(&m, udata, sizeof(struct privcmd_mmapbatch_v2)))
>>> +			return -EFAULT;
>>> +		/* Returns per-frame error code in m.err. */
>>> +		if (!access_ok(VERIFY_WRITE, m.err, m.num * (sizeof(*m.err))))
>>> +			return -EFAULT;
>>> +		break;
>>> +	default:
>>> +		return -EINVAL;
>>> +	}
>>> 
>>> 	nr_pages = m.num;
>>> 	if ((m.num <= 0) || (nr_pages > (LONG_MAX >> PAGE_SHIFT)))
>>> 		return -EINVAL;
>>> 
>>> -	ret = gather_array(&pagelist, m.num, sizeof(xen_pfn_t),
>>> -			   m.arr);
>>> +	ret = gather_array(&pagelist, m.num, sizeof(xen_pfn_t), m.arr);
>>> 
>>> 	if (ret || list_empty(&pagelist))
>>> 		goto out;
>>> @@ -325,12 +377,17 @@ static long privcmd_ioctl_mmap_batch(void __user *udata)
>>> 
>>> 	up_write(&mm->mmap_sem);
>>> 
>>> -	if (state.err > 0) {
>>> -		state.user = m.arr;
>>> +	if (state.err) {
>>> +		state.err = 0;
>>> +		state.user_mfn = (xen_pfn_t *)m.arr;
>>> +		state.user_err = m.err;
>>> 		ret = traverse_pages(m.num, sizeof(xen_pfn_t),
>>> -			       &pagelist,
>>> -			       mmap_return_errors, &state);
>>> -	}
>>> +				     &pagelist,
>>> +				     mmap_return_errors, &state);
>>> +		if (ret >= 0)
>>> +			ret = state.err;
>>> +	} else if (m.err)
>>> +		__clear_user(m.err, m.num * sizeof(*m.err));
>>> 
>>> out:
>>> 	free_page_list(&pagelist);
>>> @@ -354,7 +411,11 @@ static long privcmd_ioctl(struct file *file,
>>> 		break;
>>> 
>>> 	case IOCTL_PRIVCMD_MMAPBATCH:
>>> -		ret = privcmd_ioctl_mmap_batch(udata);
>>> +		ret = privcmd_ioctl_mmap_batch(udata, 1);
>>> +		break;
>>> +
>>> +	case IOCTL_PRIVCMD_MMAPBATCH_V2:
>>> +		ret = privcmd_ioctl_mmap_batch(udata, 2);
>>> 		break;
>>> 
>>> 	default:
>>> diff --git a/include/xen/privcmd.h b/include/xen/privcmd.h
>>> index 17857fb..f60d75c 100644
>>> --- a/include/xen/privcmd.h
>>> +++ b/include/xen/privcmd.h
>>> @@ -59,13 +59,32 @@ struct privcmd_mmapbatch {
>>> 	int num;     /* number of pages to populate */
>>> 	domid_t dom; /* target domain */
>>> 	__u64 addr;  /* virtual address */
>>> -	xen_pfn_t __user *arr; /* array of mfns - top nibble set on err */
>>> +	xen_pfn_t __user *arr; /* array of mfns - or'd with
>>> +				  PRIVCMD_MMAPBATCH_MFN_ERROR on err */
>>> +};
>>> +
>>> +#define PRIVCMD_MMAPBATCH_MFN_ERROR 0xf0000000U
>>> +
>>> +struct privcmd_mmapbatch_v2 {
>>> +	unsigned int num; /* number of pages to populate */
>>> +	domid_t dom;      /* target domain */
>>> +	__u64 addr;       /* virtual address */
>>> +	const xen_pfn_t __user *arr; /* array of mfns */
>>> +	int __user *err;  /* array of error codes */
>>> };
>>> 
>>> /*
>>> * @cmd: IOCTL_PRIVCMD_HYPERCALL
>>> * @arg: &privcmd_hypercall_t
>>> * Return: Value returned from execution of the specified hypercall.
>>> + *
>>> + * @cmd: IOCTL_PRIVCMD_MMAPBATCH_V2
>>> + * @arg: &struct privcmd_mmapbatch_v2
>>> + * Return: 0 on success (i.e., arg->err contains valid error codes for
>>> + * each frame).  On an error other than a failed frame remap, -1 is
>>> + * returned and errno is set to EINVAL, EFAULT etc.  As an exception,
>>> + * if the operation was otherwise successful but any frame failed with
>>> + * -ENOENT, then -1 is returned and errno is set to ENOENT.
>>> */
>>> #define IOCTL_PRIVCMD_HYPERCALL					\
>>> 	_IOC(_IOC_NONE, 'P', 0, sizeof(struct privcmd_hypercall))
>>> @@ -73,5 +92,7 @@ struct privcmd_mmapbatch {
>>> 	_IOC(_IOC_NONE, 'P', 2, sizeof(struct privcmd_mmap))
>>> #define IOCTL_PRIVCMD_MMAPBATCH					\
>>> 	_IOC(_IOC_NONE, 'P', 3, sizeof(struct privcmd_mmapbatch))
>>> +#define IOCTL_PRIVCMD_MMAPBATCH_V2				\
>>> +	_IOC(_IOC_NONE, 'P', 4, sizeof(struct privcmd_mmapbatch_v2))
>>> 
>>> #endif /* __LINUX_PUBLIC_PRIVCMD_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 Wed Sep 05 17:22:19 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Sep 2012 17: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 1T9JIj-0007yJ-8s; Wed, 05 Sep 2012 17:22:05 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andres.lagarcavilla@gmail.com>) id 1T9JIh-0007yE-CV
	for xen-devel@lists.xen.org; Wed, 05 Sep 2012 17:22:03 +0000
Received: from [85.158.138.51:32792] by server-9.bemta-3.messagelabs.com id
	D1/F3-15390-A3A87405; Wed, 05 Sep 2012 17:22:02 +0000
X-Env-Sender: andres.lagarcavilla@gmail.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1346865720!20773918!1
X-Originating-IP: [209.85.223.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8348 invoked from network); 5 Sep 2012 17:22:01 -0000
Received: from mail-ie0-f173.google.com (HELO mail-ie0-f173.google.com)
	(209.85.223.173)
	by server-3.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Sep 2012 17:22:01 -0000
Received: by iebc10 with SMTP id c10so1856748ieb.32
	for <xen-devel@lists.xen.org>; Wed, 05 Sep 2012 10:22:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=subject:mime-version:content-type:from:in-reply-to:date:cc
	:content-transfer-encoding:message-id:references:to:x-mailer;
	bh=7XTnsfUgtv1NlTRHm2av1r2g1S7/73kOYZibeO2HEl0=;
	b=DcYeRzI1k/DdFkC8gCZ1vqKZwhWfyWrhdQFTxybOHe9Ip3fwRKm9aYoz/HwxPiuKKN
	iBJlwFyiaP6NGbJfvGEVvN9waN3JpfZwYdLie2WygmL3MhwEq7mZRjuFDBM7NGWV4ExH
	f9TX2Ppp1t4gXRBXgng3oYYys31i4zJysBcACMwmu0csUbQNwz7V4m9C6xIZjmSYtXA4
	7xGuxaxl5s0GfxU6AQArwHo/WN4OBV2iDvFPyt5PBT0cn0TtWRjEacRHU5wEI2F+AhHZ
	090lDBvyPvztiDJxkC2KIzirRzb0lg/HYDn4v38XumQgxkWRJKYPFBnc3l5yp8d0kPpa
	LJCw==
Received: by 10.50.159.130 with SMTP id xc2mr19059089igb.15.1346865719936;
	Wed, 05 Sep 2012 10:21:59 -0700 (PDT)
Received: from [192.168.7.210] ([206.223.182.18])
	by mx.google.com with ESMTPS id ho1sm8419983igc.3.2012.09.05.10.21.56
	(version=TLSv1/SSLv3 cipher=OTHER);
	Wed, 05 Sep 2012 10:21:59 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1278)
From: Andres Lagar-Cavilla <andres.lagarcavilla@gmail.com>
In-Reply-To: <20120905162731.GD11949@phenom.dumpdata.com>
Date: Wed, 5 Sep 2012 13:21:56 -0400
Message-Id: <4FAD394B-6A6C-44F1-AF1C-DC2F935639EE@gmail.com>
References: <1346086287-17674-1-git-send-email-andres@lagarcavilla.org>
	<5040CAEA.7000600@citrix.com>
	<160CC375-2682-4CBF-B1EC-06A9F3E49A40@gridcentric.ca>
	<A976B10C-58BE-4660-89E9-A8F85CAB5F19@gmail.com>
	<5040E210.2060702@citrix.com>
	<20120905162731.GD11949@phenom.dumpdata.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
X-Mailer: Apple Mail (2.1278)
Cc: Andres Lagar-Cavilla <andreslc@gridcentric.ca>,
	Ian Campbell <ian.campbell@citrix.com>, xen-devel@lists.xen.org,
	David Vrabel <david.vrabel@citrix.com>,
	Andres Lagar-Cavilla <andres@lagarcavilla.org>
Subject: Re: [Xen-devel] [PATCH] Xen backend support for paged out grant
	targets.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


On Sep 5, 2012, at 12:27 PM, Konrad Rzeszutek Wilk wrote:

> On Fri, Aug 31, 2012 at 05:10:56PM +0100, David Vrabel wrote:
>> On 31/08/12 16:42, Andres Lagar-Cavilla wrote:
>>> Actually acted upon your feedback ipso facto:
>>> 
>>> commit d5fab912caa1f0cf6be0a6773f502d3417a207b6
>>> Author: Andres Lagar-Cavilla <andres@lagarcavilla.org>
>>> Date:   Sun Aug 26 09:45:57 2012 -0400
>>> 
>>>    Xen backend support for paged out grant targets.
>> 
>> This looks mostly fine expect for the #define instead of inline functions.
>> 
>>> +#define gnttab_map_grant_no_eagain(_gop)                                    \
>> 
>> This name tripped me up previously. As I read this as:
>> 
>> gnttab_map_grant_no_[retries_for]_eagain().
>> 
>> Perhaps gnttab_map_grant_with_retries() ? Or similar?
> 
> gnttab_map_grant_retry ?
> 
> Besides that, it looks good to me. Ian Campbell needs to Ack so that
> David Miller (the network maintainer) can pick it up. Please CC them
> both and also LKML.

Sure will do. However, I need to bring attention to the following hunk:
diff --git a/drivers/net/xen-netback/netback.c b/drivers/net/xen-netback/netback.c
index 682633b..5610fd8 100644
--- a/drivers/net/xen-netback/netback.c
+++ b/drivers/net/xen-netback/netback.c
@@ -635,9 +635,7 @@ static void xen_netbk_rx_action(struct xen_netbk *netbk)
		return;

	BUG_ON(npo.copy_prod > ARRAY_SIZE(netbk->grant_copy_op));
-	ret = HYPERVISOR_grant_table_op(GNTTABOP_copy, &netbk->grant_copy_op,
-					npo.copy_prod);
-	BUG_ON(ret != 0);
+	gnttab_batch_copy_no_eagain(netbk->grant_copy_op, npo.copy_prod);

It seems like the (extant) code passes a struct gnttab_copy ** to the grant table hypercall (&netbk->grant_copy_op, defined as struct gnttab_copy [])

I "fixed" it to pass a struct gnttab_copy * (netbk->grant_copy_op, no '&'). This matches the other invocation of the grant copy hyper call (in netbk_tx_action). Did I fix it, though? I am confused as to how this could have ever worked.

(cc'ing Ian Campbell for more insight) 
Andres
>> 
>> David


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

From xen-devel-bounces@lists.xen.org Wed Sep 05 17:22:19 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Sep 2012 17: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 1T9JIj-0007yJ-8s; Wed, 05 Sep 2012 17:22:05 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andres.lagarcavilla@gmail.com>) id 1T9JIh-0007yE-CV
	for xen-devel@lists.xen.org; Wed, 05 Sep 2012 17:22:03 +0000
Received: from [85.158.138.51:32792] by server-9.bemta-3.messagelabs.com id
	D1/F3-15390-A3A87405; Wed, 05 Sep 2012 17:22:02 +0000
X-Env-Sender: andres.lagarcavilla@gmail.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1346865720!20773918!1
X-Originating-IP: [209.85.223.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8348 invoked from network); 5 Sep 2012 17:22:01 -0000
Received: from mail-ie0-f173.google.com (HELO mail-ie0-f173.google.com)
	(209.85.223.173)
	by server-3.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Sep 2012 17:22:01 -0000
Received: by iebc10 with SMTP id c10so1856748ieb.32
	for <xen-devel@lists.xen.org>; Wed, 05 Sep 2012 10:22:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=subject:mime-version:content-type:from:in-reply-to:date:cc
	:content-transfer-encoding:message-id:references:to:x-mailer;
	bh=7XTnsfUgtv1NlTRHm2av1r2g1S7/73kOYZibeO2HEl0=;
	b=DcYeRzI1k/DdFkC8gCZ1vqKZwhWfyWrhdQFTxybOHe9Ip3fwRKm9aYoz/HwxPiuKKN
	iBJlwFyiaP6NGbJfvGEVvN9waN3JpfZwYdLie2WygmL3MhwEq7mZRjuFDBM7NGWV4ExH
	f9TX2Ppp1t4gXRBXgng3oYYys31i4zJysBcACMwmu0csUbQNwz7V4m9C6xIZjmSYtXA4
	7xGuxaxl5s0GfxU6AQArwHo/WN4OBV2iDvFPyt5PBT0cn0TtWRjEacRHU5wEI2F+AhHZ
	090lDBvyPvztiDJxkC2KIzirRzb0lg/HYDn4v38XumQgxkWRJKYPFBnc3l5yp8d0kPpa
	LJCw==
Received: by 10.50.159.130 with SMTP id xc2mr19059089igb.15.1346865719936;
	Wed, 05 Sep 2012 10:21:59 -0700 (PDT)
Received: from [192.168.7.210] ([206.223.182.18])
	by mx.google.com with ESMTPS id ho1sm8419983igc.3.2012.09.05.10.21.56
	(version=TLSv1/SSLv3 cipher=OTHER);
	Wed, 05 Sep 2012 10:21:59 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1278)
From: Andres Lagar-Cavilla <andres.lagarcavilla@gmail.com>
In-Reply-To: <20120905162731.GD11949@phenom.dumpdata.com>
Date: Wed, 5 Sep 2012 13:21:56 -0400
Message-Id: <4FAD394B-6A6C-44F1-AF1C-DC2F935639EE@gmail.com>
References: <1346086287-17674-1-git-send-email-andres@lagarcavilla.org>
	<5040CAEA.7000600@citrix.com>
	<160CC375-2682-4CBF-B1EC-06A9F3E49A40@gridcentric.ca>
	<A976B10C-58BE-4660-89E9-A8F85CAB5F19@gmail.com>
	<5040E210.2060702@citrix.com>
	<20120905162731.GD11949@phenom.dumpdata.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
X-Mailer: Apple Mail (2.1278)
Cc: Andres Lagar-Cavilla <andreslc@gridcentric.ca>,
	Ian Campbell <ian.campbell@citrix.com>, xen-devel@lists.xen.org,
	David Vrabel <david.vrabel@citrix.com>,
	Andres Lagar-Cavilla <andres@lagarcavilla.org>
Subject: Re: [Xen-devel] [PATCH] Xen backend support for paged out grant
	targets.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


On Sep 5, 2012, at 12:27 PM, Konrad Rzeszutek Wilk wrote:

> On Fri, Aug 31, 2012 at 05:10:56PM +0100, David Vrabel wrote:
>> On 31/08/12 16:42, Andres Lagar-Cavilla wrote:
>>> Actually acted upon your feedback ipso facto:
>>> 
>>> commit d5fab912caa1f0cf6be0a6773f502d3417a207b6
>>> Author: Andres Lagar-Cavilla <andres@lagarcavilla.org>
>>> Date:   Sun Aug 26 09:45:57 2012 -0400
>>> 
>>>    Xen backend support for paged out grant targets.
>> 
>> This looks mostly fine expect for the #define instead of inline functions.
>> 
>>> +#define gnttab_map_grant_no_eagain(_gop)                                    \
>> 
>> This name tripped me up previously. As I read this as:
>> 
>> gnttab_map_grant_no_[retries_for]_eagain().
>> 
>> Perhaps gnttab_map_grant_with_retries() ? Or similar?
> 
> gnttab_map_grant_retry ?
> 
> Besides that, it looks good to me. Ian Campbell needs to Ack so that
> David Miller (the network maintainer) can pick it up. Please CC them
> both and also LKML.

Sure will do. However, I need to bring attention to the following hunk:
diff --git a/drivers/net/xen-netback/netback.c b/drivers/net/xen-netback/netback.c
index 682633b..5610fd8 100644
--- a/drivers/net/xen-netback/netback.c
+++ b/drivers/net/xen-netback/netback.c
@@ -635,9 +635,7 @@ static void xen_netbk_rx_action(struct xen_netbk *netbk)
		return;

	BUG_ON(npo.copy_prod > ARRAY_SIZE(netbk->grant_copy_op));
-	ret = HYPERVISOR_grant_table_op(GNTTABOP_copy, &netbk->grant_copy_op,
-					npo.copy_prod);
-	BUG_ON(ret != 0);
+	gnttab_batch_copy_no_eagain(netbk->grant_copy_op, npo.copy_prod);

It seems like the (extant) code passes a struct gnttab_copy ** to the grant table hypercall (&netbk->grant_copy_op, defined as struct gnttab_copy [])

I "fixed" it to pass a struct gnttab_copy * (netbk->grant_copy_op, no '&'). This matches the other invocation of the grant copy hyper call (in netbk_tx_action). Did I fix it, though? I am confused as to how this could have ever worked.

(cc'ing Ian Campbell for more insight) 
Andres
>> 
>> David


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

From xen-devel-bounces@lists.xen.org Wed Sep 05 17:32:36 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Sep 2012 17:32: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 1T9JSe-000880-Bt; Wed, 05 Sep 2012 17:32:20 +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 1T9JSd-00087v-3C
	for xen-devel@lists.xensource.com; Wed, 05 Sep 2012 17:32:19 +0000
Received: from [85.158.138.51:37655] by server-6.bemta-3.messagelabs.com id
	29/7C-29694-2AC87405; Wed, 05 Sep 2012 17:32:18 +0000
X-Env-Sender: mst@redhat.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1346866337!10174335!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTU4MDk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25795 invoked from network); 5 Sep 2012 17:32:17 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-13.tower-174.messagelabs.com with SMTP;
	5 Sep 2012 17:32:17 -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 q85HWDkg023763
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 5 Sep 2012 13:32:13 -0400
Received: from redhat.com (vpn1-5-98.ams2.redhat.com [10.36.5.98])
	by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with SMTP
	id q85HWA4E004181; Wed, 5 Sep 2012 13:32:11 -0400
Date: Wed, 5 Sep 2012 20:33:35 +0300
From: "Michael S. Tsirkin" <mst@redhat.com>
To: davej@redhat.com
Message-ID: <20120905173335.GA15141@redhat.com>
References: <20120430143835.GA10190@redhat.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120430143835.GA10190@redhat.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23
Cc: xen-devel@lists.xensource.com, kvm@vger.kernel.org,
	Gleb Natapov <gleb@redhat.com>, pv-drivers@vmware.com,
	virtualization@lists.linux-foundation.org, devel@linuxdriverproject.org
Subject: Re: [Xen-devel] [PATCHv2] x86info: dump kvm cpuid's
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Apr 30, 2012 at 05:38:35PM +0300, Michael S. Tsirkin wrote:
> The following makes 'x86info -r' dump hypervisor leaf cpu ids
> (for kvm this is signature+features) when running in a vm.
> 
> On the guest we see the signature and the features:
> eax in: 0x40000000, eax = 00000000 ebx = 4b4d564b ecx = 564b4d56 edx = 0000004d
> eax in: 0x40000001, eax = 0100007b ebx = 00000000 ecx = 00000000 edx = 00000000
> 
> Hypervisor flag is checked to avoid output changes when not
> running on a VM.
> 
> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
> 
> Changes from v1:
> 	Make work on non KVM hypervisors (only KVM was tested).
> 	Avi Kivity said kvm will in the future report
> 	max HV leaf in eax. For now it reports eax = 0
>         so add a work around for that.

Ping.
Davej, any comments?
Would be nice to have this in.


> ---
> 
> diff --git a/identify.c b/identify.c
> index 33f35de..a4a3763 100644
> --- a/identify.c
> +++ b/identify.c
> @@ -9,8 +9,8 @@
>  
>  void get_cpu_info_basics(struct cpudata *cpu)
>  {
> -	unsigned int maxi, maxei, vendor, address_bits;
> -	unsigned int eax;
> +	unsigned int maxi, maxei, maxhv, vendor, address_bits;
> +	unsigned int eax, ebx, ecx;
>  
>  	cpuid(cpu->number, 0, &maxi, &vendor, NULL, NULL);
>  	maxi &= 0xffff;		/* The high-order word is non-zero on some Cyrix CPUs */
> @@ -19,7 +19,7 @@ void get_cpu_info_basics(struct cpudata *cpu)
>  		return;
>  
>  	/* Everything that supports cpuid supports these. */
> -	cpuid(cpu->number, 1, &eax, NULL, NULL, NULL);
> +	cpuid(cpu->number, 1, &eax, &ebx, &ecx, NULL);
>  	cpu->stepping = eax & 0xf;
>  	cpu->model = (eax >> 4) & 0xf;
>  	cpu->family = (eax >> 8) & 0xf;
> @@ -29,6 +29,19 @@ void get_cpu_info_basics(struct cpudata *cpu)
>  
>  	cpuid(cpu->number, 0xC0000000, &maxei, NULL, NULL, NULL);
>  	cpu->maxei2 = maxei;
> +	if (ecx & 0x80000000) {
> +		cpuid(cpu->number, 0x40000000, &maxhv, NULL, NULL, NULL);
> +		/*
> +		 * KVM up to linux 3.4 reports 0 as the max hypervisor leaf,
> +		 * where it really means 0x40000001.
> +		 * Most (all?) hypervisors have at least one CPUID besides
> +		 * the vendor ID so assume that.
> +		 */
> +		cpu->maxhv = maxhv ? maxhv : 0x40000001;
> +	} else {
> +		/* Suppress hypervisor cpuid unless running on a hypervisor */
> +		cpu->maxhv = 0;
> +	}
>  
>  	cpuid(cpu->number, 0x80000008,&address_bits, NULL, NULL, NULL);
>  	cpu->phyaddr_bits = address_bits & 0xFF;
> diff --git a/x86info.c b/x86info.c
> index 22c4734..80cae36 100644
> --- a/x86info.c
> +++ b/x86info.c
> @@ -44,6 +44,10 @@ static void display_detailed_info(struct cpudata *cpu)
>  
>  		if (cpu->maxei2 >=0xC0000000)
>  			dump_raw_cpuid(cpu->number, 0xC0000000, cpu->maxei2);
> +
> +		if (cpu->maxhv >= 0x40000000)
> +			dump_raw_cpuid(cpu->number, 0x40000000, cpu->maxhv);
> +
>  	}
>  
>  	if (show_cacheinfo) {
> diff --git a/x86info.h b/x86info.h
> index 7d2a455..c4f5d81 100644
> --- a/x86info.h
> +++ b/x86info.h
> @@ -84,7 +84,7 @@ struct cpudata {
>  	unsigned int cachesize_trace;
>  	unsigned int phyaddr_bits;
>  	unsigned int viraddr_bits;
> -	unsigned int cpuid_level, maxei, maxei2;
> +	unsigned int cpuid_level, maxei, maxei2, maxhv;
>  	char name[CPU_NAME_LEN];
>  	enum connector connector;
>  	unsigned int flags_ecx;

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

From xen-devel-bounces@lists.xen.org Wed Sep 05 17:32:36 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Sep 2012 17:32: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 1T9JSe-000880-Bt; Wed, 05 Sep 2012 17:32:20 +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 1T9JSd-00087v-3C
	for xen-devel@lists.xensource.com; Wed, 05 Sep 2012 17:32:19 +0000
Received: from [85.158.138.51:37655] by server-6.bemta-3.messagelabs.com id
	29/7C-29694-2AC87405; Wed, 05 Sep 2012 17:32:18 +0000
X-Env-Sender: mst@redhat.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1346866337!10174335!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTU4MDk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25795 invoked from network); 5 Sep 2012 17:32:17 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-13.tower-174.messagelabs.com with SMTP;
	5 Sep 2012 17:32:17 -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 q85HWDkg023763
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 5 Sep 2012 13:32:13 -0400
Received: from redhat.com (vpn1-5-98.ams2.redhat.com [10.36.5.98])
	by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with SMTP
	id q85HWA4E004181; Wed, 5 Sep 2012 13:32:11 -0400
Date: Wed, 5 Sep 2012 20:33:35 +0300
From: "Michael S. Tsirkin" <mst@redhat.com>
To: davej@redhat.com
Message-ID: <20120905173335.GA15141@redhat.com>
References: <20120430143835.GA10190@redhat.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120430143835.GA10190@redhat.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23
Cc: xen-devel@lists.xensource.com, kvm@vger.kernel.org,
	Gleb Natapov <gleb@redhat.com>, pv-drivers@vmware.com,
	virtualization@lists.linux-foundation.org, devel@linuxdriverproject.org
Subject: Re: [Xen-devel] [PATCHv2] x86info: dump kvm cpuid's
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Apr 30, 2012 at 05:38:35PM +0300, Michael S. Tsirkin wrote:
> The following makes 'x86info -r' dump hypervisor leaf cpu ids
> (for kvm this is signature+features) when running in a vm.
> 
> On the guest we see the signature and the features:
> eax in: 0x40000000, eax = 00000000 ebx = 4b4d564b ecx = 564b4d56 edx = 0000004d
> eax in: 0x40000001, eax = 0100007b ebx = 00000000 ecx = 00000000 edx = 00000000
> 
> Hypervisor flag is checked to avoid output changes when not
> running on a VM.
> 
> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
> 
> Changes from v1:
> 	Make work on non KVM hypervisors (only KVM was tested).
> 	Avi Kivity said kvm will in the future report
> 	max HV leaf in eax. For now it reports eax = 0
>         so add a work around for that.

Ping.
Davej, any comments?
Would be nice to have this in.


> ---
> 
> diff --git a/identify.c b/identify.c
> index 33f35de..a4a3763 100644
> --- a/identify.c
> +++ b/identify.c
> @@ -9,8 +9,8 @@
>  
>  void get_cpu_info_basics(struct cpudata *cpu)
>  {
> -	unsigned int maxi, maxei, vendor, address_bits;
> -	unsigned int eax;
> +	unsigned int maxi, maxei, maxhv, vendor, address_bits;
> +	unsigned int eax, ebx, ecx;
>  
>  	cpuid(cpu->number, 0, &maxi, &vendor, NULL, NULL);
>  	maxi &= 0xffff;		/* The high-order word is non-zero on some Cyrix CPUs */
> @@ -19,7 +19,7 @@ void get_cpu_info_basics(struct cpudata *cpu)
>  		return;
>  
>  	/* Everything that supports cpuid supports these. */
> -	cpuid(cpu->number, 1, &eax, NULL, NULL, NULL);
> +	cpuid(cpu->number, 1, &eax, &ebx, &ecx, NULL);
>  	cpu->stepping = eax & 0xf;
>  	cpu->model = (eax >> 4) & 0xf;
>  	cpu->family = (eax >> 8) & 0xf;
> @@ -29,6 +29,19 @@ void get_cpu_info_basics(struct cpudata *cpu)
>  
>  	cpuid(cpu->number, 0xC0000000, &maxei, NULL, NULL, NULL);
>  	cpu->maxei2 = maxei;
> +	if (ecx & 0x80000000) {
> +		cpuid(cpu->number, 0x40000000, &maxhv, NULL, NULL, NULL);
> +		/*
> +		 * KVM up to linux 3.4 reports 0 as the max hypervisor leaf,
> +		 * where it really means 0x40000001.
> +		 * Most (all?) hypervisors have at least one CPUID besides
> +		 * the vendor ID so assume that.
> +		 */
> +		cpu->maxhv = maxhv ? maxhv : 0x40000001;
> +	} else {
> +		/* Suppress hypervisor cpuid unless running on a hypervisor */
> +		cpu->maxhv = 0;
> +	}
>  
>  	cpuid(cpu->number, 0x80000008,&address_bits, NULL, NULL, NULL);
>  	cpu->phyaddr_bits = address_bits & 0xFF;
> diff --git a/x86info.c b/x86info.c
> index 22c4734..80cae36 100644
> --- a/x86info.c
> +++ b/x86info.c
> @@ -44,6 +44,10 @@ static void display_detailed_info(struct cpudata *cpu)
>  
>  		if (cpu->maxei2 >=0xC0000000)
>  			dump_raw_cpuid(cpu->number, 0xC0000000, cpu->maxei2);
> +
> +		if (cpu->maxhv >= 0x40000000)
> +			dump_raw_cpuid(cpu->number, 0x40000000, cpu->maxhv);
> +
>  	}
>  
>  	if (show_cacheinfo) {
> diff --git a/x86info.h b/x86info.h
> index 7d2a455..c4f5d81 100644
> --- a/x86info.h
> +++ b/x86info.h
> @@ -84,7 +84,7 @@ struct cpudata {
>  	unsigned int cachesize_trace;
>  	unsigned int phyaddr_bits;
>  	unsigned int viraddr_bits;
> -	unsigned int cpuid_level, maxei, maxei2;
> +	unsigned int cpuid_level, maxei, maxei2, maxhv;
>  	char name[CPU_NAME_LEN];
>  	enum connector connector;
>  	unsigned int flags_ecx;

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

From xen-devel-bounces@lists.xen.org Wed Sep 05 17:51:51 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Sep 2012 17:51:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9JlB-0008Sl-CG; Wed, 05 Sep 2012 17:51:29 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1T9Jl9-0008Sg-E7
	for xen-devel@lists.xensource.com; Wed, 05 Sep 2012 17:51:27 +0000
Received: from [85.158.143.99:53295] by server-2.bemta-4.messagelabs.com id
	9E/29-21239-D1197405; Wed, 05 Sep 2012 17:51:25 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1346867480!21203851!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDczODkxOA==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1537 invoked from network); 5 Sep 2012 17:51:24 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-11.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 5 Sep 2012 17:51:24 -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 q85HpHi6001176
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 5 Sep 2012 17:51:18 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
	q85HpHdZ001549
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 5 Sep 2012 17:51:17 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
	q85HpGUl030153; Wed, 5 Sep 2012 12:51:16 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 05 Sep 2012 10:51:16 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id AA79A402C1; Wed,  5 Sep 2012 13:40:46 -0400 (EDT)
Date: Wed, 5 Sep 2012 13:40:46 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Andres Lagar-Cavilla <andreslc@gridcentric.ca>
Message-ID: <20120905174046.GA25535@phenom.dumpdata.com>
References: <1346331492-15027-1-git-send-email-david.vrabel@citrix.com>
	<1346331492-15027-3-git-send-email-david.vrabel@citrix.com>
	<C989BE9D-E520-4D04-9028-6CE6CC765E76@gridcentric.ca>
	<20120905162148.GC11949@phenom.dumpdata.com>
	<939BE993-572C-4D83-8F04-E6B9D6EE3E92@gridcentric.ca>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <939BE993-572C-4D83-8F04-E6B9D6EE3E92@gridcentric.ca>
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, David Vrabel <david.vrabel@citrix.com>
Subject: Re: [Xen-devel] [PATCH 2/2] xen/privcmd: add PRIVCMD_MMAPBATCH_V2
	ioctl
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Sep 05, 2012 at 01:09:32PM -0400, Andres Lagar-Cavilla wrote:
> Super. To which branch are you applying these now? (n00b question but have to ask)

They will show up on stable/for-linus-3.7 once the overnight tests pass.

> Andres
> On Sep 5, 2012, at 12:21 PM, Konrad Rzeszutek Wilk wrote:
> 
> > On Fri, Aug 31, 2012 at 09:59:30AM -0400, Andres Lagar-Cavilla wrote:
> >> Re-spin of alternative patch after David's feedback.
> >> Thanks
> >> Andres
> > 
> > applied. fixed some whitespace issues.
> >> 
> >> commit ab351a5cef1797935b083c2f6e72800a8949c515
> >> Author: Andres Lagar-Cavilla <andres@lagarcavilla.org>
> >> Date:   Thu Aug 30 12:23:33 2012 -0400
> >> 
> >>    xen/privcmd: add PRIVCMD_MMAPBATCH_V2 ioctl
> >> 
> >>    PRIVCMD_MMAPBATCH_V2 extends PRIVCMD_MMAPBATCH with an additional
> >>    field for reporting the error code for every frame that could not be
> >>    mapped.  libxc prefers PRIVCMD_MMAPBATCH_V2 over PRIVCMD_MMAPBATCH.
> >> 
> >>    Also expand PRIVCMD_MMAPBATCH to return appropriate error-encoding top nibble
> >>    in the mfn array.
> >> 
> >>    Signed-off-by: David Vrabel <david.vrabel@citrix.com>
> >>    Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
> >> 
> >> diff --git a/drivers/xen/privcmd.c b/drivers/xen/privcmd.c
> >> index 85226cb..5386f20 100644
> >> --- a/drivers/xen/privcmd.c
> >> +++ b/drivers/xen/privcmd.c
> >> @@ -76,7 +76,7 @@ static void free_page_list(struct list_head *pages)
> >>  */
> >> static int gather_array(struct list_head *pagelist,
> >> 			unsigned nelem, size_t size,
> >> -			void __user *data)
> >> +			const void __user *data)
> >> {
> >> 	unsigned pageidx;
> >> 	void *pagedata;
> >> @@ -246,61 +246,117 @@ struct mmap_batch_state {
> >> 	domid_t domain;
> >> 	unsigned long va;
> >> 	struct vm_area_struct *vma;
> >> -	int err;
> >> -
> >> -	xen_pfn_t __user *user;
> >> +	/* A tristate: 
> >> +	 *      0 for no errors
> >> +	 *      1 if at least one error has happened (and no
> >> +	 *          -ENOENT errors have happened)
> >> +	 *      -ENOENT if at least 1 -ENOENT has happened.
> >> +	 */
> >> +	int global_error;
> >> +	/* An array for individual errors */
> >> +	int *err;
> >> +
> >> +	/* User-space mfn array to store errors in the second pass for V1. */
> >> +	xen_pfn_t __user *user_mfn;
> >> };
> >> 
> >> static int mmap_batch_fn(void *data, void *state)
> >> {
> >> 	xen_pfn_t *mfnp = data;
> >> 	struct mmap_batch_state *st = state;
> >> +	int ret;
> >> 
> >> -	if (xen_remap_domain_mfn_range(st->vma, st->va & PAGE_MASK, *mfnp, 1,
> >> -				       st->vma->vm_page_prot, st->domain) < 0) {
> >> -		*mfnp |= 0xf0000000U;
> >> -		st->err++;
> >> +	ret = xen_remap_domain_mfn_range(st->vma, st->va & PAGE_MASK, *mfnp, 1,
> >> +					 st->vma->vm_page_prot, st->domain);
> >> +
> >> +	/* Store error code for second pass. */
> >> +	*(st->err++) = ret;
> >> +
> >> +	/* And see if it affects the global_error. */
> >> +	if (ret < 0) {
> >> +		if (ret == -ENOENT)
> >> +			st->global_error = -ENOENT;
> >> +		else {
> >> +			/* Record that at least one error has happened. */
> >> +			if (st->global_error == 0)
> >> +				st->global_error = 1;
> >> +		}
> >> 	}
> >> 	st->va += PAGE_SIZE;
> >> 
> >> 	return 0;
> >> }
> >> 
> >> -static int mmap_return_errors(void *data, void *state)
> >> +static int mmap_return_errors_v1(void *data, void *state)
> >> {
> >> 	xen_pfn_t *mfnp = data;
> >> 	struct mmap_batch_state *st = state;
> >> -
> >> -	return put_user(*mfnp, st->user++);
> >> +	int err = *(st->err++);
> >> +
> >> +	/*
> >> +	 * V1 encodes the error codes in the 32bit top nibble of the 
> >> +	 * mfn (with its known limitations vis-a-vis 64 bit callers).
> >> +	 */
> >> +	*mfnp |= (err == -ENOENT) ?
> >> +				PRIVCMD_MMAPBATCH_PAGED_ERROR :
> >> +				PRIVCMD_MMAPBATCH_MFN_ERROR;
> >> +	return __put_user(*mfnp, st->user_mfn++);
> >> }
> >> 
> >> static struct vm_operations_struct privcmd_vm_ops;
> >> 
> >> -static long privcmd_ioctl_mmap_batch(void __user *udata)
> >> +static long privcmd_ioctl_mmap_batch(void __user *udata, int version)
> >> {
> >> 	int ret;
> >> -	struct privcmd_mmapbatch m;
> >> +	struct privcmd_mmapbatch_v2 m;
> >> 	struct mm_struct *mm = current->mm;
> >> 	struct vm_area_struct *vma;
> >> 	unsigned long nr_pages;
> >> 	LIST_HEAD(pagelist);
> >> +	int *err_array = NULL;
> >> 	struct mmap_batch_state state;
> >> 
> >> 	if (!xen_initial_domain())
> >> 		return -EPERM;
> >> 
> >> -	if (copy_from_user(&m, udata, sizeof(m)))
> >> -		return -EFAULT;
> >> +	switch (version) {
> >> +	case 1:
> >> +		if (copy_from_user(&m, udata, sizeof(struct privcmd_mmapbatch)))
> >> +			return -EFAULT;
> >> +		/* Returns per-frame error in m.arr. */
> >> +		m.err = NULL;
> >> +		if (!access_ok(VERIFY_WRITE, m.arr, m.num * sizeof(*m.arr)))
> >> +			return -EFAULT;
> >> +		break;
> >> +	case 2:
> >> +		if (copy_from_user(&m, udata, sizeof(struct privcmd_mmapbatch_v2)))
> >> +			return -EFAULT;
> >> +		/* Returns per-frame error code in m.err. */
> >> +		if (!access_ok(VERIFY_WRITE, m.err, m.num * (sizeof(*m.err))))
> >> +			return -EFAULT;
> >> +		break;
> >> +	default:
> >> +		return -EINVAL;
> >> +	}
> >> 
> >> 	nr_pages = m.num;
> >> 	if ((m.num <= 0) || (nr_pages > (LONG_MAX >> PAGE_SHIFT)))
> >> 		return -EINVAL;
> >> 
> >> -	ret = gather_array(&pagelist, m.num, sizeof(xen_pfn_t),
> >> -			   m.arr);
> >> +	ret = gather_array(&pagelist, m.num, sizeof(xen_pfn_t), m.arr);
> >> +
> >> +	if (ret)
> >> +		goto out;
> >> +	if (list_empty(&pagelist)) {
> >> +		ret = -EINVAL;
> >> +		goto out;
> >> +    }
> >> 
> >> -	if (ret || list_empty(&pagelist))
> >> +	err_array = kcalloc(m.num, sizeof(int), GFP_KERNEL);
> >> +	if (err_array == NULL) {
> >> +		ret = -ENOMEM;
> >> 		goto out;
> >> +	}
> >> 
> >> 	down_write(&mm->mmap_sem);
> >> 
> >> @@ -315,24 +371,34 @@ static long privcmd_ioctl_mmap_batch(void __user *udata)
> >> 		goto out;
> >> 	}
> >> 
> >> -	state.domain = m.dom;
> >> -	state.vma = vma;
> >> -	state.va = m.addr;
> >> -	state.err = 0;
> >> +	state.domain        = m.dom;
> >> +	state.vma           = vma;
> >> +	state.va            = m.addr;
> >> +	state.global_error  = 0;
> >> +	state.err           = err_array;
> >> 
> >> -	ret = traverse_pages(m.num, sizeof(xen_pfn_t),
> >> -			     &pagelist, mmap_batch_fn, &state);
> >> +	/* mmap_batch_fn guarantees ret == 0 */
> >> +	BUG_ON(traverse_pages(m.num, sizeof(xen_pfn_t),
> >> +			     &pagelist, mmap_batch_fn, &state));
> >> 
> >> 	up_write(&mm->mmap_sem);
> >> 
> >> -	if (state.err > 0) {
> >> -		state.user = m.arr;
> >> +	if (state.global_error && (version == 1)) {
> >> +		/* Write back errors in second pass. */
> >> +		state.user_mfn = (xen_pfn_t *)m.arr;
> >> +		state.err      = err_array;
> >> 		ret = traverse_pages(m.num, sizeof(xen_pfn_t),
> >> -			       &pagelist,
> >> -			       mmap_return_errors, &state);
> >> -	}
> >> +					 &pagelist, mmap_return_errors_v1, &state);
> >> +	} else
> >> +		ret = __copy_to_user(m.err, err_array, m.num * sizeof(int));
> >> +
> >> +    /* If we have not had any EFAULT-like global errors then set the global
> >> +     * error to -ENOENT if necessary. */
> >> +    if ((ret == 0) && (state.global_error == -ENOENT))
> >> +        ret = -ENOENT;
> >> 
> >> out:
> >> +	kfree(err_array);
> >> 	free_page_list(&pagelist);
> >> 
> >> 	return ret;
> >> @@ -354,7 +420,11 @@ static long privcmd_ioctl(struct file *file,
> >> 		break;
> >> 
> >> 	case IOCTL_PRIVCMD_MMAPBATCH:
> >> -		ret = privcmd_ioctl_mmap_batch(udata);
> >> +		ret = privcmd_ioctl_mmap_batch(udata, 1);
> >> +		break;
> >> +
> >> +	case IOCTL_PRIVCMD_MMAPBATCH_V2:
> >> +		ret = privcmd_ioctl_mmap_batch(udata, 2);
> >> 		break;
> >> 
> >> 	default:
> >> diff --git a/include/xen/privcmd.h b/include/xen/privcmd.h
> >> index 45c1aa1..a853168 100644
> >> --- a/include/xen/privcmd.h
> >> +++ b/include/xen/privcmd.h
> >> @@ -58,13 +58,33 @@ struct privcmd_mmapbatch {
> >> 	int num;     /* number of pages to populate */
> >> 	domid_t dom; /* target domain */
> >> 	__u64 addr;  /* virtual address */
> >> -	xen_pfn_t __user *arr; /* array of mfns - top nibble set on err */
> >> +	xen_pfn_t __user *arr; /* array of mfns - or'd with
> >> +				  PRIVCMD_MMAPBATCH_*_ERROR on err */
> >> +};
> >> +
> >> +#define PRIVCMD_MMAPBATCH_MFN_ERROR     0xf0000000U
> >> +#define PRIVCMD_MMAPBATCH_PAGED_ERROR   0x80000000U
> >> +
> >> +struct privcmd_mmapbatch_v2 {
> >> +	unsigned int num; /* number of pages to populate */
> >> +	domid_t dom;      /* target domain */
> >> +	__u64 addr;       /* virtual address */
> >> +	const xen_pfn_t __user *arr; /* array of mfns */
> >> +	int __user *err;  /* array of error codes */
> >> };
> >> 
> >> /*
> >>  * @cmd: IOCTL_PRIVCMD_HYPERCALL
> >>  * @arg: &privcmd_hypercall_t
> >>  * Return: Value returned from execution of the specified hypercall.
> >> + *
> >> + * @cmd: IOCTL_PRIVCMD_MMAPBATCH_V2
> >> + * @arg: &struct privcmd_mmapbatch_v2
> >> + * Return: 0 on success (i.e., arg->err contains valid error codes for
> >> + * each frame).  On an error other than a failed frame remap, -1 is
> >> + * returned and errno is set to EINVAL, EFAULT etc.  As an exception,
> >> + * if the operation was otherwise successful but any frame failed with
> >> + * -ENOENT, then -1 is returned and errno is set to ENOENT.
> >>  */
> >> #define IOCTL_PRIVCMD_HYPERCALL					\
> >> 	_IOC(_IOC_NONE, 'P', 0, sizeof(struct privcmd_hypercall))
> >> @@ -72,5 +92,7 @@ struct privcmd_mmapbatch {
> >> 	_IOC(_IOC_NONE, 'P', 2, sizeof(struct privcmd_mmap))
> >> #define IOCTL_PRIVCMD_MMAPBATCH					\
> >> 	_IOC(_IOC_NONE, 'P', 3, sizeof(struct privcmd_mmapbatch))
> >> +#define IOCTL_PRIVCMD_MMAPBATCH_V2				\
> >> +	_IOC(_IOC_NONE, 'P', 4, sizeof(struct privcmd_mmapbatch_v2))
> >> 
> >> #endif /* __LINUX_PUBLIC_PRIVCMD_H__ */
> >> 
> >> On Aug 30, 2012, at 8:58 AM, David Vrabel wrote:
> >> 
> >>> From: David Vrabel <david.vrabel@citrix.com>
> >>> 
> >>> PRIVCMD_MMAPBATCH_V2 extends PRIVCMD_MMAPBATCH with an additional
> >>> field for reporting the error code for every frame that could not be
> >>> mapped.  libxc prefers PRIVCMD_MMAPBATCH_V2 over PRIVCMD_MMAPBATCH.
> >>> 
> >>> Signed-off-by: David Vrabel <david.vrabel@citrix.com>
> >>> ---
> >>> drivers/xen/privcmd.c |   99 +++++++++++++++++++++++++++++++++++++++---------
> >>> include/xen/privcmd.h |   23 +++++++++++-
> >>> 2 files changed, 102 insertions(+), 20 deletions(-)
> >>> 
> >>> diff --git a/drivers/xen/privcmd.c b/drivers/xen/privcmd.c
> >>> index ccee0f1..c0e89e7 100644
> >>> --- a/drivers/xen/privcmd.c
> >>> +++ b/drivers/xen/privcmd.c
> >>> @@ -76,7 +76,7 @@ static void free_page_list(struct list_head *pages)
> >>> */
> >>> static int gather_array(struct list_head *pagelist,
> >>> 			unsigned nelem, size_t size,
> >>> -			void __user *data)
> >>> +			const void __user *data)
> >>> {
> >>> 	unsigned pageidx;
> >>> 	void *pagedata;
> >>> @@ -248,18 +248,37 @@ struct mmap_batch_state {
> >>> 	struct vm_area_struct *vma;
> >>> 	int err;
> >>> 
> >>> -	xen_pfn_t __user *user;
> >>> +	xen_pfn_t __user *user_mfn;
> >>> +	int __user *user_err;
> >>> };
> >>> 
> >>> static int mmap_batch_fn(void *data, void *state)
> >>> {
> >>> 	xen_pfn_t *mfnp = data;
> >>> 	struct mmap_batch_state *st = state;
> >>> +	int ret;
> >>> 
> >>> -	if (xen_remap_domain_mfn_range(st->vma, st->va & PAGE_MASK, *mfnp, 1,
> >>> -				       st->vma->vm_page_prot, st->domain) < 0) {
> >>> -		*mfnp |= 0xf0000000U;
> >>> -		st->err++;
> >>> +	ret = xen_remap_domain_mfn_range(st->vma, st->va & PAGE_MASK, *mfnp, 1,
> >>> +					 st->vma->vm_page_prot, st->domain);
> >>> +	if (ret < 0) {
> >>> +		/*
> >>> +		 * Error reporting is a mess but userspace relies on
> >>> +		 * it behaving this way.
> >>> +		 *
> >>> +		 * V2 needs to a) return the result of each frame's
> >>> +		 * remap; and b) return -ENOENT if any frame failed
> >>> +		 * with -ENOENT.
> >>> +		 *
> >>> +		 * In this first pass the error code is saved by
> >>> +		 * overwriting the mfn and an error is indicated in
> >>> +		 * st->err.
> >>> +		 *
> >>> +		 * The second pass by mmap_return_errors() will write
> >>> +		 * the error codes to user space and get the right
> >>> +		 * ioctl return value.
> >>> +		 */
> >>> +		*(int *)mfnp = ret;
> >>> +		st->err = ret;
> >>> 	}
> >>> 	st->va += PAGE_SIZE;
> >>> 
> >>> @@ -270,16 +289,33 @@ static int mmap_return_errors(void *data, void *state)
> >>> {
> >>> 	xen_pfn_t *mfnp = data;
> >>> 	struct mmap_batch_state *st = state;
> >>> +	int ret;
> >>> +
> >>> +	if (st->user_err) {
> >>> +		int err = *(int *)mfnp;
> >>> +
> >>> +		if (err == -ENOENT)
> >>> +			st->err = err;
> >>> 
> >>> -	return put_user(*mfnp, st->user++);
> >>> +		return __put_user(err, st->user_err++);
> >>> +	} else {
> >>> +		xen_pfn_t mfn;
> >>> +
> >>> +		ret = __get_user(mfn, st->user_mfn);
> >>> +		if (ret < 0)
> >>> +			return ret;
> >>> +
> >>> +		mfn |= PRIVCMD_MMAPBATCH_MFN_ERROR;
> >>> +		return __put_user(mfn, st->user_mfn++);
> >>> +	}
> >>> }
> >>> 
> >>> static struct vm_operations_struct privcmd_vm_ops;
> >>> 
> >>> -static long privcmd_ioctl_mmap_batch(void __user *udata)
> >>> +static long privcmd_ioctl_mmap_batch(void __user *udata, int version)
> >>> {
> >>> 	int ret;
> >>> -	struct privcmd_mmapbatch m;
> >>> +	struct privcmd_mmapbatch_v2 m;
> >>> 	struct mm_struct *mm = current->mm;
> >>> 	struct vm_area_struct *vma;
> >>> 	unsigned long nr_pages;
> >>> @@ -289,15 +325,31 @@ static long privcmd_ioctl_mmap_batch(void __user *udata)
> >>> 	if (!xen_initial_domain())
> >>> 		return -EPERM;
> >>> 
> >>> -	if (copy_from_user(&m, udata, sizeof(m)))
> >>> -		return -EFAULT;
> >>> +	switch (version) {
> >>> +	case 1:
> >>> +		if (copy_from_user(&m, udata, sizeof(struct privcmd_mmapbatch)))
> >>> +			return -EFAULT;
> >>> +		/* Returns per-frame error in m.arr. */
> >>> +		m.err = NULL;
> >>> +		if (!access_ok(VERIFY_WRITE, m.arr, m.num * sizeof(*m.arr)))
> >>> +			return -EFAULT;
> >>> +		break;
> >>> +	case 2:
> >>> +		if (copy_from_user(&m, udata, sizeof(struct privcmd_mmapbatch_v2)))
> >>> +			return -EFAULT;
> >>> +		/* Returns per-frame error code in m.err. */
> >>> +		if (!access_ok(VERIFY_WRITE, m.err, m.num * (sizeof(*m.err))))
> >>> +			return -EFAULT;
> >>> +		break;
> >>> +	default:
> >>> +		return -EINVAL;
> >>> +	}
> >>> 
> >>> 	nr_pages = m.num;
> >>> 	if ((m.num <= 0) || (nr_pages > (LONG_MAX >> PAGE_SHIFT)))
> >>> 		return -EINVAL;
> >>> 
> >>> -	ret = gather_array(&pagelist, m.num, sizeof(xen_pfn_t),
> >>> -			   m.arr);
> >>> +	ret = gather_array(&pagelist, m.num, sizeof(xen_pfn_t), m.arr);
> >>> 
> >>> 	if (ret || list_empty(&pagelist))
> >>> 		goto out;
> >>> @@ -325,12 +377,17 @@ static long privcmd_ioctl_mmap_batch(void __user *udata)
> >>> 
> >>> 	up_write(&mm->mmap_sem);
> >>> 
> >>> -	if (state.err > 0) {
> >>> -		state.user = m.arr;
> >>> +	if (state.err) {
> >>> +		state.err = 0;
> >>> +		state.user_mfn = (xen_pfn_t *)m.arr;
> >>> +		state.user_err = m.err;
> >>> 		ret = traverse_pages(m.num, sizeof(xen_pfn_t),
> >>> -			       &pagelist,
> >>> -			       mmap_return_errors, &state);
> >>> -	}
> >>> +				     &pagelist,
> >>> +				     mmap_return_errors, &state);
> >>> +		if (ret >= 0)
> >>> +			ret = state.err;
> >>> +	} else if (m.err)
> >>> +		__clear_user(m.err, m.num * sizeof(*m.err));
> >>> 
> >>> out:
> >>> 	free_page_list(&pagelist);
> >>> @@ -354,7 +411,11 @@ static long privcmd_ioctl(struct file *file,
> >>> 		break;
> >>> 
> >>> 	case IOCTL_PRIVCMD_MMAPBATCH:
> >>> -		ret = privcmd_ioctl_mmap_batch(udata);
> >>> +		ret = privcmd_ioctl_mmap_batch(udata, 1);
> >>> +		break;
> >>> +
> >>> +	case IOCTL_PRIVCMD_MMAPBATCH_V2:
> >>> +		ret = privcmd_ioctl_mmap_batch(udata, 2);
> >>> 		break;
> >>> 
> >>> 	default:
> >>> diff --git a/include/xen/privcmd.h b/include/xen/privcmd.h
> >>> index 17857fb..f60d75c 100644
> >>> --- a/include/xen/privcmd.h
> >>> +++ b/include/xen/privcmd.h
> >>> @@ -59,13 +59,32 @@ struct privcmd_mmapbatch {
> >>> 	int num;     /* number of pages to populate */
> >>> 	domid_t dom; /* target domain */
> >>> 	__u64 addr;  /* virtual address */
> >>> -	xen_pfn_t __user *arr; /* array of mfns - top nibble set on err */
> >>> +	xen_pfn_t __user *arr; /* array of mfns - or'd with
> >>> +				  PRIVCMD_MMAPBATCH_MFN_ERROR on err */
> >>> +};
> >>> +
> >>> +#define PRIVCMD_MMAPBATCH_MFN_ERROR 0xf0000000U
> >>> +
> >>> +struct privcmd_mmapbatch_v2 {
> >>> +	unsigned int num; /* number of pages to populate */
> >>> +	domid_t dom;      /* target domain */
> >>> +	__u64 addr;       /* virtual address */
> >>> +	const xen_pfn_t __user *arr; /* array of mfns */
> >>> +	int __user *err;  /* array of error codes */
> >>> };
> >>> 
> >>> /*
> >>> * @cmd: IOCTL_PRIVCMD_HYPERCALL
> >>> * @arg: &privcmd_hypercall_t
> >>> * Return: Value returned from execution of the specified hypercall.
> >>> + *
> >>> + * @cmd: IOCTL_PRIVCMD_MMAPBATCH_V2
> >>> + * @arg: &struct privcmd_mmapbatch_v2
> >>> + * Return: 0 on success (i.e., arg->err contains valid error codes for
> >>> + * each frame).  On an error other than a failed frame remap, -1 is
> >>> + * returned and errno is set to EINVAL, EFAULT etc.  As an exception,
> >>> + * if the operation was otherwise successful but any frame failed with
> >>> + * -ENOENT, then -1 is returned and errno is set to ENOENT.
> >>> */
> >>> #define IOCTL_PRIVCMD_HYPERCALL					\
> >>> 	_IOC(_IOC_NONE, 'P', 0, sizeof(struct privcmd_hypercall))
> >>> @@ -73,5 +92,7 @@ struct privcmd_mmapbatch {
> >>> 	_IOC(_IOC_NONE, 'P', 2, sizeof(struct privcmd_mmap))
> >>> #define IOCTL_PRIVCMD_MMAPBATCH					\
> >>> 	_IOC(_IOC_NONE, 'P', 3, sizeof(struct privcmd_mmapbatch))
> >>> +#define IOCTL_PRIVCMD_MMAPBATCH_V2				\
> >>> +	_IOC(_IOC_NONE, 'P', 4, sizeof(struct privcmd_mmapbatch_v2))
> >>> 
> >>> #endif /* __LINUX_PUBLIC_PRIVCMD_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 Wed Sep 05 17:51:51 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Sep 2012 17:51:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9JlB-0008Sl-CG; Wed, 05 Sep 2012 17:51:29 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1T9Jl9-0008Sg-E7
	for xen-devel@lists.xensource.com; Wed, 05 Sep 2012 17:51:27 +0000
Received: from [85.158.143.99:53295] by server-2.bemta-4.messagelabs.com id
	9E/29-21239-D1197405; Wed, 05 Sep 2012 17:51:25 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1346867480!21203851!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDczODkxOA==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1537 invoked from network); 5 Sep 2012 17:51:24 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-11.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 5 Sep 2012 17:51:24 -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 q85HpHi6001176
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 5 Sep 2012 17:51:18 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
	q85HpHdZ001549
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 5 Sep 2012 17:51:17 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
	q85HpGUl030153; Wed, 5 Sep 2012 12:51:16 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 05 Sep 2012 10:51:16 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id AA79A402C1; Wed,  5 Sep 2012 13:40:46 -0400 (EDT)
Date: Wed, 5 Sep 2012 13:40:46 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Andres Lagar-Cavilla <andreslc@gridcentric.ca>
Message-ID: <20120905174046.GA25535@phenom.dumpdata.com>
References: <1346331492-15027-1-git-send-email-david.vrabel@citrix.com>
	<1346331492-15027-3-git-send-email-david.vrabel@citrix.com>
	<C989BE9D-E520-4D04-9028-6CE6CC765E76@gridcentric.ca>
	<20120905162148.GC11949@phenom.dumpdata.com>
	<939BE993-572C-4D83-8F04-E6B9D6EE3E92@gridcentric.ca>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <939BE993-572C-4D83-8F04-E6B9D6EE3E92@gridcentric.ca>
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, David Vrabel <david.vrabel@citrix.com>
Subject: Re: [Xen-devel] [PATCH 2/2] xen/privcmd: add PRIVCMD_MMAPBATCH_V2
	ioctl
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Sep 05, 2012 at 01:09:32PM -0400, Andres Lagar-Cavilla wrote:
> Super. To which branch are you applying these now? (n00b question but have to ask)

They will show up on stable/for-linus-3.7 once the overnight tests pass.

> Andres
> On Sep 5, 2012, at 12:21 PM, Konrad Rzeszutek Wilk wrote:
> 
> > On Fri, Aug 31, 2012 at 09:59:30AM -0400, Andres Lagar-Cavilla wrote:
> >> Re-spin of alternative patch after David's feedback.
> >> Thanks
> >> Andres
> > 
> > applied. fixed some whitespace issues.
> >> 
> >> commit ab351a5cef1797935b083c2f6e72800a8949c515
> >> Author: Andres Lagar-Cavilla <andres@lagarcavilla.org>
> >> Date:   Thu Aug 30 12:23:33 2012 -0400
> >> 
> >>    xen/privcmd: add PRIVCMD_MMAPBATCH_V2 ioctl
> >> 
> >>    PRIVCMD_MMAPBATCH_V2 extends PRIVCMD_MMAPBATCH with an additional
> >>    field for reporting the error code for every frame that could not be
> >>    mapped.  libxc prefers PRIVCMD_MMAPBATCH_V2 over PRIVCMD_MMAPBATCH.
> >> 
> >>    Also expand PRIVCMD_MMAPBATCH to return appropriate error-encoding top nibble
> >>    in the mfn array.
> >> 
> >>    Signed-off-by: David Vrabel <david.vrabel@citrix.com>
> >>    Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
> >> 
> >> diff --git a/drivers/xen/privcmd.c b/drivers/xen/privcmd.c
> >> index 85226cb..5386f20 100644
> >> --- a/drivers/xen/privcmd.c
> >> +++ b/drivers/xen/privcmd.c
> >> @@ -76,7 +76,7 @@ static void free_page_list(struct list_head *pages)
> >>  */
> >> static int gather_array(struct list_head *pagelist,
> >> 			unsigned nelem, size_t size,
> >> -			void __user *data)
> >> +			const void __user *data)
> >> {
> >> 	unsigned pageidx;
> >> 	void *pagedata;
> >> @@ -246,61 +246,117 @@ struct mmap_batch_state {
> >> 	domid_t domain;
> >> 	unsigned long va;
> >> 	struct vm_area_struct *vma;
> >> -	int err;
> >> -
> >> -	xen_pfn_t __user *user;
> >> +	/* A tristate: 
> >> +	 *      0 for no errors
> >> +	 *      1 if at least one error has happened (and no
> >> +	 *          -ENOENT errors have happened)
> >> +	 *      -ENOENT if at least 1 -ENOENT has happened.
> >> +	 */
> >> +	int global_error;
> >> +	/* An array for individual errors */
> >> +	int *err;
> >> +
> >> +	/* User-space mfn array to store errors in the second pass for V1. */
> >> +	xen_pfn_t __user *user_mfn;
> >> };
> >> 
> >> static int mmap_batch_fn(void *data, void *state)
> >> {
> >> 	xen_pfn_t *mfnp = data;
> >> 	struct mmap_batch_state *st = state;
> >> +	int ret;
> >> 
> >> -	if (xen_remap_domain_mfn_range(st->vma, st->va & PAGE_MASK, *mfnp, 1,
> >> -				       st->vma->vm_page_prot, st->domain) < 0) {
> >> -		*mfnp |= 0xf0000000U;
> >> -		st->err++;
> >> +	ret = xen_remap_domain_mfn_range(st->vma, st->va & PAGE_MASK, *mfnp, 1,
> >> +					 st->vma->vm_page_prot, st->domain);
> >> +
> >> +	/* Store error code for second pass. */
> >> +	*(st->err++) = ret;
> >> +
> >> +	/* And see if it affects the global_error. */
> >> +	if (ret < 0) {
> >> +		if (ret == -ENOENT)
> >> +			st->global_error = -ENOENT;
> >> +		else {
> >> +			/* Record that at least one error has happened. */
> >> +			if (st->global_error == 0)
> >> +				st->global_error = 1;
> >> +		}
> >> 	}
> >> 	st->va += PAGE_SIZE;
> >> 
> >> 	return 0;
> >> }
> >> 
> >> -static int mmap_return_errors(void *data, void *state)
> >> +static int mmap_return_errors_v1(void *data, void *state)
> >> {
> >> 	xen_pfn_t *mfnp = data;
> >> 	struct mmap_batch_state *st = state;
> >> -
> >> -	return put_user(*mfnp, st->user++);
> >> +	int err = *(st->err++);
> >> +
> >> +	/*
> >> +	 * V1 encodes the error codes in the 32bit top nibble of the 
> >> +	 * mfn (with its known limitations vis-a-vis 64 bit callers).
> >> +	 */
> >> +	*mfnp |= (err == -ENOENT) ?
> >> +				PRIVCMD_MMAPBATCH_PAGED_ERROR :
> >> +				PRIVCMD_MMAPBATCH_MFN_ERROR;
> >> +	return __put_user(*mfnp, st->user_mfn++);
> >> }
> >> 
> >> static struct vm_operations_struct privcmd_vm_ops;
> >> 
> >> -static long privcmd_ioctl_mmap_batch(void __user *udata)
> >> +static long privcmd_ioctl_mmap_batch(void __user *udata, int version)
> >> {
> >> 	int ret;
> >> -	struct privcmd_mmapbatch m;
> >> +	struct privcmd_mmapbatch_v2 m;
> >> 	struct mm_struct *mm = current->mm;
> >> 	struct vm_area_struct *vma;
> >> 	unsigned long nr_pages;
> >> 	LIST_HEAD(pagelist);
> >> +	int *err_array = NULL;
> >> 	struct mmap_batch_state state;
> >> 
> >> 	if (!xen_initial_domain())
> >> 		return -EPERM;
> >> 
> >> -	if (copy_from_user(&m, udata, sizeof(m)))
> >> -		return -EFAULT;
> >> +	switch (version) {
> >> +	case 1:
> >> +		if (copy_from_user(&m, udata, sizeof(struct privcmd_mmapbatch)))
> >> +			return -EFAULT;
> >> +		/* Returns per-frame error in m.arr. */
> >> +		m.err = NULL;
> >> +		if (!access_ok(VERIFY_WRITE, m.arr, m.num * sizeof(*m.arr)))
> >> +			return -EFAULT;
> >> +		break;
> >> +	case 2:
> >> +		if (copy_from_user(&m, udata, sizeof(struct privcmd_mmapbatch_v2)))
> >> +			return -EFAULT;
> >> +		/* Returns per-frame error code in m.err. */
> >> +		if (!access_ok(VERIFY_WRITE, m.err, m.num * (sizeof(*m.err))))
> >> +			return -EFAULT;
> >> +		break;
> >> +	default:
> >> +		return -EINVAL;
> >> +	}
> >> 
> >> 	nr_pages = m.num;
> >> 	if ((m.num <= 0) || (nr_pages > (LONG_MAX >> PAGE_SHIFT)))
> >> 		return -EINVAL;
> >> 
> >> -	ret = gather_array(&pagelist, m.num, sizeof(xen_pfn_t),
> >> -			   m.arr);
> >> +	ret = gather_array(&pagelist, m.num, sizeof(xen_pfn_t), m.arr);
> >> +
> >> +	if (ret)
> >> +		goto out;
> >> +	if (list_empty(&pagelist)) {
> >> +		ret = -EINVAL;
> >> +		goto out;
> >> +    }
> >> 
> >> -	if (ret || list_empty(&pagelist))
> >> +	err_array = kcalloc(m.num, sizeof(int), GFP_KERNEL);
> >> +	if (err_array == NULL) {
> >> +		ret = -ENOMEM;
> >> 		goto out;
> >> +	}
> >> 
> >> 	down_write(&mm->mmap_sem);
> >> 
> >> @@ -315,24 +371,34 @@ static long privcmd_ioctl_mmap_batch(void __user *udata)
> >> 		goto out;
> >> 	}
> >> 
> >> -	state.domain = m.dom;
> >> -	state.vma = vma;
> >> -	state.va = m.addr;
> >> -	state.err = 0;
> >> +	state.domain        = m.dom;
> >> +	state.vma           = vma;
> >> +	state.va            = m.addr;
> >> +	state.global_error  = 0;
> >> +	state.err           = err_array;
> >> 
> >> -	ret = traverse_pages(m.num, sizeof(xen_pfn_t),
> >> -			     &pagelist, mmap_batch_fn, &state);
> >> +	/* mmap_batch_fn guarantees ret == 0 */
> >> +	BUG_ON(traverse_pages(m.num, sizeof(xen_pfn_t),
> >> +			     &pagelist, mmap_batch_fn, &state));
> >> 
> >> 	up_write(&mm->mmap_sem);
> >> 
> >> -	if (state.err > 0) {
> >> -		state.user = m.arr;
> >> +	if (state.global_error && (version == 1)) {
> >> +		/* Write back errors in second pass. */
> >> +		state.user_mfn = (xen_pfn_t *)m.arr;
> >> +		state.err      = err_array;
> >> 		ret = traverse_pages(m.num, sizeof(xen_pfn_t),
> >> -			       &pagelist,
> >> -			       mmap_return_errors, &state);
> >> -	}
> >> +					 &pagelist, mmap_return_errors_v1, &state);
> >> +	} else
> >> +		ret = __copy_to_user(m.err, err_array, m.num * sizeof(int));
> >> +
> >> +    /* If we have not had any EFAULT-like global errors then set the global
> >> +     * error to -ENOENT if necessary. */
> >> +    if ((ret == 0) && (state.global_error == -ENOENT))
> >> +        ret = -ENOENT;
> >> 
> >> out:
> >> +	kfree(err_array);
> >> 	free_page_list(&pagelist);
> >> 
> >> 	return ret;
> >> @@ -354,7 +420,11 @@ static long privcmd_ioctl(struct file *file,
> >> 		break;
> >> 
> >> 	case IOCTL_PRIVCMD_MMAPBATCH:
> >> -		ret = privcmd_ioctl_mmap_batch(udata);
> >> +		ret = privcmd_ioctl_mmap_batch(udata, 1);
> >> +		break;
> >> +
> >> +	case IOCTL_PRIVCMD_MMAPBATCH_V2:
> >> +		ret = privcmd_ioctl_mmap_batch(udata, 2);
> >> 		break;
> >> 
> >> 	default:
> >> diff --git a/include/xen/privcmd.h b/include/xen/privcmd.h
> >> index 45c1aa1..a853168 100644
> >> --- a/include/xen/privcmd.h
> >> +++ b/include/xen/privcmd.h
> >> @@ -58,13 +58,33 @@ struct privcmd_mmapbatch {
> >> 	int num;     /* number of pages to populate */
> >> 	domid_t dom; /* target domain */
> >> 	__u64 addr;  /* virtual address */
> >> -	xen_pfn_t __user *arr; /* array of mfns - top nibble set on err */
> >> +	xen_pfn_t __user *arr; /* array of mfns - or'd with
> >> +				  PRIVCMD_MMAPBATCH_*_ERROR on err */
> >> +};
> >> +
> >> +#define PRIVCMD_MMAPBATCH_MFN_ERROR     0xf0000000U
> >> +#define PRIVCMD_MMAPBATCH_PAGED_ERROR   0x80000000U
> >> +
> >> +struct privcmd_mmapbatch_v2 {
> >> +	unsigned int num; /* number of pages to populate */
> >> +	domid_t dom;      /* target domain */
> >> +	__u64 addr;       /* virtual address */
> >> +	const xen_pfn_t __user *arr; /* array of mfns */
> >> +	int __user *err;  /* array of error codes */
> >> };
> >> 
> >> /*
> >>  * @cmd: IOCTL_PRIVCMD_HYPERCALL
> >>  * @arg: &privcmd_hypercall_t
> >>  * Return: Value returned from execution of the specified hypercall.
> >> + *
> >> + * @cmd: IOCTL_PRIVCMD_MMAPBATCH_V2
> >> + * @arg: &struct privcmd_mmapbatch_v2
> >> + * Return: 0 on success (i.e., arg->err contains valid error codes for
> >> + * each frame).  On an error other than a failed frame remap, -1 is
> >> + * returned and errno is set to EINVAL, EFAULT etc.  As an exception,
> >> + * if the operation was otherwise successful but any frame failed with
> >> + * -ENOENT, then -1 is returned and errno is set to ENOENT.
> >>  */
> >> #define IOCTL_PRIVCMD_HYPERCALL					\
> >> 	_IOC(_IOC_NONE, 'P', 0, sizeof(struct privcmd_hypercall))
> >> @@ -72,5 +92,7 @@ struct privcmd_mmapbatch {
> >> 	_IOC(_IOC_NONE, 'P', 2, sizeof(struct privcmd_mmap))
> >> #define IOCTL_PRIVCMD_MMAPBATCH					\
> >> 	_IOC(_IOC_NONE, 'P', 3, sizeof(struct privcmd_mmapbatch))
> >> +#define IOCTL_PRIVCMD_MMAPBATCH_V2				\
> >> +	_IOC(_IOC_NONE, 'P', 4, sizeof(struct privcmd_mmapbatch_v2))
> >> 
> >> #endif /* __LINUX_PUBLIC_PRIVCMD_H__ */
> >> 
> >> On Aug 30, 2012, at 8:58 AM, David Vrabel wrote:
> >> 
> >>> From: David Vrabel <david.vrabel@citrix.com>
> >>> 
> >>> PRIVCMD_MMAPBATCH_V2 extends PRIVCMD_MMAPBATCH with an additional
> >>> field for reporting the error code for every frame that could not be
> >>> mapped.  libxc prefers PRIVCMD_MMAPBATCH_V2 over PRIVCMD_MMAPBATCH.
> >>> 
> >>> Signed-off-by: David Vrabel <david.vrabel@citrix.com>
> >>> ---
> >>> drivers/xen/privcmd.c |   99 +++++++++++++++++++++++++++++++++++++++---------
> >>> include/xen/privcmd.h |   23 +++++++++++-
> >>> 2 files changed, 102 insertions(+), 20 deletions(-)
> >>> 
> >>> diff --git a/drivers/xen/privcmd.c b/drivers/xen/privcmd.c
> >>> index ccee0f1..c0e89e7 100644
> >>> --- a/drivers/xen/privcmd.c
> >>> +++ b/drivers/xen/privcmd.c
> >>> @@ -76,7 +76,7 @@ static void free_page_list(struct list_head *pages)
> >>> */
> >>> static int gather_array(struct list_head *pagelist,
> >>> 			unsigned nelem, size_t size,
> >>> -			void __user *data)
> >>> +			const void __user *data)
> >>> {
> >>> 	unsigned pageidx;
> >>> 	void *pagedata;
> >>> @@ -248,18 +248,37 @@ struct mmap_batch_state {
> >>> 	struct vm_area_struct *vma;
> >>> 	int err;
> >>> 
> >>> -	xen_pfn_t __user *user;
> >>> +	xen_pfn_t __user *user_mfn;
> >>> +	int __user *user_err;
> >>> };
> >>> 
> >>> static int mmap_batch_fn(void *data, void *state)
> >>> {
> >>> 	xen_pfn_t *mfnp = data;
> >>> 	struct mmap_batch_state *st = state;
> >>> +	int ret;
> >>> 
> >>> -	if (xen_remap_domain_mfn_range(st->vma, st->va & PAGE_MASK, *mfnp, 1,
> >>> -				       st->vma->vm_page_prot, st->domain) < 0) {
> >>> -		*mfnp |= 0xf0000000U;
> >>> -		st->err++;
> >>> +	ret = xen_remap_domain_mfn_range(st->vma, st->va & PAGE_MASK, *mfnp, 1,
> >>> +					 st->vma->vm_page_prot, st->domain);
> >>> +	if (ret < 0) {
> >>> +		/*
> >>> +		 * Error reporting is a mess but userspace relies on
> >>> +		 * it behaving this way.
> >>> +		 *
> >>> +		 * V2 needs to a) return the result of each frame's
> >>> +		 * remap; and b) return -ENOENT if any frame failed
> >>> +		 * with -ENOENT.
> >>> +		 *
> >>> +		 * In this first pass the error code is saved by
> >>> +		 * overwriting the mfn and an error is indicated in
> >>> +		 * st->err.
> >>> +		 *
> >>> +		 * The second pass by mmap_return_errors() will write
> >>> +		 * the error codes to user space and get the right
> >>> +		 * ioctl return value.
> >>> +		 */
> >>> +		*(int *)mfnp = ret;
> >>> +		st->err = ret;
> >>> 	}
> >>> 	st->va += PAGE_SIZE;
> >>> 
> >>> @@ -270,16 +289,33 @@ static int mmap_return_errors(void *data, void *state)
> >>> {
> >>> 	xen_pfn_t *mfnp = data;
> >>> 	struct mmap_batch_state *st = state;
> >>> +	int ret;
> >>> +
> >>> +	if (st->user_err) {
> >>> +		int err = *(int *)mfnp;
> >>> +
> >>> +		if (err == -ENOENT)
> >>> +			st->err = err;
> >>> 
> >>> -	return put_user(*mfnp, st->user++);
> >>> +		return __put_user(err, st->user_err++);
> >>> +	} else {
> >>> +		xen_pfn_t mfn;
> >>> +
> >>> +		ret = __get_user(mfn, st->user_mfn);
> >>> +		if (ret < 0)
> >>> +			return ret;
> >>> +
> >>> +		mfn |= PRIVCMD_MMAPBATCH_MFN_ERROR;
> >>> +		return __put_user(mfn, st->user_mfn++);
> >>> +	}
> >>> }
> >>> 
> >>> static struct vm_operations_struct privcmd_vm_ops;
> >>> 
> >>> -static long privcmd_ioctl_mmap_batch(void __user *udata)
> >>> +static long privcmd_ioctl_mmap_batch(void __user *udata, int version)
> >>> {
> >>> 	int ret;
> >>> -	struct privcmd_mmapbatch m;
> >>> +	struct privcmd_mmapbatch_v2 m;
> >>> 	struct mm_struct *mm = current->mm;
> >>> 	struct vm_area_struct *vma;
> >>> 	unsigned long nr_pages;
> >>> @@ -289,15 +325,31 @@ static long privcmd_ioctl_mmap_batch(void __user *udata)
> >>> 	if (!xen_initial_domain())
> >>> 		return -EPERM;
> >>> 
> >>> -	if (copy_from_user(&m, udata, sizeof(m)))
> >>> -		return -EFAULT;
> >>> +	switch (version) {
> >>> +	case 1:
> >>> +		if (copy_from_user(&m, udata, sizeof(struct privcmd_mmapbatch)))
> >>> +			return -EFAULT;
> >>> +		/* Returns per-frame error in m.arr. */
> >>> +		m.err = NULL;
> >>> +		if (!access_ok(VERIFY_WRITE, m.arr, m.num * sizeof(*m.arr)))
> >>> +			return -EFAULT;
> >>> +		break;
> >>> +	case 2:
> >>> +		if (copy_from_user(&m, udata, sizeof(struct privcmd_mmapbatch_v2)))
> >>> +			return -EFAULT;
> >>> +		/* Returns per-frame error code in m.err. */
> >>> +		if (!access_ok(VERIFY_WRITE, m.err, m.num * (sizeof(*m.err))))
> >>> +			return -EFAULT;
> >>> +		break;
> >>> +	default:
> >>> +		return -EINVAL;
> >>> +	}
> >>> 
> >>> 	nr_pages = m.num;
> >>> 	if ((m.num <= 0) || (nr_pages > (LONG_MAX >> PAGE_SHIFT)))
> >>> 		return -EINVAL;
> >>> 
> >>> -	ret = gather_array(&pagelist, m.num, sizeof(xen_pfn_t),
> >>> -			   m.arr);
> >>> +	ret = gather_array(&pagelist, m.num, sizeof(xen_pfn_t), m.arr);
> >>> 
> >>> 	if (ret || list_empty(&pagelist))
> >>> 		goto out;
> >>> @@ -325,12 +377,17 @@ static long privcmd_ioctl_mmap_batch(void __user *udata)
> >>> 
> >>> 	up_write(&mm->mmap_sem);
> >>> 
> >>> -	if (state.err > 0) {
> >>> -		state.user = m.arr;
> >>> +	if (state.err) {
> >>> +		state.err = 0;
> >>> +		state.user_mfn = (xen_pfn_t *)m.arr;
> >>> +		state.user_err = m.err;
> >>> 		ret = traverse_pages(m.num, sizeof(xen_pfn_t),
> >>> -			       &pagelist,
> >>> -			       mmap_return_errors, &state);
> >>> -	}
> >>> +				     &pagelist,
> >>> +				     mmap_return_errors, &state);
> >>> +		if (ret >= 0)
> >>> +			ret = state.err;
> >>> +	} else if (m.err)
> >>> +		__clear_user(m.err, m.num * sizeof(*m.err));
> >>> 
> >>> out:
> >>> 	free_page_list(&pagelist);
> >>> @@ -354,7 +411,11 @@ static long privcmd_ioctl(struct file *file,
> >>> 		break;
> >>> 
> >>> 	case IOCTL_PRIVCMD_MMAPBATCH:
> >>> -		ret = privcmd_ioctl_mmap_batch(udata);
> >>> +		ret = privcmd_ioctl_mmap_batch(udata, 1);
> >>> +		break;
> >>> +
> >>> +	case IOCTL_PRIVCMD_MMAPBATCH_V2:
> >>> +		ret = privcmd_ioctl_mmap_batch(udata, 2);
> >>> 		break;
> >>> 
> >>> 	default:
> >>> diff --git a/include/xen/privcmd.h b/include/xen/privcmd.h
> >>> index 17857fb..f60d75c 100644
> >>> --- a/include/xen/privcmd.h
> >>> +++ b/include/xen/privcmd.h
> >>> @@ -59,13 +59,32 @@ struct privcmd_mmapbatch {
> >>> 	int num;     /* number of pages to populate */
> >>> 	domid_t dom; /* target domain */
> >>> 	__u64 addr;  /* virtual address */
> >>> -	xen_pfn_t __user *arr; /* array of mfns - top nibble set on err */
> >>> +	xen_pfn_t __user *arr; /* array of mfns - or'd with
> >>> +				  PRIVCMD_MMAPBATCH_MFN_ERROR on err */
> >>> +};
> >>> +
> >>> +#define PRIVCMD_MMAPBATCH_MFN_ERROR 0xf0000000U
> >>> +
> >>> +struct privcmd_mmapbatch_v2 {
> >>> +	unsigned int num; /* number of pages to populate */
> >>> +	domid_t dom;      /* target domain */
> >>> +	__u64 addr;       /* virtual address */
> >>> +	const xen_pfn_t __user *arr; /* array of mfns */
> >>> +	int __user *err;  /* array of error codes */
> >>> };
> >>> 
> >>> /*
> >>> * @cmd: IOCTL_PRIVCMD_HYPERCALL
> >>> * @arg: &privcmd_hypercall_t
> >>> * Return: Value returned from execution of the specified hypercall.
> >>> + *
> >>> + * @cmd: IOCTL_PRIVCMD_MMAPBATCH_V2
> >>> + * @arg: &struct privcmd_mmapbatch_v2
> >>> + * Return: 0 on success (i.e., arg->err contains valid error codes for
> >>> + * each frame).  On an error other than a failed frame remap, -1 is
> >>> + * returned and errno is set to EINVAL, EFAULT etc.  As an exception,
> >>> + * if the operation was otherwise successful but any frame failed with
> >>> + * -ENOENT, then -1 is returned and errno is set to ENOENT.
> >>> */
> >>> #define IOCTL_PRIVCMD_HYPERCALL					\
> >>> 	_IOC(_IOC_NONE, 'P', 0, sizeof(struct privcmd_hypercall))
> >>> @@ -73,5 +92,7 @@ struct privcmd_mmapbatch {
> >>> 	_IOC(_IOC_NONE, 'P', 2, sizeof(struct privcmd_mmap))
> >>> #define IOCTL_PRIVCMD_MMAPBATCH					\
> >>> 	_IOC(_IOC_NONE, 'P', 3, sizeof(struct privcmd_mmapbatch))
> >>> +#define IOCTL_PRIVCMD_MMAPBATCH_V2				\
> >>> +	_IOC(_IOC_NONE, 'P', 4, sizeof(struct privcmd_mmapbatch_v2))
> >>> 
> >>> #endif /* __LINUX_PUBLIC_PRIVCMD_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 Wed Sep 05 17:53:39 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Sep 2012 17:53: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 1T9Jmy-00007h-1p; Wed, 05 Sep 2012 17:53:20 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <lists+xen@internecto.net>) id 1T9Jmx-00007X-CN
	for xen-devel@lists.xen.org; Wed, 05 Sep 2012 17:53:19 +0000
Received: from [85.158.143.99:59539] by server-3.bemta-4.messagelabs.com id
	D3/32-08232-E8197405; Wed, 05 Sep 2012 17:53:18 +0000
X-Env-Sender: lists+xen@internecto.net
X-Msg-Ref: server-3.tower-216.messagelabs.com!1346867595!28155512!1
X-Originating-IP: [176.9.245.29]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23433 invoked from network); 5 Sep 2012 17:53:18 -0000
Received: from polaris.internecto.net (HELO mx1.internecto.net) (176.9.245.29)
	by server-3.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 5 Sep 2012 17:53:18 -0000
Received: from localhost (localhost [127.0.0.1])
	by mx1.internecto.net (Postfix) with ESMTP id 48273A0086;
	Wed,  5 Sep 2012 17:53:11 +0000 (UTC)
X-Virus-Scanned: Debian amavisd-new at mail.internecto.net
Received: from mx1.internecto.net ([127.0.0.1])
	by localhost (mail.polaris.internecto.net [127.0.0.1]) (amavisd-new,
	port 10024)
	with ESMTP id Ecj6FGasp5gl; Wed,  5 Sep 2012 17:53:10 +0000 (UTC)
Received: from internecto.net (5ED4FDEB.cm-7-5d.dynamic.ziggo.nl
	[94.212.253.235])
	(using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits))
	(Client did not present a certificate)
	(Authenticated sender: lists@internecto.net)
	by mx1.internecto.net (Postfix) with ESMTPSA id BE728A0058;
	Wed,  5 Sep 2012 17:53:10 +0000 (UTC)
Date: Wed, 5 Sep 2012 19:53:07 +0200
From: Mark van Dijk <lists+xen@internecto.net>
To: xen-users@lists.xen.org
Message-ID: <20120905195307.101d0cbc@internecto.net>
In-Reply-To: <20120905152926.GM8912@reaktio.net>
References: <1346665360.25864.2.camel@zakaz.uk.xensource.com>
	<20120905152926.GM8912@reaktio.net>
Organization: Internecto SIS
X-Mailer: Claws Mail 3.8.0 (GTK+ 2.24.10; x86_64-pc-linux-gnu)
Mime-Version: 1.0
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [Xen-users]  Xen 4.2.0 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

>> tools, nice to have:
>
>      * pygrub support for ext4 on rhel5/centos5.
>        Roger already sent a patch for this.

I'd love to see some kind of extlinux (or grub2) that can replace the
current pv-grub. Both support ext4 and, more importantly imho,
btrfs, now that is one really cool filesystem.

Grub0.97 is/will be being deprecated on an increasing number of
distributions. And pv-grub is safer than pygrub because pygrub executes
in the dom0 and pv-grub in the domU, if I understand correctly.

Anyone willing to share thoughts on the possibility of 'pv-extlinux?'

-- 
Stay in touch,
Mark van Dijk.                ,---------------------------------
-----------------------------'         Wed Sep 05 17:44 UTC 2012
Today is Pungenday, the 29th day of Bureaucracy in the YOLD 3178

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

From xen-devel-bounces@lists.xen.org Wed Sep 05 17:53:39 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Sep 2012 17:53: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 1T9Jmy-00007h-1p; Wed, 05 Sep 2012 17:53:20 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <lists+xen@internecto.net>) id 1T9Jmx-00007X-CN
	for xen-devel@lists.xen.org; Wed, 05 Sep 2012 17:53:19 +0000
Received: from [85.158.143.99:59539] by server-3.bemta-4.messagelabs.com id
	D3/32-08232-E8197405; Wed, 05 Sep 2012 17:53:18 +0000
X-Env-Sender: lists+xen@internecto.net
X-Msg-Ref: server-3.tower-216.messagelabs.com!1346867595!28155512!1
X-Originating-IP: [176.9.245.29]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23433 invoked from network); 5 Sep 2012 17:53:18 -0000
Received: from polaris.internecto.net (HELO mx1.internecto.net) (176.9.245.29)
	by server-3.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 5 Sep 2012 17:53:18 -0000
Received: from localhost (localhost [127.0.0.1])
	by mx1.internecto.net (Postfix) with ESMTP id 48273A0086;
	Wed,  5 Sep 2012 17:53:11 +0000 (UTC)
X-Virus-Scanned: Debian amavisd-new at mail.internecto.net
Received: from mx1.internecto.net ([127.0.0.1])
	by localhost (mail.polaris.internecto.net [127.0.0.1]) (amavisd-new,
	port 10024)
	with ESMTP id Ecj6FGasp5gl; Wed,  5 Sep 2012 17:53:10 +0000 (UTC)
Received: from internecto.net (5ED4FDEB.cm-7-5d.dynamic.ziggo.nl
	[94.212.253.235])
	(using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits))
	(Client did not present a certificate)
	(Authenticated sender: lists@internecto.net)
	by mx1.internecto.net (Postfix) with ESMTPSA id BE728A0058;
	Wed,  5 Sep 2012 17:53:10 +0000 (UTC)
Date: Wed, 5 Sep 2012 19:53:07 +0200
From: Mark van Dijk <lists+xen@internecto.net>
To: xen-users@lists.xen.org
Message-ID: <20120905195307.101d0cbc@internecto.net>
In-Reply-To: <20120905152926.GM8912@reaktio.net>
References: <1346665360.25864.2.camel@zakaz.uk.xensource.com>
	<20120905152926.GM8912@reaktio.net>
Organization: Internecto SIS
X-Mailer: Claws Mail 3.8.0 (GTK+ 2.24.10; x86_64-pc-linux-gnu)
Mime-Version: 1.0
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [Xen-users]  Xen 4.2.0 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

>> tools, nice to have:
>
>      * pygrub support for ext4 on rhel5/centos5.
>        Roger already sent a patch for this.

I'd love to see some kind of extlinux (or grub2) that can replace the
current pv-grub. Both support ext4 and, more importantly imho,
btrfs, now that is one really cool filesystem.

Grub0.97 is/will be being deprecated on an increasing number of
distributions. And pv-grub is safer than pygrub because pygrub executes
in the dom0 and pv-grub in the domU, if I understand correctly.

Anyone willing to share thoughts on the possibility of 'pv-extlinux?'

-- 
Stay in touch,
Mark van Dijk.                ,---------------------------------
-----------------------------'         Wed Sep 05 17:44 UTC 2012
Today is Pungenday, the 29th day of Bureaucracy in the YOLD 3178

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

From xen-devel-bounces@lists.xen.org Wed Sep 05 17:58:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Sep 2012 17:58:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9JrK-0000Vr-De; Wed, 05 Sep 2012 17:57: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 1T9JrI-0000VW-FP
	for xen-devel@lists.xen.org; Wed, 05 Sep 2012 17:57:48 +0000
Received: from [85.158.139.83:45969] by server-10.bemta-5.messagelabs.com id
	CD/42-10969-B9297405; Wed, 05 Sep 2012 17:57:47 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1346867867!21426399!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTE5ODY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26408 invoked from network); 5 Sep 2012 17:57:47 -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;
	5 Sep 2012 17:57:47 -0000
X-IronPort-AV: E=Sophos;i="4.80,375,1344211200"; d="scan'208";a="14365823"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Sep 2012 17:57:47 +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.279.1; Wed, 5 Sep 2012
	18:57:46 +0100
Message-ID: <1346867866.10570.4.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Pasi =?ISO-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
Date: Wed, 5 Sep 2012 18:57:46 +0100
In-Reply-To: <20120905152926.GM8912@reaktio.net>
References: <1346665360.25864.2.camel@zakaz.uk.xensource.com>
	<20120905152926.GM8912@reaktio.net>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: xen-users <xen-users@lists.xen.org>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.2.0 Release Plan / TODO
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-09-05 at 16:29 +0100, Pasi K=E4rkk=E4inen wrote:
> On Mon, Sep 03, 2012 at 10:42:40AM +0100, Ian Campbell wrote:
> > =

> > tools, nice to have:
> > =

> =

>       * pygrub support for ext4 on rhel5/centos5.
>         Roger already sent a patch for this.

As I said in the introduction we are intending to do the final RC on
Friday (i.e. the day after tomorrow).

So at this stage in the release I'm afraid you will have to do a *much*
better job of justifying why any change should go on the list (and
therefore be considered for inclusion in 4.2.0) than 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 Sep 05 17:58:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Sep 2012 17:58:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9JrK-0000Vr-De; Wed, 05 Sep 2012 17:57: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 1T9JrI-0000VW-FP
	for xen-devel@lists.xen.org; Wed, 05 Sep 2012 17:57:48 +0000
Received: from [85.158.139.83:45969] by server-10.bemta-5.messagelabs.com id
	CD/42-10969-B9297405; Wed, 05 Sep 2012 17:57:47 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1346867867!21426399!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTE5ODY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26408 invoked from network); 5 Sep 2012 17:57:47 -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;
	5 Sep 2012 17:57:47 -0000
X-IronPort-AV: E=Sophos;i="4.80,375,1344211200"; d="scan'208";a="14365823"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Sep 2012 17:57:47 +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.279.1; Wed, 5 Sep 2012
	18:57:46 +0100
Message-ID: <1346867866.10570.4.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Pasi =?ISO-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
Date: Wed, 5 Sep 2012 18:57:46 +0100
In-Reply-To: <20120905152926.GM8912@reaktio.net>
References: <1346665360.25864.2.camel@zakaz.uk.xensource.com>
	<20120905152926.GM8912@reaktio.net>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: xen-users <xen-users@lists.xen.org>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.2.0 Release Plan / TODO
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-09-05 at 16:29 +0100, Pasi K=E4rkk=E4inen wrote:
> On Mon, Sep 03, 2012 at 10:42:40AM +0100, Ian Campbell wrote:
> > =

> > tools, nice to have:
> > =

> =

>       * pygrub support for ext4 on rhel5/centos5.
>         Roger already sent a patch for this.

As I said in the introduction we are intending to do the final RC on
Friday (i.e. the day after tomorrow).

So at this stage in the release I'm afraid you will have to do a *much*
better job of justifying why any change should go on the list (and
therefore be considered for inclusion in 4.2.0) than 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 Sep 05 18:05:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Sep 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 1T9Jy9-00014p-Ua; Wed, 05 Sep 2012 18:04:53 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1T9Jy8-00014g-O2
	for xen-devel@lists.xen.org; Wed, 05 Sep 2012 18:04:53 +0000
Received: from [85.158.139.83:22250] by server-10.bemta-5.messagelabs.com id
	55/BA-10969-44497405; Wed, 05 Sep 2012 18:04:52 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1346868291!28757949!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTE5ODY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22487 invoked from network); 5 Sep 2012 18:04:51 -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;
	5 Sep 2012 18:04:51 -0000
X-IronPort-AV: E=Sophos;i="4.80,375,1344211200"; d="scan'208";a="14365873"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Sep 2012 18:04: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.279.1; Wed, 5 Sep 2012
	19:04:50 +0100
Message-ID: <1346868289.10570.6.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Roger Pau Monne <roger.pau@citrix.com>
Date: Wed, 5 Sep 2012 19:04:49 +0100
In-Reply-To: <1346846602-1109-1-git-send-email-roger.pau@citrix.com>
References: <20120905030239.GJ8912@reaktio.net>
	<1346846602-1109-1-git-send-email-roger.pau@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] libfsimage: add ext4 support for CentOS 5.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 Wed, 2012-09-05 at 13:03 +0100, Roger Pau Monne wrote:
> CentOS 5.x forked e2fs ext4 support into a different package called
> e4fs, and so headers and library names changed from ext2fs to ext4fs.
> Check if ext4fs/ext2fs.h and -lext4fs work, and use that instead of
> ext2fs to build libfsimage. This patch assumes that if the ext4fs
> library is present it should always be used instead of ext2fs.
> 
> This patch includes a rework of the ext2fs check, a new ext4fs check
> and a minor modification in libfsimage to use the correct library.
> 
> Signed-off-by: Roger Pau Monne <roger.pau@citrix.com>

Thanks.

Any patch which is intended for 4.2 at this stage needs to come with
some rationale as to why it is acceptable at this late stage.

Therefore unless someone can argue convincingly for it this is 4.3
material.

Ian.

> ---
> Please re-run autogen.sh after applying
> ---
>  config/Tools.mk.in                       |    2 +-
>  tools/config.h.in                        |    3 +++
>  tools/configure.ac                       |    4 ++--
>  tools/libfsimage/Makefile                |    2 +-
>  tools/libfsimage/ext2fs-lib/Makefile     |    5 ++++-
>  tools/libfsimage/ext2fs-lib/ext2fs-lib.c |    5 ++++-
>  tools/m4/extfs.m4                        |   20 ++++++++++++++++++++
>  7 files changed, 35 insertions(+), 6 deletions(-)
>  create mode 100644 tools/m4/extfs.m4
> 
> diff --git a/config/Tools.mk.in b/config/Tools.mk.in
> index 8a52bcc..0859b36 100644
> --- a/config/Tools.mk.in
> +++ b/config/Tools.mk.in
> @@ -56,5 +56,5 @@ CONFIG_SYSTEM_LIBAIO:= @system_aio@
>  ZLIB                := @zlib@
>  CONFIG_LIBICONV     := @libiconv@
>  CONFIG_GCRYPT       := @libgcrypt@
> -CONFIG_EXT2FS       := @libext2fs@
> +EXTFS_LIBS          := @EXTFS_LIBS@
>  CURSES_LIBS         := @CURSES_LIBS@
> diff --git a/tools/config.h.in b/tools/config.h.in
> index bc1ed10..ab726f6 100644
> --- a/tools/config.h.in
> +++ b/tools/config.h.in
> @@ -45,6 +45,9 @@
>  /* libutil header file name */
>  #undef INCLUDE_LIBUTIL_H
>  
> +/* e2fs/e4fs header file name */
> +#undef INCLUDE_EXTFS_H
> +
>  /* Define to the address where bug reports for this package should be sent. */
>  #undef PACKAGE_BUGREPORT
>  
> diff --git a/tools/configure.ac b/tools/configure.ac
> index bb497cc..938bc8b 100644
> --- a/tools/configure.ac
> +++ b/tools/configure.ac
> @@ -35,6 +35,7 @@ m4_include([m4/pkg.m4])
>  m4_include([m4/curses.m4])
>  m4_include([m4/pthread.m4])
>  m4_include([m4/ptyfuncs.m4])
> +m4_include([m4/extfs.m4])
>  
>  # Enable/disable options
>  AX_ARG_DEFAULT_DISABLE([githttp], [Download GIT repositories via HTTP])
> @@ -138,8 +139,7 @@ AC_SUBST(zlib)
>  AC_CHECK_LIB([aio], [io_setup], [system_aio="y"], [system_aio="n"])
>  AC_SUBST(system_aio)
>  AC_CHECK_LIB([crypto], [MD5], [], [AC_MSG_ERROR([Could not find libcrypto])])
> -AC_CHECK_LIB([ext2fs], [ext2fs_open2], [libext2fs="y"], [libext2fs="n"])
> -AC_SUBST(libext2fs)
> +AX_CHECK_EXTFS
>  AC_CHECK_LIB([gcrypt], [gcry_md_hash_buffer], [libgcrypt="y"], [libgcrypt="n"])
>  AC_SUBST(libgcrypt)
>  AX_CHECK_PTHREAD
> diff --git a/tools/libfsimage/Makefile b/tools/libfsimage/Makefile
> index 5a506f3..69fd18a 100644
> --- a/tools/libfsimage/Makefile
> +++ b/tools/libfsimage/Makefile
> @@ -3,7 +3,7 @@ include $(XEN_ROOT)/tools/Rules.mk
>  
>  SUBDIRS-y = common ufs reiserfs iso9660 fat zfs
>  SUBDIRS-$(CONFIG_X86) += xfs
> -ifeq ($(CONFIG_EXT2FS), y)
> +ifneq ($(EXTFS_LIBS), )
>      SUBDIRS-y += ext2fs-lib
>  else
>      SUBDIRS-y += ext2fs
> diff --git a/tools/libfsimage/ext2fs-lib/Makefile b/tools/libfsimage/ext2fs-lib/Makefile
> index 142207f..671fbff 100644
> --- a/tools/libfsimage/ext2fs-lib/Makefile
> +++ b/tools/libfsimage/ext2fs-lib/Makefile
> @@ -4,7 +4,10 @@ LIB_SRCS-y = ext2fs-lib.c
>  
>  FS = ext2fs-lib
>  
> -FS_LIBDEPS = -lext2fs
> +FS_LIBDEPS = $(EXTFS_LIBS)
> +
> +# Include configure output (config.h) to headers search path
> +CFLAGS += -I$(XEN_ROOT)/tools
>  
>  .PHONY: all
>  all: fs-all
> diff --git a/tools/libfsimage/ext2fs-lib/ext2fs-lib.c b/tools/libfsimage/ext2fs-lib/ext2fs-lib.c
> index 36a27dc..ed47146 100644
> --- a/tools/libfsimage/ext2fs-lib/ext2fs-lib.c
> +++ b/tools/libfsimage/ext2fs-lib/ext2fs-lib.c
> @@ -21,8 +21,11 @@
>   * Use is subject to license terms.
>   */
>  
> +/* Include output from configure */
> +#include <config.h>
> +
>  #include <fsimage_plugin.h>
> -#include <ext2fs/ext2fs.h>
> +#include INCLUDE_EXTFS_H
>  #include <errno.h>
>  #include <inttypes.h>
>  
> diff --git a/tools/m4/extfs.m4 b/tools/m4/extfs.m4
> new file mode 100644
> index 0000000..7309da9
> --- /dev/null
> +++ b/tools/m4/extfs.m4
> @@ -0,0 +1,20 @@
> +AC_DEFUN([AX_CHECK_EXTFS], [
> +AC_CHECK_HEADER([ext2fs/ext2fs.h], [
> +AC_CHECK_LIB([ext2fs], [ext2fs_open2], [
> +    AC_DEFINE([INCLUDE_EXTFS_H], [<ext2fs/ext2fs.h>],
> +              [Define extfs header to use])
> +    EXTFS_LIBS="-lext2fs"
> +])
> +])
> +dnl This is a temporary hack for CentOS 5.x, which split the ext4 support
> +dnl of ext2fs in a different package. Once CentOS 5.x is no longer supported
> +dnl we can remove this.
> +AC_CHECK_HEADER([ext4fs/ext2fs.h], [
> +AC_CHECK_LIB([ext4fs], [ext2fs_open2], [
> +    AC_DEFINE([INCLUDE_EXTFS_H], [<ext4fs/ext2fs.h>],
> +              [Define extfs header to use])
> +    EXTFS_LIBS="-lext4fs"
> +])
> +])
> +AC_SUBST(EXTFS_LIBS)
> +])



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

From xen-devel-bounces@lists.xen.org Wed Sep 05 18:05:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Sep 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 1T9Jy9-00014p-Ua; Wed, 05 Sep 2012 18:04:53 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1T9Jy8-00014g-O2
	for xen-devel@lists.xen.org; Wed, 05 Sep 2012 18:04:53 +0000
Received: from [85.158.139.83:22250] by server-10.bemta-5.messagelabs.com id
	55/BA-10969-44497405; Wed, 05 Sep 2012 18:04:52 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1346868291!28757949!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTE5ODY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22487 invoked from network); 5 Sep 2012 18:04:51 -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;
	5 Sep 2012 18:04:51 -0000
X-IronPort-AV: E=Sophos;i="4.80,375,1344211200"; d="scan'208";a="14365873"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Sep 2012 18:04: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.279.1; Wed, 5 Sep 2012
	19:04:50 +0100
Message-ID: <1346868289.10570.6.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Roger Pau Monne <roger.pau@citrix.com>
Date: Wed, 5 Sep 2012 19:04:49 +0100
In-Reply-To: <1346846602-1109-1-git-send-email-roger.pau@citrix.com>
References: <20120905030239.GJ8912@reaktio.net>
	<1346846602-1109-1-git-send-email-roger.pau@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] libfsimage: add ext4 support for CentOS 5.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 Wed, 2012-09-05 at 13:03 +0100, Roger Pau Monne wrote:
> CentOS 5.x forked e2fs ext4 support into a different package called
> e4fs, and so headers and library names changed from ext2fs to ext4fs.
> Check if ext4fs/ext2fs.h and -lext4fs work, and use that instead of
> ext2fs to build libfsimage. This patch assumes that if the ext4fs
> library is present it should always be used instead of ext2fs.
> 
> This patch includes a rework of the ext2fs check, a new ext4fs check
> and a minor modification in libfsimage to use the correct library.
> 
> Signed-off-by: Roger Pau Monne <roger.pau@citrix.com>

Thanks.

Any patch which is intended for 4.2 at this stage needs to come with
some rationale as to why it is acceptable at this late stage.

Therefore unless someone can argue convincingly for it this is 4.3
material.

Ian.

> ---
> Please re-run autogen.sh after applying
> ---
>  config/Tools.mk.in                       |    2 +-
>  tools/config.h.in                        |    3 +++
>  tools/configure.ac                       |    4 ++--
>  tools/libfsimage/Makefile                |    2 +-
>  tools/libfsimage/ext2fs-lib/Makefile     |    5 ++++-
>  tools/libfsimage/ext2fs-lib/ext2fs-lib.c |    5 ++++-
>  tools/m4/extfs.m4                        |   20 ++++++++++++++++++++
>  7 files changed, 35 insertions(+), 6 deletions(-)
>  create mode 100644 tools/m4/extfs.m4
> 
> diff --git a/config/Tools.mk.in b/config/Tools.mk.in
> index 8a52bcc..0859b36 100644
> --- a/config/Tools.mk.in
> +++ b/config/Tools.mk.in
> @@ -56,5 +56,5 @@ CONFIG_SYSTEM_LIBAIO:= @system_aio@
>  ZLIB                := @zlib@
>  CONFIG_LIBICONV     := @libiconv@
>  CONFIG_GCRYPT       := @libgcrypt@
> -CONFIG_EXT2FS       := @libext2fs@
> +EXTFS_LIBS          := @EXTFS_LIBS@
>  CURSES_LIBS         := @CURSES_LIBS@
> diff --git a/tools/config.h.in b/tools/config.h.in
> index bc1ed10..ab726f6 100644
> --- a/tools/config.h.in
> +++ b/tools/config.h.in
> @@ -45,6 +45,9 @@
>  /* libutil header file name */
>  #undef INCLUDE_LIBUTIL_H
>  
> +/* e2fs/e4fs header file name */
> +#undef INCLUDE_EXTFS_H
> +
>  /* Define to the address where bug reports for this package should be sent. */
>  #undef PACKAGE_BUGREPORT
>  
> diff --git a/tools/configure.ac b/tools/configure.ac
> index bb497cc..938bc8b 100644
> --- a/tools/configure.ac
> +++ b/tools/configure.ac
> @@ -35,6 +35,7 @@ m4_include([m4/pkg.m4])
>  m4_include([m4/curses.m4])
>  m4_include([m4/pthread.m4])
>  m4_include([m4/ptyfuncs.m4])
> +m4_include([m4/extfs.m4])
>  
>  # Enable/disable options
>  AX_ARG_DEFAULT_DISABLE([githttp], [Download GIT repositories via HTTP])
> @@ -138,8 +139,7 @@ AC_SUBST(zlib)
>  AC_CHECK_LIB([aio], [io_setup], [system_aio="y"], [system_aio="n"])
>  AC_SUBST(system_aio)
>  AC_CHECK_LIB([crypto], [MD5], [], [AC_MSG_ERROR([Could not find libcrypto])])
> -AC_CHECK_LIB([ext2fs], [ext2fs_open2], [libext2fs="y"], [libext2fs="n"])
> -AC_SUBST(libext2fs)
> +AX_CHECK_EXTFS
>  AC_CHECK_LIB([gcrypt], [gcry_md_hash_buffer], [libgcrypt="y"], [libgcrypt="n"])
>  AC_SUBST(libgcrypt)
>  AX_CHECK_PTHREAD
> diff --git a/tools/libfsimage/Makefile b/tools/libfsimage/Makefile
> index 5a506f3..69fd18a 100644
> --- a/tools/libfsimage/Makefile
> +++ b/tools/libfsimage/Makefile
> @@ -3,7 +3,7 @@ include $(XEN_ROOT)/tools/Rules.mk
>  
>  SUBDIRS-y = common ufs reiserfs iso9660 fat zfs
>  SUBDIRS-$(CONFIG_X86) += xfs
> -ifeq ($(CONFIG_EXT2FS), y)
> +ifneq ($(EXTFS_LIBS), )
>      SUBDIRS-y += ext2fs-lib
>  else
>      SUBDIRS-y += ext2fs
> diff --git a/tools/libfsimage/ext2fs-lib/Makefile b/tools/libfsimage/ext2fs-lib/Makefile
> index 142207f..671fbff 100644
> --- a/tools/libfsimage/ext2fs-lib/Makefile
> +++ b/tools/libfsimage/ext2fs-lib/Makefile
> @@ -4,7 +4,10 @@ LIB_SRCS-y = ext2fs-lib.c
>  
>  FS = ext2fs-lib
>  
> -FS_LIBDEPS = -lext2fs
> +FS_LIBDEPS = $(EXTFS_LIBS)
> +
> +# Include configure output (config.h) to headers search path
> +CFLAGS += -I$(XEN_ROOT)/tools
>  
>  .PHONY: all
>  all: fs-all
> diff --git a/tools/libfsimage/ext2fs-lib/ext2fs-lib.c b/tools/libfsimage/ext2fs-lib/ext2fs-lib.c
> index 36a27dc..ed47146 100644
> --- a/tools/libfsimage/ext2fs-lib/ext2fs-lib.c
> +++ b/tools/libfsimage/ext2fs-lib/ext2fs-lib.c
> @@ -21,8 +21,11 @@
>   * Use is subject to license terms.
>   */
>  
> +/* Include output from configure */
> +#include <config.h>
> +
>  #include <fsimage_plugin.h>
> -#include <ext2fs/ext2fs.h>
> +#include INCLUDE_EXTFS_H
>  #include <errno.h>
>  #include <inttypes.h>
>  
> diff --git a/tools/m4/extfs.m4 b/tools/m4/extfs.m4
> new file mode 100644
> index 0000000..7309da9
> --- /dev/null
> +++ b/tools/m4/extfs.m4
> @@ -0,0 +1,20 @@
> +AC_DEFUN([AX_CHECK_EXTFS], [
> +AC_CHECK_HEADER([ext2fs/ext2fs.h], [
> +AC_CHECK_LIB([ext2fs], [ext2fs_open2], [
> +    AC_DEFINE([INCLUDE_EXTFS_H], [<ext2fs/ext2fs.h>],
> +              [Define extfs header to use])
> +    EXTFS_LIBS="-lext2fs"
> +])
> +])
> +dnl This is a temporary hack for CentOS 5.x, which split the ext4 support
> +dnl of ext2fs in a different package. Once CentOS 5.x is no longer supported
> +dnl we can remove this.
> +AC_CHECK_HEADER([ext4fs/ext2fs.h], [
> +AC_CHECK_LIB([ext4fs], [ext2fs_open2], [
> +    AC_DEFINE([INCLUDE_EXTFS_H], [<ext4fs/ext2fs.h>],
> +              [Define extfs header to use])
> +    EXTFS_LIBS="-lext4fs"
> +])
> +])
> +AC_SUBST(EXTFS_LIBS)
> +])



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

From xen-devel-bounces@lists.xen.org Wed Sep 05 18:53:09 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Sep 2012 18:53:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9KiZ-0002GP-1t; Wed, 05 Sep 2012 18:52:51 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mukesh.rathor@oracle.com>) id 1T9KiX-0002GI-4b
	for Xen-devel@lists.xensource.com; Wed, 05 Sep 2012 18:52:49 +0000
Received: from [85.158.138.51:44031] by server-2.bemta-3.messagelabs.com id
	65/1E-04862-08F97405; Wed, 05 Sep 2012 18:52:48 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1346871166!10185507!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDczODkxOA==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29073 invoked from network); 5 Sep 2012 18:52:47 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-13.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 5 Sep 2012 18:52:47 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q85Iqf2c007195
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 5 Sep 2012 18:52:42 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
	q85IqfPG027450
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 5 Sep 2012 18:52: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
	q85IqeEK008209; Wed, 5 Sep 2012 13:52:40 -0500
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 05 Sep 2012 11:52:40 -0700
Date: Wed, 5 Sep 2012 11:52:39 -0700
From: Mukesh Rathor <mukesh.rathor@oracle.com>
To: Ben Guthro <ben@guthro.net>
Message-ID: <20120905115239.486ff01b@mantra.us.oracle.com>
In-Reply-To: <CAOvdn6UPzBncAU7Wi3PNPaMX6DRXkg8Bb92fJN8i5VdYciuEgg@mail.gmail.com>
References: <20120829143512.7c579fb1@mantra.us.oracle.com>
	<20120829144125.25a5eb3e@mantra.us.oracle.com>
	<CAOvdn6UPzBncAU7Wi3PNPaMX6DRXkg8Bb92fJN8i5VdYciuEgg@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
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: "Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
	msw@amazon.com
Subject: Re: [Xen-devel] xen debugger (kdb/xdb/hdb) patch for c/s 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 Wed, 5 Sep 2012 12:02:13 -0400
Ben Guthro <ben@guthro.net> wrote:

> FYI - I applied this against the tip, and turned it on (and debug off)
> - but I get link errors:
> 
> ld    -melf_x86_64  -T xen.lds -N prelink.o \
> 	    /data/home/bguthro/dev/orc-newdev.git/orc-xen/xen-4.2/xen/common/symbols-dummy.o
> -o /data/home/bguthro/dev/orc-newdev.git/orc-xen/xen-4.2/xen/.xen-syms.0
> prelink.o: In function `kdb_cmdf_f':
> /data/home/bguthro/dev/orc-newdev.git/orc-xen/xen-4.2/xen/kdb/kdb_cmds.c:510:
> undefined reference to `show_trace'
> /data/home/bguthro/dev/orc-newdev.git/orc-xen/xen-4.2/xen/kdb/kdb_cmds.c:510:(.text+0x11f6b9):
> relocation truncated to fit: R_X86_64_PC32 against undefined symbol
> `show_trace'
> ld: /data/home/bguthro/dev/orc-newdev.git/orc-xen/xen-4.2/xen/.xen-syms.0:
> hidden symbol `show_trace' isn't defined
> ld: final link failed: Bad value

It's prob static. Just un-static it :). Missed in patch because we
might have it that way here already in our tree.

LMK. 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 Sep 05 18:53:09 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Sep 2012 18:53:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9KiZ-0002GP-1t; Wed, 05 Sep 2012 18:52:51 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mukesh.rathor@oracle.com>) id 1T9KiX-0002GI-4b
	for Xen-devel@lists.xensource.com; Wed, 05 Sep 2012 18:52:49 +0000
Received: from [85.158.138.51:44031] by server-2.bemta-3.messagelabs.com id
	65/1E-04862-08F97405; Wed, 05 Sep 2012 18:52:48 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1346871166!10185507!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDczODkxOA==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29073 invoked from network); 5 Sep 2012 18:52:47 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-13.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 5 Sep 2012 18:52:47 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q85Iqf2c007195
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 5 Sep 2012 18:52:42 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
	q85IqfPG027450
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 5 Sep 2012 18:52: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
	q85IqeEK008209; Wed, 5 Sep 2012 13:52:40 -0500
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 05 Sep 2012 11:52:40 -0700
Date: Wed, 5 Sep 2012 11:52:39 -0700
From: Mukesh Rathor <mukesh.rathor@oracle.com>
To: Ben Guthro <ben@guthro.net>
Message-ID: <20120905115239.486ff01b@mantra.us.oracle.com>
In-Reply-To: <CAOvdn6UPzBncAU7Wi3PNPaMX6DRXkg8Bb92fJN8i5VdYciuEgg@mail.gmail.com>
References: <20120829143512.7c579fb1@mantra.us.oracle.com>
	<20120829144125.25a5eb3e@mantra.us.oracle.com>
	<CAOvdn6UPzBncAU7Wi3PNPaMX6DRXkg8Bb92fJN8i5VdYciuEgg@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
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: "Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
	msw@amazon.com
Subject: Re: [Xen-devel] xen debugger (kdb/xdb/hdb) patch for c/s 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 Wed, 5 Sep 2012 12:02:13 -0400
Ben Guthro <ben@guthro.net> wrote:

> FYI - I applied this against the tip, and turned it on (and debug off)
> - but I get link errors:
> 
> ld    -melf_x86_64  -T xen.lds -N prelink.o \
> 	    /data/home/bguthro/dev/orc-newdev.git/orc-xen/xen-4.2/xen/common/symbols-dummy.o
> -o /data/home/bguthro/dev/orc-newdev.git/orc-xen/xen-4.2/xen/.xen-syms.0
> prelink.o: In function `kdb_cmdf_f':
> /data/home/bguthro/dev/orc-newdev.git/orc-xen/xen-4.2/xen/kdb/kdb_cmds.c:510:
> undefined reference to `show_trace'
> /data/home/bguthro/dev/orc-newdev.git/orc-xen/xen-4.2/xen/kdb/kdb_cmds.c:510:(.text+0x11f6b9):
> relocation truncated to fit: R_X86_64_PC32 against undefined symbol
> `show_trace'
> ld: /data/home/bguthro/dev/orc-newdev.git/orc-xen/xen-4.2/xen/.xen-syms.0:
> hidden symbol `show_trace' isn't defined
> ld: final link failed: Bad value

It's prob static. Just un-static it :). Missed in patch because we
might have it that way here already in our tree.

LMK. 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 Sep 05 19:05:20 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Sep 2012 19:05:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9KuF-0002Zq-A6; Wed, 05 Sep 2012 19:04:55 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1T9KuD-0002Zl-Gb
	for xen-devel@lists.xen.org; Wed, 05 Sep 2012 19:04:53 +0000
Received: from [85.158.139.83:59907] by server-5.bemta-5.messagelabs.com id
	9D/1C-30514-452A7405; Wed, 05 Sep 2012 19:04:52 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1346871890!28242421!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDczODkxOA==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10090 invoked from network); 5 Sep 2012 19:04:51 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-13.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 5 Sep 2012 19:04:51 -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 q85J4iqk019975
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 5 Sep 2012 19:04:45 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q85J4hJA014044
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 5 Sep 2012 19:04:43 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
	q85J4gbJ017420; Wed, 5 Sep 2012 14:04:42 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 05 Sep 2012 12:04:42 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id D3910402C1; Wed,  5 Sep 2012 14:54:12 -0400 (EDT)
Date: Wed, 5 Sep 2012 14:54:12 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: "Ren, Yongjie" <yongjie.ren@intel.com>
Message-ID: <20120905185412.GA27077@phenom.dumpdata.com>
References: <1B4B44D9196EFF41AE41FDA404FC0A101881CE@SHSMSX101.ccr.corp.intel.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1B4B44D9196EFF41AE41FDA404FC0A101881CE@SHSMSX101.ccr.corp.intel.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: Konrad Rzeszutek Wilk <konrad@kernel.org>,
	Tobias Geiger <tobias.geiger@vido.info>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Regression in kernel 3.5 as Dom0 regarding 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

> > > > And its due to a patch I added in v3.4
> > > > (cd9db80e5257682a7f7ab245a2459648b3c8d268)
> > > > - which did not work properly in v3.4, but with v3.5 got it working
> > > > (977f857ca566a1e68045fcbb7cfc9c4acb077cf0) which causes v3.5 to
> > now
> > > > work
> > > > anymore.
> > > >
> > > > Anyhow, for right now jsut revert
> > > > cd9db80e5257682a7f7ab245a2459648b3c8d268
> > > > and it should work for you.
> > > >
> Confirmed, after reverting that commit, VT-d will work fine.
> Will you fix this and push it to upstream Linux, Konrad?
> 
> > > Also, our team reported a VT-d bug 2 months ago.
> > > http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1824
> >

Can either one of you please test this patch, please:


diff --git a/drivers/xen/xen-pciback/pci_stub.c b/drivers/xen/xen-pciback/pci_stub.c
index 097e536..425bd0b 100644
--- a/drivers/xen/xen-pciback/pci_stub.c
+++ b/drivers/xen/xen-pciback/pci_stub.c
@@ -4,6 +4,8 @@
  * Ryan Wilson <hap9@epoch.ncsc.mil>
  * Chris Bookholt <hap10@epoch.ncsc.mil>
  */
+#define DEBUG 1
+
 #include <linux/module.h>
 #include <linux/init.h>
 #include <linux/rwsem.h>
@@ -97,13 +99,15 @@ static void pcistub_device_release(struct kref *kref)
 	/* Call the reset function which does not take lock as this
 	 * is called from "unbind" which takes a device_lock mutex.
 	 */
+	dev_dbg(&psdev->dev->dev, "FLR locked..\n");
 	__pci_reset_function_locked(psdev->dev);
 	if (pci_load_and_free_saved_state(psdev->dev,
 					  &dev_data->pci_saved_state)) {
 		dev_dbg(&psdev->dev->dev, "Could not reload PCI state\n");
-	} else
+	} else {
+		dev_dbg(&psdev->dev->dev, "Reloading PCI state..\n");
 		pci_restore_state(psdev->dev);
-
+	}
 	/* Disable the device */
 	xen_pcibk_reset_device(psdev->dev);
 
@@ -353,16 +357,16 @@ static int __devinit pcistub_init_device(struct pci_dev *dev)
 	if (err)
 		goto config_release;
 
-	dev_dbg(&dev->dev, "reseting (FLR, D3, etc) the device\n");
-	__pci_reset_function_locked(dev);
-
 	/* We need the device active to save the state. */
 	dev_dbg(&dev->dev, "save state of device\n");
 	pci_save_state(dev);
 	dev_data->pci_saved_state = pci_store_saved_state(dev);
 	if (!dev_data->pci_saved_state)
 		dev_err(&dev->dev, "Could not store PCI conf saved state!\n");
-
+	else {
+		dev_dbg(&dev->dev, "reseting (FLR, D3, etc) the device\n");
+		__pci_reset_function_locked(dev);
+	}
 	/* Now disable the device (this also ensures some private device
 	 * data is setup before we export)
 	 */

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

From xen-devel-bounces@lists.xen.org Wed Sep 05 19:05:20 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Sep 2012 19:05:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9KuF-0002Zq-A6; Wed, 05 Sep 2012 19:04:55 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1T9KuD-0002Zl-Gb
	for xen-devel@lists.xen.org; Wed, 05 Sep 2012 19:04:53 +0000
Received: from [85.158.139.83:59907] by server-5.bemta-5.messagelabs.com id
	9D/1C-30514-452A7405; Wed, 05 Sep 2012 19:04:52 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1346871890!28242421!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDczODkxOA==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10090 invoked from network); 5 Sep 2012 19:04:51 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-13.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 5 Sep 2012 19:04:51 -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 q85J4iqk019975
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 5 Sep 2012 19:04:45 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q85J4hJA014044
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 5 Sep 2012 19:04:43 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
	q85J4gbJ017420; Wed, 5 Sep 2012 14:04:42 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 05 Sep 2012 12:04:42 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id D3910402C1; Wed,  5 Sep 2012 14:54:12 -0400 (EDT)
Date: Wed, 5 Sep 2012 14:54:12 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: "Ren, Yongjie" <yongjie.ren@intel.com>
Message-ID: <20120905185412.GA27077@phenom.dumpdata.com>
References: <1B4B44D9196EFF41AE41FDA404FC0A101881CE@SHSMSX101.ccr.corp.intel.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1B4B44D9196EFF41AE41FDA404FC0A101881CE@SHSMSX101.ccr.corp.intel.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: Konrad Rzeszutek Wilk <konrad@kernel.org>,
	Tobias Geiger <tobias.geiger@vido.info>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Regression in kernel 3.5 as Dom0 regarding 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

> > > > And its due to a patch I added in v3.4
> > > > (cd9db80e5257682a7f7ab245a2459648b3c8d268)
> > > > - which did not work properly in v3.4, but with v3.5 got it working
> > > > (977f857ca566a1e68045fcbb7cfc9c4acb077cf0) which causes v3.5 to
> > now
> > > > work
> > > > anymore.
> > > >
> > > > Anyhow, for right now jsut revert
> > > > cd9db80e5257682a7f7ab245a2459648b3c8d268
> > > > and it should work for you.
> > > >
> Confirmed, after reverting that commit, VT-d will work fine.
> Will you fix this and push it to upstream Linux, Konrad?
> 
> > > Also, our team reported a VT-d bug 2 months ago.
> > > http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1824
> >

Can either one of you please test this patch, please:


diff --git a/drivers/xen/xen-pciback/pci_stub.c b/drivers/xen/xen-pciback/pci_stub.c
index 097e536..425bd0b 100644
--- a/drivers/xen/xen-pciback/pci_stub.c
+++ b/drivers/xen/xen-pciback/pci_stub.c
@@ -4,6 +4,8 @@
  * Ryan Wilson <hap9@epoch.ncsc.mil>
  * Chris Bookholt <hap10@epoch.ncsc.mil>
  */
+#define DEBUG 1
+
 #include <linux/module.h>
 #include <linux/init.h>
 #include <linux/rwsem.h>
@@ -97,13 +99,15 @@ static void pcistub_device_release(struct kref *kref)
 	/* Call the reset function which does not take lock as this
 	 * is called from "unbind" which takes a device_lock mutex.
 	 */
+	dev_dbg(&psdev->dev->dev, "FLR locked..\n");
 	__pci_reset_function_locked(psdev->dev);
 	if (pci_load_and_free_saved_state(psdev->dev,
 					  &dev_data->pci_saved_state)) {
 		dev_dbg(&psdev->dev->dev, "Could not reload PCI state\n");
-	} else
+	} else {
+		dev_dbg(&psdev->dev->dev, "Reloading PCI state..\n");
 		pci_restore_state(psdev->dev);
-
+	}
 	/* Disable the device */
 	xen_pcibk_reset_device(psdev->dev);
 
@@ -353,16 +357,16 @@ static int __devinit pcistub_init_device(struct pci_dev *dev)
 	if (err)
 		goto config_release;
 
-	dev_dbg(&dev->dev, "reseting (FLR, D3, etc) the device\n");
-	__pci_reset_function_locked(dev);
-
 	/* We need the device active to save the state. */
 	dev_dbg(&dev->dev, "save state of device\n");
 	pci_save_state(dev);
 	dev_data->pci_saved_state = pci_store_saved_state(dev);
 	if (!dev_data->pci_saved_state)
 		dev_err(&dev->dev, "Could not store PCI conf saved state!\n");
-
+	else {
+		dev_dbg(&dev->dev, "reseting (FLR, D3, etc) the device\n");
+		__pci_reset_function_locked(dev);
+	}
 	/* Now disable the device (this also ensures some private device
 	 * data is setup before we export)
 	 */

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

From xen-devel-bounces@lists.xen.org Wed Sep 05 19:08:34 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Sep 2012 19:08:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9KxR-0002fz-Tv; Wed, 05 Sep 2012 19:08:13 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1T9KxQ-0002fr-1c
	for xen-devel@lists.xensource.com; Wed, 05 Sep 2012 19:08:12 +0000
Received: from [85.158.143.99:8310] by server-2.bemta-4.messagelabs.com id
	F9/0C-21239-A13A7405; Wed, 05 Sep 2012 19:08:10 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1346872088!21213235!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzI4NDYw\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11590 invoked from network); 5 Sep 2012 19:08:09 -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 Sep 2012 19:08:09 -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 q85J7xhq003193
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 5 Sep 2012 19:08:00 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
	q85J7wcw017797
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 5 Sep 2012 19:07:59 GMT
Received: from abhmt120.oracle.com (abhmt120.oracle.com [141.146.116.72])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q85J7wud023962; Wed, 5 Sep 2012 14:07:58 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 05 Sep 2012 12:07:58 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 6356F402C1; Wed,  5 Sep 2012 14:57:28 -0400 (EDT)
Date: Wed, 5 Sep 2012 14:57:28 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Andres Lagar-Cavilla <andreslc@gridcentric.ca>
Message-ID: <20120905185728.GA14981@phenom.dumpdata.com>
References: <1346331492-15027-1-git-send-email-david.vrabel@citrix.com>
	<20120830200509.GA12955@localhost.localdomain>
	<EE725C18-21B4-4F03-834E-F516178E0EAA@gridcentric.ca>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <EE725C18-21B4-4F03-834E-F516178E0EAA@gridcentric.ca>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: Konrad Rzeszutek Wilk <konrad@kernel.org>, xen-devel@lists.xensource.com,
	David Vrabel <david.vrabel@citrix.com>
Subject: Re: [Xen-devel] [PATCHv3 0/2] xen/privcmd: support for paged-out
 frames
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Aug 30, 2012 at 04:12:03PM -0400, Andres Lagar-Cavilla wrote:
> On Aug 30, 2012, at 4:05 PM, Konrad Rzeszutek Wilk wrote:
> 
> >> I think this should probably get a "Tested-by" Andres or someone else
> >> who uses paging before being applied.
> > 
> > How do I test it? Is there an easy explanation/tutorial Andres?
> 
> I have a unit test lying somewhere but I'll need a day to dig it out.

If you can send that that would be super..
> 
> Or you can start an hvm, pause it, fire up xenpaging with debug output so it tells you what it paged out, and then trace libxc as you xc_map_foreign_bulk a known batch of evicted pfns. On the first try it should get rc == -1, errno == ENOENT, error field for the pfn == ENOENT. On the second try it should all be dandy.
> 

This works well with Xen 4.1 or should I use Xen 4.2?
> Thanks
> Andres

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

From xen-devel-bounces@lists.xen.org Wed Sep 05 19:08:34 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Sep 2012 19:08:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9KxR-0002fz-Tv; Wed, 05 Sep 2012 19:08:13 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1T9KxQ-0002fr-1c
	for xen-devel@lists.xensource.com; Wed, 05 Sep 2012 19:08:12 +0000
Received: from [85.158.143.99:8310] by server-2.bemta-4.messagelabs.com id
	F9/0C-21239-A13A7405; Wed, 05 Sep 2012 19:08:10 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1346872088!21213235!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzI4NDYw\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11590 invoked from network); 5 Sep 2012 19:08:09 -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 Sep 2012 19:08:09 -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 q85J7xhq003193
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 5 Sep 2012 19:08:00 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
	q85J7wcw017797
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 5 Sep 2012 19:07:59 GMT
Received: from abhmt120.oracle.com (abhmt120.oracle.com [141.146.116.72])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q85J7wud023962; Wed, 5 Sep 2012 14:07:58 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 05 Sep 2012 12:07:58 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 6356F402C1; Wed,  5 Sep 2012 14:57:28 -0400 (EDT)
Date: Wed, 5 Sep 2012 14:57:28 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Andres Lagar-Cavilla <andreslc@gridcentric.ca>
Message-ID: <20120905185728.GA14981@phenom.dumpdata.com>
References: <1346331492-15027-1-git-send-email-david.vrabel@citrix.com>
	<20120830200509.GA12955@localhost.localdomain>
	<EE725C18-21B4-4F03-834E-F516178E0EAA@gridcentric.ca>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <EE725C18-21B4-4F03-834E-F516178E0EAA@gridcentric.ca>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: Konrad Rzeszutek Wilk <konrad@kernel.org>, xen-devel@lists.xensource.com,
	David Vrabel <david.vrabel@citrix.com>
Subject: Re: [Xen-devel] [PATCHv3 0/2] xen/privcmd: support for paged-out
 frames
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Aug 30, 2012 at 04:12:03PM -0400, Andres Lagar-Cavilla wrote:
> On Aug 30, 2012, at 4:05 PM, Konrad Rzeszutek Wilk wrote:
> 
> >> I think this should probably get a "Tested-by" Andres or someone else
> >> who uses paging before being applied.
> > 
> > How do I test it? Is there an easy explanation/tutorial Andres?
> 
> I have a unit test lying somewhere but I'll need a day to dig it out.

If you can send that that would be super..
> 
> Or you can start an hvm, pause it, fire up xenpaging with debug output so it tells you what it paged out, and then trace libxc as you xc_map_foreign_bulk a known batch of evicted pfns. On the first try it should get rc == -1, errno == ENOENT, error field for the pfn == ENOENT. On the second try it should all be dandy.
> 

This works well with Xen 4.1 or should I use Xen 4.2?
> Thanks
> Andres

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

From xen-devel-bounces@lists.xen.org Wed Sep 05 19:51:34 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Sep 2012 19:51:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9Ld0-0003C3-21; Wed, 05 Sep 2012 19:51:10 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andreslc@gridcentric.ca>) id 1T9Lcx-0003By-V7
	for xen-devel@lists.xensource.com; Wed, 05 Sep 2012 19:51:08 +0000
Received: from [85.158.138.51:38741] by server-9.bemta-3.messagelabs.com id
	C4/F6-15390-B2DA7405; Wed, 05 Sep 2012 19:51:07 +0000
X-Env-Sender: andreslc@gridcentric.ca
X-Msg-Ref: server-12.tower-174.messagelabs.com!1346874664!20937763!1
X-Originating-IP: [209.85.223.171]
X-SpamReason: No, hits=0.4 required=7.0 tests=MIME_QP_LONG_LINE,
  RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29566 invoked from network); 5 Sep 2012 19:51:06 -0000
Received: from mail-ie0-f171.google.com (HELO mail-ie0-f171.google.com)
	(209.85.223.171)
	by server-12.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Sep 2012 19:51:06 -0000
Received: by ieje14 with SMTP id e14so2236696iej.30
	for <xen-devel@lists.xensource.com>;
	Wed, 05 Sep 2012 12:51:04 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=subject:mime-version:content-type:from:in-reply-to:date:cc
	:content-transfer-encoding:message-id:references:to:x-mailer
	:x-gm-message-state;
	bh=MwNmlNGeuuv5AgEmdr/1mzOAhU9ojjiOGQjzDYAHP04=;
	b=bcwmpz7QbfUeiDAIubt6YvBl1cAosZciOYV+/ZaP/luKx2VzQOzWuHqGvI9NIRgVZF
	VwHF2FEYjAFRFWWBygF3X3fkCOV9BAYTZoisJMVt58QASfwDu7bM3xgfyGhJvTWhOEg7
	tIXOptY1Rh/MbPWmffidvfHQc/3i/B71//5r9O25xblaQuxRWAM/V0nyMRhzgijwU865
	LLghxY60pZcnbKgdYTbc8NrpwLp27k5vqFAvQVxdH2vEb9j25pJbY9AX79NdnyKRZ86h
	lw3KvedzoJrJKE0YtFehyQvgsfrCaMbw+SGtqditpEdpQtVKDGFdKIhEF82hiHKfLUl2
	dODQ==
Received: by 10.50.195.233 with SMTP id ih9mr14849753igc.65.1346874664677;
	Wed, 05 Sep 2012 12:51:04 -0700 (PDT)
Received: from [192.168.7.210] ([206.223.182.18])
	by mx.google.com with ESMTPS id ng5sm184988igc.0.2012.09.05.12.51.02
	(version=TLSv1/SSLv3 cipher=OTHER);
	Wed, 05 Sep 2012 12:51:03 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1278)
From: Andres Lagar-Cavilla <andreslc@gridcentric.ca>
In-Reply-To: <20120905185728.GA14981@phenom.dumpdata.com>
Date: Wed, 5 Sep 2012 15:51:03 -0400
Message-Id: <8E34FA8A-2169-45E5-82D2-19EA35162F66@gridcentric.ca>
References: <1346331492-15027-1-git-send-email-david.vrabel@citrix.com>
	<20120830200509.GA12955@localhost.localdomain>
	<EE725C18-21B4-4F03-834E-F516178E0EAA@gridcentric.ca>
	<20120905185728.GA14981@phenom.dumpdata.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
X-Mailer: Apple Mail (2.1278)
X-Gm-Message-State: ALoCoQnlt9iyw+2oqUExdSSPUSxT+eOlGNdqdzyAcpZ0zlt3kHBXLsZQTWap1L8YB5NqJ7xYAluU
Cc: Andres Lagar-Cavilla <andreslc@gridcentric.ca>,
	xen-devel@lists.xensource.com, David Vrabel <david.vrabel@citrix.com>,
	Konrad Rzeszutek Wilk <konrad@kernel.org>
Subject: Re: [Xen-devel] [PATCHv3 0/2] xen/privcmd: support for paged-out
	frames
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


On Sep 5, 2012, at 2:57 PM, Konrad Rzeszutek Wilk wrote:

> On Thu, Aug 30, 2012 at 04:12:03PM -0400, Andres Lagar-Cavilla wrote:
>> On Aug 30, 2012, at 4:05 PM, Konrad Rzeszutek Wilk wrote:
>> 
>>>> I think this should probably get a "Tested-by" Andres or someone else
>>>> who uses paging before being applied.
>>> 
>>> How do I test it? Is there an easy explanation/tutorial Andres?
>> 
>> I have a unit test lying somewhere but I'll need a day to dig it out.
> 
> If you can send that that would be super..
Yeah. Sorry, forgot. Will take me a bit though.
>> 
>> Or you can start an hvm, pause it, fire up xenpaging with debug output so it tells you what it paged out, and then trace libxc as you xc_map_foreign_bulk a known batch of evicted pfns. On the first try it should get rc == -1, errno == ENOENT, error field for the pfn == ENOENT. On the second try it should all be dandy.
>> 
> 
> This works well with Xen 4.1 or should I use Xen 4.2?

Xen-4.1 is advertised to work with this but I've never tried. Xen-4.2 is what I use all the time

Andres

>> Thanks
>> Andres


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

From xen-devel-bounces@lists.xen.org Wed Sep 05 19:51:34 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Sep 2012 19:51:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9Ld0-0003C3-21; Wed, 05 Sep 2012 19:51:10 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andreslc@gridcentric.ca>) id 1T9Lcx-0003By-V7
	for xen-devel@lists.xensource.com; Wed, 05 Sep 2012 19:51:08 +0000
Received: from [85.158.138.51:38741] by server-9.bemta-3.messagelabs.com id
	C4/F6-15390-B2DA7405; Wed, 05 Sep 2012 19:51:07 +0000
X-Env-Sender: andreslc@gridcentric.ca
X-Msg-Ref: server-12.tower-174.messagelabs.com!1346874664!20937763!1
X-Originating-IP: [209.85.223.171]
X-SpamReason: No, hits=0.4 required=7.0 tests=MIME_QP_LONG_LINE,
  RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29566 invoked from network); 5 Sep 2012 19:51:06 -0000
Received: from mail-ie0-f171.google.com (HELO mail-ie0-f171.google.com)
	(209.85.223.171)
	by server-12.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Sep 2012 19:51:06 -0000
Received: by ieje14 with SMTP id e14so2236696iej.30
	for <xen-devel@lists.xensource.com>;
	Wed, 05 Sep 2012 12:51:04 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=subject:mime-version:content-type:from:in-reply-to:date:cc
	:content-transfer-encoding:message-id:references:to:x-mailer
	:x-gm-message-state;
	bh=MwNmlNGeuuv5AgEmdr/1mzOAhU9ojjiOGQjzDYAHP04=;
	b=bcwmpz7QbfUeiDAIubt6YvBl1cAosZciOYV+/ZaP/luKx2VzQOzWuHqGvI9NIRgVZF
	VwHF2FEYjAFRFWWBygF3X3fkCOV9BAYTZoisJMVt58QASfwDu7bM3xgfyGhJvTWhOEg7
	tIXOptY1Rh/MbPWmffidvfHQc/3i/B71//5r9O25xblaQuxRWAM/V0nyMRhzgijwU865
	LLghxY60pZcnbKgdYTbc8NrpwLp27k5vqFAvQVxdH2vEb9j25pJbY9AX79NdnyKRZ86h
	lw3KvedzoJrJKE0YtFehyQvgsfrCaMbw+SGtqditpEdpQtVKDGFdKIhEF82hiHKfLUl2
	dODQ==
Received: by 10.50.195.233 with SMTP id ih9mr14849753igc.65.1346874664677;
	Wed, 05 Sep 2012 12:51:04 -0700 (PDT)
Received: from [192.168.7.210] ([206.223.182.18])
	by mx.google.com with ESMTPS id ng5sm184988igc.0.2012.09.05.12.51.02
	(version=TLSv1/SSLv3 cipher=OTHER);
	Wed, 05 Sep 2012 12:51:03 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1278)
From: Andres Lagar-Cavilla <andreslc@gridcentric.ca>
In-Reply-To: <20120905185728.GA14981@phenom.dumpdata.com>
Date: Wed, 5 Sep 2012 15:51:03 -0400
Message-Id: <8E34FA8A-2169-45E5-82D2-19EA35162F66@gridcentric.ca>
References: <1346331492-15027-1-git-send-email-david.vrabel@citrix.com>
	<20120830200509.GA12955@localhost.localdomain>
	<EE725C18-21B4-4F03-834E-F516178E0EAA@gridcentric.ca>
	<20120905185728.GA14981@phenom.dumpdata.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
X-Mailer: Apple Mail (2.1278)
X-Gm-Message-State: ALoCoQnlt9iyw+2oqUExdSSPUSxT+eOlGNdqdzyAcpZ0zlt3kHBXLsZQTWap1L8YB5NqJ7xYAluU
Cc: Andres Lagar-Cavilla <andreslc@gridcentric.ca>,
	xen-devel@lists.xensource.com, David Vrabel <david.vrabel@citrix.com>,
	Konrad Rzeszutek Wilk <konrad@kernel.org>
Subject: Re: [Xen-devel] [PATCHv3 0/2] xen/privcmd: support for paged-out
	frames
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


On Sep 5, 2012, at 2:57 PM, Konrad Rzeszutek Wilk wrote:

> On Thu, Aug 30, 2012 at 04:12:03PM -0400, Andres Lagar-Cavilla wrote:
>> On Aug 30, 2012, at 4:05 PM, Konrad Rzeszutek Wilk wrote:
>> 
>>>> I think this should probably get a "Tested-by" Andres or someone else
>>>> who uses paging before being applied.
>>> 
>>> How do I test it? Is there an easy explanation/tutorial Andres?
>> 
>> I have a unit test lying somewhere but I'll need a day to dig it out.
> 
> If you can send that that would be super..
Yeah. Sorry, forgot. Will take me a bit though.
>> 
>> Or you can start an hvm, pause it, fire up xenpaging with debug output so it tells you what it paged out, and then trace libxc as you xc_map_foreign_bulk a known batch of evicted pfns. On the first try it should get rc == -1, errno == ENOENT, error field for the pfn == ENOENT. On the second try it should all be dandy.
>> 
> 
> This works well with Xen 4.1 or should I use Xen 4.2?

Xen-4.1 is advertised to work with this but I've never tried. Xen-4.2 is what I use all the time

Andres

>> Thanks
>> Andres


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

From xen-devel-bounces@lists.xen.org Wed Sep 05 19:54:30 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Sep 2012 19:54:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9Lfs-0003O6-2B; Wed, 05 Sep 2012 19:54:08 +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 1T9Lfr-0003Ny-1o
	for xen-devel@lists.xen.org; Wed, 05 Sep 2012 19:54:07 +0000
Received: from [85.158.143.99:47901] by server-1.bemta-4.messagelabs.com id
	20/D6-12504-EDDA7405; Wed, 05 Sep 2012 19:54:06 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-14.tower-216.messagelabs.com!1346874845!19129035!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA1MDI2OTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5685 invoked from network); 5 Sep 2012 19:54:05 -0000
Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25)
	by server-14.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 5 Sep 2012 19:54:05 -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 BFB7C2564;
	Wed,  5 Sep 2012 22:54:04 +0300 (EEST)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id AA2652005D; Wed,  5 Sep 2012 22:54:03 +0300 (EEST)
Date: Wed, 5 Sep 2012 22:54:03 +0300
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120905195403.GO8912@reaktio.net>
References: <20120902053549.GF8912@reaktio.net>
	<1346667053.25864.21.camel@zakaz.uk.xensource.com>
	<20120904191229.GH8912@reaktio.net>
	<1346834000.17325.4.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1346834000.17325.4.camel@zakaz.uk.xensource.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] [PATCH] xl.cfg: gfx_passthru documentation
 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 Wed, Sep 05, 2012 at 09:33:20AM +0100, Ian Campbell wrote:
> On Tue, 2012-09-04 at 20:12 +0100, Pasi K=E4rkk=E4inen wrote:
> > On Mon, Sep 03, 2012 at 11:10:53AM +0100, Ian Campbell wrote:
> > > On Sun, 2012-09-02 at 06:35 +0100, Pasi K=E4rkk=E4inen wrote:
> > > > Hello,
> > > > =

> > > > xl.cfg.pod.5 documentation improvements:
> > > > =

> > > > - gfx_passthru: Document gfx_passthru makes the GPU become primary =
in the guest
> > > >   and other generic info about gfx_passthru.
> > > > =

> > > > =

> > > > Signed-off-by: Pasi K=E4rkk=E4inen <pasik@iki.fi>
> > > > --- docs/man/xl.cfg.pod.5.orig1 2012-09-02 07:16:39.316782158 +0300
> > > > +++ docs/man/xl.cfg.pod.5       2012-09-02 08:26:40.081639087 +0300
> > > > @@ -968,7 +968,43 @@
> > > >  =

> > > >  =3Ditem B<gfx_passthru=3DBOOLEAN>
> > > >  =

> > > > -Enable graphics device PCI passthrough. XXX which device is passed=
 through ?
> > > > +Enable graphics device PCI passthrough. This option makes the pass=
thru
> > > > +graphics card become primary graphics card in the VM,
> > > =

> > > The option is slightly misnamed then I guess, a better name would have
> > > been gfx_passthru_primary? oh well, we are stuck with it now.
> > > =

> > =

> > Yeah.. I think earlier gfx_passthru wasn't a boolean, but an integer, t=
o choose the mode.
> =

> Oh, do you happen to know what the meanings were?
> =


iirc off/primary/secondary.. =



> > > >  so the Qemu emulated =

> > > > +graphics adapter is disabled, and the VNC console for the VM won't=
 have
> > > > +any graphics output. All graphics output, including boot time Qemu=
 BIOS
> > > > +messages from the VM, will go to the physical outputs of the passe=
d thru
> > > > +physical graphics card.
> > > > +
> > > > +Graphics card PCI device to passthru is chosen with B<pci> option, =

> > > > +exactly in the same way as normal Xen PCI device passthru/assignme=
nt is done. =

> > > > +Note that gfx_passthru doesn't do any kind of sharing
> > > > +of the GPU, so you can only assign the GPU to one single VM at a t=
ime.
> > > > +
> > > > +gfx_passthru also enables various legacy VGA memory ranges, BARs, =
MMIOs, =

> > > > +and ioports to be passed thru to the VM, since those are required
> > > > +for correct operation of things like VGA BIOS, text mode, VBE, etc.
> > > > +
> > > > +Enabling gfx_passthru option also copies the physical graphics car=
d =

> > > > +video bios to the guest memory, and executes the vbios in the gues=
t =

> > > =

> > > "BIOS" and (I expect) "VBIOS"?
> > > =

> > =

> > video bios =3D=3D vbios, or did you ask something else? =

> =

> I was just commenting on the capitalisation differing from other
> mentions of the BIOS.
> =


Ok.

> > > > +to get the graphics card initialized.
> > > > +
> > > > +Most graphics adapters require vendor specific tweaks for properly
> > > > +working graphics passthru. Xen currently includes necessary tweaks
> > > > +for Intel IGD (Integrated Graphics Device) GPUs.  =

> > > > +
> > > > +Support for AMD/Nvidia gfx_passthru is not yet merged to Xen,
> > > > +but there are out-of-tree patches available.
> > > =

> > > If there is a comprehensive list of supported/not-supported devices on
> > > the wiki then I think a reference here would be more useful than these
> > > two brief paragraphs.
> > > =

> > =

> > We have a list, but it's not up-to-date unfortunately:
> > http://wiki.xen.org/wiki/XenVGAPassthroughTestedAdapters
> =

> I think it is worth referencing it, and perhaps adding a note to the
> page itself regarding its freshness (and then working to improve it, of
> course ;-))
> =


Yep.

> > > In particular the second isn't very useful without links and those te=
nd
> > > to become out of date in docs IME, I would tend to omit this from here
> > > and instead include them in the wiki where they can be kept up to date
> > >
> > =

> > Ok. I'll fix that, and add a link to:
> > http://wiki.xen.org/wiki/XenVGAPassthrough
> =

> Thanks.
> =


I'll send a new patch soon.

-- Pasi


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

From xen-devel-bounces@lists.xen.org Wed Sep 05 19:54:30 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Sep 2012 19:54:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9Lfs-0003O6-2B; Wed, 05 Sep 2012 19:54:08 +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 1T9Lfr-0003Ny-1o
	for xen-devel@lists.xen.org; Wed, 05 Sep 2012 19:54:07 +0000
Received: from [85.158.143.99:47901] by server-1.bemta-4.messagelabs.com id
	20/D6-12504-EDDA7405; Wed, 05 Sep 2012 19:54:06 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-14.tower-216.messagelabs.com!1346874845!19129035!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA1MDI2OTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5685 invoked from network); 5 Sep 2012 19:54:05 -0000
Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25)
	by server-14.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 5 Sep 2012 19:54:05 -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 BFB7C2564;
	Wed,  5 Sep 2012 22:54:04 +0300 (EEST)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id AA2652005D; Wed,  5 Sep 2012 22:54:03 +0300 (EEST)
Date: Wed, 5 Sep 2012 22:54:03 +0300
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120905195403.GO8912@reaktio.net>
References: <20120902053549.GF8912@reaktio.net>
	<1346667053.25864.21.camel@zakaz.uk.xensource.com>
	<20120904191229.GH8912@reaktio.net>
	<1346834000.17325.4.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1346834000.17325.4.camel@zakaz.uk.xensource.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] [PATCH] xl.cfg: gfx_passthru documentation
 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 Wed, Sep 05, 2012 at 09:33:20AM +0100, Ian Campbell wrote:
> On Tue, 2012-09-04 at 20:12 +0100, Pasi K=E4rkk=E4inen wrote:
> > On Mon, Sep 03, 2012 at 11:10:53AM +0100, Ian Campbell wrote:
> > > On Sun, 2012-09-02 at 06:35 +0100, Pasi K=E4rkk=E4inen wrote:
> > > > Hello,
> > > > =

> > > > xl.cfg.pod.5 documentation improvements:
> > > > =

> > > > - gfx_passthru: Document gfx_passthru makes the GPU become primary =
in the guest
> > > >   and other generic info about gfx_passthru.
> > > > =

> > > > =

> > > > Signed-off-by: Pasi K=E4rkk=E4inen <pasik@iki.fi>
> > > > --- docs/man/xl.cfg.pod.5.orig1 2012-09-02 07:16:39.316782158 +0300
> > > > +++ docs/man/xl.cfg.pod.5       2012-09-02 08:26:40.081639087 +0300
> > > > @@ -968,7 +968,43 @@
> > > >  =

> > > >  =3Ditem B<gfx_passthru=3DBOOLEAN>
> > > >  =

> > > > -Enable graphics device PCI passthrough. XXX which device is passed=
 through ?
> > > > +Enable graphics device PCI passthrough. This option makes the pass=
thru
> > > > +graphics card become primary graphics card in the VM,
> > > =

> > > The option is slightly misnamed then I guess, a better name would have
> > > been gfx_passthru_primary? oh well, we are stuck with it now.
> > > =

> > =

> > Yeah.. I think earlier gfx_passthru wasn't a boolean, but an integer, t=
o choose the mode.
> =

> Oh, do you happen to know what the meanings were?
> =


iirc off/primary/secondary.. =



> > > >  so the Qemu emulated =

> > > > +graphics adapter is disabled, and the VNC console for the VM won't=
 have
> > > > +any graphics output. All graphics output, including boot time Qemu=
 BIOS
> > > > +messages from the VM, will go to the physical outputs of the passe=
d thru
> > > > +physical graphics card.
> > > > +
> > > > +Graphics card PCI device to passthru is chosen with B<pci> option, =

> > > > +exactly in the same way as normal Xen PCI device passthru/assignme=
nt is done. =

> > > > +Note that gfx_passthru doesn't do any kind of sharing
> > > > +of the GPU, so you can only assign the GPU to one single VM at a t=
ime.
> > > > +
> > > > +gfx_passthru also enables various legacy VGA memory ranges, BARs, =
MMIOs, =

> > > > +and ioports to be passed thru to the VM, since those are required
> > > > +for correct operation of things like VGA BIOS, text mode, VBE, etc.
> > > > +
> > > > +Enabling gfx_passthru option also copies the physical graphics car=
d =

> > > > +video bios to the guest memory, and executes the vbios in the gues=
t =

> > > =

> > > "BIOS" and (I expect) "VBIOS"?
> > > =

> > =

> > video bios =3D=3D vbios, or did you ask something else? =

> =

> I was just commenting on the capitalisation differing from other
> mentions of the BIOS.
> =


Ok.

> > > > +to get the graphics card initialized.
> > > > +
> > > > +Most graphics adapters require vendor specific tweaks for properly
> > > > +working graphics passthru. Xen currently includes necessary tweaks
> > > > +for Intel IGD (Integrated Graphics Device) GPUs.  =

> > > > +
> > > > +Support for AMD/Nvidia gfx_passthru is not yet merged to Xen,
> > > > +but there are out-of-tree patches available.
> > > =

> > > If there is a comprehensive list of supported/not-supported devices on
> > > the wiki then I think a reference here would be more useful than these
> > > two brief paragraphs.
> > > =

> > =

> > We have a list, but it's not up-to-date unfortunately:
> > http://wiki.xen.org/wiki/XenVGAPassthroughTestedAdapters
> =

> I think it is worth referencing it, and perhaps adding a note to the
> page itself regarding its freshness (and then working to improve it, of
> course ;-))
> =


Yep.

> > > In particular the second isn't very useful without links and those te=
nd
> > > to become out of date in docs IME, I would tend to omit this from here
> > > and instead include them in the wiki where they can be kept up to date
> > >
> > =

> > Ok. I'll fix that, and add a link to:
> > http://wiki.xen.org/wiki/XenVGAPassthrough
> =

> Thanks.
> =


I'll send a new patch soon.

-- Pasi


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

From xen-devel-bounces@lists.xen.org Wed Sep 05 20:09:28 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Sep 2012 20:09:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9LuJ-0003mn-Hv; Wed, 05 Sep 2012 20:09:03 +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 1T9LuH-0003mi-MP
	for xen-devel@lists.xen.org; Wed, 05 Sep 2012 20:09:02 +0000
Received: from [85.158.143.99:15285] by server-2.bemta-4.messagelabs.com id
	0E/21-21239-C51B7405; Wed, 05 Sep 2012 20:09:00 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-6.tower-216.messagelabs.com!1346875739!21726627!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA1MDI2OTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7342 invoked from network); 5 Sep 2012 20:09:00 -0000
Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25)
	by server-6.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 5 Sep 2012 20:09:00 -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 19D331ACA;
	Wed,  5 Sep 2012 23:08:58 +0300 (EEST)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id 8493D2005D; Wed,  5 Sep 2012 23:08:58 +0300 (EEST)
Date: Wed, 5 Sep 2012 23:08:58 +0300
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120905200858.GP8912@reaktio.net>
References: <20120902053549.GF8912@reaktio.net>
	<1346667053.25864.21.camel@zakaz.uk.xensource.com>
	<20120904191229.GH8912@reaktio.net>
	<1346834000.17325.4.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="/e2eDi0V/xtL+Mc8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <1346834000.17325.4.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: [Xen-devel] [PATCH v2] xl.cfg: gfx_passthru documentation
	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>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--/e2eDi0V/xtL+Mc8
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit

Hello,

v2: address review comments.

xl.cfg.pod.5 documentation improvements:

- gfx_passthru: Document gfx_passthru makes the GPU become primary in the guest
  and other generic info about gfx_passthru.

Signed-off-by: Pasi Kärkkäinen <pasik@iki.fi>


--- xen-unstable.hg/docs/man/xl.cfg.pod.5.orig  2012-09-05 22:51:39.745137076 +0300
+++ xen-unstable.hg/docs/man/xl.cfg.pod.5       2012-09-05 23:02:29.746203364 +0300
@@ -992,7 +992,44 @@

 =item B<gfx_passthru=BOOLEAN>

-Enable graphics device PCI passthrough. XXX which device is passed through ?
+Enable graphics device PCI passthrough. This option makes the passthru
+graphics card become primary graphics card in the VM, so the Qemu emulated
+graphics adapter is disabled, and the VNC console for the VM won't have
+any graphics output. All graphics output, including boot time Qemu BIOS
+messages from the VM, will go to the physical outputs of the passed thru
+physical graphics card.
+
+Graphics card PCI device to passthru is chosen with B<pci> option,
+exactly in the same way as normal Xen PCI device passthru/assignment is done.
+Note that gfx_passthru doesn't do any kind of sharing
+of the GPU, so you can only assign the GPU to one single VM at a time.
+
+gfx_passthru also enables various legacy VGA memory ranges, BARs, MMIOs,
+and ioports to be passed thru to the VM, since those are required
+for correct operation of things like VGA BIOS, text mode, VBE, etc.
+
+Enabling gfx_passthru option also copies the physical graphics card
+video BIOS to the guest memory, and executes the VBIOS in the guest
+to get the graphics card initialized.
+
+Most graphics adapters require vendor specific tweaks for properly
+working graphics passthru. See the XenVGAPassthroughTestedAdapters
+L<http://wiki.xen.org/wiki/XenVGAPassthroughTestedAdapters>
+wiki page for currently supported graphics cards for gfx_passthru.
+
+gfx_passthru is currently only supported with the qemu-xen-traditional
+device-model. Upstream qemu-xen device-model currently doesn't have
+support for gfx_passthru.
+
+Note that some graphics adapters (AMD/ATI cards, for example) don't
+necessarily require gfx_passthru option, so you can use the normal
+Xen PCI passthru to assign the graphics card as a secondary graphics card
+to the VM. Qemu emulated graphics card stays as the primary graphics card,
+and you get VNC output from the Qemu-emulated primary adapter.
+
+More information about Xen gfx_passthru feature is available
+on the XenVGAPassthrough L<http://wiki.xen.org/wiki/XenVGAPassthrough>
+wiki page.

 =item B<nomigrate=BOOLEAN>


--/e2eDi0V/xtL+Mc8
Content-Type: text/x-diff; charset=us-ascii
Content-Disposition: attachment; filename="xl.cfg.pod.5-gfx_passthru-2.patch"

--- xen-unstable.hg/docs/man/xl.cfg.pod.5.orig	2012-09-05 22:51:39.745137076 +0300
+++ xen-unstable.hg/docs/man/xl.cfg.pod.5	2012-09-05 23:02:29.746203364 +0300
@@ -992,7 +992,44 @@
 
 =item B<gfx_passthru=BOOLEAN>
 
-Enable graphics device PCI passthrough. XXX which device is passed through ?
+Enable graphics device PCI passthrough. This option makes the passthru
+graphics card become primary graphics card in the VM, so the Qemu emulated 
+graphics adapter is disabled, and the VNC console for the VM won't have
+any graphics output. All graphics output, including boot time Qemu BIOS
+messages from the VM, will go to the physical outputs of the passed thru
+physical graphics card.
+
+Graphics card PCI device to passthru is chosen with B<pci> option, 
+exactly in the same way as normal Xen PCI device passthru/assignment is done. 
+Note that gfx_passthru doesn't do any kind of sharing
+of the GPU, so you can only assign the GPU to one single VM at a time.
+
+gfx_passthru also enables various legacy VGA memory ranges, BARs, MMIOs, 
+and ioports to be passed thru to the VM, since those are required
+for correct operation of things like VGA BIOS, text mode, VBE, etc.
+
+Enabling gfx_passthru option also copies the physical graphics card 
+video BIOS to the guest memory, and executes the VBIOS in the guest 
+to get the graphics card initialized.
+
+Most graphics adapters require vendor specific tweaks for properly
+working graphics passthru. See the XenVGAPassthroughTestedAdapters
+L<http://wiki.xen.org/wiki/XenVGAPassthroughTestedAdapters> 
+wiki page for currently supported graphics cards for gfx_passthru.
+ 
+gfx_passthru is currently only supported with the qemu-xen-traditional
+device-model. Upstream qemu-xen device-model currently doesn't have
+support for gfx_passthru.
+
+Note that some graphics adapters (AMD/ATI cards, for example) don't
+necessarily require gfx_passthru option, so you can use the normal
+Xen PCI passthru to assign the graphics card as a secondary graphics card
+to the VM. Qemu emulated graphics card stays as the primary graphics card, 
+and you get VNC output from the Qemu-emulated primary adapter.
+
+More information about Xen gfx_passthru feature is available
+on the XenVGAPassthrough L<http://wiki.xen.org/wiki/XenVGAPassthrough> 
+wiki page.
 
 =item B<nomigrate=BOOLEAN>
 

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

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

--/e2eDi0V/xtL+Mc8--


From xen-devel-bounces@lists.xen.org Wed Sep 05 20:09:28 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Sep 2012 20:09:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9LuJ-0003mn-Hv; Wed, 05 Sep 2012 20:09:03 +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 1T9LuH-0003mi-MP
	for xen-devel@lists.xen.org; Wed, 05 Sep 2012 20:09:02 +0000
Received: from [85.158.143.99:15285] by server-2.bemta-4.messagelabs.com id
	0E/21-21239-C51B7405; Wed, 05 Sep 2012 20:09:00 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-6.tower-216.messagelabs.com!1346875739!21726627!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA1MDI2OTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7342 invoked from network); 5 Sep 2012 20:09:00 -0000
Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25)
	by server-6.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 5 Sep 2012 20:09:00 -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 19D331ACA;
	Wed,  5 Sep 2012 23:08:58 +0300 (EEST)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id 8493D2005D; Wed,  5 Sep 2012 23:08:58 +0300 (EEST)
Date: Wed, 5 Sep 2012 23:08:58 +0300
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120905200858.GP8912@reaktio.net>
References: <20120902053549.GF8912@reaktio.net>
	<1346667053.25864.21.camel@zakaz.uk.xensource.com>
	<20120904191229.GH8912@reaktio.net>
	<1346834000.17325.4.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="/e2eDi0V/xtL+Mc8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <1346834000.17325.4.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: [Xen-devel] [PATCH v2] xl.cfg: gfx_passthru documentation
	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>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--/e2eDi0V/xtL+Mc8
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit

Hello,

v2: address review comments.

xl.cfg.pod.5 documentation improvements:

- gfx_passthru: Document gfx_passthru makes the GPU become primary in the guest
  and other generic info about gfx_passthru.

Signed-off-by: Pasi Kärkkäinen <pasik@iki.fi>


--- xen-unstable.hg/docs/man/xl.cfg.pod.5.orig  2012-09-05 22:51:39.745137076 +0300
+++ xen-unstable.hg/docs/man/xl.cfg.pod.5       2012-09-05 23:02:29.746203364 +0300
@@ -992,7 +992,44 @@

 =item B<gfx_passthru=BOOLEAN>

-Enable graphics device PCI passthrough. XXX which device is passed through ?
+Enable graphics device PCI passthrough. This option makes the passthru
+graphics card become primary graphics card in the VM, so the Qemu emulated
+graphics adapter is disabled, and the VNC console for the VM won't have
+any graphics output. All graphics output, including boot time Qemu BIOS
+messages from the VM, will go to the physical outputs of the passed thru
+physical graphics card.
+
+Graphics card PCI device to passthru is chosen with B<pci> option,
+exactly in the same way as normal Xen PCI device passthru/assignment is done.
+Note that gfx_passthru doesn't do any kind of sharing
+of the GPU, so you can only assign the GPU to one single VM at a time.
+
+gfx_passthru also enables various legacy VGA memory ranges, BARs, MMIOs,
+and ioports to be passed thru to the VM, since those are required
+for correct operation of things like VGA BIOS, text mode, VBE, etc.
+
+Enabling gfx_passthru option also copies the physical graphics card
+video BIOS to the guest memory, and executes the VBIOS in the guest
+to get the graphics card initialized.
+
+Most graphics adapters require vendor specific tweaks for properly
+working graphics passthru. See the XenVGAPassthroughTestedAdapters
+L<http://wiki.xen.org/wiki/XenVGAPassthroughTestedAdapters>
+wiki page for currently supported graphics cards for gfx_passthru.
+
+gfx_passthru is currently only supported with the qemu-xen-traditional
+device-model. Upstream qemu-xen device-model currently doesn't have
+support for gfx_passthru.
+
+Note that some graphics adapters (AMD/ATI cards, for example) don't
+necessarily require gfx_passthru option, so you can use the normal
+Xen PCI passthru to assign the graphics card as a secondary graphics card
+to the VM. Qemu emulated graphics card stays as the primary graphics card,
+and you get VNC output from the Qemu-emulated primary adapter.
+
+More information about Xen gfx_passthru feature is available
+on the XenVGAPassthrough L<http://wiki.xen.org/wiki/XenVGAPassthrough>
+wiki page.

 =item B<nomigrate=BOOLEAN>


--/e2eDi0V/xtL+Mc8
Content-Type: text/x-diff; charset=us-ascii
Content-Disposition: attachment; filename="xl.cfg.pod.5-gfx_passthru-2.patch"

--- xen-unstable.hg/docs/man/xl.cfg.pod.5.orig	2012-09-05 22:51:39.745137076 +0300
+++ xen-unstable.hg/docs/man/xl.cfg.pod.5	2012-09-05 23:02:29.746203364 +0300
@@ -992,7 +992,44 @@
 
 =item B<gfx_passthru=BOOLEAN>
 
-Enable graphics device PCI passthrough. XXX which device is passed through ?
+Enable graphics device PCI passthrough. This option makes the passthru
+graphics card become primary graphics card in the VM, so the Qemu emulated 
+graphics adapter is disabled, and the VNC console for the VM won't have
+any graphics output. All graphics output, including boot time Qemu BIOS
+messages from the VM, will go to the physical outputs of the passed thru
+physical graphics card.
+
+Graphics card PCI device to passthru is chosen with B<pci> option, 
+exactly in the same way as normal Xen PCI device passthru/assignment is done. 
+Note that gfx_passthru doesn't do any kind of sharing
+of the GPU, so you can only assign the GPU to one single VM at a time.
+
+gfx_passthru also enables various legacy VGA memory ranges, BARs, MMIOs, 
+and ioports to be passed thru to the VM, since those are required
+for correct operation of things like VGA BIOS, text mode, VBE, etc.
+
+Enabling gfx_passthru option also copies the physical graphics card 
+video BIOS to the guest memory, and executes the VBIOS in the guest 
+to get the graphics card initialized.
+
+Most graphics adapters require vendor specific tweaks for properly
+working graphics passthru. See the XenVGAPassthroughTestedAdapters
+L<http://wiki.xen.org/wiki/XenVGAPassthroughTestedAdapters> 
+wiki page for currently supported graphics cards for gfx_passthru.
+ 
+gfx_passthru is currently only supported with the qemu-xen-traditional
+device-model. Upstream qemu-xen device-model currently doesn't have
+support for gfx_passthru.
+
+Note that some graphics adapters (AMD/ATI cards, for example) don't
+necessarily require gfx_passthru option, so you can use the normal
+Xen PCI passthru to assign the graphics card as a secondary graphics card
+to the VM. Qemu emulated graphics card stays as the primary graphics card, 
+and you get VNC output from the Qemu-emulated primary adapter.
+
+More information about Xen gfx_passthru feature is available
+on the XenVGAPassthrough L<http://wiki.xen.org/wiki/XenVGAPassthrough> 
+wiki page.
 
 =item B<nomigrate=BOOLEAN>
 

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

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

--/e2eDi0V/xtL+Mc8--


From xen-devel-bounces@lists.xen.org Wed Sep 05 20:14:32 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Sep 2012 20:14:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9LzH-0003v0-AI; Wed, 05 Sep 2012 20:14:11 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <karrelsj@gmail.com>) id 1T9LzF-0003us-VH
	for xen-devel@lists.xensource.com; Wed, 05 Sep 2012 20:14:10 +0000
Received: from [85.158.143.99:52131] by server-3.bemta-4.messagelabs.com id
	01/0E-08232-192B7405; Wed, 05 Sep 2012 20:14:09 +0000
X-Env-Sender: karrelsj@gmail.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1346876048!18979761!1
X-Originating-IP: [209.85.212.177]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31617 invoked from network); 5 Sep 2012 20:14:08 -0000
Received: from mail-wi0-f177.google.com (HELO mail-wi0-f177.google.com)
	(209.85.212.177)
	by server-8.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Sep 2012 20:14:08 -0000
Received: by wibhn17 with SMTP id hn17so544666wib.6
	for <xen-devel@lists.xensource.com>;
	Wed, 05 Sep 2012 13:14: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;
	bh=Cm6bVVlOSXMgbMcBxI9v/fKpWWTtT7fifhZc3OmRwXo=;
	b=pkun0L2wvQxb7lZAOFBBQ/6iyRsvBXqZ1kjeNPzzAuDeckRo+6tgq9LcX2UFuq8TMy
	eL9qG9AWWJ0l4eaYIGX3Ara9pCTiMcvk090uqTUJfOC38xyd9vwfGY2owSgqE7gx3WsT
	uNquJn0WsXdXFxwv4XWfKipm5ezDDXOgG3v3pxkCE8AwWQPK9isBOclB7ivzid2yc+lw
	oonn/OeyU7bj//fq+FNf8+1GYdwsI1aGHw4h5wGQL/sJtugrIlOkeeGoCT8frmRPyN3m
	KPz5e2jYxG2nhuKf89zg9GURkMyCG78NZmCimd7ustHuiDkHMn4Z4lUQCKzjzsu+fBp5
	hG0Q==
Received: by 10.181.13.208 with SMTP id fa16mr40470539wid.11.1346876048577;
	Wed, 05 Sep 2012 13:14:08 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.216.255.79 with HTTP; Wed, 5 Sep 2012 13:13:48 -0700 (PDT)
In-Reply-To: <20120316155132.GB31099@phenom.dumpdata.com>
References: <CAFw--Df+3UxXWqq63eo0f-98EeaisipX+eRr91qXouDkSfphSg@mail.gmail.com>
	<20120313164708.GE19228@phenom.dumpdata.com>
	<1331658232.8995.14.camel@Solace>
	<CAFw--DdRYLyEqyKm0h+mrasW_F=Akh_DuHbNHsiBJMrJAbLaLg@mail.gmail.com>
	<20120314185823.GC5341@phenom.dumpdata.com>
	<CAFw--DcCajB36X+rKrgTdDmkZLB0om9hQJLxiO1CBPuNjbdx8A@mail.gmail.com>
	<CAFw--Dcrw4vxWY44X4mOT0JUEfGbQVa6XtPYNEL_ieSNSRHzxg@mail.gmail.com>
	<20120316155132.GB31099@phenom.dumpdata.com>
From: Jeffrey Karrels <karrelsj@gmail.com>
Date: Wed, 5 Sep 2012 13:13:48 -0700
Message-ID: <CAFw--Ddq574pC9JGj9RLO8-OTQu-VswUx9Cb1bWWHvvVH9umvw@mail.gmail.com>
To: lars.kurth@xen.org
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] Static analysis: Code weaknesses
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> Huh? That really does not compute - as there are developers who are not
> Citrix employeed - and the sources/trees, etc are all on xenbits.org which
> is a non-prof organization I think? CC-ing Lars here as he might know better.

Lars, sorry to revive an ancient thread. Do you have any idea why
Coverity would not accept Xen into its opensource program?

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

From xen-devel-bounces@lists.xen.org Wed Sep 05 20:14:32 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Sep 2012 20:14:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9LzH-0003v0-AI; Wed, 05 Sep 2012 20:14:11 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <karrelsj@gmail.com>) id 1T9LzF-0003us-VH
	for xen-devel@lists.xensource.com; Wed, 05 Sep 2012 20:14:10 +0000
Received: from [85.158.143.99:52131] by server-3.bemta-4.messagelabs.com id
	01/0E-08232-192B7405; Wed, 05 Sep 2012 20:14:09 +0000
X-Env-Sender: karrelsj@gmail.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1346876048!18979761!1
X-Originating-IP: [209.85.212.177]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31617 invoked from network); 5 Sep 2012 20:14:08 -0000
Received: from mail-wi0-f177.google.com (HELO mail-wi0-f177.google.com)
	(209.85.212.177)
	by server-8.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Sep 2012 20:14:08 -0000
Received: by wibhn17 with SMTP id hn17so544666wib.6
	for <xen-devel@lists.xensource.com>;
	Wed, 05 Sep 2012 13:14: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;
	bh=Cm6bVVlOSXMgbMcBxI9v/fKpWWTtT7fifhZc3OmRwXo=;
	b=pkun0L2wvQxb7lZAOFBBQ/6iyRsvBXqZ1kjeNPzzAuDeckRo+6tgq9LcX2UFuq8TMy
	eL9qG9AWWJ0l4eaYIGX3Ara9pCTiMcvk090uqTUJfOC38xyd9vwfGY2owSgqE7gx3WsT
	uNquJn0WsXdXFxwv4XWfKipm5ezDDXOgG3v3pxkCE8AwWQPK9isBOclB7ivzid2yc+lw
	oonn/OeyU7bj//fq+FNf8+1GYdwsI1aGHw4h5wGQL/sJtugrIlOkeeGoCT8frmRPyN3m
	KPz5e2jYxG2nhuKf89zg9GURkMyCG78NZmCimd7ustHuiDkHMn4Z4lUQCKzjzsu+fBp5
	hG0Q==
Received: by 10.181.13.208 with SMTP id fa16mr40470539wid.11.1346876048577;
	Wed, 05 Sep 2012 13:14:08 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.216.255.79 with HTTP; Wed, 5 Sep 2012 13:13:48 -0700 (PDT)
In-Reply-To: <20120316155132.GB31099@phenom.dumpdata.com>
References: <CAFw--Df+3UxXWqq63eo0f-98EeaisipX+eRr91qXouDkSfphSg@mail.gmail.com>
	<20120313164708.GE19228@phenom.dumpdata.com>
	<1331658232.8995.14.camel@Solace>
	<CAFw--DdRYLyEqyKm0h+mrasW_F=Akh_DuHbNHsiBJMrJAbLaLg@mail.gmail.com>
	<20120314185823.GC5341@phenom.dumpdata.com>
	<CAFw--DcCajB36X+rKrgTdDmkZLB0om9hQJLxiO1CBPuNjbdx8A@mail.gmail.com>
	<CAFw--Dcrw4vxWY44X4mOT0JUEfGbQVa6XtPYNEL_ieSNSRHzxg@mail.gmail.com>
	<20120316155132.GB31099@phenom.dumpdata.com>
From: Jeffrey Karrels <karrelsj@gmail.com>
Date: Wed, 5 Sep 2012 13:13:48 -0700
Message-ID: <CAFw--Ddq574pC9JGj9RLO8-OTQu-VswUx9Cb1bWWHvvVH9umvw@mail.gmail.com>
To: lars.kurth@xen.org
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] Static analysis: Code weaknesses
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> Huh? That really does not compute - as there are developers who are not
> Citrix employeed - and the sources/trees, etc are all on xenbits.org which
> is a non-prof organization I think? CC-ing Lars here as he might know better.

Lars, sorry to revive an ancient thread. Do you have any idea why
Coverity would not accept Xen into its opensource program?

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

From xen-devel-bounces@lists.xen.org Wed Sep 05 20:16:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Sep 2012 20:16:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9M1T-00041N-S1; Wed, 05 Sep 2012 20:16:27 +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 1T9M1S-00041B-IL
	for xen-devel@lists.xensource.com; Wed, 05 Sep 2012 20:16:26 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1346876179!6338274!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDczODkxOA==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17229 invoked from network); 5 Sep 2012 20:16:20 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-5.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 5 Sep 2012 20:16:20 -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 q85KGDbM027767
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 5 Sep 2012 20:16:14 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q85KGDMu018470
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 5 Sep 2012 20:16:13 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
	q85KGD1s007157; Wed, 5 Sep 2012 15:16:13 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 05 Sep 2012 13:16:12 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 4D902402C1; Wed,  5 Sep 2012 16:05:43 -0400 (EDT)
Date: Wed, 5 Sep 2012 16:05:43 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Andres Lagar-Cavilla <andreslc@gridcentric.ca>
Message-ID: <20120905200543.GB27713@phenom.dumpdata.com>
References: <1346331492-15027-1-git-send-email-david.vrabel@citrix.com>
	<20120830200509.GA12955@localhost.localdomain>
	<EE725C18-21B4-4F03-834E-F516178E0EAA@gridcentric.ca>
	<20120905185728.GA14981@phenom.dumpdata.com>
	<8E34FA8A-2169-45E5-82D2-19EA35162F66@gridcentric.ca>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <8E34FA8A-2169-45E5-82D2-19EA35162F66@gridcentric.ca>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: Konrad Rzeszutek Wilk <konrad@kernel.org>, xen-devel@lists.xensource.com,
	David Vrabel <david.vrabel@citrix.com>
Subject: Re: [Xen-devel] [PATCHv3 0/2] xen/privcmd: support for paged-out
 frames
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Sep 05, 2012 at 03:51:03PM -0400, Andres Lagar-Cavilla wrote:
> 
> On Sep 5, 2012, at 2:57 PM, Konrad Rzeszutek Wilk wrote:
> 
> > On Thu, Aug 30, 2012 at 04:12:03PM -0400, Andres Lagar-Cavilla wrote:
> >> On Aug 30, 2012, at 4:05 PM, Konrad Rzeszutek Wilk wrote:
> >> 
> >>>> I think this should probably get a "Tested-by" Andres or someone else
> >>>> who uses paging before being applied.
> >>> 
> >>> How do I test it? Is there an easy explanation/tutorial Andres?
> >> 
> >> I have a unit test lying somewhere but I'll need a day to dig it out.
> > 
> > If you can send that that would be super..
> Yeah. Sorry, forgot. Will take me a bit though.
> >> 
> >> Or you can start an hvm, pause it, fire up xenpaging with debug output so it tells you what it paged out, and then trace libxc as you xc_map_foreign_bulk a known batch of evicted pfns. On the first try it should get rc == -1, errno == ENOENT, error field for the pfn == ENOENT. On the second try it should all be dandy.
> >> 
> > 
> > This works well with Xen 4.1 or should I use Xen 4.2?
> 
> Xen-4.1 is advertised to work with this but I've never tried. Xen-4.2 is what I use all the time

OK, Well I can also hoist the testing of this to you.
So let me make sure it works overnight and then push out the patches to my #linux-next
tree and you can test it and make sure nothing is amiss.


> 
> Andres
> 
> >> Thanks
> >> Andres

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

From xen-devel-bounces@lists.xen.org Wed Sep 05 20:16:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Sep 2012 20:16:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9M1T-00041N-S1; Wed, 05 Sep 2012 20:16:27 +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 1T9M1S-00041B-IL
	for xen-devel@lists.xensource.com; Wed, 05 Sep 2012 20:16:26 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1346876179!6338274!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDczODkxOA==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17229 invoked from network); 5 Sep 2012 20:16:20 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-5.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 5 Sep 2012 20:16:20 -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 q85KGDbM027767
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 5 Sep 2012 20:16:14 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q85KGDMu018470
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 5 Sep 2012 20:16:13 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
	q85KGD1s007157; Wed, 5 Sep 2012 15:16:13 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 05 Sep 2012 13:16:12 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 4D902402C1; Wed,  5 Sep 2012 16:05:43 -0400 (EDT)
Date: Wed, 5 Sep 2012 16:05:43 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Andres Lagar-Cavilla <andreslc@gridcentric.ca>
Message-ID: <20120905200543.GB27713@phenom.dumpdata.com>
References: <1346331492-15027-1-git-send-email-david.vrabel@citrix.com>
	<20120830200509.GA12955@localhost.localdomain>
	<EE725C18-21B4-4F03-834E-F516178E0EAA@gridcentric.ca>
	<20120905185728.GA14981@phenom.dumpdata.com>
	<8E34FA8A-2169-45E5-82D2-19EA35162F66@gridcentric.ca>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <8E34FA8A-2169-45E5-82D2-19EA35162F66@gridcentric.ca>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: Konrad Rzeszutek Wilk <konrad@kernel.org>, xen-devel@lists.xensource.com,
	David Vrabel <david.vrabel@citrix.com>
Subject: Re: [Xen-devel] [PATCHv3 0/2] xen/privcmd: support for paged-out
 frames
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Sep 05, 2012 at 03:51:03PM -0400, Andres Lagar-Cavilla wrote:
> 
> On Sep 5, 2012, at 2:57 PM, Konrad Rzeszutek Wilk wrote:
> 
> > On Thu, Aug 30, 2012 at 04:12:03PM -0400, Andres Lagar-Cavilla wrote:
> >> On Aug 30, 2012, at 4:05 PM, Konrad Rzeszutek Wilk wrote:
> >> 
> >>>> I think this should probably get a "Tested-by" Andres or someone else
> >>>> who uses paging before being applied.
> >>> 
> >>> How do I test it? Is there an easy explanation/tutorial Andres?
> >> 
> >> I have a unit test lying somewhere but I'll need a day to dig it out.
> > 
> > If you can send that that would be super..
> Yeah. Sorry, forgot. Will take me a bit though.
> >> 
> >> Or you can start an hvm, pause it, fire up xenpaging with debug output so it tells you what it paged out, and then trace libxc as you xc_map_foreign_bulk a known batch of evicted pfns. On the first try it should get rc == -1, errno == ENOENT, error field for the pfn == ENOENT. On the second try it should all be dandy.
> >> 
> > 
> > This works well with Xen 4.1 or should I use Xen 4.2?
> 
> Xen-4.1 is advertised to work with this but I've never tried. Xen-4.2 is what I use all the time

OK, Well I can also hoist the testing of this to you.
So let me make sure it works overnight and then push out the patches to my #linux-next
tree and you can test it and make sure nothing is amiss.


> 
> Andres
> 
> >> Thanks
> >> Andres

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

From xen-devel-bounces@lists.xen.org Wed Sep 05 20:31:33 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Sep 2012 20:31:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9MFn-0004Wc-UO; Wed, 05 Sep 2012 20:31:15 +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 1T9MFl-0004WV-FR
	for xen-devel@lists.xen.org; Wed, 05 Sep 2012 20:31:13 +0000
Received: from [85.158.143.99:42029] by server-2.bemta-4.messagelabs.com id
	7E/DD-21239-096B7405; Wed, 05 Sep 2012 20:31:12 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1346877070!18981652!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzI4NDYw\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14692 invoked from network); 5 Sep 2012 20:31:12 -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; 5 Sep 2012 20:31:12 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q85KU4gF020020
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 5 Sep 2012 20:30:05 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q85KU33x029332
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 5 Sep 2012 20:30:04 GMT
Received: from abhmt114.oracle.com (abhmt114.oracle.com [141.146.116.66])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q85KU2QT013413; Wed, 5 Sep 2012 15:30:03 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 05 Sep 2012 13:30:02 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 2E3CB402C1; Wed,  5 Sep 2012 16:19:33 -0400 (EDT)
Date: Wed, 5 Sep 2012 16:19:33 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Sander Eikelenboom <linux@eikelenboom.it>
Message-ID: <20120905201933.GA27814@phenom.dumpdata.com>
References: <1136369816.20120904183757@eikelenboom.it>
	<20120904163347.GH23361@phenom.dumpdata.com>
	<143844933.20120904191941@eikelenboom.it>
	<CAOvdn6U_yHgtZwv9MWazdLbd3NLq3pwGXnZY5sL2UVBhV_FUoQ@mail.gmail.com>
	<1813712325.20120904213459@eikelenboom.it>
	<048EAD622912254A9DEA24C1734613C18C864C3C5D@FTLPMAILBOX02.citrite.net>
	<20120905140600.GA5844@phenom.dumpdata.com>
	<1014998302.20120905163848@eikelenboom.it>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1014998302.20120905163848@eikelenboom.it>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: Robert Phillips <robert.phillips@citrix.com>, Ben Guthro <ben@guthro.net>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] dom0 linux 3.6.0-rc4,
 crash due to ballooning althoug dom0_mem=X, max:X set
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Sep 05, 2012 at 04:38:48PM +0200, Sander Eikelenboom wrote:
> 
> Wednesday, September 5, 2012, 4:06:01 PM, you wrote:
> 
> > On Tue, Sep 04, 2012 at 04:27:20PM -0400, Robert Phillips wrote:
> >> Ben,
> >> 
> >> You have asked me to provide the rationale behind the gnttab_old_mfn patch, which you emailed to Sander earlier today. 
> >> Here are my findings.
> >> 
> >> I found that xen_blkbk_map() in drivers/block/xen-blkback/blkback.c has changed from our previous version.  It now calls gnttab_map_refs() in drivers/xen/grant-table.c.
> >> 
> >> That function first calls HYPERVISOR_grant_table_op(GNTTABOP_map_grant_ref, ... ) and then calls m2p_add_override() in p2m.c
> 
> > And HYPERVISOR_grant_table_op .. would populate map_ops[i].bus_addr with the machine address..
> 
> >> which is where I made my change.
> >> 
> >> The unpatched code was saving the pfn's old mfn in kmap_op->dev_bus_addr.  
> >> 
> >> kmap_op is of type struct gnttab_map_grant_ref.  That data type is used to record grant table mappings so later they can be unmapped correctly.
> 
> > Right, but the blkback makes a distinction by passing NULL as kmap_op, which means it should
> > use the old mechanism. Meaning that once the hypercall is done, the map_ops[i].bus_addr is not
> > used anymore..
> 
> >> 
> >> The problem with saving the old mfn in kmap_op->dev_bus_addr is that it is later overwritten by __gnttab_map_grant_ref() in xen/common/grant_table.c
> 
> > Uh, so the problem of saving the old mfn in dev_bus_addr has been there for a long long time then?
> > Even before this patch set?
> >> 
> >> Since the storage holding the old mfn got overwritten, the unmapping was being done incorrectly.  The balloon code detected that and bugged at drivers/xen/balloon.c:359
> >> 
> 
> > Hmm, I believe the storage for holding the old mfn was/is page->index.
> 
> 
> >> My patch simply adds another member called old_mfn to struct gnttab_map_grant_ref rather than trying to overload dev_bus_addr.
> >> 
> >> I don't know if Sander's bug is the same or related.  The BUG_ON at drivers/xen/balloon.c:359 is quite general.  It simply asserts that we are not trying to re-map a valid mapping.
> 
> > Right. Somehow he ends up with valid mappings where there should be none. And lots of them.
> 
> It's something between kernel v3.4.1 and v3.5.3, haven't had time to narrow it down yet.
> Any suggestions for specific commits i could try to quickly bisect this one ?

These are the ones that went in:

ea61fc0 xen/p2m: Reserve 8MB of _brk space for P2M leafs when populating back.
b9e0d95 xen: mark local pages as FOREIGN in the m2p_override
6878c32 xen/blkfront: Add WARN to deal with misbehaving backends.
5e62625 xen/setup: filter APERFMPERF cpuid feature out
8c9ce60 xen/blkback: Copy id field when doing BLKIF_DISCARD.
58b7b53 xen/balloon: Subtract from xen_released_pages the count that is populated.
780dbcd xen/pci: Check for PCI bridge before using it.
5e152e6 xen/events: Add WARN_ON when quick lookup found invalid type.
5842f57 xen/hvc: Check HVM_PARAM_CONSOLE_[EVTCHN|PFN] for correctness.
a32c88b xen/hvc: Fix error cases around HVM_PARAM_CONSOLE_PFN
2e5ad6b xen/hvc: Collapse error logic.
7664810 xen: do not disable netfront in dom0
68c2c39 xen: do not map the same GSI twice in PVHVM guests.
201a52b hvc_xen: NULL dereference on allocation failure
d79d595 xen: Add selfballoning memory reservation tunable.
d2fb4c5 xenbus: Add support for xenbus backend in stub domain
2f1bd67 xen/smp: unbind irqworkX when unplugging vCPUs.
87e4baa x86/xen/apic: Add missing #include <xen/xen.h>
323f90a xen-acpi-processor: Add missing #include <xen/xen.h>
8605067 xen-blkfront: module exit handling adjustments
e77c78c xen-blkfront: properly name all devices
f62805f xen: enter/exit lazy_mmu_mode around m2p_override calls
211063d xen/acpi/sleep: Enable ACPI sleep via the __acpi_os_prepare_sleep
1ff2b0c xen: implement IRQ_WORK_VECTOR handler
f447d56 xen: implement apic ipi interface
83d51ab xen/setup: update VA mapping when releasing memory during setup
96dc08b xen/setup: Combine the two hypercall functions - since they are quite similar.
2e2fb75 xen/setup: Populate freed MFNs from non-RAM E820 entries and gaps to E820 RAM
ca11823 xen/setup: Only print "Freeing XXX-YYY pfn range: Z pages freed" if Z > 0
9438ef7 x86/apic: Fix UP boot crash
ab6ec39 xen/apic: implement io apic read with hypercall
27abd14 Revert "xen/x86: Workaround 'x86/ioapic: Add register level checks to detect bogus io-apic entries'"
31b3c9d xen/x86: Implement x86_apic_ops
4a8e2a3 x86/apic: Replace io_apic_ops with x86_io_apic_ops.
977f857 PCI: move mutex locking out of pci_dev_reset function
569ca5b xen/gnttab: add deferred freeing logic
9fe2a70 debugfs: Add support to print u32 array in debugfs
940713b xen/p2m: An early bootup variant of set_phys_to_machine
d509685 xen/p2m: Collapse early_alloc_p2m_middle redundant checks.
cef4cca xen/p2m: Allow alloc_p2m_middle to call reserve_brk depending on argument
3f3aaea xen/p2m: Move code around to allow for better re-usage.


Narrowing this down (so ignore APIC bootup, drivers, etc) these could be it:

b9e0d95 xen: mark local pages as FOREIGN in the m2p_override
58b7b53 xen/balloon: Subtract from xen_released_pages the count that is populated.
d79d595 xen: Add selfballoning memory reservation tunable.
f62805f xen: enter/exit lazy_mmu_mode around m2p_override calls
83d51ab xen/setup: update VA mapping when releasing memory during setup
96dc08b xen/setup: Combine the two hypercall functions - since they are quite similar.
2e2fb75 xen/setup: Populate freed MFNs from non-RAM E820 entries and gaps to E820 RAM
ca11823 xen/setup: Only print "Freeing XXX-YYY pfn range: Z pages freed" if Z > 0
940713b xen/p2m: An early bootup variant of set_phys_to_machine
d509685 xen/p2m: Collapse early_alloc_p2m_middle redundant checks.
cef4cca xen/p2m: Allow alloc_p2m_middle to call reserve_brk depending on argument
3f3aaea xen/p2m: Move code around to allow for better re-usage.

About nine of them deal with dom0_mem=max ballooning up right, so if you
ignore those:

b9e0d95 xen: mark local pages as FOREIGN in the m2p_override
d79d595 xen: Add selfballoning memory reservation tunable.
f62805f xen: enter/exit lazy_mmu_mode around m2p_override calls

Try reverting any of those.

And if nothing works there then we can try to revert the ones that
deal with 'dom0_mem=max:XX'..

I also need to be able to reproduce this. You said you can only reproduce this
on your Intel box - is this a fast Intel machine? It also looks like you only
have 2GB in the machine - and reserve 1GB to the dom0.

If you manually (so don't start the guest), balloon down - say to 512MB and then launch
a guest do you see this problem?

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

From xen-devel-bounces@lists.xen.org Wed Sep 05 20:31:33 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Sep 2012 20:31:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9MFn-0004Wc-UO; Wed, 05 Sep 2012 20:31:15 +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 1T9MFl-0004WV-FR
	for xen-devel@lists.xen.org; Wed, 05 Sep 2012 20:31:13 +0000
Received: from [85.158.143.99:42029] by server-2.bemta-4.messagelabs.com id
	7E/DD-21239-096B7405; Wed, 05 Sep 2012 20:31:12 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1346877070!18981652!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzI4NDYw\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14692 invoked from network); 5 Sep 2012 20:31:12 -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; 5 Sep 2012 20:31:12 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q85KU4gF020020
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 5 Sep 2012 20:30:05 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q85KU33x029332
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 5 Sep 2012 20:30:04 GMT
Received: from abhmt114.oracle.com (abhmt114.oracle.com [141.146.116.66])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q85KU2QT013413; Wed, 5 Sep 2012 15:30:03 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 05 Sep 2012 13:30:02 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 2E3CB402C1; Wed,  5 Sep 2012 16:19:33 -0400 (EDT)
Date: Wed, 5 Sep 2012 16:19:33 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Sander Eikelenboom <linux@eikelenboom.it>
Message-ID: <20120905201933.GA27814@phenom.dumpdata.com>
References: <1136369816.20120904183757@eikelenboom.it>
	<20120904163347.GH23361@phenom.dumpdata.com>
	<143844933.20120904191941@eikelenboom.it>
	<CAOvdn6U_yHgtZwv9MWazdLbd3NLq3pwGXnZY5sL2UVBhV_FUoQ@mail.gmail.com>
	<1813712325.20120904213459@eikelenboom.it>
	<048EAD622912254A9DEA24C1734613C18C864C3C5D@FTLPMAILBOX02.citrite.net>
	<20120905140600.GA5844@phenom.dumpdata.com>
	<1014998302.20120905163848@eikelenboom.it>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1014998302.20120905163848@eikelenboom.it>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: Robert Phillips <robert.phillips@citrix.com>, Ben Guthro <ben@guthro.net>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] dom0 linux 3.6.0-rc4,
 crash due to ballooning althoug dom0_mem=X, max:X set
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Sep 05, 2012 at 04:38:48PM +0200, Sander Eikelenboom wrote:
> 
> Wednesday, September 5, 2012, 4:06:01 PM, you wrote:
> 
> > On Tue, Sep 04, 2012 at 04:27:20PM -0400, Robert Phillips wrote:
> >> Ben,
> >> 
> >> You have asked me to provide the rationale behind the gnttab_old_mfn patch, which you emailed to Sander earlier today. 
> >> Here are my findings.
> >> 
> >> I found that xen_blkbk_map() in drivers/block/xen-blkback/blkback.c has changed from our previous version.  It now calls gnttab_map_refs() in drivers/xen/grant-table.c.
> >> 
> >> That function first calls HYPERVISOR_grant_table_op(GNTTABOP_map_grant_ref, ... ) and then calls m2p_add_override() in p2m.c
> 
> > And HYPERVISOR_grant_table_op .. would populate map_ops[i].bus_addr with the machine address..
> 
> >> which is where I made my change.
> >> 
> >> The unpatched code was saving the pfn's old mfn in kmap_op->dev_bus_addr.  
> >> 
> >> kmap_op is of type struct gnttab_map_grant_ref.  That data type is used to record grant table mappings so later they can be unmapped correctly.
> 
> > Right, but the blkback makes a distinction by passing NULL as kmap_op, which means it should
> > use the old mechanism. Meaning that once the hypercall is done, the map_ops[i].bus_addr is not
> > used anymore..
> 
> >> 
> >> The problem with saving the old mfn in kmap_op->dev_bus_addr is that it is later overwritten by __gnttab_map_grant_ref() in xen/common/grant_table.c
> 
> > Uh, so the problem of saving the old mfn in dev_bus_addr has been there for a long long time then?
> > Even before this patch set?
> >> 
> >> Since the storage holding the old mfn got overwritten, the unmapping was being done incorrectly.  The balloon code detected that and bugged at drivers/xen/balloon.c:359
> >> 
> 
> > Hmm, I believe the storage for holding the old mfn was/is page->index.
> 
> 
> >> My patch simply adds another member called old_mfn to struct gnttab_map_grant_ref rather than trying to overload dev_bus_addr.
> >> 
> >> I don't know if Sander's bug is the same or related.  The BUG_ON at drivers/xen/balloon.c:359 is quite general.  It simply asserts that we are not trying to re-map a valid mapping.
> 
> > Right. Somehow he ends up with valid mappings where there should be none. And lots of them.
> 
> It's something between kernel v3.4.1 and v3.5.3, haven't had time to narrow it down yet.
> Any suggestions for specific commits i could try to quickly bisect this one ?

These are the ones that went in:

ea61fc0 xen/p2m: Reserve 8MB of _brk space for P2M leafs when populating back.
b9e0d95 xen: mark local pages as FOREIGN in the m2p_override
6878c32 xen/blkfront: Add WARN to deal with misbehaving backends.
5e62625 xen/setup: filter APERFMPERF cpuid feature out
8c9ce60 xen/blkback: Copy id field when doing BLKIF_DISCARD.
58b7b53 xen/balloon: Subtract from xen_released_pages the count that is populated.
780dbcd xen/pci: Check for PCI bridge before using it.
5e152e6 xen/events: Add WARN_ON when quick lookup found invalid type.
5842f57 xen/hvc: Check HVM_PARAM_CONSOLE_[EVTCHN|PFN] for correctness.
a32c88b xen/hvc: Fix error cases around HVM_PARAM_CONSOLE_PFN
2e5ad6b xen/hvc: Collapse error logic.
7664810 xen: do not disable netfront in dom0
68c2c39 xen: do not map the same GSI twice in PVHVM guests.
201a52b hvc_xen: NULL dereference on allocation failure
d79d595 xen: Add selfballoning memory reservation tunable.
d2fb4c5 xenbus: Add support for xenbus backend in stub domain
2f1bd67 xen/smp: unbind irqworkX when unplugging vCPUs.
87e4baa x86/xen/apic: Add missing #include <xen/xen.h>
323f90a xen-acpi-processor: Add missing #include <xen/xen.h>
8605067 xen-blkfront: module exit handling adjustments
e77c78c xen-blkfront: properly name all devices
f62805f xen: enter/exit lazy_mmu_mode around m2p_override calls
211063d xen/acpi/sleep: Enable ACPI sleep via the __acpi_os_prepare_sleep
1ff2b0c xen: implement IRQ_WORK_VECTOR handler
f447d56 xen: implement apic ipi interface
83d51ab xen/setup: update VA mapping when releasing memory during setup
96dc08b xen/setup: Combine the two hypercall functions - since they are quite similar.
2e2fb75 xen/setup: Populate freed MFNs from non-RAM E820 entries and gaps to E820 RAM
ca11823 xen/setup: Only print "Freeing XXX-YYY pfn range: Z pages freed" if Z > 0
9438ef7 x86/apic: Fix UP boot crash
ab6ec39 xen/apic: implement io apic read with hypercall
27abd14 Revert "xen/x86: Workaround 'x86/ioapic: Add register level checks to detect bogus io-apic entries'"
31b3c9d xen/x86: Implement x86_apic_ops
4a8e2a3 x86/apic: Replace io_apic_ops with x86_io_apic_ops.
977f857 PCI: move mutex locking out of pci_dev_reset function
569ca5b xen/gnttab: add deferred freeing logic
9fe2a70 debugfs: Add support to print u32 array in debugfs
940713b xen/p2m: An early bootup variant of set_phys_to_machine
d509685 xen/p2m: Collapse early_alloc_p2m_middle redundant checks.
cef4cca xen/p2m: Allow alloc_p2m_middle to call reserve_brk depending on argument
3f3aaea xen/p2m: Move code around to allow for better re-usage.


Narrowing this down (so ignore APIC bootup, drivers, etc) these could be it:

b9e0d95 xen: mark local pages as FOREIGN in the m2p_override
58b7b53 xen/balloon: Subtract from xen_released_pages the count that is populated.
d79d595 xen: Add selfballoning memory reservation tunable.
f62805f xen: enter/exit lazy_mmu_mode around m2p_override calls
83d51ab xen/setup: update VA mapping when releasing memory during setup
96dc08b xen/setup: Combine the two hypercall functions - since they are quite similar.
2e2fb75 xen/setup: Populate freed MFNs from non-RAM E820 entries and gaps to E820 RAM
ca11823 xen/setup: Only print "Freeing XXX-YYY pfn range: Z pages freed" if Z > 0
940713b xen/p2m: An early bootup variant of set_phys_to_machine
d509685 xen/p2m: Collapse early_alloc_p2m_middle redundant checks.
cef4cca xen/p2m: Allow alloc_p2m_middle to call reserve_brk depending on argument
3f3aaea xen/p2m: Move code around to allow for better re-usage.

About nine of them deal with dom0_mem=max ballooning up right, so if you
ignore those:

b9e0d95 xen: mark local pages as FOREIGN in the m2p_override
d79d595 xen: Add selfballoning memory reservation tunable.
f62805f xen: enter/exit lazy_mmu_mode around m2p_override calls

Try reverting any of those.

And if nothing works there then we can try to revert the ones that
deal with 'dom0_mem=max:XX'..

I also need to be able to reproduce this. You said you can only reproduce this
on your Intel box - is this a fast Intel machine? It also looks like you only
have 2GB in the machine - and reserve 1GB to the dom0.

If you manually (so don't start the guest), balloon down - say to 512MB and then launch
a guest do you see this problem?

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

From xen-devel-bounces@lists.xen.org Wed Sep 05 20:32:22 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Sep 2012 20:32:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9MGf-0004b5-IR; Wed, 05 Sep 2012 20:32:09 +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 1T9MGe-0004ar-Hk
	for xen-devel@lists.xen.org; Wed, 05 Sep 2012 20:32:08 +0000
Received: from [85.158.143.35:62520] by server-1.bemta-4.messagelabs.com id
	79/7D-12504-7C6B7405; Wed, 05 Sep 2012 20:32:07 +0000
X-Env-Sender: msw@amazon.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1346877120!12413963!1
X-Originating-IP: [207.171.178.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA3LjE3MS4xNzguMjUgPT4gNjU1MTM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7492 invoked from network); 5 Sep 2012 20:32:03 -0000
Received: from smtp-fw-31001.amazon.com (HELO smtp-fw-31001.amazon.com)
	(207.171.178.25)
	by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Sep 2012 20:32:03 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=amazon.com; i=msw@amazon.com; q=dns/txt; s=rte02;
	t=1346877122; x=1378413122;
	h=date:from:to:cc:subject:message-id:references:
	mime-version:in-reply-to;
	bh=weYfTFCljrbFAUUawEUS2pPVdOSV9Qrhfomfs+TD0Lg=;
	b=luHWZOnqD+YpimcShgPtMLGHm/31aLwemXKqQhlOAz+nFGw9T5pRU8Zi
	Pl3zK+kTZiUntVOa3iQC8LVZrJsNcQ==;
X-IronPort-AV: E=Sophos;i="4.80,376,1344211200"; d="scan'208";a="289914386"
Received: from smtp-in-0102.sea3.amazon.com ([10.224.19.46])
	by smtp-border-fw-out-31001.sea31.amazon.com with
	ESMTP/TLS/DHE-RSA-AES256-SHA; 05 Sep 2012 20:31:58 +0000
Received: from ex10-hub-9003.ant.amazon.com (ex10-hub-9003.ant.amazon.com
	[10.185.137.132])
	by smtp-in-0102.sea3.amazon.com (8.13.8/8.13.8) with ESMTP id
	q85KVvJk006258
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL);
	Wed, 5 Sep 2012 20:31:58 GMT
Received: from u002268147cd4502c336d.ant.amazon.com (10.224.80.34) by
	ex10-hub-9003.ant.amazon.com (10.185.137.132) with Microsoft SMTP
	Server id 14.2.247.3; Wed, 5 Sep 2012 13:31:52 -0700
Received: by u002268147cd4502c336d.ant.amazon.com (sSMTP sendmail emulation); 
	Wed, 05 Sep 2012 13:31:55 -0700
Date: Wed, 5 Sep 2012 13:31:55 -0700
From: Matt Wilson <msw@amazon.com>
To: Mark van Dijk <lists+xen@internecto.net>
Message-ID: <20120905203153.GA26680@u002268147cd4502c336d.ant.amazon.com>
References: <1346665360.25864.2.camel@zakaz.uk.xensource.com>
	<20120905152926.GM8912@reaktio.net>
	<20120905195307.101d0cbc@internecto.net>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120905195307.101d0cbc@internecto.net>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: xen-users@lists.xen.org, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [Xen-users]  Xen 4.2.0 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, Sep 05, 2012 at 07:53:07PM +0200, Mark van Dijk wrote:
> >> tools, nice to have:
> >
> >      * pygrub support for ext4 on rhel5/centos5.
> >        Roger already sent a patch for this.
> 
> I'd love to see some kind of extlinux (or grub2) that can replace the
> current pv-grub. Both support ext4 and, more importantly imho,
> btrfs, now that is one really cool filesystem.

Personally I'd love to see pv-extlinux. I chatted last week with some
folks at the Linux Plumbers Conference about this, and I think it
should be possible with a lot of work.

> Grub0.97 is/will be being deprecated on an increasing number of
> distributions. And pv-grub is safer than pygrub because pygrub executes
> in the dom0 and pv-grub in the domU, if I understand correctly.
> 
> Anyone willing to share thoughts on the possibility of 'pv-extlinux?'

I believe that syslinux only builds as 32-bit, and the elf output is
only an intermediate build target. Booting a 64-bit kernel with a
32-bit pv-extlinux won't work. Also, I'm not sure that you could load
the .elf output and do anything useful with it. I've heard a rumor
that a pure-C syslinux version is in the works, which could help with
this.

syslinux has a really decent subset of the standard C library in
com32/, and implementing the frontend drivers with it shouldn't not be
too hard. Building libxc against it might be another matter entirely.

GRUB2 is currently more popular than extlinux I think, and it might
lend itself to a PV port more readily. There was some initial work
that made grub-emu run on top of MiniOS [1], but I'm not sure that it
got much farther than that.

Matt

[1] http://lists.xen.org/archives/html/xen-devel/2009-05/msg00666.html

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

From xen-devel-bounces@lists.xen.org Wed Sep 05 20:32:22 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Sep 2012 20:32:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9MGf-0004b5-IR; Wed, 05 Sep 2012 20:32:09 +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 1T9MGe-0004ar-Hk
	for xen-devel@lists.xen.org; Wed, 05 Sep 2012 20:32:08 +0000
Received: from [85.158.143.35:62520] by server-1.bemta-4.messagelabs.com id
	79/7D-12504-7C6B7405; Wed, 05 Sep 2012 20:32:07 +0000
X-Env-Sender: msw@amazon.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1346877120!12413963!1
X-Originating-IP: [207.171.178.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA3LjE3MS4xNzguMjUgPT4gNjU1MTM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7492 invoked from network); 5 Sep 2012 20:32:03 -0000
Received: from smtp-fw-31001.amazon.com (HELO smtp-fw-31001.amazon.com)
	(207.171.178.25)
	by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Sep 2012 20:32:03 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=amazon.com; i=msw@amazon.com; q=dns/txt; s=rte02;
	t=1346877122; x=1378413122;
	h=date:from:to:cc:subject:message-id:references:
	mime-version:in-reply-to;
	bh=weYfTFCljrbFAUUawEUS2pPVdOSV9Qrhfomfs+TD0Lg=;
	b=luHWZOnqD+YpimcShgPtMLGHm/31aLwemXKqQhlOAz+nFGw9T5pRU8Zi
	Pl3zK+kTZiUntVOa3iQC8LVZrJsNcQ==;
X-IronPort-AV: E=Sophos;i="4.80,376,1344211200"; d="scan'208";a="289914386"
Received: from smtp-in-0102.sea3.amazon.com ([10.224.19.46])
	by smtp-border-fw-out-31001.sea31.amazon.com with
	ESMTP/TLS/DHE-RSA-AES256-SHA; 05 Sep 2012 20:31:58 +0000
Received: from ex10-hub-9003.ant.amazon.com (ex10-hub-9003.ant.amazon.com
	[10.185.137.132])
	by smtp-in-0102.sea3.amazon.com (8.13.8/8.13.8) with ESMTP id
	q85KVvJk006258
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL);
	Wed, 5 Sep 2012 20:31:58 GMT
Received: from u002268147cd4502c336d.ant.amazon.com (10.224.80.34) by
	ex10-hub-9003.ant.amazon.com (10.185.137.132) with Microsoft SMTP
	Server id 14.2.247.3; Wed, 5 Sep 2012 13:31:52 -0700
Received: by u002268147cd4502c336d.ant.amazon.com (sSMTP sendmail emulation); 
	Wed, 05 Sep 2012 13:31:55 -0700
Date: Wed, 5 Sep 2012 13:31:55 -0700
From: Matt Wilson <msw@amazon.com>
To: Mark van Dijk <lists+xen@internecto.net>
Message-ID: <20120905203153.GA26680@u002268147cd4502c336d.ant.amazon.com>
References: <1346665360.25864.2.camel@zakaz.uk.xensource.com>
	<20120905152926.GM8912@reaktio.net>
	<20120905195307.101d0cbc@internecto.net>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120905195307.101d0cbc@internecto.net>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: xen-users@lists.xen.org, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [Xen-users]  Xen 4.2.0 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, Sep 05, 2012 at 07:53:07PM +0200, Mark van Dijk wrote:
> >> tools, nice to have:
> >
> >      * pygrub support for ext4 on rhel5/centos5.
> >        Roger already sent a patch for this.
> 
> I'd love to see some kind of extlinux (or grub2) that can replace the
> current pv-grub. Both support ext4 and, more importantly imho,
> btrfs, now that is one really cool filesystem.

Personally I'd love to see pv-extlinux. I chatted last week with some
folks at the Linux Plumbers Conference about this, and I think it
should be possible with a lot of work.

> Grub0.97 is/will be being deprecated on an increasing number of
> distributions. And pv-grub is safer than pygrub because pygrub executes
> in the dom0 and pv-grub in the domU, if I understand correctly.
> 
> Anyone willing to share thoughts on the possibility of 'pv-extlinux?'

I believe that syslinux only builds as 32-bit, and the elf output is
only an intermediate build target. Booting a 64-bit kernel with a
32-bit pv-extlinux won't work. Also, I'm not sure that you could load
the .elf output and do anything useful with it. I've heard a rumor
that a pure-C syslinux version is in the works, which could help with
this.

syslinux has a really decent subset of the standard C library in
com32/, and implementing the frontend drivers with it shouldn't not be
too hard. Building libxc against it might be another matter entirely.

GRUB2 is currently more popular than extlinux I think, and it might
lend itself to a PV port more readily. There was some initial work
that made grub-emu run on top of MiniOS [1], but I'm not sure that it
got much farther than that.

Matt

[1] http://lists.xen.org/archives/html/xen-devel/2009-05/msg00666.html

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

From xen-devel-bounces@lists.xen.org Wed Sep 05 20:42:59 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Sep 2012 20: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 1T9MQt-00051E-Ry; Wed, 05 Sep 2012 20:42:43 +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 1T9MQs-000519-J5
	for xen-devel@lists.xen.org; Wed, 05 Sep 2012 20:42:42 +0000
Received: from [85.158.139.83:33279] by server-7.bemta-5.messagelabs.com id
	72/AA-19703-149B7405; Wed, 05 Sep 2012 20:42:41 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1346877760!24842240!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDczODkxOA==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2740 invoked from network); 5 Sep 2012 20:42:41 -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; 5 Sep 2012 20:42:41 -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 q85Kdxr1018910
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 5 Sep 2012 20:40:00 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q85Kdvuu018172
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 5 Sep 2012 20:39:58 GMT
Received: from abhmt114.oracle.com (abhmt114.oracle.com [141.146.116.66])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q85Kdv5x020537; Wed, 5 Sep 2012 15:39:57 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 05 Sep 2012 13:39:57 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 79C84402C1; Wed,  5 Sep 2012 16:29:27 -0400 (EDT)
Date: Wed, 5 Sep 2012 16:29:27 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: James Harper <james.harper@bendigoit.com.au>
Message-ID: <20120905202927.GD27814@phenom.dumpdata.com>
References: <6035A0D088A63A46850C3988ED045A4B299F74F8@BITCOM1.int.sbss.com.au>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <6035A0D088A63A46850C3988ED045A4B299F74F8@BITCOM1.int.sbss.com.au>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] bug when using 4K sectors?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Aug 13, 2012 at 02:12:58PM +0000, James Harper wrote:
> I notice this code in drivers/block/xen-blkback/common.h
> 
> #define vbd_sz(_v)      ((_v)->bdev->bd_part ? \
>                          (_v)->bdev->bd_part->nr_sects : \
>                           get_capacity((_v)->bdev->bd_disk))
> 
> is the value returned by vbd_sz(_v) the number of sectors in the Linux device (eg size / 4096), or the number of 512 byte sectors? I suspect the former which is causing block requests beyond 1/8th the size of the device to fail (assuming 4K sectors are expected to work at all - I can't quite get my head around how it would be expected to work - does Linux do the read-modify-write if required?)

I think you need to instrument it to be sure.. But more interesting, do you actually
have a disk that exposes a 4KB hardware and logical sector? So far I've only found
SSDs that expose a 512kB logical sector but also expose the 4KB hardware.

Never could figure out how that is all suppose to work as the blkback
is filled with << 9 on a bunch of things.

> 
> I can't test until tomorrow AEDT, but maybe someone here knows the answer already?
> 
> James
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

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

From xen-devel-bounces@lists.xen.org Wed Sep 05 20:42:59 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Sep 2012 20: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 1T9MQt-00051E-Ry; Wed, 05 Sep 2012 20:42:43 +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 1T9MQs-000519-J5
	for xen-devel@lists.xen.org; Wed, 05 Sep 2012 20:42:42 +0000
Received: from [85.158.139.83:33279] by server-7.bemta-5.messagelabs.com id
	72/AA-19703-149B7405; Wed, 05 Sep 2012 20:42:41 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1346877760!24842240!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDczODkxOA==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2740 invoked from network); 5 Sep 2012 20:42:41 -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; 5 Sep 2012 20:42:41 -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 q85Kdxr1018910
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 5 Sep 2012 20:40:00 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q85Kdvuu018172
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 5 Sep 2012 20:39:58 GMT
Received: from abhmt114.oracle.com (abhmt114.oracle.com [141.146.116.66])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q85Kdv5x020537; Wed, 5 Sep 2012 15:39:57 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 05 Sep 2012 13:39:57 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 79C84402C1; Wed,  5 Sep 2012 16:29:27 -0400 (EDT)
Date: Wed, 5 Sep 2012 16:29:27 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: James Harper <james.harper@bendigoit.com.au>
Message-ID: <20120905202927.GD27814@phenom.dumpdata.com>
References: <6035A0D088A63A46850C3988ED045A4B299F74F8@BITCOM1.int.sbss.com.au>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <6035A0D088A63A46850C3988ED045A4B299F74F8@BITCOM1.int.sbss.com.au>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] bug when using 4K sectors?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Aug 13, 2012 at 02:12:58PM +0000, James Harper wrote:
> I notice this code in drivers/block/xen-blkback/common.h
> 
> #define vbd_sz(_v)      ((_v)->bdev->bd_part ? \
>                          (_v)->bdev->bd_part->nr_sects : \
>                           get_capacity((_v)->bdev->bd_disk))
> 
> is the value returned by vbd_sz(_v) the number of sectors in the Linux device (eg size / 4096), or the number of 512 byte sectors? I suspect the former which is causing block requests beyond 1/8th the size of the device to fail (assuming 4K sectors are expected to work at all - I can't quite get my head around how it would be expected to work - does Linux do the read-modify-write if required?)

I think you need to instrument it to be sure.. But more interesting, do you actually
have a disk that exposes a 4KB hardware and logical sector? So far I've only found
SSDs that expose a 512kB logical sector but also expose the 4KB hardware.

Never could figure out how that is all suppose to work as the blkback
is filled with << 9 on a bunch of things.

> 
> I can't test until tomorrow AEDT, but maybe someone here knows the answer already?
> 
> James
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

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

From xen-devel-bounces@lists.xen.org Wed Sep 05 20:56:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Sep 2012 20: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 1T9MdZ-0005BN-60; Wed, 05 Sep 2012 20:55:49 +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 1T9MdX-0005BF-0r
	for xen-devel@lists.xen.org; Wed, 05 Sep 2012 20:55:47 +0000
Received: from [85.158.143.99:5240] by server-2.bemta-4.messagelabs.com id
	02/6B-21239-25CB7405; Wed, 05 Sep 2012 20:55:46 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-11.tower-216.messagelabs.com!1346878545!21225057!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA1MDI2OTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31068 invoked from network); 5 Sep 2012 20:55:45 -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; 5 Sep 2012 20:55:45 -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 763F02AB7;
	Wed,  5 Sep 2012 23:55:44 +0300 (EEST)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id 011872005D; Wed,  5 Sep 2012 23:55:43 +0300 (EEST)
Date: Wed, 5 Sep 2012 23:55:43 +0300
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120905205543.GQ8912@reaktio.net>
References: <20120905030239.GJ8912@reaktio.net>
	<1346846602-1109-1-git-send-email-roger.pau@citrix.com>
	<1346868289.10570.6.camel@dagon.hellion.org.uk>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1346868289.10570.6.camel@dagon.hellion.org.uk>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Roger Pau Monne <roger.pau@citrix.com>
Subject: Re: [Xen-devel] [PATCH] libfsimage: add ext4 support for CentOS 5.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 Wed, Sep 05, 2012 at 07:04:49PM +0100, Ian Campbell wrote:
> On Wed, 2012-09-05 at 13:03 +0100, Roger Pau Monne wrote:
> > CentOS 5.x forked e2fs ext4 support into a different package called
> > e4fs, and so headers and library names changed from ext2fs to ext4fs.
> > Check if ext4fs/ext2fs.h and -lext4fs work, and use that instead of
> > ext2fs to build libfsimage. This patch assumes that if the ext4fs
> > library is present it should always be used instead of ext2fs.
> > 
> > This patch includes a rework of the ext2fs check, a new ext4fs check
> > and a minor modification in libfsimage to use the correct library.
> > 
> > Signed-off-by: Roger Pau Monne <roger.pau@citrix.com>
> 
> Thanks.
> 
> Any patch which is intended for 4.2 at this stage needs to come with
> some rationale as to why it is acceptable at this late stage.
> 

rhel5/centos5 has a lot of Xen users, so it'd be nice if those people
could build Xen 4.2 from sources and still have pygrub ext4 support.

(the stock redhat el5 Xen 3.1.2 rpms have similar tweaks and 
they do provide pygrub ext4 support out-of-the-box on el5).

Also XenServer/XCP has hacks to get pygrub ext4 support enabled in similar way,
so it'd make sense to fix/workaround this properly in Xen upstream.

> Therefore unless someone can argue convincingly for it this is 4.3
> material.
> 

I'm not expecting that was convincing enough :) so if not 4.2.0 then 4.3 and 4.2.1 ? 

-- Pasi


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

From xen-devel-bounces@lists.xen.org Wed Sep 05 20:56:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Sep 2012 20: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 1T9MdZ-0005BN-60; Wed, 05 Sep 2012 20:55:49 +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 1T9MdX-0005BF-0r
	for xen-devel@lists.xen.org; Wed, 05 Sep 2012 20:55:47 +0000
Received: from [85.158.143.99:5240] by server-2.bemta-4.messagelabs.com id
	02/6B-21239-25CB7405; Wed, 05 Sep 2012 20:55:46 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-11.tower-216.messagelabs.com!1346878545!21225057!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA1MDI2OTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31068 invoked from network); 5 Sep 2012 20:55:45 -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; 5 Sep 2012 20:55:45 -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 763F02AB7;
	Wed,  5 Sep 2012 23:55:44 +0300 (EEST)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id 011872005D; Wed,  5 Sep 2012 23:55:43 +0300 (EEST)
Date: Wed, 5 Sep 2012 23:55:43 +0300
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120905205543.GQ8912@reaktio.net>
References: <20120905030239.GJ8912@reaktio.net>
	<1346846602-1109-1-git-send-email-roger.pau@citrix.com>
	<1346868289.10570.6.camel@dagon.hellion.org.uk>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1346868289.10570.6.camel@dagon.hellion.org.uk>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Roger Pau Monne <roger.pau@citrix.com>
Subject: Re: [Xen-devel] [PATCH] libfsimage: add ext4 support for CentOS 5.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 Wed, Sep 05, 2012 at 07:04:49PM +0100, Ian Campbell wrote:
> On Wed, 2012-09-05 at 13:03 +0100, Roger Pau Monne wrote:
> > CentOS 5.x forked e2fs ext4 support into a different package called
> > e4fs, and so headers and library names changed from ext2fs to ext4fs.
> > Check if ext4fs/ext2fs.h and -lext4fs work, and use that instead of
> > ext2fs to build libfsimage. This patch assumes that if the ext4fs
> > library is present it should always be used instead of ext2fs.
> > 
> > This patch includes a rework of the ext2fs check, a new ext4fs check
> > and a minor modification in libfsimage to use the correct library.
> > 
> > Signed-off-by: Roger Pau Monne <roger.pau@citrix.com>
> 
> Thanks.
> 
> Any patch which is intended for 4.2 at this stage needs to come with
> some rationale as to why it is acceptable at this late stage.
> 

rhel5/centos5 has a lot of Xen users, so it'd be nice if those people
could build Xen 4.2 from sources and still have pygrub ext4 support.

(the stock redhat el5 Xen 3.1.2 rpms have similar tweaks and 
they do provide pygrub ext4 support out-of-the-box on el5).

Also XenServer/XCP has hacks to get pygrub ext4 support enabled in similar way,
so it'd make sense to fix/workaround this properly in Xen upstream.

> Therefore unless someone can argue convincingly for it this is 4.3
> material.
> 

I'm not expecting that was convincing enough :) so if not 4.2.0 then 4.3 and 4.2.1 ? 

-- Pasi


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

From xen-devel-bounces@lists.xen.org Wed Sep 05 21:11:35 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Sep 2012 21:11:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9MsZ-0005yG-5M; Wed, 05 Sep 2012 21:11: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 1T9MsX-0005xl-Mw
	for xen-devel@lists.xensource.com; Wed, 05 Sep 2012 21:11:18 +0000
Received: from [85.158.139.83:11434] by server-11.bemta-5.messagelabs.com id
	05/E6-24658-4FFB7405; Wed, 05 Sep 2012 21:11:16 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1346879475!28565824!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTE5NjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8787 invoked from network); 5 Sep 2012 21:11:15 -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;
	5 Sep 2012 21:11:15 -0000
X-IronPort-AV: E=Sophos;i="4.80,375,1344211200"; d="scan'208";a="14368169"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Sep 2012 21:11: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.279.1; Wed, 5 Sep 2012 22:11:14 +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 1T9MsT-000738-US;
	Wed, 05 Sep 2012 21:11:13 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1T9MsT-0002Vq-IT;
	Wed, 05 Sep 2012 22:11:13 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-13650-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 5 Sep 2012 22:11:13 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.0-testing test] 13650: 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 13650 xen-4.0-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13650/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf      5 xen-boot                  fail REGR. vs. 13588
 test-amd64-i386-xl-credit2    5 xen-boot                     fail   like 13580

Tests which did not succeed, but are not blocking:
 test-amd64-i386-xl-multivcpu 15 guest-stop                   fail   never pass
 test-amd64-amd64-xl-pcipt-intel  8 debian-fixup                fail never pass
 test-i386-i386-xl            15 guest-stop                   fail   never pass
 test-amd64-i386-xl           15 guest-stop                   fail   never pass
 test-amd64-i386-qemuu-rhel6hvm-amd  7 redhat-install           fail never pass
 test-amd64-amd64-xl-sedf-pin 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-i386-qemuu-rhel6hvm-intel  7 redhat-install         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-amd64-xl-qemuu-win7-amd64  8 guest-saverestore      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-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1  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-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
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-i386-i386-xl-winxpsp3    7 windows-install              fail   never pass

version targeted for testing:
 xen                  79444af3258c
baseline version:
 xen                  228e6f382d5d

------------------------------------------------------------
People who touched revisions under test:
  Ian Campbell <ian.campbell@citrix.com>
  Jan Beulich <jbeulich@suse.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                                          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=79444af3258c
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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 79444af3258c
+ branch=xen-4.0-testing
+ revision=79444af3258c
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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 79444af3258c 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 3 changes to 3 files

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

From xen-devel-bounces@lists.xen.org Wed Sep 05 21:11:35 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Sep 2012 21:11:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9MsZ-0005yG-5M; Wed, 05 Sep 2012 21:11: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 1T9MsX-0005xl-Mw
	for xen-devel@lists.xensource.com; Wed, 05 Sep 2012 21:11:18 +0000
Received: from [85.158.139.83:11434] by server-11.bemta-5.messagelabs.com id
	05/E6-24658-4FFB7405; Wed, 05 Sep 2012 21:11:16 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1346879475!28565824!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTE5NjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8787 invoked from network); 5 Sep 2012 21:11:15 -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;
	5 Sep 2012 21:11:15 -0000
X-IronPort-AV: E=Sophos;i="4.80,375,1344211200"; d="scan'208";a="14368169"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Sep 2012 21:11: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.279.1; Wed, 5 Sep 2012 22:11:14 +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 1T9MsT-000738-US;
	Wed, 05 Sep 2012 21:11:13 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1T9MsT-0002Vq-IT;
	Wed, 05 Sep 2012 22:11:13 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-13650-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 5 Sep 2012 22:11:13 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.0-testing test] 13650: 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 13650 xen-4.0-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13650/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf      5 xen-boot                  fail REGR. vs. 13588
 test-amd64-i386-xl-credit2    5 xen-boot                     fail   like 13580

Tests which did not succeed, but are not blocking:
 test-amd64-i386-xl-multivcpu 15 guest-stop                   fail   never pass
 test-amd64-amd64-xl-pcipt-intel  8 debian-fixup                fail never pass
 test-i386-i386-xl            15 guest-stop                   fail   never pass
 test-amd64-i386-xl           15 guest-stop                   fail   never pass
 test-amd64-i386-qemuu-rhel6hvm-amd  7 redhat-install           fail never pass
 test-amd64-amd64-xl-sedf-pin 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-i386-qemuu-rhel6hvm-intel  7 redhat-install         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-amd64-xl-qemuu-win7-amd64  8 guest-saverestore      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-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1  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-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
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-i386-i386-xl-winxpsp3    7 windows-install              fail   never pass

version targeted for testing:
 xen                  79444af3258c
baseline version:
 xen                  228e6f382d5d

------------------------------------------------------------
People who touched revisions under test:
  Ian Campbell <ian.campbell@citrix.com>
  Jan Beulich <jbeulich@suse.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                                          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=79444af3258c
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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 79444af3258c
+ branch=xen-4.0-testing
+ revision=79444af3258c
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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 79444af3258c 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 3 changes to 3 files

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

From xen-devel-bounces@lists.xen.org Wed Sep 05 22:52:58 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Sep 2012 22:52: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 1T9OSR-000729-Pj; Wed, 05 Sep 2012 22:52:27 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <linux@eikelenboom.it>) id 1T9OSQ-000724-KH
	for xen-devel@lists.xen.org; Wed, 05 Sep 2012 22:52:26 +0000
Received: from [85.158.139.83:60626] by server-3.bemta-5.messagelabs.com id
	C8/12-21836-9A7D7405; Wed, 05 Sep 2012 22:52:25 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-11.tower-182.messagelabs.com!1346885544!21580035!1
X-Originating-IP: [188.40.164.121]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2048 invoked from network); 5 Sep 2012 22:52:24 -0000
Received: from static.121.164.40.188.clients.your-server.de (HELO
	smtp.eikelenboom.it) (188.40.164.121)
	by server-11.tower-182.messagelabs.com with AES256-SHA encrypted SMTP;
	5 Sep 2012 22:52:24 -0000
Received: from 128-64-ftth.onsneteindhoven.nl ([88.159.64.128]:56544
	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 1T9OSO-0000PE-1y; Thu, 06 Sep 2012 00:52:24 +0200
Date: Thu, 6 Sep 2012 00:52:20 +0200
From: Sander Eikelenboom <linux@eikelenboom.it>
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <679529047.20120906005220@eikelenboom.it>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
In-Reply-To: <20120905201933.GA27814@phenom.dumpdata.com>
References: <1136369816.20120904183757@eikelenboom.it>
	<20120904163347.GH23361@phenom.dumpdata.com>
	<143844933.20120904191941@eikelenboom.it>
	<CAOvdn6U_yHgtZwv9MWazdLbd3NLq3pwGXnZY5sL2UVBhV_FUoQ@mail.gmail.com>
	<1813712325.20120904213459@eikelenboom.it>
	<048EAD622912254A9DEA24C1734613C18C864C3C5D@FTLPMAILBOX02.citrite.net>
	<20120905140600.GA5844@phenom.dumpdata.com>
	<1014998302.20120905163848@eikelenboom.it>
	<20120905201933.GA27814@phenom.dumpdata.com>
MIME-Version: 1.0
Cc: Robert Phillips <robert.phillips@citrix.com>, Ben Guthro <ben@guthro.net>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] dom0 linux 3.6.0-rc4,
	crash due to ballooning althoug dom0_mem=X, max:X 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


Wednesday, September 5, 2012, 10:19:33 PM, you wrote:

> On Wed, Sep 05, 2012 at 04:38:48PM +0200, Sander Eikelenboom wrote:
>> 
>> Wednesday, September 5, 2012, 4:06:01 PM, you wrote:
>> 
>> > On Tue, Sep 04, 2012 at 04:27:20PM -0400, Robert Phillips wrote:
>> >> Ben,
>> >> 
>> >> You have asked me to provide the rationale behind the gnttab_old_mfn patch, which you emailed to Sander earlier today. 
>> >> Here are my findings.
>> >> 
>> >> I found that xen_blkbk_map() in drivers/block/xen-blkback/blkback.c has changed from our previous version.  It now calls gnttab_map_refs() in drivers/xen/grant-table.c.
>> >> 
>> >> That function first calls HYPERVISOR_grant_table_op(GNTTABOP_map_grant_ref, ... ) and then calls m2p_add_override() in p2m.c
>> 
>> > And HYPERVISOR_grant_table_op .. would populate map_ops[i].bus_addr with the machine address..
>> 
>> >> which is where I made my change.
>> >> 
>> >> The unpatched code was saving the pfn's old mfn in kmap_op->dev_bus_addr.  
>> >> 
>> >> kmap_op is of type struct gnttab_map_grant_ref.  That data type is used to record grant table mappings so later they can be unmapped correctly.
>> 
>> > Right, but the blkback makes a distinction by passing NULL as kmap_op, which means it should
>> > use the old mechanism. Meaning that once the hypercall is done, the map_ops[i].bus_addr is not
>> > used anymore..
>> 
>> >> 
>> >> The problem with saving the old mfn in kmap_op->dev_bus_addr is that it is later overwritten by __gnttab_map_grant_ref() in xen/common/grant_table.c
>> 
>> > Uh, so the problem of saving the old mfn in dev_bus_addr has been there for a long long time then?
>> > Even before this patch set?
>> >> 
>> >> Since the storage holding the old mfn got overwritten, the unmapping was being done incorrectly.  The balloon code detected that and bugged at drivers/xen/balloon.c:359
>> >> 
>> 
>> > Hmm, I believe the storage for holding the old mfn was/is page->index.
>> 
>> 
>> >> My patch simply adds another member called old_mfn to struct gnttab_map_grant_ref rather than trying to overload dev_bus_addr.
>> >> 
>> >> I don't know if Sander's bug is the same or related.  The BUG_ON at drivers/xen/balloon.c:359 is quite general.  It simply asserts that we are not trying to re-map a valid mapping.
>> 
>> > Right. Somehow he ends up with valid mappings where there should be none. And lots of them.
>> 
>> It's something between kernel v3.4.1 and v3.5.3, haven't had time to narrow it down yet.
>> Any suggestions for specific commits i could try to quickly bisect this one ?

> These are the ones that went in:

> ea61fc0 xen/p2m: Reserve 8MB of _brk space for P2M leafs when populating back.
> b9e0d95 xen: mark local pages as FOREIGN in the m2p_override
> 6878c32 xen/blkfront: Add WARN to deal with misbehaving backends.
> 5e62625 xen/setup: filter APERFMPERF cpuid feature out
> 8c9ce60 xen/blkback: Copy id field when doing BLKIF_DISCARD.
> 58b7b53 xen/balloon: Subtract from xen_released_pages the count that is populated.
> 780dbcd xen/pci: Check for PCI bridge before using it.
> 5e152e6 xen/events: Add WARN_ON when quick lookup found invalid type.
> 5842f57 xen/hvc: Check HVM_PARAM_CONSOLE_[EVTCHN|PFN] for correctness.
> a32c88b xen/hvc: Fix error cases around HVM_PARAM_CONSOLE_PFN
> 2e5ad6b xen/hvc: Collapse error logic.
> 7664810 xen: do not disable netfront in dom0
> 68c2c39 xen: do not map the same GSI twice in PVHVM guests.
> 201a52b hvc_xen: NULL dereference on allocation failure
> d79d595 xen: Add selfballoning memory reservation tunable.
> d2fb4c5 xenbus: Add support for xenbus backend in stub domain
> 2f1bd67 xen/smp: unbind irqworkX when unplugging vCPUs.
> 87e4baa x86/xen/apic: Add missing #include <xen/xen.h>
> 323f90a xen-acpi-processor: Add missing #include <xen/xen.h>
> 8605067 xen-blkfront: module exit handling adjustments
> e77c78c xen-blkfront: properly name all devices
> f62805f xen: enter/exit lazy_mmu_mode around m2p_override calls
> 211063d xen/acpi/sleep: Enable ACPI sleep via the __acpi_os_prepare_sleep
> 1ff2b0c xen: implement IRQ_WORK_VECTOR handler
> f447d56 xen: implement apic ipi interface
> 83d51ab xen/setup: update VA mapping when releasing memory during setup
> 96dc08b xen/setup: Combine the two hypercall functions - since they are quite similar.
> 2e2fb75 xen/setup: Populate freed MFNs from non-RAM E820 entries and gaps to E820 RAM
> ca11823 xen/setup: Only print "Freeing XXX-YYY pfn range: Z pages freed" if Z > 0
> 9438ef7 x86/apic: Fix UP boot crash
> ab6ec39 xen/apic: implement io apic read with hypercall
> 27abd14 Revert "xen/x86: Workaround 'x86/ioapic: Add register level checks to detect bogus io-apic entries'"
> 31b3c9d xen/x86: Implement x86_apic_ops
> 4a8e2a3 x86/apic: Replace io_apic_ops with x86_io_apic_ops.
> 977f857 PCI: move mutex locking out of pci_dev_reset function
> 569ca5b xen/gnttab: add deferred freeing logic
> 9fe2a70 debugfs: Add support to print u32 array in debugfs
> 940713b xen/p2m: An early bootup variant of set_phys_to_machine
> d509685 xen/p2m: Collapse early_alloc_p2m_middle redundant checks.
> cef4cca xen/p2m: Allow alloc_p2m_middle to call reserve_brk depending on argument
> 3f3aaea xen/p2m: Move code around to allow for better re-usage.


> Narrowing this down (so ignore APIC bootup, drivers, etc) these could be it:

> b9e0d95 xen: mark local pages as FOREIGN in the m2p_override
> 58b7b53 xen/balloon: Subtract from xen_released_pages the count that is populated.
> d79d595 xen: Add selfballoning memory reservation tunable.
> f62805f xen: enter/exit lazy_mmu_mode around m2p_override calls
> 83d51ab xen/setup: update VA mapping when releasing memory during setup
> 96dc08b xen/setup: Combine the two hypercall functions - since they are quite similar.
> 2e2fb75 xen/setup: Populate freed MFNs from non-RAM E820 entries and gaps to E820 RAM
> ca11823 xen/setup: Only print "Freeing XXX-YYY pfn range: Z pages freed" if Z > 0
> 940713b xen/p2m: An early bootup variant of set_phys_to_machine
> d509685 xen/p2m: Collapse early_alloc_p2m_middle redundant checks.
> cef4cca xen/p2m: Allow alloc_p2m_middle to call reserve_brk depending on argument
> 3f3aaea xen/p2m: Move code around to allow for better re-usage.

> About nine of them deal with dom0_mem=max ballooning up right, so if you
> ignore those:

> b9e0d95 xen: mark local pages as FOREIGN in the m2p_override
> d79d595 xen: Add selfballoning memory reservation tunable.
> f62805f xen: enter/exit lazy_mmu_mode around m2p_override calls

> Try reverting any of those.

Ah i missed your email since my hostingprovider was down :-(
But anyway done a git bisect in the mean time that leads to:

[f62805f1f30a40e354bd036b4cb799863a39be4b] xen: enter/exit lazy_mmu_mode around m2p_override calls


> And if nothing works there then we can try to revert the ones that
> deal with 'dom0_mem=max:XX'..

> I also need to be able to reproduce this. You said you can only reproduce this
> on your Intel box - is this a fast Intel machine? It also looks like you only
> have 2GB in the machine - and reserve 1GB to the dom0.

Machine is a quad core q9400 @ 2.66mhz, not very fast .. not very slow either

> If you manually (so don't start the guest), balloon down - say to 512MB and then launch
> a guest do you see this problem?


Should i use

xl  mem-max domain-id mem

or

xl  mem-set domain-id mem

for that ?


Perhaps a silly question, but why is it ballooning anyway ?
I have set dom0's memory and there is enough left to create the domain ... or at least there should be ...

--
Sander


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

From xen-devel-bounces@lists.xen.org Wed Sep 05 22:52:58 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Sep 2012 22:52: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 1T9OSR-000729-Pj; Wed, 05 Sep 2012 22:52:27 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <linux@eikelenboom.it>) id 1T9OSQ-000724-KH
	for xen-devel@lists.xen.org; Wed, 05 Sep 2012 22:52:26 +0000
Received: from [85.158.139.83:60626] by server-3.bemta-5.messagelabs.com id
	C8/12-21836-9A7D7405; Wed, 05 Sep 2012 22:52:25 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-11.tower-182.messagelabs.com!1346885544!21580035!1
X-Originating-IP: [188.40.164.121]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2048 invoked from network); 5 Sep 2012 22:52:24 -0000
Received: from static.121.164.40.188.clients.your-server.de (HELO
	smtp.eikelenboom.it) (188.40.164.121)
	by server-11.tower-182.messagelabs.com with AES256-SHA encrypted SMTP;
	5 Sep 2012 22:52:24 -0000
Received: from 128-64-ftth.onsneteindhoven.nl ([88.159.64.128]:56544
	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 1T9OSO-0000PE-1y; Thu, 06 Sep 2012 00:52:24 +0200
Date: Thu, 6 Sep 2012 00:52:20 +0200
From: Sander Eikelenboom <linux@eikelenboom.it>
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <679529047.20120906005220@eikelenboom.it>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
In-Reply-To: <20120905201933.GA27814@phenom.dumpdata.com>
References: <1136369816.20120904183757@eikelenboom.it>
	<20120904163347.GH23361@phenom.dumpdata.com>
	<143844933.20120904191941@eikelenboom.it>
	<CAOvdn6U_yHgtZwv9MWazdLbd3NLq3pwGXnZY5sL2UVBhV_FUoQ@mail.gmail.com>
	<1813712325.20120904213459@eikelenboom.it>
	<048EAD622912254A9DEA24C1734613C18C864C3C5D@FTLPMAILBOX02.citrite.net>
	<20120905140600.GA5844@phenom.dumpdata.com>
	<1014998302.20120905163848@eikelenboom.it>
	<20120905201933.GA27814@phenom.dumpdata.com>
MIME-Version: 1.0
Cc: Robert Phillips <robert.phillips@citrix.com>, Ben Guthro <ben@guthro.net>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] dom0 linux 3.6.0-rc4,
	crash due to ballooning althoug dom0_mem=X, max:X 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


Wednesday, September 5, 2012, 10:19:33 PM, you wrote:

> On Wed, Sep 05, 2012 at 04:38:48PM +0200, Sander Eikelenboom wrote:
>> 
>> Wednesday, September 5, 2012, 4:06:01 PM, you wrote:
>> 
>> > On Tue, Sep 04, 2012 at 04:27:20PM -0400, Robert Phillips wrote:
>> >> Ben,
>> >> 
>> >> You have asked me to provide the rationale behind the gnttab_old_mfn patch, which you emailed to Sander earlier today. 
>> >> Here are my findings.
>> >> 
>> >> I found that xen_blkbk_map() in drivers/block/xen-blkback/blkback.c has changed from our previous version.  It now calls gnttab_map_refs() in drivers/xen/grant-table.c.
>> >> 
>> >> That function first calls HYPERVISOR_grant_table_op(GNTTABOP_map_grant_ref, ... ) and then calls m2p_add_override() in p2m.c
>> 
>> > And HYPERVISOR_grant_table_op .. would populate map_ops[i].bus_addr with the machine address..
>> 
>> >> which is where I made my change.
>> >> 
>> >> The unpatched code was saving the pfn's old mfn in kmap_op->dev_bus_addr.  
>> >> 
>> >> kmap_op is of type struct gnttab_map_grant_ref.  That data type is used to record grant table mappings so later they can be unmapped correctly.
>> 
>> > Right, but the blkback makes a distinction by passing NULL as kmap_op, which means it should
>> > use the old mechanism. Meaning that once the hypercall is done, the map_ops[i].bus_addr is not
>> > used anymore..
>> 
>> >> 
>> >> The problem with saving the old mfn in kmap_op->dev_bus_addr is that it is later overwritten by __gnttab_map_grant_ref() in xen/common/grant_table.c
>> 
>> > Uh, so the problem of saving the old mfn in dev_bus_addr has been there for a long long time then?
>> > Even before this patch set?
>> >> 
>> >> Since the storage holding the old mfn got overwritten, the unmapping was being done incorrectly.  The balloon code detected that and bugged at drivers/xen/balloon.c:359
>> >> 
>> 
>> > Hmm, I believe the storage for holding the old mfn was/is page->index.
>> 
>> 
>> >> My patch simply adds another member called old_mfn to struct gnttab_map_grant_ref rather than trying to overload dev_bus_addr.
>> >> 
>> >> I don't know if Sander's bug is the same or related.  The BUG_ON at drivers/xen/balloon.c:359 is quite general.  It simply asserts that we are not trying to re-map a valid mapping.
>> 
>> > Right. Somehow he ends up with valid mappings where there should be none. And lots of them.
>> 
>> It's something between kernel v3.4.1 and v3.5.3, haven't had time to narrow it down yet.
>> Any suggestions for specific commits i could try to quickly bisect this one ?

> These are the ones that went in:

> ea61fc0 xen/p2m: Reserve 8MB of _brk space for P2M leafs when populating back.
> b9e0d95 xen: mark local pages as FOREIGN in the m2p_override
> 6878c32 xen/blkfront: Add WARN to deal with misbehaving backends.
> 5e62625 xen/setup: filter APERFMPERF cpuid feature out
> 8c9ce60 xen/blkback: Copy id field when doing BLKIF_DISCARD.
> 58b7b53 xen/balloon: Subtract from xen_released_pages the count that is populated.
> 780dbcd xen/pci: Check for PCI bridge before using it.
> 5e152e6 xen/events: Add WARN_ON when quick lookup found invalid type.
> 5842f57 xen/hvc: Check HVM_PARAM_CONSOLE_[EVTCHN|PFN] for correctness.
> a32c88b xen/hvc: Fix error cases around HVM_PARAM_CONSOLE_PFN
> 2e5ad6b xen/hvc: Collapse error logic.
> 7664810 xen: do not disable netfront in dom0
> 68c2c39 xen: do not map the same GSI twice in PVHVM guests.
> 201a52b hvc_xen: NULL dereference on allocation failure
> d79d595 xen: Add selfballoning memory reservation tunable.
> d2fb4c5 xenbus: Add support for xenbus backend in stub domain
> 2f1bd67 xen/smp: unbind irqworkX when unplugging vCPUs.
> 87e4baa x86/xen/apic: Add missing #include <xen/xen.h>
> 323f90a xen-acpi-processor: Add missing #include <xen/xen.h>
> 8605067 xen-blkfront: module exit handling adjustments
> e77c78c xen-blkfront: properly name all devices
> f62805f xen: enter/exit lazy_mmu_mode around m2p_override calls
> 211063d xen/acpi/sleep: Enable ACPI sleep via the __acpi_os_prepare_sleep
> 1ff2b0c xen: implement IRQ_WORK_VECTOR handler
> f447d56 xen: implement apic ipi interface
> 83d51ab xen/setup: update VA mapping when releasing memory during setup
> 96dc08b xen/setup: Combine the two hypercall functions - since they are quite similar.
> 2e2fb75 xen/setup: Populate freed MFNs from non-RAM E820 entries and gaps to E820 RAM
> ca11823 xen/setup: Only print "Freeing XXX-YYY pfn range: Z pages freed" if Z > 0
> 9438ef7 x86/apic: Fix UP boot crash
> ab6ec39 xen/apic: implement io apic read with hypercall
> 27abd14 Revert "xen/x86: Workaround 'x86/ioapic: Add register level checks to detect bogus io-apic entries'"
> 31b3c9d xen/x86: Implement x86_apic_ops
> 4a8e2a3 x86/apic: Replace io_apic_ops with x86_io_apic_ops.
> 977f857 PCI: move mutex locking out of pci_dev_reset function
> 569ca5b xen/gnttab: add deferred freeing logic
> 9fe2a70 debugfs: Add support to print u32 array in debugfs
> 940713b xen/p2m: An early bootup variant of set_phys_to_machine
> d509685 xen/p2m: Collapse early_alloc_p2m_middle redundant checks.
> cef4cca xen/p2m: Allow alloc_p2m_middle to call reserve_brk depending on argument
> 3f3aaea xen/p2m: Move code around to allow for better re-usage.


> Narrowing this down (so ignore APIC bootup, drivers, etc) these could be it:

> b9e0d95 xen: mark local pages as FOREIGN in the m2p_override
> 58b7b53 xen/balloon: Subtract from xen_released_pages the count that is populated.
> d79d595 xen: Add selfballoning memory reservation tunable.
> f62805f xen: enter/exit lazy_mmu_mode around m2p_override calls
> 83d51ab xen/setup: update VA mapping when releasing memory during setup
> 96dc08b xen/setup: Combine the two hypercall functions - since they are quite similar.
> 2e2fb75 xen/setup: Populate freed MFNs from non-RAM E820 entries and gaps to E820 RAM
> ca11823 xen/setup: Only print "Freeing XXX-YYY pfn range: Z pages freed" if Z > 0
> 940713b xen/p2m: An early bootup variant of set_phys_to_machine
> d509685 xen/p2m: Collapse early_alloc_p2m_middle redundant checks.
> cef4cca xen/p2m: Allow alloc_p2m_middle to call reserve_brk depending on argument
> 3f3aaea xen/p2m: Move code around to allow for better re-usage.

> About nine of them deal with dom0_mem=max ballooning up right, so if you
> ignore those:

> b9e0d95 xen: mark local pages as FOREIGN in the m2p_override
> d79d595 xen: Add selfballoning memory reservation tunable.
> f62805f xen: enter/exit lazy_mmu_mode around m2p_override calls

> Try reverting any of those.

Ah i missed your email since my hostingprovider was down :-(
But anyway done a git bisect in the mean time that leads to:

[f62805f1f30a40e354bd036b4cb799863a39be4b] xen: enter/exit lazy_mmu_mode around m2p_override calls


> And if nothing works there then we can try to revert the ones that
> deal with 'dom0_mem=max:XX'..

> I also need to be able to reproduce this. You said you can only reproduce this
> on your Intel box - is this a fast Intel machine? It also looks like you only
> have 2GB in the machine - and reserve 1GB to the dom0.

Machine is a quad core q9400 @ 2.66mhz, not very fast .. not very slow either

> If you manually (so don't start the guest), balloon down - say to 512MB and then launch
> a guest do you see this problem?


Should i use

xl  mem-max domain-id mem

or

xl  mem-set domain-id mem

for that ?


Perhaps a silly question, but why is it ballooning anyway ?
I have set dom0's memory and there is enough left to create the domain ... or at least there should be ...

--
Sander


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

From xen-devel-bounces@lists.xen.org Wed Sep 05 23:00:19 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Sep 2012 23:00:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9OZb-0007D4-Tf; Wed, 05 Sep 2012 22:59:51 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <linux@eikelenboom.it>) id 1T9OZZ-0007Cz-J3
	for xen-devel@lists.xensource.com; Wed, 05 Sep 2012 22:59:50 +0000
Received: from [85.158.143.35:13701] by server-2.bemta-4.messagelabs.com id
	05/B6-21239-469D7405; Wed, 05 Sep 2012 22:59:48 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-4.tower-21.messagelabs.com!1346885981!5207701!1
X-Originating-IP: [188.40.164.121]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8280 invoked from network); 5 Sep 2012 22:59:41 -0000
Received: from static.121.164.40.188.clients.your-server.de (HELO
	smtp.eikelenboom.it) (188.40.164.121)
	by server-4.tower-21.messagelabs.com with AES256-SHA encrypted SMTP;
	5 Sep 2012 22:59:41 -0000
Received: from 128-64-ftth.onsneteindhoven.nl ([88.159.64.128]:56555
	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 1T9OZP-0000S8-H2; Thu, 06 Sep 2012 00:59:40 +0200
Date: Thu, 6 Sep 2012 00:59:36 +0200
From: Sander Eikelenboom <linux@eikelenboom.it>
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <326589347.20120906005936@eikelenboom.it>
To: Wei Wang <wei.wang2@amd.com>
In-Reply-To: <504764E2.4000809@amd.com>
References: <504764E2.4000809@amd.com>
MIME-Version: 1.0
Content-Type: multipart/mixed;
 boundary="----------0F617E023294CEA4E"
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH] amd iommu: Dump flags of IO page faults
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

------------0F617E023294CEA4E
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit


Wednesday, September 5, 2012, 4:42:42 PM, you wrote:

> Hi Jan,
> Attached patch dumps io page fault flags. The flags show the reason of 
> the fault and tell us if this is an unmapped interrupt fault or a DMA fault.

> Thanks,
> Wei

> signed-off-by: Wei Wang <wei.wang2@amd.com>


I have applied the patch and the flags seem to differ between the faults:

AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0a06, fault address = 0xc2c2c2c0, flags = 0x000
(XEN) [2012-09-05 20:54:16] AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0a06, fault address = 0xc2c2c2c0, flags = 0x000
(XEN) [2012-09-05 20:54:16] AMD-Vi: IO_PAGE_FAULT: domain = 14, device id = 0x0700, fault address = 0xa8d339e0, flags = 0x020
(XEN) [2012-09-05 20:54:16] AMD-Vi: IO_PAGE_FAULT: domain = 14, device id = 0x0700, fault address = 0xa8d33a40, flags = 0x020

Complete xl dmesg and lspci -vvvknn attached.

Thx

--
Sander
------------0F617E023294CEA4E
Content-Type: text/plain;
 name="lspci.txt"
Content-transfer-encoding: base64
Content-Disposition: attachment;
 filename="lspci.txt"

MDA6MDAuMCBIb3N0IGJyaWRnZSBbMDYwMF06IEFUSSBUZWNobm9sb2dpZXMgSW5jIFJEODkw
IE5vcnRoYnJpZGdlIG9ubHkgc2luZ2xlIHNsb3QgUENJLWUgR0ZYIEh5ZHJhIHBhcnQgWzEw
MDI6NWExMV0gKHJldiAwMikNCglTdWJzeXN0ZW06IEFUSSBUZWNobm9sb2dpZXMgSW5jIFJE
ODkwIE5vcnRoYnJpZGdlIG9ubHkgc2luZ2xlIHNsb3QgUENJLWUgR0ZYIEh5ZHJhIHBhcnQg
WzEwMDI6NWExMV0NCglDb250cm9sOiBJL08tIE1lbSsgQnVzTWFzdGVyLSBTcGVjQ3ljbGUt
IE1lbVdJTlYtIFZHQVNub29wLSBQYXJFcnItIFN0ZXBwaW5nLSBTRVJSLSBGYXN0QjJCLSBE
aXNJTlR4LQ0KCVN0YXR1czogQ2FwKyA2Nk1Iei0gVURGLSBGYXN0QjJCLSBQYXJFcnItIERF
VlNFTD1mYXN0ID5UQWJvcnQtIDxUQWJvcnQtIDxNQWJvcnQrID5TRVJSLSA8UEVSUi0gSU5U
eC0NCglDYXBhYmlsaXRpZXM6IFtmMF0gSHlwZXJUcmFuc3BvcnQ6IE1TSSBNYXBwaW5nIEVu
YWJsZSsgRml4ZWQrDQoJQ2FwYWJpbGl0aWVzOiBbYzRdIEh5cGVyVHJhbnNwb3J0OiBTbGF2
ZSBvciBQcmltYXJ5IEludGVyZmFjZQ0KCQlDb21tYW5kOiBCYXNlVW5pdElEPTAgVW5pdENu
dD0yMCBNYXN0SG9zdC0gRGVmRGlyLSBEVUwtDQoJCUxpbmsgQ29udHJvbCAwOiBDRmxFLSBD
U1QtIENGRS0gPExrRmFpbC0gSW5pdCsgRU9DLSBUWE8tIDxDUkNFcnI9MCBJc29jRW4tIExT
RW4tIEV4dENUTC0gNjRiLQ0KCQlMaW5rIENvbmZpZyAwOiBNTFdJPTE2Yml0IER3RmNJbi0g
TUxXTz0xNmJpdCBEd0ZjT3V0LSBMV0k9MTZiaXQgRHdGY0luRW4tIExXTz0xNmJpdCBEd0Zj
T3V0RW4tDQoJCUxpbmsgQ29udHJvbCAxOiBDRmxFLSBDU1QtIENGRS0gPExrRmFpbCsgSW5p
dC0gRU9DKyBUWE8rIDxDUkNFcnI9MCBJc29jRW4tIExTRW4tIEV4dENUTC0gNjRiLQ0KCQlM
aW5rIENvbmZpZyAxOiBNTFdJPThiaXQgRHdGY0luLSBNTFdPPThiaXQgRHdGY091dC0gTFdJ
PThiaXQgRHdGY0luRW4tIExXTz04Yml0IER3RmNPdXRFbi0NCgkJUmV2aXNpb24gSUQ6IDMu
MDANCgkJTGluayBGcmVxdWVuY3kgMDogW2JdDQoJCUxpbmsgRXJyb3IgMDogPFByb3QtIDxP
dmZsLSA8RU9DLSBDVExUbS0NCgkJTGluayBGcmVxdWVuY3kgQ2FwYWJpbGl0eSAwOiAyMDBN
SHorIDMwME1Iei0gNDAwTUh6KyA1MDBNSHotIDYwME1IeisgODAwTUh6KyAxLjBHSHorIDEu
MkdIeisgMS40R0h6LSAxLjZHSHotIFZlbmQtDQoJCUZlYXR1cmUgQ2FwYWJpbGl0eTogSXNv
Y0ZDKyBMRFRTVE9QKyBDUkNUTS0gRUNUTFQtIDY0YkErIFVJRFJELQ0KCQlMaW5rIEZyZXF1
ZW5jeSAxOiAyMDBNSHoNCgkJTGluayBFcnJvciAxOiA8UHJvdC0gPE92ZmwtIDxFT0MtIENU
TFRtLQ0KCQlMaW5rIEZyZXF1ZW5jeSBDYXBhYmlsaXR5IDE6IDIwME1Iei0gMzAwTUh6LSA0
MDBNSHotIDUwME1Iei0gNjAwTUh6LSA4MDBNSHotIDEuMEdIei0gMS4yR0h6LSAxLjRHSHot
IDEuNkdIei0gVmVuZC0NCgkJRXJyb3IgSGFuZGxpbmc6IFBGbEUtIE9GbEUtIFBGRS0gT0ZF
LSBFT0NGRS0gUkZFLSBDUkNGRS0gU0VSUkZFLSBDRi0gUkUtIFBORkUtIE9ORkUtIEVPQ05G
RS0gUk5GRS0gQ1JDTkZFLSBTRVJSTkZFLQ0KCQlQcmVmZXRjaGFibGUgbWVtb3J5IGJlaGlu
ZCBicmlkZ2UgVXBwZXI6IDAwLTAwDQoJCUJ1cyBOdW1iZXI6IDAwDQoJQ2FwYWJpbGl0aWVz
OiBbNDBdIEh5cGVyVHJhbnNwb3J0OiBSZXRyeSBNb2RlDQoJQ2FwYWJpbGl0aWVzOiBbNTRd
IEh5cGVyVHJhbnNwb3J0OiBVbml0SUQgQ2x1bXBpbmcNCglDYXBhYmlsaXRpZXM6IFs5Y10g
SHlwZXJUcmFuc3BvcnQ6ICMxYQ0KCUNhcGFiaWxpdGllczogWzcwXSBNU0k6IEVuYWJsZS0g
Q291bnQ9MS80IE1hc2thYmxlLSA2NGJpdC0NCgkJQWRkcmVzczogMDAwMDAwMDAgIERhdGE6
IDAwMDANCg0KMDA6MDAuMiBHZW5lcmljIHN5c3RlbSBwZXJpcGhlcmFsIFswODA2XTogQVRJ
IFRlY2hub2xvZ2llcyBJbmMgUkQ5OTAgSS9PIE1lbW9yeSBNYW5hZ2VtZW50IFVuaXQgKElP
TU1VKSBbMTAwMjo1YTIzXQ0KCVN1YnN5c3RlbTogQVRJIFRlY2hub2xvZ2llcyBJbmMgUkQ5
OTAgSS9PIE1lbW9yeSBNYW5hZ2VtZW50IFVuaXQgKElPTU1VKSBbMTAwMjo1YTIzXQ0KCUNv
bnRyb2w6IEkvTy0gTWVtLSBCdXNNYXN0ZXIrIFNwZWNDeWNsZS0gTWVtV0lOVi0gVkdBU25v
b3AtIFBhckVyci0gU3RlcHBpbmctIFNFUlItIEZhc3RCMkItIERpc0lOVHgtDQoJU3RhdHVz
OiBDYXArIDY2TUh6LSBVREYtIEZhc3RCMkItIFBhckVyci0gREVWU0VMPWZhc3QgPlRBYm9y
dC0gPFRBYm9ydC0gPE1BYm9ydC0gPlNFUlItIDxQRVJSLSBJTlR4LQ0KCUxhdGVuY3k6IDAN
CglJbnRlcnJ1cHQ6IHBpbiBBIHJvdXRlZCB0byBJUlEgMTANCglDYXBhYmlsaXRpZXM6IFs0
MF0gU2VjdXJlIGRldmljZSA8Pz4NCglDYXBhYmlsaXRpZXM6IFs1NF0gTVNJOiBFbmFibGUr
IENvdW50PTEvMSBNYXNrYWJsZS0gNjRiaXQrDQoJCUFkZHJlc3M6IDAwMDAwMDAwZmVlMDEw
MGMgIERhdGE6IDQxMjgNCglDYXBhYmlsaXRpZXM6IFs2NF0gSHlwZXJUcmFuc3BvcnQ6IE1T
SSBNYXBwaW5nIEVuYWJsZSsgRml4ZWQrDQoNCjAwOjAyLjAgUENJIGJyaWRnZSBbMDYwNF06
IEFUSSBUZWNobm9sb2dpZXMgSW5jIFJEODkwIFBDSSB0byBQQ0kgYnJpZGdlIChQQ0kgZXhw
cmVzcyBncHAgcG9ydCBCKSBbMTAwMjo1YTE2XSAocHJvZy1pZiAwMCBbTm9ybWFsIGRlY29k
ZV0pDQoJQ29udHJvbDogSS9PKyBNZW0rIEJ1c01hc3RlcisgU3BlY0N5Y2xlLSBNZW1XSU5W
LSBWR0FTbm9vcC0gUGFyRXJyLSBTdGVwcGluZy0gU0VSUisgRmFzdEIyQi0gRGlzSU5UeCsN
CglTdGF0dXM6IENhcCsgNjZNSHotIFVERi0gRmFzdEIyQi0gUGFyRXJyLSBERVZTRUw9ZmFz
dCA+VEFib3J0LSA8VEFib3J0LSA8TUFib3J0LSA+U0VSUi0gPFBFUlItIElOVHgtDQoJTGF0
ZW5jeTogMCwgQ2FjaGUgTGluZSBTaXplOiA2NCBieXRlcw0KCUJ1czogcHJpbWFyeT0wMCwg
c2Vjb25kYXJ5PTBiLCBzdWJvcmRpbmF0ZT0wYiwgc2VjLWxhdGVuY3k9MA0KCUkvTyBiZWhp
bmQgYnJpZGdlOiAwMDAwZTAwMC0wMDAwZWZmZg0KCU1lbW9yeSBiZWhpbmQgYnJpZGdlOiBm
YTAwMDAwMC1mZTlmZmZmZg0KCVByZWZldGNoYWJsZSBtZW1vcnkgYmVoaW5kIGJyaWRnZTog
MDAwMDAwMDBkMDAwMDAwMC0wMDAwMDAwMGRmZmZmZmZmDQoJU2Vjb25kYXJ5IHN0YXR1czog
NjZNSHotIEZhc3RCMkItIFBhckVyci0gREVWU0VMPWZhc3QgPlRBYm9ydC0gPFRBYm9ydC0g
PE1BYm9ydC0gPFNFUlItIDxQRVJSLQ0KCUJyaWRnZUN0bDogUGFyaXR5KyBTRVJSKyBOb0lT
QS0gVkdBKyBNQWJvcnQtID5SZXNldC0gRmFzdEIyQi0NCgkJUHJpRGlzY1Rtci0gU2VjRGlz
Y1Rtci0gRGlzY1RtclN0YXQtIERpc2NUbXJTRVJSRW4tDQoJQ2FwYWJpbGl0aWVzOiBbNTBd
IFBvd2VyIE1hbmFnZW1lbnQgdmVyc2lvbiAzDQoJCUZsYWdzOiBQTUVDbGstIERTSS0gRDEt
IEQyLSBBdXhDdXJyZW50PTBtQSBQTUUoRDArLEQxLSxEMi0sRDNob3QrLEQzY29sZCspDQoJ
CVN0YXR1czogRDAgTm9Tb2Z0UnN0LSBQTUUtRW5hYmxlLSBEU2VsPTAgRFNjYWxlPTAgUE1F
LQ0KCUNhcGFiaWxpdGllczogWzU4XSBFeHByZXNzICh2MikgUm9vdCBQb3J0IChTbG90Kyks
IE1TSSAwMA0KCQlEZXZDYXA6CU1heFBheWxvYWQgMTI4IGJ5dGVzLCBQaGFudEZ1bmMgMCwg
TGF0ZW5jeSBMMHMgPDY0bnMsIEwxIDwxdXMNCgkJCUV4dFRhZysgUkJFKyBGTFJlc2V0LQ0K
CQlEZXZDdGw6CVJlcG9ydCBlcnJvcnM6IENvcnJlY3RhYmxlLSBOb24tRmF0YWwtIEZhdGFs
LSBVbnN1cHBvcnRlZC0NCgkJCVJseGRPcmQrIEV4dFRhZy0gUGhhbnRGdW5jLSBBdXhQd3It
IE5vU25vb3ArDQoJCQlNYXhQYXlsb2FkIDEyOCBieXRlcywgTWF4UmVhZFJlcSAxMjggYnl0
ZXMNCgkJRGV2U3RhOglDb3JyRXJyLSBVbmNvcnJFcnItIEZhdGFsRXJyLSBVbnN1cHBSZXEt
IEF1eFB3ci0gVHJhbnNQZW5kLQ0KCQlMbmtDYXA6CVBvcnQgIzAsIFNwZWVkIDVHVC9zLCBX
aWR0aCB4OCwgQVNQTSBMMHMgTDEsIExhdGVuY3kgTDAgPDF1cywgTDEgPDh1cw0KCQkJQ2xv
Y2tQTS0gU3VycHJpc2UtIExMQWN0UmVwKyBCd05vdCsNCgkJTG5rQ3RsOglBU1BNIERpc2Fi
bGVkOyBSQ0IgNjQgYnl0ZXMgRGlzYWJsZWQtIFJldHJhaW4tIENvbW1DbGsrDQoJCQlFeHRT
eW5jaC0gQ2xvY2tQTS0gQXV0V2lkRGlzLSBCV0ludC0gQXV0QldJbnQtDQoJCUxua1N0YToJ
U3BlZWQgMi41R1QvcywgV2lkdGggeDgsIFRyRXJyLSBUcmFpbi0gU2xvdENsaysgRExBY3Rp
dmUrIEJXTWdtdCsgQUJXTWdtdC0NCgkJU2x0Q2FwOglBdHRuQnRuLSBQd3JDdHJsLSBNUkwt
IEF0dG5JbmQtIFB3ckluZC0gSG90UGx1Zy0gU3VycHJpc2UtDQoJCQlTbG90ICMxLCBQb3dl
ckxpbWl0IDI1LjAwMFc7IEludGVybG9jay0gTm9Db21wbCsNCgkJU2x0Q3RsOglFbmFibGU6
IEF0dG5CdG4tIFB3ckZsdC0gTVJMLSBQcmVzRGV0LSBDbWRDcGx0LSBIUElycS0gTGlua0No
Zy0NCgkJCUNvbnRyb2w6IEF0dG5JbmQgVW5rbm93biwgUHdySW5kIFVua25vd24sIFBvd2Vy
LSBJbnRlcmxvY2stDQoJCVNsdFN0YToJU3RhdHVzOiBBdHRuQnRuLSBQb3dlckZsdC0gTVJM
LSBDbWRDcGx0LSBQcmVzRGV0KyBJbnRlcmxvY2stDQoJCQlDaGFuZ2VkOiBNUkwtIFByZXNE
ZXQrIExpbmtTdGF0ZSsNCgkJUm9vdEN0bDogRXJyQ29ycmVjdGFibGUtIEVyck5vbi1GYXRh
bC0gRXJyRmF0YWwtIFBNRUludEVuYS0gQ1JTVmlzaWJsZS0NCgkJUm9vdENhcDogQ1JTVmlz
aWJsZS0NCgkJUm9vdFN0YTogUE1FIFJlcUlEIDAwMDAsIFBNRVN0YXR1cy0gUE1FUGVuZGlu
Zy0NCgkJRGV2Q2FwMjogQ29tcGxldGlvbiBUaW1lb3V0OiBSYW5nZSBBQkNELCBUaW1lb3V0
RGlzKyBBUklGd2QrDQoJCURldkN0bDI6IENvbXBsZXRpb24gVGltZW91dDogNjVtcyB0byAy
MTBtcywgVGltZW91dERpcy0gQVJJRndkLQ0KCQlMbmtDdGwyOiBUYXJnZXQgTGluayBTcGVl
ZDogNUdUL3MsIEVudGVyQ29tcGxpYW5jZS0gU3BlZWREaXMtLCBTZWxlY3RhYmxlIERlLWVt
cGhhc2lzOiAtMy41ZEINCgkJCSBUcmFuc21pdCBNYXJnaW46IE5vcm1hbCBPcGVyYXRpbmcg
UmFuZ2UsIEVudGVyTW9kaWZpZWRDb21wbGlhbmNlLSBDb21wbGlhbmNlU09TLQ0KCQkJIENv
bXBsaWFuY2UgRGUtZW1waGFzaXM6IC02ZEINCgkJTG5rU3RhMjogQ3VycmVudCBEZS1lbXBo
YXNpcyBMZXZlbDogLTMuNWRCDQoJQ2FwYWJpbGl0aWVzOiBbYTBdIE1TSTogRW5hYmxlKyBD
b3VudD0xLzEgTWFza2FibGUtIDY0Yml0LQ0KCQlBZGRyZXNzOiBmZWUzZjAwYyAgRGF0YTog
NDE1MQ0KCUNhcGFiaWxpdGllczogW2IwXSBTdWJzeXN0ZW06IEFUSSBUZWNobm9sb2dpZXMg
SW5jIERldmljZSBbMTAwMjo1YTExXQ0KCUNhcGFiaWxpdGllczogW2I4XSBIeXBlclRyYW5z
cG9ydDogTVNJIE1hcHBpbmcgRW5hYmxlKyBGaXhlZCsNCglDYXBhYmlsaXRpZXM6IFsxMDAg
djFdIFZlbmRvciBTcGVjaWZpYyBJbmZvcm1hdGlvbjogSUQ9MDAwMSBSZXY9MSBMZW49MDEw
IDw/Pg0KCUNhcGFiaWxpdGllczogWzE5MCB2MV0gQWNjZXNzIENvbnRyb2wgU2VydmljZXMN
CgkJQUNTQ2FwOglTcmNWYWxpZCsgVHJhbnNCbGsrIFJlcVJlZGlyKyBDbXBsdFJlZGlyKyBV
cHN0cmVhbUZ3ZCsgRWdyZXNzQ3RybC0gRGlyZWN0VHJhbnMrDQoJCUFDU0N0bDoJU3JjVmFs
aWQrIFRyYW5zQmxrLSBSZXFSZWRpcisgQ21wbHRSZWRpcisgVXBzdHJlYW1Gd2QrIEVncmVz
c0N0cmwtIERpcmVjdFRyYW5zLQ0KCUtlcm5lbCBkcml2ZXIgaW4gdXNlOiBwY2llcG9ydA0K
DQowMDowMy4wIFBDSSBicmlkZ2UgWzA2MDRdOiBBVEkgVGVjaG5vbG9naWVzIEluYyBSRDg5
MCBQQ0kgdG8gUENJIGJyaWRnZSAoUENJIGV4cHJlc3MgZ3BwIHBvcnQgQykgWzEwMDI6NWEx
N10gKHByb2ctaWYgMDAgW05vcm1hbCBkZWNvZGVdKQ0KCUNvbnRyb2w6IEkvTy0gTWVtKyBC
dXNNYXN0ZXIrIFNwZWNDeWNsZS0gTWVtV0lOVi0gVkdBU25vb3AtIFBhckVyci0gU3RlcHBp
bmctIFNFUlIrIEZhc3RCMkItIERpc0lOVHgrDQoJU3RhdHVzOiBDYXArIDY2TUh6LSBVREYt
IEZhc3RCMkItIFBhckVyci0gREVWU0VMPWZhc3QgPlRBYm9ydC0gPFRBYm9ydCsgPE1BYm9y
dC0gPlNFUlItIDxQRVJSLSBJTlR4LQ0KCUxhdGVuY3k6IDAsIENhY2hlIExpbmUgU2l6ZTog
NjQgYnl0ZXMNCglCdXM6IHByaW1hcnk9MDAsIHNlY29uZGFyeT0wYSwgc3Vib3JkaW5hdGU9
MGEsIHNlYy1sYXRlbmN5PTANCglJL08gYmVoaW5kIGJyaWRnZTogMDAwMGYwMDAtMDAwMDBm
ZmYNCglNZW1vcnkgYmVoaW5kIGJyaWRnZTogZjlmMDAwMDAtZjlmZmZmZmYNCglQcmVmZXRj
aGFibGUgbWVtb3J5IGJlaGluZCBicmlkZ2U6IDAwMDAwMDAwZmZmMDAwMDAtMDAwMDAwMDAw
MDBmZmZmZg0KCVNlY29uZGFyeSBzdGF0dXM6IDY2TUh6LSBGYXN0QjJCLSBQYXJFcnItIERF
VlNFTD1mYXN0ID5UQWJvcnQrIDxUQWJvcnQtIDxNQWJvcnQtIDxTRVJSLSA8UEVSUi0NCglC
cmlkZ2VDdGw6IFBhcml0eSsgU0VSUisgTm9JU0ErIFZHQS0gTUFib3J0LSA+UmVzZXQtIEZh
c3RCMkItDQoJCVByaURpc2NUbXItIFNlY0Rpc2NUbXItIERpc2NUbXJTdGF0LSBEaXNjVG1y
U0VSUkVuLQ0KCUNhcGFiaWxpdGllczogWzUwXSBQb3dlciBNYW5hZ2VtZW50IHZlcnNpb24g
Mw0KCQlGbGFnczogUE1FQ2xrLSBEU0ktIEQxLSBEMi0gQXV4Q3VycmVudD0wbUEgUE1FKEQw
KyxEMS0sRDItLEQzaG90KyxEM2NvbGQrKQ0KCQlTdGF0dXM6IEQwIE5vU29mdFJzdC0gUE1F
LUVuYWJsZS0gRFNlbD0wIERTY2FsZT0wIFBNRS0NCglDYXBhYmlsaXRpZXM6IFs1OF0gRXhw
cmVzcyAodjIpIFJvb3QgUG9ydCAoU2xvdCspLCBNU0kgMDANCgkJRGV2Q2FwOglNYXhQYXls
b2FkIDEyOCBieXRlcywgUGhhbnRGdW5jIDAsIExhdGVuY3kgTDBzIDw2NG5zLCBMMSA8MXVz
DQoJCQlFeHRUYWcrIFJCRSsgRkxSZXNldC0NCgkJRGV2Q3RsOglSZXBvcnQgZXJyb3JzOiBD
b3JyZWN0YWJsZS0gTm9uLUZhdGFsLSBGYXRhbC0gVW5zdXBwb3J0ZWQtDQoJCQlSbHhkT3Jk
KyBFeHRUYWctIFBoYW50RnVuYy0gQXV4UHdyLSBOb1Nub29wKw0KCQkJTWF4UGF5bG9hZCAx
MjggYnl0ZXMsIE1heFJlYWRSZXEgMTI4IGJ5dGVzDQoJCURldlN0YToJQ29yckVyci0gVW5j
b3JyRXJyLSBGYXRhbEVyci0gVW5zdXBwUmVxLSBBdXhQd3ItIFRyYW5zUGVuZC0NCgkJTG5r
Q2FwOglQb3J0ICMxLCBTcGVlZCA1R1QvcywgV2lkdGggeDgsIEFTUE0gTDBzIEwxLCBMYXRl
bmN5IEwwIDwxdXMsIEwxIDw4dXMNCgkJCUNsb2NrUE0tIFN1cnByaXNlLSBMTEFjdFJlcCsg
QndOb3QrDQoJCUxua0N0bDoJQVNQTSBEaXNhYmxlZDsgUkNCIDY0IGJ5dGVzIERpc2FibGVk
LSBSZXRyYWluLSBDb21tQ2xrLQ0KCQkJRXh0U3luY2gtIENsb2NrUE0tIEF1dFdpZERpcy0g
QldJbnQtIEF1dEJXSW50LQ0KCQlMbmtTdGE6CVNwZWVkIDIuNUdUL3MsIFdpZHRoIHgxLCBU
ckVyci0gVHJhaW4tIFNsb3RDbGsrIERMQWN0aXZlKyBCV01nbXQrIEFCV01nbXQtDQoJCVNs
dENhcDoJQXR0bkJ0bi0gUHdyQ3RybC0gTVJMLSBBdHRuSW5kLSBQd3JJbmQtIEhvdFBsdWct
IFN1cnByaXNlLQ0KCQkJU2xvdCAjMywgUG93ZXJMaW1pdCAxMC4wMDBXOyBJbnRlcmxvY2st
IE5vQ29tcGwrDQoJCVNsdEN0bDoJRW5hYmxlOiBBdHRuQnRuLSBQd3JGbHQtIE1STC0gUHJl
c0RldC0gQ21kQ3BsdC0gSFBJcnEtIExpbmtDaGctDQoJCQlDb250cm9sOiBBdHRuSW5kIFVu
a25vd24sIFB3ckluZCBVbmtub3duLCBQb3dlci0gSW50ZXJsb2NrLQ0KCQlTbHRTdGE6CVN0
YXR1czogQXR0bkJ0bi0gUG93ZXJGbHQtIE1STC0gQ21kQ3BsdC0gUHJlc0RldCsgSW50ZXJs
b2NrLQ0KCQkJQ2hhbmdlZDogTVJMLSBQcmVzRGV0KyBMaW5rU3RhdGUrDQoJCVJvb3RDdGw6
IEVyckNvcnJlY3RhYmxlLSBFcnJOb24tRmF0YWwtIEVyckZhdGFsLSBQTUVJbnRFbmEtIENS
U1Zpc2libGUtDQoJCVJvb3RDYXA6IENSU1Zpc2libGUtDQoJCVJvb3RTdGE6IFBNRSBSZXFJ
RCAwMDAwLCBQTUVTdGF0dXMtIFBNRVBlbmRpbmctDQoJCURldkNhcDI6IENvbXBsZXRpb24g
VGltZW91dDogUmFuZ2UgQUJDRCwgVGltZW91dERpcysgQVJJRndkKw0KCQlEZXZDdGwyOiBD
b21wbGV0aW9uIFRpbWVvdXQ6IDY1bXMgdG8gMjEwbXMsIFRpbWVvdXREaXMtIEFSSUZ3ZC0N
CgkJTG5rQ3RsMjogVGFyZ2V0IExpbmsgU3BlZWQ6IDVHVC9zLCBFbnRlckNvbXBsaWFuY2Ut
IFNwZWVkRGlzLSwgU2VsZWN0YWJsZSBEZS1lbXBoYXNpczogLTMuNWRCDQoJCQkgVHJhbnNt
aXQgTWFyZ2luOiBOb3JtYWwgT3BlcmF0aW5nIFJhbmdlLCBFbnRlck1vZGlmaWVkQ29tcGxp
YW5jZS0gQ29tcGxpYW5jZVNPUy0NCgkJCSBDb21wbGlhbmNlIERlLWVtcGhhc2lzOiAtNmRC
DQoJCUxua1N0YTI6IEN1cnJlbnQgRGUtZW1waGFzaXMgTGV2ZWw6IC0zLjVkQg0KCUNhcGFi
aWxpdGllczogW2EwXSBNU0k6IEVuYWJsZSsgQ291bnQ9MS8xIE1hc2thYmxlLSA2NGJpdC0N
CgkJQWRkcmVzczogZmVlM2YwMGMgIERhdGE6IDQxNTkNCglDYXBhYmlsaXRpZXM6IFtiMF0g
U3Vic3lzdGVtOiBBVEkgVGVjaG5vbG9naWVzIEluYyBEZXZpY2UgWzEwMDI6NWExMV0NCglD
YXBhYmlsaXRpZXM6IFtiOF0gSHlwZXJUcmFuc3BvcnQ6IE1TSSBNYXBwaW5nIEVuYWJsZSsg
Rml4ZWQrDQoJQ2FwYWJpbGl0aWVzOiBbMTAwIHYxXSBWZW5kb3IgU3BlY2lmaWMgSW5mb3Jt
YXRpb246IElEPTAwMDEgUmV2PTEgTGVuPTAxMCA8Pz4NCglDYXBhYmlsaXRpZXM6IFsxOTAg
djFdIEFjY2VzcyBDb250cm9sIFNlcnZpY2VzDQoJCUFDU0NhcDoJU3JjVmFsaWQrIFRyYW5z
QmxrKyBSZXFSZWRpcisgQ21wbHRSZWRpcisgVXBzdHJlYW1Gd2QrIEVncmVzc0N0cmwtIERp
cmVjdFRyYW5zKw0KCQlBQ1NDdGw6CVNyY1ZhbGlkKyBUcmFuc0Jsay0gUmVxUmVkaXIrIENt
cGx0UmVkaXIrIFVwc3RyZWFtRndkKyBFZ3Jlc3NDdHJsLSBEaXJlY3RUcmFucy0NCglLZXJu
ZWwgZHJpdmVyIGluIHVzZTogcGNpZXBvcnQNCg0KMDA6MDUuMCBQQ0kgYnJpZGdlIFswNjA0
XTogQVRJIFRlY2hub2xvZ2llcyBJbmMgUkQ4OTAgUENJIHRvIFBDSSBicmlkZ2UgKFBDSSBl
eHByZXNzIGdwcCBwb3J0IEUpIFsxMDAyOjVhMTldIChwcm9nLWlmIDAwIFtOb3JtYWwgZGVj
b2RlXSkNCglDb250cm9sOiBJL08rIE1lbSsgQnVzTWFzdGVyKyBTcGVjQ3ljbGUtIE1lbVdJ
TlYtIFZHQVNub29wLSBQYXJFcnItIFN0ZXBwaW5nLSBTRVJSKyBGYXN0QjJCLSBEaXNJTlR4
Kw0KCVN0YXR1czogQ2FwKyA2Nk1Iei0gVURGLSBGYXN0QjJCLSBQYXJFcnItIERFVlNFTD1m
YXN0ID5UQWJvcnQtIDxUQWJvcnQtIDxNQWJvcnQtID5TRVJSLSA8UEVSUi0gSU5UeC0NCglM
YXRlbmN5OiAwLCBDYWNoZSBMaW5lIFNpemU6IDY0IGJ5dGVzDQoJQnVzOiBwcmltYXJ5PTAw
LCBzZWNvbmRhcnk9MDksIHN1Ym9yZGluYXRlPTA5LCBzZWMtbGF0ZW5jeT0wDQoJSS9PIGJl
aGluZCBicmlkZ2U6IDAwMDBkMDAwLTAwMDBkZmZmDQoJTWVtb3J5IGJlaGluZCBicmlkZ2U6
IGY5ZTAwMDAwLWY5ZWZmZmZmDQoJUHJlZmV0Y2hhYmxlIG1lbW9yeSBiZWhpbmQgYnJpZGdl
OiAwMDAwMDAwMGNmZjAwMDAwLTAwMDAwMDAwY2ZmZmZmZmYNCglTZWNvbmRhcnkgc3RhdHVz
OiA2Nk1Iei0gRmFzdEIyQi0gUGFyRXJyLSBERVZTRUw9ZmFzdCA+VEFib3J0LSA8VEFib3J0
LSA8TUFib3J0LSA8U0VSUi0gPFBFUlItDQoJQnJpZGdlQ3RsOiBQYXJpdHkrIFNFUlIrIE5v
SVNBKyBWR0EtIE1BYm9ydC0gPlJlc2V0LSBGYXN0QjJCLQ0KCQlQcmlEaXNjVG1yLSBTZWNE
aXNjVG1yLSBEaXNjVG1yU3RhdC0gRGlzY1RtclNFUlJFbi0NCglDYXBhYmlsaXRpZXM6IFs1
MF0gUG93ZXIgTWFuYWdlbWVudCB2ZXJzaW9uIDMNCgkJRmxhZ3M6IFBNRUNsay0gRFNJLSBE
MS0gRDItIEF1eEN1cnJlbnQ9MG1BIFBNRShEMCssRDEtLEQyLSxEM2hvdCssRDNjb2xkKykN
CgkJU3RhdHVzOiBEMCBOb1NvZnRSc3QtIFBNRS1FbmFibGUtIERTZWw9MCBEU2NhbGU9MCBQ
TUUtDQoJQ2FwYWJpbGl0aWVzOiBbNThdIEV4cHJlc3MgKHYyKSBSb290IFBvcnQgKFNsb3Qr
KSwgTVNJIDAwDQoJCURldkNhcDoJTWF4UGF5bG9hZCAxMjggYnl0ZXMsIFBoYW50RnVuYyAw
LCBMYXRlbmN5IEwwcyA8NjRucywgTDEgPDF1cw0KCQkJRXh0VGFnKyBSQkUrIEZMUmVzZXQt
DQoJCURldkN0bDoJUmVwb3J0IGVycm9yczogQ29ycmVjdGFibGUtIE5vbi1GYXRhbC0gRmF0
YWwtIFVuc3VwcG9ydGVkLQ0KCQkJUmx4ZE9yZCsgRXh0VGFnLSBQaGFudEZ1bmMtIEF1eFB3
ci0gTm9Tbm9vcCsNCgkJCU1heFBheWxvYWQgMTI4IGJ5dGVzLCBNYXhSZWFkUmVxIDEyOCBi
eXRlcw0KCQlEZXZTdGE6CUNvcnJFcnItIFVuY29yckVyci0gRmF0YWxFcnItIFVuc3VwcFJl
cS0gQXV4UHdyLSBUcmFuc1BlbmQtDQoJCUxua0NhcDoJUG9ydCAjMSwgU3BlZWQgNUdUL3Ms
IFdpZHRoIHgxLCBBU1BNIEwwcyBMMSwgTGF0ZW5jeSBMMCA8MXVzLCBMMSA8OHVzDQoJCQlD
bG9ja1BNLSBTdXJwcmlzZS0gTExBY3RSZXArIEJ3Tm90Kw0KCQlMbmtDdGw6CUFTUE0gRGlz
YWJsZWQ7IFJDQiA2NCBieXRlcyBEaXNhYmxlZC0gUmV0cmFpbi0gQ29tbUNsaysNCgkJCUV4
dFN5bmNoLSBDbG9ja1BNLSBBdXRXaWREaXMtIEJXSW50LSBBdXRCV0ludC0NCgkJTG5rU3Rh
OglTcGVlZCAyLjVHVC9zLCBXaWR0aCB4MSwgVHJFcnItIFRyYWluLSBTbG90Q2xrKyBETEFj
dGl2ZSsgQldNZ210KyBBQldNZ210LQ0KCQlTbHRDYXA6CUF0dG5CdG4tIFB3ckN0cmwtIE1S
TC0gQXR0bkluZC0gUHdySW5kLSBIb3RQbHVnLSBTdXJwcmlzZS0NCgkJCVNsb3QgIzUsIFBv
d2VyTGltaXQgNzUuMDAwVzsgSW50ZXJsb2NrLSBOb0NvbXBsKw0KCQlTbHRDdGw6CUVuYWJs
ZTogQXR0bkJ0bi0gUHdyRmx0LSBNUkwtIFByZXNEZXQtIENtZENwbHQtIEhQSXJxLSBMaW5r
Q2hnLQ0KCQkJQ29udHJvbDogQXR0bkluZCBVbmtub3duLCBQd3JJbmQgVW5rbm93biwgUG93
ZXItIEludGVybG9jay0NCgkJU2x0U3RhOglTdGF0dXM6IEF0dG5CdG4tIFBvd2VyRmx0LSBN
UkwtIENtZENwbHQtIFByZXNEZXQrIEludGVybG9jay0NCgkJCUNoYW5nZWQ6IE1STC0gUHJl
c0RldCsgTGlua1N0YXRlKw0KCQlSb290Q3RsOiBFcnJDb3JyZWN0YWJsZS0gRXJyTm9uLUZh
dGFsLSBFcnJGYXRhbC0gUE1FSW50RW5hLSBDUlNWaXNpYmxlLQ0KCQlSb290Q2FwOiBDUlNW
aXNpYmxlLQ0KCQlSb290U3RhOiBQTUUgUmVxSUQgMDAwMCwgUE1FU3RhdHVzLSBQTUVQZW5k
aW5nLQ0KCQlEZXZDYXAyOiBDb21wbGV0aW9uIFRpbWVvdXQ6IFJhbmdlIEFCQ0QsIFRpbWVv
dXREaXMrIEFSSUZ3ZCsNCgkJRGV2Q3RsMjogQ29tcGxldGlvbiBUaW1lb3V0OiA2NW1zIHRv
IDIxMG1zLCBUaW1lb3V0RGlzLSBBUklGd2QtDQoJCUxua0N0bDI6IFRhcmdldCBMaW5rIFNw
ZWVkOiA1R1QvcywgRW50ZXJDb21wbGlhbmNlLSBTcGVlZERpcy0sIFNlbGVjdGFibGUgRGUt
ZW1waGFzaXM6IC0zLjVkQg0KCQkJIFRyYW5zbWl0IE1hcmdpbjogTm9ybWFsIE9wZXJhdGlu
ZyBSYW5nZSwgRW50ZXJNb2RpZmllZENvbXBsaWFuY2UtIENvbXBsaWFuY2VTT1MtDQoJCQkg
Q29tcGxpYW5jZSBEZS1lbXBoYXNpczogLTZkQg0KCQlMbmtTdGEyOiBDdXJyZW50IERlLWVt
cGhhc2lzIExldmVsOiAtMy41ZEINCglDYXBhYmlsaXRpZXM6IFthMF0gTVNJOiBFbmFibGUr
IENvdW50PTEvMSBNYXNrYWJsZS0gNjRiaXQtDQoJCUFkZHJlc3M6IGZlZTNmMDBjICBEYXRh
OiA0MTYxDQoJQ2FwYWJpbGl0aWVzOiBbYjBdIFN1YnN5c3RlbTogQVRJIFRlY2hub2xvZ2ll
cyBJbmMgRGV2aWNlIFsxMDAyOjVhMTFdDQoJQ2FwYWJpbGl0aWVzOiBbYjhdIEh5cGVyVHJh
bnNwb3J0OiBNU0kgTWFwcGluZyBFbmFibGUrIEZpeGVkKw0KCUNhcGFiaWxpdGllczogWzEw
MCB2MV0gVmVuZG9yIFNwZWNpZmljIEluZm9ybWF0aW9uOiBJRD0wMDAxIFJldj0xIExlbj0w
MTAgPD8+DQoJQ2FwYWJpbGl0aWVzOiBbMTkwIHYxXSBBY2Nlc3MgQ29udHJvbCBTZXJ2aWNl
cw0KCQlBQ1NDYXA6CVNyY1ZhbGlkKyBUcmFuc0JsaysgUmVxUmVkaXIrIENtcGx0UmVkaXIr
IFVwc3RyZWFtRndkKyBFZ3Jlc3NDdHJsLSBEaXJlY3RUcmFucysNCgkJQUNTQ3RsOglTcmNW
YWxpZCsgVHJhbnNCbGstIFJlcVJlZGlyKyBDbXBsdFJlZGlyKyBVcHN0cmVhbUZ3ZCsgRWdy
ZXNzQ3RybC0gRGlyZWN0VHJhbnMtDQoJS2VybmVsIGRyaXZlciBpbiB1c2U6IHBjaWVwb3J0
DQoNCjAwOjA2LjAgUENJIGJyaWRnZSBbMDYwNF06IEFUSSBUZWNobm9sb2dpZXMgSW5jIFJE
ODkwIFBDSSB0byBQQ0kgYnJpZGdlIChQQ0kgZXhwcmVzcyBncHAgcG9ydCBGKSBbMTAwMjo1
YTFhXSAocHJvZy1pZiAwMCBbTm9ybWFsIGRlY29kZV0pDQoJQ29udHJvbDogSS9PKyBNZW0r
IEJ1c01hc3RlcisgU3BlY0N5Y2xlLSBNZW1XSU5WLSBWR0FTbm9vcC0gUGFyRXJyLSBTdGVw
cGluZy0gU0VSUisgRmFzdEIyQi0gRGlzSU5UeCsNCglTdGF0dXM6IENhcCsgNjZNSHotIFVE
Ri0gRmFzdEIyQi0gUGFyRXJyLSBERVZTRUw9ZmFzdCA+VEFib3J0LSA8VEFib3J0LSA8TUFi
b3J0LSA+U0VSUi0gPFBFUlItIElOVHgtDQoJTGF0ZW5jeTogMCwgQ2FjaGUgTGluZSBTaXpl
OiA2NCBieXRlcw0KCUJ1czogcHJpbWFyeT0wMCwgc2Vjb25kYXJ5PTA4LCBzdWJvcmRpbmF0
ZT0wOCwgc2VjLWxhdGVuY3k9MA0KCUkvTyBiZWhpbmQgYnJpZGdlOiAwMDAwYzAwMC0wMDAw
Y2ZmZg0KCU1lbW9yeSBiZWhpbmQgYnJpZGdlOiBmOWQwMDAwMC1mOWRmZmZmZg0KCVByZWZl
dGNoYWJsZSBtZW1vcnkgYmVoaW5kIGJyaWRnZTogMDAwMDAwMDBjZmUwMDAwMC0wMDAwMDAw
MGNmZWZmZmZmDQoJU2Vjb25kYXJ5IHN0YXR1czogNjZNSHotIEZhc3RCMkItIFBhckVyci0g
REVWU0VMPWZhc3QgPlRBYm9ydC0gPFRBYm9ydC0gPE1BYm9ydC0gPFNFUlItIDxQRVJSLQ0K
CUJyaWRnZUN0bDogUGFyaXR5KyBTRVJSKyBOb0lTQSsgVkdBLSBNQWJvcnQtID5SZXNldC0g
RmFzdEIyQi0NCgkJUHJpRGlzY1Rtci0gU2VjRGlzY1Rtci0gRGlzY1RtclN0YXQtIERpc2NU
bXJTRVJSRW4tDQoJQ2FwYWJpbGl0aWVzOiBbNTBdIFBvd2VyIE1hbmFnZW1lbnQgdmVyc2lv
biAzDQoJCUZsYWdzOiBQTUVDbGstIERTSS0gRDEtIEQyLSBBdXhDdXJyZW50PTBtQSBQTUUo
RDArLEQxLSxEMi0sRDNob3QrLEQzY29sZCspDQoJCVN0YXR1czogRDAgTm9Tb2Z0UnN0LSBQ
TUUtRW5hYmxlLSBEU2VsPTAgRFNjYWxlPTAgUE1FLQ0KCUNhcGFiaWxpdGllczogWzU4XSBF
eHByZXNzICh2MikgUm9vdCBQb3J0IChTbG90KyksIE1TSSAwMA0KCQlEZXZDYXA6CU1heFBh
eWxvYWQgMTI4IGJ5dGVzLCBQaGFudEZ1bmMgMCwgTGF0ZW5jeSBMMHMgPDY0bnMsIEwxIDwx
dXMNCgkJCUV4dFRhZysgUkJFKyBGTFJlc2V0LQ0KCQlEZXZDdGw6CVJlcG9ydCBlcnJvcnM6
IENvcnJlY3RhYmxlLSBOb24tRmF0YWwtIEZhdGFsLSBVbnN1cHBvcnRlZC0NCgkJCVJseGRP
cmQrIEV4dFRhZy0gUGhhbnRGdW5jLSBBdXhQd3ItIE5vU25vb3ArDQoJCQlNYXhQYXlsb2Fk
IDEyOCBieXRlcywgTWF4UmVhZFJlcSAxMjggYnl0ZXMNCgkJRGV2U3RhOglDb3JyRXJyLSBV
bmNvcnJFcnItIEZhdGFsRXJyLSBVbnN1cHBSZXEtIEF1eFB3ci0gVHJhbnNQZW5kLQ0KCQlM
bmtDYXA6CVBvcnQgIzIsIFNwZWVkIDVHVC9zLCBXaWR0aCB4MSwgQVNQTSBMMHMgTDEsIExh
dGVuY3kgTDAgPDF1cywgTDEgPDh1cw0KCQkJQ2xvY2tQTS0gU3VycHJpc2UtIExMQWN0UmVw
KyBCd05vdCsNCgkJTG5rQ3RsOglBU1BNIERpc2FibGVkOyBSQ0IgNjQgYnl0ZXMgRGlzYWJs
ZWQtIFJldHJhaW4tIENvbW1DbGsrDQoJCQlFeHRTeW5jaC0gQ2xvY2tQTS0gQXV0V2lkRGlz
LSBCV0ludC0gQXV0QldJbnQtDQoJCUxua1N0YToJU3BlZWQgMi41R1QvcywgV2lkdGggeDEs
IFRyRXJyLSBUcmFpbi0gU2xvdENsaysgRExBY3RpdmUrIEJXTWdtdCsgQUJXTWdtdC0NCgkJ
U2x0Q2FwOglBdHRuQnRuLSBQd3JDdHJsLSBNUkwtIEF0dG5JbmQtIFB3ckluZC0gSG90UGx1
Zy0gU3VycHJpc2UtDQoJCQlTbG90ICM2LCBQb3dlckxpbWl0IDc1LjAwMFc7IEludGVybG9j
ay0gTm9Db21wbCsNCgkJU2x0Q3RsOglFbmFibGU6IEF0dG5CdG4tIFB3ckZsdC0gTVJMLSBQ
cmVzRGV0LSBDbWRDcGx0LSBIUElycS0gTGlua0NoZy0NCgkJCUNvbnRyb2w6IEF0dG5JbmQg
VW5rbm93biwgUHdySW5kIFVua25vd24sIFBvd2VyLSBJbnRlcmxvY2stDQoJCVNsdFN0YToJ
U3RhdHVzOiBBdHRuQnRuLSBQb3dlckZsdC0gTVJMLSBDbWRDcGx0LSBQcmVzRGV0KyBJbnRl
cmxvY2stDQoJCQlDaGFuZ2VkOiBNUkwtIFByZXNEZXQrIExpbmtTdGF0ZSsNCgkJUm9vdEN0
bDogRXJyQ29ycmVjdGFibGUtIEVyck5vbi1GYXRhbC0gRXJyRmF0YWwtIFBNRUludEVuYS0g
Q1JTVmlzaWJsZS0NCgkJUm9vdENhcDogQ1JTVmlzaWJsZS0NCgkJUm9vdFN0YTogUE1FIFJl
cUlEIDAwMDAsIFBNRVN0YXR1cy0gUE1FUGVuZGluZy0NCgkJRGV2Q2FwMjogQ29tcGxldGlv
biBUaW1lb3V0OiBSYW5nZSBBQkNELCBUaW1lb3V0RGlzKyBBUklGd2QrDQoJCURldkN0bDI6
IENvbXBsZXRpb24gVGltZW91dDogNjVtcyB0byAyMTBtcywgVGltZW91dERpcy0gQVJJRndk
LQ0KCQlMbmtDdGwyOiBUYXJnZXQgTGluayBTcGVlZDogNUdUL3MsIEVudGVyQ29tcGxpYW5j
ZS0gU3BlZWREaXMtLCBTZWxlY3RhYmxlIERlLWVtcGhhc2lzOiAtMy41ZEINCgkJCSBUcmFu
c21pdCBNYXJnaW46IE5vcm1hbCBPcGVyYXRpbmcgUmFuZ2UsIEVudGVyTW9kaWZpZWRDb21w
bGlhbmNlLSBDb21wbGlhbmNlU09TLQ0KCQkJIENvbXBsaWFuY2UgRGUtZW1waGFzaXM6IC02
ZEINCgkJTG5rU3RhMjogQ3VycmVudCBEZS1lbXBoYXNpcyBMZXZlbDogLTMuNWRCDQoJQ2Fw
YWJpbGl0aWVzOiBbYTBdIE1TSTogRW5hYmxlKyBDb3VudD0xLzEgTWFza2FibGUtIDY0Yml0
LQ0KCQlBZGRyZXNzOiBmZWUzZjAwYyAgRGF0YTogNDE2OQ0KCUNhcGFiaWxpdGllczogW2Iw
XSBTdWJzeXN0ZW06IEFUSSBUZWNobm9sb2dpZXMgSW5jIERldmljZSBbMTAwMjo1YTExXQ0K
CUNhcGFiaWxpdGllczogW2I4XSBIeXBlclRyYW5zcG9ydDogTVNJIE1hcHBpbmcgRW5hYmxl
KyBGaXhlZCsNCglDYXBhYmlsaXRpZXM6IFsxMDAgdjFdIFZlbmRvciBTcGVjaWZpYyBJbmZv
cm1hdGlvbjogSUQ9MDAwMSBSZXY9MSBMZW49MDEwIDw/Pg0KCUNhcGFiaWxpdGllczogWzE5
MCB2MV0gQWNjZXNzIENvbnRyb2wgU2VydmljZXMNCgkJQUNTQ2FwOglTcmNWYWxpZCsgVHJh
bnNCbGsrIFJlcVJlZGlyKyBDbXBsdFJlZGlyKyBVcHN0cmVhbUZ3ZCsgRWdyZXNzQ3RybC0g
RGlyZWN0VHJhbnMrDQoJCUFDU0N0bDoJU3JjVmFsaWQrIFRyYW5zQmxrLSBSZXFSZWRpcisg
Q21wbHRSZWRpcisgVXBzdHJlYW1Gd2QrIEVncmVzc0N0cmwtIERpcmVjdFRyYW5zLQ0KCUtl
cm5lbCBkcml2ZXIgaW4gdXNlOiBwY2llcG9ydA0KDQowMDowYS4wIFBDSSBicmlkZ2UgWzA2
MDRdOiBBVEkgVGVjaG5vbG9naWVzIEluYyBSRDg5MCBQQ0kgdG8gUENJIGJyaWRnZSAoZXh0
ZXJuYWwgZ2Z4MSBwb3J0IEEpIFsxMDAyOjVhMWRdIChwcm9nLWlmIDAwIFtOb3JtYWwgZGVj
b2RlXSkNCglDb250cm9sOiBJL08tIE1lbSsgQnVzTWFzdGVyKyBTcGVjQ3ljbGUtIE1lbVdJ
TlYtIFZHQVNub29wLSBQYXJFcnItIFN0ZXBwaW5nLSBTRVJSKyBGYXN0QjJCLSBEaXNJTlR4
Kw0KCVN0YXR1czogQ2FwKyA2Nk1Iei0gVURGLSBGYXN0QjJCLSBQYXJFcnItIERFVlNFTD1m
YXN0ID5UQWJvcnQtIDxUQWJvcnQtIDxNQWJvcnQtID5TRVJSLSA8UEVSUi0gSU5UeC0NCglM
YXRlbmN5OiAwLCBDYWNoZSBMaW5lIFNpemU6IDY0IGJ5dGVzDQoJQnVzOiBwcmltYXJ5PTAw
LCBzZWNvbmRhcnk9MDcsIHN1Ym9yZGluYXRlPTA3LCBzZWMtbGF0ZW5jeT0wDQoJSS9PIGJl
aGluZCBicmlkZ2U6IDAwMDBmMDAwLTAwMDAwZmZmDQoJTWVtb3J5IGJlaGluZCBicmlkZ2U6
IGY5YTAwMDAwLWY5YmZmZmZmDQoJUHJlZmV0Y2hhYmxlIG1lbW9yeSBiZWhpbmQgYnJpZGdl
OiAwMDAwMDAwMGZmZjAwMDAwLTAwMDAwMDAwMDAwZmZmZmYNCglTZWNvbmRhcnkgc3RhdHVz
OiA2Nk1Iei0gRmFzdEIyQi0gUGFyRXJyLSBERVZTRUw9ZmFzdCA+VEFib3J0LSA8VEFib3J0
LSA8TUFib3J0KyA8U0VSUi0gPFBFUlItDQoJQnJpZGdlQ3RsOiBQYXJpdHkrIFNFUlIrIE5v
SVNBKyBWR0EtIE1BYm9ydC0gPlJlc2V0LSBGYXN0QjJCLQ0KCQlQcmlEaXNjVG1yLSBTZWNE
aXNjVG1yLSBEaXNjVG1yU3RhdC0gRGlzY1RtclNFUlJFbi0NCglDYXBhYmlsaXRpZXM6IFs1
MF0gUG93ZXIgTWFuYWdlbWVudCB2ZXJzaW9uIDMNCgkJRmxhZ3M6IFBNRUNsay0gRFNJLSBE
MS0gRDItIEF1eEN1cnJlbnQ9MG1BIFBNRShEMCssRDEtLEQyLSxEM2hvdCssRDNjb2xkKykN
CgkJU3RhdHVzOiBEMCBOb1NvZnRSc3QtIFBNRS1FbmFibGUtIERTZWw9MCBEU2NhbGU9MCBQ
TUUtDQoJQ2FwYWJpbGl0aWVzOiBbNThdIEV4cHJlc3MgKHYyKSBSb290IFBvcnQgKFNsb3Qr
KSwgTVNJIDAwDQoJCURldkNhcDoJTWF4UGF5bG9hZCAxMjggYnl0ZXMsIFBoYW50RnVuYyAw
LCBMYXRlbmN5IEwwcyA8NjRucywgTDEgPDF1cw0KCQkJRXh0VGFnKyBSQkUrIEZMUmVzZXQt
DQoJCURldkN0bDoJUmVwb3J0IGVycm9yczogQ29ycmVjdGFibGUtIE5vbi1GYXRhbC0gRmF0
YWwtIFVuc3VwcG9ydGVkLQ0KCQkJUmx4ZE9yZCsgRXh0VGFnLSBQaGFudEZ1bmMtIEF1eFB3
ci0gTm9Tbm9vcCsNCgkJCU1heFBheWxvYWQgMTI4IGJ5dGVzLCBNYXhSZWFkUmVxIDEyOCBi
eXRlcw0KCQlEZXZTdGE6CUNvcnJFcnItIFVuY29yckVyci0gRmF0YWxFcnItIFVuc3VwcFJl
cS0gQXV4UHdyLSBUcmFuc1BlbmQtDQoJCUxua0NhcDoJUG9ydCAjNSwgU3BlZWQgMi41R1Qv
cywgV2lkdGggeDEsIEFTUE0gTDBzIEwxLCBMYXRlbmN5IEwwIDwxdXMsIEwxIDw4dXMNCgkJ
CUNsb2NrUE0tIFN1cnByaXNlLSBMTEFjdFJlcCsgQndOb3QrDQoJCUxua0N0bDoJQVNQTSBE
aXNhYmxlZDsgUkNCIDY0IGJ5dGVzIERpc2FibGVkLSBSZXRyYWluLSBDb21tQ2xrLQ0KCQkJ
RXh0U3luY2gtIENsb2NrUE0tIEF1dFdpZERpcy0gQldJbnQtIEF1dEJXSW50LQ0KCQlMbmtT
dGE6CVNwZWVkIDIuNUdUL3MsIFdpZHRoIHgxLCBUckVyci0gVHJhaW4tIFNsb3RDbGsrIERM
QWN0aXZlKyBCV01nbXQrIEFCV01nbXQtDQoJCVNsdENhcDoJQXR0bkJ0bi0gUHdyQ3RybC0g
TVJMLSBBdHRuSW5kLSBQd3JJbmQtIEhvdFBsdWctIFN1cnByaXNlLQ0KCQkJU2xvdCAjMiwg
UG93ZXJMaW1pdCA3NS4wMDBXOyBJbnRlcmxvY2stIE5vQ29tcGwrDQoJCVNsdEN0bDoJRW5h
YmxlOiBBdHRuQnRuLSBQd3JGbHQtIE1STC0gUHJlc0RldC0gQ21kQ3BsdC0gSFBJcnEtIExp
bmtDaGctDQoJCQlDb250cm9sOiBBdHRuSW5kIFVua25vd24sIFB3ckluZCBVbmtub3duLCBQ
b3dlci0gSW50ZXJsb2NrLQ0KCQlTbHRTdGE6CVN0YXR1czogQXR0bkJ0bi0gUG93ZXJGbHQt
IE1STC0gQ21kQ3BsdC0gUHJlc0RldCsgSW50ZXJsb2NrLQ0KCQkJQ2hhbmdlZDogTVJMLSBQ
cmVzRGV0KyBMaW5rU3RhdGUrDQoJCVJvb3RDdGw6IEVyckNvcnJlY3RhYmxlLSBFcnJOb24t
RmF0YWwtIEVyckZhdGFsLSBQTUVJbnRFbmEtIENSU1Zpc2libGUtDQoJCVJvb3RDYXA6IENS
U1Zpc2libGUtDQoJCVJvb3RTdGE6IFBNRSBSZXFJRCAwMDAwLCBQTUVTdGF0dXMtIFBNRVBl
bmRpbmctDQoJCURldkNhcDI6IENvbXBsZXRpb24gVGltZW91dDogUmFuZ2UgQUJDRCwgVGlt
ZW91dERpcysgQVJJRndkKw0KCQlEZXZDdGwyOiBDb21wbGV0aW9uIFRpbWVvdXQ6IDY1bXMg
dG8gMjEwbXMsIFRpbWVvdXREaXMtIEFSSUZ3ZC0NCgkJTG5rQ3RsMjogVGFyZ2V0IExpbmsg
U3BlZWQ6IDIuNUdUL3MsIEVudGVyQ29tcGxpYW5jZS0gU3BlZWREaXMtLCBTZWxlY3RhYmxl
IERlLWVtcGhhc2lzOiAtNmRCDQoJCQkgVHJhbnNtaXQgTWFyZ2luOiBOb3JtYWwgT3BlcmF0
aW5nIFJhbmdlLCBFbnRlck1vZGlmaWVkQ29tcGxpYW5jZS0gQ29tcGxpYW5jZVNPUy0NCgkJ
CSBDb21wbGlhbmNlIERlLWVtcGhhc2lzOiAtNmRCDQoJCUxua1N0YTI6IEN1cnJlbnQgRGUt
ZW1waGFzaXMgTGV2ZWw6IC02ZEINCglDYXBhYmlsaXRpZXM6IFthMF0gTVNJOiBFbmFibGUr
IENvdW50PTEvMSBNYXNrYWJsZS0gNjRiaXQtDQoJCUFkZHJlc3M6IGZlZTNmMDBjICBEYXRh
OiA0MTcxDQoJQ2FwYWJpbGl0aWVzOiBbYjBdIFN1YnN5c3RlbTogQVRJIFRlY2hub2xvZ2ll
cyBJbmMgRGV2aWNlIFsxMDAyOjVhMTFdDQoJQ2FwYWJpbGl0aWVzOiBbYjhdIEh5cGVyVHJh
bnNwb3J0OiBNU0kgTWFwcGluZyBFbmFibGUrIEZpeGVkKw0KCUNhcGFiaWxpdGllczogWzEw
MCB2MV0gVmVuZG9yIFNwZWNpZmljIEluZm9ybWF0aW9uOiBJRD0wMDAxIFJldj0xIExlbj0w
MTAgPD8+DQoJQ2FwYWJpbGl0aWVzOiBbMTkwIHYxXSBBY2Nlc3MgQ29udHJvbCBTZXJ2aWNl
cw0KCQlBQ1NDYXA6CVNyY1ZhbGlkKyBUcmFuc0JsaysgUmVxUmVkaXIrIENtcGx0UmVkaXIr
IFVwc3RyZWFtRndkKyBFZ3Jlc3NDdHJsLSBEaXJlY3RUcmFucysNCgkJQUNTQ3RsOglTcmNW
YWxpZCsgVHJhbnNCbGstIFJlcVJlZGlyKyBDbXBsdFJlZGlyKyBVcHN0cmVhbUZ3ZCsgRWdy
ZXNzQ3RybC0gRGlyZWN0VHJhbnMtDQoJS2VybmVsIGRyaXZlciBpbiB1c2U6IHBjaWVwb3J0
DQoNCjAwOjBiLjAgUENJIGJyaWRnZSBbMDYwNF06IEFUSSBUZWNobm9sb2dpZXMgSW5jIFJE
ODkwIFBDSSB0byBQQ0kgYnJpZGdlIChOQi1TQiBsaW5rKSBbMTAwMjo1YTFmXSAocHJvZy1p
ZiAwMCBbTm9ybWFsIGRlY29kZV0pDQoJQ29udHJvbDogSS9PKyBNZW0rIEJ1c01hc3Rlcisg
U3BlY0N5Y2xlLSBNZW1XSU5WLSBWR0FTbm9vcC0gUGFyRXJyLSBTdGVwcGluZy0gU0VSUisg
RmFzdEIyQi0gRGlzSU5UeCsNCglTdGF0dXM6IENhcCsgNjZNSHotIFVERi0gRmFzdEIyQi0g
UGFyRXJyLSBERVZTRUw9ZmFzdCA+VEFib3J0LSA8VEFib3J0LSA8TUFib3J0LSA+U0VSUi0g
PFBFUlItIElOVHgtDQoJTGF0ZW5jeTogMCwgQ2FjaGUgTGluZSBTaXplOiA2NCBieXRlcw0K
CUJ1czogcHJpbWFyeT0wMCwgc2Vjb25kYXJ5PTA2LCBzdWJvcmRpbmF0ZT0wNiwgc2VjLWxh
dGVuY3k9MA0KCUkvTyBiZWhpbmQgYnJpZGdlOiAwMDAwYjAwMC0wMDAwYmZmZg0KCU1lbW9y
eSBiZWhpbmQgYnJpZGdlOiBmOTkwMDAwMC1mOTlmZmZmZg0KCVByZWZldGNoYWJsZSBtZW1v
cnkgYmVoaW5kIGJyaWRnZTogMDAwMDAwMDBiMDAwMDAwMC0wMDAwMDAwMGJmZmZmZmZmDQoJ
U2Vjb25kYXJ5IHN0YXR1czogNjZNSHotIEZhc3RCMkItIFBhckVyci0gREVWU0VMPWZhc3Qg
PlRBYm9ydC0gPFRBYm9ydC0gPE1BYm9ydC0gPFNFUlItIDxQRVJSLQ0KCUJyaWRnZUN0bDog
UGFyaXR5KyBTRVJSKyBOb0lTQSsgVkdBLSBNQWJvcnQtID5SZXNldC0gRmFzdEIyQi0NCgkJ
UHJpRGlzY1Rtci0gU2VjRGlzY1Rtci0gRGlzY1RtclN0YXQtIERpc2NUbXJTRVJSRW4tDQoJ
Q2FwYWJpbGl0aWVzOiBbNTBdIFBvd2VyIE1hbmFnZW1lbnQgdmVyc2lvbiAzDQoJCUZsYWdz
OiBQTUVDbGstIERTSS0gRDEtIEQyLSBBdXhDdXJyZW50PTBtQSBQTUUoRDArLEQxLSxEMi0s
RDNob3QrLEQzY29sZCspDQoJCVN0YXR1czogRDAgTm9Tb2Z0UnN0LSBQTUUtRW5hYmxlLSBE
U2VsPTAgRFNjYWxlPTAgUE1FLQ0KCUNhcGFiaWxpdGllczogWzU4XSBFeHByZXNzICh2Mikg
Um9vdCBQb3J0IChTbG90KyksIE1TSSAwMA0KCQlEZXZDYXA6CU1heFBheWxvYWQgMTI4IGJ5
dGVzLCBQaGFudEZ1bmMgMCwgTGF0ZW5jeSBMMHMgPDY0bnMsIEwxIDwxdXMNCgkJCUV4dFRh
ZysgUkJFKyBGTFJlc2V0LQ0KCQlEZXZDdGw6CVJlcG9ydCBlcnJvcnM6IENvcnJlY3RhYmxl
LSBOb24tRmF0YWwtIEZhdGFsLSBVbnN1cHBvcnRlZC0NCgkJCVJseGRPcmQrIEV4dFRhZy0g
UGhhbnRGdW5jLSBBdXhQd3ItIE5vU25vb3ArDQoJCQlNYXhQYXlsb2FkIDEyOCBieXRlcywg
TWF4UmVhZFJlcSAxMjggYnl0ZXMNCgkJRGV2U3RhOglDb3JyRXJyLSBVbmNvcnJFcnItIEZh
dGFsRXJyLSBVbnN1cHBSZXEtIEF1eFB3ci0gVHJhbnNQZW5kLQ0KCQlMbmtDYXA6CVBvcnQg
IzAsIFNwZWVkIDVHVC9zLCBXaWR0aCB4OCwgQVNQTSBMMHMgTDEsIExhdGVuY3kgTDAgPDF1
cywgTDEgPDh1cw0KCQkJQ2xvY2tQTS0gU3VycHJpc2UtIExMQWN0UmVwKyBCd05vdCsNCgkJ
TG5rQ3RsOglBU1BNIERpc2FibGVkOyBSQ0IgNjQgYnl0ZXMgRGlzYWJsZWQtIFJldHJhaW4t
IENvbW1DbGsrDQoJCQlFeHRTeW5jaC0gQ2xvY2tQTS0gQXV0V2lkRGlzLSBCV0ludC0gQXV0
QldJbnQtDQoJCUxua1N0YToJU3BlZWQgMi41R1QvcywgV2lkdGggeDEsIFRyRXJyLSBUcmFp
bi0gU2xvdENsaysgRExBY3RpdmUrIEJXTWdtdCsgQUJXTWdtdC0NCgkJU2x0Q2FwOglBdHRu
QnRuLSBQd3JDdHJsLSBNUkwtIEF0dG5JbmQtIFB3ckluZC0gSG90UGx1Zy0gU3VycHJpc2Ut
DQoJCQlTbG90ICM1LCBQb3dlckxpbWl0IDMxLjAwMFc7IEludGVybG9jay0gTm9Db21wbCsN
CgkJU2x0Q3RsOglFbmFibGU6IEF0dG5CdG4tIFB3ckZsdC0gTVJMLSBQcmVzRGV0LSBDbWRD
cGx0LSBIUElycS0gTGlua0NoZy0NCgkJCUNvbnRyb2w6IEF0dG5JbmQgVW5rbm93biwgUHdy
SW5kIFVua25vd24sIFBvd2VyLSBJbnRlcmxvY2stDQoJCVNsdFN0YToJU3RhdHVzOiBBdHRu
QnRuLSBQb3dlckZsdC0gTVJMLSBDbWRDcGx0LSBQcmVzRGV0KyBJbnRlcmxvY2stDQoJCQlD
aGFuZ2VkOiBNUkwtIFByZXNEZXQrIExpbmtTdGF0ZSsNCgkJUm9vdEN0bDogRXJyQ29ycmVj
dGFibGUtIEVyck5vbi1GYXRhbC0gRXJyRmF0YWwtIFBNRUludEVuYS0gQ1JTVmlzaWJsZS0N
CgkJUm9vdENhcDogQ1JTVmlzaWJsZS0NCgkJUm9vdFN0YTogUE1FIFJlcUlEIDAwMDAsIFBN
RVN0YXR1cy0gUE1FUGVuZGluZy0NCgkJRGV2Q2FwMjogQ29tcGxldGlvbiBUaW1lb3V0OiBS
YW5nZSBBQkNELCBUaW1lb3V0RGlzKyBBUklGd2QrDQoJCURldkN0bDI6IENvbXBsZXRpb24g
VGltZW91dDogNjVtcyB0byAyMTBtcywgVGltZW91dERpcy0gQVJJRndkLQ0KCQlMbmtDdGwy
OiBUYXJnZXQgTGluayBTcGVlZDogNUdUL3MsIEVudGVyQ29tcGxpYW5jZS0gU3BlZWREaXMt
LCBTZWxlY3RhYmxlIERlLWVtcGhhc2lzOiAtMy41ZEINCgkJCSBUcmFuc21pdCBNYXJnaW46
IE5vcm1hbCBPcGVyYXRpbmcgUmFuZ2UsIEVudGVyTW9kaWZpZWRDb21wbGlhbmNlLSBDb21w
bGlhbmNlU09TLQ0KCQkJIENvbXBsaWFuY2UgRGUtZW1waGFzaXM6IC02ZEINCgkJTG5rU3Rh
MjogQ3VycmVudCBEZS1lbXBoYXNpcyBMZXZlbDogLTMuNWRCDQoJQ2FwYWJpbGl0aWVzOiBb
YTBdIE1TSTogRW5hYmxlKyBDb3VudD0xLzEgTWFza2FibGUtIDY0Yml0LQ0KCQlBZGRyZXNz
OiBmZWUzZjAwYyAgRGF0YTogNDE3OQ0KCUNhcGFiaWxpdGllczogW2IwXSBTdWJzeXN0ZW06
IEFUSSBUZWNobm9sb2dpZXMgSW5jIERldmljZSBbMTAwMjo1YTExXQ0KCUNhcGFiaWxpdGll
czogW2I4XSBIeXBlclRyYW5zcG9ydDogTVNJIE1hcHBpbmcgRW5hYmxlKyBGaXhlZCsNCglD
YXBhYmlsaXRpZXM6IFsxMDAgdjFdIFZlbmRvciBTcGVjaWZpYyBJbmZvcm1hdGlvbjogSUQ9
MDAwMSBSZXY9MSBMZW49MDEwIDw/Pg0KCUNhcGFiaWxpdGllczogWzE5MCB2MV0gQWNjZXNz
IENvbnRyb2wgU2VydmljZXMNCgkJQUNTQ2FwOglTcmNWYWxpZCsgVHJhbnNCbGsrIFJlcVJl
ZGlyKyBDbXBsdFJlZGlyKyBVcHN0cmVhbUZ3ZCsgRWdyZXNzQ3RybC0gRGlyZWN0VHJhbnMr
DQoJCUFDU0N0bDoJU3JjVmFsaWQrIFRyYW5zQmxrLSBSZXFSZWRpcisgQ21wbHRSZWRpcisg
VXBzdHJlYW1Gd2QrIEVncmVzc0N0cmwtIERpcmVjdFRyYW5zLQ0KCUtlcm5lbCBkcml2ZXIg
aW4gdXNlOiBwY2llcG9ydA0KDQowMDowYy4wIFBDSSBicmlkZ2UgWzA2MDRdOiBBVEkgVGVj
aG5vbG9naWVzIEluYyBEZXZpY2UgWzEwMDI6NWEyMF0gKHByb2ctaWYgMDAgW05vcm1hbCBk
ZWNvZGVdKQ0KCUNvbnRyb2w6IEkvTy0gTWVtKyBCdXNNYXN0ZXIrIFNwZWNDeWNsZS0gTWVt
V0lOVi0gVkdBU25vb3AtIFBhckVyci0gU3RlcHBpbmctIFNFUlIrIEZhc3RCMkItIERpc0lO
VHgrDQoJU3RhdHVzOiBDYXArIDY2TUh6LSBVREYtIEZhc3RCMkItIFBhckVyci0gREVWU0VM
PWZhc3QgPlRBYm9ydC0gPFRBYm9ydC0gPE1BYm9ydC0gPlNFUlItIDxQRVJSLSBJTlR4LQ0K
CUxhdGVuY3k6IDAsIENhY2hlIExpbmUgU2l6ZTogNjQgYnl0ZXMNCglCdXM6IHByaW1hcnk9
MDAsIHNlY29uZGFyeT0wNSwgc3Vib3JkaW5hdGU9MDUsIHNlYy1sYXRlbmN5PTANCglJL08g
YmVoaW5kIGJyaWRnZTogMDAwMGYwMDAtMDAwMDBmZmYNCglNZW1vcnkgYmVoaW5kIGJyaWRn
ZTogZjk2MDAwMDAtZjk3ZmZmZmYNCglQcmVmZXRjaGFibGUgbWVtb3J5IGJlaGluZCBicmlk
Z2U6IDAwMDAwMDAwZmZmMDAwMDAtMDAwMDAwMDAwMDBmZmZmZg0KCVNlY29uZGFyeSBzdGF0
dXM6IDY2TUh6LSBGYXN0QjJCLSBQYXJFcnItIERFVlNFTD1mYXN0ID5UQWJvcnQtIDxUQWJv
cnQtIDxNQWJvcnQrIDxTRVJSLSA8UEVSUi0NCglCcmlkZ2VDdGw6IFBhcml0eSsgU0VSUisg
Tm9JU0ErIFZHQS0gTUFib3J0LSA+UmVzZXQtIEZhc3RCMkItDQoJCVByaURpc2NUbXItIFNl
Y0Rpc2NUbXItIERpc2NUbXJTdGF0LSBEaXNjVG1yU0VSUkVuLQ0KCUNhcGFiaWxpdGllczog
WzUwXSBQb3dlciBNYW5hZ2VtZW50IHZlcnNpb24gMw0KCQlGbGFnczogUE1FQ2xrLSBEU0kt
IEQxLSBEMi0gQXV4Q3VycmVudD0wbUEgUE1FKEQwKyxEMS0sRDItLEQzaG90KyxEM2NvbGQr
KQ0KCQlTdGF0dXM6IEQwIE5vU29mdFJzdC0gUE1FLUVuYWJsZS0gRFNlbD0wIERTY2FsZT0w
IFBNRS0NCglDYXBhYmlsaXRpZXM6IFs1OF0gRXhwcmVzcyAodjIpIFJvb3QgUG9ydCAoU2xv
dCspLCBNU0kgMDANCgkJRGV2Q2FwOglNYXhQYXlsb2FkIDEyOCBieXRlcywgUGhhbnRGdW5j
IDAsIExhdGVuY3kgTDBzIDw2NG5zLCBMMSA8MXVzDQoJCQlFeHRUYWcrIFJCRSsgRkxSZXNl
dC0NCgkJRGV2Q3RsOglSZXBvcnQgZXJyb3JzOiBDb3JyZWN0YWJsZS0gTm9uLUZhdGFsLSBG
YXRhbC0gVW5zdXBwb3J0ZWQtDQoJCQlSbHhkT3JkKyBFeHRUYWctIFBoYW50RnVuYy0gQXV4
UHdyLSBOb1Nub29wKw0KCQkJTWF4UGF5bG9hZCAxMjggYnl0ZXMsIE1heFJlYWRSZXEgMTI4
IGJ5dGVzDQoJCURldlN0YToJQ29yckVyci0gVW5jb3JyRXJyLSBGYXRhbEVyci0gVW5zdXBw
UmVxLSBBdXhQd3ItIFRyYW5zUGVuZC0NCgkJTG5rQ2FwOglQb3J0ICMxLCBTcGVlZCA1R1Qv
cywgV2lkdGggeDgsIEFTUE0gTDBzIEwxLCBMYXRlbmN5IEwwIDwxdXMsIEwxIDw4dXMNCgkJ
CUNsb2NrUE0tIFN1cnByaXNlLSBMTEFjdFJlcCsgQndOb3QrDQoJCUxua0N0bDoJQVNQTSBE
aXNhYmxlZDsgUkNCIDY0IGJ5dGVzIERpc2FibGVkLSBSZXRyYWluLSBDb21tQ2xrLQ0KCQkJ
RXh0U3luY2gtIENsb2NrUE0tIEF1dFdpZERpcy0gQldJbnQtIEF1dEJXSW50LQ0KCQlMbmtT
dGE6CVNwZWVkIDIuNUdUL3MsIFdpZHRoIHgxLCBUckVyci0gVHJhaW4tIFNsb3RDbGsrIERM
QWN0aXZlKyBCV01nbXQrIEFCV01nbXQtDQoJCVNsdENhcDoJQXR0bkJ0bi0gUHdyQ3RybC0g
TVJMLSBBdHRuSW5kLSBQd3JJbmQtIEhvdFBsdWctIFN1cnByaXNlLQ0KCQkJU2xvdCAjNiwg
UG93ZXJMaW1pdCAxNC4wMDBXOyBJbnRlcmxvY2stIE5vQ29tcGwrDQoJCVNsdEN0bDoJRW5h
YmxlOiBBdHRuQnRuLSBQd3JGbHQtIE1STC0gUHJlc0RldC0gQ21kQ3BsdC0gSFBJcnEtIExp
bmtDaGctDQoJCQlDb250cm9sOiBBdHRuSW5kIFVua25vd24sIFB3ckluZCBVbmtub3duLCBQ
b3dlci0gSW50ZXJsb2NrLQ0KCQlTbHRTdGE6CVN0YXR1czogQXR0bkJ0bi0gUG93ZXJGbHQt
IE1STC0gQ21kQ3BsdC0gUHJlc0RldCsgSW50ZXJsb2NrLQ0KCQkJQ2hhbmdlZDogTVJMLSBQ
cmVzRGV0KyBMaW5rU3RhdGUrDQoJCVJvb3RDdGw6IEVyckNvcnJlY3RhYmxlLSBFcnJOb24t
RmF0YWwtIEVyckZhdGFsLSBQTUVJbnRFbmEtIENSU1Zpc2libGUtDQoJCVJvb3RDYXA6IENS
U1Zpc2libGUtDQoJCVJvb3RTdGE6IFBNRSBSZXFJRCAwMDAwLCBQTUVTdGF0dXMtIFBNRVBl
bmRpbmctDQoJCURldkNhcDI6IENvbXBsZXRpb24gVGltZW91dDogUmFuZ2UgQUJDRCwgVGlt
ZW91dERpcysgQVJJRndkKw0KCQlEZXZDdGwyOiBDb21wbGV0aW9uIFRpbWVvdXQ6IDY1bXMg
dG8gMjEwbXMsIFRpbWVvdXREaXMtIEFSSUZ3ZC0NCgkJTG5rQ3RsMjogVGFyZ2V0IExpbmsg
U3BlZWQ6IDVHVC9zLCBFbnRlckNvbXBsaWFuY2UtIFNwZWVkRGlzLSwgU2VsZWN0YWJsZSBE
ZS1lbXBoYXNpczogLTMuNWRCDQoJCQkgVHJhbnNtaXQgTWFyZ2luOiBOb3JtYWwgT3BlcmF0
aW5nIFJhbmdlLCBFbnRlck1vZGlmaWVkQ29tcGxpYW5jZS0gQ29tcGxpYW5jZVNPUy0NCgkJ
CSBDb21wbGlhbmNlIERlLWVtcGhhc2lzOiAtNmRCDQoJCUxua1N0YTI6IEN1cnJlbnQgRGUt
ZW1waGFzaXMgTGV2ZWw6IC0zLjVkQg0KCUNhcGFiaWxpdGllczogW2EwXSBNU0k6IEVuYWJs
ZSsgQ291bnQ9MS8xIE1hc2thYmxlLSA2NGJpdC0NCgkJQWRkcmVzczogZmVlM2YwMGMgIERh
dGE6IDQxODENCglDYXBhYmlsaXRpZXM6IFtiMF0gU3Vic3lzdGVtOiBBVEkgVGVjaG5vbG9n
aWVzIEluYyBEZXZpY2UgWzEwMDI6NWExMV0NCglDYXBhYmlsaXRpZXM6IFtiOF0gSHlwZXJU
cmFuc3BvcnQ6IE1TSSBNYXBwaW5nIEVuYWJsZSsgRml4ZWQrDQoJQ2FwYWJpbGl0aWVzOiBb
MTAwIHYxXSBWZW5kb3IgU3BlY2lmaWMgSW5mb3JtYXRpb246IElEPTAwMDEgUmV2PTEgTGVu
PTAxMCA8Pz4NCglDYXBhYmlsaXRpZXM6IFsxOTAgdjFdIEFjY2VzcyBDb250cm9sIFNlcnZp
Y2VzDQoJCUFDU0NhcDoJU3JjVmFsaWQrIFRyYW5zQmxrKyBSZXFSZWRpcisgQ21wbHRSZWRp
cisgVXBzdHJlYW1Gd2QrIEVncmVzc0N0cmwtIERpcmVjdFRyYW5zKw0KCQlBQ1NDdGw6CVNy
Y1ZhbGlkKyBUcmFuc0Jsay0gUmVxUmVkaXIrIENtcGx0UmVkaXIrIFVwc3RyZWFtRndkKyBF
Z3Jlc3NDdHJsLSBEaXJlY3RUcmFucy0NCglLZXJuZWwgZHJpdmVyIGluIHVzZTogcGNpZXBv
cnQNCg0KMDA6MGQuMCBQQ0kgYnJpZGdlIFswNjA0XTogQVRJIFRlY2hub2xvZ2llcyBJbmMg
UkQ4OTAgUENJIHRvIFBDSSBicmlkZ2UgKGV4dGVybmFsIGdmeDEgcG9ydCBCKSBbMTAwMjo1
YTFlXSAocHJvZy1pZiAwMCBbTm9ybWFsIGRlY29kZV0pDQoJQ29udHJvbDogSS9PLSBNZW0r
IEJ1c01hc3RlcisgU3BlY0N5Y2xlLSBNZW1XSU5WLSBWR0FTbm9vcC0gUGFyRXJyLSBTdGVw
cGluZy0gU0VSUisgRmFzdEIyQi0gRGlzSU5UeCsNCglTdGF0dXM6IENhcCsgNjZNSHotIFVE
Ri0gRmFzdEIyQi0gUGFyRXJyLSBERVZTRUw9ZmFzdCA+VEFib3J0LSA8VEFib3J0LSA8TUFi
b3J0LSA+U0VSUi0gPFBFUlItIElOVHgtDQoJTGF0ZW5jeTogMCwgQ2FjaGUgTGluZSBTaXpl
OiA2NCBieXRlcw0KCUJ1czogcHJpbWFyeT0wMCwgc2Vjb25kYXJ5PTA0LCBzdWJvcmRpbmF0
ZT0wNCwgc2VjLWxhdGVuY3k9MA0KCUkvTyBiZWhpbmQgYnJpZGdlOiAwMDAwZjAwMC0wMDAw
MGZmZg0KCU1lbW9yeSBiZWhpbmQgYnJpZGdlOiBmOTUwMDAwMC1mOTVmZmZmZg0KCVByZWZl
dGNoYWJsZSBtZW1vcnkgYmVoaW5kIGJyaWRnZTogMDAwMDAwMDBmZmYwMDAwMC0wMDAwMDAw
MDAwMGZmZmZmDQoJU2Vjb25kYXJ5IHN0YXR1czogNjZNSHotIEZhc3RCMkItIFBhckVyci0g
REVWU0VMPWZhc3QgPlRBYm9ydC0gPFRBYm9ydC0gPE1BYm9ydC0gPFNFUlItIDxQRVJSLQ0K
CUJyaWRnZUN0bDogUGFyaXR5KyBTRVJSKyBOb0lTQSsgVkdBLSBNQWJvcnQtID5SZXNldC0g
RmFzdEIyQi0NCgkJUHJpRGlzY1Rtci0gU2VjRGlzY1Rtci0gRGlzY1RtclN0YXQtIERpc2NU
bXJTRVJSRW4tDQoJQ2FwYWJpbGl0aWVzOiBbNTBdIFBvd2VyIE1hbmFnZW1lbnQgdmVyc2lv
biAzDQoJCUZsYWdzOiBQTUVDbGstIERTSS0gRDEtIEQyLSBBdXhDdXJyZW50PTBtQSBQTUUo
RDArLEQxLSxEMi0sRDNob3QrLEQzY29sZCspDQoJCVN0YXR1czogRDAgTm9Tb2Z0UnN0LSBQ
TUUtRW5hYmxlLSBEU2VsPTAgRFNjYWxlPTAgUE1FLQ0KCUNhcGFiaWxpdGllczogWzU4XSBF
eHByZXNzICh2MikgUm9vdCBQb3J0IChTbG90KyksIE1TSSAwMA0KCQlEZXZDYXA6CU1heFBh
eWxvYWQgMTI4IGJ5dGVzLCBQaGFudEZ1bmMgMCwgTGF0ZW5jeSBMMHMgPDY0bnMsIEwxIDwx
dXMNCgkJCUV4dFRhZysgUkJFKyBGTFJlc2V0LQ0KCQlEZXZDdGw6CVJlcG9ydCBlcnJvcnM6
IENvcnJlY3RhYmxlLSBOb24tRmF0YWwtIEZhdGFsLSBVbnN1cHBvcnRlZC0NCgkJCVJseGRP
cmQrIEV4dFRhZy0gUGhhbnRGdW5jLSBBdXhQd3ItIE5vU25vb3ArDQoJCQlNYXhQYXlsb2Fk
IDEyOCBieXRlcywgTWF4UmVhZFJlcSAxMjggYnl0ZXMNCgkJRGV2U3RhOglDb3JyRXJyLSBV
bmNvcnJFcnItIEZhdGFsRXJyLSBVbnN1cHBSZXEtIEF1eFB3ci0gVHJhbnNQZW5kLQ0KCQlM
bmtDYXA6CVBvcnQgIzAsIFNwZWVkIDVHVC9zLCBXaWR0aCB4NCwgQVNQTSBMMHMgTDEsIExh
dGVuY3kgTDAgPDF1cywgTDEgPDh1cw0KCQkJQ2xvY2tQTS0gU3VycHJpc2UtIExMQWN0UmVw
KyBCd05vdCsNCgkJTG5rQ3RsOglBU1BNIERpc2FibGVkOyBSQ0IgNjQgYnl0ZXMgRGlzYWJs
ZWQtIFJldHJhaW4tIENvbW1DbGstDQoJCQlFeHRTeW5jaC0gQ2xvY2tQTS0gQXV0V2lkRGlz
LSBCV0ludC0gQXV0QldJbnQtDQoJCUxua1N0YToJU3BlZWQgMi41R1QvcywgV2lkdGggeDEs
IFRyRXJyLSBUcmFpbi0gU2xvdENsaysgRExBY3RpdmUrIEJXTWdtdCsgQUJXTWdtdC0NCgkJ
U2x0Q2FwOglBdHRuQnRuLSBQd3JDdHJsLSBNUkwtIEF0dG5JbmQtIFB3ckluZC0gSG90UGx1
Zy0gU3VycHJpc2UtDQoJCQlTbG90ICM0LCBQb3dlckxpbWl0IDc1LjAwMFc7IEludGVybG9j
ay0gTm9Db21wbCsNCgkJU2x0Q3RsOglFbmFibGU6IEF0dG5CdG4tIFB3ckZsdC0gTVJMLSBQ
cmVzRGV0LSBDbWRDcGx0LSBIUElycS0gTGlua0NoZy0NCgkJCUNvbnRyb2w6IEF0dG5JbmQg
VW5rbm93biwgUHdySW5kIFVua25vd24sIFBvd2VyLSBJbnRlcmxvY2stDQoJCVNsdFN0YToJ
U3RhdHVzOiBBdHRuQnRuLSBQb3dlckZsdC0gTVJMLSBDbWRDcGx0LSBQcmVzRGV0KyBJbnRl
cmxvY2stDQoJCQlDaGFuZ2VkOiBNUkwtIFByZXNEZXQrIExpbmtTdGF0ZSsNCgkJUm9vdEN0
bDogRXJyQ29ycmVjdGFibGUtIEVyck5vbi1GYXRhbC0gRXJyRmF0YWwtIFBNRUludEVuYS0g
Q1JTVmlzaWJsZS0NCgkJUm9vdENhcDogQ1JTVmlzaWJsZS0NCgkJUm9vdFN0YTogUE1FIFJl
cUlEIDAwMDAsIFBNRVN0YXR1cy0gUE1FUGVuZGluZy0NCgkJRGV2Q2FwMjogQ29tcGxldGlv
biBUaW1lb3V0OiBSYW5nZSBBQkNELCBUaW1lb3V0RGlzKyBBUklGd2QrDQoJCURldkN0bDI6
IENvbXBsZXRpb24gVGltZW91dDogNjVtcyB0byAyMTBtcywgVGltZW91dERpcy0gQVJJRndk
LQ0KCQlMbmtDdGwyOiBUYXJnZXQgTGluayBTcGVlZDogNUdUL3MsIEVudGVyQ29tcGxpYW5j
ZS0gU3BlZWREaXMtLCBTZWxlY3RhYmxlIERlLWVtcGhhc2lzOiAtMy41ZEINCgkJCSBUcmFu
c21pdCBNYXJnaW46IE5vcm1hbCBPcGVyYXRpbmcgUmFuZ2UsIEVudGVyTW9kaWZpZWRDb21w
bGlhbmNlLSBDb21wbGlhbmNlU09TLQ0KCQkJIENvbXBsaWFuY2UgRGUtZW1waGFzaXM6IC02
ZEINCgkJTG5rU3RhMjogQ3VycmVudCBEZS1lbXBoYXNpcyBMZXZlbDogLTMuNWRCDQoJQ2Fw
YWJpbGl0aWVzOiBbYTBdIE1TSTogRW5hYmxlKyBDb3VudD0xLzEgTWFza2FibGUtIDY0Yml0
LQ0KCQlBZGRyZXNzOiBmZWUzZjAwYyAgRGF0YTogNDE4OQ0KCUNhcGFiaWxpdGllczogW2Iw
XSBTdWJzeXN0ZW06IEFUSSBUZWNobm9sb2dpZXMgSW5jIERldmljZSBbMTAwMjo1YTExXQ0K
CUNhcGFiaWxpdGllczogW2I4XSBIeXBlclRyYW5zcG9ydDogTVNJIE1hcHBpbmcgRW5hYmxl
KyBGaXhlZCsNCglDYXBhYmlsaXRpZXM6IFsxMDAgdjFdIFZlbmRvciBTcGVjaWZpYyBJbmZv
cm1hdGlvbjogSUQ9MDAwMSBSZXY9MSBMZW49MDEwIDw/Pg0KCUNhcGFiaWxpdGllczogWzE5
MCB2MV0gQWNjZXNzIENvbnRyb2wgU2VydmljZXMNCgkJQUNTQ2FwOglTcmNWYWxpZCsgVHJh
bnNCbGsrIFJlcVJlZGlyKyBDbXBsdFJlZGlyKyBVcHN0cmVhbUZ3ZCsgRWdyZXNzQ3RybC0g
RGlyZWN0VHJhbnMrDQoJCUFDU0N0bDoJU3JjVmFsaWQrIFRyYW5zQmxrLSBSZXFSZWRpcisg
Q21wbHRSZWRpcisgVXBzdHJlYW1Gd2QrIEVncmVzc0N0cmwtIERpcmVjdFRyYW5zLQ0KCUtl
cm5lbCBkcml2ZXIgaW4gdXNlOiBwY2llcG9ydA0KDQowMDoxMS4wIFNBVEEgY29udHJvbGxl
ciBbMDEwNl06IEFUSSBUZWNobm9sb2dpZXMgSW5jIFNCN3gwL1NCOHgwL1NCOXgwIFNBVEEg
Q29udHJvbGxlciBbQUhDSSBtb2RlXSBbMTAwMjo0MzkxXSAocmV2IDQwKSAocHJvZy1pZiAw
MSBbQUhDSSAxLjBdKQ0KCVN1YnN5c3RlbTogTWljcm8tU3RhciBJbnRlcm5hdGlvbmFsIENv
LiwgTHRkLiBEZXZpY2UgWzE0NjI6NzY0MF0NCglDb250cm9sOiBJL08rIE1lbSsgQnVzTWFz
dGVyKyBTcGVjQ3ljbGUtIE1lbVdJTlYtIFZHQVNub29wLSBQYXJFcnItIFN0ZXBwaW5nLSBT
RVJSKyBGYXN0QjJCLSBEaXNJTlR4Kw0KCVN0YXR1czogQ2FwKyA2Nk1IeisgVURGLSBGYXN0
QjJCLSBQYXJFcnItIERFVlNFTD1tZWRpdW0gPlRBYm9ydC0gPFRBYm9ydC0gPE1BYm9ydC0g
PlNFUlItIDxQRVJSLSBJTlR4LQ0KCUxhdGVuY3k6IDY0LCBDYWNoZSBMaW5lIFNpemU6IDY0
IGJ5dGVzDQoJSW50ZXJydXB0OiBwaW4gQSByb3V0ZWQgdG8gSVJRIDEyMA0KCVJlZ2lvbiAw
OiBJL08gcG9ydHMgYXQgNzAwMCBbc2l6ZT04XQ0KCVJlZ2lvbiAxOiBJL08gcG9ydHMgYXQg
NjAwMCBbc2l6ZT00XQ0KCVJlZ2lvbiAyOiBJL08gcG9ydHMgYXQgNTAwMCBbc2l6ZT04XQ0K
CVJlZ2lvbiAzOiBJL08gcG9ydHMgYXQgMzAwMCBbc2l6ZT00XQ0KCVJlZ2lvbiA0OiBJL08g
cG9ydHMgYXQgMjAwMCBbc2l6ZT0xNl0NCglSZWdpb24gNTogTWVtb3J5IGF0IGY5M2ZmMDAw
ICgzMi1iaXQsIG5vbi1wcmVmZXRjaGFibGUpIFtzaXplPTFLXQ0KCUNhcGFiaWxpdGllczog
WzUwXSBNU0k6IEVuYWJsZSsgQ291bnQ9MS84IE1hc2thYmxlLSA2NGJpdCsNCgkJQWRkcmVz
czogMDAwMDAwMDBmZWUwMTAwYyAgRGF0YTogNDFiOQ0KCUNhcGFiaWxpdGllczogWzcwXSBT
QVRBIEhCQSB2MS4wIEluQ2ZnU3BhY2UNCglDYXBhYmlsaXRpZXM6IFthNF0gUENJIEFkdmFu
Y2VkIEZlYXR1cmVzDQoJCUFGQ2FwOiBUUCsgRkxSKw0KCQlBRkN0cmw6IEZMUi0NCgkJQUZT
dGF0dXM6IFRQLQ0KCUtlcm5lbCBkcml2ZXIgaW4gdXNlOiBhaGNpDQoNCjAwOjEyLjAgVVNC
IGNvbnRyb2xsZXIgWzBjMDNdOiBBVEkgVGVjaG5vbG9naWVzIEluYyBTQjd4MC9TQjh4MC9T
Qjl4MCBVU0IgT0hDSTAgQ29udHJvbGxlciBbMTAwMjo0Mzk3XSAocHJvZy1pZiAxMCBbT0hD
SV0pDQoJU3Vic3lzdGVtOiBNaWNyby1TdGFyIEludGVybmF0aW9uYWwgQ28uLCBMdGQuIERl
dmljZSBbMTQ2Mjo3NjQwXQ0KCUNvbnRyb2w6IEkvTysgTWVtKyBCdXNNYXN0ZXIrIFNwZWND
eWNsZS0gTWVtV0lOVisgVkdBU25vb3AtIFBhckVyci0gU3RlcHBpbmctIFNFUlIrIEZhc3RC
MkItIERpc0lOVHgtDQoJU3RhdHVzOiBDYXAtIDY2TUh6KyBVREYtIEZhc3RCMkIrIFBhckVy
ci0gREVWU0VMPW1lZGl1bSA+VEFib3J0LSA8VEFib3J0LSA8TUFib3J0LSA+U0VSUi0gPFBF
UlItIElOVHgtDQoJTGF0ZW5jeTogNjQsIENhY2hlIExpbmUgU2l6ZTogNjQgYnl0ZXMNCglJ
bnRlcnJ1cHQ6IHBpbiBBIHJvdXRlZCB0byBJUlEgMTgNCglSZWdpb24gMDogTWVtb3J5IGF0
IGY5M2ZiMDAwICgzMi1iaXQsIG5vbi1wcmVmZXRjaGFibGUpIFtzaXplPTRLXQ0KCUtlcm5l
bCBkcml2ZXIgaW4gdXNlOiBvaGNpX2hjZA0KDQowMDoxMi4yIFVTQiBjb250cm9sbGVyIFsw
YzAzXTogQVRJIFRlY2hub2xvZ2llcyBJbmMgU0I3eDAvU0I4eDAvU0I5eDAgVVNCIEVIQ0kg
Q29udHJvbGxlciBbMTAwMjo0Mzk2XSAocHJvZy1pZiAyMCBbRUhDSV0pDQoJU3Vic3lzdGVt
OiBNaWNyby1TdGFyIEludGVybmF0aW9uYWwgQ28uLCBMdGQuIERldmljZSBbMTQ2Mjo3NjQw
XQ0KCUNvbnRyb2w6IEkvTy0gTWVtKyBCdXNNYXN0ZXIrIFNwZWNDeWNsZS0gTWVtV0lOVisg
VkdBU25vb3AtIFBhckVyci0gU3RlcHBpbmctIFNFUlIrIEZhc3RCMkItIERpc0lOVHgtDQoJ
U3RhdHVzOiBDYXArIDY2TUh6KyBVREYtIEZhc3RCMkIrIFBhckVyci0gREVWU0VMPW1lZGl1
bSA+VEFib3J0LSA8VEFib3J0LSA8TUFib3J0LSA+U0VSUi0gPFBFUlItIElOVHgtDQoJTGF0
ZW5jeTogNjQsIENhY2hlIExpbmUgU2l6ZTogNjQgYnl0ZXMNCglJbnRlcnJ1cHQ6IHBpbiBC
IHJvdXRlZCB0byBJUlEgMTcNCglSZWdpb24gMDogTWVtb3J5IGF0IGY5M2ZmNDAwICgzMi1i
aXQsIG5vbi1wcmVmZXRjaGFibGUpIFtzaXplPTI1Nl0NCglDYXBhYmlsaXRpZXM6IFtjMF0g
UG93ZXIgTWFuYWdlbWVudCB2ZXJzaW9uIDINCgkJRmxhZ3M6IFBNRUNsay0gRFNJLSBEMSsg
RDIrIEF1eEN1cnJlbnQ9MG1BIFBNRShEMCssRDErLEQyKyxEM2hvdCssRDNjb2xkLSkNCgkJ
U3RhdHVzOiBEMCBOb1NvZnRSc3QtIFBNRS1FbmFibGUtIERTZWw9MCBEU2NhbGU9MCBQTUUt
DQoJCUJyaWRnZTogUE0tIEIzKw0KCUNhcGFiaWxpdGllczogW2U0XSBEZWJ1ZyBwb3J0OiBC
QVI9MSBvZmZzZXQ9MDBlMA0KCUtlcm5lbCBkcml2ZXIgaW4gdXNlOiBlaGNpX2hjZA0KDQow
MDoxMy4wIFVTQiBjb250cm9sbGVyIFswYzAzXTogQVRJIFRlY2hub2xvZ2llcyBJbmMgU0I3
eDAvU0I4eDAvU0I5eDAgVVNCIE9IQ0kwIENvbnRyb2xsZXIgWzEwMDI6NDM5N10gKHByb2ct
aWYgMTAgW09IQ0ldKQ0KCVN1YnN5c3RlbTogTWljcm8tU3RhciBJbnRlcm5hdGlvbmFsIENv
LiwgTHRkLiBEZXZpY2UgWzE0NjI6NzY0MF0NCglDb250cm9sOiBJL08rIE1lbSsgQnVzTWFz
dGVyKyBTcGVjQ3ljbGUtIE1lbVdJTlYrIFZHQVNub29wLSBQYXJFcnItIFN0ZXBwaW5nLSBT
RVJSKyBGYXN0QjJCLSBEaXNJTlR4LQ0KCVN0YXR1czogQ2FwLSA2Nk1IeisgVURGLSBGYXN0
QjJCKyBQYXJFcnItIERFVlNFTD1tZWRpdW0gPlRBYm9ydC0gPFRBYm9ydC0gPE1BYm9ydC0g
PlNFUlItIDxQRVJSLSBJTlR4LQ0KCUxhdGVuY3k6IDY0LCBDYWNoZSBMaW5lIFNpemU6IDY0
IGJ5dGVzDQoJSW50ZXJydXB0OiBwaW4gQSByb3V0ZWQgdG8gSVJRIDE4DQoJUmVnaW9uIDA6
IE1lbW9yeSBhdCBmOTNmYzAwMCAoMzItYml0LCBub24tcHJlZmV0Y2hhYmxlKSBbc2l6ZT00
S10NCglLZXJuZWwgZHJpdmVyIGluIHVzZTogb2hjaV9oY2QNCg0KMDA6MTMuMiBVU0IgY29u
dHJvbGxlciBbMGMwM106IEFUSSBUZWNobm9sb2dpZXMgSW5jIFNCN3gwL1NCOHgwL1NCOXgw
IFVTQiBFSENJIENvbnRyb2xsZXIgWzEwMDI6NDM5Nl0gKHByb2ctaWYgMjAgW0VIQ0ldKQ0K
CVN1YnN5c3RlbTogTWljcm8tU3RhciBJbnRlcm5hdGlvbmFsIENvLiwgTHRkLiBEZXZpY2Ug
WzE0NjI6NzY0MF0NCglDb250cm9sOiBJL08tIE1lbSsgQnVzTWFzdGVyKyBTcGVjQ3ljbGUt
IE1lbVdJTlYrIFZHQVNub29wLSBQYXJFcnItIFN0ZXBwaW5nLSBTRVJSKyBGYXN0QjJCLSBE
aXNJTlR4LQ0KCVN0YXR1czogQ2FwKyA2Nk1IeisgVURGLSBGYXN0QjJCKyBQYXJFcnItIERF
VlNFTD1tZWRpdW0gPlRBYm9ydC0gPFRBYm9ydC0gPE1BYm9ydC0gPlNFUlItIDxQRVJSLSBJ
TlR4LQ0KCUxhdGVuY3k6IDY0LCBDYWNoZSBMaW5lIFNpemU6IDY0IGJ5dGVzDQoJSW50ZXJy
dXB0OiBwaW4gQiByb3V0ZWQgdG8gSVJRIDE3DQoJUmVnaW9uIDA6IE1lbW9yeSBhdCBmOTNm
ZjgwMCAoMzItYml0LCBub24tcHJlZmV0Y2hhYmxlKSBbc2l6ZT0yNTZdDQoJQ2FwYWJpbGl0
aWVzOiBbYzBdIFBvd2VyIE1hbmFnZW1lbnQgdmVyc2lvbiAyDQoJCUZsYWdzOiBQTUVDbGst
IERTSS0gRDErIEQyKyBBdXhDdXJyZW50PTBtQSBQTUUoRDArLEQxKyxEMissRDNob3QrLEQz
Y29sZC0pDQoJCVN0YXR1czogRDAgTm9Tb2Z0UnN0LSBQTUUtRW5hYmxlLSBEU2VsPTAgRFNj
YWxlPTAgUE1FLQ0KCQlCcmlkZ2U6IFBNLSBCMysNCglDYXBhYmlsaXRpZXM6IFtlNF0gRGVi
dWcgcG9ydDogQkFSPTEgb2Zmc2V0PTAwZTANCglLZXJuZWwgZHJpdmVyIGluIHVzZTogZWhj
aV9oY2QNCg0KMDA6MTQuMCBTTUJ1cyBbMGMwNV06IEFUSSBUZWNobm9sb2dpZXMgSW5jIFNC
eDAwIFNNQnVzIENvbnRyb2xsZXIgWzEwMDI6NDM4NV0gKHJldiA0MSkNCglDb250cm9sOiBJ
L08rIE1lbSsgQnVzTWFzdGVyLSBTcGVjQ3ljbGUtIE1lbVdJTlYtIFZHQVNub29wLSBQYXJF
cnItIFN0ZXBwaW5nLSBTRVJSLSBGYXN0QjJCLSBEaXNJTlR4Kw0KCVN0YXR1czogQ2FwLSA2
Nk1IeisgVURGLSBGYXN0QjJCLSBQYXJFcnItIERFVlNFTD1tZWRpdW0gPlRBYm9ydC0gPFRB
Ym9ydC0gPE1BYm9ydC0gPlNFUlItIDxQRVJSLSBJTlR4LQ0KDQowMDoxNC4zIElTQSBicmlk
Z2UgWzA2MDFdOiBBVEkgVGVjaG5vbG9naWVzIEluYyBTQjd4MC9TQjh4MC9TQjl4MCBMUEMg
aG9zdCBjb250cm9sbGVyIFsxMDAyOjQzOWRdIChyZXYgNDApDQoJU3Vic3lzdGVtOiBNaWNy
by1TdGFyIEludGVybmF0aW9uYWwgQ28uLCBMdGQuIERldmljZSBbMTQ2Mjo3NjQwXQ0KCUNv
bnRyb2w6IEkvTysgTWVtKyBCdXNNYXN0ZXIrIFNwZWNDeWNsZSsgTWVtV0lOVi0gVkdBU25v
b3AtIFBhckVyci0gU3RlcHBpbmctIFNFUlItIEZhc3RCMkItIERpc0lOVHgtDQoJU3RhdHVz
OiBDYXAtIDY2TUh6KyBVREYtIEZhc3RCMkItIFBhckVyci0gREVWU0VMPW1lZGl1bSA+VEFi
b3J0LSA8VEFib3J0LSA8TUFib3J0LSA+U0VSUi0gPFBFUlItIElOVHgtDQoJTGF0ZW5jeTog
MA0KDQowMDoxNC40IFBDSSBicmlkZ2UgWzA2MDRdOiBBVEkgVGVjaG5vbG9naWVzIEluYyBT
QngwMCBQQ0kgdG8gUENJIEJyaWRnZSBbMTAwMjo0Mzg0XSAocmV2IDQwKSAocHJvZy1pZiAw
MSBbU3VidHJhY3RpdmUgZGVjb2RlXSkNCglDb250cm9sOiBJL08rIE1lbS0gQnVzTWFzdGVy
KyBTcGVjQ3ljbGUtIE1lbVdJTlYtIFZHQVNub29wLSBQYXJFcnItIFN0ZXBwaW5nLSBTRVJS
KyBGYXN0QjJCLSBEaXNJTlR4LQ0KCVN0YXR1czogQ2FwLSA2Nk1IeisgVURGLSBGYXN0QjJC
KyBQYXJFcnItIERFVlNFTD1tZWRpdW0gPlRBYm9ydC0gPFRBYm9ydC0gPE1BYm9ydC0gPlNF
UlItIDxQRVJSLSBJTlR4LQ0KCUxhdGVuY3k6IDY0DQoJQnVzOiBwcmltYXJ5PTAwLCBzZWNv
bmRhcnk9MDMsIHN1Ym9yZGluYXRlPTAzLCBzZWMtbGF0ZW5jeT02NA0KCUkvTyBiZWhpbmQg
YnJpZGdlOiAwMDAwYTAwMC0wMDAwYWZmZg0KCU1lbW9yeSBiZWhpbmQgYnJpZGdlOiBmZmYw
MDAwMC0wMDBmZmZmZg0KCVByZWZldGNoYWJsZSBtZW1vcnkgYmVoaW5kIGJyaWRnZTogZmZm
MDAwMDAtMDAwZmZmZmYNCglTZWNvbmRhcnkgc3RhdHVzOiA2Nk1Iei0gRmFzdEIyQisgUGFy
RXJyLSBERVZTRUw9bWVkaXVtID5UQWJvcnQtIDxUQWJvcnQtIDxNQWJvcnQrIDxTRVJSLSA8
UEVSUi0NCglCcmlkZ2VDdGw6IFBhcml0eSsgU0VSUisgTm9JU0ErIFZHQS0gTUFib3J0LSA+
UmVzZXQtIEZhc3RCMkItDQoJCVByaURpc2NUbXItIFNlY0Rpc2NUbXItIERpc2NUbXJTdGF0
LSBEaXNjVG1yU0VSUkVuLQ0KDQowMDoxNC41IFVTQiBjb250cm9sbGVyIFswYzAzXTogQVRJ
IFRlY2hub2xvZ2llcyBJbmMgU0I3eDAvU0I4eDAvU0I5eDAgVVNCIE9IQ0kyIENvbnRyb2xs
ZXIgWzEwMDI6NDM5OV0gKHByb2ctaWYgMTAgW09IQ0ldKQ0KCVN1YnN5c3RlbTogTWljcm8t
U3RhciBJbnRlcm5hdGlvbmFsIENvLiwgTHRkLiBEZXZpY2UgWzE0NjI6NzY0MF0NCglDb250
cm9sOiBJL08rIE1lbSsgQnVzTWFzdGVyKyBTcGVjQ3ljbGUtIE1lbVdJTlYrIFZHQVNub29w
LSBQYXJFcnItIFN0ZXBwaW5nLSBTRVJSKyBGYXN0QjJCLSBEaXNJTlR4LQ0KCVN0YXR1czog
Q2FwLSA2Nk1IeisgVURGLSBGYXN0QjJCKyBQYXJFcnItIERFVlNFTD1tZWRpdW0gPlRBYm9y
dC0gPFRBYm9ydC0gPE1BYm9ydC0gPlNFUlItIDxQRVJSLSBJTlR4LQ0KCUxhdGVuY3k6IDY0
LCBDYWNoZSBMaW5lIFNpemU6IDY0IGJ5dGVzDQoJSW50ZXJydXB0OiBwaW4gQyByb3V0ZWQg
dG8gSVJRIDE4DQoJUmVnaW9uIDA6IE1lbW9yeSBhdCBmOTNmZDAwMCAoMzItYml0LCBub24t
cHJlZmV0Y2hhYmxlKSBbc2l6ZT00S10NCglLZXJuZWwgZHJpdmVyIGluIHVzZTogb2hjaV9o
Y2QNCg0KMDA6MTUuMCBQQ0kgYnJpZGdlIFswNjA0XTogQVRJIFRlY2hub2xvZ2llcyBJbmMg
U0I3MDAvU0I4MDAvU0I5MDAgUENJIHRvIFBDSSBicmlkZ2UgKFBDSUUgcG9ydCAwKSBbMTAw
Mjo0M2EwXSAocHJvZy1pZiAwMCBbTm9ybWFsIGRlY29kZV0pDQoJQ29udHJvbDogSS9PLSBN
ZW0tIEJ1c01hc3RlcisgU3BlY0N5Y2xlLSBNZW1XSU5WLSBWR0FTbm9vcC0gUGFyRXJyLSBT
dGVwcGluZy0gU0VSUisgRmFzdEIyQi0gRGlzSU5UeCsNCglTdGF0dXM6IENhcCsgNjZNSHot
IFVERi0gRmFzdEIyQi0gUGFyRXJyLSBERVZTRUw9ZmFzdCA+VEFib3J0LSA8VEFib3J0LSA8
TUFib3J0LSA+U0VSUi0gPFBFUlItIElOVHgtDQoJTGF0ZW5jeTogMCwgQ2FjaGUgTGluZSBT
aXplOiA2NCBieXRlcw0KCUJ1czogcHJpbWFyeT0wMCwgc2Vjb25kYXJ5PTAyLCBzdWJvcmRp
bmF0ZT0wMiwgc2VjLWxhdGVuY3k9MA0KCUkvTyBiZWhpbmQgYnJpZGdlOiAwMDAwZjAwMC0w
MDAwMGZmZg0KCU1lbW9yeSBiZWhpbmQgYnJpZGdlOiBmZmYwMDAwMC0wMDBmZmZmZg0KCVBy
ZWZldGNoYWJsZSBtZW1vcnkgYmVoaW5kIGJyaWRnZTogMDAwMDAwMDBmZmYwMDAwMC0wMDAw
MDAwMDAwMGZmZmZmDQoJU2Vjb25kYXJ5IHN0YXR1czogNjZNSHotIEZhc3RCMkItIFBhckVy
ci0gREVWU0VMPWZhc3QgPlRBYm9ydC0gPFRBYm9ydC0gPE1BYm9ydC0gPFNFUlItIDxQRVJS
LQ0KCUJyaWRnZUN0bDogUGFyaXR5KyBTRVJSKyBOb0lTQSsgVkdBLSBNQWJvcnQtID5SZXNl
dC0gRmFzdEIyQi0NCgkJUHJpRGlzY1Rtci0gU2VjRGlzY1Rtci0gRGlzY1RtclN0YXQtIERp
c2NUbXJTRVJSRW4tDQoJQ2FwYWJpbGl0aWVzOiBbNTBdIFBvd2VyIE1hbmFnZW1lbnQgdmVy
c2lvbiAzDQoJCUZsYWdzOiBQTUVDbGstIERTSS0gRDErIEQyKyBBdXhDdXJyZW50PTBtQSBQ
TUUoRDAtLEQxLSxEMi0sRDNob3QtLEQzY29sZC0pDQoJCVN0YXR1czogRDAgTm9Tb2Z0UnN0
LSBQTUUtRW5hYmxlLSBEU2VsPTAgRFNjYWxlPTAgUE1FLQ0KCUNhcGFiaWxpdGllczogWzU4
XSBFeHByZXNzICh2MikgUm9vdCBQb3J0IChTbG90KyksIE1TSSAwMA0KCQlEZXZDYXA6CU1h
eFBheWxvYWQgMTI4IGJ5dGVzLCBQaGFudEZ1bmMgMCwgTGF0ZW5jeSBMMHMgPDY0bnMsIEwx
IDwxdXMNCgkJCUV4dFRhZysgUkJFKyBGTFJlc2V0LQ0KCQlEZXZDdGw6CVJlcG9ydCBlcnJv
cnM6IENvcnJlY3RhYmxlLSBOb24tRmF0YWwtIEZhdGFsLSBVbnN1cHBvcnRlZC0NCgkJCVJs
eGRPcmQrIEV4dFRhZy0gUGhhbnRGdW5jLSBBdXhQd3ItIE5vU25vb3ArDQoJCQlNYXhQYXls
b2FkIDEyOCBieXRlcywgTWF4UmVhZFJlcSAxMjggYnl0ZXMNCgkJRGV2U3RhOglDb3JyRXJy
LSBVbmNvcnJFcnItIEZhdGFsRXJyLSBVbnN1cHBSZXEtIEF1eFB3ci0gVHJhbnNQZW5kLQ0K
CQlMbmtDYXA6CVBvcnQgIzI0NywgU3BlZWQgMi41R1QvcywgV2lkdGggeDEsIEFTUE0gTDBz
IEwxLCBMYXRlbmN5IEwwIDw2NG5zLCBMMSA8MXVzDQoJCQlDbG9ja1BNLSBTdXJwcmlzZS0g
TExBY3RSZXArIEJ3Tm90Kw0KCQlMbmtDdGw6CUFTUE0gRGlzYWJsZWQ7IFJDQiA2NCBieXRl
cyBEaXNhYmxlZC0gUmV0cmFpbi0gQ29tbUNsay0NCgkJCUV4dFN5bmNoLSBDbG9ja1BNLSBB
dXRXaWREaXMtIEJXSW50LSBBdXRCV0ludC0NCgkJTG5rU3RhOglTcGVlZCB1bmtub3duLCBX
aWR0aCB4MTYsIFRyRXJyLSBUcmFpbi0gU2xvdENsaysgRExBY3RpdmUtIEJXTWdtdC0gQUJX
TWdtdC0NCgkJU2x0Q2FwOglBdHRuQnRuLSBQd3JDdHJsLSBNUkwtIEF0dG5JbmQtIFB3cklu
ZC0gSG90UGx1Zy0gU3VycHJpc2UtDQoJCQlTbG90ICMzMiwgUG93ZXJMaW1pdCA3NS4wMDBX
OyBJbnRlcmxvY2stIE5vQ29tcGwrDQoJCVNsdEN0bDoJRW5hYmxlOiBBdHRuQnRuLSBQd3JG
bHQtIE1STC0gUHJlc0RldC0gQ21kQ3BsdC0gSFBJcnEtIExpbmtDaGctDQoJCQlDb250cm9s
OiBBdHRuSW5kIFVua25vd24sIFB3ckluZCBVbmtub3duLCBQb3dlci0gSW50ZXJsb2NrLQ0K
CQlTbHRTdGE6CVN0YXR1czogQXR0bkJ0bi0gUG93ZXJGbHQtIE1STC0gQ21kQ3BsdC0gUHJl
c0RldC0gSW50ZXJsb2NrLQ0KCQkJQ2hhbmdlZDogTVJMLSBQcmVzRGV0LSBMaW5rU3RhdGUt
DQoJCVJvb3RDdGw6IEVyckNvcnJlY3RhYmxlLSBFcnJOb24tRmF0YWwtIEVyckZhdGFsLSBQ
TUVJbnRFbmEtIENSU1Zpc2libGUtDQoJCVJvb3RDYXA6IENSU1Zpc2libGUtDQoJCVJvb3RT
dGE6IFBNRSBSZXFJRCAwMDAwLCBQTUVTdGF0dXMtIFBNRVBlbmRpbmctDQoJCURldkNhcDI6
IENvbXBsZXRpb24gVGltZW91dDogUmFuZ2UgQUJDRCwgVGltZW91dERpcysgQVJJRndkLQ0K
CQlEZXZDdGwyOiBDb21wbGV0aW9uIFRpbWVvdXQ6IDY1bXMgdG8gMjEwbXMsIFRpbWVvdXRE
aXMtIEFSSUZ3ZC0NCgkJTG5rQ3RsMjogVGFyZ2V0IExpbmsgU3BlZWQ6IDIuNUdUL3MsIEVu
dGVyQ29tcGxpYW5jZS0gU3BlZWREaXMtLCBTZWxlY3RhYmxlIERlLWVtcGhhc2lzOiAtMy41
ZEINCgkJCSBUcmFuc21pdCBNYXJnaW46IE5vcm1hbCBPcGVyYXRpbmcgUmFuZ2UsIEVudGVy
TW9kaWZpZWRDb21wbGlhbmNlLSBDb21wbGlhbmNlU09TLQ0KCQkJIENvbXBsaWFuY2UgRGUt
ZW1waGFzaXM6IC02ZEINCgkJTG5rU3RhMjogQ3VycmVudCBEZS1lbXBoYXNpcyBMZXZlbDog
LTZkQg0KCUNhcGFiaWxpdGllczogW2EwXSBNU0k6IEVuYWJsZSsgQ291bnQ9MS8xIE1hc2th
YmxlLSA2NGJpdCsNCgkJQWRkcmVzczogMDAwMDAwMDBmZWUzZjAwYyAgRGF0YTogNDE5MQ0K
CUNhcGFiaWxpdGllczogW2IwXSBTdWJzeXN0ZW06IEFUSSBUZWNobm9sb2dpZXMgSW5jIERl
dmljZSBbMTAwMjowMDAwXQ0KCUNhcGFiaWxpdGllczogW2I4XSBIeXBlclRyYW5zcG9ydDog
TVNJIE1hcHBpbmcgRW5hYmxlKyBGaXhlZCsNCglDYXBhYmlsaXRpZXM6IFsxMDAgdjFdIFZl
bmRvciBTcGVjaWZpYyBJbmZvcm1hdGlvbjogSUQ9MDAwMSBSZXY9MSBMZW49MDEwIDw/Pg0K
CUtlcm5lbCBkcml2ZXIgaW4gdXNlOiBwY2llcG9ydA0KDQowMDoxNi4wIFVTQiBjb250cm9s
bGVyIFswYzAzXTogQVRJIFRlY2hub2xvZ2llcyBJbmMgU0I3eDAvU0I4eDAvU0I5eDAgVVNC
IE9IQ0kwIENvbnRyb2xsZXIgWzEwMDI6NDM5N10gKHByb2ctaWYgMTAgW09IQ0ldKQ0KCVN1
YnN5c3RlbTogTWljcm8tU3RhciBJbnRlcm5hdGlvbmFsIENvLiwgTHRkLiBEZXZpY2UgWzE0
NjI6NzY0MF0NCglDb250cm9sOiBJL08rIE1lbSsgQnVzTWFzdGVyKyBTcGVjQ3ljbGUtIE1l
bVdJTlYrIFZHQVNub29wLSBQYXJFcnItIFN0ZXBwaW5nLSBTRVJSKyBGYXN0QjJCLSBEaXNJ
TlR4LQ0KCVN0YXR1czogQ2FwLSA2Nk1IeisgVURGLSBGYXN0QjJCKyBQYXJFcnItIERFVlNF
TD1tZWRpdW0gPlRBYm9ydC0gPFRBYm9ydC0gPE1BYm9ydC0gPlNFUlItIDxQRVJSLSBJTlR4
LQ0KCUxhdGVuY3k6IDY0LCBDYWNoZSBMaW5lIFNpemU6IDY0IGJ5dGVzDQoJSW50ZXJydXB0
OiBwaW4gQSByb3V0ZWQgdG8gSVJRIDE4DQoJUmVnaW9uIDA6IE1lbW9yeSBhdCBmOTNmZTAw
MCAoMzItYml0LCBub24tcHJlZmV0Y2hhYmxlKSBbc2l6ZT00S10NCglLZXJuZWwgZHJpdmVy
IGluIHVzZTogb2hjaV9oY2QNCg0KMDA6MTYuMiBVU0IgY29udHJvbGxlciBbMGMwM106IEFU
SSBUZWNobm9sb2dpZXMgSW5jIFNCN3gwL1NCOHgwL1NCOXgwIFVTQiBFSENJIENvbnRyb2xs
ZXIgWzEwMDI6NDM5Nl0gKHByb2ctaWYgMjAgW0VIQ0ldKQ0KCVN1YnN5c3RlbTogTWljcm8t
U3RhciBJbnRlcm5hdGlvbmFsIENvLiwgTHRkLiBEZXZpY2UgWzE0NjI6NzY0MF0NCglDb250
cm9sOiBJL08tIE1lbSsgQnVzTWFzdGVyKyBTcGVjQ3ljbGUtIE1lbVdJTlYrIFZHQVNub29w
LSBQYXJFcnItIFN0ZXBwaW5nLSBTRVJSKyBGYXN0QjJCLSBEaXNJTlR4LQ0KCVN0YXR1czog
Q2FwKyA2Nk1IeisgVURGLSBGYXN0QjJCKyBQYXJFcnItIERFVlNFTD1tZWRpdW0gPlRBYm9y
dC0gPFRBYm9ydC0gPE1BYm9ydC0gPlNFUlItIDxQRVJSLSBJTlR4LQ0KCUxhdGVuY3k6IDY0
LCBDYWNoZSBMaW5lIFNpemU6IDY0IGJ5dGVzDQoJSW50ZXJydXB0OiBwaW4gQiByb3V0ZWQg
dG8gSVJRIDE3DQoJUmVnaW9uIDA6IE1lbW9yeSBhdCBmOTNmZmMwMCAoMzItYml0LCBub24t
cHJlZmV0Y2hhYmxlKSBbc2l6ZT0yNTZdDQoJQ2FwYWJpbGl0aWVzOiBbYzBdIFBvd2VyIE1h
bmFnZW1lbnQgdmVyc2lvbiAyDQoJCUZsYWdzOiBQTUVDbGstIERTSS0gRDErIEQyKyBBdXhD
dXJyZW50PTBtQSBQTUUoRDArLEQxKyxEMissRDNob3QrLEQzY29sZC0pDQoJCVN0YXR1czog
RDAgTm9Tb2Z0UnN0LSBQTUUtRW5hYmxlLSBEU2VsPTAgRFNjYWxlPTAgUE1FLQ0KCQlCcmlk
Z2U6IFBNLSBCMysNCglDYXBhYmlsaXRpZXM6IFtlNF0gRGVidWcgcG9ydDogQkFSPTEgb2Zm
c2V0PTAwZTANCglLZXJuZWwgZHJpdmVyIGluIHVzZTogZWhjaV9oY2QNCg0KMDA6MTguMCBI
b3N0IGJyaWRnZSBbMDYwMF06IEFkdmFuY2VkIE1pY3JvIERldmljZXMgW0FNRF0gRmFtaWx5
IDEwaCBQcm9jZXNzb3IgSHlwZXJUcmFuc3BvcnQgQ29uZmlndXJhdGlvbiBbMTAyMjoxMjAw
XQ0KCUNvbnRyb2w6IEkvTy0gTWVtLSBCdXNNYXN0ZXItIFNwZWNDeWNsZS0gTWVtV0lOVi0g
VkdBU25vb3AtIFBhckVyci0gU3RlcHBpbmctIFNFUlItIEZhc3RCMkItIERpc0lOVHgtDQoJ
U3RhdHVzOiBDYXArIDY2TUh6LSBVREYtIEZhc3RCMkItIFBhckVyci0gREVWU0VMPWZhc3Qg
PlRBYm9ydC0gPFRBYm9ydC0gPE1BYm9ydC0gPlNFUlItIDxQRVJSLSBJTlR4LQ0KCUNhcGFi
aWxpdGllczogWzgwXSBIeXBlclRyYW5zcG9ydDogSG9zdCBvciBTZWNvbmRhcnkgSW50ZXJm
YWNlDQoJCUNvbW1hbmQ6IFdhcm1Sc3QrIERibEVuZC0gRGV2TnVtPTAgQ2hhaW5TaWRlLSBI
b3N0SGlkZSsgU2xhdmUtIDxFT0NFcnItIERVTC0NCgkJTGluayBDb250cm9sOiBDRmxFLSBD
U1QtIENGRS0gPExrRmFpbC0gSW5pdCsgRU9DLSBUWE8tIDxDUkNFcnI9MCBJc29jRW4tIExT
RW4rIEV4dENUTC0gNjRiLQ0KCQlMaW5rIENvbmZpZzogTUxXST0xNmJpdCBEd0ZjSW4tIE1M
V089MTZiaXQgRHdGY091dC0gTFdJPTE2Yml0IER3RmNJbkVuLSBMV089MTZiaXQgRHdGY091
dEVuLQ0KCQlSZXZpc2lvbiBJRDogMy4wMA0KCQlMaW5rIEZyZXF1ZW5jeTogW2JdDQoJCUxp
bmsgRXJyb3I6IDxQcm90LSA8T3ZmbC0gPEVPQy0gQ1RMVG0tDQoJCUxpbmsgRnJlcXVlbmN5
IENhcGFiaWxpdHk6IDIwME1IeisgMzAwTUh6LSA0MDBNSHorIDUwME1Iei0gNjAwTUh6KyA4
MDBNSHorIDEuMEdIeisgMS4yR0h6KyAxLjRHSHotIDEuNkdIei0gVmVuZC0NCgkJRmVhdHVy
ZSBDYXBhYmlsaXR5OiBJc29jRkMrIExEVFNUT1ArIENSQ1RNLSBFQ1RMVC0gNjRiQSsgVUlE
UkQtIEV4dFJTLSBVQ25mRS0NCg0KMDA6MTguMSBIb3N0IGJyaWRnZSBbMDYwMF06IEFkdmFu
Y2VkIE1pY3JvIERldmljZXMgW0FNRF0gRmFtaWx5IDEwaCBQcm9jZXNzb3IgQWRkcmVzcyBN
YXAgWzEwMjI6MTIwMV0NCglDb250cm9sOiBJL08tIE1lbS0gQnVzTWFzdGVyLSBTcGVjQ3lj
bGUtIE1lbVdJTlYtIFZHQVNub29wLSBQYXJFcnItIFN0ZXBwaW5nLSBTRVJSLSBGYXN0QjJC
LSBEaXNJTlR4LQ0KCVN0YXR1czogQ2FwLSA2Nk1Iei0gVURGLSBGYXN0QjJCLSBQYXJFcnIt
IERFVlNFTD1mYXN0ID5UQWJvcnQtIDxUQWJvcnQtIDxNQWJvcnQtID5TRVJSLSA8UEVSUi0g
SU5UeC0NCg0KMDA6MTguMiBIb3N0IGJyaWRnZSBbMDYwMF06IEFkdmFuY2VkIE1pY3JvIERl
dmljZXMgW0FNRF0gRmFtaWx5IDEwaCBQcm9jZXNzb3IgRFJBTSBDb250cm9sbGVyIFsxMDIy
OjEyMDJdDQoJQ29udHJvbDogSS9PLSBNZW0tIEJ1c01hc3Rlci0gU3BlY0N5Y2xlLSBNZW1X
SU5WLSBWR0FTbm9vcC0gUGFyRXJyLSBTdGVwcGluZy0gU0VSUi0gRmFzdEIyQi0gRGlzSU5U
eC0NCglTdGF0dXM6IENhcC0gNjZNSHotIFVERi0gRmFzdEIyQi0gUGFyRXJyLSBERVZTRUw9
ZmFzdCA+VEFib3J0LSA8VEFib3J0LSA8TUFib3J0LSA+U0VSUi0gPFBFUlItIElOVHgtDQoN
CjAwOjE4LjMgSG9zdCBicmlkZ2UgWzA2MDBdOiBBZHZhbmNlZCBNaWNybyBEZXZpY2VzIFtB
TURdIEZhbWlseSAxMGggUHJvY2Vzc29yIE1pc2NlbGxhbmVvdXMgQ29udHJvbCBbMTAyMjox
MjAzXQ0KCUNvbnRyb2w6IEkvTy0gTWVtLSBCdXNNYXN0ZXItIFNwZWNDeWNsZS0gTWVtV0lO
Vi0gVkdBU25vb3AtIFBhckVyci0gU3RlcHBpbmctIFNFUlItIEZhc3RCMkItIERpc0lOVHgt
DQoJU3RhdHVzOiBDYXArIDY2TUh6LSBVREYtIEZhc3RCMkItIFBhckVyci0gREVWU0VMPWZh
c3QgPlRBYm9ydC0gPFRBYm9ydC0gPE1BYm9ydC0gPlNFUlItIDxQRVJSLSBJTlR4LQ0KCUNh
cGFiaWxpdGllczogW2YwXSBTZWN1cmUgZGV2aWNlIDw/Pg0KCUtlcm5lbCBkcml2ZXIgaW4g
dXNlOiBrMTB0ZW1wDQoNCjAwOjE4LjQgSG9zdCBicmlkZ2UgWzA2MDBdOiBBZHZhbmNlZCBN
aWNybyBEZXZpY2VzIFtBTURdIEZhbWlseSAxMGggUHJvY2Vzc29yIExpbmsgQ29udHJvbCBb
MTAyMjoxMjA0XQ0KCUNvbnRyb2w6IEkvTy0gTWVtLSBCdXNNYXN0ZXItIFNwZWNDeWNsZS0g
TWVtV0lOVi0gVkdBU25vb3AtIFBhckVyci0gU3RlcHBpbmctIFNFUlItIEZhc3RCMkItIERp
c0lOVHgtDQoJU3RhdHVzOiBDYXAtIDY2TUh6LSBVREYtIEZhc3RCMkItIFBhckVyci0gREVW
U0VMPWZhc3QgPlRBYm9ydC0gPFRBYm9ydC0gPE1BYm9ydC0gPlNFUlItIDxQRVJSLSBJTlR4
LQ0KDQowMzowNi4wIE11bHRpbWVkaWEgYXVkaW8gY29udHJvbGxlciBbMDQwMV06IEMtTWVk
aWEgRWxlY3Ryb25pY3MgSW5jIENNODczOCBbMTNmNjowMTExXSAocmV2IDEwKQ0KCVN1YnN5
c3RlbTogQy1NZWRpYSBFbGVjdHJvbmljcyBJbmMgQ01JODczOC9DM0RYIFBDSSBBdWRpbyBE
ZXZpY2UgWzEzZjY6MDExMV0NCglDb250cm9sOiBJL08rIE1lbS0gQnVzTWFzdGVyKyBTcGVj
Q3ljbGUtIE1lbVdJTlYtIFZHQVNub29wLSBQYXJFcnItIFN0ZXBwaW5nLSBTRVJSLSBGYXN0
QjJCLSBEaXNJTlR4LQ0KCVN0YXR1czogQ2FwKyA2Nk1Iei0gVURGLSBGYXN0QjJCLSBQYXJF
cnItIERFVlNFTD1tZWRpdW0gPlRBYm9ydC0gPFRBYm9ydC0gPE1BYm9ydC0gPlNFUlItIDxQ
RVJSLSBJTlR4LQ0KCUxhdGVuY3k6IDY0ICg1MDBucyBtaW4sIDYwMDBucyBtYXgpDQoJSW50
ZXJydXB0OiBwaW4gQSByb3V0ZWQgdG8gSVJRIDIyDQoJUmVnaW9uIDA6IEkvTyBwb3J0cyBh
dCBhODAwIFtzaXplPTI1Nl0NCglDYXBhYmlsaXRpZXM6IFtjMF0gUG93ZXIgTWFuYWdlbWVu
dCB2ZXJzaW9uIDINCgkJRmxhZ3M6IFBNRUNsay0gRFNJLSBEMSsgRDIrIEF1eEN1cnJlbnQ9
MG1BIFBNRShEMC0sRDEtLEQyLSxEM2hvdC0sRDNjb2xkLSkNCgkJU3RhdHVzOiBEMCBOb1Nv
ZnRSc3QtIFBNRS1FbmFibGUtIERTZWw9MCBEU2NhbGU9MCBQTUUtDQoJS2VybmVsIGRyaXZl
ciBpbiB1c2U6IHBjaWJhY2sNCg0KMDQ6MDAuMCBVU0IgY29udHJvbGxlciBbMGMwM106IE5l
dE1vcyBUZWNobm9sb2d5IE1DUzk5OTAgUENJZSB0byA04oCQUG9ydCBVU0IgMi4wIEhvc3Qg
Q29udHJvbGxlciBbOTcxMDo5OTkwXSAocHJvZy1pZiAxMCBbT0hDSV0pDQoJU3Vic3lzdGVt
OiBEZXZpY2UgW2EwMDA6NDAwMF0NCglDb250cm9sOiBJL08tIE1lbS0gQnVzTWFzdGVyLSBT
cGVjQ3ljbGUtIE1lbVdJTlYtIFZHQVNub29wLSBQYXJFcnItIFN0ZXBwaW5nLSBTRVJSLSBG
YXN0QjJCLSBEaXNJTlR4LQ0KCVN0YXR1czogQ2FwKyA2Nk1Iei0gVURGLSBGYXN0QjJCLSBQ
YXJFcnItIERFVlNFTD1mYXN0ID5UQWJvcnQtIDxUQWJvcnQtIDxNQWJvcnQtID5TRVJSLSA8
UEVSUi0gSU5UeC0NCglJbnRlcnJ1cHQ6IHBpbiBBIHJvdXRlZCB0byBJUlEgNDANCglSZWdp
b24gMDogTWVtb3J5IGF0IGY5NWY4MDAwICgzMi1iaXQsIG5vbi1wcmVmZXRjaGFibGUpIFtk
aXNhYmxlZF0gW3NpemU9NEtdDQoJQ2FwYWJpbGl0aWVzOiBbNTBdIE1TSTogRW5hYmxlLSBD
b3VudD0xLzEgTWFza2FibGUtIDY0Yml0Kw0KCQlBZGRyZXNzOiAwMDAwMDAwMDAwMDAwMDAw
ICBEYXRhOiAwMDAwDQoJQ2FwYWJpbGl0aWVzOiBbNzhdIFBvd2VyIE1hbmFnZW1lbnQgdmVy
c2lvbiAzDQoJCUZsYWdzOiBQTUVDbGstIERTSS0gRDErIEQyKyBBdXhDdXJyZW50PTM3NW1B
IFBNRShEMCssRDErLEQyKyxEM2hvdCssRDNjb2xkLSkNCgkJU3RhdHVzOiBEMCBOb1NvZnRS
c3QrIFBNRS1FbmFibGUtIERTZWw9MCBEU2NhbGU9MCBQTUUtDQoJQ2FwYWJpbGl0aWVzOiBb
ODBdIEV4cHJlc3MgKHYxKSBFbmRwb2ludCwgTVNJIDAwDQoJCURldkNhcDoJTWF4UGF5bG9h
ZCAyNTYgYnl0ZXMsIFBoYW50RnVuYyAwLCBMYXRlbmN5IEwwcyB1bmxpbWl0ZWQsIEwxIHVu
bGltaXRlZA0KCQkJRXh0VGFnLSBBdHRuQnRuLSBBdHRuSW5kLSBQd3JJbmQtIFJCRSsgRkxS
ZXNldC0NCgkJRGV2Q3RsOglSZXBvcnQgZXJyb3JzOiBDb3JyZWN0YWJsZS0gTm9uLUZhdGFs
LSBGYXRhbC0gVW5zdXBwb3J0ZWQtDQoJCQlSbHhkT3JkLSBFeHRUYWctIFBoYW50RnVuYy0g
QXV4UHdyLSBOb1Nub29wKw0KCQkJTWF4UGF5bG9hZCAxMjggYnl0ZXMsIE1heFJlYWRSZXEg
NTEyIGJ5dGVzDQoJCURldlN0YToJQ29yckVyci0gVW5jb3JyRXJyLSBGYXRhbEVyci0gVW5z
dXBwUmVxLSBBdXhQd3ItIFRyYW5zUGVuZC0NCgkJTG5rQ2FwOglQb3J0ICMxLCBTcGVlZCAy
LjVHVC9zLCBXaWR0aCB4MSwgQVNQTSB1bmtub3duLCBMYXRlbmN5IEwwIDw2NG5zLCBMMSB1
bmxpbWl0ZWQNCgkJCUNsb2NrUE0rIFN1cnByaXNlLSBMTEFjdFJlcC0gQndOb3QtDQoJCUxu
a0N0bDoJQVNQTSBEaXNhYmxlZDsgUkNCIDY0IGJ5dGVzIERpc2FibGVkLSBSZXRyYWluLSBD
b21tQ2xrLQ0KCQkJRXh0U3luY2gtIENsb2NrUE0tIEF1dFdpZERpcy0gQldJbnQtIEF1dEJX
SW50LQ0KCQlMbmtTdGE6CVNwZWVkIDIuNUdUL3MsIFdpZHRoIHgxLCBUckVyci0gVHJhaW4t
IFNsb3RDbGstIERMQWN0aXZlLSBCV01nbXQtIEFCV01nbXQtDQoJQ2FwYWJpbGl0aWVzOiBb
MTAwIHYxXSBWaXJ0dWFsIENoYW5uZWwNCgkJQ2FwczoJTFBFVkM9MCBSZWZDbGs9MTAwbnMg
UEFURW50cnlCaXRzPTENCgkJQXJiOglGaXhlZC0gV1JSMzItIFdSUjY0LSBXUlIxMjgtDQoJ
CUN0cmw6CUFyYlNlbGVjdD1GaXhlZA0KCQlTdGF0dXM6CUluUHJvZ3Jlc3MtDQoJCVZDMDoJ
Q2FwczoJUEFUT2Zmc2V0PTAwIE1heFRpbWVTbG90cz0xIFJlalNub29wVHJhbnMtDQoJCQlB
cmI6CUZpeGVkLSBXUlIzMi0gV1JSNjQtIFdSUjEyOC0gVFdSUjEyOC0gV1JSMjU2LQ0KCQkJ
Q3RybDoJRW5hYmxlKyBJRD0wIEFyYlNlbGVjdD1GaXhlZCBUQy9WQz1mZg0KCQkJU3RhdHVz
OglOZWdvUGVuZGluZy0gSW5Qcm9ncmVzcy0NCglLZXJuZWwgZHJpdmVyIGluIHVzZTogcGNp
YmFjaw0KDQowNDowMC4xIFVTQiBjb250cm9sbGVyIFswYzAzXTogTmV0TW9zIFRlY2hub2xv
Z3kgTUNTOTk5MCBQQ0llIHRvIDTigJBQb3J0IFVTQiAyLjAgSG9zdCBDb250cm9sbGVyIFs5
NzEwOjk5OTBdIChwcm9nLWlmIDIwIFtFSENJXSkNCglTdWJzeXN0ZW06IERldmljZSBbYTAw
MDo0MDAwXQ0KCUNvbnRyb2w6IEkvTy0gTWVtLSBCdXNNYXN0ZXItIFNwZWNDeWNsZS0gTWVt
V0lOVi0gVkdBU25vb3AtIFBhckVyci0gU3RlcHBpbmctIFNFUlItIEZhc3RCMkItIERpc0lO
VHgtDQoJU3RhdHVzOiBDYXArIDY2TUh6LSBVREYtIEZhc3RCMkItIFBhckVyci0gREVWU0VM
PWZhc3QgPlRBYm9ydC0gPFRBYm9ydC0gPE1BYm9ydC0gPlNFUlItIDxQRVJSLSBJTlR4LQ0K
CUludGVycnVwdDogcGluIEEgcm91dGVkIHRvIElSUSA0MA0KCVJlZ2lvbiAwOiBNZW1vcnkg
YXQgZjk1ZjkwMDAgKDMyLWJpdCwgbm9uLXByZWZldGNoYWJsZSkgW2Rpc2FibGVkXSBbc2l6
ZT00S10NCglDYXBhYmlsaXRpZXM6IFs1MF0gTVNJOiBFbmFibGUtIENvdW50PTEvMSBNYXNr
YWJsZS0gNjRiaXQrDQoJCUFkZHJlc3M6IDAwMDAwMDAwMDAwMDAwMDAgIERhdGE6IDAwMDAN
CglDYXBhYmlsaXRpZXM6IFs3OF0gUG93ZXIgTWFuYWdlbWVudCB2ZXJzaW9uIDMNCgkJRmxh
Z3M6IFBNRUNsay0gRFNJLSBEMSsgRDIrIEF1eEN1cnJlbnQ9Mzc1bUEgUE1FKEQwKyxEMSss
RDIrLEQzaG90KyxEM2NvbGQtKQ0KCQlTdGF0dXM6IEQwIE5vU29mdFJzdCsgUE1FLUVuYWJs
ZS0gRFNlbD0wIERTY2FsZT0wIFBNRS0NCglDYXBhYmlsaXRpZXM6IFs4MF0gRXhwcmVzcyAo
djEpIEVuZHBvaW50LCBNU0kgMDANCgkJRGV2Q2FwOglNYXhQYXlsb2FkIDI1NiBieXRlcywg
UGhhbnRGdW5jIDAsIExhdGVuY3kgTDBzIHVubGltaXRlZCwgTDEgdW5saW1pdGVkDQoJCQlF
eHRUYWctIEF0dG5CdG4tIEF0dG5JbmQtIFB3ckluZC0gUkJFKyBGTFJlc2V0LQ0KCQlEZXZD
dGw6CVJlcG9ydCBlcnJvcnM6IENvcnJlY3RhYmxlLSBOb24tRmF0YWwtIEZhdGFsLSBVbnN1
cHBvcnRlZC0NCgkJCVJseGRPcmQtIEV4dFRhZy0gUGhhbnRGdW5jLSBBdXhQd3ItIE5vU25v
b3ArDQoJCQlNYXhQYXlsb2FkIDEyOCBieXRlcywgTWF4UmVhZFJlcSA1MTIgYnl0ZXMNCgkJ
RGV2U3RhOglDb3JyRXJyLSBVbmNvcnJFcnItIEZhdGFsRXJyLSBVbnN1cHBSZXEtIEF1eFB3
ci0gVHJhbnNQZW5kLQ0KCQlMbmtDYXA6CVBvcnQgIzEsIFNwZWVkIDIuNUdUL3MsIFdpZHRo
IHgxLCBBU1BNIHVua25vd24sIExhdGVuY3kgTDAgPDY0bnMsIEwxIHVubGltaXRlZA0KCQkJ
Q2xvY2tQTSsgU3VycHJpc2UtIExMQWN0UmVwLSBCd05vdC0NCgkJTG5rQ3RsOglBU1BNIERp
c2FibGVkOyBSQ0IgNjQgYnl0ZXMgRGlzYWJsZWQtIFJldHJhaW4tIENvbW1DbGstDQoJCQlF
eHRTeW5jaC0gQ2xvY2tQTS0gQXV0V2lkRGlzLSBCV0ludC0gQXV0QldJbnQtDQoJCUxua1N0
YToJU3BlZWQgMi41R1QvcywgV2lkdGggeDEsIFRyRXJyLSBUcmFpbi0gU2xvdENsay0gRExB
Y3RpdmUtIEJXTWdtdC0gQUJXTWdtdC0NCglLZXJuZWwgZHJpdmVyIGluIHVzZTogcGNpYmFj
aw0KDQowNDowMC4yIFVTQiBjb250cm9sbGVyIFswYzAzXTogTmV0TW9zIFRlY2hub2xvZ3kg
TUNTOTk5MCBQQ0llIHRvIDTigJBQb3J0IFVTQiAyLjAgSG9zdCBDb250cm9sbGVyIFs5NzEw
Ojk5OTBdIChwcm9nLWlmIDEwIFtPSENJXSkNCglTdWJzeXN0ZW06IERldmljZSBbYTAwMDo0
MDAwXQ0KCUNvbnRyb2w6IEkvTy0gTWVtLSBCdXNNYXN0ZXItIFNwZWNDeWNsZS0gTWVtV0lO
Vi0gVkdBU25vb3AtIFBhckVyci0gU3RlcHBpbmctIFNFUlItIEZhc3RCMkItIERpc0lOVHgt
DQoJU3RhdHVzOiBDYXArIDY2TUh6LSBVREYtIEZhc3RCMkItIFBhckVyci0gREVWU0VMPWZh
c3QgPlRBYm9ydC0gPFRBYm9ydC0gPE1BYm9ydC0gPlNFUlItIDxQRVJSLSBJTlR4LQ0KCUlu
dGVycnVwdDogcGluIEIgcm91dGVkIHRvIElSUSA0MQ0KCVJlZ2lvbiAwOiBNZW1vcnkgYXQg
Zjk1ZmEwMDAgKDMyLWJpdCwgbm9uLXByZWZldGNoYWJsZSkgW2Rpc2FibGVkXSBbc2l6ZT00
S10NCglDYXBhYmlsaXRpZXM6IFs1MF0gTVNJOiBFbmFibGUtIENvdW50PTEvMSBNYXNrYWJs
ZS0gNjRiaXQrDQoJCUFkZHJlc3M6IDAwMDAwMDAwMDAwMDAwMDAgIERhdGE6IDAwMDANCglD
YXBhYmlsaXRpZXM6IFs3OF0gUG93ZXIgTWFuYWdlbWVudCB2ZXJzaW9uIDMNCgkJRmxhZ3M6
IFBNRUNsay0gRFNJLSBEMSsgRDIrIEF1eEN1cnJlbnQ9Mzc1bUEgUE1FKEQwKyxEMSssRDIr
LEQzaG90KyxEM2NvbGQtKQ0KCQlTdGF0dXM6IEQwIE5vU29mdFJzdCsgUE1FLUVuYWJsZS0g
RFNlbD0wIERTY2FsZT0wIFBNRS0NCglDYXBhYmlsaXRpZXM6IFs4MF0gRXhwcmVzcyAodjEp
IEVuZHBvaW50LCBNU0kgMDANCgkJRGV2Q2FwOglNYXhQYXlsb2FkIDI1NiBieXRlcywgUGhh
bnRGdW5jIDAsIExhdGVuY3kgTDBzIHVubGltaXRlZCwgTDEgdW5saW1pdGVkDQoJCQlFeHRU
YWctIEF0dG5CdG4tIEF0dG5JbmQtIFB3ckluZC0gUkJFKyBGTFJlc2V0LQ0KCQlEZXZDdGw6
CVJlcG9ydCBlcnJvcnM6IENvcnJlY3RhYmxlLSBOb24tRmF0YWwtIEZhdGFsLSBVbnN1cHBv
cnRlZC0NCgkJCVJseGRPcmQtIEV4dFRhZy0gUGhhbnRGdW5jLSBBdXhQd3ItIE5vU25vb3Ar
DQoJCQlNYXhQYXlsb2FkIDEyOCBieXRlcywgTWF4UmVhZFJlcSA1MTIgYnl0ZXMNCgkJRGV2
U3RhOglDb3JyRXJyLSBVbmNvcnJFcnItIEZhdGFsRXJyLSBVbnN1cHBSZXEtIEF1eFB3ci0g
VHJhbnNQZW5kLQ0KCQlMbmtDYXA6CVBvcnQgIzEsIFNwZWVkIDIuNUdUL3MsIFdpZHRoIHgx
LCBBU1BNIHVua25vd24sIExhdGVuY3kgTDAgPDY0bnMsIEwxIHVubGltaXRlZA0KCQkJQ2xv
Y2tQTSsgU3VycHJpc2UtIExMQWN0UmVwLSBCd05vdC0NCgkJTG5rQ3RsOglBU1BNIERpc2Fi
bGVkOyBSQ0IgNjQgYnl0ZXMgRGlzYWJsZWQtIFJldHJhaW4tIENvbW1DbGstDQoJCQlFeHRT
eW5jaC0gQ2xvY2tQTS0gQXV0V2lkRGlzLSBCV0ludC0gQXV0QldJbnQtDQoJCUxua1N0YToJ
U3BlZWQgMi41R1QvcywgV2lkdGggeDEsIFRyRXJyLSBUcmFpbi0gU2xvdENsay0gRExBY3Rp
dmUtIEJXTWdtdC0gQUJXTWdtdC0NCglLZXJuZWwgZHJpdmVyIGluIHVzZTogcGNpYmFjaw0K
DQowNDowMC4zIFVTQiBjb250cm9sbGVyIFswYzAzXTogTmV0TW9zIFRlY2hub2xvZ3kgTUNT
OTk5MCBQQ0llIHRvIDTigJBQb3J0IFVTQiAyLjAgSG9zdCBDb250cm9sbGVyIFs5NzEwOjk5
OTBdIChwcm9nLWlmIDIwIFtFSENJXSkNCglTdWJzeXN0ZW06IERldmljZSBbYTAwMDo0MDAw
XQ0KCUNvbnRyb2w6IEkvTy0gTWVtLSBCdXNNYXN0ZXItIFNwZWNDeWNsZS0gTWVtV0lOVi0g
VkdBU25vb3AtIFBhckVyci0gU3RlcHBpbmctIFNFUlItIEZhc3RCMkItIERpc0lOVHgtDQoJ
U3RhdHVzOiBDYXArIDY2TUh6LSBVREYtIEZhc3RCMkItIFBhckVyci0gREVWU0VMPWZhc3Qg
PlRBYm9ydC0gPFRBYm9ydC0gPE1BYm9ydC0gPlNFUlItIDxQRVJSLSBJTlR4LQ0KCUludGVy
cnVwdDogcGluIEIgcm91dGVkIHRvIElSUSA0MQ0KCVJlZ2lvbiAwOiBNZW1vcnkgYXQgZjk1
ZmIwMDAgKDMyLWJpdCwgbm9uLXByZWZldGNoYWJsZSkgW2Rpc2FibGVkXSBbc2l6ZT00S10N
CglDYXBhYmlsaXRpZXM6IFs1MF0gTVNJOiBFbmFibGUtIENvdW50PTEvMSBNYXNrYWJsZS0g
NjRiaXQrDQoJCUFkZHJlc3M6IDAwMDAwMDAwMDAwMDAwMDAgIERhdGE6IDAwMDANCglDYXBh
YmlsaXRpZXM6IFs3OF0gUG93ZXIgTWFuYWdlbWVudCB2ZXJzaW9uIDMNCgkJRmxhZ3M6IFBN
RUNsay0gRFNJLSBEMSsgRDIrIEF1eEN1cnJlbnQ9Mzc1bUEgUE1FKEQwKyxEMSssRDIrLEQz
aG90KyxEM2NvbGQtKQ0KCQlTdGF0dXM6IEQwIE5vU29mdFJzdCsgUE1FLUVuYWJsZS0gRFNl
bD0wIERTY2FsZT0wIFBNRS0NCglDYXBhYmlsaXRpZXM6IFs4MF0gRXhwcmVzcyAodjEpIEVu
ZHBvaW50LCBNU0kgMDANCgkJRGV2Q2FwOglNYXhQYXlsb2FkIDI1NiBieXRlcywgUGhhbnRG
dW5jIDAsIExhdGVuY3kgTDBzIHVubGltaXRlZCwgTDEgdW5saW1pdGVkDQoJCQlFeHRUYWct
IEF0dG5CdG4tIEF0dG5JbmQtIFB3ckluZC0gUkJFKyBGTFJlc2V0LQ0KCQlEZXZDdGw6CVJl
cG9ydCBlcnJvcnM6IENvcnJlY3RhYmxlLSBOb24tRmF0YWwtIEZhdGFsLSBVbnN1cHBvcnRl
ZC0NCgkJCVJseGRPcmQtIEV4dFRhZy0gUGhhbnRGdW5jLSBBdXhQd3ItIE5vU25vb3ArDQoJ
CQlNYXhQYXlsb2FkIDEyOCBieXRlcywgTWF4UmVhZFJlcSA1MTIgYnl0ZXMNCgkJRGV2U3Rh
OglDb3JyRXJyLSBVbmNvcnJFcnItIEZhdGFsRXJyLSBVbnN1cHBSZXEtIEF1eFB3ci0gVHJh
bnNQZW5kLQ0KCQlMbmtDYXA6CVBvcnQgIzEsIFNwZWVkIDIuNUdUL3MsIFdpZHRoIHgxLCBB
U1BNIHVua25vd24sIExhdGVuY3kgTDAgPDY0bnMsIEwxIHVubGltaXRlZA0KCQkJQ2xvY2tQ
TSsgU3VycHJpc2UtIExMQWN0UmVwLSBCd05vdC0NCgkJTG5rQ3RsOglBU1BNIERpc2FibGVk
OyBSQ0IgNjQgYnl0ZXMgRGlzYWJsZWQtIFJldHJhaW4tIENvbW1DbGstDQoJCQlFeHRTeW5j
aC0gQ2xvY2tQTS0gQXV0V2lkRGlzLSBCV0ludC0gQXV0QldJbnQtDQoJCUxua1N0YToJU3Bl
ZWQgMi41R1QvcywgV2lkdGggeDEsIFRyRXJyLSBUcmFpbi0gU2xvdENsay0gRExBY3RpdmUt
IEJXTWdtdC0gQUJXTWdtdC0NCglLZXJuZWwgZHJpdmVyIGluIHVzZTogcGNpYmFjaw0KDQow
NDowMC40IFVTQiBjb250cm9sbGVyIFswYzAzXTogTmV0TW9zIFRlY2hub2xvZ3kgTUNTOTk5
MCBQQ0llIHRvIDTigJBQb3J0IFVTQiAyLjAgSG9zdCBDb250cm9sbGVyIFs5NzEwOjk5OTBd
IChwcm9nLWlmIDEwIFtPSENJXSkNCglTdWJzeXN0ZW06IERldmljZSBbYTAwMDo0MDAwXQ0K
CUNvbnRyb2w6IEkvTy0gTWVtLSBCdXNNYXN0ZXItIFNwZWNDeWNsZS0gTWVtV0lOVi0gVkdB
U25vb3AtIFBhckVyci0gU3RlcHBpbmctIFNFUlItIEZhc3RCMkItIERpc0lOVHgtDQoJU3Rh
dHVzOiBDYXArIDY2TUh6LSBVREYtIEZhc3RCMkItIFBhckVyci0gREVWU0VMPWZhc3QgPlRB
Ym9ydC0gPFRBYm9ydC0gPE1BYm9ydC0gPlNFUlItIDxQRVJSLSBJTlR4LQ0KCUludGVycnVw
dDogcGluIEMgcm91dGVkIHRvIElSUSA0Mg0KCVJlZ2lvbiAwOiBNZW1vcnkgYXQgZjk1ZmMw
MDAgKDMyLWJpdCwgbm9uLXByZWZldGNoYWJsZSkgW2Rpc2FibGVkXSBbc2l6ZT00S10NCglD
YXBhYmlsaXRpZXM6IFs1MF0gTVNJOiBFbmFibGUtIENvdW50PTEvMSBNYXNrYWJsZS0gNjRi
aXQrDQoJCUFkZHJlc3M6IDAwMDAwMDAwMDAwMDAwMDAgIERhdGE6IDAwMDANCglDYXBhYmls
aXRpZXM6IFs3OF0gUG93ZXIgTWFuYWdlbWVudCB2ZXJzaW9uIDMNCgkJRmxhZ3M6IFBNRUNs
ay0gRFNJLSBEMSsgRDIrIEF1eEN1cnJlbnQ9Mzc1bUEgUE1FKEQwKyxEMSssRDIrLEQzaG90
KyxEM2NvbGQtKQ0KCQlTdGF0dXM6IEQwIE5vU29mdFJzdCsgUE1FLUVuYWJsZS0gRFNlbD0w
IERTY2FsZT0wIFBNRS0NCglDYXBhYmlsaXRpZXM6IFs4MF0gRXhwcmVzcyAodjEpIEVuZHBv
aW50LCBNU0kgMDANCgkJRGV2Q2FwOglNYXhQYXlsb2FkIDI1NiBieXRlcywgUGhhbnRGdW5j
IDAsIExhdGVuY3kgTDBzIHVubGltaXRlZCwgTDEgdW5saW1pdGVkDQoJCQlFeHRUYWctIEF0
dG5CdG4tIEF0dG5JbmQtIFB3ckluZC0gUkJFKyBGTFJlc2V0LQ0KCQlEZXZDdGw6CVJlcG9y
dCBlcnJvcnM6IENvcnJlY3RhYmxlLSBOb24tRmF0YWwtIEZhdGFsLSBVbnN1cHBvcnRlZC0N
CgkJCVJseGRPcmQtIEV4dFRhZy0gUGhhbnRGdW5jLSBBdXhQd3ItIE5vU25vb3ArDQoJCQlN
YXhQYXlsb2FkIDEyOCBieXRlcywgTWF4UmVhZFJlcSA1MTIgYnl0ZXMNCgkJRGV2U3RhOglD
b3JyRXJyLSBVbmNvcnJFcnItIEZhdGFsRXJyLSBVbnN1cHBSZXEtIEF1eFB3ci0gVHJhbnNQ
ZW5kLQ0KCQlMbmtDYXA6CVBvcnQgIzEsIFNwZWVkIDIuNUdUL3MsIFdpZHRoIHgxLCBBU1BN
IHVua25vd24sIExhdGVuY3kgTDAgPDY0bnMsIEwxIHVubGltaXRlZA0KCQkJQ2xvY2tQTSsg
U3VycHJpc2UtIExMQWN0UmVwLSBCd05vdC0NCgkJTG5rQ3RsOglBU1BNIERpc2FibGVkOyBS
Q0IgNjQgYnl0ZXMgRGlzYWJsZWQtIFJldHJhaW4tIENvbW1DbGstDQoJCQlFeHRTeW5jaC0g
Q2xvY2tQTS0gQXV0V2lkRGlzLSBCV0ludC0gQXV0QldJbnQtDQoJCUxua1N0YToJU3BlZWQg
Mi41R1QvcywgV2lkdGggeDEsIFRyRXJyLSBUcmFpbi0gU2xvdENsay0gRExBY3RpdmUtIEJX
TWdtdC0gQUJXTWdtdC0NCglLZXJuZWwgZHJpdmVyIGluIHVzZTogcGNpYmFjaw0KDQowNDow
MC41IFVTQiBjb250cm9sbGVyIFswYzAzXTogTmV0TW9zIFRlY2hub2xvZ3kgTUNTOTk5MCBQ
Q0llIHRvIDTigJBQb3J0IFVTQiAyLjAgSG9zdCBDb250cm9sbGVyIFs5NzEwOjk5OTBdIChw
cm9nLWlmIDIwIFtFSENJXSkNCglTdWJzeXN0ZW06IERldmljZSBbYTAwMDo0MDAwXQ0KCUNv
bnRyb2w6IEkvTy0gTWVtLSBCdXNNYXN0ZXItIFNwZWNDeWNsZS0gTWVtV0lOVi0gVkdBU25v
b3AtIFBhckVyci0gU3RlcHBpbmctIFNFUlItIEZhc3RCMkItIERpc0lOVHgtDQoJU3RhdHVz
OiBDYXArIDY2TUh6LSBVREYtIEZhc3RCMkItIFBhckVyci0gREVWU0VMPWZhc3QgPlRBYm9y
dC0gPFRBYm9ydC0gPE1BYm9ydC0gPlNFUlItIDxQRVJSLSBJTlR4LQ0KCUludGVycnVwdDog
cGluIEMgcm91dGVkIHRvIElSUSA0Mg0KCVJlZ2lvbiAwOiBNZW1vcnkgYXQgZjk1ZmQwMDAg
KDMyLWJpdCwgbm9uLXByZWZldGNoYWJsZSkgW2Rpc2FibGVkXSBbc2l6ZT00S10NCglDYXBh
YmlsaXRpZXM6IFs1MF0gTVNJOiBFbmFibGUtIENvdW50PTEvMSBNYXNrYWJsZS0gNjRiaXQr
DQoJCUFkZHJlc3M6IDAwMDAwMDAwMDAwMDAwMDAgIERhdGE6IDAwMDANCglDYXBhYmlsaXRp
ZXM6IFs3OF0gUG93ZXIgTWFuYWdlbWVudCB2ZXJzaW9uIDMNCgkJRmxhZ3M6IFBNRUNsay0g
RFNJLSBEMSsgRDIrIEF1eEN1cnJlbnQ9Mzc1bUEgUE1FKEQwKyxEMSssRDIrLEQzaG90KyxE
M2NvbGQtKQ0KCQlTdGF0dXM6IEQwIE5vU29mdFJzdCsgUE1FLUVuYWJsZS0gRFNlbD0wIERT
Y2FsZT0wIFBNRS0NCglDYXBhYmlsaXRpZXM6IFs4MF0gRXhwcmVzcyAodjEpIEVuZHBvaW50
LCBNU0kgMDANCgkJRGV2Q2FwOglNYXhQYXlsb2FkIDI1NiBieXRlcywgUGhhbnRGdW5jIDAs
IExhdGVuY3kgTDBzIHVubGltaXRlZCwgTDEgdW5saW1pdGVkDQoJCQlFeHRUYWctIEF0dG5C
dG4tIEF0dG5JbmQtIFB3ckluZC0gUkJFKyBGTFJlc2V0LQ0KCQlEZXZDdGw6CVJlcG9ydCBl
cnJvcnM6IENvcnJlY3RhYmxlLSBOb24tRmF0YWwtIEZhdGFsLSBVbnN1cHBvcnRlZC0NCgkJ
CVJseGRPcmQtIEV4dFRhZy0gUGhhbnRGdW5jLSBBdXhQd3ItIE5vU25vb3ArDQoJCQlNYXhQ
YXlsb2FkIDEyOCBieXRlcywgTWF4UmVhZFJlcSA1MTIgYnl0ZXMNCgkJRGV2U3RhOglDb3Jy
RXJyLSBVbmNvcnJFcnItIEZhdGFsRXJyLSBVbnN1cHBSZXEtIEF1eFB3ci0gVHJhbnNQZW5k
LQ0KCQlMbmtDYXA6CVBvcnQgIzEsIFNwZWVkIDIuNUdUL3MsIFdpZHRoIHgxLCBBU1BNIHVu
a25vd24sIExhdGVuY3kgTDAgPDY0bnMsIEwxIHVubGltaXRlZA0KCQkJQ2xvY2tQTSsgU3Vy
cHJpc2UtIExMQWN0UmVwLSBCd05vdC0NCgkJTG5rQ3RsOglBU1BNIERpc2FibGVkOyBSQ0Ig
NjQgYnl0ZXMgRGlzYWJsZWQtIFJldHJhaW4tIENvbW1DbGstDQoJCQlFeHRTeW5jaC0gQ2xv
Y2tQTS0gQXV0V2lkRGlzLSBCV0ludC0gQXV0QldJbnQtDQoJCUxua1N0YToJU3BlZWQgMi41
R1QvcywgV2lkdGggeDEsIFRyRXJyLSBUcmFpbi0gU2xvdENsay0gRExBY3RpdmUtIEJXTWdt
dC0gQUJXTWdtdC0NCglLZXJuZWwgZHJpdmVyIGluIHVzZTogcGNpYmFjaw0KDQowNDowMC42
IFVTQiBjb250cm9sbGVyIFswYzAzXTogTmV0TW9zIFRlY2hub2xvZ3kgTUNTOTk5MCBQQ0ll
IHRvIDTigJBQb3J0IFVTQiAyLjAgSG9zdCBDb250cm9sbGVyIFs5NzEwOjk5OTBdIChwcm9n
LWlmIDEwIFtPSENJXSkNCglTdWJzeXN0ZW06IERldmljZSBbYTAwMDo0MDAwXQ0KCUNvbnRy
b2w6IEkvTy0gTWVtLSBCdXNNYXN0ZXItIFNwZWNDeWNsZS0gTWVtV0lOVi0gVkdBU25vb3At
IFBhckVyci0gU3RlcHBpbmctIFNFUlItIEZhc3RCMkItIERpc0lOVHgtDQoJU3RhdHVzOiBD
YXArIDY2TUh6LSBVREYtIEZhc3RCMkItIFBhckVyci0gREVWU0VMPWZhc3QgPlRBYm9ydC0g
PFRBYm9ydC0gPE1BYm9ydC0gPlNFUlItIDxQRVJSLSBJTlR4LQ0KCUludGVycnVwdDogcGlu
IEQgcm91dGVkIHRvIElSUSA0Mw0KCVJlZ2lvbiAwOiBNZW1vcnkgYXQgZjk1ZmUwMDAgKDMy
LWJpdCwgbm9uLXByZWZldGNoYWJsZSkgW2Rpc2FibGVkXSBbc2l6ZT00S10NCglDYXBhYmls
aXRpZXM6IFs1MF0gTVNJOiBFbmFibGUtIENvdW50PTEvMSBNYXNrYWJsZS0gNjRiaXQrDQoJ
CUFkZHJlc3M6IDAwMDAwMDAwMDAwMDAwMDAgIERhdGE6IDAwMDANCglDYXBhYmlsaXRpZXM6
IFs3OF0gUG93ZXIgTWFuYWdlbWVudCB2ZXJzaW9uIDMNCgkJRmxhZ3M6IFBNRUNsay0gRFNJ
LSBEMSsgRDIrIEF1eEN1cnJlbnQ9Mzc1bUEgUE1FKEQwKyxEMSssRDIrLEQzaG90KyxEM2Nv
bGQtKQ0KCQlTdGF0dXM6IEQwIE5vU29mdFJzdCsgUE1FLUVuYWJsZS0gRFNlbD0wIERTY2Fs
ZT0wIFBNRS0NCglDYXBhYmlsaXRpZXM6IFs4MF0gRXhwcmVzcyAodjEpIEVuZHBvaW50LCBN
U0kgMDANCgkJRGV2Q2FwOglNYXhQYXlsb2FkIDI1NiBieXRlcywgUGhhbnRGdW5jIDAsIExh
dGVuY3kgTDBzIHVubGltaXRlZCwgTDEgdW5saW1pdGVkDQoJCQlFeHRUYWctIEF0dG5CdG4t
IEF0dG5JbmQtIFB3ckluZC0gUkJFKyBGTFJlc2V0LQ0KCQlEZXZDdGw6CVJlcG9ydCBlcnJv
cnM6IENvcnJlY3RhYmxlLSBOb24tRmF0YWwtIEZhdGFsLSBVbnN1cHBvcnRlZC0NCgkJCVJs
eGRPcmQtIEV4dFRhZy0gUGhhbnRGdW5jLSBBdXhQd3ItIE5vU25vb3ArDQoJCQlNYXhQYXls
b2FkIDEyOCBieXRlcywgTWF4UmVhZFJlcSA1MTIgYnl0ZXMNCgkJRGV2U3RhOglDb3JyRXJy
LSBVbmNvcnJFcnItIEZhdGFsRXJyLSBVbnN1cHBSZXEtIEF1eFB3ci0gVHJhbnNQZW5kLQ0K
CQlMbmtDYXA6CVBvcnQgIzEsIFNwZWVkIDIuNUdUL3MsIFdpZHRoIHgxLCBBU1BNIHVua25v
d24sIExhdGVuY3kgTDAgPDY0bnMsIEwxIHVubGltaXRlZA0KCQkJQ2xvY2tQTSsgU3VycHJp
c2UtIExMQWN0UmVwLSBCd05vdC0NCgkJTG5rQ3RsOglBU1BNIERpc2FibGVkOyBSQ0IgNjQg
Ynl0ZXMgRGlzYWJsZWQtIFJldHJhaW4tIENvbW1DbGstDQoJCQlFeHRTeW5jaC0gQ2xvY2tQ
TS0gQXV0V2lkRGlzLSBCV0ludC0gQXV0QldJbnQtDQoJCUxua1N0YToJU3BlZWQgMi41R1Qv
cywgV2lkdGggeDEsIFRyRXJyLSBUcmFpbi0gU2xvdENsay0gRExBY3RpdmUtIEJXTWdtdC0g
QUJXTWdtdC0NCglLZXJuZWwgZHJpdmVyIGluIHVzZTogcGNpYmFjaw0KDQowNDowMC43IFVT
QiBjb250cm9sbGVyIFswYzAzXTogTmV0TW9zIFRlY2hub2xvZ3kgTUNTOTk5MCBQQ0llIHRv
IDTigJBQb3J0IFVTQiAyLjAgSG9zdCBDb250cm9sbGVyIFs5NzEwOjk5OTBdIChwcm9nLWlm
IDIwIFtFSENJXSkNCglTdWJzeXN0ZW06IERldmljZSBbYTAwMDo0MDAwXQ0KCUNvbnRyb2w6
IEkvTy0gTWVtLSBCdXNNYXN0ZXItIFNwZWNDeWNsZS0gTWVtV0lOVi0gVkdBU25vb3AtIFBh
ckVyci0gU3RlcHBpbmctIFNFUlItIEZhc3RCMkItIERpc0lOVHgtDQoJU3RhdHVzOiBDYXAr
IDY2TUh6LSBVREYtIEZhc3RCMkItIFBhckVyci0gREVWU0VMPWZhc3QgPlRBYm9ydC0gPFRB
Ym9ydC0gPE1BYm9ydC0gPlNFUlItIDxQRVJSLSBJTlR4LQ0KCUludGVycnVwdDogcGluIEQg
cm91dGVkIHRvIElSUSA0Mw0KCVJlZ2lvbiAwOiBNZW1vcnkgYXQgZjk1ZmYwMDAgKDMyLWJp
dCwgbm9uLXByZWZldGNoYWJsZSkgW2Rpc2FibGVkXSBbc2l6ZT00S10NCglDYXBhYmlsaXRp
ZXM6IFs1MF0gTVNJOiBFbmFibGUtIENvdW50PTEvMSBNYXNrYWJsZS0gNjRiaXQrDQoJCUFk
ZHJlc3M6IDAwMDAwMDAwMDAwMDAwMDAgIERhdGE6IDAwMDANCglDYXBhYmlsaXRpZXM6IFs3
OF0gUG93ZXIgTWFuYWdlbWVudCB2ZXJzaW9uIDMNCgkJRmxhZ3M6IFBNRUNsay0gRFNJLSBE
MSsgRDIrIEF1eEN1cnJlbnQ9Mzc1bUEgUE1FKEQwKyxEMSssRDIrLEQzaG90KyxEM2NvbGQt
KQ0KCQlTdGF0dXM6IEQwIE5vU29mdFJzdCsgUE1FLUVuYWJsZS0gRFNlbD0wIERTY2FsZT0w
IFBNRS0NCglDYXBhYmlsaXRpZXM6IFs4MF0gRXhwcmVzcyAodjEpIEVuZHBvaW50LCBNU0kg
MDANCgkJRGV2Q2FwOglNYXhQYXlsb2FkIDI1NiBieXRlcywgUGhhbnRGdW5jIDAsIExhdGVu
Y3kgTDBzIHVubGltaXRlZCwgTDEgdW5saW1pdGVkDQoJCQlFeHRUYWctIEF0dG5CdG4tIEF0
dG5JbmQtIFB3ckluZC0gUkJFKyBGTFJlc2V0LQ0KCQlEZXZDdGw6CVJlcG9ydCBlcnJvcnM6
IENvcnJlY3RhYmxlLSBOb24tRmF0YWwtIEZhdGFsLSBVbnN1cHBvcnRlZC0NCgkJCVJseGRP
cmQtIEV4dFRhZy0gUGhhbnRGdW5jLSBBdXhQd3ItIE5vU25vb3ArDQoJCQlNYXhQYXlsb2Fk
IDEyOCBieXRlcywgTWF4UmVhZFJlcSA1MTIgYnl0ZXMNCgkJRGV2U3RhOglDb3JyRXJyLSBV
bmNvcnJFcnItIEZhdGFsRXJyLSBVbnN1cHBSZXEtIEF1eFB3ci0gVHJhbnNQZW5kLQ0KCQlM
bmtDYXA6CVBvcnQgIzEsIFNwZWVkIDIuNUdUL3MsIFdpZHRoIHgxLCBBU1BNIHVua25vd24s
IExhdGVuY3kgTDAgPDY0bnMsIEwxIHVubGltaXRlZA0KCQkJQ2xvY2tQTSsgU3VycHJpc2Ut
IExMQWN0UmVwLSBCd05vdC0NCgkJTG5rQ3RsOglBU1BNIERpc2FibGVkOyBSQ0IgNjQgYnl0
ZXMgRGlzYWJsZWQtIFJldHJhaW4tIENvbW1DbGstDQoJCQlFeHRTeW5jaC0gQ2xvY2tQTS0g
QXV0V2lkRGlzLSBCV0ludC0gQXV0QldJbnQtDQoJCUxua1N0YToJU3BlZWQgMi41R1Qvcywg
V2lkdGggeDEsIFRyRXJyLSBUcmFpbi0gU2xvdENsay0gRExBY3RpdmUtIEJXTWdtdC0gQUJX
TWdtdC0NCglLZXJuZWwgZHJpdmVyIGluIHVzZTogcGNpYmFjaw0KDQowNTowMC4wIE11bHRp
bWVkaWEgdmlkZW8gY29udHJvbGxlciBbMDQwMF06IENvbmV4YW50IFN5c3RlbXMsIEluYy4g
Q1gyNTg1MCBbMTRmMTo4MjAwXQ0KCUNvbnRyb2w6IEkvTy0gTWVtLSBCdXNNYXN0ZXItIFNw
ZWNDeWNsZS0gTWVtV0lOVi0gVkdBU25vb3AtIFBhckVyci0gU3RlcHBpbmctIFNFUlItIEZh
c3RCMkItIERpc0lOVHgtDQoJU3RhdHVzOiBDYXArIDY2TUh6LSBVREYtIEZhc3RCMkItIFBh
ckVyci0gREVWU0VMPWZhc3QgPlRBYm9ydC0gPFRBYm9ydC0gPE1BYm9ydC0gPlNFUlItIDxQ
RVJSLSBJTlR4LQ0KCUludGVycnVwdDogcGluIEEgcm91dGVkIHRvIElSUSAzNg0KCVJlZ2lv
biAwOiBNZW1vcnkgYXQgZjk2MDAwMDAgKDY0LWJpdCwgbm9uLXByZWZldGNoYWJsZSkgW2Rp
c2FibGVkXSBbc2l6ZT0yTV0NCglDYXBhYmlsaXRpZXM6IFs0MF0gRXhwcmVzcyAodjEpIEVu
ZHBvaW50LCBNU0kgMDANCgkJRGV2Q2FwOglNYXhQYXlsb2FkIDEyOCBieXRlcywgUGhhbnRG
dW5jIDAsIExhdGVuY3kgTDBzIDw2NG5zLCBMMSA8MXVzDQoJCQlFeHRUYWctIEF0dG5CdG4t
IEF0dG5JbmQtIFB3ckluZC0gUkJFKyBGTFJlc2V0LQ0KCQlEZXZDdGw6CVJlcG9ydCBlcnJv
cnM6IENvcnJlY3RhYmxlLSBOb24tRmF0YWwtIEZhdGFsLSBVbnN1cHBvcnRlZC0NCgkJCVJs
eGRPcmQrIEV4dFRhZy0gUGhhbnRGdW5jLSBBdXhQd3ItIE5vU25vb3ArDQoJCQlNYXhQYXls
b2FkIDEyOCBieXRlcywgTWF4UmVhZFJlcSA1MTIgYnl0ZXMNCgkJRGV2U3RhOglDb3JyRXJy
LSBVbmNvcnJFcnItIEZhdGFsRXJyLSBVbnN1cHBSZXEtIEF1eFB3ci0gVHJhbnNQZW5kLQ0K
CQlMbmtDYXA6CVBvcnQgIzAsIFNwZWVkIDIuNUdUL3MsIFdpZHRoIHgxLCBBU1BNIEwwcyBM
MSwgTGF0ZW5jeSBMMCA8MnVzLCBMMSA8NHVzDQoJCQlDbG9ja1BNLSBTdXJwcmlzZS0gTExB
Y3RSZXAtIEJ3Tm90LQ0KCQlMbmtDdGw6CUFTUE0gRGlzYWJsZWQ7IFJDQiA2NCBieXRlcyBE
aXNhYmxlZC0gUmV0cmFpbi0gQ29tbUNsay0NCgkJCUV4dFN5bmNoLSBDbG9ja1BNLSBBdXRX
aWREaXMtIEJXSW50LSBBdXRCV0ludC0NCgkJTG5rU3RhOglTcGVlZCAyLjVHVC9zLCBXaWR0
aCB4MSwgVHJFcnItIFRyYWluLSBTbG90Q2xrLSBETEFjdGl2ZS0gQldNZ210LSBBQldNZ210
LQ0KCUNhcGFiaWxpdGllczogWzgwXSBQb3dlciBNYW5hZ2VtZW50IHZlcnNpb24gMw0KCQlG
bGFnczogUE1FQ2xrLSBEU0krIEQxKyBEMisgQXV4Q3VycmVudD0wbUEgUE1FKEQwKyxEMSss
RDIrLEQzaG90KyxEM2NvbGQtKQ0KCQlTdGF0dXM6IEQwIE5vU29mdFJzdCsgUE1FLUVuYWJs
ZS0gRFNlbD0wIERTY2FsZT0wIFBNRS0NCglDYXBhYmlsaXRpZXM6IFs5MF0gVml0YWwgUHJv
ZHVjdCBEYXRhDQoJCVVua25vd24gc21hbGwgcmVzb3VyY2UgdHlwZSAwMCwgd2lsbCBub3Qg
ZGVjb2RlIG1vcmUuDQoJQ2FwYWJpbGl0aWVzOiBbYTBdIE1TSTogRW5hYmxlLSBDb3VudD0x
LzEgTWFza2FibGUtIDY0Yml0Kw0KCQlBZGRyZXNzOiAwMDAwMDAwMDAwMDAwMDAwICBEYXRh
OiAwMDAwDQoJQ2FwYWJpbGl0aWVzOiBbMTAwIHYxXSBBZHZhbmNlZCBFcnJvciBSZXBvcnRp
bmcNCgkJVUVTdGE6CURMUC0gU0RFUy0gVExQLSBGQ1AtIENtcGx0VE8tIENtcGx0QWJydC0g
VW54Q21wbHQtIFJ4T0YtIE1hbGZUTFAtIEVDUkMtIFVuc3VwUmVxLSBBQ1NWaW9sLQ0KCQlV
RU1zazoJRExQLSBTREVTLSBUTFAtIEZDUC0gQ21wbHRUTy0gQ21wbHRBYnJ0LSBVbnhDbXBs
dC0gUnhPRi0gTWFsZlRMUC0gRUNSQy0gVW5zdXBSZXEtIEFDU1Zpb2wtDQoJCVVFU3ZydDoJ
RExQKyBTREVTLSBUTFAtIEZDUCsgQ21wbHRUTy0gQ21wbHRBYnJ0LSBVbnhDbXBsdC0gUnhP
RisgTWFsZlRMUCsgRUNSQy0gVW5zdXBSZXEtIEFDU1Zpb2wtDQoJCUNFU3RhOglSeEVyci0g
QmFkVExQLSBCYWRETExQLSBSb2xsb3Zlci0gVGltZW91dC0gTm9uRmF0YWxFcnIrDQoJCUNF
TXNrOglSeEVyci0gQmFkVExQLSBCYWRETExQLSBSb2xsb3Zlci0gVGltZW91dC0gTm9uRmF0
YWxFcnIrDQoJCUFFUkNhcDoJRmlyc3QgRXJyb3IgUG9pbnRlcjogMDAsIEdlbkNhcC0gQ0dl
bkVuLSBDaGtDYXAtIENoa0VuLQ0KCUNhcGFiaWxpdGllczogWzIwMCB2MV0gVmlydHVhbCBD
aGFubmVsDQoJCUNhcHM6CUxQRVZDPTEgUmVmQ2xrPTEwMG5zIFBBVEVudHJ5Qml0cz0xDQoJ
CUFyYjoJRml4ZWQrIFdSUjMyKyBXUlI2NCsgV1JSMTI4LQ0KCQlDdHJsOglBcmJTZWxlY3Q9
V1JSNjQNCgkJU3RhdHVzOglJblByb2dyZXNzLQ0KCQlQb3J0IEFyYml0cmF0aW9uIFRhYmxl
IFsyNDBdIDw/Pg0KCQlWQzA6CUNhcHM6CVBBVE9mZnNldD0wMCBNYXhUaW1lU2xvdHM9MSBS
ZWpTbm9vcFRyYW5zLQ0KCQkJQXJiOglGaXhlZC0gV1JSMzItIFdSUjY0LSBXUlIxMjgtIFRX
UlIxMjgtIFdSUjI1Ni0NCgkJCUN0cmw6CUVuYWJsZSsgSUQ9MCBBcmJTZWxlY3Q9Rml4ZWQg
VEMvVkM9ZmYNCgkJCVN0YXR1czoJTmVnb1BlbmRpbmctIEluUHJvZ3Jlc3MtDQoJCVZDMToJ
Q2FwczoJUEFUT2Zmc2V0PTAwIE1heFRpbWVTbG90cz0xIFJlalNub29wVHJhbnMtDQoJCQlB
cmI6CUZpeGVkLSBXUlIzMi0gV1JSNjQtIFdSUjEyOC0gVFdSUjEyOC0gV1JSMjU2LQ0KCQkJ
Q3RybDoJRW5hYmxlLSBJRD0xIEFyYlNlbGVjdD1GaXhlZCBUQy9WQz0wMA0KCQkJU3RhdHVz
OglOZWdvUGVuZGluZy0gSW5Qcm9ncmVzcy0NCglLZXJuZWwgZHJpdmVyIGluIHVzZTogcGNp
YmFjaw0KDQowNjowMC4wIFZHQSBjb21wYXRpYmxlIGNvbnRyb2xsZXIgWzAzMDBdOiBBVEkg
VGVjaG5vbG9naWVzIEluYyBSVjYyMCBMRSBbUmFkZW9uIEhEIDM0NTBdIFsxMDAyOjk1YzVd
IChwcm9nLWlmIDAwIFtWR0EgY29udHJvbGxlcl0pDQoJU3Vic3lzdGVtOiBBU1VTVGVLIENv
bXB1dGVyIEluYy4gRGV2aWNlIFsxMDQzOjAxZDRdDQoJQ29udHJvbDogSS9PLSBNZW0tIEJ1
c01hc3Rlci0gU3BlY0N5Y2xlLSBNZW1XSU5WLSBWR0FTbm9vcC0gUGFyRXJyLSBTdGVwcGlu
Zy0gU0VSUi0gRmFzdEIyQi0gRGlzSU5UeC0NCglTdGF0dXM6IENhcCsgNjZNSHotIFVERi0g
RmFzdEIyQi0gUGFyRXJyLSBERVZTRUw9ZmFzdCA+VEFib3J0LSA8VEFib3J0LSA8TUFib3J0
LSA+U0VSUi0gPFBFUlItIElOVHgtDQoJSW50ZXJydXB0OiBwaW4gQSByb3V0ZWQgdG8gSVJR
IDEwDQoJUmVnaW9uIDA6IE1lbW9yeSBhdCBiMDAwMDAwMCAoNjQtYml0LCBwcmVmZXRjaGFi
bGUpIFtkaXNhYmxlZF0gW3NpemU9MjU2TV0NCglSZWdpb24gMjogTWVtb3J5IGF0IGY5OWUw
MDAwICg2NC1iaXQsIG5vbi1wcmVmZXRjaGFibGUpIFtkaXNhYmxlZF0gW3NpemU9NjRLXQ0K
CVJlZ2lvbiA0OiBJL08gcG9ydHMgYXQgYjAwMCBbZGlzYWJsZWRdIFtzaXplPTI1Nl0NCglF
eHBhbnNpb24gUk9NIGF0IGY5OWMwMDAwIFtkaXNhYmxlZF0gW3NpemU9MTI4S10NCglDYXBh
YmlsaXRpZXM6IFs1MF0gUG93ZXIgTWFuYWdlbWVudCB2ZXJzaW9uIDMNCgkJRmxhZ3M6IFBN
RUNsay0gRFNJLSBEMSsgRDIrIEF1eEN1cnJlbnQ9MG1BIFBNRShEMC0sRDEtLEQyLSxEM2hv
dC0sRDNjb2xkLSkNCgkJU3RhdHVzOiBEMCBOb1NvZnRSc3QtIFBNRS1FbmFibGUtIERTZWw9
MCBEU2NhbGU9MCBQTUUtDQoJQ2FwYWJpbGl0aWVzOiBbNThdIEV4cHJlc3MgKHYyKSBMZWdh
Y3kgRW5kcG9pbnQsIE1TSSAwMA0KCQlEZXZDYXA6CU1heFBheWxvYWQgMTI4IGJ5dGVzLCBQ
aGFudEZ1bmMgMCwgTGF0ZW5jeSBMMHMgPDR1cywgTDEgdW5saW1pdGVkDQoJCQlFeHRUYWcr
IEF0dG5CdG4tIEF0dG5JbmQtIFB3ckluZC0gUkJFKyBGTFJlc2V0LQ0KCQlEZXZDdGw6CVJl
cG9ydCBlcnJvcnM6IENvcnJlY3RhYmxlLSBOb24tRmF0YWwtIEZhdGFsLSBVbnN1cHBvcnRl
ZC0NCgkJCVJseGRPcmQrIEV4dFRhZy0gUGhhbnRGdW5jLSBBdXhQd3ItIE5vU25vb3ArDQoJ
CQlNYXhQYXlsb2FkIDEyOCBieXRlcywgTWF4UmVhZFJlcSAxMjggYnl0ZXMNCgkJRGV2U3Rh
OglDb3JyRXJyLSBVbmNvcnJFcnItIEZhdGFsRXJyLSBVbnN1cHBSZXEtIEF1eFB3ci0gVHJh
bnNQZW5kLQ0KCQlMbmtDYXA6CVBvcnQgIzAsIFNwZWVkIDIuNUdUL3MsIFdpZHRoIHgxNiwg
QVNQTSBMMHMgTDEsIExhdGVuY3kgTDAgPDY0bnMsIEwxIDwxdXMNCgkJCUNsb2NrUE0tIFN1
cnByaXNlLSBMTEFjdFJlcC0gQndOb3QtDQoJCUxua0N0bDoJQVNQTSBEaXNhYmxlZDsgUkNC
IDY0IGJ5dGVzIERpc2FibGVkLSBSZXRyYWluLSBDb21tQ2xrKw0KCQkJRXh0U3luY2gtIENs
b2NrUE0tIEF1dFdpZERpcy0gQldJbnQtIEF1dEJXSW50LQ0KCQlMbmtTdGE6CVNwZWVkIDIu
NUdUL3MsIFdpZHRoIHgxLCBUckVyci0gVHJhaW4tIFNsb3RDbGsrIERMQWN0aXZlLSBCV01n
bXQtIEFCV01nbXQtDQoJCURldkNhcDI6IENvbXBsZXRpb24gVGltZW91dDogTm90IFN1cHBv
cnRlZCwgVGltZW91dERpcy0NCgkJRGV2Q3RsMjogQ29tcGxldGlvbiBUaW1lb3V0OiA1MHVz
IHRvIDUwbXMsIFRpbWVvdXREaXMtDQoJCUxua0N0bDI6IFRhcmdldCBMaW5rIFNwZWVkOiAy
LjVHVC9zLCBFbnRlckNvbXBsaWFuY2UtIFNwZWVkRGlzLSwgU2VsZWN0YWJsZSBEZS1lbXBo
YXNpczogLTZkQg0KCQkJIFRyYW5zbWl0IE1hcmdpbjogTm9ybWFsIE9wZXJhdGluZyBSYW5n
ZSwgRW50ZXJNb2RpZmllZENvbXBsaWFuY2UtIENvbXBsaWFuY2VTT1MtDQoJCQkgQ29tcGxp
YW5jZSBEZS1lbXBoYXNpczogLTZkQg0KCQlMbmtTdGEyOiBDdXJyZW50IERlLWVtcGhhc2lz
IExldmVsOiAtNmRCDQoJQ2FwYWJpbGl0aWVzOiBbYTBdIE1TSTogRW5hYmxlLSBDb3VudD0x
LzEgTWFza2FibGUtIDY0Yml0Kw0KCQlBZGRyZXNzOiAwMDAwMDAwMDAwMDAwMDAwICBEYXRh
OiAwMDAwDQoJQ2FwYWJpbGl0aWVzOiBbMTAwIHYxXSBWZW5kb3IgU3BlY2lmaWMgSW5mb3Jt
YXRpb246IElEPTAwMDEgUmV2PTEgTGVuPTAxMCA8Pz4NCg0KMDY6MDAuMSBBdWRpbyBkZXZp
Y2UgWzA0MDNdOiBBVEkgVGVjaG5vbG9naWVzIEluYyBSVjYyMCBBdWRpbyBkZXZpY2UgW1Jh
ZGVvbiBIRCAzNHh4IFNlcmllc10gWzEwMDI6YWEyOF0NCglTdWJzeXN0ZW06IEFTVVNUZUsg
Q29tcHV0ZXIgSW5jLiBEZXZpY2UgWzEwNDM6YWEyOF0NCglDb250cm9sOiBJL08rIE1lbSsg
QnVzTWFzdGVyKyBTcGVjQ3ljbGUtIE1lbVdJTlYtIFZHQVNub29wLSBQYXJFcnItIFN0ZXBw
aW5nLSBTRVJSKyBGYXN0QjJCLSBEaXNJTlR4Kw0KCVN0YXR1czogQ2FwKyA2Nk1Iei0gVURG
LSBGYXN0QjJCLSBQYXJFcnItIERFVlNFTD1mYXN0ID5UQWJvcnQtIDxUQWJvcnQtIDxNQWJv
cnQtID5TRVJSLSA8UEVSUi0gSU5UeC0NCglMYXRlbmN5OiAwLCBDYWNoZSBMaW5lIFNpemU6
IDY0IGJ5dGVzDQoJSW50ZXJydXB0OiBwaW4gQiByb3V0ZWQgdG8gSVJRIDEyMw0KCVJlZ2lv
biAwOiBNZW1vcnkgYXQgZjk5ZmMwMDAgKDY0LWJpdCwgbm9uLXByZWZldGNoYWJsZSkgW3Np
emU9MTZLXQ0KCUNhcGFiaWxpdGllczogWzUwXSBQb3dlciBNYW5hZ2VtZW50IHZlcnNpb24g
Mw0KCQlGbGFnczogUE1FQ2xrLSBEU0ktIEQxKyBEMisgQXV4Q3VycmVudD0wbUEgUE1FKEQw
LSxEMS0sRDItLEQzaG90LSxEM2NvbGQtKQ0KCQlTdGF0dXM6IEQwIE5vU29mdFJzdC0gUE1F
LUVuYWJsZS0gRFNlbD0wIERTY2FsZT0wIFBNRS0NCglDYXBhYmlsaXRpZXM6IFs1OF0gRXhw
cmVzcyAodjIpIExlZ2FjeSBFbmRwb2ludCwgTVNJIDAwDQoJCURldkNhcDoJTWF4UGF5bG9h
ZCAxMjggYnl0ZXMsIFBoYW50RnVuYyAwLCBMYXRlbmN5IEwwcyA8NHVzLCBMMSB1bmxpbWl0
ZWQNCgkJCUV4dFRhZysgQXR0bkJ0bi0gQXR0bkluZC0gUHdySW5kLSBSQkUrIEZMUmVzZXQt
DQoJCURldkN0bDoJUmVwb3J0IGVycm9yczogQ29ycmVjdGFibGUtIE5vbi1GYXRhbC0gRmF0
YWwtIFVuc3VwcG9ydGVkLQ0KCQkJUmx4ZE9yZCsgRXh0VGFnLSBQaGFudEZ1bmMtIEF1eFB3
ci0gTm9Tbm9vcCsNCgkJCU1heFBheWxvYWQgMTI4IGJ5dGVzLCBNYXhSZWFkUmVxIDEyOCBi
eXRlcw0KCQlEZXZTdGE6CUNvcnJFcnItIFVuY29yckVyci0gRmF0YWxFcnItIFVuc3VwcFJl
cS0gQXV4UHdyLSBUcmFuc1BlbmQtDQoJCUxua0NhcDoJUG9ydCAjMCwgU3BlZWQgMi41R1Qv
cywgV2lkdGggeDE2LCBBU1BNIEwwcyBMMSwgTGF0ZW5jeSBMMCA8NjRucywgTDEgPDF1cw0K
CQkJQ2xvY2tQTS0gU3VycHJpc2UtIExMQWN0UmVwLSBCd05vdC0NCgkJTG5rQ3RsOglBU1BN
IERpc2FibGVkOyBSQ0IgNjQgYnl0ZXMgRGlzYWJsZWQtIFJldHJhaW4tIENvbW1DbGsrDQoJ
CQlFeHRTeW5jaC0gQ2xvY2tQTS0gQXV0V2lkRGlzLSBCV0ludC0gQXV0QldJbnQtDQoJCUxu
a1N0YToJU3BlZWQgMi41R1QvcywgV2lkdGggeDEsIFRyRXJyLSBUcmFpbi0gU2xvdENsaysg
RExBY3RpdmUtIEJXTWdtdC0gQUJXTWdtdC0NCgkJRGV2Q2FwMjogQ29tcGxldGlvbiBUaW1l
b3V0OiBOb3QgU3VwcG9ydGVkLCBUaW1lb3V0RGlzLQ0KCQlEZXZDdGwyOiBDb21wbGV0aW9u
IFRpbWVvdXQ6IDUwdXMgdG8gNTBtcywgVGltZW91dERpcy0NCgkJTG5rQ3RsMjogVGFyZ2V0
IExpbmsgU3BlZWQ6IDIuNUdUL3MsIEVudGVyQ29tcGxpYW5jZS0gU3BlZWREaXMtLCBTZWxl
Y3RhYmxlIERlLWVtcGhhc2lzOiAtNmRCDQoJCQkgVHJhbnNtaXQgTWFyZ2luOiBOb3JtYWwg
T3BlcmF0aW5nIFJhbmdlLCBFbnRlck1vZGlmaWVkQ29tcGxpYW5jZS0gQ29tcGxpYW5jZVNP
Uy0NCgkJCSBDb21wbGlhbmNlIERlLWVtcGhhc2lzOiAtNmRCDQoJCUxua1N0YTI6IEN1cnJl
bnQgRGUtZW1waGFzaXMgTGV2ZWw6IC02ZEINCglDYXBhYmlsaXRpZXM6IFthMF0gTVNJOiBF
bmFibGUrIENvdW50PTEvMSBNYXNrYWJsZS0gNjRiaXQrDQoJCUFkZHJlc3M6IDAwMDAwMDAw
ZmVlMDEwMGMgIERhdGE6IDQxMmENCglDYXBhYmlsaXRpZXM6IFsxMDAgdjFdIFZlbmRvciBT
cGVjaWZpYyBJbmZvcm1hdGlvbjogSUQ9MDAwMSBSZXY9MSBMZW49MDEwIDw/Pg0KCUtlcm5l
bCBkcml2ZXIgaW4gdXNlOiBzbmRfaGRhX2ludGVsDQoNCjA3OjAwLjAgTXVsdGltZWRpYSB2
aWRlbyBjb250cm9sbGVyIFswNDAwXTogQ29uZXhhbnQgU3lzdGVtcywgSW5jLiBEZXZpY2Ug
WzE0ZjE6ODIxMF0NCglDb250cm9sOiBJL08tIE1lbSsgQnVzTWFzdGVyLSBTcGVjQ3ljbGUt
IE1lbVdJTlYtIFZHQVNub29wLSBQYXJFcnItIFN0ZXBwaW5nLSBTRVJSLSBGYXN0QjJCLSBE
aXNJTlR4LQ0KCVN0YXR1czogQ2FwKyA2Nk1Iei0gVURGLSBGYXN0QjJCLSBQYXJFcnItIERF
VlNFTD1mYXN0ID5UQWJvcnQtIDxUQWJvcnQtIDxNQWJvcnQtID5TRVJSLSA8UEVSUi0gSU5U
eC0NCglJbnRlcnJ1cHQ6IHBpbiBBIHJvdXRlZCB0byBJUlEgNDcNCglSZWdpb24gMDogTWVt
b3J5IGF0IGY5YTAwMDAwICg2NC1iaXQsIG5vbi1wcmVmZXRjaGFibGUpIFtzaXplPTJNXQ0K
CUNhcGFiaWxpdGllczogWzQwXSBFeHByZXNzICh2MSkgRW5kcG9pbnQsIE1TSSAwMA0KCQlE
ZXZDYXA6CU1heFBheWxvYWQgMTI4IGJ5dGVzLCBQaGFudEZ1bmMgMCwgTGF0ZW5jeSBMMHMg
PDY0bnMsIEwxIDwxdXMNCgkJCUV4dFRhZy0gQXR0bkJ0bi0gQXR0bkluZC0gUHdySW5kLSBS
QkUrIEZMUmVzZXQtDQoJCURldkN0bDoJUmVwb3J0IGVycm9yczogQ29ycmVjdGFibGUtIE5v
bi1GYXRhbC0gRmF0YWwtIFVuc3VwcG9ydGVkLQ0KCQkJUmx4ZE9yZCsgRXh0VGFnLSBQaGFu
dEZ1bmMtIEF1eFB3ci0gTm9Tbm9vcCsNCgkJCU1heFBheWxvYWQgMTI4IGJ5dGVzLCBNYXhS
ZWFkUmVxIDUxMiBieXRlcw0KCQlEZXZTdGE6CUNvcnJFcnItIFVuY29yckVyci0gRmF0YWxF
cnItIFVuc3VwcFJlcS0gQXV4UHdyLSBUcmFuc1BlbmQtDQoJCUxua0NhcDoJUG9ydCAjMCwg
U3BlZWQgMi41R1QvcywgV2lkdGggeDEsIEFTUE0gTDBzIEwxLCBMYXRlbmN5IEwwIDwydXMs
IEwxIDw0dXMNCgkJCUNsb2NrUE0tIFN1cnByaXNlLSBMTEFjdFJlcC0gQndOb3QtDQoJCUxu
a0N0bDoJQVNQTSBEaXNhYmxlZDsgUkNCIDY0IGJ5dGVzIERpc2FibGVkLSBSZXRyYWluLSBD
b21tQ2xrLQ0KCQkJRXh0U3luY2gtIENsb2NrUE0tIEF1dFdpZERpcy0gQldJbnQtIEF1dEJX
SW50LQ0KCQlMbmtTdGE6CVNwZWVkIDIuNUdUL3MsIFdpZHRoIHgxLCBUckVyci0gVHJhaW4t
IFNsb3RDbGstIERMQWN0aXZlLSBCV01nbXQtIEFCV01nbXQtDQoJQ2FwYWJpbGl0aWVzOiBb
ODBdIFBvd2VyIE1hbmFnZW1lbnQgdmVyc2lvbiAzDQoJCUZsYWdzOiBQTUVDbGstIERTSSsg
RDErIEQyKyBBdXhDdXJyZW50PTBtQSBQTUUoRDArLEQxKyxEMissRDNob3QrLEQzY29sZC0p
DQoJCVN0YXR1czogRDAgTm9Tb2Z0UnN0KyBQTUUtRW5hYmxlLSBEU2VsPTAgRFNjYWxlPTAg
UE1FLQ0KCUNhcGFiaWxpdGllczogWzkwXSBWaXRhbCBQcm9kdWN0IERhdGENCgkJVW5rbm93
biBzbWFsbCByZXNvdXJjZSB0eXBlIDAyLCB3aWxsIG5vdCBkZWNvZGUgbW9yZS4NCglDYXBh
YmlsaXRpZXM6IFthMF0gTVNJOiBFbmFibGUtIENvdW50PTEvMSBNYXNrYWJsZS0gNjRiaXQr
DQoJCUFkZHJlc3M6IDAwMDAwMDAwMDAwMDAwMDAgIERhdGE6IDAwMDANCglDYXBhYmlsaXRp
ZXM6IFsxMDAgdjFdIEFkdmFuY2VkIEVycm9yIFJlcG9ydGluZw0KCQlVRVN0YToJRExQLSBT
REVTLSBUTFAtIEZDUC0gQ21wbHRUTy0gQ21wbHRBYnJ0LSBVbnhDbXBsdC0gUnhPRi0gTWFs
ZlRMUC0gRUNSQy0gVW5zdXBSZXEtIEFDU1Zpb2wtDQoJCVVFTXNrOglETFAtIFNERVMtIFRM
UC0gRkNQLSBDbXBsdFRPLSBDbXBsdEFicnQtIFVueENtcGx0LSBSeE9GLSBNYWxmVExQLSBF
Q1JDLSBVbnN1cFJlcS0gQUNTVmlvbC0NCgkJVUVTdnJ0OglETFArIFNERVMtIFRMUC0gRkNQ
KyBDbXBsdFRPLSBDbXBsdEFicnQtIFVueENtcGx0LSBSeE9GKyBNYWxmVExQKyBFQ1JDLSBV
bnN1cFJlcS0gQUNTVmlvbC0NCgkJQ0VTdGE6CVJ4RXJyLSBCYWRUTFAtIEJhZERMTFAtIFJv
bGxvdmVyLSBUaW1lb3V0LSBOb25GYXRhbEVycisNCgkJQ0VNc2s6CVJ4RXJyLSBCYWRUTFAt
IEJhZERMTFAtIFJvbGxvdmVyLSBUaW1lb3V0LSBOb25GYXRhbEVycisNCgkJQUVSQ2FwOglG
aXJzdCBFcnJvciBQb2ludGVyOiAwMCwgR2VuQ2FwLSBDR2VuRW4tIENoa0NhcC0gQ2hrRW4t
DQoJQ2FwYWJpbGl0aWVzOiBbMjAwIHYxXSBWaXJ0dWFsIENoYW5uZWwNCgkJQ2FwczoJTFBF
VkM9MSBSZWZDbGs9MTAwbnMgUEFURW50cnlCaXRzPTENCgkJQXJiOglGaXhlZCsgV1JSMzIr
IFdSUjY0KyBXUlIxMjgtDQoJCUN0cmw6CUFyYlNlbGVjdD1XUlI2NA0KCQlTdGF0dXM6CUlu
UHJvZ3Jlc3MtDQoJCVBvcnQgQXJiaXRyYXRpb24gVGFibGUgWzI0MF0gPD8+DQoJCVZDMDoJ
Q2FwczoJUEFUT2Zmc2V0PTAwIE1heFRpbWVTbG90cz0xIFJlalNub29wVHJhbnMtDQoJCQlB
cmI6CUZpeGVkLSBXUlIzMi0gV1JSNjQtIFdSUjEyOC0gVFdSUjEyOC0gV1JSMjU2LQ0KCQkJ
Q3RybDoJRW5hYmxlKyBJRD0wIEFyYlNlbGVjdD1GaXhlZCBUQy9WQz1mZg0KCQkJU3RhdHVz
OglOZWdvUGVuZGluZy0gSW5Qcm9ncmVzcy0NCgkJVkMxOglDYXBzOglQQVRPZmZzZXQ9MDAg
TWF4VGltZVNsb3RzPTEgUmVqU25vb3BUcmFucy0NCgkJCUFyYjoJRml4ZWQtIFdSUjMyLSBX
UlI2NC0gV1JSMTI4LSBUV1JSMTI4LSBXUlIyNTYtDQoJCQlDdHJsOglFbmFibGUtIElEPTEg
QXJiU2VsZWN0PUZpeGVkIFRDL1ZDPTAwDQoJCQlTdGF0dXM6CU5lZ29QZW5kaW5nLSBJblBy
b2dyZXNzLQ0KCUtlcm5lbCBkcml2ZXIgaW4gdXNlOiBwY2liYWNrDQoNCjA4OjAwLjAgRXRo
ZXJuZXQgY29udHJvbGxlciBbMDIwMF06IFJlYWx0ZWsgU2VtaWNvbmR1Y3RvciBDby4sIEx0
ZC4gUlRMODExMS84MTY4QiBQQ0kgRXhwcmVzcyBHaWdhYml0IEV0aGVybmV0IGNvbnRyb2xs
ZXIgWzEwZWM6ODE2OF0gKHJldiAwMykNCglTdWJzeXN0ZW06IE1pY3JvLVN0YXIgSW50ZXJu
YXRpb25hbCBDby4sIEx0ZC4gRGV2aWNlIFsxNDYyOjc2NDBdDQoJQ29udHJvbDogSS9PKyBN
ZW0rIEJ1c01hc3RlcisgU3BlY0N5Y2xlLSBNZW1XSU5WLSBWR0FTbm9vcC0gUGFyRXJyLSBT
dGVwcGluZy0gU0VSUisgRmFzdEIyQi0gRGlzSU5UeCsNCglTdGF0dXM6IENhcCsgNjZNSHot
IFVERi0gRmFzdEIyQi0gUGFyRXJyLSBERVZTRUw9ZmFzdCA+VEFib3J0LSA8VEFib3J0LSA8
TUFib3J0LSA+U0VSUi0gPFBFUlItIElOVHgtDQoJTGF0ZW5jeTogMCwgQ2FjaGUgTGluZSBT
aXplOiA2NCBieXRlcw0KCUludGVycnVwdDogcGluIEEgcm91dGVkIHRvIElSUSAxMjINCglS
ZWdpb24gMDogSS9PIHBvcnRzIGF0IGM4MDAgW3NpemU9MjU2XQ0KCVJlZ2lvbiAyOiBNZW1v
cnkgYXQgY2ZlZmYwMDAgKDY0LWJpdCwgcHJlZmV0Y2hhYmxlKSBbc2l6ZT00S10NCglSZWdp
b24gNDogTWVtb3J5IGF0IGNmZWY4MDAwICg2NC1iaXQsIHByZWZldGNoYWJsZSkgW3NpemU9
MTZLXQ0KCUV4cGFuc2lvbiBST00gYXQgZjlkZTAwMDAgW2Rpc2FibGVkXSBbc2l6ZT0xMjhL
XQ0KCUNhcGFiaWxpdGllczogWzQwXSBQb3dlciBNYW5hZ2VtZW50IHZlcnNpb24gMw0KCQlG
bGFnczogUE1FQ2xrLSBEU0ktIEQxKyBEMisgQXV4Q3VycmVudD0zNzVtQSBQTUUoRDArLEQx
KyxEMissRDNob3QrLEQzY29sZCspDQoJCVN0YXR1czogRDAgTm9Tb2Z0UnN0KyBQTUUtRW5h
YmxlLSBEU2VsPTAgRFNjYWxlPTAgUE1FLQ0KCUNhcGFiaWxpdGllczogWzUwXSBNU0k6IEVu
YWJsZSsgQ291bnQ9MS8xIE1hc2thYmxlLSA2NGJpdCsNCgkJQWRkcmVzczogMDAwMDAwMDBm
ZWUwMTAwYyAgRGF0YTogNDFkOQ0KCUNhcGFiaWxpdGllczogWzcwXSBFeHByZXNzICh2Mikg
RW5kcG9pbnQsIE1TSSAwMQ0KCQlEZXZDYXA6CU1heFBheWxvYWQgMjU2IGJ5dGVzLCBQaGFu
dEZ1bmMgMCwgTGF0ZW5jeSBMMHMgPDUxMm5zLCBMMSA8NjR1cw0KCQkJRXh0VGFnLSBBdHRu
QnRuLSBBdHRuSW5kLSBQd3JJbmQtIFJCRSsgRkxSZXNldC0NCgkJRGV2Q3RsOglSZXBvcnQg
ZXJyb3JzOiBDb3JyZWN0YWJsZS0gTm9uLUZhdGFsLSBGYXRhbC0gVW5zdXBwb3J0ZWQtDQoJ
CQlSbHhkT3JkLSBFeHRUYWctIFBoYW50RnVuYy0gQXV4UHdyLSBOb1Nub29wLQ0KCQkJTWF4
UGF5bG9hZCAxMjggYnl0ZXMsIE1heFJlYWRSZXEgNTEyIGJ5dGVzDQoJCURldlN0YToJQ29y
ckVycisgVW5jb3JyRXJyLSBGYXRhbEVyci0gVW5zdXBwUmVxKyBBdXhQd3IrIFRyYW5zUGVu
ZC0NCgkJTG5rQ2FwOglQb3J0ICMwLCBTcGVlZCAyLjVHVC9zLCBXaWR0aCB4MSwgQVNQTSBM
MHMgTDEsIExhdGVuY3kgTDAgPDUxMm5zLCBMMSA8NjR1cw0KCQkJQ2xvY2tQTSsgU3VycHJp
c2UtIExMQWN0UmVwLSBCd05vdC0NCgkJTG5rQ3RsOglBU1BNIERpc2FibGVkOyBSQ0IgNjQg
Ynl0ZXMgRGlzYWJsZWQtIFJldHJhaW4tIENvbW1DbGsrDQoJCQlFeHRTeW5jaC0gQ2xvY2tQ
TS0gQXV0V2lkRGlzLSBCV0ludC0gQXV0QldJbnQtDQoJCUxua1N0YToJU3BlZWQgMi41R1Qv
cywgV2lkdGggeDEsIFRyRXJyLSBUcmFpbi0gU2xvdENsaysgRExBY3RpdmUtIEJXTWdtdC0g
QUJXTWdtdC0NCgkJRGV2Q2FwMjogQ29tcGxldGlvbiBUaW1lb3V0OiBOb3QgU3VwcG9ydGVk
LCBUaW1lb3V0RGlzKw0KCQlEZXZDdGwyOiBDb21wbGV0aW9uIFRpbWVvdXQ6IDUwdXMgdG8g
NTBtcywgVGltZW91dERpcy0NCgkJTG5rQ3RsMjogVGFyZ2V0IExpbmsgU3BlZWQ6IDIuNUdU
L3MsIEVudGVyQ29tcGxpYW5jZS0gU3BlZWREaXMtLCBTZWxlY3RhYmxlIERlLWVtcGhhc2lz
OiAtNmRCDQoJCQkgVHJhbnNtaXQgTWFyZ2luOiBOb3JtYWwgT3BlcmF0aW5nIFJhbmdlLCBF
bnRlck1vZGlmaWVkQ29tcGxpYW5jZS0gQ29tcGxpYW5jZVNPUy0NCgkJCSBDb21wbGlhbmNl
IERlLWVtcGhhc2lzOiAtNmRCDQoJCUxua1N0YTI6IEN1cnJlbnQgRGUtZW1waGFzaXMgTGV2
ZWw6IC02ZEINCglDYXBhYmlsaXRpZXM6IFthY10gTVNJLVg6IEVuYWJsZS0gQ291bnQ9NCBN
YXNrZWQtDQoJCVZlY3RvciB0YWJsZTogQkFSPTQgb2Zmc2V0PTAwMDAwMDAwDQoJCVBCQTog
QkFSPTQgb2Zmc2V0PTAwMDAwODAwDQoJQ2FwYWJpbGl0aWVzOiBbY2NdIFZpdGFsIFByb2R1
Y3QgRGF0YQ0KCQlVbmtub3duIHNtYWxsIHJlc291cmNlIHR5cGUgMDAsIHdpbGwgbm90IGRl
Y29kZSBtb3JlLg0KCUNhcGFiaWxpdGllczogWzEwMCB2MV0gQWR2YW5jZWQgRXJyb3IgUmVw
b3J0aW5nDQoJCVVFU3RhOglETFAtIFNERVMtIFRMUC0gRkNQLSBDbXBsdFRPLSBDbXBsdEFi
cnQtIFVueENtcGx0LSBSeE9GLSBNYWxmVExQLSBFQ1JDLSBVbnN1cFJlcS0gQUNTVmlvbC0N
CgkJVUVNc2s6CURMUC0gU0RFUy0gVExQLSBGQ1AtIENtcGx0VE8tIENtcGx0QWJydC0gVW54
Q21wbHQtIFJ4T0YtIE1hbGZUTFAtIEVDUkMtIFVuc3VwUmVxLSBBQ1NWaW9sLQ0KCQlVRVN2
cnQ6CURMUCsgU0RFUysgVExQLSBGQ1ArIENtcGx0VE8tIENtcGx0QWJydC0gVW54Q21wbHQt
IFJ4T0YrIE1hbGZUTFArIEVDUkMtIFVuc3VwUmVxLSBBQ1NWaW9sLQ0KCQlDRVN0YToJUnhF
cnIrIEJhZFRMUC0gQmFkRExMUC0gUm9sbG92ZXItIFRpbWVvdXQtIE5vbkZhdGFsRXJyKw0K
CQlDRU1zazoJUnhFcnItIEJhZFRMUC0gQmFkRExMUC0gUm9sbG92ZXItIFRpbWVvdXQtIE5v
bkZhdGFsRXJyKw0KCQlBRVJDYXA6CUZpcnN0IEVycm9yIFBvaW50ZXI6IDAwLCBHZW5DYXAr
IENHZW5Fbi0gQ2hrQ2FwKyBDaGtFbi0NCglDYXBhYmlsaXRpZXM6IFsxNDAgdjFdIFZpcnR1
YWwgQ2hhbm5lbA0KCQlDYXBzOglMUEVWQz0wIFJlZkNsaz0xMDBucyBQQVRFbnRyeUJpdHM9
MQ0KCQlBcmI6CUZpeGVkLSBXUlIzMi0gV1JSNjQtIFdSUjEyOC0NCgkJQ3RybDoJQXJiU2Vs
ZWN0PUZpeGVkDQoJCVN0YXR1czoJSW5Qcm9ncmVzcy0NCgkJVkMwOglDYXBzOglQQVRPZmZz
ZXQ9MDAgTWF4VGltZVNsb3RzPTEgUmVqU25vb3BUcmFucy0NCgkJCUFyYjoJRml4ZWQtIFdS
UjMyLSBXUlI2NC0gV1JSMTI4LSBUV1JSMTI4LSBXUlIyNTYtDQoJCQlDdHJsOglFbmFibGUr
IElEPTAgQXJiU2VsZWN0PUZpeGVkIFRDL1ZDPWZmDQoJCQlTdGF0dXM6CU5lZ29QZW5kaW5n
LSBJblByb2dyZXNzLQ0KCUNhcGFiaWxpdGllczogWzE2MCB2MV0gRGV2aWNlIFNlcmlhbCBO
dW1iZXIgMDMtMDAtMDAtMDAtNjgtNGMtZTAtMDANCglLZXJuZWwgZHJpdmVyIGluIHVzZTog
cjgxNjkNCg0KMDk6MDAuMCBFdGhlcm5ldCBjb250cm9sbGVyIFswMjAwXTogUmVhbHRlayBT
ZW1pY29uZHVjdG9yIENvLiwgTHRkLiBSVEw4MTExLzgxNjhCIFBDSSBFeHByZXNzIEdpZ2Fi
aXQgRXRoZXJuZXQgY29udHJvbGxlciBbMTBlYzo4MTY4XSAocmV2IDAzKQ0KCVN1YnN5c3Rl
bTogTWljcm8tU3RhciBJbnRlcm5hdGlvbmFsIENvLiwgTHRkLiBEZXZpY2UgWzE0NjI6NzY0
MF0NCglDb250cm9sOiBJL08rIE1lbSsgQnVzTWFzdGVyKyBTcGVjQ3ljbGUtIE1lbVdJTlYt
IFZHQVNub29wLSBQYXJFcnItIFN0ZXBwaW5nLSBTRVJSKyBGYXN0QjJCLSBEaXNJTlR4Kw0K
CVN0YXR1czogQ2FwKyA2Nk1Iei0gVURGLSBGYXN0QjJCLSBQYXJFcnItIERFVlNFTD1mYXN0
ID5UQWJvcnQtIDxUQWJvcnQtIDxNQWJvcnQtID5TRVJSLSA8UEVSUi0gSU5UeC0NCglMYXRl
bmN5OiAwLCBDYWNoZSBMaW5lIFNpemU6IDY0IGJ5dGVzDQoJSW50ZXJydXB0OiBwaW4gQSBy
b3V0ZWQgdG8gSVJRIDEyMQ0KCVJlZ2lvbiAwOiBJL08gcG9ydHMgYXQgZDgwMCBbc2l6ZT0y
NTZdDQoJUmVnaW9uIDI6IE1lbW9yeSBhdCBjZmZmZjAwMCAoNjQtYml0LCBwcmVmZXRjaGFi
bGUpIFtzaXplPTRLXQ0KCVJlZ2lvbiA0OiBNZW1vcnkgYXQgY2ZmZjgwMDAgKDY0LWJpdCwg
cHJlZmV0Y2hhYmxlKSBbc2l6ZT0xNktdDQoJRXhwYW5zaW9uIFJPTSBhdCBmOWVlMDAwMCBb
ZGlzYWJsZWRdIFtzaXplPTEyOEtdDQoJQ2FwYWJpbGl0aWVzOiBbNDBdIFBvd2VyIE1hbmFn
ZW1lbnQgdmVyc2lvbiAzDQoJCUZsYWdzOiBQTUVDbGstIERTSS0gRDErIEQyKyBBdXhDdXJy
ZW50PTM3NW1BIFBNRShEMCssRDErLEQyKyxEM2hvdCssRDNjb2xkKykNCgkJU3RhdHVzOiBE
MCBOb1NvZnRSc3QrIFBNRS1FbmFibGUtIERTZWw9MCBEU2NhbGU9MCBQTUUtDQoJQ2FwYWJp
bGl0aWVzOiBbNTBdIE1TSTogRW5hYmxlKyBDb3VudD0xLzEgTWFza2FibGUtIDY0Yml0Kw0K
CQlBZGRyZXNzOiAwMDAwMDAwMGZlZTAxMDBjICBEYXRhOiA0MWM5DQoJQ2FwYWJpbGl0aWVz
OiBbNzBdIEV4cHJlc3MgKHYyKSBFbmRwb2ludCwgTVNJIDAxDQoJCURldkNhcDoJTWF4UGF5
bG9hZCAyNTYgYnl0ZXMsIFBoYW50RnVuYyAwLCBMYXRlbmN5IEwwcyA8NTEybnMsIEwxIDw2
NHVzDQoJCQlFeHRUYWctIEF0dG5CdG4tIEF0dG5JbmQtIFB3ckluZC0gUkJFKyBGTFJlc2V0
LQ0KCQlEZXZDdGw6CVJlcG9ydCBlcnJvcnM6IENvcnJlY3RhYmxlLSBOb24tRmF0YWwtIEZh
dGFsLSBVbnN1cHBvcnRlZC0NCgkJCVJseGRPcmQtIEV4dFRhZy0gUGhhbnRGdW5jLSBBdXhQ
d3ItIE5vU25vb3AtDQoJCQlNYXhQYXlsb2FkIDEyOCBieXRlcywgTWF4UmVhZFJlcSA0MDk2
IGJ5dGVzDQoJCURldlN0YToJQ29yckVycisgVW5jb3JyRXJyLSBGYXRhbEVyci0gVW5zdXBw
UmVxKyBBdXhQd3IrIFRyYW5zUGVuZC0NCgkJTG5rQ2FwOglQb3J0ICMwLCBTcGVlZCAyLjVH
VC9zLCBXaWR0aCB4MSwgQVNQTSBMMHMgTDEsIExhdGVuY3kgTDAgPDUxMm5zLCBMMSA8NjR1
cw0KCQkJQ2xvY2tQTSsgU3VycHJpc2UtIExMQWN0UmVwLSBCd05vdC0NCgkJTG5rQ3RsOglB
U1BNIERpc2FibGVkOyBSQ0IgNjQgYnl0ZXMgRGlzYWJsZWQtIFJldHJhaW4tIENvbW1DbGsr
DQoJCQlFeHRTeW5jaC0gQ2xvY2tQTS0gQXV0V2lkRGlzLSBCV0ludC0gQXV0QldJbnQtDQoJ
CUxua1N0YToJU3BlZWQgMi41R1QvcywgV2lkdGggeDEsIFRyRXJyLSBUcmFpbi0gU2xvdENs
aysgRExBY3RpdmUtIEJXTWdtdC0gQUJXTWdtdC0NCgkJRGV2Q2FwMjogQ29tcGxldGlvbiBU
aW1lb3V0OiBOb3QgU3VwcG9ydGVkLCBUaW1lb3V0RGlzKw0KCQlEZXZDdGwyOiBDb21wbGV0
aW9uIFRpbWVvdXQ6IDUwdXMgdG8gNTBtcywgVGltZW91dERpcy0NCgkJTG5rQ3RsMjogVGFy
Z2V0IExpbmsgU3BlZWQ6IDIuNUdUL3MsIEVudGVyQ29tcGxpYW5jZS0gU3BlZWREaXMtLCBT
ZWxlY3RhYmxlIERlLWVtcGhhc2lzOiAtNmRCDQoJCQkgVHJhbnNtaXQgTWFyZ2luOiBOb3Jt
YWwgT3BlcmF0aW5nIFJhbmdlLCBFbnRlck1vZGlmaWVkQ29tcGxpYW5jZS0gQ29tcGxpYW5j
ZVNPUy0NCgkJCSBDb21wbGlhbmNlIERlLWVtcGhhc2lzOiAtNmRCDQoJCUxua1N0YTI6IEN1
cnJlbnQgRGUtZW1waGFzaXMgTGV2ZWw6IC02ZEINCglDYXBhYmlsaXRpZXM6IFthY10gTVNJ
LVg6IEVuYWJsZS0gQ291bnQ9NCBNYXNrZWQtDQoJCVZlY3RvciB0YWJsZTogQkFSPTQgb2Zm
c2V0PTAwMDAwMDAwDQoJCVBCQTogQkFSPTQgb2Zmc2V0PTAwMDAwODAwDQoJQ2FwYWJpbGl0
aWVzOiBbY2NdIFZpdGFsIFByb2R1Y3QgRGF0YQ0KCQlVbmtub3duIHNtYWxsIHJlc291cmNl
IHR5cGUgMDAsIHdpbGwgbm90IGRlY29kZSBtb3JlLg0KCUNhcGFiaWxpdGllczogWzEwMCB2
MV0gQWR2YW5jZWQgRXJyb3IgUmVwb3J0aW5nDQoJCVVFU3RhOglETFAtIFNERVMtIFRMUC0g
RkNQLSBDbXBsdFRPLSBDbXBsdEFicnQtIFVueENtcGx0LSBSeE9GLSBNYWxmVExQLSBFQ1JD
LSBVbnN1cFJlcS0gQUNTVmlvbC0NCgkJVUVNc2s6CURMUC0gU0RFUy0gVExQLSBGQ1AtIENt
cGx0VE8tIENtcGx0QWJydC0gVW54Q21wbHQtIFJ4T0YtIE1hbGZUTFAtIEVDUkMtIFVuc3Vw
UmVxLSBBQ1NWaW9sLQ0KCQlVRVN2cnQ6CURMUCsgU0RFUysgVExQLSBGQ1ArIENtcGx0VE8t
IENtcGx0QWJydC0gVW54Q21wbHQtIFJ4T0YrIE1hbGZUTFArIEVDUkMtIFVuc3VwUmVxLSBB
Q1NWaW9sLQ0KCQlDRVN0YToJUnhFcnIrIEJhZFRMUC0gQmFkRExMUC0gUm9sbG92ZXItIFRp
bWVvdXQtIE5vbkZhdGFsRXJyKw0KCQlDRU1zazoJUnhFcnItIEJhZFRMUC0gQmFkRExMUC0g
Um9sbG92ZXItIFRpbWVvdXQtIE5vbkZhdGFsRXJyKw0KCQlBRVJDYXA6CUZpcnN0IEVycm9y
IFBvaW50ZXI6IDAwLCBHZW5DYXArIENHZW5Fbi0gQ2hrQ2FwKyBDaGtFbi0NCglDYXBhYmls
aXRpZXM6IFsxNDAgdjFdIFZpcnR1YWwgQ2hhbm5lbA0KCQlDYXBzOglMUEVWQz0wIFJlZkNs
az0xMDBucyBQQVRFbnRyeUJpdHM9MQ0KCQlBcmI6CUZpeGVkLSBXUlIzMi0gV1JSNjQtIFdS
UjEyOC0NCgkJQ3RybDoJQXJiU2VsZWN0PUZpeGVkDQoJCVN0YXR1czoJSW5Qcm9ncmVzcy0N
CgkJVkMwOglDYXBzOglQQVRPZmZzZXQ9MDAgTWF4VGltZVNsb3RzPTEgUmVqU25vb3BUcmFu
cy0NCgkJCUFyYjoJRml4ZWQtIFdSUjMyLSBXUlI2NC0gV1JSMTI4LSBUV1JSMTI4LSBXUlIy
NTYtDQoJCQlDdHJsOglFbmFibGUrIElEPTAgQXJiU2VsZWN0PUZpeGVkIFRDL1ZDPWZmDQoJ
CQlTdGF0dXM6CU5lZ29QZW5kaW5nLSBJblByb2dyZXNzLQ0KCUNhcGFiaWxpdGllczogWzE2
MCB2MV0gRGV2aWNlIFNlcmlhbCBOdW1iZXIgMDQtMDAtMDAtMDAtNjgtNGMtZTAtMDANCglL
ZXJuZWwgZHJpdmVyIGluIHVzZTogcjgxNjkNCg0KMGE6MDAuMCBVU0IgY29udHJvbGxlciBb
MGMwM106IE5ldE1vcyBUZWNobm9sb2d5IE1DUzk5OTAgUENJZSB0byA04oCQUG9ydCBVU0Ig
Mi4wIEhvc3QgQ29udHJvbGxlciBbOTcxMDo5OTkwXSAocHJvZy1pZiAxMCBbT0hDSV0pDQoJ
U3Vic3lzdGVtOiBEZXZpY2UgW2EwMDA6NDAwMF0NCglDb250cm9sOiBJL08tIE1lbSsgQnVz
TWFzdGVyKyBTcGVjQ3ljbGUtIE1lbVdJTlYtIFZHQVNub29wLSBQYXJFcnItIFN0ZXBwaW5n
LSBTRVJSLSBGYXN0QjJCLSBEaXNJTlR4LQ0KCVN0YXR1czogQ2FwKyA2Nk1Iei0gVURGLSBG
YXN0QjJCLSBQYXJFcnItIERFVlNFTD1mYXN0ID5UQWJvcnQtIDxUQWJvcnQrIDxNQWJvcnQt
ID5TRVJSLSA8UEVSUi0gSU5UeC0NCglMYXRlbmN5OiAwLCBDYWNoZSBMaW5lIFNpemU6IDY0
IGJ5dGVzDQoJSW50ZXJydXB0OiBwaW4gQSByb3V0ZWQgdG8gSVJRIDI4DQoJUmVnaW9uIDA6
IE1lbW9yeSBhdCBmOWZmODAwMCAoMzItYml0LCBub24tcHJlZmV0Y2hhYmxlKSBbc2l6ZT00
S10NCglDYXBhYmlsaXRpZXM6IFs1MF0gTVNJOiBFbmFibGUtIENvdW50PTEvMSBNYXNrYWJs
ZS0gNjRiaXQrDQoJCUFkZHJlc3M6IDAwMDAwMDAwMDAwMDAwMDAgIERhdGE6IDAwMDANCglD
YXBhYmlsaXRpZXM6IFs3OF0gUG93ZXIgTWFuYWdlbWVudCB2ZXJzaW9uIDMNCgkJRmxhZ3M6
IFBNRUNsay0gRFNJLSBEMSsgRDIrIEF1eEN1cnJlbnQ9Mzc1bUEgUE1FKEQwKyxEMSssRDIr
LEQzaG90KyxEM2NvbGQtKQ0KCQlTdGF0dXM6IEQwIE5vU29mdFJzdCsgUE1FLUVuYWJsZS0g
RFNlbD0wIERTY2FsZT0wIFBNRS0NCglDYXBhYmlsaXRpZXM6IFs4MF0gRXhwcmVzcyAodjEp
IEVuZHBvaW50LCBNU0kgMDANCgkJRGV2Q2FwOglNYXhQYXlsb2FkIDI1NiBieXRlcywgUGhh
bnRGdW5jIDAsIExhdGVuY3kgTDBzIHVubGltaXRlZCwgTDEgdW5saW1pdGVkDQoJCQlFeHRU
YWctIEF0dG5CdG4tIEF0dG5JbmQtIFB3ckluZC0gUkJFKyBGTFJlc2V0LQ0KCQlEZXZDdGw6
CVJlcG9ydCBlcnJvcnM6IENvcnJlY3RhYmxlLSBOb24tRmF0YWwtIEZhdGFsLSBVbnN1cHBv
cnRlZC0NCgkJCVJseGRPcmQtIEV4dFRhZy0gUGhhbnRGdW5jLSBBdXhQd3ItIE5vU25vb3Ar
DQoJCQlNYXhQYXlsb2FkIDEyOCBieXRlcywgTWF4UmVhZFJlcSA1MTIgYnl0ZXMNCgkJRGV2
U3RhOglDb3JyRXJyLSBVbmNvcnJFcnItIEZhdGFsRXJyLSBVbnN1cHBSZXEtIEF1eFB3ci0g
VHJhbnNQZW5kLQ0KCQlMbmtDYXA6CVBvcnQgIzEsIFNwZWVkIDIuNUdUL3MsIFdpZHRoIHgx
LCBBU1BNIHVua25vd24sIExhdGVuY3kgTDAgPDY0bnMsIEwxIHVubGltaXRlZA0KCQkJQ2xv
Y2tQTSsgU3VycHJpc2UtIExMQWN0UmVwLSBCd05vdC0NCgkJTG5rQ3RsOglBU1BNIERpc2Fi
bGVkOyBSQ0IgNjQgYnl0ZXMgRGlzYWJsZWQtIFJldHJhaW4tIENvbW1DbGstDQoJCQlFeHRT
eW5jaC0gQ2xvY2tQTS0gQXV0V2lkRGlzLSBCV0ludC0gQXV0QldJbnQtDQoJCUxua1N0YToJ
U3BlZWQgMi41R1QvcywgV2lkdGggeDEsIFRyRXJyLSBUcmFpbi0gU2xvdENsay0gRExBY3Rp
dmUtIEJXTWdtdC0gQUJXTWdtdC0NCglDYXBhYmlsaXRpZXM6IFsxMDAgdjFdIFZpcnR1YWwg
Q2hhbm5lbA0KCQlDYXBzOglMUEVWQz0wIFJlZkNsaz0xMDBucyBQQVRFbnRyeUJpdHM9MQ0K
CQlBcmI6CUZpeGVkLSBXUlIzMi0gV1JSNjQtIFdSUjEyOC0NCgkJQ3RybDoJQXJiU2VsZWN0
PUZpeGVkDQoJCVN0YXR1czoJSW5Qcm9ncmVzcy0NCgkJVkMwOglDYXBzOglQQVRPZmZzZXQ9
MDAgTWF4VGltZVNsb3RzPTEgUmVqU25vb3BUcmFucy0NCgkJCUFyYjoJRml4ZWQtIFdSUjMy
LSBXUlI2NC0gV1JSMTI4LSBUV1JSMTI4LSBXUlIyNTYtDQoJCQlDdHJsOglFbmFibGUrIElE
PTAgQXJiU2VsZWN0PUZpeGVkIFRDL1ZDPWZmDQoJCQlTdGF0dXM6CU5lZ29QZW5kaW5nLSBJ
blByb2dyZXNzLQ0KCUtlcm5lbCBkcml2ZXIgaW4gdXNlOiBwY2liYWNrDQoNCjBhOjAwLjEg
VVNCIGNvbnRyb2xsZXIgWzBjMDNdOiBOZXRNb3MgVGVjaG5vbG9neSBNQ1M5OTkwIFBDSWUg
dG8gNOKAkFBvcnQgVVNCIDIuMCBIb3N0IENvbnRyb2xsZXIgWzk3MTA6OTk5MF0gKHByb2ct
aWYgMjAgW0VIQ0ldKQ0KCVN1YnN5c3RlbTogRGV2aWNlIFthMDAwOjQwMDBdDQoJQ29udHJv
bDogSS9PLSBNZW0rIEJ1c01hc3RlcisgU3BlY0N5Y2xlLSBNZW1XSU5WLSBWR0FTbm9vcC0g
UGFyRXJyLSBTdGVwcGluZy0gU0VSUi0gRmFzdEIyQi0gRGlzSU5UeC0NCglTdGF0dXM6IENh
cCsgNjZNSHotIFVERi0gRmFzdEIyQi0gUGFyRXJyLSBERVZTRUw9ZmFzdCA+VEFib3J0LSA8
VEFib3J0KyA8TUFib3J0LSA+U0VSUi0gPFBFUlItIElOVHgtDQoJTGF0ZW5jeTogMCwgQ2Fj
aGUgTGluZSBTaXplOiA2NCBieXRlcw0KCUludGVycnVwdDogcGluIEEgcm91dGVkIHRvIElS
USAyOA0KCVJlZ2lvbiAwOiBNZW1vcnkgYXQgZjlmZjkwMDAgKDMyLWJpdCwgbm9uLXByZWZl
dGNoYWJsZSkgW3NpemU9NEtdDQoJQ2FwYWJpbGl0aWVzOiBbNTBdIE1TSTogRW5hYmxlLSBD
b3VudD0xLzEgTWFza2FibGUtIDY0Yml0Kw0KCQlBZGRyZXNzOiAwMDAwMDAwMDAwMDAwMDAw
ICBEYXRhOiAwMDAwDQoJQ2FwYWJpbGl0aWVzOiBbNzhdIFBvd2VyIE1hbmFnZW1lbnQgdmVy
c2lvbiAzDQoJCUZsYWdzOiBQTUVDbGstIERTSS0gRDErIEQyKyBBdXhDdXJyZW50PTM3NW1B
IFBNRShEMCssRDErLEQyKyxEM2hvdCssRDNjb2xkLSkNCgkJU3RhdHVzOiBEMCBOb1NvZnRS
c3QrIFBNRS1FbmFibGUtIERTZWw9MCBEU2NhbGU9MCBQTUUtDQoJQ2FwYWJpbGl0aWVzOiBb
ODBdIEV4cHJlc3MgKHYxKSBFbmRwb2ludCwgTVNJIDAwDQoJCURldkNhcDoJTWF4UGF5bG9h
ZCAyNTYgYnl0ZXMsIFBoYW50RnVuYyAwLCBMYXRlbmN5IEwwcyB1bmxpbWl0ZWQsIEwxIHVu
bGltaXRlZA0KCQkJRXh0VGFnLSBBdHRuQnRuLSBBdHRuSW5kLSBQd3JJbmQtIFJCRSsgRkxS
ZXNldC0NCgkJRGV2Q3RsOglSZXBvcnQgZXJyb3JzOiBDb3JyZWN0YWJsZS0gTm9uLUZhdGFs
LSBGYXRhbC0gVW5zdXBwb3J0ZWQtDQoJCQlSbHhkT3JkLSBFeHRUYWctIFBoYW50RnVuYy0g
QXV4UHdyLSBOb1Nub29wKw0KCQkJTWF4UGF5bG9hZCAxMjggYnl0ZXMsIE1heFJlYWRSZXEg
NTEyIGJ5dGVzDQoJCURldlN0YToJQ29yckVyci0gVW5jb3JyRXJyLSBGYXRhbEVyci0gVW5z
dXBwUmVxLSBBdXhQd3ItIFRyYW5zUGVuZC0NCgkJTG5rQ2FwOglQb3J0ICMxLCBTcGVlZCAy
LjVHVC9zLCBXaWR0aCB4MSwgQVNQTSB1bmtub3duLCBMYXRlbmN5IEwwIDw2NG5zLCBMMSB1
bmxpbWl0ZWQNCgkJCUNsb2NrUE0rIFN1cnByaXNlLSBMTEFjdFJlcC0gQndOb3QtDQoJCUxu
a0N0bDoJQVNQTSBEaXNhYmxlZDsgUkNCIDY0IGJ5dGVzIERpc2FibGVkLSBSZXRyYWluLSBD
b21tQ2xrLQ0KCQkJRXh0U3luY2gtIENsb2NrUE0tIEF1dFdpZERpcy0gQldJbnQtIEF1dEJX
SW50LQ0KCQlMbmtTdGE6CVNwZWVkIDIuNUdUL3MsIFdpZHRoIHgxLCBUckVyci0gVHJhaW4t
IFNsb3RDbGstIERMQWN0aXZlLSBCV01nbXQtIEFCV01nbXQtDQoJS2VybmVsIGRyaXZlciBp
biB1c2U6IHBjaWJhY2sNCg0KMGE6MDAuMiBVU0IgY29udHJvbGxlciBbMGMwM106IE5ldE1v
cyBUZWNobm9sb2d5IE1DUzk5OTAgUENJZSB0byA04oCQUG9ydCBVU0IgMi4wIEhvc3QgQ29u
dHJvbGxlciBbOTcxMDo5OTkwXSAocHJvZy1pZiAxMCBbT0hDSV0pDQoJU3Vic3lzdGVtOiBE
ZXZpY2UgW2EwMDA6NDAwMF0NCglDb250cm9sOiBJL08tIE1lbSsgQnVzTWFzdGVyKyBTcGVj
Q3ljbGUtIE1lbVdJTlYtIFZHQVNub29wLSBQYXJFcnItIFN0ZXBwaW5nLSBTRVJSLSBGYXN0
QjJCLSBEaXNJTlR4LQ0KCVN0YXR1czogQ2FwKyA2Nk1Iei0gVURGLSBGYXN0QjJCLSBQYXJF
cnItIERFVlNFTD1mYXN0ID5UQWJvcnQtIDxUQWJvcnQrIDxNQWJvcnQtID5TRVJSLSA8UEVS
Ui0gSU5UeC0NCglMYXRlbmN5OiAwLCBDYWNoZSBMaW5lIFNpemU6IDY0IGJ5dGVzDQoJSW50
ZXJydXB0OiBwaW4gQiByb3V0ZWQgdG8gSVJRIDI5DQoJUmVnaW9uIDA6IE1lbW9yeSBhdCBm
OWZmYTAwMCAoMzItYml0LCBub24tcHJlZmV0Y2hhYmxlKSBbc2l6ZT00S10NCglDYXBhYmls
aXRpZXM6IFs1MF0gTVNJOiBFbmFibGUtIENvdW50PTEvMSBNYXNrYWJsZS0gNjRiaXQrDQoJ
CUFkZHJlc3M6IDAwMDAwMDAwMDAwMDAwMDAgIERhdGE6IDAwMDANCglDYXBhYmlsaXRpZXM6
IFs3OF0gUG93ZXIgTWFuYWdlbWVudCB2ZXJzaW9uIDMNCgkJRmxhZ3M6IFBNRUNsay0gRFNJ
LSBEMSsgRDIrIEF1eEN1cnJlbnQ9Mzc1bUEgUE1FKEQwKyxEMSssRDIrLEQzaG90KyxEM2Nv
bGQtKQ0KCQlTdGF0dXM6IEQwIE5vU29mdFJzdCsgUE1FLUVuYWJsZS0gRFNlbD0wIERTY2Fs
ZT0wIFBNRS0NCglDYXBhYmlsaXRpZXM6IFs4MF0gRXhwcmVzcyAodjEpIEVuZHBvaW50LCBN
U0kgMDANCgkJRGV2Q2FwOglNYXhQYXlsb2FkIDI1NiBieXRlcywgUGhhbnRGdW5jIDAsIExh
dGVuY3kgTDBzIHVubGltaXRlZCwgTDEgdW5saW1pdGVkDQoJCQlFeHRUYWctIEF0dG5CdG4t
IEF0dG5JbmQtIFB3ckluZC0gUkJFKyBGTFJlc2V0LQ0KCQlEZXZDdGw6CVJlcG9ydCBlcnJv
cnM6IENvcnJlY3RhYmxlLSBOb24tRmF0YWwtIEZhdGFsLSBVbnN1cHBvcnRlZC0NCgkJCVJs
eGRPcmQtIEV4dFRhZy0gUGhhbnRGdW5jLSBBdXhQd3ItIE5vU25vb3ArDQoJCQlNYXhQYXls
b2FkIDEyOCBieXRlcywgTWF4UmVhZFJlcSA1MTIgYnl0ZXMNCgkJRGV2U3RhOglDb3JyRXJy
LSBVbmNvcnJFcnItIEZhdGFsRXJyLSBVbnN1cHBSZXEtIEF1eFB3ci0gVHJhbnNQZW5kLQ0K
CQlMbmtDYXA6CVBvcnQgIzEsIFNwZWVkIDIuNUdUL3MsIFdpZHRoIHgxLCBBU1BNIHVua25v
d24sIExhdGVuY3kgTDAgPDY0bnMsIEwxIHVubGltaXRlZA0KCQkJQ2xvY2tQTSsgU3VycHJp
c2UtIExMQWN0UmVwLSBCd05vdC0NCgkJTG5rQ3RsOglBU1BNIERpc2FibGVkOyBSQ0IgNjQg
Ynl0ZXMgRGlzYWJsZWQtIFJldHJhaW4tIENvbW1DbGstDQoJCQlFeHRTeW5jaC0gQ2xvY2tQ
TS0gQXV0V2lkRGlzLSBCV0ludC0gQXV0QldJbnQtDQoJCUxua1N0YToJU3BlZWQgMi41R1Qv
cywgV2lkdGggeDEsIFRyRXJyLSBUcmFpbi0gU2xvdENsay0gRExBY3RpdmUtIEJXTWdtdC0g
QUJXTWdtdC0NCglLZXJuZWwgZHJpdmVyIGluIHVzZTogcGNpYmFjaw0KDQowYTowMC4zIFVT
QiBjb250cm9sbGVyIFswYzAzXTogTmV0TW9zIFRlY2hub2xvZ3kgTUNTOTk5MCBQQ0llIHRv
IDTigJBQb3J0IFVTQiAyLjAgSG9zdCBDb250cm9sbGVyIFs5NzEwOjk5OTBdIChwcm9nLWlm
IDIwIFtFSENJXSkNCglTdWJzeXN0ZW06IERldmljZSBbYTAwMDo0MDAwXQ0KCUNvbnRyb2w6
IEkvTy0gTWVtKyBCdXNNYXN0ZXIrIFNwZWNDeWNsZS0gTWVtV0lOVi0gVkdBU25vb3AtIFBh
ckVyci0gU3RlcHBpbmctIFNFUlItIEZhc3RCMkItIERpc0lOVHgtDQoJU3RhdHVzOiBDYXAr
IDY2TUh6LSBVREYtIEZhc3RCMkItIFBhckVyci0gREVWU0VMPWZhc3QgPlRBYm9ydC0gPFRB
Ym9ydCsgPE1BYm9ydC0gPlNFUlItIDxQRVJSLSBJTlR4LQ0KCUxhdGVuY3k6IDAsIENhY2hl
IExpbmUgU2l6ZTogNjQgYnl0ZXMNCglJbnRlcnJ1cHQ6IHBpbiBCIHJvdXRlZCB0byBJUlEg
MjkNCglSZWdpb24gMDogTWVtb3J5IGF0IGY5ZmZiMDAwICgzMi1iaXQsIG5vbi1wcmVmZXRj
aGFibGUpIFtzaXplPTRLXQ0KCUNhcGFiaWxpdGllczogWzUwXSBNU0k6IEVuYWJsZS0gQ291
bnQ9MS8xIE1hc2thYmxlLSA2NGJpdCsNCgkJQWRkcmVzczogMDAwMDAwMDAwMDAwMDAwMCAg
RGF0YTogMDAwMA0KCUNhcGFiaWxpdGllczogWzc4XSBQb3dlciBNYW5hZ2VtZW50IHZlcnNp
b24gMw0KCQlGbGFnczogUE1FQ2xrLSBEU0ktIEQxKyBEMisgQXV4Q3VycmVudD0zNzVtQSBQ
TUUoRDArLEQxKyxEMissRDNob3QrLEQzY29sZC0pDQoJCVN0YXR1czogRDAgTm9Tb2Z0UnN0
KyBQTUUtRW5hYmxlLSBEU2VsPTAgRFNjYWxlPTAgUE1FLQ0KCUNhcGFiaWxpdGllczogWzgw
XSBFeHByZXNzICh2MSkgRW5kcG9pbnQsIE1TSSAwMA0KCQlEZXZDYXA6CU1heFBheWxvYWQg
MjU2IGJ5dGVzLCBQaGFudEZ1bmMgMCwgTGF0ZW5jeSBMMHMgdW5saW1pdGVkLCBMMSB1bmxp
bWl0ZWQNCgkJCUV4dFRhZy0gQXR0bkJ0bi0gQXR0bkluZC0gUHdySW5kLSBSQkUrIEZMUmVz
ZXQtDQoJCURldkN0bDoJUmVwb3J0IGVycm9yczogQ29ycmVjdGFibGUtIE5vbi1GYXRhbC0g
RmF0YWwtIFVuc3VwcG9ydGVkLQ0KCQkJUmx4ZE9yZC0gRXh0VGFnLSBQaGFudEZ1bmMtIEF1
eFB3ci0gTm9Tbm9vcCsNCgkJCU1heFBheWxvYWQgMTI4IGJ5dGVzLCBNYXhSZWFkUmVxIDUx
MiBieXRlcw0KCQlEZXZTdGE6CUNvcnJFcnItIFVuY29yckVyci0gRmF0YWxFcnItIFVuc3Vw
cFJlcS0gQXV4UHdyLSBUcmFuc1BlbmQtDQoJCUxua0NhcDoJUG9ydCAjMSwgU3BlZWQgMi41
R1QvcywgV2lkdGggeDEsIEFTUE0gdW5rbm93biwgTGF0ZW5jeSBMMCA8NjRucywgTDEgdW5s
aW1pdGVkDQoJCQlDbG9ja1BNKyBTdXJwcmlzZS0gTExBY3RSZXAtIEJ3Tm90LQ0KCQlMbmtD
dGw6CUFTUE0gRGlzYWJsZWQ7IFJDQiA2NCBieXRlcyBEaXNhYmxlZC0gUmV0cmFpbi0gQ29t
bUNsay0NCgkJCUV4dFN5bmNoLSBDbG9ja1BNLSBBdXRXaWREaXMtIEJXSW50LSBBdXRCV0lu
dC0NCgkJTG5rU3RhOglTcGVlZCAyLjVHVC9zLCBXaWR0aCB4MSwgVHJFcnItIFRyYWluLSBT
bG90Q2xrLSBETEFjdGl2ZS0gQldNZ210LSBBQldNZ210LQ0KCUtlcm5lbCBkcml2ZXIgaW4g
dXNlOiBwY2liYWNrDQoNCjBhOjAwLjQgVVNCIGNvbnRyb2xsZXIgWzBjMDNdOiBOZXRNb3Mg
VGVjaG5vbG9neSBNQ1M5OTkwIFBDSWUgdG8gNOKAkFBvcnQgVVNCIDIuMCBIb3N0IENvbnRy
b2xsZXIgWzk3MTA6OTk5MF0gKHByb2ctaWYgMTAgW09IQ0ldKQ0KCVN1YnN5c3RlbTogRGV2
aWNlIFthMDAwOjQwMDBdDQoJQ29udHJvbDogSS9PLSBNZW0rIEJ1c01hc3RlcisgU3BlY0N5
Y2xlLSBNZW1XSU5WLSBWR0FTbm9vcC0gUGFyRXJyLSBTdGVwcGluZy0gU0VSUi0gRmFzdEIy
Qi0gRGlzSU5UeC0NCglTdGF0dXM6IENhcCsgNjZNSHotIFVERi0gRmFzdEIyQi0gUGFyRXJy
LSBERVZTRUw9ZmFzdCA+VEFib3J0LSA8VEFib3J0KyA8TUFib3J0LSA+U0VSUi0gPFBFUlIt
IElOVHgtDQoJTGF0ZW5jeTogMCwgQ2FjaGUgTGluZSBTaXplOiA2NCBieXRlcw0KCUludGVy
cnVwdDogcGluIEMgcm91dGVkIHRvIElSUSAzMA0KCVJlZ2lvbiAwOiBNZW1vcnkgYXQgZjlm
ZmMwMDAgKDMyLWJpdCwgbm9uLXByZWZldGNoYWJsZSkgW3NpemU9NEtdDQoJQ2FwYWJpbGl0
aWVzOiBbNTBdIE1TSTogRW5hYmxlLSBDb3VudD0xLzEgTWFza2FibGUtIDY0Yml0Kw0KCQlB
ZGRyZXNzOiAwMDAwMDAwMDAwMDAwMDAwICBEYXRhOiAwMDAwDQoJQ2FwYWJpbGl0aWVzOiBb
NzhdIFBvd2VyIE1hbmFnZW1lbnQgdmVyc2lvbiAzDQoJCUZsYWdzOiBQTUVDbGstIERTSS0g
RDErIEQyKyBBdXhDdXJyZW50PTM3NW1BIFBNRShEMCssRDErLEQyKyxEM2hvdCssRDNjb2xk
LSkNCgkJU3RhdHVzOiBEMCBOb1NvZnRSc3QrIFBNRS1FbmFibGUtIERTZWw9MCBEU2NhbGU9
MCBQTUUtDQoJQ2FwYWJpbGl0aWVzOiBbODBdIEV4cHJlc3MgKHYxKSBFbmRwb2ludCwgTVNJ
IDAwDQoJCURldkNhcDoJTWF4UGF5bG9hZCAyNTYgYnl0ZXMsIFBoYW50RnVuYyAwLCBMYXRl
bmN5IEwwcyB1bmxpbWl0ZWQsIEwxIHVubGltaXRlZA0KCQkJRXh0VGFnLSBBdHRuQnRuLSBB
dHRuSW5kLSBQd3JJbmQtIFJCRSsgRkxSZXNldC0NCgkJRGV2Q3RsOglSZXBvcnQgZXJyb3Jz
OiBDb3JyZWN0YWJsZS0gTm9uLUZhdGFsLSBGYXRhbC0gVW5zdXBwb3J0ZWQtDQoJCQlSbHhk
T3JkLSBFeHRUYWctIFBoYW50RnVuYy0gQXV4UHdyLSBOb1Nub29wKw0KCQkJTWF4UGF5bG9h
ZCAxMjggYnl0ZXMsIE1heFJlYWRSZXEgNTEyIGJ5dGVzDQoJCURldlN0YToJQ29yckVyci0g
VW5jb3JyRXJyLSBGYXRhbEVyci0gVW5zdXBwUmVxLSBBdXhQd3ItIFRyYW5zUGVuZC0NCgkJ
TG5rQ2FwOglQb3J0ICMxLCBTcGVlZCAyLjVHVC9zLCBXaWR0aCB4MSwgQVNQTSB1bmtub3du
LCBMYXRlbmN5IEwwIDw2NG5zLCBMMSB1bmxpbWl0ZWQNCgkJCUNsb2NrUE0rIFN1cnByaXNl
LSBMTEFjdFJlcC0gQndOb3QtDQoJCUxua0N0bDoJQVNQTSBEaXNhYmxlZDsgUkNCIDY0IGJ5
dGVzIERpc2FibGVkLSBSZXRyYWluLSBDb21tQ2xrLQ0KCQkJRXh0U3luY2gtIENsb2NrUE0t
IEF1dFdpZERpcy0gQldJbnQtIEF1dEJXSW50LQ0KCQlMbmtTdGE6CVNwZWVkIDIuNUdUL3Ms
IFdpZHRoIHgxLCBUckVyci0gVHJhaW4tIFNsb3RDbGstIERMQWN0aXZlLSBCV01nbXQtIEFC
V01nbXQtDQoJS2VybmVsIGRyaXZlciBpbiB1c2U6IHBjaWJhY2sNCg0KMGE6MDAuNSBVU0Ig
Y29udHJvbGxlciBbMGMwM106IE5ldE1vcyBUZWNobm9sb2d5IE1DUzk5OTAgUENJZSB0byA0
4oCQUG9ydCBVU0IgMi4wIEhvc3QgQ29udHJvbGxlciBbOTcxMDo5OTkwXSAocHJvZy1pZiAy
MCBbRUhDSV0pDQoJU3Vic3lzdGVtOiBEZXZpY2UgW2EwMDA6NDAwMF0NCglDb250cm9sOiBJ
L08tIE1lbSsgQnVzTWFzdGVyKyBTcGVjQ3ljbGUtIE1lbVdJTlYtIFZHQVNub29wLSBQYXJF
cnItIFN0ZXBwaW5nLSBTRVJSLSBGYXN0QjJCLSBEaXNJTlR4LQ0KCVN0YXR1czogQ2FwKyA2
Nk1Iei0gVURGLSBGYXN0QjJCLSBQYXJFcnItIERFVlNFTD1mYXN0ID5UQWJvcnQtIDxUQWJv
cnQrIDxNQWJvcnQtID5TRVJSLSA8UEVSUi0gSU5UeC0NCglMYXRlbmN5OiAwLCBDYWNoZSBM
aW5lIFNpemU6IDY0IGJ5dGVzDQoJSW50ZXJydXB0OiBwaW4gQyByb3V0ZWQgdG8gSVJRIDMw
DQoJUmVnaW9uIDA6IE1lbW9yeSBhdCBmOWZmZDAwMCAoMzItYml0LCBub24tcHJlZmV0Y2hh
YmxlKSBbc2l6ZT00S10NCglDYXBhYmlsaXRpZXM6IFs1MF0gTVNJOiBFbmFibGUtIENvdW50
PTEvMSBNYXNrYWJsZS0gNjRiaXQrDQoJCUFkZHJlc3M6IDAwMDAwMDAwMDAwMDAwMDAgIERh
dGE6IDAwMDANCglDYXBhYmlsaXRpZXM6IFs3OF0gUG93ZXIgTWFuYWdlbWVudCB2ZXJzaW9u
IDMNCgkJRmxhZ3M6IFBNRUNsay0gRFNJLSBEMSsgRDIrIEF1eEN1cnJlbnQ9Mzc1bUEgUE1F
KEQwKyxEMSssRDIrLEQzaG90KyxEM2NvbGQtKQ0KCQlTdGF0dXM6IEQwIE5vU29mdFJzdCsg
UE1FLUVuYWJsZS0gRFNlbD0wIERTY2FsZT0wIFBNRS0NCglDYXBhYmlsaXRpZXM6IFs4MF0g
RXhwcmVzcyAodjEpIEVuZHBvaW50LCBNU0kgMDANCgkJRGV2Q2FwOglNYXhQYXlsb2FkIDI1
NiBieXRlcywgUGhhbnRGdW5jIDAsIExhdGVuY3kgTDBzIHVubGltaXRlZCwgTDEgdW5saW1p
dGVkDQoJCQlFeHRUYWctIEF0dG5CdG4tIEF0dG5JbmQtIFB3ckluZC0gUkJFKyBGTFJlc2V0
LQ0KCQlEZXZDdGw6CVJlcG9ydCBlcnJvcnM6IENvcnJlY3RhYmxlLSBOb24tRmF0YWwtIEZh
dGFsLSBVbnN1cHBvcnRlZC0NCgkJCVJseGRPcmQtIEV4dFRhZy0gUGhhbnRGdW5jLSBBdXhQ
d3ItIE5vU25vb3ArDQoJCQlNYXhQYXlsb2FkIDEyOCBieXRlcywgTWF4UmVhZFJlcSA1MTIg
Ynl0ZXMNCgkJRGV2U3RhOglDb3JyRXJyLSBVbmNvcnJFcnItIEZhdGFsRXJyLSBVbnN1cHBS
ZXEtIEF1eFB3ci0gVHJhbnNQZW5kLQ0KCQlMbmtDYXA6CVBvcnQgIzEsIFNwZWVkIDIuNUdU
L3MsIFdpZHRoIHgxLCBBU1BNIHVua25vd24sIExhdGVuY3kgTDAgPDY0bnMsIEwxIHVubGlt
aXRlZA0KCQkJQ2xvY2tQTSsgU3VycHJpc2UtIExMQWN0UmVwLSBCd05vdC0NCgkJTG5rQ3Rs
OglBU1BNIERpc2FibGVkOyBSQ0IgNjQgYnl0ZXMgRGlzYWJsZWQtIFJldHJhaW4tIENvbW1D
bGstDQoJCQlFeHRTeW5jaC0gQ2xvY2tQTS0gQXV0V2lkRGlzLSBCV0ludC0gQXV0QldJbnQt
DQoJCUxua1N0YToJU3BlZWQgMi41R1QvcywgV2lkdGggeDEsIFRyRXJyLSBUcmFpbi0gU2xv
dENsay0gRExBY3RpdmUtIEJXTWdtdC0gQUJXTWdtdC0NCglLZXJuZWwgZHJpdmVyIGluIHVz
ZTogcGNpYmFjaw0KDQowYTowMC42IFVTQiBjb250cm9sbGVyIFswYzAzXTogTmV0TW9zIFRl
Y2hub2xvZ3kgTUNTOTk5MCBQQ0llIHRvIDTigJBQb3J0IFVTQiAyLjAgSG9zdCBDb250cm9s
bGVyIFs5NzEwOjk5OTBdIChwcm9nLWlmIDEwIFtPSENJXSkNCglTdWJzeXN0ZW06IERldmlj
ZSBbYTAwMDo0MDAwXQ0KCUNvbnRyb2w6IEkvTy0gTWVtKyBCdXNNYXN0ZXItIFNwZWNDeWNs
ZS0gTWVtV0lOVi0gVkdBU25vb3AtIFBhckVyci0gU3RlcHBpbmctIFNFUlItIEZhc3RCMkIt
IERpc0lOVHgtDQoJU3RhdHVzOiBDYXArIDY2TUh6LSBVREYtIEZhc3RCMkItIFBhckVyci0g
REVWU0VMPWZhc3QgPlRBYm9ydC0gPFRBYm9ydCsgPE1BYm9ydC0gPlNFUlItIDxQRVJSLSBJ
TlR4LQ0KCUludGVycnVwdDogcGluIEQgcm91dGVkIHRvIElSUSAzMQ0KCVJlZ2lvbiAwOiBN
ZW1vcnkgYXQgZjlmZmUwMDAgKDMyLWJpdCwgbm9uLXByZWZldGNoYWJsZSkgW3NpemU9NEtd
DQoJQ2FwYWJpbGl0aWVzOiBbNTBdIE1TSTogRW5hYmxlLSBDb3VudD0xLzEgTWFza2FibGUt
IDY0Yml0Kw0KCQlBZGRyZXNzOiAwMDAwMDAwMDAwMDAwMDAwICBEYXRhOiAwMDAwDQoJQ2Fw
YWJpbGl0aWVzOiBbNzhdIFBvd2VyIE1hbmFnZW1lbnQgdmVyc2lvbiAzDQoJCUZsYWdzOiBQ
TUVDbGstIERTSS0gRDErIEQyKyBBdXhDdXJyZW50PTM3NW1BIFBNRShEMCssRDErLEQyKyxE
M2hvdCssRDNjb2xkLSkNCgkJU3RhdHVzOiBEMCBOb1NvZnRSc3QrIFBNRS1FbmFibGUtIERT
ZWw9MCBEU2NhbGU9MCBQTUUtDQoJQ2FwYWJpbGl0aWVzOiBbODBdIEV4cHJlc3MgKHYxKSBF
bmRwb2ludCwgTVNJIDAwDQoJCURldkNhcDoJTWF4UGF5bG9hZCAyNTYgYnl0ZXMsIFBoYW50
RnVuYyAwLCBMYXRlbmN5IEwwcyB1bmxpbWl0ZWQsIEwxIHVubGltaXRlZA0KCQkJRXh0VGFn
LSBBdHRuQnRuLSBBdHRuSW5kLSBQd3JJbmQtIFJCRSsgRkxSZXNldC0NCgkJRGV2Q3RsOglS
ZXBvcnQgZXJyb3JzOiBDb3JyZWN0YWJsZS0gTm9uLUZhdGFsLSBGYXRhbC0gVW5zdXBwb3J0
ZWQtDQoJCQlSbHhkT3JkLSBFeHRUYWctIFBoYW50RnVuYy0gQXV4UHdyLSBOb1Nub29wKw0K
CQkJTWF4UGF5bG9hZCAxMjggYnl0ZXMsIE1heFJlYWRSZXEgNTEyIGJ5dGVzDQoJCURldlN0
YToJQ29yckVyci0gVW5jb3JyRXJyLSBGYXRhbEVyci0gVW5zdXBwUmVxLSBBdXhQd3ItIFRy
YW5zUGVuZC0NCgkJTG5rQ2FwOglQb3J0ICMxLCBTcGVlZCAyLjVHVC9zLCBXaWR0aCB4MSwg
QVNQTSB1bmtub3duLCBMYXRlbmN5IEwwIDw2NG5zLCBMMSB1bmxpbWl0ZWQNCgkJCUNsb2Nr
UE0rIFN1cnByaXNlLSBMTEFjdFJlcC0gQndOb3QtDQoJCUxua0N0bDoJQVNQTSBEaXNhYmxl
ZDsgUkNCIDY0IGJ5dGVzIERpc2FibGVkLSBSZXRyYWluLSBDb21tQ2xrLQ0KCQkJRXh0U3lu
Y2gtIENsb2NrUE0tIEF1dFdpZERpcy0gQldJbnQtIEF1dEJXSW50LQ0KCQlMbmtTdGE6CVNw
ZWVkIDIuNUdUL3MsIFdpZHRoIHgxLCBUckVyci0gVHJhaW4tIFNsb3RDbGstIERMQWN0aXZl
LSBCV01nbXQtIEFCV01nbXQtDQoJS2VybmVsIGRyaXZlciBpbiB1c2U6IHBjaWJhY2sNCg0K
MGE6MDAuNyBVU0IgY29udHJvbGxlciBbMGMwM106IE5ldE1vcyBUZWNobm9sb2d5IE1DUzk5
OTAgUENJZSB0byA04oCQUG9ydCBVU0IgMi4wIEhvc3QgQ29udHJvbGxlciBbOTcxMDo5OTkw
XSAocHJvZy1pZiAyMCBbRUhDSV0pDQoJU3Vic3lzdGVtOiBEZXZpY2UgW2EwMDA6NDAwMF0N
CglDb250cm9sOiBJL08tIE1lbSsgQnVzTWFzdGVyKyBTcGVjQ3ljbGUtIE1lbVdJTlYtIFZH
QVNub29wLSBQYXJFcnItIFN0ZXBwaW5nLSBTRVJSLSBGYXN0QjJCLSBEaXNJTlR4LQ0KCVN0
YXR1czogQ2FwKyA2Nk1Iei0gVURGLSBGYXN0QjJCLSBQYXJFcnItIERFVlNFTD1mYXN0ID5U
QWJvcnQtIDxUQWJvcnQrIDxNQWJvcnQtID5TRVJSLSA8UEVSUi0gSU5UeC0NCglMYXRlbmN5
OiAwLCBDYWNoZSBMaW5lIFNpemU6IDY0IGJ5dGVzDQoJSW50ZXJydXB0OiBwaW4gRCByb3V0
ZWQgdG8gSVJRIDMxDQoJUmVnaW9uIDA6IE1lbW9yeSBhdCBmOWZmZjAwMCAoMzItYml0LCBu
b24tcHJlZmV0Y2hhYmxlKSBbc2l6ZT00S10NCglDYXBhYmlsaXRpZXM6IFs1MF0gTVNJOiBF
bmFibGUtIENvdW50PTEvMSBNYXNrYWJsZS0gNjRiaXQrDQoJCUFkZHJlc3M6IDAwMDAwMDAw
MDAwMDAwMDAgIERhdGE6IDAwMDANCglDYXBhYmlsaXRpZXM6IFs3OF0gUG93ZXIgTWFuYWdl
bWVudCB2ZXJzaW9uIDMNCgkJRmxhZ3M6IFBNRUNsay0gRFNJLSBEMSsgRDIrIEF1eEN1cnJl
bnQ9Mzc1bUEgUE1FKEQwKyxEMSssRDIrLEQzaG90KyxEM2NvbGQtKQ0KCQlTdGF0dXM6IEQw
IE5vU29mdFJzdCsgUE1FLUVuYWJsZS0gRFNlbD0wIERTY2FsZT0wIFBNRS0NCglDYXBhYmls
aXRpZXM6IFs4MF0gRXhwcmVzcyAodjEpIEVuZHBvaW50LCBNU0kgMDANCgkJRGV2Q2FwOglN
YXhQYXlsb2FkIDI1NiBieXRlcywgUGhhbnRGdW5jIDAsIExhdGVuY3kgTDBzIHVubGltaXRl
ZCwgTDEgdW5saW1pdGVkDQoJCQlFeHRUYWctIEF0dG5CdG4tIEF0dG5JbmQtIFB3ckluZC0g
UkJFKyBGTFJlc2V0LQ0KCQlEZXZDdGw6CVJlcG9ydCBlcnJvcnM6IENvcnJlY3RhYmxlLSBO
b24tRmF0YWwtIEZhdGFsLSBVbnN1cHBvcnRlZC0NCgkJCVJseGRPcmQtIEV4dFRhZy0gUGhh
bnRGdW5jLSBBdXhQd3ItIE5vU25vb3ArDQoJCQlNYXhQYXlsb2FkIDEyOCBieXRlcywgTWF4
UmVhZFJlcSA1MTIgYnl0ZXMNCgkJRGV2U3RhOglDb3JyRXJyLSBVbmNvcnJFcnItIEZhdGFs
RXJyLSBVbnN1cHBSZXEtIEF1eFB3ci0gVHJhbnNQZW5kLQ0KCQlMbmtDYXA6CVBvcnQgIzEs
IFNwZWVkIDIuNUdUL3MsIFdpZHRoIHgxLCBBU1BNIHVua25vd24sIExhdGVuY3kgTDAgPDY0
bnMsIEwxIHVubGltaXRlZA0KCQkJQ2xvY2tQTSsgU3VycHJpc2UtIExMQWN0UmVwLSBCd05v
dC0NCgkJTG5rQ3RsOglBU1BNIERpc2FibGVkOyBSQ0IgNjQgYnl0ZXMgRGlzYWJsZWQtIFJl
dHJhaW4tIENvbW1DbGstDQoJCQlFeHRTeW5jaC0gQ2xvY2tQTS0gQXV0V2lkRGlzLSBCV0lu
dC0gQXV0QldJbnQtDQoJCUxua1N0YToJU3BlZWQgMi41R1QvcywgV2lkdGggeDEsIFRyRXJy
LSBUcmFpbi0gU2xvdENsay0gRExBY3RpdmUtIEJXTWdtdC0gQUJXTWdtdC0NCglLZXJuZWwg
ZHJpdmVyIGluIHVzZTogcGNpYmFjaw0KDQowYjowMC4wIFZHQSBjb21wYXRpYmxlIGNvbnRy
b2xsZXIgWzAzMDBdOiBuVmlkaWEgQ29ycG9yYXRpb24gRzk4IFtHZUZvcmNlIDg0MDAgR1Nd
IFsxMGRlOjA2ZTRdIChyZXYgYTEpIChwcm9nLWlmIDAwIFtWR0EgY29udHJvbGxlcl0pDQoJ
U3Vic3lzdGVtOiBBU1VTVGVLIENvbXB1dGVyIEluYy4gRGV2aWNlIFsxMDQzOjgyNjZdDQoJ
Q29udHJvbDogSS9PKyBNZW0rIEJ1c01hc3RlcisgU3BlY0N5Y2xlLSBNZW1XSU5WLSBWR0FT
bm9vcC0gUGFyRXJyLSBTdGVwcGluZy0gU0VSUisgRmFzdEIyQi0gRGlzSU5UeC0NCglTdGF0
dXM6IENhcCsgNjZNSHotIFVERi0gRmFzdEIyQi0gUGFyRXJyLSBERVZTRUw9ZmFzdCA+VEFi
b3J0LSA8VEFib3J0LSA8TUFib3J0LSA+U0VSUi0gPFBFUlItIElOVHgtDQoJTGF0ZW5jeTog
MCwgQ2FjaGUgTGluZSBTaXplOiA2NCBieXRlcw0KCUludGVycnVwdDogcGluIEEgcm91dGVk
IHRvIElSUSAxMA0KCVJlZ2lvbiAwOiBNZW1vcnkgYXQgZmQwMDAwMDAgKDMyLWJpdCwgbm9u
LXByZWZldGNoYWJsZSkgW3NpemU9MTZNXQ0KCVJlZ2lvbiAxOiBNZW1vcnkgYXQgZDAwMDAw
MDAgKDY0LWJpdCwgcHJlZmV0Y2hhYmxlKSBbc2l6ZT0yNTZNXQ0KCVJlZ2lvbiAzOiBNZW1v
cnkgYXQgZmEwMDAwMDAgKDY0LWJpdCwgbm9uLXByZWZldGNoYWJsZSkgW3NpemU9MzJNXQ0K
CVJlZ2lvbiA1OiBJL08gcG9ydHMgYXQgZTgwMCBbc2l6ZT0xMjhdDQoJRXhwYW5zaW9uIFJP
TSBhdCBmZTllMDAwMCBbZGlzYWJsZWRdIFtzaXplPTEyOEtdDQoJQ2FwYWJpbGl0aWVzOiBb
NjBdIFBvd2VyIE1hbmFnZW1lbnQgdmVyc2lvbiAzDQoJCUZsYWdzOiBQTUVDbGstIERTSS0g
RDEtIEQyLSBBdXhDdXJyZW50PTBtQSBQTUUoRDAtLEQxLSxEMi0sRDNob3QtLEQzY29sZC0p
DQoJCVN0YXR1czogRDAgTm9Tb2Z0UnN0KyBQTUUtRW5hYmxlLSBEU2VsPTAgRFNjYWxlPTAg
UE1FLQ0KCUNhcGFiaWxpdGllczogWzY4XSBNU0k6IEVuYWJsZS0gQ291bnQ9MS8xIE1hc2th
YmxlLSA2NGJpdCsNCgkJQWRkcmVzczogMDAwMDAwMDAwMDAwMDAwMCAgRGF0YTogMDAwMA0K
CUNhcGFiaWxpdGllczogWzc4XSBFeHByZXNzICh2MSkgRW5kcG9pbnQsIE1TSSAwMA0KCQlE
ZXZDYXA6CU1heFBheWxvYWQgMTI4IGJ5dGVzLCBQaGFudEZ1bmMgMCwgTGF0ZW5jeSBMMHMg
PDUxMm5zLCBMMSA8NHVzDQoJCQlFeHRUYWcrIEF0dG5CdG4tIEF0dG5JbmQtIFB3ckluZC0g
UkJFKyBGTFJlc2V0LQ0KCQlEZXZDdGw6CVJlcG9ydCBlcnJvcnM6IENvcnJlY3RhYmxlLSBO
b24tRmF0YWwtIEZhdGFsLSBVbnN1cHBvcnRlZC0NCgkJCVJseGRPcmQtIEV4dFRhZy0gUGhh
bnRGdW5jLSBBdXhQd3ItIE5vU25vb3ArDQoJCQlNYXhQYXlsb2FkIDEyOCBieXRlcywgTWF4
UmVhZFJlcSA1MTIgYnl0ZXMNCgkJRGV2U3RhOglDb3JyRXJyLSBVbmNvcnJFcnItIEZhdGFs
RXJyLSBVbnN1cHBSZXEtIEF1eFB3ci0gVHJhbnNQZW5kLQ0KCQlMbmtDYXA6CVBvcnQgIzAs
IFNwZWVkIDIuNUdUL3MsIFdpZHRoIHgxNiwgQVNQTSBMMHMgTDEsIExhdGVuY3kgTDAgPDUx
Mm5zLCBMMSA8MXVzDQoJCQlDbG9ja1BNLSBTdXJwcmlzZS0gTExBY3RSZXAtIEJ3Tm90LQ0K
CQlMbmtDdGw6CUFTUE0gRGlzYWJsZWQ7IFJDQiAxMjggYnl0ZXMgRGlzYWJsZWQtIFJldHJh
aW4tIENvbW1DbGsrDQoJCQlFeHRTeW5jaC0gQ2xvY2tQTS0gQXV0V2lkRGlzLSBCV0ludC0g
QXV0QldJbnQtDQoJCUxua1N0YToJU3BlZWQgMi41R1QvcywgV2lkdGggeDgsIFRyRXJyLSBU
cmFpbi0gU2xvdENsaysgRExBY3RpdmUtIEJXTWdtdC0gQUJXTWdtdC0NCglDYXBhYmlsaXRp
ZXM6IFsxMDAgdjFdIFZpcnR1YWwgQ2hhbm5lbA0KCQlDYXBzOglMUEVWQz0wIFJlZkNsaz0x
MDBucyBQQVRFbnRyeUJpdHM9MQ0KCQlBcmI6CUZpeGVkLSBXUlIzMi0gV1JSNjQtIFdSUjEy
OC0NCgkJQ3RybDoJQXJiU2VsZWN0PUZpeGVkDQoJCVN0YXR1czoJSW5Qcm9ncmVzcy0NCgkJ
VkMwOglDYXBzOglQQVRPZmZzZXQ9MDAgTWF4VGltZVNsb3RzPTEgUmVqU25vb3BUcmFucy0N
CgkJCUFyYjoJRml4ZWQtIFdSUjMyLSBXUlI2NC0gV1JSMTI4LSBUV1JSMTI4LSBXUlIyNTYt
DQoJCQlDdHJsOglFbmFibGUrIElEPTAgQXJiU2VsZWN0PUZpeGVkIFRDL1ZDPWZmDQoJCQlT
dGF0dXM6CU5lZ29QZW5kaW5nLSBJblByb2dyZXNzLQ0KCUNhcGFiaWxpdGllczogWzEyOCB2
MV0gUG93ZXIgQnVkZ2V0aW5nIDw/Pg0KCUNhcGFiaWxpdGllczogWzYwMCB2MV0gVmVuZG9y
IFNwZWNpZmljIEluZm9ybWF0aW9uOiBJRD0wMDAxIFJldj0xIExlbj0wMjQgPD8+DQoNCg==
------------0F617E023294CEA4E
Content-Type: text/plain;
 name="xl-dmesg.txt"
Content-transfer-encoding: base64
Content-Disposition: attachment;
 filename="xl-dmesg.txt"

DQooWEVOKSBFbmFibGluZyBBUElDIG1vZGU6ICBGbGF0LiAgVXNpbmcgMiBJL08gQVBJQ3MN
CihYRU4pIEFDUEk6IEhQRVQgaWQ6IDB4ODMwMCBiYXNlOiAweGZlZDAwMDAwDQooWEVOKSBU
YWJsZSBpcyBub3QgZm91bmQhDQooWEVOKSBVc2luZyBBQ1BJIChNQURUKSBmb3IgU01QIGNv
bmZpZ3VyYXRpb24gaW5mb3JtYXRpb24NCihYRU4pIFNNUDogQWxsb3dpbmcgNiBDUFVzICgw
IGhvdHBsdWcgQ1BVcykNCihYRU4pIG1hcHBlZCBBUElDIHRvIGZmZmY4MmMzZmZkZmUwMDAg
KGZlZTAwMDAwKQ0KKFhFTikgbWFwcGVkIElPQVBJQyB0byBmZmZmODJjM2ZmZGZkMDAwIChm
ZWMwMDAwMCkNCihYRU4pIG1hcHBlZCBJT0FQSUMgdG8gZmZmZjgyYzNmZmRmYzAwMCAoZmVj
MjAwMDApDQooWEVOKSBJUlEgbGltaXRzOiA1NiBHU0ksIDExMTIgTVNJL01TSS1YDQooWEVO
KSBVc2luZyBzY2hlZHVsZXI6IFNNUCBDcmVkaXQgU2NoZWR1bGVyIChjcmVkaXQpDQooWEVO
KSBEZXRlY3RlZCAzMjAwLjE5OSBNSHogcHJvY2Vzc29yLg0KKFhFTikgSW5pdGluZyBtZW1v
cnkgc2hhcmluZy4NCihYRU4pIEFNRCBGYW0xMGggbWFjaGluZSBjaGVjayByZXBvcnRpbmcg
ZW5hYmxlZA0KKFhFTikgUENJOiBNQ0ZHIGNvbmZpZ3VyYXRpb24gMDogYmFzZSBlMDAwMDAw
MCBzZWdtZW50IDAwMDAgYnVzZXMgMDAgLSBmZg0KKFhFTikgUENJOiBOb3QgdXNpbmcgTUNG
RyBmb3Igc2VnbWVudCAwMDAwIGJ1cyAwMC1mZg0KKFhFTikgQU1ELVZpOiBGb3VuZCBNU0kg
Y2FwYWJpbGl0eSBibG9jayBhdCAweDU0DQooWEVOKSBBTUQtVmk6IEFDUEkgVGFibGU6DQoo
WEVOKSBBTUQtVmk6ICBTaWduYXR1cmUgSVZSUw0KKFhFTikgQU1ELVZpOiAgTGVuZ3RoIDB4
ZjgNCihYRU4pIEFNRC1WaTogIFJldmlzaW9uIDB4MQ0KKFhFTikgQU1ELVZpOiAgQ2hlY2tT
dW0gMHg2ZQ0KKFhFTikgQU1ELVZpOiAgT0VNX0lkIEFNRCAgDQooWEVOKSBBTUQtVmk6ICBP
RU1fVGFibGVfSWQgUkQ4OTBTDQooWEVOKSBBTUQtVmk6ICBPRU1fUmV2aXNpb24gMHgyMDIw
MzENCihYRU4pIEFNRC1WaTogIENyZWF0b3JfSWQgQU1EIA0KKFhFTikgQU1ELVZpOiAgQ3Jl
YXRvcl9SZXZpc2lvbiAweDANCihYRU4pIEFNRC1WaTogSVZSUyBCbG9jazoNCihYRU4pIEFN
RC1WaTogIFR5cGUgMHgxMA0KKFhFTikgQU1ELVZpOiAgRmxhZ3MgMHgzZQ0KKFhFTikgQU1E
LVZpOiAgTGVuZ3RoIDB4YzgNCihYRU4pIEFNRC1WaTogIERldl9JZCAweDINCihYRU4pIEFN
RC1WaTogSVZIRCBEZXZpY2UgRW50cnk6DQooWEVOKSBBTUQtVmk6ICBUeXBlIDB4Mw0KKFhF
TikgQU1ELVZpOiAgRGV2X0lkIDB4MA0KKFhFTikgQU1ELVZpOiAgRmxhZ3MgMHgwDQooWEVO
KSBBTUQtVmk6ICBEZXZfSWQgUmFuZ2U6IDB4MCAtPiAweDINCihYRU4pIEFNRC1WaTogSVZI
RCBEZXZpY2UgRW50cnk6DQooWEVOKSBBTUQtVmk6ICBUeXBlIDB4Mg0KKFhFTikgQU1ELVZp
OiAgRGV2X0lkIDB4MTANCihYRU4pIEFNRC1WaTogIEZsYWdzIDB4MA0KKFhFTikgQU1ELVZp
OiBJVkhEIERldmljZSBFbnRyeToNCihYRU4pIEFNRC1WaTogIFR5cGUgMHgyDQooWEVOKSBB
TUQtVmk6ICBEZXZfSWQgMHhiMDANCihYRU4pIEFNRC1WaTogIEZsYWdzIDB4MA0KKFhFTikg
QU1ELVZpOiBJVkhEIERldmljZSBFbnRyeToNCihYRU4pIEFNRC1WaTogIFR5cGUgMHgyDQoo
WEVOKSBBTUQtVmk6ICBEZXZfSWQgMHgxOA0KKFhFTikgQU1ELVZpOiAgRmxhZ3MgMHgwDQoo
WEVOKSBBTUQtVmk6IElWSEQgRGV2aWNlIEVudHJ5Og0KKFhFTikgQU1ELVZpOiAgVHlwZSAw
eDMNCihYRU4pIEFNRC1WaTogIERldl9JZCAweGEwMA0KKFhFTikgQU1ELVZpOiAgRmxhZ3Mg
MHgwDQooWEVOKSBBTUQtVmk6ICBEZXZfSWQgUmFuZ2U6IDB4YTAwIC0+IDB4YTA3DQooWEVO
KSBBTUQtVmk6IElWSEQgRGV2aWNlIEVudHJ5Og0KKFhFTikgQU1ELVZpOiAgVHlwZSAweDIN
CihYRU4pIEFNRC1WaTogIERldl9JZCAweDI4DQooWEVOKSBBTUQtVmk6ICBGbGFncyAweDAN
CihYRU4pIEFNRC1WaTogSVZIRCBEZXZpY2UgRW50cnk6DQooWEVOKSBBTUQtVmk6ICBUeXBl
IDB4Mg0KKFhFTikgQU1ELVZpOiAgRGV2X0lkIDB4OTAwDQooWEVOKSBBTUQtVmk6ICBGbGFn
cyAweDANCihYRU4pIEFNRC1WaTogSVZIRCBEZXZpY2UgRW50cnk6DQooWEVOKSBBTUQtVmk6
ICBUeXBlIDB4Mg0KKFhFTikgQU1ELVZpOiAgRGV2X0lkIDB4MzANCihYRU4pIEFNRC1WaTog
IEZsYWdzIDB4MA0KKFhFTikgQU1ELVZpOiBJVkhEIERldmljZSBFbnRyeToNCihYRU4pIEFN
RC1WaTogIFR5cGUgMHgyDQooWEVOKSBBTUQtVmk6ICBEZXZfSWQgMHg4MDANCihYRU4pIEFN
RC1WaTogIEZsYWdzIDB4MA0KKFhFTikgQU1ELVZpOiBJVkhEIERldmljZSBFbnRyeToNCihY
RU4pIEFNRC1WaTogIFR5cGUgMHgyDQooWEVOKSBBTUQtVmk6ICBEZXZfSWQgMHg1MA0KKFhF
TikgQU1ELVZpOiAgRmxhZ3MgMHgwDQooWEVOKSBBTUQtVmk6IElWSEQgRGV2aWNlIEVudHJ5
Og0KKFhFTikgQU1ELVZpOiAgVHlwZSAweDINCihYRU4pIEFNRC1WaTogIERldl9JZCAweDcw
MA0KKFhFTikgQU1ELVZpOiAgRmxhZ3MgMHgwDQooWEVOKSBBTUQtVmk6IElWSEQgRGV2aWNl
IEVudHJ5Og0KKFhFTikgQU1ELVZpOiAgVHlwZSAweDINCihYRU4pIEFNRC1WaTogIERldl9J
ZCAweDU4DQooWEVOKSBBTUQtVmk6ICBGbGFncyAweDANCihYRU4pIEFNRC1WaTogSVZIRCBE
ZXZpY2UgRW50cnk6DQooWEVOKSBBTUQtVmk6ICBUeXBlIDB4Mw0KKFhFTikgQU1ELVZpOiAg
RGV2X0lkIDB4NjAwDQooWEVOKSBBTUQtVmk6ICBGbGFncyAweDANCihYRU4pIEFNRC1WaTog
IERldl9JZCBSYW5nZTogMHg2MDAgLT4gMHg2MDENCihYRU4pIEFNRC1WaTogSVZIRCBEZXZp
Y2UgRW50cnk6DQooWEVOKSBBTUQtVmk6ICBUeXBlIDB4Mg0KKFhFTikgQU1ELVZpOiAgRGV2
X0lkIDB4NjANCihYRU4pIEFNRC1WaTogIEZsYWdzIDB4MA0KKFhFTikgQU1ELVZpOiBJVkhE
IERldmljZSBFbnRyeToNCihYRU4pIEFNRC1WaTogIFR5cGUgMHgyDQooWEVOKSBBTUQtVmk6
ICBEZXZfSWQgMHg1MDANCihYRU4pIEFNRC1WaTogIEZsYWdzIDB4MA0KKFhFTikgQU1ELVZp
OiBJVkhEIERldmljZSBFbnRyeToNCihYRU4pIEFNRC1WaTogIFR5cGUgMHgyDQooWEVOKSBB
TUQtVmk6ICBEZXZfSWQgMHg2OA0KKFhFTikgQU1ELVZpOiAgRmxhZ3MgMHgwDQooWEVOKSBB
TUQtVmk6IElWSEQgRGV2aWNlIEVudHJ5Og0KKFhFTikgQU1ELVZpOiAgVHlwZSAweDMNCihY
RU4pIEFNRC1WaTogIERldl9JZCAweDQwMA0KKFhFTikgQU1ELVZpOiAgRmxhZ3MgMHgwDQoo
WEVOKSBBTUQtVmk6ICBEZXZfSWQgUmFuZ2U6IDB4NDAwIC0+IDB4NDA3DQooWEVOKSBBTUQt
Vmk6IElWSEQgRGV2aWNlIEVudHJ5Og0KKFhFTikgQU1ELVZpOiAgVHlwZSAweDINCihYRU4p
IEFNRC1WaTogIERldl9JZCAweDg4DQooWEVOKSBBTUQtVmk6ICBGbGFncyAweDANCihYRU4p
IEFNRC1WaTogSVZIRCBEZXZpY2UgRW50cnk6DQooWEVOKSBBTUQtVmk6ICBUeXBlIDB4Mw0K
KFhFTikgQU1ELVZpOiAgRGV2X0lkIDB4OTANCihYRU4pIEFNRC1WaTogIEZsYWdzIDB4MA0K
KFhFTikgQU1ELVZpOiAgRGV2X0lkIFJhbmdlOiAweDkwIC0+IDB4OTINCihYRU4pIEFNRC1W
aTogSVZIRCBEZXZpY2UgRW50cnk6DQooWEVOKSBBTUQtVmk6ICBUeXBlIDB4Mw0KKFhFTikg
QU1ELVZpOiAgRGV2X0lkIDB4OTgNCihYRU4pIEFNRC1WaTogIEZsYWdzIDB4MA0KKFhFTikg
QU1ELVZpOiAgRGV2X0lkIFJhbmdlOiAweDk4IC0+IDB4OWENCihYRU4pIEFNRC1WaTogSVZI
RCBEZXZpY2UgRW50cnk6DQooWEVOKSBBTUQtVmk6ICBUeXBlIDB4Mg0KKFhFTikgQU1ELVZp
OiAgRGV2X0lkIDB4YTANCihYRU4pIEFNRC1WaTogIEZsYWdzIDB4ZDcNCihYRU4pIEFNRC1W
aTogSVZIRCBEZXZpY2UgRW50cnk6DQooWEVOKSBBTUQtVmk6ICBUeXBlIDB4Mg0KKFhFTikg
QU1ELVZpOiAgRGV2X0lkIDB4YTMNCihYRU4pIEFNRC1WaTogIEZsYWdzIDB4MA0KKFhFTikg
QU1ELVZpOiBJVkhEIERldmljZSBFbnRyeToNCihYRU4pIEFNRC1WaTogIFR5cGUgMHgyDQoo
WEVOKSBBTUQtVmk6ICBEZXZfSWQgMHhhNA0KKFhFTikgQU1ELVZpOiAgRmxhZ3MgMHgwDQoo
WEVOKSBBTUQtVmk6IElWSEQgRGV2aWNlIEVudHJ5Og0KKFhFTikgQU1ELVZpOiAgVHlwZSAw
eDANCihYRU4pIEFNRC1WaTogIERldl9JZCAweDANCihYRU4pIEFNRC1WaTogIEZsYWdzIDB4
MA0KKFhFTikgQU1ELVZpOiBJVkhEIERldmljZSBFbnRyeToNCihYRU4pIEFNRC1WaTogIFR5
cGUgMHg0Mw0KKFhFTikgQU1ELVZpOiAgRGV2X0lkIDB4MzAwDQooWEVOKSBBTUQtVmk6ICBG
bGFncyAweDANCihYRU4pIEFNRC1WaTogIERldl9JZCBSYW5nZTogMHgzMDAgLT4gMHgzZmYN
CihYRU4pIEFNRC1WaTogIERldl9JZCBBbGlhczogMHhhNA0KKFhFTikgQU1ELVZpOiBJVkhE
IERldmljZSBFbnRyeToNCihYRU4pIEFNRC1WaTogIFR5cGUgMHgyDQooWEVOKSBBTUQtVmk6
ICBEZXZfSWQgMHhhNQ0KKFhFTikgQU1ELVZpOiAgRmxhZ3MgMHgwDQooWEVOKSBBTUQtVmk6
IElWSEQgRGV2aWNlIEVudHJ5Og0KKFhFTikgQU1ELVZpOiAgVHlwZSAweDINCihYRU4pIEFN
RC1WaTogIERldl9JZCAweGE4DQooWEVOKSBBTUQtVmk6ICBGbGFncyAweDANCihYRU4pIEFN
RC1WaTogSVZIRCBEZXZpY2UgRW50cnk6DQooWEVOKSBBTUQtVmk6ICBUeXBlIDB4Mg0KKFhF
TikgQU1ELVZpOiAgRGV2X0lkIDB4YTkNCihYRU4pIEFNRC1WaTogIEZsYWdzIDB4MA0KKFhF
TikgQU1ELVZpOiBJVkhEIERldmljZSBFbnRyeToNCihYRU4pIEFNRC1WaTogIFR5cGUgMHgy
DQooWEVOKSBBTUQtVmk6ICBEZXZfSWQgMHgxMDANCihYRU4pIEFNRC1WaTogIEZsYWdzIDB4
MA0KKFhFTikgQU1ELVZpOiBJVkhEIERldmljZSBFbnRyeToNCihYRU4pIEFNRC1WaTogIFR5
cGUgMHgzDQooWEVOKSBBTUQtVmk6ICBEZXZfSWQgMHhiMA0KKFhFTikgQU1ELVZpOiAgRmxh
Z3MgMHgwDQooWEVOKSBBTUQtVmk6ICBEZXZfSWQgUmFuZ2U6IDB4YjAgLT4gMHhiMg0KKFhF
TikgQU1ELVZpOiBJVkhEIERldmljZSBFbnRyeToNCihYRU4pIEFNRC1WaTogIFR5cGUgMHgw
DQooWEVOKSBBTUQtVmk6ICBEZXZfSWQgMHgwDQooWEVOKSBBTUQtVmk6ICBGbGFncyAweDAN
CihYRU4pIEFNRC1WaTogSVZIRCBEZXZpY2UgRW50cnk6DQooWEVOKSBBTUQtVmk6ICBUeXBl
IDB4NDgNCihYRU4pIEFNRC1WaTogIERldl9JZCAweDANCihYRU4pIEFNRC1WaTogIEZsYWdz
IDB4ZDcNCihYRU4pIEFNRC1WaTogSVZIRCBEZXZpY2UgRW50cnk6DQooWEVOKSBBTUQtVmk6
ICBUeXBlIDB4NDgNCihYRU4pIEFNRC1WaTogIERldl9JZCAweDANCihYRU4pIEFNRC1WaTog
IEZsYWdzIDB4MA0KKFhFTikgQU1ELVZpOiBJT01NVSAwIEVuYWJsZWQuDQooWEVOKSBBTUQt
Vmk6IEVuYWJsaW5nIGdsb2JhbCB2ZWN0b3IgbWFwDQooWEVOKSBJL08gdmlydHVhbGlzYXRp
b24gZW5hYmxlZA0KKFhFTikgIC0gRG9tMCBtb2RlOiBSZWxheGVkDQooWEVOKSBHZXR0aW5n
IFZFUlNJT046IDgwMDUwMDEwDQooWEVOKSBHZXR0aW5nIFZFUlNJT046IDgwMDUwMDEwDQoo
WEVOKSBHZXR0aW5nIElEOiAwDQooWEVOKSBHZXR0aW5nIExWVDA6IDcwMA0KKFhFTikgR2V0
dGluZyBMVlQxOiA0MDANCihYRU4pIGVuYWJsZWQgRXh0SU5UIG9uIENQVSMwDQooWEVOKSBF
U1IgdmFsdWUgYmVmb3JlIGVuYWJsaW5nIHZlY3RvcjogMHgwMDAwMDAwNCAgYWZ0ZXI6IDB4
MDAwMDAwMDANCihYRU4pIEVOQUJMSU5HIElPLUFQSUMgSVJRcw0KKFhFTikgIC0+IFVzaW5n
IG5ldyBBQ0sgbWV0aG9kDQooWEVOKSBpbml0IElPX0FQSUMgSVJRcw0KKFhFTikgIElPLUFQ
SUMgKGFwaWNpZC1waW4pIDYtMCwgNi0xNiwgNi0xNywgNi0xOCwgNi0xOSwgNi0yMCwgNi0y
MSwgNi0yMiwgNi0yMywgNy0wLCA3LTEsIDctMiwgNy0zLCA3LTQsIDctNSwgNy02LCA3LTcs
IDctOCwgNy05LCA3LTEwLCA3LTExLCA3LTEyLCA3LTEzLCA3LTE0LCA3LTE1LCA3LTE2LCA3
LTE3LCA3LTE4LCA3LTE5LCA3LTIwLCA3LTIxLCA3LTIyLCA3LTIzLCA3LTI0LCA3LTI1LCA3
LTI2LCA3LTI3LCA3LTI4LCA3LTI5LCA3LTMwLCA3LTMxIG5vdCBjb25uZWN0ZWQuDQooWEVO
KSAuLlRJTUVSOiB2ZWN0b3I9MHhGMCBhcGljMT0wIHBpbjE9MiBhcGljMj0tMSBwaW4yPS0x
DQooWEVOKSBudW1iZXIgb2YgTVAgSVJRIHNvdXJjZXM6IDE1Lg0KKFhFTikgbnVtYmVyIG9m
IElPLUFQSUMgIzYgcmVnaXN0ZXJzOiAyNC4NCihYRU4pIG51bWJlciBvZiBJTy1BUElDICM3
IHJlZ2lzdGVyczogMzIuDQooWEVOKSB0ZXN0aW5nIHRoZSBJTyBBUElDLi4uLi4uLi4uLi4u
Li4uLi4uLi4uLi4NCihYRU4pIElPIEFQSUMgIzYuLi4uLi4NCihYRU4pIC4uLi4gcmVnaXN0
ZXIgIzAwOiAwNjAwMDAwMA0KKFhFTikgLi4uLi4uLiAgICA6IHBoeXNpY2FsIEFQSUMgaWQ6
IDA2DQooWEVOKSAuLi4uLi4uICAgIDogRGVsaXZlcnkgVHlwZTogMA0KKFhFTikgLi4uLi4u
LiAgICA6IExUUyAgICAgICAgICA6IDANCihYRU4pIC4uLi4gcmVnaXN0ZXIgIzAxOiAwMDE3
ODAyMQ0KKFhFTikgLi4uLi4uLiAgICAgOiBtYXggcmVkaXJlY3Rpb24gZW50cmllczogMDAx
Nw0KKFhFTikgLi4uLi4uLiAgICAgOiBQUlEgaW1wbGVtZW50ZWQ6IDENCihYRU4pIC4uLi4u
Li4gICAgIDogSU8gQVBJQyB2ZXJzaW9uOiAwMDIxDQooWEVOKSAuLi4uIHJlZ2lzdGVyICMw
MjogMDYwMDAwMDANCihYRU4pIC4uLi4uLi4gICAgIDogYXJiaXRyYXRpb246IDA2DQooWEVO
KSAuLi4uIHJlZ2lzdGVyICMwMzogMDcwMDAwMDANCihYRU4pIC4uLi4uLi4gICAgIDogQm9v
dCBEVCAgICA6IDANCihYRU4pIC4uLi4gSVJRIHJlZGlyZWN0aW9uIHRhYmxlOg0KKFhFTikg
IE5SIExvZyBQaHkgTWFzayBUcmlnIElSUiBQb2wgU3RhdCBEZXN0IERlbGkgVmVjdDogICAN
CihYRU4pICAwMCAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAw
DQooWEVOKSAgMDEgMDAxIDAxICAwICAgIDAgICAgMCAgIDAgICAwICAgIDEgICAgMSAgICAz
MA0KKFhFTikgIDAyIDAwMSAwMSAgMCAgICAwICAgIDAgICAwICAgMCAgICAxICAgIDEgICAg
RjANCihYRU4pICAwMyAwMDEgMDEgIDAgICAgMCAgICAwICAgMCAgIDAgICAgMSAgICAxICAg
IDM4DQooWEVOKSAgMDQgMDAxIDAxICAwICAgIDAgICAgMCAgIDAgICAwICAgIDEgICAgMSAg
ICBGMQ0KKFhFTikgIDA1IDAwMSAwMSAgMCAgICAwICAgIDAgICAwICAgMCAgICAxICAgIDEg
ICAgNDANCihYRU4pICAwNiAwMDEgMDEgIDAgICAgMCAgICAwICAgMCAgIDAgICAgMSAgICAx
ICAgIDQ4DQooWEVOKSAgMDcgMDAxIDAxICAwICAgIDAgICAgMCAgIDAgICAwICAgIDEgICAg
MSAgICA1MA0KKFhFTikgIDA4IDAwMSAwMSAgMCAgICAwICAgIDAgICAwICAgMCAgICAxICAg
IDEgICAgNTgNCihYRU4pICAwOSAwMDEgMDEgIDEgICAgMSAgICAwICAgMSAgIDAgICAgMSAg
ICAxICAgIDYwDQooWEVOKSAgMGEgMDAxIDAxICAwICAgIDAgICAgMCAgIDAgICAwICAgIDEg
ICAgMSAgICA2OA0KKFhFTikgIDBiIDAwMSAwMSAgMCAgICAwICAgIDAgICAwICAgMCAgICAx
ICAgIDEgICAgNzANCihYRU4pICAwYyAwMDEgMDEgIDAgICAgMCAgICAwICAgMCAgIDAgICAg
MSAgICAxICAgIDc4DQooWEVOKSAgMGQgMDAxIDAxICAwICAgIDAgICAgMCAgIDAgICAwICAg
IDEgICAgMSAgICA4OA0KKFhFTikgIDBlIDAwMSAwMSAgMCAgICAwICAgIDAgICAwICAgMCAg
ICAxICAgIDEgICAgOTANCihYRU4pICAwZiAwMDEgMDEgIDAgICAgMCAgICAwICAgMCAgIDAg
ICAgMSAgICAxICAgIDk4DQooWEVOKSAgMTAgMDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAw
ICAgIDAgICAgMCAgICAwMA0KKFhFTikgIDExIDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAg
MCAgICAwICAgIDAgICAgMDANCihYRU4pICAxMiAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAg
IDAgICAgMCAgICAwICAgIDAwDQooWEVOKSAgMTMgMDAwIDAwICAxICAgIDAgICAgMCAgIDAg
ICAwICAgIDAgICAgMCAgICAwMA0KKFhFTikgIDE0IDAwMCAwMCAgMSAgICAwICAgIDAgICAw
ICAgMCAgICAwICAgIDAgICAgMDANCihYRU4pICAxNSAwMDAgMDAgIDEgICAgMCAgICAwICAg
MCAgIDAgICAgMCAgICAwICAgIDAwDQooWEVOKSAgMTYgMDAwIDAwICAxICAgIDAgICAgMCAg
IDAgICAwICAgIDAgICAgMCAgICAwMA0KKFhFTikgIDE3IDAwMCAwMCAgMSAgICAwICAgIDAg
ICAwICAgMCAgICAwICAgIDAgICAgMDANCihYRU4pIElPIEFQSUMgIzcuLi4uLi4NCihYRU4p
IC4uLi4gcmVnaXN0ZXIgIzAwOiAwNzAwMDAwMA0KKFhFTikgLi4uLi4uLiAgICA6IHBoeXNp
Y2FsIEFQSUMgaWQ6IDA3DQooWEVOKSAuLi4uLi4uICAgIDogRGVsaXZlcnkgVHlwZTogMA0K
KFhFTikgLi4uLi4uLiAgICA6IExUUyAgICAgICAgICA6IDANCihYRU4pIC4uLi4gcmVnaXN0
ZXIgIzAxOiAwMDFGODAyMQ0KKFhFTikgLi4uLi4uLiAgICAgOiBtYXggcmVkaXJlY3Rpb24g
ZW50cmllczogMDAxRg0KKFhFTikgLi4uLi4uLiAgICAgOiBQUlEgaW1wbGVtZW50ZWQ6IDEN
CihYRU4pIC4uLi4uLi4gICAgIDogSU8gQVBJQyB2ZXJzaW9uOiAwMDIxDQooWEVOKSAuLi4u
IHJlZ2lzdGVyICMwMjogMDAwMDAwMDANCihYRU4pIC4uLi4uLi4gICAgIDogYXJiaXRyYXRp
b246IDAwDQooWEVOKSAuLi4uIElSUSByZWRpcmVjdGlvbiB0YWJsZToNCihYRU4pICBOUiBM
b2cgUGh5IE1hc2sgVHJpZyBJUlIgUG9sIFN0YXQgRGVzdCBEZWxpIFZlY3Q6ICAgDQooWEVO
KSAgMDAgMDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAwICAgIDAgICAgMCAgICAwMA0KKFhF
TikgIDAxIDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDAgICAgMDANCihY
RU4pICAwMiAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwDQoo
WEVOKSAgMDMgMDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAwICAgIDAgICAgMCAgICAwMA0K
KFhFTikgIDA0IDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDAgICAgMDAN
CihYRU4pICAwNSAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAw
DQooWEVOKSAgMDYgMDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAwICAgIDAgICAgMCAgICAw
MA0KKFhFTikgIDA3IDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDAgICAg
MDANCihYRU4pICAwOCAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAg
IDAwDQooWEVOKSAgMDkgMDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAwICAgIDAgICAgMCAg
ICAwMA0KKFhFTikgIDBhIDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDAg
ICAgMDANCihYRU4pICAwYiAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAw
ICAgIDAwDQooWEVOKSAgMGMgMDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAwICAgIDAgICAg
MCAgICAwMA0KKFhFTikgIDBkIDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAg
IDAgICAgMDANCihYRU4pICAwZSAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAg
ICAwICAgIDAwDQooWEVOKSAgMGYgMDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAwICAgIDAg
ICAgMCAgICAwMA0KKFhFTikgIDEwIDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAw
ICAgIDAgICAgMDANCihYRU4pICAxMSAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAg
MCAgICAwICAgIDAwDQooWEVOKSAgMTIgMDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAwICAg
IDAgICAgMCAgICAwMA0KKFhFTikgIDEzIDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAg
ICAwICAgIDAgICAgMDANCihYRU4pICAxNCAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAg
ICAgMCAgICAwICAgIDAwDQooWEVOKSAgMTUgMDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAw
ICAgIDAgICAgMCAgICAwMA0KKFhFTikgIDE2IDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAg
MCAgICAwICAgIDAgICAgMDANCihYRU4pICAxNyAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAg
IDAgICAgMCAgICAwICAgIDAwDQooWEVOKSAgMTggMDAwIDAwICAxICAgIDAgICAgMCAgIDAg
ICAwICAgIDAgICAgMCAgICAwMA0KKFhFTikgIDE5IDAwMCAwMCAgMSAgICAwICAgIDAgICAw
ICAgMCAgICAwICAgIDAgICAgMDANCihYRU4pICAxYSAwMDAgMDAgIDEgICAgMCAgICAwICAg
MCAgIDAgICAgMCAgICAwICAgIDAwDQooWEVOKSAgMWIgMDAwIDAwICAxICAgIDAgICAgMCAg
IDAgICAwICAgIDAgICAgMCAgICAwMA0KKFhFTikgIDFjIDAwMCAwMCAgMSAgICAwICAgIDAg
ICAwICAgMCAgICAwICAgIDAgICAgMDANCihYRU4pICAxZCAwMDAgMDAgIDEgICAgMCAgICAw
ICAgMCAgIDAgICAgMCAgICAwICAgIDAwDQooWEVOKSAgMWUgMDAwIDAwICAxICAgIDAgICAg
MCAgIDAgICAwICAgIDAgICAgMCAgICAwMA0KKFhFTikgIDFmIDAwMCAwMCAgMSAgICAwICAg
IDAgICAwICAgMCAgICAwICAgIDAgICAgMDANCihYRU4pIFVzaW5nIHZlY3Rvci1iYXNlZCBp
bmRleGluZw0KKFhFTikgSVJRIHRvIHBpbiBtYXBwaW5nczoNCihYRU4pIElSUTI0MCAtPiAw
OjINCihYRU4pIElSUTQ4IC0+IDA6MQ0KKFhFTikgSVJRNTYgLT4gMDozDQooWEVOKSBJUlEy
NDEgLT4gMDo0DQooWEVOKSBJUlE2NCAtPiAwOjUNCihYRU4pIElSUTcyIC0+IDA6Ng0KKFhF
TikgSVJRODAgLT4gMDo3DQooWEVOKSBJUlE4OCAtPiAwOjgNCihYRU4pIElSUTk2IC0+IDA6
OQ0KKFhFTikgSVJRMTA0IC0+IDA6MTANCihYRU4pIElSUTExMiAtPiAwOjExDQooWEVOKSBJ
UlExMjAgLT4gMDoxMg0KKFhFTikgSVJRMTM2IC0+IDA6MTMNCihYRU4pIElSUTE0NCAtPiAw
OjE0DQooWEVOKSBJUlExNTIgLT4gMDoxNQ0KKFhFTikgLi4uLi4uLi4uLi4uLi4uLi4uLi4u
Li4uLi4uLi4uLi4uLi4uIGRvbmUuDQooWEVOKSBVc2luZyBsb2NhbCBBUElDIHRpbWVyIGlu
dGVycnVwdHMuDQooWEVOKSBjYWxpYnJhdGluZyBBUElDIHRpbWVyIC4uLg0KKFhFTikgLi4u
Li4gQ1BVIGNsb2NrIHNwZWVkIGlzIDMyMDAuMTM3OCBNSHouDQooWEVOKSAuLi4uLiBob3N0
IGJ1cyBjbG9jayBzcGVlZCBpcyAyMDAuMDA4NSBNSHouDQooWEVOKSAuLi4uLiBidXNfc2Nh
bGUgPSAweDAwMDBDQ0Q3DQooWEVOKSBbMjAxMi0wOS0wNSAxNTo0OTowOV0gUGxhdGZvcm0g
dGltZXIgaXMgMTQuMzE4TUh6IEhQRVQNCihYRU4pIFsyMDEyLTA5LTA1IDE1OjQ5OjA5XSBB
bGxvY2F0ZWQgY29uc29sZSByaW5nIG9mIDY0IEtpQi4NCihYRU4pIFsyMDEyLTA5LTA1IDE1
OjQ5OjA5XSBIVk06IEFTSURzIGVuYWJsZWQuDQooWEVOKSBbMjAxMi0wOS0wNSAxNTo0OTow
OV0gU1ZNOiBTdXBwb3J0ZWQgYWR2YW5jZWQgZmVhdHVyZXM6DQooWEVOKSBbMjAxMi0wOS0w
NSAxNTo0OTowOV0gIC0gTmVzdGVkIFBhZ2UgVGFibGVzIChOUFQpDQooWEVOKSBbMjAxMi0w
OS0wNSAxNTo0OTowOV0gIC0gTGFzdCBCcmFuY2ggUmVjb3JkIChMQlIpIFZpcnR1YWxpc2F0
aW9uDQooWEVOKSBbMjAxMi0wOS0wNSAxNTo0OTowOV0gIC0gTmV4dC1SSVAgU2F2ZWQgb24g
I1ZNRVhJVA0KKFhFTikgWzIwMTItMDktMDUgMTU6NDk6MDldICAtIFBhdXNlLUludGVyY2Vw
dCBGaWx0ZXINCihYRU4pIFsyMDEyLTA5LTA1IDE1OjQ5OjA5XSBIVk06IFNWTSBlbmFibGVk
DQooWEVOKSBbMjAxMi0wOS0wNSAxNTo0OTowOV0gSFZNOiBIYXJkd2FyZSBBc3Npc3RlZCBQ
YWdpbmcgKEhBUCkgZGV0ZWN0ZWQNCihYRU4pIFsyMDEyLTA5LTA1IDE1OjQ5OjA5XSBIVk06
IEhBUCBwYWdlIHNpemVzOiA0a0IsIDJNQiwgMUdCDQooWEVOKSBbMjAxMi0wOS0wNSAxNTo0
OTowOF0gbWFza2VkIEV4dElOVCBvbiBDUFUjMQ0KKFhFTikgWzIwMTItMDktMDUgMTU6NDk6
MDldIG1pY3JvY29kZTogY29sbGVjdF9jcHVfaW5mbzogcGF0Y2hfaWQ9MHgxMDAwMGJmDQoo
WEVOKSBbMjAxMi0wOS0wNSAxNTo0OTowOF0gbWFza2VkIEV4dElOVCBvbiBDUFUjMg0KKFhF
TikgWzIwMTItMDktMDUgMTU6NDk6MDldIG1pY3JvY29kZTogY29sbGVjdF9jcHVfaW5mbzog
cGF0Y2hfaWQ9MHgxMDAwMGJmDQooWEVOKSBbMjAxMi0wOS0wNSAxNTo0OTowOF0gbWFza2Vk
IEV4dElOVCBvbiBDUFUjMw0KKFhFTikgWzIwMTItMDktMDUgMTU6NDk6MDldIG1pY3JvY29k
ZTogY29sbGVjdF9jcHVfaW5mbzogcGF0Y2hfaWQ9MHgxMDAwMGJmDQooWEVOKSBbMjAxMi0w
OS0wNSAxNTo0OTowOF0gbWFza2VkIEV4dElOVCBvbiBDUFUjNA0KKFhFTikgWzIwMTItMDkt
MDUgMTU6NDk6MDldIG1pY3JvY29kZTogY29sbGVjdF9jcHVfaW5mbzogcGF0Y2hfaWQ9MHgx
MDAwMGJmDQooWEVOKSBbMjAxMi0wOS0wNSAxNTo0OTowOF0gbWFza2VkIEV4dElOVCBvbiBD
UFUjNQ0KKFhFTikgWzIwMTItMDktMDUgMTU6NDk6MDldIEJyb3VnaHQgdXAgNiBDUFVzDQoo
WEVOKSBbMjAxMi0wOS0wNSAxNTo0OTowOV0gbWljcm9jb2RlOiBjb2xsZWN0X2NwdV9pbmZv
OiBwYXRjaF9pZD0weDEwMDAwYmYNCihYRU4pIFsyMDEyLTA5LTA1IDE1OjQ5OjA5XSBIUEVU
J3MgTVNJIG1vZGUgaGFzbid0IGJlZW4gc3VwcG9ydGVkIHdoZW4gSW50ZXJydXB0IFJlbWFw
cGluZyBpcyBlbmFibGVkLg0KKFhFTikgWzIwMTItMDktMDUgMTU6NDk6MDldIEFDUEkgc2xl
ZXAgbW9kZXM6IFMzDQooWEVOKSBbMjAxMi0wOS0wNSAxNTo0OTowOV0gTUNBOiBVc2UgaHcg
dGhyZXNob2xkaW5nIHRvIGFkanVzdCBwb2xsaW5nIGZyZXF1ZW5jeQ0KKFhFTikgWzIwMTIt
MDktMDUgMTU6NDk6MDldIG1jaGVja19wb2xsOiBNYWNoaW5lIGNoZWNrIHBvbGxpbmcgdGlt
ZXIgc3RhcnRlZC4NCihYRU4pIFsyMDEyLTA5LTA1IDE1OjQ5OjA5XSBYZW5vcHJvZmlsZTog
RmFpbGVkIHRvIHNldHVwIElCUyBMVlQgb2Zmc2V0LCBJQlNDVEwgPSAweGZmZmZmZmZmDQoo
WEVOKSBbMjAxMi0wOS0wNSAxNTo0OTowOV0gKioqIExPQURJTkcgRE9NQUlOIDAgKioqDQoo
WEVOKSBbMjAxMi0wOS0wNSAxNTo0OTowOV0gZWxmX3BhcnNlX2JpbmFyeTogcGhkcjogcGFk
ZHI9MHgxMDAwMDAwIG1lbXN6PTB4ZDZhMDAwDQooWEVOKSBbMjAxMi0wOS0wNSAxNTo0OTow
OV0gZWxmX3BhcnNlX2JpbmFyeTogcGhkcjogcGFkZHI9MHgxZTAwMDAwIG1lbXN6PTB4ZGIw
ZTgNCihYRU4pIFsyMDEyLTA5LTA1IDE1OjQ5OjA5XSBlbGZfcGFyc2VfYmluYXJ5OiBwaGRy
OiBwYWRkcj0weDFlZGMwMDAgbWVtc3o9MHgxM2MwMA0KKFhFTikgWzIwMTItMDktMDUgMTU6
NDk6MDldIGVsZl9wYXJzZV9iaW5hcnk6IHBoZHI6IHBhZGRyPTB4MWVmMDAwMCBtZW1zej0w
eGRlNTAwMA0KKFhFTikgWzIwMTItMDktMDUgMTU6NDk6MDldIGVsZl9wYXJzZV9iaW5hcnk6
IG1lbW9yeTogMHgxMDAwMDAwIC0+IDB4MmNkNTAwMA0KKFhFTikgWzIwMTItMDktMDUgMTU6
NDk6MDldIGVsZl94ZW5fcGFyc2Vfbm90ZTogR1VFU1RfT1MgPSAibGludXgiDQooWEVOKSBb
MjAxMi0wOS0wNSAxNTo0OTowOV0gZWxmX3hlbl9wYXJzZV9ub3RlOiBHVUVTVF9WRVJTSU9O
ID0gIjIuNiINCihYRU4pIFsyMDEyLTA5LTA1IDE1OjQ5OjA5XSBlbGZfeGVuX3BhcnNlX25v
dGU6IFhFTl9WRVJTSU9OID0gInhlbi0zLjAiDQooWEVOKSBbMjAxMi0wOS0wNSAxNTo0OTow
OV0gZWxmX3hlbl9wYXJzZV9ub3RlOiBWSVJUX0JBU0UgPSAweGZmZmZmZmZmODAwMDAwMDAN
CihYRU4pIFsyMDEyLTA5LTA1IDE1OjQ5OjA5XSBlbGZfeGVuX3BhcnNlX25vdGU6IEVOVFJZ
ID0gMHhmZmZmZmZmZjgxZWYwMjEwDQooWEVOKSBbMjAxMi0wOS0wNSAxNTo0OTowOV0gZWxm
X3hlbl9wYXJzZV9ub3RlOiBIWVBFUkNBTExfUEFHRSA9IDB4ZmZmZmZmZmY4MTAwMTAwMA0K
KFhFTikgWzIwMTItMDktMDUgMTU6NDk6MDldIGVsZl94ZW5fcGFyc2Vfbm90ZTogRkVBVFVS
RVMgPSAiIXdyaXRhYmxlX3BhZ2VfdGFibGVzfHBhZV9wZ2Rpcl9hYm92ZV80Z2IiDQooWEVO
KSBbMjAxMi0wOS0wNSAxNTo0OTowOV0gZWxmX3hlbl9wYXJzZV9ub3RlOiBQQUVfTU9ERSA9
ICJ5ZXMiDQooWEVOKSBbMjAxMi0wOS0wNSAxNTo0OTowOV0gZWxmX3hlbl9wYXJzZV9ub3Rl
OiBMT0FERVIgPSAiZ2VuZXJpYyINCihYRU4pIFsyMDEyLTA5LTA1IDE1OjQ5OjA5XSBlbGZf
eGVuX3BhcnNlX25vdGU6IHVua25vd24geGVuIGVsZiBub3RlICgweGQpDQooWEVOKSBbMjAx
Mi0wOS0wNSAxNTo0OTowOV0gZWxmX3hlbl9wYXJzZV9ub3RlOiBTVVNQRU5EX0NBTkNFTCA9
IDB4MQ0KKFhFTikgWzIwMTItMDktMDUgMTU6NDk6MDldIGVsZl94ZW5fcGFyc2Vfbm90ZTog
SFZfU1RBUlRfTE9XID0gMHhmZmZmODAwMDAwMDAwMDAwDQooWEVOKSBbMjAxMi0wOS0wNSAx
NTo0OTowOV0gZWxmX3hlbl9wYXJzZV9ub3RlOiBQQUREUl9PRkZTRVQgPSAweDANCihYRU4p
IFsyMDEyLTA5LTA1IDE1OjQ5OjA5XSBlbGZfeGVuX2FkZHJfY2FsY19jaGVjazogYWRkcmVz
c2VzOg0KKFhFTikgWzIwMTItMDktMDUgMTU6NDk6MDldICAgICB2aXJ0X2Jhc2UgICAgICAg
ID0gMHhmZmZmZmZmZjgwMDAwMDAwDQooWEVOKSBbMjAxMi0wOS0wNSAxNTo0OTowOV0gICAg
IGVsZl9wYWRkcl9vZmZzZXQgPSAweDANCihYRU4pIFsyMDEyLTA5LTA1IDE1OjQ5OjA5XSAg
ICAgdmlydF9vZmZzZXQgICAgICA9IDB4ZmZmZmZmZmY4MDAwMDAwMA0KKFhFTikgWzIwMTIt
MDktMDUgMTU6NDk6MDldICAgICB2aXJ0X2tzdGFydCAgICAgID0gMHhmZmZmZmZmZjgxMDAw
MDAwDQooWEVOKSBbMjAxMi0wOS0wNSAxNTo0OTowOV0gICAgIHZpcnRfa2VuZCAgICAgICAg
PSAweGZmZmZmZmZmODJjZDUwMDANCihYRU4pIFsyMDEyLTA5LTA1IDE1OjQ5OjA5XSAgICAg
dmlydF9lbnRyeSAgICAgICA9IDB4ZmZmZmZmZmY4MWVmMDIxMA0KKFhFTikgWzIwMTItMDkt
MDUgMTU6NDk6MDldICAgICBwMm1fYmFzZSAgICAgICAgID0gMHhmZmZmZmZmZmZmZmZmZmZm
DQooWEVOKSBbMjAxMi0wOS0wNSAxNTo0OTowOV0gIFhlbiAga2VybmVsOiA2NC1iaXQsIGxz
YiwgY29tcGF0MzINCihYRU4pIFsyMDEyLTA5LTA1IDE1OjQ5OjA5XSAgRG9tMCBrZXJuZWw6
IDY0LWJpdCwgUEFFLCBsc2IsIHBhZGRyIDB4MTAwMDAwMCAtPiAweDJjZDUwMDANCihYRU4p
IFsyMDEyLTA5LTA1IDE1OjQ5OjA5XSBQSFlTSUNBTCBNRU1PUlkgQVJSQU5HRU1FTlQ6DQoo
WEVOKSBbMjAxMi0wOS0wNSAxNTo0OTowOV0gIERvbTAgYWxsb2MuOiAgIDAwMDAwMDAyNDAw
MDAwMDAtPjAwMDAwMDAyNDQwMDAwMDAgKDI0MjQyOCBwYWdlcyB0byBiZSBhbGxvY2F0ZWQp
DQooWEVOKSBbMjAxMi0wOS0wNSAxNTo0OTowOV0gIEluaXQuIHJhbWRpc2s6IDAwMDAwMDAy
NGYyZmMwMDAtPjAwMDAwMDAyNGZmZmY4MDANCihYRU4pIFsyMDEyLTA5LTA1IDE1OjQ5OjA5
XSBWSVJUVUFMIE1FTU9SWSBBUlJBTkdFTUVOVDoNCihYRU4pIFsyMDEyLTA5LTA1IDE1OjQ5
OjA5XSAgTG9hZGVkIGtlcm5lbDogZmZmZmZmZmY4MTAwMDAwMC0+ZmZmZmZmZmY4MmNkNTAw
MA0KKFhFTikgWzIwMTItMDktMDUgMTU6NDk6MDldICBJbml0LiByYW1kaXNrOiBmZmZmZmZm
ZjgyY2Q1MDAwLT5mZmZmZmZmZjgzOWQ4ODAwDQooWEVOKSBbMjAxMi0wOS0wNSAxNTo0OTow
OV0gIFBoeXMtTWFjaCBtYXA6IGZmZmZmZmZmODM5ZDkwMDAtPmZmZmZmZmZmODNiZDkwMDAN
CihYRU4pIFsyMDEyLTA5LTA1IDE1OjQ5OjA5XSAgU3RhcnQgaW5mbzogICAgZmZmZmZmZmY4
M2JkOTAwMC0+ZmZmZmZmZmY4M2JkOTRiNA0KKFhFTikgWzIwMTItMDktMDUgMTU6NDk6MDld
ICBQYWdlIHRhYmxlczogICBmZmZmZmZmZjgzYmRhMDAwLT5mZmZmZmZmZjgzYmZkMDAwDQoo
WEVOKSBbMjAxMi0wOS0wNSAxNTo0OTowOV0gIEJvb3Qgc3RhY2s6ICAgIGZmZmZmZmZmODNi
ZmQwMDAtPmZmZmZmZmZmODNiZmUwMDANCihYRU4pIFsyMDEyLTA5LTA1IDE1OjQ5OjA5XSAg
VE9UQUw6ICAgICAgICAgZmZmZmZmZmY4MDAwMDAwMC0+ZmZmZmZmZmY4NDAwMDAwMA0KKFhF
TikgWzIwMTItMDktMDUgMTU6NDk6MDldICBFTlRSWSBBRERSRVNTOiBmZmZmZmZmZjgxZWYw
MjEwDQooWEVOKSBbMjAxMi0wOS0wNSAxNTo0OTowOV0gRG9tMCBoYXMgbWF4aW11bSA2IFZD
UFVzDQooWEVOKSBbMjAxMi0wOS0wNSAxNTo0OTowOV0gZWxmX2xvYWRfYmluYXJ5OiBwaGRy
IDAgYXQgMHhmZmZmZmZmZjgxMDAwMDAwIC0+IDB4ZmZmZmZmZmY4MWQ2YTAwMA0KKFhFTikg
WzIwMTItMDktMDUgMTU6NDk6MDldIGVsZl9sb2FkX2JpbmFyeTogcGhkciAxIGF0IDB4ZmZm
ZmZmZmY4MWUwMDAwMCAtPiAweGZmZmZmZmZmODFlZGIwZTgNCihYRU4pIFsyMDEyLTA5LTA1
IDE1OjQ5OjA5XSBlbGZfbG9hZF9iaW5hcnk6IHBoZHIgMiBhdCAweGZmZmZmZmZmODFlZGMw
MDAgLT4gMHhmZmZmZmZmZjgxZWVmYzAwDQooWEVOKSBbMjAxMi0wOS0wNSAxNTo0OTowOV0g
ZWxmX2xvYWRfYmluYXJ5OiBwaGRyIDMgYXQgMHhmZmZmZmZmZjgxZWYwMDAwIC0+IDB4ZmZm
ZmZmZmY4MWY4OTAwMA0KKFhFTikgWzIwMTItMDktMDUgMTU6NDk6MTBdIEFNRC1WaTogU2V0
dXAgSS9PIHBhZ2UgdGFibGU6IGRldmljZSBpZCA9IDB4MDAwMCwgcm9vdCB0YWJsZSA9IDB4
MjRkODRiMDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMNCihYRU4pIFsyMDEyLTA5
LTA1IDE1OjQ5OjEwXSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQg
PSAweDAwMDIsIHJvb3QgdGFibGUgPSAweDI0ZDg0YjAwMCwgZG9tYWluID0gMCwgcGFnaW5n
IG1vZGUgPSAzDQooWEVOKSBbMjAxMi0wOS0wNSAxNTo0OToxMF0gQU1ELVZpOiBTZXR1cCBJ
L08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHgwMDEwLCByb290IHRhYmxlID0gMHgyNGQ4
NGIwMDAsIGRvbWFpbiA9IDAsIHBhZ2luZyBtb2RlID0gMw0KKFhFTikgWzIwMTItMDktMDUg
MTU6NDk6MTBdIEFNRC1WaTogU2V0dXAgSS9PIHBhZ2UgdGFibGU6IGRldmljZSBpZCA9IDB4
MDAxOCwgcm9vdCB0YWJsZSA9IDB4MjRkODRiMDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9k
ZSA9IDMNCihYRU4pIFsyMDEyLTA5LTA1IDE1OjQ5OjEwXSBBTUQtVmk6IFNldHVwIEkvTyBw
YWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweDAwMjgsIHJvb3QgdGFibGUgPSAweDI0ZDg0YjAw
MCwgZG9tYWluID0gMCwgcGFnaW5nIG1vZGUgPSAzDQooWEVOKSBbMjAxMi0wOS0wNSAxNTo0
OToxMF0gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHgwMDMw
LCByb290IHRhYmxlID0gMHgyNGQ4NGIwMDAsIGRvbWFpbiA9IDAsIHBhZ2luZyBtb2RlID0g
Mw0KKFhFTikgWzIwMTItMDktMDUgMTU6NDk6MTBdIEFNRC1WaTogU2V0dXAgSS9PIHBhZ2Ug
dGFibGU6IGRldmljZSBpZCA9IDB4MDA1MCwgcm9vdCB0YWJsZSA9IDB4MjRkODRiMDAwLCBk
b21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMNCihYRU4pIFsyMDEyLTA5LTA1IDE1OjQ5OjEw
XSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweDAwNTgsIHJv
b3QgdGFibGUgPSAweDI0ZDg0YjAwMCwgZG9tYWluID0gMCwgcGFnaW5nIG1vZGUgPSAzDQoo
WEVOKSBbMjAxMi0wOS0wNSAxNTo0OToxMF0gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJs
ZTogZGV2aWNlIGlkID0gMHgwMDYwLCByb290IHRhYmxlID0gMHgyNGQ4NGIwMDAsIGRvbWFp
biA9IDAsIHBhZ2luZyBtb2RlID0gMw0KKFhFTikgWzIwMTItMDktMDUgMTU6NDk6MTBdIEFN
RC1WaTogU2V0dXAgSS9PIHBhZ2UgdGFibGU6IGRldmljZSBpZCA9IDB4MDA2OCwgcm9vdCB0
YWJsZSA9IDB4MjRkODRiMDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMNCihYRU4p
IFsyMDEyLTA5LTA1IDE1OjQ5OjEwXSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBk
ZXZpY2UgaWQgPSAweDAwODgsIHJvb3QgdGFibGUgPSAweDI0ZDg0YjAwMCwgZG9tYWluID0g
MCwgcGFnaW5nIG1vZGUgPSAzDQooWEVOKSBbMjAxMi0wOS0wNSAxNTo0OToxMF0gQU1ELVZp
OiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHgwMDkwLCByb290IHRhYmxl
ID0gMHgyNGQ4NGIwMDAsIGRvbWFpbiA9IDAsIHBhZ2luZyBtb2RlID0gMw0KKFhFTikgWzIw
MTItMDktMDUgMTU6NDk6MTBdIEFNRC1WaTogU2V0dXAgSS9PIHBhZ2UgdGFibGU6IGRldmlj
ZSBpZCA9IDB4MDA5Miwgcm9vdCB0YWJsZSA9IDB4MjRkODRiMDAwLCBkb21haW4gPSAwLCBw
YWdpbmcgbW9kZSA9IDMNCihYRU4pIFsyMDEyLTA5LTA1IDE1OjQ5OjEwXSBBTUQtVmk6IFNl
dHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweDAwOTgsIHJvb3QgdGFibGUgPSAw
eDI0ZDg0YjAwMCwgZG9tYWluID0gMCwgcGFnaW5nIG1vZGUgPSAzDQooWEVOKSBbMjAxMi0w
OS0wNSAxNTo0OToxMF0gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlk
ID0gMHgwMDlhLCByb290IHRhYmxlID0gMHgyNGQ4NGIwMDAsIGRvbWFpbiA9IDAsIHBhZ2lu
ZyBtb2RlID0gMw0KKFhFTikgWzIwMTItMDktMDUgMTU6NDk6MTBdIEFNRC1WaTogU2V0dXAg
SS9PIHBhZ2UgdGFibGU6IGRldmljZSBpZCA9IDB4MDBhMCwgcm9vdCB0YWJsZSA9IDB4MjRk
ODRiMDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMNCihYRU4pIFsyMDEyLTA5LTA1
IDE1OjQ5OjEwXSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAw
eDAwYTMsIHJvb3QgdGFibGUgPSAweDI0ZDg0YjAwMCwgZG9tYWluID0gMCwgcGFnaW5nIG1v
ZGUgPSAzDQooWEVOKSBbMjAxMi0wOS0wNSAxNTo0OToxMF0gQU1ELVZpOiBTZXR1cCBJL08g
cGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHgwMGE0LCByb290IHRhYmxlID0gMHgyNGQ4NGIw
MDAsIGRvbWFpbiA9IDAsIHBhZ2luZyBtb2RlID0gMw0KKFhFTikgWzIwMTItMDktMDUgMTU6
NDk6MTBdIEFNRC1WaTogU2V0dXAgSS9PIHBhZ2UgdGFibGU6IGRldmljZSBpZCA9IDB4MDBh
NSwgcm9vdCB0YWJsZSA9IDB4MjRkODRiMDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9
IDMNCihYRU4pIFsyMDEyLTA5LTA1IDE1OjQ5OjEwXSBBTUQtVmk6IFNldHVwIEkvTyBwYWdl
IHRhYmxlOiBkZXZpY2UgaWQgPSAweDAwYTgsIHJvb3QgdGFibGUgPSAweDI0ZDg0YjAwMCwg
ZG9tYWluID0gMCwgcGFnaW5nIG1vZGUgPSAzDQooWEVOKSBbMjAxMi0wOS0wNSAxNTo0OTox
MF0gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHgwMGIwLCBy
b290IHRhYmxlID0gMHgyNGQ4NGIwMDAsIGRvbWFpbiA9IDAsIHBhZ2luZyBtb2RlID0gMw0K
KFhFTikgWzIwMTItMDktMDUgMTU6NDk6MTBdIEFNRC1WaTogU2V0dXAgSS9PIHBhZ2UgdGFi
bGU6IGRldmljZSBpZCA9IDB4MDBiMiwgcm9vdCB0YWJsZSA9IDB4MjRkODRiMDAwLCBkb21h
aW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMNCihYRU4pIFsyMDEyLTA5LTA1IDE1OjQ5OjEwXSBB
TUQtVmk6IE5vIGlvbW11IGZvciBkZXZpY2UgMDAwMDowMDoxOC4wDQooWEVOKSBbMjAxMi0w
OS0wNSAxNTo0OToxMF0gQU1ELVZpOiBObyBpb21tdSBmb3IgZGV2aWNlIDAwMDA6MDA6MTgu
MQ0KKFhFTikgWzIwMTItMDktMDUgMTU6NDk6MTBdIEFNRC1WaTogTm8gaW9tbXUgZm9yIGRl
dmljZSAwMDAwOjAwOjE4LjINCihYRU4pIFsyMDEyLTA5LTA1IDE1OjQ5OjEwXSBBTUQtVmk6
IE5vIGlvbW11IGZvciBkZXZpY2UgMDAwMDowMDoxOC4zDQooWEVOKSBbMjAxMi0wOS0wNSAx
NTo0OToxMF0gQU1ELVZpOiBObyBpb21tdSBmb3IgZGV2aWNlIDAwMDA6MDA6MTguNA0KKFhF
TikgWzIwMTItMDktMDUgMTU6NDk6MTBdIEFNRC1WaTogU2V0dXAgSS9PIHBhZ2UgdGFibGU6
IGRldmljZSBpZCA9IDB4MDQwMCwgcm9vdCB0YWJsZSA9IDB4MjRkODRiMDAwLCBkb21haW4g
PSAwLCBwYWdpbmcgbW9kZSA9IDMNCihYRU4pIFsyMDEyLTA5LTA1IDE1OjQ5OjEwXSBBTUQt
Vmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweDA0MDEsIHJvb3QgdGFi
bGUgPSAweDI0ZDg0YjAwMCwgZG9tYWluID0gMCwgcGFnaW5nIG1vZGUgPSAzDQooWEVOKSBb
MjAxMi0wOS0wNSAxNTo0OToxMF0gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2
aWNlIGlkID0gMHgwNDAyLCByb290IHRhYmxlID0gMHgyNGQ4NGIwMDAsIGRvbWFpbiA9IDAs
IHBhZ2luZyBtb2RlID0gMw0KKFhFTikgWzIwMTItMDktMDUgMTU6NDk6MTBdIEFNRC1WaTog
U2V0dXAgSS9PIHBhZ2UgdGFibGU6IGRldmljZSBpZCA9IDB4MDQwMywgcm9vdCB0YWJsZSA9
IDB4MjRkODRiMDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMNCihYRU4pIFsyMDEy
LTA5LTA1IDE1OjQ5OjEwXSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2Ug
aWQgPSAweDA0MDQsIHJvb3QgdGFibGUgPSAweDI0ZDg0YjAwMCwgZG9tYWluID0gMCwgcGFn
aW5nIG1vZGUgPSAzDQooWEVOKSBbMjAxMi0wOS0wNSAxNTo0OToxMF0gQU1ELVZpOiBTZXR1
cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHgwNDA1LCByb290IHRhYmxlID0gMHgy
NGQ4NGIwMDAsIGRvbWFpbiA9IDAsIHBhZ2luZyBtb2RlID0gMw0KKFhFTikgWzIwMTItMDkt
MDUgMTU6NDk6MTBdIEFNRC1WaTogU2V0dXAgSS9PIHBhZ2UgdGFibGU6IGRldmljZSBpZCA9
IDB4MDQwNiwgcm9vdCB0YWJsZSA9IDB4MjRkODRiMDAwLCBkb21haW4gPSAwLCBwYWdpbmcg
bW9kZSA9IDMNCihYRU4pIFsyMDEyLTA5LTA1IDE1OjQ5OjEwXSBBTUQtVmk6IFNldHVwIEkv
TyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweDA0MDcsIHJvb3QgdGFibGUgPSAweDI0ZDg0
YjAwMCwgZG9tYWluID0gMCwgcGFnaW5nIG1vZGUgPSAzDQooWEVOKSBbMjAxMi0wOS0wNSAx
NTo0OToxMF0gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHgw
NTAwLCByb290IHRhYmxlID0gMHgyNGQ4NGIwMDAsIGRvbWFpbiA9IDAsIHBhZ2luZyBtb2Rl
ID0gMw0KKFhFTikgWzIwMTItMDktMDUgMTU6NDk6MTBdIEFNRC1WaTogU2V0dXAgSS9PIHBh
Z2UgdGFibGU6IGRldmljZSBpZCA9IDB4MDYwMCwgcm9vdCB0YWJsZSA9IDB4MjRkODRiMDAw
LCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMNCihYRU4pIFsyMDEyLTA5LTA1IDE1OjQ5
OjEwXSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweDA2MDEs
IHJvb3QgdGFibGUgPSAweDI0ZDg0YjAwMCwgZG9tYWluID0gMCwgcGFnaW5nIG1vZGUgPSAz
DQooWEVOKSBbMjAxMi0wOS0wNSAxNTo0OToxMF0gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0
YWJsZTogZGV2aWNlIGlkID0gMHgwNzAwLCByb290IHRhYmxlID0gMHgyNGQ4NGIwMDAsIGRv
bWFpbiA9IDAsIHBhZ2luZyBtb2RlID0gMw0KKFhFTikgWzIwMTItMDktMDUgMTU6NDk6MTBd
IEFNRC1WaTogU2V0dXAgSS9PIHBhZ2UgdGFibGU6IGRldmljZSBpZCA9IDB4MDgwMCwgcm9v
dCB0YWJsZSA9IDB4MjRkODRiMDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMNCihY
RU4pIFsyMDEyLTA5LTA1IDE1OjQ5OjEwXSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxl
OiBkZXZpY2UgaWQgPSAweDA5MDAsIHJvb3QgdGFibGUgPSAweDI0ZDg0YjAwMCwgZG9tYWlu
ID0gMCwgcGFnaW5nIG1vZGUgPSAzDQooWEVOKSBbMjAxMi0wOS0wNSAxNTo0OToxMF0gQU1E
LVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHgwYTAwLCByb290IHRh
YmxlID0gMHgyNGQ4NGIwMDAsIGRvbWFpbiA9IDAsIHBhZ2luZyBtb2RlID0gMw0KKFhFTikg
WzIwMTItMDktMDUgMTU6NDk6MTBdIEFNRC1WaTogU2V0dXAgSS9PIHBhZ2UgdGFibGU6IGRl
dmljZSBpZCA9IDB4MGEwMSwgcm9vdCB0YWJsZSA9IDB4MjRkODRiMDAwLCBkb21haW4gPSAw
LCBwYWdpbmcgbW9kZSA9IDMNCihYRU4pIFsyMDEyLTA5LTA1IDE1OjQ5OjEwXSBBTUQtVmk6
IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweDBhMDIsIHJvb3QgdGFibGUg
PSAweDI0ZDg0YjAwMCwgZG9tYWluID0gMCwgcGFnaW5nIG1vZGUgPSAzDQooWEVOKSBbMjAx
Mi0wOS0wNSAxNTo0OToxMF0gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNl
IGlkID0gMHgwYTAzLCByb290IHRhYmxlID0gMHgyNGQ4NGIwMDAsIGRvbWFpbiA9IDAsIHBh
Z2luZyBtb2RlID0gMw0KKFhFTikgWzIwMTItMDktMDUgMTU6NDk6MTBdIEFNRC1WaTogU2V0
dXAgSS9PIHBhZ2UgdGFibGU6IGRldmljZSBpZCA9IDB4MGEwNCwgcm9vdCB0YWJsZSA9IDB4
MjRkODRiMDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMNCihYRU4pIFsyMDEyLTA5
LTA1IDE1OjQ5OjEwXSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQg
PSAweDBhMDUsIHJvb3QgdGFibGUgPSAweDI0ZDg0YjAwMCwgZG9tYWluID0gMCwgcGFnaW5n
IG1vZGUgPSAzDQooWEVOKSBbMjAxMi0wOS0wNSAxNTo0OToxMF0gQU1ELVZpOiBTZXR1cCBJ
L08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHgwYTA2LCByb290IHRhYmxlID0gMHgyNGQ4
NGIwMDAsIGRvbWFpbiA9IDAsIHBhZ2luZyBtb2RlID0gMw0KKFhFTikgWzIwMTItMDktMDUg
MTU6NDk6MTBdIEFNRC1WaTogU2V0dXAgSS9PIHBhZ2UgdGFibGU6IGRldmljZSBpZCA9IDB4
MGEwNywgcm9vdCB0YWJsZSA9IDB4MjRkODRiMDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9k
ZSA9IDMNCihYRU4pIFsyMDEyLTA5LTA1IDE1OjQ5OjEwXSBBTUQtVmk6IFNldHVwIEkvTyBw
YWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweDBiMDAsIHJvb3QgdGFibGUgPSAweDI0ZDg0YjAw
MCwgZG9tYWluID0gMCwgcGFnaW5nIG1vZGUgPSAzDQooWEVOKSBbMjAxMi0wOS0wNSAxNTo0
OToxMF0gU2NydWJiaW5nIEZyZWUgUkFNOiAuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi48
MD5BTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MGEw
NiwgZmF1bHQgYWRkcmVzcyA9IDB4YzJjMmMyYzAsIGZsYWdzID0gMHgwMDANCihYRU4pIFsy
MDEyLTA5LTA1IDE1OjQ5OjExXSAuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u
Li4uLi4uLi4uLmRvbmUuDQooWEVOKSBbMjAxMi0wOS0wNSAxNTo0OToxMl0gSW5pdGlhbCBs
b3cgbWVtb3J5IHZpcnEgdGhyZXNob2xkIHNldCBhdCAweDQwMDAgcGFnZXMuDQooWEVOKSBb
MjAxMi0wOS0wNSAxNTo0OToxMl0gU3RkLiBMb2dsZXZlbDogQWxsDQooWEVOKSBbMjAxMi0w
OS0wNSAxNTo0OToxMl0gR3Vlc3QgTG9nbGV2ZWw6IEFsbA0KKFhFTikgWzIwMTItMDktMDUg
MTU6NDk6MTJdIFhlbiBpcyByZWxpbnF1aXNoaW5nIFZHQSBjb25zb2xlLg0KKFhFTikgWzIw
MTItMDktMDUgMTU6NDk6MTJdICoqKiBTZXJpYWwgaW5wdXQgLT4gRE9NMCAodHlwZSAnQ1RS
TC1hJyB0aHJlZSB0aW1lcyB0byBzd2l0Y2ggaW5wdXQgdG8gWGVuKQ0KKFhFTikgWzIwMTIt
MDktMDUgMTU6NDk6MTJdIEZyZWVkIDI1NmtCIGluaXQgbWVtb3J5Lg0KKFhFTikgWzIwMTIt
MDktMDUgMTU6NDk6MTJdIElPQVBJQ1swXTogU2V0IFBDSSByb3V0aW5nIGVudHJ5ICg2LTkg
LT4gMHg2MCAtPiBJUlEgOSBNb2RlOjEgQWN0aXZlOjEpDQooWEVOKSBbMjAxMi0wOS0wNSAx
NTo0OToxMl0gdHJhcHMuYzoyNTg0OmQwIERvbWFpbiBhdHRlbXB0ZWQgV1JNU1IgMDAwMDAw
MDBjMDAwMDQwOCBmcm9tIDB4YzAwMDAwMDAwMTAwMDAwMCB0byAweGMwMDgwMDAwMDEwMDAw
MDAuDQooWEVOKSBbMjAxMi0wOS0wNSAxNTo0OToxMl0gdHJhcHMuYzoyNTg0OmQwIERvbWFp
biBhdHRlbXB0ZWQgV1JNU1IgMDAwMDAwMDBjMDAwMDQwOSBmcm9tIDB4YzAwMDAwMDAwMTAw
MDAwMCB0byAweGMwMDgwMDAwMDEwMDAwMDAuDQooWEVOKSBbMjAxMi0wOS0wNSAxNTo0OTox
Ml0gdHJhcHMuYzoyNTg0OmQwIERvbWFpbiBhdHRlbXB0ZWQgV1JNU1IgMDAwMDAwMDBjMDAx
MDAwNCBmcm9tIDB4MDAwMGVmZjBiZGZiMWZjZSB0byAweDAwMDAwMDAwMDAwMGFiY2QuDQoo
WEVOKSBbMjAxMi0wOS0wNSAxNTo0OToxMl0gdHJhcHMuYzoyNTg0OmQwIERvbWFpbiBhdHRl
bXB0ZWQgV1JNU1IgMDAwMDAwMDBjMDAwMDQwOCBmcm9tIDB4YzAwMDAwMDAwMTAwMDAwMCB0
byAweGMwMDgwMDAwMDEwMDAwMDAuDQooWEVOKSBbMjAxMi0wOS0wNSAxNTo0OToxMl0gdHJh
cHMuYzoyNTg0OmQwIERvbWFpbiBhdHRlbXB0ZWQgV1JNU1IgMDAwMDAwMDBjMDAwMDQwOSBm
cm9tIDB4YzAwMDAwMDAwMTAwMDAwMCB0byAweGMwMDgwMDAwMDEwMDAwMDAuDQooWEVOKSBb
MjAxMi0wOS0wNSAxNTo0OToxMl0gdHJhcHMuYzoyNTg0OmQwIERvbWFpbiBhdHRlbXB0ZWQg
V1JNU1IgMDAwMDAwMDBjMDAwMDQwOCBmcm9tIDB4YzAwMDAwMDAwMTAwMDAwMCB0byAweGMw
MDgwMDAwMDEwMDAwMDAuDQooWEVOKSBbMjAxMi0wOS0wNSAxNTo0OToxMl0gdHJhcHMuYzoy
NTg0OmQwIERvbWFpbiBhdHRlbXB0ZWQgV1JNU1IgMDAwMDAwMDBjMDAwMDQwOSBmcm9tIDB4
YzAwMDAwMDAwMTAwMDAwMCB0byAweGMwMDgwMDAwMDEwMDAwMDAuDQooWEVOKSBbMjAxMi0w
OS0wNSAxNTo0OToxM10gdHJhcHMuYzoyNTg0OmQwIERvbWFpbiBhdHRlbXB0ZWQgV1JNU1Ig
MDAwMDAwMDBjMDAwMDQwOCBmcm9tIDB4YzAwMDAwMDAwMTAwMDAwMCB0byAweGMwMDgwMDAw
MDEwMDAwMDAuDQooWEVOKSBbMjAxMi0wOS0wNSAxNTo0OToxM10gdHJhcHMuYzoyNTg0OmQw
IERvbWFpbiBhdHRlbXB0ZWQgV1JNU1IgMDAwMDAwMDBjMDAwMDQwOSBmcm9tIDB4YzAwMDAw
MDAwMTAwMDAwMCB0byAweGMwMDgwMDAwMDEwMDAwMDAuDQooWEVOKSBbMjAxMi0wOS0wNSAx
NTo0OToxM10gdHJhcHMuYzoyNTg0OmQwIERvbWFpbiBhdHRlbXB0ZWQgV1JNU1IgMDAwMDAw
MDBjMDAwMDQwOCBmcm9tIDB4YzAwMDAwMDAwMTAwMDAwMCB0byAweGMwMDgwMDAwMDEwMDAw
MDAuDQooWEVOKSBbMjAxMi0wOS0wNSAxNTo0OToxM10gdHJhcHMuYzoyNTg0OmQwIERvbWFp
biBhdHRlbXB0ZWQgV1JNU1IgMDAwMDAwMDBjMDAwMDQwOSBmcm9tIDB4YzAwMDAwMDAwMTAw
MDAwMCB0byAweGMwMDgwMDAwMDEwMDAwMDAuDQooWEVOKSBbMjAxMi0wOS0wNSAxNTo0OTox
M10gdHJhcHMuYzoyNTg0OmQwIERvbWFpbiBhdHRlbXB0ZWQgV1JNU1IgMDAwMDAwMDBjMDAw
MDQwOCBmcm9tIDB4YzAwMDAwMDAwMTAwMDAwMCB0byAweGMwMDgwMDAwMDEwMDAwMDAuDQoo
WEVOKSBbMjAxMi0wOS0wNSAxNTo0OToxM10gdHJhcHMuYzoyNTg0OmQwIERvbWFpbiBhdHRl
bXB0ZWQgV1JNU1IgMDAwMDAwMDBjMDAwMDQwOSBmcm9tIDB4YzAwMDAwMDAwMTAwMDAwMCB0
byAweGMwMDgwMDAwMDEwMDAwMDAuDQooWEVOKSBbMjAxMi0wOS0wNSAxNTo0OToxM10gUENJ
IGFkZCBkZXZpY2UgMDAwMDowMDowMC4wDQooWEVOKSBbMjAxMi0wOS0wNSAxNTo0OToxM10g
UENJIGFkZCBkZXZpY2UgMDAwMDowMDowMC4yDQooWEVOKSBbMjAxMi0wOS0wNSAxNTo0OTox
M10gUENJIGFkZCBkZXZpY2UgMDAwMDowMDowMi4wDQooWEVOKSBbMjAxMi0wOS0wNSAxNTo0
OToxM10gUENJIGFkZCBkZXZpY2UgMDAwMDowMDowMy4wDQooWEVOKSBbMjAxMi0wOS0wNSAx
NTo0OToxM10gUENJIGFkZCBkZXZpY2UgMDAwMDowMDowNS4wDQooWEVOKSBbMjAxMi0wOS0w
NSAxNTo0OToxM10gUENJIGFkZCBkZXZpY2UgMDAwMDowMDowNi4wDQooWEVOKSBbMjAxMi0w
OS0wNSAxNTo0OToxM10gUENJIGFkZCBkZXZpY2UgMDAwMDowMDowYS4wDQooWEVOKSBbMjAx
Mi0wOS0wNSAxNTo0OToxM10gUENJIGFkZCBkZXZpY2UgMDAwMDowMDowYi4wDQooWEVOKSBb
MjAxMi0wOS0wNSAxNTo0OToxM10gUENJIGFkZCBkZXZpY2UgMDAwMDowMDowYy4wDQooWEVO
KSBbMjAxMi0wOS0wNSAxNTo0OToxM10gUENJIGFkZCBkZXZpY2UgMDAwMDowMDowZC4wDQoo
WEVOKSBbMjAxMi0wOS0wNSAxNTo0OToxM10gUENJIGFkZCBkZXZpY2UgMDAwMDowMDoxMS4w
DQooWEVOKSBbMjAxMi0wOS0wNSAxNTo0OToxM10gUENJIGFkZCBkZXZpY2UgMDAwMDowMDox
Mi4wDQooWEVOKSBbMjAxMi0wOS0wNSAxNTo0OToxM10gUENJIGFkZCBkZXZpY2UgMDAwMDow
MDoxMi4yDQooWEVOKSBbMjAxMi0wOS0wNSAxNTo0OToxM10gUENJIGFkZCBkZXZpY2UgMDAw
MDowMDoxMy4wDQooWEVOKSBbMjAxMi0wOS0wNSAxNTo0OToxM10gUENJIGFkZCBkZXZpY2Ug
MDAwMDowMDoxMy4yDQooWEVOKSBbMjAxMi0wOS0wNSAxNTo0OToxM10gUENJIGFkZCBkZXZp
Y2UgMDAwMDowMDoxNC4wDQooWEVOKSBbMjAxMi0wOS0wNSAxNTo0OToxM10gUENJIGFkZCBk
ZXZpY2UgMDAwMDowMDoxNC4zDQooWEVOKSBbMjAxMi0wOS0wNSAxNTo0OToxM10gUENJIGFk
ZCBkZXZpY2UgMDAwMDowMDoxNC40DQooWEVOKSBbMjAxMi0wOS0wNSAxNTo0OToxM10gUENJ
IGFkZCBkZXZpY2UgMDAwMDowMDoxNC41DQooWEVOKSBbMjAxMi0wOS0wNSAxNTo0OToxM10g
UENJIGFkZCBkZXZpY2UgMDAwMDowMDoxNS4wDQooWEVOKSBbMjAxMi0wOS0wNSAxNTo0OTox
M10gUENJIGFkZCBkZXZpY2UgMDAwMDowMDoxNi4wDQooWEVOKSBbMjAxMi0wOS0wNSAxNTo0
OToxM10gUENJIGFkZCBkZXZpY2UgMDAwMDowMDoxNi4yDQooWEVOKSBbMjAxMi0wOS0wNSAx
NTo0OToxM10gUENJIGFkZCBkZXZpY2UgMDAwMDowMDoxOC4wDQooWEVOKSBbMjAxMi0wOS0w
NSAxNTo0OToxM10gUENJIGFkZCBkZXZpY2UgMDAwMDowMDoxOC4xDQooWEVOKSBbMjAxMi0w
OS0wNSAxNTo0OToxM10gUENJIGFkZCBkZXZpY2UgMDAwMDowMDoxOC4yDQooWEVOKSBbMjAx
Mi0wOS0wNSAxNTo0OToxM10gUENJIGFkZCBkZXZpY2UgMDAwMDowMDoxOC4zDQooWEVOKSBb
MjAxMi0wOS0wNSAxNTo0OToxM10gUENJIGFkZCBkZXZpY2UgMDAwMDowMDoxOC40DQooWEVO
KSBbMjAxMi0wOS0wNSAxNTo0OToxM10gUENJIGFkZCBkZXZpY2UgMDAwMDowYjowMC4wDQoo
WEVOKSBbMjAxMi0wOS0wNSAxNTo0OToxM10gUENJIGFkZCBkZXZpY2UgMDAwMDowYTowMC4w
DQooWEVOKSBbMjAxMi0wOS0wNSAxNTo0OToxM10gUENJIGFkZCBkZXZpY2UgMDAwMDowYTow
MC4xDQooWEVOKSBbMjAxMi0wOS0wNSAxNTo0OToxM10gUENJIGFkZCBkZXZpY2UgMDAwMDow
YTowMC4yDQooWEVOKSBbMjAxMi0wOS0wNSAxNTo0OToxM10gUENJIGFkZCBkZXZpY2UgMDAw
MDowYTowMC4zDQooWEVOKSBbMjAxMi0wOS0wNSAxNTo0OToxM10gUENJIGFkZCBkZXZpY2Ug
MDAwMDowYTowMC40DQooWEVOKSBbMjAxMi0wOS0wNSAxNTo0OToxM10gUENJIGFkZCBkZXZp
Y2UgMDAwMDowYTowMC41DQooWEVOKSBbMjAxMi0wOS0wNSAxNTo0OToxM10gUENJIGFkZCBk
ZXZpY2UgMDAwMDowYTowMC42DQooWEVOKSBbMjAxMi0wOS0wNSAxNTo0OToxM10gUENJIGFk
ZCBkZXZpY2UgMDAwMDowYTowMC43DQooWEVOKSBbMjAxMi0wOS0wNSAxNTo0OToxM10gUENJ
IGFkZCBkZXZpY2UgMDAwMDowOTowMC4wDQooWEVOKSBbMjAxMi0wOS0wNSAxNTo0OToxM10g
UENJIGFkZCBkZXZpY2UgMDAwMDowODowMC4wDQooWEVOKSBbMjAxMi0wOS0wNSAxNTo0OTox
M10gUENJIGFkZCBkZXZpY2UgMDAwMDowNzowMC4wDQooWEVOKSBbMjAxMi0wOS0wNSAxNTo0
OToxM10gUENJIGFkZCBkZXZpY2UgMDAwMDowNjowMC4wDQooWEVOKSBbMjAxMi0wOS0wNSAx
NTo0OToxM10gUENJIGFkZCBkZXZpY2UgMDAwMDowNjowMC4xDQooWEVOKSBbMjAxMi0wOS0w
NSAxNTo0OToxM10gUENJIGFkZCBkZXZpY2UgMDAwMDowNTowMC4wDQooWEVOKSBbMjAxMi0w
OS0wNSAxNTo0OToxM10gUENJIGFkZCBkZXZpY2UgMDAwMDowNDowMC4wDQooWEVOKSBbMjAx
Mi0wOS0wNSAxNTo0OToxM10gUENJIGFkZCBkZXZpY2UgMDAwMDowNDowMC4xDQooWEVOKSBb
MjAxMi0wOS0wNSAxNTo0OToxM10gUENJIGFkZCBkZXZpY2UgMDAwMDowNDowMC4yDQooWEVO
KSBbMjAxMi0wOS0wNSAxNTo0OToxM10gUENJIGFkZCBkZXZpY2UgMDAwMDowNDowMC4zDQoo
WEVOKSBbMjAxMi0wOS0wNSAxNTo0OToxM10gUENJIGFkZCBkZXZpY2UgMDAwMDowNDowMC40
DQooWEVOKSBbMjAxMi0wOS0wNSAxNTo0OToxM10gUENJIGFkZCBkZXZpY2UgMDAwMDowNDow
MC41DQooWEVOKSBbMjAxMi0wOS0wNSAxNTo0OToxM10gUENJIGFkZCBkZXZpY2UgMDAwMDow
NDowMC42DQooWEVOKSBbMjAxMi0wOS0wNSAxNTo0OToxM10gUENJIGFkZCBkZXZpY2UgMDAw
MDowNDowMC43DQooWEVOKSBbMjAxMi0wOS0wNSAxNTo0OToxM10gUENJIGFkZCBkZXZpY2Ug
MDAwMDowMzowNi4wDQooWEVOKSBbMjAxMi0wOS0wNSAxNTo0OToxM10gSU9BUElDWzBdOiBT
ZXQgUENJIHJvdXRpbmcgZW50cnkgKDYtOCAtPiAweDU4IC0+IElSUSA4IE1vZGU6MCBBY3Rp
dmU6MCkNCihYRU4pIFsyMDEyLTA5LTA1IDE1OjQ5OjEzXSBJT0FQSUNbMF06IFNldCBQQ0kg
cm91dGluZyBlbnRyeSAoNi0xMyAtPiAweDg4IC0+IElSUSAxMyBNb2RlOjAgQWN0aXZlOjAp
DQooWEVOKSBbMjAxMi0wOS0wNSAxNTo0OToxM10gSU9BUElDWzFdOiBTZXQgUENJIHJvdXRp
bmcgZW50cnkgKDctMjggLT4gMHhhMCAtPiBJUlEgNTIgTW9kZToxIEFjdGl2ZToxKQ0KKFhF
TikgWzIwMTItMDktMDUgMTU6NDk6MTNdIElPQVBJQ1sxXTogU2V0IFBDSSByb3V0aW5nIGVu
dHJ5ICg3LTI5IC0+IDB4YTggLT4gSVJRIDUzIE1vZGU6MSBBY3RpdmU6MSkNCihYRU4pIFsy
MDEyLTA5LTA1IDE1OjQ5OjEzXSBJT0FQSUNbMV06IFNldCBQQ0kgcm91dGluZyBlbnRyeSAo
Ny0zMCAtPiAweGIwIC0+IElSUSA1NCBNb2RlOjEgQWN0aXZlOjEpDQooWEVOKSBbMjAxMi0w
OS0wNSAxNTo0OToxM10gSU9BUElDWzBdOiBTZXQgUENJIHJvdXRpbmcgZW50cnkgKDYtMTYg
LT4gMHhiOCAtPiBJUlEgMTYgTW9kZToxIEFjdGl2ZToxKQ0KKFhFTikgWzIwMTItMDktMDUg
MTU6NDk6MTNdIElPQVBJQ1swXTogU2V0IFBDSSByb3V0aW5nIGVudHJ5ICg2LTE4IC0+IDB4
YzAgLT4gSVJRIDE4IE1vZGU6MSBBY3RpdmU6MSkNCihYRU4pIFsyMDEyLTA5LTA1IDE1OjQ5
OjEzXSBJT0FQSUNbMF06IFNldCBQQ0kgcm91dGluZyBlbnRyeSAoNi0xNyAtPiAweGM4IC0+
IElSUSAxNyBNb2RlOjEgQWN0aXZlOjEpDQooWEVOKSBbMjAxMi0wOS0wNSAxNTo0OToxM10g
SU9BUElDWzFdOiBTZXQgUENJIHJvdXRpbmcgZW50cnkgKDctNCAtPiAweGQwIC0+IElSUSAy
OCBNb2RlOjEgQWN0aXZlOjEpDQooWEVOKSBbMjAxMi0wOS0wNSAxNTo0OToxM10gSU9BUElD
WzFdOiBTZXQgUENJIHJvdXRpbmcgZW50cnkgKDctNSAtPiAweGQ4IC0+IElSUSAyOSBNb2Rl
OjEgQWN0aXZlOjEpDQooWEVOKSBbMjAxMi0wOS0wNSAxNTo0OToxM10gSU9BUElDWzFdOiBT
ZXQgUENJIHJvdXRpbmcgZW50cnkgKDctNiAtPiAweDIxIC0+IElSUSAzMCBNb2RlOjEgQWN0
aXZlOjEpDQooWEVOKSBbMjAxMi0wOS0wNSAxNTo0OToxM10gSU9BUElDWzFdOiBTZXQgUENJ
IHJvdXRpbmcgZW50cnkgKDctNyAtPiAweDI5IC0+IElSUSAzMSBNb2RlOjEgQWN0aXZlOjEp
DQooWEVOKSBbMjAxMi0wOS0wNSAxNTo0OToxM10gSU9BUElDWzFdOiBTZXQgUENJIHJvdXRp
bmcgZW50cnkgKDctMTYgLT4gMHgzMSAtPiBJUlEgNDAgTW9kZToxIEFjdGl2ZToxKQ0KKFhF
TikgWzIwMTItMDktMDUgMTU6NDk6MTNdIElPQVBJQ1sxXTogU2V0IFBDSSByb3V0aW5nIGVu
dHJ5ICg3LTE3IC0+IDB4MzkgLT4gSVJRIDQxIE1vZGU6MSBBY3RpdmU6MSkNCihYRU4pIFsy
MDEyLTA5LTA1IDE1OjQ5OjEzXSBJT0FQSUNbMV06IFNldCBQQ0kgcm91dGluZyBlbnRyeSAo
Ny0xOCAtPiAweDQxIC0+IElSUSA0MiBNb2RlOjEgQWN0aXZlOjEpDQooWEVOKSBbMjAxMi0w
OS0wNSAxNTo0OToxM10gSU9BUElDWzFdOiBTZXQgUENJIHJvdXRpbmcgZW50cnkgKDctMTkg
LT4gMHg0OSAtPiBJUlEgNDMgTW9kZToxIEFjdGl2ZToxKQ0KKFhFTikgWzIwMTItMDktMDUg
MTU6NDk6MTRdIElPQVBJQ1swXTogU2V0IFBDSSByb3V0aW5nIGVudHJ5ICg2LTIyIC0+IDB4
OTkgLT4gSVJRIDIyIE1vZGU6MSBBY3RpdmU6MSkNCihYRU4pIFsyMDEyLTA5LTA1IDE1OjQ5
OjE0XSBJT0FQSUNbMV06IFNldCBQQ0kgcm91dGluZyBlbnRyeSAoNy0xMiAtPiAweGExIC0+
IElSUSAzNiBNb2RlOjEgQWN0aXZlOjEpDQooWEVOKSBbMjAxMi0wOS0wNSAxNTo0OToxNF0g
SU9BUElDWzFdOiBTZXQgUENJIHJvdXRpbmcgZW50cnkgKDctMjMgLT4gMHhhOSAtPiBJUlEg
NDcgTW9kZToxIEFjdGl2ZToxKQ0KKFhFTikgWzIwMTItMDktMDUgMTU6NDk6MTRdIElPQVBJ
Q1swXTogU2V0IFBDSSByb3V0aW5nIGVudHJ5ICg2LTE5IC0+IDB4YjEgLT4gSVJRIDE5IE1v
ZGU6MSBBY3RpdmU6MSkNCihYRU4pIFsyMDEyLTA5LTA1IDE1OjQ5OjE0XSBJT0FQSUNbMV06
IFNldCBQQ0kgcm91dGluZyBlbnRyeSAoNy0yMiAtPiAweGMxIC0+IElSUSA0NiBNb2RlOjEg
QWN0aXZlOjEpDQooWEVOKSBbMjAxMi0wOS0wNSAxNTo0OToxNF0gSU9BUElDWzFdOiBTZXQg
UENJIHJvdXRpbmcgZW50cnkgKDctMjcgLT4gMHhkMSAtPiBJUlEgNTEgTW9kZToxIEFjdGl2
ZToxKQ0KKFhFTikgWzIwMTItMDktMDUgMTU6NDk6MTZdIElPQVBJQ1sxXTogU2V0IFBDSSBy
b3V0aW5nIGVudHJ5ICg3LTkgLT4gMHgyMiAtPiBJUlEgMzMgTW9kZToxIEFjdGl2ZToxKQ0K
KFhFTikgWzIwMTItMDktMDUgMTU6NTA6MTldIHRyYXBzLmM6MjU4NDpkMSBEb21haW4gYXR0
ZW1wdGVkIFdSTVNSIDAwMDAwMDAwYzAwMTAwMDQgZnJvbSAweDAwMDA2ZmIwMzlkZTc5MDAg
dG8gMHgwMDAwMDAwMDAwMDBhYmNkLg0KKFhFTikgWzIwMTItMDktMDUgMTU6NTA6MjVdIHRy
YXBzLmM6MjU4NDpkMiBEb21haW4gYXR0ZW1wdGVkIFdSTVNSIDAwMDAwMDAwYzAwMTAwMDQg
ZnJvbSAweDAwMDA0MjM0NWEwZGE1NDUgdG8gMHgwMDAwMDAwMDAwMDBhYmNkLg0KKFhFTikg
WzIwMTItMDktMDUgMTU6NTA6MzddIHRyYXBzLmM6MjU4NDpkMyBEb21haW4gYXR0ZW1wdGVk
IFdSTVNSIDAwMDAwMDAwYzAwMTAwMDQgZnJvbSAweDAwMDA2ZmIwMzlkZTc5MDAgdG8gMHgw
MDAwMDAwMDAwMDBhYmNkLg0KKFhFTikgWzIwMTItMDktMDUgMTU6NTA6MzddIHRyYXBzLmM6
MjU4NDpkNCBEb21haW4gYXR0ZW1wdGVkIFdSTVNSIDAwMDAwMDAwYzAwMTAwMDQgZnJvbSAw
eDAwMDA2ZmIwMzlkZTc5MDAgdG8gMHgwMDAwMDAwMDAwMDBhYmNkLg0KKFhFTikgWzIwMTIt
MDktMDUgMTU6NTA6NDNdIHRyYXBzLmM6MjU4NDpkNSBEb21haW4gYXR0ZW1wdGVkIFdSTVNS
IDAwMDAwMDAwYzAwMTAwMDQgZnJvbSAweDAwMDA0MjM0NWEwZGE1NDUgdG8gMHgwMDAwMDAw
MDAwMDBhYmNkLg0KKFhFTikgWzIwMTItMDktMDUgMTU6NTA6NDldIHRyYXBzLmM6MjU4NDpk
NiBEb21haW4gYXR0ZW1wdGVkIFdSTVNSIDAwMDAwMDAwYzAwMTAwMDQgZnJvbSAweDAwMDA0
MjM0NWEwZGE1NDUgdG8gMHgwMDAwMDAwMDAwMDBhYmNkLg0KKFhFTikgWzIwMTItMDktMDUg
MTU6NTA6NTVdIHRyYXBzLmM6MjU4NDpkNyBEb21haW4gYXR0ZW1wdGVkIFdSTVNSIDAwMDAw
MDAwYzAwMTAwMDQgZnJvbSAweDAwMDBhMTk1YzQwZjYxOGYgdG8gMHgwMDAwMDAwMDAwMDBh
YmNkLg0KKFhFTikgWzIwMTItMDktMDUgMTU6NTE6MDFdIHRyYXBzLmM6MjU4NDpkOCBEb21h
aW4gYXR0ZW1wdGVkIFdSTVNSIDAwMDAwMDAwYzAwMTAwMDQgZnJvbSAweDAwMDA4Njc5YzAy
YjQxNjUgdG8gMHgwMDAwMDAwMDAwMDBhYmNkLg0KKFhFTikgWzIwMTItMDktMDUgMTU6NTE6
MDddIHRyYXBzLmM6MjU4NDpkOSBEb21haW4gYXR0ZW1wdGVkIFdSTVNSIDAwMDAwMDAwYzAw
MTAwMDQgZnJvbSAweDAwMDBhMTk1YzQwZjYxOGYgdG8gMHgwMDAwMDAwMDAwMDBhYmNkLg0K
KFhFTikgWzIwMTItMDktMDUgMTU6NTE6MTNdIHRyYXBzLmM6MjU4NDpkMTAgRG9tYWluIGF0
dGVtcHRlZCBXUk1TUiAwMDAwMDAwMGMwMDEwMDA0IGZyb20gMHgwMDAwYTE5NWM0MGY2MThm
IHRvIDB4MDAwMDAwMDAwMDAwYWJjZC4NCihYRU4pIFsyMDEyLTA5LTA1IDE1OjUxOjIyXSBB
TUQtVmk6IERpc2FibGU6IGRldmljZSBpZCA9IDB4MDBhNCwgZG9tYWluID0gMCwgcGFnaW5n
IG1vZGUgPSAzDQooWEVOKSBbMjAxMi0wOS0wNSAxNTo1MToyMl0gQU1ELVZpOiBTZXR1cCBJ
L08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHgwMGE0LCByb290IHRhYmxlID0gMHgxOGUw
YTEwMDAsIGRvbWFpbiA9IDExLCBwYWdpbmcgbW9kZSA9IDMNCihYRU4pIFsyMDEyLTA5LTA1
IDE1OjUxOjIyXSBBTUQtVmk6IFJlLWFzc2lnbiAwMDAwOjAzOjA2LjAgZnJvbSBkb20wIHRv
IGRvbTExDQooWEVOKSBbMjAxMi0wOS0wNSAxNTo1MToyMl0gdHJhcHMuYzoyNTg0OmQxMSBE
b21haW4gYXR0ZW1wdGVkIFdSTVNSIDAwMDAwMDAwYzAwMTAwMDQgZnJvbSAweDAwMDBhMTk1
YzQwZjYxOGYgdG8gMHgwMDAwMDAwMDAwMDBhYmNkLg0KKFhFTikgWzIwMTItMDktMDUgMTU6
NTE6MjhdIHRyYXBzLmM6MjU4NDpkMTIgRG9tYWluIGF0dGVtcHRlZCBXUk1TUiAwMDAwMDAw
MGMwMDEwMDA0IGZyb20gMHgwMDAwYTE5NWM0MGY2MThmIHRvIDB4MDAwMDAwMDAwMDAwYWJj
ZC4NCihYRU4pIFsyMDEyLTA5LTA1IDE1OjUxOjM1XSB0cmFwcy5jOjI1ODQ6ZDEzIERvbWFp
biBhdHRlbXB0ZWQgV1JNU1IgMDAwMDAwMDBjMDAxMDAwNCBmcm9tIDB4MDAwMDQyMzQ1YTBk
YTU0NSB0byAweDAwMDAwMDAwMDAwMGFiY2QuDQooWEVOKSBbMjAxMi0wOS0wNSAxNTo1MTo0
MV0gQU1ELVZpOiBEaXNhYmxlOiBkZXZpY2UgaWQgPSAweDBhMDAsIGRvbWFpbiA9IDAsIHBh
Z2luZyBtb2RlID0gMw0KKFhFTikgWzIwMTItMDktMDUgMTU6NTE6NDFdIEFNRC1WaTogU2V0
dXAgSS9PIHBhZ2UgdGFibGU6IGRldmljZSBpZCA9IDB4MGEwMCwgcm9vdCB0YWJsZSA9IDB4
MWUxZmMwMDAwLCBkb21haW4gPSAxNCwgcGFnaW5nIG1vZGUgPSAzDQooWEVOKSBbMjAxMi0w
OS0wNSAxNTo1MTo0MV0gQU1ELVZpOiBSZS1hc3NpZ24gMDAwMDowYTowMC4wIGZyb20gZG9t
MCB0byBkb20xNA0KKFhFTikgWzIwMTItMDktMDUgMTU6NTE6NDFdIEFNRC1WaTogRGlzYWJs
ZTogZGV2aWNlIGlkID0gMHgwYTAxLCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMNCihY
RU4pIFsyMDEyLTA5LTA1IDE1OjUxOjQxXSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxl
OiBkZXZpY2UgaWQgPSAweDBhMDEsIHJvb3QgdGFibGUgPSAweDFlMWZjMDAwMCwgZG9tYWlu
ID0gMTQsIHBhZ2luZyBtb2RlID0gMw0KKFhFTikgWzIwMTItMDktMDUgMTU6NTE6NDFdIEFN
RC1WaTogUmUtYXNzaWduIDAwMDA6MGE6MDAuMSBmcm9tIGRvbTAgdG8gZG9tMTQNCihYRU4p
IFsyMDEyLTA5LTA1IDE1OjUxOjQxXSBBTUQtVmk6IERpc2FibGU6IGRldmljZSBpZCA9IDB4
MGEwMiwgZG9tYWluID0gMCwgcGFnaW5nIG1vZGUgPSAzDQooWEVOKSBbMjAxMi0wOS0wNSAx
NTo1MTo0MV0gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHgw
YTAyLCByb290IHRhYmxlID0gMHgxZTFmYzAwMDAsIGRvbWFpbiA9IDE0LCBwYWdpbmcgbW9k
ZSA9IDMNCihYRU4pIFsyMDEyLTA5LTA1IDE1OjUxOjQxXSBBTUQtVmk6IFJlLWFzc2lnbiAw
MDAwOjBhOjAwLjIgZnJvbSBkb20wIHRvIGRvbTE0DQooWEVOKSBbMjAxMi0wOS0wNSAxNTo1
MTo0MV0gQU1ELVZpOiBEaXNhYmxlOiBkZXZpY2UgaWQgPSAweDBhMDMsIGRvbWFpbiA9IDAs
IHBhZ2luZyBtb2RlID0gMw0KKFhFTikgWzIwMTItMDktMDUgMTU6NTE6NDFdIEFNRC1WaTog
U2V0dXAgSS9PIHBhZ2UgdGFibGU6IGRldmljZSBpZCA9IDB4MGEwMywgcm9vdCB0YWJsZSA9
IDB4MWUxZmMwMDAwLCBkb21haW4gPSAxNCwgcGFnaW5nIG1vZGUgPSAzDQooWEVOKSBbMjAx
Mi0wOS0wNSAxNTo1MTo0MV0gQU1ELVZpOiBSZS1hc3NpZ24gMDAwMDowYTowMC4zIGZyb20g
ZG9tMCB0byBkb20xNA0KKFhFTikgWzIwMTItMDktMDUgMTU6NTE6NDFdIEFNRC1WaTogRGlz
YWJsZTogZGV2aWNlIGlkID0gMHgwYTA0LCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMN
CihYRU4pIFsyMDEyLTA5LTA1IDE1OjUxOjQxXSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRh
YmxlOiBkZXZpY2UgaWQgPSAweDBhMDQsIHJvb3QgdGFibGUgPSAweDFlMWZjMDAwMCwgZG9t
YWluID0gMTQsIHBhZ2luZyBtb2RlID0gMw0KKFhFTikgWzIwMTItMDktMDUgMTU6NTE6NDFd
IEFNRC1WaTogUmUtYXNzaWduIDAwMDA6MGE6MDAuNCBmcm9tIGRvbTAgdG8gZG9tMTQNCihY
RU4pIFsyMDEyLTA5LTA1IDE1OjUxOjQxXSBBTUQtVmk6IERpc2FibGU6IGRldmljZSBpZCA9
IDB4MGEwNSwgZG9tYWluID0gMCwgcGFnaW5nIG1vZGUgPSAzDQooWEVOKSBbMjAxMi0wOS0w
NSAxNTo1MTo0MV0gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0g
MHgwYTA1LCByb290IHRhYmxlID0gMHgxZTFmYzAwMDAsIGRvbWFpbiA9IDE0LCBwYWdpbmcg
bW9kZSA9IDMNCihYRU4pIFsyMDEyLTA5LTA1IDE1OjUxOjQxXSBBTUQtVmk6IFJlLWFzc2ln
biAwMDAwOjBhOjAwLjUgZnJvbSBkb20wIHRvIGRvbTE0DQooWEVOKSBbMjAxMi0wOS0wNSAx
NTo1MTo0MV0gQU1ELVZpOiBEaXNhYmxlOiBkZXZpY2UgaWQgPSAweDBhMDYsIGRvbWFpbiA9
IDAsIHBhZ2luZyBtb2RlID0gMw0KKFhFTikgWzIwMTItMDktMDUgMTU6NTE6NDFdIEFNRC1W
aTogU2V0dXAgSS9PIHBhZ2UgdGFibGU6IGRldmljZSBpZCA9IDB4MGEwNiwgcm9vdCB0YWJs
ZSA9IDB4MWUxZmMwMDAwLCBkb21haW4gPSAxNCwgcGFnaW5nIG1vZGUgPSAzDQooWEVOKSBb
MjAxMi0wOS0wNSAxNTo1MTo0MV0gQU1ELVZpOiBSZS1hc3NpZ24gMDAwMDowYTowMC42IGZy
b20gZG9tMCB0byBkb20xNA0KKFhFTikgWzIwMTItMDktMDUgMTU6NTE6NDFdIEFNRC1WaTog
RGlzYWJsZTogZGV2aWNlIGlkID0gMHgwYTA3LCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9
IDMNCihYRU4pIFsyMDEyLTA5LTA1IDE1OjUxOjQxXSBBTUQtVmk6IFNldHVwIEkvTyBwYWdl
IHRhYmxlOiBkZXZpY2UgaWQgPSAweDBhMDcsIHJvb3QgdGFibGUgPSAweDFlMWZjMDAwMCwg
ZG9tYWluID0gMTQsIHBhZ2luZyBtb2RlID0gMw0KKFhFTikgWzIwMTItMDktMDUgMTU6NTE6
NDFdIEFNRC1WaTogUmUtYXNzaWduIDAwMDA6MGE6MDAuNyBmcm9tIGRvbTAgdG8gZG9tMTQN
CihYRU4pIFsyMDEyLTA5LTA1IDE1OjUxOjQxXSBBTUQtVmk6IERpc2FibGU6IGRldmljZSBp
ZCA9IDB4MDcwMCwgZG9tYWluID0gMCwgcGFnaW5nIG1vZGUgPSAzDQooWEVOKSBbMjAxMi0w
OS0wNSAxNTo1MTo0MV0gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlk
ID0gMHgwNzAwLCByb290IHRhYmxlID0gMHgxZTFmYzAwMDAsIGRvbWFpbiA9IDE0LCBwYWdp
bmcgbW9kZSA9IDMNCihYRU4pIFsyMDEyLTA5LTA1IDE1OjUxOjQxXSBBTUQtVmk6IFJlLWFz
c2lnbiAwMDAwOjA3OjAwLjAgZnJvbSBkb20wIHRvIGRvbTE0DQooWEVOKSBbMjAxMi0wOS0w
NSAxNTo1MTo0MV0gdHJhcHMuYzoyNTg0OmQxNCBEb21haW4gYXR0ZW1wdGVkIFdSTVNSIDAw
MDAwMDAwYzAwMTAwMDQgZnJvbSAweDAwMDA0MjM0NWEwZGE1NDUgdG8gMHgwMDAwMDAwMDAw
MDBhYmNkLg0KKFhFTikgWzIwMTItMDktMDUgMTU6NTE6NTZdIEhWTTE1OiBIVk0gTG9hZGVy
DQooWEVOKSBbMjAxMi0wOS0wNSAxNTo1MTo1Nl0gSFZNMTU6IERldGVjdGVkIFhlbiB2NC4y
LjAtcmM0LXByZQ0KKFhFTikgWzIwMTItMDktMDUgMTU6NTE6NTZdIEhWTTE1OiBYZW5idXMg
cmluZ3MgQDB4ZmVmZmMwMDAsIGV2ZW50IGNoYW5uZWwgNA0KKFhFTikgWzIwMTItMDktMDUg
MTU6NTE6NTZdIEhWTTE1OiBTeXN0ZW0gcmVxdWVzdGVkIFJPTUJJT1MNCihYRU4pIFsyMDEy
LTA5LTA1IDE1OjUxOjU2XSBIVk0xNTogQ1BVIHNwZWVkIGlzIDMyMDAgTUh6DQooWEVOKSBb
MjAxMi0wOS0wNSAxNTo1MTo1Nl0gaXJxLmM6MjcwOiBEb20xNSBQQ0kgbGluayAwIGNoYW5n
ZWQgMCAtPiA1DQooWEVOKSBbMjAxMi0wOS0wNSAxNTo1MTo1Nl0gSFZNMTU6IFBDSS1JU0Eg
bGluayAwIHJvdXRlZCB0byBJUlE1DQooWEVOKSBbMjAxMi0wOS0wNSAxNTo1MTo1Nl0gaXJx
LmM6MjcwOiBEb20xNSBQQ0kgbGluayAxIGNoYW5nZWQgMCAtPiAxMA0KKFhFTikgWzIwMTIt
MDktMDUgMTU6NTE6NTZdIEhWTTE1OiBQQ0ktSVNBIGxpbmsgMSByb3V0ZWQgdG8gSVJRMTAN
CihYRU4pIFsyMDEyLTA5LTA1IDE1OjUxOjU2XSBpcnEuYzoyNzA6IERvbTE1IFBDSSBsaW5r
IDIgY2hhbmdlZCAwIC0+IDExDQooWEVOKSBbMjAxMi0wOS0wNSAxNTo1MTo1Nl0gSFZNMTU6
IFBDSS1JU0EgbGluayAyIHJvdXRlZCB0byBJUlExMQ0KKFhFTikgWzIwMTItMDktMDUgMTU6
NTE6NTZdIGlycS5jOjI3MDogRG9tMTUgUENJIGxpbmsgMyBjaGFuZ2VkIDAgLT4gNQ0KKFhF
TikgWzIwMTItMDktMDUgMTU6NTE6NTZdIEhWTTE1OiBQQ0ktSVNBIGxpbmsgMyByb3V0ZWQg
dG8gSVJRNQ0KKFhFTikgWzIwMTItMDktMDUgMTU6NTE6NTZdIEhWTTE1OiBwY2kgZGV2IDAx
OjIgSU5URC0+SVJRNQ0KKFhFTikgWzIwMTItMDktMDUgMTU6NTE6NTZdIEhWTTE1OiBwY2kg
ZGV2IDAxOjMgSU5UQS0+SVJRMTANCihYRU4pIFsyMDEyLTA5LTA1IDE1OjUxOjU2XSBIVk0x
NTogcGNpIGRldiAwMzowIElOVEEtPklSUTUNCihYRU4pIFsyMDEyLTA5LTA1IDE1OjUxOjU2
XSBIVk0xNTogcGNpIGRldiAwNDowIElOVEEtPklSUTUNCihYRU4pIFsyMDEyLTA5LTA1IDE1
OjUxOjU2XSBIVk0xNTogcGNpIGRldiAwMjowIGJhciAxMCBzaXplIDAyMDAwMDAwOiBmMDAw
MDAwOA0KKFhFTikgWzIwMTItMDktMDUgMTU6NTE6NTZdIEhWTTE1OiBwY2kgZGV2IDAzOjAg
YmFyIDE0IHNpemUgMDEwMDAwMDA6IGYyMDAwMDA4DQooWEVOKSBbMjAxMi0wOS0wNSAxNTo1
MTo1Nl0gSFZNMTU6IHBjaSBkZXYgMDQ6MCBiYXIgMTAgc2l6ZSAwMDAyMDAwMDogZjMwMDAw
MDANCihYRU4pIFsyMDEyLTA5LTA1IDE1OjUxOjU2XSBIVk0xNTogcGNpIGRldiAwMjowIGJh
ciAxNCBzaXplIDAwMDAxMDAwOiBmMzAyMDAwMA0KKFhFTikgWzIwMTItMDktMDUgMTU6NTE6
NTZdIEhWTTE1OiBwY2kgZGV2IDAzOjAgYmFyIDEwIHNpemUgMDAwMDAxMDA6IDAwMDBjMDAx
DQooWEVOKSBbMjAxMi0wOS0wNSAxNTo1MTo1Nl0gSFZNMTU6IHBjaSBkZXYgMDQ6MCBiYXIg
MTQgc2l6ZSAwMDAwMDA0MDogMDAwMGMxMDENCihYRU4pIFsyMDEyLTA5LTA1IDE1OjUxOjU2
XSBIVk0xNTogcGNpIGRldiAwMToyIGJhciAyMCBzaXplIDAwMDAwMDIwOiAwMDAwYzE0MQ0K
KFhFTikgWzIwMTItMDktMDUgMTU6NTE6NTZdIEhWTTE1OiBwY2kgZGV2IDAxOjEgYmFyIDIw
IHNpemUgMDAwMDAwMTA6IDAwMDBjMTYxDQooWEVOKSBbMjAxMi0wOS0wNSAxNTo1MTo1Nl0g
SFZNMTU6IE11bHRpcHJvY2Vzc29yIGluaXRpYWxpc2F0aW9uOg0KKFhFTikgWzIwMTItMDkt
MDUgMTU6NTE6NTZdIEhWTTE1OiAgLSBDUFUwIC4uLiA0OC1iaXQgcGh5cyAuLi4gZml4ZWQg
TVRSUnMgLi4uIHZhciBNVFJScyBbMi84XSAuLi4gZG9uZS4NCihYRU4pIFsyMDEyLTA5LTA1
IDE1OjUxOjU2XSBIVk0xNTogIC0gQ1BVMSAuLi4gNDgtYml0IHBoeXMgLi4uIGZpeGVkIE1U
UlJzIC4uLiB2YXIgTVRSUnMgWzIvOF0gLi4uIGRvbmUuDQooWEVOKSBbMjAxMi0wOS0wNSAx
NTo1MTo1Nl0gSFZNMTU6IFRlc3RpbmcgSFZNIGVudmlyb25tZW50Og0KKFhFTikgWzIwMTIt
MDktMDUgMTU6NTE6NTZdIEhWTTE1OiAgLSBSRVAgSU5TQiBhY3Jvc3MgcGFnZSBib3VuZGFy
aWVzIC4uLiBwYXNzZWQNCihYRU4pIFsyMDEyLTA5LTA1IDE1OjUxOjU2XSBIVk0xNTogIC0g
R1MgYmFzZSBNU1JzIGFuZCBTV0FQR1MgLi4uIHBhc3NlZA0KKFhFTikgWzIwMTItMDktMDUg
MTU6NTE6NTZdIEhWTTE1OiBQYXNzZWQgMiBvZiAyIHRlc3RzDQooWEVOKSBbMjAxMi0wOS0w
NSAxNTo1MTo1Nl0gSFZNMTU6IFdyaXRpbmcgU01CSU9TIHRhYmxlcyAuLi4NCihYRU4pIFsy
MDEyLTA5LTA1IDE1OjUxOjU2XSBIVk0xNTogTG9hZGluZyBST01CSU9TIC4uLg0KKFhFTikg
WzIwMTItMDktMDUgMTU6NTE6NTZdIEhWTTE1OiA5NjYwIGJ5dGVzIG9mIFJPTUJJT1MgaGln
aC1tZW1vcnkgZXh0ZW5zaW9uczoNCihYRU4pIFsyMDEyLTA5LTA1IDE1OjUxOjU2XSBIVk0x
NTogICBSZWxvY2F0aW5nIHRvIDB4ZmMwMDEwMDAtMHhmYzAwMzViYyAuLi4gZG9uZQ0KKFhF
TikgWzIwMTItMDktMDUgMTU6NTE6NTZdIEhWTTE1OiBDcmVhdGluZyBNUCB0YWJsZXMgLi4u
DQooWEVOKSBbMjAxMi0wOS0wNSAxNTo1MTo1Nl0gSFZNMTU6IExvYWRpbmcgQ2lycnVzIFZH
QUJJT1MgLi4uDQooWEVOKSBbMjAxMi0wOS0wNSAxNTo1MTo1Nl0gSFZNMTU6IExvYWRpbmcg
UENJIE9wdGlvbiBST00gLi4uDQooWEVOKSBbMjAxMi0wOS0wNSAxNTo1MTo1Nl0gSFZNMTU6
ICAtIE1hbnVmYWN0dXJlcjogaHR0cDovL2lweGUub3JnDQooWEVOKSBbMjAxMi0wOS0wNSAx
NTo1MTo1Nl0gSFZNMTU6ICAtIFByb2R1Y3QgbmFtZTogaVBYRQ0KKFhFTikgWzIwMTItMDkt
MDUgMTU6NTE6NTZdIEhWTTE1OiBPcHRpb24gUk9NczoNCihYRU4pIFsyMDEyLTA5LTA1IDE1
OjUxOjU2XSBIVk0xNTogIGMwMDAwLWM4ZmZmOiBWR0EgQklPUw0KKFhFTikgWzIwMTItMDkt
MDUgMTU6NTE6NTZdIEhWTTE1OiAgYzkwMDAtZDlmZmY6IEV0aGVyYm9vdCBST00NCihYRU4p
IFsyMDEyLTA5LTA1IDE1OjUxOjU2XSBIVk0xNTogTG9hZGluZyBBQ1BJIC4uLg0KKFhFTikg
WzIwMTItMDktMDUgMTU6NTE6NTZdIEhWTTE1OiB2bTg2IFRTUyBhdCBmYzAwZjY4MA0KKFhF
TikgWzIwMTItMDktMDUgMTU6NTE6NTZdIEhWTTE1OiBCSU9TIG1hcDoNCihYRU4pIFsyMDEy
LTA5LTA1IDE1OjUxOjU2XSBIVk0xNTogIGYwMDAwLWZmZmZmOiBNYWluIEJJT1MNCihYRU4p
IFsyMDEyLTA5LTA1IDE1OjUxOjU2XSBIVk0xNTogRTgyMCB0YWJsZToNCihYRU4pIFsyMDEy
LTA5LTA1IDE1OjUxOjU2XSBIVk0xNTogIFswMF06IDAwMDAwMDAwOjAwMDAwMDAwIC0gMDAw
MDAwMDA6MDAwOWUwMDA6IFJBTQ0KKFhFTikgWzIwMTItMDktMDUgMTU6NTE6NTZdIEhWTTE1
OiAgWzAxXTogMDAwMDAwMDA6MDAwOWUwMDAgLSAwMDAwMDAwMDowMDBhMDAwMDogUkVTRVJW
RUQNCihYRU4pIFsyMDEyLTA5LTA1IDE1OjUxOjU2XSBIVk0xNTogIEhPTEU6IDAwMDAwMDAw
OjAwMGEwMDAwIC0gMDAwMDAwMDA6MDAwZTAwMDANCihYRU4pIFsyMDEyLTA5LTA1IDE1OjUx
OjU2XSBIVk0xNTogIFswMl06IDAwMDAwMDAwOjAwMGUwMDAwIC0gMDAwMDAwMDA6MDAxMDAw
MDA6IFJFU0VSVkVEDQooWEVOKSBbMjAxMi0wOS0wNSAxNTo1MTo1Nl0gSFZNMTU6ICBbMDNd
OiAwMDAwMDAwMDowMDEwMDAwMCAtIDAwMDAwMDAwOjFmODAwMDAwOiBSQU0NCihYRU4pIFsy
MDEyLTA5LTA1IDE1OjUxOjU2XSBIVk0xNTogIEhPTEU6IDAwMDAwMDAwOjFmODAwMDAwIC0g
MDAwMDAwMDA6ZmMwMDAwMDANCihYRU4pIFsyMDEyLTA5LTA1IDE1OjUxOjU2XSBIVk0xNTog
IFswNF06IDAwMDAwMDAwOmZjMDAwMDAwIC0gMDAwMDAwMDE6MDAwMDAwMDA6IFJFU0VSVkVE
DQooWEVOKSBbMjAxMi0wOS0wNSAxNTo1MTo1Nl0gSFZNMTU6IEludm9raW5nIFJPTUJJT1Mg
Li4uDQooWEVOKSBbMjAxMi0wOS0wNSAxNTo1MTo1Nl0gSFZNMTU6ICRSZXZpc2lvbjogMS4y
MjEgJCAkRGF0ZTogMjAwOC8xMi8wNyAxNzozMjoyOSAkDQooWEVOKSBbMjAxMi0wOS0wNSAx
NTo1MTo1N10gc3RkdmdhLmM6MTQ3OmQxNSBlbnRlcmluZyBzdGR2Z2EgYW5kIGNhY2hpbmcg
bW9kZXMNCihYRU4pIFsyMDEyLTA5LTA1IDE1OjUxOjU3XSBIVk0xNTogVkdBQmlvcyAkSWQ6
IHZnYWJpb3MuYyx2IDEuNjcgMjAwOC8wMS8yNyAwOTo0NDoxMiB2cnVwcGVydCBFeHAgJA0K
KFhFTikgWzIwMTItMDktMDUgMTU6NTE6NTddIEhWTTE1OiBCb2NocyBCSU9TIC0gYnVpbGQ6
IDA2LzIzLzk5DQooWEVOKSBbMjAxMi0wOS0wNSAxNTo1MTo1N10gSFZNMTU6ICRSZXZpc2lv
bjogMS4yMjEgJCAkRGF0ZTogMjAwOC8xMi8wNyAxNzozMjoyOSAkDQooWEVOKSBbMjAxMi0w
OS0wNSAxNTo1MTo1N10gSFZNMTU6IE9wdGlvbnM6IGFwbWJpb3MgcGNpYmlvcyBlbHRvcml0
byBQTU0gDQooWEVOKSBbMjAxMi0wOS0wNSAxNTo1MTo1N10gSFZNMTU6IA0KKFhFTikgWzIw
MTItMDktMDUgMTU6NTE6NTddIEhWTTE1OiBhdGEwLTA6IFBDSFM9MTYzODMvMTYvNjMgdHJh
bnNsYXRpb249bGJhIExDSFM9MTAyNC8yNTUvNjMNCihYRU4pIFsyMDEyLTA5LTA1IDE1OjUx
OjU3XSBIVk0xNTogYXRhMCBtYXN0ZXI6IFFFTVUgSEFSRERJU0sgQVRBLTcgSGFyZC1EaXNr
ICg1NzI0NCBNQnl0ZXMpDQooWEVOKSBbMjAxMi0wOS0wNSAxNTo1MTo1OF0gSFZNMTU6IElE
RSB0aW1lIG91dA0KKFhFTikgWzIwMTItMDktMDUgMTU6NTE6NThdIEhWTTE1OiBhdGExIG1h
c3RlcjogUUVNVSBEVkQtUk9NIEFUQVBJLTQgQ0QtUm9tL0RWRC1Sb20NCihYRU4pIFsyMDEy
LTA5LTA1IDE1OjUyOjAwXSBIVk0xNTogSURFIHRpbWUgb3V0DQooWEVOKSBbMjAxMi0wOS0w
NSAxNTo1MjowMF0gSFZNMTU6IA0KKFhFTikgWzIwMTItMDktMDUgMTU6NTI6MDBdIEhWTTE1
OiANCihYRU4pIFsyMDEyLTA5LTA1IDE1OjUyOjAwXSBIVk0xNTogDQooWEVOKSBbMjAxMi0w
OS0wNSAxNTo1MjowMF0gSFZNMTU6IFByZXNzIEYxMiBmb3IgYm9vdCBtZW51Lg0KKFhFTikg
WzIwMTItMDktMDUgMTU6NTI6MDBdIEhWTTE1OiANCihYRU4pIFsyMDEyLTA5LTA1IDE1OjUy
OjAwXSBIVk0xNTogQm9vdGluZyBmcm9tIEhhcmQgRGlzay4uLg0KKFhFTikgWzIwMTItMDkt
MDUgMTU6NTI6MDBdIEhWTTE1OiBCb290aW5nIGZyb20gMDAwMDo3YzAwDQooWEVOKSBbMjAx
Mi0wOS0wNSAxNTo1MjowNF0gdHJhcHMuYzoyNTg0OmQxNiBEb21haW4gYXR0ZW1wdGVkIFdS
TVNSIDAwMDAwMDAwYzAwMTAwMDQgZnJvbSAweDAwMDA4Njc5YzAyYjQxNjUgdG8gMHgwMDAw
MDAwMDAwMDBhYmNkLg0KKFhFTikgWzIwMTItMDktMDUgMTU6NTI6MjddIHRyYXBzLmM6MzE1
NjogR1BGICgwMDYwKTogZmZmZjgyYzQ4MDE1YzlmZSAtPiBmZmZmODJjNDgwMjI0YjgzDQoo
WEVOKSBbMjAxMi0wOS0wNSAxNTo1MjoyN10gdHJhcHMuYzozMTU3OiAgc2hvd19leGVjdXRp
b25fc3RhdGUocmVncyk6IA0KKFhFTikgWzIwMTItMDktMDUgMTU6NTI6MjddIC0tLS1bIFhl
bi00LjIuMC1yYzQtcHJlICB4ODZfNjQgIGRlYnVnPXkgIE5vdCB0YWludGVkIF0tLS0tDQoo
WEVOKSBbMjAxMi0wOS0wNSAxNTo1MjoyN10gQ1BVOiAgICAyDQooWEVOKSBbMjAxMi0wOS0w
NSAxNTo1MjoyN10gUklQOiAgICBlMDA4Ols8ZmZmZjgyYzQ4MDE1YzlmZT5dIGNvbnRleHRf
c3dpdGNoKzB4Mzk0LzB4ZWViDQooWEVOKSBbMjAxMi0wOS0wNSAxNTo1MjoyN10gUkZMQUdT
OiAwMDAwMDAwMDAwMDEwMjQ2ICAgQ09OVEVYVDogaHlwZXJ2aXNvcg0KKFhFTikgWzIwMTIt
MDktMDUgMTU6NTI6MjddIHJheDogMDAwMDAwMDAwMDAwMDAwMSAgIHJieDogZmZmZjgzMDBh
NTJkOTAwMCAgIHJjeDogMDAwMDAwMDAwMDAwMDAwMQ0KKFhFTikgWzIwMTItMDktMDUgMTU6
NTI6MjddIHJkeDogMDAwMDAwMDAwMDAwMDA2MyAgIHJzaTogMDAwMDAwMDAwMDAwMDAwMSAg
IHJkaTogMDAwMDAwMDAwMDAwMDE3MQ0KKFhFTikgWzIwMTItMDktMDUgMTU6NTI6MjddIHJi
cDogZmZmZjgzMDI0ZDhiN2UyOCAgIHJzcDogZmZmZjgzMDI0ZDhiN2Q4OCAgIHI4OiAgMDAw
MDAwMDAwMDAwMDAwNg0KKFhFTikgWzIwMTItMDktMDUgMTU6NTI6MjddIHI5OiAgZmZmZjgz
MDBhZmQwNzA2MCAgIHIxMDogMDAwMDAwMDBkZWFkYmVlZiAgIHIxMTogMDAwMDAwMDAwMDAw
MDI0Ng0KKFhFTikgWzIwMTItMDktMDUgMTU6NTI6MjddIHIxMjogZmZmZjgzMDBhZmQwNzAw
MCAgIHIxMzogMDAwMDAwMDAwMDAwMDAwMiAgIHIxNDogMDAwMDAwMDAwMDAwMDAwMg0KKFhF
TikgWzIwMTItMDktMDUgMTU6NTI6MjddIHIxNTogZmZmZjgzMDI0ZDk1MDA0OCAgIGNyMDog
MDAwMDAwMDA4MDA1MDAzYiAgIGNyNDogMDAwMDAwMDAwMDAwMDZmMA0KKFhFTikgWzIwMTIt
MDktMDUgMTU6NTI6MjddIGNyMzogMDAwMDAwMDA2ODQ1YzAwMCAgIGNyMjogMDAwMDAwMDBm
NzYwYzg4Zg0KKFhFTikgWzIwMTItMDktMDUgMTU6NTI6MjddIGRzOiAwMDAwICAgZXM6IDAw
MDAgICBmczogMDAwMCAgIGdzOiAwMDAwICAgc3M6IGUwMTAgICBjczogZTAwOA0KKFhFTikg
WzIwMTItMDktMDUgMTU6NTI6MjddIFhlbiBzdGFjayB0cmFjZSBmcm9tIHJzcD1mZmZmODMw
MjRkOGI3ZDg4Og0KKFhFTikgWzIwMTItMDktMDUgMTU6NTI6MjddICAgIGZmZmY4MzAyNGQ4
YjdlZjggZmZmZjgyYzQ4MDEwZWQ3YiAwMDAwMDAxZTY1NzU1MDc4IDAwMDAwMDAwNjViNTEw
MDANCihYRU4pIFsyMDEyLTA5LTA1IDE1OjUyOjI3XSAgICBmZmZmODMwMDY1YjUxMDYwIGZm
ZmY4MzAyNGQ5NTAwNjAgZmZmZjgzMDI0ZDhiN2UxOCBmZmZmODJjNDgwMTgwNWJlDQooWEVO
KSBbMjAxMi0wOS0wNSAxNTo1MjoyN10gICAgMDAwMDAwMDAwMDAwMDBiNCAwMDAwMDBhZWY3
NDYyOWQwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMA0KKFhFTikgWzIwMTIt
MDktMDUgMTU6NTI6MjddICAgIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCBm
ZmZmODMwMjRkOGI3ZTI4IGZmZmY4MzAwYWZkMDcwMDANCihYRU4pIFsyMDEyLTA5LTA1IDE1
OjUyOjI3XSAgICBmZmZmODMwMGE1MmQ5MDAwIDAwMDAwMDJlNTQwZTUyNDUgMDAwMDAwMDAw
MDAwMDAwMiBmZmZmODMwMjRkOTUwMDQ4DQooWEVOKSBbMjAxMi0wOS0wNSAxNTo1MjoyN10g
ICAgZmZmZjgzMDI0ZDhiN2ViOCBmZmZmODJjNDgwMTI0YTcwIDAwZmY4MzAyNGQ4YjdlODgg
ZmZmZjgzMDI0ZDk1MDA0MA0KKFhFTikgWzIwMTItMDktMDUgMTU6NTI6MjddICAgIDAwMDAw
MDAyNTc3MWFhMjcgMDAwMDAwMmU1NDBlNTI0NSBmZmZmODMwMjRkOGI3ZTg4IGZmZmZmZmZm
ZmZmZmZmYzINCihYRU4pIFsyMDEyLTA5LTA1IDE1OjUyOjI3XSAgICBmZmZmODMwMGE1MmQ5
MDAwIDAwMDAwMDAwMDFjOWMzODAgZmZmZjgzMDI0ZDhiN2UwMCBmZmZmODJjNDgwMTIyNmNl
DQooWEVOKSBbMjAxMi0wOS0wNSAxNTo1MjoyN10gICAgZmZmZjgzMDI0ZDhiN2VmOCBmZmZm
ODJjNDgwMmQ4MTAwIDAwMDAwMDAwZmZmZmZmZmYgZmZmZjgyYzQ4MDJkODAwMA0KKFhFTikg
WzIwMTItMDktMDUgMTU6NTI6MjddICAgIGZmZmY4MzAyNGQ4YjdmMTggZmZmZmZmZmZmZmZm
ZmZmZiBmZmZmODMwMjRkOGI3ZWY4IGZmZmY4MmM0ODAxMjVlMzENCihYRU4pIFsyMDEyLTA5
LTA1IDE1OjUyOjI3XSAgICAwMDAwMDAwMDAwMDAwMjQ2IGZmZmY4MzAwYWZkMDcwMDAgZmZm
ZmZmZmY4MWVjZTVkOCAwMDAwMDAwMDAwMDAwMDAwDQooWEVOKSBbMjAxMi0wOS0wNSAxNTo1
MjoyN10gICAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIGZmZmY4MzAyNGQ4
YjdmMDggZmZmZjgyYzQ4MDEyNWU2OA0KKFhFTikgWzIwMTItMDktMDUgMTU6NTI6MjddICAg
IDAwMDA3Y2ZkYjI3NDgwYzcgZmZmZjgyYzQ4MDIyMmYwNiAwMDAwMDAwMDAwMDAwMDAwIGZm
ZmZmZmZmODFlMTM4ODANCihYRU4pIFsyMDEyLTA5LTA1IDE1OjUyOjI3XSAgICAwMDAwMDAw
MDAwMDAwMDAwIGZmZmY4ODAwMWUwYjAwZDggZmZmZmZmZmY4MWUwMWNlOCBmZmZmODgwMDFm
YzBiMTAwDQooWEVOKSBbMjAxMi0wOS0wNSAxNTo1MjoyN10gICAgMDAwMDAwMDAwMDAwMDIw
MiAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMA0K
KFhFTikgWzIwMTItMDktMDUgMTU6NTI6MjddICAgIDAwMDAwMDAwMDAwMDAwMDAgZmZmZmZm
ZmY4MTAwMTFhYSBmZmZmODgwMDFlYWQzMGMwIDAwMDAwMDAwZGVhZGJlZWYNCihYRU4pIFsy
MDEyLTA5LTA1IDE1OjUyOjI3XSAgICAwMDAwMDAwMGRlYWRiZWVmIDAwMDAwMTAwMDAwMDAw
MDAgZmZmZmZmZmY4MTAwMTFhYSAwMDAwMDAwMDAwMDBlMDMzDQooWEVOKSBbMjAxMi0wOS0w
NSAxNTo1MjoyN10gICAgMDAwMDAwMDAwMDAwMDIwMiBmZmZmZmZmZjgxZTAxY2IwIDAwMDAw
MDAwMDAwMGUwMmIgMDAwMDViZmQwMDAwYmVlZg0KKFhFTikgWzIwMTItMDktMDUgMTU6NTI6
MjddICAgIDgwMDAwMDAwMDAwMGJlZWYgNzQwMDAwMDAwMDAwYmVlZiAwMDAwMDAwMDAwMThi
ZWVmIDAwMDA1YmZlMDAwMDAwMDINCihYRU4pIFsyMDEyLTA5LTA1IDE1OjUyOjI3XSAgICBm
ZmZmODMwMGE1MmQ5MDAwIDAwMDAwMDNkY2Q2NGU2ODAgMDAwMDAwMDAwMDE4ZTBjOQ0KKFhF
TikgWzIwMTItMDktMDUgMTU6NTI6MjddIFhlbiBjYWxsIHRyYWNlOg0KKFhFTikgWzIwMTIt
MDktMDUgMTU6NTI6MjddICAgIFs8ZmZmZjgyYzQ4MDE1YzlmZT5dIGNvbnRleHRfc3dpdGNo
KzB4Mzk0LzB4ZWViDQooWEVOKSBbMjAxMi0wOS0wNSAxNTo1MjoyN10gICAgWzxmZmZmODJj
NDgwMTI0YTcwPl0gc2NoZWR1bGUrMHg2NjYvMHg2NzUNCihYRU4pIFsyMDEyLTA5LTA1IDE1
OjUyOjI3XSAgICBbPGZmZmY4MmM0ODAxMjVlMzE+XSBfX2RvX3NvZnRpcnErMHhhNC8weGI1
DQooWEVOKSBbMjAxMi0wOS0wNSAxNTo1MjoyN10gICAgWzxmZmZmODJjNDgwMTI1ZTY4Pl0g
ZG9fc29mdGlycSsweDI2LzB4MjgNCihYRU4pIFsyMDEyLTA5LTA1IDE1OjUyOjI3XSAgICAN
CihYRU4pIFsyMDEyLTA5LTA1IDE1OjUyOjI3XSB0cmFwcy5jOjMxNTk6ICAgc2hvd19leGVj
dXRpb25fc3RhdGUoZ3Vlc3RfY3B1X3VzZXJfcmVncygpKTogDQooWEVOKSBbMjAxMi0wOS0w
NSAxNTo1MjoyN10gLS0tLVsgWGVuLTQuMi4wLXJjNC1wcmUgIHg4Nl82NCAgZGVidWc9eSAg
Tm90IHRhaW50ZWQgXS0tLS0NCihYRU4pIFsyMDEyLTA5LTA1IDE1OjUyOjI3XSBDUFU6ICAg
IDINCihYRU4pIFsyMDEyLTA5LTA1IDE1OjUyOjI3XSBSSVA6ICAgIGUwMzM6WzxmZmZmZmZm
ZjgxMDAxMWFhPl0NCihYRU4pIFsyMDEyLTA5LTA1IDE1OjUyOjI3XSBSRkxBR1M6IDAwMDAw
MDAwMDAwMDAyMDIgICBFTTogMSAgIENPTlRFWFQ6IHB2IGd1ZXN0DQooWEVOKSBbMjAxMi0w
OS0wNSAxNTo1MjoyN10gcmF4OiAwMDAwMDAwMDAwMDAwMDAwICAgcmJ4OiBmZmZmODgwMDFm
YzBiMTAwICAgcmN4OiBmZmZmZmZmZjgxMDAxMWFhDQooWEVOKSBbMjAxMi0wOS0wNSAxNTo1
MjoyN10gcmR4OiBmZmZmODgwMDFlYWQzMGMwICAgcnNpOiAwMDAwMDAwMGRlYWRiZWVmICAg
cmRpOiAwMDAwMDAwMGRlYWRiZWVmDQooWEVOKSBbMjAxMi0wOS0wNSAxNTo1MjoyN10gcmJw
OiBmZmZmZmZmZjgxZTAxY2U4ICAgcnNwOiBmZmZmZmZmZjgxZTAxY2IwICAgcjg6ICAwMDAw
MDAwMDAwMDAwMDAwDQooWEVOKSBbMjAxMi0wOS0wNSAxNTo1MjoyN10gcjk6ICAwMDAwMDAw
MDAwMDAwMDAwICAgcjEwOiAwMDAwMDAwMDAwMDAwMDAwICAgcjExOiAwMDAwMDAwMDAwMDAw
MjAyDQooWEVOKSBbMjAxMi0wOS0wNSAxNTo1MjoyN10gcjEyOiBmZmZmODgwMDFlMGIwMGQ4
ICAgcjEzOiAwMDAwMDAwMDAwMDAwMDAwICAgcjE0OiBmZmZmZmZmZjgxZTEzODgwDQooWEVO
KSBbMjAxMi0wOS0wNSAxNTo1MjoyN10gcjE1OiAwMDAwMDAwMDAwMDAwMDAwICAgY3IwOiAw
MDAwMDAwMDgwMDUwMDNiICAgY3I0OiAwMDAwMDAwMDAwMDAwNmYwDQooWEVOKSBbMjAxMi0w
OS0wNSAxNTo1MjoyN10gY3IzOiAwMDAwMDAwMDY4NDVjMDAwICAgY3IyOiAwMDAwMDAwMGY3
NjBjODhmDQooWEVOKSBbMjAxMi0wOS0wNSAxNTo1MjoyN10gZHM6IDAwMDAgICBlczogMDAw
MCAgIGZzOiAwMDAwICAgZ3M6IDAwMDAgICBzczogZTAyYiAgIGNzOiBlMDMzDQooWEVOKSBb
MjAxMi0wOS0wNSAxNTo1MjoyN10gR3Vlc3Qgc3RhY2sgdHJhY2UgZnJvbSByc3A9ZmZmZmZm
ZmY4MWUwMWNiMDoNCihYRU4pIFsyMDEyLTA5LTA1IDE1OjUyOjI3XSAgICAwMDAwMDAwMDAw
MDAwMDAwIDAwMDAwMDAwMDAwMDAwMDEgZmZmZmZmZmY4MTAwNDk0MiBmZmZmZmZmZjgxZTEz
NDIwDQooWEVOKSBbMjAxMi0wOS0wNSAxNTo1MjoyN10gICAgZmZmZjg4MDAxZWFkMzBjMCAw
MDAwMDAwMDAwMDAwMDAwIGZmZmZmZmZmODFlMTM4ODAgZmZmZmZmZmY4MWUwMWQwOA0KKFhF
TikgWzIwMTItMDktMDUgMTU6NTI6MjddICAgIGZmZmZmZmZmODEwMDM5NDEgZmZmZjg4MDAx
ZWFkMzBjMCBmZmZmZmZmZjgxZTEzNDIwIGZmZmZmZmZmODFlMDFkNjgNCihYRU4pIFsyMDEy
LTA5LTA1IDE1OjUyOjI3XSAgICBmZmZmZmZmZjgxMDBiODUwIGZmZmZmZmZmODFlMTM0MjAg
MDAwMDAwMDAwMDAwMDAwMSAwMDAwMDAwMDAwMDAwMDYzDQooWEVOKSBbMjAxMi0wOS0wNSAx
NTo1MjoyN10gICAgZmZmZjg4MDAxZmMxMGE4MCBmZmZmZmZmZjgxZTAxZDc4IGZmZmY4ODAw
MWZjMTJlODAgMDAwMDAwMDAwMDAwMDAwMA0KKFhFTikgWzIwMTItMDktMDUgMTU6NTI6Mjdd
ICAgIGZmZmY4ODAwMWNjZDY4ODAgMDAwMDAwMDAwMDAwMDA4MiBmZmZmZmZmZjgxMGYwMDQw
IGZmZmZmZmZmODFlMTM0MjANCihYRU4pIFsyMDEyLTA5LTA1IDE1OjUyOjI3XSAgICBmZmZm
ZmZmZjgxN2ZhMmY1IGZmZmZmZmZmODFlMDFlYzggMDAwMDAwMDAwMDAwMDIxNiBmZmZmODgw
MDFmYzBlNjk4DQooWEVOKSBbMjAxMi0wOS0wNSAxNTo1MjoyN10gICAgMDAwMDAwMDAwMDAw
MDAwMSBmZmZmZmZmZjgxZTEzNDIwIDAwMDAwMDAwMDAwMTJlODAgZmZmZmZmZmY4MWUwMWZk
OA0KKFhFTikgWzIwMTItMDktMDUgMTU6NTI6MjddICAgIGZmZmZmZmZmODFlMDAwMTAgMDAw
MDAwMDAwMDAxMmU4MCAwMDAwMDAwMDAwMDEyZTgwIGZmZmZmZmZmODFlMDFmZDgNCihYRU4p
IFsyMDEyLTA5LTA1IDE1OjUyOjI3XSAgICAwMDAwMDAwMDAwMDEyZTgwIGZmZmY4ODAwMWVh
ZDIwODAgZmZmZmZmZmY4MWUxMzQyMCBmZmZmODgwMDFmYzBlOGEwDQooWEVOKSBbMjAxMi0w
OS0wNSAxNTo1MjoyN10gICAgMDAwMDAwMDAwMDAwMDAwMCBmZmZmZmZmZjgxZTAxZTk4IGZm
ZmZmZmZmODEwOGIzODEgMDAwMDAwMDAwMDAwMDAwMQ0KKFhFTikgWzIwMTItMDktMDUgMTU6
NTI6MjddICAgIGZmZmZmZmZmODEwYWIyMjEgMDAwMDAwMDE4MWUwMWUyOCAwMDAwMDAwMDAw
MDAwMDAwIDAwMDAwMDAwODFlMDFlNDgNCihYRU4pIFsyMDEyLTA5LTA1IDE1OjUyOjI3XSAg
ICAwMDAwMDAwMDAwMDAwMDcwIDAwMDAwMDAwMWZjMGU4YTAgMDAwMDAwMDAwMDAwZTY4MCAw
MDAwMDAwMDAwMDAwMDAwDQooWEVOKSBbMjAxMi0wOS0wNSAxNTo1MjoyN10gICAgZmZmZmZm
ZmY4MWUxMzQyMCBmZmZmZmZmZjgxMGE4NmZjIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAw
MDAwMDAwMA0KKFhFTikgWzIwMTItMDktMDUgMTU6NTI6MjddICAgIDAwMDAwMDAwMDAwMDAw
MDAgZmZmZmZmZmY4MWUwMWU5OCBmZmZmZmZmZjgxMGFjYjc4IGZmZmY4ODAwMWZjMGU4YTAN
CihYRU4pIFsyMDEyLTA5LTA1IDE1OjUyOjI3XSAgICAwMDAwMDAwNTczOWQwNWQ5IGZmZmZm
ZmZmODFlMDFlYTggZmZmZmZmZmY4MWUwMDAxMCBmZmZmZmZmZjgxZWNlNWQ4DQooWEVOKSBb
MjAxMi0wOS0wNSAxNTo1MjoyN10gICAgZmZmZmZmZmY4MWY0MjBjMCAwMDAwMDAwMDAwMDAw
MDAwIDAwMDAwMDAwMDAwMDAwMDAgZmZmZmZmZmY4MWUwMWVkOA0KKFhFTikgWzIwMTItMDkt
MDUgMTU6NTI6MjddICAgIGZmZmZmZmZmODE3ZmE4MTQgZmZmZmZmZmY4MWUwMWVmOCBmZmZm
ZmZmZjgxMDE2NDU2IDAwMDAwMDAwMDAwMDAwMDINCihYRU4pIFsyMDEyLTA5LTA1IDE1OjUy
OjI3XSAgICBmZmZmZmZmZjgxZjM5OTIwIGZmZmZmZmZmODFlMDFmMjggZmZmZmZmZmY4MTdk
NWI4YyBmZmZmZmZmZjgxN2Q1YWQwDQooWEVOKSBbMjAxMi0wOS0wNSAxNTo1MjoyN10gICAg
ZmZmZjg4MDAwMDAwMTAwMCBmZmZmZmZmZjgxZTAxZjI4IDAwMDAwMDAwMDAwMDAwMDAgZmZm
ZmZmZmY4MWUwMWY3OA0KKFhFTikgWzIwMTItMDktMDUgMTU6NTI6MjhdIGlycS5jOjI3MDog
RG9tMTUgUENJIGxpbmsgMCBjaGFuZ2VkIDUgLT4gMA0KKFhFTikgWzIwMTItMDktMDUgMTU6
NTI6MjhdIGlycS5jOjI3MDogRG9tMTUgUENJIGxpbmsgMSBjaGFuZ2VkIDEwIC0+IDANCihY
RU4pIFsyMDEyLTA5LTA1IDE1OjUyOjI4XSBpcnEuYzoyNzA6IERvbTE1IFBDSSBsaW5rIDIg
Y2hhbmdlZCAxMSAtPiAwDQooWEVOKSBbMjAxMi0wOS0wNSAxNTo1MjoyOF0gaXJxLmM6Mjcw
OiBEb20xNSBQQ0kgbGluayAzIGNoYW5nZWQgNSAtPiAwDQooWEVOKSBbMjAxMi0wOS0wNSAx
NTo1MjoyOF0gaHZtLmM6MjQzNTpkMTUgZ3Vlc3QgYXR0ZW1wdGVkIHdyaXRlIHRvIHJlYWQt
b25seSBtZW1vcnkgcGFnZS4gZ2ZuPTB4ZGMsIG1mbj0weGE0YTBhDQooWEVOKSBbMjAxMi0w
OS0wNSAxNTo1MjoyOF0gaHZtLmM6MjQzNTpkMTUgZ3Vlc3QgYXR0ZW1wdGVkIHdyaXRlIHRv
IHJlYWQtb25seSBtZW1vcnkgcGFnZS4gZ2ZuPTB4ZGQsIG1mbj0weGE0YTA5DQooWEVOKSBb
MjAxMi0wOS0wNSAxNTo1MjoyOF0gaHZtLmM6MjQzNTpkMTUgZ3Vlc3QgYXR0ZW1wdGVkIHdy
aXRlIHRvIHJlYWQtb25seSBtZW1vcnkgcGFnZS4gZ2ZuPTB4ZGUsIG1mbj0weGE0YTA4DQoo
WEVOKSBbMjAxMi0wOS0wNSAxNTo1MjoyOF0gaHZtLmM6MjQzNTpkMTUgZ3Vlc3QgYXR0ZW1w
dGVkIHdyaXRlIHRvIHJlYWQtb25seSBtZW1vcnkgcGFnZS4gZ2ZuPTB4ZGQsIG1mbj0weGE0
YTA5DQooWEVOKSBbMjAxMi0wOS0wNSAxNTo1MjoyOF0gaHZtLmM6MjQzNTpkMTUgZ3Vlc3Qg
YXR0ZW1wdGVkIHdyaXRlIHRvIHJlYWQtb25seSBtZW1vcnkgcGFnZS4gZ2ZuPTB4ZGMsIG1m
bj0weGE0YTBhDQooWEVOKSBbMjAxMi0wOS0wNSAxNTo1MjoyOF0gaHZtLmM6MjQzNTpkMTUg
Z3Vlc3QgYXR0ZW1wdGVkIHdyaXRlIHRvIHJlYWQtb25seSBtZW1vcnkgcGFnZS4gZ2ZuPTB4
ZGUsIG1mbj0weGE0YTA4DQooWEVOKSBbMjAxMi0wOS0wNSAxNTo1MjoyOF0gaHZtLmM6MjQz
NTpkMTUgZ3Vlc3QgYXR0ZW1wdGVkIHdyaXRlIHRvIHJlYWQtb25seSBtZW1vcnkgcGFnZS4g
Z2ZuPTB4ZGQsIG1mbj0weGE0YTA5DQooWEVOKSBbMjAxMi0wOS0wNSAxNTo1MjoyOF0gaHZt
LmM6MjQzNTpkMTUgZ3Vlc3QgYXR0ZW1wdGVkIHdyaXRlIHRvIHJlYWQtb25seSBtZW1vcnkg
cGFnZS4gZ2ZuPTB4ZGUsIG1mbj0weGE0YTA4DQooWEVOKSBbMjAxMi0wOS0wNSAxNTo1Mjoy
OF0gaHZtLmM6MjQzNTpkMTUgZ3Vlc3QgYXR0ZW1wdGVkIHdyaXRlIHRvIHJlYWQtb25seSBt
ZW1vcnkgcGFnZS4gZ2ZuPTB4ZGMsIG1mbj0weGE0YTBhDQooWEVOKSBbMjAxMi0wOS0wNSAx
NTo1MjoyOF0gaHZtLmM6MjQzNTpkMTUgZ3Vlc3QgYXR0ZW1wdGVkIHdyaXRlIHRvIHJlYWQt
b25seSBtZW1vcnkgcGFnZS4gZ2ZuPTB4ZGQsIG1mbj0weGE0YTA5DQooWEVOKSBbMjAxMi0w
OS0wNSAxNTo1MjoyOF0gaHZtLmM6MjQzNTpkMTUgZ3Vlc3QgYXR0ZW1wdGVkIHdyaXRlIHRv
IHJlYWQtb25seSBtZW1vcnkgcGFnZS4gZ2ZuPTB4ZGMsIG1mbj0weGE0YTBhDQooWEVOKSBb
MjAxMi0wOS0wNSAxNTo1MjoyOF0gaHZtLmM6MjQzNTpkMTUgZ3Vlc3QgYXR0ZW1wdGVkIHdy
aXRlIHRvIHJlYWQtb25seSBtZW1vcnkgcGFnZS4gZ2ZuPTB4ZGQsIG1mbj0weGE0YTA5DQoo
WEVOKSBbMjAxMi0wOS0wNSAxNTo1MjoyOF0gaHZtLmM6MjQzNTpkMTUgZ3Vlc3QgYXR0ZW1w
dGVkIHdyaXRlIHRvIHJlYWQtb25seSBtZW1vcnkgcGFnZS4gZ2ZuPTB4ZGUsIG1mbj0weGE0
YTA4DQooWEVOKSBbMjAxMi0wOS0wNSAxNTo1MjoyOF0gaHZtLmM6MjQzNTpkMTUgZ3Vlc3Qg
YXR0ZW1wdGVkIHdyaXRlIHRvIHJlYWQtb25seSBtZW1vcnkgcGFnZS4gZ2ZuPTB4ZGQsIG1m
bj0weGE0YTA5DQooWEVOKSBbMjAxMi0wOS0wNSAxNTo1MjoyOF0gaHZtLmM6MjQzNTpkMTUg
Z3Vlc3QgYXR0ZW1wdGVkIHdyaXRlIHRvIHJlYWQtb25seSBtZW1vcnkgcGFnZS4gZ2ZuPTB4
ZGMsIG1mbj0weGE0YTBhDQooWEVOKSBbMjAxMi0wOS0wNSAxNTo1MjoyOF0gaHZtLmM6MjQz
NTpkMTUgZ3Vlc3QgYXR0ZW1wdGVkIHdyaXRlIHRvIHJlYWQtb25seSBtZW1vcnkgcGFnZS4g
Z2ZuPTB4ZGQsIG1mbj0weGE0YTA5DQooWEVOKSBbMjAxMi0wOS0wNSAxNTo1MjoyOF0gaHZt
LmM6MjQzNTpkMTUgZ3Vlc3QgYXR0ZW1wdGVkIHdyaXRlIHRvIHJlYWQtb25seSBtZW1vcnkg
cGFnZS4gZ2ZuPTB4ZGMsIG1mbj0weGE0YTBhDQooWEVOKSBbMjAxMi0wOS0wNSAxNTo1Mjoy
OF0gaHZtLmM6MjQzNTpkMTUgZ3Vlc3QgYXR0ZW1wdGVkIHdyaXRlIHRvIHJlYWQtb25seSBt
ZW1vcnkgcGFnZS4gZ2ZuPTB4ZGQsIG1mbj0weGE0YTA5DQooWEVOKSBbMjAxMi0wOS0wNSAx
NTo1MjozMV0gaHZtLmM6MjQzNTpkMTUgZ3Vlc3QgYXR0ZW1wdGVkIHdyaXRlIHRvIHJlYWQt
b25seSBtZW1vcnkgcGFnZS4gZ2ZuPTB4YzksIG1mbj0weGE0YTFkDQooWEVOKSBbMjAxMi0w
OS0wNSAxNTo1MjozMV0gaHZtLmM6MjQzNTpkMTUgZ3Vlc3QgYXR0ZW1wdGVkIHdyaXRlIHRv
IHJlYWQtb25seSBtZW1vcnkgcGFnZS4gZ2ZuPTB4Y2IsIG1mbj0weGE0YTFiDQooWEVOKSBb
MjAxMi0wOS0wNSAxNTo1MjozMV0gaHZtLmM6MjQzNTpkMTUgZ3Vlc3QgYXR0ZW1wdGVkIHdy
aXRlIHRvIHJlYWQtb25seSBtZW1vcnkgcGFnZS4gZ2ZuPTB4Y2QsIG1mbj0weGE0YTE5DQoo
WEVOKSBbMjAxMi0wOS0wNSAxNTo1MjozMV0gaHZtLmM6MjQzNTpkMTUgZ3Vlc3QgYXR0ZW1w
dGVkIHdyaXRlIHRvIHJlYWQtb25seSBtZW1vcnkgcGFnZS4gZ2ZuPTB4Y2YsIG1mbj0weGE0
YTE3DQooWEVOKSBbMjAxMi0wOS0wNSAxNTo1MjozMV0gaHZtLmM6MjQzNTpkMTUgZ3Vlc3Qg
YXR0ZW1wdGVkIHdyaXRlIHRvIHJlYWQtb25seSBtZW1vcnkgcGFnZS4gZ2ZuPTB4ZDEsIG1m
bj0weGE0YTE1DQooWEVOKSBbMjAxMi0wOS0wNSAxNTo1MjozMV0gaHZtLmM6MjQzNTpkMTUg
Z3Vlc3QgYXR0ZW1wdGVkIHdyaXRlIHRvIHJlYWQtb25seSBtZW1vcnkgcGFnZS4gZ2ZuPTB4
ZDMsIG1mbj0weGE0YTEzDQooWEVOKSBbMjAxMi0wOS0wNSAxNTo1MjozMV0gaHZtLmM6MjQz
NTpkMTUgZ3Vlc3QgYXR0ZW1wdGVkIHdyaXRlIHRvIHJlYWQtb25seSBtZW1vcnkgcGFnZS4g
Z2ZuPTB4ZDUsIG1mbj0weGE0YTExDQooWEVOKSBbMjAxMi0wOS0wNSAxNTo1MjozMV0gaHZt
LmM6MjQzNTpkMTUgZ3Vlc3QgYXR0ZW1wdGVkIHdyaXRlIHRvIHJlYWQtb25seSBtZW1vcnkg
cGFnZS4gZ2ZuPTB4ZDcsIG1mbj0weGE0YTBmDQooWEVOKSBbMjAxMi0wOS0wNSAxNTo1Mjoz
MV0gaHZtLmM6MjQzNTpkMTUgZ3Vlc3QgYXR0ZW1wdGVkIHdyaXRlIHRvIHJlYWQtb25seSBt
ZW1vcnkgcGFnZS4gZ2ZuPTB4ZDksIG1mbj0weGE0YTBkDQooWEVOKSBbMjAxMi0wOS0wNSAx
NTo1MjozMV0gaHZtLmM6MjQzNTpkMTUgZ3Vlc3QgYXR0ZW1wdGVkIHdyaXRlIHRvIHJlYWQt
b25seSBtZW1vcnkgcGFnZS4gZ2ZuPTB4ZGIsIG1mbj0weGE0YTBiDQooWEVOKSBbMjAxMi0w
OS0wNSAxNTo1MjozMV0gaHZtLmM6MjQzNTpkMTUgZ3Vlc3QgYXR0ZW1wdGVkIHdyaXRlIHRv
IHJlYWQtb25seSBtZW1vcnkgcGFnZS4gZ2ZuPTB4ZGQsIG1mbj0weGE0YTA5DQooWEVOKSBb
MjAxMi0wOS0wNSAxNTo1MjozMV0gaHZtLmM6MjQzNTpkMTUgZ3Vlc3QgYXR0ZW1wdGVkIHdy
aXRlIHRvIHJlYWQtb25seSBtZW1vcnkgcGFnZS4gZ2ZuPTB4ZGYsIG1mbj0weGE0YTA3DQoo
WEVOKSBbMjAxMi0wOS0wNSAxNTo1MjozMV0gaHZtLmM6MjQzNTpkMTUgZ3Vlc3QgYXR0ZW1w
dGVkIHdyaXRlIHRvIHJlYWQtb25seSBtZW1vcnkgcGFnZS4gZ2ZuPTB4ZTEsIG1mbj0weGE0
YTA1DQooWEVOKSBbMjAxMi0wOS0wNSAxNTo1MjozMV0gaHZtLmM6MjQzNTpkMTUgZ3Vlc3Qg
YXR0ZW1wdGVkIHdyaXRlIHRvIHJlYWQtb25seSBtZW1vcnkgcGFnZS4gZ2ZuPTB4ZTMsIG1m
bj0weGE0YTAzDQooWEVOKSBbMjAxMi0wOS0wNSAxNTo1MjozMV0gaHZtLmM6MjQzNTpkMTUg
Z3Vlc3QgYXR0ZW1wdGVkIHdyaXRlIHRvIHJlYWQtb25seSBtZW1vcnkgcGFnZS4gZ2ZuPTB4
ZTUsIG1mbj0weGE0YTAxDQooWEVOKSBbMjAxMi0wOS0wNSAxNTo1MjozMV0gaHZtLmM6MjQz
NTpkMTUgZ3Vlc3QgYXR0ZW1wdGVkIHdyaXRlIHRvIHJlYWQtb25seSBtZW1vcnkgcGFnZS4g
Z2ZuPTB4ZTcsIG1mbj0weGE0NjNmDQooWEVOKSBbMjAxMi0wOS0wNSAxNTo1MjozMV0gaHZt
LmM6MjQzNTpkMTUgZ3Vlc3QgYXR0ZW1wdGVkIHdyaXRlIHRvIHJlYWQtb25seSBtZW1vcnkg
cGFnZS4gZ2ZuPTB4ZTksIG1mbj0weGE0NjNkDQooWEVOKSBbMjAxMi0wOS0wNSAxNTo1Mjoz
MV0gaHZtLmM6MjQzNTpkMTUgZ3Vlc3QgYXR0ZW1wdGVkIHdyaXRlIHRvIHJlYWQtb25seSBt
ZW1vcnkgcGFnZS4gZ2ZuPTB4ZWIsIG1mbj0weGE0NjNiDQooWEVOKSBbMjAxMi0wOS0wNSAx
NTo1MjozMV0gaHZtLmM6MjQzNTpkMTUgZ3Vlc3QgYXR0ZW1wdGVkIHdyaXRlIHRvIHJlYWQt
b25seSBtZW1vcnkgcGFnZS4gZ2ZuPTB4ZWQsIG1mbj0weGE0NjM5DQooWEVOKSBbMjAxMi0w
OS0wNSAxNTo1MjozMV0gaHZtLmM6MjQzNTpkMTUgZ3Vlc3QgYXR0ZW1wdGVkIHdyaXRlIHRv
IHJlYWQtb25seSBtZW1vcnkgcGFnZS4gZ2ZuPTB4ZWYsIG1mbj0weGE0NjM3DQooWEVOKSBb
MjAxMi0wOS0wNSAxNTo1ODo0Ml0gdHJhcHMuYzozMTU2OiBHUEYgKDAwNjApOiBmZmZmODJj
NDgwMTVjOWZlIC0+IGZmZmY4MmM0ODAyMjRiODMNCihYRU4pIFsyMDEyLTA5LTA1IDE1OjU4
OjQyXSB0cmFwcy5jOjMxNTc6ICBzaG93X2V4ZWN1dGlvbl9zdGF0ZShyZWdzKTogDQooWEVO
KSBbMjAxMi0wOS0wNSAxNTo1ODo0Ml0gLS0tLVsgWGVuLTQuMi4wLXJjNC1wcmUgIHg4Nl82
NCAgZGVidWc9eSAgTm90IHRhaW50ZWQgXS0tLS0NCihYRU4pIFsyMDEyLTA5LTA1IDE1OjU4
OjQyXSBDUFU6ICAgIDMNCihYRU4pIFsyMDEyLTA5LTA1IDE1OjU4OjQyXSBSSVA6ICAgIGUw
MDg6WzxmZmZmODJjNDgwMTVjOWZlPl0gY29udGV4dF9zd2l0Y2grMHgzOTQvMHhlZWINCihY
RU4pIFsyMDEyLTA5LTA1IDE1OjU4OjQyXSBSRkxBR1M6IDAwMDAwMDAwMDAwMTAyNDYgICBD
T05URVhUOiBoeXBlcnZpc29yDQooWEVOKSBbMjAxMi0wOS0wNSAxNTo1ODo0Ml0gcmF4OiAw
MDAwMDAwMDAwMDAwMDAxICAgcmJ4OiBmZmZmODMwMGE1MmQ5MDAwICAgcmN4OiAwMDAwMDAw
MDAwMDAwMDAxDQooWEVOKSBbMjAxMi0wOS0wNSAxNTo1ODo0Ml0gcmR4OiAwMDAwMDAwMDAw
MDAwMDYzICAgcnNpOiAwMDAwMDAwMDAwMDAwMDAxICAgcmRpOiAwMDAwMDAwMDAwMDAwMTVj
DQooWEVOKSBbMjAxMi0wOS0wNSAxNTo1ODo0Ml0gcmJwOiBmZmZmODMwMjRkOGE3ZTI4ICAg
cnNwOiBmZmZmODMwMjRkOGE3ZDg4ICAgcjg6ICAwMDAwMDAwMDAwMDAwMDA2DQooWEVOKSBb
MjAxMi0wOS0wNSAxNTo1ODo0Ml0gcjk6ICBmZmZmODMwMGFmZDA3MDYwICAgcjEwOiAwMDAw
MDAwMGRlYWRiZWVmICAgcjExOiAwMDAwMDAwMDAwMDAwMjQ2DQooWEVOKSBbMjAxMi0wOS0w
NSAxNTo1ODo0Ml0gcjEyOiBmZmZmODMwMGFmZDA3MDAwICAgcjEzOiAwMDAwMDAwMDAwMDAw
MDAzICAgcjE0OiAwMDAwMDAwMDAwMDAwMDAzDQooWEVOKSBbMjAxMi0wOS0wNSAxNTo1ODo0
Ml0gcjE1OiBmZmZmODMwMjRkOGFhMDQ4ICAgY3IwOiAwMDAwMDAwMDgwMDUwMDNiICAgY3I0
OiAwMDAwMDAwMDAwMDAwNmYwDQooWEVOKSBbMjAxMi0wOS0wNSAxNTo1ODo0Ml0gY3IzOiAw
MDAwMDAwMDY4MTQ0MDAwICAgY3IyOiAwMDAwMDAwMGY3NmFkOTM0DQooWEVOKSBbMjAxMi0w
OS0wNSAxNTo1ODo0Ml0gZHM6IDAwMDAgICBlczogMDAwMCAgIGZzOiAwMDAwICAgZ3M6IDAw
MDAgICBzczogZTAxMCAgIGNzOiBlMDA4DQooWEVOKSBbMjAxMi0wOS0wNSAxNTo1ODo0Ml0g
WGVuIHN0YWNrIHRyYWNlIGZyb20gcnNwPWZmZmY4MzAyNGQ4YTdkODg6DQooWEVOKSBbMjAx
Mi0wOS0wNSAxNTo1ODo0Ml0gICAgZmZmZjgzMDI0ZDhhN2RkOCAwMDAwMDAwMDAwMDAwMjgy
IDAwMDAwMDFlNzcyZmQ2ZDkgMDAwMDAwMDAwMDAwMDI4Mg0KKFhFTikgWzIwMTItMDktMDUg
MTU6NTg6NDJdICAgIGZmZmY4MzAwNjViNTEwNjAgZmZmZjgzMDI0ZDhhYTA2MCBmZmZmODMw
MjRkOGE3ZTE4IGZmZmY4MmM0ODAxODA1YmUNCihYRU4pIFsyMDEyLTA5LTA1IDE1OjU4OjQy
XSAgICAwMDAwMDAwMDAwMDAwOTRhIDAwMDAwMWM1YTljZWY5NDIgMDAwMDAwMDAwMDAwMDAw
MCAwMDAwMDAwMDAwMDAwMDAwDQooWEVOKSBbMjAxMi0wOS0wNSAxNTo1ODo0Ml0gICAgMDAw
MDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIGZmZmY4MzAyNGQ4YTdlMjggZmZmZjgz
MDBhZmQwNzAwMA0KKFhFTikgWzIwMTItMDktMDUgMTU6NTg6NDJdICAgIGZmZmY4MzAwYTUy
ZDkwMDAgMDAwMDAwODU3Njk4MzlmMCAwMDAwMDAwMDAwMDAwMDAyIGZmZmY4MzAyNGQ4YWEw
NDgNCihYRU4pIFsyMDEyLTA5LTA1IDE1OjU4OjQyXSAgICBmZmZmODMwMjRkOGE3ZWI4IGZm
ZmY4MmM0ODAxMjRhNzAgMDBmZjgzMDI0ZDhhN2U4OCBmZmZmODMwMjRkOGFhMDQwDQooWEVO
KSBbMjAxMi0wOS0wNSAxNTo1ODo0Ml0gICAgMDAwMDAwMDM4Y2ExNWRjNCAwMDAwMDA4NTc2
OTgzOWYwIGZmZmY4MzAyNGQ4YTdlODggZmZmZmZmZmZmZmZmZmZjMg0KKFhFTikgWzIwMTIt
MDktMDUgMTU6NTg6NDJdICAgIGZmZmY4MzAwYTUyZDkwMDAgMDAwMDAwMDAwMWM5YzM4MCBm
ZmZmODMwMjRkOGE3ZTAwIGZmZmY4MmM0ODAxMjI2Y2UNCihYRU4pIFsyMDEyLTA5LTA1IDE1
OjU4OjQyXSAgICBmZmZmODMwMjRkOGE3ZWY4IGZmZmY4MmM0ODAyZDgxODAgMDAwMDAwMDBm
ZmZmZmZmZiBmZmZmODJjNDgwMmQ4MDAwDQooWEVOKSBbMjAxMi0wOS0wNSAxNTo1ODo0Ml0g
ICAgZmZmZjgzMDI0ZDhhN2YxOCBmZmZmZmZmZmZmZmZmZmZmIGZmZmY4MzAyNGQ4YTdlZjgg
ZmZmZjgyYzQ4MDEyNWUzMQ0KKFhFTikgWzIwMTItMDktMDUgMTU6NTg6NDJdICAgIDAwMDAw
MDAwMDAwMDAyNDYgZmZmZjgzMDBhZmQwNzAwMCBmZmZmZmZmZjgxZWNlNWQ4IDAwMDAwMDAw
MDAwMDAwMDANCihYRU4pIFsyMDEyLTA5LTA1IDE1OjU4OjQyXSAgICAwMDAwMDAwMDAwMDAw
MDAwIDAwMDAwMDAwMDAwMDAwMDAgZmZmZjgzMDI0ZDhhN2YwOCBmZmZmODJjNDgwMTI1ZTY4
DQooWEVOKSBbMjAxMi0wOS0wNSAxNTo1ODo0Ml0gICAgMDAwMDdjZmRiMjc1ODBjNyBmZmZm
ODJjNDgwMjIyZjA2IDAwMDAwMDAwMDAwMDAwMDAgZmZmZmZmZmY4MWUxMzg4MA0KKFhFTikg
WzIwMTItMDktMDUgMTU6NTg6NDJdICAgIDAwMDAwMDAwMDAwMDAwMDAgZmZmZjg4MDAxZDNm
MDBkOCBmZmZmZmZmZjgxZTAxY2U4IGZmZmY4ODAwMWZjMGIxMDANCihYRU4pIFsyMDEyLTA5
LTA1IDE1OjU4OjQyXSAgICAwMDAwMDAwMDAwMDAwMjAyIDAwMDAwMDAwMDAwMDAwMDAgMDAw
MDAwMDAwMDAwMDAwMSAwMDAwMDAwMDAwMDAwMDAwDQooWEVOKSBbMjAxMi0wOS0wNSAxNTo1
ODo0Ml0gICAgMDAwMDAwMDAwMDAwMDAwMCBmZmZmZmZmZjgxMDAxMWFhIGZmZmY4ODAwMWVi
NDAwMDAgMDAwMDAwMDBkZWFkYmVlZg0KKFhFTikgWzIwMTItMDktMDUgMTU6NTg6NDJdICAg
IDAwMDAwMDAwZGVhZGJlZWYgMDAwMDAxMDAwMDAwMDAwMCBmZmZmZmZmZjgxMDAxMWFhIDAw
MDAwMDAwMDAwMGUwMzMNCihYRU4pIFsyMDEyLTA5LTA1IDE1OjU4OjQyXSAgICAwMDAwMDAw
MDAwMDAwMjAyIGZmZmZmZmZmODFlMDFjYjAgMDAwMDAwMDAwMDAwZTAyYiAwMDAwNTNmZDAw
MDBiZWVmDQooWEVOKSBbMjAxMi0wOS0wNSAxNTo1ODo0Ml0gICAgODAwMDAwMDAwMDAwYmVl
ZiA3NDAwMDAwMDAwMDBiZWVmIDAwMDAwMDAwMDAxOGJlZWYgMDAwMDUzZmUwMDAwMDAwMw0K
KFhFTikgWzIwMTItMDktMDUgMTU6NTg6NDJdICAgIGZmZmY4MzAwYTUyZDkwMDAgMDAwMDAw
M2RjZDVhODY4MCAwMDAwMDAwMDAwMThlMGM5DQooWEVOKSBbMjAxMi0wOS0wNSAxNTo1ODo0
Ml0gWGVuIGNhbGwgdHJhY2U6DQooWEVOKSBbMjAxMi0wOS0wNSAxNTo1ODo0Ml0gICAgWzxm
ZmZmODJjNDgwMTVjOWZlPl0gY29udGV4dF9zd2l0Y2grMHgzOTQvMHhlZWINCihYRU4pIFsy
MDEyLTA5LTA1IDE1OjU4OjQyXSAgICBbPGZmZmY4MmM0ODAxMjRhNzA+XSBzY2hlZHVsZSsw
eDY2Ni8weDY3NQ0KKFhFTikgWzIwMTItMDktMDUgMTU6NTg6NDJdICAgIFs8ZmZmZjgyYzQ4
MDEyNWUzMT5dIF9fZG9fc29mdGlycSsweGE0LzB4YjUNCihYRU4pIFsyMDEyLTA5LTA1IDE1
OjU4OjQyXSAgICBbPGZmZmY4MmM0ODAxMjVlNjg+XSBkb19zb2Z0aXJxKzB4MjYvMHgyOA0K
KFhFTikgWzIwMTItMDktMDUgMTU6NTg6NDJdICAgIA0KKFhFTikgWzIwMTItMDktMDUgMTU6
NTg6NDJdIHRyYXBzLmM6MzE1OTogICBzaG93X2V4ZWN1dGlvbl9zdGF0ZShndWVzdF9jcHVf
dXNlcl9yZWdzKCkpOiANCihYRU4pIFsyMDEyLTA5LTA1IDE1OjU4OjQyXSAtLS0tWyBYZW4t
NC4yLjAtcmM0LXByZSAgeDg2XzY0ICBkZWJ1Zz15ICBOb3QgdGFpbnRlZCBdLS0tLQ0KKFhF
TikgWzIwMTItMDktMDUgMTU6NTg6NDJdIENQVTogICAgMw0KKFhFTikgWzIwMTItMDktMDUg
MTU6NTg6NDJdIFJJUDogICAgZTAzMzpbPGZmZmZmZmZmODEwMDExYWE+XQ0KKFhFTikgWzIw
MTItMDktMDUgMTU6NTg6NDJdIFJGTEFHUzogMDAwMDAwMDAwMDAwMDIwMiAgIEVNOiAxICAg
Q09OVEVYVDogcHYgZ3Vlc3QNCihYRU4pIFsyMDEyLTA5LTA1IDE1OjU4OjQyXSByYXg6IDAw
MDAwMDAwMDAwMDAwMDAgICByYng6IGZmZmY4ODAwMWZjMGIxMDAgICByY3g6IGZmZmZmZmZm
ODEwMDExYWENCihYRU4pIFsyMDEyLTA5LTA1IDE1OjU4OjQyXSByZHg6IGZmZmY4ODAwMWVi
NDAwMDAgICByc2k6IDAwMDAwMDAwZGVhZGJlZWYgICByZGk6IDAwMDAwMDAwZGVhZGJlZWYN
CihYRU4pIFsyMDEyLTA5LTA1IDE1OjU4OjQyXSByYnA6IGZmZmZmZmZmODFlMDFjZTggICBy
c3A6IGZmZmZmZmZmODFlMDFjYjAgICByODogIDAwMDAwMDAwMDAwMDAwMDANCihYRU4pIFsy
MDEyLTA5LTA1IDE1OjU4OjQyXSByOTogIDAwMDAwMDAwMDAwMDAwMDEgICByMTA6IDAwMDAw
MDAwMDAwMDAwMDAgICByMTE6IDAwMDAwMDAwMDAwMDAyMDINCihYRU4pIFsyMDEyLTA5LTA1
IDE1OjU4OjQyXSByMTI6IGZmZmY4ODAwMWQzZjAwZDggICByMTM6IDAwMDAwMDAwMDAwMDAw
MDAgICByMTQ6IGZmZmZmZmZmODFlMTM4ODANCihYRU4pIFsyMDEyLTA5LTA1IDE1OjU4OjQy
XSByMTU6IDAwMDAwMDAwMDAwMDAwMDAgICBjcjA6IDAwMDAwMDAwODAwNTAwM2IgICBjcjQ6
IDAwMDAwMDAwMDAwMDA2ZjANCihYRU4pIFsyMDEyLTA5LTA1IDE1OjU4OjQyXSBjcjM6IDAw
MDAwMDAwNjgxNDQwMDAgICBjcjI6IDAwMDAwMDAwZjc2YWQ5MzQNCihYRU4pIFsyMDEyLTA5
LTA1IDE1OjU4OjQyXSBkczogMDAwMCAgIGVzOiAwMDAwICAgZnM6IDAwMDAgICBnczogMDAw
MCAgIHNzOiBlMDJiICAgY3M6IGUwMzMNCihYRU4pIFsyMDEyLTA5LTA1IDE1OjU4OjQyXSBH
dWVzdCBzdGFjayB0cmFjZSBmcm9tIHJzcD1mZmZmZmZmZjgxZTAxY2IwOg0KKFhFTikgWzIw
MTItMDktMDUgMTU6NTg6NDJdICAgIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAw
MSBmZmZmZmZmZjgxMDA0OTQyIGZmZmZmZmZmODFlMTM0MjANCihYRU4pIFsyMDEyLTA5LTA1
IDE1OjU4OjQyXSAgICBmZmZmODgwMDFlYjQwMDAwIDAwMDAwMDAwMDAwMDAwMDAgZmZmZmZm
ZmY4MWUxMzg4MCBmZmZmZmZmZjgxZTAxZDA4DQooWEVOKSBbMjAxMi0wOS0wNSAxNTo1ODo0
Ml0gICAgZmZmZmZmZmY4MTAwMzk0MSBmZmZmODgwMDFlYjQwMDAwIGZmZmZmZmZmODFlMTM0
MjAgZmZmZmZmZmY4MWUwMWQ2OA0KKFhFTikgWzIwMTItMDktMDUgMTU6NTg6NDJdICAgIGZm
ZmZmZmZmODEwMGI4NTAgZmZmZmZmZmY4MWUxMzQyMCAwMDAwMDAwMDAwMDAwMDAxIDAwMDAw
MDAwMDAwMDAwNjMNCihYRU4pIFsyMDEyLTA5LTA1IDE1OjU4OjQyXSAgICBmZmZmODgwMDFm
YzEwYTgwIGZmZmZmZmZmODFlMDFkNzggZmZmZjg4MDAxZmMxMmU4MCAwMDAwMDAwMDAwMDAw
MDAwDQooWEVOKSBbMjAxMi0wOS0wNSAxNTo1ODo0Ml0gICAgZmZmZjg4MDAxY2NkNDkwMCAw
MDAwMDAwMDAwMDAwMDgyIGZmZmZmZmZmODEwZjAwNDAgZmZmZmZmZmY4MWUxMzQyMA0KKFhF
TikgWzIwMTItMDktMDUgMTU6NTg6NDJdICAgIGZmZmZmZmZmODE3ZmEyZjUgZmZmZmZmZmY4
MWUwMWVjOCAwMDAwMDAwMDAwMDAwMjE2IGZmZmY4ODAwMWZjMGU2OTgNCihYRU4pIFsyMDEy
LTA5LTA1IDE1OjU4OjQyXSAgICAwMDAwMDAwMDAwMDAwMDAxIGZmZmZmZmZmODFlMTM0MjAg
MDAwMDAwMDAwMDAxMmU4MCBmZmZmZmZmZjgxZTAxZmQ4DQooWEVOKSBbMjAxMi0wOS0wNSAx
NTo1ODo0Ml0gICAgZmZmZmZmZmY4MWUwMDAxMCAwMDAwMDAwMDAwMDEyZTgwIDAwMDAwMDAw
MDAwMTJlODAgZmZmZmZmZmY4MWUwMWZkOA0KKFhFTikgWzIwMTItMDktMDUgMTU6NTg6NDJd
ICAgIDAwMDAwMDAwMDAwMTJlODAgZmZmZjg4MDAxZWFkMjA4MCBmZmZmZmZmZjgxZTEzNDIw
IGZmZmY4ODAwMWZjMGU4YTANCihYRU4pIFsyMDEyLTA5LTA1IDE1OjU4OjQyXSAgICAwMDAw
MDAwMDAwMDAwMDAwIGZmZmZmZmZmODFlMDFlOTggZmZmZmZmZmY4MTA4YjM4MSAwMDAwMDAw
MDAwMDAwMDAwDQooWEVOKSBbMjAxMi0wOS0wNSAxNTo1ODo0Ml0gICAgZmZmZmZmZmY4MTBh
YjIyMSAwMDAwMDAwMTgxZTAxZTI4IDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDA4MWUwMWU0
OA0KKFhFTikgWzIwMTItMDktMDUgMTU6NTg6NDJdICAgIDAwMDAwMDAwMDAwMDAwNzAgMDAw
MDAwMDAxZmMwZThhMCAwMDAwMDAwMDAwMDBlNjgwIDAwMDAwMDAwMDAwMDAwMDANCihYRU4p
IFsyMDEyLTA5LTA1IDE1OjU4OjQyXSAgICBmZmZmZmZmZjgxZTEzNDIwIGZmZmZmZmZmODEw
YTg2ZmMgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwDQooWEVOKSBbMjAxMi0w
OS0wNSAxNTo1ODo0Ml0gICAgMDAwMDAwMDAwMDAwMDAwMCBmZmZmZmZmZjgxZTAxZTk4IGZm
ZmZmZmZmODEwYWNiNzggZmZmZjg4MDAxZmMwZThhMA0KKFhFTikgWzIwMTItMDktMDUgMTU6
NTg6NDJdICAgIDAwMDAwMDVjOTVhMzk0NWUgZmZmZmZmZmY4MWUwMWVhOCBmZmZmZmZmZjgx
ZTAwMDEwIGZmZmZmZmZmODFlY2U1ZDgNCihYRU4pIFsyMDEyLTA5LTA1IDE1OjU4OjQyXSAg
ICBmZmZmZmZmZjgxZjQyMGMwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCBm
ZmZmZmZmZjgxZTAxZWQ4DQooWEVOKSBbMjAxMi0wOS0wNSAxNTo1ODo0Ml0gICAgZmZmZmZm
ZmY4MTdmYTgxNCBmZmZmZmZmZjgxZTAxZWY4IGZmZmZmZmZmODEwMTY0NTYgMDAwMDAwMDAw
MDAwMDAwMg0KKFhFTikgWzIwMTItMDktMDUgMTU6NTg6NDJdICAgIGZmZmZmZmZmODFmMzk5
MjAgZmZmZmZmZmY4MWUwMWYyOCBmZmZmZmZmZjgxN2Q1YjhjIGZmZmZmZmZmODE3ZDVhZDAN
CihYRU4pIFsyMDEyLTA5LTA1IDE1OjU4OjQyXSAgICBmZmZmODgwMDAwMDAxMDAwIGZmZmZm
ZmZmODFlMDFmMjggMDAwMDAwMDAwMDAwMDAwMCBmZmZmZmZmZjgxZTAxZjc4DQooWEVOKSBb
MjAxMi0wOS0wNSAxNTo1ODo1NV0gdHJhcHMuYzozMTU2OiBHUEYgKDAwNjApOiBmZmZmODJj
NDgwMTVjOWZlIC0+IGZmZmY4MmM0ODAyMjRiODMNCihYRU4pIFsyMDEyLTA5LTA1IDE1OjU4
OjU1XSB0cmFwcy5jOjMxNTc6ICBzaG93X2V4ZWN1dGlvbl9zdGF0ZShyZWdzKTogDQooWEVO
KSBbMjAxMi0wOS0wNSAxNTo1ODo1NV0gLS0tLVsgWGVuLTQuMi4wLXJjNC1wcmUgIHg4Nl82
NCAgZGVidWc9eSAgTm90IHRhaW50ZWQgXS0tLS0NCihYRU4pIFsyMDEyLTA5LTA1IDE1OjU4
OjU1XSBDUFU6ICAgIDMNCihYRU4pIFsyMDEyLTA5LTA1IDE1OjU4OjU1XSBSSVA6ICAgIGUw
MDg6WzxmZmZmODJjNDgwMTVjOWZlPl0gY29udGV4dF9zd2l0Y2grMHgzOTQvMHhlZWINCihY
RU4pIFsyMDEyLTA5LTA1IDE1OjU4OjU1XSBSRkxBR1M6IDAwMDAwMDAwMDAyMTAyMDIgICBD
T05URVhUOiBoeXBlcnZpc29yDQooWEVOKSBbMjAxMi0wOS0wNSAxNTo1ODo1NV0gcmF4OiAw
MDAwMDAwMDAwMDAwMDAxICAgcmJ4OiBmZmZmODMwMGE1MmQ5MDAwICAgcmN4OiAwMDAwMDAw
MDAwMDAwMDAxDQooWEVOKSBbMjAxMi0wOS0wNSAxNTo1ODo1NV0gcmR4OiAwMDAwMDAwMDAw
MDAwMDYzICAgcnNpOiAwMDAwMDAwMDAwMDAwMDAxICAgcmRpOiAwMDAwMDAwMDAwMDAwMWFl
DQooWEVOKSBbMjAxMi0wOS0wNSAxNTo1ODo1NV0gcmJwOiBmZmZmODMwMjRkOGE3ZTI4ICAg
cnNwOiBmZmZmODMwMjRkOGE3ZDg4ICAgcjg6ICAwMDAwMDAwMDAwMDAwMDA2DQooWEVOKSBb
MjAxMi0wOS0wNSAxNTo1ODo1NV0gcjk6ICBmZmZmODMwMjRkOGFhMDYwICAgcjEwOiBmZmZm
ODMwMGFmZDFiMDYwICAgcjExOiAwMDAwMDA4ODgzYTllODM1DQooWEVOKSBbMjAxMi0wOS0w
NSAxNTo1ODo1NV0gcjEyOiBmZmZmODMwMGE1YTcyMDAwICAgcjEzOiAwMDAwMDAwMDAwMDAw
MDAzICAgcjE0OiAwMDAwMDAwMDAwMDAwMDAzDQooWEVOKSBbMjAxMi0wOS0wNSAxNTo1ODo1
NV0gcjE1OiBmZmZmODMwMjRkOGFhMDQ4ICAgY3IwOiAwMDAwMDAwMDgwMDUwMDNiICAgY3I0
OiAwMDAwMDAwMDAwMDAwNmYwDQooWEVOKSBbMjAxMi0wOS0wNSAxNTo1ODo1NV0gY3IzOiAw
MDAwMDAwMDgwOTU3MDAwICAgY3IyOiAwMDAwMDAwMGI3MzgxMDAwDQooWEVOKSBbMjAxMi0w
OS0wNSAxNTo1ODo1NV0gZHM6IDAwMDAgICBlczogMDAwMCAgIGZzOiAwMDAwICAgZ3M6IDAw
NjMgICBzczogMDAwMCAgIGNzOiBlMDA4DQooWEVOKSBbMjAxMi0wOS0wNSAxNTo1ODo1NV0g
WGVuIHN0YWNrIHRyYWNlIGZyb20gcnNwPWZmZmY4MzAyNGQ4YTdkODg6DQooWEVOKSBbMjAx
Mi0wOS0wNSAxNTo1ODo1NV0gICAgMDAwMDAwMDAwMDAwMDBhYiBmZmZmODJmNjAwY2I2YTIw
IDAwMDAwMDFlYTU2OTQwMDAgMDAwMDAwMDAwMDAwMDAwMA0KKFhFTikgWzIwMTItMDktMDUg
MTU6NTg6NTVdICAgIGZmZmY4MzAwNjViNTEwNjAgZmZmZjgzMDI0ZDhhYTA2MCBmZmZmODMw
MjRkOGE3ZTE4IGZmZmY4MmM0ODAxODA1YmUNCihYRU4pIFsyMDEyLTA5LTA1IDE1OjU4OjU1
XSAgICAwMDAwMDAwMDAwMDAwOWFhIDAwMDAwMWNmNTljNjdhN2EgMDAwMDAwMDAwMDAwMDAw
MCAwMDAwMDAwMDAwMDAwMDAwDQooWEVOKSBbMjAxMi0wOS0wNSAxNTo1ODo1NV0gICAgMDAw
MDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIGZmZmY4MzAyNGQ4YTdlMjggZmZmZjgz
MDBhNWE3MjAwMA0KKFhFTikgWzIwMTItMDktMDUgMTU6NTg6NTVdICAgIGZmZmY4MzAwYTUy
ZDkwMDAgMDAwMDAwODg4MzgxYmY1NiAwMDAwMDAwMDAwMDAwMDAzIGZmZmY4MzAyNGQ4YWEw
NDgNCihYRU4pIFsyMDEyLTA5LTA1IDE1OjU4OjU1XSAgICBmZmZmODMwMjRkOGE3ZWI4IGZm
ZmY4MmM0ODAxMjRhNzAgMDBmZjgzMDI0ZDhhN2U2OCBmZmZmODMwMjRkOGFhMDQwDQooWEVO
KSBbMjAxMi0wOS0wNSAxNTo1ODo1NV0gICAgMDAwMDAwMDM0ZDhhN2U2OCAwMDAwMDA4ODgz
ODFiZjU2IGZmZmY4MzAyNGQ4YTdlNzggZmZmZjgyYzQ4MDFiZTM4OA0KKFhFTikgWzIwMTIt
MDktMDUgMTU6NTg6NTVdICAgIGZmZmY4MzAwYTUyZDkwMDAgMDAwMDAwMDAwMWM5YzM4MCBm
ZmZmODMwMjRkOGE3ZTAwIGZmZmY4MmM0ODAxYjg3MGQNCihYRU4pIFsyMDEyLTA5LTA1IDE1
OjU4OjU1XSAgICBmZmZmODMwMGE1YTcyMDAwIGZmZmY4MmM0ODAyZDgxODAgMDAwMDAwMDBm
ZmZmZmZmZiBmZmZmODJjNDgwMmQ4MDAwDQooWEVOKSBbMjAxMi0wOS0wNSAxNTo1ODo1NV0g
ICAgZmZmZjgzMDI0ZDhhN2YxOCBmZmZmZmZmZmZmZmZmZmZmIGZmZmY4MzAyNGQ4YTdlZjgg
ZmZmZjgyYzQ4MDEyNWUzMQ0KKFhFTikgWzIwMTItMDktMDUgMTU6NTg6NTVdICAgIGZmZmY4
MzAyNGQ4YTdlZDggZmZmZjgzMDBhNWE3MjAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAw
MDAwMDAwMDANCihYRU4pIFsyMDEyLTA5LTA1IDE1OjU4OjU1XSAgICAwMDAwMDAwMDAwMDAw
MDAwIDAwMDAwMDAwMDAwMDAwMDAgZmZmZjgzMDI0ZDhhN2YwOCBmZmZmODJjNDgwMTI1ZTY4
DQooWEVOKSBbMjAxMi0wOS0wNSAxNTo1ODo1NV0gICAgMDAwMDAwMDBkZTBhMWY4YSBmZmZm
ODJjNDgwMWNiNWQyIDAwMDAwMDAwMDAwMDAwMDAgZmZmZmZmZmY4MWUxMzg4MA0KKFhFTikg
WzIwMTItMDktMDUgMTU6NTg6NTVdICAgIDAwMDAwMDAwMDAwMDAwMDAgZmZmZjg4MDAwYjlj
MDBkOCBmZmZmZmZmZjgxZTAxY2U4IGZmZmY4ODAwMWZjMGIxMDANCihYRU4pIFsyMDEyLTA5
LTA1IDE1OjU4OjU1XSAgICAwMDAwMDAwMDAwMjAwMjAyIDAwMDAwMDAwMDAwMDAwMDAgMDAw
MDAwMDAwMDAwMDAwMSAwMDAwMDAwMDAwMDAwMDAwDQooWEVOKSBbMjAxMi0wOS0wNSAxNTo1
ODo1NV0gICAgMDAwMDAwMDAwMDAwMDAwMCBmZmZmZmZmZjgxMDAxMWFhIGZmZmY4ODAwMWVi
NDEwNDAgMDAwMDAwMDBkZWFkYmVlZg0KKFhFTikgWzIwMTItMDktMDUgMTU6NTg6NTVdICAg
IDAwMDAwMDAwZGVhZGJlZWYgMDAwMDAxMDAwMDAwMDAwMCBmZmZmZmZmZjgxMDAxMWFhIDAw
MDAwMDAwMDAwMGUwMzMNCihYRU4pIFsyMDEyLTA5LTA1IDE1OjU4OjU1XSAgICAwMDAwMDAw
MDAwMjAwMjAyIGZmZmZmZmZmODFlMDFjYjAgMDAwMDAwMDAwMDAwZTAyYiAwMDAwNTNmZDAw
MDBiZWVmDQooWEVOKSBbMjAxMi0wOS0wNSAxNTo1ODo1NV0gICAgODAwMDAwMDAwMDAwYmVl
ZiA3NDAwMDAwMDAwMDBiZWVmIDAwMDAwMDAwMDAxOGJlZWYgMDAwMDUzZmUwMDAwMDAwMw0K
KFhFTikgWzIwMTItMDktMDUgMTU6NTg6NTVdICAgIGZmZmY4MzAwYTUyZDkwMDAgMDAwMDAw
M2RjZDVhODY4MCAwMDAwMDAwMDAwMThlMGM5DQooWEVOKSBbMjAxMi0wOS0wNSAxNTo1ODo1
NV0gWGVuIGNhbGwgdHJhY2U6DQooWEVOKSBbMjAxMi0wOS0wNSAxNTo1ODo1NV0gICAgWzxm
ZmZmODJjNDgwMTVjOWZlPl0gY29udGV4dF9zd2l0Y2grMHgzOTQvMHhlZWINCihYRU4pIFsy
MDEyLTA5LTA1IDE1OjU4OjU1XSAgICBbPGZmZmY4MmM0ODAxMjRhNzA+XSBzY2hlZHVsZSsw
eDY2Ni8weDY3NQ0KKFhFTikgWzIwMTItMDktMDUgMTU6NTg6NTVdICAgIFs8ZmZmZjgyYzQ4
MDEyNWUzMT5dIF9fZG9fc29mdGlycSsweGE0LzB4YjUNCihYRU4pIFsyMDEyLTA5LTA1IDE1
OjU4OjU1XSAgICBbPGZmZmY4MmM0ODAxMjVlNjg+XSBkb19zb2Z0aXJxKzB4MjYvMHgyOA0K
KFhFTikgWzIwMTItMDktMDUgMTU6NTg6NTVdICAgIA0KKFhFTikgWzIwMTItMDktMDUgMTU6
NTg6NTVdIHRyYXBzLmM6MzE1OTogICBzaG93X2V4ZWN1dGlvbl9zdGF0ZShndWVzdF9jcHVf
dXNlcl9yZWdzKCkpOiANCihYRU4pIFsyMDEyLTA5LTA1IDE1OjU4OjU1XSAtLS0tWyBYZW4t
NC4yLjAtcmM0LXByZSAgeDg2XzY0ICBkZWJ1Zz15ICBOb3QgdGFpbnRlZCBdLS0tLQ0KKFhF
TikgWzIwMTItMDktMDUgMTU6NTg6NTVdIENQVTogICAgMw0KKFhFTikgWzIwMTItMDktMDUg
MTU6NTg6NTVdIFJJUDogICAgZTAzMzpbPGZmZmZmZmZmODEwMDExYWE+XQ0KKFhFTikgWzIw
MTItMDktMDUgMTU6NTg6NTVdIFJGTEFHUzogMDAwMDAwMDAwMDIwMDIwMiAgIEVNOiAxICAg
Q09OVEVYVDogcHYgZ3Vlc3QNCihYRU4pIFsyMDEyLTA5LTA1IDE1OjU4OjU1XSByYXg6IDAw
MDAwMDAwMDAwMDAwMDAgICByYng6IGZmZmY4ODAwMWZjMGIxMDAgICByY3g6IGZmZmZmZmZm
ODEwMDExYWENCihYRU4pIFsyMDEyLTA5LTA1IDE1OjU4OjU1XSByZHg6IGZmZmY4ODAwMWVi
NDEwNDAgICByc2k6IDAwMDAwMDAwZGVhZGJlZWYgICByZGk6IDAwMDAwMDAwZGVhZGJlZWYN
CihYRU4pIFsyMDEyLTA5LTA1IDE1OjU4OjU1XSByYnA6IGZmZmZmZmZmODFlMDFjZTggICBy
c3A6IGZmZmZmZmZmODFlMDFjYjAgICByODogIDAwMDAwMDAwMDAwMDAwMDANCihYRU4pIFsy
MDEyLTA5LTA1IDE1OjU4OjU1XSByOTogIDAwMDAwMDAwMDAwMDAwMDEgICByMTA6IDAwMDAw
MDAwMDAwMDAwMDAgICByMTE6IDAwMDAwMDAwMDAyMDAyMDINCihYRU4pIFsyMDEyLTA5LTA1
IDE1OjU4OjU1XSByMTI6IGZmZmY4ODAwMGI5YzAwZDggICByMTM6IDAwMDAwMDAwMDAwMDAw
MDAgICByMTQ6IGZmZmZmZmZmODFlMTM4ODANCihYRU4pIFsyMDEyLTA5LTA1IDE1OjU4OjU1
XSByMTU6IDAwMDAwMDAwMDAwMDAwMDAgICBjcjA6IDAwMDAwMDAwODAwNTAwM2IgICBjcjQ6
IDAwMDAwMDAwMDAwMDA2ZjANCihYRU4pIFsyMDEyLTA5LTA1IDE1OjU4OjU1XSBjcjM6IDAw
MDAwMDAwODA5NTcwMDAgICBjcjI6IDAwMDAwMDAwMGMyNmMwMmMNCihYRU4pIFsyMDEyLTA5
LTA1IDE1OjU4OjU1XSBkczogMDAwMCAgIGVzOiAwMDAwICAgZnM6IDAwMDAgICBnczogMDA2
MyAgIHNzOiBlMDJiICAgY3M6IGUwMzMNCihYRU4pIFsyMDEyLTA5LTA1IDE1OjU4OjU1XSBH
dWVzdCBzdGFjayB0cmFjZSBmcm9tIHJzcD1mZmZmZmZmZjgxZTAxY2IwOg0KKFhFTikgWzIw
MTItMDktMDUgMTU6NTg6NTVdICAgIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAw
MSBmZmZmZmZmZjgxMDA0OTQyIGZmZmZmZmZmODFlMTM0MjANCihYRU4pIFsyMDEyLTA5LTA1
IDE1OjU4OjU1XSAgICBmZmZmODgwMDFlYjQxMDQwIDAwMDAwMDAwMDAwMDAwMDAgZmZmZmZm
ZmY4MWUxMzg4MCBmZmZmZmZmZjgxZTAxZDA4DQooWEVOKSBbMjAxMi0wOS0wNSAxNTo1ODo1
NV0gICAgZmZmZmZmZmY4MTAwMzk0MSBmZmZmODgwMDFlYjQxMDQwIGZmZmZmZmZmODFlMTM0
MjAgZmZmZmZmZmY4MWUwMWQ2OA0KKFhFTikgWzIwMTItMDktMDUgMTU6NTg6NTVdICAgIGZm
ZmZmZmZmODEwMGI4NTAgZmZmZmZmZmY4MWUxMzQyMCAwMDAwMDAwMDAwMDAwMDAxIDAwMDAw
MDAwMDAwMDAwNjMNCihYRU4pIFsyMDEyLTA5LTA1IDE1OjU4OjU1XSAgICBmZmZmODgwMDFm
YzEwYTgwIGZmZmZmZmZmODFlMDFkNzggZmZmZjg4MDAxZmMxMmU4MCAwMDAwMDAwMDAwMDAw
MDAwDQooWEVOKSBbMjAxMi0wOS0wNSAxNTo1ODo1NV0gICAgZmZmZjg4MDAxY2NkNWY4MCAw
MDAwMDAwMDAwMDAwMDgyIGZmZmZmZmZmODEwZjAwNDAgZmZmZmZmZmY4MWUxMzQyMA0KKFhF
TikgWzIwMTItMDktMDUgMTU6NTg6NTVdICAgIGZmZmZmZmZmODE3ZmEyZjUgZmZmZmZmZmY4
MWUwMWVjOCAwMDAwMDAwMDAwMDAwMjE2IGZmZmY4ODAwMWZjMGU2OTgNCihYRU4pIFsyMDEy
LTA5LTA1IDE1OjU4OjU1XSAgICAwMDAwMDAwMDAwMDAwMDAxIGZmZmZmZmZmODFlMTM0MjAg
MDAwMDAwMDAwMDAxMmU4MCBmZmZmZmZmZjgxZTAxZmQ4DQooWEVOKSBbMjAxMi0wOS0wNSAx
NTo1ODo1NV0gICAgZmZmZmZmZmY4MWUwMDAxMCAwMDAwMDAwMDAwMDEyZTgwIDAwMDAwMDAw
MDAwMTJlODAgZmZmZmZmZmY4MWUwMWZkOA0KKFhFTikgWzIwMTItMDktMDUgMTU6NTg6NTVd
ICAgIDAwMDAwMDAwMDAwMTJlODAgZmZmZjg4MDAxZWFkMjA4MCBmZmZmZmZmZjgxZTEzNDIw
IGZmZmY4ODAwMWZjMGU4YTANCihYRU4pIFsyMDEyLTA5LTA1IDE1OjU4OjU1XSAgICAwMDAw
MDAwMDAwMDAwMDAwIGZmZmZmZmZmODFlMDFlOTggZmZmZmZmZmY4MTA4YjM4MSAwMDAwMDAw
MDAwMDAwMDAxDQooWEVOKSBbMjAxMi0wOS0wNSAxNTo1ODo1NV0gICAgZmZmZmZmZmY4MTBh
YjIyMSAwMDAwMDAwMTgxZTAxZTI4IDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDA4MWUwMWU0
OA0KKFhFTikgWzIwMTItMDktMDUgMTU6NTg6NTVdICAgIDAwMDAwMDAwMDAwMDAwNzAgMDAw
MDAwMDAxZmMwZThhMCAwMDAwMDAwMDAwMDBlNjgwIDAwMDAwMDAwMDAwMDAwMDANCihYRU4p
IFsyMDEyLTA5LTA1IDE1OjU4OjU1XSAgICBmZmZmZmZmZjgxZTEzNDIwIGZmZmZmZmZmODEw
YTg2ZmMgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwDQooWEVOKSBbMjAxMi0w
OS0wNSAxNTo1ODo1NV0gICAgMDAwMDAwMDAwMDAwMDAwMCBmZmZmZmZmZjgxZTAxZTk4IGZm
ZmZmZmZmODEwYWNiNzggZmZmZjg4MDAxZmMwZThhMA0KKFhFTikgWzIwMTItMDktMDUgMTU6
NTg6NTVdICAgIDAwMDAwMDVmYTRhMDA4NzYgZmZmZmZmZmY4MWUwMWVhOCBmZmZmZmZmZjgx
ZTAwMDEwIGZmZmZmZmZmODFlY2U1ZDgNCihYRU4pIFsyMDEyLTA5LTA1IDE1OjU4OjU1XSAg
ICBmZmZmZmZmZjgxZjQyMGMwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCBm
ZmZmZmZmZjgxZTAxZWQ4DQooWEVOKSBbMjAxMi0wOS0wNSAxNTo1ODo1NV0gICAgZmZmZmZm
ZmY4MTdmYTgxNCBmZmZmZmZmZjgxZTAxZWY4IGZmZmZmZmZmODEwMTY0NTYgMDAwMDAwMDAw
MDAwMDAwMg0KKFhFTikgWzIwMTItMDktMDUgMTU6NTg6NTVdICAgIGZmZmZmZmZmODFmMzk5
MjAgZmZmZmZmZmY4MWUwMWYyOCBmZmZmZmZmZjgxN2Q1YjhjIGZmZmZmZmZmODE3ZDVhZDAN
CihYRU4pIFsyMDEyLTA5LTA1IDE1OjU4OjU1XSAgICBmZmZmODgwMDAwMDAxMDAwIGZmZmZm
ZmZmODFlMDFmMjggMDAwMDAwMDAwMDAwMDAwMCBmZmZmZmZmZjgxZTAxZjc4DQooWEVOKSBb
MjAxMi0wOS0wNSAxOToxMTozNl0gZ3JhbnRfdGFibGUuYzoyNTQ6ZDAgSW5jcmVhc2VkIG1h
cHRyYWNrIHNpemUgdG8gMiBmcmFtZXMNCihYRU4pIFsyMDEyLTA5LTA1IDIwOjU0OjE2XSBB
TUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MGEwNiwg
ZmF1bHQgYWRkcmVzcyA9IDB4YzJjMmMyYzAsIGZsYWdzID0gMHgwMDANCihYRU4pIFsyMDEy
LTA5LTA1IDIwOjU0OjE2XSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDE0LCBk
ZXZpY2UgaWQgPSAweDA3MDAsIGZhdWx0IGFkZHJlc3MgPSAweGE4ZDMzOWUwLCBmbGFncyA9
IDB4MDIwDQooWEVOKSBbMjAxMi0wOS0wNSAyMDo1NDoxNl0gQU1ELVZpOiBJT19QQUdFX0ZB
VUxUOiBkb21haW4gPSAxNCwgZGV2aWNlIGlkID0gMHgwNzAwLCBmYXVsdCBhZGRyZXNzID0g
MHhhOGQzM2E0MCwgZmxhZ3MgPSAweDAyMA0K
------------0F617E023294CEA4E
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

------------0F617E023294CEA4E--



From xen-devel-bounces@lists.xen.org Wed Sep 05 23:00:19 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Sep 2012 23:00:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9OZb-0007D4-Tf; Wed, 05 Sep 2012 22:59:51 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <linux@eikelenboom.it>) id 1T9OZZ-0007Cz-J3
	for xen-devel@lists.xensource.com; Wed, 05 Sep 2012 22:59:50 +0000
Received: from [85.158.143.35:13701] by server-2.bemta-4.messagelabs.com id
	05/B6-21239-469D7405; Wed, 05 Sep 2012 22:59:48 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-4.tower-21.messagelabs.com!1346885981!5207701!1
X-Originating-IP: [188.40.164.121]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8280 invoked from network); 5 Sep 2012 22:59:41 -0000
Received: from static.121.164.40.188.clients.your-server.de (HELO
	smtp.eikelenboom.it) (188.40.164.121)
	by server-4.tower-21.messagelabs.com with AES256-SHA encrypted SMTP;
	5 Sep 2012 22:59:41 -0000
Received: from 128-64-ftth.onsneteindhoven.nl ([88.159.64.128]:56555
	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 1T9OZP-0000S8-H2; Thu, 06 Sep 2012 00:59:40 +0200
Date: Thu, 6 Sep 2012 00:59:36 +0200
From: Sander Eikelenboom <linux@eikelenboom.it>
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <326589347.20120906005936@eikelenboom.it>
To: Wei Wang <wei.wang2@amd.com>
In-Reply-To: <504764E2.4000809@amd.com>
References: <504764E2.4000809@amd.com>
MIME-Version: 1.0
Content-Type: multipart/mixed;
 boundary="----------0F617E023294CEA4E"
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH] amd iommu: Dump flags of IO page faults
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

------------0F617E023294CEA4E
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit


Wednesday, September 5, 2012, 4:42:42 PM, you wrote:

> Hi Jan,
> Attached patch dumps io page fault flags. The flags show the reason of 
> the fault and tell us if this is an unmapped interrupt fault or a DMA fault.

> Thanks,
> Wei

> signed-off-by: Wei Wang <wei.wang2@amd.com>


I have applied the patch and the flags seem to differ between the faults:

AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0a06, fault address = 0xc2c2c2c0, flags = 0x000
(XEN) [2012-09-05 20:54:16] AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0a06, fault address = 0xc2c2c2c0, flags = 0x000
(XEN) [2012-09-05 20:54:16] AMD-Vi: IO_PAGE_FAULT: domain = 14, device id = 0x0700, fault address = 0xa8d339e0, flags = 0x020
(XEN) [2012-09-05 20:54:16] AMD-Vi: IO_PAGE_FAULT: domain = 14, device id = 0x0700, fault address = 0xa8d33a40, flags = 0x020

Complete xl dmesg and lspci -vvvknn attached.

Thx

--
Sander
------------0F617E023294CEA4E
Content-Type: text/plain;
 name="lspci.txt"
Content-transfer-encoding: base64
Content-Disposition: attachment;
 filename="lspci.txt"

MDA6MDAuMCBIb3N0IGJyaWRnZSBbMDYwMF06IEFUSSBUZWNobm9sb2dpZXMgSW5jIFJEODkw
IE5vcnRoYnJpZGdlIG9ubHkgc2luZ2xlIHNsb3QgUENJLWUgR0ZYIEh5ZHJhIHBhcnQgWzEw
MDI6NWExMV0gKHJldiAwMikNCglTdWJzeXN0ZW06IEFUSSBUZWNobm9sb2dpZXMgSW5jIFJE
ODkwIE5vcnRoYnJpZGdlIG9ubHkgc2luZ2xlIHNsb3QgUENJLWUgR0ZYIEh5ZHJhIHBhcnQg
WzEwMDI6NWExMV0NCglDb250cm9sOiBJL08tIE1lbSsgQnVzTWFzdGVyLSBTcGVjQ3ljbGUt
IE1lbVdJTlYtIFZHQVNub29wLSBQYXJFcnItIFN0ZXBwaW5nLSBTRVJSLSBGYXN0QjJCLSBE
aXNJTlR4LQ0KCVN0YXR1czogQ2FwKyA2Nk1Iei0gVURGLSBGYXN0QjJCLSBQYXJFcnItIERF
VlNFTD1mYXN0ID5UQWJvcnQtIDxUQWJvcnQtIDxNQWJvcnQrID5TRVJSLSA8UEVSUi0gSU5U
eC0NCglDYXBhYmlsaXRpZXM6IFtmMF0gSHlwZXJUcmFuc3BvcnQ6IE1TSSBNYXBwaW5nIEVu
YWJsZSsgRml4ZWQrDQoJQ2FwYWJpbGl0aWVzOiBbYzRdIEh5cGVyVHJhbnNwb3J0OiBTbGF2
ZSBvciBQcmltYXJ5IEludGVyZmFjZQ0KCQlDb21tYW5kOiBCYXNlVW5pdElEPTAgVW5pdENu
dD0yMCBNYXN0SG9zdC0gRGVmRGlyLSBEVUwtDQoJCUxpbmsgQ29udHJvbCAwOiBDRmxFLSBD
U1QtIENGRS0gPExrRmFpbC0gSW5pdCsgRU9DLSBUWE8tIDxDUkNFcnI9MCBJc29jRW4tIExT
RW4tIEV4dENUTC0gNjRiLQ0KCQlMaW5rIENvbmZpZyAwOiBNTFdJPTE2Yml0IER3RmNJbi0g
TUxXTz0xNmJpdCBEd0ZjT3V0LSBMV0k9MTZiaXQgRHdGY0luRW4tIExXTz0xNmJpdCBEd0Zj
T3V0RW4tDQoJCUxpbmsgQ29udHJvbCAxOiBDRmxFLSBDU1QtIENGRS0gPExrRmFpbCsgSW5p
dC0gRU9DKyBUWE8rIDxDUkNFcnI9MCBJc29jRW4tIExTRW4tIEV4dENUTC0gNjRiLQ0KCQlM
aW5rIENvbmZpZyAxOiBNTFdJPThiaXQgRHdGY0luLSBNTFdPPThiaXQgRHdGY091dC0gTFdJ
PThiaXQgRHdGY0luRW4tIExXTz04Yml0IER3RmNPdXRFbi0NCgkJUmV2aXNpb24gSUQ6IDMu
MDANCgkJTGluayBGcmVxdWVuY3kgMDogW2JdDQoJCUxpbmsgRXJyb3IgMDogPFByb3QtIDxP
dmZsLSA8RU9DLSBDVExUbS0NCgkJTGluayBGcmVxdWVuY3kgQ2FwYWJpbGl0eSAwOiAyMDBN
SHorIDMwME1Iei0gNDAwTUh6KyA1MDBNSHotIDYwME1IeisgODAwTUh6KyAxLjBHSHorIDEu
MkdIeisgMS40R0h6LSAxLjZHSHotIFZlbmQtDQoJCUZlYXR1cmUgQ2FwYWJpbGl0eTogSXNv
Y0ZDKyBMRFRTVE9QKyBDUkNUTS0gRUNUTFQtIDY0YkErIFVJRFJELQ0KCQlMaW5rIEZyZXF1
ZW5jeSAxOiAyMDBNSHoNCgkJTGluayBFcnJvciAxOiA8UHJvdC0gPE92ZmwtIDxFT0MtIENU
TFRtLQ0KCQlMaW5rIEZyZXF1ZW5jeSBDYXBhYmlsaXR5IDE6IDIwME1Iei0gMzAwTUh6LSA0
MDBNSHotIDUwME1Iei0gNjAwTUh6LSA4MDBNSHotIDEuMEdIei0gMS4yR0h6LSAxLjRHSHot
IDEuNkdIei0gVmVuZC0NCgkJRXJyb3IgSGFuZGxpbmc6IFBGbEUtIE9GbEUtIFBGRS0gT0ZF
LSBFT0NGRS0gUkZFLSBDUkNGRS0gU0VSUkZFLSBDRi0gUkUtIFBORkUtIE9ORkUtIEVPQ05G
RS0gUk5GRS0gQ1JDTkZFLSBTRVJSTkZFLQ0KCQlQcmVmZXRjaGFibGUgbWVtb3J5IGJlaGlu
ZCBicmlkZ2UgVXBwZXI6IDAwLTAwDQoJCUJ1cyBOdW1iZXI6IDAwDQoJQ2FwYWJpbGl0aWVz
OiBbNDBdIEh5cGVyVHJhbnNwb3J0OiBSZXRyeSBNb2RlDQoJQ2FwYWJpbGl0aWVzOiBbNTRd
IEh5cGVyVHJhbnNwb3J0OiBVbml0SUQgQ2x1bXBpbmcNCglDYXBhYmlsaXRpZXM6IFs5Y10g
SHlwZXJUcmFuc3BvcnQ6ICMxYQ0KCUNhcGFiaWxpdGllczogWzcwXSBNU0k6IEVuYWJsZS0g
Q291bnQ9MS80IE1hc2thYmxlLSA2NGJpdC0NCgkJQWRkcmVzczogMDAwMDAwMDAgIERhdGE6
IDAwMDANCg0KMDA6MDAuMiBHZW5lcmljIHN5c3RlbSBwZXJpcGhlcmFsIFswODA2XTogQVRJ
IFRlY2hub2xvZ2llcyBJbmMgUkQ5OTAgSS9PIE1lbW9yeSBNYW5hZ2VtZW50IFVuaXQgKElP
TU1VKSBbMTAwMjo1YTIzXQ0KCVN1YnN5c3RlbTogQVRJIFRlY2hub2xvZ2llcyBJbmMgUkQ5
OTAgSS9PIE1lbW9yeSBNYW5hZ2VtZW50IFVuaXQgKElPTU1VKSBbMTAwMjo1YTIzXQ0KCUNv
bnRyb2w6IEkvTy0gTWVtLSBCdXNNYXN0ZXIrIFNwZWNDeWNsZS0gTWVtV0lOVi0gVkdBU25v
b3AtIFBhckVyci0gU3RlcHBpbmctIFNFUlItIEZhc3RCMkItIERpc0lOVHgtDQoJU3RhdHVz
OiBDYXArIDY2TUh6LSBVREYtIEZhc3RCMkItIFBhckVyci0gREVWU0VMPWZhc3QgPlRBYm9y
dC0gPFRBYm9ydC0gPE1BYm9ydC0gPlNFUlItIDxQRVJSLSBJTlR4LQ0KCUxhdGVuY3k6IDAN
CglJbnRlcnJ1cHQ6IHBpbiBBIHJvdXRlZCB0byBJUlEgMTANCglDYXBhYmlsaXRpZXM6IFs0
MF0gU2VjdXJlIGRldmljZSA8Pz4NCglDYXBhYmlsaXRpZXM6IFs1NF0gTVNJOiBFbmFibGUr
IENvdW50PTEvMSBNYXNrYWJsZS0gNjRiaXQrDQoJCUFkZHJlc3M6IDAwMDAwMDAwZmVlMDEw
MGMgIERhdGE6IDQxMjgNCglDYXBhYmlsaXRpZXM6IFs2NF0gSHlwZXJUcmFuc3BvcnQ6IE1T
SSBNYXBwaW5nIEVuYWJsZSsgRml4ZWQrDQoNCjAwOjAyLjAgUENJIGJyaWRnZSBbMDYwNF06
IEFUSSBUZWNobm9sb2dpZXMgSW5jIFJEODkwIFBDSSB0byBQQ0kgYnJpZGdlIChQQ0kgZXhw
cmVzcyBncHAgcG9ydCBCKSBbMTAwMjo1YTE2XSAocHJvZy1pZiAwMCBbTm9ybWFsIGRlY29k
ZV0pDQoJQ29udHJvbDogSS9PKyBNZW0rIEJ1c01hc3RlcisgU3BlY0N5Y2xlLSBNZW1XSU5W
LSBWR0FTbm9vcC0gUGFyRXJyLSBTdGVwcGluZy0gU0VSUisgRmFzdEIyQi0gRGlzSU5UeCsN
CglTdGF0dXM6IENhcCsgNjZNSHotIFVERi0gRmFzdEIyQi0gUGFyRXJyLSBERVZTRUw9ZmFz
dCA+VEFib3J0LSA8VEFib3J0LSA8TUFib3J0LSA+U0VSUi0gPFBFUlItIElOVHgtDQoJTGF0
ZW5jeTogMCwgQ2FjaGUgTGluZSBTaXplOiA2NCBieXRlcw0KCUJ1czogcHJpbWFyeT0wMCwg
c2Vjb25kYXJ5PTBiLCBzdWJvcmRpbmF0ZT0wYiwgc2VjLWxhdGVuY3k9MA0KCUkvTyBiZWhp
bmQgYnJpZGdlOiAwMDAwZTAwMC0wMDAwZWZmZg0KCU1lbW9yeSBiZWhpbmQgYnJpZGdlOiBm
YTAwMDAwMC1mZTlmZmZmZg0KCVByZWZldGNoYWJsZSBtZW1vcnkgYmVoaW5kIGJyaWRnZTog
MDAwMDAwMDBkMDAwMDAwMC0wMDAwMDAwMGRmZmZmZmZmDQoJU2Vjb25kYXJ5IHN0YXR1czog
NjZNSHotIEZhc3RCMkItIFBhckVyci0gREVWU0VMPWZhc3QgPlRBYm9ydC0gPFRBYm9ydC0g
PE1BYm9ydC0gPFNFUlItIDxQRVJSLQ0KCUJyaWRnZUN0bDogUGFyaXR5KyBTRVJSKyBOb0lT
QS0gVkdBKyBNQWJvcnQtID5SZXNldC0gRmFzdEIyQi0NCgkJUHJpRGlzY1Rtci0gU2VjRGlz
Y1Rtci0gRGlzY1RtclN0YXQtIERpc2NUbXJTRVJSRW4tDQoJQ2FwYWJpbGl0aWVzOiBbNTBd
IFBvd2VyIE1hbmFnZW1lbnQgdmVyc2lvbiAzDQoJCUZsYWdzOiBQTUVDbGstIERTSS0gRDEt
IEQyLSBBdXhDdXJyZW50PTBtQSBQTUUoRDArLEQxLSxEMi0sRDNob3QrLEQzY29sZCspDQoJ
CVN0YXR1czogRDAgTm9Tb2Z0UnN0LSBQTUUtRW5hYmxlLSBEU2VsPTAgRFNjYWxlPTAgUE1F
LQ0KCUNhcGFiaWxpdGllczogWzU4XSBFeHByZXNzICh2MikgUm9vdCBQb3J0IChTbG90Kyks
IE1TSSAwMA0KCQlEZXZDYXA6CU1heFBheWxvYWQgMTI4IGJ5dGVzLCBQaGFudEZ1bmMgMCwg
TGF0ZW5jeSBMMHMgPDY0bnMsIEwxIDwxdXMNCgkJCUV4dFRhZysgUkJFKyBGTFJlc2V0LQ0K
CQlEZXZDdGw6CVJlcG9ydCBlcnJvcnM6IENvcnJlY3RhYmxlLSBOb24tRmF0YWwtIEZhdGFs
LSBVbnN1cHBvcnRlZC0NCgkJCVJseGRPcmQrIEV4dFRhZy0gUGhhbnRGdW5jLSBBdXhQd3It
IE5vU25vb3ArDQoJCQlNYXhQYXlsb2FkIDEyOCBieXRlcywgTWF4UmVhZFJlcSAxMjggYnl0
ZXMNCgkJRGV2U3RhOglDb3JyRXJyLSBVbmNvcnJFcnItIEZhdGFsRXJyLSBVbnN1cHBSZXEt
IEF1eFB3ci0gVHJhbnNQZW5kLQ0KCQlMbmtDYXA6CVBvcnQgIzAsIFNwZWVkIDVHVC9zLCBX
aWR0aCB4OCwgQVNQTSBMMHMgTDEsIExhdGVuY3kgTDAgPDF1cywgTDEgPDh1cw0KCQkJQ2xv
Y2tQTS0gU3VycHJpc2UtIExMQWN0UmVwKyBCd05vdCsNCgkJTG5rQ3RsOglBU1BNIERpc2Fi
bGVkOyBSQ0IgNjQgYnl0ZXMgRGlzYWJsZWQtIFJldHJhaW4tIENvbW1DbGsrDQoJCQlFeHRT
eW5jaC0gQ2xvY2tQTS0gQXV0V2lkRGlzLSBCV0ludC0gQXV0QldJbnQtDQoJCUxua1N0YToJ
U3BlZWQgMi41R1QvcywgV2lkdGggeDgsIFRyRXJyLSBUcmFpbi0gU2xvdENsaysgRExBY3Rp
dmUrIEJXTWdtdCsgQUJXTWdtdC0NCgkJU2x0Q2FwOglBdHRuQnRuLSBQd3JDdHJsLSBNUkwt
IEF0dG5JbmQtIFB3ckluZC0gSG90UGx1Zy0gU3VycHJpc2UtDQoJCQlTbG90ICMxLCBQb3dl
ckxpbWl0IDI1LjAwMFc7IEludGVybG9jay0gTm9Db21wbCsNCgkJU2x0Q3RsOglFbmFibGU6
IEF0dG5CdG4tIFB3ckZsdC0gTVJMLSBQcmVzRGV0LSBDbWRDcGx0LSBIUElycS0gTGlua0No
Zy0NCgkJCUNvbnRyb2w6IEF0dG5JbmQgVW5rbm93biwgUHdySW5kIFVua25vd24sIFBvd2Vy
LSBJbnRlcmxvY2stDQoJCVNsdFN0YToJU3RhdHVzOiBBdHRuQnRuLSBQb3dlckZsdC0gTVJM
LSBDbWRDcGx0LSBQcmVzRGV0KyBJbnRlcmxvY2stDQoJCQlDaGFuZ2VkOiBNUkwtIFByZXNE
ZXQrIExpbmtTdGF0ZSsNCgkJUm9vdEN0bDogRXJyQ29ycmVjdGFibGUtIEVyck5vbi1GYXRh
bC0gRXJyRmF0YWwtIFBNRUludEVuYS0gQ1JTVmlzaWJsZS0NCgkJUm9vdENhcDogQ1JTVmlz
aWJsZS0NCgkJUm9vdFN0YTogUE1FIFJlcUlEIDAwMDAsIFBNRVN0YXR1cy0gUE1FUGVuZGlu
Zy0NCgkJRGV2Q2FwMjogQ29tcGxldGlvbiBUaW1lb3V0OiBSYW5nZSBBQkNELCBUaW1lb3V0
RGlzKyBBUklGd2QrDQoJCURldkN0bDI6IENvbXBsZXRpb24gVGltZW91dDogNjVtcyB0byAy
MTBtcywgVGltZW91dERpcy0gQVJJRndkLQ0KCQlMbmtDdGwyOiBUYXJnZXQgTGluayBTcGVl
ZDogNUdUL3MsIEVudGVyQ29tcGxpYW5jZS0gU3BlZWREaXMtLCBTZWxlY3RhYmxlIERlLWVt
cGhhc2lzOiAtMy41ZEINCgkJCSBUcmFuc21pdCBNYXJnaW46IE5vcm1hbCBPcGVyYXRpbmcg
UmFuZ2UsIEVudGVyTW9kaWZpZWRDb21wbGlhbmNlLSBDb21wbGlhbmNlU09TLQ0KCQkJIENv
bXBsaWFuY2UgRGUtZW1waGFzaXM6IC02ZEINCgkJTG5rU3RhMjogQ3VycmVudCBEZS1lbXBo
YXNpcyBMZXZlbDogLTMuNWRCDQoJQ2FwYWJpbGl0aWVzOiBbYTBdIE1TSTogRW5hYmxlKyBD
b3VudD0xLzEgTWFza2FibGUtIDY0Yml0LQ0KCQlBZGRyZXNzOiBmZWUzZjAwYyAgRGF0YTog
NDE1MQ0KCUNhcGFiaWxpdGllczogW2IwXSBTdWJzeXN0ZW06IEFUSSBUZWNobm9sb2dpZXMg
SW5jIERldmljZSBbMTAwMjo1YTExXQ0KCUNhcGFiaWxpdGllczogW2I4XSBIeXBlclRyYW5z
cG9ydDogTVNJIE1hcHBpbmcgRW5hYmxlKyBGaXhlZCsNCglDYXBhYmlsaXRpZXM6IFsxMDAg
djFdIFZlbmRvciBTcGVjaWZpYyBJbmZvcm1hdGlvbjogSUQ9MDAwMSBSZXY9MSBMZW49MDEw
IDw/Pg0KCUNhcGFiaWxpdGllczogWzE5MCB2MV0gQWNjZXNzIENvbnRyb2wgU2VydmljZXMN
CgkJQUNTQ2FwOglTcmNWYWxpZCsgVHJhbnNCbGsrIFJlcVJlZGlyKyBDbXBsdFJlZGlyKyBV
cHN0cmVhbUZ3ZCsgRWdyZXNzQ3RybC0gRGlyZWN0VHJhbnMrDQoJCUFDU0N0bDoJU3JjVmFs
aWQrIFRyYW5zQmxrLSBSZXFSZWRpcisgQ21wbHRSZWRpcisgVXBzdHJlYW1Gd2QrIEVncmVz
c0N0cmwtIERpcmVjdFRyYW5zLQ0KCUtlcm5lbCBkcml2ZXIgaW4gdXNlOiBwY2llcG9ydA0K
DQowMDowMy4wIFBDSSBicmlkZ2UgWzA2MDRdOiBBVEkgVGVjaG5vbG9naWVzIEluYyBSRDg5
MCBQQ0kgdG8gUENJIGJyaWRnZSAoUENJIGV4cHJlc3MgZ3BwIHBvcnQgQykgWzEwMDI6NWEx
N10gKHByb2ctaWYgMDAgW05vcm1hbCBkZWNvZGVdKQ0KCUNvbnRyb2w6IEkvTy0gTWVtKyBC
dXNNYXN0ZXIrIFNwZWNDeWNsZS0gTWVtV0lOVi0gVkdBU25vb3AtIFBhckVyci0gU3RlcHBp
bmctIFNFUlIrIEZhc3RCMkItIERpc0lOVHgrDQoJU3RhdHVzOiBDYXArIDY2TUh6LSBVREYt
IEZhc3RCMkItIFBhckVyci0gREVWU0VMPWZhc3QgPlRBYm9ydC0gPFRBYm9ydCsgPE1BYm9y
dC0gPlNFUlItIDxQRVJSLSBJTlR4LQ0KCUxhdGVuY3k6IDAsIENhY2hlIExpbmUgU2l6ZTog
NjQgYnl0ZXMNCglCdXM6IHByaW1hcnk9MDAsIHNlY29uZGFyeT0wYSwgc3Vib3JkaW5hdGU9
MGEsIHNlYy1sYXRlbmN5PTANCglJL08gYmVoaW5kIGJyaWRnZTogMDAwMGYwMDAtMDAwMDBm
ZmYNCglNZW1vcnkgYmVoaW5kIGJyaWRnZTogZjlmMDAwMDAtZjlmZmZmZmYNCglQcmVmZXRj
aGFibGUgbWVtb3J5IGJlaGluZCBicmlkZ2U6IDAwMDAwMDAwZmZmMDAwMDAtMDAwMDAwMDAw
MDBmZmZmZg0KCVNlY29uZGFyeSBzdGF0dXM6IDY2TUh6LSBGYXN0QjJCLSBQYXJFcnItIERF
VlNFTD1mYXN0ID5UQWJvcnQrIDxUQWJvcnQtIDxNQWJvcnQtIDxTRVJSLSA8UEVSUi0NCglC
cmlkZ2VDdGw6IFBhcml0eSsgU0VSUisgTm9JU0ErIFZHQS0gTUFib3J0LSA+UmVzZXQtIEZh
c3RCMkItDQoJCVByaURpc2NUbXItIFNlY0Rpc2NUbXItIERpc2NUbXJTdGF0LSBEaXNjVG1y
U0VSUkVuLQ0KCUNhcGFiaWxpdGllczogWzUwXSBQb3dlciBNYW5hZ2VtZW50IHZlcnNpb24g
Mw0KCQlGbGFnczogUE1FQ2xrLSBEU0ktIEQxLSBEMi0gQXV4Q3VycmVudD0wbUEgUE1FKEQw
KyxEMS0sRDItLEQzaG90KyxEM2NvbGQrKQ0KCQlTdGF0dXM6IEQwIE5vU29mdFJzdC0gUE1F
LUVuYWJsZS0gRFNlbD0wIERTY2FsZT0wIFBNRS0NCglDYXBhYmlsaXRpZXM6IFs1OF0gRXhw
cmVzcyAodjIpIFJvb3QgUG9ydCAoU2xvdCspLCBNU0kgMDANCgkJRGV2Q2FwOglNYXhQYXls
b2FkIDEyOCBieXRlcywgUGhhbnRGdW5jIDAsIExhdGVuY3kgTDBzIDw2NG5zLCBMMSA8MXVz
DQoJCQlFeHRUYWcrIFJCRSsgRkxSZXNldC0NCgkJRGV2Q3RsOglSZXBvcnQgZXJyb3JzOiBD
b3JyZWN0YWJsZS0gTm9uLUZhdGFsLSBGYXRhbC0gVW5zdXBwb3J0ZWQtDQoJCQlSbHhkT3Jk
KyBFeHRUYWctIFBoYW50RnVuYy0gQXV4UHdyLSBOb1Nub29wKw0KCQkJTWF4UGF5bG9hZCAx
MjggYnl0ZXMsIE1heFJlYWRSZXEgMTI4IGJ5dGVzDQoJCURldlN0YToJQ29yckVyci0gVW5j
b3JyRXJyLSBGYXRhbEVyci0gVW5zdXBwUmVxLSBBdXhQd3ItIFRyYW5zUGVuZC0NCgkJTG5r
Q2FwOglQb3J0ICMxLCBTcGVlZCA1R1QvcywgV2lkdGggeDgsIEFTUE0gTDBzIEwxLCBMYXRl
bmN5IEwwIDwxdXMsIEwxIDw4dXMNCgkJCUNsb2NrUE0tIFN1cnByaXNlLSBMTEFjdFJlcCsg
QndOb3QrDQoJCUxua0N0bDoJQVNQTSBEaXNhYmxlZDsgUkNCIDY0IGJ5dGVzIERpc2FibGVk
LSBSZXRyYWluLSBDb21tQ2xrLQ0KCQkJRXh0U3luY2gtIENsb2NrUE0tIEF1dFdpZERpcy0g
QldJbnQtIEF1dEJXSW50LQ0KCQlMbmtTdGE6CVNwZWVkIDIuNUdUL3MsIFdpZHRoIHgxLCBU
ckVyci0gVHJhaW4tIFNsb3RDbGsrIERMQWN0aXZlKyBCV01nbXQrIEFCV01nbXQtDQoJCVNs
dENhcDoJQXR0bkJ0bi0gUHdyQ3RybC0gTVJMLSBBdHRuSW5kLSBQd3JJbmQtIEhvdFBsdWct
IFN1cnByaXNlLQ0KCQkJU2xvdCAjMywgUG93ZXJMaW1pdCAxMC4wMDBXOyBJbnRlcmxvY2st
IE5vQ29tcGwrDQoJCVNsdEN0bDoJRW5hYmxlOiBBdHRuQnRuLSBQd3JGbHQtIE1STC0gUHJl
c0RldC0gQ21kQ3BsdC0gSFBJcnEtIExpbmtDaGctDQoJCQlDb250cm9sOiBBdHRuSW5kIFVu
a25vd24sIFB3ckluZCBVbmtub3duLCBQb3dlci0gSW50ZXJsb2NrLQ0KCQlTbHRTdGE6CVN0
YXR1czogQXR0bkJ0bi0gUG93ZXJGbHQtIE1STC0gQ21kQ3BsdC0gUHJlc0RldCsgSW50ZXJs
b2NrLQ0KCQkJQ2hhbmdlZDogTVJMLSBQcmVzRGV0KyBMaW5rU3RhdGUrDQoJCVJvb3RDdGw6
IEVyckNvcnJlY3RhYmxlLSBFcnJOb24tRmF0YWwtIEVyckZhdGFsLSBQTUVJbnRFbmEtIENS
U1Zpc2libGUtDQoJCVJvb3RDYXA6IENSU1Zpc2libGUtDQoJCVJvb3RTdGE6IFBNRSBSZXFJ
RCAwMDAwLCBQTUVTdGF0dXMtIFBNRVBlbmRpbmctDQoJCURldkNhcDI6IENvbXBsZXRpb24g
VGltZW91dDogUmFuZ2UgQUJDRCwgVGltZW91dERpcysgQVJJRndkKw0KCQlEZXZDdGwyOiBD
b21wbGV0aW9uIFRpbWVvdXQ6IDY1bXMgdG8gMjEwbXMsIFRpbWVvdXREaXMtIEFSSUZ3ZC0N
CgkJTG5rQ3RsMjogVGFyZ2V0IExpbmsgU3BlZWQ6IDVHVC9zLCBFbnRlckNvbXBsaWFuY2Ut
IFNwZWVkRGlzLSwgU2VsZWN0YWJsZSBEZS1lbXBoYXNpczogLTMuNWRCDQoJCQkgVHJhbnNt
aXQgTWFyZ2luOiBOb3JtYWwgT3BlcmF0aW5nIFJhbmdlLCBFbnRlck1vZGlmaWVkQ29tcGxp
YW5jZS0gQ29tcGxpYW5jZVNPUy0NCgkJCSBDb21wbGlhbmNlIERlLWVtcGhhc2lzOiAtNmRC
DQoJCUxua1N0YTI6IEN1cnJlbnQgRGUtZW1waGFzaXMgTGV2ZWw6IC0zLjVkQg0KCUNhcGFi
aWxpdGllczogW2EwXSBNU0k6IEVuYWJsZSsgQ291bnQ9MS8xIE1hc2thYmxlLSA2NGJpdC0N
CgkJQWRkcmVzczogZmVlM2YwMGMgIERhdGE6IDQxNTkNCglDYXBhYmlsaXRpZXM6IFtiMF0g
U3Vic3lzdGVtOiBBVEkgVGVjaG5vbG9naWVzIEluYyBEZXZpY2UgWzEwMDI6NWExMV0NCglD
YXBhYmlsaXRpZXM6IFtiOF0gSHlwZXJUcmFuc3BvcnQ6IE1TSSBNYXBwaW5nIEVuYWJsZSsg
Rml4ZWQrDQoJQ2FwYWJpbGl0aWVzOiBbMTAwIHYxXSBWZW5kb3IgU3BlY2lmaWMgSW5mb3Jt
YXRpb246IElEPTAwMDEgUmV2PTEgTGVuPTAxMCA8Pz4NCglDYXBhYmlsaXRpZXM6IFsxOTAg
djFdIEFjY2VzcyBDb250cm9sIFNlcnZpY2VzDQoJCUFDU0NhcDoJU3JjVmFsaWQrIFRyYW5z
QmxrKyBSZXFSZWRpcisgQ21wbHRSZWRpcisgVXBzdHJlYW1Gd2QrIEVncmVzc0N0cmwtIERp
cmVjdFRyYW5zKw0KCQlBQ1NDdGw6CVNyY1ZhbGlkKyBUcmFuc0Jsay0gUmVxUmVkaXIrIENt
cGx0UmVkaXIrIFVwc3RyZWFtRndkKyBFZ3Jlc3NDdHJsLSBEaXJlY3RUcmFucy0NCglLZXJu
ZWwgZHJpdmVyIGluIHVzZTogcGNpZXBvcnQNCg0KMDA6MDUuMCBQQ0kgYnJpZGdlIFswNjA0
XTogQVRJIFRlY2hub2xvZ2llcyBJbmMgUkQ4OTAgUENJIHRvIFBDSSBicmlkZ2UgKFBDSSBl
eHByZXNzIGdwcCBwb3J0IEUpIFsxMDAyOjVhMTldIChwcm9nLWlmIDAwIFtOb3JtYWwgZGVj
b2RlXSkNCglDb250cm9sOiBJL08rIE1lbSsgQnVzTWFzdGVyKyBTcGVjQ3ljbGUtIE1lbVdJ
TlYtIFZHQVNub29wLSBQYXJFcnItIFN0ZXBwaW5nLSBTRVJSKyBGYXN0QjJCLSBEaXNJTlR4
Kw0KCVN0YXR1czogQ2FwKyA2Nk1Iei0gVURGLSBGYXN0QjJCLSBQYXJFcnItIERFVlNFTD1m
YXN0ID5UQWJvcnQtIDxUQWJvcnQtIDxNQWJvcnQtID5TRVJSLSA8UEVSUi0gSU5UeC0NCglM
YXRlbmN5OiAwLCBDYWNoZSBMaW5lIFNpemU6IDY0IGJ5dGVzDQoJQnVzOiBwcmltYXJ5PTAw
LCBzZWNvbmRhcnk9MDksIHN1Ym9yZGluYXRlPTA5LCBzZWMtbGF0ZW5jeT0wDQoJSS9PIGJl
aGluZCBicmlkZ2U6IDAwMDBkMDAwLTAwMDBkZmZmDQoJTWVtb3J5IGJlaGluZCBicmlkZ2U6
IGY5ZTAwMDAwLWY5ZWZmZmZmDQoJUHJlZmV0Y2hhYmxlIG1lbW9yeSBiZWhpbmQgYnJpZGdl
OiAwMDAwMDAwMGNmZjAwMDAwLTAwMDAwMDAwY2ZmZmZmZmYNCglTZWNvbmRhcnkgc3RhdHVz
OiA2Nk1Iei0gRmFzdEIyQi0gUGFyRXJyLSBERVZTRUw9ZmFzdCA+VEFib3J0LSA8VEFib3J0
LSA8TUFib3J0LSA8U0VSUi0gPFBFUlItDQoJQnJpZGdlQ3RsOiBQYXJpdHkrIFNFUlIrIE5v
SVNBKyBWR0EtIE1BYm9ydC0gPlJlc2V0LSBGYXN0QjJCLQ0KCQlQcmlEaXNjVG1yLSBTZWNE
aXNjVG1yLSBEaXNjVG1yU3RhdC0gRGlzY1RtclNFUlJFbi0NCglDYXBhYmlsaXRpZXM6IFs1
MF0gUG93ZXIgTWFuYWdlbWVudCB2ZXJzaW9uIDMNCgkJRmxhZ3M6IFBNRUNsay0gRFNJLSBE
MS0gRDItIEF1eEN1cnJlbnQ9MG1BIFBNRShEMCssRDEtLEQyLSxEM2hvdCssRDNjb2xkKykN
CgkJU3RhdHVzOiBEMCBOb1NvZnRSc3QtIFBNRS1FbmFibGUtIERTZWw9MCBEU2NhbGU9MCBQ
TUUtDQoJQ2FwYWJpbGl0aWVzOiBbNThdIEV4cHJlc3MgKHYyKSBSb290IFBvcnQgKFNsb3Qr
KSwgTVNJIDAwDQoJCURldkNhcDoJTWF4UGF5bG9hZCAxMjggYnl0ZXMsIFBoYW50RnVuYyAw
LCBMYXRlbmN5IEwwcyA8NjRucywgTDEgPDF1cw0KCQkJRXh0VGFnKyBSQkUrIEZMUmVzZXQt
DQoJCURldkN0bDoJUmVwb3J0IGVycm9yczogQ29ycmVjdGFibGUtIE5vbi1GYXRhbC0gRmF0
YWwtIFVuc3VwcG9ydGVkLQ0KCQkJUmx4ZE9yZCsgRXh0VGFnLSBQaGFudEZ1bmMtIEF1eFB3
ci0gTm9Tbm9vcCsNCgkJCU1heFBheWxvYWQgMTI4IGJ5dGVzLCBNYXhSZWFkUmVxIDEyOCBi
eXRlcw0KCQlEZXZTdGE6CUNvcnJFcnItIFVuY29yckVyci0gRmF0YWxFcnItIFVuc3VwcFJl
cS0gQXV4UHdyLSBUcmFuc1BlbmQtDQoJCUxua0NhcDoJUG9ydCAjMSwgU3BlZWQgNUdUL3Ms
IFdpZHRoIHgxLCBBU1BNIEwwcyBMMSwgTGF0ZW5jeSBMMCA8MXVzLCBMMSA8OHVzDQoJCQlD
bG9ja1BNLSBTdXJwcmlzZS0gTExBY3RSZXArIEJ3Tm90Kw0KCQlMbmtDdGw6CUFTUE0gRGlz
YWJsZWQ7IFJDQiA2NCBieXRlcyBEaXNhYmxlZC0gUmV0cmFpbi0gQ29tbUNsaysNCgkJCUV4
dFN5bmNoLSBDbG9ja1BNLSBBdXRXaWREaXMtIEJXSW50LSBBdXRCV0ludC0NCgkJTG5rU3Rh
OglTcGVlZCAyLjVHVC9zLCBXaWR0aCB4MSwgVHJFcnItIFRyYWluLSBTbG90Q2xrKyBETEFj
dGl2ZSsgQldNZ210KyBBQldNZ210LQ0KCQlTbHRDYXA6CUF0dG5CdG4tIFB3ckN0cmwtIE1S
TC0gQXR0bkluZC0gUHdySW5kLSBIb3RQbHVnLSBTdXJwcmlzZS0NCgkJCVNsb3QgIzUsIFBv
d2VyTGltaXQgNzUuMDAwVzsgSW50ZXJsb2NrLSBOb0NvbXBsKw0KCQlTbHRDdGw6CUVuYWJs
ZTogQXR0bkJ0bi0gUHdyRmx0LSBNUkwtIFByZXNEZXQtIENtZENwbHQtIEhQSXJxLSBMaW5r
Q2hnLQ0KCQkJQ29udHJvbDogQXR0bkluZCBVbmtub3duLCBQd3JJbmQgVW5rbm93biwgUG93
ZXItIEludGVybG9jay0NCgkJU2x0U3RhOglTdGF0dXM6IEF0dG5CdG4tIFBvd2VyRmx0LSBN
UkwtIENtZENwbHQtIFByZXNEZXQrIEludGVybG9jay0NCgkJCUNoYW5nZWQ6IE1STC0gUHJl
c0RldCsgTGlua1N0YXRlKw0KCQlSb290Q3RsOiBFcnJDb3JyZWN0YWJsZS0gRXJyTm9uLUZh
dGFsLSBFcnJGYXRhbC0gUE1FSW50RW5hLSBDUlNWaXNpYmxlLQ0KCQlSb290Q2FwOiBDUlNW
aXNpYmxlLQ0KCQlSb290U3RhOiBQTUUgUmVxSUQgMDAwMCwgUE1FU3RhdHVzLSBQTUVQZW5k
aW5nLQ0KCQlEZXZDYXAyOiBDb21wbGV0aW9uIFRpbWVvdXQ6IFJhbmdlIEFCQ0QsIFRpbWVv
dXREaXMrIEFSSUZ3ZCsNCgkJRGV2Q3RsMjogQ29tcGxldGlvbiBUaW1lb3V0OiA2NW1zIHRv
IDIxMG1zLCBUaW1lb3V0RGlzLSBBUklGd2QtDQoJCUxua0N0bDI6IFRhcmdldCBMaW5rIFNw
ZWVkOiA1R1QvcywgRW50ZXJDb21wbGlhbmNlLSBTcGVlZERpcy0sIFNlbGVjdGFibGUgRGUt
ZW1waGFzaXM6IC0zLjVkQg0KCQkJIFRyYW5zbWl0IE1hcmdpbjogTm9ybWFsIE9wZXJhdGlu
ZyBSYW5nZSwgRW50ZXJNb2RpZmllZENvbXBsaWFuY2UtIENvbXBsaWFuY2VTT1MtDQoJCQkg
Q29tcGxpYW5jZSBEZS1lbXBoYXNpczogLTZkQg0KCQlMbmtTdGEyOiBDdXJyZW50IERlLWVt
cGhhc2lzIExldmVsOiAtMy41ZEINCglDYXBhYmlsaXRpZXM6IFthMF0gTVNJOiBFbmFibGUr
IENvdW50PTEvMSBNYXNrYWJsZS0gNjRiaXQtDQoJCUFkZHJlc3M6IGZlZTNmMDBjICBEYXRh
OiA0MTYxDQoJQ2FwYWJpbGl0aWVzOiBbYjBdIFN1YnN5c3RlbTogQVRJIFRlY2hub2xvZ2ll
cyBJbmMgRGV2aWNlIFsxMDAyOjVhMTFdDQoJQ2FwYWJpbGl0aWVzOiBbYjhdIEh5cGVyVHJh
bnNwb3J0OiBNU0kgTWFwcGluZyBFbmFibGUrIEZpeGVkKw0KCUNhcGFiaWxpdGllczogWzEw
MCB2MV0gVmVuZG9yIFNwZWNpZmljIEluZm9ybWF0aW9uOiBJRD0wMDAxIFJldj0xIExlbj0w
MTAgPD8+DQoJQ2FwYWJpbGl0aWVzOiBbMTkwIHYxXSBBY2Nlc3MgQ29udHJvbCBTZXJ2aWNl
cw0KCQlBQ1NDYXA6CVNyY1ZhbGlkKyBUcmFuc0JsaysgUmVxUmVkaXIrIENtcGx0UmVkaXIr
IFVwc3RyZWFtRndkKyBFZ3Jlc3NDdHJsLSBEaXJlY3RUcmFucysNCgkJQUNTQ3RsOglTcmNW
YWxpZCsgVHJhbnNCbGstIFJlcVJlZGlyKyBDbXBsdFJlZGlyKyBVcHN0cmVhbUZ3ZCsgRWdy
ZXNzQ3RybC0gRGlyZWN0VHJhbnMtDQoJS2VybmVsIGRyaXZlciBpbiB1c2U6IHBjaWVwb3J0
DQoNCjAwOjA2LjAgUENJIGJyaWRnZSBbMDYwNF06IEFUSSBUZWNobm9sb2dpZXMgSW5jIFJE
ODkwIFBDSSB0byBQQ0kgYnJpZGdlIChQQ0kgZXhwcmVzcyBncHAgcG9ydCBGKSBbMTAwMjo1
YTFhXSAocHJvZy1pZiAwMCBbTm9ybWFsIGRlY29kZV0pDQoJQ29udHJvbDogSS9PKyBNZW0r
IEJ1c01hc3RlcisgU3BlY0N5Y2xlLSBNZW1XSU5WLSBWR0FTbm9vcC0gUGFyRXJyLSBTdGVw
cGluZy0gU0VSUisgRmFzdEIyQi0gRGlzSU5UeCsNCglTdGF0dXM6IENhcCsgNjZNSHotIFVE
Ri0gRmFzdEIyQi0gUGFyRXJyLSBERVZTRUw9ZmFzdCA+VEFib3J0LSA8VEFib3J0LSA8TUFi
b3J0LSA+U0VSUi0gPFBFUlItIElOVHgtDQoJTGF0ZW5jeTogMCwgQ2FjaGUgTGluZSBTaXpl
OiA2NCBieXRlcw0KCUJ1czogcHJpbWFyeT0wMCwgc2Vjb25kYXJ5PTA4LCBzdWJvcmRpbmF0
ZT0wOCwgc2VjLWxhdGVuY3k9MA0KCUkvTyBiZWhpbmQgYnJpZGdlOiAwMDAwYzAwMC0wMDAw
Y2ZmZg0KCU1lbW9yeSBiZWhpbmQgYnJpZGdlOiBmOWQwMDAwMC1mOWRmZmZmZg0KCVByZWZl
dGNoYWJsZSBtZW1vcnkgYmVoaW5kIGJyaWRnZTogMDAwMDAwMDBjZmUwMDAwMC0wMDAwMDAw
MGNmZWZmZmZmDQoJU2Vjb25kYXJ5IHN0YXR1czogNjZNSHotIEZhc3RCMkItIFBhckVyci0g
REVWU0VMPWZhc3QgPlRBYm9ydC0gPFRBYm9ydC0gPE1BYm9ydC0gPFNFUlItIDxQRVJSLQ0K
CUJyaWRnZUN0bDogUGFyaXR5KyBTRVJSKyBOb0lTQSsgVkdBLSBNQWJvcnQtID5SZXNldC0g
RmFzdEIyQi0NCgkJUHJpRGlzY1Rtci0gU2VjRGlzY1Rtci0gRGlzY1RtclN0YXQtIERpc2NU
bXJTRVJSRW4tDQoJQ2FwYWJpbGl0aWVzOiBbNTBdIFBvd2VyIE1hbmFnZW1lbnQgdmVyc2lv
biAzDQoJCUZsYWdzOiBQTUVDbGstIERTSS0gRDEtIEQyLSBBdXhDdXJyZW50PTBtQSBQTUUo
RDArLEQxLSxEMi0sRDNob3QrLEQzY29sZCspDQoJCVN0YXR1czogRDAgTm9Tb2Z0UnN0LSBQ
TUUtRW5hYmxlLSBEU2VsPTAgRFNjYWxlPTAgUE1FLQ0KCUNhcGFiaWxpdGllczogWzU4XSBF
eHByZXNzICh2MikgUm9vdCBQb3J0IChTbG90KyksIE1TSSAwMA0KCQlEZXZDYXA6CU1heFBh
eWxvYWQgMTI4IGJ5dGVzLCBQaGFudEZ1bmMgMCwgTGF0ZW5jeSBMMHMgPDY0bnMsIEwxIDwx
dXMNCgkJCUV4dFRhZysgUkJFKyBGTFJlc2V0LQ0KCQlEZXZDdGw6CVJlcG9ydCBlcnJvcnM6
IENvcnJlY3RhYmxlLSBOb24tRmF0YWwtIEZhdGFsLSBVbnN1cHBvcnRlZC0NCgkJCVJseGRP
cmQrIEV4dFRhZy0gUGhhbnRGdW5jLSBBdXhQd3ItIE5vU25vb3ArDQoJCQlNYXhQYXlsb2Fk
IDEyOCBieXRlcywgTWF4UmVhZFJlcSAxMjggYnl0ZXMNCgkJRGV2U3RhOglDb3JyRXJyLSBV
bmNvcnJFcnItIEZhdGFsRXJyLSBVbnN1cHBSZXEtIEF1eFB3ci0gVHJhbnNQZW5kLQ0KCQlM
bmtDYXA6CVBvcnQgIzIsIFNwZWVkIDVHVC9zLCBXaWR0aCB4MSwgQVNQTSBMMHMgTDEsIExh
dGVuY3kgTDAgPDF1cywgTDEgPDh1cw0KCQkJQ2xvY2tQTS0gU3VycHJpc2UtIExMQWN0UmVw
KyBCd05vdCsNCgkJTG5rQ3RsOglBU1BNIERpc2FibGVkOyBSQ0IgNjQgYnl0ZXMgRGlzYWJs
ZWQtIFJldHJhaW4tIENvbW1DbGsrDQoJCQlFeHRTeW5jaC0gQ2xvY2tQTS0gQXV0V2lkRGlz
LSBCV0ludC0gQXV0QldJbnQtDQoJCUxua1N0YToJU3BlZWQgMi41R1QvcywgV2lkdGggeDEs
IFRyRXJyLSBUcmFpbi0gU2xvdENsaysgRExBY3RpdmUrIEJXTWdtdCsgQUJXTWdtdC0NCgkJ
U2x0Q2FwOglBdHRuQnRuLSBQd3JDdHJsLSBNUkwtIEF0dG5JbmQtIFB3ckluZC0gSG90UGx1
Zy0gU3VycHJpc2UtDQoJCQlTbG90ICM2LCBQb3dlckxpbWl0IDc1LjAwMFc7IEludGVybG9j
ay0gTm9Db21wbCsNCgkJU2x0Q3RsOglFbmFibGU6IEF0dG5CdG4tIFB3ckZsdC0gTVJMLSBQ
cmVzRGV0LSBDbWRDcGx0LSBIUElycS0gTGlua0NoZy0NCgkJCUNvbnRyb2w6IEF0dG5JbmQg
VW5rbm93biwgUHdySW5kIFVua25vd24sIFBvd2VyLSBJbnRlcmxvY2stDQoJCVNsdFN0YToJ
U3RhdHVzOiBBdHRuQnRuLSBQb3dlckZsdC0gTVJMLSBDbWRDcGx0LSBQcmVzRGV0KyBJbnRl
cmxvY2stDQoJCQlDaGFuZ2VkOiBNUkwtIFByZXNEZXQrIExpbmtTdGF0ZSsNCgkJUm9vdEN0
bDogRXJyQ29ycmVjdGFibGUtIEVyck5vbi1GYXRhbC0gRXJyRmF0YWwtIFBNRUludEVuYS0g
Q1JTVmlzaWJsZS0NCgkJUm9vdENhcDogQ1JTVmlzaWJsZS0NCgkJUm9vdFN0YTogUE1FIFJl
cUlEIDAwMDAsIFBNRVN0YXR1cy0gUE1FUGVuZGluZy0NCgkJRGV2Q2FwMjogQ29tcGxldGlv
biBUaW1lb3V0OiBSYW5nZSBBQkNELCBUaW1lb3V0RGlzKyBBUklGd2QrDQoJCURldkN0bDI6
IENvbXBsZXRpb24gVGltZW91dDogNjVtcyB0byAyMTBtcywgVGltZW91dERpcy0gQVJJRndk
LQ0KCQlMbmtDdGwyOiBUYXJnZXQgTGluayBTcGVlZDogNUdUL3MsIEVudGVyQ29tcGxpYW5j
ZS0gU3BlZWREaXMtLCBTZWxlY3RhYmxlIERlLWVtcGhhc2lzOiAtMy41ZEINCgkJCSBUcmFu
c21pdCBNYXJnaW46IE5vcm1hbCBPcGVyYXRpbmcgUmFuZ2UsIEVudGVyTW9kaWZpZWRDb21w
bGlhbmNlLSBDb21wbGlhbmNlU09TLQ0KCQkJIENvbXBsaWFuY2UgRGUtZW1waGFzaXM6IC02
ZEINCgkJTG5rU3RhMjogQ3VycmVudCBEZS1lbXBoYXNpcyBMZXZlbDogLTMuNWRCDQoJQ2Fw
YWJpbGl0aWVzOiBbYTBdIE1TSTogRW5hYmxlKyBDb3VudD0xLzEgTWFza2FibGUtIDY0Yml0
LQ0KCQlBZGRyZXNzOiBmZWUzZjAwYyAgRGF0YTogNDE2OQ0KCUNhcGFiaWxpdGllczogW2Iw
XSBTdWJzeXN0ZW06IEFUSSBUZWNobm9sb2dpZXMgSW5jIERldmljZSBbMTAwMjo1YTExXQ0K
CUNhcGFiaWxpdGllczogW2I4XSBIeXBlclRyYW5zcG9ydDogTVNJIE1hcHBpbmcgRW5hYmxl
KyBGaXhlZCsNCglDYXBhYmlsaXRpZXM6IFsxMDAgdjFdIFZlbmRvciBTcGVjaWZpYyBJbmZv
cm1hdGlvbjogSUQ9MDAwMSBSZXY9MSBMZW49MDEwIDw/Pg0KCUNhcGFiaWxpdGllczogWzE5
MCB2MV0gQWNjZXNzIENvbnRyb2wgU2VydmljZXMNCgkJQUNTQ2FwOglTcmNWYWxpZCsgVHJh
bnNCbGsrIFJlcVJlZGlyKyBDbXBsdFJlZGlyKyBVcHN0cmVhbUZ3ZCsgRWdyZXNzQ3RybC0g
RGlyZWN0VHJhbnMrDQoJCUFDU0N0bDoJU3JjVmFsaWQrIFRyYW5zQmxrLSBSZXFSZWRpcisg
Q21wbHRSZWRpcisgVXBzdHJlYW1Gd2QrIEVncmVzc0N0cmwtIERpcmVjdFRyYW5zLQ0KCUtl
cm5lbCBkcml2ZXIgaW4gdXNlOiBwY2llcG9ydA0KDQowMDowYS4wIFBDSSBicmlkZ2UgWzA2
MDRdOiBBVEkgVGVjaG5vbG9naWVzIEluYyBSRDg5MCBQQ0kgdG8gUENJIGJyaWRnZSAoZXh0
ZXJuYWwgZ2Z4MSBwb3J0IEEpIFsxMDAyOjVhMWRdIChwcm9nLWlmIDAwIFtOb3JtYWwgZGVj
b2RlXSkNCglDb250cm9sOiBJL08tIE1lbSsgQnVzTWFzdGVyKyBTcGVjQ3ljbGUtIE1lbVdJ
TlYtIFZHQVNub29wLSBQYXJFcnItIFN0ZXBwaW5nLSBTRVJSKyBGYXN0QjJCLSBEaXNJTlR4
Kw0KCVN0YXR1czogQ2FwKyA2Nk1Iei0gVURGLSBGYXN0QjJCLSBQYXJFcnItIERFVlNFTD1m
YXN0ID5UQWJvcnQtIDxUQWJvcnQtIDxNQWJvcnQtID5TRVJSLSA8UEVSUi0gSU5UeC0NCglM
YXRlbmN5OiAwLCBDYWNoZSBMaW5lIFNpemU6IDY0IGJ5dGVzDQoJQnVzOiBwcmltYXJ5PTAw
LCBzZWNvbmRhcnk9MDcsIHN1Ym9yZGluYXRlPTA3LCBzZWMtbGF0ZW5jeT0wDQoJSS9PIGJl
aGluZCBicmlkZ2U6IDAwMDBmMDAwLTAwMDAwZmZmDQoJTWVtb3J5IGJlaGluZCBicmlkZ2U6
IGY5YTAwMDAwLWY5YmZmZmZmDQoJUHJlZmV0Y2hhYmxlIG1lbW9yeSBiZWhpbmQgYnJpZGdl
OiAwMDAwMDAwMGZmZjAwMDAwLTAwMDAwMDAwMDAwZmZmZmYNCglTZWNvbmRhcnkgc3RhdHVz
OiA2Nk1Iei0gRmFzdEIyQi0gUGFyRXJyLSBERVZTRUw9ZmFzdCA+VEFib3J0LSA8VEFib3J0
LSA8TUFib3J0KyA8U0VSUi0gPFBFUlItDQoJQnJpZGdlQ3RsOiBQYXJpdHkrIFNFUlIrIE5v
SVNBKyBWR0EtIE1BYm9ydC0gPlJlc2V0LSBGYXN0QjJCLQ0KCQlQcmlEaXNjVG1yLSBTZWNE
aXNjVG1yLSBEaXNjVG1yU3RhdC0gRGlzY1RtclNFUlJFbi0NCglDYXBhYmlsaXRpZXM6IFs1
MF0gUG93ZXIgTWFuYWdlbWVudCB2ZXJzaW9uIDMNCgkJRmxhZ3M6IFBNRUNsay0gRFNJLSBE
MS0gRDItIEF1eEN1cnJlbnQ9MG1BIFBNRShEMCssRDEtLEQyLSxEM2hvdCssRDNjb2xkKykN
CgkJU3RhdHVzOiBEMCBOb1NvZnRSc3QtIFBNRS1FbmFibGUtIERTZWw9MCBEU2NhbGU9MCBQ
TUUtDQoJQ2FwYWJpbGl0aWVzOiBbNThdIEV4cHJlc3MgKHYyKSBSb290IFBvcnQgKFNsb3Qr
KSwgTVNJIDAwDQoJCURldkNhcDoJTWF4UGF5bG9hZCAxMjggYnl0ZXMsIFBoYW50RnVuYyAw
LCBMYXRlbmN5IEwwcyA8NjRucywgTDEgPDF1cw0KCQkJRXh0VGFnKyBSQkUrIEZMUmVzZXQt
DQoJCURldkN0bDoJUmVwb3J0IGVycm9yczogQ29ycmVjdGFibGUtIE5vbi1GYXRhbC0gRmF0
YWwtIFVuc3VwcG9ydGVkLQ0KCQkJUmx4ZE9yZCsgRXh0VGFnLSBQaGFudEZ1bmMtIEF1eFB3
ci0gTm9Tbm9vcCsNCgkJCU1heFBheWxvYWQgMTI4IGJ5dGVzLCBNYXhSZWFkUmVxIDEyOCBi
eXRlcw0KCQlEZXZTdGE6CUNvcnJFcnItIFVuY29yckVyci0gRmF0YWxFcnItIFVuc3VwcFJl
cS0gQXV4UHdyLSBUcmFuc1BlbmQtDQoJCUxua0NhcDoJUG9ydCAjNSwgU3BlZWQgMi41R1Qv
cywgV2lkdGggeDEsIEFTUE0gTDBzIEwxLCBMYXRlbmN5IEwwIDwxdXMsIEwxIDw4dXMNCgkJ
CUNsb2NrUE0tIFN1cnByaXNlLSBMTEFjdFJlcCsgQndOb3QrDQoJCUxua0N0bDoJQVNQTSBE
aXNhYmxlZDsgUkNCIDY0IGJ5dGVzIERpc2FibGVkLSBSZXRyYWluLSBDb21tQ2xrLQ0KCQkJ
RXh0U3luY2gtIENsb2NrUE0tIEF1dFdpZERpcy0gQldJbnQtIEF1dEJXSW50LQ0KCQlMbmtT
dGE6CVNwZWVkIDIuNUdUL3MsIFdpZHRoIHgxLCBUckVyci0gVHJhaW4tIFNsb3RDbGsrIERM
QWN0aXZlKyBCV01nbXQrIEFCV01nbXQtDQoJCVNsdENhcDoJQXR0bkJ0bi0gUHdyQ3RybC0g
TVJMLSBBdHRuSW5kLSBQd3JJbmQtIEhvdFBsdWctIFN1cnByaXNlLQ0KCQkJU2xvdCAjMiwg
UG93ZXJMaW1pdCA3NS4wMDBXOyBJbnRlcmxvY2stIE5vQ29tcGwrDQoJCVNsdEN0bDoJRW5h
YmxlOiBBdHRuQnRuLSBQd3JGbHQtIE1STC0gUHJlc0RldC0gQ21kQ3BsdC0gSFBJcnEtIExp
bmtDaGctDQoJCQlDb250cm9sOiBBdHRuSW5kIFVua25vd24sIFB3ckluZCBVbmtub3duLCBQ
b3dlci0gSW50ZXJsb2NrLQ0KCQlTbHRTdGE6CVN0YXR1czogQXR0bkJ0bi0gUG93ZXJGbHQt
IE1STC0gQ21kQ3BsdC0gUHJlc0RldCsgSW50ZXJsb2NrLQ0KCQkJQ2hhbmdlZDogTVJMLSBQ
cmVzRGV0KyBMaW5rU3RhdGUrDQoJCVJvb3RDdGw6IEVyckNvcnJlY3RhYmxlLSBFcnJOb24t
RmF0YWwtIEVyckZhdGFsLSBQTUVJbnRFbmEtIENSU1Zpc2libGUtDQoJCVJvb3RDYXA6IENS
U1Zpc2libGUtDQoJCVJvb3RTdGE6IFBNRSBSZXFJRCAwMDAwLCBQTUVTdGF0dXMtIFBNRVBl
bmRpbmctDQoJCURldkNhcDI6IENvbXBsZXRpb24gVGltZW91dDogUmFuZ2UgQUJDRCwgVGlt
ZW91dERpcysgQVJJRndkKw0KCQlEZXZDdGwyOiBDb21wbGV0aW9uIFRpbWVvdXQ6IDY1bXMg
dG8gMjEwbXMsIFRpbWVvdXREaXMtIEFSSUZ3ZC0NCgkJTG5rQ3RsMjogVGFyZ2V0IExpbmsg
U3BlZWQ6IDIuNUdUL3MsIEVudGVyQ29tcGxpYW5jZS0gU3BlZWREaXMtLCBTZWxlY3RhYmxl
IERlLWVtcGhhc2lzOiAtNmRCDQoJCQkgVHJhbnNtaXQgTWFyZ2luOiBOb3JtYWwgT3BlcmF0
aW5nIFJhbmdlLCBFbnRlck1vZGlmaWVkQ29tcGxpYW5jZS0gQ29tcGxpYW5jZVNPUy0NCgkJ
CSBDb21wbGlhbmNlIERlLWVtcGhhc2lzOiAtNmRCDQoJCUxua1N0YTI6IEN1cnJlbnQgRGUt
ZW1waGFzaXMgTGV2ZWw6IC02ZEINCglDYXBhYmlsaXRpZXM6IFthMF0gTVNJOiBFbmFibGUr
IENvdW50PTEvMSBNYXNrYWJsZS0gNjRiaXQtDQoJCUFkZHJlc3M6IGZlZTNmMDBjICBEYXRh
OiA0MTcxDQoJQ2FwYWJpbGl0aWVzOiBbYjBdIFN1YnN5c3RlbTogQVRJIFRlY2hub2xvZ2ll
cyBJbmMgRGV2aWNlIFsxMDAyOjVhMTFdDQoJQ2FwYWJpbGl0aWVzOiBbYjhdIEh5cGVyVHJh
bnNwb3J0OiBNU0kgTWFwcGluZyBFbmFibGUrIEZpeGVkKw0KCUNhcGFiaWxpdGllczogWzEw
MCB2MV0gVmVuZG9yIFNwZWNpZmljIEluZm9ybWF0aW9uOiBJRD0wMDAxIFJldj0xIExlbj0w
MTAgPD8+DQoJQ2FwYWJpbGl0aWVzOiBbMTkwIHYxXSBBY2Nlc3MgQ29udHJvbCBTZXJ2aWNl
cw0KCQlBQ1NDYXA6CVNyY1ZhbGlkKyBUcmFuc0JsaysgUmVxUmVkaXIrIENtcGx0UmVkaXIr
IFVwc3RyZWFtRndkKyBFZ3Jlc3NDdHJsLSBEaXJlY3RUcmFucysNCgkJQUNTQ3RsOglTcmNW
YWxpZCsgVHJhbnNCbGstIFJlcVJlZGlyKyBDbXBsdFJlZGlyKyBVcHN0cmVhbUZ3ZCsgRWdy
ZXNzQ3RybC0gRGlyZWN0VHJhbnMtDQoJS2VybmVsIGRyaXZlciBpbiB1c2U6IHBjaWVwb3J0
DQoNCjAwOjBiLjAgUENJIGJyaWRnZSBbMDYwNF06IEFUSSBUZWNobm9sb2dpZXMgSW5jIFJE
ODkwIFBDSSB0byBQQ0kgYnJpZGdlIChOQi1TQiBsaW5rKSBbMTAwMjo1YTFmXSAocHJvZy1p
ZiAwMCBbTm9ybWFsIGRlY29kZV0pDQoJQ29udHJvbDogSS9PKyBNZW0rIEJ1c01hc3Rlcisg
U3BlY0N5Y2xlLSBNZW1XSU5WLSBWR0FTbm9vcC0gUGFyRXJyLSBTdGVwcGluZy0gU0VSUisg
RmFzdEIyQi0gRGlzSU5UeCsNCglTdGF0dXM6IENhcCsgNjZNSHotIFVERi0gRmFzdEIyQi0g
UGFyRXJyLSBERVZTRUw9ZmFzdCA+VEFib3J0LSA8VEFib3J0LSA8TUFib3J0LSA+U0VSUi0g
PFBFUlItIElOVHgtDQoJTGF0ZW5jeTogMCwgQ2FjaGUgTGluZSBTaXplOiA2NCBieXRlcw0K
CUJ1czogcHJpbWFyeT0wMCwgc2Vjb25kYXJ5PTA2LCBzdWJvcmRpbmF0ZT0wNiwgc2VjLWxh
dGVuY3k9MA0KCUkvTyBiZWhpbmQgYnJpZGdlOiAwMDAwYjAwMC0wMDAwYmZmZg0KCU1lbW9y
eSBiZWhpbmQgYnJpZGdlOiBmOTkwMDAwMC1mOTlmZmZmZg0KCVByZWZldGNoYWJsZSBtZW1v
cnkgYmVoaW5kIGJyaWRnZTogMDAwMDAwMDBiMDAwMDAwMC0wMDAwMDAwMGJmZmZmZmZmDQoJ
U2Vjb25kYXJ5IHN0YXR1czogNjZNSHotIEZhc3RCMkItIFBhckVyci0gREVWU0VMPWZhc3Qg
PlRBYm9ydC0gPFRBYm9ydC0gPE1BYm9ydC0gPFNFUlItIDxQRVJSLQ0KCUJyaWRnZUN0bDog
UGFyaXR5KyBTRVJSKyBOb0lTQSsgVkdBLSBNQWJvcnQtID5SZXNldC0gRmFzdEIyQi0NCgkJ
UHJpRGlzY1Rtci0gU2VjRGlzY1Rtci0gRGlzY1RtclN0YXQtIERpc2NUbXJTRVJSRW4tDQoJ
Q2FwYWJpbGl0aWVzOiBbNTBdIFBvd2VyIE1hbmFnZW1lbnQgdmVyc2lvbiAzDQoJCUZsYWdz
OiBQTUVDbGstIERTSS0gRDEtIEQyLSBBdXhDdXJyZW50PTBtQSBQTUUoRDArLEQxLSxEMi0s
RDNob3QrLEQzY29sZCspDQoJCVN0YXR1czogRDAgTm9Tb2Z0UnN0LSBQTUUtRW5hYmxlLSBE
U2VsPTAgRFNjYWxlPTAgUE1FLQ0KCUNhcGFiaWxpdGllczogWzU4XSBFeHByZXNzICh2Mikg
Um9vdCBQb3J0IChTbG90KyksIE1TSSAwMA0KCQlEZXZDYXA6CU1heFBheWxvYWQgMTI4IGJ5
dGVzLCBQaGFudEZ1bmMgMCwgTGF0ZW5jeSBMMHMgPDY0bnMsIEwxIDwxdXMNCgkJCUV4dFRh
ZysgUkJFKyBGTFJlc2V0LQ0KCQlEZXZDdGw6CVJlcG9ydCBlcnJvcnM6IENvcnJlY3RhYmxl
LSBOb24tRmF0YWwtIEZhdGFsLSBVbnN1cHBvcnRlZC0NCgkJCVJseGRPcmQrIEV4dFRhZy0g
UGhhbnRGdW5jLSBBdXhQd3ItIE5vU25vb3ArDQoJCQlNYXhQYXlsb2FkIDEyOCBieXRlcywg
TWF4UmVhZFJlcSAxMjggYnl0ZXMNCgkJRGV2U3RhOglDb3JyRXJyLSBVbmNvcnJFcnItIEZh
dGFsRXJyLSBVbnN1cHBSZXEtIEF1eFB3ci0gVHJhbnNQZW5kLQ0KCQlMbmtDYXA6CVBvcnQg
IzAsIFNwZWVkIDVHVC9zLCBXaWR0aCB4OCwgQVNQTSBMMHMgTDEsIExhdGVuY3kgTDAgPDF1
cywgTDEgPDh1cw0KCQkJQ2xvY2tQTS0gU3VycHJpc2UtIExMQWN0UmVwKyBCd05vdCsNCgkJ
TG5rQ3RsOglBU1BNIERpc2FibGVkOyBSQ0IgNjQgYnl0ZXMgRGlzYWJsZWQtIFJldHJhaW4t
IENvbW1DbGsrDQoJCQlFeHRTeW5jaC0gQ2xvY2tQTS0gQXV0V2lkRGlzLSBCV0ludC0gQXV0
QldJbnQtDQoJCUxua1N0YToJU3BlZWQgMi41R1QvcywgV2lkdGggeDEsIFRyRXJyLSBUcmFp
bi0gU2xvdENsaysgRExBY3RpdmUrIEJXTWdtdCsgQUJXTWdtdC0NCgkJU2x0Q2FwOglBdHRu
QnRuLSBQd3JDdHJsLSBNUkwtIEF0dG5JbmQtIFB3ckluZC0gSG90UGx1Zy0gU3VycHJpc2Ut
DQoJCQlTbG90ICM1LCBQb3dlckxpbWl0IDMxLjAwMFc7IEludGVybG9jay0gTm9Db21wbCsN
CgkJU2x0Q3RsOglFbmFibGU6IEF0dG5CdG4tIFB3ckZsdC0gTVJMLSBQcmVzRGV0LSBDbWRD
cGx0LSBIUElycS0gTGlua0NoZy0NCgkJCUNvbnRyb2w6IEF0dG5JbmQgVW5rbm93biwgUHdy
SW5kIFVua25vd24sIFBvd2VyLSBJbnRlcmxvY2stDQoJCVNsdFN0YToJU3RhdHVzOiBBdHRu
QnRuLSBQb3dlckZsdC0gTVJMLSBDbWRDcGx0LSBQcmVzRGV0KyBJbnRlcmxvY2stDQoJCQlD
aGFuZ2VkOiBNUkwtIFByZXNEZXQrIExpbmtTdGF0ZSsNCgkJUm9vdEN0bDogRXJyQ29ycmVj
dGFibGUtIEVyck5vbi1GYXRhbC0gRXJyRmF0YWwtIFBNRUludEVuYS0gQ1JTVmlzaWJsZS0N
CgkJUm9vdENhcDogQ1JTVmlzaWJsZS0NCgkJUm9vdFN0YTogUE1FIFJlcUlEIDAwMDAsIFBN
RVN0YXR1cy0gUE1FUGVuZGluZy0NCgkJRGV2Q2FwMjogQ29tcGxldGlvbiBUaW1lb3V0OiBS
YW5nZSBBQkNELCBUaW1lb3V0RGlzKyBBUklGd2QrDQoJCURldkN0bDI6IENvbXBsZXRpb24g
VGltZW91dDogNjVtcyB0byAyMTBtcywgVGltZW91dERpcy0gQVJJRndkLQ0KCQlMbmtDdGwy
OiBUYXJnZXQgTGluayBTcGVlZDogNUdUL3MsIEVudGVyQ29tcGxpYW5jZS0gU3BlZWREaXMt
LCBTZWxlY3RhYmxlIERlLWVtcGhhc2lzOiAtMy41ZEINCgkJCSBUcmFuc21pdCBNYXJnaW46
IE5vcm1hbCBPcGVyYXRpbmcgUmFuZ2UsIEVudGVyTW9kaWZpZWRDb21wbGlhbmNlLSBDb21w
bGlhbmNlU09TLQ0KCQkJIENvbXBsaWFuY2UgRGUtZW1waGFzaXM6IC02ZEINCgkJTG5rU3Rh
MjogQ3VycmVudCBEZS1lbXBoYXNpcyBMZXZlbDogLTMuNWRCDQoJQ2FwYWJpbGl0aWVzOiBb
YTBdIE1TSTogRW5hYmxlKyBDb3VudD0xLzEgTWFza2FibGUtIDY0Yml0LQ0KCQlBZGRyZXNz
OiBmZWUzZjAwYyAgRGF0YTogNDE3OQ0KCUNhcGFiaWxpdGllczogW2IwXSBTdWJzeXN0ZW06
IEFUSSBUZWNobm9sb2dpZXMgSW5jIERldmljZSBbMTAwMjo1YTExXQ0KCUNhcGFiaWxpdGll
czogW2I4XSBIeXBlclRyYW5zcG9ydDogTVNJIE1hcHBpbmcgRW5hYmxlKyBGaXhlZCsNCglD
YXBhYmlsaXRpZXM6IFsxMDAgdjFdIFZlbmRvciBTcGVjaWZpYyBJbmZvcm1hdGlvbjogSUQ9
MDAwMSBSZXY9MSBMZW49MDEwIDw/Pg0KCUNhcGFiaWxpdGllczogWzE5MCB2MV0gQWNjZXNz
IENvbnRyb2wgU2VydmljZXMNCgkJQUNTQ2FwOglTcmNWYWxpZCsgVHJhbnNCbGsrIFJlcVJl
ZGlyKyBDbXBsdFJlZGlyKyBVcHN0cmVhbUZ3ZCsgRWdyZXNzQ3RybC0gRGlyZWN0VHJhbnMr
DQoJCUFDU0N0bDoJU3JjVmFsaWQrIFRyYW5zQmxrLSBSZXFSZWRpcisgQ21wbHRSZWRpcisg
VXBzdHJlYW1Gd2QrIEVncmVzc0N0cmwtIERpcmVjdFRyYW5zLQ0KCUtlcm5lbCBkcml2ZXIg
aW4gdXNlOiBwY2llcG9ydA0KDQowMDowYy4wIFBDSSBicmlkZ2UgWzA2MDRdOiBBVEkgVGVj
aG5vbG9naWVzIEluYyBEZXZpY2UgWzEwMDI6NWEyMF0gKHByb2ctaWYgMDAgW05vcm1hbCBk
ZWNvZGVdKQ0KCUNvbnRyb2w6IEkvTy0gTWVtKyBCdXNNYXN0ZXIrIFNwZWNDeWNsZS0gTWVt
V0lOVi0gVkdBU25vb3AtIFBhckVyci0gU3RlcHBpbmctIFNFUlIrIEZhc3RCMkItIERpc0lO
VHgrDQoJU3RhdHVzOiBDYXArIDY2TUh6LSBVREYtIEZhc3RCMkItIFBhckVyci0gREVWU0VM
PWZhc3QgPlRBYm9ydC0gPFRBYm9ydC0gPE1BYm9ydC0gPlNFUlItIDxQRVJSLSBJTlR4LQ0K
CUxhdGVuY3k6IDAsIENhY2hlIExpbmUgU2l6ZTogNjQgYnl0ZXMNCglCdXM6IHByaW1hcnk9
MDAsIHNlY29uZGFyeT0wNSwgc3Vib3JkaW5hdGU9MDUsIHNlYy1sYXRlbmN5PTANCglJL08g
YmVoaW5kIGJyaWRnZTogMDAwMGYwMDAtMDAwMDBmZmYNCglNZW1vcnkgYmVoaW5kIGJyaWRn
ZTogZjk2MDAwMDAtZjk3ZmZmZmYNCglQcmVmZXRjaGFibGUgbWVtb3J5IGJlaGluZCBicmlk
Z2U6IDAwMDAwMDAwZmZmMDAwMDAtMDAwMDAwMDAwMDBmZmZmZg0KCVNlY29uZGFyeSBzdGF0
dXM6IDY2TUh6LSBGYXN0QjJCLSBQYXJFcnItIERFVlNFTD1mYXN0ID5UQWJvcnQtIDxUQWJv
cnQtIDxNQWJvcnQrIDxTRVJSLSA8UEVSUi0NCglCcmlkZ2VDdGw6IFBhcml0eSsgU0VSUisg
Tm9JU0ErIFZHQS0gTUFib3J0LSA+UmVzZXQtIEZhc3RCMkItDQoJCVByaURpc2NUbXItIFNl
Y0Rpc2NUbXItIERpc2NUbXJTdGF0LSBEaXNjVG1yU0VSUkVuLQ0KCUNhcGFiaWxpdGllczog
WzUwXSBQb3dlciBNYW5hZ2VtZW50IHZlcnNpb24gMw0KCQlGbGFnczogUE1FQ2xrLSBEU0kt
IEQxLSBEMi0gQXV4Q3VycmVudD0wbUEgUE1FKEQwKyxEMS0sRDItLEQzaG90KyxEM2NvbGQr
KQ0KCQlTdGF0dXM6IEQwIE5vU29mdFJzdC0gUE1FLUVuYWJsZS0gRFNlbD0wIERTY2FsZT0w
IFBNRS0NCglDYXBhYmlsaXRpZXM6IFs1OF0gRXhwcmVzcyAodjIpIFJvb3QgUG9ydCAoU2xv
dCspLCBNU0kgMDANCgkJRGV2Q2FwOglNYXhQYXlsb2FkIDEyOCBieXRlcywgUGhhbnRGdW5j
IDAsIExhdGVuY3kgTDBzIDw2NG5zLCBMMSA8MXVzDQoJCQlFeHRUYWcrIFJCRSsgRkxSZXNl
dC0NCgkJRGV2Q3RsOglSZXBvcnQgZXJyb3JzOiBDb3JyZWN0YWJsZS0gTm9uLUZhdGFsLSBG
YXRhbC0gVW5zdXBwb3J0ZWQtDQoJCQlSbHhkT3JkKyBFeHRUYWctIFBoYW50RnVuYy0gQXV4
UHdyLSBOb1Nub29wKw0KCQkJTWF4UGF5bG9hZCAxMjggYnl0ZXMsIE1heFJlYWRSZXEgMTI4
IGJ5dGVzDQoJCURldlN0YToJQ29yckVyci0gVW5jb3JyRXJyLSBGYXRhbEVyci0gVW5zdXBw
UmVxLSBBdXhQd3ItIFRyYW5zUGVuZC0NCgkJTG5rQ2FwOglQb3J0ICMxLCBTcGVlZCA1R1Qv
cywgV2lkdGggeDgsIEFTUE0gTDBzIEwxLCBMYXRlbmN5IEwwIDwxdXMsIEwxIDw4dXMNCgkJ
CUNsb2NrUE0tIFN1cnByaXNlLSBMTEFjdFJlcCsgQndOb3QrDQoJCUxua0N0bDoJQVNQTSBE
aXNhYmxlZDsgUkNCIDY0IGJ5dGVzIERpc2FibGVkLSBSZXRyYWluLSBDb21tQ2xrLQ0KCQkJ
RXh0U3luY2gtIENsb2NrUE0tIEF1dFdpZERpcy0gQldJbnQtIEF1dEJXSW50LQ0KCQlMbmtT
dGE6CVNwZWVkIDIuNUdUL3MsIFdpZHRoIHgxLCBUckVyci0gVHJhaW4tIFNsb3RDbGsrIERM
QWN0aXZlKyBCV01nbXQrIEFCV01nbXQtDQoJCVNsdENhcDoJQXR0bkJ0bi0gUHdyQ3RybC0g
TVJMLSBBdHRuSW5kLSBQd3JJbmQtIEhvdFBsdWctIFN1cnByaXNlLQ0KCQkJU2xvdCAjNiwg
UG93ZXJMaW1pdCAxNC4wMDBXOyBJbnRlcmxvY2stIE5vQ29tcGwrDQoJCVNsdEN0bDoJRW5h
YmxlOiBBdHRuQnRuLSBQd3JGbHQtIE1STC0gUHJlc0RldC0gQ21kQ3BsdC0gSFBJcnEtIExp
bmtDaGctDQoJCQlDb250cm9sOiBBdHRuSW5kIFVua25vd24sIFB3ckluZCBVbmtub3duLCBQ
b3dlci0gSW50ZXJsb2NrLQ0KCQlTbHRTdGE6CVN0YXR1czogQXR0bkJ0bi0gUG93ZXJGbHQt
IE1STC0gQ21kQ3BsdC0gUHJlc0RldCsgSW50ZXJsb2NrLQ0KCQkJQ2hhbmdlZDogTVJMLSBQ
cmVzRGV0KyBMaW5rU3RhdGUrDQoJCVJvb3RDdGw6IEVyckNvcnJlY3RhYmxlLSBFcnJOb24t
RmF0YWwtIEVyckZhdGFsLSBQTUVJbnRFbmEtIENSU1Zpc2libGUtDQoJCVJvb3RDYXA6IENS
U1Zpc2libGUtDQoJCVJvb3RTdGE6IFBNRSBSZXFJRCAwMDAwLCBQTUVTdGF0dXMtIFBNRVBl
bmRpbmctDQoJCURldkNhcDI6IENvbXBsZXRpb24gVGltZW91dDogUmFuZ2UgQUJDRCwgVGlt
ZW91dERpcysgQVJJRndkKw0KCQlEZXZDdGwyOiBDb21wbGV0aW9uIFRpbWVvdXQ6IDY1bXMg
dG8gMjEwbXMsIFRpbWVvdXREaXMtIEFSSUZ3ZC0NCgkJTG5rQ3RsMjogVGFyZ2V0IExpbmsg
U3BlZWQ6IDVHVC9zLCBFbnRlckNvbXBsaWFuY2UtIFNwZWVkRGlzLSwgU2VsZWN0YWJsZSBE
ZS1lbXBoYXNpczogLTMuNWRCDQoJCQkgVHJhbnNtaXQgTWFyZ2luOiBOb3JtYWwgT3BlcmF0
aW5nIFJhbmdlLCBFbnRlck1vZGlmaWVkQ29tcGxpYW5jZS0gQ29tcGxpYW5jZVNPUy0NCgkJ
CSBDb21wbGlhbmNlIERlLWVtcGhhc2lzOiAtNmRCDQoJCUxua1N0YTI6IEN1cnJlbnQgRGUt
ZW1waGFzaXMgTGV2ZWw6IC0zLjVkQg0KCUNhcGFiaWxpdGllczogW2EwXSBNU0k6IEVuYWJs
ZSsgQ291bnQ9MS8xIE1hc2thYmxlLSA2NGJpdC0NCgkJQWRkcmVzczogZmVlM2YwMGMgIERh
dGE6IDQxODENCglDYXBhYmlsaXRpZXM6IFtiMF0gU3Vic3lzdGVtOiBBVEkgVGVjaG5vbG9n
aWVzIEluYyBEZXZpY2UgWzEwMDI6NWExMV0NCglDYXBhYmlsaXRpZXM6IFtiOF0gSHlwZXJU
cmFuc3BvcnQ6IE1TSSBNYXBwaW5nIEVuYWJsZSsgRml4ZWQrDQoJQ2FwYWJpbGl0aWVzOiBb
MTAwIHYxXSBWZW5kb3IgU3BlY2lmaWMgSW5mb3JtYXRpb246IElEPTAwMDEgUmV2PTEgTGVu
PTAxMCA8Pz4NCglDYXBhYmlsaXRpZXM6IFsxOTAgdjFdIEFjY2VzcyBDb250cm9sIFNlcnZp
Y2VzDQoJCUFDU0NhcDoJU3JjVmFsaWQrIFRyYW5zQmxrKyBSZXFSZWRpcisgQ21wbHRSZWRp
cisgVXBzdHJlYW1Gd2QrIEVncmVzc0N0cmwtIERpcmVjdFRyYW5zKw0KCQlBQ1NDdGw6CVNy
Y1ZhbGlkKyBUcmFuc0Jsay0gUmVxUmVkaXIrIENtcGx0UmVkaXIrIFVwc3RyZWFtRndkKyBF
Z3Jlc3NDdHJsLSBEaXJlY3RUcmFucy0NCglLZXJuZWwgZHJpdmVyIGluIHVzZTogcGNpZXBv
cnQNCg0KMDA6MGQuMCBQQ0kgYnJpZGdlIFswNjA0XTogQVRJIFRlY2hub2xvZ2llcyBJbmMg
UkQ4OTAgUENJIHRvIFBDSSBicmlkZ2UgKGV4dGVybmFsIGdmeDEgcG9ydCBCKSBbMTAwMjo1
YTFlXSAocHJvZy1pZiAwMCBbTm9ybWFsIGRlY29kZV0pDQoJQ29udHJvbDogSS9PLSBNZW0r
IEJ1c01hc3RlcisgU3BlY0N5Y2xlLSBNZW1XSU5WLSBWR0FTbm9vcC0gUGFyRXJyLSBTdGVw
cGluZy0gU0VSUisgRmFzdEIyQi0gRGlzSU5UeCsNCglTdGF0dXM6IENhcCsgNjZNSHotIFVE
Ri0gRmFzdEIyQi0gUGFyRXJyLSBERVZTRUw9ZmFzdCA+VEFib3J0LSA8VEFib3J0LSA8TUFi
b3J0LSA+U0VSUi0gPFBFUlItIElOVHgtDQoJTGF0ZW5jeTogMCwgQ2FjaGUgTGluZSBTaXpl
OiA2NCBieXRlcw0KCUJ1czogcHJpbWFyeT0wMCwgc2Vjb25kYXJ5PTA0LCBzdWJvcmRpbmF0
ZT0wNCwgc2VjLWxhdGVuY3k9MA0KCUkvTyBiZWhpbmQgYnJpZGdlOiAwMDAwZjAwMC0wMDAw
MGZmZg0KCU1lbW9yeSBiZWhpbmQgYnJpZGdlOiBmOTUwMDAwMC1mOTVmZmZmZg0KCVByZWZl
dGNoYWJsZSBtZW1vcnkgYmVoaW5kIGJyaWRnZTogMDAwMDAwMDBmZmYwMDAwMC0wMDAwMDAw
MDAwMGZmZmZmDQoJU2Vjb25kYXJ5IHN0YXR1czogNjZNSHotIEZhc3RCMkItIFBhckVyci0g
REVWU0VMPWZhc3QgPlRBYm9ydC0gPFRBYm9ydC0gPE1BYm9ydC0gPFNFUlItIDxQRVJSLQ0K
CUJyaWRnZUN0bDogUGFyaXR5KyBTRVJSKyBOb0lTQSsgVkdBLSBNQWJvcnQtID5SZXNldC0g
RmFzdEIyQi0NCgkJUHJpRGlzY1Rtci0gU2VjRGlzY1Rtci0gRGlzY1RtclN0YXQtIERpc2NU
bXJTRVJSRW4tDQoJQ2FwYWJpbGl0aWVzOiBbNTBdIFBvd2VyIE1hbmFnZW1lbnQgdmVyc2lv
biAzDQoJCUZsYWdzOiBQTUVDbGstIERTSS0gRDEtIEQyLSBBdXhDdXJyZW50PTBtQSBQTUUo
RDArLEQxLSxEMi0sRDNob3QrLEQzY29sZCspDQoJCVN0YXR1czogRDAgTm9Tb2Z0UnN0LSBQ
TUUtRW5hYmxlLSBEU2VsPTAgRFNjYWxlPTAgUE1FLQ0KCUNhcGFiaWxpdGllczogWzU4XSBF
eHByZXNzICh2MikgUm9vdCBQb3J0IChTbG90KyksIE1TSSAwMA0KCQlEZXZDYXA6CU1heFBh
eWxvYWQgMTI4IGJ5dGVzLCBQaGFudEZ1bmMgMCwgTGF0ZW5jeSBMMHMgPDY0bnMsIEwxIDwx
dXMNCgkJCUV4dFRhZysgUkJFKyBGTFJlc2V0LQ0KCQlEZXZDdGw6CVJlcG9ydCBlcnJvcnM6
IENvcnJlY3RhYmxlLSBOb24tRmF0YWwtIEZhdGFsLSBVbnN1cHBvcnRlZC0NCgkJCVJseGRP
cmQrIEV4dFRhZy0gUGhhbnRGdW5jLSBBdXhQd3ItIE5vU25vb3ArDQoJCQlNYXhQYXlsb2Fk
IDEyOCBieXRlcywgTWF4UmVhZFJlcSAxMjggYnl0ZXMNCgkJRGV2U3RhOglDb3JyRXJyLSBV
bmNvcnJFcnItIEZhdGFsRXJyLSBVbnN1cHBSZXEtIEF1eFB3ci0gVHJhbnNQZW5kLQ0KCQlM
bmtDYXA6CVBvcnQgIzAsIFNwZWVkIDVHVC9zLCBXaWR0aCB4NCwgQVNQTSBMMHMgTDEsIExh
dGVuY3kgTDAgPDF1cywgTDEgPDh1cw0KCQkJQ2xvY2tQTS0gU3VycHJpc2UtIExMQWN0UmVw
KyBCd05vdCsNCgkJTG5rQ3RsOglBU1BNIERpc2FibGVkOyBSQ0IgNjQgYnl0ZXMgRGlzYWJs
ZWQtIFJldHJhaW4tIENvbW1DbGstDQoJCQlFeHRTeW5jaC0gQ2xvY2tQTS0gQXV0V2lkRGlz
LSBCV0ludC0gQXV0QldJbnQtDQoJCUxua1N0YToJU3BlZWQgMi41R1QvcywgV2lkdGggeDEs
IFRyRXJyLSBUcmFpbi0gU2xvdENsaysgRExBY3RpdmUrIEJXTWdtdCsgQUJXTWdtdC0NCgkJ
U2x0Q2FwOglBdHRuQnRuLSBQd3JDdHJsLSBNUkwtIEF0dG5JbmQtIFB3ckluZC0gSG90UGx1
Zy0gU3VycHJpc2UtDQoJCQlTbG90ICM0LCBQb3dlckxpbWl0IDc1LjAwMFc7IEludGVybG9j
ay0gTm9Db21wbCsNCgkJU2x0Q3RsOglFbmFibGU6IEF0dG5CdG4tIFB3ckZsdC0gTVJMLSBQ
cmVzRGV0LSBDbWRDcGx0LSBIUElycS0gTGlua0NoZy0NCgkJCUNvbnRyb2w6IEF0dG5JbmQg
VW5rbm93biwgUHdySW5kIFVua25vd24sIFBvd2VyLSBJbnRlcmxvY2stDQoJCVNsdFN0YToJ
U3RhdHVzOiBBdHRuQnRuLSBQb3dlckZsdC0gTVJMLSBDbWRDcGx0LSBQcmVzRGV0KyBJbnRl
cmxvY2stDQoJCQlDaGFuZ2VkOiBNUkwtIFByZXNEZXQrIExpbmtTdGF0ZSsNCgkJUm9vdEN0
bDogRXJyQ29ycmVjdGFibGUtIEVyck5vbi1GYXRhbC0gRXJyRmF0YWwtIFBNRUludEVuYS0g
Q1JTVmlzaWJsZS0NCgkJUm9vdENhcDogQ1JTVmlzaWJsZS0NCgkJUm9vdFN0YTogUE1FIFJl
cUlEIDAwMDAsIFBNRVN0YXR1cy0gUE1FUGVuZGluZy0NCgkJRGV2Q2FwMjogQ29tcGxldGlv
biBUaW1lb3V0OiBSYW5nZSBBQkNELCBUaW1lb3V0RGlzKyBBUklGd2QrDQoJCURldkN0bDI6
IENvbXBsZXRpb24gVGltZW91dDogNjVtcyB0byAyMTBtcywgVGltZW91dERpcy0gQVJJRndk
LQ0KCQlMbmtDdGwyOiBUYXJnZXQgTGluayBTcGVlZDogNUdUL3MsIEVudGVyQ29tcGxpYW5j
ZS0gU3BlZWREaXMtLCBTZWxlY3RhYmxlIERlLWVtcGhhc2lzOiAtMy41ZEINCgkJCSBUcmFu
c21pdCBNYXJnaW46IE5vcm1hbCBPcGVyYXRpbmcgUmFuZ2UsIEVudGVyTW9kaWZpZWRDb21w
bGlhbmNlLSBDb21wbGlhbmNlU09TLQ0KCQkJIENvbXBsaWFuY2UgRGUtZW1waGFzaXM6IC02
ZEINCgkJTG5rU3RhMjogQ3VycmVudCBEZS1lbXBoYXNpcyBMZXZlbDogLTMuNWRCDQoJQ2Fw
YWJpbGl0aWVzOiBbYTBdIE1TSTogRW5hYmxlKyBDb3VudD0xLzEgTWFza2FibGUtIDY0Yml0
LQ0KCQlBZGRyZXNzOiBmZWUzZjAwYyAgRGF0YTogNDE4OQ0KCUNhcGFiaWxpdGllczogW2Iw
XSBTdWJzeXN0ZW06IEFUSSBUZWNobm9sb2dpZXMgSW5jIERldmljZSBbMTAwMjo1YTExXQ0K
CUNhcGFiaWxpdGllczogW2I4XSBIeXBlclRyYW5zcG9ydDogTVNJIE1hcHBpbmcgRW5hYmxl
KyBGaXhlZCsNCglDYXBhYmlsaXRpZXM6IFsxMDAgdjFdIFZlbmRvciBTcGVjaWZpYyBJbmZv
cm1hdGlvbjogSUQ9MDAwMSBSZXY9MSBMZW49MDEwIDw/Pg0KCUNhcGFiaWxpdGllczogWzE5
MCB2MV0gQWNjZXNzIENvbnRyb2wgU2VydmljZXMNCgkJQUNTQ2FwOglTcmNWYWxpZCsgVHJh
bnNCbGsrIFJlcVJlZGlyKyBDbXBsdFJlZGlyKyBVcHN0cmVhbUZ3ZCsgRWdyZXNzQ3RybC0g
RGlyZWN0VHJhbnMrDQoJCUFDU0N0bDoJU3JjVmFsaWQrIFRyYW5zQmxrLSBSZXFSZWRpcisg
Q21wbHRSZWRpcisgVXBzdHJlYW1Gd2QrIEVncmVzc0N0cmwtIERpcmVjdFRyYW5zLQ0KCUtl
cm5lbCBkcml2ZXIgaW4gdXNlOiBwY2llcG9ydA0KDQowMDoxMS4wIFNBVEEgY29udHJvbGxl
ciBbMDEwNl06IEFUSSBUZWNobm9sb2dpZXMgSW5jIFNCN3gwL1NCOHgwL1NCOXgwIFNBVEEg
Q29udHJvbGxlciBbQUhDSSBtb2RlXSBbMTAwMjo0MzkxXSAocmV2IDQwKSAocHJvZy1pZiAw
MSBbQUhDSSAxLjBdKQ0KCVN1YnN5c3RlbTogTWljcm8tU3RhciBJbnRlcm5hdGlvbmFsIENv
LiwgTHRkLiBEZXZpY2UgWzE0NjI6NzY0MF0NCglDb250cm9sOiBJL08rIE1lbSsgQnVzTWFz
dGVyKyBTcGVjQ3ljbGUtIE1lbVdJTlYtIFZHQVNub29wLSBQYXJFcnItIFN0ZXBwaW5nLSBT
RVJSKyBGYXN0QjJCLSBEaXNJTlR4Kw0KCVN0YXR1czogQ2FwKyA2Nk1IeisgVURGLSBGYXN0
QjJCLSBQYXJFcnItIERFVlNFTD1tZWRpdW0gPlRBYm9ydC0gPFRBYm9ydC0gPE1BYm9ydC0g
PlNFUlItIDxQRVJSLSBJTlR4LQ0KCUxhdGVuY3k6IDY0LCBDYWNoZSBMaW5lIFNpemU6IDY0
IGJ5dGVzDQoJSW50ZXJydXB0OiBwaW4gQSByb3V0ZWQgdG8gSVJRIDEyMA0KCVJlZ2lvbiAw
OiBJL08gcG9ydHMgYXQgNzAwMCBbc2l6ZT04XQ0KCVJlZ2lvbiAxOiBJL08gcG9ydHMgYXQg
NjAwMCBbc2l6ZT00XQ0KCVJlZ2lvbiAyOiBJL08gcG9ydHMgYXQgNTAwMCBbc2l6ZT04XQ0K
CVJlZ2lvbiAzOiBJL08gcG9ydHMgYXQgMzAwMCBbc2l6ZT00XQ0KCVJlZ2lvbiA0OiBJL08g
cG9ydHMgYXQgMjAwMCBbc2l6ZT0xNl0NCglSZWdpb24gNTogTWVtb3J5IGF0IGY5M2ZmMDAw
ICgzMi1iaXQsIG5vbi1wcmVmZXRjaGFibGUpIFtzaXplPTFLXQ0KCUNhcGFiaWxpdGllczog
WzUwXSBNU0k6IEVuYWJsZSsgQ291bnQ9MS84IE1hc2thYmxlLSA2NGJpdCsNCgkJQWRkcmVz
czogMDAwMDAwMDBmZWUwMTAwYyAgRGF0YTogNDFiOQ0KCUNhcGFiaWxpdGllczogWzcwXSBT
QVRBIEhCQSB2MS4wIEluQ2ZnU3BhY2UNCglDYXBhYmlsaXRpZXM6IFthNF0gUENJIEFkdmFu
Y2VkIEZlYXR1cmVzDQoJCUFGQ2FwOiBUUCsgRkxSKw0KCQlBRkN0cmw6IEZMUi0NCgkJQUZT
dGF0dXM6IFRQLQ0KCUtlcm5lbCBkcml2ZXIgaW4gdXNlOiBhaGNpDQoNCjAwOjEyLjAgVVNC
IGNvbnRyb2xsZXIgWzBjMDNdOiBBVEkgVGVjaG5vbG9naWVzIEluYyBTQjd4MC9TQjh4MC9T
Qjl4MCBVU0IgT0hDSTAgQ29udHJvbGxlciBbMTAwMjo0Mzk3XSAocHJvZy1pZiAxMCBbT0hD
SV0pDQoJU3Vic3lzdGVtOiBNaWNyby1TdGFyIEludGVybmF0aW9uYWwgQ28uLCBMdGQuIERl
dmljZSBbMTQ2Mjo3NjQwXQ0KCUNvbnRyb2w6IEkvTysgTWVtKyBCdXNNYXN0ZXIrIFNwZWND
eWNsZS0gTWVtV0lOVisgVkdBU25vb3AtIFBhckVyci0gU3RlcHBpbmctIFNFUlIrIEZhc3RC
MkItIERpc0lOVHgtDQoJU3RhdHVzOiBDYXAtIDY2TUh6KyBVREYtIEZhc3RCMkIrIFBhckVy
ci0gREVWU0VMPW1lZGl1bSA+VEFib3J0LSA8VEFib3J0LSA8TUFib3J0LSA+U0VSUi0gPFBF
UlItIElOVHgtDQoJTGF0ZW5jeTogNjQsIENhY2hlIExpbmUgU2l6ZTogNjQgYnl0ZXMNCglJ
bnRlcnJ1cHQ6IHBpbiBBIHJvdXRlZCB0byBJUlEgMTgNCglSZWdpb24gMDogTWVtb3J5IGF0
IGY5M2ZiMDAwICgzMi1iaXQsIG5vbi1wcmVmZXRjaGFibGUpIFtzaXplPTRLXQ0KCUtlcm5l
bCBkcml2ZXIgaW4gdXNlOiBvaGNpX2hjZA0KDQowMDoxMi4yIFVTQiBjb250cm9sbGVyIFsw
YzAzXTogQVRJIFRlY2hub2xvZ2llcyBJbmMgU0I3eDAvU0I4eDAvU0I5eDAgVVNCIEVIQ0kg
Q29udHJvbGxlciBbMTAwMjo0Mzk2XSAocHJvZy1pZiAyMCBbRUhDSV0pDQoJU3Vic3lzdGVt
OiBNaWNyby1TdGFyIEludGVybmF0aW9uYWwgQ28uLCBMdGQuIERldmljZSBbMTQ2Mjo3NjQw
XQ0KCUNvbnRyb2w6IEkvTy0gTWVtKyBCdXNNYXN0ZXIrIFNwZWNDeWNsZS0gTWVtV0lOVisg
VkdBU25vb3AtIFBhckVyci0gU3RlcHBpbmctIFNFUlIrIEZhc3RCMkItIERpc0lOVHgtDQoJ
U3RhdHVzOiBDYXArIDY2TUh6KyBVREYtIEZhc3RCMkIrIFBhckVyci0gREVWU0VMPW1lZGl1
bSA+VEFib3J0LSA8VEFib3J0LSA8TUFib3J0LSA+U0VSUi0gPFBFUlItIElOVHgtDQoJTGF0
ZW5jeTogNjQsIENhY2hlIExpbmUgU2l6ZTogNjQgYnl0ZXMNCglJbnRlcnJ1cHQ6IHBpbiBC
IHJvdXRlZCB0byBJUlEgMTcNCglSZWdpb24gMDogTWVtb3J5IGF0IGY5M2ZmNDAwICgzMi1i
aXQsIG5vbi1wcmVmZXRjaGFibGUpIFtzaXplPTI1Nl0NCglDYXBhYmlsaXRpZXM6IFtjMF0g
UG93ZXIgTWFuYWdlbWVudCB2ZXJzaW9uIDINCgkJRmxhZ3M6IFBNRUNsay0gRFNJLSBEMSsg
RDIrIEF1eEN1cnJlbnQ9MG1BIFBNRShEMCssRDErLEQyKyxEM2hvdCssRDNjb2xkLSkNCgkJ
U3RhdHVzOiBEMCBOb1NvZnRSc3QtIFBNRS1FbmFibGUtIERTZWw9MCBEU2NhbGU9MCBQTUUt
DQoJCUJyaWRnZTogUE0tIEIzKw0KCUNhcGFiaWxpdGllczogW2U0XSBEZWJ1ZyBwb3J0OiBC
QVI9MSBvZmZzZXQ9MDBlMA0KCUtlcm5lbCBkcml2ZXIgaW4gdXNlOiBlaGNpX2hjZA0KDQow
MDoxMy4wIFVTQiBjb250cm9sbGVyIFswYzAzXTogQVRJIFRlY2hub2xvZ2llcyBJbmMgU0I3
eDAvU0I4eDAvU0I5eDAgVVNCIE9IQ0kwIENvbnRyb2xsZXIgWzEwMDI6NDM5N10gKHByb2ct
aWYgMTAgW09IQ0ldKQ0KCVN1YnN5c3RlbTogTWljcm8tU3RhciBJbnRlcm5hdGlvbmFsIENv
LiwgTHRkLiBEZXZpY2UgWzE0NjI6NzY0MF0NCglDb250cm9sOiBJL08rIE1lbSsgQnVzTWFz
dGVyKyBTcGVjQ3ljbGUtIE1lbVdJTlYrIFZHQVNub29wLSBQYXJFcnItIFN0ZXBwaW5nLSBT
RVJSKyBGYXN0QjJCLSBEaXNJTlR4LQ0KCVN0YXR1czogQ2FwLSA2Nk1IeisgVURGLSBGYXN0
QjJCKyBQYXJFcnItIERFVlNFTD1tZWRpdW0gPlRBYm9ydC0gPFRBYm9ydC0gPE1BYm9ydC0g
PlNFUlItIDxQRVJSLSBJTlR4LQ0KCUxhdGVuY3k6IDY0LCBDYWNoZSBMaW5lIFNpemU6IDY0
IGJ5dGVzDQoJSW50ZXJydXB0OiBwaW4gQSByb3V0ZWQgdG8gSVJRIDE4DQoJUmVnaW9uIDA6
IE1lbW9yeSBhdCBmOTNmYzAwMCAoMzItYml0LCBub24tcHJlZmV0Y2hhYmxlKSBbc2l6ZT00
S10NCglLZXJuZWwgZHJpdmVyIGluIHVzZTogb2hjaV9oY2QNCg0KMDA6MTMuMiBVU0IgY29u
dHJvbGxlciBbMGMwM106IEFUSSBUZWNobm9sb2dpZXMgSW5jIFNCN3gwL1NCOHgwL1NCOXgw
IFVTQiBFSENJIENvbnRyb2xsZXIgWzEwMDI6NDM5Nl0gKHByb2ctaWYgMjAgW0VIQ0ldKQ0K
CVN1YnN5c3RlbTogTWljcm8tU3RhciBJbnRlcm5hdGlvbmFsIENvLiwgTHRkLiBEZXZpY2Ug
WzE0NjI6NzY0MF0NCglDb250cm9sOiBJL08tIE1lbSsgQnVzTWFzdGVyKyBTcGVjQ3ljbGUt
IE1lbVdJTlYrIFZHQVNub29wLSBQYXJFcnItIFN0ZXBwaW5nLSBTRVJSKyBGYXN0QjJCLSBE
aXNJTlR4LQ0KCVN0YXR1czogQ2FwKyA2Nk1IeisgVURGLSBGYXN0QjJCKyBQYXJFcnItIERF
VlNFTD1tZWRpdW0gPlRBYm9ydC0gPFRBYm9ydC0gPE1BYm9ydC0gPlNFUlItIDxQRVJSLSBJ
TlR4LQ0KCUxhdGVuY3k6IDY0LCBDYWNoZSBMaW5lIFNpemU6IDY0IGJ5dGVzDQoJSW50ZXJy
dXB0OiBwaW4gQiByb3V0ZWQgdG8gSVJRIDE3DQoJUmVnaW9uIDA6IE1lbW9yeSBhdCBmOTNm
ZjgwMCAoMzItYml0LCBub24tcHJlZmV0Y2hhYmxlKSBbc2l6ZT0yNTZdDQoJQ2FwYWJpbGl0
aWVzOiBbYzBdIFBvd2VyIE1hbmFnZW1lbnQgdmVyc2lvbiAyDQoJCUZsYWdzOiBQTUVDbGst
IERTSS0gRDErIEQyKyBBdXhDdXJyZW50PTBtQSBQTUUoRDArLEQxKyxEMissRDNob3QrLEQz
Y29sZC0pDQoJCVN0YXR1czogRDAgTm9Tb2Z0UnN0LSBQTUUtRW5hYmxlLSBEU2VsPTAgRFNj
YWxlPTAgUE1FLQ0KCQlCcmlkZ2U6IFBNLSBCMysNCglDYXBhYmlsaXRpZXM6IFtlNF0gRGVi
dWcgcG9ydDogQkFSPTEgb2Zmc2V0PTAwZTANCglLZXJuZWwgZHJpdmVyIGluIHVzZTogZWhj
aV9oY2QNCg0KMDA6MTQuMCBTTUJ1cyBbMGMwNV06IEFUSSBUZWNobm9sb2dpZXMgSW5jIFNC
eDAwIFNNQnVzIENvbnRyb2xsZXIgWzEwMDI6NDM4NV0gKHJldiA0MSkNCglDb250cm9sOiBJ
L08rIE1lbSsgQnVzTWFzdGVyLSBTcGVjQ3ljbGUtIE1lbVdJTlYtIFZHQVNub29wLSBQYXJF
cnItIFN0ZXBwaW5nLSBTRVJSLSBGYXN0QjJCLSBEaXNJTlR4Kw0KCVN0YXR1czogQ2FwLSA2
Nk1IeisgVURGLSBGYXN0QjJCLSBQYXJFcnItIERFVlNFTD1tZWRpdW0gPlRBYm9ydC0gPFRB
Ym9ydC0gPE1BYm9ydC0gPlNFUlItIDxQRVJSLSBJTlR4LQ0KDQowMDoxNC4zIElTQSBicmlk
Z2UgWzA2MDFdOiBBVEkgVGVjaG5vbG9naWVzIEluYyBTQjd4MC9TQjh4MC9TQjl4MCBMUEMg
aG9zdCBjb250cm9sbGVyIFsxMDAyOjQzOWRdIChyZXYgNDApDQoJU3Vic3lzdGVtOiBNaWNy
by1TdGFyIEludGVybmF0aW9uYWwgQ28uLCBMdGQuIERldmljZSBbMTQ2Mjo3NjQwXQ0KCUNv
bnRyb2w6IEkvTysgTWVtKyBCdXNNYXN0ZXIrIFNwZWNDeWNsZSsgTWVtV0lOVi0gVkdBU25v
b3AtIFBhckVyci0gU3RlcHBpbmctIFNFUlItIEZhc3RCMkItIERpc0lOVHgtDQoJU3RhdHVz
OiBDYXAtIDY2TUh6KyBVREYtIEZhc3RCMkItIFBhckVyci0gREVWU0VMPW1lZGl1bSA+VEFi
b3J0LSA8VEFib3J0LSA8TUFib3J0LSA+U0VSUi0gPFBFUlItIElOVHgtDQoJTGF0ZW5jeTog
MA0KDQowMDoxNC40IFBDSSBicmlkZ2UgWzA2MDRdOiBBVEkgVGVjaG5vbG9naWVzIEluYyBT
QngwMCBQQ0kgdG8gUENJIEJyaWRnZSBbMTAwMjo0Mzg0XSAocmV2IDQwKSAocHJvZy1pZiAw
MSBbU3VidHJhY3RpdmUgZGVjb2RlXSkNCglDb250cm9sOiBJL08rIE1lbS0gQnVzTWFzdGVy
KyBTcGVjQ3ljbGUtIE1lbVdJTlYtIFZHQVNub29wLSBQYXJFcnItIFN0ZXBwaW5nLSBTRVJS
KyBGYXN0QjJCLSBEaXNJTlR4LQ0KCVN0YXR1czogQ2FwLSA2Nk1IeisgVURGLSBGYXN0QjJC
KyBQYXJFcnItIERFVlNFTD1tZWRpdW0gPlRBYm9ydC0gPFRBYm9ydC0gPE1BYm9ydC0gPlNF
UlItIDxQRVJSLSBJTlR4LQ0KCUxhdGVuY3k6IDY0DQoJQnVzOiBwcmltYXJ5PTAwLCBzZWNv
bmRhcnk9MDMsIHN1Ym9yZGluYXRlPTAzLCBzZWMtbGF0ZW5jeT02NA0KCUkvTyBiZWhpbmQg
YnJpZGdlOiAwMDAwYTAwMC0wMDAwYWZmZg0KCU1lbW9yeSBiZWhpbmQgYnJpZGdlOiBmZmYw
MDAwMC0wMDBmZmZmZg0KCVByZWZldGNoYWJsZSBtZW1vcnkgYmVoaW5kIGJyaWRnZTogZmZm
MDAwMDAtMDAwZmZmZmYNCglTZWNvbmRhcnkgc3RhdHVzOiA2Nk1Iei0gRmFzdEIyQisgUGFy
RXJyLSBERVZTRUw9bWVkaXVtID5UQWJvcnQtIDxUQWJvcnQtIDxNQWJvcnQrIDxTRVJSLSA8
UEVSUi0NCglCcmlkZ2VDdGw6IFBhcml0eSsgU0VSUisgTm9JU0ErIFZHQS0gTUFib3J0LSA+
UmVzZXQtIEZhc3RCMkItDQoJCVByaURpc2NUbXItIFNlY0Rpc2NUbXItIERpc2NUbXJTdGF0
LSBEaXNjVG1yU0VSUkVuLQ0KDQowMDoxNC41IFVTQiBjb250cm9sbGVyIFswYzAzXTogQVRJ
IFRlY2hub2xvZ2llcyBJbmMgU0I3eDAvU0I4eDAvU0I5eDAgVVNCIE9IQ0kyIENvbnRyb2xs
ZXIgWzEwMDI6NDM5OV0gKHByb2ctaWYgMTAgW09IQ0ldKQ0KCVN1YnN5c3RlbTogTWljcm8t
U3RhciBJbnRlcm5hdGlvbmFsIENvLiwgTHRkLiBEZXZpY2UgWzE0NjI6NzY0MF0NCglDb250
cm9sOiBJL08rIE1lbSsgQnVzTWFzdGVyKyBTcGVjQ3ljbGUtIE1lbVdJTlYrIFZHQVNub29w
LSBQYXJFcnItIFN0ZXBwaW5nLSBTRVJSKyBGYXN0QjJCLSBEaXNJTlR4LQ0KCVN0YXR1czog
Q2FwLSA2Nk1IeisgVURGLSBGYXN0QjJCKyBQYXJFcnItIERFVlNFTD1tZWRpdW0gPlRBYm9y
dC0gPFRBYm9ydC0gPE1BYm9ydC0gPlNFUlItIDxQRVJSLSBJTlR4LQ0KCUxhdGVuY3k6IDY0
LCBDYWNoZSBMaW5lIFNpemU6IDY0IGJ5dGVzDQoJSW50ZXJydXB0OiBwaW4gQyByb3V0ZWQg
dG8gSVJRIDE4DQoJUmVnaW9uIDA6IE1lbW9yeSBhdCBmOTNmZDAwMCAoMzItYml0LCBub24t
cHJlZmV0Y2hhYmxlKSBbc2l6ZT00S10NCglLZXJuZWwgZHJpdmVyIGluIHVzZTogb2hjaV9o
Y2QNCg0KMDA6MTUuMCBQQ0kgYnJpZGdlIFswNjA0XTogQVRJIFRlY2hub2xvZ2llcyBJbmMg
U0I3MDAvU0I4MDAvU0I5MDAgUENJIHRvIFBDSSBicmlkZ2UgKFBDSUUgcG9ydCAwKSBbMTAw
Mjo0M2EwXSAocHJvZy1pZiAwMCBbTm9ybWFsIGRlY29kZV0pDQoJQ29udHJvbDogSS9PLSBN
ZW0tIEJ1c01hc3RlcisgU3BlY0N5Y2xlLSBNZW1XSU5WLSBWR0FTbm9vcC0gUGFyRXJyLSBT
dGVwcGluZy0gU0VSUisgRmFzdEIyQi0gRGlzSU5UeCsNCglTdGF0dXM6IENhcCsgNjZNSHot
IFVERi0gRmFzdEIyQi0gUGFyRXJyLSBERVZTRUw9ZmFzdCA+VEFib3J0LSA8VEFib3J0LSA8
TUFib3J0LSA+U0VSUi0gPFBFUlItIElOVHgtDQoJTGF0ZW5jeTogMCwgQ2FjaGUgTGluZSBT
aXplOiA2NCBieXRlcw0KCUJ1czogcHJpbWFyeT0wMCwgc2Vjb25kYXJ5PTAyLCBzdWJvcmRp
bmF0ZT0wMiwgc2VjLWxhdGVuY3k9MA0KCUkvTyBiZWhpbmQgYnJpZGdlOiAwMDAwZjAwMC0w
MDAwMGZmZg0KCU1lbW9yeSBiZWhpbmQgYnJpZGdlOiBmZmYwMDAwMC0wMDBmZmZmZg0KCVBy
ZWZldGNoYWJsZSBtZW1vcnkgYmVoaW5kIGJyaWRnZTogMDAwMDAwMDBmZmYwMDAwMC0wMDAw
MDAwMDAwMGZmZmZmDQoJU2Vjb25kYXJ5IHN0YXR1czogNjZNSHotIEZhc3RCMkItIFBhckVy
ci0gREVWU0VMPWZhc3QgPlRBYm9ydC0gPFRBYm9ydC0gPE1BYm9ydC0gPFNFUlItIDxQRVJS
LQ0KCUJyaWRnZUN0bDogUGFyaXR5KyBTRVJSKyBOb0lTQSsgVkdBLSBNQWJvcnQtID5SZXNl
dC0gRmFzdEIyQi0NCgkJUHJpRGlzY1Rtci0gU2VjRGlzY1Rtci0gRGlzY1RtclN0YXQtIERp
c2NUbXJTRVJSRW4tDQoJQ2FwYWJpbGl0aWVzOiBbNTBdIFBvd2VyIE1hbmFnZW1lbnQgdmVy
c2lvbiAzDQoJCUZsYWdzOiBQTUVDbGstIERTSS0gRDErIEQyKyBBdXhDdXJyZW50PTBtQSBQ
TUUoRDAtLEQxLSxEMi0sRDNob3QtLEQzY29sZC0pDQoJCVN0YXR1czogRDAgTm9Tb2Z0UnN0
LSBQTUUtRW5hYmxlLSBEU2VsPTAgRFNjYWxlPTAgUE1FLQ0KCUNhcGFiaWxpdGllczogWzU4
XSBFeHByZXNzICh2MikgUm9vdCBQb3J0IChTbG90KyksIE1TSSAwMA0KCQlEZXZDYXA6CU1h
eFBheWxvYWQgMTI4IGJ5dGVzLCBQaGFudEZ1bmMgMCwgTGF0ZW5jeSBMMHMgPDY0bnMsIEwx
IDwxdXMNCgkJCUV4dFRhZysgUkJFKyBGTFJlc2V0LQ0KCQlEZXZDdGw6CVJlcG9ydCBlcnJv
cnM6IENvcnJlY3RhYmxlLSBOb24tRmF0YWwtIEZhdGFsLSBVbnN1cHBvcnRlZC0NCgkJCVJs
eGRPcmQrIEV4dFRhZy0gUGhhbnRGdW5jLSBBdXhQd3ItIE5vU25vb3ArDQoJCQlNYXhQYXls
b2FkIDEyOCBieXRlcywgTWF4UmVhZFJlcSAxMjggYnl0ZXMNCgkJRGV2U3RhOglDb3JyRXJy
LSBVbmNvcnJFcnItIEZhdGFsRXJyLSBVbnN1cHBSZXEtIEF1eFB3ci0gVHJhbnNQZW5kLQ0K
CQlMbmtDYXA6CVBvcnQgIzI0NywgU3BlZWQgMi41R1QvcywgV2lkdGggeDEsIEFTUE0gTDBz
IEwxLCBMYXRlbmN5IEwwIDw2NG5zLCBMMSA8MXVzDQoJCQlDbG9ja1BNLSBTdXJwcmlzZS0g
TExBY3RSZXArIEJ3Tm90Kw0KCQlMbmtDdGw6CUFTUE0gRGlzYWJsZWQ7IFJDQiA2NCBieXRl
cyBEaXNhYmxlZC0gUmV0cmFpbi0gQ29tbUNsay0NCgkJCUV4dFN5bmNoLSBDbG9ja1BNLSBB
dXRXaWREaXMtIEJXSW50LSBBdXRCV0ludC0NCgkJTG5rU3RhOglTcGVlZCB1bmtub3duLCBX
aWR0aCB4MTYsIFRyRXJyLSBUcmFpbi0gU2xvdENsaysgRExBY3RpdmUtIEJXTWdtdC0gQUJX
TWdtdC0NCgkJU2x0Q2FwOglBdHRuQnRuLSBQd3JDdHJsLSBNUkwtIEF0dG5JbmQtIFB3cklu
ZC0gSG90UGx1Zy0gU3VycHJpc2UtDQoJCQlTbG90ICMzMiwgUG93ZXJMaW1pdCA3NS4wMDBX
OyBJbnRlcmxvY2stIE5vQ29tcGwrDQoJCVNsdEN0bDoJRW5hYmxlOiBBdHRuQnRuLSBQd3JG
bHQtIE1STC0gUHJlc0RldC0gQ21kQ3BsdC0gSFBJcnEtIExpbmtDaGctDQoJCQlDb250cm9s
OiBBdHRuSW5kIFVua25vd24sIFB3ckluZCBVbmtub3duLCBQb3dlci0gSW50ZXJsb2NrLQ0K
CQlTbHRTdGE6CVN0YXR1czogQXR0bkJ0bi0gUG93ZXJGbHQtIE1STC0gQ21kQ3BsdC0gUHJl
c0RldC0gSW50ZXJsb2NrLQ0KCQkJQ2hhbmdlZDogTVJMLSBQcmVzRGV0LSBMaW5rU3RhdGUt
DQoJCVJvb3RDdGw6IEVyckNvcnJlY3RhYmxlLSBFcnJOb24tRmF0YWwtIEVyckZhdGFsLSBQ
TUVJbnRFbmEtIENSU1Zpc2libGUtDQoJCVJvb3RDYXA6IENSU1Zpc2libGUtDQoJCVJvb3RT
dGE6IFBNRSBSZXFJRCAwMDAwLCBQTUVTdGF0dXMtIFBNRVBlbmRpbmctDQoJCURldkNhcDI6
IENvbXBsZXRpb24gVGltZW91dDogUmFuZ2UgQUJDRCwgVGltZW91dERpcysgQVJJRndkLQ0K
CQlEZXZDdGwyOiBDb21wbGV0aW9uIFRpbWVvdXQ6IDY1bXMgdG8gMjEwbXMsIFRpbWVvdXRE
aXMtIEFSSUZ3ZC0NCgkJTG5rQ3RsMjogVGFyZ2V0IExpbmsgU3BlZWQ6IDIuNUdUL3MsIEVu
dGVyQ29tcGxpYW5jZS0gU3BlZWREaXMtLCBTZWxlY3RhYmxlIERlLWVtcGhhc2lzOiAtMy41
ZEINCgkJCSBUcmFuc21pdCBNYXJnaW46IE5vcm1hbCBPcGVyYXRpbmcgUmFuZ2UsIEVudGVy
TW9kaWZpZWRDb21wbGlhbmNlLSBDb21wbGlhbmNlU09TLQ0KCQkJIENvbXBsaWFuY2UgRGUt
ZW1waGFzaXM6IC02ZEINCgkJTG5rU3RhMjogQ3VycmVudCBEZS1lbXBoYXNpcyBMZXZlbDog
LTZkQg0KCUNhcGFiaWxpdGllczogW2EwXSBNU0k6IEVuYWJsZSsgQ291bnQ9MS8xIE1hc2th
YmxlLSA2NGJpdCsNCgkJQWRkcmVzczogMDAwMDAwMDBmZWUzZjAwYyAgRGF0YTogNDE5MQ0K
CUNhcGFiaWxpdGllczogW2IwXSBTdWJzeXN0ZW06IEFUSSBUZWNobm9sb2dpZXMgSW5jIERl
dmljZSBbMTAwMjowMDAwXQ0KCUNhcGFiaWxpdGllczogW2I4XSBIeXBlclRyYW5zcG9ydDog
TVNJIE1hcHBpbmcgRW5hYmxlKyBGaXhlZCsNCglDYXBhYmlsaXRpZXM6IFsxMDAgdjFdIFZl
bmRvciBTcGVjaWZpYyBJbmZvcm1hdGlvbjogSUQ9MDAwMSBSZXY9MSBMZW49MDEwIDw/Pg0K
CUtlcm5lbCBkcml2ZXIgaW4gdXNlOiBwY2llcG9ydA0KDQowMDoxNi4wIFVTQiBjb250cm9s
bGVyIFswYzAzXTogQVRJIFRlY2hub2xvZ2llcyBJbmMgU0I3eDAvU0I4eDAvU0I5eDAgVVNC
IE9IQ0kwIENvbnRyb2xsZXIgWzEwMDI6NDM5N10gKHByb2ctaWYgMTAgW09IQ0ldKQ0KCVN1
YnN5c3RlbTogTWljcm8tU3RhciBJbnRlcm5hdGlvbmFsIENvLiwgTHRkLiBEZXZpY2UgWzE0
NjI6NzY0MF0NCglDb250cm9sOiBJL08rIE1lbSsgQnVzTWFzdGVyKyBTcGVjQ3ljbGUtIE1l
bVdJTlYrIFZHQVNub29wLSBQYXJFcnItIFN0ZXBwaW5nLSBTRVJSKyBGYXN0QjJCLSBEaXNJ
TlR4LQ0KCVN0YXR1czogQ2FwLSA2Nk1IeisgVURGLSBGYXN0QjJCKyBQYXJFcnItIERFVlNF
TD1tZWRpdW0gPlRBYm9ydC0gPFRBYm9ydC0gPE1BYm9ydC0gPlNFUlItIDxQRVJSLSBJTlR4
LQ0KCUxhdGVuY3k6IDY0LCBDYWNoZSBMaW5lIFNpemU6IDY0IGJ5dGVzDQoJSW50ZXJydXB0
OiBwaW4gQSByb3V0ZWQgdG8gSVJRIDE4DQoJUmVnaW9uIDA6IE1lbW9yeSBhdCBmOTNmZTAw
MCAoMzItYml0LCBub24tcHJlZmV0Y2hhYmxlKSBbc2l6ZT00S10NCglLZXJuZWwgZHJpdmVy
IGluIHVzZTogb2hjaV9oY2QNCg0KMDA6MTYuMiBVU0IgY29udHJvbGxlciBbMGMwM106IEFU
SSBUZWNobm9sb2dpZXMgSW5jIFNCN3gwL1NCOHgwL1NCOXgwIFVTQiBFSENJIENvbnRyb2xs
ZXIgWzEwMDI6NDM5Nl0gKHByb2ctaWYgMjAgW0VIQ0ldKQ0KCVN1YnN5c3RlbTogTWljcm8t
U3RhciBJbnRlcm5hdGlvbmFsIENvLiwgTHRkLiBEZXZpY2UgWzE0NjI6NzY0MF0NCglDb250
cm9sOiBJL08tIE1lbSsgQnVzTWFzdGVyKyBTcGVjQ3ljbGUtIE1lbVdJTlYrIFZHQVNub29w
LSBQYXJFcnItIFN0ZXBwaW5nLSBTRVJSKyBGYXN0QjJCLSBEaXNJTlR4LQ0KCVN0YXR1czog
Q2FwKyA2Nk1IeisgVURGLSBGYXN0QjJCKyBQYXJFcnItIERFVlNFTD1tZWRpdW0gPlRBYm9y
dC0gPFRBYm9ydC0gPE1BYm9ydC0gPlNFUlItIDxQRVJSLSBJTlR4LQ0KCUxhdGVuY3k6IDY0
LCBDYWNoZSBMaW5lIFNpemU6IDY0IGJ5dGVzDQoJSW50ZXJydXB0OiBwaW4gQiByb3V0ZWQg
dG8gSVJRIDE3DQoJUmVnaW9uIDA6IE1lbW9yeSBhdCBmOTNmZmMwMCAoMzItYml0LCBub24t
cHJlZmV0Y2hhYmxlKSBbc2l6ZT0yNTZdDQoJQ2FwYWJpbGl0aWVzOiBbYzBdIFBvd2VyIE1h
bmFnZW1lbnQgdmVyc2lvbiAyDQoJCUZsYWdzOiBQTUVDbGstIERTSS0gRDErIEQyKyBBdXhD
dXJyZW50PTBtQSBQTUUoRDArLEQxKyxEMissRDNob3QrLEQzY29sZC0pDQoJCVN0YXR1czog
RDAgTm9Tb2Z0UnN0LSBQTUUtRW5hYmxlLSBEU2VsPTAgRFNjYWxlPTAgUE1FLQ0KCQlCcmlk
Z2U6IFBNLSBCMysNCglDYXBhYmlsaXRpZXM6IFtlNF0gRGVidWcgcG9ydDogQkFSPTEgb2Zm
c2V0PTAwZTANCglLZXJuZWwgZHJpdmVyIGluIHVzZTogZWhjaV9oY2QNCg0KMDA6MTguMCBI
b3N0IGJyaWRnZSBbMDYwMF06IEFkdmFuY2VkIE1pY3JvIERldmljZXMgW0FNRF0gRmFtaWx5
IDEwaCBQcm9jZXNzb3IgSHlwZXJUcmFuc3BvcnQgQ29uZmlndXJhdGlvbiBbMTAyMjoxMjAw
XQ0KCUNvbnRyb2w6IEkvTy0gTWVtLSBCdXNNYXN0ZXItIFNwZWNDeWNsZS0gTWVtV0lOVi0g
VkdBU25vb3AtIFBhckVyci0gU3RlcHBpbmctIFNFUlItIEZhc3RCMkItIERpc0lOVHgtDQoJ
U3RhdHVzOiBDYXArIDY2TUh6LSBVREYtIEZhc3RCMkItIFBhckVyci0gREVWU0VMPWZhc3Qg
PlRBYm9ydC0gPFRBYm9ydC0gPE1BYm9ydC0gPlNFUlItIDxQRVJSLSBJTlR4LQ0KCUNhcGFi
aWxpdGllczogWzgwXSBIeXBlclRyYW5zcG9ydDogSG9zdCBvciBTZWNvbmRhcnkgSW50ZXJm
YWNlDQoJCUNvbW1hbmQ6IFdhcm1Sc3QrIERibEVuZC0gRGV2TnVtPTAgQ2hhaW5TaWRlLSBI
b3N0SGlkZSsgU2xhdmUtIDxFT0NFcnItIERVTC0NCgkJTGluayBDb250cm9sOiBDRmxFLSBD
U1QtIENGRS0gPExrRmFpbC0gSW5pdCsgRU9DLSBUWE8tIDxDUkNFcnI9MCBJc29jRW4tIExT
RW4rIEV4dENUTC0gNjRiLQ0KCQlMaW5rIENvbmZpZzogTUxXST0xNmJpdCBEd0ZjSW4tIE1M
V089MTZiaXQgRHdGY091dC0gTFdJPTE2Yml0IER3RmNJbkVuLSBMV089MTZiaXQgRHdGY091
dEVuLQ0KCQlSZXZpc2lvbiBJRDogMy4wMA0KCQlMaW5rIEZyZXF1ZW5jeTogW2JdDQoJCUxp
bmsgRXJyb3I6IDxQcm90LSA8T3ZmbC0gPEVPQy0gQ1RMVG0tDQoJCUxpbmsgRnJlcXVlbmN5
IENhcGFiaWxpdHk6IDIwME1IeisgMzAwTUh6LSA0MDBNSHorIDUwME1Iei0gNjAwTUh6KyA4
MDBNSHorIDEuMEdIeisgMS4yR0h6KyAxLjRHSHotIDEuNkdIei0gVmVuZC0NCgkJRmVhdHVy
ZSBDYXBhYmlsaXR5OiBJc29jRkMrIExEVFNUT1ArIENSQ1RNLSBFQ1RMVC0gNjRiQSsgVUlE
UkQtIEV4dFJTLSBVQ25mRS0NCg0KMDA6MTguMSBIb3N0IGJyaWRnZSBbMDYwMF06IEFkdmFu
Y2VkIE1pY3JvIERldmljZXMgW0FNRF0gRmFtaWx5IDEwaCBQcm9jZXNzb3IgQWRkcmVzcyBN
YXAgWzEwMjI6MTIwMV0NCglDb250cm9sOiBJL08tIE1lbS0gQnVzTWFzdGVyLSBTcGVjQ3lj
bGUtIE1lbVdJTlYtIFZHQVNub29wLSBQYXJFcnItIFN0ZXBwaW5nLSBTRVJSLSBGYXN0QjJC
LSBEaXNJTlR4LQ0KCVN0YXR1czogQ2FwLSA2Nk1Iei0gVURGLSBGYXN0QjJCLSBQYXJFcnIt
IERFVlNFTD1mYXN0ID5UQWJvcnQtIDxUQWJvcnQtIDxNQWJvcnQtID5TRVJSLSA8UEVSUi0g
SU5UeC0NCg0KMDA6MTguMiBIb3N0IGJyaWRnZSBbMDYwMF06IEFkdmFuY2VkIE1pY3JvIERl
dmljZXMgW0FNRF0gRmFtaWx5IDEwaCBQcm9jZXNzb3IgRFJBTSBDb250cm9sbGVyIFsxMDIy
OjEyMDJdDQoJQ29udHJvbDogSS9PLSBNZW0tIEJ1c01hc3Rlci0gU3BlY0N5Y2xlLSBNZW1X
SU5WLSBWR0FTbm9vcC0gUGFyRXJyLSBTdGVwcGluZy0gU0VSUi0gRmFzdEIyQi0gRGlzSU5U
eC0NCglTdGF0dXM6IENhcC0gNjZNSHotIFVERi0gRmFzdEIyQi0gUGFyRXJyLSBERVZTRUw9
ZmFzdCA+VEFib3J0LSA8VEFib3J0LSA8TUFib3J0LSA+U0VSUi0gPFBFUlItIElOVHgtDQoN
CjAwOjE4LjMgSG9zdCBicmlkZ2UgWzA2MDBdOiBBZHZhbmNlZCBNaWNybyBEZXZpY2VzIFtB
TURdIEZhbWlseSAxMGggUHJvY2Vzc29yIE1pc2NlbGxhbmVvdXMgQ29udHJvbCBbMTAyMjox
MjAzXQ0KCUNvbnRyb2w6IEkvTy0gTWVtLSBCdXNNYXN0ZXItIFNwZWNDeWNsZS0gTWVtV0lO
Vi0gVkdBU25vb3AtIFBhckVyci0gU3RlcHBpbmctIFNFUlItIEZhc3RCMkItIERpc0lOVHgt
DQoJU3RhdHVzOiBDYXArIDY2TUh6LSBVREYtIEZhc3RCMkItIFBhckVyci0gREVWU0VMPWZh
c3QgPlRBYm9ydC0gPFRBYm9ydC0gPE1BYm9ydC0gPlNFUlItIDxQRVJSLSBJTlR4LQ0KCUNh
cGFiaWxpdGllczogW2YwXSBTZWN1cmUgZGV2aWNlIDw/Pg0KCUtlcm5lbCBkcml2ZXIgaW4g
dXNlOiBrMTB0ZW1wDQoNCjAwOjE4LjQgSG9zdCBicmlkZ2UgWzA2MDBdOiBBZHZhbmNlZCBN
aWNybyBEZXZpY2VzIFtBTURdIEZhbWlseSAxMGggUHJvY2Vzc29yIExpbmsgQ29udHJvbCBb
MTAyMjoxMjA0XQ0KCUNvbnRyb2w6IEkvTy0gTWVtLSBCdXNNYXN0ZXItIFNwZWNDeWNsZS0g
TWVtV0lOVi0gVkdBU25vb3AtIFBhckVyci0gU3RlcHBpbmctIFNFUlItIEZhc3RCMkItIERp
c0lOVHgtDQoJU3RhdHVzOiBDYXAtIDY2TUh6LSBVREYtIEZhc3RCMkItIFBhckVyci0gREVW
U0VMPWZhc3QgPlRBYm9ydC0gPFRBYm9ydC0gPE1BYm9ydC0gPlNFUlItIDxQRVJSLSBJTlR4
LQ0KDQowMzowNi4wIE11bHRpbWVkaWEgYXVkaW8gY29udHJvbGxlciBbMDQwMV06IEMtTWVk
aWEgRWxlY3Ryb25pY3MgSW5jIENNODczOCBbMTNmNjowMTExXSAocmV2IDEwKQ0KCVN1YnN5
c3RlbTogQy1NZWRpYSBFbGVjdHJvbmljcyBJbmMgQ01JODczOC9DM0RYIFBDSSBBdWRpbyBE
ZXZpY2UgWzEzZjY6MDExMV0NCglDb250cm9sOiBJL08rIE1lbS0gQnVzTWFzdGVyKyBTcGVj
Q3ljbGUtIE1lbVdJTlYtIFZHQVNub29wLSBQYXJFcnItIFN0ZXBwaW5nLSBTRVJSLSBGYXN0
QjJCLSBEaXNJTlR4LQ0KCVN0YXR1czogQ2FwKyA2Nk1Iei0gVURGLSBGYXN0QjJCLSBQYXJF
cnItIERFVlNFTD1tZWRpdW0gPlRBYm9ydC0gPFRBYm9ydC0gPE1BYm9ydC0gPlNFUlItIDxQ
RVJSLSBJTlR4LQ0KCUxhdGVuY3k6IDY0ICg1MDBucyBtaW4sIDYwMDBucyBtYXgpDQoJSW50
ZXJydXB0OiBwaW4gQSByb3V0ZWQgdG8gSVJRIDIyDQoJUmVnaW9uIDA6IEkvTyBwb3J0cyBh
dCBhODAwIFtzaXplPTI1Nl0NCglDYXBhYmlsaXRpZXM6IFtjMF0gUG93ZXIgTWFuYWdlbWVu
dCB2ZXJzaW9uIDINCgkJRmxhZ3M6IFBNRUNsay0gRFNJLSBEMSsgRDIrIEF1eEN1cnJlbnQ9
MG1BIFBNRShEMC0sRDEtLEQyLSxEM2hvdC0sRDNjb2xkLSkNCgkJU3RhdHVzOiBEMCBOb1Nv
ZnRSc3QtIFBNRS1FbmFibGUtIERTZWw9MCBEU2NhbGU9MCBQTUUtDQoJS2VybmVsIGRyaXZl
ciBpbiB1c2U6IHBjaWJhY2sNCg0KMDQ6MDAuMCBVU0IgY29udHJvbGxlciBbMGMwM106IE5l
dE1vcyBUZWNobm9sb2d5IE1DUzk5OTAgUENJZSB0byA04oCQUG9ydCBVU0IgMi4wIEhvc3Qg
Q29udHJvbGxlciBbOTcxMDo5OTkwXSAocHJvZy1pZiAxMCBbT0hDSV0pDQoJU3Vic3lzdGVt
OiBEZXZpY2UgW2EwMDA6NDAwMF0NCglDb250cm9sOiBJL08tIE1lbS0gQnVzTWFzdGVyLSBT
cGVjQ3ljbGUtIE1lbVdJTlYtIFZHQVNub29wLSBQYXJFcnItIFN0ZXBwaW5nLSBTRVJSLSBG
YXN0QjJCLSBEaXNJTlR4LQ0KCVN0YXR1czogQ2FwKyA2Nk1Iei0gVURGLSBGYXN0QjJCLSBQ
YXJFcnItIERFVlNFTD1mYXN0ID5UQWJvcnQtIDxUQWJvcnQtIDxNQWJvcnQtID5TRVJSLSA8
UEVSUi0gSU5UeC0NCglJbnRlcnJ1cHQ6IHBpbiBBIHJvdXRlZCB0byBJUlEgNDANCglSZWdp
b24gMDogTWVtb3J5IGF0IGY5NWY4MDAwICgzMi1iaXQsIG5vbi1wcmVmZXRjaGFibGUpIFtk
aXNhYmxlZF0gW3NpemU9NEtdDQoJQ2FwYWJpbGl0aWVzOiBbNTBdIE1TSTogRW5hYmxlLSBD
b3VudD0xLzEgTWFza2FibGUtIDY0Yml0Kw0KCQlBZGRyZXNzOiAwMDAwMDAwMDAwMDAwMDAw
ICBEYXRhOiAwMDAwDQoJQ2FwYWJpbGl0aWVzOiBbNzhdIFBvd2VyIE1hbmFnZW1lbnQgdmVy
c2lvbiAzDQoJCUZsYWdzOiBQTUVDbGstIERTSS0gRDErIEQyKyBBdXhDdXJyZW50PTM3NW1B
IFBNRShEMCssRDErLEQyKyxEM2hvdCssRDNjb2xkLSkNCgkJU3RhdHVzOiBEMCBOb1NvZnRS
c3QrIFBNRS1FbmFibGUtIERTZWw9MCBEU2NhbGU9MCBQTUUtDQoJQ2FwYWJpbGl0aWVzOiBb
ODBdIEV4cHJlc3MgKHYxKSBFbmRwb2ludCwgTVNJIDAwDQoJCURldkNhcDoJTWF4UGF5bG9h
ZCAyNTYgYnl0ZXMsIFBoYW50RnVuYyAwLCBMYXRlbmN5IEwwcyB1bmxpbWl0ZWQsIEwxIHVu
bGltaXRlZA0KCQkJRXh0VGFnLSBBdHRuQnRuLSBBdHRuSW5kLSBQd3JJbmQtIFJCRSsgRkxS
ZXNldC0NCgkJRGV2Q3RsOglSZXBvcnQgZXJyb3JzOiBDb3JyZWN0YWJsZS0gTm9uLUZhdGFs
LSBGYXRhbC0gVW5zdXBwb3J0ZWQtDQoJCQlSbHhkT3JkLSBFeHRUYWctIFBoYW50RnVuYy0g
QXV4UHdyLSBOb1Nub29wKw0KCQkJTWF4UGF5bG9hZCAxMjggYnl0ZXMsIE1heFJlYWRSZXEg
NTEyIGJ5dGVzDQoJCURldlN0YToJQ29yckVyci0gVW5jb3JyRXJyLSBGYXRhbEVyci0gVW5z
dXBwUmVxLSBBdXhQd3ItIFRyYW5zUGVuZC0NCgkJTG5rQ2FwOglQb3J0ICMxLCBTcGVlZCAy
LjVHVC9zLCBXaWR0aCB4MSwgQVNQTSB1bmtub3duLCBMYXRlbmN5IEwwIDw2NG5zLCBMMSB1
bmxpbWl0ZWQNCgkJCUNsb2NrUE0rIFN1cnByaXNlLSBMTEFjdFJlcC0gQndOb3QtDQoJCUxu
a0N0bDoJQVNQTSBEaXNhYmxlZDsgUkNCIDY0IGJ5dGVzIERpc2FibGVkLSBSZXRyYWluLSBD
b21tQ2xrLQ0KCQkJRXh0U3luY2gtIENsb2NrUE0tIEF1dFdpZERpcy0gQldJbnQtIEF1dEJX
SW50LQ0KCQlMbmtTdGE6CVNwZWVkIDIuNUdUL3MsIFdpZHRoIHgxLCBUckVyci0gVHJhaW4t
IFNsb3RDbGstIERMQWN0aXZlLSBCV01nbXQtIEFCV01nbXQtDQoJQ2FwYWJpbGl0aWVzOiBb
MTAwIHYxXSBWaXJ0dWFsIENoYW5uZWwNCgkJQ2FwczoJTFBFVkM9MCBSZWZDbGs9MTAwbnMg
UEFURW50cnlCaXRzPTENCgkJQXJiOglGaXhlZC0gV1JSMzItIFdSUjY0LSBXUlIxMjgtDQoJ
CUN0cmw6CUFyYlNlbGVjdD1GaXhlZA0KCQlTdGF0dXM6CUluUHJvZ3Jlc3MtDQoJCVZDMDoJ
Q2FwczoJUEFUT2Zmc2V0PTAwIE1heFRpbWVTbG90cz0xIFJlalNub29wVHJhbnMtDQoJCQlB
cmI6CUZpeGVkLSBXUlIzMi0gV1JSNjQtIFdSUjEyOC0gVFdSUjEyOC0gV1JSMjU2LQ0KCQkJ
Q3RybDoJRW5hYmxlKyBJRD0wIEFyYlNlbGVjdD1GaXhlZCBUQy9WQz1mZg0KCQkJU3RhdHVz
OglOZWdvUGVuZGluZy0gSW5Qcm9ncmVzcy0NCglLZXJuZWwgZHJpdmVyIGluIHVzZTogcGNp
YmFjaw0KDQowNDowMC4xIFVTQiBjb250cm9sbGVyIFswYzAzXTogTmV0TW9zIFRlY2hub2xv
Z3kgTUNTOTk5MCBQQ0llIHRvIDTigJBQb3J0IFVTQiAyLjAgSG9zdCBDb250cm9sbGVyIFs5
NzEwOjk5OTBdIChwcm9nLWlmIDIwIFtFSENJXSkNCglTdWJzeXN0ZW06IERldmljZSBbYTAw
MDo0MDAwXQ0KCUNvbnRyb2w6IEkvTy0gTWVtLSBCdXNNYXN0ZXItIFNwZWNDeWNsZS0gTWVt
V0lOVi0gVkdBU25vb3AtIFBhckVyci0gU3RlcHBpbmctIFNFUlItIEZhc3RCMkItIERpc0lO
VHgtDQoJU3RhdHVzOiBDYXArIDY2TUh6LSBVREYtIEZhc3RCMkItIFBhckVyci0gREVWU0VM
PWZhc3QgPlRBYm9ydC0gPFRBYm9ydC0gPE1BYm9ydC0gPlNFUlItIDxQRVJSLSBJTlR4LQ0K
CUludGVycnVwdDogcGluIEEgcm91dGVkIHRvIElSUSA0MA0KCVJlZ2lvbiAwOiBNZW1vcnkg
YXQgZjk1ZjkwMDAgKDMyLWJpdCwgbm9uLXByZWZldGNoYWJsZSkgW2Rpc2FibGVkXSBbc2l6
ZT00S10NCglDYXBhYmlsaXRpZXM6IFs1MF0gTVNJOiBFbmFibGUtIENvdW50PTEvMSBNYXNr
YWJsZS0gNjRiaXQrDQoJCUFkZHJlc3M6IDAwMDAwMDAwMDAwMDAwMDAgIERhdGE6IDAwMDAN
CglDYXBhYmlsaXRpZXM6IFs3OF0gUG93ZXIgTWFuYWdlbWVudCB2ZXJzaW9uIDMNCgkJRmxh
Z3M6IFBNRUNsay0gRFNJLSBEMSsgRDIrIEF1eEN1cnJlbnQ9Mzc1bUEgUE1FKEQwKyxEMSss
RDIrLEQzaG90KyxEM2NvbGQtKQ0KCQlTdGF0dXM6IEQwIE5vU29mdFJzdCsgUE1FLUVuYWJs
ZS0gRFNlbD0wIERTY2FsZT0wIFBNRS0NCglDYXBhYmlsaXRpZXM6IFs4MF0gRXhwcmVzcyAo
djEpIEVuZHBvaW50LCBNU0kgMDANCgkJRGV2Q2FwOglNYXhQYXlsb2FkIDI1NiBieXRlcywg
UGhhbnRGdW5jIDAsIExhdGVuY3kgTDBzIHVubGltaXRlZCwgTDEgdW5saW1pdGVkDQoJCQlF
eHRUYWctIEF0dG5CdG4tIEF0dG5JbmQtIFB3ckluZC0gUkJFKyBGTFJlc2V0LQ0KCQlEZXZD
dGw6CVJlcG9ydCBlcnJvcnM6IENvcnJlY3RhYmxlLSBOb24tRmF0YWwtIEZhdGFsLSBVbnN1
cHBvcnRlZC0NCgkJCVJseGRPcmQtIEV4dFRhZy0gUGhhbnRGdW5jLSBBdXhQd3ItIE5vU25v
b3ArDQoJCQlNYXhQYXlsb2FkIDEyOCBieXRlcywgTWF4UmVhZFJlcSA1MTIgYnl0ZXMNCgkJ
RGV2U3RhOglDb3JyRXJyLSBVbmNvcnJFcnItIEZhdGFsRXJyLSBVbnN1cHBSZXEtIEF1eFB3
ci0gVHJhbnNQZW5kLQ0KCQlMbmtDYXA6CVBvcnQgIzEsIFNwZWVkIDIuNUdUL3MsIFdpZHRo
IHgxLCBBU1BNIHVua25vd24sIExhdGVuY3kgTDAgPDY0bnMsIEwxIHVubGltaXRlZA0KCQkJ
Q2xvY2tQTSsgU3VycHJpc2UtIExMQWN0UmVwLSBCd05vdC0NCgkJTG5rQ3RsOglBU1BNIERp
c2FibGVkOyBSQ0IgNjQgYnl0ZXMgRGlzYWJsZWQtIFJldHJhaW4tIENvbW1DbGstDQoJCQlF
eHRTeW5jaC0gQ2xvY2tQTS0gQXV0V2lkRGlzLSBCV0ludC0gQXV0QldJbnQtDQoJCUxua1N0
YToJU3BlZWQgMi41R1QvcywgV2lkdGggeDEsIFRyRXJyLSBUcmFpbi0gU2xvdENsay0gRExB
Y3RpdmUtIEJXTWdtdC0gQUJXTWdtdC0NCglLZXJuZWwgZHJpdmVyIGluIHVzZTogcGNpYmFj
aw0KDQowNDowMC4yIFVTQiBjb250cm9sbGVyIFswYzAzXTogTmV0TW9zIFRlY2hub2xvZ3kg
TUNTOTk5MCBQQ0llIHRvIDTigJBQb3J0IFVTQiAyLjAgSG9zdCBDb250cm9sbGVyIFs5NzEw
Ojk5OTBdIChwcm9nLWlmIDEwIFtPSENJXSkNCglTdWJzeXN0ZW06IERldmljZSBbYTAwMDo0
MDAwXQ0KCUNvbnRyb2w6IEkvTy0gTWVtLSBCdXNNYXN0ZXItIFNwZWNDeWNsZS0gTWVtV0lO
Vi0gVkdBU25vb3AtIFBhckVyci0gU3RlcHBpbmctIFNFUlItIEZhc3RCMkItIERpc0lOVHgt
DQoJU3RhdHVzOiBDYXArIDY2TUh6LSBVREYtIEZhc3RCMkItIFBhckVyci0gREVWU0VMPWZh
c3QgPlRBYm9ydC0gPFRBYm9ydC0gPE1BYm9ydC0gPlNFUlItIDxQRVJSLSBJTlR4LQ0KCUlu
dGVycnVwdDogcGluIEIgcm91dGVkIHRvIElSUSA0MQ0KCVJlZ2lvbiAwOiBNZW1vcnkgYXQg
Zjk1ZmEwMDAgKDMyLWJpdCwgbm9uLXByZWZldGNoYWJsZSkgW2Rpc2FibGVkXSBbc2l6ZT00
S10NCglDYXBhYmlsaXRpZXM6IFs1MF0gTVNJOiBFbmFibGUtIENvdW50PTEvMSBNYXNrYWJs
ZS0gNjRiaXQrDQoJCUFkZHJlc3M6IDAwMDAwMDAwMDAwMDAwMDAgIERhdGE6IDAwMDANCglD
YXBhYmlsaXRpZXM6IFs3OF0gUG93ZXIgTWFuYWdlbWVudCB2ZXJzaW9uIDMNCgkJRmxhZ3M6
IFBNRUNsay0gRFNJLSBEMSsgRDIrIEF1eEN1cnJlbnQ9Mzc1bUEgUE1FKEQwKyxEMSssRDIr
LEQzaG90KyxEM2NvbGQtKQ0KCQlTdGF0dXM6IEQwIE5vU29mdFJzdCsgUE1FLUVuYWJsZS0g
RFNlbD0wIERTY2FsZT0wIFBNRS0NCglDYXBhYmlsaXRpZXM6IFs4MF0gRXhwcmVzcyAodjEp
IEVuZHBvaW50LCBNU0kgMDANCgkJRGV2Q2FwOglNYXhQYXlsb2FkIDI1NiBieXRlcywgUGhh
bnRGdW5jIDAsIExhdGVuY3kgTDBzIHVubGltaXRlZCwgTDEgdW5saW1pdGVkDQoJCQlFeHRU
YWctIEF0dG5CdG4tIEF0dG5JbmQtIFB3ckluZC0gUkJFKyBGTFJlc2V0LQ0KCQlEZXZDdGw6
CVJlcG9ydCBlcnJvcnM6IENvcnJlY3RhYmxlLSBOb24tRmF0YWwtIEZhdGFsLSBVbnN1cHBv
cnRlZC0NCgkJCVJseGRPcmQtIEV4dFRhZy0gUGhhbnRGdW5jLSBBdXhQd3ItIE5vU25vb3Ar
DQoJCQlNYXhQYXlsb2FkIDEyOCBieXRlcywgTWF4UmVhZFJlcSA1MTIgYnl0ZXMNCgkJRGV2
U3RhOglDb3JyRXJyLSBVbmNvcnJFcnItIEZhdGFsRXJyLSBVbnN1cHBSZXEtIEF1eFB3ci0g
VHJhbnNQZW5kLQ0KCQlMbmtDYXA6CVBvcnQgIzEsIFNwZWVkIDIuNUdUL3MsIFdpZHRoIHgx
LCBBU1BNIHVua25vd24sIExhdGVuY3kgTDAgPDY0bnMsIEwxIHVubGltaXRlZA0KCQkJQ2xv
Y2tQTSsgU3VycHJpc2UtIExMQWN0UmVwLSBCd05vdC0NCgkJTG5rQ3RsOglBU1BNIERpc2Fi
bGVkOyBSQ0IgNjQgYnl0ZXMgRGlzYWJsZWQtIFJldHJhaW4tIENvbW1DbGstDQoJCQlFeHRT
eW5jaC0gQ2xvY2tQTS0gQXV0V2lkRGlzLSBCV0ludC0gQXV0QldJbnQtDQoJCUxua1N0YToJ
U3BlZWQgMi41R1QvcywgV2lkdGggeDEsIFRyRXJyLSBUcmFpbi0gU2xvdENsay0gRExBY3Rp
dmUtIEJXTWdtdC0gQUJXTWdtdC0NCglLZXJuZWwgZHJpdmVyIGluIHVzZTogcGNpYmFjaw0K
DQowNDowMC4zIFVTQiBjb250cm9sbGVyIFswYzAzXTogTmV0TW9zIFRlY2hub2xvZ3kgTUNT
OTk5MCBQQ0llIHRvIDTigJBQb3J0IFVTQiAyLjAgSG9zdCBDb250cm9sbGVyIFs5NzEwOjk5
OTBdIChwcm9nLWlmIDIwIFtFSENJXSkNCglTdWJzeXN0ZW06IERldmljZSBbYTAwMDo0MDAw
XQ0KCUNvbnRyb2w6IEkvTy0gTWVtLSBCdXNNYXN0ZXItIFNwZWNDeWNsZS0gTWVtV0lOVi0g
VkdBU25vb3AtIFBhckVyci0gU3RlcHBpbmctIFNFUlItIEZhc3RCMkItIERpc0lOVHgtDQoJ
U3RhdHVzOiBDYXArIDY2TUh6LSBVREYtIEZhc3RCMkItIFBhckVyci0gREVWU0VMPWZhc3Qg
PlRBYm9ydC0gPFRBYm9ydC0gPE1BYm9ydC0gPlNFUlItIDxQRVJSLSBJTlR4LQ0KCUludGVy
cnVwdDogcGluIEIgcm91dGVkIHRvIElSUSA0MQ0KCVJlZ2lvbiAwOiBNZW1vcnkgYXQgZjk1
ZmIwMDAgKDMyLWJpdCwgbm9uLXByZWZldGNoYWJsZSkgW2Rpc2FibGVkXSBbc2l6ZT00S10N
CglDYXBhYmlsaXRpZXM6IFs1MF0gTVNJOiBFbmFibGUtIENvdW50PTEvMSBNYXNrYWJsZS0g
NjRiaXQrDQoJCUFkZHJlc3M6IDAwMDAwMDAwMDAwMDAwMDAgIERhdGE6IDAwMDANCglDYXBh
YmlsaXRpZXM6IFs3OF0gUG93ZXIgTWFuYWdlbWVudCB2ZXJzaW9uIDMNCgkJRmxhZ3M6IFBN
RUNsay0gRFNJLSBEMSsgRDIrIEF1eEN1cnJlbnQ9Mzc1bUEgUE1FKEQwKyxEMSssRDIrLEQz
aG90KyxEM2NvbGQtKQ0KCQlTdGF0dXM6IEQwIE5vU29mdFJzdCsgUE1FLUVuYWJsZS0gRFNl
bD0wIERTY2FsZT0wIFBNRS0NCglDYXBhYmlsaXRpZXM6IFs4MF0gRXhwcmVzcyAodjEpIEVu
ZHBvaW50LCBNU0kgMDANCgkJRGV2Q2FwOglNYXhQYXlsb2FkIDI1NiBieXRlcywgUGhhbnRG
dW5jIDAsIExhdGVuY3kgTDBzIHVubGltaXRlZCwgTDEgdW5saW1pdGVkDQoJCQlFeHRUYWct
IEF0dG5CdG4tIEF0dG5JbmQtIFB3ckluZC0gUkJFKyBGTFJlc2V0LQ0KCQlEZXZDdGw6CVJl
cG9ydCBlcnJvcnM6IENvcnJlY3RhYmxlLSBOb24tRmF0YWwtIEZhdGFsLSBVbnN1cHBvcnRl
ZC0NCgkJCVJseGRPcmQtIEV4dFRhZy0gUGhhbnRGdW5jLSBBdXhQd3ItIE5vU25vb3ArDQoJ
CQlNYXhQYXlsb2FkIDEyOCBieXRlcywgTWF4UmVhZFJlcSA1MTIgYnl0ZXMNCgkJRGV2U3Rh
OglDb3JyRXJyLSBVbmNvcnJFcnItIEZhdGFsRXJyLSBVbnN1cHBSZXEtIEF1eFB3ci0gVHJh
bnNQZW5kLQ0KCQlMbmtDYXA6CVBvcnQgIzEsIFNwZWVkIDIuNUdUL3MsIFdpZHRoIHgxLCBB
U1BNIHVua25vd24sIExhdGVuY3kgTDAgPDY0bnMsIEwxIHVubGltaXRlZA0KCQkJQ2xvY2tQ
TSsgU3VycHJpc2UtIExMQWN0UmVwLSBCd05vdC0NCgkJTG5rQ3RsOglBU1BNIERpc2FibGVk
OyBSQ0IgNjQgYnl0ZXMgRGlzYWJsZWQtIFJldHJhaW4tIENvbW1DbGstDQoJCQlFeHRTeW5j
aC0gQ2xvY2tQTS0gQXV0V2lkRGlzLSBCV0ludC0gQXV0QldJbnQtDQoJCUxua1N0YToJU3Bl
ZWQgMi41R1QvcywgV2lkdGggeDEsIFRyRXJyLSBUcmFpbi0gU2xvdENsay0gRExBY3RpdmUt
IEJXTWdtdC0gQUJXTWdtdC0NCglLZXJuZWwgZHJpdmVyIGluIHVzZTogcGNpYmFjaw0KDQow
NDowMC40IFVTQiBjb250cm9sbGVyIFswYzAzXTogTmV0TW9zIFRlY2hub2xvZ3kgTUNTOTk5
MCBQQ0llIHRvIDTigJBQb3J0IFVTQiAyLjAgSG9zdCBDb250cm9sbGVyIFs5NzEwOjk5OTBd
IChwcm9nLWlmIDEwIFtPSENJXSkNCglTdWJzeXN0ZW06IERldmljZSBbYTAwMDo0MDAwXQ0K
CUNvbnRyb2w6IEkvTy0gTWVtLSBCdXNNYXN0ZXItIFNwZWNDeWNsZS0gTWVtV0lOVi0gVkdB
U25vb3AtIFBhckVyci0gU3RlcHBpbmctIFNFUlItIEZhc3RCMkItIERpc0lOVHgtDQoJU3Rh
dHVzOiBDYXArIDY2TUh6LSBVREYtIEZhc3RCMkItIFBhckVyci0gREVWU0VMPWZhc3QgPlRB
Ym9ydC0gPFRBYm9ydC0gPE1BYm9ydC0gPlNFUlItIDxQRVJSLSBJTlR4LQ0KCUludGVycnVw
dDogcGluIEMgcm91dGVkIHRvIElSUSA0Mg0KCVJlZ2lvbiAwOiBNZW1vcnkgYXQgZjk1ZmMw
MDAgKDMyLWJpdCwgbm9uLXByZWZldGNoYWJsZSkgW2Rpc2FibGVkXSBbc2l6ZT00S10NCglD
YXBhYmlsaXRpZXM6IFs1MF0gTVNJOiBFbmFibGUtIENvdW50PTEvMSBNYXNrYWJsZS0gNjRi
aXQrDQoJCUFkZHJlc3M6IDAwMDAwMDAwMDAwMDAwMDAgIERhdGE6IDAwMDANCglDYXBhYmls
aXRpZXM6IFs3OF0gUG93ZXIgTWFuYWdlbWVudCB2ZXJzaW9uIDMNCgkJRmxhZ3M6IFBNRUNs
ay0gRFNJLSBEMSsgRDIrIEF1eEN1cnJlbnQ9Mzc1bUEgUE1FKEQwKyxEMSssRDIrLEQzaG90
KyxEM2NvbGQtKQ0KCQlTdGF0dXM6IEQwIE5vU29mdFJzdCsgUE1FLUVuYWJsZS0gRFNlbD0w
IERTY2FsZT0wIFBNRS0NCglDYXBhYmlsaXRpZXM6IFs4MF0gRXhwcmVzcyAodjEpIEVuZHBv
aW50LCBNU0kgMDANCgkJRGV2Q2FwOglNYXhQYXlsb2FkIDI1NiBieXRlcywgUGhhbnRGdW5j
IDAsIExhdGVuY3kgTDBzIHVubGltaXRlZCwgTDEgdW5saW1pdGVkDQoJCQlFeHRUYWctIEF0
dG5CdG4tIEF0dG5JbmQtIFB3ckluZC0gUkJFKyBGTFJlc2V0LQ0KCQlEZXZDdGw6CVJlcG9y
dCBlcnJvcnM6IENvcnJlY3RhYmxlLSBOb24tRmF0YWwtIEZhdGFsLSBVbnN1cHBvcnRlZC0N
CgkJCVJseGRPcmQtIEV4dFRhZy0gUGhhbnRGdW5jLSBBdXhQd3ItIE5vU25vb3ArDQoJCQlN
YXhQYXlsb2FkIDEyOCBieXRlcywgTWF4UmVhZFJlcSA1MTIgYnl0ZXMNCgkJRGV2U3RhOglD
b3JyRXJyLSBVbmNvcnJFcnItIEZhdGFsRXJyLSBVbnN1cHBSZXEtIEF1eFB3ci0gVHJhbnNQ
ZW5kLQ0KCQlMbmtDYXA6CVBvcnQgIzEsIFNwZWVkIDIuNUdUL3MsIFdpZHRoIHgxLCBBU1BN
IHVua25vd24sIExhdGVuY3kgTDAgPDY0bnMsIEwxIHVubGltaXRlZA0KCQkJQ2xvY2tQTSsg
U3VycHJpc2UtIExMQWN0UmVwLSBCd05vdC0NCgkJTG5rQ3RsOglBU1BNIERpc2FibGVkOyBS
Q0IgNjQgYnl0ZXMgRGlzYWJsZWQtIFJldHJhaW4tIENvbW1DbGstDQoJCQlFeHRTeW5jaC0g
Q2xvY2tQTS0gQXV0V2lkRGlzLSBCV0ludC0gQXV0QldJbnQtDQoJCUxua1N0YToJU3BlZWQg
Mi41R1QvcywgV2lkdGggeDEsIFRyRXJyLSBUcmFpbi0gU2xvdENsay0gRExBY3RpdmUtIEJX
TWdtdC0gQUJXTWdtdC0NCglLZXJuZWwgZHJpdmVyIGluIHVzZTogcGNpYmFjaw0KDQowNDow
MC41IFVTQiBjb250cm9sbGVyIFswYzAzXTogTmV0TW9zIFRlY2hub2xvZ3kgTUNTOTk5MCBQ
Q0llIHRvIDTigJBQb3J0IFVTQiAyLjAgSG9zdCBDb250cm9sbGVyIFs5NzEwOjk5OTBdIChw
cm9nLWlmIDIwIFtFSENJXSkNCglTdWJzeXN0ZW06IERldmljZSBbYTAwMDo0MDAwXQ0KCUNv
bnRyb2w6IEkvTy0gTWVtLSBCdXNNYXN0ZXItIFNwZWNDeWNsZS0gTWVtV0lOVi0gVkdBU25v
b3AtIFBhckVyci0gU3RlcHBpbmctIFNFUlItIEZhc3RCMkItIERpc0lOVHgtDQoJU3RhdHVz
OiBDYXArIDY2TUh6LSBVREYtIEZhc3RCMkItIFBhckVyci0gREVWU0VMPWZhc3QgPlRBYm9y
dC0gPFRBYm9ydC0gPE1BYm9ydC0gPlNFUlItIDxQRVJSLSBJTlR4LQ0KCUludGVycnVwdDog
cGluIEMgcm91dGVkIHRvIElSUSA0Mg0KCVJlZ2lvbiAwOiBNZW1vcnkgYXQgZjk1ZmQwMDAg
KDMyLWJpdCwgbm9uLXByZWZldGNoYWJsZSkgW2Rpc2FibGVkXSBbc2l6ZT00S10NCglDYXBh
YmlsaXRpZXM6IFs1MF0gTVNJOiBFbmFibGUtIENvdW50PTEvMSBNYXNrYWJsZS0gNjRiaXQr
DQoJCUFkZHJlc3M6IDAwMDAwMDAwMDAwMDAwMDAgIERhdGE6IDAwMDANCglDYXBhYmlsaXRp
ZXM6IFs3OF0gUG93ZXIgTWFuYWdlbWVudCB2ZXJzaW9uIDMNCgkJRmxhZ3M6IFBNRUNsay0g
RFNJLSBEMSsgRDIrIEF1eEN1cnJlbnQ9Mzc1bUEgUE1FKEQwKyxEMSssRDIrLEQzaG90KyxE
M2NvbGQtKQ0KCQlTdGF0dXM6IEQwIE5vU29mdFJzdCsgUE1FLUVuYWJsZS0gRFNlbD0wIERT
Y2FsZT0wIFBNRS0NCglDYXBhYmlsaXRpZXM6IFs4MF0gRXhwcmVzcyAodjEpIEVuZHBvaW50
LCBNU0kgMDANCgkJRGV2Q2FwOglNYXhQYXlsb2FkIDI1NiBieXRlcywgUGhhbnRGdW5jIDAs
IExhdGVuY3kgTDBzIHVubGltaXRlZCwgTDEgdW5saW1pdGVkDQoJCQlFeHRUYWctIEF0dG5C
dG4tIEF0dG5JbmQtIFB3ckluZC0gUkJFKyBGTFJlc2V0LQ0KCQlEZXZDdGw6CVJlcG9ydCBl
cnJvcnM6IENvcnJlY3RhYmxlLSBOb24tRmF0YWwtIEZhdGFsLSBVbnN1cHBvcnRlZC0NCgkJ
CVJseGRPcmQtIEV4dFRhZy0gUGhhbnRGdW5jLSBBdXhQd3ItIE5vU25vb3ArDQoJCQlNYXhQ
YXlsb2FkIDEyOCBieXRlcywgTWF4UmVhZFJlcSA1MTIgYnl0ZXMNCgkJRGV2U3RhOglDb3Jy
RXJyLSBVbmNvcnJFcnItIEZhdGFsRXJyLSBVbnN1cHBSZXEtIEF1eFB3ci0gVHJhbnNQZW5k
LQ0KCQlMbmtDYXA6CVBvcnQgIzEsIFNwZWVkIDIuNUdUL3MsIFdpZHRoIHgxLCBBU1BNIHVu
a25vd24sIExhdGVuY3kgTDAgPDY0bnMsIEwxIHVubGltaXRlZA0KCQkJQ2xvY2tQTSsgU3Vy
cHJpc2UtIExMQWN0UmVwLSBCd05vdC0NCgkJTG5rQ3RsOglBU1BNIERpc2FibGVkOyBSQ0Ig
NjQgYnl0ZXMgRGlzYWJsZWQtIFJldHJhaW4tIENvbW1DbGstDQoJCQlFeHRTeW5jaC0gQ2xv
Y2tQTS0gQXV0V2lkRGlzLSBCV0ludC0gQXV0QldJbnQtDQoJCUxua1N0YToJU3BlZWQgMi41
R1QvcywgV2lkdGggeDEsIFRyRXJyLSBUcmFpbi0gU2xvdENsay0gRExBY3RpdmUtIEJXTWdt
dC0gQUJXTWdtdC0NCglLZXJuZWwgZHJpdmVyIGluIHVzZTogcGNpYmFjaw0KDQowNDowMC42
IFVTQiBjb250cm9sbGVyIFswYzAzXTogTmV0TW9zIFRlY2hub2xvZ3kgTUNTOTk5MCBQQ0ll
IHRvIDTigJBQb3J0IFVTQiAyLjAgSG9zdCBDb250cm9sbGVyIFs5NzEwOjk5OTBdIChwcm9n
LWlmIDEwIFtPSENJXSkNCglTdWJzeXN0ZW06IERldmljZSBbYTAwMDo0MDAwXQ0KCUNvbnRy
b2w6IEkvTy0gTWVtLSBCdXNNYXN0ZXItIFNwZWNDeWNsZS0gTWVtV0lOVi0gVkdBU25vb3At
IFBhckVyci0gU3RlcHBpbmctIFNFUlItIEZhc3RCMkItIERpc0lOVHgtDQoJU3RhdHVzOiBD
YXArIDY2TUh6LSBVREYtIEZhc3RCMkItIFBhckVyci0gREVWU0VMPWZhc3QgPlRBYm9ydC0g
PFRBYm9ydC0gPE1BYm9ydC0gPlNFUlItIDxQRVJSLSBJTlR4LQ0KCUludGVycnVwdDogcGlu
IEQgcm91dGVkIHRvIElSUSA0Mw0KCVJlZ2lvbiAwOiBNZW1vcnkgYXQgZjk1ZmUwMDAgKDMy
LWJpdCwgbm9uLXByZWZldGNoYWJsZSkgW2Rpc2FibGVkXSBbc2l6ZT00S10NCglDYXBhYmls
aXRpZXM6IFs1MF0gTVNJOiBFbmFibGUtIENvdW50PTEvMSBNYXNrYWJsZS0gNjRiaXQrDQoJ
CUFkZHJlc3M6IDAwMDAwMDAwMDAwMDAwMDAgIERhdGE6IDAwMDANCglDYXBhYmlsaXRpZXM6
IFs3OF0gUG93ZXIgTWFuYWdlbWVudCB2ZXJzaW9uIDMNCgkJRmxhZ3M6IFBNRUNsay0gRFNJ
LSBEMSsgRDIrIEF1eEN1cnJlbnQ9Mzc1bUEgUE1FKEQwKyxEMSssRDIrLEQzaG90KyxEM2Nv
bGQtKQ0KCQlTdGF0dXM6IEQwIE5vU29mdFJzdCsgUE1FLUVuYWJsZS0gRFNlbD0wIERTY2Fs
ZT0wIFBNRS0NCglDYXBhYmlsaXRpZXM6IFs4MF0gRXhwcmVzcyAodjEpIEVuZHBvaW50LCBN
U0kgMDANCgkJRGV2Q2FwOglNYXhQYXlsb2FkIDI1NiBieXRlcywgUGhhbnRGdW5jIDAsIExh
dGVuY3kgTDBzIHVubGltaXRlZCwgTDEgdW5saW1pdGVkDQoJCQlFeHRUYWctIEF0dG5CdG4t
IEF0dG5JbmQtIFB3ckluZC0gUkJFKyBGTFJlc2V0LQ0KCQlEZXZDdGw6CVJlcG9ydCBlcnJv
cnM6IENvcnJlY3RhYmxlLSBOb24tRmF0YWwtIEZhdGFsLSBVbnN1cHBvcnRlZC0NCgkJCVJs
eGRPcmQtIEV4dFRhZy0gUGhhbnRGdW5jLSBBdXhQd3ItIE5vU25vb3ArDQoJCQlNYXhQYXls
b2FkIDEyOCBieXRlcywgTWF4UmVhZFJlcSA1MTIgYnl0ZXMNCgkJRGV2U3RhOglDb3JyRXJy
LSBVbmNvcnJFcnItIEZhdGFsRXJyLSBVbnN1cHBSZXEtIEF1eFB3ci0gVHJhbnNQZW5kLQ0K
CQlMbmtDYXA6CVBvcnQgIzEsIFNwZWVkIDIuNUdUL3MsIFdpZHRoIHgxLCBBU1BNIHVua25v
d24sIExhdGVuY3kgTDAgPDY0bnMsIEwxIHVubGltaXRlZA0KCQkJQ2xvY2tQTSsgU3VycHJp
c2UtIExMQWN0UmVwLSBCd05vdC0NCgkJTG5rQ3RsOglBU1BNIERpc2FibGVkOyBSQ0IgNjQg
Ynl0ZXMgRGlzYWJsZWQtIFJldHJhaW4tIENvbW1DbGstDQoJCQlFeHRTeW5jaC0gQ2xvY2tQ
TS0gQXV0V2lkRGlzLSBCV0ludC0gQXV0QldJbnQtDQoJCUxua1N0YToJU3BlZWQgMi41R1Qv
cywgV2lkdGggeDEsIFRyRXJyLSBUcmFpbi0gU2xvdENsay0gRExBY3RpdmUtIEJXTWdtdC0g
QUJXTWdtdC0NCglLZXJuZWwgZHJpdmVyIGluIHVzZTogcGNpYmFjaw0KDQowNDowMC43IFVT
QiBjb250cm9sbGVyIFswYzAzXTogTmV0TW9zIFRlY2hub2xvZ3kgTUNTOTk5MCBQQ0llIHRv
IDTigJBQb3J0IFVTQiAyLjAgSG9zdCBDb250cm9sbGVyIFs5NzEwOjk5OTBdIChwcm9nLWlm
IDIwIFtFSENJXSkNCglTdWJzeXN0ZW06IERldmljZSBbYTAwMDo0MDAwXQ0KCUNvbnRyb2w6
IEkvTy0gTWVtLSBCdXNNYXN0ZXItIFNwZWNDeWNsZS0gTWVtV0lOVi0gVkdBU25vb3AtIFBh
ckVyci0gU3RlcHBpbmctIFNFUlItIEZhc3RCMkItIERpc0lOVHgtDQoJU3RhdHVzOiBDYXAr
IDY2TUh6LSBVREYtIEZhc3RCMkItIFBhckVyci0gREVWU0VMPWZhc3QgPlRBYm9ydC0gPFRB
Ym9ydC0gPE1BYm9ydC0gPlNFUlItIDxQRVJSLSBJTlR4LQ0KCUludGVycnVwdDogcGluIEQg
cm91dGVkIHRvIElSUSA0Mw0KCVJlZ2lvbiAwOiBNZW1vcnkgYXQgZjk1ZmYwMDAgKDMyLWJp
dCwgbm9uLXByZWZldGNoYWJsZSkgW2Rpc2FibGVkXSBbc2l6ZT00S10NCglDYXBhYmlsaXRp
ZXM6IFs1MF0gTVNJOiBFbmFibGUtIENvdW50PTEvMSBNYXNrYWJsZS0gNjRiaXQrDQoJCUFk
ZHJlc3M6IDAwMDAwMDAwMDAwMDAwMDAgIERhdGE6IDAwMDANCglDYXBhYmlsaXRpZXM6IFs3
OF0gUG93ZXIgTWFuYWdlbWVudCB2ZXJzaW9uIDMNCgkJRmxhZ3M6IFBNRUNsay0gRFNJLSBE
MSsgRDIrIEF1eEN1cnJlbnQ9Mzc1bUEgUE1FKEQwKyxEMSssRDIrLEQzaG90KyxEM2NvbGQt
KQ0KCQlTdGF0dXM6IEQwIE5vU29mdFJzdCsgUE1FLUVuYWJsZS0gRFNlbD0wIERTY2FsZT0w
IFBNRS0NCglDYXBhYmlsaXRpZXM6IFs4MF0gRXhwcmVzcyAodjEpIEVuZHBvaW50LCBNU0kg
MDANCgkJRGV2Q2FwOglNYXhQYXlsb2FkIDI1NiBieXRlcywgUGhhbnRGdW5jIDAsIExhdGVu
Y3kgTDBzIHVubGltaXRlZCwgTDEgdW5saW1pdGVkDQoJCQlFeHRUYWctIEF0dG5CdG4tIEF0
dG5JbmQtIFB3ckluZC0gUkJFKyBGTFJlc2V0LQ0KCQlEZXZDdGw6CVJlcG9ydCBlcnJvcnM6
IENvcnJlY3RhYmxlLSBOb24tRmF0YWwtIEZhdGFsLSBVbnN1cHBvcnRlZC0NCgkJCVJseGRP
cmQtIEV4dFRhZy0gUGhhbnRGdW5jLSBBdXhQd3ItIE5vU25vb3ArDQoJCQlNYXhQYXlsb2Fk
IDEyOCBieXRlcywgTWF4UmVhZFJlcSA1MTIgYnl0ZXMNCgkJRGV2U3RhOglDb3JyRXJyLSBV
bmNvcnJFcnItIEZhdGFsRXJyLSBVbnN1cHBSZXEtIEF1eFB3ci0gVHJhbnNQZW5kLQ0KCQlM
bmtDYXA6CVBvcnQgIzEsIFNwZWVkIDIuNUdUL3MsIFdpZHRoIHgxLCBBU1BNIHVua25vd24s
IExhdGVuY3kgTDAgPDY0bnMsIEwxIHVubGltaXRlZA0KCQkJQ2xvY2tQTSsgU3VycHJpc2Ut
IExMQWN0UmVwLSBCd05vdC0NCgkJTG5rQ3RsOglBU1BNIERpc2FibGVkOyBSQ0IgNjQgYnl0
ZXMgRGlzYWJsZWQtIFJldHJhaW4tIENvbW1DbGstDQoJCQlFeHRTeW5jaC0gQ2xvY2tQTS0g
QXV0V2lkRGlzLSBCV0ludC0gQXV0QldJbnQtDQoJCUxua1N0YToJU3BlZWQgMi41R1Qvcywg
V2lkdGggeDEsIFRyRXJyLSBUcmFpbi0gU2xvdENsay0gRExBY3RpdmUtIEJXTWdtdC0gQUJX
TWdtdC0NCglLZXJuZWwgZHJpdmVyIGluIHVzZTogcGNpYmFjaw0KDQowNTowMC4wIE11bHRp
bWVkaWEgdmlkZW8gY29udHJvbGxlciBbMDQwMF06IENvbmV4YW50IFN5c3RlbXMsIEluYy4g
Q1gyNTg1MCBbMTRmMTo4MjAwXQ0KCUNvbnRyb2w6IEkvTy0gTWVtLSBCdXNNYXN0ZXItIFNw
ZWNDeWNsZS0gTWVtV0lOVi0gVkdBU25vb3AtIFBhckVyci0gU3RlcHBpbmctIFNFUlItIEZh
c3RCMkItIERpc0lOVHgtDQoJU3RhdHVzOiBDYXArIDY2TUh6LSBVREYtIEZhc3RCMkItIFBh
ckVyci0gREVWU0VMPWZhc3QgPlRBYm9ydC0gPFRBYm9ydC0gPE1BYm9ydC0gPlNFUlItIDxQ
RVJSLSBJTlR4LQ0KCUludGVycnVwdDogcGluIEEgcm91dGVkIHRvIElSUSAzNg0KCVJlZ2lv
biAwOiBNZW1vcnkgYXQgZjk2MDAwMDAgKDY0LWJpdCwgbm9uLXByZWZldGNoYWJsZSkgW2Rp
c2FibGVkXSBbc2l6ZT0yTV0NCglDYXBhYmlsaXRpZXM6IFs0MF0gRXhwcmVzcyAodjEpIEVu
ZHBvaW50LCBNU0kgMDANCgkJRGV2Q2FwOglNYXhQYXlsb2FkIDEyOCBieXRlcywgUGhhbnRG
dW5jIDAsIExhdGVuY3kgTDBzIDw2NG5zLCBMMSA8MXVzDQoJCQlFeHRUYWctIEF0dG5CdG4t
IEF0dG5JbmQtIFB3ckluZC0gUkJFKyBGTFJlc2V0LQ0KCQlEZXZDdGw6CVJlcG9ydCBlcnJv
cnM6IENvcnJlY3RhYmxlLSBOb24tRmF0YWwtIEZhdGFsLSBVbnN1cHBvcnRlZC0NCgkJCVJs
eGRPcmQrIEV4dFRhZy0gUGhhbnRGdW5jLSBBdXhQd3ItIE5vU25vb3ArDQoJCQlNYXhQYXls
b2FkIDEyOCBieXRlcywgTWF4UmVhZFJlcSA1MTIgYnl0ZXMNCgkJRGV2U3RhOglDb3JyRXJy
LSBVbmNvcnJFcnItIEZhdGFsRXJyLSBVbnN1cHBSZXEtIEF1eFB3ci0gVHJhbnNQZW5kLQ0K
CQlMbmtDYXA6CVBvcnQgIzAsIFNwZWVkIDIuNUdUL3MsIFdpZHRoIHgxLCBBU1BNIEwwcyBM
MSwgTGF0ZW5jeSBMMCA8MnVzLCBMMSA8NHVzDQoJCQlDbG9ja1BNLSBTdXJwcmlzZS0gTExB
Y3RSZXAtIEJ3Tm90LQ0KCQlMbmtDdGw6CUFTUE0gRGlzYWJsZWQ7IFJDQiA2NCBieXRlcyBE
aXNhYmxlZC0gUmV0cmFpbi0gQ29tbUNsay0NCgkJCUV4dFN5bmNoLSBDbG9ja1BNLSBBdXRX
aWREaXMtIEJXSW50LSBBdXRCV0ludC0NCgkJTG5rU3RhOglTcGVlZCAyLjVHVC9zLCBXaWR0
aCB4MSwgVHJFcnItIFRyYWluLSBTbG90Q2xrLSBETEFjdGl2ZS0gQldNZ210LSBBQldNZ210
LQ0KCUNhcGFiaWxpdGllczogWzgwXSBQb3dlciBNYW5hZ2VtZW50IHZlcnNpb24gMw0KCQlG
bGFnczogUE1FQ2xrLSBEU0krIEQxKyBEMisgQXV4Q3VycmVudD0wbUEgUE1FKEQwKyxEMSss
RDIrLEQzaG90KyxEM2NvbGQtKQ0KCQlTdGF0dXM6IEQwIE5vU29mdFJzdCsgUE1FLUVuYWJs
ZS0gRFNlbD0wIERTY2FsZT0wIFBNRS0NCglDYXBhYmlsaXRpZXM6IFs5MF0gVml0YWwgUHJv
ZHVjdCBEYXRhDQoJCVVua25vd24gc21hbGwgcmVzb3VyY2UgdHlwZSAwMCwgd2lsbCBub3Qg
ZGVjb2RlIG1vcmUuDQoJQ2FwYWJpbGl0aWVzOiBbYTBdIE1TSTogRW5hYmxlLSBDb3VudD0x
LzEgTWFza2FibGUtIDY0Yml0Kw0KCQlBZGRyZXNzOiAwMDAwMDAwMDAwMDAwMDAwICBEYXRh
OiAwMDAwDQoJQ2FwYWJpbGl0aWVzOiBbMTAwIHYxXSBBZHZhbmNlZCBFcnJvciBSZXBvcnRp
bmcNCgkJVUVTdGE6CURMUC0gU0RFUy0gVExQLSBGQ1AtIENtcGx0VE8tIENtcGx0QWJydC0g
VW54Q21wbHQtIFJ4T0YtIE1hbGZUTFAtIEVDUkMtIFVuc3VwUmVxLSBBQ1NWaW9sLQ0KCQlV
RU1zazoJRExQLSBTREVTLSBUTFAtIEZDUC0gQ21wbHRUTy0gQ21wbHRBYnJ0LSBVbnhDbXBs
dC0gUnhPRi0gTWFsZlRMUC0gRUNSQy0gVW5zdXBSZXEtIEFDU1Zpb2wtDQoJCVVFU3ZydDoJ
RExQKyBTREVTLSBUTFAtIEZDUCsgQ21wbHRUTy0gQ21wbHRBYnJ0LSBVbnhDbXBsdC0gUnhP
RisgTWFsZlRMUCsgRUNSQy0gVW5zdXBSZXEtIEFDU1Zpb2wtDQoJCUNFU3RhOglSeEVyci0g
QmFkVExQLSBCYWRETExQLSBSb2xsb3Zlci0gVGltZW91dC0gTm9uRmF0YWxFcnIrDQoJCUNF
TXNrOglSeEVyci0gQmFkVExQLSBCYWRETExQLSBSb2xsb3Zlci0gVGltZW91dC0gTm9uRmF0
YWxFcnIrDQoJCUFFUkNhcDoJRmlyc3QgRXJyb3IgUG9pbnRlcjogMDAsIEdlbkNhcC0gQ0dl
bkVuLSBDaGtDYXAtIENoa0VuLQ0KCUNhcGFiaWxpdGllczogWzIwMCB2MV0gVmlydHVhbCBD
aGFubmVsDQoJCUNhcHM6CUxQRVZDPTEgUmVmQ2xrPTEwMG5zIFBBVEVudHJ5Qml0cz0xDQoJ
CUFyYjoJRml4ZWQrIFdSUjMyKyBXUlI2NCsgV1JSMTI4LQ0KCQlDdHJsOglBcmJTZWxlY3Q9
V1JSNjQNCgkJU3RhdHVzOglJblByb2dyZXNzLQ0KCQlQb3J0IEFyYml0cmF0aW9uIFRhYmxl
IFsyNDBdIDw/Pg0KCQlWQzA6CUNhcHM6CVBBVE9mZnNldD0wMCBNYXhUaW1lU2xvdHM9MSBS
ZWpTbm9vcFRyYW5zLQ0KCQkJQXJiOglGaXhlZC0gV1JSMzItIFdSUjY0LSBXUlIxMjgtIFRX
UlIxMjgtIFdSUjI1Ni0NCgkJCUN0cmw6CUVuYWJsZSsgSUQ9MCBBcmJTZWxlY3Q9Rml4ZWQg
VEMvVkM9ZmYNCgkJCVN0YXR1czoJTmVnb1BlbmRpbmctIEluUHJvZ3Jlc3MtDQoJCVZDMToJ
Q2FwczoJUEFUT2Zmc2V0PTAwIE1heFRpbWVTbG90cz0xIFJlalNub29wVHJhbnMtDQoJCQlB
cmI6CUZpeGVkLSBXUlIzMi0gV1JSNjQtIFdSUjEyOC0gVFdSUjEyOC0gV1JSMjU2LQ0KCQkJ
Q3RybDoJRW5hYmxlLSBJRD0xIEFyYlNlbGVjdD1GaXhlZCBUQy9WQz0wMA0KCQkJU3RhdHVz
OglOZWdvUGVuZGluZy0gSW5Qcm9ncmVzcy0NCglLZXJuZWwgZHJpdmVyIGluIHVzZTogcGNp
YmFjaw0KDQowNjowMC4wIFZHQSBjb21wYXRpYmxlIGNvbnRyb2xsZXIgWzAzMDBdOiBBVEkg
VGVjaG5vbG9naWVzIEluYyBSVjYyMCBMRSBbUmFkZW9uIEhEIDM0NTBdIFsxMDAyOjk1YzVd
IChwcm9nLWlmIDAwIFtWR0EgY29udHJvbGxlcl0pDQoJU3Vic3lzdGVtOiBBU1VTVGVLIENv
bXB1dGVyIEluYy4gRGV2aWNlIFsxMDQzOjAxZDRdDQoJQ29udHJvbDogSS9PLSBNZW0tIEJ1
c01hc3Rlci0gU3BlY0N5Y2xlLSBNZW1XSU5WLSBWR0FTbm9vcC0gUGFyRXJyLSBTdGVwcGlu
Zy0gU0VSUi0gRmFzdEIyQi0gRGlzSU5UeC0NCglTdGF0dXM6IENhcCsgNjZNSHotIFVERi0g
RmFzdEIyQi0gUGFyRXJyLSBERVZTRUw9ZmFzdCA+VEFib3J0LSA8VEFib3J0LSA8TUFib3J0
LSA+U0VSUi0gPFBFUlItIElOVHgtDQoJSW50ZXJydXB0OiBwaW4gQSByb3V0ZWQgdG8gSVJR
IDEwDQoJUmVnaW9uIDA6IE1lbW9yeSBhdCBiMDAwMDAwMCAoNjQtYml0LCBwcmVmZXRjaGFi
bGUpIFtkaXNhYmxlZF0gW3NpemU9MjU2TV0NCglSZWdpb24gMjogTWVtb3J5IGF0IGY5OWUw
MDAwICg2NC1iaXQsIG5vbi1wcmVmZXRjaGFibGUpIFtkaXNhYmxlZF0gW3NpemU9NjRLXQ0K
CVJlZ2lvbiA0OiBJL08gcG9ydHMgYXQgYjAwMCBbZGlzYWJsZWRdIFtzaXplPTI1Nl0NCglF
eHBhbnNpb24gUk9NIGF0IGY5OWMwMDAwIFtkaXNhYmxlZF0gW3NpemU9MTI4S10NCglDYXBh
YmlsaXRpZXM6IFs1MF0gUG93ZXIgTWFuYWdlbWVudCB2ZXJzaW9uIDMNCgkJRmxhZ3M6IFBN
RUNsay0gRFNJLSBEMSsgRDIrIEF1eEN1cnJlbnQ9MG1BIFBNRShEMC0sRDEtLEQyLSxEM2hv
dC0sRDNjb2xkLSkNCgkJU3RhdHVzOiBEMCBOb1NvZnRSc3QtIFBNRS1FbmFibGUtIERTZWw9
MCBEU2NhbGU9MCBQTUUtDQoJQ2FwYWJpbGl0aWVzOiBbNThdIEV4cHJlc3MgKHYyKSBMZWdh
Y3kgRW5kcG9pbnQsIE1TSSAwMA0KCQlEZXZDYXA6CU1heFBheWxvYWQgMTI4IGJ5dGVzLCBQ
aGFudEZ1bmMgMCwgTGF0ZW5jeSBMMHMgPDR1cywgTDEgdW5saW1pdGVkDQoJCQlFeHRUYWcr
IEF0dG5CdG4tIEF0dG5JbmQtIFB3ckluZC0gUkJFKyBGTFJlc2V0LQ0KCQlEZXZDdGw6CVJl
cG9ydCBlcnJvcnM6IENvcnJlY3RhYmxlLSBOb24tRmF0YWwtIEZhdGFsLSBVbnN1cHBvcnRl
ZC0NCgkJCVJseGRPcmQrIEV4dFRhZy0gUGhhbnRGdW5jLSBBdXhQd3ItIE5vU25vb3ArDQoJ
CQlNYXhQYXlsb2FkIDEyOCBieXRlcywgTWF4UmVhZFJlcSAxMjggYnl0ZXMNCgkJRGV2U3Rh
OglDb3JyRXJyLSBVbmNvcnJFcnItIEZhdGFsRXJyLSBVbnN1cHBSZXEtIEF1eFB3ci0gVHJh
bnNQZW5kLQ0KCQlMbmtDYXA6CVBvcnQgIzAsIFNwZWVkIDIuNUdUL3MsIFdpZHRoIHgxNiwg
QVNQTSBMMHMgTDEsIExhdGVuY3kgTDAgPDY0bnMsIEwxIDwxdXMNCgkJCUNsb2NrUE0tIFN1
cnByaXNlLSBMTEFjdFJlcC0gQndOb3QtDQoJCUxua0N0bDoJQVNQTSBEaXNhYmxlZDsgUkNC
IDY0IGJ5dGVzIERpc2FibGVkLSBSZXRyYWluLSBDb21tQ2xrKw0KCQkJRXh0U3luY2gtIENs
b2NrUE0tIEF1dFdpZERpcy0gQldJbnQtIEF1dEJXSW50LQ0KCQlMbmtTdGE6CVNwZWVkIDIu
NUdUL3MsIFdpZHRoIHgxLCBUckVyci0gVHJhaW4tIFNsb3RDbGsrIERMQWN0aXZlLSBCV01n
bXQtIEFCV01nbXQtDQoJCURldkNhcDI6IENvbXBsZXRpb24gVGltZW91dDogTm90IFN1cHBv
cnRlZCwgVGltZW91dERpcy0NCgkJRGV2Q3RsMjogQ29tcGxldGlvbiBUaW1lb3V0OiA1MHVz
IHRvIDUwbXMsIFRpbWVvdXREaXMtDQoJCUxua0N0bDI6IFRhcmdldCBMaW5rIFNwZWVkOiAy
LjVHVC9zLCBFbnRlckNvbXBsaWFuY2UtIFNwZWVkRGlzLSwgU2VsZWN0YWJsZSBEZS1lbXBo
YXNpczogLTZkQg0KCQkJIFRyYW5zbWl0IE1hcmdpbjogTm9ybWFsIE9wZXJhdGluZyBSYW5n
ZSwgRW50ZXJNb2RpZmllZENvbXBsaWFuY2UtIENvbXBsaWFuY2VTT1MtDQoJCQkgQ29tcGxp
YW5jZSBEZS1lbXBoYXNpczogLTZkQg0KCQlMbmtTdGEyOiBDdXJyZW50IERlLWVtcGhhc2lz
IExldmVsOiAtNmRCDQoJQ2FwYWJpbGl0aWVzOiBbYTBdIE1TSTogRW5hYmxlLSBDb3VudD0x
LzEgTWFza2FibGUtIDY0Yml0Kw0KCQlBZGRyZXNzOiAwMDAwMDAwMDAwMDAwMDAwICBEYXRh
OiAwMDAwDQoJQ2FwYWJpbGl0aWVzOiBbMTAwIHYxXSBWZW5kb3IgU3BlY2lmaWMgSW5mb3Jt
YXRpb246IElEPTAwMDEgUmV2PTEgTGVuPTAxMCA8Pz4NCg0KMDY6MDAuMSBBdWRpbyBkZXZp
Y2UgWzA0MDNdOiBBVEkgVGVjaG5vbG9naWVzIEluYyBSVjYyMCBBdWRpbyBkZXZpY2UgW1Jh
ZGVvbiBIRCAzNHh4IFNlcmllc10gWzEwMDI6YWEyOF0NCglTdWJzeXN0ZW06IEFTVVNUZUsg
Q29tcHV0ZXIgSW5jLiBEZXZpY2UgWzEwNDM6YWEyOF0NCglDb250cm9sOiBJL08rIE1lbSsg
QnVzTWFzdGVyKyBTcGVjQ3ljbGUtIE1lbVdJTlYtIFZHQVNub29wLSBQYXJFcnItIFN0ZXBw
aW5nLSBTRVJSKyBGYXN0QjJCLSBEaXNJTlR4Kw0KCVN0YXR1czogQ2FwKyA2Nk1Iei0gVURG
LSBGYXN0QjJCLSBQYXJFcnItIERFVlNFTD1mYXN0ID5UQWJvcnQtIDxUQWJvcnQtIDxNQWJv
cnQtID5TRVJSLSA8UEVSUi0gSU5UeC0NCglMYXRlbmN5OiAwLCBDYWNoZSBMaW5lIFNpemU6
IDY0IGJ5dGVzDQoJSW50ZXJydXB0OiBwaW4gQiByb3V0ZWQgdG8gSVJRIDEyMw0KCVJlZ2lv
biAwOiBNZW1vcnkgYXQgZjk5ZmMwMDAgKDY0LWJpdCwgbm9uLXByZWZldGNoYWJsZSkgW3Np
emU9MTZLXQ0KCUNhcGFiaWxpdGllczogWzUwXSBQb3dlciBNYW5hZ2VtZW50IHZlcnNpb24g
Mw0KCQlGbGFnczogUE1FQ2xrLSBEU0ktIEQxKyBEMisgQXV4Q3VycmVudD0wbUEgUE1FKEQw
LSxEMS0sRDItLEQzaG90LSxEM2NvbGQtKQ0KCQlTdGF0dXM6IEQwIE5vU29mdFJzdC0gUE1F
LUVuYWJsZS0gRFNlbD0wIERTY2FsZT0wIFBNRS0NCglDYXBhYmlsaXRpZXM6IFs1OF0gRXhw
cmVzcyAodjIpIExlZ2FjeSBFbmRwb2ludCwgTVNJIDAwDQoJCURldkNhcDoJTWF4UGF5bG9h
ZCAxMjggYnl0ZXMsIFBoYW50RnVuYyAwLCBMYXRlbmN5IEwwcyA8NHVzLCBMMSB1bmxpbWl0
ZWQNCgkJCUV4dFRhZysgQXR0bkJ0bi0gQXR0bkluZC0gUHdySW5kLSBSQkUrIEZMUmVzZXQt
DQoJCURldkN0bDoJUmVwb3J0IGVycm9yczogQ29ycmVjdGFibGUtIE5vbi1GYXRhbC0gRmF0
YWwtIFVuc3VwcG9ydGVkLQ0KCQkJUmx4ZE9yZCsgRXh0VGFnLSBQaGFudEZ1bmMtIEF1eFB3
ci0gTm9Tbm9vcCsNCgkJCU1heFBheWxvYWQgMTI4IGJ5dGVzLCBNYXhSZWFkUmVxIDEyOCBi
eXRlcw0KCQlEZXZTdGE6CUNvcnJFcnItIFVuY29yckVyci0gRmF0YWxFcnItIFVuc3VwcFJl
cS0gQXV4UHdyLSBUcmFuc1BlbmQtDQoJCUxua0NhcDoJUG9ydCAjMCwgU3BlZWQgMi41R1Qv
cywgV2lkdGggeDE2LCBBU1BNIEwwcyBMMSwgTGF0ZW5jeSBMMCA8NjRucywgTDEgPDF1cw0K
CQkJQ2xvY2tQTS0gU3VycHJpc2UtIExMQWN0UmVwLSBCd05vdC0NCgkJTG5rQ3RsOglBU1BN
IERpc2FibGVkOyBSQ0IgNjQgYnl0ZXMgRGlzYWJsZWQtIFJldHJhaW4tIENvbW1DbGsrDQoJ
CQlFeHRTeW5jaC0gQ2xvY2tQTS0gQXV0V2lkRGlzLSBCV0ludC0gQXV0QldJbnQtDQoJCUxu
a1N0YToJU3BlZWQgMi41R1QvcywgV2lkdGggeDEsIFRyRXJyLSBUcmFpbi0gU2xvdENsaysg
RExBY3RpdmUtIEJXTWdtdC0gQUJXTWdtdC0NCgkJRGV2Q2FwMjogQ29tcGxldGlvbiBUaW1l
b3V0OiBOb3QgU3VwcG9ydGVkLCBUaW1lb3V0RGlzLQ0KCQlEZXZDdGwyOiBDb21wbGV0aW9u
IFRpbWVvdXQ6IDUwdXMgdG8gNTBtcywgVGltZW91dERpcy0NCgkJTG5rQ3RsMjogVGFyZ2V0
IExpbmsgU3BlZWQ6IDIuNUdUL3MsIEVudGVyQ29tcGxpYW5jZS0gU3BlZWREaXMtLCBTZWxl
Y3RhYmxlIERlLWVtcGhhc2lzOiAtNmRCDQoJCQkgVHJhbnNtaXQgTWFyZ2luOiBOb3JtYWwg
T3BlcmF0aW5nIFJhbmdlLCBFbnRlck1vZGlmaWVkQ29tcGxpYW5jZS0gQ29tcGxpYW5jZVNP
Uy0NCgkJCSBDb21wbGlhbmNlIERlLWVtcGhhc2lzOiAtNmRCDQoJCUxua1N0YTI6IEN1cnJl
bnQgRGUtZW1waGFzaXMgTGV2ZWw6IC02ZEINCglDYXBhYmlsaXRpZXM6IFthMF0gTVNJOiBF
bmFibGUrIENvdW50PTEvMSBNYXNrYWJsZS0gNjRiaXQrDQoJCUFkZHJlc3M6IDAwMDAwMDAw
ZmVlMDEwMGMgIERhdGE6IDQxMmENCglDYXBhYmlsaXRpZXM6IFsxMDAgdjFdIFZlbmRvciBT
cGVjaWZpYyBJbmZvcm1hdGlvbjogSUQ9MDAwMSBSZXY9MSBMZW49MDEwIDw/Pg0KCUtlcm5l
bCBkcml2ZXIgaW4gdXNlOiBzbmRfaGRhX2ludGVsDQoNCjA3OjAwLjAgTXVsdGltZWRpYSB2
aWRlbyBjb250cm9sbGVyIFswNDAwXTogQ29uZXhhbnQgU3lzdGVtcywgSW5jLiBEZXZpY2Ug
WzE0ZjE6ODIxMF0NCglDb250cm9sOiBJL08tIE1lbSsgQnVzTWFzdGVyLSBTcGVjQ3ljbGUt
IE1lbVdJTlYtIFZHQVNub29wLSBQYXJFcnItIFN0ZXBwaW5nLSBTRVJSLSBGYXN0QjJCLSBE
aXNJTlR4LQ0KCVN0YXR1czogQ2FwKyA2Nk1Iei0gVURGLSBGYXN0QjJCLSBQYXJFcnItIERF
VlNFTD1mYXN0ID5UQWJvcnQtIDxUQWJvcnQtIDxNQWJvcnQtID5TRVJSLSA8UEVSUi0gSU5U
eC0NCglJbnRlcnJ1cHQ6IHBpbiBBIHJvdXRlZCB0byBJUlEgNDcNCglSZWdpb24gMDogTWVt
b3J5IGF0IGY5YTAwMDAwICg2NC1iaXQsIG5vbi1wcmVmZXRjaGFibGUpIFtzaXplPTJNXQ0K
CUNhcGFiaWxpdGllczogWzQwXSBFeHByZXNzICh2MSkgRW5kcG9pbnQsIE1TSSAwMA0KCQlE
ZXZDYXA6CU1heFBheWxvYWQgMTI4IGJ5dGVzLCBQaGFudEZ1bmMgMCwgTGF0ZW5jeSBMMHMg
PDY0bnMsIEwxIDwxdXMNCgkJCUV4dFRhZy0gQXR0bkJ0bi0gQXR0bkluZC0gUHdySW5kLSBS
QkUrIEZMUmVzZXQtDQoJCURldkN0bDoJUmVwb3J0IGVycm9yczogQ29ycmVjdGFibGUtIE5v
bi1GYXRhbC0gRmF0YWwtIFVuc3VwcG9ydGVkLQ0KCQkJUmx4ZE9yZCsgRXh0VGFnLSBQaGFu
dEZ1bmMtIEF1eFB3ci0gTm9Tbm9vcCsNCgkJCU1heFBheWxvYWQgMTI4IGJ5dGVzLCBNYXhS
ZWFkUmVxIDUxMiBieXRlcw0KCQlEZXZTdGE6CUNvcnJFcnItIFVuY29yckVyci0gRmF0YWxF
cnItIFVuc3VwcFJlcS0gQXV4UHdyLSBUcmFuc1BlbmQtDQoJCUxua0NhcDoJUG9ydCAjMCwg
U3BlZWQgMi41R1QvcywgV2lkdGggeDEsIEFTUE0gTDBzIEwxLCBMYXRlbmN5IEwwIDwydXMs
IEwxIDw0dXMNCgkJCUNsb2NrUE0tIFN1cnByaXNlLSBMTEFjdFJlcC0gQndOb3QtDQoJCUxu
a0N0bDoJQVNQTSBEaXNhYmxlZDsgUkNCIDY0IGJ5dGVzIERpc2FibGVkLSBSZXRyYWluLSBD
b21tQ2xrLQ0KCQkJRXh0U3luY2gtIENsb2NrUE0tIEF1dFdpZERpcy0gQldJbnQtIEF1dEJX
SW50LQ0KCQlMbmtTdGE6CVNwZWVkIDIuNUdUL3MsIFdpZHRoIHgxLCBUckVyci0gVHJhaW4t
IFNsb3RDbGstIERMQWN0aXZlLSBCV01nbXQtIEFCV01nbXQtDQoJQ2FwYWJpbGl0aWVzOiBb
ODBdIFBvd2VyIE1hbmFnZW1lbnQgdmVyc2lvbiAzDQoJCUZsYWdzOiBQTUVDbGstIERTSSsg
RDErIEQyKyBBdXhDdXJyZW50PTBtQSBQTUUoRDArLEQxKyxEMissRDNob3QrLEQzY29sZC0p
DQoJCVN0YXR1czogRDAgTm9Tb2Z0UnN0KyBQTUUtRW5hYmxlLSBEU2VsPTAgRFNjYWxlPTAg
UE1FLQ0KCUNhcGFiaWxpdGllczogWzkwXSBWaXRhbCBQcm9kdWN0IERhdGENCgkJVW5rbm93
biBzbWFsbCByZXNvdXJjZSB0eXBlIDAyLCB3aWxsIG5vdCBkZWNvZGUgbW9yZS4NCglDYXBh
YmlsaXRpZXM6IFthMF0gTVNJOiBFbmFibGUtIENvdW50PTEvMSBNYXNrYWJsZS0gNjRiaXQr
DQoJCUFkZHJlc3M6IDAwMDAwMDAwMDAwMDAwMDAgIERhdGE6IDAwMDANCglDYXBhYmlsaXRp
ZXM6IFsxMDAgdjFdIEFkdmFuY2VkIEVycm9yIFJlcG9ydGluZw0KCQlVRVN0YToJRExQLSBT
REVTLSBUTFAtIEZDUC0gQ21wbHRUTy0gQ21wbHRBYnJ0LSBVbnhDbXBsdC0gUnhPRi0gTWFs
ZlRMUC0gRUNSQy0gVW5zdXBSZXEtIEFDU1Zpb2wtDQoJCVVFTXNrOglETFAtIFNERVMtIFRM
UC0gRkNQLSBDbXBsdFRPLSBDbXBsdEFicnQtIFVueENtcGx0LSBSeE9GLSBNYWxmVExQLSBF
Q1JDLSBVbnN1cFJlcS0gQUNTVmlvbC0NCgkJVUVTdnJ0OglETFArIFNERVMtIFRMUC0gRkNQ
KyBDbXBsdFRPLSBDbXBsdEFicnQtIFVueENtcGx0LSBSeE9GKyBNYWxmVExQKyBFQ1JDLSBV
bnN1cFJlcS0gQUNTVmlvbC0NCgkJQ0VTdGE6CVJ4RXJyLSBCYWRUTFAtIEJhZERMTFAtIFJv
bGxvdmVyLSBUaW1lb3V0LSBOb25GYXRhbEVycisNCgkJQ0VNc2s6CVJ4RXJyLSBCYWRUTFAt
IEJhZERMTFAtIFJvbGxvdmVyLSBUaW1lb3V0LSBOb25GYXRhbEVycisNCgkJQUVSQ2FwOglG
aXJzdCBFcnJvciBQb2ludGVyOiAwMCwgR2VuQ2FwLSBDR2VuRW4tIENoa0NhcC0gQ2hrRW4t
DQoJQ2FwYWJpbGl0aWVzOiBbMjAwIHYxXSBWaXJ0dWFsIENoYW5uZWwNCgkJQ2FwczoJTFBF
VkM9MSBSZWZDbGs9MTAwbnMgUEFURW50cnlCaXRzPTENCgkJQXJiOglGaXhlZCsgV1JSMzIr
IFdSUjY0KyBXUlIxMjgtDQoJCUN0cmw6CUFyYlNlbGVjdD1XUlI2NA0KCQlTdGF0dXM6CUlu
UHJvZ3Jlc3MtDQoJCVBvcnQgQXJiaXRyYXRpb24gVGFibGUgWzI0MF0gPD8+DQoJCVZDMDoJ
Q2FwczoJUEFUT2Zmc2V0PTAwIE1heFRpbWVTbG90cz0xIFJlalNub29wVHJhbnMtDQoJCQlB
cmI6CUZpeGVkLSBXUlIzMi0gV1JSNjQtIFdSUjEyOC0gVFdSUjEyOC0gV1JSMjU2LQ0KCQkJ
Q3RybDoJRW5hYmxlKyBJRD0wIEFyYlNlbGVjdD1GaXhlZCBUQy9WQz1mZg0KCQkJU3RhdHVz
OglOZWdvUGVuZGluZy0gSW5Qcm9ncmVzcy0NCgkJVkMxOglDYXBzOglQQVRPZmZzZXQ9MDAg
TWF4VGltZVNsb3RzPTEgUmVqU25vb3BUcmFucy0NCgkJCUFyYjoJRml4ZWQtIFdSUjMyLSBX
UlI2NC0gV1JSMTI4LSBUV1JSMTI4LSBXUlIyNTYtDQoJCQlDdHJsOglFbmFibGUtIElEPTEg
QXJiU2VsZWN0PUZpeGVkIFRDL1ZDPTAwDQoJCQlTdGF0dXM6CU5lZ29QZW5kaW5nLSBJblBy
b2dyZXNzLQ0KCUtlcm5lbCBkcml2ZXIgaW4gdXNlOiBwY2liYWNrDQoNCjA4OjAwLjAgRXRo
ZXJuZXQgY29udHJvbGxlciBbMDIwMF06IFJlYWx0ZWsgU2VtaWNvbmR1Y3RvciBDby4sIEx0
ZC4gUlRMODExMS84MTY4QiBQQ0kgRXhwcmVzcyBHaWdhYml0IEV0aGVybmV0IGNvbnRyb2xs
ZXIgWzEwZWM6ODE2OF0gKHJldiAwMykNCglTdWJzeXN0ZW06IE1pY3JvLVN0YXIgSW50ZXJu
YXRpb25hbCBDby4sIEx0ZC4gRGV2aWNlIFsxNDYyOjc2NDBdDQoJQ29udHJvbDogSS9PKyBN
ZW0rIEJ1c01hc3RlcisgU3BlY0N5Y2xlLSBNZW1XSU5WLSBWR0FTbm9vcC0gUGFyRXJyLSBT
dGVwcGluZy0gU0VSUisgRmFzdEIyQi0gRGlzSU5UeCsNCglTdGF0dXM6IENhcCsgNjZNSHot
IFVERi0gRmFzdEIyQi0gUGFyRXJyLSBERVZTRUw9ZmFzdCA+VEFib3J0LSA8VEFib3J0LSA8
TUFib3J0LSA+U0VSUi0gPFBFUlItIElOVHgtDQoJTGF0ZW5jeTogMCwgQ2FjaGUgTGluZSBT
aXplOiA2NCBieXRlcw0KCUludGVycnVwdDogcGluIEEgcm91dGVkIHRvIElSUSAxMjINCglS
ZWdpb24gMDogSS9PIHBvcnRzIGF0IGM4MDAgW3NpemU9MjU2XQ0KCVJlZ2lvbiAyOiBNZW1v
cnkgYXQgY2ZlZmYwMDAgKDY0LWJpdCwgcHJlZmV0Y2hhYmxlKSBbc2l6ZT00S10NCglSZWdp
b24gNDogTWVtb3J5IGF0IGNmZWY4MDAwICg2NC1iaXQsIHByZWZldGNoYWJsZSkgW3NpemU9
MTZLXQ0KCUV4cGFuc2lvbiBST00gYXQgZjlkZTAwMDAgW2Rpc2FibGVkXSBbc2l6ZT0xMjhL
XQ0KCUNhcGFiaWxpdGllczogWzQwXSBQb3dlciBNYW5hZ2VtZW50IHZlcnNpb24gMw0KCQlG
bGFnczogUE1FQ2xrLSBEU0ktIEQxKyBEMisgQXV4Q3VycmVudD0zNzVtQSBQTUUoRDArLEQx
KyxEMissRDNob3QrLEQzY29sZCspDQoJCVN0YXR1czogRDAgTm9Tb2Z0UnN0KyBQTUUtRW5h
YmxlLSBEU2VsPTAgRFNjYWxlPTAgUE1FLQ0KCUNhcGFiaWxpdGllczogWzUwXSBNU0k6IEVu
YWJsZSsgQ291bnQ9MS8xIE1hc2thYmxlLSA2NGJpdCsNCgkJQWRkcmVzczogMDAwMDAwMDBm
ZWUwMTAwYyAgRGF0YTogNDFkOQ0KCUNhcGFiaWxpdGllczogWzcwXSBFeHByZXNzICh2Mikg
RW5kcG9pbnQsIE1TSSAwMQ0KCQlEZXZDYXA6CU1heFBheWxvYWQgMjU2IGJ5dGVzLCBQaGFu
dEZ1bmMgMCwgTGF0ZW5jeSBMMHMgPDUxMm5zLCBMMSA8NjR1cw0KCQkJRXh0VGFnLSBBdHRu
QnRuLSBBdHRuSW5kLSBQd3JJbmQtIFJCRSsgRkxSZXNldC0NCgkJRGV2Q3RsOglSZXBvcnQg
ZXJyb3JzOiBDb3JyZWN0YWJsZS0gTm9uLUZhdGFsLSBGYXRhbC0gVW5zdXBwb3J0ZWQtDQoJ
CQlSbHhkT3JkLSBFeHRUYWctIFBoYW50RnVuYy0gQXV4UHdyLSBOb1Nub29wLQ0KCQkJTWF4
UGF5bG9hZCAxMjggYnl0ZXMsIE1heFJlYWRSZXEgNTEyIGJ5dGVzDQoJCURldlN0YToJQ29y
ckVycisgVW5jb3JyRXJyLSBGYXRhbEVyci0gVW5zdXBwUmVxKyBBdXhQd3IrIFRyYW5zUGVu
ZC0NCgkJTG5rQ2FwOglQb3J0ICMwLCBTcGVlZCAyLjVHVC9zLCBXaWR0aCB4MSwgQVNQTSBM
MHMgTDEsIExhdGVuY3kgTDAgPDUxMm5zLCBMMSA8NjR1cw0KCQkJQ2xvY2tQTSsgU3VycHJp
c2UtIExMQWN0UmVwLSBCd05vdC0NCgkJTG5rQ3RsOglBU1BNIERpc2FibGVkOyBSQ0IgNjQg
Ynl0ZXMgRGlzYWJsZWQtIFJldHJhaW4tIENvbW1DbGsrDQoJCQlFeHRTeW5jaC0gQ2xvY2tQ
TS0gQXV0V2lkRGlzLSBCV0ludC0gQXV0QldJbnQtDQoJCUxua1N0YToJU3BlZWQgMi41R1Qv
cywgV2lkdGggeDEsIFRyRXJyLSBUcmFpbi0gU2xvdENsaysgRExBY3RpdmUtIEJXTWdtdC0g
QUJXTWdtdC0NCgkJRGV2Q2FwMjogQ29tcGxldGlvbiBUaW1lb3V0OiBOb3QgU3VwcG9ydGVk
LCBUaW1lb3V0RGlzKw0KCQlEZXZDdGwyOiBDb21wbGV0aW9uIFRpbWVvdXQ6IDUwdXMgdG8g
NTBtcywgVGltZW91dERpcy0NCgkJTG5rQ3RsMjogVGFyZ2V0IExpbmsgU3BlZWQ6IDIuNUdU
L3MsIEVudGVyQ29tcGxpYW5jZS0gU3BlZWREaXMtLCBTZWxlY3RhYmxlIERlLWVtcGhhc2lz
OiAtNmRCDQoJCQkgVHJhbnNtaXQgTWFyZ2luOiBOb3JtYWwgT3BlcmF0aW5nIFJhbmdlLCBF
bnRlck1vZGlmaWVkQ29tcGxpYW5jZS0gQ29tcGxpYW5jZVNPUy0NCgkJCSBDb21wbGlhbmNl
IERlLWVtcGhhc2lzOiAtNmRCDQoJCUxua1N0YTI6IEN1cnJlbnQgRGUtZW1waGFzaXMgTGV2
ZWw6IC02ZEINCglDYXBhYmlsaXRpZXM6IFthY10gTVNJLVg6IEVuYWJsZS0gQ291bnQ9NCBN
YXNrZWQtDQoJCVZlY3RvciB0YWJsZTogQkFSPTQgb2Zmc2V0PTAwMDAwMDAwDQoJCVBCQTog
QkFSPTQgb2Zmc2V0PTAwMDAwODAwDQoJQ2FwYWJpbGl0aWVzOiBbY2NdIFZpdGFsIFByb2R1
Y3QgRGF0YQ0KCQlVbmtub3duIHNtYWxsIHJlc291cmNlIHR5cGUgMDAsIHdpbGwgbm90IGRl
Y29kZSBtb3JlLg0KCUNhcGFiaWxpdGllczogWzEwMCB2MV0gQWR2YW5jZWQgRXJyb3IgUmVw
b3J0aW5nDQoJCVVFU3RhOglETFAtIFNERVMtIFRMUC0gRkNQLSBDbXBsdFRPLSBDbXBsdEFi
cnQtIFVueENtcGx0LSBSeE9GLSBNYWxmVExQLSBFQ1JDLSBVbnN1cFJlcS0gQUNTVmlvbC0N
CgkJVUVNc2s6CURMUC0gU0RFUy0gVExQLSBGQ1AtIENtcGx0VE8tIENtcGx0QWJydC0gVW54
Q21wbHQtIFJ4T0YtIE1hbGZUTFAtIEVDUkMtIFVuc3VwUmVxLSBBQ1NWaW9sLQ0KCQlVRVN2
cnQ6CURMUCsgU0RFUysgVExQLSBGQ1ArIENtcGx0VE8tIENtcGx0QWJydC0gVW54Q21wbHQt
IFJ4T0YrIE1hbGZUTFArIEVDUkMtIFVuc3VwUmVxLSBBQ1NWaW9sLQ0KCQlDRVN0YToJUnhF
cnIrIEJhZFRMUC0gQmFkRExMUC0gUm9sbG92ZXItIFRpbWVvdXQtIE5vbkZhdGFsRXJyKw0K
CQlDRU1zazoJUnhFcnItIEJhZFRMUC0gQmFkRExMUC0gUm9sbG92ZXItIFRpbWVvdXQtIE5v
bkZhdGFsRXJyKw0KCQlBRVJDYXA6CUZpcnN0IEVycm9yIFBvaW50ZXI6IDAwLCBHZW5DYXAr
IENHZW5Fbi0gQ2hrQ2FwKyBDaGtFbi0NCglDYXBhYmlsaXRpZXM6IFsxNDAgdjFdIFZpcnR1
YWwgQ2hhbm5lbA0KCQlDYXBzOglMUEVWQz0wIFJlZkNsaz0xMDBucyBQQVRFbnRyeUJpdHM9
MQ0KCQlBcmI6CUZpeGVkLSBXUlIzMi0gV1JSNjQtIFdSUjEyOC0NCgkJQ3RybDoJQXJiU2Vs
ZWN0PUZpeGVkDQoJCVN0YXR1czoJSW5Qcm9ncmVzcy0NCgkJVkMwOglDYXBzOglQQVRPZmZz
ZXQ9MDAgTWF4VGltZVNsb3RzPTEgUmVqU25vb3BUcmFucy0NCgkJCUFyYjoJRml4ZWQtIFdS
UjMyLSBXUlI2NC0gV1JSMTI4LSBUV1JSMTI4LSBXUlIyNTYtDQoJCQlDdHJsOglFbmFibGUr
IElEPTAgQXJiU2VsZWN0PUZpeGVkIFRDL1ZDPWZmDQoJCQlTdGF0dXM6CU5lZ29QZW5kaW5n
LSBJblByb2dyZXNzLQ0KCUNhcGFiaWxpdGllczogWzE2MCB2MV0gRGV2aWNlIFNlcmlhbCBO
dW1iZXIgMDMtMDAtMDAtMDAtNjgtNGMtZTAtMDANCglLZXJuZWwgZHJpdmVyIGluIHVzZTog
cjgxNjkNCg0KMDk6MDAuMCBFdGhlcm5ldCBjb250cm9sbGVyIFswMjAwXTogUmVhbHRlayBT
ZW1pY29uZHVjdG9yIENvLiwgTHRkLiBSVEw4MTExLzgxNjhCIFBDSSBFeHByZXNzIEdpZ2Fi
aXQgRXRoZXJuZXQgY29udHJvbGxlciBbMTBlYzo4MTY4XSAocmV2IDAzKQ0KCVN1YnN5c3Rl
bTogTWljcm8tU3RhciBJbnRlcm5hdGlvbmFsIENvLiwgTHRkLiBEZXZpY2UgWzE0NjI6NzY0
MF0NCglDb250cm9sOiBJL08rIE1lbSsgQnVzTWFzdGVyKyBTcGVjQ3ljbGUtIE1lbVdJTlYt
IFZHQVNub29wLSBQYXJFcnItIFN0ZXBwaW5nLSBTRVJSKyBGYXN0QjJCLSBEaXNJTlR4Kw0K
CVN0YXR1czogQ2FwKyA2Nk1Iei0gVURGLSBGYXN0QjJCLSBQYXJFcnItIERFVlNFTD1mYXN0
ID5UQWJvcnQtIDxUQWJvcnQtIDxNQWJvcnQtID5TRVJSLSA8UEVSUi0gSU5UeC0NCglMYXRl
bmN5OiAwLCBDYWNoZSBMaW5lIFNpemU6IDY0IGJ5dGVzDQoJSW50ZXJydXB0OiBwaW4gQSBy
b3V0ZWQgdG8gSVJRIDEyMQ0KCVJlZ2lvbiAwOiBJL08gcG9ydHMgYXQgZDgwMCBbc2l6ZT0y
NTZdDQoJUmVnaW9uIDI6IE1lbW9yeSBhdCBjZmZmZjAwMCAoNjQtYml0LCBwcmVmZXRjaGFi
bGUpIFtzaXplPTRLXQ0KCVJlZ2lvbiA0OiBNZW1vcnkgYXQgY2ZmZjgwMDAgKDY0LWJpdCwg
cHJlZmV0Y2hhYmxlKSBbc2l6ZT0xNktdDQoJRXhwYW5zaW9uIFJPTSBhdCBmOWVlMDAwMCBb
ZGlzYWJsZWRdIFtzaXplPTEyOEtdDQoJQ2FwYWJpbGl0aWVzOiBbNDBdIFBvd2VyIE1hbmFn
ZW1lbnQgdmVyc2lvbiAzDQoJCUZsYWdzOiBQTUVDbGstIERTSS0gRDErIEQyKyBBdXhDdXJy
ZW50PTM3NW1BIFBNRShEMCssRDErLEQyKyxEM2hvdCssRDNjb2xkKykNCgkJU3RhdHVzOiBE
MCBOb1NvZnRSc3QrIFBNRS1FbmFibGUtIERTZWw9MCBEU2NhbGU9MCBQTUUtDQoJQ2FwYWJp
bGl0aWVzOiBbNTBdIE1TSTogRW5hYmxlKyBDb3VudD0xLzEgTWFza2FibGUtIDY0Yml0Kw0K
CQlBZGRyZXNzOiAwMDAwMDAwMGZlZTAxMDBjICBEYXRhOiA0MWM5DQoJQ2FwYWJpbGl0aWVz
OiBbNzBdIEV4cHJlc3MgKHYyKSBFbmRwb2ludCwgTVNJIDAxDQoJCURldkNhcDoJTWF4UGF5
bG9hZCAyNTYgYnl0ZXMsIFBoYW50RnVuYyAwLCBMYXRlbmN5IEwwcyA8NTEybnMsIEwxIDw2
NHVzDQoJCQlFeHRUYWctIEF0dG5CdG4tIEF0dG5JbmQtIFB3ckluZC0gUkJFKyBGTFJlc2V0
LQ0KCQlEZXZDdGw6CVJlcG9ydCBlcnJvcnM6IENvcnJlY3RhYmxlLSBOb24tRmF0YWwtIEZh
dGFsLSBVbnN1cHBvcnRlZC0NCgkJCVJseGRPcmQtIEV4dFRhZy0gUGhhbnRGdW5jLSBBdXhQ
d3ItIE5vU25vb3AtDQoJCQlNYXhQYXlsb2FkIDEyOCBieXRlcywgTWF4UmVhZFJlcSA0MDk2
IGJ5dGVzDQoJCURldlN0YToJQ29yckVycisgVW5jb3JyRXJyLSBGYXRhbEVyci0gVW5zdXBw
UmVxKyBBdXhQd3IrIFRyYW5zUGVuZC0NCgkJTG5rQ2FwOglQb3J0ICMwLCBTcGVlZCAyLjVH
VC9zLCBXaWR0aCB4MSwgQVNQTSBMMHMgTDEsIExhdGVuY3kgTDAgPDUxMm5zLCBMMSA8NjR1
cw0KCQkJQ2xvY2tQTSsgU3VycHJpc2UtIExMQWN0UmVwLSBCd05vdC0NCgkJTG5rQ3RsOglB
U1BNIERpc2FibGVkOyBSQ0IgNjQgYnl0ZXMgRGlzYWJsZWQtIFJldHJhaW4tIENvbW1DbGsr
DQoJCQlFeHRTeW5jaC0gQ2xvY2tQTS0gQXV0V2lkRGlzLSBCV0ludC0gQXV0QldJbnQtDQoJ
CUxua1N0YToJU3BlZWQgMi41R1QvcywgV2lkdGggeDEsIFRyRXJyLSBUcmFpbi0gU2xvdENs
aysgRExBY3RpdmUtIEJXTWdtdC0gQUJXTWdtdC0NCgkJRGV2Q2FwMjogQ29tcGxldGlvbiBU
aW1lb3V0OiBOb3QgU3VwcG9ydGVkLCBUaW1lb3V0RGlzKw0KCQlEZXZDdGwyOiBDb21wbGV0
aW9uIFRpbWVvdXQ6IDUwdXMgdG8gNTBtcywgVGltZW91dERpcy0NCgkJTG5rQ3RsMjogVGFy
Z2V0IExpbmsgU3BlZWQ6IDIuNUdUL3MsIEVudGVyQ29tcGxpYW5jZS0gU3BlZWREaXMtLCBT
ZWxlY3RhYmxlIERlLWVtcGhhc2lzOiAtNmRCDQoJCQkgVHJhbnNtaXQgTWFyZ2luOiBOb3Jt
YWwgT3BlcmF0aW5nIFJhbmdlLCBFbnRlck1vZGlmaWVkQ29tcGxpYW5jZS0gQ29tcGxpYW5j
ZVNPUy0NCgkJCSBDb21wbGlhbmNlIERlLWVtcGhhc2lzOiAtNmRCDQoJCUxua1N0YTI6IEN1
cnJlbnQgRGUtZW1waGFzaXMgTGV2ZWw6IC02ZEINCglDYXBhYmlsaXRpZXM6IFthY10gTVNJ
LVg6IEVuYWJsZS0gQ291bnQ9NCBNYXNrZWQtDQoJCVZlY3RvciB0YWJsZTogQkFSPTQgb2Zm
c2V0PTAwMDAwMDAwDQoJCVBCQTogQkFSPTQgb2Zmc2V0PTAwMDAwODAwDQoJQ2FwYWJpbGl0
aWVzOiBbY2NdIFZpdGFsIFByb2R1Y3QgRGF0YQ0KCQlVbmtub3duIHNtYWxsIHJlc291cmNl
IHR5cGUgMDAsIHdpbGwgbm90IGRlY29kZSBtb3JlLg0KCUNhcGFiaWxpdGllczogWzEwMCB2
MV0gQWR2YW5jZWQgRXJyb3IgUmVwb3J0aW5nDQoJCVVFU3RhOglETFAtIFNERVMtIFRMUC0g
RkNQLSBDbXBsdFRPLSBDbXBsdEFicnQtIFVueENtcGx0LSBSeE9GLSBNYWxmVExQLSBFQ1JD
LSBVbnN1cFJlcS0gQUNTVmlvbC0NCgkJVUVNc2s6CURMUC0gU0RFUy0gVExQLSBGQ1AtIENt
cGx0VE8tIENtcGx0QWJydC0gVW54Q21wbHQtIFJ4T0YtIE1hbGZUTFAtIEVDUkMtIFVuc3Vw
UmVxLSBBQ1NWaW9sLQ0KCQlVRVN2cnQ6CURMUCsgU0RFUysgVExQLSBGQ1ArIENtcGx0VE8t
IENtcGx0QWJydC0gVW54Q21wbHQtIFJ4T0YrIE1hbGZUTFArIEVDUkMtIFVuc3VwUmVxLSBB
Q1NWaW9sLQ0KCQlDRVN0YToJUnhFcnIrIEJhZFRMUC0gQmFkRExMUC0gUm9sbG92ZXItIFRp
bWVvdXQtIE5vbkZhdGFsRXJyKw0KCQlDRU1zazoJUnhFcnItIEJhZFRMUC0gQmFkRExMUC0g
Um9sbG92ZXItIFRpbWVvdXQtIE5vbkZhdGFsRXJyKw0KCQlBRVJDYXA6CUZpcnN0IEVycm9y
IFBvaW50ZXI6IDAwLCBHZW5DYXArIENHZW5Fbi0gQ2hrQ2FwKyBDaGtFbi0NCglDYXBhYmls
aXRpZXM6IFsxNDAgdjFdIFZpcnR1YWwgQ2hhbm5lbA0KCQlDYXBzOglMUEVWQz0wIFJlZkNs
az0xMDBucyBQQVRFbnRyeUJpdHM9MQ0KCQlBcmI6CUZpeGVkLSBXUlIzMi0gV1JSNjQtIFdS
UjEyOC0NCgkJQ3RybDoJQXJiU2VsZWN0PUZpeGVkDQoJCVN0YXR1czoJSW5Qcm9ncmVzcy0N
CgkJVkMwOglDYXBzOglQQVRPZmZzZXQ9MDAgTWF4VGltZVNsb3RzPTEgUmVqU25vb3BUcmFu
cy0NCgkJCUFyYjoJRml4ZWQtIFdSUjMyLSBXUlI2NC0gV1JSMTI4LSBUV1JSMTI4LSBXUlIy
NTYtDQoJCQlDdHJsOglFbmFibGUrIElEPTAgQXJiU2VsZWN0PUZpeGVkIFRDL1ZDPWZmDQoJ
CQlTdGF0dXM6CU5lZ29QZW5kaW5nLSBJblByb2dyZXNzLQ0KCUNhcGFiaWxpdGllczogWzE2
MCB2MV0gRGV2aWNlIFNlcmlhbCBOdW1iZXIgMDQtMDAtMDAtMDAtNjgtNGMtZTAtMDANCglL
ZXJuZWwgZHJpdmVyIGluIHVzZTogcjgxNjkNCg0KMGE6MDAuMCBVU0IgY29udHJvbGxlciBb
MGMwM106IE5ldE1vcyBUZWNobm9sb2d5IE1DUzk5OTAgUENJZSB0byA04oCQUG9ydCBVU0Ig
Mi4wIEhvc3QgQ29udHJvbGxlciBbOTcxMDo5OTkwXSAocHJvZy1pZiAxMCBbT0hDSV0pDQoJ
U3Vic3lzdGVtOiBEZXZpY2UgW2EwMDA6NDAwMF0NCglDb250cm9sOiBJL08tIE1lbSsgQnVz
TWFzdGVyKyBTcGVjQ3ljbGUtIE1lbVdJTlYtIFZHQVNub29wLSBQYXJFcnItIFN0ZXBwaW5n
LSBTRVJSLSBGYXN0QjJCLSBEaXNJTlR4LQ0KCVN0YXR1czogQ2FwKyA2Nk1Iei0gVURGLSBG
YXN0QjJCLSBQYXJFcnItIERFVlNFTD1mYXN0ID5UQWJvcnQtIDxUQWJvcnQrIDxNQWJvcnQt
ID5TRVJSLSA8UEVSUi0gSU5UeC0NCglMYXRlbmN5OiAwLCBDYWNoZSBMaW5lIFNpemU6IDY0
IGJ5dGVzDQoJSW50ZXJydXB0OiBwaW4gQSByb3V0ZWQgdG8gSVJRIDI4DQoJUmVnaW9uIDA6
IE1lbW9yeSBhdCBmOWZmODAwMCAoMzItYml0LCBub24tcHJlZmV0Y2hhYmxlKSBbc2l6ZT00
S10NCglDYXBhYmlsaXRpZXM6IFs1MF0gTVNJOiBFbmFibGUtIENvdW50PTEvMSBNYXNrYWJs
ZS0gNjRiaXQrDQoJCUFkZHJlc3M6IDAwMDAwMDAwMDAwMDAwMDAgIERhdGE6IDAwMDANCglD
YXBhYmlsaXRpZXM6IFs3OF0gUG93ZXIgTWFuYWdlbWVudCB2ZXJzaW9uIDMNCgkJRmxhZ3M6
IFBNRUNsay0gRFNJLSBEMSsgRDIrIEF1eEN1cnJlbnQ9Mzc1bUEgUE1FKEQwKyxEMSssRDIr
LEQzaG90KyxEM2NvbGQtKQ0KCQlTdGF0dXM6IEQwIE5vU29mdFJzdCsgUE1FLUVuYWJsZS0g
RFNlbD0wIERTY2FsZT0wIFBNRS0NCglDYXBhYmlsaXRpZXM6IFs4MF0gRXhwcmVzcyAodjEp
IEVuZHBvaW50LCBNU0kgMDANCgkJRGV2Q2FwOglNYXhQYXlsb2FkIDI1NiBieXRlcywgUGhh
bnRGdW5jIDAsIExhdGVuY3kgTDBzIHVubGltaXRlZCwgTDEgdW5saW1pdGVkDQoJCQlFeHRU
YWctIEF0dG5CdG4tIEF0dG5JbmQtIFB3ckluZC0gUkJFKyBGTFJlc2V0LQ0KCQlEZXZDdGw6
CVJlcG9ydCBlcnJvcnM6IENvcnJlY3RhYmxlLSBOb24tRmF0YWwtIEZhdGFsLSBVbnN1cHBv
cnRlZC0NCgkJCVJseGRPcmQtIEV4dFRhZy0gUGhhbnRGdW5jLSBBdXhQd3ItIE5vU25vb3Ar
DQoJCQlNYXhQYXlsb2FkIDEyOCBieXRlcywgTWF4UmVhZFJlcSA1MTIgYnl0ZXMNCgkJRGV2
U3RhOglDb3JyRXJyLSBVbmNvcnJFcnItIEZhdGFsRXJyLSBVbnN1cHBSZXEtIEF1eFB3ci0g
VHJhbnNQZW5kLQ0KCQlMbmtDYXA6CVBvcnQgIzEsIFNwZWVkIDIuNUdUL3MsIFdpZHRoIHgx
LCBBU1BNIHVua25vd24sIExhdGVuY3kgTDAgPDY0bnMsIEwxIHVubGltaXRlZA0KCQkJQ2xv
Y2tQTSsgU3VycHJpc2UtIExMQWN0UmVwLSBCd05vdC0NCgkJTG5rQ3RsOglBU1BNIERpc2Fi
bGVkOyBSQ0IgNjQgYnl0ZXMgRGlzYWJsZWQtIFJldHJhaW4tIENvbW1DbGstDQoJCQlFeHRT
eW5jaC0gQ2xvY2tQTS0gQXV0V2lkRGlzLSBCV0ludC0gQXV0QldJbnQtDQoJCUxua1N0YToJ
U3BlZWQgMi41R1QvcywgV2lkdGggeDEsIFRyRXJyLSBUcmFpbi0gU2xvdENsay0gRExBY3Rp
dmUtIEJXTWdtdC0gQUJXTWdtdC0NCglDYXBhYmlsaXRpZXM6IFsxMDAgdjFdIFZpcnR1YWwg
Q2hhbm5lbA0KCQlDYXBzOglMUEVWQz0wIFJlZkNsaz0xMDBucyBQQVRFbnRyeUJpdHM9MQ0K
CQlBcmI6CUZpeGVkLSBXUlIzMi0gV1JSNjQtIFdSUjEyOC0NCgkJQ3RybDoJQXJiU2VsZWN0
PUZpeGVkDQoJCVN0YXR1czoJSW5Qcm9ncmVzcy0NCgkJVkMwOglDYXBzOglQQVRPZmZzZXQ9
MDAgTWF4VGltZVNsb3RzPTEgUmVqU25vb3BUcmFucy0NCgkJCUFyYjoJRml4ZWQtIFdSUjMy
LSBXUlI2NC0gV1JSMTI4LSBUV1JSMTI4LSBXUlIyNTYtDQoJCQlDdHJsOglFbmFibGUrIElE
PTAgQXJiU2VsZWN0PUZpeGVkIFRDL1ZDPWZmDQoJCQlTdGF0dXM6CU5lZ29QZW5kaW5nLSBJ
blByb2dyZXNzLQ0KCUtlcm5lbCBkcml2ZXIgaW4gdXNlOiBwY2liYWNrDQoNCjBhOjAwLjEg
VVNCIGNvbnRyb2xsZXIgWzBjMDNdOiBOZXRNb3MgVGVjaG5vbG9neSBNQ1M5OTkwIFBDSWUg
dG8gNOKAkFBvcnQgVVNCIDIuMCBIb3N0IENvbnRyb2xsZXIgWzk3MTA6OTk5MF0gKHByb2ct
aWYgMjAgW0VIQ0ldKQ0KCVN1YnN5c3RlbTogRGV2aWNlIFthMDAwOjQwMDBdDQoJQ29udHJv
bDogSS9PLSBNZW0rIEJ1c01hc3RlcisgU3BlY0N5Y2xlLSBNZW1XSU5WLSBWR0FTbm9vcC0g
UGFyRXJyLSBTdGVwcGluZy0gU0VSUi0gRmFzdEIyQi0gRGlzSU5UeC0NCglTdGF0dXM6IENh
cCsgNjZNSHotIFVERi0gRmFzdEIyQi0gUGFyRXJyLSBERVZTRUw9ZmFzdCA+VEFib3J0LSA8
VEFib3J0KyA8TUFib3J0LSA+U0VSUi0gPFBFUlItIElOVHgtDQoJTGF0ZW5jeTogMCwgQ2Fj
aGUgTGluZSBTaXplOiA2NCBieXRlcw0KCUludGVycnVwdDogcGluIEEgcm91dGVkIHRvIElS
USAyOA0KCVJlZ2lvbiAwOiBNZW1vcnkgYXQgZjlmZjkwMDAgKDMyLWJpdCwgbm9uLXByZWZl
dGNoYWJsZSkgW3NpemU9NEtdDQoJQ2FwYWJpbGl0aWVzOiBbNTBdIE1TSTogRW5hYmxlLSBD
b3VudD0xLzEgTWFza2FibGUtIDY0Yml0Kw0KCQlBZGRyZXNzOiAwMDAwMDAwMDAwMDAwMDAw
ICBEYXRhOiAwMDAwDQoJQ2FwYWJpbGl0aWVzOiBbNzhdIFBvd2VyIE1hbmFnZW1lbnQgdmVy
c2lvbiAzDQoJCUZsYWdzOiBQTUVDbGstIERTSS0gRDErIEQyKyBBdXhDdXJyZW50PTM3NW1B
IFBNRShEMCssRDErLEQyKyxEM2hvdCssRDNjb2xkLSkNCgkJU3RhdHVzOiBEMCBOb1NvZnRS
c3QrIFBNRS1FbmFibGUtIERTZWw9MCBEU2NhbGU9MCBQTUUtDQoJQ2FwYWJpbGl0aWVzOiBb
ODBdIEV4cHJlc3MgKHYxKSBFbmRwb2ludCwgTVNJIDAwDQoJCURldkNhcDoJTWF4UGF5bG9h
ZCAyNTYgYnl0ZXMsIFBoYW50RnVuYyAwLCBMYXRlbmN5IEwwcyB1bmxpbWl0ZWQsIEwxIHVu
bGltaXRlZA0KCQkJRXh0VGFnLSBBdHRuQnRuLSBBdHRuSW5kLSBQd3JJbmQtIFJCRSsgRkxS
ZXNldC0NCgkJRGV2Q3RsOglSZXBvcnQgZXJyb3JzOiBDb3JyZWN0YWJsZS0gTm9uLUZhdGFs
LSBGYXRhbC0gVW5zdXBwb3J0ZWQtDQoJCQlSbHhkT3JkLSBFeHRUYWctIFBoYW50RnVuYy0g
QXV4UHdyLSBOb1Nub29wKw0KCQkJTWF4UGF5bG9hZCAxMjggYnl0ZXMsIE1heFJlYWRSZXEg
NTEyIGJ5dGVzDQoJCURldlN0YToJQ29yckVyci0gVW5jb3JyRXJyLSBGYXRhbEVyci0gVW5z
dXBwUmVxLSBBdXhQd3ItIFRyYW5zUGVuZC0NCgkJTG5rQ2FwOglQb3J0ICMxLCBTcGVlZCAy
LjVHVC9zLCBXaWR0aCB4MSwgQVNQTSB1bmtub3duLCBMYXRlbmN5IEwwIDw2NG5zLCBMMSB1
bmxpbWl0ZWQNCgkJCUNsb2NrUE0rIFN1cnByaXNlLSBMTEFjdFJlcC0gQndOb3QtDQoJCUxu
a0N0bDoJQVNQTSBEaXNhYmxlZDsgUkNCIDY0IGJ5dGVzIERpc2FibGVkLSBSZXRyYWluLSBD
b21tQ2xrLQ0KCQkJRXh0U3luY2gtIENsb2NrUE0tIEF1dFdpZERpcy0gQldJbnQtIEF1dEJX
SW50LQ0KCQlMbmtTdGE6CVNwZWVkIDIuNUdUL3MsIFdpZHRoIHgxLCBUckVyci0gVHJhaW4t
IFNsb3RDbGstIERMQWN0aXZlLSBCV01nbXQtIEFCV01nbXQtDQoJS2VybmVsIGRyaXZlciBp
biB1c2U6IHBjaWJhY2sNCg0KMGE6MDAuMiBVU0IgY29udHJvbGxlciBbMGMwM106IE5ldE1v
cyBUZWNobm9sb2d5IE1DUzk5OTAgUENJZSB0byA04oCQUG9ydCBVU0IgMi4wIEhvc3QgQ29u
dHJvbGxlciBbOTcxMDo5OTkwXSAocHJvZy1pZiAxMCBbT0hDSV0pDQoJU3Vic3lzdGVtOiBE
ZXZpY2UgW2EwMDA6NDAwMF0NCglDb250cm9sOiBJL08tIE1lbSsgQnVzTWFzdGVyKyBTcGVj
Q3ljbGUtIE1lbVdJTlYtIFZHQVNub29wLSBQYXJFcnItIFN0ZXBwaW5nLSBTRVJSLSBGYXN0
QjJCLSBEaXNJTlR4LQ0KCVN0YXR1czogQ2FwKyA2Nk1Iei0gVURGLSBGYXN0QjJCLSBQYXJF
cnItIERFVlNFTD1mYXN0ID5UQWJvcnQtIDxUQWJvcnQrIDxNQWJvcnQtID5TRVJSLSA8UEVS
Ui0gSU5UeC0NCglMYXRlbmN5OiAwLCBDYWNoZSBMaW5lIFNpemU6IDY0IGJ5dGVzDQoJSW50
ZXJydXB0OiBwaW4gQiByb3V0ZWQgdG8gSVJRIDI5DQoJUmVnaW9uIDA6IE1lbW9yeSBhdCBm
OWZmYTAwMCAoMzItYml0LCBub24tcHJlZmV0Y2hhYmxlKSBbc2l6ZT00S10NCglDYXBhYmls
aXRpZXM6IFs1MF0gTVNJOiBFbmFibGUtIENvdW50PTEvMSBNYXNrYWJsZS0gNjRiaXQrDQoJ
CUFkZHJlc3M6IDAwMDAwMDAwMDAwMDAwMDAgIERhdGE6IDAwMDANCglDYXBhYmlsaXRpZXM6
IFs3OF0gUG93ZXIgTWFuYWdlbWVudCB2ZXJzaW9uIDMNCgkJRmxhZ3M6IFBNRUNsay0gRFNJ
LSBEMSsgRDIrIEF1eEN1cnJlbnQ9Mzc1bUEgUE1FKEQwKyxEMSssRDIrLEQzaG90KyxEM2Nv
bGQtKQ0KCQlTdGF0dXM6IEQwIE5vU29mdFJzdCsgUE1FLUVuYWJsZS0gRFNlbD0wIERTY2Fs
ZT0wIFBNRS0NCglDYXBhYmlsaXRpZXM6IFs4MF0gRXhwcmVzcyAodjEpIEVuZHBvaW50LCBN
U0kgMDANCgkJRGV2Q2FwOglNYXhQYXlsb2FkIDI1NiBieXRlcywgUGhhbnRGdW5jIDAsIExh
dGVuY3kgTDBzIHVubGltaXRlZCwgTDEgdW5saW1pdGVkDQoJCQlFeHRUYWctIEF0dG5CdG4t
IEF0dG5JbmQtIFB3ckluZC0gUkJFKyBGTFJlc2V0LQ0KCQlEZXZDdGw6CVJlcG9ydCBlcnJv
cnM6IENvcnJlY3RhYmxlLSBOb24tRmF0YWwtIEZhdGFsLSBVbnN1cHBvcnRlZC0NCgkJCVJs
eGRPcmQtIEV4dFRhZy0gUGhhbnRGdW5jLSBBdXhQd3ItIE5vU25vb3ArDQoJCQlNYXhQYXls
b2FkIDEyOCBieXRlcywgTWF4UmVhZFJlcSA1MTIgYnl0ZXMNCgkJRGV2U3RhOglDb3JyRXJy
LSBVbmNvcnJFcnItIEZhdGFsRXJyLSBVbnN1cHBSZXEtIEF1eFB3ci0gVHJhbnNQZW5kLQ0K
CQlMbmtDYXA6CVBvcnQgIzEsIFNwZWVkIDIuNUdUL3MsIFdpZHRoIHgxLCBBU1BNIHVua25v
d24sIExhdGVuY3kgTDAgPDY0bnMsIEwxIHVubGltaXRlZA0KCQkJQ2xvY2tQTSsgU3VycHJp
c2UtIExMQWN0UmVwLSBCd05vdC0NCgkJTG5rQ3RsOglBU1BNIERpc2FibGVkOyBSQ0IgNjQg
Ynl0ZXMgRGlzYWJsZWQtIFJldHJhaW4tIENvbW1DbGstDQoJCQlFeHRTeW5jaC0gQ2xvY2tQ
TS0gQXV0V2lkRGlzLSBCV0ludC0gQXV0QldJbnQtDQoJCUxua1N0YToJU3BlZWQgMi41R1Qv
cywgV2lkdGggeDEsIFRyRXJyLSBUcmFpbi0gU2xvdENsay0gRExBY3RpdmUtIEJXTWdtdC0g
QUJXTWdtdC0NCglLZXJuZWwgZHJpdmVyIGluIHVzZTogcGNpYmFjaw0KDQowYTowMC4zIFVT
QiBjb250cm9sbGVyIFswYzAzXTogTmV0TW9zIFRlY2hub2xvZ3kgTUNTOTk5MCBQQ0llIHRv
IDTigJBQb3J0IFVTQiAyLjAgSG9zdCBDb250cm9sbGVyIFs5NzEwOjk5OTBdIChwcm9nLWlm
IDIwIFtFSENJXSkNCglTdWJzeXN0ZW06IERldmljZSBbYTAwMDo0MDAwXQ0KCUNvbnRyb2w6
IEkvTy0gTWVtKyBCdXNNYXN0ZXIrIFNwZWNDeWNsZS0gTWVtV0lOVi0gVkdBU25vb3AtIFBh
ckVyci0gU3RlcHBpbmctIFNFUlItIEZhc3RCMkItIERpc0lOVHgtDQoJU3RhdHVzOiBDYXAr
IDY2TUh6LSBVREYtIEZhc3RCMkItIFBhckVyci0gREVWU0VMPWZhc3QgPlRBYm9ydC0gPFRB
Ym9ydCsgPE1BYm9ydC0gPlNFUlItIDxQRVJSLSBJTlR4LQ0KCUxhdGVuY3k6IDAsIENhY2hl
IExpbmUgU2l6ZTogNjQgYnl0ZXMNCglJbnRlcnJ1cHQ6IHBpbiBCIHJvdXRlZCB0byBJUlEg
MjkNCglSZWdpb24gMDogTWVtb3J5IGF0IGY5ZmZiMDAwICgzMi1iaXQsIG5vbi1wcmVmZXRj
aGFibGUpIFtzaXplPTRLXQ0KCUNhcGFiaWxpdGllczogWzUwXSBNU0k6IEVuYWJsZS0gQ291
bnQ9MS8xIE1hc2thYmxlLSA2NGJpdCsNCgkJQWRkcmVzczogMDAwMDAwMDAwMDAwMDAwMCAg
RGF0YTogMDAwMA0KCUNhcGFiaWxpdGllczogWzc4XSBQb3dlciBNYW5hZ2VtZW50IHZlcnNp
b24gMw0KCQlGbGFnczogUE1FQ2xrLSBEU0ktIEQxKyBEMisgQXV4Q3VycmVudD0zNzVtQSBQ
TUUoRDArLEQxKyxEMissRDNob3QrLEQzY29sZC0pDQoJCVN0YXR1czogRDAgTm9Tb2Z0UnN0
KyBQTUUtRW5hYmxlLSBEU2VsPTAgRFNjYWxlPTAgUE1FLQ0KCUNhcGFiaWxpdGllczogWzgw
XSBFeHByZXNzICh2MSkgRW5kcG9pbnQsIE1TSSAwMA0KCQlEZXZDYXA6CU1heFBheWxvYWQg
MjU2IGJ5dGVzLCBQaGFudEZ1bmMgMCwgTGF0ZW5jeSBMMHMgdW5saW1pdGVkLCBMMSB1bmxp
bWl0ZWQNCgkJCUV4dFRhZy0gQXR0bkJ0bi0gQXR0bkluZC0gUHdySW5kLSBSQkUrIEZMUmVz
ZXQtDQoJCURldkN0bDoJUmVwb3J0IGVycm9yczogQ29ycmVjdGFibGUtIE5vbi1GYXRhbC0g
RmF0YWwtIFVuc3VwcG9ydGVkLQ0KCQkJUmx4ZE9yZC0gRXh0VGFnLSBQaGFudEZ1bmMtIEF1
eFB3ci0gTm9Tbm9vcCsNCgkJCU1heFBheWxvYWQgMTI4IGJ5dGVzLCBNYXhSZWFkUmVxIDUx
MiBieXRlcw0KCQlEZXZTdGE6CUNvcnJFcnItIFVuY29yckVyci0gRmF0YWxFcnItIFVuc3Vw
cFJlcS0gQXV4UHdyLSBUcmFuc1BlbmQtDQoJCUxua0NhcDoJUG9ydCAjMSwgU3BlZWQgMi41
R1QvcywgV2lkdGggeDEsIEFTUE0gdW5rbm93biwgTGF0ZW5jeSBMMCA8NjRucywgTDEgdW5s
aW1pdGVkDQoJCQlDbG9ja1BNKyBTdXJwcmlzZS0gTExBY3RSZXAtIEJ3Tm90LQ0KCQlMbmtD
dGw6CUFTUE0gRGlzYWJsZWQ7IFJDQiA2NCBieXRlcyBEaXNhYmxlZC0gUmV0cmFpbi0gQ29t
bUNsay0NCgkJCUV4dFN5bmNoLSBDbG9ja1BNLSBBdXRXaWREaXMtIEJXSW50LSBBdXRCV0lu
dC0NCgkJTG5rU3RhOglTcGVlZCAyLjVHVC9zLCBXaWR0aCB4MSwgVHJFcnItIFRyYWluLSBT
bG90Q2xrLSBETEFjdGl2ZS0gQldNZ210LSBBQldNZ210LQ0KCUtlcm5lbCBkcml2ZXIgaW4g
dXNlOiBwY2liYWNrDQoNCjBhOjAwLjQgVVNCIGNvbnRyb2xsZXIgWzBjMDNdOiBOZXRNb3Mg
VGVjaG5vbG9neSBNQ1M5OTkwIFBDSWUgdG8gNOKAkFBvcnQgVVNCIDIuMCBIb3N0IENvbnRy
b2xsZXIgWzk3MTA6OTk5MF0gKHByb2ctaWYgMTAgW09IQ0ldKQ0KCVN1YnN5c3RlbTogRGV2
aWNlIFthMDAwOjQwMDBdDQoJQ29udHJvbDogSS9PLSBNZW0rIEJ1c01hc3RlcisgU3BlY0N5
Y2xlLSBNZW1XSU5WLSBWR0FTbm9vcC0gUGFyRXJyLSBTdGVwcGluZy0gU0VSUi0gRmFzdEIy
Qi0gRGlzSU5UeC0NCglTdGF0dXM6IENhcCsgNjZNSHotIFVERi0gRmFzdEIyQi0gUGFyRXJy
LSBERVZTRUw9ZmFzdCA+VEFib3J0LSA8VEFib3J0KyA8TUFib3J0LSA+U0VSUi0gPFBFUlIt
IElOVHgtDQoJTGF0ZW5jeTogMCwgQ2FjaGUgTGluZSBTaXplOiA2NCBieXRlcw0KCUludGVy
cnVwdDogcGluIEMgcm91dGVkIHRvIElSUSAzMA0KCVJlZ2lvbiAwOiBNZW1vcnkgYXQgZjlm
ZmMwMDAgKDMyLWJpdCwgbm9uLXByZWZldGNoYWJsZSkgW3NpemU9NEtdDQoJQ2FwYWJpbGl0
aWVzOiBbNTBdIE1TSTogRW5hYmxlLSBDb3VudD0xLzEgTWFza2FibGUtIDY0Yml0Kw0KCQlB
ZGRyZXNzOiAwMDAwMDAwMDAwMDAwMDAwICBEYXRhOiAwMDAwDQoJQ2FwYWJpbGl0aWVzOiBb
NzhdIFBvd2VyIE1hbmFnZW1lbnQgdmVyc2lvbiAzDQoJCUZsYWdzOiBQTUVDbGstIERTSS0g
RDErIEQyKyBBdXhDdXJyZW50PTM3NW1BIFBNRShEMCssRDErLEQyKyxEM2hvdCssRDNjb2xk
LSkNCgkJU3RhdHVzOiBEMCBOb1NvZnRSc3QrIFBNRS1FbmFibGUtIERTZWw9MCBEU2NhbGU9
MCBQTUUtDQoJQ2FwYWJpbGl0aWVzOiBbODBdIEV4cHJlc3MgKHYxKSBFbmRwb2ludCwgTVNJ
IDAwDQoJCURldkNhcDoJTWF4UGF5bG9hZCAyNTYgYnl0ZXMsIFBoYW50RnVuYyAwLCBMYXRl
bmN5IEwwcyB1bmxpbWl0ZWQsIEwxIHVubGltaXRlZA0KCQkJRXh0VGFnLSBBdHRuQnRuLSBB
dHRuSW5kLSBQd3JJbmQtIFJCRSsgRkxSZXNldC0NCgkJRGV2Q3RsOglSZXBvcnQgZXJyb3Jz
OiBDb3JyZWN0YWJsZS0gTm9uLUZhdGFsLSBGYXRhbC0gVW5zdXBwb3J0ZWQtDQoJCQlSbHhk
T3JkLSBFeHRUYWctIFBoYW50RnVuYy0gQXV4UHdyLSBOb1Nub29wKw0KCQkJTWF4UGF5bG9h
ZCAxMjggYnl0ZXMsIE1heFJlYWRSZXEgNTEyIGJ5dGVzDQoJCURldlN0YToJQ29yckVyci0g
VW5jb3JyRXJyLSBGYXRhbEVyci0gVW5zdXBwUmVxLSBBdXhQd3ItIFRyYW5zUGVuZC0NCgkJ
TG5rQ2FwOglQb3J0ICMxLCBTcGVlZCAyLjVHVC9zLCBXaWR0aCB4MSwgQVNQTSB1bmtub3du
LCBMYXRlbmN5IEwwIDw2NG5zLCBMMSB1bmxpbWl0ZWQNCgkJCUNsb2NrUE0rIFN1cnByaXNl
LSBMTEFjdFJlcC0gQndOb3QtDQoJCUxua0N0bDoJQVNQTSBEaXNhYmxlZDsgUkNCIDY0IGJ5
dGVzIERpc2FibGVkLSBSZXRyYWluLSBDb21tQ2xrLQ0KCQkJRXh0U3luY2gtIENsb2NrUE0t
IEF1dFdpZERpcy0gQldJbnQtIEF1dEJXSW50LQ0KCQlMbmtTdGE6CVNwZWVkIDIuNUdUL3Ms
IFdpZHRoIHgxLCBUckVyci0gVHJhaW4tIFNsb3RDbGstIERMQWN0aXZlLSBCV01nbXQtIEFC
V01nbXQtDQoJS2VybmVsIGRyaXZlciBpbiB1c2U6IHBjaWJhY2sNCg0KMGE6MDAuNSBVU0Ig
Y29udHJvbGxlciBbMGMwM106IE5ldE1vcyBUZWNobm9sb2d5IE1DUzk5OTAgUENJZSB0byA0
4oCQUG9ydCBVU0IgMi4wIEhvc3QgQ29udHJvbGxlciBbOTcxMDo5OTkwXSAocHJvZy1pZiAy
MCBbRUhDSV0pDQoJU3Vic3lzdGVtOiBEZXZpY2UgW2EwMDA6NDAwMF0NCglDb250cm9sOiBJ
L08tIE1lbSsgQnVzTWFzdGVyKyBTcGVjQ3ljbGUtIE1lbVdJTlYtIFZHQVNub29wLSBQYXJF
cnItIFN0ZXBwaW5nLSBTRVJSLSBGYXN0QjJCLSBEaXNJTlR4LQ0KCVN0YXR1czogQ2FwKyA2
Nk1Iei0gVURGLSBGYXN0QjJCLSBQYXJFcnItIERFVlNFTD1mYXN0ID5UQWJvcnQtIDxUQWJv
cnQrIDxNQWJvcnQtID5TRVJSLSA8UEVSUi0gSU5UeC0NCglMYXRlbmN5OiAwLCBDYWNoZSBM
aW5lIFNpemU6IDY0IGJ5dGVzDQoJSW50ZXJydXB0OiBwaW4gQyByb3V0ZWQgdG8gSVJRIDMw
DQoJUmVnaW9uIDA6IE1lbW9yeSBhdCBmOWZmZDAwMCAoMzItYml0LCBub24tcHJlZmV0Y2hh
YmxlKSBbc2l6ZT00S10NCglDYXBhYmlsaXRpZXM6IFs1MF0gTVNJOiBFbmFibGUtIENvdW50
PTEvMSBNYXNrYWJsZS0gNjRiaXQrDQoJCUFkZHJlc3M6IDAwMDAwMDAwMDAwMDAwMDAgIERh
dGE6IDAwMDANCglDYXBhYmlsaXRpZXM6IFs3OF0gUG93ZXIgTWFuYWdlbWVudCB2ZXJzaW9u
IDMNCgkJRmxhZ3M6IFBNRUNsay0gRFNJLSBEMSsgRDIrIEF1eEN1cnJlbnQ9Mzc1bUEgUE1F
KEQwKyxEMSssRDIrLEQzaG90KyxEM2NvbGQtKQ0KCQlTdGF0dXM6IEQwIE5vU29mdFJzdCsg
UE1FLUVuYWJsZS0gRFNlbD0wIERTY2FsZT0wIFBNRS0NCglDYXBhYmlsaXRpZXM6IFs4MF0g
RXhwcmVzcyAodjEpIEVuZHBvaW50LCBNU0kgMDANCgkJRGV2Q2FwOglNYXhQYXlsb2FkIDI1
NiBieXRlcywgUGhhbnRGdW5jIDAsIExhdGVuY3kgTDBzIHVubGltaXRlZCwgTDEgdW5saW1p
dGVkDQoJCQlFeHRUYWctIEF0dG5CdG4tIEF0dG5JbmQtIFB3ckluZC0gUkJFKyBGTFJlc2V0
LQ0KCQlEZXZDdGw6CVJlcG9ydCBlcnJvcnM6IENvcnJlY3RhYmxlLSBOb24tRmF0YWwtIEZh
dGFsLSBVbnN1cHBvcnRlZC0NCgkJCVJseGRPcmQtIEV4dFRhZy0gUGhhbnRGdW5jLSBBdXhQ
d3ItIE5vU25vb3ArDQoJCQlNYXhQYXlsb2FkIDEyOCBieXRlcywgTWF4UmVhZFJlcSA1MTIg
Ynl0ZXMNCgkJRGV2U3RhOglDb3JyRXJyLSBVbmNvcnJFcnItIEZhdGFsRXJyLSBVbnN1cHBS
ZXEtIEF1eFB3ci0gVHJhbnNQZW5kLQ0KCQlMbmtDYXA6CVBvcnQgIzEsIFNwZWVkIDIuNUdU
L3MsIFdpZHRoIHgxLCBBU1BNIHVua25vd24sIExhdGVuY3kgTDAgPDY0bnMsIEwxIHVubGlt
aXRlZA0KCQkJQ2xvY2tQTSsgU3VycHJpc2UtIExMQWN0UmVwLSBCd05vdC0NCgkJTG5rQ3Rs
OglBU1BNIERpc2FibGVkOyBSQ0IgNjQgYnl0ZXMgRGlzYWJsZWQtIFJldHJhaW4tIENvbW1D
bGstDQoJCQlFeHRTeW5jaC0gQ2xvY2tQTS0gQXV0V2lkRGlzLSBCV0ludC0gQXV0QldJbnQt
DQoJCUxua1N0YToJU3BlZWQgMi41R1QvcywgV2lkdGggeDEsIFRyRXJyLSBUcmFpbi0gU2xv
dENsay0gRExBY3RpdmUtIEJXTWdtdC0gQUJXTWdtdC0NCglLZXJuZWwgZHJpdmVyIGluIHVz
ZTogcGNpYmFjaw0KDQowYTowMC42IFVTQiBjb250cm9sbGVyIFswYzAzXTogTmV0TW9zIFRl
Y2hub2xvZ3kgTUNTOTk5MCBQQ0llIHRvIDTigJBQb3J0IFVTQiAyLjAgSG9zdCBDb250cm9s
bGVyIFs5NzEwOjk5OTBdIChwcm9nLWlmIDEwIFtPSENJXSkNCglTdWJzeXN0ZW06IERldmlj
ZSBbYTAwMDo0MDAwXQ0KCUNvbnRyb2w6IEkvTy0gTWVtKyBCdXNNYXN0ZXItIFNwZWNDeWNs
ZS0gTWVtV0lOVi0gVkdBU25vb3AtIFBhckVyci0gU3RlcHBpbmctIFNFUlItIEZhc3RCMkIt
IERpc0lOVHgtDQoJU3RhdHVzOiBDYXArIDY2TUh6LSBVREYtIEZhc3RCMkItIFBhckVyci0g
REVWU0VMPWZhc3QgPlRBYm9ydC0gPFRBYm9ydCsgPE1BYm9ydC0gPlNFUlItIDxQRVJSLSBJ
TlR4LQ0KCUludGVycnVwdDogcGluIEQgcm91dGVkIHRvIElSUSAzMQ0KCVJlZ2lvbiAwOiBN
ZW1vcnkgYXQgZjlmZmUwMDAgKDMyLWJpdCwgbm9uLXByZWZldGNoYWJsZSkgW3NpemU9NEtd
DQoJQ2FwYWJpbGl0aWVzOiBbNTBdIE1TSTogRW5hYmxlLSBDb3VudD0xLzEgTWFza2FibGUt
IDY0Yml0Kw0KCQlBZGRyZXNzOiAwMDAwMDAwMDAwMDAwMDAwICBEYXRhOiAwMDAwDQoJQ2Fw
YWJpbGl0aWVzOiBbNzhdIFBvd2VyIE1hbmFnZW1lbnQgdmVyc2lvbiAzDQoJCUZsYWdzOiBQ
TUVDbGstIERTSS0gRDErIEQyKyBBdXhDdXJyZW50PTM3NW1BIFBNRShEMCssRDErLEQyKyxE
M2hvdCssRDNjb2xkLSkNCgkJU3RhdHVzOiBEMCBOb1NvZnRSc3QrIFBNRS1FbmFibGUtIERT
ZWw9MCBEU2NhbGU9MCBQTUUtDQoJQ2FwYWJpbGl0aWVzOiBbODBdIEV4cHJlc3MgKHYxKSBF
bmRwb2ludCwgTVNJIDAwDQoJCURldkNhcDoJTWF4UGF5bG9hZCAyNTYgYnl0ZXMsIFBoYW50
RnVuYyAwLCBMYXRlbmN5IEwwcyB1bmxpbWl0ZWQsIEwxIHVubGltaXRlZA0KCQkJRXh0VGFn
LSBBdHRuQnRuLSBBdHRuSW5kLSBQd3JJbmQtIFJCRSsgRkxSZXNldC0NCgkJRGV2Q3RsOglS
ZXBvcnQgZXJyb3JzOiBDb3JyZWN0YWJsZS0gTm9uLUZhdGFsLSBGYXRhbC0gVW5zdXBwb3J0
ZWQtDQoJCQlSbHhkT3JkLSBFeHRUYWctIFBoYW50RnVuYy0gQXV4UHdyLSBOb1Nub29wKw0K
CQkJTWF4UGF5bG9hZCAxMjggYnl0ZXMsIE1heFJlYWRSZXEgNTEyIGJ5dGVzDQoJCURldlN0
YToJQ29yckVyci0gVW5jb3JyRXJyLSBGYXRhbEVyci0gVW5zdXBwUmVxLSBBdXhQd3ItIFRy
YW5zUGVuZC0NCgkJTG5rQ2FwOglQb3J0ICMxLCBTcGVlZCAyLjVHVC9zLCBXaWR0aCB4MSwg
QVNQTSB1bmtub3duLCBMYXRlbmN5IEwwIDw2NG5zLCBMMSB1bmxpbWl0ZWQNCgkJCUNsb2Nr
UE0rIFN1cnByaXNlLSBMTEFjdFJlcC0gQndOb3QtDQoJCUxua0N0bDoJQVNQTSBEaXNhYmxl
ZDsgUkNCIDY0IGJ5dGVzIERpc2FibGVkLSBSZXRyYWluLSBDb21tQ2xrLQ0KCQkJRXh0U3lu
Y2gtIENsb2NrUE0tIEF1dFdpZERpcy0gQldJbnQtIEF1dEJXSW50LQ0KCQlMbmtTdGE6CVNw
ZWVkIDIuNUdUL3MsIFdpZHRoIHgxLCBUckVyci0gVHJhaW4tIFNsb3RDbGstIERMQWN0aXZl
LSBCV01nbXQtIEFCV01nbXQtDQoJS2VybmVsIGRyaXZlciBpbiB1c2U6IHBjaWJhY2sNCg0K
MGE6MDAuNyBVU0IgY29udHJvbGxlciBbMGMwM106IE5ldE1vcyBUZWNobm9sb2d5IE1DUzk5
OTAgUENJZSB0byA04oCQUG9ydCBVU0IgMi4wIEhvc3QgQ29udHJvbGxlciBbOTcxMDo5OTkw
XSAocHJvZy1pZiAyMCBbRUhDSV0pDQoJU3Vic3lzdGVtOiBEZXZpY2UgW2EwMDA6NDAwMF0N
CglDb250cm9sOiBJL08tIE1lbSsgQnVzTWFzdGVyKyBTcGVjQ3ljbGUtIE1lbVdJTlYtIFZH
QVNub29wLSBQYXJFcnItIFN0ZXBwaW5nLSBTRVJSLSBGYXN0QjJCLSBEaXNJTlR4LQ0KCVN0
YXR1czogQ2FwKyA2Nk1Iei0gVURGLSBGYXN0QjJCLSBQYXJFcnItIERFVlNFTD1mYXN0ID5U
QWJvcnQtIDxUQWJvcnQrIDxNQWJvcnQtID5TRVJSLSA8UEVSUi0gSU5UeC0NCglMYXRlbmN5
OiAwLCBDYWNoZSBMaW5lIFNpemU6IDY0IGJ5dGVzDQoJSW50ZXJydXB0OiBwaW4gRCByb3V0
ZWQgdG8gSVJRIDMxDQoJUmVnaW9uIDA6IE1lbW9yeSBhdCBmOWZmZjAwMCAoMzItYml0LCBu
b24tcHJlZmV0Y2hhYmxlKSBbc2l6ZT00S10NCglDYXBhYmlsaXRpZXM6IFs1MF0gTVNJOiBF
bmFibGUtIENvdW50PTEvMSBNYXNrYWJsZS0gNjRiaXQrDQoJCUFkZHJlc3M6IDAwMDAwMDAw
MDAwMDAwMDAgIERhdGE6IDAwMDANCglDYXBhYmlsaXRpZXM6IFs3OF0gUG93ZXIgTWFuYWdl
bWVudCB2ZXJzaW9uIDMNCgkJRmxhZ3M6IFBNRUNsay0gRFNJLSBEMSsgRDIrIEF1eEN1cnJl
bnQ9Mzc1bUEgUE1FKEQwKyxEMSssRDIrLEQzaG90KyxEM2NvbGQtKQ0KCQlTdGF0dXM6IEQw
IE5vU29mdFJzdCsgUE1FLUVuYWJsZS0gRFNlbD0wIERTY2FsZT0wIFBNRS0NCglDYXBhYmls
aXRpZXM6IFs4MF0gRXhwcmVzcyAodjEpIEVuZHBvaW50LCBNU0kgMDANCgkJRGV2Q2FwOglN
YXhQYXlsb2FkIDI1NiBieXRlcywgUGhhbnRGdW5jIDAsIExhdGVuY3kgTDBzIHVubGltaXRl
ZCwgTDEgdW5saW1pdGVkDQoJCQlFeHRUYWctIEF0dG5CdG4tIEF0dG5JbmQtIFB3ckluZC0g
UkJFKyBGTFJlc2V0LQ0KCQlEZXZDdGw6CVJlcG9ydCBlcnJvcnM6IENvcnJlY3RhYmxlLSBO
b24tRmF0YWwtIEZhdGFsLSBVbnN1cHBvcnRlZC0NCgkJCVJseGRPcmQtIEV4dFRhZy0gUGhh
bnRGdW5jLSBBdXhQd3ItIE5vU25vb3ArDQoJCQlNYXhQYXlsb2FkIDEyOCBieXRlcywgTWF4
UmVhZFJlcSA1MTIgYnl0ZXMNCgkJRGV2U3RhOglDb3JyRXJyLSBVbmNvcnJFcnItIEZhdGFs
RXJyLSBVbnN1cHBSZXEtIEF1eFB3ci0gVHJhbnNQZW5kLQ0KCQlMbmtDYXA6CVBvcnQgIzEs
IFNwZWVkIDIuNUdUL3MsIFdpZHRoIHgxLCBBU1BNIHVua25vd24sIExhdGVuY3kgTDAgPDY0
bnMsIEwxIHVubGltaXRlZA0KCQkJQ2xvY2tQTSsgU3VycHJpc2UtIExMQWN0UmVwLSBCd05v
dC0NCgkJTG5rQ3RsOglBU1BNIERpc2FibGVkOyBSQ0IgNjQgYnl0ZXMgRGlzYWJsZWQtIFJl
dHJhaW4tIENvbW1DbGstDQoJCQlFeHRTeW5jaC0gQ2xvY2tQTS0gQXV0V2lkRGlzLSBCV0lu
dC0gQXV0QldJbnQtDQoJCUxua1N0YToJU3BlZWQgMi41R1QvcywgV2lkdGggeDEsIFRyRXJy
LSBUcmFpbi0gU2xvdENsay0gRExBY3RpdmUtIEJXTWdtdC0gQUJXTWdtdC0NCglLZXJuZWwg
ZHJpdmVyIGluIHVzZTogcGNpYmFjaw0KDQowYjowMC4wIFZHQSBjb21wYXRpYmxlIGNvbnRy
b2xsZXIgWzAzMDBdOiBuVmlkaWEgQ29ycG9yYXRpb24gRzk4IFtHZUZvcmNlIDg0MDAgR1Nd
IFsxMGRlOjA2ZTRdIChyZXYgYTEpIChwcm9nLWlmIDAwIFtWR0EgY29udHJvbGxlcl0pDQoJ
U3Vic3lzdGVtOiBBU1VTVGVLIENvbXB1dGVyIEluYy4gRGV2aWNlIFsxMDQzOjgyNjZdDQoJ
Q29udHJvbDogSS9PKyBNZW0rIEJ1c01hc3RlcisgU3BlY0N5Y2xlLSBNZW1XSU5WLSBWR0FT
bm9vcC0gUGFyRXJyLSBTdGVwcGluZy0gU0VSUisgRmFzdEIyQi0gRGlzSU5UeC0NCglTdGF0
dXM6IENhcCsgNjZNSHotIFVERi0gRmFzdEIyQi0gUGFyRXJyLSBERVZTRUw9ZmFzdCA+VEFi
b3J0LSA8VEFib3J0LSA8TUFib3J0LSA+U0VSUi0gPFBFUlItIElOVHgtDQoJTGF0ZW5jeTog
MCwgQ2FjaGUgTGluZSBTaXplOiA2NCBieXRlcw0KCUludGVycnVwdDogcGluIEEgcm91dGVk
IHRvIElSUSAxMA0KCVJlZ2lvbiAwOiBNZW1vcnkgYXQgZmQwMDAwMDAgKDMyLWJpdCwgbm9u
LXByZWZldGNoYWJsZSkgW3NpemU9MTZNXQ0KCVJlZ2lvbiAxOiBNZW1vcnkgYXQgZDAwMDAw
MDAgKDY0LWJpdCwgcHJlZmV0Y2hhYmxlKSBbc2l6ZT0yNTZNXQ0KCVJlZ2lvbiAzOiBNZW1v
cnkgYXQgZmEwMDAwMDAgKDY0LWJpdCwgbm9uLXByZWZldGNoYWJsZSkgW3NpemU9MzJNXQ0K
CVJlZ2lvbiA1OiBJL08gcG9ydHMgYXQgZTgwMCBbc2l6ZT0xMjhdDQoJRXhwYW5zaW9uIFJP
TSBhdCBmZTllMDAwMCBbZGlzYWJsZWRdIFtzaXplPTEyOEtdDQoJQ2FwYWJpbGl0aWVzOiBb
NjBdIFBvd2VyIE1hbmFnZW1lbnQgdmVyc2lvbiAzDQoJCUZsYWdzOiBQTUVDbGstIERTSS0g
RDEtIEQyLSBBdXhDdXJyZW50PTBtQSBQTUUoRDAtLEQxLSxEMi0sRDNob3QtLEQzY29sZC0p
DQoJCVN0YXR1czogRDAgTm9Tb2Z0UnN0KyBQTUUtRW5hYmxlLSBEU2VsPTAgRFNjYWxlPTAg
UE1FLQ0KCUNhcGFiaWxpdGllczogWzY4XSBNU0k6IEVuYWJsZS0gQ291bnQ9MS8xIE1hc2th
YmxlLSA2NGJpdCsNCgkJQWRkcmVzczogMDAwMDAwMDAwMDAwMDAwMCAgRGF0YTogMDAwMA0K
CUNhcGFiaWxpdGllczogWzc4XSBFeHByZXNzICh2MSkgRW5kcG9pbnQsIE1TSSAwMA0KCQlE
ZXZDYXA6CU1heFBheWxvYWQgMTI4IGJ5dGVzLCBQaGFudEZ1bmMgMCwgTGF0ZW5jeSBMMHMg
PDUxMm5zLCBMMSA8NHVzDQoJCQlFeHRUYWcrIEF0dG5CdG4tIEF0dG5JbmQtIFB3ckluZC0g
UkJFKyBGTFJlc2V0LQ0KCQlEZXZDdGw6CVJlcG9ydCBlcnJvcnM6IENvcnJlY3RhYmxlLSBO
b24tRmF0YWwtIEZhdGFsLSBVbnN1cHBvcnRlZC0NCgkJCVJseGRPcmQtIEV4dFRhZy0gUGhh
bnRGdW5jLSBBdXhQd3ItIE5vU25vb3ArDQoJCQlNYXhQYXlsb2FkIDEyOCBieXRlcywgTWF4
UmVhZFJlcSA1MTIgYnl0ZXMNCgkJRGV2U3RhOglDb3JyRXJyLSBVbmNvcnJFcnItIEZhdGFs
RXJyLSBVbnN1cHBSZXEtIEF1eFB3ci0gVHJhbnNQZW5kLQ0KCQlMbmtDYXA6CVBvcnQgIzAs
IFNwZWVkIDIuNUdUL3MsIFdpZHRoIHgxNiwgQVNQTSBMMHMgTDEsIExhdGVuY3kgTDAgPDUx
Mm5zLCBMMSA8MXVzDQoJCQlDbG9ja1BNLSBTdXJwcmlzZS0gTExBY3RSZXAtIEJ3Tm90LQ0K
CQlMbmtDdGw6CUFTUE0gRGlzYWJsZWQ7IFJDQiAxMjggYnl0ZXMgRGlzYWJsZWQtIFJldHJh
aW4tIENvbW1DbGsrDQoJCQlFeHRTeW5jaC0gQ2xvY2tQTS0gQXV0V2lkRGlzLSBCV0ludC0g
QXV0QldJbnQtDQoJCUxua1N0YToJU3BlZWQgMi41R1QvcywgV2lkdGggeDgsIFRyRXJyLSBU
cmFpbi0gU2xvdENsaysgRExBY3RpdmUtIEJXTWdtdC0gQUJXTWdtdC0NCglDYXBhYmlsaXRp
ZXM6IFsxMDAgdjFdIFZpcnR1YWwgQ2hhbm5lbA0KCQlDYXBzOglMUEVWQz0wIFJlZkNsaz0x
MDBucyBQQVRFbnRyeUJpdHM9MQ0KCQlBcmI6CUZpeGVkLSBXUlIzMi0gV1JSNjQtIFdSUjEy
OC0NCgkJQ3RybDoJQXJiU2VsZWN0PUZpeGVkDQoJCVN0YXR1czoJSW5Qcm9ncmVzcy0NCgkJ
VkMwOglDYXBzOglQQVRPZmZzZXQ9MDAgTWF4VGltZVNsb3RzPTEgUmVqU25vb3BUcmFucy0N
CgkJCUFyYjoJRml4ZWQtIFdSUjMyLSBXUlI2NC0gV1JSMTI4LSBUV1JSMTI4LSBXUlIyNTYt
DQoJCQlDdHJsOglFbmFibGUrIElEPTAgQXJiU2VsZWN0PUZpeGVkIFRDL1ZDPWZmDQoJCQlT
dGF0dXM6CU5lZ29QZW5kaW5nLSBJblByb2dyZXNzLQ0KCUNhcGFiaWxpdGllczogWzEyOCB2
MV0gUG93ZXIgQnVkZ2V0aW5nIDw/Pg0KCUNhcGFiaWxpdGllczogWzYwMCB2MV0gVmVuZG9y
IFNwZWNpZmljIEluZm9ybWF0aW9uOiBJRD0wMDAxIFJldj0xIExlbj0wMjQgPD8+DQoNCg==
------------0F617E023294CEA4E
Content-Type: text/plain;
 name="xl-dmesg.txt"
Content-transfer-encoding: base64
Content-Disposition: attachment;
 filename="xl-dmesg.txt"

DQooWEVOKSBFbmFibGluZyBBUElDIG1vZGU6ICBGbGF0LiAgVXNpbmcgMiBJL08gQVBJQ3MN
CihYRU4pIEFDUEk6IEhQRVQgaWQ6IDB4ODMwMCBiYXNlOiAweGZlZDAwMDAwDQooWEVOKSBU
YWJsZSBpcyBub3QgZm91bmQhDQooWEVOKSBVc2luZyBBQ1BJIChNQURUKSBmb3IgU01QIGNv
bmZpZ3VyYXRpb24gaW5mb3JtYXRpb24NCihYRU4pIFNNUDogQWxsb3dpbmcgNiBDUFVzICgw
IGhvdHBsdWcgQ1BVcykNCihYRU4pIG1hcHBlZCBBUElDIHRvIGZmZmY4MmMzZmZkZmUwMDAg
KGZlZTAwMDAwKQ0KKFhFTikgbWFwcGVkIElPQVBJQyB0byBmZmZmODJjM2ZmZGZkMDAwIChm
ZWMwMDAwMCkNCihYRU4pIG1hcHBlZCBJT0FQSUMgdG8gZmZmZjgyYzNmZmRmYzAwMCAoZmVj
MjAwMDApDQooWEVOKSBJUlEgbGltaXRzOiA1NiBHU0ksIDExMTIgTVNJL01TSS1YDQooWEVO
KSBVc2luZyBzY2hlZHVsZXI6IFNNUCBDcmVkaXQgU2NoZWR1bGVyIChjcmVkaXQpDQooWEVO
KSBEZXRlY3RlZCAzMjAwLjE5OSBNSHogcHJvY2Vzc29yLg0KKFhFTikgSW5pdGluZyBtZW1v
cnkgc2hhcmluZy4NCihYRU4pIEFNRCBGYW0xMGggbWFjaGluZSBjaGVjayByZXBvcnRpbmcg
ZW5hYmxlZA0KKFhFTikgUENJOiBNQ0ZHIGNvbmZpZ3VyYXRpb24gMDogYmFzZSBlMDAwMDAw
MCBzZWdtZW50IDAwMDAgYnVzZXMgMDAgLSBmZg0KKFhFTikgUENJOiBOb3QgdXNpbmcgTUNG
RyBmb3Igc2VnbWVudCAwMDAwIGJ1cyAwMC1mZg0KKFhFTikgQU1ELVZpOiBGb3VuZCBNU0kg
Y2FwYWJpbGl0eSBibG9jayBhdCAweDU0DQooWEVOKSBBTUQtVmk6IEFDUEkgVGFibGU6DQoo
WEVOKSBBTUQtVmk6ICBTaWduYXR1cmUgSVZSUw0KKFhFTikgQU1ELVZpOiAgTGVuZ3RoIDB4
ZjgNCihYRU4pIEFNRC1WaTogIFJldmlzaW9uIDB4MQ0KKFhFTikgQU1ELVZpOiAgQ2hlY2tT
dW0gMHg2ZQ0KKFhFTikgQU1ELVZpOiAgT0VNX0lkIEFNRCAgDQooWEVOKSBBTUQtVmk6ICBP
RU1fVGFibGVfSWQgUkQ4OTBTDQooWEVOKSBBTUQtVmk6ICBPRU1fUmV2aXNpb24gMHgyMDIw
MzENCihYRU4pIEFNRC1WaTogIENyZWF0b3JfSWQgQU1EIA0KKFhFTikgQU1ELVZpOiAgQ3Jl
YXRvcl9SZXZpc2lvbiAweDANCihYRU4pIEFNRC1WaTogSVZSUyBCbG9jazoNCihYRU4pIEFN
RC1WaTogIFR5cGUgMHgxMA0KKFhFTikgQU1ELVZpOiAgRmxhZ3MgMHgzZQ0KKFhFTikgQU1E
LVZpOiAgTGVuZ3RoIDB4YzgNCihYRU4pIEFNRC1WaTogIERldl9JZCAweDINCihYRU4pIEFN
RC1WaTogSVZIRCBEZXZpY2UgRW50cnk6DQooWEVOKSBBTUQtVmk6ICBUeXBlIDB4Mw0KKFhF
TikgQU1ELVZpOiAgRGV2X0lkIDB4MA0KKFhFTikgQU1ELVZpOiAgRmxhZ3MgMHgwDQooWEVO
KSBBTUQtVmk6ICBEZXZfSWQgUmFuZ2U6IDB4MCAtPiAweDINCihYRU4pIEFNRC1WaTogSVZI
RCBEZXZpY2UgRW50cnk6DQooWEVOKSBBTUQtVmk6ICBUeXBlIDB4Mg0KKFhFTikgQU1ELVZp
OiAgRGV2X0lkIDB4MTANCihYRU4pIEFNRC1WaTogIEZsYWdzIDB4MA0KKFhFTikgQU1ELVZp
OiBJVkhEIERldmljZSBFbnRyeToNCihYRU4pIEFNRC1WaTogIFR5cGUgMHgyDQooWEVOKSBB
TUQtVmk6ICBEZXZfSWQgMHhiMDANCihYRU4pIEFNRC1WaTogIEZsYWdzIDB4MA0KKFhFTikg
QU1ELVZpOiBJVkhEIERldmljZSBFbnRyeToNCihYRU4pIEFNRC1WaTogIFR5cGUgMHgyDQoo
WEVOKSBBTUQtVmk6ICBEZXZfSWQgMHgxOA0KKFhFTikgQU1ELVZpOiAgRmxhZ3MgMHgwDQoo
WEVOKSBBTUQtVmk6IElWSEQgRGV2aWNlIEVudHJ5Og0KKFhFTikgQU1ELVZpOiAgVHlwZSAw
eDMNCihYRU4pIEFNRC1WaTogIERldl9JZCAweGEwMA0KKFhFTikgQU1ELVZpOiAgRmxhZ3Mg
MHgwDQooWEVOKSBBTUQtVmk6ICBEZXZfSWQgUmFuZ2U6IDB4YTAwIC0+IDB4YTA3DQooWEVO
KSBBTUQtVmk6IElWSEQgRGV2aWNlIEVudHJ5Og0KKFhFTikgQU1ELVZpOiAgVHlwZSAweDIN
CihYRU4pIEFNRC1WaTogIERldl9JZCAweDI4DQooWEVOKSBBTUQtVmk6ICBGbGFncyAweDAN
CihYRU4pIEFNRC1WaTogSVZIRCBEZXZpY2UgRW50cnk6DQooWEVOKSBBTUQtVmk6ICBUeXBl
IDB4Mg0KKFhFTikgQU1ELVZpOiAgRGV2X0lkIDB4OTAwDQooWEVOKSBBTUQtVmk6ICBGbGFn
cyAweDANCihYRU4pIEFNRC1WaTogSVZIRCBEZXZpY2UgRW50cnk6DQooWEVOKSBBTUQtVmk6
ICBUeXBlIDB4Mg0KKFhFTikgQU1ELVZpOiAgRGV2X0lkIDB4MzANCihYRU4pIEFNRC1WaTog
IEZsYWdzIDB4MA0KKFhFTikgQU1ELVZpOiBJVkhEIERldmljZSBFbnRyeToNCihYRU4pIEFN
RC1WaTogIFR5cGUgMHgyDQooWEVOKSBBTUQtVmk6ICBEZXZfSWQgMHg4MDANCihYRU4pIEFN
RC1WaTogIEZsYWdzIDB4MA0KKFhFTikgQU1ELVZpOiBJVkhEIERldmljZSBFbnRyeToNCihY
RU4pIEFNRC1WaTogIFR5cGUgMHgyDQooWEVOKSBBTUQtVmk6ICBEZXZfSWQgMHg1MA0KKFhF
TikgQU1ELVZpOiAgRmxhZ3MgMHgwDQooWEVOKSBBTUQtVmk6IElWSEQgRGV2aWNlIEVudHJ5
Og0KKFhFTikgQU1ELVZpOiAgVHlwZSAweDINCihYRU4pIEFNRC1WaTogIERldl9JZCAweDcw
MA0KKFhFTikgQU1ELVZpOiAgRmxhZ3MgMHgwDQooWEVOKSBBTUQtVmk6IElWSEQgRGV2aWNl
IEVudHJ5Og0KKFhFTikgQU1ELVZpOiAgVHlwZSAweDINCihYRU4pIEFNRC1WaTogIERldl9J
ZCAweDU4DQooWEVOKSBBTUQtVmk6ICBGbGFncyAweDANCihYRU4pIEFNRC1WaTogSVZIRCBE
ZXZpY2UgRW50cnk6DQooWEVOKSBBTUQtVmk6ICBUeXBlIDB4Mw0KKFhFTikgQU1ELVZpOiAg
RGV2X0lkIDB4NjAwDQooWEVOKSBBTUQtVmk6ICBGbGFncyAweDANCihYRU4pIEFNRC1WaTog
IERldl9JZCBSYW5nZTogMHg2MDAgLT4gMHg2MDENCihYRU4pIEFNRC1WaTogSVZIRCBEZXZp
Y2UgRW50cnk6DQooWEVOKSBBTUQtVmk6ICBUeXBlIDB4Mg0KKFhFTikgQU1ELVZpOiAgRGV2
X0lkIDB4NjANCihYRU4pIEFNRC1WaTogIEZsYWdzIDB4MA0KKFhFTikgQU1ELVZpOiBJVkhE
IERldmljZSBFbnRyeToNCihYRU4pIEFNRC1WaTogIFR5cGUgMHgyDQooWEVOKSBBTUQtVmk6
ICBEZXZfSWQgMHg1MDANCihYRU4pIEFNRC1WaTogIEZsYWdzIDB4MA0KKFhFTikgQU1ELVZp
OiBJVkhEIERldmljZSBFbnRyeToNCihYRU4pIEFNRC1WaTogIFR5cGUgMHgyDQooWEVOKSBB
TUQtVmk6ICBEZXZfSWQgMHg2OA0KKFhFTikgQU1ELVZpOiAgRmxhZ3MgMHgwDQooWEVOKSBB
TUQtVmk6IElWSEQgRGV2aWNlIEVudHJ5Og0KKFhFTikgQU1ELVZpOiAgVHlwZSAweDMNCihY
RU4pIEFNRC1WaTogIERldl9JZCAweDQwMA0KKFhFTikgQU1ELVZpOiAgRmxhZ3MgMHgwDQoo
WEVOKSBBTUQtVmk6ICBEZXZfSWQgUmFuZ2U6IDB4NDAwIC0+IDB4NDA3DQooWEVOKSBBTUQt
Vmk6IElWSEQgRGV2aWNlIEVudHJ5Og0KKFhFTikgQU1ELVZpOiAgVHlwZSAweDINCihYRU4p
IEFNRC1WaTogIERldl9JZCAweDg4DQooWEVOKSBBTUQtVmk6ICBGbGFncyAweDANCihYRU4p
IEFNRC1WaTogSVZIRCBEZXZpY2UgRW50cnk6DQooWEVOKSBBTUQtVmk6ICBUeXBlIDB4Mw0K
KFhFTikgQU1ELVZpOiAgRGV2X0lkIDB4OTANCihYRU4pIEFNRC1WaTogIEZsYWdzIDB4MA0K
KFhFTikgQU1ELVZpOiAgRGV2X0lkIFJhbmdlOiAweDkwIC0+IDB4OTINCihYRU4pIEFNRC1W
aTogSVZIRCBEZXZpY2UgRW50cnk6DQooWEVOKSBBTUQtVmk6ICBUeXBlIDB4Mw0KKFhFTikg
QU1ELVZpOiAgRGV2X0lkIDB4OTgNCihYRU4pIEFNRC1WaTogIEZsYWdzIDB4MA0KKFhFTikg
QU1ELVZpOiAgRGV2X0lkIFJhbmdlOiAweDk4IC0+IDB4OWENCihYRU4pIEFNRC1WaTogSVZI
RCBEZXZpY2UgRW50cnk6DQooWEVOKSBBTUQtVmk6ICBUeXBlIDB4Mg0KKFhFTikgQU1ELVZp
OiAgRGV2X0lkIDB4YTANCihYRU4pIEFNRC1WaTogIEZsYWdzIDB4ZDcNCihYRU4pIEFNRC1W
aTogSVZIRCBEZXZpY2UgRW50cnk6DQooWEVOKSBBTUQtVmk6ICBUeXBlIDB4Mg0KKFhFTikg
QU1ELVZpOiAgRGV2X0lkIDB4YTMNCihYRU4pIEFNRC1WaTogIEZsYWdzIDB4MA0KKFhFTikg
QU1ELVZpOiBJVkhEIERldmljZSBFbnRyeToNCihYRU4pIEFNRC1WaTogIFR5cGUgMHgyDQoo
WEVOKSBBTUQtVmk6ICBEZXZfSWQgMHhhNA0KKFhFTikgQU1ELVZpOiAgRmxhZ3MgMHgwDQoo
WEVOKSBBTUQtVmk6IElWSEQgRGV2aWNlIEVudHJ5Og0KKFhFTikgQU1ELVZpOiAgVHlwZSAw
eDANCihYRU4pIEFNRC1WaTogIERldl9JZCAweDANCihYRU4pIEFNRC1WaTogIEZsYWdzIDB4
MA0KKFhFTikgQU1ELVZpOiBJVkhEIERldmljZSBFbnRyeToNCihYRU4pIEFNRC1WaTogIFR5
cGUgMHg0Mw0KKFhFTikgQU1ELVZpOiAgRGV2X0lkIDB4MzAwDQooWEVOKSBBTUQtVmk6ICBG
bGFncyAweDANCihYRU4pIEFNRC1WaTogIERldl9JZCBSYW5nZTogMHgzMDAgLT4gMHgzZmYN
CihYRU4pIEFNRC1WaTogIERldl9JZCBBbGlhczogMHhhNA0KKFhFTikgQU1ELVZpOiBJVkhE
IERldmljZSBFbnRyeToNCihYRU4pIEFNRC1WaTogIFR5cGUgMHgyDQooWEVOKSBBTUQtVmk6
ICBEZXZfSWQgMHhhNQ0KKFhFTikgQU1ELVZpOiAgRmxhZ3MgMHgwDQooWEVOKSBBTUQtVmk6
IElWSEQgRGV2aWNlIEVudHJ5Og0KKFhFTikgQU1ELVZpOiAgVHlwZSAweDINCihYRU4pIEFN
RC1WaTogIERldl9JZCAweGE4DQooWEVOKSBBTUQtVmk6ICBGbGFncyAweDANCihYRU4pIEFN
RC1WaTogSVZIRCBEZXZpY2UgRW50cnk6DQooWEVOKSBBTUQtVmk6ICBUeXBlIDB4Mg0KKFhF
TikgQU1ELVZpOiAgRGV2X0lkIDB4YTkNCihYRU4pIEFNRC1WaTogIEZsYWdzIDB4MA0KKFhF
TikgQU1ELVZpOiBJVkhEIERldmljZSBFbnRyeToNCihYRU4pIEFNRC1WaTogIFR5cGUgMHgy
DQooWEVOKSBBTUQtVmk6ICBEZXZfSWQgMHgxMDANCihYRU4pIEFNRC1WaTogIEZsYWdzIDB4
MA0KKFhFTikgQU1ELVZpOiBJVkhEIERldmljZSBFbnRyeToNCihYRU4pIEFNRC1WaTogIFR5
cGUgMHgzDQooWEVOKSBBTUQtVmk6ICBEZXZfSWQgMHhiMA0KKFhFTikgQU1ELVZpOiAgRmxh
Z3MgMHgwDQooWEVOKSBBTUQtVmk6ICBEZXZfSWQgUmFuZ2U6IDB4YjAgLT4gMHhiMg0KKFhF
TikgQU1ELVZpOiBJVkhEIERldmljZSBFbnRyeToNCihYRU4pIEFNRC1WaTogIFR5cGUgMHgw
DQooWEVOKSBBTUQtVmk6ICBEZXZfSWQgMHgwDQooWEVOKSBBTUQtVmk6ICBGbGFncyAweDAN
CihYRU4pIEFNRC1WaTogSVZIRCBEZXZpY2UgRW50cnk6DQooWEVOKSBBTUQtVmk6ICBUeXBl
IDB4NDgNCihYRU4pIEFNRC1WaTogIERldl9JZCAweDANCihYRU4pIEFNRC1WaTogIEZsYWdz
IDB4ZDcNCihYRU4pIEFNRC1WaTogSVZIRCBEZXZpY2UgRW50cnk6DQooWEVOKSBBTUQtVmk6
ICBUeXBlIDB4NDgNCihYRU4pIEFNRC1WaTogIERldl9JZCAweDANCihYRU4pIEFNRC1WaTog
IEZsYWdzIDB4MA0KKFhFTikgQU1ELVZpOiBJT01NVSAwIEVuYWJsZWQuDQooWEVOKSBBTUQt
Vmk6IEVuYWJsaW5nIGdsb2JhbCB2ZWN0b3IgbWFwDQooWEVOKSBJL08gdmlydHVhbGlzYXRp
b24gZW5hYmxlZA0KKFhFTikgIC0gRG9tMCBtb2RlOiBSZWxheGVkDQooWEVOKSBHZXR0aW5n
IFZFUlNJT046IDgwMDUwMDEwDQooWEVOKSBHZXR0aW5nIFZFUlNJT046IDgwMDUwMDEwDQoo
WEVOKSBHZXR0aW5nIElEOiAwDQooWEVOKSBHZXR0aW5nIExWVDA6IDcwMA0KKFhFTikgR2V0
dGluZyBMVlQxOiA0MDANCihYRU4pIGVuYWJsZWQgRXh0SU5UIG9uIENQVSMwDQooWEVOKSBF
U1IgdmFsdWUgYmVmb3JlIGVuYWJsaW5nIHZlY3RvcjogMHgwMDAwMDAwNCAgYWZ0ZXI6IDB4
MDAwMDAwMDANCihYRU4pIEVOQUJMSU5HIElPLUFQSUMgSVJRcw0KKFhFTikgIC0+IFVzaW5n
IG5ldyBBQ0sgbWV0aG9kDQooWEVOKSBpbml0IElPX0FQSUMgSVJRcw0KKFhFTikgIElPLUFQ
SUMgKGFwaWNpZC1waW4pIDYtMCwgNi0xNiwgNi0xNywgNi0xOCwgNi0xOSwgNi0yMCwgNi0y
MSwgNi0yMiwgNi0yMywgNy0wLCA3LTEsIDctMiwgNy0zLCA3LTQsIDctNSwgNy02LCA3LTcs
IDctOCwgNy05LCA3LTEwLCA3LTExLCA3LTEyLCA3LTEzLCA3LTE0LCA3LTE1LCA3LTE2LCA3
LTE3LCA3LTE4LCA3LTE5LCA3LTIwLCA3LTIxLCA3LTIyLCA3LTIzLCA3LTI0LCA3LTI1LCA3
LTI2LCA3LTI3LCA3LTI4LCA3LTI5LCA3LTMwLCA3LTMxIG5vdCBjb25uZWN0ZWQuDQooWEVO
KSAuLlRJTUVSOiB2ZWN0b3I9MHhGMCBhcGljMT0wIHBpbjE9MiBhcGljMj0tMSBwaW4yPS0x
DQooWEVOKSBudW1iZXIgb2YgTVAgSVJRIHNvdXJjZXM6IDE1Lg0KKFhFTikgbnVtYmVyIG9m
IElPLUFQSUMgIzYgcmVnaXN0ZXJzOiAyNC4NCihYRU4pIG51bWJlciBvZiBJTy1BUElDICM3
IHJlZ2lzdGVyczogMzIuDQooWEVOKSB0ZXN0aW5nIHRoZSBJTyBBUElDLi4uLi4uLi4uLi4u
Li4uLi4uLi4uLi4NCihYRU4pIElPIEFQSUMgIzYuLi4uLi4NCihYRU4pIC4uLi4gcmVnaXN0
ZXIgIzAwOiAwNjAwMDAwMA0KKFhFTikgLi4uLi4uLiAgICA6IHBoeXNpY2FsIEFQSUMgaWQ6
IDA2DQooWEVOKSAuLi4uLi4uICAgIDogRGVsaXZlcnkgVHlwZTogMA0KKFhFTikgLi4uLi4u
LiAgICA6IExUUyAgICAgICAgICA6IDANCihYRU4pIC4uLi4gcmVnaXN0ZXIgIzAxOiAwMDE3
ODAyMQ0KKFhFTikgLi4uLi4uLiAgICAgOiBtYXggcmVkaXJlY3Rpb24gZW50cmllczogMDAx
Nw0KKFhFTikgLi4uLi4uLiAgICAgOiBQUlEgaW1wbGVtZW50ZWQ6IDENCihYRU4pIC4uLi4u
Li4gICAgIDogSU8gQVBJQyB2ZXJzaW9uOiAwMDIxDQooWEVOKSAuLi4uIHJlZ2lzdGVyICMw
MjogMDYwMDAwMDANCihYRU4pIC4uLi4uLi4gICAgIDogYXJiaXRyYXRpb246IDA2DQooWEVO
KSAuLi4uIHJlZ2lzdGVyICMwMzogMDcwMDAwMDANCihYRU4pIC4uLi4uLi4gICAgIDogQm9v
dCBEVCAgICA6IDANCihYRU4pIC4uLi4gSVJRIHJlZGlyZWN0aW9uIHRhYmxlOg0KKFhFTikg
IE5SIExvZyBQaHkgTWFzayBUcmlnIElSUiBQb2wgU3RhdCBEZXN0IERlbGkgVmVjdDogICAN
CihYRU4pICAwMCAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAw
DQooWEVOKSAgMDEgMDAxIDAxICAwICAgIDAgICAgMCAgIDAgICAwICAgIDEgICAgMSAgICAz
MA0KKFhFTikgIDAyIDAwMSAwMSAgMCAgICAwICAgIDAgICAwICAgMCAgICAxICAgIDEgICAg
RjANCihYRU4pICAwMyAwMDEgMDEgIDAgICAgMCAgICAwICAgMCAgIDAgICAgMSAgICAxICAg
IDM4DQooWEVOKSAgMDQgMDAxIDAxICAwICAgIDAgICAgMCAgIDAgICAwICAgIDEgICAgMSAg
ICBGMQ0KKFhFTikgIDA1IDAwMSAwMSAgMCAgICAwICAgIDAgICAwICAgMCAgICAxICAgIDEg
ICAgNDANCihYRU4pICAwNiAwMDEgMDEgIDAgICAgMCAgICAwICAgMCAgIDAgICAgMSAgICAx
ICAgIDQ4DQooWEVOKSAgMDcgMDAxIDAxICAwICAgIDAgICAgMCAgIDAgICAwICAgIDEgICAg
MSAgICA1MA0KKFhFTikgIDA4IDAwMSAwMSAgMCAgICAwICAgIDAgICAwICAgMCAgICAxICAg
IDEgICAgNTgNCihYRU4pICAwOSAwMDEgMDEgIDEgICAgMSAgICAwICAgMSAgIDAgICAgMSAg
ICAxICAgIDYwDQooWEVOKSAgMGEgMDAxIDAxICAwICAgIDAgICAgMCAgIDAgICAwICAgIDEg
ICAgMSAgICA2OA0KKFhFTikgIDBiIDAwMSAwMSAgMCAgICAwICAgIDAgICAwICAgMCAgICAx
ICAgIDEgICAgNzANCihYRU4pICAwYyAwMDEgMDEgIDAgICAgMCAgICAwICAgMCAgIDAgICAg
MSAgICAxICAgIDc4DQooWEVOKSAgMGQgMDAxIDAxICAwICAgIDAgICAgMCAgIDAgICAwICAg
IDEgICAgMSAgICA4OA0KKFhFTikgIDBlIDAwMSAwMSAgMCAgICAwICAgIDAgICAwICAgMCAg
ICAxICAgIDEgICAgOTANCihYRU4pICAwZiAwMDEgMDEgIDAgICAgMCAgICAwICAgMCAgIDAg
ICAgMSAgICAxICAgIDk4DQooWEVOKSAgMTAgMDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAw
ICAgIDAgICAgMCAgICAwMA0KKFhFTikgIDExIDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAg
MCAgICAwICAgIDAgICAgMDANCihYRU4pICAxMiAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAg
IDAgICAgMCAgICAwICAgIDAwDQooWEVOKSAgMTMgMDAwIDAwICAxICAgIDAgICAgMCAgIDAg
ICAwICAgIDAgICAgMCAgICAwMA0KKFhFTikgIDE0IDAwMCAwMCAgMSAgICAwICAgIDAgICAw
ICAgMCAgICAwICAgIDAgICAgMDANCihYRU4pICAxNSAwMDAgMDAgIDEgICAgMCAgICAwICAg
MCAgIDAgICAgMCAgICAwICAgIDAwDQooWEVOKSAgMTYgMDAwIDAwICAxICAgIDAgICAgMCAg
IDAgICAwICAgIDAgICAgMCAgICAwMA0KKFhFTikgIDE3IDAwMCAwMCAgMSAgICAwICAgIDAg
ICAwICAgMCAgICAwICAgIDAgICAgMDANCihYRU4pIElPIEFQSUMgIzcuLi4uLi4NCihYRU4p
IC4uLi4gcmVnaXN0ZXIgIzAwOiAwNzAwMDAwMA0KKFhFTikgLi4uLi4uLiAgICA6IHBoeXNp
Y2FsIEFQSUMgaWQ6IDA3DQooWEVOKSAuLi4uLi4uICAgIDogRGVsaXZlcnkgVHlwZTogMA0K
KFhFTikgLi4uLi4uLiAgICA6IExUUyAgICAgICAgICA6IDANCihYRU4pIC4uLi4gcmVnaXN0
ZXIgIzAxOiAwMDFGODAyMQ0KKFhFTikgLi4uLi4uLiAgICAgOiBtYXggcmVkaXJlY3Rpb24g
ZW50cmllczogMDAxRg0KKFhFTikgLi4uLi4uLiAgICAgOiBQUlEgaW1wbGVtZW50ZWQ6IDEN
CihYRU4pIC4uLi4uLi4gICAgIDogSU8gQVBJQyB2ZXJzaW9uOiAwMDIxDQooWEVOKSAuLi4u
IHJlZ2lzdGVyICMwMjogMDAwMDAwMDANCihYRU4pIC4uLi4uLi4gICAgIDogYXJiaXRyYXRp
b246IDAwDQooWEVOKSAuLi4uIElSUSByZWRpcmVjdGlvbiB0YWJsZToNCihYRU4pICBOUiBM
b2cgUGh5IE1hc2sgVHJpZyBJUlIgUG9sIFN0YXQgRGVzdCBEZWxpIFZlY3Q6ICAgDQooWEVO
KSAgMDAgMDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAwICAgIDAgICAgMCAgICAwMA0KKFhF
TikgIDAxIDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDAgICAgMDANCihY
RU4pICAwMiAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwDQoo
WEVOKSAgMDMgMDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAwICAgIDAgICAgMCAgICAwMA0K
KFhFTikgIDA0IDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDAgICAgMDAN
CihYRU4pICAwNSAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAw
DQooWEVOKSAgMDYgMDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAwICAgIDAgICAgMCAgICAw
MA0KKFhFTikgIDA3IDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDAgICAg
MDANCihYRU4pICAwOCAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAg
IDAwDQooWEVOKSAgMDkgMDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAwICAgIDAgICAgMCAg
ICAwMA0KKFhFTikgIDBhIDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDAg
ICAgMDANCihYRU4pICAwYiAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAw
ICAgIDAwDQooWEVOKSAgMGMgMDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAwICAgIDAgICAg
MCAgICAwMA0KKFhFTikgIDBkIDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAg
IDAgICAgMDANCihYRU4pICAwZSAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAg
ICAwICAgIDAwDQooWEVOKSAgMGYgMDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAwICAgIDAg
ICAgMCAgICAwMA0KKFhFTikgIDEwIDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAw
ICAgIDAgICAgMDANCihYRU4pICAxMSAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAg
MCAgICAwICAgIDAwDQooWEVOKSAgMTIgMDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAwICAg
IDAgICAgMCAgICAwMA0KKFhFTikgIDEzIDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAg
ICAwICAgIDAgICAgMDANCihYRU4pICAxNCAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAg
ICAgMCAgICAwICAgIDAwDQooWEVOKSAgMTUgMDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAw
ICAgIDAgICAgMCAgICAwMA0KKFhFTikgIDE2IDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAg
MCAgICAwICAgIDAgICAgMDANCihYRU4pICAxNyAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAg
IDAgICAgMCAgICAwICAgIDAwDQooWEVOKSAgMTggMDAwIDAwICAxICAgIDAgICAgMCAgIDAg
ICAwICAgIDAgICAgMCAgICAwMA0KKFhFTikgIDE5IDAwMCAwMCAgMSAgICAwICAgIDAgICAw
ICAgMCAgICAwICAgIDAgICAgMDANCihYRU4pICAxYSAwMDAgMDAgIDEgICAgMCAgICAwICAg
MCAgIDAgICAgMCAgICAwICAgIDAwDQooWEVOKSAgMWIgMDAwIDAwICAxICAgIDAgICAgMCAg
IDAgICAwICAgIDAgICAgMCAgICAwMA0KKFhFTikgIDFjIDAwMCAwMCAgMSAgICAwICAgIDAg
ICAwICAgMCAgICAwICAgIDAgICAgMDANCihYRU4pICAxZCAwMDAgMDAgIDEgICAgMCAgICAw
ICAgMCAgIDAgICAgMCAgICAwICAgIDAwDQooWEVOKSAgMWUgMDAwIDAwICAxICAgIDAgICAg
MCAgIDAgICAwICAgIDAgICAgMCAgICAwMA0KKFhFTikgIDFmIDAwMCAwMCAgMSAgICAwICAg
IDAgICAwICAgMCAgICAwICAgIDAgICAgMDANCihYRU4pIFVzaW5nIHZlY3Rvci1iYXNlZCBp
bmRleGluZw0KKFhFTikgSVJRIHRvIHBpbiBtYXBwaW5nczoNCihYRU4pIElSUTI0MCAtPiAw
OjINCihYRU4pIElSUTQ4IC0+IDA6MQ0KKFhFTikgSVJRNTYgLT4gMDozDQooWEVOKSBJUlEy
NDEgLT4gMDo0DQooWEVOKSBJUlE2NCAtPiAwOjUNCihYRU4pIElSUTcyIC0+IDA6Ng0KKFhF
TikgSVJRODAgLT4gMDo3DQooWEVOKSBJUlE4OCAtPiAwOjgNCihYRU4pIElSUTk2IC0+IDA6
OQ0KKFhFTikgSVJRMTA0IC0+IDA6MTANCihYRU4pIElSUTExMiAtPiAwOjExDQooWEVOKSBJ
UlExMjAgLT4gMDoxMg0KKFhFTikgSVJRMTM2IC0+IDA6MTMNCihYRU4pIElSUTE0NCAtPiAw
OjE0DQooWEVOKSBJUlExNTIgLT4gMDoxNQ0KKFhFTikgLi4uLi4uLi4uLi4uLi4uLi4uLi4u
Li4uLi4uLi4uLi4uLi4uIGRvbmUuDQooWEVOKSBVc2luZyBsb2NhbCBBUElDIHRpbWVyIGlu
dGVycnVwdHMuDQooWEVOKSBjYWxpYnJhdGluZyBBUElDIHRpbWVyIC4uLg0KKFhFTikgLi4u
Li4gQ1BVIGNsb2NrIHNwZWVkIGlzIDMyMDAuMTM3OCBNSHouDQooWEVOKSAuLi4uLiBob3N0
IGJ1cyBjbG9jayBzcGVlZCBpcyAyMDAuMDA4NSBNSHouDQooWEVOKSAuLi4uLiBidXNfc2Nh
bGUgPSAweDAwMDBDQ0Q3DQooWEVOKSBbMjAxMi0wOS0wNSAxNTo0OTowOV0gUGxhdGZvcm0g
dGltZXIgaXMgMTQuMzE4TUh6IEhQRVQNCihYRU4pIFsyMDEyLTA5LTA1IDE1OjQ5OjA5XSBB
bGxvY2F0ZWQgY29uc29sZSByaW5nIG9mIDY0IEtpQi4NCihYRU4pIFsyMDEyLTA5LTA1IDE1
OjQ5OjA5XSBIVk06IEFTSURzIGVuYWJsZWQuDQooWEVOKSBbMjAxMi0wOS0wNSAxNTo0OTow
OV0gU1ZNOiBTdXBwb3J0ZWQgYWR2YW5jZWQgZmVhdHVyZXM6DQooWEVOKSBbMjAxMi0wOS0w
NSAxNTo0OTowOV0gIC0gTmVzdGVkIFBhZ2UgVGFibGVzIChOUFQpDQooWEVOKSBbMjAxMi0w
OS0wNSAxNTo0OTowOV0gIC0gTGFzdCBCcmFuY2ggUmVjb3JkIChMQlIpIFZpcnR1YWxpc2F0
aW9uDQooWEVOKSBbMjAxMi0wOS0wNSAxNTo0OTowOV0gIC0gTmV4dC1SSVAgU2F2ZWQgb24g
I1ZNRVhJVA0KKFhFTikgWzIwMTItMDktMDUgMTU6NDk6MDldICAtIFBhdXNlLUludGVyY2Vw
dCBGaWx0ZXINCihYRU4pIFsyMDEyLTA5LTA1IDE1OjQ5OjA5XSBIVk06IFNWTSBlbmFibGVk
DQooWEVOKSBbMjAxMi0wOS0wNSAxNTo0OTowOV0gSFZNOiBIYXJkd2FyZSBBc3Npc3RlZCBQ
YWdpbmcgKEhBUCkgZGV0ZWN0ZWQNCihYRU4pIFsyMDEyLTA5LTA1IDE1OjQ5OjA5XSBIVk06
IEhBUCBwYWdlIHNpemVzOiA0a0IsIDJNQiwgMUdCDQooWEVOKSBbMjAxMi0wOS0wNSAxNTo0
OTowOF0gbWFza2VkIEV4dElOVCBvbiBDUFUjMQ0KKFhFTikgWzIwMTItMDktMDUgMTU6NDk6
MDldIG1pY3JvY29kZTogY29sbGVjdF9jcHVfaW5mbzogcGF0Y2hfaWQ9MHgxMDAwMGJmDQoo
WEVOKSBbMjAxMi0wOS0wNSAxNTo0OTowOF0gbWFza2VkIEV4dElOVCBvbiBDUFUjMg0KKFhF
TikgWzIwMTItMDktMDUgMTU6NDk6MDldIG1pY3JvY29kZTogY29sbGVjdF9jcHVfaW5mbzog
cGF0Y2hfaWQ9MHgxMDAwMGJmDQooWEVOKSBbMjAxMi0wOS0wNSAxNTo0OTowOF0gbWFza2Vk
IEV4dElOVCBvbiBDUFUjMw0KKFhFTikgWzIwMTItMDktMDUgMTU6NDk6MDldIG1pY3JvY29k
ZTogY29sbGVjdF9jcHVfaW5mbzogcGF0Y2hfaWQ9MHgxMDAwMGJmDQooWEVOKSBbMjAxMi0w
OS0wNSAxNTo0OTowOF0gbWFza2VkIEV4dElOVCBvbiBDUFUjNA0KKFhFTikgWzIwMTItMDkt
MDUgMTU6NDk6MDldIG1pY3JvY29kZTogY29sbGVjdF9jcHVfaW5mbzogcGF0Y2hfaWQ9MHgx
MDAwMGJmDQooWEVOKSBbMjAxMi0wOS0wNSAxNTo0OTowOF0gbWFza2VkIEV4dElOVCBvbiBD
UFUjNQ0KKFhFTikgWzIwMTItMDktMDUgMTU6NDk6MDldIEJyb3VnaHQgdXAgNiBDUFVzDQoo
WEVOKSBbMjAxMi0wOS0wNSAxNTo0OTowOV0gbWljcm9jb2RlOiBjb2xsZWN0X2NwdV9pbmZv
OiBwYXRjaF9pZD0weDEwMDAwYmYNCihYRU4pIFsyMDEyLTA5LTA1IDE1OjQ5OjA5XSBIUEVU
J3MgTVNJIG1vZGUgaGFzbid0IGJlZW4gc3VwcG9ydGVkIHdoZW4gSW50ZXJydXB0IFJlbWFw
cGluZyBpcyBlbmFibGVkLg0KKFhFTikgWzIwMTItMDktMDUgMTU6NDk6MDldIEFDUEkgc2xl
ZXAgbW9kZXM6IFMzDQooWEVOKSBbMjAxMi0wOS0wNSAxNTo0OTowOV0gTUNBOiBVc2UgaHcg
dGhyZXNob2xkaW5nIHRvIGFkanVzdCBwb2xsaW5nIGZyZXF1ZW5jeQ0KKFhFTikgWzIwMTIt
MDktMDUgMTU6NDk6MDldIG1jaGVja19wb2xsOiBNYWNoaW5lIGNoZWNrIHBvbGxpbmcgdGlt
ZXIgc3RhcnRlZC4NCihYRU4pIFsyMDEyLTA5LTA1IDE1OjQ5OjA5XSBYZW5vcHJvZmlsZTog
RmFpbGVkIHRvIHNldHVwIElCUyBMVlQgb2Zmc2V0LCBJQlNDVEwgPSAweGZmZmZmZmZmDQoo
WEVOKSBbMjAxMi0wOS0wNSAxNTo0OTowOV0gKioqIExPQURJTkcgRE9NQUlOIDAgKioqDQoo
WEVOKSBbMjAxMi0wOS0wNSAxNTo0OTowOV0gZWxmX3BhcnNlX2JpbmFyeTogcGhkcjogcGFk
ZHI9MHgxMDAwMDAwIG1lbXN6PTB4ZDZhMDAwDQooWEVOKSBbMjAxMi0wOS0wNSAxNTo0OTow
OV0gZWxmX3BhcnNlX2JpbmFyeTogcGhkcjogcGFkZHI9MHgxZTAwMDAwIG1lbXN6PTB4ZGIw
ZTgNCihYRU4pIFsyMDEyLTA5LTA1IDE1OjQ5OjA5XSBlbGZfcGFyc2VfYmluYXJ5OiBwaGRy
OiBwYWRkcj0weDFlZGMwMDAgbWVtc3o9MHgxM2MwMA0KKFhFTikgWzIwMTItMDktMDUgMTU6
NDk6MDldIGVsZl9wYXJzZV9iaW5hcnk6IHBoZHI6IHBhZGRyPTB4MWVmMDAwMCBtZW1zej0w
eGRlNTAwMA0KKFhFTikgWzIwMTItMDktMDUgMTU6NDk6MDldIGVsZl9wYXJzZV9iaW5hcnk6
IG1lbW9yeTogMHgxMDAwMDAwIC0+IDB4MmNkNTAwMA0KKFhFTikgWzIwMTItMDktMDUgMTU6
NDk6MDldIGVsZl94ZW5fcGFyc2Vfbm90ZTogR1VFU1RfT1MgPSAibGludXgiDQooWEVOKSBb
MjAxMi0wOS0wNSAxNTo0OTowOV0gZWxmX3hlbl9wYXJzZV9ub3RlOiBHVUVTVF9WRVJTSU9O
ID0gIjIuNiINCihYRU4pIFsyMDEyLTA5LTA1IDE1OjQ5OjA5XSBlbGZfeGVuX3BhcnNlX25v
dGU6IFhFTl9WRVJTSU9OID0gInhlbi0zLjAiDQooWEVOKSBbMjAxMi0wOS0wNSAxNTo0OTow
OV0gZWxmX3hlbl9wYXJzZV9ub3RlOiBWSVJUX0JBU0UgPSAweGZmZmZmZmZmODAwMDAwMDAN
CihYRU4pIFsyMDEyLTA5LTA1IDE1OjQ5OjA5XSBlbGZfeGVuX3BhcnNlX25vdGU6IEVOVFJZ
ID0gMHhmZmZmZmZmZjgxZWYwMjEwDQooWEVOKSBbMjAxMi0wOS0wNSAxNTo0OTowOV0gZWxm
X3hlbl9wYXJzZV9ub3RlOiBIWVBFUkNBTExfUEFHRSA9IDB4ZmZmZmZmZmY4MTAwMTAwMA0K
KFhFTikgWzIwMTItMDktMDUgMTU6NDk6MDldIGVsZl94ZW5fcGFyc2Vfbm90ZTogRkVBVFVS
RVMgPSAiIXdyaXRhYmxlX3BhZ2VfdGFibGVzfHBhZV9wZ2Rpcl9hYm92ZV80Z2IiDQooWEVO
KSBbMjAxMi0wOS0wNSAxNTo0OTowOV0gZWxmX3hlbl9wYXJzZV9ub3RlOiBQQUVfTU9ERSA9
ICJ5ZXMiDQooWEVOKSBbMjAxMi0wOS0wNSAxNTo0OTowOV0gZWxmX3hlbl9wYXJzZV9ub3Rl
OiBMT0FERVIgPSAiZ2VuZXJpYyINCihYRU4pIFsyMDEyLTA5LTA1IDE1OjQ5OjA5XSBlbGZf
eGVuX3BhcnNlX25vdGU6IHVua25vd24geGVuIGVsZiBub3RlICgweGQpDQooWEVOKSBbMjAx
Mi0wOS0wNSAxNTo0OTowOV0gZWxmX3hlbl9wYXJzZV9ub3RlOiBTVVNQRU5EX0NBTkNFTCA9
IDB4MQ0KKFhFTikgWzIwMTItMDktMDUgMTU6NDk6MDldIGVsZl94ZW5fcGFyc2Vfbm90ZTog
SFZfU1RBUlRfTE9XID0gMHhmZmZmODAwMDAwMDAwMDAwDQooWEVOKSBbMjAxMi0wOS0wNSAx
NTo0OTowOV0gZWxmX3hlbl9wYXJzZV9ub3RlOiBQQUREUl9PRkZTRVQgPSAweDANCihYRU4p
IFsyMDEyLTA5LTA1IDE1OjQ5OjA5XSBlbGZfeGVuX2FkZHJfY2FsY19jaGVjazogYWRkcmVz
c2VzOg0KKFhFTikgWzIwMTItMDktMDUgMTU6NDk6MDldICAgICB2aXJ0X2Jhc2UgICAgICAg
ID0gMHhmZmZmZmZmZjgwMDAwMDAwDQooWEVOKSBbMjAxMi0wOS0wNSAxNTo0OTowOV0gICAg
IGVsZl9wYWRkcl9vZmZzZXQgPSAweDANCihYRU4pIFsyMDEyLTA5LTA1IDE1OjQ5OjA5XSAg
ICAgdmlydF9vZmZzZXQgICAgICA9IDB4ZmZmZmZmZmY4MDAwMDAwMA0KKFhFTikgWzIwMTIt
MDktMDUgMTU6NDk6MDldICAgICB2aXJ0X2tzdGFydCAgICAgID0gMHhmZmZmZmZmZjgxMDAw
MDAwDQooWEVOKSBbMjAxMi0wOS0wNSAxNTo0OTowOV0gICAgIHZpcnRfa2VuZCAgICAgICAg
PSAweGZmZmZmZmZmODJjZDUwMDANCihYRU4pIFsyMDEyLTA5LTA1IDE1OjQ5OjA5XSAgICAg
dmlydF9lbnRyeSAgICAgICA9IDB4ZmZmZmZmZmY4MWVmMDIxMA0KKFhFTikgWzIwMTItMDkt
MDUgMTU6NDk6MDldICAgICBwMm1fYmFzZSAgICAgICAgID0gMHhmZmZmZmZmZmZmZmZmZmZm
DQooWEVOKSBbMjAxMi0wOS0wNSAxNTo0OTowOV0gIFhlbiAga2VybmVsOiA2NC1iaXQsIGxz
YiwgY29tcGF0MzINCihYRU4pIFsyMDEyLTA5LTA1IDE1OjQ5OjA5XSAgRG9tMCBrZXJuZWw6
IDY0LWJpdCwgUEFFLCBsc2IsIHBhZGRyIDB4MTAwMDAwMCAtPiAweDJjZDUwMDANCihYRU4p
IFsyMDEyLTA5LTA1IDE1OjQ5OjA5XSBQSFlTSUNBTCBNRU1PUlkgQVJSQU5HRU1FTlQ6DQoo
WEVOKSBbMjAxMi0wOS0wNSAxNTo0OTowOV0gIERvbTAgYWxsb2MuOiAgIDAwMDAwMDAyNDAw
MDAwMDAtPjAwMDAwMDAyNDQwMDAwMDAgKDI0MjQyOCBwYWdlcyB0byBiZSBhbGxvY2F0ZWQp
DQooWEVOKSBbMjAxMi0wOS0wNSAxNTo0OTowOV0gIEluaXQuIHJhbWRpc2s6IDAwMDAwMDAy
NGYyZmMwMDAtPjAwMDAwMDAyNGZmZmY4MDANCihYRU4pIFsyMDEyLTA5LTA1IDE1OjQ5OjA5
XSBWSVJUVUFMIE1FTU9SWSBBUlJBTkdFTUVOVDoNCihYRU4pIFsyMDEyLTA5LTA1IDE1OjQ5
OjA5XSAgTG9hZGVkIGtlcm5lbDogZmZmZmZmZmY4MTAwMDAwMC0+ZmZmZmZmZmY4MmNkNTAw
MA0KKFhFTikgWzIwMTItMDktMDUgMTU6NDk6MDldICBJbml0LiByYW1kaXNrOiBmZmZmZmZm
ZjgyY2Q1MDAwLT5mZmZmZmZmZjgzOWQ4ODAwDQooWEVOKSBbMjAxMi0wOS0wNSAxNTo0OTow
OV0gIFBoeXMtTWFjaCBtYXA6IGZmZmZmZmZmODM5ZDkwMDAtPmZmZmZmZmZmODNiZDkwMDAN
CihYRU4pIFsyMDEyLTA5LTA1IDE1OjQ5OjA5XSAgU3RhcnQgaW5mbzogICAgZmZmZmZmZmY4
M2JkOTAwMC0+ZmZmZmZmZmY4M2JkOTRiNA0KKFhFTikgWzIwMTItMDktMDUgMTU6NDk6MDld
ICBQYWdlIHRhYmxlczogICBmZmZmZmZmZjgzYmRhMDAwLT5mZmZmZmZmZjgzYmZkMDAwDQoo
WEVOKSBbMjAxMi0wOS0wNSAxNTo0OTowOV0gIEJvb3Qgc3RhY2s6ICAgIGZmZmZmZmZmODNi
ZmQwMDAtPmZmZmZmZmZmODNiZmUwMDANCihYRU4pIFsyMDEyLTA5LTA1IDE1OjQ5OjA5XSAg
VE9UQUw6ICAgICAgICAgZmZmZmZmZmY4MDAwMDAwMC0+ZmZmZmZmZmY4NDAwMDAwMA0KKFhF
TikgWzIwMTItMDktMDUgMTU6NDk6MDldICBFTlRSWSBBRERSRVNTOiBmZmZmZmZmZjgxZWYw
MjEwDQooWEVOKSBbMjAxMi0wOS0wNSAxNTo0OTowOV0gRG9tMCBoYXMgbWF4aW11bSA2IFZD
UFVzDQooWEVOKSBbMjAxMi0wOS0wNSAxNTo0OTowOV0gZWxmX2xvYWRfYmluYXJ5OiBwaGRy
IDAgYXQgMHhmZmZmZmZmZjgxMDAwMDAwIC0+IDB4ZmZmZmZmZmY4MWQ2YTAwMA0KKFhFTikg
WzIwMTItMDktMDUgMTU6NDk6MDldIGVsZl9sb2FkX2JpbmFyeTogcGhkciAxIGF0IDB4ZmZm
ZmZmZmY4MWUwMDAwMCAtPiAweGZmZmZmZmZmODFlZGIwZTgNCihYRU4pIFsyMDEyLTA5LTA1
IDE1OjQ5OjA5XSBlbGZfbG9hZF9iaW5hcnk6IHBoZHIgMiBhdCAweGZmZmZmZmZmODFlZGMw
MDAgLT4gMHhmZmZmZmZmZjgxZWVmYzAwDQooWEVOKSBbMjAxMi0wOS0wNSAxNTo0OTowOV0g
ZWxmX2xvYWRfYmluYXJ5OiBwaGRyIDMgYXQgMHhmZmZmZmZmZjgxZWYwMDAwIC0+IDB4ZmZm
ZmZmZmY4MWY4OTAwMA0KKFhFTikgWzIwMTItMDktMDUgMTU6NDk6MTBdIEFNRC1WaTogU2V0
dXAgSS9PIHBhZ2UgdGFibGU6IGRldmljZSBpZCA9IDB4MDAwMCwgcm9vdCB0YWJsZSA9IDB4
MjRkODRiMDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMNCihYRU4pIFsyMDEyLTA5
LTA1IDE1OjQ5OjEwXSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQg
PSAweDAwMDIsIHJvb3QgdGFibGUgPSAweDI0ZDg0YjAwMCwgZG9tYWluID0gMCwgcGFnaW5n
IG1vZGUgPSAzDQooWEVOKSBbMjAxMi0wOS0wNSAxNTo0OToxMF0gQU1ELVZpOiBTZXR1cCBJ
L08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHgwMDEwLCByb290IHRhYmxlID0gMHgyNGQ4
NGIwMDAsIGRvbWFpbiA9IDAsIHBhZ2luZyBtb2RlID0gMw0KKFhFTikgWzIwMTItMDktMDUg
MTU6NDk6MTBdIEFNRC1WaTogU2V0dXAgSS9PIHBhZ2UgdGFibGU6IGRldmljZSBpZCA9IDB4
MDAxOCwgcm9vdCB0YWJsZSA9IDB4MjRkODRiMDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9k
ZSA9IDMNCihYRU4pIFsyMDEyLTA5LTA1IDE1OjQ5OjEwXSBBTUQtVmk6IFNldHVwIEkvTyBw
YWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweDAwMjgsIHJvb3QgdGFibGUgPSAweDI0ZDg0YjAw
MCwgZG9tYWluID0gMCwgcGFnaW5nIG1vZGUgPSAzDQooWEVOKSBbMjAxMi0wOS0wNSAxNTo0
OToxMF0gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHgwMDMw
LCByb290IHRhYmxlID0gMHgyNGQ4NGIwMDAsIGRvbWFpbiA9IDAsIHBhZ2luZyBtb2RlID0g
Mw0KKFhFTikgWzIwMTItMDktMDUgMTU6NDk6MTBdIEFNRC1WaTogU2V0dXAgSS9PIHBhZ2Ug
dGFibGU6IGRldmljZSBpZCA9IDB4MDA1MCwgcm9vdCB0YWJsZSA9IDB4MjRkODRiMDAwLCBk
b21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMNCihYRU4pIFsyMDEyLTA5LTA1IDE1OjQ5OjEw
XSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweDAwNTgsIHJv
b3QgdGFibGUgPSAweDI0ZDg0YjAwMCwgZG9tYWluID0gMCwgcGFnaW5nIG1vZGUgPSAzDQoo
WEVOKSBbMjAxMi0wOS0wNSAxNTo0OToxMF0gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJs
ZTogZGV2aWNlIGlkID0gMHgwMDYwLCByb290IHRhYmxlID0gMHgyNGQ4NGIwMDAsIGRvbWFp
biA9IDAsIHBhZ2luZyBtb2RlID0gMw0KKFhFTikgWzIwMTItMDktMDUgMTU6NDk6MTBdIEFN
RC1WaTogU2V0dXAgSS9PIHBhZ2UgdGFibGU6IGRldmljZSBpZCA9IDB4MDA2OCwgcm9vdCB0
YWJsZSA9IDB4MjRkODRiMDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMNCihYRU4p
IFsyMDEyLTA5LTA1IDE1OjQ5OjEwXSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBk
ZXZpY2UgaWQgPSAweDAwODgsIHJvb3QgdGFibGUgPSAweDI0ZDg0YjAwMCwgZG9tYWluID0g
MCwgcGFnaW5nIG1vZGUgPSAzDQooWEVOKSBbMjAxMi0wOS0wNSAxNTo0OToxMF0gQU1ELVZp
OiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHgwMDkwLCByb290IHRhYmxl
ID0gMHgyNGQ4NGIwMDAsIGRvbWFpbiA9IDAsIHBhZ2luZyBtb2RlID0gMw0KKFhFTikgWzIw
MTItMDktMDUgMTU6NDk6MTBdIEFNRC1WaTogU2V0dXAgSS9PIHBhZ2UgdGFibGU6IGRldmlj
ZSBpZCA9IDB4MDA5Miwgcm9vdCB0YWJsZSA9IDB4MjRkODRiMDAwLCBkb21haW4gPSAwLCBw
YWdpbmcgbW9kZSA9IDMNCihYRU4pIFsyMDEyLTA5LTA1IDE1OjQ5OjEwXSBBTUQtVmk6IFNl
dHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweDAwOTgsIHJvb3QgdGFibGUgPSAw
eDI0ZDg0YjAwMCwgZG9tYWluID0gMCwgcGFnaW5nIG1vZGUgPSAzDQooWEVOKSBbMjAxMi0w
OS0wNSAxNTo0OToxMF0gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlk
ID0gMHgwMDlhLCByb290IHRhYmxlID0gMHgyNGQ4NGIwMDAsIGRvbWFpbiA9IDAsIHBhZ2lu
ZyBtb2RlID0gMw0KKFhFTikgWzIwMTItMDktMDUgMTU6NDk6MTBdIEFNRC1WaTogU2V0dXAg
SS9PIHBhZ2UgdGFibGU6IGRldmljZSBpZCA9IDB4MDBhMCwgcm9vdCB0YWJsZSA9IDB4MjRk
ODRiMDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMNCihYRU4pIFsyMDEyLTA5LTA1
IDE1OjQ5OjEwXSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAw
eDAwYTMsIHJvb3QgdGFibGUgPSAweDI0ZDg0YjAwMCwgZG9tYWluID0gMCwgcGFnaW5nIG1v
ZGUgPSAzDQooWEVOKSBbMjAxMi0wOS0wNSAxNTo0OToxMF0gQU1ELVZpOiBTZXR1cCBJL08g
cGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHgwMGE0LCByb290IHRhYmxlID0gMHgyNGQ4NGIw
MDAsIGRvbWFpbiA9IDAsIHBhZ2luZyBtb2RlID0gMw0KKFhFTikgWzIwMTItMDktMDUgMTU6
NDk6MTBdIEFNRC1WaTogU2V0dXAgSS9PIHBhZ2UgdGFibGU6IGRldmljZSBpZCA9IDB4MDBh
NSwgcm9vdCB0YWJsZSA9IDB4MjRkODRiMDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9
IDMNCihYRU4pIFsyMDEyLTA5LTA1IDE1OjQ5OjEwXSBBTUQtVmk6IFNldHVwIEkvTyBwYWdl
IHRhYmxlOiBkZXZpY2UgaWQgPSAweDAwYTgsIHJvb3QgdGFibGUgPSAweDI0ZDg0YjAwMCwg
ZG9tYWluID0gMCwgcGFnaW5nIG1vZGUgPSAzDQooWEVOKSBbMjAxMi0wOS0wNSAxNTo0OTox
MF0gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHgwMGIwLCBy
b290IHRhYmxlID0gMHgyNGQ4NGIwMDAsIGRvbWFpbiA9IDAsIHBhZ2luZyBtb2RlID0gMw0K
KFhFTikgWzIwMTItMDktMDUgMTU6NDk6MTBdIEFNRC1WaTogU2V0dXAgSS9PIHBhZ2UgdGFi
bGU6IGRldmljZSBpZCA9IDB4MDBiMiwgcm9vdCB0YWJsZSA9IDB4MjRkODRiMDAwLCBkb21h
aW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMNCihYRU4pIFsyMDEyLTA5LTA1IDE1OjQ5OjEwXSBB
TUQtVmk6IE5vIGlvbW11IGZvciBkZXZpY2UgMDAwMDowMDoxOC4wDQooWEVOKSBbMjAxMi0w
OS0wNSAxNTo0OToxMF0gQU1ELVZpOiBObyBpb21tdSBmb3IgZGV2aWNlIDAwMDA6MDA6MTgu
MQ0KKFhFTikgWzIwMTItMDktMDUgMTU6NDk6MTBdIEFNRC1WaTogTm8gaW9tbXUgZm9yIGRl
dmljZSAwMDAwOjAwOjE4LjINCihYRU4pIFsyMDEyLTA5LTA1IDE1OjQ5OjEwXSBBTUQtVmk6
IE5vIGlvbW11IGZvciBkZXZpY2UgMDAwMDowMDoxOC4zDQooWEVOKSBbMjAxMi0wOS0wNSAx
NTo0OToxMF0gQU1ELVZpOiBObyBpb21tdSBmb3IgZGV2aWNlIDAwMDA6MDA6MTguNA0KKFhF
TikgWzIwMTItMDktMDUgMTU6NDk6MTBdIEFNRC1WaTogU2V0dXAgSS9PIHBhZ2UgdGFibGU6
IGRldmljZSBpZCA9IDB4MDQwMCwgcm9vdCB0YWJsZSA9IDB4MjRkODRiMDAwLCBkb21haW4g
PSAwLCBwYWdpbmcgbW9kZSA9IDMNCihYRU4pIFsyMDEyLTA5LTA1IDE1OjQ5OjEwXSBBTUQt
Vmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweDA0MDEsIHJvb3QgdGFi
bGUgPSAweDI0ZDg0YjAwMCwgZG9tYWluID0gMCwgcGFnaW5nIG1vZGUgPSAzDQooWEVOKSBb
MjAxMi0wOS0wNSAxNTo0OToxMF0gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2
aWNlIGlkID0gMHgwNDAyLCByb290IHRhYmxlID0gMHgyNGQ4NGIwMDAsIGRvbWFpbiA9IDAs
IHBhZ2luZyBtb2RlID0gMw0KKFhFTikgWzIwMTItMDktMDUgMTU6NDk6MTBdIEFNRC1WaTog
U2V0dXAgSS9PIHBhZ2UgdGFibGU6IGRldmljZSBpZCA9IDB4MDQwMywgcm9vdCB0YWJsZSA9
IDB4MjRkODRiMDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMNCihYRU4pIFsyMDEy
LTA5LTA1IDE1OjQ5OjEwXSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2Ug
aWQgPSAweDA0MDQsIHJvb3QgdGFibGUgPSAweDI0ZDg0YjAwMCwgZG9tYWluID0gMCwgcGFn
aW5nIG1vZGUgPSAzDQooWEVOKSBbMjAxMi0wOS0wNSAxNTo0OToxMF0gQU1ELVZpOiBTZXR1
cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHgwNDA1LCByb290IHRhYmxlID0gMHgy
NGQ4NGIwMDAsIGRvbWFpbiA9IDAsIHBhZ2luZyBtb2RlID0gMw0KKFhFTikgWzIwMTItMDkt
MDUgMTU6NDk6MTBdIEFNRC1WaTogU2V0dXAgSS9PIHBhZ2UgdGFibGU6IGRldmljZSBpZCA9
IDB4MDQwNiwgcm9vdCB0YWJsZSA9IDB4MjRkODRiMDAwLCBkb21haW4gPSAwLCBwYWdpbmcg
bW9kZSA9IDMNCihYRU4pIFsyMDEyLTA5LTA1IDE1OjQ5OjEwXSBBTUQtVmk6IFNldHVwIEkv
TyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweDA0MDcsIHJvb3QgdGFibGUgPSAweDI0ZDg0
YjAwMCwgZG9tYWluID0gMCwgcGFnaW5nIG1vZGUgPSAzDQooWEVOKSBbMjAxMi0wOS0wNSAx
NTo0OToxMF0gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHgw
NTAwLCByb290IHRhYmxlID0gMHgyNGQ4NGIwMDAsIGRvbWFpbiA9IDAsIHBhZ2luZyBtb2Rl
ID0gMw0KKFhFTikgWzIwMTItMDktMDUgMTU6NDk6MTBdIEFNRC1WaTogU2V0dXAgSS9PIHBh
Z2UgdGFibGU6IGRldmljZSBpZCA9IDB4MDYwMCwgcm9vdCB0YWJsZSA9IDB4MjRkODRiMDAw
LCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMNCihYRU4pIFsyMDEyLTA5LTA1IDE1OjQ5
OjEwXSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweDA2MDEs
IHJvb3QgdGFibGUgPSAweDI0ZDg0YjAwMCwgZG9tYWluID0gMCwgcGFnaW5nIG1vZGUgPSAz
DQooWEVOKSBbMjAxMi0wOS0wNSAxNTo0OToxMF0gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0
YWJsZTogZGV2aWNlIGlkID0gMHgwNzAwLCByb290IHRhYmxlID0gMHgyNGQ4NGIwMDAsIGRv
bWFpbiA9IDAsIHBhZ2luZyBtb2RlID0gMw0KKFhFTikgWzIwMTItMDktMDUgMTU6NDk6MTBd
IEFNRC1WaTogU2V0dXAgSS9PIHBhZ2UgdGFibGU6IGRldmljZSBpZCA9IDB4MDgwMCwgcm9v
dCB0YWJsZSA9IDB4MjRkODRiMDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMNCihY
RU4pIFsyMDEyLTA5LTA1IDE1OjQ5OjEwXSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxl
OiBkZXZpY2UgaWQgPSAweDA5MDAsIHJvb3QgdGFibGUgPSAweDI0ZDg0YjAwMCwgZG9tYWlu
ID0gMCwgcGFnaW5nIG1vZGUgPSAzDQooWEVOKSBbMjAxMi0wOS0wNSAxNTo0OToxMF0gQU1E
LVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHgwYTAwLCByb290IHRh
YmxlID0gMHgyNGQ4NGIwMDAsIGRvbWFpbiA9IDAsIHBhZ2luZyBtb2RlID0gMw0KKFhFTikg
WzIwMTItMDktMDUgMTU6NDk6MTBdIEFNRC1WaTogU2V0dXAgSS9PIHBhZ2UgdGFibGU6IGRl
dmljZSBpZCA9IDB4MGEwMSwgcm9vdCB0YWJsZSA9IDB4MjRkODRiMDAwLCBkb21haW4gPSAw
LCBwYWdpbmcgbW9kZSA9IDMNCihYRU4pIFsyMDEyLTA5LTA1IDE1OjQ5OjEwXSBBTUQtVmk6
IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweDBhMDIsIHJvb3QgdGFibGUg
PSAweDI0ZDg0YjAwMCwgZG9tYWluID0gMCwgcGFnaW5nIG1vZGUgPSAzDQooWEVOKSBbMjAx
Mi0wOS0wNSAxNTo0OToxMF0gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNl
IGlkID0gMHgwYTAzLCByb290IHRhYmxlID0gMHgyNGQ4NGIwMDAsIGRvbWFpbiA9IDAsIHBh
Z2luZyBtb2RlID0gMw0KKFhFTikgWzIwMTItMDktMDUgMTU6NDk6MTBdIEFNRC1WaTogU2V0
dXAgSS9PIHBhZ2UgdGFibGU6IGRldmljZSBpZCA9IDB4MGEwNCwgcm9vdCB0YWJsZSA9IDB4
MjRkODRiMDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMNCihYRU4pIFsyMDEyLTA5
LTA1IDE1OjQ5OjEwXSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQg
PSAweDBhMDUsIHJvb3QgdGFibGUgPSAweDI0ZDg0YjAwMCwgZG9tYWluID0gMCwgcGFnaW5n
IG1vZGUgPSAzDQooWEVOKSBbMjAxMi0wOS0wNSAxNTo0OToxMF0gQU1ELVZpOiBTZXR1cCBJ
L08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHgwYTA2LCByb290IHRhYmxlID0gMHgyNGQ4
NGIwMDAsIGRvbWFpbiA9IDAsIHBhZ2luZyBtb2RlID0gMw0KKFhFTikgWzIwMTItMDktMDUg
MTU6NDk6MTBdIEFNRC1WaTogU2V0dXAgSS9PIHBhZ2UgdGFibGU6IGRldmljZSBpZCA9IDB4
MGEwNywgcm9vdCB0YWJsZSA9IDB4MjRkODRiMDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9k
ZSA9IDMNCihYRU4pIFsyMDEyLTA5LTA1IDE1OjQ5OjEwXSBBTUQtVmk6IFNldHVwIEkvTyBw
YWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweDBiMDAsIHJvb3QgdGFibGUgPSAweDI0ZDg0YjAw
MCwgZG9tYWluID0gMCwgcGFnaW5nIG1vZGUgPSAzDQooWEVOKSBbMjAxMi0wOS0wNSAxNTo0
OToxMF0gU2NydWJiaW5nIEZyZWUgUkFNOiAuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi48
MD5BTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MGEw
NiwgZmF1bHQgYWRkcmVzcyA9IDB4YzJjMmMyYzAsIGZsYWdzID0gMHgwMDANCihYRU4pIFsy
MDEyLTA5LTA1IDE1OjQ5OjExXSAuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u
Li4uLi4uLi4uLmRvbmUuDQooWEVOKSBbMjAxMi0wOS0wNSAxNTo0OToxMl0gSW5pdGlhbCBs
b3cgbWVtb3J5IHZpcnEgdGhyZXNob2xkIHNldCBhdCAweDQwMDAgcGFnZXMuDQooWEVOKSBb
MjAxMi0wOS0wNSAxNTo0OToxMl0gU3RkLiBMb2dsZXZlbDogQWxsDQooWEVOKSBbMjAxMi0w
OS0wNSAxNTo0OToxMl0gR3Vlc3QgTG9nbGV2ZWw6IEFsbA0KKFhFTikgWzIwMTItMDktMDUg
MTU6NDk6MTJdIFhlbiBpcyByZWxpbnF1aXNoaW5nIFZHQSBjb25zb2xlLg0KKFhFTikgWzIw
MTItMDktMDUgMTU6NDk6MTJdICoqKiBTZXJpYWwgaW5wdXQgLT4gRE9NMCAodHlwZSAnQ1RS
TC1hJyB0aHJlZSB0aW1lcyB0byBzd2l0Y2ggaW5wdXQgdG8gWGVuKQ0KKFhFTikgWzIwMTIt
MDktMDUgMTU6NDk6MTJdIEZyZWVkIDI1NmtCIGluaXQgbWVtb3J5Lg0KKFhFTikgWzIwMTIt
MDktMDUgMTU6NDk6MTJdIElPQVBJQ1swXTogU2V0IFBDSSByb3V0aW5nIGVudHJ5ICg2LTkg
LT4gMHg2MCAtPiBJUlEgOSBNb2RlOjEgQWN0aXZlOjEpDQooWEVOKSBbMjAxMi0wOS0wNSAx
NTo0OToxMl0gdHJhcHMuYzoyNTg0OmQwIERvbWFpbiBhdHRlbXB0ZWQgV1JNU1IgMDAwMDAw
MDBjMDAwMDQwOCBmcm9tIDB4YzAwMDAwMDAwMTAwMDAwMCB0byAweGMwMDgwMDAwMDEwMDAw
MDAuDQooWEVOKSBbMjAxMi0wOS0wNSAxNTo0OToxMl0gdHJhcHMuYzoyNTg0OmQwIERvbWFp
biBhdHRlbXB0ZWQgV1JNU1IgMDAwMDAwMDBjMDAwMDQwOSBmcm9tIDB4YzAwMDAwMDAwMTAw
MDAwMCB0byAweGMwMDgwMDAwMDEwMDAwMDAuDQooWEVOKSBbMjAxMi0wOS0wNSAxNTo0OTox
Ml0gdHJhcHMuYzoyNTg0OmQwIERvbWFpbiBhdHRlbXB0ZWQgV1JNU1IgMDAwMDAwMDBjMDAx
MDAwNCBmcm9tIDB4MDAwMGVmZjBiZGZiMWZjZSB0byAweDAwMDAwMDAwMDAwMGFiY2QuDQoo
WEVOKSBbMjAxMi0wOS0wNSAxNTo0OToxMl0gdHJhcHMuYzoyNTg0OmQwIERvbWFpbiBhdHRl
bXB0ZWQgV1JNU1IgMDAwMDAwMDBjMDAwMDQwOCBmcm9tIDB4YzAwMDAwMDAwMTAwMDAwMCB0
byAweGMwMDgwMDAwMDEwMDAwMDAuDQooWEVOKSBbMjAxMi0wOS0wNSAxNTo0OToxMl0gdHJh
cHMuYzoyNTg0OmQwIERvbWFpbiBhdHRlbXB0ZWQgV1JNU1IgMDAwMDAwMDBjMDAwMDQwOSBm
cm9tIDB4YzAwMDAwMDAwMTAwMDAwMCB0byAweGMwMDgwMDAwMDEwMDAwMDAuDQooWEVOKSBb
MjAxMi0wOS0wNSAxNTo0OToxMl0gdHJhcHMuYzoyNTg0OmQwIERvbWFpbiBhdHRlbXB0ZWQg
V1JNU1IgMDAwMDAwMDBjMDAwMDQwOCBmcm9tIDB4YzAwMDAwMDAwMTAwMDAwMCB0byAweGMw
MDgwMDAwMDEwMDAwMDAuDQooWEVOKSBbMjAxMi0wOS0wNSAxNTo0OToxMl0gdHJhcHMuYzoy
NTg0OmQwIERvbWFpbiBhdHRlbXB0ZWQgV1JNU1IgMDAwMDAwMDBjMDAwMDQwOSBmcm9tIDB4
YzAwMDAwMDAwMTAwMDAwMCB0byAweGMwMDgwMDAwMDEwMDAwMDAuDQooWEVOKSBbMjAxMi0w
OS0wNSAxNTo0OToxM10gdHJhcHMuYzoyNTg0OmQwIERvbWFpbiBhdHRlbXB0ZWQgV1JNU1Ig
MDAwMDAwMDBjMDAwMDQwOCBmcm9tIDB4YzAwMDAwMDAwMTAwMDAwMCB0byAweGMwMDgwMDAw
MDEwMDAwMDAuDQooWEVOKSBbMjAxMi0wOS0wNSAxNTo0OToxM10gdHJhcHMuYzoyNTg0OmQw
IERvbWFpbiBhdHRlbXB0ZWQgV1JNU1IgMDAwMDAwMDBjMDAwMDQwOSBmcm9tIDB4YzAwMDAw
MDAwMTAwMDAwMCB0byAweGMwMDgwMDAwMDEwMDAwMDAuDQooWEVOKSBbMjAxMi0wOS0wNSAx
NTo0OToxM10gdHJhcHMuYzoyNTg0OmQwIERvbWFpbiBhdHRlbXB0ZWQgV1JNU1IgMDAwMDAw
MDBjMDAwMDQwOCBmcm9tIDB4YzAwMDAwMDAwMTAwMDAwMCB0byAweGMwMDgwMDAwMDEwMDAw
MDAuDQooWEVOKSBbMjAxMi0wOS0wNSAxNTo0OToxM10gdHJhcHMuYzoyNTg0OmQwIERvbWFp
biBhdHRlbXB0ZWQgV1JNU1IgMDAwMDAwMDBjMDAwMDQwOSBmcm9tIDB4YzAwMDAwMDAwMTAw
MDAwMCB0byAweGMwMDgwMDAwMDEwMDAwMDAuDQooWEVOKSBbMjAxMi0wOS0wNSAxNTo0OTox
M10gdHJhcHMuYzoyNTg0OmQwIERvbWFpbiBhdHRlbXB0ZWQgV1JNU1IgMDAwMDAwMDBjMDAw
MDQwOCBmcm9tIDB4YzAwMDAwMDAwMTAwMDAwMCB0byAweGMwMDgwMDAwMDEwMDAwMDAuDQoo
WEVOKSBbMjAxMi0wOS0wNSAxNTo0OToxM10gdHJhcHMuYzoyNTg0OmQwIERvbWFpbiBhdHRl
bXB0ZWQgV1JNU1IgMDAwMDAwMDBjMDAwMDQwOSBmcm9tIDB4YzAwMDAwMDAwMTAwMDAwMCB0
byAweGMwMDgwMDAwMDEwMDAwMDAuDQooWEVOKSBbMjAxMi0wOS0wNSAxNTo0OToxM10gUENJ
IGFkZCBkZXZpY2UgMDAwMDowMDowMC4wDQooWEVOKSBbMjAxMi0wOS0wNSAxNTo0OToxM10g
UENJIGFkZCBkZXZpY2UgMDAwMDowMDowMC4yDQooWEVOKSBbMjAxMi0wOS0wNSAxNTo0OTox
M10gUENJIGFkZCBkZXZpY2UgMDAwMDowMDowMi4wDQooWEVOKSBbMjAxMi0wOS0wNSAxNTo0
OToxM10gUENJIGFkZCBkZXZpY2UgMDAwMDowMDowMy4wDQooWEVOKSBbMjAxMi0wOS0wNSAx
NTo0OToxM10gUENJIGFkZCBkZXZpY2UgMDAwMDowMDowNS4wDQooWEVOKSBbMjAxMi0wOS0w
NSAxNTo0OToxM10gUENJIGFkZCBkZXZpY2UgMDAwMDowMDowNi4wDQooWEVOKSBbMjAxMi0w
OS0wNSAxNTo0OToxM10gUENJIGFkZCBkZXZpY2UgMDAwMDowMDowYS4wDQooWEVOKSBbMjAx
Mi0wOS0wNSAxNTo0OToxM10gUENJIGFkZCBkZXZpY2UgMDAwMDowMDowYi4wDQooWEVOKSBb
MjAxMi0wOS0wNSAxNTo0OToxM10gUENJIGFkZCBkZXZpY2UgMDAwMDowMDowYy4wDQooWEVO
KSBbMjAxMi0wOS0wNSAxNTo0OToxM10gUENJIGFkZCBkZXZpY2UgMDAwMDowMDowZC4wDQoo
WEVOKSBbMjAxMi0wOS0wNSAxNTo0OToxM10gUENJIGFkZCBkZXZpY2UgMDAwMDowMDoxMS4w
DQooWEVOKSBbMjAxMi0wOS0wNSAxNTo0OToxM10gUENJIGFkZCBkZXZpY2UgMDAwMDowMDox
Mi4wDQooWEVOKSBbMjAxMi0wOS0wNSAxNTo0OToxM10gUENJIGFkZCBkZXZpY2UgMDAwMDow
MDoxMi4yDQooWEVOKSBbMjAxMi0wOS0wNSAxNTo0OToxM10gUENJIGFkZCBkZXZpY2UgMDAw
MDowMDoxMy4wDQooWEVOKSBbMjAxMi0wOS0wNSAxNTo0OToxM10gUENJIGFkZCBkZXZpY2Ug
MDAwMDowMDoxMy4yDQooWEVOKSBbMjAxMi0wOS0wNSAxNTo0OToxM10gUENJIGFkZCBkZXZp
Y2UgMDAwMDowMDoxNC4wDQooWEVOKSBbMjAxMi0wOS0wNSAxNTo0OToxM10gUENJIGFkZCBk
ZXZpY2UgMDAwMDowMDoxNC4zDQooWEVOKSBbMjAxMi0wOS0wNSAxNTo0OToxM10gUENJIGFk
ZCBkZXZpY2UgMDAwMDowMDoxNC40DQooWEVOKSBbMjAxMi0wOS0wNSAxNTo0OToxM10gUENJ
IGFkZCBkZXZpY2UgMDAwMDowMDoxNC41DQooWEVOKSBbMjAxMi0wOS0wNSAxNTo0OToxM10g
UENJIGFkZCBkZXZpY2UgMDAwMDowMDoxNS4wDQooWEVOKSBbMjAxMi0wOS0wNSAxNTo0OTox
M10gUENJIGFkZCBkZXZpY2UgMDAwMDowMDoxNi4wDQooWEVOKSBbMjAxMi0wOS0wNSAxNTo0
OToxM10gUENJIGFkZCBkZXZpY2UgMDAwMDowMDoxNi4yDQooWEVOKSBbMjAxMi0wOS0wNSAx
NTo0OToxM10gUENJIGFkZCBkZXZpY2UgMDAwMDowMDoxOC4wDQooWEVOKSBbMjAxMi0wOS0w
NSAxNTo0OToxM10gUENJIGFkZCBkZXZpY2UgMDAwMDowMDoxOC4xDQooWEVOKSBbMjAxMi0w
OS0wNSAxNTo0OToxM10gUENJIGFkZCBkZXZpY2UgMDAwMDowMDoxOC4yDQooWEVOKSBbMjAx
Mi0wOS0wNSAxNTo0OToxM10gUENJIGFkZCBkZXZpY2UgMDAwMDowMDoxOC4zDQooWEVOKSBb
MjAxMi0wOS0wNSAxNTo0OToxM10gUENJIGFkZCBkZXZpY2UgMDAwMDowMDoxOC40DQooWEVO
KSBbMjAxMi0wOS0wNSAxNTo0OToxM10gUENJIGFkZCBkZXZpY2UgMDAwMDowYjowMC4wDQoo
WEVOKSBbMjAxMi0wOS0wNSAxNTo0OToxM10gUENJIGFkZCBkZXZpY2UgMDAwMDowYTowMC4w
DQooWEVOKSBbMjAxMi0wOS0wNSAxNTo0OToxM10gUENJIGFkZCBkZXZpY2UgMDAwMDowYTow
MC4xDQooWEVOKSBbMjAxMi0wOS0wNSAxNTo0OToxM10gUENJIGFkZCBkZXZpY2UgMDAwMDow
YTowMC4yDQooWEVOKSBbMjAxMi0wOS0wNSAxNTo0OToxM10gUENJIGFkZCBkZXZpY2UgMDAw
MDowYTowMC4zDQooWEVOKSBbMjAxMi0wOS0wNSAxNTo0OToxM10gUENJIGFkZCBkZXZpY2Ug
MDAwMDowYTowMC40DQooWEVOKSBbMjAxMi0wOS0wNSAxNTo0OToxM10gUENJIGFkZCBkZXZp
Y2UgMDAwMDowYTowMC41DQooWEVOKSBbMjAxMi0wOS0wNSAxNTo0OToxM10gUENJIGFkZCBk
ZXZpY2UgMDAwMDowYTowMC42DQooWEVOKSBbMjAxMi0wOS0wNSAxNTo0OToxM10gUENJIGFk
ZCBkZXZpY2UgMDAwMDowYTowMC43DQooWEVOKSBbMjAxMi0wOS0wNSAxNTo0OToxM10gUENJ
IGFkZCBkZXZpY2UgMDAwMDowOTowMC4wDQooWEVOKSBbMjAxMi0wOS0wNSAxNTo0OToxM10g
UENJIGFkZCBkZXZpY2UgMDAwMDowODowMC4wDQooWEVOKSBbMjAxMi0wOS0wNSAxNTo0OTox
M10gUENJIGFkZCBkZXZpY2UgMDAwMDowNzowMC4wDQooWEVOKSBbMjAxMi0wOS0wNSAxNTo0
OToxM10gUENJIGFkZCBkZXZpY2UgMDAwMDowNjowMC4wDQooWEVOKSBbMjAxMi0wOS0wNSAx
NTo0OToxM10gUENJIGFkZCBkZXZpY2UgMDAwMDowNjowMC4xDQooWEVOKSBbMjAxMi0wOS0w
NSAxNTo0OToxM10gUENJIGFkZCBkZXZpY2UgMDAwMDowNTowMC4wDQooWEVOKSBbMjAxMi0w
OS0wNSAxNTo0OToxM10gUENJIGFkZCBkZXZpY2UgMDAwMDowNDowMC4wDQooWEVOKSBbMjAx
Mi0wOS0wNSAxNTo0OToxM10gUENJIGFkZCBkZXZpY2UgMDAwMDowNDowMC4xDQooWEVOKSBb
MjAxMi0wOS0wNSAxNTo0OToxM10gUENJIGFkZCBkZXZpY2UgMDAwMDowNDowMC4yDQooWEVO
KSBbMjAxMi0wOS0wNSAxNTo0OToxM10gUENJIGFkZCBkZXZpY2UgMDAwMDowNDowMC4zDQoo
WEVOKSBbMjAxMi0wOS0wNSAxNTo0OToxM10gUENJIGFkZCBkZXZpY2UgMDAwMDowNDowMC40
DQooWEVOKSBbMjAxMi0wOS0wNSAxNTo0OToxM10gUENJIGFkZCBkZXZpY2UgMDAwMDowNDow
MC41DQooWEVOKSBbMjAxMi0wOS0wNSAxNTo0OToxM10gUENJIGFkZCBkZXZpY2UgMDAwMDow
NDowMC42DQooWEVOKSBbMjAxMi0wOS0wNSAxNTo0OToxM10gUENJIGFkZCBkZXZpY2UgMDAw
MDowNDowMC43DQooWEVOKSBbMjAxMi0wOS0wNSAxNTo0OToxM10gUENJIGFkZCBkZXZpY2Ug
MDAwMDowMzowNi4wDQooWEVOKSBbMjAxMi0wOS0wNSAxNTo0OToxM10gSU9BUElDWzBdOiBT
ZXQgUENJIHJvdXRpbmcgZW50cnkgKDYtOCAtPiAweDU4IC0+IElSUSA4IE1vZGU6MCBBY3Rp
dmU6MCkNCihYRU4pIFsyMDEyLTA5LTA1IDE1OjQ5OjEzXSBJT0FQSUNbMF06IFNldCBQQ0kg
cm91dGluZyBlbnRyeSAoNi0xMyAtPiAweDg4IC0+IElSUSAxMyBNb2RlOjAgQWN0aXZlOjAp
DQooWEVOKSBbMjAxMi0wOS0wNSAxNTo0OToxM10gSU9BUElDWzFdOiBTZXQgUENJIHJvdXRp
bmcgZW50cnkgKDctMjggLT4gMHhhMCAtPiBJUlEgNTIgTW9kZToxIEFjdGl2ZToxKQ0KKFhF
TikgWzIwMTItMDktMDUgMTU6NDk6MTNdIElPQVBJQ1sxXTogU2V0IFBDSSByb3V0aW5nIGVu
dHJ5ICg3LTI5IC0+IDB4YTggLT4gSVJRIDUzIE1vZGU6MSBBY3RpdmU6MSkNCihYRU4pIFsy
MDEyLTA5LTA1IDE1OjQ5OjEzXSBJT0FQSUNbMV06IFNldCBQQ0kgcm91dGluZyBlbnRyeSAo
Ny0zMCAtPiAweGIwIC0+IElSUSA1NCBNb2RlOjEgQWN0aXZlOjEpDQooWEVOKSBbMjAxMi0w
OS0wNSAxNTo0OToxM10gSU9BUElDWzBdOiBTZXQgUENJIHJvdXRpbmcgZW50cnkgKDYtMTYg
LT4gMHhiOCAtPiBJUlEgMTYgTW9kZToxIEFjdGl2ZToxKQ0KKFhFTikgWzIwMTItMDktMDUg
MTU6NDk6MTNdIElPQVBJQ1swXTogU2V0IFBDSSByb3V0aW5nIGVudHJ5ICg2LTE4IC0+IDB4
YzAgLT4gSVJRIDE4IE1vZGU6MSBBY3RpdmU6MSkNCihYRU4pIFsyMDEyLTA5LTA1IDE1OjQ5
OjEzXSBJT0FQSUNbMF06IFNldCBQQ0kgcm91dGluZyBlbnRyeSAoNi0xNyAtPiAweGM4IC0+
IElSUSAxNyBNb2RlOjEgQWN0aXZlOjEpDQooWEVOKSBbMjAxMi0wOS0wNSAxNTo0OToxM10g
SU9BUElDWzFdOiBTZXQgUENJIHJvdXRpbmcgZW50cnkgKDctNCAtPiAweGQwIC0+IElSUSAy
OCBNb2RlOjEgQWN0aXZlOjEpDQooWEVOKSBbMjAxMi0wOS0wNSAxNTo0OToxM10gSU9BUElD
WzFdOiBTZXQgUENJIHJvdXRpbmcgZW50cnkgKDctNSAtPiAweGQ4IC0+IElSUSAyOSBNb2Rl
OjEgQWN0aXZlOjEpDQooWEVOKSBbMjAxMi0wOS0wNSAxNTo0OToxM10gSU9BUElDWzFdOiBT
ZXQgUENJIHJvdXRpbmcgZW50cnkgKDctNiAtPiAweDIxIC0+IElSUSAzMCBNb2RlOjEgQWN0
aXZlOjEpDQooWEVOKSBbMjAxMi0wOS0wNSAxNTo0OToxM10gSU9BUElDWzFdOiBTZXQgUENJ
IHJvdXRpbmcgZW50cnkgKDctNyAtPiAweDI5IC0+IElSUSAzMSBNb2RlOjEgQWN0aXZlOjEp
DQooWEVOKSBbMjAxMi0wOS0wNSAxNTo0OToxM10gSU9BUElDWzFdOiBTZXQgUENJIHJvdXRp
bmcgZW50cnkgKDctMTYgLT4gMHgzMSAtPiBJUlEgNDAgTW9kZToxIEFjdGl2ZToxKQ0KKFhF
TikgWzIwMTItMDktMDUgMTU6NDk6MTNdIElPQVBJQ1sxXTogU2V0IFBDSSByb3V0aW5nIGVu
dHJ5ICg3LTE3IC0+IDB4MzkgLT4gSVJRIDQxIE1vZGU6MSBBY3RpdmU6MSkNCihYRU4pIFsy
MDEyLTA5LTA1IDE1OjQ5OjEzXSBJT0FQSUNbMV06IFNldCBQQ0kgcm91dGluZyBlbnRyeSAo
Ny0xOCAtPiAweDQxIC0+IElSUSA0MiBNb2RlOjEgQWN0aXZlOjEpDQooWEVOKSBbMjAxMi0w
OS0wNSAxNTo0OToxM10gSU9BUElDWzFdOiBTZXQgUENJIHJvdXRpbmcgZW50cnkgKDctMTkg
LT4gMHg0OSAtPiBJUlEgNDMgTW9kZToxIEFjdGl2ZToxKQ0KKFhFTikgWzIwMTItMDktMDUg
MTU6NDk6MTRdIElPQVBJQ1swXTogU2V0IFBDSSByb3V0aW5nIGVudHJ5ICg2LTIyIC0+IDB4
OTkgLT4gSVJRIDIyIE1vZGU6MSBBY3RpdmU6MSkNCihYRU4pIFsyMDEyLTA5LTA1IDE1OjQ5
OjE0XSBJT0FQSUNbMV06IFNldCBQQ0kgcm91dGluZyBlbnRyeSAoNy0xMiAtPiAweGExIC0+
IElSUSAzNiBNb2RlOjEgQWN0aXZlOjEpDQooWEVOKSBbMjAxMi0wOS0wNSAxNTo0OToxNF0g
SU9BUElDWzFdOiBTZXQgUENJIHJvdXRpbmcgZW50cnkgKDctMjMgLT4gMHhhOSAtPiBJUlEg
NDcgTW9kZToxIEFjdGl2ZToxKQ0KKFhFTikgWzIwMTItMDktMDUgMTU6NDk6MTRdIElPQVBJ
Q1swXTogU2V0IFBDSSByb3V0aW5nIGVudHJ5ICg2LTE5IC0+IDB4YjEgLT4gSVJRIDE5IE1v
ZGU6MSBBY3RpdmU6MSkNCihYRU4pIFsyMDEyLTA5LTA1IDE1OjQ5OjE0XSBJT0FQSUNbMV06
IFNldCBQQ0kgcm91dGluZyBlbnRyeSAoNy0yMiAtPiAweGMxIC0+IElSUSA0NiBNb2RlOjEg
QWN0aXZlOjEpDQooWEVOKSBbMjAxMi0wOS0wNSAxNTo0OToxNF0gSU9BUElDWzFdOiBTZXQg
UENJIHJvdXRpbmcgZW50cnkgKDctMjcgLT4gMHhkMSAtPiBJUlEgNTEgTW9kZToxIEFjdGl2
ZToxKQ0KKFhFTikgWzIwMTItMDktMDUgMTU6NDk6MTZdIElPQVBJQ1sxXTogU2V0IFBDSSBy
b3V0aW5nIGVudHJ5ICg3LTkgLT4gMHgyMiAtPiBJUlEgMzMgTW9kZToxIEFjdGl2ZToxKQ0K
KFhFTikgWzIwMTItMDktMDUgMTU6NTA6MTldIHRyYXBzLmM6MjU4NDpkMSBEb21haW4gYXR0
ZW1wdGVkIFdSTVNSIDAwMDAwMDAwYzAwMTAwMDQgZnJvbSAweDAwMDA2ZmIwMzlkZTc5MDAg
dG8gMHgwMDAwMDAwMDAwMDBhYmNkLg0KKFhFTikgWzIwMTItMDktMDUgMTU6NTA6MjVdIHRy
YXBzLmM6MjU4NDpkMiBEb21haW4gYXR0ZW1wdGVkIFdSTVNSIDAwMDAwMDAwYzAwMTAwMDQg
ZnJvbSAweDAwMDA0MjM0NWEwZGE1NDUgdG8gMHgwMDAwMDAwMDAwMDBhYmNkLg0KKFhFTikg
WzIwMTItMDktMDUgMTU6NTA6MzddIHRyYXBzLmM6MjU4NDpkMyBEb21haW4gYXR0ZW1wdGVk
IFdSTVNSIDAwMDAwMDAwYzAwMTAwMDQgZnJvbSAweDAwMDA2ZmIwMzlkZTc5MDAgdG8gMHgw
MDAwMDAwMDAwMDBhYmNkLg0KKFhFTikgWzIwMTItMDktMDUgMTU6NTA6MzddIHRyYXBzLmM6
MjU4NDpkNCBEb21haW4gYXR0ZW1wdGVkIFdSTVNSIDAwMDAwMDAwYzAwMTAwMDQgZnJvbSAw
eDAwMDA2ZmIwMzlkZTc5MDAgdG8gMHgwMDAwMDAwMDAwMDBhYmNkLg0KKFhFTikgWzIwMTIt
MDktMDUgMTU6NTA6NDNdIHRyYXBzLmM6MjU4NDpkNSBEb21haW4gYXR0ZW1wdGVkIFdSTVNS
IDAwMDAwMDAwYzAwMTAwMDQgZnJvbSAweDAwMDA0MjM0NWEwZGE1NDUgdG8gMHgwMDAwMDAw
MDAwMDBhYmNkLg0KKFhFTikgWzIwMTItMDktMDUgMTU6NTA6NDldIHRyYXBzLmM6MjU4NDpk
NiBEb21haW4gYXR0ZW1wdGVkIFdSTVNSIDAwMDAwMDAwYzAwMTAwMDQgZnJvbSAweDAwMDA0
MjM0NWEwZGE1NDUgdG8gMHgwMDAwMDAwMDAwMDBhYmNkLg0KKFhFTikgWzIwMTItMDktMDUg
MTU6NTA6NTVdIHRyYXBzLmM6MjU4NDpkNyBEb21haW4gYXR0ZW1wdGVkIFdSTVNSIDAwMDAw
MDAwYzAwMTAwMDQgZnJvbSAweDAwMDBhMTk1YzQwZjYxOGYgdG8gMHgwMDAwMDAwMDAwMDBh
YmNkLg0KKFhFTikgWzIwMTItMDktMDUgMTU6NTE6MDFdIHRyYXBzLmM6MjU4NDpkOCBEb21h
aW4gYXR0ZW1wdGVkIFdSTVNSIDAwMDAwMDAwYzAwMTAwMDQgZnJvbSAweDAwMDA4Njc5YzAy
YjQxNjUgdG8gMHgwMDAwMDAwMDAwMDBhYmNkLg0KKFhFTikgWzIwMTItMDktMDUgMTU6NTE6
MDddIHRyYXBzLmM6MjU4NDpkOSBEb21haW4gYXR0ZW1wdGVkIFdSTVNSIDAwMDAwMDAwYzAw
MTAwMDQgZnJvbSAweDAwMDBhMTk1YzQwZjYxOGYgdG8gMHgwMDAwMDAwMDAwMDBhYmNkLg0K
KFhFTikgWzIwMTItMDktMDUgMTU6NTE6MTNdIHRyYXBzLmM6MjU4NDpkMTAgRG9tYWluIGF0
dGVtcHRlZCBXUk1TUiAwMDAwMDAwMGMwMDEwMDA0IGZyb20gMHgwMDAwYTE5NWM0MGY2MThm
IHRvIDB4MDAwMDAwMDAwMDAwYWJjZC4NCihYRU4pIFsyMDEyLTA5LTA1IDE1OjUxOjIyXSBB
TUQtVmk6IERpc2FibGU6IGRldmljZSBpZCA9IDB4MDBhNCwgZG9tYWluID0gMCwgcGFnaW5n
IG1vZGUgPSAzDQooWEVOKSBbMjAxMi0wOS0wNSAxNTo1MToyMl0gQU1ELVZpOiBTZXR1cCBJ
L08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHgwMGE0LCByb290IHRhYmxlID0gMHgxOGUw
YTEwMDAsIGRvbWFpbiA9IDExLCBwYWdpbmcgbW9kZSA9IDMNCihYRU4pIFsyMDEyLTA5LTA1
IDE1OjUxOjIyXSBBTUQtVmk6IFJlLWFzc2lnbiAwMDAwOjAzOjA2LjAgZnJvbSBkb20wIHRv
IGRvbTExDQooWEVOKSBbMjAxMi0wOS0wNSAxNTo1MToyMl0gdHJhcHMuYzoyNTg0OmQxMSBE
b21haW4gYXR0ZW1wdGVkIFdSTVNSIDAwMDAwMDAwYzAwMTAwMDQgZnJvbSAweDAwMDBhMTk1
YzQwZjYxOGYgdG8gMHgwMDAwMDAwMDAwMDBhYmNkLg0KKFhFTikgWzIwMTItMDktMDUgMTU6
NTE6MjhdIHRyYXBzLmM6MjU4NDpkMTIgRG9tYWluIGF0dGVtcHRlZCBXUk1TUiAwMDAwMDAw
MGMwMDEwMDA0IGZyb20gMHgwMDAwYTE5NWM0MGY2MThmIHRvIDB4MDAwMDAwMDAwMDAwYWJj
ZC4NCihYRU4pIFsyMDEyLTA5LTA1IDE1OjUxOjM1XSB0cmFwcy5jOjI1ODQ6ZDEzIERvbWFp
biBhdHRlbXB0ZWQgV1JNU1IgMDAwMDAwMDBjMDAxMDAwNCBmcm9tIDB4MDAwMDQyMzQ1YTBk
YTU0NSB0byAweDAwMDAwMDAwMDAwMGFiY2QuDQooWEVOKSBbMjAxMi0wOS0wNSAxNTo1MTo0
MV0gQU1ELVZpOiBEaXNhYmxlOiBkZXZpY2UgaWQgPSAweDBhMDAsIGRvbWFpbiA9IDAsIHBh
Z2luZyBtb2RlID0gMw0KKFhFTikgWzIwMTItMDktMDUgMTU6NTE6NDFdIEFNRC1WaTogU2V0
dXAgSS9PIHBhZ2UgdGFibGU6IGRldmljZSBpZCA9IDB4MGEwMCwgcm9vdCB0YWJsZSA9IDB4
MWUxZmMwMDAwLCBkb21haW4gPSAxNCwgcGFnaW5nIG1vZGUgPSAzDQooWEVOKSBbMjAxMi0w
OS0wNSAxNTo1MTo0MV0gQU1ELVZpOiBSZS1hc3NpZ24gMDAwMDowYTowMC4wIGZyb20gZG9t
MCB0byBkb20xNA0KKFhFTikgWzIwMTItMDktMDUgMTU6NTE6NDFdIEFNRC1WaTogRGlzYWJs
ZTogZGV2aWNlIGlkID0gMHgwYTAxLCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMNCihY
RU4pIFsyMDEyLTA5LTA1IDE1OjUxOjQxXSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxl
OiBkZXZpY2UgaWQgPSAweDBhMDEsIHJvb3QgdGFibGUgPSAweDFlMWZjMDAwMCwgZG9tYWlu
ID0gMTQsIHBhZ2luZyBtb2RlID0gMw0KKFhFTikgWzIwMTItMDktMDUgMTU6NTE6NDFdIEFN
RC1WaTogUmUtYXNzaWduIDAwMDA6MGE6MDAuMSBmcm9tIGRvbTAgdG8gZG9tMTQNCihYRU4p
IFsyMDEyLTA5LTA1IDE1OjUxOjQxXSBBTUQtVmk6IERpc2FibGU6IGRldmljZSBpZCA9IDB4
MGEwMiwgZG9tYWluID0gMCwgcGFnaW5nIG1vZGUgPSAzDQooWEVOKSBbMjAxMi0wOS0wNSAx
NTo1MTo0MV0gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHgw
YTAyLCByb290IHRhYmxlID0gMHgxZTFmYzAwMDAsIGRvbWFpbiA9IDE0LCBwYWdpbmcgbW9k
ZSA9IDMNCihYRU4pIFsyMDEyLTA5LTA1IDE1OjUxOjQxXSBBTUQtVmk6IFJlLWFzc2lnbiAw
MDAwOjBhOjAwLjIgZnJvbSBkb20wIHRvIGRvbTE0DQooWEVOKSBbMjAxMi0wOS0wNSAxNTo1
MTo0MV0gQU1ELVZpOiBEaXNhYmxlOiBkZXZpY2UgaWQgPSAweDBhMDMsIGRvbWFpbiA9IDAs
IHBhZ2luZyBtb2RlID0gMw0KKFhFTikgWzIwMTItMDktMDUgMTU6NTE6NDFdIEFNRC1WaTog
U2V0dXAgSS9PIHBhZ2UgdGFibGU6IGRldmljZSBpZCA9IDB4MGEwMywgcm9vdCB0YWJsZSA9
IDB4MWUxZmMwMDAwLCBkb21haW4gPSAxNCwgcGFnaW5nIG1vZGUgPSAzDQooWEVOKSBbMjAx
Mi0wOS0wNSAxNTo1MTo0MV0gQU1ELVZpOiBSZS1hc3NpZ24gMDAwMDowYTowMC4zIGZyb20g
ZG9tMCB0byBkb20xNA0KKFhFTikgWzIwMTItMDktMDUgMTU6NTE6NDFdIEFNRC1WaTogRGlz
YWJsZTogZGV2aWNlIGlkID0gMHgwYTA0LCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMN
CihYRU4pIFsyMDEyLTA5LTA1IDE1OjUxOjQxXSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRh
YmxlOiBkZXZpY2UgaWQgPSAweDBhMDQsIHJvb3QgdGFibGUgPSAweDFlMWZjMDAwMCwgZG9t
YWluID0gMTQsIHBhZ2luZyBtb2RlID0gMw0KKFhFTikgWzIwMTItMDktMDUgMTU6NTE6NDFd
IEFNRC1WaTogUmUtYXNzaWduIDAwMDA6MGE6MDAuNCBmcm9tIGRvbTAgdG8gZG9tMTQNCihY
RU4pIFsyMDEyLTA5LTA1IDE1OjUxOjQxXSBBTUQtVmk6IERpc2FibGU6IGRldmljZSBpZCA9
IDB4MGEwNSwgZG9tYWluID0gMCwgcGFnaW5nIG1vZGUgPSAzDQooWEVOKSBbMjAxMi0wOS0w
NSAxNTo1MTo0MV0gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0g
MHgwYTA1LCByb290IHRhYmxlID0gMHgxZTFmYzAwMDAsIGRvbWFpbiA9IDE0LCBwYWdpbmcg
bW9kZSA9IDMNCihYRU4pIFsyMDEyLTA5LTA1IDE1OjUxOjQxXSBBTUQtVmk6IFJlLWFzc2ln
biAwMDAwOjBhOjAwLjUgZnJvbSBkb20wIHRvIGRvbTE0DQooWEVOKSBbMjAxMi0wOS0wNSAx
NTo1MTo0MV0gQU1ELVZpOiBEaXNhYmxlOiBkZXZpY2UgaWQgPSAweDBhMDYsIGRvbWFpbiA9
IDAsIHBhZ2luZyBtb2RlID0gMw0KKFhFTikgWzIwMTItMDktMDUgMTU6NTE6NDFdIEFNRC1W
aTogU2V0dXAgSS9PIHBhZ2UgdGFibGU6IGRldmljZSBpZCA9IDB4MGEwNiwgcm9vdCB0YWJs
ZSA9IDB4MWUxZmMwMDAwLCBkb21haW4gPSAxNCwgcGFnaW5nIG1vZGUgPSAzDQooWEVOKSBb
MjAxMi0wOS0wNSAxNTo1MTo0MV0gQU1ELVZpOiBSZS1hc3NpZ24gMDAwMDowYTowMC42IGZy
b20gZG9tMCB0byBkb20xNA0KKFhFTikgWzIwMTItMDktMDUgMTU6NTE6NDFdIEFNRC1WaTog
RGlzYWJsZTogZGV2aWNlIGlkID0gMHgwYTA3LCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9
IDMNCihYRU4pIFsyMDEyLTA5LTA1IDE1OjUxOjQxXSBBTUQtVmk6IFNldHVwIEkvTyBwYWdl
IHRhYmxlOiBkZXZpY2UgaWQgPSAweDBhMDcsIHJvb3QgdGFibGUgPSAweDFlMWZjMDAwMCwg
ZG9tYWluID0gMTQsIHBhZ2luZyBtb2RlID0gMw0KKFhFTikgWzIwMTItMDktMDUgMTU6NTE6
NDFdIEFNRC1WaTogUmUtYXNzaWduIDAwMDA6MGE6MDAuNyBmcm9tIGRvbTAgdG8gZG9tMTQN
CihYRU4pIFsyMDEyLTA5LTA1IDE1OjUxOjQxXSBBTUQtVmk6IERpc2FibGU6IGRldmljZSBp
ZCA9IDB4MDcwMCwgZG9tYWluID0gMCwgcGFnaW5nIG1vZGUgPSAzDQooWEVOKSBbMjAxMi0w
OS0wNSAxNTo1MTo0MV0gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlk
ID0gMHgwNzAwLCByb290IHRhYmxlID0gMHgxZTFmYzAwMDAsIGRvbWFpbiA9IDE0LCBwYWdp
bmcgbW9kZSA9IDMNCihYRU4pIFsyMDEyLTA5LTA1IDE1OjUxOjQxXSBBTUQtVmk6IFJlLWFz
c2lnbiAwMDAwOjA3OjAwLjAgZnJvbSBkb20wIHRvIGRvbTE0DQooWEVOKSBbMjAxMi0wOS0w
NSAxNTo1MTo0MV0gdHJhcHMuYzoyNTg0OmQxNCBEb21haW4gYXR0ZW1wdGVkIFdSTVNSIDAw
MDAwMDAwYzAwMTAwMDQgZnJvbSAweDAwMDA0MjM0NWEwZGE1NDUgdG8gMHgwMDAwMDAwMDAw
MDBhYmNkLg0KKFhFTikgWzIwMTItMDktMDUgMTU6NTE6NTZdIEhWTTE1OiBIVk0gTG9hZGVy
DQooWEVOKSBbMjAxMi0wOS0wNSAxNTo1MTo1Nl0gSFZNMTU6IERldGVjdGVkIFhlbiB2NC4y
LjAtcmM0LXByZQ0KKFhFTikgWzIwMTItMDktMDUgMTU6NTE6NTZdIEhWTTE1OiBYZW5idXMg
cmluZ3MgQDB4ZmVmZmMwMDAsIGV2ZW50IGNoYW5uZWwgNA0KKFhFTikgWzIwMTItMDktMDUg
MTU6NTE6NTZdIEhWTTE1OiBTeXN0ZW0gcmVxdWVzdGVkIFJPTUJJT1MNCihYRU4pIFsyMDEy
LTA5LTA1IDE1OjUxOjU2XSBIVk0xNTogQ1BVIHNwZWVkIGlzIDMyMDAgTUh6DQooWEVOKSBb
MjAxMi0wOS0wNSAxNTo1MTo1Nl0gaXJxLmM6MjcwOiBEb20xNSBQQ0kgbGluayAwIGNoYW5n
ZWQgMCAtPiA1DQooWEVOKSBbMjAxMi0wOS0wNSAxNTo1MTo1Nl0gSFZNMTU6IFBDSS1JU0Eg
bGluayAwIHJvdXRlZCB0byBJUlE1DQooWEVOKSBbMjAxMi0wOS0wNSAxNTo1MTo1Nl0gaXJx
LmM6MjcwOiBEb20xNSBQQ0kgbGluayAxIGNoYW5nZWQgMCAtPiAxMA0KKFhFTikgWzIwMTIt
MDktMDUgMTU6NTE6NTZdIEhWTTE1OiBQQ0ktSVNBIGxpbmsgMSByb3V0ZWQgdG8gSVJRMTAN
CihYRU4pIFsyMDEyLTA5LTA1IDE1OjUxOjU2XSBpcnEuYzoyNzA6IERvbTE1IFBDSSBsaW5r
IDIgY2hhbmdlZCAwIC0+IDExDQooWEVOKSBbMjAxMi0wOS0wNSAxNTo1MTo1Nl0gSFZNMTU6
IFBDSS1JU0EgbGluayAyIHJvdXRlZCB0byBJUlExMQ0KKFhFTikgWzIwMTItMDktMDUgMTU6
NTE6NTZdIGlycS5jOjI3MDogRG9tMTUgUENJIGxpbmsgMyBjaGFuZ2VkIDAgLT4gNQ0KKFhF
TikgWzIwMTItMDktMDUgMTU6NTE6NTZdIEhWTTE1OiBQQ0ktSVNBIGxpbmsgMyByb3V0ZWQg
dG8gSVJRNQ0KKFhFTikgWzIwMTItMDktMDUgMTU6NTE6NTZdIEhWTTE1OiBwY2kgZGV2IDAx
OjIgSU5URC0+SVJRNQ0KKFhFTikgWzIwMTItMDktMDUgMTU6NTE6NTZdIEhWTTE1OiBwY2kg
ZGV2IDAxOjMgSU5UQS0+SVJRMTANCihYRU4pIFsyMDEyLTA5LTA1IDE1OjUxOjU2XSBIVk0x
NTogcGNpIGRldiAwMzowIElOVEEtPklSUTUNCihYRU4pIFsyMDEyLTA5LTA1IDE1OjUxOjU2
XSBIVk0xNTogcGNpIGRldiAwNDowIElOVEEtPklSUTUNCihYRU4pIFsyMDEyLTA5LTA1IDE1
OjUxOjU2XSBIVk0xNTogcGNpIGRldiAwMjowIGJhciAxMCBzaXplIDAyMDAwMDAwOiBmMDAw
MDAwOA0KKFhFTikgWzIwMTItMDktMDUgMTU6NTE6NTZdIEhWTTE1OiBwY2kgZGV2IDAzOjAg
YmFyIDE0IHNpemUgMDEwMDAwMDA6IGYyMDAwMDA4DQooWEVOKSBbMjAxMi0wOS0wNSAxNTo1
MTo1Nl0gSFZNMTU6IHBjaSBkZXYgMDQ6MCBiYXIgMTAgc2l6ZSAwMDAyMDAwMDogZjMwMDAw
MDANCihYRU4pIFsyMDEyLTA5LTA1IDE1OjUxOjU2XSBIVk0xNTogcGNpIGRldiAwMjowIGJh
ciAxNCBzaXplIDAwMDAxMDAwOiBmMzAyMDAwMA0KKFhFTikgWzIwMTItMDktMDUgMTU6NTE6
NTZdIEhWTTE1OiBwY2kgZGV2IDAzOjAgYmFyIDEwIHNpemUgMDAwMDAxMDA6IDAwMDBjMDAx
DQooWEVOKSBbMjAxMi0wOS0wNSAxNTo1MTo1Nl0gSFZNMTU6IHBjaSBkZXYgMDQ6MCBiYXIg
MTQgc2l6ZSAwMDAwMDA0MDogMDAwMGMxMDENCihYRU4pIFsyMDEyLTA5LTA1IDE1OjUxOjU2
XSBIVk0xNTogcGNpIGRldiAwMToyIGJhciAyMCBzaXplIDAwMDAwMDIwOiAwMDAwYzE0MQ0K
KFhFTikgWzIwMTItMDktMDUgMTU6NTE6NTZdIEhWTTE1OiBwY2kgZGV2IDAxOjEgYmFyIDIw
IHNpemUgMDAwMDAwMTA6IDAwMDBjMTYxDQooWEVOKSBbMjAxMi0wOS0wNSAxNTo1MTo1Nl0g
SFZNMTU6IE11bHRpcHJvY2Vzc29yIGluaXRpYWxpc2F0aW9uOg0KKFhFTikgWzIwMTItMDkt
MDUgMTU6NTE6NTZdIEhWTTE1OiAgLSBDUFUwIC4uLiA0OC1iaXQgcGh5cyAuLi4gZml4ZWQg
TVRSUnMgLi4uIHZhciBNVFJScyBbMi84XSAuLi4gZG9uZS4NCihYRU4pIFsyMDEyLTA5LTA1
IDE1OjUxOjU2XSBIVk0xNTogIC0gQ1BVMSAuLi4gNDgtYml0IHBoeXMgLi4uIGZpeGVkIE1U
UlJzIC4uLiB2YXIgTVRSUnMgWzIvOF0gLi4uIGRvbmUuDQooWEVOKSBbMjAxMi0wOS0wNSAx
NTo1MTo1Nl0gSFZNMTU6IFRlc3RpbmcgSFZNIGVudmlyb25tZW50Og0KKFhFTikgWzIwMTIt
MDktMDUgMTU6NTE6NTZdIEhWTTE1OiAgLSBSRVAgSU5TQiBhY3Jvc3MgcGFnZSBib3VuZGFy
aWVzIC4uLiBwYXNzZWQNCihYRU4pIFsyMDEyLTA5LTA1IDE1OjUxOjU2XSBIVk0xNTogIC0g
R1MgYmFzZSBNU1JzIGFuZCBTV0FQR1MgLi4uIHBhc3NlZA0KKFhFTikgWzIwMTItMDktMDUg
MTU6NTE6NTZdIEhWTTE1OiBQYXNzZWQgMiBvZiAyIHRlc3RzDQooWEVOKSBbMjAxMi0wOS0w
NSAxNTo1MTo1Nl0gSFZNMTU6IFdyaXRpbmcgU01CSU9TIHRhYmxlcyAuLi4NCihYRU4pIFsy
MDEyLTA5LTA1IDE1OjUxOjU2XSBIVk0xNTogTG9hZGluZyBST01CSU9TIC4uLg0KKFhFTikg
WzIwMTItMDktMDUgMTU6NTE6NTZdIEhWTTE1OiA5NjYwIGJ5dGVzIG9mIFJPTUJJT1MgaGln
aC1tZW1vcnkgZXh0ZW5zaW9uczoNCihYRU4pIFsyMDEyLTA5LTA1IDE1OjUxOjU2XSBIVk0x
NTogICBSZWxvY2F0aW5nIHRvIDB4ZmMwMDEwMDAtMHhmYzAwMzViYyAuLi4gZG9uZQ0KKFhF
TikgWzIwMTItMDktMDUgMTU6NTE6NTZdIEhWTTE1OiBDcmVhdGluZyBNUCB0YWJsZXMgLi4u
DQooWEVOKSBbMjAxMi0wOS0wNSAxNTo1MTo1Nl0gSFZNMTU6IExvYWRpbmcgQ2lycnVzIFZH
QUJJT1MgLi4uDQooWEVOKSBbMjAxMi0wOS0wNSAxNTo1MTo1Nl0gSFZNMTU6IExvYWRpbmcg
UENJIE9wdGlvbiBST00gLi4uDQooWEVOKSBbMjAxMi0wOS0wNSAxNTo1MTo1Nl0gSFZNMTU6
ICAtIE1hbnVmYWN0dXJlcjogaHR0cDovL2lweGUub3JnDQooWEVOKSBbMjAxMi0wOS0wNSAx
NTo1MTo1Nl0gSFZNMTU6ICAtIFByb2R1Y3QgbmFtZTogaVBYRQ0KKFhFTikgWzIwMTItMDkt
MDUgMTU6NTE6NTZdIEhWTTE1OiBPcHRpb24gUk9NczoNCihYRU4pIFsyMDEyLTA5LTA1IDE1
OjUxOjU2XSBIVk0xNTogIGMwMDAwLWM4ZmZmOiBWR0EgQklPUw0KKFhFTikgWzIwMTItMDkt
MDUgMTU6NTE6NTZdIEhWTTE1OiAgYzkwMDAtZDlmZmY6IEV0aGVyYm9vdCBST00NCihYRU4p
IFsyMDEyLTA5LTA1IDE1OjUxOjU2XSBIVk0xNTogTG9hZGluZyBBQ1BJIC4uLg0KKFhFTikg
WzIwMTItMDktMDUgMTU6NTE6NTZdIEhWTTE1OiB2bTg2IFRTUyBhdCBmYzAwZjY4MA0KKFhF
TikgWzIwMTItMDktMDUgMTU6NTE6NTZdIEhWTTE1OiBCSU9TIG1hcDoNCihYRU4pIFsyMDEy
LTA5LTA1IDE1OjUxOjU2XSBIVk0xNTogIGYwMDAwLWZmZmZmOiBNYWluIEJJT1MNCihYRU4p
IFsyMDEyLTA5LTA1IDE1OjUxOjU2XSBIVk0xNTogRTgyMCB0YWJsZToNCihYRU4pIFsyMDEy
LTA5LTA1IDE1OjUxOjU2XSBIVk0xNTogIFswMF06IDAwMDAwMDAwOjAwMDAwMDAwIC0gMDAw
MDAwMDA6MDAwOWUwMDA6IFJBTQ0KKFhFTikgWzIwMTItMDktMDUgMTU6NTE6NTZdIEhWTTE1
OiAgWzAxXTogMDAwMDAwMDA6MDAwOWUwMDAgLSAwMDAwMDAwMDowMDBhMDAwMDogUkVTRVJW
RUQNCihYRU4pIFsyMDEyLTA5LTA1IDE1OjUxOjU2XSBIVk0xNTogIEhPTEU6IDAwMDAwMDAw
OjAwMGEwMDAwIC0gMDAwMDAwMDA6MDAwZTAwMDANCihYRU4pIFsyMDEyLTA5LTA1IDE1OjUx
OjU2XSBIVk0xNTogIFswMl06IDAwMDAwMDAwOjAwMGUwMDAwIC0gMDAwMDAwMDA6MDAxMDAw
MDA6IFJFU0VSVkVEDQooWEVOKSBbMjAxMi0wOS0wNSAxNTo1MTo1Nl0gSFZNMTU6ICBbMDNd
OiAwMDAwMDAwMDowMDEwMDAwMCAtIDAwMDAwMDAwOjFmODAwMDAwOiBSQU0NCihYRU4pIFsy
MDEyLTA5LTA1IDE1OjUxOjU2XSBIVk0xNTogIEhPTEU6IDAwMDAwMDAwOjFmODAwMDAwIC0g
MDAwMDAwMDA6ZmMwMDAwMDANCihYRU4pIFsyMDEyLTA5LTA1IDE1OjUxOjU2XSBIVk0xNTog
IFswNF06IDAwMDAwMDAwOmZjMDAwMDAwIC0gMDAwMDAwMDE6MDAwMDAwMDA6IFJFU0VSVkVE
DQooWEVOKSBbMjAxMi0wOS0wNSAxNTo1MTo1Nl0gSFZNMTU6IEludm9raW5nIFJPTUJJT1Mg
Li4uDQooWEVOKSBbMjAxMi0wOS0wNSAxNTo1MTo1Nl0gSFZNMTU6ICRSZXZpc2lvbjogMS4y
MjEgJCAkRGF0ZTogMjAwOC8xMi8wNyAxNzozMjoyOSAkDQooWEVOKSBbMjAxMi0wOS0wNSAx
NTo1MTo1N10gc3RkdmdhLmM6MTQ3OmQxNSBlbnRlcmluZyBzdGR2Z2EgYW5kIGNhY2hpbmcg
bW9kZXMNCihYRU4pIFsyMDEyLTA5LTA1IDE1OjUxOjU3XSBIVk0xNTogVkdBQmlvcyAkSWQ6
IHZnYWJpb3MuYyx2IDEuNjcgMjAwOC8wMS8yNyAwOTo0NDoxMiB2cnVwcGVydCBFeHAgJA0K
KFhFTikgWzIwMTItMDktMDUgMTU6NTE6NTddIEhWTTE1OiBCb2NocyBCSU9TIC0gYnVpbGQ6
IDA2LzIzLzk5DQooWEVOKSBbMjAxMi0wOS0wNSAxNTo1MTo1N10gSFZNMTU6ICRSZXZpc2lv
bjogMS4yMjEgJCAkRGF0ZTogMjAwOC8xMi8wNyAxNzozMjoyOSAkDQooWEVOKSBbMjAxMi0w
OS0wNSAxNTo1MTo1N10gSFZNMTU6IE9wdGlvbnM6IGFwbWJpb3MgcGNpYmlvcyBlbHRvcml0
byBQTU0gDQooWEVOKSBbMjAxMi0wOS0wNSAxNTo1MTo1N10gSFZNMTU6IA0KKFhFTikgWzIw
MTItMDktMDUgMTU6NTE6NTddIEhWTTE1OiBhdGEwLTA6IFBDSFM9MTYzODMvMTYvNjMgdHJh
bnNsYXRpb249bGJhIExDSFM9MTAyNC8yNTUvNjMNCihYRU4pIFsyMDEyLTA5LTA1IDE1OjUx
OjU3XSBIVk0xNTogYXRhMCBtYXN0ZXI6IFFFTVUgSEFSRERJU0sgQVRBLTcgSGFyZC1EaXNr
ICg1NzI0NCBNQnl0ZXMpDQooWEVOKSBbMjAxMi0wOS0wNSAxNTo1MTo1OF0gSFZNMTU6IElE
RSB0aW1lIG91dA0KKFhFTikgWzIwMTItMDktMDUgMTU6NTE6NThdIEhWTTE1OiBhdGExIG1h
c3RlcjogUUVNVSBEVkQtUk9NIEFUQVBJLTQgQ0QtUm9tL0RWRC1Sb20NCihYRU4pIFsyMDEy
LTA5LTA1IDE1OjUyOjAwXSBIVk0xNTogSURFIHRpbWUgb3V0DQooWEVOKSBbMjAxMi0wOS0w
NSAxNTo1MjowMF0gSFZNMTU6IA0KKFhFTikgWzIwMTItMDktMDUgMTU6NTI6MDBdIEhWTTE1
OiANCihYRU4pIFsyMDEyLTA5LTA1IDE1OjUyOjAwXSBIVk0xNTogDQooWEVOKSBbMjAxMi0w
OS0wNSAxNTo1MjowMF0gSFZNMTU6IFByZXNzIEYxMiBmb3IgYm9vdCBtZW51Lg0KKFhFTikg
WzIwMTItMDktMDUgMTU6NTI6MDBdIEhWTTE1OiANCihYRU4pIFsyMDEyLTA5LTA1IDE1OjUy
OjAwXSBIVk0xNTogQm9vdGluZyBmcm9tIEhhcmQgRGlzay4uLg0KKFhFTikgWzIwMTItMDkt
MDUgMTU6NTI6MDBdIEhWTTE1OiBCb290aW5nIGZyb20gMDAwMDo3YzAwDQooWEVOKSBbMjAx
Mi0wOS0wNSAxNTo1MjowNF0gdHJhcHMuYzoyNTg0OmQxNiBEb21haW4gYXR0ZW1wdGVkIFdS
TVNSIDAwMDAwMDAwYzAwMTAwMDQgZnJvbSAweDAwMDA4Njc5YzAyYjQxNjUgdG8gMHgwMDAw
MDAwMDAwMDBhYmNkLg0KKFhFTikgWzIwMTItMDktMDUgMTU6NTI6MjddIHRyYXBzLmM6MzE1
NjogR1BGICgwMDYwKTogZmZmZjgyYzQ4MDE1YzlmZSAtPiBmZmZmODJjNDgwMjI0YjgzDQoo
WEVOKSBbMjAxMi0wOS0wNSAxNTo1MjoyN10gdHJhcHMuYzozMTU3OiAgc2hvd19leGVjdXRp
b25fc3RhdGUocmVncyk6IA0KKFhFTikgWzIwMTItMDktMDUgMTU6NTI6MjddIC0tLS1bIFhl
bi00LjIuMC1yYzQtcHJlICB4ODZfNjQgIGRlYnVnPXkgIE5vdCB0YWludGVkIF0tLS0tDQoo
WEVOKSBbMjAxMi0wOS0wNSAxNTo1MjoyN10gQ1BVOiAgICAyDQooWEVOKSBbMjAxMi0wOS0w
NSAxNTo1MjoyN10gUklQOiAgICBlMDA4Ols8ZmZmZjgyYzQ4MDE1YzlmZT5dIGNvbnRleHRf
c3dpdGNoKzB4Mzk0LzB4ZWViDQooWEVOKSBbMjAxMi0wOS0wNSAxNTo1MjoyN10gUkZMQUdT
OiAwMDAwMDAwMDAwMDEwMjQ2ICAgQ09OVEVYVDogaHlwZXJ2aXNvcg0KKFhFTikgWzIwMTIt
MDktMDUgMTU6NTI6MjddIHJheDogMDAwMDAwMDAwMDAwMDAwMSAgIHJieDogZmZmZjgzMDBh
NTJkOTAwMCAgIHJjeDogMDAwMDAwMDAwMDAwMDAwMQ0KKFhFTikgWzIwMTItMDktMDUgMTU6
NTI6MjddIHJkeDogMDAwMDAwMDAwMDAwMDA2MyAgIHJzaTogMDAwMDAwMDAwMDAwMDAwMSAg
IHJkaTogMDAwMDAwMDAwMDAwMDE3MQ0KKFhFTikgWzIwMTItMDktMDUgMTU6NTI6MjddIHJi
cDogZmZmZjgzMDI0ZDhiN2UyOCAgIHJzcDogZmZmZjgzMDI0ZDhiN2Q4OCAgIHI4OiAgMDAw
MDAwMDAwMDAwMDAwNg0KKFhFTikgWzIwMTItMDktMDUgMTU6NTI6MjddIHI5OiAgZmZmZjgz
MDBhZmQwNzA2MCAgIHIxMDogMDAwMDAwMDBkZWFkYmVlZiAgIHIxMTogMDAwMDAwMDAwMDAw
MDI0Ng0KKFhFTikgWzIwMTItMDktMDUgMTU6NTI6MjddIHIxMjogZmZmZjgzMDBhZmQwNzAw
MCAgIHIxMzogMDAwMDAwMDAwMDAwMDAwMiAgIHIxNDogMDAwMDAwMDAwMDAwMDAwMg0KKFhF
TikgWzIwMTItMDktMDUgMTU6NTI6MjddIHIxNTogZmZmZjgzMDI0ZDk1MDA0OCAgIGNyMDog
MDAwMDAwMDA4MDA1MDAzYiAgIGNyNDogMDAwMDAwMDAwMDAwMDZmMA0KKFhFTikgWzIwMTIt
MDktMDUgMTU6NTI6MjddIGNyMzogMDAwMDAwMDA2ODQ1YzAwMCAgIGNyMjogMDAwMDAwMDBm
NzYwYzg4Zg0KKFhFTikgWzIwMTItMDktMDUgMTU6NTI6MjddIGRzOiAwMDAwICAgZXM6IDAw
MDAgICBmczogMDAwMCAgIGdzOiAwMDAwICAgc3M6IGUwMTAgICBjczogZTAwOA0KKFhFTikg
WzIwMTItMDktMDUgMTU6NTI6MjddIFhlbiBzdGFjayB0cmFjZSBmcm9tIHJzcD1mZmZmODMw
MjRkOGI3ZDg4Og0KKFhFTikgWzIwMTItMDktMDUgMTU6NTI6MjddICAgIGZmZmY4MzAyNGQ4
YjdlZjggZmZmZjgyYzQ4MDEwZWQ3YiAwMDAwMDAxZTY1NzU1MDc4IDAwMDAwMDAwNjViNTEw
MDANCihYRU4pIFsyMDEyLTA5LTA1IDE1OjUyOjI3XSAgICBmZmZmODMwMDY1YjUxMDYwIGZm
ZmY4MzAyNGQ5NTAwNjAgZmZmZjgzMDI0ZDhiN2UxOCBmZmZmODJjNDgwMTgwNWJlDQooWEVO
KSBbMjAxMi0wOS0wNSAxNTo1MjoyN10gICAgMDAwMDAwMDAwMDAwMDBiNCAwMDAwMDBhZWY3
NDYyOWQwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMA0KKFhFTikgWzIwMTIt
MDktMDUgMTU6NTI6MjddICAgIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCBm
ZmZmODMwMjRkOGI3ZTI4IGZmZmY4MzAwYWZkMDcwMDANCihYRU4pIFsyMDEyLTA5LTA1IDE1
OjUyOjI3XSAgICBmZmZmODMwMGE1MmQ5MDAwIDAwMDAwMDJlNTQwZTUyNDUgMDAwMDAwMDAw
MDAwMDAwMiBmZmZmODMwMjRkOTUwMDQ4DQooWEVOKSBbMjAxMi0wOS0wNSAxNTo1MjoyN10g
ICAgZmZmZjgzMDI0ZDhiN2ViOCBmZmZmODJjNDgwMTI0YTcwIDAwZmY4MzAyNGQ4YjdlODgg
ZmZmZjgzMDI0ZDk1MDA0MA0KKFhFTikgWzIwMTItMDktMDUgMTU6NTI6MjddICAgIDAwMDAw
MDAyNTc3MWFhMjcgMDAwMDAwMmU1NDBlNTI0NSBmZmZmODMwMjRkOGI3ZTg4IGZmZmZmZmZm
ZmZmZmZmYzINCihYRU4pIFsyMDEyLTA5LTA1IDE1OjUyOjI3XSAgICBmZmZmODMwMGE1MmQ5
MDAwIDAwMDAwMDAwMDFjOWMzODAgZmZmZjgzMDI0ZDhiN2UwMCBmZmZmODJjNDgwMTIyNmNl
DQooWEVOKSBbMjAxMi0wOS0wNSAxNTo1MjoyN10gICAgZmZmZjgzMDI0ZDhiN2VmOCBmZmZm
ODJjNDgwMmQ4MTAwIDAwMDAwMDAwZmZmZmZmZmYgZmZmZjgyYzQ4MDJkODAwMA0KKFhFTikg
WzIwMTItMDktMDUgMTU6NTI6MjddICAgIGZmZmY4MzAyNGQ4YjdmMTggZmZmZmZmZmZmZmZm
ZmZmZiBmZmZmODMwMjRkOGI3ZWY4IGZmZmY4MmM0ODAxMjVlMzENCihYRU4pIFsyMDEyLTA5
LTA1IDE1OjUyOjI3XSAgICAwMDAwMDAwMDAwMDAwMjQ2IGZmZmY4MzAwYWZkMDcwMDAgZmZm
ZmZmZmY4MWVjZTVkOCAwMDAwMDAwMDAwMDAwMDAwDQooWEVOKSBbMjAxMi0wOS0wNSAxNTo1
MjoyN10gICAgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIGZmZmY4MzAyNGQ4
YjdmMDggZmZmZjgyYzQ4MDEyNWU2OA0KKFhFTikgWzIwMTItMDktMDUgMTU6NTI6MjddICAg
IDAwMDA3Y2ZkYjI3NDgwYzcgZmZmZjgyYzQ4MDIyMmYwNiAwMDAwMDAwMDAwMDAwMDAwIGZm
ZmZmZmZmODFlMTM4ODANCihYRU4pIFsyMDEyLTA5LTA1IDE1OjUyOjI3XSAgICAwMDAwMDAw
MDAwMDAwMDAwIGZmZmY4ODAwMWUwYjAwZDggZmZmZmZmZmY4MWUwMWNlOCBmZmZmODgwMDFm
YzBiMTAwDQooWEVOKSBbMjAxMi0wOS0wNSAxNTo1MjoyN10gICAgMDAwMDAwMDAwMDAwMDIw
MiAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMA0K
KFhFTikgWzIwMTItMDktMDUgMTU6NTI6MjddICAgIDAwMDAwMDAwMDAwMDAwMDAgZmZmZmZm
ZmY4MTAwMTFhYSBmZmZmODgwMDFlYWQzMGMwIDAwMDAwMDAwZGVhZGJlZWYNCihYRU4pIFsy
MDEyLTA5LTA1IDE1OjUyOjI3XSAgICAwMDAwMDAwMGRlYWRiZWVmIDAwMDAwMTAwMDAwMDAw
MDAgZmZmZmZmZmY4MTAwMTFhYSAwMDAwMDAwMDAwMDBlMDMzDQooWEVOKSBbMjAxMi0wOS0w
NSAxNTo1MjoyN10gICAgMDAwMDAwMDAwMDAwMDIwMiBmZmZmZmZmZjgxZTAxY2IwIDAwMDAw
MDAwMDAwMGUwMmIgMDAwMDViZmQwMDAwYmVlZg0KKFhFTikgWzIwMTItMDktMDUgMTU6NTI6
MjddICAgIDgwMDAwMDAwMDAwMGJlZWYgNzQwMDAwMDAwMDAwYmVlZiAwMDAwMDAwMDAwMThi
ZWVmIDAwMDA1YmZlMDAwMDAwMDINCihYRU4pIFsyMDEyLTA5LTA1IDE1OjUyOjI3XSAgICBm
ZmZmODMwMGE1MmQ5MDAwIDAwMDAwMDNkY2Q2NGU2ODAgMDAwMDAwMDAwMDE4ZTBjOQ0KKFhF
TikgWzIwMTItMDktMDUgMTU6NTI6MjddIFhlbiBjYWxsIHRyYWNlOg0KKFhFTikgWzIwMTIt
MDktMDUgMTU6NTI6MjddICAgIFs8ZmZmZjgyYzQ4MDE1YzlmZT5dIGNvbnRleHRfc3dpdGNo
KzB4Mzk0LzB4ZWViDQooWEVOKSBbMjAxMi0wOS0wNSAxNTo1MjoyN10gICAgWzxmZmZmODJj
NDgwMTI0YTcwPl0gc2NoZWR1bGUrMHg2NjYvMHg2NzUNCihYRU4pIFsyMDEyLTA5LTA1IDE1
OjUyOjI3XSAgICBbPGZmZmY4MmM0ODAxMjVlMzE+XSBfX2RvX3NvZnRpcnErMHhhNC8weGI1
DQooWEVOKSBbMjAxMi0wOS0wNSAxNTo1MjoyN10gICAgWzxmZmZmODJjNDgwMTI1ZTY4Pl0g
ZG9fc29mdGlycSsweDI2LzB4MjgNCihYRU4pIFsyMDEyLTA5LTA1IDE1OjUyOjI3XSAgICAN
CihYRU4pIFsyMDEyLTA5LTA1IDE1OjUyOjI3XSB0cmFwcy5jOjMxNTk6ICAgc2hvd19leGVj
dXRpb25fc3RhdGUoZ3Vlc3RfY3B1X3VzZXJfcmVncygpKTogDQooWEVOKSBbMjAxMi0wOS0w
NSAxNTo1MjoyN10gLS0tLVsgWGVuLTQuMi4wLXJjNC1wcmUgIHg4Nl82NCAgZGVidWc9eSAg
Tm90IHRhaW50ZWQgXS0tLS0NCihYRU4pIFsyMDEyLTA5LTA1IDE1OjUyOjI3XSBDUFU6ICAg
IDINCihYRU4pIFsyMDEyLTA5LTA1IDE1OjUyOjI3XSBSSVA6ICAgIGUwMzM6WzxmZmZmZmZm
ZjgxMDAxMWFhPl0NCihYRU4pIFsyMDEyLTA5LTA1IDE1OjUyOjI3XSBSRkxBR1M6IDAwMDAw
MDAwMDAwMDAyMDIgICBFTTogMSAgIENPTlRFWFQ6IHB2IGd1ZXN0DQooWEVOKSBbMjAxMi0w
OS0wNSAxNTo1MjoyN10gcmF4OiAwMDAwMDAwMDAwMDAwMDAwICAgcmJ4OiBmZmZmODgwMDFm
YzBiMTAwICAgcmN4OiBmZmZmZmZmZjgxMDAxMWFhDQooWEVOKSBbMjAxMi0wOS0wNSAxNTo1
MjoyN10gcmR4OiBmZmZmODgwMDFlYWQzMGMwICAgcnNpOiAwMDAwMDAwMGRlYWRiZWVmICAg
cmRpOiAwMDAwMDAwMGRlYWRiZWVmDQooWEVOKSBbMjAxMi0wOS0wNSAxNTo1MjoyN10gcmJw
OiBmZmZmZmZmZjgxZTAxY2U4ICAgcnNwOiBmZmZmZmZmZjgxZTAxY2IwICAgcjg6ICAwMDAw
MDAwMDAwMDAwMDAwDQooWEVOKSBbMjAxMi0wOS0wNSAxNTo1MjoyN10gcjk6ICAwMDAwMDAw
MDAwMDAwMDAwICAgcjEwOiAwMDAwMDAwMDAwMDAwMDAwICAgcjExOiAwMDAwMDAwMDAwMDAw
MjAyDQooWEVOKSBbMjAxMi0wOS0wNSAxNTo1MjoyN10gcjEyOiBmZmZmODgwMDFlMGIwMGQ4
ICAgcjEzOiAwMDAwMDAwMDAwMDAwMDAwICAgcjE0OiBmZmZmZmZmZjgxZTEzODgwDQooWEVO
KSBbMjAxMi0wOS0wNSAxNTo1MjoyN10gcjE1OiAwMDAwMDAwMDAwMDAwMDAwICAgY3IwOiAw
MDAwMDAwMDgwMDUwMDNiICAgY3I0OiAwMDAwMDAwMDAwMDAwNmYwDQooWEVOKSBbMjAxMi0w
OS0wNSAxNTo1MjoyN10gY3IzOiAwMDAwMDAwMDY4NDVjMDAwICAgY3IyOiAwMDAwMDAwMGY3
NjBjODhmDQooWEVOKSBbMjAxMi0wOS0wNSAxNTo1MjoyN10gZHM6IDAwMDAgICBlczogMDAw
MCAgIGZzOiAwMDAwICAgZ3M6IDAwMDAgICBzczogZTAyYiAgIGNzOiBlMDMzDQooWEVOKSBb
MjAxMi0wOS0wNSAxNTo1MjoyN10gR3Vlc3Qgc3RhY2sgdHJhY2UgZnJvbSByc3A9ZmZmZmZm
ZmY4MWUwMWNiMDoNCihYRU4pIFsyMDEyLTA5LTA1IDE1OjUyOjI3XSAgICAwMDAwMDAwMDAw
MDAwMDAwIDAwMDAwMDAwMDAwMDAwMDEgZmZmZmZmZmY4MTAwNDk0MiBmZmZmZmZmZjgxZTEz
NDIwDQooWEVOKSBbMjAxMi0wOS0wNSAxNTo1MjoyN10gICAgZmZmZjg4MDAxZWFkMzBjMCAw
MDAwMDAwMDAwMDAwMDAwIGZmZmZmZmZmODFlMTM4ODAgZmZmZmZmZmY4MWUwMWQwOA0KKFhF
TikgWzIwMTItMDktMDUgMTU6NTI6MjddICAgIGZmZmZmZmZmODEwMDM5NDEgZmZmZjg4MDAx
ZWFkMzBjMCBmZmZmZmZmZjgxZTEzNDIwIGZmZmZmZmZmODFlMDFkNjgNCihYRU4pIFsyMDEy
LTA5LTA1IDE1OjUyOjI3XSAgICBmZmZmZmZmZjgxMDBiODUwIGZmZmZmZmZmODFlMTM0MjAg
MDAwMDAwMDAwMDAwMDAwMSAwMDAwMDAwMDAwMDAwMDYzDQooWEVOKSBbMjAxMi0wOS0wNSAx
NTo1MjoyN10gICAgZmZmZjg4MDAxZmMxMGE4MCBmZmZmZmZmZjgxZTAxZDc4IGZmZmY4ODAw
MWZjMTJlODAgMDAwMDAwMDAwMDAwMDAwMA0KKFhFTikgWzIwMTItMDktMDUgMTU6NTI6Mjdd
ICAgIGZmZmY4ODAwMWNjZDY4ODAgMDAwMDAwMDAwMDAwMDA4MiBmZmZmZmZmZjgxMGYwMDQw
IGZmZmZmZmZmODFlMTM0MjANCihYRU4pIFsyMDEyLTA5LTA1IDE1OjUyOjI3XSAgICBmZmZm
ZmZmZjgxN2ZhMmY1IGZmZmZmZmZmODFlMDFlYzggMDAwMDAwMDAwMDAwMDIxNiBmZmZmODgw
MDFmYzBlNjk4DQooWEVOKSBbMjAxMi0wOS0wNSAxNTo1MjoyN10gICAgMDAwMDAwMDAwMDAw
MDAwMSBmZmZmZmZmZjgxZTEzNDIwIDAwMDAwMDAwMDAwMTJlODAgZmZmZmZmZmY4MWUwMWZk
OA0KKFhFTikgWzIwMTItMDktMDUgMTU6NTI6MjddICAgIGZmZmZmZmZmODFlMDAwMTAgMDAw
MDAwMDAwMDAxMmU4MCAwMDAwMDAwMDAwMDEyZTgwIGZmZmZmZmZmODFlMDFmZDgNCihYRU4p
IFsyMDEyLTA5LTA1IDE1OjUyOjI3XSAgICAwMDAwMDAwMDAwMDEyZTgwIGZmZmY4ODAwMWVh
ZDIwODAgZmZmZmZmZmY4MWUxMzQyMCBmZmZmODgwMDFmYzBlOGEwDQooWEVOKSBbMjAxMi0w
OS0wNSAxNTo1MjoyN10gICAgMDAwMDAwMDAwMDAwMDAwMCBmZmZmZmZmZjgxZTAxZTk4IGZm
ZmZmZmZmODEwOGIzODEgMDAwMDAwMDAwMDAwMDAwMQ0KKFhFTikgWzIwMTItMDktMDUgMTU6
NTI6MjddICAgIGZmZmZmZmZmODEwYWIyMjEgMDAwMDAwMDE4MWUwMWUyOCAwMDAwMDAwMDAw
MDAwMDAwIDAwMDAwMDAwODFlMDFlNDgNCihYRU4pIFsyMDEyLTA5LTA1IDE1OjUyOjI3XSAg
ICAwMDAwMDAwMDAwMDAwMDcwIDAwMDAwMDAwMWZjMGU4YTAgMDAwMDAwMDAwMDAwZTY4MCAw
MDAwMDAwMDAwMDAwMDAwDQooWEVOKSBbMjAxMi0wOS0wNSAxNTo1MjoyN10gICAgZmZmZmZm
ZmY4MWUxMzQyMCBmZmZmZmZmZjgxMGE4NmZjIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAw
MDAwMDAwMA0KKFhFTikgWzIwMTItMDktMDUgMTU6NTI6MjddICAgIDAwMDAwMDAwMDAwMDAw
MDAgZmZmZmZmZmY4MWUwMWU5OCBmZmZmZmZmZjgxMGFjYjc4IGZmZmY4ODAwMWZjMGU4YTAN
CihYRU4pIFsyMDEyLTA5LTA1IDE1OjUyOjI3XSAgICAwMDAwMDAwNTczOWQwNWQ5IGZmZmZm
ZmZmODFlMDFlYTggZmZmZmZmZmY4MWUwMDAxMCBmZmZmZmZmZjgxZWNlNWQ4DQooWEVOKSBb
MjAxMi0wOS0wNSAxNTo1MjoyN10gICAgZmZmZmZmZmY4MWY0MjBjMCAwMDAwMDAwMDAwMDAw
MDAwIDAwMDAwMDAwMDAwMDAwMDAgZmZmZmZmZmY4MWUwMWVkOA0KKFhFTikgWzIwMTItMDkt
MDUgMTU6NTI6MjddICAgIGZmZmZmZmZmODE3ZmE4MTQgZmZmZmZmZmY4MWUwMWVmOCBmZmZm
ZmZmZjgxMDE2NDU2IDAwMDAwMDAwMDAwMDAwMDINCihYRU4pIFsyMDEyLTA5LTA1IDE1OjUy
OjI3XSAgICBmZmZmZmZmZjgxZjM5OTIwIGZmZmZmZmZmODFlMDFmMjggZmZmZmZmZmY4MTdk
NWI4YyBmZmZmZmZmZjgxN2Q1YWQwDQooWEVOKSBbMjAxMi0wOS0wNSAxNTo1MjoyN10gICAg
ZmZmZjg4MDAwMDAwMTAwMCBmZmZmZmZmZjgxZTAxZjI4IDAwMDAwMDAwMDAwMDAwMDAgZmZm
ZmZmZmY4MWUwMWY3OA0KKFhFTikgWzIwMTItMDktMDUgMTU6NTI6MjhdIGlycS5jOjI3MDog
RG9tMTUgUENJIGxpbmsgMCBjaGFuZ2VkIDUgLT4gMA0KKFhFTikgWzIwMTItMDktMDUgMTU6
NTI6MjhdIGlycS5jOjI3MDogRG9tMTUgUENJIGxpbmsgMSBjaGFuZ2VkIDEwIC0+IDANCihY
RU4pIFsyMDEyLTA5LTA1IDE1OjUyOjI4XSBpcnEuYzoyNzA6IERvbTE1IFBDSSBsaW5rIDIg
Y2hhbmdlZCAxMSAtPiAwDQooWEVOKSBbMjAxMi0wOS0wNSAxNTo1MjoyOF0gaXJxLmM6Mjcw
OiBEb20xNSBQQ0kgbGluayAzIGNoYW5nZWQgNSAtPiAwDQooWEVOKSBbMjAxMi0wOS0wNSAx
NTo1MjoyOF0gaHZtLmM6MjQzNTpkMTUgZ3Vlc3QgYXR0ZW1wdGVkIHdyaXRlIHRvIHJlYWQt
b25seSBtZW1vcnkgcGFnZS4gZ2ZuPTB4ZGMsIG1mbj0weGE0YTBhDQooWEVOKSBbMjAxMi0w
OS0wNSAxNTo1MjoyOF0gaHZtLmM6MjQzNTpkMTUgZ3Vlc3QgYXR0ZW1wdGVkIHdyaXRlIHRv
IHJlYWQtb25seSBtZW1vcnkgcGFnZS4gZ2ZuPTB4ZGQsIG1mbj0weGE0YTA5DQooWEVOKSBb
MjAxMi0wOS0wNSAxNTo1MjoyOF0gaHZtLmM6MjQzNTpkMTUgZ3Vlc3QgYXR0ZW1wdGVkIHdy
aXRlIHRvIHJlYWQtb25seSBtZW1vcnkgcGFnZS4gZ2ZuPTB4ZGUsIG1mbj0weGE0YTA4DQoo
WEVOKSBbMjAxMi0wOS0wNSAxNTo1MjoyOF0gaHZtLmM6MjQzNTpkMTUgZ3Vlc3QgYXR0ZW1w
dGVkIHdyaXRlIHRvIHJlYWQtb25seSBtZW1vcnkgcGFnZS4gZ2ZuPTB4ZGQsIG1mbj0weGE0
YTA5DQooWEVOKSBbMjAxMi0wOS0wNSAxNTo1MjoyOF0gaHZtLmM6MjQzNTpkMTUgZ3Vlc3Qg
YXR0ZW1wdGVkIHdyaXRlIHRvIHJlYWQtb25seSBtZW1vcnkgcGFnZS4gZ2ZuPTB4ZGMsIG1m
bj0weGE0YTBhDQooWEVOKSBbMjAxMi0wOS0wNSAxNTo1MjoyOF0gaHZtLmM6MjQzNTpkMTUg
Z3Vlc3QgYXR0ZW1wdGVkIHdyaXRlIHRvIHJlYWQtb25seSBtZW1vcnkgcGFnZS4gZ2ZuPTB4
ZGUsIG1mbj0weGE0YTA4DQooWEVOKSBbMjAxMi0wOS0wNSAxNTo1MjoyOF0gaHZtLmM6MjQz
NTpkMTUgZ3Vlc3QgYXR0ZW1wdGVkIHdyaXRlIHRvIHJlYWQtb25seSBtZW1vcnkgcGFnZS4g
Z2ZuPTB4ZGQsIG1mbj0weGE0YTA5DQooWEVOKSBbMjAxMi0wOS0wNSAxNTo1MjoyOF0gaHZt
LmM6MjQzNTpkMTUgZ3Vlc3QgYXR0ZW1wdGVkIHdyaXRlIHRvIHJlYWQtb25seSBtZW1vcnkg
cGFnZS4gZ2ZuPTB4ZGUsIG1mbj0weGE0YTA4DQooWEVOKSBbMjAxMi0wOS0wNSAxNTo1Mjoy
OF0gaHZtLmM6MjQzNTpkMTUgZ3Vlc3QgYXR0ZW1wdGVkIHdyaXRlIHRvIHJlYWQtb25seSBt
ZW1vcnkgcGFnZS4gZ2ZuPTB4ZGMsIG1mbj0weGE0YTBhDQooWEVOKSBbMjAxMi0wOS0wNSAx
NTo1MjoyOF0gaHZtLmM6MjQzNTpkMTUgZ3Vlc3QgYXR0ZW1wdGVkIHdyaXRlIHRvIHJlYWQt
b25seSBtZW1vcnkgcGFnZS4gZ2ZuPTB4ZGQsIG1mbj0weGE0YTA5DQooWEVOKSBbMjAxMi0w
OS0wNSAxNTo1MjoyOF0gaHZtLmM6MjQzNTpkMTUgZ3Vlc3QgYXR0ZW1wdGVkIHdyaXRlIHRv
IHJlYWQtb25seSBtZW1vcnkgcGFnZS4gZ2ZuPTB4ZGMsIG1mbj0weGE0YTBhDQooWEVOKSBb
MjAxMi0wOS0wNSAxNTo1MjoyOF0gaHZtLmM6MjQzNTpkMTUgZ3Vlc3QgYXR0ZW1wdGVkIHdy
aXRlIHRvIHJlYWQtb25seSBtZW1vcnkgcGFnZS4gZ2ZuPTB4ZGQsIG1mbj0weGE0YTA5DQoo
WEVOKSBbMjAxMi0wOS0wNSAxNTo1MjoyOF0gaHZtLmM6MjQzNTpkMTUgZ3Vlc3QgYXR0ZW1w
dGVkIHdyaXRlIHRvIHJlYWQtb25seSBtZW1vcnkgcGFnZS4gZ2ZuPTB4ZGUsIG1mbj0weGE0
YTA4DQooWEVOKSBbMjAxMi0wOS0wNSAxNTo1MjoyOF0gaHZtLmM6MjQzNTpkMTUgZ3Vlc3Qg
YXR0ZW1wdGVkIHdyaXRlIHRvIHJlYWQtb25seSBtZW1vcnkgcGFnZS4gZ2ZuPTB4ZGQsIG1m
bj0weGE0YTA5DQooWEVOKSBbMjAxMi0wOS0wNSAxNTo1MjoyOF0gaHZtLmM6MjQzNTpkMTUg
Z3Vlc3QgYXR0ZW1wdGVkIHdyaXRlIHRvIHJlYWQtb25seSBtZW1vcnkgcGFnZS4gZ2ZuPTB4
ZGMsIG1mbj0weGE0YTBhDQooWEVOKSBbMjAxMi0wOS0wNSAxNTo1MjoyOF0gaHZtLmM6MjQz
NTpkMTUgZ3Vlc3QgYXR0ZW1wdGVkIHdyaXRlIHRvIHJlYWQtb25seSBtZW1vcnkgcGFnZS4g
Z2ZuPTB4ZGQsIG1mbj0weGE0YTA5DQooWEVOKSBbMjAxMi0wOS0wNSAxNTo1MjoyOF0gaHZt
LmM6MjQzNTpkMTUgZ3Vlc3QgYXR0ZW1wdGVkIHdyaXRlIHRvIHJlYWQtb25seSBtZW1vcnkg
cGFnZS4gZ2ZuPTB4ZGMsIG1mbj0weGE0YTBhDQooWEVOKSBbMjAxMi0wOS0wNSAxNTo1Mjoy
OF0gaHZtLmM6MjQzNTpkMTUgZ3Vlc3QgYXR0ZW1wdGVkIHdyaXRlIHRvIHJlYWQtb25seSBt
ZW1vcnkgcGFnZS4gZ2ZuPTB4ZGQsIG1mbj0weGE0YTA5DQooWEVOKSBbMjAxMi0wOS0wNSAx
NTo1MjozMV0gaHZtLmM6MjQzNTpkMTUgZ3Vlc3QgYXR0ZW1wdGVkIHdyaXRlIHRvIHJlYWQt
b25seSBtZW1vcnkgcGFnZS4gZ2ZuPTB4YzksIG1mbj0weGE0YTFkDQooWEVOKSBbMjAxMi0w
OS0wNSAxNTo1MjozMV0gaHZtLmM6MjQzNTpkMTUgZ3Vlc3QgYXR0ZW1wdGVkIHdyaXRlIHRv
IHJlYWQtb25seSBtZW1vcnkgcGFnZS4gZ2ZuPTB4Y2IsIG1mbj0weGE0YTFiDQooWEVOKSBb
MjAxMi0wOS0wNSAxNTo1MjozMV0gaHZtLmM6MjQzNTpkMTUgZ3Vlc3QgYXR0ZW1wdGVkIHdy
aXRlIHRvIHJlYWQtb25seSBtZW1vcnkgcGFnZS4gZ2ZuPTB4Y2QsIG1mbj0weGE0YTE5DQoo
WEVOKSBbMjAxMi0wOS0wNSAxNTo1MjozMV0gaHZtLmM6MjQzNTpkMTUgZ3Vlc3QgYXR0ZW1w
dGVkIHdyaXRlIHRvIHJlYWQtb25seSBtZW1vcnkgcGFnZS4gZ2ZuPTB4Y2YsIG1mbj0weGE0
YTE3DQooWEVOKSBbMjAxMi0wOS0wNSAxNTo1MjozMV0gaHZtLmM6MjQzNTpkMTUgZ3Vlc3Qg
YXR0ZW1wdGVkIHdyaXRlIHRvIHJlYWQtb25seSBtZW1vcnkgcGFnZS4gZ2ZuPTB4ZDEsIG1m
bj0weGE0YTE1DQooWEVOKSBbMjAxMi0wOS0wNSAxNTo1MjozMV0gaHZtLmM6MjQzNTpkMTUg
Z3Vlc3QgYXR0ZW1wdGVkIHdyaXRlIHRvIHJlYWQtb25seSBtZW1vcnkgcGFnZS4gZ2ZuPTB4
ZDMsIG1mbj0weGE0YTEzDQooWEVOKSBbMjAxMi0wOS0wNSAxNTo1MjozMV0gaHZtLmM6MjQz
NTpkMTUgZ3Vlc3QgYXR0ZW1wdGVkIHdyaXRlIHRvIHJlYWQtb25seSBtZW1vcnkgcGFnZS4g
Z2ZuPTB4ZDUsIG1mbj0weGE0YTExDQooWEVOKSBbMjAxMi0wOS0wNSAxNTo1MjozMV0gaHZt
LmM6MjQzNTpkMTUgZ3Vlc3QgYXR0ZW1wdGVkIHdyaXRlIHRvIHJlYWQtb25seSBtZW1vcnkg
cGFnZS4gZ2ZuPTB4ZDcsIG1mbj0weGE0YTBmDQooWEVOKSBbMjAxMi0wOS0wNSAxNTo1Mjoz
MV0gaHZtLmM6MjQzNTpkMTUgZ3Vlc3QgYXR0ZW1wdGVkIHdyaXRlIHRvIHJlYWQtb25seSBt
ZW1vcnkgcGFnZS4gZ2ZuPTB4ZDksIG1mbj0weGE0YTBkDQooWEVOKSBbMjAxMi0wOS0wNSAx
NTo1MjozMV0gaHZtLmM6MjQzNTpkMTUgZ3Vlc3QgYXR0ZW1wdGVkIHdyaXRlIHRvIHJlYWQt
b25seSBtZW1vcnkgcGFnZS4gZ2ZuPTB4ZGIsIG1mbj0weGE0YTBiDQooWEVOKSBbMjAxMi0w
OS0wNSAxNTo1MjozMV0gaHZtLmM6MjQzNTpkMTUgZ3Vlc3QgYXR0ZW1wdGVkIHdyaXRlIHRv
IHJlYWQtb25seSBtZW1vcnkgcGFnZS4gZ2ZuPTB4ZGQsIG1mbj0weGE0YTA5DQooWEVOKSBb
MjAxMi0wOS0wNSAxNTo1MjozMV0gaHZtLmM6MjQzNTpkMTUgZ3Vlc3QgYXR0ZW1wdGVkIHdy
aXRlIHRvIHJlYWQtb25seSBtZW1vcnkgcGFnZS4gZ2ZuPTB4ZGYsIG1mbj0weGE0YTA3DQoo
WEVOKSBbMjAxMi0wOS0wNSAxNTo1MjozMV0gaHZtLmM6MjQzNTpkMTUgZ3Vlc3QgYXR0ZW1w
dGVkIHdyaXRlIHRvIHJlYWQtb25seSBtZW1vcnkgcGFnZS4gZ2ZuPTB4ZTEsIG1mbj0weGE0
YTA1DQooWEVOKSBbMjAxMi0wOS0wNSAxNTo1MjozMV0gaHZtLmM6MjQzNTpkMTUgZ3Vlc3Qg
YXR0ZW1wdGVkIHdyaXRlIHRvIHJlYWQtb25seSBtZW1vcnkgcGFnZS4gZ2ZuPTB4ZTMsIG1m
bj0weGE0YTAzDQooWEVOKSBbMjAxMi0wOS0wNSAxNTo1MjozMV0gaHZtLmM6MjQzNTpkMTUg
Z3Vlc3QgYXR0ZW1wdGVkIHdyaXRlIHRvIHJlYWQtb25seSBtZW1vcnkgcGFnZS4gZ2ZuPTB4
ZTUsIG1mbj0weGE0YTAxDQooWEVOKSBbMjAxMi0wOS0wNSAxNTo1MjozMV0gaHZtLmM6MjQz
NTpkMTUgZ3Vlc3QgYXR0ZW1wdGVkIHdyaXRlIHRvIHJlYWQtb25seSBtZW1vcnkgcGFnZS4g
Z2ZuPTB4ZTcsIG1mbj0weGE0NjNmDQooWEVOKSBbMjAxMi0wOS0wNSAxNTo1MjozMV0gaHZt
LmM6MjQzNTpkMTUgZ3Vlc3QgYXR0ZW1wdGVkIHdyaXRlIHRvIHJlYWQtb25seSBtZW1vcnkg
cGFnZS4gZ2ZuPTB4ZTksIG1mbj0weGE0NjNkDQooWEVOKSBbMjAxMi0wOS0wNSAxNTo1Mjoz
MV0gaHZtLmM6MjQzNTpkMTUgZ3Vlc3QgYXR0ZW1wdGVkIHdyaXRlIHRvIHJlYWQtb25seSBt
ZW1vcnkgcGFnZS4gZ2ZuPTB4ZWIsIG1mbj0weGE0NjNiDQooWEVOKSBbMjAxMi0wOS0wNSAx
NTo1MjozMV0gaHZtLmM6MjQzNTpkMTUgZ3Vlc3QgYXR0ZW1wdGVkIHdyaXRlIHRvIHJlYWQt
b25seSBtZW1vcnkgcGFnZS4gZ2ZuPTB4ZWQsIG1mbj0weGE0NjM5DQooWEVOKSBbMjAxMi0w
OS0wNSAxNTo1MjozMV0gaHZtLmM6MjQzNTpkMTUgZ3Vlc3QgYXR0ZW1wdGVkIHdyaXRlIHRv
IHJlYWQtb25seSBtZW1vcnkgcGFnZS4gZ2ZuPTB4ZWYsIG1mbj0weGE0NjM3DQooWEVOKSBb
MjAxMi0wOS0wNSAxNTo1ODo0Ml0gdHJhcHMuYzozMTU2OiBHUEYgKDAwNjApOiBmZmZmODJj
NDgwMTVjOWZlIC0+IGZmZmY4MmM0ODAyMjRiODMNCihYRU4pIFsyMDEyLTA5LTA1IDE1OjU4
OjQyXSB0cmFwcy5jOjMxNTc6ICBzaG93X2V4ZWN1dGlvbl9zdGF0ZShyZWdzKTogDQooWEVO
KSBbMjAxMi0wOS0wNSAxNTo1ODo0Ml0gLS0tLVsgWGVuLTQuMi4wLXJjNC1wcmUgIHg4Nl82
NCAgZGVidWc9eSAgTm90IHRhaW50ZWQgXS0tLS0NCihYRU4pIFsyMDEyLTA5LTA1IDE1OjU4
OjQyXSBDUFU6ICAgIDMNCihYRU4pIFsyMDEyLTA5LTA1IDE1OjU4OjQyXSBSSVA6ICAgIGUw
MDg6WzxmZmZmODJjNDgwMTVjOWZlPl0gY29udGV4dF9zd2l0Y2grMHgzOTQvMHhlZWINCihY
RU4pIFsyMDEyLTA5LTA1IDE1OjU4OjQyXSBSRkxBR1M6IDAwMDAwMDAwMDAwMTAyNDYgICBD
T05URVhUOiBoeXBlcnZpc29yDQooWEVOKSBbMjAxMi0wOS0wNSAxNTo1ODo0Ml0gcmF4OiAw
MDAwMDAwMDAwMDAwMDAxICAgcmJ4OiBmZmZmODMwMGE1MmQ5MDAwICAgcmN4OiAwMDAwMDAw
MDAwMDAwMDAxDQooWEVOKSBbMjAxMi0wOS0wNSAxNTo1ODo0Ml0gcmR4OiAwMDAwMDAwMDAw
MDAwMDYzICAgcnNpOiAwMDAwMDAwMDAwMDAwMDAxICAgcmRpOiAwMDAwMDAwMDAwMDAwMTVj
DQooWEVOKSBbMjAxMi0wOS0wNSAxNTo1ODo0Ml0gcmJwOiBmZmZmODMwMjRkOGE3ZTI4ICAg
cnNwOiBmZmZmODMwMjRkOGE3ZDg4ICAgcjg6ICAwMDAwMDAwMDAwMDAwMDA2DQooWEVOKSBb
MjAxMi0wOS0wNSAxNTo1ODo0Ml0gcjk6ICBmZmZmODMwMGFmZDA3MDYwICAgcjEwOiAwMDAw
MDAwMGRlYWRiZWVmICAgcjExOiAwMDAwMDAwMDAwMDAwMjQ2DQooWEVOKSBbMjAxMi0wOS0w
NSAxNTo1ODo0Ml0gcjEyOiBmZmZmODMwMGFmZDA3MDAwICAgcjEzOiAwMDAwMDAwMDAwMDAw
MDAzICAgcjE0OiAwMDAwMDAwMDAwMDAwMDAzDQooWEVOKSBbMjAxMi0wOS0wNSAxNTo1ODo0
Ml0gcjE1OiBmZmZmODMwMjRkOGFhMDQ4ICAgY3IwOiAwMDAwMDAwMDgwMDUwMDNiICAgY3I0
OiAwMDAwMDAwMDAwMDAwNmYwDQooWEVOKSBbMjAxMi0wOS0wNSAxNTo1ODo0Ml0gY3IzOiAw
MDAwMDAwMDY4MTQ0MDAwICAgY3IyOiAwMDAwMDAwMGY3NmFkOTM0DQooWEVOKSBbMjAxMi0w
OS0wNSAxNTo1ODo0Ml0gZHM6IDAwMDAgICBlczogMDAwMCAgIGZzOiAwMDAwICAgZ3M6IDAw
MDAgICBzczogZTAxMCAgIGNzOiBlMDA4DQooWEVOKSBbMjAxMi0wOS0wNSAxNTo1ODo0Ml0g
WGVuIHN0YWNrIHRyYWNlIGZyb20gcnNwPWZmZmY4MzAyNGQ4YTdkODg6DQooWEVOKSBbMjAx
Mi0wOS0wNSAxNTo1ODo0Ml0gICAgZmZmZjgzMDI0ZDhhN2RkOCAwMDAwMDAwMDAwMDAwMjgy
IDAwMDAwMDFlNzcyZmQ2ZDkgMDAwMDAwMDAwMDAwMDI4Mg0KKFhFTikgWzIwMTItMDktMDUg
MTU6NTg6NDJdICAgIGZmZmY4MzAwNjViNTEwNjAgZmZmZjgzMDI0ZDhhYTA2MCBmZmZmODMw
MjRkOGE3ZTE4IGZmZmY4MmM0ODAxODA1YmUNCihYRU4pIFsyMDEyLTA5LTA1IDE1OjU4OjQy
XSAgICAwMDAwMDAwMDAwMDAwOTRhIDAwMDAwMWM1YTljZWY5NDIgMDAwMDAwMDAwMDAwMDAw
MCAwMDAwMDAwMDAwMDAwMDAwDQooWEVOKSBbMjAxMi0wOS0wNSAxNTo1ODo0Ml0gICAgMDAw
MDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIGZmZmY4MzAyNGQ4YTdlMjggZmZmZjgz
MDBhZmQwNzAwMA0KKFhFTikgWzIwMTItMDktMDUgMTU6NTg6NDJdICAgIGZmZmY4MzAwYTUy
ZDkwMDAgMDAwMDAwODU3Njk4MzlmMCAwMDAwMDAwMDAwMDAwMDAyIGZmZmY4MzAyNGQ4YWEw
NDgNCihYRU4pIFsyMDEyLTA5LTA1IDE1OjU4OjQyXSAgICBmZmZmODMwMjRkOGE3ZWI4IGZm
ZmY4MmM0ODAxMjRhNzAgMDBmZjgzMDI0ZDhhN2U4OCBmZmZmODMwMjRkOGFhMDQwDQooWEVO
KSBbMjAxMi0wOS0wNSAxNTo1ODo0Ml0gICAgMDAwMDAwMDM4Y2ExNWRjNCAwMDAwMDA4NTc2
OTgzOWYwIGZmZmY4MzAyNGQ4YTdlODggZmZmZmZmZmZmZmZmZmZjMg0KKFhFTikgWzIwMTIt
MDktMDUgMTU6NTg6NDJdICAgIGZmZmY4MzAwYTUyZDkwMDAgMDAwMDAwMDAwMWM5YzM4MCBm
ZmZmODMwMjRkOGE3ZTAwIGZmZmY4MmM0ODAxMjI2Y2UNCihYRU4pIFsyMDEyLTA5LTA1IDE1
OjU4OjQyXSAgICBmZmZmODMwMjRkOGE3ZWY4IGZmZmY4MmM0ODAyZDgxODAgMDAwMDAwMDBm
ZmZmZmZmZiBmZmZmODJjNDgwMmQ4MDAwDQooWEVOKSBbMjAxMi0wOS0wNSAxNTo1ODo0Ml0g
ICAgZmZmZjgzMDI0ZDhhN2YxOCBmZmZmZmZmZmZmZmZmZmZmIGZmZmY4MzAyNGQ4YTdlZjgg
ZmZmZjgyYzQ4MDEyNWUzMQ0KKFhFTikgWzIwMTItMDktMDUgMTU6NTg6NDJdICAgIDAwMDAw
MDAwMDAwMDAyNDYgZmZmZjgzMDBhZmQwNzAwMCBmZmZmZmZmZjgxZWNlNWQ4IDAwMDAwMDAw
MDAwMDAwMDANCihYRU4pIFsyMDEyLTA5LTA1IDE1OjU4OjQyXSAgICAwMDAwMDAwMDAwMDAw
MDAwIDAwMDAwMDAwMDAwMDAwMDAgZmZmZjgzMDI0ZDhhN2YwOCBmZmZmODJjNDgwMTI1ZTY4
DQooWEVOKSBbMjAxMi0wOS0wNSAxNTo1ODo0Ml0gICAgMDAwMDdjZmRiMjc1ODBjNyBmZmZm
ODJjNDgwMjIyZjA2IDAwMDAwMDAwMDAwMDAwMDAgZmZmZmZmZmY4MWUxMzg4MA0KKFhFTikg
WzIwMTItMDktMDUgMTU6NTg6NDJdICAgIDAwMDAwMDAwMDAwMDAwMDAgZmZmZjg4MDAxZDNm
MDBkOCBmZmZmZmZmZjgxZTAxY2U4IGZmZmY4ODAwMWZjMGIxMDANCihYRU4pIFsyMDEyLTA5
LTA1IDE1OjU4OjQyXSAgICAwMDAwMDAwMDAwMDAwMjAyIDAwMDAwMDAwMDAwMDAwMDAgMDAw
MDAwMDAwMDAwMDAwMSAwMDAwMDAwMDAwMDAwMDAwDQooWEVOKSBbMjAxMi0wOS0wNSAxNTo1
ODo0Ml0gICAgMDAwMDAwMDAwMDAwMDAwMCBmZmZmZmZmZjgxMDAxMWFhIGZmZmY4ODAwMWVi
NDAwMDAgMDAwMDAwMDBkZWFkYmVlZg0KKFhFTikgWzIwMTItMDktMDUgMTU6NTg6NDJdICAg
IDAwMDAwMDAwZGVhZGJlZWYgMDAwMDAxMDAwMDAwMDAwMCBmZmZmZmZmZjgxMDAxMWFhIDAw
MDAwMDAwMDAwMGUwMzMNCihYRU4pIFsyMDEyLTA5LTA1IDE1OjU4OjQyXSAgICAwMDAwMDAw
MDAwMDAwMjAyIGZmZmZmZmZmODFlMDFjYjAgMDAwMDAwMDAwMDAwZTAyYiAwMDAwNTNmZDAw
MDBiZWVmDQooWEVOKSBbMjAxMi0wOS0wNSAxNTo1ODo0Ml0gICAgODAwMDAwMDAwMDAwYmVl
ZiA3NDAwMDAwMDAwMDBiZWVmIDAwMDAwMDAwMDAxOGJlZWYgMDAwMDUzZmUwMDAwMDAwMw0K
KFhFTikgWzIwMTItMDktMDUgMTU6NTg6NDJdICAgIGZmZmY4MzAwYTUyZDkwMDAgMDAwMDAw
M2RjZDVhODY4MCAwMDAwMDAwMDAwMThlMGM5DQooWEVOKSBbMjAxMi0wOS0wNSAxNTo1ODo0
Ml0gWGVuIGNhbGwgdHJhY2U6DQooWEVOKSBbMjAxMi0wOS0wNSAxNTo1ODo0Ml0gICAgWzxm
ZmZmODJjNDgwMTVjOWZlPl0gY29udGV4dF9zd2l0Y2grMHgzOTQvMHhlZWINCihYRU4pIFsy
MDEyLTA5LTA1IDE1OjU4OjQyXSAgICBbPGZmZmY4MmM0ODAxMjRhNzA+XSBzY2hlZHVsZSsw
eDY2Ni8weDY3NQ0KKFhFTikgWzIwMTItMDktMDUgMTU6NTg6NDJdICAgIFs8ZmZmZjgyYzQ4
MDEyNWUzMT5dIF9fZG9fc29mdGlycSsweGE0LzB4YjUNCihYRU4pIFsyMDEyLTA5LTA1IDE1
OjU4OjQyXSAgICBbPGZmZmY4MmM0ODAxMjVlNjg+XSBkb19zb2Z0aXJxKzB4MjYvMHgyOA0K
KFhFTikgWzIwMTItMDktMDUgMTU6NTg6NDJdICAgIA0KKFhFTikgWzIwMTItMDktMDUgMTU6
NTg6NDJdIHRyYXBzLmM6MzE1OTogICBzaG93X2V4ZWN1dGlvbl9zdGF0ZShndWVzdF9jcHVf
dXNlcl9yZWdzKCkpOiANCihYRU4pIFsyMDEyLTA5LTA1IDE1OjU4OjQyXSAtLS0tWyBYZW4t
NC4yLjAtcmM0LXByZSAgeDg2XzY0ICBkZWJ1Zz15ICBOb3QgdGFpbnRlZCBdLS0tLQ0KKFhF
TikgWzIwMTItMDktMDUgMTU6NTg6NDJdIENQVTogICAgMw0KKFhFTikgWzIwMTItMDktMDUg
MTU6NTg6NDJdIFJJUDogICAgZTAzMzpbPGZmZmZmZmZmODEwMDExYWE+XQ0KKFhFTikgWzIw
MTItMDktMDUgMTU6NTg6NDJdIFJGTEFHUzogMDAwMDAwMDAwMDAwMDIwMiAgIEVNOiAxICAg
Q09OVEVYVDogcHYgZ3Vlc3QNCihYRU4pIFsyMDEyLTA5LTA1IDE1OjU4OjQyXSByYXg6IDAw
MDAwMDAwMDAwMDAwMDAgICByYng6IGZmZmY4ODAwMWZjMGIxMDAgICByY3g6IGZmZmZmZmZm
ODEwMDExYWENCihYRU4pIFsyMDEyLTA5LTA1IDE1OjU4OjQyXSByZHg6IGZmZmY4ODAwMWVi
NDAwMDAgICByc2k6IDAwMDAwMDAwZGVhZGJlZWYgICByZGk6IDAwMDAwMDAwZGVhZGJlZWYN
CihYRU4pIFsyMDEyLTA5LTA1IDE1OjU4OjQyXSByYnA6IGZmZmZmZmZmODFlMDFjZTggICBy
c3A6IGZmZmZmZmZmODFlMDFjYjAgICByODogIDAwMDAwMDAwMDAwMDAwMDANCihYRU4pIFsy
MDEyLTA5LTA1IDE1OjU4OjQyXSByOTogIDAwMDAwMDAwMDAwMDAwMDEgICByMTA6IDAwMDAw
MDAwMDAwMDAwMDAgICByMTE6IDAwMDAwMDAwMDAwMDAyMDINCihYRU4pIFsyMDEyLTA5LTA1
IDE1OjU4OjQyXSByMTI6IGZmZmY4ODAwMWQzZjAwZDggICByMTM6IDAwMDAwMDAwMDAwMDAw
MDAgICByMTQ6IGZmZmZmZmZmODFlMTM4ODANCihYRU4pIFsyMDEyLTA5LTA1IDE1OjU4OjQy
XSByMTU6IDAwMDAwMDAwMDAwMDAwMDAgICBjcjA6IDAwMDAwMDAwODAwNTAwM2IgICBjcjQ6
IDAwMDAwMDAwMDAwMDA2ZjANCihYRU4pIFsyMDEyLTA5LTA1IDE1OjU4OjQyXSBjcjM6IDAw
MDAwMDAwNjgxNDQwMDAgICBjcjI6IDAwMDAwMDAwZjc2YWQ5MzQNCihYRU4pIFsyMDEyLTA5
LTA1IDE1OjU4OjQyXSBkczogMDAwMCAgIGVzOiAwMDAwICAgZnM6IDAwMDAgICBnczogMDAw
MCAgIHNzOiBlMDJiICAgY3M6IGUwMzMNCihYRU4pIFsyMDEyLTA5LTA1IDE1OjU4OjQyXSBH
dWVzdCBzdGFjayB0cmFjZSBmcm9tIHJzcD1mZmZmZmZmZjgxZTAxY2IwOg0KKFhFTikgWzIw
MTItMDktMDUgMTU6NTg6NDJdICAgIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAw
MSBmZmZmZmZmZjgxMDA0OTQyIGZmZmZmZmZmODFlMTM0MjANCihYRU4pIFsyMDEyLTA5LTA1
IDE1OjU4OjQyXSAgICBmZmZmODgwMDFlYjQwMDAwIDAwMDAwMDAwMDAwMDAwMDAgZmZmZmZm
ZmY4MWUxMzg4MCBmZmZmZmZmZjgxZTAxZDA4DQooWEVOKSBbMjAxMi0wOS0wNSAxNTo1ODo0
Ml0gICAgZmZmZmZmZmY4MTAwMzk0MSBmZmZmODgwMDFlYjQwMDAwIGZmZmZmZmZmODFlMTM0
MjAgZmZmZmZmZmY4MWUwMWQ2OA0KKFhFTikgWzIwMTItMDktMDUgMTU6NTg6NDJdICAgIGZm
ZmZmZmZmODEwMGI4NTAgZmZmZmZmZmY4MWUxMzQyMCAwMDAwMDAwMDAwMDAwMDAxIDAwMDAw
MDAwMDAwMDAwNjMNCihYRU4pIFsyMDEyLTA5LTA1IDE1OjU4OjQyXSAgICBmZmZmODgwMDFm
YzEwYTgwIGZmZmZmZmZmODFlMDFkNzggZmZmZjg4MDAxZmMxMmU4MCAwMDAwMDAwMDAwMDAw
MDAwDQooWEVOKSBbMjAxMi0wOS0wNSAxNTo1ODo0Ml0gICAgZmZmZjg4MDAxY2NkNDkwMCAw
MDAwMDAwMDAwMDAwMDgyIGZmZmZmZmZmODEwZjAwNDAgZmZmZmZmZmY4MWUxMzQyMA0KKFhF
TikgWzIwMTItMDktMDUgMTU6NTg6NDJdICAgIGZmZmZmZmZmODE3ZmEyZjUgZmZmZmZmZmY4
MWUwMWVjOCAwMDAwMDAwMDAwMDAwMjE2IGZmZmY4ODAwMWZjMGU2OTgNCihYRU4pIFsyMDEy
LTA5LTA1IDE1OjU4OjQyXSAgICAwMDAwMDAwMDAwMDAwMDAxIGZmZmZmZmZmODFlMTM0MjAg
MDAwMDAwMDAwMDAxMmU4MCBmZmZmZmZmZjgxZTAxZmQ4DQooWEVOKSBbMjAxMi0wOS0wNSAx
NTo1ODo0Ml0gICAgZmZmZmZmZmY4MWUwMDAxMCAwMDAwMDAwMDAwMDEyZTgwIDAwMDAwMDAw
MDAwMTJlODAgZmZmZmZmZmY4MWUwMWZkOA0KKFhFTikgWzIwMTItMDktMDUgMTU6NTg6NDJd
ICAgIDAwMDAwMDAwMDAwMTJlODAgZmZmZjg4MDAxZWFkMjA4MCBmZmZmZmZmZjgxZTEzNDIw
IGZmZmY4ODAwMWZjMGU4YTANCihYRU4pIFsyMDEyLTA5LTA1IDE1OjU4OjQyXSAgICAwMDAw
MDAwMDAwMDAwMDAwIGZmZmZmZmZmODFlMDFlOTggZmZmZmZmZmY4MTA4YjM4MSAwMDAwMDAw
MDAwMDAwMDAwDQooWEVOKSBbMjAxMi0wOS0wNSAxNTo1ODo0Ml0gICAgZmZmZmZmZmY4MTBh
YjIyMSAwMDAwMDAwMTgxZTAxZTI4IDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDA4MWUwMWU0
OA0KKFhFTikgWzIwMTItMDktMDUgMTU6NTg6NDJdICAgIDAwMDAwMDAwMDAwMDAwNzAgMDAw
MDAwMDAxZmMwZThhMCAwMDAwMDAwMDAwMDBlNjgwIDAwMDAwMDAwMDAwMDAwMDANCihYRU4p
IFsyMDEyLTA5LTA1IDE1OjU4OjQyXSAgICBmZmZmZmZmZjgxZTEzNDIwIGZmZmZmZmZmODEw
YTg2ZmMgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwDQooWEVOKSBbMjAxMi0w
OS0wNSAxNTo1ODo0Ml0gICAgMDAwMDAwMDAwMDAwMDAwMCBmZmZmZmZmZjgxZTAxZTk4IGZm
ZmZmZmZmODEwYWNiNzggZmZmZjg4MDAxZmMwZThhMA0KKFhFTikgWzIwMTItMDktMDUgMTU6
NTg6NDJdICAgIDAwMDAwMDVjOTVhMzk0NWUgZmZmZmZmZmY4MWUwMWVhOCBmZmZmZmZmZjgx
ZTAwMDEwIGZmZmZmZmZmODFlY2U1ZDgNCihYRU4pIFsyMDEyLTA5LTA1IDE1OjU4OjQyXSAg
ICBmZmZmZmZmZjgxZjQyMGMwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCBm
ZmZmZmZmZjgxZTAxZWQ4DQooWEVOKSBbMjAxMi0wOS0wNSAxNTo1ODo0Ml0gICAgZmZmZmZm
ZmY4MTdmYTgxNCBmZmZmZmZmZjgxZTAxZWY4IGZmZmZmZmZmODEwMTY0NTYgMDAwMDAwMDAw
MDAwMDAwMg0KKFhFTikgWzIwMTItMDktMDUgMTU6NTg6NDJdICAgIGZmZmZmZmZmODFmMzk5
MjAgZmZmZmZmZmY4MWUwMWYyOCBmZmZmZmZmZjgxN2Q1YjhjIGZmZmZmZmZmODE3ZDVhZDAN
CihYRU4pIFsyMDEyLTA5LTA1IDE1OjU4OjQyXSAgICBmZmZmODgwMDAwMDAxMDAwIGZmZmZm
ZmZmODFlMDFmMjggMDAwMDAwMDAwMDAwMDAwMCBmZmZmZmZmZjgxZTAxZjc4DQooWEVOKSBb
MjAxMi0wOS0wNSAxNTo1ODo1NV0gdHJhcHMuYzozMTU2OiBHUEYgKDAwNjApOiBmZmZmODJj
NDgwMTVjOWZlIC0+IGZmZmY4MmM0ODAyMjRiODMNCihYRU4pIFsyMDEyLTA5LTA1IDE1OjU4
OjU1XSB0cmFwcy5jOjMxNTc6ICBzaG93X2V4ZWN1dGlvbl9zdGF0ZShyZWdzKTogDQooWEVO
KSBbMjAxMi0wOS0wNSAxNTo1ODo1NV0gLS0tLVsgWGVuLTQuMi4wLXJjNC1wcmUgIHg4Nl82
NCAgZGVidWc9eSAgTm90IHRhaW50ZWQgXS0tLS0NCihYRU4pIFsyMDEyLTA5LTA1IDE1OjU4
OjU1XSBDUFU6ICAgIDMNCihYRU4pIFsyMDEyLTA5LTA1IDE1OjU4OjU1XSBSSVA6ICAgIGUw
MDg6WzxmZmZmODJjNDgwMTVjOWZlPl0gY29udGV4dF9zd2l0Y2grMHgzOTQvMHhlZWINCihY
RU4pIFsyMDEyLTA5LTA1IDE1OjU4OjU1XSBSRkxBR1M6IDAwMDAwMDAwMDAyMTAyMDIgICBD
T05URVhUOiBoeXBlcnZpc29yDQooWEVOKSBbMjAxMi0wOS0wNSAxNTo1ODo1NV0gcmF4OiAw
MDAwMDAwMDAwMDAwMDAxICAgcmJ4OiBmZmZmODMwMGE1MmQ5MDAwICAgcmN4OiAwMDAwMDAw
MDAwMDAwMDAxDQooWEVOKSBbMjAxMi0wOS0wNSAxNTo1ODo1NV0gcmR4OiAwMDAwMDAwMDAw
MDAwMDYzICAgcnNpOiAwMDAwMDAwMDAwMDAwMDAxICAgcmRpOiAwMDAwMDAwMDAwMDAwMWFl
DQooWEVOKSBbMjAxMi0wOS0wNSAxNTo1ODo1NV0gcmJwOiBmZmZmODMwMjRkOGE3ZTI4ICAg
cnNwOiBmZmZmODMwMjRkOGE3ZDg4ICAgcjg6ICAwMDAwMDAwMDAwMDAwMDA2DQooWEVOKSBb
MjAxMi0wOS0wNSAxNTo1ODo1NV0gcjk6ICBmZmZmODMwMjRkOGFhMDYwICAgcjEwOiBmZmZm
ODMwMGFmZDFiMDYwICAgcjExOiAwMDAwMDA4ODgzYTllODM1DQooWEVOKSBbMjAxMi0wOS0w
NSAxNTo1ODo1NV0gcjEyOiBmZmZmODMwMGE1YTcyMDAwICAgcjEzOiAwMDAwMDAwMDAwMDAw
MDAzICAgcjE0OiAwMDAwMDAwMDAwMDAwMDAzDQooWEVOKSBbMjAxMi0wOS0wNSAxNTo1ODo1
NV0gcjE1OiBmZmZmODMwMjRkOGFhMDQ4ICAgY3IwOiAwMDAwMDAwMDgwMDUwMDNiICAgY3I0
OiAwMDAwMDAwMDAwMDAwNmYwDQooWEVOKSBbMjAxMi0wOS0wNSAxNTo1ODo1NV0gY3IzOiAw
MDAwMDAwMDgwOTU3MDAwICAgY3IyOiAwMDAwMDAwMGI3MzgxMDAwDQooWEVOKSBbMjAxMi0w
OS0wNSAxNTo1ODo1NV0gZHM6IDAwMDAgICBlczogMDAwMCAgIGZzOiAwMDAwICAgZ3M6IDAw
NjMgICBzczogMDAwMCAgIGNzOiBlMDA4DQooWEVOKSBbMjAxMi0wOS0wNSAxNTo1ODo1NV0g
WGVuIHN0YWNrIHRyYWNlIGZyb20gcnNwPWZmZmY4MzAyNGQ4YTdkODg6DQooWEVOKSBbMjAx
Mi0wOS0wNSAxNTo1ODo1NV0gICAgMDAwMDAwMDAwMDAwMDBhYiBmZmZmODJmNjAwY2I2YTIw
IDAwMDAwMDFlYTU2OTQwMDAgMDAwMDAwMDAwMDAwMDAwMA0KKFhFTikgWzIwMTItMDktMDUg
MTU6NTg6NTVdICAgIGZmZmY4MzAwNjViNTEwNjAgZmZmZjgzMDI0ZDhhYTA2MCBmZmZmODMw
MjRkOGE3ZTE4IGZmZmY4MmM0ODAxODA1YmUNCihYRU4pIFsyMDEyLTA5LTA1IDE1OjU4OjU1
XSAgICAwMDAwMDAwMDAwMDAwOWFhIDAwMDAwMWNmNTljNjdhN2EgMDAwMDAwMDAwMDAwMDAw
MCAwMDAwMDAwMDAwMDAwMDAwDQooWEVOKSBbMjAxMi0wOS0wNSAxNTo1ODo1NV0gICAgMDAw
MDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIGZmZmY4MzAyNGQ4YTdlMjggZmZmZjgz
MDBhNWE3MjAwMA0KKFhFTikgWzIwMTItMDktMDUgMTU6NTg6NTVdICAgIGZmZmY4MzAwYTUy
ZDkwMDAgMDAwMDAwODg4MzgxYmY1NiAwMDAwMDAwMDAwMDAwMDAzIGZmZmY4MzAyNGQ4YWEw
NDgNCihYRU4pIFsyMDEyLTA5LTA1IDE1OjU4OjU1XSAgICBmZmZmODMwMjRkOGE3ZWI4IGZm
ZmY4MmM0ODAxMjRhNzAgMDBmZjgzMDI0ZDhhN2U2OCBmZmZmODMwMjRkOGFhMDQwDQooWEVO
KSBbMjAxMi0wOS0wNSAxNTo1ODo1NV0gICAgMDAwMDAwMDM0ZDhhN2U2OCAwMDAwMDA4ODgz
ODFiZjU2IGZmZmY4MzAyNGQ4YTdlNzggZmZmZjgyYzQ4MDFiZTM4OA0KKFhFTikgWzIwMTIt
MDktMDUgMTU6NTg6NTVdICAgIGZmZmY4MzAwYTUyZDkwMDAgMDAwMDAwMDAwMWM5YzM4MCBm
ZmZmODMwMjRkOGE3ZTAwIGZmZmY4MmM0ODAxYjg3MGQNCihYRU4pIFsyMDEyLTA5LTA1IDE1
OjU4OjU1XSAgICBmZmZmODMwMGE1YTcyMDAwIGZmZmY4MmM0ODAyZDgxODAgMDAwMDAwMDBm
ZmZmZmZmZiBmZmZmODJjNDgwMmQ4MDAwDQooWEVOKSBbMjAxMi0wOS0wNSAxNTo1ODo1NV0g
ICAgZmZmZjgzMDI0ZDhhN2YxOCBmZmZmZmZmZmZmZmZmZmZmIGZmZmY4MzAyNGQ4YTdlZjgg
ZmZmZjgyYzQ4MDEyNWUzMQ0KKFhFTikgWzIwMTItMDktMDUgMTU6NTg6NTVdICAgIGZmZmY4
MzAyNGQ4YTdlZDggZmZmZjgzMDBhNWE3MjAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAw
MDAwMDAwMDANCihYRU4pIFsyMDEyLTA5LTA1IDE1OjU4OjU1XSAgICAwMDAwMDAwMDAwMDAw
MDAwIDAwMDAwMDAwMDAwMDAwMDAgZmZmZjgzMDI0ZDhhN2YwOCBmZmZmODJjNDgwMTI1ZTY4
DQooWEVOKSBbMjAxMi0wOS0wNSAxNTo1ODo1NV0gICAgMDAwMDAwMDBkZTBhMWY4YSBmZmZm
ODJjNDgwMWNiNWQyIDAwMDAwMDAwMDAwMDAwMDAgZmZmZmZmZmY4MWUxMzg4MA0KKFhFTikg
WzIwMTItMDktMDUgMTU6NTg6NTVdICAgIDAwMDAwMDAwMDAwMDAwMDAgZmZmZjg4MDAwYjlj
MDBkOCBmZmZmZmZmZjgxZTAxY2U4IGZmZmY4ODAwMWZjMGIxMDANCihYRU4pIFsyMDEyLTA5
LTA1IDE1OjU4OjU1XSAgICAwMDAwMDAwMDAwMjAwMjAyIDAwMDAwMDAwMDAwMDAwMDAgMDAw
MDAwMDAwMDAwMDAwMSAwMDAwMDAwMDAwMDAwMDAwDQooWEVOKSBbMjAxMi0wOS0wNSAxNTo1
ODo1NV0gICAgMDAwMDAwMDAwMDAwMDAwMCBmZmZmZmZmZjgxMDAxMWFhIGZmZmY4ODAwMWVi
NDEwNDAgMDAwMDAwMDBkZWFkYmVlZg0KKFhFTikgWzIwMTItMDktMDUgMTU6NTg6NTVdICAg
IDAwMDAwMDAwZGVhZGJlZWYgMDAwMDAxMDAwMDAwMDAwMCBmZmZmZmZmZjgxMDAxMWFhIDAw
MDAwMDAwMDAwMGUwMzMNCihYRU4pIFsyMDEyLTA5LTA1IDE1OjU4OjU1XSAgICAwMDAwMDAw
MDAwMjAwMjAyIGZmZmZmZmZmODFlMDFjYjAgMDAwMDAwMDAwMDAwZTAyYiAwMDAwNTNmZDAw
MDBiZWVmDQooWEVOKSBbMjAxMi0wOS0wNSAxNTo1ODo1NV0gICAgODAwMDAwMDAwMDAwYmVl
ZiA3NDAwMDAwMDAwMDBiZWVmIDAwMDAwMDAwMDAxOGJlZWYgMDAwMDUzZmUwMDAwMDAwMw0K
KFhFTikgWzIwMTItMDktMDUgMTU6NTg6NTVdICAgIGZmZmY4MzAwYTUyZDkwMDAgMDAwMDAw
M2RjZDVhODY4MCAwMDAwMDAwMDAwMThlMGM5DQooWEVOKSBbMjAxMi0wOS0wNSAxNTo1ODo1
NV0gWGVuIGNhbGwgdHJhY2U6DQooWEVOKSBbMjAxMi0wOS0wNSAxNTo1ODo1NV0gICAgWzxm
ZmZmODJjNDgwMTVjOWZlPl0gY29udGV4dF9zd2l0Y2grMHgzOTQvMHhlZWINCihYRU4pIFsy
MDEyLTA5LTA1IDE1OjU4OjU1XSAgICBbPGZmZmY4MmM0ODAxMjRhNzA+XSBzY2hlZHVsZSsw
eDY2Ni8weDY3NQ0KKFhFTikgWzIwMTItMDktMDUgMTU6NTg6NTVdICAgIFs8ZmZmZjgyYzQ4
MDEyNWUzMT5dIF9fZG9fc29mdGlycSsweGE0LzB4YjUNCihYRU4pIFsyMDEyLTA5LTA1IDE1
OjU4OjU1XSAgICBbPGZmZmY4MmM0ODAxMjVlNjg+XSBkb19zb2Z0aXJxKzB4MjYvMHgyOA0K
KFhFTikgWzIwMTItMDktMDUgMTU6NTg6NTVdICAgIA0KKFhFTikgWzIwMTItMDktMDUgMTU6
NTg6NTVdIHRyYXBzLmM6MzE1OTogICBzaG93X2V4ZWN1dGlvbl9zdGF0ZShndWVzdF9jcHVf
dXNlcl9yZWdzKCkpOiANCihYRU4pIFsyMDEyLTA5LTA1IDE1OjU4OjU1XSAtLS0tWyBYZW4t
NC4yLjAtcmM0LXByZSAgeDg2XzY0ICBkZWJ1Zz15ICBOb3QgdGFpbnRlZCBdLS0tLQ0KKFhF
TikgWzIwMTItMDktMDUgMTU6NTg6NTVdIENQVTogICAgMw0KKFhFTikgWzIwMTItMDktMDUg
MTU6NTg6NTVdIFJJUDogICAgZTAzMzpbPGZmZmZmZmZmODEwMDExYWE+XQ0KKFhFTikgWzIw
MTItMDktMDUgMTU6NTg6NTVdIFJGTEFHUzogMDAwMDAwMDAwMDIwMDIwMiAgIEVNOiAxICAg
Q09OVEVYVDogcHYgZ3Vlc3QNCihYRU4pIFsyMDEyLTA5LTA1IDE1OjU4OjU1XSByYXg6IDAw
MDAwMDAwMDAwMDAwMDAgICByYng6IGZmZmY4ODAwMWZjMGIxMDAgICByY3g6IGZmZmZmZmZm
ODEwMDExYWENCihYRU4pIFsyMDEyLTA5LTA1IDE1OjU4OjU1XSByZHg6IGZmZmY4ODAwMWVi
NDEwNDAgICByc2k6IDAwMDAwMDAwZGVhZGJlZWYgICByZGk6IDAwMDAwMDAwZGVhZGJlZWYN
CihYRU4pIFsyMDEyLTA5LTA1IDE1OjU4OjU1XSByYnA6IGZmZmZmZmZmODFlMDFjZTggICBy
c3A6IGZmZmZmZmZmODFlMDFjYjAgICByODogIDAwMDAwMDAwMDAwMDAwMDANCihYRU4pIFsy
MDEyLTA5LTA1IDE1OjU4OjU1XSByOTogIDAwMDAwMDAwMDAwMDAwMDEgICByMTA6IDAwMDAw
MDAwMDAwMDAwMDAgICByMTE6IDAwMDAwMDAwMDAyMDAyMDINCihYRU4pIFsyMDEyLTA5LTA1
IDE1OjU4OjU1XSByMTI6IGZmZmY4ODAwMGI5YzAwZDggICByMTM6IDAwMDAwMDAwMDAwMDAw
MDAgICByMTQ6IGZmZmZmZmZmODFlMTM4ODANCihYRU4pIFsyMDEyLTA5LTA1IDE1OjU4OjU1
XSByMTU6IDAwMDAwMDAwMDAwMDAwMDAgICBjcjA6IDAwMDAwMDAwODAwNTAwM2IgICBjcjQ6
IDAwMDAwMDAwMDAwMDA2ZjANCihYRU4pIFsyMDEyLTA5LTA1IDE1OjU4OjU1XSBjcjM6IDAw
MDAwMDAwODA5NTcwMDAgICBjcjI6IDAwMDAwMDAwMGMyNmMwMmMNCihYRU4pIFsyMDEyLTA5
LTA1IDE1OjU4OjU1XSBkczogMDAwMCAgIGVzOiAwMDAwICAgZnM6IDAwMDAgICBnczogMDA2
MyAgIHNzOiBlMDJiICAgY3M6IGUwMzMNCihYRU4pIFsyMDEyLTA5LTA1IDE1OjU4OjU1XSBH
dWVzdCBzdGFjayB0cmFjZSBmcm9tIHJzcD1mZmZmZmZmZjgxZTAxY2IwOg0KKFhFTikgWzIw
MTItMDktMDUgMTU6NTg6NTVdICAgIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAw
MSBmZmZmZmZmZjgxMDA0OTQyIGZmZmZmZmZmODFlMTM0MjANCihYRU4pIFsyMDEyLTA5LTA1
IDE1OjU4OjU1XSAgICBmZmZmODgwMDFlYjQxMDQwIDAwMDAwMDAwMDAwMDAwMDAgZmZmZmZm
ZmY4MWUxMzg4MCBmZmZmZmZmZjgxZTAxZDA4DQooWEVOKSBbMjAxMi0wOS0wNSAxNTo1ODo1
NV0gICAgZmZmZmZmZmY4MTAwMzk0MSBmZmZmODgwMDFlYjQxMDQwIGZmZmZmZmZmODFlMTM0
MjAgZmZmZmZmZmY4MWUwMWQ2OA0KKFhFTikgWzIwMTItMDktMDUgMTU6NTg6NTVdICAgIGZm
ZmZmZmZmODEwMGI4NTAgZmZmZmZmZmY4MWUxMzQyMCAwMDAwMDAwMDAwMDAwMDAxIDAwMDAw
MDAwMDAwMDAwNjMNCihYRU4pIFsyMDEyLTA5LTA1IDE1OjU4OjU1XSAgICBmZmZmODgwMDFm
YzEwYTgwIGZmZmZmZmZmODFlMDFkNzggZmZmZjg4MDAxZmMxMmU4MCAwMDAwMDAwMDAwMDAw
MDAwDQooWEVOKSBbMjAxMi0wOS0wNSAxNTo1ODo1NV0gICAgZmZmZjg4MDAxY2NkNWY4MCAw
MDAwMDAwMDAwMDAwMDgyIGZmZmZmZmZmODEwZjAwNDAgZmZmZmZmZmY4MWUxMzQyMA0KKFhF
TikgWzIwMTItMDktMDUgMTU6NTg6NTVdICAgIGZmZmZmZmZmODE3ZmEyZjUgZmZmZmZmZmY4
MWUwMWVjOCAwMDAwMDAwMDAwMDAwMjE2IGZmZmY4ODAwMWZjMGU2OTgNCihYRU4pIFsyMDEy
LTA5LTA1IDE1OjU4OjU1XSAgICAwMDAwMDAwMDAwMDAwMDAxIGZmZmZmZmZmODFlMTM0MjAg
MDAwMDAwMDAwMDAxMmU4MCBmZmZmZmZmZjgxZTAxZmQ4DQooWEVOKSBbMjAxMi0wOS0wNSAx
NTo1ODo1NV0gICAgZmZmZmZmZmY4MWUwMDAxMCAwMDAwMDAwMDAwMDEyZTgwIDAwMDAwMDAw
MDAwMTJlODAgZmZmZmZmZmY4MWUwMWZkOA0KKFhFTikgWzIwMTItMDktMDUgMTU6NTg6NTVd
ICAgIDAwMDAwMDAwMDAwMTJlODAgZmZmZjg4MDAxZWFkMjA4MCBmZmZmZmZmZjgxZTEzNDIw
IGZmZmY4ODAwMWZjMGU4YTANCihYRU4pIFsyMDEyLTA5LTA1IDE1OjU4OjU1XSAgICAwMDAw
MDAwMDAwMDAwMDAwIGZmZmZmZmZmODFlMDFlOTggZmZmZmZmZmY4MTA4YjM4MSAwMDAwMDAw
MDAwMDAwMDAxDQooWEVOKSBbMjAxMi0wOS0wNSAxNTo1ODo1NV0gICAgZmZmZmZmZmY4MTBh
YjIyMSAwMDAwMDAwMTgxZTAxZTI4IDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDA4MWUwMWU0
OA0KKFhFTikgWzIwMTItMDktMDUgMTU6NTg6NTVdICAgIDAwMDAwMDAwMDAwMDAwNzAgMDAw
MDAwMDAxZmMwZThhMCAwMDAwMDAwMDAwMDBlNjgwIDAwMDAwMDAwMDAwMDAwMDANCihYRU4p
IFsyMDEyLTA5LTA1IDE1OjU4OjU1XSAgICBmZmZmZmZmZjgxZTEzNDIwIGZmZmZmZmZmODEw
YTg2ZmMgMDAwMDAwMDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwDQooWEVOKSBbMjAxMi0w
OS0wNSAxNTo1ODo1NV0gICAgMDAwMDAwMDAwMDAwMDAwMCBmZmZmZmZmZjgxZTAxZTk4IGZm
ZmZmZmZmODEwYWNiNzggZmZmZjg4MDAxZmMwZThhMA0KKFhFTikgWzIwMTItMDktMDUgMTU6
NTg6NTVdICAgIDAwMDAwMDVmYTRhMDA4NzYgZmZmZmZmZmY4MWUwMWVhOCBmZmZmZmZmZjgx
ZTAwMDEwIGZmZmZmZmZmODFlY2U1ZDgNCihYRU4pIFsyMDEyLTA5LTA1IDE1OjU4OjU1XSAg
ICBmZmZmZmZmZjgxZjQyMGMwIDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCBm
ZmZmZmZmZjgxZTAxZWQ4DQooWEVOKSBbMjAxMi0wOS0wNSAxNTo1ODo1NV0gICAgZmZmZmZm
ZmY4MTdmYTgxNCBmZmZmZmZmZjgxZTAxZWY4IGZmZmZmZmZmODEwMTY0NTYgMDAwMDAwMDAw
MDAwMDAwMg0KKFhFTikgWzIwMTItMDktMDUgMTU6NTg6NTVdICAgIGZmZmZmZmZmODFmMzk5
MjAgZmZmZmZmZmY4MWUwMWYyOCBmZmZmZmZmZjgxN2Q1YjhjIGZmZmZmZmZmODE3ZDVhZDAN
CihYRU4pIFsyMDEyLTA5LTA1IDE1OjU4OjU1XSAgICBmZmZmODgwMDAwMDAxMDAwIGZmZmZm
ZmZmODFlMDFmMjggMDAwMDAwMDAwMDAwMDAwMCBmZmZmZmZmZjgxZTAxZjc4DQooWEVOKSBb
MjAxMi0wOS0wNSAxOToxMTozNl0gZ3JhbnRfdGFibGUuYzoyNTQ6ZDAgSW5jcmVhc2VkIG1h
cHRyYWNrIHNpemUgdG8gMiBmcmFtZXMNCihYRU4pIFsyMDEyLTA5LTA1IDIwOjU0OjE2XSBB
TUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MGEwNiwg
ZmF1bHQgYWRkcmVzcyA9IDB4YzJjMmMyYzAsIGZsYWdzID0gMHgwMDANCihYRU4pIFsyMDEy
LTA5LTA1IDIwOjU0OjE2XSBBTUQtVmk6IElPX1BBR0VfRkFVTFQ6IGRvbWFpbiA9IDE0LCBk
ZXZpY2UgaWQgPSAweDA3MDAsIGZhdWx0IGFkZHJlc3MgPSAweGE4ZDMzOWUwLCBmbGFncyA9
IDB4MDIwDQooWEVOKSBbMjAxMi0wOS0wNSAyMDo1NDoxNl0gQU1ELVZpOiBJT19QQUdFX0ZB
VUxUOiBkb21haW4gPSAxNCwgZGV2aWNlIGlkID0gMHgwNzAwLCBmYXVsdCBhZGRyZXNzID0g
MHhhOGQzM2E0MCwgZmxhZ3MgPSAweDAyMA0K
------------0F617E023294CEA4E
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

------------0F617E023294CEA4E--



From xen-devel-bounces@lists.xen.org Wed Sep 05 23:57:00 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Sep 2012 23:57: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 1T9PSM-0007lO-U8; Wed, 05 Sep 2012 23:56:26 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <james.harper@bendigoit.com.au>) id 1T9PSL-0007lJ-4U
	for xen-devel@lists.xen.org; Wed, 05 Sep 2012 23:56:25 +0000
Received: from [85.158.143.99:14168] by server-3.bemta-4.messagelabs.com id
	9E/E9-08232-8A6E7405; Wed, 05 Sep 2012 23:56:24 +0000
X-Env-Sender: james.harper@bendigoit.com.au
X-Msg-Ref: server-7.tower-216.messagelabs.com!1346889380!25407372!1
X-Originating-IP: [203.16.224.4]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19049 invoked from network); 5 Sep 2012 23:56:23 -0000
Received: from smtp1.bendigoit.com.au (HELO smtp1.bendigoit.com.au)
	(203.16.224.4)
	by server-7.tower-216.messagelabs.com with AES256-SHA encrypted SMTP;
	5 Sep 2012 23:56:23 -0000
Received: from [2001:388:e000:712:a5ca:4fd3:14f:ad5d]
	(helo=BITCOM1.int.sbss.com.au)
	by smtp1.bendigoit.com.au with esmtp (Exim 4.69)
	(envelope-from <james.harper@bendigoit.com.au>)
	id 1T9PSB-0000DT-Bs; Thu, 06 Sep 2012 09:56:15 +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 id
	14.01.0379.000; Thu, 6 Sep 2012 09:56:09 +1000
From: James Harper <james.harper@bendigoit.com.au>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Thread-Topic: [Xen-devel] bug when using 4K sectors?
Thread-Index: Ac15XJ9mOEWrLpZlQnymzekcRdWXAQR9LPqAABwcDwA=
Date: Wed, 5 Sep 2012 23:56:08 +0000
Message-ID: <6035A0D088A63A46850C3988ED045A4B29B5D23E@BITCOM1.int.sbss.com.au>
References: <6035A0D088A63A46850C3988ED045A4B299F74F8@BITCOM1.int.sbss.com.au>
	<20120905202927.GD27814@phenom.dumpdata.com>
In-Reply-To: <20120905202927.GD27814@phenom.dumpdata.com>
Accept-Language: en-AU, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [2001:388:e000:712:5e4:3634:9056:495f]
x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19166.002
x-tm-as-result: No--36.993100-0.000000-31
x-tm-as-user-approved-sender: Yes
x-tm-as-user-blocked-sender: No
MIME-Version: 1.0
X-Really-From-Bendigo-IT: magichashvalue
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] bug when using 4K sectors?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> On Mon, Aug 13, 2012 at 02:12:58PM +0000, James Harper wrote:
> > I notice this code in drivers/block/xen-blkback/common.h
> >
> > #define vbd_sz(_v)      ((_v)->bdev->bd_part ? \
> >                          (_v)->bdev->bd_part->nr_sects : \
> >                           get_capacity((_v)->bdev->bd_disk))
> >
> > is the value returned by vbd_sz(_v) the number of sectors in the Linux
> > device (eg size / 4096), or the number of 512 byte sectors? I suspect
> > the former which is causing block requests beyond 1/8th the size of
> > the device to fail (assuming 4K sectors are expected to work at all -
> > I can't quite get my head around how it would be expected to work -
> > does Linux do the read-modify-write if required?)
> 
> I think you need to instrument it to be sure.. But more interesting, do you
> actually have a disk that exposes a 4KB hardware and logical sector? So far
> I've only found SSDs that expose a 512kB logical sector but also expose the
> 4KB hardware.
> 
> Never could figure out how that is all suppose to work as the blkback is filled
> with << 9 on a bunch of things.
> 

I was using bcache which does expose a 4K block size, by default. I changed it to 512 and it all works now, although I haven't tested if there is any loss of performance.

Does Xen provide a way to tell Windows that the underlying device is 512e (4K sector with 512 byte emulated interface)? This would keep everything working as is but allow windows to align writes to 4K boundaries where possible.

James

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

From xen-devel-bounces@lists.xen.org Wed Sep 05 23:57:00 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 05 Sep 2012 23:57: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 1T9PSM-0007lO-U8; Wed, 05 Sep 2012 23:56:26 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <james.harper@bendigoit.com.au>) id 1T9PSL-0007lJ-4U
	for xen-devel@lists.xen.org; Wed, 05 Sep 2012 23:56:25 +0000
Received: from [85.158.143.99:14168] by server-3.bemta-4.messagelabs.com id
	9E/E9-08232-8A6E7405; Wed, 05 Sep 2012 23:56:24 +0000
X-Env-Sender: james.harper@bendigoit.com.au
X-Msg-Ref: server-7.tower-216.messagelabs.com!1346889380!25407372!1
X-Originating-IP: [203.16.224.4]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19049 invoked from network); 5 Sep 2012 23:56:23 -0000
Received: from smtp1.bendigoit.com.au (HELO smtp1.bendigoit.com.au)
	(203.16.224.4)
	by server-7.tower-216.messagelabs.com with AES256-SHA encrypted SMTP;
	5 Sep 2012 23:56:23 -0000
Received: from [2001:388:e000:712:a5ca:4fd3:14f:ad5d]
	(helo=BITCOM1.int.sbss.com.au)
	by smtp1.bendigoit.com.au with esmtp (Exim 4.69)
	(envelope-from <james.harper@bendigoit.com.au>)
	id 1T9PSB-0000DT-Bs; Thu, 06 Sep 2012 09:56:15 +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 id
	14.01.0379.000; Thu, 6 Sep 2012 09:56:09 +1000
From: James Harper <james.harper@bendigoit.com.au>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Thread-Topic: [Xen-devel] bug when using 4K sectors?
Thread-Index: Ac15XJ9mOEWrLpZlQnymzekcRdWXAQR9LPqAABwcDwA=
Date: Wed, 5 Sep 2012 23:56:08 +0000
Message-ID: <6035A0D088A63A46850C3988ED045A4B29B5D23E@BITCOM1.int.sbss.com.au>
References: <6035A0D088A63A46850C3988ED045A4B299F74F8@BITCOM1.int.sbss.com.au>
	<20120905202927.GD27814@phenom.dumpdata.com>
In-Reply-To: <20120905202927.GD27814@phenom.dumpdata.com>
Accept-Language: en-AU, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [2001:388:e000:712:5e4:3634:9056:495f]
x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19166.002
x-tm-as-result: No--36.993100-0.000000-31
x-tm-as-user-approved-sender: Yes
x-tm-as-user-blocked-sender: No
MIME-Version: 1.0
X-Really-From-Bendigo-IT: magichashvalue
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] bug when using 4K sectors?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> On Mon, Aug 13, 2012 at 02:12:58PM +0000, James Harper wrote:
> > I notice this code in drivers/block/xen-blkback/common.h
> >
> > #define vbd_sz(_v)      ((_v)->bdev->bd_part ? \
> >                          (_v)->bdev->bd_part->nr_sects : \
> >                           get_capacity((_v)->bdev->bd_disk))
> >
> > is the value returned by vbd_sz(_v) the number of sectors in the Linux
> > device (eg size / 4096), or the number of 512 byte sectors? I suspect
> > the former which is causing block requests beyond 1/8th the size of
> > the device to fail (assuming 4K sectors are expected to work at all -
> > I can't quite get my head around how it would be expected to work -
> > does Linux do the read-modify-write if required?)
> 
> I think you need to instrument it to be sure.. But more interesting, do you
> actually have a disk that exposes a 4KB hardware and logical sector? So far
> I've only found SSDs that expose a 512kB logical sector but also expose the
> 4KB hardware.
> 
> Never could figure out how that is all suppose to work as the blkback is filled
> with << 9 on a bunch of things.
> 

I was using bcache which does expose a 4K block size, by default. I changed it to 512 and it all works now, although I haven't tested if there is any loss of performance.

Does Xen provide a way to tell Windows that the underlying device is 512e (4K sector with 512 byte emulated interface)? This would keep everything working as is but allow windows to align writes to 4K boundaries where possible.

James

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

From xen-devel-bounces@lists.xen.org Thu Sep 06 00:28:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 2012 00: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 1T9Pwf-00004q-F2; Thu, 06 Sep 2012 00:27: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 1T9Pwd-0008WR-CO
	for xen-devel@lists.xensource.com; Thu, 06 Sep 2012 00:27:43 +0000
Received: from [85.158.143.35:22048] by server-3.bemta-4.messagelabs.com id
	FC/19-08232-EFDE7405; Thu, 06 Sep 2012 00:27:42 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1346891261!13511591!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTE5NjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13354 invoked from network); 6 Sep 2012 00:27:41 -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;
	6 Sep 2012 00:27:41 -0000
X-IronPort-AV: E=Sophos;i="4.80,377,1344211200"; d="scan'208";a="14371115"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Sep 2012 00:27: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.279.1; Thu, 6 Sep 2012 01:27: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 1T9Pwa-0008KO-Jg;
	Thu, 06 Sep 2012 00:27:40 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1T9PwY-0001x3-25;
	Thu, 06 Sep 2012 01:27:40 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-13651-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 6 Sep 2012 01:27:38 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.1-testing test] 13651: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 13651 xen-4.1-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13651/

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. 13646

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-amd64-xl-sedf-pin  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pv           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-amd64-xl           1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf      1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-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-amd64-pair         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-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 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-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-win          1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 xen-build-check(1)         blocked n/a
 test-amd64-amd64-xl-win       1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-qemuu-winxpsp3 13 guest-stop                 fail never pass
 test-amd64-amd64-xl-winxpsp3  1 xen-build-check(1)           blocked  n/a

version targeted for testing:
 xen                  3e4782f17f5c
baseline version:
 xen                  d28a9ba889c0

------------------------------------------------------------
People who touched revisions under test:
  Ian Campbell <ian.campbell@citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Keir Fraser <keir@xen.org>
  Tim Deegan <tim@xen.org>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            fail    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          blocked 
 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                         blocked 
 test-amd64-amd64-xl-win7-amd64                               blocked 
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              blocked 
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        blocked 
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 blocked 
 test-amd64-amd64-pv                                          blocked 
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     blocked 
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         blocked 
 test-amd64-i386-win                                          fail    
 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                                fail    
 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.

------------------------------------------------------------
changeset:   23353:3e4782f17f5c
tag:         tip
user:        Ian Jackson <Ian.Jackson@eu.citrix.com>
date:        Wed Sep 05 12:40:10 2012 +0100
    
    QEMU_TAG update (XSA-17 / CVE-2012-3515)
    
    
changeset:   23352:936f63ee4dad
user:        Ian Jackson <Ian.Jackson@eu.citrix.com>
date:        Wed Sep 05 12:29:56 2012 +0100
    
    x86/pvhvm: properly range-check PHYSDEVOP_map_pirq/MAP_PIRQ_TYPE_GSI
    
    This is being used as a array index, and hence must be validated before
    use.
    
    This is XSA-16 / CVE-2012-3498.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    
    
changeset:   23351:8ebda5388e4e
user:        Ian Jackson <Ian.Jackson@eu.citrix.com>
date:        Wed Sep 05 12:29:05 2012 +0100
    
    xen: Don't BUG_ON() PoD operations on a non-translated guest.
    
    This is XSA-14 / CVE-2012-3496
    
    Signed-off-by: Tim Deegan <tim@xen.org>
    Reviewed-by: Ian Campbell <ian.campbell@citrix.com>
    Tested-by: Ian Campbell <ian.campbell@citrix.com>
    
    
changeset:   23350:6779ddca8593
user:        Ian Jackson <Ian.Jackson@eu.citrix.com>
date:        Wed Sep 05 12:28:17 2012 +0100
    
    xen: handle out-of-pirq condition correctly in PHYSDEVOP_get_free_pirq
    
    This is XSA-13 / CVE-2012-3495
    
    Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
    Signed-off-by: Jan Beulich <JBeulich@suse.com>
    
    
changeset:   23349:bcc340292731
user:        Ian Jackson <Ian.Jackson@eu.citrix.com>
date:        Wed Sep 05 12:27:54 2012 +0100
    
    xen: prevent a 64 bit guest setting reserved bits in DR7
    
    The upper 32 bits of this register are reserved and should be written as
    zero.
    
    This is XSA-12 / CVE-2012-3494
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Reviewed-by: Ian Campbell <ian.campbell@citrix.com>
    
    
changeset:   23348:d28a9ba889c0
user:        Jan Beulich <jbeulich@suse.com>
date:        Tue Sep 04 14:56:48 2012 +0200
    
    make all (native) hypercalls consistently have "long" return type
    
    for common and x86 ones at least, to address the problem of storing
    zero-extended values into the multicall result field otherwise.
    
    Reported-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    xen-unstable changeset: 25744:47080c965937
    xen-unstable date: Fri Aug 10 07:51:01 UTC 2012
    
    
(qemu changes not included)

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

From xen-devel-bounces@lists.xen.org Thu Sep 06 00:28:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 2012 00: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 1T9Pwf-00004q-F2; Thu, 06 Sep 2012 00:27: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 1T9Pwd-0008WR-CO
	for xen-devel@lists.xensource.com; Thu, 06 Sep 2012 00:27:43 +0000
Received: from [85.158.143.35:22048] by server-3.bemta-4.messagelabs.com id
	FC/19-08232-EFDE7405; Thu, 06 Sep 2012 00:27:42 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1346891261!13511591!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTE5NjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13354 invoked from network); 6 Sep 2012 00:27:41 -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;
	6 Sep 2012 00:27:41 -0000
X-IronPort-AV: E=Sophos;i="4.80,377,1344211200"; d="scan'208";a="14371115"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Sep 2012 00:27: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.279.1; Thu, 6 Sep 2012 01:27: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 1T9Pwa-0008KO-Jg;
	Thu, 06 Sep 2012 00:27:40 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1T9PwY-0001x3-25;
	Thu, 06 Sep 2012 01:27:40 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-13651-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 6 Sep 2012 01:27:38 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.1-testing test] 13651: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 13651 xen-4.1-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13651/

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. 13646

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-amd64-xl-sedf-pin  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pv           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-amd64-xl           1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf      1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-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-amd64-pair         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-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 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-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-win          1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 xen-build-check(1)         blocked n/a
 test-amd64-amd64-xl-win       1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-qemuu-winxpsp3 13 guest-stop                 fail never pass
 test-amd64-amd64-xl-winxpsp3  1 xen-build-check(1)           blocked  n/a

version targeted for testing:
 xen                  3e4782f17f5c
baseline version:
 xen                  d28a9ba889c0

------------------------------------------------------------
People who touched revisions under test:
  Ian Campbell <ian.campbell@citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Keir Fraser <keir@xen.org>
  Tim Deegan <tim@xen.org>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            fail    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          blocked 
 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                         blocked 
 test-amd64-amd64-xl-win7-amd64                               blocked 
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              blocked 
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        blocked 
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 blocked 
 test-amd64-amd64-pv                                          blocked 
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     blocked 
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         blocked 
 test-amd64-i386-win                                          fail    
 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                                fail    
 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.

------------------------------------------------------------
changeset:   23353:3e4782f17f5c
tag:         tip
user:        Ian Jackson <Ian.Jackson@eu.citrix.com>
date:        Wed Sep 05 12:40:10 2012 +0100
    
    QEMU_TAG update (XSA-17 / CVE-2012-3515)
    
    
changeset:   23352:936f63ee4dad
user:        Ian Jackson <Ian.Jackson@eu.citrix.com>
date:        Wed Sep 05 12:29:56 2012 +0100
    
    x86/pvhvm: properly range-check PHYSDEVOP_map_pirq/MAP_PIRQ_TYPE_GSI
    
    This is being used as a array index, and hence must be validated before
    use.
    
    This is XSA-16 / CVE-2012-3498.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    
    
changeset:   23351:8ebda5388e4e
user:        Ian Jackson <Ian.Jackson@eu.citrix.com>
date:        Wed Sep 05 12:29:05 2012 +0100
    
    xen: Don't BUG_ON() PoD operations on a non-translated guest.
    
    This is XSA-14 / CVE-2012-3496
    
    Signed-off-by: Tim Deegan <tim@xen.org>
    Reviewed-by: Ian Campbell <ian.campbell@citrix.com>
    Tested-by: Ian Campbell <ian.campbell@citrix.com>
    
    
changeset:   23350:6779ddca8593
user:        Ian Jackson <Ian.Jackson@eu.citrix.com>
date:        Wed Sep 05 12:28:17 2012 +0100
    
    xen: handle out-of-pirq condition correctly in PHYSDEVOP_get_free_pirq
    
    This is XSA-13 / CVE-2012-3495
    
    Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
    Signed-off-by: Jan Beulich <JBeulich@suse.com>
    
    
changeset:   23349:bcc340292731
user:        Ian Jackson <Ian.Jackson@eu.citrix.com>
date:        Wed Sep 05 12:27:54 2012 +0100
    
    xen: prevent a 64 bit guest setting reserved bits in DR7
    
    The upper 32 bits of this register are reserved and should be written as
    zero.
    
    This is XSA-12 / CVE-2012-3494
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Reviewed-by: Ian Campbell <ian.campbell@citrix.com>
    
    
changeset:   23348:d28a9ba889c0
user:        Jan Beulich <jbeulich@suse.com>
date:        Tue Sep 04 14:56:48 2012 +0200
    
    make all (native) hypercalls consistently have "long" return type
    
    for common and x86 ones at least, to address the problem of storing
    zero-extended values into the multicall result field otherwise.
    
    Reported-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    xen-unstable changeset: 25744:47080c965937
    xen-unstable date: Fri Aug 10 07:51:01 UTC 2012
    
    
(qemu changes not included)

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

From xen-devel-bounces@lists.xen.org Thu Sep 06 01:39:28 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 2012 01:39:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9R3b-0004Wz-0a; Thu, 06 Sep 2012 01:38:59 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1T9R3Y-0004Wu-Gh
	for xen-devel@lists.xensource.com; Thu, 06 Sep 2012 01:38:56 +0000
Received: from [85.158.139.83:35142] by server-9.bemta-5.messagelabs.com id
	64/80-20529-FAEF7405; Thu, 06 Sep 2012 01:38:55 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1346895534!26091673!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTE5NjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17573 invoked from network); 6 Sep 2012 01:38:55 -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;
	6 Sep 2012 01:38:55 -0000
X-IronPort-AV: E=Sophos;i="4.80,377,1344211200"; d="scan'208";a="14371752"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Sep 2012 01:38:54 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Thu, 6 Sep 2012 02:38: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 1T9R3W-0000LT-A6;
	Thu, 06 Sep 2012 01:38:54 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1T9R3W-0004Fb-7A;
	Thu, 06 Sep 2012 02:38:54 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-13652-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 6 Sep 2012 02:38:54 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13652: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

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

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. 13648

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore            fail   like 13648
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail like 13648
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail like 13648

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  9 guest-start                 fail never pass
 test-amd64-i386-xl-credit2    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-multivcpu  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-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-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-xl-win-vcpus1  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pv            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-win-vcpus1    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 xen-build-check(1)         blocked n/a
 test-amd64-i386-xl            1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-i386-i386-pair           1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-winxpsp3    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-winxpsp3-vcpus1  1 xen-build-check(1)           blocked n/a
 test-i386-i386-pv             1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pair          1 xen-build-check(1)           blocked  n/a
 test-i386-i386-win            1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-win         1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a

version targeted for testing:
 xen                  cbc0c2368a6d
baseline version:
 xen                  9dc729b75595

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@citrix.com>
  Ian Campbell <ian.campbell@citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Keir Fraser <keir@xen.org>
  Pasi K?rkk?inen <pasik@iki.fi>
  Paul Durrant <paul.durrant@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                                             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                                     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.

------------------------------------------------------------
changeset:   25820:cbc0c2368a6d
tag:         tip
user:        Jan Beulich <jbeulich@suse.com>
date:        Wed Sep 05 15:09:48 2012 +0200
    
    x86: fix RCU locking in PHYSDEVOP_get_free_pirq
    
    Apart from properly pairing locks with unlocks, also reduce the lock
    scope - no need to do the copy_{from,to}_guest()-s inside the protected
    region.
    
    I actually wonder whether the RCU locks are needed here at all.
    
    Reported-by: Tim Deegan <tim@xen.org>
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   25819:aa69843f0b02
user:        Jan Beulich <jbeulich@suse.com>
date:        Wed Sep 05 15:07:42 2012 +0200
    
    x86: drop "index" parameter from get_free_pirq()
    
    It's unused.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   25818:50adc933faaf
user:        Ian Jackson <Ian.Jackson@eu.citrix.com>
date:        Wed Sep 05 12:38:40 2012 +0100
    
    QEMU_TAG update (XSA-17 / CVE-2012-3515)
    
    
changeset:   25817:93e5a791d076
user:        Ian Jackson <Ian.Jackson@eu.citrix.com>
date:        Wed Sep 05 12:30:26 2012 +0100
    
    xen/gnttab: Validate input to GNTTABOP_swap_grant_ref
    
    xen-unstable c/s 24548:d115844ebfbb introduces a new GNTTABOP to swap
    grant refs.  However, it fails to validate the two refs passed from
    the guest.
    
    The result is that passing out-of-range refs can cause Xen to read
    past the end of the grant_table->active[] array, and deference
    whatever it finds.  Typically, this results in Xen trying to deference
    a low pointer and fail with a page-fault.
    
    As this hypercall can be issued by an unprivileged guest, this is a
    Denial of Service against Xen.  This is XSA-18 / CVE-2012-3516.
    
    Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
    Acked-by: Paul Durrant <paul.durrant@citrix.com>
    
    
changeset:   25816:2750340a347d
user:        Ian Jackson <Ian.Jackson@eu.citrix.com>
date:        Wed Sep 05 12:29:52 2012 +0100
    
    x86/pvhvm: properly range-check PHYSDEVOP_map_pirq/MAP_PIRQ_TYPE_GSI
    
    This is being used as a array index, and hence must be validated before
    use.
    
    This is XSA-16 / CVE-2012-3498.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    
    
changeset:   25815:bcf58ef63b7c
user:        Ian Jackson <Ian.Jackson@eu.citrix.com>
date:        Wed Sep 05 12:29:03 2012 +0100
    
    xen: Don't BUG_ON() PoD operations on a non-translated guest.
    
    This is XSA-14 / CVE-2012-3496
    
    Signed-off-by: Tim Deegan <tim@xen.org>
    Reviewed-by: Ian Campbell <ian.campbell@citrix.com>
    Tested-by: Ian Campbell <ian.campbell@citrix.com>
    
    
changeset:   25814:4f1c69648201
user:        Ian Jackson <Ian.Jackson@eu.citrix.com>
date:        Wed Sep 05 12:27:25 2012 +0100
    
    xen: prevent a 64 bit guest setting reserved bits in DR7
    
    The upper 32 bits of this register are reserved and should be written as
    zero.
    
    This is XSA-12 / CVE-2012-3494
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Reviewed-by: Ian Campbell <ian.campbell@citrix.com>
    
    
changeset:   25813:9dc729b75595
user:        Pasi K?rkk?inen <pasik@iki.fi>
date:        Mon Sep 03 11:22:02 2012 +0100
    
    xl.cfg: videoram and stdvga documentation improvements
    
    - videoram: Document that only qemu-xen-traditional device-model currently
       supports changing the amount of video memory for stdvga graphics device.
    
    - videoram: Better document the default amount of videoram for both stdvga
      and Cirrus.
    
    - stdvga: Add a note that stdvga allows bigger amount of videoram and
      bigger resolutions.
    
    Signed-off-by: Pasi K?rkk?inen <pasik@iki.fi>
    Acked-by: Ian Campbell <ian.campbell@citrix.com>
    Committed-by: Ian Campbell <ian.campbell@citrix.com>
    
    
(qemu changes not included)

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

From xen-devel-bounces@lists.xen.org Thu Sep 06 01:39:28 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 2012 01:39:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9R3b-0004Wz-0a; Thu, 06 Sep 2012 01:38:59 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1T9R3Y-0004Wu-Gh
	for xen-devel@lists.xensource.com; Thu, 06 Sep 2012 01:38:56 +0000
Received: from [85.158.139.83:35142] by server-9.bemta-5.messagelabs.com id
	64/80-20529-FAEF7405; Thu, 06 Sep 2012 01:38:55 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1346895534!26091673!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTE5NjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17573 invoked from network); 6 Sep 2012 01:38:55 -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;
	6 Sep 2012 01:38:55 -0000
X-IronPort-AV: E=Sophos;i="4.80,377,1344211200"; d="scan'208";a="14371752"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Sep 2012 01:38:54 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Thu, 6 Sep 2012 02:38: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 1T9R3W-0000LT-A6;
	Thu, 06 Sep 2012 01:38:54 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1T9R3W-0004Fb-7A;
	Thu, 06 Sep 2012 02:38:54 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-13652-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 6 Sep 2012 02:38:54 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13652: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

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

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. 13648

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore            fail   like 13648
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail like 13648
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail like 13648

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  9 guest-start                 fail never pass
 test-amd64-i386-xl-credit2    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-multivcpu  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-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-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-xl-win-vcpus1  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pv            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-win-vcpus1    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 xen-build-check(1)         blocked n/a
 test-amd64-i386-xl            1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-i386-i386-pair           1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-winxpsp3    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-winxpsp3-vcpus1  1 xen-build-check(1)           blocked n/a
 test-i386-i386-pv             1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pair          1 xen-build-check(1)           blocked  n/a
 test-i386-i386-win            1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-win         1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a

version targeted for testing:
 xen                  cbc0c2368a6d
baseline version:
 xen                  9dc729b75595

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@citrix.com>
  Ian Campbell <ian.campbell@citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Keir Fraser <keir@xen.org>
  Pasi K?rkk?inen <pasik@iki.fi>
  Paul Durrant <paul.durrant@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                                             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                                     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.

------------------------------------------------------------
changeset:   25820:cbc0c2368a6d
tag:         tip
user:        Jan Beulich <jbeulich@suse.com>
date:        Wed Sep 05 15:09:48 2012 +0200
    
    x86: fix RCU locking in PHYSDEVOP_get_free_pirq
    
    Apart from properly pairing locks with unlocks, also reduce the lock
    scope - no need to do the copy_{from,to}_guest()-s inside the protected
    region.
    
    I actually wonder whether the RCU locks are needed here at all.
    
    Reported-by: Tim Deegan <tim@xen.org>
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   25819:aa69843f0b02
user:        Jan Beulich <jbeulich@suse.com>
date:        Wed Sep 05 15:07:42 2012 +0200
    
    x86: drop "index" parameter from get_free_pirq()
    
    It's unused.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   25818:50adc933faaf
user:        Ian Jackson <Ian.Jackson@eu.citrix.com>
date:        Wed Sep 05 12:38:40 2012 +0100
    
    QEMU_TAG update (XSA-17 / CVE-2012-3515)
    
    
changeset:   25817:93e5a791d076
user:        Ian Jackson <Ian.Jackson@eu.citrix.com>
date:        Wed Sep 05 12:30:26 2012 +0100
    
    xen/gnttab: Validate input to GNTTABOP_swap_grant_ref
    
    xen-unstable c/s 24548:d115844ebfbb introduces a new GNTTABOP to swap
    grant refs.  However, it fails to validate the two refs passed from
    the guest.
    
    The result is that passing out-of-range refs can cause Xen to read
    past the end of the grant_table->active[] array, and deference
    whatever it finds.  Typically, this results in Xen trying to deference
    a low pointer and fail with a page-fault.
    
    As this hypercall can be issued by an unprivileged guest, this is a
    Denial of Service against Xen.  This is XSA-18 / CVE-2012-3516.
    
    Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
    Acked-by: Paul Durrant <paul.durrant@citrix.com>
    
    
changeset:   25816:2750340a347d
user:        Ian Jackson <Ian.Jackson@eu.citrix.com>
date:        Wed Sep 05 12:29:52 2012 +0100
    
    x86/pvhvm: properly range-check PHYSDEVOP_map_pirq/MAP_PIRQ_TYPE_GSI
    
    This is being used as a array index, and hence must be validated before
    use.
    
    This is XSA-16 / CVE-2012-3498.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    
    
changeset:   25815:bcf58ef63b7c
user:        Ian Jackson <Ian.Jackson@eu.citrix.com>
date:        Wed Sep 05 12:29:03 2012 +0100
    
    xen: Don't BUG_ON() PoD operations on a non-translated guest.
    
    This is XSA-14 / CVE-2012-3496
    
    Signed-off-by: Tim Deegan <tim@xen.org>
    Reviewed-by: Ian Campbell <ian.campbell@citrix.com>
    Tested-by: Ian Campbell <ian.campbell@citrix.com>
    
    
changeset:   25814:4f1c69648201
user:        Ian Jackson <Ian.Jackson@eu.citrix.com>
date:        Wed Sep 05 12:27:25 2012 +0100
    
    xen: prevent a 64 bit guest setting reserved bits in DR7
    
    The upper 32 bits of this register are reserved and should be written as
    zero.
    
    This is XSA-12 / CVE-2012-3494
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Reviewed-by: Ian Campbell <ian.campbell@citrix.com>
    
    
changeset:   25813:9dc729b75595
user:        Pasi K?rkk?inen <pasik@iki.fi>
date:        Mon Sep 03 11:22:02 2012 +0100
    
    xl.cfg: videoram and stdvga documentation improvements
    
    - videoram: Document that only qemu-xen-traditional device-model currently
       supports changing the amount of video memory for stdvga graphics device.
    
    - videoram: Better document the default amount of videoram for both stdvga
      and Cirrus.
    
    - stdvga: Add a note that stdvga allows bigger amount of videoram and
      bigger resolutions.
    
    Signed-off-by: Pasi K?rkk?inen <pasik@iki.fi>
    Acked-by: Ian Campbell <ian.campbell@citrix.com>
    Committed-by: Ian Campbell <ian.campbell@citrix.com>
    
    
(qemu changes not included)

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

From xen-devel-bounces@lists.xen.org Thu Sep 06 02:28:16 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 2012 02:28:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9Rop-000586-TZ; Thu, 06 Sep 2012 02:27: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 1T9Roo-00057y-HV
	for xen-devel@lists.xensource.com; Thu, 06 Sep 2012 02:27:46 +0000
Received: from [85.158.138.51:26370] by server-6.bemta-3.messagelabs.com id
	37/05-29694-12A08405; Thu, 06 Sep 2012 02:27:45 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1346898464!20837568!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTE5NjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1121 invoked from network); 6 Sep 2012 02:27:45 -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;
	6 Sep 2012 02:27:45 -0000
X-IronPort-AV: E=Sophos;i="4.80,377,1344211200"; d="scan'208";a="14372280"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Sep 2012 02: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.279.1; Thu, 6 Sep 2012 03: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 1T9RoW-0000fb-86;
	Thu, 06 Sep 2012 02: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 1T9RoV-0007el-Uy;
	Thu, 06 Sep 2012 03:27:28 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-13653-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 6 Sep 2012 03:27:27 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [qemu-upstream-unstable test] 13653: 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 13653 qemu-upstream-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13653/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-qemuu-win7-amd64 9 guest-localmigrate fail REGR. vs. 13387
 test-amd64-i386-xl-qemuu-win-vcpus1  9 guest-localmigrate fail REGR. vs. 13387
 test-amd64-i386-xl-qemuu-win7-amd64  9 guest-localmigrate fail REGR. vs. 13387
 test-i386-i386-xl-qemuu-winxpsp3  9 guest-localmigrate    fail REGR. vs. 13387
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 9 guest-localmigrate fail REGR. vs. 13387
 test-amd64-amd64-xl-qemuu-win  9 guest-localmigrate       fail REGR. vs. 13387
 test-i386-i386-xl-qemuu-win   9 guest-localmigrate        fail REGR. vs. 13387
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate  fail REGR. vs. 13387

Tests which did not succeed, but are not blocking:
 test-i386-i386-qemuu-win     16 leak-check/check             fail   never pass
 test-amd64-i386-qemuu-win    16 leak-check/check             fail   never pass
 test-amd64-amd64-qemuu-win   16 leak-check/check             fail   never pass
 test-amd64-i386-xend-qemuu-winxpsp3 16 leak-check/check        fail never pass
 test-amd64-i386-qemuu-win-vcpus1 16 leak-check/check           fail never pass

version targeted for testing:
 qemuu                87650d262dea07c955a683dcac75db86477c7ee3
baseline version:
 qemuu                dbaf62769e1bfa7636208a4f00ea2331f5c40685

------------------------------------------------------------
People who touched revisions under test:
  Ian Campbell <ian.campbell@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                           pass    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-win-vcpus1                             fail    
 test-amd64-i386-xl-qemuu-win-vcpus1                          fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-amd64-qemuu-win                                   fail    
 test-amd64-i386-qemuu-win                                    fail    
 test-i386-i386-qemuu-win                                     fail    
 test-amd64-amd64-xl-qemuu-win                                fail    
 test-i386-i386-xl-qemuu-win                                  fail    
 test-amd64-i386-xend-qemuu-winxpsp3                          fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    


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

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

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


Pushing revision :

+ branch=qemu-upstream-unstable
+ revision=87650d262dea07c955a683dcac75db86477c7ee3
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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 87650d262dea07c955a683dcac75db86477c7ee3
+ branch=qemu-upstream-unstable
+ revision=87650d262dea07c955a683dcac75db86477c7ee3
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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 87650d262dea07c955a683dcac75db86477c7ee3:master
Counting objects: 1   
Counting objects: 5   
Counting objects: 5, done.
Compressing objects: 100% (1/1)   
Compressing objects: 100% (1/1), done.
Writing objects:  33% (1/3)   
Writing objects:  66% (2/3)   
Writing objects: 100% (3/3)   
Writing objects: 100% (3/3), 662 bytes, done.
Total 3 (delta 2), reused 3 (delta 2)
To xen@xenbits.xensource.com:git/qemu-upstream-unstable.git
   dbaf627..87650d2  87650d262dea07c955a683dcac75db86477c7ee3 -> master

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

From xen-devel-bounces@lists.xen.org Thu Sep 06 02:28:16 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 2012 02:28:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9Rop-000586-TZ; Thu, 06 Sep 2012 02:27: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 1T9Roo-00057y-HV
	for xen-devel@lists.xensource.com; Thu, 06 Sep 2012 02:27:46 +0000
Received: from [85.158.138.51:26370] by server-6.bemta-3.messagelabs.com id
	37/05-29694-12A08405; Thu, 06 Sep 2012 02:27:45 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1346898464!20837568!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTE5NjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1121 invoked from network); 6 Sep 2012 02:27:45 -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;
	6 Sep 2012 02:27:45 -0000
X-IronPort-AV: E=Sophos;i="4.80,377,1344211200"; d="scan'208";a="14372280"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Sep 2012 02: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.279.1; Thu, 6 Sep 2012 03: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 1T9RoW-0000fb-86;
	Thu, 06 Sep 2012 02: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 1T9RoV-0007el-Uy;
	Thu, 06 Sep 2012 03:27:28 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-13653-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 6 Sep 2012 03:27:27 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [qemu-upstream-unstable test] 13653: 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 13653 qemu-upstream-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13653/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-qemuu-win7-amd64 9 guest-localmigrate fail REGR. vs. 13387
 test-amd64-i386-xl-qemuu-win-vcpus1  9 guest-localmigrate fail REGR. vs. 13387
 test-amd64-i386-xl-qemuu-win7-amd64  9 guest-localmigrate fail REGR. vs. 13387
 test-i386-i386-xl-qemuu-winxpsp3  9 guest-localmigrate    fail REGR. vs. 13387
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 9 guest-localmigrate fail REGR. vs. 13387
 test-amd64-amd64-xl-qemuu-win  9 guest-localmigrate       fail REGR. vs. 13387
 test-i386-i386-xl-qemuu-win   9 guest-localmigrate        fail REGR. vs. 13387
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate  fail REGR. vs. 13387

Tests which did not succeed, but are not blocking:
 test-i386-i386-qemuu-win     16 leak-check/check             fail   never pass
 test-amd64-i386-qemuu-win    16 leak-check/check             fail   never pass
 test-amd64-amd64-qemuu-win   16 leak-check/check             fail   never pass
 test-amd64-i386-xend-qemuu-winxpsp3 16 leak-check/check        fail never pass
 test-amd64-i386-qemuu-win-vcpus1 16 leak-check/check           fail never pass

version targeted for testing:
 qemuu                87650d262dea07c955a683dcac75db86477c7ee3
baseline version:
 qemuu                dbaf62769e1bfa7636208a4f00ea2331f5c40685

------------------------------------------------------------
People who touched revisions under test:
  Ian Campbell <ian.campbell@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                           pass    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-win-vcpus1                             fail    
 test-amd64-i386-xl-qemuu-win-vcpus1                          fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-amd64-qemuu-win                                   fail    
 test-amd64-i386-qemuu-win                                    fail    
 test-i386-i386-qemuu-win                                     fail    
 test-amd64-amd64-xl-qemuu-win                                fail    
 test-i386-i386-xl-qemuu-win                                  fail    
 test-amd64-i386-xend-qemuu-winxpsp3                          fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    


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

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

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


Pushing revision :

+ branch=qemu-upstream-unstable
+ revision=87650d262dea07c955a683dcac75db86477c7ee3
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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 87650d262dea07c955a683dcac75db86477c7ee3
+ branch=qemu-upstream-unstable
+ revision=87650d262dea07c955a683dcac75db86477c7ee3
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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 87650d262dea07c955a683dcac75db86477c7ee3:master
Counting objects: 1   
Counting objects: 5   
Counting objects: 5, done.
Compressing objects: 100% (1/1)   
Compressing objects: 100% (1/1), done.
Writing objects:  33% (1/3)   
Writing objects:  66% (2/3)   
Writing objects: 100% (3/3)   
Writing objects: 100% (3/3), 662 bytes, done.
Total 3 (delta 2), reused 3 (delta 2)
To xen@xenbits.xensource.com:git/qemu-upstream-unstable.git
   dbaf627..87650d2  87650d262dea07c955a683dcac75db86477c7ee3 -> master

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

From xen-devel-bounces@lists.xen.org Thu Sep 06 06:00:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 2012 06: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 1T9V83-0006yR-8w; Thu, 06 Sep 2012 05:59:51 +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 1T9V81-0006yM-K5
	for xen-devel@lists.xen.org; Thu, 06 Sep 2012 05:59:49 +0000
Received: from [85.158.143.99:12508] by server-3.bemta-4.messagelabs.com id
	88/1A-08232-4DB38405; Thu, 06 Sep 2012 05:59:48 +0000
X-Env-Sender: yongjie.ren@intel.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1346911187!21275845!1
X-Originating-IP: [134.134.136.24]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjQgPT4gMzM5ODEy\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4095 invoked from network); 6 Sep 2012 05:59:48 -0000
Received: from mga09.intel.com (HELO mga09.intel.com) (134.134.136.24)
	by server-11.tower-216.messagelabs.com with SMTP;
	6 Sep 2012 05:59:48 -0000
Received: from orsmga001.jf.intel.com ([10.7.209.18])
	by orsmga102.jf.intel.com with ESMTP; 05 Sep 2012 22:59:41 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.80,377,1344236400"; d="scan'208";a="189492758"
Received: from fmsmsx105.amr.corp.intel.com ([10.19.9.36])
	by orsmga001.jf.intel.com with ESMTP; 05 Sep 2012 22:59:46 -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; Wed, 5 Sep 2012 22:59:46 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.239]) by
	SHSMSX102.ccr.corp.intel.com ([169.254.2.92]) with mapi id
	14.01.0355.002; Thu, 6 Sep 2012 13:59:22 +0800
From: "Ren, Yongjie" <yongjie.ren@intel.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Thread-Topic: Xen4.2-rc3 test result
Thread-Index: Ac2HShtAedsoaH/XR0eHCAg2EulTuP///YMA//asT0A=
Date: Thu, 6 Sep 2012 05:59:21 +0000
Message-ID: <1B4B44D9196EFF41AE41FDA404FC0A1018FAD3@SHSMSX101.ccr.corp.intel.com>
References: <1B4B44D9196EFF41AE41FDA404FC0A1018AF31@SHSMSX101.ccr.corp.intel.com>
	<1346426328.27277.234.camel@zakaz.uk.xensource.com>
In-Reply-To: <1346426328.27277.234.camel@zakaz.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: 'Konrad Rzeszutek Wilk' <konrad.wilk@oracle.com>,
	"Keir \(Xen.org\)" <keir@xen.org>, 'Jan Beulich' <JBeulich@suse.com>,
	'xen-devel' <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen4.2-rc3 test result
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> -----Original Message-----
> From: Ian Campbell [mailto:Ian.Campbell@citrix.com]
> Sent: Friday, August 31, 2012 11:19 PM
> To: Ren, Yongjie
> Cc: 'xen-devel'; Keir (Xen.org); 'Jan Beulich'; 'Konrad Rzeszutek Wilk'
> Subject: Re: Xen4.2-rc3 test result
> 
> On Fri, 2012-08-31 at 08:27 +0100, Ren, Yongjie wrote:
> > 3. 'xl vcpu-set' can't decrease the vCPU number of a HVM guest
> >   http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1822
> 
> I've only just noticed that this has changed from the previous
> description which was "vcpu-set doesn't take effect on guest".
> 
Sorry. It's me who changed its description. :-)
vCPU number increment works fine, while decrement can't work.

> Have we ever supported HVM guest CPU remove? I thought not.
> 
> http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1822#c3 seems to
> describe the behaviour I would expect.
> 
If we don't want to support HVM guest CPU remove in near future, I want to close this bug.

> If this is supposed to be an existing feature then is this a regression
> with xl vs xm or from 4.1 to 4.2?
> 
No, it's not a regression from 4.1 to 4.2.
Neither Xen 4.1 nor 4.2 supports HVM guest CPU remove with xm or xl.

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

From xen-devel-bounces@lists.xen.org Thu Sep 06 06:00:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 2012 06: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 1T9V83-0006yR-8w; Thu, 06 Sep 2012 05:59:51 +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 1T9V81-0006yM-K5
	for xen-devel@lists.xen.org; Thu, 06 Sep 2012 05:59:49 +0000
Received: from [85.158.143.99:12508] by server-3.bemta-4.messagelabs.com id
	88/1A-08232-4DB38405; Thu, 06 Sep 2012 05:59:48 +0000
X-Env-Sender: yongjie.ren@intel.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1346911187!21275845!1
X-Originating-IP: [134.134.136.24]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjQgPT4gMzM5ODEy\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4095 invoked from network); 6 Sep 2012 05:59:48 -0000
Received: from mga09.intel.com (HELO mga09.intel.com) (134.134.136.24)
	by server-11.tower-216.messagelabs.com with SMTP;
	6 Sep 2012 05:59:48 -0000
Received: from orsmga001.jf.intel.com ([10.7.209.18])
	by orsmga102.jf.intel.com with ESMTP; 05 Sep 2012 22:59:41 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.80,377,1344236400"; d="scan'208";a="189492758"
Received: from fmsmsx105.amr.corp.intel.com ([10.19.9.36])
	by orsmga001.jf.intel.com with ESMTP; 05 Sep 2012 22:59:46 -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; Wed, 5 Sep 2012 22:59:46 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.239]) by
	SHSMSX102.ccr.corp.intel.com ([169.254.2.92]) with mapi id
	14.01.0355.002; Thu, 6 Sep 2012 13:59:22 +0800
From: "Ren, Yongjie" <yongjie.ren@intel.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Thread-Topic: Xen4.2-rc3 test result
Thread-Index: Ac2HShtAedsoaH/XR0eHCAg2EulTuP///YMA//asT0A=
Date: Thu, 6 Sep 2012 05:59:21 +0000
Message-ID: <1B4B44D9196EFF41AE41FDA404FC0A1018FAD3@SHSMSX101.ccr.corp.intel.com>
References: <1B4B44D9196EFF41AE41FDA404FC0A1018AF31@SHSMSX101.ccr.corp.intel.com>
	<1346426328.27277.234.camel@zakaz.uk.xensource.com>
In-Reply-To: <1346426328.27277.234.camel@zakaz.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: 'Konrad Rzeszutek Wilk' <konrad.wilk@oracle.com>,
	"Keir \(Xen.org\)" <keir@xen.org>, 'Jan Beulich' <JBeulich@suse.com>,
	'xen-devel' <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen4.2-rc3 test result
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> -----Original Message-----
> From: Ian Campbell [mailto:Ian.Campbell@citrix.com]
> Sent: Friday, August 31, 2012 11:19 PM
> To: Ren, Yongjie
> Cc: 'xen-devel'; Keir (Xen.org); 'Jan Beulich'; 'Konrad Rzeszutek Wilk'
> Subject: Re: Xen4.2-rc3 test result
> 
> On Fri, 2012-08-31 at 08:27 +0100, Ren, Yongjie wrote:
> > 3. 'xl vcpu-set' can't decrease the vCPU number of a HVM guest
> >   http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1822
> 
> I've only just noticed that this has changed from the previous
> description which was "vcpu-set doesn't take effect on guest".
> 
Sorry. It's me who changed its description. :-)
vCPU number increment works fine, while decrement can't work.

> Have we ever supported HVM guest CPU remove? I thought not.
> 
> http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1822#c3 seems to
> describe the behaviour I would expect.
> 
If we don't want to support HVM guest CPU remove in near future, I want to close this bug.

> If this is supposed to be an existing feature then is this a regression
> with xl vs xm or from 4.1 to 4.2?
> 
No, it's not a regression from 4.1 to 4.2.
Neither Xen 4.1 nor 4.2 supports HVM guest CPU remove with xm or xl.

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

From xen-devel-bounces@lists.xen.org Thu Sep 06 07:22:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 2012 07:22:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9WPE-0007sR-Gc; Thu, 06 Sep 2012 07:21: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 1T9WPC-0007sM-TJ
	for xen-devel@lists.xen.org; Thu, 06 Sep 2012 07:21:39 +0000
Received: from [85.158.143.99:14273] by server-3.bemta-4.messagelabs.com id
	9A/BD-08232-20F48405; Thu, 06 Sep 2012 07:21:38 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1346916096!21796013!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQwNzE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17113 invoked from network); 6 Sep 2012 07:21:36 -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;
	6 Sep 2012 07:21:36 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 06 Sep 2012 08:21:36 +0100
Message-Id: <50486B560200007800099177@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 06 Sep 2012 08:22:30 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Dan Magenheimer" <dan.magenheimer@oracle.com>
References: <5047639E0200007800098DD1@nat28.tlf.novell.com>
	<c0ecf9e3-e9d1-4fc8-8427-88aff3441c33@default>
In-Reply-To: <c0ecf9e3-e9d1-4fc8-8427-88aff3441c33@default>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Konrad Wilk <konrad.wilk@oracle.com>,
	Zhenzhong Duan <zhenzhong.duan@oracle.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 05/11] tmem: don't access guest memory
 without using the accessors intended for this
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.09.12 at 18:50, Dan Magenheimer <dan.magenheimer@oracle.com> wrote:
>>  From: Jan Beulich [mailto:JBeulich@suse.com]
>> Sent: Wednesday, September 05, 2012 6:37 AM
>> To: xen-devel
>> Cc: Dan Magenheimer; Zhenzhong Duan
>> Subject: [PATCH 05/11] tmem: don't access guest memory without using the 
> accessors intended for this
>> 
>> This is not permitted, not even for buffers coming from Dom0 (and it
>> would also break the moment Dom0 runs in HVM mode). An implication from
>> the changes here is that tmh_copy_page() can't be used anymore for
>> control operations calling tmh_copy_{from,to}_client() (as those pass
>> the buffer by virtual address rather than MFN).
>> 
>> Note that tmemc_save_get_next_page() previously didn't set the returned
>> handle's pool_id field, while the new code does. It need to be
>> confirmed that this is not a problem (otherwise the copy-out operation
>> will require further tmh_...() abstractions to be added).
>> 
>> Further note that the patch removes (rather than adjusts) an invalid
>> call to unmap_domain_page() (no matching map_domain_page()) from
>> tmh_compress_from_client() and adds a missing one to an error return
>> path in tmh_copy_from_client().
>> 
>> Finally note that the patch adds a previously missing return statement
>> to cli_get_page() (without which that function could de-reference a
>> NULL pointer, triggerable from guest mode).
>> 
>> This is part of XSA-15 / CVE-2012-3497.
>> 
>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> 
> I'm a bit baffled by all the unrelated changes and cleanups, but
> they all appear to be valid fixes and, most importantly, the
> related security issues appear to be resolved.

Having gone through the patch once more, I'd be really
curious where you spotted unrelated changes (apart from
e.g. adding proper white space use on lines that needed
changing anyway).

With the size of the patch, and with this one having been
done when we still thought we would issue the patches
together with the advisory, I would really hope not to be
caught to have done unnecessary changes here (while
still preserving generic style of the code, see below).

> I'm also unable right now to plumb the depths of the guest copying
> macros so will have to trust Jan's good judgement.  One point in
> particular, it's difficult to determine if the following line is
> copying two bytes (wrong) or two uint64_t's (correct).
> 
>> +        tmh_copy_to_client_buf(buf, pool->uuid, 2);

With

#define tmh_copy_to_client_buf(clibuf, tmembuf, cnt) \
    copy_to_guest(guest_handle_cast(clibuf, void), tmembuf, cnt)

it is clear that it copies two elements of whatever tmembuf's
type is, in the case at hand uint64_t.

I would have preferred to use copy_to_guest() directly, but
that appeared to be against the spirit of the rest of the file,
which is why I added these new wrapper macros.

Jan


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

From xen-devel-bounces@lists.xen.org Thu Sep 06 07:22:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 2012 07:22:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9WPE-0007sR-Gc; Thu, 06 Sep 2012 07:21: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 1T9WPC-0007sM-TJ
	for xen-devel@lists.xen.org; Thu, 06 Sep 2012 07:21:39 +0000
Received: from [85.158.143.99:14273] by server-3.bemta-4.messagelabs.com id
	9A/BD-08232-20F48405; Thu, 06 Sep 2012 07:21:38 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1346916096!21796013!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQwNzE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17113 invoked from network); 6 Sep 2012 07:21:36 -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;
	6 Sep 2012 07:21:36 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 06 Sep 2012 08:21:36 +0100
Message-Id: <50486B560200007800099177@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 06 Sep 2012 08:22:30 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Dan Magenheimer" <dan.magenheimer@oracle.com>
References: <5047639E0200007800098DD1@nat28.tlf.novell.com>
	<c0ecf9e3-e9d1-4fc8-8427-88aff3441c33@default>
In-Reply-To: <c0ecf9e3-e9d1-4fc8-8427-88aff3441c33@default>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Konrad Wilk <konrad.wilk@oracle.com>,
	Zhenzhong Duan <zhenzhong.duan@oracle.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 05/11] tmem: don't access guest memory
 without using the accessors intended for this
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.09.12 at 18:50, Dan Magenheimer <dan.magenheimer@oracle.com> wrote:
>>  From: Jan Beulich [mailto:JBeulich@suse.com]
>> Sent: Wednesday, September 05, 2012 6:37 AM
>> To: xen-devel
>> Cc: Dan Magenheimer; Zhenzhong Duan
>> Subject: [PATCH 05/11] tmem: don't access guest memory without using the 
> accessors intended for this
>> 
>> This is not permitted, not even for buffers coming from Dom0 (and it
>> would also break the moment Dom0 runs in HVM mode). An implication from
>> the changes here is that tmh_copy_page() can't be used anymore for
>> control operations calling tmh_copy_{from,to}_client() (as those pass
>> the buffer by virtual address rather than MFN).
>> 
>> Note that tmemc_save_get_next_page() previously didn't set the returned
>> handle's pool_id field, while the new code does. It need to be
>> confirmed that this is not a problem (otherwise the copy-out operation
>> will require further tmh_...() abstractions to be added).
>> 
>> Further note that the patch removes (rather than adjusts) an invalid
>> call to unmap_domain_page() (no matching map_domain_page()) from
>> tmh_compress_from_client() and adds a missing one to an error return
>> path in tmh_copy_from_client().
>> 
>> Finally note that the patch adds a previously missing return statement
>> to cli_get_page() (without which that function could de-reference a
>> NULL pointer, triggerable from guest mode).
>> 
>> This is part of XSA-15 / CVE-2012-3497.
>> 
>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> 
> I'm a bit baffled by all the unrelated changes and cleanups, but
> they all appear to be valid fixes and, most importantly, the
> related security issues appear to be resolved.

Having gone through the patch once more, I'd be really
curious where you spotted unrelated changes (apart from
e.g. adding proper white space use on lines that needed
changing anyway).

With the size of the patch, and with this one having been
done when we still thought we would issue the patches
together with the advisory, I would really hope not to be
caught to have done unnecessary changes here (while
still preserving generic style of the code, see below).

> I'm also unable right now to plumb the depths of the guest copying
> macros so will have to trust Jan's good judgement.  One point in
> particular, it's difficult to determine if the following line is
> copying two bytes (wrong) or two uint64_t's (correct).
> 
>> +        tmh_copy_to_client_buf(buf, pool->uuid, 2);

With

#define tmh_copy_to_client_buf(clibuf, tmembuf, cnt) \
    copy_to_guest(guest_handle_cast(clibuf, void), tmembuf, cnt)

it is clear that it copies two elements of whatever tmembuf's
type is, in the case at hand uint64_t.

I would have preferred to use copy_to_guest() directly, but
that appeared to be against the spirit of the rest of the file,
which is why I added these new wrapper macros.

Jan


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

From xen-devel-bounces@lists.xen.org Thu Sep 06 07:23:40 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 2012 07:23:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9WQk-0007wL-0d; Thu, 06 Sep 2012 07:23:14 +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 1T9WQj-0007vy-Ef
	for xen-devel@lists.xen.org; Thu, 06 Sep 2012 07:23:13 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1346916186!9821822!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTE5NjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4637 invoked from network); 6 Sep 2012 07:23:06 -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 Sep 2012 07:23:06 -0000
X-IronPort-AV: E=Sophos;i="4.80,377,1344211200"; d="scan'208";a="14375993"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Sep 2012 07:23: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.279.1; Thu, 6 Sep 2012
	08:23:06 +0100
Message-ID: <1346916185.10570.15.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Pasi =?ISO-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
Date: Thu, 6 Sep 2012 08:23:05 +0100
In-Reply-To: <20120905205543.GQ8912@reaktio.net>
References: <20120905030239.GJ8912@reaktio.net>
	<1346846602-1109-1-git-send-email-roger.pau@citrix.com>
	<1346868289.10570.6.camel@dagon.hellion.org.uk>
	<20120905205543.GQ8912@reaktio.net>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-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] libfsimage: add ext4 support for CentOS 5.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="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, 2012-09-05 at 21:55 +0100, Pasi K=E4rkk=E4inen wrote:
> On Wed, Sep 05, 2012 at 07:04:49PM +0100, Ian Campbell wrote:
> > On Wed, 2012-09-05 at 13:03 +0100, Roger Pau Monne wrote:
> > > CentOS 5.x forked e2fs ext4 support into a different package called
> > > e4fs, and so headers and library names changed from ext2fs to ext4fs.
> > > Check if ext4fs/ext2fs.h and -lext4fs work, and use that instead of
> > > ext2fs to build libfsimage. This patch assumes that if the ext4fs
> > > library is present it should always be used instead of ext2fs.
> > > =

> > > This patch includes a rework of the ext2fs check, a new ext4fs check
> > > and a minor modification in libfsimage to use the correct library.
> > > =

> > > Signed-off-by: Roger Pau Monne <roger.pau@citrix.com>
> > =

> > Thanks.
> > =

> > Any patch which is intended for 4.2 at this stage needs to come with
> > some rationale as to why it is acceptable at this late stage.
> > =

> =

> rhel5/centos5 has a lot of Xen users, so it'd be nice if those people
> could build Xen 4.2 from sources and still have pygrub ext4 support.

I'm sorry but two days (now one day) before the final RC we need more
justification than "it would be nice".

Who are these people? How many of them are there? Why are they doing
this? If you are building from source what reason is there to be using
RHEL5?

We certainly don't seem to be getting bugs reports (either on -devel@ or
-users@) about this problem.

> (the stock redhat el5 Xen 3.1.2 rpms have similar tweaks and =

> they do provide pygrub ext4 support out-of-the-box on el5).
> =

> Also XenServer/XCP has hacks to get pygrub ext4 support enabled in simila=
r way,
> so it'd make sense to fix/workaround this properly in Xen upstream.

This seems right and proper to me and isn't an argument for us taking
and carry this hack in our tree.

IMHO the presence of libe4fs in RHEL5 is a distro specific packaging
hack and it is appropriate that the fallout be dealt with via RHEL5
specific packaging hacks.

> > Therefore unless someone can argue convincingly for it this is 4.3
> > material.
> > =

> =

> I'm not expecting that was convincing enough :) so if not 4.2.0 then 4.3 =
and 4.2.1 ? =


Perhaps. I'm not entirely convinced of the need at all though. If RHEL5
was the current release then maybe, but RHEL6 is nearly two years old at
this point.

Ian.


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

From xen-devel-bounces@lists.xen.org Thu Sep 06 07:23:40 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 2012 07:23:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9WQk-0007wL-0d; Thu, 06 Sep 2012 07:23:14 +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 1T9WQj-0007vy-Ef
	for xen-devel@lists.xen.org; Thu, 06 Sep 2012 07:23:13 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1346916186!9821822!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTE5NjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4637 invoked from network); 6 Sep 2012 07:23:06 -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 Sep 2012 07:23:06 -0000
X-IronPort-AV: E=Sophos;i="4.80,377,1344211200"; d="scan'208";a="14375993"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Sep 2012 07:23: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.279.1; Thu, 6 Sep 2012
	08:23:06 +0100
Message-ID: <1346916185.10570.15.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Pasi =?ISO-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
Date: Thu, 6 Sep 2012 08:23:05 +0100
In-Reply-To: <20120905205543.GQ8912@reaktio.net>
References: <20120905030239.GJ8912@reaktio.net>
	<1346846602-1109-1-git-send-email-roger.pau@citrix.com>
	<1346868289.10570.6.camel@dagon.hellion.org.uk>
	<20120905205543.GQ8912@reaktio.net>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-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] libfsimage: add ext4 support for CentOS 5.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="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, 2012-09-05 at 21:55 +0100, Pasi K=E4rkk=E4inen wrote:
> On Wed, Sep 05, 2012 at 07:04:49PM +0100, Ian Campbell wrote:
> > On Wed, 2012-09-05 at 13:03 +0100, Roger Pau Monne wrote:
> > > CentOS 5.x forked e2fs ext4 support into a different package called
> > > e4fs, and so headers and library names changed from ext2fs to ext4fs.
> > > Check if ext4fs/ext2fs.h and -lext4fs work, and use that instead of
> > > ext2fs to build libfsimage. This patch assumes that if the ext4fs
> > > library is present it should always be used instead of ext2fs.
> > > =

> > > This patch includes a rework of the ext2fs check, a new ext4fs check
> > > and a minor modification in libfsimage to use the correct library.
> > > =

> > > Signed-off-by: Roger Pau Monne <roger.pau@citrix.com>
> > =

> > Thanks.
> > =

> > Any patch which is intended for 4.2 at this stage needs to come with
> > some rationale as to why it is acceptable at this late stage.
> > =

> =

> rhel5/centos5 has a lot of Xen users, so it'd be nice if those people
> could build Xen 4.2 from sources and still have pygrub ext4 support.

I'm sorry but two days (now one day) before the final RC we need more
justification than "it would be nice".

Who are these people? How many of them are there? Why are they doing
this? If you are building from source what reason is there to be using
RHEL5?

We certainly don't seem to be getting bugs reports (either on -devel@ or
-users@) about this problem.

> (the stock redhat el5 Xen 3.1.2 rpms have similar tweaks and =

> they do provide pygrub ext4 support out-of-the-box on el5).
> =

> Also XenServer/XCP has hacks to get pygrub ext4 support enabled in simila=
r way,
> so it'd make sense to fix/workaround this properly in Xen upstream.

This seems right and proper to me and isn't an argument for us taking
and carry this hack in our tree.

IMHO the presence of libe4fs in RHEL5 is a distro specific packaging
hack and it is appropriate that the fallout be dealt with via RHEL5
specific packaging hacks.

> > Therefore unless someone can argue convincingly for it this is 4.3
> > material.
> > =

> =

> I'm not expecting that was convincing enough :) so if not 4.2.0 then 4.3 =
and 4.2.1 ? =


Perhaps. I'm not entirely convinced of the need at all though. If RHEL5
was the current release then maybe, but RHEL6 is nearly two years old at
this point.

Ian.


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

From xen-devel-bounces@lists.xen.org Thu Sep 06 07:26:54 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 2012 07: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 1T9WTy-00086o-MP; Thu, 06 Sep 2012 07:26: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 1T9WTx-00086c-Kb
	for xen-devel@lists.xen.org; Thu, 06 Sep 2012 07:26:33 +0000
Received: from [85.158.143.35:28681] by server-3.bemta-4.messagelabs.com id
	FD/75-08232-92058405; Thu, 06 Sep 2012 07:26:33 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1346916392!11397975!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTE5NjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4616 invoked from network); 6 Sep 2012 07:26:32 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Sep 2012 07:26:32 -0000
X-IronPort-AV: E=Sophos;i="4.80,377,1344211200"; d="scan'208";a="14376064"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Sep 2012 07:26:32 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Thu, 6 Sep 2012
	08:26:31 +0100
Message-ID: <1346916391.10570.17.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Date: Thu, 6 Sep 2012 08:26:31 +0100
In-Reply-To: <1346864713-28732-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1346400260.27277.93.camel@zakaz.uk.xensource.com>
	<1346864713-28732-1-git-send-email-dgdegra@tycho.nsa.gov>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-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: Support backend domain ID for
	disks
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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-09-05 at 18:05 +0100, Daniel De Graaf wrote:
> Allow specification of backend domains for disks, either in the config
> file or via xl block-attach. This functionality was supported in xend
> (via an optional command line parameter to block-attach), so should also
> be supported with libxl.
> 
> In order to support named backend domains like network-attach, a valid
> libxl_ctx must now be passed to xlu_cfg_init.
> 
> Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>

Sorry but I think in the end this has missed the cut-off for 4.2.0 (we
are cutting the final RC tomorrow).

We should be branching soon after the final RC which means 4.3
development will open in unstable shortly. We should take this into
unstable then and consider it for 4.2.1.

In the meantime I suppose we should mention this in the release notes.

> 
> ---
> 
> This patch does not include the changes to tools/libxl/libxlu_disk_l.c
> and tools/libxl/libxlu_disk_l.h because the diffs contain unrelated
> changes due to different generator versions.
> 
>  docs/misc/xl-disk-configuration.txt | 12 ++++++++++++
>  tools/libxl/libxlu_cfg.c            |  4 +++-
>  tools/libxl/libxlu_disk_l.l         |  9 +++++++++
>  tools/libxl/libxlu_internal.h       |  1 +
>  tools/libxl/libxlutil.h             |  3 ++-
>  tools/libxl/xl.c                    |  2 +-
>  tools/libxl/xl_cmdimpl.c            | 20 +++++++++-----------
>  7 files changed, 37 insertions(+), 14 deletions(-)
> 
> diff --git a/docs/misc/xl-disk-configuration.txt b/docs/misc/xl-disk-configuration.txt
> index 86c16be..5bd456d 100644
> --- a/docs/misc/xl-disk-configuration.txt
> +++ b/docs/misc/xl-disk-configuration.txt
> @@ -139,6 +139,18 @@ cdrom
>  Convenience alias for "devtype=cdrom".
>  
> 
> +backend=<domain-name>
> +---------------------
> +
> +Description:           Designates a backend domain for the device
> +Supported values:      Valid domain names
> +Mandatory:             No
> +
> +Specifies the backend domain which this device should attach to. This
> +defaults to domain 0. Specifying another domain requires setting up a
> +driver domain which is outside the scope of this document.
> +
> +
>  backendtype=<backend-type>
>  --------------------------
>  
> diff --git a/tools/libxl/libxlu_cfg.c b/tools/libxl/libxlu_cfg.c
> index 22adcb0..1d086b4 100644
> --- a/tools/libxl/libxlu_cfg.c
> +++ b/tools/libxl/libxlu_cfg.c
> @@ -25,13 +25,15 @@
>  #include "libxlu_cfg_l.h"
>  #include "libxlu_cfg_i.h"
>  
> -XLU_Config *xlu_cfg_init(FILE *report, const char *report_source) {
> +XLU_Config *xlu_cfg_init(FILE *report, const char *report_source,
> +                         libxl_ctx *ctx) {
>      XLU_Config *cfg;
>  
>      cfg= malloc(sizeof(*cfg));
>      if (!cfg) return 0;
>  
>      cfg->report= report;
> +    cfg->ctx = ctx;
>      cfg->config_source= strdup(report_source);
>      if (!cfg->config_source) { free(cfg); return 0; }
>  
> diff --git a/tools/libxl/libxlu_disk_l.l b/tools/libxl/libxlu_disk_l.l
> index bee16a1..8cfc16e 100644
> --- a/tools/libxl/libxlu_disk_l.l
> +++ b/tools/libxl/libxlu_disk_l.l
> @@ -33,6 +33,7 @@
>  
>  %{
>  #include "libxlu_disk_i.h"
> +#include "libxl_utils.h"
>  
>  #define YY_NO_INPUT
>  
> @@ -113,6 +114,13 @@ static void setbackendtype(DiskParseContext *dpc, const char *str) {
>      else xlu__disk_err(dpc,str,"unknown value for backendtype");
>  }
>  
> +/* Sets ->backend_domid from the string. */
> +static void setbackend(DiskParseContext *dpc, const char *str) {
> +    if (libxl_name_to_domid(dpc->cfg->ctx, str, &dpc->disk->backend_domid)) {
> +        xlu__disk_err(dpc,str,"unknown domain for backend");
> +    }
> +}
> +
>  #define DEPRECATE(usewhatinstead) /* not currently reported */
>  
>  /* Handles a vdev positional parameter which includes a devtype. */
> @@ -168,6 +176,7 @@ devtype=disk,?	{ DPC->disk->is_cdrom = 0; }
>  devtype=[^,]*,?	{ xlu__disk_err(DPC,yytext,"unknown value for type"); }
>  
>  access=[^,]*,?	{ STRIP(','); setaccess(DPC, FROMEQUALS); }
> +backend=[^,]*,? { STRIP(','); setbackend(DPC,FROMEQUALS); }
>  backendtype=[^,]*,? { STRIP(','); setbackendtype(DPC,FROMEQUALS); }
>  
>  vdev=[^,]*,?	{ STRIP(','); SAVESTRING("vdev", vdev, FROMEQUALS); }
> diff --git a/tools/libxl/libxlu_internal.h b/tools/libxl/libxlu_internal.h
> index 7579158..5a9cf6d 100644
> --- a/tools/libxl/libxlu_internal.h
> +++ b/tools/libxl/libxlu_internal.h
> @@ -39,6 +39,7 @@ struct XLU_Config {
>      XLU_ConfigSetting *settings;
>      FILE *report;
>      char *config_source;
> +    libxl_ctx *ctx;
>  };
>  
>  typedef struct {
> diff --git a/tools/libxl/libxlutil.h b/tools/libxl/libxlutil.h
> index 0333e55..1de23e7 100644
> --- a/tools/libxl/libxlutil.h
> +++ b/tools/libxl/libxlutil.h
> @@ -24,7 +24,8 @@
>  typedef struct XLU_Config XLU_Config;
>  typedef struct XLU_ConfigList XLU_ConfigList;
>  
> -XLU_Config *xlu_cfg_init(FILE *report, const char *report_filename);
> +XLU_Config *xlu_cfg_init(FILE *report, const char *report_filename,
> +                         libxl_ctx *ctx);
>    /* 0 means we got ENOMEM. */
>    /* report_filename is copied; report is saved and must remain valid
>     *  until the Config is destroyed. */
> diff --git a/tools/libxl/xl.c b/tools/libxl/xl.c
> index f31e836..32a5c32 100644
> --- a/tools/libxl/xl.c
> +++ b/tools/libxl/xl.c
> @@ -56,7 +56,7 @@ static void parse_global_config(const char *configfile,
>      int e;
>      const char *buf;
>  
> -    config = xlu_cfg_init(stderr, configfile);
> +    config = xlu_cfg_init(stderr, configfile, ctx);
>      if (!config) {
>          fprintf(stderr, "Failed to allocate for configuration\n");
>          exit(1);
> diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
> index 2d6ab97..eaebbeb 100644
> --- a/tools/libxl/xl_cmdimpl.c
> +++ b/tools/libxl/xl_cmdimpl.c
> @@ -427,7 +427,7 @@ static void parse_disk_config_multistring(XLU_Config **config,
>      libxl_device_disk_init(disk);
>  
>      if (!*config) {
> -        *config = xlu_cfg_init(stderr, "command line");
> +        *config = xlu_cfg_init(stderr, "command line", ctx);
>          if (!*config) { perror("xlu_cfg_init"); exit(-1); }
>      }
>  
> @@ -583,7 +583,7 @@ static void parse_config_data(const char *config_source,
>      libxl_domain_create_info *c_info = &d_config->c_info;
>      libxl_domain_build_info *b_info = &d_config->b_info;
>  
> -    config= xlu_cfg_init(stderr, config_source);
> +    config= xlu_cfg_init(stderr, config_source, ctx);
>      if (!config) {
>          fprintf(stderr, "Failed to allocate for configuration\n");
>          exit(1);
> @@ -2473,7 +2473,7 @@ static void pcidetach(const char *dom, const char *bdf, int force)
>  
>      libxl_device_pci_init(&pcidev);
>      
> -    config = xlu_cfg_init(stderr, "command line");
> +    config = xlu_cfg_init(stderr, "command line", ctx);
>      if (!config) { perror("xlu_cfg_inig"); exit(-1); }
>  
>      if (xlu_pci_parse_bdf(config, &pcidev, bdf)) {
> @@ -2520,7 +2520,7 @@ static void pciattach(const char *dom, const char *bdf, const char *vs)
>  
>      libxl_device_pci_init(&pcidev);
>  
> -    config = xlu_cfg_init(stderr, "command line");
> +    config = xlu_cfg_init(stderr, "command line", ctx);
>      if (!config) { perror("xlu_cfg_inig"); exit(-1); }
>  
>      if (xlu_pci_parse_bdf(config, &pcidev, bdf)) {
> @@ -2586,7 +2586,7 @@ static void pciassignable_add(const char *bdf, int rebind)
>  
>      libxl_device_pci_init(&pcidev);
>  
> -    config = xlu_cfg_init(stderr, "command line");
> +    config = xlu_cfg_init(stderr, "command line", ctx);
>      if (!config) { perror("xlu_cfg_init"); exit(-1); }
>  
>      if (xlu_pci_parse_bdf(config, &pcidev, bdf)) {
> @@ -2624,7 +2624,7 @@ static void pciassignable_remove(const char *bdf, int rebind)
>  
>      libxl_device_pci_init(&pcidev);
>  
> -    config = xlu_cfg_init(stderr, "command line");
> +    config = xlu_cfg_init(stderr, "command line", ctx);
>      if (!config) { perror("xlu_cfg_init"); exit(-1); }
>  
>      if (xlu_pci_parse_bdf(config, &pcidev, bdf)) {
> @@ -5321,7 +5321,7 @@ int main_networkattach(int argc, char **argv)
>          return 1;
>      }
>  
> -    config= xlu_cfg_init(stderr, "command line");
> +    config= xlu_cfg_init(stderr, "command line", ctx);
>      if (!config) {
>          fprintf(stderr, "Failed to allocate for configuration\n");
>          return 1;
> @@ -5467,7 +5467,7 @@ int main_networkdetach(int argc, char **argv)
>  int main_blockattach(int argc, char **argv)
>  {
>      int opt;
> -    uint32_t fe_domid, be_domid = 0;
> +    uint32_t fe_domid;
>      libxl_device_disk disk = { 0 };
>      XLU_Config *config = 0;
>  
> @@ -5483,8 +5483,6 @@ int main_blockattach(int argc, char **argv)
>      parse_disk_config_multistring
>          (&config, argc-optind, (const char* const*)argv + optind, &disk);
>  
> -    disk.backend_domid = be_domid;
> -
>      if (dryrun_only) {
>          char *json = libxl_device_disk_to_json(ctx, &disk);
>          printf("disk: %s\n", json);
> @@ -6078,7 +6076,7 @@ int main_cpupoolcreate(int argc, char **argv)
>          config_len += strlen(extra_config) + 1;
>      }
>  
> -    config = xlu_cfg_init(stderr, config_src);
> +    config = xlu_cfg_init(stderr, config_src, ctx);
>      if (!config) {
>          fprintf(stderr, "Failed to allocate for configuration\n");
>          goto out;



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

From xen-devel-bounces@lists.xen.org Thu Sep 06 07:26:54 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 2012 07: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 1T9WTy-00086o-MP; Thu, 06 Sep 2012 07:26: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 1T9WTx-00086c-Kb
	for xen-devel@lists.xen.org; Thu, 06 Sep 2012 07:26:33 +0000
Received: from [85.158.143.35:28681] by server-3.bemta-4.messagelabs.com id
	FD/75-08232-92058405; Thu, 06 Sep 2012 07:26:33 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1346916392!11397975!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTE5NjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4616 invoked from network); 6 Sep 2012 07:26:32 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Sep 2012 07:26:32 -0000
X-IronPort-AV: E=Sophos;i="4.80,377,1344211200"; d="scan'208";a="14376064"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Sep 2012 07:26:32 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Thu, 6 Sep 2012
	08:26:31 +0100
Message-ID: <1346916391.10570.17.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Date: Thu, 6 Sep 2012 08:26:31 +0100
In-Reply-To: <1346864713-28732-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1346400260.27277.93.camel@zakaz.uk.xensource.com>
	<1346864713-28732-1-git-send-email-dgdegra@tycho.nsa.gov>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-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: Support backend domain ID for
	disks
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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-09-05 at 18:05 +0100, Daniel De Graaf wrote:
> Allow specification of backend domains for disks, either in the config
> file or via xl block-attach. This functionality was supported in xend
> (via an optional command line parameter to block-attach), so should also
> be supported with libxl.
> 
> In order to support named backend domains like network-attach, a valid
> libxl_ctx must now be passed to xlu_cfg_init.
> 
> Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>

Sorry but I think in the end this has missed the cut-off for 4.2.0 (we
are cutting the final RC tomorrow).

We should be branching soon after the final RC which means 4.3
development will open in unstable shortly. We should take this into
unstable then and consider it for 4.2.1.

In the meantime I suppose we should mention this in the release notes.

> 
> ---
> 
> This patch does not include the changes to tools/libxl/libxlu_disk_l.c
> and tools/libxl/libxlu_disk_l.h because the diffs contain unrelated
> changes due to different generator versions.
> 
>  docs/misc/xl-disk-configuration.txt | 12 ++++++++++++
>  tools/libxl/libxlu_cfg.c            |  4 +++-
>  tools/libxl/libxlu_disk_l.l         |  9 +++++++++
>  tools/libxl/libxlu_internal.h       |  1 +
>  tools/libxl/libxlutil.h             |  3 ++-
>  tools/libxl/xl.c                    |  2 +-
>  tools/libxl/xl_cmdimpl.c            | 20 +++++++++-----------
>  7 files changed, 37 insertions(+), 14 deletions(-)
> 
> diff --git a/docs/misc/xl-disk-configuration.txt b/docs/misc/xl-disk-configuration.txt
> index 86c16be..5bd456d 100644
> --- a/docs/misc/xl-disk-configuration.txt
> +++ b/docs/misc/xl-disk-configuration.txt
> @@ -139,6 +139,18 @@ cdrom
>  Convenience alias for "devtype=cdrom".
>  
> 
> +backend=<domain-name>
> +---------------------
> +
> +Description:           Designates a backend domain for the device
> +Supported values:      Valid domain names
> +Mandatory:             No
> +
> +Specifies the backend domain which this device should attach to. This
> +defaults to domain 0. Specifying another domain requires setting up a
> +driver domain which is outside the scope of this document.
> +
> +
>  backendtype=<backend-type>
>  --------------------------
>  
> diff --git a/tools/libxl/libxlu_cfg.c b/tools/libxl/libxlu_cfg.c
> index 22adcb0..1d086b4 100644
> --- a/tools/libxl/libxlu_cfg.c
> +++ b/tools/libxl/libxlu_cfg.c
> @@ -25,13 +25,15 @@
>  #include "libxlu_cfg_l.h"
>  #include "libxlu_cfg_i.h"
>  
> -XLU_Config *xlu_cfg_init(FILE *report, const char *report_source) {
> +XLU_Config *xlu_cfg_init(FILE *report, const char *report_source,
> +                         libxl_ctx *ctx) {
>      XLU_Config *cfg;
>  
>      cfg= malloc(sizeof(*cfg));
>      if (!cfg) return 0;
>  
>      cfg->report= report;
> +    cfg->ctx = ctx;
>      cfg->config_source= strdup(report_source);
>      if (!cfg->config_source) { free(cfg); return 0; }
>  
> diff --git a/tools/libxl/libxlu_disk_l.l b/tools/libxl/libxlu_disk_l.l
> index bee16a1..8cfc16e 100644
> --- a/tools/libxl/libxlu_disk_l.l
> +++ b/tools/libxl/libxlu_disk_l.l
> @@ -33,6 +33,7 @@
>  
>  %{
>  #include "libxlu_disk_i.h"
> +#include "libxl_utils.h"
>  
>  #define YY_NO_INPUT
>  
> @@ -113,6 +114,13 @@ static void setbackendtype(DiskParseContext *dpc, const char *str) {
>      else xlu__disk_err(dpc,str,"unknown value for backendtype");
>  }
>  
> +/* Sets ->backend_domid from the string. */
> +static void setbackend(DiskParseContext *dpc, const char *str) {
> +    if (libxl_name_to_domid(dpc->cfg->ctx, str, &dpc->disk->backend_domid)) {
> +        xlu__disk_err(dpc,str,"unknown domain for backend");
> +    }
> +}
> +
>  #define DEPRECATE(usewhatinstead) /* not currently reported */
>  
>  /* Handles a vdev positional parameter which includes a devtype. */
> @@ -168,6 +176,7 @@ devtype=disk,?	{ DPC->disk->is_cdrom = 0; }
>  devtype=[^,]*,?	{ xlu__disk_err(DPC,yytext,"unknown value for type"); }
>  
>  access=[^,]*,?	{ STRIP(','); setaccess(DPC, FROMEQUALS); }
> +backend=[^,]*,? { STRIP(','); setbackend(DPC,FROMEQUALS); }
>  backendtype=[^,]*,? { STRIP(','); setbackendtype(DPC,FROMEQUALS); }
>  
>  vdev=[^,]*,?	{ STRIP(','); SAVESTRING("vdev", vdev, FROMEQUALS); }
> diff --git a/tools/libxl/libxlu_internal.h b/tools/libxl/libxlu_internal.h
> index 7579158..5a9cf6d 100644
> --- a/tools/libxl/libxlu_internal.h
> +++ b/tools/libxl/libxlu_internal.h
> @@ -39,6 +39,7 @@ struct XLU_Config {
>      XLU_ConfigSetting *settings;
>      FILE *report;
>      char *config_source;
> +    libxl_ctx *ctx;
>  };
>  
>  typedef struct {
> diff --git a/tools/libxl/libxlutil.h b/tools/libxl/libxlutil.h
> index 0333e55..1de23e7 100644
> --- a/tools/libxl/libxlutil.h
> +++ b/tools/libxl/libxlutil.h
> @@ -24,7 +24,8 @@
>  typedef struct XLU_Config XLU_Config;
>  typedef struct XLU_ConfigList XLU_ConfigList;
>  
> -XLU_Config *xlu_cfg_init(FILE *report, const char *report_filename);
> +XLU_Config *xlu_cfg_init(FILE *report, const char *report_filename,
> +                         libxl_ctx *ctx);
>    /* 0 means we got ENOMEM. */
>    /* report_filename is copied; report is saved and must remain valid
>     *  until the Config is destroyed. */
> diff --git a/tools/libxl/xl.c b/tools/libxl/xl.c
> index f31e836..32a5c32 100644
> --- a/tools/libxl/xl.c
> +++ b/tools/libxl/xl.c
> @@ -56,7 +56,7 @@ static void parse_global_config(const char *configfile,
>      int e;
>      const char *buf;
>  
> -    config = xlu_cfg_init(stderr, configfile);
> +    config = xlu_cfg_init(stderr, configfile, ctx);
>      if (!config) {
>          fprintf(stderr, "Failed to allocate for configuration\n");
>          exit(1);
> diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
> index 2d6ab97..eaebbeb 100644
> --- a/tools/libxl/xl_cmdimpl.c
> +++ b/tools/libxl/xl_cmdimpl.c
> @@ -427,7 +427,7 @@ static void parse_disk_config_multistring(XLU_Config **config,
>      libxl_device_disk_init(disk);
>  
>      if (!*config) {
> -        *config = xlu_cfg_init(stderr, "command line");
> +        *config = xlu_cfg_init(stderr, "command line", ctx);
>          if (!*config) { perror("xlu_cfg_init"); exit(-1); }
>      }
>  
> @@ -583,7 +583,7 @@ static void parse_config_data(const char *config_source,
>      libxl_domain_create_info *c_info = &d_config->c_info;
>      libxl_domain_build_info *b_info = &d_config->b_info;
>  
> -    config= xlu_cfg_init(stderr, config_source);
> +    config= xlu_cfg_init(stderr, config_source, ctx);
>      if (!config) {
>          fprintf(stderr, "Failed to allocate for configuration\n");
>          exit(1);
> @@ -2473,7 +2473,7 @@ static void pcidetach(const char *dom, const char *bdf, int force)
>  
>      libxl_device_pci_init(&pcidev);
>      
> -    config = xlu_cfg_init(stderr, "command line");
> +    config = xlu_cfg_init(stderr, "command line", ctx);
>      if (!config) { perror("xlu_cfg_inig"); exit(-1); }
>  
>      if (xlu_pci_parse_bdf(config, &pcidev, bdf)) {
> @@ -2520,7 +2520,7 @@ static void pciattach(const char *dom, const char *bdf, const char *vs)
>  
>      libxl_device_pci_init(&pcidev);
>  
> -    config = xlu_cfg_init(stderr, "command line");
> +    config = xlu_cfg_init(stderr, "command line", ctx);
>      if (!config) { perror("xlu_cfg_inig"); exit(-1); }
>  
>      if (xlu_pci_parse_bdf(config, &pcidev, bdf)) {
> @@ -2586,7 +2586,7 @@ static void pciassignable_add(const char *bdf, int rebind)
>  
>      libxl_device_pci_init(&pcidev);
>  
> -    config = xlu_cfg_init(stderr, "command line");
> +    config = xlu_cfg_init(stderr, "command line", ctx);
>      if (!config) { perror("xlu_cfg_init"); exit(-1); }
>  
>      if (xlu_pci_parse_bdf(config, &pcidev, bdf)) {
> @@ -2624,7 +2624,7 @@ static void pciassignable_remove(const char *bdf, int rebind)
>  
>      libxl_device_pci_init(&pcidev);
>  
> -    config = xlu_cfg_init(stderr, "command line");
> +    config = xlu_cfg_init(stderr, "command line", ctx);
>      if (!config) { perror("xlu_cfg_init"); exit(-1); }
>  
>      if (xlu_pci_parse_bdf(config, &pcidev, bdf)) {
> @@ -5321,7 +5321,7 @@ int main_networkattach(int argc, char **argv)
>          return 1;
>      }
>  
> -    config= xlu_cfg_init(stderr, "command line");
> +    config= xlu_cfg_init(stderr, "command line", ctx);
>      if (!config) {
>          fprintf(stderr, "Failed to allocate for configuration\n");
>          return 1;
> @@ -5467,7 +5467,7 @@ int main_networkdetach(int argc, char **argv)
>  int main_blockattach(int argc, char **argv)
>  {
>      int opt;
> -    uint32_t fe_domid, be_domid = 0;
> +    uint32_t fe_domid;
>      libxl_device_disk disk = { 0 };
>      XLU_Config *config = 0;
>  
> @@ -5483,8 +5483,6 @@ int main_blockattach(int argc, char **argv)
>      parse_disk_config_multistring
>          (&config, argc-optind, (const char* const*)argv + optind, &disk);
>  
> -    disk.backend_domid = be_domid;
> -
>      if (dryrun_only) {
>          char *json = libxl_device_disk_to_json(ctx, &disk);
>          printf("disk: %s\n", json);
> @@ -6078,7 +6076,7 @@ int main_cpupoolcreate(int argc, char **argv)
>          config_len += strlen(extra_config) + 1;
>      }
>  
> -    config = xlu_cfg_init(stderr, config_src);
> +    config = xlu_cfg_init(stderr, config_src, ctx);
>      if (!config) {
>          fprintf(stderr, "Failed to allocate for configuration\n");
>          goto out;



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

From xen-devel-bounces@lists.xen.org Thu Sep 06 07:29:33 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 2012 07:29: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 1T9WWU-0008Fj-8Y; Thu, 06 Sep 2012 07:29:10 +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 1T9WWS-0008FZ-Qd
	for xen-devel@lists.xen.org; Thu, 06 Sep 2012 07:29:09 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1346916542!8394185!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTE5NjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7099 invoked from network); 6 Sep 2012 07:29:03 -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 Sep 2012 07:29:03 -0000
X-IronPort-AV: E=Sophos;i="4.80,377,1344211200"; d="scan'208";a="14376111"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Sep 2012 07:29: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.279.1; Thu, 6 Sep 2012
	08:29:02 +0100
Message-ID: <1346916542.10570.18.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Roger Pau Monne <roger.pau@citrix.com>
Date: Thu, 6 Sep 2012 08:29:02 +0100
In-Reply-To: <1346771812-98690-1-git-send-email-roger.pau@citrix.com>
References: <1346771812-98690-1-git-send-email-roger.pau@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v2 1/2] libxl: fix usage of backend
 parameter and run_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

On Tue, 2012-09-04 at 16:16 +0100, Roger Pau Monne wrote:
> vif interfaces allows the user to specify the domain that should run
> the backend (also known as driver domain) using the 'backend'
> parameter. This is not compatible with run_hotplug_scripts=1, since
> libxl can only run the hotplug scripts from the Domain 0.

Sorry but I think in the end this has missed the cut-off for 4.2.0 (we
are cutting the final RC tomorrow).

We should be branching soon after the final RC which means 4.3
development will open in unstable shortly. We should take this into
unstable then and consider it for 4.2.1.

In the meantime I suppose we should mention this in the release notes.



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

From xen-devel-bounces@lists.xen.org Thu Sep 06 07:29:33 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 2012 07:29: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 1T9WWU-0008Fj-8Y; Thu, 06 Sep 2012 07:29:10 +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 1T9WWS-0008FZ-Qd
	for xen-devel@lists.xen.org; Thu, 06 Sep 2012 07:29:09 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1346916542!8394185!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTE5NjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7099 invoked from network); 6 Sep 2012 07:29:03 -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 Sep 2012 07:29:03 -0000
X-IronPort-AV: E=Sophos;i="4.80,377,1344211200"; d="scan'208";a="14376111"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Sep 2012 07:29: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.279.1; Thu, 6 Sep 2012
	08:29:02 +0100
Message-ID: <1346916542.10570.18.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Roger Pau Monne <roger.pau@citrix.com>
Date: Thu, 6 Sep 2012 08:29:02 +0100
In-Reply-To: <1346771812-98690-1-git-send-email-roger.pau@citrix.com>
References: <1346771812-98690-1-git-send-email-roger.pau@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v2 1/2] libxl: fix usage of backend
 parameter and run_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

On Tue, 2012-09-04 at 16:16 +0100, Roger Pau Monne wrote:
> vif interfaces allows the user to specify the domain that should run
> the backend (also known as driver domain) using the 'backend'
> parameter. This is not compatible with run_hotplug_scripts=1, since
> libxl can only run the hotplug scripts from the Domain 0.

Sorry but I think in the end this has missed the cut-off for 4.2.0 (we
are cutting the final RC tomorrow).

We should be branching soon after the final RC which means 4.3
development will open in unstable shortly. We should take this into
unstable then and consider it for 4.2.1.

In the meantime I suppose we should mention this in the release notes.



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

From xen-devel-bounces@lists.xen.org Thu Sep 06 07:31:39 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 2012 07:31:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9WYb-0008Ng-Ph; Thu, 06 Sep 2012 07:31:21 +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 1T9WYa-0008NO-9n
	for xen-devel@lists.xen.org; Thu, 06 Sep 2012 07:31:20 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1346916673!9823251!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTE5NjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1106 invoked from network); 6 Sep 2012 07:31:14 -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;
	6 Sep 2012 07:31:14 -0000
X-IronPort-AV: E=Sophos;i="4.80,377,1344211200"; d="scan'208";a="14376146"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Sep 2012 07:31:13 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Thu, 6 Sep 2012
	08:31:13 +0100
Message-ID: <1346916672.10570.20.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "Ren, Yongjie" <yongjie.ren@intel.com>
Date: Thu, 6 Sep 2012 08:31:12 +0100
In-Reply-To: <1B4B44D9196EFF41AE41FDA404FC0A1018FAD3@SHSMSX101.ccr.corp.intel.com>
References: <1B4B44D9196EFF41AE41FDA404FC0A1018AF31@SHSMSX101.ccr.corp.intel.com>
	<1346426328.27277.234.camel@zakaz.uk.xensource.com>
	<1B4B44D9196EFF41AE41FDA404FC0A1018FAD3@SHSMSX101.ccr.corp.intel.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: 'Konrad Rzeszutek Wilk' <konrad.wilk@oracle.com>,
	"Keir \(Xen.org\)" <keir@xen.org>, 'Jan Beulich' <JBeulich@suse.com>,
	'xen-devel' <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen4.2-rc3 test result
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-09-06 at 06:59 +0100, Ren, Yongjie wrote:
> > Have we ever supported HVM guest CPU remove? I thought not.
> > 
> > http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1822#c3 seems to
> > describe the behaviour I would expect.
> > 
> If we don't want to support HVM guest CPU remove in near future, I want to close this bug.

Is this something Intel is considering working on? If so then someone
should mention it to George in the 4.3 planning thread.

> > If this is supposed to be an existing feature then is this a regression
> > with xl vs xm or from 4.1 to 4.2?
> > 
> No, it's not a regression from 4.1 to 4.2.
> Neither Xen 4.1 nor 4.2 supports HVM guest CPU remove with xm or xl.

OK, then I can remove it from the TODO list for 4.2, since it certainly
isn't happening for 4.2.0 at this stage.

Thanks for letting me know,
Ian.




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

From xen-devel-bounces@lists.xen.org Thu Sep 06 07:31:39 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 2012 07:31:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9WYb-0008Ng-Ph; Thu, 06 Sep 2012 07:31:21 +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 1T9WYa-0008NO-9n
	for xen-devel@lists.xen.org; Thu, 06 Sep 2012 07:31:20 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1346916673!9823251!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTE5NjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1106 invoked from network); 6 Sep 2012 07:31:14 -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;
	6 Sep 2012 07:31:14 -0000
X-IronPort-AV: E=Sophos;i="4.80,377,1344211200"; d="scan'208";a="14376146"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Sep 2012 07:31:13 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Thu, 6 Sep 2012
	08:31:13 +0100
Message-ID: <1346916672.10570.20.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "Ren, Yongjie" <yongjie.ren@intel.com>
Date: Thu, 6 Sep 2012 08:31:12 +0100
In-Reply-To: <1B4B44D9196EFF41AE41FDA404FC0A1018FAD3@SHSMSX101.ccr.corp.intel.com>
References: <1B4B44D9196EFF41AE41FDA404FC0A1018AF31@SHSMSX101.ccr.corp.intel.com>
	<1346426328.27277.234.camel@zakaz.uk.xensource.com>
	<1B4B44D9196EFF41AE41FDA404FC0A1018FAD3@SHSMSX101.ccr.corp.intel.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: 'Konrad Rzeszutek Wilk' <konrad.wilk@oracle.com>,
	"Keir \(Xen.org\)" <keir@xen.org>, 'Jan Beulich' <JBeulich@suse.com>,
	'xen-devel' <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen4.2-rc3 test result
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-09-06 at 06:59 +0100, Ren, Yongjie wrote:
> > Have we ever supported HVM guest CPU remove? I thought not.
> > 
> > http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1822#c3 seems to
> > describe the behaviour I would expect.
> > 
> If we don't want to support HVM guest CPU remove in near future, I want to close this bug.

Is this something Intel is considering working on? If so then someone
should mention it to George in the 4.3 planning thread.

> > If this is supposed to be an existing feature then is this a regression
> > with xl vs xm or from 4.1 to 4.2?
> > 
> No, it's not a regression from 4.1 to 4.2.
> Neither Xen 4.1 nor 4.2 supports HVM guest CPU remove with xm or xl.

OK, then I can remove it from the TODO list for 4.2, since it certainly
isn't happening for 4.2.0 at this stage.

Thanks for letting me know,
Ian.




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

From xen-devel-bounces@lists.xen.org Thu Sep 06 07:34:48 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 2012 07: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 1T9Wbg-0000Gr-Id; Thu, 06 Sep 2012 07:34:32 +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 1T9Wbe-0000GX-Pa
	for xen-devel@lists.xensource.com; Thu, 06 Sep 2012 07:34:31 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1346916864!9004530!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTE5NjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29098 invoked from network); 6 Sep 2012 07:34:24 -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;
	6 Sep 2012 07:34:24 -0000
X-IronPort-AV: E=Sophos;i="4.80,377,1344211200"; d="scan'208";a="14376222"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Sep 2012 07:34:24 +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.279.1; Thu, 6 Sep 2012
	08:34:23 +0100
Message-ID: <1346916863.10570.22.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 6 Sep 2012 08:34:23 +0100
In-Reply-To: <osstest-13652-mainreport@xen.org>
References: <osstest-13652-mainreport@xen.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [xen-unstable test] 13652: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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-09-06 at 02:38 +0100, xen.org wrote:
> flight 13652 xen-unstable real [real]
> http://www.chiark.greenend.org.uk/~xensrcts/logs/13652/
> 
> 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. 13648

This timed out cloning git://xenbits.xen.org/linux-pvops.git. Might be
an infrastructure thing. xenbits seemed slow to me yesterday as well
(although I thought osstest used a local git cache where possible).

I've had a look and the server load seems reasonable and we don't have
lots of stuck git-daemon processes like we sometimes do.

Hopefully the next pass will be more successful!

Ian.


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

From xen-devel-bounces@lists.xen.org Thu Sep 06 07:34:48 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 2012 07: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 1T9Wbg-0000Gr-Id; Thu, 06 Sep 2012 07:34:32 +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 1T9Wbe-0000GX-Pa
	for xen-devel@lists.xensource.com; Thu, 06 Sep 2012 07:34:31 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1346916864!9004530!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTE5NjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29098 invoked from network); 6 Sep 2012 07:34:24 -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;
	6 Sep 2012 07:34:24 -0000
X-IronPort-AV: E=Sophos;i="4.80,377,1344211200"; d="scan'208";a="14376222"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Sep 2012 07:34:24 +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.279.1; Thu, 6 Sep 2012
	08:34:23 +0100
Message-ID: <1346916863.10570.22.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 6 Sep 2012 08:34:23 +0100
In-Reply-To: <osstest-13652-mainreport@xen.org>
References: <osstest-13652-mainreport@xen.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [xen-unstable test] 13652: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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-09-06 at 02:38 +0100, xen.org wrote:
> flight 13652 xen-unstable real [real]
> http://www.chiark.greenend.org.uk/~xensrcts/logs/13652/
> 
> 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. 13648

This timed out cloning git://xenbits.xen.org/linux-pvops.git. Might be
an infrastructure thing. xenbits seemed slow to me yesterday as well
(although I thought osstest used a local git cache where possible).

I've had a look and the server load seems reasonable and we don't have
lots of stuck git-daemon processes like we sometimes do.

Hopefully the next pass will be more successful!

Ian.


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

From xen-devel-bounces@lists.xen.org Thu Sep 06 07:54:25 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 2012 07: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 1T9Wue-0000TH-CG; Thu, 06 Sep 2012 07:54:08 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <daniel.lezcano@linaro.org>) id 1T9Wuc-0000TC-60
	for xen-devel@lists.xensource.com; Thu, 06 Sep 2012 07:54:06 +0000
Received: from [85.158.138.51:23441] by server-12.bemta-3.messagelabs.com id
	E1/93-10384-D9658405; Thu, 06 Sep 2012 07:54:05 +0000
X-Env-Sender: daniel.lezcano@linaro.org
X-Msg-Ref: server-6.tower-174.messagelabs.com!1346918044!20932782!1
X-Originating-IP: [209.85.214.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1293 invoked from network); 6 Sep 2012 07:54:04 -0000
Received: from mail-bk0-f43.google.com (HELO mail-bk0-f43.google.com)
	(209.85.214.43)
	by server-6.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Sep 2012 07:54:04 -0000
Received: by bkty15 with SMTP id y15so655602bkt.30
	for <xen-devel@lists.xensource.com>;
	Thu, 06 Sep 2012 00:54:04 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=message-id:date:from:user-agent:mime-version:to:cc:subject
	:references:in-reply-to:content-type:content-transfer-encoding
	:x-gm-message-state;
	bh=LIoPcMpSG881BapRyaS3PtYdHoMjjtu/2mxU54uW5/w=;
	b=g9t2zvgcxW6lf+I/ePQa5rDh8mY1/oKyNiKkt4B/vB6Q1KBpkHVZYaxJ2Lxkco4AyI
	8cj5/6notIw2SnwNV4UixuvIBlckJ83/ywfmYuVopLnxWT+SCdWhuQi+keTlz5aGk+9Z
	iTNQ8RFNpGOTJ89PItP2zoV37SSSiOZtbYWer6IbAoj/o+KlFdATTTlv/w8OLJN50zZF
	3ivgKsilaw+ZzV+hIiYLvTLcWqmfZJOvMQhmZKzAmm1dLNw8gftH8P5aq6Qqm9tC5EoP
	IDKlp9s6faOggt1HJehJ/ZLQDmBwEJJ2apsJLZMrAOGM81NhseAIqqYlzo2V9ksSN7lM
	h/HA==
Received: by 10.204.130.156 with SMTP id t28mr313983bks.33.1346918044196;
	Thu, 06 Sep 2012 00:54:04 -0700 (PDT)
Received: from [192.168.1.11] (AToulouse-651-1-16-21.w92-149.abo.wanadoo.fr.
	[92.149.191.21])
	by mx.google.com with ESMTPS id 14sm424072bkw.15.2012.09.06.00.54.01
	(version=SSLv3 cipher=OTHER); Thu, 06 Sep 2012 00:54:03 -0700 (PDT)
Message-ID: <50485698.1070905@linaro.org>
Date: Thu, 06 Sep 2012 09:54:00 +0200
From: Daniel Lezcano <daniel.lezcano@linaro.org>
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:12.0) Gecko/20120430 Thunderbird/12.0.1
MIME-Version: 1.0
To: "Rafael J. Wysocki" <rjw@sisk.pl>
References: <1343164349-28550-1-git-send-email-daniel.lezcano@linaro.org>
	<50410811.70500@linaro.org> <201209010754.58999.rjw@sisk.pl>
	<201209051541.58909.rjw@sisk.pl>
In-Reply-To: <201209051541.58909.rjw@sisk.pl>
X-Gm-Message-State: ALoCoQlwShV6z54ylLUCRopahAuSmh5xWjkEj4mKClojusSV86BFEgOVCx+xxPabEBp8aXhi/cPl
Cc: xen-devel@lists.xensource.com, linaro-dev@lists.linaro.org,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	linux-pm@vger.kernel.org, patches@linaro.org,
	linux-acpi@vger.kernel.org, lenb@kernel.org
Subject: Re: [Xen-devel] [PATCH] acpi : remove power from acpi_processor_cx
	structure
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gMDkvMDUvMjAxMiAwMzo0MSBQTSwgUmFmYWVsIEouIFd5c29ja2kgd3JvdGU6Cj4gT24gU2F0
dXJkYXksIFNlcHRlbWJlciAwMSwgMjAxMiwgUmFmYWVsIEouIFd5c29ja2kgd3JvdGU6Cj4+IE9u
IEZyaWRheSwgQXVndXN0IDMxLCAyMDEyLCBEYW5pZWwgTGV6Y2FubyB3cm90ZToKPj4+IE9uIDA3
LzI0LzIwMTIgMTE6MDYgUE0sIEtvbnJhZCBSemVzenV0ZWsgV2lsayB3cm90ZToKPj4+PiBPbiBU
dWUsIEp1bCAyNCwgMjAxMiBhdCAxMToxMjoyOVBNICswMjAwLCBEYW5pZWwgTGV6Y2FubyB3cm90
ZToKPj4+Pj4gUmVtb3ZlIHRoZSBwb3dlciBmaWVsZCBhcyBpdCBpcyBub3QgdXNlZC4KPj4+Pj4K
Pj4+Pj4gU2lnbmVkLW9mZi1ieTogRGFuaWVsIExlemNhbm8gPGRhbmllbC5sZXpjYW5vQGxpbmFy
by5vcmc+Cj4+Pj4+IENjOiBLb25yYWQgUnplc3p1dGVrIFdpbGsgPGtvbnJhZC53aWxrQG9yYWNs
ZS5jb20+Cj4+Pj4gQWNrZWQuCj4+Pgo+Pj4gSGkgUmFmYWVsLAo+Pj4KPj4+IEkgZGlkIG5vdCBz
ZWUgdGhpcyBwYXRjaCBnb2luZyBpbi4gSXMgaXQgcG9zc2libGUgdG8gbWVyZ2UgaXQgPwo+Pgo+
PiBJIHRoaW5rIHNvLiAgSSdsbCB0YWtlIGNhcmUgb2YgaXQgd2hlbiBJIGdldCBiYWNrIGZyb20g
TGludXhDb24vUGx1bWJlcnMgQ29uZi4KPj4gKGVhcmx5IG5leHQgd2VlaykuCj4gCj4gQXBwbGll
ZCB0byB0aGUgbGludXgtbmV4dCBicmFuY2ggb2YgdGhlIGxpbnV4LXBtLmdpdCB0cmVlIGFzIHYz
LjcgbWF0ZXJpYWwuCgpUaGFua3MgUmFmYWVsLgoKPiBBcmUgdGhlcmUgYW55IG90aGVyIHBhdGNo
ZXMgeW91IHdhbnQgbWUgdG8gY29uc2lkZXIgZm9yIHYzLjc/CgpZZXMgcGxlYXNlLCBJIGhhdmUg
dGhlIHBlciBjcHUgbGF0ZW5jaWVzIHJlYWR5IHRvIGJlIHN1Ym1pdHRlZCBidXQgSQp3YW50IHRv
IGRvIGV4dHJhIHRlc3RpbmcgYmVmb3JlLiBVbmZvcnR1bmF0ZWx5LCB0aGUgbGludXgtcG0tbmV4
dCBoYW5ncwphdCBib290IHRpbWUgb24gbXkgaW50ZWwgZHVhbCBjb3JlIChub3QgcmVsYXRlZCB0
byB0aGUgcGF0Y2hzZXQpLgoKSSBhbSBnaXQgYmlzZWN0aW5nIHJpZ2h0IG5vdy4KClRoYW5rcwog
IC0tIERhbmllbAoKLS0gCiA8aHR0cDovL3d3dy5saW5hcm8ub3JnLz4gTGluYXJvLm9yZyDilIIg
T3BlbiBzb3VyY2Ugc29mdHdhcmUgZm9yIEFSTSBTb0NzCgpGb2xsb3cgTGluYXJvOiAgPGh0dHA6
Ly93d3cuZmFjZWJvb2suY29tL3BhZ2VzL0xpbmFybz4gRmFjZWJvb2sgfAo8aHR0cDovL3R3aXR0
ZXIuY29tLyMhL2xpbmFyb29yZz4gVHdpdHRlciB8CjxodHRwOi8vd3d3LmxpbmFyby5vcmcvbGlu
YXJvLWJsb2cvPiBCbG9nCgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpo
dHRwOi8vbGlzdHMueGVuLm9yZy94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xen.org Thu Sep 06 07:54:25 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 2012 07: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 1T9Wue-0000TH-CG; Thu, 06 Sep 2012 07:54:08 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <daniel.lezcano@linaro.org>) id 1T9Wuc-0000TC-60
	for xen-devel@lists.xensource.com; Thu, 06 Sep 2012 07:54:06 +0000
Received: from [85.158.138.51:23441] by server-12.bemta-3.messagelabs.com id
	E1/93-10384-D9658405; Thu, 06 Sep 2012 07:54:05 +0000
X-Env-Sender: daniel.lezcano@linaro.org
X-Msg-Ref: server-6.tower-174.messagelabs.com!1346918044!20932782!1
X-Originating-IP: [209.85.214.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1293 invoked from network); 6 Sep 2012 07:54:04 -0000
Received: from mail-bk0-f43.google.com (HELO mail-bk0-f43.google.com)
	(209.85.214.43)
	by server-6.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Sep 2012 07:54:04 -0000
Received: by bkty15 with SMTP id y15so655602bkt.30
	for <xen-devel@lists.xensource.com>;
	Thu, 06 Sep 2012 00:54:04 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=message-id:date:from:user-agent:mime-version:to:cc:subject
	:references:in-reply-to:content-type:content-transfer-encoding
	:x-gm-message-state;
	bh=LIoPcMpSG881BapRyaS3PtYdHoMjjtu/2mxU54uW5/w=;
	b=g9t2zvgcxW6lf+I/ePQa5rDh8mY1/oKyNiKkt4B/vB6Q1KBpkHVZYaxJ2Lxkco4AyI
	8cj5/6notIw2SnwNV4UixuvIBlckJ83/ywfmYuVopLnxWT+SCdWhuQi+keTlz5aGk+9Z
	iTNQ8RFNpGOTJ89PItP2zoV37SSSiOZtbYWer6IbAoj/o+KlFdATTTlv/w8OLJN50zZF
	3ivgKsilaw+ZzV+hIiYLvTLcWqmfZJOvMQhmZKzAmm1dLNw8gftH8P5aq6Qqm9tC5EoP
	IDKlp9s6faOggt1HJehJ/ZLQDmBwEJJ2apsJLZMrAOGM81NhseAIqqYlzo2V9ksSN7lM
	h/HA==
Received: by 10.204.130.156 with SMTP id t28mr313983bks.33.1346918044196;
	Thu, 06 Sep 2012 00:54:04 -0700 (PDT)
Received: from [192.168.1.11] (AToulouse-651-1-16-21.w92-149.abo.wanadoo.fr.
	[92.149.191.21])
	by mx.google.com with ESMTPS id 14sm424072bkw.15.2012.09.06.00.54.01
	(version=SSLv3 cipher=OTHER); Thu, 06 Sep 2012 00:54:03 -0700 (PDT)
Message-ID: <50485698.1070905@linaro.org>
Date: Thu, 06 Sep 2012 09:54:00 +0200
From: Daniel Lezcano <daniel.lezcano@linaro.org>
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:12.0) Gecko/20120430 Thunderbird/12.0.1
MIME-Version: 1.0
To: "Rafael J. Wysocki" <rjw@sisk.pl>
References: <1343164349-28550-1-git-send-email-daniel.lezcano@linaro.org>
	<50410811.70500@linaro.org> <201209010754.58999.rjw@sisk.pl>
	<201209051541.58909.rjw@sisk.pl>
In-Reply-To: <201209051541.58909.rjw@sisk.pl>
X-Gm-Message-State: ALoCoQlwShV6z54ylLUCRopahAuSmh5xWjkEj4mKClojusSV86BFEgOVCx+xxPabEBp8aXhi/cPl
Cc: xen-devel@lists.xensource.com, linaro-dev@lists.linaro.org,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	linux-pm@vger.kernel.org, patches@linaro.org,
	linux-acpi@vger.kernel.org, lenb@kernel.org
Subject: Re: [Xen-devel] [PATCH] acpi : remove power from acpi_processor_cx
	structure
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gMDkvMDUvMjAxMiAwMzo0MSBQTSwgUmFmYWVsIEouIFd5c29ja2kgd3JvdGU6Cj4gT24gU2F0
dXJkYXksIFNlcHRlbWJlciAwMSwgMjAxMiwgUmFmYWVsIEouIFd5c29ja2kgd3JvdGU6Cj4+IE9u
IEZyaWRheSwgQXVndXN0IDMxLCAyMDEyLCBEYW5pZWwgTGV6Y2FubyB3cm90ZToKPj4+IE9uIDA3
LzI0LzIwMTIgMTE6MDYgUE0sIEtvbnJhZCBSemVzenV0ZWsgV2lsayB3cm90ZToKPj4+PiBPbiBU
dWUsIEp1bCAyNCwgMjAxMiBhdCAxMToxMjoyOVBNICswMjAwLCBEYW5pZWwgTGV6Y2FubyB3cm90
ZToKPj4+Pj4gUmVtb3ZlIHRoZSBwb3dlciBmaWVsZCBhcyBpdCBpcyBub3QgdXNlZC4KPj4+Pj4K
Pj4+Pj4gU2lnbmVkLW9mZi1ieTogRGFuaWVsIExlemNhbm8gPGRhbmllbC5sZXpjYW5vQGxpbmFy
by5vcmc+Cj4+Pj4+IENjOiBLb25yYWQgUnplc3p1dGVrIFdpbGsgPGtvbnJhZC53aWxrQG9yYWNs
ZS5jb20+Cj4+Pj4gQWNrZWQuCj4+Pgo+Pj4gSGkgUmFmYWVsLAo+Pj4KPj4+IEkgZGlkIG5vdCBz
ZWUgdGhpcyBwYXRjaCBnb2luZyBpbi4gSXMgaXQgcG9zc2libGUgdG8gbWVyZ2UgaXQgPwo+Pgo+
PiBJIHRoaW5rIHNvLiAgSSdsbCB0YWtlIGNhcmUgb2YgaXQgd2hlbiBJIGdldCBiYWNrIGZyb20g
TGludXhDb24vUGx1bWJlcnMgQ29uZi4KPj4gKGVhcmx5IG5leHQgd2VlaykuCj4gCj4gQXBwbGll
ZCB0byB0aGUgbGludXgtbmV4dCBicmFuY2ggb2YgdGhlIGxpbnV4LXBtLmdpdCB0cmVlIGFzIHYz
LjcgbWF0ZXJpYWwuCgpUaGFua3MgUmFmYWVsLgoKPiBBcmUgdGhlcmUgYW55IG90aGVyIHBhdGNo
ZXMgeW91IHdhbnQgbWUgdG8gY29uc2lkZXIgZm9yIHYzLjc/CgpZZXMgcGxlYXNlLCBJIGhhdmUg
dGhlIHBlciBjcHUgbGF0ZW5jaWVzIHJlYWR5IHRvIGJlIHN1Ym1pdHRlZCBidXQgSQp3YW50IHRv
IGRvIGV4dHJhIHRlc3RpbmcgYmVmb3JlLiBVbmZvcnR1bmF0ZWx5LCB0aGUgbGludXgtcG0tbmV4
dCBoYW5ncwphdCBib290IHRpbWUgb24gbXkgaW50ZWwgZHVhbCBjb3JlIChub3QgcmVsYXRlZCB0
byB0aGUgcGF0Y2hzZXQpLgoKSSBhbSBnaXQgYmlzZWN0aW5nIHJpZ2h0IG5vdy4KClRoYW5rcwog
IC0tIERhbmllbAoKLS0gCiA8aHR0cDovL3d3dy5saW5hcm8ub3JnLz4gTGluYXJvLm9yZyDilIIg
T3BlbiBzb3VyY2Ugc29mdHdhcmUgZm9yIEFSTSBTb0NzCgpGb2xsb3cgTGluYXJvOiAgPGh0dHA6
Ly93d3cuZmFjZWJvb2suY29tL3BhZ2VzL0xpbmFybz4gRmFjZWJvb2sgfAo8aHR0cDovL3R3aXR0
ZXIuY29tLyMhL2xpbmFyb29yZz4gVHdpdHRlciB8CjxodHRwOi8vd3d3LmxpbmFyby5vcmcvbGlu
YXJvLWJsb2cvPiBCbG9nCgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpo
dHRwOi8vbGlzdHMueGVuLm9yZy94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xen.org Thu Sep 06 08:18:43 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 2012 08: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 1T9XI8-0001Dg-IS; Thu, 06 Sep 2012 08:18:24 +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 1T9XI6-0001Db-UU
	for xen-devel@lists.xen.org; Thu, 06 Sep 2012 08:18:23 +0000
Received: from [85.158.138.51:57392] by server-11.bemta-3.messagelabs.com id
	CD/C6-30250-E4C58405; Thu, 06 Sep 2012 08:18:22 +0000
X-Env-Sender: yongjie.ren@intel.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1346919500!29019308!1
X-Originating-IP: [192.55.52.93]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjkzID0+IDM0NTYwNQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7291 invoked from network); 6 Sep 2012 08:18:20 -0000
Received: from mga11.intel.com (HELO mga11.intel.com) (192.55.52.93)
	by server-9.tower-174.messagelabs.com with SMTP;
	6 Sep 2012 08:18:20 -0000
Received: from fmsmga002.fm.intel.com ([10.253.24.26])
	by fmsmga102.fm.intel.com with ESMTP; 06 Sep 2012 01:18:19 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.80,377,1344236400"; d="scan'208";a="218474599"
Received: from fmsmsx106.amr.corp.intel.com ([10.19.9.37])
	by fmsmga002.fm.intel.com with ESMTP; 06 Sep 2012 01:18:19 -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; Thu, 6 Sep 2012 01:18:18 -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; Thu, 6 Sep 2012 01:18:18 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.239]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.175]) with mapi id
	14.01.0355.002; Thu, 6 Sep 2012 16:18:17 +0800
From: "Ren, Yongjie" <yongjie.ren@intel.com>
To: Konrad Rzeszutek Wilk <konrad@kernel.org>
Thread-Topic: [Xen-devel] Xen4.2-rc3 test result
Thread-Index: Ac2HShtAedsoaH/XR0eHCAg2EulTuAAEEXiAASd316A=
Date: Thu, 6 Sep 2012 08:18:16 +0000
Message-ID: <1B4B44D9196EFF41AE41FDA404FC0A10190E9D@SHSMSX101.ccr.corp.intel.com>
References: <1B4B44D9196EFF41AE41FDA404FC0A1018AF31@SHSMSX101.ccr.corp.intel.com>
	<20120831172410.GA19756@localhost.localdomain>
In-Reply-To: <20120831172410.GA19756@localhost.localdomain>
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: 'Konrad Rzeszutek Wilk' <konrad.wilk@oracle.com>,
	'Keir Fraser' <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] Xen4.2-rc3 test result
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> -----Original Message-----
> From: Konrad Rzeszutek [mailto:ketuzsezr@gmail.com] On Behalf Of
> Konrad Rzeszutek Wilk
> Sent: Saturday, September 01, 2012 1:24 AM
> To: Ren, Yongjie
> Cc: 'xen-devel'; 'Keir Fraser'; 'Ian Campbell'; 'Jan Beulich'; 'Konrad
> Rzeszutek Wilk'
> Subject: Re: [Xen-devel] Xen4.2-rc3 test result

> > 5. Dom0 cannot be shutdown before PCI detachment from guest and
> when pci assignment conflicts
> >   http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1826
> 
> Um, so you are assigning the same VF to two guests. I am surprised that
> the tools even allowed you to do that. Was 'xm' allowing you to do that?
> 
No, 'xl' doesn't allow me to do that. We can't assignment a device to different guests. 
Sorry, the description of this bug is not accurate. I changed its title to "Dom0 cannot be shut down before PCI device detachment from a guest".
If a guest (with a PCI device assigned) is running, Dom0 will panic when shutting down.

> > 6. Guest hang after resuming from S3
> >   http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1828
> 
> Jan posted some patches to fix that. Can you test with an up-to-date
> guest? (so not RHEL6U1 which does not have the fix).
> 
I tested a RHEL guest with Linux kernel 3.5.3 which already includes Jan's patches you mentioned.
It will not fix this bug.
If using kernel 3.5.3 in guest, the guest totally can't resume after running ' xl trigger $dom_ID s3resume'.
There's some info (as following) in 'xl dmesg' when trying to resume the guest.
(XEN) HVM10: S3 resume called 00fe 0x00099180
(XEN) HVM10: S3 resume jump to 9918:0000
But the guest can't resume.

> > 7. Dom0 S3 resume fails
> >   http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1707
> 
> Yeah, that one is mine. Have some patches for that I will post soonish.
> >
> > Best Regards,
> >      Yongjie (Jay)
> >
> >
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xen.org
> > http://lists.xen.org/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 Sep 06 08:18:43 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 2012 08: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 1T9XI8-0001Dg-IS; Thu, 06 Sep 2012 08:18:24 +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 1T9XI6-0001Db-UU
	for xen-devel@lists.xen.org; Thu, 06 Sep 2012 08:18:23 +0000
Received: from [85.158.138.51:57392] by server-11.bemta-3.messagelabs.com id
	CD/C6-30250-E4C58405; Thu, 06 Sep 2012 08:18:22 +0000
X-Env-Sender: yongjie.ren@intel.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1346919500!29019308!1
X-Originating-IP: [192.55.52.93]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjkzID0+IDM0NTYwNQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7291 invoked from network); 6 Sep 2012 08:18:20 -0000
Received: from mga11.intel.com (HELO mga11.intel.com) (192.55.52.93)
	by server-9.tower-174.messagelabs.com with SMTP;
	6 Sep 2012 08:18:20 -0000
Received: from fmsmga002.fm.intel.com ([10.253.24.26])
	by fmsmga102.fm.intel.com with ESMTP; 06 Sep 2012 01:18:19 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.80,377,1344236400"; d="scan'208";a="218474599"
Received: from fmsmsx106.amr.corp.intel.com ([10.19.9.37])
	by fmsmga002.fm.intel.com with ESMTP; 06 Sep 2012 01:18:19 -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; Thu, 6 Sep 2012 01:18:18 -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; Thu, 6 Sep 2012 01:18:18 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.239]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.175]) with mapi id
	14.01.0355.002; Thu, 6 Sep 2012 16:18:17 +0800
From: "Ren, Yongjie" <yongjie.ren@intel.com>
To: Konrad Rzeszutek Wilk <konrad@kernel.org>
Thread-Topic: [Xen-devel] Xen4.2-rc3 test result
Thread-Index: Ac2HShtAedsoaH/XR0eHCAg2EulTuAAEEXiAASd316A=
Date: Thu, 6 Sep 2012 08:18:16 +0000
Message-ID: <1B4B44D9196EFF41AE41FDA404FC0A10190E9D@SHSMSX101.ccr.corp.intel.com>
References: <1B4B44D9196EFF41AE41FDA404FC0A1018AF31@SHSMSX101.ccr.corp.intel.com>
	<20120831172410.GA19756@localhost.localdomain>
In-Reply-To: <20120831172410.GA19756@localhost.localdomain>
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: 'Konrad Rzeszutek Wilk' <konrad.wilk@oracle.com>,
	'Keir Fraser' <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] Xen4.2-rc3 test result
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> -----Original Message-----
> From: Konrad Rzeszutek [mailto:ketuzsezr@gmail.com] On Behalf Of
> Konrad Rzeszutek Wilk
> Sent: Saturday, September 01, 2012 1:24 AM
> To: Ren, Yongjie
> Cc: 'xen-devel'; 'Keir Fraser'; 'Ian Campbell'; 'Jan Beulich'; 'Konrad
> Rzeszutek Wilk'
> Subject: Re: [Xen-devel] Xen4.2-rc3 test result

> > 5. Dom0 cannot be shutdown before PCI detachment from guest and
> when pci assignment conflicts
> >   http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1826
> 
> Um, so you are assigning the same VF to two guests. I am surprised that
> the tools even allowed you to do that. Was 'xm' allowing you to do that?
> 
No, 'xl' doesn't allow me to do that. We can't assignment a device to different guests. 
Sorry, the description of this bug is not accurate. I changed its title to "Dom0 cannot be shut down before PCI device detachment from a guest".
If a guest (with a PCI device assigned) is running, Dom0 will panic when shutting down.

> > 6. Guest hang after resuming from S3
> >   http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1828
> 
> Jan posted some patches to fix that. Can you test with an up-to-date
> guest? (so not RHEL6U1 which does not have the fix).
> 
I tested a RHEL guest with Linux kernel 3.5.3 which already includes Jan's patches you mentioned.
It will not fix this bug.
If using kernel 3.5.3 in guest, the guest totally can't resume after running ' xl trigger $dom_ID s3resume'.
There's some info (as following) in 'xl dmesg' when trying to resume the guest.
(XEN) HVM10: S3 resume called 00fe 0x00099180
(XEN) HVM10: S3 resume jump to 9918:0000
But the guest can't resume.

> > 7. Dom0 S3 resume fails
> >   http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1707
> 
> Yeah, that one is mine. Have some patches for that I will post soonish.
> >
> > Best Regards,
> >      Yongjie (Jay)
> >
> >
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xen.org
> > http://lists.xen.org/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 Sep 06 08:29:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 2012 08:29:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9XSE-0001NI-Ni; Thu, 06 Sep 2012 08:28:50 +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 1T9XSD-0001NA-4J
	for xen-devel@lists.xen.org; Thu, 06 Sep 2012 08:28:49 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1346920122!9263514!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTE5NjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8420 invoked from network); 6 Sep 2012 08:28:42 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Sep 2012 08:28:42 -0000
X-IronPort-AV: E=Sophos;i="4.80,377,1344211200"; d="scan'208";a="14377812"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Sep 2012 08:28: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.279.1; Thu, 6 Sep 2012
	09:28:41 +0100
Message-ID: <1346920119.23055.17.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "Ren, Yongjie" <yongjie.ren@intel.com>
Date: Thu, 6 Sep 2012 09:28:39 +0100
In-Reply-To: <1B4B44D9196EFF41AE41FDA404FC0A10190E9D@SHSMSX101.ccr.corp.intel.com>
References: <1B4B44D9196EFF41AE41FDA404FC0A1018AF31@SHSMSX101.ccr.corp.intel.com>
	<20120831172410.GA19756@localhost.localdomain>
	<1B4B44D9196EFF41AE41FDA404FC0A10190E9D@SHSMSX101.ccr.corp.intel.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Konrad Rzeszutek Wilk <konrad@kernel.org>,
	'Konrad Rzeszutek Wilk' <konrad.wilk@oracle.com>,
	"Keir \(Xen.org\)" <keir@xen.org>, 'Jan Beulich' <JBeulich@suse.com>,
	'xen-devel' <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen4.2-rc3 test result
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-09-06 at 09:18 +0100, Ren, Yongjie wrote:
> > -----Original Message-----
> > From: Konrad Rzeszutek [mailto:ketuzsezr@gmail.com] On Behalf Of
> > Konrad Rzeszutek Wilk
> > Sent: Saturday, September 01, 2012 1:24 AM
> > To: Ren, Yongjie
> > Cc: 'xen-devel'; 'Keir Fraser'; 'Ian Campbell'; 'Jan Beulich'; 'Konrad
> > Rzeszutek Wilk'
> > Subject: Re: [Xen-devel] Xen4.2-rc3 test result
> 
> > > 5. Dom0 cannot be shutdown before PCI detachment from guest and
> > when pci assignment conflicts
> > >   http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1826
> > 
> > Um, so you are assigning the same VF to two guests. I am surprised that
> > the tools even allowed you to do that. Was 'xm' allowing you to do that?
> > 
> No, 'xl' doesn't allow me to do that. We can't assignment a device to different guests. 
> Sorry, the description of this bug is not accurate. I changed its title to "Dom0 cannot be shut down before PCI device detachment from a guest".
> If a guest (with a PCI device assigned) is running, Dom0 will panic when shutting down.

So this is a dom0 kernel issue and not something relating to 4.2? In
which case I shall remove it from the 4.2 TODO list.

Ian.


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

From xen-devel-bounces@lists.xen.org Thu Sep 06 08:29:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 2012 08:29:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9XSE-0001NI-Ni; Thu, 06 Sep 2012 08:28:50 +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 1T9XSD-0001NA-4J
	for xen-devel@lists.xen.org; Thu, 06 Sep 2012 08:28:49 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1346920122!9263514!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTE5NjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8420 invoked from network); 6 Sep 2012 08:28:42 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Sep 2012 08:28:42 -0000
X-IronPort-AV: E=Sophos;i="4.80,377,1344211200"; d="scan'208";a="14377812"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Sep 2012 08:28: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.279.1; Thu, 6 Sep 2012
	09:28:41 +0100
Message-ID: <1346920119.23055.17.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "Ren, Yongjie" <yongjie.ren@intel.com>
Date: Thu, 6 Sep 2012 09:28:39 +0100
In-Reply-To: <1B4B44D9196EFF41AE41FDA404FC0A10190E9D@SHSMSX101.ccr.corp.intel.com>
References: <1B4B44D9196EFF41AE41FDA404FC0A1018AF31@SHSMSX101.ccr.corp.intel.com>
	<20120831172410.GA19756@localhost.localdomain>
	<1B4B44D9196EFF41AE41FDA404FC0A10190E9D@SHSMSX101.ccr.corp.intel.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Konrad Rzeszutek Wilk <konrad@kernel.org>,
	'Konrad Rzeszutek Wilk' <konrad.wilk@oracle.com>,
	"Keir \(Xen.org\)" <keir@xen.org>, 'Jan Beulich' <JBeulich@suse.com>,
	'xen-devel' <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen4.2-rc3 test result
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-09-06 at 09:18 +0100, Ren, Yongjie wrote:
> > -----Original Message-----
> > From: Konrad Rzeszutek [mailto:ketuzsezr@gmail.com] On Behalf Of
> > Konrad Rzeszutek Wilk
> > Sent: Saturday, September 01, 2012 1:24 AM
> > To: Ren, Yongjie
> > Cc: 'xen-devel'; 'Keir Fraser'; 'Ian Campbell'; 'Jan Beulich'; 'Konrad
> > Rzeszutek Wilk'
> > Subject: Re: [Xen-devel] Xen4.2-rc3 test result
> 
> > > 5. Dom0 cannot be shutdown before PCI detachment from guest and
> > when pci assignment conflicts
> > >   http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1826
> > 
> > Um, so you are assigning the same VF to two guests. I am surprised that
> > the tools even allowed you to do that. Was 'xm' allowing you to do that?
> > 
> No, 'xl' doesn't allow me to do that. We can't assignment a device to different guests. 
> Sorry, the description of this bug is not accurate. I changed its title to "Dom0 cannot be shut down before PCI device detachment from a guest".
> If a guest (with a PCI device assigned) is running, Dom0 will panic when shutting down.

So this is a dom0 kernel issue and not something relating to 4.2? In
which case I shall remove it from the 4.2 TODO list.

Ian.


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

From xen-devel-bounces@lists.xen.org Thu Sep 06 08:32:25 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 2012 08: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 1T9XVP-0001UT-TW; Thu, 06 Sep 2012 08:32:07 +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 1T9XVO-0001UL-AN
	for xen-devel@lists.xen.org; Thu, 06 Sep 2012 08:32:06 +0000
Received: from [85.158.138.51:40072] by server-5.bemta-3.messagelabs.com id
	5C/E3-13133-58F58405; Thu, 06 Sep 2012 08:32:05 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1346920324!20081096!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTE5NjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4476 invoked from network); 6 Sep 2012 08:32:05 -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 Sep 2012 08:32:05 -0000
X-IronPort-AV: E=Sophos;i="4.80,379,1344211200"; d="scan'208";a="14377886"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Sep 2012 08:31:41 +0000
Received: from Roger-2.local (10.31.3.231) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Thu, 6 Sep 2012
	09:31:41 +0100
Message-ID: <50485F26.4070400@citrix.com>
Date: Thu, 6 Sep 2012 10:30:30 +0200
From: Roger Pau Monne <roger.pau@citrix.com>
User-Agent: Postbox 3.0.5 (Macintosh/20120826)
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <1346771812-98690-1-git-send-email-roger.pau@citrix.com>
	<1346916542.10570.18.camel@dagon.hellion.org.uk>
In-Reply-To: <1346916542.10570.18.camel@dagon.hellion.org.uk>
X-Enigmail-Version: 1.2.2
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v2 1/2] libxl: fix usage of backend
 parameter and run_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

Ian Campbell wrote:
> On Tue, 2012-09-04 at 16:16 +0100, Roger Pau Monne wrote:
>> vif interfaces allows the user to specify the domain that should run
>> the backend (also known as driver domain) using the 'backend'
>> parameter. This is not compatible with run_hotplug_scripts=1, since
>> libxl can only run the hotplug scripts from the Domain 0.
> 
> Sorry but I think in the end this has missed the cut-off for 4.2.0 (we
> are cutting the final RC tomorrow).
> 
> We should be branching soon after the final RC which means 4.3
> development will open in unstable shortly. We should take this into
> unstable then and consider it for 4.2.1.
> 
> In the meantime I suppose we should mention this in the release notes.

Do you think we could commit the docs change
(xl-network-configuration.markdown) only? So people can know that this
won't work in current release.

Sorry for the delay.


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

From xen-devel-bounces@lists.xen.org Thu Sep 06 08:32:25 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 2012 08: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 1T9XVP-0001UT-TW; Thu, 06 Sep 2012 08:32:07 +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 1T9XVO-0001UL-AN
	for xen-devel@lists.xen.org; Thu, 06 Sep 2012 08:32:06 +0000
Received: from [85.158.138.51:40072] by server-5.bemta-3.messagelabs.com id
	5C/E3-13133-58F58405; Thu, 06 Sep 2012 08:32:05 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1346920324!20081096!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTE5NjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4476 invoked from network); 6 Sep 2012 08:32:05 -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 Sep 2012 08:32:05 -0000
X-IronPort-AV: E=Sophos;i="4.80,379,1344211200"; d="scan'208";a="14377886"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Sep 2012 08:31:41 +0000
Received: from Roger-2.local (10.31.3.231) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Thu, 6 Sep 2012
	09:31:41 +0100
Message-ID: <50485F26.4070400@citrix.com>
Date: Thu, 6 Sep 2012 10:30:30 +0200
From: Roger Pau Monne <roger.pau@citrix.com>
User-Agent: Postbox 3.0.5 (Macintosh/20120826)
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <1346771812-98690-1-git-send-email-roger.pau@citrix.com>
	<1346916542.10570.18.camel@dagon.hellion.org.uk>
In-Reply-To: <1346916542.10570.18.camel@dagon.hellion.org.uk>
X-Enigmail-Version: 1.2.2
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v2 1/2] libxl: fix usage of backend
 parameter and run_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

Ian Campbell wrote:
> On Tue, 2012-09-04 at 16:16 +0100, Roger Pau Monne wrote:
>> vif interfaces allows the user to specify the domain that should run
>> the backend (also known as driver domain) using the 'backend'
>> parameter. This is not compatible with run_hotplug_scripts=1, since
>> libxl can only run the hotplug scripts from the Domain 0.
> 
> Sorry but I think in the end this has missed the cut-off for 4.2.0 (we
> are cutting the final RC tomorrow).
> 
> We should be branching soon after the final RC which means 4.3
> development will open in unstable shortly. We should take this into
> unstable then and consider it for 4.2.1.
> 
> In the meantime I suppose we should mention this in the release notes.

Do you think we could commit the docs change
(xl-network-configuration.markdown) only? So people can know that this
won't work in current release.

Sorry for the delay.


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

From xen-devel-bounces@lists.xen.org Thu Sep 06 08:36:34 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 2012 08:36:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9XZS-0001fe-J0; Thu, 06 Sep 2012 08:36:18 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <kks.kbase@gmail.com>) id 1T9XVF-0001Te-C4
	for xen-devel@lists.xen.org; Thu, 06 Sep 2012 08:31:57 +0000
Received: from [85.158.139.83:30605] by server-4.bemta-5.messagelabs.com id
	A9/F7-23042-C7F58405; Thu, 06 Sep 2012 08:31:56 +0000
X-Env-Sender: kks.kbase@gmail.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1346920315!24926816!1
X-Originating-IP: [209.85.214.45]
X-SpamReason: No, hits=3.3 required=7.0 tests=HTML_60_70,HTML_MESSAGE,
	HTML_OBFUSCATE_20_30,ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21875 invoked from network); 6 Sep 2012 08:31:55 -0000
Received: from mail-bk0-f45.google.com (HELO mail-bk0-f45.google.com)
	(209.85.214.45)
	by server-7.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Sep 2012 08:31:55 -0000
Received: by bkcji1 with SMTP id ji1so640256bkc.32
	for <multiple recipients>; Thu, 06 Sep 2012 01:31: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=lOuOuo1q2EMSOyeWBKK6mpZh9TtU/kWkbEKqNvQCppM=;
	b=IjoApTWOOmB9biHLR/aDnHgZfSQjmE6JKicV5m5NqEHI0olIuuFmf+WjA0RRObd9xO
	H6ialTy5vhX+DBDqmtJTiugQntvZ3Xp0eXtVM3wL5h755u0sue2VMDsdt3Vt2xXHjFh/
	9x+ExvtD81SES1qFojH5Jx5cDXZvThhzQP/eRKjAy3jxIxP+1+Y1T4OOE6nhClvWP7eq
	1wqV+qOrm4Q9FRiqAAa3GUu0vzQhN7fGq6K/LXDyu8cBX8l1hy7rAmurtbPuR7+9LeQp
	0IQ9h/Cyb6y3GJB+cn7H/spZR8pJkMT7oL2+eWc/8LPme/tCooth9ZSGa555mcToSr6U
	9x2w==
MIME-Version: 1.0
Received: by 10.204.152.136 with SMTP id g8mr363414bkw.44.1346920314713; Thu,
	06 Sep 2012 01:31:54 -0700 (PDT)
Received: by 10.204.56.134 with HTTP; Thu, 6 Sep 2012 01:31:54 -0700 (PDT)
Date: Thu, 6 Sep 2012 14:01:54 +0530
Message-ID: <CAPU-Ed65dguruSSNrGxk4PmejTJQT7zELXpNAxJULCmdwEvpnA@mail.gmail.com>
From: kk s <kks.kbase@gmail.com>
To: xen-users@lists.xen.org, xen-devel@lists.xen.org
X-Mailman-Approved-At: Thu, 06 Sep 2012 08:36:17 +0000
Subject: [Xen-devel] Security patches
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============7764777337874184537=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============7764777337874184537==
Content-Type: multipart/alternative; boundary=0015175d0998e637f704c90452ff

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

Hi,

Can anyone give the patch file download link for the below xen security for
xen version 3.4 and 4.1? Since I couldn't find the downloadable patch file
for some of the CVE's.

CVE-2012-0029 <http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-0029>
- http://lists.xen.org/archives/html/xen-devel/2012-02/msg00212.html
(There is no download link for both xen 3.4 and 4.1)
CVE-2012-2934 <http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-2934>
- http://lists.xen.org/archives/html/xen-announce/2012-06/msg00002.html
(There is no patch file to download of xen 3.4)
CVE-2012-3432 <http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-3432>
- http://lists.xen.org/archives/html/xen-devel/2012-07/msg01649.html
(There is no download link for both xen 3.4 and 4.1)
CVE-2012-3433 <http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-3433>
- http://lists.xen.org/archives/html/xen-devel/2012-08/msg00855.html
(There is no download link for both xen 3.4 and 4.1)
CVE-2012-3497 <http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-3497>
- http://lists.xen.org/archives/html/xen-announce/2012-09/msg00006.html
(There is no download link for patch)

Also I have some doubts for the below CVE's.

CVE-2012-3496 <http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-3496>
- Is this vulnerability affected for xen 4.x only or it does include for
xen 3.4 too? Since the patch name was
*xsa14-xen-3.4-and-4.x.patch<http://lists.xen.org/archives/html/xen-announce/2012-09/bin_3Uh1V9Hnc.bin>
*  http://lists.xen.org/archives/html/xen-announce/2012-09/msg00002.html
CVE-2012-3516 <http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-3516>
- Shall I apply this unstable for patch for xen4.2 too?
http://lists.xen.org/archives/html/xen-announce/2012-09/msg00004.html

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

Hi,<br><br>Can anyone give the patch file download link for the below xen s=
ecurity for xen version 3.4 and 4.1? Since I couldn&#39;t find the download=
able patch file for some of the CVE&#39;s.<br><br><a href=3D"http://cve.mit=
re.org/cgi-bin/cvename.cgi?name=3DCVE-2012-0029" class=3D"external text" ti=
tle=3D"http://cve.mitre.org/cgi-bin/cvename.cgi?name=3DCVE-2012-0029" rel=
=3D"nofollow">CVE-2012-0029</a>=A0=A0 - <a href=3D"http://lists.xen.org/arc=
hives/html/xen-devel/2012-02/msg00212.html">http://lists.xen.org/archives/h=
tml/xen-devel/2012-02/msg00212.html</a>=A0 (There is no download link for b=
oth xen 3.4 and 4.1)<br>
<a href=3D"http://cve.mitre.org/cgi-bin/cvename.cgi?name=3DCVE-2012-2934" c=
lass=3D"external text" title=3D"http://cve.mitre.org/cgi-bin/cvename.cgi?na=
me=3DCVE-2012-2934" rel=3D"nofollow">CVE-2012-2934</a>=A0=A0 - <a href=3D"h=
ttp://lists.xen.org/archives/html/xen-announce/2012-06/msg00002.html">http:=
//lists.xen.org/archives/html/xen-announce/2012-06/msg00002.html</a>=A0 (Th=
ere is no patch file to download of xen 3.4)<br>
<a href=3D"http://cve.mitre.org/cgi-bin/cvename.cgi?name=3DCVE-2012-3432" c=
lass=3D"external text" title=3D"http://cve.mitre.org/cgi-bin/cvename.cgi?na=
me=3DCVE-2012-3432" rel=3D"nofollow">CVE-2012-3432</a>=A0=A0 - <a href=3D"h=
ttp://lists.xen.org/archives/html/xen-devel/2012-07/msg01649.html">http://l=
ists.xen.org/archives/html/xen-devel/2012-07/msg01649.html</a>=A0 (There is=
 no download link for both xen 3.4 and 4.1)<br>
<a href=3D"http://cve.mitre.org/cgi-bin/cvename.cgi?name=3DCVE-2012-3433" c=
lass=3D"external text" title=3D"http://cve.mitre.org/cgi-bin/cvename.cgi?na=
me=3DCVE-2012-3433" rel=3D"nofollow">CVE-2012-3433</a>=A0=A0 - <a href=3D"h=
ttp://lists.xen.org/archives/html/xen-devel/2012-08/msg00855.html">http://l=
ists.xen.org/archives/html/xen-devel/2012-08/msg00855.html</a>=A0 (There is=
 no download link for both xen 3.4 and 4.1)<br>
<a href=3D"http://cve.mitre.org/cgi-bin/cvename.cgi?name=3DCVE-2012-3497" c=
lass=3D"external text" title=3D"http://cve.mitre.org/cgi-bin/cvename.cgi?na=
me=3DCVE-2012-3497" rel=3D"nofollow">CVE-2012-3497</a>=A0=A0 - <a href=3D"h=
ttp://lists.xen.org/archives/html/xen-announce/2012-09/msg00006.html">http:=
//lists.xen.org/archives/html/xen-announce/2012-09/msg00006.html</a>=A0 (Th=
ere is no download link for patch)<br>
<br>Also I have some doubts for the below CVE&#39;s.<br><br><a href=3D"http=
://cve.mitre.org/cgi-bin/cvename.cgi?name=3DCVE-2012-3496" class=3D"externa=
l text" title=3D"http://cve.mitre.org/cgi-bin/cvename.cgi?name=3DCVE-2012-3=
496" rel=3D"nofollow">CVE-2012-3496</a>=A0 - Is this vulnerability affected=
 for xen 4.x only or it does include for xen 3.4 too? Since the patch name =
was <strong><a href=3D"http://lists.xen.org/archives/html/xen-announce/2012=
-09/bin_3Uh1V9Hnc.bin"><tt>xsa14-xen-3.4-and-4.x.patch</tt></a></strong>=A0=
 <a href=3D"http://lists.xen.org/archives/html/xen-announce/2012-09/msg0000=
2.html">http://lists.xen.org/archives/html/xen-announce/2012-09/msg00002.ht=
ml</a><br>
<a href=3D"http://cve.mitre.org/cgi-bin/cvename.cgi?name=3DCVE-2012-3516" c=
lass=3D"external text" title=3D"http://cve.mitre.org/cgi-bin/cvename.cgi?na=
me=3DCVE-2012-3516" rel=3D"nofollow">CVE-2012-3516</a>=A0 - Shall I apply t=
his unstable for patch for xen4.2 too?=A0=A0 <a href=3D"http://lists.xen.or=
g/archives/html/xen-announce/2012-09/msg00004.html">http://lists.xen.org/ar=
chives/html/xen-announce/2012-09/msg00004.html</a><br>
<br><br>

--0015175d0998e637f704c90452ff--


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

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

--===============7764777337874184537==--


From xen-devel-bounces@lists.xen.org Thu Sep 06 08:36:34 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 2012 08:36:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9XZS-0001fe-J0; Thu, 06 Sep 2012 08:36:18 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <kks.kbase@gmail.com>) id 1T9XVF-0001Te-C4
	for xen-devel@lists.xen.org; Thu, 06 Sep 2012 08:31:57 +0000
Received: from [85.158.139.83:30605] by server-4.bemta-5.messagelabs.com id
	A9/F7-23042-C7F58405; Thu, 06 Sep 2012 08:31:56 +0000
X-Env-Sender: kks.kbase@gmail.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1346920315!24926816!1
X-Originating-IP: [209.85.214.45]
X-SpamReason: No, hits=3.3 required=7.0 tests=HTML_60_70,HTML_MESSAGE,
	HTML_OBFUSCATE_20_30,ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21875 invoked from network); 6 Sep 2012 08:31:55 -0000
Received: from mail-bk0-f45.google.com (HELO mail-bk0-f45.google.com)
	(209.85.214.45)
	by server-7.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Sep 2012 08:31:55 -0000
Received: by bkcji1 with SMTP id ji1so640256bkc.32
	for <multiple recipients>; Thu, 06 Sep 2012 01:31: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=lOuOuo1q2EMSOyeWBKK6mpZh9TtU/kWkbEKqNvQCppM=;
	b=IjoApTWOOmB9biHLR/aDnHgZfSQjmE6JKicV5m5NqEHI0olIuuFmf+WjA0RRObd9xO
	H6ialTy5vhX+DBDqmtJTiugQntvZ3Xp0eXtVM3wL5h755u0sue2VMDsdt3Vt2xXHjFh/
	9x+ExvtD81SES1qFojH5Jx5cDXZvThhzQP/eRKjAy3jxIxP+1+Y1T4OOE6nhClvWP7eq
	1wqV+qOrm4Q9FRiqAAa3GUu0vzQhN7fGq6K/LXDyu8cBX8l1hy7rAmurtbPuR7+9LeQp
	0IQ9h/Cyb6y3GJB+cn7H/spZR8pJkMT7oL2+eWc/8LPme/tCooth9ZSGa555mcToSr6U
	9x2w==
MIME-Version: 1.0
Received: by 10.204.152.136 with SMTP id g8mr363414bkw.44.1346920314713; Thu,
	06 Sep 2012 01:31:54 -0700 (PDT)
Received: by 10.204.56.134 with HTTP; Thu, 6 Sep 2012 01:31:54 -0700 (PDT)
Date: Thu, 6 Sep 2012 14:01:54 +0530
Message-ID: <CAPU-Ed65dguruSSNrGxk4PmejTJQT7zELXpNAxJULCmdwEvpnA@mail.gmail.com>
From: kk s <kks.kbase@gmail.com>
To: xen-users@lists.xen.org, xen-devel@lists.xen.org
X-Mailman-Approved-At: Thu, 06 Sep 2012 08:36:17 +0000
Subject: [Xen-devel] Security patches
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============7764777337874184537=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============7764777337874184537==
Content-Type: multipart/alternative; boundary=0015175d0998e637f704c90452ff

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

Hi,

Can anyone give the patch file download link for the below xen security for
xen version 3.4 and 4.1? Since I couldn't find the downloadable patch file
for some of the CVE's.

CVE-2012-0029 <http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-0029>
- http://lists.xen.org/archives/html/xen-devel/2012-02/msg00212.html
(There is no download link for both xen 3.4 and 4.1)
CVE-2012-2934 <http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-2934>
- http://lists.xen.org/archives/html/xen-announce/2012-06/msg00002.html
(There is no patch file to download of xen 3.4)
CVE-2012-3432 <http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-3432>
- http://lists.xen.org/archives/html/xen-devel/2012-07/msg01649.html
(There is no download link for both xen 3.4 and 4.1)
CVE-2012-3433 <http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-3433>
- http://lists.xen.org/archives/html/xen-devel/2012-08/msg00855.html
(There is no download link for both xen 3.4 and 4.1)
CVE-2012-3497 <http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-3497>
- http://lists.xen.org/archives/html/xen-announce/2012-09/msg00006.html
(There is no download link for patch)

Also I have some doubts for the below CVE's.

CVE-2012-3496 <http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-3496>
- Is this vulnerability affected for xen 4.x only or it does include for
xen 3.4 too? Since the patch name was
*xsa14-xen-3.4-and-4.x.patch<http://lists.xen.org/archives/html/xen-announce/2012-09/bin_3Uh1V9Hnc.bin>
*  http://lists.xen.org/archives/html/xen-announce/2012-09/msg00002.html
CVE-2012-3516 <http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-3516>
- Shall I apply this unstable for patch for xen4.2 too?
http://lists.xen.org/archives/html/xen-announce/2012-09/msg00004.html

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

Hi,<br><br>Can anyone give the patch file download link for the below xen s=
ecurity for xen version 3.4 and 4.1? Since I couldn&#39;t find the download=
able patch file for some of the CVE&#39;s.<br><br><a href=3D"http://cve.mit=
re.org/cgi-bin/cvename.cgi?name=3DCVE-2012-0029" class=3D"external text" ti=
tle=3D"http://cve.mitre.org/cgi-bin/cvename.cgi?name=3DCVE-2012-0029" rel=
=3D"nofollow">CVE-2012-0029</a>=A0=A0 - <a href=3D"http://lists.xen.org/arc=
hives/html/xen-devel/2012-02/msg00212.html">http://lists.xen.org/archives/h=
tml/xen-devel/2012-02/msg00212.html</a>=A0 (There is no download link for b=
oth xen 3.4 and 4.1)<br>
<a href=3D"http://cve.mitre.org/cgi-bin/cvename.cgi?name=3DCVE-2012-2934" c=
lass=3D"external text" title=3D"http://cve.mitre.org/cgi-bin/cvename.cgi?na=
me=3DCVE-2012-2934" rel=3D"nofollow">CVE-2012-2934</a>=A0=A0 - <a href=3D"h=
ttp://lists.xen.org/archives/html/xen-announce/2012-06/msg00002.html">http:=
//lists.xen.org/archives/html/xen-announce/2012-06/msg00002.html</a>=A0 (Th=
ere is no patch file to download of xen 3.4)<br>
<a href=3D"http://cve.mitre.org/cgi-bin/cvename.cgi?name=3DCVE-2012-3432" c=
lass=3D"external text" title=3D"http://cve.mitre.org/cgi-bin/cvename.cgi?na=
me=3DCVE-2012-3432" rel=3D"nofollow">CVE-2012-3432</a>=A0=A0 - <a href=3D"h=
ttp://lists.xen.org/archives/html/xen-devel/2012-07/msg01649.html">http://l=
ists.xen.org/archives/html/xen-devel/2012-07/msg01649.html</a>=A0 (There is=
 no download link for both xen 3.4 and 4.1)<br>
<a href=3D"http://cve.mitre.org/cgi-bin/cvename.cgi?name=3DCVE-2012-3433" c=
lass=3D"external text" title=3D"http://cve.mitre.org/cgi-bin/cvename.cgi?na=
me=3DCVE-2012-3433" rel=3D"nofollow">CVE-2012-3433</a>=A0=A0 - <a href=3D"h=
ttp://lists.xen.org/archives/html/xen-devel/2012-08/msg00855.html">http://l=
ists.xen.org/archives/html/xen-devel/2012-08/msg00855.html</a>=A0 (There is=
 no download link for both xen 3.4 and 4.1)<br>
<a href=3D"http://cve.mitre.org/cgi-bin/cvename.cgi?name=3DCVE-2012-3497" c=
lass=3D"external text" title=3D"http://cve.mitre.org/cgi-bin/cvename.cgi?na=
me=3DCVE-2012-3497" rel=3D"nofollow">CVE-2012-3497</a>=A0=A0 - <a href=3D"h=
ttp://lists.xen.org/archives/html/xen-announce/2012-09/msg00006.html">http:=
//lists.xen.org/archives/html/xen-announce/2012-09/msg00006.html</a>=A0 (Th=
ere is no download link for patch)<br>
<br>Also I have some doubts for the below CVE&#39;s.<br><br><a href=3D"http=
://cve.mitre.org/cgi-bin/cvename.cgi?name=3DCVE-2012-3496" class=3D"externa=
l text" title=3D"http://cve.mitre.org/cgi-bin/cvename.cgi?name=3DCVE-2012-3=
496" rel=3D"nofollow">CVE-2012-3496</a>=A0 - Is this vulnerability affected=
 for xen 4.x only or it does include for xen 3.4 too? Since the patch name =
was <strong><a href=3D"http://lists.xen.org/archives/html/xen-announce/2012=
-09/bin_3Uh1V9Hnc.bin"><tt>xsa14-xen-3.4-and-4.x.patch</tt></a></strong>=A0=
 <a href=3D"http://lists.xen.org/archives/html/xen-announce/2012-09/msg0000=
2.html">http://lists.xen.org/archives/html/xen-announce/2012-09/msg00002.ht=
ml</a><br>
<a href=3D"http://cve.mitre.org/cgi-bin/cvename.cgi?name=3DCVE-2012-3516" c=
lass=3D"external text" title=3D"http://cve.mitre.org/cgi-bin/cvename.cgi?na=
me=3DCVE-2012-3516" rel=3D"nofollow">CVE-2012-3516</a>=A0 - Shall I apply t=
his unstable for patch for xen4.2 too?=A0=A0 <a href=3D"http://lists.xen.or=
g/archives/html/xen-announce/2012-09/msg00004.html">http://lists.xen.org/ar=
chives/html/xen-announce/2012-09/msg00004.html</a><br>
<br><br>

--0015175d0998e637f704c90452ff--


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

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

--===============7764777337874184537==--


From xen-devel-bounces@lists.xen.org Thu Sep 06 08:49:09 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 2012 08: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 1T9Xlc-0001xL-Sd; Thu, 06 Sep 2012 08:48:52 +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 1T9Xlb-0001xD-AM
	for xen-devel@lists.xen.org; Thu, 06 Sep 2012 08:48:51 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1346921325!9792913!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTE5NjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24612 invoked from network); 6 Sep 2012 08:48:45 -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;
	6 Sep 2012 08:48:45 -0000
X-IronPort-AV: E=Sophos;i="4.80,379,1344211200"; d="scan'208";a="14378334"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Sep 2012 08:48: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.279.1; Thu, 6 Sep 2012
	09:48:44 +0100
Message-ID: <1346921323.23055.20.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Roger Pau Monne <roger.pau@citrix.com>
Date: Thu, 6 Sep 2012 09:48:43 +0100
In-Reply-To: <50485F26.4070400@citrix.com>
References: <1346771812-98690-1-git-send-email-roger.pau@citrix.com>
	<1346916542.10570.18.camel@dagon.hellion.org.uk>
	<50485F26.4070400@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-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 1/2] libxl: fix usage of backend
 parameter and run_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

On Thu, 2012-09-06 at 09:30 +0100, Roger Pau Monne wrote:
> Ian Campbell wrote:
> > On Tue, 2012-09-04 at 16:16 +0100, Roger Pau Monne wrote:
> >> vif interfaces allows the user to specify the domain that should run
> >> the backend (also known as driver domain) using the 'backend'
> >> parameter. This is not compatible with run_hotplug_scripts=1, since
> >> libxl can only run the hotplug scripts from the Domain 0.
> > 
> > Sorry but I think in the end this has missed the cut-off for 4.2.0 (we
> > are cutting the final RC tomorrow).
> > 
> > We should be branching soon after the final RC which means 4.3
> > development will open in unstable shortly. We should take this into
> > unstable then and consider it for 4.2.1.
> > 
> > In the meantime I suppose we should mention this in the release notes.
> 
> Do you think we could commit the docs change
> (xl-network-configuration.markdown) only? So people can know that this
> won't work in current release.

I think we can take some docs only patches after RC4, I don't want to
taker any patches before then since we need a test pass before we tag it
tomorrow.

> Sorry for the delay.

S'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 Sep 06 08:49:09 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 2012 08: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 1T9Xlc-0001xL-Sd; Thu, 06 Sep 2012 08:48:52 +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 1T9Xlb-0001xD-AM
	for xen-devel@lists.xen.org; Thu, 06 Sep 2012 08:48:51 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1346921325!9792913!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTE5NjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24612 invoked from network); 6 Sep 2012 08:48:45 -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;
	6 Sep 2012 08:48:45 -0000
X-IronPort-AV: E=Sophos;i="4.80,379,1344211200"; d="scan'208";a="14378334"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Sep 2012 08:48: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.279.1; Thu, 6 Sep 2012
	09:48:44 +0100
Message-ID: <1346921323.23055.20.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Roger Pau Monne <roger.pau@citrix.com>
Date: Thu, 6 Sep 2012 09:48:43 +0100
In-Reply-To: <50485F26.4070400@citrix.com>
References: <1346771812-98690-1-git-send-email-roger.pau@citrix.com>
	<1346916542.10570.18.camel@dagon.hellion.org.uk>
	<50485F26.4070400@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-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 1/2] libxl: fix usage of backend
 parameter and run_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

On Thu, 2012-09-06 at 09:30 +0100, Roger Pau Monne wrote:
> Ian Campbell wrote:
> > On Tue, 2012-09-04 at 16:16 +0100, Roger Pau Monne wrote:
> >> vif interfaces allows the user to specify the domain that should run
> >> the backend (also known as driver domain) using the 'backend'
> >> parameter. This is not compatible with run_hotplug_scripts=1, since
> >> libxl can only run the hotplug scripts from the Domain 0.
> > 
> > Sorry but I think in the end this has missed the cut-off for 4.2.0 (we
> > are cutting the final RC tomorrow).
> > 
> > We should be branching soon after the final RC which means 4.3
> > development will open in unstable shortly. We should take this into
> > unstable then and consider it for 4.2.1.
> > 
> > In the meantime I suppose we should mention this in the release notes.
> 
> Do you think we could commit the docs change
> (xl-network-configuration.markdown) only? So people can know that this
> won't work in current release.

I think we can take some docs only patches after RC4, I don't want to
taker any patches before then since we need a test pass before we tag it
tomorrow.

> Sorry for the delay.

S'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 Sep 06 08:57:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 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 1T9XtI-00028i-Uc; Thu, 06 Sep 2012 08:56: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 1T9XtG-00028N-RM
	for xen-devel@lists.xen.org; Thu, 06 Sep 2012 08:56:47 +0000
Received: from [85.158.143.35:60558] by server-1.bemta-4.messagelabs.com id
	70/E2-12504-E4568405; Thu, 06 Sep 2012 08:56:46 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1346921804!12497002!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTE5NzY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2094 invoked from network); 6 Sep 2012 08:56:44 -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;
	6 Sep 2012 08:56:44 -0000
X-IronPort-AV: E=Sophos;i="4.80,379,1344211200"; d="scan'208";a="14378549"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Sep 2012 08:56: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.279.1; Thu, 6 Sep 2012
	09:56:44 +0100
Message-ID: <1346921802.23055.26.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: kk s <kks.kbase@gmail.com>
Date: Thu, 6 Sep 2012 09:56:42 +0100
In-Reply-To: <CAPU-Ed65dguruSSNrGxk4PmejTJQT7zELXpNAxJULCmdwEvpnA@mail.gmail.com>
References: <CAPU-Ed65dguruSSNrGxk4PmejTJQT7zELXpNAxJULCmdwEvpnA@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-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] Security patches
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-09-06 at 09:31 +0100, kk s wrote:
> Hi,
> 
> Can anyone give the patch file download link for the below xen
> security for xen version 3.4 and 4.1? Since I couldn't find the
> downloadable patch file for some of the CVE's.
> 
> CVE-2012-0029   - http://lists.xen.org/archives/html/xen-devel/2012-02/msg00212.html  (There is no download link for both xen 3.4 and 4.1)
> CVE-2012-2934   - http://lists.xen.org/archives/html/xen-announce/2012-06/msg00002.html  (There is no patch file to download of xen 3.4)
> CVE-2012-3432   - http://lists.xen.org/archives/html/xen-devel/2012-07/msg01649.html  (There is no download link for both xen 3.4 and 4.1)
> CVE-2012-3433   - http://lists.xen.org/archives/html/xen-devel/2012-08/msg00855.html  (There is no download link for both xen 3.4 and 4.1)

It looks to me like there are changeset references and/or patches for
all of these in the advisories. You might find it easier to follow: 
        http://wiki.xen.org/wiki/Security_Announcements

You can also always look in the appropriate xen-X.Y-testing.hg tree for
the fix.

> CVE-2012-3497   - http://lists.xen.org/archives/html/xen-announce/2012-09/msg00006.html  (There is no download link for patch)

This is quite clearly explained in the advisory.

> Also I have some doubts for the below CVE's.
> 
> CVE-2012-3496  - Is this vulnerability affected for xen 4.x only or it
> does include for xen 3.4 too? Since the patch name was
> xsa14-xen-3.4-and-4.x.patch
> http://lists.xen.org/archives/html/xen-announce/2012-09/msg00002.html

Yes, it looks like this effects 3.4 too.

> CVE-2012-3516  - Shall I apply this unstable for patch for xen4.2 too?
> http://lists.xen.org/archives/html/xen-announce/2012-09/msg00004.html

The advisory says "Xen-unstable, including Xen 4.2 release candidates
are vulnerable to this issue.", so yes, obviously.

In the future please carefully read the advisories before asking lots of
questions, almost everything you have asked is addressed in the advisory
texts AFAICT.

Ian.



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

From xen-devel-bounces@lists.xen.org Thu Sep 06 08:57:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 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 1T9XtI-00028i-Uc; Thu, 06 Sep 2012 08:56: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 1T9XtG-00028N-RM
	for xen-devel@lists.xen.org; Thu, 06 Sep 2012 08:56:47 +0000
Received: from [85.158.143.35:60558] by server-1.bemta-4.messagelabs.com id
	70/E2-12504-E4568405; Thu, 06 Sep 2012 08:56:46 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1346921804!12497002!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTE5NzY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2094 invoked from network); 6 Sep 2012 08:56:44 -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;
	6 Sep 2012 08:56:44 -0000
X-IronPort-AV: E=Sophos;i="4.80,379,1344211200"; d="scan'208";a="14378549"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Sep 2012 08:56: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.279.1; Thu, 6 Sep 2012
	09:56:44 +0100
Message-ID: <1346921802.23055.26.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: kk s <kks.kbase@gmail.com>
Date: Thu, 6 Sep 2012 09:56:42 +0100
In-Reply-To: <CAPU-Ed65dguruSSNrGxk4PmejTJQT7zELXpNAxJULCmdwEvpnA@mail.gmail.com>
References: <CAPU-Ed65dguruSSNrGxk4PmejTJQT7zELXpNAxJULCmdwEvpnA@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-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] Security patches
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-09-06 at 09:31 +0100, kk s wrote:
> Hi,
> 
> Can anyone give the patch file download link for the below xen
> security for xen version 3.4 and 4.1? Since I couldn't find the
> downloadable patch file for some of the CVE's.
> 
> CVE-2012-0029   - http://lists.xen.org/archives/html/xen-devel/2012-02/msg00212.html  (There is no download link for both xen 3.4 and 4.1)
> CVE-2012-2934   - http://lists.xen.org/archives/html/xen-announce/2012-06/msg00002.html  (There is no patch file to download of xen 3.4)
> CVE-2012-3432   - http://lists.xen.org/archives/html/xen-devel/2012-07/msg01649.html  (There is no download link for both xen 3.4 and 4.1)
> CVE-2012-3433   - http://lists.xen.org/archives/html/xen-devel/2012-08/msg00855.html  (There is no download link for both xen 3.4 and 4.1)

It looks to me like there are changeset references and/or patches for
all of these in the advisories. You might find it easier to follow: 
        http://wiki.xen.org/wiki/Security_Announcements

You can also always look in the appropriate xen-X.Y-testing.hg tree for
the fix.

> CVE-2012-3497   - http://lists.xen.org/archives/html/xen-announce/2012-09/msg00006.html  (There is no download link for patch)

This is quite clearly explained in the advisory.

> Also I have some doubts for the below CVE's.
> 
> CVE-2012-3496  - Is this vulnerability affected for xen 4.x only or it
> does include for xen 3.4 too? Since the patch name was
> xsa14-xen-3.4-and-4.x.patch
> http://lists.xen.org/archives/html/xen-announce/2012-09/msg00002.html

Yes, it looks like this effects 3.4 too.

> CVE-2012-3516  - Shall I apply this unstable for patch for xen4.2 too?
> http://lists.xen.org/archives/html/xen-announce/2012-09/msg00004.html

The advisory says "Xen-unstable, including Xen 4.2 release candidates
are vulnerable to this issue.", so yes, obviously.

In the future please carefully read the advisories before asking lots of
questions, almost everything you have asked is addressed in the advisory
texts AFAICT.

Ian.



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

From xen-devel-bounces@lists.xen.org Thu Sep 06 08:58:35 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 2012 08:58:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9Xun-0002Hj-9d; Thu, 06 Sep 2012 08:58:21 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <kks.kbase@gmail.com>) id 1T9XtH-00028O-Jr
	for xen-devel@lists.xen.org; Thu, 06 Sep 2012 08:56:48 +0000
Received: from [85.158.138.51:26658] by server-4.bemta-3.messagelabs.com id
	8E/6F-24831-E4568405; Thu, 06 Sep 2012 08:56:46 +0000
X-Env-Sender: kks.kbase@gmail.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1346921805!29029970!1
X-Originating-IP: [209.85.214.45]
X-SpamReason: No, hits=2.8 required=7.0 tests=HTML_10_20,HTML_MESSAGE,
	HTML_SHORT_LENGTH,ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 862 invoked from network); 6 Sep 2012 08:56:46 -0000
Received: from mail-bk0-f45.google.com (HELO mail-bk0-f45.google.com)
	(209.85.214.45)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Sep 2012 08:56:46 -0000
Received: by bkcji1 with SMTP id ji1so653178bkc.32
	for <multiple recipients>; Thu, 06 Sep 2012 01:56:45 -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=MS0jXLhw+w2Uqa0SCtUAzPS+SNN0Syugsvf8huDdFY4=;
	b=UEYD7X6a2cYTajEcZ1AXxLhtv0k5FdVSeICSjugK2IQjZH4c3XUwHwHB+Ng8Gu0sJ5
	V7xwcISvXj3RSWclGFWdfgAkMcZCMtCDdoV/Zx0JcFNgOoiPUN65xEr7jRSTjFz7yO/7
	+AYirGMPCl7j102NRIWOcZgsmfScFeD0BbFEug/p9w9vbFDU1db2MAwUqVCjs5zHPPCH
	7WSXbbe1HR+J4yLHu5y9s0r+zytccpDaLSQLUdZLoXjxQ/I2Mx8QIdk8xZBaoRj0Z9Sv
	rFKAOOayTFtsQxAn4nsnOZ+/lXqLJUFPXtSdSww6CH8DIPwMbBQRQDfrE3ulXWBmpE0j
	CDKA==
MIME-Version: 1.0
Received: by 10.205.126.13 with SMTP id gu13mr403746bkc.79.1346921805299; Thu,
	06 Sep 2012 01:56:45 -0700 (PDT)
Received: by 10.204.56.134 with HTTP; Thu, 6 Sep 2012 01:56:45 -0700 (PDT)
Date: Thu, 6 Sep 2012 14:26:45 +0530
Message-ID: <CAPU-Ed7oSas3XAYDk+EXUvegWhGkXzzPLRoCOt5YBWbP6YKT2w@mail.gmail.com>
From: kk s <kks.kbase@gmail.com>
To: xen-devel@lists.xen.org, xen-users@lists.xen.org
X-Mailman-Approved-At: Thu, 06 Sep 2012 08:58:20 +0000
Subject: [Xen-devel] Xen 4.2 rpm build
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============7615012485611245661=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============7615012485611245661==
Content-Type: multipart/alternative; boundary=00151747b744bec1ed04c904ab76

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

Hi,

Can anyone provide the steps to build rpm from source for Xen 4.1.2?

--00151747b744bec1ed04c904ab76
Content-Type: text/html; charset=ISO-8859-1

Hi,<br><br>Can anyone provide the steps to build rpm from source for Xen 4.1.2?<br><br><br>

--00151747b744bec1ed04c904ab76--


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

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

--===============7615012485611245661==--


From xen-devel-bounces@lists.xen.org Thu Sep 06 08:58:35 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 2012 08:58:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9Xun-0002Hj-9d; Thu, 06 Sep 2012 08:58:21 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <kks.kbase@gmail.com>) id 1T9XtH-00028O-Jr
	for xen-devel@lists.xen.org; Thu, 06 Sep 2012 08:56:48 +0000
Received: from [85.158.138.51:26658] by server-4.bemta-3.messagelabs.com id
	8E/6F-24831-E4568405; Thu, 06 Sep 2012 08:56:46 +0000
X-Env-Sender: kks.kbase@gmail.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1346921805!29029970!1
X-Originating-IP: [209.85.214.45]
X-SpamReason: No, hits=2.8 required=7.0 tests=HTML_10_20,HTML_MESSAGE,
	HTML_SHORT_LENGTH,ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 862 invoked from network); 6 Sep 2012 08:56:46 -0000
Received: from mail-bk0-f45.google.com (HELO mail-bk0-f45.google.com)
	(209.85.214.45)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Sep 2012 08:56:46 -0000
Received: by bkcji1 with SMTP id ji1so653178bkc.32
	for <multiple recipients>; Thu, 06 Sep 2012 01:56:45 -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=MS0jXLhw+w2Uqa0SCtUAzPS+SNN0Syugsvf8huDdFY4=;
	b=UEYD7X6a2cYTajEcZ1AXxLhtv0k5FdVSeICSjugK2IQjZH4c3XUwHwHB+Ng8Gu0sJ5
	V7xwcISvXj3RSWclGFWdfgAkMcZCMtCDdoV/Zx0JcFNgOoiPUN65xEr7jRSTjFz7yO/7
	+AYirGMPCl7j102NRIWOcZgsmfScFeD0BbFEug/p9w9vbFDU1db2MAwUqVCjs5zHPPCH
	7WSXbbe1HR+J4yLHu5y9s0r+zytccpDaLSQLUdZLoXjxQ/I2Mx8QIdk8xZBaoRj0Z9Sv
	rFKAOOayTFtsQxAn4nsnOZ+/lXqLJUFPXtSdSww6CH8DIPwMbBQRQDfrE3ulXWBmpE0j
	CDKA==
MIME-Version: 1.0
Received: by 10.205.126.13 with SMTP id gu13mr403746bkc.79.1346921805299; Thu,
	06 Sep 2012 01:56:45 -0700 (PDT)
Received: by 10.204.56.134 with HTTP; Thu, 6 Sep 2012 01:56:45 -0700 (PDT)
Date: Thu, 6 Sep 2012 14:26:45 +0530
Message-ID: <CAPU-Ed7oSas3XAYDk+EXUvegWhGkXzzPLRoCOt5YBWbP6YKT2w@mail.gmail.com>
From: kk s <kks.kbase@gmail.com>
To: xen-devel@lists.xen.org, xen-users@lists.xen.org
X-Mailman-Approved-At: Thu, 06 Sep 2012 08:58:20 +0000
Subject: [Xen-devel] Xen 4.2 rpm build
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============7615012485611245661=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============7615012485611245661==
Content-Type: multipart/alternative; boundary=00151747b744bec1ed04c904ab76

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

Hi,

Can anyone provide the steps to build rpm from source for Xen 4.1.2?

--00151747b744bec1ed04c904ab76
Content-Type: text/html; charset=ISO-8859-1

Hi,<br><br>Can anyone provide the steps to build rpm from source for Xen 4.1.2?<br><br><br>

--00151747b744bec1ed04c904ab76--


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

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

--===============7615012485611245661==--


From xen-devel-bounces@lists.xen.org Thu Sep 06 09:06:50 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 2012 09:06: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 1T9Y2m-0002rH-6l; Thu, 06 Sep 2012 09:06: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 1T9Xzm-0002fz-Ir
	for xen-devel@lists.xen.org; Thu, 06 Sep 2012 09:03:30 +0000
Received: from [85.158.138.51:49653] by server-3.bemta-3.messagelabs.com id
	43/71-21322-1E668405; Thu, 06 Sep 2012 09:03:29 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1346922209!20901213!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTE5NjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19165 invoked from network); 6 Sep 2012 09:03:29 -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;
	6 Sep 2012 09:03:29 -0000
X-IronPort-AV: E=Sophos;i="4.80,379,1344211200"; d="scan'208";a="14378956"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Sep 2012 09:03: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.279.1; Thu, 6 Sep 2012
	10:03:29 +0100
Message-ID: <1346922207.23055.29.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: kk s <kks.kbase@gmail.com>
Date: Thu, 6 Sep 2012 10:03:27 +0100
In-Reply-To: <CAPU-Ed7oSas3XAYDk+EXUvegWhGkXzzPLRoCOt5YBWbP6YKT2w@mail.gmail.com>
References: <CAPU-Ed7oSas3XAYDk+EXUvegWhGkXzzPLRoCOt5YBWbP6YKT2w@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
X-Mailman-Approved-At: Thu, 06 Sep 2012 09:06:35 +0000
Cc: "xen-users@lists.xen.org" <xen-users@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.2 rpm build
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Please don't cross post to both users and devel.

Both http://wiki.xen.org/wiki/Asking_Xen_Devel_Questions and
http://wiki.xen.org/wiki/Xen_Users_Netiquette caution against this.

I have moved xen-devel to BCC.

On Thu, 2012-09-06 at 09:56 +0100, kk s wrote:
> Can anyone provide the steps to build rpm from source for Xen 4.1.2?

Have you searched the wiki and tries using a search engine? There are
plenty of tutorials around.

Ian.


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

From xen-devel-bounces@lists.xen.org Thu Sep 06 09:06:50 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 2012 09:06: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 1T9Y2m-0002rH-6l; Thu, 06 Sep 2012 09:06: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 1T9Xzm-0002fz-Ir
	for xen-devel@lists.xen.org; Thu, 06 Sep 2012 09:03:30 +0000
Received: from [85.158.138.51:49653] by server-3.bemta-3.messagelabs.com id
	43/71-21322-1E668405; Thu, 06 Sep 2012 09:03:29 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1346922209!20901213!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTE5NjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19165 invoked from network); 6 Sep 2012 09:03:29 -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;
	6 Sep 2012 09:03:29 -0000
X-IronPort-AV: E=Sophos;i="4.80,379,1344211200"; d="scan'208";a="14378956"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Sep 2012 09:03: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.279.1; Thu, 6 Sep 2012
	10:03:29 +0100
Message-ID: <1346922207.23055.29.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: kk s <kks.kbase@gmail.com>
Date: Thu, 6 Sep 2012 10:03:27 +0100
In-Reply-To: <CAPU-Ed7oSas3XAYDk+EXUvegWhGkXzzPLRoCOt5YBWbP6YKT2w@mail.gmail.com>
References: <CAPU-Ed7oSas3XAYDk+EXUvegWhGkXzzPLRoCOt5YBWbP6YKT2w@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
X-Mailman-Approved-At: Thu, 06 Sep 2012 09:06:35 +0000
Cc: "xen-users@lists.xen.org" <xen-users@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.2 rpm build
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Please don't cross post to both users and devel.

Both http://wiki.xen.org/wiki/Asking_Xen_Devel_Questions and
http://wiki.xen.org/wiki/Xen_Users_Netiquette caution against this.

I have moved xen-devel to BCC.

On Thu, 2012-09-06 at 09:56 +0100, kk s wrote:
> Can anyone provide the steps to build rpm from source for Xen 4.1.2?

Have you searched the wiki and tries using a search engine? There are
plenty of tutorials around.

Ian.


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

From xen-devel-bounces@lists.xen.org Thu Sep 06 09:14:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 2012 09: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 1T9Y9y-0003Rh-1h; Thu, 06 Sep 2012 09: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.Campbell@citrix.com>) id 1T9Y9w-0003RT-3D
	for xen-devel@lists.xen.org; Thu, 06 Sep 2012 09:14:00 +0000
Received: from [85.158.143.35:57464] by server-3.bemta-4.messagelabs.com id
	F0/E7-08232-75968405; Thu, 06 Sep 2012 09:13:59 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1346922838!5245294!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTE5NzY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7331 invoked from network); 6 Sep 2012 09:13:59 -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 Sep 2012 09:13:59 -0000
X-IronPort-AV: E=Sophos;i="4.80,379,1344211200"; d="scan'208";a="14379307"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Sep 2012 09:13: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.279.1; Thu, 6 Sep 2012
	10:13:58 +0100
Message-ID: <1346922837.23055.33.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: kk s <kks.kbase@gmail.com>
Date: Thu, 6 Sep 2012 10:13:57 +0100
In-Reply-To: <CAPU-Ed4=r6KT0r4fM--94oPPo0mn4LcmwRJh41wHiAFvf6irLg@mail.gmail.com>
References: <CAPU-Ed65dguruSSNrGxk4PmejTJQT7zELXpNAxJULCmdwEvpnA@mail.gmail.com>
	<1346921802.23055.26.camel@zakaz.uk.xensource.com>
	<CAPU-Ed4=r6KT0r4fM--94oPPo0mn4LcmwRJh41wHiAFvf6irLg@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-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] Security patches
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-09-06 at 10:08 +0100, kk s wrote:
> Hi Ian,
> 
> Thanks for your reply. Sorry to bother you with this. I am bit
> confused and so I am asking to make clear myself.
> 
> Reg CVE-2012-2934 -
> http://lists.xen.org/archives/html/xen-announce/2012-06/msg00002.html
> Is Xen 3.4 too affected with this vulnerable? If so I couldn't find
> the patch for xen 3.4 and it does exit for xen 4.x only.

I expect it does effect 3.4, but only if you are running on one of the
listed processors.

security@xen.org doesn't provide security support for 3.4 any more. If
you aren't able to backport the 4.0 patch yourself, you would need to
speak to Keith Coleman who is the 3.4 stable maintainer.

> I don't how to apply the following patches since I have created rpm
> with patches applied that included as downloadable file. But for these
> patches I am not seeing any downloadable file.
> 
> http://lists.xen.org/archives/html/xen-devel/2012-02/msg00212.html
> http://lists.xen.org/archives/html/xen-devel/2012-07/msg01649.html
> http://lists.xen.org/archives/html/xen-devel/2012-08/msg00855.html
> 
> If you can clear this for me that would be great :)

I already pointed you at http://wiki.xen.org/wiki/Security_Announcements
which should have all the links 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 Sep 06 09:14:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 2012 09: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 1T9Y9y-0003Rh-1h; Thu, 06 Sep 2012 09: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.Campbell@citrix.com>) id 1T9Y9w-0003RT-3D
	for xen-devel@lists.xen.org; Thu, 06 Sep 2012 09:14:00 +0000
Received: from [85.158.143.35:57464] by server-3.bemta-4.messagelabs.com id
	F0/E7-08232-75968405; Thu, 06 Sep 2012 09:13:59 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1346922838!5245294!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTE5NzY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7331 invoked from network); 6 Sep 2012 09:13:59 -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 Sep 2012 09:13:59 -0000
X-IronPort-AV: E=Sophos;i="4.80,379,1344211200"; d="scan'208";a="14379307"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Sep 2012 09:13: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.279.1; Thu, 6 Sep 2012
	10:13:58 +0100
Message-ID: <1346922837.23055.33.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: kk s <kks.kbase@gmail.com>
Date: Thu, 6 Sep 2012 10:13:57 +0100
In-Reply-To: <CAPU-Ed4=r6KT0r4fM--94oPPo0mn4LcmwRJh41wHiAFvf6irLg@mail.gmail.com>
References: <CAPU-Ed65dguruSSNrGxk4PmejTJQT7zELXpNAxJULCmdwEvpnA@mail.gmail.com>
	<1346921802.23055.26.camel@zakaz.uk.xensource.com>
	<CAPU-Ed4=r6KT0r4fM--94oPPo0mn4LcmwRJh41wHiAFvf6irLg@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-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] Security patches
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-09-06 at 10:08 +0100, kk s wrote:
> Hi Ian,
> 
> Thanks for your reply. Sorry to bother you with this. I am bit
> confused and so I am asking to make clear myself.
> 
> Reg CVE-2012-2934 -
> http://lists.xen.org/archives/html/xen-announce/2012-06/msg00002.html
> Is Xen 3.4 too affected with this vulnerable? If so I couldn't find
> the patch for xen 3.4 and it does exit for xen 4.x only.

I expect it does effect 3.4, but only if you are running on one of the
listed processors.

security@xen.org doesn't provide security support for 3.4 any more. If
you aren't able to backport the 4.0 patch yourself, you would need to
speak to Keith Coleman who is the 3.4 stable maintainer.

> I don't how to apply the following patches since I have created rpm
> with patches applied that included as downloadable file. But for these
> patches I am not seeing any downloadable file.
> 
> http://lists.xen.org/archives/html/xen-devel/2012-02/msg00212.html
> http://lists.xen.org/archives/html/xen-devel/2012-07/msg01649.html
> http://lists.xen.org/archives/html/xen-devel/2012-08/msg00855.html
> 
> If you can clear this for me that would be great :)

I already pointed you at http://wiki.xen.org/wiki/Security_Announcements
which should have all the links 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 Sep 06 09:15:54 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 2012 09: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 1T9YBc-0003lB-E2; Thu, 06 Sep 2012 09:15:44 +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 1T9YBb-0003kv-Gn
	for xen-devel@lists.xensource.com; Thu, 06 Sep 2012 09:15:43 +0000
Received: from [85.158.143.99:53011] by server-1.bemta-4.messagelabs.com id
	62/10-12504-EB968405; Thu, 06 Sep 2012 09:15:42 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-3.tower-216.messagelabs.com!1346922939!28270058!1
X-Originating-IP: [88.159.1.183]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogODguMTU5LjEuMTgzID0+IDI5MDg2\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31737 invoked from network); 6 Sep 2012 09:15:40 -0000
Received: from isp-bos-02.edutel.nl (HELO isp-bos-02.edutel.nl) (88.159.1.183)
	by server-3.tower-216.messagelabs.com with SMTP;
	6 Sep 2012 09:15:40 -0000
Received: from isp-aos-01.edutel.intern (unknown [IPv6:2a01:670:100:11::1:1])
	by isp-bos-02.edutel.nl (Postfix) with ESMTP id 2C7D22C64B1;
	Thu,  6 Sep 2012 11:15:39 +0200 (CEST)
Received: from localhost (localhost.localdomain [127.0.0.1])
	by isp-aos-01.edutel.intern (Postfix) with ESMTP id 231B93DC4B6;
	Thu,  6 Sep 2012 11:15:39 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at isp-aos-01.edutel.intern
Received: from isp-aos-01.edutel.intern ([127.0.0.1])
	by localhost (isp-aos-01.edutel.intern [127.0.0.1]) (amavisd-new,
	port 10024)
	with ESMTP id oAQlpVb+Yo6G; Thu,  6 Sep 2012 11:15:38 +0200 (CEST)
Received: from mail.home.eikelenboom.it (128-64-ftth.onsneteindhoven.nl
	[88.159.64.128])
	by isp-aos-01.edutel.intern (Postfix) with ESMTPSA id 134B43DC4B5;
	Thu,  6 Sep 2012 11:15:38 +0200 (CEST)
Received: from [172.16.1.31] (helo=xentest.example.org)
	by mail.home.eikelenboom.it with esmtpa (Exim 4.72)
	(envelope-from <linux@eikelenboom.it>)
	id 1T9YAo-0000wy-Hx; Thu, 06 Sep 2012 11:14:54 +0200
MIME-Version: 1.0
X-Mercurial-Node: 67f9ef64993791d81845aed83719194b81764c10
Message-Id: <67f9ef64993791d81845.1346926055@xentest.example.org>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Thu, 06 Sep 2012 12:07:35 +0200
From: Sander Eikelenboom <linux@eikelenboom.it>
To: xen-devel@lists.xensource.com
Cc: Ian.Campbell@citrix.com
Subject: [Xen-devel] [PATCH] xl: Introduce shutdown xm compatibility option
 -a to shutdown all 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

 docs/man/xl.pod.1         |   6 +++++-
 tools/libxl/xl_cmdimpl.c  |  39 ++++++++++++++++++++++++++++++++++++---
 tools/libxl/xl_cmdtable.c |   3 ++-
 3 files changed, 43 insertions(+), 5 deletions(-)


xl: Introduce shutdown xm compatibility option -a to shutdown all domains

Signed-off-by: Sander Eikelenboom <linux@eikelenboom.it>

diff -r 9dc729b75595 -r 67f9ef649937 docs/man/xl.pod.1
--- a/docs/man/xl.pod.1	Mon Sep 03 11:22:02 2012 +0100
+++ b/docs/man/xl.pod.1	Thu Sep 06 12:04:12 2012 +0200
@@ -527,7 +527,7 @@ List specifically for that domain. Other
 
 =back
 
-=item B<shutdown> [I<OPTIONS>] I<domain-id>
+=item B<shutdown> [I<OPTIONS>] [I<domain-id>]
 
 Gracefully shuts down a domain.  This coordinates with the domain OS
 to perform graceful shutdown, so there is no guarantee that it will
@@ -550,6 +550,10 @@ B<OPTIONS>
 
 =over 4
 
+=item B<-a>
+
+-a  Shutdown all domains.  Often used when doing a complete shutdown of a Xen system.
+
 =item B<-w>
 
 Wait for the domain to complete shutdown before returning.
diff -r 9dc729b75595 -r 67f9ef649937 tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Mon Sep 03 11:22:02 2012 +0100
+++ b/tools/libxl/xl_cmdimpl.c	Thu Sep 06 12:04:12 2012 +0200
@@ -3670,14 +3670,20 @@ int main_destroy(int argc, char **argv)
 
 int main_shutdown(int argc, char **argv)
 {
-    int opt;
+    libxl_dominfo *dominfo;
+    char *domname;
+    int opt, i, nb_domain;
+    int all = 0;
     int wait = 0;
     int fallback_trigger = 0;
 
-    while ((opt = def_getopt(argc, argv, "wF", "shutdown", 1)) != -1) {
+    while ((opt = def_getopt(argc, argv, "awF", "shutdown", 0)) != -1) {
         switch (opt) {
         case 0: case 2:
             return opt;
+        case 'a':
+            all = 1;
+            break;
         case 'w':
             wait = 1;
             break;
@@ -3687,7 +3693,34 @@ int main_shutdown(int argc, char **argv)
         }
     }
 
-    shutdown_domain(argv[optind], wait, fallback_trigger);
+    if (!argv[optind] && !all) {
+        fprintf(stderr, "You must specify -a or a domain id.\n\n");
+        return opt;
+    }
+
+    if (all) {
+        if (!(dominfo = libxl_list_domain(ctx, &nb_domain))) {
+            fprintf(stderr, "libxl_list_domain failed.\n");
+            goto main_shutdown_out;
+        }
+
+        for (i = 0; i<nb_domain; i++) {
+            if (dominfo[i].domid == 0)
+                continue;
+
+            domname = libxl_domid_to_name(ctx, dominfo[i].domid);
+            if (domname)
+                shutdown_domain(domname, wait, fallback_trigger);
+
+	    free(domname);
+        }
+
+        libxl_dominfo_list_free(dominfo, nb_domain);
+    } else {
+        shutdown_domain(argv[optind], wait, fallback_trigger);
+    }
+
+main_shutdown_out:
     return 0;
 }
 
diff -r 9dc729b75595 -r 67f9ef649937 tools/libxl/xl_cmdtable.c
--- a/tools/libxl/xl_cmdtable.c	Mon Sep 03 11:22:02 2012 +0100
+++ b/tools/libxl/xl_cmdtable.c	Thu Sep 06 12:04:12 2012 +0200
@@ -60,7 +60,8 @@ struct cmd_spec cmd_table[] = {
     { "shutdown",
       &main_shutdown, 0, 1,
       "Issue a shutdown signal to a domain",
-      "[options] <Domain>",
+      "[options] [Domain]",
+      "-a                      Shutdown all domains.\n"
       "-h                      Print this help.\n"
       "-F                      Fallback to ACPI power event for HVM guests with\n"
       "                        no PV drivers.\n"

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

From xen-devel-bounces@lists.xen.org Thu Sep 06 09:15:54 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 2012 09: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 1T9YBc-0003lB-E2; Thu, 06 Sep 2012 09:15:44 +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 1T9YBb-0003kv-Gn
	for xen-devel@lists.xensource.com; Thu, 06 Sep 2012 09:15:43 +0000
Received: from [85.158.143.99:53011] by server-1.bemta-4.messagelabs.com id
	62/10-12504-EB968405; Thu, 06 Sep 2012 09:15:42 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-3.tower-216.messagelabs.com!1346922939!28270058!1
X-Originating-IP: [88.159.1.183]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogODguMTU5LjEuMTgzID0+IDI5MDg2\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31737 invoked from network); 6 Sep 2012 09:15:40 -0000
Received: from isp-bos-02.edutel.nl (HELO isp-bos-02.edutel.nl) (88.159.1.183)
	by server-3.tower-216.messagelabs.com with SMTP;
	6 Sep 2012 09:15:40 -0000
Received: from isp-aos-01.edutel.intern (unknown [IPv6:2a01:670:100:11::1:1])
	by isp-bos-02.edutel.nl (Postfix) with ESMTP id 2C7D22C64B1;
	Thu,  6 Sep 2012 11:15:39 +0200 (CEST)
Received: from localhost (localhost.localdomain [127.0.0.1])
	by isp-aos-01.edutel.intern (Postfix) with ESMTP id 231B93DC4B6;
	Thu,  6 Sep 2012 11:15:39 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at isp-aos-01.edutel.intern
Received: from isp-aos-01.edutel.intern ([127.0.0.1])
	by localhost (isp-aos-01.edutel.intern [127.0.0.1]) (amavisd-new,
	port 10024)
	with ESMTP id oAQlpVb+Yo6G; Thu,  6 Sep 2012 11:15:38 +0200 (CEST)
Received: from mail.home.eikelenboom.it (128-64-ftth.onsneteindhoven.nl
	[88.159.64.128])
	by isp-aos-01.edutel.intern (Postfix) with ESMTPSA id 134B43DC4B5;
	Thu,  6 Sep 2012 11:15:38 +0200 (CEST)
Received: from [172.16.1.31] (helo=xentest.example.org)
	by mail.home.eikelenboom.it with esmtpa (Exim 4.72)
	(envelope-from <linux@eikelenboom.it>)
	id 1T9YAo-0000wy-Hx; Thu, 06 Sep 2012 11:14:54 +0200
MIME-Version: 1.0
X-Mercurial-Node: 67f9ef64993791d81845aed83719194b81764c10
Message-Id: <67f9ef64993791d81845.1346926055@xentest.example.org>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Thu, 06 Sep 2012 12:07:35 +0200
From: Sander Eikelenboom <linux@eikelenboom.it>
To: xen-devel@lists.xensource.com
Cc: Ian.Campbell@citrix.com
Subject: [Xen-devel] [PATCH] xl: Introduce shutdown xm compatibility option
 -a to shutdown all 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

 docs/man/xl.pod.1         |   6 +++++-
 tools/libxl/xl_cmdimpl.c  |  39 ++++++++++++++++++++++++++++++++++++---
 tools/libxl/xl_cmdtable.c |   3 ++-
 3 files changed, 43 insertions(+), 5 deletions(-)


xl: Introduce shutdown xm compatibility option -a to shutdown all domains

Signed-off-by: Sander Eikelenboom <linux@eikelenboom.it>

diff -r 9dc729b75595 -r 67f9ef649937 docs/man/xl.pod.1
--- a/docs/man/xl.pod.1	Mon Sep 03 11:22:02 2012 +0100
+++ b/docs/man/xl.pod.1	Thu Sep 06 12:04:12 2012 +0200
@@ -527,7 +527,7 @@ List specifically for that domain. Other
 
 =back
 
-=item B<shutdown> [I<OPTIONS>] I<domain-id>
+=item B<shutdown> [I<OPTIONS>] [I<domain-id>]
 
 Gracefully shuts down a domain.  This coordinates with the domain OS
 to perform graceful shutdown, so there is no guarantee that it will
@@ -550,6 +550,10 @@ B<OPTIONS>
 
 =over 4
 
+=item B<-a>
+
+-a  Shutdown all domains.  Often used when doing a complete shutdown of a Xen system.
+
 =item B<-w>
 
 Wait for the domain to complete shutdown before returning.
diff -r 9dc729b75595 -r 67f9ef649937 tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Mon Sep 03 11:22:02 2012 +0100
+++ b/tools/libxl/xl_cmdimpl.c	Thu Sep 06 12:04:12 2012 +0200
@@ -3670,14 +3670,20 @@ int main_destroy(int argc, char **argv)
 
 int main_shutdown(int argc, char **argv)
 {
-    int opt;
+    libxl_dominfo *dominfo;
+    char *domname;
+    int opt, i, nb_domain;
+    int all = 0;
     int wait = 0;
     int fallback_trigger = 0;
 
-    while ((opt = def_getopt(argc, argv, "wF", "shutdown", 1)) != -1) {
+    while ((opt = def_getopt(argc, argv, "awF", "shutdown", 0)) != -1) {
         switch (opt) {
         case 0: case 2:
             return opt;
+        case 'a':
+            all = 1;
+            break;
         case 'w':
             wait = 1;
             break;
@@ -3687,7 +3693,34 @@ int main_shutdown(int argc, char **argv)
         }
     }
 
-    shutdown_domain(argv[optind], wait, fallback_trigger);
+    if (!argv[optind] && !all) {
+        fprintf(stderr, "You must specify -a or a domain id.\n\n");
+        return opt;
+    }
+
+    if (all) {
+        if (!(dominfo = libxl_list_domain(ctx, &nb_domain))) {
+            fprintf(stderr, "libxl_list_domain failed.\n");
+            goto main_shutdown_out;
+        }
+
+        for (i = 0; i<nb_domain; i++) {
+            if (dominfo[i].domid == 0)
+                continue;
+
+            domname = libxl_domid_to_name(ctx, dominfo[i].domid);
+            if (domname)
+                shutdown_domain(domname, wait, fallback_trigger);
+
+	    free(domname);
+        }
+
+        libxl_dominfo_list_free(dominfo, nb_domain);
+    } else {
+        shutdown_domain(argv[optind], wait, fallback_trigger);
+    }
+
+main_shutdown_out:
     return 0;
 }
 
diff -r 9dc729b75595 -r 67f9ef649937 tools/libxl/xl_cmdtable.c
--- a/tools/libxl/xl_cmdtable.c	Mon Sep 03 11:22:02 2012 +0100
+++ b/tools/libxl/xl_cmdtable.c	Thu Sep 06 12:04:12 2012 +0200
@@ -60,7 +60,8 @@ struct cmd_spec cmd_table[] = {
     { "shutdown",
       &main_shutdown, 0, 1,
       "Issue a shutdown signal to a domain",
-      "[options] <Domain>",
+      "[options] [Domain]",
+      "-a                      Shutdown all domains.\n"
       "-h                      Print this help.\n"
       "-F                      Fallback to ACPI power event for HVM guests with\n"
       "                        no PV drivers.\n"

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

From xen-devel-bounces@lists.xen.org Thu Sep 06 09:22:51 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 2012 09:22: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 1T9YIJ-0004Fy-EW; Thu, 06 Sep 2012 09:22:39 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <daniel.lezcano@linaro.org>) id 1T9YIH-0004Ft-Np
	for xen-devel@lists.xensource.com; Thu, 06 Sep 2012 09:22:37 +0000
Received: from [85.158.143.99:48227] by server-2.bemta-4.messagelabs.com id
	F9/60-21239-D5B68405; Thu, 06 Sep 2012 09:22:37 +0000
X-Env-Sender: daniel.lezcano@linaro.org
X-Msg-Ref: server-15.tower-216.messagelabs.com!1346923355!28843212!1
X-Originating-IP: [209.85.214.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20988 invoked from network); 6 Sep 2012 09:22:36 -0000
Received: from mail-bk0-f43.google.com (HELO mail-bk0-f43.google.com)
	(209.85.214.43)
	by server-15.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Sep 2012 09:22:36 -0000
Received: by bkty15 with SMTP id y15so702727bkt.30
	for <xen-devel@lists.xensource.com>;
	Thu, 06 Sep 2012 02:22:35 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=message-id:date:from:user-agent:mime-version:to:cc:subject
	:references:in-reply-to:content-type:content-transfer-encoding
	:x-gm-message-state;
	bh=Zpw0zUgL6HWLXJQbileb+juGRrUZzPQdz488/mGmCww=;
	b=DG3SNeX3g6YbgT73dmgS3oOTDkr1dqLoZU6QLWd465+7Wuj3eQuUjKlnAmBII14yUp
	jA8YUqPCW8qcpMTf+PdzCbZL48aPUkfZnOPX859/i4gEdbIqsBfB0N5YJvqDyZhJHr7h
	LbcFncH+WNJkBawZxt2EC21EX8yPM9iLm3Mg6RF1p2m+l2V+pi94ezs3SfMXsefOtldC
	6xHhsY/maPJvioyzMcEyBQr7PRas1d+fKQ52p5FPzcKAzK+HwuxsOTsjp8gPk2tsUaXh
	BuCufjSpK1Gbm+wIroB3cMETkynzBlVfGuPw8MfgaN/Lj5m1qF/Gx4IvdO6UO8YM1e0C
	ZLEg==
Received: by 10.204.132.77 with SMTP id a13mr451050bkt.99.1346923355468;
	Thu, 06 Sep 2012 02:22:35 -0700 (PDT)
Received: from [192.168.1.11] (AToulouse-651-1-16-21.w92-149.abo.wanadoo.fr.
	[92.149.191.21])
	by mx.google.com with ESMTPS id c18sm655709bkv.8.2012.09.06.02.22.32
	(version=SSLv3 cipher=OTHER); Thu, 06 Sep 2012 02:22:34 -0700 (PDT)
Message-ID: <50486B58.7000901@linaro.org>
Date: Thu, 06 Sep 2012 11:22:32 +0200
From: Daniel Lezcano <daniel.lezcano@linaro.org>
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:12.0) Gecko/20120430 Thunderbird/12.0.1
MIME-Version: 1.0
To: "Rafael J. Wysocki" <rjw@sisk.pl>
References: <1343164349-28550-1-git-send-email-daniel.lezcano@linaro.org>
	<50410811.70500@linaro.org> <201209010754.58999.rjw@sisk.pl>
	<201209051541.58909.rjw@sisk.pl> <50485698.1070905@linaro.org>
In-Reply-To: <50485698.1070905@linaro.org>
X-Gm-Message-State: ALoCoQmAN+gCzsQwFYcB01uVAknEiOYnB2ExWJyoiaoQ1TX4HlKz05QPV5FwDlobdTXyEAW+Yd6n
Cc: xen-devel@lists.xensource.com, linaro-dev@lists.linaro.org,
	linux-pm@vger.kernel.org, Frederic Weisbecker <fweisbec@gmail.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	linux-acpi@vger.kernel.org, lenb@kernel.org
Subject: [Xen-devel] CONFIG_NO_HZ + CONFIG_CPU_IDLE freeze the system (Was
 Re: [PATCH] acpi : remove power from acpi_processor_cx structure)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 09/06/2012 09:54 AM, Daniel Lezcano wrote:
> On 09/05/2012 03:41 PM, Rafael J. Wysocki wrote:
>> On Saturday, September 01, 2012, Rafael J. Wysocki wrote:
>>> On Friday, August 31, 2012, Daniel Lezcano wrote:
>>>> On 07/24/2012 11:06 PM, Konrad Rzeszutek Wilk wrote:
>>>>> On Tue, Jul 24, 2012 at 11:12:29PM +0200, Daniel Lezcano wrote:
>>>>>> Remove the power field as it is not used.
>>>>>>
>>>>>> Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
>>>>>> Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
>>>>> Acked.
>>>> Hi Rafael,
>>>>
>>>> I did not see this patch going in. Is it possible to merge it ?
>>> I think so.  I'll take care of it when I get back from LinuxCon/Plumbers Conf.
>>> (early next week).
>> Applied to the linux-next branch of the linux-pm.git tree as v3.7 material.
> Thanks Rafael.
>
>> Are there any other patches you want me to consider for v3.7?
> Yes please, I have the per cpu latencies ready to be submitted but I
> want to do extra testing before. Unfortunately, the linux-pm-next hangs
> at boot time on my intel dual core (not related to the patchset).
>
> I am git bisecting right now.

I found the culprit. This is not related to the linux-pm tree but with
net-next.
The following patch introduced the issue.

commit 6bdb7fe31046ac50b47e83c35cd6c6b6160a475d
Author: Amerigo Wang <amwang@redhat.com>
Date:   Fri Aug 10 01:24:50 2012 +0000

    netpoll: re-enable irq in poll_napi()
   
    napi->poll() needs IRQ enabled, so we have to re-enable IRQ before
    calling it.
   
    Cc: David Miller <davem@davemloft.net>
    Signed-off-by: Cong Wang <amwang@redhat.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>

AFAICS, it has been fixed by commit
072a9c48600409d72aeb0d5b29fbb75861a06631 which is not yet in linux-pm-next.

I fall into this issue because NETCONSOLE is set, disabling it allowed
me to go further.

Unfortunately I am facing to some random freeze on the system which
seems to be related to CONFIG_NO_HZ=y and CONFIG_CPU_IDLE=y.

Disabling one of them, make the freezes to disappear.

Is it a known issue ?

Thanks in advance
  -- Daniel





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

From xen-devel-bounces@lists.xen.org Thu Sep 06 09:22:51 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 2012 09:22: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 1T9YIJ-0004Fy-EW; Thu, 06 Sep 2012 09:22:39 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <daniel.lezcano@linaro.org>) id 1T9YIH-0004Ft-Np
	for xen-devel@lists.xensource.com; Thu, 06 Sep 2012 09:22:37 +0000
Received: from [85.158.143.99:48227] by server-2.bemta-4.messagelabs.com id
	F9/60-21239-D5B68405; Thu, 06 Sep 2012 09:22:37 +0000
X-Env-Sender: daniel.lezcano@linaro.org
X-Msg-Ref: server-15.tower-216.messagelabs.com!1346923355!28843212!1
X-Originating-IP: [209.85.214.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20988 invoked from network); 6 Sep 2012 09:22:36 -0000
Received: from mail-bk0-f43.google.com (HELO mail-bk0-f43.google.com)
	(209.85.214.43)
	by server-15.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Sep 2012 09:22:36 -0000
Received: by bkty15 with SMTP id y15so702727bkt.30
	for <xen-devel@lists.xensource.com>;
	Thu, 06 Sep 2012 02:22:35 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=message-id:date:from:user-agent:mime-version:to:cc:subject
	:references:in-reply-to:content-type:content-transfer-encoding
	:x-gm-message-state;
	bh=Zpw0zUgL6HWLXJQbileb+juGRrUZzPQdz488/mGmCww=;
	b=DG3SNeX3g6YbgT73dmgS3oOTDkr1dqLoZU6QLWd465+7Wuj3eQuUjKlnAmBII14yUp
	jA8YUqPCW8qcpMTf+PdzCbZL48aPUkfZnOPX859/i4gEdbIqsBfB0N5YJvqDyZhJHr7h
	LbcFncH+WNJkBawZxt2EC21EX8yPM9iLm3Mg6RF1p2m+l2V+pi94ezs3SfMXsefOtldC
	6xHhsY/maPJvioyzMcEyBQr7PRas1d+fKQ52p5FPzcKAzK+HwuxsOTsjp8gPk2tsUaXh
	BuCufjSpK1Gbm+wIroB3cMETkynzBlVfGuPw8MfgaN/Lj5m1qF/Gx4IvdO6UO8YM1e0C
	ZLEg==
Received: by 10.204.132.77 with SMTP id a13mr451050bkt.99.1346923355468;
	Thu, 06 Sep 2012 02:22:35 -0700 (PDT)
Received: from [192.168.1.11] (AToulouse-651-1-16-21.w92-149.abo.wanadoo.fr.
	[92.149.191.21])
	by mx.google.com with ESMTPS id c18sm655709bkv.8.2012.09.06.02.22.32
	(version=SSLv3 cipher=OTHER); Thu, 06 Sep 2012 02:22:34 -0700 (PDT)
Message-ID: <50486B58.7000901@linaro.org>
Date: Thu, 06 Sep 2012 11:22:32 +0200
From: Daniel Lezcano <daniel.lezcano@linaro.org>
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:12.0) Gecko/20120430 Thunderbird/12.0.1
MIME-Version: 1.0
To: "Rafael J. Wysocki" <rjw@sisk.pl>
References: <1343164349-28550-1-git-send-email-daniel.lezcano@linaro.org>
	<50410811.70500@linaro.org> <201209010754.58999.rjw@sisk.pl>
	<201209051541.58909.rjw@sisk.pl> <50485698.1070905@linaro.org>
In-Reply-To: <50485698.1070905@linaro.org>
X-Gm-Message-State: ALoCoQmAN+gCzsQwFYcB01uVAknEiOYnB2ExWJyoiaoQ1TX4HlKz05QPV5FwDlobdTXyEAW+Yd6n
Cc: xen-devel@lists.xensource.com, linaro-dev@lists.linaro.org,
	linux-pm@vger.kernel.org, Frederic Weisbecker <fweisbec@gmail.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	linux-acpi@vger.kernel.org, lenb@kernel.org
Subject: [Xen-devel] CONFIG_NO_HZ + CONFIG_CPU_IDLE freeze the system (Was
 Re: [PATCH] acpi : remove power from acpi_processor_cx structure)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 09/06/2012 09:54 AM, Daniel Lezcano wrote:
> On 09/05/2012 03:41 PM, Rafael J. Wysocki wrote:
>> On Saturday, September 01, 2012, Rafael J. Wysocki wrote:
>>> On Friday, August 31, 2012, Daniel Lezcano wrote:
>>>> On 07/24/2012 11:06 PM, Konrad Rzeszutek Wilk wrote:
>>>>> On Tue, Jul 24, 2012 at 11:12:29PM +0200, Daniel Lezcano wrote:
>>>>>> Remove the power field as it is not used.
>>>>>>
>>>>>> Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
>>>>>> Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
>>>>> Acked.
>>>> Hi Rafael,
>>>>
>>>> I did not see this patch going in. Is it possible to merge it ?
>>> I think so.  I'll take care of it when I get back from LinuxCon/Plumbers Conf.
>>> (early next week).
>> Applied to the linux-next branch of the linux-pm.git tree as v3.7 material.
> Thanks Rafael.
>
>> Are there any other patches you want me to consider for v3.7?
> Yes please, I have the per cpu latencies ready to be submitted but I
> want to do extra testing before. Unfortunately, the linux-pm-next hangs
> at boot time on my intel dual core (not related to the patchset).
>
> I am git bisecting right now.

I found the culprit. This is not related to the linux-pm tree but with
net-next.
The following patch introduced the issue.

commit 6bdb7fe31046ac50b47e83c35cd6c6b6160a475d
Author: Amerigo Wang <amwang@redhat.com>
Date:   Fri Aug 10 01:24:50 2012 +0000

    netpoll: re-enable irq in poll_napi()
   
    napi->poll() needs IRQ enabled, so we have to re-enable IRQ before
    calling it.
   
    Cc: David Miller <davem@davemloft.net>
    Signed-off-by: Cong Wang <amwang@redhat.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>

AFAICS, it has been fixed by commit
072a9c48600409d72aeb0d5b29fbb75861a06631 which is not yet in linux-pm-next.

I fall into this issue because NETCONSOLE is set, disabling it allowed
me to go further.

Unfortunately I am facing to some random freeze on the system which
seems to be related to CONFIG_NO_HZ=y and CONFIG_CPU_IDLE=y.

Disabling one of them, make the freezes to disappear.

Is it a known issue ?

Thanks in advance
  -- Daniel





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

From xen-devel-bounces@lists.xen.org Thu Sep 06 09:25:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 2012 09: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 1T9YLK-0004Pl-1v; Thu, 06 Sep 2012 09:25: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 1T9YLI-0004PT-8w
	for xen-devel@lists.xen.org; Thu, 06 Sep 2012 09:25:44 +0000
Received: from [85.158.139.83:15955] by server-10.bemta-5.messagelabs.com id
	35/03-10969-71C68405; Thu, 06 Sep 2012 09:25:43 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1346923542!17618741!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM5ODQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24210 invoked from network); 6 Sep 2012 09:25:42 -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;
	6 Sep 2012 09:25:42 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 06 Sep 2012 10:25:42 +0100
Message-Id: <504887F10200007800099399@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 06 Sep 2012 10:24:33 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ben Guthro" <ben@guthro.net>
References: <50367C78.80608@citrix.com>
	<CAOvdn6U_mSNQBbeboipKHuRJzcbrCe1Kj7ZY9=7N6s--AMESmQ@mail.gmail.com>
	<503686A7.5050206@citrix.com>
	<CAOvdn6U5Kmsfv9e=Un8qNR_mbM-V2x-v7Ork9S+saj6EjC-sEA@mail.gmail.com>
	<CAOvdn6VZVVZUsUASowme-t87s8JW6WkGqHRRh64YYC24k7BQLA@mail.gmail.com>
	<50380B69020000780008A7EC@nat28.tlf.novell.com>
	<CAOvdn6U1touhawCb2GvgVQZqxhWn9CRw6-wkqdxk=uOTq015OA@mail.gmail.com>
In-Reply-To: <CAOvdn6U1touhawCb2GvgVQZqxhWn9CRw6-wkqdxk=uOTq015OA@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>, john.baboval@citrix.com,
	Thomas Goetz <thomas.goetz@citrix.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen4.2 S3 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 04.09.12 at 20:34, Ben Guthro <ben@guthro.net> wrote:
> On Fri, Aug 24, 2012 at 6:16 PM, Jan Beulich <JBeulich@suse.com> wrote:
>>>>> On 24.08.12 at 17:10, Ben Guthro <ben@guthro.net> wrote:
>>> The attached patch is essentially the change you suggested, plus a
>>> check for NULL in irq_complete_move()
>>>
>>> This patch seems to fix some of the issues I was seeing, but not all.
>>> MSI's are now delivered, after a handful of suspend / resumes, which
>>> is the issue I was setting out to solve here.
>>
>> But I'm afraid this is just masking some other problem (see my
>> response to Andrew's mail that I just sent).
>>
>> Further more, the NULL check here seems pretty odd - I'd be very
>> curious what code path could get us there with the IRQ regs
>> pointer being NULL. It would likely be that code path that needs
>> fixing, not irq_complete_move(). Could you add a call to
>> dump_execution_state() to the early return path that you added?
> 
> Apologies that I'm just getting back to this.
> 
> The call trace in this early return patch looks like this:
> 
> (XEN) Xen call trace:
> (XEN)    [<ffff82c480167d1a>] irq_complete_move+0x3e/0xd9
> (XEN)    [<ffff82c48014424a>] dma_msi_mask+0x1d/0x49
> (XEN)    [<ffff82c480169cc2>] fixup_irqs+0x19c/0x300
> (XEN)    [<ffff82c48017e762>] __cpu_disable+0x337/0x37e
> (XEN)    [<ffff82c4801013e3>] take_cpu_down+0x43/0x4a
> (XEN)    [<ffff82c480125fe6>] stopmachine_action+0x8a/0xb3
> (XEN)    [<ffff82c48012756e>] do_tasklet_work+0x8d/0xc7
> (XEN)    [<ffff82c4801278d9>] do_tasklet+0x6b/0x9b
> (XEN)    [<ffff82c480158cbd>] idle_loop+0x67/0x71
> 
> 
> This seems to get printed 4 times - twice on CPU1, and CPU2

This one appears to be relatively clear, and I'll add a tentative
fix to the next version of debugging patch that I'm in the
process of preparing: irq_complete_move() is supposed to be
getting called from the hw_irq_controllers' .ack methods, yet
VT-d currently uses the same handler for .ack and .disable
(and calling irq_complete_move() in the context of .disable
is certainly wrong) - this appears to have been the case
forever, but a flaw like this may of course get uncovered with
completely unrelated changes.

Jan

(also restored the Cc list)


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

From xen-devel-bounces@lists.xen.org Thu Sep 06 09:25:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 2012 09: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 1T9YLK-0004Pl-1v; Thu, 06 Sep 2012 09:25: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 1T9YLI-0004PT-8w
	for xen-devel@lists.xen.org; Thu, 06 Sep 2012 09:25:44 +0000
Received: from [85.158.139.83:15955] by server-10.bemta-5.messagelabs.com id
	35/03-10969-71C68405; Thu, 06 Sep 2012 09:25:43 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1346923542!17618741!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM5ODQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24210 invoked from network); 6 Sep 2012 09:25:42 -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;
	6 Sep 2012 09:25:42 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 06 Sep 2012 10:25:42 +0100
Message-Id: <504887F10200007800099399@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 06 Sep 2012 10:24:33 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ben Guthro" <ben@guthro.net>
References: <50367C78.80608@citrix.com>
	<CAOvdn6U_mSNQBbeboipKHuRJzcbrCe1Kj7ZY9=7N6s--AMESmQ@mail.gmail.com>
	<503686A7.5050206@citrix.com>
	<CAOvdn6U5Kmsfv9e=Un8qNR_mbM-V2x-v7Ork9S+saj6EjC-sEA@mail.gmail.com>
	<CAOvdn6VZVVZUsUASowme-t87s8JW6WkGqHRRh64YYC24k7BQLA@mail.gmail.com>
	<50380B69020000780008A7EC@nat28.tlf.novell.com>
	<CAOvdn6U1touhawCb2GvgVQZqxhWn9CRw6-wkqdxk=uOTq015OA@mail.gmail.com>
In-Reply-To: <CAOvdn6U1touhawCb2GvgVQZqxhWn9CRw6-wkqdxk=uOTq015OA@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>, john.baboval@citrix.com,
	Thomas Goetz <thomas.goetz@citrix.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen4.2 S3 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 04.09.12 at 20:34, Ben Guthro <ben@guthro.net> wrote:
> On Fri, Aug 24, 2012 at 6:16 PM, Jan Beulich <JBeulich@suse.com> wrote:
>>>>> On 24.08.12 at 17:10, Ben Guthro <ben@guthro.net> wrote:
>>> The attached patch is essentially the change you suggested, plus a
>>> check for NULL in irq_complete_move()
>>>
>>> This patch seems to fix some of the issues I was seeing, but not all.
>>> MSI's are now delivered, after a handful of suspend / resumes, which
>>> is the issue I was setting out to solve here.
>>
>> But I'm afraid this is just masking some other problem (see my
>> response to Andrew's mail that I just sent).
>>
>> Further more, the NULL check here seems pretty odd - I'd be very
>> curious what code path could get us there with the IRQ regs
>> pointer being NULL. It would likely be that code path that needs
>> fixing, not irq_complete_move(). Could you add a call to
>> dump_execution_state() to the early return path that you added?
> 
> Apologies that I'm just getting back to this.
> 
> The call trace in this early return patch looks like this:
> 
> (XEN) Xen call trace:
> (XEN)    [<ffff82c480167d1a>] irq_complete_move+0x3e/0xd9
> (XEN)    [<ffff82c48014424a>] dma_msi_mask+0x1d/0x49
> (XEN)    [<ffff82c480169cc2>] fixup_irqs+0x19c/0x300
> (XEN)    [<ffff82c48017e762>] __cpu_disable+0x337/0x37e
> (XEN)    [<ffff82c4801013e3>] take_cpu_down+0x43/0x4a
> (XEN)    [<ffff82c480125fe6>] stopmachine_action+0x8a/0xb3
> (XEN)    [<ffff82c48012756e>] do_tasklet_work+0x8d/0xc7
> (XEN)    [<ffff82c4801278d9>] do_tasklet+0x6b/0x9b
> (XEN)    [<ffff82c480158cbd>] idle_loop+0x67/0x71
> 
> 
> This seems to get printed 4 times - twice on CPU1, and CPU2

This one appears to be relatively clear, and I'll add a tentative
fix to the next version of debugging patch that I'm in the
process of preparing: irq_complete_move() is supposed to be
getting called from the hw_irq_controllers' .ack methods, yet
VT-d currently uses the same handler for .ack and .disable
(and calling irq_complete_move() in the context of .disable
is certainly wrong) - this appears to have been the case
forever, but a flaw like this may of course get uncovered with
completely unrelated changes.

Jan

(also restored the Cc list)


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

From xen-devel-bounces@lists.xen.org Thu Sep 06 09:27:22 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 2012 09:27: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 1T9YMj-0004YV-Mj; Thu, 06 Sep 2012 09:27: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 1T9YMi-0004YM-Og
	for xen-devel@lists.xensource.com; Thu, 06 Sep 2012 09:27:12 +0000
Received: from [85.158.138.51:52027] by server-11.bemta-3.messagelabs.com id
	B7/91-30250-F6C68405; Thu, 06 Sep 2012 09:27:11 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1346923630!20096842!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTE5NzY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 952 invoked from network); 6 Sep 2012 09:27:11 -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 Sep 2012 09:27:11 -0000
X-IronPort-AV: E=Sophos;i="4.80,379,1344211200"; d="scan'208";a="14379694"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Sep 2012 09:27: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.279.1; Thu, 6 Sep 2012
	10:27:09 +0100
Message-ID: <1346923628.23055.37.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Sander Eikelenboom <linux@eikelenboom.it>
Date: Thu, 6 Sep 2012 10:27:08 +0100
In-Reply-To: <67f9ef64993791d81845.1346926055@xentest.example.org>
References: <67f9ef64993791d81845.1346926055@xentest.example.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] xl: Introduce shutdown xm compatibility
 option -a to shutdown all domains
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-09-06 at 11:07 +0100, Sander Eikelenboom wrote:
> docs/man/xl.pod.1         |   6 +++++-
>  tools/libxl/xl_cmdimpl.c  |  39 ++++++++++++++++++++++++++++++++++++---
>  tools/libxl/xl_cmdtable.c |   3 ++-
>  3 files changed, 43 insertions(+), 5 deletions(-)
> 
> 
> xl: Introduce shutdown xm compatibility option -a to shutdown all domains
> 
> Signed-off-by: Sander Eikelenboom <linux@eikelenboom.it>

Thanks Sander, however I'm afraid this comes too late for 4.2.0 (it was
always going to be tight). We should take it for 4.2.1 though.

> diff -r 9dc729b75595 -r 67f9ef649937 docs/man/xl.pod.1
> --- a/docs/man/xl.pod.1	Mon Sep 03 11:22:02 2012 +0100
> +++ b/docs/man/xl.pod.1	Thu Sep 06 12:04:12 2012 +0200
> @@ -527,7 +527,7 @@ List specifically for that domain. Other
>  
>  =back
>  
> -=item B<shutdown> [I<OPTIONS>] I<domain-id>
> +=item B<shutdown> [I<OPTIONS>] [I<domain-id>]

Perhaps write this as "I<-a|domain-id>" to make it clear one or the
other is needed?

>  Gracefully shuts down a domain.  This coordinates with the domain OS
>  to perform graceful shutdown, so there is no guarantee that it will
> @@ -550,6 +550,10 @@ B<OPTIONS>
>  
>  =over 4
>  
> +=item B<-a>
> +
> +-a  Shutdown all domains.  Often used when doing a complete shutdown of a Xen system.
> +
>  =item B<-w>
>  
>  Wait for the domain to complete shutdown before returning.
> diff -r 9dc729b75595 -r 67f9ef649937 tools/libxl/xl_cmdimpl.c
> --- a/tools/libxl/xl_cmdimpl.c	Mon Sep 03 11:22:02 2012 +0100
> +++ b/tools/libxl/xl_cmdimpl.c	Thu Sep 06 12:04:12 2012 +0200
> @@ -3670,14 +3670,20 @@ int main_destroy(int argc, char **argv)
>  
>  int main_shutdown(int argc, char **argv)
>  {
> -    int opt;
> +    libxl_dominfo *dominfo;
> +    char *domname;
> +    int opt, i, nb_domain;
> +    int all = 0;
>      int wait = 0;
>      int fallback_trigger = 0;
>  
> -    while ((opt = def_getopt(argc, argv, "wF", "shutdown", 1)) != -1) {
> +    while ((opt = def_getopt(argc, argv, "awF", "shutdown", 0)) != -1) {
>          switch (opt) {
>          case 0: case 2:
>              return opt;
> +        case 'a':
> +            all = 1;
> +            break;
>          case 'w':
>              wait = 1;
>              break;
> @@ -3687,7 +3693,34 @@ int main_shutdown(int argc, char **argv)
>          }
>      }
>  
> -    shutdown_domain(argv[optind], wait, fallback_trigger);
> +    if (!argv[optind] && !all) {
> +        fprintf(stderr, "You must specify -a or a domain id.\n\n");
> +        return opt;
> +    }
> +
> +    if (all) {
> +        if (!(dominfo = libxl_list_domain(ctx, &nb_domain))) {
> +            fprintf(stderr, "libxl_list_domain failed.\n");
> +            goto main_shutdown_out;

return -1 here, main_shutdown_out reurns 0 AKA success.

> +        }
> +
> +        for (i = 0; i<nb_domain; i++) {
> +            if (dominfo[i].domid == 0)
> +                continue;
> +
> +            domname = libxl_domid_to_name(ctx, dominfo[i].domid);
> +            if (domname)
> +                shutdown_domain(domname, wait, fallback_trigger);
> +
> +	    free(domname);
> +        }
> +
> +        libxl_dominfo_list_free(dominfo, nb_domain);
> +    } else {
> +        shutdown_domain(argv[optind], wait, fallback_trigger);
> +    }

Can you make shutdown_domain take a domid instead, which avoids the
needless libxl_domid_to_name->libxl_name_to_domid laundering in the -a
case.

Otherwise the patch looks good, thanks!

Thanks,
Ian.


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

From xen-devel-bounces@lists.xen.org Thu Sep 06 09:27:22 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 2012 09:27: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 1T9YMj-0004YV-Mj; Thu, 06 Sep 2012 09:27: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 1T9YMi-0004YM-Og
	for xen-devel@lists.xensource.com; Thu, 06 Sep 2012 09:27:12 +0000
Received: from [85.158.138.51:52027] by server-11.bemta-3.messagelabs.com id
	B7/91-30250-F6C68405; Thu, 06 Sep 2012 09:27:11 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1346923630!20096842!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTE5NzY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 952 invoked from network); 6 Sep 2012 09:27:11 -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 Sep 2012 09:27:11 -0000
X-IronPort-AV: E=Sophos;i="4.80,379,1344211200"; d="scan'208";a="14379694"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Sep 2012 09:27: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.279.1; Thu, 6 Sep 2012
	10:27:09 +0100
Message-ID: <1346923628.23055.37.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Sander Eikelenboom <linux@eikelenboom.it>
Date: Thu, 6 Sep 2012 10:27:08 +0100
In-Reply-To: <67f9ef64993791d81845.1346926055@xentest.example.org>
References: <67f9ef64993791d81845.1346926055@xentest.example.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] xl: Introduce shutdown xm compatibility
 option -a to shutdown all domains
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-09-06 at 11:07 +0100, Sander Eikelenboom wrote:
> docs/man/xl.pod.1         |   6 +++++-
>  tools/libxl/xl_cmdimpl.c  |  39 ++++++++++++++++++++++++++++++++++++---
>  tools/libxl/xl_cmdtable.c |   3 ++-
>  3 files changed, 43 insertions(+), 5 deletions(-)
> 
> 
> xl: Introduce shutdown xm compatibility option -a to shutdown all domains
> 
> Signed-off-by: Sander Eikelenboom <linux@eikelenboom.it>

Thanks Sander, however I'm afraid this comes too late for 4.2.0 (it was
always going to be tight). We should take it for 4.2.1 though.

> diff -r 9dc729b75595 -r 67f9ef649937 docs/man/xl.pod.1
> --- a/docs/man/xl.pod.1	Mon Sep 03 11:22:02 2012 +0100
> +++ b/docs/man/xl.pod.1	Thu Sep 06 12:04:12 2012 +0200
> @@ -527,7 +527,7 @@ List specifically for that domain. Other
>  
>  =back
>  
> -=item B<shutdown> [I<OPTIONS>] I<domain-id>
> +=item B<shutdown> [I<OPTIONS>] [I<domain-id>]

Perhaps write this as "I<-a|domain-id>" to make it clear one or the
other is needed?

>  Gracefully shuts down a domain.  This coordinates with the domain OS
>  to perform graceful shutdown, so there is no guarantee that it will
> @@ -550,6 +550,10 @@ B<OPTIONS>
>  
>  =over 4
>  
> +=item B<-a>
> +
> +-a  Shutdown all domains.  Often used when doing a complete shutdown of a Xen system.
> +
>  =item B<-w>
>  
>  Wait for the domain to complete shutdown before returning.
> diff -r 9dc729b75595 -r 67f9ef649937 tools/libxl/xl_cmdimpl.c
> --- a/tools/libxl/xl_cmdimpl.c	Mon Sep 03 11:22:02 2012 +0100
> +++ b/tools/libxl/xl_cmdimpl.c	Thu Sep 06 12:04:12 2012 +0200
> @@ -3670,14 +3670,20 @@ int main_destroy(int argc, char **argv)
>  
>  int main_shutdown(int argc, char **argv)
>  {
> -    int opt;
> +    libxl_dominfo *dominfo;
> +    char *domname;
> +    int opt, i, nb_domain;
> +    int all = 0;
>      int wait = 0;
>      int fallback_trigger = 0;
>  
> -    while ((opt = def_getopt(argc, argv, "wF", "shutdown", 1)) != -1) {
> +    while ((opt = def_getopt(argc, argv, "awF", "shutdown", 0)) != -1) {
>          switch (opt) {
>          case 0: case 2:
>              return opt;
> +        case 'a':
> +            all = 1;
> +            break;
>          case 'w':
>              wait = 1;
>              break;
> @@ -3687,7 +3693,34 @@ int main_shutdown(int argc, char **argv)
>          }
>      }
>  
> -    shutdown_domain(argv[optind], wait, fallback_trigger);
> +    if (!argv[optind] && !all) {
> +        fprintf(stderr, "You must specify -a or a domain id.\n\n");
> +        return opt;
> +    }
> +
> +    if (all) {
> +        if (!(dominfo = libxl_list_domain(ctx, &nb_domain))) {
> +            fprintf(stderr, "libxl_list_domain failed.\n");
> +            goto main_shutdown_out;

return -1 here, main_shutdown_out reurns 0 AKA success.

> +        }
> +
> +        for (i = 0; i<nb_domain; i++) {
> +            if (dominfo[i].domid == 0)
> +                continue;
> +
> +            domname = libxl_domid_to_name(ctx, dominfo[i].domid);
> +            if (domname)
> +                shutdown_domain(domname, wait, fallback_trigger);
> +
> +	    free(domname);
> +        }
> +
> +        libxl_dominfo_list_free(dominfo, nb_domain);
> +    } else {
> +        shutdown_domain(argv[optind], wait, fallback_trigger);
> +    }

Can you make shutdown_domain take a domid instead, which avoids the
needless libxl_domid_to_name->libxl_name_to_domid laundering in the -a
case.

Otherwise the patch looks good, thanks!

Thanks,
Ian.


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

From xen-devel-bounces@lists.xen.org Thu Sep 06 09:44:19 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 2012 09:44: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 1T9Yd1-0004u9-FE; Thu, 06 Sep 2012 09:44:03 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <linux@eikelenboom.it>) id 1T9Ycz-0004u4-Gn
	for xen-devel@lists.xensource.com; Thu, 06 Sep 2012 09:44:01 +0000
Received: from [85.158.139.83:63718] by server-1.bemta-5.messagelabs.com id
	D9/4B-32692-06078405; Thu, 06 Sep 2012 09:44:00 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-9.tower-182.messagelabs.com!1346924639!28219745!1
X-Originating-IP: [188.40.164.121]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20845 invoked from network); 6 Sep 2012 09:44:00 -0000
Received: from static.121.164.40.188.clients.your-server.de (HELO
	smtp.eikelenboom.it) (188.40.164.121)
	by server-9.tower-182.messagelabs.com with AES256-SHA encrypted SMTP;
	6 Sep 2012 09:44:00 -0000
Received: from 128-64-ftth.onsneteindhoven.nl ([88.159.64.128]:50745
	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 1T9Ycx-0006WW-Fk; Thu, 06 Sep 2012 11:43:59 +0200
Date: Thu, 6 Sep 2012 11:43:54 +0200
From: Sander Eikelenboom <linux@eikelenboom.it>
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <64723127.20120906114354@eikelenboom.it>
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1346923628.23055.37.camel@zakaz.uk.xensource.com>
References: <67f9ef64993791d81845.1346926055@xentest.example.org>
	<1346923628.23055.37.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] xl: Introduce shutdown xm compatibility
	option -a to shutdown all 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


Thursday, September 6, 2012, 11:27:08 AM, you wrote:

> On Thu, 2012-09-06 at 11:07 +0100, Sander Eikelenboom wrote:
>> docs/man/xl.pod.1         |   6 +++++-
>>  tools/libxl/xl_cmdimpl.c  |  39 ++++++++++++++++++++++++++++++++++++---
>>  tools/libxl/xl_cmdtable.c |   3 ++-
>>  3 files changed, 43 insertions(+), 5 deletions(-)
>> 
>> 
>> xl: Introduce shutdown xm compatibility option -a to shutdown all domains
>> 
>> Signed-off-by: Sander Eikelenboom <linux@eikelenboom.it>

> Thanks Sander, however I'm afraid this comes too late for 4.2.0 (it was
> always going to be tight). We should take it for 4.2.1 though.

Ok, although init.d/xendomains in combination with the default sysconfig-xendomains scripts use this (needs another patch to use the short -a instead of --all
Will respin with the changes below !


>> diff -r 9dc729b75595 -r 67f9ef649937 docs/man/xl.pod.1
>> --- a/docs/man/xl.pod.1       Mon Sep 03 11:22:02 2012 +0100
>> +++ b/docs/man/xl.pod.1       Thu Sep 06 12:04:12 2012 +0200
>> @@ -527,7 +527,7 @@ List specifically for that domain. Other
>>  
>>  =back
>>  
>> -=item B<shutdown> [I<OPTIONS>] I<domain-id>
>> +=item B<shutdown> [I<OPTIONS>] [I<domain-id>]

> Perhaps write this as "I<-a|domain-id>" to make it clear one or the
> other is needed?

>>  Gracefully shuts down a domain.  This coordinates with the domain OS
>>  to perform graceful shutdown, so there is no guarantee that it will
>> @@ -550,6 +550,10 @@ B<OPTIONS>
>>  
>>  =over 4
>>  
>> +=item B<-a>
>> +
>> +-a  Shutdown all domains.  Often used when doing a complete shutdown of a Xen system.
>> +
>>  =item B<-w>
>>  
>>  Wait for the domain to complete shutdown before returning.
>> diff -r 9dc729b75595 -r 67f9ef649937 tools/libxl/xl_cmdimpl.c
>> --- a/tools/libxl/xl_cmdimpl.c        Mon Sep 03 11:22:02 2012 +0100
>> +++ b/tools/libxl/xl_cmdimpl.c        Thu Sep 06 12:04:12 2012 +0200
>> @@ -3670,14 +3670,20 @@ int main_destroy(int argc, char **argv)
>>  
>>  int main_shutdown(int argc, char **argv)
>>  {
>> -    int opt;
>> +    libxl_dominfo *dominfo;
>> +    char *domname;
>> +    int opt, i, nb_domain;
>> +    int all = 0;
>>      int wait = 0;
>>      int fallback_trigger = 0;
>>  
>> -    while ((opt = def_getopt(argc, argv, "wF", "shutdown", 1)) != -1) {
>> +    while ((opt = def_getopt(argc, argv, "awF", "shutdown", 0)) != -1) {
>>          switch (opt) {
>>          case 0: case 2:
>>              return opt;
>> +        case 'a':
>> +            all = 1;
>> +            break;
>>          case 'w':
>>              wait = 1;
>>              break;
>> @@ -3687,7 +3693,34 @@ int main_shutdown(int argc, char **argv)
>>          }
>>      }
>>  
>> -    shutdown_domain(argv[optind], wait, fallback_trigger);
>> +    if (!argv[optind] && !all) {
>> +        fprintf(stderr, "You must specify -a or a domain id.\n\n");
>> +        return opt;
>> +    }
>> +
>> +    if (all) {
>> +        if (!(dominfo = libxl_list_domain(ctx, &nb_domain))) {
>> +            fprintf(stderr, "libxl_list_domain failed.\n");
>> +            goto main_shutdown_out;

> return -1 here, main_shutdown_out reurns 0 AKA success.

>> +        }
>> +
>> +        for (i = 0; i<nb_domain; i++) {
>> +            if (dominfo[i].domid == 0)
>> +                continue;
>> +
>> +            domname = libxl_domid_to_name(ctx, dominfo[i].domid);
>> +            if (domname)
>> +                shutdown_domain(domname, wait, fallback_trigger);
>> +
>> +         free(domname);
>> +        }
>> +
>> +        libxl_dominfo_list_free(dominfo, nb_domain);
>> +    } else {
>> +        shutdown_domain(argv[optind], wait, fallback_trigger);
>> +    }

> Can you make shutdown_domain take a domid instead, which avoids the
> needless libxl_domid_to_name->libxl_name_to_domid laundering in the -a
> case.

> Otherwise the patch looks good, thanks!

> Thanks,
> Ian.




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

From xen-devel-bounces@lists.xen.org Thu Sep 06 09:44:19 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 2012 09:44: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 1T9Yd1-0004u9-FE; Thu, 06 Sep 2012 09:44:03 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <linux@eikelenboom.it>) id 1T9Ycz-0004u4-Gn
	for xen-devel@lists.xensource.com; Thu, 06 Sep 2012 09:44:01 +0000
Received: from [85.158.139.83:63718] by server-1.bemta-5.messagelabs.com id
	D9/4B-32692-06078405; Thu, 06 Sep 2012 09:44:00 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-9.tower-182.messagelabs.com!1346924639!28219745!1
X-Originating-IP: [188.40.164.121]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20845 invoked from network); 6 Sep 2012 09:44:00 -0000
Received: from static.121.164.40.188.clients.your-server.de (HELO
	smtp.eikelenboom.it) (188.40.164.121)
	by server-9.tower-182.messagelabs.com with AES256-SHA encrypted SMTP;
	6 Sep 2012 09:44:00 -0000
Received: from 128-64-ftth.onsneteindhoven.nl ([88.159.64.128]:50745
	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 1T9Ycx-0006WW-Fk; Thu, 06 Sep 2012 11:43:59 +0200
Date: Thu, 6 Sep 2012 11:43:54 +0200
From: Sander Eikelenboom <linux@eikelenboom.it>
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <64723127.20120906114354@eikelenboom.it>
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1346923628.23055.37.camel@zakaz.uk.xensource.com>
References: <67f9ef64993791d81845.1346926055@xentest.example.org>
	<1346923628.23055.37.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] xl: Introduce shutdown xm compatibility
	option -a to shutdown all 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


Thursday, September 6, 2012, 11:27:08 AM, you wrote:

> On Thu, 2012-09-06 at 11:07 +0100, Sander Eikelenboom wrote:
>> docs/man/xl.pod.1         |   6 +++++-
>>  tools/libxl/xl_cmdimpl.c  |  39 ++++++++++++++++++++++++++++++++++++---
>>  tools/libxl/xl_cmdtable.c |   3 ++-
>>  3 files changed, 43 insertions(+), 5 deletions(-)
>> 
>> 
>> xl: Introduce shutdown xm compatibility option -a to shutdown all domains
>> 
>> Signed-off-by: Sander Eikelenboom <linux@eikelenboom.it>

> Thanks Sander, however I'm afraid this comes too late for 4.2.0 (it was
> always going to be tight). We should take it for 4.2.1 though.

Ok, although init.d/xendomains in combination with the default sysconfig-xendomains scripts use this (needs another patch to use the short -a instead of --all
Will respin with the changes below !


>> diff -r 9dc729b75595 -r 67f9ef649937 docs/man/xl.pod.1
>> --- a/docs/man/xl.pod.1       Mon Sep 03 11:22:02 2012 +0100
>> +++ b/docs/man/xl.pod.1       Thu Sep 06 12:04:12 2012 +0200
>> @@ -527,7 +527,7 @@ List specifically for that domain. Other
>>  
>>  =back
>>  
>> -=item B<shutdown> [I<OPTIONS>] I<domain-id>
>> +=item B<shutdown> [I<OPTIONS>] [I<domain-id>]

> Perhaps write this as "I<-a|domain-id>" to make it clear one or the
> other is needed?

>>  Gracefully shuts down a domain.  This coordinates with the domain OS
>>  to perform graceful shutdown, so there is no guarantee that it will
>> @@ -550,6 +550,10 @@ B<OPTIONS>
>>  
>>  =over 4
>>  
>> +=item B<-a>
>> +
>> +-a  Shutdown all domains.  Often used when doing a complete shutdown of a Xen system.
>> +
>>  =item B<-w>
>>  
>>  Wait for the domain to complete shutdown before returning.
>> diff -r 9dc729b75595 -r 67f9ef649937 tools/libxl/xl_cmdimpl.c
>> --- a/tools/libxl/xl_cmdimpl.c        Mon Sep 03 11:22:02 2012 +0100
>> +++ b/tools/libxl/xl_cmdimpl.c        Thu Sep 06 12:04:12 2012 +0200
>> @@ -3670,14 +3670,20 @@ int main_destroy(int argc, char **argv)
>>  
>>  int main_shutdown(int argc, char **argv)
>>  {
>> -    int opt;
>> +    libxl_dominfo *dominfo;
>> +    char *domname;
>> +    int opt, i, nb_domain;
>> +    int all = 0;
>>      int wait = 0;
>>      int fallback_trigger = 0;
>>  
>> -    while ((opt = def_getopt(argc, argv, "wF", "shutdown", 1)) != -1) {
>> +    while ((opt = def_getopt(argc, argv, "awF", "shutdown", 0)) != -1) {
>>          switch (opt) {
>>          case 0: case 2:
>>              return opt;
>> +        case 'a':
>> +            all = 1;
>> +            break;
>>          case 'w':
>>              wait = 1;
>>              break;
>> @@ -3687,7 +3693,34 @@ int main_shutdown(int argc, char **argv)
>>          }
>>      }
>>  
>> -    shutdown_domain(argv[optind], wait, fallback_trigger);
>> +    if (!argv[optind] && !all) {
>> +        fprintf(stderr, "You must specify -a or a domain id.\n\n");
>> +        return opt;
>> +    }
>> +
>> +    if (all) {
>> +        if (!(dominfo = libxl_list_domain(ctx, &nb_domain))) {
>> +            fprintf(stderr, "libxl_list_domain failed.\n");
>> +            goto main_shutdown_out;

> return -1 here, main_shutdown_out reurns 0 AKA success.

>> +        }
>> +
>> +        for (i = 0; i<nb_domain; i++) {
>> +            if (dominfo[i].domid == 0)
>> +                continue;
>> +
>> +            domname = libxl_domid_to_name(ctx, dominfo[i].domid);
>> +            if (domname)
>> +                shutdown_domain(domname, wait, fallback_trigger);
>> +
>> +         free(domname);
>> +        }
>> +
>> +        libxl_dominfo_list_free(dominfo, nb_domain);
>> +    } else {
>> +        shutdown_domain(argv[optind], wait, fallback_trigger);
>> +    }

> Can you make shutdown_domain take a domid instead, which avoids the
> needless libxl_domid_to_name->libxl_name_to_domid laundering in the -a
> case.

> Otherwise the patch looks good, thanks!

> Thanks,
> Ian.




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

From xen-devel-bounces@lists.xen.org Thu Sep 06 09:57:07 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 2012 09:57: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 1T9YpR-00054W-Q4; Thu, 06 Sep 2012 09:56:53 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1T9YpQ-00054R-8t
	for xen-devel@lists.xen.org; Thu, 06 Sep 2012 09:56:52 +0000
Received: from [85.158.143.99:30003] by server-1.bemta-4.messagelabs.com id
	61/19-12504-36378405; Thu, 06 Sep 2012 09:56:51 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-3.tower-216.messagelabs.com!1346925410!28281037!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31969 invoked from network); 6 Sep 2012 09:56:51 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-3.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 6 Sep 2012 09:56:51 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1T9YpN-000Es5-Mf; Thu, 06 Sep 2012 09:56:49 +0000
Date: Thu, 6 Sep 2012 10:56:49 +0100
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <ian.campbell@citrix.com>
Message-ID: <20120906095649.GA56463@ocelot.phlegethon.org>
References: <1346678886.32462.9.camel@zakaz.uk.xensource.com>
	<1346679056-8108-1-git-send-email-ian.campbell@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1346679056-8108-1-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 01/16] arm: Zero the BSS at start of day.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At 13:30 +0000 on 03 Sep (1346679041), Ian Campbell wrote:
> Avoids surprises e.g. when loading via the boot-wrapper.
> 
> 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 Sep 06 09:57:07 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 2012 09:57: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 1T9YpR-00054W-Q4; Thu, 06 Sep 2012 09:56:53 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1T9YpQ-00054R-8t
	for xen-devel@lists.xen.org; Thu, 06 Sep 2012 09:56:52 +0000
Received: from [85.158.143.99:30003] by server-1.bemta-4.messagelabs.com id
	61/19-12504-36378405; Thu, 06 Sep 2012 09:56:51 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-3.tower-216.messagelabs.com!1346925410!28281037!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31969 invoked from network); 6 Sep 2012 09:56:51 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-3.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 6 Sep 2012 09:56:51 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1T9YpN-000Es5-Mf; Thu, 06 Sep 2012 09:56:49 +0000
Date: Thu, 6 Sep 2012 10:56:49 +0100
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <ian.campbell@citrix.com>
Message-ID: <20120906095649.GA56463@ocelot.phlegethon.org>
References: <1346678886.32462.9.camel@zakaz.uk.xensource.com>
	<1346679056-8108-1-git-send-email-ian.campbell@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1346679056-8108-1-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 01/16] arm: Zero the BSS at start of day.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At 13:30 +0000 on 03 Sep (1346679041), Ian Campbell wrote:
> Avoids surprises e.g. when loading via the boot-wrapper.
> 
> 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 Sep 06 10:00:50 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 2012 10:00: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 1T9Yt1-0005G5-EU; Thu, 06 Sep 2012 10:00:35 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jiongxi.li@intel.com>) id 1T9Yt0-0005Fz-D9
	for xen-devel@lists.xen.org; Thu, 06 Sep 2012 10:00:34 +0000
Received: from [85.158.143.35:4385] by server-1.bemta-4.messagelabs.com id
	EE/41-12504-14478405; Thu, 06 Sep 2012 10:00:33 +0000
X-Env-Sender: jiongxi.li@intel.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1346925627!13673859!1
X-Originating-IP: [134.134.136.20]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjAgPT4gMjkzNjg2\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1161 invoked from network); 6 Sep 2012 10:00:31 -0000
Received: from mga02.intel.com (HELO mga02.intel.com) (134.134.136.20)
	by server-8.tower-21.messagelabs.com with SMTP;
	6 Sep 2012 10:00:31 -0000
Received: from orsmga001.jf.intel.com ([10.7.209.18])
	by orsmga101.jf.intel.com with ESMTP; 06 Sep 2012 03:00:26 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.80,379,1344236400"; d="scan'208";a="189563499"
Received: from fmsmsx108.amr.corp.intel.com ([10.19.9.228])
	by orsmga001.jf.intel.com with ESMTP; 06 Sep 2012 03:00:26 -0700
Received: from FMSMSX109.amr.corp.intel.com (10.19.9.28) by
	FMSMSX108.amr.corp.intel.com (10.19.9.228) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Thu, 6 Sep 2012 03:00:25 -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; Thu, 6 Sep 2012 03:00:26 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.239]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.175]) with mapi id
	14.01.0355.002; Thu, 6 Sep 2012 18:00:08 +0800
From: "Li, Jiongxi" <jiongxi.li@intel.com>
To: Keir Fraser <keir.xen@gmail.com>, "xen-devel@lists.xen.org"
	<xen-devel@lists.xen.org>
Thread-Topic: [Xen-devel] [ PATCH 2/2] xen: enable  Virtual-interrupt delivery
Thread-Index: Ac2HWp7G2HqBx++QQP2kPrY5SPXyLgABHshJAPpQGPA=
Date: Thu, 6 Sep 2012 10:00:08 +0000
Message-ID: <D9137FCD9CFF644B965863BCFBEDABB877CBB8@SHSMSX101.ccr.corp.intel.com>
References: <D9137FCD9CFF644B965863BCFBEDABB8779942@SHSMSX101.ccr.corp.intel.com>
	<CC664937.3D6DA%keir.xen@gmail.com>
In-Reply-To: <CC664937.3D6DA%keir.xen@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Subject: Re: [Xen-devel] [ PATCH 2/2] xen: enable Virtual-interrupt 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

Sorry for the late response.

> -----Original Message-----
> From: Keir Fraser [mailto:keir.xen@gmail.com]
> Sent: Friday, August 31, 2012 5:58 PM
> To: Li, Jiongxi; xen-devel@lists.xen.org
> Subject: Re: [Xen-devel] [ PATCH 2/2] xen: enable Virtual-interrupt delivery
> 
> On 31/08/2012 10:30, "Li, Jiongxi" <jiongxi.li@intel.com> wrote:
> 
> > Virtual interrupt delivery avoids Xen to inject vAPIC interrupts
> > manually, which is fully taken care of by the hardware. This needs
> > some special awareness into existing interrupr injection path:
> > For pending interrupt from vLAPIC, instead of direct injection, we may
> > need update architecture specific indicators before resuming to guest.
> > Before returning to guest, RVI should be updated if any pending IRRs
> > EOI exit bitmap controls whether an EOI write should cause VM-Exit. If
> > set, a trap-like induced EOI VM-Exit is triggered. The approach here
> > is to manipulate EOI exit bitmap based on value of TMR. Level
> > triggered irq requires a hook in vLAPIC EOI write, so that vIOAPIC EOI
> > is triggered and emulated
> 
> Thanks. A couple of quick comments below. This will need some careful review
> from a couple of us, I expect.
> 
>  -- Keir
> 
> > Signed-off-by: Yang Zhang <yang.z.zhang@intel.com>
> > Signed-off-by: Jiongxi Li <jiongxi.li@intel.com>
> >
> > diff -r cb821c24ca74 xen/arch/x86/hvm/irq.c
> > --- a/xen/arch/x86/hvm/irq.c  Fri Aug 31 09:30:38 2012 +0800
> > +++ b/xen/arch/x86/hvm/irq.c         Fri Aug 31 09:49:39 2012 +0800
> > @@ -452,7 +452,11 @@ struct hvm_intack hvm_vcpu_ack_pending_i
> >
> >  int hvm_local_events_need_delivery(struct vcpu *v) {
> > -    struct hvm_intack intack = hvm_vcpu_has_pending_irq(v);
> > +    struct hvm_intack intack;
> > +
> > +    pt_update_irq(v);
> 
> Why would this change be needed for vAPIC?
When vcpu is scheduled out, there will be periodic timer interrupt pending for injection. Every VMExit is a chance to inject the pending periodic timer interrupt on vmx_intr_assist. In no virtual interrupt delivery case, although injected timer interrupt is edge trigger, EOI always induces VMExit, pending periodic timer can be kept injected till there is no pending left. But in virtual interrupt delivery case, only level trigger interrupt can induce VMExit, there is much less chance for injecting pending timer interrupt through VMExit. 
Adding pt_update_irq here is another code path to inject pending periodic timer, but it can't guarantee every pending timer interrupt can be injected. Another way is to make every EOI of pending timer interrupt induce VMExit, but it may obey the spirit of virtual interrupt delivery - reducing VMExit.
We have been evaluating that.
> 
> > +    intack = hvm_vcpu_has_pending_irq(v);
> >
> >      if ( likely(intack.source == hvm_intsrc_none) )
> >          return 0;
> > diff -r cb821c24ca74 xen/arch/x86/hvm/vlapic.c
> > --- a/xen/arch/x86/hvm/vlapic.c      Fri Aug 31 09:30:38 2012 +0800
> > +++ b/xen/arch/x86/hvm/vlapic.c   Fri Aug 31 09:49:39 2012 +0800
> > @@ -143,7 +143,16 @@ static int vlapic_find_highest_irr(struc int
> > vlapic_set_irq(struct vlapic *vlapic, uint8_t vec, uint8_t trig) {
> >      if ( trig )
> > +    {
> >          vlapic_set_vector(vec, &vlapic->regs->data[APIC_TMR]);
> > +        if ( cpu_has_vmx_virtual_intr_delivery )
> > +            vmx_set_eoi_exit_bitmap(vlapic_vcpu(vlapic), vec);
> > +    }
> > +    else
> > +    {
> > +        if ( cpu_has_vmx_virtual_intr_delivery )
> > +            vmx_clear_eoi_exit_bitmap(vlapic_vcpu(vlapic), vec);
> > +    }
> >
> >      /* We may need to wake up target vcpu, besides set pending bit here
> */
> >      return !vlapic_test_and_set_irr(vec, vlapic); @@ -410,6 +419,22
> > @@ void vlapic_EOI_set(struct vlapic *vlapi
> >      hvm_dpci_msi_eoi(current->domain, vector); }
> >
> > +/*
> > + * When "Virtual Interrupt Delivery" is enabled, this function is
> > +used
> > + * to handle EOI-induced VM exit
> > + */
> > +void vlapic_handle_EOI_induced_exit(struct vlapic *vlapic, int
> > +vector) {
> > +    ASSERT(cpu_has_vmx_virtual_intr_delivery);
> > +
> > +    if ( vlapic_test_and_clear_vector(vector,
> > + &vlapic->regs->data[APIC_TMR])
> > )
> > +    {
> > +        vioapic_update_EOI(vlapic_domain(vlapic), vector);
> > +    }
> 
> No need for braces for single-line statement.
OK.
> 
> > +    hvm_dpci_msi_eoi(current->domain, vector); }
> > +
> > int vlapic_ipi(
> >      struct vlapic *vlapic, uint32_t icr_low, uint32_t icr_high) { @@
> > -1014,6 +1039,9 @@ int vlapic_has_pending_irq(struct vcpu *
> >      if ( irr == -1 )
> >          return -1;
> >
> > +    if ( cpu_has_vmx_virtual_intr_delivery )
> > +        return irr;
> 
> Why is it correct to ignore ISR here? I guess vAPIC deals with interrupt window
> automatically, maybe?
In delivery of virtual interrupt and VEOI updates, VISR[vector] is updated automatically by hardware, software doesn't need to care much about it
> 
> >      isr = vlapic_find_highest_isr(vlapic);
> >      isr = (isr != -1) ? isr : 0;
> >      if ( (isr & 0xf0) >= (irr & 0xf0) ) @@ -1026,6 +1054,9 @@ int
> > vlapic_ack_pending_irq(struct vcpu * {
> >      struct vlapic *vlapic = vcpu_vlapic(v);
> >
> > +    if ( cpu_has_vmx_virtual_intr_delivery )
> > +        return 1;
> > +
> >     vlapic_set_vector(vector, &vlapic->regs->data[APIC_ISR]);
> >      vlapic_clear_irr(vector, vlapic);
> >
> 


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

From xen-devel-bounces@lists.xen.org Thu Sep 06 10:00:50 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 2012 10:00: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 1T9Yt1-0005G5-EU; Thu, 06 Sep 2012 10:00:35 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jiongxi.li@intel.com>) id 1T9Yt0-0005Fz-D9
	for xen-devel@lists.xen.org; Thu, 06 Sep 2012 10:00:34 +0000
Received: from [85.158.143.35:4385] by server-1.bemta-4.messagelabs.com id
	EE/41-12504-14478405; Thu, 06 Sep 2012 10:00:33 +0000
X-Env-Sender: jiongxi.li@intel.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1346925627!13673859!1
X-Originating-IP: [134.134.136.20]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjAgPT4gMjkzNjg2\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1161 invoked from network); 6 Sep 2012 10:00:31 -0000
Received: from mga02.intel.com (HELO mga02.intel.com) (134.134.136.20)
	by server-8.tower-21.messagelabs.com with SMTP;
	6 Sep 2012 10:00:31 -0000
Received: from orsmga001.jf.intel.com ([10.7.209.18])
	by orsmga101.jf.intel.com with ESMTP; 06 Sep 2012 03:00:26 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.80,379,1344236400"; d="scan'208";a="189563499"
Received: from fmsmsx108.amr.corp.intel.com ([10.19.9.228])
	by orsmga001.jf.intel.com with ESMTP; 06 Sep 2012 03:00:26 -0700
Received: from FMSMSX109.amr.corp.intel.com (10.19.9.28) by
	FMSMSX108.amr.corp.intel.com (10.19.9.228) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Thu, 6 Sep 2012 03:00:25 -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; Thu, 6 Sep 2012 03:00:26 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.239]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.175]) with mapi id
	14.01.0355.002; Thu, 6 Sep 2012 18:00:08 +0800
From: "Li, Jiongxi" <jiongxi.li@intel.com>
To: Keir Fraser <keir.xen@gmail.com>, "xen-devel@lists.xen.org"
	<xen-devel@lists.xen.org>
Thread-Topic: [Xen-devel] [ PATCH 2/2] xen: enable  Virtual-interrupt delivery
Thread-Index: Ac2HWp7G2HqBx++QQP2kPrY5SPXyLgABHshJAPpQGPA=
Date: Thu, 6 Sep 2012 10:00:08 +0000
Message-ID: <D9137FCD9CFF644B965863BCFBEDABB877CBB8@SHSMSX101.ccr.corp.intel.com>
References: <D9137FCD9CFF644B965863BCFBEDABB8779942@SHSMSX101.ccr.corp.intel.com>
	<CC664937.3D6DA%keir.xen@gmail.com>
In-Reply-To: <CC664937.3D6DA%keir.xen@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Subject: Re: [Xen-devel] [ PATCH 2/2] xen: enable Virtual-interrupt 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

Sorry for the late response.

> -----Original Message-----
> From: Keir Fraser [mailto:keir.xen@gmail.com]
> Sent: Friday, August 31, 2012 5:58 PM
> To: Li, Jiongxi; xen-devel@lists.xen.org
> Subject: Re: [Xen-devel] [ PATCH 2/2] xen: enable Virtual-interrupt delivery
> 
> On 31/08/2012 10:30, "Li, Jiongxi" <jiongxi.li@intel.com> wrote:
> 
> > Virtual interrupt delivery avoids Xen to inject vAPIC interrupts
> > manually, which is fully taken care of by the hardware. This needs
> > some special awareness into existing interrupr injection path:
> > For pending interrupt from vLAPIC, instead of direct injection, we may
> > need update architecture specific indicators before resuming to guest.
> > Before returning to guest, RVI should be updated if any pending IRRs
> > EOI exit bitmap controls whether an EOI write should cause VM-Exit. If
> > set, a trap-like induced EOI VM-Exit is triggered. The approach here
> > is to manipulate EOI exit bitmap based on value of TMR. Level
> > triggered irq requires a hook in vLAPIC EOI write, so that vIOAPIC EOI
> > is triggered and emulated
> 
> Thanks. A couple of quick comments below. This will need some careful review
> from a couple of us, I expect.
> 
>  -- Keir
> 
> > Signed-off-by: Yang Zhang <yang.z.zhang@intel.com>
> > Signed-off-by: Jiongxi Li <jiongxi.li@intel.com>
> >
> > diff -r cb821c24ca74 xen/arch/x86/hvm/irq.c
> > --- a/xen/arch/x86/hvm/irq.c  Fri Aug 31 09:30:38 2012 +0800
> > +++ b/xen/arch/x86/hvm/irq.c         Fri Aug 31 09:49:39 2012 +0800
> > @@ -452,7 +452,11 @@ struct hvm_intack hvm_vcpu_ack_pending_i
> >
> >  int hvm_local_events_need_delivery(struct vcpu *v) {
> > -    struct hvm_intack intack = hvm_vcpu_has_pending_irq(v);
> > +    struct hvm_intack intack;
> > +
> > +    pt_update_irq(v);
> 
> Why would this change be needed for vAPIC?
When vcpu is scheduled out, there will be periodic timer interrupt pending for injection. Every VMExit is a chance to inject the pending periodic timer interrupt on vmx_intr_assist. In no virtual interrupt delivery case, although injected timer interrupt is edge trigger, EOI always induces VMExit, pending periodic timer can be kept injected till there is no pending left. But in virtual interrupt delivery case, only level trigger interrupt can induce VMExit, there is much less chance for injecting pending timer interrupt through VMExit. 
Adding pt_update_irq here is another code path to inject pending periodic timer, but it can't guarantee every pending timer interrupt can be injected. Another way is to make every EOI of pending timer interrupt induce VMExit, but it may obey the spirit of virtual interrupt delivery - reducing VMExit.
We have been evaluating that.
> 
> > +    intack = hvm_vcpu_has_pending_irq(v);
> >
> >      if ( likely(intack.source == hvm_intsrc_none) )
> >          return 0;
> > diff -r cb821c24ca74 xen/arch/x86/hvm/vlapic.c
> > --- a/xen/arch/x86/hvm/vlapic.c      Fri Aug 31 09:30:38 2012 +0800
> > +++ b/xen/arch/x86/hvm/vlapic.c   Fri Aug 31 09:49:39 2012 +0800
> > @@ -143,7 +143,16 @@ static int vlapic_find_highest_irr(struc int
> > vlapic_set_irq(struct vlapic *vlapic, uint8_t vec, uint8_t trig) {
> >      if ( trig )
> > +    {
> >          vlapic_set_vector(vec, &vlapic->regs->data[APIC_TMR]);
> > +        if ( cpu_has_vmx_virtual_intr_delivery )
> > +            vmx_set_eoi_exit_bitmap(vlapic_vcpu(vlapic), vec);
> > +    }
> > +    else
> > +    {
> > +        if ( cpu_has_vmx_virtual_intr_delivery )
> > +            vmx_clear_eoi_exit_bitmap(vlapic_vcpu(vlapic), vec);
> > +    }
> >
> >      /* We may need to wake up target vcpu, besides set pending bit here
> */
> >      return !vlapic_test_and_set_irr(vec, vlapic); @@ -410,6 +419,22
> > @@ void vlapic_EOI_set(struct vlapic *vlapi
> >      hvm_dpci_msi_eoi(current->domain, vector); }
> >
> > +/*
> > + * When "Virtual Interrupt Delivery" is enabled, this function is
> > +used
> > + * to handle EOI-induced VM exit
> > + */
> > +void vlapic_handle_EOI_induced_exit(struct vlapic *vlapic, int
> > +vector) {
> > +    ASSERT(cpu_has_vmx_virtual_intr_delivery);
> > +
> > +    if ( vlapic_test_and_clear_vector(vector,
> > + &vlapic->regs->data[APIC_TMR])
> > )
> > +    {
> > +        vioapic_update_EOI(vlapic_domain(vlapic), vector);
> > +    }
> 
> No need for braces for single-line statement.
OK.
> 
> > +    hvm_dpci_msi_eoi(current->domain, vector); }
> > +
> > int vlapic_ipi(
> >      struct vlapic *vlapic, uint32_t icr_low, uint32_t icr_high) { @@
> > -1014,6 +1039,9 @@ int vlapic_has_pending_irq(struct vcpu *
> >      if ( irr == -1 )
> >          return -1;
> >
> > +    if ( cpu_has_vmx_virtual_intr_delivery )
> > +        return irr;
> 
> Why is it correct to ignore ISR here? I guess vAPIC deals with interrupt window
> automatically, maybe?
In delivery of virtual interrupt and VEOI updates, VISR[vector] is updated automatically by hardware, software doesn't need to care much about it
> 
> >      isr = vlapic_find_highest_isr(vlapic);
> >      isr = (isr != -1) ? isr : 0;
> >      if ( (isr & 0xf0) >= (irr & 0xf0) ) @@ -1026,6 +1054,9 @@ int
> > vlapic_ack_pending_irq(struct vcpu * {
> >      struct vlapic *vlapic = vcpu_vlapic(v);
> >
> > +    if ( cpu_has_vmx_virtual_intr_delivery )
> > +        return 1;
> > +
> >     vlapic_set_vector(vector, &vlapic->regs->data[APIC_ISR]);
> >      vlapic_clear_irr(vector, vlapic);
> >
> 


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

From xen-devel-bounces@lists.xen.org Thu Sep 06 10:00:56 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 2012 10: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 1T9Yt9-0005Gi-S7; Thu, 06 Sep 2012 10:00:43 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jiongxi.li@intel.com>) id 1T9Yt8-0005GT-6q
	for xen-devel@lists.xen.org; Thu, 06 Sep 2012 10:00:42 +0000
Received: from [85.158.143.35:4912] by server-1.bemta-4.messagelabs.com id
	85/B1-12504-94478405; Thu, 06 Sep 2012 10:00:41 +0000
X-Env-Sender: jiongxi.li@intel.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1346925627!13673859!2
X-Originating-IP: [134.134.136.20]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjAgPT4gMjkzNjg2\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1624 invoked from network); 6 Sep 2012 10:00:38 -0000
Received: from mga02.intel.com (HELO mga02.intel.com) (134.134.136.20)
	by server-8.tower-21.messagelabs.com with SMTP;
	6 Sep 2012 10:00:38 -0000
Received: from orsmga001.jf.intel.com ([10.7.209.18])
	by orsmga101.jf.intel.com with ESMTP; 06 Sep 2012 03:00:35 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.80,379,1344236400"; d="scan'208";a="189563511"
Received: from fmsmsx105.amr.corp.intel.com ([10.19.9.36])
	by orsmga001.jf.intel.com with ESMTP; 06 Sep 2012 03:00:28 -0700
Received: from FMSMSX109.amr.corp.intel.com (10.19.9.28) by
	FMSMSX105.amr.corp.intel.com (10.19.9.36) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Thu, 6 Sep 2012 03:00:26 -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; Thu, 6 Sep 2012 03:00:26 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.239]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.175]) with mapi id
	14.01.0355.002; Thu, 6 Sep 2012 18:00:23 +0800
From: "Li, Jiongxi" <jiongxi.li@intel.com>
To: Jan Beulich <JBeulich@suse.com>
Thread-Topic: [Xen-devel] [ PATCH 1/2] xen: enable APIC-Register Virtualization
Thread-Index: Ac2HWGKAUDDr53BWQZO2/Uq+OTcM5///rYGA//YyhgA=
Date: Thu, 6 Sep 2012 10:00:22 +0000
Message-ID: <D9137FCD9CFF644B965863BCFBEDABB877CBC2@SHSMSX101.ccr.corp.intel.com>
References: <D9137FCD9CFF644B965863BCFBEDABB8779924@SHSMSX101.ccr.corp.intel.com>
	<5040C6CF0200007800097D65@nat28.tlf.novell.com>
In-Reply-To: <5040C6CF0200007800097D65@nat28.tlf.novell.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [ PATCH 1/2] xen: enable APIC-Register
 Virtualization
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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.

> -----Original Message-----
> From: Jan Beulich [mailto:JBeulich@suse.com]
> Sent: Friday, August 31, 2012 8:15 PM
> To: Li, Jiongxi
> Cc: xen-devel@lists.xen.org
> Subject: Re: [Xen-devel] [ PATCH 1/2] xen: enable APIC-Register Virtualization
> 
> >>> On 31.08.12 at 11:29, "Li, Jiongxi" <jiongxi.li@intel.com> wrote:
> > --- a/xen/arch/x86/hvm/vlapic.c      Fri Aug 24 12:38:18 2012 +0100
> > +++ b/xen/arch/x86/hvm/vlapic.c   Thu Aug 30 22:38:26 2012 +0800
> > @@ -823,6 +823,16 @@ static int vlapic_write(struct vcpu *v,
> >      return rc;
> > }
> >
> > +int vlapic_apicv_write(struct vcpu *v, unsigned int offset) {
> > +    uint32_t val = vlapic_get_reg(vcpu_vlapic(v), offset);
> > +
> > +    ASSERT(cpu_has_vmx_apic_reg_virt);
> 
> Given the function and the assertion are in a common file, both should be
> named without using VMX specific terms (or moved elsewhere).
Ok, will may the change
> 
> Jan
> 
> > +
> > +    vlapic_reg_write(v, offset, val);
> > +    return 0;
> > +}
> > +
> 


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

From xen-devel-bounces@lists.xen.org Thu Sep 06 10:00:56 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 2012 10: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 1T9Yt9-0005Gi-S7; Thu, 06 Sep 2012 10:00:43 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jiongxi.li@intel.com>) id 1T9Yt8-0005GT-6q
	for xen-devel@lists.xen.org; Thu, 06 Sep 2012 10:00:42 +0000
Received: from [85.158.143.35:4912] by server-1.bemta-4.messagelabs.com id
	85/B1-12504-94478405; Thu, 06 Sep 2012 10:00:41 +0000
X-Env-Sender: jiongxi.li@intel.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1346925627!13673859!2
X-Originating-IP: [134.134.136.20]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjAgPT4gMjkzNjg2\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1624 invoked from network); 6 Sep 2012 10:00:38 -0000
Received: from mga02.intel.com (HELO mga02.intel.com) (134.134.136.20)
	by server-8.tower-21.messagelabs.com with SMTP;
	6 Sep 2012 10:00:38 -0000
Received: from orsmga001.jf.intel.com ([10.7.209.18])
	by orsmga101.jf.intel.com with ESMTP; 06 Sep 2012 03:00:35 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.80,379,1344236400"; d="scan'208";a="189563511"
Received: from fmsmsx105.amr.corp.intel.com ([10.19.9.36])
	by orsmga001.jf.intel.com with ESMTP; 06 Sep 2012 03:00:28 -0700
Received: from FMSMSX109.amr.corp.intel.com (10.19.9.28) by
	FMSMSX105.amr.corp.intel.com (10.19.9.36) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Thu, 6 Sep 2012 03:00:26 -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; Thu, 6 Sep 2012 03:00:26 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.239]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.175]) with mapi id
	14.01.0355.002; Thu, 6 Sep 2012 18:00:23 +0800
From: "Li, Jiongxi" <jiongxi.li@intel.com>
To: Jan Beulich <JBeulich@suse.com>
Thread-Topic: [Xen-devel] [ PATCH 1/2] xen: enable APIC-Register Virtualization
Thread-Index: Ac2HWGKAUDDr53BWQZO2/Uq+OTcM5///rYGA//YyhgA=
Date: Thu, 6 Sep 2012 10:00:22 +0000
Message-ID: <D9137FCD9CFF644B965863BCFBEDABB877CBC2@SHSMSX101.ccr.corp.intel.com>
References: <D9137FCD9CFF644B965863BCFBEDABB8779924@SHSMSX101.ccr.corp.intel.com>
	<5040C6CF0200007800097D65@nat28.tlf.novell.com>
In-Reply-To: <5040C6CF0200007800097D65@nat28.tlf.novell.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [ PATCH 1/2] xen: enable APIC-Register
 Virtualization
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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.

> -----Original Message-----
> From: Jan Beulich [mailto:JBeulich@suse.com]
> Sent: Friday, August 31, 2012 8:15 PM
> To: Li, Jiongxi
> Cc: xen-devel@lists.xen.org
> Subject: Re: [Xen-devel] [ PATCH 1/2] xen: enable APIC-Register Virtualization
> 
> >>> On 31.08.12 at 11:29, "Li, Jiongxi" <jiongxi.li@intel.com> wrote:
> > --- a/xen/arch/x86/hvm/vlapic.c      Fri Aug 24 12:38:18 2012 +0100
> > +++ b/xen/arch/x86/hvm/vlapic.c   Thu Aug 30 22:38:26 2012 +0800
> > @@ -823,6 +823,16 @@ static int vlapic_write(struct vcpu *v,
> >      return rc;
> > }
> >
> > +int vlapic_apicv_write(struct vcpu *v, unsigned int offset) {
> > +    uint32_t val = vlapic_get_reg(vcpu_vlapic(v), offset);
> > +
> > +    ASSERT(cpu_has_vmx_apic_reg_virt);
> 
> Given the function and the assertion are in a common file, both should be
> named without using VMX specific terms (or moved elsewhere).
Ok, will may the change
> 
> Jan
> 
> > +
> > +    vlapic_reg_write(v, offset, val);
> > +    return 0;
> > +}
> > +
> 


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

From xen-devel-bounces@lists.xen.org Thu Sep 06 10:01:27 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 2012 10:01:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9Yti-0005L3-9m; Thu, 06 Sep 2012 10:01:18 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1T9Ytg-0005Kf-B5
	for xen-devel@lists.xen.org; Thu, 06 Sep 2012 10:01:16 +0000
Received: from [85.158.143.35:9311] by server-1.bemta-4.messagelabs.com id
	50/23-12504-B6478405; Thu, 06 Sep 2012 10:01:15 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-6.tower-21.messagelabs.com!1346925673!16945371!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9611 invoked from network); 6 Sep 2012 10:01:13 -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; 6 Sep 2012 10:01:13 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1T9Ytd-000EtC-0F; Thu, 06 Sep 2012 10:01:13 +0000
Date: Thu, 6 Sep 2012 11:01:12 +0100
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <ian.campbell@citrix.com>
Message-ID: <20120906100112.GB56463@ocelot.phlegethon.org>
References: <1346678886.32462.9.camel@zakaz.uk.xensource.com>
	<1346679056-8108-2-git-send-email-ian.campbell@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1346679056-8108-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/16] Create a raw binary target.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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:30 +0000 on 03 Sep (1346679042), Ian Campbell wrote:
> +# 
> +$(TARGET).bin: $(TARGET)-syms
> +	objcopy -O binary -R .comment -S $< $@

Why remove .comment in particular and not the other non-load sections?

Tim.

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

From xen-devel-bounces@lists.xen.org Thu Sep 06 10:01:27 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 2012 10:01:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9Yti-0005L3-9m; Thu, 06 Sep 2012 10:01:18 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1T9Ytg-0005Kf-B5
	for xen-devel@lists.xen.org; Thu, 06 Sep 2012 10:01:16 +0000
Received: from [85.158.143.35:9311] by server-1.bemta-4.messagelabs.com id
	50/23-12504-B6478405; Thu, 06 Sep 2012 10:01:15 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-6.tower-21.messagelabs.com!1346925673!16945371!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9611 invoked from network); 6 Sep 2012 10:01:13 -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; 6 Sep 2012 10:01:13 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1T9Ytd-000EtC-0F; Thu, 06 Sep 2012 10:01:13 +0000
Date: Thu, 6 Sep 2012 11:01:12 +0100
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <ian.campbell@citrix.com>
Message-ID: <20120906100112.GB56463@ocelot.phlegethon.org>
References: <1346678886.32462.9.camel@zakaz.uk.xensource.com>
	<1346679056-8108-2-git-send-email-ian.campbell@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1346679056-8108-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/16] Create a raw binary target.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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:30 +0000 on 03 Sep (1346679042), Ian Campbell wrote:
> +# 
> +$(TARGET).bin: $(TARGET)-syms
> +	objcopy -O binary -R .comment -S $< $@

Why remove .comment in particular and not the other non-load sections?

Tim.

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

From xen-devel-bounces@lists.xen.org Thu Sep 06 10:01:41 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 2012 10:01:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9Ytu-0005Nk-Mf; Thu, 06 Sep 2012 10:01:30 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jiongxi.li@intel.com>) id 1T9Ytt-0005NB-Qc
	for xen-devel@lists.xen.org; Thu, 06 Sep 2012 10:01:30 +0000
Received: from [85.158.139.83:30702] by server-10.bemta-5.messagelabs.com id
	2A/25-10969-87478405; Thu, 06 Sep 2012 10:01:28 +0000
X-Env-Sender: jiongxi.li@intel.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1346925624!17627651!1
X-Originating-IP: [143.182.124.37]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMzcgPT4gMTk2OTQ3\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27304 invoked from network); 6 Sep 2012 10:00:26 -0000
Received: from mga14.intel.com (HELO mga14.intel.com) (143.182.124.37)
	by server-8.tower-182.messagelabs.com with SMTP;
	6 Sep 2012 10:00:26 -0000
Received: from azsmga002.ch.intel.com ([10.2.17.35])
	by azsmga102.ch.intel.com with ESMTP; 06 Sep 2012 03:00:23 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.80,379,1344236400"; d="scan'208";a="142118836"
Received: from fmsmsx106.amr.corp.intel.com ([10.19.9.37])
	by AZSMGA002.ch.intel.com with ESMTP; 06 Sep 2012 03:00:22 -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, 6 Sep 2012 03:00:21 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.239]) by
	SHSMSX102.ccr.corp.intel.com ([169.254.2.92]) with mapi id
	14.01.0355.002; Thu, 6 Sep 2012 18:00:20 +0800
From: "Li, Jiongxi" <jiongxi.li@intel.com>
To: Jan Beulich <JBeulich@suse.com>
Thread-Topic: [Xen-devel] [ PATCH 2/2] xen: enable Virtual-interrupt delivery
Thread-Index: AQHNh3SPp9GzlhoirU6IqGbbi9ySy5d7dUYg
Date: Thu, 6 Sep 2012 10:00:19 +0000
Message-ID: <D9137FCD9CFF644B965863BCFBEDABB877CBBD@SHSMSX101.ccr.corp.intel.com>
References: <D9137FCD9CFF644B965863BCFBEDABB8779942@SHSMSX101.ccr.corp.intel.com>
	<5040CAB30200007800097D73@nat28.tlf.novell.com>
In-Reply-To: <5040CAB30200007800097D73@nat28.tlf.novell.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [ PATCH 2/2] xen: enable Virtual-interrupt 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

Sorry for the late response.

> -----Original Message-----
> From: xen-devel-bounces@lists.xen.org
> [mailto:xen-devel-bounces@lists.xen.org] On Behalf Of Jan Beulich
> Sent: Friday, August 31, 2012 8:31 PM
> To: Li, Jiongxi
> Cc: xen-devel@lists.xen.org
> Subject: Re: [Xen-devel] [ PATCH 2/2] xen: enable Virtual-interrupt delivery
> 
> >>> On 31.08.12 at 11:30, "Li, Jiongxi" <jiongxi.li@intel.com> wrote:
> > +/*
> > + * When "Virtual Interrupt Delivery" is enabled, this function is
> > +used
> > + * to handle EOI-induced VM exit
> > + */
> > +void vlapic_handle_EOI_induced_exit(struct vlapic *vlapic, int
> > +vector) {
> > +    ASSERT(cpu_has_vmx_virtual_intr_delivery);
> > +
> > +    if ( vlapic_test_and_clear_vector(vector,
> > + &vlapic->regs->data[APIC_TMR]) )
> 
> Why test_and_clear rather than just test?
While virtual interrupt delivery is enabled, 'vlapic_EOI_set' function won't be called( 'vlapic_EOI_set' also has the test and clear call). ' vlapic->regs->data[APIC_TMR]' set by 'vlapic_set_irq' should be clear here, or the interrupt of the same vector will be always treated as level trigger even it becomes edge trigger later.
> 
> > +    {
> > +        vioapic_update_EOI(vlapic_domain(vlapic), vector);
> > +    }
> > +
> > +    hvm_dpci_msi_eoi(current->domain, vector); }
> >...
> > --- a/xen/arch/x86/hvm/vmx/intr.c Fri Aug 31 09:30:38 2012 +0800
> > +++ b/xen/arch/x86/hvm/vmx/intr.c       Fri Aug 31 09:49:39 2012 +0800
> > @@ -227,19 +227,43 @@ void vmx_intr_assist(void)
> >              goto out;
> >
> >          intblk = hvm_interrupt_blocked(v, intack);
> > -        if ( intblk == hvm_intblk_tpr )
> > +        if ( cpu_has_vmx_virtual_intr_delivery )
> >          {
> > -            ASSERT(vlapic_enabled(vcpu_vlapic(v)));
> > -            ASSERT(intack.source == hvm_intsrc_lapic);
> > -            tpr_threshold = intack.vector >> 4;
> > -            goto out;
> > +            /* Set "Interrupt-window exiting" for ExtINT */
> > +            if ( (intblk != hvm_intblk_none) &&
> > +                 ( (intack.source == hvm_intsrc_pic) ||
> > +                 ( intack.source == hvm_intsrc_vector) ) )
> > +            {
> > +                enable_intr_window(v, intack);
> > +                goto out;
> > +            }
> > +
> > +            if ( __vmread(VM_ENTRY_INTR_INFO) &
> INTR_INFO_VALID_MASK )
> > +            {
> > +                if ( (intack.source == hvm_intsrc_pic) ||
> > +                     (intack.source == hvm_intsrc_nmi) ||
> > +                     (intack.source == hvm_intsrc_mce) )
> > +                    enable_intr_window(v, intack);
> > +
> > +                goto out;
> > +            }
> >          }
> > +        else
> > +        {
> > +            if ( intblk == hvm_intblk_tpr )
> > +            {
> > +                ASSERT(vlapic_enabled(vcpu_vlapic(v)));
> > +                ASSERT(intack.source == hvm_intsrc_lapic);
> > +                tpr_threshold = intack.vector >> 4;
> > +                goto out;
> > +            }
> >
> > -        if ( (intblk != hvm_intblk_none) ||
> > -             (__vmread(VM_ENTRY_INTR_INFO) &
> INTR_INFO_VALID_MASK) )
> > -        {
> > -            enable_intr_window(v, intack);
> > -            goto out;
> > +            if ( (intblk != hvm_intblk_none) ||
> > +                 (__vmread(VM_ENTRY_INTR_INFO) &
> INTR_INFO_VALID_MASK) )
> > +            {
> > +                enable_intr_window(v, intack);
> > +                goto out;
> > +            }
> >          }
> 
> If you made the above and if()/else if() series, some of the differences would go
> away, making the changes easier to review.
I can't quite understand you here.
The original code looked like:
if (a)
{}
if (b)
{}
And my change as follow:
if ( cpu_has_vmx_virtual_intr_delivery )
{
}
else
{
  if (a)
  {}
  if (b)
  {}
}
How should I adjust the code?

> 
> >
> >          intack = hvm_vcpu_ack_pending_irq(v, intack); @@ -253,6
> > +277,29 @@ void vmx_intr_assist(void)
> >      {
> >          hvm_inject_hw_exception(TRAP_machine_check,
> HVM_DELIVER_NO_ERROR_CODE);
> >      }
> > +    else if ( cpu_has_vmx_virtual_intr_delivery &&
> > +              intack.source != hvm_intsrc_pic &&
> > +              intack.source != hvm_intsrc_vector )
> > +    {
> > +        /* we need update the RVI field */
> > +        unsigned long status = __vmread(GUEST_INTR_STATUS);
> > +        status &= ~(unsigned long)0x0FF;
> > +        status |= (unsigned long)0x0FF &
> > +                    intack.vector;
> > +        __vmwrite(GUEST_INTR_STATUS, status);
> > +        if (v->arch.hvm_vmx.eoi_exitmap_changed) {
> > +#define UPDATE_EOI_EXITMAP(v, e) {                             \
> > +        if (test_and_clear_bit(e, &(v).eoi_exitmap_changed)) {      \
> 
> Here and elsewhere - do you really need locked accesses?
Do you mean using the '__test_and_set_bit' ?
> 
> > +                __vmwrite(EOI_EXIT_BITMAP##e,
> > + (v).eoi_exit_bitmap[e]);}}
> > +
> > +                UPDATE_EOI_EXITMAP(v->arch.hvm_vmx, 0);
> 
> This is not very logical: Passing just 'v' to the macro, and accessing the full field
> there would be more consistent.
OK, I will modify the passing just 'v' to the macro and modify the macro
> 
> Furthermore, here and in other places you fail to write the upper halves for
> 32-bit, yet you also don't disable the code for 32-bit afaics.
OK, __vmwrite(EOI_EXIT_BITMAP##e, (v).eoi_exit_bitmap[e]) ;would be
  __vmwrite(EOI_EXIT_BITMAP##e, (v).eoi_exit_bitmap[e])
#ifdef __i386__
  __vmwrite(EOI_EXIT_BITMAP##e##_HIGH, (v).eoi_exit_bitmap[e] >> 32)
#endif
> 
> > +                UPDATE_EOI_EXITMAP(v->arch.hvm_vmx, 1);
> > +                UPDATE_EOI_EXITMAP(v->arch.hvm_vmx, 2);
> > +                UPDATE_EOI_EXITMAP(v->arch.hvm_vmx, 3);
> > +        }
> > +
> > +        pt_intr_post(v, intack);
> > +    }
> >      else
> >      {
> >          HVMTRACE_2D(INJ_VIRQ, intack.vector, /*fake=*/ 0);
> 
> 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 Sep 06 10:01:41 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 2012 10:01:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9Ytu-0005Nk-Mf; Thu, 06 Sep 2012 10:01:30 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jiongxi.li@intel.com>) id 1T9Ytt-0005NB-Qc
	for xen-devel@lists.xen.org; Thu, 06 Sep 2012 10:01:30 +0000
Received: from [85.158.139.83:30702] by server-10.bemta-5.messagelabs.com id
	2A/25-10969-87478405; Thu, 06 Sep 2012 10:01:28 +0000
X-Env-Sender: jiongxi.li@intel.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1346925624!17627651!1
X-Originating-IP: [143.182.124.37]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMzcgPT4gMTk2OTQ3\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27304 invoked from network); 6 Sep 2012 10:00:26 -0000
Received: from mga14.intel.com (HELO mga14.intel.com) (143.182.124.37)
	by server-8.tower-182.messagelabs.com with SMTP;
	6 Sep 2012 10:00:26 -0000
Received: from azsmga002.ch.intel.com ([10.2.17.35])
	by azsmga102.ch.intel.com with ESMTP; 06 Sep 2012 03:00:23 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.80,379,1344236400"; d="scan'208";a="142118836"
Received: from fmsmsx106.amr.corp.intel.com ([10.19.9.37])
	by AZSMGA002.ch.intel.com with ESMTP; 06 Sep 2012 03:00:22 -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, 6 Sep 2012 03:00:21 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.239]) by
	SHSMSX102.ccr.corp.intel.com ([169.254.2.92]) with mapi id
	14.01.0355.002; Thu, 6 Sep 2012 18:00:20 +0800
From: "Li, Jiongxi" <jiongxi.li@intel.com>
To: Jan Beulich <JBeulich@suse.com>
Thread-Topic: [Xen-devel] [ PATCH 2/2] xen: enable Virtual-interrupt delivery
Thread-Index: AQHNh3SPp9GzlhoirU6IqGbbi9ySy5d7dUYg
Date: Thu, 6 Sep 2012 10:00:19 +0000
Message-ID: <D9137FCD9CFF644B965863BCFBEDABB877CBBD@SHSMSX101.ccr.corp.intel.com>
References: <D9137FCD9CFF644B965863BCFBEDABB8779942@SHSMSX101.ccr.corp.intel.com>
	<5040CAB30200007800097D73@nat28.tlf.novell.com>
In-Reply-To: <5040CAB30200007800097D73@nat28.tlf.novell.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [ PATCH 2/2] xen: enable Virtual-interrupt 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

Sorry for the late response.

> -----Original Message-----
> From: xen-devel-bounces@lists.xen.org
> [mailto:xen-devel-bounces@lists.xen.org] On Behalf Of Jan Beulich
> Sent: Friday, August 31, 2012 8:31 PM
> To: Li, Jiongxi
> Cc: xen-devel@lists.xen.org
> Subject: Re: [Xen-devel] [ PATCH 2/2] xen: enable Virtual-interrupt delivery
> 
> >>> On 31.08.12 at 11:30, "Li, Jiongxi" <jiongxi.li@intel.com> wrote:
> > +/*
> > + * When "Virtual Interrupt Delivery" is enabled, this function is
> > +used
> > + * to handle EOI-induced VM exit
> > + */
> > +void vlapic_handle_EOI_induced_exit(struct vlapic *vlapic, int
> > +vector) {
> > +    ASSERT(cpu_has_vmx_virtual_intr_delivery);
> > +
> > +    if ( vlapic_test_and_clear_vector(vector,
> > + &vlapic->regs->data[APIC_TMR]) )
> 
> Why test_and_clear rather than just test?
While virtual interrupt delivery is enabled, 'vlapic_EOI_set' function won't be called( 'vlapic_EOI_set' also has the test and clear call). ' vlapic->regs->data[APIC_TMR]' set by 'vlapic_set_irq' should be clear here, or the interrupt of the same vector will be always treated as level trigger even it becomes edge trigger later.
> 
> > +    {
> > +        vioapic_update_EOI(vlapic_domain(vlapic), vector);
> > +    }
> > +
> > +    hvm_dpci_msi_eoi(current->domain, vector); }
> >...
> > --- a/xen/arch/x86/hvm/vmx/intr.c Fri Aug 31 09:30:38 2012 +0800
> > +++ b/xen/arch/x86/hvm/vmx/intr.c       Fri Aug 31 09:49:39 2012 +0800
> > @@ -227,19 +227,43 @@ void vmx_intr_assist(void)
> >              goto out;
> >
> >          intblk = hvm_interrupt_blocked(v, intack);
> > -        if ( intblk == hvm_intblk_tpr )
> > +        if ( cpu_has_vmx_virtual_intr_delivery )
> >          {
> > -            ASSERT(vlapic_enabled(vcpu_vlapic(v)));
> > -            ASSERT(intack.source == hvm_intsrc_lapic);
> > -            tpr_threshold = intack.vector >> 4;
> > -            goto out;
> > +            /* Set "Interrupt-window exiting" for ExtINT */
> > +            if ( (intblk != hvm_intblk_none) &&
> > +                 ( (intack.source == hvm_intsrc_pic) ||
> > +                 ( intack.source == hvm_intsrc_vector) ) )
> > +            {
> > +                enable_intr_window(v, intack);
> > +                goto out;
> > +            }
> > +
> > +            if ( __vmread(VM_ENTRY_INTR_INFO) &
> INTR_INFO_VALID_MASK )
> > +            {
> > +                if ( (intack.source == hvm_intsrc_pic) ||
> > +                     (intack.source == hvm_intsrc_nmi) ||
> > +                     (intack.source == hvm_intsrc_mce) )
> > +                    enable_intr_window(v, intack);
> > +
> > +                goto out;
> > +            }
> >          }
> > +        else
> > +        {
> > +            if ( intblk == hvm_intblk_tpr )
> > +            {
> > +                ASSERT(vlapic_enabled(vcpu_vlapic(v)));
> > +                ASSERT(intack.source == hvm_intsrc_lapic);
> > +                tpr_threshold = intack.vector >> 4;
> > +                goto out;
> > +            }
> >
> > -        if ( (intblk != hvm_intblk_none) ||
> > -             (__vmread(VM_ENTRY_INTR_INFO) &
> INTR_INFO_VALID_MASK) )
> > -        {
> > -            enable_intr_window(v, intack);
> > -            goto out;
> > +            if ( (intblk != hvm_intblk_none) ||
> > +                 (__vmread(VM_ENTRY_INTR_INFO) &
> INTR_INFO_VALID_MASK) )
> > +            {
> > +                enable_intr_window(v, intack);
> > +                goto out;
> > +            }
> >          }
> 
> If you made the above and if()/else if() series, some of the differences would go
> away, making the changes easier to review.
I can't quite understand you here.
The original code looked like:
if (a)
{}
if (b)
{}
And my change as follow:
if ( cpu_has_vmx_virtual_intr_delivery )
{
}
else
{
  if (a)
  {}
  if (b)
  {}
}
How should I adjust the code?

> 
> >
> >          intack = hvm_vcpu_ack_pending_irq(v, intack); @@ -253,6
> > +277,29 @@ void vmx_intr_assist(void)
> >      {
> >          hvm_inject_hw_exception(TRAP_machine_check,
> HVM_DELIVER_NO_ERROR_CODE);
> >      }
> > +    else if ( cpu_has_vmx_virtual_intr_delivery &&
> > +              intack.source != hvm_intsrc_pic &&
> > +              intack.source != hvm_intsrc_vector )
> > +    {
> > +        /* we need update the RVI field */
> > +        unsigned long status = __vmread(GUEST_INTR_STATUS);
> > +        status &= ~(unsigned long)0x0FF;
> > +        status |= (unsigned long)0x0FF &
> > +                    intack.vector;
> > +        __vmwrite(GUEST_INTR_STATUS, status);
> > +        if (v->arch.hvm_vmx.eoi_exitmap_changed) {
> > +#define UPDATE_EOI_EXITMAP(v, e) {                             \
> > +        if (test_and_clear_bit(e, &(v).eoi_exitmap_changed)) {      \
> 
> Here and elsewhere - do you really need locked accesses?
Do you mean using the '__test_and_set_bit' ?
> 
> > +                __vmwrite(EOI_EXIT_BITMAP##e,
> > + (v).eoi_exit_bitmap[e]);}}
> > +
> > +                UPDATE_EOI_EXITMAP(v->arch.hvm_vmx, 0);
> 
> This is not very logical: Passing just 'v' to the macro, and accessing the full field
> there would be more consistent.
OK, I will modify the passing just 'v' to the macro and modify the macro
> 
> Furthermore, here and in other places you fail to write the upper halves for
> 32-bit, yet you also don't disable the code for 32-bit afaics.
OK, __vmwrite(EOI_EXIT_BITMAP##e, (v).eoi_exit_bitmap[e]) ;would be
  __vmwrite(EOI_EXIT_BITMAP##e, (v).eoi_exit_bitmap[e])
#ifdef __i386__
  __vmwrite(EOI_EXIT_BITMAP##e##_HIGH, (v).eoi_exit_bitmap[e] >> 32)
#endif
> 
> > +                UPDATE_EOI_EXITMAP(v->arch.hvm_vmx, 1);
> > +                UPDATE_EOI_EXITMAP(v->arch.hvm_vmx, 2);
> > +                UPDATE_EOI_EXITMAP(v->arch.hvm_vmx, 3);
> > +        }
> > +
> > +        pt_intr_post(v, intack);
> > +    }
> >      else
> >      {
> >          HVMTRACE_2D(INJ_VIRQ, intack.vector, /*fake=*/ 0);
> 
> 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 Sep 06 10:03:16 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 2012 10:03:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9YvS-0005gQ-I1; Thu, 06 Sep 2012 10:03:06 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1T9YvR-0005fi-6S
	for xen-devel@lists.xen.org; Thu, 06 Sep 2012 10:03:05 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-11.tower-27.messagelabs.com!1346925754!2893197!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14479 invoked from network); 6 Sep 2012 10:02:34 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-11.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 6 Sep 2012 10:02:34 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1T9Yuv-000EtZ-Oh; Thu, 06 Sep 2012 10:02:33 +0000
Date: Thu, 6 Sep 2012 11:02:33 +0100
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <ian.campbell@citrix.com>
Message-ID: <20120906100233.GC56463@ocelot.phlegethon.org>
References: <1346678886.32462.9.camel@zakaz.uk.xensource.com>
	<1346679056-8108-3-git-send-email-ian.campbell@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1346679056-8108-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/16] arm: make virtual address defines
	unsigned
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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:30 +0000 on 03 Sep (1346679043), Ian Campbell wrote:
> avoids confusion due to overflow 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 Sep 06 10:03:16 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 2012 10:03:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9YvS-0005gQ-I1; Thu, 06 Sep 2012 10:03:06 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1T9YvR-0005fi-6S
	for xen-devel@lists.xen.org; Thu, 06 Sep 2012 10:03:05 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-11.tower-27.messagelabs.com!1346925754!2893197!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14479 invoked from network); 6 Sep 2012 10:02:34 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-11.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 6 Sep 2012 10:02:34 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1T9Yuv-000EtZ-Oh; Thu, 06 Sep 2012 10:02:33 +0000
Date: Thu, 6 Sep 2012 11:02:33 +0100
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <ian.campbell@citrix.com>
Message-ID: <20120906100233.GC56463@ocelot.phlegethon.org>
References: <1346678886.32462.9.camel@zakaz.uk.xensource.com>
	<1346679056-8108-3-git-send-email-ian.campbell@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1346679056-8108-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/16] arm: make virtual address defines
	unsigned
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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:30 +0000 on 03 Sep (1346679043), Ian Campbell wrote:
> avoids confusion due to overflow 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 Sep 06 10:22:01 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 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 1T9ZDX-0006EN-95; Thu, 06 Sep 2012 10:21:47 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1T9ZDV-0006EF-4S
	for xen-devel@lists.xen.org; Thu, 06 Sep 2012 10:21:45 +0000
Received: from [85.158.139.83:39721] by server-6.bemta-5.messagelabs.com id
	ED/F8-21336-83978405; Thu, 06 Sep 2012 10:21:44 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1346926903!21688585!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM5ODQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7107 invoked from network); 6 Sep 2012 10:21:43 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-11.tower-182.messagelabs.com with SMTP;
	6 Sep 2012 10:21:43 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 06 Sep 2012 11:21:43 +0100
Message-Id: <5048958D02000078000993EB@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 06 Sep 2012 11:22:37 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ben Guthro" <ben@guthro.net>
References: <CAOvdn6WwgBD-2yf1uu3m9-16=Tb5KUrybXf2KibtnxKbP7YtwA@mail.gmail.com>
	<CAOvdn6UBW-yTOMd3YSf5M9JiHLRivyaKL-qzcKG8epszqaKmGg@mail.gmail.com>
	<20120807163320.GC15053@phenom.dumpdata.com>
	<CAOvdn6XcRGKtJxGwJO8J+ZBJr89wfTLc1woW5rhtMM540H9h1w@mail.gmail.com>
	<CAOvdn6XUoSeGoo7X=AJ1kpDxZB9HZEv+TJ4v-=FHcyR4=CHK-w@mail.gmail.com>
	<502240F302000078000937A6@nat28.tlf.novell.com>
	<CAOvdn6WN3kxC8Bb9g6MpfLULu47EGSGCtajPc-SFeJ-8VSUQDQ@mail.gmail.com>
	<CAOvdn6Xk1inm1hU55i0phU2qvSWyJLNoyDdn43biBAY2OewPtw@mail.gmail.com>
	<5023F5400200007800093F4E@nat28.tlf.novell.com>
	<CAOvdn6U-f3C4U8xVPvDyRFkFFLkbfiCXg_n+9zgA9V5u+q5jfw@mail.gmail.com>
	<5023F8B80200007800093F8C@nat28.tlf.novell.com>
	<CAOvdn6XKHfete_+=Hkvt20G7_cJ-4i8+9j9YD30OxzQ16Ru-+g@mail.gmail.com>
	<5024CB720200007800094124@nat28.tlf.novell.com>
	<CAOvdn6VVJdhWVYa-gNVt3euE4AbGi1TijUCUd1wGzv0SCWEUYA@mail.gmail.com>
	<CAOvdn6USnG9Y4MNBhrDZmob0oJ8BgFfKTvFEhcKbXDxNmzfZ-Q@mail.gmail.com>
	<502B75BA0200007800094FD4@nat28.tlf.novell.com>
	<CAOvdn6Ww5oEj6Xg=XT4dWCYWUBuOdPqLz-CqNjz4HmCScE+==g@mail.gmail.com>
	<CAOvdn6Wsjds_dmZ0dwDTYmD-o-OqjBH5-b9mitAuUADE+A4_ag@mail.gmail.com>
	<502BB8FD02000078000951E0@nat28.tlf.novell.com>
	<CAOvdn6VD6bp13F-tvYdkBsj4hkhE7PTGZrapndtdHrDKeZqccg@mail.gmail.com>
	<502CCC0002000078000955C4@nat28.tlf.novell.com>
	<CAOvdn6VEuX7R2_wz74ZvCxMjC-=YUir9kP5sdxEVaKVspRUd_w@mail.gmail.com>
	<502CF0A8020000780009574E@nat28.tlf.novell.com>
	<CAOvdn6VsZvn_1TCWYeuyY5YuTcP8=miK2KwE4583nsj6Qjb_vg@mail.gmail.com>
	<504494FB0200007800098398@nat28.tlf.novell.com>
	<CAOvdn6UT13qvWbMyfZkWND03RoVKVSgb6wW4yqTUpuBYEX01Dg@mail.gmail.com>
In-Reply-To: <CAOvdn6UT13qvWbMyfZkWND03RoVKVSgb6wW4yqTUpuBYEX01Dg@mail.gmail.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part7445617D.2__="
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>, john.baboval@citrix.com,
	Thomas Goetz <thomas.goetz@citrix.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen4.2 S3 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>
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.

--=__Part7445617D.2__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

>>> On 04.09.12 at 14:27, Ben Guthro <ben@guthro.net> wrote:
> I've put the console log of this test run here:
> https://citrix.sharefile.com/d/sdc383e252fb41c5a=20
>=20
> (again, so as not to clog everyone's inbox)
>=20
> I have not yet gone through the log in its entirety yet, but thought I
> would first send it to you to see if you had something in particular
> you were looking for.
>=20
> The file name is console-S3-MSI.txt

I think that nailed it: pci_restore_msi_state() passed a pointer
to the stored entry->msg to write_msi_msg(), but with interrupt
remapping enabled that function's call to
iommu_update_ire_from_msi() alters the passed in struct
msi_msg instance. As the stored value is used for nothing but
a subsequent (second) restore, a problem would only arise if
between the two saves to further writing of the stored entry
would occur (i.e. no intermediate call to set_msi_affinity()).

Attached the advertised next version of the debugging patch
(printks - slightly altered - left in to catch eventual further
problems or to deal with my analysis being wrong; none of the
"bogus!" ones should now trigger anymore). If this works, I'd
be curious to see how much of your other workaround code
you could then remove without breaking things again.

Jan


--=__Part7445617D.2__=
Content-Type: text/plain; name="S3-MSI.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="S3-MSI.patch"

--- a/xen/arch/x86/msi.c=0A+++ b/xen/arch/x86/msi.c=0A@@ -207,10 +207,22 =
@@ static void read_msi_msg(struct msi_desc=0A =0A static void write_msi_ms=
g(struct msi_desc *entry, struct msi_msg *msg)=0A {=0A+ if(!(msg->data & =
MSI_DATA_VECTOR_MASK) || !(msg->data & MSI_DATA_LEVEL_ASSERT)//temp=0A+    =
|| (msg->data & MSI_DATA_DELIVERY_MODE_MASK) > MSI_DATA_DELIVERY_LOWPRI) =
{//temp=0A+  printk("MSI: addr=3D%08x%08x data=3D%08x dest=3D%08x =
bogus!\n", msg->address_hi, msg->address_lo, msg->data, msg->dest32);=0A+  =
dump_execution_state();=0A+ }=0A     entry->msg =3D *msg;=0A =0A     if ( =
iommu_enabled )=0A+    {=0A+        ASSERT(msg !=3D &entry->msg);=0A       =
  iommu_update_ire_from_msi(entry, msg);=0A+ if(!(entry->msg.data & =
MSI_DATA_VECTOR_MASK) || !(entry->msg.data & MSI_DATA_LEVEL_ASSERT)//temp=
=0A+    || (entry->msg.data & MSI_DATA_DELIVERY_MODE_MASK) > MSI_DATA_DELIV=
ERY_LOWPRI)//temp=0A+  printk("MSI: addr=3D%08x%08x data=3D%08x dest=3D%08x=
 (%08x) bogus!\n",//temp=0A+         entry->msg.address_hi, entry->msg.addr=
ess_lo, entry->msg.data, entry->msg.dest32, msg->address_lo);//temp=0A+    =
}=0A =0A     switch ( entry->msi_attrib.type )=0A     {=0A@@ -268,6 =
+280,11 @@ static void set_msi_affinity(struct irq_=0A =0A     memset(&msg,=
 0, sizeof(msg));=0A     read_msi_msg(msi_desc, &msg);=0A+ if(!(msg.data & =
MSI_DATA_VECTOR_MASK) || !(msg.data & MSI_DATA_LEVEL_ASSERT)//temp=0A+    =
|| (msg.data & MSI_DATA_DELIVERY_MODE_MASK) > MSI_DATA_DELIVERY_LOWPRI) =
{//temp=0A+  printk("MSI: addr=3D%08x%08x data=3D%08x bogus!\n", msg.addres=
s_hi, msg.address_lo, msg.data);=0A+  dump_execution_state();=0A+ }=0A =0A =
    msg.data &=3D ~MSI_DATA_VECTOR_MASK;=0A     msg.data |=3D MSI_DATA_VECT=
OR(desc->arch.vector);=0A@@ -996,6 +1013,7 @@ int pci_restore_msi_state(str=
uct pci_dev=0A     int ret;=0A     struct msi_desc *entry, *tmp;=0A     =
struct irq_desc *desc;=0A+    struct msi_msg msg;=0A =0A     ASSERT(spin_is=
_locked(&pcidevs_lock));=0A =0A@@ -1024,13 +1042,17 @@ int pci_restore_msi_=
state(struct pci_dev=0A             spin_unlock_irqrestore(&desc->lock, =
flags);=0A             return -EINVAL;=0A         }=0A+printk("MSI[%04x:%02=
x:%02x:%u]: addr=3D%08x%08x data=3D%08x dest=3D%08x\n",//temp=0A+       =
pdev->seg, pdev->bus, PCI_SLOT(pdev->devfn), PCI_FUNC(pdev->devfn),//temp=
=0A+       entry->msg.address_hi, entry->msg.address_lo, entry->msg.data, =
entry->msg.dest32);//temp=0A =0A         if ( entry->msi_attrib.type =
=3D=3D PCI_CAP_ID_MSI )=0A             msi_set_enable(pdev, 0);=0A         =
else if ( entry->msi_attrib.type =3D=3D PCI_CAP_ID_MSIX )=0A             =
msix_set_enable(pdev, 0);=0A =0A-        write_msi_msg(entry, &entry->msg);=
=0A+        msg =3D entry->msg;=0A+        write_msi_msg(entry, &msg);=0A =
=0A         msi_set_mask_bit(desc, entry->msi_attrib.masked);=0A =0A--- =
a/xen/drivers/passthrough/vtd/iommu.c=0A+++ b/xen/drivers/passthrough/vtd/i=
ommu.c=0A@@ -1040,8 +1040,6 @@ static void dma_msi_mask(struct irq_desc=0A =
    unsigned long flags;=0A     struct iommu *iommu =3D desc->action->dev_i=
d;=0A =0A-    irq_complete_move(desc);=0A-=0A     /* mask it */=0A     =
spin_lock_irqsave(&iommu->register_lock, flags);=0A     dmar_writel(iommu->=
reg, DMAR_FECTL_REG, DMA_FECTL_IM);=0A@@ -1054,6 +1052,13 @@ static =
unsigned int dma_msi_startup(stru=0A     return 0;=0A }=0A =0A+static void =
dma_msi_ack(struct irq_desc *desc)=0A+{=0A+    irq_complete_move(desc);=0A+=
    dma_msi_mask(desc);=0A+    move_masked_irq(desc);=0A+}=0A+=0A static =
void dma_msi_end(struct irq_desc *desc, u8 vector)=0A {=0A     dma_msi_unma=
sk(desc);=0A@@ -1115,7 +1120,7 @@ static hw_irq_controller dma_msi_type =
=3D =0A     .shutdown =3D dma_msi_mask,=0A     .enable =3D dma_msi_unmask,=
=0A     .disable =3D dma_msi_mask,=0A-    .ack =3D dma_msi_mask,=0A+    =
.ack =3D dma_msi_ack,=0A     .end =3D dma_msi_end,=0A     .set_affinity =
=3D dma_msi_set_affinity,=0A };=0A
--=__Part7445617D.2__=
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--=__Part7445617D.2__=--


From xen-devel-bounces@lists.xen.org Thu Sep 06 10:22:01 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 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 1T9ZDX-0006EN-95; Thu, 06 Sep 2012 10:21:47 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1T9ZDV-0006EF-4S
	for xen-devel@lists.xen.org; Thu, 06 Sep 2012 10:21:45 +0000
Received: from [85.158.139.83:39721] by server-6.bemta-5.messagelabs.com id
	ED/F8-21336-83978405; Thu, 06 Sep 2012 10:21:44 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1346926903!21688585!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM5ODQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7107 invoked from network); 6 Sep 2012 10:21:43 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-11.tower-182.messagelabs.com with SMTP;
	6 Sep 2012 10:21:43 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 06 Sep 2012 11:21:43 +0100
Message-Id: <5048958D02000078000993EB@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 06 Sep 2012 11:22:37 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ben Guthro" <ben@guthro.net>
References: <CAOvdn6WwgBD-2yf1uu3m9-16=Tb5KUrybXf2KibtnxKbP7YtwA@mail.gmail.com>
	<CAOvdn6UBW-yTOMd3YSf5M9JiHLRivyaKL-qzcKG8epszqaKmGg@mail.gmail.com>
	<20120807163320.GC15053@phenom.dumpdata.com>
	<CAOvdn6XcRGKtJxGwJO8J+ZBJr89wfTLc1woW5rhtMM540H9h1w@mail.gmail.com>
	<CAOvdn6XUoSeGoo7X=AJ1kpDxZB9HZEv+TJ4v-=FHcyR4=CHK-w@mail.gmail.com>
	<502240F302000078000937A6@nat28.tlf.novell.com>
	<CAOvdn6WN3kxC8Bb9g6MpfLULu47EGSGCtajPc-SFeJ-8VSUQDQ@mail.gmail.com>
	<CAOvdn6Xk1inm1hU55i0phU2qvSWyJLNoyDdn43biBAY2OewPtw@mail.gmail.com>
	<5023F5400200007800093F4E@nat28.tlf.novell.com>
	<CAOvdn6U-f3C4U8xVPvDyRFkFFLkbfiCXg_n+9zgA9V5u+q5jfw@mail.gmail.com>
	<5023F8B80200007800093F8C@nat28.tlf.novell.com>
	<CAOvdn6XKHfete_+=Hkvt20G7_cJ-4i8+9j9YD30OxzQ16Ru-+g@mail.gmail.com>
	<5024CB720200007800094124@nat28.tlf.novell.com>
	<CAOvdn6VVJdhWVYa-gNVt3euE4AbGi1TijUCUd1wGzv0SCWEUYA@mail.gmail.com>
	<CAOvdn6USnG9Y4MNBhrDZmob0oJ8BgFfKTvFEhcKbXDxNmzfZ-Q@mail.gmail.com>
	<502B75BA0200007800094FD4@nat28.tlf.novell.com>
	<CAOvdn6Ww5oEj6Xg=XT4dWCYWUBuOdPqLz-CqNjz4HmCScE+==g@mail.gmail.com>
	<CAOvdn6Wsjds_dmZ0dwDTYmD-o-OqjBH5-b9mitAuUADE+A4_ag@mail.gmail.com>
	<502BB8FD02000078000951E0@nat28.tlf.novell.com>
	<CAOvdn6VD6bp13F-tvYdkBsj4hkhE7PTGZrapndtdHrDKeZqccg@mail.gmail.com>
	<502CCC0002000078000955C4@nat28.tlf.novell.com>
	<CAOvdn6VEuX7R2_wz74ZvCxMjC-=YUir9kP5sdxEVaKVspRUd_w@mail.gmail.com>
	<502CF0A8020000780009574E@nat28.tlf.novell.com>
	<CAOvdn6VsZvn_1TCWYeuyY5YuTcP8=miK2KwE4583nsj6Qjb_vg@mail.gmail.com>
	<504494FB0200007800098398@nat28.tlf.novell.com>
	<CAOvdn6UT13qvWbMyfZkWND03RoVKVSgb6wW4yqTUpuBYEX01Dg@mail.gmail.com>
In-Reply-To: <CAOvdn6UT13qvWbMyfZkWND03RoVKVSgb6wW4yqTUpuBYEX01Dg@mail.gmail.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part7445617D.2__="
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>, john.baboval@citrix.com,
	Thomas Goetz <thomas.goetz@citrix.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen4.2 S3 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>
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.

--=__Part7445617D.2__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

>>> On 04.09.12 at 14:27, Ben Guthro <ben@guthro.net> wrote:
> I've put the console log of this test run here:
> https://citrix.sharefile.com/d/sdc383e252fb41c5a=20
>=20
> (again, so as not to clog everyone's inbox)
>=20
> I have not yet gone through the log in its entirety yet, but thought I
> would first send it to you to see if you had something in particular
> you were looking for.
>=20
> The file name is console-S3-MSI.txt

I think that nailed it: pci_restore_msi_state() passed a pointer
to the stored entry->msg to write_msi_msg(), but with interrupt
remapping enabled that function's call to
iommu_update_ire_from_msi() alters the passed in struct
msi_msg instance. As the stored value is used for nothing but
a subsequent (second) restore, a problem would only arise if
between the two saves to further writing of the stored entry
would occur (i.e. no intermediate call to set_msi_affinity()).

Attached the advertised next version of the debugging patch
(printks - slightly altered - left in to catch eventual further
problems or to deal with my analysis being wrong; none of the
"bogus!" ones should now trigger anymore). If this works, I'd
be curious to see how much of your other workaround code
you could then remove without breaking things again.

Jan


--=__Part7445617D.2__=
Content-Type: text/plain; name="S3-MSI.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="S3-MSI.patch"

--- a/xen/arch/x86/msi.c=0A+++ b/xen/arch/x86/msi.c=0A@@ -207,10 +207,22 =
@@ static void read_msi_msg(struct msi_desc=0A =0A static void write_msi_ms=
g(struct msi_desc *entry, struct msi_msg *msg)=0A {=0A+ if(!(msg->data & =
MSI_DATA_VECTOR_MASK) || !(msg->data & MSI_DATA_LEVEL_ASSERT)//temp=0A+    =
|| (msg->data & MSI_DATA_DELIVERY_MODE_MASK) > MSI_DATA_DELIVERY_LOWPRI) =
{//temp=0A+  printk("MSI: addr=3D%08x%08x data=3D%08x dest=3D%08x =
bogus!\n", msg->address_hi, msg->address_lo, msg->data, msg->dest32);=0A+  =
dump_execution_state();=0A+ }=0A     entry->msg =3D *msg;=0A =0A     if ( =
iommu_enabled )=0A+    {=0A+        ASSERT(msg !=3D &entry->msg);=0A       =
  iommu_update_ire_from_msi(entry, msg);=0A+ if(!(entry->msg.data & =
MSI_DATA_VECTOR_MASK) || !(entry->msg.data & MSI_DATA_LEVEL_ASSERT)//temp=
=0A+    || (entry->msg.data & MSI_DATA_DELIVERY_MODE_MASK) > MSI_DATA_DELIV=
ERY_LOWPRI)//temp=0A+  printk("MSI: addr=3D%08x%08x data=3D%08x dest=3D%08x=
 (%08x) bogus!\n",//temp=0A+         entry->msg.address_hi, entry->msg.addr=
ess_lo, entry->msg.data, entry->msg.dest32, msg->address_lo);//temp=0A+    =
}=0A =0A     switch ( entry->msi_attrib.type )=0A     {=0A@@ -268,6 =
+280,11 @@ static void set_msi_affinity(struct irq_=0A =0A     memset(&msg,=
 0, sizeof(msg));=0A     read_msi_msg(msi_desc, &msg);=0A+ if(!(msg.data & =
MSI_DATA_VECTOR_MASK) || !(msg.data & MSI_DATA_LEVEL_ASSERT)//temp=0A+    =
|| (msg.data & MSI_DATA_DELIVERY_MODE_MASK) > MSI_DATA_DELIVERY_LOWPRI) =
{//temp=0A+  printk("MSI: addr=3D%08x%08x data=3D%08x bogus!\n", msg.addres=
s_hi, msg.address_lo, msg.data);=0A+  dump_execution_state();=0A+ }=0A =0A =
    msg.data &=3D ~MSI_DATA_VECTOR_MASK;=0A     msg.data |=3D MSI_DATA_VECT=
OR(desc->arch.vector);=0A@@ -996,6 +1013,7 @@ int pci_restore_msi_state(str=
uct pci_dev=0A     int ret;=0A     struct msi_desc *entry, *tmp;=0A     =
struct irq_desc *desc;=0A+    struct msi_msg msg;=0A =0A     ASSERT(spin_is=
_locked(&pcidevs_lock));=0A =0A@@ -1024,13 +1042,17 @@ int pci_restore_msi_=
state(struct pci_dev=0A             spin_unlock_irqrestore(&desc->lock, =
flags);=0A             return -EINVAL;=0A         }=0A+printk("MSI[%04x:%02=
x:%02x:%u]: addr=3D%08x%08x data=3D%08x dest=3D%08x\n",//temp=0A+       =
pdev->seg, pdev->bus, PCI_SLOT(pdev->devfn), PCI_FUNC(pdev->devfn),//temp=
=0A+       entry->msg.address_hi, entry->msg.address_lo, entry->msg.data, =
entry->msg.dest32);//temp=0A =0A         if ( entry->msi_attrib.type =
=3D=3D PCI_CAP_ID_MSI )=0A             msi_set_enable(pdev, 0);=0A         =
else if ( entry->msi_attrib.type =3D=3D PCI_CAP_ID_MSIX )=0A             =
msix_set_enable(pdev, 0);=0A =0A-        write_msi_msg(entry, &entry->msg);=
=0A+        msg =3D entry->msg;=0A+        write_msi_msg(entry, &msg);=0A =
=0A         msi_set_mask_bit(desc, entry->msi_attrib.masked);=0A =0A--- =
a/xen/drivers/passthrough/vtd/iommu.c=0A+++ b/xen/drivers/passthrough/vtd/i=
ommu.c=0A@@ -1040,8 +1040,6 @@ static void dma_msi_mask(struct irq_desc=0A =
    unsigned long flags;=0A     struct iommu *iommu =3D desc->action->dev_i=
d;=0A =0A-    irq_complete_move(desc);=0A-=0A     /* mask it */=0A     =
spin_lock_irqsave(&iommu->register_lock, flags);=0A     dmar_writel(iommu->=
reg, DMAR_FECTL_REG, DMA_FECTL_IM);=0A@@ -1054,6 +1052,13 @@ static =
unsigned int dma_msi_startup(stru=0A     return 0;=0A }=0A =0A+static void =
dma_msi_ack(struct irq_desc *desc)=0A+{=0A+    irq_complete_move(desc);=0A+=
    dma_msi_mask(desc);=0A+    move_masked_irq(desc);=0A+}=0A+=0A static =
void dma_msi_end(struct irq_desc *desc, u8 vector)=0A {=0A     dma_msi_unma=
sk(desc);=0A@@ -1115,7 +1120,7 @@ static hw_irq_controller dma_msi_type =
=3D =0A     .shutdown =3D dma_msi_mask,=0A     .enable =3D dma_msi_unmask,=
=0A     .disable =3D dma_msi_mask,=0A-    .ack =3D dma_msi_mask,=0A+    =
.ack =3D dma_msi_ack,=0A     .end =3D dma_msi_end,=0A     .set_affinity =
=3D dma_msi_set_affinity,=0A };=0A
--=__Part7445617D.2__=
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--=__Part7445617D.2__=--


From xen-devel-bounces@lists.xen.org Thu Sep 06 10:29:53 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 2012 10: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 1T9ZL4-0006V5-7t; Thu, 06 Sep 2012 10:29: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 1T9ZL2-0006V0-TQ
	for xen-devel@lists.xen.org; Thu, 06 Sep 2012 10:29:33 +0000
Received: from [85.158.143.35:15467] by server-3.bemta-4.messagelabs.com id
	91/E1-08232-C0B78405; Thu, 06 Sep 2012 10:29:32 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1346927368!5261135!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTE5NzY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12188 invoked from network); 6 Sep 2012 10:29:29 -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 Sep 2012 10:29:29 -0000
X-IronPort-AV: E=Sophos;i="4.80,380,1344211200"; d="scan'208";a="14381721"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Sep 2012 10:29: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.279.1; Thu, 6 Sep 2012
	11:29:26 +0100
Message-ID: <1346927365.23055.38.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Tim Deegan <tim@xen.org>
Date: Thu, 6 Sep 2012 11:29:25 +0100
In-Reply-To: <20120906100112.GB56463@ocelot.phlegethon.org>
References: <1346678886.32462.9.camel@zakaz.uk.xensource.com>
	<1346679056-8108-2-git-send-email-ian.campbell@citrix.com>
	<20120906100112.GB56463@ocelot.phlegethon.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 02/16] Create a raw binary target.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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-09-06 at 11:01 +0100, Tim Deegan wrote:
> At 13:30 +0000 on 03 Sep (1346679042), Ian Campbell wrote:
> > +# 
> > +$(TARGET).bin: $(TARGET)-syms
> > +	objcopy -O binary -R .comment -S $< $@
> 
> Why remove .comment in particular and not the other non-load sections?

Because wherever I copied the rune from (probably Linux) did ;-)

Ian.


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

From xen-devel-bounces@lists.xen.org Thu Sep 06 10:29:53 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 2012 10: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 1T9ZL4-0006V5-7t; Thu, 06 Sep 2012 10:29: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 1T9ZL2-0006V0-TQ
	for xen-devel@lists.xen.org; Thu, 06 Sep 2012 10:29:33 +0000
Received: from [85.158.143.35:15467] by server-3.bemta-4.messagelabs.com id
	91/E1-08232-C0B78405; Thu, 06 Sep 2012 10:29:32 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1346927368!5261135!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTE5NzY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12188 invoked from network); 6 Sep 2012 10:29:29 -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 Sep 2012 10:29:29 -0000
X-IronPort-AV: E=Sophos;i="4.80,380,1344211200"; d="scan'208";a="14381721"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Sep 2012 10:29: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.279.1; Thu, 6 Sep 2012
	11:29:26 +0100
Message-ID: <1346927365.23055.38.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Tim Deegan <tim@xen.org>
Date: Thu, 6 Sep 2012 11:29:25 +0100
In-Reply-To: <20120906100112.GB56463@ocelot.phlegethon.org>
References: <1346678886.32462.9.camel@zakaz.uk.xensource.com>
	<1346679056-8108-2-git-send-email-ian.campbell@citrix.com>
	<20120906100112.GB56463@ocelot.phlegethon.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 02/16] Create a raw binary target.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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-09-06 at 11:01 +0100, Tim Deegan wrote:
> At 13:30 +0000 on 03 Sep (1346679042), Ian Campbell wrote:
> > +# 
> > +$(TARGET).bin: $(TARGET)-syms
> > +	objcopy -O binary -R .comment -S $< $@
> 
> Why remove .comment in particular and not the other non-load sections?

Because wherever I copied the rune from (probably Linux) did ;-)

Ian.


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

From xen-devel-bounces@lists.xen.org Thu Sep 06 10:34:43 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 2012 10:34:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9ZPo-0006eP-VH; Thu, 06 Sep 2012 10:34:28 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1T9ZPn-0006eJ-6v
	for xen-devel@lists.xen.org; Thu, 06 Sep 2012 10:34:27 +0000
Received: from [85.158.143.99:28963] by server-1.bemta-4.messagelabs.com id
	F2/A8-12504-23C78405; Thu, 06 Sep 2012 10:34:26 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1346927665!21847002!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM5ODQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11059 invoked from network); 6 Sep 2012 10:34:25 -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;
	6 Sep 2012 10:34:25 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 06 Sep 2012 11:34:25 +0100
Message-Id: <504898870200007800099427@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 06 Sep 2012 11:35:19 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Jiongxi Li" <jiongxi.li@intel.com>
References: <D9137FCD9CFF644B965863BCFBEDABB8779942@SHSMSX101.ccr.corp.intel.com>
	<5040CAB30200007800097D73@nat28.tlf.novell.com>
	<D9137FCD9CFF644B965863BCFBEDABB877CBBD@SHSMSX101.ccr.corp.intel.com>
In-Reply-To: <D9137FCD9CFF644B965863BCFBEDABB877CBBD@SHSMSX101.ccr.corp.intel.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [ PATCH 2/2] xen: enable Virtual-interrupt 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

>>> On 06.09.12 at 12:00, "Li, Jiongxi" <jiongxi.li@intel.com> wrote:
>> > +/*
>> > + * When "Virtual Interrupt Delivery" is enabled, this function is
>> > +used
>> > + * to handle EOI-induced VM exit
>> > + */
>> > +void vlapic_handle_EOI_induced_exit(struct vlapic *vlapic, int
>> > +vector) {
>> > +    ASSERT(cpu_has_vmx_virtual_intr_delivery);
>> > +
>> > +    if ( vlapic_test_and_clear_vector(vector,
>> > + &vlapic->regs->data[APIC_TMR]) )
>> 
>> Why test_and_clear rather than just test?
> While virtual interrupt delivery is enabled, 'vlapic_EOI_set' function won't 
> be called( 'vlapic_EOI_set' also has the test and clear call). ' 

Ah, okay.

>> > --- a/xen/arch/x86/hvm/vmx/intr.c Fri Aug 31 09:30:38 2012 +0800
>> > +++ b/xen/arch/x86/hvm/vmx/intr.c       Fri Aug 31 09:49:39 2012 +0800
>> > @@ -227,19 +227,43 @@ void vmx_intr_assist(void)
>> >              goto out;
>> >
>> >          intblk = hvm_interrupt_blocked(v, intack);
>> > -        if ( intblk == hvm_intblk_tpr )
>> > +        if ( cpu_has_vmx_virtual_intr_delivery )
>> >          {
>> > -            ASSERT(vlapic_enabled(vcpu_vlapic(v)));
>> > -            ASSERT(intack.source == hvm_intsrc_lapic);
>> > -            tpr_threshold = intack.vector >> 4;
>> > -            goto out;
>> > +            /* Set "Interrupt-window exiting" for ExtINT */
>> > +            if ( (intblk != hvm_intblk_none) &&
>> > +                 ( (intack.source == hvm_intsrc_pic) ||
>> > +                 ( intack.source == hvm_intsrc_vector) ) )
>> > +            {
>> > +                enable_intr_window(v, intack);
>> > +                goto out;
>> > +            }
>> > +
>> > +            if ( __vmread(VM_ENTRY_INTR_INFO) &
>> INTR_INFO_VALID_MASK )
>> > +            {
>> > +                if ( (intack.source == hvm_intsrc_pic) ||
>> > +                     (intack.source == hvm_intsrc_nmi) ||
>> > +                     (intack.source == hvm_intsrc_mce) )
>> > +                    enable_intr_window(v, intack);
>> > +
>> > +                goto out;
>> > +            }
>> >          }
>> > +        else
>> > +        {
>> > +            if ( intblk == hvm_intblk_tpr )
>> > +            {
>> > +                ASSERT(vlapic_enabled(vcpu_vlapic(v)));
>> > +                ASSERT(intack.source == hvm_intsrc_lapic);
>> > +                tpr_threshold = intack.vector >> 4;
>> > +                goto out;
>> > +            }
>> >
>> > -        if ( (intblk != hvm_intblk_none) ||
>> > -             (__vmread(VM_ENTRY_INTR_INFO) &
>> INTR_INFO_VALID_MASK) )
>> > -        {
>> > -            enable_intr_window(v, intack);
>> > -            goto out;
>> > +            if ( (intblk != hvm_intblk_none) ||
>> > +                 (__vmread(VM_ENTRY_INTR_INFO) &
>> INTR_INFO_VALID_MASK) )
>> > +            {
>> > +                enable_intr_window(v, intack);
>> > +                goto out;
>> > +            }
>> >          }
>> 
>> If you made the above and if()/else if() series, some of the differences 
> would go
>> away, making the changes easier to review.
> I can't quite understand you here.
> The original code looked like:
> if (a)
> {}
> if (b)
> {}
> And my change as follow:
> if ( cpu_has_vmx_virtual_intr_delivery )
> {
> }
> else
> {
>   if (a)
>   {}
>   if (b)
>   {}
> }
> How should I adjust the code?

Considering that the original could already have been written
with if/else-if, I was suggesting to expand this to your addition:

if ( cpu_has_vmx_virtual_intr_delivery )
{
}
else if (a)
  {}
else if (b)
  {}

which will avoid any (indentation only) changes past the first of
the two else-if-s. Plus it would make the logic of the code more
clear, at once likely making apparent that there'll now be quite
a few "goto out"-s that ought to be check for being replaceable
by fewer instances of them placed slightly differently.

>> > +#define UPDATE_EOI_EXITMAP(v, e) {                             \
>> > +        if (test_and_clear_bit(e, &(v).eoi_exitmap_changed)) {      \
>> 
>> Here and elsewhere - do you really need locked accesses?
> Do you mean using the '__test_and_set_bit' ?

Yes, if suitable.

>> Furthermore, here and in other places you fail to write the upper halves for
>> 32-bit, yet you also don't disable the code for 32-bit afaics.
> OK, __vmwrite(EOI_EXIT_BITMAP##e, (v).eoi_exit_bitmap[e]) ;would be
>   __vmwrite(EOI_EXIT_BITMAP##e, (v).eoi_exit_bitmap[e])
> #ifdef __i386__
>   __vmwrite(EOI_EXIT_BITMAP##e##_HIGH, (v).eoi_exit_bitmap[e] >> 32)
> #endif

Something along those lines, yes.

Jan

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

From xen-devel-bounces@lists.xen.org Thu Sep 06 10:34:43 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 2012 10:34:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9ZPo-0006eP-VH; Thu, 06 Sep 2012 10:34:28 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1T9ZPn-0006eJ-6v
	for xen-devel@lists.xen.org; Thu, 06 Sep 2012 10:34:27 +0000
Received: from [85.158.143.99:28963] by server-1.bemta-4.messagelabs.com id
	F2/A8-12504-23C78405; Thu, 06 Sep 2012 10:34:26 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1346927665!21847002!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM5ODQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11059 invoked from network); 6 Sep 2012 10:34:25 -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;
	6 Sep 2012 10:34:25 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 06 Sep 2012 11:34:25 +0100
Message-Id: <504898870200007800099427@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 06 Sep 2012 11:35:19 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Jiongxi Li" <jiongxi.li@intel.com>
References: <D9137FCD9CFF644B965863BCFBEDABB8779942@SHSMSX101.ccr.corp.intel.com>
	<5040CAB30200007800097D73@nat28.tlf.novell.com>
	<D9137FCD9CFF644B965863BCFBEDABB877CBBD@SHSMSX101.ccr.corp.intel.com>
In-Reply-To: <D9137FCD9CFF644B965863BCFBEDABB877CBBD@SHSMSX101.ccr.corp.intel.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [ PATCH 2/2] xen: enable Virtual-interrupt 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

>>> On 06.09.12 at 12:00, "Li, Jiongxi" <jiongxi.li@intel.com> wrote:
>> > +/*
>> > + * When "Virtual Interrupt Delivery" is enabled, this function is
>> > +used
>> > + * to handle EOI-induced VM exit
>> > + */
>> > +void vlapic_handle_EOI_induced_exit(struct vlapic *vlapic, int
>> > +vector) {
>> > +    ASSERT(cpu_has_vmx_virtual_intr_delivery);
>> > +
>> > +    if ( vlapic_test_and_clear_vector(vector,
>> > + &vlapic->regs->data[APIC_TMR]) )
>> 
>> Why test_and_clear rather than just test?
> While virtual interrupt delivery is enabled, 'vlapic_EOI_set' function won't 
> be called( 'vlapic_EOI_set' also has the test and clear call). ' 

Ah, okay.

>> > --- a/xen/arch/x86/hvm/vmx/intr.c Fri Aug 31 09:30:38 2012 +0800
>> > +++ b/xen/arch/x86/hvm/vmx/intr.c       Fri Aug 31 09:49:39 2012 +0800
>> > @@ -227,19 +227,43 @@ void vmx_intr_assist(void)
>> >              goto out;
>> >
>> >          intblk = hvm_interrupt_blocked(v, intack);
>> > -        if ( intblk == hvm_intblk_tpr )
>> > +        if ( cpu_has_vmx_virtual_intr_delivery )
>> >          {
>> > -            ASSERT(vlapic_enabled(vcpu_vlapic(v)));
>> > -            ASSERT(intack.source == hvm_intsrc_lapic);
>> > -            tpr_threshold = intack.vector >> 4;
>> > -            goto out;
>> > +            /* Set "Interrupt-window exiting" for ExtINT */
>> > +            if ( (intblk != hvm_intblk_none) &&
>> > +                 ( (intack.source == hvm_intsrc_pic) ||
>> > +                 ( intack.source == hvm_intsrc_vector) ) )
>> > +            {
>> > +                enable_intr_window(v, intack);
>> > +                goto out;
>> > +            }
>> > +
>> > +            if ( __vmread(VM_ENTRY_INTR_INFO) &
>> INTR_INFO_VALID_MASK )
>> > +            {
>> > +                if ( (intack.source == hvm_intsrc_pic) ||
>> > +                     (intack.source == hvm_intsrc_nmi) ||
>> > +                     (intack.source == hvm_intsrc_mce) )
>> > +                    enable_intr_window(v, intack);
>> > +
>> > +                goto out;
>> > +            }
>> >          }
>> > +        else
>> > +        {
>> > +            if ( intblk == hvm_intblk_tpr )
>> > +            {
>> > +                ASSERT(vlapic_enabled(vcpu_vlapic(v)));
>> > +                ASSERT(intack.source == hvm_intsrc_lapic);
>> > +                tpr_threshold = intack.vector >> 4;
>> > +                goto out;
>> > +            }
>> >
>> > -        if ( (intblk != hvm_intblk_none) ||
>> > -             (__vmread(VM_ENTRY_INTR_INFO) &
>> INTR_INFO_VALID_MASK) )
>> > -        {
>> > -            enable_intr_window(v, intack);
>> > -            goto out;
>> > +            if ( (intblk != hvm_intblk_none) ||
>> > +                 (__vmread(VM_ENTRY_INTR_INFO) &
>> INTR_INFO_VALID_MASK) )
>> > +            {
>> > +                enable_intr_window(v, intack);
>> > +                goto out;
>> > +            }
>> >          }
>> 
>> If you made the above and if()/else if() series, some of the differences 
> would go
>> away, making the changes easier to review.
> I can't quite understand you here.
> The original code looked like:
> if (a)
> {}
> if (b)
> {}
> And my change as follow:
> if ( cpu_has_vmx_virtual_intr_delivery )
> {
> }
> else
> {
>   if (a)
>   {}
>   if (b)
>   {}
> }
> How should I adjust the code?

Considering that the original could already have been written
with if/else-if, I was suggesting to expand this to your addition:

if ( cpu_has_vmx_virtual_intr_delivery )
{
}
else if (a)
  {}
else if (b)
  {}

which will avoid any (indentation only) changes past the first of
the two else-if-s. Plus it would make the logic of the code more
clear, at once likely making apparent that there'll now be quite
a few "goto out"-s that ought to be check for being replaceable
by fewer instances of them placed slightly differently.

>> > +#define UPDATE_EOI_EXITMAP(v, e) {                             \
>> > +        if (test_and_clear_bit(e, &(v).eoi_exitmap_changed)) {      \
>> 
>> Here and elsewhere - do you really need locked accesses?
> Do you mean using the '__test_and_set_bit' ?

Yes, if suitable.

>> Furthermore, here and in other places you fail to write the upper halves for
>> 32-bit, yet you also don't disable the code for 32-bit afaics.
> OK, __vmwrite(EOI_EXIT_BITMAP##e, (v).eoi_exit_bitmap[e]) ;would be
>   __vmwrite(EOI_EXIT_BITMAP##e, (v).eoi_exit_bitmap[e])
> #ifdef __i386__
>   __vmwrite(EOI_EXIT_BITMAP##e##_HIGH, (v).eoi_exit_bitmap[e] >> 32)
> #endif

Something along those lines, yes.

Jan

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

From xen-devel-bounces@lists.xen.org Thu Sep 06 10:39:59 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 2012 10:39:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9ZUw-0006o6-N4; Thu, 06 Sep 2012 10:39: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 1T9ZUv-0006nw-5V
	for xen-devel@lists.xen.org; Thu, 06 Sep 2012 10:39:45 +0000
Received: from [85.158.139.83:63789] by server-8.bemta-5.messagelabs.com id
	55/09-17085-07D78405; Thu, 06 Sep 2012 10:39:44 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1346927983!24650557!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM5ODQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16955 invoked from network); 6 Sep 2012 10:39:43 -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;
	6 Sep 2012 10:39:43 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 06 Sep 2012 11:39:43 +0100
Message-Id: <504899C40200007800099435@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 06 Sep 2012 11:40:36 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Jiongxi Li" <jiongxi.li@intel.com>
References: <D9137FCD9CFF644B965863BCFBEDABB8779942@SHSMSX101.ccr.corp.intel.com>
	<CC664937.3D6DA%keir.xen@gmail.com>
	<D9137FCD9CFF644B965863BCFBEDABB877CBB8@SHSMSX101.ccr.corp.intel.com>
In-Reply-To: <D9137FCD9CFF644B965863BCFBEDABB877CBB8@SHSMSX101.ccr.corp.intel.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Keir Fraser <keir.xen@gmail.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [ PATCH 2/2] xen: enable Virtual-interrupt 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

>>> On 06.09.12 at 12:00, "Li, Jiongxi" <jiongxi.li@intel.com> wrote:
>> From: Keir Fraser [mailto:keir.xen@gmail.com]
>> On 31/08/2012 10:30, "Li, Jiongxi" <jiongxi.li@intel.com> wrote:
>> > --- a/xen/arch/x86/hvm/irq.c  Fri Aug 31 09:30:38 2012 +0800
>> > +++ b/xen/arch/x86/hvm/irq.c         Fri Aug 31 09:49:39 2012 +0800
>> > @@ -452,7 +452,11 @@ struct hvm_intack hvm_vcpu_ack_pending_i
>> >
>> >  int hvm_local_events_need_delivery(struct vcpu *v) {
>> > -    struct hvm_intack intack = hvm_vcpu_has_pending_irq(v);
>> > +    struct hvm_intack intack;
>> > +
>> > +    pt_update_irq(v);
>> 
>> Why would this change be needed for vAPIC?
> When vcpu is scheduled out, there will be periodic timer interrupt pending 

Probably rather "may"?

> for injection. Every VMExit is a chance to inject the pending periodic timer 
> interrupt on vmx_intr_assist. In no virtual interrupt delivery case, although 
> injected timer interrupt is edge trigger, EOI always induces VMExit, pending 
> periodic timer can be kept injected till there is no pending left. But in 
> virtual interrupt delivery case, only level trigger interrupt can induce 
> VMExit, there is much less chance for injecting pending timer interrupt 
> through VMExit. 

And it's not possible to set the respective VIRR[] bit, and let the
hardware take care of injecting at the right time?

> Adding pt_update_irq here is another code path to inject pending periodic 
> timer, but it can't guarantee every pending timer interrupt can be injected. 
> Another way is to make every EOI of pending timer interrupt induce VMExit, 
> but it may obey the spirit of virtual interrupt delivery - reducing VMExit.
> We have been evaluating that.

With which result?

Jan


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

From xen-devel-bounces@lists.xen.org Thu Sep 06 10:39:59 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 2012 10:39:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9ZUw-0006o6-N4; Thu, 06 Sep 2012 10:39: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 1T9ZUv-0006nw-5V
	for xen-devel@lists.xen.org; Thu, 06 Sep 2012 10:39:45 +0000
Received: from [85.158.139.83:63789] by server-8.bemta-5.messagelabs.com id
	55/09-17085-07D78405; Thu, 06 Sep 2012 10:39:44 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1346927983!24650557!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM5ODQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16955 invoked from network); 6 Sep 2012 10:39:43 -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;
	6 Sep 2012 10:39:43 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 06 Sep 2012 11:39:43 +0100
Message-Id: <504899C40200007800099435@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 06 Sep 2012 11:40:36 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Jiongxi Li" <jiongxi.li@intel.com>
References: <D9137FCD9CFF644B965863BCFBEDABB8779942@SHSMSX101.ccr.corp.intel.com>
	<CC664937.3D6DA%keir.xen@gmail.com>
	<D9137FCD9CFF644B965863BCFBEDABB877CBB8@SHSMSX101.ccr.corp.intel.com>
In-Reply-To: <D9137FCD9CFF644B965863BCFBEDABB877CBB8@SHSMSX101.ccr.corp.intel.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Keir Fraser <keir.xen@gmail.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [ PATCH 2/2] xen: enable Virtual-interrupt 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

>>> On 06.09.12 at 12:00, "Li, Jiongxi" <jiongxi.li@intel.com> wrote:
>> From: Keir Fraser [mailto:keir.xen@gmail.com]
>> On 31/08/2012 10:30, "Li, Jiongxi" <jiongxi.li@intel.com> wrote:
>> > --- a/xen/arch/x86/hvm/irq.c  Fri Aug 31 09:30:38 2012 +0800
>> > +++ b/xen/arch/x86/hvm/irq.c         Fri Aug 31 09:49:39 2012 +0800
>> > @@ -452,7 +452,11 @@ struct hvm_intack hvm_vcpu_ack_pending_i
>> >
>> >  int hvm_local_events_need_delivery(struct vcpu *v) {
>> > -    struct hvm_intack intack = hvm_vcpu_has_pending_irq(v);
>> > +    struct hvm_intack intack;
>> > +
>> > +    pt_update_irq(v);
>> 
>> Why would this change be needed for vAPIC?
> When vcpu is scheduled out, there will be periodic timer interrupt pending 

Probably rather "may"?

> for injection. Every VMExit is a chance to inject the pending periodic timer 
> interrupt on vmx_intr_assist. In no virtual interrupt delivery case, although 
> injected timer interrupt is edge trigger, EOI always induces VMExit, pending 
> periodic timer can be kept injected till there is no pending left. But in 
> virtual interrupt delivery case, only level trigger interrupt can induce 
> VMExit, there is much less chance for injecting pending timer interrupt 
> through VMExit. 

And it's not possible to set the respective VIRR[] bit, and let the
hardware take care of injecting at the right time?

> Adding pt_update_irq here is another code path to inject pending periodic 
> timer, but it can't guarantee every pending timer interrupt can be injected. 
> Another way is to make every EOI of pending timer interrupt induce VMExit, 
> but it may obey the spirit of virtual interrupt delivery - reducing VMExit.
> We have been evaluating that.

With which result?

Jan


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

From xen-devel-bounces@lists.xen.org Thu Sep 06 10:47:33 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 2012 10:47:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9ZcH-0007C9-8x; Thu, 06 Sep 2012 10:47: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 1T9ZcF-0007C3-Qy
	for xen-devel@lists.xen.org; Thu, 06 Sep 2012 10:47:20 +0000
Received: from [85.158.143.35:48110] by server-3.bemta-4.messagelabs.com id
	3B/78-08232-73F78405; Thu, 06 Sep 2012 10:47:19 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1346928437!13684151!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-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26464 invoked from network); 6 Sep 2012 10:47:18 -0000
Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com)
	(74.125.83.45)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Sep 2012 10:47:18 -0000
Received: by eeke53 with SMTP id e53so707397eek.32
	for <xen-devel@lists.xen.org>; Thu, 06 Sep 2012 03:47: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:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=0HFu8/C+jIjunicsu9zhOjSx0+yskcG9raCPS1Ur18A=;
	b=zz04Dfele25IKlFWJ03/jO5e+5agYqe/FbUz8xjkXcefNsM9NgXlUMKxKS/7xFiadS
	V39/aCicm/7b5WcoSBHInhyJvhSezdn7a0bsMWW7nDFwBGTkBWk0fAFTSQColmMyAT9Y
	b/FxC66Kpv8IMdqAhmzi5QQoMXJbvB6R7loeVhqUJMfoK0js96LSeDclCvYVCXVb5xC9
	NofvwtI+wDD0J6spfPL8zOJCbf6lYRR678al13b83EDgb86JkLifyp5XiDYMt/vXI/WA
	9Dq2j9Jm+1jWOoIXpp7bCy7u1N1PQz9XawcjImdQ0oNcl3qTXTB9ztb8JOYG0MPmOL5/
	Lszg==
Received: by 10.14.219.198 with SMTP id m46mr2207822eep.18.1346928437583;
	Thu, 06 Sep 2012 03:47:17 -0700 (PDT)
Received: from [192.168.1.3] (host86-184-74-117.range86-184.btcentralplus.com.
	[86.184.74.117])
	by mx.google.com with ESMTPS id k49sm4847701een.4.2012.09.06.03.47.15
	(version=SSLv3 cipher=OTHER); Thu, 06 Sep 2012 03:47:16 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.33.0.120411
Date: Thu, 06 Sep 2012 11:47:09 +0100
From: Keir Fraser <keir@xen.org>
To: "Li, Jiongxi" <jiongxi.li@intel.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Message-ID: <CC6E3DBD.4ADE4%keir@xen.org>
Thread-Topic: [Xen-devel] [ PATCH 2/2] xen: enable Virtual-interrupt delivery
Thread-Index: Ac2HWp7G2HqBx++QQP2kPrY5SPXyLgABHshJAPpQGPAANScdiA==
In-Reply-To: <D9137FCD9CFF644B965863BCFBEDABB877CBB8@SHSMSX101.ccr.corp.intel.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] [ PATCH 2/2] xen: enable Virtual-interrupt 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

On 06/09/2012 11:00, "Li, Jiongxi" <jiongxi.li@intel.com> wrote:

>>>  int hvm_local_events_need_delivery(struct vcpu *v) {
>>> -    struct hvm_intack intack = hvm_vcpu_has_pending_irq(v);
>>> +    struct hvm_intack intack;
>>> +
>>> +    pt_update_irq(v);
>> 
>> Why would this change be needed for vAPIC?
> When vcpu is scheduled out, there will be periodic timer interrupt pending for
> injection. Every VMExit is a chance to inject the pending periodic timer
> interrupt on vmx_intr_assist. In no virtual interrupt delivery case, although
> injected timer interrupt is edge trigger, EOI always induces VMExit, pending
> periodic timer can be kept injected till there is no pending left. But in
> virtual interrupt delivery case, only level trigger interrupt can induce
> VMExit, there is much less chance for injecting pending timer interrupt
> through VMExit. 
> Adding pt_update_irq here is another code path to inject pending periodic
> timer, but it can't guarantee every pending timer interrupt can be injected.
> Another way is to make every EOI of pending timer interrupt induce VMExit, but
> it may obey the spirit of virtual interrupt delivery - reducing VMExit.
> We have been evaluating that.

Should cause EOI to induce VMExit only when there is more periodic timer
work to be done? That would be better than this hack.

 -- Keir



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

From xen-devel-bounces@lists.xen.org Thu Sep 06 10:47:33 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 2012 10:47:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9ZcH-0007C9-8x; Thu, 06 Sep 2012 10:47: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 1T9ZcF-0007C3-Qy
	for xen-devel@lists.xen.org; Thu, 06 Sep 2012 10:47:20 +0000
Received: from [85.158.143.35:48110] by server-3.bemta-4.messagelabs.com id
	3B/78-08232-73F78405; Thu, 06 Sep 2012 10:47:19 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1346928437!13684151!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-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26464 invoked from network); 6 Sep 2012 10:47:18 -0000
Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com)
	(74.125.83.45)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Sep 2012 10:47:18 -0000
Received: by eeke53 with SMTP id e53so707397eek.32
	for <xen-devel@lists.xen.org>; Thu, 06 Sep 2012 03:47: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:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=0HFu8/C+jIjunicsu9zhOjSx0+yskcG9raCPS1Ur18A=;
	b=zz04Dfele25IKlFWJ03/jO5e+5agYqe/FbUz8xjkXcefNsM9NgXlUMKxKS/7xFiadS
	V39/aCicm/7b5WcoSBHInhyJvhSezdn7a0bsMWW7nDFwBGTkBWk0fAFTSQColmMyAT9Y
	b/FxC66Kpv8IMdqAhmzi5QQoMXJbvB6R7loeVhqUJMfoK0js96LSeDclCvYVCXVb5xC9
	NofvwtI+wDD0J6spfPL8zOJCbf6lYRR678al13b83EDgb86JkLifyp5XiDYMt/vXI/WA
	9Dq2j9Jm+1jWOoIXpp7bCy7u1N1PQz9XawcjImdQ0oNcl3qTXTB9ztb8JOYG0MPmOL5/
	Lszg==
Received: by 10.14.219.198 with SMTP id m46mr2207822eep.18.1346928437583;
	Thu, 06 Sep 2012 03:47:17 -0700 (PDT)
Received: from [192.168.1.3] (host86-184-74-117.range86-184.btcentralplus.com.
	[86.184.74.117])
	by mx.google.com with ESMTPS id k49sm4847701een.4.2012.09.06.03.47.15
	(version=SSLv3 cipher=OTHER); Thu, 06 Sep 2012 03:47:16 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.33.0.120411
Date: Thu, 06 Sep 2012 11:47:09 +0100
From: Keir Fraser <keir@xen.org>
To: "Li, Jiongxi" <jiongxi.li@intel.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Message-ID: <CC6E3DBD.4ADE4%keir@xen.org>
Thread-Topic: [Xen-devel] [ PATCH 2/2] xen: enable Virtual-interrupt delivery
Thread-Index: Ac2HWp7G2HqBx++QQP2kPrY5SPXyLgABHshJAPpQGPAANScdiA==
In-Reply-To: <D9137FCD9CFF644B965863BCFBEDABB877CBB8@SHSMSX101.ccr.corp.intel.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] [ PATCH 2/2] xen: enable Virtual-interrupt 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

On 06/09/2012 11:00, "Li, Jiongxi" <jiongxi.li@intel.com> wrote:

>>>  int hvm_local_events_need_delivery(struct vcpu *v) {
>>> -    struct hvm_intack intack = hvm_vcpu_has_pending_irq(v);
>>> +    struct hvm_intack intack;
>>> +
>>> +    pt_update_irq(v);
>> 
>> Why would this change be needed for vAPIC?
> When vcpu is scheduled out, there will be periodic timer interrupt pending for
> injection. Every VMExit is a chance to inject the pending periodic timer
> interrupt on vmx_intr_assist. In no virtual interrupt delivery case, although
> injected timer interrupt is edge trigger, EOI always induces VMExit, pending
> periodic timer can be kept injected till there is no pending left. But in
> virtual interrupt delivery case, only level trigger interrupt can induce
> VMExit, there is much less chance for injecting pending timer interrupt
> through VMExit. 
> Adding pt_update_irq here is another code path to inject pending periodic
> timer, but it can't guarantee every pending timer interrupt can be injected.
> Another way is to make every EOI of pending timer interrupt induce VMExit, but
> it may obey the spirit of virtual interrupt delivery - reducing VMExit.
> We have been evaluating that.

Should cause EOI to induce VMExit only when there is more periodic timer
work to be done? That would be better than this hack.

 -- Keir



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

From xen-devel-bounces@lists.xen.org Thu Sep 06 10:57:22 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 2012 10: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 1T9Zlk-0007hB-8J; Thu, 06 Sep 2012 10:57:08 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1T9Zli-0007gy-Mf
	for xen-devel@lists.xensource.com; Thu, 06 Sep 2012 10:57:06 +0000
Received: from [85.158.143.35:14540] by server-1.bemta-4.messagelabs.com id
	77/85-12504-18188405; Thu, 06 Sep 2012 10:57:05 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1346928994!11442364!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTE5NzY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27568 invoked from network); 6 Sep 2012 10:56:35 -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;
	6 Sep 2012 10:56:35 -0000
X-IronPort-AV: E=Sophos;i="4.80,380,1344211200"; d="scan'208";a="14382406"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Sep 2012 10:56: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.279.1; Thu, 6 Sep 2012 11:56:34 +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 1T9ZfN-0004ku-Mo;
	Thu, 06 Sep 2012 10:50:33 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1T9ZfN-0002xl-9D;
	Thu, 06 Sep 2012 11:50:33 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-13655-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 6 Sep 2012 11:50:33 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.1-testing test] 13655: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 13655 xen-4.1-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13655/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64-pvops             4 kernel-build     fail in 13651 REGR. vs. 13646

Tests which are failing intermittently (not blocking):
 test-amd64-i386-qemuu-rhel6hvm-amd  7 redhat-install        fail pass in 13651

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-pcipt-intel  8 debian-fixup                fail like 13646
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 13646

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-intel 11 leak-check/check       fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 13 guest-stop               fail never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 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-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 13 guest-stop             fail never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-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-amd64-amd64-xl-pcipt-intel  1 xen-build-check(1)     blocked in 13651 n/a
 test-amd64-amd64-xl-sedf-pin  1 xen-build-check(1)        blocked in 13651 n/a
 test-amd64-amd64-pv           1 xen-build-check(1)        blocked in 13651 n/a
 test-amd64-amd64-xl           1 xen-build-check(1)        blocked in 13651 n/a
 test-amd64-amd64-xl-sedf      1 xen-build-check(1)        blocked in 13651 n/a
 test-amd64-amd64-pair         1 xen-build-check(1)        blocked in 13651 n/a
 test-amd64-amd64-xl-qemuu-winxpsp3  1 xen-build-check(1)  blocked in 13651 n/a
 test-amd64-i386-qemuu-rhel6hvm-amd 11 leak-check/check fail in 13651 never pass
 test-amd64-amd64-xl-win7-amd64  1 xen-build-check(1)      blocked in 13651 n/a
 test-amd64-amd64-xl-qemuu-win7-amd64 1 xen-build-check(1) blocked in 13651 n/a
 test-amd64-amd64-win          1 xen-build-check(1)        blocked in 13651 n/a
 test-amd64-amd64-xl-win       1 xen-build-check(1)        blocked in 13651 n/a
 test-amd64-amd64-xl-winxpsp3  1 xen-build-check(1)        blocked in 13651 n/a

version targeted for testing:
 xen                  3e4782f17f5c
baseline version:
 xen                  d28a9ba889c0

------------------------------------------------------------
People who touched revisions under test:
  Ian Campbell <ian.campbell@citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Keir Fraser <keir@xen.org>
  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                                     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.

------------------------------------------------------------
changeset:   23353:3e4782f17f5c
tag:         tip
user:        Ian Jackson <Ian.Jackson@eu.citrix.com>
date:        Wed Sep 05 12:40:10 2012 +0100
    
    QEMU_TAG update (XSA-17 / CVE-2012-3515)
    
    
changeset:   23352:936f63ee4dad
user:        Ian Jackson <Ian.Jackson@eu.citrix.com>
date:        Wed Sep 05 12:29:56 2012 +0100
    
    x86/pvhvm: properly range-check PHYSDEVOP_map_pirq/MAP_PIRQ_TYPE_GSI
    
    This is being used as a array index, and hence must be validated before
    use.
    
    This is XSA-16 / CVE-2012-3498.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    
    
changeset:   23351:8ebda5388e4e
user:        Ian Jackson <Ian.Jackson@eu.citrix.com>
date:        Wed Sep 05 12:29:05 2012 +0100
    
    xen: Don't BUG_ON() PoD operations on a non-translated guest.
    
    This is XSA-14 / CVE-2012-3496
    
    Signed-off-by: Tim Deegan <tim@xen.org>
    Reviewed-by: Ian Campbell <ian.campbell@citrix.com>
    Tested-by: Ian Campbell <ian.campbell@citrix.com>
    
    
changeset:   23350:6779ddca8593
user:        Ian Jackson <Ian.Jackson@eu.citrix.com>
date:        Wed Sep 05 12:28:17 2012 +0100
    
    xen: handle out-of-pirq condition correctly in PHYSDEVOP_get_free_pirq
    
    This is XSA-13 / CVE-2012-3495
    
    Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
    Signed-off-by: Jan Beulich <JBeulich@suse.com>
    
    
changeset:   23349:bcc340292731
user:        Ian Jackson <Ian.Jackson@eu.citrix.com>
date:        Wed Sep 05 12:27:54 2012 +0100
    
    xen: prevent a 64 bit guest setting reserved bits in DR7
    
    The upper 32 bits of this register are reserved and should be written as
    zero.
    
    This is XSA-12 / CVE-2012-3494
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Reviewed-by: Ian Campbell <ian.campbell@citrix.com>
    
    
changeset:   23348:d28a9ba889c0
user:        Jan Beulich <jbeulich@suse.com>
date:        Tue Sep 04 14:56:48 2012 +0200
    
    make all (native) hypercalls consistently have "long" return type
    
    for common and x86 ones at least, to address the problem of storing
    zero-extended values into the multicall result field otherwise.
    
    Reported-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    xen-unstable changeset: 25744:47080c965937
    xen-unstable date: Fri Aug 10 07:51:01 UTC 2012
    
    
(qemu changes not included)

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

From xen-devel-bounces@lists.xen.org Thu Sep 06 10:57:22 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 2012 10: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 1T9Zlk-0007hB-8J; Thu, 06 Sep 2012 10:57:08 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1T9Zli-0007gy-Mf
	for xen-devel@lists.xensource.com; Thu, 06 Sep 2012 10:57:06 +0000
Received: from [85.158.143.35:14540] by server-1.bemta-4.messagelabs.com id
	77/85-12504-18188405; Thu, 06 Sep 2012 10:57:05 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1346928994!11442364!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTE5NzY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27568 invoked from network); 6 Sep 2012 10:56:35 -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;
	6 Sep 2012 10:56:35 -0000
X-IronPort-AV: E=Sophos;i="4.80,380,1344211200"; d="scan'208";a="14382406"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Sep 2012 10:56: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.279.1; Thu, 6 Sep 2012 11:56:34 +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 1T9ZfN-0004ku-Mo;
	Thu, 06 Sep 2012 10:50:33 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1T9ZfN-0002xl-9D;
	Thu, 06 Sep 2012 11:50:33 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-13655-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 6 Sep 2012 11:50:33 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.1-testing test] 13655: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 13655 xen-4.1-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13655/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64-pvops             4 kernel-build     fail in 13651 REGR. vs. 13646

Tests which are failing intermittently (not blocking):
 test-amd64-i386-qemuu-rhel6hvm-amd  7 redhat-install        fail pass in 13651

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-pcipt-intel  8 debian-fixup                fail like 13646
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 13646

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-intel 11 leak-check/check       fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 13 guest-stop               fail never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 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-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 13 guest-stop             fail never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-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-amd64-amd64-xl-pcipt-intel  1 xen-build-check(1)     blocked in 13651 n/a
 test-amd64-amd64-xl-sedf-pin  1 xen-build-check(1)        blocked in 13651 n/a
 test-amd64-amd64-pv           1 xen-build-check(1)        blocked in 13651 n/a
 test-amd64-amd64-xl           1 xen-build-check(1)        blocked in 13651 n/a
 test-amd64-amd64-xl-sedf      1 xen-build-check(1)        blocked in 13651 n/a
 test-amd64-amd64-pair         1 xen-build-check(1)        blocked in 13651 n/a
 test-amd64-amd64-xl-qemuu-winxpsp3  1 xen-build-check(1)  blocked in 13651 n/a
 test-amd64-i386-qemuu-rhel6hvm-amd 11 leak-check/check fail in 13651 never pass
 test-amd64-amd64-xl-win7-amd64  1 xen-build-check(1)      blocked in 13651 n/a
 test-amd64-amd64-xl-qemuu-win7-amd64 1 xen-build-check(1) blocked in 13651 n/a
 test-amd64-amd64-win          1 xen-build-check(1)        blocked in 13651 n/a
 test-amd64-amd64-xl-win       1 xen-build-check(1)        blocked in 13651 n/a
 test-amd64-amd64-xl-winxpsp3  1 xen-build-check(1)        blocked in 13651 n/a

version targeted for testing:
 xen                  3e4782f17f5c
baseline version:
 xen                  d28a9ba889c0

------------------------------------------------------------
People who touched revisions under test:
  Ian Campbell <ian.campbell@citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Keir Fraser <keir@xen.org>
  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                                     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.

------------------------------------------------------------
changeset:   23353:3e4782f17f5c
tag:         tip
user:        Ian Jackson <Ian.Jackson@eu.citrix.com>
date:        Wed Sep 05 12:40:10 2012 +0100
    
    QEMU_TAG update (XSA-17 / CVE-2012-3515)
    
    
changeset:   23352:936f63ee4dad
user:        Ian Jackson <Ian.Jackson@eu.citrix.com>
date:        Wed Sep 05 12:29:56 2012 +0100
    
    x86/pvhvm: properly range-check PHYSDEVOP_map_pirq/MAP_PIRQ_TYPE_GSI
    
    This is being used as a array index, and hence must be validated before
    use.
    
    This is XSA-16 / CVE-2012-3498.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    
    
changeset:   23351:8ebda5388e4e
user:        Ian Jackson <Ian.Jackson@eu.citrix.com>
date:        Wed Sep 05 12:29:05 2012 +0100
    
    xen: Don't BUG_ON() PoD operations on a non-translated guest.
    
    This is XSA-14 / CVE-2012-3496
    
    Signed-off-by: Tim Deegan <tim@xen.org>
    Reviewed-by: Ian Campbell <ian.campbell@citrix.com>
    Tested-by: Ian Campbell <ian.campbell@citrix.com>
    
    
changeset:   23350:6779ddca8593
user:        Ian Jackson <Ian.Jackson@eu.citrix.com>
date:        Wed Sep 05 12:28:17 2012 +0100
    
    xen: handle out-of-pirq condition correctly in PHYSDEVOP_get_free_pirq
    
    This is XSA-13 / CVE-2012-3495
    
    Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
    Signed-off-by: Jan Beulich <JBeulich@suse.com>
    
    
changeset:   23349:bcc340292731
user:        Ian Jackson <Ian.Jackson@eu.citrix.com>
date:        Wed Sep 05 12:27:54 2012 +0100
    
    xen: prevent a 64 bit guest setting reserved bits in DR7
    
    The upper 32 bits of this register are reserved and should be written as
    zero.
    
    This is XSA-12 / CVE-2012-3494
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Reviewed-by: Ian Campbell <ian.campbell@citrix.com>
    
    
changeset:   23348:d28a9ba889c0
user:        Jan Beulich <jbeulich@suse.com>
date:        Tue Sep 04 14:56:48 2012 +0200
    
    make all (native) hypercalls consistently have "long" return type
    
    for common and x86 ones at least, to address the problem of storing
    zero-extended values into the multicall result field otherwise.
    
    Reported-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    xen-unstable changeset: 25744:47080c965937
    xen-unstable date: Fri Aug 10 07:51:01 UTC 2012
    
    
(qemu changes not included)

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

From xen-devel-bounces@lists.xen.org Thu Sep 06 10:58:31 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 2012 10:58:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9Zmt-0007nl-Rg; Thu, 06 Sep 2012 10:58:19 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ketuzsezr@gmail.com>) id 1T9Zms-0007na-My
	for xen-devel@lists.xen.org; Thu, 06 Sep 2012 10:58:18 +0000
Received: from [85.158.143.99:4555] by server-3.bemta-4.messagelabs.com id
	41/8F-08232-AC188405; Thu, 06 Sep 2012 10:58:18 +0000
X-Env-Sender: ketuzsezr@gmail.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1346929096!28536427!1
X-Originating-IP: [209.85.212.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19085 invoked from network); 6 Sep 2012 10:58:17 -0000
Received: from mail-vb0-f45.google.com (HELO mail-vb0-f45.google.com)
	(209.85.212.45)
	by server-5.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Sep 2012 10:58:17 -0000
Received: by vbip1 with SMTP id p1so1520002vbi.32
	for <xen-devel@lists.xen.org>; Thu, 06 Sep 2012 03:58:16 -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=EfOcJCu4ZCw4jQQE5yvCmlqalkwSjzXr/Br14axod24=;
	b=i0j+zTJWFKKp0caJs74G7qmLHqIglAlUfQQ88jfn9/ear11LPPTtBS5ZdisnxaZPOj
	lRjHbrBeGSoVw8CRPuEz5s0h4jjr9EMLE275oJ65rTziIPfgePiubL4rnKJjaFVP9TVY
	OMKWQWZGteP0KHpoa4E/zrFnXsln+5xymGKDz/TwIl4BXHypsWIqKmwFpOYGI2Dh7zic
	/ZUury4G3egjke+G4CAB2D6f0PnKhZM03jVC88I5afhHz6HKigGWd4DieG9dB5FRwlRh
	FR/H2qA0C/Y4nFtO1iB8bBaofCnTWIvV20J+8+VSj+PXP1cc5a16E7MZRgh/pzy75dLv
	mC1A==
Received: by 10.220.223.201 with SMTP id il9mr1445686vcb.64.1346929095972;
	Thu, 06 Sep 2012 03:58:15 -0700 (PDT)
Received: from phenom.dumpdata.com
	(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 v9sm941618ves.8.2012.09.06.03.58.14
	(version=TLSv1/SSLv3 cipher=OTHER);
	Thu, 06 Sep 2012 03:58:15 -0700 (PDT)
Date: Thu, 6 Sep 2012 06:47:41 -0400
From: Konrad Rzeszutek Wilk <konrad@kernel.org>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>, Oliver.Chick@citrix.com
Message-ID: <20120906104740.GA3744@phenom.dumpdata.com>
References: <20120905132920.GA5792@localhost.localdomain>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120905132920.GA5792@localhost.localdomain>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: justing@spectralogic.com, ronghui.duan@intel.com, JBeulich@suse.com,
	donald.d.dugger@intel.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Block ring protocol (segment expansion, multi-page,
 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 Wed, Sep 05, 2012 at 09:29:21AM -0400, Konrad Rzeszutek Wilk wrote:
> Please correct me if I a got something wrong.

CC-ing here a Citrix person who has expressed interest in also
implementing persistent grants in block backend.
> 
> About two or three years ago Citrix (and Red Hat I think?) posted a
> multi-page extension protocol (max-ring-page-order, max-ring-pages
> and ring-page-order and ring-pages)-
> which never got upstream (needed just to be rebased on the driver that
> went in the kernel I think?).
> 
> Then about a year ago SpectraLogic started enhancing the FreeBSD variant
> of blkback - and realized what Ronghui also did - that the just doing a
> multi-page extension is not enough. The issue was that if one just
> expanded to a ring composed of two pages, 1/4 of the page was wasted b/c
> of the segment is constrained to 11.
> 
> Justin (SpectraLogic) came up with a protocol enh were the existing
> blkif protocol is the same, but the BLKIF_MAX_SEGMENTS_PER_REQUEST
> is negotitated via max-request-segments. And then there is the
> max-request-size which rolls the segment size and the size of the ring
> to give you an idea of what is the biggest I/O you can fit on a ring in
> a single transaction. This solves the wastage problem and expands the
> ring.
> 
> Ronghui did something similar, but instead of re-using the existing
> blkif structure he split them in two. One ring is for
> blkif_request_header (which has the segments ripped out), and the other
> is for just for blkif_request_segments. Solves the wastage and also
> allows to expand the ring.
> 
> The three major outstanding issues that exists with the current protocol
> that I know of are:
>  - We split up the I/O requests. This ends up eating a lot of CPU
>    cycles.
>  - We might have huge I/O requests. Justin mentioned 1MB single I/Os -
>    and to fit that on a ring it has to be .. well, be able to fit 256
>    segments. Jan mentioned 256kB for SCSI - since the protocol
>    extensions here could very well be carried over.
>  - concurrent usage. If we have more than 4 VBDs blkback suffers when it
>    tries to get a page as there is a "global" pool shared across all
>    guests instead of being something 'per guest' or 'per VBD'.
> 
> So.. Ronghui - I am curious to why you choosen the path of making two
> seperate rings? Was the mechanism that Justin came up not really that
> good or was this just easier to implement?
> 
> Thanks.
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Sep 06 10:58:31 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 2012 10:58:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9Zmt-0007nl-Rg; Thu, 06 Sep 2012 10:58:19 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ketuzsezr@gmail.com>) id 1T9Zms-0007na-My
	for xen-devel@lists.xen.org; Thu, 06 Sep 2012 10:58:18 +0000
Received: from [85.158.143.99:4555] by server-3.bemta-4.messagelabs.com id
	41/8F-08232-AC188405; Thu, 06 Sep 2012 10:58:18 +0000
X-Env-Sender: ketuzsezr@gmail.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1346929096!28536427!1
X-Originating-IP: [209.85.212.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19085 invoked from network); 6 Sep 2012 10:58:17 -0000
Received: from mail-vb0-f45.google.com (HELO mail-vb0-f45.google.com)
	(209.85.212.45)
	by server-5.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Sep 2012 10:58:17 -0000
Received: by vbip1 with SMTP id p1so1520002vbi.32
	for <xen-devel@lists.xen.org>; Thu, 06 Sep 2012 03:58:16 -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=EfOcJCu4ZCw4jQQE5yvCmlqalkwSjzXr/Br14axod24=;
	b=i0j+zTJWFKKp0caJs74G7qmLHqIglAlUfQQ88jfn9/ear11LPPTtBS5ZdisnxaZPOj
	lRjHbrBeGSoVw8CRPuEz5s0h4jjr9EMLE275oJ65rTziIPfgePiubL4rnKJjaFVP9TVY
	OMKWQWZGteP0KHpoa4E/zrFnXsln+5xymGKDz/TwIl4BXHypsWIqKmwFpOYGI2Dh7zic
	/ZUury4G3egjke+G4CAB2D6f0PnKhZM03jVC88I5afhHz6HKigGWd4DieG9dB5FRwlRh
	FR/H2qA0C/Y4nFtO1iB8bBaofCnTWIvV20J+8+VSj+PXP1cc5a16E7MZRgh/pzy75dLv
	mC1A==
Received: by 10.220.223.201 with SMTP id il9mr1445686vcb.64.1346929095972;
	Thu, 06 Sep 2012 03:58:15 -0700 (PDT)
Received: from phenom.dumpdata.com
	(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 v9sm941618ves.8.2012.09.06.03.58.14
	(version=TLSv1/SSLv3 cipher=OTHER);
	Thu, 06 Sep 2012 03:58:15 -0700 (PDT)
Date: Thu, 6 Sep 2012 06:47:41 -0400
From: Konrad Rzeszutek Wilk <konrad@kernel.org>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>, Oliver.Chick@citrix.com
Message-ID: <20120906104740.GA3744@phenom.dumpdata.com>
References: <20120905132920.GA5792@localhost.localdomain>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120905132920.GA5792@localhost.localdomain>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: justing@spectralogic.com, ronghui.duan@intel.com, JBeulich@suse.com,
	donald.d.dugger@intel.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Block ring protocol (segment expansion, multi-page,
 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 Wed, Sep 05, 2012 at 09:29:21AM -0400, Konrad Rzeszutek Wilk wrote:
> Please correct me if I a got something wrong.

CC-ing here a Citrix person who has expressed interest in also
implementing persistent grants in block backend.
> 
> About two or three years ago Citrix (and Red Hat I think?) posted a
> multi-page extension protocol (max-ring-page-order, max-ring-pages
> and ring-page-order and ring-pages)-
> which never got upstream (needed just to be rebased on the driver that
> went in the kernel I think?).
> 
> Then about a year ago SpectraLogic started enhancing the FreeBSD variant
> of blkback - and realized what Ronghui also did - that the just doing a
> multi-page extension is not enough. The issue was that if one just
> expanded to a ring composed of two pages, 1/4 of the page was wasted b/c
> of the segment is constrained to 11.
> 
> Justin (SpectraLogic) came up with a protocol enh were the existing
> blkif protocol is the same, but the BLKIF_MAX_SEGMENTS_PER_REQUEST
> is negotitated via max-request-segments. And then there is the
> max-request-size which rolls the segment size and the size of the ring
> to give you an idea of what is the biggest I/O you can fit on a ring in
> a single transaction. This solves the wastage problem and expands the
> ring.
> 
> Ronghui did something similar, but instead of re-using the existing
> blkif structure he split them in two. One ring is for
> blkif_request_header (which has the segments ripped out), and the other
> is for just for blkif_request_segments. Solves the wastage and also
> allows to expand the ring.
> 
> The three major outstanding issues that exists with the current protocol
> that I know of are:
>  - We split up the I/O requests. This ends up eating a lot of CPU
>    cycles.
>  - We might have huge I/O requests. Justin mentioned 1MB single I/Os -
>    and to fit that on a ring it has to be .. well, be able to fit 256
>    segments. Jan mentioned 256kB for SCSI - since the protocol
>    extensions here could very well be carried over.
>  - concurrent usage. If we have more than 4 VBDs blkback suffers when it
>    tries to get a page as there is a "global" pool shared across all
>    guests instead of being something 'per guest' or 'per VBD'.
> 
> So.. Ronghui - I am curious to why you choosen the path of making two
> seperate rings? Was the mechanism that Justin came up not really that
> good or was this just easier to implement?
> 
> Thanks.
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Sep 06 11:02:10 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 2012 11:02:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9ZqO-000856-G3; Thu, 06 Sep 2012 11:01:56 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1T9ZqM-00084y-8y
	for xen-devel@lists.xen.org; Thu, 06 Sep 2012 11:01:54 +0000
Received: from [85.158.143.35:10068] by server-2.bemta-4.messagelabs.com id
	0B/EF-21239-1A288405; Thu, 06 Sep 2012 11:01:53 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1346929272!16959364!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM5ODQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22587 invoked from network); 6 Sep 2012 11:01:22 -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;
	6 Sep 2012 11:01:22 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 06 Sep 2012 12:01:13 +0100
Message-Id: <50489ECF020000780009944C@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 06 Sep 2012 12:02:07 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>
References: <20120905132920.GA5792@localhost.localdomain>
In-Reply-To: <20120905132920.GA5792@localhost.localdomain>
Mime-Version: 1.0
Content-Disposition: inline
Cc: justing@spectralogic.com, ronghui.duan@intel.com, donald.d.dugger@intel.com,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Block ring protocol (segment expansion, multi-page,
	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 05.09.12 at 15:29, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
> The three major outstanding issues that exists with the current protocol
> that I know of are:
>  - We split up the I/O requests. This ends up eating a lot of CPU
>    cycles.
>  - We might have huge I/O requests. Justin mentioned 1MB single I/Os -
>    and to fit that on a ring it has to be .. well, be able to fit 256
>    segments. Jan mentioned 256kB for SCSI - since the protocol
>    extensions here could very well be carried over.

This one is at least partly solved with the higher segment count.
With Justin's scheme, up to 255 segments (i.e. slightly less than
1Mb) can be transferred at a time. With Ronghui's scheme (and
provided the segment count is wider than a byte), there shouldn't
be any really limiting upper bound anymore.

>  - concurrent usage. If we have more than 4 VBDs blkback suffers when it
>    tries to get a page as there is a "global" pool shared across all
>    guests instead of being something 'per guest' or 'per VBD'.

Per-vbd would be what we currently have, where for little used
vbd-s a pointlessly large amount of pages is set aside. Per-guest
is what I think it needs to be (to prevent multiple guests from
starving one another).

But then it's also not just the page pool, but also the number
of grants used/mapped - without command line override there's
32 map track frames, allowing 32k grants to be mapped in a
single domain (e.g. Dom0). Scaling the larger segment and
request counts with the number of guests and considering that
other backends also need to be able to do their jobs, this could
become a noticeable limit quite quickly (especially considering
that failed grant map operations fail the request in the backend
rather than deferring it, at least when GNTST_no_device_space
gets returned).

Jan


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

From xen-devel-bounces@lists.xen.org Thu Sep 06 11:02:10 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 2012 11:02:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9ZqO-000856-G3; Thu, 06 Sep 2012 11:01:56 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1T9ZqM-00084y-8y
	for xen-devel@lists.xen.org; Thu, 06 Sep 2012 11:01:54 +0000
Received: from [85.158.143.35:10068] by server-2.bemta-4.messagelabs.com id
	0B/EF-21239-1A288405; Thu, 06 Sep 2012 11:01:53 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1346929272!16959364!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM5ODQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22587 invoked from network); 6 Sep 2012 11:01:22 -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;
	6 Sep 2012 11:01:22 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 06 Sep 2012 12:01:13 +0100
Message-Id: <50489ECF020000780009944C@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 06 Sep 2012 12:02:07 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>
References: <20120905132920.GA5792@localhost.localdomain>
In-Reply-To: <20120905132920.GA5792@localhost.localdomain>
Mime-Version: 1.0
Content-Disposition: inline
Cc: justing@spectralogic.com, ronghui.duan@intel.com, donald.d.dugger@intel.com,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Block ring protocol (segment expansion, multi-page,
	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 05.09.12 at 15:29, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
> The three major outstanding issues that exists with the current protocol
> that I know of are:
>  - We split up the I/O requests. This ends up eating a lot of CPU
>    cycles.
>  - We might have huge I/O requests. Justin mentioned 1MB single I/Os -
>    and to fit that on a ring it has to be .. well, be able to fit 256
>    segments. Jan mentioned 256kB for SCSI - since the protocol
>    extensions here could very well be carried over.

This one is at least partly solved with the higher segment count.
With Justin's scheme, up to 255 segments (i.e. slightly less than
1Mb) can be transferred at a time. With Ronghui's scheme (and
provided the segment count is wider than a byte), there shouldn't
be any really limiting upper bound anymore.

>  - concurrent usage. If we have more than 4 VBDs blkback suffers when it
>    tries to get a page as there is a "global" pool shared across all
>    guests instead of being something 'per guest' or 'per VBD'.

Per-vbd would be what we currently have, where for little used
vbd-s a pointlessly large amount of pages is set aside. Per-guest
is what I think it needs to be (to prevent multiple guests from
starving one another).

But then it's also not just the page pool, but also the number
of grants used/mapped - without command line override there's
32 map track frames, allowing 32k grants to be mapped in a
single domain (e.g. Dom0). Scaling the larger segment and
request counts with the number of guests and considering that
other backends also need to be able to do their jobs, this could
become a noticeable limit quite quickly (especially considering
that failed grant map operations fail the request in the backend
rather than deferring it, at least when GNTST_no_device_space
gets returned).

Jan


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

From xen-devel-bounces@lists.xen.org Thu Sep 06 11:04:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 2012 11:04:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9ZsM-0008H4-Lt; Thu, 06 Sep 2012 11:03:58 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Christoph.Egger@amd.com>) id 1T9ZsK-0008Gh-Nc
	for xen-devel@lists.xen.org; Thu, 06 Sep 2012 11:03:57 +0000
Received: from [85.158.143.99:22865] by server-1.bemta-4.messagelabs.com id
	E9/54-12504-C1388405; Thu, 06 Sep 2012 11:03:56 +0000
X-Env-Sender: Christoph.Egger@amd.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1346929434!28298652!1
X-Originating-IP: [216.32.181.181]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4960 invoked from network); 6 Sep 2012 11:03:55 -0000
Received: from ch1ehsobe001.messaging.microsoft.com (HELO
	ch1outboundpool.messaging.microsoft.com) (216.32.181.181)
	by server-3.tower-216.messagelabs.com with AES128-SHA encrypted SMTP;
	6 Sep 2012 11:03:55 -0000
Received: from mail180-ch1-R.bigfish.com (10.43.68.250) by
	CH1EHSOBE010.bigfish.com (10.43.70.60) with Microsoft SMTP Server id
	14.1.225.23; Thu, 6 Sep 2012 11:03:54 +0000
Received: from mail180-ch1 (localhost [127.0.0.1])	by
	mail180-ch1-R.bigfish.com (Postfix) with ESMTP id F392540033D;
	Thu,  6 Sep 2012 11:03:53 +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(zzbb2dI98dI1432Izz1202hzz8275bhz2dh668h839he5bhf0ah107ah1155h)
Received: from mail180-ch1 (localhost.localdomain [127.0.0.1]) by mail180-ch1
	(MessageSwitch) id 1346929432206066_32445;
	Thu,  6 Sep 2012 11:03:52 +0000 (UTC)
Received: from CH1EHSMHS021.bigfish.com (snatpool3.int.messaging.microsoft.com
	[10.43.68.226])	by mail180-ch1.bigfish.com (Postfix) with ESMTP id
	2E8382C0042;	Thu,  6 Sep 2012 11:03:52 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	CH1EHSMHS021.bigfish.com (10.43.70.21) with Microsoft SMTP Server id
	14.1.225.23; Thu, 6 Sep 2012 11:03:51 +0000
X-WSS-ID: 0M9XDE9-02-7R3-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 2475FC80CD;	Thu,  6 Sep 2012 06:03:45 -0500 (CDT)
Received: from sausexhtp02.amd.com (163.181.3.152) by sausexedgep02.amd.com
	(163.181.36.59) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Thu, 6 Sep 2012 06:04:04 -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;
	Thu, 6 Sep 2012 06:03:48 -0500
Received: from rhodium.osrc.amd.com (165.204.15.173) by storexhtp02.amd.com
	(172.24.4.4) with Microsoft SMTP Server id 8.3.213.0; Thu, 6 Sep 2012
	07:03:47 -0400
Message-ID: <50488311.7020702@amd.com>
Date: Thu, 6 Sep 2012 13:03:45 +0200
From: Christoph Egger <Christoph.Egger@amd.com>
User-Agent: Mozilla/5.0 (X11; NetBSD amd64;
	rv:11.0) Gecko/20120404 Thunderbird/11.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <D9137FCD9CFF644B965863BCFBEDABB8779942@SHSMSX101.ccr.corp.intel.com>
	<5040CAB30200007800097D73@nat28.tlf.novell.com>
	<D9137FCD9CFF644B965863BCFBEDABB877CBBD@SHSMSX101.ccr.corp.intel.com>
	<504898870200007800099427@nat28.tlf.novell.com>
In-Reply-To: <504898870200007800099427@nat28.tlf.novell.com>
X-OriginatorOrg: amd.com
Cc: Jiongxi Li <jiongxi.li@intel.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [ PATCH 2/2] xen: enable Virtual-interrupt 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

On 09/06/12 12:35, Jan Beulich wrote:

>>>> On 06.09.12 at 12:00, "Li, Jiongxi" <jiongxi.li@intel.com> wrote:
>>>> +/*
>>>> + * When "Virtual Interrupt Delivery" is enabled, this function is
>>>> +used
>>>> + * to handle EOI-induced VM exit
>>>> + */
>>>> +void vlapic_handle_EOI_induced_exit(struct vlapic *vlapic, int
>>>> +vector) {
>>>> +    ASSERT(cpu_has_vmx_virtual_intr_delivery);
>>>> +
>>>> +    if ( vlapic_test_and_clear_vector(vector,
>>>> + &vlapic->regs->data[APIC_TMR]) )
>>>
>>> Why test_and_clear rather than just test?
>> While virtual interrupt delivery is enabled, 'vlapic_EOI_set' function won't 
>> be called( 'vlapic_EOI_set' also has the test and clear call). ' 
> 
> Ah, okay.
> 
>>>> --- a/xen/arch/x86/hvm/vmx/intr.c Fri Aug 31 09:30:38 2012 +0800
>>>> +++ b/xen/arch/x86/hvm/vmx/intr.c       Fri Aug 31 09:49:39 2012 +0800
>>>> @@ -227,19 +227,43 @@ void vmx_intr_assist(void)
>>>>              goto out;
>>>>
>>>>          intblk = hvm_interrupt_blocked(v, intack);
>>>> -        if ( intblk == hvm_intblk_tpr )
>>>> +        if ( cpu_has_vmx_virtual_intr_delivery )
>>>>          {
>>>> -            ASSERT(vlapic_enabled(vcpu_vlapic(v)));
>>>> -            ASSERT(intack.source == hvm_intsrc_lapic);
>>>> -            tpr_threshold = intack.vector >> 4;
>>>> -            goto out;
>>>> +            /* Set "Interrupt-window exiting" for ExtINT */
>>>> +            if ( (intblk != hvm_intblk_none) &&
>>>> +                 ( (intack.source == hvm_intsrc_pic) ||
>>>> +                 ( intack.source == hvm_intsrc_vector) ) )
>>>> +            {
>>>> +                enable_intr_window(v, intack);
>>>> +                goto out;
>>>> +            }
>>>> +
>>>> +            if ( __vmread(VM_ENTRY_INTR_INFO) &
>>> INTR_INFO_VALID_MASK )
>>>> +            {
>>>> +                if ( (intack.source == hvm_intsrc_pic) ||
>>>> +                     (intack.source == hvm_intsrc_nmi) ||
>>>> +                     (intack.source == hvm_intsrc_mce) )
>>>> +                    enable_intr_window(v, intack);
>>>> +
>>>> +                goto out;
>>>> +            }
>>>>          }
>>>> +        else
>>>> +        {
>>>> +            if ( intblk == hvm_intblk_tpr )
>>>> +            {
>>>> +                ASSERT(vlapic_enabled(vcpu_vlapic(v)));
>>>> +                ASSERT(intack.source == hvm_intsrc_lapic);
>>>> +                tpr_threshold = intack.vector >> 4;
>>>> +                goto out;
>>>> +            }
>>>>
>>>> -        if ( (intblk != hvm_intblk_none) ||
>>>> -             (__vmread(VM_ENTRY_INTR_INFO) &
>>> INTR_INFO_VALID_MASK) )
>>>> -        {
>>>> -            enable_intr_window(v, intack);
>>>> -            goto out;
>>>> +            if ( (intblk != hvm_intblk_none) ||
>>>> +                 (__vmread(VM_ENTRY_INTR_INFO) &
>>> INTR_INFO_VALID_MASK) )
>>>> +            {
>>>> +                enable_intr_window(v, intack);
>>>> +                goto out;
>>>> +            }
>>>>          }
>>>
>>> If you made the above and if()/else if() series, some of the differences 
>> would go
>>> away, making the changes easier to review.
>> I can't quite understand you here.
>> The original code looked like:
>> if (a)
>> {}
>> if (b)
>> {}
>> And my change as follow:
>> if ( cpu_has_vmx_virtual_intr_delivery )
>> {
>> }
>> else
>> {
>>   if (a)
>>   {}
>>   if (b)
>>   {}
>> }
>> How should I adjust the code?
> 
> Considering that the original could already have been written
> with if/else-if, I was suggesting to expand this to your addition:
> 
> if ( cpu_has_vmx_virtual_intr_delivery )
> {
> }
> else if (a)
>   {}
> else if (b)
>   {}


I think, move the VMX part into hvm/vmx/* and call a function pointer
from common code. Having VMX or SVM specific code in common code
is broken by design.

Christoph

-- 

---to satisfy European Law for business letters:
Advanced Micro Devices GmbH
Einsteinring 24, 85689 Dornach b. Muenchen
Geschaeftsfuehrer: Alberto Bozzo
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 Thu Sep 06 11:04:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 2012 11:04:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9ZsM-0008H4-Lt; Thu, 06 Sep 2012 11:03:58 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Christoph.Egger@amd.com>) id 1T9ZsK-0008Gh-Nc
	for xen-devel@lists.xen.org; Thu, 06 Sep 2012 11:03:57 +0000
Received: from [85.158.143.99:22865] by server-1.bemta-4.messagelabs.com id
	E9/54-12504-C1388405; Thu, 06 Sep 2012 11:03:56 +0000
X-Env-Sender: Christoph.Egger@amd.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1346929434!28298652!1
X-Originating-IP: [216.32.181.181]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4960 invoked from network); 6 Sep 2012 11:03:55 -0000
Received: from ch1ehsobe001.messaging.microsoft.com (HELO
	ch1outboundpool.messaging.microsoft.com) (216.32.181.181)
	by server-3.tower-216.messagelabs.com with AES128-SHA encrypted SMTP;
	6 Sep 2012 11:03:55 -0000
Received: from mail180-ch1-R.bigfish.com (10.43.68.250) by
	CH1EHSOBE010.bigfish.com (10.43.70.60) with Microsoft SMTP Server id
	14.1.225.23; Thu, 6 Sep 2012 11:03:54 +0000
Received: from mail180-ch1 (localhost [127.0.0.1])	by
	mail180-ch1-R.bigfish.com (Postfix) with ESMTP id F392540033D;
	Thu,  6 Sep 2012 11:03:53 +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(zzbb2dI98dI1432Izz1202hzz8275bhz2dh668h839he5bhf0ah107ah1155h)
Received: from mail180-ch1 (localhost.localdomain [127.0.0.1]) by mail180-ch1
	(MessageSwitch) id 1346929432206066_32445;
	Thu,  6 Sep 2012 11:03:52 +0000 (UTC)
Received: from CH1EHSMHS021.bigfish.com (snatpool3.int.messaging.microsoft.com
	[10.43.68.226])	by mail180-ch1.bigfish.com (Postfix) with ESMTP id
	2E8382C0042;	Thu,  6 Sep 2012 11:03:52 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	CH1EHSMHS021.bigfish.com (10.43.70.21) with Microsoft SMTP Server id
	14.1.225.23; Thu, 6 Sep 2012 11:03:51 +0000
X-WSS-ID: 0M9XDE9-02-7R3-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 2475FC80CD;	Thu,  6 Sep 2012 06:03:45 -0500 (CDT)
Received: from sausexhtp02.amd.com (163.181.3.152) by sausexedgep02.amd.com
	(163.181.36.59) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Thu, 6 Sep 2012 06:04:04 -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;
	Thu, 6 Sep 2012 06:03:48 -0500
Received: from rhodium.osrc.amd.com (165.204.15.173) by storexhtp02.amd.com
	(172.24.4.4) with Microsoft SMTP Server id 8.3.213.0; Thu, 6 Sep 2012
	07:03:47 -0400
Message-ID: <50488311.7020702@amd.com>
Date: Thu, 6 Sep 2012 13:03:45 +0200
From: Christoph Egger <Christoph.Egger@amd.com>
User-Agent: Mozilla/5.0 (X11; NetBSD amd64;
	rv:11.0) Gecko/20120404 Thunderbird/11.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <D9137FCD9CFF644B965863BCFBEDABB8779942@SHSMSX101.ccr.corp.intel.com>
	<5040CAB30200007800097D73@nat28.tlf.novell.com>
	<D9137FCD9CFF644B965863BCFBEDABB877CBBD@SHSMSX101.ccr.corp.intel.com>
	<504898870200007800099427@nat28.tlf.novell.com>
In-Reply-To: <504898870200007800099427@nat28.tlf.novell.com>
X-OriginatorOrg: amd.com
Cc: Jiongxi Li <jiongxi.li@intel.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [ PATCH 2/2] xen: enable Virtual-interrupt 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

On 09/06/12 12:35, Jan Beulich wrote:

>>>> On 06.09.12 at 12:00, "Li, Jiongxi" <jiongxi.li@intel.com> wrote:
>>>> +/*
>>>> + * When "Virtual Interrupt Delivery" is enabled, this function is
>>>> +used
>>>> + * to handle EOI-induced VM exit
>>>> + */
>>>> +void vlapic_handle_EOI_induced_exit(struct vlapic *vlapic, int
>>>> +vector) {
>>>> +    ASSERT(cpu_has_vmx_virtual_intr_delivery);
>>>> +
>>>> +    if ( vlapic_test_and_clear_vector(vector,
>>>> + &vlapic->regs->data[APIC_TMR]) )
>>>
>>> Why test_and_clear rather than just test?
>> While virtual interrupt delivery is enabled, 'vlapic_EOI_set' function won't 
>> be called( 'vlapic_EOI_set' also has the test and clear call). ' 
> 
> Ah, okay.
> 
>>>> --- a/xen/arch/x86/hvm/vmx/intr.c Fri Aug 31 09:30:38 2012 +0800
>>>> +++ b/xen/arch/x86/hvm/vmx/intr.c       Fri Aug 31 09:49:39 2012 +0800
>>>> @@ -227,19 +227,43 @@ void vmx_intr_assist(void)
>>>>              goto out;
>>>>
>>>>          intblk = hvm_interrupt_blocked(v, intack);
>>>> -        if ( intblk == hvm_intblk_tpr )
>>>> +        if ( cpu_has_vmx_virtual_intr_delivery )
>>>>          {
>>>> -            ASSERT(vlapic_enabled(vcpu_vlapic(v)));
>>>> -            ASSERT(intack.source == hvm_intsrc_lapic);
>>>> -            tpr_threshold = intack.vector >> 4;
>>>> -            goto out;
>>>> +            /* Set "Interrupt-window exiting" for ExtINT */
>>>> +            if ( (intblk != hvm_intblk_none) &&
>>>> +                 ( (intack.source == hvm_intsrc_pic) ||
>>>> +                 ( intack.source == hvm_intsrc_vector) ) )
>>>> +            {
>>>> +                enable_intr_window(v, intack);
>>>> +                goto out;
>>>> +            }
>>>> +
>>>> +            if ( __vmread(VM_ENTRY_INTR_INFO) &
>>> INTR_INFO_VALID_MASK )
>>>> +            {
>>>> +                if ( (intack.source == hvm_intsrc_pic) ||
>>>> +                     (intack.source == hvm_intsrc_nmi) ||
>>>> +                     (intack.source == hvm_intsrc_mce) )
>>>> +                    enable_intr_window(v, intack);
>>>> +
>>>> +                goto out;
>>>> +            }
>>>>          }
>>>> +        else
>>>> +        {
>>>> +            if ( intblk == hvm_intblk_tpr )
>>>> +            {
>>>> +                ASSERT(vlapic_enabled(vcpu_vlapic(v)));
>>>> +                ASSERT(intack.source == hvm_intsrc_lapic);
>>>> +                tpr_threshold = intack.vector >> 4;
>>>> +                goto out;
>>>> +            }
>>>>
>>>> -        if ( (intblk != hvm_intblk_none) ||
>>>> -             (__vmread(VM_ENTRY_INTR_INFO) &
>>> INTR_INFO_VALID_MASK) )
>>>> -        {
>>>> -            enable_intr_window(v, intack);
>>>> -            goto out;
>>>> +            if ( (intblk != hvm_intblk_none) ||
>>>> +                 (__vmread(VM_ENTRY_INTR_INFO) &
>>> INTR_INFO_VALID_MASK) )
>>>> +            {
>>>> +                enable_intr_window(v, intack);
>>>> +                goto out;
>>>> +            }
>>>>          }
>>>
>>> If you made the above and if()/else if() series, some of the differences 
>> would go
>>> away, making the changes easier to review.
>> I can't quite understand you here.
>> The original code looked like:
>> if (a)
>> {}
>> if (b)
>> {}
>> And my change as follow:
>> if ( cpu_has_vmx_virtual_intr_delivery )
>> {
>> }
>> else
>> {
>>   if (a)
>>   {}
>>   if (b)
>>   {}
>> }
>> How should I adjust the code?
> 
> Considering that the original could already have been written
> with if/else-if, I was suggesting to expand this to your addition:
> 
> if ( cpu_has_vmx_virtual_intr_delivery )
> {
> }
> else if (a)
>   {}
> else if (b)
>   {}


I think, move the VMX part into hvm/vmx/* and call a function pointer
from common code. Having VMX or SVM specific code in common code
is broken by design.

Christoph

-- 

---to satisfy European Law for business letters:
Advanced Micro Devices GmbH
Einsteinring 24, 85689 Dornach b. Muenchen
Geschaeftsfuehrer: Alberto Bozzo
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 Thu Sep 06 11:09:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 2012 11: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 1T9Zx6-0000EF-D8; Thu, 06 Sep 2012 11:08:52 +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 1T9Zx4-0000Dv-NF
	for xen-devel@lists.xen.org; Thu, 06 Sep 2012 11:08:50 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1346929708!8434302!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDc0MTc4NQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5579 invoked from network); 6 Sep 2012 11:08:29 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-16.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 6 Sep 2012 11:08: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 q86B8K3R015818
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 6 Sep 2012 11:08:21 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q86B8IFE007358
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 6 Sep 2012 11:08:19 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
	q86B8I5D017408; Thu, 6 Sep 2012 06:08:18 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 06 Sep 2012 04:08:18 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 24EDB402E4; Thu,  6 Sep 2012 06:57:46 -0400 (EDT)
Date: Thu, 6 Sep 2012 06:57:46 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Sander Eikelenboom <linux@eikelenboom.it>
Message-ID: <20120906105746.GA3668@phenom.dumpdata.com>
References: <1136369816.20120904183757@eikelenboom.it>
	<20120904163347.GH23361@phenom.dumpdata.com>
	<143844933.20120904191941@eikelenboom.it>
	<CAOvdn6U_yHgtZwv9MWazdLbd3NLq3pwGXnZY5sL2UVBhV_FUoQ@mail.gmail.com>
	<1813712325.20120904213459@eikelenboom.it>
	<048EAD622912254A9DEA24C1734613C18C864C3C5D@FTLPMAILBOX02.citrite.net>
	<20120905140600.GA5844@phenom.dumpdata.com>
	<1014998302.20120905163848@eikelenboom.it>
	<20120905201933.GA27814@phenom.dumpdata.com>
	<679529047.20120906005220@eikelenboom.it>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <679529047.20120906005220@eikelenboom.it>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: Robert Phillips <robert.phillips@citrix.com>, Ben Guthro <ben@guthro.net>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] dom0 linux 3.6.0-rc4,
 crash due to ballooning althoug dom0_mem=X, max:X 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

> > About nine of them deal with dom0_mem=max ballooning up right, so if you
> > ignore those:
> 
> > b9e0d95 xen: mark local pages as FOREIGN in the m2p_override
> > d79d595 xen: Add selfballoning memory reservation tunable.
> > f62805f xen: enter/exit lazy_mmu_mode around m2p_override calls
> 
> > Try reverting any of those.
> 
> Ah i missed your email since my hostingprovider was down :-(
> But anyway done a git bisect in the mean time that leads to:
> 
> [f62805f1f30a40e354bd036b4cb799863a39be4b] xen: enter/exit lazy_mmu_mode around m2p_override calls

OK. Hmm.that will take a bit of thinking to fix.
> 
> 
> > And if nothing works there then we can try to revert the ones that
> > deal with 'dom0_mem=max:XX'..
> 
> > I also need to be able to reproduce this. You said you can only reproduce this
> > on your Intel box - is this a fast Intel machine? It also looks like you only
> > have 2GB in the machine - and reserve 1GB to the dom0.
> 
> Machine is a quad core q9400 @ 2.66mhz, not very fast .. not very slow either

That is a fast machine. I was thinking you had a Core2 Solo or a Pentium IV Prescott.

> 
> > If you manually (so don't start the guest), balloon down - say to 512MB and then launch
> > a guest do you see this problem?
> 
> 
> Should i use
> 
> xl  mem-max domain-id mem
> 
> or
> 
> xl  mem-set domain-id mem

The later.
> 
> for that ?
> 
> 
> Perhaps a silly question, but why is it ballooning anyway ?
> I have set dom0's memory and there is enough left to create the domain ... or at least there should be ...

There was a bug in xl that would autoballoon. You can turn it off using some xl.conf file.

> 
> --
> Sander

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

From xen-devel-bounces@lists.xen.org Thu Sep 06 11:09:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 2012 11: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 1T9Zx6-0000EF-D8; Thu, 06 Sep 2012 11:08:52 +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 1T9Zx4-0000Dv-NF
	for xen-devel@lists.xen.org; Thu, 06 Sep 2012 11:08:50 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1346929708!8434302!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDc0MTc4NQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5579 invoked from network); 6 Sep 2012 11:08:29 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-16.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 6 Sep 2012 11:08: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 q86B8K3R015818
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 6 Sep 2012 11:08:21 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q86B8IFE007358
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 6 Sep 2012 11:08:19 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
	q86B8I5D017408; Thu, 6 Sep 2012 06:08:18 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 06 Sep 2012 04:08:18 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 24EDB402E4; Thu,  6 Sep 2012 06:57:46 -0400 (EDT)
Date: Thu, 6 Sep 2012 06:57:46 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Sander Eikelenboom <linux@eikelenboom.it>
Message-ID: <20120906105746.GA3668@phenom.dumpdata.com>
References: <1136369816.20120904183757@eikelenboom.it>
	<20120904163347.GH23361@phenom.dumpdata.com>
	<143844933.20120904191941@eikelenboom.it>
	<CAOvdn6U_yHgtZwv9MWazdLbd3NLq3pwGXnZY5sL2UVBhV_FUoQ@mail.gmail.com>
	<1813712325.20120904213459@eikelenboom.it>
	<048EAD622912254A9DEA24C1734613C18C864C3C5D@FTLPMAILBOX02.citrite.net>
	<20120905140600.GA5844@phenom.dumpdata.com>
	<1014998302.20120905163848@eikelenboom.it>
	<20120905201933.GA27814@phenom.dumpdata.com>
	<679529047.20120906005220@eikelenboom.it>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <679529047.20120906005220@eikelenboom.it>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: Robert Phillips <robert.phillips@citrix.com>, Ben Guthro <ben@guthro.net>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] dom0 linux 3.6.0-rc4,
 crash due to ballooning althoug dom0_mem=X, max:X 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

> > About nine of them deal with dom0_mem=max ballooning up right, so if you
> > ignore those:
> 
> > b9e0d95 xen: mark local pages as FOREIGN in the m2p_override
> > d79d595 xen: Add selfballoning memory reservation tunable.
> > f62805f xen: enter/exit lazy_mmu_mode around m2p_override calls
> 
> > Try reverting any of those.
> 
> Ah i missed your email since my hostingprovider was down :-(
> But anyway done a git bisect in the mean time that leads to:
> 
> [f62805f1f30a40e354bd036b4cb799863a39be4b] xen: enter/exit lazy_mmu_mode around m2p_override calls

OK. Hmm.that will take a bit of thinking to fix.
> 
> 
> > And if nothing works there then we can try to revert the ones that
> > deal with 'dom0_mem=max:XX'..
> 
> > I also need to be able to reproduce this. You said you can only reproduce this
> > on your Intel box - is this a fast Intel machine? It also looks like you only
> > have 2GB in the machine - and reserve 1GB to the dom0.
> 
> Machine is a quad core q9400 @ 2.66mhz, not very fast .. not very slow either

That is a fast machine. I was thinking you had a Core2 Solo or a Pentium IV Prescott.

> 
> > If you manually (so don't start the guest), balloon down - say to 512MB and then launch
> > a guest do you see this problem?
> 
> 
> Should i use
> 
> xl  mem-max domain-id mem
> 
> or
> 
> xl  mem-set domain-id mem

The later.
> 
> for that ?
> 
> 
> Perhaps a silly question, but why is it ballooning anyway ?
> I have set dom0's memory and there is enough left to create the domain ... or at least there should be ...

There was a bug in xl that would autoballoon. You can turn it off using some xl.conf file.

> 
> --
> Sander

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

From xen-devel-bounces@lists.xen.org Thu Sep 06 11:09:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 2012 11: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 1T9Zxm-0000Hm-Rl; Thu, 06 Sep 2012 11:09:34 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1T9Zxm-0000He-3h
	for xen-devel@lists.xen.org; Thu, 06 Sep 2012 11:09:34 +0000
Received: from [85.158.139.83:60027] by server-5.bemta-5.messagelabs.com id
	07/34-30514-D6488405; Thu, 06 Sep 2012 11:09:33 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1346929771!21701740!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzMxMzIz\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15034 invoked from network); 6 Sep 2012 11:09:32 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-11.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 6 Sep 2012 11:09:32 -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 q86B8tR1026753
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 6 Sep 2012 11:08:56 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
	q86B8sWm008281
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 6 Sep 2012 11:08:55 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
	q86B8r17015822; Thu, 6 Sep 2012 06:08:53 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 06 Sep 2012 04:08:53 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 3CD5A402E4; Thu,  6 Sep 2012 06:58:22 -0400 (EDT)
Date: Thu, 6 Sep 2012 06:58:22 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: James Harper <james.harper@bendigoit.com.au>
Message-ID: <20120906105822.GB3668@phenom.dumpdata.com>
References: <6035A0D088A63A46850C3988ED045A4B299F74F8@BITCOM1.int.sbss.com.au>
	<20120905202927.GD27814@phenom.dumpdata.com>
	<6035A0D088A63A46850C3988ED045A4B29B5D23E@BITCOM1.int.sbss.com.au>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <6035A0D088A63A46850C3988ED045A4B29B5D23E@BITCOM1.int.sbss.com.au>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] bug when using 4K sectors?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Sep 05, 2012 at 11:56:08PM +0000, James Harper wrote:
> > On Mon, Aug 13, 2012 at 02:12:58PM +0000, James Harper wrote:
> > > I notice this code in drivers/block/xen-blkback/common.h
> > >
> > > #define vbd_sz(_v)      ((_v)->bdev->bd_part ? \
> > >                          (_v)->bdev->bd_part->nr_sects : \
> > >                           get_capacity((_v)->bdev->bd_disk))
> > >
> > > is the value returned by vbd_sz(_v) the number of sectors in the Linux
> > > device (eg size / 4096), or the number of 512 byte sectors? I suspect
> > > the former which is causing block requests beyond 1/8th the size of
> > > the device to fail (assuming 4K sectors are expected to work at all -
> > > I can't quite get my head around how it would be expected to work -
> > > does Linux do the read-modify-write if required?)
> > 
> > I think you need to instrument it to be sure.. But more interesting, do you
> > actually have a disk that exposes a 4KB hardware and logical sector? So far
> > I've only found SSDs that expose a 512kB logical sector but also expose the
> > 4KB hardware.
> > 
> > Never could figure out how that is all suppose to work as the blkback is filled
> > with << 9 on a bunch of things.
> > 
> 
> I was using bcache which does expose a 4K block size, by default. I changed it to 512 and it all works now, although I haven't tested if there is any loss of performance.

OK, let me see how I can setup bcache and play with that.
> 
> Does Xen provide a way to tell Windows that the underlying device is 512e (4K sector with 512 byte emulated interface)? This would keep everything working as is but allow windows to align writes to 4K boundaries where possible.

We can certainly expose that via the XenBus interface.
> 
> James

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

From xen-devel-bounces@lists.xen.org Thu Sep 06 11:09:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 2012 11: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 1T9Zxm-0000Hm-Rl; Thu, 06 Sep 2012 11:09:34 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1T9Zxm-0000He-3h
	for xen-devel@lists.xen.org; Thu, 06 Sep 2012 11:09:34 +0000
Received: from [85.158.139.83:60027] by server-5.bemta-5.messagelabs.com id
	07/34-30514-D6488405; Thu, 06 Sep 2012 11:09:33 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1346929771!21701740!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzMxMzIz\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15034 invoked from network); 6 Sep 2012 11:09:32 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-11.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 6 Sep 2012 11:09:32 -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 q86B8tR1026753
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 6 Sep 2012 11:08:56 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
	q86B8sWm008281
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 6 Sep 2012 11:08:55 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
	q86B8r17015822; Thu, 6 Sep 2012 06:08:53 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 06 Sep 2012 04:08:53 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 3CD5A402E4; Thu,  6 Sep 2012 06:58:22 -0400 (EDT)
Date: Thu, 6 Sep 2012 06:58:22 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: James Harper <james.harper@bendigoit.com.au>
Message-ID: <20120906105822.GB3668@phenom.dumpdata.com>
References: <6035A0D088A63A46850C3988ED045A4B299F74F8@BITCOM1.int.sbss.com.au>
	<20120905202927.GD27814@phenom.dumpdata.com>
	<6035A0D088A63A46850C3988ED045A4B29B5D23E@BITCOM1.int.sbss.com.au>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <6035A0D088A63A46850C3988ED045A4B29B5D23E@BITCOM1.int.sbss.com.au>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] bug when using 4K sectors?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Sep 05, 2012 at 11:56:08PM +0000, James Harper wrote:
> > On Mon, Aug 13, 2012 at 02:12:58PM +0000, James Harper wrote:
> > > I notice this code in drivers/block/xen-blkback/common.h
> > >
> > > #define vbd_sz(_v)      ((_v)->bdev->bd_part ? \
> > >                          (_v)->bdev->bd_part->nr_sects : \
> > >                           get_capacity((_v)->bdev->bd_disk))
> > >
> > > is the value returned by vbd_sz(_v) the number of sectors in the Linux
> > > device (eg size / 4096), or the number of 512 byte sectors? I suspect
> > > the former which is causing block requests beyond 1/8th the size of
> > > the device to fail (assuming 4K sectors are expected to work at all -
> > > I can't quite get my head around how it would be expected to work -
> > > does Linux do the read-modify-write if required?)
> > 
> > I think you need to instrument it to be sure.. But more interesting, do you
> > actually have a disk that exposes a 4KB hardware and logical sector? So far
> > I've only found SSDs that expose a 512kB logical sector but also expose the
> > 4KB hardware.
> > 
> > Never could figure out how that is all suppose to work as the blkback is filled
> > with << 9 on a bunch of things.
> > 
> 
> I was using bcache which does expose a 4K block size, by default. I changed it to 512 and it all works now, although I haven't tested if there is any loss of performance.

OK, let me see how I can setup bcache and play with that.
> 
> Does Xen provide a way to tell Windows that the underlying device is 512e (4K sector with 512 byte emulated interface)? This would keep everything working as is but allow windows to align writes to 4K boundaries where possible.

We can certainly expose that via the XenBus interface.
> 
> James

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

From xen-devel-bounces@lists.xen.org Thu Sep 06 11:11:36 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 2012 11:11: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 1T9ZzZ-0000Rr-CC; Thu, 06 Sep 2012 11:11: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 1T9ZzX-0000Ri-UZ
	for xen-devel@lists.xen.org; Thu, 06 Sep 2012 11:11:24 +0000
Received: from [85.158.138.51:26037] by server-10.bemta-3.messagelabs.com id
	94/8D-10411-BD488405; Thu, 06 Sep 2012 11:11:23 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1346929882!20990025!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM5ODQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10912 invoked from network); 6 Sep 2012 11:11:22 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-6.tower-174.messagelabs.com with SMTP;
	6 Sep 2012 11:11:22 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 06 Sep 2012 12:11:23 +0100
Message-Id: <5048A1310200007800099471@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 06 Sep 2012 12:12:17 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Dan Magenheimer" <dan.magenheimer@oracle.com>
References: <504762B50200007800098D92@nat28.tlf.novell.com>
	<ece4f196-e34e-47f5-869f-9994503e4c18@default>
In-Reply-To: <ece4f196-e34e-47f5-869f-9994503e4c18@default>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Kurt Hackel <kurt.hackel@oracle.com>, Konrad Wilk <konrad.wilk@oracle.com>,
	Zhenzhong Duan <zhenzhong.duan@oracle.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 00/11] various tmem adjustments (mostly
 XSA-15 related)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.09.12 at 18:37, Dan Magenheimer <dan.magenheimer@oracle.com> wrote:
> Keir or Jan (or whoever is applying the patches), a heads-up would
> be appreciated to me and this cc list when this patchset is applied
> to -staging or any other Xen tree.

It was decided to put them in only after branching off 4.2, so
if all goes well early next week. Backporting to 4.2 would be
considered mostly based upon the whole feature becoming
fully functional again.

Jan


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

From xen-devel-bounces@lists.xen.org Thu Sep 06 11:11:36 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 2012 11:11: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 1T9ZzZ-0000Rr-CC; Thu, 06 Sep 2012 11:11: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 1T9ZzX-0000Ri-UZ
	for xen-devel@lists.xen.org; Thu, 06 Sep 2012 11:11:24 +0000
Received: from [85.158.138.51:26037] by server-10.bemta-3.messagelabs.com id
	94/8D-10411-BD488405; Thu, 06 Sep 2012 11:11:23 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1346929882!20990025!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM5ODQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10912 invoked from network); 6 Sep 2012 11:11:22 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-6.tower-174.messagelabs.com with SMTP;
	6 Sep 2012 11:11:22 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 06 Sep 2012 12:11:23 +0100
Message-Id: <5048A1310200007800099471@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 06 Sep 2012 12:12:17 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Dan Magenheimer" <dan.magenheimer@oracle.com>
References: <504762B50200007800098D92@nat28.tlf.novell.com>
	<ece4f196-e34e-47f5-869f-9994503e4c18@default>
In-Reply-To: <ece4f196-e34e-47f5-869f-9994503e4c18@default>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Kurt Hackel <kurt.hackel@oracle.com>, Konrad Wilk <konrad.wilk@oracle.com>,
	Zhenzhong Duan <zhenzhong.duan@oracle.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 00/11] various tmem adjustments (mostly
 XSA-15 related)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.09.12 at 18:37, Dan Magenheimer <dan.magenheimer@oracle.com> wrote:
> Keir or Jan (or whoever is applying the patches), a heads-up would
> be appreciated to me and this cc list when this patchset is applied
> to -staging or any other Xen tree.

It was decided to put them in only after branching off 4.2, so
if all goes well early next week. Backporting to 4.2 would be
considered mostly based upon the whole feature becoming
fully functional again.

Jan


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

From xen-devel-bounces@lists.xen.org Thu Sep 06 11:12:28 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 2012 11:12:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9a0R-0000Zs-Vu; Thu, 06 Sep 2012 11:12: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 1T9a0P-0000ZC-Nl
	for xen-devel@lists.xen.org; Thu, 06 Sep 2012 11:12:17 +0000
Received: from [85.158.138.51:64274] by server-10.bemta-3.messagelabs.com id
	2C/10-10411-E0588405; Thu, 06 Sep 2012 11:12:14 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1346929932!29011252!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM5ODQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11724 invoked from network); 6 Sep 2012 11:12:12 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-11.tower-174.messagelabs.com with SMTP;
	6 Sep 2012 11:12:12 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 06 Sep 2012 12:12:13 +0100
Message-Id: <5048A1620200007800099474@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 06 Sep 2012 12:13:06 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Christoph Egger" <Christoph.Egger@amd.com>
References: <D9137FCD9CFF644B965863BCFBEDABB8779942@SHSMSX101.ccr.corp.intel.com>
	<5040CAB30200007800097D73@nat28.tlf.novell.com>
	<D9137FCD9CFF644B965863BCFBEDABB877CBBD@SHSMSX101.ccr.corp.intel.com>
	<504898870200007800099427@nat28.tlf.novell.com>
	<50488311.7020702@amd.com>
In-Reply-To: <50488311.7020702@amd.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Jiongxi Li <jiongxi.li@intel.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [ PATCH 2/2] xen: enable Virtual-interrupt 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

>>> On 06.09.12 at 13:03, Christoph Egger <Christoph.Egger@amd.com> wrote:
> I think, move the VMX part into hvm/vmx/* and call a function pointer
> from common code. Having VMX or SVM specific code in common code
> is broken by design.

Yes - I had commented on that aspect 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 Sep 06 11:12:28 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 2012 11:12:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9a0R-0000Zs-Vu; Thu, 06 Sep 2012 11:12: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 1T9a0P-0000ZC-Nl
	for xen-devel@lists.xen.org; Thu, 06 Sep 2012 11:12:17 +0000
Received: from [85.158.138.51:64274] by server-10.bemta-3.messagelabs.com id
	2C/10-10411-E0588405; Thu, 06 Sep 2012 11:12:14 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1346929932!29011252!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM5ODQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11724 invoked from network); 6 Sep 2012 11:12:12 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-11.tower-174.messagelabs.com with SMTP;
	6 Sep 2012 11:12:12 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 06 Sep 2012 12:12:13 +0100
Message-Id: <5048A1620200007800099474@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 06 Sep 2012 12:13:06 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Christoph Egger" <Christoph.Egger@amd.com>
References: <D9137FCD9CFF644B965863BCFBEDABB8779942@SHSMSX101.ccr.corp.intel.com>
	<5040CAB30200007800097D73@nat28.tlf.novell.com>
	<D9137FCD9CFF644B965863BCFBEDABB877CBBD@SHSMSX101.ccr.corp.intel.com>
	<504898870200007800099427@nat28.tlf.novell.com>
	<50488311.7020702@amd.com>
In-Reply-To: <50488311.7020702@amd.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Jiongxi Li <jiongxi.li@intel.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [ PATCH 2/2] xen: enable Virtual-interrupt 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

>>> On 06.09.12 at 13:03, Christoph Egger <Christoph.Egger@amd.com> wrote:
> I think, move the VMX part into hvm/vmx/* and call a function pointer
> from common code. Having VMX or SVM specific code in common code
> is broken by design.

Yes - I had commented on that aspect 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 Sep 06 11:17:36 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 2012 11: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 1T9a5O-0000wA-On; Thu, 06 Sep 2012 11:17:26 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <linux@eikelenboom.it>) id 1T9a5N-0000w4-T7
	for xen-devel@lists.xen.org; Thu, 06 Sep 2012 11:17:26 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-14.tower-27.messagelabs.com!1346930220!2853631!1
X-Originating-IP: [188.40.164.121]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23261 invoked from network); 6 Sep 2012 11:17:00 -0000
Received: from static.121.164.40.188.clients.your-server.de (HELO
	smtp.eikelenboom.it) (188.40.164.121)
	by server-14.tower-27.messagelabs.com with AES256-SHA encrypted SMTP;
	6 Sep 2012 11:17:00 -0000
Received: from 128-64-ftth.onsneteindhoven.nl ([88.159.64.128]:52268
	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 1T9a4y-00075g-U0; Thu, 06 Sep 2012 13:17:01 +0200
Date: Thu, 6 Sep 2012 13:16:55 +0200
From: Sander Eikelenboom <linux@eikelenboom.it>
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <899997008.20120906131655@eikelenboom.it>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
In-Reply-To: <20120906105746.GA3668@phenom.dumpdata.com>
References: <1136369816.20120904183757@eikelenboom.it>
	<20120904163347.GH23361@phenom.dumpdata.com>
	<143844933.20120904191941@eikelenboom.it>
	<CAOvdn6U_yHgtZwv9MWazdLbd3NLq3pwGXnZY5sL2UVBhV_FUoQ@mail.gmail.com>
	<1813712325.20120904213459@eikelenboom.it>
	<048EAD622912254A9DEA24C1734613C18C864C3C5D@FTLPMAILBOX02.citrite.net>
	<20120905140600.GA5844@phenom.dumpdata.com>
	<1014998302.20120905163848@eikelenboom.it>
	<20120905201933.GA27814@phenom.dumpdata.com>
	<679529047.20120906005220@eikelenboom.it>
	<20120906105746.GA3668@phenom.dumpdata.com>
MIME-Version: 1.0
Cc: Robert Phillips <robert.phillips@citrix.com>, Ben Guthro <ben@guthro.net>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] dom0 linux 3.6.0-rc4,
	crash due to ballooning althoug dom0_mem=X, max:X 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


Thursday, September 6, 2012, 12:57:46 PM, you wrote:

>> > About nine of them deal with dom0_mem=max ballooning up right, so if you
>> > ignore those:
>> 
>> > b9e0d95 xen: mark local pages as FOREIGN in the m2p_override
>> > d79d595 xen: Add selfballoning memory reservation tunable.
>> > f62805f xen: enter/exit lazy_mmu_mode around m2p_override calls
>> 
>> > Try reverting any of those.
>> 
>> Ah i missed your email since my hostingprovider was down :-(
>> But anyway done a git bisect in the mean time that leads to:
>> 
>> [f62805f1f30a40e354bd036b4cb799863a39be4b] xen: enter/exit lazy_mmu_mode around m2p_override calls

> OK. Hmm.that will take a bit of thinking to fix.
>> 
>> 
>> > And if nothing works there then we can try to revert the ones that
>> > deal with 'dom0_mem=max:XX'..
>> 
>> > I also need to be able to reproduce this. You said you can only reproduce this
>> > on your Intel box - is this a fast Intel machine? It also looks like you only
>> > have 2GB in the machine - and reserve 1GB to the dom0.
>> 
>> Machine is a quad core q9400 @ 2.66mhz, not very fast .. not very slow either

> That is a fast machine. I was thinking you had a Core2 Solo or a Pentium IV Prescott.

>> 
>> > If you manually (so don't start the guest), balloon down - say to 512MB and then launch
>> > a guest do you see this problem?
>> 
>> 
>> Should i use
>> 
>> xl  mem-max domain-id mem
>> 
>> or
>> 
>> xl  mem-set domain-id mem

Will test that shortly

> The later.
>> 
>> for that ?
>> 
>> 
>> Perhaps a silly question, but why is it ballooning anyway ?
>> I have set dom0's memory and there is enough left to create the domain ... or at least there should be ...

> There was a bug in xl that would autoballoon. You can turn it off using some xl.conf file.

Should that have been fixed ?
       A) you describe it as a bug, so even without tinkering with the default xl.conf, the tools shouldn't be autoballooning when "dom0_mem=X, max:X" is set right ?)
       B) or was it fixed by letting the user turn it off in xl.conf ?

If A .. That would make that the "bug" is still present in xen-4.2-rc4 ...

Because i was under the impression the "dom0_mem=X, max:X" would prevent the whole autoballooning stuff :-)


>> 
>> --
>> Sander



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

From xen-devel-bounces@lists.xen.org Thu Sep 06 11:17:36 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 2012 11: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 1T9a5O-0000wA-On; Thu, 06 Sep 2012 11:17:26 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <linux@eikelenboom.it>) id 1T9a5N-0000w4-T7
	for xen-devel@lists.xen.org; Thu, 06 Sep 2012 11:17:26 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-14.tower-27.messagelabs.com!1346930220!2853631!1
X-Originating-IP: [188.40.164.121]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23261 invoked from network); 6 Sep 2012 11:17:00 -0000
Received: from static.121.164.40.188.clients.your-server.de (HELO
	smtp.eikelenboom.it) (188.40.164.121)
	by server-14.tower-27.messagelabs.com with AES256-SHA encrypted SMTP;
	6 Sep 2012 11:17:00 -0000
Received: from 128-64-ftth.onsneteindhoven.nl ([88.159.64.128]:52268
	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 1T9a4y-00075g-U0; Thu, 06 Sep 2012 13:17:01 +0200
Date: Thu, 6 Sep 2012 13:16:55 +0200
From: Sander Eikelenboom <linux@eikelenboom.it>
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <899997008.20120906131655@eikelenboom.it>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
In-Reply-To: <20120906105746.GA3668@phenom.dumpdata.com>
References: <1136369816.20120904183757@eikelenboom.it>
	<20120904163347.GH23361@phenom.dumpdata.com>
	<143844933.20120904191941@eikelenboom.it>
	<CAOvdn6U_yHgtZwv9MWazdLbd3NLq3pwGXnZY5sL2UVBhV_FUoQ@mail.gmail.com>
	<1813712325.20120904213459@eikelenboom.it>
	<048EAD622912254A9DEA24C1734613C18C864C3C5D@FTLPMAILBOX02.citrite.net>
	<20120905140600.GA5844@phenom.dumpdata.com>
	<1014998302.20120905163848@eikelenboom.it>
	<20120905201933.GA27814@phenom.dumpdata.com>
	<679529047.20120906005220@eikelenboom.it>
	<20120906105746.GA3668@phenom.dumpdata.com>
MIME-Version: 1.0
Cc: Robert Phillips <robert.phillips@citrix.com>, Ben Guthro <ben@guthro.net>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] dom0 linux 3.6.0-rc4,
	crash due to ballooning althoug dom0_mem=X, max:X 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


Thursday, September 6, 2012, 12:57:46 PM, you wrote:

>> > About nine of them deal with dom0_mem=max ballooning up right, so if you
>> > ignore those:
>> 
>> > b9e0d95 xen: mark local pages as FOREIGN in the m2p_override
>> > d79d595 xen: Add selfballoning memory reservation tunable.
>> > f62805f xen: enter/exit lazy_mmu_mode around m2p_override calls
>> 
>> > Try reverting any of those.
>> 
>> Ah i missed your email since my hostingprovider was down :-(
>> But anyway done a git bisect in the mean time that leads to:
>> 
>> [f62805f1f30a40e354bd036b4cb799863a39be4b] xen: enter/exit lazy_mmu_mode around m2p_override calls

> OK. Hmm.that will take a bit of thinking to fix.
>> 
>> 
>> > And if nothing works there then we can try to revert the ones that
>> > deal with 'dom0_mem=max:XX'..
>> 
>> > I also need to be able to reproduce this. You said you can only reproduce this
>> > on your Intel box - is this a fast Intel machine? It also looks like you only
>> > have 2GB in the machine - and reserve 1GB to the dom0.
>> 
>> Machine is a quad core q9400 @ 2.66mhz, not very fast .. not very slow either

> That is a fast machine. I was thinking you had a Core2 Solo or a Pentium IV Prescott.

>> 
>> > If you manually (so don't start the guest), balloon down - say to 512MB and then launch
>> > a guest do you see this problem?
>> 
>> 
>> Should i use
>> 
>> xl  mem-max domain-id mem
>> 
>> or
>> 
>> xl  mem-set domain-id mem

Will test that shortly

> The later.
>> 
>> for that ?
>> 
>> 
>> Perhaps a silly question, but why is it ballooning anyway ?
>> I have set dom0's memory and there is enough left to create the domain ... or at least there should be ...

> There was a bug in xl that would autoballoon. You can turn it off using some xl.conf file.

Should that have been fixed ?
       A) you describe it as a bug, so even without tinkering with the default xl.conf, the tools shouldn't be autoballooning when "dom0_mem=X, max:X" is set right ?)
       B) or was it fixed by letting the user turn it off in xl.conf ?

If A .. That would make that the "bug" is still present in xen-4.2-rc4 ...

Because i was under the impression the "dom0_mem=X, max:X" would prevent the whole autoballooning stuff :-)


>> 
>> --
>> Sander



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

From xen-devel-bounces@lists.xen.org Thu Sep 06 11:19:17 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 2012 11:19:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9a72-000114-8e; Thu, 06 Sep 2012 11:19:08 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1T9a70-00010u-Gs
	for xen-devel@lists.xen.org; Thu, 06 Sep 2012 11:19:06 +0000
Received: from [85.158.143.99:50082] by server-1.bemta-4.messagelabs.com id
	77/34-12504-9A688405; Thu, 06 Sep 2012 11:19:05 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1346930343!19114311!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDc0MTc4NQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3257 invoked from network); 6 Sep 2012 11:19:05 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-8.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 6 Sep 2012 11:19: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 q86BIxQO027105
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 6 Sep 2012 11:19:00 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
	q86BIwE2027188
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 6 Sep 2012 11:18:58 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
	q86BIv4l026307; Thu, 6 Sep 2012 06:18:58 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 06 Sep 2012 04:18:57 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id D1D60402E4; Thu,  6 Sep 2012 07:08:25 -0400 (EDT)
Date: Thu, 6 Sep 2012 07:08:25 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120906110825.GE3668@phenom.dumpdata.com>
References: <1B4B44D9196EFF41AE41FDA404FC0A1018AF31@SHSMSX101.ccr.corp.intel.com>
	<1346426328.27277.234.camel@zakaz.uk.xensource.com>
	<1B4B44D9196EFF41AE41FDA404FC0A1018FAD3@SHSMSX101.ccr.corp.intel.com>
	<1346916672.10570.20.camel@dagon.hellion.org.uk>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1346916672.10570.20.camel@dagon.hellion.org.uk>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: "Ren, Yongjie" <yongjie.ren@intel.com>, "Keir \(Xen.org\)" <keir@xen.org>,
	'Jan Beulich' <JBeulich@suse.com>, 'xen-devel' <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen4.2-rc3 test result
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Sep 06, 2012 at 08:31:12AM +0100, Ian Campbell wrote:
> On Thu, 2012-09-06 at 06:59 +0100, Ren, Yongjie wrote:
> > > Have we ever supported HVM guest CPU remove? I thought not.
> > > 
> > > http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1822#c3 seems to
> > > describe the behaviour I would expect.
> > > 
> > If we don't want to support HVM guest CPU remove in near future, I want to close this bug.
> 
> Is this something Intel is considering working on? If so then someone
> should mention it to George in the 4.3 planning thread.
> 
> > > If this is supposed to be an existing feature then is this a regression
> > > with xl vs xm or from 4.1 to 4.2?
> > > 
> > No, it's not a regression from 4.1 to 4.2.
> > Neither Xen 4.1 nor 4.2 supports HVM guest CPU remove with xm or xl.

But I think the bug does not talk about 'remove' but 'offline'.

That functionality (from a Xen toolstack perspective) works - if you
do 'xl vcpu-set' it properly tells the guest (either PV or HVM) to decrease
the count.

The problem is with the Linux kernel - and with the generic code:

https://lkml.org/lkml/2012/4/30/198

(and no, I had not a chance to actually fix it. Looking for volunteers).

> 
> OK, then I can remove it from the TODO list for 4.2, since it certainly
> isn't happening for 4.2.0 at this stage.

Right. Its a Linux kernel issue.
> 
> Thanks for letting me know,
> Ian.
> 
> 

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

From xen-devel-bounces@lists.xen.org Thu Sep 06 11:19:17 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 2012 11:19:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9a72-000114-8e; Thu, 06 Sep 2012 11:19:08 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1T9a70-00010u-Gs
	for xen-devel@lists.xen.org; Thu, 06 Sep 2012 11:19:06 +0000
Received: from [85.158.143.99:50082] by server-1.bemta-4.messagelabs.com id
	77/34-12504-9A688405; Thu, 06 Sep 2012 11:19:05 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1346930343!19114311!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDc0MTc4NQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3257 invoked from network); 6 Sep 2012 11:19:05 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-8.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 6 Sep 2012 11:19: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 q86BIxQO027105
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 6 Sep 2012 11:19:00 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
	q86BIwE2027188
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 6 Sep 2012 11:18:58 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
	q86BIv4l026307; Thu, 6 Sep 2012 06:18:58 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 06 Sep 2012 04:18:57 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id D1D60402E4; Thu,  6 Sep 2012 07:08:25 -0400 (EDT)
Date: Thu, 6 Sep 2012 07:08:25 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120906110825.GE3668@phenom.dumpdata.com>
References: <1B4B44D9196EFF41AE41FDA404FC0A1018AF31@SHSMSX101.ccr.corp.intel.com>
	<1346426328.27277.234.camel@zakaz.uk.xensource.com>
	<1B4B44D9196EFF41AE41FDA404FC0A1018FAD3@SHSMSX101.ccr.corp.intel.com>
	<1346916672.10570.20.camel@dagon.hellion.org.uk>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1346916672.10570.20.camel@dagon.hellion.org.uk>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: "Ren, Yongjie" <yongjie.ren@intel.com>, "Keir \(Xen.org\)" <keir@xen.org>,
	'Jan Beulich' <JBeulich@suse.com>, 'xen-devel' <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen4.2-rc3 test result
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Sep 06, 2012 at 08:31:12AM +0100, Ian Campbell wrote:
> On Thu, 2012-09-06 at 06:59 +0100, Ren, Yongjie wrote:
> > > Have we ever supported HVM guest CPU remove? I thought not.
> > > 
> > > http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1822#c3 seems to
> > > describe the behaviour I would expect.
> > > 
> > If we don't want to support HVM guest CPU remove in near future, I want to close this bug.
> 
> Is this something Intel is considering working on? If so then someone
> should mention it to George in the 4.3 planning thread.
> 
> > > If this is supposed to be an existing feature then is this a regression
> > > with xl vs xm or from 4.1 to 4.2?
> > > 
> > No, it's not a regression from 4.1 to 4.2.
> > Neither Xen 4.1 nor 4.2 supports HVM guest CPU remove with xm or xl.

But I think the bug does not talk about 'remove' but 'offline'.

That functionality (from a Xen toolstack perspective) works - if you
do 'xl vcpu-set' it properly tells the guest (either PV or HVM) to decrease
the count.

The problem is with the Linux kernel - and with the generic code:

https://lkml.org/lkml/2012/4/30/198

(and no, I had not a chance to actually fix it. Looking for volunteers).

> 
> OK, then I can remove it from the TODO list for 4.2, since it certainly
> isn't happening for 4.2.0 at this stage.

Right. Its a Linux kernel issue.
> 
> Thanks for letting me know,
> Ian.
> 
> 

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

From xen-devel-bounces@lists.xen.org Thu Sep 06 11:22:53 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 2012 11:22:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9aAV-0001DF-Sv; Thu, 06 Sep 2012 11:22:43 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1T9aAT-0001D8-Kq
	for xen-devel@lists.xen.org; Thu, 06 Sep 2012 11:22:41 +0000
Received: from [85.158.143.99:27435] by server-2.bemta-4.messagelabs.com id
	5B/BB-21239-08788405; Thu, 06 Sep 2012 11:22:40 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1346930559!19115187!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDc0MTc4NQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20894 invoked from network); 6 Sep 2012 11:22:40 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-8.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 6 Sep 2012 11:22: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 q86BMWwu030105
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 6 Sep 2012 11:22:32 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q86BMVrK002670
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 6 Sep 2012 11:22:31 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
	q86BMVtd028483; Thu, 6 Sep 2012 06:22:31 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 06 Sep 2012 04:22:30 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id BC9E4402E4; Thu,  6 Sep 2012 07:11:58 -0400 (EDT)
Date: Thu, 6 Sep 2012 07:11:58 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: "Ren, Yongjie" <yongjie.ren@intel.com>
Message-ID: <20120906111158.GF3668@phenom.dumpdata.com>
References: <1B4B44D9196EFF41AE41FDA404FC0A1018AF31@SHSMSX101.ccr.corp.intel.com>
	<20120831172410.GA19756@localhost.localdomain>
	<1B4B44D9196EFF41AE41FDA404FC0A10190E9D@SHSMSX101.ccr.corp.intel.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1B4B44D9196EFF41AE41FDA404FC0A10190E9D@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: Konrad Rzeszutek Wilk <konrad@kernel.org>, 'Keir Fraser' <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] Xen4.2-rc3 test result
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Sep 06, 2012 at 08:18:16AM +0000, Ren, Yongjie wrote:
> > -----Original Message-----
> > From: Konrad Rzeszutek [mailto:ketuzsezr@gmail.com] On Behalf Of
> > Konrad Rzeszutek Wilk
> > Sent: Saturday, September 01, 2012 1:24 AM
> > To: Ren, Yongjie
> > Cc: 'xen-devel'; 'Keir Fraser'; 'Ian Campbell'; 'Jan Beulich'; 'Konrad
> > Rzeszutek Wilk'
> > Subject: Re: [Xen-devel] Xen4.2-rc3 test result
> 
> > > 5. Dom0 cannot be shutdown before PCI detachment from guest and
> > when pci assignment conflicts
> > >   http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1826
> > 
> > Um, so you are assigning the same VF to two guests. I am surprised that
> > the tools even allowed you to do that. Was 'xm' allowing you to do that?
> > 
> No, 'xl' doesn't allow me to do that. We can't assignment a device to different guests. 
> Sorry, the description of this bug is not accurate. I changed its title to "Dom0 cannot be shut down before PCI device detachment from a guest".
> If a guest (with a PCI device assigned) is running, Dom0 will panic when shutting down.

And does it panic if you use the 'irqpoll' option it asks for?
Xen-pciback has no involvment as:


[  283.747488] xenbus_dev_shutdown: backend/pci/1/0: Initialised != Connected, skipping

and the guest still keeps on getting interrupts.

What is the stack at the hang? 
> 
> > > 6. Guest hang after resuming from S3
> > >   http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1828
> > 
> > Jan posted some patches to fix that. Can you test with an up-to-date
> > guest? (so not RHEL6U1 which does not have the fix).
> > 
> I tested a RHEL guest with Linux kernel 3.5.3 which already includes Jan's patches you mentioned.
> It will not fix this bug.
> If using kernel 3.5.3 in guest, the guest totally can't resume after running ' xl trigger $dom_ID s3resume'.
> There's some info (as following) in 'xl dmesg' when trying to resume the guest.
> (XEN) HVM10: S3 resume called 00fe 0x00099180
> (XEN) HVM10: S3 resume jump to 9918:0000
> But the guest can't resume.
> 
> > > 7. Dom0 S3 resume fails
> > >   http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1707
> > 
> > Yeah, that one is mine. Have some patches for that I will post soonish.
> > >
> > > Best Regards,
> > >      Yongjie (Jay)
> > >
> > >
> > > _______________________________________________
> > > Xen-devel mailing list
> > > Xen-devel@lists.xen.org
> > > http://lists.xen.org/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 Sep 06 11:22:53 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 2012 11:22:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9aAV-0001DF-Sv; Thu, 06 Sep 2012 11:22:43 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1T9aAT-0001D8-Kq
	for xen-devel@lists.xen.org; Thu, 06 Sep 2012 11:22:41 +0000
Received: from [85.158.143.99:27435] by server-2.bemta-4.messagelabs.com id
	5B/BB-21239-08788405; Thu, 06 Sep 2012 11:22:40 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1346930559!19115187!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDc0MTc4NQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20894 invoked from network); 6 Sep 2012 11:22:40 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-8.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 6 Sep 2012 11:22: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 q86BMWwu030105
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 6 Sep 2012 11:22:32 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q86BMVrK002670
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 6 Sep 2012 11:22:31 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
	q86BMVtd028483; Thu, 6 Sep 2012 06:22:31 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 06 Sep 2012 04:22:30 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id BC9E4402E4; Thu,  6 Sep 2012 07:11:58 -0400 (EDT)
Date: Thu, 6 Sep 2012 07:11:58 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: "Ren, Yongjie" <yongjie.ren@intel.com>
Message-ID: <20120906111158.GF3668@phenom.dumpdata.com>
References: <1B4B44D9196EFF41AE41FDA404FC0A1018AF31@SHSMSX101.ccr.corp.intel.com>
	<20120831172410.GA19756@localhost.localdomain>
	<1B4B44D9196EFF41AE41FDA404FC0A10190E9D@SHSMSX101.ccr.corp.intel.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1B4B44D9196EFF41AE41FDA404FC0A10190E9D@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: Konrad Rzeszutek Wilk <konrad@kernel.org>, 'Keir Fraser' <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] Xen4.2-rc3 test result
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Sep 06, 2012 at 08:18:16AM +0000, Ren, Yongjie wrote:
> > -----Original Message-----
> > From: Konrad Rzeszutek [mailto:ketuzsezr@gmail.com] On Behalf Of
> > Konrad Rzeszutek Wilk
> > Sent: Saturday, September 01, 2012 1:24 AM
> > To: Ren, Yongjie
> > Cc: 'xen-devel'; 'Keir Fraser'; 'Ian Campbell'; 'Jan Beulich'; 'Konrad
> > Rzeszutek Wilk'
> > Subject: Re: [Xen-devel] Xen4.2-rc3 test result
> 
> > > 5. Dom0 cannot be shutdown before PCI detachment from guest and
> > when pci assignment conflicts
> > >   http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1826
> > 
> > Um, so you are assigning the same VF to two guests. I am surprised that
> > the tools even allowed you to do that. Was 'xm' allowing you to do that?
> > 
> No, 'xl' doesn't allow me to do that. We can't assignment a device to different guests. 
> Sorry, the description of this bug is not accurate. I changed its title to "Dom0 cannot be shut down before PCI device detachment from a guest".
> If a guest (with a PCI device assigned) is running, Dom0 will panic when shutting down.

And does it panic if you use the 'irqpoll' option it asks for?
Xen-pciback has no involvment as:


[  283.747488] xenbus_dev_shutdown: backend/pci/1/0: Initialised != Connected, skipping

and the guest still keeps on getting interrupts.

What is the stack at the hang? 
> 
> > > 6. Guest hang after resuming from S3
> > >   http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1828
> > 
> > Jan posted some patches to fix that. Can you test with an up-to-date
> > guest? (so not RHEL6U1 which does not have the fix).
> > 
> I tested a RHEL guest with Linux kernel 3.5.3 which already includes Jan's patches you mentioned.
> It will not fix this bug.
> If using kernel 3.5.3 in guest, the guest totally can't resume after running ' xl trigger $dom_ID s3resume'.
> There's some info (as following) in 'xl dmesg' when trying to resume the guest.
> (XEN) HVM10: S3 resume called 00fe 0x00099180
> (XEN) HVM10: S3 resume jump to 9918:0000
> But the guest can't resume.
> 
> > > 7. Dom0 S3 resume fails
> > >   http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1707
> > 
> > Yeah, that one is mine. Have some patches for that I will post soonish.
> > >
> > > Best Regards,
> > >      Yongjie (Jay)
> > >
> > >
> > > _______________________________________________
> > > Xen-devel mailing list
> > > Xen-devel@lists.xen.org
> > > http://lists.xen.org/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 Sep 06 11:28:22 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 2012 11:28:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9aFn-0001Np-LT; Thu, 06 Sep 2012 11:28:11 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <tobias.geiger@vido.info>) id 1T9aFm-0001Nh-1k
	for xen-devel@lists.xen.org; Thu, 06 Sep 2012 11:28:10 +0000
Received: from [85.158.139.83:43569] by server-9.bemta-5.messagelabs.com id
	39/1C-20529-9C888405; Thu, 06 Sep 2012 11:28:09 +0000
X-Env-Sender: tobias.geiger@vido.info
X-Msg-Ref: server-9.tower-182.messagelabs.com!1346930888!28249186!1
X-Originating-IP: [78.47.43.170]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
	MAILTO_TO_SPAM_ADDR,SUBJECT_EXCESS_QP,UNPARSEABLE_RELAY
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17648 invoked from network); 6 Sep 2012 11:28:08 -0000
Received: from mail.vido.info (HELO mail.vido.info) (78.47.43.170)
	by server-9.tower-182.messagelabs.com with SMTP;
	6 Sep 2012 11:28:08 -0000
Received: from localhost (ip6-localhost [127.0.0.1])
	by mail.vido.info (Postfix) with ESMTP id E9D0DD3429D;
	Thu,  6 Sep 2012 13:28:07 +0200 (CEST)
X-Virus-Scanned: by amavis at mail.vido.info
Received: from mail.vido.info ([127.0.0.1])
	by localhost (mail.vido.info [127.0.0.1]) (amavisd-new, port 10024)
	with LMTP id gGrWlujlG8q2; Thu,  6 Sep 2012 13:28:01 +0200 (CEST)
Received: from www.vido.info (www.vido.info [78.47.43.171])
	by mail.vido.info (Postfix) with ESMTP id 034C7D34290;
	Thu,  6 Sep 2012 13:28:01 +0200 (CEST)
Received: from A08X7SPVzjnaJkW+7cCX53ocxut7je+ERMSBHlcK3+KOUxlhwVVwlA==
	(SuRgyhmAslcido4lHmoqR+vf8zrnQIUF) by www.vido.info
	with HTTP (HTTP/1.1 POST); Thu, 06 Sep 2012 13:28:00 +0200
MIME-Version: 1.0
Date: Thu, 06 Sep 2012 13:28:00 +0200
From: Tobias Geiger <tobias.geiger@vido.info>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
In-Reply-To: <20120905185412.GA27077@phenom.dumpdata.com>
References: <1B4B44D9196EFF41AE41FDA404FC0A101881CE@SHSMSX101.ccr.corp.intel.com>
	<20120905185412.GA27077@phenom.dumpdata.com>
Message-ID: <f74e17a2c22339a3eb0439a03bef10b1@vido.info>
X-Sender: tobias.geiger@vido.info
User-Agent: Roundcube Webmail
Cc: Konrad Rzeszutek Wilk <konrad@kernel.org>, "Ren,
	Yongjie" <yongjie.ren@intel.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel]
 =?utf-8?q?Regression_in_kernel_3=2E5_as_Dom0_regardin?=
 =?utf-8?q?g_PCI_Passthrough=3F!?=
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
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 Konrad,

the patch helps regarding the USB-PCIController-Passthrough - this 
works now in DomU.

but i still get the Dom0 crash when shutting down DomU:

Sep  6 13:26:19 pc kernel: [  361.011514] 
xen-blkback:backend/vbd/1/832: prepare for reconnect
Sep  6 13:26:20 pc kernel: [  361.876395] 
xen-blkback:backend/vbd/1/768: prepare for reconnect
Sep  6 13:26:21 pc kernel: [  362.682152] br0: port 3(vif1.0) entered 
disabled state
Sep  6 13:26:21 pc kernel: [  362.682267] br0: port 3(vif1.0) entered 
disabled state
Sep  6 13:26:24 pc kernel: [  365.541386] ------------[ cut here 
]------------
Sep  6 13:26:24 pc kernel: [  365.541411] invalid opcode: 0000 [#1] 
PREEMPT SMP
Sep  6 13:26:24 pc kernel: [  365.541423] CPU 2
Sep  6 13:26:24 pc kernel: [  365.541427] Modules linked in: uvcvideo 
snd_usb_audio snd_usbmidi_lib snd_seq_midi snd_hwd
ep snd_rawmidi videobuf2_vmalloc videobuf2_memops videobuf2_core 
videodev gpio_ich joydev hid_generic [last unloaded: sc
si_wait_scan]
Sep  6 13:26:24 pc kernel: [  365.541474]
Sep  6 13:26:24 pc kernel: [  365.541477] Pid: 1208, comm: kworker/2:1 
Not tainted 3.5.0 #3                  /DX58SO
Sep  6 13:26:24 pc kernel: [  365.541491] RIP: 
e030:[<ffffffff81447f95>]  [<ffffffff81447f95>] 
balloon_process+0x385/0x3
a0
Sep  6 13:26:24 pc kernel: [  365.541507] RSP: e02b:ffff88012e7abdc0  
EFLAGS: 00010213
Sep  6 13:26:24 pc kernel: [  365.541515] RAX: 0000000220be7000 RBX: 
0000000000000000 RCX: 0000000000000008
Sep  6 13:26:24 pc kernel: [  365.541523] RDX: ffff88010d99a000 RSI: 
00000000000001df RDI: 000000000020efdf
Sep  6 13:26:24 pc kernel: [  365.541532] RBP: ffff88012e7abe20 R08: 
ffff88014064e140 R09: 00000000fffffffe
Sep  6 13:26:24 pc kernel: [  365.541540] R10: 0000000000000001 R11: 
0000000000000000 R12: 0000160000000000
Sep  6 13:26:24 pc kernel: [  365.541548] R13: 0000000000000001 R14: 
000000000020efdf R15: ffffea00083bf7c0
Sep  6 13:26:24 pc kernel: [  365.541561] FS:  00007f79d32ce700(0000) 
GS:ffff880140640000(0000) knlGS:0000000000000000
Sep  6 13:26:24 pc kernel: [  365.541571] CS:  e033 DS: 0000 ES: 0000 
CR0: 000000008005003b
Sep  6 13:26:24 pc kernel: [  365.541578] CR2: 00007f79d2d6ce02 CR3: 
0000000001e0c000 CR4: 0000000000002660
Sep  6 13:26:24 pc kernel: [  365.541587] DR0: 0000000000000000 DR1: 
0000000000000000 DR2: 0000000000000000
Sep  6 13:26:24 pc kernel: [  365.541596] DR3: 0000000000000000 DR6: 
00000000ffff0ff0 DR7: 0000000000000400
Sep  6 13:26:24 pc kernel: [  365.541604] Process kworker/2:1 (pid: 
1208, threadinfo ffff88012e7aa000, task ffff88013101
c440)
Sep  6 13:26:24 pc kernel: [  365.541613] Stack:
Sep  6 13:26:24 pc kernel: [  365.541618]  000000000006877b 
0000000000000001 ffffffff8200ea80 0000000000000001
Sep  6 13:26:24 pc kernel: [  365.541649]  0000000000000000 
0000000000007ff0 ffff88012e7abe00 ffff8801302eee00
Sep  6 13:26:24 pc kernel: [  365.541664]  ffff880140657000 
ffff88014064e140 0000000000000000 ffffffff81e587c0
Sep  6 13:26:24 pc kernel: [  365.541679] Call Trace:
Sep  6 13:26:24 pc kernel: [  365.541688]  [<ffffffff8106753b>] 
process_one_work+0x12b/0x450
Sep  6 13:26:24 pc kernel: [  365.541697]  [<ffffffff81447c10>] ? 
decrease_reservation+0x320/0x320
Sep  6 13:26:24 pc kernel: [  365.541706]  [<ffffffff810688be>] 
worker_thread+0x12e/0x2d0
Sep  6 13:26:24 pc kernel: [  365.541715]  [<ffffffff81068790>] ? 
manage_workers.isra.26+0x1f0/0x1f0
Sep  6 13:26:24 pc kernel: [  365.541725]  [<ffffffff8106db7e>] 
kthread+0x8e/0xa0
Sep  6 13:26:24 pc kernel: [  365.541735]  [<ffffffff8184e3e4>] 
kernel_thread_helper+0x4/0x10
Sep  6 13:26:24 pc kernel: [  365.541745]  [<ffffffff8184c87c>] ? 
retint_restore_args+0x5/0x6
Sep  6 13:26:24 pc kernel: [  365.541754]  [<ffffffff8184e3e0>] ? 
gs_change+0x13/0x13
Sep  6 13:26:24 pc kernel: [  365.541760] Code: 01 15 f0 6a bc 00 48 29 
d0 48 89 05 ee 6a bc 00 e9 31 fd ff ff 0f 0b 0f
0b 4c 89 f7 e8 85 34 bc ff 48 83 f8 ff 0f 84 2b fe ff ff <0f> 0b 66 0f 
1f 84 00 00 00 00 00 48 83 c1 01 e9 c2 fd ff ff 0
f
Sep  6 13:26:24 pc kernel: [  365.541898]  RSP <ffff88012e7abdc0>
Sep  6 13:26:24 pc kernel: [  365.565054] ---[ end trace 
25eb9ce0cc61c3a1 ]---
Sep  6 13:26:24 pc kernel: [  365.565101] PGD 1e0e067 PUD 1e0f067 PMD 0
Sep  6 13:26:24 pc kernel: [  365.565108] Oops: 0000 [#2] PREEMPT SMP
Sep  6 13:26:24 pc kernel: [  365.565115] CPU 2
Sep  6 13:26:24 pc kernel: [  365.565118] Modules linked in: uvcvideo 
snd_usb_audio snd_usbmidi_lib snd_seq_midi snd_hwd
ep snd_rawmidi videobuf2_vmalloc videobuf2_memops videobuf2_core 
videodev gpio_ich joydev hid_generic [last unloaded: sc
si_wait_scan]
Sep  6 13:26:24 pc kernel: [  365.565153]
Sep  6 13:26:24 pc kernel: [  365.565156] Pid: 1208, comm: kworker/2:1 
Tainted: G      D      3.5.0 #3
/DX58SO
Sep  6 13:26:24 pc kernel: [  365.565176] RIP: 
e030:[<ffffffff8106e08c>]  [<ffffffff8106e08c>] kthread_data+0xc/0x20
Sep  6 13:26:24 pc kernel: [  365.565194] RSP: e02b:ffff88012e7aba90  
EFLAGS: 00010092
Sep  6 13:26:24 pc kernel: [  365.565205] RAX: 0000000000000000 RBX: 
0000000000000002 RCX: 0000000000000002
Sep  6 13:26:24 pc kernel: [  365.565219] RDX: ffffffff81fcba40 RSI: 
0000000000000002 RDI: ffff88013101c440
Sep  6 13:26:24 pc kernel: [  365.565233] RBP: ffff88012e7abaa8 R08: 
0000000000989680 R09: ffffffff81fcba40
Sep  6 13:26:24 pc kernel: [  365.565248] R10: ffffffff813b0c00 R11: 
0000000000000000 R12: ffff8801406536c0
Sep  6 13:26:24 pc kernel: [  365.565262] R13: 0000000000000002 R14: 
ffff88013101c430 R15: ffff88013101c440
Sep  6 13:26:24 pc kernel: [  365.565280] FS:  00007f79d32ce700(0000) 
GS:ffff880140640000(0000) knlGS:0000000000000000
Sep  6 13:26:24 pc kernel: [  365.565293] CS:  e033 DS: 0000 ES: 0000 
CR0: 000000008005003b
Sep  6 13:26:24 pc kernel: [  365.565303] CR2: fffffffffffffff8 CR3: 
0000000001e0c000 CR4: 0000000000002660
Sep  6 13:26:24 pc kernel: [  365.565318] DR0: 0000000000000000 DR1: 
0000000000000000 DR2: 0000000000000000
Sep  6 13:26:24 pc kernel: [  365.565332] DR3: 0000000000000000 DR6: 
00000000ffff0ff0 DR7: 0000000000000400
Sep  6 13:26:24 pc kernel: [  365.565349] Process kworker/2:1 (pid: 
1208, threadinfo ffff88012e7aa000, task ffff88013101
c440)
Sep  6 13:26:24 pc kernel: [  365.565362] Stack:
Sep  6 13:26:24 pc kernel: [  365.565367]  ffffffff810698e0 
ffff88012e7abaa8 ffff88013101c818 ffff88012e7abb18
Sep  6 13:26:24 pc kernel: [  365.565389]  ffffffff8184ae02 
ffff88012e7abfd8 ffff88013101c440 ffff88012e7abfd8
Sep  6 13:26:24 pc kernel: [  365.565410]  ffff88012e7abfd8 
ffff88012d8840c0 ffff88013101c440 ffff88013101ca30



Perhaps this stacktrace helps...

Thanks!

Am 05.09.2012 20:54, schrieb Konrad Rzeszutek Wilk:
>> > > > And its due to a patch I added in v3.4
>> > > > (cd9db80e5257682a7f7ab245a2459648b3c8d268)
>> > > > - which did not work properly in v3.4, but with v3.5 got it 
>> working
>> > > > (977f857ca566a1e68045fcbb7cfc9c4acb077cf0) which causes v3.5 
>> to
>> > now
>> > > > work
>> > > > anymore.
>> > > >
>> > > > Anyhow, for right now jsut revert
>> > > > cd9db80e5257682a7f7ab245a2459648b3c8d268
>> > > > and it should work for you.
>> > > >
>> Confirmed, after reverting that commit, VT-d will work fine.
>> Will you fix this and push it to upstream Linux, Konrad?
>>
>> > > Also, our team reported a VT-d bug 2 months ago.
>> > > http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1824
>> >
>
> Can either one of you please test this patch, please:
>
>
> diff --git a/drivers/xen/xen-pciback/pci_stub.c
> b/drivers/xen/xen-pciback/pci_stub.c
> index 097e536..425bd0b 100644
> --- a/drivers/xen/xen-pciback/pci_stub.c
> +++ b/drivers/xen/xen-pciback/pci_stub.c
> @@ -4,6 +4,8 @@
>   * Ryan Wilson <hap9@epoch.ncsc.mil>
>   * Chris Bookholt <hap10@epoch.ncsc.mil>
>   */
> +#define DEBUG 1
> +
>  #include <linux/module.h>
>  #include <linux/init.h>
>  #include <linux/rwsem.h>
> @@ -97,13 +99,15 @@ static void pcistub_device_release(struct kref 
> *kref)
>  	/* Call the reset function which does not take lock as this
>  	 * is called from "unbind" which takes a device_lock mutex.
>  	 */
> +	dev_dbg(&psdev->dev->dev, "FLR locked..\n");
>  	__pci_reset_function_locked(psdev->dev);
>  	if (pci_load_and_free_saved_state(psdev->dev,
>  					  &dev_data->pci_saved_state)) {
>  		dev_dbg(&psdev->dev->dev, "Could not reload PCI state\n");
> -	} else
> +	} else {
> +		dev_dbg(&psdev->dev->dev, "Reloading PCI state..\n");
>  		pci_restore_state(psdev->dev);
> -
> +	}
>  	/* Disable the device */
>  	xen_pcibk_reset_device(psdev->dev);
>
> @@ -353,16 +357,16 @@ static int __devinit pcistub_init_device(struct
> pci_dev *dev)
>  	if (err)
>  		goto config_release;
>
> -	dev_dbg(&dev->dev, "reseting (FLR, D3, etc) the device\n");
> -	__pci_reset_function_locked(dev);
> -
>  	/* We need the device active to save the state. */
>  	dev_dbg(&dev->dev, "save state of device\n");
>  	pci_save_state(dev);
>  	dev_data->pci_saved_state = pci_store_saved_state(dev);
>  	if (!dev_data->pci_saved_state)
>  		dev_err(&dev->dev, "Could not store PCI conf saved state!\n");
> -
> +	else {
> +		dev_dbg(&dev->dev, "reseting (FLR, D3, etc) the device\n");
> +		__pci_reset_function_locked(dev);
> +	}
>  	/* Now disable the device (this also ensures some private device
>  	 * data is setup before we export)
>  	 */


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

From xen-devel-bounces@lists.xen.org Thu Sep 06 11:28:22 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 2012 11:28:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9aFn-0001Np-LT; Thu, 06 Sep 2012 11:28:11 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <tobias.geiger@vido.info>) id 1T9aFm-0001Nh-1k
	for xen-devel@lists.xen.org; Thu, 06 Sep 2012 11:28:10 +0000
Received: from [85.158.139.83:43569] by server-9.bemta-5.messagelabs.com id
	39/1C-20529-9C888405; Thu, 06 Sep 2012 11:28:09 +0000
X-Env-Sender: tobias.geiger@vido.info
X-Msg-Ref: server-9.tower-182.messagelabs.com!1346930888!28249186!1
X-Originating-IP: [78.47.43.170]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
	MAILTO_TO_SPAM_ADDR,SUBJECT_EXCESS_QP,UNPARSEABLE_RELAY
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17648 invoked from network); 6 Sep 2012 11:28:08 -0000
Received: from mail.vido.info (HELO mail.vido.info) (78.47.43.170)
	by server-9.tower-182.messagelabs.com with SMTP;
	6 Sep 2012 11:28:08 -0000
Received: from localhost (ip6-localhost [127.0.0.1])
	by mail.vido.info (Postfix) with ESMTP id E9D0DD3429D;
	Thu,  6 Sep 2012 13:28:07 +0200 (CEST)
X-Virus-Scanned: by amavis at mail.vido.info
Received: from mail.vido.info ([127.0.0.1])
	by localhost (mail.vido.info [127.0.0.1]) (amavisd-new, port 10024)
	with LMTP id gGrWlujlG8q2; Thu,  6 Sep 2012 13:28:01 +0200 (CEST)
Received: from www.vido.info (www.vido.info [78.47.43.171])
	by mail.vido.info (Postfix) with ESMTP id 034C7D34290;
	Thu,  6 Sep 2012 13:28:01 +0200 (CEST)
Received: from A08X7SPVzjnaJkW+7cCX53ocxut7je+ERMSBHlcK3+KOUxlhwVVwlA==
	(SuRgyhmAslcido4lHmoqR+vf8zrnQIUF) by www.vido.info
	with HTTP (HTTP/1.1 POST); Thu, 06 Sep 2012 13:28:00 +0200
MIME-Version: 1.0
Date: Thu, 06 Sep 2012 13:28:00 +0200
From: Tobias Geiger <tobias.geiger@vido.info>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
In-Reply-To: <20120905185412.GA27077@phenom.dumpdata.com>
References: <1B4B44D9196EFF41AE41FDA404FC0A101881CE@SHSMSX101.ccr.corp.intel.com>
	<20120905185412.GA27077@phenom.dumpdata.com>
Message-ID: <f74e17a2c22339a3eb0439a03bef10b1@vido.info>
X-Sender: tobias.geiger@vido.info
User-Agent: Roundcube Webmail
Cc: Konrad Rzeszutek Wilk <konrad@kernel.org>, "Ren,
	Yongjie" <yongjie.ren@intel.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel]
 =?utf-8?q?Regression_in_kernel_3=2E5_as_Dom0_regardin?=
 =?utf-8?q?g_PCI_Passthrough=3F!?=
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
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 Konrad,

the patch helps regarding the USB-PCIController-Passthrough - this 
works now in DomU.

but i still get the Dom0 crash when shutting down DomU:

Sep  6 13:26:19 pc kernel: [  361.011514] 
xen-blkback:backend/vbd/1/832: prepare for reconnect
Sep  6 13:26:20 pc kernel: [  361.876395] 
xen-blkback:backend/vbd/1/768: prepare for reconnect
Sep  6 13:26:21 pc kernel: [  362.682152] br0: port 3(vif1.0) entered 
disabled state
Sep  6 13:26:21 pc kernel: [  362.682267] br0: port 3(vif1.0) entered 
disabled state
Sep  6 13:26:24 pc kernel: [  365.541386] ------------[ cut here 
]------------
Sep  6 13:26:24 pc kernel: [  365.541411] invalid opcode: 0000 [#1] 
PREEMPT SMP
Sep  6 13:26:24 pc kernel: [  365.541423] CPU 2
Sep  6 13:26:24 pc kernel: [  365.541427] Modules linked in: uvcvideo 
snd_usb_audio snd_usbmidi_lib snd_seq_midi snd_hwd
ep snd_rawmidi videobuf2_vmalloc videobuf2_memops videobuf2_core 
videodev gpio_ich joydev hid_generic [last unloaded: sc
si_wait_scan]
Sep  6 13:26:24 pc kernel: [  365.541474]
Sep  6 13:26:24 pc kernel: [  365.541477] Pid: 1208, comm: kworker/2:1 
Not tainted 3.5.0 #3                  /DX58SO
Sep  6 13:26:24 pc kernel: [  365.541491] RIP: 
e030:[<ffffffff81447f95>]  [<ffffffff81447f95>] 
balloon_process+0x385/0x3
a0
Sep  6 13:26:24 pc kernel: [  365.541507] RSP: e02b:ffff88012e7abdc0  
EFLAGS: 00010213
Sep  6 13:26:24 pc kernel: [  365.541515] RAX: 0000000220be7000 RBX: 
0000000000000000 RCX: 0000000000000008
Sep  6 13:26:24 pc kernel: [  365.541523] RDX: ffff88010d99a000 RSI: 
00000000000001df RDI: 000000000020efdf
Sep  6 13:26:24 pc kernel: [  365.541532] RBP: ffff88012e7abe20 R08: 
ffff88014064e140 R09: 00000000fffffffe
Sep  6 13:26:24 pc kernel: [  365.541540] R10: 0000000000000001 R11: 
0000000000000000 R12: 0000160000000000
Sep  6 13:26:24 pc kernel: [  365.541548] R13: 0000000000000001 R14: 
000000000020efdf R15: ffffea00083bf7c0
Sep  6 13:26:24 pc kernel: [  365.541561] FS:  00007f79d32ce700(0000) 
GS:ffff880140640000(0000) knlGS:0000000000000000
Sep  6 13:26:24 pc kernel: [  365.541571] CS:  e033 DS: 0000 ES: 0000 
CR0: 000000008005003b
Sep  6 13:26:24 pc kernel: [  365.541578] CR2: 00007f79d2d6ce02 CR3: 
0000000001e0c000 CR4: 0000000000002660
Sep  6 13:26:24 pc kernel: [  365.541587] DR0: 0000000000000000 DR1: 
0000000000000000 DR2: 0000000000000000
Sep  6 13:26:24 pc kernel: [  365.541596] DR3: 0000000000000000 DR6: 
00000000ffff0ff0 DR7: 0000000000000400
Sep  6 13:26:24 pc kernel: [  365.541604] Process kworker/2:1 (pid: 
1208, threadinfo ffff88012e7aa000, task ffff88013101
c440)
Sep  6 13:26:24 pc kernel: [  365.541613] Stack:
Sep  6 13:26:24 pc kernel: [  365.541618]  000000000006877b 
0000000000000001 ffffffff8200ea80 0000000000000001
Sep  6 13:26:24 pc kernel: [  365.541649]  0000000000000000 
0000000000007ff0 ffff88012e7abe00 ffff8801302eee00
Sep  6 13:26:24 pc kernel: [  365.541664]  ffff880140657000 
ffff88014064e140 0000000000000000 ffffffff81e587c0
Sep  6 13:26:24 pc kernel: [  365.541679] Call Trace:
Sep  6 13:26:24 pc kernel: [  365.541688]  [<ffffffff8106753b>] 
process_one_work+0x12b/0x450
Sep  6 13:26:24 pc kernel: [  365.541697]  [<ffffffff81447c10>] ? 
decrease_reservation+0x320/0x320
Sep  6 13:26:24 pc kernel: [  365.541706]  [<ffffffff810688be>] 
worker_thread+0x12e/0x2d0
Sep  6 13:26:24 pc kernel: [  365.541715]  [<ffffffff81068790>] ? 
manage_workers.isra.26+0x1f0/0x1f0
Sep  6 13:26:24 pc kernel: [  365.541725]  [<ffffffff8106db7e>] 
kthread+0x8e/0xa0
Sep  6 13:26:24 pc kernel: [  365.541735]  [<ffffffff8184e3e4>] 
kernel_thread_helper+0x4/0x10
Sep  6 13:26:24 pc kernel: [  365.541745]  [<ffffffff8184c87c>] ? 
retint_restore_args+0x5/0x6
Sep  6 13:26:24 pc kernel: [  365.541754]  [<ffffffff8184e3e0>] ? 
gs_change+0x13/0x13
Sep  6 13:26:24 pc kernel: [  365.541760] Code: 01 15 f0 6a bc 00 48 29 
d0 48 89 05 ee 6a bc 00 e9 31 fd ff ff 0f 0b 0f
0b 4c 89 f7 e8 85 34 bc ff 48 83 f8 ff 0f 84 2b fe ff ff <0f> 0b 66 0f 
1f 84 00 00 00 00 00 48 83 c1 01 e9 c2 fd ff ff 0
f
Sep  6 13:26:24 pc kernel: [  365.541898]  RSP <ffff88012e7abdc0>
Sep  6 13:26:24 pc kernel: [  365.565054] ---[ end trace 
25eb9ce0cc61c3a1 ]---
Sep  6 13:26:24 pc kernel: [  365.565101] PGD 1e0e067 PUD 1e0f067 PMD 0
Sep  6 13:26:24 pc kernel: [  365.565108] Oops: 0000 [#2] PREEMPT SMP
Sep  6 13:26:24 pc kernel: [  365.565115] CPU 2
Sep  6 13:26:24 pc kernel: [  365.565118] Modules linked in: uvcvideo 
snd_usb_audio snd_usbmidi_lib snd_seq_midi snd_hwd
ep snd_rawmidi videobuf2_vmalloc videobuf2_memops videobuf2_core 
videodev gpio_ich joydev hid_generic [last unloaded: sc
si_wait_scan]
Sep  6 13:26:24 pc kernel: [  365.565153]
Sep  6 13:26:24 pc kernel: [  365.565156] Pid: 1208, comm: kworker/2:1 
Tainted: G      D      3.5.0 #3
/DX58SO
Sep  6 13:26:24 pc kernel: [  365.565176] RIP: 
e030:[<ffffffff8106e08c>]  [<ffffffff8106e08c>] kthread_data+0xc/0x20
Sep  6 13:26:24 pc kernel: [  365.565194] RSP: e02b:ffff88012e7aba90  
EFLAGS: 00010092
Sep  6 13:26:24 pc kernel: [  365.565205] RAX: 0000000000000000 RBX: 
0000000000000002 RCX: 0000000000000002
Sep  6 13:26:24 pc kernel: [  365.565219] RDX: ffffffff81fcba40 RSI: 
0000000000000002 RDI: ffff88013101c440
Sep  6 13:26:24 pc kernel: [  365.565233] RBP: ffff88012e7abaa8 R08: 
0000000000989680 R09: ffffffff81fcba40
Sep  6 13:26:24 pc kernel: [  365.565248] R10: ffffffff813b0c00 R11: 
0000000000000000 R12: ffff8801406536c0
Sep  6 13:26:24 pc kernel: [  365.565262] R13: 0000000000000002 R14: 
ffff88013101c430 R15: ffff88013101c440
Sep  6 13:26:24 pc kernel: [  365.565280] FS:  00007f79d32ce700(0000) 
GS:ffff880140640000(0000) knlGS:0000000000000000
Sep  6 13:26:24 pc kernel: [  365.565293] CS:  e033 DS: 0000 ES: 0000 
CR0: 000000008005003b
Sep  6 13:26:24 pc kernel: [  365.565303] CR2: fffffffffffffff8 CR3: 
0000000001e0c000 CR4: 0000000000002660
Sep  6 13:26:24 pc kernel: [  365.565318] DR0: 0000000000000000 DR1: 
0000000000000000 DR2: 0000000000000000
Sep  6 13:26:24 pc kernel: [  365.565332] DR3: 0000000000000000 DR6: 
00000000ffff0ff0 DR7: 0000000000000400
Sep  6 13:26:24 pc kernel: [  365.565349] Process kworker/2:1 (pid: 
1208, threadinfo ffff88012e7aa000, task ffff88013101
c440)
Sep  6 13:26:24 pc kernel: [  365.565362] Stack:
Sep  6 13:26:24 pc kernel: [  365.565367]  ffffffff810698e0 
ffff88012e7abaa8 ffff88013101c818 ffff88012e7abb18
Sep  6 13:26:24 pc kernel: [  365.565389]  ffffffff8184ae02 
ffff88012e7abfd8 ffff88013101c440 ffff88012e7abfd8
Sep  6 13:26:24 pc kernel: [  365.565410]  ffff88012e7abfd8 
ffff88012d8840c0 ffff88013101c440 ffff88013101ca30



Perhaps this stacktrace helps...

Thanks!

Am 05.09.2012 20:54, schrieb Konrad Rzeszutek Wilk:
>> > > > And its due to a patch I added in v3.4
>> > > > (cd9db80e5257682a7f7ab245a2459648b3c8d268)
>> > > > - which did not work properly in v3.4, but with v3.5 got it 
>> working
>> > > > (977f857ca566a1e68045fcbb7cfc9c4acb077cf0) which causes v3.5 
>> to
>> > now
>> > > > work
>> > > > anymore.
>> > > >
>> > > > Anyhow, for right now jsut revert
>> > > > cd9db80e5257682a7f7ab245a2459648b3c8d268
>> > > > and it should work for you.
>> > > >
>> Confirmed, after reverting that commit, VT-d will work fine.
>> Will you fix this and push it to upstream Linux, Konrad?
>>
>> > > Also, our team reported a VT-d bug 2 months ago.
>> > > http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1824
>> >
>
> Can either one of you please test this patch, please:
>
>
> diff --git a/drivers/xen/xen-pciback/pci_stub.c
> b/drivers/xen/xen-pciback/pci_stub.c
> index 097e536..425bd0b 100644
> --- a/drivers/xen/xen-pciback/pci_stub.c
> +++ b/drivers/xen/xen-pciback/pci_stub.c
> @@ -4,6 +4,8 @@
>   * Ryan Wilson <hap9@epoch.ncsc.mil>
>   * Chris Bookholt <hap10@epoch.ncsc.mil>
>   */
> +#define DEBUG 1
> +
>  #include <linux/module.h>
>  #include <linux/init.h>
>  #include <linux/rwsem.h>
> @@ -97,13 +99,15 @@ static void pcistub_device_release(struct kref 
> *kref)
>  	/* Call the reset function which does not take lock as this
>  	 * is called from "unbind" which takes a device_lock mutex.
>  	 */
> +	dev_dbg(&psdev->dev->dev, "FLR locked..\n");
>  	__pci_reset_function_locked(psdev->dev);
>  	if (pci_load_and_free_saved_state(psdev->dev,
>  					  &dev_data->pci_saved_state)) {
>  		dev_dbg(&psdev->dev->dev, "Could not reload PCI state\n");
> -	} else
> +	} else {
> +		dev_dbg(&psdev->dev->dev, "Reloading PCI state..\n");
>  		pci_restore_state(psdev->dev);
> -
> +	}
>  	/* Disable the device */
>  	xen_pcibk_reset_device(psdev->dev);
>
> @@ -353,16 +357,16 @@ static int __devinit pcistub_init_device(struct
> pci_dev *dev)
>  	if (err)
>  		goto config_release;
>
> -	dev_dbg(&dev->dev, "reseting (FLR, D3, etc) the device\n");
> -	__pci_reset_function_locked(dev);
> -
>  	/* We need the device active to save the state. */
>  	dev_dbg(&dev->dev, "save state of device\n");
>  	pci_save_state(dev);
>  	dev_data->pci_saved_state = pci_store_saved_state(dev);
>  	if (!dev_data->pci_saved_state)
>  		dev_err(&dev->dev, "Could not store PCI conf saved state!\n");
> -
> +	else {
> +		dev_dbg(&dev->dev, "reseting (FLR, D3, etc) the device\n");
> +		__pci_reset_function_locked(dev);
> +	}
>  	/* Now disable the device (this also ensures some private device
>  	 * data is setup before we export)
>  	 */


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

From xen-devel-bounces@lists.xen.org Thu Sep 06 11:33:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 2012 11:33:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9aKQ-0001Zl-1F; Thu, 06 Sep 2012 11:32:58 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <tobias.geiger@vido.info>) id 1T9aKN-0001ZY-UN
	for xen-devel@lists.xen.org; Thu, 06 Sep 2012 11:32:56 +0000
Received: from [85.158.138.51:45952] by server-3.bemta-3.messagelabs.com id
	53/64-21322-7E988405; Thu, 06 Sep 2012 11:32:55 +0000
X-Env-Sender: tobias.geiger@vido.info
X-Msg-Ref: server-16.tower-174.messagelabs.com!1346931174!28934552!1
X-Originating-IP: [78.47.43.170]
X-SpamReason: No, hits=0.3 required=7.0 tests=MAILTO_TO_SPAM_ADDR,
	SUBJECT_EXCESS_QP,UNPARSEABLE_RELAY
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9934 invoked from network); 6 Sep 2012 11:32:54 -0000
Received: from mail.vido.info (HELO mail.vido.info) (78.47.43.170)
	by server-16.tower-174.messagelabs.com with SMTP;
	6 Sep 2012 11:32:54 -0000
Received: from localhost (ip6-localhost [127.0.0.1])
	by mail.vido.info (Postfix) with ESMTP id C975DD342A2;
	Thu,  6 Sep 2012 13:32:53 +0200 (CEST)
X-Virus-Scanned: by amavis at mail.vido.info
Received: from mail.vido.info ([127.0.0.1])
	by localhost (mail.vido.info [127.0.0.1]) (amavisd-new, port 10024)
	with LMTP id WIOn184zI1ll; Thu,  6 Sep 2012 13:32:47 +0200 (CEST)
Received: from www.vido.info (www.vido.info [78.47.43.171])
	by mail.vido.info (Postfix) with ESMTP id 9E11BD342A0;
	Thu,  6 Sep 2012 13:32:47 +0200 (CEST)
Received: from RLjs5EFv7bhTxS5GZzWNjIOjic5nwfdwcsuXHMZFoimmMQt7i0GWZA==
	(zcosvS8rfSIC6XgDGgELHSn6DBzSmB+F) by www.vido.info
	with HTTP (HTTP/1.1 POST); Thu, 06 Sep 2012 13:32:47 +0200
MIME-Version: 1.0
Date: Thu, 06 Sep 2012 13:32:47 +0200
From: Tobias Geiger <tobias.geiger@vido.info>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
In-Reply-To: <20120905185412.GA27077@phenom.dumpdata.com>
References: <1B4B44D9196EFF41AE41FDA404FC0A101881CE@SHSMSX101.ccr.corp.intel.com>
	<20120905185412.GA27077@phenom.dumpdata.com>
Message-ID: <553cc0393c35dc3aff8ffa040b96831a@vido.info>
X-Sender: tobias.geiger@vido.info
User-Agent: Roundcube Webmail
Cc: Konrad Rzeszutek Wilk <konrad@kernel.org>, "Ren,
	Yongjie" <yongjie.ren@intel.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel]
 =?utf-8?q?Regression_in_kernel_3=2E5_as_Dom0_regardin?=
 =?utf-8?q?g_PCI_Passthrough=3F!?=
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

FYI:

This Dom0-Crash only happens, when i shuttdown the DomU within the 
DomU, meaning when i choose "Start - Shutdown" within Windows7.
The Crash does NOT happen, when i do "xl shutdown domu" ... ?! :)

Greetings
Tobias

Am 05.09.2012 20:54, schrieb Konrad Rzeszutek Wilk:
>> > > > And its due to a patch I added in v3.4
>> > > > (cd9db80e5257682a7f7ab245a2459648b3c8d268)
>> > > > - which did not work properly in v3.4, but with v3.5 got it 
>> working
>> > > > (977f857ca566a1e68045fcbb7cfc9c4acb077cf0) which causes v3.5 
>> to
>> > now
>> > > > work
>> > > > anymore.
>> > > >
>> > > > Anyhow, for right now jsut revert
>> > > > cd9db80e5257682a7f7ab245a2459648b3c8d268
>> > > > and it should work for you.
>> > > >
>> Confirmed, after reverting that commit, VT-d will work fine.
>> Will you fix this and push it to upstream Linux, Konrad?
>>
>> > > Also, our team reported a VT-d bug 2 months ago.
>> > > http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1824
>> >
>
> Can either one of you please test this patch, please:
>
>
> diff --git a/drivers/xen/xen-pciback/pci_stub.c
> b/drivers/xen/xen-pciback/pci_stub.c
> index 097e536..425bd0b 100644
> --- a/drivers/xen/xen-pciback/pci_stub.c
> +++ b/drivers/xen/xen-pciback/pci_stub.c
> @@ -4,6 +4,8 @@
>   * Ryan Wilson <hap9@epoch.ncsc.mil>
>   * Chris Bookholt <hap10@epoch.ncsc.mil>
>   */
> +#define DEBUG 1
> +
>  #include <linux/module.h>
>  #include <linux/init.h>
>  #include <linux/rwsem.h>
> @@ -97,13 +99,15 @@ static void pcistub_device_release(struct kref 
> *kref)
>  	/* Call the reset function which does not take lock as this
>  	 * is called from "unbind" which takes a device_lock mutex.
>  	 */
> +	dev_dbg(&psdev->dev->dev, "FLR locked..\n");
>  	__pci_reset_function_locked(psdev->dev);
>  	if (pci_load_and_free_saved_state(psdev->dev,
>  					  &dev_data->pci_saved_state)) {
>  		dev_dbg(&psdev->dev->dev, "Could not reload PCI state\n");
> -	} else
> +	} else {
> +		dev_dbg(&psdev->dev->dev, "Reloading PCI state..\n");
>  		pci_restore_state(psdev->dev);
> -
> +	}
>  	/* Disable the device */
>  	xen_pcibk_reset_device(psdev->dev);
>
> @@ -353,16 +357,16 @@ static int __devinit pcistub_init_device(struct
> pci_dev *dev)
>  	if (err)
>  		goto config_release;
>
> -	dev_dbg(&dev->dev, "reseting (FLR, D3, etc) the device\n");
> -	__pci_reset_function_locked(dev);
> -
>  	/* We need the device active to save the state. */
>  	dev_dbg(&dev->dev, "save state of device\n");
>  	pci_save_state(dev);
>  	dev_data->pci_saved_state = pci_store_saved_state(dev);
>  	if (!dev_data->pci_saved_state)
>  		dev_err(&dev->dev, "Could not store PCI conf saved state!\n");
> -
> +	else {
> +		dev_dbg(&dev->dev, "reseting (FLR, D3, etc) the device\n");
> +		__pci_reset_function_locked(dev);
> +	}
>  	/* Now disable the device (this also ensures some private device
>  	 * data is setup before we export)
>  	 */


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

From xen-devel-bounces@lists.xen.org Thu Sep 06 11:33:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 2012 11:33:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9aKQ-0001Zl-1F; Thu, 06 Sep 2012 11:32:58 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <tobias.geiger@vido.info>) id 1T9aKN-0001ZY-UN
	for xen-devel@lists.xen.org; Thu, 06 Sep 2012 11:32:56 +0000
Received: from [85.158.138.51:45952] by server-3.bemta-3.messagelabs.com id
	53/64-21322-7E988405; Thu, 06 Sep 2012 11:32:55 +0000
X-Env-Sender: tobias.geiger@vido.info
X-Msg-Ref: server-16.tower-174.messagelabs.com!1346931174!28934552!1
X-Originating-IP: [78.47.43.170]
X-SpamReason: No, hits=0.3 required=7.0 tests=MAILTO_TO_SPAM_ADDR,
	SUBJECT_EXCESS_QP,UNPARSEABLE_RELAY
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9934 invoked from network); 6 Sep 2012 11:32:54 -0000
Received: from mail.vido.info (HELO mail.vido.info) (78.47.43.170)
	by server-16.tower-174.messagelabs.com with SMTP;
	6 Sep 2012 11:32:54 -0000
Received: from localhost (ip6-localhost [127.0.0.1])
	by mail.vido.info (Postfix) with ESMTP id C975DD342A2;
	Thu,  6 Sep 2012 13:32:53 +0200 (CEST)
X-Virus-Scanned: by amavis at mail.vido.info
Received: from mail.vido.info ([127.0.0.1])
	by localhost (mail.vido.info [127.0.0.1]) (amavisd-new, port 10024)
	with LMTP id WIOn184zI1ll; Thu,  6 Sep 2012 13:32:47 +0200 (CEST)
Received: from www.vido.info (www.vido.info [78.47.43.171])
	by mail.vido.info (Postfix) with ESMTP id 9E11BD342A0;
	Thu,  6 Sep 2012 13:32:47 +0200 (CEST)
Received: from RLjs5EFv7bhTxS5GZzWNjIOjic5nwfdwcsuXHMZFoimmMQt7i0GWZA==
	(zcosvS8rfSIC6XgDGgELHSn6DBzSmB+F) by www.vido.info
	with HTTP (HTTP/1.1 POST); Thu, 06 Sep 2012 13:32:47 +0200
MIME-Version: 1.0
Date: Thu, 06 Sep 2012 13:32:47 +0200
From: Tobias Geiger <tobias.geiger@vido.info>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
In-Reply-To: <20120905185412.GA27077@phenom.dumpdata.com>
References: <1B4B44D9196EFF41AE41FDA404FC0A101881CE@SHSMSX101.ccr.corp.intel.com>
	<20120905185412.GA27077@phenom.dumpdata.com>
Message-ID: <553cc0393c35dc3aff8ffa040b96831a@vido.info>
X-Sender: tobias.geiger@vido.info
User-Agent: Roundcube Webmail
Cc: Konrad Rzeszutek Wilk <konrad@kernel.org>, "Ren,
	Yongjie" <yongjie.ren@intel.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel]
 =?utf-8?q?Regression_in_kernel_3=2E5_as_Dom0_regardin?=
 =?utf-8?q?g_PCI_Passthrough=3F!?=
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

FYI:

This Dom0-Crash only happens, when i shuttdown the DomU within the 
DomU, meaning when i choose "Start - Shutdown" within Windows7.
The Crash does NOT happen, when i do "xl shutdown domu" ... ?! :)

Greetings
Tobias

Am 05.09.2012 20:54, schrieb Konrad Rzeszutek Wilk:
>> > > > And its due to a patch I added in v3.4
>> > > > (cd9db80e5257682a7f7ab245a2459648b3c8d268)
>> > > > - which did not work properly in v3.4, but with v3.5 got it 
>> working
>> > > > (977f857ca566a1e68045fcbb7cfc9c4acb077cf0) which causes v3.5 
>> to
>> > now
>> > > > work
>> > > > anymore.
>> > > >
>> > > > Anyhow, for right now jsut revert
>> > > > cd9db80e5257682a7f7ab245a2459648b3c8d268
>> > > > and it should work for you.
>> > > >
>> Confirmed, after reverting that commit, VT-d will work fine.
>> Will you fix this and push it to upstream Linux, Konrad?
>>
>> > > Also, our team reported a VT-d bug 2 months ago.
>> > > http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1824
>> >
>
> Can either one of you please test this patch, please:
>
>
> diff --git a/drivers/xen/xen-pciback/pci_stub.c
> b/drivers/xen/xen-pciback/pci_stub.c
> index 097e536..425bd0b 100644
> --- a/drivers/xen/xen-pciback/pci_stub.c
> +++ b/drivers/xen/xen-pciback/pci_stub.c
> @@ -4,6 +4,8 @@
>   * Ryan Wilson <hap9@epoch.ncsc.mil>
>   * Chris Bookholt <hap10@epoch.ncsc.mil>
>   */
> +#define DEBUG 1
> +
>  #include <linux/module.h>
>  #include <linux/init.h>
>  #include <linux/rwsem.h>
> @@ -97,13 +99,15 @@ static void pcistub_device_release(struct kref 
> *kref)
>  	/* Call the reset function which does not take lock as this
>  	 * is called from "unbind" which takes a device_lock mutex.
>  	 */
> +	dev_dbg(&psdev->dev->dev, "FLR locked..\n");
>  	__pci_reset_function_locked(psdev->dev);
>  	if (pci_load_and_free_saved_state(psdev->dev,
>  					  &dev_data->pci_saved_state)) {
>  		dev_dbg(&psdev->dev->dev, "Could not reload PCI state\n");
> -	} else
> +	} else {
> +		dev_dbg(&psdev->dev->dev, "Reloading PCI state..\n");
>  		pci_restore_state(psdev->dev);
> -
> +	}
>  	/* Disable the device */
>  	xen_pcibk_reset_device(psdev->dev);
>
> @@ -353,16 +357,16 @@ static int __devinit pcistub_init_device(struct
> pci_dev *dev)
>  	if (err)
>  		goto config_release;
>
> -	dev_dbg(&dev->dev, "reseting (FLR, D3, etc) the device\n");
> -	__pci_reset_function_locked(dev);
> -
>  	/* We need the device active to save the state. */
>  	dev_dbg(&dev->dev, "save state of device\n");
>  	pci_save_state(dev);
>  	dev_data->pci_saved_state = pci_store_saved_state(dev);
>  	if (!dev_data->pci_saved_state)
>  		dev_err(&dev->dev, "Could not store PCI conf saved state!\n");
> -
> +	else {
> +		dev_dbg(&dev->dev, "reseting (FLR, D3, etc) the device\n");
> +		__pci_reset_function_locked(dev);
> +	}
>  	/* Now disable the device (this also ensures some private device
>  	 * data is setup before we export)
>  	 */


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

From xen-devel-bounces@lists.xen.org Thu Sep 06 11:36:27 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 2012 11: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 1T9aNa-0001ur-Qd; Thu, 06 Sep 2012 11:36:14 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1T9aNZ-0001uk-5z
	for xen-devel@lists.xen.org; Thu, 06 Sep 2012 11:36:13 +0000
Received: from [85.158.138.51:15856] by server-11.bemta-3.messagelabs.com id
	05/AE-30250-CAA88405; Thu, 06 Sep 2012 11:36:12 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-11.tower-174.messagelabs.com!1346931362!29017918!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19437 invoked from network); 6 Sep 2012 11:36:02 -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; 6 Sep 2012 11:36:02 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1T9aNN-000F9K-HZ; Thu, 06 Sep 2012 11:36:01 +0000
Date: Thu, 6 Sep 2012 12:36:01 +0100
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <ian.campbell@citrix.com>
Message-ID: <20120906113601.GD56463@ocelot.phlegethon.org>
References: <1346678886.32462.9.camel@zakaz.uk.xensource.com>
	<1346679056-8108-4-git-send-email-ian.campbell@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1346679056-8108-4-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 04/16] arm: handle xenheap which isn't at
	the start of RAM.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At 13:30 +0000 on 03 Sep (1346679044), Ian Campbell wrote:
> Also refactor page_to_virt somewhat in an attempt to make it clearer
> what is happening.
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> ---
>  xen/include/asm-arm/mm.h |   24 +++++++++++++++++++-----
>  1 files changed, 19 insertions(+), 5 deletions(-)
> 
> diff --git a/xen/include/asm-arm/mm.h b/xen/include/asm-arm/mm.h
> index b37bd35..6498322 100644
> --- a/xen/include/asm-arm/mm.h
> +++ b/xen/include/asm-arm/mm.h
> @@ -214,17 +214,31 @@ static inline struct page_info *virt_to_page(const void *v)
>      ASSERT(va >= XENHEAP_VIRT_START);
>      ASSERT(va < xenheap_virt_end);
>  
> -    return frame_table + ((va - XENHEAP_VIRT_START) >> PAGE_SHIFT);
> +    return frame_table
> +        + ((va - XENHEAP_VIRT_START) >> PAGE_SHIFT)
> +        + xenheap_mfn_start
> +        - frametable_base_mfn;
>  }
>  
>  static inline void *page_to_virt(const struct page_info *pg)
>  {
> +    unsigned long va;
> +    const unsigned long offset =
> +        (xenheap_mfn_start-frametable_base_mfn)*sizeof(*pg);
> +
> +    /*
> +     * Dividing by this on both top and bottom factors out the largest
> +     * common factor of 2 which helps the compiler to use smaller shifts.
> +     */
> +    const unsigned long lcd = (sizeof(*pg) & -sizeof(*pg));
> +
>      ASSERT((unsigned long)pg - FRAMETABLE_VIRT_START < frametable_virt_end);
> -    return (void *)(XENHEAP_VIRT_START +
> -                    ((unsigned long)pg - FRAMETABLE_VIRT_START) /
> -                    (sizeof(*pg) / (sizeof(*pg) & -sizeof(*pg))) *
> -                    (PAGE_SIZE / (sizeof(*pg) & -sizeof(*pg))));
>  
> +    va = (unsigned long)pg;
> +    va = XENHEAP_VIRT_START +
> +        ((va - FRAMETABLE_VIRT_START - offset) / (sizeof(*pg) / lcd)) *
> +        (PAGE_SIZE / lcd);
> +    return (void *)va;

This function is getting a bit too confusing.  I think we should just
use page_to_mfn and mfn_to_virt instead: the magic lcd trick eliminates
a shift but having to construct "offset" to match it adds one.

Tim.

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

From xen-devel-bounces@lists.xen.org Thu Sep 06 11:36:27 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 2012 11: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 1T9aNa-0001ur-Qd; Thu, 06 Sep 2012 11:36:14 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1T9aNZ-0001uk-5z
	for xen-devel@lists.xen.org; Thu, 06 Sep 2012 11:36:13 +0000
Received: from [85.158.138.51:15856] by server-11.bemta-3.messagelabs.com id
	05/AE-30250-CAA88405; Thu, 06 Sep 2012 11:36:12 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-11.tower-174.messagelabs.com!1346931362!29017918!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19437 invoked from network); 6 Sep 2012 11:36:02 -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; 6 Sep 2012 11:36:02 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1T9aNN-000F9K-HZ; Thu, 06 Sep 2012 11:36:01 +0000
Date: Thu, 6 Sep 2012 12:36:01 +0100
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <ian.campbell@citrix.com>
Message-ID: <20120906113601.GD56463@ocelot.phlegethon.org>
References: <1346678886.32462.9.camel@zakaz.uk.xensource.com>
	<1346679056-8108-4-git-send-email-ian.campbell@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1346679056-8108-4-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 04/16] arm: handle xenheap which isn't at
	the start of RAM.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At 13:30 +0000 on 03 Sep (1346679044), Ian Campbell wrote:
> Also refactor page_to_virt somewhat in an attempt to make it clearer
> what is happening.
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> ---
>  xen/include/asm-arm/mm.h |   24 +++++++++++++++++++-----
>  1 files changed, 19 insertions(+), 5 deletions(-)
> 
> diff --git a/xen/include/asm-arm/mm.h b/xen/include/asm-arm/mm.h
> index b37bd35..6498322 100644
> --- a/xen/include/asm-arm/mm.h
> +++ b/xen/include/asm-arm/mm.h
> @@ -214,17 +214,31 @@ static inline struct page_info *virt_to_page(const void *v)
>      ASSERT(va >= XENHEAP_VIRT_START);
>      ASSERT(va < xenheap_virt_end);
>  
> -    return frame_table + ((va - XENHEAP_VIRT_START) >> PAGE_SHIFT);
> +    return frame_table
> +        + ((va - XENHEAP_VIRT_START) >> PAGE_SHIFT)
> +        + xenheap_mfn_start
> +        - frametable_base_mfn;
>  }
>  
>  static inline void *page_to_virt(const struct page_info *pg)
>  {
> +    unsigned long va;
> +    const unsigned long offset =
> +        (xenheap_mfn_start-frametable_base_mfn)*sizeof(*pg);
> +
> +    /*
> +     * Dividing by this on both top and bottom factors out the largest
> +     * common factor of 2 which helps the compiler to use smaller shifts.
> +     */
> +    const unsigned long lcd = (sizeof(*pg) & -sizeof(*pg));
> +
>      ASSERT((unsigned long)pg - FRAMETABLE_VIRT_START < frametable_virt_end);
> -    return (void *)(XENHEAP_VIRT_START +
> -                    ((unsigned long)pg - FRAMETABLE_VIRT_START) /
> -                    (sizeof(*pg) / (sizeof(*pg) & -sizeof(*pg))) *
> -                    (PAGE_SIZE / (sizeof(*pg) & -sizeof(*pg))));
>  
> +    va = (unsigned long)pg;
> +    va = XENHEAP_VIRT_START +
> +        ((va - FRAMETABLE_VIRT_START - offset) / (sizeof(*pg) / lcd)) *
> +        (PAGE_SIZE / lcd);
> +    return (void *)va;

This function is getting a bit too confusing.  I think we should just
use page_to_mfn and mfn_to_virt instead: the magic lcd trick eliminates
a shift but having to construct "offset" to match it adds one.

Tim.

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

From xen-devel-bounces@lists.xen.org Thu Sep 06 11:40:19 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 2012 11: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 1T9aRQ-0003AL-UA; Thu, 06 Sep 2012 11:40:12 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1T9aRP-00038b-E4
	for xen-devel@lists.xen.org; Thu, 06 Sep 2012 11:40:11 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-4.tower-27.messagelabs.com!1346931605!9300487!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 856 invoked from network); 6 Sep 2012 11:40:05 -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; 6 Sep 2012 11:40:05 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1T9aRI-000FAM-8K; Thu, 06 Sep 2012 11:40:04 +0000
Date: Thu, 6 Sep 2012 12:40:04 +0100
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <ian.campbell@citrix.com>
Message-ID: <20120906114004.GE56463@ocelot.phlegethon.org>
References: <1346678886.32462.9.camel@zakaz.uk.xensource.com>
	<1346679056-8108-5-git-send-email-ian.campbell@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1346679056-8108-5-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 05/16] arm: move get_paddr_function to arch
	setup.c from device_tree.c
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At 13:30 +0000 on 03 Sep (1346679045), Ian Campbell wrote:
> It's not realy got any DT functionality in it and its only caller is
> setup_pagetables.
> 
> Put it here because future patches want to incorporate of the module
> layout in memory and I'd like to confine that to setup.c
> 
> 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 Sep 06 11:40:19 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 2012 11: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 1T9aRQ-0003AL-UA; Thu, 06 Sep 2012 11:40:12 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1T9aRP-00038b-E4
	for xen-devel@lists.xen.org; Thu, 06 Sep 2012 11:40:11 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-4.tower-27.messagelabs.com!1346931605!9300487!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 856 invoked from network); 6 Sep 2012 11:40:05 -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; 6 Sep 2012 11:40:05 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1T9aRI-000FAM-8K; Thu, 06 Sep 2012 11:40:04 +0000
Date: Thu, 6 Sep 2012 12:40:04 +0100
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <ian.campbell@citrix.com>
Message-ID: <20120906114004.GE56463@ocelot.phlegethon.org>
References: <1346678886.32462.9.camel@zakaz.uk.xensource.com>
	<1346679056-8108-5-git-send-email-ian.campbell@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1346679056-8108-5-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 05/16] arm: move get_paddr_function to arch
	setup.c from device_tree.c
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At 13:30 +0000 on 03 Sep (1346679045), Ian Campbell wrote:
> It's not realy got any DT functionality in it and its only caller is
> setup_pagetables.
> 
> Put it here because future patches want to incorporate of the module
> layout in memory and I'd like to confine that to setup.c
> 
> 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 Sep 06 11:46:46 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 2012 11: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 1T9aXY-0004Fm-Ss; Thu, 06 Sep 2012 11:46:32 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <tobias.geiger@vido.info>) id 1T9aXX-0004Fa-Jd
	for xen-devel@lists.xen.org; Thu, 06 Sep 2012 11:46:31 +0000
Received: from [85.158.138.51:7497] by server-9.bemta-3.messagelabs.com id
	C6/5F-15390-61D88405; Thu, 06 Sep 2012 11:46:30 +0000
X-Env-Sender: tobias.geiger@vido.info
X-Msg-Ref: server-14.tower-174.messagelabs.com!1346931989!22682395!1
X-Originating-IP: [78.47.43.170]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
	MAILTO_TO_SPAM_ADDR,SUBJECT_EXCESS_QP,UNPARSEABLE_RELAY
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13830 invoked from network); 6 Sep 2012 11:46:29 -0000
Received: from mail.vido.info (HELO mail.vido.info) (78.47.43.170)
	by server-14.tower-174.messagelabs.com with SMTP;
	6 Sep 2012 11:46:29 -0000
Received: from localhost (ip6-localhost [127.0.0.1])
	by mail.vido.info (Postfix) with ESMTP id 61F0AD3429D;
	Thu,  6 Sep 2012 13:46:29 +0200 (CEST)
X-Virus-Scanned: by amavis at mail.vido.info
Received: from mail.vido.info ([127.0.0.1])
	by localhost (mail.vido.info [127.0.0.1]) (amavisd-new, port 10024)
	with LMTP id 3rB6qXsUw5Pr; Thu,  6 Sep 2012 13:46:25 +0200 (CEST)
Received: from www.vido.info (www.vido.info [78.47.43.171])
	by mail.vido.info (Postfix) with ESMTP id D68F7D34290;
	Thu,  6 Sep 2012 13:46:25 +0200 (CEST)
Received: from E3Z9zPOLZS/QATD+l1nhJ3BWJUO+kdobJUr2Fs7WQXKAvpH/8PY3uA==
	(gR1co/7ag7pSyeuym4AcWxY1jGlrDQan) by www.vido.info
	with HTTP (HTTP/1.1 POST); Thu, 06 Sep 2012 13:46:25 +0200
MIME-Version: 1.0
Date: Thu, 06 Sep 2012 13:46:25 +0200
From: Tobias Geiger <tobias.geiger@vido.info>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
In-Reply-To: <20120905185412.GA27077@phenom.dumpdata.com>
References: <1B4B44D9196EFF41AE41FDA404FC0A101881CE@SHSMSX101.ccr.corp.intel.com>
	<20120905185412.GA27077@phenom.dumpdata.com>
Message-ID: <bbe773ba08f144c0881398fc8dee456a@vido.info>
X-Sender: tobias.geiger@vido.info
User-Agent: Roundcube Webmail
Cc: Konrad Rzeszutek Wilk <konrad@kernel.org>, "Ren,
	Yongjie" <yongjie.ren@intel.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel]
 =?utf-8?q?Regression_in_kernel_3=2E5_as_Dom0_regardin?=
 =?utf-8?q?g_PCI_Passthrough=3F!?=
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

me again :)

it seems the Crash is not always a "fatal one":

[  247.080617] vif vif-2-0: 2 reading script
[  247.083519] br0: port 4(vif2.0) entered disabled state
[  247.084144] br0: port 4(vif2.0) entered disabled state
[  250.700029] ------------[ cut here ]------------
[  250.700046] kernel BUG at drivers/xen/balloon.c:359!
[  250.700059] invalid opcode: 0000 [#1] PREEMPT SMP
[  250.700071] CPU 4
[  250.700075] Modules linked in: joydev hid_generic uvcvideo 
snd_usb_audio snd_seq_midi snd_usbmidi_lib snd_hwdep snd_r
awmidi videobuf2_vmalloc videobuf2_memops videobuf2_core videodev 
gpio_ich [last unloaded: scsi_wait_scan]
[  250.700122]
[  250.700125] Pid: 23, comm: kworker/4:0 Not tainted 3.5.0 #3          
        /DX58SO
[  250.700139] RIP: e030:[<ffffffff81447f95>]  [<ffffffff81447f95>] 
balloon_process+0x385/0x3a0
[  250.700158] RSP: e02b:ffff8801317b9dc0  EFLAGS: 00010213
[  250.700162] RAX: 000000021f895000 RBX: 0000000000000000 RCX: 
0000000000000002
[  250.700167] RDX: ffffffff82027000 RSI: 0000000000000137 RDI: 
00000000000a2337
[  250.700172] RBP: ffff8801317b9e20 R08: ffff88014068e140 R09: 
00000000fffffffc
[  250.700180] R10: 0000000000000001 R11: 0000000000000000 R12: 
0000160000000000
[  250.700185] R13: 0000000000000001 R14: 00000000000a2337 R15: 
ffffea000288cdc0
[  250.700192] FS:  00007fb82ee14700(0000) GS:ffff880140680000(0000) 
knlGS:0000000000000000
[  250.700198] CS:  e033 DS: 0000 ES: 0000 CR0: 000000008005003b
[  250.700202] CR2: 00007fb82e7b39a6 CR3: 0000000001e0c000 CR4: 
0000000000002660
[  250.700207] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 
0000000000000000
[  250.700213] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 
0000000000000400
[  250.700218] Process kworker/4:0 (pid: 23, threadinfo 
ffff8801317b8000, task ffff88013178db00)
[  250.700223] Stack:
[  250.700225]  000000000006aa7b 0000000000000001 ffffffff8200ea80 
0000000000000001
[  250.700293]  0000000000000000 0000000000007ff0 ffff8801317b9e00 
ffff880131796400
[  250.700301]  ffff880140697000 ffff88014068e140 0000000000000000 
ffffffff81e587c0
[  250.700311] Call Trace:
[  250.700317]  [<ffffffff8106753b>] process_one_work+0x12b/0x450
[  250.700322]  [<ffffffff81447c10>] ? decrease_reservation+0x320/0x320
[  250.700328]  [<ffffffff810688be>] worker_thread+0x12e/0x2d0
[  250.700334]  [<ffffffff81068790>] ? 
manage_workers.isra.26+0x1f0/0x1f0
[  250.700340]  [<ffffffff8106db7e>] kthread+0x8e/0xa0
[  250.700346]  [<ffffffff8184e3e4>] kernel_thread_helper+0x4/0x10
[  250.700353]  [<ffffffff8184c87c>] ? retint_restore_args+0x5/0x6
[  250.700358]  [<ffffffff8184e3e0>] ? gs_change+0x13/0x13
[  250.700362] Code: 01 15 f0 6a bc 00 48 29 d0 48 89 05 ee 6a bc 00 e9 
31 fd ff ff 0f 0b 0f 0b 4c 89 f7 e8 85 34 bc ff
48 83 f8 ff 0f 84 2b fe ff ff <0f> 0b 66 0f 1f 84 00 00 00 00 00 48 83 
c1 01 e9 c2 fd ff ff 0f
[  250.700471] RIP  [<ffffffff81447f95>] balloon_process+0x385/0x3a0
[  250.700482]  RSP <ffff8801317b9dc0>
[  250.733955] ---[ end trace a5e5187e8ed6c1ff ]---
[  250.733982] BUG: unable to handle kernel paging request at 
fffffffffffffff8
[  250.733992] IP: [<ffffffff8106e08c>] kthread_data+0xc/0x20
[  250.733999] PGD 1e0e067 PUD 1e0f067 PMD 0
[  250.734006] Oops: 0000 [#2] PREEMPT SMP
[  250.734013] CPU 4
[  250.734016] Modules linked in: joydev hid_generic uvcvideo 
snd_usb_audio snd_seq_midi snd_usbmidi_lib snd_hwdep snd_r
awmidi videobuf2_vmalloc videobuf2_memops videobuf2_core videodev 
gpio_ich [last unloaded: scsi_wait_scan]
[  250.734071]
[  250.734073] Pid: 23, comm: kworker/4:0 Tainted: G      D      3.5.0 
#3                  /DX58SO
[  250.734095] RIP: e030:[<ffffffff8106e08c>]  [<ffffffff8106e08c>] 
kthread_data+0xc/0x20
[  250.734111] RSP: e02b:ffff8801317b9a90  EFLAGS: 00010092
[  250.734122] RAX: 0000000000000000 RBX: 0000000000000004 RCX: 
0000000000000004
[  250.734137] RDX: ffffffff81fcba40 RSI: 0000000000000004 RDI: 
ffff88013178db00
[  250.734151] RBP: ffff8801317b9aa8 R08: 0000000000989680 R09: 
ffffffff81fcba40
[  250.734166] R10: ffffffff8104960a R11: 0000000000000000 R12: 
ffff8801406936c0
[  250.734178] R13: 0000000000000004 R14: ffff88013178daf0 R15: 
ffff88013178db00
[  250.734196] FS:  00007fb82ee14700(0000) GS:ffff880140680000(0000) 
knlGS:0000000000000000
[  250.734202] CS:  e033 DS: 0000 ES: 0000 CR0: 000000008005003b
[  250.734209] CR2: fffffffffffffff8 CR3: 0000000001e0c000 CR4: 
0000000000002660
[  250.734222] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 
0000000000000000
[  250.734235] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 
0000000000000400
[  250.734249] Process kworker/4:0 (pid: 23, threadinfo 
ffff8801317b8000, task ffff88013178db00)
[  250.734266] Stack:
[  250.734271]  ffffffff810698e0 ffff8801317b9aa8 ffff88013178ded8 
ffff8801317b9b18
[  250.734292]  ffffffff8184ae02 ffff8801317b9fd8 ffff88013178db00 
ffff8801317b9fd8
[  250.734313]  ffff8801317b9fd8 ffff8801334796c0 ffff88013178db00 
ffff8801317b9ae8
[  250.734979] Call Trace:
[  250.735572]  [<ffffffff810698e0>] ? wq_worker_sleeping+0x10/0xa0
[  250.736179]  [<ffffffff8184ae02>] __schedule+0x592/0x7d0
[  250.736783]  [<ffffffff8184b164>] schedule+0x24/0x70
[  250.737373]  [<ffffffff81051592>] do_exit+0x5b2/0x910
[  250.737937]  [<ffffffff8183ea1e>] ? printk+0x48/0x4a
[  250.738498]  [<ffffffff8100ace2>] ? check_events+0x12/0x20
[  250.739053]  [<ffffffff81017581>] oops_end+0x71/0xa0
[  250.739596]  [<ffffffff810176f3>] die+0x53/0x80
[  250.740134]  [<ffffffff810143f8>] do_trap+0xb8/0x160
[  250.740668]  [<ffffffff810146f3>] do_invalid_op+0xa3/0xb0
[  250.741203]  [<ffffffff81447f95>] ? balloon_process+0x385/0x3a0
[  250.741737]  [<ffffffff81085f52>] ? load_balance+0xd2/0x800
[  250.742267]  [<ffffffff81006276>] ? xen_flush_tlb+0xd6/0x2a0
[  250.742803]  [<ffffffff8108117d>] ? cpuacct_charge+0x6d/0xb0
[  250.743332]  [<ffffffff8184e25b>] invalid_op+0x1b/0x20
[  250.743855]  [<ffffffff81447f95>] ? balloon_process+0x385/0x3a0
[  250.744374]  [<ffffffff8106753b>] process_one_work+0x12b/0x450
[  250.744897]  [<ffffffff81447c10>] ? decrease_reservation+0x320/0x320
[  250.745426]  [<ffffffff810688be>] worker_thread+0x12e/0x2d0
[  250.745942]  [<ffffffff81068790>] ? 
manage_workers.isra.26+0x1f0/0x1f0
[  250.746457]  [<ffffffff8106db7e>] kthread+0x8e/0xa0
[  250.746969]  [<ffffffff8184e3e4>] kernel_thread_helper+0x4/0x10
[  250.747480]  [<ffffffff8184c87c>] ? retint_restore_args+0x5/0x6
[  250.747990]  [<ffffffff8184e3e0>] ? gs_change+0x13/0x13
[  250.748487] Code: e0 ff ff 01 48 8b 80 38 e0 ff ff a8 08 0f 84 3d ff 
ff ff e8 57 d0 7d 00 e9 33 ff ff ff 66 90 48 8b
87 80 03 00 00 55 48 89 e5 5d <48> 8b 40 f8 c3 66 66 66 66 66 66 2e 0f 
1f 84 00 00 00 00 00 55
[  250.749575] RIP  [<ffffffff8106e08c>] kthread_data+0xc/0x20
[  250.750103]  RSP <ffff8801317b9a90>
[  250.750627] CR2: fffffffffffffff8
[  250.751151] ---[ end trace a5e5187e8ed6c200 ]---
[  250.751152] Fixing recursive fault but reboot is needed!
[  311.042233] INFO: rcu_preempt detected stalls on CPUs/tasks: { 4} 
(detected by 7, t=60011 jiffies)
[  311.042237] INFO: Stall ended before state dump start
[  491.279642] INFO: rcu_preempt detected stalls on CPUs/tasks: { 4} 
(detected by 7, t=240249 jiffies)
[  491.279646] INFO: Stall ended before state dump start
[  671.670546] INFO: rcu_preempt detected stalls on CPUs/tasks: { 4} 
(detected by 7, t=420638 jiffies)
[  671.670550] INFO: Stall ended before state dump start
[  763.240862] INFO: rcu_bh detected stalls on CPUs/tasks: { 1 4} 
(detected by 5, t=63547 jiffies)
[  763.240867] INFO: Stall ended before state dump start
[  853.438186] INFO: rcu_preempt detected stalls on CPUs/tasks: { 4} 
(detected by 7, t=602410 jiffies)
[  853.438190] INFO: Stall ended before state dump start
[  943.632087] INFO: rcu_bh detected stalls on CPUs/tasks: { 1 4} 
(detected by 0, t=243935 jiffies)
[  943.632092] INFO: Stall ended before state dump start
[ 1033.828726] INFO: rcu_preempt detected stalls on CPUs/tasks: { 4} 
(detected by 7, t=782798 jiffies)
[ 1033.828729] INFO: Stall ended before state dump start


Now Dom0 still reacts, but mostly unusable sluggish...

Am 05.09.2012 20:54, schrieb Konrad Rzeszutek Wilk:
>> > > > And its due to a patch I added in v3.4
>> > > > (cd9db80e5257682a7f7ab245a2459648b3c8d268)
>> > > > - which did not work properly in v3.4, but with v3.5 got it 
>> working
>> > > > (977f857ca566a1e68045fcbb7cfc9c4acb077cf0) which causes v3.5 
>> to
>> > now
>> > > > work
>> > > > anymore.
>> > > >
>> > > > Anyhow, for right now jsut revert
>> > > > cd9db80e5257682a7f7ab245a2459648b3c8d268
>> > > > and it should work for you.
>> > > >
>> Confirmed, after reverting that commit, VT-d will work fine.
>> Will you fix this and push it to upstream Linux, Konrad?
>>
>> > > Also, our team reported a VT-d bug 2 months ago.
>> > > http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1824
>> >
>
> Can either one of you please test this patch, please:
>
>
> diff --git a/drivers/xen/xen-pciback/pci_stub.c
> b/drivers/xen/xen-pciback/pci_stub.c
> index 097e536..425bd0b 100644
> --- a/drivers/xen/xen-pciback/pci_stub.c
> +++ b/drivers/xen/xen-pciback/pci_stub.c
> @@ -4,6 +4,8 @@
>   * Ryan Wilson <hap9@epoch.ncsc.mil>
>   * Chris Bookholt <hap10@epoch.ncsc.mil>
>   */
> +#define DEBUG 1
> +
>  #include <linux/module.h>
>  #include <linux/init.h>
>  #include <linux/rwsem.h>
> @@ -97,13 +99,15 @@ static void pcistub_device_release(struct kref 
> *kref)
>  	/* Call the reset function which does not take lock as this
>  	 * is called from "unbind" which takes a device_lock mutex.
>  	 */
> +	dev_dbg(&psdev->dev->dev, "FLR locked..\n");
>  	__pci_reset_function_locked(psdev->dev);
>  	if (pci_load_and_free_saved_state(psdev->dev,
>  					  &dev_data->pci_saved_state)) {
>  		dev_dbg(&psdev->dev->dev, "Could not reload PCI state\n");
> -	} else
> +	} else {
> +		dev_dbg(&psdev->dev->dev, "Reloading PCI state..\n");
>  		pci_restore_state(psdev->dev);
> -
> +	}
>  	/* Disable the device */
>  	xen_pcibk_reset_device(psdev->dev);
>
> @@ -353,16 +357,16 @@ static int __devinit pcistub_init_device(struct
> pci_dev *dev)
>  	if (err)
>  		goto config_release;
>
> -	dev_dbg(&dev->dev, "reseting (FLR, D3, etc) the device\n");
> -	__pci_reset_function_locked(dev);
> -
>  	/* We need the device active to save the state. */
>  	dev_dbg(&dev->dev, "save state of device\n");
>  	pci_save_state(dev);
>  	dev_data->pci_saved_state = pci_store_saved_state(dev);
>  	if (!dev_data->pci_saved_state)
>  		dev_err(&dev->dev, "Could not store PCI conf saved state!\n");
> -
> +	else {
> +		dev_dbg(&dev->dev, "reseting (FLR, D3, etc) the device\n");
> +		__pci_reset_function_locked(dev);
> +	}
>  	/* Now disable the device (this also ensures some private device
>  	 * data is setup before we export)
>  	 */


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

From xen-devel-bounces@lists.xen.org Thu Sep 06 11:46:46 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 2012 11: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 1T9aXY-0004Fm-Ss; Thu, 06 Sep 2012 11:46:32 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <tobias.geiger@vido.info>) id 1T9aXX-0004Fa-Jd
	for xen-devel@lists.xen.org; Thu, 06 Sep 2012 11:46:31 +0000
Received: from [85.158.138.51:7497] by server-9.bemta-3.messagelabs.com id
	C6/5F-15390-61D88405; Thu, 06 Sep 2012 11:46:30 +0000
X-Env-Sender: tobias.geiger@vido.info
X-Msg-Ref: server-14.tower-174.messagelabs.com!1346931989!22682395!1
X-Originating-IP: [78.47.43.170]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
	MAILTO_TO_SPAM_ADDR,SUBJECT_EXCESS_QP,UNPARSEABLE_RELAY
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13830 invoked from network); 6 Sep 2012 11:46:29 -0000
Received: from mail.vido.info (HELO mail.vido.info) (78.47.43.170)
	by server-14.tower-174.messagelabs.com with SMTP;
	6 Sep 2012 11:46:29 -0000
Received: from localhost (ip6-localhost [127.0.0.1])
	by mail.vido.info (Postfix) with ESMTP id 61F0AD3429D;
	Thu,  6 Sep 2012 13:46:29 +0200 (CEST)
X-Virus-Scanned: by amavis at mail.vido.info
Received: from mail.vido.info ([127.0.0.1])
	by localhost (mail.vido.info [127.0.0.1]) (amavisd-new, port 10024)
	with LMTP id 3rB6qXsUw5Pr; Thu,  6 Sep 2012 13:46:25 +0200 (CEST)
Received: from www.vido.info (www.vido.info [78.47.43.171])
	by mail.vido.info (Postfix) with ESMTP id D68F7D34290;
	Thu,  6 Sep 2012 13:46:25 +0200 (CEST)
Received: from E3Z9zPOLZS/QATD+l1nhJ3BWJUO+kdobJUr2Fs7WQXKAvpH/8PY3uA==
	(gR1co/7ag7pSyeuym4AcWxY1jGlrDQan) by www.vido.info
	with HTTP (HTTP/1.1 POST); Thu, 06 Sep 2012 13:46:25 +0200
MIME-Version: 1.0
Date: Thu, 06 Sep 2012 13:46:25 +0200
From: Tobias Geiger <tobias.geiger@vido.info>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
In-Reply-To: <20120905185412.GA27077@phenom.dumpdata.com>
References: <1B4B44D9196EFF41AE41FDA404FC0A101881CE@SHSMSX101.ccr.corp.intel.com>
	<20120905185412.GA27077@phenom.dumpdata.com>
Message-ID: <bbe773ba08f144c0881398fc8dee456a@vido.info>
X-Sender: tobias.geiger@vido.info
User-Agent: Roundcube Webmail
Cc: Konrad Rzeszutek Wilk <konrad@kernel.org>, "Ren,
	Yongjie" <yongjie.ren@intel.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel]
 =?utf-8?q?Regression_in_kernel_3=2E5_as_Dom0_regardin?=
 =?utf-8?q?g_PCI_Passthrough=3F!?=
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

me again :)

it seems the Crash is not always a "fatal one":

[  247.080617] vif vif-2-0: 2 reading script
[  247.083519] br0: port 4(vif2.0) entered disabled state
[  247.084144] br0: port 4(vif2.0) entered disabled state
[  250.700029] ------------[ cut here ]------------
[  250.700046] kernel BUG at drivers/xen/balloon.c:359!
[  250.700059] invalid opcode: 0000 [#1] PREEMPT SMP
[  250.700071] CPU 4
[  250.700075] Modules linked in: joydev hid_generic uvcvideo 
snd_usb_audio snd_seq_midi snd_usbmidi_lib snd_hwdep snd_r
awmidi videobuf2_vmalloc videobuf2_memops videobuf2_core videodev 
gpio_ich [last unloaded: scsi_wait_scan]
[  250.700122]
[  250.700125] Pid: 23, comm: kworker/4:0 Not tainted 3.5.0 #3          
        /DX58SO
[  250.700139] RIP: e030:[<ffffffff81447f95>]  [<ffffffff81447f95>] 
balloon_process+0x385/0x3a0
[  250.700158] RSP: e02b:ffff8801317b9dc0  EFLAGS: 00010213
[  250.700162] RAX: 000000021f895000 RBX: 0000000000000000 RCX: 
0000000000000002
[  250.700167] RDX: ffffffff82027000 RSI: 0000000000000137 RDI: 
00000000000a2337
[  250.700172] RBP: ffff8801317b9e20 R08: ffff88014068e140 R09: 
00000000fffffffc
[  250.700180] R10: 0000000000000001 R11: 0000000000000000 R12: 
0000160000000000
[  250.700185] R13: 0000000000000001 R14: 00000000000a2337 R15: 
ffffea000288cdc0
[  250.700192] FS:  00007fb82ee14700(0000) GS:ffff880140680000(0000) 
knlGS:0000000000000000
[  250.700198] CS:  e033 DS: 0000 ES: 0000 CR0: 000000008005003b
[  250.700202] CR2: 00007fb82e7b39a6 CR3: 0000000001e0c000 CR4: 
0000000000002660
[  250.700207] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 
0000000000000000
[  250.700213] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 
0000000000000400
[  250.700218] Process kworker/4:0 (pid: 23, threadinfo 
ffff8801317b8000, task ffff88013178db00)
[  250.700223] Stack:
[  250.700225]  000000000006aa7b 0000000000000001 ffffffff8200ea80 
0000000000000001
[  250.700293]  0000000000000000 0000000000007ff0 ffff8801317b9e00 
ffff880131796400
[  250.700301]  ffff880140697000 ffff88014068e140 0000000000000000 
ffffffff81e587c0
[  250.700311] Call Trace:
[  250.700317]  [<ffffffff8106753b>] process_one_work+0x12b/0x450
[  250.700322]  [<ffffffff81447c10>] ? decrease_reservation+0x320/0x320
[  250.700328]  [<ffffffff810688be>] worker_thread+0x12e/0x2d0
[  250.700334]  [<ffffffff81068790>] ? 
manage_workers.isra.26+0x1f0/0x1f0
[  250.700340]  [<ffffffff8106db7e>] kthread+0x8e/0xa0
[  250.700346]  [<ffffffff8184e3e4>] kernel_thread_helper+0x4/0x10
[  250.700353]  [<ffffffff8184c87c>] ? retint_restore_args+0x5/0x6
[  250.700358]  [<ffffffff8184e3e0>] ? gs_change+0x13/0x13
[  250.700362] Code: 01 15 f0 6a bc 00 48 29 d0 48 89 05 ee 6a bc 00 e9 
31 fd ff ff 0f 0b 0f 0b 4c 89 f7 e8 85 34 bc ff
48 83 f8 ff 0f 84 2b fe ff ff <0f> 0b 66 0f 1f 84 00 00 00 00 00 48 83 
c1 01 e9 c2 fd ff ff 0f
[  250.700471] RIP  [<ffffffff81447f95>] balloon_process+0x385/0x3a0
[  250.700482]  RSP <ffff8801317b9dc0>
[  250.733955] ---[ end trace a5e5187e8ed6c1ff ]---
[  250.733982] BUG: unable to handle kernel paging request at 
fffffffffffffff8
[  250.733992] IP: [<ffffffff8106e08c>] kthread_data+0xc/0x20
[  250.733999] PGD 1e0e067 PUD 1e0f067 PMD 0
[  250.734006] Oops: 0000 [#2] PREEMPT SMP
[  250.734013] CPU 4
[  250.734016] Modules linked in: joydev hid_generic uvcvideo 
snd_usb_audio snd_seq_midi snd_usbmidi_lib snd_hwdep snd_r
awmidi videobuf2_vmalloc videobuf2_memops videobuf2_core videodev 
gpio_ich [last unloaded: scsi_wait_scan]
[  250.734071]
[  250.734073] Pid: 23, comm: kworker/4:0 Tainted: G      D      3.5.0 
#3                  /DX58SO
[  250.734095] RIP: e030:[<ffffffff8106e08c>]  [<ffffffff8106e08c>] 
kthread_data+0xc/0x20
[  250.734111] RSP: e02b:ffff8801317b9a90  EFLAGS: 00010092
[  250.734122] RAX: 0000000000000000 RBX: 0000000000000004 RCX: 
0000000000000004
[  250.734137] RDX: ffffffff81fcba40 RSI: 0000000000000004 RDI: 
ffff88013178db00
[  250.734151] RBP: ffff8801317b9aa8 R08: 0000000000989680 R09: 
ffffffff81fcba40
[  250.734166] R10: ffffffff8104960a R11: 0000000000000000 R12: 
ffff8801406936c0
[  250.734178] R13: 0000000000000004 R14: ffff88013178daf0 R15: 
ffff88013178db00
[  250.734196] FS:  00007fb82ee14700(0000) GS:ffff880140680000(0000) 
knlGS:0000000000000000
[  250.734202] CS:  e033 DS: 0000 ES: 0000 CR0: 000000008005003b
[  250.734209] CR2: fffffffffffffff8 CR3: 0000000001e0c000 CR4: 
0000000000002660
[  250.734222] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 
0000000000000000
[  250.734235] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 
0000000000000400
[  250.734249] Process kworker/4:0 (pid: 23, threadinfo 
ffff8801317b8000, task ffff88013178db00)
[  250.734266] Stack:
[  250.734271]  ffffffff810698e0 ffff8801317b9aa8 ffff88013178ded8 
ffff8801317b9b18
[  250.734292]  ffffffff8184ae02 ffff8801317b9fd8 ffff88013178db00 
ffff8801317b9fd8
[  250.734313]  ffff8801317b9fd8 ffff8801334796c0 ffff88013178db00 
ffff8801317b9ae8
[  250.734979] Call Trace:
[  250.735572]  [<ffffffff810698e0>] ? wq_worker_sleeping+0x10/0xa0
[  250.736179]  [<ffffffff8184ae02>] __schedule+0x592/0x7d0
[  250.736783]  [<ffffffff8184b164>] schedule+0x24/0x70
[  250.737373]  [<ffffffff81051592>] do_exit+0x5b2/0x910
[  250.737937]  [<ffffffff8183ea1e>] ? printk+0x48/0x4a
[  250.738498]  [<ffffffff8100ace2>] ? check_events+0x12/0x20
[  250.739053]  [<ffffffff81017581>] oops_end+0x71/0xa0
[  250.739596]  [<ffffffff810176f3>] die+0x53/0x80
[  250.740134]  [<ffffffff810143f8>] do_trap+0xb8/0x160
[  250.740668]  [<ffffffff810146f3>] do_invalid_op+0xa3/0xb0
[  250.741203]  [<ffffffff81447f95>] ? balloon_process+0x385/0x3a0
[  250.741737]  [<ffffffff81085f52>] ? load_balance+0xd2/0x800
[  250.742267]  [<ffffffff81006276>] ? xen_flush_tlb+0xd6/0x2a0
[  250.742803]  [<ffffffff8108117d>] ? cpuacct_charge+0x6d/0xb0
[  250.743332]  [<ffffffff8184e25b>] invalid_op+0x1b/0x20
[  250.743855]  [<ffffffff81447f95>] ? balloon_process+0x385/0x3a0
[  250.744374]  [<ffffffff8106753b>] process_one_work+0x12b/0x450
[  250.744897]  [<ffffffff81447c10>] ? decrease_reservation+0x320/0x320
[  250.745426]  [<ffffffff810688be>] worker_thread+0x12e/0x2d0
[  250.745942]  [<ffffffff81068790>] ? 
manage_workers.isra.26+0x1f0/0x1f0
[  250.746457]  [<ffffffff8106db7e>] kthread+0x8e/0xa0
[  250.746969]  [<ffffffff8184e3e4>] kernel_thread_helper+0x4/0x10
[  250.747480]  [<ffffffff8184c87c>] ? retint_restore_args+0x5/0x6
[  250.747990]  [<ffffffff8184e3e0>] ? gs_change+0x13/0x13
[  250.748487] Code: e0 ff ff 01 48 8b 80 38 e0 ff ff a8 08 0f 84 3d ff 
ff ff e8 57 d0 7d 00 e9 33 ff ff ff 66 90 48 8b
87 80 03 00 00 55 48 89 e5 5d <48> 8b 40 f8 c3 66 66 66 66 66 66 2e 0f 
1f 84 00 00 00 00 00 55
[  250.749575] RIP  [<ffffffff8106e08c>] kthread_data+0xc/0x20
[  250.750103]  RSP <ffff8801317b9a90>
[  250.750627] CR2: fffffffffffffff8
[  250.751151] ---[ end trace a5e5187e8ed6c200 ]---
[  250.751152] Fixing recursive fault but reboot is needed!
[  311.042233] INFO: rcu_preempt detected stalls on CPUs/tasks: { 4} 
(detected by 7, t=60011 jiffies)
[  311.042237] INFO: Stall ended before state dump start
[  491.279642] INFO: rcu_preempt detected stalls on CPUs/tasks: { 4} 
(detected by 7, t=240249 jiffies)
[  491.279646] INFO: Stall ended before state dump start
[  671.670546] INFO: rcu_preempt detected stalls on CPUs/tasks: { 4} 
(detected by 7, t=420638 jiffies)
[  671.670550] INFO: Stall ended before state dump start
[  763.240862] INFO: rcu_bh detected stalls on CPUs/tasks: { 1 4} 
(detected by 5, t=63547 jiffies)
[  763.240867] INFO: Stall ended before state dump start
[  853.438186] INFO: rcu_preempt detected stalls on CPUs/tasks: { 4} 
(detected by 7, t=602410 jiffies)
[  853.438190] INFO: Stall ended before state dump start
[  943.632087] INFO: rcu_bh detected stalls on CPUs/tasks: { 1 4} 
(detected by 0, t=243935 jiffies)
[  943.632092] INFO: Stall ended before state dump start
[ 1033.828726] INFO: rcu_preempt detected stalls on CPUs/tasks: { 4} 
(detected by 7, t=782798 jiffies)
[ 1033.828729] INFO: Stall ended before state dump start


Now Dom0 still reacts, but mostly unusable sluggish...

Am 05.09.2012 20:54, schrieb Konrad Rzeszutek Wilk:
>> > > > And its due to a patch I added in v3.4
>> > > > (cd9db80e5257682a7f7ab245a2459648b3c8d268)
>> > > > - which did not work properly in v3.4, but with v3.5 got it 
>> working
>> > > > (977f857ca566a1e68045fcbb7cfc9c4acb077cf0) which causes v3.5 
>> to
>> > now
>> > > > work
>> > > > anymore.
>> > > >
>> > > > Anyhow, for right now jsut revert
>> > > > cd9db80e5257682a7f7ab245a2459648b3c8d268
>> > > > and it should work for you.
>> > > >
>> Confirmed, after reverting that commit, VT-d will work fine.
>> Will you fix this and push it to upstream Linux, Konrad?
>>
>> > > Also, our team reported a VT-d bug 2 months ago.
>> > > http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1824
>> >
>
> Can either one of you please test this patch, please:
>
>
> diff --git a/drivers/xen/xen-pciback/pci_stub.c
> b/drivers/xen/xen-pciback/pci_stub.c
> index 097e536..425bd0b 100644
> --- a/drivers/xen/xen-pciback/pci_stub.c
> +++ b/drivers/xen/xen-pciback/pci_stub.c
> @@ -4,6 +4,8 @@
>   * Ryan Wilson <hap9@epoch.ncsc.mil>
>   * Chris Bookholt <hap10@epoch.ncsc.mil>
>   */
> +#define DEBUG 1
> +
>  #include <linux/module.h>
>  #include <linux/init.h>
>  #include <linux/rwsem.h>
> @@ -97,13 +99,15 @@ static void pcistub_device_release(struct kref 
> *kref)
>  	/* Call the reset function which does not take lock as this
>  	 * is called from "unbind" which takes a device_lock mutex.
>  	 */
> +	dev_dbg(&psdev->dev->dev, "FLR locked..\n");
>  	__pci_reset_function_locked(psdev->dev);
>  	if (pci_load_and_free_saved_state(psdev->dev,
>  					  &dev_data->pci_saved_state)) {
>  		dev_dbg(&psdev->dev->dev, "Could not reload PCI state\n");
> -	} else
> +	} else {
> +		dev_dbg(&psdev->dev->dev, "Reloading PCI state..\n");
>  		pci_restore_state(psdev->dev);
> -
> +	}
>  	/* Disable the device */
>  	xen_pcibk_reset_device(psdev->dev);
>
> @@ -353,16 +357,16 @@ static int __devinit pcistub_init_device(struct
> pci_dev *dev)
>  	if (err)
>  		goto config_release;
>
> -	dev_dbg(&dev->dev, "reseting (FLR, D3, etc) the device\n");
> -	__pci_reset_function_locked(dev);
> -
>  	/* We need the device active to save the state. */
>  	dev_dbg(&dev->dev, "save state of device\n");
>  	pci_save_state(dev);
>  	dev_data->pci_saved_state = pci_store_saved_state(dev);
>  	if (!dev_data->pci_saved_state)
>  		dev_err(&dev->dev, "Could not store PCI conf saved state!\n");
> -
> +	else {
> +		dev_dbg(&dev->dev, "reseting (FLR, D3, etc) the device\n");
> +		__pci_reset_function_locked(dev);
> +	}
>  	/* Now disable the device (this also ensures some private device
>  	 * data is setup before we export)
>  	 */


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

From xen-devel-bounces@lists.xen.org Thu Sep 06 11:47:01 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 2012 11: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 1T9aXs-0004I3-AH; Thu, 06 Sep 2012 11:46:52 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1T9aXq-0004Hp-UT
	for xen-devel@lists.xen.org; Thu, 06 Sep 2012 11:46:51 +0000
Received: from [85.158.138.51:8688] by server-12.bemta-3.messagelabs.com id
	0E/F2-10384-A2D88405; Thu, 06 Sep 2012 11:46:50 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1346932007!20948614!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNjkzMDI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10642 invoked from network); 6 Sep 2012 11:46:49 -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;
	6 Sep 2012 11:46:49 -0000
X-IronPort-AV: E=Sophos;i="4.80,380,1344211200"; d="scan'208";a="36970136"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Sep 2012 11:46:47 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1;
	Thu, 6 Sep 2012 07:46:46 -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 1T9aXm-0007Kk-Ba;
	Thu, 06 Sep 2012 12:46:46 +0100
MIME-Version: 1.0
X-Mercurial-Node: d4d7031eb68bf0ce9bc83901b699cf13a2c73c95
Message-ID: <d4d7031eb68bf0ce9bc8.1346932006@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Thu, 6 Sep 2012 12:46:46 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Cc: Ian.Jackson@citrix.com, Juergen Gross <juergen.gross@ts.fujitsu.com>
Subject: [Xen-devel] [PATCH] xl: do not leak cpupool names
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 1346931944 -3600
# Node ID d4d7031eb68bf0ce9bc83901b699cf13a2c73c95
# Parent  1db796c3c0b97bba222f20db543c227e313ec1be
xl: do not leak cpupool names.

Valgrind reports:
==3076== 7 bytes in 1 blocks are definitely lost in loss record 1 of 1
==3076==    at 0x402458C: malloc (vg_replace_malloc.c:270)
==3076==    by 0x406F86D: libxl_cpupoolid_to_name (libxl_utils.c:102)
==3076==    by 0x8058742: parse_config_data (xl_cmdimpl.c:639)
==3076==    by 0x805BD56: create_domain (xl_cmdimpl.c:1838)
==3076==    by 0x805DAED: main_create (xl_cmdimpl.c:3903)
==3076==    by 0x804D39D: main (xl.c:285)

And indeed there are several places where xl uses
libxl_cpupoolid_to_name as a boolean to test if the pool name is
valid and leaks the name if it is. Introduce an is_valid helper and
use that instead.

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

This leak is in xl not libxl so this is 4.3 material IMHO.

diff -r 1db796c3c0b9 -r d4d7031eb68b tools/libxl/libxl_utils.c
--- a/tools/libxl/libxl_utils.c	Thu Sep 06 12:24:44 2012 +0100
+++ b/tools/libxl/libxl_utils.c	Thu Sep 06 12:45:44 2012 +0100
@@ -103,6 +103,17 @@ char *libxl_cpupoolid_to_name(libxl_ctx 
     return s;
 }
 
+/* This is a bit horrid but without xs_exists it seems like the only way. */
+int libxl_cpupoolid_is_valid(libxl_ctx *ctx, uint32_t poolid)
+{
+    int ret;
+    char *s = libxl_cpupoolid_to_name(ctx, poolid);
+
+    ret = (s != NULL);
+    free(s);
+    return ret;
+}
+
 char *libxl__cpupoolid_to_name(libxl__gc *gc, uint32_t poolid)
 {
     char *s = libxl_cpupoolid_to_name(libxl__gc_owner(gc), poolid);
diff -r 1db796c3c0b9 -r d4d7031eb68b tools/libxl/libxl_utils.h
--- a/tools/libxl/libxl_utils.h	Thu Sep 06 12:24:44 2012 +0100
+++ b/tools/libxl/libxl_utils.h	Thu Sep 06 12:45:44 2012 +0100
@@ -24,6 +24,7 @@ int libxl_name_to_domid(libxl_ctx *ctx, 
 char *libxl_domid_to_name(libxl_ctx *ctx, uint32_t domid);
 int libxl_name_to_cpupoolid(libxl_ctx *ctx, const char *name, uint32_t *poolid);
 char *libxl_cpupoolid_to_name(libxl_ctx *ctx, uint32_t poolid);
+int libxl_cpupoolid_is_valid(libxl_ctx *ctx, uint32_t poolid);
 int libxl_get_stubdom_id(libxl_ctx *ctx, int guest_domid);
 int libxl_is_stubdom(libxl_ctx *ctx, uint32_t domid, uint32_t *target_domid);
 int libxl_create_logfile(libxl_ctx *ctx, const char *name, char **full_name);
diff -r 1db796c3c0b9 -r d4d7031eb68b tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Thu Sep 06 12:24:44 2012 +0100
+++ b/tools/libxl/xl_cmdimpl.c	Thu Sep 06 12:45:44 2012 +0100
@@ -636,7 +636,7 @@ static void parse_config_data(const char
         c_info->poolid = -1;
         cpupool_qualifier_to_cpupoolid(buf, &c_info->poolid, NULL);
     }
-    if (!libxl_cpupoolid_to_name(ctx, c_info->poolid)) {
+    if (!libxl_cpupoolid_is_valid(ctx, c_info->poolid)) {
         fprintf(stderr, "Illegal pool specified\n");
         exit(1);
     }
@@ -4733,7 +4733,7 @@ static int sched_domain_output(libxl_sch
 
     if (cpupool) {
         if (cpupool_qualifier_to_cpupoolid(cpupool, &poolid, NULL) ||
-            !libxl_cpupoolid_to_name(ctx, poolid)) {
+            !libxl_cpupoolid_is_valid(ctx, poolid)) {
             fprintf(stderr, "unknown cpupool \'%s\'\n", cpupool);
             return -ERROR_FAIL;
         }
@@ -4863,7 +4863,7 @@ int main_sched_credit(int argc, char **a
 
         if (cpupool) {
             if (cpupool_qualifier_to_cpupoolid(cpupool, &poolid, NULL) ||
-                !libxl_cpupoolid_to_name(ctx, poolid)) {
+                !libxl_cpupoolid_is_valid(ctx, poolid)) {
                 fprintf(stderr, "unknown cpupool \'%s\'\n", cpupool);
                 return -ERROR_FAIL;
             }
@@ -6290,7 +6290,7 @@ int main_cpupooldestroy(int argc, char *
     pool = argv[optind];
 
     if (cpupool_qualifier_to_cpupoolid(pool, &poolid, NULL) ||
-        !libxl_cpupoolid_to_name(ctx, poolid)) {
+        !libxl_cpupoolid_is_valid(ctx, poolid)) {
         fprintf(stderr, "unknown cpupool \'%s\'\n", pool);
         return -ERROR_FAIL;
     }
@@ -6311,7 +6311,7 @@ int main_cpupoolrename(int argc, char **
     pool = argv[optind++];
 
     if (cpupool_qualifier_to_cpupoolid(pool, &poolid, NULL) ||
-        !libxl_cpupoolid_to_name(ctx, poolid)) {
+        !libxl_cpupoolid_is_valid(ctx, poolid)) {
         fprintf(stderr, "unknown cpupool \'%s\'\n", pool);
         return -ERROR_FAIL;
     }
@@ -6348,7 +6348,7 @@ int main_cpupoolcpuadd(int argc, char **
     }
 
     if (cpupool_qualifier_to_cpupoolid(pool, &poolid, NULL) ||
-        !libxl_cpupoolid_to_name(ctx, poolid)) {
+        !libxl_cpupoolid_is_valid(ctx, poolid)) {
         fprintf(stderr, "unknown cpupool \'%s\'\n", pool);
         return -ERROR_FAIL;
     }
@@ -6392,7 +6392,7 @@ int main_cpupoolcpuremove(int argc, char
     }
 
     if (cpupool_qualifier_to_cpupoolid(pool, &poolid, NULL) ||
-        !libxl_cpupoolid_to_name(ctx, poolid)) {
+        !libxl_cpupoolid_is_valid(ctx, poolid)) {
         fprintf(stderr, "unknown cpupool \'%s\'\n", pool);
         return -ERROR_FAIL;
     }
@@ -6435,7 +6435,7 @@ int main_cpupoolmigrate(int argc, char *
     }
 
     if (cpupool_qualifier_to_cpupoolid(pool, &poolid, NULL) ||
-        !libxl_cpupoolid_to_name(ctx, poolid)) {
+        !libxl_cpupoolid_is_valid(ctx, poolid)) {
         fprintf(stderr, "unknown cpupool \'%s\'\n", pool);
         return -ERROR_FAIL;
     }
diff -r 1db796c3c0b9 -r d4d7031eb68b tools/libxl/xl_sxp.c
--- a/tools/libxl/xl_sxp.c	Thu Sep 06 12:24:44 2012 +0100
+++ b/tools/libxl/xl_sxp.c	Thu Sep 06 12:45:44 2012 +0100
@@ -37,6 +37,7 @@ void printf_info_sexp(int domid, libxl_d
 
     libxl_domain_create_info *c_info = &d_config->c_info;
     libxl_domain_build_info *b_info = &d_config->b_info;
+    char *pool;
 
     printf("(domain\n\t(domid %d)\n", domid);
     printf("\t(create_info)\n");
@@ -54,8 +55,10 @@ void printf_info_sexp(int domid, libxl_d
     } else {
         printf("\t(uuid <unknown>)\n");
     }
-
-    printf("\t(cpupool %s)\n", libxl_cpupoolid_to_name(ctx, c_info->poolid));
+    pool = libxl_cpupoolid_to_name(ctx, c_info->poolid);
+    if (pool)
+        printf("\t(cpupool %s)\n", pool);
+    free(pool);
     if (c_info->xsdata)
         printf("\t(xsdata contains data)\n");
     else

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

From xen-devel-bounces@lists.xen.org Thu Sep 06 11:47:01 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 2012 11: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 1T9aXs-0004I3-AH; Thu, 06 Sep 2012 11:46:52 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1T9aXq-0004Hp-UT
	for xen-devel@lists.xen.org; Thu, 06 Sep 2012 11:46:51 +0000
Received: from [85.158.138.51:8688] by server-12.bemta-3.messagelabs.com id
	0E/F2-10384-A2D88405; Thu, 06 Sep 2012 11:46:50 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1346932007!20948614!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNjkzMDI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10642 invoked from network); 6 Sep 2012 11:46:49 -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;
	6 Sep 2012 11:46:49 -0000
X-IronPort-AV: E=Sophos;i="4.80,380,1344211200"; d="scan'208";a="36970136"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Sep 2012 11:46:47 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1;
	Thu, 6 Sep 2012 07:46:46 -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 1T9aXm-0007Kk-Ba;
	Thu, 06 Sep 2012 12:46:46 +0100
MIME-Version: 1.0
X-Mercurial-Node: d4d7031eb68bf0ce9bc83901b699cf13a2c73c95
Message-ID: <d4d7031eb68bf0ce9bc8.1346932006@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Thu, 6 Sep 2012 12:46:46 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Cc: Ian.Jackson@citrix.com, Juergen Gross <juergen.gross@ts.fujitsu.com>
Subject: [Xen-devel] [PATCH] xl: do not leak cpupool names
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 1346931944 -3600
# Node ID d4d7031eb68bf0ce9bc83901b699cf13a2c73c95
# Parent  1db796c3c0b97bba222f20db543c227e313ec1be
xl: do not leak cpupool names.

Valgrind reports:
==3076== 7 bytes in 1 blocks are definitely lost in loss record 1 of 1
==3076==    at 0x402458C: malloc (vg_replace_malloc.c:270)
==3076==    by 0x406F86D: libxl_cpupoolid_to_name (libxl_utils.c:102)
==3076==    by 0x8058742: parse_config_data (xl_cmdimpl.c:639)
==3076==    by 0x805BD56: create_domain (xl_cmdimpl.c:1838)
==3076==    by 0x805DAED: main_create (xl_cmdimpl.c:3903)
==3076==    by 0x804D39D: main (xl.c:285)

And indeed there are several places where xl uses
libxl_cpupoolid_to_name as a boolean to test if the pool name is
valid and leaks the name if it is. Introduce an is_valid helper and
use that instead.

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

This leak is in xl not libxl so this is 4.3 material IMHO.

diff -r 1db796c3c0b9 -r d4d7031eb68b tools/libxl/libxl_utils.c
--- a/tools/libxl/libxl_utils.c	Thu Sep 06 12:24:44 2012 +0100
+++ b/tools/libxl/libxl_utils.c	Thu Sep 06 12:45:44 2012 +0100
@@ -103,6 +103,17 @@ char *libxl_cpupoolid_to_name(libxl_ctx 
     return s;
 }
 
+/* This is a bit horrid but without xs_exists it seems like the only way. */
+int libxl_cpupoolid_is_valid(libxl_ctx *ctx, uint32_t poolid)
+{
+    int ret;
+    char *s = libxl_cpupoolid_to_name(ctx, poolid);
+
+    ret = (s != NULL);
+    free(s);
+    return ret;
+}
+
 char *libxl__cpupoolid_to_name(libxl__gc *gc, uint32_t poolid)
 {
     char *s = libxl_cpupoolid_to_name(libxl__gc_owner(gc), poolid);
diff -r 1db796c3c0b9 -r d4d7031eb68b tools/libxl/libxl_utils.h
--- a/tools/libxl/libxl_utils.h	Thu Sep 06 12:24:44 2012 +0100
+++ b/tools/libxl/libxl_utils.h	Thu Sep 06 12:45:44 2012 +0100
@@ -24,6 +24,7 @@ int libxl_name_to_domid(libxl_ctx *ctx, 
 char *libxl_domid_to_name(libxl_ctx *ctx, uint32_t domid);
 int libxl_name_to_cpupoolid(libxl_ctx *ctx, const char *name, uint32_t *poolid);
 char *libxl_cpupoolid_to_name(libxl_ctx *ctx, uint32_t poolid);
+int libxl_cpupoolid_is_valid(libxl_ctx *ctx, uint32_t poolid);
 int libxl_get_stubdom_id(libxl_ctx *ctx, int guest_domid);
 int libxl_is_stubdom(libxl_ctx *ctx, uint32_t domid, uint32_t *target_domid);
 int libxl_create_logfile(libxl_ctx *ctx, const char *name, char **full_name);
diff -r 1db796c3c0b9 -r d4d7031eb68b tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Thu Sep 06 12:24:44 2012 +0100
+++ b/tools/libxl/xl_cmdimpl.c	Thu Sep 06 12:45:44 2012 +0100
@@ -636,7 +636,7 @@ static void parse_config_data(const char
         c_info->poolid = -1;
         cpupool_qualifier_to_cpupoolid(buf, &c_info->poolid, NULL);
     }
-    if (!libxl_cpupoolid_to_name(ctx, c_info->poolid)) {
+    if (!libxl_cpupoolid_is_valid(ctx, c_info->poolid)) {
         fprintf(stderr, "Illegal pool specified\n");
         exit(1);
     }
@@ -4733,7 +4733,7 @@ static int sched_domain_output(libxl_sch
 
     if (cpupool) {
         if (cpupool_qualifier_to_cpupoolid(cpupool, &poolid, NULL) ||
-            !libxl_cpupoolid_to_name(ctx, poolid)) {
+            !libxl_cpupoolid_is_valid(ctx, poolid)) {
             fprintf(stderr, "unknown cpupool \'%s\'\n", cpupool);
             return -ERROR_FAIL;
         }
@@ -4863,7 +4863,7 @@ int main_sched_credit(int argc, char **a
 
         if (cpupool) {
             if (cpupool_qualifier_to_cpupoolid(cpupool, &poolid, NULL) ||
-                !libxl_cpupoolid_to_name(ctx, poolid)) {
+                !libxl_cpupoolid_is_valid(ctx, poolid)) {
                 fprintf(stderr, "unknown cpupool \'%s\'\n", cpupool);
                 return -ERROR_FAIL;
             }
@@ -6290,7 +6290,7 @@ int main_cpupooldestroy(int argc, char *
     pool = argv[optind];
 
     if (cpupool_qualifier_to_cpupoolid(pool, &poolid, NULL) ||
-        !libxl_cpupoolid_to_name(ctx, poolid)) {
+        !libxl_cpupoolid_is_valid(ctx, poolid)) {
         fprintf(stderr, "unknown cpupool \'%s\'\n", pool);
         return -ERROR_FAIL;
     }
@@ -6311,7 +6311,7 @@ int main_cpupoolrename(int argc, char **
     pool = argv[optind++];
 
     if (cpupool_qualifier_to_cpupoolid(pool, &poolid, NULL) ||
-        !libxl_cpupoolid_to_name(ctx, poolid)) {
+        !libxl_cpupoolid_is_valid(ctx, poolid)) {
         fprintf(stderr, "unknown cpupool \'%s\'\n", pool);
         return -ERROR_FAIL;
     }
@@ -6348,7 +6348,7 @@ int main_cpupoolcpuadd(int argc, char **
     }
 
     if (cpupool_qualifier_to_cpupoolid(pool, &poolid, NULL) ||
-        !libxl_cpupoolid_to_name(ctx, poolid)) {
+        !libxl_cpupoolid_is_valid(ctx, poolid)) {
         fprintf(stderr, "unknown cpupool \'%s\'\n", pool);
         return -ERROR_FAIL;
     }
@@ -6392,7 +6392,7 @@ int main_cpupoolcpuremove(int argc, char
     }
 
     if (cpupool_qualifier_to_cpupoolid(pool, &poolid, NULL) ||
-        !libxl_cpupoolid_to_name(ctx, poolid)) {
+        !libxl_cpupoolid_is_valid(ctx, poolid)) {
         fprintf(stderr, "unknown cpupool \'%s\'\n", pool);
         return -ERROR_FAIL;
     }
@@ -6435,7 +6435,7 @@ int main_cpupoolmigrate(int argc, char *
     }
 
     if (cpupool_qualifier_to_cpupoolid(pool, &poolid, NULL) ||
-        !libxl_cpupoolid_to_name(ctx, poolid)) {
+        !libxl_cpupoolid_is_valid(ctx, poolid)) {
         fprintf(stderr, "unknown cpupool \'%s\'\n", pool);
         return -ERROR_FAIL;
     }
diff -r 1db796c3c0b9 -r d4d7031eb68b tools/libxl/xl_sxp.c
--- a/tools/libxl/xl_sxp.c	Thu Sep 06 12:24:44 2012 +0100
+++ b/tools/libxl/xl_sxp.c	Thu Sep 06 12:45:44 2012 +0100
@@ -37,6 +37,7 @@ void printf_info_sexp(int domid, libxl_d
 
     libxl_domain_create_info *c_info = &d_config->c_info;
     libxl_domain_build_info *b_info = &d_config->b_info;
+    char *pool;
 
     printf("(domain\n\t(domid %d)\n", domid);
     printf("\t(create_info)\n");
@@ -54,8 +55,10 @@ void printf_info_sexp(int domid, libxl_d
     } else {
         printf("\t(uuid <unknown>)\n");
     }
-
-    printf("\t(cpupool %s)\n", libxl_cpupoolid_to_name(ctx, c_info->poolid));
+    pool = libxl_cpupoolid_to_name(ctx, c_info->poolid);
+    if (pool)
+        printf("\t(cpupool %s)\n", pool);
+    free(pool);
     if (c_info->xsdata)
         printf("\t(xsdata contains data)\n");
     else

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

From xen-devel-bounces@lists.xen.org Thu Sep 06 11:47:58 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 2012 11: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 1T9aYn-0004T6-OS; Thu, 06 Sep 2012 11:47:49 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1T9aYm-0004Rk-N2
	for xen-devel@lists.xen.org; Thu, 06 Sep 2012 11:47:48 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-7.tower-27.messagelabs.com!1346932062!2182778!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4284 invoked from network); 6 Sep 2012 11:47:42 -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; 6 Sep 2012 11:47:42 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1T9aYf-000FBd-L0; Thu, 06 Sep 2012 11:47:41 +0000
Date: Thu, 6 Sep 2012 12:47:41 +0100
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <ian.campbell@citrix.com>
Message-ID: <20120906114741.GF56463@ocelot.phlegethon.org>
References: <1346678886.32462.9.camel@zakaz.uk.xensource.com>
	<1346679056-8108-6-git-send-email-ian.campbell@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1346679056-8108-6-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 06/16] arm: parse modules from DT during
	early boot.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At 13:30 +0000 on 03 Sep (1346679046), Ian Campbell wrote:
> The bootloader should populate /chosen/nr-modules with the number of
> modules and then for each module 0..nr-modules-1 it should populate
> /chosen/moduleN-{start,end} with the physical address of the module.

The code below looks like it's expecting the modules to be numbered from
1, not from 0.

Tim.

> The hypervisor allows for 2 modules (kernel and initrd). Currently we
> don't do anything with them.
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> ---
>  xen/common/device_tree.c      |   57 +++++++++++++++++++++++++++++++++++++++++
>  xen/include/xen/device_tree.h |    7 +++++
>  2 files changed, 64 insertions(+), 0 deletions(-)
> 
> diff --git a/xen/common/device_tree.c b/xen/common/device_tree.c
> index 3d1f0f4..226e3f3 100644
> --- a/xen/common/device_tree.c
> +++ b/xen/common/device_tree.c
> @@ -229,6 +229,61 @@ static void __init process_memory_node(const void *fdt, int node,
>      }
>  }
>  
> +static void __init process_chosen_node(const void *fdt, int node,
> +                                       const char *name,
> +                                       u32 address_cells, u32 size_cells)
> +{
> +    const struct fdt_property *prop;
> +    const u32 *cell;
> +    paddr_t size;
> +    int i, nr_modules;
> +
> +    prop = fdt_get_property(fdt, node, "nr-modules", NULL);
> +    if ( !prop )
> +    {
> +        early_info.modules.nr_mods = 0;
> +        return;
> +    }
> +
> +    cell = (const u32 *)prop->data;
> +    get_val(&cell, 1, (u64*)&nr_modules);
> +
> +    if ( nr_modules > NR_MODULES )
> +    {
> +        early_panic("too many modules %d > %d\n", nr_modules, NR_MODULES);
> +    }
> +
> +    for ( i = 0; i < nr_modules; i++ )
> +    {
> +        struct membank *mod = &early_info.modules.module[i];
> +        /* longest prop name is "start", single digit numbers of modules */
> +        char propname[strlen("moduleX-start") + 1];
> +
> +        BUILD_BUG_ON(NR_MODULES > 9);
> +
> +        snprintf(propname, sizeof(propname), "module%d-start", i+1);
> +        prop = fdt_get_property(fdt, node, propname, NULL);
> +        if ( !prop )
> +            early_panic("no start for module %d\n", i);
> +
> +        cell = (const u32 *)prop->data;
> +        device_tree_get_reg(&cell, address_cells, size_cells,
> +                            &mod->start, &size);
> +
> +        snprintf(propname, sizeof(propname), "module%d-end", i+1);
> +        prop = fdt_get_property(fdt, node, propname, NULL);
> +        if ( !prop )
> +            early_panic("no end for module %d\n", i);
> +
> +        cell = (const u32 *)prop->data;
> +        device_tree_get_reg(&cell, address_cells, size_cells,
> +                            &mod->size, &size);
> +        mod->size -= mod->start;
> +    }
> +
> +    early_info.modules.nr_mods = nr_modules;
> +}
> +
>  static int __init early_scan_node(const void *fdt,
>                                    int node, const char *name, int depth,
>                                    u32 address_cells, u32 size_cells,
> @@ -236,6 +291,8 @@ static int __init early_scan_node(const void *fdt,
>  {
>      if ( device_tree_node_matches(fdt, node, "memory") )
>          process_memory_node(fdt, node, name, address_cells, size_cells);
> +    else if ( device_tree_node_matches(fdt, node, "chosen") )
> +        process_chosen_node(fdt, node, name, address_cells, size_cells);
>  
>      return 0;
>  }
> diff --git a/xen/include/xen/device_tree.h b/xen/include/xen/device_tree.h
> index 4d010c0..585fcc9 100644
> --- a/xen/include/xen/device_tree.h
> +++ b/xen/include/xen/device_tree.h
> @@ -15,6 +15,7 @@
>  #define DEVICE_TREE_MAX_DEPTH 16
>  
>  #define NR_MEM_BANKS 8
> +#define NR_MODULES 2
>  
>  struct membank {
>      paddr_t start;
> @@ -26,8 +27,14 @@ struct dt_mem_info {
>      struct membank bank[NR_MEM_BANKS];
>  };
>  
> +struct dt_module_info {
> +    int nr_mods;
> +    struct membank module[NR_MODULES];
> +};
> +
>  struct dt_early_info {
>      struct dt_mem_info mem;
> +    struct dt_module_info modules;
>  };
>  
>  typedef int (*device_tree_node_func)(const void *fdt,
> -- 
> 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 Sep 06 11:47:58 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 2012 11: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 1T9aYn-0004T6-OS; Thu, 06 Sep 2012 11:47:49 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1T9aYm-0004Rk-N2
	for xen-devel@lists.xen.org; Thu, 06 Sep 2012 11:47:48 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-7.tower-27.messagelabs.com!1346932062!2182778!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4284 invoked from network); 6 Sep 2012 11:47:42 -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; 6 Sep 2012 11:47:42 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1T9aYf-000FBd-L0; Thu, 06 Sep 2012 11:47:41 +0000
Date: Thu, 6 Sep 2012 12:47:41 +0100
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <ian.campbell@citrix.com>
Message-ID: <20120906114741.GF56463@ocelot.phlegethon.org>
References: <1346678886.32462.9.camel@zakaz.uk.xensource.com>
	<1346679056-8108-6-git-send-email-ian.campbell@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1346679056-8108-6-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 06/16] arm: parse modules from DT during
	early boot.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At 13:30 +0000 on 03 Sep (1346679046), Ian Campbell wrote:
> The bootloader should populate /chosen/nr-modules with the number of
> modules and then for each module 0..nr-modules-1 it should populate
> /chosen/moduleN-{start,end} with the physical address of the module.

The code below looks like it's expecting the modules to be numbered from
1, not from 0.

Tim.

> The hypervisor allows for 2 modules (kernel and initrd). Currently we
> don't do anything with them.
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> ---
>  xen/common/device_tree.c      |   57 +++++++++++++++++++++++++++++++++++++++++
>  xen/include/xen/device_tree.h |    7 +++++
>  2 files changed, 64 insertions(+), 0 deletions(-)
> 
> diff --git a/xen/common/device_tree.c b/xen/common/device_tree.c
> index 3d1f0f4..226e3f3 100644
> --- a/xen/common/device_tree.c
> +++ b/xen/common/device_tree.c
> @@ -229,6 +229,61 @@ static void __init process_memory_node(const void *fdt, int node,
>      }
>  }
>  
> +static void __init process_chosen_node(const void *fdt, int node,
> +                                       const char *name,
> +                                       u32 address_cells, u32 size_cells)
> +{
> +    const struct fdt_property *prop;
> +    const u32 *cell;
> +    paddr_t size;
> +    int i, nr_modules;
> +
> +    prop = fdt_get_property(fdt, node, "nr-modules", NULL);
> +    if ( !prop )
> +    {
> +        early_info.modules.nr_mods = 0;
> +        return;
> +    }
> +
> +    cell = (const u32 *)prop->data;
> +    get_val(&cell, 1, (u64*)&nr_modules);
> +
> +    if ( nr_modules > NR_MODULES )
> +    {
> +        early_panic("too many modules %d > %d\n", nr_modules, NR_MODULES);
> +    }
> +
> +    for ( i = 0; i < nr_modules; i++ )
> +    {
> +        struct membank *mod = &early_info.modules.module[i];
> +        /* longest prop name is "start", single digit numbers of modules */
> +        char propname[strlen("moduleX-start") + 1];
> +
> +        BUILD_BUG_ON(NR_MODULES > 9);
> +
> +        snprintf(propname, sizeof(propname), "module%d-start", i+1);
> +        prop = fdt_get_property(fdt, node, propname, NULL);
> +        if ( !prop )
> +            early_panic("no start for module %d\n", i);
> +
> +        cell = (const u32 *)prop->data;
> +        device_tree_get_reg(&cell, address_cells, size_cells,
> +                            &mod->start, &size);
> +
> +        snprintf(propname, sizeof(propname), "module%d-end", i+1);
> +        prop = fdt_get_property(fdt, node, propname, NULL);
> +        if ( !prop )
> +            early_panic("no end for module %d\n", i);
> +
> +        cell = (const u32 *)prop->data;
> +        device_tree_get_reg(&cell, address_cells, size_cells,
> +                            &mod->size, &size);
> +        mod->size -= mod->start;
> +    }
> +
> +    early_info.modules.nr_mods = nr_modules;
> +}
> +
>  static int __init early_scan_node(const void *fdt,
>                                    int node, const char *name, int depth,
>                                    u32 address_cells, u32 size_cells,
> @@ -236,6 +291,8 @@ static int __init early_scan_node(const void *fdt,
>  {
>      if ( device_tree_node_matches(fdt, node, "memory") )
>          process_memory_node(fdt, node, name, address_cells, size_cells);
> +    else if ( device_tree_node_matches(fdt, node, "chosen") )
> +        process_chosen_node(fdt, node, name, address_cells, size_cells);
>  
>      return 0;
>  }
> diff --git a/xen/include/xen/device_tree.h b/xen/include/xen/device_tree.h
> index 4d010c0..585fcc9 100644
> --- a/xen/include/xen/device_tree.h
> +++ b/xen/include/xen/device_tree.h
> @@ -15,6 +15,7 @@
>  #define DEVICE_TREE_MAX_DEPTH 16
>  
>  #define NR_MEM_BANKS 8
> +#define NR_MODULES 2
>  
>  struct membank {
>      paddr_t start;
> @@ -26,8 +27,14 @@ struct dt_mem_info {
>      struct membank bank[NR_MEM_BANKS];
>  };
>  
> +struct dt_module_info {
> +    int nr_mods;
> +    struct membank module[NR_MODULES];
> +};
> +
>  struct dt_early_info {
>      struct dt_mem_info mem;
> +    struct dt_module_info modules;
>  };
>  
>  typedef int (*device_tree_node_func)(const void *fdt,
> -- 
> 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 Sep 06 11:48:37 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 2012 11:48:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9aZT-0004cV-Bv; Thu, 06 Sep 2012 11:48:31 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ben.guthro@gmail.com>) id 1T9aZS-0004bx-03
	for xen-devel@lists.xen.org; Thu, 06 Sep 2012 11:48:30 +0000
Received: from [85.158.143.99:13374] by server-3.bemta-4.messagelabs.com id
	2D/68-08232-D8D88405; Thu, 06 Sep 2012 11:48:29 +0000
X-Env-Sender: ben.guthro@gmail.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1346932107!19121304!1
X-Originating-IP: [209.85.223.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 315 invoked from network); 6 Sep 2012 11:48:28 -0000
Received: from mail-ie0-f173.google.com (HELO mail-ie0-f173.google.com)
	(209.85.223.173)
	by server-8.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Sep 2012 11:48:28 -0000
Received: by iebc10 with SMTP id c10so3477771ieb.32
	for <xen-devel@lists.xen.org>; Thu, 06 Sep 2012 04:48: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;
	bh=+78xRzRCJ50gS57wKudlVGIrGeT5EubJElwh+n0Iyk8=;
	b=Z28CxKIxNqoBVZ6gkbI9lDeaB4wtcwGiis83h+jCof8+sbemsO3WlmDrxggWE5RLcv
	PqcSUR4FwgEpjMNlBCwiGqcNtSccKYUX8ax6uaBCVmmH151dMV+spKFLvJpgGAmZOG8d
	kICHjiUbEEufYL/NCPKLzptsLL716RHZCBJ5nz25/4DY+hPfPCQVe3SI2RFfHe2HgJAz
	E29lRtOl9x9VXobwHQ9RwOCArUmn0J4R+m/Mlfwjjxqb+JQaVv6bVrbqp6MUFmLQEk6x
	X4zt7Iz3yB0VYED91t+MHCsj0P6SQ72um+O6wuF6GmnJUQuUYFgupdAiQWM91OYbFFcB
	nXmQ==
MIME-Version: 1.0
Received: by 10.50.195.134 with SMTP id ie6mr1943209igc.28.1346932106897; Thu,
	06 Sep 2012 04:48:26 -0700 (PDT)
Received: by 10.64.28.203 with HTTP; Thu, 6 Sep 2012 04:48:26 -0700 (PDT)
In-Reply-To: <5048958D02000078000993EB@nat28.tlf.novell.com>
References: <CAOvdn6WwgBD-2yf1uu3m9-16=Tb5KUrybXf2KibtnxKbP7YtwA@mail.gmail.com>
	<CAOvdn6UBW-yTOMd3YSf5M9JiHLRivyaKL-qzcKG8epszqaKmGg@mail.gmail.com>
	<20120807163320.GC15053@phenom.dumpdata.com>
	<CAOvdn6XcRGKtJxGwJO8J+ZBJr89wfTLc1woW5rhtMM540H9h1w@mail.gmail.com>
	<CAOvdn6XUoSeGoo7X=AJ1kpDxZB9HZEv+TJ4v-=FHcyR4=CHK-w@mail.gmail.com>
	<502240F302000078000937A6@nat28.tlf.novell.com>
	<CAOvdn6WN3kxC8Bb9g6MpfLULu47EGSGCtajPc-SFeJ-8VSUQDQ@mail.gmail.com>
	<CAOvdn6Xk1inm1hU55i0phU2qvSWyJLNoyDdn43biBAY2OewPtw@mail.gmail.com>
	<5023F5400200007800093F4E@nat28.tlf.novell.com>
	<CAOvdn6U-f3C4U8xVPvDyRFkFFLkbfiCXg_n+9zgA9V5u+q5jfw@mail.gmail.com>
	<5023F8B80200007800093F8C@nat28.tlf.novell.com>
	<CAOvdn6XKHfete_+=Hkvt20G7_cJ-4i8+9j9YD30OxzQ16Ru-+g@mail.gmail.com>
	<5024CB720200007800094124@nat28.tlf.novell.com>
	<CAOvdn6VVJdhWVYa-gNVt3euE4AbGi1TijUCUd1wGzv0SCWEUYA@mail.gmail.com>
	<CAOvdn6USnG9Y4MNBhrDZmob0oJ8BgFfKTvFEhcKbXDxNmzfZ-Q@mail.gmail.com>
	<502B75BA0200007800094FD4@nat28.tlf.novell.com>
	<CAOvdn6Ww5oEj6Xg=XT4dWCYWUBuOdPqLz-CqNjz4HmCScE+==g@mail.gmail.com>
	<CAOvdn6Wsjds_dmZ0dwDTYmD-o-OqjBH5-b9mitAuUADE+A4_ag@mail.gmail.com>
	<502BB8FD02000078000951E0@nat28.tlf.novell.com>
	<CAOvdn6VD6bp13F-tvYdkBsj4hkhE7PTGZrapndtdHrDKeZqccg@mail.gmail.com>
	<502CCC0002000078000955C4@nat28.tlf.novell.com>
	<CAOvdn6VEuX7R2_wz74ZvCxMjC-=YUir9kP5sdxEVaKVspRUd_w@mail.gmail.com>
	<502CF0A8020000780009574E@nat28.tlf.novell.com>
	<CAOvdn6VsZvn_1TCWYeuyY5YuTcP8=miK2KwE4583nsj6Qjb_vg@mail.gmail.com>
	<504494FB0200007800098398@nat28.tlf.novell.com>
	<CAOvdn6UT13qvWbMyfZkWND03RoVKVSgb6wW4yqTUpuBYEX01Dg@mail.gmail.com>
	<5048958D02000078000993EB@nat28.tlf.novell.com>
Date: Thu, 6 Sep 2012 07:48:26 -0400
X-Google-Sender-Auth: tODPlLp6X8mOQO9144hPTxsQpWc
Message-ID: <CAOvdn6WrNK1Jn_Y_P7C3AwX6ApVcgzacLA_x-u=xBQtebnuPxA@mail.gmail.com>
From: Ben Guthro <ben@guthro.net>
To: Jan Beulich <JBeulich@suse.com>
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>, john.baboval@citrix.com,
	Thomas Goetz <thomas.goetz@citrix.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen4.2 S3 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

Fantastic!

Initial tests are very good, with this dma_msi_ack modification.

I've been able to get past the ahci stall, and run through ~10 suspend
/ resume cycles with this fix.
Additional tests are warranted, and I'll run through an automated
sleep / wake script I have to make sure this fix holds over time.

Thanks for this.

Ben

On Thu, Sep 6, 2012 at 6:22 AM, Jan Beulich <JBeulich@suse.com> wrote:
>>>> On 04.09.12 at 14:27, Ben Guthro <ben@guthro.net> wrote:
>> I've put the console log of this test run here:
>> https://citrix.sharefile.com/d/sdc383e252fb41c5a
>>
>> (again, so as not to clog everyone's inbox)
>>
>> I have not yet gone through the log in its entirety yet, but thought I
>> would first send it to you to see if you had something in particular
>> you were looking for.
>>
>> The file name is console-S3-MSI.txt
>
> I think that nailed it: pci_restore_msi_state() passed a pointer
> to the stored entry->msg to write_msi_msg(), but with interrupt
> remapping enabled that function's call to
> iommu_update_ire_from_msi() alters the passed in struct
> msi_msg instance. As the stored value is used for nothing but
> a subsequent (second) restore, a problem would only arise if
> between the two saves to further writing of the stored entry
> would occur (i.e. no intermediate call to set_msi_affinity()).
>
> Attached the advertised next version of the debugging patch
> (printks - slightly altered - left in to catch eventual further
> problems or to deal with my analysis being wrong; none of the
> "bogus!" ones should now trigger anymore). If this works, I'd
> be curious to see how much of your other workaround code
> you could then remove without breaking things again.
>
> Jan
>

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

From xen-devel-bounces@lists.xen.org Thu Sep 06 11:48:37 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 2012 11:48:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9aZT-0004cV-Bv; Thu, 06 Sep 2012 11:48:31 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ben.guthro@gmail.com>) id 1T9aZS-0004bx-03
	for xen-devel@lists.xen.org; Thu, 06 Sep 2012 11:48:30 +0000
Received: from [85.158.143.99:13374] by server-3.bemta-4.messagelabs.com id
	2D/68-08232-D8D88405; Thu, 06 Sep 2012 11:48:29 +0000
X-Env-Sender: ben.guthro@gmail.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1346932107!19121304!1
X-Originating-IP: [209.85.223.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 315 invoked from network); 6 Sep 2012 11:48:28 -0000
Received: from mail-ie0-f173.google.com (HELO mail-ie0-f173.google.com)
	(209.85.223.173)
	by server-8.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Sep 2012 11:48:28 -0000
Received: by iebc10 with SMTP id c10so3477771ieb.32
	for <xen-devel@lists.xen.org>; Thu, 06 Sep 2012 04:48: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;
	bh=+78xRzRCJ50gS57wKudlVGIrGeT5EubJElwh+n0Iyk8=;
	b=Z28CxKIxNqoBVZ6gkbI9lDeaB4wtcwGiis83h+jCof8+sbemsO3WlmDrxggWE5RLcv
	PqcSUR4FwgEpjMNlBCwiGqcNtSccKYUX8ax6uaBCVmmH151dMV+spKFLvJpgGAmZOG8d
	kICHjiUbEEufYL/NCPKLzptsLL716RHZCBJ5nz25/4DY+hPfPCQVe3SI2RFfHe2HgJAz
	E29lRtOl9x9VXobwHQ9RwOCArUmn0J4R+m/Mlfwjjxqb+JQaVv6bVrbqp6MUFmLQEk6x
	X4zt7Iz3yB0VYED91t+MHCsj0P6SQ72um+O6wuF6GmnJUQuUYFgupdAiQWM91OYbFFcB
	nXmQ==
MIME-Version: 1.0
Received: by 10.50.195.134 with SMTP id ie6mr1943209igc.28.1346932106897; Thu,
	06 Sep 2012 04:48:26 -0700 (PDT)
Received: by 10.64.28.203 with HTTP; Thu, 6 Sep 2012 04:48:26 -0700 (PDT)
In-Reply-To: <5048958D02000078000993EB@nat28.tlf.novell.com>
References: <CAOvdn6WwgBD-2yf1uu3m9-16=Tb5KUrybXf2KibtnxKbP7YtwA@mail.gmail.com>
	<CAOvdn6UBW-yTOMd3YSf5M9JiHLRivyaKL-qzcKG8epszqaKmGg@mail.gmail.com>
	<20120807163320.GC15053@phenom.dumpdata.com>
	<CAOvdn6XcRGKtJxGwJO8J+ZBJr89wfTLc1woW5rhtMM540H9h1w@mail.gmail.com>
	<CAOvdn6XUoSeGoo7X=AJ1kpDxZB9HZEv+TJ4v-=FHcyR4=CHK-w@mail.gmail.com>
	<502240F302000078000937A6@nat28.tlf.novell.com>
	<CAOvdn6WN3kxC8Bb9g6MpfLULu47EGSGCtajPc-SFeJ-8VSUQDQ@mail.gmail.com>
	<CAOvdn6Xk1inm1hU55i0phU2qvSWyJLNoyDdn43biBAY2OewPtw@mail.gmail.com>
	<5023F5400200007800093F4E@nat28.tlf.novell.com>
	<CAOvdn6U-f3C4U8xVPvDyRFkFFLkbfiCXg_n+9zgA9V5u+q5jfw@mail.gmail.com>
	<5023F8B80200007800093F8C@nat28.tlf.novell.com>
	<CAOvdn6XKHfete_+=Hkvt20G7_cJ-4i8+9j9YD30OxzQ16Ru-+g@mail.gmail.com>
	<5024CB720200007800094124@nat28.tlf.novell.com>
	<CAOvdn6VVJdhWVYa-gNVt3euE4AbGi1TijUCUd1wGzv0SCWEUYA@mail.gmail.com>
	<CAOvdn6USnG9Y4MNBhrDZmob0oJ8BgFfKTvFEhcKbXDxNmzfZ-Q@mail.gmail.com>
	<502B75BA0200007800094FD4@nat28.tlf.novell.com>
	<CAOvdn6Ww5oEj6Xg=XT4dWCYWUBuOdPqLz-CqNjz4HmCScE+==g@mail.gmail.com>
	<CAOvdn6Wsjds_dmZ0dwDTYmD-o-OqjBH5-b9mitAuUADE+A4_ag@mail.gmail.com>
	<502BB8FD02000078000951E0@nat28.tlf.novell.com>
	<CAOvdn6VD6bp13F-tvYdkBsj4hkhE7PTGZrapndtdHrDKeZqccg@mail.gmail.com>
	<502CCC0002000078000955C4@nat28.tlf.novell.com>
	<CAOvdn6VEuX7R2_wz74ZvCxMjC-=YUir9kP5sdxEVaKVspRUd_w@mail.gmail.com>
	<502CF0A8020000780009574E@nat28.tlf.novell.com>
	<CAOvdn6VsZvn_1TCWYeuyY5YuTcP8=miK2KwE4583nsj6Qjb_vg@mail.gmail.com>
	<504494FB0200007800098398@nat28.tlf.novell.com>
	<CAOvdn6UT13qvWbMyfZkWND03RoVKVSgb6wW4yqTUpuBYEX01Dg@mail.gmail.com>
	<5048958D02000078000993EB@nat28.tlf.novell.com>
Date: Thu, 6 Sep 2012 07:48:26 -0400
X-Google-Sender-Auth: tODPlLp6X8mOQO9144hPTxsQpWc
Message-ID: <CAOvdn6WrNK1Jn_Y_P7C3AwX6ApVcgzacLA_x-u=xBQtebnuPxA@mail.gmail.com>
From: Ben Guthro <ben@guthro.net>
To: Jan Beulich <JBeulich@suse.com>
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>, john.baboval@citrix.com,
	Thomas Goetz <thomas.goetz@citrix.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen4.2 S3 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

Fantastic!

Initial tests are very good, with this dma_msi_ack modification.

I've been able to get past the ahci stall, and run through ~10 suspend
/ resume cycles with this fix.
Additional tests are warranted, and I'll run through an automated
sleep / wake script I have to make sure this fix holds over time.

Thanks for this.

Ben

On Thu, Sep 6, 2012 at 6:22 AM, Jan Beulich <JBeulich@suse.com> wrote:
>>>> On 04.09.12 at 14:27, Ben Guthro <ben@guthro.net> wrote:
>> I've put the console log of this test run here:
>> https://citrix.sharefile.com/d/sdc383e252fb41c5a
>>
>> (again, so as not to clog everyone's inbox)
>>
>> I have not yet gone through the log in its entirety yet, but thought I
>> would first send it to you to see if you had something in particular
>> you were looking for.
>>
>> The file name is console-S3-MSI.txt
>
> I think that nailed it: pci_restore_msi_state() passed a pointer
> to the stored entry->msg to write_msi_msg(), but with interrupt
> remapping enabled that function's call to
> iommu_update_ire_from_msi() alters the passed in struct
> msi_msg instance. As the stored value is used for nothing but
> a subsequent (second) restore, a problem would only arise if
> between the two saves to further writing of the stored entry
> would occur (i.e. no intermediate call to set_msi_affinity()).
>
> Attached the advertised next version of the debugging patch
> (printks - slightly altered - left in to catch eventual further
> problems or to deal with my analysis being wrong; none of the
> "bogus!" ones should now trigger anymore). If this works, I'd
> be curious to see how much of your other workaround code
> you could then remove without breaking things again.
>
> Jan
>

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

From xen-devel-bounces@lists.xen.org Thu Sep 06 11:51:29 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 2012 11:51:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9acD-0005AK-VI; Thu, 06 Sep 2012 11:51:21 +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 1T9acC-0005AA-ED
	for xen-devel@lists.xen.org; Thu, 06 Sep 2012 11:51:20 +0000
Received: from [85.158.139.83:5439] by server-2.bemta-5.messagelabs.com id
	41/7A-11456-73E88405; Thu, 06 Sep 2012 11:51:19 +0000
X-Env-Sender: ben.guthro@gmail.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1346932277!21586364!1
X-Originating-IP: [209.85.223.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4836 invoked from network); 6 Sep 2012 11:51:18 -0000
Received: from mail-ie0-f173.google.com (HELO mail-ie0-f173.google.com)
	(209.85.223.173)
	by server-16.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Sep 2012 11:51:18 -0000
Received: by iebc10 with SMTP id c10so3482095ieb.32
	for <xen-devel@lists.xen.org>; Thu, 06 Sep 2012 04:51:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
	bh=4w/tVaw4kdM74NmyqiYHb4i6bHATL6F3UDrDV+ib2Jo=;
	b=JeNfDw5/D0BzAcNDlXyQqV3V7XeBqB4NfuqwwT0H6clxPtZm9YmGA/l6LWQNgG8PHY
	qjsOiI88BMNtDLJAjprVaOoZZfv92xynDvbQViBbN3j7RKFdtnNHTX77GKjgDhHRa1Nx
	O8GfjvcFOYZzezyipFX3RUllxZgAhvefSo24A1s41DtXSXLdbaeaEKSUYvQ0KEEpsJVb
	uapCY32uomxujE5CZACGEruFoVCjBHWE8s9lzrsuz2jfp8Xpj/HfQ1GkQWFl7bEjw2en
	76bhUzTxJdJm3BGTXL/hTQ5UryJbbRJrO/Ztj8FgW7yIYcFyvpli8L02qgPAAHng5dBL
	Q4OA==
MIME-Version: 1.0
Received: by 10.50.180.129 with SMTP id do1mr2468887igc.28.1346932277083; Thu,
	06 Sep 2012 04:51:17 -0700 (PDT)
Received: by 10.64.28.203 with HTTP; Thu, 6 Sep 2012 04:51:16 -0700 (PDT)
In-Reply-To: <CAOvdn6WrNK1Jn_Y_P7C3AwX6ApVcgzacLA_x-u=xBQtebnuPxA@mail.gmail.com>
References: <CAOvdn6WwgBD-2yf1uu3m9-16=Tb5KUrybXf2KibtnxKbP7YtwA@mail.gmail.com>
	<CAOvdn6UBW-yTOMd3YSf5M9JiHLRivyaKL-qzcKG8epszqaKmGg@mail.gmail.com>
	<20120807163320.GC15053@phenom.dumpdata.com>
	<CAOvdn6XcRGKtJxGwJO8J+ZBJr89wfTLc1woW5rhtMM540H9h1w@mail.gmail.com>
	<CAOvdn6XUoSeGoo7X=AJ1kpDxZB9HZEv+TJ4v-=FHcyR4=CHK-w@mail.gmail.com>
	<502240F302000078000937A6@nat28.tlf.novell.com>
	<CAOvdn6WN3kxC8Bb9g6MpfLULu47EGSGCtajPc-SFeJ-8VSUQDQ@mail.gmail.com>
	<CAOvdn6Xk1inm1hU55i0phU2qvSWyJLNoyDdn43biBAY2OewPtw@mail.gmail.com>
	<5023F5400200007800093F4E@nat28.tlf.novell.com>
	<CAOvdn6U-f3C4U8xVPvDyRFkFFLkbfiCXg_n+9zgA9V5u+q5jfw@mail.gmail.com>
	<5023F8B80200007800093F8C@nat28.tlf.novell.com>
	<CAOvdn6XKHfete_+=Hkvt20G7_cJ-4i8+9j9YD30OxzQ16Ru-+g@mail.gmail.com>
	<5024CB720200007800094124@nat28.tlf.novell.com>
	<CAOvdn6VVJdhWVYa-gNVt3euE4AbGi1TijUCUd1wGzv0SCWEUYA@mail.gmail.com>
	<CAOvdn6USnG9Y4MNBhrDZmob0oJ8BgFfKTvFEhcKbXDxNmzfZ-Q@mail.gmail.com>
	<502B75BA0200007800094FD4@nat28.tlf.novell.com>
	<CAOvdn6Ww5oEj6Xg=XT4dWCYWUBuOdPqLz-CqNjz4HmCScE+==g@mail.gmail.com>
	<CAOvdn6Wsjds_dmZ0dwDTYmD-o-OqjBH5-b9mitAuUADE+A4_ag@mail.gmail.com>
	<502BB8FD02000078000951E0@nat28.tlf.novell.com>
	<CAOvdn6VD6bp13F-tvYdkBsj4hkhE7PTGZrapndtdHrDKeZqccg@mail.gmail.com>
	<502CCC0002000078000955C4@nat28.tlf.novell.com>
	<CAOvdn6VEuX7R2_wz74ZvCxMjC-=YUir9kP5sdxEVaKVspRUd_w@mail.gmail.com>
	<502CF0A8020000780009574E@nat28.tlf.novell.com>
	<CAOvdn6VsZvn_1TCWYeuyY5YuTcP8=miK2KwE4583nsj6Qjb_vg@mail.gmail.com>
	<504494FB0200007800098398@nat28.tlf.novell.com>
	<CAOvdn6UT13qvWbMyfZkWND03RoVKVSgb6wW4yqTUpuBYEX01Dg@mail.gmail.com>
	<5048958D02000078000993EB@nat28.tlf.novell.com>
	<CAOvdn6WrNK1Jn_Y_P7C3AwX6ApVcgzacLA_x-u=xBQtebnuPxA@mail.gmail.com>
Date: Thu, 6 Sep 2012 07:51:16 -0400
X-Google-Sender-Auth: G4CF84VFNwxexGVfsuoCgo-hWuM
Message-ID: <CAOvdn6VDx_8zw4XpEEga6AHHmm=qOXS_fy11wE9+8n62Tg_fUA@mail.gmail.com>
From: Ben Guthro <ben@guthro.net>
To: Jan Beulich <JBeulich@suse.com>
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>, john.baboval@citrix.com,
	Thomas Goetz <thomas.goetz@citrix.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen4.2 S3 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

Additionally - I was able to use this patch on its own, without any of
the prior debug patch - which, as you pointed out before, ended up
being unnecessary.

On Thu, Sep 6, 2012 at 7:48 AM, Ben Guthro <ben@guthro.net> wrote:
> Fantastic!
>
> Initial tests are very good, with this dma_msi_ack modification.
>
> I've been able to get past the ahci stall, and run through ~10 suspend
> / resume cycles with this fix.
> Additional tests are warranted, and I'll run through an automated
> sleep / wake script I have to make sure this fix holds over time.
>
> Thanks for this.
>
> Ben
>
> On Thu, Sep 6, 2012 at 6:22 AM, Jan Beulich <JBeulich@suse.com> wrote:
>>>>> On 04.09.12 at 14:27, Ben Guthro <ben@guthro.net> wrote:
>>> I've put the console log of this test run here:
>>> https://citrix.sharefile.com/d/sdc383e252fb41c5a
>>>
>>> (again, so as not to clog everyone's inbox)
>>>
>>> I have not yet gone through the log in its entirety yet, but thought I
>>> would first send it to you to see if you had something in particular
>>> you were looking for.
>>>
>>> The file name is console-S3-MSI.txt
>>
>> I think that nailed it: pci_restore_msi_state() passed a pointer
>> to the stored entry->msg to write_msi_msg(), but with interrupt
>> remapping enabled that function's call to
>> iommu_update_ire_from_msi() alters the passed in struct
>> msi_msg instance. As the stored value is used for nothing but
>> a subsequent (second) restore, a problem would only arise if
>> between the two saves to further writing of the stored entry
>> would occur (i.e. no intermediate call to set_msi_affinity()).
>>
>> Attached the advertised next version of the debugging patch
>> (printks - slightly altered - left in to catch eventual further
>> problems or to deal with my analysis being wrong; none of the
>> "bogus!" ones should now trigger anymore). If this works, I'd
>> be curious to see how much of your other workaround code
>> you could then remove without breaking things again.
>>
>> Jan
>>

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

From xen-devel-bounces@lists.xen.org Thu Sep 06 11:51:29 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 2012 11:51:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9acD-0005AK-VI; Thu, 06 Sep 2012 11:51:21 +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 1T9acC-0005AA-ED
	for xen-devel@lists.xen.org; Thu, 06 Sep 2012 11:51:20 +0000
Received: from [85.158.139.83:5439] by server-2.bemta-5.messagelabs.com id
	41/7A-11456-73E88405; Thu, 06 Sep 2012 11:51:19 +0000
X-Env-Sender: ben.guthro@gmail.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1346932277!21586364!1
X-Originating-IP: [209.85.223.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4836 invoked from network); 6 Sep 2012 11:51:18 -0000
Received: from mail-ie0-f173.google.com (HELO mail-ie0-f173.google.com)
	(209.85.223.173)
	by server-16.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Sep 2012 11:51:18 -0000
Received: by iebc10 with SMTP id c10so3482095ieb.32
	for <xen-devel@lists.xen.org>; Thu, 06 Sep 2012 04:51:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
	bh=4w/tVaw4kdM74NmyqiYHb4i6bHATL6F3UDrDV+ib2Jo=;
	b=JeNfDw5/D0BzAcNDlXyQqV3V7XeBqB4NfuqwwT0H6clxPtZm9YmGA/l6LWQNgG8PHY
	qjsOiI88BMNtDLJAjprVaOoZZfv92xynDvbQViBbN3j7RKFdtnNHTX77GKjgDhHRa1Nx
	O8GfjvcFOYZzezyipFX3RUllxZgAhvefSo24A1s41DtXSXLdbaeaEKSUYvQ0KEEpsJVb
	uapCY32uomxujE5CZACGEruFoVCjBHWE8s9lzrsuz2jfp8Xpj/HfQ1GkQWFl7bEjw2en
	76bhUzTxJdJm3BGTXL/hTQ5UryJbbRJrO/Ztj8FgW7yIYcFyvpli8L02qgPAAHng5dBL
	Q4OA==
MIME-Version: 1.0
Received: by 10.50.180.129 with SMTP id do1mr2468887igc.28.1346932277083; Thu,
	06 Sep 2012 04:51:17 -0700 (PDT)
Received: by 10.64.28.203 with HTTP; Thu, 6 Sep 2012 04:51:16 -0700 (PDT)
In-Reply-To: <CAOvdn6WrNK1Jn_Y_P7C3AwX6ApVcgzacLA_x-u=xBQtebnuPxA@mail.gmail.com>
References: <CAOvdn6WwgBD-2yf1uu3m9-16=Tb5KUrybXf2KibtnxKbP7YtwA@mail.gmail.com>
	<CAOvdn6UBW-yTOMd3YSf5M9JiHLRivyaKL-qzcKG8epszqaKmGg@mail.gmail.com>
	<20120807163320.GC15053@phenom.dumpdata.com>
	<CAOvdn6XcRGKtJxGwJO8J+ZBJr89wfTLc1woW5rhtMM540H9h1w@mail.gmail.com>
	<CAOvdn6XUoSeGoo7X=AJ1kpDxZB9HZEv+TJ4v-=FHcyR4=CHK-w@mail.gmail.com>
	<502240F302000078000937A6@nat28.tlf.novell.com>
	<CAOvdn6WN3kxC8Bb9g6MpfLULu47EGSGCtajPc-SFeJ-8VSUQDQ@mail.gmail.com>
	<CAOvdn6Xk1inm1hU55i0phU2qvSWyJLNoyDdn43biBAY2OewPtw@mail.gmail.com>
	<5023F5400200007800093F4E@nat28.tlf.novell.com>
	<CAOvdn6U-f3C4U8xVPvDyRFkFFLkbfiCXg_n+9zgA9V5u+q5jfw@mail.gmail.com>
	<5023F8B80200007800093F8C@nat28.tlf.novell.com>
	<CAOvdn6XKHfete_+=Hkvt20G7_cJ-4i8+9j9YD30OxzQ16Ru-+g@mail.gmail.com>
	<5024CB720200007800094124@nat28.tlf.novell.com>
	<CAOvdn6VVJdhWVYa-gNVt3euE4AbGi1TijUCUd1wGzv0SCWEUYA@mail.gmail.com>
	<CAOvdn6USnG9Y4MNBhrDZmob0oJ8BgFfKTvFEhcKbXDxNmzfZ-Q@mail.gmail.com>
	<502B75BA0200007800094FD4@nat28.tlf.novell.com>
	<CAOvdn6Ww5oEj6Xg=XT4dWCYWUBuOdPqLz-CqNjz4HmCScE+==g@mail.gmail.com>
	<CAOvdn6Wsjds_dmZ0dwDTYmD-o-OqjBH5-b9mitAuUADE+A4_ag@mail.gmail.com>
	<502BB8FD02000078000951E0@nat28.tlf.novell.com>
	<CAOvdn6VD6bp13F-tvYdkBsj4hkhE7PTGZrapndtdHrDKeZqccg@mail.gmail.com>
	<502CCC0002000078000955C4@nat28.tlf.novell.com>
	<CAOvdn6VEuX7R2_wz74ZvCxMjC-=YUir9kP5sdxEVaKVspRUd_w@mail.gmail.com>
	<502CF0A8020000780009574E@nat28.tlf.novell.com>
	<CAOvdn6VsZvn_1TCWYeuyY5YuTcP8=miK2KwE4583nsj6Qjb_vg@mail.gmail.com>
	<504494FB0200007800098398@nat28.tlf.novell.com>
	<CAOvdn6UT13qvWbMyfZkWND03RoVKVSgb6wW4yqTUpuBYEX01Dg@mail.gmail.com>
	<5048958D02000078000993EB@nat28.tlf.novell.com>
	<CAOvdn6WrNK1Jn_Y_P7C3AwX6ApVcgzacLA_x-u=xBQtebnuPxA@mail.gmail.com>
Date: Thu, 6 Sep 2012 07:51:16 -0400
X-Google-Sender-Auth: G4CF84VFNwxexGVfsuoCgo-hWuM
Message-ID: <CAOvdn6VDx_8zw4XpEEga6AHHmm=qOXS_fy11wE9+8n62Tg_fUA@mail.gmail.com>
From: Ben Guthro <ben@guthro.net>
To: Jan Beulich <JBeulich@suse.com>
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>, john.baboval@citrix.com,
	Thomas Goetz <thomas.goetz@citrix.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen4.2 S3 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

Additionally - I was able to use this patch on its own, without any of
the prior debug patch - which, as you pointed out before, ended up
being unnecessary.

On Thu, Sep 6, 2012 at 7:48 AM, Ben Guthro <ben@guthro.net> wrote:
> Fantastic!
>
> Initial tests are very good, with this dma_msi_ack modification.
>
> I've been able to get past the ahci stall, and run through ~10 suspend
> / resume cycles with this fix.
> Additional tests are warranted, and I'll run through an automated
> sleep / wake script I have to make sure this fix holds over time.
>
> Thanks for this.
>
> Ben
>
> On Thu, Sep 6, 2012 at 6:22 AM, Jan Beulich <JBeulich@suse.com> wrote:
>>>>> On 04.09.12 at 14:27, Ben Guthro <ben@guthro.net> wrote:
>>> I've put the console log of this test run here:
>>> https://citrix.sharefile.com/d/sdc383e252fb41c5a
>>>
>>> (again, so as not to clog everyone's inbox)
>>>
>>> I have not yet gone through the log in its entirety yet, but thought I
>>> would first send it to you to see if you had something in particular
>>> you were looking for.
>>>
>>> The file name is console-S3-MSI.txt
>>
>> I think that nailed it: pci_restore_msi_state() passed a pointer
>> to the stored entry->msg to write_msi_msg(), but with interrupt
>> remapping enabled that function's call to
>> iommu_update_ire_from_msi() alters the passed in struct
>> msi_msg instance. As the stored value is used for nothing but
>> a subsequent (second) restore, a problem would only arise if
>> between the two saves to further writing of the stored entry
>> would occur (i.e. no intermediate call to set_msi_affinity()).
>>
>> Attached the advertised next version of the debugging patch
>> (printks - slightly altered - left in to catch eventual further
>> problems or to deal with my analysis being wrong; none of the
>> "bogus!" ones should now trigger anymore). If this works, I'd
>> be curious to see how much of your other workaround code
>> you could then remove without breaking things again.
>>
>> Jan
>>

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

From xen-devel-bounces@lists.xen.org Thu Sep 06 11:54:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 2012 11:54:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9aem-0005Lx-Hl; Thu, 06 Sep 2012 11:54:00 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1T9ael-0005Lp-B5
	for xen-devel@lists.xen.org; Thu, 06 Sep 2012 11:53:59 +0000
Received: from [85.158.138.51:2777] by server-12.bemta-3.messagelabs.com id
	7A/94-10384-6DE88405; Thu, 06 Sep 2012 11:53:58 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1346932437!21095096!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTE5NzY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15859 invoked from network); 6 Sep 2012 11:53:58 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Sep 2012 11:53:58 -0000
X-IronPort-AV: E=Sophos;i="4.80,380,1344211200"; d="scan'208";a="14383911"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Sep 2012 11:53: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.279.1; Thu, 6 Sep 2012
	12:53:57 +0100
Message-ID: <1346932435.30018.2.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Tim Deegan <tim@xen.org>
Date: Thu, 6 Sep 2012 12:53:55 +0100
In-Reply-To: <20120906114741.GF56463@ocelot.phlegethon.org>
References: <1346678886.32462.9.camel@zakaz.uk.xensource.com>
	<1346679056-8108-6-git-send-email-ian.campbell@citrix.com>
	<20120906114741.GF56463@ocelot.phlegethon.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 06/16] arm: parse modules from DT during
 early boot.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-09-06 at 12:47 +0100, Tim Deegan wrote:
> At 13:30 +0000 on 03 Sep (1346679046), Ian Campbell wrote:
> > The bootloader should populate /chosen/nr-modules with the number of
> > modules and then for each module 0..nr-modules-1 it should populate
> > /chosen/moduleN-{start,end} with the physical address of the module.
> 
> The code below looks like it's expecting the modules to be numbered from
> 1, not from 0.

Yes, looks like I'd forgotten that by the time I wrote the commit
message. Thanks.

Ian.

> 
> Tim.
> 
> > The hypervisor allows for 2 modules (kernel and initrd). Currently we
> > don't do anything with them.
> > 
> > Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> > ---
> >  xen/common/device_tree.c      |   57 +++++++++++++++++++++++++++++++++++++++++
> >  xen/include/xen/device_tree.h |    7 +++++
> >  2 files changed, 64 insertions(+), 0 deletions(-)
> > 
> > diff --git a/xen/common/device_tree.c b/xen/common/device_tree.c
> > index 3d1f0f4..226e3f3 100644
> > --- a/xen/common/device_tree.c
> > +++ b/xen/common/device_tree.c
> > @@ -229,6 +229,61 @@ static void __init process_memory_node(const void *fdt, int node,
> >      }
> >  }
> >  
> > +static void __init process_chosen_node(const void *fdt, int node,
> > +                                       const char *name,
> > +                                       u32 address_cells, u32 size_cells)
> > +{
> > +    const struct fdt_property *prop;
> > +    const u32 *cell;
> > +    paddr_t size;
> > +    int i, nr_modules;
> > +
> > +    prop = fdt_get_property(fdt, node, "nr-modules", NULL);
> > +    if ( !prop )
> > +    {
> > +        early_info.modules.nr_mods = 0;
> > +        return;
> > +    }
> > +
> > +    cell = (const u32 *)prop->data;
> > +    get_val(&cell, 1, (u64*)&nr_modules);
> > +
> > +    if ( nr_modules > NR_MODULES )
> > +    {
> > +        early_panic("too many modules %d > %d\n", nr_modules, NR_MODULES);
> > +    }
> > +
> > +    for ( i = 0; i < nr_modules; i++ )
> > +    {
> > +        struct membank *mod = &early_info.modules.module[i];
> > +        /* longest prop name is "start", single digit numbers of modules */
> > +        char propname[strlen("moduleX-start") + 1];
> > +
> > +        BUILD_BUG_ON(NR_MODULES > 9);
> > +
> > +        snprintf(propname, sizeof(propname), "module%d-start", i+1);
> > +        prop = fdt_get_property(fdt, node, propname, NULL);
> > +        if ( !prop )
> > +            early_panic("no start for module %d\n", i);
> > +
> > +        cell = (const u32 *)prop->data;
> > +        device_tree_get_reg(&cell, address_cells, size_cells,
> > +                            &mod->start, &size);
> > +
> > +        snprintf(propname, sizeof(propname), "module%d-end", i+1);
> > +        prop = fdt_get_property(fdt, node, propname, NULL);
> > +        if ( !prop )
> > +            early_panic("no end for module %d\n", i);
> > +
> > +        cell = (const u32 *)prop->data;
> > +        device_tree_get_reg(&cell, address_cells, size_cells,
> > +                            &mod->size, &size);
> > +        mod->size -= mod->start;
> > +    }
> > +
> > +    early_info.modules.nr_mods = nr_modules;
> > +}
> > +
> >  static int __init early_scan_node(const void *fdt,
> >                                    int node, const char *name, int depth,
> >                                    u32 address_cells, u32 size_cells,
> > @@ -236,6 +291,8 @@ static int __init early_scan_node(const void *fdt,
> >  {
> >      if ( device_tree_node_matches(fdt, node, "memory") )
> >          process_memory_node(fdt, node, name, address_cells, size_cells);
> > +    else if ( device_tree_node_matches(fdt, node, "chosen") )
> > +        process_chosen_node(fdt, node, name, address_cells, size_cells);
> >  
> >      return 0;
> >  }
> > diff --git a/xen/include/xen/device_tree.h b/xen/include/xen/device_tree.h
> > index 4d010c0..585fcc9 100644
> > --- a/xen/include/xen/device_tree.h
> > +++ b/xen/include/xen/device_tree.h
> > @@ -15,6 +15,7 @@
> >  #define DEVICE_TREE_MAX_DEPTH 16
> >  
> >  #define NR_MEM_BANKS 8
> > +#define NR_MODULES 2
> >  
> >  struct membank {
> >      paddr_t start;
> > @@ -26,8 +27,14 @@ struct dt_mem_info {
> >      struct membank bank[NR_MEM_BANKS];
> >  };
> >  
> > +struct dt_module_info {
> > +    int nr_mods;
> > +    struct membank module[NR_MODULES];
> > +};
> > +
> >  struct dt_early_info {
> >      struct dt_mem_info mem;
> > +    struct dt_module_info modules;
> >  };
> >  
> >  typedef int (*device_tree_node_func)(const void *fdt,
> > -- 
> > 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 Sep 06 11:54:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 2012 11:54:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9aem-0005Lx-Hl; Thu, 06 Sep 2012 11:54:00 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1T9ael-0005Lp-B5
	for xen-devel@lists.xen.org; Thu, 06 Sep 2012 11:53:59 +0000
Received: from [85.158.138.51:2777] by server-12.bemta-3.messagelabs.com id
	7A/94-10384-6DE88405; Thu, 06 Sep 2012 11:53:58 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1346932437!21095096!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTE5NzY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15859 invoked from network); 6 Sep 2012 11:53:58 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Sep 2012 11:53:58 -0000
X-IronPort-AV: E=Sophos;i="4.80,380,1344211200"; d="scan'208";a="14383911"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Sep 2012 11:53: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.279.1; Thu, 6 Sep 2012
	12:53:57 +0100
Message-ID: <1346932435.30018.2.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Tim Deegan <tim@xen.org>
Date: Thu, 6 Sep 2012 12:53:55 +0100
In-Reply-To: <20120906114741.GF56463@ocelot.phlegethon.org>
References: <1346678886.32462.9.camel@zakaz.uk.xensource.com>
	<1346679056-8108-6-git-send-email-ian.campbell@citrix.com>
	<20120906114741.GF56463@ocelot.phlegethon.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 06/16] arm: parse modules from DT during
 early boot.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-09-06 at 12:47 +0100, Tim Deegan wrote:
> At 13:30 +0000 on 03 Sep (1346679046), Ian Campbell wrote:
> > The bootloader should populate /chosen/nr-modules with the number of
> > modules and then for each module 0..nr-modules-1 it should populate
> > /chosen/moduleN-{start,end} with the physical address of the module.
> 
> The code below looks like it's expecting the modules to be numbered from
> 1, not from 0.

Yes, looks like I'd forgotten that by the time I wrote the commit
message. Thanks.

Ian.

> 
> Tim.
> 
> > The hypervisor allows for 2 modules (kernel and initrd). Currently we
> > don't do anything with them.
> > 
> > Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> > ---
> >  xen/common/device_tree.c      |   57 +++++++++++++++++++++++++++++++++++++++++
> >  xen/include/xen/device_tree.h |    7 +++++
> >  2 files changed, 64 insertions(+), 0 deletions(-)
> > 
> > diff --git a/xen/common/device_tree.c b/xen/common/device_tree.c
> > index 3d1f0f4..226e3f3 100644
> > --- a/xen/common/device_tree.c
> > +++ b/xen/common/device_tree.c
> > @@ -229,6 +229,61 @@ static void __init process_memory_node(const void *fdt, int node,
> >      }
> >  }
> >  
> > +static void __init process_chosen_node(const void *fdt, int node,
> > +                                       const char *name,
> > +                                       u32 address_cells, u32 size_cells)
> > +{
> > +    const struct fdt_property *prop;
> > +    const u32 *cell;
> > +    paddr_t size;
> > +    int i, nr_modules;
> > +
> > +    prop = fdt_get_property(fdt, node, "nr-modules", NULL);
> > +    if ( !prop )
> > +    {
> > +        early_info.modules.nr_mods = 0;
> > +        return;
> > +    }
> > +
> > +    cell = (const u32 *)prop->data;
> > +    get_val(&cell, 1, (u64*)&nr_modules);
> > +
> > +    if ( nr_modules > NR_MODULES )
> > +    {
> > +        early_panic("too many modules %d > %d\n", nr_modules, NR_MODULES);
> > +    }
> > +
> > +    for ( i = 0; i < nr_modules; i++ )
> > +    {
> > +        struct membank *mod = &early_info.modules.module[i];
> > +        /* longest prop name is "start", single digit numbers of modules */
> > +        char propname[strlen("moduleX-start") + 1];
> > +
> > +        BUILD_BUG_ON(NR_MODULES > 9);
> > +
> > +        snprintf(propname, sizeof(propname), "module%d-start", i+1);
> > +        prop = fdt_get_property(fdt, node, propname, NULL);
> > +        if ( !prop )
> > +            early_panic("no start for module %d\n", i);
> > +
> > +        cell = (const u32 *)prop->data;
> > +        device_tree_get_reg(&cell, address_cells, size_cells,
> > +                            &mod->start, &size);
> > +
> > +        snprintf(propname, sizeof(propname), "module%d-end", i+1);
> > +        prop = fdt_get_property(fdt, node, propname, NULL);
> > +        if ( !prop )
> > +            early_panic("no end for module %d\n", i);
> > +
> > +        cell = (const u32 *)prop->data;
> > +        device_tree_get_reg(&cell, address_cells, size_cells,
> > +                            &mod->size, &size);
> > +        mod->size -= mod->start;
> > +    }
> > +
> > +    early_info.modules.nr_mods = nr_modules;
> > +}
> > +
> >  static int __init early_scan_node(const void *fdt,
> >                                    int node, const char *name, int depth,
> >                                    u32 address_cells, u32 size_cells,
> > @@ -236,6 +291,8 @@ static int __init early_scan_node(const void *fdt,
> >  {
> >      if ( device_tree_node_matches(fdt, node, "memory") )
> >          process_memory_node(fdt, node, name, address_cells, size_cells);
> > +    else if ( device_tree_node_matches(fdt, node, "chosen") )
> > +        process_chosen_node(fdt, node, name, address_cells, size_cells);
> >  
> >      return 0;
> >  }
> > diff --git a/xen/include/xen/device_tree.h b/xen/include/xen/device_tree.h
> > index 4d010c0..585fcc9 100644
> > --- a/xen/include/xen/device_tree.h
> > +++ b/xen/include/xen/device_tree.h
> > @@ -15,6 +15,7 @@
> >  #define DEVICE_TREE_MAX_DEPTH 16
> >  
> >  #define NR_MEM_BANKS 8
> > +#define NR_MODULES 2
> >  
> >  struct membank {
> >      paddr_t start;
> > @@ -26,8 +27,14 @@ struct dt_mem_info {
> >      struct membank bank[NR_MEM_BANKS];
> >  };
> >  
> > +struct dt_module_info {
> > +    int nr_mods;
> > +    struct membank module[NR_MODULES];
> > +};
> > +
> >  struct dt_early_info {
> >      struct dt_mem_info mem;
> > +    struct dt_module_info modules;
> >  };
> >  
> >  typedef int (*device_tree_node_func)(const void *fdt,
> > -- 
> > 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 Sep 06 11:56:58 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 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 1T9ahX-0005Uk-4K; Thu, 06 Sep 2012 11:56:51 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1T9ahV-0005Uc-ES
	for xen-devel@lists.xen.org; Thu, 06 Sep 2012 11:56:49 +0000
Received: from [85.158.143.99:17472] by server-3.bemta-4.messagelabs.com id
	EE/08-08232-08F88405; Thu, 06 Sep 2012 11:56:48 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1346932606!28881998!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNzcyMDY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14945 invoked from network); 6 Sep 2012 11:56:48 -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;
	6 Sep 2012 11:56:48 -0000
X-IronPort-AV: E=Sophos;i="4.80,380,1344211200"; d="scan'208";a="207268016"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Sep 2012 11:56:46 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1;
	Thu, 6 Sep 2012 07:56:46 -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 1T9ahR-0007Uh-PK;
	Thu, 06 Sep 2012 12:56:45 +0100
MIME-Version: 1.0
X-Mercurial-Node: 22d5e100131d1576d455780b9fdf36eacd453445
Message-ID: <22d5e100131d1576d455.1346932605@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Thu, 6 Sep 2012 12:56:45 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Cc: tim@xen.org, Dario Faggioli <dario.faggioli@citrix.com>, keir@xen.org,
	Jan Beulich <JBeulich@suse.com>
Subject: [Xen-devel] [PATCH] xen: clamp bitmaps to correct number of bits
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 1346932601 -3600
# Node ID 22d5e100131d1576d455780b9fdf36eacd453445
# Parent  7db66f2a0242c2dca66dca9165cb58a98d92dba9
xen: clamp bitmaps to correct number of bits

Valgrind running xl create reports:
 ==24777== Invalid read of size 4
 ==24777==    at 0x4072805: libxl__get_numa_candidate (libxl_numa.c:203)
 ==24777==    by 0x40680B6: libxl__build_pre (libxl_dom.c:166)
 ==24777==    by 0x405B82E: libxl__domain_build (libxl_create.c:323)
 ==24777==    by 0x405BB9C: domcreate_bootloader_done (libxl_create.c:747)
 ==24777==    by 0x407AD27: bootloader_local_detached_cb (libxl_bootloader.c:281)
 ==24777==    by 0x40508D8: local_device_detach_cb (libxl.c:2470)
 ==24777==    by 0x4052B10: libxl__device_disk_local_initiate_detach (libxl.c:2445)
 ==24777==    by 0x407AE9F: bootloader_callback (libxl_bootloader.c:265)
 ==24777==    by 0x407C69A: libxl__bootloader_run (libxl_bootloader.c:392)
 ==24777==    by 0x405CB24: do_domain_create (libxl_create.c:687)
 ==24777==    by 0x405CC5E: libxl_domain_create_new (libxl_create.c:1177)
 ==24777==    by 0x805BDE2: create_domain (xl_cmdimpl.c:1812)
 ==24777==  Address 0x42dbdd8 is 8 bytes after a block of size 48 alloc'd
 ==24777==    at 0x4023340: calloc (vg_replace_malloc.c:593)
 ==24777==    by 0x406D479: libxl__zalloc (libxl_internal.c:88)
 ==24777==    by 0x404EF38: libxl_get_cpu_topology (libxl.c:3707)
 ==24777==    by 0x4072232: libxl__get_numa_candidate (libxl_numa.c:314)
 ==24777==    by 0x40680B6: libxl__build_pre (libxl_dom.c:166)
 ==24777==    by 0x405B82E: libxl__domain_build (libxl_create.c:323)
 ==24777==    by 0x405BB9C: domcreate_bootloader_done (libxl_create.c:747)
 ==24777==    by 0x407AD27: bootloader_local_detached_cb (libxl_bootloader.c:281)
 ==24777==    by 0x40508D8: local_device_detach_cb (libxl.c:2470)
 ==24777==    by 0x4052B10: libxl__device_disk_local_initiate_detach (libxl.c:2445)
 ==24777==    by 0x407AE9F: bootloader_callback (libxl_bootloader.c:265)
 ==24777==    by 0x407C69A: libxl__bootloader_run (libxl_bootloader.c:392)

This is because with nr_cpus=4 the bitmask returned from Xen
contains 0xff rather than 0x0f bit our bitmap walking routines (e.g.
libxl_for_each_set_bit) round up to the next byte (so it iterates
e.g. 8 times not 4). This then causes us to access of the end of
whatever array we are walking through each set bit for.

The principal of least surprise suggests that these bits ought not to
be set and this is not a hot path so fix this at the hypervisor layer
by clamping the bits in the returned bitmap to the correct limit.

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

The impact of this seems to be fairly benign in practice, so I'm not
sure about it for 4.2.0. Could leave to 4.2.1?

Dario,

Any chance you could look at the libxl bitmap functions in 4.3 and
make them use the right limit (i.e. nr_bits not (nr_bits+7)/8?

Thanks,
Ian.

diff -r 7db66f2a0242 -r 22d5e100131d xen/common/bitmap.c
--- a/xen/common/bitmap.c	Thu Sep 06 10:44:46 2012 +0100
+++ b/xen/common/bitmap.c	Thu Sep 06 12:56:41 2012 +0100
@@ -38,6 +38,17 @@
  * for the best explanations of this ordering.
  */
 
+/* Ensure that the last byte is zero from nbits onwards. */
+static void clamp_last_byte(uint8_t *bp, int nbits)
+{
+	int lastbyte = nbits/8;
+	int remainder = nbits % 8;
+	int mask = ((1U<<remainder)-1)&0xff;
+
+	if (remainder)
+		bp[lastbyte] &= mask;
+}
+
 int __bitmap_empty(const unsigned long *bitmap, int bits)
 {
 	int k, lim = bits/BITS_PER_LONG;
@@ -485,6 +496,7 @@ void bitmap_long_to_byte(uint8_t *bp, co
 			nbits -= 8;
 		}
 	}
+	clamp_last_byte(bp, nbits);
 }
 
 void bitmap_byte_to_long(unsigned long *lp, const uint8_t *bp, int nbits)
@@ -507,6 +519,7 @@ void bitmap_byte_to_long(unsigned long *
 void bitmap_long_to_byte(uint8_t *bp, const unsigned long *lp, int nbits)
 {
 	memcpy(bp, lp, (nbits+7)/8);
+	clamp_last_byte(bp, nbits);
 }
 
 void bitmap_byte_to_long(unsigned long *lp, const uint8_t *bp, int nbits)

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

From xen-devel-bounces@lists.xen.org Thu Sep 06 11:56:58 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 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 1T9ahX-0005Uk-4K; Thu, 06 Sep 2012 11:56:51 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1T9ahV-0005Uc-ES
	for xen-devel@lists.xen.org; Thu, 06 Sep 2012 11:56:49 +0000
Received: from [85.158.143.99:17472] by server-3.bemta-4.messagelabs.com id
	EE/08-08232-08F88405; Thu, 06 Sep 2012 11:56:48 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1346932606!28881998!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNzcyMDY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14945 invoked from network); 6 Sep 2012 11:56:48 -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;
	6 Sep 2012 11:56:48 -0000
X-IronPort-AV: E=Sophos;i="4.80,380,1344211200"; d="scan'208";a="207268016"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Sep 2012 11:56:46 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1;
	Thu, 6 Sep 2012 07:56:46 -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 1T9ahR-0007Uh-PK;
	Thu, 06 Sep 2012 12:56:45 +0100
MIME-Version: 1.0
X-Mercurial-Node: 22d5e100131d1576d455780b9fdf36eacd453445
Message-ID: <22d5e100131d1576d455.1346932605@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Thu, 6 Sep 2012 12:56:45 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Cc: tim@xen.org, Dario Faggioli <dario.faggioli@citrix.com>, keir@xen.org,
	Jan Beulich <JBeulich@suse.com>
Subject: [Xen-devel] [PATCH] xen: clamp bitmaps to correct number of bits
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 1346932601 -3600
# Node ID 22d5e100131d1576d455780b9fdf36eacd453445
# Parent  7db66f2a0242c2dca66dca9165cb58a98d92dba9
xen: clamp bitmaps to correct number of bits

Valgrind running xl create reports:
 ==24777== Invalid read of size 4
 ==24777==    at 0x4072805: libxl__get_numa_candidate (libxl_numa.c:203)
 ==24777==    by 0x40680B6: libxl__build_pre (libxl_dom.c:166)
 ==24777==    by 0x405B82E: libxl__domain_build (libxl_create.c:323)
 ==24777==    by 0x405BB9C: domcreate_bootloader_done (libxl_create.c:747)
 ==24777==    by 0x407AD27: bootloader_local_detached_cb (libxl_bootloader.c:281)
 ==24777==    by 0x40508D8: local_device_detach_cb (libxl.c:2470)
 ==24777==    by 0x4052B10: libxl__device_disk_local_initiate_detach (libxl.c:2445)
 ==24777==    by 0x407AE9F: bootloader_callback (libxl_bootloader.c:265)
 ==24777==    by 0x407C69A: libxl__bootloader_run (libxl_bootloader.c:392)
 ==24777==    by 0x405CB24: do_domain_create (libxl_create.c:687)
 ==24777==    by 0x405CC5E: libxl_domain_create_new (libxl_create.c:1177)
 ==24777==    by 0x805BDE2: create_domain (xl_cmdimpl.c:1812)
 ==24777==  Address 0x42dbdd8 is 8 bytes after a block of size 48 alloc'd
 ==24777==    at 0x4023340: calloc (vg_replace_malloc.c:593)
 ==24777==    by 0x406D479: libxl__zalloc (libxl_internal.c:88)
 ==24777==    by 0x404EF38: libxl_get_cpu_topology (libxl.c:3707)
 ==24777==    by 0x4072232: libxl__get_numa_candidate (libxl_numa.c:314)
 ==24777==    by 0x40680B6: libxl__build_pre (libxl_dom.c:166)
 ==24777==    by 0x405B82E: libxl__domain_build (libxl_create.c:323)
 ==24777==    by 0x405BB9C: domcreate_bootloader_done (libxl_create.c:747)
 ==24777==    by 0x407AD27: bootloader_local_detached_cb (libxl_bootloader.c:281)
 ==24777==    by 0x40508D8: local_device_detach_cb (libxl.c:2470)
 ==24777==    by 0x4052B10: libxl__device_disk_local_initiate_detach (libxl.c:2445)
 ==24777==    by 0x407AE9F: bootloader_callback (libxl_bootloader.c:265)
 ==24777==    by 0x407C69A: libxl__bootloader_run (libxl_bootloader.c:392)

This is because with nr_cpus=4 the bitmask returned from Xen
contains 0xff rather than 0x0f bit our bitmap walking routines (e.g.
libxl_for_each_set_bit) round up to the next byte (so it iterates
e.g. 8 times not 4). This then causes us to access of the end of
whatever array we are walking through each set bit for.

The principal of least surprise suggests that these bits ought not to
be set and this is not a hot path so fix this at the hypervisor layer
by clamping the bits in the returned bitmap to the correct limit.

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

The impact of this seems to be fairly benign in practice, so I'm not
sure about it for 4.2.0. Could leave to 4.2.1?

Dario,

Any chance you could look at the libxl bitmap functions in 4.3 and
make them use the right limit (i.e. nr_bits not (nr_bits+7)/8?

Thanks,
Ian.

diff -r 7db66f2a0242 -r 22d5e100131d xen/common/bitmap.c
--- a/xen/common/bitmap.c	Thu Sep 06 10:44:46 2012 +0100
+++ b/xen/common/bitmap.c	Thu Sep 06 12:56:41 2012 +0100
@@ -38,6 +38,17 @@
  * for the best explanations of this ordering.
  */
 
+/* Ensure that the last byte is zero from nbits onwards. */
+static void clamp_last_byte(uint8_t *bp, int nbits)
+{
+	int lastbyte = nbits/8;
+	int remainder = nbits % 8;
+	int mask = ((1U<<remainder)-1)&0xff;
+
+	if (remainder)
+		bp[lastbyte] &= mask;
+}
+
 int __bitmap_empty(const unsigned long *bitmap, int bits)
 {
 	int k, lim = bits/BITS_PER_LONG;
@@ -485,6 +496,7 @@ void bitmap_long_to_byte(uint8_t *bp, co
 			nbits -= 8;
 		}
 	}
+	clamp_last_byte(bp, nbits);
 }
 
 void bitmap_byte_to_long(unsigned long *lp, const uint8_t *bp, int nbits)
@@ -507,6 +519,7 @@ void bitmap_byte_to_long(unsigned long *
 void bitmap_long_to_byte(uint8_t *bp, const unsigned long *lp, int nbits)
 {
 	memcpy(bp, lp, (nbits+7)/8);
+	clamp_last_byte(bp, nbits);
 }
 
 void bitmap_byte_to_long(unsigned long *lp, const uint8_t *bp, int nbits)

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

From xen-devel-bounces@lists.xen.org Thu Sep 06 12:02:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 2012 12:02:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9ama-0005pJ-Iu; Thu, 06 Sep 2012 12:02: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 1T9amZ-0005pB-HS
	for xen-devel@lists.xen.org; Thu, 06 Sep 2012 12:02:03 +0000
Received: from [85.158.143.35:35206] by server-2.bemta-4.messagelabs.com id
	28/A4-21239-AB098405; Thu, 06 Sep 2012 12:02:02 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-14.tower-21.messagelabs.com!1346932920!17045523!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27454 invoked from network); 6 Sep 2012 12:02:00 -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; 6 Sep 2012 12:02:00 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1T9amV-000FEz-Ox; Thu, 06 Sep 2012 12:01:59 +0000
Date: Thu, 6 Sep 2012 13:01:59 +0100
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <ian.campbell@citrix.com>
Message-ID: <20120906120159.GG56463@ocelot.phlegethon.org>
References: <1346678886.32462.9.camel@zakaz.uk.xensource.com>
	<1346679056-8108-7-git-send-email-ian.campbell@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1346679056-8108-7-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 07/16] arm: avoid placing Xen over any
	modules.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At 13:30 +0000 on 03 Sep (1346679047), Ian Campbell wrote:
> @@ -85,17 +126,28 @@ static paddr_t __init get_xen_paddr(void)
>      /* Find the highest bank with enough space. */
>      for ( i = 0; i < mi->nr_banks; i++ )
>      {
> -        if ( mi->bank[i].size >= min_size )
> +        const struct membank *bank = &mi->bank[i];
> +        paddr_t s, e;
> +
> +        if ( bank->size >= min_size )
>          {
> -            t = mi->bank[i].start + mi->bank[i].size - min_size;
> -            if ( t > paddr )
> -                paddr = t;
> +            e = consider_modules(bank->start, bank->start + bank->size,
> +                                 min_size, XEN_PADDR_ALIGN, 0);
> +            if ( !e )continue;

Missing newline.  With that fixed,
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 Sep 06 12:02:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 2012 12:02:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9ama-0005pJ-Iu; Thu, 06 Sep 2012 12:02: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 1T9amZ-0005pB-HS
	for xen-devel@lists.xen.org; Thu, 06 Sep 2012 12:02:03 +0000
Received: from [85.158.143.35:35206] by server-2.bemta-4.messagelabs.com id
	28/A4-21239-AB098405; Thu, 06 Sep 2012 12:02:02 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-14.tower-21.messagelabs.com!1346932920!17045523!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27454 invoked from network); 6 Sep 2012 12:02:00 -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; 6 Sep 2012 12:02:00 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1T9amV-000FEz-Ox; Thu, 06 Sep 2012 12:01:59 +0000
Date: Thu, 6 Sep 2012 13:01:59 +0100
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <ian.campbell@citrix.com>
Message-ID: <20120906120159.GG56463@ocelot.phlegethon.org>
References: <1346678886.32462.9.camel@zakaz.uk.xensource.com>
	<1346679056-8108-7-git-send-email-ian.campbell@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1346679056-8108-7-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 07/16] arm: avoid placing Xen over any
	modules.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At 13:30 +0000 on 03 Sep (1346679047), Ian Campbell wrote:
> @@ -85,17 +126,28 @@ static paddr_t __init get_xen_paddr(void)
>      /* Find the highest bank with enough space. */
>      for ( i = 0; i < mi->nr_banks; i++ )
>      {
> -        if ( mi->bank[i].size >= min_size )
> +        const struct membank *bank = &mi->bank[i];
> +        paddr_t s, e;
> +
> +        if ( bank->size >= min_size )
>          {
> -            t = mi->bank[i].start + mi->bank[i].size - min_size;
> -            if ( t > paddr )
> -                paddr = t;
> +            e = consider_modules(bank->start, bank->start + bank->size,
> +                                 min_size, XEN_PADDR_ALIGN, 0);
> +            if ( !e )continue;

Missing newline.  With that fixed,
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 Sep 06 12:02:54 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 2012 12:02:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9anD-0005sV-0H; Thu, 06 Sep 2012 12:02: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 1T9anB-0005s8-8g
	for xen-devel@lists.xen.org; Thu, 06 Sep 2012 12:02:41 +0000
Received: from [85.158.139.83:37740] by server-7.bemta-5.messagelabs.com id
	3A/E8-19703-0E098405; Thu, 06 Sep 2012 12:02:40 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1346932958!25055901!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNzcyMDY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23956 invoked from network); 6 Sep 2012 12:02:39 -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;
	6 Sep 2012 12:02:39 -0000
X-IronPort-AV: E=Sophos;i="4.80,380,1344211200"; d="scan'208";a="207268468"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Sep 2012 12:02:27 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1;
	Thu, 6 Sep 2012 08:02:27 -0400
Received: from cosworth.uk.xensource.com ([10.80.16.52] ident=ianc)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1T9amw-0007Zf-Pg;
	Thu, 06 Sep 2012 13:02:26 +0100
MIME-Version: 1.0
X-Mercurial-Node: 844e10487b91fb4dcb9c6f8be42a9940d95a7119
Message-ID: <844e10487b91fb4dcb9c.1346932946@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Thu, 6 Sep 2012 13:02:26 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Cc: Ian.Jackson@citrix.com
Subject: [Xen-devel] [PATCH] xl: free libxl context,
 logger and lockfile using atexit handler
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1346932936 -3600
# Node ID 844e10487b91fb4dcb9c6f8be42a9940d95a7119
# Parent  1b6912dc15f39d1455929f605bbbda1a51c06fe5
xl: free libxl context, logger and lockfile using atexit handler

xl frequently just calls exit(3), especially on error. Try to clean
up some of our global state to make tools like valgrind more useful.

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

For 4.3 only.

diff -r 1b6912dc15f3 -r 844e10487b91 tools/libxl/xl.c
--- a/tools/libxl/xl.c	Thu Sep 06 10:44:40 2012 +0100
+++ b/tools/libxl/xl.c	Thu Sep 06 13:02:16 2012 +0100
@@ -191,6 +191,22 @@ void xl_ctx_alloc(void) {
     libxl_childproc_setmode(ctx, &childproc_hooks, 0);
 }
 
+static void xl_ctx_free(void)
+{
+    if (ctx) {
+        libxl_ctx_free(ctx);
+        ctx = NULL;
+    }
+    if (logger) {
+        xtl_logger_destroy((xentoollog_logger*)logger);
+        logger = NULL;
+    }
+    if (lockfile) {
+        free(lockfile);
+        lockfile = NULL;
+    }
+}
+
 int main(int argc, char **argv)
 {
     int opt = 0;
@@ -229,6 +245,8 @@ int main(int argc, char **argv)
     logger = xtl_createlogger_stdiostream(stderr, minmsglevel,  0);
     if (!logger) exit(1);
 
+    atexit(xl_ctx_free);
+
     xl_ctx_alloc();
 
     ret = libxl_read_file_contents(ctx, XL_GLOBAL_CONFIG,
@@ -274,8 +292,6 @@ int main(int argc, char **argv)
     }
 
  xit:
-    libxl_ctx_free(ctx);
-    xtl_logger_destroy((xentoollog_logger*)logger);
     return ret;
 }
 

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

From xen-devel-bounces@lists.xen.org Thu Sep 06 12:02:54 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 2012 12:02:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9anD-0005sV-0H; Thu, 06 Sep 2012 12:02: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 1T9anB-0005s8-8g
	for xen-devel@lists.xen.org; Thu, 06 Sep 2012 12:02:41 +0000
Received: from [85.158.139.83:37740] by server-7.bemta-5.messagelabs.com id
	3A/E8-19703-0E098405; Thu, 06 Sep 2012 12:02:40 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1346932958!25055901!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNzcyMDY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23956 invoked from network); 6 Sep 2012 12:02:39 -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;
	6 Sep 2012 12:02:39 -0000
X-IronPort-AV: E=Sophos;i="4.80,380,1344211200"; d="scan'208";a="207268468"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Sep 2012 12:02:27 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1;
	Thu, 6 Sep 2012 08:02:27 -0400
Received: from cosworth.uk.xensource.com ([10.80.16.52] ident=ianc)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1T9amw-0007Zf-Pg;
	Thu, 06 Sep 2012 13:02:26 +0100
MIME-Version: 1.0
X-Mercurial-Node: 844e10487b91fb4dcb9c6f8be42a9940d95a7119
Message-ID: <844e10487b91fb4dcb9c.1346932946@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Thu, 6 Sep 2012 13:02:26 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Cc: Ian.Jackson@citrix.com
Subject: [Xen-devel] [PATCH] xl: free libxl context,
 logger and lockfile using atexit handler
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1346932936 -3600
# Node ID 844e10487b91fb4dcb9c6f8be42a9940d95a7119
# Parent  1b6912dc15f39d1455929f605bbbda1a51c06fe5
xl: free libxl context, logger and lockfile using atexit handler

xl frequently just calls exit(3), especially on error. Try to clean
up some of our global state to make tools like valgrind more useful.

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

For 4.3 only.

diff -r 1b6912dc15f3 -r 844e10487b91 tools/libxl/xl.c
--- a/tools/libxl/xl.c	Thu Sep 06 10:44:40 2012 +0100
+++ b/tools/libxl/xl.c	Thu Sep 06 13:02:16 2012 +0100
@@ -191,6 +191,22 @@ void xl_ctx_alloc(void) {
     libxl_childproc_setmode(ctx, &childproc_hooks, 0);
 }
 
+static void xl_ctx_free(void)
+{
+    if (ctx) {
+        libxl_ctx_free(ctx);
+        ctx = NULL;
+    }
+    if (logger) {
+        xtl_logger_destroy((xentoollog_logger*)logger);
+        logger = NULL;
+    }
+    if (lockfile) {
+        free(lockfile);
+        lockfile = NULL;
+    }
+}
+
 int main(int argc, char **argv)
 {
     int opt = 0;
@@ -229,6 +245,8 @@ int main(int argc, char **argv)
     logger = xtl_createlogger_stdiostream(stderr, minmsglevel,  0);
     if (!logger) exit(1);
 
+    atexit(xl_ctx_free);
+
     xl_ctx_alloc();
 
     ret = libxl_read_file_contents(ctx, XL_GLOBAL_CONFIG,
@@ -274,8 +292,6 @@ int main(int argc, char **argv)
     }
 
  xit:
-    libxl_ctx_free(ctx);
-    xtl_logger_destroy((xentoollog_logger*)logger);
     return ret;
 }
 

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

From xen-devel-bounces@lists.xen.org Thu Sep 06 12:04:39 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 2012 12:04:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9aou-000646-HN; Thu, 06 Sep 2012 12:04:28 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1T9aos-00063i-SU
	for xen-devel@lists.xen.org; Thu, 06 Sep 2012 12:04:27 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-7.tower-27.messagelabs.com!1346933060!2186000!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14705 invoked from network); 6 Sep 2012 12:04:21 -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; 6 Sep 2012 12:04:21 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1T9aom-000FFQ-5B; Thu, 06 Sep 2012 12:04:20 +0000
Date: Thu, 6 Sep 2012 13:04:20 +0100
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <ian.campbell@citrix.com>
Message-ID: <20120906120420.GH56463@ocelot.phlegethon.org>
References: <1346678886.32462.9.camel@zakaz.uk.xensource.com>
	<1346679056-8108-8-git-send-email-ian.campbell@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1346679056-8108-8-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 08/16] arm: really allocate boot frametable
	pages with 32M alignment
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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:30 +0000 on 03 Sep (1346679048), Ian Campbell wrote:
> This argument to alloc_boot_pages is "pfn_align" and not an order.
> We've been lucky until now that the area given to the boot allocator
> happened to be properly aligned and this allocation was early enough
> to benefit.
> 
> 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 Sep 06 12:04:39 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 2012 12:04:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9aou-000646-HN; Thu, 06 Sep 2012 12:04:28 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1T9aos-00063i-SU
	for xen-devel@lists.xen.org; Thu, 06 Sep 2012 12:04:27 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-7.tower-27.messagelabs.com!1346933060!2186000!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14705 invoked from network); 6 Sep 2012 12:04:21 -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; 6 Sep 2012 12:04:21 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1T9aom-000FFQ-5B; Thu, 06 Sep 2012 12:04:20 +0000
Date: Thu, 6 Sep 2012 13:04:20 +0100
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <ian.campbell@citrix.com>
Message-ID: <20120906120420.GH56463@ocelot.phlegethon.org>
References: <1346678886.32462.9.camel@zakaz.uk.xensource.com>
	<1346679056-8108-8-git-send-email-ian.campbell@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1346679056-8108-8-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 08/16] arm: really allocate boot frametable
	pages with 32M alignment
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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:30 +0000 on 03 Sep (1346679048), Ian Campbell wrote:
> This argument to alloc_boot_pages is "pfn_align" and not an order.
> We've been lucky until now that the area given to the boot allocator
> happened to be properly aligned and this allocation was early enough
> to benefit.
> 
> 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 Sep 06 12:05:51 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 2012 12: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 1T9aq6-0006E5-0E; Thu, 06 Sep 2012 12:05:42 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1T9aq4-0006C5-Ih
	for xen-devel@lists.xensource.com; Thu, 06 Sep 2012 12:05:40 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1346933129!4267696!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNjkzMDI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15336 invoked from network); 6 Sep 2012 12:05:30 -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;
	6 Sep 2012 12:05:30 -0000
X-IronPort-AV: E=Sophos;i="4.80,380,1344211200"; d="scan'208";a="36971826"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Sep 2012 12:05:28 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1;
	Thu, 6 Sep 2012 08:05:28 -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 1T9apr-0007cO-Gq;
	Thu, 06 Sep 2012 13:05:27 +0100
From: David Vrabel <david.vrabel@citrix.com>
To: xen-devel@lists.xensource.com
Date: Thu, 6 Sep 2012 13:05:18 +0100
Message-ID: <1346933118-28928-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>
Subject: [Xen-devel] [PATCH] timer: remove stray local_irq_enable()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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>

migrate_timers_from_cpu() has a stray local_irq_enable() that does
nothing (it's immediately after a spin_unlock_irq()) and has no
matching local_irq_disable().

Signed-off-by: David Vrabel <david.vrabel@citrix.com>
---
 xen/common/timer.c |    1 -
 1 files changed, 0 insertions(+), 1 deletions(-)

diff --git a/xen/common/timer.c b/xen/common/timer.c
index 0dd2476..39de52d 100644
--- a/xen/common/timer.c
+++ b/xen/common/timer.c
@@ -587,7 +587,6 @@ static void migrate_timers_from_cpu(unsigned int old_cpu)
 
     spin_unlock(&old_ts->lock);
     spin_unlock_irq(&new_ts->lock);
-    local_irq_enable();
 
     if ( notify )
         cpu_raise_softirq(new_cpu, TIMER_SOFTIRQ);
-- 
1.7.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 Sep 06 12:05:51 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 2012 12: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 1T9aq6-0006E5-0E; Thu, 06 Sep 2012 12:05:42 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1T9aq4-0006C5-Ih
	for xen-devel@lists.xensource.com; Thu, 06 Sep 2012 12:05:40 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1346933129!4267696!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNjkzMDI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15336 invoked from network); 6 Sep 2012 12:05:30 -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;
	6 Sep 2012 12:05:30 -0000
X-IronPort-AV: E=Sophos;i="4.80,380,1344211200"; d="scan'208";a="36971826"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Sep 2012 12:05:28 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1;
	Thu, 6 Sep 2012 08:05:28 -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 1T9apr-0007cO-Gq;
	Thu, 06 Sep 2012 13:05:27 +0100
From: David Vrabel <david.vrabel@citrix.com>
To: xen-devel@lists.xensource.com
Date: Thu, 6 Sep 2012 13:05:18 +0100
Message-ID: <1346933118-28928-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>
Subject: [Xen-devel] [PATCH] timer: remove stray local_irq_enable()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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>

migrate_timers_from_cpu() has a stray local_irq_enable() that does
nothing (it's immediately after a spin_unlock_irq()) and has no
matching local_irq_disable().

Signed-off-by: David Vrabel <david.vrabel@citrix.com>
---
 xen/common/timer.c |    1 -
 1 files changed, 0 insertions(+), 1 deletions(-)

diff --git a/xen/common/timer.c b/xen/common/timer.c
index 0dd2476..39de52d 100644
--- a/xen/common/timer.c
+++ b/xen/common/timer.c
@@ -587,7 +587,6 @@ static void migrate_timers_from_cpu(unsigned int old_cpu)
 
     spin_unlock(&old_ts->lock);
     spin_unlock_irq(&new_ts->lock);
-    local_irq_enable();
 
     if ( notify )
         cpu_raise_softirq(new_cpu, TIMER_SOFTIRQ);
-- 
1.7.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 Sep 06 12:09:02 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 2012 12:09:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9atB-0006WD-KG; Thu, 06 Sep 2012 12:08: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 1T9at9-0006W2-PE
	for xen-devel@lists.xen.org; Thu, 06 Sep 2012 12:08:51 +0000
Received: from [85.158.138.51:5494] by server-9.bemta-3.messagelabs.com id
	DF/E1-15390-25298405; Thu, 06 Sep 2012 12:08:50 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-8.tower-174.messagelabs.com!1346933330!28990559!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14383 invoked from network); 6 Sep 2012 12:08:50 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-8.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 6 Sep 2012 12:08:50 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1T9at7-000FGb-SK; Thu, 06 Sep 2012 12:08:49 +0000
Date: Thu, 6 Sep 2012 13:08:49 +0100
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <ian.campbell@citrix.com>
Message-ID: <20120906120849.GI56463@ocelot.phlegethon.org>
References: <1346678886.32462.9.camel@zakaz.uk.xensource.com>
	<1346679056-8108-9-git-send-email-ian.campbell@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1346679056-8108-9-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 09/16] arm: avoid allocating the heaps over
	modules or xen itself.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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:30 +0000 on 03 Sep (1346679049), Ian Campbell wrote:
> @@ -72,7 +74,8 @@ static void __init processor_id(void)
>   * with required size and alignment that does not conflict with the
>   * modules from first_mod to nr_modules.
>   *
> - * For non-recursive callers first_mod should normally be 0.
> + * For non-recursive callers first_mod should normally be 0 (all
> + * modules) or -1 (all modules and Xen itself).

Oh dear.  I think that having Xen be module 0 would make this and the
module-parsing code much cleaner. 

Tim.

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

From xen-devel-bounces@lists.xen.org Thu Sep 06 12:09:02 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 2012 12:09:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9atB-0006WD-KG; Thu, 06 Sep 2012 12:08: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 1T9at9-0006W2-PE
	for xen-devel@lists.xen.org; Thu, 06 Sep 2012 12:08:51 +0000
Received: from [85.158.138.51:5494] by server-9.bemta-3.messagelabs.com id
	DF/E1-15390-25298405; Thu, 06 Sep 2012 12:08:50 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-8.tower-174.messagelabs.com!1346933330!28990559!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14383 invoked from network); 6 Sep 2012 12:08:50 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-8.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 6 Sep 2012 12:08:50 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1T9at7-000FGb-SK; Thu, 06 Sep 2012 12:08:49 +0000
Date: Thu, 6 Sep 2012 13:08:49 +0100
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <ian.campbell@citrix.com>
Message-ID: <20120906120849.GI56463@ocelot.phlegethon.org>
References: <1346678886.32462.9.camel@zakaz.uk.xensource.com>
	<1346679056-8108-9-git-send-email-ian.campbell@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1346679056-8108-9-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 09/16] arm: avoid allocating the heaps over
	modules or xen itself.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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:30 +0000 on 03 Sep (1346679049), Ian Campbell wrote:
> @@ -72,7 +74,8 @@ static void __init processor_id(void)
>   * with required size and alignment that does not conflict with the
>   * modules from first_mod to nr_modules.
>   *
> - * For non-recursive callers first_mod should normally be 0.
> + * For non-recursive callers first_mod should normally be 0 (all
> + * modules) or -1 (all modules and Xen itself).

Oh dear.  I think that having Xen be module 0 would make this and the
module-parsing code much cleaner. 

Tim.

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

From xen-devel-bounces@lists.xen.org Thu Sep 06 12:09:22 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 2012 12:09:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9atW-0006Yu-R5; Thu, 06 Sep 2012 12:09:14 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <kks.kbase@gmail.com>)
	id 1T9Zfw-0007Oh-JV; Thu, 06 Sep 2012 10:51:08 +0000
X-Env-Sender: kks.kbase@gmail.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1346928655!2849028!1
X-Originating-IP: [209.85.214.45]
X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31892 invoked from network); 6 Sep 2012 10:50:55 -0000
Received: from mail-bk0-f45.google.com (HELO mail-bk0-f45.google.com)
	(209.85.214.45)
	by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Sep 2012 10:50:55 -0000
Received: by bkcji1 with SMTP id ji1so715084bkc.32
	for <multiple recipients>; Thu, 06 Sep 2012 03:50:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=V7/Vv9Jz8UEIn0Z+MytWrJHC7wUcL5sz5JRRZW0A82M=;
	b=0vCa3+dcFfyoqlIQpUTSM0TlVZVfZGIHyKajGdLGjrBe84e3WA1uOUw4c4i7d0kDkj
	/42fmUTTl/GrsF5tWt/FTrJzX2uz1ieQkzIkSD/eo+RH0AIqyfHa2+BVGIuzp+ABpCpx
	lbCEf8PYeCYOPceySCuS9qocp1X4KNT285wbVvtSjGYV3kmQVjL1PLTvfmob21ebbRfQ
	Zz2UZyngW6s/ZSuHHi3/7Ch5X4oQUAMCBxHKFsSHxiuy5TciKzJq9SBg0+NCbsljSd35
	Sp+eC+Jt6caynZd094zOlvPPQG2vC8iC462EdgbYH4LzeKaDWb+pfz1FEN0Q3sCdjvV3
	A3fA==
MIME-Version: 1.0
Received: by 10.204.130.156 with SMTP id t28mr667416bks.33.1346928654792; Thu,
	06 Sep 2012 03:50:54 -0700 (PDT)
Received: by 10.204.56.134 with HTTP; Thu, 6 Sep 2012 03:50:54 -0700 (PDT)
In-Reply-To: <1346922837.23055.33.camel@zakaz.uk.xensource.com>
References: <CAPU-Ed65dguruSSNrGxk4PmejTJQT7zELXpNAxJULCmdwEvpnA@mail.gmail.com>
	<1346921802.23055.26.camel@zakaz.uk.xensource.com>
	<CAPU-Ed4=r6KT0r4fM--94oPPo0mn4LcmwRJh41wHiAFvf6irLg@mail.gmail.com>
	<1346922837.23055.33.camel@zakaz.uk.xensource.com>
Date: Thu, 6 Sep 2012 16:20:54 +0530
Message-ID: <CAPU-Ed5S9yWdB9HRLEtA8Q-QJFdnO2EvaPJkqg7SS7JkSu33hw@mail.gmail.com>
From: kk s <kks.kbase@gmail.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
X-Mailman-Approved-At: Thu, 06 Sep 2012 12:09:12 +0000
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] Security patches
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1972687549918794135=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============1972687549918794135==
Content-Type: multipart/alternative; boundary=00151743f82e01b70504c9064409

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

Hi,

It looks like the patch that has been provided on Xen Security Advisory 11
(CVE-2012-3433) doesn't applied for Xen 3.4.4.

When I try to apply this patch and I am getting the below error,

1 out of 1 hunk FAILED -- saving rejects to file xen/arch/x86/mm/p2m.c.rej
1 out of 1 hunk FAILED -- saving rejects to file xen/arch/x86/mm/p2m.c.rej

Seems there is no for loop "for ( gfn=0; gfn < p2m->max_mapped_pfn; gfn++
)" on xen/arch/x86/mm/p2m.c.rej on xen3.4.4 source instead if loop only
exists.

p2m.c: && (gfn + (1UL << page_order) - 1 > d->arch.p2m->max_mapped_pfn) )
p2m.c: d->arch.p2m->max_mapped_pfn = gfn + (1UL << page_order) - 1;
p2m.c: if ( gfn > d->arch.p2m->max_mapped_pfn )
p2m.c: if ( gfn <= current->domain->arch.p2m->max_mapped_pfn )
p2m.c: if ( test_linear && (gfn <= d->arch.p2m->max_mapped_pfn) )
p2m.c.orig: && (gfn + (1UL << page_order) - 1 >
d->arch.p2m->max_mapped_pfn) )
p2m.c.orig: d->arch.p2m->max_mapped_pfn = gfn + (1UL << page_order) - 1;
p2m.c.orig: if ( gfn > d->arch.p2m->max_mapped_pfn )
p2m.c.orig: if ( gfn <= current->domain->arch.p2m->max_mapped_pfn )
p2m.c.orig: if ( test_linear && (gfn <= d->arch.p2m->max_mapped_pfn) )
p2m.c.rej: for ( gfn=0; gfn < p2m->max_mapped_pfn; gfn++ )
p2m.c.rej: for ( gfn=0; gfn < p2m->max_mapped_pfn; gfn++ )

So I guess this patch applicable for Xen 4.x only. If you update the patch
for Xen 3.4 that would be great.


On Thu, Sep 6, 2012 at 2:43 PM, Ian Campbell <Ian.Campbell@citrix.com>wrote:

> On Thu, 2012-09-06 at 10:08 +0100, kk s wrote:
> > Hi Ian,
> >
> > Thanks for your reply. Sorry to bother you with this. I am bit
> > confused and so I am asking to make clear myself.
> >
> > Reg CVE-2012-2934 -
> > http://lists.xen.org/archives/html/xen-announce/2012-06/msg00002.html
> > Is Xen 3.4 too affected with this vulnerable? If so I couldn't find
> > the patch for xen 3.4 and it does exit for xen 4.x only.
>
> I expect it does effect 3.4, but only if you are running on one of the
> listed processors.
>
> security@xen.org doesn't provide security support for 3.4 any more. If
> you aren't able to backport the 4.0 patch yourself, you would need to
> speak to Keith Coleman who is the 3.4 stable maintainer.
>
> > I don't how to apply the following patches since I have created rpm
> > with patches applied that included as downloadable file. But for these
> > patches I am not seeing any downloadable file.
> >
> > http://lists.xen.org/archives/html/xen-devel/2012-02/msg00212.html
> > http://lists.xen.org/archives/html/xen-devel/2012-07/msg01649.html
> > http://lists.xen.org/archives/html/xen-devel/2012-08/msg00855.html
> >
> > If you can clear this for me that would be great :)
>
> I already pointed you at http://wiki.xen.org/wiki/Security_Announcements
> which should have all the links you need.
>
>
>

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

<div>Hi,<br></div><div><br></div><div>It looks like the patch that has been=
 provided on Xen Security Advisory 11 (CVE-2012-3433) doesn&#39;t applied f=
or Xen 3.4.4.</div><div><br></div><div>When I try to apply this patch and I=
 am getting the below error,</div>
<div><br></div><div>1 out of 1 hunk FAILED -- saving rejects to file xen/ar=
ch/x86/mm/p2m.c.rej<br>1 out of 1 hunk FAILED -- saving rejects to file xen=
/arch/x86/mm/p2m.c.rej</div><div><br></div><div>Seems there is no for loop =
&quot;for ( gfn=3D0; gfn &lt; p2m-&gt;max_mapped_pfn; gfn++ )&quot; on xen/=
arch/x86/mm/p2m.c.rej on xen3.4.4 source instead if loop only exists.</div>
<div><br></div><div>p2m.c:         &amp;&amp; (gfn + (1UL &lt;&lt; page_ord=
er) - 1 &gt; d-&gt;arch.p2m-&gt;max_mapped_pfn) )<br>p2m.c:        d-&gt;ar=
ch.p2m-&gt;max_mapped_pfn =3D gfn + (1UL &lt;&lt; page_order) - 1;<br>p2m.c=
:    if ( gfn &gt; d-&gt;arch.p2m-&gt;max_mapped_pfn )<br>
p2m.c:    if ( gfn &lt;=3D current-&gt;domain-&gt;arch.p2m-&gt;max_mapped_p=
fn )<br>p2m.c:        if ( test_linear &amp;&amp; (gfn &lt;=3D d-&gt;arch.p=
2m-&gt;max_mapped_pfn) )<br>p2m.c.orig:         &amp;&amp; (gfn + (1UL &lt;=
&lt; page_order) - 1 &gt; d-&gt;arch.p2m-&gt;max_mapped_pfn) )<br>
p2m.c.orig:        d-&gt;arch.p2m-&gt;max_mapped_pfn =3D gfn + (1UL &lt;&lt=
; page_order) - 1;<br>p2m.c.orig:    if ( gfn &gt; d-&gt;arch.p2m-&gt;max_m=
apped_pfn )<br>p2m.c.orig:    if ( gfn &lt;=3D current-&gt;domain-&gt;arch.=
p2m-&gt;max_mapped_pfn )<br>
p2m.c.orig:        if ( test_linear &amp;&amp; (gfn &lt;=3D d-&gt;arch.p2m-=
&gt;max_mapped_pfn) )<br>p2m.c.rej:      for ( gfn=3D0; gfn &lt; p2m-&gt;ma=
x_mapped_pfn; gfn++ )<br>p2m.c.rej:      for ( gfn=3D0; gfn &lt; p2m-&gt;ma=
x_mapped_pfn; gfn++ )</div>
<div><br></div><div>So I guess this patch applicable for Xen 4.x only. If y=
ou update the patch for Xen 3.4 that would be great.</div><div><br></div><b=
r><div class=3D"gmail_quote">On Thu, Sep 6, 2012 at 2:43 PM, Ian Campbell <=
span dir=3D"ltr">&lt;<a href=3D"mailto:Ian.Campbell@citrix.com" target=3D"_=
blank">Ian.Campbell@citrix.com</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div class=3D"im">On Thu, 2012-09-06 at 10:0=
8 +0100, kk s wrote:<br>
&gt; Hi Ian,<br>
&gt;<br>
&gt; Thanks for your reply. Sorry to bother you with this. I am bit<br>
&gt; confused and so I am asking to make clear myself.<br>
&gt;<br>
&gt; Reg CVE-2012-2934 -<br>
&gt; <a href=3D"http://lists.xen.org/archives/html/xen-announce/2012-06/msg=
00002.html" target=3D"_blank">http://lists.xen.org/archives/html/xen-announ=
ce/2012-06/msg00002.html</a><br>
&gt; Is Xen 3.4 too affected with this vulnerable? If so I couldn&#39;t fin=
d<br>
&gt; the patch for xen 3.4 and it does exit for xen 4.x only.<br>
<br>
</div>I expect it does effect 3.4, but only if you are running on one of th=
e<br>
listed processors.<br>
<br>
<a href=3D"mailto:security@xen.org">security@xen.org</a> doesn&#39;t provid=
e security support for 3.4 any more. If<br>
you aren&#39;t able to backport the 4.0 patch yourself, you would need to<b=
r>
speak to Keith Coleman who is the 3.4 stable maintainer.<br>
<div class=3D"im"><br>
&gt; I don&#39;t how to apply the following patches since I have created rp=
m<br>
&gt; with patches applied that included as downloadable file. But for these=
<br>
&gt; patches I am not seeing any downloadable file.<br>
&gt;<br>
&gt; <a href=3D"http://lists.xen.org/archives/html/xen-devel/2012-02/msg002=
12.html" target=3D"_blank">http://lists.xen.org/archives/html/xen-devel/201=
2-02/msg00212.html</a><br>
&gt; <a href=3D"http://lists.xen.org/archives/html/xen-devel/2012-07/msg016=
49.html" target=3D"_blank">http://lists.xen.org/archives/html/xen-devel/201=
2-07/msg01649.html</a><br>
&gt; <a href=3D"http://lists.xen.org/archives/html/xen-devel/2012-08/msg008=
55.html" target=3D"_blank">http://lists.xen.org/archives/html/xen-devel/201=
2-08/msg00855.html</a><br>
&gt;<br>
&gt; If you can clear this for me that would be great :)<br>
<br>
</div>I already pointed you at <a href=3D"http://wiki.xen.org/wiki/Security=
_Announcements" target=3D"_blank">http://wiki.xen.org/wiki/Security_Announc=
ements</a><br>
which should have all the links you need.<br>
<br>
<br>
</blockquote></div><br>

--00151743f82e01b70504c9064409--


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

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

--===============1972687549918794135==--


From xen-devel-bounces@lists.xen.org Thu Sep 06 12:09:22 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 2012 12:09:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9atW-0006Yu-R5; Thu, 06 Sep 2012 12:09:14 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <kks.kbase@gmail.com>)
	id 1T9Zfw-0007Oh-JV; Thu, 06 Sep 2012 10:51:08 +0000
X-Env-Sender: kks.kbase@gmail.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1346928655!2849028!1
X-Originating-IP: [209.85.214.45]
X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31892 invoked from network); 6 Sep 2012 10:50:55 -0000
Received: from mail-bk0-f45.google.com (HELO mail-bk0-f45.google.com)
	(209.85.214.45)
	by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Sep 2012 10:50:55 -0000
Received: by bkcji1 with SMTP id ji1so715084bkc.32
	for <multiple recipients>; Thu, 06 Sep 2012 03:50:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=V7/Vv9Jz8UEIn0Z+MytWrJHC7wUcL5sz5JRRZW0A82M=;
	b=0vCa3+dcFfyoqlIQpUTSM0TlVZVfZGIHyKajGdLGjrBe84e3WA1uOUw4c4i7d0kDkj
	/42fmUTTl/GrsF5tWt/FTrJzX2uz1ieQkzIkSD/eo+RH0AIqyfHa2+BVGIuzp+ABpCpx
	lbCEf8PYeCYOPceySCuS9qocp1X4KNT285wbVvtSjGYV3kmQVjL1PLTvfmob21ebbRfQ
	Zz2UZyngW6s/ZSuHHi3/7Ch5X4oQUAMCBxHKFsSHxiuy5TciKzJq9SBg0+NCbsljSd35
	Sp+eC+Jt6caynZd094zOlvPPQG2vC8iC462EdgbYH4LzeKaDWb+pfz1FEN0Q3sCdjvV3
	A3fA==
MIME-Version: 1.0
Received: by 10.204.130.156 with SMTP id t28mr667416bks.33.1346928654792; Thu,
	06 Sep 2012 03:50:54 -0700 (PDT)
Received: by 10.204.56.134 with HTTP; Thu, 6 Sep 2012 03:50:54 -0700 (PDT)
In-Reply-To: <1346922837.23055.33.camel@zakaz.uk.xensource.com>
References: <CAPU-Ed65dguruSSNrGxk4PmejTJQT7zELXpNAxJULCmdwEvpnA@mail.gmail.com>
	<1346921802.23055.26.camel@zakaz.uk.xensource.com>
	<CAPU-Ed4=r6KT0r4fM--94oPPo0mn4LcmwRJh41wHiAFvf6irLg@mail.gmail.com>
	<1346922837.23055.33.camel@zakaz.uk.xensource.com>
Date: Thu, 6 Sep 2012 16:20:54 +0530
Message-ID: <CAPU-Ed5S9yWdB9HRLEtA8Q-QJFdnO2EvaPJkqg7SS7JkSu33hw@mail.gmail.com>
From: kk s <kks.kbase@gmail.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
X-Mailman-Approved-At: Thu, 06 Sep 2012 12:09:12 +0000
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] Security patches
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1972687549918794135=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============1972687549918794135==
Content-Type: multipart/alternative; boundary=00151743f82e01b70504c9064409

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

Hi,

It looks like the patch that has been provided on Xen Security Advisory 11
(CVE-2012-3433) doesn't applied for Xen 3.4.4.

When I try to apply this patch and I am getting the below error,

1 out of 1 hunk FAILED -- saving rejects to file xen/arch/x86/mm/p2m.c.rej
1 out of 1 hunk FAILED -- saving rejects to file xen/arch/x86/mm/p2m.c.rej

Seems there is no for loop "for ( gfn=0; gfn < p2m->max_mapped_pfn; gfn++
)" on xen/arch/x86/mm/p2m.c.rej on xen3.4.4 source instead if loop only
exists.

p2m.c: && (gfn + (1UL << page_order) - 1 > d->arch.p2m->max_mapped_pfn) )
p2m.c: d->arch.p2m->max_mapped_pfn = gfn + (1UL << page_order) - 1;
p2m.c: if ( gfn > d->arch.p2m->max_mapped_pfn )
p2m.c: if ( gfn <= current->domain->arch.p2m->max_mapped_pfn )
p2m.c: if ( test_linear && (gfn <= d->arch.p2m->max_mapped_pfn) )
p2m.c.orig: && (gfn + (1UL << page_order) - 1 >
d->arch.p2m->max_mapped_pfn) )
p2m.c.orig: d->arch.p2m->max_mapped_pfn = gfn + (1UL << page_order) - 1;
p2m.c.orig: if ( gfn > d->arch.p2m->max_mapped_pfn )
p2m.c.orig: if ( gfn <= current->domain->arch.p2m->max_mapped_pfn )
p2m.c.orig: if ( test_linear && (gfn <= d->arch.p2m->max_mapped_pfn) )
p2m.c.rej: for ( gfn=0; gfn < p2m->max_mapped_pfn; gfn++ )
p2m.c.rej: for ( gfn=0; gfn < p2m->max_mapped_pfn; gfn++ )

So I guess this patch applicable for Xen 4.x only. If you update the patch
for Xen 3.4 that would be great.


On Thu, Sep 6, 2012 at 2:43 PM, Ian Campbell <Ian.Campbell@citrix.com>wrote:

> On Thu, 2012-09-06 at 10:08 +0100, kk s wrote:
> > Hi Ian,
> >
> > Thanks for your reply. Sorry to bother you with this. I am bit
> > confused and so I am asking to make clear myself.
> >
> > Reg CVE-2012-2934 -
> > http://lists.xen.org/archives/html/xen-announce/2012-06/msg00002.html
> > Is Xen 3.4 too affected with this vulnerable? If so I couldn't find
> > the patch for xen 3.4 and it does exit for xen 4.x only.
>
> I expect it does effect 3.4, but only if you are running on one of the
> listed processors.
>
> security@xen.org doesn't provide security support for 3.4 any more. If
> you aren't able to backport the 4.0 patch yourself, you would need to
> speak to Keith Coleman who is the 3.4 stable maintainer.
>
> > I don't how to apply the following patches since I have created rpm
> > with patches applied that included as downloadable file. But for these
> > patches I am not seeing any downloadable file.
> >
> > http://lists.xen.org/archives/html/xen-devel/2012-02/msg00212.html
> > http://lists.xen.org/archives/html/xen-devel/2012-07/msg01649.html
> > http://lists.xen.org/archives/html/xen-devel/2012-08/msg00855.html
> >
> > If you can clear this for me that would be great :)
>
> I already pointed you at http://wiki.xen.org/wiki/Security_Announcements
> which should have all the links you need.
>
>
>

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

<div>Hi,<br></div><div><br></div><div>It looks like the patch that has been=
 provided on Xen Security Advisory 11 (CVE-2012-3433) doesn&#39;t applied f=
or Xen 3.4.4.</div><div><br></div><div>When I try to apply this patch and I=
 am getting the below error,</div>
<div><br></div><div>1 out of 1 hunk FAILED -- saving rejects to file xen/ar=
ch/x86/mm/p2m.c.rej<br>1 out of 1 hunk FAILED -- saving rejects to file xen=
/arch/x86/mm/p2m.c.rej</div><div><br></div><div>Seems there is no for loop =
&quot;for ( gfn=3D0; gfn &lt; p2m-&gt;max_mapped_pfn; gfn++ )&quot; on xen/=
arch/x86/mm/p2m.c.rej on xen3.4.4 source instead if loop only exists.</div>
<div><br></div><div>p2m.c:         &amp;&amp; (gfn + (1UL &lt;&lt; page_ord=
er) - 1 &gt; d-&gt;arch.p2m-&gt;max_mapped_pfn) )<br>p2m.c:        d-&gt;ar=
ch.p2m-&gt;max_mapped_pfn =3D gfn + (1UL &lt;&lt; page_order) - 1;<br>p2m.c=
:    if ( gfn &gt; d-&gt;arch.p2m-&gt;max_mapped_pfn )<br>
p2m.c:    if ( gfn &lt;=3D current-&gt;domain-&gt;arch.p2m-&gt;max_mapped_p=
fn )<br>p2m.c:        if ( test_linear &amp;&amp; (gfn &lt;=3D d-&gt;arch.p=
2m-&gt;max_mapped_pfn) )<br>p2m.c.orig:         &amp;&amp; (gfn + (1UL &lt;=
&lt; page_order) - 1 &gt; d-&gt;arch.p2m-&gt;max_mapped_pfn) )<br>
p2m.c.orig:        d-&gt;arch.p2m-&gt;max_mapped_pfn =3D gfn + (1UL &lt;&lt=
; page_order) - 1;<br>p2m.c.orig:    if ( gfn &gt; d-&gt;arch.p2m-&gt;max_m=
apped_pfn )<br>p2m.c.orig:    if ( gfn &lt;=3D current-&gt;domain-&gt;arch.=
p2m-&gt;max_mapped_pfn )<br>
p2m.c.orig:        if ( test_linear &amp;&amp; (gfn &lt;=3D d-&gt;arch.p2m-=
&gt;max_mapped_pfn) )<br>p2m.c.rej:      for ( gfn=3D0; gfn &lt; p2m-&gt;ma=
x_mapped_pfn; gfn++ )<br>p2m.c.rej:      for ( gfn=3D0; gfn &lt; p2m-&gt;ma=
x_mapped_pfn; gfn++ )</div>
<div><br></div><div>So I guess this patch applicable for Xen 4.x only. If y=
ou update the patch for Xen 3.4 that would be great.</div><div><br></div><b=
r><div class=3D"gmail_quote">On Thu, Sep 6, 2012 at 2:43 PM, Ian Campbell <=
span dir=3D"ltr">&lt;<a href=3D"mailto:Ian.Campbell@citrix.com" target=3D"_=
blank">Ian.Campbell@citrix.com</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div class=3D"im">On Thu, 2012-09-06 at 10:0=
8 +0100, kk s wrote:<br>
&gt; Hi Ian,<br>
&gt;<br>
&gt; Thanks for your reply. Sorry to bother you with this. I am bit<br>
&gt; confused and so I am asking to make clear myself.<br>
&gt;<br>
&gt; Reg CVE-2012-2934 -<br>
&gt; <a href=3D"http://lists.xen.org/archives/html/xen-announce/2012-06/msg=
00002.html" target=3D"_blank">http://lists.xen.org/archives/html/xen-announ=
ce/2012-06/msg00002.html</a><br>
&gt; Is Xen 3.4 too affected with this vulnerable? If so I couldn&#39;t fin=
d<br>
&gt; the patch for xen 3.4 and it does exit for xen 4.x only.<br>
<br>
</div>I expect it does effect 3.4, but only if you are running on one of th=
e<br>
listed processors.<br>
<br>
<a href=3D"mailto:security@xen.org">security@xen.org</a> doesn&#39;t provid=
e security support for 3.4 any more. If<br>
you aren&#39;t able to backport the 4.0 patch yourself, you would need to<b=
r>
speak to Keith Coleman who is the 3.4 stable maintainer.<br>
<div class=3D"im"><br>
&gt; I don&#39;t how to apply the following patches since I have created rp=
m<br>
&gt; with patches applied that included as downloadable file. But for these=
<br>
&gt; patches I am not seeing any downloadable file.<br>
&gt;<br>
&gt; <a href=3D"http://lists.xen.org/archives/html/xen-devel/2012-02/msg002=
12.html" target=3D"_blank">http://lists.xen.org/archives/html/xen-devel/201=
2-02/msg00212.html</a><br>
&gt; <a href=3D"http://lists.xen.org/archives/html/xen-devel/2012-07/msg016=
49.html" target=3D"_blank">http://lists.xen.org/archives/html/xen-devel/201=
2-07/msg01649.html</a><br>
&gt; <a href=3D"http://lists.xen.org/archives/html/xen-devel/2012-08/msg008=
55.html" target=3D"_blank">http://lists.xen.org/archives/html/xen-devel/201=
2-08/msg00855.html</a><br>
&gt;<br>
&gt; If you can clear this for me that would be great :)<br>
<br>
</div>I already pointed you at <a href=3D"http://wiki.xen.org/wiki/Security=
_Announcements" target=3D"_blank">http://wiki.xen.org/wiki/Security_Announc=
ements</a><br>
which should have all the links you need.<br>
<br>
<br>
</blockquote></div><br>

--00151743f82e01b70504c9064409--


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

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

--===============1972687549918794135==--


From xen-devel-bounces@lists.xen.org Thu Sep 06 12:09:23 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 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 1T9atW-0006Yb-2N; Thu, 06 Sep 2012 12:09:14 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <kks.kbase@gmail.com>) id 1T9Y55-00036x-0G
	for xen-devel@lists.xen.org; Thu, 06 Sep 2012 09:08:59 +0000
Received: from [85.158.138.51:43682] by server-12.bemta-3.messagelabs.com id
	C5/4A-10384-A2868405; Thu, 06 Sep 2012 09:08:58 +0000
X-Env-Sender: kks.kbase@gmail.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1346922536!29062103!1
X-Originating-IP: [209.85.214.45]
X-SpamReason: No, hits=0.9 required=7.0 tests=HTML_40_50,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21746 invoked from network); 6 Sep 2012 09:08:56 -0000
Received: from mail-bk0-f45.google.com (HELO mail-bk0-f45.google.com)
	(209.85.214.45)
	by server-5.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Sep 2012 09:08:56 -0000
Received: by bkcji1 with SMTP id ji1so659471bkc.32
	for <multiple recipients>; Thu, 06 Sep 2012 02:08:56 -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=SOOv7sUmIDAPjfyj2g9cQZ2zdyjmkSxCKdSjoKNaHGo=;
	b=fo+MT4ThDxyniKW0rTsFlx45nRLUYRCRWfv/jpdAvvPHSfS5Kw5fCsDTiZj/RjcPlG
	SVJBa6Qtq63sXnBKWxZxGlEfPlE30VPZ9o/Rm/QykVT6EWpqpKzttyOgl60D5tJTr6Zc
	dnp+RrAMKmIdyyTA8jYvebxAuxrdFtlctHe9E0097qkqvkPuZzyVzwMTM41uxqH6EFZl
	FRtzHWDW3CoZMNZr4gwZ0B1Gu6Tc0IpizweXdSdRytxG84XiJo5HWTHCmPWXneUUz7lh
	BmWFdNY8Yt+dJlGPUjPXr0SmiJA5zWndhoi+0Sswicx2+PjQUOh66kHeJwUV59g86R4q
	w/xw==
MIME-Version: 1.0
Received: by 10.205.127.72 with SMTP id gz8mr422122bkc.121.1346922536405; Thu,
	06 Sep 2012 02:08:56 -0700 (PDT)
Received: by 10.204.56.134 with HTTP; Thu, 6 Sep 2012 02:08:56 -0700 (PDT)
In-Reply-To: <1346921802.23055.26.camel@zakaz.uk.xensource.com>
References: <CAPU-Ed65dguruSSNrGxk4PmejTJQT7zELXpNAxJULCmdwEvpnA@mail.gmail.com>
	<1346921802.23055.26.camel@zakaz.uk.xensource.com>
Date: Thu, 6 Sep 2012 14:38:56 +0530
Message-ID: <CAPU-Ed4=r6KT0r4fM--94oPPo0mn4LcmwRJh41wHiAFvf6irLg@mail.gmail.com>
From: kk s <kks.kbase@gmail.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
X-Mailman-Approved-At: Thu, 06 Sep 2012 12:09:12 +0000
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] Security patches
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============3557187784032691441=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============3557187784032691441==
Content-Type: multipart/alternative; boundary=0015173fe992528c2804c904d71e

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

Hi Ian,

Thanks for your reply. Sorry to bother you with this. I am bit confused and
so I am asking to make clear myself.

Reg CVE-2012-2934 -
http://lists.xen.org/archives/html/xen-announce/2012-06/msg00002.html Is
Xen 3.4 too affected with this vulnerable? If so I couldn't find the patch
for xen 3.4 and it does exit for xen 4.x only.

I don't how to apply the following patches since I have created rpm with
patches applied that included as downloadable file. But for these patches I
am not seeing any downloadable file.

http://lists.xen.org/archives/html/xen-devel/2012-02/msg00212.html
http://lists.xen.org/archives/html/xen-devel/2012-07/msg01649.html
http://lists.xen.org/archives/html/xen-devel/2012-08/msg00855.html

If you can clear this for me that would be great :)

I hope that I am replying in correct way.


On Thu, Sep 6, 2012 at 2:26 PM, Ian Campbell <Ian.Campbell@citrix.com>wrote:

> On Thu, 2012-09-06 at 09:31 +0100, kk s wrote:
> > Hi,
> >
> > Can anyone give the patch file download link for the below xen
> > security for xen version 3.4 and 4.1? Since I couldn't find the
> > downloadable patch file for some of the CVE's.
> >
> > CVE-2012-0029   -
> http://lists.xen.org/archives/html/xen-devel/2012-02/msg00212.html (There is no download link for both xen 3.4 and 4.1)
> > CVE-2012-2934   -
> http://lists.xen.org/archives/html/xen-announce/2012-06/msg00002.html (There is no patch file to download of xen 3.4)
> > CVE-2012-3432   -
> http://lists.xen.org/archives/html/xen-devel/2012-07/msg01649.html (There is no download link for both xen 3.4 and 4.1)
> > CVE-2012-3433   -
> http://lists.xen.org/archives/html/xen-devel/2012-08/msg00855.html (There is no download link for both xen 3.4 and 4.1)
>
> It looks to me like there are changeset references and/or patches for
> all of these in the advisories. You might find it easier to follow:
>         http://wiki.xen.org/wiki/Security_Announcements
>
> You can also always look in the appropriate xen-X.Y-testing.hg tree for
> the fix.
>
> > CVE-2012-3497   -
> http://lists.xen.org/archives/html/xen-announce/2012-09/msg00006.html (There is no download link for patch)
>
> This is quite clearly explained in the advisory.
>
> > Also I have some doubts for the below CVE's.
> >
> > CVE-2012-3496  - Is this vulnerability affected for xen 4.x only or it
> > does include for xen 3.4 too? Since the patch name was
> > xsa14-xen-3.4-and-4.x.patch
> > http://lists.xen.org/archives/html/xen-announce/2012-09/msg00002.html
>
> Yes, it looks like this effects 3.4 too.
>
> > CVE-2012-3516  - Shall I apply this unstable for patch for xen4.2 too?
> > http://lists.xen.org/archives/html/xen-announce/2012-09/msg00004.html
>
> The advisory says "Xen-unstable, including Xen 4.2 release candidates
> are vulnerable to this issue.", so yes, obviously.
>
> In the future please carefully read the advisories before asking lots of
> questions, almost everything you have asked is addressed in the advisory
> texts AFAICT.
>
> Ian.
>
>
>

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

Hi Ian,<br><br>Thanks for your reply. Sorry to bother you with this. I am b=
it confused and so I am asking to make clear myself.<br><br>Reg <font><span=
 style=3D"font-weight:normal">CVE-2012-2934 - <a href=3D"http://lists.xen.o=
rg/archives/html/xen-announce/2012-06/msg00002.html" target=3D"_blank">http=
://lists.xen.org/archives/html/xen-announce/2012-06/msg00002.html</a></span=
></font> Is Xen 3.4 too affected with this vulnerable? If so I couldn&#39;t=
 find the patch for xen 3.4 and it does exit for xen 4.x only.<br>

<br>I don&#39;t how to apply the following patches since I have created rpm=
=20
with patches applied that included as downloadable file. But for these=20
patches I am not seeing any downloadable file.<br><br><a href=3D"http://lis=
ts.xen.org/archives/html/xen-devel/2012-02/msg00212.html" target=3D"_blank"=
>http://lists.xen.org/archives/html/xen-devel/2012-02/msg00212.html</a><br>

<a href=3D"http://lists.xen.org/archives/html/xen-devel/2012-07/msg01649.ht=
ml" target=3D"_blank">http://lists.xen.org/archives/html/xen-devel/2012-07/=
msg01649.html</a><br><a href=3D"http://lists.xen.org/archives/html/xen-deve=
l/2012-08/msg00855.html" target=3D"_blank">http://lists.xen.org/archives/ht=
ml/xen-devel/2012-08/msg00855.html</a><br>

<br>If you can clear this for me that would be great :)<br><br>I hope that =
I am replying in correct way.<br><br><br><div class=3D"gmail_quote">On Thu,=
 Sep 6, 2012 at 2:26 PM, Ian Campbell <span dir=3D"ltr">&lt;<a href=3D"mail=
to:Ian.Campbell@citrix.com" target=3D"_blank">Ian.Campbell@citrix.com</a>&g=
t;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div class=3D"im">On Thu, 2012-09-06 at 09:3=
1 +0100, kk s wrote:<br>
&gt; Hi,<br>
&gt;<br>
&gt; Can anyone give the patch file download link for the below xen<br>
&gt; security for xen version 3.4 and 4.1? Since I couldn&#39;t find the<br=
>
&gt; downloadable patch file for some of the CVE&#39;s.<br>
&gt;<br>
&gt; CVE-2012-0029 =A0 - <a href=3D"http://lists.xen.org/archives/html/xen-=
devel/2012-02/msg00212.html" target=3D"_blank">http://lists.xen.org/archive=
s/html/xen-devel/2012-02/msg00212.html</a> =A0(There is no download link fo=
r both xen 3.4 and 4.1)<br>

&gt; CVE-2012-2934 =A0 - <a href=3D"http://lists.xen.org/archives/html/xen-=
announce/2012-06/msg00002.html" target=3D"_blank">http://lists.xen.org/arch=
ives/html/xen-announce/2012-06/msg00002.html</a> =A0(There is no patch file=
 to download of xen 3.4)<br>

&gt; CVE-2012-3432 =A0 - <a href=3D"http://lists.xen.org/archives/html/xen-=
devel/2012-07/msg01649.html" target=3D"_blank">http://lists.xen.org/archive=
s/html/xen-devel/2012-07/msg01649.html</a> =A0(There is no download link fo=
r both xen 3.4 and 4.1)<br>

&gt; CVE-2012-3433 =A0 - <a href=3D"http://lists.xen.org/archives/html/xen-=
devel/2012-08/msg00855.html" target=3D"_blank">http://lists.xen.org/archive=
s/html/xen-devel/2012-08/msg00855.html</a> =A0(There is no download link fo=
r both xen 3.4 and 4.1)<br>

<br>
</div>It looks to me like there are changeset references and/or patches for=
<br>
all of these in the advisories. You might find it easier to follow:<br>
=A0 =A0 =A0 =A0 <a href=3D"http://wiki.xen.org/wiki/Security_Announcements"=
 target=3D"_blank">http://wiki.xen.org/wiki/Security_Announcements</a><br>
<br>
You can also always look in the appropriate xen-X.Y-testing.hg tree for<br>
the fix.<br>
<div class=3D"im"><br>
&gt; CVE-2012-3497 =A0 - <a href=3D"http://lists.xen.org/archives/html/xen-=
announce/2012-09/msg00006.html" target=3D"_blank">http://lists.xen.org/arch=
ives/html/xen-announce/2012-09/msg00006.html</a> =A0(There is no download l=
ink for patch)<br>

<br>
</div>This is quite clearly explained in the advisory.<br>
<div class=3D"im"><br>
&gt; Also I have some doubts for the below CVE&#39;s.<br>
&gt;<br>
&gt; CVE-2012-3496 =A0- Is this vulnerability affected for xen 4.x only or =
it<br>
&gt; does include for xen 3.4 too? Since the patch name was<br>
&gt; xsa14-xen-3.4-and-4.x.patch<br>
&gt; <a href=3D"http://lists.xen.org/archives/html/xen-announce/2012-09/msg=
00002.html" target=3D"_blank">http://lists.xen.org/archives/html/xen-announ=
ce/2012-09/msg00002.html</a><br>
<br>
</div>Yes, it looks like this effects 3.4 too.<br>
<div class=3D"im"><br>
&gt; CVE-2012-3516 =A0- Shall I apply this unstable for patch for xen4.2 to=
o?<br>
&gt; <a href=3D"http://lists.xen.org/archives/html/xen-announce/2012-09/msg=
00004.html" target=3D"_blank">http://lists.xen.org/archives/html/xen-announ=
ce/2012-09/msg00004.html</a><br>
<br>
</div>The advisory says &quot;Xen-unstable, including Xen 4.2 release candi=
dates<br>
are vulnerable to this issue.&quot;, so yes, obviously.<br>
<br>
In the future please carefully read the advisories before asking lots of<br=
>
questions, almost everything you have asked is addressed in the advisory<br=
>
texts AFAICT.<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
Ian.<br>
<br>
<br>
</font></span></blockquote></div><br>

--0015173fe992528c2804c904d71e--


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

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

--===============3557187784032691441==--


From xen-devel-bounces@lists.xen.org Thu Sep 06 12:09:23 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 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 1T9atW-0006Yb-2N; Thu, 06 Sep 2012 12:09:14 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <kks.kbase@gmail.com>) id 1T9Y55-00036x-0G
	for xen-devel@lists.xen.org; Thu, 06 Sep 2012 09:08:59 +0000
Received: from [85.158.138.51:43682] by server-12.bemta-3.messagelabs.com id
	C5/4A-10384-A2868405; Thu, 06 Sep 2012 09:08:58 +0000
X-Env-Sender: kks.kbase@gmail.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1346922536!29062103!1
X-Originating-IP: [209.85.214.45]
X-SpamReason: No, hits=0.9 required=7.0 tests=HTML_40_50,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21746 invoked from network); 6 Sep 2012 09:08:56 -0000
Received: from mail-bk0-f45.google.com (HELO mail-bk0-f45.google.com)
	(209.85.214.45)
	by server-5.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Sep 2012 09:08:56 -0000
Received: by bkcji1 with SMTP id ji1so659471bkc.32
	for <multiple recipients>; Thu, 06 Sep 2012 02:08:56 -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=SOOv7sUmIDAPjfyj2g9cQZ2zdyjmkSxCKdSjoKNaHGo=;
	b=fo+MT4ThDxyniKW0rTsFlx45nRLUYRCRWfv/jpdAvvPHSfS5Kw5fCsDTiZj/RjcPlG
	SVJBa6Qtq63sXnBKWxZxGlEfPlE30VPZ9o/Rm/QykVT6EWpqpKzttyOgl60D5tJTr6Zc
	dnp+RrAMKmIdyyTA8jYvebxAuxrdFtlctHe9E0097qkqvkPuZzyVzwMTM41uxqH6EFZl
	FRtzHWDW3CoZMNZr4gwZ0B1Gu6Tc0IpizweXdSdRytxG84XiJo5HWTHCmPWXneUUz7lh
	BmWFdNY8Yt+dJlGPUjPXr0SmiJA5zWndhoi+0Sswicx2+PjQUOh66kHeJwUV59g86R4q
	w/xw==
MIME-Version: 1.0
Received: by 10.205.127.72 with SMTP id gz8mr422122bkc.121.1346922536405; Thu,
	06 Sep 2012 02:08:56 -0700 (PDT)
Received: by 10.204.56.134 with HTTP; Thu, 6 Sep 2012 02:08:56 -0700 (PDT)
In-Reply-To: <1346921802.23055.26.camel@zakaz.uk.xensource.com>
References: <CAPU-Ed65dguruSSNrGxk4PmejTJQT7zELXpNAxJULCmdwEvpnA@mail.gmail.com>
	<1346921802.23055.26.camel@zakaz.uk.xensource.com>
Date: Thu, 6 Sep 2012 14:38:56 +0530
Message-ID: <CAPU-Ed4=r6KT0r4fM--94oPPo0mn4LcmwRJh41wHiAFvf6irLg@mail.gmail.com>
From: kk s <kks.kbase@gmail.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
X-Mailman-Approved-At: Thu, 06 Sep 2012 12:09:12 +0000
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] Security patches
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============3557187784032691441=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============3557187784032691441==
Content-Type: multipart/alternative; boundary=0015173fe992528c2804c904d71e

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

Hi Ian,

Thanks for your reply. Sorry to bother you with this. I am bit confused and
so I am asking to make clear myself.

Reg CVE-2012-2934 -
http://lists.xen.org/archives/html/xen-announce/2012-06/msg00002.html Is
Xen 3.4 too affected with this vulnerable? If so I couldn't find the patch
for xen 3.4 and it does exit for xen 4.x only.

I don't how to apply the following patches since I have created rpm with
patches applied that included as downloadable file. But for these patches I
am not seeing any downloadable file.

http://lists.xen.org/archives/html/xen-devel/2012-02/msg00212.html
http://lists.xen.org/archives/html/xen-devel/2012-07/msg01649.html
http://lists.xen.org/archives/html/xen-devel/2012-08/msg00855.html

If you can clear this for me that would be great :)

I hope that I am replying in correct way.


On Thu, Sep 6, 2012 at 2:26 PM, Ian Campbell <Ian.Campbell@citrix.com>wrote:

> On Thu, 2012-09-06 at 09:31 +0100, kk s wrote:
> > Hi,
> >
> > Can anyone give the patch file download link for the below xen
> > security for xen version 3.4 and 4.1? Since I couldn't find the
> > downloadable patch file for some of the CVE's.
> >
> > CVE-2012-0029   -
> http://lists.xen.org/archives/html/xen-devel/2012-02/msg00212.html (There is no download link for both xen 3.4 and 4.1)
> > CVE-2012-2934   -
> http://lists.xen.org/archives/html/xen-announce/2012-06/msg00002.html (There is no patch file to download of xen 3.4)
> > CVE-2012-3432   -
> http://lists.xen.org/archives/html/xen-devel/2012-07/msg01649.html (There is no download link for both xen 3.4 and 4.1)
> > CVE-2012-3433   -
> http://lists.xen.org/archives/html/xen-devel/2012-08/msg00855.html (There is no download link for both xen 3.4 and 4.1)
>
> It looks to me like there are changeset references and/or patches for
> all of these in the advisories. You might find it easier to follow:
>         http://wiki.xen.org/wiki/Security_Announcements
>
> You can also always look in the appropriate xen-X.Y-testing.hg tree for
> the fix.
>
> > CVE-2012-3497   -
> http://lists.xen.org/archives/html/xen-announce/2012-09/msg00006.html (There is no download link for patch)
>
> This is quite clearly explained in the advisory.
>
> > Also I have some doubts for the below CVE's.
> >
> > CVE-2012-3496  - Is this vulnerability affected for xen 4.x only or it
> > does include for xen 3.4 too? Since the patch name was
> > xsa14-xen-3.4-and-4.x.patch
> > http://lists.xen.org/archives/html/xen-announce/2012-09/msg00002.html
>
> Yes, it looks like this effects 3.4 too.
>
> > CVE-2012-3516  - Shall I apply this unstable for patch for xen4.2 too?
> > http://lists.xen.org/archives/html/xen-announce/2012-09/msg00004.html
>
> The advisory says "Xen-unstable, including Xen 4.2 release candidates
> are vulnerable to this issue.", so yes, obviously.
>
> In the future please carefully read the advisories before asking lots of
> questions, almost everything you have asked is addressed in the advisory
> texts AFAICT.
>
> Ian.
>
>
>

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

Hi Ian,<br><br>Thanks for your reply. Sorry to bother you with this. I am b=
it confused and so I am asking to make clear myself.<br><br>Reg <font><span=
 style=3D"font-weight:normal">CVE-2012-2934 - <a href=3D"http://lists.xen.o=
rg/archives/html/xen-announce/2012-06/msg00002.html" target=3D"_blank">http=
://lists.xen.org/archives/html/xen-announce/2012-06/msg00002.html</a></span=
></font> Is Xen 3.4 too affected with this vulnerable? If so I couldn&#39;t=
 find the patch for xen 3.4 and it does exit for xen 4.x only.<br>

<br>I don&#39;t how to apply the following patches since I have created rpm=
=20
with patches applied that included as downloadable file. But for these=20
patches I am not seeing any downloadable file.<br><br><a href=3D"http://lis=
ts.xen.org/archives/html/xen-devel/2012-02/msg00212.html" target=3D"_blank"=
>http://lists.xen.org/archives/html/xen-devel/2012-02/msg00212.html</a><br>

<a href=3D"http://lists.xen.org/archives/html/xen-devel/2012-07/msg01649.ht=
ml" target=3D"_blank">http://lists.xen.org/archives/html/xen-devel/2012-07/=
msg01649.html</a><br><a href=3D"http://lists.xen.org/archives/html/xen-deve=
l/2012-08/msg00855.html" target=3D"_blank">http://lists.xen.org/archives/ht=
ml/xen-devel/2012-08/msg00855.html</a><br>

<br>If you can clear this for me that would be great :)<br><br>I hope that =
I am replying in correct way.<br><br><br><div class=3D"gmail_quote">On Thu,=
 Sep 6, 2012 at 2:26 PM, Ian Campbell <span dir=3D"ltr">&lt;<a href=3D"mail=
to:Ian.Campbell@citrix.com" target=3D"_blank">Ian.Campbell@citrix.com</a>&g=
t;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div class=3D"im">On Thu, 2012-09-06 at 09:3=
1 +0100, kk s wrote:<br>
&gt; Hi,<br>
&gt;<br>
&gt; Can anyone give the patch file download link for the below xen<br>
&gt; security for xen version 3.4 and 4.1? Since I couldn&#39;t find the<br=
>
&gt; downloadable patch file for some of the CVE&#39;s.<br>
&gt;<br>
&gt; CVE-2012-0029 =A0 - <a href=3D"http://lists.xen.org/archives/html/xen-=
devel/2012-02/msg00212.html" target=3D"_blank">http://lists.xen.org/archive=
s/html/xen-devel/2012-02/msg00212.html</a> =A0(There is no download link fo=
r both xen 3.4 and 4.1)<br>

&gt; CVE-2012-2934 =A0 - <a href=3D"http://lists.xen.org/archives/html/xen-=
announce/2012-06/msg00002.html" target=3D"_blank">http://lists.xen.org/arch=
ives/html/xen-announce/2012-06/msg00002.html</a> =A0(There is no patch file=
 to download of xen 3.4)<br>

&gt; CVE-2012-3432 =A0 - <a href=3D"http://lists.xen.org/archives/html/xen-=
devel/2012-07/msg01649.html" target=3D"_blank">http://lists.xen.org/archive=
s/html/xen-devel/2012-07/msg01649.html</a> =A0(There is no download link fo=
r both xen 3.4 and 4.1)<br>

&gt; CVE-2012-3433 =A0 - <a href=3D"http://lists.xen.org/archives/html/xen-=
devel/2012-08/msg00855.html" target=3D"_blank">http://lists.xen.org/archive=
s/html/xen-devel/2012-08/msg00855.html</a> =A0(There is no download link fo=
r both xen 3.4 and 4.1)<br>

<br>
</div>It looks to me like there are changeset references and/or patches for=
<br>
all of these in the advisories. You might find it easier to follow:<br>
=A0 =A0 =A0 =A0 <a href=3D"http://wiki.xen.org/wiki/Security_Announcements"=
 target=3D"_blank">http://wiki.xen.org/wiki/Security_Announcements</a><br>
<br>
You can also always look in the appropriate xen-X.Y-testing.hg tree for<br>
the fix.<br>
<div class=3D"im"><br>
&gt; CVE-2012-3497 =A0 - <a href=3D"http://lists.xen.org/archives/html/xen-=
announce/2012-09/msg00006.html" target=3D"_blank">http://lists.xen.org/arch=
ives/html/xen-announce/2012-09/msg00006.html</a> =A0(There is no download l=
ink for patch)<br>

<br>
</div>This is quite clearly explained in the advisory.<br>
<div class=3D"im"><br>
&gt; Also I have some doubts for the below CVE&#39;s.<br>
&gt;<br>
&gt; CVE-2012-3496 =A0- Is this vulnerability affected for xen 4.x only or =
it<br>
&gt; does include for xen 3.4 too? Since the patch name was<br>
&gt; xsa14-xen-3.4-and-4.x.patch<br>
&gt; <a href=3D"http://lists.xen.org/archives/html/xen-announce/2012-09/msg=
00002.html" target=3D"_blank">http://lists.xen.org/archives/html/xen-announ=
ce/2012-09/msg00002.html</a><br>
<br>
</div>Yes, it looks like this effects 3.4 too.<br>
<div class=3D"im"><br>
&gt; CVE-2012-3516 =A0- Shall I apply this unstable for patch for xen4.2 to=
o?<br>
&gt; <a href=3D"http://lists.xen.org/archives/html/xen-announce/2012-09/msg=
00004.html" target=3D"_blank">http://lists.xen.org/archives/html/xen-announ=
ce/2012-09/msg00004.html</a><br>
<br>
</div>The advisory says &quot;Xen-unstable, including Xen 4.2 release candi=
dates<br>
are vulnerable to this issue.&quot;, so yes, obviously.<br>
<br>
In the future please carefully read the advisories before asking lots of<br=
>
questions, almost everything you have asked is addressed in the advisory<br=
>
texts AFAICT.<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
Ian.<br>
<br>
<br>
</font></span></blockquote></div><br>

--0015173fe992528c2804c904d71e--


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

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

--===============3557187784032691441==--


From xen-devel-bounces@lists.xen.org Thu Sep 06 12:09:23 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 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 1T9atW-0006Yl-Ez; Thu, 06 Sep 2012 12:09:14 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <kks.kbase@gmail.com>) id 1T9YAb-0003XJ-RZ
	for xen-devel@lists.xen.org; Thu, 06 Sep 2012 09:14:42 +0000
Received: from [85.158.139.83:58995] by server-3.bemta-5.messagelabs.com id
	95/BE-21836-08968405; Thu, 06 Sep 2012 09:14:40 +0000
X-Env-Sender: kks.kbase@gmail.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1346922880!28658026!1
X-Originating-IP: [209.85.214.45]
X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_10_20,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31760 invoked from network); 6 Sep 2012 09:14:40 -0000
Received: from mail-bk0-f45.google.com (HELO mail-bk0-f45.google.com)
	(209.85.214.45)
	by server-5.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Sep 2012 09:14:40 -0000
Received: by bkcji1 with SMTP id ji1so662618bkc.32
	for <multiple recipients>; Thu, 06 Sep 2012 02:14: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=m4gDY9EYLd5BSKK+88RD//Nfqk9RdX5fCTCKMVp5YEo=;
	b=yq9+lIgwMT2pnD9ZvCtCx9tGA20EPwzYb7xgy9wpXoBnU06HyopTULlNwV583qOCGE
	/+GBtcr5XxiYJrdq0f2O1n5ngfMmU13JlYKdhRlT/GR4ZzqaQ7iDfaJ7nteArTV/8oR5
	xeZs7ttlLXXm24bEWQvFszMGDI6DqFRkBqWFCAHU5J86kRw+Hc3Vwp0uB6yiSE13gFrH
	gXdcsU4oq/9UOavLKmb1ICXa0dSFhpf01KA9g3+eU02fsIpoqGb867qY5s9eO8V4QvjF
	JWbdaNaUvRF+rXL06f9qudhovrxEGhxZYAzuMdyGaTWaW7n4t+7a4Q/90molTWOGULSr
	YVLQ==
MIME-Version: 1.0
Received: by 10.204.154.131 with SMTP id o3mr438749bkw.87.1346922879846; Thu,
	06 Sep 2012 02:14:39 -0700 (PDT)
Received: by 10.204.56.134 with HTTP; Thu, 6 Sep 2012 02:14:39 -0700 (PDT)
Date: Thu, 6 Sep 2012 14:44:39 +0530
Message-ID: <CAPU-Ed7nBbCikRHVsNr+WY3-4c3Z9XV+-gmRLf2GdJaJiO0rLg@mail.gmail.com>
From: kk s <kks.kbase@gmail.com>
To: xen-users@lists.xen.org, xen-devel@lists.xen.org
X-Mailman-Approved-At: Thu, 06 Sep 2012 12:09:12 +0000
Subject: [Xen-devel] Issue with making rpm with patch applied
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0974290944371246163=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============0974290944371246163==
Content-Type: multipart/alternative; boundary=0015175cae66cb089204c904eb73

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

Hi,

I have downloaded src rpm from gitco and extracted into the
/usr/src/redhat/SOURCES dir then downloaded the patches and renamed it as
properly like xen-3.4.4-xsa17-qemu-xen-traditional-all.patch. Then edited
the xen-x.spec file and added the patches. After that I have tried to make
rpm using rpmbuild -bb xen-x.spec and I ended up with the below error,


Patch #13 (xen-3.4.4-xsa17-qemu-xen-traditional-all.patch):
+ patch -p1 -s
The text leading up to this was:
--------------------------
|console: bounds check whenever changing the cursor due to an escape code
|
|This is XSA-17 / CVE-2012-3515
|
|Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
|
|diff --git a/console.c b/console.c
|index 5e6e3d0..9984d6f 100644
|--- a/console.c
|+++ b/console.c
--------------------------
File to patch:


Fyi : I have added the patches xsa12-all.patch, xsa14-xen-3.4-and-4.x.patch
and xsa17-qemu-xen-traditional-all.patch. All the patches goes fine expect
xsa17-qemu-xen-traditional-all.patch.

May I know how can I apply this?

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

Hi,<br><br>I have downloaded src rpm from gitco and extracted into the /usr=
/src/redhat/SOURCES dir then downloaded the patches and renamed it as prope=
rly like xen-3.4.4-xsa17-qemu-xen-traditional-all.patch. Then edited the xe=
n-x.spec file and added the patches. After that I have tried to make rpm us=
ing rpmbuild -bb xen-x.spec and I ended up with the below error,<br>
<br><br>Patch #13 (xen-3.4.4-xsa17-qemu-xen-traditional-all.patch):<br>+ pa=
tch -p1 -s<br>The text leading up to this was:<br>-------------------------=
-<br>|console: bounds check whenever changing the cursor due to an escape c=
ode<br>
|<br>|This is XSA-17 / CVE-2012-3515<br>|<br>|Signed-off-by: Ian Campbell &=
lt;<a href=3D"mailto:ian.campbell@citrix.com">ian.campbell@citrix.com</a>&g=
t;<br>|<br>|diff --git a/console.c b/console.c<br>|index 5e6e3d0..9984d6f 1=
00644<br>
|--- a/console.c<br>|+++ b/console.c<br>--------------------------<br>File =
to patch:=A0=A0=A0=A0=A0 <br><br><br>Fyi : I have added the patches xsa12-a=
ll.patch, xsa14-xen-3.4-and-4.x.patch and xsa17-qemu-xen-traditional-all.pa=
tch. All the patches goes fine expect xsa17-qemu-xen-traditional-all.patch.=
<br>
<br>May I know how can I apply this?<br><br>

--0015175cae66cb089204c904eb73--


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

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

--===============0974290944371246163==--


From xen-devel-bounces@lists.xen.org Thu Sep 06 12:09:23 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 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 1T9atW-0006Yl-Ez; Thu, 06 Sep 2012 12:09:14 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <kks.kbase@gmail.com>) id 1T9YAb-0003XJ-RZ
	for xen-devel@lists.xen.org; Thu, 06 Sep 2012 09:14:42 +0000
Received: from [85.158.139.83:58995] by server-3.bemta-5.messagelabs.com id
	95/BE-21836-08968405; Thu, 06 Sep 2012 09:14:40 +0000
X-Env-Sender: kks.kbase@gmail.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1346922880!28658026!1
X-Originating-IP: [209.85.214.45]
X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_10_20,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31760 invoked from network); 6 Sep 2012 09:14:40 -0000
Received: from mail-bk0-f45.google.com (HELO mail-bk0-f45.google.com)
	(209.85.214.45)
	by server-5.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Sep 2012 09:14:40 -0000
Received: by bkcji1 with SMTP id ji1so662618bkc.32
	for <multiple recipients>; Thu, 06 Sep 2012 02:14: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=m4gDY9EYLd5BSKK+88RD//Nfqk9RdX5fCTCKMVp5YEo=;
	b=yq9+lIgwMT2pnD9ZvCtCx9tGA20EPwzYb7xgy9wpXoBnU06HyopTULlNwV583qOCGE
	/+GBtcr5XxiYJrdq0f2O1n5ngfMmU13JlYKdhRlT/GR4ZzqaQ7iDfaJ7nteArTV/8oR5
	xeZs7ttlLXXm24bEWQvFszMGDI6DqFRkBqWFCAHU5J86kRw+Hc3Vwp0uB6yiSE13gFrH
	gXdcsU4oq/9UOavLKmb1ICXa0dSFhpf01KA9g3+eU02fsIpoqGb867qY5s9eO8V4QvjF
	JWbdaNaUvRF+rXL06f9qudhovrxEGhxZYAzuMdyGaTWaW7n4t+7a4Q/90molTWOGULSr
	YVLQ==
MIME-Version: 1.0
Received: by 10.204.154.131 with SMTP id o3mr438749bkw.87.1346922879846; Thu,
	06 Sep 2012 02:14:39 -0700 (PDT)
Received: by 10.204.56.134 with HTTP; Thu, 6 Sep 2012 02:14:39 -0700 (PDT)
Date: Thu, 6 Sep 2012 14:44:39 +0530
Message-ID: <CAPU-Ed7nBbCikRHVsNr+WY3-4c3Z9XV+-gmRLf2GdJaJiO0rLg@mail.gmail.com>
From: kk s <kks.kbase@gmail.com>
To: xen-users@lists.xen.org, xen-devel@lists.xen.org
X-Mailman-Approved-At: Thu, 06 Sep 2012 12:09:12 +0000
Subject: [Xen-devel] Issue with making rpm with patch applied
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0974290944371246163=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============0974290944371246163==
Content-Type: multipart/alternative; boundary=0015175cae66cb089204c904eb73

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

Hi,

I have downloaded src rpm from gitco and extracted into the
/usr/src/redhat/SOURCES dir then downloaded the patches and renamed it as
properly like xen-3.4.4-xsa17-qemu-xen-traditional-all.patch. Then edited
the xen-x.spec file and added the patches. After that I have tried to make
rpm using rpmbuild -bb xen-x.spec and I ended up with the below error,


Patch #13 (xen-3.4.4-xsa17-qemu-xen-traditional-all.patch):
+ patch -p1 -s
The text leading up to this was:
--------------------------
|console: bounds check whenever changing the cursor due to an escape code
|
|This is XSA-17 / CVE-2012-3515
|
|Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
|
|diff --git a/console.c b/console.c
|index 5e6e3d0..9984d6f 100644
|--- a/console.c
|+++ b/console.c
--------------------------
File to patch:


Fyi : I have added the patches xsa12-all.patch, xsa14-xen-3.4-and-4.x.patch
and xsa17-qemu-xen-traditional-all.patch. All the patches goes fine expect
xsa17-qemu-xen-traditional-all.patch.

May I know how can I apply this?

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

Hi,<br><br>I have downloaded src rpm from gitco and extracted into the /usr=
/src/redhat/SOURCES dir then downloaded the patches and renamed it as prope=
rly like xen-3.4.4-xsa17-qemu-xen-traditional-all.patch. Then edited the xe=
n-x.spec file and added the patches. After that I have tried to make rpm us=
ing rpmbuild -bb xen-x.spec and I ended up with the below error,<br>
<br><br>Patch #13 (xen-3.4.4-xsa17-qemu-xen-traditional-all.patch):<br>+ pa=
tch -p1 -s<br>The text leading up to this was:<br>-------------------------=
-<br>|console: bounds check whenever changing the cursor due to an escape c=
ode<br>
|<br>|This is XSA-17 / CVE-2012-3515<br>|<br>|Signed-off-by: Ian Campbell &=
lt;<a href=3D"mailto:ian.campbell@citrix.com">ian.campbell@citrix.com</a>&g=
t;<br>|<br>|diff --git a/console.c b/console.c<br>|index 5e6e3d0..9984d6f 1=
00644<br>
|--- a/console.c<br>|+++ b/console.c<br>--------------------------<br>File =
to patch:=A0=A0=A0=A0=A0 <br><br><br>Fyi : I have added the patches xsa12-a=
ll.patch, xsa14-xen-3.4-and-4.x.patch and xsa17-qemu-xen-traditional-all.pa=
tch. All the patches goes fine expect xsa17-qemu-xen-traditional-all.patch.=
<br>
<br>May I know how can I apply this?<br><br>

--0015175cae66cb089204c904eb73--


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

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

--===============0974290944371246163==--


From xen-devel-bounces@lists.xen.org Thu Sep 06 12:22:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 2012 12: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 1T9b64-0007Au-Bi; Thu, 06 Sep 2012 12:22: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 1T9b62-0007AY-4O
	for xen-devel@lists.xen.org; Thu, 06 Sep 2012 12:22:10 +0000
Received: from [85.158.139.83:58445] by server-10.bemta-5.messagelabs.com id
	F0/FD-10969-17598405; Thu, 06 Sep 2012 12:22:09 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1346934127!24994177!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM5ODQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15006 invoked from network); 6 Sep 2012 12:22:07 -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;
	6 Sep 2012 12:22:07 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 06 Sep 2012 13:22:19 +0100
Message-Id: <5048B1C4020000780009952E@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 06 Sep 2012 13:23:00 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Campbell" <ian.campbell@citrix.com>
References: <22d5e100131d1576d455.1346932605@cosworth.uk.xensource.com>
In-Reply-To: <22d5e100131d1576d455.1346932605@cosworth.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: tim@xen.org, DarioFaggioli <dario.faggioli@citrix.com>, keir@xen.org,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] xen: clamp bitmaps to correct number of bits
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.09.12 at 13:56, Ian Campbell <ian.campbell@citrix.com> wrote:
> The principal of least surprise suggests that these bits ought not to
> be set and this is not a hot path so fix this at the hypervisor layer
> by clamping the bits in the returned bitmap to the correct limit.

Hmm, I see your point, but without looking at the description
above (i.e. if I just saw the code in its post-patch form) I'd be
immediately tempted to rip this all out again, the more that
the inverse functions don't do the same. So perhaps extending
the comment before the newly added function would be useful
to prevent such desires from coming up?

> @@ -38,6 +38,17 @@
>   * for the best explanations of this ordering.
>   */
>  
> +/* Ensure that the last byte is zero from nbits onwards. */
> +static void clamp_last_byte(uint8_t *bp, int nbits)
> +{
> +	int lastbyte = nbits/8;
> +	int remainder = nbits % 8;
> +	int mask = ((1U<<remainder)-1)&0xff;

While I realize the callers use plain int, I'd be very much in favor
of not continuing this bad practice (the more that you use 1U
already) - simply make the parameter and all locals (assuming
you really think they're useful; I would have omitted all but
"remainder", given they're being used just once) unsigned.

And once at it, please insert spaces consistently and drop the
bogus "&0xff".

Jan

> +
> +	if (remainder)
> +		bp[lastbyte] &= mask;
> +}
> +
>  int __bitmap_empty(const unsigned long *bitmap, int bits)
>  {
>  	int k, lim = bits/BITS_PER_LONG;



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

From xen-devel-bounces@lists.xen.org Thu Sep 06 12:22:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 2012 12: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 1T9b64-0007Au-Bi; Thu, 06 Sep 2012 12:22: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 1T9b62-0007AY-4O
	for xen-devel@lists.xen.org; Thu, 06 Sep 2012 12:22:10 +0000
Received: from [85.158.139.83:58445] by server-10.bemta-5.messagelabs.com id
	F0/FD-10969-17598405; Thu, 06 Sep 2012 12:22:09 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1346934127!24994177!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM5ODQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15006 invoked from network); 6 Sep 2012 12:22:07 -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;
	6 Sep 2012 12:22:07 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 06 Sep 2012 13:22:19 +0100
Message-Id: <5048B1C4020000780009952E@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 06 Sep 2012 13:23:00 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Campbell" <ian.campbell@citrix.com>
References: <22d5e100131d1576d455.1346932605@cosworth.uk.xensource.com>
In-Reply-To: <22d5e100131d1576d455.1346932605@cosworth.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: tim@xen.org, DarioFaggioli <dario.faggioli@citrix.com>, keir@xen.org,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] xen: clamp bitmaps to correct number of bits
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.09.12 at 13:56, Ian Campbell <ian.campbell@citrix.com> wrote:
> The principal of least surprise suggests that these bits ought not to
> be set and this is not a hot path so fix this at the hypervisor layer
> by clamping the bits in the returned bitmap to the correct limit.

Hmm, I see your point, but without looking at the description
above (i.e. if I just saw the code in its post-patch form) I'd be
immediately tempted to rip this all out again, the more that
the inverse functions don't do the same. So perhaps extending
the comment before the newly added function would be useful
to prevent such desires from coming up?

> @@ -38,6 +38,17 @@
>   * for the best explanations of this ordering.
>   */
>  
> +/* Ensure that the last byte is zero from nbits onwards. */
> +static void clamp_last_byte(uint8_t *bp, int nbits)
> +{
> +	int lastbyte = nbits/8;
> +	int remainder = nbits % 8;
> +	int mask = ((1U<<remainder)-1)&0xff;

While I realize the callers use plain int, I'd be very much in favor
of not continuing this bad practice (the more that you use 1U
already) - simply make the parameter and all locals (assuming
you really think they're useful; I would have omitted all but
"remainder", given they're being used just once) unsigned.

And once at it, please insert spaces consistently and drop the
bogus "&0xff".

Jan

> +
> +	if (remainder)
> +		bp[lastbyte] &= mask;
> +}
> +
>  int __bitmap_empty(const unsigned long *bitmap, int bits)
>  {
>  	int k, lim = bits/BITS_PER_LONG;



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

From xen-devel-bounces@lists.xen.org Thu Sep 06 12:25:01 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 2012 12: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 1T9b8b-0007JP-VK; Thu, 06 Sep 2012 12:24:49 +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 1T9b8a-0007JG-8K
	for xen-devel@lists.xen.org; Thu, 06 Sep 2012 12:24:48 +0000
Received: from [85.158.138.51:20671] by server-4.bemta-3.messagelabs.com id
	87/2D-24831-F0698405; Thu, 06 Sep 2012 12:24:47 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-11.tower-174.messagelabs.com!1346934286!29031013!1
X-Originating-IP: [63.239.67.9]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32528 invoked from network); 6 Sep 2012 12:24:46 -0000
Received: from emvm-gh1-uea08.nsa.gov (HELO nsa.gov) (63.239.67.9)
	by server-11.tower-174.messagelabs.com with SMTP;
	6 Sep 2012 12:24:46 -0000
X-TM-IMSS-Message-ID: <1a36617d000c8bb2@nsa.gov>
Received: from tarius.tycho.ncsc.mil ([144.51.3.1]) by nsa.gov ([63.239.67.9])
	with ESMTP (TREND IMSS SMTP Service 7.1) id 1a36617d000c8bb2 ;
	Thu, 6 Sep 2012 08:24:46 -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 q86COfSE012245; 
	Thu, 6 Sep 2012 08:24:41 -0400
Message-ID: <50489609.6050502@tycho.nsa.gov>
Date: Thu, 06 Sep 2012 08:24:41 -0400
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Organization: National Security Agency
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120828 Thunderbird/15.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <1346400260.27277.93.camel@zakaz.uk.xensource.com>
	<1346864713-28732-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1346916391.10570.17.camel@dagon.hellion.org.uk>
In-Reply-To: <1346916391.10570.17.camel@dagon.hellion.org.uk>
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: Support backend domain ID for
	disks
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 09/06/2012 03:26 AM, Ian Campbell wrote:
> On Wed, 2012-09-05 at 18:05 +0100, Daniel De Graaf wrote:
>> Allow specification of backend domains for disks, either in the config
>> file or via xl block-attach. This functionality was supported in xend
>> (via an optional command line parameter to block-attach), so should also
>> be supported with libxl.
>>
>> In order to support named backend domains like network-attach, a valid
>> libxl_ctx must now be passed to xlu_cfg_init.
>>
>> Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
> 
> Sorry but I think in the end this has missed the cut-off for 4.2.0 (we
> are cutting the final RC tomorrow).
> 
> We should be branching soon after the final RC which means 4.3
> development will open in unstable shortly. We should take this into
> unstable then and consider it for 4.2.1.
> 
> In the meantime I suppose we should mention this in the release notes.
> 

That's fine; I just wanted to be sure that the change to xlu_cfg_init
was noticed and that the API change was noted in 4.2.0 if that is needed
to make this acceptable for 4.2.1. Sorry I didn't get this in earlier; I
didn't notice that you wanted me to resubmit until it was too late.

-- 
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 Sep 06 12:25:01 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 2012 12: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 1T9b8b-0007JP-VK; Thu, 06 Sep 2012 12:24:49 +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 1T9b8a-0007JG-8K
	for xen-devel@lists.xen.org; Thu, 06 Sep 2012 12:24:48 +0000
Received: from [85.158.138.51:20671] by server-4.bemta-3.messagelabs.com id
	87/2D-24831-F0698405; Thu, 06 Sep 2012 12:24:47 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-11.tower-174.messagelabs.com!1346934286!29031013!1
X-Originating-IP: [63.239.67.9]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32528 invoked from network); 6 Sep 2012 12:24:46 -0000
Received: from emvm-gh1-uea08.nsa.gov (HELO nsa.gov) (63.239.67.9)
	by server-11.tower-174.messagelabs.com with SMTP;
	6 Sep 2012 12:24:46 -0000
X-TM-IMSS-Message-ID: <1a36617d000c8bb2@nsa.gov>
Received: from tarius.tycho.ncsc.mil ([144.51.3.1]) by nsa.gov ([63.239.67.9])
	with ESMTP (TREND IMSS SMTP Service 7.1) id 1a36617d000c8bb2 ;
	Thu, 6 Sep 2012 08:24:46 -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 q86COfSE012245; 
	Thu, 6 Sep 2012 08:24:41 -0400
Message-ID: <50489609.6050502@tycho.nsa.gov>
Date: Thu, 06 Sep 2012 08:24:41 -0400
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Organization: National Security Agency
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120828 Thunderbird/15.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <1346400260.27277.93.camel@zakaz.uk.xensource.com>
	<1346864713-28732-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1346916391.10570.17.camel@dagon.hellion.org.uk>
In-Reply-To: <1346916391.10570.17.camel@dagon.hellion.org.uk>
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: Support backend domain ID for
	disks
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 09/06/2012 03:26 AM, Ian Campbell wrote:
> On Wed, 2012-09-05 at 18:05 +0100, Daniel De Graaf wrote:
>> Allow specification of backend domains for disks, either in the config
>> file or via xl block-attach. This functionality was supported in xend
>> (via an optional command line parameter to block-attach), so should also
>> be supported with libxl.
>>
>> In order to support named backend domains like network-attach, a valid
>> libxl_ctx must now be passed to xlu_cfg_init.
>>
>> Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
> 
> Sorry but I think in the end this has missed the cut-off for 4.2.0 (we
> are cutting the final RC tomorrow).
> 
> We should be branching soon after the final RC which means 4.3
> development will open in unstable shortly. We should take this into
> unstable then and consider it for 4.2.1.
> 
> In the meantime I suppose we should mention this in the release notes.
> 

That's fine; I just wanted to be sure that the change to xlu_cfg_init
was noticed and that the API change was noted in 4.2.0 if that is needed
to make this acceptable for 4.2.1. Sorry I didn't get this in earlier; I
didn't notice that you wanted me to resubmit until it was too late.

-- 
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 Sep 06 12:25:25 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 2012 12: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 1T9b92-0007LL-D4; Thu, 06 Sep 2012 12:25: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 1T9b90-0007LC-O1
	for xen-devel@lists.xen.org; Thu, 06 Sep 2012 12:25:14 +0000
Received: from [85.158.139.83:33888] by server-5.bemta-5.messagelabs.com id
	FD/D9-30514-92698405; Thu, 06 Sep 2012 12:25:13 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1346934312!21595381!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM5ODQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29645 invoked from network); 6 Sep 2012 12:25:12 -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;
	6 Sep 2012 12:25:12 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 06 Sep 2012 13:25:25 +0100
Message-Id: <5048B27F0200007800099535@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 06 Sep 2012 13:26:07 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "David Vrabel" <david.vrabel@citrix.com>
References: <1346933118-28928-1-git-send-email-david.vrabel@citrix.com>
In-Reply-To: <1346933118-28928-1-git-send-email-david.vrabel@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] timer: remove stray local_irq_enable()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.09.12 at 14:05, David Vrabel <david.vrabel@citrix.com> wrote:
> From: David Vrabel <david.vrabel@citrix.com>
> 
> migrate_timers_from_cpu() has a stray local_irq_enable() that does
> nothing (it's immediately after a spin_unlock_irq()) and has no
> matching local_irq_disable().
> 
> Signed-off-by: David Vrabel <david.vrabel@citrix.com>

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

> --- a/xen/common/timer.c
> +++ b/xen/common/timer.c
> @@ -587,7 +587,6 @@ static void migrate_timers_from_cpu(unsigned int old_cpu)
>  
>      spin_unlock(&old_ts->lock);
>      spin_unlock_irq(&new_ts->lock);
> -    local_irq_enable();
>  
>      if ( notify )
>          cpu_raise_softirq(new_cpu, TIMER_SOFTIRQ);



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

From xen-devel-bounces@lists.xen.org Thu Sep 06 12:25:25 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 2012 12: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 1T9b92-0007LL-D4; Thu, 06 Sep 2012 12:25: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 1T9b90-0007LC-O1
	for xen-devel@lists.xen.org; Thu, 06 Sep 2012 12:25:14 +0000
Received: from [85.158.139.83:33888] by server-5.bemta-5.messagelabs.com id
	FD/D9-30514-92698405; Thu, 06 Sep 2012 12:25:13 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1346934312!21595381!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM5ODQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29645 invoked from network); 6 Sep 2012 12:25:12 -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;
	6 Sep 2012 12:25:12 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 06 Sep 2012 13:25:25 +0100
Message-Id: <5048B27F0200007800099535@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 06 Sep 2012 13:26:07 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "David Vrabel" <david.vrabel@citrix.com>
References: <1346933118-28928-1-git-send-email-david.vrabel@citrix.com>
In-Reply-To: <1346933118-28928-1-git-send-email-david.vrabel@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] timer: remove stray local_irq_enable()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.09.12 at 14:05, David Vrabel <david.vrabel@citrix.com> wrote:
> From: David Vrabel <david.vrabel@citrix.com>
> 
> migrate_timers_from_cpu() has a stray local_irq_enable() that does
> nothing (it's immediately after a spin_unlock_irq()) and has no
> matching local_irq_disable().
> 
> Signed-off-by: David Vrabel <david.vrabel@citrix.com>

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

> --- a/xen/common/timer.c
> +++ b/xen/common/timer.c
> @@ -587,7 +587,6 @@ static void migrate_timers_from_cpu(unsigned int old_cpu)
>  
>      spin_unlock(&old_ts->lock);
>      spin_unlock_irq(&new_ts->lock);
> -    local_irq_enable();
>  
>      if ( notify )
>          cpu_raise_softirq(new_cpu, TIMER_SOFTIRQ);



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

From xen-devel-bounces@lists.xen.org Thu Sep 06 12:31:52 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 2012 12:31:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9bFG-0007ii-Bq; Thu, 06 Sep 2012 12:31: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 1T9bFF-0007id-2s
	for xen-devel@lists.xen.org; Thu, 06 Sep 2012 12:31:41 +0000
Received: from [85.158.143.99:37613] by server-2.bemta-4.messagelabs.com id
	DF/8B-21239-CA798405; Thu, 06 Sep 2012 12:31:40 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-7.tower-216.messagelabs.com!1346934699!25533974!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16085 invoked from network); 6 Sep 2012 12:31:39 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-7.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 6 Sep 2012 12:31:39 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1T9bFB-000FLS-6g; Thu, 06 Sep 2012 12:31:37 +0000
Date: Thu, 6 Sep 2012 13:31:37 +0100
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <ian.campbell@citrix.com>
Message-ID: <20120906123137.GJ56463@ocelot.phlegethon.org>
References: <1346678886.32462.9.camel@zakaz.uk.xensource.com>
	<1346679056-8108-10-git-send-email-ian.campbell@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1346679056-8108-10-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 10/16] arm: print a message if multiple
	banks of memory are present.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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:30 +0000 on 03 Sep (1346679050), 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 Sep 06 12:31:52 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 2012 12:31:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9bFG-0007ii-Bq; Thu, 06 Sep 2012 12:31: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 1T9bFF-0007id-2s
	for xen-devel@lists.xen.org; Thu, 06 Sep 2012 12:31:41 +0000
Received: from [85.158.143.99:37613] by server-2.bemta-4.messagelabs.com id
	DF/8B-21239-CA798405; Thu, 06 Sep 2012 12:31:40 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-7.tower-216.messagelabs.com!1346934699!25533974!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16085 invoked from network); 6 Sep 2012 12:31:39 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-7.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 6 Sep 2012 12:31:39 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1T9bFB-000FLS-6g; Thu, 06 Sep 2012 12:31:37 +0000
Date: Thu, 6 Sep 2012 13:31:37 +0100
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <ian.campbell@citrix.com>
Message-ID: <20120906123137.GJ56463@ocelot.phlegethon.org>
References: <1346678886.32462.9.camel@zakaz.uk.xensource.com>
	<1346679056-8108-10-git-send-email-ian.campbell@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1346679056-8108-10-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 10/16] arm: print a message if multiple
	banks of memory are present.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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:30 +0000 on 03 Sep (1346679050), 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 Sep 06 12:35:36 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 2012 12:35: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 1T9bIr-0007we-WC; Thu, 06 Sep 2012 12:35: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 1T9bIq-0007wW-Aa
	for xen-devel@lists.xen.org; Thu, 06 Sep 2012 12:35:24 +0000
Received: from [85.158.143.99:7310] by server-1.bemta-4.messagelabs.com id
	C3/72-12504-B8898405; Thu, 06 Sep 2012 12:35:23 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1346934921!27997347!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM5ODQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26112 invoked from network); 6 Sep 2012 12:35:22 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-13.tower-216.messagelabs.com with SMTP;
	6 Sep 2012 12:35:22 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 06 Sep 2012 13:35:38 +0100
Message-Id: <5048B4DF0200007800099554@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 06 Sep 2012 13:36:15 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Campbell" <Ian.Campbell@citrix.com>
References: <1346665360.25864.2.camel@zakaz.uk.xensource.com>
In-Reply-To: <1346665360.25864.2.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.0 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 03.09.12 at 11:42, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> hypervisor, nice to have:
> 
>     * S3 regression(s?) reported by Ben Guthro (Ben & Jan Beulich)

So it looks like we got this nailed down (actually requiring two
fixes). Would it be intended to still get these in before the
release, or leave them for 4.3/4.2.1?

Jan

NB:  I also found an unrelated issue earlier today where a
hypercall would return success when it actually failed, but I
won't even bother sending that out if the fixes needed here
aren't to be considered, as that's clearly minor compared to
the regression here.


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

From xen-devel-bounces@lists.xen.org Thu Sep 06 12:35:36 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 2012 12:35: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 1T9bIr-0007we-WC; Thu, 06 Sep 2012 12:35: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 1T9bIq-0007wW-Aa
	for xen-devel@lists.xen.org; Thu, 06 Sep 2012 12:35:24 +0000
Received: from [85.158.143.99:7310] by server-1.bemta-4.messagelabs.com id
	C3/72-12504-B8898405; Thu, 06 Sep 2012 12:35:23 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1346934921!27997347!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM5ODQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26112 invoked from network); 6 Sep 2012 12:35:22 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-13.tower-216.messagelabs.com with SMTP;
	6 Sep 2012 12:35:22 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 06 Sep 2012 13:35:38 +0100
Message-Id: <5048B4DF0200007800099554@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 06 Sep 2012 13:36:15 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Campbell" <Ian.Campbell@citrix.com>
References: <1346665360.25864.2.camel@zakaz.uk.xensource.com>
In-Reply-To: <1346665360.25864.2.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.0 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 03.09.12 at 11:42, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> hypervisor, nice to have:
> 
>     * S3 regression(s?) reported by Ben Guthro (Ben & Jan Beulich)

So it looks like we got this nailed down (actually requiring two
fixes). Would it be intended to still get these in before the
release, or leave them for 4.3/4.2.1?

Jan

NB:  I also found an unrelated issue earlier today where a
hypercall would return success when it actually failed, but I
won't even bother sending that out if the fixes needed here
aren't to be considered, as that's clearly minor compared to
the regression here.


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

From xen-devel-bounces@lists.xen.org Thu Sep 06 12:55:29 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 2012 12:55:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9bc4-0000P0-58; Thu, 06 Sep 2012 12:55:16 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ben.guthro@gmail.com>) id 1T9bc2-0000Ob-7C
	for xen-devel@lists.xen.org; Thu, 06 Sep 2012 12:55:14 +0000
X-Env-Sender: ben.guthro@gmail.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1346936106!2194717!1
X-Originating-IP: [209.85.223.173]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
  RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22691 invoked from network); 6 Sep 2012 12:55:07 -0000
Received: from mail-ie0-f173.google.com (HELO mail-ie0-f173.google.com)
	(209.85.223.173)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Sep 2012 12:55:07 -0000
Received: by iebc10 with SMTP id c10so3601708ieb.32
	for <xen-devel@lists.xen.org>; Thu, 06 Sep 2012 05:55:05 -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=lGMFZ+RGgwYIroqcSoGFdVYBoIX1ZG7x1ILY6/Kl7VM=;
	b=Xd+PRBIDHnK5dTbnc6u8YheZSmBoTZTxGtLtrdyKp+ckyaQpJfuJEdBSifyi81VPBn
	YEg2/G1HUVm2/+ggEZ8pyyZ+cb8K6e+2YDR+Do0TXXMe2M3ZAnAs2Nd5y+pgae2nduPP
	6xHlvvSqsOBa8kqJhBPR8rFJ5zEYXiKjfsZyNOdunkYfY7neymKP1zSwm5o22z/S5KLD
	4Cn726grqEfRJ2m0HtjrvYjZJc6ILjNRRSvVlLdOlz9blt/CXI3swAOhKGqVCSvq14pz
	YpsoIBl5lddO0plJXqlFmQA6qxL8TY4OvBZcLpZP8qO8eYFUYrioO+VJRWu9tVsA5Hqi
	vZzg==
MIME-Version: 1.0
Received: by 10.50.217.227 with SMTP id pb3mr22544634igc.28.1346936105740;
	Thu, 06 Sep 2012 05:55:05 -0700 (PDT)
Received: by 10.64.28.203 with HTTP; Thu, 6 Sep 2012 05:55:05 -0700 (PDT)
In-Reply-To: <5048B4DF0200007800099554@nat28.tlf.novell.com>
References: <1346665360.25864.2.camel@zakaz.uk.xensource.com>
	<5048B4DF0200007800099554@nat28.tlf.novell.com>
Date: Thu, 6 Sep 2012 08:55:05 -0400
X-Google-Sender-Auth: XbNtIO5iZEBylb6ZBLRkgG9vizI
Message-ID: <CAOvdn6VUoFN8n-weX4Ni6-O2HivLepWfXV+JMuj7Hjc7oXN9cg@mail.gmail.com>
From: Ben Guthro <ben@guthro.net>
To: Jan Beulich <JBeulich@suse.com>
Cc: Ian Campbell <Ian.Campbell@citrix.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.2.0 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

FWIW, I ran this through 100 suspend / resume cycles successfully, on
the machine where I could only do one before.

I'm still waiting for a laptop to free up that exhibited the other S3
failure where it went to sleep, but just pulsed the power LED when
asked to wake up.
I'm cautiously hopeful this fixes that problem, as well.

Ben

On Thu, Sep 6, 2012 at 8:36 AM, Jan Beulich <JBeulich@suse.com> wrote:
>>>> On 03.09.12 at 11:42, Ian Campbell <Ian.Campbell@citrix.com> wrote:
>> hypervisor, nice to have:
>>
>>     * S3 regression(s?) reported by Ben Guthro (Ben & Jan Beulich)
>
> So it looks like we got this nailed down (actually requiring two
> fixes). Would it be intended to still get these in before the
> release, or leave them for 4.3/4.2.1?
>
> Jan
>
> NB:  I also found an unrelated issue earlier today where a
> hypercall would return success when it actually failed, but I
> won't even bother sending that out if the fixes needed here
> aren't to be considered, as that's clearly minor compared to
> the regression here.
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Sep 06 12:55:29 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 2012 12:55:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9bc4-0000P0-58; Thu, 06 Sep 2012 12:55:16 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ben.guthro@gmail.com>) id 1T9bc2-0000Ob-7C
	for xen-devel@lists.xen.org; Thu, 06 Sep 2012 12:55:14 +0000
X-Env-Sender: ben.guthro@gmail.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1346936106!2194717!1
X-Originating-IP: [209.85.223.173]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
  RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22691 invoked from network); 6 Sep 2012 12:55:07 -0000
Received: from mail-ie0-f173.google.com (HELO mail-ie0-f173.google.com)
	(209.85.223.173)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Sep 2012 12:55:07 -0000
Received: by iebc10 with SMTP id c10so3601708ieb.32
	for <xen-devel@lists.xen.org>; Thu, 06 Sep 2012 05:55:05 -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=lGMFZ+RGgwYIroqcSoGFdVYBoIX1ZG7x1ILY6/Kl7VM=;
	b=Xd+PRBIDHnK5dTbnc6u8YheZSmBoTZTxGtLtrdyKp+ckyaQpJfuJEdBSifyi81VPBn
	YEg2/G1HUVm2/+ggEZ8pyyZ+cb8K6e+2YDR+Do0TXXMe2M3ZAnAs2Nd5y+pgae2nduPP
	6xHlvvSqsOBa8kqJhBPR8rFJ5zEYXiKjfsZyNOdunkYfY7neymKP1zSwm5o22z/S5KLD
	4Cn726grqEfRJ2m0HtjrvYjZJc6ILjNRRSvVlLdOlz9blt/CXI3swAOhKGqVCSvq14pz
	YpsoIBl5lddO0plJXqlFmQA6qxL8TY4OvBZcLpZP8qO8eYFUYrioO+VJRWu9tVsA5Hqi
	vZzg==
MIME-Version: 1.0
Received: by 10.50.217.227 with SMTP id pb3mr22544634igc.28.1346936105740;
	Thu, 06 Sep 2012 05:55:05 -0700 (PDT)
Received: by 10.64.28.203 with HTTP; Thu, 6 Sep 2012 05:55:05 -0700 (PDT)
In-Reply-To: <5048B4DF0200007800099554@nat28.tlf.novell.com>
References: <1346665360.25864.2.camel@zakaz.uk.xensource.com>
	<5048B4DF0200007800099554@nat28.tlf.novell.com>
Date: Thu, 6 Sep 2012 08:55:05 -0400
X-Google-Sender-Auth: XbNtIO5iZEBylb6ZBLRkgG9vizI
Message-ID: <CAOvdn6VUoFN8n-weX4Ni6-O2HivLepWfXV+JMuj7Hjc7oXN9cg@mail.gmail.com>
From: Ben Guthro <ben@guthro.net>
To: Jan Beulich <JBeulich@suse.com>
Cc: Ian Campbell <Ian.Campbell@citrix.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.2.0 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

FWIW, I ran this through 100 suspend / resume cycles successfully, on
the machine where I could only do one before.

I'm still waiting for a laptop to free up that exhibited the other S3
failure where it went to sleep, but just pulsed the power LED when
asked to wake up.
I'm cautiously hopeful this fixes that problem, as well.

Ben

On Thu, Sep 6, 2012 at 8:36 AM, Jan Beulich <JBeulich@suse.com> wrote:
>>>> On 03.09.12 at 11:42, Ian Campbell <Ian.Campbell@citrix.com> wrote:
>> hypervisor, nice to have:
>>
>>     * S3 regression(s?) reported by Ben Guthro (Ben & Jan Beulich)
>
> So it looks like we got this nailed down (actually requiring two
> fixes). Would it be intended to still get these in before the
> release, or leave them for 4.3/4.2.1?
>
> Jan
>
> NB:  I also found an unrelated issue earlier today where a
> hypercall would return success when it actually failed, but I
> won't even bother sending that out if the fixes needed here
> aren't to be considered, as that's clearly minor compared to
> the regression here.
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Sep 06 13:16:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 2012 13:16:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9bwJ-0001HD-9i; Thu, 06 Sep 2012 13:16:11 +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 1T9bwH-0001GZ-MJ
	for xen-devel@lists.xen.org; Thu, 06 Sep 2012 13:16:09 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1346937313!4704529!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzMxMzIz\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15680 invoked from network); 6 Sep 2012 13:15:14 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-10.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 6 Sep 2012 13:15:14 -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 q86DFB60023639
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 6 Sep 2012 13:15:12 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q86DFBwK029864
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 6 Sep 2012 13:15:11 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
	q86DF8YK002278; Thu, 6 Sep 2012 08:15:10 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 06 Sep 2012 06:15:08 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 91D3C402E4; Thu,  6 Sep 2012 09:04:36 -0400 (EDT)
Date: Thu, 6 Sep 2012 09:04:36 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20120906130436.GA22927@phenom.dumpdata.com>
References: <504762B50200007800098D92@nat28.tlf.novell.com>
	<ece4f196-e34e-47f5-869f-9994503e4c18@default>
	<5048A1310200007800099471@nat28.tlf.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <5048A1310200007800099471@nat28.tlf.novell.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: Kurt Hackel <kurt.hackel@oracle.com>,
	Dan Magenheimer <dan.magenheimer@oracle.com>,
	Zhenzhong Duan <zhenzhong.duan@oracle.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 00/11] various tmem adjustments (mostly
	XSA-15 related)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Sep 06, 2012 at 12:12:17PM +0100, Jan Beulich wrote:
> >>> On 05.09.12 at 18:37, Dan Magenheimer <dan.magenheimer@oracle.com> wrote:
> > Keir or Jan (or whoever is applying the patches), a heads-up would
> > be appreciated to me and this cc list when this patchset is applied
> > to -staging or any other Xen tree.
> 
> It was decided to put them in only after branching off 4.2, so
> if all goes well early next week. Backporting to 4.2 would be
> considered mostly based upon the whole feature becoming
> fully functional again.

That is the goal of course. I am reading this as saying that you want
to wait until we have all of the patches to make it work right - and
then backport in Xen 4.2-stable all at once.

And I believe Dan is narrowing the last of the xm save/restore
ones.

> 
> Jan

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

From xen-devel-bounces@lists.xen.org Thu Sep 06 13:16:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 2012 13:16:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9bwF-0001Ge-P2; Thu, 06 Sep 2012 13:16:07 +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 1T9bwE-0001GY-IJ
	for xen-devel@lists.xen.org; Thu, 06 Sep 2012 13:16:06 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1346937358!8458172!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzMxMzIz\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32318 invoked from network); 6 Sep 2012 13:15:59 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-16.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 6 Sep 2012 13:15:59 -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 q86DFpTh024218
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 6 Sep 2012 13:15:52 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q86DFoSA001108
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 6 Sep 2012 13:15:50 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
	q86DFos5005114; Thu, 6 Sep 2012 08:15:50 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 06 Sep 2012 06:15:50 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 61384402E4; Thu,  6 Sep 2012 09:05:18 -0400 (EDT)
Date: Thu, 6 Sep 2012 09:05:18 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Tobias Geiger <tobias.geiger@vido.info>
Message-ID: <20120906130518.GB22927@phenom.dumpdata.com>
References: <1B4B44D9196EFF41AE41FDA404FC0A101881CE@SHSMSX101.ccr.corp.intel.com>
	<20120905185412.GA27077@phenom.dumpdata.com>
	<f74e17a2c22339a3eb0439a03bef10b1@vido.info>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <f74e17a2c22339a3eb0439a03bef10b1@vido.info>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: Konrad Rzeszutek Wilk <konrad@kernel.org>, "Ren,
	Yongjie" <yongjie.ren@intel.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Regression in kernel 3.5 as Dom0 regarding 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, Sep 06, 2012 at 01:28:00PM +0200, Tobias Geiger wrote:
> Hello Konrad,
> 
> the patch helps regarding the USB-PCIController-Passthrough - this
> works now in DomU.

Good. Can I put your Reported and Tested by tag.
> 
> but i still get the Dom0 crash when shutting down DomU:

That is a different issue. Take a look at 
" dom0 linux 3.6.0-rc4, crash due to ballooning althoug dom0_mem=X, max:X set   "
thread please.


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

From xen-devel-bounces@lists.xen.org Thu Sep 06 13:16:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 2012 13:16:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9bwJ-0001HD-9i; Thu, 06 Sep 2012 13:16:11 +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 1T9bwH-0001GZ-MJ
	for xen-devel@lists.xen.org; Thu, 06 Sep 2012 13:16:09 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1346937313!4704529!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzMxMzIz\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15680 invoked from network); 6 Sep 2012 13:15:14 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-10.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 6 Sep 2012 13:15:14 -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 q86DFB60023639
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 6 Sep 2012 13:15:12 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q86DFBwK029864
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 6 Sep 2012 13:15:11 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
	q86DF8YK002278; Thu, 6 Sep 2012 08:15:10 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 06 Sep 2012 06:15:08 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 91D3C402E4; Thu,  6 Sep 2012 09:04:36 -0400 (EDT)
Date: Thu, 6 Sep 2012 09:04:36 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20120906130436.GA22927@phenom.dumpdata.com>
References: <504762B50200007800098D92@nat28.tlf.novell.com>
	<ece4f196-e34e-47f5-869f-9994503e4c18@default>
	<5048A1310200007800099471@nat28.tlf.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <5048A1310200007800099471@nat28.tlf.novell.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: Kurt Hackel <kurt.hackel@oracle.com>,
	Dan Magenheimer <dan.magenheimer@oracle.com>,
	Zhenzhong Duan <zhenzhong.duan@oracle.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 00/11] various tmem adjustments (mostly
	XSA-15 related)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Sep 06, 2012 at 12:12:17PM +0100, Jan Beulich wrote:
> >>> On 05.09.12 at 18:37, Dan Magenheimer <dan.magenheimer@oracle.com> wrote:
> > Keir or Jan (or whoever is applying the patches), a heads-up would
> > be appreciated to me and this cc list when this patchset is applied
> > to -staging or any other Xen tree.
> 
> It was decided to put them in only after branching off 4.2, so
> if all goes well early next week. Backporting to 4.2 would be
> considered mostly based upon the whole feature becoming
> fully functional again.

That is the goal of course. I am reading this as saying that you want
to wait until we have all of the patches to make it work right - and
then backport in Xen 4.2-stable all at once.

And I believe Dan is narrowing the last of the xm save/restore
ones.

> 
> Jan

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

From xen-devel-bounces@lists.xen.org Thu Sep 06 13:16:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 2012 13:16:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9bwF-0001Ge-P2; Thu, 06 Sep 2012 13:16:07 +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 1T9bwE-0001GY-IJ
	for xen-devel@lists.xen.org; Thu, 06 Sep 2012 13:16:06 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1346937358!8458172!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzMxMzIz\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32318 invoked from network); 6 Sep 2012 13:15:59 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-16.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 6 Sep 2012 13:15:59 -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 q86DFpTh024218
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 6 Sep 2012 13:15:52 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q86DFoSA001108
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 6 Sep 2012 13:15:50 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
	q86DFos5005114; Thu, 6 Sep 2012 08:15:50 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 06 Sep 2012 06:15:50 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 61384402E4; Thu,  6 Sep 2012 09:05:18 -0400 (EDT)
Date: Thu, 6 Sep 2012 09:05:18 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Tobias Geiger <tobias.geiger@vido.info>
Message-ID: <20120906130518.GB22927@phenom.dumpdata.com>
References: <1B4B44D9196EFF41AE41FDA404FC0A101881CE@SHSMSX101.ccr.corp.intel.com>
	<20120905185412.GA27077@phenom.dumpdata.com>
	<f74e17a2c22339a3eb0439a03bef10b1@vido.info>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <f74e17a2c22339a3eb0439a03bef10b1@vido.info>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: Konrad Rzeszutek Wilk <konrad@kernel.org>, "Ren,
	Yongjie" <yongjie.ren@intel.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Regression in kernel 3.5 as Dom0 regarding 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, Sep 06, 2012 at 01:28:00PM +0200, Tobias Geiger wrote:
> Hello Konrad,
> 
> the patch helps regarding the USB-PCIController-Passthrough - this
> works now in DomU.

Good. Can I put your Reported and Tested by tag.
> 
> but i still get the Dom0 crash when shutting down DomU:

That is a different issue. Take a look at 
" dom0 linux 3.6.0-rc4, crash due to ballooning althoug dom0_mem=X, max:X set   "
thread please.


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

From xen-devel-bounces@lists.xen.org Thu Sep 06 13:16:52 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 2012 13:16:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9bwm-0001Kb-N7; Thu, 06 Sep 2012 13:16:40 +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 1T9bwl-0001KI-EH
	for xen-devel@lists.xen.org; Thu, 06 Sep 2012 13:16:39 +0000
Received: from [85.158.139.83:49717] by server-9.bemta-5.messagelabs.com id
	FA/A7-20529-632A8405; Thu, 06 Sep 2012 13:16:38 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1346937396!28937938!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzMxMzIz\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10554 invoked from network); 6 Sep 2012 13:16:38 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-3.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 6 Sep 2012 13:16:38 -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 q86DGWOq024978
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 6 Sep 2012 13:16:33 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
	q86DGV02016312
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 6 Sep 2012 13:16:32 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
	q86DGVD7003307; Thu, 6 Sep 2012 08:16:31 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 06 Sep 2012 06:16:31 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 8D292402E4; Thu,  6 Sep 2012 09:05:59 -0400 (EDT)
Date: Thu, 6 Sep 2012 09:05:59 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Ben Guthro <ben@guthro.net>
Message-ID: <20120906130559.GC22927@phenom.dumpdata.com>
References: <502BB8FD02000078000951E0@nat28.tlf.novell.com>
	<CAOvdn6VD6bp13F-tvYdkBsj4hkhE7PTGZrapndtdHrDKeZqccg@mail.gmail.com>
	<502CCC0002000078000955C4@nat28.tlf.novell.com>
	<CAOvdn6VEuX7R2_wz74ZvCxMjC-=YUir9kP5sdxEVaKVspRUd_w@mail.gmail.com>
	<502CF0A8020000780009574E@nat28.tlf.novell.com>
	<CAOvdn6VsZvn_1TCWYeuyY5YuTcP8=miK2KwE4583nsj6Qjb_vg@mail.gmail.com>
	<504494FB0200007800098398@nat28.tlf.novell.com>
	<CAOvdn6UT13qvWbMyfZkWND03RoVKVSgb6wW4yqTUpuBYEX01Dg@mail.gmail.com>
	<5048958D02000078000993EB@nat28.tlf.novell.com>
	<CAOvdn6WrNK1Jn_Y_P7C3AwX6ApVcgzacLA_x-u=xBQtebnuPxA@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAOvdn6WrNK1Jn_Y_P7C3AwX6ApVcgzacLA_x-u=xBQtebnuPxA@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: Thomas Goetz <thomas.goetz@citrix.com>, john.baboval@citrix.com,
	Jan Beulich <JBeulich@suse.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen4.2 S3 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 Thu, Sep 06, 2012 at 07:48:26AM -0400, Ben Guthro wrote:
> Fantastic!
> 
> Initial tests are very good, with this dma_msi_ack modification.
> 
> I've been able to get past the ahci stall, and run through ~10 suspend
> / resume cycles with this fix.
> Additional tests are warranted, and I'll run through an automated
> sleep / wake script I have to make sure this fix holds over time.

How are you automating this? (/me imagines some robotic arm pressing
the power button every couple of minutes).

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

From xen-devel-bounces@lists.xen.org Thu Sep 06 13:16:52 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 2012 13:16:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9bwm-0001Kb-N7; Thu, 06 Sep 2012 13:16:40 +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 1T9bwl-0001KI-EH
	for xen-devel@lists.xen.org; Thu, 06 Sep 2012 13:16:39 +0000
Received: from [85.158.139.83:49717] by server-9.bemta-5.messagelabs.com id
	FA/A7-20529-632A8405; Thu, 06 Sep 2012 13:16:38 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1346937396!28937938!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzMxMzIz\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10554 invoked from network); 6 Sep 2012 13:16:38 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-3.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 6 Sep 2012 13:16:38 -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 q86DGWOq024978
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 6 Sep 2012 13:16:33 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
	q86DGV02016312
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 6 Sep 2012 13:16:32 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
	q86DGVD7003307; Thu, 6 Sep 2012 08:16:31 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 06 Sep 2012 06:16:31 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 8D292402E4; Thu,  6 Sep 2012 09:05:59 -0400 (EDT)
Date: Thu, 6 Sep 2012 09:05:59 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Ben Guthro <ben@guthro.net>
Message-ID: <20120906130559.GC22927@phenom.dumpdata.com>
References: <502BB8FD02000078000951E0@nat28.tlf.novell.com>
	<CAOvdn6VD6bp13F-tvYdkBsj4hkhE7PTGZrapndtdHrDKeZqccg@mail.gmail.com>
	<502CCC0002000078000955C4@nat28.tlf.novell.com>
	<CAOvdn6VEuX7R2_wz74ZvCxMjC-=YUir9kP5sdxEVaKVspRUd_w@mail.gmail.com>
	<502CF0A8020000780009574E@nat28.tlf.novell.com>
	<CAOvdn6VsZvn_1TCWYeuyY5YuTcP8=miK2KwE4583nsj6Qjb_vg@mail.gmail.com>
	<504494FB0200007800098398@nat28.tlf.novell.com>
	<CAOvdn6UT13qvWbMyfZkWND03RoVKVSgb6wW4yqTUpuBYEX01Dg@mail.gmail.com>
	<5048958D02000078000993EB@nat28.tlf.novell.com>
	<CAOvdn6WrNK1Jn_Y_P7C3AwX6ApVcgzacLA_x-u=xBQtebnuPxA@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAOvdn6WrNK1Jn_Y_P7C3AwX6ApVcgzacLA_x-u=xBQtebnuPxA@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: Thomas Goetz <thomas.goetz@citrix.com>, john.baboval@citrix.com,
	Jan Beulich <JBeulich@suse.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen4.2 S3 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 Thu, Sep 06, 2012 at 07:48:26AM -0400, Ben Guthro wrote:
> Fantastic!
> 
> Initial tests are very good, with this dma_msi_ack modification.
> 
> I've been able to get past the ahci stall, and run through ~10 suspend
> / resume cycles with this fix.
> Additional tests are warranted, and I'll run through an automated
> sleep / wake script I have to make sure this fix holds over time.

How are you automating this? (/me imagines some robotic arm pressing
the power button every couple of minutes).

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

From xen-devel-bounces@lists.xen.org Thu Sep 06 13:18:50 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 2012 13: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 1T9byh-0001Yb-A4; Thu, 06 Sep 2012 13:18:39 +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 1T9byf-0001YK-E6
	for xen-devel@lists.xen.org; Thu, 06 Sep 2012 13:18:37 +0000
Received: from [85.158.139.83:47603] by server-12.bemta-5.messagelabs.com id
	51/A6-18300-CA2A8405; Thu, 06 Sep 2012 13:18:36 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-10.tower-182.messagelabs.com!1346937515!29239876!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA1MDQ1MDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3419 invoked from network); 6 Sep 2012 13:18:36 -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; 6 Sep 2012 13:18:36 -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 BA98B1735;
	Thu,  6 Sep 2012 16:18:34 +0300 (EEST)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id 3798A2005D; Thu,  6 Sep 2012 16:18:34 +0300 (EEST)
Date: Thu, 6 Sep 2012 16:18:34 +0300
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120906131834.GV8912@reaktio.net>
References: <201208281225.q7SCP1WO017490@wind.enjellic.com>
	<1346226868.4847.21.camel@dagon.hellion.org.uk>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1346226868.4847.21.camel@dagon.hellion.org.uk>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: "greg@enjellic.com" <greg@enjellic.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] XEN 4.1.3 blktap2 patches.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hello,

On Wed, Aug 29, 2012 at 08:54:28AM +0100, Ian Campbell wrote:
> On Tue, 2012-08-28 at 13:25 +0100, Dr. Greg Wettstein wrote:
> > Good morning, hope the day is going well for everyone.
> > 
> > The patches to fix the blktap2 issues which result in orphaned
> > tapdisk2 processes and the transitory deadlock on guest shutdown
> > didn't make it into the 4.1.3 release.  Updated patches to address
> > these problems are available at the following location:
> > 
> > 	ftp://ftp.enjellic.com/pub/xen/xen-4.1.3.blktap1.patch
> > 	ftp://ftp.enjellic.com/pub/xen/xen-4.1.3.blktap2.patch
> > 
> > The patches are designed to be applied in order and have been verified
> > to work against the 4.1.3 release.
> 
> Please can you post these patches as emails with a changelog and a
> signed-off-by. You should also CC Ian Jackson since he is the one who
> does the tools backports.
> 

Added Ian Jackson to CC list..


> The changelog should be clear about the backport status. IIRC one of
> these is a backport from unstable (so the changelog should say of which
> commit and preserve the original S-o-b) and the other is a
> reimplementation since too much has changed in unstable so there is no
> plausible backport (and the changelog should mention this).
> 
> Ideally these mails would be threaded with subjects "[PATCH 1/2] ..."
> and "[PATCH 2/2] ..." so that it is obvious that there is a sequence to
> them. A tool such as hg email will do this for you.
> http://wiki.xen.org/wiki/Submitting_Xen_Patches has some hints on how to
> use it.
> 
> If nothing has changed since the previous posting it may be sufficient
> to reply to that previous postings with a "ping" message and CC Ian
> there.
> 

So is repost needed here? 

-- Pasi


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

From xen-devel-bounces@lists.xen.org Thu Sep 06 13:18:50 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 2012 13: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 1T9byh-0001Yb-A4; Thu, 06 Sep 2012 13:18:39 +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 1T9byf-0001YK-E6
	for xen-devel@lists.xen.org; Thu, 06 Sep 2012 13:18:37 +0000
Received: from [85.158.139.83:47603] by server-12.bemta-5.messagelabs.com id
	51/A6-18300-CA2A8405; Thu, 06 Sep 2012 13:18:36 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-10.tower-182.messagelabs.com!1346937515!29239876!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA1MDQ1MDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3419 invoked from network); 6 Sep 2012 13:18:36 -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; 6 Sep 2012 13:18:36 -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 BA98B1735;
	Thu,  6 Sep 2012 16:18:34 +0300 (EEST)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id 3798A2005D; Thu,  6 Sep 2012 16:18:34 +0300 (EEST)
Date: Thu, 6 Sep 2012 16:18:34 +0300
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120906131834.GV8912@reaktio.net>
References: <201208281225.q7SCP1WO017490@wind.enjellic.com>
	<1346226868.4847.21.camel@dagon.hellion.org.uk>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1346226868.4847.21.camel@dagon.hellion.org.uk>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: "greg@enjellic.com" <greg@enjellic.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] XEN 4.1.3 blktap2 patches.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hello,

On Wed, Aug 29, 2012 at 08:54:28AM +0100, Ian Campbell wrote:
> On Tue, 2012-08-28 at 13:25 +0100, Dr. Greg Wettstein wrote:
> > Good morning, hope the day is going well for everyone.
> > 
> > The patches to fix the blktap2 issues which result in orphaned
> > tapdisk2 processes and the transitory deadlock on guest shutdown
> > didn't make it into the 4.1.3 release.  Updated patches to address
> > these problems are available at the following location:
> > 
> > 	ftp://ftp.enjellic.com/pub/xen/xen-4.1.3.blktap1.patch
> > 	ftp://ftp.enjellic.com/pub/xen/xen-4.1.3.blktap2.patch
> > 
> > The patches are designed to be applied in order and have been verified
> > to work against the 4.1.3 release.
> 
> Please can you post these patches as emails with a changelog and a
> signed-off-by. You should also CC Ian Jackson since he is the one who
> does the tools backports.
> 

Added Ian Jackson to CC list..


> The changelog should be clear about the backport status. IIRC one of
> these is a backport from unstable (so the changelog should say of which
> commit and preserve the original S-o-b) and the other is a
> reimplementation since too much has changed in unstable so there is no
> plausible backport (and the changelog should mention this).
> 
> Ideally these mails would be threaded with subjects "[PATCH 1/2] ..."
> and "[PATCH 2/2] ..." so that it is obvious that there is a sequence to
> them. A tool such as hg email will do this for you.
> http://wiki.xen.org/wiki/Submitting_Xen_Patches has some hints on how to
> use it.
> 
> If nothing has changed since the previous posting it may be sufficient
> to reply to that previous postings with a "ping" message and CC Ian
> there.
> 

So is repost needed here? 

-- Pasi


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

From xen-devel-bounces@lists.xen.org Thu Sep 06 13:25:10 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 2012 13:25:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9c4n-0001ux-HL; Thu, 06 Sep 2012 13:24:57 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <tobias.geiger@vido.info>) id 1T9c4m-0001um-4z
	for xen-devel@lists.xen.org; Thu, 06 Sep 2012 13:24:56 +0000
Received: from [85.158.138.51:14146] by server-10.bemta-3.messagelabs.com id
	3F/1F-10411-724A8405; Thu, 06 Sep 2012 13:24:55 +0000
X-Env-Sender: tobias.geiger@vido.info
X-Msg-Ref: server-12.tower-174.messagelabs.com!1346937894!21120681!1
X-Originating-IP: [78.47.43.170]
X-SpamReason: No, hits=0.0 required=7.0 tests=SUBJECT_EXCESS_QP,
	UNPARSEABLE_RELAY
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6209 invoked from network); 6 Sep 2012 13:24:54 -0000
Received: from mail.vido.info (HELO mail.vido.info) (78.47.43.170)
	by server-12.tower-174.messagelabs.com with SMTP;
	6 Sep 2012 13:24:54 -0000
Received: from localhost (ip6-localhost [127.0.0.1])
	by mail.vido.info (Postfix) with ESMTP id 9EA21D34290;
	Thu,  6 Sep 2012 15:24:54 +0200 (CEST)
X-Virus-Scanned: by amavis at mail.vido.info
Received: from mail.vido.info ([127.0.0.1])
	by localhost (mail.vido.info [127.0.0.1]) (amavisd-new, port 10024)
	with LMTP id CQmbjWFCts4n; Thu,  6 Sep 2012 15:24:49 +0200 (CEST)
Received: from www.vido.info (www.vido.info [78.47.43.171])
	by mail.vido.info (Postfix) with ESMTP id DE39BD3428D;
	Thu,  6 Sep 2012 15:24:48 +0200 (CEST)
Received: from C8o34cRifU2E6dNCAPdZyzlI+Co1mbl8ExmzTBwnQch+fVJZasFlmQ==
	(Uf/G668H83e+jiSJUIdC8dO7VS+9CAZL) by www.vido.info
	with HTTP (HTTP/1.1 POST); Thu, 06 Sep 2012 15:24:48 +0200
MIME-Version: 1.0
Date: Thu, 06 Sep 2012 15:24:48 +0200
From: Tobias Geiger <tobias.geiger@vido.info>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
In-Reply-To: <20120906130518.GB22927@phenom.dumpdata.com>
References: <1B4B44D9196EFF41AE41FDA404FC0A101881CE@SHSMSX101.ccr.corp.intel.com>
	<20120905185412.GA27077@phenom.dumpdata.com>
	<f74e17a2c22339a3eb0439a03bef10b1@vido.info>
	<20120906130518.GB22927@phenom.dumpdata.com>
Message-ID: <acef36a96927049386abf57417294c5d@vido.info>
X-Sender: tobias.geiger@vido.info
User-Agent: Roundcube Webmail
Cc: Konrad Rzeszutek Wilk <konrad@kernel.org>, "Ren,
	Yongjie" <yongjie.ren@intel.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel]
 =?utf-8?q?Regression_in_kernel_3=2E5_as_Dom0_regardin?=
 =?utf-8?q?g_PCI_Passthrough=3F!?=
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
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 06.09.2012 15:05, schrieb Konrad Rzeszutek Wilk:
> On Thu, Sep 06, 2012 at 01:28:00PM +0200, Tobias Geiger wrote:
>> Hello Konrad,
>>
>> the patch helps regarding the USB-PCIController-Passthrough - this
>> works now in DomU.
>
> Good. Can I put your Reported and Tested by tag.

Of course. thanks for the fix!

>>
>> but i still get the Dom0 crash when shutting down DomU:
>
> That is a different issue. Take a look at
> " dom0 linux 3.6.0-rc4, crash due to ballooning althoug dom0_mem=X,
> max:X set   "
> thread please.

ok will do!

Greetings
Tobias


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

From xen-devel-bounces@lists.xen.org Thu Sep 06 13:25:10 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 2012 13:25:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9c4n-0001ux-HL; Thu, 06 Sep 2012 13:24:57 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <tobias.geiger@vido.info>) id 1T9c4m-0001um-4z
	for xen-devel@lists.xen.org; Thu, 06 Sep 2012 13:24:56 +0000
Received: from [85.158.138.51:14146] by server-10.bemta-3.messagelabs.com id
	3F/1F-10411-724A8405; Thu, 06 Sep 2012 13:24:55 +0000
X-Env-Sender: tobias.geiger@vido.info
X-Msg-Ref: server-12.tower-174.messagelabs.com!1346937894!21120681!1
X-Originating-IP: [78.47.43.170]
X-SpamReason: No, hits=0.0 required=7.0 tests=SUBJECT_EXCESS_QP,
	UNPARSEABLE_RELAY
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6209 invoked from network); 6 Sep 2012 13:24:54 -0000
Received: from mail.vido.info (HELO mail.vido.info) (78.47.43.170)
	by server-12.tower-174.messagelabs.com with SMTP;
	6 Sep 2012 13:24:54 -0000
Received: from localhost (ip6-localhost [127.0.0.1])
	by mail.vido.info (Postfix) with ESMTP id 9EA21D34290;
	Thu,  6 Sep 2012 15:24:54 +0200 (CEST)
X-Virus-Scanned: by amavis at mail.vido.info
Received: from mail.vido.info ([127.0.0.1])
	by localhost (mail.vido.info [127.0.0.1]) (amavisd-new, port 10024)
	with LMTP id CQmbjWFCts4n; Thu,  6 Sep 2012 15:24:49 +0200 (CEST)
Received: from www.vido.info (www.vido.info [78.47.43.171])
	by mail.vido.info (Postfix) with ESMTP id DE39BD3428D;
	Thu,  6 Sep 2012 15:24:48 +0200 (CEST)
Received: from C8o34cRifU2E6dNCAPdZyzlI+Co1mbl8ExmzTBwnQch+fVJZasFlmQ==
	(Uf/G668H83e+jiSJUIdC8dO7VS+9CAZL) by www.vido.info
	with HTTP (HTTP/1.1 POST); Thu, 06 Sep 2012 15:24:48 +0200
MIME-Version: 1.0
Date: Thu, 06 Sep 2012 15:24:48 +0200
From: Tobias Geiger <tobias.geiger@vido.info>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
In-Reply-To: <20120906130518.GB22927@phenom.dumpdata.com>
References: <1B4B44D9196EFF41AE41FDA404FC0A101881CE@SHSMSX101.ccr.corp.intel.com>
	<20120905185412.GA27077@phenom.dumpdata.com>
	<f74e17a2c22339a3eb0439a03bef10b1@vido.info>
	<20120906130518.GB22927@phenom.dumpdata.com>
Message-ID: <acef36a96927049386abf57417294c5d@vido.info>
X-Sender: tobias.geiger@vido.info
User-Agent: Roundcube Webmail
Cc: Konrad Rzeszutek Wilk <konrad@kernel.org>, "Ren,
	Yongjie" <yongjie.ren@intel.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel]
 =?utf-8?q?Regression_in_kernel_3=2E5_as_Dom0_regardin?=
 =?utf-8?q?g_PCI_Passthrough=3F!?=
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
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 06.09.2012 15:05, schrieb Konrad Rzeszutek Wilk:
> On Thu, Sep 06, 2012 at 01:28:00PM +0200, Tobias Geiger wrote:
>> Hello Konrad,
>>
>> the patch helps regarding the USB-PCIController-Passthrough - this
>> works now in DomU.
>
> Good. Can I put your Reported and Tested by tag.

Of course. thanks for the fix!

>>
>> but i still get the Dom0 crash when shutting down DomU:
>
> That is a different issue. Take a look at
> " dom0 linux 3.6.0-rc4, crash due to ballooning althoug dom0_mem=X,
> max:X set   "
> thread please.

ok will do!

Greetings
Tobias


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

From xen-devel-bounces@lists.xen.org Thu Sep 06 13:27:45 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 2012 13:27: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 1T9c7M-0002IO-43; Thu, 06 Sep 2012 13:27:36 +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 1T9c7K-0002IB-IJ
	for xen-devel@lists.xen.org; Thu, 06 Sep 2012 13:27:34 +0000
Received: from [85.158.143.99:58193] by server-2.bemta-4.messagelabs.com id
	B6/F8-21239-5C4A8405; Thu, 06 Sep 2012 13:27:33 +0000
X-Env-Sender: ben.guthro@gmail.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1346938051!17702964!1
X-Originating-IP: [209.85.210.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10879 invoked from network); 6 Sep 2012 13:27:32 -0000
Received: from mail-iy0-f173.google.com (HELO mail-iy0-f173.google.com)
	(209.85.210.173)
	by server-16.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Sep 2012 13:27:32 -0000
Received: by iakx26 with SMTP id x26so2495019iak.32
	for <xen-devel@lists.xen.org>; Thu, 06 Sep 2012 06:27:31 -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=8MtAiweYrqJM6mi+c0XfF2buGl8jHy5JYttUkhzfVcg=;
	b=c2y5zbC7HZYJL/eiyA2cDxbch26s9INPTPU6R0LosIptixjNhoe4mrW/YXCmqvpy2N
	q4rnDpVCIS5TwglcUDm1+OruOkEYF5XhWxHNEU0JrvWTH7Gl09YmNziKFiOVmn71e+k9
	/DcD8aeXpI8YU985zFcClmxg1VVNwcmOSIj024LQmsxtjRSa1HacscotI5kwStSQbUFj
	y4iYC5Pd/bMiDUVVJrdjMMeRBhhorKJdENjsmgPJZnTbmhpft8c0+Xq4JbzZ+XuQZBdi
	B0LvvN6sYZoXY+Kg04at0/nEDzlj9R+qxbz/TeJIUi7HolcgHguL6Gvn08gYZAAbdaqp
	JCfg==
MIME-Version: 1.0
Received: by 10.43.9.3 with SMTP id ou3mr2365895icb.14.1346938051231; Thu, 06
	Sep 2012 06:27:31 -0700 (PDT)
Received: by 10.64.28.203 with HTTP; Thu, 6 Sep 2012 06:27:31 -0700 (PDT)
In-Reply-To: <20120906130559.GC22927@phenom.dumpdata.com>
References: <502BB8FD02000078000951E0@nat28.tlf.novell.com>
	<CAOvdn6VD6bp13F-tvYdkBsj4hkhE7PTGZrapndtdHrDKeZqccg@mail.gmail.com>
	<502CCC0002000078000955C4@nat28.tlf.novell.com>
	<CAOvdn6VEuX7R2_wz74ZvCxMjC-=YUir9kP5sdxEVaKVspRUd_w@mail.gmail.com>
	<502CF0A8020000780009574E@nat28.tlf.novell.com>
	<CAOvdn6VsZvn_1TCWYeuyY5YuTcP8=miK2KwE4583nsj6Qjb_vg@mail.gmail.com>
	<504494FB0200007800098398@nat28.tlf.novell.com>
	<CAOvdn6UT13qvWbMyfZkWND03RoVKVSgb6wW4yqTUpuBYEX01Dg@mail.gmail.com>
	<5048958D02000078000993EB@nat28.tlf.novell.com>
	<CAOvdn6WrNK1Jn_Y_P7C3AwX6ApVcgzacLA_x-u=xBQtebnuPxA@mail.gmail.com>
	<20120906130559.GC22927@phenom.dumpdata.com>
Date: Thu, 6 Sep 2012 09:27:31 -0400
X-Google-Sender-Auth: YLAFhbG3g00f_f3a8nRT-tsY1QA
Message-ID: <CAOvdn6XabjBqSkt7amzqw9omemNfNhJVds4Dgwf-APYAQWBwNQ@mail.gmail.com>
From: Ben Guthro <ben@guthro.net>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Content-Type: multipart/mixed; boundary=bcaec50fe0ad13fe9e04c9087459
Cc: Thomas Goetz <thomas.goetz@citrix.com>, john.baboval@citrix.com,
	Jan Beulich <JBeulich@suse.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen4.2 S3 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>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

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

We have a cycle_wakeup script (attached) that programs the RTC

This in itsself is not sufficient, due to interaction with the HPET.
We have an additional patch (see below) to deal with that.

The patch is not the cleanest solution ever, but it works...


diff -r fc9dd79fe91a xen/arch/x86/hpet.c
--- a/xen/arch/x86/hpet.c	Thu Mar 03 17:21:16 2011 -0500
+++ b/xen/arch/x86/hpet.c	Thu Mar 03 17:35:57 2011 -0500
@@ -520,13 +520,28 @@

     if ( index != RTC_REG_B )
         return;
-
+
+    /*
+     *  Wake on RTC alarm does not conflict with hpet.
+     * The HW will wake up the CPU when the RTC alarm kicks off
+     * even thought the interrupt is not routed to the APIC.
+     *
+     * In our distro, xen will always own the interrupt so
+     * that we never disable deep cstates.  We do not run
+     * dom0 apps/drivers that require RTC interrupts other
+     * than wakeup functionality.
+     */
+#if 0
     /* RTC Reg B, contain PIE/AIE/UIE */
     if ( value & (RTC_PIE | RTC_AIE | RTC_UIE ) )
     {
         cpuidle_disable_deep_cstate();
         pv_rtc_handler = NULL;
     }
+#else
+    if ( value & (RTC_PIE | RTC_UIE ) )
+	    printk("WARNING: dom0 attempting to use RTC interrupts!\n");
+#endif
 }

 void hpet_broadcast_init(void)


On Thu, Sep 6, 2012 at 9:05 AM, Konrad Rzeszutek Wilk
<konrad.wilk@oracle.com> wrote:
> On Thu, Sep 06, 2012 at 07:48:26AM -0400, Ben Guthro wrote:
>> Fantastic!
>>
>> Initial tests are very good, with this dma_msi_ack modification.
>>
>> I've been able to get past the ahci stall, and run through ~10 suspend
>> / resume cycles with this fix.
>> Additional tests are warranted, and I'll run through an automated
>> sleep / wake script I have to make sure this fix holds over time.
>
> How are you automating this? (/me imagines some robotic arm pressing
> the power button every couple of minutes).

--bcaec50fe0ad13fe9e04c9087459
Content-Type: application/octet-stream; name=cycle_wakeup
Content-Disposition: attachment; filename=cycle_wakeup
Content-Transfer-Encoding: base64
X-Attachment-Id: f_h6rw2hq90

IyEvYmluL3NoCgpwYXNzZXM9MTAwCnN1c3BlbmRfdGltZT0xNQphd2FrZV90aW1lPTMwCgpwcm9n
bmFtZT0kKGJhc2VuYW1lICQwKQoKdWV4aXQoKQp7CmNhdCA8PEVPRgpVc2FnZTogJHByb2duYW1l
IFtbLXZdIFstbF0gWy1wIDxudW0+XSBbLXMgPHNlY3M+XSBbLWEgPHNlY3M+XV0gWzxjb21tYW5k
Pl0KICAgICAgIC12ICAgICAgICAgIHZlcmJvc2UsIGVjaG8gcHJvZ2VzcyB0byBzdGRvdXQKICAg
ICAgIC1sICAgICAgICAgIGxvZyBwcm9ncmVzcyB0byBzeXNsb2cKICAgICAgIC1wICAgICAgICAg
IHNwZWNpZnkgbnVtYmVyIG9mIHBhc3NlcwogICAgICAgLXMgICAgICAgICAgdGltZSBzdGF5IGlu
IHN1c3BlbmQgaW4gc2Vjb25kcwogICAgICAgLWEgICAgICAgICAgYXdha2UgdGltZSBiZWZvcmUg
c3VzcGVuZCBpbiBzZWNvbmRzCiAgICAgICAgICAgICAgICAgICAgc3BlY2lmeWluZyAnbmV0JyBv
ciAnLTEnIHdpbGwgd2FpdCBmb3IgdGhlCiAgICAgICAgICAgICAgICAgICAgbmV0d29yayB0byBi
ZSB1cCBiZWZvcmUgcmUtc3VzcGVuZGluZwogICAgICAgPGNvbW1hbmQ+ICAgYSBzaGVsbCBjb21t
YW5kIHRvIHJ1biBmb3IgZWFjaCBwYXNzIG9mIHRoZSB0ZXN0CiAgICAgICAgICAgICAgICAgICAg
b24gcmVzdW1lIGZyb20gc3VzcGVuZC4KRU9GCn0KCiMKIyBQcm9jZXNzIGNvbW1hbmQgbGluZSBh
cmdzCiMKd2hpbGUgWyAtbiAiJDEiIF07IGRvCiAgICBjYXNlICQxIGluCgktdikJdmVyYm9zZT10
cnVlOwoJCTs7CgktbCkJdmVyYm9zZV9sb2c9dHJ1ZQoJCTs7CgktcCkJWyAkIyAtbHQgMiBdICYm
IHVleGl0CgkgICAgCXBhc3Nlcz0kMgoJCXNoaWZ0CgkJOzsKCS1zKQlbICQjIC1sdCAyIF0gJiYg
dWV4aXQKCSAgICAJc3VzcGVuZF90aW1lPSQyCgkJc2hpZnQKCQk7OwoJLWEpCVsgJCMgLWx0IDIg
XSAmJiB1ZXhpdAoJICAgIAlhd2FrZV90aW1lPSQyCgkJc2hpZnQKCQk7OwoJKikJYnJlYWsKCQk7
OwogICAgZXNhYwogICAgc2hpZnQKZG9uZQoKY21kPSIkKiIKCiMKIyBTdXBwb3J0IHJvdXRpbmVz
CiMKbG9naXQoKQp7CiAgICBpZiBbIHgiJDEiID0geCItdiIgXTsgdGhlbgoJc2hpZnQKCWVjaG8g
IiQqIgogICAgZWxpZiBbIC1uICIkdmVyYm9zZSIgXTsgdGhlbgoJZWNobyAiYGRhdGVgICQqIgog
ICAgZmkKICAgIGlmIFsgLW4gIiR2ZXJib3NlX2xvZyIgXTsgdGhlbgogICAgICAgIGVjaG8gIiRw
cm9nbmFtZTogJCoiID4gL2Rldi9rbXNnCiAgICBmaQp9CgpnZXR0aW1lKCkKewogICAgY2F0IC9z
eXMvY2xhc3MvcnRjL3J0YzAvc2luY2VfZXBvY2gKfQoKcGluZ2l0KCkKewogICAgbG9naXQgIlBp
bmdpbmcgcmVwb21hbi4iCiAgICBpPTYwCiAgICB3aGlsZSBbICRpIC1ndCAwIF07IGRvCglpZiBw
aW5nIC1jIDEgMTAuMS4xLjExID4vZGV2L251bGwgMj4mMTsgdGhlbgoJICAgIHJldHVybgoJZmkK
CXNsZWVwIDEKCWk9JCgoJGkgLSAxKSkKICAgIGRvbmUKICAgIGxvZ2l0ICJQaW5nIHRpbWVkIG91
dC4iCn0KCmRvX3N0YW5kYnkoKQp7CiAgICAjCiAgICAjIFRoZSBzdXNwZW5kIGNvZGUgdGhhdCBk
bWQgY2FsbHMsIC91c3IvbG9jYWwvYmluL3N0YW5kYnksCiAgICAjIHdpbGwgY2xlYXIgdGhlIC90
bXAvc3RhbmRieV90ZXN0IGZpbGUgd2hlbiBpdCBjb21wbGV0ZXMuCiAgICAjCiAgICB0b3VjaCAv
dG1wL3N0YW5kYnlfdGVzdAogICAgZG1kcnYgc3VzcGVuZF9wbGF0Zm9ybSAkKgogICAgd2hpbGUg
WyAtZSAvdG1wL3N0YW5kYnlfdGVzdCBdOyBkbwoJc2xlZXAgMQogICAgZG9uZQp9CgojCiMgL3Rt
cC9zdGFuZGJ5X3Rlc3QgaXMgdXNlZCB0byBwYXNzIHBhcmFtZXRlcnMgdG8gdGhlIHN0YW5kYnkg
c2NyaXB0CiMgaW4gL3Vzci9sb2NhbC9iaW4uCiMKcm0gLWYgL3RtcC9zdGFuZGJ5X3Rlc3QKCmxv
Z2l0IC12ICJSdW5uaW5nIHN1c3BlbmQgY3ljbGUgdGVzdCB3aXRoIHRoZSBmb2xsb3dpbmcgcGFy
YW1ldGVyczoiCmxvZ2l0IC12ICIgICAgcnVuIGZvciAkcGFzc2VzIHBhc3NlcyIKbG9naXQgLXYg
IiAgICBzdXNwZW5kIGZvciAkc3VzcGVuZF90aW1lIHNlY29uZHMiCmxvZ2l0IC12ICIgICAgc3Rh
eSBhd2FrZSBmb3IgJGF3YWtlX3RpbWUgc2Vjb25kcyIKCmNvdW50PTEKd2hpbGUgWyAxIF07IGRv
CgogICAgIwogICAgIyBEbyB0aGUgc3VzcGVuZAogICAgIwogICAgbG9naXQgIlN1c3BlbmRpbmcg
Zm9yICRzdXNwZW5kX3RpbWUgc2Vjb25kcywgUGFzcyAkY291bnQuIgoKICAgIHN0YXJ0PSQoZ2V0
dGltZSkKICAgIGRvX3N0YW5kYnkgLW4gLXMgJHN1c3BlbmRfdGltZSBQQVNTICRjb3VudAogICAg
ZW5kPSQoZ2V0dGltZSkKICAgIGRlbHRhPSQoKCRlbmQgLSAkc3RhcnQpKQoKICAgIGxvZ2l0ICJS
ZXN1bWVkIGluICRkZWx0YSBzZWNvbmRzLiIKCiAgICAjCiAgICAjIFNhbml0eSBjaGVjayB0aGUg
c3VzcGVuZCBkdXJhdGlvbgogICAgIwogICAgZXhwZWN0ZWQ9JCgoJHN1c3BlbmRfdGltZSArIDYw
KSkKICAgIGlmIFsgJGRlbHRhIC1ndCAkZXhwZWN0ZWQgXTsgdGhlbgoJbG9naXQgIkZBSUxVUkUs
IHN5c3RlbSBpbiBzdGFuZGJ5IGZvciB0b28gbG9uZyEiCglleGl0IDEKICAgIGZpCgogICAgIwog
ICAgIyBFeGVjdXRlIHRoZSBjb21tYW5kIHNwZWNpZmllZCBmb3IgZWFjaCBwYXNzCiAgICAjCiAg
ICBbIC1uICIkY21kIiBdICYmIGV2YWwgIiRjbWQiCgogICAgWyAkY291bnQgLWVxICRwYXNzZXMg
XSAmJiBicmVhawoKICAgICMKICAgICMgU3RheSBhd2FrZSBmb3IgdGhlIHNwZWNpZmllZCBwZXJp
b2QKICAgICMKICAgIGlmIFsgJGF3YWtlX3RpbWUgPSAibmV0IiAtbyAkYXdha2VfdGltZSAtZXEg
LTEgXTsgdGhlbgoJbG9naXQgIldhaXRpbmcgZm9yIG5ldHdvcmsgdG8gY29tZSB1cCIKCXBpbmdp
dAogICAgZWxpZiBbICRhd2FrZV90aW1lIC1ndCAwIF07IHRoZW4KCWxvZ2l0ICJXYWl0aW5nIGZv
ciAkYXdha2VfdGltZSBzZWNvbmRzLiIKCXNsZWVwICRhd2FrZV90aW1lIAogICAgZWxzZQoJbG9n
aXQgIk5vdCB3YWl0aW5nIgogICAgZmkKCiAgICBjb3VudD0kKCgkY291bnQgKyAxKSkKZG9uZQo=
--bcaec50fe0ad13fe9e04c9087459
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--bcaec50fe0ad13fe9e04c9087459--


From xen-devel-bounces@lists.xen.org Thu Sep 06 13:27:45 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 2012 13:27: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 1T9c7M-0002IO-43; Thu, 06 Sep 2012 13:27:36 +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 1T9c7K-0002IB-IJ
	for xen-devel@lists.xen.org; Thu, 06 Sep 2012 13:27:34 +0000
Received: from [85.158.143.99:58193] by server-2.bemta-4.messagelabs.com id
	B6/F8-21239-5C4A8405; Thu, 06 Sep 2012 13:27:33 +0000
X-Env-Sender: ben.guthro@gmail.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1346938051!17702964!1
X-Originating-IP: [209.85.210.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10879 invoked from network); 6 Sep 2012 13:27:32 -0000
Received: from mail-iy0-f173.google.com (HELO mail-iy0-f173.google.com)
	(209.85.210.173)
	by server-16.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Sep 2012 13:27:32 -0000
Received: by iakx26 with SMTP id x26so2495019iak.32
	for <xen-devel@lists.xen.org>; Thu, 06 Sep 2012 06:27:31 -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=8MtAiweYrqJM6mi+c0XfF2buGl8jHy5JYttUkhzfVcg=;
	b=c2y5zbC7HZYJL/eiyA2cDxbch26s9INPTPU6R0LosIptixjNhoe4mrW/YXCmqvpy2N
	q4rnDpVCIS5TwglcUDm1+OruOkEYF5XhWxHNEU0JrvWTH7Gl09YmNziKFiOVmn71e+k9
	/DcD8aeXpI8YU985zFcClmxg1VVNwcmOSIj024LQmsxtjRSa1HacscotI5kwStSQbUFj
	y4iYC5Pd/bMiDUVVJrdjMMeRBhhorKJdENjsmgPJZnTbmhpft8c0+Xq4JbzZ+XuQZBdi
	B0LvvN6sYZoXY+Kg04at0/nEDzlj9R+qxbz/TeJIUi7HolcgHguL6Gvn08gYZAAbdaqp
	JCfg==
MIME-Version: 1.0
Received: by 10.43.9.3 with SMTP id ou3mr2365895icb.14.1346938051231; Thu, 06
	Sep 2012 06:27:31 -0700 (PDT)
Received: by 10.64.28.203 with HTTP; Thu, 6 Sep 2012 06:27:31 -0700 (PDT)
In-Reply-To: <20120906130559.GC22927@phenom.dumpdata.com>
References: <502BB8FD02000078000951E0@nat28.tlf.novell.com>
	<CAOvdn6VD6bp13F-tvYdkBsj4hkhE7PTGZrapndtdHrDKeZqccg@mail.gmail.com>
	<502CCC0002000078000955C4@nat28.tlf.novell.com>
	<CAOvdn6VEuX7R2_wz74ZvCxMjC-=YUir9kP5sdxEVaKVspRUd_w@mail.gmail.com>
	<502CF0A8020000780009574E@nat28.tlf.novell.com>
	<CAOvdn6VsZvn_1TCWYeuyY5YuTcP8=miK2KwE4583nsj6Qjb_vg@mail.gmail.com>
	<504494FB0200007800098398@nat28.tlf.novell.com>
	<CAOvdn6UT13qvWbMyfZkWND03RoVKVSgb6wW4yqTUpuBYEX01Dg@mail.gmail.com>
	<5048958D02000078000993EB@nat28.tlf.novell.com>
	<CAOvdn6WrNK1Jn_Y_P7C3AwX6ApVcgzacLA_x-u=xBQtebnuPxA@mail.gmail.com>
	<20120906130559.GC22927@phenom.dumpdata.com>
Date: Thu, 6 Sep 2012 09:27:31 -0400
X-Google-Sender-Auth: YLAFhbG3g00f_f3a8nRT-tsY1QA
Message-ID: <CAOvdn6XabjBqSkt7amzqw9omemNfNhJVds4Dgwf-APYAQWBwNQ@mail.gmail.com>
From: Ben Guthro <ben@guthro.net>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Content-Type: multipart/mixed; boundary=bcaec50fe0ad13fe9e04c9087459
Cc: Thomas Goetz <thomas.goetz@citrix.com>, john.baboval@citrix.com,
	Jan Beulich <JBeulich@suse.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen4.2 S3 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>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

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

We have a cycle_wakeup script (attached) that programs the RTC

This in itsself is not sufficient, due to interaction with the HPET.
We have an additional patch (see below) to deal with that.

The patch is not the cleanest solution ever, but it works...


diff -r fc9dd79fe91a xen/arch/x86/hpet.c
--- a/xen/arch/x86/hpet.c	Thu Mar 03 17:21:16 2011 -0500
+++ b/xen/arch/x86/hpet.c	Thu Mar 03 17:35:57 2011 -0500
@@ -520,13 +520,28 @@

     if ( index != RTC_REG_B )
         return;
-
+
+    /*
+     *  Wake on RTC alarm does not conflict with hpet.
+     * The HW will wake up the CPU when the RTC alarm kicks off
+     * even thought the interrupt is not routed to the APIC.
+     *
+     * In our distro, xen will always own the interrupt so
+     * that we never disable deep cstates.  We do not run
+     * dom0 apps/drivers that require RTC interrupts other
+     * than wakeup functionality.
+     */
+#if 0
     /* RTC Reg B, contain PIE/AIE/UIE */
     if ( value & (RTC_PIE | RTC_AIE | RTC_UIE ) )
     {
         cpuidle_disable_deep_cstate();
         pv_rtc_handler = NULL;
     }
+#else
+    if ( value & (RTC_PIE | RTC_UIE ) )
+	    printk("WARNING: dom0 attempting to use RTC interrupts!\n");
+#endif
 }

 void hpet_broadcast_init(void)


On Thu, Sep 6, 2012 at 9:05 AM, Konrad Rzeszutek Wilk
<konrad.wilk@oracle.com> wrote:
> On Thu, Sep 06, 2012 at 07:48:26AM -0400, Ben Guthro wrote:
>> Fantastic!
>>
>> Initial tests are very good, with this dma_msi_ack modification.
>>
>> I've been able to get past the ahci stall, and run through ~10 suspend
>> / resume cycles with this fix.
>> Additional tests are warranted, and I'll run through an automated
>> sleep / wake script I have to make sure this fix holds over time.
>
> How are you automating this? (/me imagines some robotic arm pressing
> the power button every couple of minutes).

--bcaec50fe0ad13fe9e04c9087459
Content-Type: application/octet-stream; name=cycle_wakeup
Content-Disposition: attachment; filename=cycle_wakeup
Content-Transfer-Encoding: base64
X-Attachment-Id: f_h6rw2hq90

IyEvYmluL3NoCgpwYXNzZXM9MTAwCnN1c3BlbmRfdGltZT0xNQphd2FrZV90aW1lPTMwCgpwcm9n
bmFtZT0kKGJhc2VuYW1lICQwKQoKdWV4aXQoKQp7CmNhdCA8PEVPRgpVc2FnZTogJHByb2duYW1l
IFtbLXZdIFstbF0gWy1wIDxudW0+XSBbLXMgPHNlY3M+XSBbLWEgPHNlY3M+XV0gWzxjb21tYW5k
Pl0KICAgICAgIC12ICAgICAgICAgIHZlcmJvc2UsIGVjaG8gcHJvZ2VzcyB0byBzdGRvdXQKICAg
ICAgIC1sICAgICAgICAgIGxvZyBwcm9ncmVzcyB0byBzeXNsb2cKICAgICAgIC1wICAgICAgICAg
IHNwZWNpZnkgbnVtYmVyIG9mIHBhc3NlcwogICAgICAgLXMgICAgICAgICAgdGltZSBzdGF5IGlu
IHN1c3BlbmQgaW4gc2Vjb25kcwogICAgICAgLWEgICAgICAgICAgYXdha2UgdGltZSBiZWZvcmUg
c3VzcGVuZCBpbiBzZWNvbmRzCiAgICAgICAgICAgICAgICAgICAgc3BlY2lmeWluZyAnbmV0JyBv
ciAnLTEnIHdpbGwgd2FpdCBmb3IgdGhlCiAgICAgICAgICAgICAgICAgICAgbmV0d29yayB0byBi
ZSB1cCBiZWZvcmUgcmUtc3VzcGVuZGluZwogICAgICAgPGNvbW1hbmQ+ICAgYSBzaGVsbCBjb21t
YW5kIHRvIHJ1biBmb3IgZWFjaCBwYXNzIG9mIHRoZSB0ZXN0CiAgICAgICAgICAgICAgICAgICAg
b24gcmVzdW1lIGZyb20gc3VzcGVuZC4KRU9GCn0KCiMKIyBQcm9jZXNzIGNvbW1hbmQgbGluZSBh
cmdzCiMKd2hpbGUgWyAtbiAiJDEiIF07IGRvCiAgICBjYXNlICQxIGluCgktdikJdmVyYm9zZT10
cnVlOwoJCTs7CgktbCkJdmVyYm9zZV9sb2c9dHJ1ZQoJCTs7CgktcCkJWyAkIyAtbHQgMiBdICYm
IHVleGl0CgkgICAgCXBhc3Nlcz0kMgoJCXNoaWZ0CgkJOzsKCS1zKQlbICQjIC1sdCAyIF0gJiYg
dWV4aXQKCSAgICAJc3VzcGVuZF90aW1lPSQyCgkJc2hpZnQKCQk7OwoJLWEpCVsgJCMgLWx0IDIg
XSAmJiB1ZXhpdAoJICAgIAlhd2FrZV90aW1lPSQyCgkJc2hpZnQKCQk7OwoJKikJYnJlYWsKCQk7
OwogICAgZXNhYwogICAgc2hpZnQKZG9uZQoKY21kPSIkKiIKCiMKIyBTdXBwb3J0IHJvdXRpbmVz
CiMKbG9naXQoKQp7CiAgICBpZiBbIHgiJDEiID0geCItdiIgXTsgdGhlbgoJc2hpZnQKCWVjaG8g
IiQqIgogICAgZWxpZiBbIC1uICIkdmVyYm9zZSIgXTsgdGhlbgoJZWNobyAiYGRhdGVgICQqIgog
ICAgZmkKICAgIGlmIFsgLW4gIiR2ZXJib3NlX2xvZyIgXTsgdGhlbgogICAgICAgIGVjaG8gIiRw
cm9nbmFtZTogJCoiID4gL2Rldi9rbXNnCiAgICBmaQp9CgpnZXR0aW1lKCkKewogICAgY2F0IC9z
eXMvY2xhc3MvcnRjL3J0YzAvc2luY2VfZXBvY2gKfQoKcGluZ2l0KCkKewogICAgbG9naXQgIlBp
bmdpbmcgcmVwb21hbi4iCiAgICBpPTYwCiAgICB3aGlsZSBbICRpIC1ndCAwIF07IGRvCglpZiBw
aW5nIC1jIDEgMTAuMS4xLjExID4vZGV2L251bGwgMj4mMTsgdGhlbgoJICAgIHJldHVybgoJZmkK
CXNsZWVwIDEKCWk9JCgoJGkgLSAxKSkKICAgIGRvbmUKICAgIGxvZ2l0ICJQaW5nIHRpbWVkIG91
dC4iCn0KCmRvX3N0YW5kYnkoKQp7CiAgICAjCiAgICAjIFRoZSBzdXNwZW5kIGNvZGUgdGhhdCBk
bWQgY2FsbHMsIC91c3IvbG9jYWwvYmluL3N0YW5kYnksCiAgICAjIHdpbGwgY2xlYXIgdGhlIC90
bXAvc3RhbmRieV90ZXN0IGZpbGUgd2hlbiBpdCBjb21wbGV0ZXMuCiAgICAjCiAgICB0b3VjaCAv
dG1wL3N0YW5kYnlfdGVzdAogICAgZG1kcnYgc3VzcGVuZF9wbGF0Zm9ybSAkKgogICAgd2hpbGUg
WyAtZSAvdG1wL3N0YW5kYnlfdGVzdCBdOyBkbwoJc2xlZXAgMQogICAgZG9uZQp9CgojCiMgL3Rt
cC9zdGFuZGJ5X3Rlc3QgaXMgdXNlZCB0byBwYXNzIHBhcmFtZXRlcnMgdG8gdGhlIHN0YW5kYnkg
c2NyaXB0CiMgaW4gL3Vzci9sb2NhbC9iaW4uCiMKcm0gLWYgL3RtcC9zdGFuZGJ5X3Rlc3QKCmxv
Z2l0IC12ICJSdW5uaW5nIHN1c3BlbmQgY3ljbGUgdGVzdCB3aXRoIHRoZSBmb2xsb3dpbmcgcGFy
YW1ldGVyczoiCmxvZ2l0IC12ICIgICAgcnVuIGZvciAkcGFzc2VzIHBhc3NlcyIKbG9naXQgLXYg
IiAgICBzdXNwZW5kIGZvciAkc3VzcGVuZF90aW1lIHNlY29uZHMiCmxvZ2l0IC12ICIgICAgc3Rh
eSBhd2FrZSBmb3IgJGF3YWtlX3RpbWUgc2Vjb25kcyIKCmNvdW50PTEKd2hpbGUgWyAxIF07IGRv
CgogICAgIwogICAgIyBEbyB0aGUgc3VzcGVuZAogICAgIwogICAgbG9naXQgIlN1c3BlbmRpbmcg
Zm9yICRzdXNwZW5kX3RpbWUgc2Vjb25kcywgUGFzcyAkY291bnQuIgoKICAgIHN0YXJ0PSQoZ2V0
dGltZSkKICAgIGRvX3N0YW5kYnkgLW4gLXMgJHN1c3BlbmRfdGltZSBQQVNTICRjb3VudAogICAg
ZW5kPSQoZ2V0dGltZSkKICAgIGRlbHRhPSQoKCRlbmQgLSAkc3RhcnQpKQoKICAgIGxvZ2l0ICJS
ZXN1bWVkIGluICRkZWx0YSBzZWNvbmRzLiIKCiAgICAjCiAgICAjIFNhbml0eSBjaGVjayB0aGUg
c3VzcGVuZCBkdXJhdGlvbgogICAgIwogICAgZXhwZWN0ZWQ9JCgoJHN1c3BlbmRfdGltZSArIDYw
KSkKICAgIGlmIFsgJGRlbHRhIC1ndCAkZXhwZWN0ZWQgXTsgdGhlbgoJbG9naXQgIkZBSUxVUkUs
IHN5c3RlbSBpbiBzdGFuZGJ5IGZvciB0b28gbG9uZyEiCglleGl0IDEKICAgIGZpCgogICAgIwog
ICAgIyBFeGVjdXRlIHRoZSBjb21tYW5kIHNwZWNpZmllZCBmb3IgZWFjaCBwYXNzCiAgICAjCiAg
ICBbIC1uICIkY21kIiBdICYmIGV2YWwgIiRjbWQiCgogICAgWyAkY291bnQgLWVxICRwYXNzZXMg
XSAmJiBicmVhawoKICAgICMKICAgICMgU3RheSBhd2FrZSBmb3IgdGhlIHNwZWNpZmllZCBwZXJp
b2QKICAgICMKICAgIGlmIFsgJGF3YWtlX3RpbWUgPSAibmV0IiAtbyAkYXdha2VfdGltZSAtZXEg
LTEgXTsgdGhlbgoJbG9naXQgIldhaXRpbmcgZm9yIG5ldHdvcmsgdG8gY29tZSB1cCIKCXBpbmdp
dAogICAgZWxpZiBbICRhd2FrZV90aW1lIC1ndCAwIF07IHRoZW4KCWxvZ2l0ICJXYWl0aW5nIGZv
ciAkYXdha2VfdGltZSBzZWNvbmRzLiIKCXNsZWVwICRhd2FrZV90aW1lIAogICAgZWxzZQoJbG9n
aXQgIk5vdCB3YWl0aW5nIgogICAgZmkKCiAgICBjb3VudD0kKCgkY291bnQgKyAxKSkKZG9uZQo=
--bcaec50fe0ad13fe9e04c9087459
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--bcaec50fe0ad13fe9e04c9087459--


From xen-devel-bounces@lists.xen.org Thu Sep 06 13:28:31 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 2012 13:28:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9c81-0002PJ-Hw; Thu, 06 Sep 2012 13:28:17 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1T9c80-0002OR-Bv
	for xen-devel@lists.xen.org; Thu, 06 Sep 2012 13:28:16 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1346938088!9879054!1
X-Originating-IP: [209.85.160.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19623 invoked from network); 6 Sep 2012 13:28:09 -0000
Received: from mail-gh0-f173.google.com (HELO mail-gh0-f173.google.com)
	(209.85.160.173)
	by server-8.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Sep 2012 13:28:09 -0000
Received: by ghrr17 with SMTP id r17so324038ghr.32
	for <xen-devel@lists.xen.org>; Thu, 06 Sep 2012 06:28:08 -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=2RfYAf6E0iTQMuM6+uutMzd5Kb1iykzIlVonm6Jd22Q=;
	b=piomi3vKuZjB+1JlrfVPFlmP6fmxL0EXJ1xDhGbTxjLOozyxdZYHEUj7FXAG3eDtVZ
	+9ciAbhpbWiqAKF7TndgJU//kNcOigC9AQvB5e/XCXByCE3OY5SSX/ny+3qSVi3Ew9y5
	J9ZCZ6NTOFHGk4n1fnvaWr7lSFVNqM3rDe3+qHl4z60gEwZW1wlJwoMpzUOTliwcCUNi
	Qxv5DFta1K9BzcZ441/kXrOFtfbiVALibYT/tCWFAO8z43STWra/RLrP3Vr4xkM/bIdL
	tVNKrrNfUe/ZBHzk6zKeAxlmR/Bklns+n3lTKGpBYj+So3KdmJ4/FWY5O9TpUNx4A43S
	2H8g==
Received: by 10.236.180.42 with SMTP id i30mr1631932yhm.89.1346938088348;
	Thu, 06 Sep 2012 06:28:08 -0700 (PDT)
Received: from [10.80.114.52] (firewall.ctxuk.citrix.com. [62.200.22.2])
	by mx.google.com with ESMTPS id g8sm1729978ank.18.2012.09.06.06.28.05
	(version=SSLv3 cipher=OTHER); Thu, 06 Sep 2012 06:28:06 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Thu, 06 Sep 2012 14:28:02 +0100
From: Keir Fraser <keir.xen@gmail.com>
To: Jan Beulich <JBeulich@suse.com>,
	David Vrabel <david.vrabel@citrix.com>
Message-ID: <CC6E6372.3DE4C%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [PATCH] timer: remove stray local_irq_enable()
Thread-Index: Ac2MM3BdIyABEibblkeTG63WakKQJw==
In-Reply-To: <5048B27F0200007800099535@nat28.tlf.novell.com>
Mime-version: 1.0
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] timer: remove stray local_irq_enable()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/09/2012 13:26, "Jan Beulich" <JBeulich@suse.com> wrote:

>>>> On 06.09.12 at 14:05, David Vrabel <david.vrabel@citrix.com> wrote:
>> From: David Vrabel <david.vrabel@citrix.com>
>> 
>> migrate_timers_from_cpu() has a stray local_irq_enable() that does
>> nothing (it's immediately after a spin_unlock_irq()) and has no
>> matching local_irq_disable().
>> 
>> Signed-off-by: David Vrabel <david.vrabel@citrix.com>
> 
> Acked-by: Jan Beulich <jbeulich@suse.com>

Acked-by: Keir Fraser <keir@xen.org>

Jan, Please apply it to xen-unstable.

 -- Keir

>> --- a/xen/common/timer.c
>> +++ b/xen/common/timer.c
>> @@ -587,7 +587,6 @@ static void migrate_timers_from_cpu(unsigned int old_cpu)
>>  
>>      spin_unlock(&old_ts->lock);
>>      spin_unlock_irq(&new_ts->lock);
>> -    local_irq_enable();
>>  
>>      if ( notify )
>>          cpu_raise_softirq(new_cpu, TIMER_SOFTIRQ);
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Sep 06 13:28:31 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 2012 13:28:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9c81-0002PJ-Hw; Thu, 06 Sep 2012 13:28:17 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1T9c80-0002OR-Bv
	for xen-devel@lists.xen.org; Thu, 06 Sep 2012 13:28:16 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1346938088!9879054!1
X-Originating-IP: [209.85.160.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19623 invoked from network); 6 Sep 2012 13:28:09 -0000
Received: from mail-gh0-f173.google.com (HELO mail-gh0-f173.google.com)
	(209.85.160.173)
	by server-8.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Sep 2012 13:28:09 -0000
Received: by ghrr17 with SMTP id r17so324038ghr.32
	for <xen-devel@lists.xen.org>; Thu, 06 Sep 2012 06:28:08 -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=2RfYAf6E0iTQMuM6+uutMzd5Kb1iykzIlVonm6Jd22Q=;
	b=piomi3vKuZjB+1JlrfVPFlmP6fmxL0EXJ1xDhGbTxjLOozyxdZYHEUj7FXAG3eDtVZ
	+9ciAbhpbWiqAKF7TndgJU//kNcOigC9AQvB5e/XCXByCE3OY5SSX/ny+3qSVi3Ew9y5
	J9ZCZ6NTOFHGk4n1fnvaWr7lSFVNqM3rDe3+qHl4z60gEwZW1wlJwoMpzUOTliwcCUNi
	Qxv5DFta1K9BzcZ441/kXrOFtfbiVALibYT/tCWFAO8z43STWra/RLrP3Vr4xkM/bIdL
	tVNKrrNfUe/ZBHzk6zKeAxlmR/Bklns+n3lTKGpBYj+So3KdmJ4/FWY5O9TpUNx4A43S
	2H8g==
Received: by 10.236.180.42 with SMTP id i30mr1631932yhm.89.1346938088348;
	Thu, 06 Sep 2012 06:28:08 -0700 (PDT)
Received: from [10.80.114.52] (firewall.ctxuk.citrix.com. [62.200.22.2])
	by mx.google.com with ESMTPS id g8sm1729978ank.18.2012.09.06.06.28.05
	(version=SSLv3 cipher=OTHER); Thu, 06 Sep 2012 06:28:06 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Thu, 06 Sep 2012 14:28:02 +0100
From: Keir Fraser <keir.xen@gmail.com>
To: Jan Beulich <JBeulich@suse.com>,
	David Vrabel <david.vrabel@citrix.com>
Message-ID: <CC6E6372.3DE4C%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [PATCH] timer: remove stray local_irq_enable()
Thread-Index: Ac2MM3BdIyABEibblkeTG63WakKQJw==
In-Reply-To: <5048B27F0200007800099535@nat28.tlf.novell.com>
Mime-version: 1.0
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] timer: remove stray local_irq_enable()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/09/2012 13:26, "Jan Beulich" <JBeulich@suse.com> wrote:

>>>> On 06.09.12 at 14:05, David Vrabel <david.vrabel@citrix.com> wrote:
>> From: David Vrabel <david.vrabel@citrix.com>
>> 
>> migrate_timers_from_cpu() has a stray local_irq_enable() that does
>> nothing (it's immediately after a spin_unlock_irq()) and has no
>> matching local_irq_disable().
>> 
>> Signed-off-by: David Vrabel <david.vrabel@citrix.com>
> 
> Acked-by: Jan Beulich <jbeulich@suse.com>

Acked-by: Keir Fraser <keir@xen.org>

Jan, Please apply it to xen-unstable.

 -- Keir

>> --- a/xen/common/timer.c
>> +++ b/xen/common/timer.c
>> @@ -587,7 +587,6 @@ static void migrate_timers_from_cpu(unsigned int old_cpu)
>>  
>>      spin_unlock(&old_ts->lock);
>>      spin_unlock_irq(&new_ts->lock);
>> -    local_irq_enable();
>>  
>>      if ( notify )
>>          cpu_raise_softirq(new_cpu, TIMER_SOFTIRQ);
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Sep 06 13:29:51 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 2012 13:29: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 1T9c9P-0002a7-16; Thu, 06 Sep 2012 13:29:43 +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 1T9c9N-0002Zu-Fh
	for xen-devel@lists.xen.org; Thu, 06 Sep 2012 13:29:41 +0000
Received: from [85.158.138.51:38000] by server-2.bemta-3.messagelabs.com id
	98/B9-04862-445A8405; Thu, 06 Sep 2012 13:29:40 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-11.tower-174.messagelabs.com!1346938180!29049278!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2590 invoked from network); 6 Sep 2012 13:29:40 -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; 6 Sep 2012 13:29:40 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1T9c9K-000FUi-RU; Thu, 06 Sep 2012 13:29:38 +0000
Date: Thu, 6 Sep 2012 14:29:38 +0100
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <ian.campbell@citrix.com>
Message-ID: <20120906132938.GK56463@ocelot.phlegethon.org>
References: <1346678886.32462.9.camel@zakaz.uk.xensource.com>
	<1346679056-8108-11-git-send-email-ian.campbell@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1346679056-8108-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/16] arm: mark heap and frametable limits
	as read mostly
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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:30 +0000 on 03 Sep (1346679051), Ian Campbell wrote:
> These are used in virt_to_page and page_to_virt so I imagine there's
> some small benefit to this (but I've not measured)
> 
> 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 Sep 06 13:29:51 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 2012 13:29: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 1T9c9P-0002a7-16; Thu, 06 Sep 2012 13:29:43 +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 1T9c9N-0002Zu-Fh
	for xen-devel@lists.xen.org; Thu, 06 Sep 2012 13:29:41 +0000
Received: from [85.158.138.51:38000] by server-2.bemta-3.messagelabs.com id
	98/B9-04862-445A8405; Thu, 06 Sep 2012 13:29:40 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-11.tower-174.messagelabs.com!1346938180!29049278!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2590 invoked from network); 6 Sep 2012 13:29:40 -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; 6 Sep 2012 13:29:40 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1T9c9K-000FUi-RU; Thu, 06 Sep 2012 13:29:38 +0000
Date: Thu, 6 Sep 2012 14:29:38 +0100
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <ian.campbell@citrix.com>
Message-ID: <20120906132938.GK56463@ocelot.phlegethon.org>
References: <1346678886.32462.9.camel@zakaz.uk.xensource.com>
	<1346679056-8108-11-git-send-email-ian.campbell@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1346679056-8108-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/16] arm: mark heap and frametable limits
	as read mostly
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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:30 +0000 on 03 Sep (1346679051), Ian Campbell wrote:
> These are used in virt_to_page and page_to_virt so I imagine there's
> some small benefit to this (but I've not measured)
> 
> 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 Sep 06 13:32:52 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 2012 13: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 1T9cCJ-0002w0-Qh; Thu, 06 Sep 2012 13:32:43 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Wei.Wang2@amd.com>) id 1T9cCH-0002uy-Lj
	for xen-devel@lists.xensource.com; Thu, 06 Sep 2012 13:32:41 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1346938354!6467406!1
X-Originating-IP: [213.199.154.141]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23545 invoked from network); 6 Sep 2012 13:32:35 -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;
	6 Sep 2012 13:32:35 -0000
Received: from mail75-db3-R.bigfish.com (10.3.81.231) by
	DB3EHSOBE007.bigfish.com (10.3.84.27) with Microsoft SMTP Server id
	14.1.225.23; Thu, 6 Sep 2012 13:32:34 +0000
Received: from mail75-db3 (localhost [127.0.0.1])	by mail75-db3-R.bigfish.com
	(Postfix) with ESMTP id 6DF1C2A01FB;
	Thu,  6 Sep 2012 13:32:34 +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: -6
X-BigFish: VPS-6(zzbb2dI98dI9371I936eI1432I4015Izz1202hzz8275bhz2dh668h839hd25he5bhf0ah107ah1155h)
Received: from mail75-db3 (localhost.localdomain [127.0.0.1]) by mail75-db3
	(MessageSwitch) id 1346938348572136_6571;
	Thu,  6 Sep 2012 13:32:28 +0000 (UTC)
Received: from DB3EHSMHS010.bigfish.com (unknown [10.3.81.241])	by
	mail75-db3.bigfish.com (Postfix) with ESMTP id 797BA400163;
	Thu,  6 Sep 2012 13:32:28 +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; Thu, 6 Sep 2012 13:32:26 +0000
X-WSS-ID: 0M9XK9Y-01-292-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 20CA8102825D;	Thu,  6 Sep 2012 08:31:43 -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, 6 Sep 2012 08:31:58 -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, 6 Sep 2012 08:31: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; Thu, 6 Sep 2012
	09:31: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 B372949C121; Thu,  6 Sep 2012
	14:31:39 +0100 (BST)
Message-ID: <5048A603.3070207@amd.com>
Date: Thu, 6 Sep 2012 15:32:51 +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: Sander Eikelenboom <linux@eikelenboom.it>
References: <504764E2.4000809@amd.com>
	<326589347.20120906005936@eikelenboom.it>
In-Reply-To: <326589347.20120906005936@eikelenboom.it>
X-OriginatorOrg: amd.com
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH] amd iommu: Dump flags of IO page faults
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 09/06/2012 12:59 AM, Sander Eikelenboom wrote:
>
> Wednesday, September 5, 2012, 4:42:42 PM, you wrote:
>
>> Hi Jan,
>> Attached patch dumps io page fault flags. The flags show the reason of
>> the fault and tell us if this is an unmapped interrupt fault or a DMA fault.
>
>> Thanks,
>> Wei
>
>> signed-off-by: Wei Wang<wei.wang2@amd.com>
>
>
> I have applied the patch and the flags seem to differ between the faults:
>
> AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0a06, fault address = 0xc2c2c2c0, flags = 0x000
> (XEN) [2012-09-05 20:54:16] AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0a06, fault address = 0xc2c2c2c0, flags = 0x000
> (XEN) [2012-09-05 20:54:16] AMD-Vi: IO_PAGE_FAULT: domain = 14, device id = 0x0700, fault address = 0xa8d339e0, flags = 0x020
> (XEN) [2012-09-05 20:54:16] AMD-Vi: IO_PAGE_FAULT: domain = 14, device id = 0x0700, fault address = 0xa8d33a40, flags = 0x020

OK, so they are not interrupt requests. I guess further information from 
your system would be helpful to debug this issue:
1) xl info
2) xl list
3) lscpi -vvv (NOTE: not in dom0 but in your guest)
4) cat /proc/iomem (in both dom0 and your hvm guest)

* I would also like to know the symptoms of device 0x0700 when IO_PF 
happened. Did it stop working?

(BTW: I copied a few options from your boot cmd line and it worked with 
my RD890 system

dom0_mem=1024M,max:1024M loglvl=all loglvl_guest=all console_timestamps 
cpuidle cpufreq=xen noreboot debug lapic=debug apic_verbosity=debug 
apic=debug iommu=on,verbose,debug,no-sharept

* so, what OEM board you have?)

Also from your log, these lines looks very strange:

(XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to 
read-only memory page. gfn=0xd5, mfn=0xa4a11
(XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to 
read-only memory page. gfn=0xd7, mfn=0xa4a0f
(XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to 
read-only memory page. gfn=0xd9, mfn=0xa4a0d
(XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to 
read-only memory page. gfn=0xdb, mfn=0xa4a0b
(XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to 
read-only memory page. gfn=0xdd, mfn=0xa4a09
(XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to 
read-only memory page. gfn=0xdf, mfn=0xa4a07
(XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to 
read-only memory page. gfn=0xe1, mfn=0xa4a05
(XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to 
read-only memory page. gfn=0xe3, mfn=0xa4a03
(XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to 
read-only memory page. gfn=0xe5, mfn=0xa4a01
(XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to 
read-only memory page. gfn=0xe7, mfn=0xa463f
(XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to 
read-only memory page. gfn=0xe9, mfn=0xa463d
(XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to 
read-only memory page. gfn=0xeb, mfn=0xa463b
(XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to 
read-only memory page. gfn=0xed, mfn=0xa4639
(XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to 
read-only memory page. gfn=0xef, mfn=0xa4637
(XEN) [2012-09-04 16:13:56] AMD-Vi: IO_PAGE_FAULT: domain = 0, device id 
= 0x0a06, fault address = 0xc2c2c2c0
(XEN) [2012-09-04 16:13:56] AMD-Vi: IO_PAGE_FAULT: domain = 14, device 
id = 0x0700, fault address = 0xa90f8300
(XEN) [2012-09-04 16:13:56] AMD-Vi: IO_PAGE_FAULT: domain = 14, device 
id = 0x0700, fault address = 0xa90f8340
(XEN) [2012-09-04 16:13:56] AMD-Vi: IO_PAGE_FAULT: domain = 14, device 
id = 0x0700, fault address = 0xa90f8380
(XEN) [2012-09-04 16:13:56] AMD-Vi: IO_PAGE_FAULT: domain = 14, device 
id = 0x0700, fault address = 0xa90f83c0

* they are just followed by the IO PAGE fault. Do you know where are 
they from? Your video card driver maybe?

Thanks,
Wei


> Complete xl dmesg and lspci -vvvknn attached.
>
> Thx
>
> --
> Sander



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

From xen-devel-bounces@lists.xen.org Thu Sep 06 13:32:52 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 2012 13: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 1T9cCJ-0002w0-Qh; Thu, 06 Sep 2012 13:32:43 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Wei.Wang2@amd.com>) id 1T9cCH-0002uy-Lj
	for xen-devel@lists.xensource.com; Thu, 06 Sep 2012 13:32:41 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1346938354!6467406!1
X-Originating-IP: [213.199.154.141]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23545 invoked from network); 6 Sep 2012 13:32:35 -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;
	6 Sep 2012 13:32:35 -0000
Received: from mail75-db3-R.bigfish.com (10.3.81.231) by
	DB3EHSOBE007.bigfish.com (10.3.84.27) with Microsoft SMTP Server id
	14.1.225.23; Thu, 6 Sep 2012 13:32:34 +0000
Received: from mail75-db3 (localhost [127.0.0.1])	by mail75-db3-R.bigfish.com
	(Postfix) with ESMTP id 6DF1C2A01FB;
	Thu,  6 Sep 2012 13:32:34 +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: -6
X-BigFish: VPS-6(zzbb2dI98dI9371I936eI1432I4015Izz1202hzz8275bhz2dh668h839hd25he5bhf0ah107ah1155h)
Received: from mail75-db3 (localhost.localdomain [127.0.0.1]) by mail75-db3
	(MessageSwitch) id 1346938348572136_6571;
	Thu,  6 Sep 2012 13:32:28 +0000 (UTC)
Received: from DB3EHSMHS010.bigfish.com (unknown [10.3.81.241])	by
	mail75-db3.bigfish.com (Postfix) with ESMTP id 797BA400163;
	Thu,  6 Sep 2012 13:32:28 +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; Thu, 6 Sep 2012 13:32:26 +0000
X-WSS-ID: 0M9XK9Y-01-292-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 20CA8102825D;	Thu,  6 Sep 2012 08:31:43 -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, 6 Sep 2012 08:31:58 -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, 6 Sep 2012 08:31: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; Thu, 6 Sep 2012
	09:31: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 B372949C121; Thu,  6 Sep 2012
	14:31:39 +0100 (BST)
Message-ID: <5048A603.3070207@amd.com>
Date: Thu, 6 Sep 2012 15:32:51 +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: Sander Eikelenboom <linux@eikelenboom.it>
References: <504764E2.4000809@amd.com>
	<326589347.20120906005936@eikelenboom.it>
In-Reply-To: <326589347.20120906005936@eikelenboom.it>
X-OriginatorOrg: amd.com
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH] amd iommu: Dump flags of IO page faults
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 09/06/2012 12:59 AM, Sander Eikelenboom wrote:
>
> Wednesday, September 5, 2012, 4:42:42 PM, you wrote:
>
>> Hi Jan,
>> Attached patch dumps io page fault flags. The flags show the reason of
>> the fault and tell us if this is an unmapped interrupt fault or a DMA fault.
>
>> Thanks,
>> Wei
>
>> signed-off-by: Wei Wang<wei.wang2@amd.com>
>
>
> I have applied the patch and the flags seem to differ between the faults:
>
> AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0a06, fault address = 0xc2c2c2c0, flags = 0x000
> (XEN) [2012-09-05 20:54:16] AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0a06, fault address = 0xc2c2c2c0, flags = 0x000
> (XEN) [2012-09-05 20:54:16] AMD-Vi: IO_PAGE_FAULT: domain = 14, device id = 0x0700, fault address = 0xa8d339e0, flags = 0x020
> (XEN) [2012-09-05 20:54:16] AMD-Vi: IO_PAGE_FAULT: domain = 14, device id = 0x0700, fault address = 0xa8d33a40, flags = 0x020

OK, so they are not interrupt requests. I guess further information from 
your system would be helpful to debug this issue:
1) xl info
2) xl list
3) lscpi -vvv (NOTE: not in dom0 but in your guest)
4) cat /proc/iomem (in both dom0 and your hvm guest)

* I would also like to know the symptoms of device 0x0700 when IO_PF 
happened. Did it stop working?

(BTW: I copied a few options from your boot cmd line and it worked with 
my RD890 system

dom0_mem=1024M,max:1024M loglvl=all loglvl_guest=all console_timestamps 
cpuidle cpufreq=xen noreboot debug lapic=debug apic_verbosity=debug 
apic=debug iommu=on,verbose,debug,no-sharept

* so, what OEM board you have?)

Also from your log, these lines looks very strange:

(XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to 
read-only memory page. gfn=0xd5, mfn=0xa4a11
(XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to 
read-only memory page. gfn=0xd7, mfn=0xa4a0f
(XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to 
read-only memory page. gfn=0xd9, mfn=0xa4a0d
(XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to 
read-only memory page. gfn=0xdb, mfn=0xa4a0b
(XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to 
read-only memory page. gfn=0xdd, mfn=0xa4a09
(XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to 
read-only memory page. gfn=0xdf, mfn=0xa4a07
(XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to 
read-only memory page. gfn=0xe1, mfn=0xa4a05
(XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to 
read-only memory page. gfn=0xe3, mfn=0xa4a03
(XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to 
read-only memory page. gfn=0xe5, mfn=0xa4a01
(XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to 
read-only memory page. gfn=0xe7, mfn=0xa463f
(XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to 
read-only memory page. gfn=0xe9, mfn=0xa463d
(XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to 
read-only memory page. gfn=0xeb, mfn=0xa463b
(XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to 
read-only memory page. gfn=0xed, mfn=0xa4639
(XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to 
read-only memory page. gfn=0xef, mfn=0xa4637
(XEN) [2012-09-04 16:13:56] AMD-Vi: IO_PAGE_FAULT: domain = 0, device id 
= 0x0a06, fault address = 0xc2c2c2c0
(XEN) [2012-09-04 16:13:56] AMD-Vi: IO_PAGE_FAULT: domain = 14, device 
id = 0x0700, fault address = 0xa90f8300
(XEN) [2012-09-04 16:13:56] AMD-Vi: IO_PAGE_FAULT: domain = 14, device 
id = 0x0700, fault address = 0xa90f8340
(XEN) [2012-09-04 16:13:56] AMD-Vi: IO_PAGE_FAULT: domain = 14, device 
id = 0x0700, fault address = 0xa90f8380
(XEN) [2012-09-04 16:13:56] AMD-Vi: IO_PAGE_FAULT: domain = 14, device 
id = 0x0700, fault address = 0xa90f83c0

* they are just followed by the IO PAGE fault. Do you know where are 
they from? Your video card driver maybe?

Thanks,
Wei


> Complete xl dmesg and lspci -vvvknn attached.
>
> Thx
>
> --
> Sander



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

From xen-devel-bounces@lists.xen.org Thu Sep 06 13:34:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 2012 13:34:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9cDS-00035D-9w; Thu, 06 Sep 2012 13:33: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 1T9cDQ-00034y-VM
	for xen-devel@lists.xen.org; Thu, 06 Sep 2012 13:33:53 +0000
Received: from [85.158.143.35:56236] by server-3.bemta-4.messagelabs.com id
	EB/BB-08232-046A8405; Thu, 06 Sep 2012 13:33:52 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-13.tower-21.messagelabs.com!1346938431!15629799!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2571 invoked from network); 6 Sep 2012 13:33:51 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-13.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 6 Sep 2012 13:33:51 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1T9cDP-000FVp-3u; Thu, 06 Sep 2012 13:33:51 +0000
Date: Thu, 6 Sep 2012 14:33:51 +0100
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <ian.campbell@citrix.com>
Message-ID: <20120906133351.GL56463@ocelot.phlegethon.org>
References: <1346678886.32462.9.camel@zakaz.uk.xensource.com>
	<1346679056-8108-12-git-send-email-ian.campbell@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1346679056-8108-12-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 12/16] arm: const-correctness in
	virt_to_maddr
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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:30 +0000 on 03 Sep (1346679052), Ian Campbell wrote:
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> ---
>  xen/include/asm-arm/mm.h |    4 ++--
>  1 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/xen/include/asm-arm/mm.h b/xen/include/asm-arm/mm.h
> index b0e5a67..7440fe5 100644
> --- a/xen/include/asm-arm/mm.h
> +++ b/xen/include/asm-arm/mm.h
> @@ -179,9 +179,9 @@ extern void clear_fixmap(unsigned map);
>  #define paddr_to_pdx(pa)    pfn_to_pdx(paddr_to_pfn(pa))
>  
>  
> -static inline paddr_t virt_to_maddr(void *va)
> +static inline paddr_t virt_to_maddr(const void *va)
>  {
> -    uint64_t par = va_to_par((uint32_t)va);
> +    uint64_t par = va_to_par((const uint32_t)va);

This second const is unnecessary (or else you also need one in the cast
on the next line).  For the first one, though:

Acked-by: Tim Deegan <tim@xen.org> 

>      return (par & PADDR_MASK & PAGE_MASK) | ((unsigned long) va & ~PAGE_MASK);
>  }
>  
> -- 
> 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 Sep 06 13:34:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 2012 13:34:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9cDS-00035D-9w; Thu, 06 Sep 2012 13:33: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 1T9cDQ-00034y-VM
	for xen-devel@lists.xen.org; Thu, 06 Sep 2012 13:33:53 +0000
Received: from [85.158.143.35:56236] by server-3.bemta-4.messagelabs.com id
	EB/BB-08232-046A8405; Thu, 06 Sep 2012 13:33:52 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-13.tower-21.messagelabs.com!1346938431!15629799!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2571 invoked from network); 6 Sep 2012 13:33:51 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-13.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 6 Sep 2012 13:33:51 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1T9cDP-000FVp-3u; Thu, 06 Sep 2012 13:33:51 +0000
Date: Thu, 6 Sep 2012 14:33:51 +0100
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <ian.campbell@citrix.com>
Message-ID: <20120906133351.GL56463@ocelot.phlegethon.org>
References: <1346678886.32462.9.camel@zakaz.uk.xensource.com>
	<1346679056-8108-12-git-send-email-ian.campbell@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1346679056-8108-12-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 12/16] arm: const-correctness in
	virt_to_maddr
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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:30 +0000 on 03 Sep (1346679052), Ian Campbell wrote:
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> ---
>  xen/include/asm-arm/mm.h |    4 ++--
>  1 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/xen/include/asm-arm/mm.h b/xen/include/asm-arm/mm.h
> index b0e5a67..7440fe5 100644
> --- a/xen/include/asm-arm/mm.h
> +++ b/xen/include/asm-arm/mm.h
> @@ -179,9 +179,9 @@ extern void clear_fixmap(unsigned map);
>  #define paddr_to_pdx(pa)    pfn_to_pdx(paddr_to_pfn(pa))
>  
>  
> -static inline paddr_t virt_to_maddr(void *va)
> +static inline paddr_t virt_to_maddr(const void *va)
>  {
> -    uint64_t par = va_to_par((uint32_t)va);
> +    uint64_t par = va_to_par((const uint32_t)va);

This second const is unnecessary (or else you also need one in the cast
on the next line).  For the first one, though:

Acked-by: Tim Deegan <tim@xen.org> 

>      return (par & PADDR_MASK & PAGE_MASK) | ((unsigned long) va & ~PAGE_MASK);
>  }
>  
> -- 
> 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 Sep 06 13:35:30 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 2012 13: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 1T9cEr-0003Fr-QO; Thu, 06 Sep 2012 13:35:21 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1T9cEq-0003Fa-Ch
	for xen-devel@lists.xen.org; Thu, 06 Sep 2012 13:35:20 +0000
Received: from [85.158.143.35:4139] by server-1.bemta-4.messagelabs.com id
	CE/1B-12504-796A8405; Thu, 06 Sep 2012 13:35:19 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-6.tower-21.messagelabs.com!1346938517!16991811!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26579 invoked from network); 6 Sep 2012 13:35:17 -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; 6 Sep 2012 13:35:17 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1T9cEm-000FWa-TD; Thu, 06 Sep 2012 13:35:16 +0000
Date: Thu, 6 Sep 2012 14:35:16 +0100
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <ian.campbell@citrix.com>
Message-ID: <20120906133516.GM56463@ocelot.phlegethon.org>
References: <1346678886.32462.9.camel@zakaz.uk.xensource.com>
	<1346679056-8108-13-git-send-email-ian.campbell@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1346679056-8108-13-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 13/16] device-tree: get_val cannot cope with
	cells > 2, add a BUG
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At 13:30 +0000 on 03 Sep (1346679053), Ian Campbell wrote:
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> ---
>  xen/common/device_tree.c |    4 +++-
>  1 files changed, 3 insertions(+), 1 deletions(-)
> 
> diff --git a/xen/common/device_tree.c b/xen/common/device_tree.c
> index 226e3f3..60f3a03 100644
> --- a/xen/common/device_tree.c
> +++ b/xen/common/device_tree.c
> @@ -45,6 +45,8 @@ static void __init get_val(const u32 **cell, u32 cells, u64 *val)
>  {
>      *val = 0;
>  
> +    BUG_ON( cells > 2 );
> +
>      while ( cells-- )
>      {
>          *val <<= 32;
> @@ -139,7 +141,7 @@ int device_tree_for_each_node(const void *fdt,
>   */
>  const char *device_tree_bootargs(const void *fdt)
>  {
> -    int node; 
> +    int node;

Unrelated change - maybe in a cset of its own, if that's not too ridiculous?

Tim.

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

From xen-devel-bounces@lists.xen.org Thu Sep 06 13:35:30 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 2012 13: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 1T9cEr-0003Fr-QO; Thu, 06 Sep 2012 13:35:21 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1T9cEq-0003Fa-Ch
	for xen-devel@lists.xen.org; Thu, 06 Sep 2012 13:35:20 +0000
Received: from [85.158.143.35:4139] by server-1.bemta-4.messagelabs.com id
	CE/1B-12504-796A8405; Thu, 06 Sep 2012 13:35:19 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-6.tower-21.messagelabs.com!1346938517!16991811!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26579 invoked from network); 6 Sep 2012 13:35:17 -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; 6 Sep 2012 13:35:17 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1T9cEm-000FWa-TD; Thu, 06 Sep 2012 13:35:16 +0000
Date: Thu, 6 Sep 2012 14:35:16 +0100
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <ian.campbell@citrix.com>
Message-ID: <20120906133516.GM56463@ocelot.phlegethon.org>
References: <1346678886.32462.9.camel@zakaz.uk.xensource.com>
	<1346679056-8108-13-git-send-email-ian.campbell@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1346679056-8108-13-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 13/16] device-tree: get_val cannot cope with
	cells > 2, add a BUG
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At 13:30 +0000 on 03 Sep (1346679053), Ian Campbell wrote:
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> ---
>  xen/common/device_tree.c |    4 +++-
>  1 files changed, 3 insertions(+), 1 deletions(-)
> 
> diff --git a/xen/common/device_tree.c b/xen/common/device_tree.c
> index 226e3f3..60f3a03 100644
> --- a/xen/common/device_tree.c
> +++ b/xen/common/device_tree.c
> @@ -45,6 +45,8 @@ static void __init get_val(const u32 **cell, u32 cells, u64 *val)
>  {
>      *val = 0;
>  
> +    BUG_ON( cells > 2 );
> +
>      while ( cells-- )
>      {
>          *val <<= 32;
> @@ -139,7 +141,7 @@ int device_tree_for_each_node(const void *fdt,
>   */
>  const char *device_tree_bootargs(const void *fdt)
>  {
> -    int node; 
> +    int node;

Unrelated change - maybe in a cset of its own, if that's not too ridiculous?

Tim.

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

From xen-devel-bounces@lists.xen.org Thu Sep 06 13:36:59 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 2012 13:36:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9cGK-0003R9-Bs; Thu, 06 Sep 2012 13:36:52 +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 1T9cGH-0003Ql-Qd
	for xen-devel@lists.xen.org; Thu, 06 Sep 2012 13:36:50 +0000
Received: from [85.158.138.51:52356] by server-3.bemta-3.messagelabs.com id
	48/EE-21322-1F6A8405; Thu, 06 Sep 2012 13:36:49 +0000
X-Env-Sender: ben.guthro@gmail.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1346938606!25014830!1
X-Originating-IP: [209.85.223.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5509 invoked from network); 6 Sep 2012 13:36:48 -0000
Received: from mail-ie0-f173.google.com (HELO mail-ie0-f173.google.com)
	(209.85.223.173)
	by server-10.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Sep 2012 13:36:48 -0000
Received: by iebc10 with SMTP id c10so3694168ieb.32
	for <xen-devel@lists.xen.org>; Thu, 06 Sep 2012 06:36: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=V7uJQXVY4D/r1G+e/wB1VmJoCdxksVZKQ71rgwZbYqA=;
	b=kXhoe5uEulE6Uq47+KsjaAzRlbZTWdYO/wcnLixuYLGacyAu16iQvemSbBXq8SYgSu
	bYNG7Zww+MWd0ZPRJE28kPRY6WHuLvWRLgzoK+XHi/dphxtStUnRJtAGnK7aIbohIo8I
	tVTXjiVmmffXLIsRZhzIYicv6LxZKGy6yFVCHcU01mTLJoJ6K86miDvAc1R+/tyVB9t9
	ISdGXxGArmeahgPpet3NbbURdpb2FQIRASNKAlqmqu4rStjIFH95sW1FR0Q6KllESt2d
	Or3bIqD3CSwXAMwrCISm/CjSD0AUYk1lgSwOjZYV7BnK+M+iupx9yKulZMZ0QHw15A//
	tFPA==
MIME-Version: 1.0
Received: by 10.50.160.233 with SMTP id xn9mr22756223igb.37.1346938606597;
	Thu, 06 Sep 2012 06:36:46 -0700 (PDT)
Received: by 10.64.28.203 with HTTP; Thu, 6 Sep 2012 06:36:46 -0700 (PDT)
In-Reply-To: <CAOvdn6XabjBqSkt7amzqw9omemNfNhJVds4Dgwf-APYAQWBwNQ@mail.gmail.com>
References: <502BB8FD02000078000951E0@nat28.tlf.novell.com>
	<CAOvdn6VD6bp13F-tvYdkBsj4hkhE7PTGZrapndtdHrDKeZqccg@mail.gmail.com>
	<502CCC0002000078000955C4@nat28.tlf.novell.com>
	<CAOvdn6VEuX7R2_wz74ZvCxMjC-=YUir9kP5sdxEVaKVspRUd_w@mail.gmail.com>
	<502CF0A8020000780009574E@nat28.tlf.novell.com>
	<CAOvdn6VsZvn_1TCWYeuyY5YuTcP8=miK2KwE4583nsj6Qjb_vg@mail.gmail.com>
	<504494FB0200007800098398@nat28.tlf.novell.com>
	<CAOvdn6UT13qvWbMyfZkWND03RoVKVSgb6wW4yqTUpuBYEX01Dg@mail.gmail.com>
	<5048958D02000078000993EB@nat28.tlf.novell.com>
	<CAOvdn6WrNK1Jn_Y_P7C3AwX6ApVcgzacLA_x-u=xBQtebnuPxA@mail.gmail.com>
	<20120906130559.GC22927@phenom.dumpdata.com>
	<CAOvdn6XabjBqSkt7amzqw9omemNfNhJVds4Dgwf-APYAQWBwNQ@mail.gmail.com>
Date: Thu, 6 Sep 2012 09:36:46 -0400
X-Google-Sender-Auth: qFOBOlNjzzQGIrL89pyQ8GYHJNY
Message-ID: <CAOvdn6Vk4ftVdjMNX15i30_N4z1GC7b9EzyCmMqhhfcwXBU_Lw@mail.gmail.com>
From: Ben Guthro <ben@guthro.net>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: Thomas Goetz <thomas.goetz@citrix.com>, john.baboval@citrix.com,
	Jan Beulich <JBeulich@suse.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen4.2 S3 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

Hmm - that script uses some stuff that is specific to our distro, but
could be adapted to do do something more standard, like
echo mem > /sys/power/state


On Thu, Sep 6, 2012 at 9:27 AM, Ben Guthro <ben@guthro.net> wrote:
> We have a cycle_wakeup script (attached) that programs the RTC
>
> This in itsself is not sufficient, due to interaction with the HPET.
> We have an additional patch (see below) to deal with that.
>
> The patch is not the cleanest solution ever, but it works...
>
>
> diff -r fc9dd79fe91a xen/arch/x86/hpet.c
> --- a/xen/arch/x86/hpet.c       Thu Mar 03 17:21:16 2011 -0500
> +++ b/xen/arch/x86/hpet.c       Thu Mar 03 17:35:57 2011 -0500
> @@ -520,13 +520,28 @@
>
>      if ( index != RTC_REG_B )
>          return;
> -
> +
> +    /*
> +     *  Wake on RTC alarm does not conflict with hpet.
> +     * The HW will wake up the CPU when the RTC alarm kicks off
> +     * even thought the interrupt is not routed to the APIC.
> +     *
> +     * In our distro, xen will always own the interrupt so
> +     * that we never disable deep cstates.  We do not run
> +     * dom0 apps/drivers that require RTC interrupts other
> +     * than wakeup functionality.
> +     */
> +#if 0
>      /* RTC Reg B, contain PIE/AIE/UIE */
>      if ( value & (RTC_PIE | RTC_AIE | RTC_UIE ) )
>      {
>          cpuidle_disable_deep_cstate();
>          pv_rtc_handler = NULL;
>      }
> +#else
> +    if ( value & (RTC_PIE | RTC_UIE ) )
> +           printk("WARNING: dom0 attempting to use RTC interrupts!\n");
> +#endif
>  }
>
>  void hpet_broadcast_init(void)
>
>
> On Thu, Sep 6, 2012 at 9:05 AM, Konrad Rzeszutek Wilk
> <konrad.wilk@oracle.com> wrote:
>> On Thu, Sep 06, 2012 at 07:48:26AM -0400, Ben Guthro wrote:
>>> Fantastic!
>>>
>>> Initial tests are very good, with this dma_msi_ack modification.
>>>
>>> I've been able to get past the ahci stall, and run through ~10 suspend
>>> / resume cycles with this fix.
>>> Additional tests are warranted, and I'll run through an automated
>>> sleep / wake script I have to make sure this fix holds over time.
>>
>> How are you automating this? (/me imagines some robotic arm pressing
>> the power button every couple of minutes).

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

From xen-devel-bounces@lists.xen.org Thu Sep 06 13:36:59 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 2012 13:36:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9cGK-0003R9-Bs; Thu, 06 Sep 2012 13:36:52 +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 1T9cGH-0003Ql-Qd
	for xen-devel@lists.xen.org; Thu, 06 Sep 2012 13:36:50 +0000
Received: from [85.158.138.51:52356] by server-3.bemta-3.messagelabs.com id
	48/EE-21322-1F6A8405; Thu, 06 Sep 2012 13:36:49 +0000
X-Env-Sender: ben.guthro@gmail.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1346938606!25014830!1
X-Originating-IP: [209.85.223.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5509 invoked from network); 6 Sep 2012 13:36:48 -0000
Received: from mail-ie0-f173.google.com (HELO mail-ie0-f173.google.com)
	(209.85.223.173)
	by server-10.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Sep 2012 13:36:48 -0000
Received: by iebc10 with SMTP id c10so3694168ieb.32
	for <xen-devel@lists.xen.org>; Thu, 06 Sep 2012 06:36: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=V7uJQXVY4D/r1G+e/wB1VmJoCdxksVZKQ71rgwZbYqA=;
	b=kXhoe5uEulE6Uq47+KsjaAzRlbZTWdYO/wcnLixuYLGacyAu16iQvemSbBXq8SYgSu
	bYNG7Zww+MWd0ZPRJE28kPRY6WHuLvWRLgzoK+XHi/dphxtStUnRJtAGnK7aIbohIo8I
	tVTXjiVmmffXLIsRZhzIYicv6LxZKGy6yFVCHcU01mTLJoJ6K86miDvAc1R+/tyVB9t9
	ISdGXxGArmeahgPpet3NbbURdpb2FQIRASNKAlqmqu4rStjIFH95sW1FR0Q6KllESt2d
	Or3bIqD3CSwXAMwrCISm/CjSD0AUYk1lgSwOjZYV7BnK+M+iupx9yKulZMZ0QHw15A//
	tFPA==
MIME-Version: 1.0
Received: by 10.50.160.233 with SMTP id xn9mr22756223igb.37.1346938606597;
	Thu, 06 Sep 2012 06:36:46 -0700 (PDT)
Received: by 10.64.28.203 with HTTP; Thu, 6 Sep 2012 06:36:46 -0700 (PDT)
In-Reply-To: <CAOvdn6XabjBqSkt7amzqw9omemNfNhJVds4Dgwf-APYAQWBwNQ@mail.gmail.com>
References: <502BB8FD02000078000951E0@nat28.tlf.novell.com>
	<CAOvdn6VD6bp13F-tvYdkBsj4hkhE7PTGZrapndtdHrDKeZqccg@mail.gmail.com>
	<502CCC0002000078000955C4@nat28.tlf.novell.com>
	<CAOvdn6VEuX7R2_wz74ZvCxMjC-=YUir9kP5sdxEVaKVspRUd_w@mail.gmail.com>
	<502CF0A8020000780009574E@nat28.tlf.novell.com>
	<CAOvdn6VsZvn_1TCWYeuyY5YuTcP8=miK2KwE4583nsj6Qjb_vg@mail.gmail.com>
	<504494FB0200007800098398@nat28.tlf.novell.com>
	<CAOvdn6UT13qvWbMyfZkWND03RoVKVSgb6wW4yqTUpuBYEX01Dg@mail.gmail.com>
	<5048958D02000078000993EB@nat28.tlf.novell.com>
	<CAOvdn6WrNK1Jn_Y_P7C3AwX6ApVcgzacLA_x-u=xBQtebnuPxA@mail.gmail.com>
	<20120906130559.GC22927@phenom.dumpdata.com>
	<CAOvdn6XabjBqSkt7amzqw9omemNfNhJVds4Dgwf-APYAQWBwNQ@mail.gmail.com>
Date: Thu, 6 Sep 2012 09:36:46 -0400
X-Google-Sender-Auth: qFOBOlNjzzQGIrL89pyQ8GYHJNY
Message-ID: <CAOvdn6Vk4ftVdjMNX15i30_N4z1GC7b9EzyCmMqhhfcwXBU_Lw@mail.gmail.com>
From: Ben Guthro <ben@guthro.net>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: Thomas Goetz <thomas.goetz@citrix.com>, john.baboval@citrix.com,
	Jan Beulich <JBeulich@suse.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen4.2 S3 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

Hmm - that script uses some stuff that is specific to our distro, but
could be adapted to do do something more standard, like
echo mem > /sys/power/state


On Thu, Sep 6, 2012 at 9:27 AM, Ben Guthro <ben@guthro.net> wrote:
> We have a cycle_wakeup script (attached) that programs the RTC
>
> This in itsself is not sufficient, due to interaction with the HPET.
> We have an additional patch (see below) to deal with that.
>
> The patch is not the cleanest solution ever, but it works...
>
>
> diff -r fc9dd79fe91a xen/arch/x86/hpet.c
> --- a/xen/arch/x86/hpet.c       Thu Mar 03 17:21:16 2011 -0500
> +++ b/xen/arch/x86/hpet.c       Thu Mar 03 17:35:57 2011 -0500
> @@ -520,13 +520,28 @@
>
>      if ( index != RTC_REG_B )
>          return;
> -
> +
> +    /*
> +     *  Wake on RTC alarm does not conflict with hpet.
> +     * The HW will wake up the CPU when the RTC alarm kicks off
> +     * even thought the interrupt is not routed to the APIC.
> +     *
> +     * In our distro, xen will always own the interrupt so
> +     * that we never disable deep cstates.  We do not run
> +     * dom0 apps/drivers that require RTC interrupts other
> +     * than wakeup functionality.
> +     */
> +#if 0
>      /* RTC Reg B, contain PIE/AIE/UIE */
>      if ( value & (RTC_PIE | RTC_AIE | RTC_UIE ) )
>      {
>          cpuidle_disable_deep_cstate();
>          pv_rtc_handler = NULL;
>      }
> +#else
> +    if ( value & (RTC_PIE | RTC_UIE ) )
> +           printk("WARNING: dom0 attempting to use RTC interrupts!\n");
> +#endif
>  }
>
>  void hpet_broadcast_init(void)
>
>
> On Thu, Sep 6, 2012 at 9:05 AM, Konrad Rzeszutek Wilk
> <konrad.wilk@oracle.com> wrote:
>> On Thu, Sep 06, 2012 at 07:48:26AM -0400, Ben Guthro wrote:
>>> Fantastic!
>>>
>>> Initial tests are very good, with this dma_msi_ack modification.
>>>
>>> I've been able to get past the ahci stall, and run through ~10 suspend
>>> / resume cycles with this fix.
>>> Additional tests are warranted, and I'll run through an automated
>>> sleep / wake script I have to make sure this fix holds over time.
>>
>> How are you automating this? (/me imagines some robotic arm pressing
>> the power button every couple of minutes).

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

From xen-devel-bounces@lists.xen.org Thu Sep 06 13:40:24 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 2012 13: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 1T9cJY-0003iO-0t; Thu, 06 Sep 2012 13:40:12 +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 1T9cJW-0003iF-Kc
	for xen-devel@lists.xen.org; Thu, 06 Sep 2012 13:40:10 +0000
Received: from [85.158.143.99:63190] by server-3.bemta-4.messagelabs.com id
	0D/09-08232-8B7A8405; Thu, 06 Sep 2012 13:40:08 +0000
X-Env-Sender: ben.guthro@gmail.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1346938805!23636496!1
X-Originating-IP: [209.85.223.173]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
  RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6081 invoked from network); 6 Sep 2012 13:40:07 -0000
Received: from mail-ie0-f173.google.com (HELO mail-ie0-f173.google.com)
	(209.85.223.173)
	by server-4.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Sep 2012 13:40:07 -0000
Received: by iebc10 with SMTP id c10so3701721ieb.32
	for <xen-devel@lists.xen.org>; Thu, 06 Sep 2012 06:40:05 -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=vKikuthL3GPVPbT61cYornLjipMCgLUsk+CSYCMTCog=;
	b=yBLTPCHYBNsM+VS29oYD3jtjm06Bii+2uvzfWqF5LcmOVyJan2/zhpv+0vE1n8ZUjJ
	u2/UEsIBZikqB0WaYKqjIX7CX6JVYG8go/0pJEg+R/TglwSt/C3HiVvrZhDC/abXUG71
	vR57/Lml52gWzGMRhpHMf6Xk8XpRyrorMB/7o1BPBrwLCudK//mICYG/GAcrTJNhiwGt
	1ipVusGjJNHP82Wr9kqbcBG6zVFMKtvteuZyEGXmHY7LvVTXfhePNR/MSByrqPlA4W19
	ItQo5nKWzqb1rat5PsLpaAHWFC/c5FSLjbyYVeJC9CnpGKSa4lboR37ybBj3Du1eOAxi
	z92g==
MIME-Version: 1.0
Received: by 10.50.159.194 with SMTP id xe2mr3015366igb.62.1346938805491; Thu,
	06 Sep 2012 06:40:05 -0700 (PDT)
Received: by 10.64.28.203 with HTTP; Thu, 6 Sep 2012 06:40:05 -0700 (PDT)
In-Reply-To: <CAOvdn6VUoFN8n-weX4Ni6-O2HivLepWfXV+JMuj7Hjc7oXN9cg@mail.gmail.com>
References: <1346665360.25864.2.camel@zakaz.uk.xensource.com>
	<5048B4DF0200007800099554@nat28.tlf.novell.com>
	<CAOvdn6VUoFN8n-weX4Ni6-O2HivLepWfXV+JMuj7Hjc7oXN9cg@mail.gmail.com>
Date: Thu, 6 Sep 2012 09:40:05 -0400
X-Google-Sender-Auth: irGKyBErr7tsOf_2ZuK7b1ELnDI
Message-ID: <CAOvdn6XUFL665RNvL6JKRovgPYYO32ujTkSE4LTrQy8xTU_9fQ@mail.gmail.com>
From: Ben Guthro <ben@guthro.net>
To: Jan Beulich <JBeulich@suse.com>
Cc: Ian Campbell <Ian.Campbell@citrix.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.2.0 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

Good news on this front, as well - it seems to fix the "blinky power
button" failure, as well.


On Thu, Sep 6, 2012 at 8:55 AM, Ben Guthro <ben@guthro.net> wrote:
> FWIW, I ran this through 100 suspend / resume cycles successfully, on
> the machine where I could only do one before.
>
> I'm still waiting for a laptop to free up that exhibited the other S3
> failure where it went to sleep, but just pulsed the power LED when
> asked to wake up.
> I'm cautiously hopeful this fixes that problem, as well.
>
> Ben
>
> On Thu, Sep 6, 2012 at 8:36 AM, Jan Beulich <JBeulich@suse.com> wrote:
>>>>> On 03.09.12 at 11:42, Ian Campbell <Ian.Campbell@citrix.com> wrote:
>>> hypervisor, nice to have:
>>>
>>>     * S3 regression(s?) reported by Ben Guthro (Ben & Jan Beulich)
>>
>> So it looks like we got this nailed down (actually requiring two
>> fixes). Would it be intended to still get these in before the
>> release, or leave them for 4.3/4.2.1?
>>
>> Jan
>>
>> NB:  I also found an unrelated issue earlier today where a
>> hypercall would return success when it actually failed, but I
>> won't even bother sending that out if the fixes needed here
>> aren't to be considered, as that's clearly minor compared to
>> the regression here.
>>
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xen.org
>> http://lists.xen.org/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 Sep 06 13:40:24 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 2012 13: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 1T9cJY-0003iO-0t; Thu, 06 Sep 2012 13:40:12 +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 1T9cJW-0003iF-Kc
	for xen-devel@lists.xen.org; Thu, 06 Sep 2012 13:40:10 +0000
Received: from [85.158.143.99:63190] by server-3.bemta-4.messagelabs.com id
	0D/09-08232-8B7A8405; Thu, 06 Sep 2012 13:40:08 +0000
X-Env-Sender: ben.guthro@gmail.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1346938805!23636496!1
X-Originating-IP: [209.85.223.173]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
  RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6081 invoked from network); 6 Sep 2012 13:40:07 -0000
Received: from mail-ie0-f173.google.com (HELO mail-ie0-f173.google.com)
	(209.85.223.173)
	by server-4.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Sep 2012 13:40:07 -0000
Received: by iebc10 with SMTP id c10so3701721ieb.32
	for <xen-devel@lists.xen.org>; Thu, 06 Sep 2012 06:40:05 -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=vKikuthL3GPVPbT61cYornLjipMCgLUsk+CSYCMTCog=;
	b=yBLTPCHYBNsM+VS29oYD3jtjm06Bii+2uvzfWqF5LcmOVyJan2/zhpv+0vE1n8ZUjJ
	u2/UEsIBZikqB0WaYKqjIX7CX6JVYG8go/0pJEg+R/TglwSt/C3HiVvrZhDC/abXUG71
	vR57/Lml52gWzGMRhpHMf6Xk8XpRyrorMB/7o1BPBrwLCudK//mICYG/GAcrTJNhiwGt
	1ipVusGjJNHP82Wr9kqbcBG6zVFMKtvteuZyEGXmHY7LvVTXfhePNR/MSByrqPlA4W19
	ItQo5nKWzqb1rat5PsLpaAHWFC/c5FSLjbyYVeJC9CnpGKSa4lboR37ybBj3Du1eOAxi
	z92g==
MIME-Version: 1.0
Received: by 10.50.159.194 with SMTP id xe2mr3015366igb.62.1346938805491; Thu,
	06 Sep 2012 06:40:05 -0700 (PDT)
Received: by 10.64.28.203 with HTTP; Thu, 6 Sep 2012 06:40:05 -0700 (PDT)
In-Reply-To: <CAOvdn6VUoFN8n-weX4Ni6-O2HivLepWfXV+JMuj7Hjc7oXN9cg@mail.gmail.com>
References: <1346665360.25864.2.camel@zakaz.uk.xensource.com>
	<5048B4DF0200007800099554@nat28.tlf.novell.com>
	<CAOvdn6VUoFN8n-weX4Ni6-O2HivLepWfXV+JMuj7Hjc7oXN9cg@mail.gmail.com>
Date: Thu, 6 Sep 2012 09:40:05 -0400
X-Google-Sender-Auth: irGKyBErr7tsOf_2ZuK7b1ELnDI
Message-ID: <CAOvdn6XUFL665RNvL6JKRovgPYYO32ujTkSE4LTrQy8xTU_9fQ@mail.gmail.com>
From: Ben Guthro <ben@guthro.net>
To: Jan Beulich <JBeulich@suse.com>
Cc: Ian Campbell <Ian.Campbell@citrix.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.2.0 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

Good news on this front, as well - it seems to fix the "blinky power
button" failure, as well.


On Thu, Sep 6, 2012 at 8:55 AM, Ben Guthro <ben@guthro.net> wrote:
> FWIW, I ran this through 100 suspend / resume cycles successfully, on
> the machine where I could only do one before.
>
> I'm still waiting for a laptop to free up that exhibited the other S3
> failure where it went to sleep, but just pulsed the power LED when
> asked to wake up.
> I'm cautiously hopeful this fixes that problem, as well.
>
> Ben
>
> On Thu, Sep 6, 2012 at 8:36 AM, Jan Beulich <JBeulich@suse.com> wrote:
>>>>> On 03.09.12 at 11:42, Ian Campbell <Ian.Campbell@citrix.com> wrote:
>>> hypervisor, nice to have:
>>>
>>>     * S3 regression(s?) reported by Ben Guthro (Ben & Jan Beulich)
>>
>> So it looks like we got this nailed down (actually requiring two
>> fixes). Would it be intended to still get these in before the
>> release, or leave them for 4.3/4.2.1?
>>
>> Jan
>>
>> NB:  I also found an unrelated issue earlier today where a
>> hypercall would return success when it actually failed, but I
>> won't even bother sending that out if the fixes needed here
>> aren't to be considered, as that's clearly minor compared to
>> the regression here.
>>
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xen.org
>> http://lists.xen.org/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 Sep 06 13:40:56 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 2012 13: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 1T9cK7-0003lQ-Er; Thu, 06 Sep 2012 13:40:47 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <linux@eikelenboom.it>) id 1T9cK6-0003kq-Cj
	for xen-devel@lists.xensource.com; Thu, 06 Sep 2012 13:40:46 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-6.tower-27.messagelabs.com!1346938838!4285889!1
X-Originating-IP: [88.159.1.182]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogODguMTU5LjEuMTgyID0+IDMyMzAz\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16083 invoked from network); 6 Sep 2012 13:40:38 -0000
Received: from isp-bos-01.edutel.nl (HELO isp-bos-01.edutel.nl) (88.159.1.182)
	by server-6.tower-27.messagelabs.com with SMTP;
	6 Sep 2012 13:40:38 -0000
Received: from isp-aos-02.edutel.intern (unknown [IPv6:2a01:670:100:11::1:2])
	by isp-bos-01.edutel.nl (Postfix) with ESMTP id 20BFA2BC16A;
	Thu,  6 Sep 2012 15:40:38 +0200 (CEST)
Received: from localhost (localhost.localdomain [127.0.0.1])
	by isp-aos-02.edutel.intern (Postfix) with ESMTP id 1EEE4394305;
	Thu,  6 Sep 2012 15:40:38 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at isp-aos-02.edutel.intern
Received: from isp-aos-02.edutel.intern ([127.0.0.1])
	by localhost (isp-aos-02.edutel.intern [127.0.0.1]) (amavisd-new,
	port 10024)
	with ESMTP id Ax9RZkXER2Vu; Thu,  6 Sep 2012 15:40:38 +0200 (CEST)
Received: from mail.home.eikelenboom.it (128-64-ftth.onsneteindhoven.nl
	[88.159.64.128])
	by isp-aos-02.edutel.intern (Postfix) with ESMTPSA id 0C89B394303;
	Thu,  6 Sep 2012 15:40:38 +0200 (CEST)
Received: from [172.16.1.31] (helo=xentest.example.org)
	by mail.home.eikelenboom.it with esmtpa (Exim 4.72)
	(envelope-from <linux@eikelenboom.it>)
	id 1T9cG4-00012c-Nb; Thu, 06 Sep 2012 15:36:36 +0200
MIME-Version: 1.0
X-Mercurial-Node: c6d5f62c345b6b41b9ffdb85244bdc486830f8ac
Message-Id: <c6d5f62c345b6b41b9ff.1346942187@xentest.example.org>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Thu, 06 Sep 2012 16:36:27 +0200
From: Sander Eikelenboom <linux@eikelenboom.it>
To: xen-devel@lists.xensource.com
Cc: Ian.Campbell@citrix.com
Subject: [Xen-devel] [PATCH] xl: Introduce shutdown xm compatibility option
 -a to shutdown all 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

xl: Introduce shutdown xm compatibility option -a to shutdown all domains

v2: address review comments.
    - Change shutdown_domain to take domid instead of domname
    - Docs: Make it more clear -a only shuts down GUEST domains

Signed-off-by: Sander Eikelenboom <linux@eikelenboom.it>

diff -r 9dc729b75595 -r c6d5f62c345b docs/man/xl.pod.1
--- a/docs/man/xl.pod.1	Mon Sep 03 11:22:02 2012 +0100
+++ b/docs/man/xl.pod.1	Thu Sep 06 16:35:04 2012 +0200
@@ -527,7 +527,7 @@ List specifically for that domain. Other
 
 =back
 
-=item B<shutdown> [I<OPTIONS>] I<domain-id>
+=item B<shutdown> [I<OPTIONS>] I<-a|domain-id>
 
 Gracefully shuts down a domain.  This coordinates with the domain OS
 to perform graceful shutdown, so there is no guarantee that it will
@@ -550,6 +550,10 @@ B<OPTIONS>
 
 =over 4
 
+=item B<-a>
+
+-a  Shutdown all guest domains.  Often used when doing a complete shutdown of a Xen system.
+
 =item B<-w>
 
 Wait for the domain to complete shutdown before returning.
diff -r 9dc729b75595 -r c6d5f62c345b tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Mon Sep 03 11:22:02 2012 +0100
+++ b/tools/libxl/xl_cmdimpl.c	Thu Sep 06 16:35:04 2012 +0200
@@ -2683,12 +2683,11 @@ static void destroy_domain(const char *p
     if (rc) { fprintf(stderr,"destroy failed (rc=%d)\n",rc); exit(-1); }
 }
 
-static void shutdown_domain(const char *p, int wait, int fallback_trigger)
+static void shutdown_domain(uint32_t domid, int wait, int fallback_trigger)
 {
     int rc;
     libxl_event *event;
 
-    find_domain(p);
     rc=libxl_domain_shutdown(ctx, domid);
     if (rc == ERROR_NOPARAVIRT) {
         if (fallback_trigger) {
@@ -3670,14 +3669,19 @@ int main_destroy(int argc, char **argv)
 
 int main_shutdown(int argc, char **argv)
 {
-    int opt;
+    libxl_dominfo *dominfo;
+    int opt, i, nb_domain;
+    int all = 0;
     int wait = 0;
     int fallback_trigger = 0;
 
-    while ((opt = def_getopt(argc, argv, "wF", "shutdown", 1)) != -1) {
+    while ((opt = def_getopt(argc, argv, "awF", "shutdown", 0)) != -1) {
         switch (opt) {
         case 0: case 2:
             return opt;
+        case 'a':
+            all = 1;
+            break;
         case 'w':
             wait = 1;
             break;
@@ -3687,7 +3691,30 @@ int main_shutdown(int argc, char **argv)
         }
     }
 
-    shutdown_domain(argv[optind], wait, fallback_trigger);
+    if (!argv[optind] && !all) {
+        fprintf(stderr, "You must specify -a or a domain id.\n\n");
+        return opt;
+    }
+
+    if (all) {
+        if (!(dominfo = libxl_list_domain(ctx, &nb_domain))) {
+            fprintf(stderr, "libxl_list_domain failed.\n");
+            return -1;
+        }
+
+        for (i = 0; i<nb_domain; i++) {
+            if (dominfo[i].domid == 0)
+                continue;
+
+            shutdown_domain(dominfo[i].domid, wait, fallback_trigger);
+        }
+
+        libxl_dominfo_list_free(dominfo, nb_domain);
+    } else {
+        find_domain(argv[optind]);
+        shutdown_domain(domid, wait, fallback_trigger);
+    }
+
     return 0;
 }
 
diff -r 9dc729b75595 -r c6d5f62c345b tools/libxl/xl_cmdtable.c
--- a/tools/libxl/xl_cmdtable.c	Mon Sep 03 11:22:02 2012 +0100
+++ b/tools/libxl/xl_cmdtable.c	Thu Sep 06 16:35:04 2012 +0200
@@ -60,7 +60,8 @@ struct cmd_spec cmd_table[] = {
     { "shutdown",
       &main_shutdown, 0, 1,
       "Issue a shutdown signal to a domain",
-      "[options] <Domain>",
+      "[options] <-a|Domain>",
+      "-a                      Shutdown all guest domains.\n"
       "-h                      Print this help.\n"
       "-F                      Fallback to ACPI power event for HVM guests with\n"
       "                        no PV drivers.\n"

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

From xen-devel-bounces@lists.xen.org Thu Sep 06 13:40:56 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 2012 13: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 1T9cK7-0003lQ-Er; Thu, 06 Sep 2012 13:40:47 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <linux@eikelenboom.it>) id 1T9cK6-0003kq-Cj
	for xen-devel@lists.xensource.com; Thu, 06 Sep 2012 13:40:46 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-6.tower-27.messagelabs.com!1346938838!4285889!1
X-Originating-IP: [88.159.1.182]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogODguMTU5LjEuMTgyID0+IDMyMzAz\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16083 invoked from network); 6 Sep 2012 13:40:38 -0000
Received: from isp-bos-01.edutel.nl (HELO isp-bos-01.edutel.nl) (88.159.1.182)
	by server-6.tower-27.messagelabs.com with SMTP;
	6 Sep 2012 13:40:38 -0000
Received: from isp-aos-02.edutel.intern (unknown [IPv6:2a01:670:100:11::1:2])
	by isp-bos-01.edutel.nl (Postfix) with ESMTP id 20BFA2BC16A;
	Thu,  6 Sep 2012 15:40:38 +0200 (CEST)
Received: from localhost (localhost.localdomain [127.0.0.1])
	by isp-aos-02.edutel.intern (Postfix) with ESMTP id 1EEE4394305;
	Thu,  6 Sep 2012 15:40:38 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at isp-aos-02.edutel.intern
Received: from isp-aos-02.edutel.intern ([127.0.0.1])
	by localhost (isp-aos-02.edutel.intern [127.0.0.1]) (amavisd-new,
	port 10024)
	with ESMTP id Ax9RZkXER2Vu; Thu,  6 Sep 2012 15:40:38 +0200 (CEST)
Received: from mail.home.eikelenboom.it (128-64-ftth.onsneteindhoven.nl
	[88.159.64.128])
	by isp-aos-02.edutel.intern (Postfix) with ESMTPSA id 0C89B394303;
	Thu,  6 Sep 2012 15:40:38 +0200 (CEST)
Received: from [172.16.1.31] (helo=xentest.example.org)
	by mail.home.eikelenboom.it with esmtpa (Exim 4.72)
	(envelope-from <linux@eikelenboom.it>)
	id 1T9cG4-00012c-Nb; Thu, 06 Sep 2012 15:36:36 +0200
MIME-Version: 1.0
X-Mercurial-Node: c6d5f62c345b6b41b9ffdb85244bdc486830f8ac
Message-Id: <c6d5f62c345b6b41b9ff.1346942187@xentest.example.org>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Thu, 06 Sep 2012 16:36:27 +0200
From: Sander Eikelenboom <linux@eikelenboom.it>
To: xen-devel@lists.xensource.com
Cc: Ian.Campbell@citrix.com
Subject: [Xen-devel] [PATCH] xl: Introduce shutdown xm compatibility option
 -a to shutdown all 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

xl: Introduce shutdown xm compatibility option -a to shutdown all domains

v2: address review comments.
    - Change shutdown_domain to take domid instead of domname
    - Docs: Make it more clear -a only shuts down GUEST domains

Signed-off-by: Sander Eikelenboom <linux@eikelenboom.it>

diff -r 9dc729b75595 -r c6d5f62c345b docs/man/xl.pod.1
--- a/docs/man/xl.pod.1	Mon Sep 03 11:22:02 2012 +0100
+++ b/docs/man/xl.pod.1	Thu Sep 06 16:35:04 2012 +0200
@@ -527,7 +527,7 @@ List specifically for that domain. Other
 
 =back
 
-=item B<shutdown> [I<OPTIONS>] I<domain-id>
+=item B<shutdown> [I<OPTIONS>] I<-a|domain-id>
 
 Gracefully shuts down a domain.  This coordinates with the domain OS
 to perform graceful shutdown, so there is no guarantee that it will
@@ -550,6 +550,10 @@ B<OPTIONS>
 
 =over 4
 
+=item B<-a>
+
+-a  Shutdown all guest domains.  Often used when doing a complete shutdown of a Xen system.
+
 =item B<-w>
 
 Wait for the domain to complete shutdown before returning.
diff -r 9dc729b75595 -r c6d5f62c345b tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Mon Sep 03 11:22:02 2012 +0100
+++ b/tools/libxl/xl_cmdimpl.c	Thu Sep 06 16:35:04 2012 +0200
@@ -2683,12 +2683,11 @@ static void destroy_domain(const char *p
     if (rc) { fprintf(stderr,"destroy failed (rc=%d)\n",rc); exit(-1); }
 }
 
-static void shutdown_domain(const char *p, int wait, int fallback_trigger)
+static void shutdown_domain(uint32_t domid, int wait, int fallback_trigger)
 {
     int rc;
     libxl_event *event;
 
-    find_domain(p);
     rc=libxl_domain_shutdown(ctx, domid);
     if (rc == ERROR_NOPARAVIRT) {
         if (fallback_trigger) {
@@ -3670,14 +3669,19 @@ int main_destroy(int argc, char **argv)
 
 int main_shutdown(int argc, char **argv)
 {
-    int opt;
+    libxl_dominfo *dominfo;
+    int opt, i, nb_domain;
+    int all = 0;
     int wait = 0;
     int fallback_trigger = 0;
 
-    while ((opt = def_getopt(argc, argv, "wF", "shutdown", 1)) != -1) {
+    while ((opt = def_getopt(argc, argv, "awF", "shutdown", 0)) != -1) {
         switch (opt) {
         case 0: case 2:
             return opt;
+        case 'a':
+            all = 1;
+            break;
         case 'w':
             wait = 1;
             break;
@@ -3687,7 +3691,30 @@ int main_shutdown(int argc, char **argv)
         }
     }
 
-    shutdown_domain(argv[optind], wait, fallback_trigger);
+    if (!argv[optind] && !all) {
+        fprintf(stderr, "You must specify -a or a domain id.\n\n");
+        return opt;
+    }
+
+    if (all) {
+        if (!(dominfo = libxl_list_domain(ctx, &nb_domain))) {
+            fprintf(stderr, "libxl_list_domain failed.\n");
+            return -1;
+        }
+
+        for (i = 0; i<nb_domain; i++) {
+            if (dominfo[i].domid == 0)
+                continue;
+
+            shutdown_domain(dominfo[i].domid, wait, fallback_trigger);
+        }
+
+        libxl_dominfo_list_free(dominfo, nb_domain);
+    } else {
+        find_domain(argv[optind]);
+        shutdown_domain(domid, wait, fallback_trigger);
+    }
+
     return 0;
 }
 
diff -r 9dc729b75595 -r c6d5f62c345b tools/libxl/xl_cmdtable.c
--- a/tools/libxl/xl_cmdtable.c	Mon Sep 03 11:22:02 2012 +0100
+++ b/tools/libxl/xl_cmdtable.c	Thu Sep 06 16:35:04 2012 +0200
@@ -60,7 +60,8 @@ struct cmd_spec cmd_table[] = {
     { "shutdown",
       &main_shutdown, 0, 1,
       "Issue a shutdown signal to a domain",
-      "[options] <Domain>",
+      "[options] <-a|Domain>",
+      "-a                      Shutdown all guest domains.\n"
       "-h                      Print this help.\n"
       "-F                      Fallback to ACPI power event for HVM guests with\n"
       "                        no PV drivers.\n"

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

From xen-devel-bounces@lists.xen.org Thu Sep 06 13:42:00 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 2012 13:42:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9cLB-0003tF-2S; Thu, 06 Sep 2012 13:41:53 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andreslc@gridcentric.ca>) id 1T9cL8-0003ss-2j
	for xen-devel@lists.xen.org; Thu, 06 Sep 2012 13:41:51 +0000
Received: from [85.158.138.51:47081] by server-10.bemta-3.messagelabs.com id
	E7/54-10411-D18A8405; Thu, 06 Sep 2012 13:41:49 +0000
X-Env-Sender: andreslc@gridcentric.ca
X-Msg-Ref: server-3.tower-174.messagelabs.com!1346938906!20980376!1
X-Originating-IP: [209.85.223.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11563 invoked from network); 6 Sep 2012 13:41:47 -0000
Received: from mail-ie0-f173.google.com (HELO mail-ie0-f173.google.com)
	(209.85.223.173)
	by server-3.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Sep 2012 13:41:47 -0000
Received: by iebc10 with SMTP id c10so3705690ieb.32
	for <xen-devel@lists.xen.org>; Thu, 06 Sep 2012 06:41:45 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=subject:mime-version:content-type:from:in-reply-to:date:cc
	:content-transfer-encoding:message-id:references:to:x-mailer
	:x-gm-message-state;
	bh=MyBgE1ElmJSLQ7p07GVKmGblLfWB/YYAZKmNYGiGHn4=;
	b=BVaCPstkqlGiO+ibGLLXH8/eyMEQsXBGYE1btBSW4r0GBrLUpZrr/OAG2EhOhrZpqE
	AAQQxz6/NH48aU7eipoA4+L/tOuLWd46jMkZ4CZqj7wwOY5thhbdAE6OZ7bXzm3JwWPc
	niRlbXw2OVaS8woloNQIh+1F2Hc8IXcMTJreRZncZGNCX1b8VNk3K7g2+TlBQ6CK1jAZ
	hKzvHUxNauFzl7aS2okk3N17Q1TN5JQIq04xNTFJPb3rIpNvrBuBkOr0RFU0kw0FZyM/
	kIbhoinMA6HIA3DqmmQIu4O2DvpnnW6DgIOjDRiwWwDs1IaMmM3vwU8VbpL8W4oxPH3E
	Z4sw==
Received: by 10.50.209.41 with SMTP id mj9mr3026186igc.23.1346938905840;
	Thu, 06 Sep 2012 06:41:45 -0700 (PDT)
Received: from [192.168.5.251] ([206.223.182.18])
	by mx.google.com with ESMTPS id p5sm3562270igm.13.2012.09.06.06.41.42
	(version=TLSv1/SSLv3 cipher=OTHER);
	Thu, 06 Sep 2012 06:41:44 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1278)
From: Andres Lagar-Cavilla <andreslc@gridcentric.ca>
In-Reply-To: <20120905174046.GA25535@phenom.dumpdata.com>
Date: Thu, 6 Sep 2012 09:41:44 -0400
Message-Id: <39CBBAD7-E10F-457F-BFE3-717A50D059FB@gridcentric.ca>
References: <1346331492-15027-1-git-send-email-david.vrabel@citrix.com>
	<1346331492-15027-3-git-send-email-david.vrabel@citrix.com>
	<C989BE9D-E520-4D04-9028-6CE6CC765E76@gridcentric.ca>
	<20120905162148.GC11949@phenom.dumpdata.com>
	<939BE993-572C-4D83-8F04-E6B9D6EE3E92@gridcentric.ca>
	<20120905174046.GA25535@phenom.dumpdata.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
X-Mailer: Apple Mail (2.1278)
X-Gm-Message-State: ALoCoQkyyrJc7QvU9sn2C2+trxHZfp1T3Se8kByPjEyQbpKkKvacw1t+wCAZenLtrgrSgWg+aNTG
Cc: Andres Lagar-Cavilla <andreslc@gridcentric.ca>,
	David Vrabel <david.vrabel@citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 2/2] xen/privcmd: add PRIVCMD_MMAPBATCH_V2
	ioctl
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Sep 5, 2012, at 1:40 PM, Konrad Rzeszutek Wilk wrote:

> On Wed, Sep 05, 2012 at 01:09:32PM -0400, Andres Lagar-Cavilla wrote:
>> Super. To which branch are you applying these now? (n00b question but have to ask)
> 
> They will show up on stable/for-linus-3.7 once the overnight tests pass.

I would be very surprised if this passed your nighties. This is because the following hunk is necessary:

diff --git a/drivers/xen/privcmd.c b/drivers/xen/privcmd.c
index 5386f20..e4dfa3b 100644
--- a/drivers/xen/privcmd.c
+++ b/drivers/xen/privcmd.c
@@ -389,7 +389,7 @@ static long privcmd_ioctl_mmap_batch(void __user *udata, int version)
                state.err      = err_array;
                ret = traverse_pages(m.num, sizeof(xen_pfn_t),
                                         &pagelist, mmap_return_errors_v1, &state);
-       } else
+       } else if (version == 2)
                ret = __copy_to_user(m.err, err_array, m.num * sizeof(int));
 
     /* If we have not had any EFAULT-like global errors then set the global

I can either resubmit the original patch with this squashed in, or send this stand-alone. Nightlies may have passed if your libxc never exercises v1 in favor of v2. But this is broken for v1 as it will unconditionally attempt a copy to user on a NULL target and this set rc to EFAULT.

Andres

> 
>> Andres
>> On Sep 5, 2012, at 12:21 PM, Konrad Rzeszutek Wilk wrote:
>> 
>>> On Fri, Aug 31, 2012 at 09:59:30AM -0400, Andres Lagar-Cavilla wrote:
>>>> Re-spin of alternative patch after David's feedback.
>>>> Thanks
>>>> Andres
>>> 
>>> applied. fixed some whitespace issues.
>>>> 
>>>> commit ab351a5cef1797935b083c2f6e72800a8949c515
>>>> Author: Andres Lagar-Cavilla <andres@lagarcavilla.org>
>>>> Date:   Thu Aug 30 12:23:33 2012 -0400
>>>> 
>>>>   xen/privcmd: add PRIVCMD_MMAPBATCH_V2 ioctl
>>>> 
>>>>   PRIVCMD_MMAPBATCH_V2 extends PRIVCMD_MMAPBATCH with an additional
>>>>   field for reporting the error code for every frame that could not be
>>>>   mapped.  libxc prefers PRIVCMD_MMAPBATCH_V2 over PRIVCMD_MMAPBATCH.
>>>> 
>>>>   Also expand PRIVCMD_MMAPBATCH to return appropriate error-encoding top nibble
>>>>   in the mfn array.
>>>> 
>>>>   Signed-off-by: David Vrabel <david.vrabel@citrix.com>
>>>>   Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
>>>> 
>>>> diff --git a/drivers/xen/privcmd.c b/drivers/xen/privcmd.c
>>>> index 85226cb..5386f20 100644
>>>> --- a/drivers/xen/privcmd.c
>>>> +++ b/drivers/xen/privcmd.c
>>>> @@ -76,7 +76,7 @@ static void free_page_list(struct list_head *pages)
>>>> */
>>>> static int gather_array(struct list_head *pagelist,
>>>> 			unsigned nelem, size_t size,
>>>> -			void __user *data)
>>>> +			const void __user *data)
>>>> {
>>>> 	unsigned pageidx;
>>>> 	void *pagedata;
>>>> @@ -246,61 +246,117 @@ struct mmap_batch_state {
>>>> 	domid_t domain;
>>>> 	unsigned long va;
>>>> 	struct vm_area_struct *vma;
>>>> -	int err;
>>>> -
>>>> -	xen_pfn_t __user *user;
>>>> +	/* A tristate: 
>>>> +	 *      0 for no errors
>>>> +	 *      1 if at least one error has happened (and no
>>>> +	 *          -ENOENT errors have happened)
>>>> +	 *      -ENOENT if at least 1 -ENOENT has happened.
>>>> +	 */
>>>> +	int global_error;
>>>> +	/* An array for individual errors */
>>>> +	int *err;
>>>> +
>>>> +	/* User-space mfn array to store errors in the second pass for V1. */
>>>> +	xen_pfn_t __user *user_mfn;
>>>> };
>>>> 
>>>> static int mmap_batch_fn(void *data, void *state)
>>>> {
>>>> 	xen_pfn_t *mfnp = data;
>>>> 	struct mmap_batch_state *st = state;
>>>> +	int ret;
>>>> 
>>>> -	if (xen_remap_domain_mfn_range(st->vma, st->va & PAGE_MASK, *mfnp, 1,
>>>> -				       st->vma->vm_page_prot, st->domain) < 0) {
>>>> -		*mfnp |= 0xf0000000U;
>>>> -		st->err++;
>>>> +	ret = xen_remap_domain_mfn_range(st->vma, st->va & PAGE_MASK, *mfnp, 1,
>>>> +					 st->vma->vm_page_prot, st->domain);
>>>> +
>>>> +	/* Store error code for second pass. */
>>>> +	*(st->err++) = ret;
>>>> +
>>>> +	/* And see if it affects the global_error. */
>>>> +	if (ret < 0) {
>>>> +		if (ret == -ENOENT)
>>>> +			st->global_error = -ENOENT;
>>>> +		else {
>>>> +			/* Record that at least one error has happened. */
>>>> +			if (st->global_error == 0)
>>>> +				st->global_error = 1;
>>>> +		}
>>>> 	}
>>>> 	st->va += PAGE_SIZE;
>>>> 
>>>> 	return 0;
>>>> }
>>>> 
>>>> -static int mmap_return_errors(void *data, void *state)
>>>> +static int mmap_return_errors_v1(void *data, void *state)
>>>> {
>>>> 	xen_pfn_t *mfnp = data;
>>>> 	struct mmap_batch_state *st = state;
>>>> -
>>>> -	return put_user(*mfnp, st->user++);
>>>> +	int err = *(st->err++);
>>>> +
>>>> +	/*
>>>> +	 * V1 encodes the error codes in the 32bit top nibble of the 
>>>> +	 * mfn (with its known limitations vis-a-vis 64 bit callers).
>>>> +	 */
>>>> +	*mfnp |= (err == -ENOENT) ?
>>>> +				PRIVCMD_MMAPBATCH_PAGED_ERROR :
>>>> +				PRIVCMD_MMAPBATCH_MFN_ERROR;
>>>> +	return __put_user(*mfnp, st->user_mfn++);
>>>> }
>>>> 
>>>> static struct vm_operations_struct privcmd_vm_ops;
>>>> 
>>>> -static long privcmd_ioctl_mmap_batch(void __user *udata)
>>>> +static long privcmd_ioctl_mmap_batch(void __user *udata, int version)
>>>> {
>>>> 	int ret;
>>>> -	struct privcmd_mmapbatch m;
>>>> +	struct privcmd_mmapbatch_v2 m;
>>>> 	struct mm_struct *mm = current->mm;
>>>> 	struct vm_area_struct *vma;
>>>> 	unsigned long nr_pages;
>>>> 	LIST_HEAD(pagelist);
>>>> +	int *err_array = NULL;
>>>> 	struct mmap_batch_state state;
>>>> 
>>>> 	if (!xen_initial_domain())
>>>> 		return -EPERM;
>>>> 
>>>> -	if (copy_from_user(&m, udata, sizeof(m)))
>>>> -		return -EFAULT;
>>>> +	switch (version) {
>>>> +	case 1:
>>>> +		if (copy_from_user(&m, udata, sizeof(struct privcmd_mmapbatch)))
>>>> +			return -EFAULT;
>>>> +		/* Returns per-frame error in m.arr. */
>>>> +		m.err = NULL;
>>>> +		if (!access_ok(VERIFY_WRITE, m.arr, m.num * sizeof(*m.arr)))
>>>> +			return -EFAULT;
>>>> +		break;
>>>> +	case 2:
>>>> +		if (copy_from_user(&m, udata, sizeof(struct privcmd_mmapbatch_v2)))
>>>> +			return -EFAULT;
>>>> +		/* Returns per-frame error code in m.err. */
>>>> +		if (!access_ok(VERIFY_WRITE, m.err, m.num * (sizeof(*m.err))))
>>>> +			return -EFAULT;
>>>> +		break;
>>>> +	default:
>>>> +		return -EINVAL;
>>>> +	}
>>>> 
>>>> 	nr_pages = m.num;
>>>> 	if ((m.num <= 0) || (nr_pages > (LONG_MAX >> PAGE_SHIFT)))
>>>> 		return -EINVAL;
>>>> 
>>>> -	ret = gather_array(&pagelist, m.num, sizeof(xen_pfn_t),
>>>> -			   m.arr);
>>>> +	ret = gather_array(&pagelist, m.num, sizeof(xen_pfn_t), m.arr);
>>>> +
>>>> +	if (ret)
>>>> +		goto out;
>>>> +	if (list_empty(&pagelist)) {
>>>> +		ret = -EINVAL;
>>>> +		goto out;
>>>> +    }
>>>> 
>>>> -	if (ret || list_empty(&pagelist))
>>>> +	err_array = kcalloc(m.num, sizeof(int), GFP_KERNEL);
>>>> +	if (err_array == NULL) {
>>>> +		ret = -ENOMEM;
>>>> 		goto out;
>>>> +	}
>>>> 
>>>> 	down_write(&mm->mmap_sem);
>>>> 
>>>> @@ -315,24 +371,34 @@ static long privcmd_ioctl_mmap_batch(void __user *udata)
>>>> 		goto out;
>>>> 	}
>>>> 
>>>> -	state.domain = m.dom;
>>>> -	state.vma = vma;
>>>> -	state.va = m.addr;
>>>> -	state.err = 0;
>>>> +	state.domain        = m.dom;
>>>> +	state.vma           = vma;
>>>> +	state.va            = m.addr;
>>>> +	state.global_error  = 0;
>>>> +	state.err           = err_array;
>>>> 
>>>> -	ret = traverse_pages(m.num, sizeof(xen_pfn_t),
>>>> -			     &pagelist, mmap_batch_fn, &state);
>>>> +	/* mmap_batch_fn guarantees ret == 0 */
>>>> +	BUG_ON(traverse_pages(m.num, sizeof(xen_pfn_t),
>>>> +			     &pagelist, mmap_batch_fn, &state));
>>>> 
>>>> 	up_write(&mm->mmap_sem);
>>>> 
>>>> -	if (state.err > 0) {
>>>> -		state.user = m.arr;
>>>> +	if (state.global_error && (version == 1)) {
>>>> +		/* Write back errors in second pass. */
>>>> +		state.user_mfn = (xen_pfn_t *)m.arr;
>>>> +		state.err      = err_array;
>>>> 		ret = traverse_pages(m.num, sizeof(xen_pfn_t),
>>>> -			       &pagelist,
>>>> -			       mmap_return_errors, &state);
>>>> -	}
>>>> +					 &pagelist, mmap_return_errors_v1, &state);
>>>> +	} else
>>>> +		ret = __copy_to_user(m.err, err_array, m.num * sizeof(int));
>>>> +
>>>> +    /* If we have not had any EFAULT-like global errors then set the global
>>>> +     * error to -ENOENT if necessary. */
>>>> +    if ((ret == 0) && (state.global_error == -ENOENT))
>>>> +        ret = -ENOENT;
>>>> 
>>>> out:
>>>> +	kfree(err_array);
>>>> 	free_page_list(&pagelist);
>>>> 
>>>> 	return ret;
>>>> @@ -354,7 +420,11 @@ static long privcmd_ioctl(struct file *file,
>>>> 		break;
>>>> 
>>>> 	case IOCTL_PRIVCMD_MMAPBATCH:
>>>> -		ret = privcmd_ioctl_mmap_batch(udata);
>>>> +		ret = privcmd_ioctl_mmap_batch(udata, 1);
>>>> +		break;
>>>> +
>>>> +	case IOCTL_PRIVCMD_MMAPBATCH_V2:
>>>> +		ret = privcmd_ioctl_mmap_batch(udata, 2);
>>>> 		break;
>>>> 
>>>> 	default:
>>>> diff --git a/include/xen/privcmd.h b/include/xen/privcmd.h
>>>> index 45c1aa1..a853168 100644
>>>> --- a/include/xen/privcmd.h
>>>> +++ b/include/xen/privcmd.h
>>>> @@ -58,13 +58,33 @@ struct privcmd_mmapbatch {
>>>> 	int num;     /* number of pages to populate */
>>>> 	domid_t dom; /* target domain */
>>>> 	__u64 addr;  /* virtual address */
>>>> -	xen_pfn_t __user *arr; /* array of mfns - top nibble set on err */
>>>> +	xen_pfn_t __user *arr; /* array of mfns - or'd with
>>>> +				  PRIVCMD_MMAPBATCH_*_ERROR on err */
>>>> +};
>>>> +
>>>> +#define PRIVCMD_MMAPBATCH_MFN_ERROR     0xf0000000U
>>>> +#define PRIVCMD_MMAPBATCH_PAGED_ERROR   0x80000000U
>>>> +
>>>> +struct privcmd_mmapbatch_v2 {
>>>> +	unsigned int num; /* number of pages to populate */
>>>> +	domid_t dom;      /* target domain */
>>>> +	__u64 addr;       /* virtual address */
>>>> +	const xen_pfn_t __user *arr; /* array of mfns */
>>>> +	int __user *err;  /* array of error codes */
>>>> };
>>>> 
>>>> /*
>>>> * @cmd: IOCTL_PRIVCMD_HYPERCALL
>>>> * @arg: &privcmd_hypercall_t
>>>> * Return: Value returned from execution of the specified hypercall.
>>>> + *
>>>> + * @cmd: IOCTL_PRIVCMD_MMAPBATCH_V2
>>>> + * @arg: &struct privcmd_mmapbatch_v2
>>>> + * Return: 0 on success (i.e., arg->err contains valid error codes for
>>>> + * each frame).  On an error other than a failed frame remap, -1 is
>>>> + * returned and errno is set to EINVAL, EFAULT etc.  As an exception,
>>>> + * if the operation was otherwise successful but any frame failed with
>>>> + * -ENOENT, then -1 is returned and errno is set to ENOENT.
>>>> */
>>>> #define IOCTL_PRIVCMD_HYPERCALL					\
>>>> 	_IOC(_IOC_NONE, 'P', 0, sizeof(struct privcmd_hypercall))
>>>> @@ -72,5 +92,7 @@ struct privcmd_mmapbatch {
>>>> 	_IOC(_IOC_NONE, 'P', 2, sizeof(struct privcmd_mmap))
>>>> #define IOCTL_PRIVCMD_MMAPBATCH					\
>>>> 	_IOC(_IOC_NONE, 'P', 3, sizeof(struct privcmd_mmapbatch))
>>>> +#define IOCTL_PRIVCMD_MMAPBATCH_V2				\
>>>> +	_IOC(_IOC_NONE, 'P', 4, sizeof(struct privcmd_mmapbatch_v2))
>>>> 
>>>> #endif /* __LINUX_PUBLIC_PRIVCMD_H__ */
>>>> 
>>>> On Aug 30, 2012, at 8:58 AM, David Vrabel wrote:
>>>> 
>>>>> From: David Vrabel <david.vrabel@citrix.com>
>>>>> 
>>>>> PRIVCMD_MMAPBATCH_V2 extends PRIVCMD_MMAPBATCH with an additional
>>>>> field for reporting the error code for every frame that could not be
>>>>> mapped.  libxc prefers PRIVCMD_MMAPBATCH_V2 over PRIVCMD_MMAPBATCH.
>>>>> 
>>>>> Signed-off-by: David Vrabel <david.vrabel@citrix.com>
>>>>> ---
>>>>> drivers/xen/privcmd.c |   99 +++++++++++++++++++++++++++++++++++++++---------
>>>>> include/xen/privcmd.h |   23 +++++++++++-
>>>>> 2 files changed, 102 insertions(+), 20 deletions(-)
>>>>> 
>>>>> diff --git a/drivers/xen/privcmd.c b/drivers/xen/privcmd.c
>>>>> index ccee0f1..c0e89e7 100644
>>>>> --- a/drivers/xen/privcmd.c
>>>>> +++ b/drivers/xen/privcmd.c
>>>>> @@ -76,7 +76,7 @@ static void free_page_list(struct list_head *pages)
>>>>> */
>>>>> static int gather_array(struct list_head *pagelist,
>>>>> 			unsigned nelem, size_t size,
>>>>> -			void __user *data)
>>>>> +			const void __user *data)
>>>>> {
>>>>> 	unsigned pageidx;
>>>>> 	void *pagedata;
>>>>> @@ -248,18 +248,37 @@ struct mmap_batch_state {
>>>>> 	struct vm_area_struct *vma;
>>>>> 	int err;
>>>>> 
>>>>> -	xen_pfn_t __user *user;
>>>>> +	xen_pfn_t __user *user_mfn;
>>>>> +	int __user *user_err;
>>>>> };
>>>>> 
>>>>> static int mmap_batch_fn(void *data, void *state)
>>>>> {
>>>>> 	xen_pfn_t *mfnp = data;
>>>>> 	struct mmap_batch_state *st = state;
>>>>> +	int ret;
>>>>> 
>>>>> -	if (xen_remap_domain_mfn_range(st->vma, st->va & PAGE_MASK, *mfnp, 1,
>>>>> -				       st->vma->vm_page_prot, st->domain) < 0) {
>>>>> -		*mfnp |= 0xf0000000U;
>>>>> -		st->err++;
>>>>> +	ret = xen_remap_domain_mfn_range(st->vma, st->va & PAGE_MASK, *mfnp, 1,
>>>>> +					 st->vma->vm_page_prot, st->domain);
>>>>> +	if (ret < 0) {
>>>>> +		/*
>>>>> +		 * Error reporting is a mess but userspace relies on
>>>>> +		 * it behaving this way.
>>>>> +		 *
>>>>> +		 * V2 needs to a) return the result of each frame's
>>>>> +		 * remap; and b) return -ENOENT if any frame failed
>>>>> +		 * with -ENOENT.
>>>>> +		 *
>>>>> +		 * In this first pass the error code is saved by
>>>>> +		 * overwriting the mfn and an error is indicated in
>>>>> +		 * st->err.
>>>>> +		 *
>>>>> +		 * The second pass by mmap_return_errors() will write
>>>>> +		 * the error codes to user space and get the right
>>>>> +		 * ioctl return value.
>>>>> +		 */
>>>>> +		*(int *)mfnp = ret;
>>>>> +		st->err = ret;
>>>>> 	}
>>>>> 	st->va += PAGE_SIZE;
>>>>> 
>>>>> @@ -270,16 +289,33 @@ static int mmap_return_errors(void *data, void *state)
>>>>> {
>>>>> 	xen_pfn_t *mfnp = data;
>>>>> 	struct mmap_batch_state *st = state;
>>>>> +	int ret;
>>>>> +
>>>>> +	if (st->user_err) {
>>>>> +		int err = *(int *)mfnp;
>>>>> +
>>>>> +		if (err == -ENOENT)
>>>>> +			st->err = err;
>>>>> 
>>>>> -	return put_user(*mfnp, st->user++);
>>>>> +		return __put_user(err, st->user_err++);
>>>>> +	} else {
>>>>> +		xen_pfn_t mfn;
>>>>> +
>>>>> +		ret = __get_user(mfn, st->user_mfn);
>>>>> +		if (ret < 0)
>>>>> +			return ret;
>>>>> +
>>>>> +		mfn |= PRIVCMD_MMAPBATCH_MFN_ERROR;
>>>>> +		return __put_user(mfn, st->user_mfn++);
>>>>> +	}
>>>>> }
>>>>> 
>>>>> static struct vm_operations_struct privcmd_vm_ops;
>>>>> 
>>>>> -static long privcmd_ioctl_mmap_batch(void __user *udata)
>>>>> +static long privcmd_ioctl_mmap_batch(void __user *udata, int version)
>>>>> {
>>>>> 	int ret;
>>>>> -	struct privcmd_mmapbatch m;
>>>>> +	struct privcmd_mmapbatch_v2 m;
>>>>> 	struct mm_struct *mm = current->mm;
>>>>> 	struct vm_area_struct *vma;
>>>>> 	unsigned long nr_pages;
>>>>> @@ -289,15 +325,31 @@ static long privcmd_ioctl_mmap_batch(void __user *udata)
>>>>> 	if (!xen_initial_domain())
>>>>> 		return -EPERM;
>>>>> 
>>>>> -	if (copy_from_user(&m, udata, sizeof(m)))
>>>>> -		return -EFAULT;
>>>>> +	switch (version) {
>>>>> +	case 1:
>>>>> +		if (copy_from_user(&m, udata, sizeof(struct privcmd_mmapbatch)))
>>>>> +			return -EFAULT;
>>>>> +		/* Returns per-frame error in m.arr. */
>>>>> +		m.err = NULL;
>>>>> +		if (!access_ok(VERIFY_WRITE, m.arr, m.num * sizeof(*m.arr)))
>>>>> +			return -EFAULT;
>>>>> +		break;
>>>>> +	case 2:
>>>>> +		if (copy_from_user(&m, udata, sizeof(struct privcmd_mmapbatch_v2)))
>>>>> +			return -EFAULT;
>>>>> +		/* Returns per-frame error code in m.err. */
>>>>> +		if (!access_ok(VERIFY_WRITE, m.err, m.num * (sizeof(*m.err))))
>>>>> +			return -EFAULT;
>>>>> +		break;
>>>>> +	default:
>>>>> +		return -EINVAL;
>>>>> +	}
>>>>> 
>>>>> 	nr_pages = m.num;
>>>>> 	if ((m.num <= 0) || (nr_pages > (LONG_MAX >> PAGE_SHIFT)))
>>>>> 		return -EINVAL;
>>>>> 
>>>>> -	ret = gather_array(&pagelist, m.num, sizeof(xen_pfn_t),
>>>>> -			   m.arr);
>>>>> +	ret = gather_array(&pagelist, m.num, sizeof(xen_pfn_t), m.arr);
>>>>> 
>>>>> 	if (ret || list_empty(&pagelist))
>>>>> 		goto out;
>>>>> @@ -325,12 +377,17 @@ static long privcmd_ioctl_mmap_batch(void __user *udata)
>>>>> 
>>>>> 	up_write(&mm->mmap_sem);
>>>>> 
>>>>> -	if (state.err > 0) {
>>>>> -		state.user = m.arr;
>>>>> +	if (state.err) {
>>>>> +		state.err = 0;
>>>>> +		state.user_mfn = (xen_pfn_t *)m.arr;
>>>>> +		state.user_err = m.err;
>>>>> 		ret = traverse_pages(m.num, sizeof(xen_pfn_t),
>>>>> -			       &pagelist,
>>>>> -			       mmap_return_errors, &state);
>>>>> -	}
>>>>> +				     &pagelist,
>>>>> +				     mmap_return_errors, &state);
>>>>> +		if (ret >= 0)
>>>>> +			ret = state.err;
>>>>> +	} else if (m.err)
>>>>> +		__clear_user(m.err, m.num * sizeof(*m.err));
>>>>> 
>>>>> out:
>>>>> 	free_page_list(&pagelist);
>>>>> @@ -354,7 +411,11 @@ static long privcmd_ioctl(struct file *file,
>>>>> 		break;
>>>>> 
>>>>> 	case IOCTL_PRIVCMD_MMAPBATCH:
>>>>> -		ret = privcmd_ioctl_mmap_batch(udata);
>>>>> +		ret = privcmd_ioctl_mmap_batch(udata, 1);
>>>>> +		break;
>>>>> +
>>>>> +	case IOCTL_PRIVCMD_MMAPBATCH_V2:
>>>>> +		ret = privcmd_ioctl_mmap_batch(udata, 2);
>>>>> 		break;
>>>>> 
>>>>> 	default:
>>>>> diff --git a/include/xen/privcmd.h b/include/xen/privcmd.h
>>>>> index 17857fb..f60d75c 100644
>>>>> --- a/include/xen/privcmd.h
>>>>> +++ b/include/xen/privcmd.h
>>>>> @@ -59,13 +59,32 @@ struct privcmd_mmapbatch {
>>>>> 	int num;     /* number of pages to populate */
>>>>> 	domid_t dom; /* target domain */
>>>>> 	__u64 addr;  /* virtual address */
>>>>> -	xen_pfn_t __user *arr; /* array of mfns - top nibble set on err */
>>>>> +	xen_pfn_t __user *arr; /* array of mfns - or'd with
>>>>> +				  PRIVCMD_MMAPBATCH_MFN_ERROR on err */
>>>>> +};
>>>>> +
>>>>> +#define PRIVCMD_MMAPBATCH_MFN_ERROR 0xf0000000U
>>>>> +
>>>>> +struct privcmd_mmapbatch_v2 {
>>>>> +	unsigned int num; /* number of pages to populate */
>>>>> +	domid_t dom;      /* target domain */
>>>>> +	__u64 addr;       /* virtual address */
>>>>> +	const xen_pfn_t __user *arr; /* array of mfns */
>>>>> +	int __user *err;  /* array of error codes */
>>>>> };
>>>>> 
>>>>> /*
>>>>> * @cmd: IOCTL_PRIVCMD_HYPERCALL
>>>>> * @arg: &privcmd_hypercall_t
>>>>> * Return: Value returned from execution of the specified hypercall.
>>>>> + *
>>>>> + * @cmd: IOCTL_PRIVCMD_MMAPBATCH_V2
>>>>> + * @arg: &struct privcmd_mmapbatch_v2
>>>>> + * Return: 0 on success (i.e., arg->err contains valid error codes for
>>>>> + * each frame).  On an error other than a failed frame remap, -1 is
>>>>> + * returned and errno is set to EINVAL, EFAULT etc.  As an exception,
>>>>> + * if the operation was otherwise successful but any frame failed with
>>>>> + * -ENOENT, then -1 is returned and errno is set to ENOENT.
>>>>> */
>>>>> #define IOCTL_PRIVCMD_HYPERCALL					\
>>>>> 	_IOC(_IOC_NONE, 'P', 0, sizeof(struct privcmd_hypercall))
>>>>> @@ -73,5 +92,7 @@ struct privcmd_mmapbatch {
>>>>> 	_IOC(_IOC_NONE, 'P', 2, sizeof(struct privcmd_mmap))
>>>>> #define IOCTL_PRIVCMD_MMAPBATCH					\
>>>>> 	_IOC(_IOC_NONE, 'P', 3, sizeof(struct privcmd_mmapbatch))
>>>>> +#define IOCTL_PRIVCMD_MMAPBATCH_V2				\
>>>>> +	_IOC(_IOC_NONE, 'P', 4, sizeof(struct privcmd_mmapbatch_v2))
>>>>> 
>>>>> #endif /* __LINUX_PUBLIC_PRIVCMD_H__ */
>>>>> -- 
>>>>> 1.7.2.5
>>>>> 


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

From xen-devel-bounces@lists.xen.org Thu Sep 06 13:42:00 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 2012 13:42:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9cLB-0003tF-2S; Thu, 06 Sep 2012 13:41:53 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andreslc@gridcentric.ca>) id 1T9cL8-0003ss-2j
	for xen-devel@lists.xen.org; Thu, 06 Sep 2012 13:41:51 +0000
Received: from [85.158.138.51:47081] by server-10.bemta-3.messagelabs.com id
	E7/54-10411-D18A8405; Thu, 06 Sep 2012 13:41:49 +0000
X-Env-Sender: andreslc@gridcentric.ca
X-Msg-Ref: server-3.tower-174.messagelabs.com!1346938906!20980376!1
X-Originating-IP: [209.85.223.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11563 invoked from network); 6 Sep 2012 13:41:47 -0000
Received: from mail-ie0-f173.google.com (HELO mail-ie0-f173.google.com)
	(209.85.223.173)
	by server-3.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Sep 2012 13:41:47 -0000
Received: by iebc10 with SMTP id c10so3705690ieb.32
	for <xen-devel@lists.xen.org>; Thu, 06 Sep 2012 06:41:45 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=subject:mime-version:content-type:from:in-reply-to:date:cc
	:content-transfer-encoding:message-id:references:to:x-mailer
	:x-gm-message-state;
	bh=MyBgE1ElmJSLQ7p07GVKmGblLfWB/YYAZKmNYGiGHn4=;
	b=BVaCPstkqlGiO+ibGLLXH8/eyMEQsXBGYE1btBSW4r0GBrLUpZrr/OAG2EhOhrZpqE
	AAQQxz6/NH48aU7eipoA4+L/tOuLWd46jMkZ4CZqj7wwOY5thhbdAE6OZ7bXzm3JwWPc
	niRlbXw2OVaS8woloNQIh+1F2Hc8IXcMTJreRZncZGNCX1b8VNk3K7g2+TlBQ6CK1jAZ
	hKzvHUxNauFzl7aS2okk3N17Q1TN5JQIq04xNTFJPb3rIpNvrBuBkOr0RFU0kw0FZyM/
	kIbhoinMA6HIA3DqmmQIu4O2DvpnnW6DgIOjDRiwWwDs1IaMmM3vwU8VbpL8W4oxPH3E
	Z4sw==
Received: by 10.50.209.41 with SMTP id mj9mr3026186igc.23.1346938905840;
	Thu, 06 Sep 2012 06:41:45 -0700 (PDT)
Received: from [192.168.5.251] ([206.223.182.18])
	by mx.google.com with ESMTPS id p5sm3562270igm.13.2012.09.06.06.41.42
	(version=TLSv1/SSLv3 cipher=OTHER);
	Thu, 06 Sep 2012 06:41:44 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1278)
From: Andres Lagar-Cavilla <andreslc@gridcentric.ca>
In-Reply-To: <20120905174046.GA25535@phenom.dumpdata.com>
Date: Thu, 6 Sep 2012 09:41:44 -0400
Message-Id: <39CBBAD7-E10F-457F-BFE3-717A50D059FB@gridcentric.ca>
References: <1346331492-15027-1-git-send-email-david.vrabel@citrix.com>
	<1346331492-15027-3-git-send-email-david.vrabel@citrix.com>
	<C989BE9D-E520-4D04-9028-6CE6CC765E76@gridcentric.ca>
	<20120905162148.GC11949@phenom.dumpdata.com>
	<939BE993-572C-4D83-8F04-E6B9D6EE3E92@gridcentric.ca>
	<20120905174046.GA25535@phenom.dumpdata.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
X-Mailer: Apple Mail (2.1278)
X-Gm-Message-State: ALoCoQkyyrJc7QvU9sn2C2+trxHZfp1T3Se8kByPjEyQbpKkKvacw1t+wCAZenLtrgrSgWg+aNTG
Cc: Andres Lagar-Cavilla <andreslc@gridcentric.ca>,
	David Vrabel <david.vrabel@citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 2/2] xen/privcmd: add PRIVCMD_MMAPBATCH_V2
	ioctl
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Sep 5, 2012, at 1:40 PM, Konrad Rzeszutek Wilk wrote:

> On Wed, Sep 05, 2012 at 01:09:32PM -0400, Andres Lagar-Cavilla wrote:
>> Super. To which branch are you applying these now? (n00b question but have to ask)
> 
> They will show up on stable/for-linus-3.7 once the overnight tests pass.

I would be very surprised if this passed your nighties. This is because the following hunk is necessary:

diff --git a/drivers/xen/privcmd.c b/drivers/xen/privcmd.c
index 5386f20..e4dfa3b 100644
--- a/drivers/xen/privcmd.c
+++ b/drivers/xen/privcmd.c
@@ -389,7 +389,7 @@ static long privcmd_ioctl_mmap_batch(void __user *udata, int version)
                state.err      = err_array;
                ret = traverse_pages(m.num, sizeof(xen_pfn_t),
                                         &pagelist, mmap_return_errors_v1, &state);
-       } else
+       } else if (version == 2)
                ret = __copy_to_user(m.err, err_array, m.num * sizeof(int));
 
     /* If we have not had any EFAULT-like global errors then set the global

I can either resubmit the original patch with this squashed in, or send this stand-alone. Nightlies may have passed if your libxc never exercises v1 in favor of v2. But this is broken for v1 as it will unconditionally attempt a copy to user on a NULL target and this set rc to EFAULT.

Andres

> 
>> Andres
>> On Sep 5, 2012, at 12:21 PM, Konrad Rzeszutek Wilk wrote:
>> 
>>> On Fri, Aug 31, 2012 at 09:59:30AM -0400, Andres Lagar-Cavilla wrote:
>>>> Re-spin of alternative patch after David's feedback.
>>>> Thanks
>>>> Andres
>>> 
>>> applied. fixed some whitespace issues.
>>>> 
>>>> commit ab351a5cef1797935b083c2f6e72800a8949c515
>>>> Author: Andres Lagar-Cavilla <andres@lagarcavilla.org>
>>>> Date:   Thu Aug 30 12:23:33 2012 -0400
>>>> 
>>>>   xen/privcmd: add PRIVCMD_MMAPBATCH_V2 ioctl
>>>> 
>>>>   PRIVCMD_MMAPBATCH_V2 extends PRIVCMD_MMAPBATCH with an additional
>>>>   field for reporting the error code for every frame that could not be
>>>>   mapped.  libxc prefers PRIVCMD_MMAPBATCH_V2 over PRIVCMD_MMAPBATCH.
>>>> 
>>>>   Also expand PRIVCMD_MMAPBATCH to return appropriate error-encoding top nibble
>>>>   in the mfn array.
>>>> 
>>>>   Signed-off-by: David Vrabel <david.vrabel@citrix.com>
>>>>   Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
>>>> 
>>>> diff --git a/drivers/xen/privcmd.c b/drivers/xen/privcmd.c
>>>> index 85226cb..5386f20 100644
>>>> --- a/drivers/xen/privcmd.c
>>>> +++ b/drivers/xen/privcmd.c
>>>> @@ -76,7 +76,7 @@ static void free_page_list(struct list_head *pages)
>>>> */
>>>> static int gather_array(struct list_head *pagelist,
>>>> 			unsigned nelem, size_t size,
>>>> -			void __user *data)
>>>> +			const void __user *data)
>>>> {
>>>> 	unsigned pageidx;
>>>> 	void *pagedata;
>>>> @@ -246,61 +246,117 @@ struct mmap_batch_state {
>>>> 	domid_t domain;
>>>> 	unsigned long va;
>>>> 	struct vm_area_struct *vma;
>>>> -	int err;
>>>> -
>>>> -	xen_pfn_t __user *user;
>>>> +	/* A tristate: 
>>>> +	 *      0 for no errors
>>>> +	 *      1 if at least one error has happened (and no
>>>> +	 *          -ENOENT errors have happened)
>>>> +	 *      -ENOENT if at least 1 -ENOENT has happened.
>>>> +	 */
>>>> +	int global_error;
>>>> +	/* An array for individual errors */
>>>> +	int *err;
>>>> +
>>>> +	/* User-space mfn array to store errors in the second pass for V1. */
>>>> +	xen_pfn_t __user *user_mfn;
>>>> };
>>>> 
>>>> static int mmap_batch_fn(void *data, void *state)
>>>> {
>>>> 	xen_pfn_t *mfnp = data;
>>>> 	struct mmap_batch_state *st = state;
>>>> +	int ret;
>>>> 
>>>> -	if (xen_remap_domain_mfn_range(st->vma, st->va & PAGE_MASK, *mfnp, 1,
>>>> -				       st->vma->vm_page_prot, st->domain) < 0) {
>>>> -		*mfnp |= 0xf0000000U;
>>>> -		st->err++;
>>>> +	ret = xen_remap_domain_mfn_range(st->vma, st->va & PAGE_MASK, *mfnp, 1,
>>>> +					 st->vma->vm_page_prot, st->domain);
>>>> +
>>>> +	/* Store error code for second pass. */
>>>> +	*(st->err++) = ret;
>>>> +
>>>> +	/* And see if it affects the global_error. */
>>>> +	if (ret < 0) {
>>>> +		if (ret == -ENOENT)
>>>> +			st->global_error = -ENOENT;
>>>> +		else {
>>>> +			/* Record that at least one error has happened. */
>>>> +			if (st->global_error == 0)
>>>> +				st->global_error = 1;
>>>> +		}
>>>> 	}
>>>> 	st->va += PAGE_SIZE;
>>>> 
>>>> 	return 0;
>>>> }
>>>> 
>>>> -static int mmap_return_errors(void *data, void *state)
>>>> +static int mmap_return_errors_v1(void *data, void *state)
>>>> {
>>>> 	xen_pfn_t *mfnp = data;
>>>> 	struct mmap_batch_state *st = state;
>>>> -
>>>> -	return put_user(*mfnp, st->user++);
>>>> +	int err = *(st->err++);
>>>> +
>>>> +	/*
>>>> +	 * V1 encodes the error codes in the 32bit top nibble of the 
>>>> +	 * mfn (with its known limitations vis-a-vis 64 bit callers).
>>>> +	 */
>>>> +	*mfnp |= (err == -ENOENT) ?
>>>> +				PRIVCMD_MMAPBATCH_PAGED_ERROR :
>>>> +				PRIVCMD_MMAPBATCH_MFN_ERROR;
>>>> +	return __put_user(*mfnp, st->user_mfn++);
>>>> }
>>>> 
>>>> static struct vm_operations_struct privcmd_vm_ops;
>>>> 
>>>> -static long privcmd_ioctl_mmap_batch(void __user *udata)
>>>> +static long privcmd_ioctl_mmap_batch(void __user *udata, int version)
>>>> {
>>>> 	int ret;
>>>> -	struct privcmd_mmapbatch m;
>>>> +	struct privcmd_mmapbatch_v2 m;
>>>> 	struct mm_struct *mm = current->mm;
>>>> 	struct vm_area_struct *vma;
>>>> 	unsigned long nr_pages;
>>>> 	LIST_HEAD(pagelist);
>>>> +	int *err_array = NULL;
>>>> 	struct mmap_batch_state state;
>>>> 
>>>> 	if (!xen_initial_domain())
>>>> 		return -EPERM;
>>>> 
>>>> -	if (copy_from_user(&m, udata, sizeof(m)))
>>>> -		return -EFAULT;
>>>> +	switch (version) {
>>>> +	case 1:
>>>> +		if (copy_from_user(&m, udata, sizeof(struct privcmd_mmapbatch)))
>>>> +			return -EFAULT;
>>>> +		/* Returns per-frame error in m.arr. */
>>>> +		m.err = NULL;
>>>> +		if (!access_ok(VERIFY_WRITE, m.arr, m.num * sizeof(*m.arr)))
>>>> +			return -EFAULT;
>>>> +		break;
>>>> +	case 2:
>>>> +		if (copy_from_user(&m, udata, sizeof(struct privcmd_mmapbatch_v2)))
>>>> +			return -EFAULT;
>>>> +		/* Returns per-frame error code in m.err. */
>>>> +		if (!access_ok(VERIFY_WRITE, m.err, m.num * (sizeof(*m.err))))
>>>> +			return -EFAULT;
>>>> +		break;
>>>> +	default:
>>>> +		return -EINVAL;
>>>> +	}
>>>> 
>>>> 	nr_pages = m.num;
>>>> 	if ((m.num <= 0) || (nr_pages > (LONG_MAX >> PAGE_SHIFT)))
>>>> 		return -EINVAL;
>>>> 
>>>> -	ret = gather_array(&pagelist, m.num, sizeof(xen_pfn_t),
>>>> -			   m.arr);
>>>> +	ret = gather_array(&pagelist, m.num, sizeof(xen_pfn_t), m.arr);
>>>> +
>>>> +	if (ret)
>>>> +		goto out;
>>>> +	if (list_empty(&pagelist)) {
>>>> +		ret = -EINVAL;
>>>> +		goto out;
>>>> +    }
>>>> 
>>>> -	if (ret || list_empty(&pagelist))
>>>> +	err_array = kcalloc(m.num, sizeof(int), GFP_KERNEL);
>>>> +	if (err_array == NULL) {
>>>> +		ret = -ENOMEM;
>>>> 		goto out;
>>>> +	}
>>>> 
>>>> 	down_write(&mm->mmap_sem);
>>>> 
>>>> @@ -315,24 +371,34 @@ static long privcmd_ioctl_mmap_batch(void __user *udata)
>>>> 		goto out;
>>>> 	}
>>>> 
>>>> -	state.domain = m.dom;
>>>> -	state.vma = vma;
>>>> -	state.va = m.addr;
>>>> -	state.err = 0;
>>>> +	state.domain        = m.dom;
>>>> +	state.vma           = vma;
>>>> +	state.va            = m.addr;
>>>> +	state.global_error  = 0;
>>>> +	state.err           = err_array;
>>>> 
>>>> -	ret = traverse_pages(m.num, sizeof(xen_pfn_t),
>>>> -			     &pagelist, mmap_batch_fn, &state);
>>>> +	/* mmap_batch_fn guarantees ret == 0 */
>>>> +	BUG_ON(traverse_pages(m.num, sizeof(xen_pfn_t),
>>>> +			     &pagelist, mmap_batch_fn, &state));
>>>> 
>>>> 	up_write(&mm->mmap_sem);
>>>> 
>>>> -	if (state.err > 0) {
>>>> -		state.user = m.arr;
>>>> +	if (state.global_error && (version == 1)) {
>>>> +		/* Write back errors in second pass. */
>>>> +		state.user_mfn = (xen_pfn_t *)m.arr;
>>>> +		state.err      = err_array;
>>>> 		ret = traverse_pages(m.num, sizeof(xen_pfn_t),
>>>> -			       &pagelist,
>>>> -			       mmap_return_errors, &state);
>>>> -	}
>>>> +					 &pagelist, mmap_return_errors_v1, &state);
>>>> +	} else
>>>> +		ret = __copy_to_user(m.err, err_array, m.num * sizeof(int));
>>>> +
>>>> +    /* If we have not had any EFAULT-like global errors then set the global
>>>> +     * error to -ENOENT if necessary. */
>>>> +    if ((ret == 0) && (state.global_error == -ENOENT))
>>>> +        ret = -ENOENT;
>>>> 
>>>> out:
>>>> +	kfree(err_array);
>>>> 	free_page_list(&pagelist);
>>>> 
>>>> 	return ret;
>>>> @@ -354,7 +420,11 @@ static long privcmd_ioctl(struct file *file,
>>>> 		break;
>>>> 
>>>> 	case IOCTL_PRIVCMD_MMAPBATCH:
>>>> -		ret = privcmd_ioctl_mmap_batch(udata);
>>>> +		ret = privcmd_ioctl_mmap_batch(udata, 1);
>>>> +		break;
>>>> +
>>>> +	case IOCTL_PRIVCMD_MMAPBATCH_V2:
>>>> +		ret = privcmd_ioctl_mmap_batch(udata, 2);
>>>> 		break;
>>>> 
>>>> 	default:
>>>> diff --git a/include/xen/privcmd.h b/include/xen/privcmd.h
>>>> index 45c1aa1..a853168 100644
>>>> --- a/include/xen/privcmd.h
>>>> +++ b/include/xen/privcmd.h
>>>> @@ -58,13 +58,33 @@ struct privcmd_mmapbatch {
>>>> 	int num;     /* number of pages to populate */
>>>> 	domid_t dom; /* target domain */
>>>> 	__u64 addr;  /* virtual address */
>>>> -	xen_pfn_t __user *arr; /* array of mfns - top nibble set on err */
>>>> +	xen_pfn_t __user *arr; /* array of mfns - or'd with
>>>> +				  PRIVCMD_MMAPBATCH_*_ERROR on err */
>>>> +};
>>>> +
>>>> +#define PRIVCMD_MMAPBATCH_MFN_ERROR     0xf0000000U
>>>> +#define PRIVCMD_MMAPBATCH_PAGED_ERROR   0x80000000U
>>>> +
>>>> +struct privcmd_mmapbatch_v2 {
>>>> +	unsigned int num; /* number of pages to populate */
>>>> +	domid_t dom;      /* target domain */
>>>> +	__u64 addr;       /* virtual address */
>>>> +	const xen_pfn_t __user *arr; /* array of mfns */
>>>> +	int __user *err;  /* array of error codes */
>>>> };
>>>> 
>>>> /*
>>>> * @cmd: IOCTL_PRIVCMD_HYPERCALL
>>>> * @arg: &privcmd_hypercall_t
>>>> * Return: Value returned from execution of the specified hypercall.
>>>> + *
>>>> + * @cmd: IOCTL_PRIVCMD_MMAPBATCH_V2
>>>> + * @arg: &struct privcmd_mmapbatch_v2
>>>> + * Return: 0 on success (i.e., arg->err contains valid error codes for
>>>> + * each frame).  On an error other than a failed frame remap, -1 is
>>>> + * returned and errno is set to EINVAL, EFAULT etc.  As an exception,
>>>> + * if the operation was otherwise successful but any frame failed with
>>>> + * -ENOENT, then -1 is returned and errno is set to ENOENT.
>>>> */
>>>> #define IOCTL_PRIVCMD_HYPERCALL					\
>>>> 	_IOC(_IOC_NONE, 'P', 0, sizeof(struct privcmd_hypercall))
>>>> @@ -72,5 +92,7 @@ struct privcmd_mmapbatch {
>>>> 	_IOC(_IOC_NONE, 'P', 2, sizeof(struct privcmd_mmap))
>>>> #define IOCTL_PRIVCMD_MMAPBATCH					\
>>>> 	_IOC(_IOC_NONE, 'P', 3, sizeof(struct privcmd_mmapbatch))
>>>> +#define IOCTL_PRIVCMD_MMAPBATCH_V2				\
>>>> +	_IOC(_IOC_NONE, 'P', 4, sizeof(struct privcmd_mmapbatch_v2))
>>>> 
>>>> #endif /* __LINUX_PUBLIC_PRIVCMD_H__ */
>>>> 
>>>> On Aug 30, 2012, at 8:58 AM, David Vrabel wrote:
>>>> 
>>>>> From: David Vrabel <david.vrabel@citrix.com>
>>>>> 
>>>>> PRIVCMD_MMAPBATCH_V2 extends PRIVCMD_MMAPBATCH with an additional
>>>>> field for reporting the error code for every frame that could not be
>>>>> mapped.  libxc prefers PRIVCMD_MMAPBATCH_V2 over PRIVCMD_MMAPBATCH.
>>>>> 
>>>>> Signed-off-by: David Vrabel <david.vrabel@citrix.com>
>>>>> ---
>>>>> drivers/xen/privcmd.c |   99 +++++++++++++++++++++++++++++++++++++++---------
>>>>> include/xen/privcmd.h |   23 +++++++++++-
>>>>> 2 files changed, 102 insertions(+), 20 deletions(-)
>>>>> 
>>>>> diff --git a/drivers/xen/privcmd.c b/drivers/xen/privcmd.c
>>>>> index ccee0f1..c0e89e7 100644
>>>>> --- a/drivers/xen/privcmd.c
>>>>> +++ b/drivers/xen/privcmd.c
>>>>> @@ -76,7 +76,7 @@ static void free_page_list(struct list_head *pages)
>>>>> */
>>>>> static int gather_array(struct list_head *pagelist,
>>>>> 			unsigned nelem, size_t size,
>>>>> -			void __user *data)
>>>>> +			const void __user *data)
>>>>> {
>>>>> 	unsigned pageidx;
>>>>> 	void *pagedata;
>>>>> @@ -248,18 +248,37 @@ struct mmap_batch_state {
>>>>> 	struct vm_area_struct *vma;
>>>>> 	int err;
>>>>> 
>>>>> -	xen_pfn_t __user *user;
>>>>> +	xen_pfn_t __user *user_mfn;
>>>>> +	int __user *user_err;
>>>>> };
>>>>> 
>>>>> static int mmap_batch_fn(void *data, void *state)
>>>>> {
>>>>> 	xen_pfn_t *mfnp = data;
>>>>> 	struct mmap_batch_state *st = state;
>>>>> +	int ret;
>>>>> 
>>>>> -	if (xen_remap_domain_mfn_range(st->vma, st->va & PAGE_MASK, *mfnp, 1,
>>>>> -				       st->vma->vm_page_prot, st->domain) < 0) {
>>>>> -		*mfnp |= 0xf0000000U;
>>>>> -		st->err++;
>>>>> +	ret = xen_remap_domain_mfn_range(st->vma, st->va & PAGE_MASK, *mfnp, 1,
>>>>> +					 st->vma->vm_page_prot, st->domain);
>>>>> +	if (ret < 0) {
>>>>> +		/*
>>>>> +		 * Error reporting is a mess but userspace relies on
>>>>> +		 * it behaving this way.
>>>>> +		 *
>>>>> +		 * V2 needs to a) return the result of each frame's
>>>>> +		 * remap; and b) return -ENOENT if any frame failed
>>>>> +		 * with -ENOENT.
>>>>> +		 *
>>>>> +		 * In this first pass the error code is saved by
>>>>> +		 * overwriting the mfn and an error is indicated in
>>>>> +		 * st->err.
>>>>> +		 *
>>>>> +		 * The second pass by mmap_return_errors() will write
>>>>> +		 * the error codes to user space and get the right
>>>>> +		 * ioctl return value.
>>>>> +		 */
>>>>> +		*(int *)mfnp = ret;
>>>>> +		st->err = ret;
>>>>> 	}
>>>>> 	st->va += PAGE_SIZE;
>>>>> 
>>>>> @@ -270,16 +289,33 @@ static int mmap_return_errors(void *data, void *state)
>>>>> {
>>>>> 	xen_pfn_t *mfnp = data;
>>>>> 	struct mmap_batch_state *st = state;
>>>>> +	int ret;
>>>>> +
>>>>> +	if (st->user_err) {
>>>>> +		int err = *(int *)mfnp;
>>>>> +
>>>>> +		if (err == -ENOENT)
>>>>> +			st->err = err;
>>>>> 
>>>>> -	return put_user(*mfnp, st->user++);
>>>>> +		return __put_user(err, st->user_err++);
>>>>> +	} else {
>>>>> +		xen_pfn_t mfn;
>>>>> +
>>>>> +		ret = __get_user(mfn, st->user_mfn);
>>>>> +		if (ret < 0)
>>>>> +			return ret;
>>>>> +
>>>>> +		mfn |= PRIVCMD_MMAPBATCH_MFN_ERROR;
>>>>> +		return __put_user(mfn, st->user_mfn++);
>>>>> +	}
>>>>> }
>>>>> 
>>>>> static struct vm_operations_struct privcmd_vm_ops;
>>>>> 
>>>>> -static long privcmd_ioctl_mmap_batch(void __user *udata)
>>>>> +static long privcmd_ioctl_mmap_batch(void __user *udata, int version)
>>>>> {
>>>>> 	int ret;
>>>>> -	struct privcmd_mmapbatch m;
>>>>> +	struct privcmd_mmapbatch_v2 m;
>>>>> 	struct mm_struct *mm = current->mm;
>>>>> 	struct vm_area_struct *vma;
>>>>> 	unsigned long nr_pages;
>>>>> @@ -289,15 +325,31 @@ static long privcmd_ioctl_mmap_batch(void __user *udata)
>>>>> 	if (!xen_initial_domain())
>>>>> 		return -EPERM;
>>>>> 
>>>>> -	if (copy_from_user(&m, udata, sizeof(m)))
>>>>> -		return -EFAULT;
>>>>> +	switch (version) {
>>>>> +	case 1:
>>>>> +		if (copy_from_user(&m, udata, sizeof(struct privcmd_mmapbatch)))
>>>>> +			return -EFAULT;
>>>>> +		/* Returns per-frame error in m.arr. */
>>>>> +		m.err = NULL;
>>>>> +		if (!access_ok(VERIFY_WRITE, m.arr, m.num * sizeof(*m.arr)))
>>>>> +			return -EFAULT;
>>>>> +		break;
>>>>> +	case 2:
>>>>> +		if (copy_from_user(&m, udata, sizeof(struct privcmd_mmapbatch_v2)))
>>>>> +			return -EFAULT;
>>>>> +		/* Returns per-frame error code in m.err. */
>>>>> +		if (!access_ok(VERIFY_WRITE, m.err, m.num * (sizeof(*m.err))))
>>>>> +			return -EFAULT;
>>>>> +		break;
>>>>> +	default:
>>>>> +		return -EINVAL;
>>>>> +	}
>>>>> 
>>>>> 	nr_pages = m.num;
>>>>> 	if ((m.num <= 0) || (nr_pages > (LONG_MAX >> PAGE_SHIFT)))
>>>>> 		return -EINVAL;
>>>>> 
>>>>> -	ret = gather_array(&pagelist, m.num, sizeof(xen_pfn_t),
>>>>> -			   m.arr);
>>>>> +	ret = gather_array(&pagelist, m.num, sizeof(xen_pfn_t), m.arr);
>>>>> 
>>>>> 	if (ret || list_empty(&pagelist))
>>>>> 		goto out;
>>>>> @@ -325,12 +377,17 @@ static long privcmd_ioctl_mmap_batch(void __user *udata)
>>>>> 
>>>>> 	up_write(&mm->mmap_sem);
>>>>> 
>>>>> -	if (state.err > 0) {
>>>>> -		state.user = m.arr;
>>>>> +	if (state.err) {
>>>>> +		state.err = 0;
>>>>> +		state.user_mfn = (xen_pfn_t *)m.arr;
>>>>> +		state.user_err = m.err;
>>>>> 		ret = traverse_pages(m.num, sizeof(xen_pfn_t),
>>>>> -			       &pagelist,
>>>>> -			       mmap_return_errors, &state);
>>>>> -	}
>>>>> +				     &pagelist,
>>>>> +				     mmap_return_errors, &state);
>>>>> +		if (ret >= 0)
>>>>> +			ret = state.err;
>>>>> +	} else if (m.err)
>>>>> +		__clear_user(m.err, m.num * sizeof(*m.err));
>>>>> 
>>>>> out:
>>>>> 	free_page_list(&pagelist);
>>>>> @@ -354,7 +411,11 @@ static long privcmd_ioctl(struct file *file,
>>>>> 		break;
>>>>> 
>>>>> 	case IOCTL_PRIVCMD_MMAPBATCH:
>>>>> -		ret = privcmd_ioctl_mmap_batch(udata);
>>>>> +		ret = privcmd_ioctl_mmap_batch(udata, 1);
>>>>> +		break;
>>>>> +
>>>>> +	case IOCTL_PRIVCMD_MMAPBATCH_V2:
>>>>> +		ret = privcmd_ioctl_mmap_batch(udata, 2);
>>>>> 		break;
>>>>> 
>>>>> 	default:
>>>>> diff --git a/include/xen/privcmd.h b/include/xen/privcmd.h
>>>>> index 17857fb..f60d75c 100644
>>>>> --- a/include/xen/privcmd.h
>>>>> +++ b/include/xen/privcmd.h
>>>>> @@ -59,13 +59,32 @@ struct privcmd_mmapbatch {
>>>>> 	int num;     /* number of pages to populate */
>>>>> 	domid_t dom; /* target domain */
>>>>> 	__u64 addr;  /* virtual address */
>>>>> -	xen_pfn_t __user *arr; /* array of mfns - top nibble set on err */
>>>>> +	xen_pfn_t __user *arr; /* array of mfns - or'd with
>>>>> +				  PRIVCMD_MMAPBATCH_MFN_ERROR on err */
>>>>> +};
>>>>> +
>>>>> +#define PRIVCMD_MMAPBATCH_MFN_ERROR 0xf0000000U
>>>>> +
>>>>> +struct privcmd_mmapbatch_v2 {
>>>>> +	unsigned int num; /* number of pages to populate */
>>>>> +	domid_t dom;      /* target domain */
>>>>> +	__u64 addr;       /* virtual address */
>>>>> +	const xen_pfn_t __user *arr; /* array of mfns */
>>>>> +	int __user *err;  /* array of error codes */
>>>>> };
>>>>> 
>>>>> /*
>>>>> * @cmd: IOCTL_PRIVCMD_HYPERCALL
>>>>> * @arg: &privcmd_hypercall_t
>>>>> * Return: Value returned from execution of the specified hypercall.
>>>>> + *
>>>>> + * @cmd: IOCTL_PRIVCMD_MMAPBATCH_V2
>>>>> + * @arg: &struct privcmd_mmapbatch_v2
>>>>> + * Return: 0 on success (i.e., arg->err contains valid error codes for
>>>>> + * each frame).  On an error other than a failed frame remap, -1 is
>>>>> + * returned and errno is set to EINVAL, EFAULT etc.  As an exception,
>>>>> + * if the operation was otherwise successful but any frame failed with
>>>>> + * -ENOENT, then -1 is returned and errno is set to ENOENT.
>>>>> */
>>>>> #define IOCTL_PRIVCMD_HYPERCALL					\
>>>>> 	_IOC(_IOC_NONE, 'P', 0, sizeof(struct privcmd_hypercall))
>>>>> @@ -73,5 +92,7 @@ struct privcmd_mmapbatch {
>>>>> 	_IOC(_IOC_NONE, 'P', 2, sizeof(struct privcmd_mmap))
>>>>> #define IOCTL_PRIVCMD_MMAPBATCH					\
>>>>> 	_IOC(_IOC_NONE, 'P', 3, sizeof(struct privcmd_mmapbatch))
>>>>> +#define IOCTL_PRIVCMD_MMAPBATCH_V2				\
>>>>> +	_IOC(_IOC_NONE, 'P', 4, sizeof(struct privcmd_mmapbatch_v2))
>>>>> 
>>>>> #endif /* __LINUX_PUBLIC_PRIVCMD_H__ */
>>>>> -- 
>>>>> 1.7.2.5
>>>>> 


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

From xen-devel-bounces@lists.xen.org Thu Sep 06 13:43:18 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 2012 13:43:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9cMO-00041c-Ij; Thu, 06 Sep 2012 13:43:08 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <juergen.gross@ts.fujitsu.com>) id 1T9cMN-00041K-I5
	for xen-devel@lists.xen.org; Thu, 06 Sep 2012 13:43:08 +0000
Received: from [85.158.138.51:60230] by server-2.bemta-3.messagelabs.com id
	F7/D7-04862-A68A8405; Thu, 06 Sep 2012 13:43:06 +0000
X-Env-Sender: juergen.gross@ts.fujitsu.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1346938985!22715375!1
X-Originating-IP: [80.70.172.49]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogODAuNzAuMTcyLjQ5ID0+IDI0OTc4Ng==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22040 invoked from network); 6 Sep 2012 13:43:06 -0000
Received: from dgate10.ts.fujitsu.com (HELO dgate10.ts.fujitsu.com)
	(80.70.172.49)
	by server-14.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 6 Sep 2012 13:43:06 -0000
DomainKey-Signature: s=s1536a; d=ts.fujitsu.com; c=nofws; q=dns;
	h=X-SBRSScore:X-IronPort-AV:Received:X-IronPort-AV:
	Received:Received:Message-ID:Date:From:Organization:
	User-Agent:MIME-Version:To:CC:Subject:References:
	In-Reply-To:Content-Type:Content-Transfer-Encoding;
	b=LuAVZA/JiWb432htopeBIdPB78/QHjwBcBiQY93rGJSBRd0AbHA3ru+G
	bYXeumMAw7xInt8KHj1M4YMBXgahGeRcaDe/QDfi4GDR6abhcMbbfLsuK
	VcrX7IInwQCe8cSbOKr10BX1rb6s1WPHUPrMKt9j68136xOTfdmyp+ZdD
	MN3/Jdi3sftr1aIN7wuYftf3w3yOFNTod7W8CHPKEsuD75VZtXf+F4tYT
	oRnRcYqEz3kRsd/hDik+XwoQhDpjS;
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
	d=ts.fujitsu.com; i=@ts.fujitsu.com; q=dns/txt;
	s=s1536b; t=1346938986; x=1378474986;
	h=message-id:date:from:mime-version:to:cc:subject:
	references:in-reply-to:content-transfer-encoding;
	bh=IhPKKwcT7lqqL/eJHANty50dMsQ53Ob44d0VUe+HwvA=;
	b=auGZHRWDa4AFxVCBajgK74KgZGpKBZCfdH4sGGWKTxzKQOwpqIA0rnhq
	r3ARn/P1QP4pPJ1pQ96cBnQ2uQ8rNqTKnwaayioLfUQbeQm8GfcwyY0ms
	gRrppoSzAYHLRk48QrE5k7EJY+mLJwfvdlJWFgDYwlZe4J14dvapF1/cZ
	327F4xMUoBurGXI1sUj5gInQ8iYOqx35kl0jn8yZVJ/Ew+IHj1qW8SKJK
	X/UiQ3KLOUWU0PMbR7iMjCqp1kzI5;
X-SBRSScore: None
X-IronPort-AV: E=Sophos;i="4.80,380,1344204000"; d="scan'208";a="121493381"
Received: from abgdgate40u.abg.fsc.net ([172.25.138.90])
	by dgate10u.abg.fsc.net with ESMTP; 06 Sep 2012 15:43:06 +0200
X-IronPort-AV: E=Sophos;i="4.80,380,1344204000"; d="scan'208";a="144083339"
Received: from sanpedro.mch.fsc.net ([172.17.20.6])
	by abgdgate40u.abg.fsc.net with ESMTP; 06 Sep 2012 15:43:05 +0200
Received: from [172.17.21.50] (verdon.osd.mch.fsc.net [172.17.21.50])
	by sanpedro.mch.fsc.net (Postfix) with ESMTP id B1A364A5865;
	Thu,  6 Sep 2012 15:43:05 +0200 (CEST)
Message-ID: <5048A869.6060002@ts.fujitsu.com>
Date: Thu, 06 Sep 2012 15:43:05 +0200
From: Juergen Gross <juergen.gross@ts.fujitsu.com>
Organization: Fujitsu Technology Solutions GmbH
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.1.16) Gecko/20120724 Iceowl/1.0b1 Icedove/3.0.11
MIME-Version: 1.0
To: Ian Campbell <ian.campbell@citrix.com>
References: <d4d7031eb68bf0ce9bc8.1346932006@cosworth.uk.xensource.com>
In-Reply-To: <d4d7031eb68bf0ce9bc8.1346932006@cosworth.uk.xensource.com>
Cc: Ian.Jackson@citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] xl: do not leak cpupool names
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
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 06.09.2012 13:46, schrieb Ian Campbell:
> # HG changeset patch
> # User Ian Campbell<ian.campbell@citrix.com>
> # Date 1346931944 -3600
> # Node ID d4d7031eb68bf0ce9bc83901b699cf13a2c73c95
> # Parent  1db796c3c0b97bba222f20db543c227e313ec1be
> xl: do not leak cpupool names.
>
> Valgrind reports:
> ==3076== 7 bytes in 1 blocks are definitely lost in loss record 1 of 1
> ==3076==    at 0x402458C: malloc (vg_replace_malloc.c:270)
> ==3076==    by 0x406F86D: libxl_cpupoolid_to_name (libxl_utils.c:102)
> ==3076==    by 0x8058742: parse_config_data (xl_cmdimpl.c:639)
> ==3076==    by 0x805BD56: create_domain (xl_cmdimpl.c:1838)
> ==3076==    by 0x805DAED: main_create (xl_cmdimpl.c:3903)
> ==3076==    by 0x804D39D: main (xl.c:285)
>
> And indeed there are several places where xl uses
> libxl_cpupoolid_to_name as a boolean to test if the pool name is
> valid and leaks the name if it is. Introduce an is_valid helper and
> use that instead.
>
> Signed-off-by: Ian Campbell<ian.campbell@citrix.com>

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

> ---
>
> This leak is in xl not libxl so this is 4.3 material IMHO.
>
> diff -r 1db796c3c0b9 -r d4d7031eb68b tools/libxl/libxl_utils.c
> --- a/tools/libxl/libxl_utils.c	Thu Sep 06 12:24:44 2012 +0100
> +++ b/tools/libxl/libxl_utils.c	Thu Sep 06 12:45:44 2012 +0100
> @@ -103,6 +103,17 @@ char *libxl_cpupoolid_to_name(libxl_ctx
>       return s;
>   }
>
> +/* This is a bit horrid but without xs_exists it seems like the only way. */
> +int libxl_cpupoolid_is_valid(libxl_ctx *ctx, uint32_t poolid)
> +{
> +    int ret;
> +    char *s = libxl_cpupoolid_to_name(ctx, poolid);
> +
> +    ret = (s != NULL);
> +    free(s);
> +    return ret;
> +}
> +
>   char *libxl__cpupoolid_to_name(libxl__gc *gc, uint32_t poolid)
>   {
>       char *s = libxl_cpupoolid_to_name(libxl__gc_owner(gc), poolid);
> diff -r 1db796c3c0b9 -r d4d7031eb68b tools/libxl/libxl_utils.h
> --- a/tools/libxl/libxl_utils.h	Thu Sep 06 12:24:44 2012 +0100
> +++ b/tools/libxl/libxl_utils.h	Thu Sep 06 12:45:44 2012 +0100
> @@ -24,6 +24,7 @@ int libxl_name_to_domid(libxl_ctx *ctx,
>   char *libxl_domid_to_name(libxl_ctx *ctx, uint32_t domid);
>   int libxl_name_to_cpupoolid(libxl_ctx *ctx, const char *name, uint32_t *poolid);
>   char *libxl_cpupoolid_to_name(libxl_ctx *ctx, uint32_t poolid);
> +int libxl_cpupoolid_is_valid(libxl_ctx *ctx, uint32_t poolid);
>   int libxl_get_stubdom_id(libxl_ctx *ctx, int guest_domid);
>   int libxl_is_stubdom(libxl_ctx *ctx, uint32_t domid, uint32_t *target_domid);
>   int libxl_create_logfile(libxl_ctx *ctx, const char *name, char **full_name);
> diff -r 1db796c3c0b9 -r d4d7031eb68b tools/libxl/xl_cmdimpl.c
> --- a/tools/libxl/xl_cmdimpl.c	Thu Sep 06 12:24:44 2012 +0100
> +++ b/tools/libxl/xl_cmdimpl.c	Thu Sep 06 12:45:44 2012 +0100
> @@ -636,7 +636,7 @@ static void parse_config_data(const char
>           c_info->poolid = -1;
>           cpupool_qualifier_to_cpupoolid(buf,&c_info->poolid, NULL);
>       }
> -    if (!libxl_cpupoolid_to_name(ctx, c_info->poolid)) {
> +    if (!libxl_cpupoolid_is_valid(ctx, c_info->poolid)) {
>           fprintf(stderr, "Illegal pool specified\n");
>           exit(1);
>       }
> @@ -4733,7 +4733,7 @@ static int sched_domain_output(libxl_sch
>
>       if (cpupool) {
>           if (cpupool_qualifier_to_cpupoolid(cpupool,&poolid, NULL) ||
> -            !libxl_cpupoolid_to_name(ctx, poolid)) {
> +            !libxl_cpupoolid_is_valid(ctx, poolid)) {
>               fprintf(stderr, "unknown cpupool \'%s\'\n", cpupool);
>               return -ERROR_FAIL;
>           }
> @@ -4863,7 +4863,7 @@ int main_sched_credit(int argc, char **a
>
>           if (cpupool) {
>               if (cpupool_qualifier_to_cpupoolid(cpupool,&poolid, NULL) ||
> -                !libxl_cpupoolid_to_name(ctx, poolid)) {
> +                !libxl_cpupoolid_is_valid(ctx, poolid)) {
>                   fprintf(stderr, "unknown cpupool \'%s\'\n", cpupool);
>                   return -ERROR_FAIL;
>               }
> @@ -6290,7 +6290,7 @@ int main_cpupooldestroy(int argc, char *
>       pool = argv[optind];
>
>       if (cpupool_qualifier_to_cpupoolid(pool,&poolid, NULL) ||
> -        !libxl_cpupoolid_to_name(ctx, poolid)) {
> +        !libxl_cpupoolid_is_valid(ctx, poolid)) {
>           fprintf(stderr, "unknown cpupool \'%s\'\n", pool);
>           return -ERROR_FAIL;
>       }
> @@ -6311,7 +6311,7 @@ int main_cpupoolrename(int argc, char **
>       pool = argv[optind++];
>
>       if (cpupool_qualifier_to_cpupoolid(pool,&poolid, NULL) ||
> -        !libxl_cpupoolid_to_name(ctx, poolid)) {
> +        !libxl_cpupoolid_is_valid(ctx, poolid)) {
>           fprintf(stderr, "unknown cpupool \'%s\'\n", pool);
>           return -ERROR_FAIL;
>       }
> @@ -6348,7 +6348,7 @@ int main_cpupoolcpuadd(int argc, char **
>       }
>
>       if (cpupool_qualifier_to_cpupoolid(pool,&poolid, NULL) ||
> -        !libxl_cpupoolid_to_name(ctx, poolid)) {
> +        !libxl_cpupoolid_is_valid(ctx, poolid)) {
>           fprintf(stderr, "unknown cpupool \'%s\'\n", pool);
>           return -ERROR_FAIL;
>       }
> @@ -6392,7 +6392,7 @@ int main_cpupoolcpuremove(int argc, char
>       }
>
>       if (cpupool_qualifier_to_cpupoolid(pool,&poolid, NULL) ||
> -        !libxl_cpupoolid_to_name(ctx, poolid)) {
> +        !libxl_cpupoolid_is_valid(ctx, poolid)) {
>           fprintf(stderr, "unknown cpupool \'%s\'\n", pool);
>           return -ERROR_FAIL;
>       }
> @@ -6435,7 +6435,7 @@ int main_cpupoolmigrate(int argc, char *
>       }
>
>       if (cpupool_qualifier_to_cpupoolid(pool,&poolid, NULL) ||
> -        !libxl_cpupoolid_to_name(ctx, poolid)) {
> +        !libxl_cpupoolid_is_valid(ctx, poolid)) {
>           fprintf(stderr, "unknown cpupool \'%s\'\n", pool);
>           return -ERROR_FAIL;
>       }
> diff -r 1db796c3c0b9 -r d4d7031eb68b tools/libxl/xl_sxp.c
> --- a/tools/libxl/xl_sxp.c	Thu Sep 06 12:24:44 2012 +0100
> +++ b/tools/libxl/xl_sxp.c	Thu Sep 06 12:45:44 2012 +0100
> @@ -37,6 +37,7 @@ void printf_info_sexp(int domid, libxl_d
>
>       libxl_domain_create_info *c_info =&d_config->c_info;
>       libxl_domain_build_info *b_info =&d_config->b_info;
> +    char *pool;
>
>       printf("(domain\n\t(domid %d)\n", domid);
>       printf("\t(create_info)\n");
> @@ -54,8 +55,10 @@ void printf_info_sexp(int domid, libxl_d
>       } else {
>           printf("\t(uuid<unknown>)\n");
>       }
> -
> -    printf("\t(cpupool %s)\n", libxl_cpupoolid_to_name(ctx, c_info->poolid));
> +    pool = libxl_cpupoolid_to_name(ctx, c_info->poolid);
> +    if (pool)
> +        printf("\t(cpupool %s)\n", pool);
> +    free(pool);
>       if (c_info->xsdata)
>           printf("\t(xsdata contains data)\n");
>       else
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
>
>


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

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

From xen-devel-bounces@lists.xen.org Thu Sep 06 13:43:18 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 2012 13:43:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9cMO-00041c-Ij; Thu, 06 Sep 2012 13:43:08 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <juergen.gross@ts.fujitsu.com>) id 1T9cMN-00041K-I5
	for xen-devel@lists.xen.org; Thu, 06 Sep 2012 13:43:08 +0000
Received: from [85.158.138.51:60230] by server-2.bemta-3.messagelabs.com id
	F7/D7-04862-A68A8405; Thu, 06 Sep 2012 13:43:06 +0000
X-Env-Sender: juergen.gross@ts.fujitsu.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1346938985!22715375!1
X-Originating-IP: [80.70.172.49]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogODAuNzAuMTcyLjQ5ID0+IDI0OTc4Ng==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22040 invoked from network); 6 Sep 2012 13:43:06 -0000
Received: from dgate10.ts.fujitsu.com (HELO dgate10.ts.fujitsu.com)
	(80.70.172.49)
	by server-14.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 6 Sep 2012 13:43:06 -0000
DomainKey-Signature: s=s1536a; d=ts.fujitsu.com; c=nofws; q=dns;
	h=X-SBRSScore:X-IronPort-AV:Received:X-IronPort-AV:
	Received:Received:Message-ID:Date:From:Organization:
	User-Agent:MIME-Version:To:CC:Subject:References:
	In-Reply-To:Content-Type:Content-Transfer-Encoding;
	b=LuAVZA/JiWb432htopeBIdPB78/QHjwBcBiQY93rGJSBRd0AbHA3ru+G
	bYXeumMAw7xInt8KHj1M4YMBXgahGeRcaDe/QDfi4GDR6abhcMbbfLsuK
	VcrX7IInwQCe8cSbOKr10BX1rb6s1WPHUPrMKt9j68136xOTfdmyp+ZdD
	MN3/Jdi3sftr1aIN7wuYftf3w3yOFNTod7W8CHPKEsuD75VZtXf+F4tYT
	oRnRcYqEz3kRsd/hDik+XwoQhDpjS;
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
	d=ts.fujitsu.com; i=@ts.fujitsu.com; q=dns/txt;
	s=s1536b; t=1346938986; x=1378474986;
	h=message-id:date:from:mime-version:to:cc:subject:
	references:in-reply-to:content-transfer-encoding;
	bh=IhPKKwcT7lqqL/eJHANty50dMsQ53Ob44d0VUe+HwvA=;
	b=auGZHRWDa4AFxVCBajgK74KgZGpKBZCfdH4sGGWKTxzKQOwpqIA0rnhq
	r3ARn/P1QP4pPJ1pQ96cBnQ2uQ8rNqTKnwaayioLfUQbeQm8GfcwyY0ms
	gRrppoSzAYHLRk48QrE5k7EJY+mLJwfvdlJWFgDYwlZe4J14dvapF1/cZ
	327F4xMUoBurGXI1sUj5gInQ8iYOqx35kl0jn8yZVJ/Ew+IHj1qW8SKJK
	X/UiQ3KLOUWU0PMbR7iMjCqp1kzI5;
X-SBRSScore: None
X-IronPort-AV: E=Sophos;i="4.80,380,1344204000"; d="scan'208";a="121493381"
Received: from abgdgate40u.abg.fsc.net ([172.25.138.90])
	by dgate10u.abg.fsc.net with ESMTP; 06 Sep 2012 15:43:06 +0200
X-IronPort-AV: E=Sophos;i="4.80,380,1344204000"; d="scan'208";a="144083339"
Received: from sanpedro.mch.fsc.net ([172.17.20.6])
	by abgdgate40u.abg.fsc.net with ESMTP; 06 Sep 2012 15:43:05 +0200
Received: from [172.17.21.50] (verdon.osd.mch.fsc.net [172.17.21.50])
	by sanpedro.mch.fsc.net (Postfix) with ESMTP id B1A364A5865;
	Thu,  6 Sep 2012 15:43:05 +0200 (CEST)
Message-ID: <5048A869.6060002@ts.fujitsu.com>
Date: Thu, 06 Sep 2012 15:43:05 +0200
From: Juergen Gross <juergen.gross@ts.fujitsu.com>
Organization: Fujitsu Technology Solutions GmbH
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.1.16) Gecko/20120724 Iceowl/1.0b1 Icedove/3.0.11
MIME-Version: 1.0
To: Ian Campbell <ian.campbell@citrix.com>
References: <d4d7031eb68bf0ce9bc8.1346932006@cosworth.uk.xensource.com>
In-Reply-To: <d4d7031eb68bf0ce9bc8.1346932006@cosworth.uk.xensource.com>
Cc: Ian.Jackson@citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] xl: do not leak cpupool names
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
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 06.09.2012 13:46, schrieb Ian Campbell:
> # HG changeset patch
> # User Ian Campbell<ian.campbell@citrix.com>
> # Date 1346931944 -3600
> # Node ID d4d7031eb68bf0ce9bc83901b699cf13a2c73c95
> # Parent  1db796c3c0b97bba222f20db543c227e313ec1be
> xl: do not leak cpupool names.
>
> Valgrind reports:
> ==3076== 7 bytes in 1 blocks are definitely lost in loss record 1 of 1
> ==3076==    at 0x402458C: malloc (vg_replace_malloc.c:270)
> ==3076==    by 0x406F86D: libxl_cpupoolid_to_name (libxl_utils.c:102)
> ==3076==    by 0x8058742: parse_config_data (xl_cmdimpl.c:639)
> ==3076==    by 0x805BD56: create_domain (xl_cmdimpl.c:1838)
> ==3076==    by 0x805DAED: main_create (xl_cmdimpl.c:3903)
> ==3076==    by 0x804D39D: main (xl.c:285)
>
> And indeed there are several places where xl uses
> libxl_cpupoolid_to_name as a boolean to test if the pool name is
> valid and leaks the name if it is. Introduce an is_valid helper and
> use that instead.
>
> Signed-off-by: Ian Campbell<ian.campbell@citrix.com>

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

> ---
>
> This leak is in xl not libxl so this is 4.3 material IMHO.
>
> diff -r 1db796c3c0b9 -r d4d7031eb68b tools/libxl/libxl_utils.c
> --- a/tools/libxl/libxl_utils.c	Thu Sep 06 12:24:44 2012 +0100
> +++ b/tools/libxl/libxl_utils.c	Thu Sep 06 12:45:44 2012 +0100
> @@ -103,6 +103,17 @@ char *libxl_cpupoolid_to_name(libxl_ctx
>       return s;
>   }
>
> +/* This is a bit horrid but without xs_exists it seems like the only way. */
> +int libxl_cpupoolid_is_valid(libxl_ctx *ctx, uint32_t poolid)
> +{
> +    int ret;
> +    char *s = libxl_cpupoolid_to_name(ctx, poolid);
> +
> +    ret = (s != NULL);
> +    free(s);
> +    return ret;
> +}
> +
>   char *libxl__cpupoolid_to_name(libxl__gc *gc, uint32_t poolid)
>   {
>       char *s = libxl_cpupoolid_to_name(libxl__gc_owner(gc), poolid);
> diff -r 1db796c3c0b9 -r d4d7031eb68b tools/libxl/libxl_utils.h
> --- a/tools/libxl/libxl_utils.h	Thu Sep 06 12:24:44 2012 +0100
> +++ b/tools/libxl/libxl_utils.h	Thu Sep 06 12:45:44 2012 +0100
> @@ -24,6 +24,7 @@ int libxl_name_to_domid(libxl_ctx *ctx,
>   char *libxl_domid_to_name(libxl_ctx *ctx, uint32_t domid);
>   int libxl_name_to_cpupoolid(libxl_ctx *ctx, const char *name, uint32_t *poolid);
>   char *libxl_cpupoolid_to_name(libxl_ctx *ctx, uint32_t poolid);
> +int libxl_cpupoolid_is_valid(libxl_ctx *ctx, uint32_t poolid);
>   int libxl_get_stubdom_id(libxl_ctx *ctx, int guest_domid);
>   int libxl_is_stubdom(libxl_ctx *ctx, uint32_t domid, uint32_t *target_domid);
>   int libxl_create_logfile(libxl_ctx *ctx, const char *name, char **full_name);
> diff -r 1db796c3c0b9 -r d4d7031eb68b tools/libxl/xl_cmdimpl.c
> --- a/tools/libxl/xl_cmdimpl.c	Thu Sep 06 12:24:44 2012 +0100
> +++ b/tools/libxl/xl_cmdimpl.c	Thu Sep 06 12:45:44 2012 +0100
> @@ -636,7 +636,7 @@ static void parse_config_data(const char
>           c_info->poolid = -1;
>           cpupool_qualifier_to_cpupoolid(buf,&c_info->poolid, NULL);
>       }
> -    if (!libxl_cpupoolid_to_name(ctx, c_info->poolid)) {
> +    if (!libxl_cpupoolid_is_valid(ctx, c_info->poolid)) {
>           fprintf(stderr, "Illegal pool specified\n");
>           exit(1);
>       }
> @@ -4733,7 +4733,7 @@ static int sched_domain_output(libxl_sch
>
>       if (cpupool) {
>           if (cpupool_qualifier_to_cpupoolid(cpupool,&poolid, NULL) ||
> -            !libxl_cpupoolid_to_name(ctx, poolid)) {
> +            !libxl_cpupoolid_is_valid(ctx, poolid)) {
>               fprintf(stderr, "unknown cpupool \'%s\'\n", cpupool);
>               return -ERROR_FAIL;
>           }
> @@ -4863,7 +4863,7 @@ int main_sched_credit(int argc, char **a
>
>           if (cpupool) {
>               if (cpupool_qualifier_to_cpupoolid(cpupool,&poolid, NULL) ||
> -                !libxl_cpupoolid_to_name(ctx, poolid)) {
> +                !libxl_cpupoolid_is_valid(ctx, poolid)) {
>                   fprintf(stderr, "unknown cpupool \'%s\'\n", cpupool);
>                   return -ERROR_FAIL;
>               }
> @@ -6290,7 +6290,7 @@ int main_cpupooldestroy(int argc, char *
>       pool = argv[optind];
>
>       if (cpupool_qualifier_to_cpupoolid(pool,&poolid, NULL) ||
> -        !libxl_cpupoolid_to_name(ctx, poolid)) {
> +        !libxl_cpupoolid_is_valid(ctx, poolid)) {
>           fprintf(stderr, "unknown cpupool \'%s\'\n", pool);
>           return -ERROR_FAIL;
>       }
> @@ -6311,7 +6311,7 @@ int main_cpupoolrename(int argc, char **
>       pool = argv[optind++];
>
>       if (cpupool_qualifier_to_cpupoolid(pool,&poolid, NULL) ||
> -        !libxl_cpupoolid_to_name(ctx, poolid)) {
> +        !libxl_cpupoolid_is_valid(ctx, poolid)) {
>           fprintf(stderr, "unknown cpupool \'%s\'\n", pool);
>           return -ERROR_FAIL;
>       }
> @@ -6348,7 +6348,7 @@ int main_cpupoolcpuadd(int argc, char **
>       }
>
>       if (cpupool_qualifier_to_cpupoolid(pool,&poolid, NULL) ||
> -        !libxl_cpupoolid_to_name(ctx, poolid)) {
> +        !libxl_cpupoolid_is_valid(ctx, poolid)) {
>           fprintf(stderr, "unknown cpupool \'%s\'\n", pool);
>           return -ERROR_FAIL;
>       }
> @@ -6392,7 +6392,7 @@ int main_cpupoolcpuremove(int argc, char
>       }
>
>       if (cpupool_qualifier_to_cpupoolid(pool,&poolid, NULL) ||
> -        !libxl_cpupoolid_to_name(ctx, poolid)) {
> +        !libxl_cpupoolid_is_valid(ctx, poolid)) {
>           fprintf(stderr, "unknown cpupool \'%s\'\n", pool);
>           return -ERROR_FAIL;
>       }
> @@ -6435,7 +6435,7 @@ int main_cpupoolmigrate(int argc, char *
>       }
>
>       if (cpupool_qualifier_to_cpupoolid(pool,&poolid, NULL) ||
> -        !libxl_cpupoolid_to_name(ctx, poolid)) {
> +        !libxl_cpupoolid_is_valid(ctx, poolid)) {
>           fprintf(stderr, "unknown cpupool \'%s\'\n", pool);
>           return -ERROR_FAIL;
>       }
> diff -r 1db796c3c0b9 -r d4d7031eb68b tools/libxl/xl_sxp.c
> --- a/tools/libxl/xl_sxp.c	Thu Sep 06 12:24:44 2012 +0100
> +++ b/tools/libxl/xl_sxp.c	Thu Sep 06 12:45:44 2012 +0100
> @@ -37,6 +37,7 @@ void printf_info_sexp(int domid, libxl_d
>
>       libxl_domain_create_info *c_info =&d_config->c_info;
>       libxl_domain_build_info *b_info =&d_config->b_info;
> +    char *pool;
>
>       printf("(domain\n\t(domid %d)\n", domid);
>       printf("\t(create_info)\n");
> @@ -54,8 +55,10 @@ void printf_info_sexp(int domid, libxl_d
>       } else {
>           printf("\t(uuid<unknown>)\n");
>       }
> -
> -    printf("\t(cpupool %s)\n", libxl_cpupoolid_to_name(ctx, c_info->poolid));
> +    pool = libxl_cpupoolid_to_name(ctx, c_info->poolid);
> +    if (pool)
> +        printf("\t(cpupool %s)\n", pool);
> +    free(pool);
>       if (c_info->xsdata)
>           printf("\t(xsdata contains data)\n");
>       else
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
>
>


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

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

From xen-devel-bounces@lists.xen.org Thu Sep 06 13:44:40 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 2012 13: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 1T9cNj-0004DM-7c; Thu, 06 Sep 2012 13:44:31 +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 1T9cNh-0004DB-HZ
	for xen-devel@lists.xen.org; Thu, 06 Sep 2012 13:44:29 +0000
Received: from [85.158.138.51:16654] by server-10.bemta-3.messagelabs.com id
	1D/7C-10411-CB8A8405; Thu, 06 Sep 2012 13:44:28 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-13.tower-174.messagelabs.com!1346939067!10379460!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25805 invoked from network); 6 Sep 2012 13:44:28 -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; 6 Sep 2012 13:44:28 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1T9cNf-000FYV-76; Thu, 06 Sep 2012 13:44:27 +0000
Date: Thu, 6 Sep 2012 14:44:27 +0100
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <ian.campbell@citrix.com>
Message-ID: <20120906134427.GN56463@ocelot.phlegethon.org>
References: <1346678886.32462.9.camel@zakaz.uk.xensource.com>
	<1346679056-8108-14-git-send-email-ian.campbell@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1346679056-8108-14-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 14/16] arm: load dom0 kernel from first boot
	module
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At 13:30 +0000 on 03 Sep (1346679054), Ian Campbell wrote:
> -static int kernel_try_zimage_prepare(struct kernel_info *info)
> +static int kernel_try_zimage_prepare(struct kernel_info *info,
> +                                     paddr_t addr, paddr_t size)
>  {
>      uint32_t *zimage = (void *)FIXMAP_ADDR(FIXMAP_MISC);
>      uint32_t start, end;
>      struct minimal_dtb_header dtb_hdr;
>  
> -    set_fixmap(FIXMAP_MISC, KERNEL_FLASH_ADDRESS >> PAGE_SHIFT, DEV_SHARED);
> +    set_fixmap(FIXMAP_MISC, addr >> PAGE_SHIFT, DEV_SHARED);
> +
> +    zimage += addr & ~PAGE_MASK;
>  
>      if (zimage[ZIMAGE_MAGIC_OFFSET/4] != ZIMAGE_MAGIC)
>          return -EINVAL;
> @@ -106,16 +109,24 @@ static int kernel_try_zimage_prepare(struct kernel_info *info)
>      start = zimage[ZIMAGE_START_OFFSET/4];
>      end = zimage[ZIMAGE_END_OFFSET/4];
>  
> +    if ( end > addr + size )
> +        return -EINVAL;
> +
>      clear_fixmap(FIXMAP_MISC);

No clear_fixmap() on the error path?  I see there isn't one on the
existing error path above, but I suspect that's not deliberate.

>  
>      /*
>       * Check for an appended DTB.
>       */
> -    copy_from_paddr(&dtb_hdr, KERNEL_FLASH_ADDRESS + end - start, sizeof(dtb_hdr), DEV_SHARED);
> +    copy_from_paddr(&dtb_hdr, addr + end - start, sizeof(dtb_hdr), DEV_SHARED);
>      if (be32_to_cpu(dtb_hdr.magic) == DTB_MAGIC) {
>          end += be32_to_cpu(dtb_hdr.total_size);
> +
> +        if ( end > addr + size )
> +            return -EINVAL;

There ought to be a bounds check before the copy_from_paddr as well
(though I suppose there's not much to do except fail more gracefully).

Tim.

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

From xen-devel-bounces@lists.xen.org Thu Sep 06 13:44:40 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 2012 13: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 1T9cNj-0004DM-7c; Thu, 06 Sep 2012 13:44:31 +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 1T9cNh-0004DB-HZ
	for xen-devel@lists.xen.org; Thu, 06 Sep 2012 13:44:29 +0000
Received: from [85.158.138.51:16654] by server-10.bemta-3.messagelabs.com id
	1D/7C-10411-CB8A8405; Thu, 06 Sep 2012 13:44:28 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-13.tower-174.messagelabs.com!1346939067!10379460!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25805 invoked from network); 6 Sep 2012 13:44:28 -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; 6 Sep 2012 13:44:28 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1T9cNf-000FYV-76; Thu, 06 Sep 2012 13:44:27 +0000
Date: Thu, 6 Sep 2012 14:44:27 +0100
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <ian.campbell@citrix.com>
Message-ID: <20120906134427.GN56463@ocelot.phlegethon.org>
References: <1346678886.32462.9.camel@zakaz.uk.xensource.com>
	<1346679056-8108-14-git-send-email-ian.campbell@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1346679056-8108-14-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 14/16] arm: load dom0 kernel from first boot
	module
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At 13:30 +0000 on 03 Sep (1346679054), Ian Campbell wrote:
> -static int kernel_try_zimage_prepare(struct kernel_info *info)
> +static int kernel_try_zimage_prepare(struct kernel_info *info,
> +                                     paddr_t addr, paddr_t size)
>  {
>      uint32_t *zimage = (void *)FIXMAP_ADDR(FIXMAP_MISC);
>      uint32_t start, end;
>      struct minimal_dtb_header dtb_hdr;
>  
> -    set_fixmap(FIXMAP_MISC, KERNEL_FLASH_ADDRESS >> PAGE_SHIFT, DEV_SHARED);
> +    set_fixmap(FIXMAP_MISC, addr >> PAGE_SHIFT, DEV_SHARED);
> +
> +    zimage += addr & ~PAGE_MASK;
>  
>      if (zimage[ZIMAGE_MAGIC_OFFSET/4] != ZIMAGE_MAGIC)
>          return -EINVAL;
> @@ -106,16 +109,24 @@ static int kernel_try_zimage_prepare(struct kernel_info *info)
>      start = zimage[ZIMAGE_START_OFFSET/4];
>      end = zimage[ZIMAGE_END_OFFSET/4];
>  
> +    if ( end > addr + size )
> +        return -EINVAL;
> +
>      clear_fixmap(FIXMAP_MISC);

No clear_fixmap() on the error path?  I see there isn't one on the
existing error path above, but I suspect that's not deliberate.

>  
>      /*
>       * Check for an appended DTB.
>       */
> -    copy_from_paddr(&dtb_hdr, KERNEL_FLASH_ADDRESS + end - start, sizeof(dtb_hdr), DEV_SHARED);
> +    copy_from_paddr(&dtb_hdr, addr + end - start, sizeof(dtb_hdr), DEV_SHARED);
>      if (be32_to_cpu(dtb_hdr.magic) == DTB_MAGIC) {
>          end += be32_to_cpu(dtb_hdr.total_size);
> +
> +        if ( end > addr + size )
> +            return -EINVAL;

There ought to be a bounds check before the copy_from_paddr as well
(though I suppose there's not much to do except fail more gracefully).

Tim.

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

From xen-devel-bounces@lists.xen.org Thu Sep 06 13:49:35 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 2012 13:49:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9cSR-0004a0-UK; Thu, 06 Sep 2012 13:49: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 1T9cSQ-0004Zr-Jw
	for xen-devel@lists.xen.org; Thu, 06 Sep 2012 13:49:22 +0000
Received: from [85.158.143.35:16006] by server-3.bemta-4.messagelabs.com id
	98/2D-08232-1E9A8405; Thu, 06 Sep 2012 13:49:21 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1346939360!15633118!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTE5NzY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10005 invoked from network); 6 Sep 2012 13:49:21 -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;
	6 Sep 2012 13:49:21 -0000
X-IronPort-AV: E=Sophos;i="4.80,380,1344211200"; d="scan'208";a="14387538"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Sep 2012 13:48: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.279.1; Thu, 6 Sep 2012
	14:48:44 +0100
Message-ID: <1346939323.30018.12.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Thu, 6 Sep 2012 14:48:43 +0100
In-Reply-To: <5048B1C4020000780009952E@nat28.tlf.novell.com>
References: <22d5e100131d1576d455.1346932605@cosworth.uk.xensource.com>
	<5048B1C4020000780009952E@nat28.tlf.novell.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "Tim \(Xen.org\)" <tim@xen.org>, 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] [PATCH] xen: clamp bitmaps to correct number of bits
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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-09-06 at 13:23 +0100, Jan Beulich wrote:
> >>> On 06.09.12 at 13:56, Ian Campbell <ian.campbell@citrix.com> wrote:
> > The principal of least surprise suggests that these bits ought not to
> > be set and this is not a hot path so fix this at the hypervisor layer
> > by clamping the bits in the returned bitmap to the correct limit.
> 
> Hmm, I see your point, but without looking at the description
> above (i.e. if I just saw the code in its post-patch form) I'd be
> immediately tempted to rip this all out again, the more that
> the inverse functions don't do the same. So perhaps extending
> the comment before the newly added function would be useful
> to prevent such desires from coming up?

Agreed.

> > @@ -38,6 +38,17 @@
> >   * for the best explanations of this ordering.
> >   */
> >  
> > +/* Ensure that the last byte is zero from nbits onwards. */
> > +static void clamp_last_byte(uint8_t *bp, int nbits)
> > +{
> > +	int lastbyte = nbits/8;
> > +	int remainder = nbits % 8;
> > +	int mask = ((1U<<remainder)-1)&0xff;
> 
> While I realize the callers use plain int, I'd be very much in favor
> of not continuing this bad practice (the more that you use 1U
> already) - simply make the parameter and all locals (assuming
> you really think they're useful; I would have omitted all but
> "remainder", given they're being used just once) unsigned.

I'll fold them in, it was convenient to have variables while I was
printk'ing what I was doing but not any more.

> And once at it, please insert spaces consistently and drop the
> bogus "&0xff".

Done.

8<----------------------------------------------------

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1346939305 -3600
# Node ID 8652dbb4808f66bc9d85690a5e50fd5b972c6530
# Parent  c0e71dc105f785caccee3e1aec2b18f119e60f04
xen: clamp bitmaps to correct number of bits

Valgrind running xl create reports:
 ==24777== Invalid read of size 4
 ==24777==    at 0x4072805: libxl__get_numa_candidate (libxl_numa.c:203)
 ==24777==    by 0x40680B6: libxl__build_pre (libxl_dom.c:166)
 ==24777==    by 0x405B82E: libxl__domain_build (libxl_create.c:323)
 ==24777==    by 0x405BB9C: domcreate_bootloader_done (libxl_create.c:747)
 ==24777==    by 0x407AD27: bootloader_local_detached_cb (libxl_bootloader.c:281)
 ==24777==    by 0x40508D8: local_device_detach_cb (libxl.c:2470)
 ==24777==    by 0x4052B10: libxl__device_disk_local_initiate_detach (libxl.c:2445)
 ==24777==    by 0x407AE9F: bootloader_callback (libxl_bootloader.c:265)
 ==24777==    by 0x407C69A: libxl__bootloader_run (libxl_bootloader.c:392)
 ==24777==    by 0x405CB24: do_domain_create (libxl_create.c:687)
 ==24777==    by 0x405CC5E: libxl_domain_create_new (libxl_create.c:1177)
 ==24777==    by 0x805BDE2: create_domain (xl_cmdimpl.c:1812)
 ==24777==  Address 0x42dbdd8 is 8 bytes after a block of size 48 alloc'd
 ==24777==    at 0x4023340: calloc (vg_replace_malloc.c:593)
 ==24777==    by 0x406D479: libxl__zalloc (libxl_internal.c:88)
 ==24777==    by 0x404EF38: libxl_get_cpu_topology (libxl.c:3707)
 ==24777==    by 0x4072232: libxl__get_numa_candidate (libxl_numa.c:314)
 ==24777==    by 0x40680B6: libxl__build_pre (libxl_dom.c:166)
 ==24777==    by 0x405B82E: libxl__domain_build (libxl_create.c:323)
 ==24777==    by 0x405BB9C: domcreate_bootloader_done (libxl_create.c:747)
 ==24777==    by 0x407AD27: bootloader_local_detached_cb (libxl_bootloader.c:281)
 ==24777==    by 0x40508D8: local_device_detach_cb (libxl.c:2470)
 ==24777==    by 0x4052B10: libxl__device_disk_local_initiate_detach (libxl.c:2445)
 ==24777==    by 0x407AE9F: bootloader_callback (libxl_bootloader.c:265)
 ==24777==    by 0x407C69A: libxl__bootloader_run (libxl_bootloader.c:392)

This is because with nr_cpus=4 the bitmask returned from Xen
contains 0xff rather than 0x0f bit our bitmap walking routines (e.g.
libxl_for_each_set_bit) round up to the next byte (so it iterates
e.g. 8 times not 4). This then causes us to access of the end of
whatever array we are walking through each set bit for.

The principal of least surprise suggests that these bits ought not to
be set and this is not a hot path so fix this at the hypervisor layer
by clamping the bits in the returned bitmap to the correct limit.

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

The impact of this seems to be fairly benign in practice, so I'm not
sure about it for 4.2.0. Could leave to 4.2.1?

Dario,

Any chance you could look at the libxl bitmap functions in 4.3 and
make them use the right limit (i.e. nr_bits not (nr_bits+7)/8?

Thanks,
Ian.

diff -r c0e71dc105f7 -r 8652dbb4808f xen/common/bitmap.c
--- a/xen/common/bitmap.c	Thu Sep 06 14:36:09 2012 +0100
+++ b/xen/common/bitmap.c	Thu Sep 06 14:48:25 2012 +0100
@@ -38,6 +38,21 @@
  * for the best explanations of this ordering.
  */
 
+/*
+ * If a bitmap has a number of bits which is not a multiple of 8 then
+ * the last few bits of the last byte of the bitmap can be
+ * unexpectedly set which can confuse consumers (e.g. in the tools)
+ * who also round up their loops to 8 bits. Ensure we clear those left
+ * over bits so as to prevent surprises.
+ */
+static void clamp_last_byte(uint8_t *bp, int nbits)
+{
+	int remainder = nbits % 8;
+
+	if (remainder)
+		bp[nbits/8] &= ((1U<<remainder)-1);
+}
+
 int __bitmap_empty(const unsigned long *bitmap, int bits)
 {
 	int k, lim = bits/BITS_PER_LONG;
@@ -485,6 +500,7 @@ void bitmap_long_to_byte(uint8_t *bp, co
 			nbits -= 8;
 		}
 	}
+	clamp_last_byte(bp, nbits);
 }
 
 void bitmap_byte_to_long(unsigned long *lp, const uint8_t *bp, int nbits)
@@ -507,6 +523,7 @@ void bitmap_byte_to_long(unsigned long *
 void bitmap_long_to_byte(uint8_t *bp, const unsigned long *lp, int nbits)
 {
 	memcpy(bp, lp, (nbits+7)/8);
+	clamp_last_byte(bp, nbits);
 }
 
 void bitmap_byte_to_long(unsigned long *lp, const uint8_t *bp, int nbits)



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

From xen-devel-bounces@lists.xen.org Thu Sep 06 13:49:35 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 2012 13:49:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9cSR-0004a0-UK; Thu, 06 Sep 2012 13:49: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 1T9cSQ-0004Zr-Jw
	for xen-devel@lists.xen.org; Thu, 06 Sep 2012 13:49:22 +0000
Received: from [85.158.143.35:16006] by server-3.bemta-4.messagelabs.com id
	98/2D-08232-1E9A8405; Thu, 06 Sep 2012 13:49:21 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1346939360!15633118!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTE5NzY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10005 invoked from network); 6 Sep 2012 13:49:21 -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;
	6 Sep 2012 13:49:21 -0000
X-IronPort-AV: E=Sophos;i="4.80,380,1344211200"; d="scan'208";a="14387538"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Sep 2012 13:48: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.279.1; Thu, 6 Sep 2012
	14:48:44 +0100
Message-ID: <1346939323.30018.12.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Thu, 6 Sep 2012 14:48:43 +0100
In-Reply-To: <5048B1C4020000780009952E@nat28.tlf.novell.com>
References: <22d5e100131d1576d455.1346932605@cosworth.uk.xensource.com>
	<5048B1C4020000780009952E@nat28.tlf.novell.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "Tim \(Xen.org\)" <tim@xen.org>, 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] [PATCH] xen: clamp bitmaps to correct number of bits
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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-09-06 at 13:23 +0100, Jan Beulich wrote:
> >>> On 06.09.12 at 13:56, Ian Campbell <ian.campbell@citrix.com> wrote:
> > The principal of least surprise suggests that these bits ought not to
> > be set and this is not a hot path so fix this at the hypervisor layer
> > by clamping the bits in the returned bitmap to the correct limit.
> 
> Hmm, I see your point, but without looking at the description
> above (i.e. if I just saw the code in its post-patch form) I'd be
> immediately tempted to rip this all out again, the more that
> the inverse functions don't do the same. So perhaps extending
> the comment before the newly added function would be useful
> to prevent such desires from coming up?

Agreed.

> > @@ -38,6 +38,17 @@
> >   * for the best explanations of this ordering.
> >   */
> >  
> > +/* Ensure that the last byte is zero from nbits onwards. */
> > +static void clamp_last_byte(uint8_t *bp, int nbits)
> > +{
> > +	int lastbyte = nbits/8;
> > +	int remainder = nbits % 8;
> > +	int mask = ((1U<<remainder)-1)&0xff;
> 
> While I realize the callers use plain int, I'd be very much in favor
> of not continuing this bad practice (the more that you use 1U
> already) - simply make the parameter and all locals (assuming
> you really think they're useful; I would have omitted all but
> "remainder", given they're being used just once) unsigned.

I'll fold them in, it was convenient to have variables while I was
printk'ing what I was doing but not any more.

> And once at it, please insert spaces consistently and drop the
> bogus "&0xff".

Done.

8<----------------------------------------------------

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1346939305 -3600
# Node ID 8652dbb4808f66bc9d85690a5e50fd5b972c6530
# Parent  c0e71dc105f785caccee3e1aec2b18f119e60f04
xen: clamp bitmaps to correct number of bits

Valgrind running xl create reports:
 ==24777== Invalid read of size 4
 ==24777==    at 0x4072805: libxl__get_numa_candidate (libxl_numa.c:203)
 ==24777==    by 0x40680B6: libxl__build_pre (libxl_dom.c:166)
 ==24777==    by 0x405B82E: libxl__domain_build (libxl_create.c:323)
 ==24777==    by 0x405BB9C: domcreate_bootloader_done (libxl_create.c:747)
 ==24777==    by 0x407AD27: bootloader_local_detached_cb (libxl_bootloader.c:281)
 ==24777==    by 0x40508D8: local_device_detach_cb (libxl.c:2470)
 ==24777==    by 0x4052B10: libxl__device_disk_local_initiate_detach (libxl.c:2445)
 ==24777==    by 0x407AE9F: bootloader_callback (libxl_bootloader.c:265)
 ==24777==    by 0x407C69A: libxl__bootloader_run (libxl_bootloader.c:392)
 ==24777==    by 0x405CB24: do_domain_create (libxl_create.c:687)
 ==24777==    by 0x405CC5E: libxl_domain_create_new (libxl_create.c:1177)
 ==24777==    by 0x805BDE2: create_domain (xl_cmdimpl.c:1812)
 ==24777==  Address 0x42dbdd8 is 8 bytes after a block of size 48 alloc'd
 ==24777==    at 0x4023340: calloc (vg_replace_malloc.c:593)
 ==24777==    by 0x406D479: libxl__zalloc (libxl_internal.c:88)
 ==24777==    by 0x404EF38: libxl_get_cpu_topology (libxl.c:3707)
 ==24777==    by 0x4072232: libxl__get_numa_candidate (libxl_numa.c:314)
 ==24777==    by 0x40680B6: libxl__build_pre (libxl_dom.c:166)
 ==24777==    by 0x405B82E: libxl__domain_build (libxl_create.c:323)
 ==24777==    by 0x405BB9C: domcreate_bootloader_done (libxl_create.c:747)
 ==24777==    by 0x407AD27: bootloader_local_detached_cb (libxl_bootloader.c:281)
 ==24777==    by 0x40508D8: local_device_detach_cb (libxl.c:2470)
 ==24777==    by 0x4052B10: libxl__device_disk_local_initiate_detach (libxl.c:2445)
 ==24777==    by 0x407AE9F: bootloader_callback (libxl_bootloader.c:265)
 ==24777==    by 0x407C69A: libxl__bootloader_run (libxl_bootloader.c:392)

This is because with nr_cpus=4 the bitmask returned from Xen
contains 0xff rather than 0x0f bit our bitmap walking routines (e.g.
libxl_for_each_set_bit) round up to the next byte (so it iterates
e.g. 8 times not 4). This then causes us to access of the end of
whatever array we are walking through each set bit for.

The principal of least surprise suggests that these bits ought not to
be set and this is not a hot path so fix this at the hypervisor layer
by clamping the bits in the returned bitmap to the correct limit.

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

The impact of this seems to be fairly benign in practice, so I'm not
sure about it for 4.2.0. Could leave to 4.2.1?

Dario,

Any chance you could look at the libxl bitmap functions in 4.3 and
make them use the right limit (i.e. nr_bits not (nr_bits+7)/8?

Thanks,
Ian.

diff -r c0e71dc105f7 -r 8652dbb4808f xen/common/bitmap.c
--- a/xen/common/bitmap.c	Thu Sep 06 14:36:09 2012 +0100
+++ b/xen/common/bitmap.c	Thu Sep 06 14:48:25 2012 +0100
@@ -38,6 +38,21 @@
  * for the best explanations of this ordering.
  */
 
+/*
+ * If a bitmap has a number of bits which is not a multiple of 8 then
+ * the last few bits of the last byte of the bitmap can be
+ * unexpectedly set which can confuse consumers (e.g. in the tools)
+ * who also round up their loops to 8 bits. Ensure we clear those left
+ * over bits so as to prevent surprises.
+ */
+static void clamp_last_byte(uint8_t *bp, int nbits)
+{
+	int remainder = nbits % 8;
+
+	if (remainder)
+		bp[nbits/8] &= ((1U<<remainder)-1);
+}
+
 int __bitmap_empty(const unsigned long *bitmap, int bits)
 {
 	int k, lim = bits/BITS_PER_LONG;
@@ -485,6 +500,7 @@ void bitmap_long_to_byte(uint8_t *bp, co
 			nbits -= 8;
 		}
 	}
+	clamp_last_byte(bp, nbits);
 }
 
 void bitmap_byte_to_long(unsigned long *lp, const uint8_t *bp, int nbits)
@@ -507,6 +523,7 @@ void bitmap_byte_to_long(unsigned long *
 void bitmap_long_to_byte(uint8_t *bp, const unsigned long *lp, int nbits)
 {
 	memcpy(bp, lp, (nbits+7)/8);
+	clamp_last_byte(bp, nbits);
 }
 
 void bitmap_byte_to_long(unsigned long *lp, const uint8_t *bp, int nbits)



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

From xen-devel-bounces@lists.xen.org Thu Sep 06 13:50:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 2012 13:50: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 1T9cTC-0004eQ-C4; Thu, 06 Sep 2012 13:50:10 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <linux@eikelenboom.it>) id 1T9cTB-0004eB-3x
	for xen-devel@lists.xensource.com; Thu, 06 Sep 2012 13:50:09 +0000
Received: from [85.158.138.51:16133] by server-2.bemta-3.messagelabs.com id
	DC/26-04862-01AA8405; Thu, 06 Sep 2012 13:50:08 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-12.tower-174.messagelabs.com!1346939407!21127759!1
X-Originating-IP: [188.40.164.121]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7459 invoked from network); 6 Sep 2012 13:50:07 -0000
Received: from static.121.164.40.188.clients.your-server.de (HELO
	smtp.eikelenboom.it) (188.40.164.121)
	by server-12.tower-174.messagelabs.com with AES256-SHA encrypted SMTP;
	6 Sep 2012 13:50:07 -0000
Received: from 128-64-ftth.onsneteindhoven.nl ([88.159.64.128]:53370
	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 1T9cT9-0007qM-98; Thu, 06 Sep 2012 15:50:07 +0200
Date: Thu, 6 Sep 2012 15:50:01 +0200
From: Sander Eikelenboom <linux@eikelenboom.it>
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <483486315.20120906155001@eikelenboom.it>
To: Wei Wang <wei.wang2@amd.com>
In-Reply-To: <5048A603.3070207@amd.com>
References: <504764E2.4000809@amd.com>
	<326589347.20120906005936@eikelenboom.it>
	<5048A603.3070207@amd.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH] amd iommu: Dump flags of IO page faults
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


Thursday, September 6, 2012, 3:32:51 PM, you wrote:

> On 09/06/2012 12:59 AM, Sander Eikelenboom wrote:
>>
>> Wednesday, September 5, 2012, 4:42:42 PM, you wrote:
>>
>>> Hi Jan,
>>> Attached patch dumps io page fault flags. The flags show the reason of
>>> the fault and tell us if this is an unmapped interrupt fault or a DMA fault.
>>
>>> Thanks,
>>> Wei
>>
>>> signed-off-by: Wei Wang<wei.wang2@amd.com>
>>
>>
>> I have applied the patch and the flags seem to differ between the faults:
>>
>> AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0a06, fault address = 0xc2c2c2c0, flags = 0x000
>> (XEN) [2012-09-05 20:54:16] AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0a06, fault address = 0xc2c2c2c0, flags = 0x000
>> (XEN) [2012-09-05 20:54:16] AMD-Vi: IO_PAGE_FAULT: domain = 14, device id = 0x0700, fault address = 0xa8d339e0, flags = 0x020
>> (XEN) [2012-09-05 20:54:16] AMD-Vi: IO_PAGE_FAULT: domain = 14, device id = 0x0700, fault address = 0xa8d33a40, flags = 0x020

> OK, so they are not interrupt requests. I guess further information from 
> your system would be helpful to debug this issue:
> 1) xl info
> 2) xl list
> 3) lscpi -vvv (NOTE: not in dom0 but in your guest)
> 4) cat /proc/iomem (in both dom0 and your hvm guest)

dom14 is not a HVM guest,it's a PV guest.

I will try to make a complete package, and try with one pv domain only where the devices are being passed through just to simplify the setup.


> * I would also like to know the symptoms of device 0x0700 when IO_PF 
> happened. Did it stop working?

Yes it stops working, the video capture just freezes, but the driver doesn't bail out.
For the USB controller (0x0a06) it starts to give errors for usbdev_open in the guest.

> (BTW: I copied a few options from your boot cmd line and it worked with 
> my RD890 system

> dom0_mem=1024M,max:1024M loglvl=all loglvl_guest=all console_timestamps 
> cpuidle cpufreq=xen noreboot debug lapic=debug apic_verbosity=debug 
> apic=debug iommu=on,verbose,debug,no-sharept

> * so, what OEM board you have?)

MSI 890FXA-GD70

> Also from your log, these lines looks very strange:

> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to 
> read-only memory page. gfn=0xd5, mfn=0xa4a11
> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to 
> read-only memory page. gfn=0xd7, mfn=0xa4a0f
> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to 
> read-only memory page. gfn=0xd9, mfn=0xa4a0d
> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to 
> read-only memory page. gfn=0xdb, mfn=0xa4a0b
> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to 
> read-only memory page. gfn=0xdd, mfn=0xa4a09
> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to 
> read-only memory page. gfn=0xdf, mfn=0xa4a07
> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to 
> read-only memory page. gfn=0xe1, mfn=0xa4a05
> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to 
> read-only memory page. gfn=0xe3, mfn=0xa4a03
> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to 
> read-only memory page. gfn=0xe5, mfn=0xa4a01
> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to 
> read-only memory page. gfn=0xe7, mfn=0xa463f
> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to 
> read-only memory page. gfn=0xe9, mfn=0xa463d
> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to 
> read-only memory page. gfn=0xeb, mfn=0xa463b
> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to 
> read-only memory page. gfn=0xed, mfn=0xa4639
> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to 
> read-only memory page. gfn=0xef, mfn=0xa4637
> (XEN) [2012-09-04 16:13:56] AMD-Vi: IO_PAGE_FAULT: domain = 0, device id 
> = 0x0a06, fault address = 0xc2c2c2c0
> (XEN) [2012-09-04 16:13:56] AMD-Vi: IO_PAGE_FAULT: domain = 14, device 
> id = 0x0700, fault address = 0xa90f8300
> (XEN) [2012-09-04 16:13:56] AMD-Vi: IO_PAGE_FAULT: domain = 14, device 
> id = 0x0700, fault address = 0xa90f8340
> (XEN) [2012-09-04 16:13:56] AMD-Vi: IO_PAGE_FAULT: domain = 14, device 
> id = 0x0700, fault address = 0xa90f8380
> (XEN) [2012-09-04 16:13:56] AMD-Vi: IO_PAGE_FAULT: domain = 14, device 
> id = 0x0700, fault address = 0xa90f83c0

> * they are just followed by the IO PAGE fault. Do you know where are 
> they from? Your video card driver maybe?

>From a HVM domain with a old (3.0.3) kernel, but the faults also occur without this domain being started.


> Thanks,
> Wei


>> Complete xl dmesg and lspci -vvvknn attached.
>>
>> Thx
>>
>> --
>> Sander





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

From xen-devel-bounces@lists.xen.org Thu Sep 06 13:50:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 2012 13:50: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 1T9cTC-0004eQ-C4; Thu, 06 Sep 2012 13:50:10 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <linux@eikelenboom.it>) id 1T9cTB-0004eB-3x
	for xen-devel@lists.xensource.com; Thu, 06 Sep 2012 13:50:09 +0000
Received: from [85.158.138.51:16133] by server-2.bemta-3.messagelabs.com id
	DC/26-04862-01AA8405; Thu, 06 Sep 2012 13:50:08 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-12.tower-174.messagelabs.com!1346939407!21127759!1
X-Originating-IP: [188.40.164.121]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7459 invoked from network); 6 Sep 2012 13:50:07 -0000
Received: from static.121.164.40.188.clients.your-server.de (HELO
	smtp.eikelenboom.it) (188.40.164.121)
	by server-12.tower-174.messagelabs.com with AES256-SHA encrypted SMTP;
	6 Sep 2012 13:50:07 -0000
Received: from 128-64-ftth.onsneteindhoven.nl ([88.159.64.128]:53370
	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 1T9cT9-0007qM-98; Thu, 06 Sep 2012 15:50:07 +0200
Date: Thu, 6 Sep 2012 15:50:01 +0200
From: Sander Eikelenboom <linux@eikelenboom.it>
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <483486315.20120906155001@eikelenboom.it>
To: Wei Wang <wei.wang2@amd.com>
In-Reply-To: <5048A603.3070207@amd.com>
References: <504764E2.4000809@amd.com>
	<326589347.20120906005936@eikelenboom.it>
	<5048A603.3070207@amd.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH] amd iommu: Dump flags of IO page faults
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


Thursday, September 6, 2012, 3:32:51 PM, you wrote:

> On 09/06/2012 12:59 AM, Sander Eikelenboom wrote:
>>
>> Wednesday, September 5, 2012, 4:42:42 PM, you wrote:
>>
>>> Hi Jan,
>>> Attached patch dumps io page fault flags. The flags show the reason of
>>> the fault and tell us if this is an unmapped interrupt fault or a DMA fault.
>>
>>> Thanks,
>>> Wei
>>
>>> signed-off-by: Wei Wang<wei.wang2@amd.com>
>>
>>
>> I have applied the patch and the flags seem to differ between the faults:
>>
>> AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0a06, fault address = 0xc2c2c2c0, flags = 0x000
>> (XEN) [2012-09-05 20:54:16] AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0a06, fault address = 0xc2c2c2c0, flags = 0x000
>> (XEN) [2012-09-05 20:54:16] AMD-Vi: IO_PAGE_FAULT: domain = 14, device id = 0x0700, fault address = 0xa8d339e0, flags = 0x020
>> (XEN) [2012-09-05 20:54:16] AMD-Vi: IO_PAGE_FAULT: domain = 14, device id = 0x0700, fault address = 0xa8d33a40, flags = 0x020

> OK, so they are not interrupt requests. I guess further information from 
> your system would be helpful to debug this issue:
> 1) xl info
> 2) xl list
> 3) lscpi -vvv (NOTE: not in dom0 but in your guest)
> 4) cat /proc/iomem (in both dom0 and your hvm guest)

dom14 is not a HVM guest,it's a PV guest.

I will try to make a complete package, and try with one pv domain only where the devices are being passed through just to simplify the setup.


> * I would also like to know the symptoms of device 0x0700 when IO_PF 
> happened. Did it stop working?

Yes it stops working, the video capture just freezes, but the driver doesn't bail out.
For the USB controller (0x0a06) it starts to give errors for usbdev_open in the guest.

> (BTW: I copied a few options from your boot cmd line and it worked with 
> my RD890 system

> dom0_mem=1024M,max:1024M loglvl=all loglvl_guest=all console_timestamps 
> cpuidle cpufreq=xen noreboot debug lapic=debug apic_verbosity=debug 
> apic=debug iommu=on,verbose,debug,no-sharept

> * so, what OEM board you have?)

MSI 890FXA-GD70

> Also from your log, these lines looks very strange:

> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to 
> read-only memory page. gfn=0xd5, mfn=0xa4a11
> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to 
> read-only memory page. gfn=0xd7, mfn=0xa4a0f
> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to 
> read-only memory page. gfn=0xd9, mfn=0xa4a0d
> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to 
> read-only memory page. gfn=0xdb, mfn=0xa4a0b
> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to 
> read-only memory page. gfn=0xdd, mfn=0xa4a09
> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to 
> read-only memory page. gfn=0xdf, mfn=0xa4a07
> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to 
> read-only memory page. gfn=0xe1, mfn=0xa4a05
> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to 
> read-only memory page. gfn=0xe3, mfn=0xa4a03
> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to 
> read-only memory page. gfn=0xe5, mfn=0xa4a01
> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to 
> read-only memory page. gfn=0xe7, mfn=0xa463f
> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to 
> read-only memory page. gfn=0xe9, mfn=0xa463d
> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to 
> read-only memory page. gfn=0xeb, mfn=0xa463b
> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to 
> read-only memory page. gfn=0xed, mfn=0xa4639
> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to 
> read-only memory page. gfn=0xef, mfn=0xa4637
> (XEN) [2012-09-04 16:13:56] AMD-Vi: IO_PAGE_FAULT: domain = 0, device id 
> = 0x0a06, fault address = 0xc2c2c2c0
> (XEN) [2012-09-04 16:13:56] AMD-Vi: IO_PAGE_FAULT: domain = 14, device 
> id = 0x0700, fault address = 0xa90f8300
> (XEN) [2012-09-04 16:13:56] AMD-Vi: IO_PAGE_FAULT: domain = 14, device 
> id = 0x0700, fault address = 0xa90f8340
> (XEN) [2012-09-04 16:13:56] AMD-Vi: IO_PAGE_FAULT: domain = 14, device 
> id = 0x0700, fault address = 0xa90f8380
> (XEN) [2012-09-04 16:13:56] AMD-Vi: IO_PAGE_FAULT: domain = 14, device 
> id = 0x0700, fault address = 0xa90f83c0

> * they are just followed by the IO PAGE fault. Do you know where are 
> they from? Your video card driver maybe?

>From a HVM domain with a old (3.0.3) kernel, but the faults also occur without this domain being started.


> Thanks,
> Wei


>> Complete xl dmesg and lspci -vvvknn attached.
>>
>> Thx
>>
>> --
>> Sander





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

From xen-devel-bounces@lists.xen.org Thu Sep 06 13:50:33 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 2012 13:50:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9cTR-0004g6-PV; Thu, 06 Sep 2012 13:50:25 +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 1T9cTQ-0004ft-KV
	for xen-devel@lists.xen.org; Thu, 06 Sep 2012 13:50:24 +0000
Received: from [85.158.143.99:6662] by server-3.bemta-4.messagelabs.com id
	19/3F-08232-F1AA8405; Thu, 06 Sep 2012 13:50:23 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-11.tower-216.messagelabs.com!1346939421!21386729!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27138 invoked from network); 6 Sep 2012 13:50:22 -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; 6 Sep 2012 13:50:22 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1T9cTM-000Fa4-Qt; Thu, 06 Sep 2012 13:50:20 +0000
Date: Thu, 6 Sep 2012 14:50:20 +0100
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <ian.campbell@citrix.com>
Message-ID: <20120906135020.GO56463@ocelot.phlegethon.org>
References: <1346678886.32462.9.camel@zakaz.uk.xensource.com>
	<1346679056-8108-16-git-send-email-ian.campbell@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1346679056-8108-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/16] arm: use /chosen/module1-args for
	domain 0 command line
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At 13:30 +0000 on 03 Sep (1346679056), Ian Campbell wrote:
> Ideally this would use module1-args iff the kernel came from
> module1-{start,end} and the existing xen,dom0-bootargs if the kernel
> came from flash, but this approach is simpler and has the sme effect
> in practice.
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> ---
>  xen/arch/arm/domain_build.c |   23 ++++++++++++++++++++---
>  1 files changed, 20 insertions(+), 3 deletions(-)
> 
> diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
> index e96ed10..2b65637 100644
> --- a/xen/arch/arm/domain_build.c
> +++ b/xen/arch/arm/domain_build.c
> @@ -88,6 +88,8 @@ static int write_properties(struct domain *d, struct kernel_info *kinfo,
>  {
>      int prop;
>  
> +    int had_mod1_args = 0;
> +
>      for ( prop = fdt_first_property_offset(fdt, node);
>            prop >= 0;
>            prop = fdt_next_property_offset(fdt, prop) )
> @@ -104,15 +106,30 @@ static int write_properties(struct domain *d, struct kernel_info *kinfo,
>          prop_len  = fdt32_to_cpu(p->len);
>  
>          /*
> -         * In chosen node: replace bootargs with value from
> -         * xen,dom0-bootargs.
> +         * In chosen node:
> +         *
> +         * * replace bootargs with value from module1-args, falling
> +         *   back to xen,dom0-bootargs if not present.
> +         * * remove all other module*.
>           */
>          if ( device_tree_node_matches(fdt, node, "chosen") )
>          {
>              if ( strcmp(prop_name, "bootargs") == 0 )
>                  continue;
> -            if ( strcmp(prop_name, "xen,dom0-bootargs") == 0 )
> +            if ( strcmp(prop_name, "module1-args") == 0 )
> +            {
>                  prop_name = "bootargs";
> +                had_mod1_args = 1;
> +            }
> +            if ( strncmp(prop_name, "module", strlen("module")) == 0 )
> +                 continue;

ITYM "else if" here, or the module1-args property gets dropped too,
doesn't it?  

Tim.

> +            if ( strcmp(prop_name, "xen,dom0-bootargs") == 0 )
> +            {
> +                if ( had_mod1_args )
> +                    continue;
> +                else
> +                    prop_name = "bootargs";
> +            }
>          }
>          /*
>           * In a memory node: adjust reg property.
> -- 
> 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 Sep 06 13:50:33 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 2012 13:50:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9cTR-0004g6-PV; Thu, 06 Sep 2012 13:50:25 +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 1T9cTQ-0004ft-KV
	for xen-devel@lists.xen.org; Thu, 06 Sep 2012 13:50:24 +0000
Received: from [85.158.143.99:6662] by server-3.bemta-4.messagelabs.com id
	19/3F-08232-F1AA8405; Thu, 06 Sep 2012 13:50:23 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-11.tower-216.messagelabs.com!1346939421!21386729!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27138 invoked from network); 6 Sep 2012 13:50:22 -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; 6 Sep 2012 13:50:22 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1T9cTM-000Fa4-Qt; Thu, 06 Sep 2012 13:50:20 +0000
Date: Thu, 6 Sep 2012 14:50:20 +0100
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <ian.campbell@citrix.com>
Message-ID: <20120906135020.GO56463@ocelot.phlegethon.org>
References: <1346678886.32462.9.camel@zakaz.uk.xensource.com>
	<1346679056-8108-16-git-send-email-ian.campbell@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1346679056-8108-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/16] arm: use /chosen/module1-args for
	domain 0 command line
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At 13:30 +0000 on 03 Sep (1346679056), Ian Campbell wrote:
> Ideally this would use module1-args iff the kernel came from
> module1-{start,end} and the existing xen,dom0-bootargs if the kernel
> came from flash, but this approach is simpler and has the sme effect
> in practice.
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> ---
>  xen/arch/arm/domain_build.c |   23 ++++++++++++++++++++---
>  1 files changed, 20 insertions(+), 3 deletions(-)
> 
> diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
> index e96ed10..2b65637 100644
> --- a/xen/arch/arm/domain_build.c
> +++ b/xen/arch/arm/domain_build.c
> @@ -88,6 +88,8 @@ static int write_properties(struct domain *d, struct kernel_info *kinfo,
>  {
>      int prop;
>  
> +    int had_mod1_args = 0;
> +
>      for ( prop = fdt_first_property_offset(fdt, node);
>            prop >= 0;
>            prop = fdt_next_property_offset(fdt, prop) )
> @@ -104,15 +106,30 @@ static int write_properties(struct domain *d, struct kernel_info *kinfo,
>          prop_len  = fdt32_to_cpu(p->len);
>  
>          /*
> -         * In chosen node: replace bootargs with value from
> -         * xen,dom0-bootargs.
> +         * In chosen node:
> +         *
> +         * * replace bootargs with value from module1-args, falling
> +         *   back to xen,dom0-bootargs if not present.
> +         * * remove all other module*.
>           */
>          if ( device_tree_node_matches(fdt, node, "chosen") )
>          {
>              if ( strcmp(prop_name, "bootargs") == 0 )
>                  continue;
> -            if ( strcmp(prop_name, "xen,dom0-bootargs") == 0 )
> +            if ( strcmp(prop_name, "module1-args") == 0 )
> +            {
>                  prop_name = "bootargs";
> +                had_mod1_args = 1;
> +            }
> +            if ( strncmp(prop_name, "module", strlen("module")) == 0 )
> +                 continue;

ITYM "else if" here, or the module1-args property gets dropped too,
doesn't it?  

Tim.

> +            if ( strcmp(prop_name, "xen,dom0-bootargs") == 0 )
> +            {
> +                if ( had_mod1_args )
> +                    continue;
> +                else
> +                    prop_name = "bootargs";
> +            }
>          }
>          /*
>           * In a memory node: adjust reg property.
> -- 
> 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 Sep 06 13:53:22 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 2012 13: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 1T9cWA-000544-CB; Thu, 06 Sep 2012 13:53:14 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1T9cW8-00053i-Si
	for xen-devel@lists.xen.org; Thu, 06 Sep 2012 13:53:12 +0000
Received: from [85.158.138.51:27083] by server-4.bemta-3.messagelabs.com id
	F6/4C-24831-7CAA8405; Thu, 06 Sep 2012 13:53:11 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-14.tower-174.messagelabs.com!1346939591!22718212!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22920 invoked from network); 6 Sep 2012 13:53:11 -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; 6 Sep 2012 13:53:11 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1T9cW6-000Fat-Or; Thu, 06 Sep 2012 13:53:10 +0000
Date: Thu, 6 Sep 2012 14:53:10 +0100
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <ian.campbell@citrix.com>
Message-ID: <20120906135310.GP56463@ocelot.phlegethon.org>
References: <1346678886.32462.9.camel@zakaz.uk.xensource.com>
	<1346679056-8108-15-git-send-email-ian.campbell@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1346679056-8108-15-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 15/16] arm: discard boot modules after
	building domain 0.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


At 13:30 +0000 on 03 Sep (1346679055), Ian Campbell wrote:
> +void __init discard_initial_modules(void)
> +{
> +    struct dt_module_info *mi = &early_info.modules;
> +    int i;
> +
> +    for ( i = 0; i < mi->nr_mods; i++ )
> +    {
> +        paddr_t s = mi->module[i].start;
> +        paddr_t e = s + PAGE_ALIGN(mi->module[i].size);
> +
> +        init_domheap_pages(s, e);

Is there a risk of weirdness from adding non-superpage-aligned memory to
the domheap here, given that map_domain_page always uses 2MB mappings?

> +    }
> +
> +    mi->nr_mods = 0;
> +}

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

From xen-devel-bounces@lists.xen.org Thu Sep 06 13:53:22 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 2012 13: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 1T9cWA-000544-CB; Thu, 06 Sep 2012 13:53:14 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1T9cW8-00053i-Si
	for xen-devel@lists.xen.org; Thu, 06 Sep 2012 13:53:12 +0000
Received: from [85.158.138.51:27083] by server-4.bemta-3.messagelabs.com id
	F6/4C-24831-7CAA8405; Thu, 06 Sep 2012 13:53:11 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-14.tower-174.messagelabs.com!1346939591!22718212!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22920 invoked from network); 6 Sep 2012 13:53:11 -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; 6 Sep 2012 13:53:11 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1T9cW6-000Fat-Or; Thu, 06 Sep 2012 13:53:10 +0000
Date: Thu, 6 Sep 2012 14:53:10 +0100
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <ian.campbell@citrix.com>
Message-ID: <20120906135310.GP56463@ocelot.phlegethon.org>
References: <1346678886.32462.9.camel@zakaz.uk.xensource.com>
	<1346679056-8108-15-git-send-email-ian.campbell@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1346679056-8108-15-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 15/16] arm: discard boot modules after
	building domain 0.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


At 13:30 +0000 on 03 Sep (1346679055), Ian Campbell wrote:
> +void __init discard_initial_modules(void)
> +{
> +    struct dt_module_info *mi = &early_info.modules;
> +    int i;
> +
> +    for ( i = 0; i < mi->nr_mods; i++ )
> +    {
> +        paddr_t s = mi->module[i].start;
> +        paddr_t e = s + PAGE_ALIGN(mi->module[i].size);
> +
> +        init_domheap_pages(s, e);

Is there a risk of weirdness from adding non-superpage-aligned memory to
the domheap here, given that map_domain_page always uses 2MB mappings?

> +    }
> +
> +    mi->nr_mods = 0;
> +}

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

From xen-devel-bounces@lists.xen.org Thu Sep 06 13:55:19 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 2012 13:55: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 1T9cY1-0005Jn-Tl; Thu, 06 Sep 2012 13:55:09 +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 1T9cY0-0005JJ-97
	for xen-devel@lists.xen.org; Thu, 06 Sep 2012 13:55:08 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1346939701!8465722!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTE5NzY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14842 invoked from network); 6 Sep 2012 13:55:01 -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 Sep 2012 13:55:01 -0000
X-IronPort-AV: E=Sophos;i="4.80,380,1344211200"; d="scan'208";a="14387728"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Sep 2012 13:55:01 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Thu, 6 Sep 2012
	14:55:01 +0100
Message-ID: <1346939700.30018.15.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Tim Deegan <tim@xen.org>
Date: Thu, 6 Sep 2012 14:55:00 +0100
In-Reply-To: <20120906135020.GO56463@ocelot.phlegethon.org>
References: <1346678886.32462.9.camel@zakaz.uk.xensource.com>
	<1346679056-8108-16-git-send-email-ian.campbell@citrix.com>
	<20120906135020.GO56463@ocelot.phlegethon.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 16/16] arm: use /chosen/module1-args for
 domain 0 command line
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-09-06 at 14:50 +0100, Tim Deegan wrote:
> At 13:30 +0000 on 03 Sep (1346679056), Ian Campbell wrote:
> > Ideally this would use module1-args iff the kernel came from
> > module1-{start,end} and the existing xen,dom0-bootargs if the kernel
> > came from flash, but this approach is simpler and has the sme effect
> > in practice.
> > 
> > Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> > ---
> >  xen/arch/arm/domain_build.c |   23 ++++++++++++++++++++---
> >  1 files changed, 20 insertions(+), 3 deletions(-)
> > 
> > diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
> > index e96ed10..2b65637 100644
> > --- a/xen/arch/arm/domain_build.c
> > +++ b/xen/arch/arm/domain_build.c
> > @@ -88,6 +88,8 @@ static int write_properties(struct domain *d, struct kernel_info *kinfo,
> >  {
> >      int prop;
> >  
> > +    int had_mod1_args = 0;
> > +
> >      for ( prop = fdt_first_property_offset(fdt, node);
> >            prop >= 0;
> >            prop = fdt_next_property_offset(fdt, prop) )
> > @@ -104,15 +106,30 @@ static int write_properties(struct domain *d, struct kernel_info *kinfo,
> >          prop_len  = fdt32_to_cpu(p->len);
> >  
> >          /*
> > -         * In chosen node: replace bootargs with value from
> > -         * xen,dom0-bootargs.
> > +         * In chosen node:
> > +         *
> > +         * * replace bootargs with value from module1-args, falling
> > +         *   back to xen,dom0-bootargs if not present.
> > +         * * remove all other module*.
> >           */
> >          if ( device_tree_node_matches(fdt, node, "chosen") )
> >          {
> >              if ( strcmp(prop_name, "bootargs") == 0 )
> >                  continue;
> > -            if ( strcmp(prop_name, "xen,dom0-bootargs") == 0 )
> > +            if ( strcmp(prop_name, "module1-args") == 0 )
> > +            {
> >                  prop_name = "bootargs";
> > +                had_mod1_args = 1;
> > +            }
> > +            if ( strncmp(prop_name, "module", strlen("module")) == 0 )
> > +                 continue;
> 
> ITYM "else if" here, or the module1-args property gets dropped too,
> doesn't it?  

The intention was to filter "module*" from the DTB altogether, since
they were intended for Xen not dom0. All that should remain is
module1-args which has been renamed to bootargs which is what dom0
expects.

That isn't really mentioned in the commit log but I did at least comment
it above ;-)

> 
> Tim.
> 
> > +            if ( strcmp(prop_name, "xen,dom0-bootargs") == 0 )
> > +            {
> > +                if ( had_mod1_args )
> > +                    continue;
> > +                else
> > +                    prop_name = "bootargs";
> > +            }
> >          }
> >          /*
> >           * In a memory node: adjust reg property.
> > -- 
> > 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 Sep 06 13:55:19 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 2012 13:55: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 1T9cY1-0005Jn-Tl; Thu, 06 Sep 2012 13:55:09 +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 1T9cY0-0005JJ-97
	for xen-devel@lists.xen.org; Thu, 06 Sep 2012 13:55:08 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1346939701!8465722!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTE5NzY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14842 invoked from network); 6 Sep 2012 13:55:01 -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 Sep 2012 13:55:01 -0000
X-IronPort-AV: E=Sophos;i="4.80,380,1344211200"; d="scan'208";a="14387728"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Sep 2012 13:55:01 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Thu, 6 Sep 2012
	14:55:01 +0100
Message-ID: <1346939700.30018.15.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Tim Deegan <tim@xen.org>
Date: Thu, 6 Sep 2012 14:55:00 +0100
In-Reply-To: <20120906135020.GO56463@ocelot.phlegethon.org>
References: <1346678886.32462.9.camel@zakaz.uk.xensource.com>
	<1346679056-8108-16-git-send-email-ian.campbell@citrix.com>
	<20120906135020.GO56463@ocelot.phlegethon.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 16/16] arm: use /chosen/module1-args for
 domain 0 command line
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-09-06 at 14:50 +0100, Tim Deegan wrote:
> At 13:30 +0000 on 03 Sep (1346679056), Ian Campbell wrote:
> > Ideally this would use module1-args iff the kernel came from
> > module1-{start,end} and the existing xen,dom0-bootargs if the kernel
> > came from flash, but this approach is simpler and has the sme effect
> > in practice.
> > 
> > Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> > ---
> >  xen/arch/arm/domain_build.c |   23 ++++++++++++++++++++---
> >  1 files changed, 20 insertions(+), 3 deletions(-)
> > 
> > diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
> > index e96ed10..2b65637 100644
> > --- a/xen/arch/arm/domain_build.c
> > +++ b/xen/arch/arm/domain_build.c
> > @@ -88,6 +88,8 @@ static int write_properties(struct domain *d, struct kernel_info *kinfo,
> >  {
> >      int prop;
> >  
> > +    int had_mod1_args = 0;
> > +
> >      for ( prop = fdt_first_property_offset(fdt, node);
> >            prop >= 0;
> >            prop = fdt_next_property_offset(fdt, prop) )
> > @@ -104,15 +106,30 @@ static int write_properties(struct domain *d, struct kernel_info *kinfo,
> >          prop_len  = fdt32_to_cpu(p->len);
> >  
> >          /*
> > -         * In chosen node: replace bootargs with value from
> > -         * xen,dom0-bootargs.
> > +         * In chosen node:
> > +         *
> > +         * * replace bootargs with value from module1-args, falling
> > +         *   back to xen,dom0-bootargs if not present.
> > +         * * remove all other module*.
> >           */
> >          if ( device_tree_node_matches(fdt, node, "chosen") )
> >          {
> >              if ( strcmp(prop_name, "bootargs") == 0 )
> >                  continue;
> > -            if ( strcmp(prop_name, "xen,dom0-bootargs") == 0 )
> > +            if ( strcmp(prop_name, "module1-args") == 0 )
> > +            {
> >                  prop_name = "bootargs";
> > +                had_mod1_args = 1;
> > +            }
> > +            if ( strncmp(prop_name, "module", strlen("module")) == 0 )
> > +                 continue;
> 
> ITYM "else if" here, or the module1-args property gets dropped too,
> doesn't it?  

The intention was to filter "module*" from the DTB altogether, since
they were intended for Xen not dom0. All that should remain is
module1-args which has been renamed to bootargs which is what dom0
expects.

That isn't really mentioned in the commit log but I did at least comment
it above ;-)

> 
> Tim.
> 
> > +            if ( strcmp(prop_name, "xen,dom0-bootargs") == 0 )
> > +            {
> > +                if ( had_mod1_args )
> > +                    continue;
> > +                else
> > +                    prop_name = "bootargs";
> > +            }
> >          }
> >          /*
> >           * In a memory node: adjust reg property.
> > -- 
> > 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 Sep 06 13:57:49 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 2012 13:57:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9caT-0005Uu-Lj; Thu, 06 Sep 2012 13:57: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 1T9caS-0005Uk-6S
	for xen-devel@lists.xen.org; Thu, 06 Sep 2012 13:57:40 +0000
Received: from [85.158.138.51:35762] by server-5.bemta-3.messagelabs.com id
	75/61-13133-3DBA8405; Thu, 06 Sep 2012 13:57:39 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1346939858!22719581!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTE5NzY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20673 invoked from network); 6 Sep 2012 13:57:38 -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;
	6 Sep 2012 13:57:38 -0000
X-IronPort-AV: E=Sophos;i="4.80,380,1344211200"; d="scan'208";a="14387794"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Sep 2012 13:57: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.279.1; Thu, 6 Sep 2012
	14:57:38 +0100
Message-ID: <1346939856.30018.17.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Tim Deegan <tim@xen.org>
Date: Thu, 6 Sep 2012 14:57:36 +0100
In-Reply-To: <20120906135310.GP56463@ocelot.phlegethon.org>
References: <1346678886.32462.9.camel@zakaz.uk.xensource.com>
	<1346679056-8108-15-git-send-email-ian.campbell@citrix.com>
	<20120906135310.GP56463@ocelot.phlegethon.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 15/16] arm: discard boot modules after
 building domain 0.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-09-06 at 14:53 +0100, Tim Deegan wrote:
> At 13:30 +0000 on 03 Sep (1346679055), Ian Campbell wrote:
> > +void __init discard_initial_modules(void)
> > +{
> > +    struct dt_module_info *mi = &early_info.modules;
> > +    int i;
> > +
> > +    for ( i = 0; i < mi->nr_mods; i++ )
> > +    {
> > +        paddr_t s = mi->module[i].start;
> > +        paddr_t e = s + PAGE_ALIGN(mi->module[i].size);
> > +
> > +        init_domheap_pages(s, e);
> 
> Is there a risk of weirdness from adding non-superpage-aligned memory to
> the domheap here, given that map_domain_page always uses 2MB mappings?

I hadn't thought about this.

These regions will mesh precisely with what setup_mm has added and
therefore the result is that the entire 2MB is on the heap, I think.

These non-aligned looking regions are actually within larger regions of
RAM so I don't think there is any danger of actually mapping some
non-RAM as part of such a 2MB mapping?

Ian.


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

From xen-devel-bounces@lists.xen.org Thu Sep 06 13:57:49 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 2012 13:57:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9caT-0005Uu-Lj; Thu, 06 Sep 2012 13:57: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 1T9caS-0005Uk-6S
	for xen-devel@lists.xen.org; Thu, 06 Sep 2012 13:57:40 +0000
Received: from [85.158.138.51:35762] by server-5.bemta-3.messagelabs.com id
	75/61-13133-3DBA8405; Thu, 06 Sep 2012 13:57:39 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1346939858!22719581!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTE5NzY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20673 invoked from network); 6 Sep 2012 13:57:38 -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;
	6 Sep 2012 13:57:38 -0000
X-IronPort-AV: E=Sophos;i="4.80,380,1344211200"; d="scan'208";a="14387794"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Sep 2012 13:57: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.279.1; Thu, 6 Sep 2012
	14:57:38 +0100
Message-ID: <1346939856.30018.17.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Tim Deegan <tim@xen.org>
Date: Thu, 6 Sep 2012 14:57:36 +0100
In-Reply-To: <20120906135310.GP56463@ocelot.phlegethon.org>
References: <1346678886.32462.9.camel@zakaz.uk.xensource.com>
	<1346679056-8108-15-git-send-email-ian.campbell@citrix.com>
	<20120906135310.GP56463@ocelot.phlegethon.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 15/16] arm: discard boot modules after
 building domain 0.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-09-06 at 14:53 +0100, Tim Deegan wrote:
> At 13:30 +0000 on 03 Sep (1346679055), Ian Campbell wrote:
> > +void __init discard_initial_modules(void)
> > +{
> > +    struct dt_module_info *mi = &early_info.modules;
> > +    int i;
> > +
> > +    for ( i = 0; i < mi->nr_mods; i++ )
> > +    {
> > +        paddr_t s = mi->module[i].start;
> > +        paddr_t e = s + PAGE_ALIGN(mi->module[i].size);
> > +
> > +        init_domheap_pages(s, e);
> 
> Is there a risk of weirdness from adding non-superpage-aligned memory to
> the domheap here, given that map_domain_page always uses 2MB mappings?

I hadn't thought about this.

These regions will mesh precisely with what setup_mm has added and
therefore the result is that the entire 2MB is on the heap, I think.

These non-aligned looking regions are actually within larger regions of
RAM so I don't think there is any danger of actually mapping some
non-RAM as part of such a 2MB mapping?

Ian.


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

From xen-devel-bounces@lists.xen.org Thu Sep 06 13:59:02 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 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 1T9cbb-0005bf-CB; Thu, 06 Sep 2012 13:58:51 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1T9cbZ-0005bP-Tq
	for xen-devel@lists.xen.org; Thu, 06 Sep 2012 13:58:50 +0000
Received: from [85.158.143.35:6449] by server-1.bemta-4.messagelabs.com id
	8A/3B-12504-91CA8405; Thu, 06 Sep 2012 13:58:49 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-16.tower-21.messagelabs.com!1346939928!14494922!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15292 invoked from network); 6 Sep 2012 13:58:48 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-16.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 6 Sep 2012 13:58:48 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1T9cbY-000Fcn-8E; Thu, 06 Sep 2012 13:58:48 +0000
Date: Thu, 6 Sep 2012 14:58:48 +0100
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120906135848.GA59973@ocelot.phlegethon.org>
References: <1346678886.32462.9.camel@zakaz.uk.xensource.com>
	<1346679056-8108-16-git-send-email-ian.campbell@citrix.com>
	<20120906135020.GO56463@ocelot.phlegethon.org>
	<1346939700.30018.15.camel@zakaz.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1346939700.30018.15.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 16/16] arm: use /chosen/module1-args for
	domain 0 command line
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At 14:55 +0100 on 06 Sep (1346943300), Ian Campbell wrote:
> > >          if ( device_tree_node_matches(fdt, node, "chosen") )
> > >          {
> > >              if ( strcmp(prop_name, "bootargs") == 0 )
> > >                  continue;
> > > -            if ( strcmp(prop_name, "xen,dom0-bootargs") == 0 )
> > > +            if ( strcmp(prop_name, "module1-args") == 0 )
> > > +            {
> > >                  prop_name = "bootargs";
> > > +                had_mod1_args = 1;
> > > +            }
> > > +            if ( strncmp(prop_name, "module", strlen("module")) == 0 )
> > > +                 continue;
> > 
> > ITYM "else if" here, or the module1-args property gets dropped too,
> > doesn't it?  
> 
> The intention was to filter "module*" from the DTB altogether, since
> they were intended for Xen not dom0. All that should remain is
> module1-args which has been renamed to bootargs which is what dom0
> expects.

Argh, of course now prop_name's been clobbered it won't be filtered. :)
Sorry for the noise.

Acked-by: Tim Deegan <tim@xen.org>, though I imagine you'll want
David's ack rather than mine.

Tim.

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

From xen-devel-bounces@lists.xen.org Thu Sep 06 13:59:02 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 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 1T9cbb-0005bf-CB; Thu, 06 Sep 2012 13:58:51 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1T9cbZ-0005bP-Tq
	for xen-devel@lists.xen.org; Thu, 06 Sep 2012 13:58:50 +0000
Received: from [85.158.143.35:6449] by server-1.bemta-4.messagelabs.com id
	8A/3B-12504-91CA8405; Thu, 06 Sep 2012 13:58:49 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-16.tower-21.messagelabs.com!1346939928!14494922!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15292 invoked from network); 6 Sep 2012 13:58:48 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-16.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 6 Sep 2012 13:58:48 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1T9cbY-000Fcn-8E; Thu, 06 Sep 2012 13:58:48 +0000
Date: Thu, 6 Sep 2012 14:58:48 +0100
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120906135848.GA59973@ocelot.phlegethon.org>
References: <1346678886.32462.9.camel@zakaz.uk.xensource.com>
	<1346679056-8108-16-git-send-email-ian.campbell@citrix.com>
	<20120906135020.GO56463@ocelot.phlegethon.org>
	<1346939700.30018.15.camel@zakaz.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1346939700.30018.15.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 16/16] arm: use /chosen/module1-args for
	domain 0 command line
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At 14:55 +0100 on 06 Sep (1346943300), Ian Campbell wrote:
> > >          if ( device_tree_node_matches(fdt, node, "chosen") )
> > >          {
> > >              if ( strcmp(prop_name, "bootargs") == 0 )
> > >                  continue;
> > > -            if ( strcmp(prop_name, "xen,dom0-bootargs") == 0 )
> > > +            if ( strcmp(prop_name, "module1-args") == 0 )
> > > +            {
> > >                  prop_name = "bootargs";
> > > +                had_mod1_args = 1;
> > > +            }
> > > +            if ( strncmp(prop_name, "module", strlen("module")) == 0 )
> > > +                 continue;
> > 
> > ITYM "else if" here, or the module1-args property gets dropped too,
> > doesn't it?  
> 
> The intention was to filter "module*" from the DTB altogether, since
> they were intended for Xen not dom0. All that should remain is
> module1-args which has been renamed to bootargs which is what dom0
> expects.

Argh, of course now prop_name's been clobbered it won't be filtered. :)
Sorry for the noise.

Acked-by: Tim Deegan <tim@xen.org>, though I imagine you'll want
David's ack rather than mine.

Tim.

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

From xen-devel-bounces@lists.xen.org Thu Sep 06 13:59:22 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 2012 13: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 1T9cby-0005es-Pq; Thu, 06 Sep 2012 13:59:14 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <kks.kbase@gmail.com>)
	id 1T9caa-0005VA-AL; Thu, 06 Sep 2012 13:57:48 +0000
X-Env-Sender: kks.kbase@gmail.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1346939861!9884890!1
X-Originating-IP: [209.85.214.45]
X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32646 invoked from network); 6 Sep 2012 13:57:42 -0000
Received: from mail-bk0-f45.google.com (HELO mail-bk0-f45.google.com)
	(209.85.214.45)
	by server-8.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Sep 2012 13:57:42 -0000
Received: by bkcji1 with SMTP id ji1so819621bkc.32
	for <multiple recipients>; Thu, 06 Sep 2012 06:57:41 -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=5Er4xAIOsn/W+pqGTTQlPIyQZr3e2raR7Fs4HjGSk8Y=;
	b=kIt3mF4wOZFdgtWhegWJxdQNEDo1ZXLZeLkJX7wQ1pELJbQlGSxgmWbyfuRbvd69DL
	PD8T0udArAeqMfyTh5m+zyYMM1y7Yt068EwwsqUsQfrc43A9yWqiI7sPBQfY46Ncx0nc
	HcNaTVTa9bWTo75vmSvY0UyNw/PCu0zNQeSicCQ+CE/5P9uPeWWnwbarsVcjl+XhL5q/
	rlQr+d8r0LHMtkGQlAV93N50r8DyHC1HYFQi3eJu8rJWiwM7z41VAh/wDwUHTljDIK1W
	YqNN7XlHv191IU23nfiNXEpoo4817eOgZsK2SpZR9irj0F9gq9/RDxDTcrsjFelh/Lmg
	zBaA==
MIME-Version: 1.0
Received: by 10.205.127.72 with SMTP id gz8mr982906bkc.121.1346939861514; Thu,
	06 Sep 2012 06:57:41 -0700 (PDT)
Received: by 10.204.56.134 with HTTP; Thu, 6 Sep 2012 06:57:41 -0700 (PDT)
Date: Thu, 6 Sep 2012 19:27:41 +0530
Message-ID: <CAPU-Ed6Xrbf+uM+tqCM+AhYcjw=-8C-xd3iy7C8c+MP5BoxeRg@mail.gmail.com>
From: kk s <kks.kbase@gmail.com>
To: xen-users@lists.xen.org, xen-devel@lists.xen.org
X-Mailman-Approved-At: Thu, 06 Sep 2012 13:59:14 +0000
Subject: [Xen-devel] XSA patch help
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============5296329335915531691=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============5296329335915531691==
Content-Type: multipart/alternative; boundary=0015173fe992faba7504c908dfa8

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

Hi,

Finally I got success to applied all the patches on my server except "Xen
Security Advisory 15 (CVE-2012-3497)"
http://lists.xen.org/archives/html/xen-announce/2012-09/msg00006.html .

I don't know if this includes any patch or its just the information. If
anyone clear this up then I am happy that my servers are secured.

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

<div>Hi,<br></div><div><br></div><div>Finally I got success to applied all =
the patches on my server except &quot;Xen Security Advisory 15 (CVE-2012-34=
97)&quot; <a href=3D"http://lists.xen.org/archives/html/xen-announce/2012-0=
9/msg00006.html">http://lists.xen.org/archives/html/xen-announce/2012-09/ms=
g00006.html</a> .</div>
<div><br></div><div>I don&#39;t know if this includes any patch or its just=
 the information. If anyone clear this up then I am happy that my servers a=
re secured.</div><div><br></div>

--0015173fe992faba7504c908dfa8--


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

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

--===============5296329335915531691==--


From xen-devel-bounces@lists.xen.org Thu Sep 06 13:59:22 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 2012 13: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 1T9cby-0005es-Pq; Thu, 06 Sep 2012 13:59:14 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <kks.kbase@gmail.com>)
	id 1T9caa-0005VA-AL; Thu, 06 Sep 2012 13:57:48 +0000
X-Env-Sender: kks.kbase@gmail.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1346939861!9884890!1
X-Originating-IP: [209.85.214.45]
X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32646 invoked from network); 6 Sep 2012 13:57:42 -0000
Received: from mail-bk0-f45.google.com (HELO mail-bk0-f45.google.com)
	(209.85.214.45)
	by server-8.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Sep 2012 13:57:42 -0000
Received: by bkcji1 with SMTP id ji1so819621bkc.32
	for <multiple recipients>; Thu, 06 Sep 2012 06:57:41 -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=5Er4xAIOsn/W+pqGTTQlPIyQZr3e2raR7Fs4HjGSk8Y=;
	b=kIt3mF4wOZFdgtWhegWJxdQNEDo1ZXLZeLkJX7wQ1pELJbQlGSxgmWbyfuRbvd69DL
	PD8T0udArAeqMfyTh5m+zyYMM1y7Yt068EwwsqUsQfrc43A9yWqiI7sPBQfY46Ncx0nc
	HcNaTVTa9bWTo75vmSvY0UyNw/PCu0zNQeSicCQ+CE/5P9uPeWWnwbarsVcjl+XhL5q/
	rlQr+d8r0LHMtkGQlAV93N50r8DyHC1HYFQi3eJu8rJWiwM7z41VAh/wDwUHTljDIK1W
	YqNN7XlHv191IU23nfiNXEpoo4817eOgZsK2SpZR9irj0F9gq9/RDxDTcrsjFelh/Lmg
	zBaA==
MIME-Version: 1.0
Received: by 10.205.127.72 with SMTP id gz8mr982906bkc.121.1346939861514; Thu,
	06 Sep 2012 06:57:41 -0700 (PDT)
Received: by 10.204.56.134 with HTTP; Thu, 6 Sep 2012 06:57:41 -0700 (PDT)
Date: Thu, 6 Sep 2012 19:27:41 +0530
Message-ID: <CAPU-Ed6Xrbf+uM+tqCM+AhYcjw=-8C-xd3iy7C8c+MP5BoxeRg@mail.gmail.com>
From: kk s <kks.kbase@gmail.com>
To: xen-users@lists.xen.org, xen-devel@lists.xen.org
X-Mailman-Approved-At: Thu, 06 Sep 2012 13:59:14 +0000
Subject: [Xen-devel] XSA patch help
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============5296329335915531691=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============5296329335915531691==
Content-Type: multipart/alternative; boundary=0015173fe992faba7504c908dfa8

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

Hi,

Finally I got success to applied all the patches on my server except "Xen
Security Advisory 15 (CVE-2012-3497)"
http://lists.xen.org/archives/html/xen-announce/2012-09/msg00006.html .

I don't know if this includes any patch or its just the information. If
anyone clear this up then I am happy that my servers are secured.

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

<div>Hi,<br></div><div><br></div><div>Finally I got success to applied all =
the patches on my server except &quot;Xen Security Advisory 15 (CVE-2012-34=
97)&quot; <a href=3D"http://lists.xen.org/archives/html/xen-announce/2012-0=
9/msg00006.html">http://lists.xen.org/archives/html/xen-announce/2012-09/ms=
g00006.html</a> .</div>
<div><br></div><div>I don&#39;t know if this includes any patch or its just=
 the information. If anyone clear this up then I am happy that my servers a=
re secured.</div><div><br></div>

--0015173fe992faba7504c908dfa8--


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

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

--===============5296329335915531691==--


From xen-devel-bounces@lists.xen.org Thu Sep 06 14:00:09 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 2012 14:00:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9ccl-0005r9-92; Thu, 06 Sep 2012 14:00: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 1T9cck-0005nY-8O
	for xen-devel@lists.xen.org; Thu, 06 Sep 2012 14:00:02 +0000
Received: from [85.158.143.35:13779] by server-1.bemta-4.messagelabs.com id
	04/FD-12504-16CA8405; Thu, 06 Sep 2012 14:00:01 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1346940000!13638763!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTE5NzY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5199 invoked from network); 6 Sep 2012 14:00:01 -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;
	6 Sep 2012 14:00:01 -0000
X-IronPort-AV: E=Sophos;i="4.80,380,1344211200"; d="scan'208";a="14387854"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Sep 2012 14:00: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.279.1; Thu, 6 Sep 2012
	14:59:59 +0100
Message-ID: <1346939998.30018.19.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Tim Deegan <tim@xen.org>
Date: Thu, 6 Sep 2012 14:59:58 +0100
In-Reply-To: <20120906135848.GA59973@ocelot.phlegethon.org>
References: <1346678886.32462.9.camel@zakaz.uk.xensource.com>
	<1346679056-8108-16-git-send-email-ian.campbell@citrix.com>
	<20120906135020.GO56463@ocelot.phlegethon.org>
	<1346939700.30018.15.camel@zakaz.uk.xensource.com>
	<20120906135848.GA59973@ocelot.phlegethon.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 16/16] arm: use /chosen/module1-args for
 domain 0 command line
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-09-06 at 14:58 +0100, Tim Deegan wrote:
> At 14:55 +0100 on 06 Sep (1346943300), Ian Campbell wrote:
> > > >          if ( device_tree_node_matches(fdt, node, "chosen") )
> > > >          {
> > > >              if ( strcmp(prop_name, "bootargs") == 0 )
> > > >                  continue;
> > > > -            if ( strcmp(prop_name, "xen,dom0-bootargs") == 0 )
> > > > +            if ( strcmp(prop_name, "module1-args") == 0 )
> > > > +            {
> > > >                  prop_name = "bootargs";
> > > > +                had_mod1_args = 1;
> > > > +            }
> > > > +            if ( strncmp(prop_name, "module", strlen("module")) == 0 )
> > > > +                 continue;
> > > 
> > > ITYM "else if" here, or the module1-args property gets dropped too,
> > > doesn't it?  
> > 
> > The intention was to filter "module*" from the DTB altogether, since
> > they were intended for Xen not dom0. All that should remain is
> > module1-args which has been renamed to bootargs which is what dom0
> > expects.
> 
> Argh, of course now prop_name's been clobbered it won't be filtered. :)
> Sorry for the noise.

Actually I hadn't got quite what you were suggesting, and it is a bit
subtle now you put it that way. An else if would probably help the code
be self documenting.

> 
> Acked-by: Tim Deegan <tim@xen.org>, though I imagine you'll want
> David's ack rather than mine.
> 
> Tim.



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

From xen-devel-bounces@lists.xen.org Thu Sep 06 14:00:09 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 2012 14:00:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9ccl-0005r9-92; Thu, 06 Sep 2012 14:00: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 1T9cck-0005nY-8O
	for xen-devel@lists.xen.org; Thu, 06 Sep 2012 14:00:02 +0000
Received: from [85.158.143.35:13779] by server-1.bemta-4.messagelabs.com id
	04/FD-12504-16CA8405; Thu, 06 Sep 2012 14:00:01 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1346940000!13638763!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTE5NzY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5199 invoked from network); 6 Sep 2012 14:00:01 -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;
	6 Sep 2012 14:00:01 -0000
X-IronPort-AV: E=Sophos;i="4.80,380,1344211200"; d="scan'208";a="14387854"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Sep 2012 14:00: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.279.1; Thu, 6 Sep 2012
	14:59:59 +0100
Message-ID: <1346939998.30018.19.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Tim Deegan <tim@xen.org>
Date: Thu, 6 Sep 2012 14:59:58 +0100
In-Reply-To: <20120906135848.GA59973@ocelot.phlegethon.org>
References: <1346678886.32462.9.camel@zakaz.uk.xensource.com>
	<1346679056-8108-16-git-send-email-ian.campbell@citrix.com>
	<20120906135020.GO56463@ocelot.phlegethon.org>
	<1346939700.30018.15.camel@zakaz.uk.xensource.com>
	<20120906135848.GA59973@ocelot.phlegethon.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 16/16] arm: use /chosen/module1-args for
 domain 0 command line
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-09-06 at 14:58 +0100, Tim Deegan wrote:
> At 14:55 +0100 on 06 Sep (1346943300), Ian Campbell wrote:
> > > >          if ( device_tree_node_matches(fdt, node, "chosen") )
> > > >          {
> > > >              if ( strcmp(prop_name, "bootargs") == 0 )
> > > >                  continue;
> > > > -            if ( strcmp(prop_name, "xen,dom0-bootargs") == 0 )
> > > > +            if ( strcmp(prop_name, "module1-args") == 0 )
> > > > +            {
> > > >                  prop_name = "bootargs";
> > > > +                had_mod1_args = 1;
> > > > +            }
> > > > +            if ( strncmp(prop_name, "module", strlen("module")) == 0 )
> > > > +                 continue;
> > > 
> > > ITYM "else if" here, or the module1-args property gets dropped too,
> > > doesn't it?  
> > 
> > The intention was to filter "module*" from the DTB altogether, since
> > they were intended for Xen not dom0. All that should remain is
> > module1-args which has been renamed to bootargs which is what dom0
> > expects.
> 
> Argh, of course now prop_name's been clobbered it won't be filtered. :)
> Sorry for the noise.

Actually I hadn't got quite what you were suggesting, and it is a bit
subtle now you put it that way. An else if would probably help the code
be self documenting.

> 
> Acked-by: Tim Deegan <tim@xen.org>, though I imagine you'll want
> David's ack rather than mine.
> 
> Tim.



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

From xen-devel-bounces@lists.xen.org Thu Sep 06 14:03:33 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 2012 14: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 1T9cg2-0006Ak-Te; Thu, 06 Sep 2012 14:03: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 1T9cg1-0006Ae-Rw
	for xen-devel@lists.xen.org; Thu, 06 Sep 2012 14:03:26 +0000
Received: from [85.158.143.99:54301] by server-3.bemta-4.messagelabs.com id
	6E/6C-08232-D2DA8405; Thu, 06 Sep 2012 14:03:25 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-16.tower-216.messagelabs.com!1346940204!17712326!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31753 invoked from network); 6 Sep 2012 14:03:24 -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; 6 Sep 2012 14:03:24 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1T9cg0-000Fep-4H; Thu, 06 Sep 2012 14:03:24 +0000
Date: Thu, 6 Sep 2012 15:03:24 +0100
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120906140324.GB59973@ocelot.phlegethon.org>
References: <1346678886.32462.9.camel@zakaz.uk.xensource.com>
	<1346679056-8108-15-git-send-email-ian.campbell@citrix.com>
	<20120906135310.GP56463@ocelot.phlegethon.org>
	<1346939856.30018.17.camel@zakaz.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1346939856.30018.17.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 15/16] arm: discard boot modules after
	building domain 0.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At 14:57 +0100 on 06 Sep (1346943456), Ian Campbell wrote:
> On Thu, 2012-09-06 at 14:53 +0100, Tim Deegan wrote:
> > At 13:30 +0000 on 03 Sep (1346679055), Ian Campbell wrote:
> > > +void __init discard_initial_modules(void)
> > > +{
> > > +    struct dt_module_info *mi = &early_info.modules;
> > > +    int i;
> > > +
> > > +    for ( i = 0; i < mi->nr_mods; i++ )
> > > +    {
> > > +        paddr_t s = mi->module[i].start;
> > > +        paddr_t e = s + PAGE_ALIGN(mi->module[i].size);
> > > +
> > > +        init_domheap_pages(s, e);
> > 
> > Is there a risk of weirdness from adding non-superpage-aligned memory to
> > the domheap here, given that map_domain_page always uses 2MB mappings?
> 
> I hadn't thought about this.
> 
> These regions will mesh precisely with what setup_mm has added and
> therefore the result is that the entire 2MB is on the heap, I think.
> 
> These non-aligned looking regions are actually within larger regions of
> RAM so I don't think there is any danger of actually mapping some
> non-RAM as part of such a 2MB mapping?

Righto.  We also might care about accidental r/w mappings of r/o things,
but since Xen itself is 32MB-aligned that's OK.  I think for now this is
all fine, so:

Acked-by: Tim Deegan <tim@xen.org>

though it will need adjustment if Xen becomes module 0, of course. :)

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 Sep 06 14:03:33 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 2012 14: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 1T9cg2-0006Ak-Te; Thu, 06 Sep 2012 14:03: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 1T9cg1-0006Ae-Rw
	for xen-devel@lists.xen.org; Thu, 06 Sep 2012 14:03:26 +0000
Received: from [85.158.143.99:54301] by server-3.bemta-4.messagelabs.com id
	6E/6C-08232-D2DA8405; Thu, 06 Sep 2012 14:03:25 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-16.tower-216.messagelabs.com!1346940204!17712326!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31753 invoked from network); 6 Sep 2012 14:03:24 -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; 6 Sep 2012 14:03:24 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1T9cg0-000Fep-4H; Thu, 06 Sep 2012 14:03:24 +0000
Date: Thu, 6 Sep 2012 15:03:24 +0100
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120906140324.GB59973@ocelot.phlegethon.org>
References: <1346678886.32462.9.camel@zakaz.uk.xensource.com>
	<1346679056-8108-15-git-send-email-ian.campbell@citrix.com>
	<20120906135310.GP56463@ocelot.phlegethon.org>
	<1346939856.30018.17.camel@zakaz.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1346939856.30018.17.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 15/16] arm: discard boot modules after
	building domain 0.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At 14:57 +0100 on 06 Sep (1346943456), Ian Campbell wrote:
> On Thu, 2012-09-06 at 14:53 +0100, Tim Deegan wrote:
> > At 13:30 +0000 on 03 Sep (1346679055), Ian Campbell wrote:
> > > +void __init discard_initial_modules(void)
> > > +{
> > > +    struct dt_module_info *mi = &early_info.modules;
> > > +    int i;
> > > +
> > > +    for ( i = 0; i < mi->nr_mods; i++ )
> > > +    {
> > > +        paddr_t s = mi->module[i].start;
> > > +        paddr_t e = s + PAGE_ALIGN(mi->module[i].size);
> > > +
> > > +        init_domheap_pages(s, e);
> > 
> > Is there a risk of weirdness from adding non-superpage-aligned memory to
> > the domheap here, given that map_domain_page always uses 2MB mappings?
> 
> I hadn't thought about this.
> 
> These regions will mesh precisely with what setup_mm has added and
> therefore the result is that the entire 2MB is on the heap, I think.
> 
> These non-aligned looking regions are actually within larger regions of
> RAM so I don't think there is any danger of actually mapping some
> non-RAM as part of such a 2MB mapping?

Righto.  We also might care about accidental r/w mappings of r/o things,
but since Xen itself is 32MB-aligned that's OK.  I think for now this is
all fine, so:

Acked-by: Tim Deegan <tim@xen.org>

though it will need adjustment if Xen becomes module 0, of course. :)

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 Sep 06 14:09:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 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 1T9cmB-0006bA-OM; Thu, 06 Sep 2012 14:09: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 1T9cmA-0006b1-6r
	for xen-devel@lists.xen.org; Thu, 06 Sep 2012 14:09:46 +0000
Received: from [85.158.138.51:52264] by server-4.bemta-3.messagelabs.com id
	24/00-24831-9AEA8405; Thu, 06 Sep 2012 14:09:45 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1346940584!10386699!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTE5NzY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21306 invoked from network); 6 Sep 2012 14:09:45 -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;
	6 Sep 2012 14:09:45 -0000
X-IronPort-AV: E=Sophos;i="4.80,380,1344211200"; d="scan'208";a="14388127"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Sep 2012 14:09: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.279.1; Thu, 6 Sep 2012
	15:09:26 +0100
Message-ID: <1346940565.30018.24.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: kk s <kks.kbase@gmail.com>
Date: Thu, 6 Sep 2012 15:09:25 +0100
In-Reply-To: <CAPU-Ed6Xrbf+uM+tqCM+AhYcjw=-8C-xd3iy7C8c+MP5BoxeRg@mail.gmail.com>
References: <CAPU-Ed6Xrbf+uM+tqCM+AhYcjw=-8C-xd3iy7C8c+MP5BoxeRg@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-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] XSA patch help
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 asked you already to stop cross posting (this means posting to
multiple lists), and yet you continue to do so. Please stop.

On Thu, 2012-09-06 at 14:57 +0100, kk s wrote:
> Finally I got success to applied all the patches on my server except
> "Xen Security Advisory 15 (CVE-2012-3497)"
> http://lists.xen.org/archives/html/xen-announce/2012-09/msg00006.html .

> I don't know if this includes any patch or its just the information.

Please reread the advisory, it contains the answer to your question as
well as plenty of background on the reasoning and information on what
you must have done to be vulnerable to these issues in the first place.

If you think the advisory is unclear then please quote the text which
you don't understand.

>  If anyone clear this up then I am happy that my servers are secured.

Ian.


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

From xen-devel-bounces@lists.xen.org Thu Sep 06 14:09:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 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 1T9cmB-0006bA-OM; Thu, 06 Sep 2012 14:09: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 1T9cmA-0006b1-6r
	for xen-devel@lists.xen.org; Thu, 06 Sep 2012 14:09:46 +0000
Received: from [85.158.138.51:52264] by server-4.bemta-3.messagelabs.com id
	24/00-24831-9AEA8405; Thu, 06 Sep 2012 14:09:45 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1346940584!10386699!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTE5NzY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21306 invoked from network); 6 Sep 2012 14:09:45 -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;
	6 Sep 2012 14:09:45 -0000
X-IronPort-AV: E=Sophos;i="4.80,380,1344211200"; d="scan'208";a="14388127"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Sep 2012 14:09: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.279.1; Thu, 6 Sep 2012
	15:09:26 +0100
Message-ID: <1346940565.30018.24.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: kk s <kks.kbase@gmail.com>
Date: Thu, 6 Sep 2012 15:09:25 +0100
In-Reply-To: <CAPU-Ed6Xrbf+uM+tqCM+AhYcjw=-8C-xd3iy7C8c+MP5BoxeRg@mail.gmail.com>
References: <CAPU-Ed6Xrbf+uM+tqCM+AhYcjw=-8C-xd3iy7C8c+MP5BoxeRg@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-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] XSA patch help
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 asked you already to stop cross posting (this means posting to
multiple lists), and yet you continue to do so. Please stop.

On Thu, 2012-09-06 at 14:57 +0100, kk s wrote:
> Finally I got success to applied all the patches on my server except
> "Xen Security Advisory 15 (CVE-2012-3497)"
> http://lists.xen.org/archives/html/xen-announce/2012-09/msg00006.html .

> I don't know if this includes any patch or its just the information.

Please reread the advisory, it contains the answer to your question as
well as plenty of background on the reasoning and information on what
you must have done to be vulnerable to these issues in the first place.

If you think the advisory is unclear then please quote the text which
you don't understand.

>  If anyone clear this up then I am happy that my servers are secured.

Ian.


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

From xen-devel-bounces@lists.xen.org Thu Sep 06 14:11:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 2012 14:11:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9cnP-0006j3-Qw; Thu, 06 Sep 2012 14:11: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 1T9cnO-0006is-Kp
	for xen-devel@lists.xensource.com; Thu, 06 Sep 2012 14:11:02 +0000
Received: from [85.158.143.99:57269] by server-1.bemta-4.messagelabs.com id
	24/76-12504-6FEA8405; Thu, 06 Sep 2012 14:11:02 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1346940661!23595835!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTE5NzY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5271 invoked from network); 6 Sep 2012 14:11:01 -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;
	6 Sep 2012 14:11:01 -0000
X-IronPort-AV: E=Sophos;i="4.80,380,1344211200"; d="scan'208";a="14388166"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Sep 2012 14:11: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.279.1; Thu, 6 Sep 2012 15:11: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 1T9cnL-0006eS-Tz;
	Thu, 06 Sep 2012 14:10:59 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1T9cnL-0003h2-JJ;
	Thu, 06 Sep 2012 15:10:59 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-13656-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 6 Sep 2012 15:10:59 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13656: 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 13656 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13656/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore            fail   like 13648
 test-i386-i386-xl-qemuu-winxpsp3  9 guest-localmigrate         fail like 13648
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail like 13648
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail like 13648

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

version targeted for testing:
 xen                  cbc0c2368a6d
baseline version:
 xen                  9dc729b75595

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@citrix.com>
  Ian Campbell <ian.campbell@citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Keir Fraser <keir@xen.org>
  Pasi K?rkk?inen <pasik@iki.fi>
  Paul Durrant <paul.durrant@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                                 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                                     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=cbc0c2368a6d
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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 cbc0c2368a6d
+ branch=xen-unstable
+ revision=cbc0c2368a6d
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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 cbc0c2368a6d 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 9 changes to 7 files

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

From xen-devel-bounces@lists.xen.org Thu Sep 06 14:11:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 2012 14:11:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9cnP-0006j3-Qw; Thu, 06 Sep 2012 14:11: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 1T9cnO-0006is-Kp
	for xen-devel@lists.xensource.com; Thu, 06 Sep 2012 14:11:02 +0000
Received: from [85.158.143.99:57269] by server-1.bemta-4.messagelabs.com id
	24/76-12504-6FEA8405; Thu, 06 Sep 2012 14:11:02 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1346940661!23595835!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTE5NzY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5271 invoked from network); 6 Sep 2012 14:11:01 -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;
	6 Sep 2012 14:11:01 -0000
X-IronPort-AV: E=Sophos;i="4.80,380,1344211200"; d="scan'208";a="14388166"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Sep 2012 14:11: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.279.1; Thu, 6 Sep 2012 15:11: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 1T9cnL-0006eS-Tz;
	Thu, 06 Sep 2012 14:10:59 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1T9cnL-0003h2-JJ;
	Thu, 06 Sep 2012 15:10:59 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-13656-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 6 Sep 2012 15:10:59 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13656: 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 13656 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13656/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore            fail   like 13648
 test-i386-i386-xl-qemuu-winxpsp3  9 guest-localmigrate         fail like 13648
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail like 13648
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail like 13648

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

version targeted for testing:
 xen                  cbc0c2368a6d
baseline version:
 xen                  9dc729b75595

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@citrix.com>
  Ian Campbell <ian.campbell@citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Keir Fraser <keir@xen.org>
  Pasi K?rkk?inen <pasik@iki.fi>
  Paul Durrant <paul.durrant@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                                 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                                     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=cbc0c2368a6d
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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 cbc0c2368a6d
+ branch=xen-unstable
+ revision=cbc0c2368a6d
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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 cbc0c2368a6d 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 9 changes to 7 files

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

From xen-devel-bounces@lists.xen.org Thu Sep 06 14:19:39 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 2012 14: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 1T9cvX-0007PQ-Ky; Thu, 06 Sep 2012 14:19:27 +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 1T9cvW-0007PK-2T
	for xen-devel@lists.xen.org; Thu, 06 Sep 2012 14:19:26 +0000
Received: from [85.158.139.83:59313] by server-3.bemta-5.messagelabs.com id
	16/D5-21836-DE0B8405; Thu, 06 Sep 2012 14:19:25 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1346941163!25027128!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNzcyMDY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13056 invoked from network); 6 Sep 2012 14:19:24 -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;
	6 Sep 2012 14:19:24 -0000
X-IronPort-AV: E=Sophos;i="4.80,380,1344211200"; d="scan'208";a="207287478"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Sep 2012 14:19:22 +0000
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.279.1; Thu, 6 Sep 2012
	10:19:22 -0400
Message-ID: <5048B0E9.4010706@citrix.com>
Date: Thu, 6 Sep 2012 15:19: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 Iceowl/1.0b1 Icedove/3.0.11
MIME-Version: 1.0
To: Ian Campbell <ian.campbell@citrix.com>
References: <1346678886.32462.9.camel@zakaz.uk.xensource.com>
	<1346679056-8108-16-git-send-email-ian.campbell@citrix.com>
In-Reply-To: <1346679056-8108-16-git-send-email-ian.campbell@citrix.com>
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 16/16] arm: use /chosen/module1-args for
 domain 0 command line
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 03/09/12 14:30, Ian Campbell wrote:
> Ideally this would use module1-args iff the kernel came from
> module1-{start,end} and the existing xen,dom0-bootargs if the kernel
> came from flash, but this approach is simpler and has the sme effect
> in practice.

Is module1-args defined in a spec somewhere?

If the DT has xen,dom0-bootargs followed by module1-args you will end up
with two bootargs nodes.  Suggest preferring the first one found and
discard the other.

> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> ---
>  xen/arch/arm/domain_build.c |   23 ++++++++++++++++++++---
>  1 files changed, 20 insertions(+), 3 deletions(-)
> 
> diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
> index e96ed10..2b65637 100644
> --- a/xen/arch/arm/domain_build.c
> +++ b/xen/arch/arm/domain_build.c
> @@ -88,6 +88,8 @@ static int write_properties(struct domain *d, struct kernel_info *kinfo,
>  {
>      int prop;
>  
> +    int had_mod1_args = 0;
> +
>      for ( prop = fdt_first_property_offset(fdt, node);
>            prop >= 0;
>            prop = fdt_next_property_offset(fdt, prop) )
> @@ -104,15 +106,30 @@ static int write_properties(struct domain *d, struct kernel_info *kinfo,
>          prop_len  = fdt32_to_cpu(p->len);
>  
>          /*
> -         * In chosen node: replace bootargs with value from
> -         * xen,dom0-bootargs.
> +         * In chosen node:
> +         *
> +         * * replace bootargs with value from module1-args, falling
> +         *   back to xen,dom0-bootargs if not present.
> +         * * remove all other module*.
>           */
>          if ( device_tree_node_matches(fdt, node, "chosen") )
>          {
>              if ( strcmp(prop_name, "bootargs") == 0 )
>                  continue;
> -            if ( strcmp(prop_name, "xen,dom0-bootargs") == 0 )
> +            if ( strncmp(prop_name, "module", strlen("module")) == 0 )
> +                 continue;

Clearer to write this as:

    if ( strncmp(prop_name, "module", strlen("module")) == 0 )
        if ( strcmp(prop_name, "module1-args") == 0 )
        {
            prop_name = "bootargs";
            had_mod1_args = 1;
        }
        else
            continue;
    }

> +            if ( strcmp(prop_name, "xen,dom0-bootargs") == 0 )
> +            {
> +                if ( had_mod1_args )
> +                    continue;
> +                else
> +                    prop_name = "bootargs";
> +            }
>          }
>          /*
>           * In a memory node: adjust reg property.


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

From xen-devel-bounces@lists.xen.org Thu Sep 06 14:19:39 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 2012 14: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 1T9cvX-0007PQ-Ky; Thu, 06 Sep 2012 14:19:27 +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 1T9cvW-0007PK-2T
	for xen-devel@lists.xen.org; Thu, 06 Sep 2012 14:19:26 +0000
Received: from [85.158.139.83:59313] by server-3.bemta-5.messagelabs.com id
	16/D5-21836-DE0B8405; Thu, 06 Sep 2012 14:19:25 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1346941163!25027128!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNzcyMDY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13056 invoked from network); 6 Sep 2012 14:19:24 -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;
	6 Sep 2012 14:19:24 -0000
X-IronPort-AV: E=Sophos;i="4.80,380,1344211200"; d="scan'208";a="207287478"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Sep 2012 14:19:22 +0000
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.279.1; Thu, 6 Sep 2012
	10:19:22 -0400
Message-ID: <5048B0E9.4010706@citrix.com>
Date: Thu, 6 Sep 2012 15:19: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 Iceowl/1.0b1 Icedove/3.0.11
MIME-Version: 1.0
To: Ian Campbell <ian.campbell@citrix.com>
References: <1346678886.32462.9.camel@zakaz.uk.xensource.com>
	<1346679056-8108-16-git-send-email-ian.campbell@citrix.com>
In-Reply-To: <1346679056-8108-16-git-send-email-ian.campbell@citrix.com>
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 16/16] arm: use /chosen/module1-args for
 domain 0 command line
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 03/09/12 14:30, Ian Campbell wrote:
> Ideally this would use module1-args iff the kernel came from
> module1-{start,end} and the existing xen,dom0-bootargs if the kernel
> came from flash, but this approach is simpler and has the sme effect
> in practice.

Is module1-args defined in a spec somewhere?

If the DT has xen,dom0-bootargs followed by module1-args you will end up
with two bootargs nodes.  Suggest preferring the first one found and
discard the other.

> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> ---
>  xen/arch/arm/domain_build.c |   23 ++++++++++++++++++++---
>  1 files changed, 20 insertions(+), 3 deletions(-)
> 
> diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
> index e96ed10..2b65637 100644
> --- a/xen/arch/arm/domain_build.c
> +++ b/xen/arch/arm/domain_build.c
> @@ -88,6 +88,8 @@ static int write_properties(struct domain *d, struct kernel_info *kinfo,
>  {
>      int prop;
>  
> +    int had_mod1_args = 0;
> +
>      for ( prop = fdt_first_property_offset(fdt, node);
>            prop >= 0;
>            prop = fdt_next_property_offset(fdt, prop) )
> @@ -104,15 +106,30 @@ static int write_properties(struct domain *d, struct kernel_info *kinfo,
>          prop_len  = fdt32_to_cpu(p->len);
>  
>          /*
> -         * In chosen node: replace bootargs with value from
> -         * xen,dom0-bootargs.
> +         * In chosen node:
> +         *
> +         * * replace bootargs with value from module1-args, falling
> +         *   back to xen,dom0-bootargs if not present.
> +         * * remove all other module*.
>           */
>          if ( device_tree_node_matches(fdt, node, "chosen") )
>          {
>              if ( strcmp(prop_name, "bootargs") == 0 )
>                  continue;
> -            if ( strcmp(prop_name, "xen,dom0-bootargs") == 0 )
> +            if ( strncmp(prop_name, "module", strlen("module")) == 0 )
> +                 continue;

Clearer to write this as:

    if ( strncmp(prop_name, "module", strlen("module")) == 0 )
        if ( strcmp(prop_name, "module1-args") == 0 )
        {
            prop_name = "bootargs";
            had_mod1_args = 1;
        }
        else
            continue;
    }

> +            if ( strcmp(prop_name, "xen,dom0-bootargs") == 0 )
> +            {
> +                if ( had_mod1_args )
> +                    continue;
> +                else
> +                    prop_name = "bootargs";
> +            }
>          }
>          /*
>           * In a memory node: adjust reg property.


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

From xen-devel-bounces@lists.xen.org Thu Sep 06 14:29:51 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 2012 14:29: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 1T9d5M-0007pG-Ck; Thu, 06 Sep 2012 14:29:36 +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 1T9d5L-0007p4-DW
	for xen-devel@lists.xen.org; Thu, 06 Sep 2012 14:29:35 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1346941769!2888152!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTE5NzY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14815 invoked from network); 6 Sep 2012 14:29:29 -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;
	6 Sep 2012 14:29:29 -0000
X-IronPort-AV: E=Sophos;i="4.80,380,1344211200"; d="scan'208";a="14388710"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Sep 2012 14: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.279.1; Thu, 6 Sep 2012
	15:28:47 +0100
Message-ID: <1346941726.30018.26.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: David Vrabel <david.vrabel@citrix.com>
Date: Thu, 6 Sep 2012 15:28:46 +0100
In-Reply-To: <5048B0E9.4010706@citrix.com>
References: <1346678886.32462.9.camel@zakaz.uk.xensource.com>
	<1346679056-8108-16-git-send-email-ian.campbell@citrix.com>
	<5048B0E9.4010706@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 16/16] arm: use /chosen/module1-args for
 domain 0 command line
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-09-06 at 15:19 +0100, David Vrabel wrote:
> On 03/09/12 14:30, Ian Campbell wrote:
> > Ideally this would use module1-args iff the kernel came from
> > module1-{start,end} and the existing xen,dom0-bootargs if the kernel
> > came from flash, but this approach is simpler and has the sme effect
> > in practice.
> 
> Is module1-args defined in a spec somewhere?

Nope, I made it up as a PoC. I described it a little bit in the 0/16
mail.

> If the DT has xen,dom0-bootargs followed by module1-args you will end up
> with two bootargs nodes.  Suggest preferring the first one found and
> discard the other.

Yes.

> 
> > Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> > ---
> >  xen/arch/arm/domain_build.c |   23 ++++++++++++++++++++---
> >  1 files changed, 20 insertions(+), 3 deletions(-)
> > 
> > diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
> > index e96ed10..2b65637 100644
> > --- a/xen/arch/arm/domain_build.c
> > +++ b/xen/arch/arm/domain_build.c
> > @@ -88,6 +88,8 @@ static int write_properties(struct domain *d, struct kernel_info *kinfo,
> >  {
> >      int prop;
> >  
> > +    int had_mod1_args = 0;
> > +
> >      for ( prop = fdt_first_property_offset(fdt, node);
> >            prop >= 0;
> >            prop = fdt_next_property_offset(fdt, prop) )
> > @@ -104,15 +106,30 @@ static int write_properties(struct domain *d, struct kernel_info *kinfo,
> >          prop_len  = fdt32_to_cpu(p->len);
> >  
> >          /*
> > -         * In chosen node: replace bootargs with value from
> > -         * xen,dom0-bootargs.
> > +         * In chosen node:
> > +         *
> > +         * * replace bootargs with value from module1-args, falling
> > +         *   back to xen,dom0-bootargs if not present.
> > +         * * remove all other module*.
> >           */
> >          if ( device_tree_node_matches(fdt, node, "chosen") )
> >          {
> >              if ( strcmp(prop_name, "bootargs") == 0 )
> >                  continue;
> > -            if ( strcmp(prop_name, "xen,dom0-bootargs") == 0 )
> > +            if ( strncmp(prop_name, "module", strlen("module")) == 0 )
> > +                 continue;
> 
> Clearer to write this as:
> 
>     if ( strncmp(prop_name, "module", strlen("module")) == 0 )
>         if ( strcmp(prop_name, "module1-args") == 0 )
>         {
>             prop_name = "bootargs";
>             had_mod1_args = 1;
>         }
>         else
>             continue;
>     }
> 
> > +            if ( strcmp(prop_name, "xen,dom0-bootargs") == 0 )
> > +            {
> > +                if ( had_mod1_args )
> > +                    continue;
> > +                else
> > +                    prop_name = "bootargs";
> > +            }
> >          }
> >          /*
> >           * In a memory node: adjust reg property.
> 



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

From xen-devel-bounces@lists.xen.org Thu Sep 06 14:29:51 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 2012 14:29: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 1T9d5M-0007pG-Ck; Thu, 06 Sep 2012 14:29:36 +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 1T9d5L-0007p4-DW
	for xen-devel@lists.xen.org; Thu, 06 Sep 2012 14:29:35 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1346941769!2888152!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTE5NzY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14815 invoked from network); 6 Sep 2012 14:29:29 -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;
	6 Sep 2012 14:29:29 -0000
X-IronPort-AV: E=Sophos;i="4.80,380,1344211200"; d="scan'208";a="14388710"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Sep 2012 14: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.279.1; Thu, 6 Sep 2012
	15:28:47 +0100
Message-ID: <1346941726.30018.26.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: David Vrabel <david.vrabel@citrix.com>
Date: Thu, 6 Sep 2012 15:28:46 +0100
In-Reply-To: <5048B0E9.4010706@citrix.com>
References: <1346678886.32462.9.camel@zakaz.uk.xensource.com>
	<1346679056-8108-16-git-send-email-ian.campbell@citrix.com>
	<5048B0E9.4010706@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 16/16] arm: use /chosen/module1-args for
 domain 0 command line
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-09-06 at 15:19 +0100, David Vrabel wrote:
> On 03/09/12 14:30, Ian Campbell wrote:
> > Ideally this would use module1-args iff the kernel came from
> > module1-{start,end} and the existing xen,dom0-bootargs if the kernel
> > came from flash, but this approach is simpler and has the sme effect
> > in practice.
> 
> Is module1-args defined in a spec somewhere?

Nope, I made it up as a PoC. I described it a little bit in the 0/16
mail.

> If the DT has xen,dom0-bootargs followed by module1-args you will end up
> with two bootargs nodes.  Suggest preferring the first one found and
> discard the other.

Yes.

> 
> > Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> > ---
> >  xen/arch/arm/domain_build.c |   23 ++++++++++++++++++++---
> >  1 files changed, 20 insertions(+), 3 deletions(-)
> > 
> > diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
> > index e96ed10..2b65637 100644
> > --- a/xen/arch/arm/domain_build.c
> > +++ b/xen/arch/arm/domain_build.c
> > @@ -88,6 +88,8 @@ static int write_properties(struct domain *d, struct kernel_info *kinfo,
> >  {
> >      int prop;
> >  
> > +    int had_mod1_args = 0;
> > +
> >      for ( prop = fdt_first_property_offset(fdt, node);
> >            prop >= 0;
> >            prop = fdt_next_property_offset(fdt, prop) )
> > @@ -104,15 +106,30 @@ static int write_properties(struct domain *d, struct kernel_info *kinfo,
> >          prop_len  = fdt32_to_cpu(p->len);
> >  
> >          /*
> > -         * In chosen node: replace bootargs with value from
> > -         * xen,dom0-bootargs.
> > +         * In chosen node:
> > +         *
> > +         * * replace bootargs with value from module1-args, falling
> > +         *   back to xen,dom0-bootargs if not present.
> > +         * * remove all other module*.
> >           */
> >          if ( device_tree_node_matches(fdt, node, "chosen") )
> >          {
> >              if ( strcmp(prop_name, "bootargs") == 0 )
> >                  continue;
> > -            if ( strcmp(prop_name, "xen,dom0-bootargs") == 0 )
> > +            if ( strncmp(prop_name, "module", strlen("module")) == 0 )
> > +                 continue;
> 
> Clearer to write this as:
> 
>     if ( strncmp(prop_name, "module", strlen("module")) == 0 )
>         if ( strcmp(prop_name, "module1-args") == 0 )
>         {
>             prop_name = "bootargs";
>             had_mod1_args = 1;
>         }
>         else
>             continue;
>     }
> 
> > +            if ( strcmp(prop_name, "xen,dom0-bootargs") == 0 )
> > +            {
> > +                if ( had_mod1_args )
> > +                    continue;
> > +                else
> > +                    prop_name = "bootargs";
> > +            }
> >          }
> >          /*
> >           * In a memory node: adjust reg property.
> 



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

From xen-devel-bounces@lists.xen.org Thu Sep 06 14:36:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 2012 14:36: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 1T9dBO-0008FF-7N; Thu, 06 Sep 2012 14:35:50 +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 1T9dBM-0008Eg-Cd
	for xen-devel@lists.xen.org; Thu, 06 Sep 2012 14:35:48 +0000
Received: from [85.158.143.99:18758] by server-3.bemta-4.messagelabs.com id
	A6/A1-08232-3C4B8405; Thu, 06 Sep 2012 14:35:47 +0000
X-Env-Sender: ben.guthro@gmail.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1346942145!23687928!1
X-Originating-IP: [209.85.210.173]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
  RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20460 invoked from network); 6 Sep 2012 14:35:46 -0000
Received: from mail-iy0-f173.google.com (HELO mail-iy0-f173.google.com)
	(209.85.210.173)
	by server-12.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Sep 2012 14:35:46 -0000
Received: by iakx26 with SMTP id x26so2587206iak.32
	for <xen-devel@lists.xen.org>; Thu, 06 Sep 2012 07:35:44 -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=fUvWeV9JhKVSo9pWjEBK8GGIFh5QKXRVdIsPiYRss/o=;
	b=WvLn1daEqFqw5u9BzHUaPguM0Lry8WiR3a9YqCXHZ/bQo5bTK1bwcqqKBM+bYZVBjK
	NB2+AZfZlTsr3g3a0vnwxbaPWuehFj0V/yKIW5QhedjyzVMLx8XTpaz3s41Az/G/SC8H
	w/tdGOUdHzW97Gmj/4ci73o8bUHR9H30BWJEoTjLmGt00jYlS3C8U8WczQY8NX/yKtQk
	WH9Ovx0Gff11J/S+EZqrrbi5W6xILAwQFTNwtepqHzJmOnUKu3PT6L9T0BhllFI/GKbo
	c76iJ8BQbdFouhpmK4eo1jg0qCLjPPT7Pl8jXRkv7f8dbgaFL0bScYbNujOExA8Ff+WD
	8UlA==
MIME-Version: 1.0
Received: by 10.42.89.1 with SMTP id e1mr2674294icm.8.1346942144526; Thu, 06
	Sep 2012 07:35:44 -0700 (PDT)
Received: by 10.64.28.203 with HTTP; Thu, 6 Sep 2012 07:35:44 -0700 (PDT)
In-Reply-To: <CAOvdn6XUFL665RNvL6JKRovgPYYO32ujTkSE4LTrQy8xTU_9fQ@mail.gmail.com>
References: <1346665360.25864.2.camel@zakaz.uk.xensource.com>
	<5048B4DF0200007800099554@nat28.tlf.novell.com>
	<CAOvdn6VUoFN8n-weX4Ni6-O2HivLepWfXV+JMuj7Hjc7oXN9cg@mail.gmail.com>
	<CAOvdn6XUFL665RNvL6JKRovgPYYO32ujTkSE4LTrQy8xTU_9fQ@mail.gmail.com>
Date: Thu, 6 Sep 2012 10:35:44 -0400
X-Google-Sender-Auth: qfAvPcdbD7j6lNPN69Q_db8OJqw
Message-ID: <CAOvdn6WU=haz48S=ok3M8mAovuag4wQtaj2dhGmJvVfrqK3rJg@mail.gmail.com>
From: Ben Guthro <ben@guthro.net>
To: Jan Beulich <JBeulich@suse.com>
Cc: Ian Campbell <Ian.Campbell@citrix.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.2.0 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 may have claimed success on this second one too soon. Subsequent
tests, and expansion to other systems shows S3 still to be a problem
on these laptops.

Being a laptop, without a serial port, of course makes this more
difficult to debug.
I'll continue to look into it.

On Thu, Sep 6, 2012 at 9:40 AM, Ben Guthro <ben@guthro.net> wrote:
> Good news on this front, as well - it seems to fix the "blinky power
> button" failure, as well.
>
>
> On Thu, Sep 6, 2012 at 8:55 AM, Ben Guthro <ben@guthro.net> wrote:
>> FWIW, I ran this through 100 suspend / resume cycles successfully, on
>> the machine where I could only do one before.
>>
>> I'm still waiting for a laptop to free up that exhibited the other S3
>> failure where it went to sleep, but just pulsed the power LED when
>> asked to wake up.
>> I'm cautiously hopeful this fixes that problem, as well.
>>
>> Ben
>>
>> On Thu, Sep 6, 2012 at 8:36 AM, Jan Beulich <JBeulich@suse.com> wrote:
>>>>>> On 03.09.12 at 11:42, Ian Campbell <Ian.Campbell@citrix.com> wrote:
>>>> hypervisor, nice to have:
>>>>
>>>>     * S3 regression(s?) reported by Ben Guthro (Ben & Jan Beulich)
>>>
>>> So it looks like we got this nailed down (actually requiring two
>>> fixes). Would it be intended to still get these in before the
>>> release, or leave them for 4.3/4.2.1?
>>>
>>> Jan
>>>
>>> NB:  I also found an unrelated issue earlier today where a
>>> hypercall would return success when it actually failed, but I
>>> won't even bother sending that out if the fixes needed here
>>> aren't to be considered, as that's clearly minor compared to
>>> the regression here.
>>>
>>>
>>> _______________________________________________
>>> Xen-devel mailing list
>>> Xen-devel@lists.xen.org
>>> http://lists.xen.org/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 Sep 06 14:36:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 2012 14:36: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 1T9dBO-0008FF-7N; Thu, 06 Sep 2012 14:35:50 +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 1T9dBM-0008Eg-Cd
	for xen-devel@lists.xen.org; Thu, 06 Sep 2012 14:35:48 +0000
Received: from [85.158.143.99:18758] by server-3.bemta-4.messagelabs.com id
	A6/A1-08232-3C4B8405; Thu, 06 Sep 2012 14:35:47 +0000
X-Env-Sender: ben.guthro@gmail.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1346942145!23687928!1
X-Originating-IP: [209.85.210.173]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
  RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20460 invoked from network); 6 Sep 2012 14:35:46 -0000
Received: from mail-iy0-f173.google.com (HELO mail-iy0-f173.google.com)
	(209.85.210.173)
	by server-12.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Sep 2012 14:35:46 -0000
Received: by iakx26 with SMTP id x26so2587206iak.32
	for <xen-devel@lists.xen.org>; Thu, 06 Sep 2012 07:35:44 -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=fUvWeV9JhKVSo9pWjEBK8GGIFh5QKXRVdIsPiYRss/o=;
	b=WvLn1daEqFqw5u9BzHUaPguM0Lry8WiR3a9YqCXHZ/bQo5bTK1bwcqqKBM+bYZVBjK
	NB2+AZfZlTsr3g3a0vnwxbaPWuehFj0V/yKIW5QhedjyzVMLx8XTpaz3s41Az/G/SC8H
	w/tdGOUdHzW97Gmj/4ci73o8bUHR9H30BWJEoTjLmGt00jYlS3C8U8WczQY8NX/yKtQk
	WH9Ovx0Gff11J/S+EZqrrbi5W6xILAwQFTNwtepqHzJmOnUKu3PT6L9T0BhllFI/GKbo
	c76iJ8BQbdFouhpmK4eo1jg0qCLjPPT7Pl8jXRkv7f8dbgaFL0bScYbNujOExA8Ff+WD
	8UlA==
MIME-Version: 1.0
Received: by 10.42.89.1 with SMTP id e1mr2674294icm.8.1346942144526; Thu, 06
	Sep 2012 07:35:44 -0700 (PDT)
Received: by 10.64.28.203 with HTTP; Thu, 6 Sep 2012 07:35:44 -0700 (PDT)
In-Reply-To: <CAOvdn6XUFL665RNvL6JKRovgPYYO32ujTkSE4LTrQy8xTU_9fQ@mail.gmail.com>
References: <1346665360.25864.2.camel@zakaz.uk.xensource.com>
	<5048B4DF0200007800099554@nat28.tlf.novell.com>
	<CAOvdn6VUoFN8n-weX4Ni6-O2HivLepWfXV+JMuj7Hjc7oXN9cg@mail.gmail.com>
	<CAOvdn6XUFL665RNvL6JKRovgPYYO32ujTkSE4LTrQy8xTU_9fQ@mail.gmail.com>
Date: Thu, 6 Sep 2012 10:35:44 -0400
X-Google-Sender-Auth: qfAvPcdbD7j6lNPN69Q_db8OJqw
Message-ID: <CAOvdn6WU=haz48S=ok3M8mAovuag4wQtaj2dhGmJvVfrqK3rJg@mail.gmail.com>
From: Ben Guthro <ben@guthro.net>
To: Jan Beulich <JBeulich@suse.com>
Cc: Ian Campbell <Ian.Campbell@citrix.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.2.0 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 may have claimed success on this second one too soon. Subsequent
tests, and expansion to other systems shows S3 still to be a problem
on these laptops.

Being a laptop, without a serial port, of course makes this more
difficult to debug.
I'll continue to look into it.

On Thu, Sep 6, 2012 at 9:40 AM, Ben Guthro <ben@guthro.net> wrote:
> Good news on this front, as well - it seems to fix the "blinky power
> button" failure, as well.
>
>
> On Thu, Sep 6, 2012 at 8:55 AM, Ben Guthro <ben@guthro.net> wrote:
>> FWIW, I ran this through 100 suspend / resume cycles successfully, on
>> the machine where I could only do one before.
>>
>> I'm still waiting for a laptop to free up that exhibited the other S3
>> failure where it went to sleep, but just pulsed the power LED when
>> asked to wake up.
>> I'm cautiously hopeful this fixes that problem, as well.
>>
>> Ben
>>
>> On Thu, Sep 6, 2012 at 8:36 AM, Jan Beulich <JBeulich@suse.com> wrote:
>>>>>> On 03.09.12 at 11:42, Ian Campbell <Ian.Campbell@citrix.com> wrote:
>>>> hypervisor, nice to have:
>>>>
>>>>     * S3 regression(s?) reported by Ben Guthro (Ben & Jan Beulich)
>>>
>>> So it looks like we got this nailed down (actually requiring two
>>> fixes). Would it be intended to still get these in before the
>>> release, or leave them for 4.3/4.2.1?
>>>
>>> Jan
>>>
>>> NB:  I also found an unrelated issue earlier today where a
>>> hypercall would return success when it actually failed, but I
>>> won't even bother sending that out if the fixes needed here
>>> aren't to be considered, as that's clearly minor compared to
>>> the regression here.
>>>
>>>
>>> _______________________________________________
>>> Xen-devel mailing list
>>> Xen-devel@lists.xen.org
>>> http://lists.xen.org/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 Sep 06 14:39:50 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 2012 14:39: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 1T9dF0-0008Rd-Sf; Thu, 06 Sep 2012 14:39:34 +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 1T9dEz-0008RP-Qi
	for xen-devel@lists.xen.org; Thu, 06 Sep 2012 14:39:34 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-5.tower-27.messagelabs.com!1346942367!6479360!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA1MDQ1MDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4023 invoked from network); 6 Sep 2012 14:39:27 -0000
Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25)
	by server-5.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 6 Sep 2012 14:39:27 -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 D06B61D66;
	Thu,  6 Sep 2012 17:39:26 +0300 (EEST)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id 941162005D; Thu,  6 Sep 2012 17:39:26 +0300 (EEST)
Date: Thu, 6 Sep 2012 17:39:26 +0300
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120906143926.GW8912@reaktio.net>
References: <20120905030239.GJ8912@reaktio.net>
	<1346846602-1109-1-git-send-email-roger.pau@citrix.com>
	<1346868289.10570.6.camel@dagon.hellion.org.uk>
	<20120905205543.GQ8912@reaktio.net>
	<1346916185.10570.15.camel@dagon.hellion.org.uk>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1346916185.10570.15.camel@dagon.hellion.org.uk>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Roger Pau Monne <roger.pau@citrix.com>
Subject: Re: [Xen-devel] [PATCH] libfsimage: add ext4 support for CentOS 5.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="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, Sep 06, 2012 at 08:23:05AM +0100, Ian Campbell wrote:
> On Wed, 2012-09-05 at 21:55 +0100, Pasi K=E4rkk=E4inen wrote:
> > On Wed, Sep 05, 2012 at 07:04:49PM +0100, Ian Campbell wrote:
> > > On Wed, 2012-09-05 at 13:03 +0100, Roger Pau Monne wrote:
> > > > CentOS 5.x forked e2fs ext4 support into a different package called
> > > > e4fs, and so headers and library names changed from ext2fs to ext4f=
s.
> > > > Check if ext4fs/ext2fs.h and -lext4fs work, and use that instead of
> > > > ext2fs to build libfsimage. This patch assumes that if the ext4fs
> > > > library is present it should always be used instead of ext2fs.
> > > > =

> > > > This patch includes a rework of the ext2fs check, a new ext4fs check
> > > > and a minor modification in libfsimage to use the correct library.
> > > > =

> > > > Signed-off-by: Roger Pau Monne <roger.pau@citrix.com>
> > > =

> > > Thanks.
> > > =

> > > Any patch which is intended for 4.2 at this stage needs to come with
> > > some rationale as to why it is acceptable at this late stage.
> > > =

> > =

> > rhel5/centos5 has a lot of Xen users, so it'd be nice if those people
> > could build Xen 4.2 from sources and still have pygrub ext4 support.
> =

> I'm sorry but two days (now one day) before the final RC we need more
> justification than "it would be nice".
> =


I understand that. =


> Who are these people? How many of them are there? Why are they doing
> this? If you are building from source what reason is there to be using
> RHEL5?
> =

> We certainly don't seem to be getting bugs reports (either on -devel@ or
> -users@) about this problem.
> =


Ok, so it'd be mostly *CentOS5* users, who don't have the support contracts=
 anyway.
I'm not able to give you any numbers. I hit this issue myself,
so I thought it'd be nice to get it fixed in upstream Xen aswell. =



> > (the stock redhat el5 Xen 3.1.2 rpms have similar tweaks and =

> > they do provide pygrub ext4 support out-of-the-box on el5).
> > =

> > Also XenServer/XCP has hacks to get pygrub ext4 support enabled in simi=
lar way,
> > so it'd make sense to fix/workaround this properly in Xen upstream.
> =

> This seems right and proper to me and isn't an argument for us taking
> and carry this hack in our tree.
> =

> IMHO the presence of libe4fs in RHEL5 is a distro specific packaging
> hack and it is appropriate that the fallout be dealt with via RHEL5
> specific packaging hacks.
> =


The patch that Roger submitted is dealing with this in a nice way though.. =

Or was there something wrong with the patch? =



> > > Therefore unless someone can argue convincingly for it this is 4.3
> > > material.
> > > =

> > =

> > I'm not expecting that was convincing enough :) so if not 4.2.0 then 4.=
3 and 4.2.1 ? =

> =

> Perhaps. I'm not entirely convinced of the need at all though. If RHEL5
> was the current release then maybe, but RHEL6 is nearly two years old at
> this point.
> =


RHEL5 has "Production Phase" support until 2017. It's still getting =

improvements and new features in 5.x point releases, and still keeping =

the ABI stable and compatible with earlier 5.x versions; =

that's why the e4fs stuff exists in the first place - to not break the ABI.

Next year it'll transform into "security maintenance and minor fixes"-mode.


-- Pasi


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

From xen-devel-bounces@lists.xen.org Thu Sep 06 14:39:50 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 2012 14:39: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 1T9dF0-0008Rd-Sf; Thu, 06 Sep 2012 14:39:34 +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 1T9dEz-0008RP-Qi
	for xen-devel@lists.xen.org; Thu, 06 Sep 2012 14:39:34 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-5.tower-27.messagelabs.com!1346942367!6479360!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA1MDQ1MDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4023 invoked from network); 6 Sep 2012 14:39:27 -0000
Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25)
	by server-5.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 6 Sep 2012 14:39:27 -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 D06B61D66;
	Thu,  6 Sep 2012 17:39:26 +0300 (EEST)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id 941162005D; Thu,  6 Sep 2012 17:39:26 +0300 (EEST)
Date: Thu, 6 Sep 2012 17:39:26 +0300
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120906143926.GW8912@reaktio.net>
References: <20120905030239.GJ8912@reaktio.net>
	<1346846602-1109-1-git-send-email-roger.pau@citrix.com>
	<1346868289.10570.6.camel@dagon.hellion.org.uk>
	<20120905205543.GQ8912@reaktio.net>
	<1346916185.10570.15.camel@dagon.hellion.org.uk>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1346916185.10570.15.camel@dagon.hellion.org.uk>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Roger Pau Monne <roger.pau@citrix.com>
Subject: Re: [Xen-devel] [PATCH] libfsimage: add ext4 support for CentOS 5.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="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, Sep 06, 2012 at 08:23:05AM +0100, Ian Campbell wrote:
> On Wed, 2012-09-05 at 21:55 +0100, Pasi K=E4rkk=E4inen wrote:
> > On Wed, Sep 05, 2012 at 07:04:49PM +0100, Ian Campbell wrote:
> > > On Wed, 2012-09-05 at 13:03 +0100, Roger Pau Monne wrote:
> > > > CentOS 5.x forked e2fs ext4 support into a different package called
> > > > e4fs, and so headers and library names changed from ext2fs to ext4f=
s.
> > > > Check if ext4fs/ext2fs.h and -lext4fs work, and use that instead of
> > > > ext2fs to build libfsimage. This patch assumes that if the ext4fs
> > > > library is present it should always be used instead of ext2fs.
> > > > =

> > > > This patch includes a rework of the ext2fs check, a new ext4fs check
> > > > and a minor modification in libfsimage to use the correct library.
> > > > =

> > > > Signed-off-by: Roger Pau Monne <roger.pau@citrix.com>
> > > =

> > > Thanks.
> > > =

> > > Any patch which is intended for 4.2 at this stage needs to come with
> > > some rationale as to why it is acceptable at this late stage.
> > > =

> > =

> > rhel5/centos5 has a lot of Xen users, so it'd be nice if those people
> > could build Xen 4.2 from sources and still have pygrub ext4 support.
> =

> I'm sorry but two days (now one day) before the final RC we need more
> justification than "it would be nice".
> =


I understand that. =


> Who are these people? How many of them are there? Why are they doing
> this? If you are building from source what reason is there to be using
> RHEL5?
> =

> We certainly don't seem to be getting bugs reports (either on -devel@ or
> -users@) about this problem.
> =


Ok, so it'd be mostly *CentOS5* users, who don't have the support contracts=
 anyway.
I'm not able to give you any numbers. I hit this issue myself,
so I thought it'd be nice to get it fixed in upstream Xen aswell. =



> > (the stock redhat el5 Xen 3.1.2 rpms have similar tweaks and =

> > they do provide pygrub ext4 support out-of-the-box on el5).
> > =

> > Also XenServer/XCP has hacks to get pygrub ext4 support enabled in simi=
lar way,
> > so it'd make sense to fix/workaround this properly in Xen upstream.
> =

> This seems right and proper to me and isn't an argument for us taking
> and carry this hack in our tree.
> =

> IMHO the presence of libe4fs in RHEL5 is a distro specific packaging
> hack and it is appropriate that the fallout be dealt with via RHEL5
> specific packaging hacks.
> =


The patch that Roger submitted is dealing with this in a nice way though.. =

Or was there something wrong with the patch? =



> > > Therefore unless someone can argue convincingly for it this is 4.3
> > > material.
> > > =

> > =

> > I'm not expecting that was convincing enough :) so if not 4.2.0 then 4.=
3 and 4.2.1 ? =

> =

> Perhaps. I'm not entirely convinced of the need at all though. If RHEL5
> was the current release then maybe, but RHEL6 is nearly two years old at
> this point.
> =


RHEL5 has "Production Phase" support until 2017. It's still getting =

improvements and new features in 5.x point releases, and still keeping =

the ABI stable and compatible with earlier 5.x versions; =

that's why the e4fs stuff exists in the first place - to not break the ABI.

Next year it'll transform into "security maintenance and minor fixes"-mode.


-- Pasi


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

From xen-devel-bounces@lists.xen.org Thu Sep 06 14:45:48 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 2012 14: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 1T9dKi-0000C9-NB; Thu, 06 Sep 2012 14:45:28 +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 1T9dKh-0000C4-BM
	for xen-devel@lists.xen.org; Thu, 06 Sep 2012 14:45:27 +0000
Received: from [85.158.138.51:13393] by server-12.bemta-3.messagelabs.com id
	04/17-10384-607B8405; Thu, 06 Sep 2012 14:45:26 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-13.tower-174.messagelabs.com!1346942725!10396359!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA1MDQ1MDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4330 invoked from network); 6 Sep 2012 14:45:25 -0000
Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25)
	by server-13.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 6 Sep 2012 14:45:25 -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 9313426E1;
	Thu,  6 Sep 2012 17:45:24 +0300 (EEST)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id 0E5FF2005D; Thu,  6 Sep 2012 17:45:24 +0300 (EEST)
Date: Thu, 6 Sep 2012 17:45:23 +0300
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: Ben Guthro <ben@guthro.net>
Message-ID: <20120906144523.GX8912@reaktio.net>
References: <1346665360.25864.2.camel@zakaz.uk.xensource.com>
	<5048B4DF0200007800099554@nat28.tlf.novell.com>
	<CAOvdn6VUoFN8n-weX4Ni6-O2HivLepWfXV+JMuj7Hjc7oXN9cg@mail.gmail.com>
	<CAOvdn6XUFL665RNvL6JKRovgPYYO32ujTkSE4LTrQy8xTU_9fQ@mail.gmail.com>
	<CAOvdn6WU=haz48S=ok3M8mAovuag4wQtaj2dhGmJvVfrqK3rJg@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAOvdn6WU=haz48S=ok3M8mAovuag4wQtaj2dhGmJvVfrqK3rJg@mail.gmail.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.2.0 Release Plan / TODO
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Sep 06, 2012 at 10:35:44AM -0400, Ben Guthro wrote:
> I may have claimed success on this second one too soon. Subsequent
> tests, and expansion to other systems shows S3 still to be a problem
> on these laptops.
> 
> Being a laptop, without a serial port, of course makes this more
> difficult to debug.
> I'll continue to look into it.
> 

You probably know this already but here goes anyway.. 
you could use an expresscard serial card, or if the laptop has Intel vPro (AMT),
then it has a Serial Over LAN (SOL) port, which can be used for Xen debugging/logging.

-- Pasi

> On Thu, Sep 6, 2012 at 9:40 AM, Ben Guthro <ben@guthro.net> wrote:
> > Good news on this front, as well - it seems to fix the "blinky power
> > button" failure, as well.
> >
> >
> > On Thu, Sep 6, 2012 at 8:55 AM, Ben Guthro <ben@guthro.net> wrote:
> >> FWIW, I ran this through 100 suspend / resume cycles successfully, on
> >> the machine where I could only do one before.
> >>
> >> I'm still waiting for a laptop to free up that exhibited the other S3
> >> failure where it went to sleep, but just pulsed the power LED when
> >> asked to wake up.
> >> I'm cautiously hopeful this fixes that problem, as well.
> >>
> >> Ben
> >>
> >> On Thu, Sep 6, 2012 at 8:36 AM, Jan Beulich <JBeulich@suse.com> wrote:
> >>>>>> On 03.09.12 at 11:42, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> >>>> hypervisor, nice to have:
> >>>>
> >>>>     * S3 regression(s?) reported by Ben Guthro (Ben & Jan Beulich)
> >>>
> >>> So it looks like we got this nailed down (actually requiring two
> >>> fixes). Would it be intended to still get these in before the
> >>> release, or leave them for 4.3/4.2.1?
> >>>
> >>> Jan
> >>>
> >>> NB:  I also found an unrelated issue earlier today where a
> >>> hypercall would return success when it actually failed, but I
> >>> won't even bother sending that out if the fixes needed here
> >>> aren't to be considered, as that's clearly minor compared to
> >>> the regression here.
> >>>
> >>>
> >>> _______________________________________________
> >>> Xen-devel mailing list
> >>> Xen-devel@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 Sep 06 14:45:48 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 2012 14: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 1T9dKi-0000C9-NB; Thu, 06 Sep 2012 14:45:28 +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 1T9dKh-0000C4-BM
	for xen-devel@lists.xen.org; Thu, 06 Sep 2012 14:45:27 +0000
Received: from [85.158.138.51:13393] by server-12.bemta-3.messagelabs.com id
	04/17-10384-607B8405; Thu, 06 Sep 2012 14:45:26 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-13.tower-174.messagelabs.com!1346942725!10396359!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA1MDQ1MDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4330 invoked from network); 6 Sep 2012 14:45:25 -0000
Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25)
	by server-13.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 6 Sep 2012 14:45:25 -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 9313426E1;
	Thu,  6 Sep 2012 17:45:24 +0300 (EEST)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id 0E5FF2005D; Thu,  6 Sep 2012 17:45:24 +0300 (EEST)
Date: Thu, 6 Sep 2012 17:45:23 +0300
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: Ben Guthro <ben@guthro.net>
Message-ID: <20120906144523.GX8912@reaktio.net>
References: <1346665360.25864.2.camel@zakaz.uk.xensource.com>
	<5048B4DF0200007800099554@nat28.tlf.novell.com>
	<CAOvdn6VUoFN8n-weX4Ni6-O2HivLepWfXV+JMuj7Hjc7oXN9cg@mail.gmail.com>
	<CAOvdn6XUFL665RNvL6JKRovgPYYO32ujTkSE4LTrQy8xTU_9fQ@mail.gmail.com>
	<CAOvdn6WU=haz48S=ok3M8mAovuag4wQtaj2dhGmJvVfrqK3rJg@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAOvdn6WU=haz48S=ok3M8mAovuag4wQtaj2dhGmJvVfrqK3rJg@mail.gmail.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.2.0 Release Plan / TODO
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Sep 06, 2012 at 10:35:44AM -0400, Ben Guthro wrote:
> I may have claimed success on this second one too soon. Subsequent
> tests, and expansion to other systems shows S3 still to be a problem
> on these laptops.
> 
> Being a laptop, without a serial port, of course makes this more
> difficult to debug.
> I'll continue to look into it.
> 

You probably know this already but here goes anyway.. 
you could use an expresscard serial card, or if the laptop has Intel vPro (AMT),
then it has a Serial Over LAN (SOL) port, which can be used for Xen debugging/logging.

-- Pasi

> On Thu, Sep 6, 2012 at 9:40 AM, Ben Guthro <ben@guthro.net> wrote:
> > Good news on this front, as well - it seems to fix the "blinky power
> > button" failure, as well.
> >
> >
> > On Thu, Sep 6, 2012 at 8:55 AM, Ben Guthro <ben@guthro.net> wrote:
> >> FWIW, I ran this through 100 suspend / resume cycles successfully, on
> >> the machine where I could only do one before.
> >>
> >> I'm still waiting for a laptop to free up that exhibited the other S3
> >> failure where it went to sleep, but just pulsed the power LED when
> >> asked to wake up.
> >> I'm cautiously hopeful this fixes that problem, as well.
> >>
> >> Ben
> >>
> >> On Thu, Sep 6, 2012 at 8:36 AM, Jan Beulich <JBeulich@suse.com> wrote:
> >>>>>> On 03.09.12 at 11:42, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> >>>> hypervisor, nice to have:
> >>>>
> >>>>     * S3 regression(s?) reported by Ben Guthro (Ben & Jan Beulich)
> >>>
> >>> So it looks like we got this nailed down (actually requiring two
> >>> fixes). Would it be intended to still get these in before the
> >>> release, or leave them for 4.3/4.2.1?
> >>>
> >>> Jan
> >>>
> >>> NB:  I also found an unrelated issue earlier today where a
> >>> hypercall would return success when it actually failed, but I
> >>> won't even bother sending that out if the fixes needed here
> >>> aren't to be considered, as that's clearly minor compared to
> >>> the regression here.
> >>>
> >>>
> >>> _______________________________________________
> >>> Xen-devel mailing list
> >>> Xen-devel@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 Sep 06 14:46:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 2012 14: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 1T9dLm-0000FX-5G; Thu, 06 Sep 2012 14:46:34 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1T9dLk-0000FP-Jw
	for xen-devel@lists.xen.org; Thu, 06 Sep 2012 14:46:32 +0000
Received: from [85.158.143.99:15733] by server-3.bemta-4.messagelabs.com id
	22/85-08232-747B8405; Thu, 06 Sep 2012 14:46:31 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1346942791!28593184!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM5ODQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15596 invoked from network); 6 Sep 2012 14:46:31 -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;
	6 Sep 2012 14:46:31 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 06 Sep 2012 15:46:30 +0100
Message-Id: <5048D39D0200007800099684@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 06 Sep 2012 15:47:25 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Campbell" <Ian.Campbell@citrix.com>
References: <22d5e100131d1576d455.1346932605@cosworth.uk.xensource.com>
	<5048B1C4020000780009952E@nat28.tlf.novell.com>
	<1346939323.30018.12.camel@zakaz.uk.xensource.com>
In-Reply-To: <1346939323.30018.12.camel@zakaz.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "Tim \(Xen.org\)" <tim@xen.org>, 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] [PATCH] xen: clamp bitmaps to correct number of bits
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.09.12 at 15:48, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> On Thu, 2012-09-06 at 13:23 +0100, Jan Beulich wrote:
>> >>> On 06.09.12 at 13:56, Ian Campbell <ian.campbell@citrix.com> wrote:
>> > +/* Ensure that the last byte is zero from nbits onwards. */
>> > +static void clamp_last_byte(uint8_t *bp, int nbits)
>> > +{
>> > +	int lastbyte = nbits/8;
>> > +	int remainder = nbits % 8;
>> > +	int mask = ((1U<<remainder)-1)&0xff;
>> 
>> While I realize the callers use plain int, I'd be very much in favor
>> of not continuing this bad practice (the more that you use 1U
>> already) - simply make the parameter and all locals (assuming
>> you really think they're useful; I would have omitted all but
>> "remainder", given they're being used just once) unsigned.
> 
> I'll fold them in, it was convenient to have variables while I was
> printk'ing what I was doing but not any more.

I won't ask you for another round because of this, but you
still left the parameter and remaining local variable as plain
int, nor did you insert whitespace into the expressions. If I
were the one to commit this, I would do the adjustment while
committing...

Anyway, as long as there's no easily visible tools side bug
addressed by this, I would think we should rather leave this
for after branching - Keir?

Jan


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

From xen-devel-bounces@lists.xen.org Thu Sep 06 14:46:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 2012 14: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 1T9dLm-0000FX-5G; Thu, 06 Sep 2012 14:46:34 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1T9dLk-0000FP-Jw
	for xen-devel@lists.xen.org; Thu, 06 Sep 2012 14:46:32 +0000
Received: from [85.158.143.99:15733] by server-3.bemta-4.messagelabs.com id
	22/85-08232-747B8405; Thu, 06 Sep 2012 14:46:31 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1346942791!28593184!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM5ODQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15596 invoked from network); 6 Sep 2012 14:46:31 -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;
	6 Sep 2012 14:46:31 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 06 Sep 2012 15:46:30 +0100
Message-Id: <5048D39D0200007800099684@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 06 Sep 2012 15:47:25 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Campbell" <Ian.Campbell@citrix.com>
References: <22d5e100131d1576d455.1346932605@cosworth.uk.xensource.com>
	<5048B1C4020000780009952E@nat28.tlf.novell.com>
	<1346939323.30018.12.camel@zakaz.uk.xensource.com>
In-Reply-To: <1346939323.30018.12.camel@zakaz.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "Tim \(Xen.org\)" <tim@xen.org>, 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] [PATCH] xen: clamp bitmaps to correct number of bits
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.09.12 at 15:48, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> On Thu, 2012-09-06 at 13:23 +0100, Jan Beulich wrote:
>> >>> On 06.09.12 at 13:56, Ian Campbell <ian.campbell@citrix.com> wrote:
>> > +/* Ensure that the last byte is zero from nbits onwards. */
>> > +static void clamp_last_byte(uint8_t *bp, int nbits)
>> > +{
>> > +	int lastbyte = nbits/8;
>> > +	int remainder = nbits % 8;
>> > +	int mask = ((1U<<remainder)-1)&0xff;
>> 
>> While I realize the callers use plain int, I'd be very much in favor
>> of not continuing this bad practice (the more that you use 1U
>> already) - simply make the parameter and all locals (assuming
>> you really think they're useful; I would have omitted all but
>> "remainder", given they're being used just once) unsigned.
> 
> I'll fold them in, it was convenient to have variables while I was
> printk'ing what I was doing but not any more.

I won't ask you for another round because of this, but you
still left the parameter and remaining local variable as plain
int, nor did you insert whitespace into the expressions. If I
were the one to commit this, I would do the adjustment while
committing...

Anyway, as long as there's no easily visible tools side bug
addressed by this, I would think we should rather leave this
for after branching - Keir?

Jan


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

From xen-devel-bounces@lists.xen.org Thu Sep 06 14:46:48 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 2012 14: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 1T9dLo-0000Ft-HM; Thu, 06 Sep 2012 14:46:36 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1T9dLn-0000Fk-BR
	for xen-devel@lists.xen.org; Thu, 06 Sep 2012 14:46:35 +0000
Received: from [85.158.139.83:13916] by server-4.bemta-5.messagelabs.com id
	74/7C-23042-A47B8405; Thu, 06 Sep 2012 14:46:34 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1346942792!21759970!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNzcyMDY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14699 invoked from network); 6 Sep 2012 14:46:33 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-11.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Sep 2012 14:46:33 -0000
X-IronPort-AV: E=Sophos;i="4.80,380,1344211200"; d="scan'208";a="207292170"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Sep 2012 14:46:32 +0000
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.279.1; Thu, 6 Sep 2012
	10:46:31 -0400
Message-ID: <5048B746.4070306@citrix.com>
Date: Thu, 6 Sep 2012 15:46:30 +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 Iceowl/1.0b1 Icedove/3.0.11
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <1346678886.32462.9.camel@zakaz.uk.xensource.com>
In-Reply-To: <1346678886.32462.9.camel@zakaz.uk.xensource.com>
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 0/16] arm: support for initial modules (e.g.
 dom0) and DTB supplied in RAM
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 03/09/12 14:28, Ian Campbell wrote:
> The following series implements support for initial images and DTB in
> RAM, as opposed to in flash (dom0 kernel) or compiled into the
> hypervisor (DTB). It arranges to not clobber these with either the h/v
> text on relocation or with the heaps and frees them as appropriate.
> 
> Most of this is independent of the specific bootloader protocol which is
> used to tell Xen where these modules actually are, but I have included a
> simple PoC bootloader protocol based around device tree which is similar
> to the protocol used by Linux to find its initrd
> (where /chosen/linux,initrd-{start,end} indicate the physical address).
> 
> In the PoC the modules are listed in the chosen node starting
> with /chosen/nr-modules which contains the count and then /chosen/module
> %d-{start,end} which gives the physical address of the module
> and /chosen/module%d-args which give its command line.

Until there is an agreement on this protocol I would prepend a "xen,"
prefix to the node names (xen,nr-modules etc.).

bootargs instead of args would be more consistent perhaps. So,
module1-args becomes xen,module1-bootargs.

The proposed protocol is functional and useful using nodes for each
module seems to be more device-tree-ish. I think in the longer term,
perhaps something like the following would be better?

chosen {
    module@1 {
        compatible = "multiboot-module";
        regs = <0x12345678 0x01000>;
        bootargs = "frob";
    };
    module@2 {
        compatible = "multiboot-module";
        regs = <0x12345678 0x01000>;
    }
}

David

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

From xen-devel-bounces@lists.xen.org Thu Sep 06 14:46:48 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 2012 14: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 1T9dLo-0000Ft-HM; Thu, 06 Sep 2012 14:46:36 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1T9dLn-0000Fk-BR
	for xen-devel@lists.xen.org; Thu, 06 Sep 2012 14:46:35 +0000
Received: from [85.158.139.83:13916] by server-4.bemta-5.messagelabs.com id
	74/7C-23042-A47B8405; Thu, 06 Sep 2012 14:46:34 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1346942792!21759970!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNzcyMDY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14699 invoked from network); 6 Sep 2012 14:46:33 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-11.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Sep 2012 14:46:33 -0000
X-IronPort-AV: E=Sophos;i="4.80,380,1344211200"; d="scan'208";a="207292170"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Sep 2012 14:46:32 +0000
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.279.1; Thu, 6 Sep 2012
	10:46:31 -0400
Message-ID: <5048B746.4070306@citrix.com>
Date: Thu, 6 Sep 2012 15:46:30 +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 Iceowl/1.0b1 Icedove/3.0.11
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <1346678886.32462.9.camel@zakaz.uk.xensource.com>
In-Reply-To: <1346678886.32462.9.camel@zakaz.uk.xensource.com>
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 0/16] arm: support for initial modules (e.g.
 dom0) and DTB supplied in RAM
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 03/09/12 14:28, Ian Campbell wrote:
> The following series implements support for initial images and DTB in
> RAM, as opposed to in flash (dom0 kernel) or compiled into the
> hypervisor (DTB). It arranges to not clobber these with either the h/v
> text on relocation or with the heaps and frees them as appropriate.
> 
> Most of this is independent of the specific bootloader protocol which is
> used to tell Xen where these modules actually are, but I have included a
> simple PoC bootloader protocol based around device tree which is similar
> to the protocol used by Linux to find its initrd
> (where /chosen/linux,initrd-{start,end} indicate the physical address).
> 
> In the PoC the modules are listed in the chosen node starting
> with /chosen/nr-modules which contains the count and then /chosen/module
> %d-{start,end} which gives the physical address of the module
> and /chosen/module%d-args which give its command line.

Until there is an agreement on this protocol I would prepend a "xen,"
prefix to the node names (xen,nr-modules etc.).

bootargs instead of args would be more consistent perhaps. So,
module1-args becomes xen,module1-bootargs.

The proposed protocol is functional and useful using nodes for each
module seems to be more device-tree-ish. I think in the longer term,
perhaps something like the following would be better?

chosen {
    module@1 {
        compatible = "multiboot-module";
        regs = <0x12345678 0x01000>;
        bootargs = "frob";
    };
    module@2 {
        compatible = "multiboot-module";
        regs = <0x12345678 0x01000>;
    }
}

David

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

From xen-devel-bounces@lists.xen.org Thu Sep 06 14:47:39 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 2012 14: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 1T9dMf-0000PE-An; Thu, 06 Sep 2012 14:47:29 +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 1T9dMe-0000Oy-E6
	for xen-devel@lists.xen.org; Thu, 06 Sep 2012 14:47:28 +0000
Received: from [85.158.138.51:34446] by server-12.bemta-3.messagelabs.com id
	BF/6D-10384-F77B8405; Thu, 06 Sep 2012 14:47:27 +0000
X-Env-Sender: ben.guthro@gmail.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1346942845!25034684!1
X-Originating-IP: [209.85.223.173]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
  RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17462 invoked from network); 6 Sep 2012 14:47:26 -0000
Received: from mail-ie0-f173.google.com (HELO mail-ie0-f173.google.com)
	(209.85.223.173)
	by server-10.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Sep 2012 14:47:26 -0000
Received: by iebc10 with SMTP id c10so3865645ieb.32
	for <xen-devel@lists.xen.org>; Thu, 06 Sep 2012 07:47: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
	:content-transfer-encoding;
	bh=GKl9R2IA8MWPVXO/wRWI2GfZBSzdKNW/pCZLdtbcLcA=;
	b=k4BcF3Ip7wsJRrZuuMMWu47vgUbswvqkHQrXwGu39MVw/2rdieh7sQfqkx+u9/tcJG
	u1+uWJW3xpAZnJ+NBj7ew9P9XMElLkYF44QamjaJXM6B3mTzgRzWZ7li6B8PoOGYFwWy
	7c6/3a9WMKOeVeAVBJvB6FyOl9xm96crjCIFbJ5oCNiR9LdMOW5H/V/nmAhK7zEUvI3R
	/hZfCCDPA5aP0Ltw+kuEAIwr6+ka1AUmRMWAu1SgpyjQa6JNGiDfA/l1ewPNclTUf+6O
	RUmzZpp2xnMoVxGqN/vi0kQVEPNwGNZUs2j77yaLnWyjSnR68jLzycybE8h3oblFJg9T
	tuQQ==
MIME-Version: 1.0
Received: by 10.50.217.227 with SMTP id pb3mr23132292igc.28.1346942845164;
	Thu, 06 Sep 2012 07:47:25 -0700 (PDT)
Received: by 10.64.28.203 with HTTP; Thu, 6 Sep 2012 07:47:24 -0700 (PDT)
In-Reply-To: <20120906144523.GX8912@reaktio.net>
References: <1346665360.25864.2.camel@zakaz.uk.xensource.com>
	<5048B4DF0200007800099554@nat28.tlf.novell.com>
	<CAOvdn6VUoFN8n-weX4Ni6-O2HivLepWfXV+JMuj7Hjc7oXN9cg@mail.gmail.com>
	<CAOvdn6XUFL665RNvL6JKRovgPYYO32ujTkSE4LTrQy8xTU_9fQ@mail.gmail.com>
	<CAOvdn6WU=haz48S=ok3M8mAovuag4wQtaj2dhGmJvVfrqK3rJg@mail.gmail.com>
	<20120906144523.GX8912@reaktio.net>
Date: Thu, 6 Sep 2012 10:47:24 -0400
X-Google-Sender-Auth: Wmxrl1yBkXK-ToAIcvqCs3sKCF4
Message-ID: <CAOvdn6VktcvX6mRUxL7SGDnv4oJn8ufRktLYhf8nb4Oromo84g@mail.gmail.com>
From: Ben Guthro <ben@guthro.net>
To: =?ISO-8859-1?Q?Pasi_K=E4rkk=E4inen?= <pasik@iki.fi>
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.2.0 Release Plan / TODO
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Sep 6, 2012 at 10:45 AM, Pasi K=E4rkk=E4inen <pasik@iki.fi> wrote:
> On Thu, Sep 06, 2012 at 10:35:44AM -0400, Ben Guthro wrote:
>> I may have claimed success on this second one too soon. Subsequent
>> tests, and expansion to other systems shows S3 still to be a problem
>> on these laptops.
>>
>> Being a laptop, without a serial port, of course makes this more
>> difficult to debug.
>> I'll continue to look into it.
>>
>
> You probably know this already but here goes anyway..
> you could use an expresscard serial card, or if the laptop has Intel vPro=
 (AMT),
> then it has a Serial Over LAN (SOL) port, which can be used for Xen debug=
ging/logging.

This particular machine has neither.
I'll look around for an alternate.



Ben

>
> -- Pasi
>
>> On Thu, Sep 6, 2012 at 9:40 AM, Ben Guthro <ben@guthro.net> wrote:
>> > Good news on this front, as well - it seems to fix the "blinky power
>> > button" failure, as well.
>> >
>> >
>> > On Thu, Sep 6, 2012 at 8:55 AM, Ben Guthro <ben@guthro.net> wrote:
>> >> FWIW, I ran this through 100 suspend / resume cycles successfully, on
>> >> the machine where I could only do one before.
>> >>
>> >> I'm still waiting for a laptop to free up that exhibited the other S3
>> >> failure where it went to sleep, but just pulsed the power LED when
>> >> asked to wake up.
>> >> I'm cautiously hopeful this fixes that problem, as well.
>> >>
>> >> Ben
>> >>
>> >> On Thu, Sep 6, 2012 at 8:36 AM, Jan Beulich <JBeulich@suse.com> wrote:
>> >>>>>> On 03.09.12 at 11:42, Ian Campbell <Ian.Campbell@citrix.com> wrot=
e:
>> >>>> hypervisor, nice to have:
>> >>>>
>> >>>>     * S3 regression(s?) reported by Ben Guthro (Ben & Jan Beulich)
>> >>>
>> >>> So it looks like we got this nailed down (actually requiring two
>> >>> fixes). Would it be intended to still get these in before the
>> >>> release, or leave them for 4.3/4.2.1?
>> >>>
>> >>> Jan
>> >>>
>> >>> NB:  I also found an unrelated issue earlier today where a
>> >>> hypercall would return success when it actually failed, but I
>> >>> won't even bother sending that out if the fixes needed here
>> >>> aren't to be considered, as that's clearly minor compared to
>> >>> the regression here.
>> >>>
>> >>>
>> >>> _______________________________________________
>> >>> Xen-devel mailing list
>> >>> Xen-devel@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 Sep 06 14:47:39 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 2012 14: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 1T9dMf-0000PE-An; Thu, 06 Sep 2012 14:47:29 +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 1T9dMe-0000Oy-E6
	for xen-devel@lists.xen.org; Thu, 06 Sep 2012 14:47:28 +0000
Received: from [85.158.138.51:34446] by server-12.bemta-3.messagelabs.com id
	BF/6D-10384-F77B8405; Thu, 06 Sep 2012 14:47:27 +0000
X-Env-Sender: ben.guthro@gmail.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1346942845!25034684!1
X-Originating-IP: [209.85.223.173]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
  RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17462 invoked from network); 6 Sep 2012 14:47:26 -0000
Received: from mail-ie0-f173.google.com (HELO mail-ie0-f173.google.com)
	(209.85.223.173)
	by server-10.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Sep 2012 14:47:26 -0000
Received: by iebc10 with SMTP id c10so3865645ieb.32
	for <xen-devel@lists.xen.org>; Thu, 06 Sep 2012 07:47: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
	:content-transfer-encoding;
	bh=GKl9R2IA8MWPVXO/wRWI2GfZBSzdKNW/pCZLdtbcLcA=;
	b=k4BcF3Ip7wsJRrZuuMMWu47vgUbswvqkHQrXwGu39MVw/2rdieh7sQfqkx+u9/tcJG
	u1+uWJW3xpAZnJ+NBj7ew9P9XMElLkYF44QamjaJXM6B3mTzgRzWZ7li6B8PoOGYFwWy
	7c6/3a9WMKOeVeAVBJvB6FyOl9xm96crjCIFbJ5oCNiR9LdMOW5H/V/nmAhK7zEUvI3R
	/hZfCCDPA5aP0Ltw+kuEAIwr6+ka1AUmRMWAu1SgpyjQa6JNGiDfA/l1ewPNclTUf+6O
	RUmzZpp2xnMoVxGqN/vi0kQVEPNwGNZUs2j77yaLnWyjSnR68jLzycybE8h3oblFJg9T
	tuQQ==
MIME-Version: 1.0
Received: by 10.50.217.227 with SMTP id pb3mr23132292igc.28.1346942845164;
	Thu, 06 Sep 2012 07:47:25 -0700 (PDT)
Received: by 10.64.28.203 with HTTP; Thu, 6 Sep 2012 07:47:24 -0700 (PDT)
In-Reply-To: <20120906144523.GX8912@reaktio.net>
References: <1346665360.25864.2.camel@zakaz.uk.xensource.com>
	<5048B4DF0200007800099554@nat28.tlf.novell.com>
	<CAOvdn6VUoFN8n-weX4Ni6-O2HivLepWfXV+JMuj7Hjc7oXN9cg@mail.gmail.com>
	<CAOvdn6XUFL665RNvL6JKRovgPYYO32ujTkSE4LTrQy8xTU_9fQ@mail.gmail.com>
	<CAOvdn6WU=haz48S=ok3M8mAovuag4wQtaj2dhGmJvVfrqK3rJg@mail.gmail.com>
	<20120906144523.GX8912@reaktio.net>
Date: Thu, 6 Sep 2012 10:47:24 -0400
X-Google-Sender-Auth: Wmxrl1yBkXK-ToAIcvqCs3sKCF4
Message-ID: <CAOvdn6VktcvX6mRUxL7SGDnv4oJn8ufRktLYhf8nb4Oromo84g@mail.gmail.com>
From: Ben Guthro <ben@guthro.net>
To: =?ISO-8859-1?Q?Pasi_K=E4rkk=E4inen?= <pasik@iki.fi>
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.2.0 Release Plan / TODO
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Sep 6, 2012 at 10:45 AM, Pasi K=E4rkk=E4inen <pasik@iki.fi> wrote:
> On Thu, Sep 06, 2012 at 10:35:44AM -0400, Ben Guthro wrote:
>> I may have claimed success on this second one too soon. Subsequent
>> tests, and expansion to other systems shows S3 still to be a problem
>> on these laptops.
>>
>> Being a laptop, without a serial port, of course makes this more
>> difficult to debug.
>> I'll continue to look into it.
>>
>
> You probably know this already but here goes anyway..
> you could use an expresscard serial card, or if the laptop has Intel vPro=
 (AMT),
> then it has a Serial Over LAN (SOL) port, which can be used for Xen debug=
ging/logging.

This particular machine has neither.
I'll look around for an alternate.



Ben

>
> -- Pasi
>
>> On Thu, Sep 6, 2012 at 9:40 AM, Ben Guthro <ben@guthro.net> wrote:
>> > Good news on this front, as well - it seems to fix the "blinky power
>> > button" failure, as well.
>> >
>> >
>> > On Thu, Sep 6, 2012 at 8:55 AM, Ben Guthro <ben@guthro.net> wrote:
>> >> FWIW, I ran this through 100 suspend / resume cycles successfully, on
>> >> the machine where I could only do one before.
>> >>
>> >> I'm still waiting for a laptop to free up that exhibited the other S3
>> >> failure where it went to sleep, but just pulsed the power LED when
>> >> asked to wake up.
>> >> I'm cautiously hopeful this fixes that problem, as well.
>> >>
>> >> Ben
>> >>
>> >> On Thu, Sep 6, 2012 at 8:36 AM, Jan Beulich <JBeulich@suse.com> wrote:
>> >>>>>> On 03.09.12 at 11:42, Ian Campbell <Ian.Campbell@citrix.com> wrot=
e:
>> >>>> hypervisor, nice to have:
>> >>>>
>> >>>>     * S3 regression(s?) reported by Ben Guthro (Ben & Jan Beulich)
>> >>>
>> >>> So it looks like we got this nailed down (actually requiring two
>> >>> fixes). Would it be intended to still get these in before the
>> >>> release, or leave them for 4.3/4.2.1?
>> >>>
>> >>> Jan
>> >>>
>> >>> NB:  I also found an unrelated issue earlier today where a
>> >>> hypercall would return success when it actually failed, but I
>> >>> won't even bother sending that out if the fixes needed here
>> >>> aren't to be considered, as that's clearly minor compared to
>> >>> the regression here.
>> >>>
>> >>>
>> >>> _______________________________________________
>> >>> Xen-devel mailing list
>> >>> Xen-devel@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 Sep 06 14:53:00 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 2012 14:53:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9dRp-0000pf-8f; Thu, 06 Sep 2012 14:52:49 +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 1T9dRo-0000pZ-BH
	for xen-devel@lists.xen.org; Thu, 06 Sep 2012 14:52:48 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-10.tower-27.messagelabs.com!1346943159!4722767!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA1MDQ1MDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31962 invoked from network); 6 Sep 2012 14:52:39 -0000
Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25)
	by server-10.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 6 Sep 2012 14:52: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 BA9DF1F67;
	Thu,  6 Sep 2012 17:52:37 +0300 (EEST)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id D30302005D; Thu,  6 Sep 2012 17:52:37 +0300 (EEST)
Date: Thu, 6 Sep 2012 17:52:37 +0300
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: Ben Guthro <ben@guthro.net>
Message-ID: <20120906145237.GY8912@reaktio.net>
References: <1346665360.25864.2.camel@zakaz.uk.xensource.com>
	<5048B4DF0200007800099554@nat28.tlf.novell.com>
	<CAOvdn6VUoFN8n-weX4Ni6-O2HivLepWfXV+JMuj7Hjc7oXN9cg@mail.gmail.com>
	<CAOvdn6XUFL665RNvL6JKRovgPYYO32ujTkSE4LTrQy8xTU_9fQ@mail.gmail.com>
	<CAOvdn6WU=haz48S=ok3M8mAovuag4wQtaj2dhGmJvVfrqK3rJg@mail.gmail.com>
	<20120906144523.GX8912@reaktio.net>
	<CAOvdn6VktcvX6mRUxL7SGDnv4oJn8ufRktLYhf8nb4Oromo84g@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAOvdn6VktcvX6mRUxL7SGDnv4oJn8ufRktLYhf8nb4Oromo84g@mail.gmail.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.2.0 Release Plan / TODO
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Sep 06, 2012 at 10:47:24AM -0400, Ben Guthro wrote:
> On Thu, Sep 6, 2012 at 10:45 AM, Pasi K=E4rkk=E4inen <pasik@iki.fi> wrote:
> > On Thu, Sep 06, 2012 at 10:35:44AM -0400, Ben Guthro wrote:
> >> I may have claimed success on this second one too soon. Subsequent
> >> tests, and expansion to other systems shows S3 still to be a problem
> >> on these laptops.
> >>
> >> Being a laptop, without a serial port, of course makes this more
> >> difficult to debug.
> >> I'll continue to look into it.
> >>
> >
> > You probably know this already but here goes anyway..
> > you could use an expresscard serial card, or if the laptop has Intel vP=
ro (AMT),
> > then it has a Serial Over LAN (SOL) port, which can be used for Xen deb=
ugging/logging.
> =

> This particular machine has neither.
> I'll look around for an alternate.
> =


Does it have mini PCI express? (the slot where you can put wlan adapter etc=
).

http://www.amazon.com/StarTech-com-RS232-Express-Serial-MPEX2S952/dp/B003OC=
RW1Q

-- Pasi

> =

> =

> Ben
> =

> >
> > -- Pasi
> >
> >> On Thu, Sep 6, 2012 at 9:40 AM, Ben Guthro <ben@guthro.net> wrote:
> >> > Good news on this front, as well - it seems to fix the "blinky power
> >> > button" failure, as well.
> >> >
> >> >
> >> > On Thu, Sep 6, 2012 at 8:55 AM, Ben Guthro <ben@guthro.net> wrote:
> >> >> FWIW, I ran this through 100 suspend / resume cycles successfully, =
on
> >> >> the machine where I could only do one before.
> >> >>
> >> >> I'm still waiting for a laptop to free up that exhibited the other =
S3
> >> >> failure where it went to sleep, but just pulsed the power LED when
> >> >> asked to wake up.
> >> >> I'm cautiously hopeful this fixes that problem, as well.
> >> >>
> >> >> Ben
> >> >>
> >> >> On Thu, Sep 6, 2012 at 8:36 AM, Jan Beulich <JBeulich@suse.com> wro=
te:
> >> >>>>>> On 03.09.12 at 11:42, Ian Campbell <Ian.Campbell@citrix.com> wr=
ote:
> >> >>>> hypervisor, nice to have:
> >> >>>>
> >> >>>>     * S3 regression(s?) reported by Ben Guthro (Ben & Jan Beulich)
> >> >>>
> >> >>> So it looks like we got this nailed down (actually requiring two
> >> >>> fixes). Would it be intended to still get these in before the
> >> >>> release, or leave them for 4.3/4.2.1?
> >> >>>
> >> >>> Jan
> >> >>>
> >> >>> NB:  I also found an unrelated issue earlier today where a
> >> >>> hypercall would return success when it actually failed, but I
> >> >>> won't even bother sending that out if the fixes needed here
> >> >>> aren't to be considered, as that's clearly minor compared to
> >> >>> the regression here.
> >> >>>
> >> >>>
> >> >>> _______________________________________________
> >> >>> Xen-devel mailing list
> >> >>> Xen-devel@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 Sep 06 14:53:00 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 2012 14:53:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9dRp-0000pf-8f; Thu, 06 Sep 2012 14:52:49 +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 1T9dRo-0000pZ-BH
	for xen-devel@lists.xen.org; Thu, 06 Sep 2012 14:52:48 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-10.tower-27.messagelabs.com!1346943159!4722767!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA1MDQ1MDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31962 invoked from network); 6 Sep 2012 14:52:39 -0000
Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25)
	by server-10.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 6 Sep 2012 14:52: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 BA9DF1F67;
	Thu,  6 Sep 2012 17:52:37 +0300 (EEST)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id D30302005D; Thu,  6 Sep 2012 17:52:37 +0300 (EEST)
Date: Thu, 6 Sep 2012 17:52:37 +0300
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: Ben Guthro <ben@guthro.net>
Message-ID: <20120906145237.GY8912@reaktio.net>
References: <1346665360.25864.2.camel@zakaz.uk.xensource.com>
	<5048B4DF0200007800099554@nat28.tlf.novell.com>
	<CAOvdn6VUoFN8n-weX4Ni6-O2HivLepWfXV+JMuj7Hjc7oXN9cg@mail.gmail.com>
	<CAOvdn6XUFL665RNvL6JKRovgPYYO32ujTkSE4LTrQy8xTU_9fQ@mail.gmail.com>
	<CAOvdn6WU=haz48S=ok3M8mAovuag4wQtaj2dhGmJvVfrqK3rJg@mail.gmail.com>
	<20120906144523.GX8912@reaktio.net>
	<CAOvdn6VktcvX6mRUxL7SGDnv4oJn8ufRktLYhf8nb4Oromo84g@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAOvdn6VktcvX6mRUxL7SGDnv4oJn8ufRktLYhf8nb4Oromo84g@mail.gmail.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.2.0 Release Plan / TODO
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Sep 06, 2012 at 10:47:24AM -0400, Ben Guthro wrote:
> On Thu, Sep 6, 2012 at 10:45 AM, Pasi K=E4rkk=E4inen <pasik@iki.fi> wrote:
> > On Thu, Sep 06, 2012 at 10:35:44AM -0400, Ben Guthro wrote:
> >> I may have claimed success on this second one too soon. Subsequent
> >> tests, and expansion to other systems shows S3 still to be a problem
> >> on these laptops.
> >>
> >> Being a laptop, without a serial port, of course makes this more
> >> difficult to debug.
> >> I'll continue to look into it.
> >>
> >
> > You probably know this already but here goes anyway..
> > you could use an expresscard serial card, or if the laptop has Intel vP=
ro (AMT),
> > then it has a Serial Over LAN (SOL) port, which can be used for Xen deb=
ugging/logging.
> =

> This particular machine has neither.
> I'll look around for an alternate.
> =


Does it have mini PCI express? (the slot where you can put wlan adapter etc=
).

http://www.amazon.com/StarTech-com-RS232-Express-Serial-MPEX2S952/dp/B003OC=
RW1Q

-- Pasi

> =

> =

> Ben
> =

> >
> > -- Pasi
> >
> >> On Thu, Sep 6, 2012 at 9:40 AM, Ben Guthro <ben@guthro.net> wrote:
> >> > Good news on this front, as well - it seems to fix the "blinky power
> >> > button" failure, as well.
> >> >
> >> >
> >> > On Thu, Sep 6, 2012 at 8:55 AM, Ben Guthro <ben@guthro.net> wrote:
> >> >> FWIW, I ran this through 100 suspend / resume cycles successfully, =
on
> >> >> the machine where I could only do one before.
> >> >>
> >> >> I'm still waiting for a laptop to free up that exhibited the other =
S3
> >> >> failure where it went to sleep, but just pulsed the power LED when
> >> >> asked to wake up.
> >> >> I'm cautiously hopeful this fixes that problem, as well.
> >> >>
> >> >> Ben
> >> >>
> >> >> On Thu, Sep 6, 2012 at 8:36 AM, Jan Beulich <JBeulich@suse.com> wro=
te:
> >> >>>>>> On 03.09.12 at 11:42, Ian Campbell <Ian.Campbell@citrix.com> wr=
ote:
> >> >>>> hypervisor, nice to have:
> >> >>>>
> >> >>>>     * S3 regression(s?) reported by Ben Guthro (Ben & Jan Beulich)
> >> >>>
> >> >>> So it looks like we got this nailed down (actually requiring two
> >> >>> fixes). Would it be intended to still get these in before the
> >> >>> release, or leave them for 4.3/4.2.1?
> >> >>>
> >> >>> Jan
> >> >>>
> >> >>> NB:  I also found an unrelated issue earlier today where a
> >> >>> hypercall would return success when it actually failed, but I
> >> >>> won't even bother sending that out if the fixes needed here
> >> >>> aren't to be considered, as that's clearly minor compared to
> >> >>> the regression here.
> >> >>>
> >> >>>
> >> >>> _______________________________________________
> >> >>> Xen-devel mailing list
> >> >>> Xen-devel@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 Sep 06 15:02:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 2012 15:02:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9dar-0001BZ-9q; Thu, 06 Sep 2012 15:02:09 +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 1T9dap-0001BU-W4
	for xen-devel@lists.xensource.com; Thu, 06 Sep 2012 15:02:08 +0000
Received: from [85.158.143.99:30019] by server-3.bemta-4.messagelabs.com id
	67/83-08232-FEAB8405; Thu, 06 Sep 2012 15:02:07 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1346943724!19170756!1
X-Originating-IP: [216.32.180.185]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2581 invoked from network); 6 Sep 2012 15:02:06 -0000
Received: from co1ehsobe002.messaging.microsoft.com (HELO
	co1outboundpool.messaging.microsoft.com) (216.32.180.185)
	by server-8.tower-216.messagelabs.com with AES128-SHA encrypted SMTP;
	6 Sep 2012 15:02:06 -0000
Received: from mail56-co1-R.bigfish.com (10.243.78.235) by
	CO1EHSOBE002.bigfish.com (10.243.66.65) with Microsoft SMTP Server id
	14.1.225.23; Thu, 6 Sep 2012 15:02:04 +0000
Received: from mail56-co1 (localhost [127.0.0.1])	by mail56-co1-R.bigfish.com
	(Postfix) with ESMTP id 7BFA3B0021D;
	Thu,  6 Sep 2012 15:02:04 +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: -6
X-BigFish: VPS-6(zzbb2dI98dI9371I936eI1432I4015Izz1202hzz8275bhz2dh668h839hd25he5bhf0ah107ah1155h)
Received: from mail56-co1 (localhost.localdomain [127.0.0.1]) by mail56-co1
	(MessageSwitch) id 1346943722895196_5478;
	Thu,  6 Sep 2012 15:02:02 +0000 (UTC)
Received: from CO1EHSMHS004.bigfish.com (unknown [10.243.78.229])	by
	mail56-co1.bigfish.com (Postfix) with ESMTP id CD31A3C0068;
	Thu,  6 Sep 2012 15:02:02 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	CO1EHSMHS004.bigfish.com (10.243.66.14) with Microsoft SMTP Server id
	14.1.225.23; Thu, 6 Sep 2012 15:02:00 +0000
X-WSS-ID: 0M9XOFA-01-639-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 2C84A1028098;	Thu,  6 Sep 2012 10:01:57 -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, 6 Sep 2012 10:02:14 -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;
	Thu, 6 Sep 2012 10:01: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, 6 Sep 2012
	11:01:54 -0400
Received: from [165.204.15.57] (gran.osrc.amd.com [165.204.15.57])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id 5E7DB49C121; Thu,  6 Sep 2012
	16:01:53 +0100 (BST)
Message-ID: <5048BB29.4040900@amd.com>
Date: Thu, 6 Sep 2012 17:03:05 +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: Sander Eikelenboom <linux@eikelenboom.it>
References: <504764E2.4000809@amd.com>
	<326589347.20120906005936@eikelenboom.it>
	<5048A603.3070207@amd.com>
	<483486315.20120906155001@eikelenboom.it>
In-Reply-To: <483486315.20120906155001@eikelenboom.it>
X-OriginatorOrg: amd.com
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH] amd iommu: Dump flags of IO page faults
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 09/06/2012 03:50 PM, Sander Eikelenboom wrote:
>
> Thursday, September 6, 2012, 3:32:51 PM, you wrote:
>
>> On 09/06/2012 12:59 AM, Sander Eikelenboom wrote:
>>>
>>> Wednesday, September 5, 2012, 4:42:42 PM, you wrote:
>>>
>>>> Hi Jan,
>>>> Attached patch dumps io page fault flags. The flags show the reason of
>>>> the fault and tell us if this is an unmapped interrupt fault or a DMA fault.
>>>
>>>> Thanks,
>>>> Wei
>>>
>>>> signed-off-by: Wei Wang<wei.wang2@amd.com>
>>>
>>>
>>> I have applied the patch and the flags seem to differ between the faults:
>>>
>>> AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0a06, fault address = 0xc2c2c2c0, flags = 0x000
>>> (XEN) [2012-09-05 20:54:16] AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0a06, fault address = 0xc2c2c2c0, flags = 0x000
>>> (XEN) [2012-09-05 20:54:16] AMD-Vi: IO_PAGE_FAULT: domain = 14, device id = 0x0700, fault address = 0xa8d339e0, flags = 0x020
>>> (XEN) [2012-09-05 20:54:16] AMD-Vi: IO_PAGE_FAULT: domain = 14, device id = 0x0700, fault address = 0xa8d33a40, flags = 0x020
>
>> OK, so they are not interrupt requests. I guess further information from
>> your system would be helpful to debug this issue:
>> 1) xl info
>> 2) xl list
>> 3) lscpi -vvv (NOTE: not in dom0 but in your guest)
>> 4) cat /proc/iomem (in both dom0 and your hvm guest)
>
> dom14 is not a HVM guest,it's a PV guest.

Ah, I see. PV guest is quite different than hvm, it does use p2m tables 
as io page tables. So no-sharept option does not work in this case. PV 
guests always use separated io page tables. There might be some 
incorrect mappings on the page tables. I will check this on my side.

Thanks,
Wei

> I will try to make a complete package, and try with one pv domain only where the devices are being passed through just to simplify the setup.
>
>
>> * I would also like to know the symptoms of device 0x0700 when IO_PF
>> happened. Did it stop working?
>
> Yes it stops working, the video capture just freezes, but the driver doesn't bail out.
> For the USB controller (0x0a06) it starts to give errors for usbdev_open in the guest.
>
>> (BTW: I copied a few options from your boot cmd line and it worked with
>> my RD890 system
>
>> dom0_mem=1024M,max:1024M loglvl=all loglvl_guest=all console_timestamps
>> cpuidle cpufreq=xen noreboot debug lapic=debug apic_verbosity=debug
>> apic=debug iommu=on,verbose,debug,no-sharept
>
>> * so, what OEM board you have?)
>
> MSI 890FXA-GD70
>
>> Also from your log, these lines looks very strange:
>
>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>> read-only memory page. gfn=0xd5, mfn=0xa4a11
>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>> read-only memory page. gfn=0xd7, mfn=0xa4a0f
>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>> read-only memory page. gfn=0xd9, mfn=0xa4a0d
>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>> read-only memory page. gfn=0xdb, mfn=0xa4a0b
>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>> read-only memory page. gfn=0xdd, mfn=0xa4a09
>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>> read-only memory page. gfn=0xdf, mfn=0xa4a07
>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>> read-only memory page. gfn=0xe1, mfn=0xa4a05
>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>> read-only memory page. gfn=0xe3, mfn=0xa4a03
>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>> read-only memory page. gfn=0xe5, mfn=0xa4a01
>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>> read-only memory page. gfn=0xe7, mfn=0xa463f
>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>> read-only memory page. gfn=0xe9, mfn=0xa463d
>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>> read-only memory page. gfn=0xeb, mfn=0xa463b
>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>> read-only memory page. gfn=0xed, mfn=0xa4639
>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>> read-only memory page. gfn=0xef, mfn=0xa4637
>> (XEN) [2012-09-04 16:13:56] AMD-Vi: IO_PAGE_FAULT: domain = 0, device id
>> = 0x0a06, fault address = 0xc2c2c2c0
>> (XEN) [2012-09-04 16:13:56] AMD-Vi: IO_PAGE_FAULT: domain = 14, device
>> id = 0x0700, fault address = 0xa90f8300
>> (XEN) [2012-09-04 16:13:56] AMD-Vi: IO_PAGE_FAULT: domain = 14, device
>> id = 0x0700, fault address = 0xa90f8340
>> (XEN) [2012-09-04 16:13:56] AMD-Vi: IO_PAGE_FAULT: domain = 14, device
>> id = 0x0700, fault address = 0xa90f8380
>> (XEN) [2012-09-04 16:13:56] AMD-Vi: IO_PAGE_FAULT: domain = 14, device
>> id = 0x0700, fault address = 0xa90f83c0
>
>> * they are just followed by the IO PAGE fault. Do you know where are
>> they from? Your video card driver maybe?
>
>  From a HVM domain with a old (3.0.3) kernel, but the faults also occur without this domain being started.
>
>
>> Thanks,
>> Wei
>
>
>>> Complete xl dmesg and lspci -vvvknn attached.
>>>
>>> Thx
>>>
>>> --
>>> Sander
>
>
>
>
>



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

From xen-devel-bounces@lists.xen.org Thu Sep 06 15:02:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 2012 15:02:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9dar-0001BZ-9q; Thu, 06 Sep 2012 15:02:09 +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 1T9dap-0001BU-W4
	for xen-devel@lists.xensource.com; Thu, 06 Sep 2012 15:02:08 +0000
Received: from [85.158.143.99:30019] by server-3.bemta-4.messagelabs.com id
	67/83-08232-FEAB8405; Thu, 06 Sep 2012 15:02:07 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1346943724!19170756!1
X-Originating-IP: [216.32.180.185]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2581 invoked from network); 6 Sep 2012 15:02:06 -0000
Received: from co1ehsobe002.messaging.microsoft.com (HELO
	co1outboundpool.messaging.microsoft.com) (216.32.180.185)
	by server-8.tower-216.messagelabs.com with AES128-SHA encrypted SMTP;
	6 Sep 2012 15:02:06 -0000
Received: from mail56-co1-R.bigfish.com (10.243.78.235) by
	CO1EHSOBE002.bigfish.com (10.243.66.65) with Microsoft SMTP Server id
	14.1.225.23; Thu, 6 Sep 2012 15:02:04 +0000
Received: from mail56-co1 (localhost [127.0.0.1])	by mail56-co1-R.bigfish.com
	(Postfix) with ESMTP id 7BFA3B0021D;
	Thu,  6 Sep 2012 15:02:04 +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: -6
X-BigFish: VPS-6(zzbb2dI98dI9371I936eI1432I4015Izz1202hzz8275bhz2dh668h839hd25he5bhf0ah107ah1155h)
Received: from mail56-co1 (localhost.localdomain [127.0.0.1]) by mail56-co1
	(MessageSwitch) id 1346943722895196_5478;
	Thu,  6 Sep 2012 15:02:02 +0000 (UTC)
Received: from CO1EHSMHS004.bigfish.com (unknown [10.243.78.229])	by
	mail56-co1.bigfish.com (Postfix) with ESMTP id CD31A3C0068;
	Thu,  6 Sep 2012 15:02:02 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	CO1EHSMHS004.bigfish.com (10.243.66.14) with Microsoft SMTP Server id
	14.1.225.23; Thu, 6 Sep 2012 15:02:00 +0000
X-WSS-ID: 0M9XOFA-01-639-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 2C84A1028098;	Thu,  6 Sep 2012 10:01:57 -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, 6 Sep 2012 10:02:14 -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;
	Thu, 6 Sep 2012 10:01: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, 6 Sep 2012
	11:01:54 -0400
Received: from [165.204.15.57] (gran.osrc.amd.com [165.204.15.57])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id 5E7DB49C121; Thu,  6 Sep 2012
	16:01:53 +0100 (BST)
Message-ID: <5048BB29.4040900@amd.com>
Date: Thu, 6 Sep 2012 17:03:05 +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: Sander Eikelenboom <linux@eikelenboom.it>
References: <504764E2.4000809@amd.com>
	<326589347.20120906005936@eikelenboom.it>
	<5048A603.3070207@amd.com>
	<483486315.20120906155001@eikelenboom.it>
In-Reply-To: <483486315.20120906155001@eikelenboom.it>
X-OriginatorOrg: amd.com
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH] amd iommu: Dump flags of IO page faults
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 09/06/2012 03:50 PM, Sander Eikelenboom wrote:
>
> Thursday, September 6, 2012, 3:32:51 PM, you wrote:
>
>> On 09/06/2012 12:59 AM, Sander Eikelenboom wrote:
>>>
>>> Wednesday, September 5, 2012, 4:42:42 PM, you wrote:
>>>
>>>> Hi Jan,
>>>> Attached patch dumps io page fault flags. The flags show the reason of
>>>> the fault and tell us if this is an unmapped interrupt fault or a DMA fault.
>>>
>>>> Thanks,
>>>> Wei
>>>
>>>> signed-off-by: Wei Wang<wei.wang2@amd.com>
>>>
>>>
>>> I have applied the patch and the flags seem to differ between the faults:
>>>
>>> AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0a06, fault address = 0xc2c2c2c0, flags = 0x000
>>> (XEN) [2012-09-05 20:54:16] AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0a06, fault address = 0xc2c2c2c0, flags = 0x000
>>> (XEN) [2012-09-05 20:54:16] AMD-Vi: IO_PAGE_FAULT: domain = 14, device id = 0x0700, fault address = 0xa8d339e0, flags = 0x020
>>> (XEN) [2012-09-05 20:54:16] AMD-Vi: IO_PAGE_FAULT: domain = 14, device id = 0x0700, fault address = 0xa8d33a40, flags = 0x020
>
>> OK, so they are not interrupt requests. I guess further information from
>> your system would be helpful to debug this issue:
>> 1) xl info
>> 2) xl list
>> 3) lscpi -vvv (NOTE: not in dom0 but in your guest)
>> 4) cat /proc/iomem (in both dom0 and your hvm guest)
>
> dom14 is not a HVM guest,it's a PV guest.

Ah, I see. PV guest is quite different than hvm, it does use p2m tables 
as io page tables. So no-sharept option does not work in this case. PV 
guests always use separated io page tables. There might be some 
incorrect mappings on the page tables. I will check this on my side.

Thanks,
Wei

> I will try to make a complete package, and try with one pv domain only where the devices are being passed through just to simplify the setup.
>
>
>> * I would also like to know the symptoms of device 0x0700 when IO_PF
>> happened. Did it stop working?
>
> Yes it stops working, the video capture just freezes, but the driver doesn't bail out.
> For the USB controller (0x0a06) it starts to give errors for usbdev_open in the guest.
>
>> (BTW: I copied a few options from your boot cmd line and it worked with
>> my RD890 system
>
>> dom0_mem=1024M,max:1024M loglvl=all loglvl_guest=all console_timestamps
>> cpuidle cpufreq=xen noreboot debug lapic=debug apic_verbosity=debug
>> apic=debug iommu=on,verbose,debug,no-sharept
>
>> * so, what OEM board you have?)
>
> MSI 890FXA-GD70
>
>> Also from your log, these lines looks very strange:
>
>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>> read-only memory page. gfn=0xd5, mfn=0xa4a11
>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>> read-only memory page. gfn=0xd7, mfn=0xa4a0f
>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>> read-only memory page. gfn=0xd9, mfn=0xa4a0d
>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>> read-only memory page. gfn=0xdb, mfn=0xa4a0b
>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>> read-only memory page. gfn=0xdd, mfn=0xa4a09
>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>> read-only memory page. gfn=0xdf, mfn=0xa4a07
>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>> read-only memory page. gfn=0xe1, mfn=0xa4a05
>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>> read-only memory page. gfn=0xe3, mfn=0xa4a03
>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>> read-only memory page. gfn=0xe5, mfn=0xa4a01
>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>> read-only memory page. gfn=0xe7, mfn=0xa463f
>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>> read-only memory page. gfn=0xe9, mfn=0xa463d
>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>> read-only memory page. gfn=0xeb, mfn=0xa463b
>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>> read-only memory page. gfn=0xed, mfn=0xa4639
>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>> read-only memory page. gfn=0xef, mfn=0xa4637
>> (XEN) [2012-09-04 16:13:56] AMD-Vi: IO_PAGE_FAULT: domain = 0, device id
>> = 0x0a06, fault address = 0xc2c2c2c0
>> (XEN) [2012-09-04 16:13:56] AMD-Vi: IO_PAGE_FAULT: domain = 14, device
>> id = 0x0700, fault address = 0xa90f8300
>> (XEN) [2012-09-04 16:13:56] AMD-Vi: IO_PAGE_FAULT: domain = 14, device
>> id = 0x0700, fault address = 0xa90f8340
>> (XEN) [2012-09-04 16:13:56] AMD-Vi: IO_PAGE_FAULT: domain = 14, device
>> id = 0x0700, fault address = 0xa90f8380
>> (XEN) [2012-09-04 16:13:56] AMD-Vi: IO_PAGE_FAULT: domain = 14, device
>> id = 0x0700, fault address = 0xa90f83c0
>
>> * they are just followed by the IO PAGE fault. Do you know where are
>> they from? Your video card driver maybe?
>
>  From a HVM domain with a old (3.0.3) kernel, but the faults also occur without this domain being started.
>
>
>> Thanks,
>> Wei
>
>
>>> Complete xl dmesg and lspci -vvvknn attached.
>>>
>>> Thx
>>>
>>> --
>>> Sander
>
>
>
>
>



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

From xen-devel-bounces@lists.xen.org Thu Sep 06 15:02:59 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 2012 15:02:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9dbR-0001Dl-O3; Thu, 06 Sep 2012 15:02: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 1T9dbP-0001DL-N2
	for xen-devel@lists.xen.org; Thu, 06 Sep 2012 15:02:43 +0000
Received: from [85.158.143.99:27179] by server-2.bemta-4.messagelabs.com id
	E0/B8-21239-21BB8405; Thu, 06 Sep 2012 15:02:42 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1346943762!28357518!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM5ODQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16173 invoked from network); 6 Sep 2012 15:02:42 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-3.tower-216.messagelabs.com with SMTP;
	6 Sep 2012 15:02:42 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 06 Sep 2012 16:02:42 +0100
Message-Id: <5048D76802000078000996B2@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 06 Sep 2012 16:03:36 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ben Guthro" <ben@guthro.net>
References: <1346665360.25864.2.camel@zakaz.uk.xensource.com>
	<5048B4DF0200007800099554@nat28.tlf.novell.com>
	<CAOvdn6VUoFN8n-weX4Ni6-O2HivLepWfXV+JMuj7Hjc7oXN9cg@mail.gmail.com>
	<CAOvdn6XUFL665RNvL6JKRovgPYYO32ujTkSE4LTrQy8xTU_9fQ@mail.gmail.com>
	<CAOvdn6WU=haz48S=ok3M8mAovuag4wQtaj2dhGmJvVfrqK3rJg@mail.gmail.com>
In-Reply-To: <CAOvdn6WU=haz48S=ok3M8mAovuag4wQtaj2dhGmJvVfrqK3rJg@mail.gmail.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] Xen 4.2.0 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 06.09.12 at 16:35, Ben Guthro <ben@guthro.net> wrote:
> I may have claimed success on this second one too soon. Subsequent
> tests, and expansion to other systems shows S3 still to be a problem
> on these laptops.

Blinking LEDs generally mean Linux crashed (Xen doesn't do any
blinking).

> Being a laptop, without a serial port, of course makes this more
> difficult to debug.

And the screen isn't back to be visible yet I understand. Is that
even if you run the screen in 80x25 text mode?

Does that laptop have a EHCI debug port?

Jan


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

From xen-devel-bounces@lists.xen.org Thu Sep 06 15:02:59 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 2012 15:02:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9dbR-0001Dl-O3; Thu, 06 Sep 2012 15:02: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 1T9dbP-0001DL-N2
	for xen-devel@lists.xen.org; Thu, 06 Sep 2012 15:02:43 +0000
Received: from [85.158.143.99:27179] by server-2.bemta-4.messagelabs.com id
	E0/B8-21239-21BB8405; Thu, 06 Sep 2012 15:02:42 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1346943762!28357518!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM5ODQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16173 invoked from network); 6 Sep 2012 15:02:42 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-3.tower-216.messagelabs.com with SMTP;
	6 Sep 2012 15:02:42 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 06 Sep 2012 16:02:42 +0100
Message-Id: <5048D76802000078000996B2@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 06 Sep 2012 16:03:36 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ben Guthro" <ben@guthro.net>
References: <1346665360.25864.2.camel@zakaz.uk.xensource.com>
	<5048B4DF0200007800099554@nat28.tlf.novell.com>
	<CAOvdn6VUoFN8n-weX4Ni6-O2HivLepWfXV+JMuj7Hjc7oXN9cg@mail.gmail.com>
	<CAOvdn6XUFL665RNvL6JKRovgPYYO32ujTkSE4LTrQy8xTU_9fQ@mail.gmail.com>
	<CAOvdn6WU=haz48S=ok3M8mAovuag4wQtaj2dhGmJvVfrqK3rJg@mail.gmail.com>
In-Reply-To: <CAOvdn6WU=haz48S=ok3M8mAovuag4wQtaj2dhGmJvVfrqK3rJg@mail.gmail.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] Xen 4.2.0 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 06.09.12 at 16:35, Ben Guthro <ben@guthro.net> wrote:
> I may have claimed success on this second one too soon. Subsequent
> tests, and expansion to other systems shows S3 still to be a problem
> on these laptops.

Blinking LEDs generally mean Linux crashed (Xen doesn't do any
blinking).

> Being a laptop, without a serial port, of course makes this more
> difficult to debug.

And the screen isn't back to be visible yet I understand. Is that
even if you run the screen in 80x25 text mode?

Does that laptop have a EHCI debug port?

Jan


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

From xen-devel-bounces@lists.xen.org Thu Sep 06 15:09:22 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 2012 15:09:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9dhZ-0001d7-Tc; Thu, 06 Sep 2012 15:09:05 +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 1T9dhY-0001cw-Cj
	for xen-devel@lists.xensource.com; Thu, 06 Sep 2012 15:09:04 +0000
Received: from [85.158.143.35:28704] by server-1.bemta-4.messagelabs.com id
	89/55-12504-F8CB8405; Thu, 06 Sep 2012 15:09:03 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-15.tower-21.messagelabs.com!1346944142!15228455!1
X-Originating-IP: [188.40.164.121]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8523 invoked from network); 6 Sep 2012 15:09:02 -0000
Received: from static.121.164.40.188.clients.your-server.de (HELO
	smtp.eikelenboom.it) (188.40.164.121)
	by server-15.tower-21.messagelabs.com with AES256-SHA encrypted SMTP;
	6 Sep 2012 15:09:02 -0000
Received: from 128-64-ftth.onsneteindhoven.nl ([88.159.64.128]:53899
	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 1T9dhX-0008FI-9J; Thu, 06 Sep 2012 17:09:03 +0200
Date: Thu, 6 Sep 2012 17:08:57 +0200
From: Sander Eikelenboom <linux@eikelenboom.it>
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <32670651.20120906170857@eikelenboom.it>
To: Wei Wang <wei.wang2@amd.com>
In-Reply-To: <5048BB29.4040900@amd.com>
References: <504764E2.4000809@amd.com>
	<326589347.20120906005936@eikelenboom.it>
	<5048A603.3070207@amd.com>
	<483486315.20120906155001@eikelenboom.it>
	<5048BB29.4040900@amd.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH] amd iommu: Dump flags of IO page faults
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


Thursday, September 6, 2012, 5:03:05 PM, you wrote:

> On 09/06/2012 03:50 PM, Sander Eikelenboom wrote:
>>
>> Thursday, September 6, 2012, 3:32:51 PM, you wrote:
>>
>>> On 09/06/2012 12:59 AM, Sander Eikelenboom wrote:
>>>>
>>>> Wednesday, September 5, 2012, 4:42:42 PM, you wrote:
>>>>
>>>>> Hi Jan,
>>>>> Attached patch dumps io page fault flags. The flags show the reason of
>>>>> the fault and tell us if this is an unmapped interrupt fault or a DMA fault.
>>>>
>>>>> Thanks,
>>>>> Wei
>>>>
>>>>> signed-off-by: Wei Wang<wei.wang2@amd.com>
>>>>
>>>>
>>>> I have applied the patch and the flags seem to differ between the faults:
>>>>
>>>> AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0a06, fault address = 0xc2c2c2c0, flags = 0x000
>>>> (XEN) [2012-09-05 20:54:16] AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0a06, fault address = 0xc2c2c2c0, flags = 0x000
>>>> (XEN) [2012-09-05 20:54:16] AMD-Vi: IO_PAGE_FAULT: domain = 14, device id = 0x0700, fault address = 0xa8d339e0, flags = 0x020
>>>> (XEN) [2012-09-05 20:54:16] AMD-Vi: IO_PAGE_FAULT: domain = 14, device id = 0x0700, fault address = 0xa8d33a40, flags = 0x020
>>
>>> OK, so they are not interrupt requests. I guess further information from
>>> your system would be helpful to debug this issue:
>>> 1) xl info
>>> 2) xl list
>>> 3) lscpi -vvv (NOTE: not in dom0 but in your guest)
>>> 4) cat /proc/iomem (in both dom0 and your hvm guest)
>>
>> dom14 is not a HVM guest,it's a PV guest.

> Ah, I see. PV guest is quite different than hvm, it does use p2m tables 
> as io page tables. So no-sharept option does not work in this case. PV 
> guests always use separated io page tables. There might be some 
> incorrect mappings on the page tables. I will check this on my side.

> Thanks,
> Wei

In that case it's perhaps mysteriously semi related to a p2m bug in kernels > 3.4 which freezes guests on my intel box.
Though guests start fine on the amd box with kernels > 3.4, perhaps it does give issues for iommu if those are tied somehow.


>> I will try to make a complete package, and try with one pv domain only where the devices are being passed through just to simplify the setup.
>>
>>
>>> * I would also like to know the symptoms of device 0x0700 when IO_PF
>>> happened. Did it stop working?
>>
>> Yes it stops working, the video capture just freezes, but the driver doesn't bail out.
>> For the USB controller (0x0a06) it starts to give errors for usbdev_open in the guest.
>>
>>> (BTW: I copied a few options from your boot cmd line and it worked with
>>> my RD890 system
>>
>>> dom0_mem=1024M,max:1024M loglvl=all loglvl_guest=all console_timestamps
>>> cpuidle cpufreq=xen noreboot debug lapic=debug apic_verbosity=debug
>>> apic=debug iommu=on,verbose,debug,no-sharept
>>
>>> * so, what OEM board you have?)
>>
>> MSI 890FXA-GD70
>>
>>> Also from your log, these lines looks very strange:
>>
>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>>> read-only memory page. gfn=0xd5, mfn=0xa4a11
>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>>> read-only memory page. gfn=0xd7, mfn=0xa4a0f
>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>>> read-only memory page. gfn=0xd9, mfn=0xa4a0d
>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>>> read-only memory page. gfn=0xdb, mfn=0xa4a0b
>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>>> read-only memory page. gfn=0xdd, mfn=0xa4a09
>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>>> read-only memory page. gfn=0xdf, mfn=0xa4a07
>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>>> read-only memory page. gfn=0xe1, mfn=0xa4a05
>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>>> read-only memory page. gfn=0xe3, mfn=0xa4a03
>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>>> read-only memory page. gfn=0xe5, mfn=0xa4a01
>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>>> read-only memory page. gfn=0xe7, mfn=0xa463f
>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>>> read-only memory page. gfn=0xe9, mfn=0xa463d
>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>>> read-only memory page. gfn=0xeb, mfn=0xa463b
>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>>> read-only memory page. gfn=0xed, mfn=0xa4639
>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>>> read-only memory page. gfn=0xef, mfn=0xa4637
>>> (XEN) [2012-09-04 16:13:56] AMD-Vi: IO_PAGE_FAULT: domain = 0, device id
>>> = 0x0a06, fault address = 0xc2c2c2c0
>>> (XEN) [2012-09-04 16:13:56] AMD-Vi: IO_PAGE_FAULT: domain = 14, device
>>> id = 0x0700, fault address = 0xa90f8300
>>> (XEN) [2012-09-04 16:13:56] AMD-Vi: IO_PAGE_FAULT: domain = 14, device
>>> id = 0x0700, fault address = 0xa90f8340
>>> (XEN) [2012-09-04 16:13:56] AMD-Vi: IO_PAGE_FAULT: domain = 14, device
>>> id = 0x0700, fault address = 0xa90f8380
>>> (XEN) [2012-09-04 16:13:56] AMD-Vi: IO_PAGE_FAULT: domain = 14, device
>>> id = 0x0700, fault address = 0xa90f83c0
>>
>>> * they are just followed by the IO PAGE fault. Do you know where are
>>> they from? Your video card driver maybe?
>>
>>  From a HVM domain with a old (3.0.3) kernel, but the faults also occur without this domain being started.
>>
>>
>>> Thanks,
>>> Wei
>>
>>
>>>> Complete xl dmesg and lspci -vvvknn attached.
>>>>
>>>> Thx
>>>>
>>>> --
>>>> Sander
>>
>>
>>
>>
>>





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

From xen-devel-bounces@lists.xen.org Thu Sep 06 15:09:22 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 2012 15:09:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9dhZ-0001d7-Tc; Thu, 06 Sep 2012 15:09:05 +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 1T9dhY-0001cw-Cj
	for xen-devel@lists.xensource.com; Thu, 06 Sep 2012 15:09:04 +0000
Received: from [85.158.143.35:28704] by server-1.bemta-4.messagelabs.com id
	89/55-12504-F8CB8405; Thu, 06 Sep 2012 15:09:03 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-15.tower-21.messagelabs.com!1346944142!15228455!1
X-Originating-IP: [188.40.164.121]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8523 invoked from network); 6 Sep 2012 15:09:02 -0000
Received: from static.121.164.40.188.clients.your-server.de (HELO
	smtp.eikelenboom.it) (188.40.164.121)
	by server-15.tower-21.messagelabs.com with AES256-SHA encrypted SMTP;
	6 Sep 2012 15:09:02 -0000
Received: from 128-64-ftth.onsneteindhoven.nl ([88.159.64.128]:53899
	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 1T9dhX-0008FI-9J; Thu, 06 Sep 2012 17:09:03 +0200
Date: Thu, 6 Sep 2012 17:08:57 +0200
From: Sander Eikelenboom <linux@eikelenboom.it>
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <32670651.20120906170857@eikelenboom.it>
To: Wei Wang <wei.wang2@amd.com>
In-Reply-To: <5048BB29.4040900@amd.com>
References: <504764E2.4000809@amd.com>
	<326589347.20120906005936@eikelenboom.it>
	<5048A603.3070207@amd.com>
	<483486315.20120906155001@eikelenboom.it>
	<5048BB29.4040900@amd.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH] amd iommu: Dump flags of IO page faults
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


Thursday, September 6, 2012, 5:03:05 PM, you wrote:

> On 09/06/2012 03:50 PM, Sander Eikelenboom wrote:
>>
>> Thursday, September 6, 2012, 3:32:51 PM, you wrote:
>>
>>> On 09/06/2012 12:59 AM, Sander Eikelenboom wrote:
>>>>
>>>> Wednesday, September 5, 2012, 4:42:42 PM, you wrote:
>>>>
>>>>> Hi Jan,
>>>>> Attached patch dumps io page fault flags. The flags show the reason of
>>>>> the fault and tell us if this is an unmapped interrupt fault or a DMA fault.
>>>>
>>>>> Thanks,
>>>>> Wei
>>>>
>>>>> signed-off-by: Wei Wang<wei.wang2@amd.com>
>>>>
>>>>
>>>> I have applied the patch and the flags seem to differ between the faults:
>>>>
>>>> AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0a06, fault address = 0xc2c2c2c0, flags = 0x000
>>>> (XEN) [2012-09-05 20:54:16] AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0a06, fault address = 0xc2c2c2c0, flags = 0x000
>>>> (XEN) [2012-09-05 20:54:16] AMD-Vi: IO_PAGE_FAULT: domain = 14, device id = 0x0700, fault address = 0xa8d339e0, flags = 0x020
>>>> (XEN) [2012-09-05 20:54:16] AMD-Vi: IO_PAGE_FAULT: domain = 14, device id = 0x0700, fault address = 0xa8d33a40, flags = 0x020
>>
>>> OK, so they are not interrupt requests. I guess further information from
>>> your system would be helpful to debug this issue:
>>> 1) xl info
>>> 2) xl list
>>> 3) lscpi -vvv (NOTE: not in dom0 but in your guest)
>>> 4) cat /proc/iomem (in both dom0 and your hvm guest)
>>
>> dom14 is not a HVM guest,it's a PV guest.

> Ah, I see. PV guest is quite different than hvm, it does use p2m tables 
> as io page tables. So no-sharept option does not work in this case. PV 
> guests always use separated io page tables. There might be some 
> incorrect mappings on the page tables. I will check this on my side.

> Thanks,
> Wei

In that case it's perhaps mysteriously semi related to a p2m bug in kernels > 3.4 which freezes guests on my intel box.
Though guests start fine on the amd box with kernels > 3.4, perhaps it does give issues for iommu if those are tied somehow.


>> I will try to make a complete package, and try with one pv domain only where the devices are being passed through just to simplify the setup.
>>
>>
>>> * I would also like to know the symptoms of device 0x0700 when IO_PF
>>> happened. Did it stop working?
>>
>> Yes it stops working, the video capture just freezes, but the driver doesn't bail out.
>> For the USB controller (0x0a06) it starts to give errors for usbdev_open in the guest.
>>
>>> (BTW: I copied a few options from your boot cmd line and it worked with
>>> my RD890 system
>>
>>> dom0_mem=1024M,max:1024M loglvl=all loglvl_guest=all console_timestamps
>>> cpuidle cpufreq=xen noreboot debug lapic=debug apic_verbosity=debug
>>> apic=debug iommu=on,verbose,debug,no-sharept
>>
>>> * so, what OEM board you have?)
>>
>> MSI 890FXA-GD70
>>
>>> Also from your log, these lines looks very strange:
>>
>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>>> read-only memory page. gfn=0xd5, mfn=0xa4a11
>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>>> read-only memory page. gfn=0xd7, mfn=0xa4a0f
>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>>> read-only memory page. gfn=0xd9, mfn=0xa4a0d
>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>>> read-only memory page. gfn=0xdb, mfn=0xa4a0b
>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>>> read-only memory page. gfn=0xdd, mfn=0xa4a09
>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>>> read-only memory page. gfn=0xdf, mfn=0xa4a07
>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>>> read-only memory page. gfn=0xe1, mfn=0xa4a05
>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>>> read-only memory page. gfn=0xe3, mfn=0xa4a03
>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>>> read-only memory page. gfn=0xe5, mfn=0xa4a01
>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>>> read-only memory page. gfn=0xe7, mfn=0xa463f
>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>>> read-only memory page. gfn=0xe9, mfn=0xa463d
>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>>> read-only memory page. gfn=0xeb, mfn=0xa463b
>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>>> read-only memory page. gfn=0xed, mfn=0xa4639
>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>>> read-only memory page. gfn=0xef, mfn=0xa4637
>>> (XEN) [2012-09-04 16:13:56] AMD-Vi: IO_PAGE_FAULT: domain = 0, device id
>>> = 0x0a06, fault address = 0xc2c2c2c0
>>> (XEN) [2012-09-04 16:13:56] AMD-Vi: IO_PAGE_FAULT: domain = 14, device
>>> id = 0x0700, fault address = 0xa90f8300
>>> (XEN) [2012-09-04 16:13:56] AMD-Vi: IO_PAGE_FAULT: domain = 14, device
>>> id = 0x0700, fault address = 0xa90f8340
>>> (XEN) [2012-09-04 16:13:56] AMD-Vi: IO_PAGE_FAULT: domain = 14, device
>>> id = 0x0700, fault address = 0xa90f8380
>>> (XEN) [2012-09-04 16:13:56] AMD-Vi: IO_PAGE_FAULT: domain = 14, device
>>> id = 0x0700, fault address = 0xa90f83c0
>>
>>> * they are just followed by the IO PAGE fault. Do you know where are
>>> they from? Your video card driver maybe?
>>
>>  From a HVM domain with a old (3.0.3) kernel, but the faults also occur without this domain being started.
>>
>>
>>> Thanks,
>>> Wei
>>
>>
>>>> Complete xl dmesg and lspci -vvvknn attached.
>>>>
>>>> Thx
>>>>
>>>> --
>>>> Sander
>>
>>
>>
>>
>>





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

From xen-devel-bounces@lists.xen.org Thu Sep 06 15:29:29 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 2012 15:29: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 1T9e12-00036I-DF; Thu, 06 Sep 2012 15:29:12 +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 1T9e10-000369-5k
	for xen-devel@lists.xen.org; Thu, 06 Sep 2012 15:29:10 +0000
Received: from [85.158.143.99:36233] by server-3.bemta-4.messagelabs.com id
	11/64-08232-541C8405; Thu, 06 Sep 2012 15:29:09 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-12.tower-216.messagelabs.com!1346945348!23700744!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiA0MTgxNzk=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiA0MTgxNzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15057 invoked from network); 6 Sep 2012 15:29:09 -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; 6 Sep 2012 15:29:09 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/lk2c7pE3Rh
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-090-217.pools.arcor-ip.net [84.57.90.217])
	by smtp.strato.de (jored mo42) (RZmta 30.14 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id J02a11o86Eh3gg
	for <xen-devel@lists.xen.org>; Thu, 6 Sep 2012 17:29:08 +0200 (CEST)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id D888E183A5
	for <xen-devel@lists.xen.org>; Thu,  6 Sep 2012 17:29:07 +0200 (CEST)
MIME-Version: 1.0
X-Mercurial-Node: 8a2eef481d3ab3ca5692dd0083c95cf314fe1da3
Message-Id: <8a2eef481d3ab3ca5692.1346945346@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Thu, 06 Sep 2012 17:29:06 +0200
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH] pygrub: always append --args
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 1346945306 -7200
# Node ID 8a2eef481d3ab3ca5692dd0083c95cf314fe1da3
# Parent  19d367bf07b7687b831c212a57a70e73ea14d3b7
pygrub: always append --args

If a bootloader entry in menu.lst has no additional kernel command line
options listed and the domU.cfg has 'bootargs="--args=something"' the
additional arguments from the config file are not passed to the kernel.
The reason for that incorrect behaviour is that run_grub appends arg
only if the parsed config file has arguments listed.

Fix this by appending args from image section and the config file separatly.
To avoid adding to a NoneType initialize grubcfg['args'] to an empty string.
This does not change behaviour but simplifies the code which appends the
string.

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

diff -r 19d367bf07b7 -r 8a2eef481d3a tools/pygrub/src/pygrub
--- a/tools/pygrub/src/pygrub
+++ b/tools/pygrub/src/pygrub
@@ -615,13 +615,15 @@ def run_grub(file, entry, fs, arg):
     except IndexError:
         img = g.cf.images[0]
 
-    grubcfg = { "kernel": None, "ramdisk": None, "args": None }
+    grubcfg = { "kernel": None, "ramdisk": None, "args": "" }
 
     grubcfg["kernel"] = img.kernel[1]
     if img.initrd:
         grubcfg["ramdisk"] = img.initrd[1]
     if img.args:
-        grubcfg["args"] = img.args + " " + arg
+        grubcfg["args"] += img.args
+    if arg:
+        grubcfg["args"] += " " + args
 
     return grubcfg
 

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

From xen-devel-bounces@lists.xen.org Thu Sep 06 15:29:29 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 2012 15:29: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 1T9e12-00036I-DF; Thu, 06 Sep 2012 15:29:12 +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 1T9e10-000369-5k
	for xen-devel@lists.xen.org; Thu, 06 Sep 2012 15:29:10 +0000
Received: from [85.158.143.99:36233] by server-3.bemta-4.messagelabs.com id
	11/64-08232-541C8405; Thu, 06 Sep 2012 15:29:09 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-12.tower-216.messagelabs.com!1346945348!23700744!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiA0MTgxNzk=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiA0MTgxNzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15057 invoked from network); 6 Sep 2012 15:29:09 -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; 6 Sep 2012 15:29:09 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/lk2c7pE3Rh
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-090-217.pools.arcor-ip.net [84.57.90.217])
	by smtp.strato.de (jored mo42) (RZmta 30.14 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id J02a11o86Eh3gg
	for <xen-devel@lists.xen.org>; Thu, 6 Sep 2012 17:29:08 +0200 (CEST)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id D888E183A5
	for <xen-devel@lists.xen.org>; Thu,  6 Sep 2012 17:29:07 +0200 (CEST)
MIME-Version: 1.0
X-Mercurial-Node: 8a2eef481d3ab3ca5692dd0083c95cf314fe1da3
Message-Id: <8a2eef481d3ab3ca5692.1346945346@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Thu, 06 Sep 2012 17:29:06 +0200
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH] pygrub: always append --args
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 1346945306 -7200
# Node ID 8a2eef481d3ab3ca5692dd0083c95cf314fe1da3
# Parent  19d367bf07b7687b831c212a57a70e73ea14d3b7
pygrub: always append --args

If a bootloader entry in menu.lst has no additional kernel command line
options listed and the domU.cfg has 'bootargs="--args=something"' the
additional arguments from the config file are not passed to the kernel.
The reason for that incorrect behaviour is that run_grub appends arg
only if the parsed config file has arguments listed.

Fix this by appending args from image section and the config file separatly.
To avoid adding to a NoneType initialize grubcfg['args'] to an empty string.
This does not change behaviour but simplifies the code which appends the
string.

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

diff -r 19d367bf07b7 -r 8a2eef481d3a tools/pygrub/src/pygrub
--- a/tools/pygrub/src/pygrub
+++ b/tools/pygrub/src/pygrub
@@ -615,13 +615,15 @@ def run_grub(file, entry, fs, arg):
     except IndexError:
         img = g.cf.images[0]
 
-    grubcfg = { "kernel": None, "ramdisk": None, "args": None }
+    grubcfg = { "kernel": None, "ramdisk": None, "args": "" }
 
     grubcfg["kernel"] = img.kernel[1]
     if img.initrd:
         grubcfg["ramdisk"] = img.initrd[1]
     if img.args:
-        grubcfg["args"] = img.args + " " + arg
+        grubcfg["args"] += img.args
+    if arg:
+        grubcfg["args"] += " " + args
 
     return grubcfg
 

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

From xen-devel-bounces@lists.xen.org Thu Sep 06 15:45:50 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 2012 15: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 1T9eGh-0003il-VG; Thu, 06 Sep 2012 15:45:23 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dan.magenheimer@oracle.com>) id 1T9eGg-0003ig-A3
	for xen-devel@lists.xen.org; Thu, 06 Sep 2012 15:45:22 +0000
X-Env-Sender: dan.magenheimer@oracle.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1346946314!4309241!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDc0MTc4NQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9745 invoked from network); 6 Sep 2012 15:45:15 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-6.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 6 Sep 2012 15:45:15 -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 q86FjCwK012794
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 6 Sep 2012 15:45:13 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
	q86FjCul017884
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 6 Sep 2012 15:45:12 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
	q86Fj9il031817; Thu, 6 Sep 2012 10:45:11 -0500
MIME-Version: 1.0
Message-ID: <66d49024-8337-4e68-b204-45cdf8fcf5cc@default>
Date: Thu, 6 Sep 2012 08:44:26 -0700 (PDT)
From: Dan Magenheimer <dan.magenheimer@oracle.com>
To: Jan Beulich <JBeulich@suse.com>
References: <5047639E0200007800098DD1@nat28.tlf.novell.com>
	<c0ecf9e3-e9d1-4fc8-8427-88aff3441c33@default>
	<50486B560200007800099177@nat28.tlf.novell.com>
In-Reply-To: <50486B560200007800099177@nat28.tlf.novell.com>
X-Priority: 3
X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.7  (607090) [OL
	12.0.6661.5003 (x86)]
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: Konrad Wilk <konrad.wilk@oracle.com>,
	Zhenzhong Duan <zhenzhong.duan@oracle.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 05/11] tmem: don't access guest memory
 without using the accessors intended for this
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> From: Jan Beulich [mailto:JBeulich@suse.com]
> Subject: RE: [PATCH 05/11] tmem: don't access guest memory without using the accessors intended for
> this
> 
> >>> On 05.09.12 at 18:50, Dan Magenheimer <dan.magenheimer@oracle.com> wrote:
> >>  From: Jan Beulich [mailto:JBeulich@suse.com]
> >> Sent: Wednesday, September 05, 2012 6:37 AM
> >> To: xen-devel
> >> Cc: Dan Magenheimer; Zhenzhong Duan
> >> Subject: [PATCH 05/11] tmem: don't access guest memory without using the
> > accessors intended for this
> >>
> >> This is not permitted, not even for buffers coming from Dom0 (and it
> >> would also break the moment Dom0 runs in HVM mode). An implication from
> >> the changes here is that tmh_copy_page() can't be used anymore for
> >> control operations calling tmh_copy_{from,to}_client() (as those pass
> >> the buffer by virtual address rather than MFN).
> >>
> >> Note that tmemc_save_get_next_page() previously didn't set the returned
> >> handle's pool_id field, while the new code does. It need to be
> >> confirmed that this is not a problem (otherwise the copy-out operation
> >> will require further tmh_...() abstractions to be added).
> >>
> >> Further note that the patch removes (rather than adjusts) an invalid
> >> call to unmap_domain_page() (no matching map_domain_page()) from
> >> tmh_compress_from_client() and adds a missing one to an error return
> >> path in tmh_copy_from_client().
> >>
> >> Finally note that the patch adds a previously missing return statement
> >> to cli_get_page() (without which that function could de-reference a
> >> NULL pointer, triggerable from guest mode).
> >>
> >> This is part of XSA-15 / CVE-2012-3497.
> >>
> >> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> >
> > I'm a bit baffled by all the unrelated changes and cleanups, but
> > they all appear to be valid fixes and, most importantly, the
> > related security issues appear to be resolved.
> 
> Having gone through the patch once more, I'd be really
> curious where you spotted unrelated changes (apart from
> e.g. adding proper white space use on lines that needed
> changing anyway).
> 
> With the size of the patch, and with this one having been
> done when we still thought we would issue the patches
> together with the advisory, I would really hope not to be
> caught to have done unnecessary changes here (while
> still preserving generic style of the code, see below).

Hi Jan --

Again, I am not criticizing the end result or any part of
the patch, just noting that some of it _could_ have been
separated to a different patch, which would have made it
_much_ more obvious what was the core fix for the security issue.
No need to reiterate your reasons, I'm only providing more
detail here because it sounds as if you are asking sincerely,
not defensively.

- changing NULL to tmh_cli_buf_null
- changing parameter void *cva to tmem_cli_va_t clibuf,
  which results in
  - changing all lines that use that that parameter
   which gave you the license to
   - cleanup the whitespace in all those lines
- all code using -EFAULT that you changed to "< 0"
  works correctly (though is admittedly fragile)
- inlining the use of the bool "tmemc"
- the addition of scratch (which I think I understand may
  patch a security hole undocumented in the commit comment?)

Again, all valid cleanups, and some may even decrease the
probability that future code changes will create more
security issues, but most are IMHO unnecessary to
fix the very specific security issue at hand.  Does that
make sense?

> > I'm also unable right now to plumb the depths of the guest copying
> > macros so will have to trust Jan's good judgement.  One point in
> > particular, it's difficult to determine if the following line is
> > copying two bytes (wrong) or two uint64_t's (correct).
> >
> >> +        tmh_copy_to_client_buf(buf, pool->uuid, 2);
> 
> With
> 
> #define tmh_copy_to_client_buf(clibuf, tmembuf, cnt) \
>     copy_to_guest(guest_handle_cast(clibuf, void), tmembuf, cnt)
> 
> it is clear that it copies two elements of whatever tmembuf's
> type is, in the case at hand uint64_t.

Again, just trying to be honest and helpful... it may be clear
to you, but I would venture to guess it is _not_ clear to the
vast majority of (even highly experienced) system programmers
who have not studied the guest copying code in gory detail.

IMHO, the guest copying code is incredible in what it does
and indecipherable below the first layer.  Only the page macros
in the Linux mm subsystem rival it in layers of obfuscation ;-)

Is there any detailed documentation about how it works?  If not,
it would be good to add some.

One last time: _not_ criticizing!

Dan


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

From xen-devel-bounces@lists.xen.org Thu Sep 06 15:45:50 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 2012 15: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 1T9eGh-0003il-VG; Thu, 06 Sep 2012 15:45:23 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dan.magenheimer@oracle.com>) id 1T9eGg-0003ig-A3
	for xen-devel@lists.xen.org; Thu, 06 Sep 2012 15:45:22 +0000
X-Env-Sender: dan.magenheimer@oracle.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1346946314!4309241!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDc0MTc4NQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9745 invoked from network); 6 Sep 2012 15:45:15 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-6.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 6 Sep 2012 15:45:15 -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 q86FjCwK012794
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 6 Sep 2012 15:45:13 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
	q86FjCul017884
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 6 Sep 2012 15:45:12 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
	q86Fj9il031817; Thu, 6 Sep 2012 10:45:11 -0500
MIME-Version: 1.0
Message-ID: <66d49024-8337-4e68-b204-45cdf8fcf5cc@default>
Date: Thu, 6 Sep 2012 08:44:26 -0700 (PDT)
From: Dan Magenheimer <dan.magenheimer@oracle.com>
To: Jan Beulich <JBeulich@suse.com>
References: <5047639E0200007800098DD1@nat28.tlf.novell.com>
	<c0ecf9e3-e9d1-4fc8-8427-88aff3441c33@default>
	<50486B560200007800099177@nat28.tlf.novell.com>
In-Reply-To: <50486B560200007800099177@nat28.tlf.novell.com>
X-Priority: 3
X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.7  (607090) [OL
	12.0.6661.5003 (x86)]
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: Konrad Wilk <konrad.wilk@oracle.com>,
	Zhenzhong Duan <zhenzhong.duan@oracle.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 05/11] tmem: don't access guest memory
 without using the accessors intended for this
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> From: Jan Beulich [mailto:JBeulich@suse.com]
> Subject: RE: [PATCH 05/11] tmem: don't access guest memory without using the accessors intended for
> this
> 
> >>> On 05.09.12 at 18:50, Dan Magenheimer <dan.magenheimer@oracle.com> wrote:
> >>  From: Jan Beulich [mailto:JBeulich@suse.com]
> >> Sent: Wednesday, September 05, 2012 6:37 AM
> >> To: xen-devel
> >> Cc: Dan Magenheimer; Zhenzhong Duan
> >> Subject: [PATCH 05/11] tmem: don't access guest memory without using the
> > accessors intended for this
> >>
> >> This is not permitted, not even for buffers coming from Dom0 (and it
> >> would also break the moment Dom0 runs in HVM mode). An implication from
> >> the changes here is that tmh_copy_page() can't be used anymore for
> >> control operations calling tmh_copy_{from,to}_client() (as those pass
> >> the buffer by virtual address rather than MFN).
> >>
> >> Note that tmemc_save_get_next_page() previously didn't set the returned
> >> handle's pool_id field, while the new code does. It need to be
> >> confirmed that this is not a problem (otherwise the copy-out operation
> >> will require further tmh_...() abstractions to be added).
> >>
> >> Further note that the patch removes (rather than adjusts) an invalid
> >> call to unmap_domain_page() (no matching map_domain_page()) from
> >> tmh_compress_from_client() and adds a missing one to an error return
> >> path in tmh_copy_from_client().
> >>
> >> Finally note that the patch adds a previously missing return statement
> >> to cli_get_page() (without which that function could de-reference a
> >> NULL pointer, triggerable from guest mode).
> >>
> >> This is part of XSA-15 / CVE-2012-3497.
> >>
> >> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> >
> > I'm a bit baffled by all the unrelated changes and cleanups, but
> > they all appear to be valid fixes and, most importantly, the
> > related security issues appear to be resolved.
> 
> Having gone through the patch once more, I'd be really
> curious where you spotted unrelated changes (apart from
> e.g. adding proper white space use on lines that needed
> changing anyway).
> 
> With the size of the patch, and with this one having been
> done when we still thought we would issue the patches
> together with the advisory, I would really hope not to be
> caught to have done unnecessary changes here (while
> still preserving generic style of the code, see below).

Hi Jan --

Again, I am not criticizing the end result or any part of
the patch, just noting that some of it _could_ have been
separated to a different patch, which would have made it
_much_ more obvious what was the core fix for the security issue.
No need to reiterate your reasons, I'm only providing more
detail here because it sounds as if you are asking sincerely,
not defensively.

- changing NULL to tmh_cli_buf_null
- changing parameter void *cva to tmem_cli_va_t clibuf,
  which results in
  - changing all lines that use that that parameter
   which gave you the license to
   - cleanup the whitespace in all those lines
- all code using -EFAULT that you changed to "< 0"
  works correctly (though is admittedly fragile)
- inlining the use of the bool "tmemc"
- the addition of scratch (which I think I understand may
  patch a security hole undocumented in the commit comment?)

Again, all valid cleanups, and some may even decrease the
probability that future code changes will create more
security issues, but most are IMHO unnecessary to
fix the very specific security issue at hand.  Does that
make sense?

> > I'm also unable right now to plumb the depths of the guest copying
> > macros so will have to trust Jan's good judgement.  One point in
> > particular, it's difficult to determine if the following line is
> > copying two bytes (wrong) or two uint64_t's (correct).
> >
> >> +        tmh_copy_to_client_buf(buf, pool->uuid, 2);
> 
> With
> 
> #define tmh_copy_to_client_buf(clibuf, tmembuf, cnt) \
>     copy_to_guest(guest_handle_cast(clibuf, void), tmembuf, cnt)
> 
> it is clear that it copies two elements of whatever tmembuf's
> type is, in the case at hand uint64_t.

Again, just trying to be honest and helpful... it may be clear
to you, but I would venture to guess it is _not_ clear to the
vast majority of (even highly experienced) system programmers
who have not studied the guest copying code in gory detail.

IMHO, the guest copying code is incredible in what it does
and indecipherable below the first layer.  Only the page macros
in the Linux mm subsystem rival it in layers of obfuscation ;-)

Is there any detailed documentation about how it works?  If not,
it would be good to add some.

One last time: _not_ criticizing!

Dan


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

From xen-devel-bounces@lists.xen.org Thu Sep 06 15:52:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 2012 15:52:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9eMv-0003rR-Pz; Thu, 06 Sep 2012 15:51:49 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1T9eMu-0003rL-3C
	for xen-devel@lists.xen.org; Thu, 06 Sep 2012 15:51:48 +0000
Received: from [85.158.143.35:40906] by server-3.bemta-4.messagelabs.com id
	93/29-08232-396C8405; Thu, 06 Sep 2012 15:51:47 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1346946706!12583041!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-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13276 invoked from network); 6 Sep 2012 15:51:46 -0000
Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com)
	(74.125.83.45)
	by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Sep 2012 15:51:46 -0000
Received: by eeke53 with SMTP id e53so878582eek.32
	for <xen-devel@lists.xen.org>; Thu, 06 Sep 2012 08:51:46 -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=OpHBojDxaMrVdASY91jXZUs5CqshtE43OT9cu+pfxIA=;
	b=Dx4VshgUi2riE5oKi0IF9+41Oly4Xo/VcFF11UJ/x2Xae5fhEJWzBw7aNNZec1+Gf+
	++g8yUlO0sbtSyi1XT8KdjP//9u/cjlrVVcHLt2CHzniR5trS0x3tOzShVsVAT5y8JKX
	KdtetvtJWXa4A+hT9Rsy7rFdvDIyhnguaqD+7dGGGdffnohIZ3FUDcq2NVGGg2CGU2nL
	wPXp3l/vEvYZUNrmTWB0s/mYcNPV/SCgJxaPlcc/UhMV02R1i6979K8/UXBxrSKbdE1k
	J8QOdNWk/k5x/yJO+pqRSG6yJIBy5amcMXR4qxwTFDdLQ3dPLeoEnPqOYX7gLuYSJSeA
	dlnw==
Received: by 10.14.179.136 with SMTP id h8mr3774618eem.6.1346946706593;
	Thu, 06 Sep 2012 08:51:46 -0700 (PDT)
Received: from [192.168.1.69] (host86-184-74-117.range86-184.btcentralplus.com.
	[86.184.74.117])
	by mx.google.com with ESMTPS id r45sm7085593eem.6.2012.09.06.08.51.45
	(version=SSLv3 cipher=OTHER); Thu, 06 Sep 2012 08:51:45 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Thu, 06 Sep 2012 16:51:43 +0100
From: Keir Fraser <keir.xen@gmail.com>
To: Jan Beulich <JBeulich@suse.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <CC6E851F.3DE9F%keir.xen@gmail.com>
Thread-Topic: [PATCH] xen: clamp bitmaps to correct number of bits
Thread-Index: Ac2MR4LhUdhduhlwuUOz6Zgb4jarfA==
In-Reply-To: <5048D39D0200007800099684@nat28.tlf.novell.com>
Mime-version: 1.0
Cc: "Tim \(Xen.org\)" <tim@xen.org>, 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] [PATCH] xen: clamp bitmaps to correct number of bits
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/09/2012 15:47, "Jan Beulich" <JBeulich@suse.com> wrote:

>> I'll fold them in, it was convenient to have variables while I was
>> printk'ing what I was doing but not any more.
> 
> I won't ask you for another round because of this, but you
> still left the parameter and remaining local variable as plain
> int, nor did you insert whitespace into the expressions. If I
> were the one to commit this, I would do the adjustment while
> committing...
> 
> Anyway, as long as there's no easily visible tools side bug
> addressed by this, I would think we should rather leave this
> for after branching - Keir?

Yes, we'll leave it for post 4.2.0.



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

From xen-devel-bounces@lists.xen.org Thu Sep 06 15:52:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 2012 15:52:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9eMv-0003rR-Pz; Thu, 06 Sep 2012 15:51:49 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1T9eMu-0003rL-3C
	for xen-devel@lists.xen.org; Thu, 06 Sep 2012 15:51:48 +0000
Received: from [85.158.143.35:40906] by server-3.bemta-4.messagelabs.com id
	93/29-08232-396C8405; Thu, 06 Sep 2012 15:51:47 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1346946706!12583041!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-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13276 invoked from network); 6 Sep 2012 15:51:46 -0000
Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com)
	(74.125.83.45)
	by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Sep 2012 15:51:46 -0000
Received: by eeke53 with SMTP id e53so878582eek.32
	for <xen-devel@lists.xen.org>; Thu, 06 Sep 2012 08:51:46 -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=OpHBojDxaMrVdASY91jXZUs5CqshtE43OT9cu+pfxIA=;
	b=Dx4VshgUi2riE5oKi0IF9+41Oly4Xo/VcFF11UJ/x2Xae5fhEJWzBw7aNNZec1+Gf+
	++g8yUlO0sbtSyi1XT8KdjP//9u/cjlrVVcHLt2CHzniR5trS0x3tOzShVsVAT5y8JKX
	KdtetvtJWXa4A+hT9Rsy7rFdvDIyhnguaqD+7dGGGdffnohIZ3FUDcq2NVGGg2CGU2nL
	wPXp3l/vEvYZUNrmTWB0s/mYcNPV/SCgJxaPlcc/UhMV02R1i6979K8/UXBxrSKbdE1k
	J8QOdNWk/k5x/yJO+pqRSG6yJIBy5amcMXR4qxwTFDdLQ3dPLeoEnPqOYX7gLuYSJSeA
	dlnw==
Received: by 10.14.179.136 with SMTP id h8mr3774618eem.6.1346946706593;
	Thu, 06 Sep 2012 08:51:46 -0700 (PDT)
Received: from [192.168.1.69] (host86-184-74-117.range86-184.btcentralplus.com.
	[86.184.74.117])
	by mx.google.com with ESMTPS id r45sm7085593eem.6.2012.09.06.08.51.45
	(version=SSLv3 cipher=OTHER); Thu, 06 Sep 2012 08:51:45 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Thu, 06 Sep 2012 16:51:43 +0100
From: Keir Fraser <keir.xen@gmail.com>
To: Jan Beulich <JBeulich@suse.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <CC6E851F.3DE9F%keir.xen@gmail.com>
Thread-Topic: [PATCH] xen: clamp bitmaps to correct number of bits
Thread-Index: Ac2MR4LhUdhduhlwuUOz6Zgb4jarfA==
In-Reply-To: <5048D39D0200007800099684@nat28.tlf.novell.com>
Mime-version: 1.0
Cc: "Tim \(Xen.org\)" <tim@xen.org>, 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] [PATCH] xen: clamp bitmaps to correct number of bits
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/09/2012 15:47, "Jan Beulich" <JBeulich@suse.com> wrote:

>> I'll fold them in, it was convenient to have variables while I was
>> printk'ing what I was doing but not any more.
> 
> I won't ask you for another round because of this, but you
> still left the parameter and remaining local variable as plain
> int, nor did you insert whitespace into the expressions. If I
> were the one to commit this, I would do the adjustment while
> committing...
> 
> Anyway, as long as there's no easily visible tools side bug
> addressed by this, I would think we should rather leave this
> for after branching - Keir?

Yes, we'll leave it for post 4.2.0.



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

From xen-devel-bounces@lists.xen.org Thu Sep 06 16:02:37 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 2012 16: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 1T9eX1-0004Rq-UF; Thu, 06 Sep 2012 16:02:15 +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 1T9eX0-0004Rl-HP
	for xen-devel@lists.xensource.com; Thu, 06 Sep 2012 16:02:14 +0000
Received: from [85.158.143.99:49951] by server-3.bemta-4.messagelabs.com id
	A6/89-08232-509C8405; Thu, 06 Sep 2012 16:02:13 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-5.tower-216.messagelabs.com!1346947332!28609139!1
X-Originating-IP: [188.40.164.121]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9532 invoked from network); 6 Sep 2012 16:02:12 -0000
Received: from static.121.164.40.188.clients.your-server.de (HELO
	smtp.eikelenboom.it) (188.40.164.121)
	by server-5.tower-216.messagelabs.com with AES256-SHA encrypted SMTP;
	6 Sep 2012 16:02:12 -0000
Received: from 128-64-ftth.onsneteindhoven.nl ([88.159.64.128]:54265
	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 1T9eWy-0008UD-E1; Thu, 06 Sep 2012 18:02:12 +0200
Date: Thu, 6 Sep 2012 18:02:06 +0200
From: Sander Eikelenboom <linux@eikelenboom.it>
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <887956845.20120906180206@eikelenboom.it>
To: Sander Eikelenboom <linux@eikelenboom.it>
In-Reply-To: <c6d5f62c345b6b41b9ff.1346942187@xentest.example.org>
References: <c6d5f62c345b6b41b9ff.1346942187@xentest.example.org>
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com, Ian.Campbell@citrix.com
Subject: Re: [Xen-devel] [PATCH] xl: Introduce shutdown xm compatibility
	option -a to shutdown all 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


Thursday, September 6, 2012, 4:36:27 PM, you wrote:

> xl: Introduce shutdown xm compatibility option -a to shutdown all domains

> v2: address review comments.
>     - Change shutdown_domain to take domid instead of domname
>     - Docs: Make it more clear -a only shuts down GUEST domains

> Signed-off-by: Sander Eikelenboom <linux@eikelenboom.it>

> diff -r 9dc729b75595 -r c6d5f62c345b docs/man/xl.pod.1
> --- a/docs/man/xl.pod.1       Mon Sep 03 11:22:02 2012 +0100
> +++ b/docs/man/xl.pod.1       Thu Sep 06 16:35:04 2012 +0200
> @@ -527,7 +527,7 @@ List specifically for that domain. Other
>  
>  =back
>  
> -=item B<shutdown> [I<OPTIONS>] I<domain-id>
> +=item B<shutdown> [I<OPTIONS>] I<-a|domain-id>
>  
>  Gracefully shuts down a domain.  This coordinates with the domain OS
>  to perform graceful shutdown, so there is no guarantee that it will
> @@ -550,6 +550,10 @@ B<OPTIONS>
>  
>  =over 4
>  
> +=item B<-a>
> +
> +-a  Shutdown all guest domains.  Often used when doing a complete shutdown of a Xen system.
> +
>  =item B<-w>
>  
>  Wait for the domain to complete shutdown before returning.
> diff -r 9dc729b75595 -r c6d5f62c345b tools/libxl/xl_cmdimpl.c
> --- a/tools/libxl/xl_cmdimpl.c  Mon Sep 03 11:22:02 2012 +0100
> +++ b/tools/libxl/xl_cmdimpl.c  Thu Sep 06 16:35:04 2012 +0200
> @@ -2683,12 +2683,11 @@ static void destroy_domain(const char *p
>      if (rc) { fprintf(stderr,"destroy failed (rc=%d)\n",rc); exit(-1); }
>  }
>  
> -static void shutdown_domain(const char *p, int wait, int fallback_trigger)
> +static void shutdown_domain(uint32_t domid, int wait, int fallback_trigger)
>  {
>      int rc;
>      libxl_event *event;
>  
> -    find_domain(p);
>      rc=libxl_domain_shutdown(ctx, domid);
>      if (rc == ERROR_NOPARAVIRT) {
>          if (fallback_trigger) {

Hi Ian,

Done some more testing and this seems to lead to the following error when issueing both -a and -w:

xentest:/usr/src/xen-unstable.hg# xl shutdown -a -w
libxl: error: libxl_json.c:773:libxl__object_to_json: unable to convert libxl_event to JSON representation. YAJL error code 1: keys must be strings
INTERNAL PROBLEM - ignoring unexpected event for domain 11 (expected -1): event=(null)
libxl: error: libxl_json.c:773:libxl__object_to_json: unable to convert libxl_event to JSON representation. YAJL error code 1: keys must be strings
INTERNAL PROBLEM - ignoring unexpected event for domain 11 (expected -1): event=(null)

If i only use -w and specify a specific domain, it works without a problem.

Any ideas ?

--
Sander


> @@ -3670,14 +3669,19 @@ int main_destroy(int argc, char **argv)
>  
>  int main_shutdown(int argc, char **argv)
>  {
> -    int opt;
> +    libxl_dominfo *dominfo;
> +    int opt, i, nb_domain;
> +    int all = 0;
>      int wait = 0;
>      int fallback_trigger = 0;
>  
> -    while ((opt = def_getopt(argc, argv, "wF", "shutdown", 1)) != -1) {
> +    while ((opt = def_getopt(argc, argv, "awF", "shutdown", 0)) != -1) {
>          switch (opt) {
>          case 0: case 2:
>              return opt;
> +        case 'a':
> +            all = 1;
> +            break;
>          case 'w':
>              wait = 1;
>              break;
> @@ -3687,7 +3691,30 @@ int main_shutdown(int argc, char **argv)
>          }
>      }
>  
> -    shutdown_domain(argv[optind], wait, fallback_trigger);
> +    if (!argv[optind] && !all) {
> +        fprintf(stderr, "You must specify -a or a domain id.\n\n");
> +        return opt;
> +    }
> +
> +    if (all) {
> +        if (!(dominfo = libxl_list_domain(ctx, &nb_domain))) {
> +            fprintf(stderr, "libxl_list_domain failed.\n");
> +            return -1;
> +        }
> +
> +        for (i = 0; i<nb_domain; i++) {
> +            if (dominfo[i].domid == 0)
> +                continue;
> +
> +            shutdown_domain(dominfo[i].domid, wait, fallback_trigger);
> +        }
> +
> +        libxl_dominfo_list_free(dominfo, nb_domain);
> +    } else {
> +        find_domain(argv[optind]);
> +        shutdown_domain(domid, wait, fallback_trigger);
> +    }
> +
>      return 0;
>  }
>  
> diff -r 9dc729b75595 -r c6d5f62c345b tools/libxl/xl_cmdtable.c
> --- a/tools/libxl/xl_cmdtable.c       Mon Sep 03 11:22:02 2012 +0100
> +++ b/tools/libxl/xl_cmdtable.c       Thu Sep 06 16:35:04 2012 +0200
> @@ -60,7 +60,8 @@ struct cmd_spec cmd_table[] = {
>      { "shutdown",
>        &main_shutdown, 0, 1,
>        "Issue a shutdown signal to a domain",
> -      "[options] <Domain>",
> +      "[options] <-a|Domain>",
> +      "-a                      Shutdown all guest domains.\n"
>        "-h                      Print this help.\n"
>        "-F                      Fallback to ACPI power event for HVM guests with\n"
>        "                        no PV drivers.\n"




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

From xen-devel-bounces@lists.xen.org Thu Sep 06 16:02:37 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 2012 16: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 1T9eX1-0004Rq-UF; Thu, 06 Sep 2012 16:02:15 +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 1T9eX0-0004Rl-HP
	for xen-devel@lists.xensource.com; Thu, 06 Sep 2012 16:02:14 +0000
Received: from [85.158.143.99:49951] by server-3.bemta-4.messagelabs.com id
	A6/89-08232-509C8405; Thu, 06 Sep 2012 16:02:13 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-5.tower-216.messagelabs.com!1346947332!28609139!1
X-Originating-IP: [188.40.164.121]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9532 invoked from network); 6 Sep 2012 16:02:12 -0000
Received: from static.121.164.40.188.clients.your-server.de (HELO
	smtp.eikelenboom.it) (188.40.164.121)
	by server-5.tower-216.messagelabs.com with AES256-SHA encrypted SMTP;
	6 Sep 2012 16:02:12 -0000
Received: from 128-64-ftth.onsneteindhoven.nl ([88.159.64.128]:54265
	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 1T9eWy-0008UD-E1; Thu, 06 Sep 2012 18:02:12 +0200
Date: Thu, 6 Sep 2012 18:02:06 +0200
From: Sander Eikelenboom <linux@eikelenboom.it>
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <887956845.20120906180206@eikelenboom.it>
To: Sander Eikelenboom <linux@eikelenboom.it>
In-Reply-To: <c6d5f62c345b6b41b9ff.1346942187@xentest.example.org>
References: <c6d5f62c345b6b41b9ff.1346942187@xentest.example.org>
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com, Ian.Campbell@citrix.com
Subject: Re: [Xen-devel] [PATCH] xl: Introduce shutdown xm compatibility
	option -a to shutdown all 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


Thursday, September 6, 2012, 4:36:27 PM, you wrote:

> xl: Introduce shutdown xm compatibility option -a to shutdown all domains

> v2: address review comments.
>     - Change shutdown_domain to take domid instead of domname
>     - Docs: Make it more clear -a only shuts down GUEST domains

> Signed-off-by: Sander Eikelenboom <linux@eikelenboom.it>

> diff -r 9dc729b75595 -r c6d5f62c345b docs/man/xl.pod.1
> --- a/docs/man/xl.pod.1       Mon Sep 03 11:22:02 2012 +0100
> +++ b/docs/man/xl.pod.1       Thu Sep 06 16:35:04 2012 +0200
> @@ -527,7 +527,7 @@ List specifically for that domain. Other
>  
>  =back
>  
> -=item B<shutdown> [I<OPTIONS>] I<domain-id>
> +=item B<shutdown> [I<OPTIONS>] I<-a|domain-id>
>  
>  Gracefully shuts down a domain.  This coordinates with the domain OS
>  to perform graceful shutdown, so there is no guarantee that it will
> @@ -550,6 +550,10 @@ B<OPTIONS>
>  
>  =over 4
>  
> +=item B<-a>
> +
> +-a  Shutdown all guest domains.  Often used when doing a complete shutdown of a Xen system.
> +
>  =item B<-w>
>  
>  Wait for the domain to complete shutdown before returning.
> diff -r 9dc729b75595 -r c6d5f62c345b tools/libxl/xl_cmdimpl.c
> --- a/tools/libxl/xl_cmdimpl.c  Mon Sep 03 11:22:02 2012 +0100
> +++ b/tools/libxl/xl_cmdimpl.c  Thu Sep 06 16:35:04 2012 +0200
> @@ -2683,12 +2683,11 @@ static void destroy_domain(const char *p
>      if (rc) { fprintf(stderr,"destroy failed (rc=%d)\n",rc); exit(-1); }
>  }
>  
> -static void shutdown_domain(const char *p, int wait, int fallback_trigger)
> +static void shutdown_domain(uint32_t domid, int wait, int fallback_trigger)
>  {
>      int rc;
>      libxl_event *event;
>  
> -    find_domain(p);
>      rc=libxl_domain_shutdown(ctx, domid);
>      if (rc == ERROR_NOPARAVIRT) {
>          if (fallback_trigger) {

Hi Ian,

Done some more testing and this seems to lead to the following error when issueing both -a and -w:

xentest:/usr/src/xen-unstable.hg# xl shutdown -a -w
libxl: error: libxl_json.c:773:libxl__object_to_json: unable to convert libxl_event to JSON representation. YAJL error code 1: keys must be strings
INTERNAL PROBLEM - ignoring unexpected event for domain 11 (expected -1): event=(null)
libxl: error: libxl_json.c:773:libxl__object_to_json: unable to convert libxl_event to JSON representation. YAJL error code 1: keys must be strings
INTERNAL PROBLEM - ignoring unexpected event for domain 11 (expected -1): event=(null)

If i only use -w and specify a specific domain, it works without a problem.

Any ideas ?

--
Sander


> @@ -3670,14 +3669,19 @@ int main_destroy(int argc, char **argv)
>  
>  int main_shutdown(int argc, char **argv)
>  {
> -    int opt;
> +    libxl_dominfo *dominfo;
> +    int opt, i, nb_domain;
> +    int all = 0;
>      int wait = 0;
>      int fallback_trigger = 0;
>  
> -    while ((opt = def_getopt(argc, argv, "wF", "shutdown", 1)) != -1) {
> +    while ((opt = def_getopt(argc, argv, "awF", "shutdown", 0)) != -1) {
>          switch (opt) {
>          case 0: case 2:
>              return opt;
> +        case 'a':
> +            all = 1;
> +            break;
>          case 'w':
>              wait = 1;
>              break;
> @@ -3687,7 +3691,30 @@ int main_shutdown(int argc, char **argv)
>          }
>      }
>  
> -    shutdown_domain(argv[optind], wait, fallback_trigger);
> +    if (!argv[optind] && !all) {
> +        fprintf(stderr, "You must specify -a or a domain id.\n\n");
> +        return opt;
> +    }
> +
> +    if (all) {
> +        if (!(dominfo = libxl_list_domain(ctx, &nb_domain))) {
> +            fprintf(stderr, "libxl_list_domain failed.\n");
> +            return -1;
> +        }
> +
> +        for (i = 0; i<nb_domain; i++) {
> +            if (dominfo[i].domid == 0)
> +                continue;
> +
> +            shutdown_domain(dominfo[i].domid, wait, fallback_trigger);
> +        }
> +
> +        libxl_dominfo_list_free(dominfo, nb_domain);
> +    } else {
> +        find_domain(argv[optind]);
> +        shutdown_domain(domid, wait, fallback_trigger);
> +    }
> +
>      return 0;
>  }
>  
> diff -r 9dc729b75595 -r c6d5f62c345b tools/libxl/xl_cmdtable.c
> --- a/tools/libxl/xl_cmdtable.c       Mon Sep 03 11:22:02 2012 +0100
> +++ b/tools/libxl/xl_cmdtable.c       Thu Sep 06 16:35:04 2012 +0200
> @@ -60,7 +60,8 @@ struct cmd_spec cmd_table[] = {
>      { "shutdown",
>        &main_shutdown, 0, 1,
>        "Issue a shutdown signal to a domain",
> -      "[options] <Domain>",
> +      "[options] <-a|Domain>",
> +      "-a                      Shutdown all guest domains.\n"
>        "-h                      Print this help.\n"
>        "-F                      Fallback to ACPI power event for HVM guests with\n"
>        "                        no PV drivers.\n"




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

From xen-devel-bounces@lists.xen.org Thu Sep 06 16:14:31 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 2012 16:14:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9eiY-0004x8-CE; Thu, 06 Sep 2012 16:14:10 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <iwj@xenbits.xen.org>) id 1T9ei1-0004vi-0v
	for xen-devel@lists.xen.org; Thu, 06 Sep 2012 16:13:37 +0000
Received: from [85.158.138.51:23579] by server-3.bemta-3.messagelabs.com id
	D8/7D-21322-FABC8405; Thu, 06 Sep 2012 16:13:35 +0000
X-Env-Sender: iwj@xenbits.xen.org
X-Msg-Ref: server-2.tower-174.messagelabs.com!1346948013!29115213!1
X-Originating-IP: [50.57.168.107]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 443 invoked from network); 6 Sep 2012 16:13:34 -0000
Received: from mail.xen.org (HELO mail.xen.org) (50.57.168.107)
	by server-2.tower-174.messagelabs.com with AES256-SHA encrypted SMTP;
	6 Sep 2012 16:13:34 -0000
Received: from xenbits.xen.org ([50.57.170.242])
	by mail.xen.org with esmtp (Exim 4.72)
	(envelope-from <iwj@xenbits.xen.org>)
	id 1T9ehq-0006FF-9D; Thu, 06 Sep 2012 16:13:26 +0000
Received: from iwj by xenbits.xen.org with local (Exim 4.72)
	(envelope-from <iwj@xenbits.xen.org>)
	id 1T9ehq-0006nu-7Q; Thu, 06 Sep 2012 16:13:26 +0000
Date: Thu, 06 Sep 2012 16:13:26 +0000
Message-Id: <E1T9ehq-0006nu-7Q@xenbits.xen.org>
Content-Type: multipart/mixed; boundary="=separator"; charset="utf-8"
Content-Transfer-Encoding: binary
MIME-Version: 1.0
X-Mailer: MIME-tools 5.428 (Entity 5.428)
To: xen-announce@lists.xen.org, xen-devel@lists.xen.org,
	xen-users@lists.xen.org, oss-security@lists.openwall.com
From: Xen.org security team <security@xen.org>
X-Mailman-Approved-At: Thu, 06 Sep 2012 16:14:09 +0000
Cc: "Xen.org security team" <security@xen.org>
Subject: [Xen-devel] Xen Security Advisory 19 - guest administrator can
 access qemu monitor console
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--=separator
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

                 Xen Security Advisory XSA-19

         guest administrator can access qemu monitor console


ISSUE DESCRIPTION
=================

A guest administrator who is granted access to the graphical console
of a Xen guest can access the qemu monitor.  The monitor can be used
to access host resources.

IMPACT
======

A malicious guest administrator can access host resources (perhaps
belonging to other guests or the underlying system) and may be able to
escalate their privilege to that of the host.

VULNERABLE SYSTEMS
==================

Installations where guest administrators do not have access to a
domain's graphical console, or containing only PV domains configured
without a graphical console, are not vulnerable.

Installations where all guest administrators are trustworthy are not
vulnerable, even if the guest operating systems themselves are
untrusted.

Systems using xend/xm: At least all versions since Xen 4.0 are
affected.  Systems are vulnerable even if "monitor=no" is specified in
the xm domain configuration file - this configuration option is not
properly honoured in the vulnerable versions.

Systems using libxl/xl: All versions are affected.  The "monitor="
option is not understood, and is therefore ignored, by xl.  However,
systems using the experimental device model version based on upstream
qemu are NOT vulnerable; that is, Xen 4.2 RC systems with
device_model_version="qemu_xen" specified in the xl domain config
file.

Systems using libvirt are vulnerable.  For "xen:" URIs, see xend/xm,
above.  For "libxl:" URIs, all versions are affected.

Systems based on the Xen Cloud Platform are NOT vulnerable.

CONFIRMING VULNERABILITY
========================

Connect to the guest's VNC (or SDL) graphical display and make sure
your focus is in that window.  Hold down CTRL and ALT and press 2.
You will see a black screen showing one of "serial0", "parallel0" or
"QEMU <version> monitor".  Repeat this exercise for other digits 3 to
6.  CTRL+ALT+1 is the domain's normal graphical console.  Not all
numbers will have screens attached, but note that you must release and
re-press CTRL and ALT each time.

If one of the accessible screens shows "QEMU <version> monitor" then
you are vulnerable.  Otherwise you are not.

MITIGATION
==========

With xl in Xen 4.1 and later, supplying the following config
option in the VM configuration file will disable the monitor:
   device_model_args=["-monitor","null"]

With xend the following config option will disable the monitor:
   monitor_path="null"
Note that with a vulnerable version of the software specifying
"monitor=0" will NOT disable the monitor.

We are not currently aware of the availability of mitigation for
systems using libvirt.

NOTE REGARDING EMBARGO
======================

This issue was publicly discussed online by its discoverer.
There is therefore no embargo.

NOTE REGARDING CVE
==================

This issue was previously reported in a different context, not to Xen
upstream, and assigned CVE-2007-0998 and fixed in a different way.  We
have requested a new CVE for XSA-19 but it is not yet available.

RESOLUTION
==========

The attached patch against qemu-xen-traditional
(qemu-xen-4.*-testing.git) resolves this issue.

$ sha256sum xsa19-qemu-all.patch
19fc5ff9334e7e7ad429388850dc6e52e7062c21a677082e7a89c2f2c91365fa  xsa19-qemu-all.patch
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iQEcBAEBAgAGBQJQSMr3AAoJEIP+FMlX6CvZ2O8H/2cZuOEMQd6ELDSmgj2fVaYl
qpev3Ux50+wHsBf2JS4XMW+f6wwNWa8IBP1GL+SUvOLVr0PGYb8cbISy+zp6z+ku
mAF1T19iaAMNc/feSYwgtLfYE9H25SbB4cuPg6YkyLf6dQn0KnEyf9GIJxHy0xir
nU5XKEwhhJHw17cXZyagTBheXqrIRtIhgMNv3oQKg60NDc+2sMYwMmv7lgPVIvTZ
5+rkY7RX34hBCw08qt/CEyI9OXKHL1jDjPM8QtCKuwDzaWI10yQxtLjWJCYEhGkH
QqMHU6D8Q3DptCSZj/9urs7+oWGwb3TKR7rUc5v7NbiHlliEX5njDKrhxZpxvJg=
=21pO
-----END PGP SIGNATURE-----

--=separator
Content-Type: application/octet-stream; name="xsa19-qemu-all.patch"
Content-Disposition: attachment; filename="xsa19-qemu-all.patch"
Content-Transfer-Encoding: base64

RnJvbTogSWFuIEphY2tzb24gPGlhbi5qYWNrc29uQGV1LmNpdHJpeC5jb20+
CgpEaXNhYmxlIHFlbXUgbW9uaXRvciBieSBkZWZhdWx0LiAgVGhlIHFlbXUg
bW9uaXRvciBpcyBhbiBvdmVybHkKcG93ZXJmdWwgZmVhdHVyZSB3aGljaCBt
dXN0IGJlIHByb3RlY3RlZCBmcm9tIHVudHJ1c3RlZCAoZ3Vlc3QpCmFkbWlu
aXN0cmF0b3JzLgoKTmVpdGhlciB4bCBub3IgeGVuZCBleHBlY3QgcWVtdSB0
byBwcm9kdWNlIHRoaXMgbW9uaXRvciB1bmxlc3MgaXQgaXMKZXhwbGljaXRs
eSByZXF1ZXN0ZWQuCgpUaGlzIGlzIGEgc2VjdXJpdHkgcHJvYmxlbSwgWFNB
LTE5LiAgUHJldmlvdXNseSBpdCB3YXMgQ1ZFLTIwMDctMDk5OAppbiBSZWQg
SGF0IGJ1dCB3ZSBoYXZlbid0IGRlYWx0IHdpdGggaXQgaW4gdXBzdHJlYW0u
ICBXZSBob3BlIHRvIGhhdmUKYSBuZXcgQ1ZFIGZvciBpdCBoZXJlIGJ1dCB3
ZSBkb24ndCBoYXZlIG9uZSB5ZXQuCgpTaWduZWQtb2ZmLWJ5OiBJYW4gSmFj
a3NvbiA8aWFuLmphY2tzb25AZXUuY2l0cml4LmNvbT4KCmRpZmYgLS1naXQg
YS92bC5jIGIvdmwuYwppbmRleCBkMzBjYjJjLi5kMjFjM2FhIDEwMDY0NAot
LS0gYS92bC5jCisrKyBiL3ZsLmMKQEAgLTQ5MjAsNyArNDkyMCw3IEBAIGlu
dCBtYWluKGludCBhcmdjLCBjaGFyICoqYXJndiwgY2hhciAqKmVudnApCiAg
ICAga2VybmVsX2NtZGxpbmUgPSAiIjsKICAgICBjeWxzID0gaGVhZHMgPSBz
ZWNzID0gMDsKICAgICB0cmFuc2xhdGlvbiA9IEJJT1NfQVRBX1RSQU5TTEFU
SU9OX0FVVE87Ci0gICAgbW9uaXRvcl9kZXZpY2UgPSAidmM6ODBDeDI0QyI7
CisgICAgbW9uaXRvcl9kZXZpY2UgPSAibnVsbCI7CiAKICAgICBzZXJpYWxf
ZGV2aWNlc1swXSA9ICJ2Yzo4MEN4MjRDIjsKICAgICBmb3IoaSA9IDE7IGkg
PCBNQVhfU0VSSUFMX1BPUlRTOyBpKyspCg==

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

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

--=separator--


From xen-devel-bounces@lists.xen.org Thu Sep 06 16:14:31 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 2012 16:14:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9eiY-0004x8-CE; Thu, 06 Sep 2012 16:14:10 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <iwj@xenbits.xen.org>) id 1T9ei1-0004vi-0v
	for xen-devel@lists.xen.org; Thu, 06 Sep 2012 16:13:37 +0000
Received: from [85.158.138.51:23579] by server-3.bemta-3.messagelabs.com id
	D8/7D-21322-FABC8405; Thu, 06 Sep 2012 16:13:35 +0000
X-Env-Sender: iwj@xenbits.xen.org
X-Msg-Ref: server-2.tower-174.messagelabs.com!1346948013!29115213!1
X-Originating-IP: [50.57.168.107]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 443 invoked from network); 6 Sep 2012 16:13:34 -0000
Received: from mail.xen.org (HELO mail.xen.org) (50.57.168.107)
	by server-2.tower-174.messagelabs.com with AES256-SHA encrypted SMTP;
	6 Sep 2012 16:13:34 -0000
Received: from xenbits.xen.org ([50.57.170.242])
	by mail.xen.org with esmtp (Exim 4.72)
	(envelope-from <iwj@xenbits.xen.org>)
	id 1T9ehq-0006FF-9D; Thu, 06 Sep 2012 16:13:26 +0000
Received: from iwj by xenbits.xen.org with local (Exim 4.72)
	(envelope-from <iwj@xenbits.xen.org>)
	id 1T9ehq-0006nu-7Q; Thu, 06 Sep 2012 16:13:26 +0000
Date: Thu, 06 Sep 2012 16:13:26 +0000
Message-Id: <E1T9ehq-0006nu-7Q@xenbits.xen.org>
Content-Type: multipart/mixed; boundary="=separator"; charset="utf-8"
Content-Transfer-Encoding: binary
MIME-Version: 1.0
X-Mailer: MIME-tools 5.428 (Entity 5.428)
To: xen-announce@lists.xen.org, xen-devel@lists.xen.org,
	xen-users@lists.xen.org, oss-security@lists.openwall.com
From: Xen.org security team <security@xen.org>
X-Mailman-Approved-At: Thu, 06 Sep 2012 16:14:09 +0000
Cc: "Xen.org security team" <security@xen.org>
Subject: [Xen-devel] Xen Security Advisory 19 - guest administrator can
 access qemu monitor console
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--=separator
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

                 Xen Security Advisory XSA-19

         guest administrator can access qemu monitor console


ISSUE DESCRIPTION
=================

A guest administrator who is granted access to the graphical console
of a Xen guest can access the qemu monitor.  The monitor can be used
to access host resources.

IMPACT
======

A malicious guest administrator can access host resources (perhaps
belonging to other guests or the underlying system) and may be able to
escalate their privilege to that of the host.

VULNERABLE SYSTEMS
==================

Installations where guest administrators do not have access to a
domain's graphical console, or containing only PV domains configured
without a graphical console, are not vulnerable.

Installations where all guest administrators are trustworthy are not
vulnerable, even if the guest operating systems themselves are
untrusted.

Systems using xend/xm: At least all versions since Xen 4.0 are
affected.  Systems are vulnerable even if "monitor=no" is specified in
the xm domain configuration file - this configuration option is not
properly honoured in the vulnerable versions.

Systems using libxl/xl: All versions are affected.  The "monitor="
option is not understood, and is therefore ignored, by xl.  However,
systems using the experimental device model version based on upstream
qemu are NOT vulnerable; that is, Xen 4.2 RC systems with
device_model_version="qemu_xen" specified in the xl domain config
file.

Systems using libvirt are vulnerable.  For "xen:" URIs, see xend/xm,
above.  For "libxl:" URIs, all versions are affected.

Systems based on the Xen Cloud Platform are NOT vulnerable.

CONFIRMING VULNERABILITY
========================

Connect to the guest's VNC (or SDL) graphical display and make sure
your focus is in that window.  Hold down CTRL and ALT and press 2.
You will see a black screen showing one of "serial0", "parallel0" or
"QEMU <version> monitor".  Repeat this exercise for other digits 3 to
6.  CTRL+ALT+1 is the domain's normal graphical console.  Not all
numbers will have screens attached, but note that you must release and
re-press CTRL and ALT each time.

If one of the accessible screens shows "QEMU <version> monitor" then
you are vulnerable.  Otherwise you are not.

MITIGATION
==========

With xl in Xen 4.1 and later, supplying the following config
option in the VM configuration file will disable the monitor:
   device_model_args=["-monitor","null"]

With xend the following config option will disable the monitor:
   monitor_path="null"
Note that with a vulnerable version of the software specifying
"monitor=0" will NOT disable the monitor.

We are not currently aware of the availability of mitigation for
systems using libvirt.

NOTE REGARDING EMBARGO
======================

This issue was publicly discussed online by its discoverer.
There is therefore no embargo.

NOTE REGARDING CVE
==================

This issue was previously reported in a different context, not to Xen
upstream, and assigned CVE-2007-0998 and fixed in a different way.  We
have requested a new CVE for XSA-19 but it is not yet available.

RESOLUTION
==========

The attached patch against qemu-xen-traditional
(qemu-xen-4.*-testing.git) resolves this issue.

$ sha256sum xsa19-qemu-all.patch
19fc5ff9334e7e7ad429388850dc6e52e7062c21a677082e7a89c2f2c91365fa  xsa19-qemu-all.patch
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iQEcBAEBAgAGBQJQSMr3AAoJEIP+FMlX6CvZ2O8H/2cZuOEMQd6ELDSmgj2fVaYl
qpev3Ux50+wHsBf2JS4XMW+f6wwNWa8IBP1GL+SUvOLVr0PGYb8cbISy+zp6z+ku
mAF1T19iaAMNc/feSYwgtLfYE9H25SbB4cuPg6YkyLf6dQn0KnEyf9GIJxHy0xir
nU5XKEwhhJHw17cXZyagTBheXqrIRtIhgMNv3oQKg60NDc+2sMYwMmv7lgPVIvTZ
5+rkY7RX34hBCw08qt/CEyI9OXKHL1jDjPM8QtCKuwDzaWI10yQxtLjWJCYEhGkH
QqMHU6D8Q3DptCSZj/9urs7+oWGwb3TKR7rUc5v7NbiHlliEX5njDKrhxZpxvJg=
=21pO
-----END PGP SIGNATURE-----

--=separator
Content-Type: application/octet-stream; name="xsa19-qemu-all.patch"
Content-Disposition: attachment; filename="xsa19-qemu-all.patch"
Content-Transfer-Encoding: base64

RnJvbTogSWFuIEphY2tzb24gPGlhbi5qYWNrc29uQGV1LmNpdHJpeC5jb20+
CgpEaXNhYmxlIHFlbXUgbW9uaXRvciBieSBkZWZhdWx0LiAgVGhlIHFlbXUg
bW9uaXRvciBpcyBhbiBvdmVybHkKcG93ZXJmdWwgZmVhdHVyZSB3aGljaCBt
dXN0IGJlIHByb3RlY3RlZCBmcm9tIHVudHJ1c3RlZCAoZ3Vlc3QpCmFkbWlu
aXN0cmF0b3JzLgoKTmVpdGhlciB4bCBub3IgeGVuZCBleHBlY3QgcWVtdSB0
byBwcm9kdWNlIHRoaXMgbW9uaXRvciB1bmxlc3MgaXQgaXMKZXhwbGljaXRs
eSByZXF1ZXN0ZWQuCgpUaGlzIGlzIGEgc2VjdXJpdHkgcHJvYmxlbSwgWFNB
LTE5LiAgUHJldmlvdXNseSBpdCB3YXMgQ1ZFLTIwMDctMDk5OAppbiBSZWQg
SGF0IGJ1dCB3ZSBoYXZlbid0IGRlYWx0IHdpdGggaXQgaW4gdXBzdHJlYW0u
ICBXZSBob3BlIHRvIGhhdmUKYSBuZXcgQ1ZFIGZvciBpdCBoZXJlIGJ1dCB3
ZSBkb24ndCBoYXZlIG9uZSB5ZXQuCgpTaWduZWQtb2ZmLWJ5OiBJYW4gSmFj
a3NvbiA8aWFuLmphY2tzb25AZXUuY2l0cml4LmNvbT4KCmRpZmYgLS1naXQg
YS92bC5jIGIvdmwuYwppbmRleCBkMzBjYjJjLi5kMjFjM2FhIDEwMDY0NAot
LS0gYS92bC5jCisrKyBiL3ZsLmMKQEAgLTQ5MjAsNyArNDkyMCw3IEBAIGlu
dCBtYWluKGludCBhcmdjLCBjaGFyICoqYXJndiwgY2hhciAqKmVudnApCiAg
ICAga2VybmVsX2NtZGxpbmUgPSAiIjsKICAgICBjeWxzID0gaGVhZHMgPSBz
ZWNzID0gMDsKICAgICB0cmFuc2xhdGlvbiA9IEJJT1NfQVRBX1RSQU5TTEFU
SU9OX0FVVE87Ci0gICAgbW9uaXRvcl9kZXZpY2UgPSAidmM6ODBDeDI0QyI7
CisgICAgbW9uaXRvcl9kZXZpY2UgPSAibnVsbCI7CiAKICAgICBzZXJpYWxf
ZGV2aWNlc1swXSA9ICJ2Yzo4MEN4MjRDIjsKICAgICBmb3IoaSA9IDE7IGkg
PCBNQVhfU0VSSUFMX1BPUlRTOyBpKyspCg==

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

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

--=separator--


From xen-devel-bounces@lists.xen.org Thu Sep 06 16:20:54 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 2012 16:20:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9eol-0005fC-1s; Thu, 06 Sep 2012 16:20: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 1T9eoj-0005ez-Ji
	for xen-devel@lists.xen.org; Thu, 06 Sep 2012 16:20:33 +0000
Received: from [85.158.143.99:42612] by server-2.bemta-4.messagelabs.com id
	4E/42-21239-05DC8405; Thu, 06 Sep 2012 16:20:32 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1346948429!19187451!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTE5NzY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14218 invoked from network); 6 Sep 2012 16:20:32 -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 Sep 2012 16:20:32 -0000
X-IronPort-AV: E=Sophos;i="4.80,380,1344211200"; d="scan'208";a="14391636"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Sep 2012 16:20:28 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Thu, 6 Sep 2012
	17:20:28 +0100
Message-ID: <1346948428.10570.33.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Thu, 6 Sep 2012 17:20:28 +0100
In-Reply-To: <5048D39D0200007800099684@nat28.tlf.novell.com>
References: <22d5e100131d1576d455.1346932605@cosworth.uk.xensource.com>
	<5048B1C4020000780009952E@nat28.tlf.novell.com>
	<1346939323.30018.12.camel@zakaz.uk.xensource.com>
	<5048D39D0200007800099684@nat28.tlf.novell.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "Tim \(Xen.org\)" <tim@xen.org>, 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] [PATCH] xen: clamp bitmaps to correct number of bits
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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-09-06 at 15:47 +0100, Jan Beulich wrote:
> >>> On 06.09.12 at 15:48, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> > On Thu, 2012-09-06 at 13:23 +0100, Jan Beulich wrote:
> >> >>> On 06.09.12 at 13:56, Ian Campbell <ian.campbell@citrix.com> wrote:
> >> > +/* Ensure that the last byte is zero from nbits onwards. */
> >> > +static void clamp_last_byte(uint8_t *bp, int nbits)
> >> > +{
> >> > +	int lastbyte = nbits/8;
> >> > +	int remainder = nbits % 8;
> >> > +	int mask = ((1U<<remainder)-1)&0xff;
> >> 
> >> While I realize the callers use plain int, I'd be very much in favor
> >> of not continuing this bad practice (the more that you use 1U
> >> already) - simply make the parameter and all locals (assuming
> >> you really think they're useful; I would have omitted all but
> >> "remainder", given they're being used just once) unsigned.
> > 
> > I'll fold them in, it was convenient to have variables while I was
> > printk'ing what I was doing but not any more.
> 
> I won't ask you for another round because of this, but you
> still left the parameter and remaining local variable as plain
> int,

Sorry, I forgot this bit after I nuked the variables. I've respun
(below)

>  nor did you insert whitespace into the expressions. If I
> were the one to commit this, I would do the adjustment while
> committing...

This whole file seems to use Linux coding style which is why I omitted
spaces inside the if. I made the mask "(1U << remainder) - 1" and
simultaneously drop the superfluous extra brackets in v2 left over from
removing &0xff. 

> 
> Anyway, as long as there's no easily visible tools side bug
> addressed by this, I would think we should rather leave this
> for after branching - Keir?

I'm fine with that.

Ian

8<-----------------------------------------------

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1346947834 -3600
# Node ID adf93d46186bb9b4d39aa195cf3b2445499c87a1
# Parent  6458749bcd38365bc30ae8adac608619e6eec382
xen: clamp bitmaps to correct number of bits

Valgrind running xl create reports:
 ==24777== Invalid read of size 4
 ==24777==    at 0x4072805: libxl__get_numa_candidate (libxl_numa.c:203)
 ==24777==    by 0x40680B6: libxl__build_pre (libxl_dom.c:166)
 ==24777==    by 0x405B82E: libxl__domain_build (libxl_create.c:323)
 ==24777==    by 0x405BB9C: domcreate_bootloader_done (libxl_create.c:747)
 ==24777==    by 0x407AD27: bootloader_local_detached_cb (libxl_bootloader.c:281)
 ==24777==    by 0x40508D8: local_device_detach_cb (libxl.c:2470)
 ==24777==    by 0x4052B10: libxl__device_disk_local_initiate_detach (libxl.c:2445)
 ==24777==    by 0x407AE9F: bootloader_callback (libxl_bootloader.c:265)
 ==24777==    by 0x407C69A: libxl__bootloader_run (libxl_bootloader.c:392)
 ==24777==    by 0x405CB24: do_domain_create (libxl_create.c:687)
 ==24777==    by 0x405CC5E: libxl_domain_create_new (libxl_create.c:1177)
 ==24777==    by 0x805BDE2: create_domain (xl_cmdimpl.c:1812)
 ==24777==  Address 0x42dbdd8 is 8 bytes after a block of size 48 alloc'd
 ==24777==    at 0x4023340: calloc (vg_replace_malloc.c:593)
 ==24777==    by 0x406D479: libxl__zalloc (libxl_internal.c:88)
 ==24777==    by 0x404EF38: libxl_get_cpu_topology (libxl.c:3707)
 ==24777==    by 0x4072232: libxl__get_numa_candidate (libxl_numa.c:314)
 ==24777==    by 0x40680B6: libxl__build_pre (libxl_dom.c:166)
 ==24777==    by 0x405B82E: libxl__domain_build (libxl_create.c:323)
 ==24777==    by 0x405BB9C: domcreate_bootloader_done (libxl_create.c:747)
 ==24777==    by 0x407AD27: bootloader_local_detached_cb (libxl_bootloader.c:281)
 ==24777==    by 0x40508D8: local_device_detach_cb (libxl.c:2470)
 ==24777==    by 0x4052B10: libxl__device_disk_local_initiate_detach (libxl.c:2445)
 ==24777==    by 0x407AE9F: bootloader_callback (libxl_bootloader.c:265)
 ==24777==    by 0x407C69A: libxl__bootloader_run (libxl_bootloader.c:392)

This is because with nr_cpus=4 the bitmask returned from Xen
contains 0xff rather than 0x0f bit our bitmap walking routines (e.g.
libxl_for_each_set_bit) round up to the next byte (so it iterates
e.g. 8 times not 4). This then causes us to access of the end of
whatever array we are walking through each set bit for.

The principal of least surprise suggests that these bits ought not to
be set and this is not a hot path so fix this at the hypervisor layer
by clamping the bits in the returned bitmap to the correct limit.

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

The impact of this seems to be fairly benign in practice, so I'm not
sure about it for 4.2.0. Could leave to 4.2.1?

Dario,

Any chance you could look at the libxl bitmap functions in 4.3 and
make them use the right limit (i.e. nr_bits not (nr_bits+7)/8?

Thanks,
Ian.

diff -r 6458749bcd38 -r adf93d46186b xen/common/bitmap.c
--- a/xen/common/bitmap.c	Thu Sep 06 17:04:25 2012 +0100
+++ b/xen/common/bitmap.c	Thu Sep 06 17:10:34 2012 +0100
@@ -38,6 +38,21 @@
  * for the best explanations of this ordering.
  */
 
+/*
+ * If a bitmap has a number of bits which is not a multiple of 8 then
+ * the last few bits of the last byte of the bitmap can be
+ * unexpectedly set which can confuse consumers (e.g. in the tools)
+ * who also round up their loops to 8 bits. Ensure we clear those left
+ * over bits so as to prevent surprises.
+ */
+static void clamp_last_byte(uint8_t *bp, unsigned int nbits)
+{
+	unsigned int remainder = nbits % 8;
+
+	if (remainder)
+		bp[nbits/8] &= (1U << remainder) - 1;
+}
+
 int __bitmap_empty(const unsigned long *bitmap, int bits)
 {
 	int k, lim = bits/BITS_PER_LONG;
@@ -485,6 +500,7 @@ void bitmap_long_to_byte(uint8_t *bp, co
 			nbits -= 8;
 		}
 	}
+	clamp_last_byte(bp, nbits);
 }
 
 void bitmap_byte_to_long(unsigned long *lp, const uint8_t *bp, int nbits)
@@ -507,6 +523,7 @@ void bitmap_byte_to_long(unsigned long *
 void bitmap_long_to_byte(uint8_t *bp, const unsigned long *lp, int nbits)
 {
 	memcpy(bp, lp, (nbits+7)/8);
+	clamp_last_byte(bp, nbits);
 }
 
 void bitmap_byte_to_long(unsigned long *lp, const uint8_t *bp, int nbits)




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

From xen-devel-bounces@lists.xen.org Thu Sep 06 16:20:54 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 2012 16:20:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9eop-0005g4-HZ; Thu, 06 Sep 2012 16:20:39 +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 1T9eoo-0005fh-68
	for xen-devel@lists.xen.org; Thu, 06 Sep 2012 16:20:38 +0000
Received: from [85.158.139.83:7689] by server-6.bemta-5.messagelabs.com id
	F0/40-21336-55DC8405; Thu, 06 Sep 2012 16:20:37 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1346948429!28324278!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDc0MTc4NQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23013 invoked from network); 6 Sep 2012 16:20:31 -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 Sep 2012 16:20:31 -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 q86GKRlA023067
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 6 Sep 2012 16:20:27 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
	q86GKQZN023460
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 6 Sep 2012 16:20:27 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
	q86GKQkf026582; Thu, 6 Sep 2012 11:20:26 -0500
Received: from localhost.localdomain (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 06 Sep 2012 09:20:26 -0700
Date: Thu, 6 Sep 2012 12:20:20 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Andres Lagar-Cavilla <andreslc@gridcentric.ca>
Message-ID: <20120906162020.GA13327@localhost.localdomain>
References: <1346331492-15027-1-git-send-email-david.vrabel@citrix.com>
	<1346331492-15027-3-git-send-email-david.vrabel@citrix.com>
	<C989BE9D-E520-4D04-9028-6CE6CC765E76@gridcentric.ca>
	<20120905162148.GC11949@phenom.dumpdata.com>
	<939BE993-572C-4D83-8F04-E6B9D6EE3E92@gridcentric.ca>
	<20120905174046.GA25535@phenom.dumpdata.com>
	<39CBBAD7-E10F-457F-BFE3-717A50D059FB@gridcentric.ca>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <39CBBAD7-E10F-457F-BFE3-717A50D059FB@gridcentric.ca>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: David Vrabel <david.vrabel@citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 2/2] xen/privcmd: add PRIVCMD_MMAPBATCH_V2
	ioctl
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Sep 06, 2012 at 09:41:44AM -0400, Andres Lagar-Cavilla wrote:
> On Sep 5, 2012, at 1:40 PM, Konrad Rzeszutek Wilk wrote:
> 
> > On Wed, Sep 05, 2012 at 01:09:32PM -0400, Andres Lagar-Cavilla wrote:
> >> Super. To which branch are you applying these now? (n00b question but have to ask)
> > 
> > They will show up on stable/for-linus-3.7 once the overnight tests pass.
> 
> I would be very surprised if this passed your nighties. This is because the following hunk is necessary:

It did :-) I guess the Xen 4.1 isn't using this that much.
> 
> diff --git a/drivers/xen/privcmd.c b/drivers/xen/privcmd.c
> index 5386f20..e4dfa3b 100644
> --- a/drivers/xen/privcmd.c
> +++ b/drivers/xen/privcmd.c
> @@ -389,7 +389,7 @@ static long privcmd_ioctl_mmap_batch(void __user *udata, int version)
>                 state.err      = err_array;
>                 ret = traverse_pages(m.num, sizeof(xen_pfn_t),
>                                          &pagelist, mmap_return_errors_v1, &state);
> -       } else
> +       } else if (version == 2)
>                 ret = __copy_to_user(m.err, err_array, m.num * sizeof(int));
>  
>      /* If we have not had any EFAULT-like global errors then set the global
> 
> I can either resubmit the original patch with this squashed in, or send this stand-alone. Nightlies may have passed if your libxc never exercises v1 in favor of v2. But this is broken for v1 as it will unconditionally attempt a copy to user on a NULL target and this set rc to EFAULT.
> 

Send it stand alone pls.

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

From xen-devel-bounces@lists.xen.org Thu Sep 06 16:20:54 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 2012 16:20:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9eol-0005fC-1s; Thu, 06 Sep 2012 16:20: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 1T9eoj-0005ez-Ji
	for xen-devel@lists.xen.org; Thu, 06 Sep 2012 16:20:33 +0000
Received: from [85.158.143.99:42612] by server-2.bemta-4.messagelabs.com id
	4E/42-21239-05DC8405; Thu, 06 Sep 2012 16:20:32 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1346948429!19187451!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTE5NzY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14218 invoked from network); 6 Sep 2012 16:20:32 -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 Sep 2012 16:20:32 -0000
X-IronPort-AV: E=Sophos;i="4.80,380,1344211200"; d="scan'208";a="14391636"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Sep 2012 16:20:28 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Thu, 6 Sep 2012
	17:20:28 +0100
Message-ID: <1346948428.10570.33.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Thu, 6 Sep 2012 17:20:28 +0100
In-Reply-To: <5048D39D0200007800099684@nat28.tlf.novell.com>
References: <22d5e100131d1576d455.1346932605@cosworth.uk.xensource.com>
	<5048B1C4020000780009952E@nat28.tlf.novell.com>
	<1346939323.30018.12.camel@zakaz.uk.xensource.com>
	<5048D39D0200007800099684@nat28.tlf.novell.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "Tim \(Xen.org\)" <tim@xen.org>, 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] [PATCH] xen: clamp bitmaps to correct number of bits
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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-09-06 at 15:47 +0100, Jan Beulich wrote:
> >>> On 06.09.12 at 15:48, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> > On Thu, 2012-09-06 at 13:23 +0100, Jan Beulich wrote:
> >> >>> On 06.09.12 at 13:56, Ian Campbell <ian.campbell@citrix.com> wrote:
> >> > +/* Ensure that the last byte is zero from nbits onwards. */
> >> > +static void clamp_last_byte(uint8_t *bp, int nbits)
> >> > +{
> >> > +	int lastbyte = nbits/8;
> >> > +	int remainder = nbits % 8;
> >> > +	int mask = ((1U<<remainder)-1)&0xff;
> >> 
> >> While I realize the callers use plain int, I'd be very much in favor
> >> of not continuing this bad practice (the more that you use 1U
> >> already) - simply make the parameter and all locals (assuming
> >> you really think they're useful; I would have omitted all but
> >> "remainder", given they're being used just once) unsigned.
> > 
> > I'll fold them in, it was convenient to have variables while I was
> > printk'ing what I was doing but not any more.
> 
> I won't ask you for another round because of this, but you
> still left the parameter and remaining local variable as plain
> int,

Sorry, I forgot this bit after I nuked the variables. I've respun
(below)

>  nor did you insert whitespace into the expressions. If I
> were the one to commit this, I would do the adjustment while
> committing...

This whole file seems to use Linux coding style which is why I omitted
spaces inside the if. I made the mask "(1U << remainder) - 1" and
simultaneously drop the superfluous extra brackets in v2 left over from
removing &0xff. 

> 
> Anyway, as long as there's no easily visible tools side bug
> addressed by this, I would think we should rather leave this
> for after branching - Keir?

I'm fine with that.

Ian

8<-----------------------------------------------

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1346947834 -3600
# Node ID adf93d46186bb9b4d39aa195cf3b2445499c87a1
# Parent  6458749bcd38365bc30ae8adac608619e6eec382
xen: clamp bitmaps to correct number of bits

Valgrind running xl create reports:
 ==24777== Invalid read of size 4
 ==24777==    at 0x4072805: libxl__get_numa_candidate (libxl_numa.c:203)
 ==24777==    by 0x40680B6: libxl__build_pre (libxl_dom.c:166)
 ==24777==    by 0x405B82E: libxl__domain_build (libxl_create.c:323)
 ==24777==    by 0x405BB9C: domcreate_bootloader_done (libxl_create.c:747)
 ==24777==    by 0x407AD27: bootloader_local_detached_cb (libxl_bootloader.c:281)
 ==24777==    by 0x40508D8: local_device_detach_cb (libxl.c:2470)
 ==24777==    by 0x4052B10: libxl__device_disk_local_initiate_detach (libxl.c:2445)
 ==24777==    by 0x407AE9F: bootloader_callback (libxl_bootloader.c:265)
 ==24777==    by 0x407C69A: libxl__bootloader_run (libxl_bootloader.c:392)
 ==24777==    by 0x405CB24: do_domain_create (libxl_create.c:687)
 ==24777==    by 0x405CC5E: libxl_domain_create_new (libxl_create.c:1177)
 ==24777==    by 0x805BDE2: create_domain (xl_cmdimpl.c:1812)
 ==24777==  Address 0x42dbdd8 is 8 bytes after a block of size 48 alloc'd
 ==24777==    at 0x4023340: calloc (vg_replace_malloc.c:593)
 ==24777==    by 0x406D479: libxl__zalloc (libxl_internal.c:88)
 ==24777==    by 0x404EF38: libxl_get_cpu_topology (libxl.c:3707)
 ==24777==    by 0x4072232: libxl__get_numa_candidate (libxl_numa.c:314)
 ==24777==    by 0x40680B6: libxl__build_pre (libxl_dom.c:166)
 ==24777==    by 0x405B82E: libxl__domain_build (libxl_create.c:323)
 ==24777==    by 0x405BB9C: domcreate_bootloader_done (libxl_create.c:747)
 ==24777==    by 0x407AD27: bootloader_local_detached_cb (libxl_bootloader.c:281)
 ==24777==    by 0x40508D8: local_device_detach_cb (libxl.c:2470)
 ==24777==    by 0x4052B10: libxl__device_disk_local_initiate_detach (libxl.c:2445)
 ==24777==    by 0x407AE9F: bootloader_callback (libxl_bootloader.c:265)
 ==24777==    by 0x407C69A: libxl__bootloader_run (libxl_bootloader.c:392)

This is because with nr_cpus=4 the bitmask returned from Xen
contains 0xff rather than 0x0f bit our bitmap walking routines (e.g.
libxl_for_each_set_bit) round up to the next byte (so it iterates
e.g. 8 times not 4). This then causes us to access of the end of
whatever array we are walking through each set bit for.

The principal of least surprise suggests that these bits ought not to
be set and this is not a hot path so fix this at the hypervisor layer
by clamping the bits in the returned bitmap to the correct limit.

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

The impact of this seems to be fairly benign in practice, so I'm not
sure about it for 4.2.0. Could leave to 4.2.1?

Dario,

Any chance you could look at the libxl bitmap functions in 4.3 and
make them use the right limit (i.e. nr_bits not (nr_bits+7)/8?

Thanks,
Ian.

diff -r 6458749bcd38 -r adf93d46186b xen/common/bitmap.c
--- a/xen/common/bitmap.c	Thu Sep 06 17:04:25 2012 +0100
+++ b/xen/common/bitmap.c	Thu Sep 06 17:10:34 2012 +0100
@@ -38,6 +38,21 @@
  * for the best explanations of this ordering.
  */
 
+/*
+ * If a bitmap has a number of bits which is not a multiple of 8 then
+ * the last few bits of the last byte of the bitmap can be
+ * unexpectedly set which can confuse consumers (e.g. in the tools)
+ * who also round up their loops to 8 bits. Ensure we clear those left
+ * over bits so as to prevent surprises.
+ */
+static void clamp_last_byte(uint8_t *bp, unsigned int nbits)
+{
+	unsigned int remainder = nbits % 8;
+
+	if (remainder)
+		bp[nbits/8] &= (1U << remainder) - 1;
+}
+
 int __bitmap_empty(const unsigned long *bitmap, int bits)
 {
 	int k, lim = bits/BITS_PER_LONG;
@@ -485,6 +500,7 @@ void bitmap_long_to_byte(uint8_t *bp, co
 			nbits -= 8;
 		}
 	}
+	clamp_last_byte(bp, nbits);
 }
 
 void bitmap_byte_to_long(unsigned long *lp, const uint8_t *bp, int nbits)
@@ -507,6 +523,7 @@ void bitmap_byte_to_long(unsigned long *
 void bitmap_long_to_byte(uint8_t *bp, const unsigned long *lp, int nbits)
 {
 	memcpy(bp, lp, (nbits+7)/8);
+	clamp_last_byte(bp, nbits);
 }
 
 void bitmap_byte_to_long(unsigned long *lp, const uint8_t *bp, int nbits)




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

From xen-devel-bounces@lists.xen.org Thu Sep 06 16:20:54 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 2012 16:20:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9eop-0005g4-HZ; Thu, 06 Sep 2012 16:20:39 +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 1T9eoo-0005fh-68
	for xen-devel@lists.xen.org; Thu, 06 Sep 2012 16:20:38 +0000
Received: from [85.158.139.83:7689] by server-6.bemta-5.messagelabs.com id
	F0/40-21336-55DC8405; Thu, 06 Sep 2012 16:20:37 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1346948429!28324278!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDc0MTc4NQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23013 invoked from network); 6 Sep 2012 16:20:31 -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 Sep 2012 16:20:31 -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 q86GKRlA023067
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 6 Sep 2012 16:20:27 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
	q86GKQZN023460
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 6 Sep 2012 16:20:27 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
	q86GKQkf026582; Thu, 6 Sep 2012 11:20:26 -0500
Received: from localhost.localdomain (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 06 Sep 2012 09:20:26 -0700
Date: Thu, 6 Sep 2012 12:20:20 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Andres Lagar-Cavilla <andreslc@gridcentric.ca>
Message-ID: <20120906162020.GA13327@localhost.localdomain>
References: <1346331492-15027-1-git-send-email-david.vrabel@citrix.com>
	<1346331492-15027-3-git-send-email-david.vrabel@citrix.com>
	<C989BE9D-E520-4D04-9028-6CE6CC765E76@gridcentric.ca>
	<20120905162148.GC11949@phenom.dumpdata.com>
	<939BE993-572C-4D83-8F04-E6B9D6EE3E92@gridcentric.ca>
	<20120905174046.GA25535@phenom.dumpdata.com>
	<39CBBAD7-E10F-457F-BFE3-717A50D059FB@gridcentric.ca>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <39CBBAD7-E10F-457F-BFE3-717A50D059FB@gridcentric.ca>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: David Vrabel <david.vrabel@citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 2/2] xen/privcmd: add PRIVCMD_MMAPBATCH_V2
	ioctl
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Sep 06, 2012 at 09:41:44AM -0400, Andres Lagar-Cavilla wrote:
> On Sep 5, 2012, at 1:40 PM, Konrad Rzeszutek Wilk wrote:
> 
> > On Wed, Sep 05, 2012 at 01:09:32PM -0400, Andres Lagar-Cavilla wrote:
> >> Super. To which branch are you applying these now? (n00b question but have to ask)
> > 
> > They will show up on stable/for-linus-3.7 once the overnight tests pass.
> 
> I would be very surprised if this passed your nighties. This is because the following hunk is necessary:

It did :-) I guess the Xen 4.1 isn't using this that much.
> 
> diff --git a/drivers/xen/privcmd.c b/drivers/xen/privcmd.c
> index 5386f20..e4dfa3b 100644
> --- a/drivers/xen/privcmd.c
> +++ b/drivers/xen/privcmd.c
> @@ -389,7 +389,7 @@ static long privcmd_ioctl_mmap_batch(void __user *udata, int version)
>                 state.err      = err_array;
>                 ret = traverse_pages(m.num, sizeof(xen_pfn_t),
>                                          &pagelist, mmap_return_errors_v1, &state);
> -       } else
> +       } else if (version == 2)
>                 ret = __copy_to_user(m.err, err_array, m.num * sizeof(int));
>  
>      /* If we have not had any EFAULT-like global errors then set the global
> 
> I can either resubmit the original patch with this squashed in, or send this stand-alone. Nightlies may have passed if your libxc never exercises v1 in favor of v2. But this is broken for v1 as it will unconditionally attempt a copy to user on a NULL target and this set rc to EFAULT.
> 

Send it stand alone pls.

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

From xen-devel-bounces@lists.xen.org Thu Sep 06 16:32:37 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 2012 16:32:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9f09-0006Qa-1Y; Thu, 06 Sep 2012 16:32: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 1T9f07-0006QP-Ju
	for xen-devel@lists.xensource.com; Thu, 06 Sep 2012 16:32:19 +0000
Received: from [85.158.143.99:42665] by server-3.bemta-4.messagelabs.com id
	53/D1-08232-210D8405; Thu, 06 Sep 2012 16:32:18 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1346949138!28375227!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTE5NzY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16851 invoked from network); 6 Sep 2012 16:32:18 -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;
	6 Sep 2012 16:32:18 -0000
X-IronPort-AV: E=Sophos;i="4.80,380,1344211200"; d="scan'208";a="14391874"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Sep 2012 16:32: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.279.1; Thu, 6 Sep 2012
	17:32:17 +0100
Message-ID: <1346949137.10570.37.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Sander Eikelenboom <linux@eikelenboom.it>
Date: Thu, 6 Sep 2012 17:32:17 +0100
In-Reply-To: <887956845.20120906180206@eikelenboom.it>
References: <c6d5f62c345b6b41b9ff.1346942187@xentest.example.org>
	<887956845.20120906180206@eikelenboom.it>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-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] xl: Introduce shutdown xm compatibility
 option -a to shutdown all domains
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-09-06 at 17:02 +0100, Sander Eikelenboom wrote:
> Thursday, September 6, 2012, 4:36:27 PM, you wrote:
> 
> > xl: Introduce shutdown xm compatibility option -a to shutdown all domains
> 
> > v2: address review comments.
> >     - Change shutdown_domain to take domid instead of domname
> >     - Docs: Make it more clear -a only shuts down GUEST domains
> 
> > Signed-off-by: Sander Eikelenboom <linux@eikelenboom.it>
> 
> > diff -r 9dc729b75595 -r c6d5f62c345b docs/man/xl.pod.1
> > --- a/docs/man/xl.pod.1       Mon Sep 03 11:22:02 2012 +0100
> > +++ b/docs/man/xl.pod.1       Thu Sep 06 16:35:04 2012 +0200
> > @@ -527,7 +527,7 @@ List specifically for that domain. Other
> >  
> >  =back
> >  
> > -=item B<shutdown> [I<OPTIONS>] I<domain-id>
> > +=item B<shutdown> [I<OPTIONS>] I<-a|domain-id>
> >  
> >  Gracefully shuts down a domain.  This coordinates with the domain OS
> >  to perform graceful shutdown, so there is no guarantee that it will
> > @@ -550,6 +550,10 @@ B<OPTIONS>
> >  
> >  =over 4
> >  
> > +=item B<-a>
> > +
> > +-a  Shutdown all guest domains.  Often used when doing a complete shutdown of a Xen system.
> > +
> >  =item B<-w>
> >  
> >  Wait for the domain to complete shutdown before returning.
> > diff -r 9dc729b75595 -r c6d5f62c345b tools/libxl/xl_cmdimpl.c
> > --- a/tools/libxl/xl_cmdimpl.c  Mon Sep 03 11:22:02 2012 +0100
> > +++ b/tools/libxl/xl_cmdimpl.c  Thu Sep 06 16:35:04 2012 +0200
> > @@ -2683,12 +2683,11 @@ static void destroy_domain(const char *p
> >      if (rc) { fprintf(stderr,"destroy failed (rc=%d)\n",rc); exit(-1); }
> >  }
> >  
> > -static void shutdown_domain(const char *p, int wait, int fallback_trigger)
> > +static void shutdown_domain(uint32_t domid, int wait, int fallback_trigger)
> >  {
> >      int rc;
> >      libxl_event *event;
> >  
> > -    find_domain(p);
> >      rc=libxl_domain_shutdown(ctx, domid);
> >      if (rc == ERROR_NOPARAVIRT) {
> >          if (fallback_trigger) {
> 
> Hi Ian,
> 
> Done some more testing and this seems to lead to the following error when issueing both -a and -w:
> 
> xentest:/usr/src/xen-unstable.hg# xl shutdown -a -w
> libxl: error: libxl_json.c:773:libxl__object_to_json: unable to convert libxl_event to JSON representation. YAJL error code 1: keys must be strings
> INTERNAL PROBLEM - ignoring unexpected event for domain 11 (expected -1): event=(null)
> libxl: error: libxl_json.c:773:libxl__object_to_json: unable to convert libxl_event to JSON representation. YAJL error code 1: keys must be strings
> INTERNAL PROBLEM - ignoring unexpected event for domain 11 (expected -1): event=(null)
> 
> If i only use -w and specify a specific domain, it works without a problem.
> 
> Any ideas ?

Just a guess but we have some issues in xl with local variables
shadowing global ones (which happens with domid in particular). This is
something we plan to look at in 4.3 (by enable -Wshadow and cleaning up
the mess).

I think what is happening is that shutdown_domain now takes a uint32_t
domid, which shadows the global domid but then we call domain_wait_event
which uses the global one. So when you use -a you never set the global
one because you don't need to call find_domain. Quite how this results
in the message above I'm not too sure (Ian J may have some insight to
the events subsystem)

It's all rather horrid, I think for now the best thing might be for
shutdown_domain to look like:

static void shutdown_domain(uint32_t xdomid, int wait, int fallback_trigger)
{
    [... vars...]

    domid = xdomid

    ...

Yes, this is horrible...

Ian.



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

From xen-devel-bounces@lists.xen.org Thu Sep 06 16:32:37 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 2012 16:32:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9f09-0006Qa-1Y; Thu, 06 Sep 2012 16:32: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 1T9f07-0006QP-Ju
	for xen-devel@lists.xensource.com; Thu, 06 Sep 2012 16:32:19 +0000
Received: from [85.158.143.99:42665] by server-3.bemta-4.messagelabs.com id
	53/D1-08232-210D8405; Thu, 06 Sep 2012 16:32:18 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1346949138!28375227!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTE5NzY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16851 invoked from network); 6 Sep 2012 16:32:18 -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;
	6 Sep 2012 16:32:18 -0000
X-IronPort-AV: E=Sophos;i="4.80,380,1344211200"; d="scan'208";a="14391874"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Sep 2012 16:32: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.279.1; Thu, 6 Sep 2012
	17:32:17 +0100
Message-ID: <1346949137.10570.37.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Sander Eikelenboom <linux@eikelenboom.it>
Date: Thu, 6 Sep 2012 17:32:17 +0100
In-Reply-To: <887956845.20120906180206@eikelenboom.it>
References: <c6d5f62c345b6b41b9ff.1346942187@xentest.example.org>
	<887956845.20120906180206@eikelenboom.it>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-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] xl: Introduce shutdown xm compatibility
 option -a to shutdown all domains
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-09-06 at 17:02 +0100, Sander Eikelenboom wrote:
> Thursday, September 6, 2012, 4:36:27 PM, you wrote:
> 
> > xl: Introduce shutdown xm compatibility option -a to shutdown all domains
> 
> > v2: address review comments.
> >     - Change shutdown_domain to take domid instead of domname
> >     - Docs: Make it more clear -a only shuts down GUEST domains
> 
> > Signed-off-by: Sander Eikelenboom <linux@eikelenboom.it>
> 
> > diff -r 9dc729b75595 -r c6d5f62c345b docs/man/xl.pod.1
> > --- a/docs/man/xl.pod.1       Mon Sep 03 11:22:02 2012 +0100
> > +++ b/docs/man/xl.pod.1       Thu Sep 06 16:35:04 2012 +0200
> > @@ -527,7 +527,7 @@ List specifically for that domain. Other
> >  
> >  =back
> >  
> > -=item B<shutdown> [I<OPTIONS>] I<domain-id>
> > +=item B<shutdown> [I<OPTIONS>] I<-a|domain-id>
> >  
> >  Gracefully shuts down a domain.  This coordinates with the domain OS
> >  to perform graceful shutdown, so there is no guarantee that it will
> > @@ -550,6 +550,10 @@ B<OPTIONS>
> >  
> >  =over 4
> >  
> > +=item B<-a>
> > +
> > +-a  Shutdown all guest domains.  Often used when doing a complete shutdown of a Xen system.
> > +
> >  =item B<-w>
> >  
> >  Wait for the domain to complete shutdown before returning.
> > diff -r 9dc729b75595 -r c6d5f62c345b tools/libxl/xl_cmdimpl.c
> > --- a/tools/libxl/xl_cmdimpl.c  Mon Sep 03 11:22:02 2012 +0100
> > +++ b/tools/libxl/xl_cmdimpl.c  Thu Sep 06 16:35:04 2012 +0200
> > @@ -2683,12 +2683,11 @@ static void destroy_domain(const char *p
> >      if (rc) { fprintf(stderr,"destroy failed (rc=%d)\n",rc); exit(-1); }
> >  }
> >  
> > -static void shutdown_domain(const char *p, int wait, int fallback_trigger)
> > +static void shutdown_domain(uint32_t domid, int wait, int fallback_trigger)
> >  {
> >      int rc;
> >      libxl_event *event;
> >  
> > -    find_domain(p);
> >      rc=libxl_domain_shutdown(ctx, domid);
> >      if (rc == ERROR_NOPARAVIRT) {
> >          if (fallback_trigger) {
> 
> Hi Ian,
> 
> Done some more testing and this seems to lead to the following error when issueing both -a and -w:
> 
> xentest:/usr/src/xen-unstable.hg# xl shutdown -a -w
> libxl: error: libxl_json.c:773:libxl__object_to_json: unable to convert libxl_event to JSON representation. YAJL error code 1: keys must be strings
> INTERNAL PROBLEM - ignoring unexpected event for domain 11 (expected -1): event=(null)
> libxl: error: libxl_json.c:773:libxl__object_to_json: unable to convert libxl_event to JSON representation. YAJL error code 1: keys must be strings
> INTERNAL PROBLEM - ignoring unexpected event for domain 11 (expected -1): event=(null)
> 
> If i only use -w and specify a specific domain, it works without a problem.
> 
> Any ideas ?

Just a guess but we have some issues in xl with local variables
shadowing global ones (which happens with domid in particular). This is
something we plan to look at in 4.3 (by enable -Wshadow and cleaning up
the mess).

I think what is happening is that shutdown_domain now takes a uint32_t
domid, which shadows the global domid but then we call domain_wait_event
which uses the global one. So when you use -a you never set the global
one because you don't need to call find_domain. Quite how this results
in the message above I'm not too sure (Ian J may have some insight to
the events subsystem)

It's all rather horrid, I think for now the best thing might be for
shutdown_domain to look like:

static void shutdown_domain(uint32_t xdomid, int wait, int fallback_trigger)
{
    [... vars...]

    domid = xdomid

    ...

Yes, this is horrible...

Ian.



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

From xen-devel-bounces@lists.xen.org Thu Sep 06 16:39:29 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 2012 16:39:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9f6j-0006nG-1i; Thu, 06 Sep 2012 16:39:09 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1T9f6h-0006mv-Tw
	for xen-devel@lists.xen.org; Thu, 06 Sep 2012 16:39:08 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-10.tower-27.messagelabs.com!1346949541!4739568!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiA0MTgxNzk=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiA0MTgxNzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21215 invoked from network); 6 Sep 2012 16:39:01 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-10.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 6 Sep 2012 16:39:01 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/lk2c7pE3Rh
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-090-217.pools.arcor-ip.net [84.57.90.217])
	by smtp.strato.de (joses mo24) (RZmta 30.14 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id v017a5o86GRTPG
	for <xen-devel@lists.xen.org>; Thu, 6 Sep 2012 18:39:01 +0200 (CEST)
Received: by probook.site (Postfix, from userid 1000)
	id 78FB1183AD; Thu,  6 Sep 2012 18:39:00 +0200 (CEST)
Date: Thu, 6 Sep 2012 18:39:00 +0200
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xen.org
Message-ID: <20120906163900.GA26442@aepfle.de>
MIME-Version: 1.0
Content-Disposition: inline
User-Agent: Mutt/1.5.21.rev5555 (2012-07-20)
Subject: [Xen-devel] creating _libxl_list.h is racy
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 is apparently a race in creating _libxl_list.h,
in xen-unstable 25821:19d367bf07b7:


[  261s] + make -j8 -k docs stubdom
 ...
[  379s] make -C libxl install
[  379s] make[3]: Entering directory `/usr/src/packages/BUILD/xen-4.2.25821/non-dbg/tools/libxl'
[  379s] /usr/bin/perl /usr/src/packages/BUILD/xen-4.2.25821/non-dbg/tools/libxl/../../tools/include/xen-external/bsd-sys-queue-h-seddery /usr/src/packages/BUILD/xen-4.2.25821/non-dbg/tools/libxl/../../tools/include/xen-external/bsd-sys-queue.h --prefix=libxl >_libxl_list.h.new
[  380s] rm -f _paths.h.tmp.tmp;  echo "SBINDIR=\"/usr/sbin\"" >>_paths.h.tmp.tmp;  echo "BINDIR=\"/usr/bin\"" >>_paths.h.tmp.tmp;  echo "LIBEXEC=\"/usr/lib/xen/bin\"" >>_paths.h.tmp.tmp;  echo "LIBDIR=\"/usr/lib64\"" >>_paths.h.tmp.tmp;  echo "SHAREDIR=\"/usr/share\"" >>_paths.h.tmp.tmp;  echo "PRIVATE_BINDIR=\"/usr/lib64/xen/bin\"" >>_paths.h.tmp.tmp;  echo "XENFIRMWAREDIR=\"/usr/lib/xen/boot\"" >>_paths.h.tmp.tmp;  echo "XEN_CONFIG_DIR=\"/etc/xen\"" >>_paths.h.tmp.tmp;  echo "XEN_SCRIPT_DIR=\"/etc/xen/scripts\"" >>_paths.h.tmp.tmp;  echo "XEN_LOCK_DIR=\"/var/lock\"" >>_paths.h.tmp.tmp;  echo "XEN_RUN_DIR=\"/var/run/xen\"" >>_paths.h.tmp.tmp;  echo "XEN_PAGING_DIR=\"/var/lib/xen/xenpaging\"" >>_paths.h.tmp.tmp; if ! cmp -s _paths.h.tmp.tmp _paths.h.tmp; then mv -f _paths.h.tmp.tmp _paths.h.tmp; else rm -f _paths.h.tmp.tmp; fi
[  380s] /usr/bin/perl -w libxl_save_msgs_gen.pl _libxl_save_msgs_callout.h >_libxl_save_msgs_callout.h.new
[  380s] /usr/bin/perl -w libxl_save_msgs_gen.pl _libxl_save_msgs_helper.h >_libxl_save_msgs_helper.h.new
[  380s] python gentypes.py libxl_types.idl __libxl_types.h __libxl_types_json.h __libxl_types.c
[  380s] python gentypes.py libxl_types_internal.idl __libxl_types_internal.h __libxl_types_internal_json.h __libxl_types_internal.c
[  380s] /usr/bin/perl -w libxl_save_msgs_gen.pl _libxl_save_msgs_callout.c >_libxl_save_msgs_callout.c.new
[  380s] Parsing libxl_types.idl
[  380s] if ! cmp -s _libxl_save_msgs_callout.h.new _libxl_save_msgs_callout.h; then mv -f _libxl_save_msgs_callout.h.new _libxl_save_msgs_callout.h; else rm -f _libxl_save_msgs_callout.h.new; fi
[  380s] /usr/bin/perl -w libxl_save_msgs_gen.pl _libxl_save_msgs_helper.c >_libxl_save_msgs_helper.c.new
[  380s] Parsing libxl_types_internal.idl
[  380s] if ! cmp -s _libxl_save_msgs_helper.h.new _libxl_save_msgs_helper.h; then mv -f _libxl_save_msgs_helper.h.new _libxl_save_msgs_helper.h; else rm -f _libxl_save_msgs_helper.h.new; fi
[  380s] outputting libxl type definitions to __libxl_types_internal.h
[  380s] outputting libxl JSON definitions to __libxl_types_internal_json.h
[  380s] outputting libxl type implementations to __libxl_types_internal.c
[  380s] if ! cmp -s __libxl_types_internal.h _libxl_types_internal.h; then mv -f __libxl_types_internal.h _libxl_types_internal.h; else rm -f __libxl_types_internal.h; fi
[  380s] sed -e "s/\([^=]*\)=\(.*\)/#define \1 \2/g" _paths.h.tmp >_paths.h.2.tmp
[  380s] if ! cmp -s __libxl_types_internal_json.h _libxl_types_internal_json.h; then mv -f __libxl_types_internal_json.h _libxl_types_internal_json.h; else rm -f __libxl_types_internal_json.h; fi
[  380s] rm -f _paths.h.tmp
[  380s] if ! cmp -s _paths.h.2.tmp _paths.h; then mv -f _paths.h.2.tmp _paths.h; else rm -f _paths.h.2.tmp; fi
[  380s] if ! cmp -s __libxl_types_internal.c _libxl_types_internal.c; then mv -f __libxl_types_internal.c _libxl_types_internal.c; else rm -f __libxl_types_internal.c; fi
[  380s] outputting libxl type definitions to __libxl_types.h
[  380s] outputting libxl JSON definitions to __libxl_types_json.h
[  380s] outputting libxl type implementations to __libxl_types.c
[  380s] if ! cmp -s __libxl_types.h _libxl_types.h; then mv -f __libxl_types.h _libxl_types.h; else rm -f __libxl_types.h; fi
[  380s] if ! cmp -s __libxl_types_json.h _libxl_types_json.h; then mv -f __libxl_types_json.h _libxl_types_json.h; else rm -f __libxl_types_json.h; fi
[  380s] if ! cmp -s __libxl_types.c _libxl_types.c; then mv -f __libxl_types.c _libxl_types.c; else rm -f __libxl_types.c; fi
[  380s] 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.api-for-check.d  -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -fno-optimize-sibling-calls -fmessage-length=0 -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables -fasynchronous-unwind-tables -Werror -Wno-format-zero-length -Wmissing-declarations -Wno-declaration-after-statement -Wformat-nonliteral -I. -fPIC -pthread -I/usr/src/packages/BUILD/xen-4.2.25821/non-dbg/tools/libxl/../../tools/libxc -I/usr/src/packages/BUILD/xen-4.2.25821/non-dbg/tools/libxl/../../tools/include  -I/usr/src/packages/BUILD/xen-4.2.25821/non-dbg/tools/libxl/../../tools/libxl -I/usr/src/packages/BUILD/xen-4.2.25821/non-dbg/tools/libxl/../../tools/libxc -I/usr/src/packages/BUILD/xen-4.2.25821/non-dbg/tools/libxl/../../tools/include -I/usr/src/packages/BUILD/xen-4.2.25821/non-dbg/tools/libxl/../../tools/include -include /usr/src/packages/BUILD/xen-4.2.25821/non-dbg/tools/libxl/../../tools/config.h  -I/usr/src/packages/BUILD/xen-4.2.25821/non-dbg/tools/libxl/../../tools/libxc -I/usr/src/packages/BUILD/xen-4.2.25821/non-dbg/tools/libxl/../../tools/include   -c -E libxl.h  \
[  380s] -DLIBXL_EXTERNAL_CALLERS_ONLY=LIBXL_EXTERNAL_CALLERS_ONLY \
[  380s] >_libxl.api-for-check.new
[  380s] if ! cmp -s _libxl_save_msgs_callout.c.new _libxl_save_msgs_callout.c; then mv -f _libxl_save_msgs_callout.c.new _libxl_save_msgs_callout.c; else rm -f _libxl_save_msgs_callout.c.new; fi
[  380s] if ! cmp -s _libxl_save_msgs_helper.c.new _libxl_save_msgs_helper.c; then mv -f _libxl_save_msgs_helper.c.new _libxl_save_msgs_helper.c; else rm -f _libxl_save_msgs_helper.c.new; fi
[  380s] libxl.h:260:25: fatal error: _libxl_list.h: No such file or directory
[  380s] compilation terminated.
[  380s] make[3]: *** [_libxl.api-for-check] Error 1
[  381s] if ! cmp -s _libxl_list.h.new _libxl_list.h; then mv -f _libxl_list.h.new _libxl_list.h; else rm -f _libxl_list.h.new; fi
[  381s] make[3]: Target `install' not remade because of errors.
[  381s] make[3]: Leaving directory `/usr/src/packages/BUILD/xen-4.2.25821/non-dbg/tools/libxl'
[  381s] make[2]: *** [subdir-install-libxl] Error 2
[  381s] make[2]: Leaving directory `/usr/src/packages/BUILD/xen-4.2.25821/non-dbg/tools'
[  381s] make[1]: *** [subdirs-install] Error 2
[  381s] make[1]: Target `install' not remade because of errors.
[  381s] make[1]: Leaving directory `/usr/src/packages/BUILD/xen-4.2.25821/non-dbg/tools'
[  381s] make: *** [install-tools] Error 2
[  381s] make: Target `stubdom' not remade because of errors.
[  381s] error: Bad exit status from /var/tmp/rpm-tmp.TNgYuT (%build)


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

From xen-devel-bounces@lists.xen.org Thu Sep 06 16:39:29 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 2012 16:39:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9f6j-0006nG-1i; Thu, 06 Sep 2012 16:39:09 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1T9f6h-0006mv-Tw
	for xen-devel@lists.xen.org; Thu, 06 Sep 2012 16:39:08 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-10.tower-27.messagelabs.com!1346949541!4739568!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiA0MTgxNzk=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiA0MTgxNzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21215 invoked from network); 6 Sep 2012 16:39:01 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-10.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 6 Sep 2012 16:39:01 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/lk2c7pE3Rh
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-090-217.pools.arcor-ip.net [84.57.90.217])
	by smtp.strato.de (joses mo24) (RZmta 30.14 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id v017a5o86GRTPG
	for <xen-devel@lists.xen.org>; Thu, 6 Sep 2012 18:39:01 +0200 (CEST)
Received: by probook.site (Postfix, from userid 1000)
	id 78FB1183AD; Thu,  6 Sep 2012 18:39:00 +0200 (CEST)
Date: Thu, 6 Sep 2012 18:39:00 +0200
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xen.org
Message-ID: <20120906163900.GA26442@aepfle.de>
MIME-Version: 1.0
Content-Disposition: inline
User-Agent: Mutt/1.5.21.rev5555 (2012-07-20)
Subject: [Xen-devel] creating _libxl_list.h is racy
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 is apparently a race in creating _libxl_list.h,
in xen-unstable 25821:19d367bf07b7:


[  261s] + make -j8 -k docs stubdom
 ...
[  379s] make -C libxl install
[  379s] make[3]: Entering directory `/usr/src/packages/BUILD/xen-4.2.25821/non-dbg/tools/libxl'
[  379s] /usr/bin/perl /usr/src/packages/BUILD/xen-4.2.25821/non-dbg/tools/libxl/../../tools/include/xen-external/bsd-sys-queue-h-seddery /usr/src/packages/BUILD/xen-4.2.25821/non-dbg/tools/libxl/../../tools/include/xen-external/bsd-sys-queue.h --prefix=libxl >_libxl_list.h.new
[  380s] rm -f _paths.h.tmp.tmp;  echo "SBINDIR=\"/usr/sbin\"" >>_paths.h.tmp.tmp;  echo "BINDIR=\"/usr/bin\"" >>_paths.h.tmp.tmp;  echo "LIBEXEC=\"/usr/lib/xen/bin\"" >>_paths.h.tmp.tmp;  echo "LIBDIR=\"/usr/lib64\"" >>_paths.h.tmp.tmp;  echo "SHAREDIR=\"/usr/share\"" >>_paths.h.tmp.tmp;  echo "PRIVATE_BINDIR=\"/usr/lib64/xen/bin\"" >>_paths.h.tmp.tmp;  echo "XENFIRMWAREDIR=\"/usr/lib/xen/boot\"" >>_paths.h.tmp.tmp;  echo "XEN_CONFIG_DIR=\"/etc/xen\"" >>_paths.h.tmp.tmp;  echo "XEN_SCRIPT_DIR=\"/etc/xen/scripts\"" >>_paths.h.tmp.tmp;  echo "XEN_LOCK_DIR=\"/var/lock\"" >>_paths.h.tmp.tmp;  echo "XEN_RUN_DIR=\"/var/run/xen\"" >>_paths.h.tmp.tmp;  echo "XEN_PAGING_DIR=\"/var/lib/xen/xenpaging\"" >>_paths.h.tmp.tmp; if ! cmp -s _paths.h.tmp.tmp _paths.h.tmp; then mv -f _paths.h.tmp.tmp _paths.h.tmp; else rm -f _paths.h.tmp.tmp; fi
[  380s] /usr/bin/perl -w libxl_save_msgs_gen.pl _libxl_save_msgs_callout.h >_libxl_save_msgs_callout.h.new
[  380s] /usr/bin/perl -w libxl_save_msgs_gen.pl _libxl_save_msgs_helper.h >_libxl_save_msgs_helper.h.new
[  380s] python gentypes.py libxl_types.idl __libxl_types.h __libxl_types_json.h __libxl_types.c
[  380s] python gentypes.py libxl_types_internal.idl __libxl_types_internal.h __libxl_types_internal_json.h __libxl_types_internal.c
[  380s] /usr/bin/perl -w libxl_save_msgs_gen.pl _libxl_save_msgs_callout.c >_libxl_save_msgs_callout.c.new
[  380s] Parsing libxl_types.idl
[  380s] if ! cmp -s _libxl_save_msgs_callout.h.new _libxl_save_msgs_callout.h; then mv -f _libxl_save_msgs_callout.h.new _libxl_save_msgs_callout.h; else rm -f _libxl_save_msgs_callout.h.new; fi
[  380s] /usr/bin/perl -w libxl_save_msgs_gen.pl _libxl_save_msgs_helper.c >_libxl_save_msgs_helper.c.new
[  380s] Parsing libxl_types_internal.idl
[  380s] if ! cmp -s _libxl_save_msgs_helper.h.new _libxl_save_msgs_helper.h; then mv -f _libxl_save_msgs_helper.h.new _libxl_save_msgs_helper.h; else rm -f _libxl_save_msgs_helper.h.new; fi
[  380s] outputting libxl type definitions to __libxl_types_internal.h
[  380s] outputting libxl JSON definitions to __libxl_types_internal_json.h
[  380s] outputting libxl type implementations to __libxl_types_internal.c
[  380s] if ! cmp -s __libxl_types_internal.h _libxl_types_internal.h; then mv -f __libxl_types_internal.h _libxl_types_internal.h; else rm -f __libxl_types_internal.h; fi
[  380s] sed -e "s/\([^=]*\)=\(.*\)/#define \1 \2/g" _paths.h.tmp >_paths.h.2.tmp
[  380s] if ! cmp -s __libxl_types_internal_json.h _libxl_types_internal_json.h; then mv -f __libxl_types_internal_json.h _libxl_types_internal_json.h; else rm -f __libxl_types_internal_json.h; fi
[  380s] rm -f _paths.h.tmp
[  380s] if ! cmp -s _paths.h.2.tmp _paths.h; then mv -f _paths.h.2.tmp _paths.h; else rm -f _paths.h.2.tmp; fi
[  380s] if ! cmp -s __libxl_types_internal.c _libxl_types_internal.c; then mv -f __libxl_types_internal.c _libxl_types_internal.c; else rm -f __libxl_types_internal.c; fi
[  380s] outputting libxl type definitions to __libxl_types.h
[  380s] outputting libxl JSON definitions to __libxl_types_json.h
[  380s] outputting libxl type implementations to __libxl_types.c
[  380s] if ! cmp -s __libxl_types.h _libxl_types.h; then mv -f __libxl_types.h _libxl_types.h; else rm -f __libxl_types.h; fi
[  380s] if ! cmp -s __libxl_types_json.h _libxl_types_json.h; then mv -f __libxl_types_json.h _libxl_types_json.h; else rm -f __libxl_types_json.h; fi
[  380s] if ! cmp -s __libxl_types.c _libxl_types.c; then mv -f __libxl_types.c _libxl_types.c; else rm -f __libxl_types.c; fi
[  380s] 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.api-for-check.d  -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -fno-optimize-sibling-calls -fmessage-length=0 -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables -fasynchronous-unwind-tables -Werror -Wno-format-zero-length -Wmissing-declarations -Wno-declaration-after-statement -Wformat-nonliteral -I. -fPIC -pthread -I/usr/src/packages/BUILD/xen-4.2.25821/non-dbg/tools/libxl/../../tools/libxc -I/usr/src/packages/BUILD/xen-4.2.25821/non-dbg/tools/libxl/../../tools/include  -I/usr/src/packages/BUILD/xen-4.2.25821/non-dbg/tools/libxl/../../tools/libxl -I/usr/src/packages/BUILD/xen-4.2.25821/non-dbg/tools/libxl/../../tools/libxc -I/usr/src/packages/BUILD/xen-4.2.25821/non-dbg/tools/libxl/../../tools/include -I/usr/src/packages/BUILD/xen-4.2.25821/non-dbg/tools/libxl/../../tools/include -include /usr/src/packages/BUILD/xen-4.2.25821/non-dbg/tools/libxl/../../tools/config.h  -I/usr/src/packages/BUILD/xen-4.2.25821/non-dbg/tools/libxl/../../tools/libxc -I/usr/src/packages/BUILD/xen-4.2.25821/non-dbg/tools/libxl/../../tools/include   -c -E libxl.h  \
[  380s] -DLIBXL_EXTERNAL_CALLERS_ONLY=LIBXL_EXTERNAL_CALLERS_ONLY \
[  380s] >_libxl.api-for-check.new
[  380s] if ! cmp -s _libxl_save_msgs_callout.c.new _libxl_save_msgs_callout.c; then mv -f _libxl_save_msgs_callout.c.new _libxl_save_msgs_callout.c; else rm -f _libxl_save_msgs_callout.c.new; fi
[  380s] if ! cmp -s _libxl_save_msgs_helper.c.new _libxl_save_msgs_helper.c; then mv -f _libxl_save_msgs_helper.c.new _libxl_save_msgs_helper.c; else rm -f _libxl_save_msgs_helper.c.new; fi
[  380s] libxl.h:260:25: fatal error: _libxl_list.h: No such file or directory
[  380s] compilation terminated.
[  380s] make[3]: *** [_libxl.api-for-check] Error 1
[  381s] if ! cmp -s _libxl_list.h.new _libxl_list.h; then mv -f _libxl_list.h.new _libxl_list.h; else rm -f _libxl_list.h.new; fi
[  381s] make[3]: Target `install' not remade because of errors.
[  381s] make[3]: Leaving directory `/usr/src/packages/BUILD/xen-4.2.25821/non-dbg/tools/libxl'
[  381s] make[2]: *** [subdir-install-libxl] Error 2
[  381s] make[2]: Leaving directory `/usr/src/packages/BUILD/xen-4.2.25821/non-dbg/tools'
[  381s] make[1]: *** [subdirs-install] Error 2
[  381s] make[1]: Target `install' not remade because of errors.
[  381s] make[1]: Leaving directory `/usr/src/packages/BUILD/xen-4.2.25821/non-dbg/tools'
[  381s] make: *** [install-tools] Error 2
[  381s] make: Target `stubdom' not remade because of errors.
[  381s] error: Bad exit status from /var/tmp/rpm-tmp.TNgYuT (%build)


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

From xen-devel-bounces@lists.xen.org Thu Sep 06 16:41:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 2012 16:41:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9f8V-0006ut-IW; Thu, 06 Sep 2012 16:40:59 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <linux@eikelenboom.it>) id 1T9f8T-0006uj-MV
	for xen-devel@lists.xensource.com; Thu, 06 Sep 2012 16:40:57 +0000
Received: from [85.158.139.83:38155] by server-11.bemta-5.messagelabs.com id
	32/EF-24658-812D8405; Thu, 06 Sep 2012 16:40:56 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-7.tower-182.messagelabs.com!1346949655!25060735!1
X-Originating-IP: [188.40.164.121]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10980 invoked from network); 6 Sep 2012 16:40:56 -0000
Received: from static.121.164.40.188.clients.your-server.de (HELO
	smtp.eikelenboom.it) (188.40.164.121)
	by server-7.tower-182.messagelabs.com with AES256-SHA encrypted SMTP;
	6 Sep 2012 16:40:56 -0000
Received: from 128-64-ftth.onsneteindhoven.nl ([88.159.64.128]:54379
	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 1T9f8S-0000EZ-UH; Thu, 06 Sep 2012 18:40:57 +0200
Date: Thu, 6 Sep 2012 18:40:51 +0200
From: Sander Eikelenboom <linux@eikelenboom.it>
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <1718522527.20120906184051@eikelenboom.it>
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1346949137.10570.37.camel@dagon.hellion.org.uk>
References: <c6d5f62c345b6b41b9ff.1346942187@xentest.example.org>
	<887956845.20120906180206@eikelenboom.it>
	<1346949137.10570.37.camel@dagon.hellion.org.uk>
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] xl: Introduce shutdown xm compatibility
	option -a to shutdown all 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


Thursday, September 6, 2012, 6:32:17 PM, you wrote:

> On Thu, 2012-09-06 at 17:02 +0100, Sander Eikelenboom wrote:
>> Thursday, September 6, 2012, 4:36:27 PM, you wrote:
>> 
>> > xl: Introduce shutdown xm compatibility option -a to shutdown all domains
>> 
>> > v2: address review comments.
>> >     - Change shutdown_domain to take domid instead of domname
>> >     - Docs: Make it more clear -a only shuts down GUEST domains
>> 
>> > Signed-off-by: Sander Eikelenboom <linux@eikelenboom.it>
>> 
>> > diff -r 9dc729b75595 -r c6d5f62c345b docs/man/xl.pod.1
>> > --- a/docs/man/xl.pod.1       Mon Sep 03 11:22:02 2012 +0100
>> > +++ b/docs/man/xl.pod.1       Thu Sep 06 16:35:04 2012 +0200
>> > @@ -527,7 +527,7 @@ List specifically for that domain. Other
>> >  
>> >  =back
>> >  
>> > -=item B<shutdown> [I<OPTIONS>] I<domain-id>
>> > +=item B<shutdown> [I<OPTIONS>] I<-a|domain-id>
>> >  
>> >  Gracefully shuts down a domain.  This coordinates with the domain OS
>> >  to perform graceful shutdown, so there is no guarantee that it will
>> > @@ -550,6 +550,10 @@ B<OPTIONS>
>> >  
>> >  =over 4
>> >  
>> > +=item B<-a>
>> > +
>> > +-a  Shutdown all guest domains.  Often used when doing a complete shutdown of a Xen system.
>> > +
>> >  =item B<-w>
>> >  
>> >  Wait for the domain to complete shutdown before returning.
>> > diff -r 9dc729b75595 -r c6d5f62c345b tools/libxl/xl_cmdimpl.c
>> > --- a/tools/libxl/xl_cmdimpl.c  Mon Sep 03 11:22:02 2012 +0100
>> > +++ b/tools/libxl/xl_cmdimpl.c  Thu Sep 06 16:35:04 2012 +0200
>> > @@ -2683,12 +2683,11 @@ static void destroy_domain(const char *p
>> >      if (rc) { fprintf(stderr,"destroy failed (rc=%d)\n",rc); exit(-1); }
>> >  }
>> >  
>> > -static void shutdown_domain(const char *p, int wait, int fallback_trigger)
>> > +static void shutdown_domain(uint32_t domid, int wait, int fallback_trigger)
>> >  {
>> >      int rc;
>> >      libxl_event *event;
>> >  
>> > -    find_domain(p);
>> >      rc=libxl_domain_shutdown(ctx, domid);
>> >      if (rc == ERROR_NOPARAVIRT) {
>> >          if (fallback_trigger) {
>> 
>> Hi Ian,
>> 
>> Done some more testing and this seems to lead to the following error when issueing both -a and -w:
>> 
>> xentest:/usr/src/xen-unstable.hg# xl shutdown -a -w
>> libxl: error: libxl_json.c:773:libxl__object_to_json: unable to convert libxl_event to JSON representation. YAJL error code 1: keys must be strings
>> INTERNAL PROBLEM - ignoring unexpected event for domain 11 (expected -1): event=(null)
>> libxl: error: libxl_json.c:773:libxl__object_to_json: unable to convert libxl_event to JSON representation. YAJL error code 1: keys must be strings
>> INTERNAL PROBLEM - ignoring unexpected event for domain 11 (expected -1): event=(null)
>> 
>> If i only use -w and specify a specific domain, it works without a problem.
>> 
>> Any ideas ?

> Just a guess but we have some issues in xl with local variables
> shadowing global ones (which happens with domid in particular). This is
> something we plan to look at in 4.3 (by enable -Wshadow and cleaning up
> the mess).

> I think what is happening is that shutdown_domain now takes a uint32_t
> domid, which shadows the global domid but then we call domain_wait_event
> which uses the global one. So when you use -a you never set the global
> one because you don't need to call find_domain. Quite how this results
> in the message above I'm not too sure (Ian J may have some insight to
> the events subsystem)

> It's all rather horrid, I think for now the best thing might be for
> shutdown_domain to look like:

> static void shutdown_domain(uint32_t xdomid, int wait, int fallback_trigger)
> {
>     [... vars...]

>     domid = xdomid

>     ...

> Yes, this is horrible...

> Ian.

I was quite puzzled that global variables were used, took me quite a while searching how domid could be available without being explicitly set.
I always thought of global variables as being something pretty undesired...

Is naming it "xdomid" ok ? Or would be naming it uint32_t domain_id be better ?

--
Sander




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

From xen-devel-bounces@lists.xen.org Thu Sep 06 16:41:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 2012 16:41:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9f8V-0006ut-IW; Thu, 06 Sep 2012 16:40:59 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <linux@eikelenboom.it>) id 1T9f8T-0006uj-MV
	for xen-devel@lists.xensource.com; Thu, 06 Sep 2012 16:40:57 +0000
Received: from [85.158.139.83:38155] by server-11.bemta-5.messagelabs.com id
	32/EF-24658-812D8405; Thu, 06 Sep 2012 16:40:56 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-7.tower-182.messagelabs.com!1346949655!25060735!1
X-Originating-IP: [188.40.164.121]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10980 invoked from network); 6 Sep 2012 16:40:56 -0000
Received: from static.121.164.40.188.clients.your-server.de (HELO
	smtp.eikelenboom.it) (188.40.164.121)
	by server-7.tower-182.messagelabs.com with AES256-SHA encrypted SMTP;
	6 Sep 2012 16:40:56 -0000
Received: from 128-64-ftth.onsneteindhoven.nl ([88.159.64.128]:54379
	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 1T9f8S-0000EZ-UH; Thu, 06 Sep 2012 18:40:57 +0200
Date: Thu, 6 Sep 2012 18:40:51 +0200
From: Sander Eikelenboom <linux@eikelenboom.it>
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <1718522527.20120906184051@eikelenboom.it>
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1346949137.10570.37.camel@dagon.hellion.org.uk>
References: <c6d5f62c345b6b41b9ff.1346942187@xentest.example.org>
	<887956845.20120906180206@eikelenboom.it>
	<1346949137.10570.37.camel@dagon.hellion.org.uk>
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] xl: Introduce shutdown xm compatibility
	option -a to shutdown all 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


Thursday, September 6, 2012, 6:32:17 PM, you wrote:

> On Thu, 2012-09-06 at 17:02 +0100, Sander Eikelenboom wrote:
>> Thursday, September 6, 2012, 4:36:27 PM, you wrote:
>> 
>> > xl: Introduce shutdown xm compatibility option -a to shutdown all domains
>> 
>> > v2: address review comments.
>> >     - Change shutdown_domain to take domid instead of domname
>> >     - Docs: Make it more clear -a only shuts down GUEST domains
>> 
>> > Signed-off-by: Sander Eikelenboom <linux@eikelenboom.it>
>> 
>> > diff -r 9dc729b75595 -r c6d5f62c345b docs/man/xl.pod.1
>> > --- a/docs/man/xl.pod.1       Mon Sep 03 11:22:02 2012 +0100
>> > +++ b/docs/man/xl.pod.1       Thu Sep 06 16:35:04 2012 +0200
>> > @@ -527,7 +527,7 @@ List specifically for that domain. Other
>> >  
>> >  =back
>> >  
>> > -=item B<shutdown> [I<OPTIONS>] I<domain-id>
>> > +=item B<shutdown> [I<OPTIONS>] I<-a|domain-id>
>> >  
>> >  Gracefully shuts down a domain.  This coordinates with the domain OS
>> >  to perform graceful shutdown, so there is no guarantee that it will
>> > @@ -550,6 +550,10 @@ B<OPTIONS>
>> >  
>> >  =over 4
>> >  
>> > +=item B<-a>
>> > +
>> > +-a  Shutdown all guest domains.  Often used when doing a complete shutdown of a Xen system.
>> > +
>> >  =item B<-w>
>> >  
>> >  Wait for the domain to complete shutdown before returning.
>> > diff -r 9dc729b75595 -r c6d5f62c345b tools/libxl/xl_cmdimpl.c
>> > --- a/tools/libxl/xl_cmdimpl.c  Mon Sep 03 11:22:02 2012 +0100
>> > +++ b/tools/libxl/xl_cmdimpl.c  Thu Sep 06 16:35:04 2012 +0200
>> > @@ -2683,12 +2683,11 @@ static void destroy_domain(const char *p
>> >      if (rc) { fprintf(stderr,"destroy failed (rc=%d)\n",rc); exit(-1); }
>> >  }
>> >  
>> > -static void shutdown_domain(const char *p, int wait, int fallback_trigger)
>> > +static void shutdown_domain(uint32_t domid, int wait, int fallback_trigger)
>> >  {
>> >      int rc;
>> >      libxl_event *event;
>> >  
>> > -    find_domain(p);
>> >      rc=libxl_domain_shutdown(ctx, domid);
>> >      if (rc == ERROR_NOPARAVIRT) {
>> >          if (fallback_trigger) {
>> 
>> Hi Ian,
>> 
>> Done some more testing and this seems to lead to the following error when issueing both -a and -w:
>> 
>> xentest:/usr/src/xen-unstable.hg# xl shutdown -a -w
>> libxl: error: libxl_json.c:773:libxl__object_to_json: unable to convert libxl_event to JSON representation. YAJL error code 1: keys must be strings
>> INTERNAL PROBLEM - ignoring unexpected event for domain 11 (expected -1): event=(null)
>> libxl: error: libxl_json.c:773:libxl__object_to_json: unable to convert libxl_event to JSON representation. YAJL error code 1: keys must be strings
>> INTERNAL PROBLEM - ignoring unexpected event for domain 11 (expected -1): event=(null)
>> 
>> If i only use -w and specify a specific domain, it works without a problem.
>> 
>> Any ideas ?

> Just a guess but we have some issues in xl with local variables
> shadowing global ones (which happens with domid in particular). This is
> something we plan to look at in 4.3 (by enable -Wshadow and cleaning up
> the mess).

> I think what is happening is that shutdown_domain now takes a uint32_t
> domid, which shadows the global domid but then we call domain_wait_event
> which uses the global one. So when you use -a you never set the global
> one because you don't need to call find_domain. Quite how this results
> in the message above I'm not too sure (Ian J may have some insight to
> the events subsystem)

> It's all rather horrid, I think for now the best thing might be for
> shutdown_domain to look like:

> static void shutdown_domain(uint32_t xdomid, int wait, int fallback_trigger)
> {
>     [... vars...]

>     domid = xdomid

>     ...

> Yes, this is horrible...

> Ian.

I was quite puzzled that global variables were used, took me quite a while searching how domid could be available without being explicitly set.
I always thought of global variables as being something pretty undesired...

Is naming it "xdomid" ok ? Or would be naming it uint32_t domain_id be better ?

--
Sander




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

From xen-devel-bounces@lists.xen.org Thu Sep 06 16:42:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 2012 16:42:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9f9b-00071q-5B; Thu, 06 Sep 2012 16:42:07 +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 1T9f9Z-00071M-QM
	for xen-devel@lists.xen.org; Thu, 06 Sep 2012 16:42:06 +0000
Received: from [85.158.143.35:48328] by server-1.bemta-4.messagelabs.com id
	20/DC-12504-D52D8405; Thu, 06 Sep 2012 16:42:05 +0000
X-Env-Sender: ben.guthro@gmail.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1346949722!13669463!1
X-Originating-IP: [209.85.223.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13831 invoked from network); 6 Sep 2012 16:42:03 -0000
Received: from mail-ie0-f173.google.com (HELO mail-ie0-f173.google.com)
	(209.85.223.173)
	by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Sep 2012 16:42:03 -0000
Received: by iebc10 with SMTP id c10so4136496ieb.32
	for <xen-devel@lists.xen.org>; Thu, 06 Sep 2012 09:42: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;
	bh=XsqSJEmSdBXL5jOvLS4V9sQZxrSMzM+E4ffgeoUjlYE=;
	b=EHymXmNMhnTUB0jE+U8WMo01RuYm5xx3rzmM19flG6XNIS4IKF6xwg5awNvCJ6ApDP
	47CtGPMF8PvyZfvpTwznJJwapzXcTojLa7Y2efueV0JAu2XQfB/pC/dtKgqR3+6x5cKt
	HFqMLfDhqvkLaFlTHF/jydWHMC15tA9MksfOFsC0rWlzG4vTf8bJyz0mkwqU59mB2aFw
	FVAieJCo/RFfd00RV6s8P+eQcpTX4PF1IuC0Pu7FbNtUUNGHfkN35fhVnNA1W2G6yjfj
	sztZlo/GtXobH76N0JYw7MxcOPGqmRLmWg4U8J79d5S6X0ph0adymEzN2tmCRcgVwp5g
	CNTA==
MIME-Version: 1.0
Received: by 10.50.173.69 with SMTP id bi5mr3952886igc.37.1346949722135; Thu,
	06 Sep 2012 09:42:02 -0700 (PDT)
Received: by 10.64.28.203 with HTTP; Thu, 6 Sep 2012 09:42:02 -0700 (PDT)
In-Reply-To: <CAOvdn6WrNK1Jn_Y_P7C3AwX6ApVcgzacLA_x-u=xBQtebnuPxA@mail.gmail.com>
References: <CAOvdn6WwgBD-2yf1uu3m9-16=Tb5KUrybXf2KibtnxKbP7YtwA@mail.gmail.com>
	<CAOvdn6UBW-yTOMd3YSf5M9JiHLRivyaKL-qzcKG8epszqaKmGg@mail.gmail.com>
	<20120807163320.GC15053@phenom.dumpdata.com>
	<CAOvdn6XcRGKtJxGwJO8J+ZBJr89wfTLc1woW5rhtMM540H9h1w@mail.gmail.com>
	<CAOvdn6XUoSeGoo7X=AJ1kpDxZB9HZEv+TJ4v-=FHcyR4=CHK-w@mail.gmail.com>
	<502240F302000078000937A6@nat28.tlf.novell.com>
	<CAOvdn6WN3kxC8Bb9g6MpfLULu47EGSGCtajPc-SFeJ-8VSUQDQ@mail.gmail.com>
	<CAOvdn6Xk1inm1hU55i0phU2qvSWyJLNoyDdn43biBAY2OewPtw@mail.gmail.com>
	<5023F5400200007800093F4E@nat28.tlf.novell.com>
	<CAOvdn6U-f3C4U8xVPvDyRFkFFLkbfiCXg_n+9zgA9V5u+q5jfw@mail.gmail.com>
	<5023F8B80200007800093F8C@nat28.tlf.novell.com>
	<CAOvdn6XKHfete_+=Hkvt20G7_cJ-4i8+9j9YD30OxzQ16Ru-+g@mail.gmail.com>
	<5024CB720200007800094124@nat28.tlf.novell.com>
	<CAOvdn6VVJdhWVYa-gNVt3euE4AbGi1TijUCUd1wGzv0SCWEUYA@mail.gmail.com>
	<CAOvdn6USnG9Y4MNBhrDZmob0oJ8BgFfKTvFEhcKbXDxNmzfZ-Q@mail.gmail.com>
	<502B75BA0200007800094FD4@nat28.tlf.novell.com>
	<CAOvdn6Ww5oEj6Xg=XT4dWCYWUBuOdPqLz-CqNjz4HmCScE+==g@mail.gmail.com>
	<CAOvdn6Wsjds_dmZ0dwDTYmD-o-OqjBH5-b9mitAuUADE+A4_ag@mail.gmail.com>
	<502BB8FD02000078000951E0@nat28.tlf.novell.com>
	<CAOvdn6VD6bp13F-tvYdkBsj4hkhE7PTGZrapndtdHrDKeZqccg@mail.gmail.com>
	<502CCC0002000078000955C4@nat28.tlf.novell.com>
	<CAOvdn6VEuX7R2_wz74ZvCxMjC-=YUir9kP5sdxEVaKVspRUd_w@mail.gmail.com>
	<502CF0A8020000780009574E@nat28.tlf.novell.com>
	<CAOvdn6VsZvn_1TCWYeuyY5YuTcP8=miK2KwE4583nsj6Qjb_vg@mail.gmail.com>
	<504494FB0200007800098398@nat28.tlf.novell.com>
	<CAOvdn6UT13qvWbMyfZkWND03RoVKVSgb6wW4yqTUpuBYEX01Dg@mail.gmail.com>
	<5048958D02000078000993EB@nat28.tlf.novell.com>
	<CAOvdn6WrNK1Jn_Y_P7C3AwX6ApVcgzacLA_x-u=xBQtebnuPxA@mail.gmail.com>
Date: Thu, 6 Sep 2012 12:42:02 -0400
X-Google-Sender-Auth: mcZD6S0QeZ5h5FWwx9WoZSG1Ipc
Message-ID: <CAOvdn6U_Z=KdEo56nqe7jN54BwiesRJqDOz_VzVNpkWGfFRd2A@mail.gmail.com>
From: Ben Guthro <ben@guthro.net>
To: Jan Beulich <JBeulich@suse.com>
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>, john.baboval@citrix.com,
	Thomas Goetz <thomas.goetz@citrix.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen4.2 S3 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

Odd.
The behavior seems to change, when not running with serial output.

On this desktop system that worked OK, once I go back to not running
the console output over serial - things fail on resume.
It is uncertain at what point things stop working, though - as
networking is unavailable.

I'll continue to look into it, but will be traveling next week.



On Thu, Sep 6, 2012 at 7:48 AM, Ben Guthro <ben@guthro.net> wrote:
> Fantastic!
>
> Initial tests are very good, with this dma_msi_ack modification.
>
> I've been able to get past the ahci stall, and run through ~10 suspend
> / resume cycles with this fix.
> Additional tests are warranted, and I'll run through an automated
> sleep / wake script I have to make sure this fix holds over time.
>
> Thanks for this.
>
> Ben
>
> On Thu, Sep 6, 2012 at 6:22 AM, Jan Beulich <JBeulich@suse.com> wrote:
>>>>> On 04.09.12 at 14:27, Ben Guthro <ben@guthro.net> wrote:
>>> I've put the console log of this test run here:
>>> https://citrix.sharefile.com/d/sdc383e252fb41c5a
>>>
>>> (again, so as not to clog everyone's inbox)
>>>
>>> I have not yet gone through the log in its entirety yet, but thought I
>>> would first send it to you to see if you had something in particular
>>> you were looking for.
>>>
>>> The file name is console-S3-MSI.txt
>>
>> I think that nailed it: pci_restore_msi_state() passed a pointer
>> to the stored entry->msg to write_msi_msg(), but with interrupt
>> remapping enabled that function's call to
>> iommu_update_ire_from_msi() alters the passed in struct
>> msi_msg instance. As the stored value is used for nothing but
>> a subsequent (second) restore, a problem would only arise if
>> between the two saves to further writing of the stored entry
>> would occur (i.e. no intermediate call to set_msi_affinity()).
>>
>> Attached the advertised next version of the debugging patch
>> (printks - slightly altered - left in to catch eventual further
>> problems or to deal with my analysis being wrong; none of the
>> "bogus!" ones should now trigger anymore). If this works, I'd
>> be curious to see how much of your other workaround code
>> you could then remove without breaking things again.
>>
>> Jan
>>

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

From xen-devel-bounces@lists.xen.org Thu Sep 06 16:42:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 2012 16:42:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9f9b-00071q-5B; Thu, 06 Sep 2012 16:42:07 +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 1T9f9Z-00071M-QM
	for xen-devel@lists.xen.org; Thu, 06 Sep 2012 16:42:06 +0000
Received: from [85.158.143.35:48328] by server-1.bemta-4.messagelabs.com id
	20/DC-12504-D52D8405; Thu, 06 Sep 2012 16:42:05 +0000
X-Env-Sender: ben.guthro@gmail.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1346949722!13669463!1
X-Originating-IP: [209.85.223.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13831 invoked from network); 6 Sep 2012 16:42:03 -0000
Received: from mail-ie0-f173.google.com (HELO mail-ie0-f173.google.com)
	(209.85.223.173)
	by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Sep 2012 16:42:03 -0000
Received: by iebc10 with SMTP id c10so4136496ieb.32
	for <xen-devel@lists.xen.org>; Thu, 06 Sep 2012 09:42: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;
	bh=XsqSJEmSdBXL5jOvLS4V9sQZxrSMzM+E4ffgeoUjlYE=;
	b=EHymXmNMhnTUB0jE+U8WMo01RuYm5xx3rzmM19flG6XNIS4IKF6xwg5awNvCJ6ApDP
	47CtGPMF8PvyZfvpTwznJJwapzXcTojLa7Y2efueV0JAu2XQfB/pC/dtKgqR3+6x5cKt
	HFqMLfDhqvkLaFlTHF/jydWHMC15tA9MksfOFsC0rWlzG4vTf8bJyz0mkwqU59mB2aFw
	FVAieJCo/RFfd00RV6s8P+eQcpTX4PF1IuC0Pu7FbNtUUNGHfkN35fhVnNA1W2G6yjfj
	sztZlo/GtXobH76N0JYw7MxcOPGqmRLmWg4U8J79d5S6X0ph0adymEzN2tmCRcgVwp5g
	CNTA==
MIME-Version: 1.0
Received: by 10.50.173.69 with SMTP id bi5mr3952886igc.37.1346949722135; Thu,
	06 Sep 2012 09:42:02 -0700 (PDT)
Received: by 10.64.28.203 with HTTP; Thu, 6 Sep 2012 09:42:02 -0700 (PDT)
In-Reply-To: <CAOvdn6WrNK1Jn_Y_P7C3AwX6ApVcgzacLA_x-u=xBQtebnuPxA@mail.gmail.com>
References: <CAOvdn6WwgBD-2yf1uu3m9-16=Tb5KUrybXf2KibtnxKbP7YtwA@mail.gmail.com>
	<CAOvdn6UBW-yTOMd3YSf5M9JiHLRivyaKL-qzcKG8epszqaKmGg@mail.gmail.com>
	<20120807163320.GC15053@phenom.dumpdata.com>
	<CAOvdn6XcRGKtJxGwJO8J+ZBJr89wfTLc1woW5rhtMM540H9h1w@mail.gmail.com>
	<CAOvdn6XUoSeGoo7X=AJ1kpDxZB9HZEv+TJ4v-=FHcyR4=CHK-w@mail.gmail.com>
	<502240F302000078000937A6@nat28.tlf.novell.com>
	<CAOvdn6WN3kxC8Bb9g6MpfLULu47EGSGCtajPc-SFeJ-8VSUQDQ@mail.gmail.com>
	<CAOvdn6Xk1inm1hU55i0phU2qvSWyJLNoyDdn43biBAY2OewPtw@mail.gmail.com>
	<5023F5400200007800093F4E@nat28.tlf.novell.com>
	<CAOvdn6U-f3C4U8xVPvDyRFkFFLkbfiCXg_n+9zgA9V5u+q5jfw@mail.gmail.com>
	<5023F8B80200007800093F8C@nat28.tlf.novell.com>
	<CAOvdn6XKHfete_+=Hkvt20G7_cJ-4i8+9j9YD30OxzQ16Ru-+g@mail.gmail.com>
	<5024CB720200007800094124@nat28.tlf.novell.com>
	<CAOvdn6VVJdhWVYa-gNVt3euE4AbGi1TijUCUd1wGzv0SCWEUYA@mail.gmail.com>
	<CAOvdn6USnG9Y4MNBhrDZmob0oJ8BgFfKTvFEhcKbXDxNmzfZ-Q@mail.gmail.com>
	<502B75BA0200007800094FD4@nat28.tlf.novell.com>
	<CAOvdn6Ww5oEj6Xg=XT4dWCYWUBuOdPqLz-CqNjz4HmCScE+==g@mail.gmail.com>
	<CAOvdn6Wsjds_dmZ0dwDTYmD-o-OqjBH5-b9mitAuUADE+A4_ag@mail.gmail.com>
	<502BB8FD02000078000951E0@nat28.tlf.novell.com>
	<CAOvdn6VD6bp13F-tvYdkBsj4hkhE7PTGZrapndtdHrDKeZqccg@mail.gmail.com>
	<502CCC0002000078000955C4@nat28.tlf.novell.com>
	<CAOvdn6VEuX7R2_wz74ZvCxMjC-=YUir9kP5sdxEVaKVspRUd_w@mail.gmail.com>
	<502CF0A8020000780009574E@nat28.tlf.novell.com>
	<CAOvdn6VsZvn_1TCWYeuyY5YuTcP8=miK2KwE4583nsj6Qjb_vg@mail.gmail.com>
	<504494FB0200007800098398@nat28.tlf.novell.com>
	<CAOvdn6UT13qvWbMyfZkWND03RoVKVSgb6wW4yqTUpuBYEX01Dg@mail.gmail.com>
	<5048958D02000078000993EB@nat28.tlf.novell.com>
	<CAOvdn6WrNK1Jn_Y_P7C3AwX6ApVcgzacLA_x-u=xBQtebnuPxA@mail.gmail.com>
Date: Thu, 6 Sep 2012 12:42:02 -0400
X-Google-Sender-Auth: mcZD6S0QeZ5h5FWwx9WoZSG1Ipc
Message-ID: <CAOvdn6U_Z=KdEo56nqe7jN54BwiesRJqDOz_VzVNpkWGfFRd2A@mail.gmail.com>
From: Ben Guthro <ben@guthro.net>
To: Jan Beulich <JBeulich@suse.com>
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>, john.baboval@citrix.com,
	Thomas Goetz <thomas.goetz@citrix.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen4.2 S3 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

Odd.
The behavior seems to change, when not running with serial output.

On this desktop system that worked OK, once I go back to not running
the console output over serial - things fail on resume.
It is uncertain at what point things stop working, though - as
networking is unavailable.

I'll continue to look into it, but will be traveling next week.



On Thu, Sep 6, 2012 at 7:48 AM, Ben Guthro <ben@guthro.net> wrote:
> Fantastic!
>
> Initial tests are very good, with this dma_msi_ack modification.
>
> I've been able to get past the ahci stall, and run through ~10 suspend
> / resume cycles with this fix.
> Additional tests are warranted, and I'll run through an automated
> sleep / wake script I have to make sure this fix holds over time.
>
> Thanks for this.
>
> Ben
>
> On Thu, Sep 6, 2012 at 6:22 AM, Jan Beulich <JBeulich@suse.com> wrote:
>>>>> On 04.09.12 at 14:27, Ben Guthro <ben@guthro.net> wrote:
>>> I've put the console log of this test run here:
>>> https://citrix.sharefile.com/d/sdc383e252fb41c5a
>>>
>>> (again, so as not to clog everyone's inbox)
>>>
>>> I have not yet gone through the log in its entirety yet, but thought I
>>> would first send it to you to see if you had something in particular
>>> you were looking for.
>>>
>>> The file name is console-S3-MSI.txt
>>
>> I think that nailed it: pci_restore_msi_state() passed a pointer
>> to the stored entry->msg to write_msi_msg(), but with interrupt
>> remapping enabled that function's call to
>> iommu_update_ire_from_msi() alters the passed in struct
>> msi_msg instance. As the stored value is used for nothing but
>> a subsequent (second) restore, a problem would only arise if
>> between the two saves to further writing of the stored entry
>> would occur (i.e. no intermediate call to set_msi_affinity()).
>>
>> Attached the advertised next version of the debugging patch
>> (printks - slightly altered - left in to catch eventual further
>> problems or to deal with my analysis being wrong; none of the
>> "bogus!" ones should now trigger anymore). If this works, I'd
>> be curious to see how much of your other workaround code
>> you could then remove without breaking things again.
>>
>> Jan
>>

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

From xen-devel-bounces@lists.xen.org Thu Sep 06 16:46:10 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 2012 16:46:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9fDC-0007Hv-Vu; Thu, 06 Sep 2012 16:45: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 1T9fDB-0007He-WE
	for xen-devel@lists.xen.org; Thu, 06 Sep 2012 16:45:50 +0000
Received: from [85.158.139.83:64613] by server-11.bemta-5.messagelabs.com id
	E4/99-24658-D33D8405; Thu, 06 Sep 2012 16:45:49 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1346949948!28989298!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTE5NzY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11252 invoked from network); 6 Sep 2012 16:45:48 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Sep 2012 16:45:48 -0000
X-IronPort-AV: E=Sophos;i="4.80,380,1344211200"; d="scan'208";a="14392086"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Sep 2012 16:45: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.279.1; Thu, 6 Sep 2012
	17:45:12 +0100
Message-ID: <1346949911.10570.42.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Olaf Hering <olaf@aepfle.de>
Date: Thu, 6 Sep 2012 17:45:11 +0100
In-Reply-To: <20120906163900.GA26442@aepfle.de>
References: <20120906163900.GA26442@aepfle.de>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] creating _libxl_list.h is racy
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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-09-06 at 17:39 +0100, Olaf Hering wrote:
> There is apparently a race in creating _libxl_list.h,
> in xen-unstable 25821:19d367bf07b7:
[...]
> [  380s] 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.api-for-check.d  -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -fno-optimize-sibling-calls -fmessage-length=0 -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables -fasynchronous-unwind-tables -Werror -Wno-format-zero-length -Wmissing-declarations -Wno-declaration-after-statement -Wformat-nonliteral -I. -fPIC -pthread -I/usr/src/packages/BUILD/xen-4.2.25821/non-dbg/tools/libxl/../../tools/libxc -I/usr/src/packages/BUILD/xen-4.2.25821/non-dbg/tools/libxl/../../tools/include  -I/usr/src/packages/BUILD/xen-4.2.25821/non-dbg/tools/libxl/../../tools/libxl -I/usr/src/packages/BUILD/xen-4.2.25821/non-dbg/tools/libxl/../../tools/libxc -I/usr/src/packages/BUILD/xen-4.2.25821/non-dbg/tools/libxl/../../tools/include -I/usr/src/packages/BUILD/xen-4.2.25821/non-dbg/tools/libxl/../../tools/include -include /usr/src/packages/BUILD/xen-4.2.25821/non-dbg/tools/libxl/../../tools/config.h  -I/usr/src/packages/BUILD/xen-4.2.25821/non-dbg/tools/libxl/../../tools/libxc -I/usr/src/packages/BUILD/xen-4.2.25821/non-dbg/tools/libxl/../../tools/include   -c -E libxl.h  \
> [  380s] -DLIBXL_EXTERNAL_CALLERS_ONLY=LIBXL_EXTERNAL_CALLERS_ONLY \
> [  380s] >_libxl.api-for-check.new
> [..]
> [  380s] libxl.h:260:25: fatal error: _libxl_list.h: No such file or directory
> [  380s] compilation terminated.
> [  380s] make[3]: *** [_libxl.api-for-check] Error 1
[...]

I think this is the new api check rule. We have _libxl.api-for-check
which is created by:
_%.api-for-check: %.h
        $(CC) $(CPPFLAGS) $(CFLAGS) $(CFLAGS_$*.o) -c -E $< $(APPEND_CFLAGS) \
                -DLIBXL_EXTERNAL_CALLERS_ONLY=LIBXL_EXTERNAL_CALLERS_ONLY \
                >$@.new
        mv -f $@.new $@

so it depends on libxl.h which includes the autogenerated list stuff.
But there is no depends on _libxl_list.h which is in $(AUTOINCS). Could
fix by adding AUTOINCS here somewhere but is there any reason not to add

libxl.h: $(AUTOINCS)

?

Ian.



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

From xen-devel-bounces@lists.xen.org Thu Sep 06 16:46:10 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 2012 16:46:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9fDC-0007Hv-Vu; Thu, 06 Sep 2012 16:45: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 1T9fDB-0007He-WE
	for xen-devel@lists.xen.org; Thu, 06 Sep 2012 16:45:50 +0000
Received: from [85.158.139.83:64613] by server-11.bemta-5.messagelabs.com id
	E4/99-24658-D33D8405; Thu, 06 Sep 2012 16:45:49 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1346949948!28989298!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTE5NzY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11252 invoked from network); 6 Sep 2012 16:45:48 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Sep 2012 16:45:48 -0000
X-IronPort-AV: E=Sophos;i="4.80,380,1344211200"; d="scan'208";a="14392086"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Sep 2012 16:45: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.279.1; Thu, 6 Sep 2012
	17:45:12 +0100
Message-ID: <1346949911.10570.42.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Olaf Hering <olaf@aepfle.de>
Date: Thu, 6 Sep 2012 17:45:11 +0100
In-Reply-To: <20120906163900.GA26442@aepfle.de>
References: <20120906163900.GA26442@aepfle.de>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] creating _libxl_list.h is racy
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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-09-06 at 17:39 +0100, Olaf Hering wrote:
> There is apparently a race in creating _libxl_list.h,
> in xen-unstable 25821:19d367bf07b7:
[...]
> [  380s] 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.api-for-check.d  -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -fno-optimize-sibling-calls -fmessage-length=0 -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables -fasynchronous-unwind-tables -Werror -Wno-format-zero-length -Wmissing-declarations -Wno-declaration-after-statement -Wformat-nonliteral -I. -fPIC -pthread -I/usr/src/packages/BUILD/xen-4.2.25821/non-dbg/tools/libxl/../../tools/libxc -I/usr/src/packages/BUILD/xen-4.2.25821/non-dbg/tools/libxl/../../tools/include  -I/usr/src/packages/BUILD/xen-4.2.25821/non-dbg/tools/libxl/../../tools/libxl -I/usr/src/packages/BUILD/xen-4.2.25821/non-dbg/tools/libxl/../../tools/libxc -I/usr/src/packages/BUILD/xen-4.2.25821/non-dbg/tools/libxl/../../tools/include -I/usr/src/packages/BUILD/xen-4.2.25821/non-dbg/tools/libxl/../../tools/include -include /usr/src/packages/BUILD/xen-4.2.25821/non-dbg/tools/libxl/../../tools/config.h  -I/usr/src/packages/BUILD/xen-4.2.25821/non-dbg/tools/libxl/../../tools/libxc -I/usr/src/packages/BUILD/xen-4.2.25821/non-dbg/tools/libxl/../../tools/include   -c -E libxl.h  \
> [  380s] -DLIBXL_EXTERNAL_CALLERS_ONLY=LIBXL_EXTERNAL_CALLERS_ONLY \
> [  380s] >_libxl.api-for-check.new
> [..]
> [  380s] libxl.h:260:25: fatal error: _libxl_list.h: No such file or directory
> [  380s] compilation terminated.
> [  380s] make[3]: *** [_libxl.api-for-check] Error 1
[...]

I think this is the new api check rule. We have _libxl.api-for-check
which is created by:
_%.api-for-check: %.h
        $(CC) $(CPPFLAGS) $(CFLAGS) $(CFLAGS_$*.o) -c -E $< $(APPEND_CFLAGS) \
                -DLIBXL_EXTERNAL_CALLERS_ONLY=LIBXL_EXTERNAL_CALLERS_ONLY \
                >$@.new
        mv -f $@.new $@

so it depends on libxl.h which includes the autogenerated list stuff.
But there is no depends on _libxl_list.h which is in $(AUTOINCS). Could
fix by adding AUTOINCS here somewhere but is there any reason not to add

libxl.h: $(AUTOINCS)

?

Ian.



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

From xen-devel-bounces@lists.xen.org Thu Sep 06 16:46:56 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 2012 16: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 1T9fE2-0007M6-H2; Thu, 06 Sep 2012 16:46:42 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <linux@eikelenboom.it>) id 1T9fE0-0007Lp-Iw
	for xen-devel@lists.xen.org; Thu, 06 Sep 2012 16:46:40 +0000
Received: from [85.158.143.99:53278] by server-1.bemta-4.messagelabs.com id
	83/41-12504-F63D8405; Thu, 06 Sep 2012 16:46:39 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-11.tower-216.messagelabs.com!1346949999!21424873!1
X-Originating-IP: [188.40.164.121]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5748 invoked from network); 6 Sep 2012 16:46:39 -0000
Received: from static.121.164.40.188.clients.your-server.de (HELO
	smtp.eikelenboom.it) (188.40.164.121)
	by server-11.tower-216.messagelabs.com with AES256-SHA encrypted SMTP;
	6 Sep 2012 16:46:39 -0000
Received: from 128-64-ftth.onsneteindhoven.nl ([88.159.64.128]:54383
	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 1T9fE0-0000GS-9B; Thu, 06 Sep 2012 18:46:40 +0200
Date: Thu, 6 Sep 2012 18:46:34 +0200
From: Sander Eikelenboom <linux@eikelenboom.it>
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <1557575235.20120906184634@eikelenboom.it>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
In-Reply-To: <20120906105746.GA3668@phenom.dumpdata.com>
References: <1136369816.20120904183757@eikelenboom.it>
	<20120904163347.GH23361@phenom.dumpdata.com>
	<143844933.20120904191941@eikelenboom.it>
	<CAOvdn6U_yHgtZwv9MWazdLbd3NLq3pwGXnZY5sL2UVBhV_FUoQ@mail.gmail.com>
	<1813712325.20120904213459@eikelenboom.it>
	<048EAD622912254A9DEA24C1734613C18C864C3C5D@FTLPMAILBOX02.citrite.net>
	<20120905140600.GA5844@phenom.dumpdata.com>
	<1014998302.20120905163848@eikelenboom.it>
	<20120905201933.GA27814@phenom.dumpdata.com>
	<679529047.20120906005220@eikelenboom.it>
	<20120906105746.GA3668@phenom.dumpdata.com>
MIME-Version: 1.0
Cc: Robert Phillips <robert.phillips@citrix.com>, Ben Guthro <ben@guthro.net>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] dom0 linux 3.6.0-rc4,
	crash due to ballooning althoug dom0_mem=X, max:X 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


Thursday, September 6, 2012, 12:57:46 PM, you wrote:

>> > About nine of them deal with dom0_mem=max ballooning up right, so if you
>> > ignore those:
>> 
>> > b9e0d95 xen: mark local pages as FOREIGN in the m2p_override
>> > d79d595 xen: Add selfballoning memory reservation tunable.
>> > f62805f xen: enter/exit lazy_mmu_mode around m2p_override calls
>> 
>> > Try reverting any of those.
>> 
>> Ah i missed your email since my hostingprovider was down :-(
>> But anyway done a git bisect in the mean time that leads to:
>> 
>> [f62805f1f30a40e354bd036b4cb799863a39be4b] xen: enter/exit lazy_mmu_mode around m2p_override calls

> OK. Hmm.that will take a bit of thinking to fix.
>> 
>> 
>> > And if nothing works there then we can try to revert the ones that
>> > deal with 'dom0_mem=max:XX'..
>> 
>> > I also need to be able to reproduce this. You said you can only reproduce this
>> > on your Intel box - is this a fast Intel machine? It also looks like you only
>> > have 2GB in the machine - and reserve 1GB to the dom0.
>> 
>> Machine is a quad core q9400 @ 2.66mhz, not very fast .. not very slow either

> That is a fast machine. I was thinking you had a Core2 Solo or a Pentium IV Prescott.

>> 
>> > If you manually (so don't start the guest), balloon down - say to 512MB and then launch
>> > a guest do you see this problem?
>> 
>> 
>> Should i use
>> 
>> xl  mem-max domain-id mem
>> 
>> or
>> 
>> xl  mem-set domain-id mem

> The later.

Ok tested that as well:
   - After "xl  mem-set 0 768M", xentop reports the new mem values (free and for dom0) correctly, nothing else happens.
   - After a small wait, i tried to start a guest and it crashes dom0 with the ballooning as before.

>> 
>> for that ?
>> 
>> 
>> Perhaps a silly question, but why is it ballooning anyway ?
>> I have set dom0's memory and there is enough left to create the domain ... or at least there should be ...

> There was a bug in xl that would autoballoon. You can turn it off using some xl.conf file.

>> 
>> --
>> Sander



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

From xen-devel-bounces@lists.xen.org Thu Sep 06 16:46:56 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 2012 16: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 1T9fE2-0007M6-H2; Thu, 06 Sep 2012 16:46:42 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <linux@eikelenboom.it>) id 1T9fE0-0007Lp-Iw
	for xen-devel@lists.xen.org; Thu, 06 Sep 2012 16:46:40 +0000
Received: from [85.158.143.99:53278] by server-1.bemta-4.messagelabs.com id
	83/41-12504-F63D8405; Thu, 06 Sep 2012 16:46:39 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-11.tower-216.messagelabs.com!1346949999!21424873!1
X-Originating-IP: [188.40.164.121]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5748 invoked from network); 6 Sep 2012 16:46:39 -0000
Received: from static.121.164.40.188.clients.your-server.de (HELO
	smtp.eikelenboom.it) (188.40.164.121)
	by server-11.tower-216.messagelabs.com with AES256-SHA encrypted SMTP;
	6 Sep 2012 16:46:39 -0000
Received: from 128-64-ftth.onsneteindhoven.nl ([88.159.64.128]:54383
	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 1T9fE0-0000GS-9B; Thu, 06 Sep 2012 18:46:40 +0200
Date: Thu, 6 Sep 2012 18:46:34 +0200
From: Sander Eikelenboom <linux@eikelenboom.it>
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <1557575235.20120906184634@eikelenboom.it>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
In-Reply-To: <20120906105746.GA3668@phenom.dumpdata.com>
References: <1136369816.20120904183757@eikelenboom.it>
	<20120904163347.GH23361@phenom.dumpdata.com>
	<143844933.20120904191941@eikelenboom.it>
	<CAOvdn6U_yHgtZwv9MWazdLbd3NLq3pwGXnZY5sL2UVBhV_FUoQ@mail.gmail.com>
	<1813712325.20120904213459@eikelenboom.it>
	<048EAD622912254A9DEA24C1734613C18C864C3C5D@FTLPMAILBOX02.citrite.net>
	<20120905140600.GA5844@phenom.dumpdata.com>
	<1014998302.20120905163848@eikelenboom.it>
	<20120905201933.GA27814@phenom.dumpdata.com>
	<679529047.20120906005220@eikelenboom.it>
	<20120906105746.GA3668@phenom.dumpdata.com>
MIME-Version: 1.0
Cc: Robert Phillips <robert.phillips@citrix.com>, Ben Guthro <ben@guthro.net>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] dom0 linux 3.6.0-rc4,
	crash due to ballooning althoug dom0_mem=X, max:X 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


Thursday, September 6, 2012, 12:57:46 PM, you wrote:

>> > About nine of them deal with dom0_mem=max ballooning up right, so if you
>> > ignore those:
>> 
>> > b9e0d95 xen: mark local pages as FOREIGN in the m2p_override
>> > d79d595 xen: Add selfballoning memory reservation tunable.
>> > f62805f xen: enter/exit lazy_mmu_mode around m2p_override calls
>> 
>> > Try reverting any of those.
>> 
>> Ah i missed your email since my hostingprovider was down :-(
>> But anyway done a git bisect in the mean time that leads to:
>> 
>> [f62805f1f30a40e354bd036b4cb799863a39be4b] xen: enter/exit lazy_mmu_mode around m2p_override calls

> OK. Hmm.that will take a bit of thinking to fix.
>> 
>> 
>> > And if nothing works there then we can try to revert the ones that
>> > deal with 'dom0_mem=max:XX'..
>> 
>> > I also need to be able to reproduce this. You said you can only reproduce this
>> > on your Intel box - is this a fast Intel machine? It also looks like you only
>> > have 2GB in the machine - and reserve 1GB to the dom0.
>> 
>> Machine is a quad core q9400 @ 2.66mhz, not very fast .. not very slow either

> That is a fast machine. I was thinking you had a Core2 Solo or a Pentium IV Prescott.

>> 
>> > If you manually (so don't start the guest), balloon down - say to 512MB and then launch
>> > a guest do you see this problem?
>> 
>> 
>> Should i use
>> 
>> xl  mem-max domain-id mem
>> 
>> or
>> 
>> xl  mem-set domain-id mem

> The later.

Ok tested that as well:
   - After "xl  mem-set 0 768M", xentop reports the new mem values (free and for dom0) correctly, nothing else happens.
   - After a small wait, i tried to start a guest and it crashes dom0 with the ballooning as before.

>> 
>> for that ?
>> 
>> 
>> Perhaps a silly question, but why is it ballooning anyway ?
>> I have set dom0's memory and there is enough left to create the domain ... or at least there should be ...

> There was a bug in xl that would autoballoon. You can turn it off using some xl.conf file.

>> 
>> --
>> Sander



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

From xen-devel-bounces@lists.xen.org Thu Sep 06 16:49:55 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 2012 16:49:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9fGw-0007Xk-3q; Thu, 06 Sep 2012 16:49:42 +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 1T9fGu-0007XH-I0
	for xen-devel@lists.xensource.com; Thu, 06 Sep 2012 16:49:40 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1346950172!9912513!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTE5NzY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6905 invoked from network); 6 Sep 2012 16:49:32 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Sep 2012 16:49:32 -0000
X-IronPort-AV: E=Sophos;i="4.80,380,1344211200"; d="scan'208";a="14392163"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Sep 2012 16:49:32 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Thu, 6 Sep 2012
	17:49:31 +0100
Message-ID: <1346950171.10570.45.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Sander Eikelenboom <linux@eikelenboom.it>
Date: Thu, 6 Sep 2012 17:49:31 +0100
In-Reply-To: <1718522527.20120906184051@eikelenboom.it>
References: <c6d5f62c345b6b41b9ff.1346942187@xentest.example.org>
	<887956845.20120906180206@eikelenboom.it>
	<1346949137.10570.37.camel@dagon.hellion.org.uk>
	<1718522527.20120906184051@eikelenboom.it>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-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] xl: Introduce shutdown xm compatibility
 option -a to shutdown all domains
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-09-06 at 17:40 +0100, Sander Eikelenboom wrote:
> Thursday, September 6, 2012, 6:32:17 PM, you wrote:
> 
> > On Thu, 2012-09-06 at 17:02 +0100, Sander Eikelenboom wrote:
> >> Thursday, September 6, 2012, 4:36:27 PM, you wrote:
> >> 
> >> > xl: Introduce shutdown xm compatibility option -a to shutdown all domains
> >> 
> >> > v2: address review comments.
> >> >     - Change shutdown_domain to take domid instead of domname
> >> >     - Docs: Make it more clear -a only shuts down GUEST domains
> >> 
> >> > Signed-off-by: Sander Eikelenboom <linux@eikelenboom.it>
> >> 
> >> > diff -r 9dc729b75595 -r c6d5f62c345b docs/man/xl.pod.1
> >> > --- a/docs/man/xl.pod.1       Mon Sep 03 11:22:02 2012 +0100
> >> > +++ b/docs/man/xl.pod.1       Thu Sep 06 16:35:04 2012 +0200
> >> > @@ -527,7 +527,7 @@ List specifically for that domain. Other
> >> >  
> >> >  =back
> >> >  
> >> > -=item B<shutdown> [I<OPTIONS>] I<domain-id>
> >> > +=item B<shutdown> [I<OPTIONS>] I<-a|domain-id>
> >> >  
> >> >  Gracefully shuts down a domain.  This coordinates with the domain OS
> >> >  to perform graceful shutdown, so there is no guarantee that it will
> >> > @@ -550,6 +550,10 @@ B<OPTIONS>
> >> >  
> >> >  =over 4
> >> >  
> >> > +=item B<-a>
> >> > +
> >> > +-a  Shutdown all guest domains.  Often used when doing a complete shutdown of a Xen system.
> >> > +
> >> >  =item B<-w>
> >> >  
> >> >  Wait for the domain to complete shutdown before returning.
> >> > diff -r 9dc729b75595 -r c6d5f62c345b tools/libxl/xl_cmdimpl.c
> >> > --- a/tools/libxl/xl_cmdimpl.c  Mon Sep 03 11:22:02 2012 +0100
> >> > +++ b/tools/libxl/xl_cmdimpl.c  Thu Sep 06 16:35:04 2012 +0200
> >> > @@ -2683,12 +2683,11 @@ static void destroy_domain(const char *p
> >> >      if (rc) { fprintf(stderr,"destroy failed (rc=%d)\n",rc); exit(-1); }
> >> >  }
> >> >  
> >> > -static void shutdown_domain(const char *p, int wait, int fallback_trigger)
> >> > +static void shutdown_domain(uint32_t domid, int wait, int fallback_trigger)
> >> >  {
> >> >      int rc;
> >> >      libxl_event *event;
> >> >  
> >> > -    find_domain(p);
> >> >      rc=libxl_domain_shutdown(ctx, domid);
> >> >      if (rc == ERROR_NOPARAVIRT) {
> >> >          if (fallback_trigger) {
> >> 
> >> Hi Ian,
> >> 
> >> Done some more testing and this seems to lead to the following error when issueing both -a and -w:
> >> 
> >> xentest:/usr/src/xen-unstable.hg# xl shutdown -a -w
> >> libxl: error: libxl_json.c:773:libxl__object_to_json: unable to convert libxl_event to JSON representation. YAJL error code 1: keys must be strings
> >> INTERNAL PROBLEM - ignoring unexpected event for domain 11 (expected -1): event=(null)
> >> libxl: error: libxl_json.c:773:libxl__object_to_json: unable to convert libxl_event to JSON representation. YAJL error code 1: keys must be strings
> >> INTERNAL PROBLEM - ignoring unexpected event for domain 11 (expected -1): event=(null)
> >> 
> >> If i only use -w and specify a specific domain, it works without a problem.
> >> 
> >> Any ideas ?
> 
> > Just a guess but we have some issues in xl with local variables
> > shadowing global ones (which happens with domid in particular). This is
> > something we plan to look at in 4.3 (by enable -Wshadow and cleaning up
> > the mess).
> 
> > I think what is happening is that shutdown_domain now takes a uint32_t
> > domid, which shadows the global domid but then we call domain_wait_event
> > which uses the global one. So when you use -a you never set the global
> > one because you don't need to call find_domain. Quite how this results
> > in the message above I'm not too sure (Ian J may have some insight to
> > the events subsystem)
> 
> > It's all rather horrid, I think for now the best thing might be for
> > shutdown_domain to look like:
> 
> > static void shutdown_domain(uint32_t xdomid, int wait, int fallback_trigger)
> > {
> >     [... vars...]
> 
> >     domid = xdomid
> 
> >     ...
> 
> > Yes, this is horrible...
> 
> > Ian.
> 
> I was quite puzzled that global variables were used, took me quite a while searching how domid could be available without being explicitly set.
> I always thought of global variables as being something pretty undesired...

Me too, and here we see why ;-)

> Is naming it "xdomid" ok ? Or would be naming it uint32_t domain_id be better ?

There's not much in the way of precedent. I see a tdomid but I'm not
sure what the t is for.

This'll all have to get reworked when we come to enable Wshadow anyway
so I don't think the name here matters too much.

The other option would be to remove the domid parameter altogether and
do domid = info[i].domid in the caller. That's pretty nasty 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 Sep 06 16:49:55 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 2012 16:49:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9fGw-0007Xk-3q; Thu, 06 Sep 2012 16:49:42 +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 1T9fGu-0007XH-I0
	for xen-devel@lists.xensource.com; Thu, 06 Sep 2012 16:49:40 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1346950172!9912513!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTE5NzY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6905 invoked from network); 6 Sep 2012 16:49:32 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Sep 2012 16:49:32 -0000
X-IronPort-AV: E=Sophos;i="4.80,380,1344211200"; d="scan'208";a="14392163"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Sep 2012 16:49:32 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Thu, 6 Sep 2012
	17:49:31 +0100
Message-ID: <1346950171.10570.45.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Sander Eikelenboom <linux@eikelenboom.it>
Date: Thu, 6 Sep 2012 17:49:31 +0100
In-Reply-To: <1718522527.20120906184051@eikelenboom.it>
References: <c6d5f62c345b6b41b9ff.1346942187@xentest.example.org>
	<887956845.20120906180206@eikelenboom.it>
	<1346949137.10570.37.camel@dagon.hellion.org.uk>
	<1718522527.20120906184051@eikelenboom.it>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-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] xl: Introduce shutdown xm compatibility
 option -a to shutdown all domains
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-09-06 at 17:40 +0100, Sander Eikelenboom wrote:
> Thursday, September 6, 2012, 6:32:17 PM, you wrote:
> 
> > On Thu, 2012-09-06 at 17:02 +0100, Sander Eikelenboom wrote:
> >> Thursday, September 6, 2012, 4:36:27 PM, you wrote:
> >> 
> >> > xl: Introduce shutdown xm compatibility option -a to shutdown all domains
> >> 
> >> > v2: address review comments.
> >> >     - Change shutdown_domain to take domid instead of domname
> >> >     - Docs: Make it more clear -a only shuts down GUEST domains
> >> 
> >> > Signed-off-by: Sander Eikelenboom <linux@eikelenboom.it>
> >> 
> >> > diff -r 9dc729b75595 -r c6d5f62c345b docs/man/xl.pod.1
> >> > --- a/docs/man/xl.pod.1       Mon Sep 03 11:22:02 2012 +0100
> >> > +++ b/docs/man/xl.pod.1       Thu Sep 06 16:35:04 2012 +0200
> >> > @@ -527,7 +527,7 @@ List specifically for that domain. Other
> >> >  
> >> >  =back
> >> >  
> >> > -=item B<shutdown> [I<OPTIONS>] I<domain-id>
> >> > +=item B<shutdown> [I<OPTIONS>] I<-a|domain-id>
> >> >  
> >> >  Gracefully shuts down a domain.  This coordinates with the domain OS
> >> >  to perform graceful shutdown, so there is no guarantee that it will
> >> > @@ -550,6 +550,10 @@ B<OPTIONS>
> >> >  
> >> >  =over 4
> >> >  
> >> > +=item B<-a>
> >> > +
> >> > +-a  Shutdown all guest domains.  Often used when doing a complete shutdown of a Xen system.
> >> > +
> >> >  =item B<-w>
> >> >  
> >> >  Wait for the domain to complete shutdown before returning.
> >> > diff -r 9dc729b75595 -r c6d5f62c345b tools/libxl/xl_cmdimpl.c
> >> > --- a/tools/libxl/xl_cmdimpl.c  Mon Sep 03 11:22:02 2012 +0100
> >> > +++ b/tools/libxl/xl_cmdimpl.c  Thu Sep 06 16:35:04 2012 +0200
> >> > @@ -2683,12 +2683,11 @@ static void destroy_domain(const char *p
> >> >      if (rc) { fprintf(stderr,"destroy failed (rc=%d)\n",rc); exit(-1); }
> >> >  }
> >> >  
> >> > -static void shutdown_domain(const char *p, int wait, int fallback_trigger)
> >> > +static void shutdown_domain(uint32_t domid, int wait, int fallback_trigger)
> >> >  {
> >> >      int rc;
> >> >      libxl_event *event;
> >> >  
> >> > -    find_domain(p);
> >> >      rc=libxl_domain_shutdown(ctx, domid);
> >> >      if (rc == ERROR_NOPARAVIRT) {
> >> >          if (fallback_trigger) {
> >> 
> >> Hi Ian,
> >> 
> >> Done some more testing and this seems to lead to the following error when issueing both -a and -w:
> >> 
> >> xentest:/usr/src/xen-unstable.hg# xl shutdown -a -w
> >> libxl: error: libxl_json.c:773:libxl__object_to_json: unable to convert libxl_event to JSON representation. YAJL error code 1: keys must be strings
> >> INTERNAL PROBLEM - ignoring unexpected event for domain 11 (expected -1): event=(null)
> >> libxl: error: libxl_json.c:773:libxl__object_to_json: unable to convert libxl_event to JSON representation. YAJL error code 1: keys must be strings
> >> INTERNAL PROBLEM - ignoring unexpected event for domain 11 (expected -1): event=(null)
> >> 
> >> If i only use -w and specify a specific domain, it works without a problem.
> >> 
> >> Any ideas ?
> 
> > Just a guess but we have some issues in xl with local variables
> > shadowing global ones (which happens with domid in particular). This is
> > something we plan to look at in 4.3 (by enable -Wshadow and cleaning up
> > the mess).
> 
> > I think what is happening is that shutdown_domain now takes a uint32_t
> > domid, which shadows the global domid but then we call domain_wait_event
> > which uses the global one. So when you use -a you never set the global
> > one because you don't need to call find_domain. Quite how this results
> > in the message above I'm not too sure (Ian J may have some insight to
> > the events subsystem)
> 
> > It's all rather horrid, I think for now the best thing might be for
> > shutdown_domain to look like:
> 
> > static void shutdown_domain(uint32_t xdomid, int wait, int fallback_trigger)
> > {
> >     [... vars...]
> 
> >     domid = xdomid
> 
> >     ...
> 
> > Yes, this is horrible...
> 
> > Ian.
> 
> I was quite puzzled that global variables were used, took me quite a while searching how domid could be available without being explicitly set.
> I always thought of global variables as being something pretty undesired...

Me too, and here we see why ;-)

> Is naming it "xdomid" ok ? Or would be naming it uint32_t domain_id be better ?

There's not much in the way of precedent. I see a tdomid but I'm not
sure what the t is for.

This'll all have to get reworked when we come to enable Wshadow anyway
so I don't think the name here matters too much.

The other option would be to remove the domid parameter altogether and
do domid = info[i].domid in the caller. That's pretty nasty 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 Sep 06 16:55:45 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 2012 16:55:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9fMZ-0007kE-Ts; Thu, 06 Sep 2012 16:55:31 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1T9fMZ-0007k9-4d
	for xen-devel@lists.xen.org; Thu, 06 Sep 2012 16:55:31 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-4.tower-27.messagelabs.com!1346950524!9354738!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiA0MTgxNzk=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiA0MTgxNzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11172 invoked from network); 6 Sep 2012 16:55:24 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-4.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 6 Sep 2012 16:55:24 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/lk2c7pE3Rh
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-090-217.pools.arcor-ip.net [84.57.90.217])
	by smtp.strato.de (jorabe mo39) (RZmta 30.14 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id q07454o86FgrlZ ;
	Thu, 6 Sep 2012 18:55:24 +0200 (CEST)
Received: by probook.site (Postfix, from userid 1000)
	id 72AE4183AD; Thu,  6 Sep 2012 18:55:23 +0200 (CEST)
Date: Thu, 6 Sep 2012 18:55:23 +0200
From: Olaf Hering <olaf@aepfle.de>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120906165523.GA26940@aepfle.de>
References: <20120906163900.GA26442@aepfle.de>
	<1346949911.10570.42.camel@dagon.hellion.org.uk>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1346949911.10570.42.camel@dagon.hellion.org.uk>
User-Agent: Mutt/1.5.21.rev5555 (2012-07-20)
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] creating _libxl_list.h is racy
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Sep 06, Ian Campbell wrote:

> But there is no depends on _libxl_list.h which is in $(AUTOINCS). Could
> fix by adding AUTOINCS here somewhere but is there any reason not to add
> 
> libxl.h: $(AUTOINCS)

There is already a libxl.h: _libxl_types.h, perhaps _libxl_list.h should
be added here as well.

Olaf

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

From xen-devel-bounces@lists.xen.org Thu Sep 06 16:55:45 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 2012 16:55:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9fMZ-0007kE-Ts; Thu, 06 Sep 2012 16:55:31 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1T9fMZ-0007k9-4d
	for xen-devel@lists.xen.org; Thu, 06 Sep 2012 16:55:31 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-4.tower-27.messagelabs.com!1346950524!9354738!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiA0MTgxNzk=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiA0MTgxNzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11172 invoked from network); 6 Sep 2012 16:55:24 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-4.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 6 Sep 2012 16:55:24 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/lk2c7pE3Rh
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-090-217.pools.arcor-ip.net [84.57.90.217])
	by smtp.strato.de (jorabe mo39) (RZmta 30.14 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id q07454o86FgrlZ ;
	Thu, 6 Sep 2012 18:55:24 +0200 (CEST)
Received: by probook.site (Postfix, from userid 1000)
	id 72AE4183AD; Thu,  6 Sep 2012 18:55:23 +0200 (CEST)
Date: Thu, 6 Sep 2012 18:55:23 +0200
From: Olaf Hering <olaf@aepfle.de>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120906165523.GA26940@aepfle.de>
References: <20120906163900.GA26442@aepfle.de>
	<1346949911.10570.42.camel@dagon.hellion.org.uk>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1346949911.10570.42.camel@dagon.hellion.org.uk>
User-Agent: Mutt/1.5.21.rev5555 (2012-07-20)
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] creating _libxl_list.h is racy
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Sep 06, Ian Campbell wrote:

> But there is no depends on _libxl_list.h which is in $(AUTOINCS). Could
> fix by adding AUTOINCS here somewhere but is there any reason not to add
> 
> libxl.h: $(AUTOINCS)

There is already a libxl.h: _libxl_types.h, perhaps _libxl_list.h should
be added here as well.

Olaf

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

From xen-devel-bounces@lists.xen.org Thu Sep 06 16:57:24 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 2012 16:57:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9fOA-0007ot-FO; Thu, 06 Sep 2012 16:57:10 +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 1T9fO9-0007on-D2
	for xen-devel@lists.xen.org; Thu, 06 Sep 2012 16:57:09 +0000
Received: from [85.158.139.83:17315] by server-11.bemta-5.messagelabs.com id
	FC/5D-24658-4E5D8405; Thu, 06 Sep 2012 16:57:08 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-12.tower-182.messagelabs.com!1346950627!28838547!1
X-Originating-IP: [81.169.146.162]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAzOTk2MTg=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAzOTk2MTg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1881 invoked from network); 6 Sep 2012 16:57:08 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162)
	by server-12.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 6 Sep 2012 16:57:08 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/lk2c7pE3Rh
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-090-217.pools.arcor-ip.net [84.57.90.217])
	by smtp.strato.de (joses mo46) (RZmta 30.14 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id D01cb6o86Fk558 ;
	Thu, 6 Sep 2012 18:57:07 +0200 (CEST)
Received: by probook.site (Postfix, from userid 1000)
	id 1E3FA183AD; Thu,  6 Sep 2012 18:57:07 +0200 (CEST)
Date: Thu, 6 Sep 2012 18:57:07 +0200
From: Olaf Hering <olaf@aepfle.de>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120906165706.GB26940@aepfle.de>
References: <20120906163900.GA26442@aepfle.de>
	<1346949911.10570.42.camel@dagon.hellion.org.uk>
	<20120906165523.GA26940@aepfle.de>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120906165523.GA26940@aepfle.de>
User-Agent: Mutt/1.5.21.rev5555 (2012-07-20)
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] creating _libxl_list.h is racy
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Sep 06, Olaf Hering wrote:

> On Thu, Sep 06, Ian Campbell wrote:
> 
> > But there is no depends on _libxl_list.h which is in $(AUTOINCS). Could
> > fix by adding AUTOINCS here somewhere but is there any reason not to add
> > 
> > libxl.h: $(AUTOINCS)
> 
> There is already a libxl.h: _libxl_types.h, perhaps _libxl_list.h should
> be added here as well.

And libxl.h includes also libxl_event.h, so it should depend on that
file als well I think.

Olaf

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

From xen-devel-bounces@lists.xen.org Thu Sep 06 16:57:24 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 2012 16:57:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9fOA-0007ot-FO; Thu, 06 Sep 2012 16:57:10 +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 1T9fO9-0007on-D2
	for xen-devel@lists.xen.org; Thu, 06 Sep 2012 16:57:09 +0000
Received: from [85.158.139.83:17315] by server-11.bemta-5.messagelabs.com id
	FC/5D-24658-4E5D8405; Thu, 06 Sep 2012 16:57:08 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-12.tower-182.messagelabs.com!1346950627!28838547!1
X-Originating-IP: [81.169.146.162]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAzOTk2MTg=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAzOTk2MTg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1881 invoked from network); 6 Sep 2012 16:57:08 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162)
	by server-12.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 6 Sep 2012 16:57:08 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/lk2c7pE3Rh
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-090-217.pools.arcor-ip.net [84.57.90.217])
	by smtp.strato.de (joses mo46) (RZmta 30.14 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id D01cb6o86Fk558 ;
	Thu, 6 Sep 2012 18:57:07 +0200 (CEST)
Received: by probook.site (Postfix, from userid 1000)
	id 1E3FA183AD; Thu,  6 Sep 2012 18:57:07 +0200 (CEST)
Date: Thu, 6 Sep 2012 18:57:07 +0200
From: Olaf Hering <olaf@aepfle.de>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120906165706.GB26940@aepfle.de>
References: <20120906163900.GA26442@aepfle.de>
	<1346949911.10570.42.camel@dagon.hellion.org.uk>
	<20120906165523.GA26940@aepfle.de>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120906165523.GA26940@aepfle.de>
User-Agent: Mutt/1.5.21.rev5555 (2012-07-20)
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] creating _libxl_list.h is racy
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Sep 06, Olaf Hering wrote:

> On Thu, Sep 06, Ian Campbell wrote:
> 
> > But there is no depends on _libxl_list.h which is in $(AUTOINCS). Could
> > fix by adding AUTOINCS here somewhere but is there any reason not to add
> > 
> > libxl.h: $(AUTOINCS)
> 
> There is already a libxl.h: _libxl_types.h, perhaps _libxl_list.h should
> be added here as well.

And libxl.h includes also libxl_event.h, so it should depend on that
file als well I think.

Olaf

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

From xen-devel-bounces@lists.xen.org Thu Sep 06 17:15:16 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 2012 17:15:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9ffS-0000P2-FZ; Thu, 06 Sep 2012 17:15:02 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1T9ffR-0000Ou-A2
	for xen-devel@lists.xen.org; Thu, 06 Sep 2012 17:15:01 +0000
Received: from [85.158.139.83:6730] by server-1.bemta-5.messagelabs.com id
	14/4D-32692-41AD8405; Thu, 06 Sep 2012 17:15:00 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-16.tower-182.messagelabs.com!1346951699!21665562!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiA0MTgxNzk=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiA0MTgxNzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29433 invoked from network); 6 Sep 2012 17:14:59 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-16.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 6 Sep 2012 17:14:59 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/lk2c7pE3Rh
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-090-217.pools.arcor-ip.net [84.57.90.217])
	by smtp.strato.de (jorabe mo1) (RZmta 30.14 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id e06b6co86GFwdo
	for <xen-devel@lists.xen.org>; Thu, 6 Sep 2012 19:14:59 +0200 (CEST)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id D22B4183A5
	for <xen-devel@lists.xen.org>; Thu,  6 Sep 2012 19:14:58 +0200 (CEST)
MIME-Version: 1.0
X-Mercurial-Node: cc71fe7029b27cb95d268b99e136c445903af927
Message-Id: <cc71fe7029b27cb95d26.1346951697@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Thu, 06 Sep 2012 19:14:57 +0200
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH] libxl: add missing dependencies of libxl.h
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

# HG changeset patch
# User Olaf Hering <olaf@aepfle.de>
# Date 1346951410 -7200
# Node ID cc71fe7029b27cb95d268b99e136c445903af927
# Parent  8a2eef481d3ab3ca5692dd0083c95cf314fe1da3
libxl: add missing dependencies of libxl.h

libxl.h includes generated files, but the Makefile lists no dependency on
these files. As a result compilation may fail like this:

[  379s] make -C libxl install
[  379s] make[3]: Entering directory `/usr/src/packages/BUILD/xen-4.2.25821/non-dbg/tools/libxl'
[  379s] /usr/bin/perl /usr/src/packages/BUILD/xen-4.2.25821/non-dbg/tools/libxl/../../tools/include/xen-external/bsd-sys-queue-h-seddery /usr/src/packages/BUILD/xen-4.2.25821/non-dbg/tools/libxl/../../tools/include/xen-external/bsd-sys-queue.h --prefix=libxl >_libxl_list.h.new
...
[  380s] 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.api-for-check.d  -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -fno-optimize-sibling-calls -fmessage-length=0 -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables -fasynchronous-unwind-tables -Werror -Wno-format-zero-length -Wmissing-declarations -Wno-declaration-after-statement -Wformat-nonliteral -I. -fPIC -pthread -I/usr/src/packages/BUILD/xen-4.2.25821/non-dbg/tools/libxl/../../tools/libxc -I/usr/src/packages/BUILD/xen-4.2.25821/non-dbg/tools/libxl/../../tools/include  -I/usr/src/packages/BUILD/xen-4.2.25821/non-dbg/tools/libxl/../../tools/libxl -I/usr/src/packages/BUILD/xen-4.2.25821/non-dbg/tools/libxl/../../tools/libxc -I/usr/src/packages/BUILD/xen-4.2.25821/non-dbg/tools/libxl/../../tools/include -I/usr/src/packages/BUILD/xen-4.2.25821/non-dbg/tools/libxl/../../tools/include -include /usr/src/packages/BUILD/xen-4.2.25821/non-dbg/tools/libxl/../../tools/config.h  -I/usr/src/packages/BUILD/xen-4.2.25821/non-dbg/tools/libxl/../../tools/libxc -I/usr/src/packages/BUILD/xen-4.2.25821/non-dbg/tools/libxl/../../tools/include   -c -E libxl.h  \
[  380s] -DLIBXL_EXTERNAL_CALLERS_ONLY=LIBXL_EXTERNAL_CALLERS_ONLY \
[  380s] >_libxl.api-for-check.new
...
[  380s] libxl.h:260:25: fatal error: _libxl_list.h: No such file or directory
[  380s] compilation terminated.
[  380s] make[3]: *** [_libxl.api-for-check] Error 1
[  381s] if ! cmp -s _libxl_list.h.new _libxl_list.h; then mv -f _libxl_list.h.new _libxl_list.h; else rm -f _libxl_list.h.new; fi


Fix this be extending the existing libxl.h dependency with the generated file
_libxl_list.h, and also with the existing libxl_event.h.

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

diff -r 8a2eef481d3a -r cc71fe7029b2 tools/libxl/Makefile
--- a/tools/libxl/Makefile
+++ b/tools/libxl/Makefile
@@ -140,7 +140,7 @@ _libxl_save_msgs_helper.h _libxl_save_ms
 	$(PERL) -w $< $@ >$@.new
 	$(call move-if-changed,$@.new,$@)
 
-libxl.h: _libxl_types.h
+libxl.h: _libxl_types.h _libxl_list.h libxl_event.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

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

From xen-devel-bounces@lists.xen.org Thu Sep 06 17:15:16 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 2012 17:15:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9ffS-0000P2-FZ; Thu, 06 Sep 2012 17:15:02 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1T9ffR-0000Ou-A2
	for xen-devel@lists.xen.org; Thu, 06 Sep 2012 17:15:01 +0000
Received: from [85.158.139.83:6730] by server-1.bemta-5.messagelabs.com id
	14/4D-32692-41AD8405; Thu, 06 Sep 2012 17:15:00 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-16.tower-182.messagelabs.com!1346951699!21665562!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiA0MTgxNzk=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiA0MTgxNzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29433 invoked from network); 6 Sep 2012 17:14:59 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-16.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 6 Sep 2012 17:14:59 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/lk2c7pE3Rh
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-090-217.pools.arcor-ip.net [84.57.90.217])
	by smtp.strato.de (jorabe mo1) (RZmta 30.14 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id e06b6co86GFwdo
	for <xen-devel@lists.xen.org>; Thu, 6 Sep 2012 19:14:59 +0200 (CEST)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id D22B4183A5
	for <xen-devel@lists.xen.org>; Thu,  6 Sep 2012 19:14:58 +0200 (CEST)
MIME-Version: 1.0
X-Mercurial-Node: cc71fe7029b27cb95d268b99e136c445903af927
Message-Id: <cc71fe7029b27cb95d26.1346951697@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Thu, 06 Sep 2012 19:14:57 +0200
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH] libxl: add missing dependencies of libxl.h
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

# HG changeset patch
# User Olaf Hering <olaf@aepfle.de>
# Date 1346951410 -7200
# Node ID cc71fe7029b27cb95d268b99e136c445903af927
# Parent  8a2eef481d3ab3ca5692dd0083c95cf314fe1da3
libxl: add missing dependencies of libxl.h

libxl.h includes generated files, but the Makefile lists no dependency on
these files. As a result compilation may fail like this:

[  379s] make -C libxl install
[  379s] make[3]: Entering directory `/usr/src/packages/BUILD/xen-4.2.25821/non-dbg/tools/libxl'
[  379s] /usr/bin/perl /usr/src/packages/BUILD/xen-4.2.25821/non-dbg/tools/libxl/../../tools/include/xen-external/bsd-sys-queue-h-seddery /usr/src/packages/BUILD/xen-4.2.25821/non-dbg/tools/libxl/../../tools/include/xen-external/bsd-sys-queue.h --prefix=libxl >_libxl_list.h.new
...
[  380s] 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.api-for-check.d  -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -fno-optimize-sibling-calls -fmessage-length=0 -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables -fasynchronous-unwind-tables -Werror -Wno-format-zero-length -Wmissing-declarations -Wno-declaration-after-statement -Wformat-nonliteral -I. -fPIC -pthread -I/usr/src/packages/BUILD/xen-4.2.25821/non-dbg/tools/libxl/../../tools/libxc -I/usr/src/packages/BUILD/xen-4.2.25821/non-dbg/tools/libxl/../../tools/include  -I/usr/src/packages/BUILD/xen-4.2.25821/non-dbg/tools/libxl/../../tools/libxl -I/usr/src/packages/BUILD/xen-4.2.25821/non-dbg/tools/libxl/../../tools/libxc -I/usr/src/packages/BUILD/xen-4.2.25821/non-dbg/tools/libxl/../../tools/include -I/usr/src/packages/BUILD/xen-4.2.25821/non-dbg/tools/libxl/../../tools/include -include /usr/src/packages/BUILD/xen-4.2.25821/non-dbg/tools/libxl/../../tools/config.h  -I/usr/src/packages/BUILD/xen-4.2.25821/non-dbg/tools/libxl/../../tools/libxc -I/usr/src/packages/BUILD/xen-4.2.25821/non-dbg/tools/libxl/../../tools/include   -c -E libxl.h  \
[  380s] -DLIBXL_EXTERNAL_CALLERS_ONLY=LIBXL_EXTERNAL_CALLERS_ONLY \
[  380s] >_libxl.api-for-check.new
...
[  380s] libxl.h:260:25: fatal error: _libxl_list.h: No such file or directory
[  380s] compilation terminated.
[  380s] make[3]: *** [_libxl.api-for-check] Error 1
[  381s] if ! cmp -s _libxl_list.h.new _libxl_list.h; then mv -f _libxl_list.h.new _libxl_list.h; else rm -f _libxl_list.h.new; fi


Fix this be extending the existing libxl.h dependency with the generated file
_libxl_list.h, and also with the existing libxl_event.h.

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

diff -r 8a2eef481d3a -r cc71fe7029b2 tools/libxl/Makefile
--- a/tools/libxl/Makefile
+++ b/tools/libxl/Makefile
@@ -140,7 +140,7 @@ _libxl_save_msgs_helper.h _libxl_save_ms
 	$(PERL) -w $< $@ >$@.new
 	$(call move-if-changed,$@.new,$@)
 
-libxl.h: _libxl_types.h
+libxl.h: _libxl_types.h _libxl_list.h libxl_event.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

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

From xen-devel-bounces@lists.xen.org Thu Sep 06 17:25:24 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 2012 17:25:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9fpC-0000ig-Ub; Thu, 06 Sep 2012 17:25:06 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1T9fpB-0000ib-2H
	for xen-devel@lists.xen.org; Thu, 06 Sep 2012 17:25:05 +0000
Received: from [85.158.143.99:32204] by server-1.bemta-4.messagelabs.com id
	AF/23-12504-07CD8405; Thu, 06 Sep 2012 17:25:04 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-7.tower-216.messagelabs.com!1346952303!25597153!1
X-Originating-IP: [208.97.132.74]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi43NCA9PiAyOTQzNQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12051 invoked from network); 6 Sep 2012 17:25:03 -0000
Received: from caiajhbdcahe.dreamhost.com (HELO homiemail-a17.g.dreamhost.com)
	(208.97.132.74) by server-7.tower-216.messagelabs.com with SMTP;
	6 Sep 2012 17:25:03 -0000
Received: from homiemail-a17.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a17.g.dreamhost.com (Postfix) with ESMTP id 790E3380082;
	Thu,  6 Sep 2012 10:25:02 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=from:to:cc
	:subject:date:message-id; q=dns; s=lagarcavilla.org; b=BU8iWO1Je
	aE8AMm2ZkIkScu4DzLgKh/SphG6TV6ymHu7CxSUfdJdLevGAKQ/33NUeeeTSVHoh
	3QNnWggtk19UXpEIZaew5bjXqJmzd6hCH0ba0jkm4pvlnbBtxKLN5uMttoW3z8ka
	0Qk0KSsHP6xVPJjqzcyF6jvGQXuzOTscNI=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=from
	:to:cc:subject:date:message-id; s=lagarcavilla.org; bh=52N7cwEYm
	bSfbbdqIVzLyt/bzgY=; b=lndh7phPTt7Yc7MUogiM+UcSUrevcx2hRfpwXrMHN
	ltPZHnNElDJcQ6NcAwmomWRR3xkrnVpyP4GXm951auuCcb9qlUaSwzMmV6NB3xYs
	A8fWiB5jhLDWfdsy3s24p4NhY7fwZcGxNQ7Ulywg9vJXfg9Fsa401TEfdVcvl4j8
	Oc=
Received: from kdev.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-a17.g.dreamhost.com (Postfix) with ESMTPSA id 7080E38007F; 
	Thu,  6 Sep 2012 10:25:01 -0700 (PDT)
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xen.org
Date: Thu,  6 Sep 2012 13:24:39 -0400
Message-Id: <1346952279-1068-1-git-send-email-andres@lagarcavilla.org>
X-Mailer: git-send-email 1.7.9.5
Cc: Andres Lagar-Cavilla <andreslc@gridcentric.ca>,
	David Vrabel <david.vrabel@citrix.com>,
	Andres Lagar-Cavilla <andres@lagarcavilla.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: [Xen-devel] [PATCH] Fix mmap batch ioctl error status copy back.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Copy back of per-slot error codes is only necessary for V2. V1 does not provide
an error array, so copyback will unconditionally set the global rc to EFAULT.
Only copyback for V2.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
---
 drivers/xen/privcmd.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/xen/privcmd.c b/drivers/xen/privcmd.c
index 5386f20..e4dfa3b 100644
--- a/drivers/xen/privcmd.c
+++ b/drivers/xen/privcmd.c
@@ -389,7 +389,7 @@ static long privcmd_ioctl_mmap_batch(void __user *udata, int version)
 		state.err      = err_array;
 		ret = traverse_pages(m.num, sizeof(xen_pfn_t),
 					 &pagelist, mmap_return_errors_v1, &state);
-	} else
+	} else if (version == 2)
 		ret = __copy_to_user(m.err, err_array, m.num * sizeof(int));
 
     /* If we have not had any EFAULT-like global errors then set the global
-- 
1.7.9.5


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

From xen-devel-bounces@lists.xen.org Thu Sep 06 17:25:24 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 2012 17:25:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9fpC-0000ig-Ub; Thu, 06 Sep 2012 17:25:06 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1T9fpB-0000ib-2H
	for xen-devel@lists.xen.org; Thu, 06 Sep 2012 17:25:05 +0000
Received: from [85.158.143.99:32204] by server-1.bemta-4.messagelabs.com id
	AF/23-12504-07CD8405; Thu, 06 Sep 2012 17:25:04 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-7.tower-216.messagelabs.com!1346952303!25597153!1
X-Originating-IP: [208.97.132.74]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi43NCA9PiAyOTQzNQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12051 invoked from network); 6 Sep 2012 17:25:03 -0000
Received: from caiajhbdcahe.dreamhost.com (HELO homiemail-a17.g.dreamhost.com)
	(208.97.132.74) by server-7.tower-216.messagelabs.com with SMTP;
	6 Sep 2012 17:25:03 -0000
Received: from homiemail-a17.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a17.g.dreamhost.com (Postfix) with ESMTP id 790E3380082;
	Thu,  6 Sep 2012 10:25:02 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=from:to:cc
	:subject:date:message-id; q=dns; s=lagarcavilla.org; b=BU8iWO1Je
	aE8AMm2ZkIkScu4DzLgKh/SphG6TV6ymHu7CxSUfdJdLevGAKQ/33NUeeeTSVHoh
	3QNnWggtk19UXpEIZaew5bjXqJmzd6hCH0ba0jkm4pvlnbBtxKLN5uMttoW3z8ka
	0Qk0KSsHP6xVPJjqzcyF6jvGQXuzOTscNI=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=from
	:to:cc:subject:date:message-id; s=lagarcavilla.org; bh=52N7cwEYm
	bSfbbdqIVzLyt/bzgY=; b=lndh7phPTt7Yc7MUogiM+UcSUrevcx2hRfpwXrMHN
	ltPZHnNElDJcQ6NcAwmomWRR3xkrnVpyP4GXm951auuCcb9qlUaSwzMmV6NB3xYs
	A8fWiB5jhLDWfdsy3s24p4NhY7fwZcGxNQ7Ulywg9vJXfg9Fsa401TEfdVcvl4j8
	Oc=
Received: from kdev.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-a17.g.dreamhost.com (Postfix) with ESMTPSA id 7080E38007F; 
	Thu,  6 Sep 2012 10:25:01 -0700 (PDT)
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xen.org
Date: Thu,  6 Sep 2012 13:24:39 -0400
Message-Id: <1346952279-1068-1-git-send-email-andres@lagarcavilla.org>
X-Mailer: git-send-email 1.7.9.5
Cc: Andres Lagar-Cavilla <andreslc@gridcentric.ca>,
	David Vrabel <david.vrabel@citrix.com>,
	Andres Lagar-Cavilla <andres@lagarcavilla.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: [Xen-devel] [PATCH] Fix mmap batch ioctl error status copy back.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Copy back of per-slot error codes is only necessary for V2. V1 does not provide
an error array, so copyback will unconditionally set the global rc to EFAULT.
Only copyback for V2.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
---
 drivers/xen/privcmd.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/xen/privcmd.c b/drivers/xen/privcmd.c
index 5386f20..e4dfa3b 100644
--- a/drivers/xen/privcmd.c
+++ b/drivers/xen/privcmd.c
@@ -389,7 +389,7 @@ static long privcmd_ioctl_mmap_batch(void __user *udata, int version)
 		state.err      = err_array;
 		ret = traverse_pages(m.num, sizeof(xen_pfn_t),
 					 &pagelist, mmap_return_errors_v1, &state);
-	} else
+	} else if (version == 2)
 		ret = __copy_to_user(m.err, err_array, m.num * sizeof(int));
 
     /* If we have not had any EFAULT-like global errors then set the global
-- 
1.7.9.5


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

From xen-devel-bounces@lists.xen.org Thu Sep 06 18:04:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 2012 18: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 1T9gQj-0001RU-9q; Thu, 06 Sep 2012 18:03:53 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1T9gQi-0001RP-CY
	for xen-devel@lists.xensource.com; Thu, 06 Sep 2012 18:03:52 +0000
Received: from [85.158.138.51:38576] by server-3.bemta-3.messagelabs.com id
	83/65-21322-785E8405; Thu, 06 Sep 2012 18:03:51 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1346954630!21179339!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTE5NzY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15164 invoked from network); 6 Sep 2012 18:03:50 -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;
	6 Sep 2012 18:03:50 -0000
X-IronPort-AV: E=Sophos;i="4.80,380,1344211200"; d="scan'208";a="14393468"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Sep 2012 18:03: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.279.1; Thu, 6 Sep 2012 19:03:49 +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 1T9gQf-00011V-Jk;
	Thu, 06 Sep 2012 18:03:49 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1T9gQf-0005fz-2e;
	Thu, 06 Sep 2012 19:03:49 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-13657-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 6 Sep 2012 19:03:49 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.1-testing test] 13657: 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 13657 xen-4.1-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13657/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-pcipt-intel  8 debian-fixup                fail like 13646
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 13646

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-amd64-xl-qemuu-winxpsp3 13 guest-stop               fail never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-qemuu-rhel6hvm-amd 11 leak-check/check         fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-i386-qemuu-rhel6hvm-intel 11 leak-check/check       fail never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 13 guest-stop             fail never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-i386-i386-xl-qemuu-winxpsp3 13 guest-stop                 fail never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  3e4782f17f5c
baseline version:
 xen                  d28a9ba889c0

------------------------------------------------------------
People who touched revisions under test:
  Ian Campbell <ian.campbell@citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Keir Fraser <keir@xen.org>
  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                                     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=3e4782f17f5c
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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 3e4782f17f5c
+ branch=xen-4.1-testing
+ revision=3e4782f17f5c
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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 3e4782f17f5c 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 5 changesets with 5 changes to 4 files

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 06 18:04:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 2012 18: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 1T9gQj-0001RU-9q; Thu, 06 Sep 2012 18:03:53 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1T9gQi-0001RP-CY
	for xen-devel@lists.xensource.com; Thu, 06 Sep 2012 18:03:52 +0000
Received: from [85.158.138.51:38576] by server-3.bemta-3.messagelabs.com id
	83/65-21322-785E8405; Thu, 06 Sep 2012 18:03:51 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1346954630!21179339!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTE5NzY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15164 invoked from network); 6 Sep 2012 18:03:50 -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;
	6 Sep 2012 18:03:50 -0000
X-IronPort-AV: E=Sophos;i="4.80,380,1344211200"; d="scan'208";a="14393468"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Sep 2012 18:03: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.279.1; Thu, 6 Sep 2012 19:03:49 +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 1T9gQf-00011V-Jk;
	Thu, 06 Sep 2012 18:03:49 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1T9gQf-0005fz-2e;
	Thu, 06 Sep 2012 19:03:49 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-13657-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 6 Sep 2012 19:03:49 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.1-testing test] 13657: 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 13657 xen-4.1-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13657/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-pcipt-intel  8 debian-fixup                fail like 13646
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 13646

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-amd64-xl-qemuu-winxpsp3 13 guest-stop               fail never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-qemuu-rhel6hvm-amd 11 leak-check/check         fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-i386-qemuu-rhel6hvm-intel 11 leak-check/check       fail never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 13 guest-stop             fail never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-i386-i386-xl-qemuu-winxpsp3 13 guest-stop                 fail never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  3e4782f17f5c
baseline version:
 xen                  d28a9ba889c0

------------------------------------------------------------
People who touched revisions under test:
  Ian Campbell <ian.campbell@citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Keir Fraser <keir@xen.org>
  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                                     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=3e4782f17f5c
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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 3e4782f17f5c
+ branch=xen-4.1-testing
+ revision=3e4782f17f5c
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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 3e4782f17f5c 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 5 changesets with 5 changes to 4 files

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 06 18:15:46 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 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 1T9gbm-0001mm-SP; Thu, 06 Sep 2012 18:15:18 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <kseifried@redhat.com>) id 1T9gbl-0001mZ-Kh
	for xen-devel@lists.xen.org; Thu, 06 Sep 2012 18:15:17 +0000
Received: from [85.158.138.51:60224] by server-11.bemta-3.messagelabs.com id
	A1/F7-30250-438E8405; Thu, 06 Sep 2012 18:15:16 +0000
X-Env-Sender: kseifried@redhat.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1346955314!22770708!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTU5NTQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 733 invoked from network); 6 Sep 2012 18:15:15 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-14.tower-174.messagelabs.com with SMTP;
	6 Sep 2012 18:15:15 -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 q86IF02M022527
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 6 Sep 2012 14:15:00 -0400
Received: from seif-rht-f16.edm.seifried.org (ovpn-113-47.phx2.redhat.com
	[10.3.113.47])
	by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id q86IEwmL020096; Thu, 6 Sep 2012 14:14:59 -0400
Message-ID: <5048E824.7030802@redhat.com>
Date: Thu, 06 Sep 2012 12:15:00 -0600
From: Kurt Seifried <kseifried@redhat.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:14.0) Gecko/20120717 Thunderbird/14.0
MIME-Version: 1.0
To: oss-security@lists.openwall.com
References: <E1T9ehq-0006nu-7Q@xenbits.xen.org>
In-Reply-To: <E1T9ehq-0006nu-7Q@xenbits.xen.org>
X-Enigmail-Version: 1.4.4
OpenPGP: id=5E267993
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24
Cc: xen-users@lists.xen.org, xen-devel@lists.xen.org,
	xen-announce@lists.xen.org, "Xen.org security team" <security@xen.org>
Subject: Re: [Xen-devel] [oss-security] Xen Security Advisory 19 - guest
 administrator can access qemu monitor console
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 09/06/2012 10:13 AM, Xen.org security team wrote:
>                  Xen Security Advisory XSA-19
> 
>          guest administrator can access qemu monitor console
> 
> 
> ISSUE DESCRIPTION
> =================
> 
> A guest administrator who is granted access to the graphical console
> of a Xen guest can access the qemu monitor.  The monitor can be used
> to access host resources.
> 
> IMPACT
> ======
> 
> A malicious guest administrator can access host resources (perhaps
> belonging to other guests or the underlying system) and may be able to
> escalate their privilege to that of the host.
> 
> VULNERABLE SYSTEMS
> ==================
> 
> Installations where guest administrators do not have access to a
> domain's graphical console, or containing only PV domains configured
> without a graphical console, are not vulnerable.
> 
> Installations where all guest administrators are trustworthy are not
> vulnerable, even if the guest operating systems themselves are
> untrusted.
> 
> Systems using xend/xm: At least all versions since Xen 4.0 are
> affected.  Systems are vulnerable even if "monitor=no" is specified in
> the xm domain configuration file - this configuration option is not
> properly honoured in the vulnerable versions.
> 
> Systems using libxl/xl: All versions are affected.  The "monitor="
> option is not understood, and is therefore ignored, by xl.  However,
> systems using the experimental device model version based on upstream
> qemu are NOT vulnerable; that is, Xen 4.2 RC systems with
> device_model_version="qemu_xen" specified in the xl domain config
> file.
> 
> Systems using libvirt are vulnerable.  For "xen:" URIs, see xend/xm,
> above.  For "libxl:" URIs, all versions are affected.
> 
> Systems based on the Xen Cloud Platform are NOT vulnerable.
> 
> CONFIRMING VULNERABILITY
> ========================
> 
> Connect to the guest's VNC (or SDL) graphical display and make sure
> your focus is in that window.  Hold down CTRL and ALT and press 2.
> You will see a black screen showing one of "serial0", "parallel0" or
> "QEMU <version> monitor".  Repeat this exercise for other digits 3 to
> 6.  CTRL+ALT+1 is the domain's normal graphical console.  Not all
> numbers will have screens attached, but note that you must release and
> re-press CTRL and ALT each time.
> 
> If one of the accessible screens shows "QEMU <version> monitor" then
> you are vulnerable.  Otherwise you are not.
> 
> MITIGATION
> ==========
> 
> With xl in Xen 4.1 and later, supplying the following config
> option in the VM configuration file will disable the monitor:
>    device_model_args=["-monitor","null"]
> 
> With xend the following config option will disable the monitor:
>    monitor_path="null"
> Note that with a vulnerable version of the software specifying
> "monitor=0" will NOT disable the monitor.
> 
> We are not currently aware of the availability of mitigation for
> systems using libvirt.
> 
> NOTE REGARDING EMBARGO
> ======================
> 
> This issue was publicly discussed online by its discoverer.
> There is therefore no embargo.
> 
> NOTE REGARDING CVE
> ==================
> 
> This issue was previously reported in a different context, not to Xen
> upstream, and assigned CVE-2007-0998 and fixed in a different way.  We
> have requested a new CVE for XSA-19 but it is not yet available.

Ahh I see the request now (it was in a different email folder). Please
use CVE-2012-4411 for this issue.

> RESOLUTION
> ==========
> 
> The attached patch against qemu-xen-traditional
> (qemu-xen-4.*-testing.git) resolves this issue.
> 
> $ sha256sum xsa19-qemu-all.patch
> 19fc5ff9334e7e7ad429388850dc6e52e7062c21a677082e7a89c2f2c91365fa  xsa19-qemu-all.patch
> 

- -- 
Kurt Seifried Red Hat Security Response Team (SRT)
PGP: 0x5E267993 A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/

iQIcBAEBAgAGBQJQSOgkAAoJEBYNRVNeJnmTonAP/3BTawvHhQX3HOScXFSUiIuO
Sp8+Swmfe4uvxGOR4z/q3f3FdrKN6GdBc9cmmZeSSuYelFYaIpG6PIgv4Tbf9Fwy
F8qc/nxHSWhb19J/ifAHckd7kq99qrdei+59jZeiy8PTS+6//SeVhLDvKlV7B/1X
QsS3qM6vgpGXx9xoCIxyjVODIm23Q/iWjyqtJl3uqiW5wymLOcZvLC37Do/2DJ8l
NOEqDalueYypKhPZnoj05iUiuR4vpSl/DNMvi6NHu0fI3ZEATCkEPV16fCSnPIv6
oN2UG0X7qNmIBz7oUD7lnoM86TGjFuxT4Ka4gSACykaeGpIuoeFbcboEKqMmejXH
9knYcMl9+t0G3yNYPpA6G2ED0BVXu8Ov3JmO2FoT9OEgkDv7HGD50GltnqYFvM2b
O97g3GJ9w0lJQ55cWzjU6lr763tM/lYYcl3KX/ic8frtX+7FK+rXHt0j+QHWRzbx
YmewJphXkURBVva+FvYhTlagh2tWK1w2yUarrTFiFoxUss/out58L2QP5ie41urG
JNajebW8gNPa/C3MxB+IWfGLci36+3/qW+czgvEOMwFsbE2YmbnSrZiA+9wrPNzJ
Ngn88tHZftHwUwbikjYwMBCZnFG1hySyQUCu+Ym3itQqbA9IQRxaBbBOzI4gLxso
LuaafXJ0lxi3HvevyfvA
=ZGCU
-----END PGP SIGNATURE-----

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 06 18:15:46 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 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 1T9gbm-0001mm-SP; Thu, 06 Sep 2012 18:15:18 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <kseifried@redhat.com>) id 1T9gbl-0001mZ-Kh
	for xen-devel@lists.xen.org; Thu, 06 Sep 2012 18:15:17 +0000
Received: from [85.158.138.51:60224] by server-11.bemta-3.messagelabs.com id
	A1/F7-30250-438E8405; Thu, 06 Sep 2012 18:15:16 +0000
X-Env-Sender: kseifried@redhat.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1346955314!22770708!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTU5NTQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 733 invoked from network); 6 Sep 2012 18:15:15 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-14.tower-174.messagelabs.com with SMTP;
	6 Sep 2012 18:15:15 -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 q86IF02M022527
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 6 Sep 2012 14:15:00 -0400
Received: from seif-rht-f16.edm.seifried.org (ovpn-113-47.phx2.redhat.com
	[10.3.113.47])
	by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id q86IEwmL020096; Thu, 6 Sep 2012 14:14:59 -0400
Message-ID: <5048E824.7030802@redhat.com>
Date: Thu, 06 Sep 2012 12:15:00 -0600
From: Kurt Seifried <kseifried@redhat.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:14.0) Gecko/20120717 Thunderbird/14.0
MIME-Version: 1.0
To: oss-security@lists.openwall.com
References: <E1T9ehq-0006nu-7Q@xenbits.xen.org>
In-Reply-To: <E1T9ehq-0006nu-7Q@xenbits.xen.org>
X-Enigmail-Version: 1.4.4
OpenPGP: id=5E267993
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24
Cc: xen-users@lists.xen.org, xen-devel@lists.xen.org,
	xen-announce@lists.xen.org, "Xen.org security team" <security@xen.org>
Subject: Re: [Xen-devel] [oss-security] Xen Security Advisory 19 - guest
 administrator can access qemu monitor console
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 09/06/2012 10:13 AM, Xen.org security team wrote:
>                  Xen Security Advisory XSA-19
> 
>          guest administrator can access qemu monitor console
> 
> 
> ISSUE DESCRIPTION
> =================
> 
> A guest administrator who is granted access to the graphical console
> of a Xen guest can access the qemu monitor.  The monitor can be used
> to access host resources.
> 
> IMPACT
> ======
> 
> A malicious guest administrator can access host resources (perhaps
> belonging to other guests or the underlying system) and may be able to
> escalate their privilege to that of the host.
> 
> VULNERABLE SYSTEMS
> ==================
> 
> Installations where guest administrators do not have access to a
> domain's graphical console, or containing only PV domains configured
> without a graphical console, are not vulnerable.
> 
> Installations where all guest administrators are trustworthy are not
> vulnerable, even if the guest operating systems themselves are
> untrusted.
> 
> Systems using xend/xm: At least all versions since Xen 4.0 are
> affected.  Systems are vulnerable even if "monitor=no" is specified in
> the xm domain configuration file - this configuration option is not
> properly honoured in the vulnerable versions.
> 
> Systems using libxl/xl: All versions are affected.  The "monitor="
> option is not understood, and is therefore ignored, by xl.  However,
> systems using the experimental device model version based on upstream
> qemu are NOT vulnerable; that is, Xen 4.2 RC systems with
> device_model_version="qemu_xen" specified in the xl domain config
> file.
> 
> Systems using libvirt are vulnerable.  For "xen:" URIs, see xend/xm,
> above.  For "libxl:" URIs, all versions are affected.
> 
> Systems based on the Xen Cloud Platform are NOT vulnerable.
> 
> CONFIRMING VULNERABILITY
> ========================
> 
> Connect to the guest's VNC (or SDL) graphical display and make sure
> your focus is in that window.  Hold down CTRL and ALT and press 2.
> You will see a black screen showing one of "serial0", "parallel0" or
> "QEMU <version> monitor".  Repeat this exercise for other digits 3 to
> 6.  CTRL+ALT+1 is the domain's normal graphical console.  Not all
> numbers will have screens attached, but note that you must release and
> re-press CTRL and ALT each time.
> 
> If one of the accessible screens shows "QEMU <version> monitor" then
> you are vulnerable.  Otherwise you are not.
> 
> MITIGATION
> ==========
> 
> With xl in Xen 4.1 and later, supplying the following config
> option in the VM configuration file will disable the monitor:
>    device_model_args=["-monitor","null"]
> 
> With xend the following config option will disable the monitor:
>    monitor_path="null"
> Note that with a vulnerable version of the software specifying
> "monitor=0" will NOT disable the monitor.
> 
> We are not currently aware of the availability of mitigation for
> systems using libvirt.
> 
> NOTE REGARDING EMBARGO
> ======================
> 
> This issue was publicly discussed online by its discoverer.
> There is therefore no embargo.
> 
> NOTE REGARDING CVE
> ==================
> 
> This issue was previously reported in a different context, not to Xen
> upstream, and assigned CVE-2007-0998 and fixed in a different way.  We
> have requested a new CVE for XSA-19 but it is not yet available.

Ahh I see the request now (it was in a different email folder). Please
use CVE-2012-4411 for this issue.

> RESOLUTION
> ==========
> 
> The attached patch against qemu-xen-traditional
> (qemu-xen-4.*-testing.git) resolves this issue.
> 
> $ sha256sum xsa19-qemu-all.patch
> 19fc5ff9334e7e7ad429388850dc6e52e7062c21a677082e7a89c2f2c91365fa  xsa19-qemu-all.patch
> 

- -- 
Kurt Seifried Red Hat Security Response Team (SRT)
PGP: 0x5E267993 A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/

iQIcBAEBAgAGBQJQSOgkAAoJEBYNRVNeJnmTonAP/3BTawvHhQX3HOScXFSUiIuO
Sp8+Swmfe4uvxGOR4z/q3f3FdrKN6GdBc9cmmZeSSuYelFYaIpG6PIgv4Tbf9Fwy
F8qc/nxHSWhb19J/ifAHckd7kq99qrdei+59jZeiy8PTS+6//SeVhLDvKlV7B/1X
QsS3qM6vgpGXx9xoCIxyjVODIm23Q/iWjyqtJl3uqiW5wymLOcZvLC37Do/2DJ8l
NOEqDalueYypKhPZnoj05iUiuR4vpSl/DNMvi6NHu0fI3ZEATCkEPV16fCSnPIv6
oN2UG0X7qNmIBz7oUD7lnoM86TGjFuxT4Ka4gSACykaeGpIuoeFbcboEKqMmejXH
9knYcMl9+t0G3yNYPpA6G2ED0BVXu8Ov3JmO2FoT9OEgkDv7HGD50GltnqYFvM2b
O97g3GJ9w0lJQ55cWzjU6lr763tM/lYYcl3KX/ic8frtX+7FK+rXHt0j+QHWRzbx
YmewJphXkURBVva+FvYhTlagh2tWK1w2yUarrTFiFoxUss/out58L2QP5ie41urG
JNajebW8gNPa/C3MxB+IWfGLci36+3/qW+czgvEOMwFsbE2YmbnSrZiA+9wrPNzJ
Ngn88tHZftHwUwbikjYwMBCZnFG1hySyQUCu+Ym3itQqbA9IQRxaBbBOzI4gLxso
LuaafXJ0lxi3HvevyfvA
=ZGCU
-----END PGP SIGNATURE-----

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 06 18:45:59 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 2012 18:45:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9h5F-0002yj-4F; Thu, 06 Sep 2012 18:45:45 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <linux@eikelenboom.it>) id 1T9h5D-0002xf-TP
	for xen-devel@lists.xensource.com; Thu, 06 Sep 2012 18:45:44 +0000
Received: from [85.158.138.51:49919] by server-10.bemta-3.messagelabs.com id
	81/FC-10411-75FE8405; Thu, 06 Sep 2012 18:45:43 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-13.tower-174.messagelabs.com!1346957143!10438480!1
X-Originating-IP: [88.159.1.183]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogODguMTU5LjEuMTgzID0+IDI5MDg2\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31109 invoked from network); 6 Sep 2012 18:45:43 -0000
Received: from isp-bos-02.edutel.nl (HELO isp-bos-02.edutel.nl) (88.159.1.183)
	by server-13.tower-174.messagelabs.com with SMTP;
	6 Sep 2012 18:45:43 -0000
Received: from isp-aos-01.edutel.intern (unknown [IPv6:2a01:670:100:11::1:1])
	by isp-bos-02.edutel.nl (Postfix) with ESMTP id C195A2C656E;
	Thu,  6 Sep 2012 20:45:39 +0200 (CEST)
Received: from localhost (localhost.localdomain [127.0.0.1])
	by isp-aos-01.edutel.intern (Postfix) with ESMTP id 713D33DC4C4;
	Thu,  6 Sep 2012 20:45:39 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at isp-aos-01.edutel.intern
Received: from isp-aos-01.edutel.intern ([127.0.0.1])
	by localhost (isp-aos-01.edutel.intern [127.0.0.1]) (amavisd-new,
	port 10024)
	with ESMTP id G9d2NOMToTWj; Thu,  6 Sep 2012 20:45:38 +0200 (CEST)
Received: from mail.home.eikelenboom.it (128-64-ftth.onsneteindhoven.nl
	[88.159.64.128])
	by isp-aos-01.edutel.intern (Postfix) with ESMTPSA id 144243DC4BD;
	Thu,  6 Sep 2012 20:45:38 +0200 (CEST)
Received: from [172.16.1.31] (helo=xentest.example.org)
	by mail.home.eikelenboom.it with esmtpa (Exim 4.72)
	(envelope-from <linux@eikelenboom.it>)
	id 1T9h4j-00019D-IJ; Thu, 06 Sep 2012 20:45:13 +0200
MIME-Version: 1.0
X-Mercurial-Node: 780eae92908a911f63f760971fc29d8bbbbc4b01
Message-Id: <780eae92908a911f63f7.1346960488@xentest.example.org>
In-Reply-To: <patchbomb.1346960486@xentest.example.org>
References: <patchbomb.1346960486@xentest.example.org>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Thu, 06 Sep 2012 21:41:28 +0200
From: Sander Eikelenboom <linux@eikelenboom.it>
To: xen-devel@lists.xensource.com
Cc: Ian.Campbell@citrix.com
Subject: [Xen-devel] [PATCH 2 of 3] xl: Introduce reboot xm compatibility
	option -a and -w
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 missing option -a to reboot all guest domains
  * Add missing option -w to wait for the domain to reboot before returning


Signed-off-by: Sander Eikelenboom <linux@eikelenboom.it>

diff -r 4c3d49787cea -r 780eae92908a docs/man/xl.pod.1
--- a/docs/man/xl.pod.1	Thu Sep 06 21:36:14 2012 +0200
+++ b/docs/man/xl.pod.1	Thu Sep 06 21:36:41 2012 +0200
@@ -432,7 +432,7 @@ Pause a domain.  When in a paused state 
 allocated resources such as memory, but will not be eligible for
 scheduling by the Xen hypervisor.
 
-=item B<reboot> [I<OPTIONS>] I<domain-id>
+=item B<reboot> [I<OPTIONS>] I<-a|domain-id>
 
 Reboot a domain.  This acts just as if the domain had the B<reboot>
 command run from the console.  The command returns as soon as it has
@@ -452,6 +452,12 @@ B<OPTIONS>
 
 =over 4
 
+-a  Shutdown all guest domains.  Often used when doing a complete shutdown of a Xen system.
+
+=item B<-w>
+
+Wait for the domain to complete shutdown before returning.
+
 =item B<-F>
 
 If the guest does not support PV reboot control then fallback to
diff -r 4c3d49787cea -r 780eae92908a tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Thu Sep 06 21:36:14 2012 +0200
+++ b/tools/libxl/xl_cmdimpl.c	Thu Sep 06 21:36:41 2012 +0200
@@ -2743,11 +2743,14 @@ static void shutdown_domain(uint32_t dom
     }
 }
 
-static void reboot_domain(const char *p, int fallback_trigger)
+static void reboot_domain(uint32_t domain_id, int wait, int fallback_trigger)
 {
     int rc;
-    find_domain(p);
-    rc=libxl_domain_reboot(ctx, domid);
+    libxl_event *event;
+
+    domid = domain_id;
+    rc = libxl_domain_reboot(ctx, domid);
+    
     if (rc == ERROR_NOPARAVIRT) {
         if (fallback_trigger) {
             fprintf(stderr, "PV control interface not available:"
@@ -2762,6 +2765,42 @@ static void reboot_domain(const char *p,
     if (rc) {
         fprintf(stderr,"reboot failed (rc=%d)\n",rc);exit(-1);
     }
+
+    if (wait) {
+        libxl_evgen_domain_death *deathw;
+
+        rc = libxl_evenable_domain_death(ctx, domid, 0, &deathw);
+        if (rc) {
+            fprintf(stderr,"wait for death failed (evgen, rc=%d)\n",rc);
+            exit(-1);
+        }
+
+        for (;;) {
+            rc = domain_wait_event(&event);
+            if (rc) exit(-1);
+
+            switch (event->type) {
+
+            case LIBXL_EVENT_TYPE_DOMAIN_DEATH:
+                LOG("Domain %d has been destroyed", domid);
+                goto done;
+
+            case LIBXL_EVENT_TYPE_DOMAIN_SHUTDOWN:
+                LOG("Domain %d has been shut down, reason code %d %x", domid,
+                    event->u.domain_shutdown.shutdown_reason,
+                    event->u.domain_shutdown.shutdown_reason);
+                goto done;
+
+            default:
+                LOG("Unexpected event type %d", event->type);
+                break;
+            }
+            libxl_event_free(ctx, event);
+        }
+    done:
+        libxl_event_free(ctx, event);
+        libxl_evdisable_domain_death(ctx, deathw);
+    }
 }
 
 static void list_domains_details(const libxl_dominfo *info, int nb_domain)
@@ -3722,20 +3761,52 @@ int main_shutdown(int argc, char **argv)
 
 int main_reboot(int argc, char **argv)
 {
-    int opt;
+    libxl_dominfo *dominfo;
+    int opt, i, nb_domain;
+    int all = 0;
+    int wait = 0;
     int fallback_trigger = 0;
 
-    while ((opt = def_getopt(argc, argv, "F", "reboot", 1)) != -1) {
+    while ((opt = def_getopt(argc, argv, "awF", "reboot", 0)) != -1) {
         switch (opt) {
         case 0: case 2:
             return opt;
+        case 'a':
+            all = 1;
+            break;
+        case 'w':
+            wait = 1;
+            break;
         case 'F':
             fallback_trigger = 1;
             break;
         }
     }
 
-    reboot_domain(argv[optind], fallback_trigger);
+    if (!argv[optind] && !all) {
+        fprintf(stderr, "You must specify -a or a domain id.\n\n");
+        return opt;
+    }
+
+    if (all) {
+        if (!(dominfo = libxl_list_domain(ctx, &nb_domain))) {
+            fprintf(stderr, "libxl_list_domain failed.\n");
+            return -1;
+        }
+
+        for (i = 0; i<nb_domain; i++) {
+            if (dominfo[i].domid == 0)
+                continue;
+
+            reboot_domain(dominfo[i].domid, wait, fallback_trigger);
+        }
+
+        libxl_dominfo_list_free(dominfo, nb_domain);
+    } else {
+        find_domain(argv[optind]);
+        reboot_domain(domid, wait, fallback_trigger);
+    }
+
     return 0;
 }
 
diff -r 4c3d49787cea -r 780eae92908a tools/libxl/xl_cmdtable.c
--- a/tools/libxl/xl_cmdtable.c	Thu Sep 06 21:36:14 2012 +0200
+++ b/tools/libxl/xl_cmdtable.c	Thu Sep 06 21:36:41 2012 +0200
@@ -70,10 +70,12 @@ struct cmd_spec cmd_table[] = {
     { "reboot",
       &main_reboot, 0, 1,
       "Issue a reboot signal to a domain",
-      "[options] <Domain>",
+      "[options] <-a|Domain>",
+      "-a                      Reboot all guest domains.\n"
       "-h                      Print this help.\n"
       "-F                      Fallback to ACPI reset event for HVM guests with\n"
       "                        no PV drivers.\n"
+      "-w                      Wait for guest to reboot.\n"
     },
     { "pci-attach",
       &main_pciattach, 0, 1,

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 06 18:45:59 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 2012 18:45:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9h5F-0002yj-4F; Thu, 06 Sep 2012 18:45:45 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <linux@eikelenboom.it>) id 1T9h5D-0002xf-TP
	for xen-devel@lists.xensource.com; Thu, 06 Sep 2012 18:45:44 +0000
Received: from [85.158.138.51:49919] by server-10.bemta-3.messagelabs.com id
	81/FC-10411-75FE8405; Thu, 06 Sep 2012 18:45:43 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-13.tower-174.messagelabs.com!1346957143!10438480!1
X-Originating-IP: [88.159.1.183]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogODguMTU5LjEuMTgzID0+IDI5MDg2\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31109 invoked from network); 6 Sep 2012 18:45:43 -0000
Received: from isp-bos-02.edutel.nl (HELO isp-bos-02.edutel.nl) (88.159.1.183)
	by server-13.tower-174.messagelabs.com with SMTP;
	6 Sep 2012 18:45:43 -0000
Received: from isp-aos-01.edutel.intern (unknown [IPv6:2a01:670:100:11::1:1])
	by isp-bos-02.edutel.nl (Postfix) with ESMTP id C195A2C656E;
	Thu,  6 Sep 2012 20:45:39 +0200 (CEST)
Received: from localhost (localhost.localdomain [127.0.0.1])
	by isp-aos-01.edutel.intern (Postfix) with ESMTP id 713D33DC4C4;
	Thu,  6 Sep 2012 20:45:39 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at isp-aos-01.edutel.intern
Received: from isp-aos-01.edutel.intern ([127.0.0.1])
	by localhost (isp-aos-01.edutel.intern [127.0.0.1]) (amavisd-new,
	port 10024)
	with ESMTP id G9d2NOMToTWj; Thu,  6 Sep 2012 20:45:38 +0200 (CEST)
Received: from mail.home.eikelenboom.it (128-64-ftth.onsneteindhoven.nl
	[88.159.64.128])
	by isp-aos-01.edutel.intern (Postfix) with ESMTPSA id 144243DC4BD;
	Thu,  6 Sep 2012 20:45:38 +0200 (CEST)
Received: from [172.16.1.31] (helo=xentest.example.org)
	by mail.home.eikelenboom.it with esmtpa (Exim 4.72)
	(envelope-from <linux@eikelenboom.it>)
	id 1T9h4j-00019D-IJ; Thu, 06 Sep 2012 20:45:13 +0200
MIME-Version: 1.0
X-Mercurial-Node: 780eae92908a911f63f760971fc29d8bbbbc4b01
Message-Id: <780eae92908a911f63f7.1346960488@xentest.example.org>
In-Reply-To: <patchbomb.1346960486@xentest.example.org>
References: <patchbomb.1346960486@xentest.example.org>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Thu, 06 Sep 2012 21:41:28 +0200
From: Sander Eikelenboom <linux@eikelenboom.it>
To: xen-devel@lists.xensource.com
Cc: Ian.Campbell@citrix.com
Subject: [Xen-devel] [PATCH 2 of 3] xl: Introduce reboot xm compatibility
	option -a and -w
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 missing option -a to reboot all guest domains
  * Add missing option -w to wait for the domain to reboot before returning


Signed-off-by: Sander Eikelenboom <linux@eikelenboom.it>

diff -r 4c3d49787cea -r 780eae92908a docs/man/xl.pod.1
--- a/docs/man/xl.pod.1	Thu Sep 06 21:36:14 2012 +0200
+++ b/docs/man/xl.pod.1	Thu Sep 06 21:36:41 2012 +0200
@@ -432,7 +432,7 @@ Pause a domain.  When in a paused state 
 allocated resources such as memory, but will not be eligible for
 scheduling by the Xen hypervisor.
 
-=item B<reboot> [I<OPTIONS>] I<domain-id>
+=item B<reboot> [I<OPTIONS>] I<-a|domain-id>
 
 Reboot a domain.  This acts just as if the domain had the B<reboot>
 command run from the console.  The command returns as soon as it has
@@ -452,6 +452,12 @@ B<OPTIONS>
 
 =over 4
 
+-a  Shutdown all guest domains.  Often used when doing a complete shutdown of a Xen system.
+
+=item B<-w>
+
+Wait for the domain to complete shutdown before returning.
+
 =item B<-F>
 
 If the guest does not support PV reboot control then fallback to
diff -r 4c3d49787cea -r 780eae92908a tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Thu Sep 06 21:36:14 2012 +0200
+++ b/tools/libxl/xl_cmdimpl.c	Thu Sep 06 21:36:41 2012 +0200
@@ -2743,11 +2743,14 @@ static void shutdown_domain(uint32_t dom
     }
 }
 
-static void reboot_domain(const char *p, int fallback_trigger)
+static void reboot_domain(uint32_t domain_id, int wait, int fallback_trigger)
 {
     int rc;
-    find_domain(p);
-    rc=libxl_domain_reboot(ctx, domid);
+    libxl_event *event;
+
+    domid = domain_id;
+    rc = libxl_domain_reboot(ctx, domid);
+    
     if (rc == ERROR_NOPARAVIRT) {
         if (fallback_trigger) {
             fprintf(stderr, "PV control interface not available:"
@@ -2762,6 +2765,42 @@ static void reboot_domain(const char *p,
     if (rc) {
         fprintf(stderr,"reboot failed (rc=%d)\n",rc);exit(-1);
     }
+
+    if (wait) {
+        libxl_evgen_domain_death *deathw;
+
+        rc = libxl_evenable_domain_death(ctx, domid, 0, &deathw);
+        if (rc) {
+            fprintf(stderr,"wait for death failed (evgen, rc=%d)\n",rc);
+            exit(-1);
+        }
+
+        for (;;) {
+            rc = domain_wait_event(&event);
+            if (rc) exit(-1);
+
+            switch (event->type) {
+
+            case LIBXL_EVENT_TYPE_DOMAIN_DEATH:
+                LOG("Domain %d has been destroyed", domid);
+                goto done;
+
+            case LIBXL_EVENT_TYPE_DOMAIN_SHUTDOWN:
+                LOG("Domain %d has been shut down, reason code %d %x", domid,
+                    event->u.domain_shutdown.shutdown_reason,
+                    event->u.domain_shutdown.shutdown_reason);
+                goto done;
+
+            default:
+                LOG("Unexpected event type %d", event->type);
+                break;
+            }
+            libxl_event_free(ctx, event);
+        }
+    done:
+        libxl_event_free(ctx, event);
+        libxl_evdisable_domain_death(ctx, deathw);
+    }
 }
 
 static void list_domains_details(const libxl_dominfo *info, int nb_domain)
@@ -3722,20 +3761,52 @@ int main_shutdown(int argc, char **argv)
 
 int main_reboot(int argc, char **argv)
 {
-    int opt;
+    libxl_dominfo *dominfo;
+    int opt, i, nb_domain;
+    int all = 0;
+    int wait = 0;
     int fallback_trigger = 0;
 
-    while ((opt = def_getopt(argc, argv, "F", "reboot", 1)) != -1) {
+    while ((opt = def_getopt(argc, argv, "awF", "reboot", 0)) != -1) {
         switch (opt) {
         case 0: case 2:
             return opt;
+        case 'a':
+            all = 1;
+            break;
+        case 'w':
+            wait = 1;
+            break;
         case 'F':
             fallback_trigger = 1;
             break;
         }
     }
 
-    reboot_domain(argv[optind], fallback_trigger);
+    if (!argv[optind] && !all) {
+        fprintf(stderr, "You must specify -a or a domain id.\n\n");
+        return opt;
+    }
+
+    if (all) {
+        if (!(dominfo = libxl_list_domain(ctx, &nb_domain))) {
+            fprintf(stderr, "libxl_list_domain failed.\n");
+            return -1;
+        }
+
+        for (i = 0; i<nb_domain; i++) {
+            if (dominfo[i].domid == 0)
+                continue;
+
+            reboot_domain(dominfo[i].domid, wait, fallback_trigger);
+        }
+
+        libxl_dominfo_list_free(dominfo, nb_domain);
+    } else {
+        find_domain(argv[optind]);
+        reboot_domain(domid, wait, fallback_trigger);
+    }
+
     return 0;
 }
 
diff -r 4c3d49787cea -r 780eae92908a tools/libxl/xl_cmdtable.c
--- a/tools/libxl/xl_cmdtable.c	Thu Sep 06 21:36:14 2012 +0200
+++ b/tools/libxl/xl_cmdtable.c	Thu Sep 06 21:36:41 2012 +0200
@@ -70,10 +70,12 @@ struct cmd_spec cmd_table[] = {
     { "reboot",
       &main_reboot, 0, 1,
       "Issue a reboot signal to a domain",
-      "[options] <Domain>",
+      "[options] <-a|Domain>",
+      "-a                      Reboot all guest domains.\n"
       "-h                      Print this help.\n"
       "-F                      Fallback to ACPI reset event for HVM guests with\n"
       "                        no PV drivers.\n"
+      "-w                      Wait for guest to reboot.\n"
     },
     { "pci-attach",
       &main_pciattach, 0, 1,

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 06 18:45:59 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 2012 18:45:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9h5C-0002xy-QM; Thu, 06 Sep 2012 18:45:42 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <linux@eikelenboom.it>) id 1T9h5B-0002xf-2J
	for xen-devel@lists.xensource.com; Thu, 06 Sep 2012 18:45:41 +0000
Received: from [85.158.138.51:21952] by server-10.bemta-3.messagelabs.com id
	32/EC-10411-45FE8405; Thu, 06 Sep 2012 18:45:40 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-8.tower-174.messagelabs.com!1346957139!29076997!1
X-Originating-IP: [88.159.1.183]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogODguMTU5LjEuMTgzID0+IDI5MDg2\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6335 invoked from network); 6 Sep 2012 18:45:39 -0000
Received: from isp-bos-02.edutel.nl (HELO isp-bos-02.edutel.nl) (88.159.1.183)
	by server-8.tower-174.messagelabs.com with SMTP;
	6 Sep 2012 18:45:39 -0000
Received: from isp-aos-01.edutel.intern (unknown [IPv6:2a01:670:100:11::1:1])
	by isp-bos-02.edutel.nl (Postfix) with ESMTP id 7DBDF2C656D;
	Thu,  6 Sep 2012 20:45:39 +0200 (CEST)
Received: from localhost (localhost.localdomain [127.0.0.1])
	by isp-aos-01.edutel.intern (Postfix) with ESMTP id B98BD3DC4C1;
	Thu,  6 Sep 2012 20:45:38 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at isp-aos-01.edutel.intern
Received: from isp-aos-01.edutel.intern ([127.0.0.1])
	by localhost (isp-aos-01.edutel.intern [127.0.0.1]) (amavisd-new,
	port 10024)
	with ESMTP id Fb3efISi-1i9; Thu,  6 Sep 2012 20:45:37 +0200 (CEST)
Received: from mail.home.eikelenboom.it (128-64-ftth.onsneteindhoven.nl
	[88.159.64.128])
	by isp-aos-01.edutel.intern (Postfix) with ESMTPSA id E374B3DC4B5;
	Thu,  6 Sep 2012 20:45:37 +0200 (CEST)
Received: from [172.16.1.31] (helo=xentest.example.org)
	by mail.home.eikelenboom.it with esmtpa (Exim 4.72)
	(envelope-from <linux@eikelenboom.it>)
	id 1T9h4j-00019D-Bm; Thu, 06 Sep 2012 20:45:13 +0200
MIME-Version: 1.0
Message-Id: <patchbomb.1346960486@xentest.example.org>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Thu, 06 Sep 2012 21:41:26 +0200
From: Sander Eikelenboom <linux@eikelenboom.it>
To: xen-devel@lists.xensource.com
Cc: Ian.Campbell@citrix.com
Subject: [Xen-devel] [PATCH 0 of 3] xl and hotplug: Introduce and use
 shutdown and reboot xm compatibility options
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

The /etc/init.d/xendomains script makes use of options for the shutdown command defined in xendomains-sysconfig/default.
These options were not implemented in xl, this patch series implements the options and by using the short variant makes it compatible with both xm and xl.

Signed-off-by: Sander Eikelenboom <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 Thu Sep 06 18:45:59 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 2012 18:45:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9h5C-0002xy-QM; Thu, 06 Sep 2012 18:45:42 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <linux@eikelenboom.it>) id 1T9h5B-0002xf-2J
	for xen-devel@lists.xensource.com; Thu, 06 Sep 2012 18:45:41 +0000
Received: from [85.158.138.51:21952] by server-10.bemta-3.messagelabs.com id
	32/EC-10411-45FE8405; Thu, 06 Sep 2012 18:45:40 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-8.tower-174.messagelabs.com!1346957139!29076997!1
X-Originating-IP: [88.159.1.183]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogODguMTU5LjEuMTgzID0+IDI5MDg2\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6335 invoked from network); 6 Sep 2012 18:45:39 -0000
Received: from isp-bos-02.edutel.nl (HELO isp-bos-02.edutel.nl) (88.159.1.183)
	by server-8.tower-174.messagelabs.com with SMTP;
	6 Sep 2012 18:45:39 -0000
Received: from isp-aos-01.edutel.intern (unknown [IPv6:2a01:670:100:11::1:1])
	by isp-bos-02.edutel.nl (Postfix) with ESMTP id 7DBDF2C656D;
	Thu,  6 Sep 2012 20:45:39 +0200 (CEST)
Received: from localhost (localhost.localdomain [127.0.0.1])
	by isp-aos-01.edutel.intern (Postfix) with ESMTP id B98BD3DC4C1;
	Thu,  6 Sep 2012 20:45:38 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at isp-aos-01.edutel.intern
Received: from isp-aos-01.edutel.intern ([127.0.0.1])
	by localhost (isp-aos-01.edutel.intern [127.0.0.1]) (amavisd-new,
	port 10024)
	with ESMTP id Fb3efISi-1i9; Thu,  6 Sep 2012 20:45:37 +0200 (CEST)
Received: from mail.home.eikelenboom.it (128-64-ftth.onsneteindhoven.nl
	[88.159.64.128])
	by isp-aos-01.edutel.intern (Postfix) with ESMTPSA id E374B3DC4B5;
	Thu,  6 Sep 2012 20:45:37 +0200 (CEST)
Received: from [172.16.1.31] (helo=xentest.example.org)
	by mail.home.eikelenboom.it with esmtpa (Exim 4.72)
	(envelope-from <linux@eikelenboom.it>)
	id 1T9h4j-00019D-Bm; Thu, 06 Sep 2012 20:45:13 +0200
MIME-Version: 1.0
Message-Id: <patchbomb.1346960486@xentest.example.org>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Thu, 06 Sep 2012 21:41:26 +0200
From: Sander Eikelenboom <linux@eikelenboom.it>
To: xen-devel@lists.xensource.com
Cc: Ian.Campbell@citrix.com
Subject: [Xen-devel] [PATCH 0 of 3] xl and hotplug: Introduce and use
 shutdown and reboot xm compatibility options
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

The /etc/init.d/xendomains script makes use of options for the shutdown command defined in xendomains-sysconfig/default.
These options were not implemented in xl, this patch series implements the options and by using the short variant makes it compatible with both xm and xl.

Signed-off-by: Sander Eikelenboom <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 Thu Sep 06 18:46:00 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 2012 18: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 1T9h5D-0002yL-NP; Thu, 06 Sep 2012 18:45:43 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <linux@eikelenboom.it>) id 1T9h5C-0002xi-8x
	for xen-devel@lists.xensource.com; Thu, 06 Sep 2012 18:45:42 +0000
Received: from [85.158.138.51:22062] by server-9.bemta-3.messagelabs.com id
	CF/AD-15390-55FE8405; Thu, 06 Sep 2012 18:45:41 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-12.tower-174.messagelabs.com!1346957140!21184700!2
X-Originating-IP: [88.159.1.183]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogODguMTU5LjEuMTgzID0+IDI5MDg2\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1744 invoked from network); 6 Sep 2012 18:45:41 -0000
Received: from isp-bos-02.edutel.nl (HELO isp-bos-02.edutel.nl) (88.159.1.183)
	by server-12.tower-174.messagelabs.com with SMTP;
	6 Sep 2012 18:45:41 -0000
Received: from isp-aos-01.edutel.intern (unknown [IPv6:2a01:670:100:11::1:1])
	by isp-bos-02.edutel.nl (Postfix) with ESMTP id 5AA752C6570;
	Thu,  6 Sep 2012 20:45:41 +0200 (CEST)
Received: from localhost (localhost.localdomain [127.0.0.1])
	by isp-aos-01.edutel.intern (Postfix) with ESMTP id 506723DC4B5;
	Thu,  6 Sep 2012 20:45:41 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at isp-aos-01.edutel.intern
Received: from isp-aos-01.edutel.intern ([127.0.0.1])
	by localhost (isp-aos-01.edutel.intern [127.0.0.1]) (amavisd-new,
	port 10024)
	with ESMTP id qo8PaZ7zs0ha; Thu,  6 Sep 2012 20:45:38 +0200 (CEST)
Received: from mail.home.eikelenboom.it (128-64-ftth.onsneteindhoven.nl
	[88.159.64.128])
	by isp-aos-01.edutel.intern (Postfix) with ESMTPSA id 333DD3DC4BF;
	Thu,  6 Sep 2012 20:45:38 +0200 (CEST)
Received: from [172.16.1.31] (helo=xentest.example.org)
	by mail.home.eikelenboom.it with esmtpa (Exim 4.72)
	(envelope-from <linux@eikelenboom.it>)
	id 1T9h4j-00019D-MI; Thu, 06 Sep 2012 20:45:13 +0200
MIME-Version: 1.0
X-Mercurial-Node: 261ce3cdaee8d5c30f12e051ff5843982d191eed
Message-Id: <261ce3cdaee8d5c30f12.1346960489@xentest.example.org>
In-Reply-To: <patchbomb.1346960486@xentest.example.org>
References: <patchbomb.1346960486@xentest.example.org>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Thu, 06 Sep 2012 21:41:29 +0200
From: Sander Eikelenboom <linux@eikelenboom.it>
To: xen-devel@lists.xensource.com
Cc: Ian.Campbell@citrix.com
Subject: [Xen-devel] [PATCH 3 of 3] hotplug: Change options used for
 shutdown command in xendomains script to be compatible with both xm and 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

  * Use short options for shutdown command in xendomains script to be compatible with both xm and xl
  * Drop using the --halt: Linux in a guest treats "halt" and "poweroff" identically, so the --halt is pointless and not implemented in xl

Signed-off-by: Sander Eikelenboom <linux@eikelenboom.it>

diff -r 780eae92908a -r 261ce3cdaee8 tools/hotplug/Linux/init.d/sysconfig.xendomains
--- a/tools/hotplug/Linux/init.d/sysconfig.xendomains	Thu Sep 06 21:36:41 2012 +0200
+++ b/tools/hotplug/Linux/init.d/sysconfig.xendomains	Thu Sep 06 21:36:44 2012 +0200
@@ -56,29 +56,29 @@ XENDOMAINS_MIGRATE=""
 XENDOMAINS_SAVE=/var/lib/xen/save
 
 ## Type: string
-## Default: "--halt --wait"
+## Default: "-w"
 #
 # If neither MIGRATE nor SAVE were enabled or if they failed, you can
 # try to shut down a domain by sending it a shutdown request. To do this,
-# set this to "--halt --wait". Omit the "--wait" flag to avoid waiting
+# set this to "-w". Omit the "-w" flag to avoid waiting
 # for the domain to be really down. Leave empty to skip domain shutdown.
 #
-XENDOMAINS_SHUTDOWN="--halt --wait"
+XENDOMAINS_SHUTDOWN="-w"
 
 ## Type: string
-## Default: "--all --halt --wait"
+## Default: "-a -w"
 #
 # After we have gone over all virtual machines (resp. all automatically
 # started ones, see XENDOMAINS_AUTO_ONLY below) in a loop and sent SysRq,
 # migrated, saved and/or shutdown according to the settings above, we
 # might want to shutdown the virtual machines that are still running
 # for some reason or another. To do this, set this variable to
-# "--all --halt --wait", it will be passed to xm shutdown.
+# "-a -w", it will be passed to xm shutdown.
 # Leave it empty not to do anything special here.
 # (Note: This will hit all virtual machines, even if XENDOMAINS_AUTO_ONLY
 # is set.)
 # 
-XENDOMAINS_SHUTDOWN_ALL="--all --halt --wait"
+XENDOMAINS_SHUTDOWN_ALL="-a -w"
 
 ## Type: boolean
 ## Default: true
diff -r 780eae92908a -r 261ce3cdaee8 tools/hotplug/Linux/init.d/xendomains
--- a/tools/hotplug/Linux/init.d/xendomains	Thu Sep 06 21:36:41 2012 +0200
+++ b/tools/hotplug/Linux/init.d/xendomains	Thu Sep 06 21:36:44 2012 +0200
@@ -434,7 +434,7 @@ stop()
 	    fi
 	fi
 	if test -n "$XENDOMAINS_SHUTDOWN"; then
-	    # XENDOMAINS_SHUTDOWN should be "--halt --wait"
+	    # XENDOMAINS_SHUTDOWN should be "-w"
 	    echo -n "(shut)"
 	    watchdog_xencmd shutdown &
 	    WDOG_PID=$!
@@ -453,7 +453,7 @@ stop()
     # This is because it's easier to do ;-) but arguably if this script is run
     # on system shutdown then it's also the right thing to do.
     if ! all_zombies && test -n "$XENDOMAINS_SHUTDOWN_ALL"; then
-	# XENDOMAINS_SHUTDOWN_ALL should be "--all --halt --wait"
+	# XENDOMAINS_SHUTDOWN_ALL should be "-a -w"
 	echo -n " SHUTDOWN_ALL "
 	watchdog_xencmd shutdown 1 false &
 	WDOG_PID=$!
diff -r 780eae92908a -r 261ce3cdaee8 tools/hotplug/NetBSD/rc.d/xendomains
--- a/tools/hotplug/NetBSD/rc.d/xendomains	Thu Sep 06 21:36:41 2012 +0200
+++ b/tools/hotplug/NetBSD/rc.d/xendomains	Thu Sep 06 21:36:44 2012 +0200
@@ -94,7 +94,7 @@ xendomains_stop()
 	#
 	echo "Stopping xen domains."
 	for domain in $(xendomains_list); do
-		${ctl_command} shutdown --halt $domain
+		${ctl_command} shutdown $domain
 	done
 	while [ $timeout -gt 0 ]; do
 		livedomains=$(xendomains_list)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 06 18:46:00 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 2012 18: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 1T9h5D-0002yL-NP; Thu, 06 Sep 2012 18:45:43 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <linux@eikelenboom.it>) id 1T9h5C-0002xi-8x
	for xen-devel@lists.xensource.com; Thu, 06 Sep 2012 18:45:42 +0000
Received: from [85.158.138.51:22062] by server-9.bemta-3.messagelabs.com id
	CF/AD-15390-55FE8405; Thu, 06 Sep 2012 18:45:41 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-12.tower-174.messagelabs.com!1346957140!21184700!2
X-Originating-IP: [88.159.1.183]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogODguMTU5LjEuMTgzID0+IDI5MDg2\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1744 invoked from network); 6 Sep 2012 18:45:41 -0000
Received: from isp-bos-02.edutel.nl (HELO isp-bos-02.edutel.nl) (88.159.1.183)
	by server-12.tower-174.messagelabs.com with SMTP;
	6 Sep 2012 18:45:41 -0000
Received: from isp-aos-01.edutel.intern (unknown [IPv6:2a01:670:100:11::1:1])
	by isp-bos-02.edutel.nl (Postfix) with ESMTP id 5AA752C6570;
	Thu,  6 Sep 2012 20:45:41 +0200 (CEST)
Received: from localhost (localhost.localdomain [127.0.0.1])
	by isp-aos-01.edutel.intern (Postfix) with ESMTP id 506723DC4B5;
	Thu,  6 Sep 2012 20:45:41 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at isp-aos-01.edutel.intern
Received: from isp-aos-01.edutel.intern ([127.0.0.1])
	by localhost (isp-aos-01.edutel.intern [127.0.0.1]) (amavisd-new,
	port 10024)
	with ESMTP id qo8PaZ7zs0ha; Thu,  6 Sep 2012 20:45:38 +0200 (CEST)
Received: from mail.home.eikelenboom.it (128-64-ftth.onsneteindhoven.nl
	[88.159.64.128])
	by isp-aos-01.edutel.intern (Postfix) with ESMTPSA id 333DD3DC4BF;
	Thu,  6 Sep 2012 20:45:38 +0200 (CEST)
Received: from [172.16.1.31] (helo=xentest.example.org)
	by mail.home.eikelenboom.it with esmtpa (Exim 4.72)
	(envelope-from <linux@eikelenboom.it>)
	id 1T9h4j-00019D-MI; Thu, 06 Sep 2012 20:45:13 +0200
MIME-Version: 1.0
X-Mercurial-Node: 261ce3cdaee8d5c30f12e051ff5843982d191eed
Message-Id: <261ce3cdaee8d5c30f12.1346960489@xentest.example.org>
In-Reply-To: <patchbomb.1346960486@xentest.example.org>
References: <patchbomb.1346960486@xentest.example.org>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Thu, 06 Sep 2012 21:41:29 +0200
From: Sander Eikelenboom <linux@eikelenboom.it>
To: xen-devel@lists.xensource.com
Cc: Ian.Campbell@citrix.com
Subject: [Xen-devel] [PATCH 3 of 3] hotplug: Change options used for
 shutdown command in xendomains script to be compatible with both xm and 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

  * Use short options for shutdown command in xendomains script to be compatible with both xm and xl
  * Drop using the --halt: Linux in a guest treats "halt" and "poweroff" identically, so the --halt is pointless and not implemented in xl

Signed-off-by: Sander Eikelenboom <linux@eikelenboom.it>

diff -r 780eae92908a -r 261ce3cdaee8 tools/hotplug/Linux/init.d/sysconfig.xendomains
--- a/tools/hotplug/Linux/init.d/sysconfig.xendomains	Thu Sep 06 21:36:41 2012 +0200
+++ b/tools/hotplug/Linux/init.d/sysconfig.xendomains	Thu Sep 06 21:36:44 2012 +0200
@@ -56,29 +56,29 @@ XENDOMAINS_MIGRATE=""
 XENDOMAINS_SAVE=/var/lib/xen/save
 
 ## Type: string
-## Default: "--halt --wait"
+## Default: "-w"
 #
 # If neither MIGRATE nor SAVE were enabled or if they failed, you can
 # try to shut down a domain by sending it a shutdown request. To do this,
-# set this to "--halt --wait". Omit the "--wait" flag to avoid waiting
+# set this to "-w". Omit the "-w" flag to avoid waiting
 # for the domain to be really down. Leave empty to skip domain shutdown.
 #
-XENDOMAINS_SHUTDOWN="--halt --wait"
+XENDOMAINS_SHUTDOWN="-w"
 
 ## Type: string
-## Default: "--all --halt --wait"
+## Default: "-a -w"
 #
 # After we have gone over all virtual machines (resp. all automatically
 # started ones, see XENDOMAINS_AUTO_ONLY below) in a loop and sent SysRq,
 # migrated, saved and/or shutdown according to the settings above, we
 # might want to shutdown the virtual machines that are still running
 # for some reason or another. To do this, set this variable to
-# "--all --halt --wait", it will be passed to xm shutdown.
+# "-a -w", it will be passed to xm shutdown.
 # Leave it empty not to do anything special here.
 # (Note: This will hit all virtual machines, even if XENDOMAINS_AUTO_ONLY
 # is set.)
 # 
-XENDOMAINS_SHUTDOWN_ALL="--all --halt --wait"
+XENDOMAINS_SHUTDOWN_ALL="-a -w"
 
 ## Type: boolean
 ## Default: true
diff -r 780eae92908a -r 261ce3cdaee8 tools/hotplug/Linux/init.d/xendomains
--- a/tools/hotplug/Linux/init.d/xendomains	Thu Sep 06 21:36:41 2012 +0200
+++ b/tools/hotplug/Linux/init.d/xendomains	Thu Sep 06 21:36:44 2012 +0200
@@ -434,7 +434,7 @@ stop()
 	    fi
 	fi
 	if test -n "$XENDOMAINS_SHUTDOWN"; then
-	    # XENDOMAINS_SHUTDOWN should be "--halt --wait"
+	    # XENDOMAINS_SHUTDOWN should be "-w"
 	    echo -n "(shut)"
 	    watchdog_xencmd shutdown &
 	    WDOG_PID=$!
@@ -453,7 +453,7 @@ stop()
     # This is because it's easier to do ;-) but arguably if this script is run
     # on system shutdown then it's also the right thing to do.
     if ! all_zombies && test -n "$XENDOMAINS_SHUTDOWN_ALL"; then
-	# XENDOMAINS_SHUTDOWN_ALL should be "--all --halt --wait"
+	# XENDOMAINS_SHUTDOWN_ALL should be "-a -w"
 	echo -n " SHUTDOWN_ALL "
 	watchdog_xencmd shutdown 1 false &
 	WDOG_PID=$!
diff -r 780eae92908a -r 261ce3cdaee8 tools/hotplug/NetBSD/rc.d/xendomains
--- a/tools/hotplug/NetBSD/rc.d/xendomains	Thu Sep 06 21:36:41 2012 +0200
+++ b/tools/hotplug/NetBSD/rc.d/xendomains	Thu Sep 06 21:36:44 2012 +0200
@@ -94,7 +94,7 @@ xendomains_stop()
 	#
 	echo "Stopping xen domains."
 	for domain in $(xendomains_list); do
-		${ctl_command} shutdown --halt $domain
+		${ctl_command} shutdown $domain
 	done
 	while [ $timeout -gt 0 ]; do
 		livedomains=$(xendomains_list)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 06 18:46:01 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 2012 18: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 1T9h5D-0002y5-5L; Thu, 06 Sep 2012 18:45:43 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <linux@eikelenboom.it>) id 1T9h5B-0002xi-KK
	for xen-devel@lists.xensource.com; Thu, 06 Sep 2012 18:45:41 +0000
Received: from [85.158.138.51:49717] by server-9.bemta-3.messagelabs.com id
	5A/AD-15390-45FE8405; Thu, 06 Sep 2012 18:45:40 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-12.tower-174.messagelabs.com!1346957140!21184700!1
X-Originating-IP: [88.159.1.183]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogODguMTU5LjEuMTgzID0+IDI5MDg2\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1733 invoked from network); 6 Sep 2012 18:45:40 -0000
Received: from isp-bos-02.edutel.nl (HELO isp-bos-02.edutel.nl) (88.159.1.183)
	by server-12.tower-174.messagelabs.com with SMTP;
	6 Sep 2012 18:45:40 -0000
Received: from isp-aos-01.edutel.intern (unknown [IPv6:2a01:670:100:11::1:1])
	by isp-bos-02.edutel.nl (Postfix) with ESMTP id 3A6432C656F;
	Thu,  6 Sep 2012 20:45:40 +0200 (CEST)
Received: from localhost (localhost.localdomain [127.0.0.1])
	by isp-aos-01.edutel.intern (Postfix) with ESMTP id 272D53DC4BD;
	Thu,  6 Sep 2012 20:45:40 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at isp-aos-01.edutel.intern
Received: from isp-aos-01.edutel.intern ([127.0.0.1])
	by localhost (isp-aos-01.edutel.intern [127.0.0.1]) (amavisd-new,
	port 10024)
	with ESMTP id HeBfBCZ9Dgd6; Thu,  6 Sep 2012 20:45:38 +0200 (CEST)
Received: from mail.home.eikelenboom.it (128-64-ftth.onsneteindhoven.nl
	[88.159.64.128])
	by isp-aos-01.edutel.intern (Postfix) with ESMTPSA id 5AB3F3DC4C0;
	Thu,  6 Sep 2012 20:45:38 +0200 (CEST)
Received: from [172.16.1.31] (helo=xentest.example.org)
	by mail.home.eikelenboom.it with esmtpa (Exim 4.72)
	(envelope-from <linux@eikelenboom.it>)
	id 1T9h4j-00019D-FA; Thu, 06 Sep 2012 20:45:13 +0200
MIME-Version: 1.0
X-Mercurial-Node: 4c3d49787cea5e1dffc5ecf47915bdd8caba077d
Message-Id: <4c3d49787cea5e1dffc5.1346960487@xentest.example.org>
In-Reply-To: <patchbomb.1346960486@xentest.example.org>
References: <patchbomb.1346960486@xentest.example.org>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Thu, 06 Sep 2012 21:41:27 +0200
From: Sander Eikelenboom <linux@eikelenboom.it>
To: xen-devel@lists.xensource.com
Cc: Ian.Campbell@citrix.com
Subject: [Xen-devel] [PATCH 1 of 3] xl: Introduce shutdown xm compatibility
	option -a
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

  * Add missing option -a to shutdown all guest domains

Signed-off-by: Sander Eikelenboom <linux@eikelenboom.it>


---

Changed since v2:
  * fix error occuring when using both -a and -w options
    * Due to mixing local and global domid variable


Changed since v1:
  * address review comments.
    * Change shutdown_domain to take domid instead of domname
    * Docs: Make it more clear -a only shuts down GUEST domains

diff -r 9dc729b75595 -r 4c3d49787cea docs/man/xl.pod.1
--- a/docs/man/xl.pod.1	Mon Sep 03 11:22:02 2012 +0100
+++ b/docs/man/xl.pod.1	Thu Sep 06 21:36:14 2012 +0200
@@ -527,7 +527,7 @@ List specifically for that domain. Other
 
 =back
 
-=item B<shutdown> [I<OPTIONS>] I<domain-id>
+=item B<shutdown> [I<OPTIONS>] I<-a|domain-id>
 
 Gracefully shuts down a domain.  This coordinates with the domain OS
 to perform graceful shutdown, so there is no guarantee that it will
@@ -550,6 +550,10 @@ B<OPTIONS>
 
 =over 4
 
+=item B<-a>
+
+-a  Shutdown all guest domains.  Often used when doing a complete shutdown of a Xen system.
+
 =item B<-w>
 
 Wait for the domain to complete shutdown before returning.
diff -r 9dc729b75595 -r 4c3d49787cea tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Mon Sep 03 11:22:02 2012 +0100
+++ b/tools/libxl/xl_cmdimpl.c	Thu Sep 06 21:36:14 2012 +0200
@@ -2683,13 +2683,14 @@ static void destroy_domain(const char *p
     if (rc) { fprintf(stderr,"destroy failed (rc=%d)\n",rc); exit(-1); }
 }
 
-static void shutdown_domain(const char *p, int wait, int fallback_trigger)
+static void shutdown_domain(uint32_t domain_id, int wait, int fallback_trigger)
 {
     int rc;
     libxl_event *event;
 
-    find_domain(p);
-    rc=libxl_domain_shutdown(ctx, domid);
+    domid = domain_id;
+    rc = libxl_domain_shutdown(ctx, domid);
+
     if (rc == ERROR_NOPARAVIRT) {
         if (fallback_trigger) {
             fprintf(stderr, "PV control interface not available:"
@@ -3670,14 +3671,19 @@ int main_destroy(int argc, char **argv)
 
 int main_shutdown(int argc, char **argv)
 {
-    int opt;
+    libxl_dominfo *dominfo;
+    int opt, i, nb_domain;
+    int all = 0;
     int wait = 0;
     int fallback_trigger = 0;
 
-    while ((opt = def_getopt(argc, argv, "wF", "shutdown", 1)) != -1) {
+    while ((opt = def_getopt(argc, argv, "awF", "shutdown", 0)) != -1) {
         switch (opt) {
         case 0: case 2:
             return opt;
+        case 'a':
+            all = 1;
+            break;
         case 'w':
             wait = 1;
             break;
@@ -3687,7 +3693,30 @@ int main_shutdown(int argc, char **argv)
         }
     }
 
-    shutdown_domain(argv[optind], wait, fallback_trigger);
+    if (!argv[optind] && !all) {
+        fprintf(stderr, "You must specify -a or a domain id.\n\n");
+        return opt;
+    }
+
+    if (all) {
+        if (!(dominfo = libxl_list_domain(ctx, &nb_domain))) {
+            fprintf(stderr, "libxl_list_domain failed.\n");
+            return -1;
+        }
+
+        for (i = 0; i<nb_domain; i++) {
+            if (dominfo[i].domid == 0)
+                continue;
+
+            shutdown_domain(dominfo[i].domid, wait, fallback_trigger);
+        }
+
+        libxl_dominfo_list_free(dominfo, nb_domain);
+    } else {
+        find_domain(argv[optind]);
+        shutdown_domain(domid, wait, fallback_trigger);
+    }
+
     return 0;
 }
 
diff -r 9dc729b75595 -r 4c3d49787cea tools/libxl/xl_cmdtable.c
--- a/tools/libxl/xl_cmdtable.c	Mon Sep 03 11:22:02 2012 +0100
+++ b/tools/libxl/xl_cmdtable.c	Thu Sep 06 21:36:14 2012 +0200
@@ -60,7 +60,8 @@ struct cmd_spec cmd_table[] = {
     { "shutdown",
       &main_shutdown, 0, 1,
       "Issue a shutdown signal to a domain",
-      "[options] <Domain>",
+      "[options] <-a|Domain>",
+      "-a                      Shutdown all guest domains.\n"
       "-h                      Print this help.\n"
       "-F                      Fallback to ACPI power event for HVM guests with\n"
       "                        no PV drivers.\n"

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 06 18:46:01 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 2012 18: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 1T9h5D-0002y5-5L; Thu, 06 Sep 2012 18:45:43 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <linux@eikelenboom.it>) id 1T9h5B-0002xi-KK
	for xen-devel@lists.xensource.com; Thu, 06 Sep 2012 18:45:41 +0000
Received: from [85.158.138.51:49717] by server-9.bemta-3.messagelabs.com id
	5A/AD-15390-45FE8405; Thu, 06 Sep 2012 18:45:40 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-12.tower-174.messagelabs.com!1346957140!21184700!1
X-Originating-IP: [88.159.1.183]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogODguMTU5LjEuMTgzID0+IDI5MDg2\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1733 invoked from network); 6 Sep 2012 18:45:40 -0000
Received: from isp-bos-02.edutel.nl (HELO isp-bos-02.edutel.nl) (88.159.1.183)
	by server-12.tower-174.messagelabs.com with SMTP;
	6 Sep 2012 18:45:40 -0000
Received: from isp-aos-01.edutel.intern (unknown [IPv6:2a01:670:100:11::1:1])
	by isp-bos-02.edutel.nl (Postfix) with ESMTP id 3A6432C656F;
	Thu,  6 Sep 2012 20:45:40 +0200 (CEST)
Received: from localhost (localhost.localdomain [127.0.0.1])
	by isp-aos-01.edutel.intern (Postfix) with ESMTP id 272D53DC4BD;
	Thu,  6 Sep 2012 20:45:40 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at isp-aos-01.edutel.intern
Received: from isp-aos-01.edutel.intern ([127.0.0.1])
	by localhost (isp-aos-01.edutel.intern [127.0.0.1]) (amavisd-new,
	port 10024)
	with ESMTP id HeBfBCZ9Dgd6; Thu,  6 Sep 2012 20:45:38 +0200 (CEST)
Received: from mail.home.eikelenboom.it (128-64-ftth.onsneteindhoven.nl
	[88.159.64.128])
	by isp-aos-01.edutel.intern (Postfix) with ESMTPSA id 5AB3F3DC4C0;
	Thu,  6 Sep 2012 20:45:38 +0200 (CEST)
Received: from [172.16.1.31] (helo=xentest.example.org)
	by mail.home.eikelenboom.it with esmtpa (Exim 4.72)
	(envelope-from <linux@eikelenboom.it>)
	id 1T9h4j-00019D-FA; Thu, 06 Sep 2012 20:45:13 +0200
MIME-Version: 1.0
X-Mercurial-Node: 4c3d49787cea5e1dffc5ecf47915bdd8caba077d
Message-Id: <4c3d49787cea5e1dffc5.1346960487@xentest.example.org>
In-Reply-To: <patchbomb.1346960486@xentest.example.org>
References: <patchbomb.1346960486@xentest.example.org>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Thu, 06 Sep 2012 21:41:27 +0200
From: Sander Eikelenboom <linux@eikelenboom.it>
To: xen-devel@lists.xensource.com
Cc: Ian.Campbell@citrix.com
Subject: [Xen-devel] [PATCH 1 of 3] xl: Introduce shutdown xm compatibility
	option -a
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

  * Add missing option -a to shutdown all guest domains

Signed-off-by: Sander Eikelenboom <linux@eikelenboom.it>


---

Changed since v2:
  * fix error occuring when using both -a and -w options
    * Due to mixing local and global domid variable


Changed since v1:
  * address review comments.
    * Change shutdown_domain to take domid instead of domname
    * Docs: Make it more clear -a only shuts down GUEST domains

diff -r 9dc729b75595 -r 4c3d49787cea docs/man/xl.pod.1
--- a/docs/man/xl.pod.1	Mon Sep 03 11:22:02 2012 +0100
+++ b/docs/man/xl.pod.1	Thu Sep 06 21:36:14 2012 +0200
@@ -527,7 +527,7 @@ List specifically for that domain. Other
 
 =back
 
-=item B<shutdown> [I<OPTIONS>] I<domain-id>
+=item B<shutdown> [I<OPTIONS>] I<-a|domain-id>
 
 Gracefully shuts down a domain.  This coordinates with the domain OS
 to perform graceful shutdown, so there is no guarantee that it will
@@ -550,6 +550,10 @@ B<OPTIONS>
 
 =over 4
 
+=item B<-a>
+
+-a  Shutdown all guest domains.  Often used when doing a complete shutdown of a Xen system.
+
 =item B<-w>
 
 Wait for the domain to complete shutdown before returning.
diff -r 9dc729b75595 -r 4c3d49787cea tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Mon Sep 03 11:22:02 2012 +0100
+++ b/tools/libxl/xl_cmdimpl.c	Thu Sep 06 21:36:14 2012 +0200
@@ -2683,13 +2683,14 @@ static void destroy_domain(const char *p
     if (rc) { fprintf(stderr,"destroy failed (rc=%d)\n",rc); exit(-1); }
 }
 
-static void shutdown_domain(const char *p, int wait, int fallback_trigger)
+static void shutdown_domain(uint32_t domain_id, int wait, int fallback_trigger)
 {
     int rc;
     libxl_event *event;
 
-    find_domain(p);
-    rc=libxl_domain_shutdown(ctx, domid);
+    domid = domain_id;
+    rc = libxl_domain_shutdown(ctx, domid);
+
     if (rc == ERROR_NOPARAVIRT) {
         if (fallback_trigger) {
             fprintf(stderr, "PV control interface not available:"
@@ -3670,14 +3671,19 @@ int main_destroy(int argc, char **argv)
 
 int main_shutdown(int argc, char **argv)
 {
-    int opt;
+    libxl_dominfo *dominfo;
+    int opt, i, nb_domain;
+    int all = 0;
     int wait = 0;
     int fallback_trigger = 0;
 
-    while ((opt = def_getopt(argc, argv, "wF", "shutdown", 1)) != -1) {
+    while ((opt = def_getopt(argc, argv, "awF", "shutdown", 0)) != -1) {
         switch (opt) {
         case 0: case 2:
             return opt;
+        case 'a':
+            all = 1;
+            break;
         case 'w':
             wait = 1;
             break;
@@ -3687,7 +3693,30 @@ int main_shutdown(int argc, char **argv)
         }
     }
 
-    shutdown_domain(argv[optind], wait, fallback_trigger);
+    if (!argv[optind] && !all) {
+        fprintf(stderr, "You must specify -a or a domain id.\n\n");
+        return opt;
+    }
+
+    if (all) {
+        if (!(dominfo = libxl_list_domain(ctx, &nb_domain))) {
+            fprintf(stderr, "libxl_list_domain failed.\n");
+            return -1;
+        }
+
+        for (i = 0; i<nb_domain; i++) {
+            if (dominfo[i].domid == 0)
+                continue;
+
+            shutdown_domain(dominfo[i].domid, wait, fallback_trigger);
+        }
+
+        libxl_dominfo_list_free(dominfo, nb_domain);
+    } else {
+        find_domain(argv[optind]);
+        shutdown_domain(domid, wait, fallback_trigger);
+    }
+
     return 0;
 }
 
diff -r 9dc729b75595 -r 4c3d49787cea tools/libxl/xl_cmdtable.c
--- a/tools/libxl/xl_cmdtable.c	Mon Sep 03 11:22:02 2012 +0100
+++ b/tools/libxl/xl_cmdtable.c	Thu Sep 06 21:36:14 2012 +0200
@@ -60,7 +60,8 @@ struct cmd_spec cmd_table[] = {
     { "shutdown",
       &main_shutdown, 0, 1,
       "Issue a shutdown signal to a domain",
-      "[options] <Domain>",
+      "[options] <-a|Domain>",
+      "-a                      Shutdown all guest domains.\n"
       "-h                      Print this help.\n"
       "-F                      Fallback to ACPI power event for HVM guests with\n"
       "                        no PV drivers.\n"

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 06 18:53:24 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 2012 18:53:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9hCT-0003ej-3S; Thu, 06 Sep 2012 18:53: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 1T9hCR-0003eb-FL
	for xen-devel@lists.xen.org; Thu, 06 Sep 2012 18:53:11 +0000
Received: from [85.158.139.83:22939] by server-7.bemta-5.messagelabs.com id
	4D/56-19703-611F8405; Thu, 06 Sep 2012 18:53:10 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1346957589!25077315!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTE5NzY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14765 invoked from network); 6 Sep 2012 18:53:10 -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;
	6 Sep 2012 18:53:10 -0000
X-IronPort-AV: E=Sophos;i="4.80,380,1344211200"; d="scan'208";a="14394297"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Sep 2012 18:53:09 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Thu, 6 Sep 2012
	19:53:09 +0100
Message-ID: <1346957589.10570.46.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Olaf Hering <olaf@aepfle.de>
Date: Thu, 6 Sep 2012 19:53:09 +0100
In-Reply-To: <20120906165706.GB26940@aepfle.de>
References: <20120906163900.GA26442@aepfle.de>
	<1346949911.10570.42.camel@dagon.hellion.org.uk>
	<20120906165523.GA26940@aepfle.de> <20120906165706.GB26940@aepfle.de>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] creating _libxl_list.h is racy
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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-09-06 at 17:57 +0100, Olaf Hering wrote:
> On Thu, Sep 06, Olaf Hering wrote:
> 
> > On Thu, Sep 06, Ian Campbell wrote:
> > 
> > > But there is no depends on _libxl_list.h which is in $(AUTOINCS). Could
> > > fix by adding AUTOINCS here somewhere but is there any reason not to add
> > > 
> > > libxl.h: $(AUTOINCS)
> > 
> > There is already a libxl.h: _libxl_types.h, perhaps _libxl_list.h should
> > be added here as well.
> 
> And libxl.h includes also libxl_event.h, so it should depend on that
> file als well I think.

libxl_event.h isn't autogenerated so the usual gcc generated dependency
stuff can handle that.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 06 18:53:24 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 2012 18:53:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9hCT-0003ej-3S; Thu, 06 Sep 2012 18:53: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 1T9hCR-0003eb-FL
	for xen-devel@lists.xen.org; Thu, 06 Sep 2012 18:53:11 +0000
Received: from [85.158.139.83:22939] by server-7.bemta-5.messagelabs.com id
	4D/56-19703-611F8405; Thu, 06 Sep 2012 18:53:10 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1346957589!25077315!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTE5NzY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14765 invoked from network); 6 Sep 2012 18:53:10 -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;
	6 Sep 2012 18:53:10 -0000
X-IronPort-AV: E=Sophos;i="4.80,380,1344211200"; d="scan'208";a="14394297"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Sep 2012 18:53:09 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Thu, 6 Sep 2012
	19:53:09 +0100
Message-ID: <1346957589.10570.46.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Olaf Hering <olaf@aepfle.de>
Date: Thu, 6 Sep 2012 19:53:09 +0100
In-Reply-To: <20120906165706.GB26940@aepfle.de>
References: <20120906163900.GA26442@aepfle.de>
	<1346949911.10570.42.camel@dagon.hellion.org.uk>
	<20120906165523.GA26940@aepfle.de> <20120906165706.GB26940@aepfle.de>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] creating _libxl_list.h is racy
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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-09-06 at 17:57 +0100, Olaf Hering wrote:
> On Thu, Sep 06, Olaf Hering wrote:
> 
> > On Thu, Sep 06, Ian Campbell wrote:
> > 
> > > But there is no depends on _libxl_list.h which is in $(AUTOINCS). Could
> > > fix by adding AUTOINCS here somewhere but is there any reason not to add
> > > 
> > > libxl.h: $(AUTOINCS)
> > 
> > There is already a libxl.h: _libxl_types.h, perhaps _libxl_list.h should
> > be added here as well.
> 
> And libxl.h includes also libxl_event.h, so it should depend on that
> file als well I think.

libxl_event.h isn't autogenerated so the usual gcc generated dependency
stuff can handle that.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 06 19:07:11 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 2012 19:07:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9hPi-000485-Nd; Thu, 06 Sep 2012 19:06:54 +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 1T9hPh-000480-KQ
	for xen-devel@lists.xen.org; Thu, 06 Sep 2012 19:06:53 +0000
Received: from [85.158.143.35:59831] by server-2.bemta-4.messagelabs.com id
	B0/76-21239-D44F8405; Thu, 06 Sep 2012 19:06:53 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-9.tower-21.messagelabs.com!1346958412!6005355!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiA0MTgxNzk=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiA0MTgxNzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13303 invoked from network); 6 Sep 2012 19:06:52 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-9.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 6 Sep 2012 19:06:52 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/lk2c7pE3Rh
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-090-217.pools.arcor-ip.net [84.57.90.217])
	by smtp.strato.de (jored mo23) (RZmta 30.14 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id I02647o86GwwlH ;
	Thu, 6 Sep 2012 21:06:52 +0200 (CEST)
Received: by probook.site (Postfix, from userid 1000)
	id 371E3183AD; Thu,  6 Sep 2012 21:06:51 +0200 (CEST)
Date: Thu, 6 Sep 2012 21:06:51 +0200
From: Olaf Hering <olaf@aepfle.de>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120906190650.GA3091@aepfle.de>
References: <20120906163900.GA26442@aepfle.de>
	<1346949911.10570.42.camel@dagon.hellion.org.uk>
	<20120906165523.GA26940@aepfle.de>
	<20120906165706.GB26940@aepfle.de>
	<1346957589.10570.46.camel@dagon.hellion.org.uk>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1346957589.10570.46.camel@dagon.hellion.org.uk>
User-Agent: Mutt/1.5.21.rev5555 (2012-07-20)
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] creating _libxl_list.h is racy
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Sep 06, Ian Campbell wrote:

> On Thu, 2012-09-06 at 17:57 +0100, Olaf Hering wrote:
> > On Thu, Sep 06, Olaf Hering wrote:
> > 
> > > On Thu, Sep 06, Ian Campbell wrote:
> > > 
> > > > But there is no depends on _libxl_list.h which is in $(AUTOINCS). Could
> > > > fix by adding AUTOINCS here somewhere but is there any reason not to add
> > > > 
> > > > libxl.h: $(AUTOINCS)
> > > 
> > > There is already a libxl.h: _libxl_types.h, perhaps _libxl_list.h should
> > > be added here as well.
> > 
> > And libxl.h includes also libxl_event.h, so it should depend on that
> > file als well I think.
> 
> libxl_event.h isn't autogenerated so the usual gcc generated dependency
> stuff can handle that.

Ok, should I resend my patch?

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 06 19:07:11 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 2012 19:07:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9hPi-000485-Nd; Thu, 06 Sep 2012 19:06:54 +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 1T9hPh-000480-KQ
	for xen-devel@lists.xen.org; Thu, 06 Sep 2012 19:06:53 +0000
Received: from [85.158.143.35:59831] by server-2.bemta-4.messagelabs.com id
	B0/76-21239-D44F8405; Thu, 06 Sep 2012 19:06:53 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-9.tower-21.messagelabs.com!1346958412!6005355!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiA0MTgxNzk=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiA0MTgxNzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13303 invoked from network); 6 Sep 2012 19:06:52 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-9.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 6 Sep 2012 19:06:52 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/lk2c7pE3Rh
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-090-217.pools.arcor-ip.net [84.57.90.217])
	by smtp.strato.de (jored mo23) (RZmta 30.14 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id I02647o86GwwlH ;
	Thu, 6 Sep 2012 21:06:52 +0200 (CEST)
Received: by probook.site (Postfix, from userid 1000)
	id 371E3183AD; Thu,  6 Sep 2012 21:06:51 +0200 (CEST)
Date: Thu, 6 Sep 2012 21:06:51 +0200
From: Olaf Hering <olaf@aepfle.de>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120906190650.GA3091@aepfle.de>
References: <20120906163900.GA26442@aepfle.de>
	<1346949911.10570.42.camel@dagon.hellion.org.uk>
	<20120906165523.GA26940@aepfle.de>
	<20120906165706.GB26940@aepfle.de>
	<1346957589.10570.46.camel@dagon.hellion.org.uk>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1346957589.10570.46.camel@dagon.hellion.org.uk>
User-Agent: Mutt/1.5.21.rev5555 (2012-07-20)
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] creating _libxl_list.h is racy
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Sep 06, Ian Campbell wrote:

> On Thu, 2012-09-06 at 17:57 +0100, Olaf Hering wrote:
> > On Thu, Sep 06, Olaf Hering wrote:
> > 
> > > On Thu, Sep 06, Ian Campbell wrote:
> > > 
> > > > But there is no depends on _libxl_list.h which is in $(AUTOINCS). Could
> > > > fix by adding AUTOINCS here somewhere but is there any reason not to add
> > > > 
> > > > libxl.h: $(AUTOINCS)
> > > 
> > > There is already a libxl.h: _libxl_types.h, perhaps _libxl_list.h should
> > > be added here as well.
> > 
> > And libxl.h includes also libxl_event.h, so it should depend on that
> > file als well I think.
> 
> libxl_event.h isn't autogenerated so the usual gcc generated dependency
> stuff can handle that.

Ok, should I resend my patch?

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 06 19:58:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 2012 19: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 1T9iD8-0004dv-1Q; Thu, 06 Sep 2012 19:57:58 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <rjw@sisk.pl>)
	id 1T9iD6-0004dq-1y
	for xen-devel@lists.xensource.com; Thu, 06 Sep 2012 19:57:56 +0000
Received: from [85.158.139.83:15609] by server-12.bemta-5.messagelabs.com id
	4D/06-18300-34009405; Thu, 06 Sep 2012 19:57:55 +0000
X-Env-Sender: rjw@sisk.pl
X-Msg-Ref: server-15.tower-182.messagelabs.com!1346961474!28948817!1
X-Originating-IP: [193.178.161.156]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12459 invoked from network); 6 Sep 2012 19:57:54 -0000
Received: from ogre.sisk.pl (HELO ogre.sisk.pl) (193.178.161.156)
	by server-15.tower-182.messagelabs.com with SMTP;
	6 Sep 2012 19:57:54 -0000
Received: from localhost (localhost.localdomain [127.0.0.1])
	by ogre.sisk.pl (Postfix) with ESMTP id 7A6AA1DD3DD;
	Thu,  6 Sep 2012 22:01:24 +0200 (CEST)
Received: from ogre.sisk.pl ([127.0.0.1])
	by localhost (ogre.sisk.pl [127.0.0.1]) (amavisd-new,
	port 10024) with ESMTP
	id 04312-04; Thu,  6 Sep 2012 22:01:13 +0200 (CEST)
Received: from ferrari.rjw.lan (89-67-90-11.dynamic.chello.pl [89.67.90.11])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by ogre.sisk.pl (Postfix) with ESMTP id 3A9CD1DD3D1;
	Thu,  6 Sep 2012 22:01:13 +0200 (CEST)
From: "Rafael J. Wysocki" <rjw@sisk.pl>
To: Daniel Lezcano <daniel.lezcano@linaro.org>
Date: Thu, 6 Sep 2012 22:04:11 +0200
User-Agent: KMail/1.13.6 (Linux/3.6.0-rc3+; KDE/4.6.0; x86_64; ; )
References: <1343164349-28550-1-git-send-email-daniel.lezcano@linaro.org>
	<50485698.1070905@linaro.org> <50486B58.7000901@linaro.org>
In-Reply-To: <50486B58.7000901@linaro.org>
MIME-Version: 1.0
Message-Id: <201209062204.11288.rjw@sisk.pl>
X-Virus-Scanned: amavisd-new at ogre.sisk.pl using MkS_Vir for Linux
Cc: xen-devel@lists.xensource.com, linaro-dev@lists.linaro.org,
	linux-pm@vger.kernel.org, Frederic Weisbecker <fweisbec@gmail.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	linux-acpi@vger.kernel.org, lenb@kernel.org
Subject: Re: [Xen-devel] CONFIG_NO_HZ + CONFIG_CPU_IDLE freeze the system
	(Was Re: [PATCH] acpi : remove power from acpi_processor_cx
	structure)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thursday, September 06, 2012, Daniel Lezcano wrote:
> On 09/06/2012 09:54 AM, Daniel Lezcano wrote:
> > On 09/05/2012 03:41 PM, Rafael J. Wysocki wrote:
> >> On Saturday, September 01, 2012, Rafael J. Wysocki wrote:
> >>> On Friday, August 31, 2012, Daniel Lezcano wrote:
> >>>> On 07/24/2012 11:06 PM, Konrad Rzeszutek Wilk wrote:
> >>>>> On Tue, Jul 24, 2012 at 11:12:29PM +0200, Daniel Lezcano wrote:
> >>>>>> Remove the power field as it is not used.
> >>>>>>
> >>>>>> Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
> >>>>>> Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> >>>>> Acked.
> >>>> Hi Rafael,
> >>>>
> >>>> I did not see this patch going in. Is it possible to merge it ?
> >>> I think so.  I'll take care of it when I get back from LinuxCon/Plumbers Conf.
> >>> (early next week).
> >> Applied to the linux-next branch of the linux-pm.git tree as v3.7 material.
> > Thanks Rafael.
> >
> >> Are there any other patches you want me to consider for v3.7?
> > Yes please, I have the per cpu latencies ready to be submitted but I
> > want to do extra testing before. Unfortunately, the linux-pm-next hangs
> > at boot time on my intel dual core (not related to the patchset).
> >
> > I am git bisecting right now.
> 
> I found the culprit. This is not related to the linux-pm tree but with
> net-next.
> The following patch introduced the issue.
> 
> commit 6bdb7fe31046ac50b47e83c35cd6c6b6160a475d
> Author: Amerigo Wang <amwang@redhat.com>
> Date:   Fri Aug 10 01:24:50 2012 +0000
> 
>     netpoll: re-enable irq in poll_napi()
>    
>     napi->poll() needs IRQ enabled, so we have to re-enable IRQ before
>     calling it.
>    
>     Cc: David Miller <davem@davemloft.net>
>     Signed-off-by: Cong Wang <amwang@redhat.com>
>     Signed-off-by: David S. Miller <davem@davemloft.net>
> 
> AFAICS, it has been fixed by commit
> 072a9c48600409d72aeb0d5b29fbb75861a06631 which is not yet in linux-pm-next.

If it is present in the current Linus' tree, you can just pull this one
and merge linux-pm-next into it.  It should merge without conflicts.

> I fall into this issue because NETCONSOLE is set, disabling it allowed
> me to go further.
> 
> Unfortunately I am facing to some random freeze on the system which
> seems to be related to CONFIG_NO_HZ=y and CONFIG_CPU_IDLE=y.
> 
> Disabling one of them, make the freezes to disappear.
> 
> Is it a known issue ?

Well, there are systems having problems with this configuration, but they
should be exceptional.  What system is that?

Rafael

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 06 19:58:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 2012 19: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 1T9iD8-0004dv-1Q; Thu, 06 Sep 2012 19:57:58 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <rjw@sisk.pl>)
	id 1T9iD6-0004dq-1y
	for xen-devel@lists.xensource.com; Thu, 06 Sep 2012 19:57:56 +0000
Received: from [85.158.139.83:15609] by server-12.bemta-5.messagelabs.com id
	4D/06-18300-34009405; Thu, 06 Sep 2012 19:57:55 +0000
X-Env-Sender: rjw@sisk.pl
X-Msg-Ref: server-15.tower-182.messagelabs.com!1346961474!28948817!1
X-Originating-IP: [193.178.161.156]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12459 invoked from network); 6 Sep 2012 19:57:54 -0000
Received: from ogre.sisk.pl (HELO ogre.sisk.pl) (193.178.161.156)
	by server-15.tower-182.messagelabs.com with SMTP;
	6 Sep 2012 19:57:54 -0000
Received: from localhost (localhost.localdomain [127.0.0.1])
	by ogre.sisk.pl (Postfix) with ESMTP id 7A6AA1DD3DD;
	Thu,  6 Sep 2012 22:01:24 +0200 (CEST)
Received: from ogre.sisk.pl ([127.0.0.1])
	by localhost (ogre.sisk.pl [127.0.0.1]) (amavisd-new,
	port 10024) with ESMTP
	id 04312-04; Thu,  6 Sep 2012 22:01:13 +0200 (CEST)
Received: from ferrari.rjw.lan (89-67-90-11.dynamic.chello.pl [89.67.90.11])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by ogre.sisk.pl (Postfix) with ESMTP id 3A9CD1DD3D1;
	Thu,  6 Sep 2012 22:01:13 +0200 (CEST)
From: "Rafael J. Wysocki" <rjw@sisk.pl>
To: Daniel Lezcano <daniel.lezcano@linaro.org>
Date: Thu, 6 Sep 2012 22:04:11 +0200
User-Agent: KMail/1.13.6 (Linux/3.6.0-rc3+; KDE/4.6.0; x86_64; ; )
References: <1343164349-28550-1-git-send-email-daniel.lezcano@linaro.org>
	<50485698.1070905@linaro.org> <50486B58.7000901@linaro.org>
In-Reply-To: <50486B58.7000901@linaro.org>
MIME-Version: 1.0
Message-Id: <201209062204.11288.rjw@sisk.pl>
X-Virus-Scanned: amavisd-new at ogre.sisk.pl using MkS_Vir for Linux
Cc: xen-devel@lists.xensource.com, linaro-dev@lists.linaro.org,
	linux-pm@vger.kernel.org, Frederic Weisbecker <fweisbec@gmail.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	linux-acpi@vger.kernel.org, lenb@kernel.org
Subject: Re: [Xen-devel] CONFIG_NO_HZ + CONFIG_CPU_IDLE freeze the system
	(Was Re: [PATCH] acpi : remove power from acpi_processor_cx
	structure)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thursday, September 06, 2012, Daniel Lezcano wrote:
> On 09/06/2012 09:54 AM, Daniel Lezcano wrote:
> > On 09/05/2012 03:41 PM, Rafael J. Wysocki wrote:
> >> On Saturday, September 01, 2012, Rafael J. Wysocki wrote:
> >>> On Friday, August 31, 2012, Daniel Lezcano wrote:
> >>>> On 07/24/2012 11:06 PM, Konrad Rzeszutek Wilk wrote:
> >>>>> On Tue, Jul 24, 2012 at 11:12:29PM +0200, Daniel Lezcano wrote:
> >>>>>> Remove the power field as it is not used.
> >>>>>>
> >>>>>> Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
> >>>>>> Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> >>>>> Acked.
> >>>> Hi Rafael,
> >>>>
> >>>> I did not see this patch going in. Is it possible to merge it ?
> >>> I think so.  I'll take care of it when I get back from LinuxCon/Plumbers Conf.
> >>> (early next week).
> >> Applied to the linux-next branch of the linux-pm.git tree as v3.7 material.
> > Thanks Rafael.
> >
> >> Are there any other patches you want me to consider for v3.7?
> > Yes please, I have the per cpu latencies ready to be submitted but I
> > want to do extra testing before. Unfortunately, the linux-pm-next hangs
> > at boot time on my intel dual core (not related to the patchset).
> >
> > I am git bisecting right now.
> 
> I found the culprit. This is not related to the linux-pm tree but with
> net-next.
> The following patch introduced the issue.
> 
> commit 6bdb7fe31046ac50b47e83c35cd6c6b6160a475d
> Author: Amerigo Wang <amwang@redhat.com>
> Date:   Fri Aug 10 01:24:50 2012 +0000
> 
>     netpoll: re-enable irq in poll_napi()
>    
>     napi->poll() needs IRQ enabled, so we have to re-enable IRQ before
>     calling it.
>    
>     Cc: David Miller <davem@davemloft.net>
>     Signed-off-by: Cong Wang <amwang@redhat.com>
>     Signed-off-by: David S. Miller <davem@davemloft.net>
> 
> AFAICS, it has been fixed by commit
> 072a9c48600409d72aeb0d5b29fbb75861a06631 which is not yet in linux-pm-next.

If it is present in the current Linus' tree, you can just pull this one
and merge linux-pm-next into it.  It should merge without conflicts.

> I fall into this issue because NETCONSOLE is set, disabling it allowed
> me to go further.
> 
> Unfortunately I am facing to some random freeze on the system which
> seems to be related to CONFIG_NO_HZ=y and CONFIG_CPU_IDLE=y.
> 
> Disabling one of them, make the freezes to disappear.
> 
> Is it a known issue ?

Well, there are systems having problems with this configuration, but they
should be exceptional.  What system is that?

Rafael

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 06 20:36:18 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 2012 20: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 1T9ino-0005IU-84; Thu, 06 Sep 2012 20:35:52 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <daniel.lezcano@linaro.org>) id 1T9inm-0005ID-1u
	for xen-devel@lists.xensource.com; Thu, 06 Sep 2012 20:35:50 +0000
Received: from [85.158.138.51:61258] by server-10.bemta-3.messagelabs.com id
	EA/F7-10411-52909405; Thu, 06 Sep 2012 20:35:49 +0000
X-Env-Sender: daniel.lezcano@linaro.org
X-Msg-Ref: server-16.tower-174.messagelabs.com!1346963748!29041758!1
X-Originating-IP: [209.85.215.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24078 invoked from network); 6 Sep 2012 20:35:48 -0000
Received: from mail-ey0-f171.google.com (HELO mail-ey0-f171.google.com)
	(209.85.215.171)
	by server-16.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Sep 2012 20:35:48 -0000
Received: by eaah11 with SMTP id h11so750896eaa.30
	for <xen-devel@lists.xensource.com>;
	Thu, 06 Sep 2012 13:35:48 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=message-id:date:from:user-agent:mime-version:to:cc:subject
	:references:in-reply-to:content-type:content-transfer-encoding
	:x-gm-message-state;
	bh=MNyycdrLjuX52Ad3wNCdbO8KVnhm+XAjYG4oZES0SoU=;
	b=TKeoaDg1qEt4xWTt6hWRlroYTR/Bzi0BLQt03UGr/yv+2JMh+lhOdAtMIz3e0M4ny9
	SvT8ch2U72hj9zrjaaSx0/xxpehuzmt28CDMtbziHTlOwZq/Q4Ibb+h7wlz1OyCHcnbT
	mA3vLzuihKHTnGNcsnJp4XzDsEwZHa9ac4ZxQ7YY28rpaZNapooDauxFZ6MwbO+sLf/p
	bg8uvkLcm/HKCdoo5CN57v+8u/Kj4QdOz3k57XarinrHh4JzINqlYC7w6jmd02ISmqBp
	af/NqdoqQKhLLrhCKqGKazlAA5BfBvMRUmEEjQllci/d/zh2LcAs9jK/cWke/RJOgJNB
	m9bQ==
Received: by 10.14.204.72 with SMTP id g48mr4973307eeo.45.1346963748015;
	Thu, 06 Sep 2012 13:35:48 -0700 (PDT)
Received: from [192.168.1.14] (AToulouse-651-1-16-21.w92-149.abo.wanadoo.fr.
	[92.149.191.21])
	by mx.google.com with ESMTPS id u8sm8933700eel.11.2012.09.06.13.35.45
	(version=SSLv3 cipher=OTHER); Thu, 06 Sep 2012 13:35:46 -0700 (PDT)
Message-ID: <50490920.9070204@linaro.org>
Date: Thu, 06 Sep 2012 22:35:44 +0200
From: Daniel Lezcano <daniel.lezcano@linaro.org>
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:12.0) Gecko/20120430 Thunderbird/12.0.1
MIME-Version: 1.0
To: "Rafael J. Wysocki" <rjw@sisk.pl>
References: <1343164349-28550-1-git-send-email-daniel.lezcano@linaro.org>
	<50485698.1070905@linaro.org> <50486B58.7000901@linaro.org>
	<201209062204.11288.rjw@sisk.pl>
In-Reply-To: <201209062204.11288.rjw@sisk.pl>
X-Gm-Message-State: ALoCoQmsJPPgP6nbDs3X1NRDtxZpTC7LJ75PAj6Jsd248fEVCrDp/7f9anJGWMCT5YJXmDhk5Vmq
Cc: xen-devel@lists.xensource.com, linaro-dev@lists.linaro.org,
	linux-pm@vger.kernel.org, Frederic Weisbecker <fweisbec@gmail.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	linux-acpi@vger.kernel.org, lenb@kernel.org
Subject: Re: [Xen-devel] CONFIG_NO_HZ + CONFIG_CPU_IDLE freeze the system
 (Was Re: [PATCH] acpi : remove power from acpi_processor_cx structure)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gMDkvMDYvMjAxMiAxMDowNCBQTSwgUmFmYWVsIEouIFd5c29ja2kgd3JvdGU6Cj4gT24gVGh1
cnNkYXksIFNlcHRlbWJlciAwNiwgMjAxMiwgRGFuaWVsIExlemNhbm8gd3JvdGU6Cj4+IE9uIDA5
LzA2LzIwMTIgMDk6NTQgQU0sIERhbmllbCBMZXpjYW5vIHdyb3RlOgo+Pj4gT24gMDkvMDUvMjAx
MiAwMzo0MSBQTSwgUmFmYWVsIEouIFd5c29ja2kgd3JvdGU6Cj4+Pj4gT24gU2F0dXJkYXksIFNl
cHRlbWJlciAwMSwgMjAxMiwgUmFmYWVsIEouIFd5c29ja2kgd3JvdGU6Cj4+Pj4+IE9uIEZyaWRh
eSwgQXVndXN0IDMxLCAyMDEyLCBEYW5pZWwgTGV6Y2FubyB3cm90ZToKPj4+Pj4+IE9uIDA3LzI0
LzIwMTIgMTE6MDYgUE0sIEtvbnJhZCBSemVzenV0ZWsgV2lsayB3cm90ZToKPj4+Pj4+PiBPbiBU
dWUsIEp1bCAyNCwgMjAxMiBhdCAxMToxMjoyOVBNICswMjAwLCBEYW5pZWwgTGV6Y2FubyB3cm90
ZToKPj4+Pj4+Pj4gUmVtb3ZlIHRoZSBwb3dlciBmaWVsZCBhcyBpdCBpcyBub3QgdXNlZC4KPj4+
Pj4+Pj4KPj4+Pj4+Pj4gU2lnbmVkLW9mZi1ieTogRGFuaWVsIExlemNhbm8gPGRhbmllbC5sZXpj
YW5vQGxpbmFyby5vcmc+Cj4+Pj4+Pj4+IENjOiBLb25yYWQgUnplc3p1dGVrIFdpbGsgPGtvbnJh
ZC53aWxrQG9yYWNsZS5jb20+Cj4+Pj4+Pj4gQWNrZWQuCj4+Pj4+PiBIaSBSYWZhZWwsCj4+Pj4+
Pgo+Pj4+Pj4gSSBkaWQgbm90IHNlZSB0aGlzIHBhdGNoIGdvaW5nIGluLiBJcyBpdCBwb3NzaWJs
ZSB0byBtZXJnZSBpdCA/Cj4+Pj4+IEkgdGhpbmsgc28uICBJJ2xsIHRha2UgY2FyZSBvZiBpdCB3
aGVuIEkgZ2V0IGJhY2sgZnJvbSBMaW51eENvbi9QbHVtYmVycyBDb25mLgo+Pj4+PiAoZWFybHkg
bmV4dCB3ZWVrKS4KPj4+PiBBcHBsaWVkIHRvIHRoZSBsaW51eC1uZXh0IGJyYW5jaCBvZiB0aGUg
bGludXgtcG0uZ2l0IHRyZWUgYXMgdjMuNyBtYXRlcmlhbC4KPj4+IFRoYW5rcyBSYWZhZWwuCj4+
Pgo+Pj4+IEFyZSB0aGVyZSBhbnkgb3RoZXIgcGF0Y2hlcyB5b3Ugd2FudCBtZSB0byBjb25zaWRl
ciBmb3IgdjMuNz8KPj4+IFllcyBwbGVhc2UsIEkgaGF2ZSB0aGUgcGVyIGNwdSBsYXRlbmNpZXMg
cmVhZHkgdG8gYmUgc3VibWl0dGVkIGJ1dCBJCj4+PiB3YW50IHRvIGRvIGV4dHJhIHRlc3Rpbmcg
YmVmb3JlLiBVbmZvcnR1bmF0ZWx5LCB0aGUgbGludXgtcG0tbmV4dCBoYW5ncwo+Pj4gYXQgYm9v
dCB0aW1lIG9uIG15IGludGVsIGR1YWwgY29yZSAobm90IHJlbGF0ZWQgdG8gdGhlIHBhdGNoc2V0
KS4KPj4+Cj4+PiBJIGFtIGdpdCBiaXNlY3RpbmcgcmlnaHQgbm93Lgo+Pgo+PiBJIGZvdW5kIHRo
ZSBjdWxwcml0LiBUaGlzIGlzIG5vdCByZWxhdGVkIHRvIHRoZSBsaW51eC1wbSB0cmVlIGJ1dCB3
aXRoCj4+IG5ldC1uZXh0Lgo+PiBUaGUgZm9sbG93aW5nIHBhdGNoIGludHJvZHVjZWQgdGhlIGlz
c3VlLgo+Pgo+PiBjb21taXQgNmJkYjdmZTMxMDQ2YWM1MGI0N2U4M2MzNWNkNmM2YjYxNjBhNDc1
ZAo+PiBBdXRob3I6IEFtZXJpZ28gV2FuZyA8YW13YW5nQHJlZGhhdC5jb20+Cj4+IERhdGU6ICAg
RnJpIEF1ZyAxMCAwMToyNDo1MCAyMDEyICswMDAwCj4+Cj4+ICAgICBuZXRwb2xsOiByZS1lbmFi
bGUgaXJxIGluIHBvbGxfbmFwaSgpCj4+ICAgIAo+PiAgICAgbmFwaS0+cG9sbCgpIG5lZWRzIElS
USBlbmFibGVkLCBzbyB3ZSBoYXZlIHRvIHJlLWVuYWJsZSBJUlEgYmVmb3JlCj4+ICAgICBjYWxs
aW5nIGl0Lgo+PiAgICAKPj4gICAgIENjOiBEYXZpZCBNaWxsZXIgPGRhdmVtQGRhdmVtbG9mdC5u
ZXQ+Cj4+ICAgICBTaWduZWQtb2ZmLWJ5OiBDb25nIFdhbmcgPGFtd2FuZ0ByZWRoYXQuY29tPgo+
PiAgICAgU2lnbmVkLW9mZi1ieTogRGF2aWQgUy4gTWlsbGVyIDxkYXZlbUBkYXZlbWxvZnQubmV0
Pgo+Pgo+PiBBRkFJQ1MsIGl0IGhhcyBiZWVuIGZpeGVkIGJ5IGNvbW1pdAo+PiAwNzJhOWM0ODYw
MDQwOWQ3MmFlYjBkNWIyOWZiYjc1ODYxYTA2NjMxIHdoaWNoIGlzIG5vdCB5ZXQgaW4gbGludXgt
cG0tbmV4dC4KPiAKPiBJZiBpdCBpcyBwcmVzZW50IGluIHRoZSBjdXJyZW50IExpbnVzJyB0cmVl
LCB5b3UgY2FuIGp1c3QgcHVsbCB0aGlzIG9uZQo+IGFuZCBtZXJnZSBsaW51eC1wbS1uZXh0IGlu
dG8gaXQuICBJdCBzaG91bGQgbWVyZ2Ugd2l0aG91dCBjb25mbGljdHMuCgpPaywgdGhhbmtzLgoK
Pj4gSSBmYWxsIGludG8gdGhpcyBpc3N1ZSBiZWNhdXNlIE5FVENPTlNPTEUgaXMgc2V0LCBkaXNh
YmxpbmcgaXQgYWxsb3dlZAo+PiBtZSB0byBnbyBmdXJ0aGVyLgo+Pgo+PiBVbmZvcnR1bmF0ZWx5
IEkgYW0gZmFjaW5nIHRvIHNvbWUgcmFuZG9tIGZyZWV6ZSBvbiB0aGUgc3lzdGVtIHdoaWNoCj4+
IHNlZW1zIHRvIGJlIHJlbGF0ZWQgdG8gQ09ORklHX05PX0haPXkgYW5kIENPTkZJR19DUFVfSURM
RT15Lgo+Pgo+PiBEaXNhYmxpbmcgb25lIG9mIHRoZW0sIG1ha2UgdGhlIGZyZWV6ZXMgdG8gZGlz
YXBwZWFyLgo+Pgo+PiBJcyBpdCBhIGtub3duIGlzc3VlID8KPiAKPiBXZWxsLCB0aGVyZSBhcmUg
c3lzdGVtcyBoYXZpbmcgcHJvYmxlbXMgd2l0aCB0aGlzIGNvbmZpZ3VyYXRpb24sIGJ1dCB0aGV5
Cj4gc2hvdWxkIGJlIGV4Y2VwdGlvbmFsLiAgV2hhdCBzeXN0ZW0gaXMgdGhhdD8KCkl0IGlzIGEg
bGFwdG9wIFQ2MXAgd2l0aCBhIENvcmUgMiBEdW8gVDk1MDAuIE5vdGhpbmcgZXhjZXB0aW9uYWwg
SQpiZWxpZXZlLiBNYXliZSBzb21lb25lIGdvdCB0aGUgc2FtZSBpc3N1ZSA/CgotLSAKIDxodHRw
Oi8vd3d3LmxpbmFyby5vcmcvPiBMaW5hcm8ub3JnIOKUgiBPcGVuIHNvdXJjZSBzb2Z0d2FyZSBm
b3IgQVJNIFNvQ3MKCkZvbGxvdyBMaW5hcm86ICA8aHR0cDovL3d3dy5mYWNlYm9vay5jb20vcGFn
ZXMvTGluYXJvPiBGYWNlYm9vayB8CjxodHRwOi8vdHdpdHRlci5jb20vIyEvbGluYXJvb3JnPiBU
d2l0dGVyIHwKPGh0dHA6Ly93d3cubGluYXJvLm9yZy9saW5hcm8tYmxvZy8+IEJsb2cKCgpfX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpYZW4tZGV2ZWwgbWFp
bGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW4ub3JnCmh0dHA6Ly9saXN0cy54ZW4ub3JnL3hl
bi1kZXZlbAo=

From xen-devel-bounces@lists.xen.org Thu Sep 06 20:36:18 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 2012 20: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 1T9ino-0005IU-84; Thu, 06 Sep 2012 20:35:52 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <daniel.lezcano@linaro.org>) id 1T9inm-0005ID-1u
	for xen-devel@lists.xensource.com; Thu, 06 Sep 2012 20:35:50 +0000
Received: from [85.158.138.51:61258] by server-10.bemta-3.messagelabs.com id
	EA/F7-10411-52909405; Thu, 06 Sep 2012 20:35:49 +0000
X-Env-Sender: daniel.lezcano@linaro.org
X-Msg-Ref: server-16.tower-174.messagelabs.com!1346963748!29041758!1
X-Originating-IP: [209.85.215.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24078 invoked from network); 6 Sep 2012 20:35:48 -0000
Received: from mail-ey0-f171.google.com (HELO mail-ey0-f171.google.com)
	(209.85.215.171)
	by server-16.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Sep 2012 20:35:48 -0000
Received: by eaah11 with SMTP id h11so750896eaa.30
	for <xen-devel@lists.xensource.com>;
	Thu, 06 Sep 2012 13:35:48 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=message-id:date:from:user-agent:mime-version:to:cc:subject
	:references:in-reply-to:content-type:content-transfer-encoding
	:x-gm-message-state;
	bh=MNyycdrLjuX52Ad3wNCdbO8KVnhm+XAjYG4oZES0SoU=;
	b=TKeoaDg1qEt4xWTt6hWRlroYTR/Bzi0BLQt03UGr/yv+2JMh+lhOdAtMIz3e0M4ny9
	SvT8ch2U72hj9zrjaaSx0/xxpehuzmt28CDMtbziHTlOwZq/Q4Ibb+h7wlz1OyCHcnbT
	mA3vLzuihKHTnGNcsnJp4XzDsEwZHa9ac4ZxQ7YY28rpaZNapooDauxFZ6MwbO+sLf/p
	bg8uvkLcm/HKCdoo5CN57v+8u/Kj4QdOz3k57XarinrHh4JzINqlYC7w6jmd02ISmqBp
	af/NqdoqQKhLLrhCKqGKazlAA5BfBvMRUmEEjQllci/d/zh2LcAs9jK/cWke/RJOgJNB
	m9bQ==
Received: by 10.14.204.72 with SMTP id g48mr4973307eeo.45.1346963748015;
	Thu, 06 Sep 2012 13:35:48 -0700 (PDT)
Received: from [192.168.1.14] (AToulouse-651-1-16-21.w92-149.abo.wanadoo.fr.
	[92.149.191.21])
	by mx.google.com with ESMTPS id u8sm8933700eel.11.2012.09.06.13.35.45
	(version=SSLv3 cipher=OTHER); Thu, 06 Sep 2012 13:35:46 -0700 (PDT)
Message-ID: <50490920.9070204@linaro.org>
Date: Thu, 06 Sep 2012 22:35:44 +0200
From: Daniel Lezcano <daniel.lezcano@linaro.org>
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:12.0) Gecko/20120430 Thunderbird/12.0.1
MIME-Version: 1.0
To: "Rafael J. Wysocki" <rjw@sisk.pl>
References: <1343164349-28550-1-git-send-email-daniel.lezcano@linaro.org>
	<50485698.1070905@linaro.org> <50486B58.7000901@linaro.org>
	<201209062204.11288.rjw@sisk.pl>
In-Reply-To: <201209062204.11288.rjw@sisk.pl>
X-Gm-Message-State: ALoCoQmsJPPgP6nbDs3X1NRDtxZpTC7LJ75PAj6Jsd248fEVCrDp/7f9anJGWMCT5YJXmDhk5Vmq
Cc: xen-devel@lists.xensource.com, linaro-dev@lists.linaro.org,
	linux-pm@vger.kernel.org, Frederic Weisbecker <fweisbec@gmail.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	linux-acpi@vger.kernel.org, lenb@kernel.org
Subject: Re: [Xen-devel] CONFIG_NO_HZ + CONFIG_CPU_IDLE freeze the system
 (Was Re: [PATCH] acpi : remove power from acpi_processor_cx structure)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gMDkvMDYvMjAxMiAxMDowNCBQTSwgUmFmYWVsIEouIFd5c29ja2kgd3JvdGU6Cj4gT24gVGh1
cnNkYXksIFNlcHRlbWJlciAwNiwgMjAxMiwgRGFuaWVsIExlemNhbm8gd3JvdGU6Cj4+IE9uIDA5
LzA2LzIwMTIgMDk6NTQgQU0sIERhbmllbCBMZXpjYW5vIHdyb3RlOgo+Pj4gT24gMDkvMDUvMjAx
MiAwMzo0MSBQTSwgUmFmYWVsIEouIFd5c29ja2kgd3JvdGU6Cj4+Pj4gT24gU2F0dXJkYXksIFNl
cHRlbWJlciAwMSwgMjAxMiwgUmFmYWVsIEouIFd5c29ja2kgd3JvdGU6Cj4+Pj4+IE9uIEZyaWRh
eSwgQXVndXN0IDMxLCAyMDEyLCBEYW5pZWwgTGV6Y2FubyB3cm90ZToKPj4+Pj4+IE9uIDA3LzI0
LzIwMTIgMTE6MDYgUE0sIEtvbnJhZCBSemVzenV0ZWsgV2lsayB3cm90ZToKPj4+Pj4+PiBPbiBU
dWUsIEp1bCAyNCwgMjAxMiBhdCAxMToxMjoyOVBNICswMjAwLCBEYW5pZWwgTGV6Y2FubyB3cm90
ZToKPj4+Pj4+Pj4gUmVtb3ZlIHRoZSBwb3dlciBmaWVsZCBhcyBpdCBpcyBub3QgdXNlZC4KPj4+
Pj4+Pj4KPj4+Pj4+Pj4gU2lnbmVkLW9mZi1ieTogRGFuaWVsIExlemNhbm8gPGRhbmllbC5sZXpj
YW5vQGxpbmFyby5vcmc+Cj4+Pj4+Pj4+IENjOiBLb25yYWQgUnplc3p1dGVrIFdpbGsgPGtvbnJh
ZC53aWxrQG9yYWNsZS5jb20+Cj4+Pj4+Pj4gQWNrZWQuCj4+Pj4+PiBIaSBSYWZhZWwsCj4+Pj4+
Pgo+Pj4+Pj4gSSBkaWQgbm90IHNlZSB0aGlzIHBhdGNoIGdvaW5nIGluLiBJcyBpdCBwb3NzaWJs
ZSB0byBtZXJnZSBpdCA/Cj4+Pj4+IEkgdGhpbmsgc28uICBJJ2xsIHRha2UgY2FyZSBvZiBpdCB3
aGVuIEkgZ2V0IGJhY2sgZnJvbSBMaW51eENvbi9QbHVtYmVycyBDb25mLgo+Pj4+PiAoZWFybHkg
bmV4dCB3ZWVrKS4KPj4+PiBBcHBsaWVkIHRvIHRoZSBsaW51eC1uZXh0IGJyYW5jaCBvZiB0aGUg
bGludXgtcG0uZ2l0IHRyZWUgYXMgdjMuNyBtYXRlcmlhbC4KPj4+IFRoYW5rcyBSYWZhZWwuCj4+
Pgo+Pj4+IEFyZSB0aGVyZSBhbnkgb3RoZXIgcGF0Y2hlcyB5b3Ugd2FudCBtZSB0byBjb25zaWRl
ciBmb3IgdjMuNz8KPj4+IFllcyBwbGVhc2UsIEkgaGF2ZSB0aGUgcGVyIGNwdSBsYXRlbmNpZXMg
cmVhZHkgdG8gYmUgc3VibWl0dGVkIGJ1dCBJCj4+PiB3YW50IHRvIGRvIGV4dHJhIHRlc3Rpbmcg
YmVmb3JlLiBVbmZvcnR1bmF0ZWx5LCB0aGUgbGludXgtcG0tbmV4dCBoYW5ncwo+Pj4gYXQgYm9v
dCB0aW1lIG9uIG15IGludGVsIGR1YWwgY29yZSAobm90IHJlbGF0ZWQgdG8gdGhlIHBhdGNoc2V0
KS4KPj4+Cj4+PiBJIGFtIGdpdCBiaXNlY3RpbmcgcmlnaHQgbm93Lgo+Pgo+PiBJIGZvdW5kIHRo
ZSBjdWxwcml0LiBUaGlzIGlzIG5vdCByZWxhdGVkIHRvIHRoZSBsaW51eC1wbSB0cmVlIGJ1dCB3
aXRoCj4+IG5ldC1uZXh0Lgo+PiBUaGUgZm9sbG93aW5nIHBhdGNoIGludHJvZHVjZWQgdGhlIGlz
c3VlLgo+Pgo+PiBjb21taXQgNmJkYjdmZTMxMDQ2YWM1MGI0N2U4M2MzNWNkNmM2YjYxNjBhNDc1
ZAo+PiBBdXRob3I6IEFtZXJpZ28gV2FuZyA8YW13YW5nQHJlZGhhdC5jb20+Cj4+IERhdGU6ICAg
RnJpIEF1ZyAxMCAwMToyNDo1MCAyMDEyICswMDAwCj4+Cj4+ICAgICBuZXRwb2xsOiByZS1lbmFi
bGUgaXJxIGluIHBvbGxfbmFwaSgpCj4+ICAgIAo+PiAgICAgbmFwaS0+cG9sbCgpIG5lZWRzIElS
USBlbmFibGVkLCBzbyB3ZSBoYXZlIHRvIHJlLWVuYWJsZSBJUlEgYmVmb3JlCj4+ICAgICBjYWxs
aW5nIGl0Lgo+PiAgICAKPj4gICAgIENjOiBEYXZpZCBNaWxsZXIgPGRhdmVtQGRhdmVtbG9mdC5u
ZXQ+Cj4+ICAgICBTaWduZWQtb2ZmLWJ5OiBDb25nIFdhbmcgPGFtd2FuZ0ByZWRoYXQuY29tPgo+
PiAgICAgU2lnbmVkLW9mZi1ieTogRGF2aWQgUy4gTWlsbGVyIDxkYXZlbUBkYXZlbWxvZnQubmV0
Pgo+Pgo+PiBBRkFJQ1MsIGl0IGhhcyBiZWVuIGZpeGVkIGJ5IGNvbW1pdAo+PiAwNzJhOWM0ODYw
MDQwOWQ3MmFlYjBkNWIyOWZiYjc1ODYxYTA2NjMxIHdoaWNoIGlzIG5vdCB5ZXQgaW4gbGludXgt
cG0tbmV4dC4KPiAKPiBJZiBpdCBpcyBwcmVzZW50IGluIHRoZSBjdXJyZW50IExpbnVzJyB0cmVl
LCB5b3UgY2FuIGp1c3QgcHVsbCB0aGlzIG9uZQo+IGFuZCBtZXJnZSBsaW51eC1wbS1uZXh0IGlu
dG8gaXQuICBJdCBzaG91bGQgbWVyZ2Ugd2l0aG91dCBjb25mbGljdHMuCgpPaywgdGhhbmtzLgoK
Pj4gSSBmYWxsIGludG8gdGhpcyBpc3N1ZSBiZWNhdXNlIE5FVENPTlNPTEUgaXMgc2V0LCBkaXNh
YmxpbmcgaXQgYWxsb3dlZAo+PiBtZSB0byBnbyBmdXJ0aGVyLgo+Pgo+PiBVbmZvcnR1bmF0ZWx5
IEkgYW0gZmFjaW5nIHRvIHNvbWUgcmFuZG9tIGZyZWV6ZSBvbiB0aGUgc3lzdGVtIHdoaWNoCj4+
IHNlZW1zIHRvIGJlIHJlbGF0ZWQgdG8gQ09ORklHX05PX0haPXkgYW5kIENPTkZJR19DUFVfSURM
RT15Lgo+Pgo+PiBEaXNhYmxpbmcgb25lIG9mIHRoZW0sIG1ha2UgdGhlIGZyZWV6ZXMgdG8gZGlz
YXBwZWFyLgo+Pgo+PiBJcyBpdCBhIGtub3duIGlzc3VlID8KPiAKPiBXZWxsLCB0aGVyZSBhcmUg
c3lzdGVtcyBoYXZpbmcgcHJvYmxlbXMgd2l0aCB0aGlzIGNvbmZpZ3VyYXRpb24sIGJ1dCB0aGV5
Cj4gc2hvdWxkIGJlIGV4Y2VwdGlvbmFsLiAgV2hhdCBzeXN0ZW0gaXMgdGhhdD8KCkl0IGlzIGEg
bGFwdG9wIFQ2MXAgd2l0aCBhIENvcmUgMiBEdW8gVDk1MDAuIE5vdGhpbmcgZXhjZXB0aW9uYWwg
SQpiZWxpZXZlLiBNYXliZSBzb21lb25lIGdvdCB0aGUgc2FtZSBpc3N1ZSA/CgotLSAKIDxodHRw
Oi8vd3d3LmxpbmFyby5vcmcvPiBMaW5hcm8ub3JnIOKUgiBPcGVuIHNvdXJjZSBzb2Z0d2FyZSBm
b3IgQVJNIFNvQ3MKCkZvbGxvdyBMaW5hcm86ICA8aHR0cDovL3d3dy5mYWNlYm9vay5jb20vcGFn
ZXMvTGluYXJvPiBGYWNlYm9vayB8CjxodHRwOi8vdHdpdHRlci5jb20vIyEvbGluYXJvb3JnPiBU
d2l0dGVyIHwKPGh0dHA6Ly93d3cubGluYXJvLm9yZy9saW5hcm8tYmxvZy8+IEJsb2cKCgpfX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpYZW4tZGV2ZWwgbWFp
bGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW4ub3JnCmh0dHA6Ly9saXN0cy54ZW4ub3JnL3hl
bi1kZXZlbAo=

From xen-devel-bounces@lists.xen.org Thu Sep 06 21:12:56 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 2012 21:12:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9jNB-0005pZ-L9; Thu, 06 Sep 2012 21:12:25 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <rjw@sisk.pl>)
	id 1T9jN9-0005pU-Uj
	for xen-devel@lists.xensource.com; Thu, 06 Sep 2012 21:12:24 +0000
Received: from [85.158.138.51:7075] by server-5.bemta-3.messagelabs.com id
	5D/D1-13133-7B119405; Thu, 06 Sep 2012 21:12:23 +0000
X-Env-Sender: rjw@sisk.pl
X-Msg-Ref: server-6.tower-174.messagelabs.com!1346965942!21106995!1
X-Originating-IP: [193.178.161.156]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2187 invoked from network); 6 Sep 2012 21:12:22 -0000
Received: from ogre.sisk.pl (HELO ogre.sisk.pl) (193.178.161.156)
	by server-6.tower-174.messagelabs.com with SMTP;
	6 Sep 2012 21:12:22 -0000
Received: from localhost (localhost.localdomain [127.0.0.1])
	by ogre.sisk.pl (Postfix) with ESMTP id 2A2701DD09A;
	Thu,  6 Sep 2012 23:15:51 +0200 (CEST)
Received: from ogre.sisk.pl ([127.0.0.1])
	by localhost (ogre.sisk.pl [127.0.0.1]) (amavisd-new,
	port 10024) with ESMTP
	id 04312-10; Thu,  6 Sep 2012 23:15:43 +0200 (CEST)
Received: from ferrari.rjw.lan (89-67-90-11.dynamic.chello.pl [89.67.90.11])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by ogre.sisk.pl (Postfix) with ESMTP id E8E291DD489;
	Thu,  6 Sep 2012 23:15:43 +0200 (CEST)
From: "Rafael J. Wysocki" <rjw@sisk.pl>
To: Daniel Lezcano <daniel.lezcano@linaro.org>
Date: Thu, 6 Sep 2012 23:18:42 +0200
User-Agent: KMail/1.13.6 (Linux/3.6.0-rc3+; KDE/4.6.0; x86_64; ; )
References: <1343164349-28550-1-git-send-email-daniel.lezcano@linaro.org>
	<201209062204.11288.rjw@sisk.pl> <50490920.9070204@linaro.org>
In-Reply-To: <50490920.9070204@linaro.org>
MIME-Version: 1.0
Message-Id: <201209062318.42874.rjw@sisk.pl>
X-Virus-Scanned: amavisd-new at ogre.sisk.pl using MkS_Vir for Linux
Cc: xen-devel@lists.xensource.com, linaro-dev@lists.linaro.org,
	linux-pm@vger.kernel.org, Frederic Weisbecker <fweisbec@gmail.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	linux-acpi@vger.kernel.org, lenb@kernel.org
Subject: Re: [Xen-devel] CONFIG_NO_HZ + CONFIG_CPU_IDLE freeze the system
	(Was Re: [PATCH] acpi : remove power from acpi_processor_cx
	structure)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thursday, September 06, 2012, Daniel Lezcano wrote:
> On 09/06/2012 10:04 PM, Rafael J. Wysocki wrote:
> > On Thursday, September 06, 2012, Daniel Lezcano wrote:
> >> On 09/06/2012 09:54 AM, Daniel Lezcano wrote:
> >>> On 09/05/2012 03:41 PM, Rafael J. Wysocki wrote:
> >>>> On Saturday, September 01, 2012, Rafael J. Wysocki wrote:
> >>>>> On Friday, August 31, 2012, Daniel Lezcano wrote:
> >>>>>> On 07/24/2012 11:06 PM, Konrad Rzeszutek Wilk wrote:
> >>>>>>> On Tue, Jul 24, 2012 at 11:12:29PM +0200, Daniel Lezcano wrote:
> >>>>>>>> Remove the power field as it is not used.
> >>>>>>>>
> >>>>>>>> Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
> >>>>>>>> Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> >>>>>>> Acked.
> >>>>>> Hi Rafael,
> >>>>>>
> >>>>>> I did not see this patch going in. Is it possible to merge it ?
> >>>>> I think so.  I'll take care of it when I get back from LinuxCon/Plumbers Conf.
> >>>>> (early next week).
> >>>> Applied to the linux-next branch of the linux-pm.git tree as v3.7 material.
> >>> Thanks Rafael.
> >>>
> >>>> Are there any other patches you want me to consider for v3.7?
> >>> Yes please, I have the per cpu latencies ready to be submitted but I
> >>> want to do extra testing before. Unfortunately, the linux-pm-next hangs
> >>> at boot time on my intel dual core (not related to the patchset).
> >>>
> >>> I am git bisecting right now.
> >>
> >> I found the culprit. This is not related to the linux-pm tree but with
> >> net-next.
> >> The following patch introduced the issue.
> >>
> >> commit 6bdb7fe31046ac50b47e83c35cd6c6b6160a475d
> >> Author: Amerigo Wang <amwang@redhat.com>
> >> Date:   Fri Aug 10 01:24:50 2012 +0000
> >>
> >>     netpoll: re-enable irq in poll_napi()
> >>    
> >>     napi->poll() needs IRQ enabled, so we have to re-enable IRQ before
> >>     calling it.
> >>    
> >>     Cc: David Miller <davem@davemloft.net>
> >>     Signed-off-by: Cong Wang <amwang@redhat.com>
> >>     Signed-off-by: David S. Miller <davem@davemloft.net>
> >>
> >> AFAICS, it has been fixed by commit
> >> 072a9c48600409d72aeb0d5b29fbb75861a06631 which is not yet in linux-pm-next.
> > 
> > If it is present in the current Linus' tree, you can just pull this one
> > and merge linux-pm-next into it.  It should merge without conflicts.
> 
> Ok, thanks.
> 
> >> I fall into this issue because NETCONSOLE is set, disabling it allowed
> >> me to go further.
> >>
> >> Unfortunately I am facing to some random freeze on the system which
> >> seems to be related to CONFIG_NO_HZ=y and CONFIG_CPU_IDLE=y.
> >>
> >> Disabling one of them, make the freezes to disappear.
> >>
> >> Is it a known issue ?
> > 
> > Well, there are systems having problems with this configuration, but they
> > should be exceptional.  What system is that?
> 
> It is a laptop T61p with a Core 2 Duo T9500. Nothing exceptional I
> believe. Maybe someone got the same issue ?

Is it a regression 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 Sep 06 21:12:56 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 2012 21:12:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9jNB-0005pZ-L9; Thu, 06 Sep 2012 21:12:25 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <rjw@sisk.pl>)
	id 1T9jN9-0005pU-Uj
	for xen-devel@lists.xensource.com; Thu, 06 Sep 2012 21:12:24 +0000
Received: from [85.158.138.51:7075] by server-5.bemta-3.messagelabs.com id
	5D/D1-13133-7B119405; Thu, 06 Sep 2012 21:12:23 +0000
X-Env-Sender: rjw@sisk.pl
X-Msg-Ref: server-6.tower-174.messagelabs.com!1346965942!21106995!1
X-Originating-IP: [193.178.161.156]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2187 invoked from network); 6 Sep 2012 21:12:22 -0000
Received: from ogre.sisk.pl (HELO ogre.sisk.pl) (193.178.161.156)
	by server-6.tower-174.messagelabs.com with SMTP;
	6 Sep 2012 21:12:22 -0000
Received: from localhost (localhost.localdomain [127.0.0.1])
	by ogre.sisk.pl (Postfix) with ESMTP id 2A2701DD09A;
	Thu,  6 Sep 2012 23:15:51 +0200 (CEST)
Received: from ogre.sisk.pl ([127.0.0.1])
	by localhost (ogre.sisk.pl [127.0.0.1]) (amavisd-new,
	port 10024) with ESMTP
	id 04312-10; Thu,  6 Sep 2012 23:15:43 +0200 (CEST)
Received: from ferrari.rjw.lan (89-67-90-11.dynamic.chello.pl [89.67.90.11])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by ogre.sisk.pl (Postfix) with ESMTP id E8E291DD489;
	Thu,  6 Sep 2012 23:15:43 +0200 (CEST)
From: "Rafael J. Wysocki" <rjw@sisk.pl>
To: Daniel Lezcano <daniel.lezcano@linaro.org>
Date: Thu, 6 Sep 2012 23:18:42 +0200
User-Agent: KMail/1.13.6 (Linux/3.6.0-rc3+; KDE/4.6.0; x86_64; ; )
References: <1343164349-28550-1-git-send-email-daniel.lezcano@linaro.org>
	<201209062204.11288.rjw@sisk.pl> <50490920.9070204@linaro.org>
In-Reply-To: <50490920.9070204@linaro.org>
MIME-Version: 1.0
Message-Id: <201209062318.42874.rjw@sisk.pl>
X-Virus-Scanned: amavisd-new at ogre.sisk.pl using MkS_Vir for Linux
Cc: xen-devel@lists.xensource.com, linaro-dev@lists.linaro.org,
	linux-pm@vger.kernel.org, Frederic Weisbecker <fweisbec@gmail.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	linux-acpi@vger.kernel.org, lenb@kernel.org
Subject: Re: [Xen-devel] CONFIG_NO_HZ + CONFIG_CPU_IDLE freeze the system
	(Was Re: [PATCH] acpi : remove power from acpi_processor_cx
	structure)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thursday, September 06, 2012, Daniel Lezcano wrote:
> On 09/06/2012 10:04 PM, Rafael J. Wysocki wrote:
> > On Thursday, September 06, 2012, Daniel Lezcano wrote:
> >> On 09/06/2012 09:54 AM, Daniel Lezcano wrote:
> >>> On 09/05/2012 03:41 PM, Rafael J. Wysocki wrote:
> >>>> On Saturday, September 01, 2012, Rafael J. Wysocki wrote:
> >>>>> On Friday, August 31, 2012, Daniel Lezcano wrote:
> >>>>>> On 07/24/2012 11:06 PM, Konrad Rzeszutek Wilk wrote:
> >>>>>>> On Tue, Jul 24, 2012 at 11:12:29PM +0200, Daniel Lezcano wrote:
> >>>>>>>> Remove the power field as it is not used.
> >>>>>>>>
> >>>>>>>> Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
> >>>>>>>> Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> >>>>>>> Acked.
> >>>>>> Hi Rafael,
> >>>>>>
> >>>>>> I did not see this patch going in. Is it possible to merge it ?
> >>>>> I think so.  I'll take care of it when I get back from LinuxCon/Plumbers Conf.
> >>>>> (early next week).
> >>>> Applied to the linux-next branch of the linux-pm.git tree as v3.7 material.
> >>> Thanks Rafael.
> >>>
> >>>> Are there any other patches you want me to consider for v3.7?
> >>> Yes please, I have the per cpu latencies ready to be submitted but I
> >>> want to do extra testing before. Unfortunately, the linux-pm-next hangs
> >>> at boot time on my intel dual core (not related to the patchset).
> >>>
> >>> I am git bisecting right now.
> >>
> >> I found the culprit. This is not related to the linux-pm tree but with
> >> net-next.
> >> The following patch introduced the issue.
> >>
> >> commit 6bdb7fe31046ac50b47e83c35cd6c6b6160a475d
> >> Author: Amerigo Wang <amwang@redhat.com>
> >> Date:   Fri Aug 10 01:24:50 2012 +0000
> >>
> >>     netpoll: re-enable irq in poll_napi()
> >>    
> >>     napi->poll() needs IRQ enabled, so we have to re-enable IRQ before
> >>     calling it.
> >>    
> >>     Cc: David Miller <davem@davemloft.net>
> >>     Signed-off-by: Cong Wang <amwang@redhat.com>
> >>     Signed-off-by: David S. Miller <davem@davemloft.net>
> >>
> >> AFAICS, it has been fixed by commit
> >> 072a9c48600409d72aeb0d5b29fbb75861a06631 which is not yet in linux-pm-next.
> > 
> > If it is present in the current Linus' tree, you can just pull this one
> > and merge linux-pm-next into it.  It should merge without conflicts.
> 
> Ok, thanks.
> 
> >> I fall into this issue because NETCONSOLE is set, disabling it allowed
> >> me to go further.
> >>
> >> Unfortunately I am facing to some random freeze on the system which
> >> seems to be related to CONFIG_NO_HZ=y and CONFIG_CPU_IDLE=y.
> >>
> >> Disabling one of them, make the freezes to disappear.
> >>
> >> Is it a known issue ?
> > 
> > Well, there are systems having problems with this configuration, but they
> > should be exceptional.  What system is that?
> 
> It is a laptop T61p with a Core 2 Duo T9500. Nothing exceptional I
> believe. Maybe someone got the same issue ?

Is it a regression 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 Sep 06 21:14:27 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 2012 21: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 1T9jOm-0005u6-58; Thu, 06 Sep 2012 21:14:04 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ketuzsezr@gmail.com>) id 1T9jOk-0005tv-0U
	for xen-devel@lists.xen.org; Thu, 06 Sep 2012 21:14:02 +0000
Received: from [85.158.139.83:29426] by server-3.bemta-5.messagelabs.com id
	64/7C-21836-91219405; Thu, 06 Sep 2012 21:14:01 +0000
X-Env-Sender: ketuzsezr@gmail.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1346966039!25091996!1
X-Originating-IP: [209.85.212.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22748 invoked from network); 6 Sep 2012 21:14:00 -0000
Received: from mail-vb0-f45.google.com (HELO mail-vb0-f45.google.com)
	(209.85.212.45)
	by server-7.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Sep 2012 21:14:00 -0000
Received: by vbip1 with SMTP id p1so2435014vbi.32
	for <xen-devel@lists.xen.org>; Thu, 06 Sep 2012 14:13:58 -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=nWOYihT3AFjllzChgh88WYE89dms28mULEdJ4GR5vso=;
	b=kxH9ILrR3cYqH3wE593m+j6kw+g9HBaYbnCMlX1FCML+NxgBKw2OATSuNFqo3HeJmJ
	SosJSLNzrAbcECTjVQLak465vxI1dOc4U2UTfYk3kulC5ovEeHpcAlU5x/dX+ObMcVgq
	5AFVFR8iOBvxteuumi2m7xO0PVllT2VYL45HzngWlv2FJ+P6DeL9H9UAewcYqJMG1q2D
	fR1AeAbGjlH1esB2Ah/iE7ftyS86Ht9ukysL+cpMgs8O4OCf1m7E1C76kCt3KejQH7LM
	KUdwoZG5+PB86OzXBnmXjYw2vQniK56ESvK2kpAXR266/6j7dLDeUeCNkyERXW7NtAg9
	5rhA==
Received: by 10.52.28.113 with SMTP id a17mr3476880vdh.47.1346966038607;
	Thu, 06 Sep 2012 14:13:58 -0700 (PDT)
Received: from phenom.dumpdata.com
	(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 s1sm2128983vdi.14.2012.09.06.14.13.57
	(version=TLSv1/SSLv3 cipher=OTHER);
	Thu, 06 Sep 2012 14:13:58 -0700 (PDT)
Date: Thu, 6 Sep 2012 17:03:24 -0400
From: Konrad Rzeszutek Wilk <konrad@kernel.org>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20120906210323.GA303@phenom.dumpdata.com>
References: <1343745804-28028-1-git-send-email-konrad.wilk@oracle.com>
	<20120801155040.GB15812@phenom.dumpdata.com>
	<501A5EF7020000780009219C@nat28.tlf.novell.com>
	<20120802141710.GF16749@phenom.dumpdata.com>
	<20120802160403.02de484e@mantra.us.oracle.com>
	<20120803133001.GA13750@andromeda.dapyr.net>
	<501BF44602000078000928B4@nat28.tlf.novell.com>
	<CAPbh3rsXaqQS9WQQmJ2uQ46LZdyFzkbSodUabGDAyFS+qTEwUg@mail.gmail.com>
	<5028CEE70200007800094623@nat28.tlf.novell.com>
	<50446B5402000078000981F4@nat28.tlf.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <50446B5402000078000981F4@nat28.tlf.novell.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: konrad@darnok.org, xen-devel <xen-devel@lists.xen.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] Ping: Re: [PATCH] Boot PV guests with more than
 128GB (v2) for 3.7
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Sep 03, 2012 at 07:33:24AM +0100, Jan Beulich wrote:
> >>> On 13.08.12 at 09:54, "Jan Beulich" <JBeulich@suse.com> wrote:
> >>>> On 03.08.12 at 16:46, Konrad Rzeszutek Wilk <konrad@darnok.org> wrote:
> >> Didn't get to it yet. Sorry for top posting. If you have a patch ready I
> >> can test it on Monday - travelling now.
> > 
> > So here's what I was thinking of (compile tested only).
> 
> Obviously, if this works, I'd like to see this included in 4.2 (and
> 4.1-testing).

No luck. I still get:

(XEN) Pagetable walk from ffff8800443da070:
(XEN)  L4[0x110] = 0000009342f95067 0000000000001a0c
(XEN)  L3[0x001] = 0000000000000000 ffffffffffffffff
(XEN) domain_crash_sync called from entry.S
(XEN) Domain 61 (vcpu#0) crashed on cpu#97:
(XEN) ----[ Xen-4.1.2-OVM  x86_64  debug=n  Not tainted ]----
(XEN) CPU:    97
(XEN) RIP:    e033:[<ffffffff81abf971>]
(XEN) RFLAGS: 0000000000000246   EM: 1   CONTEXT: pv guest
(XEN) rax: ffff8800443da000   rbx: 0000000000000000   rcx: 0000000000000001
(XEN) rdx: ffffffff81f76000   rsi: 0000000000000000   rdi: 0000000000000006
(XEN) rbp: ffffffff81a01ff8   rsp: ffffffff81a01f70   r8:  0000000000000000
(XEN) r9:  00000000443e0000   r10: 0000000000225000   r11: 0000008b00fc2067
(XEN) r12: 0000000000000000   r13: 0000000000000000   r14: 0000000000000000
(XEN) r15: 0000000000000000   cr0: 000000008005003b   cr4: 00000000000026f0
(XEN) cr3: 0000009342f96000   cr2: ffff8800443da070
(XEN) ds: 0000   es: 0000   fs: 0000   gs: 0000   ss: e02b   cs: e033
(XEN) Guest stack trace from rsp=ffffffff81a01f70:
(XEN)    0000000000000001 0000008b00fc2067 0000000000000000 ffffffff81abf971
(XEN)    000000010000e030 0000000000010046 ffffffff81a01fb8 000000000000e02b
(XEN)    ffffffff81abf918 0000000000000000 0000000000000000 0000000000000000
(XEN)    0000000000000000 80b822011f898975 000206e537200800 0000000000000001
(XEN)    0000000000000000 0000000000000000 0f00000060c0c748 ccccccccccccc305
(XEN)    cccccccccccccccc cccccccccccccccc cccccccccccccccc cccccccccccccccc
(XEN)    cccccccccccccccc cccccccccccccccc cccccccccccccccc cccccccccccccccc
(XEN)    cccccccccccccccc cccccccccccccccc cccccccccccccccc cccccccccccccccc
(XEN)    cccccccccccccccc cccccccccccccccc cccccccccccccccc cccccccccccccccc
(XEN)    cccccccccccccccc cccccccccccccccc cccccccccccccccc cccccccccccccccc
(XEN)    cccccccccccccccc cccccccccccccccc cccccccccccccccc cccccccccccccccc
(XEN)    cccccccccccccccc cccccccccccccccc cccccccccccccccc cccccccccccccccc
(XEN)    cccccccccccccccc cccccccccccccccc cccccccccccccccc cccccccccccccccc
(XEN)    cccccccccccccccc cccccccccccccccc cccccccccccccccc cccccccccccccccc
(XEN)    cccccccccccccccc cccccccccccccccc cccccccccccccccc cccccccccccccccc
(XEN)    cccccccccccccccc cccccccccccccccc cccccccccccccccc cccccccccccccccc
(XEN)    cccccccccccccccc cccccccccccccccc cccccccccccccccc cccccccccccccccc
(XEN)    cccccccccccccccc cccccccccccccccc cccccccccccccccc cccccccccccccccc
(XEN)    cccccccccccccccc cccccccccccccccc cccccccccccccccc cccccccccccccccc
(XEN)    cccccccccccccccc cccccccccccccccc cccccccccccccccc cccccccccccccccc


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 06 21:14:27 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 2012 21: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 1T9jOm-0005u6-58; Thu, 06 Sep 2012 21:14:04 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ketuzsezr@gmail.com>) id 1T9jOk-0005tv-0U
	for xen-devel@lists.xen.org; Thu, 06 Sep 2012 21:14:02 +0000
Received: from [85.158.139.83:29426] by server-3.bemta-5.messagelabs.com id
	64/7C-21836-91219405; Thu, 06 Sep 2012 21:14:01 +0000
X-Env-Sender: ketuzsezr@gmail.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1346966039!25091996!1
X-Originating-IP: [209.85.212.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22748 invoked from network); 6 Sep 2012 21:14:00 -0000
Received: from mail-vb0-f45.google.com (HELO mail-vb0-f45.google.com)
	(209.85.212.45)
	by server-7.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Sep 2012 21:14:00 -0000
Received: by vbip1 with SMTP id p1so2435014vbi.32
	for <xen-devel@lists.xen.org>; Thu, 06 Sep 2012 14:13:58 -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=nWOYihT3AFjllzChgh88WYE89dms28mULEdJ4GR5vso=;
	b=kxH9ILrR3cYqH3wE593m+j6kw+g9HBaYbnCMlX1FCML+NxgBKw2OATSuNFqo3HeJmJ
	SosJSLNzrAbcECTjVQLak465vxI1dOc4U2UTfYk3kulC5ovEeHpcAlU5x/dX+ObMcVgq
	5AFVFR8iOBvxteuumi2m7xO0PVllT2VYL45HzngWlv2FJ+P6DeL9H9UAewcYqJMG1q2D
	fR1AeAbGjlH1esB2Ah/iE7ftyS86Ht9ukysL+cpMgs8O4OCf1m7E1C76kCt3KejQH7LM
	KUdwoZG5+PB86OzXBnmXjYw2vQniK56ESvK2kpAXR266/6j7dLDeUeCNkyERXW7NtAg9
	5rhA==
Received: by 10.52.28.113 with SMTP id a17mr3476880vdh.47.1346966038607;
	Thu, 06 Sep 2012 14:13:58 -0700 (PDT)
Received: from phenom.dumpdata.com
	(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 s1sm2128983vdi.14.2012.09.06.14.13.57
	(version=TLSv1/SSLv3 cipher=OTHER);
	Thu, 06 Sep 2012 14:13:58 -0700 (PDT)
Date: Thu, 6 Sep 2012 17:03:24 -0400
From: Konrad Rzeszutek Wilk <konrad@kernel.org>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20120906210323.GA303@phenom.dumpdata.com>
References: <1343745804-28028-1-git-send-email-konrad.wilk@oracle.com>
	<20120801155040.GB15812@phenom.dumpdata.com>
	<501A5EF7020000780009219C@nat28.tlf.novell.com>
	<20120802141710.GF16749@phenom.dumpdata.com>
	<20120802160403.02de484e@mantra.us.oracle.com>
	<20120803133001.GA13750@andromeda.dapyr.net>
	<501BF44602000078000928B4@nat28.tlf.novell.com>
	<CAPbh3rsXaqQS9WQQmJ2uQ46LZdyFzkbSodUabGDAyFS+qTEwUg@mail.gmail.com>
	<5028CEE70200007800094623@nat28.tlf.novell.com>
	<50446B5402000078000981F4@nat28.tlf.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <50446B5402000078000981F4@nat28.tlf.novell.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: konrad@darnok.org, xen-devel <xen-devel@lists.xen.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] Ping: Re: [PATCH] Boot PV guests with more than
 128GB (v2) for 3.7
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Sep 03, 2012 at 07:33:24AM +0100, Jan Beulich wrote:
> >>> On 13.08.12 at 09:54, "Jan Beulich" <JBeulich@suse.com> wrote:
> >>>> On 03.08.12 at 16:46, Konrad Rzeszutek Wilk <konrad@darnok.org> wrote:
> >> Didn't get to it yet. Sorry for top posting. If you have a patch ready I
> >> can test it on Monday - travelling now.
> > 
> > So here's what I was thinking of (compile tested only).
> 
> Obviously, if this works, I'd like to see this included in 4.2 (and
> 4.1-testing).

No luck. I still get:

(XEN) Pagetable walk from ffff8800443da070:
(XEN)  L4[0x110] = 0000009342f95067 0000000000001a0c
(XEN)  L3[0x001] = 0000000000000000 ffffffffffffffff
(XEN) domain_crash_sync called from entry.S
(XEN) Domain 61 (vcpu#0) crashed on cpu#97:
(XEN) ----[ Xen-4.1.2-OVM  x86_64  debug=n  Not tainted ]----
(XEN) CPU:    97
(XEN) RIP:    e033:[<ffffffff81abf971>]
(XEN) RFLAGS: 0000000000000246   EM: 1   CONTEXT: pv guest
(XEN) rax: ffff8800443da000   rbx: 0000000000000000   rcx: 0000000000000001
(XEN) rdx: ffffffff81f76000   rsi: 0000000000000000   rdi: 0000000000000006
(XEN) rbp: ffffffff81a01ff8   rsp: ffffffff81a01f70   r8:  0000000000000000
(XEN) r9:  00000000443e0000   r10: 0000000000225000   r11: 0000008b00fc2067
(XEN) r12: 0000000000000000   r13: 0000000000000000   r14: 0000000000000000
(XEN) r15: 0000000000000000   cr0: 000000008005003b   cr4: 00000000000026f0
(XEN) cr3: 0000009342f96000   cr2: ffff8800443da070
(XEN) ds: 0000   es: 0000   fs: 0000   gs: 0000   ss: e02b   cs: e033
(XEN) Guest stack trace from rsp=ffffffff81a01f70:
(XEN)    0000000000000001 0000008b00fc2067 0000000000000000 ffffffff81abf971
(XEN)    000000010000e030 0000000000010046 ffffffff81a01fb8 000000000000e02b
(XEN)    ffffffff81abf918 0000000000000000 0000000000000000 0000000000000000
(XEN)    0000000000000000 80b822011f898975 000206e537200800 0000000000000001
(XEN)    0000000000000000 0000000000000000 0f00000060c0c748 ccccccccccccc305
(XEN)    cccccccccccccccc cccccccccccccccc cccccccccccccccc cccccccccccccccc
(XEN)    cccccccccccccccc cccccccccccccccc cccccccccccccccc cccccccccccccccc
(XEN)    cccccccccccccccc cccccccccccccccc cccccccccccccccc cccccccccccccccc
(XEN)    cccccccccccccccc cccccccccccccccc cccccccccccccccc cccccccccccccccc
(XEN)    cccccccccccccccc cccccccccccccccc cccccccccccccccc cccccccccccccccc
(XEN)    cccccccccccccccc cccccccccccccccc cccccccccccccccc cccccccccccccccc
(XEN)    cccccccccccccccc cccccccccccccccc cccccccccccccccc cccccccccccccccc
(XEN)    cccccccccccccccc cccccccccccccccc cccccccccccccccc cccccccccccccccc
(XEN)    cccccccccccccccc cccccccccccccccc cccccccccccccccc cccccccccccccccc
(XEN)    cccccccccccccccc cccccccccccccccc cccccccccccccccc cccccccccccccccc
(XEN)    cccccccccccccccc cccccccccccccccc cccccccccccccccc cccccccccccccccc
(XEN)    cccccccccccccccc cccccccccccccccc cccccccccccccccc cccccccccccccccc
(XEN)    cccccccccccccccc cccccccccccccccc cccccccccccccccc cccccccccccccccc
(XEN)    cccccccccccccccc cccccccccccccccc cccccccccccccccc cccccccccccccccc
(XEN)    cccccccccccccccc cccccccccccccccc cccccccccccccccc cccccccccccccccc


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 06 22:33:45 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 2012 22: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 1T9kdV-0007R0-DQ; Thu, 06 Sep 2012 22:33:21 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <karrelsj@gmail.com>) id 1T9kdT-0007Qv-VF
	for xen-devel@lists.xen.org; Thu, 06 Sep 2012 22:33:20 +0000
X-Env-Sender: karrelsj@gmail.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1346970793!9137436!1
X-Originating-IP: [74.125.82.51]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5687 invoked from network); 6 Sep 2012 22:33:14 -0000
Received: from mail-wg0-f51.google.com (HELO mail-wg0-f51.google.com)
	(74.125.82.51)
	by server-3.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Sep 2012 22:33:14 -0000
Received: by wgbed3 with SMTP id ed3so1455306wgb.32
	for <xen-devel@lists.xen.org>; Thu, 06 Sep 2012 15:33:13 -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:cc:content-type;
	bh=Fr7s2n8ei72fhTQsAVnAZNj4vCRDJiadKjANrwWkGdo=;
	b=XDKShWx4oReR8YG7hSt6N92phSROfKcRYo9ZBCZB0nwJoKD0OCTxMAT+Uy2VO69l5E
	BLHkyl4Sv0B7vnFxZVBqBTiLt1ifnP4PH95Wi1P4iCF/W/hHiMxuWDUp+LFBRcY8zzzB
	pj6CYEfq/J6ahfGOgjLkIE8h1DpuT9psEJWvqoP4OH/ACe+tqWFMG0+9nhKXWmz5Giur
	eE7XB7Ghqr94pJwI8SspjwCsKTtWOY5hxK+pPe4Khb/d9AIQOPpz1jZ+hvRAqb6nzAfG
	c4pu9ilTpcXATQxCjBu3jqIPTTj4EJjFLv1xwQOkb/a5SCHpSR1/k9RaVKPQXPI1A9DK
	Q1aQ==
Received: by 10.180.97.135 with SMTP id ea7mr48642105wib.11.1346970793688;
	Thu, 06 Sep 2012 15:33:13 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.216.255.79 with HTTP; Thu, 6 Sep 2012 15:32:53 -0700 (PDT)
From: Jeffrey Karrels <karrelsj@gmail.com>
Date: Thu, 6 Sep 2012 15:32:53 -0700
Message-ID: <CAFw--Dd0k7L+T_UJc0yHAkUGrY_-GDHaQjK3OM-1UdOp=J-wAQ@mail.gmail.com>
To: tim@xen.org
Cc: xen-devel@lists.xen.org
Subject: [Xen-devel] Clang/LLVM version requirements
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Is there a required Clang and LLVM version one needs to do a 'make
xen-dist clang=y'?

I recently tried and the process failed. I haven't begun debugging as
I figured I would ask the obvious first. The build failed with the
following:

...
make[4]: Entering directory `/home/builder/xen-unstable/xen/drivers'
make -f /home/builder/xen-unstable/xen/Rules.mk -C char built_in.o
make[5]: Entering directory `/home/builder/xen-unstable/xen/drivers/char'
clang -O1 -fno-omit-frame-pointer -m64 -g -fno-strict-aliasing
-std=gnu99 -Wall -Wstrict-prototypes -Wdeclaration-after-statement
-fno-builtin -fno-common -Wredundant-decls -iwithprefix include
-Werror -Wno-pointer-arith -pipe
-I/home/builder/xen-unstable/xen/include
-I/home/builder/xen-unstable/xen/include/asm-x86/mach-generic
-I/home/builder/xen-unstable/xen/include/asm-x86/mach-default
-msoft-float -fno-stack-protector -fno-exceptions -Wnested-externs
-mno-red-zone -mno-sse -fpic -fno-asynchronous-unwind-tables
-DGCC_HAS_VISIBILITY_ATTRIBUTE -Wno-parentheses -Wno-format
-Wno-unused-value -g -D__XEN__ -include
/home/builder/xen-unstable/xen/include/xen/config.h -DVERBOSE
-DHAS_ACPI -DHAS_GDBSX -DHAS_PASSTHROUGH -fno-omit-frame-pointer
-DCONFIG_FRAME_POINTER -MMD -MF .console.o.d -c console.c -o console.o
...
"error in backend: Invalid operand for inline asm constraint 'i'!"

Here are my details:
[builder@xenbuild1 xen-unstable]$ uname -a
Linux xenbuild1.cyberlab 2.6.32-220.el6.x86_64 #1 SMP Tue Dec 6
19:48:22 GMT 2011 x86_64 x86_64 x86_64 GNU/Linux

[builder@xenbuild1 xen-unstable]$ hg summary
parent: 25813:9dc729b75595 tip

[builder@xenbuild1 char]$ clang -v
clang version 2.8 (branches/release_28)
Target: x86_64-redhat-linux-gnu
Thread model: posix

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 06 22:33:45 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 2012 22: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 1T9kdV-0007R0-DQ; Thu, 06 Sep 2012 22:33:21 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <karrelsj@gmail.com>) id 1T9kdT-0007Qv-VF
	for xen-devel@lists.xen.org; Thu, 06 Sep 2012 22:33:20 +0000
X-Env-Sender: karrelsj@gmail.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1346970793!9137436!1
X-Originating-IP: [74.125.82.51]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5687 invoked from network); 6 Sep 2012 22:33:14 -0000
Received: from mail-wg0-f51.google.com (HELO mail-wg0-f51.google.com)
	(74.125.82.51)
	by server-3.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Sep 2012 22:33:14 -0000
Received: by wgbed3 with SMTP id ed3so1455306wgb.32
	for <xen-devel@lists.xen.org>; Thu, 06 Sep 2012 15:33:13 -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:cc:content-type;
	bh=Fr7s2n8ei72fhTQsAVnAZNj4vCRDJiadKjANrwWkGdo=;
	b=XDKShWx4oReR8YG7hSt6N92phSROfKcRYo9ZBCZB0nwJoKD0OCTxMAT+Uy2VO69l5E
	BLHkyl4Sv0B7vnFxZVBqBTiLt1ifnP4PH95Wi1P4iCF/W/hHiMxuWDUp+LFBRcY8zzzB
	pj6CYEfq/J6ahfGOgjLkIE8h1DpuT9psEJWvqoP4OH/ACe+tqWFMG0+9nhKXWmz5Giur
	eE7XB7Ghqr94pJwI8SspjwCsKTtWOY5hxK+pPe4Khb/d9AIQOPpz1jZ+hvRAqb6nzAfG
	c4pu9ilTpcXATQxCjBu3jqIPTTj4EJjFLv1xwQOkb/a5SCHpSR1/k9RaVKPQXPI1A9DK
	Q1aQ==
Received: by 10.180.97.135 with SMTP id ea7mr48642105wib.11.1346970793688;
	Thu, 06 Sep 2012 15:33:13 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.216.255.79 with HTTP; Thu, 6 Sep 2012 15:32:53 -0700 (PDT)
From: Jeffrey Karrels <karrelsj@gmail.com>
Date: Thu, 6 Sep 2012 15:32:53 -0700
Message-ID: <CAFw--Dd0k7L+T_UJc0yHAkUGrY_-GDHaQjK3OM-1UdOp=J-wAQ@mail.gmail.com>
To: tim@xen.org
Cc: xen-devel@lists.xen.org
Subject: [Xen-devel] Clang/LLVM version requirements
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Is there a required Clang and LLVM version one needs to do a 'make
xen-dist clang=y'?

I recently tried and the process failed. I haven't begun debugging as
I figured I would ask the obvious first. The build failed with the
following:

...
make[4]: Entering directory `/home/builder/xen-unstable/xen/drivers'
make -f /home/builder/xen-unstable/xen/Rules.mk -C char built_in.o
make[5]: Entering directory `/home/builder/xen-unstable/xen/drivers/char'
clang -O1 -fno-omit-frame-pointer -m64 -g -fno-strict-aliasing
-std=gnu99 -Wall -Wstrict-prototypes -Wdeclaration-after-statement
-fno-builtin -fno-common -Wredundant-decls -iwithprefix include
-Werror -Wno-pointer-arith -pipe
-I/home/builder/xen-unstable/xen/include
-I/home/builder/xen-unstable/xen/include/asm-x86/mach-generic
-I/home/builder/xen-unstable/xen/include/asm-x86/mach-default
-msoft-float -fno-stack-protector -fno-exceptions -Wnested-externs
-mno-red-zone -mno-sse -fpic -fno-asynchronous-unwind-tables
-DGCC_HAS_VISIBILITY_ATTRIBUTE -Wno-parentheses -Wno-format
-Wno-unused-value -g -D__XEN__ -include
/home/builder/xen-unstable/xen/include/xen/config.h -DVERBOSE
-DHAS_ACPI -DHAS_GDBSX -DHAS_PASSTHROUGH -fno-omit-frame-pointer
-DCONFIG_FRAME_POINTER -MMD -MF .console.o.d -c console.c -o console.o
...
"error in backend: Invalid operand for inline asm constraint 'i'!"

Here are my details:
[builder@xenbuild1 xen-unstable]$ uname -a
Linux xenbuild1.cyberlab 2.6.32-220.el6.x86_64 #1 SMP Tue Dec 6
19:48:22 GMT 2011 x86_64 x86_64 x86_64 GNU/Linux

[builder@xenbuild1 xen-unstable]$ hg summary
parent: 25813:9dc729b75595 tip

[builder@xenbuild1 char]$ clang -v
clang version 2.8 (branches/release_28)
Target: x86_64-redhat-linux-gnu
Thread model: posix

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 06 22:56:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 2012 22: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 1T9kzO-0007mb-EP; Thu, 06 Sep 2012 22: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 1T9kzN-0007mW-75
	for xen-devel@lists.xensource.com; Thu, 06 Sep 2012 22:55:57 +0000
Received: from [85.158.143.35:38384] by server-2.bemta-4.messagelabs.com id
	D2/40-21239-CF929405; Thu, 06 Sep 2012 22:55:56 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1346972155!13789382!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTIxNDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27068 invoked from network); 6 Sep 2012 22:55: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;
	6 Sep 2012 22:55:55 -0000
X-IronPort-AV: E=Sophos;i="4.80,381,1344211200"; d="scan'208";a="14396831"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Sep 2012 22:55: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.279.1; Thu, 6 Sep 2012 23:55: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 1T9kzK-0003CE-7t;
	Thu, 06 Sep 2012 22:55:54 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1T9kzK-0006Xh-2j;
	Thu, 06 Sep 2012 23:55:54 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-13658-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 6 Sep 2012 23:55:54 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13658: 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 13658 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13658/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore            fail   like 13656
 test-i386-i386-xl-qemuu-winxpsp3  9 guest-localmigrate         fail like 13656
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail like 13656
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail like 13656

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass

version targeted for testing:
 xen                  cbc0c2368a6d
baseline version:
 xen                  cbc0c2368a6d

jobs:
 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                                 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                                     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 Sep 06 22:56:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 06 Sep 2012 22: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 1T9kzO-0007mb-EP; Thu, 06 Sep 2012 22: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 1T9kzN-0007mW-75
	for xen-devel@lists.xensource.com; Thu, 06 Sep 2012 22:55:57 +0000
Received: from [85.158.143.35:38384] by server-2.bemta-4.messagelabs.com id
	D2/40-21239-CF929405; Thu, 06 Sep 2012 22:55:56 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1346972155!13789382!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTIxNDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27068 invoked from network); 6 Sep 2012 22:55: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;
	6 Sep 2012 22:55:55 -0000
X-IronPort-AV: E=Sophos;i="4.80,381,1344211200"; d="scan'208";a="14396831"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Sep 2012 22:55: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.279.1; Thu, 6 Sep 2012 23:55: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 1T9kzK-0003CE-7t;
	Thu, 06 Sep 2012 22:55:54 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1T9kzK-0006Xh-2j;
	Thu, 06 Sep 2012 23:55:54 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-13658-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 6 Sep 2012 23:55:54 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13658: 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 13658 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13658/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore            fail   like 13656
 test-i386-i386-xl-qemuu-winxpsp3  9 guest-localmigrate         fail like 13656
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail like 13656
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail like 13656

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass

version targeted for testing:
 xen                  cbc0c2368a6d
baseline version:
 xen                  cbc0c2368a6d

jobs:
 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                                 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                                     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 Sep 07 00:25:39 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Sep 2012 00: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 1T9mNi-0000kv-UO; Fri, 07 Sep 2012 00:25:10 +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 1T9mNh-0000ki-HP
	for xen-devel@lists.xen.org; Fri, 07 Sep 2012 00:25:09 +0000
Received: from [85.158.143.99:45392] by server-3.bemta-4.messagelabs.com id
	87/B7-08232-4EE39405; Fri, 07 Sep 2012 00:25:08 +0000
X-Env-Sender: yang.z.zhang@intel.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1346977507!28662962!1
X-Originating-IP: [192.55.52.93]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjkzID0+IDM0NjExMg==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15318 invoked from network); 7 Sep 2012 00:25:07 -0000
Received: from mga11.intel.com (HELO mga11.intel.com) (192.55.52.93)
	by server-5.tower-216.messagelabs.com with SMTP;
	7 Sep 2012 00:25:07 -0000
Received: from fmsmga002.fm.intel.com ([10.253.24.26])
	by fmsmga102.fm.intel.com with ESMTP; 06 Sep 2012 17:25:06 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.80,382,1344236400"; d="scan'208";a="218825340"
Received: from fmsmsx104.amr.corp.intel.com ([10.19.9.35])
	by fmsmga002.fm.intel.com with ESMTP; 06 Sep 2012 17:25:06 -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, 6 Sep 2012 17:25:06 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.239]) by
	SHSMSX102.ccr.corp.intel.com ([169.254.2.92]) with mapi id
	14.01.0355.002; Fri, 7 Sep 2012 08:25:04 +0800
From: "Zhang, Yang Z" <yang.z.zhang@intel.com>
To: Jan Beulich <JBeulich@suse.com>, "Li, Jiongxi" <jiongxi.li@intel.com>
Thread-Topic: [Xen-devel] [ PATCH 2/2] xen: enable Virtual-interrupt delivery
Thread-Index: AQHNh3S1P5TL6y3yYk23uPXy04inPpd+ABIQ
Date: Fri, 7 Sep 2012 00:25:03 +0000
Message-ID: <A9667DDFB95DB7438FA9D7D576C3D87E24D34C@SHSMSX101.ccr.corp.intel.com>
References: <D9137FCD9CFF644B965863BCFBEDABB8779942@SHSMSX101.ccr.corp.intel.com>
	<5040CAB30200007800097D73@nat28.tlf.novell.com>
In-Reply-To: <5040CAB30200007800097D73@nat28.tlf.novell.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [ PATCH 2/2] xen: enable Virtual-interrupt 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

Jan Beulich wrote on 2012-08-31:
>>>> On 31.08.12 at 11:30, "Li, Jiongxi" <jiongxi.li@intel.com> wrote:
>> +/*
>> + * When "Virtual Interrupt Delivery" is enabled, this function is used
>> + * to handle EOI-induced VM exit
>> + */
>> +void vlapic_handle_EOI_induced_exit(struct vlapic *vlapic, int vector)
>> +{
>> +    ASSERT(cpu_has_vmx_virtual_intr_delivery);
>> +
>> +    if ( vlapic_test_and_clear_vector(vector,
> &vlapic->regs->data[APIC_TMR]) )
> 
> Why test_and_clear rather than just test?

The current logic requires to clear it when guest writes EOI. When VCPU received an interrupt, it set the TMR if it is a level trigger interrupt and do nothing if it is edge triggered(it assumes the corresponding bit in TMR is clear).

>> +    {
>> +        vioapic_update_EOI(vlapic_domain(vlapic), vector);
>> +    }
>> +
>> +    hvm_dpci_msi_eoi(current->domain, vector);
>> +}
>> ...
>> --- a/xen/arch/x86/hvm/vmx/intr.c Fri Aug 31 09:30:38 2012 +0800
>> +++ b/xen/arch/x86/hvm/vmx/intr.c       Fri Aug 31 09:49:39 2012 +0800
>> @@ -227,19 +227,43 @@ void vmx_intr_assist(void)
>>              goto out;
>>          intblk = hvm_interrupt_blocked(v, intack);
>> -        if ( intblk == hvm_intblk_tpr )
>> +        if ( cpu_has_vmx_virtual_intr_delivery )
>>          {
>> -            ASSERT(vlapic_enabled(vcpu_vlapic(v))); -           
>> ASSERT(intack.source == hvm_intsrc_lapic); -            tpr_threshold =
>> intack.vector >> 4; -            goto out; +            /* Set
>> "Interrupt-window exiting" for ExtINT */ +            if ( (intblk !=
>> hvm_intblk_none) && +                 ( (intack.source ==
>> hvm_intsrc_pic) || +                 ( intack.source ==
>> hvm_intsrc_vector) ) ) +            { +               
>> enable_intr_window(v, intack); +                goto out; +           
>> } + +            if ( __vmread(VM_ENTRY_INTR_INFO) &
>> INTR_INFO_VALID_MASK ) +            { +                if (
>> (intack.source == hvm_intsrc_pic) || +                    
>> (intack.source == hvm_intsrc_nmi) || +                    
>> (intack.source == hvm_intsrc_mce) ) +                   
>> enable_intr_window(v, intack); + +                goto out; +          
>>  }
>>          }
>> +        else
>> +        {
>> +            if ( intblk == hvm_intblk_tpr )
>> +            {
>> +                ASSERT(vlapic_enabled(vcpu_vlapic(v)));
>> +                ASSERT(intack.source == hvm_intsrc_lapic);
>> +                tpr_threshold = intack.vector >> 4;
>> +                goto out;
>> +            }
>> 
>> -        if ( (intblk != hvm_intblk_none) || -            
>> (__vmread(VM_ENTRY_INTR_INFO) & INTR_INFO_VALID_MASK) ) -        { -   
>>         enable_intr_window(v, intack); -            goto out; +        
>>    if ( (intblk != hvm_intblk_none) || +                
>> (__vmread(VM_ENTRY_INTR_INFO) & INTR_INFO_VALID_MASK) ) +            {
>> +                enable_intr_window(v, intack); +                goto
>> out; +            }
>>          }
> 
> If you made the above and if()/else if() series, some of the
> differences would go away, making the changes easier to
> review.
> 
>> 
>>          intack = hvm_vcpu_ack_pending_irq(v, intack);
>> @@ -253,6 +277,29 @@ void vmx_intr_assist(void)
>>      {
>>          hvm_inject_hw_exception(TRAP_machine_check,
> HVM_DELIVER_NO_ERROR_CODE);
>>      }
>> +    else if ( cpu_has_vmx_virtual_intr_delivery &&
>> +              intack.source != hvm_intsrc_pic &&
>> +              intack.source != hvm_intsrc_vector )
>> +    {
>> +        /* we need update the RVI field */
>> +        unsigned long status = __vmread(GUEST_INTR_STATUS);
>> +        status &= ~(unsigned long)0x0FF;
>> +        status |= (unsigned long)0x0FF &
>> +                    intack.vector;
>> +        __vmwrite(GUEST_INTR_STATUS, status);
>> +        if (v->arch.hvm_vmx.eoi_exitmap_changed) {
>> +#define UPDATE_EOI_EXITMAP(v, e) {                             \
>> +        if (test_and_clear_bit(e, &(v).eoi_exitmap_changed)) {      \
> 
> Here and elsewhere - do you really need locked accesses?
>
>> +                __vmwrite(EOI_EXIT_BITMAP##e,
>> (v).eoi_exit_bitmap[e]);}} + +               
>> UPDATE_EOI_EXITMAP(v->arch.hvm_vmx, 0);
> 
> This is not very logical: Passing just 'v' to the macro, and accessing
> the full field there would be more consistent.
> 
> Furthermore, here and in other places you fail to write the upper halves
> for 32-bit, yet you also don't disable the code for 32-bit afaics.
> 
>> +                UPDATE_EOI_EXITMAP(v->arch.hvm_vmx, 1);
>> +                UPDATE_EOI_EXITMAP(v->arch.hvm_vmx, 2);
>> +                UPDATE_EOI_EXITMAP(v->arch.hvm_vmx, 3);
>> +        }
>> +
>> +        pt_intr_post(v, intack);
>> +    }
>>      else
>>      {
>>          HVMTRACE_2D(INJ_VIRQ, intack.vector, /*fake=*/ 0);
> 
> Jan
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel


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 Sep 07 00:25:39 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Sep 2012 00: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 1T9mNi-0000kv-UO; Fri, 07 Sep 2012 00:25:10 +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 1T9mNh-0000ki-HP
	for xen-devel@lists.xen.org; Fri, 07 Sep 2012 00:25:09 +0000
Received: from [85.158.143.99:45392] by server-3.bemta-4.messagelabs.com id
	87/B7-08232-4EE39405; Fri, 07 Sep 2012 00:25:08 +0000
X-Env-Sender: yang.z.zhang@intel.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1346977507!28662962!1
X-Originating-IP: [192.55.52.93]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjkzID0+IDM0NjExMg==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15318 invoked from network); 7 Sep 2012 00:25:07 -0000
Received: from mga11.intel.com (HELO mga11.intel.com) (192.55.52.93)
	by server-5.tower-216.messagelabs.com with SMTP;
	7 Sep 2012 00:25:07 -0000
Received: from fmsmga002.fm.intel.com ([10.253.24.26])
	by fmsmga102.fm.intel.com with ESMTP; 06 Sep 2012 17:25:06 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.80,382,1344236400"; d="scan'208";a="218825340"
Received: from fmsmsx104.amr.corp.intel.com ([10.19.9.35])
	by fmsmga002.fm.intel.com with ESMTP; 06 Sep 2012 17:25:06 -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, 6 Sep 2012 17:25:06 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.239]) by
	SHSMSX102.ccr.corp.intel.com ([169.254.2.92]) with mapi id
	14.01.0355.002; Fri, 7 Sep 2012 08:25:04 +0800
From: "Zhang, Yang Z" <yang.z.zhang@intel.com>
To: Jan Beulich <JBeulich@suse.com>, "Li, Jiongxi" <jiongxi.li@intel.com>
Thread-Topic: [Xen-devel] [ PATCH 2/2] xen: enable Virtual-interrupt delivery
Thread-Index: AQHNh3S1P5TL6y3yYk23uPXy04inPpd+ABIQ
Date: Fri, 7 Sep 2012 00:25:03 +0000
Message-ID: <A9667DDFB95DB7438FA9D7D576C3D87E24D34C@SHSMSX101.ccr.corp.intel.com>
References: <D9137FCD9CFF644B965863BCFBEDABB8779942@SHSMSX101.ccr.corp.intel.com>
	<5040CAB30200007800097D73@nat28.tlf.novell.com>
In-Reply-To: <5040CAB30200007800097D73@nat28.tlf.novell.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [ PATCH 2/2] xen: enable Virtual-interrupt 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

Jan Beulich wrote on 2012-08-31:
>>>> On 31.08.12 at 11:30, "Li, Jiongxi" <jiongxi.li@intel.com> wrote:
>> +/*
>> + * When "Virtual Interrupt Delivery" is enabled, this function is used
>> + * to handle EOI-induced VM exit
>> + */
>> +void vlapic_handle_EOI_induced_exit(struct vlapic *vlapic, int vector)
>> +{
>> +    ASSERT(cpu_has_vmx_virtual_intr_delivery);
>> +
>> +    if ( vlapic_test_and_clear_vector(vector,
> &vlapic->regs->data[APIC_TMR]) )
> 
> Why test_and_clear rather than just test?

The current logic requires to clear it when guest writes EOI. When VCPU received an interrupt, it set the TMR if it is a level trigger interrupt and do nothing if it is edge triggered(it assumes the corresponding bit in TMR is clear).

>> +    {
>> +        vioapic_update_EOI(vlapic_domain(vlapic), vector);
>> +    }
>> +
>> +    hvm_dpci_msi_eoi(current->domain, vector);
>> +}
>> ...
>> --- a/xen/arch/x86/hvm/vmx/intr.c Fri Aug 31 09:30:38 2012 +0800
>> +++ b/xen/arch/x86/hvm/vmx/intr.c       Fri Aug 31 09:49:39 2012 +0800
>> @@ -227,19 +227,43 @@ void vmx_intr_assist(void)
>>              goto out;
>>          intblk = hvm_interrupt_blocked(v, intack);
>> -        if ( intblk == hvm_intblk_tpr )
>> +        if ( cpu_has_vmx_virtual_intr_delivery )
>>          {
>> -            ASSERT(vlapic_enabled(vcpu_vlapic(v))); -           
>> ASSERT(intack.source == hvm_intsrc_lapic); -            tpr_threshold =
>> intack.vector >> 4; -            goto out; +            /* Set
>> "Interrupt-window exiting" for ExtINT */ +            if ( (intblk !=
>> hvm_intblk_none) && +                 ( (intack.source ==
>> hvm_intsrc_pic) || +                 ( intack.source ==
>> hvm_intsrc_vector) ) ) +            { +               
>> enable_intr_window(v, intack); +                goto out; +           
>> } + +            if ( __vmread(VM_ENTRY_INTR_INFO) &
>> INTR_INFO_VALID_MASK ) +            { +                if (
>> (intack.source == hvm_intsrc_pic) || +                    
>> (intack.source == hvm_intsrc_nmi) || +                    
>> (intack.source == hvm_intsrc_mce) ) +                   
>> enable_intr_window(v, intack); + +                goto out; +          
>>  }
>>          }
>> +        else
>> +        {
>> +            if ( intblk == hvm_intblk_tpr )
>> +            {
>> +                ASSERT(vlapic_enabled(vcpu_vlapic(v)));
>> +                ASSERT(intack.source == hvm_intsrc_lapic);
>> +                tpr_threshold = intack.vector >> 4;
>> +                goto out;
>> +            }
>> 
>> -        if ( (intblk != hvm_intblk_none) || -            
>> (__vmread(VM_ENTRY_INTR_INFO) & INTR_INFO_VALID_MASK) ) -        { -   
>>         enable_intr_window(v, intack); -            goto out; +        
>>    if ( (intblk != hvm_intblk_none) || +                
>> (__vmread(VM_ENTRY_INTR_INFO) & INTR_INFO_VALID_MASK) ) +            {
>> +                enable_intr_window(v, intack); +                goto
>> out; +            }
>>          }
> 
> If you made the above and if()/else if() series, some of the
> differences would go away, making the changes easier to
> review.
> 
>> 
>>          intack = hvm_vcpu_ack_pending_irq(v, intack);
>> @@ -253,6 +277,29 @@ void vmx_intr_assist(void)
>>      {
>>          hvm_inject_hw_exception(TRAP_machine_check,
> HVM_DELIVER_NO_ERROR_CODE);
>>      }
>> +    else if ( cpu_has_vmx_virtual_intr_delivery &&
>> +              intack.source != hvm_intsrc_pic &&
>> +              intack.source != hvm_intsrc_vector )
>> +    {
>> +        /* we need update the RVI field */
>> +        unsigned long status = __vmread(GUEST_INTR_STATUS);
>> +        status &= ~(unsigned long)0x0FF;
>> +        status |= (unsigned long)0x0FF &
>> +                    intack.vector;
>> +        __vmwrite(GUEST_INTR_STATUS, status);
>> +        if (v->arch.hvm_vmx.eoi_exitmap_changed) {
>> +#define UPDATE_EOI_EXITMAP(v, e) {                             \
>> +        if (test_and_clear_bit(e, &(v).eoi_exitmap_changed)) {      \
> 
> Here and elsewhere - do you really need locked accesses?
>
>> +                __vmwrite(EOI_EXIT_BITMAP##e,
>> (v).eoi_exit_bitmap[e]);}} + +               
>> UPDATE_EOI_EXITMAP(v->arch.hvm_vmx, 0);
> 
> This is not very logical: Passing just 'v' to the macro, and accessing
> the full field there would be more consistent.
> 
> Furthermore, here and in other places you fail to write the upper halves
> for 32-bit, yet you also don't disable the code for 32-bit afaics.
> 
>> +                UPDATE_EOI_EXITMAP(v->arch.hvm_vmx, 1);
>> +                UPDATE_EOI_EXITMAP(v->arch.hvm_vmx, 2);
>> +                UPDATE_EOI_EXITMAP(v->arch.hvm_vmx, 3);
>> +        }
>> +
>> +        pt_intr_post(v, intack);
>> +    }
>>      else
>>      {
>>          HVMTRACE_2D(INJ_VIRQ, intack.vector, /*fake=*/ 0);
> 
> Jan
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel


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 Sep 07 01:59:30 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Sep 2012 01: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 1T9nqa-0005Tm-N5; Fri, 07 Sep 2012 01:59:04 +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 1T9nqZ-0005Th-L1
	for xen-devel@lists.xen.org; Fri, 07 Sep 2012 01:59:03 +0000
Received: from [85.158.143.99:5249] by server-1.bemta-4.messagelabs.com id
	C2/2F-12504-6E459405; Fri, 07 Sep 2012 01:59:02 +0000
X-Env-Sender: yongjie.ren@intel.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1346983141!22622818!1
X-Originating-IP: [134.134.136.20]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjAgPT4gMjk0MTM2\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27971 invoked from network); 7 Sep 2012 01:59:02 -0000
Received: from mga02.intel.com (HELO mga02.intel.com) (134.134.136.20)
	by server-10.tower-216.messagelabs.com with SMTP;
	7 Sep 2012 01:59:02 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga101.jf.intel.com with ESMTP; 06 Sep 2012 18:59:01 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.80,382,1344236400"; d="scan'208";a="198348961"
Received: from fmsmsx104.amr.corp.intel.com ([10.19.9.35])
	by orsmga002.jf.intel.com with ESMTP; 06 Sep 2012 18:59:00 -0700
Received: from fmsmsx151.amr.corp.intel.com (10.19.17.220) by
	FMSMSX104.amr.corp.intel.com (10.19.9.35) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Thu, 6 Sep 2012 18:59:00 -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, 6 Sep 2012 18:59:00 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.239]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.175]) with mapi id
	14.01.0355.002; Fri, 7 Sep 2012 09:58:58 +0800
From: "Ren, Yongjie" <yongjie.ren@intel.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Thread-Topic: [Xen-devel] Xen4.2-rc3 test result
Thread-Index: Ac2HShtAedsoaH/XR0eHCAg2EulTuAAEEXiAASd316D//5ydgP/+VVNQ
Date: Fri, 7 Sep 2012 01:58:57 +0000
Message-ID: <1B4B44D9196EFF41AE41FDA404FC0A1019337F@SHSMSX101.ccr.corp.intel.com>
References: <1B4B44D9196EFF41AE41FDA404FC0A1018AF31@SHSMSX101.ccr.corp.intel.com>
	<20120831172410.GA19756@localhost.localdomain>
	<1B4B44D9196EFF41AE41FDA404FC0A10190E9D@SHSMSX101.ccr.corp.intel.com>
	<1346920119.23055.17.camel@zakaz.uk.xensource.com>
In-Reply-To: <1346920119.23055.17.camel@zakaz.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: Konrad Rzeszutek Wilk <konrad@kernel.org>,
	'Konrad Rzeszutek Wilk' <konrad.wilk@oracle.com>,
	"Keir \(Xen.org\)" <keir@xen.org>, 'Jan Beulich' <JBeulich@suse.com>,
	'xen-devel' <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen4.2-rc3 test result
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> -----Original Message-----
> From: Ian Campbell [mailto:Ian.Campbell@citrix.com]
> Sent: Thursday, September 06, 2012 4:29 PM
> To: Ren, Yongjie
> Cc: Konrad Rzeszutek Wilk; 'xen-devel'; Keir (Xen.org); 'Jan Beulich';
> 'Konrad Rzeszutek Wilk'
> Subject: Re: [Xen-devel] Xen4.2-rc3 test result
> 
> On Thu, 2012-09-06 at 09:18 +0100, Ren, Yongjie wrote:
> > > -----Original Message-----
> > > From: Konrad Rzeszutek [mailto:ketuzsezr@gmail.com] On Behalf Of
> > > Konrad Rzeszutek Wilk
> > > Sent: Saturday, September 01, 2012 1:24 AM
> > > To: Ren, Yongjie
> > > Cc: 'xen-devel'; 'Keir Fraser'; 'Ian Campbell'; 'Jan Beulich'; 'Konrad
> > > Rzeszutek Wilk'
> > > Subject: Re: [Xen-devel] Xen4.2-rc3 test result
> >
> > > > 5. Dom0 cannot be shutdown before PCI detachment from guest and
> > > when pci assignment conflicts
> > > >   http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1826
> > >
> > > Um, so you are assigning the same VF to two guests. I am surprised
> that
> > > the tools even allowed you to do that. Was 'xm' allowing you to do
> that?
> > >
> > No, 'xl' doesn't allow me to do that. We can't assignment a device to
> different guests.
> > Sorry, the description of this bug is not accurate. I changed its title to
> "Dom0 cannot be shut down before PCI device detachment from a guest".
> > If a guest (with a PCI device assigned) is running, Dom0 will panic when
> shutting down.
> 
> So this is a dom0 kernel issue and not something relating to 4.2? In
> which case I shall remove it from the 4.2 TODO list.
> 
I don't think so.
In my testing, it should be a regression from Xen 4.1 to 4.2.
Xen4.1(22972) + Dom0(kernel3.5.3) = good
Xen4.2(25791) + Dom0(kernel3.5.3) = bad (it has this issue.)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 07 01:59:30 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Sep 2012 01: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 1T9nqa-0005Tm-N5; Fri, 07 Sep 2012 01:59:04 +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 1T9nqZ-0005Th-L1
	for xen-devel@lists.xen.org; Fri, 07 Sep 2012 01:59:03 +0000
Received: from [85.158.143.99:5249] by server-1.bemta-4.messagelabs.com id
	C2/2F-12504-6E459405; Fri, 07 Sep 2012 01:59:02 +0000
X-Env-Sender: yongjie.ren@intel.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1346983141!22622818!1
X-Originating-IP: [134.134.136.20]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjAgPT4gMjk0MTM2\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27971 invoked from network); 7 Sep 2012 01:59:02 -0000
Received: from mga02.intel.com (HELO mga02.intel.com) (134.134.136.20)
	by server-10.tower-216.messagelabs.com with SMTP;
	7 Sep 2012 01:59:02 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga101.jf.intel.com with ESMTP; 06 Sep 2012 18:59:01 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.80,382,1344236400"; d="scan'208";a="198348961"
Received: from fmsmsx104.amr.corp.intel.com ([10.19.9.35])
	by orsmga002.jf.intel.com with ESMTP; 06 Sep 2012 18:59:00 -0700
Received: from fmsmsx151.amr.corp.intel.com (10.19.17.220) by
	FMSMSX104.amr.corp.intel.com (10.19.9.35) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Thu, 6 Sep 2012 18:59:00 -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, 6 Sep 2012 18:59:00 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.239]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.175]) with mapi id
	14.01.0355.002; Fri, 7 Sep 2012 09:58:58 +0800
From: "Ren, Yongjie" <yongjie.ren@intel.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Thread-Topic: [Xen-devel] Xen4.2-rc3 test result
Thread-Index: Ac2HShtAedsoaH/XR0eHCAg2EulTuAAEEXiAASd316D//5ydgP/+VVNQ
Date: Fri, 7 Sep 2012 01:58:57 +0000
Message-ID: <1B4B44D9196EFF41AE41FDA404FC0A1019337F@SHSMSX101.ccr.corp.intel.com>
References: <1B4B44D9196EFF41AE41FDA404FC0A1018AF31@SHSMSX101.ccr.corp.intel.com>
	<20120831172410.GA19756@localhost.localdomain>
	<1B4B44D9196EFF41AE41FDA404FC0A10190E9D@SHSMSX101.ccr.corp.intel.com>
	<1346920119.23055.17.camel@zakaz.uk.xensource.com>
In-Reply-To: <1346920119.23055.17.camel@zakaz.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: Konrad Rzeszutek Wilk <konrad@kernel.org>,
	'Konrad Rzeszutek Wilk' <konrad.wilk@oracle.com>,
	"Keir \(Xen.org\)" <keir@xen.org>, 'Jan Beulich' <JBeulich@suse.com>,
	'xen-devel' <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen4.2-rc3 test result
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> -----Original Message-----
> From: Ian Campbell [mailto:Ian.Campbell@citrix.com]
> Sent: Thursday, September 06, 2012 4:29 PM
> To: Ren, Yongjie
> Cc: Konrad Rzeszutek Wilk; 'xen-devel'; Keir (Xen.org); 'Jan Beulich';
> 'Konrad Rzeszutek Wilk'
> Subject: Re: [Xen-devel] Xen4.2-rc3 test result
> 
> On Thu, 2012-09-06 at 09:18 +0100, Ren, Yongjie wrote:
> > > -----Original Message-----
> > > From: Konrad Rzeszutek [mailto:ketuzsezr@gmail.com] On Behalf Of
> > > Konrad Rzeszutek Wilk
> > > Sent: Saturday, September 01, 2012 1:24 AM
> > > To: Ren, Yongjie
> > > Cc: 'xen-devel'; 'Keir Fraser'; 'Ian Campbell'; 'Jan Beulich'; 'Konrad
> > > Rzeszutek Wilk'
> > > Subject: Re: [Xen-devel] Xen4.2-rc3 test result
> >
> > > > 5. Dom0 cannot be shutdown before PCI detachment from guest and
> > > when pci assignment conflicts
> > > >   http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1826
> > >
> > > Um, so you are assigning the same VF to two guests. I am surprised
> that
> > > the tools even allowed you to do that. Was 'xm' allowing you to do
> that?
> > >
> > No, 'xl' doesn't allow me to do that. We can't assignment a device to
> different guests.
> > Sorry, the description of this bug is not accurate. I changed its title to
> "Dom0 cannot be shut down before PCI device detachment from a guest".
> > If a guest (with a PCI device assigned) is running, Dom0 will panic when
> shutting down.
> 
> So this is a dom0 kernel issue and not something relating to 4.2? In
> which case I shall remove it from the 4.2 TODO list.
> 
I don't think so.
In my testing, it should be a regression from Xen 4.1 to 4.2.
Xen4.1(22972) + Dom0(kernel3.5.3) = good
Xen4.2(25791) + Dom0(kernel3.5.3) = bad (it has this issue.)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 07 02:08:52 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Sep 2012 02:08:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9nza-00066O-RL; Fri, 07 Sep 2012 02:08:22 +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 1T9nzY-00066J-Qf
	for xen-devel@lists.xen.org; Fri, 07 Sep 2012 02:08:21 +0000
Received: from [85.158.138.51:42583] by server-12.bemta-3.messagelabs.com id
	82/05-10384-41759405; Fri, 07 Sep 2012 02:08:20 +0000
X-Env-Sender: yang.z.zhang@intel.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1346983698!10481503!1
X-Originating-IP: [143.182.124.21]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMjEgPT4gMTk3MzQ0\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18849 invoked from network); 7 Sep 2012 02:08:19 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (143.182.124.21)
	by server-13.tower-174.messagelabs.com with SMTP;
	7 Sep 2012 02:08:19 -0000
Received: from azsmga001.ch.intel.com ([10.2.17.19])
	by azsmga101.ch.intel.com with ESMTP; 06 Sep 2012 19:08:18 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.80,382,1344236400"; d="scan'208";a="189826527"
Received: from fmsmsx107.amr.corp.intel.com ([10.19.9.54])
	by azsmga001.ch.intel.com with ESMTP; 06 Sep 2012 19:08:17 -0700
Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by
	FMSMSX107.amr.corp.intel.com (10.19.9.54) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Thu, 6 Sep 2012 19:08:17 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.239]) by
	SHSMSX102.ccr.corp.intel.com ([169.254.2.92]) with mapi id
	14.01.0355.002; Fri, 7 Sep 2012 10:08:13 +0800
From: "Zhang, Yang Z" <yang.z.zhang@intel.com>
To: Jan Beulich <JBeulich@suse.com>, "Li, Jiongxi" <jiongxi.li@intel.com>
Thread-Topic: [Xen-devel] [ PATCH 2/2] xen: enable Virtual-interrupt delivery
Thread-Index: Ac2HWp7GP5TL6y3yYk23uPXy04inPgABHshJAPpQGPAAJCkEAAAwBV9w
Date: Fri, 7 Sep 2012 02:08:12 +0000
Message-ID: <A9667DDFB95DB7438FA9D7D576C3D87E24D3B1@SHSMSX101.ccr.corp.intel.com>
References: <D9137FCD9CFF644B965863BCFBEDABB8779942@SHSMSX101.ccr.corp.intel.com>
	<CC664937.3D6DA%keir.xen@gmail.com>
	<D9137FCD9CFF644B965863BCFBEDABB877CBB8@SHSMSX101.ccr.corp.intel.com>
	<504899C40200007800099435@nat28.tlf.novell.com>
In-Reply-To: <504899C40200007800099435@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@gmail.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [ PATCH 2/2] xen: enable Virtual-interrupt 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

Jan Beulich wrote on 2012-09-06:
>>>> On 06.09.12 at 12:00, "Li, Jiongxi" <jiongxi.li@intel.com> wrote:
>>> From: Keir Fraser [mailto:keir.xen@gmail.com]
>>> On 31/08/2012 10:30, "Li, Jiongxi" <jiongxi.li@intel.com> wrote:
>>>> --- a/xen/arch/x86/hvm/irq.c  Fri Aug 31 09:30:38 2012 +0800
>>>> +++ b/xen/arch/x86/hvm/irq.c         Fri Aug 31 09:49:39 2012 +0800
>>>> @@ -452,7 +452,11 @@ struct hvm_intack hvm_vcpu_ack_pending_i
>>>> 
>>>>  int hvm_local_events_need_delivery(struct vcpu *v) {
>>>> -    struct hvm_intack intack = hvm_vcpu_has_pending_irq(v);
>>>> +    struct hvm_intack intack;
>>>> +
>>>> +    pt_update_irq(v);
>>> 
>>> Why would this change be needed for vAPIC?
>> When vcpu is scheduled out, there will be periodic timer interrupt pending
> 
> Probably rather "may"?

yes, there may have pending timer interrupt.

>> for injection. Every VMExit is a chance to inject the pending periodic timer
>> interrupt on vmx_intr_assist. In no virtual interrupt delivery case, although
>> injected timer interrupt is edge trigger, EOI always induces VMExit, pending
>> periodic timer can be kept injected till there is no pending left. But in
>> virtual interrupt delivery case, only level trigger interrupt can induce
>> VMExit, there is much less chance for injecting pending timer interrupt
>> through VMExit.
> 
> And it's not possible to set the respective VIRR[] bit, and let the
> hardware take care of injecting at the right time?

Right, we can use this way to inject the interrupt. 
But it still need a watchdog to aware when the bit in VIRR is cleared by guest, and the cost is same with forcing VM exit when writing EOI for timer interrupt.

>> Adding pt_update_irq here is another code path to inject pending periodic
>> timer, but it can't guarantee every pending timer interrupt can be injected.
>> Another way is to make every EOI of pending timer interrupt induce VMExit,
>> but it may obey the spirit of virtual interrupt delivery - reducing VMExit.
>> We have been evaluating that.
> 
> With which result?

We are doing it now. Will let you know the result when get it.

> Jan
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel


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 Sep 07 02:08:52 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Sep 2012 02:08:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9nza-00066O-RL; Fri, 07 Sep 2012 02:08:22 +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 1T9nzY-00066J-Qf
	for xen-devel@lists.xen.org; Fri, 07 Sep 2012 02:08:21 +0000
Received: from [85.158.138.51:42583] by server-12.bemta-3.messagelabs.com id
	82/05-10384-41759405; Fri, 07 Sep 2012 02:08:20 +0000
X-Env-Sender: yang.z.zhang@intel.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1346983698!10481503!1
X-Originating-IP: [143.182.124.21]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMjEgPT4gMTk3MzQ0\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18849 invoked from network); 7 Sep 2012 02:08:19 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (143.182.124.21)
	by server-13.tower-174.messagelabs.com with SMTP;
	7 Sep 2012 02:08:19 -0000
Received: from azsmga001.ch.intel.com ([10.2.17.19])
	by azsmga101.ch.intel.com with ESMTP; 06 Sep 2012 19:08:18 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.80,382,1344236400"; d="scan'208";a="189826527"
Received: from fmsmsx107.amr.corp.intel.com ([10.19.9.54])
	by azsmga001.ch.intel.com with ESMTP; 06 Sep 2012 19:08:17 -0700
Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by
	FMSMSX107.amr.corp.intel.com (10.19.9.54) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Thu, 6 Sep 2012 19:08:17 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.239]) by
	SHSMSX102.ccr.corp.intel.com ([169.254.2.92]) with mapi id
	14.01.0355.002; Fri, 7 Sep 2012 10:08:13 +0800
From: "Zhang, Yang Z" <yang.z.zhang@intel.com>
To: Jan Beulich <JBeulich@suse.com>, "Li, Jiongxi" <jiongxi.li@intel.com>
Thread-Topic: [Xen-devel] [ PATCH 2/2] xen: enable Virtual-interrupt delivery
Thread-Index: Ac2HWp7GP5TL6y3yYk23uPXy04inPgABHshJAPpQGPAAJCkEAAAwBV9w
Date: Fri, 7 Sep 2012 02:08:12 +0000
Message-ID: <A9667DDFB95DB7438FA9D7D576C3D87E24D3B1@SHSMSX101.ccr.corp.intel.com>
References: <D9137FCD9CFF644B965863BCFBEDABB8779942@SHSMSX101.ccr.corp.intel.com>
	<CC664937.3D6DA%keir.xen@gmail.com>
	<D9137FCD9CFF644B965863BCFBEDABB877CBB8@SHSMSX101.ccr.corp.intel.com>
	<504899C40200007800099435@nat28.tlf.novell.com>
In-Reply-To: <504899C40200007800099435@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@gmail.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [ PATCH 2/2] xen: enable Virtual-interrupt 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

Jan Beulich wrote on 2012-09-06:
>>>> On 06.09.12 at 12:00, "Li, Jiongxi" <jiongxi.li@intel.com> wrote:
>>> From: Keir Fraser [mailto:keir.xen@gmail.com]
>>> On 31/08/2012 10:30, "Li, Jiongxi" <jiongxi.li@intel.com> wrote:
>>>> --- a/xen/arch/x86/hvm/irq.c  Fri Aug 31 09:30:38 2012 +0800
>>>> +++ b/xen/arch/x86/hvm/irq.c         Fri Aug 31 09:49:39 2012 +0800
>>>> @@ -452,7 +452,11 @@ struct hvm_intack hvm_vcpu_ack_pending_i
>>>> 
>>>>  int hvm_local_events_need_delivery(struct vcpu *v) {
>>>> -    struct hvm_intack intack = hvm_vcpu_has_pending_irq(v);
>>>> +    struct hvm_intack intack;
>>>> +
>>>> +    pt_update_irq(v);
>>> 
>>> Why would this change be needed for vAPIC?
>> When vcpu is scheduled out, there will be periodic timer interrupt pending
> 
> Probably rather "may"?

yes, there may have pending timer interrupt.

>> for injection. Every VMExit is a chance to inject the pending periodic timer
>> interrupt on vmx_intr_assist. In no virtual interrupt delivery case, although
>> injected timer interrupt is edge trigger, EOI always induces VMExit, pending
>> periodic timer can be kept injected till there is no pending left. But in
>> virtual interrupt delivery case, only level trigger interrupt can induce
>> VMExit, there is much less chance for injecting pending timer interrupt
>> through VMExit.
> 
> And it's not possible to set the respective VIRR[] bit, and let the
> hardware take care of injecting at the right time?

Right, we can use this way to inject the interrupt. 
But it still need a watchdog to aware when the bit in VIRR is cleared by guest, and the cost is same with forcing VM exit when writing EOI for timer interrupt.

>> Adding pt_update_irq here is another code path to inject pending periodic
>> timer, but it can't guarantee every pending timer interrupt can be injected.
>> Another way is to make every EOI of pending timer interrupt induce VMExit,
>> but it may obey the spirit of virtual interrupt delivery - reducing VMExit.
>> We have been evaluating that.
> 
> With which result?

We are doing it now. Will let you know the result when get it.

> Jan
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel


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 Sep 07 02:09:29 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Sep 2012 02:09:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9o0C-00068O-Bs; Fri, 07 Sep 2012 02:09:00 +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 1T9o0A-00068B-7m
	for xen-devel@lists.xen.org; Fri, 07 Sep 2012 02:08:58 +0000
Received: from [85.158.139.83:26783] by server-8.bemta-5.messagelabs.com id
	3E/71-17085-93759405; Fri, 07 Sep 2012 02:08:57 +0000
X-Env-Sender: yongjie.ren@intel.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1346983733!24799355!1
X-Originating-IP: [143.182.124.37]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMzcgPT4gMTk3MzY4\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5788 invoked from network); 7 Sep 2012 02:08:54 -0000
Received: from mga14.intel.com (HELO mga14.intel.com) (143.182.124.37)
	by server-14.tower-182.messagelabs.com with SMTP;
	7 Sep 2012 02:08:54 -0000
Received: from azsmga001.ch.intel.com ([10.2.17.19])
	by azsmga102.ch.intel.com with ESMTP; 06 Sep 2012 19:08:52 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.80,382,1344236400"; d="scan'208";a="189826657"
Received: from fmsmsx107.amr.corp.intel.com ([10.19.9.54])
	by azsmga001.ch.intel.com with ESMTP; 06 Sep 2012 19:08:52 -0700
Received: from fmsmsx152.amr.corp.intel.com (10.19.17.221) by
	FMSMSX107.amr.corp.intel.com (10.19.9.54) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Thu, 6 Sep 2012 19:08:51 -0700
Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by
	fmsmsx152.amr.corp.intel.com (10.19.17.221) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Thu, 6 Sep 2012 19:08:51 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.239]) by
	SHSMSX102.ccr.corp.intel.com ([169.254.2.92]) with mapi id
	14.01.0355.002; Fri, 7 Sep 2012 10:08:49 +0800
From: "Ren, Yongjie" <yongjie.ren@intel.com>
To: Tobias Geiger <tobias.geiger@vido.info>, Konrad Rzeszutek Wilk
	<konrad.wilk@oracle.com>
Thread-Topic: [Xen-devel] Regression in kernel 3.5 as Dom0 regarding PCI
	Passthrough?!
Thread-Index: AQHNjCKrsV2vGXTxOkeSPEptArnLFJd+IpuA
Date: Fri, 7 Sep 2012 02:08:49 +0000
Message-ID: <1B4B44D9196EFF41AE41FDA404FC0A101933A2@SHSMSX101.ccr.corp.intel.com>
References: <1B4B44D9196EFF41AE41FDA404FC0A101881CE@SHSMSX101.ccr.corp.intel.com>
	<20120905185412.GA27077@phenom.dumpdata.com>
	<f74e17a2c22339a3eb0439a03bef10b1@vido.info>
In-Reply-To: <f74e17a2c22339a3eb0439a03bef10b1@vido.info>
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: Konrad Rzeszutek Wilk <konrad@kernel.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Regression in kernel 3.5 as Dom0 regarding 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

> -----Original Message-----
> From: Tobias Geiger [mailto:tobias.geiger@vido.info]
> Sent: Thursday, September 06, 2012 7:28 PM
> To: Konrad Rzeszutek Wilk
> Cc: Ren, Yongjie; Konrad Rzeszutek Wilk; xen-devel@lists.xen.org
> Subject: Re: [Xen-devel] Regression in kernel 3.5 as Dom0 regarding PCI
> Passthrough?!
> 
> Hello Konrad,
> 
> the patch helps regarding the USB-PCIController-Passthrough - this
> works now in DomU.
> 
Hi Tobias,
In my testing, this patch can't work for a NIC pass-through.
Could you have a try with a NIC pass-through?

> but i still get the Dom0 crash when shutting down DomU:
> 
> Sep  6 13:26:19 pc kernel: [  361.011514]
> xen-blkback:backend/vbd/1/832: prepare for reconnect
> Sep  6 13:26:20 pc kernel: [  361.876395]
> xen-blkback:backend/vbd/1/768: prepare for reconnect
> Sep  6 13:26:21 pc kernel: [  362.682152] br0: port 3(vif1.0) entered
> disabled state
> Sep  6 13:26:21 pc kernel: [  362.682267] br0: port 3(vif1.0) entered
> disabled state
> Sep  6 13:26:24 pc kernel: [  365.541386] ------------[ cut here
> ]------------
> Sep  6 13:26:24 pc kernel: [  365.541411] invalid opcode: 0000 [#1]
> PREEMPT SMP
> Sep  6 13:26:24 pc kernel: [  365.541423] CPU 2
> Sep  6 13:26:24 pc kernel: [  365.541427] Modules linked in: uvcvideo
> snd_usb_audio snd_usbmidi_lib snd_seq_midi snd_hwd
> ep snd_rawmidi videobuf2_vmalloc videobuf2_memops videobuf2_core
> videodev gpio_ich joydev hid_generic [last unloaded: sc
> si_wait_scan]
> Sep  6 13:26:24 pc kernel: [  365.541474]
> Sep  6 13:26:24 pc kernel: [  365.541477] Pid: 1208, comm: kworker/2:1
> Not tainted 3.5.0 #3                  /DX58SO
> Sep  6 13:26:24 pc kernel: [  365.541491] RIP:
> e030:[<ffffffff81447f95>]  [<ffffffff81447f95>]
> balloon_process+0x385/0x3
> a0
> Sep  6 13:26:24 pc kernel: [  365.541507] RSP: e02b:ffff88012e7abdc0
> EFLAGS: 00010213
> Sep  6 13:26:24 pc kernel: [  365.541515] RAX: 0000000220be7000 RBX:
> 0000000000000000 RCX: 0000000000000008
> Sep  6 13:26:24 pc kernel: [  365.541523] RDX: ffff88010d99a000 RSI:
> 00000000000001df RDI: 000000000020efdf
> Sep  6 13:26:24 pc kernel: [  365.541532] RBP: ffff88012e7abe20 R08:
> ffff88014064e140 R09: 00000000fffffffe
> Sep  6 13:26:24 pc kernel: [  365.541540] R10: 0000000000000001 R11:
> 0000000000000000 R12: 0000160000000000
> Sep  6 13:26:24 pc kernel: [  365.541548] R13: 0000000000000001 R14:
> 000000000020efdf R15: ffffea00083bf7c0
> Sep  6 13:26:24 pc kernel: [  365.541561] FS:  00007f79d32ce700(0000)
> GS:ffff880140640000(0000) knlGS:0000000000000000
> Sep  6 13:26:24 pc kernel: [  365.541571] CS:  e033 DS: 0000 ES: 0000
> CR0: 000000008005003b
> Sep  6 13:26:24 pc kernel: [  365.541578] CR2: 00007f79d2d6ce02 CR3:
> 0000000001e0c000 CR4: 0000000000002660
> Sep  6 13:26:24 pc kernel: [  365.541587] DR0: 0000000000000000 DR1:
> 0000000000000000 DR2: 0000000000000000
> Sep  6 13:26:24 pc kernel: [  365.541596] DR3: 0000000000000000 DR6:
> 00000000ffff0ff0 DR7: 0000000000000400
> Sep  6 13:26:24 pc kernel: [  365.541604] Process kworker/2:1 (pid:
> 1208, threadinfo ffff88012e7aa000, task ffff88013101
> c440)
> Sep  6 13:26:24 pc kernel: [  365.541613] Stack:
> Sep  6 13:26:24 pc kernel: [  365.541618]  000000000006877b
> 0000000000000001 ffffffff8200ea80 0000000000000001
> Sep  6 13:26:24 pc kernel: [  365.541649]  0000000000000000
> 0000000000007ff0 ffff88012e7abe00 ffff8801302eee00
> Sep  6 13:26:24 pc kernel: [  365.541664]  ffff880140657000
> ffff88014064e140 0000000000000000 ffffffff81e587c0
> Sep  6 13:26:24 pc kernel: [  365.541679] Call Trace:
> Sep  6 13:26:24 pc kernel: [  365.541688]  [<ffffffff8106753b>]
> process_one_work+0x12b/0x450
> Sep  6 13:26:24 pc kernel: [  365.541697]  [<ffffffff81447c10>] ?
> decrease_reservation+0x320/0x320
> Sep  6 13:26:24 pc kernel: [  365.541706]  [<ffffffff810688be>]
> worker_thread+0x12e/0x2d0
> Sep  6 13:26:24 pc kernel: [  365.541715]  [<ffffffff81068790>] ?
> manage_workers.isra.26+0x1f0/0x1f0
> Sep  6 13:26:24 pc kernel: [  365.541725]  [<ffffffff8106db7e>]
> kthread+0x8e/0xa0
> Sep  6 13:26:24 pc kernel: [  365.541735]  [<ffffffff8184e3e4>]
> kernel_thread_helper+0x4/0x10
> Sep  6 13:26:24 pc kernel: [  365.541745]  [<ffffffff8184c87c>] ?
> retint_restore_args+0x5/0x6
> Sep  6 13:26:24 pc kernel: [  365.541754]  [<ffffffff8184e3e0>] ?
> gs_change+0x13/0x13
> Sep  6 13:26:24 pc kernel: [  365.541760] Code: 01 15 f0 6a bc 00 48 29
> d0 48 89 05 ee 6a bc 00 e9 31 fd ff ff 0f 0b 0f
> 0b 4c 89 f7 e8 85 34 bc ff 48 83 f8 ff 0f 84 2b fe ff ff <0f> 0b 66 0f
> 1f 84 00 00 00 00 00 48 83 c1 01 e9 c2 fd ff ff 0
> f
> Sep  6 13:26:24 pc kernel: [  365.541898]  RSP <ffff88012e7abdc0>
> Sep  6 13:26:24 pc kernel: [  365.565054] ---[ end trace
> 25eb9ce0cc61c3a1 ]---
> Sep  6 13:26:24 pc kernel: [  365.565101] PGD 1e0e067 PUD 1e0f067
> PMD 0
> Sep  6 13:26:24 pc kernel: [  365.565108] Oops: 0000 [#2] PREEMPT SMP
> Sep  6 13:26:24 pc kernel: [  365.565115] CPU 2
> Sep  6 13:26:24 pc kernel: [  365.565118] Modules linked in: uvcvideo
> snd_usb_audio snd_usbmidi_lib snd_seq_midi snd_hwd
> ep snd_rawmidi videobuf2_vmalloc videobuf2_memops videobuf2_core
> videodev gpio_ich joydev hid_generic [last unloaded: sc
> si_wait_scan]
> Sep  6 13:26:24 pc kernel: [  365.565153]
> Sep  6 13:26:24 pc kernel: [  365.565156] Pid: 1208, comm: kworker/2:1
> Tainted: G      D      3.5.0 #3
> /DX58SO
> Sep  6 13:26:24 pc kernel: [  365.565176] RIP:
> e030:[<ffffffff8106e08c>]  [<ffffffff8106e08c>] kthread_data+0xc/0x20
> Sep  6 13:26:24 pc kernel: [  365.565194] RSP: e02b:ffff88012e7aba90
> EFLAGS: 00010092
> Sep  6 13:26:24 pc kernel: [  365.565205] RAX: 0000000000000000 RBX:
> 0000000000000002 RCX: 0000000000000002
> Sep  6 13:26:24 pc kernel: [  365.565219] RDX: ffffffff81fcba40 RSI:
> 0000000000000002 RDI: ffff88013101c440
> Sep  6 13:26:24 pc kernel: [  365.565233] RBP: ffff88012e7abaa8 R08:
> 0000000000989680 R09: ffffffff81fcba40
> Sep  6 13:26:24 pc kernel: [  365.565248] R10: ffffffff813b0c00 R11:
> 0000000000000000 R12: ffff8801406536c0
> Sep  6 13:26:24 pc kernel: [  365.565262] R13: 0000000000000002 R14:
> ffff88013101c430 R15: ffff88013101c440
> Sep  6 13:26:24 pc kernel: [  365.565280] FS:  00007f79d32ce700(0000)
> GS:ffff880140640000(0000) knlGS:0000000000000000
> Sep  6 13:26:24 pc kernel: [  365.565293] CS:  e033 DS: 0000 ES: 0000
> CR0: 000000008005003b
> Sep  6 13:26:24 pc kernel: [  365.565303] CR2: fffffffffffffff8 CR3:
> 0000000001e0c000 CR4: 0000000000002660
> Sep  6 13:26:24 pc kernel: [  365.565318] DR0: 0000000000000000 DR1:
> 0000000000000000 DR2: 0000000000000000
> Sep  6 13:26:24 pc kernel: [  365.565332] DR3: 0000000000000000 DR6:
> 00000000ffff0ff0 DR7: 0000000000000400
> Sep  6 13:26:24 pc kernel: [  365.565349] Process kworker/2:1 (pid:
> 1208, threadinfo ffff88012e7aa000, task ffff88013101
> c440)
> Sep  6 13:26:24 pc kernel: [  365.565362] Stack:
> Sep  6 13:26:24 pc kernel: [  365.565367]  ffffffff810698e0
> ffff88012e7abaa8 ffff88013101c818 ffff88012e7abb18
> Sep  6 13:26:24 pc kernel: [  365.565389]  ffffffff8184ae02
> ffff88012e7abfd8 ffff88013101c440 ffff88012e7abfd8
> Sep  6 13:26:24 pc kernel: [  365.565410]  ffff88012e7abfd8
> ffff88012d8840c0 ffff88013101c440 ffff88013101ca30
> 
> 
> 
> Perhaps this stacktrace helps...
> 
> Thanks!
> 
> Am 05.09.2012 20:54, schrieb Konrad Rzeszutek Wilk:
> >> > > > And its due to a patch I added in v3.4
> >> > > > (cd9db80e5257682a7f7ab245a2459648b3c8d268)
> >> > > > - which did not work properly in v3.4, but with v3.5 got it
> >> working
> >> > > > (977f857ca566a1e68045fcbb7cfc9c4acb077cf0) which causes v3.5
> >> to
> >> > now
> >> > > > work
> >> > > > anymore.
> >> > > >
> >> > > > Anyhow, for right now jsut revert
> >> > > > cd9db80e5257682a7f7ab245a2459648b3c8d268
> >> > > > and it should work for you.
> >> > > >
> >> Confirmed, after reverting that commit, VT-d will work fine.
> >> Will you fix this and push it to upstream Linux, Konrad?
> >>
> >> > > Also, our team reported a VT-d bug 2 months ago.
> >> > > http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1824
> >> >
> >
> > Can either one of you please test this patch, please:
> >
> >
> > diff --git a/drivers/xen/xen-pciback/pci_stub.c
> > b/drivers/xen/xen-pciback/pci_stub.c
> > index 097e536..425bd0b 100644
> > --- a/drivers/xen/xen-pciback/pci_stub.c
> > +++ b/drivers/xen/xen-pciback/pci_stub.c
> > @@ -4,6 +4,8 @@
> >   * Ryan Wilson <hap9@epoch.ncsc.mil>
> >   * Chris Bookholt <hap10@epoch.ncsc.mil>
> >   */
> > +#define DEBUG 1
> > +
> >  #include <linux/module.h>
> >  #include <linux/init.h>
> >  #include <linux/rwsem.h>
> > @@ -97,13 +99,15 @@ static void pcistub_device_release(struct kref
> > *kref)
> >  	/* Call the reset function which does not take lock as this
> >  	 * is called from "unbind" which takes a device_lock mutex.
> >  	 */
> > +	dev_dbg(&psdev->dev->dev, "FLR locked..\n");
> >  	__pci_reset_function_locked(psdev->dev);
> >  	if (pci_load_and_free_saved_state(psdev->dev,
> >  					  &dev_data->pci_saved_state)) {
> >  		dev_dbg(&psdev->dev->dev, "Could not reload PCI state\n");
> > -	} else
> > +	} else {
> > +		dev_dbg(&psdev->dev->dev, "Reloading PCI state..\n");
> >  		pci_restore_state(psdev->dev);
> > -
> > +	}
> >  	/* Disable the device */
> >  	xen_pcibk_reset_device(psdev->dev);
> >
> > @@ -353,16 +357,16 @@ static int __devinit pcistub_init_device(struct
> > pci_dev *dev)
> >  	if (err)
> >  		goto config_release;
> >
> > -	dev_dbg(&dev->dev, "reseting (FLR, D3, etc) the device\n");
> > -	__pci_reset_function_locked(dev);
> > -
> >  	/* We need the device active to save the state. */
> >  	dev_dbg(&dev->dev, "save state of device\n");
> >  	pci_save_state(dev);
> >  	dev_data->pci_saved_state = pci_store_saved_state(dev);
> >  	if (!dev_data->pci_saved_state)
> >  		dev_err(&dev->dev, "Could not store PCI conf saved state!\n");
> > -
> > +	else {
> > +		dev_dbg(&dev->dev, "reseting (FLR, D3, etc) the device\n");
> > +		__pci_reset_function_locked(dev);
> > +	}
> >  	/* Now disable the device (this also ensures some private device
> >  	 * data is setup before we export)
> >  	 */

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 07 02:09:29 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Sep 2012 02:09:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9o0C-00068O-Bs; Fri, 07 Sep 2012 02:09:00 +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 1T9o0A-00068B-7m
	for xen-devel@lists.xen.org; Fri, 07 Sep 2012 02:08:58 +0000
Received: from [85.158.139.83:26783] by server-8.bemta-5.messagelabs.com id
	3E/71-17085-93759405; Fri, 07 Sep 2012 02:08:57 +0000
X-Env-Sender: yongjie.ren@intel.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1346983733!24799355!1
X-Originating-IP: [143.182.124.37]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMzcgPT4gMTk3MzY4\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5788 invoked from network); 7 Sep 2012 02:08:54 -0000
Received: from mga14.intel.com (HELO mga14.intel.com) (143.182.124.37)
	by server-14.tower-182.messagelabs.com with SMTP;
	7 Sep 2012 02:08:54 -0000
Received: from azsmga001.ch.intel.com ([10.2.17.19])
	by azsmga102.ch.intel.com with ESMTP; 06 Sep 2012 19:08:52 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.80,382,1344236400"; d="scan'208";a="189826657"
Received: from fmsmsx107.amr.corp.intel.com ([10.19.9.54])
	by azsmga001.ch.intel.com with ESMTP; 06 Sep 2012 19:08:52 -0700
Received: from fmsmsx152.amr.corp.intel.com (10.19.17.221) by
	FMSMSX107.amr.corp.intel.com (10.19.9.54) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Thu, 6 Sep 2012 19:08:51 -0700
Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by
	fmsmsx152.amr.corp.intel.com (10.19.17.221) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Thu, 6 Sep 2012 19:08:51 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.239]) by
	SHSMSX102.ccr.corp.intel.com ([169.254.2.92]) with mapi id
	14.01.0355.002; Fri, 7 Sep 2012 10:08:49 +0800
From: "Ren, Yongjie" <yongjie.ren@intel.com>
To: Tobias Geiger <tobias.geiger@vido.info>, Konrad Rzeszutek Wilk
	<konrad.wilk@oracle.com>
Thread-Topic: [Xen-devel] Regression in kernel 3.5 as Dom0 regarding PCI
	Passthrough?!
Thread-Index: AQHNjCKrsV2vGXTxOkeSPEptArnLFJd+IpuA
Date: Fri, 7 Sep 2012 02:08:49 +0000
Message-ID: <1B4B44D9196EFF41AE41FDA404FC0A101933A2@SHSMSX101.ccr.corp.intel.com>
References: <1B4B44D9196EFF41AE41FDA404FC0A101881CE@SHSMSX101.ccr.corp.intel.com>
	<20120905185412.GA27077@phenom.dumpdata.com>
	<f74e17a2c22339a3eb0439a03bef10b1@vido.info>
In-Reply-To: <f74e17a2c22339a3eb0439a03bef10b1@vido.info>
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: Konrad Rzeszutek Wilk <konrad@kernel.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Regression in kernel 3.5 as Dom0 regarding 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

> -----Original Message-----
> From: Tobias Geiger [mailto:tobias.geiger@vido.info]
> Sent: Thursday, September 06, 2012 7:28 PM
> To: Konrad Rzeszutek Wilk
> Cc: Ren, Yongjie; Konrad Rzeszutek Wilk; xen-devel@lists.xen.org
> Subject: Re: [Xen-devel] Regression in kernel 3.5 as Dom0 regarding PCI
> Passthrough?!
> 
> Hello Konrad,
> 
> the patch helps regarding the USB-PCIController-Passthrough - this
> works now in DomU.
> 
Hi Tobias,
In my testing, this patch can't work for a NIC pass-through.
Could you have a try with a NIC pass-through?

> but i still get the Dom0 crash when shutting down DomU:
> 
> Sep  6 13:26:19 pc kernel: [  361.011514]
> xen-blkback:backend/vbd/1/832: prepare for reconnect
> Sep  6 13:26:20 pc kernel: [  361.876395]
> xen-blkback:backend/vbd/1/768: prepare for reconnect
> Sep  6 13:26:21 pc kernel: [  362.682152] br0: port 3(vif1.0) entered
> disabled state
> Sep  6 13:26:21 pc kernel: [  362.682267] br0: port 3(vif1.0) entered
> disabled state
> Sep  6 13:26:24 pc kernel: [  365.541386] ------------[ cut here
> ]------------
> Sep  6 13:26:24 pc kernel: [  365.541411] invalid opcode: 0000 [#1]
> PREEMPT SMP
> Sep  6 13:26:24 pc kernel: [  365.541423] CPU 2
> Sep  6 13:26:24 pc kernel: [  365.541427] Modules linked in: uvcvideo
> snd_usb_audio snd_usbmidi_lib snd_seq_midi snd_hwd
> ep snd_rawmidi videobuf2_vmalloc videobuf2_memops videobuf2_core
> videodev gpio_ich joydev hid_generic [last unloaded: sc
> si_wait_scan]
> Sep  6 13:26:24 pc kernel: [  365.541474]
> Sep  6 13:26:24 pc kernel: [  365.541477] Pid: 1208, comm: kworker/2:1
> Not tainted 3.5.0 #3                  /DX58SO
> Sep  6 13:26:24 pc kernel: [  365.541491] RIP:
> e030:[<ffffffff81447f95>]  [<ffffffff81447f95>]
> balloon_process+0x385/0x3
> a0
> Sep  6 13:26:24 pc kernel: [  365.541507] RSP: e02b:ffff88012e7abdc0
> EFLAGS: 00010213
> Sep  6 13:26:24 pc kernel: [  365.541515] RAX: 0000000220be7000 RBX:
> 0000000000000000 RCX: 0000000000000008
> Sep  6 13:26:24 pc kernel: [  365.541523] RDX: ffff88010d99a000 RSI:
> 00000000000001df RDI: 000000000020efdf
> Sep  6 13:26:24 pc kernel: [  365.541532] RBP: ffff88012e7abe20 R08:
> ffff88014064e140 R09: 00000000fffffffe
> Sep  6 13:26:24 pc kernel: [  365.541540] R10: 0000000000000001 R11:
> 0000000000000000 R12: 0000160000000000
> Sep  6 13:26:24 pc kernel: [  365.541548] R13: 0000000000000001 R14:
> 000000000020efdf R15: ffffea00083bf7c0
> Sep  6 13:26:24 pc kernel: [  365.541561] FS:  00007f79d32ce700(0000)
> GS:ffff880140640000(0000) knlGS:0000000000000000
> Sep  6 13:26:24 pc kernel: [  365.541571] CS:  e033 DS: 0000 ES: 0000
> CR0: 000000008005003b
> Sep  6 13:26:24 pc kernel: [  365.541578] CR2: 00007f79d2d6ce02 CR3:
> 0000000001e0c000 CR4: 0000000000002660
> Sep  6 13:26:24 pc kernel: [  365.541587] DR0: 0000000000000000 DR1:
> 0000000000000000 DR2: 0000000000000000
> Sep  6 13:26:24 pc kernel: [  365.541596] DR3: 0000000000000000 DR6:
> 00000000ffff0ff0 DR7: 0000000000000400
> Sep  6 13:26:24 pc kernel: [  365.541604] Process kworker/2:1 (pid:
> 1208, threadinfo ffff88012e7aa000, task ffff88013101
> c440)
> Sep  6 13:26:24 pc kernel: [  365.541613] Stack:
> Sep  6 13:26:24 pc kernel: [  365.541618]  000000000006877b
> 0000000000000001 ffffffff8200ea80 0000000000000001
> Sep  6 13:26:24 pc kernel: [  365.541649]  0000000000000000
> 0000000000007ff0 ffff88012e7abe00 ffff8801302eee00
> Sep  6 13:26:24 pc kernel: [  365.541664]  ffff880140657000
> ffff88014064e140 0000000000000000 ffffffff81e587c0
> Sep  6 13:26:24 pc kernel: [  365.541679] Call Trace:
> Sep  6 13:26:24 pc kernel: [  365.541688]  [<ffffffff8106753b>]
> process_one_work+0x12b/0x450
> Sep  6 13:26:24 pc kernel: [  365.541697]  [<ffffffff81447c10>] ?
> decrease_reservation+0x320/0x320
> Sep  6 13:26:24 pc kernel: [  365.541706]  [<ffffffff810688be>]
> worker_thread+0x12e/0x2d0
> Sep  6 13:26:24 pc kernel: [  365.541715]  [<ffffffff81068790>] ?
> manage_workers.isra.26+0x1f0/0x1f0
> Sep  6 13:26:24 pc kernel: [  365.541725]  [<ffffffff8106db7e>]
> kthread+0x8e/0xa0
> Sep  6 13:26:24 pc kernel: [  365.541735]  [<ffffffff8184e3e4>]
> kernel_thread_helper+0x4/0x10
> Sep  6 13:26:24 pc kernel: [  365.541745]  [<ffffffff8184c87c>] ?
> retint_restore_args+0x5/0x6
> Sep  6 13:26:24 pc kernel: [  365.541754]  [<ffffffff8184e3e0>] ?
> gs_change+0x13/0x13
> Sep  6 13:26:24 pc kernel: [  365.541760] Code: 01 15 f0 6a bc 00 48 29
> d0 48 89 05 ee 6a bc 00 e9 31 fd ff ff 0f 0b 0f
> 0b 4c 89 f7 e8 85 34 bc ff 48 83 f8 ff 0f 84 2b fe ff ff <0f> 0b 66 0f
> 1f 84 00 00 00 00 00 48 83 c1 01 e9 c2 fd ff ff 0
> f
> Sep  6 13:26:24 pc kernel: [  365.541898]  RSP <ffff88012e7abdc0>
> Sep  6 13:26:24 pc kernel: [  365.565054] ---[ end trace
> 25eb9ce0cc61c3a1 ]---
> Sep  6 13:26:24 pc kernel: [  365.565101] PGD 1e0e067 PUD 1e0f067
> PMD 0
> Sep  6 13:26:24 pc kernel: [  365.565108] Oops: 0000 [#2] PREEMPT SMP
> Sep  6 13:26:24 pc kernel: [  365.565115] CPU 2
> Sep  6 13:26:24 pc kernel: [  365.565118] Modules linked in: uvcvideo
> snd_usb_audio snd_usbmidi_lib snd_seq_midi snd_hwd
> ep snd_rawmidi videobuf2_vmalloc videobuf2_memops videobuf2_core
> videodev gpio_ich joydev hid_generic [last unloaded: sc
> si_wait_scan]
> Sep  6 13:26:24 pc kernel: [  365.565153]
> Sep  6 13:26:24 pc kernel: [  365.565156] Pid: 1208, comm: kworker/2:1
> Tainted: G      D      3.5.0 #3
> /DX58SO
> Sep  6 13:26:24 pc kernel: [  365.565176] RIP:
> e030:[<ffffffff8106e08c>]  [<ffffffff8106e08c>] kthread_data+0xc/0x20
> Sep  6 13:26:24 pc kernel: [  365.565194] RSP: e02b:ffff88012e7aba90
> EFLAGS: 00010092
> Sep  6 13:26:24 pc kernel: [  365.565205] RAX: 0000000000000000 RBX:
> 0000000000000002 RCX: 0000000000000002
> Sep  6 13:26:24 pc kernel: [  365.565219] RDX: ffffffff81fcba40 RSI:
> 0000000000000002 RDI: ffff88013101c440
> Sep  6 13:26:24 pc kernel: [  365.565233] RBP: ffff88012e7abaa8 R08:
> 0000000000989680 R09: ffffffff81fcba40
> Sep  6 13:26:24 pc kernel: [  365.565248] R10: ffffffff813b0c00 R11:
> 0000000000000000 R12: ffff8801406536c0
> Sep  6 13:26:24 pc kernel: [  365.565262] R13: 0000000000000002 R14:
> ffff88013101c430 R15: ffff88013101c440
> Sep  6 13:26:24 pc kernel: [  365.565280] FS:  00007f79d32ce700(0000)
> GS:ffff880140640000(0000) knlGS:0000000000000000
> Sep  6 13:26:24 pc kernel: [  365.565293] CS:  e033 DS: 0000 ES: 0000
> CR0: 000000008005003b
> Sep  6 13:26:24 pc kernel: [  365.565303] CR2: fffffffffffffff8 CR3:
> 0000000001e0c000 CR4: 0000000000002660
> Sep  6 13:26:24 pc kernel: [  365.565318] DR0: 0000000000000000 DR1:
> 0000000000000000 DR2: 0000000000000000
> Sep  6 13:26:24 pc kernel: [  365.565332] DR3: 0000000000000000 DR6:
> 00000000ffff0ff0 DR7: 0000000000000400
> Sep  6 13:26:24 pc kernel: [  365.565349] Process kworker/2:1 (pid:
> 1208, threadinfo ffff88012e7aa000, task ffff88013101
> c440)
> Sep  6 13:26:24 pc kernel: [  365.565362] Stack:
> Sep  6 13:26:24 pc kernel: [  365.565367]  ffffffff810698e0
> ffff88012e7abaa8 ffff88013101c818 ffff88012e7abb18
> Sep  6 13:26:24 pc kernel: [  365.565389]  ffffffff8184ae02
> ffff88012e7abfd8 ffff88013101c440 ffff88012e7abfd8
> Sep  6 13:26:24 pc kernel: [  365.565410]  ffff88012e7abfd8
> ffff88012d8840c0 ffff88013101c440 ffff88013101ca30
> 
> 
> 
> Perhaps this stacktrace helps...
> 
> Thanks!
> 
> Am 05.09.2012 20:54, schrieb Konrad Rzeszutek Wilk:
> >> > > > And its due to a patch I added in v3.4
> >> > > > (cd9db80e5257682a7f7ab245a2459648b3c8d268)
> >> > > > - which did not work properly in v3.4, but with v3.5 got it
> >> working
> >> > > > (977f857ca566a1e68045fcbb7cfc9c4acb077cf0) which causes v3.5
> >> to
> >> > now
> >> > > > work
> >> > > > anymore.
> >> > > >
> >> > > > Anyhow, for right now jsut revert
> >> > > > cd9db80e5257682a7f7ab245a2459648b3c8d268
> >> > > > and it should work for you.
> >> > > >
> >> Confirmed, after reverting that commit, VT-d will work fine.
> >> Will you fix this and push it to upstream Linux, Konrad?
> >>
> >> > > Also, our team reported a VT-d bug 2 months ago.
> >> > > http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1824
> >> >
> >
> > Can either one of you please test this patch, please:
> >
> >
> > diff --git a/drivers/xen/xen-pciback/pci_stub.c
> > b/drivers/xen/xen-pciback/pci_stub.c
> > index 097e536..425bd0b 100644
> > --- a/drivers/xen/xen-pciback/pci_stub.c
> > +++ b/drivers/xen/xen-pciback/pci_stub.c
> > @@ -4,6 +4,8 @@
> >   * Ryan Wilson <hap9@epoch.ncsc.mil>
> >   * Chris Bookholt <hap10@epoch.ncsc.mil>
> >   */
> > +#define DEBUG 1
> > +
> >  #include <linux/module.h>
> >  #include <linux/init.h>
> >  #include <linux/rwsem.h>
> > @@ -97,13 +99,15 @@ static void pcistub_device_release(struct kref
> > *kref)
> >  	/* Call the reset function which does not take lock as this
> >  	 * is called from "unbind" which takes a device_lock mutex.
> >  	 */
> > +	dev_dbg(&psdev->dev->dev, "FLR locked..\n");
> >  	__pci_reset_function_locked(psdev->dev);
> >  	if (pci_load_and_free_saved_state(psdev->dev,
> >  					  &dev_data->pci_saved_state)) {
> >  		dev_dbg(&psdev->dev->dev, "Could not reload PCI state\n");
> > -	} else
> > +	} else {
> > +		dev_dbg(&psdev->dev->dev, "Reloading PCI state..\n");
> >  		pci_restore_state(psdev->dev);
> > -
> > +	}
> >  	/* Disable the device */
> >  	xen_pcibk_reset_device(psdev->dev);
> >
> > @@ -353,16 +357,16 @@ static int __devinit pcistub_init_device(struct
> > pci_dev *dev)
> >  	if (err)
> >  		goto config_release;
> >
> > -	dev_dbg(&dev->dev, "reseting (FLR, D3, etc) the device\n");
> > -	__pci_reset_function_locked(dev);
> > -
> >  	/* We need the device active to save the state. */
> >  	dev_dbg(&dev->dev, "save state of device\n");
> >  	pci_save_state(dev);
> >  	dev_data->pci_saved_state = pci_store_saved_state(dev);
> >  	if (!dev_data->pci_saved_state)
> >  		dev_err(&dev->dev, "Could not store PCI conf saved state!\n");
> > -
> > +	else {
> > +		dev_dbg(&dev->dev, "reseting (FLR, D3, etc) the device\n");
> > +		__pci_reset_function_locked(dev);
> > +	}
> >  	/* Now disable the device (this also ensures some private device
> >  	 * data is setup before we export)
> >  	 */

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 07 04:38:28 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Sep 2012 04:38:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9qKL-0007OX-Br; Fri, 07 Sep 2012 04:37:57 +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 1T9qKJ-0007OS-K1
	for xen-devel@lists.xen.org; Fri, 07 Sep 2012 04:37:55 +0000
Received: from [85.158.143.99:5456] by server-2.bemta-4.messagelabs.com id
	DD/18-21239-22A79405; Fri, 07 Sep 2012 04:37:54 +0000
X-Env-Sender: msw@amazon.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1346992673!28445822!1
X-Originating-IP: [72.21.196.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNzIuMjEuMTk2LjI1ID0+IDEyMzM4MA==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11298 invoked from network); 7 Sep 2012 04:37:54 -0000
Received: from smtp-fw-2101.amazon.com (HELO smtp-fw-2101.amazon.com)
	(72.21.196.25)
	by server-3.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Sep 2012 04:37:54 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=amazon.com; i=msw@amazon.com; q=dns/txt; s=rte02;
	t=1346992674; x=1378528674;
	h=mime-version:content-transfer-encoding:subject:
	message-id:date:from:to:cc;
	bh=xV5gG9DcIClK7zPtDk2lb4t2b+iQmJrwA9V1RT7kZEU=;
	b=YYUbrREjy+e0OZx3P/IRMZVkDyosNWYmRw6EOfp1QadWLb5fJQ1xTJZr
	3+1Vakx1s4dUmOYn2VN4cX1+EAMRJQ==;
X-IronPort-AV: E=Sophos;i="4.80,384,1344211200"; d="scan'208";a="435963577"
Received: from smtp-in-1101.vdc.amazon.com ([10.146.54.37])
	by smtp-border-fw-out-2101.iad2.amazon.com with
	ESMTP/TLS/DHE-RSA-AES256-SHA; 07 Sep 2012 04:37:52 +0000
Received: from ex10-hub-9001.ant.amazon.com (ex10-hub-9001.ant.amazon.com
	[10.185.137.58])
	by smtp-in-1101.vdc.amazon.com (8.13.8/8.13.8) with ESMTP id
	q874bo8m020075
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL);
	Fri, 7 Sep 2012 04:37:51 GMT
Received: from u002268147cd4502c336d.ant.amazon.com (10.224.80.41) by
	ex10-hub-9001.ant.amazon.com (10.185.137.58) with Microsoft SMTP Server
	id 14.2.247.3; Thu, 6 Sep 2012 21:37:45 -0700
MIME-Version: 1.0
Message-ID: <patchbomb.1346992557@u002268147cd4502c336d.ant.amazon.com>
User-Agent: Mercurial-patchbomb/2.3.1
Date: Thu, 6 Sep 2012 21:35:57 -0700
From: Matt Wilson <msw@amazon.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>, Ian Campbell
	<Ian.Campbell@citrix.com>
Cc: xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH 0 of 2 v3] improve checking for documentation
 tools and formatting
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This version addresses feedback from v2. Please let me know if there
are any other concerns.

Matt

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 07 04:38:28 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Sep 2012 04:38:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9qKL-0007OX-Br; Fri, 07 Sep 2012 04:37:57 +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 1T9qKJ-0007OS-K1
	for xen-devel@lists.xen.org; Fri, 07 Sep 2012 04:37:55 +0000
Received: from [85.158.143.99:5456] by server-2.bemta-4.messagelabs.com id
	DD/18-21239-22A79405; Fri, 07 Sep 2012 04:37:54 +0000
X-Env-Sender: msw@amazon.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1346992673!28445822!1
X-Originating-IP: [72.21.196.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNzIuMjEuMTk2LjI1ID0+IDEyMzM4MA==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11298 invoked from network); 7 Sep 2012 04:37:54 -0000
Received: from smtp-fw-2101.amazon.com (HELO smtp-fw-2101.amazon.com)
	(72.21.196.25)
	by server-3.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Sep 2012 04:37:54 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=amazon.com; i=msw@amazon.com; q=dns/txt; s=rte02;
	t=1346992674; x=1378528674;
	h=mime-version:content-transfer-encoding:subject:
	message-id:date:from:to:cc;
	bh=xV5gG9DcIClK7zPtDk2lb4t2b+iQmJrwA9V1RT7kZEU=;
	b=YYUbrREjy+e0OZx3P/IRMZVkDyosNWYmRw6EOfp1QadWLb5fJQ1xTJZr
	3+1Vakx1s4dUmOYn2VN4cX1+EAMRJQ==;
X-IronPort-AV: E=Sophos;i="4.80,384,1344211200"; d="scan'208";a="435963577"
Received: from smtp-in-1101.vdc.amazon.com ([10.146.54.37])
	by smtp-border-fw-out-2101.iad2.amazon.com with
	ESMTP/TLS/DHE-RSA-AES256-SHA; 07 Sep 2012 04:37:52 +0000
Received: from ex10-hub-9001.ant.amazon.com (ex10-hub-9001.ant.amazon.com
	[10.185.137.58])
	by smtp-in-1101.vdc.amazon.com (8.13.8/8.13.8) with ESMTP id
	q874bo8m020075
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL);
	Fri, 7 Sep 2012 04:37:51 GMT
Received: from u002268147cd4502c336d.ant.amazon.com (10.224.80.41) by
	ex10-hub-9001.ant.amazon.com (10.185.137.58) with Microsoft SMTP Server
	id 14.2.247.3; Thu, 6 Sep 2012 21:37:45 -0700
MIME-Version: 1.0
Message-ID: <patchbomb.1346992557@u002268147cd4502c336d.ant.amazon.com>
User-Agent: Mercurial-patchbomb/2.3.1
Date: Thu, 6 Sep 2012 21:35:57 -0700
From: Matt Wilson <msw@amazon.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>, Ian Campbell
	<Ian.Campbell@citrix.com>
Cc: xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH 0 of 2 v3] improve checking for documentation
 tools and formatting
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This version addresses feedback from v2. Please let me know if there
are any other concerns.

Matt

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 07 04:38:33 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Sep 2012 04: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 1T9qKU-0007PV-UD; Fri, 07 Sep 2012 04:38:06 +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 1T9qKS-0007PC-L1
	for xen-devel@lists.xen.org; Fri, 07 Sep 2012 04:38:05 +0000
Received: from [85.158.138.51:57360] by server-3.bemta-3.messagelabs.com id
	55/68-21322-B2A79405; Fri, 07 Sep 2012 04:38:03 +0000
X-Env-Sender: msw@amazon.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1346992681!21093738!1
X-Originating-IP: [207.171.184.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA3LjE3MS4xODQuMjUgPT4gMzE1OTg5\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7011 invoked from network); 7 Sep 2012 04:38:02 -0000
Received: from smtp-fw-9101.amazon.com (HELO smtp-fw-9101.amazon.com)
	(207.171.184.25)
	by server-3.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Sep 2012 04:38: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=1346992682; x=1378528682;
	h=mime-version:content-transfer-encoding:subject:
	message-id:in-reply-to:references:date:from:to:cc;
	bh=fpjo+nziFtT5iQge1VcaR5TfSY9yxAjPuf28VCdTy0Q=;
	b=iufiPGHGMwFO15AnWGMBHtObuHf0QkKV+6Mvh+S9QmT7EaY0lT7y21wd
	2v+GOnkPF3R4qklCbiTyQek7hvstIg==;
X-IronPort-AV: E=Sophos;i="4.80,384,1344211200"; d="scan'208";a="1022562338"
Received: from smtp-in-6001.iad6.amazon.com ([10.195.76.178])
	by smtp-border-fw-out-9101.sea19.amazon.com with
	ESMTP/TLS/DHE-RSA-AES256-SHA; 07 Sep 2012 04:37:59 +0000
Received: from ex10-hub-9001.ant.amazon.com (ex10-hub-9001.ant.amazon.com
	[10.185.137.58])
	by smtp-in-6001.iad6.amazon.com (8.13.8/8.13.8) with ESMTP id
	q874bvmQ006495
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL);
	Fri, 7 Sep 2012 04:37:58 GMT
Received: from u002268147cd4502c336d.ant.amazon.com (10.224.80.41) by
	ex10-hub-9001.ant.amazon.com (10.185.137.58) with Microsoft SMTP Server
	id 14.2.247.3; Thu, 6 Sep 2012 21:37:52 -0700
MIME-Version: 1.0
X-Mercurial-Node: 3b3582f4dc423daa80404af6a785f60fc9306ce0
Message-ID: <3b3582f4dc423daa8040.1346992558@u002268147cd4502c336d.ant.amazon.com>
In-Reply-To: <patchbomb.1346992557@u002268147cd4502c336d.ant.amazon.com>
References: <patchbomb.1346992557@u002268147cd4502c336d.ant.amazon.com>
User-Agent: Mercurial-patchbomb/2.3.1
Date: Thu, 6 Sep 2012 21:35:58 -0700
From: Matt Wilson <msw@amazon.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>, Ian Campbell
	<Ian.Campbell@citrix.com>
Cc: xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH 1 of 2 v3] tools: check for documentation
 generation tools at configure 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

It is sometimes hard to discover all the optional tools that should be
on a system to build all available Xen documentation. By checking for
documentation generation tools at ./configure time and displaying a
warning, Xen packagers will more easily learn about new optional build
dependencies, like markdown, when they are introduced.

Signed-off-by: Matt Wilson <msw@amazon.com>

---
Changes since v1:
 * require that ./configure be run before building docs
 * remove Docs.mk and make Tools.mk the canonical locaiton where
   docs tools are defined (via ./configure)
 * fold in checking for markdown_py

Changes since v2:
 * drop the AX_DOCS_TOOL_PROG variant, just use AX_DOCS_TOOL_PROGS
 * use the lowercase version of the autoconf variable name for the
   help text

diff -r d7e4efa17fb0 -r 3b3582f4dc42 README
--- a/README	Tue Aug 28 15:35:08 2012 -0700
+++ b/README	Thu Sep 06 21:31:51 2012 -0700
@@ -28,8 +28,9 @@
 your system. For full documentation, see the Xen User Manual. If this
 is a pre-built release then you can find the manual at:
  dist/install/usr/share/doc/xen/pdf/user.pdf
-If you have a source release, then 'make -C docs' will build the
-manual at docs/pdf/user.pdf.
+If you have a source release and the required documentation generation
+tools, then './configure; make -C docs' will build the manual at
+docs/pdf/user.pdf.
 
 Quick-Start Guide
 =================
@@ -59,7 +60,6 @@
     * GNU gettext
     * 16-bit x86 assembler, loader and compiler (dev86 rpm or bin86 & bcc debs)
     * ACPI ASL compiler (iasl)
-    * markdown
 
 In addition to the above there are a number of optional build
 prerequisites. Omitting these will cause the related features to be
@@ -67,6 +67,7 @@
     * Development install of Ocaml (e.g. ocaml-nox and
       ocaml-findlib). Required to build ocaml components which
       includes the alternative ocaml xenstored.
+    * markdown
 
 Second, you need to acquire a suitable kernel for use in domain 0. If
 possible you should use a kernel provided by your OS distributor. If
diff -r d7e4efa17fb0 -r 3b3582f4dc42 config/Tools.mk.in
--- a/config/Tools.mk.in	Tue Aug 28 15:35:08 2012 -0700
+++ b/config/Tools.mk.in	Thu Sep 06 21:31:51 2012 -0700
@@ -22,6 +22,18 @@
 LD86                := @LD86@
 BCC                 := @BCC@
 IASL                := @IASL@
+PS2PDF              := @PS2PDF@
+DVIPS               := @DVIPS@
+LATEX               := @LATEX@
+FIG2DEV             := @FIG2DEV@
+LATEX2HTML          := @LATEX2HTML@
+DOXYGEN             := @DOXYGEN@
+POD2MAN             := @POD2MAN@
+POD2HTML            := @POD2HTML@
+POD2TEXT            := @POD2TEXT@
+DOT                 := @DOT@
+NEATO               := @NEATO@
+MARKDOWN            := @MARKDOWN@
 
 # Extra folder for libs/includes
 PREPEND_INCLUDES    := @PREPEND_INCLUDES@
diff -r d7e4efa17fb0 -r 3b3582f4dc42 docs/Makefile
--- a/docs/Makefile	Tue Aug 28 15:35:08 2012 -0700
+++ b/docs/Makefile	Thu Sep 06 21:31:51 2012 -0700
@@ -2,7 +2,7 @@
 
 XEN_ROOT=$(CURDIR)/..
 include $(XEN_ROOT)/Config.mk
-include $(XEN_ROOT)/docs/Docs.mk
+-include $(XEN_ROOT)/config/Tools.mk
 
 VERSION		= xen-unstable
 
@@ -26,10 +26,12 @@
 
 .PHONY: build
 build: html txt man-pages
-	@if which $(DOT) 1>/dev/null 2>/dev/null ; then              \
-	$(MAKE) -C xen-api build ; else                              \
-        echo "Graphviz (dot) not installed; skipping xen-api." ; fi
+ifdef DOT
+	$(MAKE) -C xen-api build
 	rm -f *.aux *.dvi *.bbl *.blg *.glo *.idx *.ilg *.log *.ind *.toc
+else
+	@echo "Graphviz (dot) not installed; skipping xen-api."
+endif
 
 .PHONY: dev-docs
 dev-docs: python-dev-docs
@@ -42,18 +44,21 @@
 
 .PHONY: python-dev-docs
 python-dev-docs:
-	@mkdir -v -p api/tools/python
-	@set -e ; if which $(DOXYGEN) 1>/dev/null 2>/dev/null; then \
-        echo "Running doxygen to generate Python tools APIs ... "; \
-	$(DOXYGEN) Doxyfile;                                       \
-	$(MAKE) -C api/tools/python/latex ; else                   \
-        echo "Doxygen not installed; skipping python-dev-docs."; fi
+ifdef DOXYGEN
+	@echo "Running doxygen to generate Python tools APIs ... "
+	mkdir -v -p api/tools/python
+	$(DOXYGEN) Doxyfile && $(MAKE) -C api/tools/python/latex
+else
+	@echo "Doxygen not installed; skipping python-dev-docs."
+endif
 
 .PHONY: man-pages
 man-pages:
-	@if which $(POD2MAN) 1>/dev/null 2>/dev/null; then \
-	$(MAKE) $(DOC_MAN1) $(DOC_MAN5); else              \
-	echo "pod2man not installed; skipping man-pages."; fi
+ifdef POD2MAN
+	$(MAKE) $(DOC_MAN1) $(DOC_MAN5)
+else
+	@echo "pod2man not installed; skipping man-pages."
+endif
 
 man1/%.1: man/%.pod.1 Makefile
 	$(INSTALL_DIR) $(@D)
@@ -94,30 +99,40 @@
 	perl -w -- ./gen-html-index -i INDEX html $(DOC_HTML)
 
 html/%.html: %.markdown
-	@$(INSTALL_DIR) $(@D)
-	@set -e ; if which $(MARKDOWN) 1>/dev/null 2>/dev/null; then \
-	echo "Running markdown to generate $*.html ... "; \
+	$(INSTALL_DIR) $(@D)
+ifdef MARKDOWN
+	@echo "Running markdown to generate $*.html ... "
 	$(MARKDOWN) $< > $@.tmp ; \
-	$(call move-if-changed,$@.tmp,$@) ; else \
-	echo "markdown not installed; skipping $*.html."; fi
+	$(call move-if-changed,$@.tmp,$@)
+else
+	@echo "markdown not installed; skipping $*.html."
+endif
 
 html/%.txt: %.txt
-	@$(INSTALL_DIR) $(@D)
+	$(INSTALL_DIR) $(@D)
 	cp $< $@
 
 html/man/%.1.html: man/%.pod.1 Makefile
 	$(INSTALL_DIR) $(@D)
+ifdef POD2HTML
 	$(POD2HTML) --infile=$< --outfile=$@.tmp
 	$(call move-if-changed,$@.tmp,$@)
+else
+	@echo "pod2html not installed; skipping $<."
+endif
 
 html/man/%.5.html: man/%.pod.5 Makefile
 	$(INSTALL_DIR) $(@D)
+ifdef POD2HTML
 	$(POD2HTML) --infile=$< --outfile=$@.tmp
 	$(call move-if-changed,$@.tmp,$@)
+else
+	@echo "pod2html not installed; skipping $<."
+endif
 
 html/hypercall/index.html: ./xen-headers
 	rm -rf $(@D)
-	@$(INSTALL_DIR) $(@D)
+	$(INSTALL_DIR) $(@D)
 	./xen-headers -O $(@D) \
 		-T 'arch-x86_64 - Xen public headers' \
 		-X arch-ia64 -X arch-x86_32 -X xen-x86_32 -X arch-arm \
@@ -137,11 +152,24 @@
 
 txt/man/%.1.txt: man/%.pod.1 Makefile
 	$(INSTALL_DIR) $(@D)
+ifdef POD2TEXT
 	$(POD2TEXT) $< $@.tmp
 	$(call move-if-changed,$@.tmp,$@)
+else
+	@echo "pod2text not installed; skipping $<."
+endif
 
 txt/man/%.5.txt: man/%.pod.5 Makefile
 	$(INSTALL_DIR) $(@D)
+ifdef POD2TEXT
 	$(POD2TEXT) $< $@.tmp
 	$(call move-if-changed,$@.tmp,$@)
+else
+	@echo "pod2text not installed; skipping $<."
+endif
 
+ifeq (,$(findstring clean,$(MAKECMDGOALS)))
+$(XEN_ROOT)/config/Tools.mk:
+	$(error You have to run ./configure before building docs)
+endif
+
diff -r d7e4efa17fb0 -r 3b3582f4dc42 docs/xen-api/Makefile
--- a/docs/xen-api/Makefile	Tue Aug 28 15:35:08 2012 -0700
+++ b/docs/xen-api/Makefile	Thu Sep 06 21:31:51 2012 -0700
@@ -2,7 +2,7 @@
 
 XEN_ROOT=$(CURDIR)/../..
 include $(XEN_ROOT)/Config.mk
-include $(XEN_ROOT)/docs/Docs.mk
+-include $(XEN_ROOT)/config/Tools.mk
 
 
 TEX := $(wildcard *.tex)
@@ -42,3 +42,8 @@
 .PHONY: clean
 clean:
 	rm -f *.pdf *.ps *.dvi *.aux *.log *.out $(EPSDOT)
+
+ifeq (,$(findstring clean,$(MAKECMDGOALS)))
+$(XEN_ROOT)/config/Tools.mk:
+	$(error You have to run ./configure before building docs)
+endif
diff -r d7e4efa17fb0 -r 3b3582f4dc42 tools/configure.ac
--- a/tools/configure.ac	Tue Aug 28 15:35:08 2012 -0700
+++ b/tools/configure.ac	Thu Sep 06 21:31:51 2012 -0700
@@ -34,6 +34,7 @@
 m4_include([m4/curses.m4])
 m4_include([m4/pthread.m4])
 m4_include([m4/ptyfuncs.m4])
+m4_include([m4/docs_tool.m4])
 
 # Enable/disable options
 AX_ARG_DEFAULT_DISABLE([githttp], [Download GIT repositories via HTTP])
@@ -80,6 +81,18 @@
 AC_PATH_PROG([BISON], [bison])
 AC_PATH_PROG([FLEX], [flex])
 AX_PATH_PROG_OR_FAIL([PERL], [perl])
+AX_DOCS_TOOL_PROGS([PS2PDF], [ps2pdf])
+AX_DOCS_TOOL_PROGS([DVIPS], [dvips])
+AX_DOCS_TOOL_PROGS([LATEX], [latex])
+AX_DOCS_TOOL_PROGS([FIG2DEV], [fig2dev])
+AX_DOCS_TOOL_PROGS([LATEX2HTML], [latex2html])
+AX_DOCS_TOOL_PROGS([DOXYGEN], [doxygen])
+AX_DOCS_TOOL_PROGS([POD2MAN], [pod2man])
+AX_DOCS_TOOL_PROGS([POD2HTML], [pod2html])
+AX_DOCS_TOOL_PROGS([POD2TEXT], [pod2text])
+AX_DOCS_TOOL_PROGS([DOT], [dot])
+AX_DOCS_TOOL_PROGS([NEATO], [neato])
+AX_DOCS_TOOL_PROGS([MARKDOWN], [markdown markdown_py])
 AS_IF([test "x$xapi" = "xy"], [
     AX_PATH_PROG_OR_FAIL([CURL], [curl-config])
     AX_PATH_PROG_OR_FAIL([XML], [xml2-config])
diff -r d7e4efa17fb0 -r 3b3582f4dc42 tools/m4/docs_tool.m4
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/tools/m4/docs_tool.m4	Thu Sep 06 21:31:51 2012 -0700
@@ -0,0 +1,10 @@
+# $1: autoconf variable name
+# $2: list of programs to check for
+AC_DEFUN([AX_DOCS_TOOL_PROGS], [
+dnl
+    AC_ARG_VAR([$1], [Path to ] m4_tolower($1) [ tool])
+    AC_PATH_PROGS([$1], [$2])
+    AS_IF([! test -x "$ac_cv_path_$1"], [
+        AC_MSG_WARN([$2 is not available so some documentation won't be built])
+    ])
+])

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 07 04:38:33 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Sep 2012 04: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 1T9qKV-0007Pd-AB; Fri, 07 Sep 2012 04:38:07 +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 1T9qKT-0007PI-Kx
	for xen-devel@lists.xen.org; Fri, 07 Sep 2012 04:38:05 +0000
Received: from [85.158.138.51:57409] by server-12.bemta-3.messagelabs.com id
	52/F8-10384-C2A79405; Fri, 07 Sep 2012 04:38:04 +0000
X-Env-Sender: msw@amazon.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1346992683!21093743!1
X-Originating-IP: [72.21.198.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNzIuMjEuMTk4LjI1ID0+IDE3Mzg4MQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7041 invoked from network); 7 Sep 2012 04:38:04 -0000
Received: from smtp-fw-4101.amazon.com (HELO smtp-fw-4101.amazon.com)
	(72.21.198.25)
	by server-3.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Sep 2012 04:38: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=1346992684; x=1378528684;
	h=mime-version:content-transfer-encoding:subject:
	message-id:in-reply-to:references:date:from:to:cc;
	bh=Z+wQeEFa5oLrw/IXYhD46QMeHlDmwn+q18VK5CITDjY=;
	b=CTyqQIVyUxQiprxg0nA9cPbJXqflDyGJ8RIBLmzGQxS+wnWRguXVUJoa
	wz/echDWxJlC5ouBvVNMwqbXGr6uGg==;
X-IronPort-AV: E=Sophos;i="4.80,384,1344211200"; d="scan'208";a="792562622"
Received: from smtp-in-1101.vdc.amazon.com ([10.146.54.37])
	by smtp-border-fw-out-4101.iad4.amazon.com with
	ESMTP/TLS/DHE-RSA-AES256-SHA; 07 Sep 2012 04:38:00 +0000
Received: from ex10-hub-9001.ant.amazon.com (ex10-hub-9001.ant.amazon.com
	[10.185.137.58])
	by smtp-in-1101.vdc.amazon.com (8.13.8/8.13.8) with ESMTP id
	q874bxo5020155
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL);
	Fri, 7 Sep 2012 04:38:00 GMT
Received: from u002268147cd4502c336d.ant.amazon.com (10.224.80.41) by
	ex10-hub-9001.ant.amazon.com (10.185.137.58) with Microsoft SMTP Server
	id 14.2.247.3; Thu, 6 Sep 2012 21:37:58 -0700
MIME-Version: 1.0
X-Mercurial-Node: 6a1ee7eacd9c90cce2644201072297ea3127eb01
Message-ID: <6a1ee7eacd9c90cce264.1346992559@u002268147cd4502c336d.ant.amazon.com>
In-Reply-To: <patchbomb.1346992557@u002268147cd4502c336d.ant.amazon.com>
References: <patchbomb.1346992557@u002268147cd4502c336d.ant.amazon.com>
User-Agent: Mercurial-patchbomb/2.3.1
Date: Thu, 6 Sep 2012 21:35:59 -0700
From: Matt Wilson <msw@amazon.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>, Ian Campbell
	<Ian.Campbell@citrix.com>
Cc: xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH 2 of 2 v3] docs: use elinks to format
 markdown-generated html to text
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Markdown, while easy to read and write, isn't the most consumable
format for users reading documentation on a terminal. This patch uses
elinks (by default) to format markdown produced HTML into text files.

Signed-off-by: Matt Wilson <msw@amazon.com>

---
Changes since v3:
 * check for html to text dump tool in ./configure
 * switch to using elinks
 * allow command line flags to dump tool to be specified

Changes since v4:
 * none, just adjusted the commit message

diff -r 3b3582f4dc42 -r 6a1ee7eacd9c config/Tools.mk.in
--- a/config/Tools.mk.in	Thu Sep 06 21:31:51 2012 -0700
+++ b/config/Tools.mk.in	Thu Sep 06 21:33:05 2012 -0700
@@ -34,6 +34,8 @@
 DOT                 := @DOT@
 NEATO               := @NEATO@
 MARKDOWN            := @MARKDOWN@
+HTMLDUMP            := @HTMLDUMP@
+HTMLDUMPFLAGS       := @HTMLDUMPFLAGS@
 
 # Extra folder for libs/includes
 PREPEND_INCLUDES    := @PREPEND_INCLUDES@
diff -r 3b3582f4dc42 -r 6a1ee7eacd9c docs/Makefile
--- a/docs/Makefile	Thu Sep 06 21:31:51 2012 -0700
+++ b/docs/Makefile	Thu Sep 06 21:33:05 2012 -0700
@@ -146,9 +146,20 @@
 	$(call move-if-changed,$@.tmp,$@)
 
 txt/%.txt: %.markdown
-	$(INSTALL_DIR) $(@D)
-	cp $< $@.tmp
+	@$(INSTALL_DIR) $(@D)
+ifdef MARKDOWN
+ifdef HTMLDUMP
+	@echo "Running markdown to generate $*.txt ... "; \
+	$(MARKDOWN) $< | $(HTMLDUMP) $(HTMLDUMPFLAGS) > $@.tmp
 	$(call move-if-changed,$@.tmp,$@)
+else
+	@echo "html dump tool (like elinks) not installed; just copying $<." \;
+	cp $< $@;
+endif
+else
+	@echo "markdown not installed; just copying $<." \;
+	cp $< $@;
+endif
 
 txt/man/%.1.txt: man/%.pod.1 Makefile
 	$(INSTALL_DIR) $(@D)
diff -r 3b3582f4dc42 -r 6a1ee7eacd9c tools/configure.ac
--- a/tools/configure.ac	Thu Sep 06 21:31:51 2012 -0700
+++ b/tools/configure.ac	Thu Sep 06 21:33:05 2012 -0700
@@ -93,6 +93,15 @@
 AX_DOCS_TOOL_PROGS([DOT], [dot])
 AX_DOCS_TOOL_PROGS([NEATO], [neato])
 AX_DOCS_TOOL_PROGS([MARKDOWN], [markdown markdown_py])
+AC_ARG_VAR([HTMLDUMP],
+           [Path to html-to-text generation tool (default: elinks)])
+AC_PATH_PROG([HTMLDUMP], [elinks])
+AS_IF([! test -x "$ac_cv_path_HTMLDUMP"], [
+    AC_MSG_WARN([$ac_cv_path_HTMLDUMP is not available so text documentation will be unformatted markdown])
+])
+AC_SUBST([HTMLDUMPFLAGS], ["-dump"])
+AC_ARG_VAR([HTMLDUMPFLAGS], [Flags passed to html to text translation tool])
+
 AS_IF([test "x$xapi" = "xy"], [
     AX_PATH_PROG_OR_FAIL([CURL], [curl-config])
     AX_PATH_PROG_OR_FAIL([XML], [xml2-config])

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 07 04:38:33 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Sep 2012 04: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 1T9qKU-0007PV-UD; Fri, 07 Sep 2012 04:38:06 +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 1T9qKS-0007PC-L1
	for xen-devel@lists.xen.org; Fri, 07 Sep 2012 04:38:05 +0000
Received: from [85.158.138.51:57360] by server-3.bemta-3.messagelabs.com id
	55/68-21322-B2A79405; Fri, 07 Sep 2012 04:38:03 +0000
X-Env-Sender: msw@amazon.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1346992681!21093738!1
X-Originating-IP: [207.171.184.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA3LjE3MS4xODQuMjUgPT4gMzE1OTg5\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7011 invoked from network); 7 Sep 2012 04:38:02 -0000
Received: from smtp-fw-9101.amazon.com (HELO smtp-fw-9101.amazon.com)
	(207.171.184.25)
	by server-3.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Sep 2012 04:38: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=1346992682; x=1378528682;
	h=mime-version:content-transfer-encoding:subject:
	message-id:in-reply-to:references:date:from:to:cc;
	bh=fpjo+nziFtT5iQge1VcaR5TfSY9yxAjPuf28VCdTy0Q=;
	b=iufiPGHGMwFO15AnWGMBHtObuHf0QkKV+6Mvh+S9QmT7EaY0lT7y21wd
	2v+GOnkPF3R4qklCbiTyQek7hvstIg==;
X-IronPort-AV: E=Sophos;i="4.80,384,1344211200"; d="scan'208";a="1022562338"
Received: from smtp-in-6001.iad6.amazon.com ([10.195.76.178])
	by smtp-border-fw-out-9101.sea19.amazon.com with
	ESMTP/TLS/DHE-RSA-AES256-SHA; 07 Sep 2012 04:37:59 +0000
Received: from ex10-hub-9001.ant.amazon.com (ex10-hub-9001.ant.amazon.com
	[10.185.137.58])
	by smtp-in-6001.iad6.amazon.com (8.13.8/8.13.8) with ESMTP id
	q874bvmQ006495
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL);
	Fri, 7 Sep 2012 04:37:58 GMT
Received: from u002268147cd4502c336d.ant.amazon.com (10.224.80.41) by
	ex10-hub-9001.ant.amazon.com (10.185.137.58) with Microsoft SMTP Server
	id 14.2.247.3; Thu, 6 Sep 2012 21:37:52 -0700
MIME-Version: 1.0
X-Mercurial-Node: 3b3582f4dc423daa80404af6a785f60fc9306ce0
Message-ID: <3b3582f4dc423daa8040.1346992558@u002268147cd4502c336d.ant.amazon.com>
In-Reply-To: <patchbomb.1346992557@u002268147cd4502c336d.ant.amazon.com>
References: <patchbomb.1346992557@u002268147cd4502c336d.ant.amazon.com>
User-Agent: Mercurial-patchbomb/2.3.1
Date: Thu, 6 Sep 2012 21:35:58 -0700
From: Matt Wilson <msw@amazon.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>, Ian Campbell
	<Ian.Campbell@citrix.com>
Cc: xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH 1 of 2 v3] tools: check for documentation
 generation tools at configure 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

It is sometimes hard to discover all the optional tools that should be
on a system to build all available Xen documentation. By checking for
documentation generation tools at ./configure time and displaying a
warning, Xen packagers will more easily learn about new optional build
dependencies, like markdown, when they are introduced.

Signed-off-by: Matt Wilson <msw@amazon.com>

---
Changes since v1:
 * require that ./configure be run before building docs
 * remove Docs.mk and make Tools.mk the canonical locaiton where
   docs tools are defined (via ./configure)
 * fold in checking for markdown_py

Changes since v2:
 * drop the AX_DOCS_TOOL_PROG variant, just use AX_DOCS_TOOL_PROGS
 * use the lowercase version of the autoconf variable name for the
   help text

diff -r d7e4efa17fb0 -r 3b3582f4dc42 README
--- a/README	Tue Aug 28 15:35:08 2012 -0700
+++ b/README	Thu Sep 06 21:31:51 2012 -0700
@@ -28,8 +28,9 @@
 your system. For full documentation, see the Xen User Manual. If this
 is a pre-built release then you can find the manual at:
  dist/install/usr/share/doc/xen/pdf/user.pdf
-If you have a source release, then 'make -C docs' will build the
-manual at docs/pdf/user.pdf.
+If you have a source release and the required documentation generation
+tools, then './configure; make -C docs' will build the manual at
+docs/pdf/user.pdf.
 
 Quick-Start Guide
 =================
@@ -59,7 +60,6 @@
     * GNU gettext
     * 16-bit x86 assembler, loader and compiler (dev86 rpm or bin86 & bcc debs)
     * ACPI ASL compiler (iasl)
-    * markdown
 
 In addition to the above there are a number of optional build
 prerequisites. Omitting these will cause the related features to be
@@ -67,6 +67,7 @@
     * Development install of Ocaml (e.g. ocaml-nox and
       ocaml-findlib). Required to build ocaml components which
       includes the alternative ocaml xenstored.
+    * markdown
 
 Second, you need to acquire a suitable kernel for use in domain 0. If
 possible you should use a kernel provided by your OS distributor. If
diff -r d7e4efa17fb0 -r 3b3582f4dc42 config/Tools.mk.in
--- a/config/Tools.mk.in	Tue Aug 28 15:35:08 2012 -0700
+++ b/config/Tools.mk.in	Thu Sep 06 21:31:51 2012 -0700
@@ -22,6 +22,18 @@
 LD86                := @LD86@
 BCC                 := @BCC@
 IASL                := @IASL@
+PS2PDF              := @PS2PDF@
+DVIPS               := @DVIPS@
+LATEX               := @LATEX@
+FIG2DEV             := @FIG2DEV@
+LATEX2HTML          := @LATEX2HTML@
+DOXYGEN             := @DOXYGEN@
+POD2MAN             := @POD2MAN@
+POD2HTML            := @POD2HTML@
+POD2TEXT            := @POD2TEXT@
+DOT                 := @DOT@
+NEATO               := @NEATO@
+MARKDOWN            := @MARKDOWN@
 
 # Extra folder for libs/includes
 PREPEND_INCLUDES    := @PREPEND_INCLUDES@
diff -r d7e4efa17fb0 -r 3b3582f4dc42 docs/Makefile
--- a/docs/Makefile	Tue Aug 28 15:35:08 2012 -0700
+++ b/docs/Makefile	Thu Sep 06 21:31:51 2012 -0700
@@ -2,7 +2,7 @@
 
 XEN_ROOT=$(CURDIR)/..
 include $(XEN_ROOT)/Config.mk
-include $(XEN_ROOT)/docs/Docs.mk
+-include $(XEN_ROOT)/config/Tools.mk
 
 VERSION		= xen-unstable
 
@@ -26,10 +26,12 @@
 
 .PHONY: build
 build: html txt man-pages
-	@if which $(DOT) 1>/dev/null 2>/dev/null ; then              \
-	$(MAKE) -C xen-api build ; else                              \
-        echo "Graphviz (dot) not installed; skipping xen-api." ; fi
+ifdef DOT
+	$(MAKE) -C xen-api build
 	rm -f *.aux *.dvi *.bbl *.blg *.glo *.idx *.ilg *.log *.ind *.toc
+else
+	@echo "Graphviz (dot) not installed; skipping xen-api."
+endif
 
 .PHONY: dev-docs
 dev-docs: python-dev-docs
@@ -42,18 +44,21 @@
 
 .PHONY: python-dev-docs
 python-dev-docs:
-	@mkdir -v -p api/tools/python
-	@set -e ; if which $(DOXYGEN) 1>/dev/null 2>/dev/null; then \
-        echo "Running doxygen to generate Python tools APIs ... "; \
-	$(DOXYGEN) Doxyfile;                                       \
-	$(MAKE) -C api/tools/python/latex ; else                   \
-        echo "Doxygen not installed; skipping python-dev-docs."; fi
+ifdef DOXYGEN
+	@echo "Running doxygen to generate Python tools APIs ... "
+	mkdir -v -p api/tools/python
+	$(DOXYGEN) Doxyfile && $(MAKE) -C api/tools/python/latex
+else
+	@echo "Doxygen not installed; skipping python-dev-docs."
+endif
 
 .PHONY: man-pages
 man-pages:
-	@if which $(POD2MAN) 1>/dev/null 2>/dev/null; then \
-	$(MAKE) $(DOC_MAN1) $(DOC_MAN5); else              \
-	echo "pod2man not installed; skipping man-pages."; fi
+ifdef POD2MAN
+	$(MAKE) $(DOC_MAN1) $(DOC_MAN5)
+else
+	@echo "pod2man not installed; skipping man-pages."
+endif
 
 man1/%.1: man/%.pod.1 Makefile
 	$(INSTALL_DIR) $(@D)
@@ -94,30 +99,40 @@
 	perl -w -- ./gen-html-index -i INDEX html $(DOC_HTML)
 
 html/%.html: %.markdown
-	@$(INSTALL_DIR) $(@D)
-	@set -e ; if which $(MARKDOWN) 1>/dev/null 2>/dev/null; then \
-	echo "Running markdown to generate $*.html ... "; \
+	$(INSTALL_DIR) $(@D)
+ifdef MARKDOWN
+	@echo "Running markdown to generate $*.html ... "
 	$(MARKDOWN) $< > $@.tmp ; \
-	$(call move-if-changed,$@.tmp,$@) ; else \
-	echo "markdown not installed; skipping $*.html."; fi
+	$(call move-if-changed,$@.tmp,$@)
+else
+	@echo "markdown not installed; skipping $*.html."
+endif
 
 html/%.txt: %.txt
-	@$(INSTALL_DIR) $(@D)
+	$(INSTALL_DIR) $(@D)
 	cp $< $@
 
 html/man/%.1.html: man/%.pod.1 Makefile
 	$(INSTALL_DIR) $(@D)
+ifdef POD2HTML
 	$(POD2HTML) --infile=$< --outfile=$@.tmp
 	$(call move-if-changed,$@.tmp,$@)
+else
+	@echo "pod2html not installed; skipping $<."
+endif
 
 html/man/%.5.html: man/%.pod.5 Makefile
 	$(INSTALL_DIR) $(@D)
+ifdef POD2HTML
 	$(POD2HTML) --infile=$< --outfile=$@.tmp
 	$(call move-if-changed,$@.tmp,$@)
+else
+	@echo "pod2html not installed; skipping $<."
+endif
 
 html/hypercall/index.html: ./xen-headers
 	rm -rf $(@D)
-	@$(INSTALL_DIR) $(@D)
+	$(INSTALL_DIR) $(@D)
 	./xen-headers -O $(@D) \
 		-T 'arch-x86_64 - Xen public headers' \
 		-X arch-ia64 -X arch-x86_32 -X xen-x86_32 -X arch-arm \
@@ -137,11 +152,24 @@
 
 txt/man/%.1.txt: man/%.pod.1 Makefile
 	$(INSTALL_DIR) $(@D)
+ifdef POD2TEXT
 	$(POD2TEXT) $< $@.tmp
 	$(call move-if-changed,$@.tmp,$@)
+else
+	@echo "pod2text not installed; skipping $<."
+endif
 
 txt/man/%.5.txt: man/%.pod.5 Makefile
 	$(INSTALL_DIR) $(@D)
+ifdef POD2TEXT
 	$(POD2TEXT) $< $@.tmp
 	$(call move-if-changed,$@.tmp,$@)
+else
+	@echo "pod2text not installed; skipping $<."
+endif
 
+ifeq (,$(findstring clean,$(MAKECMDGOALS)))
+$(XEN_ROOT)/config/Tools.mk:
+	$(error You have to run ./configure before building docs)
+endif
+
diff -r d7e4efa17fb0 -r 3b3582f4dc42 docs/xen-api/Makefile
--- a/docs/xen-api/Makefile	Tue Aug 28 15:35:08 2012 -0700
+++ b/docs/xen-api/Makefile	Thu Sep 06 21:31:51 2012 -0700
@@ -2,7 +2,7 @@
 
 XEN_ROOT=$(CURDIR)/../..
 include $(XEN_ROOT)/Config.mk
-include $(XEN_ROOT)/docs/Docs.mk
+-include $(XEN_ROOT)/config/Tools.mk
 
 
 TEX := $(wildcard *.tex)
@@ -42,3 +42,8 @@
 .PHONY: clean
 clean:
 	rm -f *.pdf *.ps *.dvi *.aux *.log *.out $(EPSDOT)
+
+ifeq (,$(findstring clean,$(MAKECMDGOALS)))
+$(XEN_ROOT)/config/Tools.mk:
+	$(error You have to run ./configure before building docs)
+endif
diff -r d7e4efa17fb0 -r 3b3582f4dc42 tools/configure.ac
--- a/tools/configure.ac	Tue Aug 28 15:35:08 2012 -0700
+++ b/tools/configure.ac	Thu Sep 06 21:31:51 2012 -0700
@@ -34,6 +34,7 @@
 m4_include([m4/curses.m4])
 m4_include([m4/pthread.m4])
 m4_include([m4/ptyfuncs.m4])
+m4_include([m4/docs_tool.m4])
 
 # Enable/disable options
 AX_ARG_DEFAULT_DISABLE([githttp], [Download GIT repositories via HTTP])
@@ -80,6 +81,18 @@
 AC_PATH_PROG([BISON], [bison])
 AC_PATH_PROG([FLEX], [flex])
 AX_PATH_PROG_OR_FAIL([PERL], [perl])
+AX_DOCS_TOOL_PROGS([PS2PDF], [ps2pdf])
+AX_DOCS_TOOL_PROGS([DVIPS], [dvips])
+AX_DOCS_TOOL_PROGS([LATEX], [latex])
+AX_DOCS_TOOL_PROGS([FIG2DEV], [fig2dev])
+AX_DOCS_TOOL_PROGS([LATEX2HTML], [latex2html])
+AX_DOCS_TOOL_PROGS([DOXYGEN], [doxygen])
+AX_DOCS_TOOL_PROGS([POD2MAN], [pod2man])
+AX_DOCS_TOOL_PROGS([POD2HTML], [pod2html])
+AX_DOCS_TOOL_PROGS([POD2TEXT], [pod2text])
+AX_DOCS_TOOL_PROGS([DOT], [dot])
+AX_DOCS_TOOL_PROGS([NEATO], [neato])
+AX_DOCS_TOOL_PROGS([MARKDOWN], [markdown markdown_py])
 AS_IF([test "x$xapi" = "xy"], [
     AX_PATH_PROG_OR_FAIL([CURL], [curl-config])
     AX_PATH_PROG_OR_FAIL([XML], [xml2-config])
diff -r d7e4efa17fb0 -r 3b3582f4dc42 tools/m4/docs_tool.m4
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/tools/m4/docs_tool.m4	Thu Sep 06 21:31:51 2012 -0700
@@ -0,0 +1,10 @@
+# $1: autoconf variable name
+# $2: list of programs to check for
+AC_DEFUN([AX_DOCS_TOOL_PROGS], [
+dnl
+    AC_ARG_VAR([$1], [Path to ] m4_tolower($1) [ tool])
+    AC_PATH_PROGS([$1], [$2])
+    AS_IF([! test -x "$ac_cv_path_$1"], [
+        AC_MSG_WARN([$2 is not available so some documentation won't be built])
+    ])
+])

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 07 04:38:33 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Sep 2012 04: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 1T9qKV-0007Pd-AB; Fri, 07 Sep 2012 04:38:07 +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 1T9qKT-0007PI-Kx
	for xen-devel@lists.xen.org; Fri, 07 Sep 2012 04:38:05 +0000
Received: from [85.158.138.51:57409] by server-12.bemta-3.messagelabs.com id
	52/F8-10384-C2A79405; Fri, 07 Sep 2012 04:38:04 +0000
X-Env-Sender: msw@amazon.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1346992683!21093743!1
X-Originating-IP: [72.21.198.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNzIuMjEuMTk4LjI1ID0+IDE3Mzg4MQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7041 invoked from network); 7 Sep 2012 04:38:04 -0000
Received: from smtp-fw-4101.amazon.com (HELO smtp-fw-4101.amazon.com)
	(72.21.198.25)
	by server-3.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Sep 2012 04:38: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=1346992684; x=1378528684;
	h=mime-version:content-transfer-encoding:subject:
	message-id:in-reply-to:references:date:from:to:cc;
	bh=Z+wQeEFa5oLrw/IXYhD46QMeHlDmwn+q18VK5CITDjY=;
	b=CTyqQIVyUxQiprxg0nA9cPbJXqflDyGJ8RIBLmzGQxS+wnWRguXVUJoa
	wz/echDWxJlC5ouBvVNMwqbXGr6uGg==;
X-IronPort-AV: E=Sophos;i="4.80,384,1344211200"; d="scan'208";a="792562622"
Received: from smtp-in-1101.vdc.amazon.com ([10.146.54.37])
	by smtp-border-fw-out-4101.iad4.amazon.com with
	ESMTP/TLS/DHE-RSA-AES256-SHA; 07 Sep 2012 04:38:00 +0000
Received: from ex10-hub-9001.ant.amazon.com (ex10-hub-9001.ant.amazon.com
	[10.185.137.58])
	by smtp-in-1101.vdc.amazon.com (8.13.8/8.13.8) with ESMTP id
	q874bxo5020155
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL);
	Fri, 7 Sep 2012 04:38:00 GMT
Received: from u002268147cd4502c336d.ant.amazon.com (10.224.80.41) by
	ex10-hub-9001.ant.amazon.com (10.185.137.58) with Microsoft SMTP Server
	id 14.2.247.3; Thu, 6 Sep 2012 21:37:58 -0700
MIME-Version: 1.0
X-Mercurial-Node: 6a1ee7eacd9c90cce2644201072297ea3127eb01
Message-ID: <6a1ee7eacd9c90cce264.1346992559@u002268147cd4502c336d.ant.amazon.com>
In-Reply-To: <patchbomb.1346992557@u002268147cd4502c336d.ant.amazon.com>
References: <patchbomb.1346992557@u002268147cd4502c336d.ant.amazon.com>
User-Agent: Mercurial-patchbomb/2.3.1
Date: Thu, 6 Sep 2012 21:35:59 -0700
From: Matt Wilson <msw@amazon.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>, Ian Campbell
	<Ian.Campbell@citrix.com>
Cc: xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH 2 of 2 v3] docs: use elinks to format
 markdown-generated html to text
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Markdown, while easy to read and write, isn't the most consumable
format for users reading documentation on a terminal. This patch uses
elinks (by default) to format markdown produced HTML into text files.

Signed-off-by: Matt Wilson <msw@amazon.com>

---
Changes since v3:
 * check for html to text dump tool in ./configure
 * switch to using elinks
 * allow command line flags to dump tool to be specified

Changes since v4:
 * none, just adjusted the commit message

diff -r 3b3582f4dc42 -r 6a1ee7eacd9c config/Tools.mk.in
--- a/config/Tools.mk.in	Thu Sep 06 21:31:51 2012 -0700
+++ b/config/Tools.mk.in	Thu Sep 06 21:33:05 2012 -0700
@@ -34,6 +34,8 @@
 DOT                 := @DOT@
 NEATO               := @NEATO@
 MARKDOWN            := @MARKDOWN@
+HTMLDUMP            := @HTMLDUMP@
+HTMLDUMPFLAGS       := @HTMLDUMPFLAGS@
 
 # Extra folder for libs/includes
 PREPEND_INCLUDES    := @PREPEND_INCLUDES@
diff -r 3b3582f4dc42 -r 6a1ee7eacd9c docs/Makefile
--- a/docs/Makefile	Thu Sep 06 21:31:51 2012 -0700
+++ b/docs/Makefile	Thu Sep 06 21:33:05 2012 -0700
@@ -146,9 +146,20 @@
 	$(call move-if-changed,$@.tmp,$@)
 
 txt/%.txt: %.markdown
-	$(INSTALL_DIR) $(@D)
-	cp $< $@.tmp
+	@$(INSTALL_DIR) $(@D)
+ifdef MARKDOWN
+ifdef HTMLDUMP
+	@echo "Running markdown to generate $*.txt ... "; \
+	$(MARKDOWN) $< | $(HTMLDUMP) $(HTMLDUMPFLAGS) > $@.tmp
 	$(call move-if-changed,$@.tmp,$@)
+else
+	@echo "html dump tool (like elinks) not installed; just copying $<." \;
+	cp $< $@;
+endif
+else
+	@echo "markdown not installed; just copying $<." \;
+	cp $< $@;
+endif
 
 txt/man/%.1.txt: man/%.pod.1 Makefile
 	$(INSTALL_DIR) $(@D)
diff -r 3b3582f4dc42 -r 6a1ee7eacd9c tools/configure.ac
--- a/tools/configure.ac	Thu Sep 06 21:31:51 2012 -0700
+++ b/tools/configure.ac	Thu Sep 06 21:33:05 2012 -0700
@@ -93,6 +93,15 @@
 AX_DOCS_TOOL_PROGS([DOT], [dot])
 AX_DOCS_TOOL_PROGS([NEATO], [neato])
 AX_DOCS_TOOL_PROGS([MARKDOWN], [markdown markdown_py])
+AC_ARG_VAR([HTMLDUMP],
+           [Path to html-to-text generation tool (default: elinks)])
+AC_PATH_PROG([HTMLDUMP], [elinks])
+AS_IF([! test -x "$ac_cv_path_HTMLDUMP"], [
+    AC_MSG_WARN([$ac_cv_path_HTMLDUMP is not available so text documentation will be unformatted markdown])
+])
+AC_SUBST([HTMLDUMPFLAGS], ["-dump"])
+AC_ARG_VAR([HTMLDUMPFLAGS], [Flags passed to html to text translation tool])
+
 AS_IF([test "x$xapi" = "xy"], [
     AX_PATH_PROG_OR_FAIL([CURL], [curl-config])
     AX_PATH_PROG_OR_FAIL([XML], [xml2-config])

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 07 05:14:33 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Sep 2012 05: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 1T9qtH-0008Hi-G2; Fri, 07 Sep 2012 05:14: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 1T9qtF-0008Hd-SJ
	for xen-devel@lists.xensource.com; Fri, 07 Sep 2012 05:14:02 +0000
Received: from [85.158.139.83:25139] by server-7.bemta-5.messagelabs.com id
	44/4F-19703-89289405; Fri, 07 Sep 2012 05:14:00 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1346994839!24814460!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTIxNDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22619 invoked from network); 7 Sep 2012 05:14:00 -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;
	7 Sep 2012 05:14:00 -0000
X-IronPort-AV: E=Sophos;i="4.80,384,1344211200"; d="scan'208";a="14398919"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Sep 2012 05:13: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.279.1; Fri, 7 Sep 2012 06:13:59 +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 1T9qtD-0005l6-1N;
	Fri, 07 Sep 2012 05:13:59 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1T9qtC-0007Ze-TN;
	Fri, 07 Sep 2012 06:13:58 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-13659-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 7 Sep 2012 06:13:58 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13659: 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 13659 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13659/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore            fail   like 13658
 test-i386-i386-xl-qemuu-winxpsp3  9 guest-localmigrate         fail like 13658
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail like 13658
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail like 13658

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass

version targeted for testing:
 xen                  ec23c2a11f6f
baseline version:
 xen                  cbc0c2368a6d

------------------------------------------------------------
People who touched revisions under test:
  David Vrabel <david.vrabel@citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Keir Fraser <keir@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                                 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                                     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=ec23c2a11f6f
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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 ec23c2a11f6f
+ branch=xen-unstable
+ revision=ec23c2a11f6f
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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 ec23c2a11f6f ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg
pushing to ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg
searching for changes
remote: adding changesets
remote: adding manifests
remote: adding file changes
remote: added 2 changesets with 2 changes to 2 files

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 07 05:14:33 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Sep 2012 05: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 1T9qtH-0008Hi-G2; Fri, 07 Sep 2012 05:14: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 1T9qtF-0008Hd-SJ
	for xen-devel@lists.xensource.com; Fri, 07 Sep 2012 05:14:02 +0000
Received: from [85.158.139.83:25139] by server-7.bemta-5.messagelabs.com id
	44/4F-19703-89289405; Fri, 07 Sep 2012 05:14:00 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1346994839!24814460!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTIxNDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22619 invoked from network); 7 Sep 2012 05:14:00 -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;
	7 Sep 2012 05:14:00 -0000
X-IronPort-AV: E=Sophos;i="4.80,384,1344211200"; d="scan'208";a="14398919"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Sep 2012 05:13: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.279.1; Fri, 7 Sep 2012 06:13:59 +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 1T9qtD-0005l6-1N;
	Fri, 07 Sep 2012 05:13:59 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1T9qtC-0007Ze-TN;
	Fri, 07 Sep 2012 06:13:58 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-13659-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 7 Sep 2012 06:13:58 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13659: 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 13659 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13659/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore            fail   like 13658
 test-i386-i386-xl-qemuu-winxpsp3  9 guest-localmigrate         fail like 13658
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail like 13658
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail like 13658

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass

version targeted for testing:
 xen                  ec23c2a11f6f
baseline version:
 xen                  cbc0c2368a6d

------------------------------------------------------------
People who touched revisions under test:
  David Vrabel <david.vrabel@citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Keir Fraser <keir@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                                 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                                     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=ec23c2a11f6f
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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 ec23c2a11f6f
+ branch=xen-unstable
+ revision=ec23c2a11f6f
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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 ec23c2a11f6f ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg
pushing to ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg
searching for changes
remote: adding changesets
remote: adding manifests
remote: adding file changes
remote: added 2 changesets with 2 changes to 2 files

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 07 07:33:34 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Sep 2012 07:33: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 1T9t3p-0001R7-2V; Fri, 07 Sep 2012 07:33:05 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <linux@eikelenboom.it>) id 1T9t3l-0001Pz-Jf
	for xen-devel@lists.xensource.com; Fri, 07 Sep 2012 07:33:02 +0000
Received: from [85.158.139.83:50102] by server-10.bemta-5.messagelabs.com id
	4D/A5-10969-C23A9405; Fri, 07 Sep 2012 07:33:00 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-3.tower-182.messagelabs.com!1347003168!29082166!1
X-Originating-IP: [188.40.164.121]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27257 invoked from network); 7 Sep 2012 07:32:49 -0000
Received: from static.121.164.40.188.clients.your-server.de (HELO
	smtp.eikelenboom.it) (188.40.164.121)
	by server-3.tower-182.messagelabs.com with AES256-SHA encrypted SMTP;
	7 Sep 2012 07:32:49 -0000
Received: from 128-64-ftth.onsneteindhoven.nl ([88.159.64.128]:49366
	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 1T9t3a-0007O3-Jl; Fri, 07 Sep 2012 09:32:51 +0200
Date: Fri, 7 Sep 2012 09:32:41 +0200
From: Sander Eikelenboom <linux@eikelenboom.it>
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <488803362.20120907093241@eikelenboom.it>
To: Wei Wang <wei.wang2@amd.com>
In-Reply-To: <5048BB29.4040900@amd.com>
References: <504764E2.4000809@amd.com>
	<326589347.20120906005936@eikelenboom.it>
	<5048A603.3070207@amd.com>
	<483486315.20120906155001@eikelenboom.it>
	<5048BB29.4040900@amd.com>
MIME-Version: 1.0
Content-Type: multipart/mixed;
 boundary="----------0E902503E1C6BF83E"
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH] amd iommu: Dump flags of IO page faults
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

------------0E902503E1C6BF83E
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit


Thursday, September 6, 2012, 5:03:05 PM, you wrote:

> On 09/06/2012 03:50 PM, Sander Eikelenboom wrote:
>>
>> Thursday, September 6, 2012, 3:32:51 PM, you wrote:
>>
>>> On 09/06/2012 12:59 AM, Sander Eikelenboom wrote:
>>>>
>>>> Wednesday, September 5, 2012, 4:42:42 PM, you wrote:
>>>>
>>>>> Hi Jan,
>>>>> Attached patch dumps io page fault flags. The flags show the reason of
>>>>> the fault and tell us if this is an unmapped interrupt fault or a DMA fault.
>>>>
>>>>> Thanks,
>>>>> Wei
>>>>
>>>>> signed-off-by: Wei Wang<wei.wang2@amd.com>
>>>>
>>>>
>>>> I have applied the patch and the flags seem to differ between the faults:
>>>>
>>>> AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0a06, fault address = 0xc2c2c2c0, flags = 0x000
>>>> (XEN) [2012-09-05 20:54:16] AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0a06, fault address = 0xc2c2c2c0, flags = 0x000
>>>> (XEN) [2012-09-05 20:54:16] AMD-Vi: IO_PAGE_FAULT: domain = 14, device id = 0x0700, fault address = 0xa8d339e0, flags = 0x020
>>>> (XEN) [2012-09-05 20:54:16] AMD-Vi: IO_PAGE_FAULT: domain = 14, device id = 0x0700, fault address = 0xa8d33a40, flags = 0x020
>>
>>> OK, so they are not interrupt requests. I guess further information from
>>> your system would be helpful to debug this issue:
>>> 1) xl info
>>> 2) xl list
>>> 3) lscpi -vvv (NOTE: not in dom0 but in your guest)
>>> 4) cat /proc/iomem (in both dom0 and your hvm guest)
>>
>> dom14 is not a HVM guest,it's a PV guest.

> Ah, I see. PV guest is quite different than hvm, it does use p2m tables 
> as io page tables. So no-sharept option does not work in this case. PV 
> guests always use separated io page tables. There might be some 
> incorrect mappings on the page tables. I will check this on my side.

I have reverted the machine to xen-4.1.4-pre (changeset 23353) and kept everything else the same.
I haven't seen any IO PAGE FAULTS after that.

I did spot some differences in the output from lspci between xen 4.1 and 4.2, related to MSI enabled or not for the IOMMU device.
Have attached the xl/xm dmesg and lspci from booting with both versions.

lspci:

00:00.2 Generic system peripheral [0806]: ATI Technologies Inc RD990 I/O Memory Management Unit (IOMMU) [1002:5a23]
        Subsystem: ATI Technologies Inc RD990 I/O Memory Management Unit (IOMMU) [1002:5a23]
        Control: I/O- Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
        Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
        Latency: 0
        Interrupt: pin A routed to IRQ 10
        Capabilities: [40] Secure device <?>
4.1:    Capabilities: [54] MSI: Enable- Count=1/1 Maskable- 64bit+
4.2:    Capabilities: [54] MSI: Enable+ Count=1/1 Maskable- 64bit+
                Address: 00000000fee0100c  Data: 4128
        Capabilities: [64] HyperTransport: MSI Mapping Enable+ Fixed+

Although it seems enabled, shouldn't the IRQ number used be much higher than 10 for MSI interrupts ?

There is another difference in the bridge device that's in front of the  0a:00.6 device that faults before the kernel is even booted.

00:03.0 PCI bridge [0604]: ATI Technologies Inc RD890 PCI to PCI bridge (PCI express gpp port C) [1002:5a17] (prog-if 00 [Normal decode])
        Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx+
4.1:    Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
4.2:    Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort+ <MAbort- >SERR- <PERR- INTx-
        Latency: 0, Cache Line Size: 64 bytes
        Bus: primary=00, secondary=0a, subordinate=0a, sec-latency=0
        I/O behind bridge: 0000f000-00000fff
        Memory behind bridge: f9f00000-f9ffffff
        Prefetchable memory behind bridge: 00000000fff00000-00000000000fffff
4.1:    Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- <SERR- <PERR-
4.2:    Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort+ <TAbort- <MAbort- <SERR- <PERR-
        BridgeCtl: Parity+ SERR+ NoISA+ VGA- MAbort- >Reset- FastB2B-
                PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
        Capabilities: [50] Power Management version 3
                Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
                Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
        Capabilities: [58] Express (v2) Root Port (Slot+), MSI 00
                DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s <64ns, L1 <1us
                        ExtTag+ RBE+ FLReset-
                DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
                        RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+
                        MaxPayload 128 bytes, MaxReadReq 128 bytes
                DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr- TransPend-
                LnkCap: Port #1, Speed 5GT/s, Width x8, ASPM L0s L1, Latency L0 <1us, L1 <8us
                        ClockPM- Surprise- LLActRep+ BwNot+
                LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommClk-
                        ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
                LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive+ BWMgmt+ ABWMgmt-
                SltCap: AttnBtn- PwrCtrl- MRL- AttnInd- PwrInd- HotPlug- Surprise-
                        Slot #3, PowerLimit 10.000W; Interlock- NoCompl+
                SltCtl: Enable: AttnBtn- PwrFlt- MRL- PresDet- CmdCplt- HPIrq- LinkChg-
                        Control: AttnInd Unknown, PwrInd Unknown, Power- Interlock-
                SltSta: Status: AttnBtn- PowerFlt- MRL- CmdCplt- PresDet+ Interlock-
                        Changed: MRL- PresDet+ LinkState+

serveerstertje:~# lspci -t
-[0000:00]-+-00.0
           +-00.2
           +-02.0-[0b]----00.0
           +-03.0-[0a]--+-00.0
           |            +-00.1
           |            +-00.2
           |            +-00.3
           |            +-00.4
           |            +-00.5
           |            +-00.6
           |            \-00.7
           +-05.0-[09]----00.0
           +-06.0-[08]----00.0
           +-0a.0-[07]----00.0
           +-0b.0-[06]--+-00.0
           |            \-00.1
           +-0c.0-[05]----00.0
           +-0d.0-[04]--+-00.0
           |            +-00.1
           |            +-00.2
           |            +-00.3
           |            +-00.4
           |            +-00.5
           |            +-00.6
           |            \-00.7
           +-11.0
           +-12.0
           +-12.2
           +-13.0
           +-13.2
           +-14.0
           +-14.3
           +-14.4-[03]----06.0
           +-14.5
           +-15.0-[02]--
           +-16.0
           +-16.2
           +-18.0
           +-18.1
           +-18.2
           +-18.3
           \-18.4





> Thanks,
> Wei

>> I will try to make a complete package, and try with one pv domain only where the devices are being passed through just to simplify the setup.
>>
>>
>>> * I would also like to know the symptoms of device 0x0700 when IO_PF
>>> happened. Did it stop working?
>>
>> Yes it stops working, the video capture just freezes, but the driver doesn't bail out.
>> For the USB controller (0x0a06) it starts to give errors for usbdev_open in the guest.
>>
>>> (BTW: I copied a few options from your boot cmd line and it worked with
>>> my RD890 system
>>
>>> dom0_mem=1024M,max:1024M loglvl=all loglvl_guest=all console_timestamps
>>> cpuidle cpufreq=xen noreboot debug lapic=debug apic_verbosity=debug
>>> apic=debug iommu=on,verbose,debug,no-sharept
>>
>>> * so, what OEM board you have?)
>>
>> MSI 890FXA-GD70
>>
>>> Also from your log, these lines looks very strange:
>>
>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>>> read-only memory page. gfn=0xd5, mfn=0xa4a11
>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>>> read-only memory page. gfn=0xd7, mfn=0xa4a0f
>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>>> read-only memory page. gfn=0xd9, mfn=0xa4a0d
>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>>> read-only memory page. gfn=0xdb, mfn=0xa4a0b
>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>>> read-only memory page. gfn=0xdd, mfn=0xa4a09
>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>>> read-only memory page. gfn=0xdf, mfn=0xa4a07
>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>>> read-only memory page. gfn=0xe1, mfn=0xa4a05
>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>>> read-only memory page. gfn=0xe3, mfn=0xa4a03
>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>>> read-only memory page. gfn=0xe5, mfn=0xa4a01
>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>>> read-only memory page. gfn=0xe7, mfn=0xa463f
>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>>> read-only memory page. gfn=0xe9, mfn=0xa463d
>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>>> read-only memory page. gfn=0xeb, mfn=0xa463b
>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>>> read-only memory page. gfn=0xed, mfn=0xa4639
>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>>> read-only memory page. gfn=0xef, mfn=0xa4637
>>> (XEN) [2012-09-04 16:13:56] AMD-Vi: IO_PAGE_FAULT: domain = 0, device id
>>> = 0x0a06, fault address = 0xc2c2c2c0
>>> (XEN) [2012-09-04 16:13:56] AMD-Vi: IO_PAGE_FAULT: domain = 14, device
>>> id = 0x0700, fault address = 0xa90f8300
>>> (XEN) [2012-09-04 16:13:56] AMD-Vi: IO_PAGE_FAULT: domain = 14, device
>>> id = 0x0700, fault address = 0xa90f8340
>>> (XEN) [2012-09-04 16:13:56] AMD-Vi: IO_PAGE_FAULT: domain = 14, device
>>> id = 0x0700, fault address = 0xa90f8380
>>> (XEN) [2012-09-04 16:13:56] AMD-Vi: IO_PAGE_FAULT: domain = 14, device
>>> id = 0x0700, fault address = 0xa90f83c0
>>
>>> * they are just followed by the IO PAGE fault. Do you know where are
>>> they from? Your video card driver maybe?
>>
>>  From a HVM domain with a old (3.0.3) kernel, but the faults also occur without this domain being started.
>>
>>
>>> Thanks,
>>> Wei
>>
>>
>>>> Complete xl dmesg and lspci -vvvknn attached.
>>>>
>>>> Thx
>>>>
>>>> --
>>>> Sander
>>
>>
>>
>>
>>



------------0E902503E1C6BF83E
Content-Type: text/plain;
 name="lspci-4.1.txt"
Content-transfer-encoding: base64
Content-Disposition: attachment;
 filename="lspci-4.1.txt"

MDA6MDAuMCBIb3N0IGJyaWRnZSBbMDYwMF06IEFUSSBUZWNobm9sb2dpZXMgSW5jIFJEODkw
IE5vcnRoYnJpZGdlIG9ubHkgc2luZ2xlIHNsb3QgUENJLWUgR0ZYIEh5ZHJhIHBhcnQgWzEw
MDI6NWExMV0gKHJldiAwMikNCglTdWJzeXN0ZW06IEFUSSBUZWNobm9sb2dpZXMgSW5jIFJE
ODkwIE5vcnRoYnJpZGdlIG9ubHkgc2luZ2xlIHNsb3QgUENJLWUgR0ZYIEh5ZHJhIHBhcnQg
WzEwMDI6NWExMV0NCglDb250cm9sOiBJL08tIE1lbSsgQnVzTWFzdGVyLSBTcGVjQ3ljbGUt
IE1lbVdJTlYtIFZHQVNub29wLSBQYXJFcnItIFN0ZXBwaW5nLSBTRVJSLSBGYXN0QjJCLSBE
aXNJTlR4LQ0KCVN0YXR1czogQ2FwKyA2Nk1Iei0gVURGLSBGYXN0QjJCLSBQYXJFcnItIERF
VlNFTD1mYXN0ID5UQWJvcnQtIDxUQWJvcnQtIDxNQWJvcnQrID5TRVJSLSA8UEVSUi0gSU5U
eC0NCglDYXBhYmlsaXRpZXM6IFtmMF0gSHlwZXJUcmFuc3BvcnQ6IE1TSSBNYXBwaW5nIEVu
YWJsZSsgRml4ZWQrDQoJQ2FwYWJpbGl0aWVzOiBbYzRdIEh5cGVyVHJhbnNwb3J0OiBTbGF2
ZSBvciBQcmltYXJ5IEludGVyZmFjZQ0KCQlDb21tYW5kOiBCYXNlVW5pdElEPTAgVW5pdENu
dD0yMCBNYXN0SG9zdC0gRGVmRGlyLSBEVUwtDQoJCUxpbmsgQ29udHJvbCAwOiBDRmxFLSBD
U1QtIENGRS0gPExrRmFpbC0gSW5pdCsgRU9DLSBUWE8tIDxDUkNFcnI9MCBJc29jRW4tIExT
RW4tIEV4dENUTC0gNjRiLQ0KCQlMaW5rIENvbmZpZyAwOiBNTFdJPTE2Yml0IER3RmNJbi0g
TUxXTz0xNmJpdCBEd0ZjT3V0LSBMV0k9MTZiaXQgRHdGY0luRW4tIExXTz0xNmJpdCBEd0Zj
T3V0RW4tDQoJCUxpbmsgQ29udHJvbCAxOiBDRmxFLSBDU1QtIENGRS0gPExrRmFpbCsgSW5p
dC0gRU9DKyBUWE8rIDxDUkNFcnI9MCBJc29jRW4tIExTRW4tIEV4dENUTC0gNjRiLQ0KCQlM
aW5rIENvbmZpZyAxOiBNTFdJPThiaXQgRHdGY0luLSBNTFdPPThiaXQgRHdGY091dC0gTFdJ
PThiaXQgRHdGY0luRW4tIExXTz04Yml0IER3RmNPdXRFbi0NCgkJUmV2aXNpb24gSUQ6IDMu
MDANCgkJTGluayBGcmVxdWVuY3kgMDogW2JdDQoJCUxpbmsgRXJyb3IgMDogPFByb3QtIDxP
dmZsLSA8RU9DLSBDVExUbS0NCgkJTGluayBGcmVxdWVuY3kgQ2FwYWJpbGl0eSAwOiAyMDBN
SHorIDMwME1Iei0gNDAwTUh6KyA1MDBNSHotIDYwME1IeisgODAwTUh6KyAxLjBHSHorIDEu
MkdIeisgMS40R0h6LSAxLjZHSHotIFZlbmQtDQoJCUZlYXR1cmUgQ2FwYWJpbGl0eTogSXNv
Y0ZDKyBMRFRTVE9QKyBDUkNUTS0gRUNUTFQtIDY0YkErIFVJRFJELQ0KCQlMaW5rIEZyZXF1
ZW5jeSAxOiAyMDBNSHoNCgkJTGluayBFcnJvciAxOiA8UHJvdC0gPE92ZmwtIDxFT0MtIENU
TFRtLQ0KCQlMaW5rIEZyZXF1ZW5jeSBDYXBhYmlsaXR5IDE6IDIwME1Iei0gMzAwTUh6LSA0
MDBNSHotIDUwME1Iei0gNjAwTUh6LSA4MDBNSHotIDEuMEdIei0gMS4yR0h6LSAxLjRHSHot
IDEuNkdIei0gVmVuZC0NCgkJRXJyb3IgSGFuZGxpbmc6IFBGbEUtIE9GbEUtIFBGRS0gT0ZF
LSBFT0NGRS0gUkZFLSBDUkNGRS0gU0VSUkZFLSBDRi0gUkUtIFBORkUtIE9ORkUtIEVPQ05G
RS0gUk5GRS0gQ1JDTkZFLSBTRVJSTkZFLQ0KCQlQcmVmZXRjaGFibGUgbWVtb3J5IGJlaGlu
ZCBicmlkZ2UgVXBwZXI6IDAwLTAwDQoJCUJ1cyBOdW1iZXI6IDAwDQoJQ2FwYWJpbGl0aWVz
OiBbNDBdIEh5cGVyVHJhbnNwb3J0OiBSZXRyeSBNb2RlDQoJQ2FwYWJpbGl0aWVzOiBbNTRd
IEh5cGVyVHJhbnNwb3J0OiBVbml0SUQgQ2x1bXBpbmcNCglDYXBhYmlsaXRpZXM6IFs5Y10g
SHlwZXJUcmFuc3BvcnQ6ICMxYQ0KCUNhcGFiaWxpdGllczogWzcwXSBNU0k6IEVuYWJsZS0g
Q291bnQ9MS80IE1hc2thYmxlLSA2NGJpdC0NCgkJQWRkcmVzczogMDAwMDAwMDAgIERhdGE6
IDAwMDANCg0KMDA6MDAuMiBHZW5lcmljIHN5c3RlbSBwZXJpcGhlcmFsIFswODA2XTogQVRJ
IFRlY2hub2xvZ2llcyBJbmMgUkQ5OTAgSS9PIE1lbW9yeSBNYW5hZ2VtZW50IFVuaXQgKElP
TU1VKSBbMTAwMjo1YTIzXQ0KCVN1YnN5c3RlbTogQVRJIFRlY2hub2xvZ2llcyBJbmMgUkQ5
OTAgSS9PIE1lbW9yeSBNYW5hZ2VtZW50IFVuaXQgKElPTU1VKSBbMTAwMjo1YTIzXQ0KCUNv
bnRyb2w6IEkvTy0gTWVtLSBCdXNNYXN0ZXIrIFNwZWNDeWNsZS0gTWVtV0lOVi0gVkdBU25v
b3AtIFBhckVyci0gU3RlcHBpbmctIFNFUlItIEZhc3RCMkItIERpc0lOVHgtDQoJU3RhdHVz
OiBDYXArIDY2TUh6LSBVREYtIEZhc3RCMkItIFBhckVyci0gREVWU0VMPWZhc3QgPlRBYm9y
dC0gPFRBYm9ydC0gPE1BYm9ydC0gPlNFUlItIDxQRVJSLSBJTlR4LQ0KCUxhdGVuY3k6IDAN
CglJbnRlcnJ1cHQ6IHBpbiBBIHJvdXRlZCB0byBJUlEgMTANCglDYXBhYmlsaXRpZXM6IFs0
MF0gU2VjdXJlIGRldmljZSA8Pz4NCglDYXBhYmlsaXRpZXM6IFs1NF0gTVNJOiBFbmFibGUt
IENvdW50PTEvMSBNYXNrYWJsZS0gNjRiaXQrDQoJCUFkZHJlc3M6IDAwMDAwMDAwZmVlMDEw
MGMgIERhdGE6IDQxMjgNCglDYXBhYmlsaXRpZXM6IFs2NF0gSHlwZXJUcmFuc3BvcnQ6IE1T
SSBNYXBwaW5nIEVuYWJsZSsgRml4ZWQrDQoNCjAwOjAyLjAgUENJIGJyaWRnZSBbMDYwNF06
IEFUSSBUZWNobm9sb2dpZXMgSW5jIFJEODkwIFBDSSB0byBQQ0kgYnJpZGdlIChQQ0kgZXhw
cmVzcyBncHAgcG9ydCBCKSBbMTAwMjo1YTE2XSAocHJvZy1pZiAwMCBbTm9ybWFsIGRlY29k
ZV0pDQoJQ29udHJvbDogSS9PKyBNZW0rIEJ1c01hc3RlcisgU3BlY0N5Y2xlLSBNZW1XSU5W
LSBWR0FTbm9vcC0gUGFyRXJyLSBTdGVwcGluZy0gU0VSUisgRmFzdEIyQi0gRGlzSU5UeCsN
CglTdGF0dXM6IENhcCsgNjZNSHotIFVERi0gRmFzdEIyQi0gUGFyRXJyLSBERVZTRUw9ZmFz
dCA+VEFib3J0LSA8VEFib3J0LSA8TUFib3J0LSA+U0VSUi0gPFBFUlItIElOVHgtDQoJTGF0
ZW5jeTogMCwgQ2FjaGUgTGluZSBTaXplOiA2NCBieXRlcw0KCUJ1czogcHJpbWFyeT0wMCwg
c2Vjb25kYXJ5PTBiLCBzdWJvcmRpbmF0ZT0wYiwgc2VjLWxhdGVuY3k9MA0KCUkvTyBiZWhp
bmQgYnJpZGdlOiAwMDAwZTAwMC0wMDAwZWZmZg0KCU1lbW9yeSBiZWhpbmQgYnJpZGdlOiBm
YTAwMDAwMC1mZTlmZmZmZg0KCVByZWZldGNoYWJsZSBtZW1vcnkgYmVoaW5kIGJyaWRnZTog
MDAwMDAwMDBkMDAwMDAwMC0wMDAwMDAwMGRmZmZmZmZmDQoJU2Vjb25kYXJ5IHN0YXR1czog
NjZNSHotIEZhc3RCMkItIFBhckVyci0gREVWU0VMPWZhc3QgPlRBYm9ydC0gPFRBYm9ydC0g
PE1BYm9ydC0gPFNFUlItIDxQRVJSLQ0KCUJyaWRnZUN0bDogUGFyaXR5KyBTRVJSKyBOb0lT
QS0gVkdBKyBNQWJvcnQtID5SZXNldC0gRmFzdEIyQi0NCgkJUHJpRGlzY1Rtci0gU2VjRGlz
Y1Rtci0gRGlzY1RtclN0YXQtIERpc2NUbXJTRVJSRW4tDQoJQ2FwYWJpbGl0aWVzOiBbNTBd
IFBvd2VyIE1hbmFnZW1lbnQgdmVyc2lvbiAzDQoJCUZsYWdzOiBQTUVDbGstIERTSS0gRDEt
IEQyLSBBdXhDdXJyZW50PTBtQSBQTUUoRDArLEQxLSxEMi0sRDNob3QrLEQzY29sZCspDQoJ
CVN0YXR1czogRDAgTm9Tb2Z0UnN0LSBQTUUtRW5hYmxlLSBEU2VsPTAgRFNjYWxlPTAgUE1F
LQ0KCUNhcGFiaWxpdGllczogWzU4XSBFeHByZXNzICh2MikgUm9vdCBQb3J0IChTbG90Kyks
IE1TSSAwMA0KCQlEZXZDYXA6CU1heFBheWxvYWQgMTI4IGJ5dGVzLCBQaGFudEZ1bmMgMCwg
TGF0ZW5jeSBMMHMgPDY0bnMsIEwxIDwxdXMNCgkJCUV4dFRhZysgUkJFKyBGTFJlc2V0LQ0K
CQlEZXZDdGw6CVJlcG9ydCBlcnJvcnM6IENvcnJlY3RhYmxlLSBOb24tRmF0YWwtIEZhdGFs
LSBVbnN1cHBvcnRlZC0NCgkJCVJseGRPcmQrIEV4dFRhZy0gUGhhbnRGdW5jLSBBdXhQd3It
IE5vU25vb3ArDQoJCQlNYXhQYXlsb2FkIDEyOCBieXRlcywgTWF4UmVhZFJlcSAxMjggYnl0
ZXMNCgkJRGV2U3RhOglDb3JyRXJyLSBVbmNvcnJFcnItIEZhdGFsRXJyLSBVbnN1cHBSZXEt
IEF1eFB3ci0gVHJhbnNQZW5kLQ0KCQlMbmtDYXA6CVBvcnQgIzAsIFNwZWVkIDVHVC9zLCBX
aWR0aCB4OCwgQVNQTSBMMHMgTDEsIExhdGVuY3kgTDAgPDF1cywgTDEgPDh1cw0KCQkJQ2xv
Y2tQTS0gU3VycHJpc2UtIExMQWN0UmVwKyBCd05vdCsNCgkJTG5rQ3RsOglBU1BNIERpc2Fi
bGVkOyBSQ0IgNjQgYnl0ZXMgRGlzYWJsZWQtIFJldHJhaW4tIENvbW1DbGsrDQoJCQlFeHRT
eW5jaC0gQ2xvY2tQTS0gQXV0V2lkRGlzLSBCV0ludC0gQXV0QldJbnQtDQoJCUxua1N0YToJ
U3BlZWQgMi41R1QvcywgV2lkdGggeDgsIFRyRXJyLSBUcmFpbi0gU2xvdENsaysgRExBY3Rp
dmUrIEJXTWdtdCsgQUJXTWdtdC0NCgkJU2x0Q2FwOglBdHRuQnRuLSBQd3JDdHJsLSBNUkwt
IEF0dG5JbmQtIFB3ckluZC0gSG90UGx1Zy0gU3VycHJpc2UtDQoJCQlTbG90ICMxLCBQb3dl
ckxpbWl0IDI1LjAwMFc7IEludGVybG9jay0gTm9Db21wbCsNCgkJU2x0Q3RsOglFbmFibGU6
IEF0dG5CdG4tIFB3ckZsdC0gTVJMLSBQcmVzRGV0LSBDbWRDcGx0LSBIUElycS0gTGlua0No
Zy0NCgkJCUNvbnRyb2w6IEF0dG5JbmQgVW5rbm93biwgUHdySW5kIFVua25vd24sIFBvd2Vy
LSBJbnRlcmxvY2stDQoJCVNsdFN0YToJU3RhdHVzOiBBdHRuQnRuLSBQb3dlckZsdC0gTVJM
LSBDbWRDcGx0LSBQcmVzRGV0KyBJbnRlcmxvY2stDQoJCQlDaGFuZ2VkOiBNUkwtIFByZXNE
ZXQrIExpbmtTdGF0ZSsNCgkJUm9vdEN0bDogRXJyQ29ycmVjdGFibGUtIEVyck5vbi1GYXRh
bC0gRXJyRmF0YWwtIFBNRUludEVuYS0gQ1JTVmlzaWJsZS0NCgkJUm9vdENhcDogQ1JTVmlz
aWJsZS0NCgkJUm9vdFN0YTogUE1FIFJlcUlEIDAwMDAsIFBNRVN0YXR1cy0gUE1FUGVuZGlu
Zy0NCgkJRGV2Q2FwMjogQ29tcGxldGlvbiBUaW1lb3V0OiBSYW5nZSBBQkNELCBUaW1lb3V0
RGlzKyBBUklGd2QrDQoJCURldkN0bDI6IENvbXBsZXRpb24gVGltZW91dDogNjVtcyB0byAy
MTBtcywgVGltZW91dERpcy0gQVJJRndkLQ0KCQlMbmtDdGwyOiBUYXJnZXQgTGluayBTcGVl
ZDogNUdUL3MsIEVudGVyQ29tcGxpYW5jZS0gU3BlZWREaXMtLCBTZWxlY3RhYmxlIERlLWVt
cGhhc2lzOiAtMy41ZEINCgkJCSBUcmFuc21pdCBNYXJnaW46IE5vcm1hbCBPcGVyYXRpbmcg
UmFuZ2UsIEVudGVyTW9kaWZpZWRDb21wbGlhbmNlLSBDb21wbGlhbmNlU09TLQ0KCQkJIENv
bXBsaWFuY2UgRGUtZW1waGFzaXM6IC02ZEINCgkJTG5rU3RhMjogQ3VycmVudCBEZS1lbXBo
YXNpcyBMZXZlbDogLTMuNWRCDQoJQ2FwYWJpbGl0aWVzOiBbYTBdIE1TSTogRW5hYmxlKyBD
b3VudD0xLzEgTWFza2FibGUtIDY0Yml0LQ0KCQlBZGRyZXNzOiBmZWUzZjAwYyAgRGF0YTog
NDE1MQ0KCUNhcGFiaWxpdGllczogW2IwXSBTdWJzeXN0ZW06IEFUSSBUZWNobm9sb2dpZXMg
SW5jIERldmljZSBbMTAwMjo1YTExXQ0KCUNhcGFiaWxpdGllczogW2I4XSBIeXBlclRyYW5z
cG9ydDogTVNJIE1hcHBpbmcgRW5hYmxlKyBGaXhlZCsNCglDYXBhYmlsaXRpZXM6IFsxMDAg
djFdIFZlbmRvciBTcGVjaWZpYyBJbmZvcm1hdGlvbjogSUQ9MDAwMSBSZXY9MSBMZW49MDEw
IDw/Pg0KCUNhcGFiaWxpdGllczogWzE5MCB2MV0gQWNjZXNzIENvbnRyb2wgU2VydmljZXMN
CgkJQUNTQ2FwOglTcmNWYWxpZCsgVHJhbnNCbGsrIFJlcVJlZGlyKyBDbXBsdFJlZGlyKyBV
cHN0cmVhbUZ3ZCsgRWdyZXNzQ3RybC0gRGlyZWN0VHJhbnMrDQoJCUFDU0N0bDoJU3JjVmFs
aWQrIFRyYW5zQmxrLSBSZXFSZWRpcisgQ21wbHRSZWRpcisgVXBzdHJlYW1Gd2QrIEVncmVz
c0N0cmwtIERpcmVjdFRyYW5zLQ0KCUtlcm5lbCBkcml2ZXIgaW4gdXNlOiBwY2llcG9ydA0K
DQowMDowMy4wIFBDSSBicmlkZ2UgWzA2MDRdOiBBVEkgVGVjaG5vbG9naWVzIEluYyBSRDg5
MCBQQ0kgdG8gUENJIGJyaWRnZSAoUENJIGV4cHJlc3MgZ3BwIHBvcnQgQykgWzEwMDI6NWEx
N10gKHByb2ctaWYgMDAgW05vcm1hbCBkZWNvZGVdKQ0KCUNvbnRyb2w6IEkvTy0gTWVtKyBC
dXNNYXN0ZXIrIFNwZWNDeWNsZS0gTWVtV0lOVi0gVkdBU25vb3AtIFBhckVyci0gU3RlcHBp
bmctIFNFUlIrIEZhc3RCMkItIERpc0lOVHgrDQoJU3RhdHVzOiBDYXArIDY2TUh6LSBVREYt
IEZhc3RCMkItIFBhckVyci0gREVWU0VMPWZhc3QgPlRBYm9ydC0gPFRBYm9ydC0gPE1BYm9y
dC0gPlNFUlItIDxQRVJSLSBJTlR4LQ0KCUxhdGVuY3k6IDAsIENhY2hlIExpbmUgU2l6ZTog
NjQgYnl0ZXMNCglCdXM6IHByaW1hcnk9MDAsIHNlY29uZGFyeT0wYSwgc3Vib3JkaW5hdGU9
MGEsIHNlYy1sYXRlbmN5PTANCglJL08gYmVoaW5kIGJyaWRnZTogMDAwMGYwMDAtMDAwMDBm
ZmYNCglNZW1vcnkgYmVoaW5kIGJyaWRnZTogZjlmMDAwMDAtZjlmZmZmZmYNCglQcmVmZXRj
aGFibGUgbWVtb3J5IGJlaGluZCBicmlkZ2U6IDAwMDAwMDAwZmZmMDAwMDAtMDAwMDAwMDAw
MDBmZmZmZg0KCVNlY29uZGFyeSBzdGF0dXM6IDY2TUh6LSBGYXN0QjJCLSBQYXJFcnItIERF
VlNFTD1mYXN0ID5UQWJvcnQtIDxUQWJvcnQtIDxNQWJvcnQtIDxTRVJSLSA8UEVSUi0NCglC
cmlkZ2VDdGw6IFBhcml0eSsgU0VSUisgTm9JU0ErIFZHQS0gTUFib3J0LSA+UmVzZXQtIEZh
c3RCMkItDQoJCVByaURpc2NUbXItIFNlY0Rpc2NUbXItIERpc2NUbXJTdGF0LSBEaXNjVG1y
U0VSUkVuLQ0KCUNhcGFiaWxpdGllczogWzUwXSBQb3dlciBNYW5hZ2VtZW50IHZlcnNpb24g
Mw0KCQlGbGFnczogUE1FQ2xrLSBEU0ktIEQxLSBEMi0gQXV4Q3VycmVudD0wbUEgUE1FKEQw
KyxEMS0sRDItLEQzaG90KyxEM2NvbGQrKQ0KCQlTdGF0dXM6IEQwIE5vU29mdFJzdC0gUE1F
LUVuYWJsZS0gRFNlbD0wIERTY2FsZT0wIFBNRS0NCglDYXBhYmlsaXRpZXM6IFs1OF0gRXhw
cmVzcyAodjIpIFJvb3QgUG9ydCAoU2xvdCspLCBNU0kgMDANCgkJRGV2Q2FwOglNYXhQYXls
b2FkIDEyOCBieXRlcywgUGhhbnRGdW5jIDAsIExhdGVuY3kgTDBzIDw2NG5zLCBMMSA8MXVz
DQoJCQlFeHRUYWcrIFJCRSsgRkxSZXNldC0NCgkJRGV2Q3RsOglSZXBvcnQgZXJyb3JzOiBD
b3JyZWN0YWJsZS0gTm9uLUZhdGFsLSBGYXRhbC0gVW5zdXBwb3J0ZWQtDQoJCQlSbHhkT3Jk
KyBFeHRUYWctIFBoYW50RnVuYy0gQXV4UHdyLSBOb1Nub29wKw0KCQkJTWF4UGF5bG9hZCAx
MjggYnl0ZXMsIE1heFJlYWRSZXEgMTI4IGJ5dGVzDQoJCURldlN0YToJQ29yckVyci0gVW5j
b3JyRXJyLSBGYXRhbEVyci0gVW5zdXBwUmVxLSBBdXhQd3ItIFRyYW5zUGVuZC0NCgkJTG5r
Q2FwOglQb3J0ICMxLCBTcGVlZCA1R1QvcywgV2lkdGggeDgsIEFTUE0gTDBzIEwxLCBMYXRl
bmN5IEwwIDwxdXMsIEwxIDw4dXMNCgkJCUNsb2NrUE0tIFN1cnByaXNlLSBMTEFjdFJlcCsg
QndOb3QrDQoJCUxua0N0bDoJQVNQTSBEaXNhYmxlZDsgUkNCIDY0IGJ5dGVzIERpc2FibGVk
LSBSZXRyYWluLSBDb21tQ2xrLQ0KCQkJRXh0U3luY2gtIENsb2NrUE0tIEF1dFdpZERpcy0g
QldJbnQtIEF1dEJXSW50LQ0KCQlMbmtTdGE6CVNwZWVkIDIuNUdUL3MsIFdpZHRoIHgxLCBU
ckVyci0gVHJhaW4tIFNsb3RDbGsrIERMQWN0aXZlKyBCV01nbXQrIEFCV01nbXQtDQoJCVNs
dENhcDoJQXR0bkJ0bi0gUHdyQ3RybC0gTVJMLSBBdHRuSW5kLSBQd3JJbmQtIEhvdFBsdWct
IFN1cnByaXNlLQ0KCQkJU2xvdCAjMywgUG93ZXJMaW1pdCAxMC4wMDBXOyBJbnRlcmxvY2st
IE5vQ29tcGwrDQoJCVNsdEN0bDoJRW5hYmxlOiBBdHRuQnRuLSBQd3JGbHQtIE1STC0gUHJl
c0RldC0gQ21kQ3BsdC0gSFBJcnEtIExpbmtDaGctDQoJCQlDb250cm9sOiBBdHRuSW5kIFVu
a25vd24sIFB3ckluZCBVbmtub3duLCBQb3dlci0gSW50ZXJsb2NrLQ0KCQlTbHRTdGE6CVN0
YXR1czogQXR0bkJ0bi0gUG93ZXJGbHQtIE1STC0gQ21kQ3BsdC0gUHJlc0RldCsgSW50ZXJs
b2NrLQ0KCQkJQ2hhbmdlZDogTVJMLSBQcmVzRGV0KyBMaW5rU3RhdGUrDQoJCVJvb3RDdGw6
IEVyckNvcnJlY3RhYmxlLSBFcnJOb24tRmF0YWwtIEVyckZhdGFsLSBQTUVJbnRFbmEtIENS
U1Zpc2libGUtDQoJCVJvb3RDYXA6IENSU1Zpc2libGUtDQoJCVJvb3RTdGE6IFBNRSBSZXFJ
RCAwMDAwLCBQTUVTdGF0dXMtIFBNRVBlbmRpbmctDQoJCURldkNhcDI6IENvbXBsZXRpb24g
VGltZW91dDogUmFuZ2UgQUJDRCwgVGltZW91dERpcysgQVJJRndkKw0KCQlEZXZDdGwyOiBD
b21wbGV0aW9uIFRpbWVvdXQ6IDY1bXMgdG8gMjEwbXMsIFRpbWVvdXREaXMtIEFSSUZ3ZC0N
CgkJTG5rQ3RsMjogVGFyZ2V0IExpbmsgU3BlZWQ6IDVHVC9zLCBFbnRlckNvbXBsaWFuY2Ut
IFNwZWVkRGlzLSwgU2VsZWN0YWJsZSBEZS1lbXBoYXNpczogLTMuNWRCDQoJCQkgVHJhbnNt
aXQgTWFyZ2luOiBOb3JtYWwgT3BlcmF0aW5nIFJhbmdlLCBFbnRlck1vZGlmaWVkQ29tcGxp
YW5jZS0gQ29tcGxpYW5jZVNPUy0NCgkJCSBDb21wbGlhbmNlIERlLWVtcGhhc2lzOiAtNmRC
DQoJCUxua1N0YTI6IEN1cnJlbnQgRGUtZW1waGFzaXMgTGV2ZWw6IC0zLjVkQg0KCUNhcGFi
aWxpdGllczogW2EwXSBNU0k6IEVuYWJsZSsgQ291bnQ9MS8xIE1hc2thYmxlLSA2NGJpdC0N
CgkJQWRkcmVzczogZmVlM2YwMGMgIERhdGE6IDQxNTkNCglDYXBhYmlsaXRpZXM6IFtiMF0g
U3Vic3lzdGVtOiBBVEkgVGVjaG5vbG9naWVzIEluYyBEZXZpY2UgWzEwMDI6NWExMV0NCglD
YXBhYmlsaXRpZXM6IFtiOF0gSHlwZXJUcmFuc3BvcnQ6IE1TSSBNYXBwaW5nIEVuYWJsZSsg
Rml4ZWQrDQoJQ2FwYWJpbGl0aWVzOiBbMTAwIHYxXSBWZW5kb3IgU3BlY2lmaWMgSW5mb3Jt
YXRpb246IElEPTAwMDEgUmV2PTEgTGVuPTAxMCA8Pz4NCglDYXBhYmlsaXRpZXM6IFsxOTAg
djFdIEFjY2VzcyBDb250cm9sIFNlcnZpY2VzDQoJCUFDU0NhcDoJU3JjVmFsaWQrIFRyYW5z
QmxrKyBSZXFSZWRpcisgQ21wbHRSZWRpcisgVXBzdHJlYW1Gd2QrIEVncmVzc0N0cmwtIERp
cmVjdFRyYW5zKw0KCQlBQ1NDdGw6CVNyY1ZhbGlkKyBUcmFuc0Jsay0gUmVxUmVkaXIrIENt
cGx0UmVkaXIrIFVwc3RyZWFtRndkKyBFZ3Jlc3NDdHJsLSBEaXJlY3RUcmFucy0NCglLZXJu
ZWwgZHJpdmVyIGluIHVzZTogcGNpZXBvcnQNCg0KMDA6MDUuMCBQQ0kgYnJpZGdlIFswNjA0
XTogQVRJIFRlY2hub2xvZ2llcyBJbmMgUkQ4OTAgUENJIHRvIFBDSSBicmlkZ2UgKFBDSSBl
eHByZXNzIGdwcCBwb3J0IEUpIFsxMDAyOjVhMTldIChwcm9nLWlmIDAwIFtOb3JtYWwgZGVj
b2RlXSkNCglDb250cm9sOiBJL08rIE1lbSsgQnVzTWFzdGVyKyBTcGVjQ3ljbGUtIE1lbVdJ
TlYtIFZHQVNub29wLSBQYXJFcnItIFN0ZXBwaW5nLSBTRVJSKyBGYXN0QjJCLSBEaXNJTlR4
Kw0KCVN0YXR1czogQ2FwKyA2Nk1Iei0gVURGLSBGYXN0QjJCLSBQYXJFcnItIERFVlNFTD1m
YXN0ID5UQWJvcnQtIDxUQWJvcnQtIDxNQWJvcnQtID5TRVJSLSA8UEVSUi0gSU5UeC0NCglM
YXRlbmN5OiAwLCBDYWNoZSBMaW5lIFNpemU6IDY0IGJ5dGVzDQoJQnVzOiBwcmltYXJ5PTAw
LCBzZWNvbmRhcnk9MDksIHN1Ym9yZGluYXRlPTA5LCBzZWMtbGF0ZW5jeT0wDQoJSS9PIGJl
aGluZCBicmlkZ2U6IDAwMDBkMDAwLTAwMDBkZmZmDQoJTWVtb3J5IGJlaGluZCBicmlkZ2U6
IGY5ZTAwMDAwLWY5ZWZmZmZmDQoJUHJlZmV0Y2hhYmxlIG1lbW9yeSBiZWhpbmQgYnJpZGdl
OiAwMDAwMDAwMGNmZjAwMDAwLTAwMDAwMDAwY2ZmZmZmZmYNCglTZWNvbmRhcnkgc3RhdHVz
OiA2Nk1Iei0gRmFzdEIyQi0gUGFyRXJyLSBERVZTRUw9ZmFzdCA+VEFib3J0LSA8VEFib3J0
LSA8TUFib3J0LSA8U0VSUi0gPFBFUlItDQoJQnJpZGdlQ3RsOiBQYXJpdHkrIFNFUlIrIE5v
SVNBKyBWR0EtIE1BYm9ydC0gPlJlc2V0LSBGYXN0QjJCLQ0KCQlQcmlEaXNjVG1yLSBTZWNE
aXNjVG1yLSBEaXNjVG1yU3RhdC0gRGlzY1RtclNFUlJFbi0NCglDYXBhYmlsaXRpZXM6IFs1
MF0gUG93ZXIgTWFuYWdlbWVudCB2ZXJzaW9uIDMNCgkJRmxhZ3M6IFBNRUNsay0gRFNJLSBE
MS0gRDItIEF1eEN1cnJlbnQ9MG1BIFBNRShEMCssRDEtLEQyLSxEM2hvdCssRDNjb2xkKykN
CgkJU3RhdHVzOiBEMCBOb1NvZnRSc3QtIFBNRS1FbmFibGUtIERTZWw9MCBEU2NhbGU9MCBQ
TUUtDQoJQ2FwYWJpbGl0aWVzOiBbNThdIEV4cHJlc3MgKHYyKSBSb290IFBvcnQgKFNsb3Qr
KSwgTVNJIDAwDQoJCURldkNhcDoJTWF4UGF5bG9hZCAxMjggYnl0ZXMsIFBoYW50RnVuYyAw
LCBMYXRlbmN5IEwwcyA8NjRucywgTDEgPDF1cw0KCQkJRXh0VGFnKyBSQkUrIEZMUmVzZXQt
DQoJCURldkN0bDoJUmVwb3J0IGVycm9yczogQ29ycmVjdGFibGUtIE5vbi1GYXRhbC0gRmF0
YWwtIFVuc3VwcG9ydGVkLQ0KCQkJUmx4ZE9yZCsgRXh0VGFnLSBQaGFudEZ1bmMtIEF1eFB3
ci0gTm9Tbm9vcCsNCgkJCU1heFBheWxvYWQgMTI4IGJ5dGVzLCBNYXhSZWFkUmVxIDEyOCBi
eXRlcw0KCQlEZXZTdGE6CUNvcnJFcnItIFVuY29yckVyci0gRmF0YWxFcnItIFVuc3VwcFJl
cS0gQXV4UHdyLSBUcmFuc1BlbmQtDQoJCUxua0NhcDoJUG9ydCAjMSwgU3BlZWQgNUdUL3Ms
IFdpZHRoIHgxLCBBU1BNIEwwcyBMMSwgTGF0ZW5jeSBMMCA8MXVzLCBMMSA8OHVzDQoJCQlD
bG9ja1BNLSBTdXJwcmlzZS0gTExBY3RSZXArIEJ3Tm90Kw0KCQlMbmtDdGw6CUFTUE0gRGlz
YWJsZWQ7IFJDQiA2NCBieXRlcyBEaXNhYmxlZC0gUmV0cmFpbi0gQ29tbUNsaysNCgkJCUV4
dFN5bmNoLSBDbG9ja1BNLSBBdXRXaWREaXMtIEJXSW50LSBBdXRCV0ludC0NCgkJTG5rU3Rh
OglTcGVlZCAyLjVHVC9zLCBXaWR0aCB4MSwgVHJFcnItIFRyYWluLSBTbG90Q2xrKyBETEFj
dGl2ZSsgQldNZ210KyBBQldNZ210LQ0KCQlTbHRDYXA6CUF0dG5CdG4tIFB3ckN0cmwtIE1S
TC0gQXR0bkluZC0gUHdySW5kLSBIb3RQbHVnLSBTdXJwcmlzZS0NCgkJCVNsb3QgIzUsIFBv
d2VyTGltaXQgNzUuMDAwVzsgSW50ZXJsb2NrLSBOb0NvbXBsKw0KCQlTbHRDdGw6CUVuYWJs
ZTogQXR0bkJ0bi0gUHdyRmx0LSBNUkwtIFByZXNEZXQtIENtZENwbHQtIEhQSXJxLSBMaW5r
Q2hnLQ0KCQkJQ29udHJvbDogQXR0bkluZCBVbmtub3duLCBQd3JJbmQgVW5rbm93biwgUG93
ZXItIEludGVybG9jay0NCgkJU2x0U3RhOglTdGF0dXM6IEF0dG5CdG4tIFBvd2VyRmx0LSBN
UkwtIENtZENwbHQtIFByZXNEZXQrIEludGVybG9jay0NCgkJCUNoYW5nZWQ6IE1STC0gUHJl
c0RldCsgTGlua1N0YXRlKw0KCQlSb290Q3RsOiBFcnJDb3JyZWN0YWJsZS0gRXJyTm9uLUZh
dGFsLSBFcnJGYXRhbC0gUE1FSW50RW5hLSBDUlNWaXNpYmxlLQ0KCQlSb290Q2FwOiBDUlNW
aXNpYmxlLQ0KCQlSb290U3RhOiBQTUUgUmVxSUQgMDAwMCwgUE1FU3RhdHVzLSBQTUVQZW5k
aW5nLQ0KCQlEZXZDYXAyOiBDb21wbGV0aW9uIFRpbWVvdXQ6IFJhbmdlIEFCQ0QsIFRpbWVv
dXREaXMrIEFSSUZ3ZCsNCgkJRGV2Q3RsMjogQ29tcGxldGlvbiBUaW1lb3V0OiA2NW1zIHRv
IDIxMG1zLCBUaW1lb3V0RGlzLSBBUklGd2QtDQoJCUxua0N0bDI6IFRhcmdldCBMaW5rIFNw
ZWVkOiA1R1QvcywgRW50ZXJDb21wbGlhbmNlLSBTcGVlZERpcy0sIFNlbGVjdGFibGUgRGUt
ZW1waGFzaXM6IC0zLjVkQg0KCQkJIFRyYW5zbWl0IE1hcmdpbjogTm9ybWFsIE9wZXJhdGlu
ZyBSYW5nZSwgRW50ZXJNb2RpZmllZENvbXBsaWFuY2UtIENvbXBsaWFuY2VTT1MtDQoJCQkg
Q29tcGxpYW5jZSBEZS1lbXBoYXNpczogLTZkQg0KCQlMbmtTdGEyOiBDdXJyZW50IERlLWVt
cGhhc2lzIExldmVsOiAtMy41ZEINCglDYXBhYmlsaXRpZXM6IFthMF0gTVNJOiBFbmFibGUr
IENvdW50PTEvMSBNYXNrYWJsZS0gNjRiaXQtDQoJCUFkZHJlc3M6IGZlZTNmMDBjICBEYXRh
OiA0MTYxDQoJQ2FwYWJpbGl0aWVzOiBbYjBdIFN1YnN5c3RlbTogQVRJIFRlY2hub2xvZ2ll
cyBJbmMgRGV2aWNlIFsxMDAyOjVhMTFdDQoJQ2FwYWJpbGl0aWVzOiBbYjhdIEh5cGVyVHJh
bnNwb3J0OiBNU0kgTWFwcGluZyBFbmFibGUrIEZpeGVkKw0KCUNhcGFiaWxpdGllczogWzEw
MCB2MV0gVmVuZG9yIFNwZWNpZmljIEluZm9ybWF0aW9uOiBJRD0wMDAxIFJldj0xIExlbj0w
MTAgPD8+DQoJQ2FwYWJpbGl0aWVzOiBbMTkwIHYxXSBBY2Nlc3MgQ29udHJvbCBTZXJ2aWNl
cw0KCQlBQ1NDYXA6CVNyY1ZhbGlkKyBUcmFuc0JsaysgUmVxUmVkaXIrIENtcGx0UmVkaXIr
IFVwc3RyZWFtRndkKyBFZ3Jlc3NDdHJsLSBEaXJlY3RUcmFucysNCgkJQUNTQ3RsOglTcmNW
YWxpZCsgVHJhbnNCbGstIFJlcVJlZGlyKyBDbXBsdFJlZGlyKyBVcHN0cmVhbUZ3ZCsgRWdy
ZXNzQ3RybC0gRGlyZWN0VHJhbnMtDQoJS2VybmVsIGRyaXZlciBpbiB1c2U6IHBjaWVwb3J0
DQoNCjAwOjA2LjAgUENJIGJyaWRnZSBbMDYwNF06IEFUSSBUZWNobm9sb2dpZXMgSW5jIFJE
ODkwIFBDSSB0byBQQ0kgYnJpZGdlIChQQ0kgZXhwcmVzcyBncHAgcG9ydCBGKSBbMTAwMjo1
YTFhXSAocHJvZy1pZiAwMCBbTm9ybWFsIGRlY29kZV0pDQoJQ29udHJvbDogSS9PKyBNZW0r
IEJ1c01hc3RlcisgU3BlY0N5Y2xlLSBNZW1XSU5WLSBWR0FTbm9vcC0gUGFyRXJyLSBTdGVw
cGluZy0gU0VSUisgRmFzdEIyQi0gRGlzSU5UeCsNCglTdGF0dXM6IENhcCsgNjZNSHotIFVE
Ri0gRmFzdEIyQi0gUGFyRXJyLSBERVZTRUw9ZmFzdCA+VEFib3J0LSA8VEFib3J0LSA8TUFi
b3J0LSA+U0VSUi0gPFBFUlItIElOVHgtDQoJTGF0ZW5jeTogMCwgQ2FjaGUgTGluZSBTaXpl
OiA2NCBieXRlcw0KCUJ1czogcHJpbWFyeT0wMCwgc2Vjb25kYXJ5PTA4LCBzdWJvcmRpbmF0
ZT0wOCwgc2VjLWxhdGVuY3k9MA0KCUkvTyBiZWhpbmQgYnJpZGdlOiAwMDAwYzAwMC0wMDAw
Y2ZmZg0KCU1lbW9yeSBiZWhpbmQgYnJpZGdlOiBmOWQwMDAwMC1mOWRmZmZmZg0KCVByZWZl
dGNoYWJsZSBtZW1vcnkgYmVoaW5kIGJyaWRnZTogMDAwMDAwMDBjZmUwMDAwMC0wMDAwMDAw
MGNmZWZmZmZmDQoJU2Vjb25kYXJ5IHN0YXR1czogNjZNSHotIEZhc3RCMkItIFBhckVyci0g
REVWU0VMPWZhc3QgPlRBYm9ydC0gPFRBYm9ydC0gPE1BYm9ydC0gPFNFUlItIDxQRVJSLQ0K
CUJyaWRnZUN0bDogUGFyaXR5KyBTRVJSKyBOb0lTQSsgVkdBLSBNQWJvcnQtID5SZXNldC0g
RmFzdEIyQi0NCgkJUHJpRGlzY1Rtci0gU2VjRGlzY1Rtci0gRGlzY1RtclN0YXQtIERpc2NU
bXJTRVJSRW4tDQoJQ2FwYWJpbGl0aWVzOiBbNTBdIFBvd2VyIE1hbmFnZW1lbnQgdmVyc2lv
biAzDQoJCUZsYWdzOiBQTUVDbGstIERTSS0gRDEtIEQyLSBBdXhDdXJyZW50PTBtQSBQTUUo
RDArLEQxLSxEMi0sRDNob3QrLEQzY29sZCspDQoJCVN0YXR1czogRDAgTm9Tb2Z0UnN0LSBQ
TUUtRW5hYmxlLSBEU2VsPTAgRFNjYWxlPTAgUE1FLQ0KCUNhcGFiaWxpdGllczogWzU4XSBF
eHByZXNzICh2MikgUm9vdCBQb3J0IChTbG90KyksIE1TSSAwMA0KCQlEZXZDYXA6CU1heFBh
eWxvYWQgMTI4IGJ5dGVzLCBQaGFudEZ1bmMgMCwgTGF0ZW5jeSBMMHMgPDY0bnMsIEwxIDwx
dXMNCgkJCUV4dFRhZysgUkJFKyBGTFJlc2V0LQ0KCQlEZXZDdGw6CVJlcG9ydCBlcnJvcnM6
IENvcnJlY3RhYmxlLSBOb24tRmF0YWwtIEZhdGFsLSBVbnN1cHBvcnRlZC0NCgkJCVJseGRP
cmQrIEV4dFRhZy0gUGhhbnRGdW5jLSBBdXhQd3ItIE5vU25vb3ArDQoJCQlNYXhQYXlsb2Fk
IDEyOCBieXRlcywgTWF4UmVhZFJlcSAxMjggYnl0ZXMNCgkJRGV2U3RhOglDb3JyRXJyLSBV
bmNvcnJFcnItIEZhdGFsRXJyLSBVbnN1cHBSZXEtIEF1eFB3ci0gVHJhbnNQZW5kLQ0KCQlM
bmtDYXA6CVBvcnQgIzIsIFNwZWVkIDVHVC9zLCBXaWR0aCB4MSwgQVNQTSBMMHMgTDEsIExh
dGVuY3kgTDAgPDF1cywgTDEgPDh1cw0KCQkJQ2xvY2tQTS0gU3VycHJpc2UtIExMQWN0UmVw
KyBCd05vdCsNCgkJTG5rQ3RsOglBU1BNIERpc2FibGVkOyBSQ0IgNjQgYnl0ZXMgRGlzYWJs
ZWQtIFJldHJhaW4tIENvbW1DbGsrDQoJCQlFeHRTeW5jaC0gQ2xvY2tQTS0gQXV0V2lkRGlz
LSBCV0ludC0gQXV0QldJbnQtDQoJCUxua1N0YToJU3BlZWQgMi41R1QvcywgV2lkdGggeDEs
IFRyRXJyLSBUcmFpbi0gU2xvdENsaysgRExBY3RpdmUrIEJXTWdtdCsgQUJXTWdtdC0NCgkJ
U2x0Q2FwOglBdHRuQnRuLSBQd3JDdHJsLSBNUkwtIEF0dG5JbmQtIFB3ckluZC0gSG90UGx1
Zy0gU3VycHJpc2UtDQoJCQlTbG90ICM2LCBQb3dlckxpbWl0IDc1LjAwMFc7IEludGVybG9j
ay0gTm9Db21wbCsNCgkJU2x0Q3RsOglFbmFibGU6IEF0dG5CdG4tIFB3ckZsdC0gTVJMLSBQ
cmVzRGV0LSBDbWRDcGx0LSBIUElycS0gTGlua0NoZy0NCgkJCUNvbnRyb2w6IEF0dG5JbmQg
VW5rbm93biwgUHdySW5kIFVua25vd24sIFBvd2VyLSBJbnRlcmxvY2stDQoJCVNsdFN0YToJ
U3RhdHVzOiBBdHRuQnRuLSBQb3dlckZsdC0gTVJMLSBDbWRDcGx0LSBQcmVzRGV0KyBJbnRl
cmxvY2stDQoJCQlDaGFuZ2VkOiBNUkwtIFByZXNEZXQrIExpbmtTdGF0ZSsNCgkJUm9vdEN0
bDogRXJyQ29ycmVjdGFibGUtIEVyck5vbi1GYXRhbC0gRXJyRmF0YWwtIFBNRUludEVuYS0g
Q1JTVmlzaWJsZS0NCgkJUm9vdENhcDogQ1JTVmlzaWJsZS0NCgkJUm9vdFN0YTogUE1FIFJl
cUlEIDAwMDAsIFBNRVN0YXR1cy0gUE1FUGVuZGluZy0NCgkJRGV2Q2FwMjogQ29tcGxldGlv
biBUaW1lb3V0OiBSYW5nZSBBQkNELCBUaW1lb3V0RGlzKyBBUklGd2QrDQoJCURldkN0bDI6
IENvbXBsZXRpb24gVGltZW91dDogNjVtcyB0byAyMTBtcywgVGltZW91dERpcy0gQVJJRndk
LQ0KCQlMbmtDdGwyOiBUYXJnZXQgTGluayBTcGVlZDogNUdUL3MsIEVudGVyQ29tcGxpYW5j
ZS0gU3BlZWREaXMtLCBTZWxlY3RhYmxlIERlLWVtcGhhc2lzOiAtMy41ZEINCgkJCSBUcmFu
c21pdCBNYXJnaW46IE5vcm1hbCBPcGVyYXRpbmcgUmFuZ2UsIEVudGVyTW9kaWZpZWRDb21w
bGlhbmNlLSBDb21wbGlhbmNlU09TLQ0KCQkJIENvbXBsaWFuY2UgRGUtZW1waGFzaXM6IC02
ZEINCgkJTG5rU3RhMjogQ3VycmVudCBEZS1lbXBoYXNpcyBMZXZlbDogLTMuNWRCDQoJQ2Fw
YWJpbGl0aWVzOiBbYTBdIE1TSTogRW5hYmxlKyBDb3VudD0xLzEgTWFza2FibGUtIDY0Yml0
LQ0KCQlBZGRyZXNzOiBmZWUzZjAwYyAgRGF0YTogNDE2OQ0KCUNhcGFiaWxpdGllczogW2Iw
XSBTdWJzeXN0ZW06IEFUSSBUZWNobm9sb2dpZXMgSW5jIERldmljZSBbMTAwMjo1YTExXQ0K
CUNhcGFiaWxpdGllczogW2I4XSBIeXBlclRyYW5zcG9ydDogTVNJIE1hcHBpbmcgRW5hYmxl
KyBGaXhlZCsNCglDYXBhYmlsaXRpZXM6IFsxMDAgdjFdIFZlbmRvciBTcGVjaWZpYyBJbmZv
cm1hdGlvbjogSUQ9MDAwMSBSZXY9MSBMZW49MDEwIDw/Pg0KCUNhcGFiaWxpdGllczogWzE5
MCB2MV0gQWNjZXNzIENvbnRyb2wgU2VydmljZXMNCgkJQUNTQ2FwOglTcmNWYWxpZCsgVHJh
bnNCbGsrIFJlcVJlZGlyKyBDbXBsdFJlZGlyKyBVcHN0cmVhbUZ3ZCsgRWdyZXNzQ3RybC0g
RGlyZWN0VHJhbnMrDQoJCUFDU0N0bDoJU3JjVmFsaWQrIFRyYW5zQmxrLSBSZXFSZWRpcisg
Q21wbHRSZWRpcisgVXBzdHJlYW1Gd2QrIEVncmVzc0N0cmwtIERpcmVjdFRyYW5zLQ0KCUtl
cm5lbCBkcml2ZXIgaW4gdXNlOiBwY2llcG9ydA0KDQowMDowYS4wIFBDSSBicmlkZ2UgWzA2
MDRdOiBBVEkgVGVjaG5vbG9naWVzIEluYyBSRDg5MCBQQ0kgdG8gUENJIGJyaWRnZSAoZXh0
ZXJuYWwgZ2Z4MSBwb3J0IEEpIFsxMDAyOjVhMWRdIChwcm9nLWlmIDAwIFtOb3JtYWwgZGVj
b2RlXSkNCglDb250cm9sOiBJL08tIE1lbSsgQnVzTWFzdGVyKyBTcGVjQ3ljbGUtIE1lbVdJ
TlYtIFZHQVNub29wLSBQYXJFcnItIFN0ZXBwaW5nLSBTRVJSKyBGYXN0QjJCLSBEaXNJTlR4
Kw0KCVN0YXR1czogQ2FwKyA2Nk1Iei0gVURGLSBGYXN0QjJCLSBQYXJFcnItIERFVlNFTD1m
YXN0ID5UQWJvcnQtIDxUQWJvcnQtIDxNQWJvcnQtID5TRVJSLSA8UEVSUi0gSU5UeC0NCglM
YXRlbmN5OiAwLCBDYWNoZSBMaW5lIFNpemU6IDY0IGJ5dGVzDQoJQnVzOiBwcmltYXJ5PTAw
LCBzZWNvbmRhcnk9MDcsIHN1Ym9yZGluYXRlPTA3LCBzZWMtbGF0ZW5jeT0wDQoJSS9PIGJl
aGluZCBicmlkZ2U6IDAwMDBmMDAwLTAwMDAwZmZmDQoJTWVtb3J5IGJlaGluZCBicmlkZ2U6
IGY5YTAwMDAwLWY5YmZmZmZmDQoJUHJlZmV0Y2hhYmxlIG1lbW9yeSBiZWhpbmQgYnJpZGdl
OiAwMDAwMDAwMGZmZjAwMDAwLTAwMDAwMDAwMDAwZmZmZmYNCglTZWNvbmRhcnkgc3RhdHVz
OiA2Nk1Iei0gRmFzdEIyQi0gUGFyRXJyLSBERVZTRUw9ZmFzdCA+VEFib3J0LSA8VEFib3J0
LSA8TUFib3J0KyA8U0VSUi0gPFBFUlItDQoJQnJpZGdlQ3RsOiBQYXJpdHkrIFNFUlIrIE5v
SVNBKyBWR0EtIE1BYm9ydC0gPlJlc2V0LSBGYXN0QjJCLQ0KCQlQcmlEaXNjVG1yLSBTZWNE
aXNjVG1yLSBEaXNjVG1yU3RhdC0gRGlzY1RtclNFUlJFbi0NCglDYXBhYmlsaXRpZXM6IFs1
MF0gUG93ZXIgTWFuYWdlbWVudCB2ZXJzaW9uIDMNCgkJRmxhZ3M6IFBNRUNsay0gRFNJLSBE
MS0gRDItIEF1eEN1cnJlbnQ9MG1BIFBNRShEMCssRDEtLEQyLSxEM2hvdCssRDNjb2xkKykN
CgkJU3RhdHVzOiBEMCBOb1NvZnRSc3QtIFBNRS1FbmFibGUtIERTZWw9MCBEU2NhbGU9MCBQ
TUUtDQoJQ2FwYWJpbGl0aWVzOiBbNThdIEV4cHJlc3MgKHYyKSBSb290IFBvcnQgKFNsb3Qr
KSwgTVNJIDAwDQoJCURldkNhcDoJTWF4UGF5bG9hZCAxMjggYnl0ZXMsIFBoYW50RnVuYyAw
LCBMYXRlbmN5IEwwcyA8NjRucywgTDEgPDF1cw0KCQkJRXh0VGFnKyBSQkUrIEZMUmVzZXQt
DQoJCURldkN0bDoJUmVwb3J0IGVycm9yczogQ29ycmVjdGFibGUtIE5vbi1GYXRhbC0gRmF0
YWwtIFVuc3VwcG9ydGVkLQ0KCQkJUmx4ZE9yZCsgRXh0VGFnLSBQaGFudEZ1bmMtIEF1eFB3
ci0gTm9Tbm9vcCsNCgkJCU1heFBheWxvYWQgMTI4IGJ5dGVzLCBNYXhSZWFkUmVxIDEyOCBi
eXRlcw0KCQlEZXZTdGE6CUNvcnJFcnItIFVuY29yckVyci0gRmF0YWxFcnItIFVuc3VwcFJl
cS0gQXV4UHdyLSBUcmFuc1BlbmQtDQoJCUxua0NhcDoJUG9ydCAjNSwgU3BlZWQgMi41R1Qv
cywgV2lkdGggeDEsIEFTUE0gTDBzIEwxLCBMYXRlbmN5IEwwIDwxdXMsIEwxIDw4dXMNCgkJ
CUNsb2NrUE0tIFN1cnByaXNlLSBMTEFjdFJlcCsgQndOb3QrDQoJCUxua0N0bDoJQVNQTSBE
aXNhYmxlZDsgUkNCIDY0IGJ5dGVzIERpc2FibGVkLSBSZXRyYWluLSBDb21tQ2xrLQ0KCQkJ
RXh0U3luY2gtIENsb2NrUE0tIEF1dFdpZERpcy0gQldJbnQtIEF1dEJXSW50LQ0KCQlMbmtT
dGE6CVNwZWVkIDIuNUdUL3MsIFdpZHRoIHgxLCBUckVyci0gVHJhaW4tIFNsb3RDbGsrIERM
QWN0aXZlKyBCV01nbXQrIEFCV01nbXQtDQoJCVNsdENhcDoJQXR0bkJ0bi0gUHdyQ3RybC0g
TVJMLSBBdHRuSW5kLSBQd3JJbmQtIEhvdFBsdWctIFN1cnByaXNlLQ0KCQkJU2xvdCAjMiwg
UG93ZXJMaW1pdCA3NS4wMDBXOyBJbnRlcmxvY2stIE5vQ29tcGwrDQoJCVNsdEN0bDoJRW5h
YmxlOiBBdHRuQnRuLSBQd3JGbHQtIE1STC0gUHJlc0RldC0gQ21kQ3BsdC0gSFBJcnEtIExp
bmtDaGctDQoJCQlDb250cm9sOiBBdHRuSW5kIFVua25vd24sIFB3ckluZCBVbmtub3duLCBQ
b3dlci0gSW50ZXJsb2NrLQ0KCQlTbHRTdGE6CVN0YXR1czogQXR0bkJ0bi0gUG93ZXJGbHQt
IE1STC0gQ21kQ3BsdC0gUHJlc0RldCsgSW50ZXJsb2NrLQ0KCQkJQ2hhbmdlZDogTVJMLSBQ
cmVzRGV0KyBMaW5rU3RhdGUrDQoJCVJvb3RDdGw6IEVyckNvcnJlY3RhYmxlLSBFcnJOb24t
RmF0YWwtIEVyckZhdGFsLSBQTUVJbnRFbmEtIENSU1Zpc2libGUtDQoJCVJvb3RDYXA6IENS
U1Zpc2libGUtDQoJCVJvb3RTdGE6IFBNRSBSZXFJRCAwMDAwLCBQTUVTdGF0dXMtIFBNRVBl
bmRpbmctDQoJCURldkNhcDI6IENvbXBsZXRpb24gVGltZW91dDogUmFuZ2UgQUJDRCwgVGlt
ZW91dERpcysgQVJJRndkKw0KCQlEZXZDdGwyOiBDb21wbGV0aW9uIFRpbWVvdXQ6IDY1bXMg
dG8gMjEwbXMsIFRpbWVvdXREaXMtIEFSSUZ3ZC0NCgkJTG5rQ3RsMjogVGFyZ2V0IExpbmsg
U3BlZWQ6IDIuNUdUL3MsIEVudGVyQ29tcGxpYW5jZS0gU3BlZWREaXMtLCBTZWxlY3RhYmxl
IERlLWVtcGhhc2lzOiAtNmRCDQoJCQkgVHJhbnNtaXQgTWFyZ2luOiBOb3JtYWwgT3BlcmF0
aW5nIFJhbmdlLCBFbnRlck1vZGlmaWVkQ29tcGxpYW5jZS0gQ29tcGxpYW5jZVNPUy0NCgkJ
CSBDb21wbGlhbmNlIERlLWVtcGhhc2lzOiAtNmRCDQoJCUxua1N0YTI6IEN1cnJlbnQgRGUt
ZW1waGFzaXMgTGV2ZWw6IC02ZEINCglDYXBhYmlsaXRpZXM6IFthMF0gTVNJOiBFbmFibGUr
IENvdW50PTEvMSBNYXNrYWJsZS0gNjRiaXQtDQoJCUFkZHJlc3M6IGZlZTNmMDBjICBEYXRh
OiA0MTcxDQoJQ2FwYWJpbGl0aWVzOiBbYjBdIFN1YnN5c3RlbTogQVRJIFRlY2hub2xvZ2ll
cyBJbmMgRGV2aWNlIFsxMDAyOjVhMTFdDQoJQ2FwYWJpbGl0aWVzOiBbYjhdIEh5cGVyVHJh
bnNwb3J0OiBNU0kgTWFwcGluZyBFbmFibGUrIEZpeGVkKw0KCUNhcGFiaWxpdGllczogWzEw
MCB2MV0gVmVuZG9yIFNwZWNpZmljIEluZm9ybWF0aW9uOiBJRD0wMDAxIFJldj0xIExlbj0w
MTAgPD8+DQoJQ2FwYWJpbGl0aWVzOiBbMTkwIHYxXSBBY2Nlc3MgQ29udHJvbCBTZXJ2aWNl
cw0KCQlBQ1NDYXA6CVNyY1ZhbGlkKyBUcmFuc0JsaysgUmVxUmVkaXIrIENtcGx0UmVkaXIr
IFVwc3RyZWFtRndkKyBFZ3Jlc3NDdHJsLSBEaXJlY3RUcmFucysNCgkJQUNTQ3RsOglTcmNW
YWxpZCsgVHJhbnNCbGstIFJlcVJlZGlyKyBDbXBsdFJlZGlyKyBVcHN0cmVhbUZ3ZCsgRWdy
ZXNzQ3RybC0gRGlyZWN0VHJhbnMtDQoJS2VybmVsIGRyaXZlciBpbiB1c2U6IHBjaWVwb3J0
DQoNCjAwOjBiLjAgUENJIGJyaWRnZSBbMDYwNF06IEFUSSBUZWNobm9sb2dpZXMgSW5jIFJE
ODkwIFBDSSB0byBQQ0kgYnJpZGdlIChOQi1TQiBsaW5rKSBbMTAwMjo1YTFmXSAocHJvZy1p
ZiAwMCBbTm9ybWFsIGRlY29kZV0pDQoJQ29udHJvbDogSS9PKyBNZW0rIEJ1c01hc3Rlcisg
U3BlY0N5Y2xlLSBNZW1XSU5WLSBWR0FTbm9vcC0gUGFyRXJyLSBTdGVwcGluZy0gU0VSUisg
RmFzdEIyQi0gRGlzSU5UeCsNCglTdGF0dXM6IENhcCsgNjZNSHotIFVERi0gRmFzdEIyQi0g
UGFyRXJyLSBERVZTRUw9ZmFzdCA+VEFib3J0LSA8VEFib3J0LSA8TUFib3J0LSA+U0VSUi0g
PFBFUlItIElOVHgtDQoJTGF0ZW5jeTogMCwgQ2FjaGUgTGluZSBTaXplOiA2NCBieXRlcw0K
CUJ1czogcHJpbWFyeT0wMCwgc2Vjb25kYXJ5PTA2LCBzdWJvcmRpbmF0ZT0wNiwgc2VjLWxh
dGVuY3k9MA0KCUkvTyBiZWhpbmQgYnJpZGdlOiAwMDAwYjAwMC0wMDAwYmZmZg0KCU1lbW9y
eSBiZWhpbmQgYnJpZGdlOiBmOTkwMDAwMC1mOTlmZmZmZg0KCVByZWZldGNoYWJsZSBtZW1v
cnkgYmVoaW5kIGJyaWRnZTogMDAwMDAwMDBiMDAwMDAwMC0wMDAwMDAwMGJmZmZmZmZmDQoJ
U2Vjb25kYXJ5IHN0YXR1czogNjZNSHotIEZhc3RCMkItIFBhckVyci0gREVWU0VMPWZhc3Qg
PlRBYm9ydC0gPFRBYm9ydC0gPE1BYm9ydC0gPFNFUlItIDxQRVJSLQ0KCUJyaWRnZUN0bDog
UGFyaXR5KyBTRVJSKyBOb0lTQSsgVkdBLSBNQWJvcnQtID5SZXNldC0gRmFzdEIyQi0NCgkJ
UHJpRGlzY1Rtci0gU2VjRGlzY1Rtci0gRGlzY1RtclN0YXQtIERpc2NUbXJTRVJSRW4tDQoJ
Q2FwYWJpbGl0aWVzOiBbNTBdIFBvd2VyIE1hbmFnZW1lbnQgdmVyc2lvbiAzDQoJCUZsYWdz
OiBQTUVDbGstIERTSS0gRDEtIEQyLSBBdXhDdXJyZW50PTBtQSBQTUUoRDArLEQxLSxEMi0s
RDNob3QrLEQzY29sZCspDQoJCVN0YXR1czogRDAgTm9Tb2Z0UnN0LSBQTUUtRW5hYmxlLSBE
U2VsPTAgRFNjYWxlPTAgUE1FLQ0KCUNhcGFiaWxpdGllczogWzU4XSBFeHByZXNzICh2Mikg
Um9vdCBQb3J0IChTbG90KyksIE1TSSAwMA0KCQlEZXZDYXA6CU1heFBheWxvYWQgMTI4IGJ5
dGVzLCBQaGFudEZ1bmMgMCwgTGF0ZW5jeSBMMHMgPDY0bnMsIEwxIDwxdXMNCgkJCUV4dFRh
ZysgUkJFKyBGTFJlc2V0LQ0KCQlEZXZDdGw6CVJlcG9ydCBlcnJvcnM6IENvcnJlY3RhYmxl
LSBOb24tRmF0YWwtIEZhdGFsLSBVbnN1cHBvcnRlZC0NCgkJCVJseGRPcmQrIEV4dFRhZy0g
UGhhbnRGdW5jLSBBdXhQd3ItIE5vU25vb3ArDQoJCQlNYXhQYXlsb2FkIDEyOCBieXRlcywg
TWF4UmVhZFJlcSAxMjggYnl0ZXMNCgkJRGV2U3RhOglDb3JyRXJyLSBVbmNvcnJFcnItIEZh
dGFsRXJyLSBVbnN1cHBSZXEtIEF1eFB3ci0gVHJhbnNQZW5kLQ0KCQlMbmtDYXA6CVBvcnQg
IzAsIFNwZWVkIDVHVC9zLCBXaWR0aCB4OCwgQVNQTSBMMHMgTDEsIExhdGVuY3kgTDAgPDF1
cywgTDEgPDh1cw0KCQkJQ2xvY2tQTS0gU3VycHJpc2UtIExMQWN0UmVwKyBCd05vdCsNCgkJ
TG5rQ3RsOglBU1BNIERpc2FibGVkOyBSQ0IgNjQgYnl0ZXMgRGlzYWJsZWQtIFJldHJhaW4t
IENvbW1DbGsrDQoJCQlFeHRTeW5jaC0gQ2xvY2tQTS0gQXV0V2lkRGlzLSBCV0ludC0gQXV0
QldJbnQtDQoJCUxua1N0YToJU3BlZWQgMi41R1QvcywgV2lkdGggeDEsIFRyRXJyLSBUcmFp
bi0gU2xvdENsaysgRExBY3RpdmUrIEJXTWdtdCsgQUJXTWdtdC0NCgkJU2x0Q2FwOglBdHRu
QnRuLSBQd3JDdHJsLSBNUkwtIEF0dG5JbmQtIFB3ckluZC0gSG90UGx1Zy0gU3VycHJpc2Ut
DQoJCQlTbG90ICM1LCBQb3dlckxpbWl0IDMxLjAwMFc7IEludGVybG9jay0gTm9Db21wbCsN
CgkJU2x0Q3RsOglFbmFibGU6IEF0dG5CdG4tIFB3ckZsdC0gTVJMLSBQcmVzRGV0LSBDbWRD
cGx0LSBIUElycS0gTGlua0NoZy0NCgkJCUNvbnRyb2w6IEF0dG5JbmQgVW5rbm93biwgUHdy
SW5kIFVua25vd24sIFBvd2VyLSBJbnRlcmxvY2stDQoJCVNsdFN0YToJU3RhdHVzOiBBdHRu
QnRuLSBQb3dlckZsdC0gTVJMLSBDbWRDcGx0LSBQcmVzRGV0KyBJbnRlcmxvY2stDQoJCQlD
aGFuZ2VkOiBNUkwtIFByZXNEZXQrIExpbmtTdGF0ZSsNCgkJUm9vdEN0bDogRXJyQ29ycmVj
dGFibGUtIEVyck5vbi1GYXRhbC0gRXJyRmF0YWwtIFBNRUludEVuYS0gQ1JTVmlzaWJsZS0N
CgkJUm9vdENhcDogQ1JTVmlzaWJsZS0NCgkJUm9vdFN0YTogUE1FIFJlcUlEIDAwMDAsIFBN
RVN0YXR1cy0gUE1FUGVuZGluZy0NCgkJRGV2Q2FwMjogQ29tcGxldGlvbiBUaW1lb3V0OiBS
YW5nZSBBQkNELCBUaW1lb3V0RGlzKyBBUklGd2QrDQoJCURldkN0bDI6IENvbXBsZXRpb24g
VGltZW91dDogNjVtcyB0byAyMTBtcywgVGltZW91dERpcy0gQVJJRndkLQ0KCQlMbmtDdGwy
OiBUYXJnZXQgTGluayBTcGVlZDogNUdUL3MsIEVudGVyQ29tcGxpYW5jZS0gU3BlZWREaXMt
LCBTZWxlY3RhYmxlIERlLWVtcGhhc2lzOiAtMy41ZEINCgkJCSBUcmFuc21pdCBNYXJnaW46
IE5vcm1hbCBPcGVyYXRpbmcgUmFuZ2UsIEVudGVyTW9kaWZpZWRDb21wbGlhbmNlLSBDb21w
bGlhbmNlU09TLQ0KCQkJIENvbXBsaWFuY2UgRGUtZW1waGFzaXM6IC02ZEINCgkJTG5rU3Rh
MjogQ3VycmVudCBEZS1lbXBoYXNpcyBMZXZlbDogLTMuNWRCDQoJQ2FwYWJpbGl0aWVzOiBb
YTBdIE1TSTogRW5hYmxlKyBDb3VudD0xLzEgTWFza2FibGUtIDY0Yml0LQ0KCQlBZGRyZXNz
OiBmZWUzZjAwYyAgRGF0YTogNDE3OQ0KCUNhcGFiaWxpdGllczogW2IwXSBTdWJzeXN0ZW06
IEFUSSBUZWNobm9sb2dpZXMgSW5jIERldmljZSBbMTAwMjo1YTExXQ0KCUNhcGFiaWxpdGll
czogW2I4XSBIeXBlclRyYW5zcG9ydDogTVNJIE1hcHBpbmcgRW5hYmxlKyBGaXhlZCsNCglD
YXBhYmlsaXRpZXM6IFsxMDAgdjFdIFZlbmRvciBTcGVjaWZpYyBJbmZvcm1hdGlvbjogSUQ9
MDAwMSBSZXY9MSBMZW49MDEwIDw/Pg0KCUNhcGFiaWxpdGllczogWzE5MCB2MV0gQWNjZXNz
IENvbnRyb2wgU2VydmljZXMNCgkJQUNTQ2FwOglTcmNWYWxpZCsgVHJhbnNCbGsrIFJlcVJl
ZGlyKyBDbXBsdFJlZGlyKyBVcHN0cmVhbUZ3ZCsgRWdyZXNzQ3RybC0gRGlyZWN0VHJhbnMr
DQoJCUFDU0N0bDoJU3JjVmFsaWQrIFRyYW5zQmxrLSBSZXFSZWRpcisgQ21wbHRSZWRpcisg
VXBzdHJlYW1Gd2QrIEVncmVzc0N0cmwtIERpcmVjdFRyYW5zLQ0KCUtlcm5lbCBkcml2ZXIg
aW4gdXNlOiBwY2llcG9ydA0KDQowMDowYy4wIFBDSSBicmlkZ2UgWzA2MDRdOiBBVEkgVGVj
aG5vbG9naWVzIEluYyBEZXZpY2UgWzEwMDI6NWEyMF0gKHByb2ctaWYgMDAgW05vcm1hbCBk
ZWNvZGVdKQ0KCUNvbnRyb2w6IEkvTy0gTWVtKyBCdXNNYXN0ZXIrIFNwZWNDeWNsZS0gTWVt
V0lOVi0gVkdBU25vb3AtIFBhckVyci0gU3RlcHBpbmctIFNFUlIrIEZhc3RCMkItIERpc0lO
VHgrDQoJU3RhdHVzOiBDYXArIDY2TUh6LSBVREYtIEZhc3RCMkItIFBhckVyci0gREVWU0VM
PWZhc3QgPlRBYm9ydC0gPFRBYm9ydC0gPE1BYm9ydC0gPlNFUlItIDxQRVJSLSBJTlR4LQ0K
CUxhdGVuY3k6IDAsIENhY2hlIExpbmUgU2l6ZTogNjQgYnl0ZXMNCglCdXM6IHByaW1hcnk9
MDAsIHNlY29uZGFyeT0wNSwgc3Vib3JkaW5hdGU9MDUsIHNlYy1sYXRlbmN5PTANCglJL08g
YmVoaW5kIGJyaWRnZTogMDAwMGYwMDAtMDAwMDBmZmYNCglNZW1vcnkgYmVoaW5kIGJyaWRn
ZTogZjk2MDAwMDAtZjk3ZmZmZmYNCglQcmVmZXRjaGFibGUgbWVtb3J5IGJlaGluZCBicmlk
Z2U6IDAwMDAwMDAwZmZmMDAwMDAtMDAwMDAwMDAwMDBmZmZmZg0KCVNlY29uZGFyeSBzdGF0
dXM6IDY2TUh6LSBGYXN0QjJCLSBQYXJFcnItIERFVlNFTD1mYXN0ID5UQWJvcnQtIDxUQWJv
cnQtIDxNQWJvcnQrIDxTRVJSLSA8UEVSUi0NCglCcmlkZ2VDdGw6IFBhcml0eSsgU0VSUisg
Tm9JU0ErIFZHQS0gTUFib3J0LSA+UmVzZXQtIEZhc3RCMkItDQoJCVByaURpc2NUbXItIFNl
Y0Rpc2NUbXItIERpc2NUbXJTdGF0LSBEaXNjVG1yU0VSUkVuLQ0KCUNhcGFiaWxpdGllczog
WzUwXSBQb3dlciBNYW5hZ2VtZW50IHZlcnNpb24gMw0KCQlGbGFnczogUE1FQ2xrLSBEU0kt
IEQxLSBEMi0gQXV4Q3VycmVudD0wbUEgUE1FKEQwKyxEMS0sRDItLEQzaG90KyxEM2NvbGQr
KQ0KCQlTdGF0dXM6IEQwIE5vU29mdFJzdC0gUE1FLUVuYWJsZS0gRFNlbD0wIERTY2FsZT0w
IFBNRS0NCglDYXBhYmlsaXRpZXM6IFs1OF0gRXhwcmVzcyAodjIpIFJvb3QgUG9ydCAoU2xv
dCspLCBNU0kgMDANCgkJRGV2Q2FwOglNYXhQYXlsb2FkIDEyOCBieXRlcywgUGhhbnRGdW5j
IDAsIExhdGVuY3kgTDBzIDw2NG5zLCBMMSA8MXVzDQoJCQlFeHRUYWcrIFJCRSsgRkxSZXNl
dC0NCgkJRGV2Q3RsOglSZXBvcnQgZXJyb3JzOiBDb3JyZWN0YWJsZS0gTm9uLUZhdGFsLSBG
YXRhbC0gVW5zdXBwb3J0ZWQtDQoJCQlSbHhkT3JkKyBFeHRUYWctIFBoYW50RnVuYy0gQXV4
UHdyLSBOb1Nub29wKw0KCQkJTWF4UGF5bG9hZCAxMjggYnl0ZXMsIE1heFJlYWRSZXEgMTI4
IGJ5dGVzDQoJCURldlN0YToJQ29yckVyci0gVW5jb3JyRXJyLSBGYXRhbEVyci0gVW5zdXBw
UmVxLSBBdXhQd3ItIFRyYW5zUGVuZC0NCgkJTG5rQ2FwOglQb3J0ICMxLCBTcGVlZCA1R1Qv
cywgV2lkdGggeDgsIEFTUE0gTDBzIEwxLCBMYXRlbmN5IEwwIDwxdXMsIEwxIDw4dXMNCgkJ
CUNsb2NrUE0tIFN1cnByaXNlLSBMTEFjdFJlcCsgQndOb3QrDQoJCUxua0N0bDoJQVNQTSBE
aXNhYmxlZDsgUkNCIDY0IGJ5dGVzIERpc2FibGVkLSBSZXRyYWluLSBDb21tQ2xrLQ0KCQkJ
RXh0U3luY2gtIENsb2NrUE0tIEF1dFdpZERpcy0gQldJbnQtIEF1dEJXSW50LQ0KCQlMbmtT
dGE6CVNwZWVkIDIuNUdUL3MsIFdpZHRoIHgxLCBUckVyci0gVHJhaW4tIFNsb3RDbGsrIERM
QWN0aXZlKyBCV01nbXQrIEFCV01nbXQtDQoJCVNsdENhcDoJQXR0bkJ0bi0gUHdyQ3RybC0g
TVJMLSBBdHRuSW5kLSBQd3JJbmQtIEhvdFBsdWctIFN1cnByaXNlLQ0KCQkJU2xvdCAjNiwg
UG93ZXJMaW1pdCAxNC4wMDBXOyBJbnRlcmxvY2stIE5vQ29tcGwrDQoJCVNsdEN0bDoJRW5h
YmxlOiBBdHRuQnRuLSBQd3JGbHQtIE1STC0gUHJlc0RldC0gQ21kQ3BsdC0gSFBJcnEtIExp
bmtDaGctDQoJCQlDb250cm9sOiBBdHRuSW5kIFVua25vd24sIFB3ckluZCBVbmtub3duLCBQ
b3dlci0gSW50ZXJsb2NrLQ0KCQlTbHRTdGE6CVN0YXR1czogQXR0bkJ0bi0gUG93ZXJGbHQt
IE1STC0gQ21kQ3BsdC0gUHJlc0RldCsgSW50ZXJsb2NrLQ0KCQkJQ2hhbmdlZDogTVJMLSBQ
cmVzRGV0KyBMaW5rU3RhdGUrDQoJCVJvb3RDdGw6IEVyckNvcnJlY3RhYmxlLSBFcnJOb24t
RmF0YWwtIEVyckZhdGFsLSBQTUVJbnRFbmEtIENSU1Zpc2libGUtDQoJCVJvb3RDYXA6IENS
U1Zpc2libGUtDQoJCVJvb3RTdGE6IFBNRSBSZXFJRCAwMDAwLCBQTUVTdGF0dXMtIFBNRVBl
bmRpbmctDQoJCURldkNhcDI6IENvbXBsZXRpb24gVGltZW91dDogUmFuZ2UgQUJDRCwgVGlt
ZW91dERpcysgQVJJRndkKw0KCQlEZXZDdGwyOiBDb21wbGV0aW9uIFRpbWVvdXQ6IDY1bXMg
dG8gMjEwbXMsIFRpbWVvdXREaXMtIEFSSUZ3ZC0NCgkJTG5rQ3RsMjogVGFyZ2V0IExpbmsg
U3BlZWQ6IDVHVC9zLCBFbnRlckNvbXBsaWFuY2UtIFNwZWVkRGlzLSwgU2VsZWN0YWJsZSBE
ZS1lbXBoYXNpczogLTMuNWRCDQoJCQkgVHJhbnNtaXQgTWFyZ2luOiBOb3JtYWwgT3BlcmF0
aW5nIFJhbmdlLCBFbnRlck1vZGlmaWVkQ29tcGxpYW5jZS0gQ29tcGxpYW5jZVNPUy0NCgkJ
CSBDb21wbGlhbmNlIERlLWVtcGhhc2lzOiAtNmRCDQoJCUxua1N0YTI6IEN1cnJlbnQgRGUt
ZW1waGFzaXMgTGV2ZWw6IC0zLjVkQg0KCUNhcGFiaWxpdGllczogW2EwXSBNU0k6IEVuYWJs
ZSsgQ291bnQ9MS8xIE1hc2thYmxlLSA2NGJpdC0NCgkJQWRkcmVzczogZmVlM2YwMGMgIERh
dGE6IDQxODENCglDYXBhYmlsaXRpZXM6IFtiMF0gU3Vic3lzdGVtOiBBVEkgVGVjaG5vbG9n
aWVzIEluYyBEZXZpY2UgWzEwMDI6NWExMV0NCglDYXBhYmlsaXRpZXM6IFtiOF0gSHlwZXJU
cmFuc3BvcnQ6IE1TSSBNYXBwaW5nIEVuYWJsZSsgRml4ZWQrDQoJQ2FwYWJpbGl0aWVzOiBb
MTAwIHYxXSBWZW5kb3IgU3BlY2lmaWMgSW5mb3JtYXRpb246IElEPTAwMDEgUmV2PTEgTGVu
PTAxMCA8Pz4NCglDYXBhYmlsaXRpZXM6IFsxOTAgdjFdIEFjY2VzcyBDb250cm9sIFNlcnZp
Y2VzDQoJCUFDU0NhcDoJU3JjVmFsaWQrIFRyYW5zQmxrKyBSZXFSZWRpcisgQ21wbHRSZWRp
cisgVXBzdHJlYW1Gd2QrIEVncmVzc0N0cmwtIERpcmVjdFRyYW5zKw0KCQlBQ1NDdGw6CVNy
Y1ZhbGlkKyBUcmFuc0Jsay0gUmVxUmVkaXIrIENtcGx0UmVkaXIrIFVwc3RyZWFtRndkKyBF
Z3Jlc3NDdHJsLSBEaXJlY3RUcmFucy0NCglLZXJuZWwgZHJpdmVyIGluIHVzZTogcGNpZXBv
cnQNCg0KMDA6MGQuMCBQQ0kgYnJpZGdlIFswNjA0XTogQVRJIFRlY2hub2xvZ2llcyBJbmMg
UkQ4OTAgUENJIHRvIFBDSSBicmlkZ2UgKGV4dGVybmFsIGdmeDEgcG9ydCBCKSBbMTAwMjo1
YTFlXSAocHJvZy1pZiAwMCBbTm9ybWFsIGRlY29kZV0pDQoJQ29udHJvbDogSS9PLSBNZW0r
IEJ1c01hc3RlcisgU3BlY0N5Y2xlLSBNZW1XSU5WLSBWR0FTbm9vcC0gUGFyRXJyLSBTdGVw
cGluZy0gU0VSUisgRmFzdEIyQi0gRGlzSU5UeCsNCglTdGF0dXM6IENhcCsgNjZNSHotIFVE
Ri0gRmFzdEIyQi0gUGFyRXJyLSBERVZTRUw9ZmFzdCA+VEFib3J0LSA8VEFib3J0LSA8TUFi
b3J0LSA+U0VSUi0gPFBFUlItIElOVHgtDQoJTGF0ZW5jeTogMCwgQ2FjaGUgTGluZSBTaXpl
OiA2NCBieXRlcw0KCUJ1czogcHJpbWFyeT0wMCwgc2Vjb25kYXJ5PTA0LCBzdWJvcmRpbmF0
ZT0wNCwgc2VjLWxhdGVuY3k9MA0KCUkvTyBiZWhpbmQgYnJpZGdlOiAwMDAwZjAwMC0wMDAw
MGZmZg0KCU1lbW9yeSBiZWhpbmQgYnJpZGdlOiBmOTUwMDAwMC1mOTVmZmZmZg0KCVByZWZl
dGNoYWJsZSBtZW1vcnkgYmVoaW5kIGJyaWRnZTogMDAwMDAwMDBmZmYwMDAwMC0wMDAwMDAw
MDAwMGZmZmZmDQoJU2Vjb25kYXJ5IHN0YXR1czogNjZNSHotIEZhc3RCMkItIFBhckVyci0g
REVWU0VMPWZhc3QgPlRBYm9ydC0gPFRBYm9ydC0gPE1BYm9ydC0gPFNFUlItIDxQRVJSLQ0K
CUJyaWRnZUN0bDogUGFyaXR5KyBTRVJSKyBOb0lTQSsgVkdBLSBNQWJvcnQtID5SZXNldC0g
RmFzdEIyQi0NCgkJUHJpRGlzY1Rtci0gU2VjRGlzY1Rtci0gRGlzY1RtclN0YXQtIERpc2NU
bXJTRVJSRW4tDQoJQ2FwYWJpbGl0aWVzOiBbNTBdIFBvd2VyIE1hbmFnZW1lbnQgdmVyc2lv
biAzDQoJCUZsYWdzOiBQTUVDbGstIERTSS0gRDEtIEQyLSBBdXhDdXJyZW50PTBtQSBQTUUo
RDArLEQxLSxEMi0sRDNob3QrLEQzY29sZCspDQoJCVN0YXR1czogRDAgTm9Tb2Z0UnN0LSBQ
TUUtRW5hYmxlLSBEU2VsPTAgRFNjYWxlPTAgUE1FLQ0KCUNhcGFiaWxpdGllczogWzU4XSBF
eHByZXNzICh2MikgUm9vdCBQb3J0IChTbG90KyksIE1TSSAwMA0KCQlEZXZDYXA6CU1heFBh
eWxvYWQgMTI4IGJ5dGVzLCBQaGFudEZ1bmMgMCwgTGF0ZW5jeSBMMHMgPDY0bnMsIEwxIDwx
dXMNCgkJCUV4dFRhZysgUkJFKyBGTFJlc2V0LQ0KCQlEZXZDdGw6CVJlcG9ydCBlcnJvcnM6
IENvcnJlY3RhYmxlLSBOb24tRmF0YWwtIEZhdGFsLSBVbnN1cHBvcnRlZC0NCgkJCVJseGRP
cmQrIEV4dFRhZy0gUGhhbnRGdW5jLSBBdXhQd3ItIE5vU25vb3ArDQoJCQlNYXhQYXlsb2Fk
IDEyOCBieXRlcywgTWF4UmVhZFJlcSAxMjggYnl0ZXMNCgkJRGV2U3RhOglDb3JyRXJyLSBV
bmNvcnJFcnItIEZhdGFsRXJyLSBVbnN1cHBSZXEtIEF1eFB3ci0gVHJhbnNQZW5kLQ0KCQlM
bmtDYXA6CVBvcnQgIzAsIFNwZWVkIDVHVC9zLCBXaWR0aCB4NCwgQVNQTSBMMHMgTDEsIExh
dGVuY3kgTDAgPDF1cywgTDEgPDh1cw0KCQkJQ2xvY2tQTS0gU3VycHJpc2UtIExMQWN0UmVw
KyBCd05vdCsNCgkJTG5rQ3RsOglBU1BNIERpc2FibGVkOyBSQ0IgNjQgYnl0ZXMgRGlzYWJs
ZWQtIFJldHJhaW4tIENvbW1DbGstDQoJCQlFeHRTeW5jaC0gQ2xvY2tQTS0gQXV0V2lkRGlz
LSBCV0ludC0gQXV0QldJbnQtDQoJCUxua1N0YToJU3BlZWQgMi41R1QvcywgV2lkdGggeDEs
IFRyRXJyLSBUcmFpbi0gU2xvdENsaysgRExBY3RpdmUrIEJXTWdtdCsgQUJXTWdtdC0NCgkJ
U2x0Q2FwOglBdHRuQnRuLSBQd3JDdHJsLSBNUkwtIEF0dG5JbmQtIFB3ckluZC0gSG90UGx1
Zy0gU3VycHJpc2UtDQoJCQlTbG90ICM0LCBQb3dlckxpbWl0IDc1LjAwMFc7IEludGVybG9j
ay0gTm9Db21wbCsNCgkJU2x0Q3RsOglFbmFibGU6IEF0dG5CdG4tIFB3ckZsdC0gTVJMLSBQ
cmVzRGV0LSBDbWRDcGx0LSBIUElycS0gTGlua0NoZy0NCgkJCUNvbnRyb2w6IEF0dG5JbmQg
VW5rbm93biwgUHdySW5kIFVua25vd24sIFBvd2VyLSBJbnRlcmxvY2stDQoJCVNsdFN0YToJ
U3RhdHVzOiBBdHRuQnRuLSBQb3dlckZsdC0gTVJMLSBDbWRDcGx0LSBQcmVzRGV0KyBJbnRl
cmxvY2stDQoJCQlDaGFuZ2VkOiBNUkwtIFByZXNEZXQrIExpbmtTdGF0ZSsNCgkJUm9vdEN0
bDogRXJyQ29ycmVjdGFibGUtIEVyck5vbi1GYXRhbC0gRXJyRmF0YWwtIFBNRUludEVuYS0g
Q1JTVmlzaWJsZS0NCgkJUm9vdENhcDogQ1JTVmlzaWJsZS0NCgkJUm9vdFN0YTogUE1FIFJl
cUlEIDAwMDAsIFBNRVN0YXR1cy0gUE1FUGVuZGluZy0NCgkJRGV2Q2FwMjogQ29tcGxldGlv
biBUaW1lb3V0OiBSYW5nZSBBQkNELCBUaW1lb3V0RGlzKyBBUklGd2QrDQoJCURldkN0bDI6
IENvbXBsZXRpb24gVGltZW91dDogNjVtcyB0byAyMTBtcywgVGltZW91dERpcy0gQVJJRndk
LQ0KCQlMbmtDdGwyOiBUYXJnZXQgTGluayBTcGVlZDogNUdUL3MsIEVudGVyQ29tcGxpYW5j
ZS0gU3BlZWREaXMtLCBTZWxlY3RhYmxlIERlLWVtcGhhc2lzOiAtMy41ZEINCgkJCSBUcmFu
c21pdCBNYXJnaW46IE5vcm1hbCBPcGVyYXRpbmcgUmFuZ2UsIEVudGVyTW9kaWZpZWRDb21w
bGlhbmNlLSBDb21wbGlhbmNlU09TLQ0KCQkJIENvbXBsaWFuY2UgRGUtZW1waGFzaXM6IC02
ZEINCgkJTG5rU3RhMjogQ3VycmVudCBEZS1lbXBoYXNpcyBMZXZlbDogLTMuNWRCDQoJQ2Fw
YWJpbGl0aWVzOiBbYTBdIE1TSTogRW5hYmxlKyBDb3VudD0xLzEgTWFza2FibGUtIDY0Yml0
LQ0KCQlBZGRyZXNzOiBmZWUzZjAwYyAgRGF0YTogNDE4OQ0KCUNhcGFiaWxpdGllczogW2Iw
XSBTdWJzeXN0ZW06IEFUSSBUZWNobm9sb2dpZXMgSW5jIERldmljZSBbMTAwMjo1YTExXQ0K
CUNhcGFiaWxpdGllczogW2I4XSBIeXBlclRyYW5zcG9ydDogTVNJIE1hcHBpbmcgRW5hYmxl
KyBGaXhlZCsNCglDYXBhYmlsaXRpZXM6IFsxMDAgdjFdIFZlbmRvciBTcGVjaWZpYyBJbmZv
cm1hdGlvbjogSUQ9MDAwMSBSZXY9MSBMZW49MDEwIDw/Pg0KCUNhcGFiaWxpdGllczogWzE5
MCB2MV0gQWNjZXNzIENvbnRyb2wgU2VydmljZXMNCgkJQUNTQ2FwOglTcmNWYWxpZCsgVHJh
bnNCbGsrIFJlcVJlZGlyKyBDbXBsdFJlZGlyKyBVcHN0cmVhbUZ3ZCsgRWdyZXNzQ3RybC0g
RGlyZWN0VHJhbnMrDQoJCUFDU0N0bDoJU3JjVmFsaWQrIFRyYW5zQmxrLSBSZXFSZWRpcisg
Q21wbHRSZWRpcisgVXBzdHJlYW1Gd2QrIEVncmVzc0N0cmwtIERpcmVjdFRyYW5zLQ0KCUtl
cm5lbCBkcml2ZXIgaW4gdXNlOiBwY2llcG9ydA0KDQowMDoxMS4wIFNBVEEgY29udHJvbGxl
ciBbMDEwNl06IEFUSSBUZWNobm9sb2dpZXMgSW5jIFNCN3gwL1NCOHgwL1NCOXgwIFNBVEEg
Q29udHJvbGxlciBbQUhDSSBtb2RlXSBbMTAwMjo0MzkxXSAocmV2IDQwKSAocHJvZy1pZiAw
MSBbQUhDSSAxLjBdKQ0KCVN1YnN5c3RlbTogTWljcm8tU3RhciBJbnRlcm5hdGlvbmFsIENv
LiwgTHRkLiBEZXZpY2UgWzE0NjI6NzY0MF0NCglDb250cm9sOiBJL08rIE1lbSsgQnVzTWFz
dGVyKyBTcGVjQ3ljbGUtIE1lbVdJTlYtIFZHQVNub29wLSBQYXJFcnItIFN0ZXBwaW5nLSBT
RVJSKyBGYXN0QjJCLSBEaXNJTlR4Kw0KCVN0YXR1czogQ2FwKyA2Nk1IeisgVURGLSBGYXN0
QjJCLSBQYXJFcnItIERFVlNFTD1tZWRpdW0gPlRBYm9ydC0gPFRBYm9ydC0gPE1BYm9ydC0g
PlNFUlItIDxQRVJSLSBJTlR4LQ0KCUxhdGVuY3k6IDY0LCBDYWNoZSBMaW5lIFNpemU6IDY0
IGJ5dGVzDQoJSW50ZXJydXB0OiBwaW4gQSByb3V0ZWQgdG8gSVJRIDEyMA0KCVJlZ2lvbiAw
OiBJL08gcG9ydHMgYXQgNzAwMCBbc2l6ZT04XQ0KCVJlZ2lvbiAxOiBJL08gcG9ydHMgYXQg
NjAwMCBbc2l6ZT00XQ0KCVJlZ2lvbiAyOiBJL08gcG9ydHMgYXQgNTAwMCBbc2l6ZT04XQ0K
CVJlZ2lvbiAzOiBJL08gcG9ydHMgYXQgMzAwMCBbc2l6ZT00XQ0KCVJlZ2lvbiA0OiBJL08g
cG9ydHMgYXQgMjAwMCBbc2l6ZT0xNl0NCglSZWdpb24gNTogTWVtb3J5IGF0IGY5M2ZmMDAw
ICgzMi1iaXQsIG5vbi1wcmVmZXRjaGFibGUpIFtzaXplPTFLXQ0KCUNhcGFiaWxpdGllczog
WzUwXSBNU0k6IEVuYWJsZSsgQ291bnQ9MS84IE1hc2thYmxlLSA2NGJpdCsNCgkJQWRkcmVz
czogMDAwMDAwMDBmZWUwMjAwYyAgRGF0YTogNDFiOQ0KCUNhcGFiaWxpdGllczogWzcwXSBT
QVRBIEhCQSB2MS4wIEluQ2ZnU3BhY2UNCglDYXBhYmlsaXRpZXM6IFthNF0gUENJIEFkdmFu
Y2VkIEZlYXR1cmVzDQoJCUFGQ2FwOiBUUCsgRkxSKw0KCQlBRkN0cmw6IEZMUi0NCgkJQUZT
dGF0dXM6IFRQKw0KCUtlcm5lbCBkcml2ZXIgaW4gdXNlOiBhaGNpDQoNCjAwOjEyLjAgVVNC
IGNvbnRyb2xsZXIgWzBjMDNdOiBBVEkgVGVjaG5vbG9naWVzIEluYyBTQjd4MC9TQjh4MC9T
Qjl4MCBVU0IgT0hDSTAgQ29udHJvbGxlciBbMTAwMjo0Mzk3XSAocHJvZy1pZiAxMCBbT0hD
SV0pDQoJU3Vic3lzdGVtOiBNaWNyby1TdGFyIEludGVybmF0aW9uYWwgQ28uLCBMdGQuIERl
dmljZSBbMTQ2Mjo3NjQwXQ0KCUNvbnRyb2w6IEkvTysgTWVtKyBCdXNNYXN0ZXIrIFNwZWND
eWNsZS0gTWVtV0lOVisgVkdBU25vb3AtIFBhckVyci0gU3RlcHBpbmctIFNFUlIrIEZhc3RC
MkItIERpc0lOVHgtDQoJU3RhdHVzOiBDYXAtIDY2TUh6KyBVREYtIEZhc3RCMkIrIFBhckVy
ci0gREVWU0VMPW1lZGl1bSA+VEFib3J0LSA8VEFib3J0LSA8TUFib3J0LSA+U0VSUi0gPFBF
UlItIElOVHgtDQoJTGF0ZW5jeTogNjQsIENhY2hlIExpbmUgU2l6ZTogNjQgYnl0ZXMNCglJ
bnRlcnJ1cHQ6IHBpbiBBIHJvdXRlZCB0byBJUlEgMTgNCglSZWdpb24gMDogTWVtb3J5IGF0
IGY5M2ZiMDAwICgzMi1iaXQsIG5vbi1wcmVmZXRjaGFibGUpIFtzaXplPTRLXQ0KCUtlcm5l
bCBkcml2ZXIgaW4gdXNlOiBvaGNpX2hjZA0KDQowMDoxMi4yIFVTQiBjb250cm9sbGVyIFsw
YzAzXTogQVRJIFRlY2hub2xvZ2llcyBJbmMgU0I3eDAvU0I4eDAvU0I5eDAgVVNCIEVIQ0kg
Q29udHJvbGxlciBbMTAwMjo0Mzk2XSAocHJvZy1pZiAyMCBbRUhDSV0pDQoJU3Vic3lzdGVt
OiBNaWNyby1TdGFyIEludGVybmF0aW9uYWwgQ28uLCBMdGQuIERldmljZSBbMTQ2Mjo3NjQw
XQ0KCUNvbnRyb2w6IEkvTy0gTWVtKyBCdXNNYXN0ZXIrIFNwZWNDeWNsZS0gTWVtV0lOVisg
VkdBU25vb3AtIFBhckVyci0gU3RlcHBpbmctIFNFUlIrIEZhc3RCMkItIERpc0lOVHgtDQoJ
U3RhdHVzOiBDYXArIDY2TUh6KyBVREYtIEZhc3RCMkIrIFBhckVyci0gREVWU0VMPW1lZGl1
bSA+VEFib3J0LSA8VEFib3J0LSA8TUFib3J0LSA+U0VSUi0gPFBFUlItIElOVHgtDQoJTGF0
ZW5jeTogNjQsIENhY2hlIExpbmUgU2l6ZTogNjQgYnl0ZXMNCglJbnRlcnJ1cHQ6IHBpbiBC
IHJvdXRlZCB0byBJUlEgMTcNCglSZWdpb24gMDogTWVtb3J5IGF0IGY5M2ZmNDAwICgzMi1i
aXQsIG5vbi1wcmVmZXRjaGFibGUpIFtzaXplPTI1Nl0NCglDYXBhYmlsaXRpZXM6IFtjMF0g
UG93ZXIgTWFuYWdlbWVudCB2ZXJzaW9uIDINCgkJRmxhZ3M6IFBNRUNsay0gRFNJLSBEMSsg
RDIrIEF1eEN1cnJlbnQ9MG1BIFBNRShEMCssRDErLEQyKyxEM2hvdCssRDNjb2xkLSkNCgkJ
U3RhdHVzOiBEMCBOb1NvZnRSc3QtIFBNRS1FbmFibGUtIERTZWw9MCBEU2NhbGU9MCBQTUUt
DQoJCUJyaWRnZTogUE0tIEIzKw0KCUNhcGFiaWxpdGllczogW2U0XSBEZWJ1ZyBwb3J0OiBC
QVI9MSBvZmZzZXQ9MDBlMA0KCUtlcm5lbCBkcml2ZXIgaW4gdXNlOiBlaGNpX2hjZA0KDQow
MDoxMy4wIFVTQiBjb250cm9sbGVyIFswYzAzXTogQVRJIFRlY2hub2xvZ2llcyBJbmMgU0I3
eDAvU0I4eDAvU0I5eDAgVVNCIE9IQ0kwIENvbnRyb2xsZXIgWzEwMDI6NDM5N10gKHByb2ct
aWYgMTAgW09IQ0ldKQ0KCVN1YnN5c3RlbTogTWljcm8tU3RhciBJbnRlcm5hdGlvbmFsIENv
LiwgTHRkLiBEZXZpY2UgWzE0NjI6NzY0MF0NCglDb250cm9sOiBJL08rIE1lbSsgQnVzTWFz
dGVyKyBTcGVjQ3ljbGUtIE1lbVdJTlYrIFZHQVNub29wLSBQYXJFcnItIFN0ZXBwaW5nLSBT
RVJSKyBGYXN0QjJCLSBEaXNJTlR4LQ0KCVN0YXR1czogQ2FwLSA2Nk1IeisgVURGLSBGYXN0
QjJCKyBQYXJFcnItIERFVlNFTD1tZWRpdW0gPlRBYm9ydC0gPFRBYm9ydC0gPE1BYm9ydC0g
PlNFUlItIDxQRVJSLSBJTlR4LQ0KCUxhdGVuY3k6IDY0LCBDYWNoZSBMaW5lIFNpemU6IDY0
IGJ5dGVzDQoJSW50ZXJydXB0OiBwaW4gQSByb3V0ZWQgdG8gSVJRIDE4DQoJUmVnaW9uIDA6
IE1lbW9yeSBhdCBmOTNmYzAwMCAoMzItYml0LCBub24tcHJlZmV0Y2hhYmxlKSBbc2l6ZT00
S10NCglLZXJuZWwgZHJpdmVyIGluIHVzZTogb2hjaV9oY2QNCg0KMDA6MTMuMiBVU0IgY29u
dHJvbGxlciBbMGMwM106IEFUSSBUZWNobm9sb2dpZXMgSW5jIFNCN3gwL1NCOHgwL1NCOXgw
IFVTQiBFSENJIENvbnRyb2xsZXIgWzEwMDI6NDM5Nl0gKHByb2ctaWYgMjAgW0VIQ0ldKQ0K
CVN1YnN5c3RlbTogTWljcm8tU3RhciBJbnRlcm5hdGlvbmFsIENvLiwgTHRkLiBEZXZpY2Ug
WzE0NjI6NzY0MF0NCglDb250cm9sOiBJL08tIE1lbSsgQnVzTWFzdGVyKyBTcGVjQ3ljbGUt
IE1lbVdJTlYrIFZHQVNub29wLSBQYXJFcnItIFN0ZXBwaW5nLSBTRVJSKyBGYXN0QjJCLSBE
aXNJTlR4LQ0KCVN0YXR1czogQ2FwKyA2Nk1IeisgVURGLSBGYXN0QjJCKyBQYXJFcnItIERF
VlNFTD1tZWRpdW0gPlRBYm9ydC0gPFRBYm9ydC0gPE1BYm9ydC0gPlNFUlItIDxQRVJSLSBJ
TlR4LQ0KCUxhdGVuY3k6IDY0LCBDYWNoZSBMaW5lIFNpemU6IDY0IGJ5dGVzDQoJSW50ZXJy
dXB0OiBwaW4gQiByb3V0ZWQgdG8gSVJRIDE3DQoJUmVnaW9uIDA6IE1lbW9yeSBhdCBmOTNm
ZjgwMCAoMzItYml0LCBub24tcHJlZmV0Y2hhYmxlKSBbc2l6ZT0yNTZdDQoJQ2FwYWJpbGl0
aWVzOiBbYzBdIFBvd2VyIE1hbmFnZW1lbnQgdmVyc2lvbiAyDQoJCUZsYWdzOiBQTUVDbGst
IERTSS0gRDErIEQyKyBBdXhDdXJyZW50PTBtQSBQTUUoRDArLEQxKyxEMissRDNob3QrLEQz
Y29sZC0pDQoJCVN0YXR1czogRDAgTm9Tb2Z0UnN0LSBQTUUtRW5hYmxlLSBEU2VsPTAgRFNj
YWxlPTAgUE1FLQ0KCQlCcmlkZ2U6IFBNLSBCMysNCglDYXBhYmlsaXRpZXM6IFtlNF0gRGVi
dWcgcG9ydDogQkFSPTEgb2Zmc2V0PTAwZTANCglLZXJuZWwgZHJpdmVyIGluIHVzZTogZWhj
aV9oY2QNCg0KMDA6MTQuMCBTTUJ1cyBbMGMwNV06IEFUSSBUZWNobm9sb2dpZXMgSW5jIFNC
eDAwIFNNQnVzIENvbnRyb2xsZXIgWzEwMDI6NDM4NV0gKHJldiA0MSkNCglDb250cm9sOiBJ
L08rIE1lbSsgQnVzTWFzdGVyLSBTcGVjQ3ljbGUtIE1lbVdJTlYtIFZHQVNub29wLSBQYXJF
cnItIFN0ZXBwaW5nLSBTRVJSLSBGYXN0QjJCLSBEaXNJTlR4Kw0KCVN0YXR1czogQ2FwLSA2
Nk1IeisgVURGLSBGYXN0QjJCLSBQYXJFcnItIERFVlNFTD1tZWRpdW0gPlRBYm9ydC0gPFRB
Ym9ydC0gPE1BYm9ydC0gPlNFUlItIDxQRVJSLSBJTlR4LQ0KDQowMDoxNC4zIElTQSBicmlk
Z2UgWzA2MDFdOiBBVEkgVGVjaG5vbG9naWVzIEluYyBTQjd4MC9TQjh4MC9TQjl4MCBMUEMg
aG9zdCBjb250cm9sbGVyIFsxMDAyOjQzOWRdIChyZXYgNDApDQoJU3Vic3lzdGVtOiBNaWNy
by1TdGFyIEludGVybmF0aW9uYWwgQ28uLCBMdGQuIERldmljZSBbMTQ2Mjo3NjQwXQ0KCUNv
bnRyb2w6IEkvTysgTWVtKyBCdXNNYXN0ZXIrIFNwZWNDeWNsZSsgTWVtV0lOVi0gVkdBU25v
b3AtIFBhckVyci0gU3RlcHBpbmctIFNFUlItIEZhc3RCMkItIERpc0lOVHgtDQoJU3RhdHVz
OiBDYXAtIDY2TUh6KyBVREYtIEZhc3RCMkItIFBhckVyci0gREVWU0VMPW1lZGl1bSA+VEFi
b3J0LSA8VEFib3J0LSA8TUFib3J0LSA+U0VSUi0gPFBFUlItIElOVHgtDQoJTGF0ZW5jeTog
MA0KDQowMDoxNC40IFBDSSBicmlkZ2UgWzA2MDRdOiBBVEkgVGVjaG5vbG9naWVzIEluYyBT
QngwMCBQQ0kgdG8gUENJIEJyaWRnZSBbMTAwMjo0Mzg0XSAocmV2IDQwKSAocHJvZy1pZiAw
MCBbTm9ybWFsIGRlY29kZV0pDQoJQ29udHJvbDogSS9PKyBNZW0tIEJ1c01hc3RlcisgU3Bl
Y0N5Y2xlLSBNZW1XSU5WLSBWR0FTbm9vcC0gUGFyRXJyLSBTdGVwcGluZy0gU0VSUisgRmFz
dEIyQi0gRGlzSU5UeC0NCglTdGF0dXM6IENhcC0gNjZNSHorIFVERi0gRmFzdEIyQisgUGFy
RXJyLSBERVZTRUw9bWVkaXVtID5UQWJvcnQtIDxUQWJvcnQtIDxNQWJvcnQtID5TRVJSLSA8
UEVSUi0gSU5UeC0NCglMYXRlbmN5OiA2NA0KCUJ1czogcHJpbWFyeT0wMCwgc2Vjb25kYXJ5
PTAzLCBzdWJvcmRpbmF0ZT0wMywgc2VjLWxhdGVuY3k9NjQNCglJL08gYmVoaW5kIGJyaWRn
ZTogMDAwMGEwMDAtMDAwMGFmZmYNCglNZW1vcnkgYmVoaW5kIGJyaWRnZTogZmZmMDAwMDAt
MDAwZmZmZmYNCglQcmVmZXRjaGFibGUgbWVtb3J5IGJlaGluZCBicmlkZ2U6IGZmZjAwMDAw
LTAwMGZmZmZmDQoJU2Vjb25kYXJ5IHN0YXR1czogNjZNSHotIEZhc3RCMkIrIFBhckVyci0g
REVWU0VMPW1lZGl1bSA+VEFib3J0LSA8VEFib3J0LSA8TUFib3J0LSA8U0VSUi0gPFBFUlIt
DQoJQnJpZGdlQ3RsOiBQYXJpdHkrIFNFUlIrIE5vSVNBKyBWR0EtIE1BYm9ydC0gPlJlc2V0
LSBGYXN0QjJCLQ0KCQlQcmlEaXNjVG1yLSBTZWNEaXNjVG1yLSBEaXNjVG1yU3RhdC0gRGlz
Y1RtclNFUlJFbi0NCg0KMDA6MTQuNSBVU0IgY29udHJvbGxlciBbMGMwM106IEFUSSBUZWNo
bm9sb2dpZXMgSW5jIFNCN3gwL1NCOHgwL1NCOXgwIFVTQiBPSENJMiBDb250cm9sbGVyIFsx
MDAyOjQzOTldIChwcm9nLWlmIDEwIFtPSENJXSkNCglTdWJzeXN0ZW06IE1pY3JvLVN0YXIg
SW50ZXJuYXRpb25hbCBDby4sIEx0ZC4gRGV2aWNlIFsxNDYyOjc2NDBdDQoJQ29udHJvbDog
SS9PKyBNZW0rIEJ1c01hc3RlcisgU3BlY0N5Y2xlLSBNZW1XSU5WKyBWR0FTbm9vcC0gUGFy
RXJyLSBTdGVwcGluZy0gU0VSUisgRmFzdEIyQi0gRGlzSU5UeC0NCglTdGF0dXM6IENhcC0g
NjZNSHorIFVERi0gRmFzdEIyQisgUGFyRXJyLSBERVZTRUw9bWVkaXVtID5UQWJvcnQtIDxU
QWJvcnQtIDxNQWJvcnQtID5TRVJSLSA8UEVSUi0gSU5UeC0NCglMYXRlbmN5OiA2NCwgQ2Fj
aGUgTGluZSBTaXplOiA2NCBieXRlcw0KCUludGVycnVwdDogcGluIEMgcm91dGVkIHRvIElS
USAxOA0KCVJlZ2lvbiAwOiBNZW1vcnkgYXQgZjkzZmQwMDAgKDMyLWJpdCwgbm9uLXByZWZl
dGNoYWJsZSkgW3NpemU9NEtdDQoJS2VybmVsIGRyaXZlciBpbiB1c2U6IG9oY2lfaGNkDQoN
CjAwOjE1LjAgUENJIGJyaWRnZSBbMDYwNF06IEFUSSBUZWNobm9sb2dpZXMgSW5jIFNCNzAw
L1NCODAwL1NCOTAwIFBDSSB0byBQQ0kgYnJpZGdlIChQQ0lFIHBvcnQgMCkgWzEwMDI6NDNh
MF0gKHByb2ctaWYgMDAgW05vcm1hbCBkZWNvZGVdKQ0KCUNvbnRyb2w6IEkvTy0gTWVtLSBC
dXNNYXN0ZXIrIFNwZWNDeWNsZS0gTWVtV0lOVi0gVkdBU25vb3AtIFBhckVyci0gU3RlcHBp
bmctIFNFUlIrIEZhc3RCMkItIERpc0lOVHgrDQoJU3RhdHVzOiBDYXArIDY2TUh6LSBVREYt
IEZhc3RCMkItIFBhckVyci0gREVWU0VMPWZhc3QgPlRBYm9ydC0gPFRBYm9ydC0gPE1BYm9y
dC0gPlNFUlItIDxQRVJSLSBJTlR4LQ0KCUxhdGVuY3k6IDAsIENhY2hlIExpbmUgU2l6ZTog
NjQgYnl0ZXMNCglCdXM6IHByaW1hcnk9MDAsIHNlY29uZGFyeT0wMiwgc3Vib3JkaW5hdGU9
MDIsIHNlYy1sYXRlbmN5PTANCglJL08gYmVoaW5kIGJyaWRnZTogMDAwMGYwMDAtMDAwMDBm
ZmYNCglNZW1vcnkgYmVoaW5kIGJyaWRnZTogZmZmMDAwMDAtMDAwZmZmZmYNCglQcmVmZXRj
aGFibGUgbWVtb3J5IGJlaGluZCBicmlkZ2U6IDAwMDAwMDAwZmZmMDAwMDAtMDAwMDAwMDAw
MDBmZmZmZg0KCVNlY29uZGFyeSBzdGF0dXM6IDY2TUh6LSBGYXN0QjJCLSBQYXJFcnItIERF
VlNFTD1mYXN0ID5UQWJvcnQtIDxUQWJvcnQtIDxNQWJvcnQtIDxTRVJSLSA8UEVSUi0NCglC
cmlkZ2VDdGw6IFBhcml0eSsgU0VSUisgTm9JU0ErIFZHQS0gTUFib3J0LSA+UmVzZXQtIEZh
c3RCMkItDQoJCVByaURpc2NUbXItIFNlY0Rpc2NUbXItIERpc2NUbXJTdGF0LSBEaXNjVG1y
U0VSUkVuLQ0KCUNhcGFiaWxpdGllczogWzUwXSBQb3dlciBNYW5hZ2VtZW50IHZlcnNpb24g
Mw0KCQlGbGFnczogUE1FQ2xrLSBEU0ktIEQxKyBEMisgQXV4Q3VycmVudD0wbUEgUE1FKEQw
LSxEMS0sRDItLEQzaG90LSxEM2NvbGQtKQ0KCQlTdGF0dXM6IEQwIE5vU29mdFJzdC0gUE1F
LUVuYWJsZS0gRFNlbD0wIERTY2FsZT0wIFBNRS0NCglDYXBhYmlsaXRpZXM6IFs1OF0gRXhw
cmVzcyAodjIpIFJvb3QgUG9ydCAoU2xvdCspLCBNU0kgMDANCgkJRGV2Q2FwOglNYXhQYXls
b2FkIDEyOCBieXRlcywgUGhhbnRGdW5jIDAsIExhdGVuY3kgTDBzIDw2NG5zLCBMMSA8MXVz
DQoJCQlFeHRUYWcrIFJCRSsgRkxSZXNldC0NCgkJRGV2Q3RsOglSZXBvcnQgZXJyb3JzOiBD
b3JyZWN0YWJsZS0gTm9uLUZhdGFsLSBGYXRhbC0gVW5zdXBwb3J0ZWQtDQoJCQlSbHhkT3Jk
KyBFeHRUYWctIFBoYW50RnVuYy0gQXV4UHdyLSBOb1Nub29wKw0KCQkJTWF4UGF5bG9hZCAx
MjggYnl0ZXMsIE1heFJlYWRSZXEgMTI4IGJ5dGVzDQoJCURldlN0YToJQ29yckVyci0gVW5j
b3JyRXJyLSBGYXRhbEVyci0gVW5zdXBwUmVxLSBBdXhQd3ItIFRyYW5zUGVuZC0NCgkJTG5r
Q2FwOglQb3J0ICMyNDcsIFNwZWVkIDIuNUdUL3MsIFdpZHRoIHgxLCBBU1BNIEwwcyBMMSwg
TGF0ZW5jeSBMMCA8NjRucywgTDEgPDF1cw0KCQkJQ2xvY2tQTS0gU3VycHJpc2UtIExMQWN0
UmVwKyBCd05vdCsNCgkJTG5rQ3RsOglBU1BNIERpc2FibGVkOyBSQ0IgNjQgYnl0ZXMgRGlz
YWJsZWQtIFJldHJhaW4tIENvbW1DbGstDQoJCQlFeHRTeW5jaC0gQ2xvY2tQTS0gQXV0V2lk
RGlzLSBCV0ludC0gQXV0QldJbnQtDQoJCUxua1N0YToJU3BlZWQgdW5rbm93biwgV2lkdGgg
eDE2LCBUckVyci0gVHJhaW4tIFNsb3RDbGsrIERMQWN0aXZlLSBCV01nbXQtIEFCV01nbXQt
DQoJCVNsdENhcDoJQXR0bkJ0bi0gUHdyQ3RybC0gTVJMLSBBdHRuSW5kLSBQd3JJbmQtIEhv
dFBsdWctIFN1cnByaXNlLQ0KCQkJU2xvdCAjMzIsIFBvd2VyTGltaXQgNzUuMDAwVzsgSW50
ZXJsb2NrLSBOb0NvbXBsKw0KCQlTbHRDdGw6CUVuYWJsZTogQXR0bkJ0bi0gUHdyRmx0LSBN
UkwtIFByZXNEZXQtIENtZENwbHQtIEhQSXJxLSBMaW5rQ2hnLQ0KCQkJQ29udHJvbDogQXR0
bkluZCBVbmtub3duLCBQd3JJbmQgVW5rbm93biwgUG93ZXItIEludGVybG9jay0NCgkJU2x0
U3RhOglTdGF0dXM6IEF0dG5CdG4tIFBvd2VyRmx0LSBNUkwtIENtZENwbHQtIFByZXNEZXQt
IEludGVybG9jay0NCgkJCUNoYW5nZWQ6IE1STC0gUHJlc0RldC0gTGlua1N0YXRlLQ0KCQlS
b290Q3RsOiBFcnJDb3JyZWN0YWJsZS0gRXJyTm9uLUZhdGFsLSBFcnJGYXRhbC0gUE1FSW50
RW5hLSBDUlNWaXNpYmxlLQ0KCQlSb290Q2FwOiBDUlNWaXNpYmxlLQ0KCQlSb290U3RhOiBQ
TUUgUmVxSUQgMDAwMCwgUE1FU3RhdHVzLSBQTUVQZW5kaW5nLQ0KCQlEZXZDYXAyOiBDb21w
bGV0aW9uIFRpbWVvdXQ6IFJhbmdlIEFCQ0QsIFRpbWVvdXREaXMrIEFSSUZ3ZC0NCgkJRGV2
Q3RsMjogQ29tcGxldGlvbiBUaW1lb3V0OiA2NW1zIHRvIDIxMG1zLCBUaW1lb3V0RGlzLSBB
UklGd2QtDQoJCUxua0N0bDI6IFRhcmdldCBMaW5rIFNwZWVkOiAyLjVHVC9zLCBFbnRlckNv
bXBsaWFuY2UtIFNwZWVkRGlzLSwgU2VsZWN0YWJsZSBEZS1lbXBoYXNpczogLTMuNWRCDQoJ
CQkgVHJhbnNtaXQgTWFyZ2luOiBOb3JtYWwgT3BlcmF0aW5nIFJhbmdlLCBFbnRlck1vZGlm
aWVkQ29tcGxpYW5jZS0gQ29tcGxpYW5jZVNPUy0NCgkJCSBDb21wbGlhbmNlIERlLWVtcGhh
c2lzOiAtNmRCDQoJCUxua1N0YTI6IEN1cnJlbnQgRGUtZW1waGFzaXMgTGV2ZWw6IC02ZEIN
CglDYXBhYmlsaXRpZXM6IFthMF0gTVNJOiBFbmFibGUrIENvdW50PTEvMSBNYXNrYWJsZS0g
NjRiaXQrDQoJCUFkZHJlc3M6IDAwMDAwMDAwZmVlM2YwMGMgIERhdGE6IDQxOTENCglDYXBh
YmlsaXRpZXM6IFtiMF0gU3Vic3lzdGVtOiBBVEkgVGVjaG5vbG9naWVzIEluYyBEZXZpY2Ug
WzEwMDI6MDAwMF0NCglDYXBhYmlsaXRpZXM6IFtiOF0gSHlwZXJUcmFuc3BvcnQ6IE1TSSBN
YXBwaW5nIEVuYWJsZSsgRml4ZWQrDQoJQ2FwYWJpbGl0aWVzOiBbMTAwIHYxXSBWZW5kb3Ig
U3BlY2lmaWMgSW5mb3JtYXRpb246IElEPTAwMDEgUmV2PTEgTGVuPTAxMCA8Pz4NCglLZXJu
ZWwgZHJpdmVyIGluIHVzZTogcGNpZXBvcnQNCg0KMDA6MTYuMCBVU0IgY29udHJvbGxlciBb
MGMwM106IEFUSSBUZWNobm9sb2dpZXMgSW5jIFNCN3gwL1NCOHgwL1NCOXgwIFVTQiBPSENJ
MCBDb250cm9sbGVyIFsxMDAyOjQzOTddIChwcm9nLWlmIDEwIFtPSENJXSkNCglTdWJzeXN0
ZW06IE1pY3JvLVN0YXIgSW50ZXJuYXRpb25hbCBDby4sIEx0ZC4gRGV2aWNlIFsxNDYyOjc2
NDBdDQoJQ29udHJvbDogSS9PKyBNZW0rIEJ1c01hc3RlcisgU3BlY0N5Y2xlLSBNZW1XSU5W
KyBWR0FTbm9vcC0gUGFyRXJyLSBTdGVwcGluZy0gU0VSUisgRmFzdEIyQi0gRGlzSU5UeC0N
CglTdGF0dXM6IENhcC0gNjZNSHorIFVERi0gRmFzdEIyQisgUGFyRXJyLSBERVZTRUw9bWVk
aXVtID5UQWJvcnQtIDxUQWJvcnQtIDxNQWJvcnQtID5TRVJSLSA8UEVSUi0gSU5UeC0NCglM
YXRlbmN5OiA2NCwgQ2FjaGUgTGluZSBTaXplOiA2NCBieXRlcw0KCUludGVycnVwdDogcGlu
IEEgcm91dGVkIHRvIElSUSAxOA0KCVJlZ2lvbiAwOiBNZW1vcnkgYXQgZjkzZmUwMDAgKDMy
LWJpdCwgbm9uLXByZWZldGNoYWJsZSkgW3NpemU9NEtdDQoJS2VybmVsIGRyaXZlciBpbiB1
c2U6IG9oY2lfaGNkDQoNCjAwOjE2LjIgVVNCIGNvbnRyb2xsZXIgWzBjMDNdOiBBVEkgVGVj
aG5vbG9naWVzIEluYyBTQjd4MC9TQjh4MC9TQjl4MCBVU0IgRUhDSSBDb250cm9sbGVyIFsx
MDAyOjQzOTZdIChwcm9nLWlmIDIwIFtFSENJXSkNCglTdWJzeXN0ZW06IE1pY3JvLVN0YXIg
SW50ZXJuYXRpb25hbCBDby4sIEx0ZC4gRGV2aWNlIFsxNDYyOjc2NDBdDQoJQ29udHJvbDog
SS9PLSBNZW0rIEJ1c01hc3RlcisgU3BlY0N5Y2xlLSBNZW1XSU5WKyBWR0FTbm9vcC0gUGFy
RXJyLSBTdGVwcGluZy0gU0VSUisgRmFzdEIyQi0gRGlzSU5UeC0NCglTdGF0dXM6IENhcCsg
NjZNSHorIFVERi0gRmFzdEIyQisgUGFyRXJyLSBERVZTRUw9bWVkaXVtID5UQWJvcnQtIDxU
QWJvcnQtIDxNQWJvcnQtID5TRVJSLSA8UEVSUi0gSU5UeC0NCglMYXRlbmN5OiA2NCwgQ2Fj
aGUgTGluZSBTaXplOiA2NCBieXRlcw0KCUludGVycnVwdDogcGluIEIgcm91dGVkIHRvIElS
USAxNw0KCVJlZ2lvbiAwOiBNZW1vcnkgYXQgZjkzZmZjMDAgKDMyLWJpdCwgbm9uLXByZWZl
dGNoYWJsZSkgW3NpemU9MjU2XQ0KCUNhcGFiaWxpdGllczogW2MwXSBQb3dlciBNYW5hZ2Vt
ZW50IHZlcnNpb24gMg0KCQlGbGFnczogUE1FQ2xrLSBEU0ktIEQxKyBEMisgQXV4Q3VycmVu
dD0wbUEgUE1FKEQwKyxEMSssRDIrLEQzaG90KyxEM2NvbGQtKQ0KCQlTdGF0dXM6IEQwIE5v
U29mdFJzdC0gUE1FLUVuYWJsZS0gRFNlbD0wIERTY2FsZT0wIFBNRS0NCgkJQnJpZGdlOiBQ
TS0gQjMrDQoJQ2FwYWJpbGl0aWVzOiBbZTRdIERlYnVnIHBvcnQ6IEJBUj0xIG9mZnNldD0w
MGUwDQoJS2VybmVsIGRyaXZlciBpbiB1c2U6IGVoY2lfaGNkDQoNCjAwOjE4LjAgSG9zdCBi
cmlkZ2UgWzA2MDBdOiBBZHZhbmNlZCBNaWNybyBEZXZpY2VzIFtBTURdIEZhbWlseSAxMGgg
UHJvY2Vzc29yIEh5cGVyVHJhbnNwb3J0IENvbmZpZ3VyYXRpb24gWzEwMjI6MTIwMF0NCglD
b250cm9sOiBJL08tIE1lbS0gQnVzTWFzdGVyLSBTcGVjQ3ljbGUtIE1lbVdJTlYtIFZHQVNu
b29wLSBQYXJFcnItIFN0ZXBwaW5nLSBTRVJSLSBGYXN0QjJCLSBEaXNJTlR4LQ0KCVN0YXR1
czogQ2FwKyA2Nk1Iei0gVURGLSBGYXN0QjJCLSBQYXJFcnItIERFVlNFTD1mYXN0ID5UQWJv
cnQtIDxUQWJvcnQtIDxNQWJvcnQtID5TRVJSLSA8UEVSUi0gSU5UeC0NCglDYXBhYmlsaXRp
ZXM6IFs4MF0gSHlwZXJUcmFuc3BvcnQ6IEhvc3Qgb3IgU2Vjb25kYXJ5IEludGVyZmFjZQ0K
CQlDb21tYW5kOiBXYXJtUnN0KyBEYmxFbmQtIERldk51bT0wIENoYWluU2lkZS0gSG9zdEhp
ZGUrIFNsYXZlLSA8RU9DRXJyLSBEVUwtDQoJCUxpbmsgQ29udHJvbDogQ0ZsRS0gQ1NULSBD
RkUtIDxMa0ZhaWwtIEluaXQrIEVPQy0gVFhPLSA8Q1JDRXJyPTAgSXNvY0VuLSBMU0VuKyBF
eHRDVEwtIDY0Yi0NCgkJTGluayBDb25maWc6IE1MV0k9MTZiaXQgRHdGY0luLSBNTFdPPTE2
Yml0IER3RmNPdXQtIExXST0xNmJpdCBEd0ZjSW5Fbi0gTFdPPTE2Yml0IER3RmNPdXRFbi0N
CgkJUmV2aXNpb24gSUQ6IDMuMDANCgkJTGluayBGcmVxdWVuY3k6IFtiXQ0KCQlMaW5rIEVy
cm9yOiA8UHJvdC0gPE92ZmwtIDxFT0MtIENUTFRtLQ0KCQlMaW5rIEZyZXF1ZW5jeSBDYXBh
YmlsaXR5OiAyMDBNSHorIDMwME1Iei0gNDAwTUh6KyA1MDBNSHotIDYwME1IeisgODAwTUh6
KyAxLjBHSHorIDEuMkdIeisgMS40R0h6LSAxLjZHSHotIFZlbmQtDQoJCUZlYXR1cmUgQ2Fw
YWJpbGl0eTogSXNvY0ZDKyBMRFRTVE9QKyBDUkNUTS0gRUNUTFQtIDY0YkErIFVJRFJELSBF
eHRSUy0gVUNuZkUtDQoNCjAwOjE4LjEgSG9zdCBicmlkZ2UgWzA2MDBdOiBBZHZhbmNlZCBN
aWNybyBEZXZpY2VzIFtBTURdIEZhbWlseSAxMGggUHJvY2Vzc29yIEFkZHJlc3MgTWFwIFsx
MDIyOjEyMDFdDQoJQ29udHJvbDogSS9PLSBNZW0tIEJ1c01hc3Rlci0gU3BlY0N5Y2xlLSBN
ZW1XSU5WLSBWR0FTbm9vcC0gUGFyRXJyLSBTdGVwcGluZy0gU0VSUi0gRmFzdEIyQi0gRGlz
SU5UeC0NCglTdGF0dXM6IENhcC0gNjZNSHotIFVERi0gRmFzdEIyQi0gUGFyRXJyLSBERVZT
RUw9ZmFzdCA+VEFib3J0LSA8VEFib3J0LSA8TUFib3J0LSA+U0VSUi0gPFBFUlItIElOVHgt
DQoNCjAwOjE4LjIgSG9zdCBicmlkZ2UgWzA2MDBdOiBBZHZhbmNlZCBNaWNybyBEZXZpY2Vz
IFtBTURdIEZhbWlseSAxMGggUHJvY2Vzc29yIERSQU0gQ29udHJvbGxlciBbMTAyMjoxMjAy
XQ0KCUNvbnRyb2w6IEkvTy0gTWVtLSBCdXNNYXN0ZXItIFNwZWNDeWNsZS0gTWVtV0lOVi0g
VkdBU25vb3AtIFBhckVyci0gU3RlcHBpbmctIFNFUlItIEZhc3RCMkItIERpc0lOVHgtDQoJ
U3RhdHVzOiBDYXAtIDY2TUh6LSBVREYtIEZhc3RCMkItIFBhckVyci0gREVWU0VMPWZhc3Qg
PlRBYm9ydC0gPFRBYm9ydC0gPE1BYm9ydC0gPlNFUlItIDxQRVJSLSBJTlR4LQ0KDQowMDox
OC4zIEhvc3QgYnJpZGdlIFswNjAwXTogQWR2YW5jZWQgTWljcm8gRGV2aWNlcyBbQU1EXSBG
YW1pbHkgMTBoIFByb2Nlc3NvciBNaXNjZWxsYW5lb3VzIENvbnRyb2wgWzEwMjI6MTIwM10N
CglDb250cm9sOiBJL08tIE1lbS0gQnVzTWFzdGVyLSBTcGVjQ3ljbGUtIE1lbVdJTlYtIFZH
QVNub29wLSBQYXJFcnItIFN0ZXBwaW5nLSBTRVJSLSBGYXN0QjJCLSBEaXNJTlR4LQ0KCVN0
YXR1czogQ2FwKyA2Nk1Iei0gVURGLSBGYXN0QjJCLSBQYXJFcnItIERFVlNFTD1mYXN0ID5U
QWJvcnQtIDxUQWJvcnQtIDxNQWJvcnQtID5TRVJSLSA8UEVSUi0gSU5UeC0NCglDYXBhYmls
aXRpZXM6IFtmMF0gU2VjdXJlIGRldmljZSA8Pz4NCglLZXJuZWwgZHJpdmVyIGluIHVzZTog
azEwdGVtcA0KDQowMDoxOC40IEhvc3QgYnJpZGdlIFswNjAwXTogQWR2YW5jZWQgTWljcm8g
RGV2aWNlcyBbQU1EXSBGYW1pbHkgMTBoIFByb2Nlc3NvciBMaW5rIENvbnRyb2wgWzEwMjI6
MTIwNF0NCglDb250cm9sOiBJL08tIE1lbS0gQnVzTWFzdGVyLSBTcGVjQ3ljbGUtIE1lbVdJ
TlYtIFZHQVNub29wLSBQYXJFcnItIFN0ZXBwaW5nLSBTRVJSLSBGYXN0QjJCLSBEaXNJTlR4
LQ0KCVN0YXR1czogQ2FwLSA2Nk1Iei0gVURGLSBGYXN0QjJCLSBQYXJFcnItIERFVlNFTD1m
YXN0ID5UQWJvcnQtIDxUQWJvcnQtIDxNQWJvcnQtID5TRVJSLSA8UEVSUi0gSU5UeC0NCg0K
MDM6MDYuMCBNdWx0aW1lZGlhIGF1ZGlvIGNvbnRyb2xsZXIgWzA0MDFdOiBDLU1lZGlhIEVs
ZWN0cm9uaWNzIEluYyBDTTg3MzggWzEzZjY6MDExMV0gKHJldiAxMCkNCglTdWJzeXN0ZW06
IEMtTWVkaWEgRWxlY3Ryb25pY3MgSW5jIENNSTg3MzgvQzNEWCBQQ0kgQXVkaW8gRGV2aWNl
IFsxM2Y2OjAxMTFdDQoJQ29udHJvbDogSS9PKyBNZW0tIEJ1c01hc3RlcisgU3BlY0N5Y2xl
LSBNZW1XSU5WLSBWR0FTbm9vcC0gUGFyRXJyLSBTdGVwcGluZy0gU0VSUi0gRmFzdEIyQi0g
RGlzSU5UeC0NCglTdGF0dXM6IENhcCsgNjZNSHotIFVERi0gRmFzdEIyQi0gUGFyRXJyLSBE
RVZTRUw9bWVkaXVtID5UQWJvcnQtIDxUQWJvcnQtIDxNQWJvcnQtID5TRVJSLSA8UEVSUi0g
SU5UeC0NCglMYXRlbmN5OiA2NCAoNTAwbnMgbWluLCA2MDAwbnMgbWF4KQ0KCUludGVycnVw
dDogcGluIEEgcm91dGVkIHRvIElSUSAyMg0KCVJlZ2lvbiAwOiBJL08gcG9ydHMgYXQgYTgw
MCBbc2l6ZT0yNTZdDQoJQ2FwYWJpbGl0aWVzOiBbYzBdIFBvd2VyIE1hbmFnZW1lbnQgdmVy
c2lvbiAyDQoJCUZsYWdzOiBQTUVDbGstIERTSS0gRDErIEQyKyBBdXhDdXJyZW50PTBtQSBQ
TUUoRDAtLEQxLSxEMi0sRDNob3QtLEQzY29sZC0pDQoJCVN0YXR1czogRDAgTm9Tb2Z0UnN0
LSBQTUUtRW5hYmxlLSBEU2VsPTAgRFNjYWxlPTAgUE1FLQ0KCUtlcm5lbCBkcml2ZXIgaW4g
dXNlOiBwY2liYWNrDQoNCjA0OjAwLjAgVVNCIGNvbnRyb2xsZXIgWzBjMDNdOiBOZXRNb3Mg
VGVjaG5vbG9neSBNQ1M5OTkwIFBDSWUgdG8gNOKAkFBvcnQgVVNCIDIuMCBIb3N0IENvbnRy
b2xsZXIgWzk3MTA6OTk5MF0gKHByb2ctaWYgMTAgW09IQ0ldKQ0KCVN1YnN5c3RlbTogRGV2
aWNlIFthMDAwOjQwMDBdDQoJQ29udHJvbDogSS9PLSBNZW0tIEJ1c01hc3Rlci0gU3BlY0N5
Y2xlLSBNZW1XSU5WLSBWR0FTbm9vcC0gUGFyRXJyLSBTdGVwcGluZy0gU0VSUi0gRmFzdEIy
Qi0gRGlzSU5UeC0NCglTdGF0dXM6IENhcCsgNjZNSHotIFVERi0gRmFzdEIyQi0gUGFyRXJy
LSBERVZTRUw9ZmFzdCA+VEFib3J0LSA8VEFib3J0LSA8TUFib3J0LSA+U0VSUi0gPFBFUlIt
IElOVHgtDQoJSW50ZXJydXB0OiBwaW4gQSByb3V0ZWQgdG8gSVJRIDQwDQoJUmVnaW9uIDA6
IE1lbW9yeSBhdCBmOTVmODAwMCAoMzItYml0LCBub24tcHJlZmV0Y2hhYmxlKSBbZGlzYWJs
ZWRdIFtzaXplPTRLXQ0KCUNhcGFiaWxpdGllczogWzUwXSBNU0k6IEVuYWJsZS0gQ291bnQ9
MS8xIE1hc2thYmxlLSA2NGJpdCsNCgkJQWRkcmVzczogMDAwMDAwMDAwMDAwMDAwMCAgRGF0
YTogMDAwMA0KCUNhcGFiaWxpdGllczogWzc4XSBQb3dlciBNYW5hZ2VtZW50IHZlcnNpb24g
Mw0KCQlGbGFnczogUE1FQ2xrLSBEU0ktIEQxKyBEMisgQXV4Q3VycmVudD0zNzVtQSBQTUUo
RDArLEQxKyxEMissRDNob3QrLEQzY29sZC0pDQoJCVN0YXR1czogRDAgTm9Tb2Z0UnN0KyBQ
TUUtRW5hYmxlLSBEU2VsPTAgRFNjYWxlPTAgUE1FLQ0KCUNhcGFiaWxpdGllczogWzgwXSBF
eHByZXNzICh2MSkgRW5kcG9pbnQsIE1TSSAwMA0KCQlEZXZDYXA6CU1heFBheWxvYWQgMjU2
IGJ5dGVzLCBQaGFudEZ1bmMgMCwgTGF0ZW5jeSBMMHMgdW5saW1pdGVkLCBMMSB1bmxpbWl0
ZWQNCgkJCUV4dFRhZy0gQXR0bkJ0bi0gQXR0bkluZC0gUHdySW5kLSBSQkUrIEZMUmVzZXQt
DQoJCURldkN0bDoJUmVwb3J0IGVycm9yczogQ29ycmVjdGFibGUtIE5vbi1GYXRhbC0gRmF0
YWwtIFVuc3VwcG9ydGVkLQ0KCQkJUmx4ZE9yZC0gRXh0VGFnLSBQaGFudEZ1bmMtIEF1eFB3
ci0gTm9Tbm9vcCsNCgkJCU1heFBheWxvYWQgMTI4IGJ5dGVzLCBNYXhSZWFkUmVxIDUxMiBi
eXRlcw0KCQlEZXZTdGE6CUNvcnJFcnItIFVuY29yckVyci0gRmF0YWxFcnItIFVuc3VwcFJl
cS0gQXV4UHdyLSBUcmFuc1BlbmQtDQoJCUxua0NhcDoJUG9ydCAjMSwgU3BlZWQgMi41R1Qv
cywgV2lkdGggeDEsIEFTUE0gdW5rbm93biwgTGF0ZW5jeSBMMCA8NjRucywgTDEgdW5saW1p
dGVkDQoJCQlDbG9ja1BNKyBTdXJwcmlzZS0gTExBY3RSZXAtIEJ3Tm90LQ0KCQlMbmtDdGw6
CUFTUE0gRGlzYWJsZWQ7IFJDQiA2NCBieXRlcyBEaXNhYmxlZC0gUmV0cmFpbi0gQ29tbUNs
ay0NCgkJCUV4dFN5bmNoLSBDbG9ja1BNLSBBdXRXaWREaXMtIEJXSW50LSBBdXRCV0ludC0N
CgkJTG5rU3RhOglTcGVlZCAyLjVHVC9zLCBXaWR0aCB4MSwgVHJFcnItIFRyYWluLSBTbG90
Q2xrLSBETEFjdGl2ZS0gQldNZ210LSBBQldNZ210LQ0KCUNhcGFiaWxpdGllczogWzEwMCB2
MV0gVmlydHVhbCBDaGFubmVsDQoJCUNhcHM6CUxQRVZDPTAgUmVmQ2xrPTEwMG5zIFBBVEVu
dHJ5Qml0cz0xDQoJCUFyYjoJRml4ZWQtIFdSUjMyLSBXUlI2NC0gV1JSMTI4LQ0KCQlDdHJs
OglBcmJTZWxlY3Q9Rml4ZWQNCgkJU3RhdHVzOglJblByb2dyZXNzLQ0KCQlWQzA6CUNhcHM6
CVBBVE9mZnNldD0wMCBNYXhUaW1lU2xvdHM9MSBSZWpTbm9vcFRyYW5zLQ0KCQkJQXJiOglG
aXhlZC0gV1JSMzItIFdSUjY0LSBXUlIxMjgtIFRXUlIxMjgtIFdSUjI1Ni0NCgkJCUN0cmw6
CUVuYWJsZSsgSUQ9MCBBcmJTZWxlY3Q9Rml4ZWQgVEMvVkM9ZmYNCgkJCVN0YXR1czoJTmVn
b1BlbmRpbmctIEluUHJvZ3Jlc3MtDQoJS2VybmVsIGRyaXZlciBpbiB1c2U6IHBjaWJhY2sN
Cg0KMDQ6MDAuMSBVU0IgY29udHJvbGxlciBbMGMwM106IE5ldE1vcyBUZWNobm9sb2d5IE1D
Uzk5OTAgUENJZSB0byA04oCQUG9ydCBVU0IgMi4wIEhvc3QgQ29udHJvbGxlciBbOTcxMDo5
OTkwXSAocHJvZy1pZiAyMCBbRUhDSV0pDQoJU3Vic3lzdGVtOiBEZXZpY2UgW2EwMDA6NDAw
MF0NCglDb250cm9sOiBJL08tIE1lbS0gQnVzTWFzdGVyLSBTcGVjQ3ljbGUtIE1lbVdJTlYt
IFZHQVNub29wLSBQYXJFcnItIFN0ZXBwaW5nLSBTRVJSLSBGYXN0QjJCLSBEaXNJTlR4LQ0K
CVN0YXR1czogQ2FwKyA2Nk1Iei0gVURGLSBGYXN0QjJCLSBQYXJFcnItIERFVlNFTD1mYXN0
ID5UQWJvcnQtIDxUQWJvcnQtIDxNQWJvcnQtID5TRVJSLSA8UEVSUi0gSU5UeC0NCglJbnRl
cnJ1cHQ6IHBpbiBBIHJvdXRlZCB0byBJUlEgNDANCglSZWdpb24gMDogTWVtb3J5IGF0IGY5
NWY5MDAwICgzMi1iaXQsIG5vbi1wcmVmZXRjaGFibGUpIFtkaXNhYmxlZF0gW3NpemU9NEtd
DQoJQ2FwYWJpbGl0aWVzOiBbNTBdIE1TSTogRW5hYmxlLSBDb3VudD0xLzEgTWFza2FibGUt
IDY0Yml0Kw0KCQlBZGRyZXNzOiAwMDAwMDAwMDAwMDAwMDAwICBEYXRhOiAwMDAwDQoJQ2Fw
YWJpbGl0aWVzOiBbNzhdIFBvd2VyIE1hbmFnZW1lbnQgdmVyc2lvbiAzDQoJCUZsYWdzOiBQ
TUVDbGstIERTSS0gRDErIEQyKyBBdXhDdXJyZW50PTM3NW1BIFBNRShEMCssRDErLEQyKyxE
M2hvdCssRDNjb2xkLSkNCgkJU3RhdHVzOiBEMCBOb1NvZnRSc3QrIFBNRS1FbmFibGUtIERT
ZWw9MCBEU2NhbGU9MCBQTUUtDQoJQ2FwYWJpbGl0aWVzOiBbODBdIEV4cHJlc3MgKHYxKSBF
bmRwb2ludCwgTVNJIDAwDQoJCURldkNhcDoJTWF4UGF5bG9hZCAyNTYgYnl0ZXMsIFBoYW50
RnVuYyAwLCBMYXRlbmN5IEwwcyB1bmxpbWl0ZWQsIEwxIHVubGltaXRlZA0KCQkJRXh0VGFn
LSBBdHRuQnRuLSBBdHRuSW5kLSBQd3JJbmQtIFJCRSsgRkxSZXNldC0NCgkJRGV2Q3RsOglS
ZXBvcnQgZXJyb3JzOiBDb3JyZWN0YWJsZS0gTm9uLUZhdGFsLSBGYXRhbC0gVW5zdXBwb3J0
ZWQtDQoJCQlSbHhkT3JkLSBFeHRUYWctIFBoYW50RnVuYy0gQXV4UHdyLSBOb1Nub29wKw0K
CQkJTWF4UGF5bG9hZCAxMjggYnl0ZXMsIE1heFJlYWRSZXEgNTEyIGJ5dGVzDQoJCURldlN0
YToJQ29yckVyci0gVW5jb3JyRXJyLSBGYXRhbEVyci0gVW5zdXBwUmVxLSBBdXhQd3ItIFRy
YW5zUGVuZC0NCgkJTG5rQ2FwOglQb3J0ICMxLCBTcGVlZCAyLjVHVC9zLCBXaWR0aCB4MSwg
QVNQTSB1bmtub3duLCBMYXRlbmN5IEwwIDw2NG5zLCBMMSB1bmxpbWl0ZWQNCgkJCUNsb2Nr
UE0rIFN1cnByaXNlLSBMTEFjdFJlcC0gQndOb3QtDQoJCUxua0N0bDoJQVNQTSBEaXNhYmxl
ZDsgUkNCIDY0IGJ5dGVzIERpc2FibGVkLSBSZXRyYWluLSBDb21tQ2xrLQ0KCQkJRXh0U3lu
Y2gtIENsb2NrUE0tIEF1dFdpZERpcy0gQldJbnQtIEF1dEJXSW50LQ0KCQlMbmtTdGE6CVNw
ZWVkIDIuNUdUL3MsIFdpZHRoIHgxLCBUckVyci0gVHJhaW4tIFNsb3RDbGstIERMQWN0aXZl
LSBCV01nbXQtIEFCV01nbXQtDQoJS2VybmVsIGRyaXZlciBpbiB1c2U6IHBjaWJhY2sNCg0K
MDQ6MDAuMiBVU0IgY29udHJvbGxlciBbMGMwM106IE5ldE1vcyBUZWNobm9sb2d5IE1DUzk5
OTAgUENJZSB0byA04oCQUG9ydCBVU0IgMi4wIEhvc3QgQ29udHJvbGxlciBbOTcxMDo5OTkw
XSAocHJvZy1pZiAxMCBbT0hDSV0pDQoJU3Vic3lzdGVtOiBEZXZpY2UgW2EwMDA6NDAwMF0N
CglDb250cm9sOiBJL08tIE1lbS0gQnVzTWFzdGVyLSBTcGVjQ3ljbGUtIE1lbVdJTlYtIFZH
QVNub29wLSBQYXJFcnItIFN0ZXBwaW5nLSBTRVJSLSBGYXN0QjJCLSBEaXNJTlR4LQ0KCVN0
YXR1czogQ2FwKyA2Nk1Iei0gVURGLSBGYXN0QjJCLSBQYXJFcnItIERFVlNFTD1mYXN0ID5U
QWJvcnQtIDxUQWJvcnQtIDxNQWJvcnQtID5TRVJSLSA8UEVSUi0gSU5UeC0NCglJbnRlcnJ1
cHQ6IHBpbiBCIHJvdXRlZCB0byBJUlEgNDENCglSZWdpb24gMDogTWVtb3J5IGF0IGY5NWZh
MDAwICgzMi1iaXQsIG5vbi1wcmVmZXRjaGFibGUpIFtkaXNhYmxlZF0gW3NpemU9NEtdDQoJ
Q2FwYWJpbGl0aWVzOiBbNTBdIE1TSTogRW5hYmxlLSBDb3VudD0xLzEgTWFza2FibGUtIDY0
Yml0Kw0KCQlBZGRyZXNzOiAwMDAwMDAwMDAwMDAwMDAwICBEYXRhOiAwMDAwDQoJQ2FwYWJp
bGl0aWVzOiBbNzhdIFBvd2VyIE1hbmFnZW1lbnQgdmVyc2lvbiAzDQoJCUZsYWdzOiBQTUVD
bGstIERTSS0gRDErIEQyKyBBdXhDdXJyZW50PTM3NW1BIFBNRShEMCssRDErLEQyKyxEM2hv
dCssRDNjb2xkLSkNCgkJU3RhdHVzOiBEMCBOb1NvZnRSc3QrIFBNRS1FbmFibGUtIERTZWw9
MCBEU2NhbGU9MCBQTUUtDQoJQ2FwYWJpbGl0aWVzOiBbODBdIEV4cHJlc3MgKHYxKSBFbmRw
b2ludCwgTVNJIDAwDQoJCURldkNhcDoJTWF4UGF5bG9hZCAyNTYgYnl0ZXMsIFBoYW50RnVu
YyAwLCBMYXRlbmN5IEwwcyB1bmxpbWl0ZWQsIEwxIHVubGltaXRlZA0KCQkJRXh0VGFnLSBB
dHRuQnRuLSBBdHRuSW5kLSBQd3JJbmQtIFJCRSsgRkxSZXNldC0NCgkJRGV2Q3RsOglSZXBv
cnQgZXJyb3JzOiBDb3JyZWN0YWJsZS0gTm9uLUZhdGFsLSBGYXRhbC0gVW5zdXBwb3J0ZWQt
DQoJCQlSbHhkT3JkLSBFeHRUYWctIFBoYW50RnVuYy0gQXV4UHdyLSBOb1Nub29wKw0KCQkJ
TWF4UGF5bG9hZCAxMjggYnl0ZXMsIE1heFJlYWRSZXEgNTEyIGJ5dGVzDQoJCURldlN0YToJ
Q29yckVyci0gVW5jb3JyRXJyLSBGYXRhbEVyci0gVW5zdXBwUmVxLSBBdXhQd3ItIFRyYW5z
UGVuZC0NCgkJTG5rQ2FwOglQb3J0ICMxLCBTcGVlZCAyLjVHVC9zLCBXaWR0aCB4MSwgQVNQ
TSB1bmtub3duLCBMYXRlbmN5IEwwIDw2NG5zLCBMMSB1bmxpbWl0ZWQNCgkJCUNsb2NrUE0r
IFN1cnByaXNlLSBMTEFjdFJlcC0gQndOb3QtDQoJCUxua0N0bDoJQVNQTSBEaXNhYmxlZDsg
UkNCIDY0IGJ5dGVzIERpc2FibGVkLSBSZXRyYWluLSBDb21tQ2xrLQ0KCQkJRXh0U3luY2gt
IENsb2NrUE0tIEF1dFdpZERpcy0gQldJbnQtIEF1dEJXSW50LQ0KCQlMbmtTdGE6CVNwZWVk
IDIuNUdUL3MsIFdpZHRoIHgxLCBUckVyci0gVHJhaW4tIFNsb3RDbGstIERMQWN0aXZlLSBC
V01nbXQtIEFCV01nbXQtDQoJS2VybmVsIGRyaXZlciBpbiB1c2U6IHBjaWJhY2sNCg0KMDQ6
MDAuMyBVU0IgY29udHJvbGxlciBbMGMwM106IE5ldE1vcyBUZWNobm9sb2d5IE1DUzk5OTAg
UENJZSB0byA04oCQUG9ydCBVU0IgMi4wIEhvc3QgQ29udHJvbGxlciBbOTcxMDo5OTkwXSAo
cHJvZy1pZiAyMCBbRUhDSV0pDQoJU3Vic3lzdGVtOiBEZXZpY2UgW2EwMDA6NDAwMF0NCglD
b250cm9sOiBJL08tIE1lbS0gQnVzTWFzdGVyLSBTcGVjQ3ljbGUtIE1lbVdJTlYtIFZHQVNu
b29wLSBQYXJFcnItIFN0ZXBwaW5nLSBTRVJSLSBGYXN0QjJCLSBEaXNJTlR4LQ0KCVN0YXR1
czogQ2FwKyA2Nk1Iei0gVURGLSBGYXN0QjJCLSBQYXJFcnItIERFVlNFTD1mYXN0ID5UQWJv
cnQtIDxUQWJvcnQtIDxNQWJvcnQtID5TRVJSLSA8UEVSUi0gSU5UeC0NCglJbnRlcnJ1cHQ6
IHBpbiBCIHJvdXRlZCB0byBJUlEgNDENCglSZWdpb24gMDogTWVtb3J5IGF0IGY5NWZiMDAw
ICgzMi1iaXQsIG5vbi1wcmVmZXRjaGFibGUpIFtkaXNhYmxlZF0gW3NpemU9NEtdDQoJQ2Fw
YWJpbGl0aWVzOiBbNTBdIE1TSTogRW5hYmxlLSBDb3VudD0xLzEgTWFza2FibGUtIDY0Yml0
Kw0KCQlBZGRyZXNzOiAwMDAwMDAwMDAwMDAwMDAwICBEYXRhOiAwMDAwDQoJQ2FwYWJpbGl0
aWVzOiBbNzhdIFBvd2VyIE1hbmFnZW1lbnQgdmVyc2lvbiAzDQoJCUZsYWdzOiBQTUVDbGst
IERTSS0gRDErIEQyKyBBdXhDdXJyZW50PTM3NW1BIFBNRShEMCssRDErLEQyKyxEM2hvdCss
RDNjb2xkLSkNCgkJU3RhdHVzOiBEMCBOb1NvZnRSc3QrIFBNRS1FbmFibGUtIERTZWw9MCBE
U2NhbGU9MCBQTUUtDQoJQ2FwYWJpbGl0aWVzOiBbODBdIEV4cHJlc3MgKHYxKSBFbmRwb2lu
dCwgTVNJIDAwDQoJCURldkNhcDoJTWF4UGF5bG9hZCAyNTYgYnl0ZXMsIFBoYW50RnVuYyAw
LCBMYXRlbmN5IEwwcyB1bmxpbWl0ZWQsIEwxIHVubGltaXRlZA0KCQkJRXh0VGFnLSBBdHRu
QnRuLSBBdHRuSW5kLSBQd3JJbmQtIFJCRSsgRkxSZXNldC0NCgkJRGV2Q3RsOglSZXBvcnQg
ZXJyb3JzOiBDb3JyZWN0YWJsZS0gTm9uLUZhdGFsLSBGYXRhbC0gVW5zdXBwb3J0ZWQtDQoJ
CQlSbHhkT3JkLSBFeHRUYWctIFBoYW50RnVuYy0gQXV4UHdyLSBOb1Nub29wKw0KCQkJTWF4
UGF5bG9hZCAxMjggYnl0ZXMsIE1heFJlYWRSZXEgNTEyIGJ5dGVzDQoJCURldlN0YToJQ29y
ckVyci0gVW5jb3JyRXJyLSBGYXRhbEVyci0gVW5zdXBwUmVxLSBBdXhQd3ItIFRyYW5zUGVu
ZC0NCgkJTG5rQ2FwOglQb3J0ICMxLCBTcGVlZCAyLjVHVC9zLCBXaWR0aCB4MSwgQVNQTSB1
bmtub3duLCBMYXRlbmN5IEwwIDw2NG5zLCBMMSB1bmxpbWl0ZWQNCgkJCUNsb2NrUE0rIFN1
cnByaXNlLSBMTEFjdFJlcC0gQndOb3QtDQoJCUxua0N0bDoJQVNQTSBEaXNhYmxlZDsgUkNC
IDY0IGJ5dGVzIERpc2FibGVkLSBSZXRyYWluLSBDb21tQ2xrLQ0KCQkJRXh0U3luY2gtIENs
b2NrUE0tIEF1dFdpZERpcy0gQldJbnQtIEF1dEJXSW50LQ0KCQlMbmtTdGE6CVNwZWVkIDIu
NUdUL3MsIFdpZHRoIHgxLCBUckVyci0gVHJhaW4tIFNsb3RDbGstIERMQWN0aXZlLSBCV01n
bXQtIEFCV01nbXQtDQoJS2VybmVsIGRyaXZlciBpbiB1c2U6IHBjaWJhY2sNCg0KMDQ6MDAu
NCBVU0IgY29udHJvbGxlciBbMGMwM106IE5ldE1vcyBUZWNobm9sb2d5IE1DUzk5OTAgUENJ
ZSB0byA04oCQUG9ydCBVU0IgMi4wIEhvc3QgQ29udHJvbGxlciBbOTcxMDo5OTkwXSAocHJv
Zy1pZiAxMCBbT0hDSV0pDQoJU3Vic3lzdGVtOiBEZXZpY2UgW2EwMDA6NDAwMF0NCglDb250
cm9sOiBJL08tIE1lbS0gQnVzTWFzdGVyLSBTcGVjQ3ljbGUtIE1lbVdJTlYtIFZHQVNub29w
LSBQYXJFcnItIFN0ZXBwaW5nLSBTRVJSLSBGYXN0QjJCLSBEaXNJTlR4LQ0KCVN0YXR1czog
Q2FwKyA2Nk1Iei0gVURGLSBGYXN0QjJCLSBQYXJFcnItIERFVlNFTD1mYXN0ID5UQWJvcnQt
IDxUQWJvcnQtIDxNQWJvcnQtID5TRVJSLSA8UEVSUi0gSU5UeC0NCglJbnRlcnJ1cHQ6IHBp
biBDIHJvdXRlZCB0byBJUlEgNDINCglSZWdpb24gMDogTWVtb3J5IGF0IGY5NWZjMDAwICgz
Mi1iaXQsIG5vbi1wcmVmZXRjaGFibGUpIFtkaXNhYmxlZF0gW3NpemU9NEtdDQoJQ2FwYWJp
bGl0aWVzOiBbNTBdIE1TSTogRW5hYmxlLSBDb3VudD0xLzEgTWFza2FibGUtIDY0Yml0Kw0K
CQlBZGRyZXNzOiAwMDAwMDAwMDAwMDAwMDAwICBEYXRhOiAwMDAwDQoJQ2FwYWJpbGl0aWVz
OiBbNzhdIFBvd2VyIE1hbmFnZW1lbnQgdmVyc2lvbiAzDQoJCUZsYWdzOiBQTUVDbGstIERT
SS0gRDErIEQyKyBBdXhDdXJyZW50PTM3NW1BIFBNRShEMCssRDErLEQyKyxEM2hvdCssRDNj
b2xkLSkNCgkJU3RhdHVzOiBEMCBOb1NvZnRSc3QrIFBNRS1FbmFibGUtIERTZWw9MCBEU2Nh
bGU9MCBQTUUtDQoJQ2FwYWJpbGl0aWVzOiBbODBdIEV4cHJlc3MgKHYxKSBFbmRwb2ludCwg
TVNJIDAwDQoJCURldkNhcDoJTWF4UGF5bG9hZCAyNTYgYnl0ZXMsIFBoYW50RnVuYyAwLCBM
YXRlbmN5IEwwcyB1bmxpbWl0ZWQsIEwxIHVubGltaXRlZA0KCQkJRXh0VGFnLSBBdHRuQnRu
LSBBdHRuSW5kLSBQd3JJbmQtIFJCRSsgRkxSZXNldC0NCgkJRGV2Q3RsOglSZXBvcnQgZXJy
b3JzOiBDb3JyZWN0YWJsZS0gTm9uLUZhdGFsLSBGYXRhbC0gVW5zdXBwb3J0ZWQtDQoJCQlS
bHhkT3JkLSBFeHRUYWctIFBoYW50RnVuYy0gQXV4UHdyLSBOb1Nub29wKw0KCQkJTWF4UGF5
bG9hZCAxMjggYnl0ZXMsIE1heFJlYWRSZXEgNTEyIGJ5dGVzDQoJCURldlN0YToJQ29yckVy
ci0gVW5jb3JyRXJyLSBGYXRhbEVyci0gVW5zdXBwUmVxLSBBdXhQd3ItIFRyYW5zUGVuZC0N
CgkJTG5rQ2FwOglQb3J0ICMxLCBTcGVlZCAyLjVHVC9zLCBXaWR0aCB4MSwgQVNQTSB1bmtu
b3duLCBMYXRlbmN5IEwwIDw2NG5zLCBMMSB1bmxpbWl0ZWQNCgkJCUNsb2NrUE0rIFN1cnBy
aXNlLSBMTEFjdFJlcC0gQndOb3QtDQoJCUxua0N0bDoJQVNQTSBEaXNhYmxlZDsgUkNCIDY0
IGJ5dGVzIERpc2FibGVkLSBSZXRyYWluLSBDb21tQ2xrLQ0KCQkJRXh0U3luY2gtIENsb2Nr
UE0tIEF1dFdpZERpcy0gQldJbnQtIEF1dEJXSW50LQ0KCQlMbmtTdGE6CVNwZWVkIDIuNUdU
L3MsIFdpZHRoIHgxLCBUckVyci0gVHJhaW4tIFNsb3RDbGstIERMQWN0aXZlLSBCV01nbXQt
IEFCV01nbXQtDQoJS2VybmVsIGRyaXZlciBpbiB1c2U6IHBjaWJhY2sNCg0KMDQ6MDAuNSBV
U0IgY29udHJvbGxlciBbMGMwM106IE5ldE1vcyBUZWNobm9sb2d5IE1DUzk5OTAgUENJZSB0
byA04oCQUG9ydCBVU0IgMi4wIEhvc3QgQ29udHJvbGxlciBbOTcxMDo5OTkwXSAocHJvZy1p
ZiAyMCBbRUhDSV0pDQoJU3Vic3lzdGVtOiBEZXZpY2UgW2EwMDA6NDAwMF0NCglDb250cm9s
OiBJL08tIE1lbS0gQnVzTWFzdGVyLSBTcGVjQ3ljbGUtIE1lbVdJTlYtIFZHQVNub29wLSBQ
YXJFcnItIFN0ZXBwaW5nLSBTRVJSLSBGYXN0QjJCLSBEaXNJTlR4LQ0KCVN0YXR1czogQ2Fw
KyA2Nk1Iei0gVURGLSBGYXN0QjJCLSBQYXJFcnItIERFVlNFTD1mYXN0ID5UQWJvcnQtIDxU
QWJvcnQtIDxNQWJvcnQtID5TRVJSLSA8UEVSUi0gSU5UeC0NCglJbnRlcnJ1cHQ6IHBpbiBD
IHJvdXRlZCB0byBJUlEgNDINCglSZWdpb24gMDogTWVtb3J5IGF0IGY5NWZkMDAwICgzMi1i
aXQsIG5vbi1wcmVmZXRjaGFibGUpIFtkaXNhYmxlZF0gW3NpemU9NEtdDQoJQ2FwYWJpbGl0
aWVzOiBbNTBdIE1TSTogRW5hYmxlLSBDb3VudD0xLzEgTWFza2FibGUtIDY0Yml0Kw0KCQlB
ZGRyZXNzOiAwMDAwMDAwMDAwMDAwMDAwICBEYXRhOiAwMDAwDQoJQ2FwYWJpbGl0aWVzOiBb
NzhdIFBvd2VyIE1hbmFnZW1lbnQgdmVyc2lvbiAzDQoJCUZsYWdzOiBQTUVDbGstIERTSS0g
RDErIEQyKyBBdXhDdXJyZW50PTM3NW1BIFBNRShEMCssRDErLEQyKyxEM2hvdCssRDNjb2xk
LSkNCgkJU3RhdHVzOiBEMCBOb1NvZnRSc3QrIFBNRS1FbmFibGUtIERTZWw9MCBEU2NhbGU9
MCBQTUUtDQoJQ2FwYWJpbGl0aWVzOiBbODBdIEV4cHJlc3MgKHYxKSBFbmRwb2ludCwgTVNJ
IDAwDQoJCURldkNhcDoJTWF4UGF5bG9hZCAyNTYgYnl0ZXMsIFBoYW50RnVuYyAwLCBMYXRl
bmN5IEwwcyB1bmxpbWl0ZWQsIEwxIHVubGltaXRlZA0KCQkJRXh0VGFnLSBBdHRuQnRuLSBB
dHRuSW5kLSBQd3JJbmQtIFJCRSsgRkxSZXNldC0NCgkJRGV2Q3RsOglSZXBvcnQgZXJyb3Jz
OiBDb3JyZWN0YWJsZS0gTm9uLUZhdGFsLSBGYXRhbC0gVW5zdXBwb3J0ZWQtDQoJCQlSbHhk
T3JkLSBFeHRUYWctIFBoYW50RnVuYy0gQXV4UHdyLSBOb1Nub29wKw0KCQkJTWF4UGF5bG9h
ZCAxMjggYnl0ZXMsIE1heFJlYWRSZXEgNTEyIGJ5dGVzDQoJCURldlN0YToJQ29yckVyci0g
VW5jb3JyRXJyLSBGYXRhbEVyci0gVW5zdXBwUmVxLSBBdXhQd3ItIFRyYW5zUGVuZC0NCgkJ
TG5rQ2FwOglQb3J0ICMxLCBTcGVlZCAyLjVHVC9zLCBXaWR0aCB4MSwgQVNQTSB1bmtub3du
LCBMYXRlbmN5IEwwIDw2NG5zLCBMMSB1bmxpbWl0ZWQNCgkJCUNsb2NrUE0rIFN1cnByaXNl
LSBMTEFjdFJlcC0gQndOb3QtDQoJCUxua0N0bDoJQVNQTSBEaXNhYmxlZDsgUkNCIDY0IGJ5
dGVzIERpc2FibGVkLSBSZXRyYWluLSBDb21tQ2xrLQ0KCQkJRXh0U3luY2gtIENsb2NrUE0t
IEF1dFdpZERpcy0gQldJbnQtIEF1dEJXSW50LQ0KCQlMbmtTdGE6CVNwZWVkIDIuNUdUL3Ms
IFdpZHRoIHgxLCBUckVyci0gVHJhaW4tIFNsb3RDbGstIERMQWN0aXZlLSBCV01nbXQtIEFC
V01nbXQtDQoJS2VybmVsIGRyaXZlciBpbiB1c2U6IHBjaWJhY2sNCg0KMDQ6MDAuNiBVU0Ig
Y29udHJvbGxlciBbMGMwM106IE5ldE1vcyBUZWNobm9sb2d5IE1DUzk5OTAgUENJZSB0byA0
4oCQUG9ydCBVU0IgMi4wIEhvc3QgQ29udHJvbGxlciBbOTcxMDo5OTkwXSAocHJvZy1pZiAx
MCBbT0hDSV0pDQoJU3Vic3lzdGVtOiBEZXZpY2UgW2EwMDA6NDAwMF0NCglDb250cm9sOiBJ
L08tIE1lbS0gQnVzTWFzdGVyLSBTcGVjQ3ljbGUtIE1lbVdJTlYtIFZHQVNub29wLSBQYXJF
cnItIFN0ZXBwaW5nLSBTRVJSLSBGYXN0QjJCLSBEaXNJTlR4LQ0KCVN0YXR1czogQ2FwKyA2
Nk1Iei0gVURGLSBGYXN0QjJCLSBQYXJFcnItIERFVlNFTD1mYXN0ID5UQWJvcnQtIDxUQWJv
cnQtIDxNQWJvcnQtID5TRVJSLSA8UEVSUi0gSU5UeC0NCglJbnRlcnJ1cHQ6IHBpbiBEIHJv
dXRlZCB0byBJUlEgNDMNCglSZWdpb24gMDogTWVtb3J5IGF0IGY5NWZlMDAwICgzMi1iaXQs
IG5vbi1wcmVmZXRjaGFibGUpIFtkaXNhYmxlZF0gW3NpemU9NEtdDQoJQ2FwYWJpbGl0aWVz
OiBbNTBdIE1TSTogRW5hYmxlLSBDb3VudD0xLzEgTWFza2FibGUtIDY0Yml0Kw0KCQlBZGRy
ZXNzOiAwMDAwMDAwMDAwMDAwMDAwICBEYXRhOiAwMDAwDQoJQ2FwYWJpbGl0aWVzOiBbNzhd
IFBvd2VyIE1hbmFnZW1lbnQgdmVyc2lvbiAzDQoJCUZsYWdzOiBQTUVDbGstIERTSS0gRDEr
IEQyKyBBdXhDdXJyZW50PTM3NW1BIFBNRShEMCssRDErLEQyKyxEM2hvdCssRDNjb2xkLSkN
CgkJU3RhdHVzOiBEMCBOb1NvZnRSc3QrIFBNRS1FbmFibGUtIERTZWw9MCBEU2NhbGU9MCBQ
TUUtDQoJQ2FwYWJpbGl0aWVzOiBbODBdIEV4cHJlc3MgKHYxKSBFbmRwb2ludCwgTVNJIDAw
DQoJCURldkNhcDoJTWF4UGF5bG9hZCAyNTYgYnl0ZXMsIFBoYW50RnVuYyAwLCBMYXRlbmN5
IEwwcyB1bmxpbWl0ZWQsIEwxIHVubGltaXRlZA0KCQkJRXh0VGFnLSBBdHRuQnRuLSBBdHRu
SW5kLSBQd3JJbmQtIFJCRSsgRkxSZXNldC0NCgkJRGV2Q3RsOglSZXBvcnQgZXJyb3JzOiBD
b3JyZWN0YWJsZS0gTm9uLUZhdGFsLSBGYXRhbC0gVW5zdXBwb3J0ZWQtDQoJCQlSbHhkT3Jk
LSBFeHRUYWctIFBoYW50RnVuYy0gQXV4UHdyLSBOb1Nub29wKw0KCQkJTWF4UGF5bG9hZCAx
MjggYnl0ZXMsIE1heFJlYWRSZXEgNTEyIGJ5dGVzDQoJCURldlN0YToJQ29yckVyci0gVW5j
b3JyRXJyLSBGYXRhbEVyci0gVW5zdXBwUmVxLSBBdXhQd3ItIFRyYW5zUGVuZC0NCgkJTG5r
Q2FwOglQb3J0ICMxLCBTcGVlZCAyLjVHVC9zLCBXaWR0aCB4MSwgQVNQTSB1bmtub3duLCBM
YXRlbmN5IEwwIDw2NG5zLCBMMSB1bmxpbWl0ZWQNCgkJCUNsb2NrUE0rIFN1cnByaXNlLSBM
TEFjdFJlcC0gQndOb3QtDQoJCUxua0N0bDoJQVNQTSBEaXNhYmxlZDsgUkNCIDY0IGJ5dGVz
IERpc2FibGVkLSBSZXRyYWluLSBDb21tQ2xrLQ0KCQkJRXh0U3luY2gtIENsb2NrUE0tIEF1
dFdpZERpcy0gQldJbnQtIEF1dEJXSW50LQ0KCQlMbmtTdGE6CVNwZWVkIDIuNUdUL3MsIFdp
ZHRoIHgxLCBUckVyci0gVHJhaW4tIFNsb3RDbGstIERMQWN0aXZlLSBCV01nbXQtIEFCV01n
bXQtDQoJS2VybmVsIGRyaXZlciBpbiB1c2U6IHBjaWJhY2sNCg0KMDQ6MDAuNyBVU0IgY29u
dHJvbGxlciBbMGMwM106IE5ldE1vcyBUZWNobm9sb2d5IE1DUzk5OTAgUENJZSB0byA04oCQ
UG9ydCBVU0IgMi4wIEhvc3QgQ29udHJvbGxlciBbOTcxMDo5OTkwXSAocHJvZy1pZiAyMCBb
RUhDSV0pDQoJU3Vic3lzdGVtOiBEZXZpY2UgW2EwMDA6NDAwMF0NCglDb250cm9sOiBJL08t
IE1lbS0gQnVzTWFzdGVyLSBTcGVjQ3ljbGUtIE1lbVdJTlYtIFZHQVNub29wLSBQYXJFcnIt
IFN0ZXBwaW5nLSBTRVJSLSBGYXN0QjJCLSBEaXNJTlR4LQ0KCVN0YXR1czogQ2FwKyA2Nk1I
ei0gVURGLSBGYXN0QjJCLSBQYXJFcnItIERFVlNFTD1mYXN0ID5UQWJvcnQtIDxUQWJvcnQt
IDxNQWJvcnQtID5TRVJSLSA8UEVSUi0gSU5UeC0NCglJbnRlcnJ1cHQ6IHBpbiBEIHJvdXRl
ZCB0byBJUlEgNDMNCglSZWdpb24gMDogTWVtb3J5IGF0IGY5NWZmMDAwICgzMi1iaXQsIG5v
bi1wcmVmZXRjaGFibGUpIFtkaXNhYmxlZF0gW3NpemU9NEtdDQoJQ2FwYWJpbGl0aWVzOiBb
NTBdIE1TSTogRW5hYmxlLSBDb3VudD0xLzEgTWFza2FibGUtIDY0Yml0Kw0KCQlBZGRyZXNz
OiAwMDAwMDAwMDAwMDAwMDAwICBEYXRhOiAwMDAwDQoJQ2FwYWJpbGl0aWVzOiBbNzhdIFBv
d2VyIE1hbmFnZW1lbnQgdmVyc2lvbiAzDQoJCUZsYWdzOiBQTUVDbGstIERTSS0gRDErIEQy
KyBBdXhDdXJyZW50PTM3NW1BIFBNRShEMCssRDErLEQyKyxEM2hvdCssRDNjb2xkLSkNCgkJ
U3RhdHVzOiBEMCBOb1NvZnRSc3QrIFBNRS1FbmFibGUtIERTZWw9MCBEU2NhbGU9MCBQTUUt
DQoJQ2FwYWJpbGl0aWVzOiBbODBdIEV4cHJlc3MgKHYxKSBFbmRwb2ludCwgTVNJIDAwDQoJ
CURldkNhcDoJTWF4UGF5bG9hZCAyNTYgYnl0ZXMsIFBoYW50RnVuYyAwLCBMYXRlbmN5IEww
cyB1bmxpbWl0ZWQsIEwxIHVubGltaXRlZA0KCQkJRXh0VGFnLSBBdHRuQnRuLSBBdHRuSW5k
LSBQd3JJbmQtIFJCRSsgRkxSZXNldC0NCgkJRGV2Q3RsOglSZXBvcnQgZXJyb3JzOiBDb3Jy
ZWN0YWJsZS0gTm9uLUZhdGFsLSBGYXRhbC0gVW5zdXBwb3J0ZWQtDQoJCQlSbHhkT3JkLSBF
eHRUYWctIFBoYW50RnVuYy0gQXV4UHdyLSBOb1Nub29wKw0KCQkJTWF4UGF5bG9hZCAxMjgg
Ynl0ZXMsIE1heFJlYWRSZXEgNTEyIGJ5dGVzDQoJCURldlN0YToJQ29yckVyci0gVW5jb3Jy
RXJyLSBGYXRhbEVyci0gVW5zdXBwUmVxLSBBdXhQd3ItIFRyYW5zUGVuZC0NCgkJTG5rQ2Fw
OglQb3J0ICMxLCBTcGVlZCAyLjVHVC9zLCBXaWR0aCB4MSwgQVNQTSB1bmtub3duLCBMYXRl
bmN5IEwwIDw2NG5zLCBMMSB1bmxpbWl0ZWQNCgkJCUNsb2NrUE0rIFN1cnByaXNlLSBMTEFj
dFJlcC0gQndOb3QtDQoJCUxua0N0bDoJQVNQTSBEaXNhYmxlZDsgUkNCIDY0IGJ5dGVzIERp
c2FibGVkLSBSZXRyYWluLSBDb21tQ2xrLQ0KCQkJRXh0U3luY2gtIENsb2NrUE0tIEF1dFdp
ZERpcy0gQldJbnQtIEF1dEJXSW50LQ0KCQlMbmtTdGE6CVNwZWVkIDIuNUdUL3MsIFdpZHRo
IHgxLCBUckVyci0gVHJhaW4tIFNsb3RDbGstIERMQWN0aXZlLSBCV01nbXQtIEFCV01nbXQt
DQoJS2VybmVsIGRyaXZlciBpbiB1c2U6IHBjaWJhY2sNCg0KMDU6MDAuMCBNdWx0aW1lZGlh
IHZpZGVvIGNvbnRyb2xsZXIgWzA0MDBdOiBDb25leGFudCBTeXN0ZW1zLCBJbmMuIENYMjU4
NTAgWzE0ZjE6ODIwMF0NCglDb250cm9sOiBJL08tIE1lbS0gQnVzTWFzdGVyLSBTcGVjQ3lj
bGUtIE1lbVdJTlYtIFZHQVNub29wLSBQYXJFcnItIFN0ZXBwaW5nLSBTRVJSLSBGYXN0QjJC
LSBEaXNJTlR4LQ0KCVN0YXR1czogQ2FwKyA2Nk1Iei0gVURGLSBGYXN0QjJCLSBQYXJFcnIt
IERFVlNFTD1mYXN0ID5UQWJvcnQtIDxUQWJvcnQtIDxNQWJvcnQtID5TRVJSLSA8UEVSUi0g
SU5UeC0NCglJbnRlcnJ1cHQ6IHBpbiBBIHJvdXRlZCB0byBJUlEgMzYNCglSZWdpb24gMDog
TWVtb3J5IGF0IGY5NjAwMDAwICg2NC1iaXQsIG5vbi1wcmVmZXRjaGFibGUpIFtkaXNhYmxl
ZF0gW3NpemU9Mk1dDQoJQ2FwYWJpbGl0aWVzOiBbNDBdIEV4cHJlc3MgKHYxKSBFbmRwb2lu
dCwgTVNJIDAwDQoJCURldkNhcDoJTWF4UGF5bG9hZCAxMjggYnl0ZXMsIFBoYW50RnVuYyAw
LCBMYXRlbmN5IEwwcyA8NjRucywgTDEgPDF1cw0KCQkJRXh0VGFnLSBBdHRuQnRuLSBBdHRu
SW5kLSBQd3JJbmQtIFJCRSsgRkxSZXNldC0NCgkJRGV2Q3RsOglSZXBvcnQgZXJyb3JzOiBD
b3JyZWN0YWJsZS0gTm9uLUZhdGFsLSBGYXRhbC0gVW5zdXBwb3J0ZWQtDQoJCQlSbHhkT3Jk
KyBFeHRUYWctIFBoYW50RnVuYy0gQXV4UHdyLSBOb1Nub29wKw0KCQkJTWF4UGF5bG9hZCAx
MjggYnl0ZXMsIE1heFJlYWRSZXEgNTEyIGJ5dGVzDQoJCURldlN0YToJQ29yckVycisgVW5j
b3JyRXJyLSBGYXRhbEVyci0gVW5zdXBwUmVxKyBBdXhQd3ItIFRyYW5zUGVuZC0NCgkJTG5r
Q2FwOglQb3J0ICMwLCBTcGVlZCAyLjVHVC9zLCBXaWR0aCB4MSwgQVNQTSBMMHMgTDEsIExh
dGVuY3kgTDAgPDJ1cywgTDEgPDR1cw0KCQkJQ2xvY2tQTS0gU3VycHJpc2UtIExMQWN0UmVw
LSBCd05vdC0NCgkJTG5rQ3RsOglBU1BNIERpc2FibGVkOyBSQ0IgNjQgYnl0ZXMgRGlzYWJs
ZWQtIFJldHJhaW4tIENvbW1DbGstDQoJCQlFeHRTeW5jaC0gQ2xvY2tQTS0gQXV0V2lkRGlz
LSBCV0ludC0gQXV0QldJbnQtDQoJCUxua1N0YToJU3BlZWQgMi41R1QvcywgV2lkdGggeDEs
IFRyRXJyLSBUcmFpbi0gU2xvdENsay0gRExBY3RpdmUtIEJXTWdtdC0gQUJXTWdtdC0NCglD
YXBhYmlsaXRpZXM6IFs4MF0gUG93ZXIgTWFuYWdlbWVudCB2ZXJzaW9uIDMNCgkJRmxhZ3M6
IFBNRUNsay0gRFNJKyBEMSsgRDIrIEF1eEN1cnJlbnQ9MG1BIFBNRShEMCssRDErLEQyKyxE
M2hvdCssRDNjb2xkLSkNCgkJU3RhdHVzOiBEMCBOb1NvZnRSc3QrIFBNRS1FbmFibGUtIERT
ZWw9MCBEU2NhbGU9MCBQTUUtDQoJQ2FwYWJpbGl0aWVzOiBbOTBdIFZpdGFsIFByb2R1Y3Qg
RGF0YQ0KCQlVbmtub3duIHNtYWxsIHJlc291cmNlIHR5cGUgMDAsIHdpbGwgbm90IGRlY29k
ZSBtb3JlLg0KCUNhcGFiaWxpdGllczogW2EwXSBNU0k6IEVuYWJsZS0gQ291bnQ9MS8xIE1h
c2thYmxlLSA2NGJpdCsNCgkJQWRkcmVzczogMDAwMDAwMDAwMDAwMDAwMCAgRGF0YTogMDAw
MA0KCUNhcGFiaWxpdGllczogWzEwMCB2MV0gQWR2YW5jZWQgRXJyb3IgUmVwb3J0aW5nDQoJ
CVVFU3RhOglETFAtIFNERVMtIFRMUC0gRkNQLSBDbXBsdFRPLSBDbXBsdEFicnQtIFVueENt
cGx0LSBSeE9GLSBNYWxmVExQLSBFQ1JDLSBVbnN1cFJlcS0gQUNTVmlvbC0NCgkJVUVNc2s6
CURMUC0gU0RFUy0gVExQLSBGQ1AtIENtcGx0VE8tIENtcGx0QWJydC0gVW54Q21wbHQtIFJ4
T0YtIE1hbGZUTFAtIEVDUkMtIFVuc3VwUmVxLSBBQ1NWaW9sLQ0KCQlVRVN2cnQ6CURMUCsg
U0RFUy0gVExQLSBGQ1ArIENtcGx0VE8tIENtcGx0QWJydC0gVW54Q21wbHQtIFJ4T0YrIE1h
bGZUTFArIEVDUkMtIFVuc3VwUmVxLSBBQ1NWaW9sLQ0KCQlDRVN0YToJUnhFcnItIEJhZFRM
UC0gQmFkRExMUC0gUm9sbG92ZXItIFRpbWVvdXQtIE5vbkZhdGFsRXJyKw0KCQlDRU1zazoJ
UnhFcnItIEJhZFRMUC0gQmFkRExMUC0gUm9sbG92ZXItIFRpbWVvdXQtIE5vbkZhdGFsRXJy
Kw0KCQlBRVJDYXA6CUZpcnN0IEVycm9yIFBvaW50ZXI6IDAwLCBHZW5DYXAtIENHZW5Fbi0g
Q2hrQ2FwLSBDaGtFbi0NCglDYXBhYmlsaXRpZXM6IFsyMDAgdjFdIFZpcnR1YWwgQ2hhbm5l
bA0KCQlDYXBzOglMUEVWQz0xIFJlZkNsaz0xMDBucyBQQVRFbnRyeUJpdHM9MQ0KCQlBcmI6
CUZpeGVkKyBXUlIzMisgV1JSNjQrIFdSUjEyOC0NCgkJQ3RybDoJQXJiU2VsZWN0PVdSUjY0
DQoJCVN0YXR1czoJSW5Qcm9ncmVzcy0NCgkJUG9ydCBBcmJpdHJhdGlvbiBUYWJsZSBbMjQw
XSA8Pz4NCgkJVkMwOglDYXBzOglQQVRPZmZzZXQ9MDAgTWF4VGltZVNsb3RzPTEgUmVqU25v
b3BUcmFucy0NCgkJCUFyYjoJRml4ZWQtIFdSUjMyLSBXUlI2NC0gV1JSMTI4LSBUV1JSMTI4
LSBXUlIyNTYtDQoJCQlDdHJsOglFbmFibGUrIElEPTAgQXJiU2VsZWN0PUZpeGVkIFRDL1ZD
PWZmDQoJCQlTdGF0dXM6CU5lZ29QZW5kaW5nLSBJblByb2dyZXNzLQ0KCQlWQzE6CUNhcHM6
CVBBVE9mZnNldD0wMCBNYXhUaW1lU2xvdHM9MSBSZWpTbm9vcFRyYW5zLQ0KCQkJQXJiOglG
aXhlZC0gV1JSMzItIFdSUjY0LSBXUlIxMjgtIFRXUlIxMjgtIFdSUjI1Ni0NCgkJCUN0cmw6
CUVuYWJsZS0gSUQ9MSBBcmJTZWxlY3Q9Rml4ZWQgVEMvVkM9MDANCgkJCVN0YXR1czoJTmVn
b1BlbmRpbmctIEluUHJvZ3Jlc3MtDQoJS2VybmVsIGRyaXZlciBpbiB1c2U6IHBjaWJhY2sN
Cg0KMDY6MDAuMCBWR0EgY29tcGF0aWJsZSBjb250cm9sbGVyIFswMzAwXTogQVRJIFRlY2hu
b2xvZ2llcyBJbmMgUlY2MjAgTEUgW1JhZGVvbiBIRCAzNDUwXSBbMTAwMjo5NWM1XSAocHJv
Zy1pZiAwMCBbVkdBIGNvbnRyb2xsZXJdKQ0KCVN1YnN5c3RlbTogQVNVU1RlSyBDb21wdXRl
ciBJbmMuIERldmljZSBbMTA0MzowMWQ0XQ0KCUNvbnRyb2w6IEkvTy0gTWVtLSBCdXNNYXN0
ZXItIFNwZWNDeWNsZS0gTWVtV0lOVi0gVkdBU25vb3AtIFBhckVyci0gU3RlcHBpbmctIFNF
UlItIEZhc3RCMkItIERpc0lOVHgtDQoJU3RhdHVzOiBDYXArIDY2TUh6LSBVREYtIEZhc3RC
MkItIFBhckVyci0gREVWU0VMPWZhc3QgPlRBYm9ydC0gPFRBYm9ydC0gPE1BYm9ydC0gPlNF
UlItIDxQRVJSLSBJTlR4LQ0KCUludGVycnVwdDogcGluIEEgcm91dGVkIHRvIElSUSAxMA0K
CVJlZ2lvbiAwOiBNZW1vcnkgYXQgYjAwMDAwMDAgKDY0LWJpdCwgcHJlZmV0Y2hhYmxlKSBb
ZGlzYWJsZWRdIFtzaXplPTI1Nk1dDQoJUmVnaW9uIDI6IE1lbW9yeSBhdCBmOTllMDAwMCAo
NjQtYml0LCBub24tcHJlZmV0Y2hhYmxlKSBbZGlzYWJsZWRdIFtzaXplPTY0S10NCglSZWdp
b24gNDogSS9PIHBvcnRzIGF0IGIwMDAgW2Rpc2FibGVkXSBbc2l6ZT0yNTZdDQoJRXhwYW5z
aW9uIFJPTSBhdCBmOTljMDAwMCBbZGlzYWJsZWRdIFtzaXplPTEyOEtdDQoJQ2FwYWJpbGl0
aWVzOiBbNTBdIFBvd2VyIE1hbmFnZW1lbnQgdmVyc2lvbiAzDQoJCUZsYWdzOiBQTUVDbGst
IERTSS0gRDErIEQyKyBBdXhDdXJyZW50PTBtQSBQTUUoRDAtLEQxLSxEMi0sRDNob3QtLEQz
Y29sZC0pDQoJCVN0YXR1czogRDAgTm9Tb2Z0UnN0LSBQTUUtRW5hYmxlLSBEU2VsPTAgRFNj
YWxlPTAgUE1FLQ0KCUNhcGFiaWxpdGllczogWzU4XSBFeHByZXNzICh2MikgTGVnYWN5IEVu
ZHBvaW50LCBNU0kgMDANCgkJRGV2Q2FwOglNYXhQYXlsb2FkIDEyOCBieXRlcywgUGhhbnRG
dW5jIDAsIExhdGVuY3kgTDBzIDw0dXMsIEwxIHVubGltaXRlZA0KCQkJRXh0VGFnKyBBdHRu
QnRuLSBBdHRuSW5kLSBQd3JJbmQtIFJCRSsgRkxSZXNldC0NCgkJRGV2Q3RsOglSZXBvcnQg
ZXJyb3JzOiBDb3JyZWN0YWJsZS0gTm9uLUZhdGFsLSBGYXRhbC0gVW5zdXBwb3J0ZWQtDQoJ
CQlSbHhkT3JkKyBFeHRUYWctIFBoYW50RnVuYy0gQXV4UHdyLSBOb1Nub29wKw0KCQkJTWF4
UGF5bG9hZCAxMjggYnl0ZXMsIE1heFJlYWRSZXEgMTI4IGJ5dGVzDQoJCURldlN0YToJQ29y
ckVyci0gVW5jb3JyRXJyLSBGYXRhbEVyci0gVW5zdXBwUmVxLSBBdXhQd3ItIFRyYW5zUGVu
ZC0NCgkJTG5rQ2FwOglQb3J0ICMwLCBTcGVlZCAyLjVHVC9zLCBXaWR0aCB4MTYsIEFTUE0g
TDBzIEwxLCBMYXRlbmN5IEwwIDw2NG5zLCBMMSA8MXVzDQoJCQlDbG9ja1BNLSBTdXJwcmlz
ZS0gTExBY3RSZXAtIEJ3Tm90LQ0KCQlMbmtDdGw6CUFTUE0gRGlzYWJsZWQ7IFJDQiA2NCBi
eXRlcyBEaXNhYmxlZC0gUmV0cmFpbi0gQ29tbUNsaysNCgkJCUV4dFN5bmNoLSBDbG9ja1BN
LSBBdXRXaWREaXMtIEJXSW50LSBBdXRCV0ludC0NCgkJTG5rU3RhOglTcGVlZCAyLjVHVC9z
LCBXaWR0aCB4MSwgVHJFcnItIFRyYWluLSBTbG90Q2xrKyBETEFjdGl2ZS0gQldNZ210LSBB
QldNZ210LQ0KCQlEZXZDYXAyOiBDb21wbGV0aW9uIFRpbWVvdXQ6IE5vdCBTdXBwb3J0ZWQs
IFRpbWVvdXREaXMtDQoJCURldkN0bDI6IENvbXBsZXRpb24gVGltZW91dDogNTB1cyB0byA1
MG1zLCBUaW1lb3V0RGlzLQ0KCQlMbmtDdGwyOiBUYXJnZXQgTGluayBTcGVlZDogMi41R1Qv
cywgRW50ZXJDb21wbGlhbmNlLSBTcGVlZERpcy0sIFNlbGVjdGFibGUgRGUtZW1waGFzaXM6
IC02ZEINCgkJCSBUcmFuc21pdCBNYXJnaW46IE5vcm1hbCBPcGVyYXRpbmcgUmFuZ2UsIEVu
dGVyTW9kaWZpZWRDb21wbGlhbmNlLSBDb21wbGlhbmNlU09TLQ0KCQkJIENvbXBsaWFuY2Ug
RGUtZW1waGFzaXM6IC02ZEINCgkJTG5rU3RhMjogQ3VycmVudCBEZS1lbXBoYXNpcyBMZXZl
bDogLTZkQg0KCUNhcGFiaWxpdGllczogW2EwXSBNU0k6IEVuYWJsZS0gQ291bnQ9MS8xIE1h
c2thYmxlLSA2NGJpdCsNCgkJQWRkcmVzczogMDAwMDAwMDAwMDAwMDAwMCAgRGF0YTogMDAw
MA0KCUNhcGFiaWxpdGllczogWzEwMCB2MV0gVmVuZG9yIFNwZWNpZmljIEluZm9ybWF0aW9u
OiBJRD0wMDAxIFJldj0xIExlbj0wMTAgPD8+DQoNCjA2OjAwLjEgQXVkaW8gZGV2aWNlIFsw
NDAzXTogQVRJIFRlY2hub2xvZ2llcyBJbmMgUlY2MjAgQXVkaW8gZGV2aWNlIFtSYWRlb24g
SEQgMzR4eCBTZXJpZXNdIFsxMDAyOmFhMjhdDQoJU3Vic3lzdGVtOiBBU1VTVGVLIENvbXB1
dGVyIEluYy4gRGV2aWNlIFsxMDQzOmFhMjhdDQoJQ29udHJvbDogSS9PKyBNZW0rIEJ1c01h
c3RlcisgU3BlY0N5Y2xlLSBNZW1XSU5WLSBWR0FTbm9vcC0gUGFyRXJyLSBTdGVwcGluZy0g
U0VSUisgRmFzdEIyQi0gRGlzSU5UeCsNCglTdGF0dXM6IENhcCsgNjZNSHotIFVERi0gRmFz
dEIyQi0gUGFyRXJyLSBERVZTRUw9ZmFzdCA+VEFib3J0LSA8VEFib3J0LSA8TUFib3J0LSA+
U0VSUi0gPFBFUlItIElOVHgtDQoJTGF0ZW5jeTogMCwgQ2FjaGUgTGluZSBTaXplOiA2NCBi
eXRlcw0KCUludGVycnVwdDogcGluIEIgcm91dGVkIHRvIElSUSAxMjMNCglSZWdpb24gMDog
TWVtb3J5IGF0IGY5OWZjMDAwICg2NC1iaXQsIG5vbi1wcmVmZXRjaGFibGUpIFtzaXplPTE2
S10NCglDYXBhYmlsaXRpZXM6IFs1MF0gUG93ZXIgTWFuYWdlbWVudCB2ZXJzaW9uIDMNCgkJ
RmxhZ3M6IFBNRUNsay0gRFNJLSBEMSsgRDIrIEF1eEN1cnJlbnQ9MG1BIFBNRShEMC0sRDEt
LEQyLSxEM2hvdC0sRDNjb2xkLSkNCgkJU3RhdHVzOiBEMCBOb1NvZnRSc3QtIFBNRS1FbmFi
bGUtIERTZWw9MCBEU2NhbGU9MCBQTUUtDQoJQ2FwYWJpbGl0aWVzOiBbNThdIEV4cHJlc3Mg
KHYyKSBMZWdhY3kgRW5kcG9pbnQsIE1TSSAwMA0KCQlEZXZDYXA6CU1heFBheWxvYWQgMTI4
IGJ5dGVzLCBQaGFudEZ1bmMgMCwgTGF0ZW5jeSBMMHMgPDR1cywgTDEgdW5saW1pdGVkDQoJ
CQlFeHRUYWcrIEF0dG5CdG4tIEF0dG5JbmQtIFB3ckluZC0gUkJFKyBGTFJlc2V0LQ0KCQlE
ZXZDdGw6CVJlcG9ydCBlcnJvcnM6IENvcnJlY3RhYmxlLSBOb24tRmF0YWwtIEZhdGFsLSBV
bnN1cHBvcnRlZC0NCgkJCVJseGRPcmQrIEV4dFRhZy0gUGhhbnRGdW5jLSBBdXhQd3ItIE5v
U25vb3ArDQoJCQlNYXhQYXlsb2FkIDEyOCBieXRlcywgTWF4UmVhZFJlcSAxMjggYnl0ZXMN
CgkJRGV2U3RhOglDb3JyRXJyLSBVbmNvcnJFcnItIEZhdGFsRXJyLSBVbnN1cHBSZXEtIEF1
eFB3ci0gVHJhbnNQZW5kLQ0KCQlMbmtDYXA6CVBvcnQgIzAsIFNwZWVkIDIuNUdUL3MsIFdp
ZHRoIHgxNiwgQVNQTSBMMHMgTDEsIExhdGVuY3kgTDAgPDY0bnMsIEwxIDwxdXMNCgkJCUNs
b2NrUE0tIFN1cnByaXNlLSBMTEFjdFJlcC0gQndOb3QtDQoJCUxua0N0bDoJQVNQTSBEaXNh
YmxlZDsgUkNCIDY0IGJ5dGVzIERpc2FibGVkLSBSZXRyYWluLSBDb21tQ2xrKw0KCQkJRXh0
U3luY2gtIENsb2NrUE0tIEF1dFdpZERpcy0gQldJbnQtIEF1dEJXSW50LQ0KCQlMbmtTdGE6
CVNwZWVkIDIuNUdUL3MsIFdpZHRoIHgxLCBUckVyci0gVHJhaW4tIFNsb3RDbGsrIERMQWN0
aXZlLSBCV01nbXQtIEFCV01nbXQtDQoJCURldkNhcDI6IENvbXBsZXRpb24gVGltZW91dDog
Tm90IFN1cHBvcnRlZCwgVGltZW91dERpcy0NCgkJRGV2Q3RsMjogQ29tcGxldGlvbiBUaW1l
b3V0OiA1MHVzIHRvIDUwbXMsIFRpbWVvdXREaXMtDQoJCUxua0N0bDI6IFRhcmdldCBMaW5r
IFNwZWVkOiAyLjVHVC9zLCBFbnRlckNvbXBsaWFuY2UtIFNwZWVkRGlzLSwgU2VsZWN0YWJs
ZSBEZS1lbXBoYXNpczogLTZkQg0KCQkJIFRyYW5zbWl0IE1hcmdpbjogTm9ybWFsIE9wZXJh
dGluZyBSYW5nZSwgRW50ZXJNb2RpZmllZENvbXBsaWFuY2UtIENvbXBsaWFuY2VTT1MtDQoJ
CQkgQ29tcGxpYW5jZSBEZS1lbXBoYXNpczogLTZkQg0KCQlMbmtTdGEyOiBDdXJyZW50IERl
LWVtcGhhc2lzIExldmVsOiAtNmRCDQoJQ2FwYWJpbGl0aWVzOiBbYTBdIE1TSTogRW5hYmxl
KyBDb3VudD0xLzEgTWFza2FibGUtIDY0Yml0Kw0KCQlBZGRyZXNzOiAwMDAwMDAwMGZlZTAx
MDBjICBEYXRhOiA0MTJhDQoJQ2FwYWJpbGl0aWVzOiBbMTAwIHYxXSBWZW5kb3IgU3BlY2lm
aWMgSW5mb3JtYXRpb246IElEPTAwMDEgUmV2PTEgTGVuPTAxMCA8Pz4NCglLZXJuZWwgZHJp
dmVyIGluIHVzZTogc25kX2hkYV9pbnRlbA0KDQowNzowMC4wIE11bHRpbWVkaWEgdmlkZW8g
Y29udHJvbGxlciBbMDQwMF06IENvbmV4YW50IFN5c3RlbXMsIEluYy4gRGV2aWNlIFsxNGYx
OjgyMTBdDQoJQ29udHJvbDogSS9PLSBNZW0rIEJ1c01hc3RlcisgU3BlY0N5Y2xlLSBNZW1X
SU5WLSBWR0FTbm9vcC0gUGFyRXJyLSBTdGVwcGluZy0gU0VSUi0gRmFzdEIyQi0gRGlzSU5U
eC0NCglTdGF0dXM6IENhcCsgNjZNSHotIFVERi0gRmFzdEIyQi0gUGFyRXJyLSBERVZTRUw9
ZmFzdCA+VEFib3J0LSA8VEFib3J0LSA8TUFib3J0LSA+U0VSUi0gPFBFUlItIElOVHgtDQoJ
TGF0ZW5jeTogMA0KCUludGVycnVwdDogcGluIEEgcm91dGVkIHRvIElSUSA0Nw0KCVJlZ2lv
biAwOiBNZW1vcnkgYXQgZjlhMDAwMDAgKDY0LWJpdCwgbm9uLXByZWZldGNoYWJsZSkgW3Np
emU9Mk1dDQoJQ2FwYWJpbGl0aWVzOiBbNDBdIEV4cHJlc3MgKHYxKSBFbmRwb2ludCwgTVNJ
IDAwDQoJCURldkNhcDoJTWF4UGF5bG9hZCAxMjggYnl0ZXMsIFBoYW50RnVuYyAwLCBMYXRl
bmN5IEwwcyA8NjRucywgTDEgPDF1cw0KCQkJRXh0VGFnLSBBdHRuQnRuLSBBdHRuSW5kLSBQ
d3JJbmQtIFJCRSsgRkxSZXNldC0NCgkJRGV2Q3RsOglSZXBvcnQgZXJyb3JzOiBDb3JyZWN0
YWJsZS0gTm9uLUZhdGFsLSBGYXRhbC0gVW5zdXBwb3J0ZWQtDQoJCQlSbHhkT3JkKyBFeHRU
YWctIFBoYW50RnVuYy0gQXV4UHdyLSBOb1Nub29wKw0KCQkJTWF4UGF5bG9hZCAxMjggYnl0
ZXMsIE1heFJlYWRSZXEgNTEyIGJ5dGVzDQoJCURldlN0YToJQ29yckVycisgVW5jb3JyRXJy
LSBGYXRhbEVyci0gVW5zdXBwUmVxKyBBdXhQd3ItIFRyYW5zUGVuZC0NCgkJTG5rQ2FwOglQ
b3J0ICMwLCBTcGVlZCAyLjVHVC9zLCBXaWR0aCB4MSwgQVNQTSBMMHMgTDEsIExhdGVuY3kg
TDAgPDJ1cywgTDEgPDR1cw0KCQkJQ2xvY2tQTS0gU3VycHJpc2UtIExMQWN0UmVwLSBCd05v
dC0NCgkJTG5rQ3RsOglBU1BNIERpc2FibGVkOyBSQ0IgNjQgYnl0ZXMgRGlzYWJsZWQtIFJl
dHJhaW4tIENvbW1DbGstDQoJCQlFeHRTeW5jaC0gQ2xvY2tQTS0gQXV0V2lkRGlzLSBCV0lu
dC0gQXV0QldJbnQtDQoJCUxua1N0YToJU3BlZWQgMi41R1QvcywgV2lkdGggeDEsIFRyRXJy
LSBUcmFpbi0gU2xvdENsay0gRExBY3RpdmUtIEJXTWdtdC0gQUJXTWdtdC0NCglDYXBhYmls
aXRpZXM6IFs4MF0gUG93ZXIgTWFuYWdlbWVudCB2ZXJzaW9uIDMNCgkJRmxhZ3M6IFBNRUNs
ay0gRFNJKyBEMSsgRDIrIEF1eEN1cnJlbnQ9MG1BIFBNRShEMCssRDErLEQyKyxEM2hvdCss
RDNjb2xkLSkNCgkJU3RhdHVzOiBEMCBOb1NvZnRSc3QrIFBNRS1FbmFibGUtIERTZWw9MCBE
U2NhbGU9MCBQTUUtDQoJQ2FwYWJpbGl0aWVzOiBbOTBdIFZpdGFsIFByb2R1Y3QgRGF0YQ0K
CQlVbmtub3duIHNtYWxsIHJlc291cmNlIHR5cGUgMDIsIHdpbGwgbm90IGRlY29kZSBtb3Jl
Lg0KCUNhcGFiaWxpdGllczogW2EwXSBNU0k6IEVuYWJsZS0gQ291bnQ9MS8xIE1hc2thYmxl
LSA2NGJpdCsNCgkJQWRkcmVzczogMDAwMDAwMDAwMDAwMDAwMCAgRGF0YTogMDAwMA0KCUNh
cGFiaWxpdGllczogWzEwMCB2MV0gQWR2YW5jZWQgRXJyb3IgUmVwb3J0aW5nDQoJCVVFU3Rh
OglETFAtIFNERVMtIFRMUC0gRkNQLSBDbXBsdFRPLSBDbXBsdEFicnQtIFVueENtcGx0LSBS
eE9GLSBNYWxmVExQLSBFQ1JDLSBVbnN1cFJlcS0gQUNTVmlvbC0NCgkJVUVNc2s6CURMUC0g
U0RFUy0gVExQLSBGQ1AtIENtcGx0VE8tIENtcGx0QWJydC0gVW54Q21wbHQtIFJ4T0YtIE1h
bGZUTFAtIEVDUkMtIFVuc3VwUmVxLSBBQ1NWaW9sLQ0KCQlVRVN2cnQ6CURMUCsgU0RFUy0g
VExQLSBGQ1ArIENtcGx0VE8tIENtcGx0QWJydC0gVW54Q21wbHQtIFJ4T0YrIE1hbGZUTFAr
IEVDUkMtIFVuc3VwUmVxLSBBQ1NWaW9sLQ0KCQlDRVN0YToJUnhFcnItIEJhZFRMUC0gQmFk
RExMUC0gUm9sbG92ZXItIFRpbWVvdXQtIE5vbkZhdGFsRXJyKw0KCQlDRU1zazoJUnhFcnIt
IEJhZFRMUC0gQmFkRExMUC0gUm9sbG92ZXItIFRpbWVvdXQtIE5vbkZhdGFsRXJyKw0KCQlB
RVJDYXA6CUZpcnN0IEVycm9yIFBvaW50ZXI6IDAwLCBHZW5DYXAtIENHZW5Fbi0gQ2hrQ2Fw
LSBDaGtFbi0NCglDYXBhYmlsaXRpZXM6IFsyMDAgdjFdIFZpcnR1YWwgQ2hhbm5lbA0KCQlD
YXBzOglMUEVWQz0xIFJlZkNsaz0xMDBucyBQQVRFbnRyeUJpdHM9MQ0KCQlBcmI6CUZpeGVk
KyBXUlIzMisgV1JSNjQrIFdSUjEyOC0NCgkJQ3RybDoJQXJiU2VsZWN0PVdSUjY0DQoJCVN0
YXR1czoJSW5Qcm9ncmVzcy0NCgkJUG9ydCBBcmJpdHJhdGlvbiBUYWJsZSBbMjQwXSA8Pz4N
CgkJVkMwOglDYXBzOglQQVRPZmZzZXQ9MDAgTWF4VGltZVNsb3RzPTEgUmVqU25vb3BUcmFu
cy0NCgkJCUFyYjoJRml4ZWQtIFdSUjMyLSBXUlI2NC0gV1JSMTI4LSBUV1JSMTI4LSBXUlIy
NTYtDQoJCQlDdHJsOglFbmFibGUrIElEPTAgQXJiU2VsZWN0PUZpeGVkIFRDL1ZDPWZmDQoJ
CQlTdGF0dXM6CU5lZ29QZW5kaW5nLSBJblByb2dyZXNzLQ0KCQlWQzE6CUNhcHM6CVBBVE9m
ZnNldD0wMCBNYXhUaW1lU2xvdHM9MSBSZWpTbm9vcFRyYW5zLQ0KCQkJQXJiOglGaXhlZC0g
V1JSMzItIFdSUjY0LSBXUlIxMjgtIFRXUlIxMjgtIFdSUjI1Ni0NCgkJCUN0cmw6CUVuYWJs
ZS0gSUQ9MSBBcmJTZWxlY3Q9Rml4ZWQgVEMvVkM9MDANCgkJCVN0YXR1czoJTmVnb1BlbmRp
bmctIEluUHJvZ3Jlc3MtDQoJS2VybmVsIGRyaXZlciBpbiB1c2U6IHBjaWJhY2sNCg0KMDg6
MDAuMCBFdGhlcm5ldCBjb250cm9sbGVyIFswMjAwXTogUmVhbHRlayBTZW1pY29uZHVjdG9y
IENvLiwgTHRkLiBSVEw4MTExLzgxNjhCIFBDSSBFeHByZXNzIEdpZ2FiaXQgRXRoZXJuZXQg
Y29udHJvbGxlciBbMTBlYzo4MTY4XSAocmV2IDAzKQ0KCVN1YnN5c3RlbTogTWljcm8tU3Rh
ciBJbnRlcm5hdGlvbmFsIENvLiwgTHRkLiBEZXZpY2UgWzE0NjI6NzY0MF0NCglDb250cm9s
OiBJL08rIE1lbSsgQnVzTWFzdGVyKyBTcGVjQ3ljbGUtIE1lbVdJTlYtIFZHQVNub29wLSBQ
YXJFcnItIFN0ZXBwaW5nLSBTRVJSKyBGYXN0QjJCLSBEaXNJTlR4Kw0KCVN0YXR1czogQ2Fw
KyA2Nk1Iei0gVURGLSBGYXN0QjJCLSBQYXJFcnItIERFVlNFTD1mYXN0ID5UQWJvcnQtIDxU
QWJvcnQtIDxNQWJvcnQtID5TRVJSLSA8UEVSUi0gSU5UeC0NCglMYXRlbmN5OiAwLCBDYWNo
ZSBMaW5lIFNpemU6IDY0IGJ5dGVzDQoJSW50ZXJydXB0OiBwaW4gQSByb3V0ZWQgdG8gSVJR
IDEyMg0KCVJlZ2lvbiAwOiBJL08gcG9ydHMgYXQgYzgwMCBbc2l6ZT0yNTZdDQoJUmVnaW9u
IDI6IE1lbW9yeSBhdCBjZmVmZjAwMCAoNjQtYml0LCBwcmVmZXRjaGFibGUpIFtzaXplPTRL
XQ0KCVJlZ2lvbiA0OiBNZW1vcnkgYXQgY2ZlZjgwMDAgKDY0LWJpdCwgcHJlZmV0Y2hhYmxl
KSBbc2l6ZT0xNktdDQoJRXhwYW5zaW9uIFJPTSBhdCBmOWRlMDAwMCBbZGlzYWJsZWRdIFtz
aXplPTEyOEtdDQoJQ2FwYWJpbGl0aWVzOiBbNDBdIFBvd2VyIE1hbmFnZW1lbnQgdmVyc2lv
biAzDQoJCUZsYWdzOiBQTUVDbGstIERTSS0gRDErIEQyKyBBdXhDdXJyZW50PTM3NW1BIFBN
RShEMCssRDErLEQyKyxEM2hvdCssRDNjb2xkKykNCgkJU3RhdHVzOiBEMCBOb1NvZnRSc3Qr
IFBNRS1FbmFibGUtIERTZWw9MCBEU2NhbGU9MCBQTUUtDQoJQ2FwYWJpbGl0aWVzOiBbNTBd
IE1TSTogRW5hYmxlKyBDb3VudD0xLzEgTWFza2FibGUtIDY0Yml0Kw0KCQlBZGRyZXNzOiAw
MDAwMDAwMGZlZTAyMDBjICBEYXRhOiA0MWQ5DQoJQ2FwYWJpbGl0aWVzOiBbNzBdIEV4cHJl
c3MgKHYyKSBFbmRwb2ludCwgTVNJIDAxDQoJCURldkNhcDoJTWF4UGF5bG9hZCAyNTYgYnl0
ZXMsIFBoYW50RnVuYyAwLCBMYXRlbmN5IEwwcyA8NTEybnMsIEwxIDw2NHVzDQoJCQlFeHRU
YWctIEF0dG5CdG4tIEF0dG5JbmQtIFB3ckluZC0gUkJFKyBGTFJlc2V0LQ0KCQlEZXZDdGw6
CVJlcG9ydCBlcnJvcnM6IENvcnJlY3RhYmxlLSBOb24tRmF0YWwtIEZhdGFsLSBVbnN1cHBv
cnRlZC0NCgkJCVJseGRPcmQtIEV4dFRhZy0gUGhhbnRGdW5jLSBBdXhQd3ItIE5vU25vb3At
DQoJCQlNYXhQYXlsb2FkIDEyOCBieXRlcywgTWF4UmVhZFJlcSA1MTIgYnl0ZXMNCgkJRGV2
U3RhOglDb3JyRXJyKyBVbmNvcnJFcnItIEZhdGFsRXJyLSBVbnN1cHBSZXErIEF1eFB3cisg
VHJhbnNQZW5kLQ0KCQlMbmtDYXA6CVBvcnQgIzAsIFNwZWVkIDIuNUdUL3MsIFdpZHRoIHgx
LCBBU1BNIEwwcyBMMSwgTGF0ZW5jeSBMMCA8NTEybnMsIEwxIDw2NHVzDQoJCQlDbG9ja1BN
KyBTdXJwcmlzZS0gTExBY3RSZXAtIEJ3Tm90LQ0KCQlMbmtDdGw6CUFTUE0gRGlzYWJsZWQ7
IFJDQiA2NCBieXRlcyBEaXNhYmxlZC0gUmV0cmFpbi0gQ29tbUNsaysNCgkJCUV4dFN5bmNo
LSBDbG9ja1BNLSBBdXRXaWREaXMtIEJXSW50LSBBdXRCV0ludC0NCgkJTG5rU3RhOglTcGVl
ZCAyLjVHVC9zLCBXaWR0aCB4MSwgVHJFcnItIFRyYWluLSBTbG90Q2xrKyBETEFjdGl2ZS0g
QldNZ210LSBBQldNZ210LQ0KCQlEZXZDYXAyOiBDb21wbGV0aW9uIFRpbWVvdXQ6IE5vdCBT
dXBwb3J0ZWQsIFRpbWVvdXREaXMrDQoJCURldkN0bDI6IENvbXBsZXRpb24gVGltZW91dDog
NTB1cyB0byA1MG1zLCBUaW1lb3V0RGlzLQ0KCQlMbmtDdGwyOiBUYXJnZXQgTGluayBTcGVl
ZDogMi41R1QvcywgRW50ZXJDb21wbGlhbmNlLSBTcGVlZERpcy0sIFNlbGVjdGFibGUgRGUt
ZW1waGFzaXM6IC02ZEINCgkJCSBUcmFuc21pdCBNYXJnaW46IE5vcm1hbCBPcGVyYXRpbmcg
UmFuZ2UsIEVudGVyTW9kaWZpZWRDb21wbGlhbmNlLSBDb21wbGlhbmNlU09TLQ0KCQkJIENv
bXBsaWFuY2UgRGUtZW1waGFzaXM6IC02ZEINCgkJTG5rU3RhMjogQ3VycmVudCBEZS1lbXBo
YXNpcyBMZXZlbDogLTZkQg0KCUNhcGFiaWxpdGllczogW2FjXSBNU0ktWDogRW5hYmxlLSBD
b3VudD00IE1hc2tlZC0NCgkJVmVjdG9yIHRhYmxlOiBCQVI9NCBvZmZzZXQ9MDAwMDAwMDAN
CgkJUEJBOiBCQVI9NCBvZmZzZXQ9MDAwMDA4MDANCglDYXBhYmlsaXRpZXM6IFtjY10gVml0
YWwgUHJvZHVjdCBEYXRhDQoJCVVua25vd24gc21hbGwgcmVzb3VyY2UgdHlwZSAwMCwgd2ls
bCBub3QgZGVjb2RlIG1vcmUuDQoJQ2FwYWJpbGl0aWVzOiBbMTAwIHYxXSBBZHZhbmNlZCBF
cnJvciBSZXBvcnRpbmcNCgkJVUVTdGE6CURMUC0gU0RFUy0gVExQLSBGQ1AtIENtcGx0VE8t
IENtcGx0QWJydC0gVW54Q21wbHQtIFJ4T0YtIE1hbGZUTFAtIEVDUkMtIFVuc3VwUmVxLSBB
Q1NWaW9sLQ0KCQlVRU1zazoJRExQLSBTREVTLSBUTFAtIEZDUC0gQ21wbHRUTy0gQ21wbHRB
YnJ0LSBVbnhDbXBsdC0gUnhPRi0gTWFsZlRMUC0gRUNSQy0gVW5zdXBSZXEtIEFDU1Zpb2wt
DQoJCVVFU3ZydDoJRExQKyBTREVTKyBUTFAtIEZDUCsgQ21wbHRUTy0gQ21wbHRBYnJ0LSBV
bnhDbXBsdC0gUnhPRisgTWFsZlRMUCsgRUNSQy0gVW5zdXBSZXEtIEFDU1Zpb2wtDQoJCUNF
U3RhOglSeEVycisgQmFkVExQLSBCYWRETExQLSBSb2xsb3Zlci0gVGltZW91dC0gTm9uRmF0
YWxFcnIrDQoJCUNFTXNrOglSeEVyci0gQmFkVExQLSBCYWRETExQLSBSb2xsb3Zlci0gVGlt
ZW91dC0gTm9uRmF0YWxFcnIrDQoJCUFFUkNhcDoJRmlyc3QgRXJyb3IgUG9pbnRlcjogMDAs
IEdlbkNhcCsgQ0dlbkVuLSBDaGtDYXArIENoa0VuLQ0KCUNhcGFiaWxpdGllczogWzE0MCB2
MV0gVmlydHVhbCBDaGFubmVsDQoJCUNhcHM6CUxQRVZDPTAgUmVmQ2xrPTEwMG5zIFBBVEVu
dHJ5Qml0cz0xDQoJCUFyYjoJRml4ZWQtIFdSUjMyLSBXUlI2NC0gV1JSMTI4LQ0KCQlDdHJs
OglBcmJTZWxlY3Q9Rml4ZWQNCgkJU3RhdHVzOglJblByb2dyZXNzLQ0KCQlWQzA6CUNhcHM6
CVBBVE9mZnNldD0wMCBNYXhUaW1lU2xvdHM9MSBSZWpTbm9vcFRyYW5zLQ0KCQkJQXJiOglG
aXhlZC0gV1JSMzItIFdSUjY0LSBXUlIxMjgtIFRXUlIxMjgtIFdSUjI1Ni0NCgkJCUN0cmw6
CUVuYWJsZSsgSUQ9MCBBcmJTZWxlY3Q9Rml4ZWQgVEMvVkM9ZmYNCgkJCVN0YXR1czoJTmVn
b1BlbmRpbmctIEluUHJvZ3Jlc3MtDQoJQ2FwYWJpbGl0aWVzOiBbMTYwIHYxXSBEZXZpY2Ug
U2VyaWFsIE51bWJlciAwMy0wMC0wMC0wMC02OC00Yy1lMC0wMA0KCUtlcm5lbCBkcml2ZXIg
aW4gdXNlOiByODE2OQ0KDQowOTowMC4wIEV0aGVybmV0IGNvbnRyb2xsZXIgWzAyMDBdOiBS
ZWFsdGVrIFNlbWljb25kdWN0b3IgQ28uLCBMdGQuIFJUTDgxMTEvODE2OEIgUENJIEV4cHJl
c3MgR2lnYWJpdCBFdGhlcm5ldCBjb250cm9sbGVyIFsxMGVjOjgxNjhdIChyZXYgMDMpDQoJ
U3Vic3lzdGVtOiBNaWNyby1TdGFyIEludGVybmF0aW9uYWwgQ28uLCBMdGQuIERldmljZSBb
MTQ2Mjo3NjQwXQ0KCUNvbnRyb2w6IEkvTysgTWVtKyBCdXNNYXN0ZXIrIFNwZWNDeWNsZS0g
TWVtV0lOVi0gVkdBU25vb3AtIFBhckVyci0gU3RlcHBpbmctIFNFUlIrIEZhc3RCMkItIERp
c0lOVHgrDQoJU3RhdHVzOiBDYXArIDY2TUh6LSBVREYtIEZhc3RCMkItIFBhckVyci0gREVW
U0VMPWZhc3QgPlRBYm9ydC0gPFRBYm9ydC0gPE1BYm9ydC0gPlNFUlItIDxQRVJSLSBJTlR4
LQ0KCUxhdGVuY3k6IDAsIENhY2hlIExpbmUgU2l6ZTogNjQgYnl0ZXMNCglJbnRlcnJ1cHQ6
IHBpbiBBIHJvdXRlZCB0byBJUlEgMTIxDQoJUmVnaW9uIDA6IEkvTyBwb3J0cyBhdCBkODAw
IFtzaXplPTI1Nl0NCglSZWdpb24gMjogTWVtb3J5IGF0IGNmZmZmMDAwICg2NC1iaXQsIHBy
ZWZldGNoYWJsZSkgW3NpemU9NEtdDQoJUmVnaW9uIDQ6IE1lbW9yeSBhdCBjZmZmODAwMCAo
NjQtYml0LCBwcmVmZXRjaGFibGUpIFtzaXplPTE2S10NCglFeHBhbnNpb24gUk9NIGF0IGY5
ZWUwMDAwIFtkaXNhYmxlZF0gW3NpemU9MTI4S10NCglDYXBhYmlsaXRpZXM6IFs0MF0gUG93
ZXIgTWFuYWdlbWVudCB2ZXJzaW9uIDMNCgkJRmxhZ3M6IFBNRUNsay0gRFNJLSBEMSsgRDIr
IEF1eEN1cnJlbnQ9Mzc1bUEgUE1FKEQwKyxEMSssRDIrLEQzaG90KyxEM2NvbGQrKQ0KCQlT
dGF0dXM6IEQwIE5vU29mdFJzdCsgUE1FLUVuYWJsZS0gRFNlbD0wIERTY2FsZT0wIFBNRS0N
CglDYXBhYmlsaXRpZXM6IFs1MF0gTVNJOiBFbmFibGUrIENvdW50PTEvMSBNYXNrYWJsZS0g
NjRiaXQrDQoJCUFkZHJlc3M6IDAwMDAwMDAwZmVlMDEwMGMgIERhdGE6IDQxYzkNCglDYXBh
YmlsaXRpZXM6IFs3MF0gRXhwcmVzcyAodjIpIEVuZHBvaW50LCBNU0kgMDENCgkJRGV2Q2Fw
OglNYXhQYXlsb2FkIDI1NiBieXRlcywgUGhhbnRGdW5jIDAsIExhdGVuY3kgTDBzIDw1MTJu
cywgTDEgPDY0dXMNCgkJCUV4dFRhZy0gQXR0bkJ0bi0gQXR0bkluZC0gUHdySW5kLSBSQkUr
IEZMUmVzZXQtDQoJCURldkN0bDoJUmVwb3J0IGVycm9yczogQ29ycmVjdGFibGUtIE5vbi1G
YXRhbC0gRmF0YWwtIFVuc3VwcG9ydGVkLQ0KCQkJUmx4ZE9yZC0gRXh0VGFnLSBQaGFudEZ1
bmMtIEF1eFB3ci0gTm9Tbm9vcC0NCgkJCU1heFBheWxvYWQgMTI4IGJ5dGVzLCBNYXhSZWFk
UmVxIDQwOTYgYnl0ZXMNCgkJRGV2U3RhOglDb3JyRXJyKyBVbmNvcnJFcnItIEZhdGFsRXJy
LSBVbnN1cHBSZXErIEF1eFB3cisgVHJhbnNQZW5kLQ0KCQlMbmtDYXA6CVBvcnQgIzAsIFNw
ZWVkIDIuNUdUL3MsIFdpZHRoIHgxLCBBU1BNIEwwcyBMMSwgTGF0ZW5jeSBMMCA8NTEybnMs
IEwxIDw2NHVzDQoJCQlDbG9ja1BNKyBTdXJwcmlzZS0gTExBY3RSZXAtIEJ3Tm90LQ0KCQlM
bmtDdGw6CUFTUE0gRGlzYWJsZWQ7IFJDQiA2NCBieXRlcyBEaXNhYmxlZC0gUmV0cmFpbi0g
Q29tbUNsaysNCgkJCUV4dFN5bmNoLSBDbG9ja1BNLSBBdXRXaWREaXMtIEJXSW50LSBBdXRC
V0ludC0NCgkJTG5rU3RhOglTcGVlZCAyLjVHVC9zLCBXaWR0aCB4MSwgVHJFcnItIFRyYWlu
LSBTbG90Q2xrKyBETEFjdGl2ZS0gQldNZ210LSBBQldNZ210LQ0KCQlEZXZDYXAyOiBDb21w
bGV0aW9uIFRpbWVvdXQ6IE5vdCBTdXBwb3J0ZWQsIFRpbWVvdXREaXMrDQoJCURldkN0bDI6
IENvbXBsZXRpb24gVGltZW91dDogNTB1cyB0byA1MG1zLCBUaW1lb3V0RGlzLQ0KCQlMbmtD
dGwyOiBUYXJnZXQgTGluayBTcGVlZDogMi41R1QvcywgRW50ZXJDb21wbGlhbmNlLSBTcGVl
ZERpcy0sIFNlbGVjdGFibGUgRGUtZW1waGFzaXM6IC02ZEINCgkJCSBUcmFuc21pdCBNYXJn
aW46IE5vcm1hbCBPcGVyYXRpbmcgUmFuZ2UsIEVudGVyTW9kaWZpZWRDb21wbGlhbmNlLSBD
b21wbGlhbmNlU09TLQ0KCQkJIENvbXBsaWFuY2UgRGUtZW1waGFzaXM6IC02ZEINCgkJTG5r
U3RhMjogQ3VycmVudCBEZS1lbXBoYXNpcyBMZXZlbDogLTZkQg0KCUNhcGFiaWxpdGllczog
W2FjXSBNU0ktWDogRW5hYmxlLSBDb3VudD00IE1hc2tlZC0NCgkJVmVjdG9yIHRhYmxlOiBC
QVI9NCBvZmZzZXQ9MDAwMDAwMDANCgkJUEJBOiBCQVI9NCBvZmZzZXQ9MDAwMDA4MDANCglD
YXBhYmlsaXRpZXM6IFtjY10gVml0YWwgUHJvZHVjdCBEYXRhDQoJCVVua25vd24gc21hbGwg
cmVzb3VyY2UgdHlwZSAwMCwgd2lsbCBub3QgZGVjb2RlIG1vcmUuDQoJQ2FwYWJpbGl0aWVz
OiBbMTAwIHYxXSBBZHZhbmNlZCBFcnJvciBSZXBvcnRpbmcNCgkJVUVTdGE6CURMUC0gU0RF
Uy0gVExQLSBGQ1AtIENtcGx0VE8tIENtcGx0QWJydC0gVW54Q21wbHQtIFJ4T0YtIE1hbGZU
TFAtIEVDUkMtIFVuc3VwUmVxLSBBQ1NWaW9sLQ0KCQlVRU1zazoJRExQLSBTREVTLSBUTFAt
IEZDUC0gQ21wbHRUTy0gQ21wbHRBYnJ0LSBVbnhDbXBsdC0gUnhPRi0gTWFsZlRMUC0gRUNS
Qy0gVW5zdXBSZXEtIEFDU1Zpb2wtDQoJCVVFU3ZydDoJRExQKyBTREVTKyBUTFAtIEZDUCsg
Q21wbHRUTy0gQ21wbHRBYnJ0LSBVbnhDbXBsdC0gUnhPRisgTWFsZlRMUCsgRUNSQy0gVW5z
dXBSZXEtIEFDU1Zpb2wtDQoJCUNFU3RhOglSeEVycisgQmFkVExQLSBCYWRETExQLSBSb2xs
b3Zlci0gVGltZW91dC0gTm9uRmF0YWxFcnIrDQoJCUNFTXNrOglSeEVyci0gQmFkVExQLSBC
YWRETExQLSBSb2xsb3Zlci0gVGltZW91dC0gTm9uRmF0YWxFcnIrDQoJCUFFUkNhcDoJRmly
c3QgRXJyb3IgUG9pbnRlcjogMDAsIEdlbkNhcCsgQ0dlbkVuLSBDaGtDYXArIENoa0VuLQ0K
CUNhcGFiaWxpdGllczogWzE0MCB2MV0gVmlydHVhbCBDaGFubmVsDQoJCUNhcHM6CUxQRVZD
PTAgUmVmQ2xrPTEwMG5zIFBBVEVudHJ5Qml0cz0xDQoJCUFyYjoJRml4ZWQtIFdSUjMyLSBX
UlI2NC0gV1JSMTI4LQ0KCQlDdHJsOglBcmJTZWxlY3Q9Rml4ZWQNCgkJU3RhdHVzOglJblBy
b2dyZXNzLQ0KCQlWQzA6CUNhcHM6CVBBVE9mZnNldD0wMCBNYXhUaW1lU2xvdHM9MSBSZWpT
bm9vcFRyYW5zLQ0KCQkJQXJiOglGaXhlZC0gV1JSMzItIFdSUjY0LSBXUlIxMjgtIFRXUlIx
MjgtIFdSUjI1Ni0NCgkJCUN0cmw6CUVuYWJsZSsgSUQ9MCBBcmJTZWxlY3Q9Rml4ZWQgVEMv
VkM9ZmYNCgkJCVN0YXR1czoJTmVnb1BlbmRpbmctIEluUHJvZ3Jlc3MtDQoJQ2FwYWJpbGl0
aWVzOiBbMTYwIHYxXSBEZXZpY2UgU2VyaWFsIE51bWJlciAwNC0wMC0wMC0wMC02OC00Yy1l
MC0wMA0KCUtlcm5lbCBkcml2ZXIgaW4gdXNlOiByODE2OQ0KDQowYTowMC4wIFVTQiBjb250
cm9sbGVyIFswYzAzXTogTmV0TW9zIFRlY2hub2xvZ3kgTUNTOTk5MCBQQ0llIHRvIDTigJBQ
b3J0IFVTQiAyLjAgSG9zdCBDb250cm9sbGVyIFs5NzEwOjk5OTBdIChwcm9nLWlmIDEwIFtP
SENJXSkNCglTdWJzeXN0ZW06IERldmljZSBbYTAwMDo0MDAwXQ0KCUNvbnRyb2w6IEkvTy0g
TWVtKyBCdXNNYXN0ZXIrIFNwZWNDeWNsZS0gTWVtV0lOVi0gVkdBU25vb3AtIFBhckVyci0g
U3RlcHBpbmctIFNFUlItIEZhc3RCMkItIERpc0lOVHgtDQoJU3RhdHVzOiBDYXArIDY2TUh6
LSBVREYtIEZhc3RCMkItIFBhckVyci0gREVWU0VMPWZhc3QgPlRBYm9ydC0gPFRBYm9ydC0g
PE1BYm9ydC0gPlNFUlItIDxQRVJSLSBJTlR4LQ0KCUxhdGVuY3k6IDAsIENhY2hlIExpbmUg
U2l6ZTogNjQgYnl0ZXMNCglJbnRlcnJ1cHQ6IHBpbiBBIHJvdXRlZCB0byBJUlEgMjgNCglS
ZWdpb24gMDogTWVtb3J5IGF0IGY5ZmY4MDAwICgzMi1iaXQsIG5vbi1wcmVmZXRjaGFibGUp
IFtzaXplPTRLXQ0KCUNhcGFiaWxpdGllczogWzUwXSBNU0k6IEVuYWJsZS0gQ291bnQ9MS8x
IE1hc2thYmxlLSA2NGJpdCsNCgkJQWRkcmVzczogMDAwMDAwMDAwMDAwMDAwMCAgRGF0YTog
MDAwMA0KCUNhcGFiaWxpdGllczogWzc4XSBQb3dlciBNYW5hZ2VtZW50IHZlcnNpb24gMw0K
CQlGbGFnczogUE1FQ2xrLSBEU0ktIEQxKyBEMisgQXV4Q3VycmVudD0zNzVtQSBQTUUoRDAr
LEQxKyxEMissRDNob3QrLEQzY29sZC0pDQoJCVN0YXR1czogRDAgTm9Tb2Z0UnN0KyBQTUUt
RW5hYmxlLSBEU2VsPTAgRFNjYWxlPTAgUE1FLQ0KCUNhcGFiaWxpdGllczogWzgwXSBFeHBy
ZXNzICh2MSkgRW5kcG9pbnQsIE1TSSAwMA0KCQlEZXZDYXA6CU1heFBheWxvYWQgMjU2IGJ5
dGVzLCBQaGFudEZ1bmMgMCwgTGF0ZW5jeSBMMHMgdW5saW1pdGVkLCBMMSB1bmxpbWl0ZWQN
CgkJCUV4dFRhZy0gQXR0bkJ0bi0gQXR0bkluZC0gUHdySW5kLSBSQkUrIEZMUmVzZXQtDQoJ
CURldkN0bDoJUmVwb3J0IGVycm9yczogQ29ycmVjdGFibGUtIE5vbi1GYXRhbC0gRmF0YWwt
IFVuc3VwcG9ydGVkLQ0KCQkJUmx4ZE9yZC0gRXh0VGFnLSBQaGFudEZ1bmMtIEF1eFB3ci0g
Tm9Tbm9vcCsNCgkJCU1heFBheWxvYWQgMTI4IGJ5dGVzLCBNYXhSZWFkUmVxIDUxMiBieXRl
cw0KCQlEZXZTdGE6CUNvcnJFcnItIFVuY29yckVyci0gRmF0YWxFcnItIFVuc3VwcFJlcS0g
QXV4UHdyLSBUcmFuc1BlbmQtDQoJCUxua0NhcDoJUG9ydCAjMSwgU3BlZWQgMi41R1Qvcywg
V2lkdGggeDEsIEFTUE0gdW5rbm93biwgTGF0ZW5jeSBMMCA8NjRucywgTDEgdW5saW1pdGVk
DQoJCQlDbG9ja1BNKyBTdXJwcmlzZS0gTExBY3RSZXAtIEJ3Tm90LQ0KCQlMbmtDdGw6CUFT
UE0gRGlzYWJsZWQ7IFJDQiA2NCBieXRlcyBEaXNhYmxlZC0gUmV0cmFpbi0gQ29tbUNsay0N
CgkJCUV4dFN5bmNoLSBDbG9ja1BNLSBBdXRXaWREaXMtIEJXSW50LSBBdXRCV0ludC0NCgkJ
TG5rU3RhOglTcGVlZCAyLjVHVC9zLCBXaWR0aCB4MSwgVHJFcnItIFRyYWluLSBTbG90Q2xr
LSBETEFjdGl2ZS0gQldNZ210LSBBQldNZ210LQ0KCUNhcGFiaWxpdGllczogWzEwMCB2MV0g
VmlydHVhbCBDaGFubmVsDQoJCUNhcHM6CUxQRVZDPTAgUmVmQ2xrPTEwMG5zIFBBVEVudHJ5
Qml0cz0xDQoJCUFyYjoJRml4ZWQtIFdSUjMyLSBXUlI2NC0gV1JSMTI4LQ0KCQlDdHJsOglB
cmJTZWxlY3Q9Rml4ZWQNCgkJU3RhdHVzOglJblByb2dyZXNzLQ0KCQlWQzA6CUNhcHM6CVBB
VE9mZnNldD0wMCBNYXhUaW1lU2xvdHM9MSBSZWpTbm9vcFRyYW5zLQ0KCQkJQXJiOglGaXhl
ZC0gV1JSMzItIFdSUjY0LSBXUlIxMjgtIFRXUlIxMjgtIFdSUjI1Ni0NCgkJCUN0cmw6CUVu
YWJsZSsgSUQ9MCBBcmJTZWxlY3Q9Rml4ZWQgVEMvVkM9ZmYNCgkJCVN0YXR1czoJTmVnb1Bl
bmRpbmctIEluUHJvZ3Jlc3MtDQoJS2VybmVsIGRyaXZlciBpbiB1c2U6IHBjaWJhY2sNCg0K
MGE6MDAuMSBVU0IgY29udHJvbGxlciBbMGMwM106IE5ldE1vcyBUZWNobm9sb2d5IE1DUzk5
OTAgUENJZSB0byA04oCQUG9ydCBVU0IgMi4wIEhvc3QgQ29udHJvbGxlciBbOTcxMDo5OTkw
XSAocHJvZy1pZiAyMCBbRUhDSV0pDQoJU3Vic3lzdGVtOiBEZXZpY2UgW2EwMDA6NDAwMF0N
CglDb250cm9sOiBJL08tIE1lbSsgQnVzTWFzdGVyKyBTcGVjQ3ljbGUtIE1lbVdJTlYtIFZH
QVNub29wLSBQYXJFcnItIFN0ZXBwaW5nLSBTRVJSLSBGYXN0QjJCLSBEaXNJTlR4LQ0KCVN0
YXR1czogQ2FwKyA2Nk1Iei0gVURGLSBGYXN0QjJCLSBQYXJFcnItIERFVlNFTD1mYXN0ID5U
QWJvcnQtIDxUQWJvcnQtIDxNQWJvcnQtID5TRVJSLSA8UEVSUi0gSU5UeC0NCglMYXRlbmN5
OiAwLCBDYWNoZSBMaW5lIFNpemU6IDY0IGJ5dGVzDQoJSW50ZXJydXB0OiBwaW4gQSByb3V0
ZWQgdG8gSVJRIDI4DQoJUmVnaW9uIDA6IE1lbW9yeSBhdCBmOWZmOTAwMCAoMzItYml0LCBu
b24tcHJlZmV0Y2hhYmxlKSBbc2l6ZT00S10NCglDYXBhYmlsaXRpZXM6IFs1MF0gTVNJOiBF
bmFibGUtIENvdW50PTEvMSBNYXNrYWJsZS0gNjRiaXQrDQoJCUFkZHJlc3M6IDAwMDAwMDAw
MDAwMDAwMDAgIERhdGE6IDAwMDANCglDYXBhYmlsaXRpZXM6IFs3OF0gUG93ZXIgTWFuYWdl
bWVudCB2ZXJzaW9uIDMNCgkJRmxhZ3M6IFBNRUNsay0gRFNJLSBEMSsgRDIrIEF1eEN1cnJl
bnQ9Mzc1bUEgUE1FKEQwKyxEMSssRDIrLEQzaG90KyxEM2NvbGQtKQ0KCQlTdGF0dXM6IEQw
IE5vU29mdFJzdCsgUE1FLUVuYWJsZS0gRFNlbD0wIERTY2FsZT0wIFBNRS0NCglDYXBhYmls
aXRpZXM6IFs4MF0gRXhwcmVzcyAodjEpIEVuZHBvaW50LCBNU0kgMDANCgkJRGV2Q2FwOglN
YXhQYXlsb2FkIDI1NiBieXRlcywgUGhhbnRGdW5jIDAsIExhdGVuY3kgTDBzIHVubGltaXRl
ZCwgTDEgdW5saW1pdGVkDQoJCQlFeHRUYWctIEF0dG5CdG4tIEF0dG5JbmQtIFB3ckluZC0g
UkJFKyBGTFJlc2V0LQ0KCQlEZXZDdGw6CVJlcG9ydCBlcnJvcnM6IENvcnJlY3RhYmxlLSBO
b24tRmF0YWwtIEZhdGFsLSBVbnN1cHBvcnRlZC0NCgkJCVJseGRPcmQtIEV4dFRhZy0gUGhh
bnRGdW5jLSBBdXhQd3ItIE5vU25vb3ArDQoJCQlNYXhQYXlsb2FkIDEyOCBieXRlcywgTWF4
UmVhZFJlcSA1MTIgYnl0ZXMNCgkJRGV2U3RhOglDb3JyRXJyLSBVbmNvcnJFcnItIEZhdGFs
RXJyLSBVbnN1cHBSZXEtIEF1eFB3ci0gVHJhbnNQZW5kLQ0KCQlMbmtDYXA6CVBvcnQgIzEs
IFNwZWVkIDIuNUdUL3MsIFdpZHRoIHgxLCBBU1BNIHVua25vd24sIExhdGVuY3kgTDAgPDY0
bnMsIEwxIHVubGltaXRlZA0KCQkJQ2xvY2tQTSsgU3VycHJpc2UtIExMQWN0UmVwLSBCd05v
dC0NCgkJTG5rQ3RsOglBU1BNIERpc2FibGVkOyBSQ0IgNjQgYnl0ZXMgRGlzYWJsZWQtIFJl
dHJhaW4tIENvbW1DbGstDQoJCQlFeHRTeW5jaC0gQ2xvY2tQTS0gQXV0V2lkRGlzLSBCV0lu
dC0gQXV0QldJbnQtDQoJCUxua1N0YToJU3BlZWQgMi41R1QvcywgV2lkdGggeDEsIFRyRXJy
LSBUcmFpbi0gU2xvdENsay0gRExBY3RpdmUtIEJXTWdtdC0gQUJXTWdtdC0NCglLZXJuZWwg
ZHJpdmVyIGluIHVzZTogcGNpYmFjaw0KDQowYTowMC4yIFVTQiBjb250cm9sbGVyIFswYzAz
XTogTmV0TW9zIFRlY2hub2xvZ3kgTUNTOTk5MCBQQ0llIHRvIDTigJBQb3J0IFVTQiAyLjAg
SG9zdCBDb250cm9sbGVyIFs5NzEwOjk5OTBdIChwcm9nLWlmIDEwIFtPSENJXSkNCglTdWJz
eXN0ZW06IERldmljZSBbYTAwMDo0MDAwXQ0KCUNvbnRyb2w6IEkvTy0gTWVtKyBCdXNNYXN0
ZXIrIFNwZWNDeWNsZS0gTWVtV0lOVi0gVkdBU25vb3AtIFBhckVyci0gU3RlcHBpbmctIFNF
UlItIEZhc3RCMkItIERpc0lOVHgtDQoJU3RhdHVzOiBDYXArIDY2TUh6LSBVREYtIEZhc3RC
MkItIFBhckVyci0gREVWU0VMPWZhc3QgPlRBYm9ydC0gPFRBYm9ydC0gPE1BYm9ydC0gPlNF
UlItIDxQRVJSLSBJTlR4LQ0KCUxhdGVuY3k6IDAsIENhY2hlIExpbmUgU2l6ZTogNjQgYnl0
ZXMNCglJbnRlcnJ1cHQ6IHBpbiBCIHJvdXRlZCB0byBJUlEgMjkNCglSZWdpb24gMDogTWVt
b3J5IGF0IGY5ZmZhMDAwICgzMi1iaXQsIG5vbi1wcmVmZXRjaGFibGUpIFtzaXplPTRLXQ0K
CUNhcGFiaWxpdGllczogWzUwXSBNU0k6IEVuYWJsZS0gQ291bnQ9MS8xIE1hc2thYmxlLSA2
NGJpdCsNCgkJQWRkcmVzczogMDAwMDAwMDAwMDAwMDAwMCAgRGF0YTogMDAwMA0KCUNhcGFi
aWxpdGllczogWzc4XSBQb3dlciBNYW5hZ2VtZW50IHZlcnNpb24gMw0KCQlGbGFnczogUE1F
Q2xrLSBEU0ktIEQxKyBEMisgQXV4Q3VycmVudD0zNzVtQSBQTUUoRDArLEQxKyxEMissRDNo
b3QrLEQzY29sZC0pDQoJCVN0YXR1czogRDAgTm9Tb2Z0UnN0KyBQTUUtRW5hYmxlLSBEU2Vs
PTAgRFNjYWxlPTAgUE1FLQ0KCUNhcGFiaWxpdGllczogWzgwXSBFeHByZXNzICh2MSkgRW5k
cG9pbnQsIE1TSSAwMA0KCQlEZXZDYXA6CU1heFBheWxvYWQgMjU2IGJ5dGVzLCBQaGFudEZ1
bmMgMCwgTGF0ZW5jeSBMMHMgdW5saW1pdGVkLCBMMSB1bmxpbWl0ZWQNCgkJCUV4dFRhZy0g
QXR0bkJ0bi0gQXR0bkluZC0gUHdySW5kLSBSQkUrIEZMUmVzZXQtDQoJCURldkN0bDoJUmVw
b3J0IGVycm9yczogQ29ycmVjdGFibGUtIE5vbi1GYXRhbC0gRmF0YWwtIFVuc3VwcG9ydGVk
LQ0KCQkJUmx4ZE9yZC0gRXh0VGFnLSBQaGFudEZ1bmMtIEF1eFB3ci0gTm9Tbm9vcCsNCgkJ
CU1heFBheWxvYWQgMTI4IGJ5dGVzLCBNYXhSZWFkUmVxIDUxMiBieXRlcw0KCQlEZXZTdGE6
CUNvcnJFcnItIFVuY29yckVyci0gRmF0YWxFcnItIFVuc3VwcFJlcS0gQXV4UHdyLSBUcmFu
c1BlbmQtDQoJCUxua0NhcDoJUG9ydCAjMSwgU3BlZWQgMi41R1QvcywgV2lkdGggeDEsIEFT
UE0gdW5rbm93biwgTGF0ZW5jeSBMMCA8NjRucywgTDEgdW5saW1pdGVkDQoJCQlDbG9ja1BN
KyBTdXJwcmlzZS0gTExBY3RSZXAtIEJ3Tm90LQ0KCQlMbmtDdGw6CUFTUE0gRGlzYWJsZWQ7
IFJDQiA2NCBieXRlcyBEaXNhYmxlZC0gUmV0cmFpbi0gQ29tbUNsay0NCgkJCUV4dFN5bmNo
LSBDbG9ja1BNLSBBdXRXaWREaXMtIEJXSW50LSBBdXRCV0ludC0NCgkJTG5rU3RhOglTcGVl
ZCAyLjVHVC9zLCBXaWR0aCB4MSwgVHJFcnItIFRyYWluLSBTbG90Q2xrLSBETEFjdGl2ZS0g
QldNZ210LSBBQldNZ210LQ0KCUtlcm5lbCBkcml2ZXIgaW4gdXNlOiBwY2liYWNrDQoNCjBh
OjAwLjMgVVNCIGNvbnRyb2xsZXIgWzBjMDNdOiBOZXRNb3MgVGVjaG5vbG9neSBNQ1M5OTkw
IFBDSWUgdG8gNOKAkFBvcnQgVVNCIDIuMCBIb3N0IENvbnRyb2xsZXIgWzk3MTA6OTk5MF0g
KHByb2ctaWYgMjAgW0VIQ0ldKQ0KCVN1YnN5c3RlbTogRGV2aWNlIFthMDAwOjQwMDBdDQoJ
Q29udHJvbDogSS9PLSBNZW0rIEJ1c01hc3RlcisgU3BlY0N5Y2xlLSBNZW1XSU5WLSBWR0FT
bm9vcC0gUGFyRXJyLSBTdGVwcGluZy0gU0VSUi0gRmFzdEIyQi0gRGlzSU5UeC0NCglTdGF0
dXM6IENhcCsgNjZNSHotIFVERi0gRmFzdEIyQi0gUGFyRXJyLSBERVZTRUw9ZmFzdCA+VEFi
b3J0LSA8VEFib3J0LSA8TUFib3J0LSA+U0VSUi0gPFBFUlItIElOVHgtDQoJTGF0ZW5jeTog
MCwgQ2FjaGUgTGluZSBTaXplOiA2NCBieXRlcw0KCUludGVycnVwdDogcGluIEIgcm91dGVk
IHRvIElSUSAyOQ0KCVJlZ2lvbiAwOiBNZW1vcnkgYXQgZjlmZmIwMDAgKDMyLWJpdCwgbm9u
LXByZWZldGNoYWJsZSkgW3NpemU9NEtdDQoJQ2FwYWJpbGl0aWVzOiBbNTBdIE1TSTogRW5h
YmxlLSBDb3VudD0xLzEgTWFza2FibGUtIDY0Yml0Kw0KCQlBZGRyZXNzOiAwMDAwMDAwMDAw
MDAwMDAwICBEYXRhOiAwMDAwDQoJQ2FwYWJpbGl0aWVzOiBbNzhdIFBvd2VyIE1hbmFnZW1l
bnQgdmVyc2lvbiAzDQoJCUZsYWdzOiBQTUVDbGstIERTSS0gRDErIEQyKyBBdXhDdXJyZW50
PTM3NW1BIFBNRShEMCssRDErLEQyKyxEM2hvdCssRDNjb2xkLSkNCgkJU3RhdHVzOiBEMCBO
b1NvZnRSc3QrIFBNRS1FbmFibGUtIERTZWw9MCBEU2NhbGU9MCBQTUUtDQoJQ2FwYWJpbGl0
aWVzOiBbODBdIEV4cHJlc3MgKHYxKSBFbmRwb2ludCwgTVNJIDAwDQoJCURldkNhcDoJTWF4
UGF5bG9hZCAyNTYgYnl0ZXMsIFBoYW50RnVuYyAwLCBMYXRlbmN5IEwwcyB1bmxpbWl0ZWQs
IEwxIHVubGltaXRlZA0KCQkJRXh0VGFnLSBBdHRuQnRuLSBBdHRuSW5kLSBQd3JJbmQtIFJC
RSsgRkxSZXNldC0NCgkJRGV2Q3RsOglSZXBvcnQgZXJyb3JzOiBDb3JyZWN0YWJsZS0gTm9u
LUZhdGFsLSBGYXRhbC0gVW5zdXBwb3J0ZWQtDQoJCQlSbHhkT3JkLSBFeHRUYWctIFBoYW50
RnVuYy0gQXV4UHdyLSBOb1Nub29wKw0KCQkJTWF4UGF5bG9hZCAxMjggYnl0ZXMsIE1heFJl
YWRSZXEgNTEyIGJ5dGVzDQoJCURldlN0YToJQ29yckVyci0gVW5jb3JyRXJyLSBGYXRhbEVy
ci0gVW5zdXBwUmVxLSBBdXhQd3ItIFRyYW5zUGVuZC0NCgkJTG5rQ2FwOglQb3J0ICMxLCBT
cGVlZCAyLjVHVC9zLCBXaWR0aCB4MSwgQVNQTSB1bmtub3duLCBMYXRlbmN5IEwwIDw2NG5z
LCBMMSB1bmxpbWl0ZWQNCgkJCUNsb2NrUE0rIFN1cnByaXNlLSBMTEFjdFJlcC0gQndOb3Qt
DQoJCUxua0N0bDoJQVNQTSBEaXNhYmxlZDsgUkNCIDY0IGJ5dGVzIERpc2FibGVkLSBSZXRy
YWluLSBDb21tQ2xrLQ0KCQkJRXh0U3luY2gtIENsb2NrUE0tIEF1dFdpZERpcy0gQldJbnQt
IEF1dEJXSW50LQ0KCQlMbmtTdGE6CVNwZWVkIDIuNUdUL3MsIFdpZHRoIHgxLCBUckVyci0g
VHJhaW4tIFNsb3RDbGstIERMQWN0aXZlLSBCV01nbXQtIEFCV01nbXQtDQoJS2VybmVsIGRy
aXZlciBpbiB1c2U6IHBjaWJhY2sNCg0KMGE6MDAuNCBVU0IgY29udHJvbGxlciBbMGMwM106
IE5ldE1vcyBUZWNobm9sb2d5IE1DUzk5OTAgUENJZSB0byA04oCQUG9ydCBVU0IgMi4wIEhv
c3QgQ29udHJvbGxlciBbOTcxMDo5OTkwXSAocHJvZy1pZiAxMCBbT0hDSV0pDQoJU3Vic3lz
dGVtOiBEZXZpY2UgW2EwMDA6NDAwMF0NCglDb250cm9sOiBJL08tIE1lbSsgQnVzTWFzdGVy
KyBTcGVjQ3ljbGUtIE1lbVdJTlYtIFZHQVNub29wLSBQYXJFcnItIFN0ZXBwaW5nLSBTRVJS
LSBGYXN0QjJCLSBEaXNJTlR4LQ0KCVN0YXR1czogQ2FwKyA2Nk1Iei0gVURGLSBGYXN0QjJC
LSBQYXJFcnItIERFVlNFTD1mYXN0ID5UQWJvcnQtIDxUQWJvcnQtIDxNQWJvcnQtID5TRVJS
LSA8UEVSUi0gSU5UeC0NCglMYXRlbmN5OiAwLCBDYWNoZSBMaW5lIFNpemU6IDY0IGJ5dGVz
DQoJSW50ZXJydXB0OiBwaW4gQyByb3V0ZWQgdG8gSVJRIDMwDQoJUmVnaW9uIDA6IE1lbW9y
eSBhdCBmOWZmYzAwMCAoMzItYml0LCBub24tcHJlZmV0Y2hhYmxlKSBbc2l6ZT00S10NCglD
YXBhYmlsaXRpZXM6IFs1MF0gTVNJOiBFbmFibGUtIENvdW50PTEvMSBNYXNrYWJsZS0gNjRi
aXQrDQoJCUFkZHJlc3M6IDAwMDAwMDAwMDAwMDAwMDAgIERhdGE6IDAwMDANCglDYXBhYmls
aXRpZXM6IFs3OF0gUG93ZXIgTWFuYWdlbWVudCB2ZXJzaW9uIDMNCgkJRmxhZ3M6IFBNRUNs
ay0gRFNJLSBEMSsgRDIrIEF1eEN1cnJlbnQ9Mzc1bUEgUE1FKEQwKyxEMSssRDIrLEQzaG90
KyxEM2NvbGQtKQ0KCQlTdGF0dXM6IEQwIE5vU29mdFJzdCsgUE1FLUVuYWJsZS0gRFNlbD0w
IERTY2FsZT0wIFBNRS0NCglDYXBhYmlsaXRpZXM6IFs4MF0gRXhwcmVzcyAodjEpIEVuZHBv
aW50LCBNU0kgMDANCgkJRGV2Q2FwOglNYXhQYXlsb2FkIDI1NiBieXRlcywgUGhhbnRGdW5j
IDAsIExhdGVuY3kgTDBzIHVubGltaXRlZCwgTDEgdW5saW1pdGVkDQoJCQlFeHRUYWctIEF0
dG5CdG4tIEF0dG5JbmQtIFB3ckluZC0gUkJFKyBGTFJlc2V0LQ0KCQlEZXZDdGw6CVJlcG9y
dCBlcnJvcnM6IENvcnJlY3RhYmxlLSBOb24tRmF0YWwtIEZhdGFsLSBVbnN1cHBvcnRlZC0N
CgkJCVJseGRPcmQtIEV4dFRhZy0gUGhhbnRGdW5jLSBBdXhQd3ItIE5vU25vb3ArDQoJCQlN
YXhQYXlsb2FkIDEyOCBieXRlcywgTWF4UmVhZFJlcSA1MTIgYnl0ZXMNCgkJRGV2U3RhOglD
b3JyRXJyLSBVbmNvcnJFcnItIEZhdGFsRXJyLSBVbnN1cHBSZXEtIEF1eFB3ci0gVHJhbnNQ
ZW5kLQ0KCQlMbmtDYXA6CVBvcnQgIzEsIFNwZWVkIDIuNUdUL3MsIFdpZHRoIHgxLCBBU1BN
IHVua25vd24sIExhdGVuY3kgTDAgPDY0bnMsIEwxIHVubGltaXRlZA0KCQkJQ2xvY2tQTSsg
U3VycHJpc2UtIExMQWN0UmVwLSBCd05vdC0NCgkJTG5rQ3RsOglBU1BNIERpc2FibGVkOyBS
Q0IgNjQgYnl0ZXMgRGlzYWJsZWQtIFJldHJhaW4tIENvbW1DbGstDQoJCQlFeHRTeW5jaC0g
Q2xvY2tQTS0gQXV0V2lkRGlzLSBCV0ludC0gQXV0QldJbnQtDQoJCUxua1N0YToJU3BlZWQg
Mi41R1QvcywgV2lkdGggeDEsIFRyRXJyLSBUcmFpbi0gU2xvdENsay0gRExBY3RpdmUtIEJX
TWdtdC0gQUJXTWdtdC0NCglLZXJuZWwgZHJpdmVyIGluIHVzZTogcGNpYmFjaw0KDQowYTow
MC41IFVTQiBjb250cm9sbGVyIFswYzAzXTogTmV0TW9zIFRlY2hub2xvZ3kgTUNTOTk5MCBQ
Q0llIHRvIDTigJBQb3J0IFVTQiAyLjAgSG9zdCBDb250cm9sbGVyIFs5NzEwOjk5OTBdIChw
cm9nLWlmIDIwIFtFSENJXSkNCglTdWJzeXN0ZW06IERldmljZSBbYTAwMDo0MDAwXQ0KCUNv
bnRyb2w6IEkvTy0gTWVtKyBCdXNNYXN0ZXIrIFNwZWNDeWNsZS0gTWVtV0lOVi0gVkdBU25v
b3AtIFBhckVyci0gU3RlcHBpbmctIFNFUlItIEZhc3RCMkItIERpc0lOVHgtDQoJU3RhdHVz
OiBDYXArIDY2TUh6LSBVREYtIEZhc3RCMkItIFBhckVyci0gREVWU0VMPWZhc3QgPlRBYm9y
dC0gPFRBYm9ydC0gPE1BYm9ydC0gPlNFUlItIDxQRVJSLSBJTlR4LQ0KCUxhdGVuY3k6IDAs
IENhY2hlIExpbmUgU2l6ZTogNjQgYnl0ZXMNCglJbnRlcnJ1cHQ6IHBpbiBDIHJvdXRlZCB0
byBJUlEgMzANCglSZWdpb24gMDogTWVtb3J5IGF0IGY5ZmZkMDAwICgzMi1iaXQsIG5vbi1w
cmVmZXRjaGFibGUpIFtzaXplPTRLXQ0KCUNhcGFiaWxpdGllczogWzUwXSBNU0k6IEVuYWJs
ZS0gQ291bnQ9MS8xIE1hc2thYmxlLSA2NGJpdCsNCgkJQWRkcmVzczogMDAwMDAwMDAwMDAw
MDAwMCAgRGF0YTogMDAwMA0KCUNhcGFiaWxpdGllczogWzc4XSBQb3dlciBNYW5hZ2VtZW50
IHZlcnNpb24gMw0KCQlGbGFnczogUE1FQ2xrLSBEU0ktIEQxKyBEMisgQXV4Q3VycmVudD0z
NzVtQSBQTUUoRDArLEQxKyxEMissRDNob3QrLEQzY29sZC0pDQoJCVN0YXR1czogRDAgTm9T
b2Z0UnN0KyBQTUUtRW5hYmxlLSBEU2VsPTAgRFNjYWxlPTAgUE1FLQ0KCUNhcGFiaWxpdGll
czogWzgwXSBFeHByZXNzICh2MSkgRW5kcG9pbnQsIE1TSSAwMA0KCQlEZXZDYXA6CU1heFBh
eWxvYWQgMjU2IGJ5dGVzLCBQaGFudEZ1bmMgMCwgTGF0ZW5jeSBMMHMgdW5saW1pdGVkLCBM
MSB1bmxpbWl0ZWQNCgkJCUV4dFRhZy0gQXR0bkJ0bi0gQXR0bkluZC0gUHdySW5kLSBSQkUr
IEZMUmVzZXQtDQoJCURldkN0bDoJUmVwb3J0IGVycm9yczogQ29ycmVjdGFibGUtIE5vbi1G
YXRhbC0gRmF0YWwtIFVuc3VwcG9ydGVkLQ0KCQkJUmx4ZE9yZC0gRXh0VGFnLSBQaGFudEZ1
bmMtIEF1eFB3ci0gTm9Tbm9vcCsNCgkJCU1heFBheWxvYWQgMTI4IGJ5dGVzLCBNYXhSZWFk
UmVxIDUxMiBieXRlcw0KCQlEZXZTdGE6CUNvcnJFcnItIFVuY29yckVyci0gRmF0YWxFcnIt
IFVuc3VwcFJlcS0gQXV4UHdyLSBUcmFuc1BlbmQtDQoJCUxua0NhcDoJUG9ydCAjMSwgU3Bl
ZWQgMi41R1QvcywgV2lkdGggeDEsIEFTUE0gdW5rbm93biwgTGF0ZW5jeSBMMCA8NjRucywg
TDEgdW5saW1pdGVkDQoJCQlDbG9ja1BNKyBTdXJwcmlzZS0gTExBY3RSZXAtIEJ3Tm90LQ0K
CQlMbmtDdGw6CUFTUE0gRGlzYWJsZWQ7IFJDQiA2NCBieXRlcyBEaXNhYmxlZC0gUmV0cmFp
bi0gQ29tbUNsay0NCgkJCUV4dFN5bmNoLSBDbG9ja1BNLSBBdXRXaWREaXMtIEJXSW50LSBB
dXRCV0ludC0NCgkJTG5rU3RhOglTcGVlZCAyLjVHVC9zLCBXaWR0aCB4MSwgVHJFcnItIFRy
YWluLSBTbG90Q2xrLSBETEFjdGl2ZS0gQldNZ210LSBBQldNZ210LQ0KCUtlcm5lbCBkcml2
ZXIgaW4gdXNlOiBwY2liYWNrDQoNCjBhOjAwLjYgVVNCIGNvbnRyb2xsZXIgWzBjMDNdOiBO
ZXRNb3MgVGVjaG5vbG9neSBNQ1M5OTkwIFBDSWUgdG8gNOKAkFBvcnQgVVNCIDIuMCBIb3N0
IENvbnRyb2xsZXIgWzk3MTA6OTk5MF0gKHByb2ctaWYgMTAgW09IQ0ldKQ0KCVN1YnN5c3Rl
bTogRGV2aWNlIFthMDAwOjQwMDBdDQoJQ29udHJvbDogSS9PLSBNZW0rIEJ1c01hc3Rlcisg
U3BlY0N5Y2xlLSBNZW1XSU5WLSBWR0FTbm9vcC0gUGFyRXJyLSBTdGVwcGluZy0gU0VSUi0g
RmFzdEIyQi0gRGlzSU5UeC0NCglTdGF0dXM6IENhcCsgNjZNSHotIFVERi0gRmFzdEIyQi0g
UGFyRXJyLSBERVZTRUw9ZmFzdCA+VEFib3J0LSA8VEFib3J0LSA8TUFib3J0LSA+U0VSUi0g
PFBFUlItIElOVHgtDQoJTGF0ZW5jeTogMCwgQ2FjaGUgTGluZSBTaXplOiA2NCBieXRlcw0K
CUludGVycnVwdDogcGluIEQgcm91dGVkIHRvIElSUSAzMQ0KCVJlZ2lvbiAwOiBNZW1vcnkg
YXQgZjlmZmUwMDAgKDMyLWJpdCwgbm9uLXByZWZldGNoYWJsZSkgW3NpemU9NEtdDQoJQ2Fw
YWJpbGl0aWVzOiBbNTBdIE1TSTogRW5hYmxlLSBDb3VudD0xLzEgTWFza2FibGUtIDY0Yml0
Kw0KCQlBZGRyZXNzOiAwMDAwMDAwMDAwMDAwMDAwICBEYXRhOiAwMDAwDQoJQ2FwYWJpbGl0
aWVzOiBbNzhdIFBvd2VyIE1hbmFnZW1lbnQgdmVyc2lvbiAzDQoJCUZsYWdzOiBQTUVDbGst
IERTSS0gRDErIEQyKyBBdXhDdXJyZW50PTM3NW1BIFBNRShEMCssRDErLEQyKyxEM2hvdCss
RDNjb2xkLSkNCgkJU3RhdHVzOiBEMCBOb1NvZnRSc3QrIFBNRS1FbmFibGUtIERTZWw9MCBE
U2NhbGU9MCBQTUUtDQoJQ2FwYWJpbGl0aWVzOiBbODBdIEV4cHJlc3MgKHYxKSBFbmRwb2lu
dCwgTVNJIDAwDQoJCURldkNhcDoJTWF4UGF5bG9hZCAyNTYgYnl0ZXMsIFBoYW50RnVuYyAw
LCBMYXRlbmN5IEwwcyB1bmxpbWl0ZWQsIEwxIHVubGltaXRlZA0KCQkJRXh0VGFnLSBBdHRu
QnRuLSBBdHRuSW5kLSBQd3JJbmQtIFJCRSsgRkxSZXNldC0NCgkJRGV2Q3RsOglSZXBvcnQg
ZXJyb3JzOiBDb3JyZWN0YWJsZS0gTm9uLUZhdGFsLSBGYXRhbC0gVW5zdXBwb3J0ZWQtDQoJ
CQlSbHhkT3JkLSBFeHRUYWctIFBoYW50RnVuYy0gQXV4UHdyLSBOb1Nub29wKw0KCQkJTWF4
UGF5bG9hZCAxMjggYnl0ZXMsIE1heFJlYWRSZXEgNTEyIGJ5dGVzDQoJCURldlN0YToJQ29y
ckVyci0gVW5jb3JyRXJyLSBGYXRhbEVyci0gVW5zdXBwUmVxLSBBdXhQd3ItIFRyYW5zUGVu
ZC0NCgkJTG5rQ2FwOglQb3J0ICMxLCBTcGVlZCAyLjVHVC9zLCBXaWR0aCB4MSwgQVNQTSB1
bmtub3duLCBMYXRlbmN5IEwwIDw2NG5zLCBMMSB1bmxpbWl0ZWQNCgkJCUNsb2NrUE0rIFN1
cnByaXNlLSBMTEFjdFJlcC0gQndOb3QtDQoJCUxua0N0bDoJQVNQTSBEaXNhYmxlZDsgUkNC
IDY0IGJ5dGVzIERpc2FibGVkLSBSZXRyYWluLSBDb21tQ2xrLQ0KCQkJRXh0U3luY2gtIENs
b2NrUE0tIEF1dFdpZERpcy0gQldJbnQtIEF1dEJXSW50LQ0KCQlMbmtTdGE6CVNwZWVkIDIu
NUdUL3MsIFdpZHRoIHgxLCBUckVyci0gVHJhaW4tIFNsb3RDbGstIERMQWN0aXZlLSBCV01n
bXQtIEFCV01nbXQtDQoJS2VybmVsIGRyaXZlciBpbiB1c2U6IHBjaWJhY2sNCg0KMGE6MDAu
NyBVU0IgY29udHJvbGxlciBbMGMwM106IE5ldE1vcyBUZWNobm9sb2d5IE1DUzk5OTAgUENJ
ZSB0byA04oCQUG9ydCBVU0IgMi4wIEhvc3QgQ29udHJvbGxlciBbOTcxMDo5OTkwXSAocHJv
Zy1pZiAyMCBbRUhDSV0pDQoJU3Vic3lzdGVtOiBEZXZpY2UgW2EwMDA6NDAwMF0NCglDb250
cm9sOiBJL08tIE1lbSsgQnVzTWFzdGVyKyBTcGVjQ3ljbGUtIE1lbVdJTlYtIFZHQVNub29w
LSBQYXJFcnItIFN0ZXBwaW5nLSBTRVJSLSBGYXN0QjJCLSBEaXNJTlR4LQ0KCVN0YXR1czog
Q2FwKyA2Nk1Iei0gVURGLSBGYXN0QjJCLSBQYXJFcnItIERFVlNFTD1mYXN0ID5UQWJvcnQt
IDxUQWJvcnQtIDxNQWJvcnQtID5TRVJSLSA8UEVSUi0gSU5UeC0NCglMYXRlbmN5OiAwLCBD
YWNoZSBMaW5lIFNpemU6IDY0IGJ5dGVzDQoJSW50ZXJydXB0OiBwaW4gRCByb3V0ZWQgdG8g
SVJRIDMxDQoJUmVnaW9uIDA6IE1lbW9yeSBhdCBmOWZmZjAwMCAoMzItYml0LCBub24tcHJl
ZmV0Y2hhYmxlKSBbc2l6ZT00S10NCglDYXBhYmlsaXRpZXM6IFs1MF0gTVNJOiBFbmFibGUt
IENvdW50PTEvMSBNYXNrYWJsZS0gNjRiaXQrDQoJCUFkZHJlc3M6IDAwMDAwMDAwMDAwMDAw
MDAgIERhdGE6IDAwMDANCglDYXBhYmlsaXRpZXM6IFs3OF0gUG93ZXIgTWFuYWdlbWVudCB2
ZXJzaW9uIDMNCgkJRmxhZ3M6IFBNRUNsay0gRFNJLSBEMSsgRDIrIEF1eEN1cnJlbnQ9Mzc1
bUEgUE1FKEQwKyxEMSssRDIrLEQzaG90KyxEM2NvbGQtKQ0KCQlTdGF0dXM6IEQwIE5vU29m
dFJzdCsgUE1FLUVuYWJsZS0gRFNlbD0wIERTY2FsZT0wIFBNRS0NCglDYXBhYmlsaXRpZXM6
IFs4MF0gRXhwcmVzcyAodjEpIEVuZHBvaW50LCBNU0kgMDANCgkJRGV2Q2FwOglNYXhQYXls
b2FkIDI1NiBieXRlcywgUGhhbnRGdW5jIDAsIExhdGVuY3kgTDBzIHVubGltaXRlZCwgTDEg
dW5saW1pdGVkDQoJCQlFeHRUYWctIEF0dG5CdG4tIEF0dG5JbmQtIFB3ckluZC0gUkJFKyBG
TFJlc2V0LQ0KCQlEZXZDdGw6CVJlcG9ydCBlcnJvcnM6IENvcnJlY3RhYmxlLSBOb24tRmF0
YWwtIEZhdGFsLSBVbnN1cHBvcnRlZC0NCgkJCVJseGRPcmQtIEV4dFRhZy0gUGhhbnRGdW5j
LSBBdXhQd3ItIE5vU25vb3ArDQoJCQlNYXhQYXlsb2FkIDEyOCBieXRlcywgTWF4UmVhZFJl
cSA1MTIgYnl0ZXMNCgkJRGV2U3RhOglDb3JyRXJyLSBVbmNvcnJFcnItIEZhdGFsRXJyLSBV
bnN1cHBSZXEtIEF1eFB3ci0gVHJhbnNQZW5kLQ0KCQlMbmtDYXA6CVBvcnQgIzEsIFNwZWVk
IDIuNUdUL3MsIFdpZHRoIHgxLCBBU1BNIHVua25vd24sIExhdGVuY3kgTDAgPDY0bnMsIEwx
IHVubGltaXRlZA0KCQkJQ2xvY2tQTSsgU3VycHJpc2UtIExMQWN0UmVwLSBCd05vdC0NCgkJ
TG5rQ3RsOglBU1BNIERpc2FibGVkOyBSQ0IgNjQgYnl0ZXMgRGlzYWJsZWQtIFJldHJhaW4t
IENvbW1DbGstDQoJCQlFeHRTeW5jaC0gQ2xvY2tQTS0gQXV0V2lkRGlzLSBCV0ludC0gQXV0
QldJbnQtDQoJCUxua1N0YToJU3BlZWQgMi41R1QvcywgV2lkdGggeDEsIFRyRXJyLSBUcmFp
bi0gU2xvdENsay0gRExBY3RpdmUtIEJXTWdtdC0gQUJXTWdtdC0NCglLZXJuZWwgZHJpdmVy
IGluIHVzZTogcGNpYmFjaw0KDQowYjowMC4wIFZHQSBjb21wYXRpYmxlIGNvbnRyb2xsZXIg
WzAzMDBdOiBuVmlkaWEgQ29ycG9yYXRpb24gRzk4IFtHZUZvcmNlIDg0MDAgR1NdIFsxMGRl
OjA2ZTRdIChyZXYgYTEpIChwcm9nLWlmIDAwIFtWR0EgY29udHJvbGxlcl0pDQoJU3Vic3lz
dGVtOiBBU1VTVGVLIENvbXB1dGVyIEluYy4gRGV2aWNlIFsxMDQzOjgyNjZdDQoJQ29udHJv
bDogSS9PKyBNZW0rIEJ1c01hc3RlcisgU3BlY0N5Y2xlLSBNZW1XSU5WLSBWR0FTbm9vcC0g
UGFyRXJyLSBTdGVwcGluZy0gU0VSUisgRmFzdEIyQi0gRGlzSU5UeC0NCglTdGF0dXM6IENh
cCsgNjZNSHotIFVERi0gRmFzdEIyQi0gUGFyRXJyLSBERVZTRUw9ZmFzdCA+VEFib3J0LSA8
VEFib3J0LSA8TUFib3J0LSA+U0VSUi0gPFBFUlItIElOVHgtDQoJTGF0ZW5jeTogMCwgQ2Fj
aGUgTGluZSBTaXplOiA2NCBieXRlcw0KCUludGVycnVwdDogcGluIEEgcm91dGVkIHRvIElS
USAxMA0KCVJlZ2lvbiAwOiBNZW1vcnkgYXQgZmQwMDAwMDAgKDMyLWJpdCwgbm9uLXByZWZl
dGNoYWJsZSkgW3NpemU9MTZNXQ0KCVJlZ2lvbiAxOiBNZW1vcnkgYXQgZDAwMDAwMDAgKDY0
LWJpdCwgcHJlZmV0Y2hhYmxlKSBbc2l6ZT0yNTZNXQ0KCVJlZ2lvbiAzOiBNZW1vcnkgYXQg
ZmEwMDAwMDAgKDY0LWJpdCwgbm9uLXByZWZldGNoYWJsZSkgW3NpemU9MzJNXQ0KCVJlZ2lv
biA1OiBJL08gcG9ydHMgYXQgZTgwMCBbc2l6ZT0xMjhdDQoJRXhwYW5zaW9uIFJPTSBhdCBm
ZTllMDAwMCBbZGlzYWJsZWRdIFtzaXplPTEyOEtdDQoJQ2FwYWJpbGl0aWVzOiBbNjBdIFBv
d2VyIE1hbmFnZW1lbnQgdmVyc2lvbiAzDQoJCUZsYWdzOiBQTUVDbGstIERTSS0gRDEtIEQy
LSBBdXhDdXJyZW50PTBtQSBQTUUoRDAtLEQxLSxEMi0sRDNob3QtLEQzY29sZC0pDQoJCVN0
YXR1czogRDAgTm9Tb2Z0UnN0KyBQTUUtRW5hYmxlLSBEU2VsPTAgRFNjYWxlPTAgUE1FLQ0K
CUNhcGFiaWxpdGllczogWzY4XSBNU0k6IEVuYWJsZS0gQ291bnQ9MS8xIE1hc2thYmxlLSA2
NGJpdCsNCgkJQWRkcmVzczogMDAwMDAwMDAwMDAwMDAwMCAgRGF0YTogMDAwMA0KCUNhcGFi
aWxpdGllczogWzc4XSBFeHByZXNzICh2MSkgRW5kcG9pbnQsIE1TSSAwMA0KCQlEZXZDYXA6
CU1heFBheWxvYWQgMTI4IGJ5dGVzLCBQaGFudEZ1bmMgMCwgTGF0ZW5jeSBMMHMgPDUxMm5z
LCBMMSA8NHVzDQoJCQlFeHRUYWcrIEF0dG5CdG4tIEF0dG5JbmQtIFB3ckluZC0gUkJFKyBG
TFJlc2V0LQ0KCQlEZXZDdGw6CVJlcG9ydCBlcnJvcnM6IENvcnJlY3RhYmxlLSBOb24tRmF0
YWwtIEZhdGFsLSBVbnN1cHBvcnRlZC0NCgkJCVJseGRPcmQtIEV4dFRhZy0gUGhhbnRGdW5j
LSBBdXhQd3ItIE5vU25vb3ArDQoJCQlNYXhQYXlsb2FkIDEyOCBieXRlcywgTWF4UmVhZFJl
cSA1MTIgYnl0ZXMNCgkJRGV2U3RhOglDb3JyRXJyLSBVbmNvcnJFcnItIEZhdGFsRXJyLSBV
bnN1cHBSZXEtIEF1eFB3ci0gVHJhbnNQZW5kLQ0KCQlMbmtDYXA6CVBvcnQgIzAsIFNwZWVk
IDIuNUdUL3MsIFdpZHRoIHgxNiwgQVNQTSBMMHMgTDEsIExhdGVuY3kgTDAgPDUxMm5zLCBM
MSA8MXVzDQoJCQlDbG9ja1BNLSBTdXJwcmlzZS0gTExBY3RSZXAtIEJ3Tm90LQ0KCQlMbmtD
dGw6CUFTUE0gRGlzYWJsZWQ7IFJDQiAxMjggYnl0ZXMgRGlzYWJsZWQtIFJldHJhaW4tIENv
bW1DbGsrDQoJCQlFeHRTeW5jaC0gQ2xvY2tQTS0gQXV0V2lkRGlzLSBCV0ludC0gQXV0QldJ
bnQtDQoJCUxua1N0YToJU3BlZWQgMi41R1QvcywgV2lkdGggeDgsIFRyRXJyLSBUcmFpbi0g
U2xvdENsaysgRExBY3RpdmUtIEJXTWdtdC0gQUJXTWdtdC0NCglDYXBhYmlsaXRpZXM6IFsx
MDAgdjFdIFZpcnR1YWwgQ2hhbm5lbA0KCQlDYXBzOglMUEVWQz0wIFJlZkNsaz0xMDBucyBQ
QVRFbnRyeUJpdHM9MQ0KCQlBcmI6CUZpeGVkLSBXUlIzMi0gV1JSNjQtIFdSUjEyOC0NCgkJ
Q3RybDoJQXJiU2VsZWN0PUZpeGVkDQoJCVN0YXR1czoJSW5Qcm9ncmVzcy0NCgkJVkMwOglD
YXBzOglQQVRPZmZzZXQ9MDAgTWF4VGltZVNsb3RzPTEgUmVqU25vb3BUcmFucy0NCgkJCUFy
YjoJRml4ZWQtIFdSUjMyLSBXUlI2NC0gV1JSMTI4LSBUV1JSMTI4LSBXUlIyNTYtDQoJCQlD
dHJsOglFbmFibGUrIElEPTAgQXJiU2VsZWN0PUZpeGVkIFRDL1ZDPWZmDQoJCQlTdGF0dXM6
CU5lZ29QZW5kaW5nLSBJblByb2dyZXNzLQ0KCUNhcGFiaWxpdGllczogWzEyOCB2MV0gUG93
ZXIgQnVkZ2V0aW5nIDw/Pg0KCUNhcGFiaWxpdGllczogWzYwMCB2MV0gVmVuZG9yIFNwZWNp
ZmljIEluZm9ybWF0aW9uOiBJRD0wMDAxIFJldj0xIExlbj0wMjQgPD8+DQoNCg==
------------0E902503E1C6BF83E
Content-Type: text/plain;
 name="lspci-4.2.txt"
Content-transfer-encoding: base64
Content-Disposition: attachment;
 filename="lspci-4.2.txt"

MDA6MDAuMCBIb3N0IGJyaWRnZSBbMDYwMF06IEFUSSBUZWNobm9sb2dpZXMgSW5jIFJEODkw
IE5vcnRoYnJpZGdlIG9ubHkgc2luZ2xlIHNsb3QgUENJLWUgR0ZYIEh5ZHJhIHBhcnQgWzEw
MDI6NWExMV0gKHJldiAwMikNCglTdWJzeXN0ZW06IEFUSSBUZWNobm9sb2dpZXMgSW5jIFJE
ODkwIE5vcnRoYnJpZGdlIG9ubHkgc2luZ2xlIHNsb3QgUENJLWUgR0ZYIEh5ZHJhIHBhcnQg
WzEwMDI6NWExMV0NCglDb250cm9sOiBJL08tIE1lbSsgQnVzTWFzdGVyLSBTcGVjQ3ljbGUt
IE1lbVdJTlYtIFZHQVNub29wLSBQYXJFcnItIFN0ZXBwaW5nLSBTRVJSLSBGYXN0QjJCLSBE
aXNJTlR4LQ0KCVN0YXR1czogQ2FwKyA2Nk1Iei0gVURGLSBGYXN0QjJCLSBQYXJFcnItIERF
VlNFTD1mYXN0ID5UQWJvcnQtIDxUQWJvcnQtIDxNQWJvcnQrID5TRVJSLSA8UEVSUi0gSU5U
eC0NCglDYXBhYmlsaXRpZXM6IFtmMF0gSHlwZXJUcmFuc3BvcnQ6IE1TSSBNYXBwaW5nIEVu
YWJsZSsgRml4ZWQrDQoJQ2FwYWJpbGl0aWVzOiBbYzRdIEh5cGVyVHJhbnNwb3J0OiBTbGF2
ZSBvciBQcmltYXJ5IEludGVyZmFjZQ0KCQlDb21tYW5kOiBCYXNlVW5pdElEPTAgVW5pdENu
dD0yMCBNYXN0SG9zdC0gRGVmRGlyLSBEVUwtDQoJCUxpbmsgQ29udHJvbCAwOiBDRmxFLSBD
U1QtIENGRS0gPExrRmFpbC0gSW5pdCsgRU9DLSBUWE8tIDxDUkNFcnI9MCBJc29jRW4tIExT
RW4tIEV4dENUTC0gNjRiLQ0KCQlMaW5rIENvbmZpZyAwOiBNTFdJPTE2Yml0IER3RmNJbi0g
TUxXTz0xNmJpdCBEd0ZjT3V0LSBMV0k9MTZiaXQgRHdGY0luRW4tIExXTz0xNmJpdCBEd0Zj
T3V0RW4tDQoJCUxpbmsgQ29udHJvbCAxOiBDRmxFLSBDU1QtIENGRS0gPExrRmFpbCsgSW5p
dC0gRU9DKyBUWE8rIDxDUkNFcnI9MCBJc29jRW4tIExTRW4tIEV4dENUTC0gNjRiLQ0KCQlM
aW5rIENvbmZpZyAxOiBNTFdJPThiaXQgRHdGY0luLSBNTFdPPThiaXQgRHdGY091dC0gTFdJ
PThiaXQgRHdGY0luRW4tIExXTz04Yml0IER3RmNPdXRFbi0NCgkJUmV2aXNpb24gSUQ6IDMu
MDANCgkJTGluayBGcmVxdWVuY3kgMDogW2JdDQoJCUxpbmsgRXJyb3IgMDogPFByb3QtIDxP
dmZsLSA8RU9DLSBDVExUbS0NCgkJTGluayBGcmVxdWVuY3kgQ2FwYWJpbGl0eSAwOiAyMDBN
SHorIDMwME1Iei0gNDAwTUh6KyA1MDBNSHotIDYwME1IeisgODAwTUh6KyAxLjBHSHorIDEu
MkdIeisgMS40R0h6LSAxLjZHSHotIFZlbmQtDQoJCUZlYXR1cmUgQ2FwYWJpbGl0eTogSXNv
Y0ZDKyBMRFRTVE9QKyBDUkNUTS0gRUNUTFQtIDY0YkErIFVJRFJELQ0KCQlMaW5rIEZyZXF1
ZW5jeSAxOiAyMDBNSHoNCgkJTGluayBFcnJvciAxOiA8UHJvdC0gPE92ZmwtIDxFT0MtIENU
TFRtLQ0KCQlMaW5rIEZyZXF1ZW5jeSBDYXBhYmlsaXR5IDE6IDIwME1Iei0gMzAwTUh6LSA0
MDBNSHotIDUwME1Iei0gNjAwTUh6LSA4MDBNSHotIDEuMEdIei0gMS4yR0h6LSAxLjRHSHot
IDEuNkdIei0gVmVuZC0NCgkJRXJyb3IgSGFuZGxpbmc6IFBGbEUtIE9GbEUtIFBGRS0gT0ZF
LSBFT0NGRS0gUkZFLSBDUkNGRS0gU0VSUkZFLSBDRi0gUkUtIFBORkUtIE9ORkUtIEVPQ05G
RS0gUk5GRS0gQ1JDTkZFLSBTRVJSTkZFLQ0KCQlQcmVmZXRjaGFibGUgbWVtb3J5IGJlaGlu
ZCBicmlkZ2UgVXBwZXI6IDAwLTAwDQoJCUJ1cyBOdW1iZXI6IDAwDQoJQ2FwYWJpbGl0aWVz
OiBbNDBdIEh5cGVyVHJhbnNwb3J0OiBSZXRyeSBNb2RlDQoJQ2FwYWJpbGl0aWVzOiBbNTRd
IEh5cGVyVHJhbnNwb3J0OiBVbml0SUQgQ2x1bXBpbmcNCglDYXBhYmlsaXRpZXM6IFs5Y10g
SHlwZXJUcmFuc3BvcnQ6ICMxYQ0KCUNhcGFiaWxpdGllczogWzcwXSBNU0k6IEVuYWJsZS0g
Q291bnQ9MS80IE1hc2thYmxlLSA2NGJpdC0NCgkJQWRkcmVzczogMDAwMDAwMDAgIERhdGE6
IDAwMDANCg0KMDA6MDAuMiBHZW5lcmljIHN5c3RlbSBwZXJpcGhlcmFsIFswODA2XTogQVRJ
IFRlY2hub2xvZ2llcyBJbmMgUkQ5OTAgSS9PIE1lbW9yeSBNYW5hZ2VtZW50IFVuaXQgKElP
TU1VKSBbMTAwMjo1YTIzXQ0KCVN1YnN5c3RlbTogQVRJIFRlY2hub2xvZ2llcyBJbmMgUkQ5
OTAgSS9PIE1lbW9yeSBNYW5hZ2VtZW50IFVuaXQgKElPTU1VKSBbMTAwMjo1YTIzXQ0KCUNv
bnRyb2w6IEkvTy0gTWVtLSBCdXNNYXN0ZXIrIFNwZWNDeWNsZS0gTWVtV0lOVi0gVkdBU25v
b3AtIFBhckVyci0gU3RlcHBpbmctIFNFUlItIEZhc3RCMkItIERpc0lOVHgtDQoJU3RhdHVz
OiBDYXArIDY2TUh6LSBVREYtIEZhc3RCMkItIFBhckVyci0gREVWU0VMPWZhc3QgPlRBYm9y
dC0gPFRBYm9ydC0gPE1BYm9ydC0gPlNFUlItIDxQRVJSLSBJTlR4LQ0KCUxhdGVuY3k6IDAN
CglJbnRlcnJ1cHQ6IHBpbiBBIHJvdXRlZCB0byBJUlEgMTANCglDYXBhYmlsaXRpZXM6IFs0
MF0gU2VjdXJlIGRldmljZSA8Pz4NCglDYXBhYmlsaXRpZXM6IFs1NF0gTVNJOiBFbmFibGUr
IENvdW50PTEvMSBNYXNrYWJsZS0gNjRiaXQrDQoJCUFkZHJlc3M6IDAwMDAwMDAwZmVlMDEw
MGMgIERhdGE6IDQxMjgNCglDYXBhYmlsaXRpZXM6IFs2NF0gSHlwZXJUcmFuc3BvcnQ6IE1T
SSBNYXBwaW5nIEVuYWJsZSsgRml4ZWQrDQoNCjAwOjAyLjAgUENJIGJyaWRnZSBbMDYwNF06
IEFUSSBUZWNobm9sb2dpZXMgSW5jIFJEODkwIFBDSSB0byBQQ0kgYnJpZGdlIChQQ0kgZXhw
cmVzcyBncHAgcG9ydCBCKSBbMTAwMjo1YTE2XSAocHJvZy1pZiAwMCBbTm9ybWFsIGRlY29k
ZV0pDQoJQ29udHJvbDogSS9PKyBNZW0rIEJ1c01hc3RlcisgU3BlY0N5Y2xlLSBNZW1XSU5W
LSBWR0FTbm9vcC0gUGFyRXJyLSBTdGVwcGluZy0gU0VSUisgRmFzdEIyQi0gRGlzSU5UeCsN
CglTdGF0dXM6IENhcCsgNjZNSHotIFVERi0gRmFzdEIyQi0gUGFyRXJyLSBERVZTRUw9ZmFz
dCA+VEFib3J0LSA8VEFib3J0LSA8TUFib3J0LSA+U0VSUi0gPFBFUlItIElOVHgtDQoJTGF0
ZW5jeTogMCwgQ2FjaGUgTGluZSBTaXplOiA2NCBieXRlcw0KCUJ1czogcHJpbWFyeT0wMCwg
c2Vjb25kYXJ5PTBiLCBzdWJvcmRpbmF0ZT0wYiwgc2VjLWxhdGVuY3k9MA0KCUkvTyBiZWhp
bmQgYnJpZGdlOiAwMDAwZTAwMC0wMDAwZWZmZg0KCU1lbW9yeSBiZWhpbmQgYnJpZGdlOiBm
YTAwMDAwMC1mZTlmZmZmZg0KCVByZWZldGNoYWJsZSBtZW1vcnkgYmVoaW5kIGJyaWRnZTog
MDAwMDAwMDBkMDAwMDAwMC0wMDAwMDAwMGRmZmZmZmZmDQoJU2Vjb25kYXJ5IHN0YXR1czog
NjZNSHotIEZhc3RCMkItIFBhckVyci0gREVWU0VMPWZhc3QgPlRBYm9ydC0gPFRBYm9ydC0g
PE1BYm9ydC0gPFNFUlItIDxQRVJSLQ0KCUJyaWRnZUN0bDogUGFyaXR5KyBTRVJSKyBOb0lT
QS0gVkdBKyBNQWJvcnQtID5SZXNldC0gRmFzdEIyQi0NCgkJUHJpRGlzY1Rtci0gU2VjRGlz
Y1Rtci0gRGlzY1RtclN0YXQtIERpc2NUbXJTRVJSRW4tDQoJQ2FwYWJpbGl0aWVzOiBbNTBd
IFBvd2VyIE1hbmFnZW1lbnQgdmVyc2lvbiAzDQoJCUZsYWdzOiBQTUVDbGstIERTSS0gRDEt
IEQyLSBBdXhDdXJyZW50PTBtQSBQTUUoRDArLEQxLSxEMi0sRDNob3QrLEQzY29sZCspDQoJ
CVN0YXR1czogRDAgTm9Tb2Z0UnN0LSBQTUUtRW5hYmxlLSBEU2VsPTAgRFNjYWxlPTAgUE1F
LQ0KCUNhcGFiaWxpdGllczogWzU4XSBFeHByZXNzICh2MikgUm9vdCBQb3J0IChTbG90Kyks
IE1TSSAwMA0KCQlEZXZDYXA6CU1heFBheWxvYWQgMTI4IGJ5dGVzLCBQaGFudEZ1bmMgMCwg
TGF0ZW5jeSBMMHMgPDY0bnMsIEwxIDwxdXMNCgkJCUV4dFRhZysgUkJFKyBGTFJlc2V0LQ0K
CQlEZXZDdGw6CVJlcG9ydCBlcnJvcnM6IENvcnJlY3RhYmxlLSBOb24tRmF0YWwtIEZhdGFs
LSBVbnN1cHBvcnRlZC0NCgkJCVJseGRPcmQrIEV4dFRhZy0gUGhhbnRGdW5jLSBBdXhQd3It
IE5vU25vb3ArDQoJCQlNYXhQYXlsb2FkIDEyOCBieXRlcywgTWF4UmVhZFJlcSAxMjggYnl0
ZXMNCgkJRGV2U3RhOglDb3JyRXJyLSBVbmNvcnJFcnItIEZhdGFsRXJyLSBVbnN1cHBSZXEt
IEF1eFB3ci0gVHJhbnNQZW5kLQ0KCQlMbmtDYXA6CVBvcnQgIzAsIFNwZWVkIDVHVC9zLCBX
aWR0aCB4OCwgQVNQTSBMMHMgTDEsIExhdGVuY3kgTDAgPDF1cywgTDEgPDh1cw0KCQkJQ2xv
Y2tQTS0gU3VycHJpc2UtIExMQWN0UmVwKyBCd05vdCsNCgkJTG5rQ3RsOglBU1BNIERpc2Fi
bGVkOyBSQ0IgNjQgYnl0ZXMgRGlzYWJsZWQtIFJldHJhaW4tIENvbW1DbGsrDQoJCQlFeHRT
eW5jaC0gQ2xvY2tQTS0gQXV0V2lkRGlzLSBCV0ludC0gQXV0QldJbnQtDQoJCUxua1N0YToJ
U3BlZWQgMi41R1QvcywgV2lkdGggeDgsIFRyRXJyLSBUcmFpbi0gU2xvdENsaysgRExBY3Rp
dmUrIEJXTWdtdCsgQUJXTWdtdC0NCgkJU2x0Q2FwOglBdHRuQnRuLSBQd3JDdHJsLSBNUkwt
IEF0dG5JbmQtIFB3ckluZC0gSG90UGx1Zy0gU3VycHJpc2UtDQoJCQlTbG90ICMxLCBQb3dl
ckxpbWl0IDI1LjAwMFc7IEludGVybG9jay0gTm9Db21wbCsNCgkJU2x0Q3RsOglFbmFibGU6
IEF0dG5CdG4tIFB3ckZsdC0gTVJMLSBQcmVzRGV0LSBDbWRDcGx0LSBIUElycS0gTGlua0No
Zy0NCgkJCUNvbnRyb2w6IEF0dG5JbmQgVW5rbm93biwgUHdySW5kIFVua25vd24sIFBvd2Vy
LSBJbnRlcmxvY2stDQoJCVNsdFN0YToJU3RhdHVzOiBBdHRuQnRuLSBQb3dlckZsdC0gTVJM
LSBDbWRDcGx0LSBQcmVzRGV0KyBJbnRlcmxvY2stDQoJCQlDaGFuZ2VkOiBNUkwtIFByZXNE
ZXQrIExpbmtTdGF0ZSsNCgkJUm9vdEN0bDogRXJyQ29ycmVjdGFibGUtIEVyck5vbi1GYXRh
bC0gRXJyRmF0YWwtIFBNRUludEVuYS0gQ1JTVmlzaWJsZS0NCgkJUm9vdENhcDogQ1JTVmlz
aWJsZS0NCgkJUm9vdFN0YTogUE1FIFJlcUlEIDAwMDAsIFBNRVN0YXR1cy0gUE1FUGVuZGlu
Zy0NCgkJRGV2Q2FwMjogQ29tcGxldGlvbiBUaW1lb3V0OiBSYW5nZSBBQkNELCBUaW1lb3V0
RGlzKyBBUklGd2QrDQoJCURldkN0bDI6IENvbXBsZXRpb24gVGltZW91dDogNjVtcyB0byAy
MTBtcywgVGltZW91dERpcy0gQVJJRndkLQ0KCQlMbmtDdGwyOiBUYXJnZXQgTGluayBTcGVl
ZDogNUdUL3MsIEVudGVyQ29tcGxpYW5jZS0gU3BlZWREaXMtLCBTZWxlY3RhYmxlIERlLWVt
cGhhc2lzOiAtMy41ZEINCgkJCSBUcmFuc21pdCBNYXJnaW46IE5vcm1hbCBPcGVyYXRpbmcg
UmFuZ2UsIEVudGVyTW9kaWZpZWRDb21wbGlhbmNlLSBDb21wbGlhbmNlU09TLQ0KCQkJIENv
bXBsaWFuY2UgRGUtZW1waGFzaXM6IC02ZEINCgkJTG5rU3RhMjogQ3VycmVudCBEZS1lbXBo
YXNpcyBMZXZlbDogLTMuNWRCDQoJQ2FwYWJpbGl0aWVzOiBbYTBdIE1TSTogRW5hYmxlKyBD
b3VudD0xLzEgTWFza2FibGUtIDY0Yml0LQ0KCQlBZGRyZXNzOiBmZWUzZjAwYyAgRGF0YTog
NDE1MQ0KCUNhcGFiaWxpdGllczogW2IwXSBTdWJzeXN0ZW06IEFUSSBUZWNobm9sb2dpZXMg
SW5jIERldmljZSBbMTAwMjo1YTExXQ0KCUNhcGFiaWxpdGllczogW2I4XSBIeXBlclRyYW5z
cG9ydDogTVNJIE1hcHBpbmcgRW5hYmxlKyBGaXhlZCsNCglDYXBhYmlsaXRpZXM6IFsxMDAg
djFdIFZlbmRvciBTcGVjaWZpYyBJbmZvcm1hdGlvbjogSUQ9MDAwMSBSZXY9MSBMZW49MDEw
IDw/Pg0KCUNhcGFiaWxpdGllczogWzE5MCB2MV0gQWNjZXNzIENvbnRyb2wgU2VydmljZXMN
CgkJQUNTQ2FwOglTcmNWYWxpZCsgVHJhbnNCbGsrIFJlcVJlZGlyKyBDbXBsdFJlZGlyKyBV
cHN0cmVhbUZ3ZCsgRWdyZXNzQ3RybC0gRGlyZWN0VHJhbnMrDQoJCUFDU0N0bDoJU3JjVmFs
aWQrIFRyYW5zQmxrLSBSZXFSZWRpcisgQ21wbHRSZWRpcisgVXBzdHJlYW1Gd2QrIEVncmVz
c0N0cmwtIERpcmVjdFRyYW5zLQ0KCUtlcm5lbCBkcml2ZXIgaW4gdXNlOiBwY2llcG9ydA0K
DQowMDowMy4wIFBDSSBicmlkZ2UgWzA2MDRdOiBBVEkgVGVjaG5vbG9naWVzIEluYyBSRDg5
MCBQQ0kgdG8gUENJIGJyaWRnZSAoUENJIGV4cHJlc3MgZ3BwIHBvcnQgQykgWzEwMDI6NWEx
N10gKHByb2ctaWYgMDAgW05vcm1hbCBkZWNvZGVdKQ0KCUNvbnRyb2w6IEkvTy0gTWVtKyBC
dXNNYXN0ZXIrIFNwZWNDeWNsZS0gTWVtV0lOVi0gVkdBU25vb3AtIFBhckVyci0gU3RlcHBp
bmctIFNFUlIrIEZhc3RCMkItIERpc0lOVHgrDQoJU3RhdHVzOiBDYXArIDY2TUh6LSBVREYt
IEZhc3RCMkItIFBhckVyci0gREVWU0VMPWZhc3QgPlRBYm9ydC0gPFRBYm9ydCsgPE1BYm9y
dC0gPlNFUlItIDxQRVJSLSBJTlR4LQ0KCUxhdGVuY3k6IDAsIENhY2hlIExpbmUgU2l6ZTog
NjQgYnl0ZXMNCglCdXM6IHByaW1hcnk9MDAsIHNlY29uZGFyeT0wYSwgc3Vib3JkaW5hdGU9
MGEsIHNlYy1sYXRlbmN5PTANCglJL08gYmVoaW5kIGJyaWRnZTogMDAwMGYwMDAtMDAwMDBm
ZmYNCglNZW1vcnkgYmVoaW5kIGJyaWRnZTogZjlmMDAwMDAtZjlmZmZmZmYNCglQcmVmZXRj
aGFibGUgbWVtb3J5IGJlaGluZCBicmlkZ2U6IDAwMDAwMDAwZmZmMDAwMDAtMDAwMDAwMDAw
MDBmZmZmZg0KCVNlY29uZGFyeSBzdGF0dXM6IDY2TUh6LSBGYXN0QjJCLSBQYXJFcnItIERF
VlNFTD1mYXN0ID5UQWJvcnQrIDxUQWJvcnQtIDxNQWJvcnQtIDxTRVJSLSA8UEVSUi0NCglC
cmlkZ2VDdGw6IFBhcml0eSsgU0VSUisgTm9JU0ErIFZHQS0gTUFib3J0LSA+UmVzZXQtIEZh
c3RCMkItDQoJCVByaURpc2NUbXItIFNlY0Rpc2NUbXItIERpc2NUbXJTdGF0LSBEaXNjVG1y
U0VSUkVuLQ0KCUNhcGFiaWxpdGllczogWzUwXSBQb3dlciBNYW5hZ2VtZW50IHZlcnNpb24g
Mw0KCQlGbGFnczogUE1FQ2xrLSBEU0ktIEQxLSBEMi0gQXV4Q3VycmVudD0wbUEgUE1FKEQw
KyxEMS0sRDItLEQzaG90KyxEM2NvbGQrKQ0KCQlTdGF0dXM6IEQwIE5vU29mdFJzdC0gUE1F
LUVuYWJsZS0gRFNlbD0wIERTY2FsZT0wIFBNRS0NCglDYXBhYmlsaXRpZXM6IFs1OF0gRXhw
cmVzcyAodjIpIFJvb3QgUG9ydCAoU2xvdCspLCBNU0kgMDANCgkJRGV2Q2FwOglNYXhQYXls
b2FkIDEyOCBieXRlcywgUGhhbnRGdW5jIDAsIExhdGVuY3kgTDBzIDw2NG5zLCBMMSA8MXVz
DQoJCQlFeHRUYWcrIFJCRSsgRkxSZXNldC0NCgkJRGV2Q3RsOglSZXBvcnQgZXJyb3JzOiBD
b3JyZWN0YWJsZS0gTm9uLUZhdGFsLSBGYXRhbC0gVW5zdXBwb3J0ZWQtDQoJCQlSbHhkT3Jk
KyBFeHRUYWctIFBoYW50RnVuYy0gQXV4UHdyLSBOb1Nub29wKw0KCQkJTWF4UGF5bG9hZCAx
MjggYnl0ZXMsIE1heFJlYWRSZXEgMTI4IGJ5dGVzDQoJCURldlN0YToJQ29yckVyci0gVW5j
b3JyRXJyLSBGYXRhbEVyci0gVW5zdXBwUmVxLSBBdXhQd3ItIFRyYW5zUGVuZC0NCgkJTG5r
Q2FwOglQb3J0ICMxLCBTcGVlZCA1R1QvcywgV2lkdGggeDgsIEFTUE0gTDBzIEwxLCBMYXRl
bmN5IEwwIDwxdXMsIEwxIDw4dXMNCgkJCUNsb2NrUE0tIFN1cnByaXNlLSBMTEFjdFJlcCsg
QndOb3QrDQoJCUxua0N0bDoJQVNQTSBEaXNhYmxlZDsgUkNCIDY0IGJ5dGVzIERpc2FibGVk
LSBSZXRyYWluLSBDb21tQ2xrLQ0KCQkJRXh0U3luY2gtIENsb2NrUE0tIEF1dFdpZERpcy0g
QldJbnQtIEF1dEJXSW50LQ0KCQlMbmtTdGE6CVNwZWVkIDIuNUdUL3MsIFdpZHRoIHgxLCBU
ckVyci0gVHJhaW4tIFNsb3RDbGsrIERMQWN0aXZlKyBCV01nbXQrIEFCV01nbXQtDQoJCVNs
dENhcDoJQXR0bkJ0bi0gUHdyQ3RybC0gTVJMLSBBdHRuSW5kLSBQd3JJbmQtIEhvdFBsdWct
IFN1cnByaXNlLQ0KCQkJU2xvdCAjMywgUG93ZXJMaW1pdCAxMC4wMDBXOyBJbnRlcmxvY2st
IE5vQ29tcGwrDQoJCVNsdEN0bDoJRW5hYmxlOiBBdHRuQnRuLSBQd3JGbHQtIE1STC0gUHJl
c0RldC0gQ21kQ3BsdC0gSFBJcnEtIExpbmtDaGctDQoJCQlDb250cm9sOiBBdHRuSW5kIFVu
a25vd24sIFB3ckluZCBVbmtub3duLCBQb3dlci0gSW50ZXJsb2NrLQ0KCQlTbHRTdGE6CVN0
YXR1czogQXR0bkJ0bi0gUG93ZXJGbHQtIE1STC0gQ21kQ3BsdC0gUHJlc0RldCsgSW50ZXJs
b2NrLQ0KCQkJQ2hhbmdlZDogTVJMLSBQcmVzRGV0KyBMaW5rU3RhdGUrDQoJCVJvb3RDdGw6
IEVyckNvcnJlY3RhYmxlLSBFcnJOb24tRmF0YWwtIEVyckZhdGFsLSBQTUVJbnRFbmEtIENS
U1Zpc2libGUtDQoJCVJvb3RDYXA6IENSU1Zpc2libGUtDQoJCVJvb3RTdGE6IFBNRSBSZXFJ
RCAwMDAwLCBQTUVTdGF0dXMtIFBNRVBlbmRpbmctDQoJCURldkNhcDI6IENvbXBsZXRpb24g
VGltZW91dDogUmFuZ2UgQUJDRCwgVGltZW91dERpcysgQVJJRndkKw0KCQlEZXZDdGwyOiBD
b21wbGV0aW9uIFRpbWVvdXQ6IDY1bXMgdG8gMjEwbXMsIFRpbWVvdXREaXMtIEFSSUZ3ZC0N
CgkJTG5rQ3RsMjogVGFyZ2V0IExpbmsgU3BlZWQ6IDVHVC9zLCBFbnRlckNvbXBsaWFuY2Ut
IFNwZWVkRGlzLSwgU2VsZWN0YWJsZSBEZS1lbXBoYXNpczogLTMuNWRCDQoJCQkgVHJhbnNt
aXQgTWFyZ2luOiBOb3JtYWwgT3BlcmF0aW5nIFJhbmdlLCBFbnRlck1vZGlmaWVkQ29tcGxp
YW5jZS0gQ29tcGxpYW5jZVNPUy0NCgkJCSBDb21wbGlhbmNlIERlLWVtcGhhc2lzOiAtNmRC
DQoJCUxua1N0YTI6IEN1cnJlbnQgRGUtZW1waGFzaXMgTGV2ZWw6IC0zLjVkQg0KCUNhcGFi
aWxpdGllczogW2EwXSBNU0k6IEVuYWJsZSsgQ291bnQ9MS8xIE1hc2thYmxlLSA2NGJpdC0N
CgkJQWRkcmVzczogZmVlM2YwMGMgIERhdGE6IDQxNTkNCglDYXBhYmlsaXRpZXM6IFtiMF0g
U3Vic3lzdGVtOiBBVEkgVGVjaG5vbG9naWVzIEluYyBEZXZpY2UgWzEwMDI6NWExMV0NCglD
YXBhYmlsaXRpZXM6IFtiOF0gSHlwZXJUcmFuc3BvcnQ6IE1TSSBNYXBwaW5nIEVuYWJsZSsg
Rml4ZWQrDQoJQ2FwYWJpbGl0aWVzOiBbMTAwIHYxXSBWZW5kb3IgU3BlY2lmaWMgSW5mb3Jt
YXRpb246IElEPTAwMDEgUmV2PTEgTGVuPTAxMCA8Pz4NCglDYXBhYmlsaXRpZXM6IFsxOTAg
djFdIEFjY2VzcyBDb250cm9sIFNlcnZpY2VzDQoJCUFDU0NhcDoJU3JjVmFsaWQrIFRyYW5z
QmxrKyBSZXFSZWRpcisgQ21wbHRSZWRpcisgVXBzdHJlYW1Gd2QrIEVncmVzc0N0cmwtIERp
cmVjdFRyYW5zKw0KCQlBQ1NDdGw6CVNyY1ZhbGlkKyBUcmFuc0Jsay0gUmVxUmVkaXIrIENt
cGx0UmVkaXIrIFVwc3RyZWFtRndkKyBFZ3Jlc3NDdHJsLSBEaXJlY3RUcmFucy0NCglLZXJu
ZWwgZHJpdmVyIGluIHVzZTogcGNpZXBvcnQNCg0KMDA6MDUuMCBQQ0kgYnJpZGdlIFswNjA0
XTogQVRJIFRlY2hub2xvZ2llcyBJbmMgUkQ4OTAgUENJIHRvIFBDSSBicmlkZ2UgKFBDSSBl
eHByZXNzIGdwcCBwb3J0IEUpIFsxMDAyOjVhMTldIChwcm9nLWlmIDAwIFtOb3JtYWwgZGVj
b2RlXSkNCglDb250cm9sOiBJL08rIE1lbSsgQnVzTWFzdGVyKyBTcGVjQ3ljbGUtIE1lbVdJ
TlYtIFZHQVNub29wLSBQYXJFcnItIFN0ZXBwaW5nLSBTRVJSKyBGYXN0QjJCLSBEaXNJTlR4
Kw0KCVN0YXR1czogQ2FwKyA2Nk1Iei0gVURGLSBGYXN0QjJCLSBQYXJFcnItIERFVlNFTD1m
YXN0ID5UQWJvcnQtIDxUQWJvcnQtIDxNQWJvcnQtID5TRVJSLSA8UEVSUi0gSU5UeC0NCglM
YXRlbmN5OiAwLCBDYWNoZSBMaW5lIFNpemU6IDY0IGJ5dGVzDQoJQnVzOiBwcmltYXJ5PTAw
LCBzZWNvbmRhcnk9MDksIHN1Ym9yZGluYXRlPTA5LCBzZWMtbGF0ZW5jeT0wDQoJSS9PIGJl
aGluZCBicmlkZ2U6IDAwMDBkMDAwLTAwMDBkZmZmDQoJTWVtb3J5IGJlaGluZCBicmlkZ2U6
IGY5ZTAwMDAwLWY5ZWZmZmZmDQoJUHJlZmV0Y2hhYmxlIG1lbW9yeSBiZWhpbmQgYnJpZGdl
OiAwMDAwMDAwMGNmZjAwMDAwLTAwMDAwMDAwY2ZmZmZmZmYNCglTZWNvbmRhcnkgc3RhdHVz
OiA2Nk1Iei0gRmFzdEIyQi0gUGFyRXJyLSBERVZTRUw9ZmFzdCA+VEFib3J0LSA8VEFib3J0
LSA8TUFib3J0LSA8U0VSUi0gPFBFUlItDQoJQnJpZGdlQ3RsOiBQYXJpdHkrIFNFUlIrIE5v
SVNBKyBWR0EtIE1BYm9ydC0gPlJlc2V0LSBGYXN0QjJCLQ0KCQlQcmlEaXNjVG1yLSBTZWNE
aXNjVG1yLSBEaXNjVG1yU3RhdC0gRGlzY1RtclNFUlJFbi0NCglDYXBhYmlsaXRpZXM6IFs1
MF0gUG93ZXIgTWFuYWdlbWVudCB2ZXJzaW9uIDMNCgkJRmxhZ3M6IFBNRUNsay0gRFNJLSBE
MS0gRDItIEF1eEN1cnJlbnQ9MG1BIFBNRShEMCssRDEtLEQyLSxEM2hvdCssRDNjb2xkKykN
CgkJU3RhdHVzOiBEMCBOb1NvZnRSc3QtIFBNRS1FbmFibGUtIERTZWw9MCBEU2NhbGU9MCBQ
TUUtDQoJQ2FwYWJpbGl0aWVzOiBbNThdIEV4cHJlc3MgKHYyKSBSb290IFBvcnQgKFNsb3Qr
KSwgTVNJIDAwDQoJCURldkNhcDoJTWF4UGF5bG9hZCAxMjggYnl0ZXMsIFBoYW50RnVuYyAw
LCBMYXRlbmN5IEwwcyA8NjRucywgTDEgPDF1cw0KCQkJRXh0VGFnKyBSQkUrIEZMUmVzZXQt
DQoJCURldkN0bDoJUmVwb3J0IGVycm9yczogQ29ycmVjdGFibGUtIE5vbi1GYXRhbC0gRmF0
YWwtIFVuc3VwcG9ydGVkLQ0KCQkJUmx4ZE9yZCsgRXh0VGFnLSBQaGFudEZ1bmMtIEF1eFB3
ci0gTm9Tbm9vcCsNCgkJCU1heFBheWxvYWQgMTI4IGJ5dGVzLCBNYXhSZWFkUmVxIDEyOCBi
eXRlcw0KCQlEZXZTdGE6CUNvcnJFcnItIFVuY29yckVyci0gRmF0YWxFcnItIFVuc3VwcFJl
cS0gQXV4UHdyLSBUcmFuc1BlbmQtDQoJCUxua0NhcDoJUG9ydCAjMSwgU3BlZWQgNUdUL3Ms
IFdpZHRoIHgxLCBBU1BNIEwwcyBMMSwgTGF0ZW5jeSBMMCA8MXVzLCBMMSA8OHVzDQoJCQlD
bG9ja1BNLSBTdXJwcmlzZS0gTExBY3RSZXArIEJ3Tm90Kw0KCQlMbmtDdGw6CUFTUE0gRGlz
YWJsZWQ7IFJDQiA2NCBieXRlcyBEaXNhYmxlZC0gUmV0cmFpbi0gQ29tbUNsaysNCgkJCUV4
dFN5bmNoLSBDbG9ja1BNLSBBdXRXaWREaXMtIEJXSW50LSBBdXRCV0ludC0NCgkJTG5rU3Rh
OglTcGVlZCAyLjVHVC9zLCBXaWR0aCB4MSwgVHJFcnItIFRyYWluLSBTbG90Q2xrKyBETEFj
dGl2ZSsgQldNZ210KyBBQldNZ210LQ0KCQlTbHRDYXA6CUF0dG5CdG4tIFB3ckN0cmwtIE1S
TC0gQXR0bkluZC0gUHdySW5kLSBIb3RQbHVnLSBTdXJwcmlzZS0NCgkJCVNsb3QgIzUsIFBv
d2VyTGltaXQgNzUuMDAwVzsgSW50ZXJsb2NrLSBOb0NvbXBsKw0KCQlTbHRDdGw6CUVuYWJs
ZTogQXR0bkJ0bi0gUHdyRmx0LSBNUkwtIFByZXNEZXQtIENtZENwbHQtIEhQSXJxLSBMaW5r
Q2hnLQ0KCQkJQ29udHJvbDogQXR0bkluZCBVbmtub3duLCBQd3JJbmQgVW5rbm93biwgUG93
ZXItIEludGVybG9jay0NCgkJU2x0U3RhOglTdGF0dXM6IEF0dG5CdG4tIFBvd2VyRmx0LSBN
UkwtIENtZENwbHQtIFByZXNEZXQrIEludGVybG9jay0NCgkJCUNoYW5nZWQ6IE1STC0gUHJl
c0RldCsgTGlua1N0YXRlKw0KCQlSb290Q3RsOiBFcnJDb3JyZWN0YWJsZS0gRXJyTm9uLUZh
dGFsLSBFcnJGYXRhbC0gUE1FSW50RW5hLSBDUlNWaXNpYmxlLQ0KCQlSb290Q2FwOiBDUlNW
aXNpYmxlLQ0KCQlSb290U3RhOiBQTUUgUmVxSUQgMDAwMCwgUE1FU3RhdHVzLSBQTUVQZW5k
aW5nLQ0KCQlEZXZDYXAyOiBDb21wbGV0aW9uIFRpbWVvdXQ6IFJhbmdlIEFCQ0QsIFRpbWVv
dXREaXMrIEFSSUZ3ZCsNCgkJRGV2Q3RsMjogQ29tcGxldGlvbiBUaW1lb3V0OiA2NW1zIHRv
IDIxMG1zLCBUaW1lb3V0RGlzLSBBUklGd2QtDQoJCUxua0N0bDI6IFRhcmdldCBMaW5rIFNw
ZWVkOiA1R1QvcywgRW50ZXJDb21wbGlhbmNlLSBTcGVlZERpcy0sIFNlbGVjdGFibGUgRGUt
ZW1waGFzaXM6IC0zLjVkQg0KCQkJIFRyYW5zbWl0IE1hcmdpbjogTm9ybWFsIE9wZXJhdGlu
ZyBSYW5nZSwgRW50ZXJNb2RpZmllZENvbXBsaWFuY2UtIENvbXBsaWFuY2VTT1MtDQoJCQkg
Q29tcGxpYW5jZSBEZS1lbXBoYXNpczogLTZkQg0KCQlMbmtTdGEyOiBDdXJyZW50IERlLWVt
cGhhc2lzIExldmVsOiAtMy41ZEINCglDYXBhYmlsaXRpZXM6IFthMF0gTVNJOiBFbmFibGUr
IENvdW50PTEvMSBNYXNrYWJsZS0gNjRiaXQtDQoJCUFkZHJlc3M6IGZlZTNmMDBjICBEYXRh
OiA0MTYxDQoJQ2FwYWJpbGl0aWVzOiBbYjBdIFN1YnN5c3RlbTogQVRJIFRlY2hub2xvZ2ll
cyBJbmMgRGV2aWNlIFsxMDAyOjVhMTFdDQoJQ2FwYWJpbGl0aWVzOiBbYjhdIEh5cGVyVHJh
bnNwb3J0OiBNU0kgTWFwcGluZyBFbmFibGUrIEZpeGVkKw0KCUNhcGFiaWxpdGllczogWzEw
MCB2MV0gVmVuZG9yIFNwZWNpZmljIEluZm9ybWF0aW9uOiBJRD0wMDAxIFJldj0xIExlbj0w
MTAgPD8+DQoJQ2FwYWJpbGl0aWVzOiBbMTkwIHYxXSBBY2Nlc3MgQ29udHJvbCBTZXJ2aWNl
cw0KCQlBQ1NDYXA6CVNyY1ZhbGlkKyBUcmFuc0JsaysgUmVxUmVkaXIrIENtcGx0UmVkaXIr
IFVwc3RyZWFtRndkKyBFZ3Jlc3NDdHJsLSBEaXJlY3RUcmFucysNCgkJQUNTQ3RsOglTcmNW
YWxpZCsgVHJhbnNCbGstIFJlcVJlZGlyKyBDbXBsdFJlZGlyKyBVcHN0cmVhbUZ3ZCsgRWdy
ZXNzQ3RybC0gRGlyZWN0VHJhbnMtDQoJS2VybmVsIGRyaXZlciBpbiB1c2U6IHBjaWVwb3J0
DQoNCjAwOjA2LjAgUENJIGJyaWRnZSBbMDYwNF06IEFUSSBUZWNobm9sb2dpZXMgSW5jIFJE
ODkwIFBDSSB0byBQQ0kgYnJpZGdlIChQQ0kgZXhwcmVzcyBncHAgcG9ydCBGKSBbMTAwMjo1
YTFhXSAocHJvZy1pZiAwMCBbTm9ybWFsIGRlY29kZV0pDQoJQ29udHJvbDogSS9PKyBNZW0r
IEJ1c01hc3RlcisgU3BlY0N5Y2xlLSBNZW1XSU5WLSBWR0FTbm9vcC0gUGFyRXJyLSBTdGVw
cGluZy0gU0VSUisgRmFzdEIyQi0gRGlzSU5UeCsNCglTdGF0dXM6IENhcCsgNjZNSHotIFVE
Ri0gRmFzdEIyQi0gUGFyRXJyLSBERVZTRUw9ZmFzdCA+VEFib3J0LSA8VEFib3J0LSA8TUFi
b3J0LSA+U0VSUi0gPFBFUlItIElOVHgtDQoJTGF0ZW5jeTogMCwgQ2FjaGUgTGluZSBTaXpl
OiA2NCBieXRlcw0KCUJ1czogcHJpbWFyeT0wMCwgc2Vjb25kYXJ5PTA4LCBzdWJvcmRpbmF0
ZT0wOCwgc2VjLWxhdGVuY3k9MA0KCUkvTyBiZWhpbmQgYnJpZGdlOiAwMDAwYzAwMC0wMDAw
Y2ZmZg0KCU1lbW9yeSBiZWhpbmQgYnJpZGdlOiBmOWQwMDAwMC1mOWRmZmZmZg0KCVByZWZl
dGNoYWJsZSBtZW1vcnkgYmVoaW5kIGJyaWRnZTogMDAwMDAwMDBjZmUwMDAwMC0wMDAwMDAw
MGNmZWZmZmZmDQoJU2Vjb25kYXJ5IHN0YXR1czogNjZNSHotIEZhc3RCMkItIFBhckVyci0g
REVWU0VMPWZhc3QgPlRBYm9ydC0gPFRBYm9ydC0gPE1BYm9ydC0gPFNFUlItIDxQRVJSLQ0K
CUJyaWRnZUN0bDogUGFyaXR5KyBTRVJSKyBOb0lTQSsgVkdBLSBNQWJvcnQtID5SZXNldC0g
RmFzdEIyQi0NCgkJUHJpRGlzY1Rtci0gU2VjRGlzY1Rtci0gRGlzY1RtclN0YXQtIERpc2NU
bXJTRVJSRW4tDQoJQ2FwYWJpbGl0aWVzOiBbNTBdIFBvd2VyIE1hbmFnZW1lbnQgdmVyc2lv
biAzDQoJCUZsYWdzOiBQTUVDbGstIERTSS0gRDEtIEQyLSBBdXhDdXJyZW50PTBtQSBQTUUo
RDArLEQxLSxEMi0sRDNob3QrLEQzY29sZCspDQoJCVN0YXR1czogRDAgTm9Tb2Z0UnN0LSBQ
TUUtRW5hYmxlLSBEU2VsPTAgRFNjYWxlPTAgUE1FLQ0KCUNhcGFiaWxpdGllczogWzU4XSBF
eHByZXNzICh2MikgUm9vdCBQb3J0IChTbG90KyksIE1TSSAwMA0KCQlEZXZDYXA6CU1heFBh
eWxvYWQgMTI4IGJ5dGVzLCBQaGFudEZ1bmMgMCwgTGF0ZW5jeSBMMHMgPDY0bnMsIEwxIDwx
dXMNCgkJCUV4dFRhZysgUkJFKyBGTFJlc2V0LQ0KCQlEZXZDdGw6CVJlcG9ydCBlcnJvcnM6
IENvcnJlY3RhYmxlLSBOb24tRmF0YWwtIEZhdGFsLSBVbnN1cHBvcnRlZC0NCgkJCVJseGRP
cmQrIEV4dFRhZy0gUGhhbnRGdW5jLSBBdXhQd3ItIE5vU25vb3ArDQoJCQlNYXhQYXlsb2Fk
IDEyOCBieXRlcywgTWF4UmVhZFJlcSAxMjggYnl0ZXMNCgkJRGV2U3RhOglDb3JyRXJyLSBV
bmNvcnJFcnItIEZhdGFsRXJyLSBVbnN1cHBSZXEtIEF1eFB3ci0gVHJhbnNQZW5kLQ0KCQlM
bmtDYXA6CVBvcnQgIzIsIFNwZWVkIDVHVC9zLCBXaWR0aCB4MSwgQVNQTSBMMHMgTDEsIExh
dGVuY3kgTDAgPDF1cywgTDEgPDh1cw0KCQkJQ2xvY2tQTS0gU3VycHJpc2UtIExMQWN0UmVw
KyBCd05vdCsNCgkJTG5rQ3RsOglBU1BNIERpc2FibGVkOyBSQ0IgNjQgYnl0ZXMgRGlzYWJs
ZWQtIFJldHJhaW4tIENvbW1DbGsrDQoJCQlFeHRTeW5jaC0gQ2xvY2tQTS0gQXV0V2lkRGlz
LSBCV0ludC0gQXV0QldJbnQtDQoJCUxua1N0YToJU3BlZWQgMi41R1QvcywgV2lkdGggeDEs
IFRyRXJyLSBUcmFpbi0gU2xvdENsaysgRExBY3RpdmUrIEJXTWdtdCsgQUJXTWdtdC0NCgkJ
U2x0Q2FwOglBdHRuQnRuLSBQd3JDdHJsLSBNUkwtIEF0dG5JbmQtIFB3ckluZC0gSG90UGx1
Zy0gU3VycHJpc2UtDQoJCQlTbG90ICM2LCBQb3dlckxpbWl0IDc1LjAwMFc7IEludGVybG9j
ay0gTm9Db21wbCsNCgkJU2x0Q3RsOglFbmFibGU6IEF0dG5CdG4tIFB3ckZsdC0gTVJMLSBQ
cmVzRGV0LSBDbWRDcGx0LSBIUElycS0gTGlua0NoZy0NCgkJCUNvbnRyb2w6IEF0dG5JbmQg
VW5rbm93biwgUHdySW5kIFVua25vd24sIFBvd2VyLSBJbnRlcmxvY2stDQoJCVNsdFN0YToJ
U3RhdHVzOiBBdHRuQnRuLSBQb3dlckZsdC0gTVJMLSBDbWRDcGx0LSBQcmVzRGV0KyBJbnRl
cmxvY2stDQoJCQlDaGFuZ2VkOiBNUkwtIFByZXNEZXQrIExpbmtTdGF0ZSsNCgkJUm9vdEN0
bDogRXJyQ29ycmVjdGFibGUtIEVyck5vbi1GYXRhbC0gRXJyRmF0YWwtIFBNRUludEVuYS0g
Q1JTVmlzaWJsZS0NCgkJUm9vdENhcDogQ1JTVmlzaWJsZS0NCgkJUm9vdFN0YTogUE1FIFJl
cUlEIDAwMDAsIFBNRVN0YXR1cy0gUE1FUGVuZGluZy0NCgkJRGV2Q2FwMjogQ29tcGxldGlv
biBUaW1lb3V0OiBSYW5nZSBBQkNELCBUaW1lb3V0RGlzKyBBUklGd2QrDQoJCURldkN0bDI6
IENvbXBsZXRpb24gVGltZW91dDogNjVtcyB0byAyMTBtcywgVGltZW91dERpcy0gQVJJRndk
LQ0KCQlMbmtDdGwyOiBUYXJnZXQgTGluayBTcGVlZDogNUdUL3MsIEVudGVyQ29tcGxpYW5j
ZS0gU3BlZWREaXMtLCBTZWxlY3RhYmxlIERlLWVtcGhhc2lzOiAtMy41ZEINCgkJCSBUcmFu
c21pdCBNYXJnaW46IE5vcm1hbCBPcGVyYXRpbmcgUmFuZ2UsIEVudGVyTW9kaWZpZWRDb21w
bGlhbmNlLSBDb21wbGlhbmNlU09TLQ0KCQkJIENvbXBsaWFuY2UgRGUtZW1waGFzaXM6IC02
ZEINCgkJTG5rU3RhMjogQ3VycmVudCBEZS1lbXBoYXNpcyBMZXZlbDogLTMuNWRCDQoJQ2Fw
YWJpbGl0aWVzOiBbYTBdIE1TSTogRW5hYmxlKyBDb3VudD0xLzEgTWFza2FibGUtIDY0Yml0
LQ0KCQlBZGRyZXNzOiBmZWUzZjAwYyAgRGF0YTogNDE2OQ0KCUNhcGFiaWxpdGllczogW2Iw
XSBTdWJzeXN0ZW06IEFUSSBUZWNobm9sb2dpZXMgSW5jIERldmljZSBbMTAwMjo1YTExXQ0K
CUNhcGFiaWxpdGllczogW2I4XSBIeXBlclRyYW5zcG9ydDogTVNJIE1hcHBpbmcgRW5hYmxl
KyBGaXhlZCsNCglDYXBhYmlsaXRpZXM6IFsxMDAgdjFdIFZlbmRvciBTcGVjaWZpYyBJbmZv
cm1hdGlvbjogSUQ9MDAwMSBSZXY9MSBMZW49MDEwIDw/Pg0KCUNhcGFiaWxpdGllczogWzE5
MCB2MV0gQWNjZXNzIENvbnRyb2wgU2VydmljZXMNCgkJQUNTQ2FwOglTcmNWYWxpZCsgVHJh
bnNCbGsrIFJlcVJlZGlyKyBDbXBsdFJlZGlyKyBVcHN0cmVhbUZ3ZCsgRWdyZXNzQ3RybC0g
RGlyZWN0VHJhbnMrDQoJCUFDU0N0bDoJU3JjVmFsaWQrIFRyYW5zQmxrLSBSZXFSZWRpcisg
Q21wbHRSZWRpcisgVXBzdHJlYW1Gd2QrIEVncmVzc0N0cmwtIERpcmVjdFRyYW5zLQ0KCUtl
cm5lbCBkcml2ZXIgaW4gdXNlOiBwY2llcG9ydA0KDQowMDowYS4wIFBDSSBicmlkZ2UgWzA2
MDRdOiBBVEkgVGVjaG5vbG9naWVzIEluYyBSRDg5MCBQQ0kgdG8gUENJIGJyaWRnZSAoZXh0
ZXJuYWwgZ2Z4MSBwb3J0IEEpIFsxMDAyOjVhMWRdIChwcm9nLWlmIDAwIFtOb3JtYWwgZGVj
b2RlXSkNCglDb250cm9sOiBJL08tIE1lbSsgQnVzTWFzdGVyKyBTcGVjQ3ljbGUtIE1lbVdJ
TlYtIFZHQVNub29wLSBQYXJFcnItIFN0ZXBwaW5nLSBTRVJSKyBGYXN0QjJCLSBEaXNJTlR4
Kw0KCVN0YXR1czogQ2FwKyA2Nk1Iei0gVURGLSBGYXN0QjJCLSBQYXJFcnItIERFVlNFTD1m
YXN0ID5UQWJvcnQtIDxUQWJvcnQtIDxNQWJvcnQtID5TRVJSLSA8UEVSUi0gSU5UeC0NCglM
YXRlbmN5OiAwLCBDYWNoZSBMaW5lIFNpemU6IDY0IGJ5dGVzDQoJQnVzOiBwcmltYXJ5PTAw
LCBzZWNvbmRhcnk9MDcsIHN1Ym9yZGluYXRlPTA3LCBzZWMtbGF0ZW5jeT0wDQoJSS9PIGJl
aGluZCBicmlkZ2U6IDAwMDBmMDAwLTAwMDAwZmZmDQoJTWVtb3J5IGJlaGluZCBicmlkZ2U6
IGY5YTAwMDAwLWY5YmZmZmZmDQoJUHJlZmV0Y2hhYmxlIG1lbW9yeSBiZWhpbmQgYnJpZGdl
OiAwMDAwMDAwMGZmZjAwMDAwLTAwMDAwMDAwMDAwZmZmZmYNCglTZWNvbmRhcnkgc3RhdHVz
OiA2Nk1Iei0gRmFzdEIyQi0gUGFyRXJyLSBERVZTRUw9ZmFzdCA+VEFib3J0LSA8VEFib3J0
LSA8TUFib3J0KyA8U0VSUi0gPFBFUlItDQoJQnJpZGdlQ3RsOiBQYXJpdHkrIFNFUlIrIE5v
SVNBKyBWR0EtIE1BYm9ydC0gPlJlc2V0LSBGYXN0QjJCLQ0KCQlQcmlEaXNjVG1yLSBTZWNE
aXNjVG1yLSBEaXNjVG1yU3RhdC0gRGlzY1RtclNFUlJFbi0NCglDYXBhYmlsaXRpZXM6IFs1
MF0gUG93ZXIgTWFuYWdlbWVudCB2ZXJzaW9uIDMNCgkJRmxhZ3M6IFBNRUNsay0gRFNJLSBE
MS0gRDItIEF1eEN1cnJlbnQ9MG1BIFBNRShEMCssRDEtLEQyLSxEM2hvdCssRDNjb2xkKykN
CgkJU3RhdHVzOiBEMCBOb1NvZnRSc3QtIFBNRS1FbmFibGUtIERTZWw9MCBEU2NhbGU9MCBQ
TUUtDQoJQ2FwYWJpbGl0aWVzOiBbNThdIEV4cHJlc3MgKHYyKSBSb290IFBvcnQgKFNsb3Qr
KSwgTVNJIDAwDQoJCURldkNhcDoJTWF4UGF5bG9hZCAxMjggYnl0ZXMsIFBoYW50RnVuYyAw
LCBMYXRlbmN5IEwwcyA8NjRucywgTDEgPDF1cw0KCQkJRXh0VGFnKyBSQkUrIEZMUmVzZXQt
DQoJCURldkN0bDoJUmVwb3J0IGVycm9yczogQ29ycmVjdGFibGUtIE5vbi1GYXRhbC0gRmF0
YWwtIFVuc3VwcG9ydGVkLQ0KCQkJUmx4ZE9yZCsgRXh0VGFnLSBQaGFudEZ1bmMtIEF1eFB3
ci0gTm9Tbm9vcCsNCgkJCU1heFBheWxvYWQgMTI4IGJ5dGVzLCBNYXhSZWFkUmVxIDEyOCBi
eXRlcw0KCQlEZXZTdGE6CUNvcnJFcnItIFVuY29yckVyci0gRmF0YWxFcnItIFVuc3VwcFJl
cS0gQXV4UHdyLSBUcmFuc1BlbmQtDQoJCUxua0NhcDoJUG9ydCAjNSwgU3BlZWQgMi41R1Qv
cywgV2lkdGggeDEsIEFTUE0gTDBzIEwxLCBMYXRlbmN5IEwwIDwxdXMsIEwxIDw4dXMNCgkJ
CUNsb2NrUE0tIFN1cnByaXNlLSBMTEFjdFJlcCsgQndOb3QrDQoJCUxua0N0bDoJQVNQTSBE
aXNhYmxlZDsgUkNCIDY0IGJ5dGVzIERpc2FibGVkLSBSZXRyYWluLSBDb21tQ2xrLQ0KCQkJ
RXh0U3luY2gtIENsb2NrUE0tIEF1dFdpZERpcy0gQldJbnQtIEF1dEJXSW50LQ0KCQlMbmtT
dGE6CVNwZWVkIDIuNUdUL3MsIFdpZHRoIHgxLCBUckVyci0gVHJhaW4tIFNsb3RDbGsrIERM
QWN0aXZlKyBCV01nbXQrIEFCV01nbXQtDQoJCVNsdENhcDoJQXR0bkJ0bi0gUHdyQ3RybC0g
TVJMLSBBdHRuSW5kLSBQd3JJbmQtIEhvdFBsdWctIFN1cnByaXNlLQ0KCQkJU2xvdCAjMiwg
UG93ZXJMaW1pdCA3NS4wMDBXOyBJbnRlcmxvY2stIE5vQ29tcGwrDQoJCVNsdEN0bDoJRW5h
YmxlOiBBdHRuQnRuLSBQd3JGbHQtIE1STC0gUHJlc0RldC0gQ21kQ3BsdC0gSFBJcnEtIExp
bmtDaGctDQoJCQlDb250cm9sOiBBdHRuSW5kIFVua25vd24sIFB3ckluZCBVbmtub3duLCBQ
b3dlci0gSW50ZXJsb2NrLQ0KCQlTbHRTdGE6CVN0YXR1czogQXR0bkJ0bi0gUG93ZXJGbHQt
IE1STC0gQ21kQ3BsdC0gUHJlc0RldCsgSW50ZXJsb2NrLQ0KCQkJQ2hhbmdlZDogTVJMLSBQ
cmVzRGV0KyBMaW5rU3RhdGUrDQoJCVJvb3RDdGw6IEVyckNvcnJlY3RhYmxlLSBFcnJOb24t
RmF0YWwtIEVyckZhdGFsLSBQTUVJbnRFbmEtIENSU1Zpc2libGUtDQoJCVJvb3RDYXA6IENS
U1Zpc2libGUtDQoJCVJvb3RTdGE6IFBNRSBSZXFJRCAwMDAwLCBQTUVTdGF0dXMtIFBNRVBl
bmRpbmctDQoJCURldkNhcDI6IENvbXBsZXRpb24gVGltZW91dDogUmFuZ2UgQUJDRCwgVGlt
ZW91dERpcysgQVJJRndkKw0KCQlEZXZDdGwyOiBDb21wbGV0aW9uIFRpbWVvdXQ6IDY1bXMg
dG8gMjEwbXMsIFRpbWVvdXREaXMtIEFSSUZ3ZC0NCgkJTG5rQ3RsMjogVGFyZ2V0IExpbmsg
U3BlZWQ6IDIuNUdUL3MsIEVudGVyQ29tcGxpYW5jZS0gU3BlZWREaXMtLCBTZWxlY3RhYmxl
IERlLWVtcGhhc2lzOiAtNmRCDQoJCQkgVHJhbnNtaXQgTWFyZ2luOiBOb3JtYWwgT3BlcmF0
aW5nIFJhbmdlLCBFbnRlck1vZGlmaWVkQ29tcGxpYW5jZS0gQ29tcGxpYW5jZVNPUy0NCgkJ
CSBDb21wbGlhbmNlIERlLWVtcGhhc2lzOiAtNmRCDQoJCUxua1N0YTI6IEN1cnJlbnQgRGUt
ZW1waGFzaXMgTGV2ZWw6IC02ZEINCglDYXBhYmlsaXRpZXM6IFthMF0gTVNJOiBFbmFibGUr
IENvdW50PTEvMSBNYXNrYWJsZS0gNjRiaXQtDQoJCUFkZHJlc3M6IGZlZTNmMDBjICBEYXRh
OiA0MTcxDQoJQ2FwYWJpbGl0aWVzOiBbYjBdIFN1YnN5c3RlbTogQVRJIFRlY2hub2xvZ2ll
cyBJbmMgRGV2aWNlIFsxMDAyOjVhMTFdDQoJQ2FwYWJpbGl0aWVzOiBbYjhdIEh5cGVyVHJh
bnNwb3J0OiBNU0kgTWFwcGluZyBFbmFibGUrIEZpeGVkKw0KCUNhcGFiaWxpdGllczogWzEw
MCB2MV0gVmVuZG9yIFNwZWNpZmljIEluZm9ybWF0aW9uOiBJRD0wMDAxIFJldj0xIExlbj0w
MTAgPD8+DQoJQ2FwYWJpbGl0aWVzOiBbMTkwIHYxXSBBY2Nlc3MgQ29udHJvbCBTZXJ2aWNl
cw0KCQlBQ1NDYXA6CVNyY1ZhbGlkKyBUcmFuc0JsaysgUmVxUmVkaXIrIENtcGx0UmVkaXIr
IFVwc3RyZWFtRndkKyBFZ3Jlc3NDdHJsLSBEaXJlY3RUcmFucysNCgkJQUNTQ3RsOglTcmNW
YWxpZCsgVHJhbnNCbGstIFJlcVJlZGlyKyBDbXBsdFJlZGlyKyBVcHN0cmVhbUZ3ZCsgRWdy
ZXNzQ3RybC0gRGlyZWN0VHJhbnMtDQoJS2VybmVsIGRyaXZlciBpbiB1c2U6IHBjaWVwb3J0
DQoNCjAwOjBiLjAgUENJIGJyaWRnZSBbMDYwNF06IEFUSSBUZWNobm9sb2dpZXMgSW5jIFJE
ODkwIFBDSSB0byBQQ0kgYnJpZGdlIChOQi1TQiBsaW5rKSBbMTAwMjo1YTFmXSAocHJvZy1p
ZiAwMCBbTm9ybWFsIGRlY29kZV0pDQoJQ29udHJvbDogSS9PKyBNZW0rIEJ1c01hc3Rlcisg
U3BlY0N5Y2xlLSBNZW1XSU5WLSBWR0FTbm9vcC0gUGFyRXJyLSBTdGVwcGluZy0gU0VSUisg
RmFzdEIyQi0gRGlzSU5UeCsNCglTdGF0dXM6IENhcCsgNjZNSHotIFVERi0gRmFzdEIyQi0g
UGFyRXJyLSBERVZTRUw9ZmFzdCA+VEFib3J0LSA8VEFib3J0LSA8TUFib3J0LSA+U0VSUi0g
PFBFUlItIElOVHgtDQoJTGF0ZW5jeTogMCwgQ2FjaGUgTGluZSBTaXplOiA2NCBieXRlcw0K
CUJ1czogcHJpbWFyeT0wMCwgc2Vjb25kYXJ5PTA2LCBzdWJvcmRpbmF0ZT0wNiwgc2VjLWxh
dGVuY3k9MA0KCUkvTyBiZWhpbmQgYnJpZGdlOiAwMDAwYjAwMC0wMDAwYmZmZg0KCU1lbW9y
eSBiZWhpbmQgYnJpZGdlOiBmOTkwMDAwMC1mOTlmZmZmZg0KCVByZWZldGNoYWJsZSBtZW1v
cnkgYmVoaW5kIGJyaWRnZTogMDAwMDAwMDBiMDAwMDAwMC0wMDAwMDAwMGJmZmZmZmZmDQoJ
U2Vjb25kYXJ5IHN0YXR1czogNjZNSHotIEZhc3RCMkItIFBhckVyci0gREVWU0VMPWZhc3Qg
PlRBYm9ydC0gPFRBYm9ydC0gPE1BYm9ydC0gPFNFUlItIDxQRVJSLQ0KCUJyaWRnZUN0bDog
UGFyaXR5KyBTRVJSKyBOb0lTQSsgVkdBLSBNQWJvcnQtID5SZXNldC0gRmFzdEIyQi0NCgkJ
UHJpRGlzY1Rtci0gU2VjRGlzY1Rtci0gRGlzY1RtclN0YXQtIERpc2NUbXJTRVJSRW4tDQoJ
Q2FwYWJpbGl0aWVzOiBbNTBdIFBvd2VyIE1hbmFnZW1lbnQgdmVyc2lvbiAzDQoJCUZsYWdz
OiBQTUVDbGstIERTSS0gRDEtIEQyLSBBdXhDdXJyZW50PTBtQSBQTUUoRDArLEQxLSxEMi0s
RDNob3QrLEQzY29sZCspDQoJCVN0YXR1czogRDAgTm9Tb2Z0UnN0LSBQTUUtRW5hYmxlLSBE
U2VsPTAgRFNjYWxlPTAgUE1FLQ0KCUNhcGFiaWxpdGllczogWzU4XSBFeHByZXNzICh2Mikg
Um9vdCBQb3J0IChTbG90KyksIE1TSSAwMA0KCQlEZXZDYXA6CU1heFBheWxvYWQgMTI4IGJ5
dGVzLCBQaGFudEZ1bmMgMCwgTGF0ZW5jeSBMMHMgPDY0bnMsIEwxIDwxdXMNCgkJCUV4dFRh
ZysgUkJFKyBGTFJlc2V0LQ0KCQlEZXZDdGw6CVJlcG9ydCBlcnJvcnM6IENvcnJlY3RhYmxl
LSBOb24tRmF0YWwtIEZhdGFsLSBVbnN1cHBvcnRlZC0NCgkJCVJseGRPcmQrIEV4dFRhZy0g
UGhhbnRGdW5jLSBBdXhQd3ItIE5vU25vb3ArDQoJCQlNYXhQYXlsb2FkIDEyOCBieXRlcywg
TWF4UmVhZFJlcSAxMjggYnl0ZXMNCgkJRGV2U3RhOglDb3JyRXJyLSBVbmNvcnJFcnItIEZh
dGFsRXJyLSBVbnN1cHBSZXEtIEF1eFB3ci0gVHJhbnNQZW5kLQ0KCQlMbmtDYXA6CVBvcnQg
IzAsIFNwZWVkIDVHVC9zLCBXaWR0aCB4OCwgQVNQTSBMMHMgTDEsIExhdGVuY3kgTDAgPDF1
cywgTDEgPDh1cw0KCQkJQ2xvY2tQTS0gU3VycHJpc2UtIExMQWN0UmVwKyBCd05vdCsNCgkJ
TG5rQ3RsOglBU1BNIERpc2FibGVkOyBSQ0IgNjQgYnl0ZXMgRGlzYWJsZWQtIFJldHJhaW4t
IENvbW1DbGsrDQoJCQlFeHRTeW5jaC0gQ2xvY2tQTS0gQXV0V2lkRGlzLSBCV0ludC0gQXV0
QldJbnQtDQoJCUxua1N0YToJU3BlZWQgMi41R1QvcywgV2lkdGggeDEsIFRyRXJyLSBUcmFp
bi0gU2xvdENsaysgRExBY3RpdmUrIEJXTWdtdCsgQUJXTWdtdC0NCgkJU2x0Q2FwOglBdHRu
QnRuLSBQd3JDdHJsLSBNUkwtIEF0dG5JbmQtIFB3ckluZC0gSG90UGx1Zy0gU3VycHJpc2Ut
DQoJCQlTbG90ICM1LCBQb3dlckxpbWl0IDMxLjAwMFc7IEludGVybG9jay0gTm9Db21wbCsN
CgkJU2x0Q3RsOglFbmFibGU6IEF0dG5CdG4tIFB3ckZsdC0gTVJMLSBQcmVzRGV0LSBDbWRD
cGx0LSBIUElycS0gTGlua0NoZy0NCgkJCUNvbnRyb2w6IEF0dG5JbmQgVW5rbm93biwgUHdy
SW5kIFVua25vd24sIFBvd2VyLSBJbnRlcmxvY2stDQoJCVNsdFN0YToJU3RhdHVzOiBBdHRu
QnRuLSBQb3dlckZsdC0gTVJMLSBDbWRDcGx0LSBQcmVzRGV0KyBJbnRlcmxvY2stDQoJCQlD
aGFuZ2VkOiBNUkwtIFByZXNEZXQrIExpbmtTdGF0ZSsNCgkJUm9vdEN0bDogRXJyQ29ycmVj
dGFibGUtIEVyck5vbi1GYXRhbC0gRXJyRmF0YWwtIFBNRUludEVuYS0gQ1JTVmlzaWJsZS0N
CgkJUm9vdENhcDogQ1JTVmlzaWJsZS0NCgkJUm9vdFN0YTogUE1FIFJlcUlEIDAwMDAsIFBN
RVN0YXR1cy0gUE1FUGVuZGluZy0NCgkJRGV2Q2FwMjogQ29tcGxldGlvbiBUaW1lb3V0OiBS
YW5nZSBBQkNELCBUaW1lb3V0RGlzKyBBUklGd2QrDQoJCURldkN0bDI6IENvbXBsZXRpb24g
VGltZW91dDogNjVtcyB0byAyMTBtcywgVGltZW91dERpcy0gQVJJRndkLQ0KCQlMbmtDdGwy
OiBUYXJnZXQgTGluayBTcGVlZDogNUdUL3MsIEVudGVyQ29tcGxpYW5jZS0gU3BlZWREaXMt
LCBTZWxlY3RhYmxlIERlLWVtcGhhc2lzOiAtMy41ZEINCgkJCSBUcmFuc21pdCBNYXJnaW46
IE5vcm1hbCBPcGVyYXRpbmcgUmFuZ2UsIEVudGVyTW9kaWZpZWRDb21wbGlhbmNlLSBDb21w
bGlhbmNlU09TLQ0KCQkJIENvbXBsaWFuY2UgRGUtZW1waGFzaXM6IC02ZEINCgkJTG5rU3Rh
MjogQ3VycmVudCBEZS1lbXBoYXNpcyBMZXZlbDogLTMuNWRCDQoJQ2FwYWJpbGl0aWVzOiBb
YTBdIE1TSTogRW5hYmxlKyBDb3VudD0xLzEgTWFza2FibGUtIDY0Yml0LQ0KCQlBZGRyZXNz
OiBmZWUzZjAwYyAgRGF0YTogNDE3OQ0KCUNhcGFiaWxpdGllczogW2IwXSBTdWJzeXN0ZW06
IEFUSSBUZWNobm9sb2dpZXMgSW5jIERldmljZSBbMTAwMjo1YTExXQ0KCUNhcGFiaWxpdGll
czogW2I4XSBIeXBlclRyYW5zcG9ydDogTVNJIE1hcHBpbmcgRW5hYmxlKyBGaXhlZCsNCglD
YXBhYmlsaXRpZXM6IFsxMDAgdjFdIFZlbmRvciBTcGVjaWZpYyBJbmZvcm1hdGlvbjogSUQ9
MDAwMSBSZXY9MSBMZW49MDEwIDw/Pg0KCUNhcGFiaWxpdGllczogWzE5MCB2MV0gQWNjZXNz
IENvbnRyb2wgU2VydmljZXMNCgkJQUNTQ2FwOglTcmNWYWxpZCsgVHJhbnNCbGsrIFJlcVJl
ZGlyKyBDbXBsdFJlZGlyKyBVcHN0cmVhbUZ3ZCsgRWdyZXNzQ3RybC0gRGlyZWN0VHJhbnMr
DQoJCUFDU0N0bDoJU3JjVmFsaWQrIFRyYW5zQmxrLSBSZXFSZWRpcisgQ21wbHRSZWRpcisg
VXBzdHJlYW1Gd2QrIEVncmVzc0N0cmwtIERpcmVjdFRyYW5zLQ0KCUtlcm5lbCBkcml2ZXIg
aW4gdXNlOiBwY2llcG9ydA0KDQowMDowYy4wIFBDSSBicmlkZ2UgWzA2MDRdOiBBVEkgVGVj
aG5vbG9naWVzIEluYyBEZXZpY2UgWzEwMDI6NWEyMF0gKHByb2ctaWYgMDAgW05vcm1hbCBk
ZWNvZGVdKQ0KCUNvbnRyb2w6IEkvTy0gTWVtKyBCdXNNYXN0ZXIrIFNwZWNDeWNsZS0gTWVt
V0lOVi0gVkdBU25vb3AtIFBhckVyci0gU3RlcHBpbmctIFNFUlIrIEZhc3RCMkItIERpc0lO
VHgrDQoJU3RhdHVzOiBDYXArIDY2TUh6LSBVREYtIEZhc3RCMkItIFBhckVyci0gREVWU0VM
PWZhc3QgPlRBYm9ydC0gPFRBYm9ydC0gPE1BYm9ydC0gPlNFUlItIDxQRVJSLSBJTlR4LQ0K
CUxhdGVuY3k6IDAsIENhY2hlIExpbmUgU2l6ZTogNjQgYnl0ZXMNCglCdXM6IHByaW1hcnk9
MDAsIHNlY29uZGFyeT0wNSwgc3Vib3JkaW5hdGU9MDUsIHNlYy1sYXRlbmN5PTANCglJL08g
YmVoaW5kIGJyaWRnZTogMDAwMGYwMDAtMDAwMDBmZmYNCglNZW1vcnkgYmVoaW5kIGJyaWRn
ZTogZjk2MDAwMDAtZjk3ZmZmZmYNCglQcmVmZXRjaGFibGUgbWVtb3J5IGJlaGluZCBicmlk
Z2U6IDAwMDAwMDAwZmZmMDAwMDAtMDAwMDAwMDAwMDBmZmZmZg0KCVNlY29uZGFyeSBzdGF0
dXM6IDY2TUh6LSBGYXN0QjJCLSBQYXJFcnItIERFVlNFTD1mYXN0ID5UQWJvcnQtIDxUQWJv
cnQtIDxNQWJvcnQrIDxTRVJSLSA8UEVSUi0NCglCcmlkZ2VDdGw6IFBhcml0eSsgU0VSUisg
Tm9JU0ErIFZHQS0gTUFib3J0LSA+UmVzZXQtIEZhc3RCMkItDQoJCVByaURpc2NUbXItIFNl
Y0Rpc2NUbXItIERpc2NUbXJTdGF0LSBEaXNjVG1yU0VSUkVuLQ0KCUNhcGFiaWxpdGllczog
WzUwXSBQb3dlciBNYW5hZ2VtZW50IHZlcnNpb24gMw0KCQlGbGFnczogUE1FQ2xrLSBEU0kt
IEQxLSBEMi0gQXV4Q3VycmVudD0wbUEgUE1FKEQwKyxEMS0sRDItLEQzaG90KyxEM2NvbGQr
KQ0KCQlTdGF0dXM6IEQwIE5vU29mdFJzdC0gUE1FLUVuYWJsZS0gRFNlbD0wIERTY2FsZT0w
IFBNRS0NCglDYXBhYmlsaXRpZXM6IFs1OF0gRXhwcmVzcyAodjIpIFJvb3QgUG9ydCAoU2xv
dCspLCBNU0kgMDANCgkJRGV2Q2FwOglNYXhQYXlsb2FkIDEyOCBieXRlcywgUGhhbnRGdW5j
IDAsIExhdGVuY3kgTDBzIDw2NG5zLCBMMSA8MXVzDQoJCQlFeHRUYWcrIFJCRSsgRkxSZXNl
dC0NCgkJRGV2Q3RsOglSZXBvcnQgZXJyb3JzOiBDb3JyZWN0YWJsZS0gTm9uLUZhdGFsLSBG
YXRhbC0gVW5zdXBwb3J0ZWQtDQoJCQlSbHhkT3JkKyBFeHRUYWctIFBoYW50RnVuYy0gQXV4
UHdyLSBOb1Nub29wKw0KCQkJTWF4UGF5bG9hZCAxMjggYnl0ZXMsIE1heFJlYWRSZXEgMTI4
IGJ5dGVzDQoJCURldlN0YToJQ29yckVyci0gVW5jb3JyRXJyLSBGYXRhbEVyci0gVW5zdXBw
UmVxLSBBdXhQd3ItIFRyYW5zUGVuZC0NCgkJTG5rQ2FwOglQb3J0ICMxLCBTcGVlZCA1R1Qv
cywgV2lkdGggeDgsIEFTUE0gTDBzIEwxLCBMYXRlbmN5IEwwIDwxdXMsIEwxIDw4dXMNCgkJ
CUNsb2NrUE0tIFN1cnByaXNlLSBMTEFjdFJlcCsgQndOb3QrDQoJCUxua0N0bDoJQVNQTSBE
aXNhYmxlZDsgUkNCIDY0IGJ5dGVzIERpc2FibGVkLSBSZXRyYWluLSBDb21tQ2xrLQ0KCQkJ
RXh0U3luY2gtIENsb2NrUE0tIEF1dFdpZERpcy0gQldJbnQtIEF1dEJXSW50LQ0KCQlMbmtT
dGE6CVNwZWVkIDIuNUdUL3MsIFdpZHRoIHgxLCBUckVyci0gVHJhaW4tIFNsb3RDbGsrIERM
QWN0aXZlKyBCV01nbXQrIEFCV01nbXQtDQoJCVNsdENhcDoJQXR0bkJ0bi0gUHdyQ3RybC0g
TVJMLSBBdHRuSW5kLSBQd3JJbmQtIEhvdFBsdWctIFN1cnByaXNlLQ0KCQkJU2xvdCAjNiwg
UG93ZXJMaW1pdCAxNC4wMDBXOyBJbnRlcmxvY2stIE5vQ29tcGwrDQoJCVNsdEN0bDoJRW5h
YmxlOiBBdHRuQnRuLSBQd3JGbHQtIE1STC0gUHJlc0RldC0gQ21kQ3BsdC0gSFBJcnEtIExp
bmtDaGctDQoJCQlDb250cm9sOiBBdHRuSW5kIFVua25vd24sIFB3ckluZCBVbmtub3duLCBQ
b3dlci0gSW50ZXJsb2NrLQ0KCQlTbHRTdGE6CVN0YXR1czogQXR0bkJ0bi0gUG93ZXJGbHQt
IE1STC0gQ21kQ3BsdC0gUHJlc0RldCsgSW50ZXJsb2NrLQ0KCQkJQ2hhbmdlZDogTVJMLSBQ
cmVzRGV0KyBMaW5rU3RhdGUrDQoJCVJvb3RDdGw6IEVyckNvcnJlY3RhYmxlLSBFcnJOb24t
RmF0YWwtIEVyckZhdGFsLSBQTUVJbnRFbmEtIENSU1Zpc2libGUtDQoJCVJvb3RDYXA6IENS
U1Zpc2libGUtDQoJCVJvb3RTdGE6IFBNRSBSZXFJRCAwMDAwLCBQTUVTdGF0dXMtIFBNRVBl
bmRpbmctDQoJCURldkNhcDI6IENvbXBsZXRpb24gVGltZW91dDogUmFuZ2UgQUJDRCwgVGlt
ZW91dERpcysgQVJJRndkKw0KCQlEZXZDdGwyOiBDb21wbGV0aW9uIFRpbWVvdXQ6IDY1bXMg
dG8gMjEwbXMsIFRpbWVvdXREaXMtIEFSSUZ3ZC0NCgkJTG5rQ3RsMjogVGFyZ2V0IExpbmsg
U3BlZWQ6IDVHVC9zLCBFbnRlckNvbXBsaWFuY2UtIFNwZWVkRGlzLSwgU2VsZWN0YWJsZSBE
ZS1lbXBoYXNpczogLTMuNWRCDQoJCQkgVHJhbnNtaXQgTWFyZ2luOiBOb3JtYWwgT3BlcmF0
aW5nIFJhbmdlLCBFbnRlck1vZGlmaWVkQ29tcGxpYW5jZS0gQ29tcGxpYW5jZVNPUy0NCgkJ
CSBDb21wbGlhbmNlIERlLWVtcGhhc2lzOiAtNmRCDQoJCUxua1N0YTI6IEN1cnJlbnQgRGUt
ZW1waGFzaXMgTGV2ZWw6IC0zLjVkQg0KCUNhcGFiaWxpdGllczogW2EwXSBNU0k6IEVuYWJs
ZSsgQ291bnQ9MS8xIE1hc2thYmxlLSA2NGJpdC0NCgkJQWRkcmVzczogZmVlM2YwMGMgIERh
dGE6IDQxODENCglDYXBhYmlsaXRpZXM6IFtiMF0gU3Vic3lzdGVtOiBBVEkgVGVjaG5vbG9n
aWVzIEluYyBEZXZpY2UgWzEwMDI6NWExMV0NCglDYXBhYmlsaXRpZXM6IFtiOF0gSHlwZXJU
cmFuc3BvcnQ6IE1TSSBNYXBwaW5nIEVuYWJsZSsgRml4ZWQrDQoJQ2FwYWJpbGl0aWVzOiBb
MTAwIHYxXSBWZW5kb3IgU3BlY2lmaWMgSW5mb3JtYXRpb246IElEPTAwMDEgUmV2PTEgTGVu
PTAxMCA8Pz4NCglDYXBhYmlsaXRpZXM6IFsxOTAgdjFdIEFjY2VzcyBDb250cm9sIFNlcnZp
Y2VzDQoJCUFDU0NhcDoJU3JjVmFsaWQrIFRyYW5zQmxrKyBSZXFSZWRpcisgQ21wbHRSZWRp
cisgVXBzdHJlYW1Gd2QrIEVncmVzc0N0cmwtIERpcmVjdFRyYW5zKw0KCQlBQ1NDdGw6CVNy
Y1ZhbGlkKyBUcmFuc0Jsay0gUmVxUmVkaXIrIENtcGx0UmVkaXIrIFVwc3RyZWFtRndkKyBF
Z3Jlc3NDdHJsLSBEaXJlY3RUcmFucy0NCglLZXJuZWwgZHJpdmVyIGluIHVzZTogcGNpZXBv
cnQNCg0KMDA6MGQuMCBQQ0kgYnJpZGdlIFswNjA0XTogQVRJIFRlY2hub2xvZ2llcyBJbmMg
UkQ4OTAgUENJIHRvIFBDSSBicmlkZ2UgKGV4dGVybmFsIGdmeDEgcG9ydCBCKSBbMTAwMjo1
YTFlXSAocHJvZy1pZiAwMCBbTm9ybWFsIGRlY29kZV0pDQoJQ29udHJvbDogSS9PLSBNZW0r
IEJ1c01hc3RlcisgU3BlY0N5Y2xlLSBNZW1XSU5WLSBWR0FTbm9vcC0gUGFyRXJyLSBTdGVw
cGluZy0gU0VSUisgRmFzdEIyQi0gRGlzSU5UeCsNCglTdGF0dXM6IENhcCsgNjZNSHotIFVE
Ri0gRmFzdEIyQi0gUGFyRXJyLSBERVZTRUw9ZmFzdCA+VEFib3J0LSA8VEFib3J0LSA8TUFi
b3J0LSA+U0VSUi0gPFBFUlItIElOVHgtDQoJTGF0ZW5jeTogMCwgQ2FjaGUgTGluZSBTaXpl
OiA2NCBieXRlcw0KCUJ1czogcHJpbWFyeT0wMCwgc2Vjb25kYXJ5PTA0LCBzdWJvcmRpbmF0
ZT0wNCwgc2VjLWxhdGVuY3k9MA0KCUkvTyBiZWhpbmQgYnJpZGdlOiAwMDAwZjAwMC0wMDAw
MGZmZg0KCU1lbW9yeSBiZWhpbmQgYnJpZGdlOiBmOTUwMDAwMC1mOTVmZmZmZg0KCVByZWZl
dGNoYWJsZSBtZW1vcnkgYmVoaW5kIGJyaWRnZTogMDAwMDAwMDBmZmYwMDAwMC0wMDAwMDAw
MDAwMGZmZmZmDQoJU2Vjb25kYXJ5IHN0YXR1czogNjZNSHotIEZhc3RCMkItIFBhckVyci0g
REVWU0VMPWZhc3QgPlRBYm9ydC0gPFRBYm9ydC0gPE1BYm9ydC0gPFNFUlItIDxQRVJSLQ0K
CUJyaWRnZUN0bDogUGFyaXR5KyBTRVJSKyBOb0lTQSsgVkdBLSBNQWJvcnQtID5SZXNldC0g
RmFzdEIyQi0NCgkJUHJpRGlzY1Rtci0gU2VjRGlzY1Rtci0gRGlzY1RtclN0YXQtIERpc2NU
bXJTRVJSRW4tDQoJQ2FwYWJpbGl0aWVzOiBbNTBdIFBvd2VyIE1hbmFnZW1lbnQgdmVyc2lv
biAzDQoJCUZsYWdzOiBQTUVDbGstIERTSS0gRDEtIEQyLSBBdXhDdXJyZW50PTBtQSBQTUUo
RDArLEQxLSxEMi0sRDNob3QrLEQzY29sZCspDQoJCVN0YXR1czogRDAgTm9Tb2Z0UnN0LSBQ
TUUtRW5hYmxlLSBEU2VsPTAgRFNjYWxlPTAgUE1FLQ0KCUNhcGFiaWxpdGllczogWzU4XSBF
eHByZXNzICh2MikgUm9vdCBQb3J0IChTbG90KyksIE1TSSAwMA0KCQlEZXZDYXA6CU1heFBh
eWxvYWQgMTI4IGJ5dGVzLCBQaGFudEZ1bmMgMCwgTGF0ZW5jeSBMMHMgPDY0bnMsIEwxIDwx
dXMNCgkJCUV4dFRhZysgUkJFKyBGTFJlc2V0LQ0KCQlEZXZDdGw6CVJlcG9ydCBlcnJvcnM6
IENvcnJlY3RhYmxlLSBOb24tRmF0YWwtIEZhdGFsLSBVbnN1cHBvcnRlZC0NCgkJCVJseGRP
cmQrIEV4dFRhZy0gUGhhbnRGdW5jLSBBdXhQd3ItIE5vU25vb3ArDQoJCQlNYXhQYXlsb2Fk
IDEyOCBieXRlcywgTWF4UmVhZFJlcSAxMjggYnl0ZXMNCgkJRGV2U3RhOglDb3JyRXJyLSBV
bmNvcnJFcnItIEZhdGFsRXJyLSBVbnN1cHBSZXEtIEF1eFB3ci0gVHJhbnNQZW5kLQ0KCQlM
bmtDYXA6CVBvcnQgIzAsIFNwZWVkIDVHVC9zLCBXaWR0aCB4NCwgQVNQTSBMMHMgTDEsIExh
dGVuY3kgTDAgPDF1cywgTDEgPDh1cw0KCQkJQ2xvY2tQTS0gU3VycHJpc2UtIExMQWN0UmVw
KyBCd05vdCsNCgkJTG5rQ3RsOglBU1BNIERpc2FibGVkOyBSQ0IgNjQgYnl0ZXMgRGlzYWJs
ZWQtIFJldHJhaW4tIENvbW1DbGstDQoJCQlFeHRTeW5jaC0gQ2xvY2tQTS0gQXV0V2lkRGlz
LSBCV0ludC0gQXV0QldJbnQtDQoJCUxua1N0YToJU3BlZWQgMi41R1QvcywgV2lkdGggeDEs
IFRyRXJyLSBUcmFpbi0gU2xvdENsaysgRExBY3RpdmUrIEJXTWdtdCsgQUJXTWdtdC0NCgkJ
U2x0Q2FwOglBdHRuQnRuLSBQd3JDdHJsLSBNUkwtIEF0dG5JbmQtIFB3ckluZC0gSG90UGx1
Zy0gU3VycHJpc2UtDQoJCQlTbG90ICM0LCBQb3dlckxpbWl0IDc1LjAwMFc7IEludGVybG9j
ay0gTm9Db21wbCsNCgkJU2x0Q3RsOglFbmFibGU6IEF0dG5CdG4tIFB3ckZsdC0gTVJMLSBQ
cmVzRGV0LSBDbWRDcGx0LSBIUElycS0gTGlua0NoZy0NCgkJCUNvbnRyb2w6IEF0dG5JbmQg
VW5rbm93biwgUHdySW5kIFVua25vd24sIFBvd2VyLSBJbnRlcmxvY2stDQoJCVNsdFN0YToJ
U3RhdHVzOiBBdHRuQnRuLSBQb3dlckZsdC0gTVJMLSBDbWRDcGx0LSBQcmVzRGV0KyBJbnRl
cmxvY2stDQoJCQlDaGFuZ2VkOiBNUkwtIFByZXNEZXQrIExpbmtTdGF0ZSsNCgkJUm9vdEN0
bDogRXJyQ29ycmVjdGFibGUtIEVyck5vbi1GYXRhbC0gRXJyRmF0YWwtIFBNRUludEVuYS0g
Q1JTVmlzaWJsZS0NCgkJUm9vdENhcDogQ1JTVmlzaWJsZS0NCgkJUm9vdFN0YTogUE1FIFJl
cUlEIDAwMDAsIFBNRVN0YXR1cy0gUE1FUGVuZGluZy0NCgkJRGV2Q2FwMjogQ29tcGxldGlv
biBUaW1lb3V0OiBSYW5nZSBBQkNELCBUaW1lb3V0RGlzKyBBUklGd2QrDQoJCURldkN0bDI6
IENvbXBsZXRpb24gVGltZW91dDogNjVtcyB0byAyMTBtcywgVGltZW91dERpcy0gQVJJRndk
LQ0KCQlMbmtDdGwyOiBUYXJnZXQgTGluayBTcGVlZDogNUdUL3MsIEVudGVyQ29tcGxpYW5j
ZS0gU3BlZWREaXMtLCBTZWxlY3RhYmxlIERlLWVtcGhhc2lzOiAtMy41ZEINCgkJCSBUcmFu
c21pdCBNYXJnaW46IE5vcm1hbCBPcGVyYXRpbmcgUmFuZ2UsIEVudGVyTW9kaWZpZWRDb21w
bGlhbmNlLSBDb21wbGlhbmNlU09TLQ0KCQkJIENvbXBsaWFuY2UgRGUtZW1waGFzaXM6IC02
ZEINCgkJTG5rU3RhMjogQ3VycmVudCBEZS1lbXBoYXNpcyBMZXZlbDogLTMuNWRCDQoJQ2Fw
YWJpbGl0aWVzOiBbYTBdIE1TSTogRW5hYmxlKyBDb3VudD0xLzEgTWFza2FibGUtIDY0Yml0
LQ0KCQlBZGRyZXNzOiBmZWUzZjAwYyAgRGF0YTogNDE4OQ0KCUNhcGFiaWxpdGllczogW2Iw
XSBTdWJzeXN0ZW06IEFUSSBUZWNobm9sb2dpZXMgSW5jIERldmljZSBbMTAwMjo1YTExXQ0K
CUNhcGFiaWxpdGllczogW2I4XSBIeXBlclRyYW5zcG9ydDogTVNJIE1hcHBpbmcgRW5hYmxl
KyBGaXhlZCsNCglDYXBhYmlsaXRpZXM6IFsxMDAgdjFdIFZlbmRvciBTcGVjaWZpYyBJbmZv
cm1hdGlvbjogSUQ9MDAwMSBSZXY9MSBMZW49MDEwIDw/Pg0KCUNhcGFiaWxpdGllczogWzE5
MCB2MV0gQWNjZXNzIENvbnRyb2wgU2VydmljZXMNCgkJQUNTQ2FwOglTcmNWYWxpZCsgVHJh
bnNCbGsrIFJlcVJlZGlyKyBDbXBsdFJlZGlyKyBVcHN0cmVhbUZ3ZCsgRWdyZXNzQ3RybC0g
RGlyZWN0VHJhbnMrDQoJCUFDU0N0bDoJU3JjVmFsaWQrIFRyYW5zQmxrLSBSZXFSZWRpcisg
Q21wbHRSZWRpcisgVXBzdHJlYW1Gd2QrIEVncmVzc0N0cmwtIERpcmVjdFRyYW5zLQ0KCUtl
cm5lbCBkcml2ZXIgaW4gdXNlOiBwY2llcG9ydA0KDQowMDoxMS4wIFNBVEEgY29udHJvbGxl
ciBbMDEwNl06IEFUSSBUZWNobm9sb2dpZXMgSW5jIFNCN3gwL1NCOHgwL1NCOXgwIFNBVEEg
Q29udHJvbGxlciBbQUhDSSBtb2RlXSBbMTAwMjo0MzkxXSAocmV2IDQwKSAocHJvZy1pZiAw
MSBbQUhDSSAxLjBdKQ0KCVN1YnN5c3RlbTogTWljcm8tU3RhciBJbnRlcm5hdGlvbmFsIENv
LiwgTHRkLiBEZXZpY2UgWzE0NjI6NzY0MF0NCglDb250cm9sOiBJL08rIE1lbSsgQnVzTWFz
dGVyKyBTcGVjQ3ljbGUtIE1lbVdJTlYtIFZHQVNub29wLSBQYXJFcnItIFN0ZXBwaW5nLSBT
RVJSKyBGYXN0QjJCLSBEaXNJTlR4Kw0KCVN0YXR1czogQ2FwKyA2Nk1IeisgVURGLSBGYXN0
QjJCLSBQYXJFcnItIERFVlNFTD1tZWRpdW0gPlRBYm9ydC0gPFRBYm9ydC0gPE1BYm9ydC0g
PlNFUlItIDxQRVJSLSBJTlR4LQ0KCUxhdGVuY3k6IDY0LCBDYWNoZSBMaW5lIFNpemU6IDY0
IGJ5dGVzDQoJSW50ZXJydXB0OiBwaW4gQSByb3V0ZWQgdG8gSVJRIDEyMA0KCVJlZ2lvbiAw
OiBJL08gcG9ydHMgYXQgNzAwMCBbc2l6ZT04XQ0KCVJlZ2lvbiAxOiBJL08gcG9ydHMgYXQg
NjAwMCBbc2l6ZT00XQ0KCVJlZ2lvbiAyOiBJL08gcG9ydHMgYXQgNTAwMCBbc2l6ZT04XQ0K
CVJlZ2lvbiAzOiBJL08gcG9ydHMgYXQgMzAwMCBbc2l6ZT00XQ0KCVJlZ2lvbiA0OiBJL08g
cG9ydHMgYXQgMjAwMCBbc2l6ZT0xNl0NCglSZWdpb24gNTogTWVtb3J5IGF0IGY5M2ZmMDAw
ICgzMi1iaXQsIG5vbi1wcmVmZXRjaGFibGUpIFtzaXplPTFLXQ0KCUNhcGFiaWxpdGllczog
WzUwXSBNU0k6IEVuYWJsZSsgQ291bnQ9MS84IE1hc2thYmxlLSA2NGJpdCsNCgkJQWRkcmVz
czogMDAwMDAwMDBmZWUwMTAwYyAgRGF0YTogNDFiOQ0KCUNhcGFiaWxpdGllczogWzcwXSBT
QVRBIEhCQSB2MS4wIEluQ2ZnU3BhY2UNCglDYXBhYmlsaXRpZXM6IFthNF0gUENJIEFkdmFu
Y2VkIEZlYXR1cmVzDQoJCUFGQ2FwOiBUUCsgRkxSKw0KCQlBRkN0cmw6IEZMUi0NCgkJQUZT
dGF0dXM6IFRQKw0KCUtlcm5lbCBkcml2ZXIgaW4gdXNlOiBhaGNpDQoNCjAwOjEyLjAgVVNC
IGNvbnRyb2xsZXIgWzBjMDNdOiBBVEkgVGVjaG5vbG9naWVzIEluYyBTQjd4MC9TQjh4MC9T
Qjl4MCBVU0IgT0hDSTAgQ29udHJvbGxlciBbMTAwMjo0Mzk3XSAocHJvZy1pZiAxMCBbT0hD
SV0pDQoJU3Vic3lzdGVtOiBNaWNyby1TdGFyIEludGVybmF0aW9uYWwgQ28uLCBMdGQuIERl
dmljZSBbMTQ2Mjo3NjQwXQ0KCUNvbnRyb2w6IEkvTysgTWVtKyBCdXNNYXN0ZXIrIFNwZWND
eWNsZS0gTWVtV0lOVisgVkdBU25vb3AtIFBhckVyci0gU3RlcHBpbmctIFNFUlIrIEZhc3RC
MkItIERpc0lOVHgtDQoJU3RhdHVzOiBDYXAtIDY2TUh6KyBVREYtIEZhc3RCMkIrIFBhckVy
ci0gREVWU0VMPW1lZGl1bSA+VEFib3J0LSA8VEFib3J0LSA8TUFib3J0LSA+U0VSUi0gPFBF
UlItIElOVHgtDQoJTGF0ZW5jeTogNjQsIENhY2hlIExpbmUgU2l6ZTogNjQgYnl0ZXMNCglJ
bnRlcnJ1cHQ6IHBpbiBBIHJvdXRlZCB0byBJUlEgMTgNCglSZWdpb24gMDogTWVtb3J5IGF0
IGY5M2ZiMDAwICgzMi1iaXQsIG5vbi1wcmVmZXRjaGFibGUpIFtzaXplPTRLXQ0KCUtlcm5l
bCBkcml2ZXIgaW4gdXNlOiBvaGNpX2hjZA0KDQowMDoxMi4yIFVTQiBjb250cm9sbGVyIFsw
YzAzXTogQVRJIFRlY2hub2xvZ2llcyBJbmMgU0I3eDAvU0I4eDAvU0I5eDAgVVNCIEVIQ0kg
Q29udHJvbGxlciBbMTAwMjo0Mzk2XSAocHJvZy1pZiAyMCBbRUhDSV0pDQoJU3Vic3lzdGVt
OiBNaWNyby1TdGFyIEludGVybmF0aW9uYWwgQ28uLCBMdGQuIERldmljZSBbMTQ2Mjo3NjQw
XQ0KCUNvbnRyb2w6IEkvTy0gTWVtKyBCdXNNYXN0ZXIrIFNwZWNDeWNsZS0gTWVtV0lOVisg
VkdBU25vb3AtIFBhckVyci0gU3RlcHBpbmctIFNFUlIrIEZhc3RCMkItIERpc0lOVHgtDQoJ
U3RhdHVzOiBDYXArIDY2TUh6KyBVREYtIEZhc3RCMkIrIFBhckVyci0gREVWU0VMPW1lZGl1
bSA+VEFib3J0LSA8VEFib3J0LSA8TUFib3J0LSA+U0VSUi0gPFBFUlItIElOVHgtDQoJTGF0
ZW5jeTogNjQsIENhY2hlIExpbmUgU2l6ZTogNjQgYnl0ZXMNCglJbnRlcnJ1cHQ6IHBpbiBC
IHJvdXRlZCB0byBJUlEgMTcNCglSZWdpb24gMDogTWVtb3J5IGF0IGY5M2ZmNDAwICgzMi1i
aXQsIG5vbi1wcmVmZXRjaGFibGUpIFtzaXplPTI1Nl0NCglDYXBhYmlsaXRpZXM6IFtjMF0g
UG93ZXIgTWFuYWdlbWVudCB2ZXJzaW9uIDINCgkJRmxhZ3M6IFBNRUNsay0gRFNJLSBEMSsg
RDIrIEF1eEN1cnJlbnQ9MG1BIFBNRShEMCssRDErLEQyKyxEM2hvdCssRDNjb2xkLSkNCgkJ
U3RhdHVzOiBEMCBOb1NvZnRSc3QtIFBNRS1FbmFibGUtIERTZWw9MCBEU2NhbGU9MCBQTUUt
DQoJCUJyaWRnZTogUE0tIEIzKw0KCUNhcGFiaWxpdGllczogW2U0XSBEZWJ1ZyBwb3J0OiBC
QVI9MSBvZmZzZXQ9MDBlMA0KCUtlcm5lbCBkcml2ZXIgaW4gdXNlOiBlaGNpX2hjZA0KDQow
MDoxMy4wIFVTQiBjb250cm9sbGVyIFswYzAzXTogQVRJIFRlY2hub2xvZ2llcyBJbmMgU0I3
eDAvU0I4eDAvU0I5eDAgVVNCIE9IQ0kwIENvbnRyb2xsZXIgWzEwMDI6NDM5N10gKHByb2ct
aWYgMTAgW09IQ0ldKQ0KCVN1YnN5c3RlbTogTWljcm8tU3RhciBJbnRlcm5hdGlvbmFsIENv
LiwgTHRkLiBEZXZpY2UgWzE0NjI6NzY0MF0NCglDb250cm9sOiBJL08rIE1lbSsgQnVzTWFz
dGVyKyBTcGVjQ3ljbGUtIE1lbVdJTlYrIFZHQVNub29wLSBQYXJFcnItIFN0ZXBwaW5nLSBT
RVJSKyBGYXN0QjJCLSBEaXNJTlR4LQ0KCVN0YXR1czogQ2FwLSA2Nk1IeisgVURGLSBGYXN0
QjJCKyBQYXJFcnItIERFVlNFTD1tZWRpdW0gPlRBYm9ydC0gPFRBYm9ydC0gPE1BYm9ydC0g
PlNFUlItIDxQRVJSLSBJTlR4LQ0KCUxhdGVuY3k6IDY0LCBDYWNoZSBMaW5lIFNpemU6IDY0
IGJ5dGVzDQoJSW50ZXJydXB0OiBwaW4gQSByb3V0ZWQgdG8gSVJRIDE4DQoJUmVnaW9uIDA6
IE1lbW9yeSBhdCBmOTNmYzAwMCAoMzItYml0LCBub24tcHJlZmV0Y2hhYmxlKSBbc2l6ZT00
S10NCglLZXJuZWwgZHJpdmVyIGluIHVzZTogb2hjaV9oY2QNCg0KMDA6MTMuMiBVU0IgY29u
dHJvbGxlciBbMGMwM106IEFUSSBUZWNobm9sb2dpZXMgSW5jIFNCN3gwL1NCOHgwL1NCOXgw
IFVTQiBFSENJIENvbnRyb2xsZXIgWzEwMDI6NDM5Nl0gKHByb2ctaWYgMjAgW0VIQ0ldKQ0K
CVN1YnN5c3RlbTogTWljcm8tU3RhciBJbnRlcm5hdGlvbmFsIENvLiwgTHRkLiBEZXZpY2Ug
WzE0NjI6NzY0MF0NCglDb250cm9sOiBJL08tIE1lbSsgQnVzTWFzdGVyKyBTcGVjQ3ljbGUt
IE1lbVdJTlYrIFZHQVNub29wLSBQYXJFcnItIFN0ZXBwaW5nLSBTRVJSKyBGYXN0QjJCLSBE
aXNJTlR4LQ0KCVN0YXR1czogQ2FwKyA2Nk1IeisgVURGLSBGYXN0QjJCKyBQYXJFcnItIERF
VlNFTD1tZWRpdW0gPlRBYm9ydC0gPFRBYm9ydC0gPE1BYm9ydC0gPlNFUlItIDxQRVJSLSBJ
TlR4LQ0KCUxhdGVuY3k6IDY0LCBDYWNoZSBMaW5lIFNpemU6IDY0IGJ5dGVzDQoJSW50ZXJy
dXB0OiBwaW4gQiByb3V0ZWQgdG8gSVJRIDE3DQoJUmVnaW9uIDA6IE1lbW9yeSBhdCBmOTNm
ZjgwMCAoMzItYml0LCBub24tcHJlZmV0Y2hhYmxlKSBbc2l6ZT0yNTZdDQoJQ2FwYWJpbGl0
aWVzOiBbYzBdIFBvd2VyIE1hbmFnZW1lbnQgdmVyc2lvbiAyDQoJCUZsYWdzOiBQTUVDbGst
IERTSS0gRDErIEQyKyBBdXhDdXJyZW50PTBtQSBQTUUoRDArLEQxKyxEMissRDNob3QrLEQz
Y29sZC0pDQoJCVN0YXR1czogRDAgTm9Tb2Z0UnN0LSBQTUUtRW5hYmxlLSBEU2VsPTAgRFNj
YWxlPTAgUE1FLQ0KCQlCcmlkZ2U6IFBNLSBCMysNCglDYXBhYmlsaXRpZXM6IFtlNF0gRGVi
dWcgcG9ydDogQkFSPTEgb2Zmc2V0PTAwZTANCglLZXJuZWwgZHJpdmVyIGluIHVzZTogZWhj
aV9oY2QNCg0KMDA6MTQuMCBTTUJ1cyBbMGMwNV06IEFUSSBUZWNobm9sb2dpZXMgSW5jIFNC
eDAwIFNNQnVzIENvbnRyb2xsZXIgWzEwMDI6NDM4NV0gKHJldiA0MSkNCglDb250cm9sOiBJ
L08rIE1lbSsgQnVzTWFzdGVyLSBTcGVjQ3ljbGUtIE1lbVdJTlYtIFZHQVNub29wLSBQYXJF
cnItIFN0ZXBwaW5nLSBTRVJSLSBGYXN0QjJCLSBEaXNJTlR4Kw0KCVN0YXR1czogQ2FwLSA2
Nk1IeisgVURGLSBGYXN0QjJCLSBQYXJFcnItIERFVlNFTD1tZWRpdW0gPlRBYm9ydC0gPFRB
Ym9ydC0gPE1BYm9ydC0gPlNFUlItIDxQRVJSLSBJTlR4LQ0KDQowMDoxNC4zIElTQSBicmlk
Z2UgWzA2MDFdOiBBVEkgVGVjaG5vbG9naWVzIEluYyBTQjd4MC9TQjh4MC9TQjl4MCBMUEMg
aG9zdCBjb250cm9sbGVyIFsxMDAyOjQzOWRdIChyZXYgNDApDQoJU3Vic3lzdGVtOiBNaWNy
by1TdGFyIEludGVybmF0aW9uYWwgQ28uLCBMdGQuIERldmljZSBbMTQ2Mjo3NjQwXQ0KCUNv
bnRyb2w6IEkvTysgTWVtKyBCdXNNYXN0ZXIrIFNwZWNDeWNsZSsgTWVtV0lOVi0gVkdBU25v
b3AtIFBhckVyci0gU3RlcHBpbmctIFNFUlItIEZhc3RCMkItIERpc0lOVHgtDQoJU3RhdHVz
OiBDYXAtIDY2TUh6KyBVREYtIEZhc3RCMkItIFBhckVyci0gREVWU0VMPW1lZGl1bSA+VEFi
b3J0LSA8VEFib3J0LSA8TUFib3J0LSA+U0VSUi0gPFBFUlItIElOVHgtDQoJTGF0ZW5jeTog
MA0KDQowMDoxNC40IFBDSSBicmlkZ2UgWzA2MDRdOiBBVEkgVGVjaG5vbG9naWVzIEluYyBT
QngwMCBQQ0kgdG8gUENJIEJyaWRnZSBbMTAwMjo0Mzg0XSAocmV2IDQwKSAocHJvZy1pZiAw
MSBbU3VidHJhY3RpdmUgZGVjb2RlXSkNCglDb250cm9sOiBJL08rIE1lbS0gQnVzTWFzdGVy
KyBTcGVjQ3ljbGUtIE1lbVdJTlYtIFZHQVNub29wLSBQYXJFcnItIFN0ZXBwaW5nLSBTRVJS
KyBGYXN0QjJCLSBEaXNJTlR4LQ0KCVN0YXR1czogQ2FwLSA2Nk1IeisgVURGLSBGYXN0QjJC
KyBQYXJFcnItIERFVlNFTD1tZWRpdW0gPlRBYm9ydC0gPFRBYm9ydC0gPE1BYm9ydC0gPlNF
UlItIDxQRVJSLSBJTlR4LQ0KCUxhdGVuY3k6IDY0DQoJQnVzOiBwcmltYXJ5PTAwLCBzZWNv
bmRhcnk9MDMsIHN1Ym9yZGluYXRlPTAzLCBzZWMtbGF0ZW5jeT02NA0KCUkvTyBiZWhpbmQg
YnJpZGdlOiAwMDAwYTAwMC0wMDAwYWZmZg0KCU1lbW9yeSBiZWhpbmQgYnJpZGdlOiBmZmYw
MDAwMC0wMDBmZmZmZg0KCVByZWZldGNoYWJsZSBtZW1vcnkgYmVoaW5kIGJyaWRnZTogZmZm
MDAwMDAtMDAwZmZmZmYNCglTZWNvbmRhcnkgc3RhdHVzOiA2Nk1Iei0gRmFzdEIyQisgUGFy
RXJyLSBERVZTRUw9bWVkaXVtID5UQWJvcnQtIDxUQWJvcnQtIDxNQWJvcnQrIDxTRVJSLSA8
UEVSUi0NCglCcmlkZ2VDdGw6IFBhcml0eSsgU0VSUisgTm9JU0ErIFZHQS0gTUFib3J0LSA+
UmVzZXQtIEZhc3RCMkItDQoJCVByaURpc2NUbXItIFNlY0Rpc2NUbXItIERpc2NUbXJTdGF0
LSBEaXNjVG1yU0VSUkVuLQ0KDQowMDoxNC41IFVTQiBjb250cm9sbGVyIFswYzAzXTogQVRJ
IFRlY2hub2xvZ2llcyBJbmMgU0I3eDAvU0I4eDAvU0I5eDAgVVNCIE9IQ0kyIENvbnRyb2xs
ZXIgWzEwMDI6NDM5OV0gKHByb2ctaWYgMTAgW09IQ0ldKQ0KCVN1YnN5c3RlbTogTWljcm8t
U3RhciBJbnRlcm5hdGlvbmFsIENvLiwgTHRkLiBEZXZpY2UgWzE0NjI6NzY0MF0NCglDb250
cm9sOiBJL08rIE1lbSsgQnVzTWFzdGVyKyBTcGVjQ3ljbGUtIE1lbVdJTlYrIFZHQVNub29w
LSBQYXJFcnItIFN0ZXBwaW5nLSBTRVJSKyBGYXN0QjJCLSBEaXNJTlR4LQ0KCVN0YXR1czog
Q2FwLSA2Nk1IeisgVURGLSBGYXN0QjJCKyBQYXJFcnItIERFVlNFTD1tZWRpdW0gPlRBYm9y
dC0gPFRBYm9ydC0gPE1BYm9ydC0gPlNFUlItIDxQRVJSLSBJTlR4LQ0KCUxhdGVuY3k6IDY0
LCBDYWNoZSBMaW5lIFNpemU6IDY0IGJ5dGVzDQoJSW50ZXJydXB0OiBwaW4gQyByb3V0ZWQg
dG8gSVJRIDE4DQoJUmVnaW9uIDA6IE1lbW9yeSBhdCBmOTNmZDAwMCAoMzItYml0LCBub24t
cHJlZmV0Y2hhYmxlKSBbc2l6ZT00S10NCglLZXJuZWwgZHJpdmVyIGluIHVzZTogb2hjaV9o
Y2QNCg0KMDA6MTUuMCBQQ0kgYnJpZGdlIFswNjA0XTogQVRJIFRlY2hub2xvZ2llcyBJbmMg
U0I3MDAvU0I4MDAvU0I5MDAgUENJIHRvIFBDSSBicmlkZ2UgKFBDSUUgcG9ydCAwKSBbMTAw
Mjo0M2EwXSAocHJvZy1pZiAwMCBbTm9ybWFsIGRlY29kZV0pDQoJQ29udHJvbDogSS9PLSBN
ZW0tIEJ1c01hc3RlcisgU3BlY0N5Y2xlLSBNZW1XSU5WLSBWR0FTbm9vcC0gUGFyRXJyLSBT
dGVwcGluZy0gU0VSUisgRmFzdEIyQi0gRGlzSU5UeCsNCglTdGF0dXM6IENhcCsgNjZNSHot
IFVERi0gRmFzdEIyQi0gUGFyRXJyLSBERVZTRUw9ZmFzdCA+VEFib3J0LSA8VEFib3J0LSA8
TUFib3J0LSA+U0VSUi0gPFBFUlItIElOVHgtDQoJTGF0ZW5jeTogMCwgQ2FjaGUgTGluZSBT
aXplOiA2NCBieXRlcw0KCUJ1czogcHJpbWFyeT0wMCwgc2Vjb25kYXJ5PTAyLCBzdWJvcmRp
bmF0ZT0wMiwgc2VjLWxhdGVuY3k9MA0KCUkvTyBiZWhpbmQgYnJpZGdlOiAwMDAwZjAwMC0w
MDAwMGZmZg0KCU1lbW9yeSBiZWhpbmQgYnJpZGdlOiBmZmYwMDAwMC0wMDBmZmZmZg0KCVBy
ZWZldGNoYWJsZSBtZW1vcnkgYmVoaW5kIGJyaWRnZTogMDAwMDAwMDBmZmYwMDAwMC0wMDAw
MDAwMDAwMGZmZmZmDQoJU2Vjb25kYXJ5IHN0YXR1czogNjZNSHotIEZhc3RCMkItIFBhckVy
ci0gREVWU0VMPWZhc3QgPlRBYm9ydC0gPFRBYm9ydC0gPE1BYm9ydC0gPFNFUlItIDxQRVJS
LQ0KCUJyaWRnZUN0bDogUGFyaXR5KyBTRVJSKyBOb0lTQSsgVkdBLSBNQWJvcnQtID5SZXNl
dC0gRmFzdEIyQi0NCgkJUHJpRGlzY1Rtci0gU2VjRGlzY1Rtci0gRGlzY1RtclN0YXQtIERp
c2NUbXJTRVJSRW4tDQoJQ2FwYWJpbGl0aWVzOiBbNTBdIFBvd2VyIE1hbmFnZW1lbnQgdmVy
c2lvbiAzDQoJCUZsYWdzOiBQTUVDbGstIERTSS0gRDErIEQyKyBBdXhDdXJyZW50PTBtQSBQ
TUUoRDAtLEQxLSxEMi0sRDNob3QtLEQzY29sZC0pDQoJCVN0YXR1czogRDAgTm9Tb2Z0UnN0
LSBQTUUtRW5hYmxlLSBEU2VsPTAgRFNjYWxlPTAgUE1FLQ0KCUNhcGFiaWxpdGllczogWzU4
XSBFeHByZXNzICh2MikgUm9vdCBQb3J0IChTbG90KyksIE1TSSAwMA0KCQlEZXZDYXA6CU1h
eFBheWxvYWQgMTI4IGJ5dGVzLCBQaGFudEZ1bmMgMCwgTGF0ZW5jeSBMMHMgPDY0bnMsIEwx
IDwxdXMNCgkJCUV4dFRhZysgUkJFKyBGTFJlc2V0LQ0KCQlEZXZDdGw6CVJlcG9ydCBlcnJv
cnM6IENvcnJlY3RhYmxlLSBOb24tRmF0YWwtIEZhdGFsLSBVbnN1cHBvcnRlZC0NCgkJCVJs
eGRPcmQrIEV4dFRhZy0gUGhhbnRGdW5jLSBBdXhQd3ItIE5vU25vb3ArDQoJCQlNYXhQYXls
b2FkIDEyOCBieXRlcywgTWF4UmVhZFJlcSAxMjggYnl0ZXMNCgkJRGV2U3RhOglDb3JyRXJy
LSBVbmNvcnJFcnItIEZhdGFsRXJyLSBVbnN1cHBSZXEtIEF1eFB3ci0gVHJhbnNQZW5kLQ0K
CQlMbmtDYXA6CVBvcnQgIzI0NywgU3BlZWQgMi41R1QvcywgV2lkdGggeDEsIEFTUE0gTDBz
IEwxLCBMYXRlbmN5IEwwIDw2NG5zLCBMMSA8MXVzDQoJCQlDbG9ja1BNLSBTdXJwcmlzZS0g
TExBY3RSZXArIEJ3Tm90Kw0KCQlMbmtDdGw6CUFTUE0gRGlzYWJsZWQ7IFJDQiA2NCBieXRl
cyBEaXNhYmxlZC0gUmV0cmFpbi0gQ29tbUNsay0NCgkJCUV4dFN5bmNoLSBDbG9ja1BNLSBB
dXRXaWREaXMtIEJXSW50LSBBdXRCV0ludC0NCgkJTG5rU3RhOglTcGVlZCB1bmtub3duLCBX
aWR0aCB4MTYsIFRyRXJyLSBUcmFpbi0gU2xvdENsaysgRExBY3RpdmUtIEJXTWdtdC0gQUJX
TWdtdC0NCgkJU2x0Q2FwOglBdHRuQnRuLSBQd3JDdHJsLSBNUkwtIEF0dG5JbmQtIFB3cklu
ZC0gSG90UGx1Zy0gU3VycHJpc2UtDQoJCQlTbG90ICMzMiwgUG93ZXJMaW1pdCA3NS4wMDBX
OyBJbnRlcmxvY2stIE5vQ29tcGwrDQoJCVNsdEN0bDoJRW5hYmxlOiBBdHRuQnRuLSBQd3JG
bHQtIE1STC0gUHJlc0RldC0gQ21kQ3BsdC0gSFBJcnEtIExpbmtDaGctDQoJCQlDb250cm9s
OiBBdHRuSW5kIFVua25vd24sIFB3ckluZCBVbmtub3duLCBQb3dlci0gSW50ZXJsb2NrLQ0K
CQlTbHRTdGE6CVN0YXR1czogQXR0bkJ0bi0gUG93ZXJGbHQtIE1STC0gQ21kQ3BsdC0gUHJl
c0RldC0gSW50ZXJsb2NrLQ0KCQkJQ2hhbmdlZDogTVJMLSBQcmVzRGV0LSBMaW5rU3RhdGUt
DQoJCVJvb3RDdGw6IEVyckNvcnJlY3RhYmxlLSBFcnJOb24tRmF0YWwtIEVyckZhdGFsLSBQ
TUVJbnRFbmEtIENSU1Zpc2libGUtDQoJCVJvb3RDYXA6IENSU1Zpc2libGUtDQoJCVJvb3RT
dGE6IFBNRSBSZXFJRCAwMDAwLCBQTUVTdGF0dXMtIFBNRVBlbmRpbmctDQoJCURldkNhcDI6
IENvbXBsZXRpb24gVGltZW91dDogUmFuZ2UgQUJDRCwgVGltZW91dERpcysgQVJJRndkLQ0K
CQlEZXZDdGwyOiBDb21wbGV0aW9uIFRpbWVvdXQ6IDY1bXMgdG8gMjEwbXMsIFRpbWVvdXRE
aXMtIEFSSUZ3ZC0NCgkJTG5rQ3RsMjogVGFyZ2V0IExpbmsgU3BlZWQ6IDIuNUdUL3MsIEVu
dGVyQ29tcGxpYW5jZS0gU3BlZWREaXMtLCBTZWxlY3RhYmxlIERlLWVtcGhhc2lzOiAtMy41
ZEINCgkJCSBUcmFuc21pdCBNYXJnaW46IE5vcm1hbCBPcGVyYXRpbmcgUmFuZ2UsIEVudGVy
TW9kaWZpZWRDb21wbGlhbmNlLSBDb21wbGlhbmNlU09TLQ0KCQkJIENvbXBsaWFuY2UgRGUt
ZW1waGFzaXM6IC02ZEINCgkJTG5rU3RhMjogQ3VycmVudCBEZS1lbXBoYXNpcyBMZXZlbDog
LTZkQg0KCUNhcGFiaWxpdGllczogW2EwXSBNU0k6IEVuYWJsZSsgQ291bnQ9MS8xIE1hc2th
YmxlLSA2NGJpdCsNCgkJQWRkcmVzczogMDAwMDAwMDBmZWUzZjAwYyAgRGF0YTogNDE5MQ0K
CUNhcGFiaWxpdGllczogW2IwXSBTdWJzeXN0ZW06IEFUSSBUZWNobm9sb2dpZXMgSW5jIERl
dmljZSBbMTAwMjowMDAwXQ0KCUNhcGFiaWxpdGllczogW2I4XSBIeXBlclRyYW5zcG9ydDog
TVNJIE1hcHBpbmcgRW5hYmxlKyBGaXhlZCsNCglDYXBhYmlsaXRpZXM6IFsxMDAgdjFdIFZl
bmRvciBTcGVjaWZpYyBJbmZvcm1hdGlvbjogSUQ9MDAwMSBSZXY9MSBMZW49MDEwIDw/Pg0K
CUtlcm5lbCBkcml2ZXIgaW4gdXNlOiBwY2llcG9ydA0KDQowMDoxNi4wIFVTQiBjb250cm9s
bGVyIFswYzAzXTogQVRJIFRlY2hub2xvZ2llcyBJbmMgU0I3eDAvU0I4eDAvU0I5eDAgVVNC
IE9IQ0kwIENvbnRyb2xsZXIgWzEwMDI6NDM5N10gKHByb2ctaWYgMTAgW09IQ0ldKQ0KCVN1
YnN5c3RlbTogTWljcm8tU3RhciBJbnRlcm5hdGlvbmFsIENvLiwgTHRkLiBEZXZpY2UgWzE0
NjI6NzY0MF0NCglDb250cm9sOiBJL08rIE1lbSsgQnVzTWFzdGVyKyBTcGVjQ3ljbGUtIE1l
bVdJTlYrIFZHQVNub29wLSBQYXJFcnItIFN0ZXBwaW5nLSBTRVJSKyBGYXN0QjJCLSBEaXNJ
TlR4LQ0KCVN0YXR1czogQ2FwLSA2Nk1IeisgVURGLSBGYXN0QjJCKyBQYXJFcnItIERFVlNF
TD1tZWRpdW0gPlRBYm9ydC0gPFRBYm9ydC0gPE1BYm9ydC0gPlNFUlItIDxQRVJSLSBJTlR4
LQ0KCUxhdGVuY3k6IDY0LCBDYWNoZSBMaW5lIFNpemU6IDY0IGJ5dGVzDQoJSW50ZXJydXB0
OiBwaW4gQSByb3V0ZWQgdG8gSVJRIDE4DQoJUmVnaW9uIDA6IE1lbW9yeSBhdCBmOTNmZTAw
MCAoMzItYml0LCBub24tcHJlZmV0Y2hhYmxlKSBbc2l6ZT00S10NCglLZXJuZWwgZHJpdmVy
IGluIHVzZTogb2hjaV9oY2QNCg0KMDA6MTYuMiBVU0IgY29udHJvbGxlciBbMGMwM106IEFU
SSBUZWNobm9sb2dpZXMgSW5jIFNCN3gwL1NCOHgwL1NCOXgwIFVTQiBFSENJIENvbnRyb2xs
ZXIgWzEwMDI6NDM5Nl0gKHByb2ctaWYgMjAgW0VIQ0ldKQ0KCVN1YnN5c3RlbTogTWljcm8t
U3RhciBJbnRlcm5hdGlvbmFsIENvLiwgTHRkLiBEZXZpY2UgWzE0NjI6NzY0MF0NCglDb250
cm9sOiBJL08tIE1lbSsgQnVzTWFzdGVyKyBTcGVjQ3ljbGUtIE1lbVdJTlYrIFZHQVNub29w
LSBQYXJFcnItIFN0ZXBwaW5nLSBTRVJSKyBGYXN0QjJCLSBEaXNJTlR4LQ0KCVN0YXR1czog
Q2FwKyA2Nk1IeisgVURGLSBGYXN0QjJCKyBQYXJFcnItIERFVlNFTD1tZWRpdW0gPlRBYm9y
dC0gPFRBYm9ydC0gPE1BYm9ydC0gPlNFUlItIDxQRVJSLSBJTlR4LQ0KCUxhdGVuY3k6IDY0
LCBDYWNoZSBMaW5lIFNpemU6IDY0IGJ5dGVzDQoJSW50ZXJydXB0OiBwaW4gQiByb3V0ZWQg
dG8gSVJRIDE3DQoJUmVnaW9uIDA6IE1lbW9yeSBhdCBmOTNmZmMwMCAoMzItYml0LCBub24t
cHJlZmV0Y2hhYmxlKSBbc2l6ZT0yNTZdDQoJQ2FwYWJpbGl0aWVzOiBbYzBdIFBvd2VyIE1h
bmFnZW1lbnQgdmVyc2lvbiAyDQoJCUZsYWdzOiBQTUVDbGstIERTSS0gRDErIEQyKyBBdXhD
dXJyZW50PTBtQSBQTUUoRDArLEQxKyxEMissRDNob3QrLEQzY29sZC0pDQoJCVN0YXR1czog
RDAgTm9Tb2Z0UnN0LSBQTUUtRW5hYmxlLSBEU2VsPTAgRFNjYWxlPTAgUE1FLQ0KCQlCcmlk
Z2U6IFBNLSBCMysNCglDYXBhYmlsaXRpZXM6IFtlNF0gRGVidWcgcG9ydDogQkFSPTEgb2Zm
c2V0PTAwZTANCglLZXJuZWwgZHJpdmVyIGluIHVzZTogZWhjaV9oY2QNCg0KMDA6MTguMCBI
b3N0IGJyaWRnZSBbMDYwMF06IEFkdmFuY2VkIE1pY3JvIERldmljZXMgW0FNRF0gRmFtaWx5
IDEwaCBQcm9jZXNzb3IgSHlwZXJUcmFuc3BvcnQgQ29uZmlndXJhdGlvbiBbMTAyMjoxMjAw
XQ0KCUNvbnRyb2w6IEkvTy0gTWVtLSBCdXNNYXN0ZXItIFNwZWNDeWNsZS0gTWVtV0lOVi0g
VkdBU25vb3AtIFBhckVyci0gU3RlcHBpbmctIFNFUlItIEZhc3RCMkItIERpc0lOVHgtDQoJ
U3RhdHVzOiBDYXArIDY2TUh6LSBVREYtIEZhc3RCMkItIFBhckVyci0gREVWU0VMPWZhc3Qg
PlRBYm9ydC0gPFRBYm9ydC0gPE1BYm9ydC0gPlNFUlItIDxQRVJSLSBJTlR4LQ0KCUNhcGFi
aWxpdGllczogWzgwXSBIeXBlclRyYW5zcG9ydDogSG9zdCBvciBTZWNvbmRhcnkgSW50ZXJm
YWNlDQoJCUNvbW1hbmQ6IFdhcm1Sc3QrIERibEVuZC0gRGV2TnVtPTAgQ2hhaW5TaWRlLSBI
b3N0SGlkZSsgU2xhdmUtIDxFT0NFcnItIERVTC0NCgkJTGluayBDb250cm9sOiBDRmxFLSBD
U1QtIENGRS0gPExrRmFpbC0gSW5pdCsgRU9DLSBUWE8tIDxDUkNFcnI9MCBJc29jRW4tIExT
RW4rIEV4dENUTC0gNjRiLQ0KCQlMaW5rIENvbmZpZzogTUxXST0xNmJpdCBEd0ZjSW4tIE1M
V089MTZiaXQgRHdGY091dC0gTFdJPTE2Yml0IER3RmNJbkVuLSBMV089MTZiaXQgRHdGY091
dEVuLQ0KCQlSZXZpc2lvbiBJRDogMy4wMA0KCQlMaW5rIEZyZXF1ZW5jeTogW2JdDQoJCUxp
bmsgRXJyb3I6IDxQcm90LSA8T3ZmbC0gPEVPQy0gQ1RMVG0tDQoJCUxpbmsgRnJlcXVlbmN5
IENhcGFiaWxpdHk6IDIwME1IeisgMzAwTUh6LSA0MDBNSHorIDUwME1Iei0gNjAwTUh6KyA4
MDBNSHorIDEuMEdIeisgMS4yR0h6KyAxLjRHSHotIDEuNkdIei0gVmVuZC0NCgkJRmVhdHVy
ZSBDYXBhYmlsaXR5OiBJc29jRkMrIExEVFNUT1ArIENSQ1RNLSBFQ1RMVC0gNjRiQSsgVUlE
UkQtIEV4dFJTLSBVQ25mRS0NCg0KMDA6MTguMSBIb3N0IGJyaWRnZSBbMDYwMF06IEFkdmFu
Y2VkIE1pY3JvIERldmljZXMgW0FNRF0gRmFtaWx5IDEwaCBQcm9jZXNzb3IgQWRkcmVzcyBN
YXAgWzEwMjI6MTIwMV0NCglDb250cm9sOiBJL08tIE1lbS0gQnVzTWFzdGVyLSBTcGVjQ3lj
bGUtIE1lbVdJTlYtIFZHQVNub29wLSBQYXJFcnItIFN0ZXBwaW5nLSBTRVJSLSBGYXN0QjJC
LSBEaXNJTlR4LQ0KCVN0YXR1czogQ2FwLSA2Nk1Iei0gVURGLSBGYXN0QjJCLSBQYXJFcnIt
IERFVlNFTD1mYXN0ID5UQWJvcnQtIDxUQWJvcnQtIDxNQWJvcnQtID5TRVJSLSA8UEVSUi0g
SU5UeC0NCg0KMDA6MTguMiBIb3N0IGJyaWRnZSBbMDYwMF06IEFkdmFuY2VkIE1pY3JvIERl
dmljZXMgW0FNRF0gRmFtaWx5IDEwaCBQcm9jZXNzb3IgRFJBTSBDb250cm9sbGVyIFsxMDIy
OjEyMDJdDQoJQ29udHJvbDogSS9PLSBNZW0tIEJ1c01hc3Rlci0gU3BlY0N5Y2xlLSBNZW1X
SU5WLSBWR0FTbm9vcC0gUGFyRXJyLSBTdGVwcGluZy0gU0VSUi0gRmFzdEIyQi0gRGlzSU5U
eC0NCglTdGF0dXM6IENhcC0gNjZNSHotIFVERi0gRmFzdEIyQi0gUGFyRXJyLSBERVZTRUw9
ZmFzdCA+VEFib3J0LSA8VEFib3J0LSA8TUFib3J0LSA+U0VSUi0gPFBFUlItIElOVHgtDQoN
CjAwOjE4LjMgSG9zdCBicmlkZ2UgWzA2MDBdOiBBZHZhbmNlZCBNaWNybyBEZXZpY2VzIFtB
TURdIEZhbWlseSAxMGggUHJvY2Vzc29yIE1pc2NlbGxhbmVvdXMgQ29udHJvbCBbMTAyMjox
MjAzXQ0KCUNvbnRyb2w6IEkvTy0gTWVtLSBCdXNNYXN0ZXItIFNwZWNDeWNsZS0gTWVtV0lO
Vi0gVkdBU25vb3AtIFBhckVyci0gU3RlcHBpbmctIFNFUlItIEZhc3RCMkItIERpc0lOVHgt
DQoJU3RhdHVzOiBDYXArIDY2TUh6LSBVREYtIEZhc3RCMkItIFBhckVyci0gREVWU0VMPWZh
c3QgPlRBYm9ydC0gPFRBYm9ydC0gPE1BYm9ydC0gPlNFUlItIDxQRVJSLSBJTlR4LQ0KCUNh
cGFiaWxpdGllczogW2YwXSBTZWN1cmUgZGV2aWNlIDw/Pg0KCUtlcm5lbCBkcml2ZXIgaW4g
dXNlOiBrMTB0ZW1wDQoNCjAwOjE4LjQgSG9zdCBicmlkZ2UgWzA2MDBdOiBBZHZhbmNlZCBN
aWNybyBEZXZpY2VzIFtBTURdIEZhbWlseSAxMGggUHJvY2Vzc29yIExpbmsgQ29udHJvbCBb
MTAyMjoxMjA0XQ0KCUNvbnRyb2w6IEkvTy0gTWVtLSBCdXNNYXN0ZXItIFNwZWNDeWNsZS0g
TWVtV0lOVi0gVkdBU25vb3AtIFBhckVyci0gU3RlcHBpbmctIFNFUlItIEZhc3RCMkItIERp
c0lOVHgtDQoJU3RhdHVzOiBDYXAtIDY2TUh6LSBVREYtIEZhc3RCMkItIFBhckVyci0gREVW
U0VMPWZhc3QgPlRBYm9ydC0gPFRBYm9ydC0gPE1BYm9ydC0gPlNFUlItIDxQRVJSLSBJTlR4
LQ0KDQowMzowNi4wIE11bHRpbWVkaWEgYXVkaW8gY29udHJvbGxlciBbMDQwMV06IEMtTWVk
aWEgRWxlY3Ryb25pY3MgSW5jIENNODczOCBbMTNmNjowMTExXSAocmV2IDEwKQ0KCVN1YnN5
c3RlbTogQy1NZWRpYSBFbGVjdHJvbmljcyBJbmMgQ01JODczOC9DM0RYIFBDSSBBdWRpbyBE
ZXZpY2UgWzEzZjY6MDExMV0NCglDb250cm9sOiBJL08rIE1lbS0gQnVzTWFzdGVyKyBTcGVj
Q3ljbGUtIE1lbVdJTlYtIFZHQVNub29wLSBQYXJFcnItIFN0ZXBwaW5nLSBTRVJSLSBGYXN0
QjJCLSBEaXNJTlR4LQ0KCVN0YXR1czogQ2FwKyA2Nk1Iei0gVURGLSBGYXN0QjJCLSBQYXJF
cnItIERFVlNFTD1tZWRpdW0gPlRBYm9ydC0gPFRBYm9ydC0gPE1BYm9ydC0gPlNFUlItIDxQ
RVJSLSBJTlR4LQ0KCUxhdGVuY3k6IDY0ICg1MDBucyBtaW4sIDYwMDBucyBtYXgpDQoJSW50
ZXJydXB0OiBwaW4gQSByb3V0ZWQgdG8gSVJRIDIyDQoJUmVnaW9uIDA6IEkvTyBwb3J0cyBh
dCBhODAwIFtzaXplPTI1Nl0NCglDYXBhYmlsaXRpZXM6IFtjMF0gUG93ZXIgTWFuYWdlbWVu
dCB2ZXJzaW9uIDINCgkJRmxhZ3M6IFBNRUNsay0gRFNJLSBEMSsgRDIrIEF1eEN1cnJlbnQ9
MG1BIFBNRShEMC0sRDEtLEQyLSxEM2hvdC0sRDNjb2xkLSkNCgkJU3RhdHVzOiBEMCBOb1Nv
ZnRSc3QtIFBNRS1FbmFibGUtIERTZWw9MCBEU2NhbGU9MCBQTUUtDQoJS2VybmVsIGRyaXZl
ciBpbiB1c2U6IHBjaWJhY2sNCg0KMDQ6MDAuMCBVU0IgY29udHJvbGxlciBbMGMwM106IE5l
dE1vcyBUZWNobm9sb2d5IE1DUzk5OTAgUENJZSB0byA04oCQUG9ydCBVU0IgMi4wIEhvc3Qg
Q29udHJvbGxlciBbOTcxMDo5OTkwXSAocHJvZy1pZiAxMCBbT0hDSV0pDQoJU3Vic3lzdGVt
OiBEZXZpY2UgW2EwMDA6NDAwMF0NCglDb250cm9sOiBJL08tIE1lbS0gQnVzTWFzdGVyLSBT
cGVjQ3ljbGUtIE1lbVdJTlYtIFZHQVNub29wLSBQYXJFcnItIFN0ZXBwaW5nLSBTRVJSLSBG
YXN0QjJCLSBEaXNJTlR4LQ0KCVN0YXR1czogQ2FwKyA2Nk1Iei0gVURGLSBGYXN0QjJCLSBQ
YXJFcnItIERFVlNFTD1mYXN0ID5UQWJvcnQtIDxUQWJvcnQtIDxNQWJvcnQtID5TRVJSLSA8
UEVSUi0gSU5UeC0NCglJbnRlcnJ1cHQ6IHBpbiBBIHJvdXRlZCB0byBJUlEgNDANCglSZWdp
b24gMDogTWVtb3J5IGF0IGY5NWY4MDAwICgzMi1iaXQsIG5vbi1wcmVmZXRjaGFibGUpIFtk
aXNhYmxlZF0gW3NpemU9NEtdDQoJQ2FwYWJpbGl0aWVzOiBbNTBdIE1TSTogRW5hYmxlLSBD
b3VudD0xLzEgTWFza2FibGUtIDY0Yml0Kw0KCQlBZGRyZXNzOiAwMDAwMDAwMDAwMDAwMDAw
ICBEYXRhOiAwMDAwDQoJQ2FwYWJpbGl0aWVzOiBbNzhdIFBvd2VyIE1hbmFnZW1lbnQgdmVy
c2lvbiAzDQoJCUZsYWdzOiBQTUVDbGstIERTSS0gRDErIEQyKyBBdXhDdXJyZW50PTM3NW1B
IFBNRShEMCssRDErLEQyKyxEM2hvdCssRDNjb2xkLSkNCgkJU3RhdHVzOiBEMCBOb1NvZnRS
c3QrIFBNRS1FbmFibGUtIERTZWw9MCBEU2NhbGU9MCBQTUUtDQoJQ2FwYWJpbGl0aWVzOiBb
ODBdIEV4cHJlc3MgKHYxKSBFbmRwb2ludCwgTVNJIDAwDQoJCURldkNhcDoJTWF4UGF5bG9h
ZCAyNTYgYnl0ZXMsIFBoYW50RnVuYyAwLCBMYXRlbmN5IEwwcyB1bmxpbWl0ZWQsIEwxIHVu
bGltaXRlZA0KCQkJRXh0VGFnLSBBdHRuQnRuLSBBdHRuSW5kLSBQd3JJbmQtIFJCRSsgRkxS
ZXNldC0NCgkJRGV2Q3RsOglSZXBvcnQgZXJyb3JzOiBDb3JyZWN0YWJsZS0gTm9uLUZhdGFs
LSBGYXRhbC0gVW5zdXBwb3J0ZWQtDQoJCQlSbHhkT3JkLSBFeHRUYWctIFBoYW50RnVuYy0g
QXV4UHdyLSBOb1Nub29wKw0KCQkJTWF4UGF5bG9hZCAxMjggYnl0ZXMsIE1heFJlYWRSZXEg
NTEyIGJ5dGVzDQoJCURldlN0YToJQ29yckVyci0gVW5jb3JyRXJyLSBGYXRhbEVyci0gVW5z
dXBwUmVxLSBBdXhQd3ItIFRyYW5zUGVuZC0NCgkJTG5rQ2FwOglQb3J0ICMxLCBTcGVlZCAy
LjVHVC9zLCBXaWR0aCB4MSwgQVNQTSB1bmtub3duLCBMYXRlbmN5IEwwIDw2NG5zLCBMMSB1
bmxpbWl0ZWQNCgkJCUNsb2NrUE0rIFN1cnByaXNlLSBMTEFjdFJlcC0gQndOb3QtDQoJCUxu
a0N0bDoJQVNQTSBEaXNhYmxlZDsgUkNCIDY0IGJ5dGVzIERpc2FibGVkLSBSZXRyYWluLSBD
b21tQ2xrLQ0KCQkJRXh0U3luY2gtIENsb2NrUE0tIEF1dFdpZERpcy0gQldJbnQtIEF1dEJX
SW50LQ0KCQlMbmtTdGE6CVNwZWVkIDIuNUdUL3MsIFdpZHRoIHgxLCBUckVyci0gVHJhaW4t
IFNsb3RDbGstIERMQWN0aXZlLSBCV01nbXQtIEFCV01nbXQtDQoJQ2FwYWJpbGl0aWVzOiBb
MTAwIHYxXSBWaXJ0dWFsIENoYW5uZWwNCgkJQ2FwczoJTFBFVkM9MCBSZWZDbGs9MTAwbnMg
UEFURW50cnlCaXRzPTENCgkJQXJiOglGaXhlZC0gV1JSMzItIFdSUjY0LSBXUlIxMjgtDQoJ
CUN0cmw6CUFyYlNlbGVjdD1GaXhlZA0KCQlTdGF0dXM6CUluUHJvZ3Jlc3MtDQoJCVZDMDoJ
Q2FwczoJUEFUT2Zmc2V0PTAwIE1heFRpbWVTbG90cz0xIFJlalNub29wVHJhbnMtDQoJCQlB
cmI6CUZpeGVkLSBXUlIzMi0gV1JSNjQtIFdSUjEyOC0gVFdSUjEyOC0gV1JSMjU2LQ0KCQkJ
Q3RybDoJRW5hYmxlKyBJRD0wIEFyYlNlbGVjdD1GaXhlZCBUQy9WQz1mZg0KCQkJU3RhdHVz
OglOZWdvUGVuZGluZy0gSW5Qcm9ncmVzcy0NCglLZXJuZWwgZHJpdmVyIGluIHVzZTogcGNp
YmFjaw0KDQowNDowMC4xIFVTQiBjb250cm9sbGVyIFswYzAzXTogTmV0TW9zIFRlY2hub2xv
Z3kgTUNTOTk5MCBQQ0llIHRvIDTigJBQb3J0IFVTQiAyLjAgSG9zdCBDb250cm9sbGVyIFs5
NzEwOjk5OTBdIChwcm9nLWlmIDIwIFtFSENJXSkNCglTdWJzeXN0ZW06IERldmljZSBbYTAw
MDo0MDAwXQ0KCUNvbnRyb2w6IEkvTy0gTWVtLSBCdXNNYXN0ZXItIFNwZWNDeWNsZS0gTWVt
V0lOVi0gVkdBU25vb3AtIFBhckVyci0gU3RlcHBpbmctIFNFUlItIEZhc3RCMkItIERpc0lO
VHgtDQoJU3RhdHVzOiBDYXArIDY2TUh6LSBVREYtIEZhc3RCMkItIFBhckVyci0gREVWU0VM
PWZhc3QgPlRBYm9ydC0gPFRBYm9ydC0gPE1BYm9ydC0gPlNFUlItIDxQRVJSLSBJTlR4LQ0K
CUludGVycnVwdDogcGluIEEgcm91dGVkIHRvIElSUSA0MA0KCVJlZ2lvbiAwOiBNZW1vcnkg
YXQgZjk1ZjkwMDAgKDMyLWJpdCwgbm9uLXByZWZldGNoYWJsZSkgW2Rpc2FibGVkXSBbc2l6
ZT00S10NCglDYXBhYmlsaXRpZXM6IFs1MF0gTVNJOiBFbmFibGUtIENvdW50PTEvMSBNYXNr
YWJsZS0gNjRiaXQrDQoJCUFkZHJlc3M6IDAwMDAwMDAwMDAwMDAwMDAgIERhdGE6IDAwMDAN
CglDYXBhYmlsaXRpZXM6IFs3OF0gUG93ZXIgTWFuYWdlbWVudCB2ZXJzaW9uIDMNCgkJRmxh
Z3M6IFBNRUNsay0gRFNJLSBEMSsgRDIrIEF1eEN1cnJlbnQ9Mzc1bUEgUE1FKEQwKyxEMSss
RDIrLEQzaG90KyxEM2NvbGQtKQ0KCQlTdGF0dXM6IEQwIE5vU29mdFJzdCsgUE1FLUVuYWJs
ZS0gRFNlbD0wIERTY2FsZT0wIFBNRS0NCglDYXBhYmlsaXRpZXM6IFs4MF0gRXhwcmVzcyAo
djEpIEVuZHBvaW50LCBNU0kgMDANCgkJRGV2Q2FwOglNYXhQYXlsb2FkIDI1NiBieXRlcywg
UGhhbnRGdW5jIDAsIExhdGVuY3kgTDBzIHVubGltaXRlZCwgTDEgdW5saW1pdGVkDQoJCQlF
eHRUYWctIEF0dG5CdG4tIEF0dG5JbmQtIFB3ckluZC0gUkJFKyBGTFJlc2V0LQ0KCQlEZXZD
dGw6CVJlcG9ydCBlcnJvcnM6IENvcnJlY3RhYmxlLSBOb24tRmF0YWwtIEZhdGFsLSBVbnN1
cHBvcnRlZC0NCgkJCVJseGRPcmQtIEV4dFRhZy0gUGhhbnRGdW5jLSBBdXhQd3ItIE5vU25v
b3ArDQoJCQlNYXhQYXlsb2FkIDEyOCBieXRlcywgTWF4UmVhZFJlcSA1MTIgYnl0ZXMNCgkJ
RGV2U3RhOglDb3JyRXJyLSBVbmNvcnJFcnItIEZhdGFsRXJyLSBVbnN1cHBSZXEtIEF1eFB3
ci0gVHJhbnNQZW5kLQ0KCQlMbmtDYXA6CVBvcnQgIzEsIFNwZWVkIDIuNUdUL3MsIFdpZHRo
IHgxLCBBU1BNIHVua25vd24sIExhdGVuY3kgTDAgPDY0bnMsIEwxIHVubGltaXRlZA0KCQkJ
Q2xvY2tQTSsgU3VycHJpc2UtIExMQWN0UmVwLSBCd05vdC0NCgkJTG5rQ3RsOglBU1BNIERp
c2FibGVkOyBSQ0IgNjQgYnl0ZXMgRGlzYWJsZWQtIFJldHJhaW4tIENvbW1DbGstDQoJCQlF
eHRTeW5jaC0gQ2xvY2tQTS0gQXV0V2lkRGlzLSBCV0ludC0gQXV0QldJbnQtDQoJCUxua1N0
YToJU3BlZWQgMi41R1QvcywgV2lkdGggeDEsIFRyRXJyLSBUcmFpbi0gU2xvdENsay0gRExB
Y3RpdmUtIEJXTWdtdC0gQUJXTWdtdC0NCglLZXJuZWwgZHJpdmVyIGluIHVzZTogcGNpYmFj
aw0KDQowNDowMC4yIFVTQiBjb250cm9sbGVyIFswYzAzXTogTmV0TW9zIFRlY2hub2xvZ3kg
TUNTOTk5MCBQQ0llIHRvIDTigJBQb3J0IFVTQiAyLjAgSG9zdCBDb250cm9sbGVyIFs5NzEw
Ojk5OTBdIChwcm9nLWlmIDEwIFtPSENJXSkNCglTdWJzeXN0ZW06IERldmljZSBbYTAwMDo0
MDAwXQ0KCUNvbnRyb2w6IEkvTy0gTWVtLSBCdXNNYXN0ZXItIFNwZWNDeWNsZS0gTWVtV0lO
Vi0gVkdBU25vb3AtIFBhckVyci0gU3RlcHBpbmctIFNFUlItIEZhc3RCMkItIERpc0lOVHgt
DQoJU3RhdHVzOiBDYXArIDY2TUh6LSBVREYtIEZhc3RCMkItIFBhckVyci0gREVWU0VMPWZh
c3QgPlRBYm9ydC0gPFRBYm9ydC0gPE1BYm9ydC0gPlNFUlItIDxQRVJSLSBJTlR4LQ0KCUlu
dGVycnVwdDogcGluIEIgcm91dGVkIHRvIElSUSA0MQ0KCVJlZ2lvbiAwOiBNZW1vcnkgYXQg
Zjk1ZmEwMDAgKDMyLWJpdCwgbm9uLXByZWZldGNoYWJsZSkgW2Rpc2FibGVkXSBbc2l6ZT00
S10NCglDYXBhYmlsaXRpZXM6IFs1MF0gTVNJOiBFbmFibGUtIENvdW50PTEvMSBNYXNrYWJs
ZS0gNjRiaXQrDQoJCUFkZHJlc3M6IDAwMDAwMDAwMDAwMDAwMDAgIERhdGE6IDAwMDANCglD
YXBhYmlsaXRpZXM6IFs3OF0gUG93ZXIgTWFuYWdlbWVudCB2ZXJzaW9uIDMNCgkJRmxhZ3M6
IFBNRUNsay0gRFNJLSBEMSsgRDIrIEF1eEN1cnJlbnQ9Mzc1bUEgUE1FKEQwKyxEMSssRDIr
LEQzaG90KyxEM2NvbGQtKQ0KCQlTdGF0dXM6IEQwIE5vU29mdFJzdCsgUE1FLUVuYWJsZS0g
RFNlbD0wIERTY2FsZT0wIFBNRS0NCglDYXBhYmlsaXRpZXM6IFs4MF0gRXhwcmVzcyAodjEp
IEVuZHBvaW50LCBNU0kgMDANCgkJRGV2Q2FwOglNYXhQYXlsb2FkIDI1NiBieXRlcywgUGhh
bnRGdW5jIDAsIExhdGVuY3kgTDBzIHVubGltaXRlZCwgTDEgdW5saW1pdGVkDQoJCQlFeHRU
YWctIEF0dG5CdG4tIEF0dG5JbmQtIFB3ckluZC0gUkJFKyBGTFJlc2V0LQ0KCQlEZXZDdGw6
CVJlcG9ydCBlcnJvcnM6IENvcnJlY3RhYmxlLSBOb24tRmF0YWwtIEZhdGFsLSBVbnN1cHBv
cnRlZC0NCgkJCVJseGRPcmQtIEV4dFRhZy0gUGhhbnRGdW5jLSBBdXhQd3ItIE5vU25vb3Ar
DQoJCQlNYXhQYXlsb2FkIDEyOCBieXRlcywgTWF4UmVhZFJlcSA1MTIgYnl0ZXMNCgkJRGV2
U3RhOglDb3JyRXJyLSBVbmNvcnJFcnItIEZhdGFsRXJyLSBVbnN1cHBSZXEtIEF1eFB3ci0g
VHJhbnNQZW5kLQ0KCQlMbmtDYXA6CVBvcnQgIzEsIFNwZWVkIDIuNUdUL3MsIFdpZHRoIHgx
LCBBU1BNIHVua25vd24sIExhdGVuY3kgTDAgPDY0bnMsIEwxIHVubGltaXRlZA0KCQkJQ2xv
Y2tQTSsgU3VycHJpc2UtIExMQWN0UmVwLSBCd05vdC0NCgkJTG5rQ3RsOglBU1BNIERpc2Fi
bGVkOyBSQ0IgNjQgYnl0ZXMgRGlzYWJsZWQtIFJldHJhaW4tIENvbW1DbGstDQoJCQlFeHRT
eW5jaC0gQ2xvY2tQTS0gQXV0V2lkRGlzLSBCV0ludC0gQXV0QldJbnQtDQoJCUxua1N0YToJ
U3BlZWQgMi41R1QvcywgV2lkdGggeDEsIFRyRXJyLSBUcmFpbi0gU2xvdENsay0gRExBY3Rp
dmUtIEJXTWdtdC0gQUJXTWdtdC0NCglLZXJuZWwgZHJpdmVyIGluIHVzZTogcGNpYmFjaw0K
DQowNDowMC4zIFVTQiBjb250cm9sbGVyIFswYzAzXTogTmV0TW9zIFRlY2hub2xvZ3kgTUNT
OTk5MCBQQ0llIHRvIDTigJBQb3J0IFVTQiAyLjAgSG9zdCBDb250cm9sbGVyIFs5NzEwOjk5
OTBdIChwcm9nLWlmIDIwIFtFSENJXSkNCglTdWJzeXN0ZW06IERldmljZSBbYTAwMDo0MDAw
XQ0KCUNvbnRyb2w6IEkvTy0gTWVtLSBCdXNNYXN0ZXItIFNwZWNDeWNsZS0gTWVtV0lOVi0g
VkdBU25vb3AtIFBhckVyci0gU3RlcHBpbmctIFNFUlItIEZhc3RCMkItIERpc0lOVHgtDQoJ
U3RhdHVzOiBDYXArIDY2TUh6LSBVREYtIEZhc3RCMkItIFBhckVyci0gREVWU0VMPWZhc3Qg
PlRBYm9ydC0gPFRBYm9ydC0gPE1BYm9ydC0gPlNFUlItIDxQRVJSLSBJTlR4LQ0KCUludGVy
cnVwdDogcGluIEIgcm91dGVkIHRvIElSUSA0MQ0KCVJlZ2lvbiAwOiBNZW1vcnkgYXQgZjk1
ZmIwMDAgKDMyLWJpdCwgbm9uLXByZWZldGNoYWJsZSkgW2Rpc2FibGVkXSBbc2l6ZT00S10N
CglDYXBhYmlsaXRpZXM6IFs1MF0gTVNJOiBFbmFibGUtIENvdW50PTEvMSBNYXNrYWJsZS0g
NjRiaXQrDQoJCUFkZHJlc3M6IDAwMDAwMDAwMDAwMDAwMDAgIERhdGE6IDAwMDANCglDYXBh
YmlsaXRpZXM6IFs3OF0gUG93ZXIgTWFuYWdlbWVudCB2ZXJzaW9uIDMNCgkJRmxhZ3M6IFBN
RUNsay0gRFNJLSBEMSsgRDIrIEF1eEN1cnJlbnQ9Mzc1bUEgUE1FKEQwKyxEMSssRDIrLEQz
aG90KyxEM2NvbGQtKQ0KCQlTdGF0dXM6IEQwIE5vU29mdFJzdCsgUE1FLUVuYWJsZS0gRFNl
bD0wIERTY2FsZT0wIFBNRS0NCglDYXBhYmlsaXRpZXM6IFs4MF0gRXhwcmVzcyAodjEpIEVu
ZHBvaW50LCBNU0kgMDANCgkJRGV2Q2FwOglNYXhQYXlsb2FkIDI1NiBieXRlcywgUGhhbnRG
dW5jIDAsIExhdGVuY3kgTDBzIHVubGltaXRlZCwgTDEgdW5saW1pdGVkDQoJCQlFeHRUYWct
IEF0dG5CdG4tIEF0dG5JbmQtIFB3ckluZC0gUkJFKyBGTFJlc2V0LQ0KCQlEZXZDdGw6CVJl
cG9ydCBlcnJvcnM6IENvcnJlY3RhYmxlLSBOb24tRmF0YWwtIEZhdGFsLSBVbnN1cHBvcnRl
ZC0NCgkJCVJseGRPcmQtIEV4dFRhZy0gUGhhbnRGdW5jLSBBdXhQd3ItIE5vU25vb3ArDQoJ
CQlNYXhQYXlsb2FkIDEyOCBieXRlcywgTWF4UmVhZFJlcSA1MTIgYnl0ZXMNCgkJRGV2U3Rh
OglDb3JyRXJyLSBVbmNvcnJFcnItIEZhdGFsRXJyLSBVbnN1cHBSZXEtIEF1eFB3ci0gVHJh
bnNQZW5kLQ0KCQlMbmtDYXA6CVBvcnQgIzEsIFNwZWVkIDIuNUdUL3MsIFdpZHRoIHgxLCBB
U1BNIHVua25vd24sIExhdGVuY3kgTDAgPDY0bnMsIEwxIHVubGltaXRlZA0KCQkJQ2xvY2tQ
TSsgU3VycHJpc2UtIExMQWN0UmVwLSBCd05vdC0NCgkJTG5rQ3RsOglBU1BNIERpc2FibGVk
OyBSQ0IgNjQgYnl0ZXMgRGlzYWJsZWQtIFJldHJhaW4tIENvbW1DbGstDQoJCQlFeHRTeW5j
aC0gQ2xvY2tQTS0gQXV0V2lkRGlzLSBCV0ludC0gQXV0QldJbnQtDQoJCUxua1N0YToJU3Bl
ZWQgMi41R1QvcywgV2lkdGggeDEsIFRyRXJyLSBUcmFpbi0gU2xvdENsay0gRExBY3RpdmUt
IEJXTWdtdC0gQUJXTWdtdC0NCglLZXJuZWwgZHJpdmVyIGluIHVzZTogcGNpYmFjaw0KDQow
NDowMC40IFVTQiBjb250cm9sbGVyIFswYzAzXTogTmV0TW9zIFRlY2hub2xvZ3kgTUNTOTk5
MCBQQ0llIHRvIDTigJBQb3J0IFVTQiAyLjAgSG9zdCBDb250cm9sbGVyIFs5NzEwOjk5OTBd
IChwcm9nLWlmIDEwIFtPSENJXSkNCglTdWJzeXN0ZW06IERldmljZSBbYTAwMDo0MDAwXQ0K
CUNvbnRyb2w6IEkvTy0gTWVtLSBCdXNNYXN0ZXItIFNwZWNDeWNsZS0gTWVtV0lOVi0gVkdB
U25vb3AtIFBhckVyci0gU3RlcHBpbmctIFNFUlItIEZhc3RCMkItIERpc0lOVHgtDQoJU3Rh
dHVzOiBDYXArIDY2TUh6LSBVREYtIEZhc3RCMkItIFBhckVyci0gREVWU0VMPWZhc3QgPlRB
Ym9ydC0gPFRBYm9ydC0gPE1BYm9ydC0gPlNFUlItIDxQRVJSLSBJTlR4LQ0KCUludGVycnVw
dDogcGluIEMgcm91dGVkIHRvIElSUSA0Mg0KCVJlZ2lvbiAwOiBNZW1vcnkgYXQgZjk1ZmMw
MDAgKDMyLWJpdCwgbm9uLXByZWZldGNoYWJsZSkgW2Rpc2FibGVkXSBbc2l6ZT00S10NCglD
YXBhYmlsaXRpZXM6IFs1MF0gTVNJOiBFbmFibGUtIENvdW50PTEvMSBNYXNrYWJsZS0gNjRi
aXQrDQoJCUFkZHJlc3M6IDAwMDAwMDAwMDAwMDAwMDAgIERhdGE6IDAwMDANCglDYXBhYmls
aXRpZXM6IFs3OF0gUG93ZXIgTWFuYWdlbWVudCB2ZXJzaW9uIDMNCgkJRmxhZ3M6IFBNRUNs
ay0gRFNJLSBEMSsgRDIrIEF1eEN1cnJlbnQ9Mzc1bUEgUE1FKEQwKyxEMSssRDIrLEQzaG90
KyxEM2NvbGQtKQ0KCQlTdGF0dXM6IEQwIE5vU29mdFJzdCsgUE1FLUVuYWJsZS0gRFNlbD0w
IERTY2FsZT0wIFBNRS0NCglDYXBhYmlsaXRpZXM6IFs4MF0gRXhwcmVzcyAodjEpIEVuZHBv
aW50LCBNU0kgMDANCgkJRGV2Q2FwOglNYXhQYXlsb2FkIDI1NiBieXRlcywgUGhhbnRGdW5j
IDAsIExhdGVuY3kgTDBzIHVubGltaXRlZCwgTDEgdW5saW1pdGVkDQoJCQlFeHRUYWctIEF0
dG5CdG4tIEF0dG5JbmQtIFB3ckluZC0gUkJFKyBGTFJlc2V0LQ0KCQlEZXZDdGw6CVJlcG9y
dCBlcnJvcnM6IENvcnJlY3RhYmxlLSBOb24tRmF0YWwtIEZhdGFsLSBVbnN1cHBvcnRlZC0N
CgkJCVJseGRPcmQtIEV4dFRhZy0gUGhhbnRGdW5jLSBBdXhQd3ItIE5vU25vb3ArDQoJCQlN
YXhQYXlsb2FkIDEyOCBieXRlcywgTWF4UmVhZFJlcSA1MTIgYnl0ZXMNCgkJRGV2U3RhOglD
b3JyRXJyLSBVbmNvcnJFcnItIEZhdGFsRXJyLSBVbnN1cHBSZXEtIEF1eFB3ci0gVHJhbnNQ
ZW5kLQ0KCQlMbmtDYXA6CVBvcnQgIzEsIFNwZWVkIDIuNUdUL3MsIFdpZHRoIHgxLCBBU1BN
IHVua25vd24sIExhdGVuY3kgTDAgPDY0bnMsIEwxIHVubGltaXRlZA0KCQkJQ2xvY2tQTSsg
U3VycHJpc2UtIExMQWN0UmVwLSBCd05vdC0NCgkJTG5rQ3RsOglBU1BNIERpc2FibGVkOyBS
Q0IgNjQgYnl0ZXMgRGlzYWJsZWQtIFJldHJhaW4tIENvbW1DbGstDQoJCQlFeHRTeW5jaC0g
Q2xvY2tQTS0gQXV0V2lkRGlzLSBCV0ludC0gQXV0QldJbnQtDQoJCUxua1N0YToJU3BlZWQg
Mi41R1QvcywgV2lkdGggeDEsIFRyRXJyLSBUcmFpbi0gU2xvdENsay0gRExBY3RpdmUtIEJX
TWdtdC0gQUJXTWdtdC0NCglLZXJuZWwgZHJpdmVyIGluIHVzZTogcGNpYmFjaw0KDQowNDow
MC41IFVTQiBjb250cm9sbGVyIFswYzAzXTogTmV0TW9zIFRlY2hub2xvZ3kgTUNTOTk5MCBQ
Q0llIHRvIDTigJBQb3J0IFVTQiAyLjAgSG9zdCBDb250cm9sbGVyIFs5NzEwOjk5OTBdIChw
cm9nLWlmIDIwIFtFSENJXSkNCglTdWJzeXN0ZW06IERldmljZSBbYTAwMDo0MDAwXQ0KCUNv
bnRyb2w6IEkvTy0gTWVtLSBCdXNNYXN0ZXItIFNwZWNDeWNsZS0gTWVtV0lOVi0gVkdBU25v
b3AtIFBhckVyci0gU3RlcHBpbmctIFNFUlItIEZhc3RCMkItIERpc0lOVHgtDQoJU3RhdHVz
OiBDYXArIDY2TUh6LSBVREYtIEZhc3RCMkItIFBhckVyci0gREVWU0VMPWZhc3QgPlRBYm9y
dC0gPFRBYm9ydC0gPE1BYm9ydC0gPlNFUlItIDxQRVJSLSBJTlR4LQ0KCUludGVycnVwdDog
cGluIEMgcm91dGVkIHRvIElSUSA0Mg0KCVJlZ2lvbiAwOiBNZW1vcnkgYXQgZjk1ZmQwMDAg
KDMyLWJpdCwgbm9uLXByZWZldGNoYWJsZSkgW2Rpc2FibGVkXSBbc2l6ZT00S10NCglDYXBh
YmlsaXRpZXM6IFs1MF0gTVNJOiBFbmFibGUtIENvdW50PTEvMSBNYXNrYWJsZS0gNjRiaXQr
DQoJCUFkZHJlc3M6IDAwMDAwMDAwMDAwMDAwMDAgIERhdGE6IDAwMDANCglDYXBhYmlsaXRp
ZXM6IFs3OF0gUG93ZXIgTWFuYWdlbWVudCB2ZXJzaW9uIDMNCgkJRmxhZ3M6IFBNRUNsay0g
RFNJLSBEMSsgRDIrIEF1eEN1cnJlbnQ9Mzc1bUEgUE1FKEQwKyxEMSssRDIrLEQzaG90KyxE
M2NvbGQtKQ0KCQlTdGF0dXM6IEQwIE5vU29mdFJzdCsgUE1FLUVuYWJsZS0gRFNlbD0wIERT
Y2FsZT0wIFBNRS0NCglDYXBhYmlsaXRpZXM6IFs4MF0gRXhwcmVzcyAodjEpIEVuZHBvaW50
LCBNU0kgMDANCgkJRGV2Q2FwOglNYXhQYXlsb2FkIDI1NiBieXRlcywgUGhhbnRGdW5jIDAs
IExhdGVuY3kgTDBzIHVubGltaXRlZCwgTDEgdW5saW1pdGVkDQoJCQlFeHRUYWctIEF0dG5C
dG4tIEF0dG5JbmQtIFB3ckluZC0gUkJFKyBGTFJlc2V0LQ0KCQlEZXZDdGw6CVJlcG9ydCBl
cnJvcnM6IENvcnJlY3RhYmxlLSBOb24tRmF0YWwtIEZhdGFsLSBVbnN1cHBvcnRlZC0NCgkJ
CVJseGRPcmQtIEV4dFRhZy0gUGhhbnRGdW5jLSBBdXhQd3ItIE5vU25vb3ArDQoJCQlNYXhQ
YXlsb2FkIDEyOCBieXRlcywgTWF4UmVhZFJlcSA1MTIgYnl0ZXMNCgkJRGV2U3RhOglDb3Jy
RXJyLSBVbmNvcnJFcnItIEZhdGFsRXJyLSBVbnN1cHBSZXEtIEF1eFB3ci0gVHJhbnNQZW5k
LQ0KCQlMbmtDYXA6CVBvcnQgIzEsIFNwZWVkIDIuNUdUL3MsIFdpZHRoIHgxLCBBU1BNIHVu
a25vd24sIExhdGVuY3kgTDAgPDY0bnMsIEwxIHVubGltaXRlZA0KCQkJQ2xvY2tQTSsgU3Vy
cHJpc2UtIExMQWN0UmVwLSBCd05vdC0NCgkJTG5rQ3RsOglBU1BNIERpc2FibGVkOyBSQ0Ig
NjQgYnl0ZXMgRGlzYWJsZWQtIFJldHJhaW4tIENvbW1DbGstDQoJCQlFeHRTeW5jaC0gQ2xv
Y2tQTS0gQXV0V2lkRGlzLSBCV0ludC0gQXV0QldJbnQtDQoJCUxua1N0YToJU3BlZWQgMi41
R1QvcywgV2lkdGggeDEsIFRyRXJyLSBUcmFpbi0gU2xvdENsay0gRExBY3RpdmUtIEJXTWdt
dC0gQUJXTWdtdC0NCglLZXJuZWwgZHJpdmVyIGluIHVzZTogcGNpYmFjaw0KDQowNDowMC42
IFVTQiBjb250cm9sbGVyIFswYzAzXTogTmV0TW9zIFRlY2hub2xvZ3kgTUNTOTk5MCBQQ0ll
IHRvIDTigJBQb3J0IFVTQiAyLjAgSG9zdCBDb250cm9sbGVyIFs5NzEwOjk5OTBdIChwcm9n
LWlmIDEwIFtPSENJXSkNCglTdWJzeXN0ZW06IERldmljZSBbYTAwMDo0MDAwXQ0KCUNvbnRy
b2w6IEkvTy0gTWVtLSBCdXNNYXN0ZXItIFNwZWNDeWNsZS0gTWVtV0lOVi0gVkdBU25vb3At
IFBhckVyci0gU3RlcHBpbmctIFNFUlItIEZhc3RCMkItIERpc0lOVHgtDQoJU3RhdHVzOiBD
YXArIDY2TUh6LSBVREYtIEZhc3RCMkItIFBhckVyci0gREVWU0VMPWZhc3QgPlRBYm9ydC0g
PFRBYm9ydC0gPE1BYm9ydC0gPlNFUlItIDxQRVJSLSBJTlR4LQ0KCUludGVycnVwdDogcGlu
IEQgcm91dGVkIHRvIElSUSA0Mw0KCVJlZ2lvbiAwOiBNZW1vcnkgYXQgZjk1ZmUwMDAgKDMy
LWJpdCwgbm9uLXByZWZldGNoYWJsZSkgW2Rpc2FibGVkXSBbc2l6ZT00S10NCglDYXBhYmls
aXRpZXM6IFs1MF0gTVNJOiBFbmFibGUtIENvdW50PTEvMSBNYXNrYWJsZS0gNjRiaXQrDQoJ
CUFkZHJlc3M6IDAwMDAwMDAwMDAwMDAwMDAgIERhdGE6IDAwMDANCglDYXBhYmlsaXRpZXM6
IFs3OF0gUG93ZXIgTWFuYWdlbWVudCB2ZXJzaW9uIDMNCgkJRmxhZ3M6IFBNRUNsay0gRFNJ
LSBEMSsgRDIrIEF1eEN1cnJlbnQ9Mzc1bUEgUE1FKEQwKyxEMSssRDIrLEQzaG90KyxEM2Nv
bGQtKQ0KCQlTdGF0dXM6IEQwIE5vU29mdFJzdCsgUE1FLUVuYWJsZS0gRFNlbD0wIERTY2Fs
ZT0wIFBNRS0NCglDYXBhYmlsaXRpZXM6IFs4MF0gRXhwcmVzcyAodjEpIEVuZHBvaW50LCBN
U0kgMDANCgkJRGV2Q2FwOglNYXhQYXlsb2FkIDI1NiBieXRlcywgUGhhbnRGdW5jIDAsIExh
dGVuY3kgTDBzIHVubGltaXRlZCwgTDEgdW5saW1pdGVkDQoJCQlFeHRUYWctIEF0dG5CdG4t
IEF0dG5JbmQtIFB3ckluZC0gUkJFKyBGTFJlc2V0LQ0KCQlEZXZDdGw6CVJlcG9ydCBlcnJv
cnM6IENvcnJlY3RhYmxlLSBOb24tRmF0YWwtIEZhdGFsLSBVbnN1cHBvcnRlZC0NCgkJCVJs
eGRPcmQtIEV4dFRhZy0gUGhhbnRGdW5jLSBBdXhQd3ItIE5vU25vb3ArDQoJCQlNYXhQYXls
b2FkIDEyOCBieXRlcywgTWF4UmVhZFJlcSA1MTIgYnl0ZXMNCgkJRGV2U3RhOglDb3JyRXJy
LSBVbmNvcnJFcnItIEZhdGFsRXJyLSBVbnN1cHBSZXEtIEF1eFB3ci0gVHJhbnNQZW5kLQ0K
CQlMbmtDYXA6CVBvcnQgIzEsIFNwZWVkIDIuNUdUL3MsIFdpZHRoIHgxLCBBU1BNIHVua25v
d24sIExhdGVuY3kgTDAgPDY0bnMsIEwxIHVubGltaXRlZA0KCQkJQ2xvY2tQTSsgU3VycHJp
c2UtIExMQWN0UmVwLSBCd05vdC0NCgkJTG5rQ3RsOglBU1BNIERpc2FibGVkOyBSQ0IgNjQg
Ynl0ZXMgRGlzYWJsZWQtIFJldHJhaW4tIENvbW1DbGstDQoJCQlFeHRTeW5jaC0gQ2xvY2tQ
TS0gQXV0V2lkRGlzLSBCV0ludC0gQXV0QldJbnQtDQoJCUxua1N0YToJU3BlZWQgMi41R1Qv
cywgV2lkdGggeDEsIFRyRXJyLSBUcmFpbi0gU2xvdENsay0gRExBY3RpdmUtIEJXTWdtdC0g
QUJXTWdtdC0NCglLZXJuZWwgZHJpdmVyIGluIHVzZTogcGNpYmFjaw0KDQowNDowMC43IFVT
QiBjb250cm9sbGVyIFswYzAzXTogTmV0TW9zIFRlY2hub2xvZ3kgTUNTOTk5MCBQQ0llIHRv
IDTigJBQb3J0IFVTQiAyLjAgSG9zdCBDb250cm9sbGVyIFs5NzEwOjk5OTBdIChwcm9nLWlm
IDIwIFtFSENJXSkNCglTdWJzeXN0ZW06IERldmljZSBbYTAwMDo0MDAwXQ0KCUNvbnRyb2w6
IEkvTy0gTWVtLSBCdXNNYXN0ZXItIFNwZWNDeWNsZS0gTWVtV0lOVi0gVkdBU25vb3AtIFBh
ckVyci0gU3RlcHBpbmctIFNFUlItIEZhc3RCMkItIERpc0lOVHgtDQoJU3RhdHVzOiBDYXAr
IDY2TUh6LSBVREYtIEZhc3RCMkItIFBhckVyci0gREVWU0VMPWZhc3QgPlRBYm9ydC0gPFRB
Ym9ydC0gPE1BYm9ydC0gPlNFUlItIDxQRVJSLSBJTlR4LQ0KCUludGVycnVwdDogcGluIEQg
cm91dGVkIHRvIElSUSA0Mw0KCVJlZ2lvbiAwOiBNZW1vcnkgYXQgZjk1ZmYwMDAgKDMyLWJp
dCwgbm9uLXByZWZldGNoYWJsZSkgW2Rpc2FibGVkXSBbc2l6ZT00S10NCglDYXBhYmlsaXRp
ZXM6IFs1MF0gTVNJOiBFbmFibGUtIENvdW50PTEvMSBNYXNrYWJsZS0gNjRiaXQrDQoJCUFk
ZHJlc3M6IDAwMDAwMDAwMDAwMDAwMDAgIERhdGE6IDAwMDANCglDYXBhYmlsaXRpZXM6IFs3
OF0gUG93ZXIgTWFuYWdlbWVudCB2ZXJzaW9uIDMNCgkJRmxhZ3M6IFBNRUNsay0gRFNJLSBE
MSsgRDIrIEF1eEN1cnJlbnQ9Mzc1bUEgUE1FKEQwKyxEMSssRDIrLEQzaG90KyxEM2NvbGQt
KQ0KCQlTdGF0dXM6IEQwIE5vU29mdFJzdCsgUE1FLUVuYWJsZS0gRFNlbD0wIERTY2FsZT0w
IFBNRS0NCglDYXBhYmlsaXRpZXM6IFs4MF0gRXhwcmVzcyAodjEpIEVuZHBvaW50LCBNU0kg
MDANCgkJRGV2Q2FwOglNYXhQYXlsb2FkIDI1NiBieXRlcywgUGhhbnRGdW5jIDAsIExhdGVu
Y3kgTDBzIHVubGltaXRlZCwgTDEgdW5saW1pdGVkDQoJCQlFeHRUYWctIEF0dG5CdG4tIEF0
dG5JbmQtIFB3ckluZC0gUkJFKyBGTFJlc2V0LQ0KCQlEZXZDdGw6CVJlcG9ydCBlcnJvcnM6
IENvcnJlY3RhYmxlLSBOb24tRmF0YWwtIEZhdGFsLSBVbnN1cHBvcnRlZC0NCgkJCVJseGRP
cmQtIEV4dFRhZy0gUGhhbnRGdW5jLSBBdXhQd3ItIE5vU25vb3ArDQoJCQlNYXhQYXlsb2Fk
IDEyOCBieXRlcywgTWF4UmVhZFJlcSA1MTIgYnl0ZXMNCgkJRGV2U3RhOglDb3JyRXJyLSBV
bmNvcnJFcnItIEZhdGFsRXJyLSBVbnN1cHBSZXEtIEF1eFB3ci0gVHJhbnNQZW5kLQ0KCQlM
bmtDYXA6CVBvcnQgIzEsIFNwZWVkIDIuNUdUL3MsIFdpZHRoIHgxLCBBU1BNIHVua25vd24s
IExhdGVuY3kgTDAgPDY0bnMsIEwxIHVubGltaXRlZA0KCQkJQ2xvY2tQTSsgU3VycHJpc2Ut
IExMQWN0UmVwLSBCd05vdC0NCgkJTG5rQ3RsOglBU1BNIERpc2FibGVkOyBSQ0IgNjQgYnl0
ZXMgRGlzYWJsZWQtIFJldHJhaW4tIENvbW1DbGstDQoJCQlFeHRTeW5jaC0gQ2xvY2tQTS0g
QXV0V2lkRGlzLSBCV0ludC0gQXV0QldJbnQtDQoJCUxua1N0YToJU3BlZWQgMi41R1Qvcywg
V2lkdGggeDEsIFRyRXJyLSBUcmFpbi0gU2xvdENsay0gRExBY3RpdmUtIEJXTWdtdC0gQUJX
TWdtdC0NCglLZXJuZWwgZHJpdmVyIGluIHVzZTogcGNpYmFjaw0KDQowNTowMC4wIE11bHRp
bWVkaWEgdmlkZW8gY29udHJvbGxlciBbMDQwMF06IENvbmV4YW50IFN5c3RlbXMsIEluYy4g
Q1gyNTg1MCBbMTRmMTo4MjAwXQ0KCUNvbnRyb2w6IEkvTy0gTWVtLSBCdXNNYXN0ZXItIFNw
ZWNDeWNsZS0gTWVtV0lOVi0gVkdBU25vb3AtIFBhckVyci0gU3RlcHBpbmctIFNFUlItIEZh
c3RCMkItIERpc0lOVHgtDQoJU3RhdHVzOiBDYXArIDY2TUh6LSBVREYtIEZhc3RCMkItIFBh
ckVyci0gREVWU0VMPWZhc3QgPlRBYm9ydC0gPFRBYm9ydC0gPE1BYm9ydC0gPlNFUlItIDxQ
RVJSLSBJTlR4LQ0KCUludGVycnVwdDogcGluIEEgcm91dGVkIHRvIElSUSAzNg0KCVJlZ2lv
biAwOiBNZW1vcnkgYXQgZjk2MDAwMDAgKDY0LWJpdCwgbm9uLXByZWZldGNoYWJsZSkgW2Rp
c2FibGVkXSBbc2l6ZT0yTV0NCglDYXBhYmlsaXRpZXM6IFs0MF0gRXhwcmVzcyAodjEpIEVu
ZHBvaW50LCBNU0kgMDANCgkJRGV2Q2FwOglNYXhQYXlsb2FkIDEyOCBieXRlcywgUGhhbnRG
dW5jIDAsIExhdGVuY3kgTDBzIDw2NG5zLCBMMSA8MXVzDQoJCQlFeHRUYWctIEF0dG5CdG4t
IEF0dG5JbmQtIFB3ckluZC0gUkJFKyBGTFJlc2V0LQ0KCQlEZXZDdGw6CVJlcG9ydCBlcnJv
cnM6IENvcnJlY3RhYmxlLSBOb24tRmF0YWwtIEZhdGFsLSBVbnN1cHBvcnRlZC0NCgkJCVJs
eGRPcmQrIEV4dFRhZy0gUGhhbnRGdW5jLSBBdXhQd3ItIE5vU25vb3ArDQoJCQlNYXhQYXls
b2FkIDEyOCBieXRlcywgTWF4UmVhZFJlcSA1MTIgYnl0ZXMNCgkJRGV2U3RhOglDb3JyRXJy
LSBVbmNvcnJFcnItIEZhdGFsRXJyLSBVbnN1cHBSZXEtIEF1eFB3ci0gVHJhbnNQZW5kLQ0K
CQlMbmtDYXA6CVBvcnQgIzAsIFNwZWVkIDIuNUdUL3MsIFdpZHRoIHgxLCBBU1BNIEwwcyBM
MSwgTGF0ZW5jeSBMMCA8MnVzLCBMMSA8NHVzDQoJCQlDbG9ja1BNLSBTdXJwcmlzZS0gTExB
Y3RSZXAtIEJ3Tm90LQ0KCQlMbmtDdGw6CUFTUE0gRGlzYWJsZWQ7IFJDQiA2NCBieXRlcyBE
aXNhYmxlZC0gUmV0cmFpbi0gQ29tbUNsay0NCgkJCUV4dFN5bmNoLSBDbG9ja1BNLSBBdXRX
aWREaXMtIEJXSW50LSBBdXRCV0ludC0NCgkJTG5rU3RhOglTcGVlZCAyLjVHVC9zLCBXaWR0
aCB4MSwgVHJFcnItIFRyYWluLSBTbG90Q2xrLSBETEFjdGl2ZS0gQldNZ210LSBBQldNZ210
LQ0KCUNhcGFiaWxpdGllczogWzgwXSBQb3dlciBNYW5hZ2VtZW50IHZlcnNpb24gMw0KCQlG
bGFnczogUE1FQ2xrLSBEU0krIEQxKyBEMisgQXV4Q3VycmVudD0wbUEgUE1FKEQwKyxEMSss
RDIrLEQzaG90KyxEM2NvbGQtKQ0KCQlTdGF0dXM6IEQwIE5vU29mdFJzdCsgUE1FLUVuYWJs
ZS0gRFNlbD0wIERTY2FsZT0wIFBNRS0NCglDYXBhYmlsaXRpZXM6IFs5MF0gVml0YWwgUHJv
ZHVjdCBEYXRhDQoJCVVua25vd24gc21hbGwgcmVzb3VyY2UgdHlwZSAwMCwgd2lsbCBub3Qg
ZGVjb2RlIG1vcmUuDQoJQ2FwYWJpbGl0aWVzOiBbYTBdIE1TSTogRW5hYmxlLSBDb3VudD0x
LzEgTWFza2FibGUtIDY0Yml0Kw0KCQlBZGRyZXNzOiAwMDAwMDAwMDAwMDAwMDAwICBEYXRh
OiAwMDAwDQoJQ2FwYWJpbGl0aWVzOiBbMTAwIHYxXSBBZHZhbmNlZCBFcnJvciBSZXBvcnRp
bmcNCgkJVUVTdGE6CURMUC0gU0RFUy0gVExQLSBGQ1AtIENtcGx0VE8tIENtcGx0QWJydC0g
VW54Q21wbHQtIFJ4T0YtIE1hbGZUTFAtIEVDUkMtIFVuc3VwUmVxLSBBQ1NWaW9sLQ0KCQlV
RU1zazoJRExQLSBTREVTLSBUTFAtIEZDUC0gQ21wbHRUTy0gQ21wbHRBYnJ0LSBVbnhDbXBs
dC0gUnhPRi0gTWFsZlRMUC0gRUNSQy0gVW5zdXBSZXEtIEFDU1Zpb2wtDQoJCVVFU3ZydDoJ
RExQKyBTREVTLSBUTFAtIEZDUCsgQ21wbHRUTy0gQ21wbHRBYnJ0LSBVbnhDbXBsdC0gUnhP
RisgTWFsZlRMUCsgRUNSQy0gVW5zdXBSZXEtIEFDU1Zpb2wtDQoJCUNFU3RhOglSeEVyci0g
QmFkVExQLSBCYWRETExQLSBSb2xsb3Zlci0gVGltZW91dC0gTm9uRmF0YWxFcnIrDQoJCUNF
TXNrOglSeEVyci0gQmFkVExQLSBCYWRETExQLSBSb2xsb3Zlci0gVGltZW91dC0gTm9uRmF0
YWxFcnIrDQoJCUFFUkNhcDoJRmlyc3QgRXJyb3IgUG9pbnRlcjogMDAsIEdlbkNhcC0gQ0dl
bkVuLSBDaGtDYXAtIENoa0VuLQ0KCUNhcGFiaWxpdGllczogWzIwMCB2MV0gVmlydHVhbCBD
aGFubmVsDQoJCUNhcHM6CUxQRVZDPTEgUmVmQ2xrPTEwMG5zIFBBVEVudHJ5Qml0cz0xDQoJ
CUFyYjoJRml4ZWQrIFdSUjMyKyBXUlI2NCsgV1JSMTI4LQ0KCQlDdHJsOglBcmJTZWxlY3Q9
V1JSNjQNCgkJU3RhdHVzOglJblByb2dyZXNzLQ0KCQlQb3J0IEFyYml0cmF0aW9uIFRhYmxl
IFsyNDBdIDw/Pg0KCQlWQzA6CUNhcHM6CVBBVE9mZnNldD0wMCBNYXhUaW1lU2xvdHM9MSBS
ZWpTbm9vcFRyYW5zLQ0KCQkJQXJiOglGaXhlZC0gV1JSMzItIFdSUjY0LSBXUlIxMjgtIFRX
UlIxMjgtIFdSUjI1Ni0NCgkJCUN0cmw6CUVuYWJsZSsgSUQ9MCBBcmJTZWxlY3Q9Rml4ZWQg
VEMvVkM9ZmYNCgkJCVN0YXR1czoJTmVnb1BlbmRpbmctIEluUHJvZ3Jlc3MtDQoJCVZDMToJ
Q2FwczoJUEFUT2Zmc2V0PTAwIE1heFRpbWVTbG90cz0xIFJlalNub29wVHJhbnMtDQoJCQlB
cmI6CUZpeGVkLSBXUlIzMi0gV1JSNjQtIFdSUjEyOC0gVFdSUjEyOC0gV1JSMjU2LQ0KCQkJ
Q3RybDoJRW5hYmxlLSBJRD0xIEFyYlNlbGVjdD1GaXhlZCBUQy9WQz0wMA0KCQkJU3RhdHVz
OglOZWdvUGVuZGluZy0gSW5Qcm9ncmVzcy0NCglLZXJuZWwgZHJpdmVyIGluIHVzZTogcGNp
YmFjaw0KDQowNjowMC4wIFZHQSBjb21wYXRpYmxlIGNvbnRyb2xsZXIgWzAzMDBdOiBBVEkg
VGVjaG5vbG9naWVzIEluYyBSVjYyMCBMRSBbUmFkZW9uIEhEIDM0NTBdIFsxMDAyOjk1YzVd
IChwcm9nLWlmIDAwIFtWR0EgY29udHJvbGxlcl0pDQoJU3Vic3lzdGVtOiBBU1VTVGVLIENv
bXB1dGVyIEluYy4gRGV2aWNlIFsxMDQzOjAxZDRdDQoJQ29udHJvbDogSS9PLSBNZW0tIEJ1
c01hc3Rlci0gU3BlY0N5Y2xlLSBNZW1XSU5WLSBWR0FTbm9vcC0gUGFyRXJyLSBTdGVwcGlu
Zy0gU0VSUi0gRmFzdEIyQi0gRGlzSU5UeC0NCglTdGF0dXM6IENhcCsgNjZNSHotIFVERi0g
RmFzdEIyQi0gUGFyRXJyLSBERVZTRUw9ZmFzdCA+VEFib3J0LSA8VEFib3J0LSA8TUFib3J0
LSA+U0VSUi0gPFBFUlItIElOVHgtDQoJSW50ZXJydXB0OiBwaW4gQSByb3V0ZWQgdG8gSVJR
IDEwDQoJUmVnaW9uIDA6IE1lbW9yeSBhdCBiMDAwMDAwMCAoNjQtYml0LCBwcmVmZXRjaGFi
bGUpIFtkaXNhYmxlZF0gW3NpemU9MjU2TV0NCglSZWdpb24gMjogTWVtb3J5IGF0IGY5OWUw
MDAwICg2NC1iaXQsIG5vbi1wcmVmZXRjaGFibGUpIFtkaXNhYmxlZF0gW3NpemU9NjRLXQ0K
CVJlZ2lvbiA0OiBJL08gcG9ydHMgYXQgYjAwMCBbZGlzYWJsZWRdIFtzaXplPTI1Nl0NCglF
eHBhbnNpb24gUk9NIGF0IGY5OWMwMDAwIFtkaXNhYmxlZF0gW3NpemU9MTI4S10NCglDYXBh
YmlsaXRpZXM6IFs1MF0gUG93ZXIgTWFuYWdlbWVudCB2ZXJzaW9uIDMNCgkJRmxhZ3M6IFBN
RUNsay0gRFNJLSBEMSsgRDIrIEF1eEN1cnJlbnQ9MG1BIFBNRShEMC0sRDEtLEQyLSxEM2hv
dC0sRDNjb2xkLSkNCgkJU3RhdHVzOiBEMCBOb1NvZnRSc3QtIFBNRS1FbmFibGUtIERTZWw9
MCBEU2NhbGU9MCBQTUUtDQoJQ2FwYWJpbGl0aWVzOiBbNThdIEV4cHJlc3MgKHYyKSBMZWdh
Y3kgRW5kcG9pbnQsIE1TSSAwMA0KCQlEZXZDYXA6CU1heFBheWxvYWQgMTI4IGJ5dGVzLCBQ
aGFudEZ1bmMgMCwgTGF0ZW5jeSBMMHMgPDR1cywgTDEgdW5saW1pdGVkDQoJCQlFeHRUYWcr
IEF0dG5CdG4tIEF0dG5JbmQtIFB3ckluZC0gUkJFKyBGTFJlc2V0LQ0KCQlEZXZDdGw6CVJl
cG9ydCBlcnJvcnM6IENvcnJlY3RhYmxlLSBOb24tRmF0YWwtIEZhdGFsLSBVbnN1cHBvcnRl
ZC0NCgkJCVJseGRPcmQrIEV4dFRhZy0gUGhhbnRGdW5jLSBBdXhQd3ItIE5vU25vb3ArDQoJ
CQlNYXhQYXlsb2FkIDEyOCBieXRlcywgTWF4UmVhZFJlcSAxMjggYnl0ZXMNCgkJRGV2U3Rh
OglDb3JyRXJyLSBVbmNvcnJFcnItIEZhdGFsRXJyLSBVbnN1cHBSZXEtIEF1eFB3ci0gVHJh
bnNQZW5kLQ0KCQlMbmtDYXA6CVBvcnQgIzAsIFNwZWVkIDIuNUdUL3MsIFdpZHRoIHgxNiwg
QVNQTSBMMHMgTDEsIExhdGVuY3kgTDAgPDY0bnMsIEwxIDwxdXMNCgkJCUNsb2NrUE0tIFN1
cnByaXNlLSBMTEFjdFJlcC0gQndOb3QtDQoJCUxua0N0bDoJQVNQTSBEaXNhYmxlZDsgUkNC
IDY0IGJ5dGVzIERpc2FibGVkLSBSZXRyYWluLSBDb21tQ2xrKw0KCQkJRXh0U3luY2gtIENs
b2NrUE0tIEF1dFdpZERpcy0gQldJbnQtIEF1dEJXSW50LQ0KCQlMbmtTdGE6CVNwZWVkIDIu
NUdUL3MsIFdpZHRoIHgxLCBUckVyci0gVHJhaW4tIFNsb3RDbGsrIERMQWN0aXZlLSBCV01n
bXQtIEFCV01nbXQtDQoJCURldkNhcDI6IENvbXBsZXRpb24gVGltZW91dDogTm90IFN1cHBv
cnRlZCwgVGltZW91dERpcy0NCgkJRGV2Q3RsMjogQ29tcGxldGlvbiBUaW1lb3V0OiA1MHVz
IHRvIDUwbXMsIFRpbWVvdXREaXMtDQoJCUxua0N0bDI6IFRhcmdldCBMaW5rIFNwZWVkOiAy
LjVHVC9zLCBFbnRlckNvbXBsaWFuY2UtIFNwZWVkRGlzLSwgU2VsZWN0YWJsZSBEZS1lbXBo
YXNpczogLTZkQg0KCQkJIFRyYW5zbWl0IE1hcmdpbjogTm9ybWFsIE9wZXJhdGluZyBSYW5n
ZSwgRW50ZXJNb2RpZmllZENvbXBsaWFuY2UtIENvbXBsaWFuY2VTT1MtDQoJCQkgQ29tcGxp
YW5jZSBEZS1lbXBoYXNpczogLTZkQg0KCQlMbmtTdGEyOiBDdXJyZW50IERlLWVtcGhhc2lz
IExldmVsOiAtNmRCDQoJQ2FwYWJpbGl0aWVzOiBbYTBdIE1TSTogRW5hYmxlLSBDb3VudD0x
LzEgTWFza2FibGUtIDY0Yml0Kw0KCQlBZGRyZXNzOiAwMDAwMDAwMDAwMDAwMDAwICBEYXRh
OiAwMDAwDQoJQ2FwYWJpbGl0aWVzOiBbMTAwIHYxXSBWZW5kb3IgU3BlY2lmaWMgSW5mb3Jt
YXRpb246IElEPTAwMDEgUmV2PTEgTGVuPTAxMCA8Pz4NCg0KMDY6MDAuMSBBdWRpbyBkZXZp
Y2UgWzA0MDNdOiBBVEkgVGVjaG5vbG9naWVzIEluYyBSVjYyMCBBdWRpbyBkZXZpY2UgW1Jh
ZGVvbiBIRCAzNHh4IFNlcmllc10gWzEwMDI6YWEyOF0NCglTdWJzeXN0ZW06IEFTVVNUZUsg
Q29tcHV0ZXIgSW5jLiBEZXZpY2UgWzEwNDM6YWEyOF0NCglDb250cm9sOiBJL08rIE1lbSsg
QnVzTWFzdGVyKyBTcGVjQ3ljbGUtIE1lbVdJTlYtIFZHQVNub29wLSBQYXJFcnItIFN0ZXBw
aW5nLSBTRVJSKyBGYXN0QjJCLSBEaXNJTlR4Kw0KCVN0YXR1czogQ2FwKyA2Nk1Iei0gVURG
LSBGYXN0QjJCLSBQYXJFcnItIERFVlNFTD1mYXN0ID5UQWJvcnQtIDxUQWJvcnQtIDxNQWJv
cnQtID5TRVJSLSA8UEVSUi0gSU5UeC0NCglMYXRlbmN5OiAwLCBDYWNoZSBMaW5lIFNpemU6
IDY0IGJ5dGVzDQoJSW50ZXJydXB0OiBwaW4gQiByb3V0ZWQgdG8gSVJRIDEyMw0KCVJlZ2lv
biAwOiBNZW1vcnkgYXQgZjk5ZmMwMDAgKDY0LWJpdCwgbm9uLXByZWZldGNoYWJsZSkgW3Np
emU9MTZLXQ0KCUNhcGFiaWxpdGllczogWzUwXSBQb3dlciBNYW5hZ2VtZW50IHZlcnNpb24g
Mw0KCQlGbGFnczogUE1FQ2xrLSBEU0ktIEQxKyBEMisgQXV4Q3VycmVudD0wbUEgUE1FKEQw
LSxEMS0sRDItLEQzaG90LSxEM2NvbGQtKQ0KCQlTdGF0dXM6IEQwIE5vU29mdFJzdC0gUE1F
LUVuYWJsZS0gRFNlbD0wIERTY2FsZT0wIFBNRS0NCglDYXBhYmlsaXRpZXM6IFs1OF0gRXhw
cmVzcyAodjIpIExlZ2FjeSBFbmRwb2ludCwgTVNJIDAwDQoJCURldkNhcDoJTWF4UGF5bG9h
ZCAxMjggYnl0ZXMsIFBoYW50RnVuYyAwLCBMYXRlbmN5IEwwcyA8NHVzLCBMMSB1bmxpbWl0
ZWQNCgkJCUV4dFRhZysgQXR0bkJ0bi0gQXR0bkluZC0gUHdySW5kLSBSQkUrIEZMUmVzZXQt
DQoJCURldkN0bDoJUmVwb3J0IGVycm9yczogQ29ycmVjdGFibGUtIE5vbi1GYXRhbC0gRmF0
YWwtIFVuc3VwcG9ydGVkLQ0KCQkJUmx4ZE9yZCsgRXh0VGFnLSBQaGFudEZ1bmMtIEF1eFB3
ci0gTm9Tbm9vcCsNCgkJCU1heFBheWxvYWQgMTI4IGJ5dGVzLCBNYXhSZWFkUmVxIDEyOCBi
eXRlcw0KCQlEZXZTdGE6CUNvcnJFcnItIFVuY29yckVyci0gRmF0YWxFcnItIFVuc3VwcFJl
cS0gQXV4UHdyLSBUcmFuc1BlbmQtDQoJCUxua0NhcDoJUG9ydCAjMCwgU3BlZWQgMi41R1Qv
cywgV2lkdGggeDE2LCBBU1BNIEwwcyBMMSwgTGF0ZW5jeSBMMCA8NjRucywgTDEgPDF1cw0K
CQkJQ2xvY2tQTS0gU3VycHJpc2UtIExMQWN0UmVwLSBCd05vdC0NCgkJTG5rQ3RsOglBU1BN
IERpc2FibGVkOyBSQ0IgNjQgYnl0ZXMgRGlzYWJsZWQtIFJldHJhaW4tIENvbW1DbGsrDQoJ
CQlFeHRTeW5jaC0gQ2xvY2tQTS0gQXV0V2lkRGlzLSBCV0ludC0gQXV0QldJbnQtDQoJCUxu
a1N0YToJU3BlZWQgMi41R1QvcywgV2lkdGggeDEsIFRyRXJyLSBUcmFpbi0gU2xvdENsaysg
RExBY3RpdmUtIEJXTWdtdC0gQUJXTWdtdC0NCgkJRGV2Q2FwMjogQ29tcGxldGlvbiBUaW1l
b3V0OiBOb3QgU3VwcG9ydGVkLCBUaW1lb3V0RGlzLQ0KCQlEZXZDdGwyOiBDb21wbGV0aW9u
IFRpbWVvdXQ6IDUwdXMgdG8gNTBtcywgVGltZW91dERpcy0NCgkJTG5rQ3RsMjogVGFyZ2V0
IExpbmsgU3BlZWQ6IDIuNUdUL3MsIEVudGVyQ29tcGxpYW5jZS0gU3BlZWREaXMtLCBTZWxl
Y3RhYmxlIERlLWVtcGhhc2lzOiAtNmRCDQoJCQkgVHJhbnNtaXQgTWFyZ2luOiBOb3JtYWwg
T3BlcmF0aW5nIFJhbmdlLCBFbnRlck1vZGlmaWVkQ29tcGxpYW5jZS0gQ29tcGxpYW5jZVNP
Uy0NCgkJCSBDb21wbGlhbmNlIERlLWVtcGhhc2lzOiAtNmRCDQoJCUxua1N0YTI6IEN1cnJl
bnQgRGUtZW1waGFzaXMgTGV2ZWw6IC02ZEINCglDYXBhYmlsaXRpZXM6IFthMF0gTVNJOiBF
bmFibGUrIENvdW50PTEvMSBNYXNrYWJsZS0gNjRiaXQrDQoJCUFkZHJlc3M6IDAwMDAwMDAw
ZmVlMDEwMGMgIERhdGE6IDQxMmENCglDYXBhYmlsaXRpZXM6IFsxMDAgdjFdIFZlbmRvciBT
cGVjaWZpYyBJbmZvcm1hdGlvbjogSUQ9MDAwMSBSZXY9MSBMZW49MDEwIDw/Pg0KCUtlcm5l
bCBkcml2ZXIgaW4gdXNlOiBzbmRfaGRhX2ludGVsDQoNCjA3OjAwLjAgTXVsdGltZWRpYSB2
aWRlbyBjb250cm9sbGVyIFswNDAwXTogQ29uZXhhbnQgU3lzdGVtcywgSW5jLiBEZXZpY2Ug
WzE0ZjE6ODIxMF0NCglDb250cm9sOiBJL08tIE1lbSsgQnVzTWFzdGVyKyBTcGVjQ3ljbGUt
IE1lbVdJTlYtIFZHQVNub29wLSBQYXJFcnItIFN0ZXBwaW5nLSBTRVJSLSBGYXN0QjJCLSBE
aXNJTlR4LQ0KCVN0YXR1czogQ2FwKyA2Nk1Iei0gVURGLSBGYXN0QjJCLSBQYXJFcnItIERF
VlNFTD1mYXN0ID5UQWJvcnQtIDxUQWJvcnQtIDxNQWJvcnQtID5TRVJSLSA8UEVSUi0gSU5U
eC0NCglMYXRlbmN5OiAwDQoJSW50ZXJydXB0OiBwaW4gQSByb3V0ZWQgdG8gSVJRIDQ3DQoJ
UmVnaW9uIDA6IE1lbW9yeSBhdCBmOWEwMDAwMCAoNjQtYml0LCBub24tcHJlZmV0Y2hhYmxl
KSBbc2l6ZT0yTV0NCglDYXBhYmlsaXRpZXM6IFs0MF0gRXhwcmVzcyAodjEpIEVuZHBvaW50
LCBNU0kgMDANCgkJRGV2Q2FwOglNYXhQYXlsb2FkIDEyOCBieXRlcywgUGhhbnRGdW5jIDAs
IExhdGVuY3kgTDBzIDw2NG5zLCBMMSA8MXVzDQoJCQlFeHRUYWctIEF0dG5CdG4tIEF0dG5J
bmQtIFB3ckluZC0gUkJFKyBGTFJlc2V0LQ0KCQlEZXZDdGw6CVJlcG9ydCBlcnJvcnM6IENv
cnJlY3RhYmxlLSBOb24tRmF0YWwtIEZhdGFsLSBVbnN1cHBvcnRlZC0NCgkJCVJseGRPcmQr
IEV4dFRhZy0gUGhhbnRGdW5jLSBBdXhQd3ItIE5vU25vb3ArDQoJCQlNYXhQYXlsb2FkIDEy
OCBieXRlcywgTWF4UmVhZFJlcSA1MTIgYnl0ZXMNCgkJRGV2U3RhOglDb3JyRXJyLSBVbmNv
cnJFcnItIEZhdGFsRXJyLSBVbnN1cHBSZXEtIEF1eFB3ci0gVHJhbnNQZW5kLQ0KCQlMbmtD
YXA6CVBvcnQgIzAsIFNwZWVkIDIuNUdUL3MsIFdpZHRoIHgxLCBBU1BNIEwwcyBMMSwgTGF0
ZW5jeSBMMCA8MnVzLCBMMSA8NHVzDQoJCQlDbG9ja1BNLSBTdXJwcmlzZS0gTExBY3RSZXAt
IEJ3Tm90LQ0KCQlMbmtDdGw6CUFTUE0gRGlzYWJsZWQ7IFJDQiA2NCBieXRlcyBEaXNhYmxl
ZC0gUmV0cmFpbi0gQ29tbUNsay0NCgkJCUV4dFN5bmNoLSBDbG9ja1BNLSBBdXRXaWREaXMt
IEJXSW50LSBBdXRCV0ludC0NCgkJTG5rU3RhOglTcGVlZCAyLjVHVC9zLCBXaWR0aCB4MSwg
VHJFcnItIFRyYWluLSBTbG90Q2xrLSBETEFjdGl2ZS0gQldNZ210LSBBQldNZ210LQ0KCUNh
cGFiaWxpdGllczogWzgwXSBQb3dlciBNYW5hZ2VtZW50IHZlcnNpb24gMw0KCQlGbGFnczog
UE1FQ2xrLSBEU0krIEQxKyBEMisgQXV4Q3VycmVudD0wbUEgUE1FKEQwKyxEMSssRDIrLEQz
aG90KyxEM2NvbGQtKQ0KCQlTdGF0dXM6IEQwIE5vU29mdFJzdCsgUE1FLUVuYWJsZS0gRFNl
bD0wIERTY2FsZT0wIFBNRS0NCglDYXBhYmlsaXRpZXM6IFs5MF0gVml0YWwgUHJvZHVjdCBE
YXRhDQoJCVVua25vd24gc21hbGwgcmVzb3VyY2UgdHlwZSAwMiwgd2lsbCBub3QgZGVjb2Rl
IG1vcmUuDQoJQ2FwYWJpbGl0aWVzOiBbYTBdIE1TSTogRW5hYmxlLSBDb3VudD0xLzEgTWFz
a2FibGUtIDY0Yml0Kw0KCQlBZGRyZXNzOiAwMDAwMDAwMDAwMDAwMDAwICBEYXRhOiAwMDAw
DQoJQ2FwYWJpbGl0aWVzOiBbMTAwIHYxXSBBZHZhbmNlZCBFcnJvciBSZXBvcnRpbmcNCgkJ
VUVTdGE6CURMUC0gU0RFUy0gVExQLSBGQ1AtIENtcGx0VE8tIENtcGx0QWJydC0gVW54Q21w
bHQtIFJ4T0YtIE1hbGZUTFAtIEVDUkMtIFVuc3VwUmVxLSBBQ1NWaW9sLQ0KCQlVRU1zazoJ
RExQLSBTREVTLSBUTFAtIEZDUC0gQ21wbHRUTy0gQ21wbHRBYnJ0LSBVbnhDbXBsdC0gUnhP
Ri0gTWFsZlRMUC0gRUNSQy0gVW5zdXBSZXEtIEFDU1Zpb2wtDQoJCVVFU3ZydDoJRExQKyBT
REVTLSBUTFAtIEZDUCsgQ21wbHRUTy0gQ21wbHRBYnJ0LSBVbnhDbXBsdC0gUnhPRisgTWFs
ZlRMUCsgRUNSQy0gVW5zdXBSZXEtIEFDU1Zpb2wtDQoJCUNFU3RhOglSeEVyci0gQmFkVExQ
LSBCYWRETExQLSBSb2xsb3Zlci0gVGltZW91dC0gTm9uRmF0YWxFcnIrDQoJCUNFTXNrOglS
eEVyci0gQmFkVExQLSBCYWRETExQLSBSb2xsb3Zlci0gVGltZW91dC0gTm9uRmF0YWxFcnIr
DQoJCUFFUkNhcDoJRmlyc3QgRXJyb3IgUG9pbnRlcjogMDAsIEdlbkNhcC0gQ0dlbkVuLSBD
aGtDYXAtIENoa0VuLQ0KCUNhcGFiaWxpdGllczogWzIwMCB2MV0gVmlydHVhbCBDaGFubmVs
DQoJCUNhcHM6CUxQRVZDPTEgUmVmQ2xrPTEwMG5zIFBBVEVudHJ5Qml0cz0xDQoJCUFyYjoJ
Rml4ZWQrIFdSUjMyKyBXUlI2NCsgV1JSMTI4LQ0KCQlDdHJsOglBcmJTZWxlY3Q9V1JSNjQN
CgkJU3RhdHVzOglJblByb2dyZXNzLQ0KCQlQb3J0IEFyYml0cmF0aW9uIFRhYmxlIFsyNDBd
IDw/Pg0KCQlWQzA6CUNhcHM6CVBBVE9mZnNldD0wMCBNYXhUaW1lU2xvdHM9MSBSZWpTbm9v
cFRyYW5zLQ0KCQkJQXJiOglGaXhlZC0gV1JSMzItIFdSUjY0LSBXUlIxMjgtIFRXUlIxMjgt
IFdSUjI1Ni0NCgkJCUN0cmw6CUVuYWJsZSsgSUQ9MCBBcmJTZWxlY3Q9Rml4ZWQgVEMvVkM9
ZmYNCgkJCVN0YXR1czoJTmVnb1BlbmRpbmctIEluUHJvZ3Jlc3MtDQoJCVZDMToJQ2FwczoJ
UEFUT2Zmc2V0PTAwIE1heFRpbWVTbG90cz0xIFJlalNub29wVHJhbnMtDQoJCQlBcmI6CUZp
eGVkLSBXUlIzMi0gV1JSNjQtIFdSUjEyOC0gVFdSUjEyOC0gV1JSMjU2LQ0KCQkJQ3RybDoJ
RW5hYmxlLSBJRD0xIEFyYlNlbGVjdD1GaXhlZCBUQy9WQz0wMA0KCQkJU3RhdHVzOglOZWdv
UGVuZGluZy0gSW5Qcm9ncmVzcy0NCglLZXJuZWwgZHJpdmVyIGluIHVzZTogcGNpYmFjaw0K
DQowODowMC4wIEV0aGVybmV0IGNvbnRyb2xsZXIgWzAyMDBdOiBSZWFsdGVrIFNlbWljb25k
dWN0b3IgQ28uLCBMdGQuIFJUTDgxMTEvODE2OEIgUENJIEV4cHJlc3MgR2lnYWJpdCBFdGhl
cm5ldCBjb250cm9sbGVyIFsxMGVjOjgxNjhdIChyZXYgMDMpDQoJU3Vic3lzdGVtOiBNaWNy
by1TdGFyIEludGVybmF0aW9uYWwgQ28uLCBMdGQuIERldmljZSBbMTQ2Mjo3NjQwXQ0KCUNv
bnRyb2w6IEkvTysgTWVtKyBCdXNNYXN0ZXIrIFNwZWNDeWNsZS0gTWVtV0lOVi0gVkdBU25v
b3AtIFBhckVyci0gU3RlcHBpbmctIFNFUlIrIEZhc3RCMkItIERpc0lOVHgrDQoJU3RhdHVz
OiBDYXArIDY2TUh6LSBVREYtIEZhc3RCMkItIFBhckVyci0gREVWU0VMPWZhc3QgPlRBYm9y
dC0gPFRBYm9ydC0gPE1BYm9ydC0gPlNFUlItIDxQRVJSLSBJTlR4LQ0KCUxhdGVuY3k6IDAs
IENhY2hlIExpbmUgU2l6ZTogNjQgYnl0ZXMNCglJbnRlcnJ1cHQ6IHBpbiBBIHJvdXRlZCB0
byBJUlEgMTIyDQoJUmVnaW9uIDA6IEkvTyBwb3J0cyBhdCBjODAwIFtzaXplPTI1Nl0NCglS
ZWdpb24gMjogTWVtb3J5IGF0IGNmZWZmMDAwICg2NC1iaXQsIHByZWZldGNoYWJsZSkgW3Np
emU9NEtdDQoJUmVnaW9uIDQ6IE1lbW9yeSBhdCBjZmVmODAwMCAoNjQtYml0LCBwcmVmZXRj
aGFibGUpIFtzaXplPTE2S10NCglFeHBhbnNpb24gUk9NIGF0IGY5ZGUwMDAwIFtkaXNhYmxl
ZF0gW3NpemU9MTI4S10NCglDYXBhYmlsaXRpZXM6IFs0MF0gUG93ZXIgTWFuYWdlbWVudCB2
ZXJzaW9uIDMNCgkJRmxhZ3M6IFBNRUNsay0gRFNJLSBEMSsgRDIrIEF1eEN1cnJlbnQ9Mzc1
bUEgUE1FKEQwKyxEMSssRDIrLEQzaG90KyxEM2NvbGQrKQ0KCQlTdGF0dXM6IEQwIE5vU29m
dFJzdCsgUE1FLUVuYWJsZS0gRFNlbD0wIERTY2FsZT0wIFBNRS0NCglDYXBhYmlsaXRpZXM6
IFs1MF0gTVNJOiBFbmFibGUrIENvdW50PTEvMSBNYXNrYWJsZS0gNjRiaXQrDQoJCUFkZHJl
c3M6IDAwMDAwMDAwZmVlMDEwMGMgIERhdGE6IDQxZDkNCglDYXBhYmlsaXRpZXM6IFs3MF0g
RXhwcmVzcyAodjIpIEVuZHBvaW50LCBNU0kgMDENCgkJRGV2Q2FwOglNYXhQYXlsb2FkIDI1
NiBieXRlcywgUGhhbnRGdW5jIDAsIExhdGVuY3kgTDBzIDw1MTJucywgTDEgPDY0dXMNCgkJ
CUV4dFRhZy0gQXR0bkJ0bi0gQXR0bkluZC0gUHdySW5kLSBSQkUrIEZMUmVzZXQtDQoJCURl
dkN0bDoJUmVwb3J0IGVycm9yczogQ29ycmVjdGFibGUtIE5vbi1GYXRhbC0gRmF0YWwtIFVu
c3VwcG9ydGVkLQ0KCQkJUmx4ZE9yZC0gRXh0VGFnLSBQaGFudEZ1bmMtIEF1eFB3ci0gTm9T
bm9vcC0NCgkJCU1heFBheWxvYWQgMTI4IGJ5dGVzLCBNYXhSZWFkUmVxIDUxMiBieXRlcw0K
CQlEZXZTdGE6CUNvcnJFcnIrIFVuY29yckVyci0gRmF0YWxFcnItIFVuc3VwcFJlcSsgQXV4
UHdyKyBUcmFuc1BlbmQtDQoJCUxua0NhcDoJUG9ydCAjMCwgU3BlZWQgMi41R1QvcywgV2lk
dGggeDEsIEFTUE0gTDBzIEwxLCBMYXRlbmN5IEwwIDw1MTJucywgTDEgPDY0dXMNCgkJCUNs
b2NrUE0rIFN1cnByaXNlLSBMTEFjdFJlcC0gQndOb3QtDQoJCUxua0N0bDoJQVNQTSBEaXNh
YmxlZDsgUkNCIDY0IGJ5dGVzIERpc2FibGVkLSBSZXRyYWluLSBDb21tQ2xrKw0KCQkJRXh0
U3luY2gtIENsb2NrUE0tIEF1dFdpZERpcy0gQldJbnQtIEF1dEJXSW50LQ0KCQlMbmtTdGE6
CVNwZWVkIDIuNUdUL3MsIFdpZHRoIHgxLCBUckVyci0gVHJhaW4tIFNsb3RDbGsrIERMQWN0
aXZlLSBCV01nbXQtIEFCV01nbXQtDQoJCURldkNhcDI6IENvbXBsZXRpb24gVGltZW91dDog
Tm90IFN1cHBvcnRlZCwgVGltZW91dERpcysNCgkJRGV2Q3RsMjogQ29tcGxldGlvbiBUaW1l
b3V0OiA1MHVzIHRvIDUwbXMsIFRpbWVvdXREaXMtDQoJCUxua0N0bDI6IFRhcmdldCBMaW5r
IFNwZWVkOiAyLjVHVC9zLCBFbnRlckNvbXBsaWFuY2UtIFNwZWVkRGlzLSwgU2VsZWN0YWJs
ZSBEZS1lbXBoYXNpczogLTZkQg0KCQkJIFRyYW5zbWl0IE1hcmdpbjogTm9ybWFsIE9wZXJh
dGluZyBSYW5nZSwgRW50ZXJNb2RpZmllZENvbXBsaWFuY2UtIENvbXBsaWFuY2VTT1MtDQoJ
CQkgQ29tcGxpYW5jZSBEZS1lbXBoYXNpczogLTZkQg0KCQlMbmtTdGEyOiBDdXJyZW50IERl
LWVtcGhhc2lzIExldmVsOiAtNmRCDQoJQ2FwYWJpbGl0aWVzOiBbYWNdIE1TSS1YOiBFbmFi
bGUtIENvdW50PTQgTWFza2VkLQ0KCQlWZWN0b3IgdGFibGU6IEJBUj00IG9mZnNldD0wMDAw
MDAwMA0KCQlQQkE6IEJBUj00IG9mZnNldD0wMDAwMDgwMA0KCUNhcGFiaWxpdGllczogW2Nj
XSBWaXRhbCBQcm9kdWN0IERhdGENCgkJVW5rbm93biBzbWFsbCByZXNvdXJjZSB0eXBlIDAw
LCB3aWxsIG5vdCBkZWNvZGUgbW9yZS4NCglDYXBhYmlsaXRpZXM6IFsxMDAgdjFdIEFkdmFu
Y2VkIEVycm9yIFJlcG9ydGluZw0KCQlVRVN0YToJRExQLSBTREVTLSBUTFAtIEZDUC0gQ21w
bHRUTy0gQ21wbHRBYnJ0LSBVbnhDbXBsdC0gUnhPRi0gTWFsZlRMUC0gRUNSQy0gVW5zdXBS
ZXEtIEFDU1Zpb2wtDQoJCVVFTXNrOglETFAtIFNERVMtIFRMUC0gRkNQLSBDbXBsdFRPLSBD
bXBsdEFicnQtIFVueENtcGx0LSBSeE9GLSBNYWxmVExQLSBFQ1JDLSBVbnN1cFJlcS0gQUNT
VmlvbC0NCgkJVUVTdnJ0OglETFArIFNERVMrIFRMUC0gRkNQKyBDbXBsdFRPLSBDbXBsdEFi
cnQtIFVueENtcGx0LSBSeE9GKyBNYWxmVExQKyBFQ1JDLSBVbnN1cFJlcS0gQUNTVmlvbC0N
CgkJQ0VTdGE6CVJ4RXJyKyBCYWRUTFAtIEJhZERMTFAtIFJvbGxvdmVyLSBUaW1lb3V0LSBO
b25GYXRhbEVycisNCgkJQ0VNc2s6CVJ4RXJyLSBCYWRUTFAtIEJhZERMTFAtIFJvbGxvdmVy
LSBUaW1lb3V0LSBOb25GYXRhbEVycisNCgkJQUVSQ2FwOglGaXJzdCBFcnJvciBQb2ludGVy
OiAwMCwgR2VuQ2FwKyBDR2VuRW4tIENoa0NhcCsgQ2hrRW4tDQoJQ2FwYWJpbGl0aWVzOiBb
MTQwIHYxXSBWaXJ0dWFsIENoYW5uZWwNCgkJQ2FwczoJTFBFVkM9MCBSZWZDbGs9MTAwbnMg
UEFURW50cnlCaXRzPTENCgkJQXJiOglGaXhlZC0gV1JSMzItIFdSUjY0LSBXUlIxMjgtDQoJ
CUN0cmw6CUFyYlNlbGVjdD1GaXhlZA0KCQlTdGF0dXM6CUluUHJvZ3Jlc3MtDQoJCVZDMDoJ
Q2FwczoJUEFUT2Zmc2V0PTAwIE1heFRpbWVTbG90cz0xIFJlalNub29wVHJhbnMtDQoJCQlB
cmI6CUZpeGVkLSBXUlIzMi0gV1JSNjQtIFdSUjEyOC0gVFdSUjEyOC0gV1JSMjU2LQ0KCQkJ
Q3RybDoJRW5hYmxlKyBJRD0wIEFyYlNlbGVjdD1GaXhlZCBUQy9WQz1mZg0KCQkJU3RhdHVz
OglOZWdvUGVuZGluZy0gSW5Qcm9ncmVzcy0NCglDYXBhYmlsaXRpZXM6IFsxNjAgdjFdIERl
dmljZSBTZXJpYWwgTnVtYmVyIDAzLTAwLTAwLTAwLTY4LTRjLWUwLTAwDQoJS2VybmVsIGRy
aXZlciBpbiB1c2U6IHI4MTY5DQoNCjA5OjAwLjAgRXRoZXJuZXQgY29udHJvbGxlciBbMDIw
MF06IFJlYWx0ZWsgU2VtaWNvbmR1Y3RvciBDby4sIEx0ZC4gUlRMODExMS84MTY4QiBQQ0kg
RXhwcmVzcyBHaWdhYml0IEV0aGVybmV0IGNvbnRyb2xsZXIgWzEwZWM6ODE2OF0gKHJldiAw
MykNCglTdWJzeXN0ZW06IE1pY3JvLVN0YXIgSW50ZXJuYXRpb25hbCBDby4sIEx0ZC4gRGV2
aWNlIFsxNDYyOjc2NDBdDQoJQ29udHJvbDogSS9PKyBNZW0rIEJ1c01hc3RlcisgU3BlY0N5
Y2xlLSBNZW1XSU5WLSBWR0FTbm9vcC0gUGFyRXJyLSBTdGVwcGluZy0gU0VSUisgRmFzdEIy
Qi0gRGlzSU5UeCsNCglTdGF0dXM6IENhcCsgNjZNSHotIFVERi0gRmFzdEIyQi0gUGFyRXJy
LSBERVZTRUw9ZmFzdCA+VEFib3J0LSA8VEFib3J0LSA8TUFib3J0LSA+U0VSUi0gPFBFUlIt
IElOVHgtDQoJTGF0ZW5jeTogMCwgQ2FjaGUgTGluZSBTaXplOiA2NCBieXRlcw0KCUludGVy
cnVwdDogcGluIEEgcm91dGVkIHRvIElSUSAxMjENCglSZWdpb24gMDogSS9PIHBvcnRzIGF0
IGQ4MDAgW3NpemU9MjU2XQ0KCVJlZ2lvbiAyOiBNZW1vcnkgYXQgY2ZmZmYwMDAgKDY0LWJp
dCwgcHJlZmV0Y2hhYmxlKSBbc2l6ZT00S10NCglSZWdpb24gNDogTWVtb3J5IGF0IGNmZmY4
MDAwICg2NC1iaXQsIHByZWZldGNoYWJsZSkgW3NpemU9MTZLXQ0KCUV4cGFuc2lvbiBST00g
YXQgZjllZTAwMDAgW2Rpc2FibGVkXSBbc2l6ZT0xMjhLXQ0KCUNhcGFiaWxpdGllczogWzQw
XSBQb3dlciBNYW5hZ2VtZW50IHZlcnNpb24gMw0KCQlGbGFnczogUE1FQ2xrLSBEU0ktIEQx
KyBEMisgQXV4Q3VycmVudD0zNzVtQSBQTUUoRDArLEQxKyxEMissRDNob3QrLEQzY29sZCsp
DQoJCVN0YXR1czogRDAgTm9Tb2Z0UnN0KyBQTUUtRW5hYmxlLSBEU2VsPTAgRFNjYWxlPTAg
UE1FLQ0KCUNhcGFiaWxpdGllczogWzUwXSBNU0k6IEVuYWJsZSsgQ291bnQ9MS8xIE1hc2th
YmxlLSA2NGJpdCsNCgkJQWRkcmVzczogMDAwMDAwMDBmZWUwMTAwYyAgRGF0YTogNDFjOQ0K
CUNhcGFiaWxpdGllczogWzcwXSBFeHByZXNzICh2MikgRW5kcG9pbnQsIE1TSSAwMQ0KCQlE
ZXZDYXA6CU1heFBheWxvYWQgMjU2IGJ5dGVzLCBQaGFudEZ1bmMgMCwgTGF0ZW5jeSBMMHMg
PDUxMm5zLCBMMSA8NjR1cw0KCQkJRXh0VGFnLSBBdHRuQnRuLSBBdHRuSW5kLSBQd3JJbmQt
IFJCRSsgRkxSZXNldC0NCgkJRGV2Q3RsOglSZXBvcnQgZXJyb3JzOiBDb3JyZWN0YWJsZS0g
Tm9uLUZhdGFsLSBGYXRhbC0gVW5zdXBwb3J0ZWQtDQoJCQlSbHhkT3JkLSBFeHRUYWctIFBo
YW50RnVuYy0gQXV4UHdyLSBOb1Nub29wLQ0KCQkJTWF4UGF5bG9hZCAxMjggYnl0ZXMsIE1h
eFJlYWRSZXEgNDA5NiBieXRlcw0KCQlEZXZTdGE6CUNvcnJFcnIrIFVuY29yckVyci0gRmF0
YWxFcnItIFVuc3VwcFJlcSsgQXV4UHdyKyBUcmFuc1BlbmQtDQoJCUxua0NhcDoJUG9ydCAj
MCwgU3BlZWQgMi41R1QvcywgV2lkdGggeDEsIEFTUE0gTDBzIEwxLCBMYXRlbmN5IEwwIDw1
MTJucywgTDEgPDY0dXMNCgkJCUNsb2NrUE0rIFN1cnByaXNlLSBMTEFjdFJlcC0gQndOb3Qt
DQoJCUxua0N0bDoJQVNQTSBEaXNhYmxlZDsgUkNCIDY0IGJ5dGVzIERpc2FibGVkLSBSZXRy
YWluLSBDb21tQ2xrKw0KCQkJRXh0U3luY2gtIENsb2NrUE0tIEF1dFdpZERpcy0gQldJbnQt
IEF1dEJXSW50LQ0KCQlMbmtTdGE6CVNwZWVkIDIuNUdUL3MsIFdpZHRoIHgxLCBUckVyci0g
VHJhaW4tIFNsb3RDbGsrIERMQWN0aXZlLSBCV01nbXQtIEFCV01nbXQtDQoJCURldkNhcDI6
IENvbXBsZXRpb24gVGltZW91dDogTm90IFN1cHBvcnRlZCwgVGltZW91dERpcysNCgkJRGV2
Q3RsMjogQ29tcGxldGlvbiBUaW1lb3V0OiA1MHVzIHRvIDUwbXMsIFRpbWVvdXREaXMtDQoJ
CUxua0N0bDI6IFRhcmdldCBMaW5rIFNwZWVkOiAyLjVHVC9zLCBFbnRlckNvbXBsaWFuY2Ut
IFNwZWVkRGlzLSwgU2VsZWN0YWJsZSBEZS1lbXBoYXNpczogLTZkQg0KCQkJIFRyYW5zbWl0
IE1hcmdpbjogTm9ybWFsIE9wZXJhdGluZyBSYW5nZSwgRW50ZXJNb2RpZmllZENvbXBsaWFu
Y2UtIENvbXBsaWFuY2VTT1MtDQoJCQkgQ29tcGxpYW5jZSBEZS1lbXBoYXNpczogLTZkQg0K
CQlMbmtTdGEyOiBDdXJyZW50IERlLWVtcGhhc2lzIExldmVsOiAtNmRCDQoJQ2FwYWJpbGl0
aWVzOiBbYWNdIE1TSS1YOiBFbmFibGUtIENvdW50PTQgTWFza2VkLQ0KCQlWZWN0b3IgdGFi
bGU6IEJBUj00IG9mZnNldD0wMDAwMDAwMA0KCQlQQkE6IEJBUj00IG9mZnNldD0wMDAwMDgw
MA0KCUNhcGFiaWxpdGllczogW2NjXSBWaXRhbCBQcm9kdWN0IERhdGENCgkJVW5rbm93biBz
bWFsbCByZXNvdXJjZSB0eXBlIDAwLCB3aWxsIG5vdCBkZWNvZGUgbW9yZS4NCglDYXBhYmls
aXRpZXM6IFsxMDAgdjFdIEFkdmFuY2VkIEVycm9yIFJlcG9ydGluZw0KCQlVRVN0YToJRExQ
LSBTREVTLSBUTFAtIEZDUC0gQ21wbHRUTy0gQ21wbHRBYnJ0LSBVbnhDbXBsdC0gUnhPRi0g
TWFsZlRMUC0gRUNSQy0gVW5zdXBSZXEtIEFDU1Zpb2wtDQoJCVVFTXNrOglETFAtIFNERVMt
IFRMUC0gRkNQLSBDbXBsdFRPLSBDbXBsdEFicnQtIFVueENtcGx0LSBSeE9GLSBNYWxmVExQ
LSBFQ1JDLSBVbnN1cFJlcS0gQUNTVmlvbC0NCgkJVUVTdnJ0OglETFArIFNERVMrIFRMUC0g
RkNQKyBDbXBsdFRPLSBDbXBsdEFicnQtIFVueENtcGx0LSBSeE9GKyBNYWxmVExQKyBFQ1JD
LSBVbnN1cFJlcS0gQUNTVmlvbC0NCgkJQ0VTdGE6CVJ4RXJyKyBCYWRUTFAtIEJhZERMTFAt
IFJvbGxvdmVyLSBUaW1lb3V0LSBOb25GYXRhbEVycisNCgkJQ0VNc2s6CVJ4RXJyLSBCYWRU
TFAtIEJhZERMTFAtIFJvbGxvdmVyLSBUaW1lb3V0LSBOb25GYXRhbEVycisNCgkJQUVSQ2Fw
OglGaXJzdCBFcnJvciBQb2ludGVyOiAwMCwgR2VuQ2FwKyBDR2VuRW4tIENoa0NhcCsgQ2hr
RW4tDQoJQ2FwYWJpbGl0aWVzOiBbMTQwIHYxXSBWaXJ0dWFsIENoYW5uZWwNCgkJQ2FwczoJ
TFBFVkM9MCBSZWZDbGs9MTAwbnMgUEFURW50cnlCaXRzPTENCgkJQXJiOglGaXhlZC0gV1JS
MzItIFdSUjY0LSBXUlIxMjgtDQoJCUN0cmw6CUFyYlNlbGVjdD1GaXhlZA0KCQlTdGF0dXM6
CUluUHJvZ3Jlc3MtDQoJCVZDMDoJQ2FwczoJUEFUT2Zmc2V0PTAwIE1heFRpbWVTbG90cz0x
IFJlalNub29wVHJhbnMtDQoJCQlBcmI6CUZpeGVkLSBXUlIzMi0gV1JSNjQtIFdSUjEyOC0g
VFdSUjEyOC0gV1JSMjU2LQ0KCQkJQ3RybDoJRW5hYmxlKyBJRD0wIEFyYlNlbGVjdD1GaXhl
ZCBUQy9WQz1mZg0KCQkJU3RhdHVzOglOZWdvUGVuZGluZy0gSW5Qcm9ncmVzcy0NCglDYXBh
YmlsaXRpZXM6IFsxNjAgdjFdIERldmljZSBTZXJpYWwgTnVtYmVyIDA0LTAwLTAwLTAwLTY4
LTRjLWUwLTAwDQoJS2VybmVsIGRyaXZlciBpbiB1c2U6IHI4MTY5DQoNCjBhOjAwLjAgVVNC
IGNvbnRyb2xsZXIgWzBjMDNdOiBOZXRNb3MgVGVjaG5vbG9neSBNQ1M5OTkwIFBDSWUgdG8g
NOKAkFBvcnQgVVNCIDIuMCBIb3N0IENvbnRyb2xsZXIgWzk3MTA6OTk5MF0gKHByb2ctaWYg
MTAgW09IQ0ldKQ0KCVN1YnN5c3RlbTogRGV2aWNlIFthMDAwOjQwMDBdDQoJQ29udHJvbDog
SS9PLSBNZW0rIEJ1c01hc3RlcisgU3BlY0N5Y2xlLSBNZW1XSU5WLSBWR0FTbm9vcC0gUGFy
RXJyLSBTdGVwcGluZy0gU0VSUi0gRmFzdEIyQi0gRGlzSU5UeC0NCglTdGF0dXM6IENhcCsg
NjZNSHotIFVERi0gRmFzdEIyQi0gUGFyRXJyLSBERVZTRUw9ZmFzdCA+VEFib3J0LSA8VEFi
b3J0KyA8TUFib3J0LSA+U0VSUi0gPFBFUlItIElOVHgtDQoJTGF0ZW5jeTogMCwgQ2FjaGUg
TGluZSBTaXplOiA2NCBieXRlcw0KCUludGVycnVwdDogcGluIEEgcm91dGVkIHRvIElSUSAy
OA0KCVJlZ2lvbiAwOiBNZW1vcnkgYXQgZjlmZjgwMDAgKDMyLWJpdCwgbm9uLXByZWZldGNo
YWJsZSkgW3NpemU9NEtdDQoJQ2FwYWJpbGl0aWVzOiBbNTBdIE1TSTogRW5hYmxlLSBDb3Vu
dD0xLzEgTWFza2FibGUtIDY0Yml0Kw0KCQlBZGRyZXNzOiAwMDAwMDAwMDAwMDAwMDAwICBE
YXRhOiAwMDAwDQoJQ2FwYWJpbGl0aWVzOiBbNzhdIFBvd2VyIE1hbmFnZW1lbnQgdmVyc2lv
biAzDQoJCUZsYWdzOiBQTUVDbGstIERTSS0gRDErIEQyKyBBdXhDdXJyZW50PTM3NW1BIFBN
RShEMCssRDErLEQyKyxEM2hvdCssRDNjb2xkLSkNCgkJU3RhdHVzOiBEMCBOb1NvZnRSc3Qr
IFBNRS1FbmFibGUtIERTZWw9MCBEU2NhbGU9MCBQTUUtDQoJQ2FwYWJpbGl0aWVzOiBbODBd
IEV4cHJlc3MgKHYxKSBFbmRwb2ludCwgTVNJIDAwDQoJCURldkNhcDoJTWF4UGF5bG9hZCAy
NTYgYnl0ZXMsIFBoYW50RnVuYyAwLCBMYXRlbmN5IEwwcyB1bmxpbWl0ZWQsIEwxIHVubGlt
aXRlZA0KCQkJRXh0VGFnLSBBdHRuQnRuLSBBdHRuSW5kLSBQd3JJbmQtIFJCRSsgRkxSZXNl
dC0NCgkJRGV2Q3RsOglSZXBvcnQgZXJyb3JzOiBDb3JyZWN0YWJsZS0gTm9uLUZhdGFsLSBG
YXRhbC0gVW5zdXBwb3J0ZWQtDQoJCQlSbHhkT3JkLSBFeHRUYWctIFBoYW50RnVuYy0gQXV4
UHdyLSBOb1Nub29wKw0KCQkJTWF4UGF5bG9hZCAxMjggYnl0ZXMsIE1heFJlYWRSZXEgNTEy
IGJ5dGVzDQoJCURldlN0YToJQ29yckVyci0gVW5jb3JyRXJyLSBGYXRhbEVyci0gVW5zdXBw
UmVxLSBBdXhQd3ItIFRyYW5zUGVuZC0NCgkJTG5rQ2FwOglQb3J0ICMxLCBTcGVlZCAyLjVH
VC9zLCBXaWR0aCB4MSwgQVNQTSB1bmtub3duLCBMYXRlbmN5IEwwIDw2NG5zLCBMMSB1bmxp
bWl0ZWQNCgkJCUNsb2NrUE0rIFN1cnByaXNlLSBMTEFjdFJlcC0gQndOb3QtDQoJCUxua0N0
bDoJQVNQTSBEaXNhYmxlZDsgUkNCIDY0IGJ5dGVzIERpc2FibGVkLSBSZXRyYWluLSBDb21t
Q2xrLQ0KCQkJRXh0U3luY2gtIENsb2NrUE0tIEF1dFdpZERpcy0gQldJbnQtIEF1dEJXSW50
LQ0KCQlMbmtTdGE6CVNwZWVkIDIuNUdUL3MsIFdpZHRoIHgxLCBUckVyci0gVHJhaW4tIFNs
b3RDbGstIERMQWN0aXZlLSBCV01nbXQtIEFCV01nbXQtDQoJQ2FwYWJpbGl0aWVzOiBbMTAw
IHYxXSBWaXJ0dWFsIENoYW5uZWwNCgkJQ2FwczoJTFBFVkM9MCBSZWZDbGs9MTAwbnMgUEFU
RW50cnlCaXRzPTENCgkJQXJiOglGaXhlZC0gV1JSMzItIFdSUjY0LSBXUlIxMjgtDQoJCUN0
cmw6CUFyYlNlbGVjdD1GaXhlZA0KCQlTdGF0dXM6CUluUHJvZ3Jlc3MtDQoJCVZDMDoJQ2Fw
czoJUEFUT2Zmc2V0PTAwIE1heFRpbWVTbG90cz0xIFJlalNub29wVHJhbnMtDQoJCQlBcmI6
CUZpeGVkLSBXUlIzMi0gV1JSNjQtIFdSUjEyOC0gVFdSUjEyOC0gV1JSMjU2LQ0KCQkJQ3Ry
bDoJRW5hYmxlKyBJRD0wIEFyYlNlbGVjdD1GaXhlZCBUQy9WQz1mZg0KCQkJU3RhdHVzOglO
ZWdvUGVuZGluZy0gSW5Qcm9ncmVzcy0NCglLZXJuZWwgZHJpdmVyIGluIHVzZTogcGNpYmFj
aw0KDQowYTowMC4xIFVTQiBjb250cm9sbGVyIFswYzAzXTogTmV0TW9zIFRlY2hub2xvZ3kg
TUNTOTk5MCBQQ0llIHRvIDTigJBQb3J0IFVTQiAyLjAgSG9zdCBDb250cm9sbGVyIFs5NzEw
Ojk5OTBdIChwcm9nLWlmIDIwIFtFSENJXSkNCglTdWJzeXN0ZW06IERldmljZSBbYTAwMDo0
MDAwXQ0KCUNvbnRyb2w6IEkvTy0gTWVtKyBCdXNNYXN0ZXIrIFNwZWNDeWNsZS0gTWVtV0lO
Vi0gVkdBU25vb3AtIFBhckVyci0gU3RlcHBpbmctIFNFUlItIEZhc3RCMkItIERpc0lOVHgt
DQoJU3RhdHVzOiBDYXArIDY2TUh6LSBVREYtIEZhc3RCMkItIFBhckVyci0gREVWU0VMPWZh
c3QgPlRBYm9ydC0gPFRBYm9ydCsgPE1BYm9ydC0gPlNFUlItIDxQRVJSLSBJTlR4LQ0KCUxh
dGVuY3k6IDAsIENhY2hlIExpbmUgU2l6ZTogNjQgYnl0ZXMNCglJbnRlcnJ1cHQ6IHBpbiBB
IHJvdXRlZCB0byBJUlEgMjgNCglSZWdpb24gMDogTWVtb3J5IGF0IGY5ZmY5MDAwICgzMi1i
aXQsIG5vbi1wcmVmZXRjaGFibGUpIFtzaXplPTRLXQ0KCUNhcGFiaWxpdGllczogWzUwXSBN
U0k6IEVuYWJsZS0gQ291bnQ9MS8xIE1hc2thYmxlLSA2NGJpdCsNCgkJQWRkcmVzczogMDAw
MDAwMDAwMDAwMDAwMCAgRGF0YTogMDAwMA0KCUNhcGFiaWxpdGllczogWzc4XSBQb3dlciBN
YW5hZ2VtZW50IHZlcnNpb24gMw0KCQlGbGFnczogUE1FQ2xrLSBEU0ktIEQxKyBEMisgQXV4
Q3VycmVudD0zNzVtQSBQTUUoRDArLEQxKyxEMissRDNob3QrLEQzY29sZC0pDQoJCVN0YXR1
czogRDAgTm9Tb2Z0UnN0KyBQTUUtRW5hYmxlLSBEU2VsPTAgRFNjYWxlPTAgUE1FLQ0KCUNh
cGFiaWxpdGllczogWzgwXSBFeHByZXNzICh2MSkgRW5kcG9pbnQsIE1TSSAwMA0KCQlEZXZD
YXA6CU1heFBheWxvYWQgMjU2IGJ5dGVzLCBQaGFudEZ1bmMgMCwgTGF0ZW5jeSBMMHMgdW5s
aW1pdGVkLCBMMSB1bmxpbWl0ZWQNCgkJCUV4dFRhZy0gQXR0bkJ0bi0gQXR0bkluZC0gUHdy
SW5kLSBSQkUrIEZMUmVzZXQtDQoJCURldkN0bDoJUmVwb3J0IGVycm9yczogQ29ycmVjdGFi
bGUtIE5vbi1GYXRhbC0gRmF0YWwtIFVuc3VwcG9ydGVkLQ0KCQkJUmx4ZE9yZC0gRXh0VGFn
LSBQaGFudEZ1bmMtIEF1eFB3ci0gTm9Tbm9vcCsNCgkJCU1heFBheWxvYWQgMTI4IGJ5dGVz
LCBNYXhSZWFkUmVxIDUxMiBieXRlcw0KCQlEZXZTdGE6CUNvcnJFcnItIFVuY29yckVyci0g
RmF0YWxFcnItIFVuc3VwcFJlcS0gQXV4UHdyLSBUcmFuc1BlbmQtDQoJCUxua0NhcDoJUG9y
dCAjMSwgU3BlZWQgMi41R1QvcywgV2lkdGggeDEsIEFTUE0gdW5rbm93biwgTGF0ZW5jeSBM
MCA8NjRucywgTDEgdW5saW1pdGVkDQoJCQlDbG9ja1BNKyBTdXJwcmlzZS0gTExBY3RSZXAt
IEJ3Tm90LQ0KCQlMbmtDdGw6CUFTUE0gRGlzYWJsZWQ7IFJDQiA2NCBieXRlcyBEaXNhYmxl
ZC0gUmV0cmFpbi0gQ29tbUNsay0NCgkJCUV4dFN5bmNoLSBDbG9ja1BNLSBBdXRXaWREaXMt
IEJXSW50LSBBdXRCV0ludC0NCgkJTG5rU3RhOglTcGVlZCAyLjVHVC9zLCBXaWR0aCB4MSwg
VHJFcnItIFRyYWluLSBTbG90Q2xrLSBETEFjdGl2ZS0gQldNZ210LSBBQldNZ210LQ0KCUtl
cm5lbCBkcml2ZXIgaW4gdXNlOiBwY2liYWNrDQoNCjBhOjAwLjIgVVNCIGNvbnRyb2xsZXIg
WzBjMDNdOiBOZXRNb3MgVGVjaG5vbG9neSBNQ1M5OTkwIFBDSWUgdG8gNOKAkFBvcnQgVVNC
IDIuMCBIb3N0IENvbnRyb2xsZXIgWzk3MTA6OTk5MF0gKHByb2ctaWYgMTAgW09IQ0ldKQ0K
CVN1YnN5c3RlbTogRGV2aWNlIFthMDAwOjQwMDBdDQoJQ29udHJvbDogSS9PLSBNZW0rIEJ1
c01hc3RlcisgU3BlY0N5Y2xlLSBNZW1XSU5WLSBWR0FTbm9vcC0gUGFyRXJyLSBTdGVwcGlu
Zy0gU0VSUi0gRmFzdEIyQi0gRGlzSU5UeC0NCglTdGF0dXM6IENhcCsgNjZNSHotIFVERi0g
RmFzdEIyQi0gUGFyRXJyLSBERVZTRUw9ZmFzdCA+VEFib3J0LSA8VEFib3J0KyA8TUFib3J0
LSA+U0VSUi0gPFBFUlItIElOVHgtDQoJTGF0ZW5jeTogMCwgQ2FjaGUgTGluZSBTaXplOiA2
NCBieXRlcw0KCUludGVycnVwdDogcGluIEIgcm91dGVkIHRvIElSUSAyOQ0KCVJlZ2lvbiAw
OiBNZW1vcnkgYXQgZjlmZmEwMDAgKDMyLWJpdCwgbm9uLXByZWZldGNoYWJsZSkgW3NpemU9
NEtdDQoJQ2FwYWJpbGl0aWVzOiBbNTBdIE1TSTogRW5hYmxlLSBDb3VudD0xLzEgTWFza2Fi
bGUtIDY0Yml0Kw0KCQlBZGRyZXNzOiAwMDAwMDAwMDAwMDAwMDAwICBEYXRhOiAwMDAwDQoJ
Q2FwYWJpbGl0aWVzOiBbNzhdIFBvd2VyIE1hbmFnZW1lbnQgdmVyc2lvbiAzDQoJCUZsYWdz
OiBQTUVDbGstIERTSS0gRDErIEQyKyBBdXhDdXJyZW50PTM3NW1BIFBNRShEMCssRDErLEQy
KyxEM2hvdCssRDNjb2xkLSkNCgkJU3RhdHVzOiBEMCBOb1NvZnRSc3QrIFBNRS1FbmFibGUt
IERTZWw9MCBEU2NhbGU9MCBQTUUtDQoJQ2FwYWJpbGl0aWVzOiBbODBdIEV4cHJlc3MgKHYx
KSBFbmRwb2ludCwgTVNJIDAwDQoJCURldkNhcDoJTWF4UGF5bG9hZCAyNTYgYnl0ZXMsIFBo
YW50RnVuYyAwLCBMYXRlbmN5IEwwcyB1bmxpbWl0ZWQsIEwxIHVubGltaXRlZA0KCQkJRXh0
VGFnLSBBdHRuQnRuLSBBdHRuSW5kLSBQd3JJbmQtIFJCRSsgRkxSZXNldC0NCgkJRGV2Q3Rs
OglSZXBvcnQgZXJyb3JzOiBDb3JyZWN0YWJsZS0gTm9uLUZhdGFsLSBGYXRhbC0gVW5zdXBw
b3J0ZWQtDQoJCQlSbHhkT3JkLSBFeHRUYWctIFBoYW50RnVuYy0gQXV4UHdyLSBOb1Nub29w
Kw0KCQkJTWF4UGF5bG9hZCAxMjggYnl0ZXMsIE1heFJlYWRSZXEgNTEyIGJ5dGVzDQoJCURl
dlN0YToJQ29yckVyci0gVW5jb3JyRXJyLSBGYXRhbEVyci0gVW5zdXBwUmVxLSBBdXhQd3It
IFRyYW5zUGVuZC0NCgkJTG5rQ2FwOglQb3J0ICMxLCBTcGVlZCAyLjVHVC9zLCBXaWR0aCB4
MSwgQVNQTSB1bmtub3duLCBMYXRlbmN5IEwwIDw2NG5zLCBMMSB1bmxpbWl0ZWQNCgkJCUNs
b2NrUE0rIFN1cnByaXNlLSBMTEFjdFJlcC0gQndOb3QtDQoJCUxua0N0bDoJQVNQTSBEaXNh
YmxlZDsgUkNCIDY0IGJ5dGVzIERpc2FibGVkLSBSZXRyYWluLSBDb21tQ2xrLQ0KCQkJRXh0
U3luY2gtIENsb2NrUE0tIEF1dFdpZERpcy0gQldJbnQtIEF1dEJXSW50LQ0KCQlMbmtTdGE6
CVNwZWVkIDIuNUdUL3MsIFdpZHRoIHgxLCBUckVyci0gVHJhaW4tIFNsb3RDbGstIERMQWN0
aXZlLSBCV01nbXQtIEFCV01nbXQtDQoJS2VybmVsIGRyaXZlciBpbiB1c2U6IHBjaWJhY2sN
Cg0KMGE6MDAuMyBVU0IgY29udHJvbGxlciBbMGMwM106IE5ldE1vcyBUZWNobm9sb2d5IE1D
Uzk5OTAgUENJZSB0byA04oCQUG9ydCBVU0IgMi4wIEhvc3QgQ29udHJvbGxlciBbOTcxMDo5
OTkwXSAocHJvZy1pZiAyMCBbRUhDSV0pDQoJU3Vic3lzdGVtOiBEZXZpY2UgW2EwMDA6NDAw
MF0NCglDb250cm9sOiBJL08tIE1lbSsgQnVzTWFzdGVyKyBTcGVjQ3ljbGUtIE1lbVdJTlYt
IFZHQVNub29wLSBQYXJFcnItIFN0ZXBwaW5nLSBTRVJSLSBGYXN0QjJCLSBEaXNJTlR4LQ0K
CVN0YXR1czogQ2FwKyA2Nk1Iei0gVURGLSBGYXN0QjJCLSBQYXJFcnItIERFVlNFTD1mYXN0
ID5UQWJvcnQtIDxUQWJvcnQrIDxNQWJvcnQtID5TRVJSLSA8UEVSUi0gSU5UeC0NCglMYXRl
bmN5OiAwLCBDYWNoZSBMaW5lIFNpemU6IDY0IGJ5dGVzDQoJSW50ZXJydXB0OiBwaW4gQiBy
b3V0ZWQgdG8gSVJRIDI5DQoJUmVnaW9uIDA6IE1lbW9yeSBhdCBmOWZmYjAwMCAoMzItYml0
LCBub24tcHJlZmV0Y2hhYmxlKSBbc2l6ZT00S10NCglDYXBhYmlsaXRpZXM6IFs1MF0gTVNJ
OiBFbmFibGUtIENvdW50PTEvMSBNYXNrYWJsZS0gNjRiaXQrDQoJCUFkZHJlc3M6IDAwMDAw
MDAwMDAwMDAwMDAgIERhdGE6IDAwMDANCglDYXBhYmlsaXRpZXM6IFs3OF0gUG93ZXIgTWFu
YWdlbWVudCB2ZXJzaW9uIDMNCgkJRmxhZ3M6IFBNRUNsay0gRFNJLSBEMSsgRDIrIEF1eEN1
cnJlbnQ9Mzc1bUEgUE1FKEQwKyxEMSssRDIrLEQzaG90KyxEM2NvbGQtKQ0KCQlTdGF0dXM6
IEQwIE5vU29mdFJzdCsgUE1FLUVuYWJsZS0gRFNlbD0wIERTY2FsZT0wIFBNRS0NCglDYXBh
YmlsaXRpZXM6IFs4MF0gRXhwcmVzcyAodjEpIEVuZHBvaW50LCBNU0kgMDANCgkJRGV2Q2Fw
OglNYXhQYXlsb2FkIDI1NiBieXRlcywgUGhhbnRGdW5jIDAsIExhdGVuY3kgTDBzIHVubGlt
aXRlZCwgTDEgdW5saW1pdGVkDQoJCQlFeHRUYWctIEF0dG5CdG4tIEF0dG5JbmQtIFB3cklu
ZC0gUkJFKyBGTFJlc2V0LQ0KCQlEZXZDdGw6CVJlcG9ydCBlcnJvcnM6IENvcnJlY3RhYmxl
LSBOb24tRmF0YWwtIEZhdGFsLSBVbnN1cHBvcnRlZC0NCgkJCVJseGRPcmQtIEV4dFRhZy0g
UGhhbnRGdW5jLSBBdXhQd3ItIE5vU25vb3ArDQoJCQlNYXhQYXlsb2FkIDEyOCBieXRlcywg
TWF4UmVhZFJlcSA1MTIgYnl0ZXMNCgkJRGV2U3RhOglDb3JyRXJyLSBVbmNvcnJFcnItIEZh
dGFsRXJyLSBVbnN1cHBSZXEtIEF1eFB3ci0gVHJhbnNQZW5kLQ0KCQlMbmtDYXA6CVBvcnQg
IzEsIFNwZWVkIDIuNUdUL3MsIFdpZHRoIHgxLCBBU1BNIHVua25vd24sIExhdGVuY3kgTDAg
PDY0bnMsIEwxIHVubGltaXRlZA0KCQkJQ2xvY2tQTSsgU3VycHJpc2UtIExMQWN0UmVwLSBC
d05vdC0NCgkJTG5rQ3RsOglBU1BNIERpc2FibGVkOyBSQ0IgNjQgYnl0ZXMgRGlzYWJsZWQt
IFJldHJhaW4tIENvbW1DbGstDQoJCQlFeHRTeW5jaC0gQ2xvY2tQTS0gQXV0V2lkRGlzLSBC
V0ludC0gQXV0QldJbnQtDQoJCUxua1N0YToJU3BlZWQgMi41R1QvcywgV2lkdGggeDEsIFRy
RXJyLSBUcmFpbi0gU2xvdENsay0gRExBY3RpdmUtIEJXTWdtdC0gQUJXTWdtdC0NCglLZXJu
ZWwgZHJpdmVyIGluIHVzZTogcGNpYmFjaw0KDQowYTowMC40IFVTQiBjb250cm9sbGVyIFsw
YzAzXTogTmV0TW9zIFRlY2hub2xvZ3kgTUNTOTk5MCBQQ0llIHRvIDTigJBQb3J0IFVTQiAy
LjAgSG9zdCBDb250cm9sbGVyIFs5NzEwOjk5OTBdIChwcm9nLWlmIDEwIFtPSENJXSkNCglT
dWJzeXN0ZW06IERldmljZSBbYTAwMDo0MDAwXQ0KCUNvbnRyb2w6IEkvTy0gTWVtKyBCdXNN
YXN0ZXIrIFNwZWNDeWNsZS0gTWVtV0lOVi0gVkdBU25vb3AtIFBhckVyci0gU3RlcHBpbmct
IFNFUlItIEZhc3RCMkItIERpc0lOVHgtDQoJU3RhdHVzOiBDYXArIDY2TUh6LSBVREYtIEZh
c3RCMkItIFBhckVyci0gREVWU0VMPWZhc3QgPlRBYm9ydC0gPFRBYm9ydCsgPE1BYm9ydC0g
PlNFUlItIDxQRVJSLSBJTlR4LQ0KCUxhdGVuY3k6IDAsIENhY2hlIExpbmUgU2l6ZTogNjQg
Ynl0ZXMNCglJbnRlcnJ1cHQ6IHBpbiBDIHJvdXRlZCB0byBJUlEgMzANCglSZWdpb24gMDog
TWVtb3J5IGF0IGY5ZmZjMDAwICgzMi1iaXQsIG5vbi1wcmVmZXRjaGFibGUpIFtzaXplPTRL
XQ0KCUNhcGFiaWxpdGllczogWzUwXSBNU0k6IEVuYWJsZS0gQ291bnQ9MS8xIE1hc2thYmxl
LSA2NGJpdCsNCgkJQWRkcmVzczogMDAwMDAwMDAwMDAwMDAwMCAgRGF0YTogMDAwMA0KCUNh
cGFiaWxpdGllczogWzc4XSBQb3dlciBNYW5hZ2VtZW50IHZlcnNpb24gMw0KCQlGbGFnczog
UE1FQ2xrLSBEU0ktIEQxKyBEMisgQXV4Q3VycmVudD0zNzVtQSBQTUUoRDArLEQxKyxEMiss
RDNob3QrLEQzY29sZC0pDQoJCVN0YXR1czogRDAgTm9Tb2Z0UnN0KyBQTUUtRW5hYmxlLSBE
U2VsPTAgRFNjYWxlPTAgUE1FLQ0KCUNhcGFiaWxpdGllczogWzgwXSBFeHByZXNzICh2MSkg
RW5kcG9pbnQsIE1TSSAwMA0KCQlEZXZDYXA6CU1heFBheWxvYWQgMjU2IGJ5dGVzLCBQaGFu
dEZ1bmMgMCwgTGF0ZW5jeSBMMHMgdW5saW1pdGVkLCBMMSB1bmxpbWl0ZWQNCgkJCUV4dFRh
Zy0gQXR0bkJ0bi0gQXR0bkluZC0gUHdySW5kLSBSQkUrIEZMUmVzZXQtDQoJCURldkN0bDoJ
UmVwb3J0IGVycm9yczogQ29ycmVjdGFibGUtIE5vbi1GYXRhbC0gRmF0YWwtIFVuc3VwcG9y
dGVkLQ0KCQkJUmx4ZE9yZC0gRXh0VGFnLSBQaGFudEZ1bmMtIEF1eFB3ci0gTm9Tbm9vcCsN
CgkJCU1heFBheWxvYWQgMTI4IGJ5dGVzLCBNYXhSZWFkUmVxIDUxMiBieXRlcw0KCQlEZXZT
dGE6CUNvcnJFcnItIFVuY29yckVyci0gRmF0YWxFcnItIFVuc3VwcFJlcS0gQXV4UHdyLSBU
cmFuc1BlbmQtDQoJCUxua0NhcDoJUG9ydCAjMSwgU3BlZWQgMi41R1QvcywgV2lkdGggeDEs
IEFTUE0gdW5rbm93biwgTGF0ZW5jeSBMMCA8NjRucywgTDEgdW5saW1pdGVkDQoJCQlDbG9j
a1BNKyBTdXJwcmlzZS0gTExBY3RSZXAtIEJ3Tm90LQ0KCQlMbmtDdGw6CUFTUE0gRGlzYWJs
ZWQ7IFJDQiA2NCBieXRlcyBEaXNhYmxlZC0gUmV0cmFpbi0gQ29tbUNsay0NCgkJCUV4dFN5
bmNoLSBDbG9ja1BNLSBBdXRXaWREaXMtIEJXSW50LSBBdXRCV0ludC0NCgkJTG5rU3RhOglT
cGVlZCAyLjVHVC9zLCBXaWR0aCB4MSwgVHJFcnItIFRyYWluLSBTbG90Q2xrLSBETEFjdGl2
ZS0gQldNZ210LSBBQldNZ210LQ0KCUtlcm5lbCBkcml2ZXIgaW4gdXNlOiBwY2liYWNrDQoN
CjBhOjAwLjUgVVNCIGNvbnRyb2xsZXIgWzBjMDNdOiBOZXRNb3MgVGVjaG5vbG9neSBNQ1M5
OTkwIFBDSWUgdG8gNOKAkFBvcnQgVVNCIDIuMCBIb3N0IENvbnRyb2xsZXIgWzk3MTA6OTk5
MF0gKHByb2ctaWYgMjAgW0VIQ0ldKQ0KCVN1YnN5c3RlbTogRGV2aWNlIFthMDAwOjQwMDBd
DQoJQ29udHJvbDogSS9PLSBNZW0rIEJ1c01hc3RlcisgU3BlY0N5Y2xlLSBNZW1XSU5WLSBW
R0FTbm9vcC0gUGFyRXJyLSBTdGVwcGluZy0gU0VSUi0gRmFzdEIyQi0gRGlzSU5UeC0NCglT
dGF0dXM6IENhcCsgNjZNSHotIFVERi0gRmFzdEIyQi0gUGFyRXJyLSBERVZTRUw9ZmFzdCA+
VEFib3J0LSA8VEFib3J0KyA8TUFib3J0LSA+U0VSUi0gPFBFUlItIElOVHgtDQoJTGF0ZW5j
eTogMCwgQ2FjaGUgTGluZSBTaXplOiA2NCBieXRlcw0KCUludGVycnVwdDogcGluIEMgcm91
dGVkIHRvIElSUSAzMA0KCVJlZ2lvbiAwOiBNZW1vcnkgYXQgZjlmZmQwMDAgKDMyLWJpdCwg
bm9uLXByZWZldGNoYWJsZSkgW3NpemU9NEtdDQoJQ2FwYWJpbGl0aWVzOiBbNTBdIE1TSTog
RW5hYmxlLSBDb3VudD0xLzEgTWFza2FibGUtIDY0Yml0Kw0KCQlBZGRyZXNzOiAwMDAwMDAw
MDAwMDAwMDAwICBEYXRhOiAwMDAwDQoJQ2FwYWJpbGl0aWVzOiBbNzhdIFBvd2VyIE1hbmFn
ZW1lbnQgdmVyc2lvbiAzDQoJCUZsYWdzOiBQTUVDbGstIERTSS0gRDErIEQyKyBBdXhDdXJy
ZW50PTM3NW1BIFBNRShEMCssRDErLEQyKyxEM2hvdCssRDNjb2xkLSkNCgkJU3RhdHVzOiBE
MCBOb1NvZnRSc3QrIFBNRS1FbmFibGUtIERTZWw9MCBEU2NhbGU9MCBQTUUtDQoJQ2FwYWJp
bGl0aWVzOiBbODBdIEV4cHJlc3MgKHYxKSBFbmRwb2ludCwgTVNJIDAwDQoJCURldkNhcDoJ
TWF4UGF5bG9hZCAyNTYgYnl0ZXMsIFBoYW50RnVuYyAwLCBMYXRlbmN5IEwwcyB1bmxpbWl0
ZWQsIEwxIHVubGltaXRlZA0KCQkJRXh0VGFnLSBBdHRuQnRuLSBBdHRuSW5kLSBQd3JJbmQt
IFJCRSsgRkxSZXNldC0NCgkJRGV2Q3RsOglSZXBvcnQgZXJyb3JzOiBDb3JyZWN0YWJsZS0g
Tm9uLUZhdGFsLSBGYXRhbC0gVW5zdXBwb3J0ZWQtDQoJCQlSbHhkT3JkLSBFeHRUYWctIFBo
YW50RnVuYy0gQXV4UHdyLSBOb1Nub29wKw0KCQkJTWF4UGF5bG9hZCAxMjggYnl0ZXMsIE1h
eFJlYWRSZXEgNTEyIGJ5dGVzDQoJCURldlN0YToJQ29yckVyci0gVW5jb3JyRXJyLSBGYXRh
bEVyci0gVW5zdXBwUmVxLSBBdXhQd3ItIFRyYW5zUGVuZC0NCgkJTG5rQ2FwOglQb3J0ICMx
LCBTcGVlZCAyLjVHVC9zLCBXaWR0aCB4MSwgQVNQTSB1bmtub3duLCBMYXRlbmN5IEwwIDw2
NG5zLCBMMSB1bmxpbWl0ZWQNCgkJCUNsb2NrUE0rIFN1cnByaXNlLSBMTEFjdFJlcC0gQndO
b3QtDQoJCUxua0N0bDoJQVNQTSBEaXNhYmxlZDsgUkNCIDY0IGJ5dGVzIERpc2FibGVkLSBS
ZXRyYWluLSBDb21tQ2xrLQ0KCQkJRXh0U3luY2gtIENsb2NrUE0tIEF1dFdpZERpcy0gQldJ
bnQtIEF1dEJXSW50LQ0KCQlMbmtTdGE6CVNwZWVkIDIuNUdUL3MsIFdpZHRoIHgxLCBUckVy
ci0gVHJhaW4tIFNsb3RDbGstIERMQWN0aXZlLSBCV01nbXQtIEFCV01nbXQtDQoJS2VybmVs
IGRyaXZlciBpbiB1c2U6IHBjaWJhY2sNCg0KMGE6MDAuNiBVU0IgY29udHJvbGxlciBbMGMw
M106IE5ldE1vcyBUZWNobm9sb2d5IE1DUzk5OTAgUENJZSB0byA04oCQUG9ydCBVU0IgMi4w
IEhvc3QgQ29udHJvbGxlciBbOTcxMDo5OTkwXSAocHJvZy1pZiAxMCBbT0hDSV0pDQoJU3Vi
c3lzdGVtOiBEZXZpY2UgW2EwMDA6NDAwMF0NCglDb250cm9sOiBJL08tIE1lbSsgQnVzTWFz
dGVyKyBTcGVjQ3ljbGUtIE1lbVdJTlYtIFZHQVNub29wLSBQYXJFcnItIFN0ZXBwaW5nLSBT
RVJSLSBGYXN0QjJCLSBEaXNJTlR4LQ0KCVN0YXR1czogQ2FwKyA2Nk1Iei0gVURGLSBGYXN0
QjJCLSBQYXJFcnItIERFVlNFTD1mYXN0ID5UQWJvcnQtIDxUQWJvcnQrIDxNQWJvcnQtID5T
RVJSLSA8UEVSUi0gSU5UeC0NCglMYXRlbmN5OiAwLCBDYWNoZSBMaW5lIFNpemU6IDY0IGJ5
dGVzDQoJSW50ZXJydXB0OiBwaW4gRCByb3V0ZWQgdG8gSVJRIDMxDQoJUmVnaW9uIDA6IE1l
bW9yeSBhdCBmOWZmZTAwMCAoMzItYml0LCBub24tcHJlZmV0Y2hhYmxlKSBbc2l6ZT00S10N
CglDYXBhYmlsaXRpZXM6IFs1MF0gTVNJOiBFbmFibGUtIENvdW50PTEvMSBNYXNrYWJsZS0g
NjRiaXQrDQoJCUFkZHJlc3M6IDAwMDAwMDAwMDAwMDAwMDAgIERhdGE6IDAwMDANCglDYXBh
YmlsaXRpZXM6IFs3OF0gUG93ZXIgTWFuYWdlbWVudCB2ZXJzaW9uIDMNCgkJRmxhZ3M6IFBN
RUNsay0gRFNJLSBEMSsgRDIrIEF1eEN1cnJlbnQ9Mzc1bUEgUE1FKEQwKyxEMSssRDIrLEQz
aG90KyxEM2NvbGQtKQ0KCQlTdGF0dXM6IEQwIE5vU29mdFJzdCsgUE1FLUVuYWJsZS0gRFNl
bD0wIERTY2FsZT0wIFBNRS0NCglDYXBhYmlsaXRpZXM6IFs4MF0gRXhwcmVzcyAodjEpIEVu
ZHBvaW50LCBNU0kgMDANCgkJRGV2Q2FwOglNYXhQYXlsb2FkIDI1NiBieXRlcywgUGhhbnRG
dW5jIDAsIExhdGVuY3kgTDBzIHVubGltaXRlZCwgTDEgdW5saW1pdGVkDQoJCQlFeHRUYWct
IEF0dG5CdG4tIEF0dG5JbmQtIFB3ckluZC0gUkJFKyBGTFJlc2V0LQ0KCQlEZXZDdGw6CVJl
cG9ydCBlcnJvcnM6IENvcnJlY3RhYmxlLSBOb24tRmF0YWwtIEZhdGFsLSBVbnN1cHBvcnRl
ZC0NCgkJCVJseGRPcmQtIEV4dFRhZy0gUGhhbnRGdW5jLSBBdXhQd3ItIE5vU25vb3ArDQoJ
CQlNYXhQYXlsb2FkIDEyOCBieXRlcywgTWF4UmVhZFJlcSA1MTIgYnl0ZXMNCgkJRGV2U3Rh
OglDb3JyRXJyLSBVbmNvcnJFcnItIEZhdGFsRXJyLSBVbnN1cHBSZXEtIEF1eFB3ci0gVHJh
bnNQZW5kLQ0KCQlMbmtDYXA6CVBvcnQgIzEsIFNwZWVkIDIuNUdUL3MsIFdpZHRoIHgxLCBB
U1BNIHVua25vd24sIExhdGVuY3kgTDAgPDY0bnMsIEwxIHVubGltaXRlZA0KCQkJQ2xvY2tQ
TSsgU3VycHJpc2UtIExMQWN0UmVwLSBCd05vdC0NCgkJTG5rQ3RsOglBU1BNIERpc2FibGVk
OyBSQ0IgNjQgYnl0ZXMgRGlzYWJsZWQtIFJldHJhaW4tIENvbW1DbGstDQoJCQlFeHRTeW5j
aC0gQ2xvY2tQTS0gQXV0V2lkRGlzLSBCV0ludC0gQXV0QldJbnQtDQoJCUxua1N0YToJU3Bl
ZWQgMi41R1QvcywgV2lkdGggeDEsIFRyRXJyLSBUcmFpbi0gU2xvdENsay0gRExBY3RpdmUt
IEJXTWdtdC0gQUJXTWdtdC0NCglLZXJuZWwgZHJpdmVyIGluIHVzZTogcGNpYmFjaw0KDQow
YTowMC43IFVTQiBjb250cm9sbGVyIFswYzAzXTogTmV0TW9zIFRlY2hub2xvZ3kgTUNTOTk5
MCBQQ0llIHRvIDTigJBQb3J0IFVTQiAyLjAgSG9zdCBDb250cm9sbGVyIFs5NzEwOjk5OTBd
IChwcm9nLWlmIDIwIFtFSENJXSkNCglTdWJzeXN0ZW06IERldmljZSBbYTAwMDo0MDAwXQ0K
CUNvbnRyb2w6IEkvTy0gTWVtKyBCdXNNYXN0ZXIrIFNwZWNDeWNsZS0gTWVtV0lOVi0gVkdB
U25vb3AtIFBhckVyci0gU3RlcHBpbmctIFNFUlItIEZhc3RCMkItIERpc0lOVHgtDQoJU3Rh
dHVzOiBDYXArIDY2TUh6LSBVREYtIEZhc3RCMkItIFBhckVyci0gREVWU0VMPWZhc3QgPlRB
Ym9ydC0gPFRBYm9ydCsgPE1BYm9ydC0gPlNFUlItIDxQRVJSLSBJTlR4LQ0KCUxhdGVuY3k6
IDAsIENhY2hlIExpbmUgU2l6ZTogNjQgYnl0ZXMNCglJbnRlcnJ1cHQ6IHBpbiBEIHJvdXRl
ZCB0byBJUlEgMzENCglSZWdpb24gMDogTWVtb3J5IGF0IGY5ZmZmMDAwICgzMi1iaXQsIG5v
bi1wcmVmZXRjaGFibGUpIFtzaXplPTRLXQ0KCUNhcGFiaWxpdGllczogWzUwXSBNU0k6IEVu
YWJsZS0gQ291bnQ9MS8xIE1hc2thYmxlLSA2NGJpdCsNCgkJQWRkcmVzczogMDAwMDAwMDAw
MDAwMDAwMCAgRGF0YTogMDAwMA0KCUNhcGFiaWxpdGllczogWzc4XSBQb3dlciBNYW5hZ2Vt
ZW50IHZlcnNpb24gMw0KCQlGbGFnczogUE1FQ2xrLSBEU0ktIEQxKyBEMisgQXV4Q3VycmVu
dD0zNzVtQSBQTUUoRDArLEQxKyxEMissRDNob3QrLEQzY29sZC0pDQoJCVN0YXR1czogRDAg
Tm9Tb2Z0UnN0KyBQTUUtRW5hYmxlLSBEU2VsPTAgRFNjYWxlPTAgUE1FLQ0KCUNhcGFiaWxp
dGllczogWzgwXSBFeHByZXNzICh2MSkgRW5kcG9pbnQsIE1TSSAwMA0KCQlEZXZDYXA6CU1h
eFBheWxvYWQgMjU2IGJ5dGVzLCBQaGFudEZ1bmMgMCwgTGF0ZW5jeSBMMHMgdW5saW1pdGVk
LCBMMSB1bmxpbWl0ZWQNCgkJCUV4dFRhZy0gQXR0bkJ0bi0gQXR0bkluZC0gUHdySW5kLSBS
QkUrIEZMUmVzZXQtDQoJCURldkN0bDoJUmVwb3J0IGVycm9yczogQ29ycmVjdGFibGUtIE5v
bi1GYXRhbC0gRmF0YWwtIFVuc3VwcG9ydGVkLQ0KCQkJUmx4ZE9yZC0gRXh0VGFnLSBQaGFu
dEZ1bmMtIEF1eFB3ci0gTm9Tbm9vcCsNCgkJCU1heFBheWxvYWQgMTI4IGJ5dGVzLCBNYXhS
ZWFkUmVxIDUxMiBieXRlcw0KCQlEZXZTdGE6CUNvcnJFcnItIFVuY29yckVyci0gRmF0YWxF
cnItIFVuc3VwcFJlcS0gQXV4UHdyLSBUcmFuc1BlbmQtDQoJCUxua0NhcDoJUG9ydCAjMSwg
U3BlZWQgMi41R1QvcywgV2lkdGggeDEsIEFTUE0gdW5rbm93biwgTGF0ZW5jeSBMMCA8NjRu
cywgTDEgdW5saW1pdGVkDQoJCQlDbG9ja1BNKyBTdXJwcmlzZS0gTExBY3RSZXAtIEJ3Tm90
LQ0KCQlMbmtDdGw6CUFTUE0gRGlzYWJsZWQ7IFJDQiA2NCBieXRlcyBEaXNhYmxlZC0gUmV0
cmFpbi0gQ29tbUNsay0NCgkJCUV4dFN5bmNoLSBDbG9ja1BNLSBBdXRXaWREaXMtIEJXSW50
LSBBdXRCV0ludC0NCgkJTG5rU3RhOglTcGVlZCAyLjVHVC9zLCBXaWR0aCB4MSwgVHJFcnIt
IFRyYWluLSBTbG90Q2xrLSBETEFjdGl2ZS0gQldNZ210LSBBQldNZ210LQ0KCUtlcm5lbCBk
cml2ZXIgaW4gdXNlOiBwY2liYWNrDQoNCjBiOjAwLjAgVkdBIGNvbXBhdGlibGUgY29udHJv
bGxlciBbMDMwMF06IG5WaWRpYSBDb3Jwb3JhdGlvbiBHOTggW0dlRm9yY2UgODQwMCBHU10g
WzEwZGU6MDZlNF0gKHJldiBhMSkgKHByb2ctaWYgMDAgW1ZHQSBjb250cm9sbGVyXSkNCglT
dWJzeXN0ZW06IEFTVVNUZUsgQ29tcHV0ZXIgSW5jLiBEZXZpY2UgWzEwNDM6ODI2Nl0NCglD
b250cm9sOiBJL08rIE1lbSsgQnVzTWFzdGVyKyBTcGVjQ3ljbGUtIE1lbVdJTlYtIFZHQVNu
b29wLSBQYXJFcnItIFN0ZXBwaW5nLSBTRVJSKyBGYXN0QjJCLSBEaXNJTlR4LQ0KCVN0YXR1
czogQ2FwKyA2Nk1Iei0gVURGLSBGYXN0QjJCLSBQYXJFcnItIERFVlNFTD1mYXN0ID5UQWJv
cnQtIDxUQWJvcnQtIDxNQWJvcnQtID5TRVJSLSA8UEVSUi0gSU5UeC0NCglMYXRlbmN5OiAw
LCBDYWNoZSBMaW5lIFNpemU6IDY0IGJ5dGVzDQoJSW50ZXJydXB0OiBwaW4gQSByb3V0ZWQg
dG8gSVJRIDEwDQoJUmVnaW9uIDA6IE1lbW9yeSBhdCBmZDAwMDAwMCAoMzItYml0LCBub24t
cHJlZmV0Y2hhYmxlKSBbc2l6ZT0xNk1dDQoJUmVnaW9uIDE6IE1lbW9yeSBhdCBkMDAwMDAw
MCAoNjQtYml0LCBwcmVmZXRjaGFibGUpIFtzaXplPTI1Nk1dDQoJUmVnaW9uIDM6IE1lbW9y
eSBhdCBmYTAwMDAwMCAoNjQtYml0LCBub24tcHJlZmV0Y2hhYmxlKSBbc2l6ZT0zMk1dDQoJ
UmVnaW9uIDU6IEkvTyBwb3J0cyBhdCBlODAwIFtzaXplPTEyOF0NCglFeHBhbnNpb24gUk9N
IGF0IGZlOWUwMDAwIFtkaXNhYmxlZF0gW3NpemU9MTI4S10NCglDYXBhYmlsaXRpZXM6IFs2
MF0gUG93ZXIgTWFuYWdlbWVudCB2ZXJzaW9uIDMNCgkJRmxhZ3M6IFBNRUNsay0gRFNJLSBE
MS0gRDItIEF1eEN1cnJlbnQ9MG1BIFBNRShEMC0sRDEtLEQyLSxEM2hvdC0sRDNjb2xkLSkN
CgkJU3RhdHVzOiBEMCBOb1NvZnRSc3QrIFBNRS1FbmFibGUtIERTZWw9MCBEU2NhbGU9MCBQ
TUUtDQoJQ2FwYWJpbGl0aWVzOiBbNjhdIE1TSTogRW5hYmxlLSBDb3VudD0xLzEgTWFza2Fi
bGUtIDY0Yml0Kw0KCQlBZGRyZXNzOiAwMDAwMDAwMDAwMDAwMDAwICBEYXRhOiAwMDAwDQoJ
Q2FwYWJpbGl0aWVzOiBbNzhdIEV4cHJlc3MgKHYxKSBFbmRwb2ludCwgTVNJIDAwDQoJCURl
dkNhcDoJTWF4UGF5bG9hZCAxMjggYnl0ZXMsIFBoYW50RnVuYyAwLCBMYXRlbmN5IEwwcyA8
NTEybnMsIEwxIDw0dXMNCgkJCUV4dFRhZysgQXR0bkJ0bi0gQXR0bkluZC0gUHdySW5kLSBS
QkUrIEZMUmVzZXQtDQoJCURldkN0bDoJUmVwb3J0IGVycm9yczogQ29ycmVjdGFibGUtIE5v
bi1GYXRhbC0gRmF0YWwtIFVuc3VwcG9ydGVkLQ0KCQkJUmx4ZE9yZC0gRXh0VGFnLSBQaGFu
dEZ1bmMtIEF1eFB3ci0gTm9Tbm9vcCsNCgkJCU1heFBheWxvYWQgMTI4IGJ5dGVzLCBNYXhS
ZWFkUmVxIDUxMiBieXRlcw0KCQlEZXZTdGE6CUNvcnJFcnItIFVuY29yckVyci0gRmF0YWxF
cnItIFVuc3VwcFJlcS0gQXV4UHdyLSBUcmFuc1BlbmQtDQoJCUxua0NhcDoJUG9ydCAjMCwg
U3BlZWQgMi41R1QvcywgV2lkdGggeDE2LCBBU1BNIEwwcyBMMSwgTGF0ZW5jeSBMMCA8NTEy
bnMsIEwxIDwxdXMNCgkJCUNsb2NrUE0tIFN1cnByaXNlLSBMTEFjdFJlcC0gQndOb3QtDQoJ
CUxua0N0bDoJQVNQTSBEaXNhYmxlZDsgUkNCIDEyOCBieXRlcyBEaXNhYmxlZC0gUmV0cmFp
bi0gQ29tbUNsaysNCgkJCUV4dFN5bmNoLSBDbG9ja1BNLSBBdXRXaWREaXMtIEJXSW50LSBB
dXRCV0ludC0NCgkJTG5rU3RhOglTcGVlZCAyLjVHVC9zLCBXaWR0aCB4OCwgVHJFcnItIFRy
YWluLSBTbG90Q2xrKyBETEFjdGl2ZS0gQldNZ210LSBBQldNZ210LQ0KCUNhcGFiaWxpdGll
czogWzEwMCB2MV0gVmlydHVhbCBDaGFubmVsDQoJCUNhcHM6CUxQRVZDPTAgUmVmQ2xrPTEw
MG5zIFBBVEVudHJ5Qml0cz0xDQoJCUFyYjoJRml4ZWQtIFdSUjMyLSBXUlI2NC0gV1JSMTI4
LQ0KCQlDdHJsOglBcmJTZWxlY3Q9Rml4ZWQNCgkJU3RhdHVzOglJblByb2dyZXNzLQ0KCQlW
QzA6CUNhcHM6CVBBVE9mZnNldD0wMCBNYXhUaW1lU2xvdHM9MSBSZWpTbm9vcFRyYW5zLQ0K
CQkJQXJiOglGaXhlZC0gV1JSMzItIFdSUjY0LSBXUlIxMjgtIFRXUlIxMjgtIFdSUjI1Ni0N
CgkJCUN0cmw6CUVuYWJsZSsgSUQ9MCBBcmJTZWxlY3Q9Rml4ZWQgVEMvVkM9ZmYNCgkJCVN0
YXR1czoJTmVnb1BlbmRpbmctIEluUHJvZ3Jlc3MtDQoJQ2FwYWJpbGl0aWVzOiBbMTI4IHYx
XSBQb3dlciBCdWRnZXRpbmcgPD8+DQoJQ2FwYWJpbGl0aWVzOiBbNjAwIHYxXSBWZW5kb3Ig
U3BlY2lmaWMgSW5mb3JtYXRpb246IElEPTAwMDEgUmV2PTEgTGVuPTAyNCA8Pz4NCg0K
------------0E902503E1C6BF83E
Content-Type: text/plain;
 name="xl-dmesg-4.2.txt"
Content-transfer-encoding: base64
Content-Disposition: attachment;
 filename="xl-dmesg-4.2.txt"

IF9fICBfXyAgICAgICAgICAgIF8gIF8gICAgX19fXyAgICBfX18gICAgICAgICAgICAgIF8g
IF8gICAgICAgICAgICAgICAgICAgICANCiBcIFwvIC9fX18gXyBfXyAgIHwgfHwgfCAgfF9f
XyBcICAvIF8gXCAgICBfIF9fIF9fX3wgfHwgfCAgICAgXyBfXyAgXyBfXyBfX18gDQogIFwg
IC8vIF8gXCAnXyBcICB8IHx8IHxfICAgX18pIHx8IHwgfCB8X198ICdfXy8gX198IHx8IHxf
IF9ffCAnXyBcfCAnX18vIF8gXA0KICAvICBcICBfXy8gfCB8IHwgfF9fICAgX3wgLyBfXy8g
fCB8X3wgfF9ffCB8IHwgKF9ffF9fICAgX3xfX3wgfF8pIHwgfCB8ICBfXy8NCiAvXy9cX1xf
X198X3wgfF98ICAgIHxffChfKV9fX19fKF8pX19fLyAgIHxffCAgXF9fX3wgIHxffCAgICB8
IC5fXy98X3wgIFxfX198DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgfF98ICAgICAgICAgICAgIA0KKFhFTikgWGVuIHZl
cnNpb24gNC4yLjAtcmM0LXByZSAocm9vdEBkeW5kbnMub3JnKSAoZ2NjIChEZWJpYW4gNC40
LjUtOCkgNC40LjUpIFdlZCBTZXAgIDUgMTc6MjY6NDAgQ0VTVCAyMDEyDQooWEVOKSBMYXRl
c3QgQ2hhbmdlU2V0OiBUdWUgQXVnIDI4IDIyOjQwOjQ1IDIwMTIgKzAxMDAgMjU3ODY6YTBi
NWY4MTAyYTAwDQooWEVOKSBCb290bG9hZGVyOiBHUlVCIDEuOTgrMjAxMDA4MDQtMTQrc3F1
ZWV6ZTENCihYRU4pIENvbW1hbmQgbGluZTogZG9tMF9tZW09MTAyNE0sbWF4OjEwMjRNIGxv
Z2x2bD1hbGwgbG9nbHZsX2d1ZXN0PWFsbCBjb25zb2xlX3RpbWVzdGFtcHMgdmdhPWdmeC0x
MjgweDEwMjR4MzIgY3B1aWRsZSBjcHVmcmVxPXhlbiBub3JlYm9vdCBkZWJ1ZyBsYXBpYz1k
ZWJ1ZyBhcGljX3ZlcmJvc2l0eT1kZWJ1ZyBhcGljPWRlYnVnIGlvbW11PW9uLHZlcmJvc2Us
ZGVidWcgY29tMT0zODQwMCw4bjEgY29uc29sZT12Z2EsY29tMQ0KKFhFTikgVmlkZW8gaW5m
b3JtYXRpb246DQooWEVOKSAgVkdBIGlzIGdyYXBoaWNzIG1vZGUgMTI4MHgxMDI0LCAzMiBi
cHANCihYRU4pICBWQkUvRERDIG1ldGhvZHM6IFYyOyBFRElEIHRyYW5zZmVyIHRpbWU6IDEg
c2Vjb25kcw0KKFhFTikgRGlzYyBpbmZvcm1hdGlvbjoNCihYRU4pICBGb3VuZCAyIE1CUiBz
aWduYXR1cmVzDQooWEVOKSAgRm91bmQgMiBFREQgaW5mb3JtYXRpb24gc3RydWN0dXJlcw0K
KFhFTikgWGVuLWU4MjAgUkFNIG1hcDoNCihYRU4pICAwMDAwMDAwMDAwMDAwMDAwIC0gMDAw
MDAwMDAwMDA5YjAwMCAodXNhYmxlKQ0KKFhFTikgIDAwMDAwMDAwMDAwOWIwMDAgLSAwMDAw
MDAwMDAwMGEwMDAwIChyZXNlcnZlZCkNCihYRU4pICAwMDAwMDAwMDAwMGU0MDAwIC0gMDAw
MDAwMDAwMDEwMDAwMCAocmVzZXJ2ZWQpDQooWEVOKSAgMDAwMDAwMDAwMDEwMDAwMCAtIDAw
MDAwMDAwYWZlOTAwMDAgKHVzYWJsZSkNCihYRU4pICAwMDAwMDAwMGFmZTkwMDAwIC0gMDAw
MDAwMDBhZmU5ZTAwMCAoQUNQSSBkYXRhKQ0KKFhFTikgIDAwMDAwMDAwYWZlOWUwMDAgLSAw
MDAwMDAwMGFmZWUwMDAwIChBQ1BJIE5WUykNCihYRU4pICAwMDAwMDAwMGFmZWUwMDAwIC0g
MDAwMDAwMDBhZmYwMDAwMCAocmVzZXJ2ZWQpDQooWEVOKSAgMDAwMDAwMDBmZmUwMDAwMCAt
IDAwMDAwMDAxMDAwMDAwMDAgKHJlc2VydmVkKQ0KKFhFTikgIDAwMDAwMDAxMDAwMDAwMDAg
LSAwMDAwMDAwMjUwMDAwMDAwICh1c2FibGUpDQooWEVOKSBBQ1BJOiBSU0RQIDAwMEZCMTIw
LCAwMDE0IChyMCBBQ1BJQU0pDQooWEVOKSBBQ1BJOiBSU0RUIEFGRTkwMDAwLCAwMDQ4IChy
MSBNU0kgICAgT0VNU0xJQyAgMjAxMDA2MjIgTVNGVCAgICAgICA5NykNCihYRU4pIEFDUEk6
IEZBQ1AgQUZFOTAyMDAsIDAwODQgKHIxIDc2NDBNUyBBNzY0MDEwMCAyMDEwMDYyMiBNU0ZU
ICAgICAgIDk3KQ0KKFhFTikgQUNQSTogRFNEVCBBRkU5MDVFMCwgOTQ0OSAocjEgIEE3NjQw
IEE3NjQwMTAwICAgICAgMTAwIElOVEwgMjAwNTExMTcpDQooWEVOKSBBQ1BJOiBGQUNTIEFG
RTlFMDAwLCAwMDQwDQooWEVOKSBBQ1BJOiBBUElDIEFGRTkwMzkwLCAwMDg4IChyMSA3NjQw
TVMgQTc2NDAxMDAgMjAxMDA2MjIgTVNGVCAgICAgICA5NykNCihYRU4pIEFDUEk6IE1DRkcg
QUZFOTA0MjAsIDAwM0MgKHIxIDc2NDBNUyBPRU1NQ0ZHICAyMDEwMDYyMiBNU0ZUICAgICAg
IDk3KQ0KKFhFTikgQUNQSTogU0xJQyBBRkU5MDQ2MCwgMDE3NiAocjEgTVNJICAgIE9FTVNM
SUMgIDIwMTAwNjIyIE1TRlQgICAgICAgOTcpDQooWEVOKSBBQ1BJOiBPRU1CIEFGRTlFMDQw
LCAwMDcyIChyMSA3NjQwTVMgQTc2NDAxMDAgMjAxMDA2MjIgTVNGVCAgICAgICA5NykNCihY
RU4pIEFDUEk6IFNSQVQgQUZFOUE1RTAsIDAxMDggKHIzIEFNRCAgICBGQU1fRl8xMCAgICAg
ICAgMiBBTUQgICAgICAgICAxKQ0KKFhFTikgQUNQSTogSFBFVCBBRkU5QTZGMCwgMDAzOCAo
cjEgNzY0ME1TIE9FTUhQRVQgIDIwMTAwNjIyIE1TRlQgICAgICAgOTcpDQooWEVOKSBBQ1BJ
OiBJVlJTIEFGRTlBNzMwLCAwMEY4IChyMSAgQU1EICAgICBSRDg5MFMgICAyMDIwMzEgQU1E
ICAgICAgICAgMCkNCihYRU4pIEFDUEk6IFNTRFQgQUZFOUE4MzAsIDBEQTQgKHIxIEEgTSBJ
ICBQT1dFUk5PVyAgICAgICAgMSBBTUQgICAgICAgICAxKQ0KKFhFTikgU3lzdGVtIFJBTTog
ODE5ME1CICg4Mzg2NzMya0IpDQooWEVOKSBTUkFUOiBQWE0gMCAtPiBBUElDIDAgLT4gTm9k
ZSAwDQooWEVOKSBTUkFUOiBQWE0gMCAtPiBBUElDIDEgLT4gTm9kZSAwDQooWEVOKSBTUkFU
OiBQWE0gMCAtPiBBUElDIDIgLT4gTm9kZSAwDQooWEVOKSBTUkFUOiBQWE0gMCAtPiBBUElD
IDMgLT4gTm9kZSAwDQooWEVOKSBTUkFUOiBQWE0gMCAtPiBBUElDIDQgLT4gTm9kZSAwDQoo
WEVOKSBTUkFUOiBQWE0gMCAtPiBBUElDIDUgLT4gTm9kZSAwDQooWEVOKSBTUkFUOiBOb2Rl
IDAgUFhNIDAgMC1hMDAwMA0KKFhFTikgU1JBVDogTm9kZSAwIFBYTSAwIDEwMDAwMC1iMDAw
MDAwMA0KKFhFTikgU1JBVDogTm9kZSAwIFBYTSAwIDEwMDAwMDAwMC0yNTAwMDAwMDANCihY
RU4pIE5VTUE6IEFsbG9jYXRlZCBtZW1ub2RlbWFwIGZyb20gMjRkOWE0MDAwIC0gMjRkOWE3
MDAwDQooWEVOKSBOVU1BOiBVc2luZyA4IGZvciB0aGUgaGFzaCBzaGlmdC4NCihYRU4pIERv
bWFpbiBoZWFwIGluaXRpYWxpc2VkDQooWEVOKSB2ZXNhZmI6IGZyYW1lYnVmZmVyIGF0IDB4
ZmIwMDAwMDAsIG1hcHBlZCB0byAweGZmZmY4MmMwMDAwMDAwMDAsIHVzaW5nIDYxNDRrLCB0
b3RhbCAxNDMzNmsNCihYRU4pIHZlc2FmYjogbW9kZSBpcyAxMjgweDEwMjR4MzIsIGxpbmVs
ZW5ndGg9NTEyMCwgZm9udCA4eDE2DQooWEVOKSB2ZXNhZmI6IFRydWVjb2xvcjogc2l6ZT04
Ojg6ODo4LCBzaGlmdD0yNDoxNjo4OjANCihYRU4pIGZvdW5kIFNNUCBNUC10YWJsZSBhdCAw
MDBmZjc4MA0KKFhFTikgRE1JIHByZXNlbnQuDQooWEVOKSBBUElDIGJvb3Qgc3RhdGUgaXMg
J3hhcGljJw0KKFhFTikgVXNpbmcgQVBJQyBkcml2ZXIgZGVmYXVsdA0KKFhFTikgQUNQSTog
UE0tVGltZXIgSU8gUG9ydDogMHg4MDgNCihYRU4pIEFDUEk6IEFDUEkgU0xFRVAgSU5GTzog
cG0xeF9jbnRbODA0LDBdLCBwbTF4X2V2dFs4MDAsMF0NCihYRU4pIEFDUEk6ICAgICAgICAg
ICAgICAgICAgd2FrZXVwX3ZlY1thZmU5ZTAwY10sIHZlY19zaXplWzIwXQ0KKFhFTikgQUNQ
STogTG9jYWwgQVBJQyBhZGRyZXNzIDB4ZmVlMDAwMDANCihYRU4pIEFDUEk6IExBUElDIChh
Y3BpX2lkWzB4MDFdIGxhcGljX2lkWzB4MDBdIGVuYWJsZWQpDQooWEVOKSBQcm9jZXNzb3Ig
IzAgMDoxMCBBUElDIHZlcnNpb24gMTYNCihYRU4pIEFDUEk6IExBUElDIChhY3BpX2lkWzB4
MDJdIGxhcGljX2lkWzB4MDFdIGVuYWJsZWQpDQooWEVOKSBQcm9jZXNzb3IgIzEgMDoxMCBB
UElDIHZlcnNpb24gMTYNCihYRU4pIEFDUEk6IExBUElDIChhY3BpX2lkWzB4MDNdIGxhcGlj
X2lkWzB4MDJdIGVuYWJsZWQpDQooWEVOKSBQcm9jZXNzb3IgIzIgMDoxMCBBUElDIHZlcnNp
b24gMTYNCihYRU4pIEFDUEk6IExBUElDIChhY3BpX2lkWzB4MDRdIGxhcGljX2lkWzB4MDNd
IGVuYWJsZWQpDQooWEVOKSBQcm9jZXNzb3IgIzMgMDoxMCBBUElDIHZlcnNpb24gMTYNCihY
RU4pIEFDUEk6IExBUElDIChhY3BpX2lkWzB4MDVdIGxhcGljX2lkWzB4MDRdIGVuYWJsZWQp
DQooWEVOKSBQcm9jZXNzb3IgIzQgMDoxMCBBUElDIHZlcnNpb24gMTYNCihYRU4pIEFDUEk6
IExBUElDIChhY3BpX2lkWzB4MDZdIGxhcGljX2lkWzB4MDVdIGVuYWJsZWQpDQooWEVOKSBQ
cm9jZXNzb3IgIzUgMDoxMCBBUElDIHZlcnNpb24gMTYNCihYRU4pIEFDUEk6IElPQVBJQyAo
aWRbMHgwNl0gYWRkcmVzc1sweGZlYzAwMDAwXSBnc2lfYmFzZVswXSkNCihYRU4pIElPQVBJ
Q1swXTogYXBpY19pZCA2LCB2ZXJzaW9uIDMzLCBhZGRyZXNzIDB4ZmVjMDAwMDAsIEdTSSAw
LTIzDQooWEVOKSBBQ1BJOiBJT0FQSUMgKGlkWzB4MDddIGFkZHJlc3NbMHhmZWMyMDAwMF0g
Z3NpX2Jhc2VbMjRdKQ0KKFhFTikgSU9BUElDWzFdOiBhcGljX2lkIDcsIHZlcnNpb24gMzMs
IGFkZHJlc3MgMHhmZWMyMDAwMCwgR1NJIDI0LTU1DQooWEVOKSBBQ1BJOiBJTlRfU1JDX09W
UiAoYnVzIDAgYnVzX2lycSAwIGdsb2JhbF9pcnEgMiBkZmwgZGZsKQ0KKFhFTikgQUNQSTog
SU5UX1NSQ19PVlIgKGJ1cyAwIGJ1c19pcnEgOSBnbG9iYWxfaXJxIDkgbG93IGxldmVsKQ0K
KFhFTikgQUNQSTogSVJRMCB1c2VkIGJ5IG92ZXJyaWRlLg0KKFhFTikgQUNQSTogSVJRMiB1
c2VkIGJ5IG92ZXJyaWRlLg0KKFhFTikgQUNQSTogSVJROSB1c2VkIGJ5IG92ZXJyaWRlLg0K
KFhFTikgRW5hYmxpbmcgQVBJQyBtb2RlOiAgRmxhdC4gIFVzaW5nIDIgSS9PIEFQSUNzDQoo
WEVOKSBBQ1BJOiBIUEVUIGlkOiAweDgzMDAgYmFzZTogMHhmZWQwMDAwMA0KKFhFTikgVGFi
bGUgaXMgbm90IGZvdW5kIQ0KKFhFTikgVXNpbmcgQUNQSSAoTUFEVCkgZm9yIFNNUCBjb25m
aWd1cmF0aW9uIGluZm9ybWF0aW9uDQooWEVOKSBTTVA6IEFsbG93aW5nIDYgQ1BVcyAoMCBo
b3RwbHVnIENQVXMpDQooWEVOKSBtYXBwZWQgQVBJQyB0byBmZmZmODJjM2ZmZGZlMDAwIChm
ZWUwMDAwMCkNCihYRU4pIG1hcHBlZCBJT0FQSUMgdG8gZmZmZjgyYzNmZmRmZDAwMCAoZmVj
MDAwMDApDQooWEVOKSBtYXBwZWQgSU9BUElDIHRvIGZmZmY4MmMzZmZkZmMwMDAgKGZlYzIw
MDAwKQ0KKFhFTikgSVJRIGxpbWl0czogNTYgR1NJLCAxMTEyIE1TSS9NU0ktWA0KKFhFTikg
VXNpbmcgc2NoZWR1bGVyOiBTTVAgQ3JlZGl0IFNjaGVkdWxlciAoY3JlZGl0KQ0KKFhFTikg
RGV0ZWN0ZWQgMzIwMC4xNDQgTUh6IHByb2Nlc3Nvci4NCihYRU4pIEluaXRpbmcgbWVtb3J5
IHNoYXJpbmcuDQooWEVOKSBBTUQgRmFtMTBoIG1hY2hpbmUgY2hlY2sgcmVwb3J0aW5nIGVu
YWJsZWQNCihYRU4pIFBDSTogTUNGRyBjb25maWd1cmF0aW9uIDA6IGJhc2UgZTAwMDAwMDAg
c2VnbWVudCAwMDAwIGJ1c2VzIDAwIC0gZmYNCihYRU4pIFBDSTogTm90IHVzaW5nIE1DRkcg
Zm9yIHNlZ21lbnQgMDAwMCBidXMgMDAtZmYNCihYRU4pIEFNRC1WaTogRm91bmQgTVNJIGNh
cGFiaWxpdHkgYmxvY2sgYXQgMHg1NA0KKFhFTikgQU1ELVZpOiBBQ1BJIFRhYmxlOg0KKFhF
TikgQU1ELVZpOiAgU2lnbmF0dXJlIElWUlMNCihYRU4pIEFNRC1WaTogIExlbmd0aCAweGY4
DQooWEVOKSBBTUQtVmk6ICBSZXZpc2lvbiAweDENCihYRU4pIEFNRC1WaTogIENoZWNrU3Vt
IDB4NmUNCihYRU4pIEFNRC1WaTogIE9FTV9JZCBBTUQgIA0KKFhFTikgQU1ELVZpOiAgT0VN
X1RhYmxlX0lkIFJEODkwUw0KKFhFTikgQU1ELVZpOiAgT0VNX1JldmlzaW9uIDB4MjAyMDMx
DQooWEVOKSBBTUQtVmk6ICBDcmVhdG9yX0lkIEFNRCANCihYRU4pIEFNRC1WaTogIENyZWF0
b3JfUmV2aXNpb24gMHgwDQooWEVOKSBBTUQtVmk6IElWUlMgQmxvY2s6DQooWEVOKSBBTUQt
Vmk6ICBUeXBlIDB4MTANCihYRU4pIEFNRC1WaTogIEZsYWdzIDB4M2UNCihYRU4pIEFNRC1W
aTogIExlbmd0aCAweGM4DQooWEVOKSBBTUQtVmk6ICBEZXZfSWQgMHgyDQooWEVOKSBBTUQt
Vmk6IElWSEQgRGV2aWNlIEVudHJ5Og0KKFhFTikgQU1ELVZpOiAgVHlwZSAweDMNCihYRU4p
IEFNRC1WaTogIERldl9JZCAweDANCihYRU4pIEFNRC1WaTogIEZsYWdzIDB4MA0KKFhFTikg
QU1ELVZpOiAgRGV2X0lkIFJhbmdlOiAweDAgLT4gMHgyDQooWEVOKSBBTUQtVmk6IElWSEQg
RGV2aWNlIEVudHJ5Og0KKFhFTikgQU1ELVZpOiAgVHlwZSAweDINCihYRU4pIEFNRC1WaTog
IERldl9JZCAweDEwDQooWEVOKSBBTUQtVmk6ICBGbGFncyAweDANCihYRU4pIEFNRC1WaTog
SVZIRCBEZXZpY2UgRW50cnk6DQooWEVOKSBBTUQtVmk6ICBUeXBlIDB4Mg0KKFhFTikgQU1E
LVZpOiAgRGV2X0lkIDB4YjAwDQooWEVOKSBBTUQtVmk6ICBGbGFncyAweDANCihYRU4pIEFN
RC1WaTogSVZIRCBEZXZpY2UgRW50cnk6DQooWEVOKSBBTUQtVmk6ICBUeXBlIDB4Mg0KKFhF
TikgQU1ELVZpOiAgRGV2X0lkIDB4MTgNCihYRU4pIEFNRC1WaTogIEZsYWdzIDB4MA0KKFhF
TikgQU1ELVZpOiBJVkhEIERldmljZSBFbnRyeToNCihYRU4pIEFNRC1WaTogIFR5cGUgMHgz
DQooWEVOKSBBTUQtVmk6ICBEZXZfSWQgMHhhMDANCihYRU4pIEFNRC1WaTogIEZsYWdzIDB4
MA0KKFhFTikgQU1ELVZpOiAgRGV2X0lkIFJhbmdlOiAweGEwMCAtPiAweGEwNw0KKFhFTikg
QU1ELVZpOiBJVkhEIERldmljZSBFbnRyeToNCihYRU4pIEFNRC1WaTogIFR5cGUgMHgyDQoo
WEVOKSBBTUQtVmk6ICBEZXZfSWQgMHgyOA0KKFhFTikgQU1ELVZpOiAgRmxhZ3MgMHgwDQoo
WEVOKSBBTUQtVmk6IElWSEQgRGV2aWNlIEVudHJ5Og0KKFhFTikgQU1ELVZpOiAgVHlwZSAw
eDINCihYRU4pIEFNRC1WaTogIERldl9JZCAweDkwMA0KKFhFTikgQU1ELVZpOiAgRmxhZ3Mg
MHgwDQooWEVOKSBBTUQtVmk6IElWSEQgRGV2aWNlIEVudHJ5Og0KKFhFTikgQU1ELVZpOiAg
VHlwZSAweDINCihYRU4pIEFNRC1WaTogIERldl9JZCAweDMwDQooWEVOKSBBTUQtVmk6ICBG
bGFncyAweDANCihYRU4pIEFNRC1WaTogSVZIRCBEZXZpY2UgRW50cnk6DQooWEVOKSBBTUQt
Vmk6ICBUeXBlIDB4Mg0KKFhFTikgQU1ELVZpOiAgRGV2X0lkIDB4ODAwDQooWEVOKSBBTUQt
Vmk6ICBGbGFncyAweDANCihYRU4pIEFNRC1WaTogSVZIRCBEZXZpY2UgRW50cnk6DQooWEVO
KSBBTUQtVmk6ICBUeXBlIDB4Mg0KKFhFTikgQU1ELVZpOiAgRGV2X0lkIDB4NTANCihYRU4p
IEFNRC1WaTogIEZsYWdzIDB4MA0KKFhFTikgQU1ELVZpOiBJVkhEIERldmljZSBFbnRyeToN
CihYRU4pIEFNRC1WaTogIFR5cGUgMHgyDQooWEVOKSBBTUQtVmk6ICBEZXZfSWQgMHg3MDAN
CihYRU4pIEFNRC1WaTogIEZsYWdzIDB4MA0KKFhFTikgQU1ELVZpOiBJVkhEIERldmljZSBF
bnRyeToNCihYRU4pIEFNRC1WaTogIFR5cGUgMHgyDQooWEVOKSBBTUQtVmk6ICBEZXZfSWQg
MHg1OA0KKFhFTikgQU1ELVZpOiAgRmxhZ3MgMHgwDQooWEVOKSBBTUQtVmk6IElWSEQgRGV2
aWNlIEVudHJ5Og0KKFhFTikgQU1ELVZpOiAgVHlwZSAweDMNCihYRU4pIEFNRC1WaTogIERl
dl9JZCAweDYwMA0KKFhFTikgQU1ELVZpOiAgRmxhZ3MgMHgwDQooWEVOKSBBTUQtVmk6ICBE
ZXZfSWQgUmFuZ2U6IDB4NjAwIC0+IDB4NjAxDQooWEVOKSBBTUQtVmk6IElWSEQgRGV2aWNl
IEVudHJ5Og0KKFhFTikgQU1ELVZpOiAgVHlwZSAweDINCihYRU4pIEFNRC1WaTogIERldl9J
ZCAweDYwDQooWEVOKSBBTUQtVmk6ICBGbGFncyAweDANCihYRU4pIEFNRC1WaTogSVZIRCBE
ZXZpY2UgRW50cnk6DQooWEVOKSBBTUQtVmk6ICBUeXBlIDB4Mg0KKFhFTikgQU1ELVZpOiAg
RGV2X0lkIDB4NTAwDQooWEVOKSBBTUQtVmk6ICBGbGFncyAweDANCihYRU4pIEFNRC1WaTog
SVZIRCBEZXZpY2UgRW50cnk6DQooWEVOKSBBTUQtVmk6ICBUeXBlIDB4Mg0KKFhFTikgQU1E
LVZpOiAgRGV2X0lkIDB4NjgNCihYRU4pIEFNRC1WaTogIEZsYWdzIDB4MA0KKFhFTikgQU1E
LVZpOiBJVkhEIERldmljZSBFbnRyeToNCihYRU4pIEFNRC1WaTogIFR5cGUgMHgzDQooWEVO
KSBBTUQtVmk6ICBEZXZfSWQgMHg0MDANCihYRU4pIEFNRC1WaTogIEZsYWdzIDB4MA0KKFhF
TikgQU1ELVZpOiAgRGV2X0lkIFJhbmdlOiAweDQwMCAtPiAweDQwNw0KKFhFTikgQU1ELVZp
OiBJVkhEIERldmljZSBFbnRyeToNCihYRU4pIEFNRC1WaTogIFR5cGUgMHgyDQooWEVOKSBB
TUQtVmk6ICBEZXZfSWQgMHg4OA0KKFhFTikgQU1ELVZpOiAgRmxhZ3MgMHgwDQooWEVOKSBB
TUQtVmk6IElWSEQgRGV2aWNlIEVudHJ5Og0KKFhFTikgQU1ELVZpOiAgVHlwZSAweDMNCihY
RU4pIEFNRC1WaTogIERldl9JZCAweDkwDQooWEVOKSBBTUQtVmk6ICBGbGFncyAweDANCihY
RU4pIEFNRC1WaTogIERldl9JZCBSYW5nZTogMHg5MCAtPiAweDkyDQooWEVOKSBBTUQtVmk6
IElWSEQgRGV2aWNlIEVudHJ5Og0KKFhFTikgQU1ELVZpOiAgVHlwZSAweDMNCihYRU4pIEFN
RC1WaTogIERldl9JZCAweDk4DQooWEVOKSBBTUQtVmk6ICBGbGFncyAweDANCihYRU4pIEFN
RC1WaTogIERldl9JZCBSYW5nZTogMHg5OCAtPiAweDlhDQooWEVOKSBBTUQtVmk6IElWSEQg
RGV2aWNlIEVudHJ5Og0KKFhFTikgQU1ELVZpOiAgVHlwZSAweDINCihYRU4pIEFNRC1WaTog
IERldl9JZCAweGEwDQooWEVOKSBBTUQtVmk6ICBGbGFncyAweGQ3DQooWEVOKSBBTUQtVmk6
IElWSEQgRGV2aWNlIEVudHJ5Og0KKFhFTikgQU1ELVZpOiAgVHlwZSAweDINCihYRU4pIEFN
RC1WaTogIERldl9JZCAweGEzDQooWEVOKSBBTUQtVmk6ICBGbGFncyAweDANCihYRU4pIEFN
RC1WaTogSVZIRCBEZXZpY2UgRW50cnk6DQooWEVOKSBBTUQtVmk6ICBUeXBlIDB4Mg0KKFhF
TikgQU1ELVZpOiAgRGV2X0lkIDB4YTQNCihYRU4pIEFNRC1WaTogIEZsYWdzIDB4MA0KKFhF
TikgQU1ELVZpOiBJVkhEIERldmljZSBFbnRyeToNCihYRU4pIEFNRC1WaTogIFR5cGUgMHgw
DQooWEVOKSBBTUQtVmk6ICBEZXZfSWQgMHgwDQooWEVOKSBBTUQtVmk6ICBGbGFncyAweDAN
CihYRU4pIEFNRC1WaTogSVZIRCBEZXZpY2UgRW50cnk6DQooWEVOKSBBTUQtVmk6ICBUeXBl
IDB4NDMNCihYRU4pIEFNRC1WaTogIERldl9JZCAweDMwMA0KKFhFTikgQU1ELVZpOiAgRmxh
Z3MgMHgwDQooWEVOKSBBTUQtVmk6ICBEZXZfSWQgUmFuZ2U6IDB4MzAwIC0+IDB4M2ZmDQoo
WEVOKSBBTUQtVmk6ICBEZXZfSWQgQWxpYXM6IDB4YTQNCihYRU4pIEFNRC1WaTogSVZIRCBE
ZXZpY2UgRW50cnk6DQooWEVOKSBBTUQtVmk6ICBUeXBlIDB4Mg0KKFhFTikgQU1ELVZpOiAg
RGV2X0lkIDB4YTUNCihYRU4pIEFNRC1WaTogIEZsYWdzIDB4MA0KKFhFTikgQU1ELVZpOiBJ
VkhEIERldmljZSBFbnRyeToNCihYRU4pIEFNRC1WaTogIFR5cGUgMHgyDQooWEVOKSBBTUQt
Vmk6ICBEZXZfSWQgMHhhOA0KKFhFTikgQU1ELVZpOiAgRmxhZ3MgMHgwDQooWEVOKSBBTUQt
Vmk6IElWSEQgRGV2aWNlIEVudHJ5Og0KKFhFTikgQU1ELVZpOiAgVHlwZSAweDINCihYRU4p
IEFNRC1WaTogIERldl9JZCAweGE5DQooWEVOKSBBTUQtVmk6ICBGbGFncyAweDANCihYRU4p
IEFNRC1WaTogSVZIRCBEZXZpY2UgRW50cnk6DQooWEVOKSBBTUQtVmk6ICBUeXBlIDB4Mg0K
KFhFTikgQU1ELVZpOiAgRGV2X0lkIDB4MTAwDQooWEVOKSBzcHVyaW91cyA4MjU5QSBpbnRl
cnJ1cHQ6IElSUTcuDQooWEVOKSBBTUQtVmk6ICBGbGFncyAweDANCihYRU4pIEFNRC1WaTog
SVZIRCBEZXZpY2UgRW50cnk6DQooWEVOKSBBTUQtVmk6ICBUeXBlIDB4Mw0KKFhFTikgQU1E
LVZpOiAgRGV2X0lkIDB4YjANCihYRU4pIEFNRC1WaTogIEZsYWdzIDB4MA0KKFhFTikgQU1E
LVZpOiAgRGV2X0lkIFJhbmdlOiAweGIwIC0+IDB4YjINCihYRU4pIEFNRC1WaTogSVZIRCBE
ZXZpY2UgRW50cnk6DQooWEVOKSBBTUQtVmk6ICBUeXBlIDB4MA0KKFhFTikgQU1ELVZpOiAg
RGV2X0lkIDB4MA0KKFhFTikgQU1ELVZpOiAgRmxhZ3MgMHgwDQooWEVOKSBBTUQtVmk6IElW
SEQgRGV2aWNlIEVudHJ5Og0KKFhFTikgQU1ELVZpOiAgVHlwZSAweDQ4DQooWEVOKSBBTUQt
Vmk6ICBEZXZfSWQgMHgwDQooWEVOKSBBTUQtVmk6ICBGbGFncyAweGQ3DQooWEVOKSBBTUQt
Vmk6IElWSEQgRGV2aWNlIEVudHJ5Og0KKFhFTikgQU1ELVZpOiAgVHlwZSAweDQ4DQooWEVO
KSBBTUQtVmk6ICBEZXZfSWQgMHgwDQooWEVOKSBBTUQtVmk6ICBGbGFncyAweDANCihYRU4p
IEFNRC1WaTogSU9NTVUgMCBFbmFibGVkLg0KKFhFTikgQU1ELVZpOiBFbmFibGluZyBnbG9i
YWwgdmVjdG9yIG1hcA0KKFhFTikgSS9PIHZpcnR1YWxpc2F0aW9uIGVuYWJsZWQNCihYRU4p
ICAtIERvbTAgbW9kZTogUmVsYXhlZA0KKFhFTikgR2V0dGluZyBWRVJTSU9OOiA4MDA1MDAx
MA0KKFhFTikgR2V0dGluZyBWRVJTSU9OOiA4MDA1MDAxMA0KKFhFTikgR2V0dGluZyBJRDog
MA0KKFhFTikgR2V0dGluZyBMVlQwOiA3MDANCihYRU4pIEdldHRpbmcgTFZUMTogNDAwDQoo
WEVOKSBlbmFibGVkIEV4dElOVCBvbiBDUFUjMA0KKFhFTikgRVNSIHZhbHVlIGJlZm9yZSBl
bmFibGluZyB2ZWN0b3I6IDB4MDAwMDAwMDQgIGFmdGVyOiAweDAwMDAwMDAwDQooWEVOKSBF
TkFCTElORyBJTy1BUElDIElSUXMNCihYRU4pICAtPiBVc2luZyBuZXcgQUNLIG1ldGhvZA0K
KFhFTikgaW5pdCBJT19BUElDIElSUXMNCihYRU4pICBJTy1BUElDIChhcGljaWQtcGluKSA2
LTAsIDYtMTYsIDYtMTcsIDYtMTgsIDYtMTksIDYtMjAsIDYtMjEsIDYtMjIsIDYtMjMsIDct
MCwgNy0xLCA3LTIsIDctMywgNy00LCA3LTUsIDctNiwgNy03LCA3LTgsIDctOSwgNy0xMCwg
Ny0xMSwgNy0xMiwgNy0xMywgNy0xNCwgNy0xNSwgNy0xNiwgNy0xNywgNy0xOCwgNy0xOSwg
Ny0yMCwgNy0yMSwgNy0yMiwgNy0yMywgNy0yNCwgNy0yNSwgNy0yNiwgNy0yNywgNy0yOCwg
Ny0yOSwgNy0zMCwgNy0zMSBub3QgY29ubmVjdGVkLg0KKFhFTikgLi5USU1FUjogdmVjdG9y
PTB4RjAgYXBpYzE9MCBwaW4xPTIgYXBpYzI9LTEgcGluMj0tMQ0KKFhFTikgbnVtYmVyIG9m
IE1QIElSUSBzb3VyY2VzOiAxNS4NCihYRU4pIG51bWJlciBvZiBJTy1BUElDICM2IHJlZ2lz
dGVyczogMjQuDQooWEVOKSBudW1iZXIgb2YgSU8tQVBJQyAjNyByZWdpc3RlcnM6IDMyLg0K
KFhFTikgdGVzdGluZyB0aGUgSU8gQVBJQy4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uDQooWEVO
KSBJTyBBUElDICM2Li4uLi4uDQooWEVOKSAuLi4uIHJlZ2lzdGVyICMwMDogMDYwMDAwMDAN
CihYRU4pIC4uLi4uLi4gICAgOiBwaHlzaWNhbCBBUElDIGlkOiAwNg0KKFhFTikgLi4uLi4u
LiAgICA6IERlbGl2ZXJ5IFR5cGU6IDANCihYRU4pIC4uLi4uLi4gICAgOiBMVFMgICAgICAg
ICAgOiAwDQooWEVOKSAuLi4uIHJlZ2lzdGVyICMwMTogMDAxNzgwMjENCihYRU4pIC4uLi4u
Li4gICAgIDogbWF4IHJlZGlyZWN0aW9uIGVudHJpZXM6IDAwMTcNCihYRU4pIC4uLi4uLi4g
ICAgIDogUFJRIGltcGxlbWVudGVkOiAxDQooWEVOKSAuLi4uLi4uICAgICA6IElPIEFQSUMg
dmVyc2lvbjogMDAyMQ0KKFhFTikgLi4uLiByZWdpc3RlciAjMDI6IDA2MDAwMDAwDQooWEVO
KSAuLi4uLi4uICAgICA6IGFyYml0cmF0aW9uOiAwNg0KKFhFTikgLi4uLiByZWdpc3RlciAj
MDM6IDA3MDAwMDAwDQooWEVOKSAuLi4uLi4uICAgICA6IEJvb3QgRFQgICAgOiAwDQooWEVO
KSAuLi4uIElSUSByZWRpcmVjdGlvbiB0YWJsZToNCihYRU4pICBOUiBMb2cgUGh5IE1hc2sg
VHJpZyBJUlIgUG9sIFN0YXQgRGVzdCBEZWxpIFZlY3Q6ICAgDQooWEVOKSAgMDAgMDAwIDAw
ICAxICAgIDAgICAgMCAgIDAgICAwICAgIDAgICAgMCAgICAwMA0KKFhFTikgIDAxIDAwMSAw
MSAgMCAgICAwICAgIDAgICAwICAgMCAgICAxICAgIDEgICAgMzANCihYRU4pICAwMiAwMDEg
MDEgIDAgICAgMCAgICAwICAgMCAgIDAgICAgMSAgICAxICAgIEYwDQooWEVOKSAgMDMgMDAx
IDAxICAwICAgIDAgICAgMCAgIDAgICAwICAgIDEgICAgMSAgICAzOA0KKFhFTikgIDA0IDAw
MSAwMSAgMCAgICAwICAgIDAgICAwICAgMCAgICAxICAgIDEgICAgRjENCihYRU4pICAwNSAw
MDEgMDEgIDAgICAgMCAgICAwICAgMCAgIDAgICAgMSAgICAxICAgIDQwDQooWEVOKSAgMDYg
MDAxIDAxICAwICAgIDAgICAgMCAgIDAgICAwICAgIDEgICAgMSAgICA0OA0KKFhFTikgIDA3
IDAwMSAwMSAgMCAgICAwICAgIDAgICAwICAgMCAgICAxICAgIDEgICAgNTANCihYRU4pICAw
OCAwMDEgMDEgIDAgICAgMCAgICAwICAgMCAgIDAgICAgMSAgICAxICAgIDU4DQooWEVOKSAg
MDkgMDAxIDAxICAxICAgIDEgICAgMCAgIDEgICAwICAgIDEgICAgMSAgICA2MA0KKFhFTikg
IDBhIDAwMSAwMSAgMCAgICAwICAgIDAgICAwICAgMCAgICAxICAgIDEgICAgNjgNCihYRU4p
ICAwYiAwMDEgMDEgIDAgICAgMCAgICAwICAgMCAgIDAgICAgMSAgICAxICAgIDcwDQooWEVO
KSAgMGMgMDAxIDAxICAwICAgIDAgICAgMCAgIDAgICAwICAgIDEgICAgMSAgICA3OA0KKFhF
TikgIDBkIDAwMSAwMSAgMCAgICAwICAgIDAgICAwICAgMCAgICAxICAgIDEgICAgODgNCihY
RU4pICAwZSAwMDEgMDEgIDAgICAgMCAgICAwICAgMCAgIDAgICAgMSAgICAxICAgIDkwDQoo
WEVOKSAgMGYgMDAxIDAxICAwICAgIDAgICAgMCAgIDAgICAwICAgIDEgICAgMSAgICA5OA0K
KFhFTikgIDEwIDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDAgICAgMDAN
CihYRU4pICAxMSAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAw
DQooWEVOKSAgMTIgMDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAwICAgIDAgICAgMCAgICAw
MA0KKFhFTikgIDEzIDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDAgICAg
MDANCihYRU4pICAxNCAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAg
IDAwDQooWEVOKSAgMTUgMDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAwICAgIDAgICAgMCAg
ICAwMA0KKFhFTikgIDE2IDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDAg
ICAgMDANCihYRU4pICAxNyAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAw
ICAgIDAwDQooWEVOKSBJTyBBUElDICM3Li4uLi4uDQooWEVOKSAuLi4uIHJlZ2lzdGVyICMw
MDogMDcwMDAwMDANCihYRU4pIC4uLi4uLi4gICAgOiBwaHlzaWNhbCBBUElDIGlkOiAwNw0K
KFhFTikgLi4uLi4uLiAgICA6IERlbGl2ZXJ5IFR5cGU6IDANCihYRU4pIC4uLi4uLi4gICAg
OiBMVFMgICAgICAgICAgOiAwDQooWEVOKSAuLi4uIHJlZ2lzdGVyICMwMTogMDAxRjgwMjEN
CihYRU4pIC4uLi4uLi4gICAgIDogbWF4IHJlZGlyZWN0aW9uIGVudHJpZXM6IDAwMUYNCihY
RU4pIC4uLi4uLi4gICAgIDogUFJRIGltcGxlbWVudGVkOiAxDQooWEVOKSAuLi4uLi4uICAg
ICA6IElPIEFQSUMgdmVyc2lvbjogMDAyMQ0KKFhFTikgLi4uLiByZWdpc3RlciAjMDI6IDAw
MDAwMDAwDQooWEVOKSAuLi4uLi4uICAgICA6IGFyYml0cmF0aW9uOiAwMA0KKFhFTikgLi4u
LiBJUlEgcmVkaXJlY3Rpb24gdGFibGU6DQooWEVOKSAgTlIgTG9nIFBoeSBNYXNrIFRyaWcg
SVJSIFBvbCBTdGF0IERlc3QgRGVsaSBWZWN0OiAgIA0KKFhFTikgIDAwIDAwMCAwMCAgMSAg
ICAwICAgIDAgICAwICAgMCAgICAwICAgIDAgICAgMDANCihYRU4pICAwMSAwMDAgMDAgIDEg
ICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwDQooWEVOKSAgMDIgMDAwIDAwICAx
ICAgIDAgICAgMCAgIDAgICAwICAgIDAgICAgMCAgICAwMA0KKFhFTikgIDAzIDAwMCAwMCAg
MSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDAgICAgMDANCihYRU4pICAwNCAwMDAgMDAg
IDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwDQooWEVOKSAgMDUgMDAwIDAw
ICAxICAgIDAgICAgMCAgIDAgICAwICAgIDAgICAgMCAgICAwMA0KKFhFTikgIDA2IDAwMCAw
MCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDAgICAgMDANCihYRU4pICAwNyAwMDAg
MDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwDQooWEVOKSAgMDggMDAw
IDAwICAxICAgIDAgICAgMCAgIDAgICAwICAgIDAgICAgMCAgICAwMA0KKFhFTikgIDA5IDAw
MCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDAgICAgMDANCihYRU4pICAwYSAw
MDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwDQooWEVOKSAgMGIg
MDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAwICAgIDAgICAgMCAgICAwMA0KKFhFTikgIDBj
IDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDAgICAgMDANCihYRU4pICAw
ZCAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwDQooWEVOKSAg
MGUgMDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAwICAgIDAgICAgMCAgICAwMA0KKFhFTikg
IDBmIDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDAgICAgMDANCihYRU4p
ICAxMCAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwDQooWEVO
KSAgMTEgMDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAwICAgIDAgICAgMCAgICAwMA0KKFhF
TikgIDEyIDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDAgICAgMDANCihY
RU4pICAxMyAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwDQoo
WEVOKSAgMTQgMDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAwICAgIDAgICAgMCAgICAwMA0K
KFhFTikgIDE1IDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDAgICAgMDAN
CihYRU4pICAxNiAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAw
DQooWEVOKSAgMTcgMDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAwICAgIDAgICAgMCAgICAw
MA0KKFhFTikgIDE4IDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDAgICAg
MDANCihYRU4pICAxOSAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAg
IDAwDQooWEVOKSAgMWEgMDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAwICAgIDAgICAgMCAg
ICAwMA0KKFhFTikgIDFiIDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDAg
ICAgMDANCihYRU4pICAxYyAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAw
ICAgIDAwDQooWEVOKSAgMWQgMDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAwICAgIDAgICAg
MCAgICAwMA0KKFhFTikgIDFlIDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAg
IDAgICAgMDANCihYRU4pICAxZiAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAg
ICAwICAgIDAwDQooWEVOKSBVc2luZyB2ZWN0b3ItYmFzZWQgaW5kZXhpbmcNCihYRU4pIElS
USB0byBwaW4gbWFwcGluZ3M6DQooWEVOKSBJUlEyNDAgLT4gMDoyDQooWEVOKSBJUlE0OCAt
PiAwOjENCihYRU4pIElSUTU2IC0+IDA6Mw0KKFhFTikgSVJRMjQxIC0+IDA6NA0KKFhFTikg
SVJRNjQgLT4gMDo1DQooWEVOKSBJUlE3MiAtPiAwOjYNCihYRU4pIElSUTgwIC0+IDA6Nw0K
KFhFTikgSVJRODggLT4gMDo4DQooWEVOKSBJUlE5NiAtPiAwOjkNCihYRU4pIElSUTEwNCAt
PiAwOjEwDQooWEVOKSBJUlExMTIgLT4gMDoxMQ0KKFhFTikgSVJRMTIwIC0+IDA6MTINCihY
RU4pIElSUTEzNiAtPiAwOjEzDQooWEVOKSBJUlExNDQgLT4gMDoxNA0KKFhFTikgSVJRMTUy
IC0+IDA6MTUNCihYRU4pIC4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLiBk
b25lLg0KKFhFTikgVXNpbmcgbG9jYWwgQVBJQyB0aW1lciBpbnRlcnJ1cHRzLg0KKFhFTikg
Y2FsaWJyYXRpbmcgQVBJQyB0aW1lciAuLi4NCihYRU4pIC4uLi4uIENQVSBjbG9jayBzcGVl
ZCBpcyAzMjAwLjEyNDggTUh6Lg0KKFhFTikgLi4uLi4gaG9zdCBidXMgY2xvY2sgc3BlZWQg
aXMgMjAwLjAwNzcgTUh6Lg0KKFhFTikgLi4uLi4gYnVzX3NjYWxlID0gMHgwMDAwQ0NENw0K
KFhFTikgWzIwMTItMDktMDYgMjA6MDk6MDZdIFBsYXRmb3JtIHRpbWVyIGlzIDE0LjMxOE1I
eiBIUEVUDQooWEVOKSBbMjAxMi0wOS0wNiAyMDowOTowNl0gQWxsb2NhdGVkIGNvbnNvbGUg
cmluZyBvZiA2NCBLaUIuDQooWEVOKSBbMjAxMi0wOS0wNiAyMDowOTowNl0gSFZNOiBBU0lE
cyBlbmFibGVkLg0KKFhFTikgWzIwMTItMDktMDYgMjA6MDk6MDZdIFNWTTogU3VwcG9ydGVk
IGFkdmFuY2VkIGZlYXR1cmVzOg0KKFhFTikgWzIwMTItMDktMDYgMjA6MDk6MDZdICAtIE5l
c3RlZCBQYWdlIFRhYmxlcyAoTlBUKQ0KKFhFTikgWzIwMTItMDktMDYgMjA6MDk6MDZdICAt
IExhc3QgQnJhbmNoIFJlY29yZCAoTEJSKSBWaXJ0dWFsaXNhdGlvbg0KKFhFTikgWzIwMTIt
MDktMDYgMjA6MDk6MDZdICAtIE5leHQtUklQIFNhdmVkIG9uICNWTUVYSVQNCihYRU4pIFsy
MDEyLTA5LTA2IDIwOjA5OjA2XSAgLSBQYXVzZS1JbnRlcmNlcHQgRmlsdGVyDQooWEVOKSBb
MjAxMi0wOS0wNiAyMDowOTowNl0gSFZNOiBTVk0gZW5hYmxlZA0KKFhFTikgWzIwMTItMDkt
MDYgMjA6MDk6MDZdIEhWTTogSGFyZHdhcmUgQXNzaXN0ZWQgUGFnaW5nIChIQVApIGRldGVj
dGVkDQooWEVOKSBbMjAxMi0wOS0wNiAyMDowOTowNl0gSFZNOiBIQVAgcGFnZSBzaXplczog
NGtCLCAyTUIsIDFHQg0KKFhFTikgWzIwMTItMDktMDYgMjA6MDk6MDVdIG1hc2tlZCBFeHRJ
TlQgb24gQ1BVIzENCihYRU4pIFsyMDEyLTA5LTA2IDIwOjA5OjA2XSBtaWNyb2NvZGU6IGNv
bGxlY3RfY3B1X2luZm86IHBhdGNoX2lkPTB4MTAwMDBiZg0KKFhFTikgWzIwMTItMDktMDYg
MjA6MDk6MDVdIG1hc2tlZCBFeHRJTlQgb24gQ1BVIzINCihYRU4pIFsyMDEyLTA5LTA2IDIw
OjA5OjA2XSBtaWNyb2NvZGU6IGNvbGxlY3RfY3B1X2luZm86IHBhdGNoX2lkPTB4MTAwMDBi
Zg0KKFhFTikgWzIwMTItMDktMDYgMjA6MDk6MDVdIG1hc2tlZCBFeHRJTlQgb24gQ1BVIzMN
CihYRU4pIFsyMDEyLTA5LTA2IDIwOjA5OjA2XSBtaWNyb2NvZGU6IGNvbGxlY3RfY3B1X2lu
Zm86IHBhdGNoX2lkPTB4MTAwMDBiZg0KKFhFTikgWzIwMTItMDktMDYgMjA6MDk6MDVdIG1h
c2tlZCBFeHRJTlQgb24gQ1BVIzQNCihYRU4pIFsyMDEyLTA5LTA2IDIwOjA5OjA2XSBtaWNy
b2NvZGU6IGNvbGxlY3RfY3B1X2luZm86IHBhdGNoX2lkPTB4MTAwMDBiZg0KKFhFTikgWzIw
MTItMDktMDYgMjA6MDk6MDVdIG1hc2tlZCBFeHRJTlQgb24gQ1BVIzUNCihYRU4pIFsyMDEy
LTA5LTA2IDIwOjA5OjA2XSBCcm91Z2h0IHVwIDYgQ1BVcw0KKFhFTikgWzIwMTItMDktMDYg
MjA6MDk6MDZdIG1pY3JvY29kZTogY29sbGVjdF9jcHVfaW5mbzogcGF0Y2hfaWQ9MHgxMDAw
MGJmDQooWEVOKSBbMjAxMi0wOS0wNiAyMDowOTowNl0gSFBFVCdzIE1TSSBtb2RlIGhhc24n
dCBiZWVuIHN1cHBvcnRlZCB3aGVuIEludGVycnVwdCBSZW1hcHBpbmcgaXMgZW5hYmxlZC4N
CihYRU4pIFsyMDEyLTA5LTA2IDIwOjA5OjA2XSBBQ1BJIHNsZWVwIG1vZGVzOiBTMw0KKFhF
TikgWzIwMTItMDktMDYgMjA6MDk6MDZdIE1DQTogVXNlIGh3IHRocmVzaG9sZGluZyB0byBh
ZGp1c3QgcG9sbGluZyBmcmVxdWVuY3kNCihYRU4pIFsyMDEyLTA5LTA2IDIwOjA5OjA2XSBt
Y2hlY2tfcG9sbDogTWFjaGluZSBjaGVjayBwb2xsaW5nIHRpbWVyIHN0YXJ0ZWQuDQooWEVO
KSBbMjAxMi0wOS0wNiAyMDowOTowNl0gWGVub3Byb2ZpbGU6IEZhaWxlZCB0byBzZXR1cCBJ
QlMgTFZUIG9mZnNldCwgSUJTQ1RMID0gMHhmZmZmZmZmZg0KKFhFTikgWzIwMTItMDktMDYg
MjA6MDk6MDZdICoqKiBMT0FESU5HIERPTUFJTiAwICoqKg0KKFhFTikgWzIwMTItMDktMDYg
MjA6MDk6MDZdIGVsZl9wYXJzZV9iaW5hcnk6IHBoZHI6IHBhZGRyPTB4MTAwMDAwMCBtZW1z
ej0weGQ2YTAwMA0KKFhFTikgWzIwMTItMDktMDYgMjA6MDk6MDZdIGVsZl9wYXJzZV9iaW5h
cnk6IHBoZHI6IHBhZGRyPTB4MWUwMDAwMCBtZW1zej0weGRiMGU4DQooWEVOKSBbMjAxMi0w
OS0wNiAyMDowOTowNl0gZWxmX3BhcnNlX2JpbmFyeTogcGhkcjogcGFkZHI9MHgxZWRjMDAw
IG1lbXN6PTB4MTNjMDANCihYRU4pIFsyMDEyLTA5LTA2IDIwOjA5OjA2XSBlbGZfcGFyc2Vf
YmluYXJ5OiBwaGRyOiBwYWRkcj0weDFlZjAwMDAgbWVtc3o9MHhkZTUwMDANCihYRU4pIFsy
MDEyLTA5LTA2IDIwOjA5OjA2XSBlbGZfcGFyc2VfYmluYXJ5OiBtZW1vcnk6IDB4MTAwMDAw
MCAtPiAweDJjZDUwMDANCihYRU4pIFsyMDEyLTA5LTA2IDIwOjA5OjA2XSBlbGZfeGVuX3Bh
cnNlX25vdGU6IEdVRVNUX09TID0gImxpbnV4Ig0KKFhFTikgWzIwMTItMDktMDYgMjA6MDk6
MDZdIGVsZl94ZW5fcGFyc2Vfbm90ZTogR1VFU1RfVkVSU0lPTiA9ICIyLjYiDQooWEVOKSBb
MjAxMi0wOS0wNiAyMDowOTowNl0gZWxmX3hlbl9wYXJzZV9ub3RlOiBYRU5fVkVSU0lPTiA9
ICJ4ZW4tMy4wIg0KKFhFTikgWzIwMTItMDktMDYgMjA6MDk6MDZdIGVsZl94ZW5fcGFyc2Vf
bm90ZTogVklSVF9CQVNFID0gMHhmZmZmZmZmZjgwMDAwMDAwDQooWEVOKSBbMjAxMi0wOS0w
NiAyMDowOTowNl0gZWxmX3hlbl9wYXJzZV9ub3RlOiBFTlRSWSA9IDB4ZmZmZmZmZmY4MWVm
MDIxMA0KKFhFTikgWzIwMTItMDktMDYgMjA6MDk6MDZdIGVsZl94ZW5fcGFyc2Vfbm90ZTog
SFlQRVJDQUxMX1BBR0UgPSAweGZmZmZmZmZmODEwMDEwMDANCihYRU4pIFsyMDEyLTA5LTA2
IDIwOjA5OjA2XSBlbGZfeGVuX3BhcnNlX25vdGU6IEZFQVRVUkVTID0gIiF3cml0YWJsZV9w
YWdlX3RhYmxlc3xwYWVfcGdkaXJfYWJvdmVfNGdiIg0KKFhFTikgWzIwMTItMDktMDYgMjA6
MDk6MDZdIGVsZl94ZW5fcGFyc2Vfbm90ZTogUEFFX01PREUgPSAieWVzIg0KKFhFTikgWzIw
MTItMDktMDYgMjA6MDk6MDZdIGVsZl94ZW5fcGFyc2Vfbm90ZTogTE9BREVSID0gImdlbmVy
aWMiDQooWEVOKSBbMjAxMi0wOS0wNiAyMDowOTowNl0gZWxmX3hlbl9wYXJzZV9ub3RlOiB1
bmtub3duIHhlbiBlbGYgbm90ZSAoMHhkKQ0KKFhFTikgWzIwMTItMDktMDYgMjA6MDk6MDZd
IGVsZl94ZW5fcGFyc2Vfbm90ZTogU1VTUEVORF9DQU5DRUwgPSAweDENCihYRU4pIFsyMDEy
LTA5LTA2IDIwOjA5OjA2XSBlbGZfeGVuX3BhcnNlX25vdGU6IEhWX1NUQVJUX0xPVyA9IDB4
ZmZmZjgwMDAwMDAwMDAwMA0KKFhFTikgWzIwMTItMDktMDYgMjA6MDk6MDZdIGVsZl94ZW5f
cGFyc2Vfbm90ZTogUEFERFJfT0ZGU0VUID0gMHgwDQooWEVOKSBbMjAxMi0wOS0wNiAyMDow
OTowNl0gZWxmX3hlbl9hZGRyX2NhbGNfY2hlY2s6IGFkZHJlc3NlczoNCihYRU4pIFsyMDEy
LTA5LTA2IDIwOjA5OjA2XSAgICAgdmlydF9iYXNlICAgICAgICA9IDB4ZmZmZmZmZmY4MDAw
MDAwMA0KKFhFTikgWzIwMTItMDktMDYgMjA6MDk6MDZdICAgICBlbGZfcGFkZHJfb2Zmc2V0
ID0gMHgwDQooWEVOKSBbMjAxMi0wOS0wNiAyMDowOTowNl0gICAgIHZpcnRfb2Zmc2V0ICAg
ICAgPSAweGZmZmZmZmZmODAwMDAwMDANCihYRU4pIFsyMDEyLTA5LTA2IDIwOjA5OjA2XSAg
ICAgdmlydF9rc3RhcnQgICAgICA9IDB4ZmZmZmZmZmY4MTAwMDAwMA0KKFhFTikgWzIwMTIt
MDktMDYgMjA6MDk6MDZdICAgICB2aXJ0X2tlbmQgICAgICAgID0gMHhmZmZmZmZmZjgyY2Q1
MDAwDQooWEVOKSBbMjAxMi0wOS0wNiAyMDowOTowNl0gICAgIHZpcnRfZW50cnkgICAgICAg
PSAweGZmZmZmZmZmODFlZjAyMTANCihYRU4pIFsyMDEyLTA5LTA2IDIwOjA5OjA2XSAgICAg
cDJtX2Jhc2UgICAgICAgICA9IDB4ZmZmZmZmZmZmZmZmZmZmZg0KKFhFTikgWzIwMTItMDkt
MDYgMjA6MDk6MDZdICBYZW4gIGtlcm5lbDogNjQtYml0LCBsc2IsIGNvbXBhdDMyDQooWEVO
KSBbMjAxMi0wOS0wNiAyMDowOTowNl0gIERvbTAga2VybmVsOiA2NC1iaXQsIFBBRSwgbHNi
LCBwYWRkciAweDEwMDAwMDAgLT4gMHgyY2Q1MDAwDQooWEVOKSBbMjAxMi0wOS0wNiAyMDow
OTowNl0gUEhZU0lDQUwgTUVNT1JZIEFSUkFOR0VNRU5UOg0KKFhFTikgWzIwMTItMDktMDYg
MjA6MDk6MDZdICBEb20wIGFsbG9jLjogICAwMDAwMDAwMjQwMDAwMDAwLT4wMDAwMDAwMjQ0
MDAwMDAwICgyNDI0MjggcGFnZXMgdG8gYmUgYWxsb2NhdGVkKQ0KKFhFTikgWzIwMTItMDkt
MDYgMjA6MDk6MDZdICBJbml0LiByYW1kaXNrOiAwMDAwMDAwMjRmMmZjMDAwLT4wMDAwMDAw
MjRmZmZmODAwDQooWEVOKSBbMjAxMi0wOS0wNiAyMDowOTowNl0gVklSVFVBTCBNRU1PUlkg
QVJSQU5HRU1FTlQ6DQooWEVOKSBbMjAxMi0wOS0wNiAyMDowOTowNl0gIExvYWRlZCBrZXJu
ZWw6IGZmZmZmZmZmODEwMDAwMDAtPmZmZmZmZmZmODJjZDUwMDANCihYRU4pIFsyMDEyLTA5
LTA2IDIwOjA5OjA2XSAgSW5pdC4gcmFtZGlzazogZmZmZmZmZmY4MmNkNTAwMC0+ZmZmZmZm
ZmY4MzlkODgwMA0KKFhFTikgWzIwMTItMDktMDYgMjA6MDk6MDZdICBQaHlzLU1hY2ggbWFw
OiBmZmZmZmZmZjgzOWQ5MDAwLT5mZmZmZmZmZjgzYmQ5MDAwDQooWEVOKSBbMjAxMi0wOS0w
NiAyMDowOTowNl0gIFN0YXJ0IGluZm86ICAgIGZmZmZmZmZmODNiZDkwMDAtPmZmZmZmZmZm
ODNiZDk0YjQNCihYRU4pIFsyMDEyLTA5LTA2IDIwOjA5OjA2XSAgUGFnZSB0YWJsZXM6ICAg
ZmZmZmZmZmY4M2JkYTAwMC0+ZmZmZmZmZmY4M2JmZDAwMA0KKFhFTikgWzIwMTItMDktMDYg
MjA6MDk6MDZdICBCb290IHN0YWNrOiAgICBmZmZmZmZmZjgzYmZkMDAwLT5mZmZmZmZmZjgz
YmZlMDAwDQooWEVOKSBbMjAxMi0wOS0wNiAyMDowOTowNl0gIFRPVEFMOiAgICAgICAgIGZm
ZmZmZmZmODAwMDAwMDAtPmZmZmZmZmZmODQwMDAwMDANCihYRU4pIFsyMDEyLTA5LTA2IDIw
OjA5OjA2XSAgRU5UUlkgQUREUkVTUzogZmZmZmZmZmY4MWVmMDIxMA0KKFhFTikgWzIwMTIt
MDktMDYgMjA6MDk6MDZdIERvbTAgaGFzIG1heGltdW0gNiBWQ1BVcw0KKFhFTikgWzIwMTIt
MDktMDYgMjA6MDk6MDZdIGVsZl9sb2FkX2JpbmFyeTogcGhkciAwIGF0IDB4ZmZmZmZmZmY4
MTAwMDAwMCAtPiAweGZmZmZmZmZmODFkNmEwMDANCihYRU4pIFsyMDEyLTA5LTA2IDIwOjA5
OjA2XSBlbGZfbG9hZF9iaW5hcnk6IHBoZHIgMSBhdCAweGZmZmZmZmZmODFlMDAwMDAgLT4g
MHhmZmZmZmZmZjgxZWRiMGU4DQooWEVOKSBbMjAxMi0wOS0wNiAyMDowOTowNl0gZWxmX2xv
YWRfYmluYXJ5OiBwaGRyIDIgYXQgMHhmZmZmZmZmZjgxZWRjMDAwIC0+IDB4ZmZmZmZmZmY4
MWVlZmMwMA0KKFhFTikgWzIwMTItMDktMDYgMjA6MDk6MDZdIGVsZl9sb2FkX2JpbmFyeTog
cGhkciAzIGF0IDB4ZmZmZmZmZmY4MWVmMDAwMCAtPiAweGZmZmZmZmZmODFmODkwMDANCihY
RU4pIFsyMDEyLTA5LTA2IDIwOjA5OjA3XSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxl
OiBkZXZpY2UgaWQgPSAweDAwMDAsIHJvb3QgdGFibGUgPSAweDI0ZDg0YjAwMCwgZG9tYWlu
ID0gMCwgcGFnaW5nIG1vZGUgPSAzDQooWEVOKSBbMjAxMi0wOS0wNiAyMDowOTowN10gQU1E
LVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHgwMDAyLCByb290IHRh
YmxlID0gMHgyNGQ4NGIwMDAsIGRvbWFpbiA9IDAsIHBhZ2luZyBtb2RlID0gMw0KKFhFTikg
WzIwMTItMDktMDYgMjA6MDk6MDddIEFNRC1WaTogU2V0dXAgSS9PIHBhZ2UgdGFibGU6IGRl
dmljZSBpZCA9IDB4MDAxMCwgcm9vdCB0YWJsZSA9IDB4MjRkODRiMDAwLCBkb21haW4gPSAw
LCBwYWdpbmcgbW9kZSA9IDMNCihYRU4pIFsyMDEyLTA5LTA2IDIwOjA5OjA3XSBBTUQtVmk6
IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweDAwMTgsIHJvb3QgdGFibGUg
PSAweDI0ZDg0YjAwMCwgZG9tYWluID0gMCwgcGFnaW5nIG1vZGUgPSAzDQooWEVOKSBbMjAx
Mi0wOS0wNiAyMDowOTowN10gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNl
IGlkID0gMHgwMDI4LCByb290IHRhYmxlID0gMHgyNGQ4NGIwMDAsIGRvbWFpbiA9IDAsIHBh
Z2luZyBtb2RlID0gMw0KKFhFTikgWzIwMTItMDktMDYgMjA6MDk6MDddIEFNRC1WaTogU2V0
dXAgSS9PIHBhZ2UgdGFibGU6IGRldmljZSBpZCA9IDB4MDAzMCwgcm9vdCB0YWJsZSA9IDB4
MjRkODRiMDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMNCihYRU4pIFsyMDEyLTA5
LTA2IDIwOjA5OjA3XSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQg
PSAweDAwNTAsIHJvb3QgdGFibGUgPSAweDI0ZDg0YjAwMCwgZG9tYWluID0gMCwgcGFnaW5n
IG1vZGUgPSAzDQooWEVOKSBbMjAxMi0wOS0wNiAyMDowOTowN10gQU1ELVZpOiBTZXR1cCBJ
L08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHgwMDU4LCByb290IHRhYmxlID0gMHgyNGQ4
NGIwMDAsIGRvbWFpbiA9IDAsIHBhZ2luZyBtb2RlID0gMw0KKFhFTikgWzIwMTItMDktMDYg
MjA6MDk6MDddIEFNRC1WaTogU2V0dXAgSS9PIHBhZ2UgdGFibGU6IGRldmljZSBpZCA9IDB4
MDA2MCwgcm9vdCB0YWJsZSA9IDB4MjRkODRiMDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9k
ZSA9IDMNCihYRU4pIFsyMDEyLTA5LTA2IDIwOjA5OjA3XSBBTUQtVmk6IFNldHVwIEkvTyBw
YWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweDAwNjgsIHJvb3QgdGFibGUgPSAweDI0ZDg0YjAw
MCwgZG9tYWluID0gMCwgcGFnaW5nIG1vZGUgPSAzDQooWEVOKSBbMjAxMi0wOS0wNiAyMDow
OTowN10gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHgwMDg4
LCByb290IHRhYmxlID0gMHgyNGQ4NGIwMDAsIGRvbWFpbiA9IDAsIHBhZ2luZyBtb2RlID0g
Mw0KKFhFTikgWzIwMTItMDktMDYgMjA6MDk6MDddIEFNRC1WaTogU2V0dXAgSS9PIHBhZ2Ug
dGFibGU6IGRldmljZSBpZCA9IDB4MDA5MCwgcm9vdCB0YWJsZSA9IDB4MjRkODRiMDAwLCBk
b21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMNCihYRU4pIFsyMDEyLTA5LTA2IDIwOjA5OjA3
XSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweDAwOTIsIHJv
b3QgdGFibGUgPSAweDI0ZDg0YjAwMCwgZG9tYWluID0gMCwgcGFnaW5nIG1vZGUgPSAzDQoo
WEVOKSBbMjAxMi0wOS0wNiAyMDowOTowN10gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJs
ZTogZGV2aWNlIGlkID0gMHgwMDk4LCByb290IHRhYmxlID0gMHgyNGQ4NGIwMDAsIGRvbWFp
biA9IDAsIHBhZ2luZyBtb2RlID0gMw0KKFhFTikgWzIwMTItMDktMDYgMjA6MDk6MDddIEFN
RC1WaTogU2V0dXAgSS9PIHBhZ2UgdGFibGU6IGRldmljZSBpZCA9IDB4MDA5YSwgcm9vdCB0
YWJsZSA9IDB4MjRkODRiMDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMNCihYRU4p
IFsyMDEyLTA5LTA2IDIwOjA5OjA3XSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBk
ZXZpY2UgaWQgPSAweDAwYTAsIHJvb3QgdGFibGUgPSAweDI0ZDg0YjAwMCwgZG9tYWluID0g
MCwgcGFnaW5nIG1vZGUgPSAzDQooWEVOKSBbMjAxMi0wOS0wNiAyMDowOTowN10gQU1ELVZp
OiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHgwMGEzLCByb290IHRhYmxl
ID0gMHgyNGQ4NGIwMDAsIGRvbWFpbiA9IDAsIHBhZ2luZyBtb2RlID0gMw0KKFhFTikgWzIw
MTItMDktMDYgMjA6MDk6MDddIEFNRC1WaTogU2V0dXAgSS9PIHBhZ2UgdGFibGU6IGRldmlj
ZSBpZCA9IDB4MDBhNCwgcm9vdCB0YWJsZSA9IDB4MjRkODRiMDAwLCBkb21haW4gPSAwLCBw
YWdpbmcgbW9kZSA9IDMNCihYRU4pIFsyMDEyLTA5LTA2IDIwOjA5OjA3XSBBTUQtVmk6IFNl
dHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweDAwYTUsIHJvb3QgdGFibGUgPSAw
eDI0ZDg0YjAwMCwgZG9tYWluID0gMCwgcGFnaW5nIG1vZGUgPSAzDQooWEVOKSBbMjAxMi0w
OS0wNiAyMDowOTowN10gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlk
ID0gMHgwMGE4LCByb290IHRhYmxlID0gMHgyNGQ4NGIwMDAsIGRvbWFpbiA9IDAsIHBhZ2lu
ZyBtb2RlID0gMw0KKFhFTikgWzIwMTItMDktMDYgMjA6MDk6MDddIEFNRC1WaTogU2V0dXAg
SS9PIHBhZ2UgdGFibGU6IGRldmljZSBpZCA9IDB4MDBiMCwgcm9vdCB0YWJsZSA9IDB4MjRk
ODRiMDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMNCihYRU4pIFsyMDEyLTA5LTA2
IDIwOjA5OjA3XSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAw
eDAwYjIsIHJvb3QgdGFibGUgPSAweDI0ZDg0YjAwMCwgZG9tYWluID0gMCwgcGFnaW5nIG1v
ZGUgPSAzDQooWEVOKSBbMjAxMi0wOS0wNiAyMDowOTowN10gQU1ELVZpOiBObyBpb21tdSBm
b3IgZGV2aWNlIDAwMDA6MDA6MTguMA0KKFhFTikgWzIwMTItMDktMDYgMjA6MDk6MDddIEFN
RC1WaTogTm8gaW9tbXUgZm9yIGRldmljZSAwMDAwOjAwOjE4LjENCihYRU4pIFsyMDEyLTA5
LTA2IDIwOjA5OjA3XSBBTUQtVmk6IE5vIGlvbW11IGZvciBkZXZpY2UgMDAwMDowMDoxOC4y
DQooWEVOKSBbMjAxMi0wOS0wNiAyMDowOTowN10gQU1ELVZpOiBObyBpb21tdSBmb3IgZGV2
aWNlIDAwMDA6MDA6MTguMw0KKFhFTikgWzIwMTItMDktMDYgMjA6MDk6MDddIEFNRC1WaTog
Tm8gaW9tbXUgZm9yIGRldmljZSAwMDAwOjAwOjE4LjQNCihYRU4pIFsyMDEyLTA5LTA2IDIw
OjA5OjA3XSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweDA0
MDAsIHJvb3QgdGFibGUgPSAweDI0ZDg0YjAwMCwgZG9tYWluID0gMCwgcGFnaW5nIG1vZGUg
PSAzDQooWEVOKSBbMjAxMi0wOS0wNiAyMDowOTowN10gQU1ELVZpOiBTZXR1cCBJL08gcGFn
ZSB0YWJsZTogZGV2aWNlIGlkID0gMHgwNDAxLCByb290IHRhYmxlID0gMHgyNGQ4NGIwMDAs
IGRvbWFpbiA9IDAsIHBhZ2luZyBtb2RlID0gMw0KKFhFTikgWzIwMTItMDktMDYgMjA6MDk6
MDddIEFNRC1WaTogU2V0dXAgSS9PIHBhZ2UgdGFibGU6IGRldmljZSBpZCA9IDB4MDQwMiwg
cm9vdCB0YWJsZSA9IDB4MjRkODRiMDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMN
CihYRU4pIFsyMDEyLTA5LTA2IDIwOjA5OjA3XSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRh
YmxlOiBkZXZpY2UgaWQgPSAweDA0MDMsIHJvb3QgdGFibGUgPSAweDI0ZDg0YjAwMCwgZG9t
YWluID0gMCwgcGFnaW5nIG1vZGUgPSAzDQooWEVOKSBbMjAxMi0wOS0wNiAyMDowOTowN10g
QU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHgwNDA0LCByb290
IHRhYmxlID0gMHgyNGQ4NGIwMDAsIGRvbWFpbiA9IDAsIHBhZ2luZyBtb2RlID0gMw0KKFhF
TikgWzIwMTItMDktMDYgMjA6MDk6MDddIEFNRC1WaTogU2V0dXAgSS9PIHBhZ2UgdGFibGU6
IGRldmljZSBpZCA9IDB4MDQwNSwgcm9vdCB0YWJsZSA9IDB4MjRkODRiMDAwLCBkb21haW4g
PSAwLCBwYWdpbmcgbW9kZSA9IDMNCihYRU4pIFsyMDEyLTA5LTA2IDIwOjA5OjA3XSBBTUQt
Vmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweDA0MDYsIHJvb3QgdGFi
bGUgPSAweDI0ZDg0YjAwMCwgZG9tYWluID0gMCwgcGFnaW5nIG1vZGUgPSAzDQooWEVOKSBb
MjAxMi0wOS0wNiAyMDowOTowN10gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2
aWNlIGlkID0gMHgwNDA3LCByb290IHRhYmxlID0gMHgyNGQ4NGIwMDAsIGRvbWFpbiA9IDAs
IHBhZ2luZyBtb2RlID0gMw0KKFhFTikgWzIwMTItMDktMDYgMjA6MDk6MDddIEFNRC1WaTog
U2V0dXAgSS9PIHBhZ2UgdGFibGU6IGRldmljZSBpZCA9IDB4MDUwMCwgcm9vdCB0YWJsZSA9
IDB4MjRkODRiMDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMNCihYRU4pIFsyMDEy
LTA5LTA2IDIwOjA5OjA3XSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2Ug
aWQgPSAweDA2MDAsIHJvb3QgdGFibGUgPSAweDI0ZDg0YjAwMCwgZG9tYWluID0gMCwgcGFn
aW5nIG1vZGUgPSAzDQooWEVOKSBbMjAxMi0wOS0wNiAyMDowOTowN10gQU1ELVZpOiBTZXR1
cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHgwNjAxLCByb290IHRhYmxlID0gMHgy
NGQ4NGIwMDAsIGRvbWFpbiA9IDAsIHBhZ2luZyBtb2RlID0gMw0KKFhFTikgWzIwMTItMDkt
MDYgMjA6MDk6MDddIEFNRC1WaTogU2V0dXAgSS9PIHBhZ2UgdGFibGU6IGRldmljZSBpZCA9
IDB4MDcwMCwgcm9vdCB0YWJsZSA9IDB4MjRkODRiMDAwLCBkb21haW4gPSAwLCBwYWdpbmcg
bW9kZSA9IDMNCihYRU4pIFsyMDEyLTA5LTA2IDIwOjA5OjA3XSBBTUQtVmk6IFNldHVwIEkv
TyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweDA4MDAsIHJvb3QgdGFibGUgPSAweDI0ZDg0
YjAwMCwgZG9tYWluID0gMCwgcGFnaW5nIG1vZGUgPSAzDQooWEVOKSBbMjAxMi0wOS0wNiAy
MDowOTowN10gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHgw
OTAwLCByb290IHRhYmxlID0gMHgyNGQ4NGIwMDAsIGRvbWFpbiA9IDAsIHBhZ2luZyBtb2Rl
ID0gMw0KKFhFTikgWzIwMTItMDktMDYgMjA6MDk6MDddIEFNRC1WaTogU2V0dXAgSS9PIHBh
Z2UgdGFibGU6IGRldmljZSBpZCA9IDB4MGEwMCwgcm9vdCB0YWJsZSA9IDB4MjRkODRiMDAw
LCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMNCihYRU4pIFsyMDEyLTA5LTA2IDIwOjA5
OjA3XSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweDBhMDEs
IHJvb3QgdGFibGUgPSAweDI0ZDg0YjAwMCwgZG9tYWluID0gMCwgcGFnaW5nIG1vZGUgPSAz
DQooWEVOKSBbMjAxMi0wOS0wNiAyMDowOTowN10gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0
YWJsZTogZGV2aWNlIGlkID0gMHgwYTAyLCByb290IHRhYmxlID0gMHgyNGQ4NGIwMDAsIGRv
bWFpbiA9IDAsIHBhZ2luZyBtb2RlID0gMw0KKFhFTikgWzIwMTItMDktMDYgMjA6MDk6MDdd
IEFNRC1WaTogU2V0dXAgSS9PIHBhZ2UgdGFibGU6IGRldmljZSBpZCA9IDB4MGEwMywgcm9v
dCB0YWJsZSA9IDB4MjRkODRiMDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMNCihY
RU4pIFsyMDEyLTA5LTA2IDIwOjA5OjA3XSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxl
OiBkZXZpY2UgaWQgPSAweDBhMDQsIHJvb3QgdGFibGUgPSAweDI0ZDg0YjAwMCwgZG9tYWlu
ID0gMCwgcGFnaW5nIG1vZGUgPSAzDQooWEVOKSBbMjAxMi0wOS0wNiAyMDowOTowN10gQU1E
LVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHgwYTA1LCByb290IHRh
YmxlID0gMHgyNGQ4NGIwMDAsIGRvbWFpbiA9IDAsIHBhZ2luZyBtb2RlID0gMw0KKFhFTikg
WzIwMTItMDktMDYgMjA6MDk6MDddIEFNRC1WaTogU2V0dXAgSS9PIHBhZ2UgdGFibGU6IGRl
dmljZSBpZCA9IDB4MGEwNiwgcm9vdCB0YWJsZSA9IDB4MjRkODRiMDAwLCBkb21haW4gPSAw
LCBwYWdpbmcgbW9kZSA9IDMNCihYRU4pIFsyMDEyLTA5LTA2IDIwOjA5OjA3XSBBTUQtVmk6
IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweDBhMDcsIHJvb3QgdGFibGUg
PSAweDI0ZDg0YjAwMCwgZG9tYWluID0gMCwgcGFnaW5nIG1vZGUgPSAzDQooWEVOKSBbMjAx
Mi0wOS0wNiAyMDowOTowN10gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNl
IGlkID0gMHgwYjAwLCByb290IHRhYmxlID0gMHgyNGQ4NGIwMDAsIGRvbWFpbiA9IDAsIHBh
Z2luZyBtb2RlID0gMw0KKFhFTikgWzIwMTItMDktMDYgMjA6MDk6MDddIFNjcnViYmluZyBG
cmVlIFJBTTogLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi48MD5BTUQtVmk6IElPX1BBR0Vf
RkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MGEwNiwgZmF1bHQgYWRkcmVzcyA9
IDB4YzJjMmMyYzAsIGZsYWdzID0gMHgwMDANCihYRU4pIFsyMDEyLTA5LTA2IDIwOjA5OjA4
XSAuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi5kb25lLg0K
KFhFTikgWzIwMTItMDktMDYgMjA6MDk6MDldIEluaXRpYWwgbG93IG1lbW9yeSB2aXJxIHRo
cmVzaG9sZCBzZXQgYXQgMHg0MDAwIHBhZ2VzLg0KKFhFTikgWzIwMTItMDktMDYgMjA6MDk6
MDldIFN0ZC4gTG9nbGV2ZWw6IEFsbA0KKFhFTikgWzIwMTItMDktMDYgMjA6MDk6MDldIEd1
ZXN0IExvZ2xldmVsOiBBbGwNCihYRU4pIFsyMDEyLTA5LTA2IDIwOjA5OjA5XSBYZW4gaXMg
cmVsaW5xdWlzaGluZyBWR0EgY29uc29sZS4NCihYRU4pIFsyMDEyLTA5LTA2IDIwOjA5OjA5
XSAqKiogU2VyaWFsIGlucHV0IC0+IERPTTAgKHR5cGUgJ0NUUkwtYScgdGhyZWUgdGltZXMg
dG8gc3dpdGNoIGlucHV0IHRvIFhlbikNCihYRU4pIFsyMDEyLTA5LTA2IDIwOjA5OjA5XSBG
cmVlZCAyNTZrQiBpbml0IG1lbW9yeS4NCihYRU4pIFsyMDEyLTA5LTA2IDIwOjA5OjA5XSBJ
T0FQSUNbMF06IFNldCBQQ0kgcm91dGluZyBlbnRyeSAoNi05IC0+IDB4NjAgLT4gSVJRIDkg
TW9kZToxIEFjdGl2ZToxKQ0KKFhFTikgWzIwMTItMDktMDYgMjA6MDk6MDldIHRyYXBzLmM6
MjU4NDpkMCBEb21haW4gYXR0ZW1wdGVkIFdSTVNSIDAwMDAwMDAwYzAwMDA0MDggZnJvbSAw
eGMwMDAwMDAwMDEwMDAwMDAgdG8gMHhjMDA4MDAwMDAxMDAwMDAwLg0KKFhFTikgWzIwMTIt
MDktMDYgMjA6MDk6MDldIHRyYXBzLmM6MjU4NDpkMCBEb21haW4gYXR0ZW1wdGVkIFdSTVNS
IDAwMDAwMDAwYzAwMDA0MDkgZnJvbSAweGMwMDAwMDAwMDEwMDAwMDAgdG8gMHhjMDA4MDAw
MDAxMDAwMDAwLg0KKFhFTikgWzIwMTItMDktMDYgMjA6MDk6MDldIHRyYXBzLmM6MjU4NDpk
MCBEb21haW4gYXR0ZW1wdGVkIFdSTVNSIDAwMDAwMDAwYzAwMTAwMDQgZnJvbSAweDAwMDBl
ZmYwYmRmYjFmY2UgdG8gMHgwMDAwMDAwMDAwMDBhYmNkLg0KKFhFTikgWzIwMTItMDktMDYg
MjA6MDk6MDldIHRyYXBzLmM6MjU4NDpkMCBEb21haW4gYXR0ZW1wdGVkIFdSTVNSIDAwMDAw
MDAwYzAwMDA0MDggZnJvbSAweGMwMDAwMDAwMDEwMDAwMDAgdG8gMHhjMDA4MDAwMDAxMDAw
MDAwLg0KKFhFTikgWzIwMTItMDktMDYgMjA6MDk6MDldIHRyYXBzLmM6MjU4NDpkMCBEb21h
aW4gYXR0ZW1wdGVkIFdSTVNSIDAwMDAwMDAwYzAwMDA0MDkgZnJvbSAweGMwMDAwMDAwMDEw
MDAwMDAgdG8gMHhjMDA4MDAwMDAxMDAwMDAwLg0KKFhFTikgWzIwMTItMDktMDYgMjA6MDk6
MDldIHRyYXBzLmM6MjU4NDpkMCBEb21haW4gYXR0ZW1wdGVkIFdSTVNSIDAwMDAwMDAwYzAw
MDA0MDggZnJvbSAweGMwMDAwMDAwMDEwMDAwMDAgdG8gMHhjMDA4MDAwMDAxMDAwMDAwLg0K
KFhFTikgWzIwMTItMDktMDYgMjA6MDk6MDldIHRyYXBzLmM6MjU4NDpkMCBEb21haW4gYXR0
ZW1wdGVkIFdSTVNSIDAwMDAwMDAwYzAwMDA0MDkgZnJvbSAweGMwMDAwMDAwMDEwMDAwMDAg
dG8gMHhjMDA4MDAwMDAxMDAwMDAwLg0KKFhFTikgWzIwMTItMDktMDYgMjA6MDk6MDldIHRy
YXBzLmM6MjU4NDpkMCBEb21haW4gYXR0ZW1wdGVkIFdSTVNSIDAwMDAwMDAwYzAwMDA0MDgg
ZnJvbSAweGMwMDAwMDAwMDEwMDAwMDAgdG8gMHhjMDA4MDAwMDAxMDAwMDAwLg0KKFhFTikg
WzIwMTItMDktMDYgMjA6MDk6MDldIHRyYXBzLmM6MjU4NDpkMCBEb21haW4gYXR0ZW1wdGVk
IFdSTVNSIDAwMDAwMDAwYzAwMDA0MDkgZnJvbSAweGMwMDAwMDAwMDEwMDAwMDAgdG8gMHhj
MDA4MDAwMDAxMDAwMDAwLg0KKFhFTikgWzIwMTItMDktMDYgMjA6MDk6MDldIHRyYXBzLmM6
MjU4NDpkMCBEb21haW4gYXR0ZW1wdGVkIFdSTVNSIDAwMDAwMDAwYzAwMDA0MDggZnJvbSAw
eGMwMDAwMDAwMDEwMDAwMDAgdG8gMHhjMDA4MDAwMDAxMDAwMDAwLg0KKFhFTikgWzIwMTIt
MDktMDYgMjA6MDk6MDldIHRyYXBzLmM6MjU4NDpkMCBEb21haW4gYXR0ZW1wdGVkIFdSTVNS
IDAwMDAwMDAwYzAwMDA0MDkgZnJvbSAweGMwMDAwMDAwMDEwMDAwMDAgdG8gMHhjMDA4MDAw
MDAxMDAwMDAwLg0KKFhFTikgWzIwMTItMDktMDYgMjA6MDk6MDldIHRyYXBzLmM6MjU4NDpk
MCBEb21haW4gYXR0ZW1wdGVkIFdSTVNSIDAwMDAwMDAwYzAwMDA0MDggZnJvbSAweGMwMDAw
MDAwMDEwMDAwMDAgdG8gMHhjMDA4MDAwMDAxMDAwMDAwLg0KKFhFTikgWzIwMTItMDktMDYg
MjA6MDk6MDldIHRyYXBzLmM6MjU4NDpkMCBEb21haW4gYXR0ZW1wdGVkIFdSTVNSIDAwMDAw
MDAwYzAwMDA0MDkgZnJvbSAweGMwMDAwMDAwMDEwMDAwMDAgdG8gMHhjMDA4MDAwMDAxMDAw
MDAwLg0KKFhFTikgWzIwMTItMDktMDYgMjA6MDk6MTBdIFBDSSBhZGQgZGV2aWNlIDAwMDA6
MDA6MDAuMA0KKFhFTikgWzIwMTItMDktMDYgMjA6MDk6MTBdIFBDSSBhZGQgZGV2aWNlIDAw
MDA6MDA6MDAuMg0KKFhFTikgWzIwMTItMDktMDYgMjA6MDk6MTBdIFBDSSBhZGQgZGV2aWNl
IDAwMDA6MDA6MDIuMA0KKFhFTikgWzIwMTItMDktMDYgMjA6MDk6MTBdIFBDSSBhZGQgZGV2
aWNlIDAwMDA6MDA6MDMuMA0KKFhFTikgWzIwMTItMDktMDYgMjA6MDk6MTBdIFBDSSBhZGQg
ZGV2aWNlIDAwMDA6MDA6MDUuMA0KKFhFTikgWzIwMTItMDktMDYgMjA6MDk6MTBdIFBDSSBh
ZGQgZGV2aWNlIDAwMDA6MDA6MDYuMA0KKFhFTikgWzIwMTItMDktMDYgMjA6MDk6MTBdIFBD
SSBhZGQgZGV2aWNlIDAwMDA6MDA6MGEuMA0KKFhFTikgWzIwMTItMDktMDYgMjA6MDk6MTBd
IFBDSSBhZGQgZGV2aWNlIDAwMDA6MDA6MGIuMA0KKFhFTikgWzIwMTItMDktMDYgMjA6MDk6
MTBdIFBDSSBhZGQgZGV2aWNlIDAwMDA6MDA6MGMuMA0KKFhFTikgWzIwMTItMDktMDYgMjA6
MDk6MTBdIFBDSSBhZGQgZGV2aWNlIDAwMDA6MDA6MGQuMA0KKFhFTikgWzIwMTItMDktMDYg
MjA6MDk6MTBdIFBDSSBhZGQgZGV2aWNlIDAwMDA6MDA6MTEuMA0KKFhFTikgWzIwMTItMDkt
MDYgMjA6MDk6MTBdIFBDSSBhZGQgZGV2aWNlIDAwMDA6MDA6MTIuMA0KKFhFTikgWzIwMTIt
MDktMDYgMjA6MDk6MTBdIFBDSSBhZGQgZGV2aWNlIDAwMDA6MDA6MTIuMg0KKFhFTikgWzIw
MTItMDktMDYgMjA6MDk6MTBdIFBDSSBhZGQgZGV2aWNlIDAwMDA6MDA6MTMuMA0KKFhFTikg
WzIwMTItMDktMDYgMjA6MDk6MTBdIFBDSSBhZGQgZGV2aWNlIDAwMDA6MDA6MTMuMg0KKFhF
TikgWzIwMTItMDktMDYgMjA6MDk6MTBdIFBDSSBhZGQgZGV2aWNlIDAwMDA6MDA6MTQuMA0K
KFhFTikgWzIwMTItMDktMDYgMjA6MDk6MTBdIFBDSSBhZGQgZGV2aWNlIDAwMDA6MDA6MTQu
Mw0KKFhFTikgWzIwMTItMDktMDYgMjA6MDk6MTBdIFBDSSBhZGQgZGV2aWNlIDAwMDA6MDA6
MTQuNA0KKFhFTikgWzIwMTItMDktMDYgMjA6MDk6MTBdIFBDSSBhZGQgZGV2aWNlIDAwMDA6
MDA6MTQuNQ0KKFhFTikgWzIwMTItMDktMDYgMjA6MDk6MTBdIFBDSSBhZGQgZGV2aWNlIDAw
MDA6MDA6MTUuMA0KKFhFTikgWzIwMTItMDktMDYgMjA6MDk6MTBdIFBDSSBhZGQgZGV2aWNl
IDAwMDA6MDA6MTYuMA0KKFhFTikgWzIwMTItMDktMDYgMjA6MDk6MTBdIFBDSSBhZGQgZGV2
aWNlIDAwMDA6MDA6MTYuMg0KKFhFTikgWzIwMTItMDktMDYgMjA6MDk6MTBdIFBDSSBhZGQg
ZGV2aWNlIDAwMDA6MDA6MTguMA0KKFhFTikgWzIwMTItMDktMDYgMjA6MDk6MTBdIFBDSSBh
ZGQgZGV2aWNlIDAwMDA6MDA6MTguMQ0KKFhFTikgWzIwMTItMDktMDYgMjA6MDk6MTBdIFBD
SSBhZGQgZGV2aWNlIDAwMDA6MDA6MTguMg0KKFhFTikgWzIwMTItMDktMDYgMjA6MDk6MTBd
IFBDSSBhZGQgZGV2aWNlIDAwMDA6MDA6MTguMw0KKFhFTikgWzIwMTItMDktMDYgMjA6MDk6
MTBdIFBDSSBhZGQgZGV2aWNlIDAwMDA6MDA6MTguNA0KKFhFTikgWzIwMTItMDktMDYgMjA6
MDk6MTBdIFBDSSBhZGQgZGV2aWNlIDAwMDA6MGI6MDAuMA0KKFhFTikgWzIwMTItMDktMDYg
MjA6MDk6MTBdIFBDSSBhZGQgZGV2aWNlIDAwMDA6MGE6MDAuMA0KKFhFTikgWzIwMTItMDkt
MDYgMjA6MDk6MTBdIFBDSSBhZGQgZGV2aWNlIDAwMDA6MGE6MDAuMQ0KKFhFTikgWzIwMTIt
MDktMDYgMjA6MDk6MTBdIFBDSSBhZGQgZGV2aWNlIDAwMDA6MGE6MDAuMg0KKFhFTikgWzIw
MTItMDktMDYgMjA6MDk6MTBdIFBDSSBhZGQgZGV2aWNlIDAwMDA6MGE6MDAuMw0KKFhFTikg
WzIwMTItMDktMDYgMjA6MDk6MTBdIFBDSSBhZGQgZGV2aWNlIDAwMDA6MGE6MDAuNA0KKFhF
TikgWzIwMTItMDktMDYgMjA6MDk6MTBdIFBDSSBhZGQgZGV2aWNlIDAwMDA6MGE6MDAuNQ0K
KFhFTikgWzIwMTItMDktMDYgMjA6MDk6MTBdIFBDSSBhZGQgZGV2aWNlIDAwMDA6MGE6MDAu
Ng0KKFhFTikgWzIwMTItMDktMDYgMjA6MDk6MTBdIFBDSSBhZGQgZGV2aWNlIDAwMDA6MGE6
MDAuNw0KKFhFTikgWzIwMTItMDktMDYgMjA6MDk6MTBdIFBDSSBhZGQgZGV2aWNlIDAwMDA6
MDk6MDAuMA0KKFhFTikgWzIwMTItMDktMDYgMjA6MDk6MTBdIFBDSSBhZGQgZGV2aWNlIDAw
MDA6MDg6MDAuMA0KKFhFTikgWzIwMTItMDktMDYgMjA6MDk6MTBdIFBDSSBhZGQgZGV2aWNl
IDAwMDA6MDc6MDAuMA0KKFhFTikgWzIwMTItMDktMDYgMjA6MDk6MTBdIFBDSSBhZGQgZGV2
aWNlIDAwMDA6MDY6MDAuMA0KKFhFTikgWzIwMTItMDktMDYgMjA6MDk6MTBdIFBDSSBhZGQg
ZGV2aWNlIDAwMDA6MDY6MDAuMQ0KKFhFTikgWzIwMTItMDktMDYgMjA6MDk6MTBdIFBDSSBh
ZGQgZGV2aWNlIDAwMDA6MDU6MDAuMA0KKFhFTikgWzIwMTItMDktMDYgMjA6MDk6MTBdIFBD
SSBhZGQgZGV2aWNlIDAwMDA6MDQ6MDAuMA0KKFhFTikgWzIwMTItMDktMDYgMjA6MDk6MTBd
IFBDSSBhZGQgZGV2aWNlIDAwMDA6MDQ6MDAuMQ0KKFhFTikgWzIwMTItMDktMDYgMjA6MDk6
MTBdIFBDSSBhZGQgZGV2aWNlIDAwMDA6MDQ6MDAuMg0KKFhFTikgWzIwMTItMDktMDYgMjA6
MDk6MTBdIFBDSSBhZGQgZGV2aWNlIDAwMDA6MDQ6MDAuMw0KKFhFTikgWzIwMTItMDktMDYg
MjA6MDk6MTBdIFBDSSBhZGQgZGV2aWNlIDAwMDA6MDQ6MDAuNA0KKFhFTikgWzIwMTItMDkt
MDYgMjA6MDk6MTBdIFBDSSBhZGQgZGV2aWNlIDAwMDA6MDQ6MDAuNQ0KKFhFTikgWzIwMTIt
MDktMDYgMjA6MDk6MTBdIFBDSSBhZGQgZGV2aWNlIDAwMDA6MDQ6MDAuNg0KKFhFTikgWzIw
MTItMDktMDYgMjA6MDk6MTBdIFBDSSBhZGQgZGV2aWNlIDAwMDA6MDQ6MDAuNw0KKFhFTikg
WzIwMTItMDktMDYgMjA6MDk6MTBdIFBDSSBhZGQgZGV2aWNlIDAwMDA6MDM6MDYuMA0KKFhF
TikgWzIwMTItMDktMDYgMjA6MDk6MTBdIElPQVBJQ1swXTogU2V0IFBDSSByb3V0aW5nIGVu
dHJ5ICg2LTggLT4gMHg1OCAtPiBJUlEgOCBNb2RlOjAgQWN0aXZlOjApDQooWEVOKSBbMjAx
Mi0wOS0wNiAyMDowOToxMF0gSU9BUElDWzBdOiBTZXQgUENJIHJvdXRpbmcgZW50cnkgKDYt
MTMgLT4gMHg4OCAtPiBJUlEgMTMgTW9kZTowIEFjdGl2ZTowKQ0KKFhFTikgWzIwMTItMDkt
MDYgMjA6MDk6MTBdIElPQVBJQ1sxXTogU2V0IFBDSSByb3V0aW5nIGVudHJ5ICg3LTI4IC0+
IDB4YTAgLT4gSVJRIDUyIE1vZGU6MSBBY3RpdmU6MSkNCihYRU4pIFsyMDEyLTA5LTA2IDIw
OjA5OjEwXSBJT0FQSUNbMV06IFNldCBQQ0kgcm91dGluZyBlbnRyeSAoNy0yOSAtPiAweGE4
IC0+IElSUSA1MyBNb2RlOjEgQWN0aXZlOjEpDQooWEVOKSBbMjAxMi0wOS0wNiAyMDowOTox
MF0gSU9BUElDWzFdOiBTZXQgUENJIHJvdXRpbmcgZW50cnkgKDctMzAgLT4gMHhiMCAtPiBJ
UlEgNTQgTW9kZToxIEFjdGl2ZToxKQ0KKFhFTikgWzIwMTItMDktMDYgMjA6MDk6MTBdIElP
QVBJQ1swXTogU2V0IFBDSSByb3V0aW5nIGVudHJ5ICg2LTE2IC0+IDB4YjggLT4gSVJRIDE2
IE1vZGU6MSBBY3RpdmU6MSkNCihYRU4pIFsyMDEyLTA5LTA2IDIwOjA5OjEwXSBJT0FQSUNb
MF06IFNldCBQQ0kgcm91dGluZyBlbnRyeSAoNi0xOCAtPiAweGMwIC0+IElSUSAxOCBNb2Rl
OjEgQWN0aXZlOjEpDQooWEVOKSBbMjAxMi0wOS0wNiAyMDowOToxMF0gSU9BUElDWzBdOiBT
ZXQgUENJIHJvdXRpbmcgZW50cnkgKDYtMTcgLT4gMHhjOCAtPiBJUlEgMTcgTW9kZToxIEFj
dGl2ZToxKQ0KKFhFTikgWzIwMTItMDktMDYgMjA6MDk6MTBdIElPQVBJQ1sxXTogU2V0IFBD
SSByb3V0aW5nIGVudHJ5ICg3LTQgLT4gMHhkMCAtPiBJUlEgMjggTW9kZToxIEFjdGl2ZTox
KQ0KKFhFTikgWzIwMTItMDktMDYgMjA6MDk6MTBdIElPQVBJQ1sxXTogU2V0IFBDSSByb3V0
aW5nIGVudHJ5ICg3LTUgLT4gMHhkOCAtPiBJUlEgMjkgTW9kZToxIEFjdGl2ZToxKQ0KKFhF
TikgWzIwMTItMDktMDYgMjA6MDk6MTBdIElPQVBJQ1sxXTogU2V0IFBDSSByb3V0aW5nIGVu
dHJ5ICg3LTYgLT4gMHgyMSAtPiBJUlEgMzAgTW9kZToxIEFjdGl2ZToxKQ0KKFhFTikgWzIw
MTItMDktMDYgMjA6MDk6MTBdIElPQVBJQ1sxXTogU2V0IFBDSSByb3V0aW5nIGVudHJ5ICg3
LTcgLT4gMHgyOSAtPiBJUlEgMzEgTW9kZToxIEFjdGl2ZToxKQ0KKFhFTikgWzIwMTItMDkt
MDYgMjA6MDk6MTBdIElPQVBJQ1sxXTogU2V0IFBDSSByb3V0aW5nIGVudHJ5ICg3LTE2IC0+
IDB4MzEgLT4gSVJRIDQwIE1vZGU6MSBBY3RpdmU6MSkNCihYRU4pIFsyMDEyLTA5LTA2IDIw
OjA5OjEwXSBJT0FQSUNbMV06IFNldCBQQ0kgcm91dGluZyBlbnRyeSAoNy0xNyAtPiAweDM5
IC0+IElSUSA0MSBNb2RlOjEgQWN0aXZlOjEpDQooWEVOKSBbMjAxMi0wOS0wNiAyMDowOTox
MF0gSU9BUElDWzFdOiBTZXQgUENJIHJvdXRpbmcgZW50cnkgKDctMTggLT4gMHg0MSAtPiBJ
UlEgNDIgTW9kZToxIEFjdGl2ZToxKQ0KKFhFTikgWzIwMTItMDktMDYgMjA6MDk6MTBdIElP
QVBJQ1sxXTogU2V0IFBDSSByb3V0aW5nIGVudHJ5ICg3LTE5IC0+IDB4NDkgLT4gSVJRIDQz
IE1vZGU6MSBBY3RpdmU6MSkNCihYRU4pIFsyMDEyLTA5LTA2IDIwOjA5OjExXSBJT0FQSUNb
MF06IFNldCBQQ0kgcm91dGluZyBlbnRyeSAoNi0yMiAtPiAweDk5IC0+IElSUSAyMiBNb2Rl
OjEgQWN0aXZlOjEpDQooWEVOKSBbMjAxMi0wOS0wNiAyMDowOToxMV0gSU9BUElDWzFdOiBT
ZXQgUENJIHJvdXRpbmcgZW50cnkgKDctMTIgLT4gMHhhMSAtPiBJUlEgMzYgTW9kZToxIEFj
dGl2ZToxKQ0KKFhFTikgWzIwMTItMDktMDYgMjA6MDk6MTFdIElPQVBJQ1sxXTogU2V0IFBD
SSByb3V0aW5nIGVudHJ5ICg3LTIzIC0+IDB4YTkgLT4gSVJRIDQ3IE1vZGU6MSBBY3RpdmU6
MSkNCihYRU4pIFsyMDEyLTA5LTA2IDIwOjA5OjExXSBJT0FQSUNbMF06IFNldCBQQ0kgcm91
dGluZyBlbnRyeSAoNi0xOSAtPiAweGIxIC0+IElSUSAxOSBNb2RlOjEgQWN0aXZlOjEpDQoo
WEVOKSBbMjAxMi0wOS0wNiAyMDowOToxMV0gSU9BUElDWzFdOiBTZXQgUENJIHJvdXRpbmcg
ZW50cnkgKDctMjIgLT4gMHhjMSAtPiBJUlEgNDYgTW9kZToxIEFjdGl2ZToxKQ0KKFhFTikg
WzIwMTItMDktMDYgMjA6MDk6MTFdIElPQVBJQ1sxXTogU2V0IFBDSSByb3V0aW5nIGVudHJ5
ICg3LTI3IC0+IDB4ZDEgLT4gSVJRIDUxIE1vZGU6MSBBY3RpdmU6MSkNCihYRU4pIFsyMDEy
LTA5LTA2IDIwOjA5OjEzXSBJT0FQSUNbMV06IFNldCBQQ0kgcm91dGluZyBlbnRyeSAoNy05
IC0+IDB4MjIgLT4gSVJRIDMzIE1vZGU6MSBBY3RpdmU6MSkNCihYRU4pIFsyMDEyLTA5LTA2
IDIwOjEwOjE5XSB0cmFwcy5jOjI1ODQ6ZDEgRG9tYWluIGF0dGVtcHRlZCBXUk1TUiAwMDAw
MDAwMGMwMDEwMDA0IGZyb20gMHgwMDAwNmZiMDM5ZGU3OTAwIHRvIDB4MDAwMDAwMDAwMDAw
YWJjZC4NCihYRU4pIFsyMDEyLTA5LTA2IDIwOjEwOjI1XSB0cmFwcy5jOjI1ODQ6ZDIgRG9t
YWluIGF0dGVtcHRlZCBXUk1TUiAwMDAwMDAwMGMwMDEwMDA0IGZyb20gMHgwMDAwYTE5NWM0
MGY2MThmIHRvIDB4MDAwMDAwMDAwMDAwYWJjZC4NCihYRU4pIFsyMDEyLTA5LTA2IDIwOjEw
OjM3XSB0cmFwcy5jOjI1ODQ6ZDMgRG9tYWluIGF0dGVtcHRlZCBXUk1TUiAwMDAwMDAwMGMw
MDEwMDA0IGZyb20gMHgwMDAwNDIzNDVhMGRhNTQ1IHRvIDB4MDAwMDAwMDAwMDAwYWJjZC4N
CihYRU4pIFsyMDEyLTA5LTA2IDIwOjEwOjM3XSB0cmFwcy5jOjI1ODQ6ZDQgRG9tYWluIGF0
dGVtcHRlZCBXUk1TUiAwMDAwMDAwMGMwMDEwMDA0IGZyb20gMHgwMDAwYTE5NWM0MGY2MThm
IHRvIDB4MDAwMDAwMDAwMDAwYWJjZC4NCihYRU4pIFsyMDEyLTA5LTA2IDIwOjEwOjQ0XSB0
cmFwcy5jOjI1ODQ6ZDUgRG9tYWluIGF0dGVtcHRlZCBXUk1TUiAwMDAwMDAwMGMwMDEwMDA0
IGZyb20gMHgwMDAwNmZiMDM5ZGU3OTAwIHRvIDB4MDAwMDAwMDAwMDAwYWJjZC4NCihYRU4p
IFsyMDEyLTA5LTA2IDIwOjEwOjQ5XSB0cmFwcy5jOjI1ODQ6ZDYgRG9tYWluIGF0dGVtcHRl
ZCBXUk1TUiAwMDAwMDAwMGMwMDEwMDA0IGZyb20gMHgwMDAwNDIzNDVhMGRhNTQ1IHRvIDB4
MDAwMDAwMDAwMDAwYWJjZC4NCihYRU4pIFsyMDEyLTA5LTA2IDIwOjEwOjU2XSB0cmFwcy5j
OjI1ODQ6ZDcgRG9tYWluIGF0dGVtcHRlZCBXUk1TUiAwMDAwMDAwMGMwMDEwMDA0IGZyb20g
MHgwMDAwNDIzNDVhMGRhNTQ1IHRvIDB4MDAwMDAwMDAwMDAwYWJjZC4NCihYRU4pIFsyMDEy
LTA5LTA2IDIwOjExOjAyXSB0cmFwcy5jOjI1ODQ6ZDggRG9tYWluIGF0dGVtcHRlZCBXUk1T
UiAwMDAwMDAwMGMwMDEwMDA0IGZyb20gMHgwMDAwNmZiMDM5ZGU3OTAwIHRvIDB4MDAwMDAw
MDAwMDAwYWJjZC4NCihYRU4pIFsyMDEyLTA5LTA2IDIwOjExOjA4XSB0cmFwcy5jOjI1ODQ6
ZDkgRG9tYWluIGF0dGVtcHRlZCBXUk1TUiAwMDAwMDAwMGMwMDEwMDA0IGZyb20gMHgwMDAw
ODY3OWMwMmI0MTY1IHRvIDB4MDAwMDAwMDAwMDAwYWJjZC4NCihYRU4pIFsyMDEyLTA5LTA2
IDIwOjExOjE1XSB0cmFwcy5jOjI1ODQ6ZDEwIERvbWFpbiBhdHRlbXB0ZWQgV1JNU1IgMDAw
MDAwMDBjMDAxMDAwNCBmcm9tIDB4MDAwMDQyMzQ1YTBkYTU0NSB0byAweDAwMDAwMDAwMDAw
MGFiY2QuDQooWEVOKSBbMjAxMi0wOS0wNiAyMDoxMToyNF0gQU1ELVZpOiBEaXNhYmxlOiBk
ZXZpY2UgaWQgPSAweDAwYTQsIGRvbWFpbiA9IDAsIHBhZ2luZyBtb2RlID0gMw0KKFhFTikg
WzIwMTItMDktMDYgMjA6MTE6MjRdIEFNRC1WaTogU2V0dXAgSS9PIHBhZ2UgdGFibGU6IGRl
dmljZSBpZCA9IDB4MDBhNCwgcm9vdCB0YWJsZSA9IDB4MThlMGExMDAwLCBkb21haW4gPSAx
MSwgcGFnaW5nIG1vZGUgPSAzDQooWEVOKSBbMjAxMi0wOS0wNiAyMDoxMToyNF0gQU1ELVZp
OiBSZS1hc3NpZ24gMDAwMDowMzowNi4wIGZyb20gZG9tMCB0byBkb20xMQ0KKFhFTikgWzIw
MTItMDktMDYgMjA6MTE6MjVdIHRyYXBzLmM6MjU4NDpkMTEgRG9tYWluIGF0dGVtcHRlZCBX
Uk1TUiAwMDAwMDAwMGMwMDEwMDA0IGZyb20gMHgwMDAwYTE5NWM0MGY2MThmIHRvIDB4MDAw
MDAwMDAwMDAwYWJjZC4NCihYRU4pIFsyMDEyLTA5LTA2IDIwOjExOjMxXSB0cmFwcy5jOjI1
ODQ6ZDEyIERvbWFpbiBhdHRlbXB0ZWQgV1JNU1IgMDAwMDAwMDBjMDAxMDAwNCBmcm9tIDB4
MDAwMDg2NzljMDJiNDE2NSB0byAweDAwMDAwMDAwMDAwMGFiY2QuDQooWEVOKSBbMjAxMi0w
OS0wNiAyMDoxMTozOF0gdHJhcHMuYzoyNTg0OmQxMyBEb21haW4gYXR0ZW1wdGVkIFdSTVNS
IDAwMDAwMDAwYzAwMTAwMDQgZnJvbSAweDAwMDBhMTk1YzQwZjYxOGYgdG8gMHgwMDAwMDAw
MDAwMDBhYmNkLg0KKFhFTikgWzIwMTItMDktMDYgMjA6MTE6NDVdIEFNRC1WaTogRGlzYWJs
ZTogZGV2aWNlIGlkID0gMHgwYTAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMNCihY
RU4pIFsyMDEyLTA5LTA2IDIwOjExOjQ1XSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxl
OiBkZXZpY2UgaWQgPSAweDBhMDAsIHJvb3QgdGFibGUgPSAweDFlMWZjMDAwMCwgZG9tYWlu
ID0gMTQsIHBhZ2luZyBtb2RlID0gMw0KKFhFTikgWzIwMTItMDktMDYgMjA6MTE6NDVdIEFN
RC1WaTogUmUtYXNzaWduIDAwMDA6MGE6MDAuMCBmcm9tIGRvbTAgdG8gZG9tMTQNCihYRU4p
IFsyMDEyLTA5LTA2IDIwOjExOjQ1XSBBTUQtVmk6IERpc2FibGU6IGRldmljZSBpZCA9IDB4
MGEwMSwgZG9tYWluID0gMCwgcGFnaW5nIG1vZGUgPSAzDQooWEVOKSBbMjAxMi0wOS0wNiAy
MDoxMTo0NV0gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHgw
YTAxLCByb290IHRhYmxlID0gMHgxZTFmYzAwMDAsIGRvbWFpbiA9IDE0LCBwYWdpbmcgbW9k
ZSA9IDMNCihYRU4pIFsyMDEyLTA5LTA2IDIwOjExOjQ1XSBBTUQtVmk6IFJlLWFzc2lnbiAw
MDAwOjBhOjAwLjEgZnJvbSBkb20wIHRvIGRvbTE0DQooWEVOKSBbMjAxMi0wOS0wNiAyMDox
MTo0NV0gQU1ELVZpOiBEaXNhYmxlOiBkZXZpY2UgaWQgPSAweDBhMDIsIGRvbWFpbiA9IDAs
IHBhZ2luZyBtb2RlID0gMw0KKFhFTikgWzIwMTItMDktMDYgMjA6MTE6NDVdIEFNRC1WaTog
U2V0dXAgSS9PIHBhZ2UgdGFibGU6IGRldmljZSBpZCA9IDB4MGEwMiwgcm9vdCB0YWJsZSA9
IDB4MWUxZmMwMDAwLCBkb21haW4gPSAxNCwgcGFnaW5nIG1vZGUgPSAzDQooWEVOKSBbMjAx
Mi0wOS0wNiAyMDoxMTo0NV0gQU1ELVZpOiBSZS1hc3NpZ24gMDAwMDowYTowMC4yIGZyb20g
ZG9tMCB0byBkb20xNA0KKFhFTikgWzIwMTItMDktMDYgMjA6MTE6NDVdIEFNRC1WaTogRGlz
YWJsZTogZGV2aWNlIGlkID0gMHgwYTAzLCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMN
CihYRU4pIFsyMDEyLTA5LTA2IDIwOjExOjQ1XSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRh
YmxlOiBkZXZpY2UgaWQgPSAweDBhMDMsIHJvb3QgdGFibGUgPSAweDFlMWZjMDAwMCwgZG9t
YWluID0gMTQsIHBhZ2luZyBtb2RlID0gMw0KKFhFTikgWzIwMTItMDktMDYgMjA6MTE6NDVd
IEFNRC1WaTogUmUtYXNzaWduIDAwMDA6MGE6MDAuMyBmcm9tIGRvbTAgdG8gZG9tMTQNCihY
RU4pIFsyMDEyLTA5LTA2IDIwOjExOjQ1XSBBTUQtVmk6IERpc2FibGU6IGRldmljZSBpZCA9
IDB4MGEwNCwgZG9tYWluID0gMCwgcGFnaW5nIG1vZGUgPSAzDQooWEVOKSBbMjAxMi0wOS0w
NiAyMDoxMTo0NV0gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0g
MHgwYTA0LCByb290IHRhYmxlID0gMHgxZTFmYzAwMDAsIGRvbWFpbiA9IDE0LCBwYWdpbmcg
bW9kZSA9IDMNCihYRU4pIFsyMDEyLTA5LTA2IDIwOjExOjQ1XSBBTUQtVmk6IFJlLWFzc2ln
biAwMDAwOjBhOjAwLjQgZnJvbSBkb20wIHRvIGRvbTE0DQooWEVOKSBbMjAxMi0wOS0wNiAy
MDoxMTo0NV0gQU1ELVZpOiBEaXNhYmxlOiBkZXZpY2UgaWQgPSAweDBhMDUsIGRvbWFpbiA9
IDAsIHBhZ2luZyBtb2RlID0gMw0KKFhFTikgWzIwMTItMDktMDYgMjA6MTE6NDVdIEFNRC1W
aTogU2V0dXAgSS9PIHBhZ2UgdGFibGU6IGRldmljZSBpZCA9IDB4MGEwNSwgcm9vdCB0YWJs
ZSA9IDB4MWUxZmMwMDAwLCBkb21haW4gPSAxNCwgcGFnaW5nIG1vZGUgPSAzDQooWEVOKSBb
MjAxMi0wOS0wNiAyMDoxMTo0NV0gQU1ELVZpOiBSZS1hc3NpZ24gMDAwMDowYTowMC41IGZy
b20gZG9tMCB0byBkb20xNA0KKFhFTikgWzIwMTItMDktMDYgMjA6MTE6NDVdIEFNRC1WaTog
RGlzYWJsZTogZGV2aWNlIGlkID0gMHgwYTA2LCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9
IDMNCihYRU4pIFsyMDEyLTA5LTA2IDIwOjExOjQ1XSBBTUQtVmk6IFNldHVwIEkvTyBwYWdl
IHRhYmxlOiBkZXZpY2UgaWQgPSAweDBhMDYsIHJvb3QgdGFibGUgPSAweDFlMWZjMDAwMCwg
ZG9tYWluID0gMTQsIHBhZ2luZyBtb2RlID0gMw0KKFhFTikgWzIwMTItMDktMDYgMjA6MTE6
NDVdIEFNRC1WaTogUmUtYXNzaWduIDAwMDA6MGE6MDAuNiBmcm9tIGRvbTAgdG8gZG9tMTQN
CihYRU4pIFsyMDEyLTA5LTA2IDIwOjExOjQ1XSBBTUQtVmk6IERpc2FibGU6IGRldmljZSBp
ZCA9IDB4MGEwNywgZG9tYWluID0gMCwgcGFnaW5nIG1vZGUgPSAzDQooWEVOKSBbMjAxMi0w
OS0wNiAyMDoxMTo0NV0gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlk
ID0gMHgwYTA3LCByb290IHRhYmxlID0gMHgxZTFmYzAwMDAsIGRvbWFpbiA9IDE0LCBwYWdp
bmcgbW9kZSA9IDMNCihYRU4pIFsyMDEyLTA5LTA2IDIwOjExOjQ1XSBBTUQtVmk6IFJlLWFz
c2lnbiAwMDAwOjBhOjAwLjcgZnJvbSBkb20wIHRvIGRvbTE0DQooWEVOKSBbMjAxMi0wOS0w
NiAyMDoxMTo0NV0gQU1ELVZpOiBEaXNhYmxlOiBkZXZpY2UgaWQgPSAweDA3MDAsIGRvbWFp
biA9IDAsIHBhZ2luZyBtb2RlID0gMw0KKFhFTikgWzIwMTItMDktMDYgMjA6MTE6NDVdIEFN
RC1WaTogU2V0dXAgSS9PIHBhZ2UgdGFibGU6IGRldmljZSBpZCA9IDB4MDcwMCwgcm9vdCB0
YWJsZSA9IDB4MWUxZmMwMDAwLCBkb21haW4gPSAxNCwgcGFnaW5nIG1vZGUgPSAzDQooWEVO
KSBbMjAxMi0wOS0wNiAyMDoxMTo0NV0gQU1ELVZpOiBSZS1hc3NpZ24gMDAwMDowNzowMC4w
IGZyb20gZG9tMCB0byBkb20xNA0KKFhFTikgWzIwMTItMDktMDYgMjA6MTE6NDVdIHRyYXBz
LmM6MjU4NDpkMTQgRG9tYWluIGF0dGVtcHRlZCBXUk1TUiAwMDAwMDAwMGMwMDEwMDA0IGZy
b20gMHgwMDAwNzg1MTkwZmI0ZTBmIHRvIDB4MDAwMDAwMDAwMDAwYWJjZC4NCihYRU4pIFsy
MDEyLTA5LTA2IDIwOjExOjUxXSBBTUQtVmk6IFNoYXJlIHAybSB0YWJsZSB3aXRoIGlvbW11
OiBwMm0gdGFibGUgPSAweGE3N2E4DQooWEVOKSBbMjAxMi0wOS0wNiAyMDoxMTo1Nl0gSFZN
MTU6IEhWTSBMb2FkZXINCihYRU4pIFsyMDEyLTA5LTA2IDIwOjExOjU2XSBIVk0xNTogRGV0
ZWN0ZWQgWGVuIHY0LjIuMC1yYzQtcHJlDQooWEVOKSBbMjAxMi0wOS0wNiAyMDoxMTo1Nl0g
SFZNMTU6IFhlbmJ1cyByaW5ncyBAMHhmZWZmYzAwMCwgZXZlbnQgY2hhbm5lbCA0DQooWEVO
KSBbMjAxMi0wOS0wNiAyMDoxMTo1Nl0gSFZNMTU6IFN5c3RlbSByZXF1ZXN0ZWQgUk9NQklP
Uw0KKFhFTikgWzIwMTItMDktMDYgMjA6MTE6NTZdIEhWTTE1OiBDUFUgc3BlZWQgaXMgMzIw
MCBNSHoNCihYRU4pIFsyMDEyLTA5LTA2IDIwOjExOjU2XSBpcnEuYzoyNzA6IERvbTE1IFBD
SSBsaW5rIDAgY2hhbmdlZCAwIC0+IDUNCihYRU4pIFsyMDEyLTA5LTA2IDIwOjExOjU2XSBI
Vk0xNTogUENJLUlTQSBsaW5rIDAgcm91dGVkIHRvIElSUTUNCihYRU4pIFsyMDEyLTA5LTA2
IDIwOjExOjU2XSBpcnEuYzoyNzA6IERvbTE1IFBDSSBsaW5rIDEgY2hhbmdlZCAwIC0+IDEw
DQooWEVOKSBbMjAxMi0wOS0wNiAyMDoxMTo1Nl0gSFZNMTU6IFBDSS1JU0EgbGluayAxIHJv
dXRlZCB0byBJUlExMA0KKFhFTikgWzIwMTItMDktMDYgMjA6MTE6NTZdIGlycS5jOjI3MDog
RG9tMTUgUENJIGxpbmsgMiBjaGFuZ2VkIDAgLT4gMTENCihYRU4pIFsyMDEyLTA5LTA2IDIw
OjExOjU2XSBIVk0xNTogUENJLUlTQSBsaW5rIDIgcm91dGVkIHRvIElSUTExDQooWEVOKSBb
MjAxMi0wOS0wNiAyMDoxMTo1Nl0gaXJxLmM6MjcwOiBEb20xNSBQQ0kgbGluayAzIGNoYW5n
ZWQgMCAtPiA1DQooWEVOKSBbMjAxMi0wOS0wNiAyMDoxMTo1Nl0gSFZNMTU6IFBDSS1JU0Eg
bGluayAzIHJvdXRlZCB0byBJUlE1DQooWEVOKSBbMjAxMi0wOS0wNiAyMDoxMTo1Nl0gSFZN
MTU6IHBjaSBkZXYgMDE6MiBJTlRELT5JUlE1DQooWEVOKSBbMjAxMi0wOS0wNiAyMDoxMTo1
Nl0gSFZNMTU6IHBjaSBkZXYgMDE6MyBJTlRBLT5JUlExMA0KKFhFTikgWzIwMTItMDktMDYg
MjA6MTE6NTZdIEhWTTE1OiBwY2kgZGV2IDAzOjAgSU5UQS0+SVJRNQ0KKFhFTikgWzIwMTIt
MDktMDYgMjA6MTE6NTZdIEhWTTE1OiBwY2kgZGV2IDA0OjAgSU5UQS0+SVJRNQ0KKFhFTikg
WzIwMTItMDktMDYgMjA6MTE6NTZdIEhWTTE1OiBwY2kgZGV2IDAyOjAgYmFyIDEwIHNpemUg
MDIwMDAwMDA6IGYwMDAwMDA4DQooWEVOKSBbMjAxMi0wOS0wNiAyMDoxMTo1Nl0gSFZNMTU6
IHBjaSBkZXYgMDM6MCBiYXIgMTQgc2l6ZSAwMTAwMDAwMDogZjIwMDAwMDgNCihYRU4pIFsy
MDEyLTA5LTA2IDIwOjExOjU2XSBIVk0xNTogcGNpIGRldiAwNDowIGJhciAxMCBzaXplIDAw
MDIwMDAwOiBmMzAwMDAwMA0KKFhFTikgWzIwMTItMDktMDYgMjA6MTE6NTZdIEhWTTE1OiBw
Y2kgZGV2IDAyOjAgYmFyIDE0IHNpemUgMDAwMDEwMDA6IGYzMDIwMDAwDQooWEVOKSBbMjAx
Mi0wOS0wNiAyMDoxMTo1Nl0gSFZNMTU6IHBjaSBkZXYgMDM6MCBiYXIgMTAgc2l6ZSAwMDAw
MDEwMDogMDAwMGMwMDENCihYRU4pIFsyMDEyLTA5LTA2IDIwOjExOjU2XSBIVk0xNTogcGNp
IGRldiAwNDowIGJhciAxNCBzaXplIDAwMDAwMDQwOiAwMDAwYzEwMQ0KKFhFTikgWzIwMTIt
MDktMDYgMjA6MTE6NTZdIEhWTTE1OiBwY2kgZGV2IDAxOjIgYmFyIDIwIHNpemUgMDAwMDAw
MjA6IDAwMDBjMTQxDQooWEVOKSBbMjAxMi0wOS0wNiAyMDoxMTo1Nl0gSFZNMTU6IHBjaSBk
ZXYgMDE6MSBiYXIgMjAgc2l6ZSAwMDAwMDAxMDogMDAwMGMxNjENCihYRU4pIFsyMDEyLTA5
LTA2IDIwOjExOjU2XSBIVk0xNTogTXVsdGlwcm9jZXNzb3IgaW5pdGlhbGlzYXRpb246DQoo
WEVOKSBbMjAxMi0wOS0wNiAyMDoxMTo1Nl0gSFZNMTU6ICAtIENQVTAgLi4uIDQ4LWJpdCBw
aHlzIC4uLiBmaXhlZCBNVFJScyAuLi4gdmFyIE1UUlJzIFsyLzhdIC4uLiBkb25lLg0KKFhF
TikgWzIwMTItMDktMDYgMjA6MTE6NTZdIEhWTTE1OiAgLSBDUFUxIC4uLiA0OC1iaXQgcGh5
cyAuLi4gZml4ZWQgTVRSUnMgLi4uIHZhciBNVFJScyBbMi84XSAuLi4gZG9uZS4NCihYRU4p
IFsyMDEyLTA5LTA2IDIwOjExOjU2XSBIVk0xNTogVGVzdGluZyBIVk0gZW52aXJvbm1lbnQ6
DQooWEVOKSBbMjAxMi0wOS0wNiAyMDoxMTo1Nl0gSFZNMTU6ICAtIFJFUCBJTlNCIGFjcm9z
cyBwYWdlIGJvdW5kYXJpZXMgLi4uIHBhc3NlZA0KKFhFTikgWzIwMTItMDktMDYgMjA6MTE6
NTZdIEhWTTE1OiAgLSBHUyBiYXNlIE1TUnMgYW5kIFNXQVBHUyAuLi4gcGFzc2VkDQooWEVO
KSBbMjAxMi0wOS0wNiAyMDoxMTo1Nl0gSFZNMTU6IFBhc3NlZCAyIG9mIDIgdGVzdHMNCihY
RU4pIFsyMDEyLTA5LTA2IDIwOjExOjU2XSBIVk0xNTogV3JpdGluZyBTTUJJT1MgdGFibGVz
IC4uLg0KKFhFTikgWzIwMTItMDktMDYgMjA6MTE6NTZdIEhWTTE1OiBMb2FkaW5nIFJPTUJJ
T1MgLi4uDQooWEVOKSBbMjAxMi0wOS0wNiAyMDoxMTo1Nl0gSFZNMTU6IDk2NjAgYnl0ZXMg
b2YgUk9NQklPUyBoaWdoLW1lbW9yeSBleHRlbnNpb25zOg0KKFhFTikgWzIwMTItMDktMDYg
MjA6MTE6NTZdIEhWTTE1OiAgIFJlbG9jYXRpbmcgdG8gMHhmYzAwMTAwMC0weGZjMDAzNWJj
IC4uLiBkb25lDQooWEVOKSBbMjAxMi0wOS0wNiAyMDoxMTo1Nl0gSFZNMTU6IENyZWF0aW5n
IE1QIHRhYmxlcyAuLi4NCihYRU4pIFsyMDEyLTA5LTA2IDIwOjExOjU2XSBIVk0xNTogTG9h
ZGluZyBDaXJydXMgVkdBQklPUyAuLi4NCihYRU4pIFsyMDEyLTA5LTA2IDIwOjExOjU2XSBI
Vk0xNTogTG9hZGluZyBQQ0kgT3B0aW9uIFJPTSAuLi4NCihYRU4pIFsyMDEyLTA5LTA2IDIw
OjExOjU2XSBIVk0xNTogIC0gTWFudWZhY3R1cmVyOiBodHRwOi8vaXB4ZS5vcmcNCihYRU4p
IFsyMDEyLTA5LTA2IDIwOjExOjU2XSBIVk0xNTogIC0gUHJvZHVjdCBuYW1lOiBpUFhFDQoo
WEVOKSBbMjAxMi0wOS0wNiAyMDoxMTo1N10gSFZNMTU6IE9wdGlvbiBST01zOg0KKFhFTikg
WzIwMTItMDktMDYgMjA6MTE6NTddIEhWTTE1OiAgYzAwMDAtYzhmZmY6IFZHQSBCSU9TDQoo
WEVOKSBbMjAxMi0wOS0wNiAyMDoxMTo1N10gSFZNMTU6ICBjOTAwMC1kOWZmZjogRXRoZXJi
b290IFJPTQ0KKFhFTikgWzIwMTItMDktMDYgMjA6MTE6NTddIEhWTTE1OiBMb2FkaW5nIEFD
UEkgLi4uDQooWEVOKSBbMjAxMi0wOS0wNiAyMDoxMTo1N10gSFZNMTU6IHZtODYgVFNTIGF0
IGZjMDBmNjgwDQooWEVOKSBbMjAxMi0wOS0wNiAyMDoxMTo1N10gSFZNMTU6IEJJT1MgbWFw
Og0KKFhFTikgWzIwMTItMDktMDYgMjA6MTE6NTddIEhWTTE1OiAgZjAwMDAtZmZmZmY6IE1h
aW4gQklPUw0KKFhFTikgWzIwMTItMDktMDYgMjA6MTE6NTddIEhWTTE1OiBFODIwIHRhYmxl
Og0KKFhFTikgWzIwMTItMDktMDYgMjA6MTE6NTddIEhWTTE1OiAgWzAwXTogMDAwMDAwMDA6
MDAwMDAwMDAgLSAwMDAwMDAwMDowMDA5ZTAwMDogUkFNDQooWEVOKSBbMjAxMi0wOS0wNiAy
MDoxMTo1N10gSFZNMTU6ICBbMDFdOiAwMDAwMDAwMDowMDA5ZTAwMCAtIDAwMDAwMDAwOjAw
MGEwMDAwOiBSRVNFUlZFRA0KKFhFTikgWzIwMTItMDktMDYgMjA6MTE6NTddIEhWTTE1OiAg
SE9MRTogMDAwMDAwMDA6MDAwYTAwMDAgLSAwMDAwMDAwMDowMDBlMDAwMA0KKFhFTikgWzIw
MTItMDktMDYgMjA6MTE6NTddIEhWTTE1OiAgWzAyXTogMDAwMDAwMDA6MDAwZTAwMDAgLSAw
MDAwMDAwMDowMDEwMDAwMDogUkVTRVJWRUQNCihYRU4pIFsyMDEyLTA5LTA2IDIwOjExOjU3
XSBIVk0xNTogIFswM106IDAwMDAwMDAwOjAwMTAwMDAwIC0gMDAwMDAwMDA6MWY4MDAwMDA6
IFJBTQ0KKFhFTikgWzIwMTItMDktMDYgMjA6MTE6NTddIEhWTTE1OiAgSE9MRTogMDAwMDAw
MDA6MWY4MDAwMDAgLSAwMDAwMDAwMDpmYzAwMDAwMA0KKFhFTikgWzIwMTItMDktMDYgMjA6
MTE6NTddIEhWTTE1OiAgWzA0XTogMDAwMDAwMDA6ZmMwMDAwMDAgLSAwMDAwMDAwMTowMDAw
MDAwMDogUkVTRVJWRUQNCihYRU4pIFsyMDEyLTA5LTA2IDIwOjExOjU3XSBIVk0xNTogSW52
b2tpbmcgUk9NQklPUyAuLi4NCihYRU4pIFsyMDEyLTA5LTA2IDIwOjExOjU3XSBIVk0xNTog
JFJldmlzaW9uOiAxLjIyMSAkICREYXRlOiAyMDA4LzEyLzA3IDE3OjMyOjI5ICQNCihYRU4p
IFsyMDEyLTA5LTA2IDIwOjExOjU3XSBzdGR2Z2EuYzoxNDc6ZDE1IGVudGVyaW5nIHN0ZHZn
YSBhbmQgY2FjaGluZyBtb2Rlcw0KKFhFTikgWzIwMTItMDktMDYgMjA6MTE6NTddIEhWTTE1
OiBWR0FCaW9zICRJZDogdmdhYmlvcy5jLHYgMS42NyAyMDA4LzAxLzI3IDA5OjQ0OjEyIHZy
dXBwZXJ0IEV4cCAkDQooWEVOKSBbMjAxMi0wOS0wNiAyMDoxMTo1N10gSFZNMTU6IEJvY2hz
IEJJT1MgLSBidWlsZDogMDYvMjMvOTkNCihYRU4pIFsyMDEyLTA5LTA2IDIwOjExOjU3XSBI
Vk0xNTogJFJldmlzaW9uOiAxLjIyMSAkICREYXRlOiAyMDA4LzEyLzA3IDE3OjMyOjI5ICQN
CihYRU4pIFsyMDEyLTA5LTA2IDIwOjExOjU3XSBIVk0xNTogT3B0aW9uczogYXBtYmlvcyBw
Y2liaW9zIGVsdG9yaXRvIFBNTSANCihYRU4pIFsyMDEyLTA5LTA2IDIwOjExOjU3XSBIVk0x
NTogDQooWEVOKSBbMjAxMi0wOS0wNiAyMDoxMTo1N10gSFZNMTU6IGF0YTAtMDogUENIUz0x
NjM4My8xNi82MyB0cmFuc2xhdGlvbj1sYmEgTENIUz0xMDI0LzI1NS82Mw0KKFhFTikgWzIw
MTItMDktMDYgMjA6MTE6NTddIEhWTTE1OiBhdGEwIG1hc3RlcjogUUVNVSBIQVJERElTSyBB
VEEtNyBIYXJkLURpc2sgKDU3MjQ0IE1CeXRlcykNCihYRU4pIFsyMDEyLTA5LTA2IDIwOjEx
OjU4XSBIVk0xNTogSURFIHRpbWUgb3V0DQooWEVOKSBbMjAxMi0wOS0wNiAyMDoxMTo1OF0g
SFZNMTU6IGF0YTEgbWFzdGVyOiBRRU1VIERWRC1ST00gQVRBUEktNCBDRC1Sb20vRFZELVJv
bQ0KKFhFTikgWzIwMTItMDktMDYgMjA6MTI6MDBdIEhWTTE1OiBJREUgdGltZSBvdXQNCihY
RU4pIFsyMDEyLTA5LTA2IDIwOjEyOjAwXSBIVk0xNTogDQooWEVOKSBbMjAxMi0wOS0wNiAy
MDoxMjowMF0gSFZNMTU6IA0KKFhFTikgWzIwMTItMDktMDYgMjA6MTI6MDBdIEhWTTE1OiAN
CihYRU4pIFsyMDEyLTA5LTA2IDIwOjEyOjAwXSBIVk0xNTogUHJlc3MgRjEyIGZvciBib290
IG1lbnUuDQooWEVOKSBbMjAxMi0wOS0wNiAyMDoxMjowMF0gSFZNMTU6IA0KKFhFTikgWzIw
MTItMDktMDYgMjA6MTI6MDBdIEhWTTE1OiBCb290aW5nIGZyb20gSGFyZCBEaXNrLi4uDQoo
WEVOKSBbMjAxMi0wOS0wNiAyMDoxMjowMF0gSFZNMTU6IEJvb3RpbmcgZnJvbSAwMDAwOjdj
MDANCihYRU4pIFsyMDEyLTA5LTA2IDIwOjEyOjA0XSB0cmFwcy5jOjI1ODQ6ZDE2IERvbWFp
biBhdHRlbXB0ZWQgV1JNU1IgMDAwMDAwMDBjMDAxMDAwNCBmcm9tIDB4MDAwMDQyMzQ1YTBk
YTU0NSB0byAweDAwMDAwMDAwMDAwMGFiY2QuDQooWEVOKSBbMjAxMi0wOS0wNiAyMDoxMjoy
N10gaXJxLmM6MjcwOiBEb20xNSBQQ0kgbGluayAwIGNoYW5nZWQgNSAtPiAwDQooWEVOKSBb
MjAxMi0wOS0wNiAyMDoxMjoyN10gaXJxLmM6MjcwOiBEb20xNSBQQ0kgbGluayAxIGNoYW5n
ZWQgMTAgLT4gMA0KKFhFTikgWzIwMTItMDktMDYgMjA6MTI6MjddIGlycS5jOjI3MDogRG9t
MTUgUENJIGxpbmsgMiBjaGFuZ2VkIDExIC0+IDANCihYRU4pIFsyMDEyLTA5LTA2IDIwOjEy
OjI3XSBpcnEuYzoyNzA6IERvbTE1IFBDSSBsaW5rIDMgY2hhbmdlZCA1IC0+IDANCihYRU4p
IFsyMDEyLTA5LTA2IDIwOjEyOjI4XSBodm0uYzoyNDM1OmQxNSBndWVzdCBhdHRlbXB0ZWQg
d3JpdGUgdG8gcmVhZC1vbmx5IG1lbW9yeSBwYWdlLiBnZm49MHhkYywgbWZuPTB4YTRhMGIN
CihYRU4pIFsyMDEyLTA5LTA2IDIwOjEyOjI4XSBodm0uYzoyNDM1OmQxNSBndWVzdCBhdHRl
bXB0ZWQgd3JpdGUgdG8gcmVhZC1vbmx5IG1lbW9yeSBwYWdlLiBnZm49MHhkZCwgbWZuPTB4
YTRhMGENCihYRU4pIFsyMDEyLTA5LTA2IDIwOjEyOjI4XSBodm0uYzoyNDM1OmQxNSBndWVz
dCBhdHRlbXB0ZWQgd3JpdGUgdG8gcmVhZC1vbmx5IG1lbW9yeSBwYWdlLiBnZm49MHhkZSwg
bWZuPTB4YTRhMDkNCihYRU4pIFsyMDEyLTA5LTA2IDIwOjEyOjI4XSBodm0uYzoyNDM1OmQx
NSBndWVzdCBhdHRlbXB0ZWQgd3JpdGUgdG8gcmVhZC1vbmx5IG1lbW9yeSBwYWdlLiBnZm49
MHhkZCwgbWZuPTB4YTRhMGENCihYRU4pIFsyMDEyLTA5LTA2IDIwOjEyOjI4XSBodm0uYzoy
NDM1OmQxNSBndWVzdCBhdHRlbXB0ZWQgd3JpdGUgdG8gcmVhZC1vbmx5IG1lbW9yeSBwYWdl
LiBnZm49MHhkYywgbWZuPTB4YTRhMGINCihYRU4pIFsyMDEyLTA5LTA2IDIwOjEyOjI4XSBo
dm0uYzoyNDM1OmQxNSBndWVzdCBhdHRlbXB0ZWQgd3JpdGUgdG8gcmVhZC1vbmx5IG1lbW9y
eSBwYWdlLiBnZm49MHhkZSwgbWZuPTB4YTRhMDkNCihYRU4pIFsyMDEyLTA5LTA2IDIwOjEy
OjI4XSBodm0uYzoyNDM1OmQxNSBndWVzdCBhdHRlbXB0ZWQgd3JpdGUgdG8gcmVhZC1vbmx5
IG1lbW9yeSBwYWdlLiBnZm49MHhkZCwgbWZuPTB4YTRhMGENCihYRU4pIFsyMDEyLTA5LTA2
IDIwOjEyOjI4XSBodm0uYzoyNDM1OmQxNSBndWVzdCBhdHRlbXB0ZWQgd3JpdGUgdG8gcmVh
ZC1vbmx5IG1lbW9yeSBwYWdlLiBnZm49MHhkZSwgbWZuPTB4YTRhMDkNCihYRU4pIFsyMDEy
LTA5LTA2IDIwOjEyOjI4XSBodm0uYzoyNDM1OmQxNSBndWVzdCBhdHRlbXB0ZWQgd3JpdGUg
dG8gcmVhZC1vbmx5IG1lbW9yeSBwYWdlLiBnZm49MHhkYywgbWZuPTB4YTRhMGINCihYRU4p
IFsyMDEyLTA5LTA2IDIwOjEyOjI4XSBodm0uYzoyNDM1OmQxNSBndWVzdCBhdHRlbXB0ZWQg
d3JpdGUgdG8gcmVhZC1vbmx5IG1lbW9yeSBwYWdlLiBnZm49MHhkZCwgbWZuPTB4YTRhMGEN
CihYRU4pIFsyMDEyLTA5LTA2IDIwOjEyOjI4XSBodm0uYzoyNDM1OmQxNSBndWVzdCBhdHRl
bXB0ZWQgd3JpdGUgdG8gcmVhZC1vbmx5IG1lbW9yeSBwYWdlLiBnZm49MHhkYywgbWZuPTB4
YTRhMGINCihYRU4pIFsyMDEyLTA5LTA2IDIwOjEyOjI4XSBodm0uYzoyNDM1OmQxNSBndWVz
dCBhdHRlbXB0ZWQgd3JpdGUgdG8gcmVhZC1vbmx5IG1lbW9yeSBwYWdlLiBnZm49MHhkZCwg
bWZuPTB4YTRhMGENCihYRU4pIFsyMDEyLTA5LTA2IDIwOjEyOjI4XSBodm0uYzoyNDM1OmQx
NSBndWVzdCBhdHRlbXB0ZWQgd3JpdGUgdG8gcmVhZC1vbmx5IG1lbW9yeSBwYWdlLiBnZm49
MHhkZSwgbWZuPTB4YTRhMDkNCihYRU4pIFsyMDEyLTA5LTA2IDIwOjEyOjI4XSBodm0uYzoy
NDM1OmQxNSBndWVzdCBhdHRlbXB0ZWQgd3JpdGUgdG8gcmVhZC1vbmx5IG1lbW9yeSBwYWdl
LiBnZm49MHhkZCwgbWZuPTB4YTRhMGENCihYRU4pIFsyMDEyLTA5LTA2IDIwOjEyOjI4XSBo
dm0uYzoyNDM1OmQxNSBndWVzdCBhdHRlbXB0ZWQgd3JpdGUgdG8gcmVhZC1vbmx5IG1lbW9y
eSBwYWdlLiBnZm49MHhkYywgbWZuPTB4YTRhMGINCihYRU4pIFsyMDEyLTA5LTA2IDIwOjEy
OjI4XSBodm0uYzoyNDM1OmQxNSBndWVzdCBhdHRlbXB0ZWQgd3JpdGUgdG8gcmVhZC1vbmx5
IG1lbW9yeSBwYWdlLiBnZm49MHhkZCwgbWZuPTB4YTRhMGENCihYRU4pIFsyMDEyLTA5LTA2
IDIwOjEyOjI4XSBodm0uYzoyNDM1OmQxNSBndWVzdCBhdHRlbXB0ZWQgd3JpdGUgdG8gcmVh
ZC1vbmx5IG1lbW9yeSBwYWdlLiBnZm49MHhkYywgbWZuPTB4YTRhMGINCihYRU4pIFsyMDEy
LTA5LTA2IDIwOjEyOjI4XSBodm0uYzoyNDM1OmQxNSBndWVzdCBhdHRlbXB0ZWQgd3JpdGUg
dG8gcmVhZC1vbmx5IG1lbW9yeSBwYWdlLiBnZm49MHhkZCwgbWZuPTB4YTRhMGENCihYRU4p
IFsyMDEyLTA5LTA2IDIwOjEyOjMxXSBodm0uYzoyNDM1OmQxNSBndWVzdCBhdHRlbXB0ZWQg
d3JpdGUgdG8gcmVhZC1vbmx5IG1lbW9yeSBwYWdlLiBnZm49MHhjOSwgbWZuPTB4YTRhMWUN
CihYRU4pIFsyMDEyLTA5LTA2IDIwOjEyOjMxXSBodm0uYzoyNDM1OmQxNSBndWVzdCBhdHRl
bXB0ZWQgd3JpdGUgdG8gcmVhZC1vbmx5IG1lbW9yeSBwYWdlLiBnZm49MHhjYiwgbWZuPTB4
YTRhMWMNCihYRU4pIFsyMDEyLTA5LTA2IDIwOjEyOjMxXSBodm0uYzoyNDM1OmQxNSBndWVz
dCBhdHRlbXB0ZWQgd3JpdGUgdG8gcmVhZC1vbmx5IG1lbW9yeSBwYWdlLiBnZm49MHhjZCwg
bWZuPTB4YTRhMWENCihYRU4pIFsyMDEyLTA5LTA2IDIwOjEyOjMxXSBodm0uYzoyNDM1OmQx
NSBndWVzdCBhdHRlbXB0ZWQgd3JpdGUgdG8gcmVhZC1vbmx5IG1lbW9yeSBwYWdlLiBnZm49
MHhjZiwgbWZuPTB4YTRhMTgNCihYRU4pIFsyMDEyLTA5LTA2IDIwOjEyOjMxXSBodm0uYzoy
NDM1OmQxNSBndWVzdCBhdHRlbXB0ZWQgd3JpdGUgdG8gcmVhZC1vbmx5IG1lbW9yeSBwYWdl
LiBnZm49MHhkMSwgbWZuPTB4YTRhMTYNCihYRU4pIFsyMDEyLTA5LTA2IDIwOjEyOjMxXSBo
dm0uYzoyNDM1OmQxNSBndWVzdCBhdHRlbXB0ZWQgd3JpdGUgdG8gcmVhZC1vbmx5IG1lbW9y
eSBwYWdlLiBnZm49MHhkMywgbWZuPTB4YTRhMTQNCihYRU4pIFsyMDEyLTA5LTA2IDIwOjEy
OjMxXSBodm0uYzoyNDM1OmQxNSBndWVzdCBhdHRlbXB0ZWQgd3JpdGUgdG8gcmVhZC1vbmx5
IG1lbW9yeSBwYWdlLiBnZm49MHhkNSwgbWZuPTB4YTRhMTINCihYRU4pIFsyMDEyLTA5LTA2
IDIwOjEyOjMxXSBodm0uYzoyNDM1OmQxNSBndWVzdCBhdHRlbXB0ZWQgd3JpdGUgdG8gcmVh
ZC1vbmx5IG1lbW9yeSBwYWdlLiBnZm49MHhkNywgbWZuPTB4YTRhMTANCihYRU4pIFsyMDEy
LTA5LTA2IDIwOjEyOjMxXSBodm0uYzoyNDM1OmQxNSBndWVzdCBhdHRlbXB0ZWQgd3JpdGUg
dG8gcmVhZC1vbmx5IG1lbW9yeSBwYWdlLiBnZm49MHhkOSwgbWZuPTB4YTRhMGUNCihYRU4p
IFsyMDEyLTA5LTA2IDIwOjEyOjMxXSBodm0uYzoyNDM1OmQxNSBndWVzdCBhdHRlbXB0ZWQg
d3JpdGUgdG8gcmVhZC1vbmx5IG1lbW9yeSBwYWdlLiBnZm49MHhkYiwgbWZuPTB4YTRhMGMN
CihYRU4pIFsyMDEyLTA5LTA2IDIwOjEyOjMxXSBodm0uYzoyNDM1OmQxNSBndWVzdCBhdHRl
bXB0ZWQgd3JpdGUgdG8gcmVhZC1vbmx5IG1lbW9yeSBwYWdlLiBnZm49MHhkZCwgbWZuPTB4
YTRhMGENCihYRU4pIFsyMDEyLTA5LTA2IDIwOjEyOjMxXSBodm0uYzoyNDM1OmQxNSBndWVz
dCBhdHRlbXB0ZWQgd3JpdGUgdG8gcmVhZC1vbmx5IG1lbW9yeSBwYWdlLiBnZm49MHhkZiwg
bWZuPTB4YTRhMDgNCihYRU4pIFsyMDEyLTA5LTA2IDIwOjEyOjMxXSBodm0uYzoyNDM1OmQx
NSBndWVzdCBhdHRlbXB0ZWQgd3JpdGUgdG8gcmVhZC1vbmx5IG1lbW9yeSBwYWdlLiBnZm49
MHhlMSwgbWZuPTB4YTRhMDYNCihYRU4pIFsyMDEyLTA5LTA2IDIwOjEyOjMxXSBodm0uYzoy
NDM1OmQxNSBndWVzdCBhdHRlbXB0ZWQgd3JpdGUgdG8gcmVhZC1vbmx5IG1lbW9yeSBwYWdl
LiBnZm49MHhlMywgbWZuPTB4YTRhMDQNCihYRU4pIFsyMDEyLTA5LTA2IDIwOjEyOjMxXSBo
dm0uYzoyNDM1OmQxNSBndWVzdCBhdHRlbXB0ZWQgd3JpdGUgdG8gcmVhZC1vbmx5IG1lbW9y
eSBwYWdlLiBnZm49MHhlNSwgbWZuPTB4YTRhMDINCihYRU4pIFsyMDEyLTA5LTA2IDIwOjEy
OjMxXSBodm0uYzoyNDM1OmQxNSBndWVzdCBhdHRlbXB0ZWQgd3JpdGUgdG8gcmVhZC1vbmx5
IG1lbW9yeSBwYWdlLiBnZm49MHhlNywgbWZuPTB4YTRhMDANCihYRU4pIFsyMDEyLTA5LTA2
IDIwOjEyOjMxXSBodm0uYzoyNDM1OmQxNSBndWVzdCBhdHRlbXB0ZWQgd3JpdGUgdG8gcmVh
ZC1vbmx5IG1lbW9yeSBwYWdlLiBnZm49MHhlOSwgbWZuPTB4YTQ2M2UNCihYRU4pIFsyMDEy
LTA5LTA2IDIwOjEyOjMxXSBodm0uYzoyNDM1OmQxNSBndWVzdCBhdHRlbXB0ZWQgd3JpdGUg
dG8gcmVhZC1vbmx5IG1lbW9yeSBwYWdlLiBnZm49MHhlYiwgbWZuPTB4YTQ2M2MNCihYRU4p
IFsyMDEyLTA5LTA2IDIwOjEyOjMxXSBodm0uYzoyNDM1OmQxNSBndWVzdCBhdHRlbXB0ZWQg
d3JpdGUgdG8gcmVhZC1vbmx5IG1lbW9yeSBwYWdlLiBnZm49MHhlZCwgbWZuPTB4YTQ2M2EN
CihYRU4pIFsyMDEyLTA5LTA2IDIwOjEyOjMxXSBodm0uYzoyNDM1OmQxNSBndWVzdCBhdHRl
bXB0ZWQgd3JpdGUgdG8gcmVhZC1vbmx5IG1lbW9yeSBwYWdlLiBnZm49MHhlZiwgbWZuPTB4
YTQ2MzgNCihYRU4pIFsyMDEyLTA5LTA2IDIwOjE3OjE5XSB0cmFwcy5jOjMxNTY6IEdQRiAo
MDA2MCk6IGZmZmY4MmM0ODAxNWM5ZmUgLT4gZmZmZjgyYzQ4MDIyNGI4Mw0KKFhFTikgWzIw
MTItMDktMDYgMjA6MTc6MTldIHRyYXBzLmM6MzE1NzogIHNob3dfZXhlY3V0aW9uX3N0YXRl
KHJlZ3MpOiANCihYRU4pIFsyMDEyLTA5LTA2IDIwOjE3OjE5XSAtLS0tWyBYZW4tNC4yLjAt
cmM0LXByZSAgeDg2XzY0ICBkZWJ1Zz15ICBOb3QgdGFpbnRlZCBdLS0tLQ0KKFhFTikgWzIw
MTItMDktMDYgMjA6MTc6MTldIENQVTogICAgNA0KKFhFTikgWzIwMTItMDktMDYgMjA6MTc6
MTldIFJJUDogICAgZTAwODpbPGZmZmY4MmM0ODAxNWM5ZmU+XSBjb250ZXh0X3N3aXRjaCsw
eDM5NC8weGVlYg0KKFhFTikgWzIwMTItMDktMDYgMjA6MTc6MTldIFJGTEFHUzogMDAwMDAw
MDAwMDAxMDI0NiAgIENPTlRFWFQ6IGh5cGVydmlzb3INCihYRU4pIFsyMDEyLTA5LTA2IDIw
OjE3OjE5XSByYXg6IDAwMDAwMDAwMDAwMDAwMDEgICByYng6IGZmZmY4MzAwYTUyZGEwMDAg
ICByY3g6IDAwMDAwMDAwMDAwMDAwMDENCihYRU4pIFsyMDEyLTA5LTA2IDIwOjE3OjE5XSBy
ZHg6IDAwMDAwMDAwMDAwMDAwNjMgICByc2k6IDAwMDAwMDAwMDAwMDAwMDEgICByZGk6IDAw
MDAwMDAwMDAwMDAxMmINCihYRU4pIFsyMDEyLTA5LTA2IDIwOjE3OjE5XSByYnA6IGZmZmY4
MzAyNGQ4OTdlMjggICByc3A6IGZmZmY4MzAyNGQ4OTdkODggICByODogIDAwMDAwMDAwMDAw
MDAwMDYNCihYRU4pIFsyMDEyLTA5LTA2IDIwOjE3OjE5XSByOTogIGZmZmY4MzAwYWZkMTUw
NjAgICByMTA6IDAwMDAwMDAwZGVhZGJlZWYgICByMTE6IDAwMDAwMDAwMDAwMDAyNDYNCihY
RU4pIFsyMDEyLTA5LTA2IDIwOjE3OjE5XSByMTI6IGZmZmY4MzAwYWZkMTUwMDAgICByMTM6
IDAwMDAwMDAwMDAwMDAwMDQgICByMTQ6IDAwMDAwMDAwMDAwMDAwMDQNCihYRU4pIFsyMDEy
LTA5LTA2IDIwOjE3OjE5XSByMTU6IGZmZmY4MzAyNGQ4OWMwNDggICBjcjA6IDAwMDAwMDAw
ODAwNTAwM2IgICBjcjQ6IDAwMDAwMDAwMDAwMDA2ZjANCihYRU4pIFsyMDEyLTA5LTA2IDIw
OjE3OjE5XSBjcjM6IDAwMDAwMDAwNjhhNGEwMDAgICBjcjI6IGZmZmY4ODAwMWZjMGJkNDAN
CihYRU4pIFsyMDEyLTA5LTA2IDIwOjE3OjE5XSBkczogMDAwMCAgIGVzOiAwMDAwICAgZnM6
IDAwMDAgICBnczogMDAwMCAgIHNzOiBlMDEwICAgY3M6IGUwMDgNCihYRU4pIFsyMDEyLTA5
LTA2IDIwOjE3OjE5XSBYZW4gc3RhY2sgdHJhY2UgZnJvbSByc3A9ZmZmZjgzMDI0ZDg5N2Q4
ODoNCihYRU4pIFsyMDEyLTA5LTA2IDIwOjE3OjE5XSAgICBmZmZmODJjNDgwMzAyN2IwIGZm
ZmY4MmY2MDMyMTZiYzAgMDAwMDAwMWU5ZTBmNzAwMCAwMDAwMDAwMDAwMDAwMDAyDQooWEVO
KSBbMjAxMi0wOS0wNiAyMDoxNzoxOV0gICAgZmZmZjgzMDI0ZDg5N2RiOCBmZmZmODMwMjRk
ODljMDYwIGZmZmY4MzAyNGQ4OTdlMTggZmZmZjgyYzQ4MDE4MDViZQ0KKFhFTikgWzIwMTIt
MDktMDYgMjA6MTc6MTldICAgIDAwMDAwMDAwMDAwMDBjYjIgMDAwMDAxOGExNjBkNTliMiAw
MDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDANCihYRU4pIFsyMDEyLTA5LTA2IDIw
OjE3OjE5XSAgICAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgZmZmZjgzMDI0
ZDg5N2UyOCBmZmZmODMwMGFmZDE1MDAwDQooWEVOKSBbMjAxMi0wOS0wNiAyMDoxNzoxOV0g
ICAgZmZmZjgzMDBhNTJkYTAwMCAwMDAwMDA3MmQzZGRjMTNmIDAwMDAwMDAwMDAwMDAwMDIg
ZmZmZjgzMDI0ZDg5YzA0OA0KKFhFTikgWzIwMTItMDktMDYgMjA6MTc6MTldICAgIGZmZmY4
MzAyNGQ4OTdlYjggZmZmZjgyYzQ4MDEyNGE3MCAwMGZmODMwMjRkODk3ZTg4IGZmZmY4MzAy
NGQ4OWMwNDANCihYRU4pIFsyMDEyLTA5LTA2IDIwOjE3OjE5XSAgICAwMDAwMDAwNGRkYWQz
YTc5IDAwMDAwMDcyZDNkZGMxM2YgZmZmZjgzMDI0ZDg5N2U4OCBmZmZmZmZmZmZmZmZmZmMy
DQooWEVOKSBbMjAxMi0wOS0wNiAyMDoxNzoxOV0gICAgZmZmZjgzMDBhNTJkYTAwMCAwMDAw
MDAwMDAxYzljMzgwIGZmZmY4MzAyNGQ4OTdlMDAgZmZmZjgyYzQ4MDEyMjZjZQ0KKFhFTikg
WzIwMTItMDktMDYgMjA6MTc6MTldICAgIGZmZmY4MzAyNGQ4OTdlZjggZmZmZjgyYzQ4MDJk
ODIwMCAwMDAwMDAwMGZmZmZmZmZmIGZmZmY4MmM0ODAyZDgwMDANCihYRU4pIFsyMDEyLTA5
LTA2IDIwOjE3OjE5XSAgICBmZmZmODMwMjRkODk3ZjE4IGZmZmZmZmZmZmZmZmZmZmYgZmZm
ZjgzMDI0ZDg5N2VmOCBmZmZmODJjNDgwMTI1ZTMxDQooWEVOKSBbMjAxMi0wOS0wNiAyMDox
NzoxOV0gICAgZmZmZjgzMDI0ZDg5N2VkOCBmZmZmODMwMGFmZDE1MDAwIGZmZmZmZmZmODFl
Y2U1ZDggZmZmZmZmZmY4MWY0MjBjMA0KKFhFTikgWzIwMTItMDktMDYgMjA6MTc6MTldICAg
IDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCBmZmZmODMwMjRkODk3ZjA4IGZm
ZmY4MmM0ODAxMjVlNjgNCihYRU4pIFsyMDEyLTA5LTA2IDIwOjE3OjE5XSAgICAwMDAwN2Nm
ZGIyNzY4MGM3IGZmZmY4MmM0ODAyMjJmMDYgMDAwMDAwMDAwMDAwMDAwMCBmZmZmODgwMDFl
YWQyNGUwDQooWEVOKSBbMjAxMi0wOS0wNiAyMDoxNzoxOV0gICAgMDAwMDAwMDAwMDAwMDAw
MCBmZmZmODgwMDFkMzQwMGQ4IGZmZmY4ODAwMWNjMmZiZjAgZmZmZjg4MDAxZmMwYjEwMA0K
KFhFTikgWzIwMTItMDktMDYgMjA6MTc6MTldICAgIDAwMDAwMDAwMDAwMDAyMDIgMDAwMDAw
MDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDANCihYRU4pIFsy
MDEyLTA5LTA2IDIwOjE3OjE5XSAgICAwMDAwMDAwMDAwMDAwMDAwIGZmZmZmZmZmODEwMDEx
YWEgZmZmZjg4MDAxZWI4YjBjMCAwMDAwMDAwMGRlYWRiZWVmDQooWEVOKSBbMjAxMi0wOS0w
NiAyMDoxNzoxOV0gICAgMDAwMDAwMDBkZWFkYmVlZiAwMDAwMDBmYTAwMDAwMDAwIGZmZmZm
ZmZmODEwMDExYWEgMDAwMDAwMDAwMDAwZTAzMw0KKFhFTikgWzIwMTItMDktMDYgMjA6MTc6
MTldICAgIDAwMDAwMDAwMDAwMDAyMDIgZmZmZjg4MDAxY2MyZmJiOCAwMDAwMDAwMDAwMDBl
MDJiIDAwMDA0YmZkMDAwMGJlZWYNCihYRU4pIFsyMDEyLTA5LTA2IDIwOjE3OjE5XSAgICA4
MDAwMDAwMDAwMDBiZWVmIDc0MDAwMDAwMDAwMGJlZWYgMDAwMDAwMDAwMDE4YmVlZiAwMDAw
NGJmZTAwMDAwMDA0DQooWEVOKSBbMjAxMi0wOS0wNiAyMDoxNzoxOV0gICAgZmZmZjgzMDBh
NTJkYTAwMCAwMDAwMDAzZGNkNTlhNjgwIDAwMDAwMDAwMDAxOGUwYzkNCihYRU4pIFsyMDEy
LTA5LTA2IDIwOjE3OjE5XSBYZW4gY2FsbCB0cmFjZToNCihYRU4pIFsyMDEyLTA5LTA2IDIw
OjE3OjE5XSAgICBbPGZmZmY4MmM0ODAxNWM5ZmU+XSBjb250ZXh0X3N3aXRjaCsweDM5NC8w
eGVlYg0KKFhFTikgWzIwMTItMDktMDYgMjA6MTc6MTldICAgIFs8ZmZmZjgyYzQ4MDEyNGE3
MD5dIHNjaGVkdWxlKzB4NjY2LzB4Njc1DQooWEVOKSBbMjAxMi0wOS0wNiAyMDoxNzoxOV0g
ICAgWzxmZmZmODJjNDgwMTI1ZTMxPl0gX19kb19zb2Z0aXJxKzB4YTQvMHhiNQ0KKFhFTikg
WzIwMTItMDktMDYgMjA6MTc6MTldICAgIFs8ZmZmZjgyYzQ4MDEyNWU2OD5dIGRvX3NvZnRp
cnErMHgyNi8weDI4DQooWEVOKSBbMjAxMi0wOS0wNiAyMDoxNzoxOV0gICAgDQooWEVOKSBb
MjAxMi0wOS0wNiAyMDoxNzoxOV0gdHJhcHMuYzozMTU5OiAgIHNob3dfZXhlY3V0aW9uX3N0
YXRlKGd1ZXN0X2NwdV91c2VyX3JlZ3MoKSk6IA0KKFhFTikgWzIwMTItMDktMDYgMjA6MTc6
MTldIC0tLS1bIFhlbi00LjIuMC1yYzQtcHJlICB4ODZfNjQgIGRlYnVnPXkgIE5vdCB0YWlu
dGVkIF0tLS0tDQooWEVOKSBbMjAxMi0wOS0wNiAyMDoxNzoxOV0gQ1BVOiAgICA0DQooWEVO
KSBbMjAxMi0wOS0wNiAyMDoxNzoxOV0gUklQOiAgICBlMDMzOls8ZmZmZmZmZmY4MTAwMTFh
YT5dDQooWEVOKSBbMjAxMi0wOS0wNiAyMDoxNzoxOV0gUkZMQUdTOiAwMDAwMDAwMDAwMDAw
MjAyICAgRU06IDEgICBDT05URVhUOiBwdiBndWVzdA0KKFhFTikgWzIwMTItMDktMDYgMjA6
MTc6MTldIHJheDogMDAwMDAwMDAwMDAwMDAwMCAgIHJieDogZmZmZjg4MDAxZmMwYjEwMCAg
IHJjeDogZmZmZmZmZmY4MTAwMTFhYQ0KKFhFTikgWzIwMTItMDktMDYgMjA6MTc6MTldIHJk
eDogZmZmZjg4MDAxZWI4YjBjMCAgIHJzaTogMDAwMDAwMDBkZWFkYmVlZiAgIHJkaTogMDAw
MDAwMDBkZWFkYmVlZg0KKFhFTikgWzIwMTItMDktMDYgMjA6MTc6MTldIHJicDogZmZmZjg4
MDAxY2MyZmJmMCAgIHJzcDogZmZmZjg4MDAxY2MyZmJiOCAgIHI4OiAgMDAwMDAwMDAwMDAw
MDAwMA0KKFhFTikgWzIwMTItMDktMDYgMjA6MTc6MTldIHI5OiAgMDAwMDAwMDAwMDAwMDAw
MCAgIHIxMDogMDAwMDAwMDAwMDAwMDAwMCAgIHIxMTogMDAwMDAwMDAwMDAwMDIwMg0KKFhF
TikgWzIwMTItMDktMDYgMjA6MTc6MTldIHIxMjogZmZmZjg4MDAxZDM0MDBkOCAgIHIxMzog
MDAwMDAwMDAwMDAwMDAwMCAgIHIxNDogZmZmZjg4MDAxZWFkMjRlMA0KKFhFTikgWzIwMTIt
MDktMDYgMjA6MTc6MTldIHIxNTogMDAwMDAwMDAwMDAwMDAwMCAgIGNyMDogMDAwMDAwMDA4
MDA1MDAzYiAgIGNyNDogMDAwMDAwMDAwMDAwMDZmMA0KKFhFTikgWzIwMTItMDktMDYgMjA6
MTc6MTldIGNyMzogMDAwMDAwMDA2OGE0YTAwMCAgIGNyMjogMDAwMDAwMDBmNmIyMDBhYw0K
KFhFTikgWzIwMTItMDktMDYgMjA6MTc6MTldIGRzOiAwMDAwICAgZXM6IDAwMDAgICBmczog
MDAwMCAgIGdzOiAwMDAwICAgc3M6IGUwMmIgICBjczogZTAzMw0KKFhFTikgWzIwMTItMDkt
MDYgMjA6MTc6MTldIEd1ZXN0IHN0YWNrIHRyYWNlIGZyb20gcnNwPWZmZmY4ODAwMWNjMmZi
Yjg6DQooWEVOKSBbMjAxMi0wOS0wNiAyMDoxNzoxOV0gICAgMDAwMDAwMDAwMDAwMDAwMCAw
MDAwMDAwMDAwMDAwMDAxIGZmZmZmZmZmODEwMDQ5NDIgZmZmZjg4MDAxZWFkMjA4MA0KKFhF
TikgWzIwMTItMDktMDYgMjA6MTc6MTldICAgIGZmZmY4ODAwMWViOGIwYzAgMDAwMDAwMDAw
MDAwMDAwMCBmZmZmODgwMDFlYWQyNGUwIGZmZmY4ODAwMWNjMmZjMTANCihYRU4pIFsyMDEy
LTA5LTA2IDIwOjE3OjE5XSAgICBmZmZmZmZmZjgxMDAzOTQxIGZmZmY4ODAwMWViOGIwYzAg
ZmZmZjg4MDAxZWFkMjA4MCBmZmZmODgwMDFjYzJmYzcwDQooWEVOKSBbMjAxMi0wOS0wNiAy
MDoxNzoxOV0gICAgZmZmZmZmZmY4MTAwYjg1MCBmZmZmODgwMDFlYWQyMDgwIGZmZmY4ODAw
MWQzYjAwMDAgMDAwMDAwMDAwMDAwMDA2Mw0KKFhFTikgWzIwMTItMDktMDYgMjA6MTc6MTld
ICAgIGZmZmY4ODAwMWZjMTBhODAgZmZmZjg4MDAxY2MyZmM4MCBmZmZmODgwMDFmYzEyZTgw
IDAwMDAwMDAwMDAwMDAwMDANCihYRU4pIFsyMDEyLTA5LTA2IDIwOjE3OjE5XSAgICBmZmZm
ODgwMDFkM2I2NDAwIGZmZmY4ODAwMWQzNjc4MDAgZmZmZmZmZmZmZmZmMDAwMCBmZmZmODgw
MDFlYWQyMDgwDQooWEVOKSBbMjAxMi0wOS0wNiAyMDoxNzoxOV0gICAgZmZmZmZmZmY4MTdm
YTJmNSBmZmZmODgwMDFjYzJmZGQwIDAwMDAwMDAwMDAwMDAyMTYgZmZmZmZmZmY4MTA3MDBm
ZQ0KKFhFTikgWzIwMTItMDktMDYgMjA6MTc6MTldICAgIGZmZmY4ODAwMWZjMGUwMTggZmZm
Zjg4MDAxZWFkMjA4MCAwMDAwMDAwMDAwMDEyZTgwIGZmZmY4ODAwMWNjMmZmZDgNCihYRU4p
IFsyMDEyLTA5LTA2IDIwOjE3OjE5XSAgICBmZmZmODgwMDFjYzJlMDEwIDAwMDAwMDAwMDAw
MTJlODAgMDAwMDAwMDAwMDAxMmU4MCBmZmZmODgwMDFjYzJmZmQ4DQooWEVOKSBbMjAxMi0w
OS0wNiAyMDoxNzoxOV0gICAgMDAwMDAwMDAwMDAxMmU4MCBmZmZmODgwMDFlYjhiMGMwIGZm
ZmY4ODAwMWVhZDIwODAgZmZmZjg4MDAwMDAwMDAwMA0KKFhFTikgWzIwMTItMDktMDYgMjA6
MTc6MTldICAgIGZmZmY4ODAwMDAwMDAwMDAgZmZmZjg4MDAxZmMwZTAwMCBmZmZmODgwMDFj
Y2VjMGMwIGZmZmY4ODAwMWZjMTZlMDANCihYRU4pIFsyMDEyLTA5LTA2IDIwOjE3OjE5XSAg
ICBmZmZmODgwMDFmYzBlMDAwIGZmZmY4ODAwMWNjMmZkNTAgZmZmZmZmZmY4MTdmYjYxNCBm
ZmZmODgwMDFkMGUwMTQwDQooWEVOKSBbMjAxMi0wOS0wNiAyMDoxNzoxOV0gICAgZmZmZjg4
MDAxY2NlYzBjMCBmZmZmODgwMDFmYzE2ZTAwIGZmZmY4ODAwMWZjMGUwMDAgZmZmZjg4MDAx
Y2MyZmRlMA0KKFhFTikgWzIwMTItMDktMDYgMjA6MTc6MTldICAgIGZmZmZmZmZmODEwN2Yw
NTkgZmZmZjg4MDAxZWFkMjA4MCBmZmZmODgwMDFlYWQyMDgwIGZmZmZmZmZmODE3ZmJlN2IN
CihYRU4pIFsyMDEyLTA5LTA2IDIwOjE3OjE5XSAgICBmZmZmODgwMDFmYzBlNDQ4IGZmZmY4
ODAwMWVhZDIwODAgZmZmZjg4MDAxY2NlYzBlMCBmZmZmODgwMDFjYzJmZGIwDQooWEVOKSBb
MjAxMi0wOS0wNiAyMDoxNzoxOV0gICAgZmZmZmZmZmY4MTBhY2I3OCBmZmZmODgwMDFmYzBl
MDAwIGZmZmY4ODAwMWNjZWMwYzAgZmZmZjg4MDAxZmMwZTQzOA0KKFhFTikgWzIwMTItMDkt
MDYgMjA6MTc6MTldICAgIGZmZmY4ODAwMWZjMGU0NDggZmZmZjg4MDAxZWFkMjA4MCBmZmZm
ODgwMDFjY2VjMGUwIGZmZmY4ODAwMWNjMmZkZTANCihYRU4pIFsyMDEyLTA5LTA2IDIwOjE3
OjE5XSAgICBmZmZmZmZmZjgxN2ZhODE0IGZmZmY4ODAwMWNjMmZlYjAgZmZmZmZmZmY4MTA3
ZjZmOSAwMDAwMDAwMDAwMDAwMDAwDQooWEVOKSBbMjAxMi0wOS0wNiAyMDoxNzoxOV0gICAg
ZmZmZjg4MDAxY2MyZmU1MCBmZmZmODgwMDFlYWQyMDgwIGZmZmY4ODAwMWNjMmUwMTAgZmZm
Zjg4MDAxZWFkMDI4MA0KKFhFTikgWzIwMTItMDktMDYgMjA6MTc6MTldICAgIGZmZmY4ODAw
MWNjMmZlNjggZmZmZjg4MDAxZWFkMjA4MCBmZmZmODgwMDFlYWQyMDgwIGZmZmY4ODAwMWVh
ZDIwODANCg==
------------0E902503E1C6BF83E
Content-Type: text/plain;
 name="xm-dmesg-4.1.txt"
Content-transfer-encoding: base64
Content-Disposition: attachment;
 filename="xm-dmesg-4.1.txt"

DQooWEVOKSBBQ1BJOiBMb2NhbCBBUElDIGFkZHJlc3MgMHhmZWUwMDAwMA0KKFhFTikgQUNQ
STogTEFQSUMgKGFjcGlfaWRbMHgwMV0gbGFwaWNfaWRbMHgwMF0gZW5hYmxlZCkNCihYRU4p
IFByb2Nlc3NvciAjMCAwOjEwIEFQSUMgdmVyc2lvbiAxNg0KKFhFTikgQUNQSTogTEFQSUMg
KGFjcGlfaWRbMHgwMl0gbGFwaWNfaWRbMHgwMV0gZW5hYmxlZCkNCihYRU4pIFByb2Nlc3Nv
ciAjMSAwOjEwIEFQSUMgdmVyc2lvbiAxNg0KKFhFTikgQUNQSTogTEFQSUMgKGFjcGlfaWRb
MHgwM10gbGFwaWNfaWRbMHgwMl0gZW5hYmxlZCkNCihYRU4pIFByb2Nlc3NvciAjMiAwOjEw
IEFQSUMgdmVyc2lvbiAxNg0KKFhFTikgQUNQSTogTEFQSUMgKGFjcGlfaWRbMHgwNF0gbGFw
aWNfaWRbMHgwM10gZW5hYmxlZCkNCihYRU4pIFByb2Nlc3NvciAjMyAwOjEwIEFQSUMgdmVy
c2lvbiAxNg0KKFhFTikgQUNQSTogTEFQSUMgKGFjcGlfaWRbMHgwNV0gbGFwaWNfaWRbMHgw
NF0gZW5hYmxlZCkNCihYRU4pIFByb2Nlc3NvciAjNCAwOjEwIEFQSUMgdmVyc2lvbiAxNg0K
KFhFTikgQUNQSTogTEFQSUMgKGFjcGlfaWRbMHgwNl0gbGFwaWNfaWRbMHgwNV0gZW5hYmxl
ZCkNCihYRU4pIFByb2Nlc3NvciAjNSAwOjEwIEFQSUMgdmVyc2lvbiAxNg0KKFhFTikgQUNQ
STogSU9BUElDIChpZFsweDA2XSBhZGRyZXNzWzB4ZmVjMDAwMDBdIGdzaV9iYXNlWzBdKQ0K
KFhFTikgSU9BUElDWzBdOiBhcGljX2lkIDYsIHZlcnNpb24gMzMsIGFkZHJlc3MgMHhmZWMw
MDAwMCwgR1NJIDAtMjMNCihYRU4pIEFDUEk6IElPQVBJQyAoaWRbMHgwN10gYWRkcmVzc1sw
eGZlYzIwMDAwXSBnc2lfYmFzZVsyNF0pDQooWEVOKSBJT0FQSUNbMV06IGFwaWNfaWQgNywg
dmVyc2lvbiAzMywgYWRkcmVzcyAweGZlYzIwMDAwLCBHU0kgMjQtNTUNCihYRU4pIEFDUEk6
IElOVF9TUkNfT1ZSIChidXMgMCBidXNfaXJxIDAgZ2xvYmFsX2lycSAyIGRmbCBkZmwpDQoo
WEVOKSBBQ1BJOiBJTlRfU1JDX09WUiAoYnVzIDAgYnVzX2lycSA5IGdsb2JhbF9pcnEgOSBs
b3cgbGV2ZWwpDQooWEVOKSBBQ1BJOiBJUlEwIHVzZWQgYnkgb3ZlcnJpZGUuDQooWEVOKSBB
Q1BJOiBJUlEyIHVzZWQgYnkgb3ZlcnJpZGUuDQooWEVOKSBBQ1BJOiBJUlE5IHVzZWQgYnkg
b3ZlcnJpZGUuDQooWEVOKSBFbmFibGluZyBBUElDIG1vZGU6ICBGbGF0LiAgVXNpbmcgMiBJ
L08gQVBJQ3MNCihYRU4pIEFDUEk6IEhQRVQgaWQ6IDB4ODMwMCBiYXNlOiAweGZlZDAwMDAw
DQooWEVOKSBQQ0k6IE1DRkcgY29uZmlndXJhdGlvbiAwOiBiYXNlIGUwMDAwMDAwIHNlZ21l
bnQgMCBidXNlcyAwIC0gMjU1DQooWEVOKSBQQ0k6IE5vdCB1c2luZyBNTUNPTkZJRy4NCihY
RU4pIFRhYmxlIGlzIG5vdCBmb3VuZCENCihYRU4pIFVzaW5nIEFDUEkgKE1BRFQpIGZvciBT
TVAgY29uZmlndXJhdGlvbiBpbmZvcm1hdGlvbg0KKFhFTikgbWFwcGVkIEFQSUMgdG8gZmZm
ZjgyYzNmZmZmZTAwMCAoZmVlMDAwMDApDQooWEVOKSBtYXBwZWQgSU9BUElDIHRvIGZmZmY4
MmMzZmZmZmQwMDAgKGZlYzAwMDAwKQ0KKFhFTikgbWFwcGVkIElPQVBJQyB0byBmZmZmODJj
M2ZmZmZjMDAwIChmZWMyMDAwMCkNCihYRU4pIElSUSBsaW1pdHM6IDU2IEdTSSwgMTExMiBN
U0kvTVNJLVgNCihYRU4pIFVzaW5nIHNjaGVkdWxlcjogU01QIENyZWRpdCBTY2hlZHVsZXIg
KGNyZWRpdCkNCihYRU4pIERldGVjdGVkIDMyMDAuMTc2IE1IeiBwcm9jZXNzb3IuDQooWEVO
KSBJbml0aW5nIG1lbW9yeSBzaGFyaW5nLg0KKFhFTikgQU1EIEZhbTEwaCBtYWNoaW5lIGNo
ZWNrIHJlcG9ydGluZyBlbmFibGVkDQooWEVOKSBBTUQtVmk6IEZvdW5kIE1TSSBjYXBhYmls
aXR5IGJsb2NrIA0KKFhFTikgQU1ELVZpOiBBQ1BJIFRhYmxlOg0KKFhFTikgQU1ELVZpOiAg
U2lnbmF0dXJlIElWUlMNCihYRU4pIEFNRC1WaTogIExlbmd0aCAweGY4DQooWEVOKSBBTUQt
Vmk6ICBSZXZpc2lvbiAweDENCihYRU4pIEFNRC1WaTogIENoZWNrU3VtIDB4NmUNCihYRU4p
IEFNRC1WaTogIE9FTV9JZCBBTUQgIA0KKFhFTikgQU1ELVZpOiAgT0VNX1RhYmxlX0lkIFJE
ODkwUw0KKFhFTikgQU1ELVZpOiAgT0VNX1JldmlzaW9uIDB4MjAyMDMxDQooWEVOKSBBTUQt
Vmk6ICBDcmVhdG9yX0lkIEFNRCANCihYRU4pIEFNRC1WaTogIENyZWF0b3JfUmV2aXNpb24g
MHgwDQooWEVOKSBBTUQtVmk6IElWUlMgQmxvY2s6DQooWEVOKSBBTUQtVmk6ICBUeXBlIDB4
MTANCihYRU4pIEFNRC1WaTogIEZsYWdzIDB4M2UNCihYRU4pIEFNRC1WaTogIExlbmd0aCAw
eGM4DQooWEVOKSBBTUQtVmk6ICBEZXZfSWQgMHgyDQooWEVOKSBBTUQtVmk6IElWSEQgRGV2
aWNlIEVudHJ5Og0KKFhFTikgQU1ELVZpOiAgVHlwZSAweDMNCihYRU4pIEFNRC1WaTogIERl
dl9JZCAweDANCihYRU4pIEFNRC1WaTogIEZsYWdzIDB4MA0KKFhFTikgQU1ELVZpOiAgRGV2
X0lkIFJhbmdlOiAweDAgLT4gMHgyDQooWEVOKSBBTUQtVmk6IElWSEQgRGV2aWNlIEVudHJ5
Og0KKFhFTikgQU1ELVZpOiAgVHlwZSAweDINCihYRU4pIEFNRC1WaTogIERldl9JZCAweDEw
DQooWEVOKSBBTUQtVmk6ICBGbGFncyAweDANCihYRU4pIEFNRC1WaTogSVZIRCBEZXZpY2Ug
RW50cnk6DQooWEVOKSBBTUQtVmk6ICBUeXBlIDB4Mg0KKFhFTikgQU1ELVZpOiAgRGV2X0lk
IDB4YjAwDQooWEVOKSBBTUQtVmk6ICBGbGFncyAweDANCihYRU4pIEFNRC1WaTogSVZIRCBE
ZXZpY2UgRW50cnk6DQooWEVOKSBBTUQtVmk6ICBUeXBlIDB4Mg0KKFhFTikgQU1ELVZpOiAg
RGV2X0lkIDB4MTgNCihYRU4pIEFNRC1WaTogIEZsYWdzIDB4MA0KKFhFTikgQU1ELVZpOiBJ
VkhEIERldmljZSBFbnRyeToNCihYRU4pIEFNRC1WaTogIFR5cGUgMHgzDQooWEVOKSBBTUQt
Vmk6ICBEZXZfSWQgMHhhMDANCihYRU4pIEFNRC1WaTogIEZsYWdzIDB4MA0KKFhFTikgQU1E
LVZpOiAgRGV2X0lkIFJhbmdlOiAweGEwMCAtPiAweGEwNw0KKFhFTikgQU1ELVZpOiBJVkhE
IERldmljZSBFbnRyeToNCihYRU4pIEFNRC1WaTogIFR5cGUgMHgyDQooWEVOKSBBTUQtVmk6
ICBEZXZfSWQgMHgyOA0KKFhFTikgQU1ELVZpOiAgRmxhZ3MgMHgwDQooWEVOKSBBTUQtVmk6
IElWSEQgRGV2aWNlIEVudHJ5Og0KKFhFTikgQU1ELVZpOiAgVHlwZSAweDINCihYRU4pIEFN
RC1WaTogIERldl9JZCAweDkwMA0KKFhFTikgQU1ELVZpOiAgRmxhZ3MgMHgwDQooWEVOKSBB
TUQtVmk6IElWSEQgRGV2aWNlIEVudHJ5Og0KKFhFTikgQU1ELVZpOiAgVHlwZSAweDINCihY
RU4pIEFNRC1WaTogIERldl9JZCAweDMwDQooWEVOKSBBTUQtVmk6ICBGbGFncyAweDANCihY
RU4pIEFNRC1WaTogSVZIRCBEZXZpY2UgRW50cnk6DQooWEVOKSBBTUQtVmk6ICBUeXBlIDB4
Mg0KKFhFTikgQU1ELVZpOiAgRGV2X0lkIDB4ODAwDQooWEVOKSBBTUQtVmk6ICBGbGFncyAw
eDANCihYRU4pIEFNRC1WaTogSVZIRCBEZXZpY2UgRW50cnk6DQooWEVOKSBBTUQtVmk6ICBU
eXBlIDB4Mg0KKFhFTikgQU1ELVZpOiAgRGV2X0lkIDB4NTANCihYRU4pIEFNRC1WaTogIEZs
YWdzIDB4MA0KKFhFTikgQU1ELVZpOiBJVkhEIERldmljZSBFbnRyeToNCihYRU4pIEFNRC1W
aTogIFR5cGUgMHgyDQooWEVOKSBBTUQtVmk6ICBEZXZfSWQgMHg3MDANCihYRU4pIEFNRC1W
aTogIEZsYWdzIDB4MA0KKFhFTikgQU1ELVZpOiBJVkhEIERldmljZSBFbnRyeToNCihYRU4p
IEFNRC1WaTogIFR5cGUgMHgyDQooWEVOKSBBTUQtVmk6ICBEZXZfSWQgMHg1OA0KKFhFTikg
QU1ELVZpOiAgRmxhZ3MgMHgwDQooWEVOKSBBTUQtVmk6IElWSEQgRGV2aWNlIEVudHJ5Og0K
KFhFTikgQU1ELVZpOiAgVHlwZSAweDMNCihYRU4pIEFNRC1WaTogIERldl9JZCAweDYwMA0K
KFhFTikgQU1ELVZpOiAgRmxhZ3MgMHgwDQooWEVOKSBBTUQtVmk6ICBEZXZfSWQgUmFuZ2U6
IDB4NjAwIC0+IDB4NjAxDQooWEVOKSBBTUQtVmk6IElWSEQgRGV2aWNlIEVudHJ5Og0KKFhF
TikgQU1ELVZpOiAgVHlwZSAweDINCihYRU4pIEFNRC1WaTogIERldl9JZCAweDYwDQooWEVO
KSBBTUQtVmk6ICBGbGFncyAweDANCihYRU4pIEFNRC1WaTogSVZIRCBEZXZpY2UgRW50cnk6
DQooWEVOKSBBTUQtVmk6ICBUeXBlIDB4Mg0KKFhFTikgQU1ELVZpOiAgRGV2X0lkIDB4NTAw
DQooWEVOKSBBTUQtVmk6ICBGbGFncyAweDANCihYRU4pIEFNRC1WaTogSVZIRCBEZXZpY2Ug
RW50cnk6DQooWEVOKSBBTUQtVmk6ICBUeXBlIDB4Mg0KKFhFTikgQU1ELVZpOiAgRGV2X0lk
IDB4NjgNCihYRU4pIEFNRC1WaTogIEZsYWdzIDB4MA0KKFhFTikgQU1ELVZpOiBJVkhEIERl
dmljZSBFbnRyeToNCihYRU4pIEFNRC1WaTogIFR5cGUgMHgzDQooWEVOKSBBTUQtVmk6ICBE
ZXZfSWQgMHg0MDANCihYRU4pIEFNRC1WaTogIEZsYWdzIDB4MA0KKFhFTikgQU1ELVZpOiAg
RGV2X0lkIFJhbmdlOiAweDQwMCAtPiAweDQwNw0KKFhFTikgQU1ELVZpOiBJVkhEIERldmlj
ZSBFbnRyeToNCihYRU4pIEFNRC1WaTogIFR5cGUgMHgyDQooWEVOKSBBTUQtVmk6ICBEZXZf
SWQgMHg4OA0KKFhFTikgQU1ELVZpOiAgRmxhZ3MgMHgwDQooWEVOKSBBTUQtVmk6IElWSEQg
RGV2aWNlIEVudHJ5Og0KKFhFTikgQU1ELVZpOiAgVHlwZSAweDMNCihYRU4pIEFNRC1WaTog
IERldl9JZCAweDkwDQooWEVOKSBBTUQtVmk6ICBGbGFncyAweDANCihYRU4pIEFNRC1WaTog
IERldl9JZCBSYW5nZTogMHg5MCAtPiAweDkyDQooWEVOKSBBTUQtVmk6IElWSEQgRGV2aWNl
IEVudHJ5Og0KKFhFTikgQU1ELVZpOiAgVHlwZSAweDMNCihYRU4pIEFNRC1WaTogIERldl9J
ZCAweDk4DQooWEVOKSBBTUQtVmk6ICBGbGFncyAweDANCihYRU4pIEFNRC1WaTogIERldl9J
ZCBSYW5nZTogMHg5OCAtPiAweDlhDQooWEVOKSBBTUQtVmk6IElWSEQgRGV2aWNlIEVudHJ5
Og0KKFhFTikgQU1ELVZpOiAgVHlwZSAweDINCihYRU4pIEFNRC1WaTogIERldl9JZCAweGEw
DQooWEVOKSBBTUQtVmk6ICBGbGFncyAweGQ3DQooWEVOKSBBTUQtVmk6IElWSEQgRGV2aWNl
IEVudHJ5Og0KKFhFTikgQU1ELVZpOiAgVHlwZSAweDINCihYRU4pIEFNRC1WaTogIERldl9J
ZCAweGEzDQooWEVOKSBBTUQtVmk6ICBGbGFncyAweDANCihYRU4pIEFNRC1WaTogSVZIRCBE
ZXZpY2UgRW50cnk6DQooWEVOKSBBTUQtVmk6ICBUeXBlIDB4Mg0KKFhFTikgQU1ELVZpOiAg
RGV2X0lkIDB4YTQNCihYRU4pIEFNRC1WaTogIEZsYWdzIDB4MA0KKFhFTikgQU1ELVZpOiBJ
VkhEIERldmljZSBFbnRyeToNCihYRU4pIEFNRC1WaTogIFR5cGUgMHgwDQooWEVOKSBBTUQt
Vmk6ICBEZXZfSWQgMHgwDQooWEVOKSBBTUQtVmk6ICBGbGFncyAweDANCihYRU4pIEFNRC1W
aTogSVZIRCBEZXZpY2UgRW50cnk6DQooWEVOKSBBTUQtVmk6ICBUeXBlIDB4NDMNCihYRU4p
IEFNRC1WaTogIERldl9JZCAweDMwMA0KKFhFTikgQU1ELVZpOiAgRmxhZ3MgMHgwDQooWEVO
KSBBTUQtVmk6ICBEZXZfSWQgUmFuZ2U6IDB4MzAwIC0+IDB4M2ZmDQooWEVOKSBBTUQtVmk6
ICBEZXZfSWQgQWxpYXM6IDB4YTQNCihYRU4pIEFNRC1WaTogSVZIRCBEZXZpY2UgRW50cnk6
DQooWEVOKSBBTUQtVmk6ICBUeXBlIDB4Mg0KKFhFTikgQU1ELVZpOiAgRGV2X0lkIDB4YTUN
CihYRU4pIEFNRC1WaTogIEZsYWdzIDB4MA0KKFhFTikgQU1ELVZpOiBJVkhEIERldmljZSBF
bnRyeToNCihYRU4pIEFNRC1WaTogIFR5cGUgMHgyDQooWEVOKSBBTUQtVmk6ICBEZXZfSWQg
MHhhOA0KKFhFTikgQU1ELVZpOiAgRmxhZ3MgMHgwDQooWEVOKSBBTUQtVmk6IElWSEQgRGV2
aWNlIEVudHJ5Og0KKFhFTikgQU1ELVZpOiAgVHlwZSAweDINCihYRU4pIEFNRC1WaTogIERl
dl9JZCAweGE5DQooWEVOKSBBTUQtVmk6ICBGbGFncyAweDANCihYRU4pIEFNRC1WaTogSVZI
RCBEZXZpY2UgRW50cnk6DQooWEVOKSBBTUQtVmk6ICBUeXBlIDB4Mg0KKFhFTikgQU1ELVZp
OiAgRGV2X0lkIDB4MTAwDQooWEVOKSBBTUQtVmk6ICBGbGFncyAweDANCihYRU4pIEFNRC1W
aTogSVZIRCBEZXZpY2UgRW50cnk6DQooWEVOKSBBTUQtVmk6ICBUeXBlIDB4Mw0KKFhFTikg
QU1ELVZpOiAgRGV2X0lkIDB4YjANCihYRU4pIEFNRC1WaTogIEZsYWdzIDB4MA0KKFhFTikg
QU1ELVZpOiAgRGV2X0lkIFJhbmdlOiAweGIwIC0+IDB4YjINCihYRU4pIEFNRC1WaTogSVZI
RCBEZXZpY2UgRW50cnk6DQooWEVOKSBBTUQtVmk6ICBUeXBlIDB4MA0KKFhFTikgQU1ELVZp
OiAgRGV2X0lkIDB4MA0KKFhFTikgQU1ELVZpOiAgRmxhZ3MgMHgwDQooWEVOKSBBTUQtVmk6
IElWSEQgRGV2aWNlIEVudHJ5Og0KKFhFTikgQU1ELVZpOiAgVHlwZSAweDQ4DQooWEVOKSBB
TUQtVmk6ICBEZXZfSWQgMHgwDQooWEVOKSBBTUQtVmk6ICBGbGFncyAweGQ3DQooWEVOKSBB
TUQtVmk6IElWSEQgRGV2aWNlIEVudHJ5Og0KKFhFTikgQU1ELVZpOiAgVHlwZSAweDQ4DQoo
WEVOKSBBTUQtVmk6ICBEZXZfSWQgMHgwDQooWEVOKSBBTUQtVmk6ICBGbGFncyAweDANCihY
RU4pIEFNRC1WaTogQWRkIGRldmljZSB0YWJsZSBlbnRyeTogZGV2aWNlIGlkID0gMHgwMDAw
LCBpbnRlcnVwdCB0YWJsZSA9IDB4MjRkOTgwMDAwDQooWEVOKSBBTUQtVmk6IEFkZCBkZXZp
Y2UgdGFibGUgZW50cnk6IGRldmljZSBpZCA9IDB4MDAwMSwgaW50ZXJ1cHQgdGFibGUgPSAw
eDI0ZDk4MDAwMA0KKFhFTikgQU1ELVZpOiBBZGQgZGV2aWNlIHRhYmxlIGVudHJ5OiBkZXZp
Y2UgaWQgPSAweDAwMDIsIGludGVydXB0IHRhYmxlID0gMHgyNGQ5ODAwMDANCihYRU4pIEFN
RC1WaTogQWRkIGRldmljZSB0YWJsZSBlbnRyeTogZGV2aWNlIGlkID0gMHgwMDEwLCBpbnRl
cnVwdCB0YWJsZSA9IDB4MjRkOTgwMDAwDQooWEVOKSBBTUQtVmk6IEFkZCBkZXZpY2UgdGFi
bGUgZW50cnk6IGRldmljZSBpZCA9IDB4MDAxOCwgaW50ZXJ1cHQgdGFibGUgPSAweDI0ZDk4
MDAwMA0KKFhFTikgQU1ELVZpOiBBZGQgZGV2aWNlIHRhYmxlIGVudHJ5OiBkZXZpY2UgaWQg
PSAweDAwMjgsIGludGVydXB0IHRhYmxlID0gMHgyNGQ5ODAwMDANCihYRU4pIEFNRC1WaTog
QWRkIGRldmljZSB0YWJsZSBlbnRyeTogZGV2aWNlIGlkID0gMHgwMDMwLCBpbnRlcnVwdCB0
YWJsZSA9IDB4MjRkOTgwMDAwDQooWEVOKSBBTUQtVmk6IEFkZCBkZXZpY2UgdGFibGUgZW50
cnk6IGRldmljZSBpZCA9IDB4MDA1MCwgaW50ZXJ1cHQgdGFibGUgPSAweDI0ZDk4MDAwMA0K
KFhFTikgQU1ELVZpOiBBZGQgZGV2aWNlIHRhYmxlIGVudHJ5OiBkZXZpY2UgaWQgPSAweDAw
NTgsIGludGVydXB0IHRhYmxlID0gMHgyNGQ5ODAwMDANCihYRU4pIEFNRC1WaTogQWRkIGRl
dmljZSB0YWJsZSBlbnRyeTogZGV2aWNlIGlkID0gMHgwMDYwLCBpbnRlcnVwdCB0YWJsZSA9
IDB4MjRkOTgwMDAwDQooWEVOKSBBTUQtVmk6IEFkZCBkZXZpY2UgdGFibGUgZW50cnk6IGRl
dmljZSBpZCA9IDB4MDA2OCwgaW50ZXJ1cHQgdGFibGUgPSAweDI0ZDk4MDAwMA0KKFhFTikg
QU1ELVZpOiBBZGQgZGV2aWNlIHRhYmxlIGVudHJ5OiBkZXZpY2UgaWQgPSAweDAwODgsIGlu
dGVydXB0IHRhYmxlID0gMHgyNGQ5ODAwMDANCihYRU4pIEFNRC1WaTogQWRkIGRldmljZSB0
YWJsZSBlbnRyeTogZGV2aWNlIGlkID0gMHgwMDkwLCBpbnRlcnVwdCB0YWJsZSA9IDB4MjRk
OTgwMDAwDQooWEVOKSBBTUQtVmk6IEFkZCBkZXZpY2UgdGFibGUgZW50cnk6IGRldmljZSBp
ZCA9IDB4MDA5MSwgaW50ZXJ1cHQgdGFibGUgPSAweDI0ZDk4MDAwMA0KKFhFTikgQU1ELVZp
OiBBZGQgZGV2aWNlIHRhYmxlIGVudHJ5OiBkZXZpY2UgaWQgPSAweDAwOTIsIGludGVydXB0
IHRhYmxlID0gMHgyNGQ5ODAwMDANCihYRU4pIEFNRC1WaTogQWRkIGRldmljZSB0YWJsZSBl
bnRyeTogZGV2aWNlIGlkID0gMHgwMDk4LCBpbnRlcnVwdCB0YWJsZSA9IDB4MjRkOTgwMDAw
DQooWEVOKSBBTUQtVmk6IEFkZCBkZXZpY2UgdGFibGUgZW50cnk6IGRldmljZSBpZCA9IDB4
MDA5OSwgaW50ZXJ1cHQgdGFibGUgPSAweDI0ZDk4MDAwMA0KKFhFTikgQU1ELVZpOiBBZGQg
ZGV2aWNlIHRhYmxlIGVudHJ5OiBkZXZpY2UgaWQgPSAweDAwOWEsIGludGVydXB0IHRhYmxl
ID0gMHgyNGQ5ODAwMDANCihYRU4pIEFNRC1WaTogQWRkIGRldmljZSB0YWJsZSBlbnRyeTog
ZGV2aWNlIGlkID0gMHgwMGEwLCBpbnRlcnVwdCB0YWJsZSA9IDB4MjRkOTgwMDAwDQooWEVO
KSBBTUQtVmk6IEFkZCBkZXZpY2UgdGFibGUgZW50cnk6IGRldmljZSBpZCA9IDB4MDBhMywg
aW50ZXJ1cHQgdGFibGUgPSAweDI0ZDk4MDAwMA0KKFhFTikgQU1ELVZpOiBBZGQgZGV2aWNl
IHRhYmxlIGVudHJ5OiBkZXZpY2UgaWQgPSAweDAwYTQsIGludGVydXB0IHRhYmxlID0gMHgy
NGQ5ODAwMDANCihYRU4pIEFNRC1WaTogQWRkIGRldmljZSB0YWJsZSBlbnRyeTogZGV2aWNl
IGlkID0gMHgwMGE1LCBpbnRlcnVwdCB0YWJsZSA9IDB4MjRkOTgwMDAwDQooWEVOKSBBTUQt
Vmk6IEFkZCBkZXZpY2UgdGFibGUgZW50cnk6IGRldmljZSBpZCA9IDB4MDBhOCwgaW50ZXJ1
cHQgdGFibGUgPSAweDI0ZDk4MDAwMA0KKFhFTikgQU1ELVZpOiBBZGQgZGV2aWNlIHRhYmxl
IGVudHJ5OiBkZXZpY2UgaWQgPSAweDAwYTksIGludGVydXB0IHRhYmxlID0gMHgyNGQ5ODAw
MDANCihYRU4pIEFNRC1WaTogQWRkIGRldmljZSB0YWJsZSBlbnRyeTogZGV2aWNlIGlkID0g
MHgwMGIwLCBpbnRlcnVwdCB0YWJsZSA9IDB4MjRkOTgwMDAwDQooWEVOKSBBTUQtVmk6IEFk
ZCBkZXZpY2UgdGFibGUgZW50cnk6IGRldmljZSBpZCA9IDB4MDBiMSwgaW50ZXJ1cHQgdGFi
bGUgPSAweDI0ZDk4MDAwMA0KKFhFTikgQU1ELVZpOiBBZGQgZGV2aWNlIHRhYmxlIGVudHJ5
OiBkZXZpY2UgaWQgPSAweDAwYjIsIGludGVydXB0IHRhYmxlID0gMHgyNGQ5ODAwMDANCihY
RU4pIEFNRC1WaTogQWRkIGRldmljZSB0YWJsZSBlbnRyeTogZGV2aWNlIGlkID0gMHgwMTAw
LCBpbnRlcnVwdCB0YWJsZSA9IDB4MjRkOTgwMDAwDQooWEVOKSBBTUQtVmk6IEFkZCBkZXZp
Y2UgdGFibGUgZW50cnk6IGRldmljZSBpZCA9IDB4MDQwMCwgaW50ZXJ1cHQgdGFibGUgPSAw
eDI0ZDk4MDAwMA0KKFhFTikgQU1ELVZpOiBBZGQgZGV2aWNlIHRhYmxlIGVudHJ5OiBkZXZp
Y2UgaWQgPSAweDA0MDEsIGludGVydXB0IHRhYmxlID0gMHgyNGQ5ODAwMDANCihYRU4pIEFN
RC1WaTogQWRkIGRldmljZSB0YWJsZSBlbnRyeTogZGV2aWNlIGlkID0gMHgwNDAyLCBpbnRl
cnVwdCB0YWJsZSA9IDB4MjRkOTgwMDAwDQooWEVOKSBBTUQtVmk6IEFkZCBkZXZpY2UgdGFi
bGUgZW50cnk6IGRldmljZSBpZCA9IDB4MDQwMywgaW50ZXJ1cHQgdGFibGUgPSAweDI0ZDk4
MDAwMA0KKFhFTikgQU1ELVZpOiBBZGQgZGV2aWNlIHRhYmxlIGVudHJ5OiBkZXZpY2UgaWQg
PSAweDA0MDQsIGludGVydXB0IHRhYmxlID0gMHgyNGQ5ODAwMDANCihYRU4pIEFNRC1WaTog
QWRkIGRldmljZSB0YWJsZSBlbnRyeTogZGV2aWNlIGlkID0gMHgwNDA1LCBpbnRlcnVwdCB0
YWJsZSA9IDB4MjRkOTgwMDAwDQooWEVOKSBBTUQtVmk6IEFkZCBkZXZpY2UgdGFibGUgZW50
cnk6IGRldmljZSBpZCA9IDB4MDQwNiwgaW50ZXJ1cHQgdGFibGUgPSAweDI0ZDk4MDAwMA0K
KFhFTikgQU1ELVZpOiBBZGQgZGV2aWNlIHRhYmxlIGVudHJ5OiBkZXZpY2UgaWQgPSAweDA0
MDcsIGludGVydXB0IHRhYmxlID0gMHgyNGQ5ODAwMDANCihYRU4pIEFNRC1WaTogQWRkIGRl
dmljZSB0YWJsZSBlbnRyeTogZGV2aWNlIGlkID0gMHgwNTAwLCBpbnRlcnVwdCB0YWJsZSA9
IDB4MjRkOTgwMDAwDQooWEVOKSBBTUQtVmk6IEFkZCBkZXZpY2UgdGFibGUgZW50cnk6IGRl
dmljZSBpZCA9IDB4MDYwMCwgaW50ZXJ1cHQgdGFibGUgPSAweDI0ZDk4MDAwMA0KKFhFTikg
QU1ELVZpOiBBZGQgZGV2aWNlIHRhYmxlIGVudHJ5OiBkZXZpY2UgaWQgPSAweDA2MDEsIGlu
dGVydXB0IHRhYmxlID0gMHgyNGQ5ODAwMDANCihYRU4pIEFNRC1WaTogQWRkIGRldmljZSB0
YWJsZSBlbnRyeTogZGV2aWNlIGlkID0gMHgwNzAwLCBpbnRlcnVwdCB0YWJsZSA9IDB4MjRk
OTgwMDAwDQooWEVOKSBBTUQtVmk6IEFkZCBkZXZpY2UgdGFibGUgZW50cnk6IGRldmljZSBp
ZCA9IDB4MDgwMCwgaW50ZXJ1cHQgdGFibGUgPSAweDI0ZDk4MDAwMA0KKFhFTikgQU1ELVZp
OiBBZGQgZGV2aWNlIHRhYmxlIGVudHJ5OiBkZXZpY2UgaWQgPSAweDA5MDAsIGludGVydXB0
IHRhYmxlID0gMHgyNGQ5ODAwMDANCihYRU4pIEFNRC1WaTogQWRkIGRldmljZSB0YWJsZSBl
bnRyeTogZGV2aWNlIGlkID0gMHgwYTAwLCBpbnRlcnVwdCB0YWJsZSA9IDB4MjRkOTgwMDAw
DQooWEVOKSBBTUQtVmk6IEFkZCBkZXZpY2UgdGFibGUgZW50cnk6IGRldmljZSBpZCA9IDB4
MGEwMSwgaW50ZXJ1cHQgdGFibGUgPSAweDI0ZDk4MDAwMA0KKFhFTikgQU1ELVZpOiBBZGQg
ZGV2aWNlIHRhYmxlIGVudHJ5OiBkZXZpY2UgaWQgPSAweDBhMDIsIGludGVydXB0IHRhYmxl
ID0gMHgyNGQ5ODAwMDANCihYRU4pIEFNRC1WaTogQWRkIGRldmljZSB0YWJsZSBlbnRyeTog
ZGV2aWNlIGlkID0gMHgwYTAzLCBpbnRlcnVwdCB0YWJsZSA9IDB4MjRkOTgwMDAwDQooWEVO
KSBBTUQtVmk6IEFkZCBkZXZpY2UgdGFibGUgZW50cnk6IGRldmljZSBpZCA9IDB4MGEwNCwg
aW50ZXJ1cHQgdGFibGUgPSAweDI0ZDk4MDAwMA0KKFhFTikgQU1ELVZpOiBBZGQgZGV2aWNl
IHRhYmxlIGVudHJ5OiBkZXZpY2UgaWQgPSAweDBhMDUsIGludGVydXB0IHRhYmxlID0gMHgy
NGQ5ODAwMDANCihYRU4pIEFNRC1WaTogQWRkIGRldmljZSB0YWJsZSBlbnRyeTogZGV2aWNl
IGlkID0gMHgwYTA2LCBpbnRlcnVwdCB0YWJsZSA9IDB4MjRkOTgwMDAwDQooWEVOKSBBTUQt
Vmk6IEFkZCBkZXZpY2UgdGFibGUgZW50cnk6IGRldmljZSBpZCA9IDB4MGEwNywgaW50ZXJ1
cHQgdGFibGUgPSAweDI0ZDk4MDAwMA0KKFhFTikgQU1ELVZpOiBBZGQgZGV2aWNlIHRhYmxl
IGVudHJ5OiBkZXZpY2UgaWQgPSAweDBiMDAsIGludGVydXB0IHRhYmxlID0gMHgyNGQ5ODAw
MDANCihYRU4pIEFNRC1WaTogSU9NTVUgMCBFbmFibGVkLg0KKFhFTikgQU1ELVZpOiBFbmFi
bGluZyBnbG9iYWwgdmVjdG9yIG1hcA0KKFhFTikgSS9PIHZpcnR1YWxpc2F0aW9uIGVuYWJs
ZWQNCihYRU4pICAtIERvbTAgbW9kZTogUmVsYXhlZA0KKFhFTikgR2V0dGluZyBWRVJTSU9O
OiA4MDA1MDAxMA0KKFhFTikgR2V0dGluZyBWRVJTSU9OOiA4MDA1MDAxMA0KKFhFTikgR2V0
dGluZyBJRDogMA0KKFhFTikgR2V0dGluZyBMVlQwOiA3MDANCihYRU4pIEdldHRpbmcgTFZU
MTogNDAwDQooWEVOKSBlbmFibGVkIEV4dElOVCBvbiBDUFUjMA0KKFhFTikgRVNSIHZhbHVl
IGJlZm9yZSBlbmFibGluZyB2ZWN0b3I6IDB4MDAwMDAwMDQgIGFmdGVyOiAweDAwMDAwMDAw
DQooWEVOKSBFTkFCTElORyBJTy1BUElDIElSUXMNCihYRU4pICAtPiBVc2luZyBuZXcgQUNL
IG1ldGhvZA0KKFhFTikgaW5pdCBJT19BUElDIElSUXMNCihYRU4pICBJTy1BUElDIChhcGlj
aWQtcGluKSA2LTAsIDYtMTYsIDYtMTcsIDYtMTgsIDYtMTksIDYtMjAsIDYtMjEsIDYtMjIs
IDYtMjMsIDctMCwgNy0xLCA3LTIsIDctMywgNy00LCA3LTUsIDctNiwgNy03LCA3LTgsIDct
OSwgNy0xMCwgNy0xMSwgNy0xMiwgNy0xMywgNy0xNCwgNy0xNSwgNy0xNiwgNy0xNywgNy0x
OCwgNy0xOSwgNy0yMCwgNy0yMSwgNy0yMiwgNy0yMywgNy0yNCwgNy0yNSwgNy0yNiwgNy0y
NywgNy0yOCwgNy0yOSwgNy0zMCwgNy0zMSBub3QgY29ubmVjdGVkLg0KKFhFTikgLi5USU1F
UjogdmVjdG9yPTB4RjAgYXBpYzE9MCBwaW4xPTIgYXBpYzI9LTEgcGluMj0tMQ0KKFhFTikg
bnVtYmVyIG9mIE1QIElSUSBzb3VyY2VzOiAxNS4NCihYRU4pIG51bWJlciBvZiBJTy1BUElD
ICM2IHJlZ2lzdGVyczogMjQuDQooWEVOKSBudW1iZXIgb2YgSU8tQVBJQyAjNyByZWdpc3Rl
cnM6IDMyLg0KKFhFTikgdGVzdGluZyB0aGUgSU8gQVBJQy4uLi4uLi4uLi4uLi4uLi4uLi4u
Li4uDQooWEVOKSBJTyBBUElDICM2Li4uLi4uDQooWEVOKSAuLi4uIHJlZ2lzdGVyICMwMDog
MDYwMDAwMDANCihYRU4pIC4uLi4uLi4gICAgOiBwaHlzaWNhbCBBUElDIGlkOiAwNg0KKFhF
TikgLi4uLi4uLiAgICA6IERlbGl2ZXJ5IFR5cGU6IDANCihYRU4pIC4uLi4uLi4gICAgOiBM
VFMgICAgICAgICAgOiAwDQooWEVOKSAuLi4uIHJlZ2lzdGVyICMwMTogMDAxNzgwMjENCihY
RU4pIC4uLi4uLi4gICAgIDogbWF4IHJlZGlyZWN0aW9uIGVudHJpZXM6IDAwMTcNCihYRU4p
IC4uLi4uLi4gICAgIDogUFJRIGltcGxlbWVudGVkOiAxDQooWEVOKSAuLi4uLi4uICAgICA6
IElPIEFQSUMgdmVyc2lvbjogMDAyMQ0KKFhFTikgLi4uLiByZWdpc3RlciAjMDI6IDA2MDAw
MDAwDQooWEVOKSAuLi4uLi4uICAgICA6IGFyYml0cmF0aW9uOiAwNg0KKFhFTikgLi4uLiBy
ZWdpc3RlciAjMDM6IDA3MDAwMDAwDQooWEVOKSAuLi4uLi4uICAgICA6IEJvb3QgRFQgICAg
OiAwDQooWEVOKSAuLi4uIElSUSByZWRpcmVjdGlvbiB0YWJsZToNCihYRU4pICBOUiBMb2cg
UGh5IE1hc2sgVHJpZyBJUlIgUG9sIFN0YXQgRGVzdCBEZWxpIFZlY3Q6ICAgDQooWEVOKSAg
MDAgMDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAwICAgIDAgICAgMCAgICAwMA0KKFhFTikg
IDAxIDAwMSAwMSAgMCAgICAwICAgIDAgICAwICAgMCAgICAxICAgIDEgICAgMzANCihYRU4p
ICAwMiAwMDEgMDEgIDAgICAgMCAgICAwICAgMCAgIDAgICAgMSAgICAxICAgIEYwDQooWEVO
KSAgMDMgMDAxIDAxICAwICAgIDAgICAgMCAgIDAgICAwICAgIDEgICAgMSAgICAzOA0KKFhF
TikgIDA0IDAwMSAwMSAgMCAgICAwICAgIDAgICAwICAgMCAgICAxICAgIDEgICAgRjENCihY
RU4pICAwNSAwMDEgMDEgIDAgICAgMCAgICAwICAgMCAgIDAgICAgMSAgICAxICAgIDQwDQoo
WEVOKSAgMDYgMDAxIDAxICAwICAgIDAgICAgMCAgIDAgICAwICAgIDEgICAgMSAgICA0OA0K
KFhFTikgIDA3IDAwMSAwMSAgMCAgICAwICAgIDAgICAwICAgMCAgICAxICAgIDEgICAgNTAN
CihYRU4pICAwOCAwMDEgMDEgIDAgICAgMCAgICAwICAgMCAgIDAgICAgMSAgICAxICAgIDU4
DQooWEVOKSAgMDkgMDAxIDAxICAxICAgIDEgICAgMCAgIDEgICAwICAgIDEgICAgMSAgICA2
MA0KKFhFTikgIDBhIDAwMSAwMSAgMCAgICAwICAgIDAgICAwICAgMCAgICAxICAgIDEgICAg
NjgNCihYRU4pICAwYiAwMDEgMDEgIDAgICAgMCAgICAwICAgMCAgIDAgICAgMSAgICAxICAg
IDcwDQooWEVOKSAgMGMgMDAxIDAxICAwICAgIDAgICAgMCAgIDAgICAwICAgIDEgICAgMSAg
ICA3OA0KKFhFTikgIDBkIDAwMSAwMSAgMCAgICAwICAgIDAgICAwICAgMCAgICAxICAgIDEg
ICAgODgNCihYRU4pICAwZSAwMDEgMDEgIDAgICAgMCAgICAwICAgMCAgIDAgICAgMSAgICAx
ICAgIDkwDQooWEVOKSAgMGYgMDAxIDAxICAwICAgIDAgICAgMCAgIDAgICAwICAgIDEgICAg
MSAgICA5OA0KKFhFTikgIDEwIDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAg
IDAgICAgMDANCihYRU4pICAxMSAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAg
ICAwICAgIDAwDQooWEVOKSAgMTIgMDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAwICAgIDAg
ICAgMCAgICAwMA0KKFhFTikgIDEzIDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAw
ICAgIDAgICAgMDANCihYRU4pICAxNCAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAg
MCAgICAwICAgIDAwDQooWEVOKSAgMTUgMDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAwICAg
IDAgICAgMCAgICAwMA0KKFhFTikgIDE2IDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAg
ICAwICAgIDAgICAgMDANCihYRU4pICAxNyAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAg
ICAgMCAgICAwICAgIDAwDQooWEVOKSBJTyBBUElDICM3Li4uLi4uDQooWEVOKSAuLi4uIHJl
Z2lzdGVyICMwMDogMDcwMDAwMDANCihYRU4pIC4uLi4uLi4gICAgOiBwaHlzaWNhbCBBUElD
IGlkOiAwNw0KKFhFTikgLi4uLi4uLiAgICA6IERlbGl2ZXJ5IFR5cGU6IDANCihYRU4pIC4u
Li4uLi4gICAgOiBMVFMgICAgICAgICAgOiAwDQooWEVOKSAuLi4uIHJlZ2lzdGVyICMwMTog
MDAxRjgwMjENCihYRU4pIC4uLi4uLi4gICAgIDogbWF4IHJlZGlyZWN0aW9uIGVudHJpZXM6
IDAwMUYNCihYRU4pIC4uLi4uLi4gICAgIDogUFJRIGltcGxlbWVudGVkOiAxDQooWEVOKSAu
Li4uLi4uICAgICA6IElPIEFQSUMgdmVyc2lvbjogMDAyMQ0KKFhFTikgLi4uLiByZWdpc3Rl
ciAjMDI6IDAwMDAwMDAwDQooWEVOKSAuLi4uLi4uICAgICA6IGFyYml0cmF0aW9uOiAwMA0K
KFhFTikgLi4uLiBJUlEgcmVkaXJlY3Rpb24gdGFibGU6DQooWEVOKSAgTlIgTG9nIFBoeSBN
YXNrIFRyaWcgSVJSIFBvbCBTdGF0IERlc3QgRGVsaSBWZWN0OiAgIA0KKFhFTikgIDAwIDAw
MCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDAgICAgMDANCihYRU4pICAwMSAw
MDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwDQooWEVOKSAgMDIg
MDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAwICAgIDAgICAgMCAgICAwMA0KKFhFTikgIDAz
IDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDAgICAgMDANCihYRU4pICAw
NCAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwDQooWEVOKSAg
MDUgMDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAwICAgIDAgICAgMCAgICAwMA0KKFhFTikg
IDA2IDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDAgICAgMDANCihYRU4p
ICAwNyAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwDQooWEVO
KSAgMDggMDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAwICAgIDAgICAgMCAgICAwMA0KKFhF
TikgIDA5IDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDAgICAgMDANCihY
RU4pICAwYSAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwDQoo
WEVOKSAgMGIgMDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAwICAgIDAgICAgMCAgICAwMA0K
KFhFTikgIDBjIDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDAgICAgMDAN
CihYRU4pICAwZCAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAw
DQooWEVOKSAgMGUgMDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAwICAgIDAgICAgMCAgICAw
MA0KKFhFTikgIDBmIDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDAgICAg
MDANCihYRU4pICAxMCAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAg
IDAwDQooWEVOKSAgMTEgMDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAwICAgIDAgICAgMCAg
ICAwMA0KKFhFTikgIDEyIDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDAg
ICAgMDANCihYRU4pICAxMyAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAw
ICAgIDAwDQooWEVOKSAgMTQgMDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAwICAgIDAgICAg
MCAgICAwMA0KKFhFTikgIDE1IDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAg
IDAgICAgMDANCihYRU4pICAxNiAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAg
ICAwICAgIDAwDQooWEVOKSAgMTcgMDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAwICAgIDAg
ICAgMCAgICAwMA0KKFhFTikgIDE4IDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAw
ICAgIDAgICAgMDANCihYRU4pICAxOSAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAg
MCAgICAwICAgIDAwDQooWEVOKSAgMWEgMDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAwICAg
IDAgICAgMCAgICAwMA0KKFhFTikgIDFiIDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAg
ICAwICAgIDAgICAgMDANCihYRU4pICAxYyAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAg
ICAgMCAgICAwICAgIDAwDQooWEVOKSAgMWQgMDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAw
ICAgIDAgICAgMCAgICAwMA0KKFhFTikgIDFlIDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAg
MCAgICAwICAgIDAgICAgMDANCihYRU4pICAxZiAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAg
IDAgICAgMCAgICAwICAgIDAwDQooWEVOKSBVc2luZyB2ZWN0b3ItYmFzZWQgaW5kZXhpbmcN
CihYRU4pIElSUSB0byBwaW4gbWFwcGluZ3M6DQooWEVOKSBJUlEyNDAgLT4gMDoyDQooWEVO
KSBJUlE0OCAtPiAwOjENCihYRU4pIElSUTU2IC0+IDA6Mw0KKFhFTikgSVJRMjQxIC0+IDA6
NA0KKFhFTikgSVJRNjQgLT4gMDo1DQooWEVOKSBJUlE3MiAtPiAwOjYNCihYRU4pIElSUTgw
IC0+IDA6Nw0KKFhFTikgSVJRODggLT4gMDo4DQooWEVOKSBJUlE5NiAtPiAwOjkNCihYRU4p
IElSUTEwNCAtPiAwOjEwDQooWEVOKSBJUlExMTIgLT4gMDoxMQ0KKFhFTikgSVJRMTIwIC0+
IDA6MTINCihYRU4pIElSUTEzNiAtPiAwOjEzDQooWEVOKSBJUlExNDQgLT4gMDoxNA0KKFhF
TikgSVJRMTUyIC0+IDA6MTUNCihYRU4pIC4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u
Li4uLi4uLiBkb25lLg0KKFhFTikgVXNpbmcgbG9jYWwgQVBJQyB0aW1lciBpbnRlcnJ1cHRz
Lg0KKFhFTikgY2FsaWJyYXRpbmcgQVBJQyB0aW1lciAuLi4NCihYRU4pIC4uLi4uIENQVSBj
bG9jayBzcGVlZCBpcyAzMjAwLjIwNDAgTUh6Lg0KKFhFTikgLi4uLi4gaG9zdCBidXMgY2xv
Y2sgc3BlZWQgaXMgMjAwLjAxMjYgTUh6Lg0KKFhFTikgLi4uLi4gYnVzX3NjYWxlID0gMHgw
MDAwQ0NENw0KKFhFTikgWzIwMTItMDktMDYgMjI6MTQ6MzNdIFBsYXRmb3JtIHRpbWVyIGlz
IDE0LjMxOE1IeiBIUEVUDQooWEVOKSBbMjAxMi0wOS0wNiAyMjoxNDozM10gQWxsb2NhdGVk
IGNvbnNvbGUgcmluZyBvZiA2NCBLaUIuDQooWEVOKSBbMjAxMi0wOS0wNiAyMjoxNDozM10g
SFZNOiBBU0lEcyBlbmFibGVkLg0KKFhFTikgWzIwMTItMDktMDYgMjI6MTQ6MzNdIFNWTTog
U3VwcG9ydGVkIGFkdmFuY2VkIGZlYXR1cmVzOg0KKFhFTikgWzIwMTItMDktMDYgMjI6MTQ6
MzNdICAtIE5lc3RlZCBQYWdlIFRhYmxlcyAoTlBUKQ0KKFhFTikgWzIwMTItMDktMDYgMjI6
MTQ6MzNdICAtIExhc3QgQnJhbmNoIFJlY29yZCAoTEJSKSBWaXJ0dWFsaXNhdGlvbg0KKFhF
TikgWzIwMTItMDktMDYgMjI6MTQ6MzNdICAtIE5leHQtUklQIFNhdmVkIG9uICNWTUVYSVQN
CihYRU4pIFsyMDEyLTA5LTA2IDIyOjE0OjMzXSAgLSBQYXVzZS1JbnRlcmNlcHQgRmlsdGVy
DQooWEVOKSBbMjAxMi0wOS0wNiAyMjoxNDozM10gSFZNOiBTVk0gZW5hYmxlZA0KKFhFTikg
WzIwMTItMDktMDYgMjI6MTQ6MzNdIEhWTTogSGFyZHdhcmUgQXNzaXN0ZWQgUGFnaW5nIChI
QVApIGRldGVjdGVkDQooWEVOKSBbMjAxMi0wOS0wNiAyMjoxNDozM10gSFZNOiBIQVAgcGFn
ZSBzaXplczogNGtCLCAyTUIsIDFHQg0KKFhFTikgWzIwMTItMDktMDYgMjI6MTQ6MzJdIG1h
c2tlZCBFeHRJTlQgb24gQ1BVIzENCihYRU4pIFsyMDEyLTA5LTA2IDIyOjE0OjMyXSBtYXNr
ZWQgRXh0SU5UIG9uIENQVSMyDQooWEVOKSBbMjAxMi0wOS0wNiAyMjoxNDozMl0gbWFza2Vk
IEV4dElOVCBvbiBDUFUjMw0KKFhFTikgWzIwMTItMDktMDYgMjI6MTQ6MzJdIG1hc2tlZCBF
eHRJTlQgb24gQ1BVIzQNCihYRU4pIFsyMDEyLTA5LTA2IDIyOjE0OjMyXSBtYXNrZWQgRXh0
SU5UIG9uIENQVSM1DQooWEVOKSBbMjAxMi0wOS0wNiAyMjoxNDozM10gQnJvdWdodCB1cCA2
IENQVXMNCihYRU4pIFsyMDEyLTA5LTA2IDIyOjE0OjMzXSBIUEVUXDA0N3MgTVNJIG1vZGUg
aGFzblwwNDd0IGJlZW4gc3VwcG9ydGVkIHdoZW4gSW50ZXJydXB0IFJlbWFwcGluZyBpcyBl
bmFibGVkLg0KKFhFTikgWzIwMTItMDktMDYgMjI6MTQ6MzNdIEFDUEkgc2xlZXAgbW9kZXM6
IFMzDQooWEVOKSBbMjAxMi0wOS0wNiAyMjoxNDozM10gTUNBOiBVc2UgaHcgdGhyZXNob2xk
aW5nIHRvIGFkanVzdCBwb2xsaW5nIGZyZXF1ZW5jeQ0KKFhFTikgWzIwMTItMDktMDYgMjI6
MTQ6MzNdIG1jaGVja19wb2xsOiBNYWNoaW5lIGNoZWNrIHBvbGxpbmcgdGltZXIgc3RhcnRl
ZC4NCihYRU4pIFsyMDEyLTA5LTA2IDIyOjE0OjMzXSBYZW5vcHJvZmlsZTogRmFpbGVkIHRv
IHNldHVwIElCUyBMVlQgb2Zmc2V0LCBJQlNDVEwgPSAweGZmZmZmZmZmDQooWEVOKSBbMjAx
Mi0wOS0wNiAyMjoxNDozM10gKioqIExPQURJTkcgRE9NQUlOIDAgKioqDQooWEVOKSBbMjAx
Mi0wOS0wNiAyMjoxNDozM10gZWxmX3BhcnNlX2JpbmFyeTogcGhkcjogcGFkZHI9MHgxMDAw
MDAwIG1lbXN6PTB4ZDZhMDAwDQooWEVOKSBbMjAxMi0wOS0wNiAyMjoxNDozM10gZWxmX3Bh
cnNlX2JpbmFyeTogcGhkcjogcGFkZHI9MHgxZTAwMDAwIG1lbXN6PTB4ZGIwZTgNCihYRU4p
IFsyMDEyLTA5LTA2IDIyOjE0OjMzXSBlbGZfcGFyc2VfYmluYXJ5OiBwaGRyOiBwYWRkcj0w
eDFlZGMwMDAgbWVtc3o9MHgxM2MwMA0KKFhFTikgWzIwMTItMDktMDYgMjI6MTQ6MzNdIGVs
Zl9wYXJzZV9iaW5hcnk6IHBoZHI6IHBhZGRyPTB4MWVmMDAwMCBtZW1zej0weGRlNTAwMA0K
KFhFTikgWzIwMTItMDktMDYgMjI6MTQ6MzNdIGVsZl9wYXJzZV9iaW5hcnk6IG1lbW9yeTog
MHgxMDAwMDAwIC0+IDB4MmNkNTAwMA0KKFhFTikgWzIwMTItMDktMDYgMjI6MTQ6MzNdIGVs
Zl94ZW5fcGFyc2Vfbm90ZTogR1VFU1RfT1MgPSAibGludXgiDQooWEVOKSBbMjAxMi0wOS0w
NiAyMjoxNDozM10gZWxmX3hlbl9wYXJzZV9ub3RlOiBHVUVTVF9WRVJTSU9OID0gIjIuNiIN
CihYRU4pIFsyMDEyLTA5LTA2IDIyOjE0OjMzXSBlbGZfeGVuX3BhcnNlX25vdGU6IFhFTl9W
RVJTSU9OID0gInhlbi0zLjAiDQooWEVOKSBbMjAxMi0wOS0wNiAyMjoxNDozM10gZWxmX3hl
bl9wYXJzZV9ub3RlOiBWSVJUX0JBU0UgPSAweGZmZmZmZmZmODAwMDAwMDANCihYRU4pIFsy
MDEyLTA5LTA2IDIyOjE0OjMzXSBlbGZfeGVuX3BhcnNlX25vdGU6IEVOVFJZID0gMHhmZmZm
ZmZmZjgxZWYwMjEwDQooWEVOKSBbMjAxMi0wOS0wNiAyMjoxNDozM10gZWxmX3hlbl9wYXJz
ZV9ub3RlOiBIWVBFUkNBTExfUEFHRSA9IDB4ZmZmZmZmZmY4MTAwMTAwMA0KKFhFTikgWzIw
MTItMDktMDYgMjI6MTQ6MzNdIGVsZl94ZW5fcGFyc2Vfbm90ZTogRkVBVFVSRVMgPSAiIXdy
aXRhYmxlX3BhZ2VfdGFibGVzfHBhZV9wZ2Rpcl9hYm92ZV80Z2IiDQooWEVOKSBbMjAxMi0w
OS0wNiAyMjoxNDozM10gZWxmX3hlbl9wYXJzZV9ub3RlOiBQQUVfTU9ERSA9ICJ5ZXMiDQoo
WEVOKSBbMjAxMi0wOS0wNiAyMjoxNDozM10gZWxmX3hlbl9wYXJzZV9ub3RlOiBMT0FERVIg
PSAiZ2VuZXJpYyINCihYRU4pIFsyMDEyLTA5LTA2IDIyOjE0OjMzXSBlbGZfeGVuX3BhcnNl
X25vdGU6IHVua25vd24geGVuIGVsZiBub3RlICgweGQpDQooWEVOKSBbMjAxMi0wOS0wNiAy
MjoxNDozM10gZWxmX3hlbl9wYXJzZV9ub3RlOiBTVVNQRU5EX0NBTkNFTCA9IDB4MQ0KKFhF
TikgWzIwMTItMDktMDYgMjI6MTQ6MzNdIGVsZl94ZW5fcGFyc2Vfbm90ZTogSFZfU1RBUlRf
TE9XID0gMHhmZmZmODAwMDAwMDAwMDAwDQooWEVOKSBbMjAxMi0wOS0wNiAyMjoxNDozM10g
ZWxmX3hlbl9wYXJzZV9ub3RlOiBQQUREUl9PRkZTRVQgPSAweDANCihYRU4pIFsyMDEyLTA5
LTA2IDIyOjE0OjMzXSBlbGZfeGVuX2FkZHJfY2FsY19jaGVjazogYWRkcmVzc2VzOg0KKFhF
TikgWzIwMTItMDktMDYgMjI6MTQ6MzNdICAgICB2aXJ0X2Jhc2UgICAgICAgID0gMHhmZmZm
ZmZmZjgwMDAwMDAwDQooWEVOKSBbMjAxMi0wOS0wNiAyMjoxNDozM10gICAgIGVsZl9wYWRk
cl9vZmZzZXQgPSAweDANCihYRU4pIFsyMDEyLTA5LTA2IDIyOjE0OjMzXSAgICAgdmlydF9v
ZmZzZXQgICAgICA9IDB4ZmZmZmZmZmY4MDAwMDAwMA0KKFhFTikgWzIwMTItMDktMDYgMjI6
MTQ6MzNdICAgICB2aXJ0X2tzdGFydCAgICAgID0gMHhmZmZmZmZmZjgxMDAwMDAwDQooWEVO
KSBbMjAxMi0wOS0wNiAyMjoxNDozM10gICAgIHZpcnRfa2VuZCAgICAgICAgPSAweGZmZmZm
ZmZmODJjZDUwMDANCihYRU4pIFsyMDEyLTA5LTA2IDIyOjE0OjMzXSAgICAgdmlydF9lbnRy
eSAgICAgICA9IDB4ZmZmZmZmZmY4MWVmMDIxMA0KKFhFTikgWzIwMTItMDktMDYgMjI6MTQ6
MzNdICAgICBwMm1fYmFzZSAgICAgICAgID0gMHhmZmZmZmZmZmZmZmZmZmZmDQooWEVOKSBb
MjAxMi0wOS0wNiAyMjoxNDozM10gIFhlbiAga2VybmVsOiA2NC1iaXQsIGxzYiwgY29tcGF0
MzINCihYRU4pIFsyMDEyLTA5LTA2IDIyOjE0OjMzXSAgRG9tMCBrZXJuZWw6IDY0LWJpdCwg
UEFFLCBsc2IsIHBhZGRyIDB4MTAwMDAwMCAtPiAweDJjZDUwMDANCihYRU4pIFsyMDEyLTA5
LTA2IDIyOjE0OjMzXSBQSFlTSUNBTCBNRU1PUlkgQVJSQU5HRU1FTlQ6DQooWEVOKSBbMjAx
Mi0wOS0wNiAyMjoxNDozM10gIERvbTAgYWxsb2MuOiAgIDAwMDAwMDAyNDAwMDAwMDAtPjAw
MDAwMDAyNDQwMDAwMDAgKDI0MjQyOCBwYWdlcyB0byBiZSBhbGxvY2F0ZWQpDQooWEVOKSBb
MjAxMi0wOS0wNiAyMjoxNDozM10gIEluaXQuIHJhbWRpc2s6IDAwMDAwMDAyNGYyZmMwMDAt
PjAwMDAwMDAyNGZmZmY4MDANCihYRU4pIFsyMDEyLTA5LTA2IDIyOjE0OjMzXSBWSVJUVUFM
IE1FTU9SWSBBUlJBTkdFTUVOVDoNCihYRU4pIFsyMDEyLTA5LTA2IDIyOjE0OjMzXSAgTG9h
ZGVkIGtlcm5lbDogZmZmZmZmZmY4MTAwMDAwMC0+ZmZmZmZmZmY4MmNkNTAwMA0KKFhFTikg
WzIwMTItMDktMDYgMjI6MTQ6MzNdICBJbml0LiByYW1kaXNrOiBmZmZmZmZmZjgyY2Q1MDAw
LT5mZmZmZmZmZjgzOWQ4ODAwDQooWEVOKSBbMjAxMi0wOS0wNiAyMjoxNDozM10gIFBoeXMt
TWFjaCBtYXA6IGZmZmZmZmZmODM5ZDkwMDAtPmZmZmZmZmZmODNiZDkwMDANCihYRU4pIFsy
MDEyLTA5LTA2IDIyOjE0OjMzXSAgU3RhcnQgaW5mbzogICAgZmZmZmZmZmY4M2JkOTAwMC0+
ZmZmZmZmZmY4M2JkOTRiNA0KKFhFTikgWzIwMTItMDktMDYgMjI6MTQ6MzNdICBQYWdlIHRh
YmxlczogICBmZmZmZmZmZjgzYmRhMDAwLT5mZmZmZmZmZjgzYmZkMDAwDQooWEVOKSBbMjAx
Mi0wOS0wNiAyMjoxNDozM10gIEJvb3Qgc3RhY2s6ICAgIGZmZmZmZmZmODNiZmQwMDAtPmZm
ZmZmZmZmODNiZmUwMDANCihYRU4pIFsyMDEyLTA5LTA2IDIyOjE0OjMzXSAgVE9UQUw6ICAg
ICAgICAgZmZmZmZmZmY4MDAwMDAwMC0+ZmZmZmZmZmY4NDAwMDAwMA0KKFhFTikgWzIwMTIt
MDktMDYgMjI6MTQ6MzNdICBFTlRSWSBBRERSRVNTOiBmZmZmZmZmZjgxZWYwMjEwDQooWEVO
KSBbMjAxMi0wOS0wNiAyMjoxNDozM10gRG9tMCBoYXMgbWF4aW11bSA2IFZDUFVzDQooWEVO
KSBbMjAxMi0wOS0wNiAyMjoxNDozM10gZWxmX2xvYWRfYmluYXJ5OiBwaGRyIDAgYXQgMHhm
ZmZmZmZmZjgxMDAwMDAwIC0+IDB4ZmZmZmZmZmY4MWQ2YTAwMA0KKFhFTikgWzIwMTItMDkt
MDYgMjI6MTQ6MzRdIGVsZl9sb2FkX2JpbmFyeTogcGhkciAxIGF0IDB4ZmZmZmZmZmY4MWUw
MDAwMCAtPiAweGZmZmZmZmZmODFlZGIwZTgNCihYRU4pIFsyMDEyLTA5LTA2IDIyOjE0OjM0
XSBlbGZfbG9hZF9iaW5hcnk6IHBoZHIgMiBhdCAweGZmZmZmZmZmODFlZGMwMDAgLT4gMHhm
ZmZmZmZmZjgxZWVmYzAwDQooWEVOKSBbMjAxMi0wOS0wNiAyMjoxNDozNF0gZWxmX2xvYWRf
YmluYXJ5OiBwaGRyIDMgYXQgMHhmZmZmZmZmZjgxZWYwMDAwIC0+IDB4ZmZmZmZmZmY4MWY4
OTAwMA0KKFhFTikgWzIwMTItMDktMDYgMjI6MTQ6MzRdIEFNRC1WaTogU2V0dXAgSS9PIHBh
Z2UgdGFibGU6IGRldmljZSBpZCA9IDB4MDAwMCwgcm9vdCB0YWJsZSA9IDB4MjRkODIzMDAw
LCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMNCihYRU4pIFsyMDEyLTA5LTA2IDIyOjE0
OjM0XSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweDAwMDIs
IHJvb3QgdGFibGUgPSAweDI0ZDgyMzAwMCwgZG9tYWluID0gMCwgcGFnaW5nIG1vZGUgPSAz
DQooWEVOKSBbMjAxMi0wOS0wNiAyMjoxNDozNF0gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0
YWJsZTogZGV2aWNlIGlkID0gMHgwMDEwLCByb290IHRhYmxlID0gMHgyNGQ4MjMwMDAsIGRv
bWFpbiA9IDAsIHBhZ2luZyBtb2RlID0gMw0KKFhFTikgWzIwMTItMDktMDYgMjI6MTQ6MzRd
IEFNRC1WaTogU2V0dXAgSS9PIHBhZ2UgdGFibGU6IGRldmljZSBpZCA9IDB4MDAxOCwgcm9v
dCB0YWJsZSA9IDB4MjRkODIzMDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMNCihY
RU4pIFsyMDEyLTA5LTA2IDIyOjE0OjM0XSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxl
OiBkZXZpY2UgaWQgPSAweDAwMjgsIHJvb3QgdGFibGUgPSAweDI0ZDgyMzAwMCwgZG9tYWlu
ID0gMCwgcGFnaW5nIG1vZGUgPSAzDQooWEVOKSBbMjAxMi0wOS0wNiAyMjoxNDozNF0gQU1E
LVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHgwMDMwLCByb290IHRh
YmxlID0gMHgyNGQ4MjMwMDAsIGRvbWFpbiA9IDAsIHBhZ2luZyBtb2RlID0gMw0KKFhFTikg
WzIwMTItMDktMDYgMjI6MTQ6MzRdIEFNRC1WaTogU2V0dXAgSS9PIHBhZ2UgdGFibGU6IGRl
dmljZSBpZCA9IDB4MDA1MCwgcm9vdCB0YWJsZSA9IDB4MjRkODIzMDAwLCBkb21haW4gPSAw
LCBwYWdpbmcgbW9kZSA9IDMNCihYRU4pIFsyMDEyLTA5LTA2IDIyOjE0OjM0XSBBTUQtVmk6
IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweDAwNTgsIHJvb3QgdGFibGUg
PSAweDI0ZDgyMzAwMCwgZG9tYWluID0gMCwgcGFnaW5nIG1vZGUgPSAzDQooWEVOKSBbMjAx
Mi0wOS0wNiAyMjoxNDozNF0gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNl
IGlkID0gMHgwMDYwLCByb290IHRhYmxlID0gMHgyNGQ4MjMwMDAsIGRvbWFpbiA9IDAsIHBh
Z2luZyBtb2RlID0gMw0KKFhFTikgWzIwMTItMDktMDYgMjI6MTQ6MzRdIEFNRC1WaTogU2V0
dXAgSS9PIHBhZ2UgdGFibGU6IGRldmljZSBpZCA9IDB4MDA2OCwgcm9vdCB0YWJsZSA9IDB4
MjRkODIzMDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMNCihYRU4pIFsyMDEyLTA5
LTA2IDIyOjE0OjM0XSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQg
PSAweDAwODgsIHJvb3QgdGFibGUgPSAweDI0ZDgyMzAwMCwgZG9tYWluID0gMCwgcGFnaW5n
IG1vZGUgPSAzDQooWEVOKSBbMjAxMi0wOS0wNiAyMjoxNDozNF0gQU1ELVZpOiBTZXR1cCBJ
L08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHgwMDkwLCByb290IHRhYmxlID0gMHgyNGQ4
MjMwMDAsIGRvbWFpbiA9IDAsIHBhZ2luZyBtb2RlID0gMw0KKFhFTikgWzIwMTItMDktMDYg
MjI6MTQ6MzRdIEFNRC1WaTogU2V0dXAgSS9PIHBhZ2UgdGFibGU6IGRldmljZSBpZCA9IDB4
MDA5Miwgcm9vdCB0YWJsZSA9IDB4MjRkODIzMDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9k
ZSA9IDMNCihYRU4pIFsyMDEyLTA5LTA2IDIyOjE0OjM0XSBBTUQtVmk6IFNldHVwIEkvTyBw
YWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweDAwOTgsIHJvb3QgdGFibGUgPSAweDI0ZDgyMzAw
MCwgZG9tYWluID0gMCwgcGFnaW5nIG1vZGUgPSAzDQooWEVOKSBbMjAxMi0wOS0wNiAyMjox
NDozNF0gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHgwMDlh
LCByb290IHRhYmxlID0gMHgyNGQ4MjMwMDAsIGRvbWFpbiA9IDAsIHBhZ2luZyBtb2RlID0g
Mw0KKFhFTikgWzIwMTItMDktMDYgMjI6MTQ6MzRdIEFNRC1WaTogU2V0dXAgSS9PIHBhZ2Ug
dGFibGU6IGRldmljZSBpZCA9IDB4MDBhMCwgcm9vdCB0YWJsZSA9IDB4MjRkODIzMDAwLCBk
b21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMNCihYRU4pIFsyMDEyLTA5LTA2IDIyOjE0OjM0
XSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweDAwYTMsIHJv
b3QgdGFibGUgPSAweDI0ZDgyMzAwMCwgZG9tYWluID0gMCwgcGFnaW5nIG1vZGUgPSAzDQoo
WEVOKSBbMjAxMi0wOS0wNiAyMjoxNDozNF0gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJs
ZTogZGV2aWNlIGlkID0gMHgwMGE0LCByb290IHRhYmxlID0gMHgyNGQ4MjMwMDAsIGRvbWFp
biA9IDAsIHBhZ2luZyBtb2RlID0gMw0KKFhFTikgWzIwMTItMDktMDYgMjI6MTQ6MzRdIEFN
RC1WaTogU2V0dXAgSS9PIHBhZ2UgdGFibGU6IGRldmljZSBpZCA9IDB4MDBhNSwgcm9vdCB0
YWJsZSA9IDB4MjRkODIzMDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMNCihYRU4p
IFsyMDEyLTA5LTA2IDIyOjE0OjM0XSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBk
ZXZpY2UgaWQgPSAweDAwYTgsIHJvb3QgdGFibGUgPSAweDI0ZDgyMzAwMCwgZG9tYWluID0g
MCwgcGFnaW5nIG1vZGUgPSAzDQooWEVOKSBbMjAxMi0wOS0wNiAyMjoxNDozNF0gQU1ELVZp
OiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHgwMGIwLCByb290IHRhYmxl
ID0gMHgyNGQ4MjMwMDAsIGRvbWFpbiA9IDAsIHBhZ2luZyBtb2RlID0gMw0KKFhFTikgWzIw
MTItMDktMDYgMjI6MTQ6MzRdIEFNRC1WaTogU2V0dXAgSS9PIHBhZ2UgdGFibGU6IGRldmlj
ZSBpZCA9IDB4MDBiMiwgcm9vdCB0YWJsZSA9IDB4MjRkODIzMDAwLCBkb21haW4gPSAwLCBw
YWdpbmcgbW9kZSA9IDMNCihYRU4pIFsyMDEyLTA5LTA2IDIyOjE0OjM0XSBBTUQtVmk6IE5v
IGlvbW11IGZvciBkZXZpY2UgMDA6MTguMA0KKFhFTikgWzIwMTItMDktMDYgMjI6MTQ6MzRd
IEFNRC1WaTogTm8gaW9tbXUgZm9yIGRldmljZSAwMDoxOC4xDQooWEVOKSBbMjAxMi0wOS0w
NiAyMjoxNDozNF0gQU1ELVZpOiBObyBpb21tdSBmb3IgZGV2aWNlIDAwOjE4LjINCihYRU4p
IFsyMDEyLTA5LTA2IDIyOjE0OjM0XSBBTUQtVmk6IE5vIGlvbW11IGZvciBkZXZpY2UgMDA6
MTguMw0KKFhFTikgWzIwMTItMDktMDYgMjI6MTQ6MzRdIEFNRC1WaTogTm8gaW9tbXUgZm9y
IGRldmljZSAwMDoxOC40DQooWEVOKSBbMjAxMi0wOS0wNiAyMjoxNDozNF0gQU1ELVZpOiBT
ZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHgwNDAwLCByb290IHRhYmxlID0g
MHgyNGQ4MjMwMDAsIGRvbWFpbiA9IDAsIHBhZ2luZyBtb2RlID0gMw0KKFhFTikgWzIwMTIt
MDktMDYgMjI6MTQ6MzRdIEFNRC1WaTogU2V0dXAgSS9PIHBhZ2UgdGFibGU6IGRldmljZSBp
ZCA9IDB4MDQwMSwgcm9vdCB0YWJsZSA9IDB4MjRkODIzMDAwLCBkb21haW4gPSAwLCBwYWdp
bmcgbW9kZSA9IDMNCihYRU4pIFsyMDEyLTA5LTA2IDIyOjE0OjM0XSBBTUQtVmk6IFNldHVw
IEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweDA0MDIsIHJvb3QgdGFibGUgPSAweDI0
ZDgyMzAwMCwgZG9tYWluID0gMCwgcGFnaW5nIG1vZGUgPSAzDQooWEVOKSBbMjAxMi0wOS0w
NiAyMjoxNDozNF0gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0g
MHgwNDAzLCByb290IHRhYmxlID0gMHgyNGQ4MjMwMDAsIGRvbWFpbiA9IDAsIHBhZ2luZyBt
b2RlID0gMw0KKFhFTikgWzIwMTItMDktMDYgMjI6MTQ6MzRdIEFNRC1WaTogU2V0dXAgSS9P
IHBhZ2UgdGFibGU6IGRldmljZSBpZCA9IDB4MDQwNCwgcm9vdCB0YWJsZSA9IDB4MjRkODIz
MDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMNCihYRU4pIFsyMDEyLTA5LTA2IDIy
OjE0OjM0XSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweDA0
MDUsIHJvb3QgdGFibGUgPSAweDI0ZDgyMzAwMCwgZG9tYWluID0gMCwgcGFnaW5nIG1vZGUg
PSAzDQooWEVOKSBbMjAxMi0wOS0wNiAyMjoxNDozNF0gQU1ELVZpOiBTZXR1cCBJL08gcGFn
ZSB0YWJsZTogZGV2aWNlIGlkID0gMHgwNDA2LCByb290IHRhYmxlID0gMHgyNGQ4MjMwMDAs
IGRvbWFpbiA9IDAsIHBhZ2luZyBtb2RlID0gMw0KKFhFTikgWzIwMTItMDktMDYgMjI6MTQ6
MzRdIEFNRC1WaTogU2V0dXAgSS9PIHBhZ2UgdGFibGU6IGRldmljZSBpZCA9IDB4MDQwNywg
cm9vdCB0YWJsZSA9IDB4MjRkODIzMDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMN
CihYRU4pIFsyMDEyLTA5LTA2IDIyOjE0OjM0XSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRh
YmxlOiBkZXZpY2UgaWQgPSAweDA1MDAsIHJvb3QgdGFibGUgPSAweDI0ZDgyMzAwMCwgZG9t
YWluID0gMCwgcGFnaW5nIG1vZGUgPSAzDQooWEVOKSBbMjAxMi0wOS0wNiAyMjoxNDozNF0g
QU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHgwNjAwLCByb290
IHRhYmxlID0gMHgyNGQ4MjMwMDAsIGRvbWFpbiA9IDAsIHBhZ2luZyBtb2RlID0gMw0KKFhF
TikgWzIwMTItMDktMDYgMjI6MTQ6MzRdIEFNRC1WaTogU2V0dXAgSS9PIHBhZ2UgdGFibGU6
IGRldmljZSBpZCA9IDB4MDYwMSwgcm9vdCB0YWJsZSA9IDB4MjRkODIzMDAwLCBkb21haW4g
PSAwLCBwYWdpbmcgbW9kZSA9IDMNCihYRU4pIFsyMDEyLTA5LTA2IDIyOjE0OjM0XSBBTUQt
Vmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweDA3MDAsIHJvb3QgdGFi
bGUgPSAweDI0ZDgyMzAwMCwgZG9tYWluID0gMCwgcGFnaW5nIG1vZGUgPSAzDQooWEVOKSBb
MjAxMi0wOS0wNiAyMjoxNDozNF0gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2
aWNlIGlkID0gMHgwODAwLCByb290IHRhYmxlID0gMHgyNGQ4MjMwMDAsIGRvbWFpbiA9IDAs
IHBhZ2luZyBtb2RlID0gMw0KKFhFTikgWzIwMTItMDktMDYgMjI6MTQ6MzRdIEFNRC1WaTog
U2V0dXAgSS9PIHBhZ2UgdGFibGU6IGRldmljZSBpZCA9IDB4MDkwMCwgcm9vdCB0YWJsZSA9
IDB4MjRkODIzMDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMNCihYRU4pIFsyMDEy
LTA5LTA2IDIyOjE0OjM0XSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2Ug
aWQgPSAweDBhMDAsIHJvb3QgdGFibGUgPSAweDI0ZDgyMzAwMCwgZG9tYWluID0gMCwgcGFn
aW5nIG1vZGUgPSAzDQooWEVOKSBbMjAxMi0wOS0wNiAyMjoxNDozNF0gQU1ELVZpOiBTZXR1
cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHgwYTAxLCByb290IHRhYmxlID0gMHgy
NGQ4MjMwMDAsIGRvbWFpbiA9IDAsIHBhZ2luZyBtb2RlID0gMw0KKFhFTikgWzIwMTItMDkt
MDYgMjI6MTQ6MzRdIEFNRC1WaTogU2V0dXAgSS9PIHBhZ2UgdGFibGU6IGRldmljZSBpZCA9
IDB4MGEwMiwgcm9vdCB0YWJsZSA9IDB4MjRkODIzMDAwLCBkb21haW4gPSAwLCBwYWdpbmcg
bW9kZSA9IDMNCihYRU4pIFsyMDEyLTA5LTA2IDIyOjE0OjM0XSBBTUQtVmk6IFNldHVwIEkv
TyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweDBhMDMsIHJvb3QgdGFibGUgPSAweDI0ZDgy
MzAwMCwgZG9tYWluID0gMCwgcGFnaW5nIG1vZGUgPSAzDQooWEVOKSBbMjAxMi0wOS0wNiAy
MjoxNDozNF0gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHgw
YTA0LCByb290IHRhYmxlID0gMHgyNGQ4MjMwMDAsIGRvbWFpbiA9IDAsIHBhZ2luZyBtb2Rl
ID0gMw0KKFhFTikgWzIwMTItMDktMDYgMjI6MTQ6MzRdIEFNRC1WaTogU2V0dXAgSS9PIHBh
Z2UgdGFibGU6IGRldmljZSBpZCA9IDB4MGEwNSwgcm9vdCB0YWJsZSA9IDB4MjRkODIzMDAw
LCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMNCihYRU4pIFsyMDEyLTA5LTA2IDIyOjE0
OjM0XSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweDBhMDYs
IHJvb3QgdGFibGUgPSAweDI0ZDgyMzAwMCwgZG9tYWluID0gMCwgcGFnaW5nIG1vZGUgPSAz
DQooWEVOKSBbMjAxMi0wOS0wNiAyMjoxNDozNF0gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0
YWJsZTogZGV2aWNlIGlkID0gMHgwYTA3LCByb290IHRhYmxlID0gMHgyNGQ4MjMwMDAsIGRv
bWFpbiA9IDAsIHBhZ2luZyBtb2RlID0gMw0KKFhFTikgWzIwMTItMDktMDYgMjI6MTQ6MzRd
IEFNRC1WaTogU2V0dXAgSS9PIHBhZ2UgdGFibGU6IGRldmljZSBpZCA9IDB4MGIwMCwgcm9v
dCB0YWJsZSA9IDB4MjRkODIzMDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMNCihY
RU4pIFsyMDEyLTA5LTA2IDIyOjE0OjM0XSBTY3J1YmJpbmcgRnJlZSBSQU06IC4uLi4uLi4u
Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u
Li4uLi4uLi4uZG9uZS4NCihYRU4pIFsyMDEyLTA5LTA2IDIyOjE0OjM2XSBYZW4gdHJhY2Ug
YnVmZmVyczogZGlzYWJsZWQNCihYRU4pIFsyMDEyLTA5LTA2IDIyOjE0OjM2XSBTdGQuIExv
Z2xldmVsOiBBbGwNCihYRU4pIFsyMDEyLTA5LTA2IDIyOjE0OjM2XSBHdWVzdCBMb2dsZXZl
bDogQWxsDQooWEVOKSBbMjAxMi0wOS0wNiAyMjoxNDozNl0gWGVuIGlzIHJlbGlucXVpc2hp
bmcgVkdBIGNvbnNvbGUuDQooWEVOKSBbMjAxMi0wOS0wNiAyMjoxNDozNl0gKioqIFNlcmlh
bCBpbnB1dCAtPiBET00wICh0eXBlIFwwNDdDVFJMLWFcMDQ3IHRocmVlIHRpbWVzIHRvIHN3
aXRjaCBpbnB1dCB0byBYZW4pDQooWEVOKSBbMjAxMi0wOS0wNiAyMjoxNDozNl0gRnJlZWQg
MTk2a0IgaW5pdCBtZW1vcnkuDQooWEVOKSBbMjAxMi0wOS0wNiAyMjoxNDozNl0gSU9BUElD
WzBdOiBTZXQgUENJIHJvdXRpbmcgZW50cnkgKDYtOSAtPiAweDYwIC0+IElSUSA5IE1vZGU6
MSBBY3RpdmU6MSkNCihYRU4pIFsyMDEyLTA5LTA2IDIyOjE0OjM2XSB0cmFwcy5jOjI0ODk6
ZDAgRG9tYWluIGF0dGVtcHRlZCBXUk1TUiAwMDAwMDAwMGMwMDEwMDA0IGZyb20gMHgwMDAw
ZWZmMGJkZmIxZmI4IHRvIDB4MDAwMDAwMDAwMDAwYWJjZC4NCihYRU4pIFsyMDEyLTA5LTA2
IDIyOjE0OjM3XSBQQ0kgYWRkIGRldmljZSAwMDowMC4wDQooWEVOKSBbMjAxMi0wOS0wNiAy
MjoxNDozN10gUENJIGFkZCBkZXZpY2UgMDA6MDAuMg0KKFhFTikgWzIwMTItMDktMDYgMjI6
MTQ6MzddIFBDSSBhZGQgZGV2aWNlIDAwOjAyLjANCihYRU4pIFsyMDEyLTA5LTA2IDIyOjE0
OjM3XSBQQ0kgYWRkIGRldmljZSAwMDowMy4wDQooWEVOKSBbMjAxMi0wOS0wNiAyMjoxNDoz
N10gUENJIGFkZCBkZXZpY2UgMDA6MDUuMA0KKFhFTikgWzIwMTItMDktMDYgMjI6MTQ6Mzdd
IFBDSSBhZGQgZGV2aWNlIDAwOjA2LjANCihYRU4pIFsyMDEyLTA5LTA2IDIyOjE0OjM3XSBQ
Q0kgYWRkIGRldmljZSAwMDowYS4wDQooWEVOKSBbMjAxMi0wOS0wNiAyMjoxNDozN10gUENJ
IGFkZCBkZXZpY2UgMDA6MGIuMA0KKFhFTikgWzIwMTItMDktMDYgMjI6MTQ6MzddIFBDSSBh
ZGQgZGV2aWNlIDAwOjBjLjANCihYRU4pIFsyMDEyLTA5LTA2IDIyOjE0OjM3XSBQQ0kgYWRk
IGRldmljZSAwMDowZC4wDQooWEVOKSBbMjAxMi0wOS0wNiAyMjoxNDozN10gUENJIGFkZCBk
ZXZpY2UgMDA6MTEuMA0KKFhFTikgWzIwMTItMDktMDYgMjI6MTQ6MzddIFBDSSBhZGQgZGV2
aWNlIDAwOjEyLjANCihYRU4pIFsyMDEyLTA5LTA2IDIyOjE0OjM3XSBQQ0kgYWRkIGRldmlj
ZSAwMDoxMi4yDQooWEVOKSBbMjAxMi0wOS0wNiAyMjoxNDozN10gUENJIGFkZCBkZXZpY2Ug
MDA6MTMuMA0KKFhFTikgWzIwMTItMDktMDYgMjI6MTQ6MzddIFBDSSBhZGQgZGV2aWNlIDAw
OjEzLjINCihYRU4pIFsyMDEyLTA5LTA2IDIyOjE0OjM3XSBQQ0kgYWRkIGRldmljZSAwMDox
NC4wDQooWEVOKSBbMjAxMi0wOS0wNiAyMjoxNDozN10gUENJIGFkZCBkZXZpY2UgMDA6MTQu
Mw0KKFhFTikgWzIwMTItMDktMDYgMjI6MTQ6MzddIFBDSSBhZGQgZGV2aWNlIDAwOjE0LjQN
CihYRU4pIFsyMDEyLTA5LTA2IDIyOjE0OjM3XSBQQ0kgYWRkIGRldmljZSAwMDoxNC41DQoo
WEVOKSBbMjAxMi0wOS0wNiAyMjoxNDozN10gUENJIGFkZCBkZXZpY2UgMDA6MTUuMA0KKFhF
TikgWzIwMTItMDktMDYgMjI6MTQ6MzddIFBDSSBhZGQgZGV2aWNlIDAwOjE2LjANCihYRU4p
IFsyMDEyLTA5LTA2IDIyOjE0OjM3XSBQQ0kgYWRkIGRldmljZSAwMDoxNi4yDQooWEVOKSBb
MjAxMi0wOS0wNiAyMjoxNDozN10gUENJIGFkZCBkZXZpY2UgMDA6MTguMA0KKFhFTikgWzIw
MTItMDktMDYgMjI6MTQ6MzddIFBDSSBhZGQgZGV2aWNlIDAwOjE4LjENCihYRU4pIFsyMDEy
LTA5LTA2IDIyOjE0OjM3XSBQQ0kgYWRkIGRldmljZSAwMDoxOC4yDQooWEVOKSBbMjAxMi0w
OS0wNiAyMjoxNDozN10gUENJIGFkZCBkZXZpY2UgMDA6MTguMw0KKFhFTikgWzIwMTItMDkt
MDYgMjI6MTQ6MzddIFBDSSBhZGQgZGV2aWNlIDAwOjE4LjQNCihYRU4pIFsyMDEyLTA5LTA2
IDIyOjE0OjM3XSBQQ0kgYWRkIGRldmljZSAwYjowMC4wDQooWEVOKSBbMjAxMi0wOS0wNiAy
MjoxNDozN10gUENJIGFkZCBkZXZpY2UgMGE6MDAuMA0KKFhFTikgWzIwMTItMDktMDYgMjI6
MTQ6MzddIFBDSSBhZGQgZGV2aWNlIDBhOjAwLjENCihYRU4pIFsyMDEyLTA5LTA2IDIyOjE0
OjM3XSBQQ0kgYWRkIGRldmljZSAwYTowMC4yDQooWEVOKSBbMjAxMi0wOS0wNiAyMjoxNDoz
N10gUENJIGFkZCBkZXZpY2UgMGE6MDAuMw0KKFhFTikgWzIwMTItMDktMDYgMjI6MTQ6Mzdd
IFBDSSBhZGQgZGV2aWNlIDBhOjAwLjQNCihYRU4pIFsyMDEyLTA5LTA2IDIyOjE0OjM3XSBQ
Q0kgYWRkIGRldmljZSAwYTowMC41DQooWEVOKSBbMjAxMi0wOS0wNiAyMjoxNDozN10gUENJ
IGFkZCBkZXZpY2UgMGE6MDAuNg0KKFhFTikgWzIwMTItMDktMDYgMjI6MTQ6MzddIFBDSSBh
ZGQgZGV2aWNlIDBhOjAwLjcNCihYRU4pIFsyMDEyLTA5LTA2IDIyOjE0OjM3XSBQQ0kgYWRk
IGRldmljZSAwOTowMC4wDQooWEVOKSBbMjAxMi0wOS0wNiAyMjoxNDozN10gUENJIGFkZCBk
ZXZpY2UgMDg6MDAuMA0KKFhFTikgWzIwMTItMDktMDYgMjI6MTQ6MzddIFBDSSBhZGQgZGV2
aWNlIDA3OjAwLjANCihYRU4pIFsyMDEyLTA5LTA2IDIyOjE0OjM3XSBQQ0kgYWRkIGRldmlj
ZSAwNjowMC4wDQooWEVOKSBbMjAxMi0wOS0wNiAyMjoxNDozN10gUENJIGFkZCBkZXZpY2Ug
MDY6MDAuMQ0KKFhFTikgWzIwMTItMDktMDYgMjI6MTQ6MzddIFBDSSBhZGQgZGV2aWNlIDA1
OjAwLjANCihYRU4pIFsyMDEyLTA5LTA2IDIyOjE0OjM3XSBQQ0kgYWRkIGRldmljZSAwNDow
MC4wDQooWEVOKSBbMjAxMi0wOS0wNiAyMjoxNDozN10gUENJIGFkZCBkZXZpY2UgMDQ6MDAu
MQ0KKFhFTikgWzIwMTItMDktMDYgMjI6MTQ6MzddIFBDSSBhZGQgZGV2aWNlIDA0OjAwLjIN
CihYRU4pIFsyMDEyLTA5LTA2IDIyOjE0OjM3XSBQQ0kgYWRkIGRldmljZSAwNDowMC4zDQoo
WEVOKSBbMjAxMi0wOS0wNiAyMjoxNDozN10gUENJIGFkZCBkZXZpY2UgMDQ6MDAuNA0KKFhF
TikgWzIwMTItMDktMDYgMjI6MTQ6MzddIFBDSSBhZGQgZGV2aWNlIDA0OjAwLjUNCihYRU4p
IFsyMDEyLTA5LTA2IDIyOjE0OjM3XSBQQ0kgYWRkIGRldmljZSAwNDowMC42DQooWEVOKSBb
MjAxMi0wOS0wNiAyMjoxNDozN10gUENJIGFkZCBkZXZpY2UgMDQ6MDAuNw0KKFhFTikgWzIw
MTItMDktMDYgMjI6MTQ6MzddIFBDSSBhZGQgZGV2aWNlIDAzOjA2LjANCihYRU4pIFsyMDEy
LTA5LTA2IDIyOjE0OjM3XSBJT0FQSUNbMF06IFNldCBQQ0kgcm91dGluZyBlbnRyeSAoNi04
IC0+IDB4NTggLT4gSVJRIDggTW9kZTowIEFjdGl2ZTowKQ0KKFhFTikgWzIwMTItMDktMDYg
MjI6MTQ6MzddIElPQVBJQ1swXTogU2V0IFBDSSByb3V0aW5nIGVudHJ5ICg2LTEzIC0+IDB4
ODggLT4gSVJRIDEzIE1vZGU6MCBBY3RpdmU6MCkNCihYRU4pIFsyMDEyLTA5LTA2IDIyOjE0
OjM3XSBJT0FQSUNbMV06IFNldCBQQ0kgcm91dGluZyBlbnRyeSAoNy0yOCAtPiAweGEwIC0+
IElSUSA1MiBNb2RlOjEgQWN0aXZlOjEpDQooWEVOKSBbMjAxMi0wOS0wNiAyMjoxNDozN10g
SU9BUElDWzFdOiBTZXQgUENJIHJvdXRpbmcgZW50cnkgKDctMjkgLT4gMHhhOCAtPiBJUlEg
NTMgTW9kZToxIEFjdGl2ZToxKQ0KKFhFTikgWzIwMTItMDktMDYgMjI6MTQ6MzddIElPQVBJ
Q1sxXTogU2V0IFBDSSByb3V0aW5nIGVudHJ5ICg3LTMwIC0+IDB4YjAgLT4gSVJRIDU0IE1v
ZGU6MSBBY3RpdmU6MSkNCihYRU4pIFsyMDEyLTA5LTA2IDIyOjE0OjM3XSBJT0FQSUNbMF06
IFNldCBQQ0kgcm91dGluZyBlbnRyeSAoNi0xNiAtPiAweGI4IC0+IElSUSAxNiBNb2RlOjEg
QWN0aXZlOjEpDQooWEVOKSBbMjAxMi0wOS0wNiAyMjoxNDozN10gSU9BUElDWzBdOiBTZXQg
UENJIHJvdXRpbmcgZW50cnkgKDYtMTggLT4gMHhjMCAtPiBJUlEgMTggTW9kZToxIEFjdGl2
ZToxKQ0KKFhFTikgWzIwMTItMDktMDYgMjI6MTQ6MzddIElPQVBJQ1swXTogU2V0IFBDSSBy
b3V0aW5nIGVudHJ5ICg2LTE3IC0+IDB4YzggLT4gSVJRIDE3IE1vZGU6MSBBY3RpdmU6MSkN
CihYRU4pIFsyMDEyLTA5LTA2IDIyOjE0OjM3XSBJT0FQSUNbMV06IFNldCBQQ0kgcm91dGlu
ZyBlbnRyeSAoNy00IC0+IDB4ZDAgLT4gSVJRIDI4IE1vZGU6MSBBY3RpdmU6MSkNCihYRU4p
IFsyMDEyLTA5LTA2IDIyOjE0OjM3XSBJT0FQSUNbMV06IFNldCBQQ0kgcm91dGluZyBlbnRy
eSAoNy01IC0+IDB4ZDggLT4gSVJRIDI5IE1vZGU6MSBBY3RpdmU6MSkNCihYRU4pIFsyMDEy
LTA5LTA2IDIyOjE0OjM3XSBJT0FQSUNbMV06IFNldCBQQ0kgcm91dGluZyBlbnRyeSAoNy02
IC0+IDB4MjEgLT4gSVJRIDMwIE1vZGU6MSBBY3RpdmU6MSkNCihYRU4pIFsyMDEyLTA5LTA2
IDIyOjE0OjM3XSBJT0FQSUNbMV06IFNldCBQQ0kgcm91dGluZyBlbnRyeSAoNy03IC0+IDB4
MjkgLT4gSVJRIDMxIE1vZGU6MSBBY3RpdmU6MSkNCihYRU4pIFsyMDEyLTA5LTA2IDIyOjE0
OjM3XSBJT0FQSUNbMV06IFNldCBQQ0kgcm91dGluZyBlbnRyeSAoNy0xNiAtPiAweDMxIC0+
IElSUSA0MCBNb2RlOjEgQWN0aXZlOjEpDQooWEVOKSBbMjAxMi0wOS0wNiAyMjoxNDozN10g
SU9BUElDWzFdOiBTZXQgUENJIHJvdXRpbmcgZW50cnkgKDctMTcgLT4gMHgzOSAtPiBJUlEg
NDEgTW9kZToxIEFjdGl2ZToxKQ0KKFhFTikgWzIwMTItMDktMDYgMjI6MTQ6MzddIElPQVBJ
Q1sxXTogU2V0IFBDSSByb3V0aW5nIGVudHJ5ICg3LTE4IC0+IDB4NDEgLT4gSVJRIDQyIE1v
ZGU6MSBBY3RpdmU6MSkNCihYRU4pIFsyMDEyLTA5LTA2IDIyOjE0OjM3XSBJT0FQSUNbMV06
IFNldCBQQ0kgcm91dGluZyBlbnRyeSAoNy0xOSAtPiAweDQ5IC0+IElSUSA0MyBNb2RlOjEg
QWN0aXZlOjEpDQooWEVOKSBbMjAxMi0wOS0wNiAyMjoxNDozN10gcGh5c2Rldi5jOjE3MTog
ZG9tMDogd3JvbmcgbWFwX3BpcnEgdHlwZSAzDQooWEVOKSBbMjAxMi0wOS0wNiAyMjoxNDoz
N10gSU9BUElDWzBdOiBTZXQgUENJIHJvdXRpbmcgZW50cnkgKDYtMjIgLT4gMHg5OSAtPiBJ
UlEgMjIgTW9kZToxIEFjdGl2ZToxKQ0KKFhFTikgWzIwMTItMDktMDYgMjI6MTQ6MzddIElP
QVBJQ1sxXTogU2V0IFBDSSByb3V0aW5nIGVudHJ5ICg3LTEyIC0+IDB4YTEgLT4gSVJRIDM2
IE1vZGU6MSBBY3RpdmU6MSkNCihYRU4pIFsyMDEyLTA5LTA2IDIyOjE0OjM3XSBJT0FQSUNb
MV06IFNldCBQQ0kgcm91dGluZyBlbnRyeSAoNy0yMyAtPiAweGE5IC0+IElSUSA0NyBNb2Rl
OjEgQWN0aXZlOjEpDQooWEVOKSBbMjAxMi0wOS0wNiAyMjoxNDozOF0gSU9BUElDWzBdOiBT
ZXQgUENJIHJvdXRpbmcgZW50cnkgKDYtMTkgLT4gMHhiMSAtPiBJUlEgMTkgTW9kZToxIEFj
dGl2ZToxKQ0KKFhFTikgWzIwMTItMDktMDYgMjI6MTQ6MzhdIElPQVBJQ1sxXTogU2V0IFBD
SSByb3V0aW5nIGVudHJ5ICg3LTIyIC0+IDB4YzEgLT4gSVJRIDQ2IE1vZGU6MSBBY3RpdmU6
MSkNCihYRU4pIFsyMDEyLTA5LTA2IDIyOjE0OjM4XSBJT0FQSUNbMV06IFNldCBQQ0kgcm91
dGluZyBlbnRyeSAoNy0yNyAtPiAweGQxIC0+IElSUSA1MSBNb2RlOjEgQWN0aXZlOjEpDQoo
WEVOKSBbMjAxMi0wOS0wNiAyMjoxNDo0MF0gSU9BUElDWzFdOiBTZXQgUENJIHJvdXRpbmcg
ZW50cnkgKDctOSAtPiAweDIyIC0+IElSUSAzMyBNb2RlOjEgQWN0aXZlOjEpDQooWEVOKSBb
MjAxMi0wOS0wNiAyMjoxNTo0NV0gdHJhcHMuYzoyNDg5OmQxIERvbWFpbiBhdHRlbXB0ZWQg
V1JNU1IgMDAwMDAwMDBjMDAxMDAwNCBmcm9tIDB4MDAwMGVkZjAzZGRlNzg0MCB0byAweDAw
MDAwMDAwMDAwMGFiY2QuDQooWEVOKSBbMjAxMi0wOS0wNiAyMjoxNTo1NF0gdHJhcHMuYzoy
NDg5OmQyIERvbWFpbiBhdHRlbXB0ZWQgV1JNU1IgMDAwMDAwMDBjMDAxMDAwNCBmcm9tIDB4
MDAwMDg0N2NjMDM5NDE0MyB0byAweDAwMDAwMDAwMDAwMGFiY2QuDQooWEVOKSBbMjAxMi0w
OS0wNiAyMjoxNjoxNF0gdHJhcHMuYzoyNDg5OmQzIERvbWFpbiBhdHRlbXB0ZWQgV1JNU1Ig
MDAwMDAwMDBjMDAxMDAwNCBmcm9tIDB4MDAwMDIxOTVjNDBmNjM4ZiB0byAweDAwMDAwMDAw
MDAwMGFiY2QuDQooWEVOKSBbMjAxMi0wOS0wNiAyMjoxNjoxNl0gdHJhcHMuYzoyNDg5OmQ0
IERvbWFpbiBhdHRlbXB0ZWQgV1JNU1IgMDAwMDAwMDBjMDAxMDAwNCBmcm9tIDB4MDAwMDg0
N2NjMDM5NDE0MyB0byAweDAwMDAwMDAwMDAwMGFiY2QuDQooWEVOKSBbMjAxMi0wOS0wNiAy
MjoxNjoyNl0gdHJhcHMuYzoyNDg5OmQ1IERvbWFpbiBhdHRlbXB0ZWQgV1JNU1IgMDAwMDAw
MDBjMDAxMDAwNCBmcm9tIDB4MDAwMDIxOTVjNDBmNjM4ZiB0byAweDAwMDAwMDAwMDAwMGFi
Y2QuDQooWEVOKSBbMjAxMi0wOS0wNiAyMjoxNjozNF0gdHJhcHMuYzoyNDg5OmQ2IERvbWFp
biBhdHRlbXB0ZWQgV1JNU1IgMDAwMDAwMDBjMDAxMDAwNCBmcm9tIDB4MDAwMDg0N2NjMDM5
NDE0MyB0byAweDAwMDAwMDAwMDAwMGFiY2QuDQooWEVOKSBbMjAxMi0wOS0wNiAyMjoxNjo1
Ml0gdHJhcHMuYzoyNDg5OmQ3IERvbWFpbiBhdHRlbXB0ZWQgV1JNU1IgMDAwMDAwMDBjMDAx
MDAwNCBmcm9tIDB4MDAwMDIxOTVjNDBmNjM4ZiB0byAweDAwMDAwMDAwMDAwMGFiY2QuDQoo
WEVOKSBbMjAxMi0wOS0wNiAyMjoxNzowOF0gdHJhcHMuYzoyNDg5OmQ4IERvbWFpbiBhdHRl
bXB0ZWQgV1JNU1IgMDAwMDAwMDBjMDAxMDAwNCBmcm9tIDB4MDAwMDQwYjQ1MzBkYTE2NSB0
byAweDAwMDAwMDAwMDAwMGFiY2QuDQooWEVOKSBbMjAxMi0wOS0wNiAyMjoxNzoxOV0gdHJh
cHMuYzoyNDg5OmQ5IERvbWFpbiBhdHRlbXB0ZWQgV1JNU1IgMDAwMDAwMDBjMDAxMDAwNCBm
cm9tIDB4MDAwMDg0N2NjMDM5NDE0MyB0byAweDAwMDAwMDAwMDAwMGFiY2QuDQooWEVOKSBb
MjAxMi0wOS0wNiAyMjoxNzozM10gdHJhcHMuYzoyNDg5OmQxMCBEb21haW4gYXR0ZW1wdGVk
IFdSTVNSIDAwMDAwMDAwYzAwMTAwMDQgZnJvbSAweDAwMDBlZGYwM2RkZTc4NDAgdG8gMHgw
MDAwMDAwMDAwMDBhYmNkLg0KKFhFTikgWzIwMTItMDktMDYgMjI6MTc6NDJdIEFNRC1WaTog
RGlzYWJsZTogZGV2aWNlIGlkID0gMHgwMGE0LCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9
IDMNCihYRU4pIFsyMDEyLTA5LTA2IDIyOjE3OjQyXSBBTUQtVmk6IFNldHVwIEkvTyBwYWdl
IHRhYmxlOiBkZXZpY2UgaWQgPSAweDAwYTQsIHJvb3QgdGFibGUgPSAweDE4Y2U0ZjAwMCwg
ZG9tYWluID0gMTEsIHBhZ2luZyBtb2RlID0gMw0KKFhFTikgWzIwMTItMDktMDYgMjI6MTc6
NDJdIEFNRC1WaTogUmUtYXNzaWduIDAzOjA2LjAgZnJvbSBkb21haW4gMCB0byBkb21haW4g
MTENCihYRU4pIFsyMDEyLTA5LTA2IDIyOjE3OjQ0XSB0cmFwcy5jOjI0ODk6ZDExIERvbWFp
biBhdHRlbXB0ZWQgV1JNU1IgMDAwMDAwMDBjMDAxMDAwNCBmcm9tIDB4MDAwMDIxOTVjNDBm
NjM4ZiB0byAweDAwMDAwMDAwMDAwMGFiY2QuDQooWEVOKSBbMjAxMi0wOS0wNiAyMjoxODoz
M10gdHJhcHMuYzoyNDg5OmQxMiBEb21haW4gYXR0ZW1wdGVkIFdSTVNSIDAwMDAwMDAwYzAw
MTAwMDQgZnJvbSAweDAwMDAyMTk1YzQwZjYzOGYgdG8gMHgwMDAwMDAwMDAwMDBhYmNkLg0K
KFhFTikgWzIwMTItMDktMDYgMjI6MTg6NDNdIHRyYXBzLmM6MjQ4OTpkMTMgRG9tYWluIGF0
dGVtcHRlZCBXUk1TUiAwMDAwMDAwMGMwMDEwMDA0IGZyb20gMHgwMDAwNDBiNDUzMGRhMTY1
IHRvIDB4MDAwMDAwMDAwMDAwYWJjZC4NCihYRU4pIFsyMDEyLTA5LTA2IDIyOjE5OjI5XSBB
TUQtVmk6IERpc2FibGU6IGRldmljZSBpZCA9IDB4MGEwMCwgZG9tYWluID0gMCwgcGFnaW5n
IG1vZGUgPSAzDQooWEVOKSBbMjAxMi0wOS0wNiAyMjoxOToyOV0gQU1ELVZpOiBTZXR1cCBJ
L08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHgwYTAwLCByb290IHRhYmxlID0gMHgxZTBk
ODMwMDAsIGRvbWFpbiA9IDE0LCBwYWdpbmcgbW9kZSA9IDMNCihYRU4pIFsyMDEyLTA5LTA2
IDIyOjE5OjI5XSBBTUQtVmk6IFJlLWFzc2lnbiAwYTowMC4wIGZyb20gZG9tYWluIDAgdG8g
ZG9tYWluIDE0DQooWEVOKSBbMjAxMi0wOS0wNiAyMjoxOToyOV0gQU1ELVZpOiBEaXNhYmxl
OiBkZXZpY2UgaWQgPSAweDBhMDEsIGRvbWFpbiA9IDAsIHBhZ2luZyBtb2RlID0gMw0KKFhF
TikgWzIwMTItMDktMDYgMjI6MTk6MjldIEFNRC1WaTogU2V0dXAgSS9PIHBhZ2UgdGFibGU6
IGRldmljZSBpZCA9IDB4MGEwMSwgcm9vdCB0YWJsZSA9IDB4MWUwZDgzMDAwLCBkb21haW4g
PSAxNCwgcGFnaW5nIG1vZGUgPSAzDQooWEVOKSBbMjAxMi0wOS0wNiAyMjoxOToyOV0gQU1E
LVZpOiBSZS1hc3NpZ24gMGE6MDAuMSBmcm9tIGRvbWFpbiAwIHRvIGRvbWFpbiAxNA0KKFhF
TikgWzIwMTItMDktMDYgMjI6MTk6MjldIEFNRC1WaTogRGlzYWJsZTogZGV2aWNlIGlkID0g
MHgwYTAyLCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMNCihYRU4pIFsyMDEyLTA5LTA2
IDIyOjE5OjI5XSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAw
eDBhMDIsIHJvb3QgdGFibGUgPSAweDFlMGQ4MzAwMCwgZG9tYWluID0gMTQsIHBhZ2luZyBt
b2RlID0gMw0KKFhFTikgWzIwMTItMDktMDYgMjI6MTk6MjldIEFNRC1WaTogUmUtYXNzaWdu
IDBhOjAwLjIgZnJvbSBkb21haW4gMCB0byBkb21haW4gMTQNCihYRU4pIFsyMDEyLTA5LTA2
IDIyOjE5OjI5XSBBTUQtVmk6IERpc2FibGU6IGRldmljZSBpZCA9IDB4MGEwMywgZG9tYWlu
ID0gMCwgcGFnaW5nIG1vZGUgPSAzDQooWEVOKSBbMjAxMi0wOS0wNiAyMjoxOToyOV0gQU1E
LVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHgwYTAzLCByb290IHRh
YmxlID0gMHgxZTBkODMwMDAsIGRvbWFpbiA9IDE0LCBwYWdpbmcgbW9kZSA9IDMNCihYRU4p
IFsyMDEyLTA5LTA2IDIyOjE5OjI5XSBBTUQtVmk6IFJlLWFzc2lnbiAwYTowMC4zIGZyb20g
ZG9tYWluIDAgdG8gZG9tYWluIDE0DQooWEVOKSBbMjAxMi0wOS0wNiAyMjoxOToyOV0gQU1E
LVZpOiBEaXNhYmxlOiBkZXZpY2UgaWQgPSAweDBhMDQsIGRvbWFpbiA9IDAsIHBhZ2luZyBt
b2RlID0gMw0KKFhFTikgWzIwMTItMDktMDYgMjI6MTk6MjldIEFNRC1WaTogU2V0dXAgSS9P
IHBhZ2UgdGFibGU6IGRldmljZSBpZCA9IDB4MGEwNCwgcm9vdCB0YWJsZSA9IDB4MWUwZDgz
MDAwLCBkb21haW4gPSAxNCwgcGFnaW5nIG1vZGUgPSAzDQooWEVOKSBbMjAxMi0wOS0wNiAy
MjoxOToyOV0gQU1ELVZpOiBSZS1hc3NpZ24gMGE6MDAuNCBmcm9tIGRvbWFpbiAwIHRvIGRv
bWFpbiAxNA0KKFhFTikgWzIwMTItMDktMDYgMjI6MTk6MjldIEFNRC1WaTogRGlzYWJsZTog
ZGV2aWNlIGlkID0gMHgwYTA1LCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMNCihYRU4p
IFsyMDEyLTA5LTA2IDIyOjE5OjI5XSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBk
ZXZpY2UgaWQgPSAweDBhMDUsIHJvb3QgdGFibGUgPSAweDFlMGQ4MzAwMCwgZG9tYWluID0g
MTQsIHBhZ2luZyBtb2RlID0gMw0KKFhFTikgWzIwMTItMDktMDYgMjI6MTk6MjldIEFNRC1W
aTogUmUtYXNzaWduIDBhOjAwLjUgZnJvbSBkb21haW4gMCB0byBkb21haW4gMTQNCihYRU4p
IFsyMDEyLTA5LTA2IDIyOjE5OjI5XSBBTUQtVmk6IERpc2FibGU6IGRldmljZSBpZCA9IDB4
MGEwNiwgZG9tYWluID0gMCwgcGFnaW5nIG1vZGUgPSAzDQooWEVOKSBbMjAxMi0wOS0wNiAy
MjoxOToyOV0gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHgw
YTA2LCByb290IHRhYmxlID0gMHgxZTBkODMwMDAsIGRvbWFpbiA9IDE0LCBwYWdpbmcgbW9k
ZSA9IDMNCihYRU4pIFsyMDEyLTA5LTA2IDIyOjE5OjI5XSBBTUQtVmk6IFJlLWFzc2lnbiAw
YTowMC42IGZyb20gZG9tYWluIDAgdG8gZG9tYWluIDE0DQooWEVOKSBbMjAxMi0wOS0wNiAy
MjoxOToyOV0gQU1ELVZpOiBEaXNhYmxlOiBkZXZpY2UgaWQgPSAweDBhMDcsIGRvbWFpbiA9
IDAsIHBhZ2luZyBtb2RlID0gMw0KKFhFTikgWzIwMTItMDktMDYgMjI6MTk6MjldIEFNRC1W
aTogU2V0dXAgSS9PIHBhZ2UgdGFibGU6IGRldmljZSBpZCA9IDB4MGEwNywgcm9vdCB0YWJs
ZSA9IDB4MWUwZDgzMDAwLCBkb21haW4gPSAxNCwgcGFnaW5nIG1vZGUgPSAzDQooWEVOKSBb
MjAxMi0wOS0wNiAyMjoxOToyOV0gQU1ELVZpOiBSZS1hc3NpZ24gMGE6MDAuNyBmcm9tIGRv
bWFpbiAwIHRvIGRvbWFpbiAxNA0KKFhFTikgWzIwMTItMDktMDYgMjI6MTk6MzBdIEFNRC1W
aTogRGlzYWJsZTogZGV2aWNlIGlkID0gMHgwNzAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9k
ZSA9IDMNCihYRU4pIFsyMDEyLTA5LTA2IDIyOjE5OjMwXSBBTUQtVmk6IFNldHVwIEkvTyBw
YWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweDA3MDAsIHJvb3QgdGFibGUgPSAweDFlMGQ4MzAw
MCwgZG9tYWluID0gMTQsIHBhZ2luZyBtb2RlID0gMw0KKFhFTikgWzIwMTItMDktMDYgMjI6
MTk6MzBdIEFNRC1WaTogUmUtYXNzaWduIDA3OjAwLjAgZnJvbSBkb21haW4gMCB0byBkb21h
aW4gMTQNCihYRU4pIFsyMDEyLTA5LTA2IDIyOjE5OjQ0XSB0cmFwcy5jOjI0ODk6ZDE0IERv
bWFpbiBhdHRlbXB0ZWQgV1JNU1IgMDAwMDAwMDBjMDAxMDAwNCBmcm9tIDB4MDAwMDc4NzEx
MGZkMGU4ZiB0byAweDAwMDAwMDAwMDAwMGFiY2QuDQo=
------------0E902503E1C6BF83E
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

------------0E902503E1C6BF83E--



From xen-devel-bounces@lists.xen.org Fri Sep 07 07:33:34 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Sep 2012 07:33: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 1T9t3p-0001R7-2V; Fri, 07 Sep 2012 07:33:05 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <linux@eikelenboom.it>) id 1T9t3l-0001Pz-Jf
	for xen-devel@lists.xensource.com; Fri, 07 Sep 2012 07:33:02 +0000
Received: from [85.158.139.83:50102] by server-10.bemta-5.messagelabs.com id
	4D/A5-10969-C23A9405; Fri, 07 Sep 2012 07:33:00 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-3.tower-182.messagelabs.com!1347003168!29082166!1
X-Originating-IP: [188.40.164.121]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27257 invoked from network); 7 Sep 2012 07:32:49 -0000
Received: from static.121.164.40.188.clients.your-server.de (HELO
	smtp.eikelenboom.it) (188.40.164.121)
	by server-3.tower-182.messagelabs.com with AES256-SHA encrypted SMTP;
	7 Sep 2012 07:32:49 -0000
Received: from 128-64-ftth.onsneteindhoven.nl ([88.159.64.128]:49366
	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 1T9t3a-0007O3-Jl; Fri, 07 Sep 2012 09:32:51 +0200
Date: Fri, 7 Sep 2012 09:32:41 +0200
From: Sander Eikelenboom <linux@eikelenboom.it>
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <488803362.20120907093241@eikelenboom.it>
To: Wei Wang <wei.wang2@amd.com>
In-Reply-To: <5048BB29.4040900@amd.com>
References: <504764E2.4000809@amd.com>
	<326589347.20120906005936@eikelenboom.it>
	<5048A603.3070207@amd.com>
	<483486315.20120906155001@eikelenboom.it>
	<5048BB29.4040900@amd.com>
MIME-Version: 1.0
Content-Type: multipart/mixed;
 boundary="----------0E902503E1C6BF83E"
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH] amd iommu: Dump flags of IO page faults
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

------------0E902503E1C6BF83E
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit


Thursday, September 6, 2012, 5:03:05 PM, you wrote:

> On 09/06/2012 03:50 PM, Sander Eikelenboom wrote:
>>
>> Thursday, September 6, 2012, 3:32:51 PM, you wrote:
>>
>>> On 09/06/2012 12:59 AM, Sander Eikelenboom wrote:
>>>>
>>>> Wednesday, September 5, 2012, 4:42:42 PM, you wrote:
>>>>
>>>>> Hi Jan,
>>>>> Attached patch dumps io page fault flags. The flags show the reason of
>>>>> the fault and tell us if this is an unmapped interrupt fault or a DMA fault.
>>>>
>>>>> Thanks,
>>>>> Wei
>>>>
>>>>> signed-off-by: Wei Wang<wei.wang2@amd.com>
>>>>
>>>>
>>>> I have applied the patch and the flags seem to differ between the faults:
>>>>
>>>> AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0a06, fault address = 0xc2c2c2c0, flags = 0x000
>>>> (XEN) [2012-09-05 20:54:16] AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0a06, fault address = 0xc2c2c2c0, flags = 0x000
>>>> (XEN) [2012-09-05 20:54:16] AMD-Vi: IO_PAGE_FAULT: domain = 14, device id = 0x0700, fault address = 0xa8d339e0, flags = 0x020
>>>> (XEN) [2012-09-05 20:54:16] AMD-Vi: IO_PAGE_FAULT: domain = 14, device id = 0x0700, fault address = 0xa8d33a40, flags = 0x020
>>
>>> OK, so they are not interrupt requests. I guess further information from
>>> your system would be helpful to debug this issue:
>>> 1) xl info
>>> 2) xl list
>>> 3) lscpi -vvv (NOTE: not in dom0 but in your guest)
>>> 4) cat /proc/iomem (in both dom0 and your hvm guest)
>>
>> dom14 is not a HVM guest,it's a PV guest.

> Ah, I see. PV guest is quite different than hvm, it does use p2m tables 
> as io page tables. So no-sharept option does not work in this case. PV 
> guests always use separated io page tables. There might be some 
> incorrect mappings on the page tables. I will check this on my side.

I have reverted the machine to xen-4.1.4-pre (changeset 23353) and kept everything else the same.
I haven't seen any IO PAGE FAULTS after that.

I did spot some differences in the output from lspci between xen 4.1 and 4.2, related to MSI enabled or not for the IOMMU device.
Have attached the xl/xm dmesg and lspci from booting with both versions.

lspci:

00:00.2 Generic system peripheral [0806]: ATI Technologies Inc RD990 I/O Memory Management Unit (IOMMU) [1002:5a23]
        Subsystem: ATI Technologies Inc RD990 I/O Memory Management Unit (IOMMU) [1002:5a23]
        Control: I/O- Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
        Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
        Latency: 0
        Interrupt: pin A routed to IRQ 10
        Capabilities: [40] Secure device <?>
4.1:    Capabilities: [54] MSI: Enable- Count=1/1 Maskable- 64bit+
4.2:    Capabilities: [54] MSI: Enable+ Count=1/1 Maskable- 64bit+
                Address: 00000000fee0100c  Data: 4128
        Capabilities: [64] HyperTransport: MSI Mapping Enable+ Fixed+

Although it seems enabled, shouldn't the IRQ number used be much higher than 10 for MSI interrupts ?

There is another difference in the bridge device that's in front of the  0a:00.6 device that faults before the kernel is even booted.

00:03.0 PCI bridge [0604]: ATI Technologies Inc RD890 PCI to PCI bridge (PCI express gpp port C) [1002:5a17] (prog-if 00 [Normal decode])
        Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx+
4.1:    Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
4.2:    Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort+ <MAbort- >SERR- <PERR- INTx-
        Latency: 0, Cache Line Size: 64 bytes
        Bus: primary=00, secondary=0a, subordinate=0a, sec-latency=0
        I/O behind bridge: 0000f000-00000fff
        Memory behind bridge: f9f00000-f9ffffff
        Prefetchable memory behind bridge: 00000000fff00000-00000000000fffff
4.1:    Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- <SERR- <PERR-
4.2:    Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort+ <TAbort- <MAbort- <SERR- <PERR-
        BridgeCtl: Parity+ SERR+ NoISA+ VGA- MAbort- >Reset- FastB2B-
                PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
        Capabilities: [50] Power Management version 3
                Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
                Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
        Capabilities: [58] Express (v2) Root Port (Slot+), MSI 00
                DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s <64ns, L1 <1us
                        ExtTag+ RBE+ FLReset-
                DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
                        RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+
                        MaxPayload 128 bytes, MaxReadReq 128 bytes
                DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr- TransPend-
                LnkCap: Port #1, Speed 5GT/s, Width x8, ASPM L0s L1, Latency L0 <1us, L1 <8us
                        ClockPM- Surprise- LLActRep+ BwNot+
                LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommClk-
                        ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
                LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive+ BWMgmt+ ABWMgmt-
                SltCap: AttnBtn- PwrCtrl- MRL- AttnInd- PwrInd- HotPlug- Surprise-
                        Slot #3, PowerLimit 10.000W; Interlock- NoCompl+
                SltCtl: Enable: AttnBtn- PwrFlt- MRL- PresDet- CmdCplt- HPIrq- LinkChg-
                        Control: AttnInd Unknown, PwrInd Unknown, Power- Interlock-
                SltSta: Status: AttnBtn- PowerFlt- MRL- CmdCplt- PresDet+ Interlock-
                        Changed: MRL- PresDet+ LinkState+

serveerstertje:~# lspci -t
-[0000:00]-+-00.0
           +-00.2
           +-02.0-[0b]----00.0
           +-03.0-[0a]--+-00.0
           |            +-00.1
           |            +-00.2
           |            +-00.3
           |            +-00.4
           |            +-00.5
           |            +-00.6
           |            \-00.7
           +-05.0-[09]----00.0
           +-06.0-[08]----00.0
           +-0a.0-[07]----00.0
           +-0b.0-[06]--+-00.0
           |            \-00.1
           +-0c.0-[05]----00.0
           +-0d.0-[04]--+-00.0
           |            +-00.1
           |            +-00.2
           |            +-00.3
           |            +-00.4
           |            +-00.5
           |            +-00.6
           |            \-00.7
           +-11.0
           +-12.0
           +-12.2
           +-13.0
           +-13.2
           +-14.0
           +-14.3
           +-14.4-[03]----06.0
           +-14.5
           +-15.0-[02]--
           +-16.0
           +-16.2
           +-18.0
           +-18.1
           +-18.2
           +-18.3
           \-18.4





> Thanks,
> Wei

>> I will try to make a complete package, and try with one pv domain only where the devices are being passed through just to simplify the setup.
>>
>>
>>> * I would also like to know the symptoms of device 0x0700 when IO_PF
>>> happened. Did it stop working?
>>
>> Yes it stops working, the video capture just freezes, but the driver doesn't bail out.
>> For the USB controller (0x0a06) it starts to give errors for usbdev_open in the guest.
>>
>>> (BTW: I copied a few options from your boot cmd line and it worked with
>>> my RD890 system
>>
>>> dom0_mem=1024M,max:1024M loglvl=all loglvl_guest=all console_timestamps
>>> cpuidle cpufreq=xen noreboot debug lapic=debug apic_verbosity=debug
>>> apic=debug iommu=on,verbose,debug,no-sharept
>>
>>> * so, what OEM board you have?)
>>
>> MSI 890FXA-GD70
>>
>>> Also from your log, these lines looks very strange:
>>
>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>>> read-only memory page. gfn=0xd5, mfn=0xa4a11
>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>>> read-only memory page. gfn=0xd7, mfn=0xa4a0f
>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>>> read-only memory page. gfn=0xd9, mfn=0xa4a0d
>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>>> read-only memory page. gfn=0xdb, mfn=0xa4a0b
>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>>> read-only memory page. gfn=0xdd, mfn=0xa4a09
>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>>> read-only memory page. gfn=0xdf, mfn=0xa4a07
>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>>> read-only memory page. gfn=0xe1, mfn=0xa4a05
>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>>> read-only memory page. gfn=0xe3, mfn=0xa4a03
>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>>> read-only memory page. gfn=0xe5, mfn=0xa4a01
>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>>> read-only memory page. gfn=0xe7, mfn=0xa463f
>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>>> read-only memory page. gfn=0xe9, mfn=0xa463d
>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>>> read-only memory page. gfn=0xeb, mfn=0xa463b
>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>>> read-only memory page. gfn=0xed, mfn=0xa4639
>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>>> read-only memory page. gfn=0xef, mfn=0xa4637
>>> (XEN) [2012-09-04 16:13:56] AMD-Vi: IO_PAGE_FAULT: domain = 0, device id
>>> = 0x0a06, fault address = 0xc2c2c2c0
>>> (XEN) [2012-09-04 16:13:56] AMD-Vi: IO_PAGE_FAULT: domain = 14, device
>>> id = 0x0700, fault address = 0xa90f8300
>>> (XEN) [2012-09-04 16:13:56] AMD-Vi: IO_PAGE_FAULT: domain = 14, device
>>> id = 0x0700, fault address = 0xa90f8340
>>> (XEN) [2012-09-04 16:13:56] AMD-Vi: IO_PAGE_FAULT: domain = 14, device
>>> id = 0x0700, fault address = 0xa90f8380
>>> (XEN) [2012-09-04 16:13:56] AMD-Vi: IO_PAGE_FAULT: domain = 14, device
>>> id = 0x0700, fault address = 0xa90f83c0
>>
>>> * they are just followed by the IO PAGE fault. Do you know where are
>>> they from? Your video card driver maybe?
>>
>>  From a HVM domain with a old (3.0.3) kernel, but the faults also occur without this domain being started.
>>
>>
>>> Thanks,
>>> Wei
>>
>>
>>>> Complete xl dmesg and lspci -vvvknn attached.
>>>>
>>>> Thx
>>>>
>>>> --
>>>> Sander
>>
>>
>>
>>
>>



------------0E902503E1C6BF83E
Content-Type: text/plain;
 name="lspci-4.1.txt"
Content-transfer-encoding: base64
Content-Disposition: attachment;
 filename="lspci-4.1.txt"

MDA6MDAuMCBIb3N0IGJyaWRnZSBbMDYwMF06IEFUSSBUZWNobm9sb2dpZXMgSW5jIFJEODkw
IE5vcnRoYnJpZGdlIG9ubHkgc2luZ2xlIHNsb3QgUENJLWUgR0ZYIEh5ZHJhIHBhcnQgWzEw
MDI6NWExMV0gKHJldiAwMikNCglTdWJzeXN0ZW06IEFUSSBUZWNobm9sb2dpZXMgSW5jIFJE
ODkwIE5vcnRoYnJpZGdlIG9ubHkgc2luZ2xlIHNsb3QgUENJLWUgR0ZYIEh5ZHJhIHBhcnQg
WzEwMDI6NWExMV0NCglDb250cm9sOiBJL08tIE1lbSsgQnVzTWFzdGVyLSBTcGVjQ3ljbGUt
IE1lbVdJTlYtIFZHQVNub29wLSBQYXJFcnItIFN0ZXBwaW5nLSBTRVJSLSBGYXN0QjJCLSBE
aXNJTlR4LQ0KCVN0YXR1czogQ2FwKyA2Nk1Iei0gVURGLSBGYXN0QjJCLSBQYXJFcnItIERF
VlNFTD1mYXN0ID5UQWJvcnQtIDxUQWJvcnQtIDxNQWJvcnQrID5TRVJSLSA8UEVSUi0gSU5U
eC0NCglDYXBhYmlsaXRpZXM6IFtmMF0gSHlwZXJUcmFuc3BvcnQ6IE1TSSBNYXBwaW5nIEVu
YWJsZSsgRml4ZWQrDQoJQ2FwYWJpbGl0aWVzOiBbYzRdIEh5cGVyVHJhbnNwb3J0OiBTbGF2
ZSBvciBQcmltYXJ5IEludGVyZmFjZQ0KCQlDb21tYW5kOiBCYXNlVW5pdElEPTAgVW5pdENu
dD0yMCBNYXN0SG9zdC0gRGVmRGlyLSBEVUwtDQoJCUxpbmsgQ29udHJvbCAwOiBDRmxFLSBD
U1QtIENGRS0gPExrRmFpbC0gSW5pdCsgRU9DLSBUWE8tIDxDUkNFcnI9MCBJc29jRW4tIExT
RW4tIEV4dENUTC0gNjRiLQ0KCQlMaW5rIENvbmZpZyAwOiBNTFdJPTE2Yml0IER3RmNJbi0g
TUxXTz0xNmJpdCBEd0ZjT3V0LSBMV0k9MTZiaXQgRHdGY0luRW4tIExXTz0xNmJpdCBEd0Zj
T3V0RW4tDQoJCUxpbmsgQ29udHJvbCAxOiBDRmxFLSBDU1QtIENGRS0gPExrRmFpbCsgSW5p
dC0gRU9DKyBUWE8rIDxDUkNFcnI9MCBJc29jRW4tIExTRW4tIEV4dENUTC0gNjRiLQ0KCQlM
aW5rIENvbmZpZyAxOiBNTFdJPThiaXQgRHdGY0luLSBNTFdPPThiaXQgRHdGY091dC0gTFdJ
PThiaXQgRHdGY0luRW4tIExXTz04Yml0IER3RmNPdXRFbi0NCgkJUmV2aXNpb24gSUQ6IDMu
MDANCgkJTGluayBGcmVxdWVuY3kgMDogW2JdDQoJCUxpbmsgRXJyb3IgMDogPFByb3QtIDxP
dmZsLSA8RU9DLSBDVExUbS0NCgkJTGluayBGcmVxdWVuY3kgQ2FwYWJpbGl0eSAwOiAyMDBN
SHorIDMwME1Iei0gNDAwTUh6KyA1MDBNSHotIDYwME1IeisgODAwTUh6KyAxLjBHSHorIDEu
MkdIeisgMS40R0h6LSAxLjZHSHotIFZlbmQtDQoJCUZlYXR1cmUgQ2FwYWJpbGl0eTogSXNv
Y0ZDKyBMRFRTVE9QKyBDUkNUTS0gRUNUTFQtIDY0YkErIFVJRFJELQ0KCQlMaW5rIEZyZXF1
ZW5jeSAxOiAyMDBNSHoNCgkJTGluayBFcnJvciAxOiA8UHJvdC0gPE92ZmwtIDxFT0MtIENU
TFRtLQ0KCQlMaW5rIEZyZXF1ZW5jeSBDYXBhYmlsaXR5IDE6IDIwME1Iei0gMzAwTUh6LSA0
MDBNSHotIDUwME1Iei0gNjAwTUh6LSA4MDBNSHotIDEuMEdIei0gMS4yR0h6LSAxLjRHSHot
IDEuNkdIei0gVmVuZC0NCgkJRXJyb3IgSGFuZGxpbmc6IFBGbEUtIE9GbEUtIFBGRS0gT0ZF
LSBFT0NGRS0gUkZFLSBDUkNGRS0gU0VSUkZFLSBDRi0gUkUtIFBORkUtIE9ORkUtIEVPQ05G
RS0gUk5GRS0gQ1JDTkZFLSBTRVJSTkZFLQ0KCQlQcmVmZXRjaGFibGUgbWVtb3J5IGJlaGlu
ZCBicmlkZ2UgVXBwZXI6IDAwLTAwDQoJCUJ1cyBOdW1iZXI6IDAwDQoJQ2FwYWJpbGl0aWVz
OiBbNDBdIEh5cGVyVHJhbnNwb3J0OiBSZXRyeSBNb2RlDQoJQ2FwYWJpbGl0aWVzOiBbNTRd
IEh5cGVyVHJhbnNwb3J0OiBVbml0SUQgQ2x1bXBpbmcNCglDYXBhYmlsaXRpZXM6IFs5Y10g
SHlwZXJUcmFuc3BvcnQ6ICMxYQ0KCUNhcGFiaWxpdGllczogWzcwXSBNU0k6IEVuYWJsZS0g
Q291bnQ9MS80IE1hc2thYmxlLSA2NGJpdC0NCgkJQWRkcmVzczogMDAwMDAwMDAgIERhdGE6
IDAwMDANCg0KMDA6MDAuMiBHZW5lcmljIHN5c3RlbSBwZXJpcGhlcmFsIFswODA2XTogQVRJ
IFRlY2hub2xvZ2llcyBJbmMgUkQ5OTAgSS9PIE1lbW9yeSBNYW5hZ2VtZW50IFVuaXQgKElP
TU1VKSBbMTAwMjo1YTIzXQ0KCVN1YnN5c3RlbTogQVRJIFRlY2hub2xvZ2llcyBJbmMgUkQ5
OTAgSS9PIE1lbW9yeSBNYW5hZ2VtZW50IFVuaXQgKElPTU1VKSBbMTAwMjo1YTIzXQ0KCUNv
bnRyb2w6IEkvTy0gTWVtLSBCdXNNYXN0ZXIrIFNwZWNDeWNsZS0gTWVtV0lOVi0gVkdBU25v
b3AtIFBhckVyci0gU3RlcHBpbmctIFNFUlItIEZhc3RCMkItIERpc0lOVHgtDQoJU3RhdHVz
OiBDYXArIDY2TUh6LSBVREYtIEZhc3RCMkItIFBhckVyci0gREVWU0VMPWZhc3QgPlRBYm9y
dC0gPFRBYm9ydC0gPE1BYm9ydC0gPlNFUlItIDxQRVJSLSBJTlR4LQ0KCUxhdGVuY3k6IDAN
CglJbnRlcnJ1cHQ6IHBpbiBBIHJvdXRlZCB0byBJUlEgMTANCglDYXBhYmlsaXRpZXM6IFs0
MF0gU2VjdXJlIGRldmljZSA8Pz4NCglDYXBhYmlsaXRpZXM6IFs1NF0gTVNJOiBFbmFibGUt
IENvdW50PTEvMSBNYXNrYWJsZS0gNjRiaXQrDQoJCUFkZHJlc3M6IDAwMDAwMDAwZmVlMDEw
MGMgIERhdGE6IDQxMjgNCglDYXBhYmlsaXRpZXM6IFs2NF0gSHlwZXJUcmFuc3BvcnQ6IE1T
SSBNYXBwaW5nIEVuYWJsZSsgRml4ZWQrDQoNCjAwOjAyLjAgUENJIGJyaWRnZSBbMDYwNF06
IEFUSSBUZWNobm9sb2dpZXMgSW5jIFJEODkwIFBDSSB0byBQQ0kgYnJpZGdlIChQQ0kgZXhw
cmVzcyBncHAgcG9ydCBCKSBbMTAwMjo1YTE2XSAocHJvZy1pZiAwMCBbTm9ybWFsIGRlY29k
ZV0pDQoJQ29udHJvbDogSS9PKyBNZW0rIEJ1c01hc3RlcisgU3BlY0N5Y2xlLSBNZW1XSU5W
LSBWR0FTbm9vcC0gUGFyRXJyLSBTdGVwcGluZy0gU0VSUisgRmFzdEIyQi0gRGlzSU5UeCsN
CglTdGF0dXM6IENhcCsgNjZNSHotIFVERi0gRmFzdEIyQi0gUGFyRXJyLSBERVZTRUw9ZmFz
dCA+VEFib3J0LSA8VEFib3J0LSA8TUFib3J0LSA+U0VSUi0gPFBFUlItIElOVHgtDQoJTGF0
ZW5jeTogMCwgQ2FjaGUgTGluZSBTaXplOiA2NCBieXRlcw0KCUJ1czogcHJpbWFyeT0wMCwg
c2Vjb25kYXJ5PTBiLCBzdWJvcmRpbmF0ZT0wYiwgc2VjLWxhdGVuY3k9MA0KCUkvTyBiZWhp
bmQgYnJpZGdlOiAwMDAwZTAwMC0wMDAwZWZmZg0KCU1lbW9yeSBiZWhpbmQgYnJpZGdlOiBm
YTAwMDAwMC1mZTlmZmZmZg0KCVByZWZldGNoYWJsZSBtZW1vcnkgYmVoaW5kIGJyaWRnZTog
MDAwMDAwMDBkMDAwMDAwMC0wMDAwMDAwMGRmZmZmZmZmDQoJU2Vjb25kYXJ5IHN0YXR1czog
NjZNSHotIEZhc3RCMkItIFBhckVyci0gREVWU0VMPWZhc3QgPlRBYm9ydC0gPFRBYm9ydC0g
PE1BYm9ydC0gPFNFUlItIDxQRVJSLQ0KCUJyaWRnZUN0bDogUGFyaXR5KyBTRVJSKyBOb0lT
QS0gVkdBKyBNQWJvcnQtID5SZXNldC0gRmFzdEIyQi0NCgkJUHJpRGlzY1Rtci0gU2VjRGlz
Y1Rtci0gRGlzY1RtclN0YXQtIERpc2NUbXJTRVJSRW4tDQoJQ2FwYWJpbGl0aWVzOiBbNTBd
IFBvd2VyIE1hbmFnZW1lbnQgdmVyc2lvbiAzDQoJCUZsYWdzOiBQTUVDbGstIERTSS0gRDEt
IEQyLSBBdXhDdXJyZW50PTBtQSBQTUUoRDArLEQxLSxEMi0sRDNob3QrLEQzY29sZCspDQoJ
CVN0YXR1czogRDAgTm9Tb2Z0UnN0LSBQTUUtRW5hYmxlLSBEU2VsPTAgRFNjYWxlPTAgUE1F
LQ0KCUNhcGFiaWxpdGllczogWzU4XSBFeHByZXNzICh2MikgUm9vdCBQb3J0IChTbG90Kyks
IE1TSSAwMA0KCQlEZXZDYXA6CU1heFBheWxvYWQgMTI4IGJ5dGVzLCBQaGFudEZ1bmMgMCwg
TGF0ZW5jeSBMMHMgPDY0bnMsIEwxIDwxdXMNCgkJCUV4dFRhZysgUkJFKyBGTFJlc2V0LQ0K
CQlEZXZDdGw6CVJlcG9ydCBlcnJvcnM6IENvcnJlY3RhYmxlLSBOb24tRmF0YWwtIEZhdGFs
LSBVbnN1cHBvcnRlZC0NCgkJCVJseGRPcmQrIEV4dFRhZy0gUGhhbnRGdW5jLSBBdXhQd3It
IE5vU25vb3ArDQoJCQlNYXhQYXlsb2FkIDEyOCBieXRlcywgTWF4UmVhZFJlcSAxMjggYnl0
ZXMNCgkJRGV2U3RhOglDb3JyRXJyLSBVbmNvcnJFcnItIEZhdGFsRXJyLSBVbnN1cHBSZXEt
IEF1eFB3ci0gVHJhbnNQZW5kLQ0KCQlMbmtDYXA6CVBvcnQgIzAsIFNwZWVkIDVHVC9zLCBX
aWR0aCB4OCwgQVNQTSBMMHMgTDEsIExhdGVuY3kgTDAgPDF1cywgTDEgPDh1cw0KCQkJQ2xv
Y2tQTS0gU3VycHJpc2UtIExMQWN0UmVwKyBCd05vdCsNCgkJTG5rQ3RsOglBU1BNIERpc2Fi
bGVkOyBSQ0IgNjQgYnl0ZXMgRGlzYWJsZWQtIFJldHJhaW4tIENvbW1DbGsrDQoJCQlFeHRT
eW5jaC0gQ2xvY2tQTS0gQXV0V2lkRGlzLSBCV0ludC0gQXV0QldJbnQtDQoJCUxua1N0YToJ
U3BlZWQgMi41R1QvcywgV2lkdGggeDgsIFRyRXJyLSBUcmFpbi0gU2xvdENsaysgRExBY3Rp
dmUrIEJXTWdtdCsgQUJXTWdtdC0NCgkJU2x0Q2FwOglBdHRuQnRuLSBQd3JDdHJsLSBNUkwt
IEF0dG5JbmQtIFB3ckluZC0gSG90UGx1Zy0gU3VycHJpc2UtDQoJCQlTbG90ICMxLCBQb3dl
ckxpbWl0IDI1LjAwMFc7IEludGVybG9jay0gTm9Db21wbCsNCgkJU2x0Q3RsOglFbmFibGU6
IEF0dG5CdG4tIFB3ckZsdC0gTVJMLSBQcmVzRGV0LSBDbWRDcGx0LSBIUElycS0gTGlua0No
Zy0NCgkJCUNvbnRyb2w6IEF0dG5JbmQgVW5rbm93biwgUHdySW5kIFVua25vd24sIFBvd2Vy
LSBJbnRlcmxvY2stDQoJCVNsdFN0YToJU3RhdHVzOiBBdHRuQnRuLSBQb3dlckZsdC0gTVJM
LSBDbWRDcGx0LSBQcmVzRGV0KyBJbnRlcmxvY2stDQoJCQlDaGFuZ2VkOiBNUkwtIFByZXNE
ZXQrIExpbmtTdGF0ZSsNCgkJUm9vdEN0bDogRXJyQ29ycmVjdGFibGUtIEVyck5vbi1GYXRh
bC0gRXJyRmF0YWwtIFBNRUludEVuYS0gQ1JTVmlzaWJsZS0NCgkJUm9vdENhcDogQ1JTVmlz
aWJsZS0NCgkJUm9vdFN0YTogUE1FIFJlcUlEIDAwMDAsIFBNRVN0YXR1cy0gUE1FUGVuZGlu
Zy0NCgkJRGV2Q2FwMjogQ29tcGxldGlvbiBUaW1lb3V0OiBSYW5nZSBBQkNELCBUaW1lb3V0
RGlzKyBBUklGd2QrDQoJCURldkN0bDI6IENvbXBsZXRpb24gVGltZW91dDogNjVtcyB0byAy
MTBtcywgVGltZW91dERpcy0gQVJJRndkLQ0KCQlMbmtDdGwyOiBUYXJnZXQgTGluayBTcGVl
ZDogNUdUL3MsIEVudGVyQ29tcGxpYW5jZS0gU3BlZWREaXMtLCBTZWxlY3RhYmxlIERlLWVt
cGhhc2lzOiAtMy41ZEINCgkJCSBUcmFuc21pdCBNYXJnaW46IE5vcm1hbCBPcGVyYXRpbmcg
UmFuZ2UsIEVudGVyTW9kaWZpZWRDb21wbGlhbmNlLSBDb21wbGlhbmNlU09TLQ0KCQkJIENv
bXBsaWFuY2UgRGUtZW1waGFzaXM6IC02ZEINCgkJTG5rU3RhMjogQ3VycmVudCBEZS1lbXBo
YXNpcyBMZXZlbDogLTMuNWRCDQoJQ2FwYWJpbGl0aWVzOiBbYTBdIE1TSTogRW5hYmxlKyBD
b3VudD0xLzEgTWFza2FibGUtIDY0Yml0LQ0KCQlBZGRyZXNzOiBmZWUzZjAwYyAgRGF0YTog
NDE1MQ0KCUNhcGFiaWxpdGllczogW2IwXSBTdWJzeXN0ZW06IEFUSSBUZWNobm9sb2dpZXMg
SW5jIERldmljZSBbMTAwMjo1YTExXQ0KCUNhcGFiaWxpdGllczogW2I4XSBIeXBlclRyYW5z
cG9ydDogTVNJIE1hcHBpbmcgRW5hYmxlKyBGaXhlZCsNCglDYXBhYmlsaXRpZXM6IFsxMDAg
djFdIFZlbmRvciBTcGVjaWZpYyBJbmZvcm1hdGlvbjogSUQ9MDAwMSBSZXY9MSBMZW49MDEw
IDw/Pg0KCUNhcGFiaWxpdGllczogWzE5MCB2MV0gQWNjZXNzIENvbnRyb2wgU2VydmljZXMN
CgkJQUNTQ2FwOglTcmNWYWxpZCsgVHJhbnNCbGsrIFJlcVJlZGlyKyBDbXBsdFJlZGlyKyBV
cHN0cmVhbUZ3ZCsgRWdyZXNzQ3RybC0gRGlyZWN0VHJhbnMrDQoJCUFDU0N0bDoJU3JjVmFs
aWQrIFRyYW5zQmxrLSBSZXFSZWRpcisgQ21wbHRSZWRpcisgVXBzdHJlYW1Gd2QrIEVncmVz
c0N0cmwtIERpcmVjdFRyYW5zLQ0KCUtlcm5lbCBkcml2ZXIgaW4gdXNlOiBwY2llcG9ydA0K
DQowMDowMy4wIFBDSSBicmlkZ2UgWzA2MDRdOiBBVEkgVGVjaG5vbG9naWVzIEluYyBSRDg5
MCBQQ0kgdG8gUENJIGJyaWRnZSAoUENJIGV4cHJlc3MgZ3BwIHBvcnQgQykgWzEwMDI6NWEx
N10gKHByb2ctaWYgMDAgW05vcm1hbCBkZWNvZGVdKQ0KCUNvbnRyb2w6IEkvTy0gTWVtKyBC
dXNNYXN0ZXIrIFNwZWNDeWNsZS0gTWVtV0lOVi0gVkdBU25vb3AtIFBhckVyci0gU3RlcHBp
bmctIFNFUlIrIEZhc3RCMkItIERpc0lOVHgrDQoJU3RhdHVzOiBDYXArIDY2TUh6LSBVREYt
IEZhc3RCMkItIFBhckVyci0gREVWU0VMPWZhc3QgPlRBYm9ydC0gPFRBYm9ydC0gPE1BYm9y
dC0gPlNFUlItIDxQRVJSLSBJTlR4LQ0KCUxhdGVuY3k6IDAsIENhY2hlIExpbmUgU2l6ZTog
NjQgYnl0ZXMNCglCdXM6IHByaW1hcnk9MDAsIHNlY29uZGFyeT0wYSwgc3Vib3JkaW5hdGU9
MGEsIHNlYy1sYXRlbmN5PTANCglJL08gYmVoaW5kIGJyaWRnZTogMDAwMGYwMDAtMDAwMDBm
ZmYNCglNZW1vcnkgYmVoaW5kIGJyaWRnZTogZjlmMDAwMDAtZjlmZmZmZmYNCglQcmVmZXRj
aGFibGUgbWVtb3J5IGJlaGluZCBicmlkZ2U6IDAwMDAwMDAwZmZmMDAwMDAtMDAwMDAwMDAw
MDBmZmZmZg0KCVNlY29uZGFyeSBzdGF0dXM6IDY2TUh6LSBGYXN0QjJCLSBQYXJFcnItIERF
VlNFTD1mYXN0ID5UQWJvcnQtIDxUQWJvcnQtIDxNQWJvcnQtIDxTRVJSLSA8UEVSUi0NCglC
cmlkZ2VDdGw6IFBhcml0eSsgU0VSUisgTm9JU0ErIFZHQS0gTUFib3J0LSA+UmVzZXQtIEZh
c3RCMkItDQoJCVByaURpc2NUbXItIFNlY0Rpc2NUbXItIERpc2NUbXJTdGF0LSBEaXNjVG1y
U0VSUkVuLQ0KCUNhcGFiaWxpdGllczogWzUwXSBQb3dlciBNYW5hZ2VtZW50IHZlcnNpb24g
Mw0KCQlGbGFnczogUE1FQ2xrLSBEU0ktIEQxLSBEMi0gQXV4Q3VycmVudD0wbUEgUE1FKEQw
KyxEMS0sRDItLEQzaG90KyxEM2NvbGQrKQ0KCQlTdGF0dXM6IEQwIE5vU29mdFJzdC0gUE1F
LUVuYWJsZS0gRFNlbD0wIERTY2FsZT0wIFBNRS0NCglDYXBhYmlsaXRpZXM6IFs1OF0gRXhw
cmVzcyAodjIpIFJvb3QgUG9ydCAoU2xvdCspLCBNU0kgMDANCgkJRGV2Q2FwOglNYXhQYXls
b2FkIDEyOCBieXRlcywgUGhhbnRGdW5jIDAsIExhdGVuY3kgTDBzIDw2NG5zLCBMMSA8MXVz
DQoJCQlFeHRUYWcrIFJCRSsgRkxSZXNldC0NCgkJRGV2Q3RsOglSZXBvcnQgZXJyb3JzOiBD
b3JyZWN0YWJsZS0gTm9uLUZhdGFsLSBGYXRhbC0gVW5zdXBwb3J0ZWQtDQoJCQlSbHhkT3Jk
KyBFeHRUYWctIFBoYW50RnVuYy0gQXV4UHdyLSBOb1Nub29wKw0KCQkJTWF4UGF5bG9hZCAx
MjggYnl0ZXMsIE1heFJlYWRSZXEgMTI4IGJ5dGVzDQoJCURldlN0YToJQ29yckVyci0gVW5j
b3JyRXJyLSBGYXRhbEVyci0gVW5zdXBwUmVxLSBBdXhQd3ItIFRyYW5zUGVuZC0NCgkJTG5r
Q2FwOglQb3J0ICMxLCBTcGVlZCA1R1QvcywgV2lkdGggeDgsIEFTUE0gTDBzIEwxLCBMYXRl
bmN5IEwwIDwxdXMsIEwxIDw4dXMNCgkJCUNsb2NrUE0tIFN1cnByaXNlLSBMTEFjdFJlcCsg
QndOb3QrDQoJCUxua0N0bDoJQVNQTSBEaXNhYmxlZDsgUkNCIDY0IGJ5dGVzIERpc2FibGVk
LSBSZXRyYWluLSBDb21tQ2xrLQ0KCQkJRXh0U3luY2gtIENsb2NrUE0tIEF1dFdpZERpcy0g
QldJbnQtIEF1dEJXSW50LQ0KCQlMbmtTdGE6CVNwZWVkIDIuNUdUL3MsIFdpZHRoIHgxLCBU
ckVyci0gVHJhaW4tIFNsb3RDbGsrIERMQWN0aXZlKyBCV01nbXQrIEFCV01nbXQtDQoJCVNs
dENhcDoJQXR0bkJ0bi0gUHdyQ3RybC0gTVJMLSBBdHRuSW5kLSBQd3JJbmQtIEhvdFBsdWct
IFN1cnByaXNlLQ0KCQkJU2xvdCAjMywgUG93ZXJMaW1pdCAxMC4wMDBXOyBJbnRlcmxvY2st
IE5vQ29tcGwrDQoJCVNsdEN0bDoJRW5hYmxlOiBBdHRuQnRuLSBQd3JGbHQtIE1STC0gUHJl
c0RldC0gQ21kQ3BsdC0gSFBJcnEtIExpbmtDaGctDQoJCQlDb250cm9sOiBBdHRuSW5kIFVu
a25vd24sIFB3ckluZCBVbmtub3duLCBQb3dlci0gSW50ZXJsb2NrLQ0KCQlTbHRTdGE6CVN0
YXR1czogQXR0bkJ0bi0gUG93ZXJGbHQtIE1STC0gQ21kQ3BsdC0gUHJlc0RldCsgSW50ZXJs
b2NrLQ0KCQkJQ2hhbmdlZDogTVJMLSBQcmVzRGV0KyBMaW5rU3RhdGUrDQoJCVJvb3RDdGw6
IEVyckNvcnJlY3RhYmxlLSBFcnJOb24tRmF0YWwtIEVyckZhdGFsLSBQTUVJbnRFbmEtIENS
U1Zpc2libGUtDQoJCVJvb3RDYXA6IENSU1Zpc2libGUtDQoJCVJvb3RTdGE6IFBNRSBSZXFJ
RCAwMDAwLCBQTUVTdGF0dXMtIFBNRVBlbmRpbmctDQoJCURldkNhcDI6IENvbXBsZXRpb24g
VGltZW91dDogUmFuZ2UgQUJDRCwgVGltZW91dERpcysgQVJJRndkKw0KCQlEZXZDdGwyOiBD
b21wbGV0aW9uIFRpbWVvdXQ6IDY1bXMgdG8gMjEwbXMsIFRpbWVvdXREaXMtIEFSSUZ3ZC0N
CgkJTG5rQ3RsMjogVGFyZ2V0IExpbmsgU3BlZWQ6IDVHVC9zLCBFbnRlckNvbXBsaWFuY2Ut
IFNwZWVkRGlzLSwgU2VsZWN0YWJsZSBEZS1lbXBoYXNpczogLTMuNWRCDQoJCQkgVHJhbnNt
aXQgTWFyZ2luOiBOb3JtYWwgT3BlcmF0aW5nIFJhbmdlLCBFbnRlck1vZGlmaWVkQ29tcGxp
YW5jZS0gQ29tcGxpYW5jZVNPUy0NCgkJCSBDb21wbGlhbmNlIERlLWVtcGhhc2lzOiAtNmRC
DQoJCUxua1N0YTI6IEN1cnJlbnQgRGUtZW1waGFzaXMgTGV2ZWw6IC0zLjVkQg0KCUNhcGFi
aWxpdGllczogW2EwXSBNU0k6IEVuYWJsZSsgQ291bnQ9MS8xIE1hc2thYmxlLSA2NGJpdC0N
CgkJQWRkcmVzczogZmVlM2YwMGMgIERhdGE6IDQxNTkNCglDYXBhYmlsaXRpZXM6IFtiMF0g
U3Vic3lzdGVtOiBBVEkgVGVjaG5vbG9naWVzIEluYyBEZXZpY2UgWzEwMDI6NWExMV0NCglD
YXBhYmlsaXRpZXM6IFtiOF0gSHlwZXJUcmFuc3BvcnQ6IE1TSSBNYXBwaW5nIEVuYWJsZSsg
Rml4ZWQrDQoJQ2FwYWJpbGl0aWVzOiBbMTAwIHYxXSBWZW5kb3IgU3BlY2lmaWMgSW5mb3Jt
YXRpb246IElEPTAwMDEgUmV2PTEgTGVuPTAxMCA8Pz4NCglDYXBhYmlsaXRpZXM6IFsxOTAg
djFdIEFjY2VzcyBDb250cm9sIFNlcnZpY2VzDQoJCUFDU0NhcDoJU3JjVmFsaWQrIFRyYW5z
QmxrKyBSZXFSZWRpcisgQ21wbHRSZWRpcisgVXBzdHJlYW1Gd2QrIEVncmVzc0N0cmwtIERp
cmVjdFRyYW5zKw0KCQlBQ1NDdGw6CVNyY1ZhbGlkKyBUcmFuc0Jsay0gUmVxUmVkaXIrIENt
cGx0UmVkaXIrIFVwc3RyZWFtRndkKyBFZ3Jlc3NDdHJsLSBEaXJlY3RUcmFucy0NCglLZXJu
ZWwgZHJpdmVyIGluIHVzZTogcGNpZXBvcnQNCg0KMDA6MDUuMCBQQ0kgYnJpZGdlIFswNjA0
XTogQVRJIFRlY2hub2xvZ2llcyBJbmMgUkQ4OTAgUENJIHRvIFBDSSBicmlkZ2UgKFBDSSBl
eHByZXNzIGdwcCBwb3J0IEUpIFsxMDAyOjVhMTldIChwcm9nLWlmIDAwIFtOb3JtYWwgZGVj
b2RlXSkNCglDb250cm9sOiBJL08rIE1lbSsgQnVzTWFzdGVyKyBTcGVjQ3ljbGUtIE1lbVdJ
TlYtIFZHQVNub29wLSBQYXJFcnItIFN0ZXBwaW5nLSBTRVJSKyBGYXN0QjJCLSBEaXNJTlR4
Kw0KCVN0YXR1czogQ2FwKyA2Nk1Iei0gVURGLSBGYXN0QjJCLSBQYXJFcnItIERFVlNFTD1m
YXN0ID5UQWJvcnQtIDxUQWJvcnQtIDxNQWJvcnQtID5TRVJSLSA8UEVSUi0gSU5UeC0NCglM
YXRlbmN5OiAwLCBDYWNoZSBMaW5lIFNpemU6IDY0IGJ5dGVzDQoJQnVzOiBwcmltYXJ5PTAw
LCBzZWNvbmRhcnk9MDksIHN1Ym9yZGluYXRlPTA5LCBzZWMtbGF0ZW5jeT0wDQoJSS9PIGJl
aGluZCBicmlkZ2U6IDAwMDBkMDAwLTAwMDBkZmZmDQoJTWVtb3J5IGJlaGluZCBicmlkZ2U6
IGY5ZTAwMDAwLWY5ZWZmZmZmDQoJUHJlZmV0Y2hhYmxlIG1lbW9yeSBiZWhpbmQgYnJpZGdl
OiAwMDAwMDAwMGNmZjAwMDAwLTAwMDAwMDAwY2ZmZmZmZmYNCglTZWNvbmRhcnkgc3RhdHVz
OiA2Nk1Iei0gRmFzdEIyQi0gUGFyRXJyLSBERVZTRUw9ZmFzdCA+VEFib3J0LSA8VEFib3J0
LSA8TUFib3J0LSA8U0VSUi0gPFBFUlItDQoJQnJpZGdlQ3RsOiBQYXJpdHkrIFNFUlIrIE5v
SVNBKyBWR0EtIE1BYm9ydC0gPlJlc2V0LSBGYXN0QjJCLQ0KCQlQcmlEaXNjVG1yLSBTZWNE
aXNjVG1yLSBEaXNjVG1yU3RhdC0gRGlzY1RtclNFUlJFbi0NCglDYXBhYmlsaXRpZXM6IFs1
MF0gUG93ZXIgTWFuYWdlbWVudCB2ZXJzaW9uIDMNCgkJRmxhZ3M6IFBNRUNsay0gRFNJLSBE
MS0gRDItIEF1eEN1cnJlbnQ9MG1BIFBNRShEMCssRDEtLEQyLSxEM2hvdCssRDNjb2xkKykN
CgkJU3RhdHVzOiBEMCBOb1NvZnRSc3QtIFBNRS1FbmFibGUtIERTZWw9MCBEU2NhbGU9MCBQ
TUUtDQoJQ2FwYWJpbGl0aWVzOiBbNThdIEV4cHJlc3MgKHYyKSBSb290IFBvcnQgKFNsb3Qr
KSwgTVNJIDAwDQoJCURldkNhcDoJTWF4UGF5bG9hZCAxMjggYnl0ZXMsIFBoYW50RnVuYyAw
LCBMYXRlbmN5IEwwcyA8NjRucywgTDEgPDF1cw0KCQkJRXh0VGFnKyBSQkUrIEZMUmVzZXQt
DQoJCURldkN0bDoJUmVwb3J0IGVycm9yczogQ29ycmVjdGFibGUtIE5vbi1GYXRhbC0gRmF0
YWwtIFVuc3VwcG9ydGVkLQ0KCQkJUmx4ZE9yZCsgRXh0VGFnLSBQaGFudEZ1bmMtIEF1eFB3
ci0gTm9Tbm9vcCsNCgkJCU1heFBheWxvYWQgMTI4IGJ5dGVzLCBNYXhSZWFkUmVxIDEyOCBi
eXRlcw0KCQlEZXZTdGE6CUNvcnJFcnItIFVuY29yckVyci0gRmF0YWxFcnItIFVuc3VwcFJl
cS0gQXV4UHdyLSBUcmFuc1BlbmQtDQoJCUxua0NhcDoJUG9ydCAjMSwgU3BlZWQgNUdUL3Ms
IFdpZHRoIHgxLCBBU1BNIEwwcyBMMSwgTGF0ZW5jeSBMMCA8MXVzLCBMMSA8OHVzDQoJCQlD
bG9ja1BNLSBTdXJwcmlzZS0gTExBY3RSZXArIEJ3Tm90Kw0KCQlMbmtDdGw6CUFTUE0gRGlz
YWJsZWQ7IFJDQiA2NCBieXRlcyBEaXNhYmxlZC0gUmV0cmFpbi0gQ29tbUNsaysNCgkJCUV4
dFN5bmNoLSBDbG9ja1BNLSBBdXRXaWREaXMtIEJXSW50LSBBdXRCV0ludC0NCgkJTG5rU3Rh
OglTcGVlZCAyLjVHVC9zLCBXaWR0aCB4MSwgVHJFcnItIFRyYWluLSBTbG90Q2xrKyBETEFj
dGl2ZSsgQldNZ210KyBBQldNZ210LQ0KCQlTbHRDYXA6CUF0dG5CdG4tIFB3ckN0cmwtIE1S
TC0gQXR0bkluZC0gUHdySW5kLSBIb3RQbHVnLSBTdXJwcmlzZS0NCgkJCVNsb3QgIzUsIFBv
d2VyTGltaXQgNzUuMDAwVzsgSW50ZXJsb2NrLSBOb0NvbXBsKw0KCQlTbHRDdGw6CUVuYWJs
ZTogQXR0bkJ0bi0gUHdyRmx0LSBNUkwtIFByZXNEZXQtIENtZENwbHQtIEhQSXJxLSBMaW5r
Q2hnLQ0KCQkJQ29udHJvbDogQXR0bkluZCBVbmtub3duLCBQd3JJbmQgVW5rbm93biwgUG93
ZXItIEludGVybG9jay0NCgkJU2x0U3RhOglTdGF0dXM6IEF0dG5CdG4tIFBvd2VyRmx0LSBN
UkwtIENtZENwbHQtIFByZXNEZXQrIEludGVybG9jay0NCgkJCUNoYW5nZWQ6IE1STC0gUHJl
c0RldCsgTGlua1N0YXRlKw0KCQlSb290Q3RsOiBFcnJDb3JyZWN0YWJsZS0gRXJyTm9uLUZh
dGFsLSBFcnJGYXRhbC0gUE1FSW50RW5hLSBDUlNWaXNpYmxlLQ0KCQlSb290Q2FwOiBDUlNW
aXNpYmxlLQ0KCQlSb290U3RhOiBQTUUgUmVxSUQgMDAwMCwgUE1FU3RhdHVzLSBQTUVQZW5k
aW5nLQ0KCQlEZXZDYXAyOiBDb21wbGV0aW9uIFRpbWVvdXQ6IFJhbmdlIEFCQ0QsIFRpbWVv
dXREaXMrIEFSSUZ3ZCsNCgkJRGV2Q3RsMjogQ29tcGxldGlvbiBUaW1lb3V0OiA2NW1zIHRv
IDIxMG1zLCBUaW1lb3V0RGlzLSBBUklGd2QtDQoJCUxua0N0bDI6IFRhcmdldCBMaW5rIFNw
ZWVkOiA1R1QvcywgRW50ZXJDb21wbGlhbmNlLSBTcGVlZERpcy0sIFNlbGVjdGFibGUgRGUt
ZW1waGFzaXM6IC0zLjVkQg0KCQkJIFRyYW5zbWl0IE1hcmdpbjogTm9ybWFsIE9wZXJhdGlu
ZyBSYW5nZSwgRW50ZXJNb2RpZmllZENvbXBsaWFuY2UtIENvbXBsaWFuY2VTT1MtDQoJCQkg
Q29tcGxpYW5jZSBEZS1lbXBoYXNpczogLTZkQg0KCQlMbmtTdGEyOiBDdXJyZW50IERlLWVt
cGhhc2lzIExldmVsOiAtMy41ZEINCglDYXBhYmlsaXRpZXM6IFthMF0gTVNJOiBFbmFibGUr
IENvdW50PTEvMSBNYXNrYWJsZS0gNjRiaXQtDQoJCUFkZHJlc3M6IGZlZTNmMDBjICBEYXRh
OiA0MTYxDQoJQ2FwYWJpbGl0aWVzOiBbYjBdIFN1YnN5c3RlbTogQVRJIFRlY2hub2xvZ2ll
cyBJbmMgRGV2aWNlIFsxMDAyOjVhMTFdDQoJQ2FwYWJpbGl0aWVzOiBbYjhdIEh5cGVyVHJh
bnNwb3J0OiBNU0kgTWFwcGluZyBFbmFibGUrIEZpeGVkKw0KCUNhcGFiaWxpdGllczogWzEw
MCB2MV0gVmVuZG9yIFNwZWNpZmljIEluZm9ybWF0aW9uOiBJRD0wMDAxIFJldj0xIExlbj0w
MTAgPD8+DQoJQ2FwYWJpbGl0aWVzOiBbMTkwIHYxXSBBY2Nlc3MgQ29udHJvbCBTZXJ2aWNl
cw0KCQlBQ1NDYXA6CVNyY1ZhbGlkKyBUcmFuc0JsaysgUmVxUmVkaXIrIENtcGx0UmVkaXIr
IFVwc3RyZWFtRndkKyBFZ3Jlc3NDdHJsLSBEaXJlY3RUcmFucysNCgkJQUNTQ3RsOglTcmNW
YWxpZCsgVHJhbnNCbGstIFJlcVJlZGlyKyBDbXBsdFJlZGlyKyBVcHN0cmVhbUZ3ZCsgRWdy
ZXNzQ3RybC0gRGlyZWN0VHJhbnMtDQoJS2VybmVsIGRyaXZlciBpbiB1c2U6IHBjaWVwb3J0
DQoNCjAwOjA2LjAgUENJIGJyaWRnZSBbMDYwNF06IEFUSSBUZWNobm9sb2dpZXMgSW5jIFJE
ODkwIFBDSSB0byBQQ0kgYnJpZGdlIChQQ0kgZXhwcmVzcyBncHAgcG9ydCBGKSBbMTAwMjo1
YTFhXSAocHJvZy1pZiAwMCBbTm9ybWFsIGRlY29kZV0pDQoJQ29udHJvbDogSS9PKyBNZW0r
IEJ1c01hc3RlcisgU3BlY0N5Y2xlLSBNZW1XSU5WLSBWR0FTbm9vcC0gUGFyRXJyLSBTdGVw
cGluZy0gU0VSUisgRmFzdEIyQi0gRGlzSU5UeCsNCglTdGF0dXM6IENhcCsgNjZNSHotIFVE
Ri0gRmFzdEIyQi0gUGFyRXJyLSBERVZTRUw9ZmFzdCA+VEFib3J0LSA8VEFib3J0LSA8TUFi
b3J0LSA+U0VSUi0gPFBFUlItIElOVHgtDQoJTGF0ZW5jeTogMCwgQ2FjaGUgTGluZSBTaXpl
OiA2NCBieXRlcw0KCUJ1czogcHJpbWFyeT0wMCwgc2Vjb25kYXJ5PTA4LCBzdWJvcmRpbmF0
ZT0wOCwgc2VjLWxhdGVuY3k9MA0KCUkvTyBiZWhpbmQgYnJpZGdlOiAwMDAwYzAwMC0wMDAw
Y2ZmZg0KCU1lbW9yeSBiZWhpbmQgYnJpZGdlOiBmOWQwMDAwMC1mOWRmZmZmZg0KCVByZWZl
dGNoYWJsZSBtZW1vcnkgYmVoaW5kIGJyaWRnZTogMDAwMDAwMDBjZmUwMDAwMC0wMDAwMDAw
MGNmZWZmZmZmDQoJU2Vjb25kYXJ5IHN0YXR1czogNjZNSHotIEZhc3RCMkItIFBhckVyci0g
REVWU0VMPWZhc3QgPlRBYm9ydC0gPFRBYm9ydC0gPE1BYm9ydC0gPFNFUlItIDxQRVJSLQ0K
CUJyaWRnZUN0bDogUGFyaXR5KyBTRVJSKyBOb0lTQSsgVkdBLSBNQWJvcnQtID5SZXNldC0g
RmFzdEIyQi0NCgkJUHJpRGlzY1Rtci0gU2VjRGlzY1Rtci0gRGlzY1RtclN0YXQtIERpc2NU
bXJTRVJSRW4tDQoJQ2FwYWJpbGl0aWVzOiBbNTBdIFBvd2VyIE1hbmFnZW1lbnQgdmVyc2lv
biAzDQoJCUZsYWdzOiBQTUVDbGstIERTSS0gRDEtIEQyLSBBdXhDdXJyZW50PTBtQSBQTUUo
RDArLEQxLSxEMi0sRDNob3QrLEQzY29sZCspDQoJCVN0YXR1czogRDAgTm9Tb2Z0UnN0LSBQ
TUUtRW5hYmxlLSBEU2VsPTAgRFNjYWxlPTAgUE1FLQ0KCUNhcGFiaWxpdGllczogWzU4XSBF
eHByZXNzICh2MikgUm9vdCBQb3J0IChTbG90KyksIE1TSSAwMA0KCQlEZXZDYXA6CU1heFBh
eWxvYWQgMTI4IGJ5dGVzLCBQaGFudEZ1bmMgMCwgTGF0ZW5jeSBMMHMgPDY0bnMsIEwxIDwx
dXMNCgkJCUV4dFRhZysgUkJFKyBGTFJlc2V0LQ0KCQlEZXZDdGw6CVJlcG9ydCBlcnJvcnM6
IENvcnJlY3RhYmxlLSBOb24tRmF0YWwtIEZhdGFsLSBVbnN1cHBvcnRlZC0NCgkJCVJseGRP
cmQrIEV4dFRhZy0gUGhhbnRGdW5jLSBBdXhQd3ItIE5vU25vb3ArDQoJCQlNYXhQYXlsb2Fk
IDEyOCBieXRlcywgTWF4UmVhZFJlcSAxMjggYnl0ZXMNCgkJRGV2U3RhOglDb3JyRXJyLSBV
bmNvcnJFcnItIEZhdGFsRXJyLSBVbnN1cHBSZXEtIEF1eFB3ci0gVHJhbnNQZW5kLQ0KCQlM
bmtDYXA6CVBvcnQgIzIsIFNwZWVkIDVHVC9zLCBXaWR0aCB4MSwgQVNQTSBMMHMgTDEsIExh
dGVuY3kgTDAgPDF1cywgTDEgPDh1cw0KCQkJQ2xvY2tQTS0gU3VycHJpc2UtIExMQWN0UmVw
KyBCd05vdCsNCgkJTG5rQ3RsOglBU1BNIERpc2FibGVkOyBSQ0IgNjQgYnl0ZXMgRGlzYWJs
ZWQtIFJldHJhaW4tIENvbW1DbGsrDQoJCQlFeHRTeW5jaC0gQ2xvY2tQTS0gQXV0V2lkRGlz
LSBCV0ludC0gQXV0QldJbnQtDQoJCUxua1N0YToJU3BlZWQgMi41R1QvcywgV2lkdGggeDEs
IFRyRXJyLSBUcmFpbi0gU2xvdENsaysgRExBY3RpdmUrIEJXTWdtdCsgQUJXTWdtdC0NCgkJ
U2x0Q2FwOglBdHRuQnRuLSBQd3JDdHJsLSBNUkwtIEF0dG5JbmQtIFB3ckluZC0gSG90UGx1
Zy0gU3VycHJpc2UtDQoJCQlTbG90ICM2LCBQb3dlckxpbWl0IDc1LjAwMFc7IEludGVybG9j
ay0gTm9Db21wbCsNCgkJU2x0Q3RsOglFbmFibGU6IEF0dG5CdG4tIFB3ckZsdC0gTVJMLSBQ
cmVzRGV0LSBDbWRDcGx0LSBIUElycS0gTGlua0NoZy0NCgkJCUNvbnRyb2w6IEF0dG5JbmQg
VW5rbm93biwgUHdySW5kIFVua25vd24sIFBvd2VyLSBJbnRlcmxvY2stDQoJCVNsdFN0YToJ
U3RhdHVzOiBBdHRuQnRuLSBQb3dlckZsdC0gTVJMLSBDbWRDcGx0LSBQcmVzRGV0KyBJbnRl
cmxvY2stDQoJCQlDaGFuZ2VkOiBNUkwtIFByZXNEZXQrIExpbmtTdGF0ZSsNCgkJUm9vdEN0
bDogRXJyQ29ycmVjdGFibGUtIEVyck5vbi1GYXRhbC0gRXJyRmF0YWwtIFBNRUludEVuYS0g
Q1JTVmlzaWJsZS0NCgkJUm9vdENhcDogQ1JTVmlzaWJsZS0NCgkJUm9vdFN0YTogUE1FIFJl
cUlEIDAwMDAsIFBNRVN0YXR1cy0gUE1FUGVuZGluZy0NCgkJRGV2Q2FwMjogQ29tcGxldGlv
biBUaW1lb3V0OiBSYW5nZSBBQkNELCBUaW1lb3V0RGlzKyBBUklGd2QrDQoJCURldkN0bDI6
IENvbXBsZXRpb24gVGltZW91dDogNjVtcyB0byAyMTBtcywgVGltZW91dERpcy0gQVJJRndk
LQ0KCQlMbmtDdGwyOiBUYXJnZXQgTGluayBTcGVlZDogNUdUL3MsIEVudGVyQ29tcGxpYW5j
ZS0gU3BlZWREaXMtLCBTZWxlY3RhYmxlIERlLWVtcGhhc2lzOiAtMy41ZEINCgkJCSBUcmFu
c21pdCBNYXJnaW46IE5vcm1hbCBPcGVyYXRpbmcgUmFuZ2UsIEVudGVyTW9kaWZpZWRDb21w
bGlhbmNlLSBDb21wbGlhbmNlU09TLQ0KCQkJIENvbXBsaWFuY2UgRGUtZW1waGFzaXM6IC02
ZEINCgkJTG5rU3RhMjogQ3VycmVudCBEZS1lbXBoYXNpcyBMZXZlbDogLTMuNWRCDQoJQ2Fw
YWJpbGl0aWVzOiBbYTBdIE1TSTogRW5hYmxlKyBDb3VudD0xLzEgTWFza2FibGUtIDY0Yml0
LQ0KCQlBZGRyZXNzOiBmZWUzZjAwYyAgRGF0YTogNDE2OQ0KCUNhcGFiaWxpdGllczogW2Iw
XSBTdWJzeXN0ZW06IEFUSSBUZWNobm9sb2dpZXMgSW5jIERldmljZSBbMTAwMjo1YTExXQ0K
CUNhcGFiaWxpdGllczogW2I4XSBIeXBlclRyYW5zcG9ydDogTVNJIE1hcHBpbmcgRW5hYmxl
KyBGaXhlZCsNCglDYXBhYmlsaXRpZXM6IFsxMDAgdjFdIFZlbmRvciBTcGVjaWZpYyBJbmZv
cm1hdGlvbjogSUQ9MDAwMSBSZXY9MSBMZW49MDEwIDw/Pg0KCUNhcGFiaWxpdGllczogWzE5
MCB2MV0gQWNjZXNzIENvbnRyb2wgU2VydmljZXMNCgkJQUNTQ2FwOglTcmNWYWxpZCsgVHJh
bnNCbGsrIFJlcVJlZGlyKyBDbXBsdFJlZGlyKyBVcHN0cmVhbUZ3ZCsgRWdyZXNzQ3RybC0g
RGlyZWN0VHJhbnMrDQoJCUFDU0N0bDoJU3JjVmFsaWQrIFRyYW5zQmxrLSBSZXFSZWRpcisg
Q21wbHRSZWRpcisgVXBzdHJlYW1Gd2QrIEVncmVzc0N0cmwtIERpcmVjdFRyYW5zLQ0KCUtl
cm5lbCBkcml2ZXIgaW4gdXNlOiBwY2llcG9ydA0KDQowMDowYS4wIFBDSSBicmlkZ2UgWzA2
MDRdOiBBVEkgVGVjaG5vbG9naWVzIEluYyBSRDg5MCBQQ0kgdG8gUENJIGJyaWRnZSAoZXh0
ZXJuYWwgZ2Z4MSBwb3J0IEEpIFsxMDAyOjVhMWRdIChwcm9nLWlmIDAwIFtOb3JtYWwgZGVj
b2RlXSkNCglDb250cm9sOiBJL08tIE1lbSsgQnVzTWFzdGVyKyBTcGVjQ3ljbGUtIE1lbVdJ
TlYtIFZHQVNub29wLSBQYXJFcnItIFN0ZXBwaW5nLSBTRVJSKyBGYXN0QjJCLSBEaXNJTlR4
Kw0KCVN0YXR1czogQ2FwKyA2Nk1Iei0gVURGLSBGYXN0QjJCLSBQYXJFcnItIERFVlNFTD1m
YXN0ID5UQWJvcnQtIDxUQWJvcnQtIDxNQWJvcnQtID5TRVJSLSA8UEVSUi0gSU5UeC0NCglM
YXRlbmN5OiAwLCBDYWNoZSBMaW5lIFNpemU6IDY0IGJ5dGVzDQoJQnVzOiBwcmltYXJ5PTAw
LCBzZWNvbmRhcnk9MDcsIHN1Ym9yZGluYXRlPTA3LCBzZWMtbGF0ZW5jeT0wDQoJSS9PIGJl
aGluZCBicmlkZ2U6IDAwMDBmMDAwLTAwMDAwZmZmDQoJTWVtb3J5IGJlaGluZCBicmlkZ2U6
IGY5YTAwMDAwLWY5YmZmZmZmDQoJUHJlZmV0Y2hhYmxlIG1lbW9yeSBiZWhpbmQgYnJpZGdl
OiAwMDAwMDAwMGZmZjAwMDAwLTAwMDAwMDAwMDAwZmZmZmYNCglTZWNvbmRhcnkgc3RhdHVz
OiA2Nk1Iei0gRmFzdEIyQi0gUGFyRXJyLSBERVZTRUw9ZmFzdCA+VEFib3J0LSA8VEFib3J0
LSA8TUFib3J0KyA8U0VSUi0gPFBFUlItDQoJQnJpZGdlQ3RsOiBQYXJpdHkrIFNFUlIrIE5v
SVNBKyBWR0EtIE1BYm9ydC0gPlJlc2V0LSBGYXN0QjJCLQ0KCQlQcmlEaXNjVG1yLSBTZWNE
aXNjVG1yLSBEaXNjVG1yU3RhdC0gRGlzY1RtclNFUlJFbi0NCglDYXBhYmlsaXRpZXM6IFs1
MF0gUG93ZXIgTWFuYWdlbWVudCB2ZXJzaW9uIDMNCgkJRmxhZ3M6IFBNRUNsay0gRFNJLSBE
MS0gRDItIEF1eEN1cnJlbnQ9MG1BIFBNRShEMCssRDEtLEQyLSxEM2hvdCssRDNjb2xkKykN
CgkJU3RhdHVzOiBEMCBOb1NvZnRSc3QtIFBNRS1FbmFibGUtIERTZWw9MCBEU2NhbGU9MCBQ
TUUtDQoJQ2FwYWJpbGl0aWVzOiBbNThdIEV4cHJlc3MgKHYyKSBSb290IFBvcnQgKFNsb3Qr
KSwgTVNJIDAwDQoJCURldkNhcDoJTWF4UGF5bG9hZCAxMjggYnl0ZXMsIFBoYW50RnVuYyAw
LCBMYXRlbmN5IEwwcyA8NjRucywgTDEgPDF1cw0KCQkJRXh0VGFnKyBSQkUrIEZMUmVzZXQt
DQoJCURldkN0bDoJUmVwb3J0IGVycm9yczogQ29ycmVjdGFibGUtIE5vbi1GYXRhbC0gRmF0
YWwtIFVuc3VwcG9ydGVkLQ0KCQkJUmx4ZE9yZCsgRXh0VGFnLSBQaGFudEZ1bmMtIEF1eFB3
ci0gTm9Tbm9vcCsNCgkJCU1heFBheWxvYWQgMTI4IGJ5dGVzLCBNYXhSZWFkUmVxIDEyOCBi
eXRlcw0KCQlEZXZTdGE6CUNvcnJFcnItIFVuY29yckVyci0gRmF0YWxFcnItIFVuc3VwcFJl
cS0gQXV4UHdyLSBUcmFuc1BlbmQtDQoJCUxua0NhcDoJUG9ydCAjNSwgU3BlZWQgMi41R1Qv
cywgV2lkdGggeDEsIEFTUE0gTDBzIEwxLCBMYXRlbmN5IEwwIDwxdXMsIEwxIDw4dXMNCgkJ
CUNsb2NrUE0tIFN1cnByaXNlLSBMTEFjdFJlcCsgQndOb3QrDQoJCUxua0N0bDoJQVNQTSBE
aXNhYmxlZDsgUkNCIDY0IGJ5dGVzIERpc2FibGVkLSBSZXRyYWluLSBDb21tQ2xrLQ0KCQkJ
RXh0U3luY2gtIENsb2NrUE0tIEF1dFdpZERpcy0gQldJbnQtIEF1dEJXSW50LQ0KCQlMbmtT
dGE6CVNwZWVkIDIuNUdUL3MsIFdpZHRoIHgxLCBUckVyci0gVHJhaW4tIFNsb3RDbGsrIERM
QWN0aXZlKyBCV01nbXQrIEFCV01nbXQtDQoJCVNsdENhcDoJQXR0bkJ0bi0gUHdyQ3RybC0g
TVJMLSBBdHRuSW5kLSBQd3JJbmQtIEhvdFBsdWctIFN1cnByaXNlLQ0KCQkJU2xvdCAjMiwg
UG93ZXJMaW1pdCA3NS4wMDBXOyBJbnRlcmxvY2stIE5vQ29tcGwrDQoJCVNsdEN0bDoJRW5h
YmxlOiBBdHRuQnRuLSBQd3JGbHQtIE1STC0gUHJlc0RldC0gQ21kQ3BsdC0gSFBJcnEtIExp
bmtDaGctDQoJCQlDb250cm9sOiBBdHRuSW5kIFVua25vd24sIFB3ckluZCBVbmtub3duLCBQ
b3dlci0gSW50ZXJsb2NrLQ0KCQlTbHRTdGE6CVN0YXR1czogQXR0bkJ0bi0gUG93ZXJGbHQt
IE1STC0gQ21kQ3BsdC0gUHJlc0RldCsgSW50ZXJsb2NrLQ0KCQkJQ2hhbmdlZDogTVJMLSBQ
cmVzRGV0KyBMaW5rU3RhdGUrDQoJCVJvb3RDdGw6IEVyckNvcnJlY3RhYmxlLSBFcnJOb24t
RmF0YWwtIEVyckZhdGFsLSBQTUVJbnRFbmEtIENSU1Zpc2libGUtDQoJCVJvb3RDYXA6IENS
U1Zpc2libGUtDQoJCVJvb3RTdGE6IFBNRSBSZXFJRCAwMDAwLCBQTUVTdGF0dXMtIFBNRVBl
bmRpbmctDQoJCURldkNhcDI6IENvbXBsZXRpb24gVGltZW91dDogUmFuZ2UgQUJDRCwgVGlt
ZW91dERpcysgQVJJRndkKw0KCQlEZXZDdGwyOiBDb21wbGV0aW9uIFRpbWVvdXQ6IDY1bXMg
dG8gMjEwbXMsIFRpbWVvdXREaXMtIEFSSUZ3ZC0NCgkJTG5rQ3RsMjogVGFyZ2V0IExpbmsg
U3BlZWQ6IDIuNUdUL3MsIEVudGVyQ29tcGxpYW5jZS0gU3BlZWREaXMtLCBTZWxlY3RhYmxl
IERlLWVtcGhhc2lzOiAtNmRCDQoJCQkgVHJhbnNtaXQgTWFyZ2luOiBOb3JtYWwgT3BlcmF0
aW5nIFJhbmdlLCBFbnRlck1vZGlmaWVkQ29tcGxpYW5jZS0gQ29tcGxpYW5jZVNPUy0NCgkJ
CSBDb21wbGlhbmNlIERlLWVtcGhhc2lzOiAtNmRCDQoJCUxua1N0YTI6IEN1cnJlbnQgRGUt
ZW1waGFzaXMgTGV2ZWw6IC02ZEINCglDYXBhYmlsaXRpZXM6IFthMF0gTVNJOiBFbmFibGUr
IENvdW50PTEvMSBNYXNrYWJsZS0gNjRiaXQtDQoJCUFkZHJlc3M6IGZlZTNmMDBjICBEYXRh
OiA0MTcxDQoJQ2FwYWJpbGl0aWVzOiBbYjBdIFN1YnN5c3RlbTogQVRJIFRlY2hub2xvZ2ll
cyBJbmMgRGV2aWNlIFsxMDAyOjVhMTFdDQoJQ2FwYWJpbGl0aWVzOiBbYjhdIEh5cGVyVHJh
bnNwb3J0OiBNU0kgTWFwcGluZyBFbmFibGUrIEZpeGVkKw0KCUNhcGFiaWxpdGllczogWzEw
MCB2MV0gVmVuZG9yIFNwZWNpZmljIEluZm9ybWF0aW9uOiBJRD0wMDAxIFJldj0xIExlbj0w
MTAgPD8+DQoJQ2FwYWJpbGl0aWVzOiBbMTkwIHYxXSBBY2Nlc3MgQ29udHJvbCBTZXJ2aWNl
cw0KCQlBQ1NDYXA6CVNyY1ZhbGlkKyBUcmFuc0JsaysgUmVxUmVkaXIrIENtcGx0UmVkaXIr
IFVwc3RyZWFtRndkKyBFZ3Jlc3NDdHJsLSBEaXJlY3RUcmFucysNCgkJQUNTQ3RsOglTcmNW
YWxpZCsgVHJhbnNCbGstIFJlcVJlZGlyKyBDbXBsdFJlZGlyKyBVcHN0cmVhbUZ3ZCsgRWdy
ZXNzQ3RybC0gRGlyZWN0VHJhbnMtDQoJS2VybmVsIGRyaXZlciBpbiB1c2U6IHBjaWVwb3J0
DQoNCjAwOjBiLjAgUENJIGJyaWRnZSBbMDYwNF06IEFUSSBUZWNobm9sb2dpZXMgSW5jIFJE
ODkwIFBDSSB0byBQQ0kgYnJpZGdlIChOQi1TQiBsaW5rKSBbMTAwMjo1YTFmXSAocHJvZy1p
ZiAwMCBbTm9ybWFsIGRlY29kZV0pDQoJQ29udHJvbDogSS9PKyBNZW0rIEJ1c01hc3Rlcisg
U3BlY0N5Y2xlLSBNZW1XSU5WLSBWR0FTbm9vcC0gUGFyRXJyLSBTdGVwcGluZy0gU0VSUisg
RmFzdEIyQi0gRGlzSU5UeCsNCglTdGF0dXM6IENhcCsgNjZNSHotIFVERi0gRmFzdEIyQi0g
UGFyRXJyLSBERVZTRUw9ZmFzdCA+VEFib3J0LSA8VEFib3J0LSA8TUFib3J0LSA+U0VSUi0g
PFBFUlItIElOVHgtDQoJTGF0ZW5jeTogMCwgQ2FjaGUgTGluZSBTaXplOiA2NCBieXRlcw0K
CUJ1czogcHJpbWFyeT0wMCwgc2Vjb25kYXJ5PTA2LCBzdWJvcmRpbmF0ZT0wNiwgc2VjLWxh
dGVuY3k9MA0KCUkvTyBiZWhpbmQgYnJpZGdlOiAwMDAwYjAwMC0wMDAwYmZmZg0KCU1lbW9y
eSBiZWhpbmQgYnJpZGdlOiBmOTkwMDAwMC1mOTlmZmZmZg0KCVByZWZldGNoYWJsZSBtZW1v
cnkgYmVoaW5kIGJyaWRnZTogMDAwMDAwMDBiMDAwMDAwMC0wMDAwMDAwMGJmZmZmZmZmDQoJ
U2Vjb25kYXJ5IHN0YXR1czogNjZNSHotIEZhc3RCMkItIFBhckVyci0gREVWU0VMPWZhc3Qg
PlRBYm9ydC0gPFRBYm9ydC0gPE1BYm9ydC0gPFNFUlItIDxQRVJSLQ0KCUJyaWRnZUN0bDog
UGFyaXR5KyBTRVJSKyBOb0lTQSsgVkdBLSBNQWJvcnQtID5SZXNldC0gRmFzdEIyQi0NCgkJ
UHJpRGlzY1Rtci0gU2VjRGlzY1Rtci0gRGlzY1RtclN0YXQtIERpc2NUbXJTRVJSRW4tDQoJ
Q2FwYWJpbGl0aWVzOiBbNTBdIFBvd2VyIE1hbmFnZW1lbnQgdmVyc2lvbiAzDQoJCUZsYWdz
OiBQTUVDbGstIERTSS0gRDEtIEQyLSBBdXhDdXJyZW50PTBtQSBQTUUoRDArLEQxLSxEMi0s
RDNob3QrLEQzY29sZCspDQoJCVN0YXR1czogRDAgTm9Tb2Z0UnN0LSBQTUUtRW5hYmxlLSBE
U2VsPTAgRFNjYWxlPTAgUE1FLQ0KCUNhcGFiaWxpdGllczogWzU4XSBFeHByZXNzICh2Mikg
Um9vdCBQb3J0IChTbG90KyksIE1TSSAwMA0KCQlEZXZDYXA6CU1heFBheWxvYWQgMTI4IGJ5
dGVzLCBQaGFudEZ1bmMgMCwgTGF0ZW5jeSBMMHMgPDY0bnMsIEwxIDwxdXMNCgkJCUV4dFRh
ZysgUkJFKyBGTFJlc2V0LQ0KCQlEZXZDdGw6CVJlcG9ydCBlcnJvcnM6IENvcnJlY3RhYmxl
LSBOb24tRmF0YWwtIEZhdGFsLSBVbnN1cHBvcnRlZC0NCgkJCVJseGRPcmQrIEV4dFRhZy0g
UGhhbnRGdW5jLSBBdXhQd3ItIE5vU25vb3ArDQoJCQlNYXhQYXlsb2FkIDEyOCBieXRlcywg
TWF4UmVhZFJlcSAxMjggYnl0ZXMNCgkJRGV2U3RhOglDb3JyRXJyLSBVbmNvcnJFcnItIEZh
dGFsRXJyLSBVbnN1cHBSZXEtIEF1eFB3ci0gVHJhbnNQZW5kLQ0KCQlMbmtDYXA6CVBvcnQg
IzAsIFNwZWVkIDVHVC9zLCBXaWR0aCB4OCwgQVNQTSBMMHMgTDEsIExhdGVuY3kgTDAgPDF1
cywgTDEgPDh1cw0KCQkJQ2xvY2tQTS0gU3VycHJpc2UtIExMQWN0UmVwKyBCd05vdCsNCgkJ
TG5rQ3RsOglBU1BNIERpc2FibGVkOyBSQ0IgNjQgYnl0ZXMgRGlzYWJsZWQtIFJldHJhaW4t
IENvbW1DbGsrDQoJCQlFeHRTeW5jaC0gQ2xvY2tQTS0gQXV0V2lkRGlzLSBCV0ludC0gQXV0
QldJbnQtDQoJCUxua1N0YToJU3BlZWQgMi41R1QvcywgV2lkdGggeDEsIFRyRXJyLSBUcmFp
bi0gU2xvdENsaysgRExBY3RpdmUrIEJXTWdtdCsgQUJXTWdtdC0NCgkJU2x0Q2FwOglBdHRu
QnRuLSBQd3JDdHJsLSBNUkwtIEF0dG5JbmQtIFB3ckluZC0gSG90UGx1Zy0gU3VycHJpc2Ut
DQoJCQlTbG90ICM1LCBQb3dlckxpbWl0IDMxLjAwMFc7IEludGVybG9jay0gTm9Db21wbCsN
CgkJU2x0Q3RsOglFbmFibGU6IEF0dG5CdG4tIFB3ckZsdC0gTVJMLSBQcmVzRGV0LSBDbWRD
cGx0LSBIUElycS0gTGlua0NoZy0NCgkJCUNvbnRyb2w6IEF0dG5JbmQgVW5rbm93biwgUHdy
SW5kIFVua25vd24sIFBvd2VyLSBJbnRlcmxvY2stDQoJCVNsdFN0YToJU3RhdHVzOiBBdHRu
QnRuLSBQb3dlckZsdC0gTVJMLSBDbWRDcGx0LSBQcmVzRGV0KyBJbnRlcmxvY2stDQoJCQlD
aGFuZ2VkOiBNUkwtIFByZXNEZXQrIExpbmtTdGF0ZSsNCgkJUm9vdEN0bDogRXJyQ29ycmVj
dGFibGUtIEVyck5vbi1GYXRhbC0gRXJyRmF0YWwtIFBNRUludEVuYS0gQ1JTVmlzaWJsZS0N
CgkJUm9vdENhcDogQ1JTVmlzaWJsZS0NCgkJUm9vdFN0YTogUE1FIFJlcUlEIDAwMDAsIFBN
RVN0YXR1cy0gUE1FUGVuZGluZy0NCgkJRGV2Q2FwMjogQ29tcGxldGlvbiBUaW1lb3V0OiBS
YW5nZSBBQkNELCBUaW1lb3V0RGlzKyBBUklGd2QrDQoJCURldkN0bDI6IENvbXBsZXRpb24g
VGltZW91dDogNjVtcyB0byAyMTBtcywgVGltZW91dERpcy0gQVJJRndkLQ0KCQlMbmtDdGwy
OiBUYXJnZXQgTGluayBTcGVlZDogNUdUL3MsIEVudGVyQ29tcGxpYW5jZS0gU3BlZWREaXMt
LCBTZWxlY3RhYmxlIERlLWVtcGhhc2lzOiAtMy41ZEINCgkJCSBUcmFuc21pdCBNYXJnaW46
IE5vcm1hbCBPcGVyYXRpbmcgUmFuZ2UsIEVudGVyTW9kaWZpZWRDb21wbGlhbmNlLSBDb21w
bGlhbmNlU09TLQ0KCQkJIENvbXBsaWFuY2UgRGUtZW1waGFzaXM6IC02ZEINCgkJTG5rU3Rh
MjogQ3VycmVudCBEZS1lbXBoYXNpcyBMZXZlbDogLTMuNWRCDQoJQ2FwYWJpbGl0aWVzOiBb
YTBdIE1TSTogRW5hYmxlKyBDb3VudD0xLzEgTWFza2FibGUtIDY0Yml0LQ0KCQlBZGRyZXNz
OiBmZWUzZjAwYyAgRGF0YTogNDE3OQ0KCUNhcGFiaWxpdGllczogW2IwXSBTdWJzeXN0ZW06
IEFUSSBUZWNobm9sb2dpZXMgSW5jIERldmljZSBbMTAwMjo1YTExXQ0KCUNhcGFiaWxpdGll
czogW2I4XSBIeXBlclRyYW5zcG9ydDogTVNJIE1hcHBpbmcgRW5hYmxlKyBGaXhlZCsNCglD
YXBhYmlsaXRpZXM6IFsxMDAgdjFdIFZlbmRvciBTcGVjaWZpYyBJbmZvcm1hdGlvbjogSUQ9
MDAwMSBSZXY9MSBMZW49MDEwIDw/Pg0KCUNhcGFiaWxpdGllczogWzE5MCB2MV0gQWNjZXNz
IENvbnRyb2wgU2VydmljZXMNCgkJQUNTQ2FwOglTcmNWYWxpZCsgVHJhbnNCbGsrIFJlcVJl
ZGlyKyBDbXBsdFJlZGlyKyBVcHN0cmVhbUZ3ZCsgRWdyZXNzQ3RybC0gRGlyZWN0VHJhbnMr
DQoJCUFDU0N0bDoJU3JjVmFsaWQrIFRyYW5zQmxrLSBSZXFSZWRpcisgQ21wbHRSZWRpcisg
VXBzdHJlYW1Gd2QrIEVncmVzc0N0cmwtIERpcmVjdFRyYW5zLQ0KCUtlcm5lbCBkcml2ZXIg
aW4gdXNlOiBwY2llcG9ydA0KDQowMDowYy4wIFBDSSBicmlkZ2UgWzA2MDRdOiBBVEkgVGVj
aG5vbG9naWVzIEluYyBEZXZpY2UgWzEwMDI6NWEyMF0gKHByb2ctaWYgMDAgW05vcm1hbCBk
ZWNvZGVdKQ0KCUNvbnRyb2w6IEkvTy0gTWVtKyBCdXNNYXN0ZXIrIFNwZWNDeWNsZS0gTWVt
V0lOVi0gVkdBU25vb3AtIFBhckVyci0gU3RlcHBpbmctIFNFUlIrIEZhc3RCMkItIERpc0lO
VHgrDQoJU3RhdHVzOiBDYXArIDY2TUh6LSBVREYtIEZhc3RCMkItIFBhckVyci0gREVWU0VM
PWZhc3QgPlRBYm9ydC0gPFRBYm9ydC0gPE1BYm9ydC0gPlNFUlItIDxQRVJSLSBJTlR4LQ0K
CUxhdGVuY3k6IDAsIENhY2hlIExpbmUgU2l6ZTogNjQgYnl0ZXMNCglCdXM6IHByaW1hcnk9
MDAsIHNlY29uZGFyeT0wNSwgc3Vib3JkaW5hdGU9MDUsIHNlYy1sYXRlbmN5PTANCglJL08g
YmVoaW5kIGJyaWRnZTogMDAwMGYwMDAtMDAwMDBmZmYNCglNZW1vcnkgYmVoaW5kIGJyaWRn
ZTogZjk2MDAwMDAtZjk3ZmZmZmYNCglQcmVmZXRjaGFibGUgbWVtb3J5IGJlaGluZCBicmlk
Z2U6IDAwMDAwMDAwZmZmMDAwMDAtMDAwMDAwMDAwMDBmZmZmZg0KCVNlY29uZGFyeSBzdGF0
dXM6IDY2TUh6LSBGYXN0QjJCLSBQYXJFcnItIERFVlNFTD1mYXN0ID5UQWJvcnQtIDxUQWJv
cnQtIDxNQWJvcnQrIDxTRVJSLSA8UEVSUi0NCglCcmlkZ2VDdGw6IFBhcml0eSsgU0VSUisg
Tm9JU0ErIFZHQS0gTUFib3J0LSA+UmVzZXQtIEZhc3RCMkItDQoJCVByaURpc2NUbXItIFNl
Y0Rpc2NUbXItIERpc2NUbXJTdGF0LSBEaXNjVG1yU0VSUkVuLQ0KCUNhcGFiaWxpdGllczog
WzUwXSBQb3dlciBNYW5hZ2VtZW50IHZlcnNpb24gMw0KCQlGbGFnczogUE1FQ2xrLSBEU0kt
IEQxLSBEMi0gQXV4Q3VycmVudD0wbUEgUE1FKEQwKyxEMS0sRDItLEQzaG90KyxEM2NvbGQr
KQ0KCQlTdGF0dXM6IEQwIE5vU29mdFJzdC0gUE1FLUVuYWJsZS0gRFNlbD0wIERTY2FsZT0w
IFBNRS0NCglDYXBhYmlsaXRpZXM6IFs1OF0gRXhwcmVzcyAodjIpIFJvb3QgUG9ydCAoU2xv
dCspLCBNU0kgMDANCgkJRGV2Q2FwOglNYXhQYXlsb2FkIDEyOCBieXRlcywgUGhhbnRGdW5j
IDAsIExhdGVuY3kgTDBzIDw2NG5zLCBMMSA8MXVzDQoJCQlFeHRUYWcrIFJCRSsgRkxSZXNl
dC0NCgkJRGV2Q3RsOglSZXBvcnQgZXJyb3JzOiBDb3JyZWN0YWJsZS0gTm9uLUZhdGFsLSBG
YXRhbC0gVW5zdXBwb3J0ZWQtDQoJCQlSbHhkT3JkKyBFeHRUYWctIFBoYW50RnVuYy0gQXV4
UHdyLSBOb1Nub29wKw0KCQkJTWF4UGF5bG9hZCAxMjggYnl0ZXMsIE1heFJlYWRSZXEgMTI4
IGJ5dGVzDQoJCURldlN0YToJQ29yckVyci0gVW5jb3JyRXJyLSBGYXRhbEVyci0gVW5zdXBw
UmVxLSBBdXhQd3ItIFRyYW5zUGVuZC0NCgkJTG5rQ2FwOglQb3J0ICMxLCBTcGVlZCA1R1Qv
cywgV2lkdGggeDgsIEFTUE0gTDBzIEwxLCBMYXRlbmN5IEwwIDwxdXMsIEwxIDw4dXMNCgkJ
CUNsb2NrUE0tIFN1cnByaXNlLSBMTEFjdFJlcCsgQndOb3QrDQoJCUxua0N0bDoJQVNQTSBE
aXNhYmxlZDsgUkNCIDY0IGJ5dGVzIERpc2FibGVkLSBSZXRyYWluLSBDb21tQ2xrLQ0KCQkJ
RXh0U3luY2gtIENsb2NrUE0tIEF1dFdpZERpcy0gQldJbnQtIEF1dEJXSW50LQ0KCQlMbmtT
dGE6CVNwZWVkIDIuNUdUL3MsIFdpZHRoIHgxLCBUckVyci0gVHJhaW4tIFNsb3RDbGsrIERM
QWN0aXZlKyBCV01nbXQrIEFCV01nbXQtDQoJCVNsdENhcDoJQXR0bkJ0bi0gUHdyQ3RybC0g
TVJMLSBBdHRuSW5kLSBQd3JJbmQtIEhvdFBsdWctIFN1cnByaXNlLQ0KCQkJU2xvdCAjNiwg
UG93ZXJMaW1pdCAxNC4wMDBXOyBJbnRlcmxvY2stIE5vQ29tcGwrDQoJCVNsdEN0bDoJRW5h
YmxlOiBBdHRuQnRuLSBQd3JGbHQtIE1STC0gUHJlc0RldC0gQ21kQ3BsdC0gSFBJcnEtIExp
bmtDaGctDQoJCQlDb250cm9sOiBBdHRuSW5kIFVua25vd24sIFB3ckluZCBVbmtub3duLCBQ
b3dlci0gSW50ZXJsb2NrLQ0KCQlTbHRTdGE6CVN0YXR1czogQXR0bkJ0bi0gUG93ZXJGbHQt
IE1STC0gQ21kQ3BsdC0gUHJlc0RldCsgSW50ZXJsb2NrLQ0KCQkJQ2hhbmdlZDogTVJMLSBQ
cmVzRGV0KyBMaW5rU3RhdGUrDQoJCVJvb3RDdGw6IEVyckNvcnJlY3RhYmxlLSBFcnJOb24t
RmF0YWwtIEVyckZhdGFsLSBQTUVJbnRFbmEtIENSU1Zpc2libGUtDQoJCVJvb3RDYXA6IENS
U1Zpc2libGUtDQoJCVJvb3RTdGE6IFBNRSBSZXFJRCAwMDAwLCBQTUVTdGF0dXMtIFBNRVBl
bmRpbmctDQoJCURldkNhcDI6IENvbXBsZXRpb24gVGltZW91dDogUmFuZ2UgQUJDRCwgVGlt
ZW91dERpcysgQVJJRndkKw0KCQlEZXZDdGwyOiBDb21wbGV0aW9uIFRpbWVvdXQ6IDY1bXMg
dG8gMjEwbXMsIFRpbWVvdXREaXMtIEFSSUZ3ZC0NCgkJTG5rQ3RsMjogVGFyZ2V0IExpbmsg
U3BlZWQ6IDVHVC9zLCBFbnRlckNvbXBsaWFuY2UtIFNwZWVkRGlzLSwgU2VsZWN0YWJsZSBE
ZS1lbXBoYXNpczogLTMuNWRCDQoJCQkgVHJhbnNtaXQgTWFyZ2luOiBOb3JtYWwgT3BlcmF0
aW5nIFJhbmdlLCBFbnRlck1vZGlmaWVkQ29tcGxpYW5jZS0gQ29tcGxpYW5jZVNPUy0NCgkJ
CSBDb21wbGlhbmNlIERlLWVtcGhhc2lzOiAtNmRCDQoJCUxua1N0YTI6IEN1cnJlbnQgRGUt
ZW1waGFzaXMgTGV2ZWw6IC0zLjVkQg0KCUNhcGFiaWxpdGllczogW2EwXSBNU0k6IEVuYWJs
ZSsgQ291bnQ9MS8xIE1hc2thYmxlLSA2NGJpdC0NCgkJQWRkcmVzczogZmVlM2YwMGMgIERh
dGE6IDQxODENCglDYXBhYmlsaXRpZXM6IFtiMF0gU3Vic3lzdGVtOiBBVEkgVGVjaG5vbG9n
aWVzIEluYyBEZXZpY2UgWzEwMDI6NWExMV0NCglDYXBhYmlsaXRpZXM6IFtiOF0gSHlwZXJU
cmFuc3BvcnQ6IE1TSSBNYXBwaW5nIEVuYWJsZSsgRml4ZWQrDQoJQ2FwYWJpbGl0aWVzOiBb
MTAwIHYxXSBWZW5kb3IgU3BlY2lmaWMgSW5mb3JtYXRpb246IElEPTAwMDEgUmV2PTEgTGVu
PTAxMCA8Pz4NCglDYXBhYmlsaXRpZXM6IFsxOTAgdjFdIEFjY2VzcyBDb250cm9sIFNlcnZp
Y2VzDQoJCUFDU0NhcDoJU3JjVmFsaWQrIFRyYW5zQmxrKyBSZXFSZWRpcisgQ21wbHRSZWRp
cisgVXBzdHJlYW1Gd2QrIEVncmVzc0N0cmwtIERpcmVjdFRyYW5zKw0KCQlBQ1NDdGw6CVNy
Y1ZhbGlkKyBUcmFuc0Jsay0gUmVxUmVkaXIrIENtcGx0UmVkaXIrIFVwc3RyZWFtRndkKyBF
Z3Jlc3NDdHJsLSBEaXJlY3RUcmFucy0NCglLZXJuZWwgZHJpdmVyIGluIHVzZTogcGNpZXBv
cnQNCg0KMDA6MGQuMCBQQ0kgYnJpZGdlIFswNjA0XTogQVRJIFRlY2hub2xvZ2llcyBJbmMg
UkQ4OTAgUENJIHRvIFBDSSBicmlkZ2UgKGV4dGVybmFsIGdmeDEgcG9ydCBCKSBbMTAwMjo1
YTFlXSAocHJvZy1pZiAwMCBbTm9ybWFsIGRlY29kZV0pDQoJQ29udHJvbDogSS9PLSBNZW0r
IEJ1c01hc3RlcisgU3BlY0N5Y2xlLSBNZW1XSU5WLSBWR0FTbm9vcC0gUGFyRXJyLSBTdGVw
cGluZy0gU0VSUisgRmFzdEIyQi0gRGlzSU5UeCsNCglTdGF0dXM6IENhcCsgNjZNSHotIFVE
Ri0gRmFzdEIyQi0gUGFyRXJyLSBERVZTRUw9ZmFzdCA+VEFib3J0LSA8VEFib3J0LSA8TUFi
b3J0LSA+U0VSUi0gPFBFUlItIElOVHgtDQoJTGF0ZW5jeTogMCwgQ2FjaGUgTGluZSBTaXpl
OiA2NCBieXRlcw0KCUJ1czogcHJpbWFyeT0wMCwgc2Vjb25kYXJ5PTA0LCBzdWJvcmRpbmF0
ZT0wNCwgc2VjLWxhdGVuY3k9MA0KCUkvTyBiZWhpbmQgYnJpZGdlOiAwMDAwZjAwMC0wMDAw
MGZmZg0KCU1lbW9yeSBiZWhpbmQgYnJpZGdlOiBmOTUwMDAwMC1mOTVmZmZmZg0KCVByZWZl
dGNoYWJsZSBtZW1vcnkgYmVoaW5kIGJyaWRnZTogMDAwMDAwMDBmZmYwMDAwMC0wMDAwMDAw
MDAwMGZmZmZmDQoJU2Vjb25kYXJ5IHN0YXR1czogNjZNSHotIEZhc3RCMkItIFBhckVyci0g
REVWU0VMPWZhc3QgPlRBYm9ydC0gPFRBYm9ydC0gPE1BYm9ydC0gPFNFUlItIDxQRVJSLQ0K
CUJyaWRnZUN0bDogUGFyaXR5KyBTRVJSKyBOb0lTQSsgVkdBLSBNQWJvcnQtID5SZXNldC0g
RmFzdEIyQi0NCgkJUHJpRGlzY1Rtci0gU2VjRGlzY1Rtci0gRGlzY1RtclN0YXQtIERpc2NU
bXJTRVJSRW4tDQoJQ2FwYWJpbGl0aWVzOiBbNTBdIFBvd2VyIE1hbmFnZW1lbnQgdmVyc2lv
biAzDQoJCUZsYWdzOiBQTUVDbGstIERTSS0gRDEtIEQyLSBBdXhDdXJyZW50PTBtQSBQTUUo
RDArLEQxLSxEMi0sRDNob3QrLEQzY29sZCspDQoJCVN0YXR1czogRDAgTm9Tb2Z0UnN0LSBQ
TUUtRW5hYmxlLSBEU2VsPTAgRFNjYWxlPTAgUE1FLQ0KCUNhcGFiaWxpdGllczogWzU4XSBF
eHByZXNzICh2MikgUm9vdCBQb3J0IChTbG90KyksIE1TSSAwMA0KCQlEZXZDYXA6CU1heFBh
eWxvYWQgMTI4IGJ5dGVzLCBQaGFudEZ1bmMgMCwgTGF0ZW5jeSBMMHMgPDY0bnMsIEwxIDwx
dXMNCgkJCUV4dFRhZysgUkJFKyBGTFJlc2V0LQ0KCQlEZXZDdGw6CVJlcG9ydCBlcnJvcnM6
IENvcnJlY3RhYmxlLSBOb24tRmF0YWwtIEZhdGFsLSBVbnN1cHBvcnRlZC0NCgkJCVJseGRP
cmQrIEV4dFRhZy0gUGhhbnRGdW5jLSBBdXhQd3ItIE5vU25vb3ArDQoJCQlNYXhQYXlsb2Fk
IDEyOCBieXRlcywgTWF4UmVhZFJlcSAxMjggYnl0ZXMNCgkJRGV2U3RhOglDb3JyRXJyLSBV
bmNvcnJFcnItIEZhdGFsRXJyLSBVbnN1cHBSZXEtIEF1eFB3ci0gVHJhbnNQZW5kLQ0KCQlM
bmtDYXA6CVBvcnQgIzAsIFNwZWVkIDVHVC9zLCBXaWR0aCB4NCwgQVNQTSBMMHMgTDEsIExh
dGVuY3kgTDAgPDF1cywgTDEgPDh1cw0KCQkJQ2xvY2tQTS0gU3VycHJpc2UtIExMQWN0UmVw
KyBCd05vdCsNCgkJTG5rQ3RsOglBU1BNIERpc2FibGVkOyBSQ0IgNjQgYnl0ZXMgRGlzYWJs
ZWQtIFJldHJhaW4tIENvbW1DbGstDQoJCQlFeHRTeW5jaC0gQ2xvY2tQTS0gQXV0V2lkRGlz
LSBCV0ludC0gQXV0QldJbnQtDQoJCUxua1N0YToJU3BlZWQgMi41R1QvcywgV2lkdGggeDEs
IFRyRXJyLSBUcmFpbi0gU2xvdENsaysgRExBY3RpdmUrIEJXTWdtdCsgQUJXTWdtdC0NCgkJ
U2x0Q2FwOglBdHRuQnRuLSBQd3JDdHJsLSBNUkwtIEF0dG5JbmQtIFB3ckluZC0gSG90UGx1
Zy0gU3VycHJpc2UtDQoJCQlTbG90ICM0LCBQb3dlckxpbWl0IDc1LjAwMFc7IEludGVybG9j
ay0gTm9Db21wbCsNCgkJU2x0Q3RsOglFbmFibGU6IEF0dG5CdG4tIFB3ckZsdC0gTVJMLSBQ
cmVzRGV0LSBDbWRDcGx0LSBIUElycS0gTGlua0NoZy0NCgkJCUNvbnRyb2w6IEF0dG5JbmQg
VW5rbm93biwgUHdySW5kIFVua25vd24sIFBvd2VyLSBJbnRlcmxvY2stDQoJCVNsdFN0YToJ
U3RhdHVzOiBBdHRuQnRuLSBQb3dlckZsdC0gTVJMLSBDbWRDcGx0LSBQcmVzRGV0KyBJbnRl
cmxvY2stDQoJCQlDaGFuZ2VkOiBNUkwtIFByZXNEZXQrIExpbmtTdGF0ZSsNCgkJUm9vdEN0
bDogRXJyQ29ycmVjdGFibGUtIEVyck5vbi1GYXRhbC0gRXJyRmF0YWwtIFBNRUludEVuYS0g
Q1JTVmlzaWJsZS0NCgkJUm9vdENhcDogQ1JTVmlzaWJsZS0NCgkJUm9vdFN0YTogUE1FIFJl
cUlEIDAwMDAsIFBNRVN0YXR1cy0gUE1FUGVuZGluZy0NCgkJRGV2Q2FwMjogQ29tcGxldGlv
biBUaW1lb3V0OiBSYW5nZSBBQkNELCBUaW1lb3V0RGlzKyBBUklGd2QrDQoJCURldkN0bDI6
IENvbXBsZXRpb24gVGltZW91dDogNjVtcyB0byAyMTBtcywgVGltZW91dERpcy0gQVJJRndk
LQ0KCQlMbmtDdGwyOiBUYXJnZXQgTGluayBTcGVlZDogNUdUL3MsIEVudGVyQ29tcGxpYW5j
ZS0gU3BlZWREaXMtLCBTZWxlY3RhYmxlIERlLWVtcGhhc2lzOiAtMy41ZEINCgkJCSBUcmFu
c21pdCBNYXJnaW46IE5vcm1hbCBPcGVyYXRpbmcgUmFuZ2UsIEVudGVyTW9kaWZpZWRDb21w
bGlhbmNlLSBDb21wbGlhbmNlU09TLQ0KCQkJIENvbXBsaWFuY2UgRGUtZW1waGFzaXM6IC02
ZEINCgkJTG5rU3RhMjogQ3VycmVudCBEZS1lbXBoYXNpcyBMZXZlbDogLTMuNWRCDQoJQ2Fw
YWJpbGl0aWVzOiBbYTBdIE1TSTogRW5hYmxlKyBDb3VudD0xLzEgTWFza2FibGUtIDY0Yml0
LQ0KCQlBZGRyZXNzOiBmZWUzZjAwYyAgRGF0YTogNDE4OQ0KCUNhcGFiaWxpdGllczogW2Iw
XSBTdWJzeXN0ZW06IEFUSSBUZWNobm9sb2dpZXMgSW5jIERldmljZSBbMTAwMjo1YTExXQ0K
CUNhcGFiaWxpdGllczogW2I4XSBIeXBlclRyYW5zcG9ydDogTVNJIE1hcHBpbmcgRW5hYmxl
KyBGaXhlZCsNCglDYXBhYmlsaXRpZXM6IFsxMDAgdjFdIFZlbmRvciBTcGVjaWZpYyBJbmZv
cm1hdGlvbjogSUQ9MDAwMSBSZXY9MSBMZW49MDEwIDw/Pg0KCUNhcGFiaWxpdGllczogWzE5
MCB2MV0gQWNjZXNzIENvbnRyb2wgU2VydmljZXMNCgkJQUNTQ2FwOglTcmNWYWxpZCsgVHJh
bnNCbGsrIFJlcVJlZGlyKyBDbXBsdFJlZGlyKyBVcHN0cmVhbUZ3ZCsgRWdyZXNzQ3RybC0g
RGlyZWN0VHJhbnMrDQoJCUFDU0N0bDoJU3JjVmFsaWQrIFRyYW5zQmxrLSBSZXFSZWRpcisg
Q21wbHRSZWRpcisgVXBzdHJlYW1Gd2QrIEVncmVzc0N0cmwtIERpcmVjdFRyYW5zLQ0KCUtl
cm5lbCBkcml2ZXIgaW4gdXNlOiBwY2llcG9ydA0KDQowMDoxMS4wIFNBVEEgY29udHJvbGxl
ciBbMDEwNl06IEFUSSBUZWNobm9sb2dpZXMgSW5jIFNCN3gwL1NCOHgwL1NCOXgwIFNBVEEg
Q29udHJvbGxlciBbQUhDSSBtb2RlXSBbMTAwMjo0MzkxXSAocmV2IDQwKSAocHJvZy1pZiAw
MSBbQUhDSSAxLjBdKQ0KCVN1YnN5c3RlbTogTWljcm8tU3RhciBJbnRlcm5hdGlvbmFsIENv
LiwgTHRkLiBEZXZpY2UgWzE0NjI6NzY0MF0NCglDb250cm9sOiBJL08rIE1lbSsgQnVzTWFz
dGVyKyBTcGVjQ3ljbGUtIE1lbVdJTlYtIFZHQVNub29wLSBQYXJFcnItIFN0ZXBwaW5nLSBT
RVJSKyBGYXN0QjJCLSBEaXNJTlR4Kw0KCVN0YXR1czogQ2FwKyA2Nk1IeisgVURGLSBGYXN0
QjJCLSBQYXJFcnItIERFVlNFTD1tZWRpdW0gPlRBYm9ydC0gPFRBYm9ydC0gPE1BYm9ydC0g
PlNFUlItIDxQRVJSLSBJTlR4LQ0KCUxhdGVuY3k6IDY0LCBDYWNoZSBMaW5lIFNpemU6IDY0
IGJ5dGVzDQoJSW50ZXJydXB0OiBwaW4gQSByb3V0ZWQgdG8gSVJRIDEyMA0KCVJlZ2lvbiAw
OiBJL08gcG9ydHMgYXQgNzAwMCBbc2l6ZT04XQ0KCVJlZ2lvbiAxOiBJL08gcG9ydHMgYXQg
NjAwMCBbc2l6ZT00XQ0KCVJlZ2lvbiAyOiBJL08gcG9ydHMgYXQgNTAwMCBbc2l6ZT04XQ0K
CVJlZ2lvbiAzOiBJL08gcG9ydHMgYXQgMzAwMCBbc2l6ZT00XQ0KCVJlZ2lvbiA0OiBJL08g
cG9ydHMgYXQgMjAwMCBbc2l6ZT0xNl0NCglSZWdpb24gNTogTWVtb3J5IGF0IGY5M2ZmMDAw
ICgzMi1iaXQsIG5vbi1wcmVmZXRjaGFibGUpIFtzaXplPTFLXQ0KCUNhcGFiaWxpdGllczog
WzUwXSBNU0k6IEVuYWJsZSsgQ291bnQ9MS84IE1hc2thYmxlLSA2NGJpdCsNCgkJQWRkcmVz
czogMDAwMDAwMDBmZWUwMjAwYyAgRGF0YTogNDFiOQ0KCUNhcGFiaWxpdGllczogWzcwXSBT
QVRBIEhCQSB2MS4wIEluQ2ZnU3BhY2UNCglDYXBhYmlsaXRpZXM6IFthNF0gUENJIEFkdmFu
Y2VkIEZlYXR1cmVzDQoJCUFGQ2FwOiBUUCsgRkxSKw0KCQlBRkN0cmw6IEZMUi0NCgkJQUZT
dGF0dXM6IFRQKw0KCUtlcm5lbCBkcml2ZXIgaW4gdXNlOiBhaGNpDQoNCjAwOjEyLjAgVVNC
IGNvbnRyb2xsZXIgWzBjMDNdOiBBVEkgVGVjaG5vbG9naWVzIEluYyBTQjd4MC9TQjh4MC9T
Qjl4MCBVU0IgT0hDSTAgQ29udHJvbGxlciBbMTAwMjo0Mzk3XSAocHJvZy1pZiAxMCBbT0hD
SV0pDQoJU3Vic3lzdGVtOiBNaWNyby1TdGFyIEludGVybmF0aW9uYWwgQ28uLCBMdGQuIERl
dmljZSBbMTQ2Mjo3NjQwXQ0KCUNvbnRyb2w6IEkvTysgTWVtKyBCdXNNYXN0ZXIrIFNwZWND
eWNsZS0gTWVtV0lOVisgVkdBU25vb3AtIFBhckVyci0gU3RlcHBpbmctIFNFUlIrIEZhc3RC
MkItIERpc0lOVHgtDQoJU3RhdHVzOiBDYXAtIDY2TUh6KyBVREYtIEZhc3RCMkIrIFBhckVy
ci0gREVWU0VMPW1lZGl1bSA+VEFib3J0LSA8VEFib3J0LSA8TUFib3J0LSA+U0VSUi0gPFBF
UlItIElOVHgtDQoJTGF0ZW5jeTogNjQsIENhY2hlIExpbmUgU2l6ZTogNjQgYnl0ZXMNCglJ
bnRlcnJ1cHQ6IHBpbiBBIHJvdXRlZCB0byBJUlEgMTgNCglSZWdpb24gMDogTWVtb3J5IGF0
IGY5M2ZiMDAwICgzMi1iaXQsIG5vbi1wcmVmZXRjaGFibGUpIFtzaXplPTRLXQ0KCUtlcm5l
bCBkcml2ZXIgaW4gdXNlOiBvaGNpX2hjZA0KDQowMDoxMi4yIFVTQiBjb250cm9sbGVyIFsw
YzAzXTogQVRJIFRlY2hub2xvZ2llcyBJbmMgU0I3eDAvU0I4eDAvU0I5eDAgVVNCIEVIQ0kg
Q29udHJvbGxlciBbMTAwMjo0Mzk2XSAocHJvZy1pZiAyMCBbRUhDSV0pDQoJU3Vic3lzdGVt
OiBNaWNyby1TdGFyIEludGVybmF0aW9uYWwgQ28uLCBMdGQuIERldmljZSBbMTQ2Mjo3NjQw
XQ0KCUNvbnRyb2w6IEkvTy0gTWVtKyBCdXNNYXN0ZXIrIFNwZWNDeWNsZS0gTWVtV0lOVisg
VkdBU25vb3AtIFBhckVyci0gU3RlcHBpbmctIFNFUlIrIEZhc3RCMkItIERpc0lOVHgtDQoJ
U3RhdHVzOiBDYXArIDY2TUh6KyBVREYtIEZhc3RCMkIrIFBhckVyci0gREVWU0VMPW1lZGl1
bSA+VEFib3J0LSA8VEFib3J0LSA8TUFib3J0LSA+U0VSUi0gPFBFUlItIElOVHgtDQoJTGF0
ZW5jeTogNjQsIENhY2hlIExpbmUgU2l6ZTogNjQgYnl0ZXMNCglJbnRlcnJ1cHQ6IHBpbiBC
IHJvdXRlZCB0byBJUlEgMTcNCglSZWdpb24gMDogTWVtb3J5IGF0IGY5M2ZmNDAwICgzMi1i
aXQsIG5vbi1wcmVmZXRjaGFibGUpIFtzaXplPTI1Nl0NCglDYXBhYmlsaXRpZXM6IFtjMF0g
UG93ZXIgTWFuYWdlbWVudCB2ZXJzaW9uIDINCgkJRmxhZ3M6IFBNRUNsay0gRFNJLSBEMSsg
RDIrIEF1eEN1cnJlbnQ9MG1BIFBNRShEMCssRDErLEQyKyxEM2hvdCssRDNjb2xkLSkNCgkJ
U3RhdHVzOiBEMCBOb1NvZnRSc3QtIFBNRS1FbmFibGUtIERTZWw9MCBEU2NhbGU9MCBQTUUt
DQoJCUJyaWRnZTogUE0tIEIzKw0KCUNhcGFiaWxpdGllczogW2U0XSBEZWJ1ZyBwb3J0OiBC
QVI9MSBvZmZzZXQ9MDBlMA0KCUtlcm5lbCBkcml2ZXIgaW4gdXNlOiBlaGNpX2hjZA0KDQow
MDoxMy4wIFVTQiBjb250cm9sbGVyIFswYzAzXTogQVRJIFRlY2hub2xvZ2llcyBJbmMgU0I3
eDAvU0I4eDAvU0I5eDAgVVNCIE9IQ0kwIENvbnRyb2xsZXIgWzEwMDI6NDM5N10gKHByb2ct
aWYgMTAgW09IQ0ldKQ0KCVN1YnN5c3RlbTogTWljcm8tU3RhciBJbnRlcm5hdGlvbmFsIENv
LiwgTHRkLiBEZXZpY2UgWzE0NjI6NzY0MF0NCglDb250cm9sOiBJL08rIE1lbSsgQnVzTWFz
dGVyKyBTcGVjQ3ljbGUtIE1lbVdJTlYrIFZHQVNub29wLSBQYXJFcnItIFN0ZXBwaW5nLSBT
RVJSKyBGYXN0QjJCLSBEaXNJTlR4LQ0KCVN0YXR1czogQ2FwLSA2Nk1IeisgVURGLSBGYXN0
QjJCKyBQYXJFcnItIERFVlNFTD1tZWRpdW0gPlRBYm9ydC0gPFRBYm9ydC0gPE1BYm9ydC0g
PlNFUlItIDxQRVJSLSBJTlR4LQ0KCUxhdGVuY3k6IDY0LCBDYWNoZSBMaW5lIFNpemU6IDY0
IGJ5dGVzDQoJSW50ZXJydXB0OiBwaW4gQSByb3V0ZWQgdG8gSVJRIDE4DQoJUmVnaW9uIDA6
IE1lbW9yeSBhdCBmOTNmYzAwMCAoMzItYml0LCBub24tcHJlZmV0Y2hhYmxlKSBbc2l6ZT00
S10NCglLZXJuZWwgZHJpdmVyIGluIHVzZTogb2hjaV9oY2QNCg0KMDA6MTMuMiBVU0IgY29u
dHJvbGxlciBbMGMwM106IEFUSSBUZWNobm9sb2dpZXMgSW5jIFNCN3gwL1NCOHgwL1NCOXgw
IFVTQiBFSENJIENvbnRyb2xsZXIgWzEwMDI6NDM5Nl0gKHByb2ctaWYgMjAgW0VIQ0ldKQ0K
CVN1YnN5c3RlbTogTWljcm8tU3RhciBJbnRlcm5hdGlvbmFsIENvLiwgTHRkLiBEZXZpY2Ug
WzE0NjI6NzY0MF0NCglDb250cm9sOiBJL08tIE1lbSsgQnVzTWFzdGVyKyBTcGVjQ3ljbGUt
IE1lbVdJTlYrIFZHQVNub29wLSBQYXJFcnItIFN0ZXBwaW5nLSBTRVJSKyBGYXN0QjJCLSBE
aXNJTlR4LQ0KCVN0YXR1czogQ2FwKyA2Nk1IeisgVURGLSBGYXN0QjJCKyBQYXJFcnItIERF
VlNFTD1tZWRpdW0gPlRBYm9ydC0gPFRBYm9ydC0gPE1BYm9ydC0gPlNFUlItIDxQRVJSLSBJ
TlR4LQ0KCUxhdGVuY3k6IDY0LCBDYWNoZSBMaW5lIFNpemU6IDY0IGJ5dGVzDQoJSW50ZXJy
dXB0OiBwaW4gQiByb3V0ZWQgdG8gSVJRIDE3DQoJUmVnaW9uIDA6IE1lbW9yeSBhdCBmOTNm
ZjgwMCAoMzItYml0LCBub24tcHJlZmV0Y2hhYmxlKSBbc2l6ZT0yNTZdDQoJQ2FwYWJpbGl0
aWVzOiBbYzBdIFBvd2VyIE1hbmFnZW1lbnQgdmVyc2lvbiAyDQoJCUZsYWdzOiBQTUVDbGst
IERTSS0gRDErIEQyKyBBdXhDdXJyZW50PTBtQSBQTUUoRDArLEQxKyxEMissRDNob3QrLEQz
Y29sZC0pDQoJCVN0YXR1czogRDAgTm9Tb2Z0UnN0LSBQTUUtRW5hYmxlLSBEU2VsPTAgRFNj
YWxlPTAgUE1FLQ0KCQlCcmlkZ2U6IFBNLSBCMysNCglDYXBhYmlsaXRpZXM6IFtlNF0gRGVi
dWcgcG9ydDogQkFSPTEgb2Zmc2V0PTAwZTANCglLZXJuZWwgZHJpdmVyIGluIHVzZTogZWhj
aV9oY2QNCg0KMDA6MTQuMCBTTUJ1cyBbMGMwNV06IEFUSSBUZWNobm9sb2dpZXMgSW5jIFNC
eDAwIFNNQnVzIENvbnRyb2xsZXIgWzEwMDI6NDM4NV0gKHJldiA0MSkNCglDb250cm9sOiBJ
L08rIE1lbSsgQnVzTWFzdGVyLSBTcGVjQ3ljbGUtIE1lbVdJTlYtIFZHQVNub29wLSBQYXJF
cnItIFN0ZXBwaW5nLSBTRVJSLSBGYXN0QjJCLSBEaXNJTlR4Kw0KCVN0YXR1czogQ2FwLSA2
Nk1IeisgVURGLSBGYXN0QjJCLSBQYXJFcnItIERFVlNFTD1tZWRpdW0gPlRBYm9ydC0gPFRB
Ym9ydC0gPE1BYm9ydC0gPlNFUlItIDxQRVJSLSBJTlR4LQ0KDQowMDoxNC4zIElTQSBicmlk
Z2UgWzA2MDFdOiBBVEkgVGVjaG5vbG9naWVzIEluYyBTQjd4MC9TQjh4MC9TQjl4MCBMUEMg
aG9zdCBjb250cm9sbGVyIFsxMDAyOjQzOWRdIChyZXYgNDApDQoJU3Vic3lzdGVtOiBNaWNy
by1TdGFyIEludGVybmF0aW9uYWwgQ28uLCBMdGQuIERldmljZSBbMTQ2Mjo3NjQwXQ0KCUNv
bnRyb2w6IEkvTysgTWVtKyBCdXNNYXN0ZXIrIFNwZWNDeWNsZSsgTWVtV0lOVi0gVkdBU25v
b3AtIFBhckVyci0gU3RlcHBpbmctIFNFUlItIEZhc3RCMkItIERpc0lOVHgtDQoJU3RhdHVz
OiBDYXAtIDY2TUh6KyBVREYtIEZhc3RCMkItIFBhckVyci0gREVWU0VMPW1lZGl1bSA+VEFi
b3J0LSA8VEFib3J0LSA8TUFib3J0LSA+U0VSUi0gPFBFUlItIElOVHgtDQoJTGF0ZW5jeTog
MA0KDQowMDoxNC40IFBDSSBicmlkZ2UgWzA2MDRdOiBBVEkgVGVjaG5vbG9naWVzIEluYyBT
QngwMCBQQ0kgdG8gUENJIEJyaWRnZSBbMTAwMjo0Mzg0XSAocmV2IDQwKSAocHJvZy1pZiAw
MCBbTm9ybWFsIGRlY29kZV0pDQoJQ29udHJvbDogSS9PKyBNZW0tIEJ1c01hc3RlcisgU3Bl
Y0N5Y2xlLSBNZW1XSU5WLSBWR0FTbm9vcC0gUGFyRXJyLSBTdGVwcGluZy0gU0VSUisgRmFz
dEIyQi0gRGlzSU5UeC0NCglTdGF0dXM6IENhcC0gNjZNSHorIFVERi0gRmFzdEIyQisgUGFy
RXJyLSBERVZTRUw9bWVkaXVtID5UQWJvcnQtIDxUQWJvcnQtIDxNQWJvcnQtID5TRVJSLSA8
UEVSUi0gSU5UeC0NCglMYXRlbmN5OiA2NA0KCUJ1czogcHJpbWFyeT0wMCwgc2Vjb25kYXJ5
PTAzLCBzdWJvcmRpbmF0ZT0wMywgc2VjLWxhdGVuY3k9NjQNCglJL08gYmVoaW5kIGJyaWRn
ZTogMDAwMGEwMDAtMDAwMGFmZmYNCglNZW1vcnkgYmVoaW5kIGJyaWRnZTogZmZmMDAwMDAt
MDAwZmZmZmYNCglQcmVmZXRjaGFibGUgbWVtb3J5IGJlaGluZCBicmlkZ2U6IGZmZjAwMDAw
LTAwMGZmZmZmDQoJU2Vjb25kYXJ5IHN0YXR1czogNjZNSHotIEZhc3RCMkIrIFBhckVyci0g
REVWU0VMPW1lZGl1bSA+VEFib3J0LSA8VEFib3J0LSA8TUFib3J0LSA8U0VSUi0gPFBFUlIt
DQoJQnJpZGdlQ3RsOiBQYXJpdHkrIFNFUlIrIE5vSVNBKyBWR0EtIE1BYm9ydC0gPlJlc2V0
LSBGYXN0QjJCLQ0KCQlQcmlEaXNjVG1yLSBTZWNEaXNjVG1yLSBEaXNjVG1yU3RhdC0gRGlz
Y1RtclNFUlJFbi0NCg0KMDA6MTQuNSBVU0IgY29udHJvbGxlciBbMGMwM106IEFUSSBUZWNo
bm9sb2dpZXMgSW5jIFNCN3gwL1NCOHgwL1NCOXgwIFVTQiBPSENJMiBDb250cm9sbGVyIFsx
MDAyOjQzOTldIChwcm9nLWlmIDEwIFtPSENJXSkNCglTdWJzeXN0ZW06IE1pY3JvLVN0YXIg
SW50ZXJuYXRpb25hbCBDby4sIEx0ZC4gRGV2aWNlIFsxNDYyOjc2NDBdDQoJQ29udHJvbDog
SS9PKyBNZW0rIEJ1c01hc3RlcisgU3BlY0N5Y2xlLSBNZW1XSU5WKyBWR0FTbm9vcC0gUGFy
RXJyLSBTdGVwcGluZy0gU0VSUisgRmFzdEIyQi0gRGlzSU5UeC0NCglTdGF0dXM6IENhcC0g
NjZNSHorIFVERi0gRmFzdEIyQisgUGFyRXJyLSBERVZTRUw9bWVkaXVtID5UQWJvcnQtIDxU
QWJvcnQtIDxNQWJvcnQtID5TRVJSLSA8UEVSUi0gSU5UeC0NCglMYXRlbmN5OiA2NCwgQ2Fj
aGUgTGluZSBTaXplOiA2NCBieXRlcw0KCUludGVycnVwdDogcGluIEMgcm91dGVkIHRvIElS
USAxOA0KCVJlZ2lvbiAwOiBNZW1vcnkgYXQgZjkzZmQwMDAgKDMyLWJpdCwgbm9uLXByZWZl
dGNoYWJsZSkgW3NpemU9NEtdDQoJS2VybmVsIGRyaXZlciBpbiB1c2U6IG9oY2lfaGNkDQoN
CjAwOjE1LjAgUENJIGJyaWRnZSBbMDYwNF06IEFUSSBUZWNobm9sb2dpZXMgSW5jIFNCNzAw
L1NCODAwL1NCOTAwIFBDSSB0byBQQ0kgYnJpZGdlIChQQ0lFIHBvcnQgMCkgWzEwMDI6NDNh
MF0gKHByb2ctaWYgMDAgW05vcm1hbCBkZWNvZGVdKQ0KCUNvbnRyb2w6IEkvTy0gTWVtLSBC
dXNNYXN0ZXIrIFNwZWNDeWNsZS0gTWVtV0lOVi0gVkdBU25vb3AtIFBhckVyci0gU3RlcHBp
bmctIFNFUlIrIEZhc3RCMkItIERpc0lOVHgrDQoJU3RhdHVzOiBDYXArIDY2TUh6LSBVREYt
IEZhc3RCMkItIFBhckVyci0gREVWU0VMPWZhc3QgPlRBYm9ydC0gPFRBYm9ydC0gPE1BYm9y
dC0gPlNFUlItIDxQRVJSLSBJTlR4LQ0KCUxhdGVuY3k6IDAsIENhY2hlIExpbmUgU2l6ZTog
NjQgYnl0ZXMNCglCdXM6IHByaW1hcnk9MDAsIHNlY29uZGFyeT0wMiwgc3Vib3JkaW5hdGU9
MDIsIHNlYy1sYXRlbmN5PTANCglJL08gYmVoaW5kIGJyaWRnZTogMDAwMGYwMDAtMDAwMDBm
ZmYNCglNZW1vcnkgYmVoaW5kIGJyaWRnZTogZmZmMDAwMDAtMDAwZmZmZmYNCglQcmVmZXRj
aGFibGUgbWVtb3J5IGJlaGluZCBicmlkZ2U6IDAwMDAwMDAwZmZmMDAwMDAtMDAwMDAwMDAw
MDBmZmZmZg0KCVNlY29uZGFyeSBzdGF0dXM6IDY2TUh6LSBGYXN0QjJCLSBQYXJFcnItIERF
VlNFTD1mYXN0ID5UQWJvcnQtIDxUQWJvcnQtIDxNQWJvcnQtIDxTRVJSLSA8UEVSUi0NCglC
cmlkZ2VDdGw6IFBhcml0eSsgU0VSUisgTm9JU0ErIFZHQS0gTUFib3J0LSA+UmVzZXQtIEZh
c3RCMkItDQoJCVByaURpc2NUbXItIFNlY0Rpc2NUbXItIERpc2NUbXJTdGF0LSBEaXNjVG1y
U0VSUkVuLQ0KCUNhcGFiaWxpdGllczogWzUwXSBQb3dlciBNYW5hZ2VtZW50IHZlcnNpb24g
Mw0KCQlGbGFnczogUE1FQ2xrLSBEU0ktIEQxKyBEMisgQXV4Q3VycmVudD0wbUEgUE1FKEQw
LSxEMS0sRDItLEQzaG90LSxEM2NvbGQtKQ0KCQlTdGF0dXM6IEQwIE5vU29mdFJzdC0gUE1F
LUVuYWJsZS0gRFNlbD0wIERTY2FsZT0wIFBNRS0NCglDYXBhYmlsaXRpZXM6IFs1OF0gRXhw
cmVzcyAodjIpIFJvb3QgUG9ydCAoU2xvdCspLCBNU0kgMDANCgkJRGV2Q2FwOglNYXhQYXls
b2FkIDEyOCBieXRlcywgUGhhbnRGdW5jIDAsIExhdGVuY3kgTDBzIDw2NG5zLCBMMSA8MXVz
DQoJCQlFeHRUYWcrIFJCRSsgRkxSZXNldC0NCgkJRGV2Q3RsOglSZXBvcnQgZXJyb3JzOiBD
b3JyZWN0YWJsZS0gTm9uLUZhdGFsLSBGYXRhbC0gVW5zdXBwb3J0ZWQtDQoJCQlSbHhkT3Jk
KyBFeHRUYWctIFBoYW50RnVuYy0gQXV4UHdyLSBOb1Nub29wKw0KCQkJTWF4UGF5bG9hZCAx
MjggYnl0ZXMsIE1heFJlYWRSZXEgMTI4IGJ5dGVzDQoJCURldlN0YToJQ29yckVyci0gVW5j
b3JyRXJyLSBGYXRhbEVyci0gVW5zdXBwUmVxLSBBdXhQd3ItIFRyYW5zUGVuZC0NCgkJTG5r
Q2FwOglQb3J0ICMyNDcsIFNwZWVkIDIuNUdUL3MsIFdpZHRoIHgxLCBBU1BNIEwwcyBMMSwg
TGF0ZW5jeSBMMCA8NjRucywgTDEgPDF1cw0KCQkJQ2xvY2tQTS0gU3VycHJpc2UtIExMQWN0
UmVwKyBCd05vdCsNCgkJTG5rQ3RsOglBU1BNIERpc2FibGVkOyBSQ0IgNjQgYnl0ZXMgRGlz
YWJsZWQtIFJldHJhaW4tIENvbW1DbGstDQoJCQlFeHRTeW5jaC0gQ2xvY2tQTS0gQXV0V2lk
RGlzLSBCV0ludC0gQXV0QldJbnQtDQoJCUxua1N0YToJU3BlZWQgdW5rbm93biwgV2lkdGgg
eDE2LCBUckVyci0gVHJhaW4tIFNsb3RDbGsrIERMQWN0aXZlLSBCV01nbXQtIEFCV01nbXQt
DQoJCVNsdENhcDoJQXR0bkJ0bi0gUHdyQ3RybC0gTVJMLSBBdHRuSW5kLSBQd3JJbmQtIEhv
dFBsdWctIFN1cnByaXNlLQ0KCQkJU2xvdCAjMzIsIFBvd2VyTGltaXQgNzUuMDAwVzsgSW50
ZXJsb2NrLSBOb0NvbXBsKw0KCQlTbHRDdGw6CUVuYWJsZTogQXR0bkJ0bi0gUHdyRmx0LSBN
UkwtIFByZXNEZXQtIENtZENwbHQtIEhQSXJxLSBMaW5rQ2hnLQ0KCQkJQ29udHJvbDogQXR0
bkluZCBVbmtub3duLCBQd3JJbmQgVW5rbm93biwgUG93ZXItIEludGVybG9jay0NCgkJU2x0
U3RhOglTdGF0dXM6IEF0dG5CdG4tIFBvd2VyRmx0LSBNUkwtIENtZENwbHQtIFByZXNEZXQt
IEludGVybG9jay0NCgkJCUNoYW5nZWQ6IE1STC0gUHJlc0RldC0gTGlua1N0YXRlLQ0KCQlS
b290Q3RsOiBFcnJDb3JyZWN0YWJsZS0gRXJyTm9uLUZhdGFsLSBFcnJGYXRhbC0gUE1FSW50
RW5hLSBDUlNWaXNpYmxlLQ0KCQlSb290Q2FwOiBDUlNWaXNpYmxlLQ0KCQlSb290U3RhOiBQ
TUUgUmVxSUQgMDAwMCwgUE1FU3RhdHVzLSBQTUVQZW5kaW5nLQ0KCQlEZXZDYXAyOiBDb21w
bGV0aW9uIFRpbWVvdXQ6IFJhbmdlIEFCQ0QsIFRpbWVvdXREaXMrIEFSSUZ3ZC0NCgkJRGV2
Q3RsMjogQ29tcGxldGlvbiBUaW1lb3V0OiA2NW1zIHRvIDIxMG1zLCBUaW1lb3V0RGlzLSBB
UklGd2QtDQoJCUxua0N0bDI6IFRhcmdldCBMaW5rIFNwZWVkOiAyLjVHVC9zLCBFbnRlckNv
bXBsaWFuY2UtIFNwZWVkRGlzLSwgU2VsZWN0YWJsZSBEZS1lbXBoYXNpczogLTMuNWRCDQoJ
CQkgVHJhbnNtaXQgTWFyZ2luOiBOb3JtYWwgT3BlcmF0aW5nIFJhbmdlLCBFbnRlck1vZGlm
aWVkQ29tcGxpYW5jZS0gQ29tcGxpYW5jZVNPUy0NCgkJCSBDb21wbGlhbmNlIERlLWVtcGhh
c2lzOiAtNmRCDQoJCUxua1N0YTI6IEN1cnJlbnQgRGUtZW1waGFzaXMgTGV2ZWw6IC02ZEIN
CglDYXBhYmlsaXRpZXM6IFthMF0gTVNJOiBFbmFibGUrIENvdW50PTEvMSBNYXNrYWJsZS0g
NjRiaXQrDQoJCUFkZHJlc3M6IDAwMDAwMDAwZmVlM2YwMGMgIERhdGE6IDQxOTENCglDYXBh
YmlsaXRpZXM6IFtiMF0gU3Vic3lzdGVtOiBBVEkgVGVjaG5vbG9naWVzIEluYyBEZXZpY2Ug
WzEwMDI6MDAwMF0NCglDYXBhYmlsaXRpZXM6IFtiOF0gSHlwZXJUcmFuc3BvcnQ6IE1TSSBN
YXBwaW5nIEVuYWJsZSsgRml4ZWQrDQoJQ2FwYWJpbGl0aWVzOiBbMTAwIHYxXSBWZW5kb3Ig
U3BlY2lmaWMgSW5mb3JtYXRpb246IElEPTAwMDEgUmV2PTEgTGVuPTAxMCA8Pz4NCglLZXJu
ZWwgZHJpdmVyIGluIHVzZTogcGNpZXBvcnQNCg0KMDA6MTYuMCBVU0IgY29udHJvbGxlciBb
MGMwM106IEFUSSBUZWNobm9sb2dpZXMgSW5jIFNCN3gwL1NCOHgwL1NCOXgwIFVTQiBPSENJ
MCBDb250cm9sbGVyIFsxMDAyOjQzOTddIChwcm9nLWlmIDEwIFtPSENJXSkNCglTdWJzeXN0
ZW06IE1pY3JvLVN0YXIgSW50ZXJuYXRpb25hbCBDby4sIEx0ZC4gRGV2aWNlIFsxNDYyOjc2
NDBdDQoJQ29udHJvbDogSS9PKyBNZW0rIEJ1c01hc3RlcisgU3BlY0N5Y2xlLSBNZW1XSU5W
KyBWR0FTbm9vcC0gUGFyRXJyLSBTdGVwcGluZy0gU0VSUisgRmFzdEIyQi0gRGlzSU5UeC0N
CglTdGF0dXM6IENhcC0gNjZNSHorIFVERi0gRmFzdEIyQisgUGFyRXJyLSBERVZTRUw9bWVk
aXVtID5UQWJvcnQtIDxUQWJvcnQtIDxNQWJvcnQtID5TRVJSLSA8UEVSUi0gSU5UeC0NCglM
YXRlbmN5OiA2NCwgQ2FjaGUgTGluZSBTaXplOiA2NCBieXRlcw0KCUludGVycnVwdDogcGlu
IEEgcm91dGVkIHRvIElSUSAxOA0KCVJlZ2lvbiAwOiBNZW1vcnkgYXQgZjkzZmUwMDAgKDMy
LWJpdCwgbm9uLXByZWZldGNoYWJsZSkgW3NpemU9NEtdDQoJS2VybmVsIGRyaXZlciBpbiB1
c2U6IG9oY2lfaGNkDQoNCjAwOjE2LjIgVVNCIGNvbnRyb2xsZXIgWzBjMDNdOiBBVEkgVGVj
aG5vbG9naWVzIEluYyBTQjd4MC9TQjh4MC9TQjl4MCBVU0IgRUhDSSBDb250cm9sbGVyIFsx
MDAyOjQzOTZdIChwcm9nLWlmIDIwIFtFSENJXSkNCglTdWJzeXN0ZW06IE1pY3JvLVN0YXIg
SW50ZXJuYXRpb25hbCBDby4sIEx0ZC4gRGV2aWNlIFsxNDYyOjc2NDBdDQoJQ29udHJvbDog
SS9PLSBNZW0rIEJ1c01hc3RlcisgU3BlY0N5Y2xlLSBNZW1XSU5WKyBWR0FTbm9vcC0gUGFy
RXJyLSBTdGVwcGluZy0gU0VSUisgRmFzdEIyQi0gRGlzSU5UeC0NCglTdGF0dXM6IENhcCsg
NjZNSHorIFVERi0gRmFzdEIyQisgUGFyRXJyLSBERVZTRUw9bWVkaXVtID5UQWJvcnQtIDxU
QWJvcnQtIDxNQWJvcnQtID5TRVJSLSA8UEVSUi0gSU5UeC0NCglMYXRlbmN5OiA2NCwgQ2Fj
aGUgTGluZSBTaXplOiA2NCBieXRlcw0KCUludGVycnVwdDogcGluIEIgcm91dGVkIHRvIElS
USAxNw0KCVJlZ2lvbiAwOiBNZW1vcnkgYXQgZjkzZmZjMDAgKDMyLWJpdCwgbm9uLXByZWZl
dGNoYWJsZSkgW3NpemU9MjU2XQ0KCUNhcGFiaWxpdGllczogW2MwXSBQb3dlciBNYW5hZ2Vt
ZW50IHZlcnNpb24gMg0KCQlGbGFnczogUE1FQ2xrLSBEU0ktIEQxKyBEMisgQXV4Q3VycmVu
dD0wbUEgUE1FKEQwKyxEMSssRDIrLEQzaG90KyxEM2NvbGQtKQ0KCQlTdGF0dXM6IEQwIE5v
U29mdFJzdC0gUE1FLUVuYWJsZS0gRFNlbD0wIERTY2FsZT0wIFBNRS0NCgkJQnJpZGdlOiBQ
TS0gQjMrDQoJQ2FwYWJpbGl0aWVzOiBbZTRdIERlYnVnIHBvcnQ6IEJBUj0xIG9mZnNldD0w
MGUwDQoJS2VybmVsIGRyaXZlciBpbiB1c2U6IGVoY2lfaGNkDQoNCjAwOjE4LjAgSG9zdCBi
cmlkZ2UgWzA2MDBdOiBBZHZhbmNlZCBNaWNybyBEZXZpY2VzIFtBTURdIEZhbWlseSAxMGgg
UHJvY2Vzc29yIEh5cGVyVHJhbnNwb3J0IENvbmZpZ3VyYXRpb24gWzEwMjI6MTIwMF0NCglD
b250cm9sOiBJL08tIE1lbS0gQnVzTWFzdGVyLSBTcGVjQ3ljbGUtIE1lbVdJTlYtIFZHQVNu
b29wLSBQYXJFcnItIFN0ZXBwaW5nLSBTRVJSLSBGYXN0QjJCLSBEaXNJTlR4LQ0KCVN0YXR1
czogQ2FwKyA2Nk1Iei0gVURGLSBGYXN0QjJCLSBQYXJFcnItIERFVlNFTD1mYXN0ID5UQWJv
cnQtIDxUQWJvcnQtIDxNQWJvcnQtID5TRVJSLSA8UEVSUi0gSU5UeC0NCglDYXBhYmlsaXRp
ZXM6IFs4MF0gSHlwZXJUcmFuc3BvcnQ6IEhvc3Qgb3IgU2Vjb25kYXJ5IEludGVyZmFjZQ0K
CQlDb21tYW5kOiBXYXJtUnN0KyBEYmxFbmQtIERldk51bT0wIENoYWluU2lkZS0gSG9zdEhp
ZGUrIFNsYXZlLSA8RU9DRXJyLSBEVUwtDQoJCUxpbmsgQ29udHJvbDogQ0ZsRS0gQ1NULSBD
RkUtIDxMa0ZhaWwtIEluaXQrIEVPQy0gVFhPLSA8Q1JDRXJyPTAgSXNvY0VuLSBMU0VuKyBF
eHRDVEwtIDY0Yi0NCgkJTGluayBDb25maWc6IE1MV0k9MTZiaXQgRHdGY0luLSBNTFdPPTE2
Yml0IER3RmNPdXQtIExXST0xNmJpdCBEd0ZjSW5Fbi0gTFdPPTE2Yml0IER3RmNPdXRFbi0N
CgkJUmV2aXNpb24gSUQ6IDMuMDANCgkJTGluayBGcmVxdWVuY3k6IFtiXQ0KCQlMaW5rIEVy
cm9yOiA8UHJvdC0gPE92ZmwtIDxFT0MtIENUTFRtLQ0KCQlMaW5rIEZyZXF1ZW5jeSBDYXBh
YmlsaXR5OiAyMDBNSHorIDMwME1Iei0gNDAwTUh6KyA1MDBNSHotIDYwME1IeisgODAwTUh6
KyAxLjBHSHorIDEuMkdIeisgMS40R0h6LSAxLjZHSHotIFZlbmQtDQoJCUZlYXR1cmUgQ2Fw
YWJpbGl0eTogSXNvY0ZDKyBMRFRTVE9QKyBDUkNUTS0gRUNUTFQtIDY0YkErIFVJRFJELSBF
eHRSUy0gVUNuZkUtDQoNCjAwOjE4LjEgSG9zdCBicmlkZ2UgWzA2MDBdOiBBZHZhbmNlZCBN
aWNybyBEZXZpY2VzIFtBTURdIEZhbWlseSAxMGggUHJvY2Vzc29yIEFkZHJlc3MgTWFwIFsx
MDIyOjEyMDFdDQoJQ29udHJvbDogSS9PLSBNZW0tIEJ1c01hc3Rlci0gU3BlY0N5Y2xlLSBN
ZW1XSU5WLSBWR0FTbm9vcC0gUGFyRXJyLSBTdGVwcGluZy0gU0VSUi0gRmFzdEIyQi0gRGlz
SU5UeC0NCglTdGF0dXM6IENhcC0gNjZNSHotIFVERi0gRmFzdEIyQi0gUGFyRXJyLSBERVZT
RUw9ZmFzdCA+VEFib3J0LSA8VEFib3J0LSA8TUFib3J0LSA+U0VSUi0gPFBFUlItIElOVHgt
DQoNCjAwOjE4LjIgSG9zdCBicmlkZ2UgWzA2MDBdOiBBZHZhbmNlZCBNaWNybyBEZXZpY2Vz
IFtBTURdIEZhbWlseSAxMGggUHJvY2Vzc29yIERSQU0gQ29udHJvbGxlciBbMTAyMjoxMjAy
XQ0KCUNvbnRyb2w6IEkvTy0gTWVtLSBCdXNNYXN0ZXItIFNwZWNDeWNsZS0gTWVtV0lOVi0g
VkdBU25vb3AtIFBhckVyci0gU3RlcHBpbmctIFNFUlItIEZhc3RCMkItIERpc0lOVHgtDQoJ
U3RhdHVzOiBDYXAtIDY2TUh6LSBVREYtIEZhc3RCMkItIFBhckVyci0gREVWU0VMPWZhc3Qg
PlRBYm9ydC0gPFRBYm9ydC0gPE1BYm9ydC0gPlNFUlItIDxQRVJSLSBJTlR4LQ0KDQowMDox
OC4zIEhvc3QgYnJpZGdlIFswNjAwXTogQWR2YW5jZWQgTWljcm8gRGV2aWNlcyBbQU1EXSBG
YW1pbHkgMTBoIFByb2Nlc3NvciBNaXNjZWxsYW5lb3VzIENvbnRyb2wgWzEwMjI6MTIwM10N
CglDb250cm9sOiBJL08tIE1lbS0gQnVzTWFzdGVyLSBTcGVjQ3ljbGUtIE1lbVdJTlYtIFZH
QVNub29wLSBQYXJFcnItIFN0ZXBwaW5nLSBTRVJSLSBGYXN0QjJCLSBEaXNJTlR4LQ0KCVN0
YXR1czogQ2FwKyA2Nk1Iei0gVURGLSBGYXN0QjJCLSBQYXJFcnItIERFVlNFTD1mYXN0ID5U
QWJvcnQtIDxUQWJvcnQtIDxNQWJvcnQtID5TRVJSLSA8UEVSUi0gSU5UeC0NCglDYXBhYmls
aXRpZXM6IFtmMF0gU2VjdXJlIGRldmljZSA8Pz4NCglLZXJuZWwgZHJpdmVyIGluIHVzZTog
azEwdGVtcA0KDQowMDoxOC40IEhvc3QgYnJpZGdlIFswNjAwXTogQWR2YW5jZWQgTWljcm8g
RGV2aWNlcyBbQU1EXSBGYW1pbHkgMTBoIFByb2Nlc3NvciBMaW5rIENvbnRyb2wgWzEwMjI6
MTIwNF0NCglDb250cm9sOiBJL08tIE1lbS0gQnVzTWFzdGVyLSBTcGVjQ3ljbGUtIE1lbVdJ
TlYtIFZHQVNub29wLSBQYXJFcnItIFN0ZXBwaW5nLSBTRVJSLSBGYXN0QjJCLSBEaXNJTlR4
LQ0KCVN0YXR1czogQ2FwLSA2Nk1Iei0gVURGLSBGYXN0QjJCLSBQYXJFcnItIERFVlNFTD1m
YXN0ID5UQWJvcnQtIDxUQWJvcnQtIDxNQWJvcnQtID5TRVJSLSA8UEVSUi0gSU5UeC0NCg0K
MDM6MDYuMCBNdWx0aW1lZGlhIGF1ZGlvIGNvbnRyb2xsZXIgWzA0MDFdOiBDLU1lZGlhIEVs
ZWN0cm9uaWNzIEluYyBDTTg3MzggWzEzZjY6MDExMV0gKHJldiAxMCkNCglTdWJzeXN0ZW06
IEMtTWVkaWEgRWxlY3Ryb25pY3MgSW5jIENNSTg3MzgvQzNEWCBQQ0kgQXVkaW8gRGV2aWNl
IFsxM2Y2OjAxMTFdDQoJQ29udHJvbDogSS9PKyBNZW0tIEJ1c01hc3RlcisgU3BlY0N5Y2xl
LSBNZW1XSU5WLSBWR0FTbm9vcC0gUGFyRXJyLSBTdGVwcGluZy0gU0VSUi0gRmFzdEIyQi0g
RGlzSU5UeC0NCglTdGF0dXM6IENhcCsgNjZNSHotIFVERi0gRmFzdEIyQi0gUGFyRXJyLSBE
RVZTRUw9bWVkaXVtID5UQWJvcnQtIDxUQWJvcnQtIDxNQWJvcnQtID5TRVJSLSA8UEVSUi0g
SU5UeC0NCglMYXRlbmN5OiA2NCAoNTAwbnMgbWluLCA2MDAwbnMgbWF4KQ0KCUludGVycnVw
dDogcGluIEEgcm91dGVkIHRvIElSUSAyMg0KCVJlZ2lvbiAwOiBJL08gcG9ydHMgYXQgYTgw
MCBbc2l6ZT0yNTZdDQoJQ2FwYWJpbGl0aWVzOiBbYzBdIFBvd2VyIE1hbmFnZW1lbnQgdmVy
c2lvbiAyDQoJCUZsYWdzOiBQTUVDbGstIERTSS0gRDErIEQyKyBBdXhDdXJyZW50PTBtQSBQ
TUUoRDAtLEQxLSxEMi0sRDNob3QtLEQzY29sZC0pDQoJCVN0YXR1czogRDAgTm9Tb2Z0UnN0
LSBQTUUtRW5hYmxlLSBEU2VsPTAgRFNjYWxlPTAgUE1FLQ0KCUtlcm5lbCBkcml2ZXIgaW4g
dXNlOiBwY2liYWNrDQoNCjA0OjAwLjAgVVNCIGNvbnRyb2xsZXIgWzBjMDNdOiBOZXRNb3Mg
VGVjaG5vbG9neSBNQ1M5OTkwIFBDSWUgdG8gNOKAkFBvcnQgVVNCIDIuMCBIb3N0IENvbnRy
b2xsZXIgWzk3MTA6OTk5MF0gKHByb2ctaWYgMTAgW09IQ0ldKQ0KCVN1YnN5c3RlbTogRGV2
aWNlIFthMDAwOjQwMDBdDQoJQ29udHJvbDogSS9PLSBNZW0tIEJ1c01hc3Rlci0gU3BlY0N5
Y2xlLSBNZW1XSU5WLSBWR0FTbm9vcC0gUGFyRXJyLSBTdGVwcGluZy0gU0VSUi0gRmFzdEIy
Qi0gRGlzSU5UeC0NCglTdGF0dXM6IENhcCsgNjZNSHotIFVERi0gRmFzdEIyQi0gUGFyRXJy
LSBERVZTRUw9ZmFzdCA+VEFib3J0LSA8VEFib3J0LSA8TUFib3J0LSA+U0VSUi0gPFBFUlIt
IElOVHgtDQoJSW50ZXJydXB0OiBwaW4gQSByb3V0ZWQgdG8gSVJRIDQwDQoJUmVnaW9uIDA6
IE1lbW9yeSBhdCBmOTVmODAwMCAoMzItYml0LCBub24tcHJlZmV0Y2hhYmxlKSBbZGlzYWJs
ZWRdIFtzaXplPTRLXQ0KCUNhcGFiaWxpdGllczogWzUwXSBNU0k6IEVuYWJsZS0gQ291bnQ9
MS8xIE1hc2thYmxlLSA2NGJpdCsNCgkJQWRkcmVzczogMDAwMDAwMDAwMDAwMDAwMCAgRGF0
YTogMDAwMA0KCUNhcGFiaWxpdGllczogWzc4XSBQb3dlciBNYW5hZ2VtZW50IHZlcnNpb24g
Mw0KCQlGbGFnczogUE1FQ2xrLSBEU0ktIEQxKyBEMisgQXV4Q3VycmVudD0zNzVtQSBQTUUo
RDArLEQxKyxEMissRDNob3QrLEQzY29sZC0pDQoJCVN0YXR1czogRDAgTm9Tb2Z0UnN0KyBQ
TUUtRW5hYmxlLSBEU2VsPTAgRFNjYWxlPTAgUE1FLQ0KCUNhcGFiaWxpdGllczogWzgwXSBF
eHByZXNzICh2MSkgRW5kcG9pbnQsIE1TSSAwMA0KCQlEZXZDYXA6CU1heFBheWxvYWQgMjU2
IGJ5dGVzLCBQaGFudEZ1bmMgMCwgTGF0ZW5jeSBMMHMgdW5saW1pdGVkLCBMMSB1bmxpbWl0
ZWQNCgkJCUV4dFRhZy0gQXR0bkJ0bi0gQXR0bkluZC0gUHdySW5kLSBSQkUrIEZMUmVzZXQt
DQoJCURldkN0bDoJUmVwb3J0IGVycm9yczogQ29ycmVjdGFibGUtIE5vbi1GYXRhbC0gRmF0
YWwtIFVuc3VwcG9ydGVkLQ0KCQkJUmx4ZE9yZC0gRXh0VGFnLSBQaGFudEZ1bmMtIEF1eFB3
ci0gTm9Tbm9vcCsNCgkJCU1heFBheWxvYWQgMTI4IGJ5dGVzLCBNYXhSZWFkUmVxIDUxMiBi
eXRlcw0KCQlEZXZTdGE6CUNvcnJFcnItIFVuY29yckVyci0gRmF0YWxFcnItIFVuc3VwcFJl
cS0gQXV4UHdyLSBUcmFuc1BlbmQtDQoJCUxua0NhcDoJUG9ydCAjMSwgU3BlZWQgMi41R1Qv
cywgV2lkdGggeDEsIEFTUE0gdW5rbm93biwgTGF0ZW5jeSBMMCA8NjRucywgTDEgdW5saW1p
dGVkDQoJCQlDbG9ja1BNKyBTdXJwcmlzZS0gTExBY3RSZXAtIEJ3Tm90LQ0KCQlMbmtDdGw6
CUFTUE0gRGlzYWJsZWQ7IFJDQiA2NCBieXRlcyBEaXNhYmxlZC0gUmV0cmFpbi0gQ29tbUNs
ay0NCgkJCUV4dFN5bmNoLSBDbG9ja1BNLSBBdXRXaWREaXMtIEJXSW50LSBBdXRCV0ludC0N
CgkJTG5rU3RhOglTcGVlZCAyLjVHVC9zLCBXaWR0aCB4MSwgVHJFcnItIFRyYWluLSBTbG90
Q2xrLSBETEFjdGl2ZS0gQldNZ210LSBBQldNZ210LQ0KCUNhcGFiaWxpdGllczogWzEwMCB2
MV0gVmlydHVhbCBDaGFubmVsDQoJCUNhcHM6CUxQRVZDPTAgUmVmQ2xrPTEwMG5zIFBBVEVu
dHJ5Qml0cz0xDQoJCUFyYjoJRml4ZWQtIFdSUjMyLSBXUlI2NC0gV1JSMTI4LQ0KCQlDdHJs
OglBcmJTZWxlY3Q9Rml4ZWQNCgkJU3RhdHVzOglJblByb2dyZXNzLQ0KCQlWQzA6CUNhcHM6
CVBBVE9mZnNldD0wMCBNYXhUaW1lU2xvdHM9MSBSZWpTbm9vcFRyYW5zLQ0KCQkJQXJiOglG
aXhlZC0gV1JSMzItIFdSUjY0LSBXUlIxMjgtIFRXUlIxMjgtIFdSUjI1Ni0NCgkJCUN0cmw6
CUVuYWJsZSsgSUQ9MCBBcmJTZWxlY3Q9Rml4ZWQgVEMvVkM9ZmYNCgkJCVN0YXR1czoJTmVn
b1BlbmRpbmctIEluUHJvZ3Jlc3MtDQoJS2VybmVsIGRyaXZlciBpbiB1c2U6IHBjaWJhY2sN
Cg0KMDQ6MDAuMSBVU0IgY29udHJvbGxlciBbMGMwM106IE5ldE1vcyBUZWNobm9sb2d5IE1D
Uzk5OTAgUENJZSB0byA04oCQUG9ydCBVU0IgMi4wIEhvc3QgQ29udHJvbGxlciBbOTcxMDo5
OTkwXSAocHJvZy1pZiAyMCBbRUhDSV0pDQoJU3Vic3lzdGVtOiBEZXZpY2UgW2EwMDA6NDAw
MF0NCglDb250cm9sOiBJL08tIE1lbS0gQnVzTWFzdGVyLSBTcGVjQ3ljbGUtIE1lbVdJTlYt
IFZHQVNub29wLSBQYXJFcnItIFN0ZXBwaW5nLSBTRVJSLSBGYXN0QjJCLSBEaXNJTlR4LQ0K
CVN0YXR1czogQ2FwKyA2Nk1Iei0gVURGLSBGYXN0QjJCLSBQYXJFcnItIERFVlNFTD1mYXN0
ID5UQWJvcnQtIDxUQWJvcnQtIDxNQWJvcnQtID5TRVJSLSA8UEVSUi0gSU5UeC0NCglJbnRl
cnJ1cHQ6IHBpbiBBIHJvdXRlZCB0byBJUlEgNDANCglSZWdpb24gMDogTWVtb3J5IGF0IGY5
NWY5MDAwICgzMi1iaXQsIG5vbi1wcmVmZXRjaGFibGUpIFtkaXNhYmxlZF0gW3NpemU9NEtd
DQoJQ2FwYWJpbGl0aWVzOiBbNTBdIE1TSTogRW5hYmxlLSBDb3VudD0xLzEgTWFza2FibGUt
IDY0Yml0Kw0KCQlBZGRyZXNzOiAwMDAwMDAwMDAwMDAwMDAwICBEYXRhOiAwMDAwDQoJQ2Fw
YWJpbGl0aWVzOiBbNzhdIFBvd2VyIE1hbmFnZW1lbnQgdmVyc2lvbiAzDQoJCUZsYWdzOiBQ
TUVDbGstIERTSS0gRDErIEQyKyBBdXhDdXJyZW50PTM3NW1BIFBNRShEMCssRDErLEQyKyxE
M2hvdCssRDNjb2xkLSkNCgkJU3RhdHVzOiBEMCBOb1NvZnRSc3QrIFBNRS1FbmFibGUtIERT
ZWw9MCBEU2NhbGU9MCBQTUUtDQoJQ2FwYWJpbGl0aWVzOiBbODBdIEV4cHJlc3MgKHYxKSBF
bmRwb2ludCwgTVNJIDAwDQoJCURldkNhcDoJTWF4UGF5bG9hZCAyNTYgYnl0ZXMsIFBoYW50
RnVuYyAwLCBMYXRlbmN5IEwwcyB1bmxpbWl0ZWQsIEwxIHVubGltaXRlZA0KCQkJRXh0VGFn
LSBBdHRuQnRuLSBBdHRuSW5kLSBQd3JJbmQtIFJCRSsgRkxSZXNldC0NCgkJRGV2Q3RsOglS
ZXBvcnQgZXJyb3JzOiBDb3JyZWN0YWJsZS0gTm9uLUZhdGFsLSBGYXRhbC0gVW5zdXBwb3J0
ZWQtDQoJCQlSbHhkT3JkLSBFeHRUYWctIFBoYW50RnVuYy0gQXV4UHdyLSBOb1Nub29wKw0K
CQkJTWF4UGF5bG9hZCAxMjggYnl0ZXMsIE1heFJlYWRSZXEgNTEyIGJ5dGVzDQoJCURldlN0
YToJQ29yckVyci0gVW5jb3JyRXJyLSBGYXRhbEVyci0gVW5zdXBwUmVxLSBBdXhQd3ItIFRy
YW5zUGVuZC0NCgkJTG5rQ2FwOglQb3J0ICMxLCBTcGVlZCAyLjVHVC9zLCBXaWR0aCB4MSwg
QVNQTSB1bmtub3duLCBMYXRlbmN5IEwwIDw2NG5zLCBMMSB1bmxpbWl0ZWQNCgkJCUNsb2Nr
UE0rIFN1cnByaXNlLSBMTEFjdFJlcC0gQndOb3QtDQoJCUxua0N0bDoJQVNQTSBEaXNhYmxl
ZDsgUkNCIDY0IGJ5dGVzIERpc2FibGVkLSBSZXRyYWluLSBDb21tQ2xrLQ0KCQkJRXh0U3lu
Y2gtIENsb2NrUE0tIEF1dFdpZERpcy0gQldJbnQtIEF1dEJXSW50LQ0KCQlMbmtTdGE6CVNw
ZWVkIDIuNUdUL3MsIFdpZHRoIHgxLCBUckVyci0gVHJhaW4tIFNsb3RDbGstIERMQWN0aXZl
LSBCV01nbXQtIEFCV01nbXQtDQoJS2VybmVsIGRyaXZlciBpbiB1c2U6IHBjaWJhY2sNCg0K
MDQ6MDAuMiBVU0IgY29udHJvbGxlciBbMGMwM106IE5ldE1vcyBUZWNobm9sb2d5IE1DUzk5
OTAgUENJZSB0byA04oCQUG9ydCBVU0IgMi4wIEhvc3QgQ29udHJvbGxlciBbOTcxMDo5OTkw
XSAocHJvZy1pZiAxMCBbT0hDSV0pDQoJU3Vic3lzdGVtOiBEZXZpY2UgW2EwMDA6NDAwMF0N
CglDb250cm9sOiBJL08tIE1lbS0gQnVzTWFzdGVyLSBTcGVjQ3ljbGUtIE1lbVdJTlYtIFZH
QVNub29wLSBQYXJFcnItIFN0ZXBwaW5nLSBTRVJSLSBGYXN0QjJCLSBEaXNJTlR4LQ0KCVN0
YXR1czogQ2FwKyA2Nk1Iei0gVURGLSBGYXN0QjJCLSBQYXJFcnItIERFVlNFTD1mYXN0ID5U
QWJvcnQtIDxUQWJvcnQtIDxNQWJvcnQtID5TRVJSLSA8UEVSUi0gSU5UeC0NCglJbnRlcnJ1
cHQ6IHBpbiBCIHJvdXRlZCB0byBJUlEgNDENCglSZWdpb24gMDogTWVtb3J5IGF0IGY5NWZh
MDAwICgzMi1iaXQsIG5vbi1wcmVmZXRjaGFibGUpIFtkaXNhYmxlZF0gW3NpemU9NEtdDQoJ
Q2FwYWJpbGl0aWVzOiBbNTBdIE1TSTogRW5hYmxlLSBDb3VudD0xLzEgTWFza2FibGUtIDY0
Yml0Kw0KCQlBZGRyZXNzOiAwMDAwMDAwMDAwMDAwMDAwICBEYXRhOiAwMDAwDQoJQ2FwYWJp
bGl0aWVzOiBbNzhdIFBvd2VyIE1hbmFnZW1lbnQgdmVyc2lvbiAzDQoJCUZsYWdzOiBQTUVD
bGstIERTSS0gRDErIEQyKyBBdXhDdXJyZW50PTM3NW1BIFBNRShEMCssRDErLEQyKyxEM2hv
dCssRDNjb2xkLSkNCgkJU3RhdHVzOiBEMCBOb1NvZnRSc3QrIFBNRS1FbmFibGUtIERTZWw9
MCBEU2NhbGU9MCBQTUUtDQoJQ2FwYWJpbGl0aWVzOiBbODBdIEV4cHJlc3MgKHYxKSBFbmRw
b2ludCwgTVNJIDAwDQoJCURldkNhcDoJTWF4UGF5bG9hZCAyNTYgYnl0ZXMsIFBoYW50RnVu
YyAwLCBMYXRlbmN5IEwwcyB1bmxpbWl0ZWQsIEwxIHVubGltaXRlZA0KCQkJRXh0VGFnLSBB
dHRuQnRuLSBBdHRuSW5kLSBQd3JJbmQtIFJCRSsgRkxSZXNldC0NCgkJRGV2Q3RsOglSZXBv
cnQgZXJyb3JzOiBDb3JyZWN0YWJsZS0gTm9uLUZhdGFsLSBGYXRhbC0gVW5zdXBwb3J0ZWQt
DQoJCQlSbHhkT3JkLSBFeHRUYWctIFBoYW50RnVuYy0gQXV4UHdyLSBOb1Nub29wKw0KCQkJ
TWF4UGF5bG9hZCAxMjggYnl0ZXMsIE1heFJlYWRSZXEgNTEyIGJ5dGVzDQoJCURldlN0YToJ
Q29yckVyci0gVW5jb3JyRXJyLSBGYXRhbEVyci0gVW5zdXBwUmVxLSBBdXhQd3ItIFRyYW5z
UGVuZC0NCgkJTG5rQ2FwOglQb3J0ICMxLCBTcGVlZCAyLjVHVC9zLCBXaWR0aCB4MSwgQVNQ
TSB1bmtub3duLCBMYXRlbmN5IEwwIDw2NG5zLCBMMSB1bmxpbWl0ZWQNCgkJCUNsb2NrUE0r
IFN1cnByaXNlLSBMTEFjdFJlcC0gQndOb3QtDQoJCUxua0N0bDoJQVNQTSBEaXNhYmxlZDsg
UkNCIDY0IGJ5dGVzIERpc2FibGVkLSBSZXRyYWluLSBDb21tQ2xrLQ0KCQkJRXh0U3luY2gt
IENsb2NrUE0tIEF1dFdpZERpcy0gQldJbnQtIEF1dEJXSW50LQ0KCQlMbmtTdGE6CVNwZWVk
IDIuNUdUL3MsIFdpZHRoIHgxLCBUckVyci0gVHJhaW4tIFNsb3RDbGstIERMQWN0aXZlLSBC
V01nbXQtIEFCV01nbXQtDQoJS2VybmVsIGRyaXZlciBpbiB1c2U6IHBjaWJhY2sNCg0KMDQ6
MDAuMyBVU0IgY29udHJvbGxlciBbMGMwM106IE5ldE1vcyBUZWNobm9sb2d5IE1DUzk5OTAg
UENJZSB0byA04oCQUG9ydCBVU0IgMi4wIEhvc3QgQ29udHJvbGxlciBbOTcxMDo5OTkwXSAo
cHJvZy1pZiAyMCBbRUhDSV0pDQoJU3Vic3lzdGVtOiBEZXZpY2UgW2EwMDA6NDAwMF0NCglD
b250cm9sOiBJL08tIE1lbS0gQnVzTWFzdGVyLSBTcGVjQ3ljbGUtIE1lbVdJTlYtIFZHQVNu
b29wLSBQYXJFcnItIFN0ZXBwaW5nLSBTRVJSLSBGYXN0QjJCLSBEaXNJTlR4LQ0KCVN0YXR1
czogQ2FwKyA2Nk1Iei0gVURGLSBGYXN0QjJCLSBQYXJFcnItIERFVlNFTD1mYXN0ID5UQWJv
cnQtIDxUQWJvcnQtIDxNQWJvcnQtID5TRVJSLSA8UEVSUi0gSU5UeC0NCglJbnRlcnJ1cHQ6
IHBpbiBCIHJvdXRlZCB0byBJUlEgNDENCglSZWdpb24gMDogTWVtb3J5IGF0IGY5NWZiMDAw
ICgzMi1iaXQsIG5vbi1wcmVmZXRjaGFibGUpIFtkaXNhYmxlZF0gW3NpemU9NEtdDQoJQ2Fw
YWJpbGl0aWVzOiBbNTBdIE1TSTogRW5hYmxlLSBDb3VudD0xLzEgTWFza2FibGUtIDY0Yml0
Kw0KCQlBZGRyZXNzOiAwMDAwMDAwMDAwMDAwMDAwICBEYXRhOiAwMDAwDQoJQ2FwYWJpbGl0
aWVzOiBbNzhdIFBvd2VyIE1hbmFnZW1lbnQgdmVyc2lvbiAzDQoJCUZsYWdzOiBQTUVDbGst
IERTSS0gRDErIEQyKyBBdXhDdXJyZW50PTM3NW1BIFBNRShEMCssRDErLEQyKyxEM2hvdCss
RDNjb2xkLSkNCgkJU3RhdHVzOiBEMCBOb1NvZnRSc3QrIFBNRS1FbmFibGUtIERTZWw9MCBE
U2NhbGU9MCBQTUUtDQoJQ2FwYWJpbGl0aWVzOiBbODBdIEV4cHJlc3MgKHYxKSBFbmRwb2lu
dCwgTVNJIDAwDQoJCURldkNhcDoJTWF4UGF5bG9hZCAyNTYgYnl0ZXMsIFBoYW50RnVuYyAw
LCBMYXRlbmN5IEwwcyB1bmxpbWl0ZWQsIEwxIHVubGltaXRlZA0KCQkJRXh0VGFnLSBBdHRu
QnRuLSBBdHRuSW5kLSBQd3JJbmQtIFJCRSsgRkxSZXNldC0NCgkJRGV2Q3RsOglSZXBvcnQg
ZXJyb3JzOiBDb3JyZWN0YWJsZS0gTm9uLUZhdGFsLSBGYXRhbC0gVW5zdXBwb3J0ZWQtDQoJ
CQlSbHhkT3JkLSBFeHRUYWctIFBoYW50RnVuYy0gQXV4UHdyLSBOb1Nub29wKw0KCQkJTWF4
UGF5bG9hZCAxMjggYnl0ZXMsIE1heFJlYWRSZXEgNTEyIGJ5dGVzDQoJCURldlN0YToJQ29y
ckVyci0gVW5jb3JyRXJyLSBGYXRhbEVyci0gVW5zdXBwUmVxLSBBdXhQd3ItIFRyYW5zUGVu
ZC0NCgkJTG5rQ2FwOglQb3J0ICMxLCBTcGVlZCAyLjVHVC9zLCBXaWR0aCB4MSwgQVNQTSB1
bmtub3duLCBMYXRlbmN5IEwwIDw2NG5zLCBMMSB1bmxpbWl0ZWQNCgkJCUNsb2NrUE0rIFN1
cnByaXNlLSBMTEFjdFJlcC0gQndOb3QtDQoJCUxua0N0bDoJQVNQTSBEaXNhYmxlZDsgUkNC
IDY0IGJ5dGVzIERpc2FibGVkLSBSZXRyYWluLSBDb21tQ2xrLQ0KCQkJRXh0U3luY2gtIENs
b2NrUE0tIEF1dFdpZERpcy0gQldJbnQtIEF1dEJXSW50LQ0KCQlMbmtTdGE6CVNwZWVkIDIu
NUdUL3MsIFdpZHRoIHgxLCBUckVyci0gVHJhaW4tIFNsb3RDbGstIERMQWN0aXZlLSBCV01n
bXQtIEFCV01nbXQtDQoJS2VybmVsIGRyaXZlciBpbiB1c2U6IHBjaWJhY2sNCg0KMDQ6MDAu
NCBVU0IgY29udHJvbGxlciBbMGMwM106IE5ldE1vcyBUZWNobm9sb2d5IE1DUzk5OTAgUENJ
ZSB0byA04oCQUG9ydCBVU0IgMi4wIEhvc3QgQ29udHJvbGxlciBbOTcxMDo5OTkwXSAocHJv
Zy1pZiAxMCBbT0hDSV0pDQoJU3Vic3lzdGVtOiBEZXZpY2UgW2EwMDA6NDAwMF0NCglDb250
cm9sOiBJL08tIE1lbS0gQnVzTWFzdGVyLSBTcGVjQ3ljbGUtIE1lbVdJTlYtIFZHQVNub29w
LSBQYXJFcnItIFN0ZXBwaW5nLSBTRVJSLSBGYXN0QjJCLSBEaXNJTlR4LQ0KCVN0YXR1czog
Q2FwKyA2Nk1Iei0gVURGLSBGYXN0QjJCLSBQYXJFcnItIERFVlNFTD1mYXN0ID5UQWJvcnQt
IDxUQWJvcnQtIDxNQWJvcnQtID5TRVJSLSA8UEVSUi0gSU5UeC0NCglJbnRlcnJ1cHQ6IHBp
biBDIHJvdXRlZCB0byBJUlEgNDINCglSZWdpb24gMDogTWVtb3J5IGF0IGY5NWZjMDAwICgz
Mi1iaXQsIG5vbi1wcmVmZXRjaGFibGUpIFtkaXNhYmxlZF0gW3NpemU9NEtdDQoJQ2FwYWJp
bGl0aWVzOiBbNTBdIE1TSTogRW5hYmxlLSBDb3VudD0xLzEgTWFza2FibGUtIDY0Yml0Kw0K
CQlBZGRyZXNzOiAwMDAwMDAwMDAwMDAwMDAwICBEYXRhOiAwMDAwDQoJQ2FwYWJpbGl0aWVz
OiBbNzhdIFBvd2VyIE1hbmFnZW1lbnQgdmVyc2lvbiAzDQoJCUZsYWdzOiBQTUVDbGstIERT
SS0gRDErIEQyKyBBdXhDdXJyZW50PTM3NW1BIFBNRShEMCssRDErLEQyKyxEM2hvdCssRDNj
b2xkLSkNCgkJU3RhdHVzOiBEMCBOb1NvZnRSc3QrIFBNRS1FbmFibGUtIERTZWw9MCBEU2Nh
bGU9MCBQTUUtDQoJQ2FwYWJpbGl0aWVzOiBbODBdIEV4cHJlc3MgKHYxKSBFbmRwb2ludCwg
TVNJIDAwDQoJCURldkNhcDoJTWF4UGF5bG9hZCAyNTYgYnl0ZXMsIFBoYW50RnVuYyAwLCBM
YXRlbmN5IEwwcyB1bmxpbWl0ZWQsIEwxIHVubGltaXRlZA0KCQkJRXh0VGFnLSBBdHRuQnRu
LSBBdHRuSW5kLSBQd3JJbmQtIFJCRSsgRkxSZXNldC0NCgkJRGV2Q3RsOglSZXBvcnQgZXJy
b3JzOiBDb3JyZWN0YWJsZS0gTm9uLUZhdGFsLSBGYXRhbC0gVW5zdXBwb3J0ZWQtDQoJCQlS
bHhkT3JkLSBFeHRUYWctIFBoYW50RnVuYy0gQXV4UHdyLSBOb1Nub29wKw0KCQkJTWF4UGF5
bG9hZCAxMjggYnl0ZXMsIE1heFJlYWRSZXEgNTEyIGJ5dGVzDQoJCURldlN0YToJQ29yckVy
ci0gVW5jb3JyRXJyLSBGYXRhbEVyci0gVW5zdXBwUmVxLSBBdXhQd3ItIFRyYW5zUGVuZC0N
CgkJTG5rQ2FwOglQb3J0ICMxLCBTcGVlZCAyLjVHVC9zLCBXaWR0aCB4MSwgQVNQTSB1bmtu
b3duLCBMYXRlbmN5IEwwIDw2NG5zLCBMMSB1bmxpbWl0ZWQNCgkJCUNsb2NrUE0rIFN1cnBy
aXNlLSBMTEFjdFJlcC0gQndOb3QtDQoJCUxua0N0bDoJQVNQTSBEaXNhYmxlZDsgUkNCIDY0
IGJ5dGVzIERpc2FibGVkLSBSZXRyYWluLSBDb21tQ2xrLQ0KCQkJRXh0U3luY2gtIENsb2Nr
UE0tIEF1dFdpZERpcy0gQldJbnQtIEF1dEJXSW50LQ0KCQlMbmtTdGE6CVNwZWVkIDIuNUdU
L3MsIFdpZHRoIHgxLCBUckVyci0gVHJhaW4tIFNsb3RDbGstIERMQWN0aXZlLSBCV01nbXQt
IEFCV01nbXQtDQoJS2VybmVsIGRyaXZlciBpbiB1c2U6IHBjaWJhY2sNCg0KMDQ6MDAuNSBV
U0IgY29udHJvbGxlciBbMGMwM106IE5ldE1vcyBUZWNobm9sb2d5IE1DUzk5OTAgUENJZSB0
byA04oCQUG9ydCBVU0IgMi4wIEhvc3QgQ29udHJvbGxlciBbOTcxMDo5OTkwXSAocHJvZy1p
ZiAyMCBbRUhDSV0pDQoJU3Vic3lzdGVtOiBEZXZpY2UgW2EwMDA6NDAwMF0NCglDb250cm9s
OiBJL08tIE1lbS0gQnVzTWFzdGVyLSBTcGVjQ3ljbGUtIE1lbVdJTlYtIFZHQVNub29wLSBQ
YXJFcnItIFN0ZXBwaW5nLSBTRVJSLSBGYXN0QjJCLSBEaXNJTlR4LQ0KCVN0YXR1czogQ2Fw
KyA2Nk1Iei0gVURGLSBGYXN0QjJCLSBQYXJFcnItIERFVlNFTD1mYXN0ID5UQWJvcnQtIDxU
QWJvcnQtIDxNQWJvcnQtID5TRVJSLSA8UEVSUi0gSU5UeC0NCglJbnRlcnJ1cHQ6IHBpbiBD
IHJvdXRlZCB0byBJUlEgNDINCglSZWdpb24gMDogTWVtb3J5IGF0IGY5NWZkMDAwICgzMi1i
aXQsIG5vbi1wcmVmZXRjaGFibGUpIFtkaXNhYmxlZF0gW3NpemU9NEtdDQoJQ2FwYWJpbGl0
aWVzOiBbNTBdIE1TSTogRW5hYmxlLSBDb3VudD0xLzEgTWFza2FibGUtIDY0Yml0Kw0KCQlB
ZGRyZXNzOiAwMDAwMDAwMDAwMDAwMDAwICBEYXRhOiAwMDAwDQoJQ2FwYWJpbGl0aWVzOiBb
NzhdIFBvd2VyIE1hbmFnZW1lbnQgdmVyc2lvbiAzDQoJCUZsYWdzOiBQTUVDbGstIERTSS0g
RDErIEQyKyBBdXhDdXJyZW50PTM3NW1BIFBNRShEMCssRDErLEQyKyxEM2hvdCssRDNjb2xk
LSkNCgkJU3RhdHVzOiBEMCBOb1NvZnRSc3QrIFBNRS1FbmFibGUtIERTZWw9MCBEU2NhbGU9
MCBQTUUtDQoJQ2FwYWJpbGl0aWVzOiBbODBdIEV4cHJlc3MgKHYxKSBFbmRwb2ludCwgTVNJ
IDAwDQoJCURldkNhcDoJTWF4UGF5bG9hZCAyNTYgYnl0ZXMsIFBoYW50RnVuYyAwLCBMYXRl
bmN5IEwwcyB1bmxpbWl0ZWQsIEwxIHVubGltaXRlZA0KCQkJRXh0VGFnLSBBdHRuQnRuLSBB
dHRuSW5kLSBQd3JJbmQtIFJCRSsgRkxSZXNldC0NCgkJRGV2Q3RsOglSZXBvcnQgZXJyb3Jz
OiBDb3JyZWN0YWJsZS0gTm9uLUZhdGFsLSBGYXRhbC0gVW5zdXBwb3J0ZWQtDQoJCQlSbHhk
T3JkLSBFeHRUYWctIFBoYW50RnVuYy0gQXV4UHdyLSBOb1Nub29wKw0KCQkJTWF4UGF5bG9h
ZCAxMjggYnl0ZXMsIE1heFJlYWRSZXEgNTEyIGJ5dGVzDQoJCURldlN0YToJQ29yckVyci0g
VW5jb3JyRXJyLSBGYXRhbEVyci0gVW5zdXBwUmVxLSBBdXhQd3ItIFRyYW5zUGVuZC0NCgkJ
TG5rQ2FwOglQb3J0ICMxLCBTcGVlZCAyLjVHVC9zLCBXaWR0aCB4MSwgQVNQTSB1bmtub3du
LCBMYXRlbmN5IEwwIDw2NG5zLCBMMSB1bmxpbWl0ZWQNCgkJCUNsb2NrUE0rIFN1cnByaXNl
LSBMTEFjdFJlcC0gQndOb3QtDQoJCUxua0N0bDoJQVNQTSBEaXNhYmxlZDsgUkNCIDY0IGJ5
dGVzIERpc2FibGVkLSBSZXRyYWluLSBDb21tQ2xrLQ0KCQkJRXh0U3luY2gtIENsb2NrUE0t
IEF1dFdpZERpcy0gQldJbnQtIEF1dEJXSW50LQ0KCQlMbmtTdGE6CVNwZWVkIDIuNUdUL3Ms
IFdpZHRoIHgxLCBUckVyci0gVHJhaW4tIFNsb3RDbGstIERMQWN0aXZlLSBCV01nbXQtIEFC
V01nbXQtDQoJS2VybmVsIGRyaXZlciBpbiB1c2U6IHBjaWJhY2sNCg0KMDQ6MDAuNiBVU0Ig
Y29udHJvbGxlciBbMGMwM106IE5ldE1vcyBUZWNobm9sb2d5IE1DUzk5OTAgUENJZSB0byA0
4oCQUG9ydCBVU0IgMi4wIEhvc3QgQ29udHJvbGxlciBbOTcxMDo5OTkwXSAocHJvZy1pZiAx
MCBbT0hDSV0pDQoJU3Vic3lzdGVtOiBEZXZpY2UgW2EwMDA6NDAwMF0NCglDb250cm9sOiBJ
L08tIE1lbS0gQnVzTWFzdGVyLSBTcGVjQ3ljbGUtIE1lbVdJTlYtIFZHQVNub29wLSBQYXJF
cnItIFN0ZXBwaW5nLSBTRVJSLSBGYXN0QjJCLSBEaXNJTlR4LQ0KCVN0YXR1czogQ2FwKyA2
Nk1Iei0gVURGLSBGYXN0QjJCLSBQYXJFcnItIERFVlNFTD1mYXN0ID5UQWJvcnQtIDxUQWJv
cnQtIDxNQWJvcnQtID5TRVJSLSA8UEVSUi0gSU5UeC0NCglJbnRlcnJ1cHQ6IHBpbiBEIHJv
dXRlZCB0byBJUlEgNDMNCglSZWdpb24gMDogTWVtb3J5IGF0IGY5NWZlMDAwICgzMi1iaXQs
IG5vbi1wcmVmZXRjaGFibGUpIFtkaXNhYmxlZF0gW3NpemU9NEtdDQoJQ2FwYWJpbGl0aWVz
OiBbNTBdIE1TSTogRW5hYmxlLSBDb3VudD0xLzEgTWFza2FibGUtIDY0Yml0Kw0KCQlBZGRy
ZXNzOiAwMDAwMDAwMDAwMDAwMDAwICBEYXRhOiAwMDAwDQoJQ2FwYWJpbGl0aWVzOiBbNzhd
IFBvd2VyIE1hbmFnZW1lbnQgdmVyc2lvbiAzDQoJCUZsYWdzOiBQTUVDbGstIERTSS0gRDEr
IEQyKyBBdXhDdXJyZW50PTM3NW1BIFBNRShEMCssRDErLEQyKyxEM2hvdCssRDNjb2xkLSkN
CgkJU3RhdHVzOiBEMCBOb1NvZnRSc3QrIFBNRS1FbmFibGUtIERTZWw9MCBEU2NhbGU9MCBQ
TUUtDQoJQ2FwYWJpbGl0aWVzOiBbODBdIEV4cHJlc3MgKHYxKSBFbmRwb2ludCwgTVNJIDAw
DQoJCURldkNhcDoJTWF4UGF5bG9hZCAyNTYgYnl0ZXMsIFBoYW50RnVuYyAwLCBMYXRlbmN5
IEwwcyB1bmxpbWl0ZWQsIEwxIHVubGltaXRlZA0KCQkJRXh0VGFnLSBBdHRuQnRuLSBBdHRu
SW5kLSBQd3JJbmQtIFJCRSsgRkxSZXNldC0NCgkJRGV2Q3RsOglSZXBvcnQgZXJyb3JzOiBD
b3JyZWN0YWJsZS0gTm9uLUZhdGFsLSBGYXRhbC0gVW5zdXBwb3J0ZWQtDQoJCQlSbHhkT3Jk
LSBFeHRUYWctIFBoYW50RnVuYy0gQXV4UHdyLSBOb1Nub29wKw0KCQkJTWF4UGF5bG9hZCAx
MjggYnl0ZXMsIE1heFJlYWRSZXEgNTEyIGJ5dGVzDQoJCURldlN0YToJQ29yckVyci0gVW5j
b3JyRXJyLSBGYXRhbEVyci0gVW5zdXBwUmVxLSBBdXhQd3ItIFRyYW5zUGVuZC0NCgkJTG5r
Q2FwOglQb3J0ICMxLCBTcGVlZCAyLjVHVC9zLCBXaWR0aCB4MSwgQVNQTSB1bmtub3duLCBM
YXRlbmN5IEwwIDw2NG5zLCBMMSB1bmxpbWl0ZWQNCgkJCUNsb2NrUE0rIFN1cnByaXNlLSBM
TEFjdFJlcC0gQndOb3QtDQoJCUxua0N0bDoJQVNQTSBEaXNhYmxlZDsgUkNCIDY0IGJ5dGVz
IERpc2FibGVkLSBSZXRyYWluLSBDb21tQ2xrLQ0KCQkJRXh0U3luY2gtIENsb2NrUE0tIEF1
dFdpZERpcy0gQldJbnQtIEF1dEJXSW50LQ0KCQlMbmtTdGE6CVNwZWVkIDIuNUdUL3MsIFdp
ZHRoIHgxLCBUckVyci0gVHJhaW4tIFNsb3RDbGstIERMQWN0aXZlLSBCV01nbXQtIEFCV01n
bXQtDQoJS2VybmVsIGRyaXZlciBpbiB1c2U6IHBjaWJhY2sNCg0KMDQ6MDAuNyBVU0IgY29u
dHJvbGxlciBbMGMwM106IE5ldE1vcyBUZWNobm9sb2d5IE1DUzk5OTAgUENJZSB0byA04oCQ
UG9ydCBVU0IgMi4wIEhvc3QgQ29udHJvbGxlciBbOTcxMDo5OTkwXSAocHJvZy1pZiAyMCBb
RUhDSV0pDQoJU3Vic3lzdGVtOiBEZXZpY2UgW2EwMDA6NDAwMF0NCglDb250cm9sOiBJL08t
IE1lbS0gQnVzTWFzdGVyLSBTcGVjQ3ljbGUtIE1lbVdJTlYtIFZHQVNub29wLSBQYXJFcnIt
IFN0ZXBwaW5nLSBTRVJSLSBGYXN0QjJCLSBEaXNJTlR4LQ0KCVN0YXR1czogQ2FwKyA2Nk1I
ei0gVURGLSBGYXN0QjJCLSBQYXJFcnItIERFVlNFTD1mYXN0ID5UQWJvcnQtIDxUQWJvcnQt
IDxNQWJvcnQtID5TRVJSLSA8UEVSUi0gSU5UeC0NCglJbnRlcnJ1cHQ6IHBpbiBEIHJvdXRl
ZCB0byBJUlEgNDMNCglSZWdpb24gMDogTWVtb3J5IGF0IGY5NWZmMDAwICgzMi1iaXQsIG5v
bi1wcmVmZXRjaGFibGUpIFtkaXNhYmxlZF0gW3NpemU9NEtdDQoJQ2FwYWJpbGl0aWVzOiBb
NTBdIE1TSTogRW5hYmxlLSBDb3VudD0xLzEgTWFza2FibGUtIDY0Yml0Kw0KCQlBZGRyZXNz
OiAwMDAwMDAwMDAwMDAwMDAwICBEYXRhOiAwMDAwDQoJQ2FwYWJpbGl0aWVzOiBbNzhdIFBv
d2VyIE1hbmFnZW1lbnQgdmVyc2lvbiAzDQoJCUZsYWdzOiBQTUVDbGstIERTSS0gRDErIEQy
KyBBdXhDdXJyZW50PTM3NW1BIFBNRShEMCssRDErLEQyKyxEM2hvdCssRDNjb2xkLSkNCgkJ
U3RhdHVzOiBEMCBOb1NvZnRSc3QrIFBNRS1FbmFibGUtIERTZWw9MCBEU2NhbGU9MCBQTUUt
DQoJQ2FwYWJpbGl0aWVzOiBbODBdIEV4cHJlc3MgKHYxKSBFbmRwb2ludCwgTVNJIDAwDQoJ
CURldkNhcDoJTWF4UGF5bG9hZCAyNTYgYnl0ZXMsIFBoYW50RnVuYyAwLCBMYXRlbmN5IEww
cyB1bmxpbWl0ZWQsIEwxIHVubGltaXRlZA0KCQkJRXh0VGFnLSBBdHRuQnRuLSBBdHRuSW5k
LSBQd3JJbmQtIFJCRSsgRkxSZXNldC0NCgkJRGV2Q3RsOglSZXBvcnQgZXJyb3JzOiBDb3Jy
ZWN0YWJsZS0gTm9uLUZhdGFsLSBGYXRhbC0gVW5zdXBwb3J0ZWQtDQoJCQlSbHhkT3JkLSBF
eHRUYWctIFBoYW50RnVuYy0gQXV4UHdyLSBOb1Nub29wKw0KCQkJTWF4UGF5bG9hZCAxMjgg
Ynl0ZXMsIE1heFJlYWRSZXEgNTEyIGJ5dGVzDQoJCURldlN0YToJQ29yckVyci0gVW5jb3Jy
RXJyLSBGYXRhbEVyci0gVW5zdXBwUmVxLSBBdXhQd3ItIFRyYW5zUGVuZC0NCgkJTG5rQ2Fw
OglQb3J0ICMxLCBTcGVlZCAyLjVHVC9zLCBXaWR0aCB4MSwgQVNQTSB1bmtub3duLCBMYXRl
bmN5IEwwIDw2NG5zLCBMMSB1bmxpbWl0ZWQNCgkJCUNsb2NrUE0rIFN1cnByaXNlLSBMTEFj
dFJlcC0gQndOb3QtDQoJCUxua0N0bDoJQVNQTSBEaXNhYmxlZDsgUkNCIDY0IGJ5dGVzIERp
c2FibGVkLSBSZXRyYWluLSBDb21tQ2xrLQ0KCQkJRXh0U3luY2gtIENsb2NrUE0tIEF1dFdp
ZERpcy0gQldJbnQtIEF1dEJXSW50LQ0KCQlMbmtTdGE6CVNwZWVkIDIuNUdUL3MsIFdpZHRo
IHgxLCBUckVyci0gVHJhaW4tIFNsb3RDbGstIERMQWN0aXZlLSBCV01nbXQtIEFCV01nbXQt
DQoJS2VybmVsIGRyaXZlciBpbiB1c2U6IHBjaWJhY2sNCg0KMDU6MDAuMCBNdWx0aW1lZGlh
IHZpZGVvIGNvbnRyb2xsZXIgWzA0MDBdOiBDb25leGFudCBTeXN0ZW1zLCBJbmMuIENYMjU4
NTAgWzE0ZjE6ODIwMF0NCglDb250cm9sOiBJL08tIE1lbS0gQnVzTWFzdGVyLSBTcGVjQ3lj
bGUtIE1lbVdJTlYtIFZHQVNub29wLSBQYXJFcnItIFN0ZXBwaW5nLSBTRVJSLSBGYXN0QjJC
LSBEaXNJTlR4LQ0KCVN0YXR1czogQ2FwKyA2Nk1Iei0gVURGLSBGYXN0QjJCLSBQYXJFcnIt
IERFVlNFTD1mYXN0ID5UQWJvcnQtIDxUQWJvcnQtIDxNQWJvcnQtID5TRVJSLSA8UEVSUi0g
SU5UeC0NCglJbnRlcnJ1cHQ6IHBpbiBBIHJvdXRlZCB0byBJUlEgMzYNCglSZWdpb24gMDog
TWVtb3J5IGF0IGY5NjAwMDAwICg2NC1iaXQsIG5vbi1wcmVmZXRjaGFibGUpIFtkaXNhYmxl
ZF0gW3NpemU9Mk1dDQoJQ2FwYWJpbGl0aWVzOiBbNDBdIEV4cHJlc3MgKHYxKSBFbmRwb2lu
dCwgTVNJIDAwDQoJCURldkNhcDoJTWF4UGF5bG9hZCAxMjggYnl0ZXMsIFBoYW50RnVuYyAw
LCBMYXRlbmN5IEwwcyA8NjRucywgTDEgPDF1cw0KCQkJRXh0VGFnLSBBdHRuQnRuLSBBdHRu
SW5kLSBQd3JJbmQtIFJCRSsgRkxSZXNldC0NCgkJRGV2Q3RsOglSZXBvcnQgZXJyb3JzOiBD
b3JyZWN0YWJsZS0gTm9uLUZhdGFsLSBGYXRhbC0gVW5zdXBwb3J0ZWQtDQoJCQlSbHhkT3Jk
KyBFeHRUYWctIFBoYW50RnVuYy0gQXV4UHdyLSBOb1Nub29wKw0KCQkJTWF4UGF5bG9hZCAx
MjggYnl0ZXMsIE1heFJlYWRSZXEgNTEyIGJ5dGVzDQoJCURldlN0YToJQ29yckVycisgVW5j
b3JyRXJyLSBGYXRhbEVyci0gVW5zdXBwUmVxKyBBdXhQd3ItIFRyYW5zUGVuZC0NCgkJTG5r
Q2FwOglQb3J0ICMwLCBTcGVlZCAyLjVHVC9zLCBXaWR0aCB4MSwgQVNQTSBMMHMgTDEsIExh
dGVuY3kgTDAgPDJ1cywgTDEgPDR1cw0KCQkJQ2xvY2tQTS0gU3VycHJpc2UtIExMQWN0UmVw
LSBCd05vdC0NCgkJTG5rQ3RsOglBU1BNIERpc2FibGVkOyBSQ0IgNjQgYnl0ZXMgRGlzYWJs
ZWQtIFJldHJhaW4tIENvbW1DbGstDQoJCQlFeHRTeW5jaC0gQ2xvY2tQTS0gQXV0V2lkRGlz
LSBCV0ludC0gQXV0QldJbnQtDQoJCUxua1N0YToJU3BlZWQgMi41R1QvcywgV2lkdGggeDEs
IFRyRXJyLSBUcmFpbi0gU2xvdENsay0gRExBY3RpdmUtIEJXTWdtdC0gQUJXTWdtdC0NCglD
YXBhYmlsaXRpZXM6IFs4MF0gUG93ZXIgTWFuYWdlbWVudCB2ZXJzaW9uIDMNCgkJRmxhZ3M6
IFBNRUNsay0gRFNJKyBEMSsgRDIrIEF1eEN1cnJlbnQ9MG1BIFBNRShEMCssRDErLEQyKyxE
M2hvdCssRDNjb2xkLSkNCgkJU3RhdHVzOiBEMCBOb1NvZnRSc3QrIFBNRS1FbmFibGUtIERT
ZWw9MCBEU2NhbGU9MCBQTUUtDQoJQ2FwYWJpbGl0aWVzOiBbOTBdIFZpdGFsIFByb2R1Y3Qg
RGF0YQ0KCQlVbmtub3duIHNtYWxsIHJlc291cmNlIHR5cGUgMDAsIHdpbGwgbm90IGRlY29k
ZSBtb3JlLg0KCUNhcGFiaWxpdGllczogW2EwXSBNU0k6IEVuYWJsZS0gQ291bnQ9MS8xIE1h
c2thYmxlLSA2NGJpdCsNCgkJQWRkcmVzczogMDAwMDAwMDAwMDAwMDAwMCAgRGF0YTogMDAw
MA0KCUNhcGFiaWxpdGllczogWzEwMCB2MV0gQWR2YW5jZWQgRXJyb3IgUmVwb3J0aW5nDQoJ
CVVFU3RhOglETFAtIFNERVMtIFRMUC0gRkNQLSBDbXBsdFRPLSBDbXBsdEFicnQtIFVueENt
cGx0LSBSeE9GLSBNYWxmVExQLSBFQ1JDLSBVbnN1cFJlcS0gQUNTVmlvbC0NCgkJVUVNc2s6
CURMUC0gU0RFUy0gVExQLSBGQ1AtIENtcGx0VE8tIENtcGx0QWJydC0gVW54Q21wbHQtIFJ4
T0YtIE1hbGZUTFAtIEVDUkMtIFVuc3VwUmVxLSBBQ1NWaW9sLQ0KCQlVRVN2cnQ6CURMUCsg
U0RFUy0gVExQLSBGQ1ArIENtcGx0VE8tIENtcGx0QWJydC0gVW54Q21wbHQtIFJ4T0YrIE1h
bGZUTFArIEVDUkMtIFVuc3VwUmVxLSBBQ1NWaW9sLQ0KCQlDRVN0YToJUnhFcnItIEJhZFRM
UC0gQmFkRExMUC0gUm9sbG92ZXItIFRpbWVvdXQtIE5vbkZhdGFsRXJyKw0KCQlDRU1zazoJ
UnhFcnItIEJhZFRMUC0gQmFkRExMUC0gUm9sbG92ZXItIFRpbWVvdXQtIE5vbkZhdGFsRXJy
Kw0KCQlBRVJDYXA6CUZpcnN0IEVycm9yIFBvaW50ZXI6IDAwLCBHZW5DYXAtIENHZW5Fbi0g
Q2hrQ2FwLSBDaGtFbi0NCglDYXBhYmlsaXRpZXM6IFsyMDAgdjFdIFZpcnR1YWwgQ2hhbm5l
bA0KCQlDYXBzOglMUEVWQz0xIFJlZkNsaz0xMDBucyBQQVRFbnRyeUJpdHM9MQ0KCQlBcmI6
CUZpeGVkKyBXUlIzMisgV1JSNjQrIFdSUjEyOC0NCgkJQ3RybDoJQXJiU2VsZWN0PVdSUjY0
DQoJCVN0YXR1czoJSW5Qcm9ncmVzcy0NCgkJUG9ydCBBcmJpdHJhdGlvbiBUYWJsZSBbMjQw
XSA8Pz4NCgkJVkMwOglDYXBzOglQQVRPZmZzZXQ9MDAgTWF4VGltZVNsb3RzPTEgUmVqU25v
b3BUcmFucy0NCgkJCUFyYjoJRml4ZWQtIFdSUjMyLSBXUlI2NC0gV1JSMTI4LSBUV1JSMTI4
LSBXUlIyNTYtDQoJCQlDdHJsOglFbmFibGUrIElEPTAgQXJiU2VsZWN0PUZpeGVkIFRDL1ZD
PWZmDQoJCQlTdGF0dXM6CU5lZ29QZW5kaW5nLSBJblByb2dyZXNzLQ0KCQlWQzE6CUNhcHM6
CVBBVE9mZnNldD0wMCBNYXhUaW1lU2xvdHM9MSBSZWpTbm9vcFRyYW5zLQ0KCQkJQXJiOglG
aXhlZC0gV1JSMzItIFdSUjY0LSBXUlIxMjgtIFRXUlIxMjgtIFdSUjI1Ni0NCgkJCUN0cmw6
CUVuYWJsZS0gSUQ9MSBBcmJTZWxlY3Q9Rml4ZWQgVEMvVkM9MDANCgkJCVN0YXR1czoJTmVn
b1BlbmRpbmctIEluUHJvZ3Jlc3MtDQoJS2VybmVsIGRyaXZlciBpbiB1c2U6IHBjaWJhY2sN
Cg0KMDY6MDAuMCBWR0EgY29tcGF0aWJsZSBjb250cm9sbGVyIFswMzAwXTogQVRJIFRlY2hu
b2xvZ2llcyBJbmMgUlY2MjAgTEUgW1JhZGVvbiBIRCAzNDUwXSBbMTAwMjo5NWM1XSAocHJv
Zy1pZiAwMCBbVkdBIGNvbnRyb2xsZXJdKQ0KCVN1YnN5c3RlbTogQVNVU1RlSyBDb21wdXRl
ciBJbmMuIERldmljZSBbMTA0MzowMWQ0XQ0KCUNvbnRyb2w6IEkvTy0gTWVtLSBCdXNNYXN0
ZXItIFNwZWNDeWNsZS0gTWVtV0lOVi0gVkdBU25vb3AtIFBhckVyci0gU3RlcHBpbmctIFNF
UlItIEZhc3RCMkItIERpc0lOVHgtDQoJU3RhdHVzOiBDYXArIDY2TUh6LSBVREYtIEZhc3RC
MkItIFBhckVyci0gREVWU0VMPWZhc3QgPlRBYm9ydC0gPFRBYm9ydC0gPE1BYm9ydC0gPlNF
UlItIDxQRVJSLSBJTlR4LQ0KCUludGVycnVwdDogcGluIEEgcm91dGVkIHRvIElSUSAxMA0K
CVJlZ2lvbiAwOiBNZW1vcnkgYXQgYjAwMDAwMDAgKDY0LWJpdCwgcHJlZmV0Y2hhYmxlKSBb
ZGlzYWJsZWRdIFtzaXplPTI1Nk1dDQoJUmVnaW9uIDI6IE1lbW9yeSBhdCBmOTllMDAwMCAo
NjQtYml0LCBub24tcHJlZmV0Y2hhYmxlKSBbZGlzYWJsZWRdIFtzaXplPTY0S10NCglSZWdp
b24gNDogSS9PIHBvcnRzIGF0IGIwMDAgW2Rpc2FibGVkXSBbc2l6ZT0yNTZdDQoJRXhwYW5z
aW9uIFJPTSBhdCBmOTljMDAwMCBbZGlzYWJsZWRdIFtzaXplPTEyOEtdDQoJQ2FwYWJpbGl0
aWVzOiBbNTBdIFBvd2VyIE1hbmFnZW1lbnQgdmVyc2lvbiAzDQoJCUZsYWdzOiBQTUVDbGst
IERTSS0gRDErIEQyKyBBdXhDdXJyZW50PTBtQSBQTUUoRDAtLEQxLSxEMi0sRDNob3QtLEQz
Y29sZC0pDQoJCVN0YXR1czogRDAgTm9Tb2Z0UnN0LSBQTUUtRW5hYmxlLSBEU2VsPTAgRFNj
YWxlPTAgUE1FLQ0KCUNhcGFiaWxpdGllczogWzU4XSBFeHByZXNzICh2MikgTGVnYWN5IEVu
ZHBvaW50LCBNU0kgMDANCgkJRGV2Q2FwOglNYXhQYXlsb2FkIDEyOCBieXRlcywgUGhhbnRG
dW5jIDAsIExhdGVuY3kgTDBzIDw0dXMsIEwxIHVubGltaXRlZA0KCQkJRXh0VGFnKyBBdHRu
QnRuLSBBdHRuSW5kLSBQd3JJbmQtIFJCRSsgRkxSZXNldC0NCgkJRGV2Q3RsOglSZXBvcnQg
ZXJyb3JzOiBDb3JyZWN0YWJsZS0gTm9uLUZhdGFsLSBGYXRhbC0gVW5zdXBwb3J0ZWQtDQoJ
CQlSbHhkT3JkKyBFeHRUYWctIFBoYW50RnVuYy0gQXV4UHdyLSBOb1Nub29wKw0KCQkJTWF4
UGF5bG9hZCAxMjggYnl0ZXMsIE1heFJlYWRSZXEgMTI4IGJ5dGVzDQoJCURldlN0YToJQ29y
ckVyci0gVW5jb3JyRXJyLSBGYXRhbEVyci0gVW5zdXBwUmVxLSBBdXhQd3ItIFRyYW5zUGVu
ZC0NCgkJTG5rQ2FwOglQb3J0ICMwLCBTcGVlZCAyLjVHVC9zLCBXaWR0aCB4MTYsIEFTUE0g
TDBzIEwxLCBMYXRlbmN5IEwwIDw2NG5zLCBMMSA8MXVzDQoJCQlDbG9ja1BNLSBTdXJwcmlz
ZS0gTExBY3RSZXAtIEJ3Tm90LQ0KCQlMbmtDdGw6CUFTUE0gRGlzYWJsZWQ7IFJDQiA2NCBi
eXRlcyBEaXNhYmxlZC0gUmV0cmFpbi0gQ29tbUNsaysNCgkJCUV4dFN5bmNoLSBDbG9ja1BN
LSBBdXRXaWREaXMtIEJXSW50LSBBdXRCV0ludC0NCgkJTG5rU3RhOglTcGVlZCAyLjVHVC9z
LCBXaWR0aCB4MSwgVHJFcnItIFRyYWluLSBTbG90Q2xrKyBETEFjdGl2ZS0gQldNZ210LSBB
QldNZ210LQ0KCQlEZXZDYXAyOiBDb21wbGV0aW9uIFRpbWVvdXQ6IE5vdCBTdXBwb3J0ZWQs
IFRpbWVvdXREaXMtDQoJCURldkN0bDI6IENvbXBsZXRpb24gVGltZW91dDogNTB1cyB0byA1
MG1zLCBUaW1lb3V0RGlzLQ0KCQlMbmtDdGwyOiBUYXJnZXQgTGluayBTcGVlZDogMi41R1Qv
cywgRW50ZXJDb21wbGlhbmNlLSBTcGVlZERpcy0sIFNlbGVjdGFibGUgRGUtZW1waGFzaXM6
IC02ZEINCgkJCSBUcmFuc21pdCBNYXJnaW46IE5vcm1hbCBPcGVyYXRpbmcgUmFuZ2UsIEVu
dGVyTW9kaWZpZWRDb21wbGlhbmNlLSBDb21wbGlhbmNlU09TLQ0KCQkJIENvbXBsaWFuY2Ug
RGUtZW1waGFzaXM6IC02ZEINCgkJTG5rU3RhMjogQ3VycmVudCBEZS1lbXBoYXNpcyBMZXZl
bDogLTZkQg0KCUNhcGFiaWxpdGllczogW2EwXSBNU0k6IEVuYWJsZS0gQ291bnQ9MS8xIE1h
c2thYmxlLSA2NGJpdCsNCgkJQWRkcmVzczogMDAwMDAwMDAwMDAwMDAwMCAgRGF0YTogMDAw
MA0KCUNhcGFiaWxpdGllczogWzEwMCB2MV0gVmVuZG9yIFNwZWNpZmljIEluZm9ybWF0aW9u
OiBJRD0wMDAxIFJldj0xIExlbj0wMTAgPD8+DQoNCjA2OjAwLjEgQXVkaW8gZGV2aWNlIFsw
NDAzXTogQVRJIFRlY2hub2xvZ2llcyBJbmMgUlY2MjAgQXVkaW8gZGV2aWNlIFtSYWRlb24g
SEQgMzR4eCBTZXJpZXNdIFsxMDAyOmFhMjhdDQoJU3Vic3lzdGVtOiBBU1VTVGVLIENvbXB1
dGVyIEluYy4gRGV2aWNlIFsxMDQzOmFhMjhdDQoJQ29udHJvbDogSS9PKyBNZW0rIEJ1c01h
c3RlcisgU3BlY0N5Y2xlLSBNZW1XSU5WLSBWR0FTbm9vcC0gUGFyRXJyLSBTdGVwcGluZy0g
U0VSUisgRmFzdEIyQi0gRGlzSU5UeCsNCglTdGF0dXM6IENhcCsgNjZNSHotIFVERi0gRmFz
dEIyQi0gUGFyRXJyLSBERVZTRUw9ZmFzdCA+VEFib3J0LSA8VEFib3J0LSA8TUFib3J0LSA+
U0VSUi0gPFBFUlItIElOVHgtDQoJTGF0ZW5jeTogMCwgQ2FjaGUgTGluZSBTaXplOiA2NCBi
eXRlcw0KCUludGVycnVwdDogcGluIEIgcm91dGVkIHRvIElSUSAxMjMNCglSZWdpb24gMDog
TWVtb3J5IGF0IGY5OWZjMDAwICg2NC1iaXQsIG5vbi1wcmVmZXRjaGFibGUpIFtzaXplPTE2
S10NCglDYXBhYmlsaXRpZXM6IFs1MF0gUG93ZXIgTWFuYWdlbWVudCB2ZXJzaW9uIDMNCgkJ
RmxhZ3M6IFBNRUNsay0gRFNJLSBEMSsgRDIrIEF1eEN1cnJlbnQ9MG1BIFBNRShEMC0sRDEt
LEQyLSxEM2hvdC0sRDNjb2xkLSkNCgkJU3RhdHVzOiBEMCBOb1NvZnRSc3QtIFBNRS1FbmFi
bGUtIERTZWw9MCBEU2NhbGU9MCBQTUUtDQoJQ2FwYWJpbGl0aWVzOiBbNThdIEV4cHJlc3Mg
KHYyKSBMZWdhY3kgRW5kcG9pbnQsIE1TSSAwMA0KCQlEZXZDYXA6CU1heFBheWxvYWQgMTI4
IGJ5dGVzLCBQaGFudEZ1bmMgMCwgTGF0ZW5jeSBMMHMgPDR1cywgTDEgdW5saW1pdGVkDQoJ
CQlFeHRUYWcrIEF0dG5CdG4tIEF0dG5JbmQtIFB3ckluZC0gUkJFKyBGTFJlc2V0LQ0KCQlE
ZXZDdGw6CVJlcG9ydCBlcnJvcnM6IENvcnJlY3RhYmxlLSBOb24tRmF0YWwtIEZhdGFsLSBV
bnN1cHBvcnRlZC0NCgkJCVJseGRPcmQrIEV4dFRhZy0gUGhhbnRGdW5jLSBBdXhQd3ItIE5v
U25vb3ArDQoJCQlNYXhQYXlsb2FkIDEyOCBieXRlcywgTWF4UmVhZFJlcSAxMjggYnl0ZXMN
CgkJRGV2U3RhOglDb3JyRXJyLSBVbmNvcnJFcnItIEZhdGFsRXJyLSBVbnN1cHBSZXEtIEF1
eFB3ci0gVHJhbnNQZW5kLQ0KCQlMbmtDYXA6CVBvcnQgIzAsIFNwZWVkIDIuNUdUL3MsIFdp
ZHRoIHgxNiwgQVNQTSBMMHMgTDEsIExhdGVuY3kgTDAgPDY0bnMsIEwxIDwxdXMNCgkJCUNs
b2NrUE0tIFN1cnByaXNlLSBMTEFjdFJlcC0gQndOb3QtDQoJCUxua0N0bDoJQVNQTSBEaXNh
YmxlZDsgUkNCIDY0IGJ5dGVzIERpc2FibGVkLSBSZXRyYWluLSBDb21tQ2xrKw0KCQkJRXh0
U3luY2gtIENsb2NrUE0tIEF1dFdpZERpcy0gQldJbnQtIEF1dEJXSW50LQ0KCQlMbmtTdGE6
CVNwZWVkIDIuNUdUL3MsIFdpZHRoIHgxLCBUckVyci0gVHJhaW4tIFNsb3RDbGsrIERMQWN0
aXZlLSBCV01nbXQtIEFCV01nbXQtDQoJCURldkNhcDI6IENvbXBsZXRpb24gVGltZW91dDog
Tm90IFN1cHBvcnRlZCwgVGltZW91dERpcy0NCgkJRGV2Q3RsMjogQ29tcGxldGlvbiBUaW1l
b3V0OiA1MHVzIHRvIDUwbXMsIFRpbWVvdXREaXMtDQoJCUxua0N0bDI6IFRhcmdldCBMaW5r
IFNwZWVkOiAyLjVHVC9zLCBFbnRlckNvbXBsaWFuY2UtIFNwZWVkRGlzLSwgU2VsZWN0YWJs
ZSBEZS1lbXBoYXNpczogLTZkQg0KCQkJIFRyYW5zbWl0IE1hcmdpbjogTm9ybWFsIE9wZXJh
dGluZyBSYW5nZSwgRW50ZXJNb2RpZmllZENvbXBsaWFuY2UtIENvbXBsaWFuY2VTT1MtDQoJ
CQkgQ29tcGxpYW5jZSBEZS1lbXBoYXNpczogLTZkQg0KCQlMbmtTdGEyOiBDdXJyZW50IERl
LWVtcGhhc2lzIExldmVsOiAtNmRCDQoJQ2FwYWJpbGl0aWVzOiBbYTBdIE1TSTogRW5hYmxl
KyBDb3VudD0xLzEgTWFza2FibGUtIDY0Yml0Kw0KCQlBZGRyZXNzOiAwMDAwMDAwMGZlZTAx
MDBjICBEYXRhOiA0MTJhDQoJQ2FwYWJpbGl0aWVzOiBbMTAwIHYxXSBWZW5kb3IgU3BlY2lm
aWMgSW5mb3JtYXRpb246IElEPTAwMDEgUmV2PTEgTGVuPTAxMCA8Pz4NCglLZXJuZWwgZHJp
dmVyIGluIHVzZTogc25kX2hkYV9pbnRlbA0KDQowNzowMC4wIE11bHRpbWVkaWEgdmlkZW8g
Y29udHJvbGxlciBbMDQwMF06IENvbmV4YW50IFN5c3RlbXMsIEluYy4gRGV2aWNlIFsxNGYx
OjgyMTBdDQoJQ29udHJvbDogSS9PLSBNZW0rIEJ1c01hc3RlcisgU3BlY0N5Y2xlLSBNZW1X
SU5WLSBWR0FTbm9vcC0gUGFyRXJyLSBTdGVwcGluZy0gU0VSUi0gRmFzdEIyQi0gRGlzSU5U
eC0NCglTdGF0dXM6IENhcCsgNjZNSHotIFVERi0gRmFzdEIyQi0gUGFyRXJyLSBERVZTRUw9
ZmFzdCA+VEFib3J0LSA8VEFib3J0LSA8TUFib3J0LSA+U0VSUi0gPFBFUlItIElOVHgtDQoJ
TGF0ZW5jeTogMA0KCUludGVycnVwdDogcGluIEEgcm91dGVkIHRvIElSUSA0Nw0KCVJlZ2lv
biAwOiBNZW1vcnkgYXQgZjlhMDAwMDAgKDY0LWJpdCwgbm9uLXByZWZldGNoYWJsZSkgW3Np
emU9Mk1dDQoJQ2FwYWJpbGl0aWVzOiBbNDBdIEV4cHJlc3MgKHYxKSBFbmRwb2ludCwgTVNJ
IDAwDQoJCURldkNhcDoJTWF4UGF5bG9hZCAxMjggYnl0ZXMsIFBoYW50RnVuYyAwLCBMYXRl
bmN5IEwwcyA8NjRucywgTDEgPDF1cw0KCQkJRXh0VGFnLSBBdHRuQnRuLSBBdHRuSW5kLSBQ
d3JJbmQtIFJCRSsgRkxSZXNldC0NCgkJRGV2Q3RsOglSZXBvcnQgZXJyb3JzOiBDb3JyZWN0
YWJsZS0gTm9uLUZhdGFsLSBGYXRhbC0gVW5zdXBwb3J0ZWQtDQoJCQlSbHhkT3JkKyBFeHRU
YWctIFBoYW50RnVuYy0gQXV4UHdyLSBOb1Nub29wKw0KCQkJTWF4UGF5bG9hZCAxMjggYnl0
ZXMsIE1heFJlYWRSZXEgNTEyIGJ5dGVzDQoJCURldlN0YToJQ29yckVycisgVW5jb3JyRXJy
LSBGYXRhbEVyci0gVW5zdXBwUmVxKyBBdXhQd3ItIFRyYW5zUGVuZC0NCgkJTG5rQ2FwOglQ
b3J0ICMwLCBTcGVlZCAyLjVHVC9zLCBXaWR0aCB4MSwgQVNQTSBMMHMgTDEsIExhdGVuY3kg
TDAgPDJ1cywgTDEgPDR1cw0KCQkJQ2xvY2tQTS0gU3VycHJpc2UtIExMQWN0UmVwLSBCd05v
dC0NCgkJTG5rQ3RsOglBU1BNIERpc2FibGVkOyBSQ0IgNjQgYnl0ZXMgRGlzYWJsZWQtIFJl
dHJhaW4tIENvbW1DbGstDQoJCQlFeHRTeW5jaC0gQ2xvY2tQTS0gQXV0V2lkRGlzLSBCV0lu
dC0gQXV0QldJbnQtDQoJCUxua1N0YToJU3BlZWQgMi41R1QvcywgV2lkdGggeDEsIFRyRXJy
LSBUcmFpbi0gU2xvdENsay0gRExBY3RpdmUtIEJXTWdtdC0gQUJXTWdtdC0NCglDYXBhYmls
aXRpZXM6IFs4MF0gUG93ZXIgTWFuYWdlbWVudCB2ZXJzaW9uIDMNCgkJRmxhZ3M6IFBNRUNs
ay0gRFNJKyBEMSsgRDIrIEF1eEN1cnJlbnQ9MG1BIFBNRShEMCssRDErLEQyKyxEM2hvdCss
RDNjb2xkLSkNCgkJU3RhdHVzOiBEMCBOb1NvZnRSc3QrIFBNRS1FbmFibGUtIERTZWw9MCBE
U2NhbGU9MCBQTUUtDQoJQ2FwYWJpbGl0aWVzOiBbOTBdIFZpdGFsIFByb2R1Y3QgRGF0YQ0K
CQlVbmtub3duIHNtYWxsIHJlc291cmNlIHR5cGUgMDIsIHdpbGwgbm90IGRlY29kZSBtb3Jl
Lg0KCUNhcGFiaWxpdGllczogW2EwXSBNU0k6IEVuYWJsZS0gQ291bnQ9MS8xIE1hc2thYmxl
LSA2NGJpdCsNCgkJQWRkcmVzczogMDAwMDAwMDAwMDAwMDAwMCAgRGF0YTogMDAwMA0KCUNh
cGFiaWxpdGllczogWzEwMCB2MV0gQWR2YW5jZWQgRXJyb3IgUmVwb3J0aW5nDQoJCVVFU3Rh
OglETFAtIFNERVMtIFRMUC0gRkNQLSBDbXBsdFRPLSBDbXBsdEFicnQtIFVueENtcGx0LSBS
eE9GLSBNYWxmVExQLSBFQ1JDLSBVbnN1cFJlcS0gQUNTVmlvbC0NCgkJVUVNc2s6CURMUC0g
U0RFUy0gVExQLSBGQ1AtIENtcGx0VE8tIENtcGx0QWJydC0gVW54Q21wbHQtIFJ4T0YtIE1h
bGZUTFAtIEVDUkMtIFVuc3VwUmVxLSBBQ1NWaW9sLQ0KCQlVRVN2cnQ6CURMUCsgU0RFUy0g
VExQLSBGQ1ArIENtcGx0VE8tIENtcGx0QWJydC0gVW54Q21wbHQtIFJ4T0YrIE1hbGZUTFAr
IEVDUkMtIFVuc3VwUmVxLSBBQ1NWaW9sLQ0KCQlDRVN0YToJUnhFcnItIEJhZFRMUC0gQmFk
RExMUC0gUm9sbG92ZXItIFRpbWVvdXQtIE5vbkZhdGFsRXJyKw0KCQlDRU1zazoJUnhFcnIt
IEJhZFRMUC0gQmFkRExMUC0gUm9sbG92ZXItIFRpbWVvdXQtIE5vbkZhdGFsRXJyKw0KCQlB
RVJDYXA6CUZpcnN0IEVycm9yIFBvaW50ZXI6IDAwLCBHZW5DYXAtIENHZW5Fbi0gQ2hrQ2Fw
LSBDaGtFbi0NCglDYXBhYmlsaXRpZXM6IFsyMDAgdjFdIFZpcnR1YWwgQ2hhbm5lbA0KCQlD
YXBzOglMUEVWQz0xIFJlZkNsaz0xMDBucyBQQVRFbnRyeUJpdHM9MQ0KCQlBcmI6CUZpeGVk
KyBXUlIzMisgV1JSNjQrIFdSUjEyOC0NCgkJQ3RybDoJQXJiU2VsZWN0PVdSUjY0DQoJCVN0
YXR1czoJSW5Qcm9ncmVzcy0NCgkJUG9ydCBBcmJpdHJhdGlvbiBUYWJsZSBbMjQwXSA8Pz4N
CgkJVkMwOglDYXBzOglQQVRPZmZzZXQ9MDAgTWF4VGltZVNsb3RzPTEgUmVqU25vb3BUcmFu
cy0NCgkJCUFyYjoJRml4ZWQtIFdSUjMyLSBXUlI2NC0gV1JSMTI4LSBUV1JSMTI4LSBXUlIy
NTYtDQoJCQlDdHJsOglFbmFibGUrIElEPTAgQXJiU2VsZWN0PUZpeGVkIFRDL1ZDPWZmDQoJ
CQlTdGF0dXM6CU5lZ29QZW5kaW5nLSBJblByb2dyZXNzLQ0KCQlWQzE6CUNhcHM6CVBBVE9m
ZnNldD0wMCBNYXhUaW1lU2xvdHM9MSBSZWpTbm9vcFRyYW5zLQ0KCQkJQXJiOglGaXhlZC0g
V1JSMzItIFdSUjY0LSBXUlIxMjgtIFRXUlIxMjgtIFdSUjI1Ni0NCgkJCUN0cmw6CUVuYWJs
ZS0gSUQ9MSBBcmJTZWxlY3Q9Rml4ZWQgVEMvVkM9MDANCgkJCVN0YXR1czoJTmVnb1BlbmRp
bmctIEluUHJvZ3Jlc3MtDQoJS2VybmVsIGRyaXZlciBpbiB1c2U6IHBjaWJhY2sNCg0KMDg6
MDAuMCBFdGhlcm5ldCBjb250cm9sbGVyIFswMjAwXTogUmVhbHRlayBTZW1pY29uZHVjdG9y
IENvLiwgTHRkLiBSVEw4MTExLzgxNjhCIFBDSSBFeHByZXNzIEdpZ2FiaXQgRXRoZXJuZXQg
Y29udHJvbGxlciBbMTBlYzo4MTY4XSAocmV2IDAzKQ0KCVN1YnN5c3RlbTogTWljcm8tU3Rh
ciBJbnRlcm5hdGlvbmFsIENvLiwgTHRkLiBEZXZpY2UgWzE0NjI6NzY0MF0NCglDb250cm9s
OiBJL08rIE1lbSsgQnVzTWFzdGVyKyBTcGVjQ3ljbGUtIE1lbVdJTlYtIFZHQVNub29wLSBQ
YXJFcnItIFN0ZXBwaW5nLSBTRVJSKyBGYXN0QjJCLSBEaXNJTlR4Kw0KCVN0YXR1czogQ2Fw
KyA2Nk1Iei0gVURGLSBGYXN0QjJCLSBQYXJFcnItIERFVlNFTD1mYXN0ID5UQWJvcnQtIDxU
QWJvcnQtIDxNQWJvcnQtID5TRVJSLSA8UEVSUi0gSU5UeC0NCglMYXRlbmN5OiAwLCBDYWNo
ZSBMaW5lIFNpemU6IDY0IGJ5dGVzDQoJSW50ZXJydXB0OiBwaW4gQSByb3V0ZWQgdG8gSVJR
IDEyMg0KCVJlZ2lvbiAwOiBJL08gcG9ydHMgYXQgYzgwMCBbc2l6ZT0yNTZdDQoJUmVnaW9u
IDI6IE1lbW9yeSBhdCBjZmVmZjAwMCAoNjQtYml0LCBwcmVmZXRjaGFibGUpIFtzaXplPTRL
XQ0KCVJlZ2lvbiA0OiBNZW1vcnkgYXQgY2ZlZjgwMDAgKDY0LWJpdCwgcHJlZmV0Y2hhYmxl
KSBbc2l6ZT0xNktdDQoJRXhwYW5zaW9uIFJPTSBhdCBmOWRlMDAwMCBbZGlzYWJsZWRdIFtz
aXplPTEyOEtdDQoJQ2FwYWJpbGl0aWVzOiBbNDBdIFBvd2VyIE1hbmFnZW1lbnQgdmVyc2lv
biAzDQoJCUZsYWdzOiBQTUVDbGstIERTSS0gRDErIEQyKyBBdXhDdXJyZW50PTM3NW1BIFBN
RShEMCssRDErLEQyKyxEM2hvdCssRDNjb2xkKykNCgkJU3RhdHVzOiBEMCBOb1NvZnRSc3Qr
IFBNRS1FbmFibGUtIERTZWw9MCBEU2NhbGU9MCBQTUUtDQoJQ2FwYWJpbGl0aWVzOiBbNTBd
IE1TSTogRW5hYmxlKyBDb3VudD0xLzEgTWFza2FibGUtIDY0Yml0Kw0KCQlBZGRyZXNzOiAw
MDAwMDAwMGZlZTAyMDBjICBEYXRhOiA0MWQ5DQoJQ2FwYWJpbGl0aWVzOiBbNzBdIEV4cHJl
c3MgKHYyKSBFbmRwb2ludCwgTVNJIDAxDQoJCURldkNhcDoJTWF4UGF5bG9hZCAyNTYgYnl0
ZXMsIFBoYW50RnVuYyAwLCBMYXRlbmN5IEwwcyA8NTEybnMsIEwxIDw2NHVzDQoJCQlFeHRU
YWctIEF0dG5CdG4tIEF0dG5JbmQtIFB3ckluZC0gUkJFKyBGTFJlc2V0LQ0KCQlEZXZDdGw6
CVJlcG9ydCBlcnJvcnM6IENvcnJlY3RhYmxlLSBOb24tRmF0YWwtIEZhdGFsLSBVbnN1cHBv
cnRlZC0NCgkJCVJseGRPcmQtIEV4dFRhZy0gUGhhbnRGdW5jLSBBdXhQd3ItIE5vU25vb3At
DQoJCQlNYXhQYXlsb2FkIDEyOCBieXRlcywgTWF4UmVhZFJlcSA1MTIgYnl0ZXMNCgkJRGV2
U3RhOglDb3JyRXJyKyBVbmNvcnJFcnItIEZhdGFsRXJyLSBVbnN1cHBSZXErIEF1eFB3cisg
VHJhbnNQZW5kLQ0KCQlMbmtDYXA6CVBvcnQgIzAsIFNwZWVkIDIuNUdUL3MsIFdpZHRoIHgx
LCBBU1BNIEwwcyBMMSwgTGF0ZW5jeSBMMCA8NTEybnMsIEwxIDw2NHVzDQoJCQlDbG9ja1BN
KyBTdXJwcmlzZS0gTExBY3RSZXAtIEJ3Tm90LQ0KCQlMbmtDdGw6CUFTUE0gRGlzYWJsZWQ7
IFJDQiA2NCBieXRlcyBEaXNhYmxlZC0gUmV0cmFpbi0gQ29tbUNsaysNCgkJCUV4dFN5bmNo
LSBDbG9ja1BNLSBBdXRXaWREaXMtIEJXSW50LSBBdXRCV0ludC0NCgkJTG5rU3RhOglTcGVl
ZCAyLjVHVC9zLCBXaWR0aCB4MSwgVHJFcnItIFRyYWluLSBTbG90Q2xrKyBETEFjdGl2ZS0g
QldNZ210LSBBQldNZ210LQ0KCQlEZXZDYXAyOiBDb21wbGV0aW9uIFRpbWVvdXQ6IE5vdCBT
dXBwb3J0ZWQsIFRpbWVvdXREaXMrDQoJCURldkN0bDI6IENvbXBsZXRpb24gVGltZW91dDog
NTB1cyB0byA1MG1zLCBUaW1lb3V0RGlzLQ0KCQlMbmtDdGwyOiBUYXJnZXQgTGluayBTcGVl
ZDogMi41R1QvcywgRW50ZXJDb21wbGlhbmNlLSBTcGVlZERpcy0sIFNlbGVjdGFibGUgRGUt
ZW1waGFzaXM6IC02ZEINCgkJCSBUcmFuc21pdCBNYXJnaW46IE5vcm1hbCBPcGVyYXRpbmcg
UmFuZ2UsIEVudGVyTW9kaWZpZWRDb21wbGlhbmNlLSBDb21wbGlhbmNlU09TLQ0KCQkJIENv
bXBsaWFuY2UgRGUtZW1waGFzaXM6IC02ZEINCgkJTG5rU3RhMjogQ3VycmVudCBEZS1lbXBo
YXNpcyBMZXZlbDogLTZkQg0KCUNhcGFiaWxpdGllczogW2FjXSBNU0ktWDogRW5hYmxlLSBD
b3VudD00IE1hc2tlZC0NCgkJVmVjdG9yIHRhYmxlOiBCQVI9NCBvZmZzZXQ9MDAwMDAwMDAN
CgkJUEJBOiBCQVI9NCBvZmZzZXQ9MDAwMDA4MDANCglDYXBhYmlsaXRpZXM6IFtjY10gVml0
YWwgUHJvZHVjdCBEYXRhDQoJCVVua25vd24gc21hbGwgcmVzb3VyY2UgdHlwZSAwMCwgd2ls
bCBub3QgZGVjb2RlIG1vcmUuDQoJQ2FwYWJpbGl0aWVzOiBbMTAwIHYxXSBBZHZhbmNlZCBF
cnJvciBSZXBvcnRpbmcNCgkJVUVTdGE6CURMUC0gU0RFUy0gVExQLSBGQ1AtIENtcGx0VE8t
IENtcGx0QWJydC0gVW54Q21wbHQtIFJ4T0YtIE1hbGZUTFAtIEVDUkMtIFVuc3VwUmVxLSBB
Q1NWaW9sLQ0KCQlVRU1zazoJRExQLSBTREVTLSBUTFAtIEZDUC0gQ21wbHRUTy0gQ21wbHRB
YnJ0LSBVbnhDbXBsdC0gUnhPRi0gTWFsZlRMUC0gRUNSQy0gVW5zdXBSZXEtIEFDU1Zpb2wt
DQoJCVVFU3ZydDoJRExQKyBTREVTKyBUTFAtIEZDUCsgQ21wbHRUTy0gQ21wbHRBYnJ0LSBV
bnhDbXBsdC0gUnhPRisgTWFsZlRMUCsgRUNSQy0gVW5zdXBSZXEtIEFDU1Zpb2wtDQoJCUNF
U3RhOglSeEVycisgQmFkVExQLSBCYWRETExQLSBSb2xsb3Zlci0gVGltZW91dC0gTm9uRmF0
YWxFcnIrDQoJCUNFTXNrOglSeEVyci0gQmFkVExQLSBCYWRETExQLSBSb2xsb3Zlci0gVGlt
ZW91dC0gTm9uRmF0YWxFcnIrDQoJCUFFUkNhcDoJRmlyc3QgRXJyb3IgUG9pbnRlcjogMDAs
IEdlbkNhcCsgQ0dlbkVuLSBDaGtDYXArIENoa0VuLQ0KCUNhcGFiaWxpdGllczogWzE0MCB2
MV0gVmlydHVhbCBDaGFubmVsDQoJCUNhcHM6CUxQRVZDPTAgUmVmQ2xrPTEwMG5zIFBBVEVu
dHJ5Qml0cz0xDQoJCUFyYjoJRml4ZWQtIFdSUjMyLSBXUlI2NC0gV1JSMTI4LQ0KCQlDdHJs
OglBcmJTZWxlY3Q9Rml4ZWQNCgkJU3RhdHVzOglJblByb2dyZXNzLQ0KCQlWQzA6CUNhcHM6
CVBBVE9mZnNldD0wMCBNYXhUaW1lU2xvdHM9MSBSZWpTbm9vcFRyYW5zLQ0KCQkJQXJiOglG
aXhlZC0gV1JSMzItIFdSUjY0LSBXUlIxMjgtIFRXUlIxMjgtIFdSUjI1Ni0NCgkJCUN0cmw6
CUVuYWJsZSsgSUQ9MCBBcmJTZWxlY3Q9Rml4ZWQgVEMvVkM9ZmYNCgkJCVN0YXR1czoJTmVn
b1BlbmRpbmctIEluUHJvZ3Jlc3MtDQoJQ2FwYWJpbGl0aWVzOiBbMTYwIHYxXSBEZXZpY2Ug
U2VyaWFsIE51bWJlciAwMy0wMC0wMC0wMC02OC00Yy1lMC0wMA0KCUtlcm5lbCBkcml2ZXIg
aW4gdXNlOiByODE2OQ0KDQowOTowMC4wIEV0aGVybmV0IGNvbnRyb2xsZXIgWzAyMDBdOiBS
ZWFsdGVrIFNlbWljb25kdWN0b3IgQ28uLCBMdGQuIFJUTDgxMTEvODE2OEIgUENJIEV4cHJl
c3MgR2lnYWJpdCBFdGhlcm5ldCBjb250cm9sbGVyIFsxMGVjOjgxNjhdIChyZXYgMDMpDQoJ
U3Vic3lzdGVtOiBNaWNyby1TdGFyIEludGVybmF0aW9uYWwgQ28uLCBMdGQuIERldmljZSBb
MTQ2Mjo3NjQwXQ0KCUNvbnRyb2w6IEkvTysgTWVtKyBCdXNNYXN0ZXIrIFNwZWNDeWNsZS0g
TWVtV0lOVi0gVkdBU25vb3AtIFBhckVyci0gU3RlcHBpbmctIFNFUlIrIEZhc3RCMkItIERp
c0lOVHgrDQoJU3RhdHVzOiBDYXArIDY2TUh6LSBVREYtIEZhc3RCMkItIFBhckVyci0gREVW
U0VMPWZhc3QgPlRBYm9ydC0gPFRBYm9ydC0gPE1BYm9ydC0gPlNFUlItIDxQRVJSLSBJTlR4
LQ0KCUxhdGVuY3k6IDAsIENhY2hlIExpbmUgU2l6ZTogNjQgYnl0ZXMNCglJbnRlcnJ1cHQ6
IHBpbiBBIHJvdXRlZCB0byBJUlEgMTIxDQoJUmVnaW9uIDA6IEkvTyBwb3J0cyBhdCBkODAw
IFtzaXplPTI1Nl0NCglSZWdpb24gMjogTWVtb3J5IGF0IGNmZmZmMDAwICg2NC1iaXQsIHBy
ZWZldGNoYWJsZSkgW3NpemU9NEtdDQoJUmVnaW9uIDQ6IE1lbW9yeSBhdCBjZmZmODAwMCAo
NjQtYml0LCBwcmVmZXRjaGFibGUpIFtzaXplPTE2S10NCglFeHBhbnNpb24gUk9NIGF0IGY5
ZWUwMDAwIFtkaXNhYmxlZF0gW3NpemU9MTI4S10NCglDYXBhYmlsaXRpZXM6IFs0MF0gUG93
ZXIgTWFuYWdlbWVudCB2ZXJzaW9uIDMNCgkJRmxhZ3M6IFBNRUNsay0gRFNJLSBEMSsgRDIr
IEF1eEN1cnJlbnQ9Mzc1bUEgUE1FKEQwKyxEMSssRDIrLEQzaG90KyxEM2NvbGQrKQ0KCQlT
dGF0dXM6IEQwIE5vU29mdFJzdCsgUE1FLUVuYWJsZS0gRFNlbD0wIERTY2FsZT0wIFBNRS0N
CglDYXBhYmlsaXRpZXM6IFs1MF0gTVNJOiBFbmFibGUrIENvdW50PTEvMSBNYXNrYWJsZS0g
NjRiaXQrDQoJCUFkZHJlc3M6IDAwMDAwMDAwZmVlMDEwMGMgIERhdGE6IDQxYzkNCglDYXBh
YmlsaXRpZXM6IFs3MF0gRXhwcmVzcyAodjIpIEVuZHBvaW50LCBNU0kgMDENCgkJRGV2Q2Fw
OglNYXhQYXlsb2FkIDI1NiBieXRlcywgUGhhbnRGdW5jIDAsIExhdGVuY3kgTDBzIDw1MTJu
cywgTDEgPDY0dXMNCgkJCUV4dFRhZy0gQXR0bkJ0bi0gQXR0bkluZC0gUHdySW5kLSBSQkUr
IEZMUmVzZXQtDQoJCURldkN0bDoJUmVwb3J0IGVycm9yczogQ29ycmVjdGFibGUtIE5vbi1G
YXRhbC0gRmF0YWwtIFVuc3VwcG9ydGVkLQ0KCQkJUmx4ZE9yZC0gRXh0VGFnLSBQaGFudEZ1
bmMtIEF1eFB3ci0gTm9Tbm9vcC0NCgkJCU1heFBheWxvYWQgMTI4IGJ5dGVzLCBNYXhSZWFk
UmVxIDQwOTYgYnl0ZXMNCgkJRGV2U3RhOglDb3JyRXJyKyBVbmNvcnJFcnItIEZhdGFsRXJy
LSBVbnN1cHBSZXErIEF1eFB3cisgVHJhbnNQZW5kLQ0KCQlMbmtDYXA6CVBvcnQgIzAsIFNw
ZWVkIDIuNUdUL3MsIFdpZHRoIHgxLCBBU1BNIEwwcyBMMSwgTGF0ZW5jeSBMMCA8NTEybnMs
IEwxIDw2NHVzDQoJCQlDbG9ja1BNKyBTdXJwcmlzZS0gTExBY3RSZXAtIEJ3Tm90LQ0KCQlM
bmtDdGw6CUFTUE0gRGlzYWJsZWQ7IFJDQiA2NCBieXRlcyBEaXNhYmxlZC0gUmV0cmFpbi0g
Q29tbUNsaysNCgkJCUV4dFN5bmNoLSBDbG9ja1BNLSBBdXRXaWREaXMtIEJXSW50LSBBdXRC
V0ludC0NCgkJTG5rU3RhOglTcGVlZCAyLjVHVC9zLCBXaWR0aCB4MSwgVHJFcnItIFRyYWlu
LSBTbG90Q2xrKyBETEFjdGl2ZS0gQldNZ210LSBBQldNZ210LQ0KCQlEZXZDYXAyOiBDb21w
bGV0aW9uIFRpbWVvdXQ6IE5vdCBTdXBwb3J0ZWQsIFRpbWVvdXREaXMrDQoJCURldkN0bDI6
IENvbXBsZXRpb24gVGltZW91dDogNTB1cyB0byA1MG1zLCBUaW1lb3V0RGlzLQ0KCQlMbmtD
dGwyOiBUYXJnZXQgTGluayBTcGVlZDogMi41R1QvcywgRW50ZXJDb21wbGlhbmNlLSBTcGVl
ZERpcy0sIFNlbGVjdGFibGUgRGUtZW1waGFzaXM6IC02ZEINCgkJCSBUcmFuc21pdCBNYXJn
aW46IE5vcm1hbCBPcGVyYXRpbmcgUmFuZ2UsIEVudGVyTW9kaWZpZWRDb21wbGlhbmNlLSBD
b21wbGlhbmNlU09TLQ0KCQkJIENvbXBsaWFuY2UgRGUtZW1waGFzaXM6IC02ZEINCgkJTG5r
U3RhMjogQ3VycmVudCBEZS1lbXBoYXNpcyBMZXZlbDogLTZkQg0KCUNhcGFiaWxpdGllczog
W2FjXSBNU0ktWDogRW5hYmxlLSBDb3VudD00IE1hc2tlZC0NCgkJVmVjdG9yIHRhYmxlOiBC
QVI9NCBvZmZzZXQ9MDAwMDAwMDANCgkJUEJBOiBCQVI9NCBvZmZzZXQ9MDAwMDA4MDANCglD
YXBhYmlsaXRpZXM6IFtjY10gVml0YWwgUHJvZHVjdCBEYXRhDQoJCVVua25vd24gc21hbGwg
cmVzb3VyY2UgdHlwZSAwMCwgd2lsbCBub3QgZGVjb2RlIG1vcmUuDQoJQ2FwYWJpbGl0aWVz
OiBbMTAwIHYxXSBBZHZhbmNlZCBFcnJvciBSZXBvcnRpbmcNCgkJVUVTdGE6CURMUC0gU0RF
Uy0gVExQLSBGQ1AtIENtcGx0VE8tIENtcGx0QWJydC0gVW54Q21wbHQtIFJ4T0YtIE1hbGZU
TFAtIEVDUkMtIFVuc3VwUmVxLSBBQ1NWaW9sLQ0KCQlVRU1zazoJRExQLSBTREVTLSBUTFAt
IEZDUC0gQ21wbHRUTy0gQ21wbHRBYnJ0LSBVbnhDbXBsdC0gUnhPRi0gTWFsZlRMUC0gRUNS
Qy0gVW5zdXBSZXEtIEFDU1Zpb2wtDQoJCVVFU3ZydDoJRExQKyBTREVTKyBUTFAtIEZDUCsg
Q21wbHRUTy0gQ21wbHRBYnJ0LSBVbnhDbXBsdC0gUnhPRisgTWFsZlRMUCsgRUNSQy0gVW5z
dXBSZXEtIEFDU1Zpb2wtDQoJCUNFU3RhOglSeEVycisgQmFkVExQLSBCYWRETExQLSBSb2xs
b3Zlci0gVGltZW91dC0gTm9uRmF0YWxFcnIrDQoJCUNFTXNrOglSeEVyci0gQmFkVExQLSBC
YWRETExQLSBSb2xsb3Zlci0gVGltZW91dC0gTm9uRmF0YWxFcnIrDQoJCUFFUkNhcDoJRmly
c3QgRXJyb3IgUG9pbnRlcjogMDAsIEdlbkNhcCsgQ0dlbkVuLSBDaGtDYXArIENoa0VuLQ0K
CUNhcGFiaWxpdGllczogWzE0MCB2MV0gVmlydHVhbCBDaGFubmVsDQoJCUNhcHM6CUxQRVZD
PTAgUmVmQ2xrPTEwMG5zIFBBVEVudHJ5Qml0cz0xDQoJCUFyYjoJRml4ZWQtIFdSUjMyLSBX
UlI2NC0gV1JSMTI4LQ0KCQlDdHJsOglBcmJTZWxlY3Q9Rml4ZWQNCgkJU3RhdHVzOglJblBy
b2dyZXNzLQ0KCQlWQzA6CUNhcHM6CVBBVE9mZnNldD0wMCBNYXhUaW1lU2xvdHM9MSBSZWpT
bm9vcFRyYW5zLQ0KCQkJQXJiOglGaXhlZC0gV1JSMzItIFdSUjY0LSBXUlIxMjgtIFRXUlIx
MjgtIFdSUjI1Ni0NCgkJCUN0cmw6CUVuYWJsZSsgSUQ9MCBBcmJTZWxlY3Q9Rml4ZWQgVEMv
VkM9ZmYNCgkJCVN0YXR1czoJTmVnb1BlbmRpbmctIEluUHJvZ3Jlc3MtDQoJQ2FwYWJpbGl0
aWVzOiBbMTYwIHYxXSBEZXZpY2UgU2VyaWFsIE51bWJlciAwNC0wMC0wMC0wMC02OC00Yy1l
MC0wMA0KCUtlcm5lbCBkcml2ZXIgaW4gdXNlOiByODE2OQ0KDQowYTowMC4wIFVTQiBjb250
cm9sbGVyIFswYzAzXTogTmV0TW9zIFRlY2hub2xvZ3kgTUNTOTk5MCBQQ0llIHRvIDTigJBQ
b3J0IFVTQiAyLjAgSG9zdCBDb250cm9sbGVyIFs5NzEwOjk5OTBdIChwcm9nLWlmIDEwIFtP
SENJXSkNCglTdWJzeXN0ZW06IERldmljZSBbYTAwMDo0MDAwXQ0KCUNvbnRyb2w6IEkvTy0g
TWVtKyBCdXNNYXN0ZXIrIFNwZWNDeWNsZS0gTWVtV0lOVi0gVkdBU25vb3AtIFBhckVyci0g
U3RlcHBpbmctIFNFUlItIEZhc3RCMkItIERpc0lOVHgtDQoJU3RhdHVzOiBDYXArIDY2TUh6
LSBVREYtIEZhc3RCMkItIFBhckVyci0gREVWU0VMPWZhc3QgPlRBYm9ydC0gPFRBYm9ydC0g
PE1BYm9ydC0gPlNFUlItIDxQRVJSLSBJTlR4LQ0KCUxhdGVuY3k6IDAsIENhY2hlIExpbmUg
U2l6ZTogNjQgYnl0ZXMNCglJbnRlcnJ1cHQ6IHBpbiBBIHJvdXRlZCB0byBJUlEgMjgNCglS
ZWdpb24gMDogTWVtb3J5IGF0IGY5ZmY4MDAwICgzMi1iaXQsIG5vbi1wcmVmZXRjaGFibGUp
IFtzaXplPTRLXQ0KCUNhcGFiaWxpdGllczogWzUwXSBNU0k6IEVuYWJsZS0gQ291bnQ9MS8x
IE1hc2thYmxlLSA2NGJpdCsNCgkJQWRkcmVzczogMDAwMDAwMDAwMDAwMDAwMCAgRGF0YTog
MDAwMA0KCUNhcGFiaWxpdGllczogWzc4XSBQb3dlciBNYW5hZ2VtZW50IHZlcnNpb24gMw0K
CQlGbGFnczogUE1FQ2xrLSBEU0ktIEQxKyBEMisgQXV4Q3VycmVudD0zNzVtQSBQTUUoRDAr
LEQxKyxEMissRDNob3QrLEQzY29sZC0pDQoJCVN0YXR1czogRDAgTm9Tb2Z0UnN0KyBQTUUt
RW5hYmxlLSBEU2VsPTAgRFNjYWxlPTAgUE1FLQ0KCUNhcGFiaWxpdGllczogWzgwXSBFeHBy
ZXNzICh2MSkgRW5kcG9pbnQsIE1TSSAwMA0KCQlEZXZDYXA6CU1heFBheWxvYWQgMjU2IGJ5
dGVzLCBQaGFudEZ1bmMgMCwgTGF0ZW5jeSBMMHMgdW5saW1pdGVkLCBMMSB1bmxpbWl0ZWQN
CgkJCUV4dFRhZy0gQXR0bkJ0bi0gQXR0bkluZC0gUHdySW5kLSBSQkUrIEZMUmVzZXQtDQoJ
CURldkN0bDoJUmVwb3J0IGVycm9yczogQ29ycmVjdGFibGUtIE5vbi1GYXRhbC0gRmF0YWwt
IFVuc3VwcG9ydGVkLQ0KCQkJUmx4ZE9yZC0gRXh0VGFnLSBQaGFudEZ1bmMtIEF1eFB3ci0g
Tm9Tbm9vcCsNCgkJCU1heFBheWxvYWQgMTI4IGJ5dGVzLCBNYXhSZWFkUmVxIDUxMiBieXRl
cw0KCQlEZXZTdGE6CUNvcnJFcnItIFVuY29yckVyci0gRmF0YWxFcnItIFVuc3VwcFJlcS0g
QXV4UHdyLSBUcmFuc1BlbmQtDQoJCUxua0NhcDoJUG9ydCAjMSwgU3BlZWQgMi41R1Qvcywg
V2lkdGggeDEsIEFTUE0gdW5rbm93biwgTGF0ZW5jeSBMMCA8NjRucywgTDEgdW5saW1pdGVk
DQoJCQlDbG9ja1BNKyBTdXJwcmlzZS0gTExBY3RSZXAtIEJ3Tm90LQ0KCQlMbmtDdGw6CUFT
UE0gRGlzYWJsZWQ7IFJDQiA2NCBieXRlcyBEaXNhYmxlZC0gUmV0cmFpbi0gQ29tbUNsay0N
CgkJCUV4dFN5bmNoLSBDbG9ja1BNLSBBdXRXaWREaXMtIEJXSW50LSBBdXRCV0ludC0NCgkJ
TG5rU3RhOglTcGVlZCAyLjVHVC9zLCBXaWR0aCB4MSwgVHJFcnItIFRyYWluLSBTbG90Q2xr
LSBETEFjdGl2ZS0gQldNZ210LSBBQldNZ210LQ0KCUNhcGFiaWxpdGllczogWzEwMCB2MV0g
VmlydHVhbCBDaGFubmVsDQoJCUNhcHM6CUxQRVZDPTAgUmVmQ2xrPTEwMG5zIFBBVEVudHJ5
Qml0cz0xDQoJCUFyYjoJRml4ZWQtIFdSUjMyLSBXUlI2NC0gV1JSMTI4LQ0KCQlDdHJsOglB
cmJTZWxlY3Q9Rml4ZWQNCgkJU3RhdHVzOglJblByb2dyZXNzLQ0KCQlWQzA6CUNhcHM6CVBB
VE9mZnNldD0wMCBNYXhUaW1lU2xvdHM9MSBSZWpTbm9vcFRyYW5zLQ0KCQkJQXJiOglGaXhl
ZC0gV1JSMzItIFdSUjY0LSBXUlIxMjgtIFRXUlIxMjgtIFdSUjI1Ni0NCgkJCUN0cmw6CUVu
YWJsZSsgSUQ9MCBBcmJTZWxlY3Q9Rml4ZWQgVEMvVkM9ZmYNCgkJCVN0YXR1czoJTmVnb1Bl
bmRpbmctIEluUHJvZ3Jlc3MtDQoJS2VybmVsIGRyaXZlciBpbiB1c2U6IHBjaWJhY2sNCg0K
MGE6MDAuMSBVU0IgY29udHJvbGxlciBbMGMwM106IE5ldE1vcyBUZWNobm9sb2d5IE1DUzk5
OTAgUENJZSB0byA04oCQUG9ydCBVU0IgMi4wIEhvc3QgQ29udHJvbGxlciBbOTcxMDo5OTkw
XSAocHJvZy1pZiAyMCBbRUhDSV0pDQoJU3Vic3lzdGVtOiBEZXZpY2UgW2EwMDA6NDAwMF0N
CglDb250cm9sOiBJL08tIE1lbSsgQnVzTWFzdGVyKyBTcGVjQ3ljbGUtIE1lbVdJTlYtIFZH
QVNub29wLSBQYXJFcnItIFN0ZXBwaW5nLSBTRVJSLSBGYXN0QjJCLSBEaXNJTlR4LQ0KCVN0
YXR1czogQ2FwKyA2Nk1Iei0gVURGLSBGYXN0QjJCLSBQYXJFcnItIERFVlNFTD1mYXN0ID5U
QWJvcnQtIDxUQWJvcnQtIDxNQWJvcnQtID5TRVJSLSA8UEVSUi0gSU5UeC0NCglMYXRlbmN5
OiAwLCBDYWNoZSBMaW5lIFNpemU6IDY0IGJ5dGVzDQoJSW50ZXJydXB0OiBwaW4gQSByb3V0
ZWQgdG8gSVJRIDI4DQoJUmVnaW9uIDA6IE1lbW9yeSBhdCBmOWZmOTAwMCAoMzItYml0LCBu
b24tcHJlZmV0Y2hhYmxlKSBbc2l6ZT00S10NCglDYXBhYmlsaXRpZXM6IFs1MF0gTVNJOiBF
bmFibGUtIENvdW50PTEvMSBNYXNrYWJsZS0gNjRiaXQrDQoJCUFkZHJlc3M6IDAwMDAwMDAw
MDAwMDAwMDAgIERhdGE6IDAwMDANCglDYXBhYmlsaXRpZXM6IFs3OF0gUG93ZXIgTWFuYWdl
bWVudCB2ZXJzaW9uIDMNCgkJRmxhZ3M6IFBNRUNsay0gRFNJLSBEMSsgRDIrIEF1eEN1cnJl
bnQ9Mzc1bUEgUE1FKEQwKyxEMSssRDIrLEQzaG90KyxEM2NvbGQtKQ0KCQlTdGF0dXM6IEQw
IE5vU29mdFJzdCsgUE1FLUVuYWJsZS0gRFNlbD0wIERTY2FsZT0wIFBNRS0NCglDYXBhYmls
aXRpZXM6IFs4MF0gRXhwcmVzcyAodjEpIEVuZHBvaW50LCBNU0kgMDANCgkJRGV2Q2FwOglN
YXhQYXlsb2FkIDI1NiBieXRlcywgUGhhbnRGdW5jIDAsIExhdGVuY3kgTDBzIHVubGltaXRl
ZCwgTDEgdW5saW1pdGVkDQoJCQlFeHRUYWctIEF0dG5CdG4tIEF0dG5JbmQtIFB3ckluZC0g
UkJFKyBGTFJlc2V0LQ0KCQlEZXZDdGw6CVJlcG9ydCBlcnJvcnM6IENvcnJlY3RhYmxlLSBO
b24tRmF0YWwtIEZhdGFsLSBVbnN1cHBvcnRlZC0NCgkJCVJseGRPcmQtIEV4dFRhZy0gUGhh
bnRGdW5jLSBBdXhQd3ItIE5vU25vb3ArDQoJCQlNYXhQYXlsb2FkIDEyOCBieXRlcywgTWF4
UmVhZFJlcSA1MTIgYnl0ZXMNCgkJRGV2U3RhOglDb3JyRXJyLSBVbmNvcnJFcnItIEZhdGFs
RXJyLSBVbnN1cHBSZXEtIEF1eFB3ci0gVHJhbnNQZW5kLQ0KCQlMbmtDYXA6CVBvcnQgIzEs
IFNwZWVkIDIuNUdUL3MsIFdpZHRoIHgxLCBBU1BNIHVua25vd24sIExhdGVuY3kgTDAgPDY0
bnMsIEwxIHVubGltaXRlZA0KCQkJQ2xvY2tQTSsgU3VycHJpc2UtIExMQWN0UmVwLSBCd05v
dC0NCgkJTG5rQ3RsOglBU1BNIERpc2FibGVkOyBSQ0IgNjQgYnl0ZXMgRGlzYWJsZWQtIFJl
dHJhaW4tIENvbW1DbGstDQoJCQlFeHRTeW5jaC0gQ2xvY2tQTS0gQXV0V2lkRGlzLSBCV0lu
dC0gQXV0QldJbnQtDQoJCUxua1N0YToJU3BlZWQgMi41R1QvcywgV2lkdGggeDEsIFRyRXJy
LSBUcmFpbi0gU2xvdENsay0gRExBY3RpdmUtIEJXTWdtdC0gQUJXTWdtdC0NCglLZXJuZWwg
ZHJpdmVyIGluIHVzZTogcGNpYmFjaw0KDQowYTowMC4yIFVTQiBjb250cm9sbGVyIFswYzAz
XTogTmV0TW9zIFRlY2hub2xvZ3kgTUNTOTk5MCBQQ0llIHRvIDTigJBQb3J0IFVTQiAyLjAg
SG9zdCBDb250cm9sbGVyIFs5NzEwOjk5OTBdIChwcm9nLWlmIDEwIFtPSENJXSkNCglTdWJz
eXN0ZW06IERldmljZSBbYTAwMDo0MDAwXQ0KCUNvbnRyb2w6IEkvTy0gTWVtKyBCdXNNYXN0
ZXIrIFNwZWNDeWNsZS0gTWVtV0lOVi0gVkdBU25vb3AtIFBhckVyci0gU3RlcHBpbmctIFNF
UlItIEZhc3RCMkItIERpc0lOVHgtDQoJU3RhdHVzOiBDYXArIDY2TUh6LSBVREYtIEZhc3RC
MkItIFBhckVyci0gREVWU0VMPWZhc3QgPlRBYm9ydC0gPFRBYm9ydC0gPE1BYm9ydC0gPlNF
UlItIDxQRVJSLSBJTlR4LQ0KCUxhdGVuY3k6IDAsIENhY2hlIExpbmUgU2l6ZTogNjQgYnl0
ZXMNCglJbnRlcnJ1cHQ6IHBpbiBCIHJvdXRlZCB0byBJUlEgMjkNCglSZWdpb24gMDogTWVt
b3J5IGF0IGY5ZmZhMDAwICgzMi1iaXQsIG5vbi1wcmVmZXRjaGFibGUpIFtzaXplPTRLXQ0K
CUNhcGFiaWxpdGllczogWzUwXSBNU0k6IEVuYWJsZS0gQ291bnQ9MS8xIE1hc2thYmxlLSA2
NGJpdCsNCgkJQWRkcmVzczogMDAwMDAwMDAwMDAwMDAwMCAgRGF0YTogMDAwMA0KCUNhcGFi
aWxpdGllczogWzc4XSBQb3dlciBNYW5hZ2VtZW50IHZlcnNpb24gMw0KCQlGbGFnczogUE1F
Q2xrLSBEU0ktIEQxKyBEMisgQXV4Q3VycmVudD0zNzVtQSBQTUUoRDArLEQxKyxEMissRDNo
b3QrLEQzY29sZC0pDQoJCVN0YXR1czogRDAgTm9Tb2Z0UnN0KyBQTUUtRW5hYmxlLSBEU2Vs
PTAgRFNjYWxlPTAgUE1FLQ0KCUNhcGFiaWxpdGllczogWzgwXSBFeHByZXNzICh2MSkgRW5k
cG9pbnQsIE1TSSAwMA0KCQlEZXZDYXA6CU1heFBheWxvYWQgMjU2IGJ5dGVzLCBQaGFudEZ1
bmMgMCwgTGF0ZW5jeSBMMHMgdW5saW1pdGVkLCBMMSB1bmxpbWl0ZWQNCgkJCUV4dFRhZy0g
QXR0bkJ0bi0gQXR0bkluZC0gUHdySW5kLSBSQkUrIEZMUmVzZXQtDQoJCURldkN0bDoJUmVw
b3J0IGVycm9yczogQ29ycmVjdGFibGUtIE5vbi1GYXRhbC0gRmF0YWwtIFVuc3VwcG9ydGVk
LQ0KCQkJUmx4ZE9yZC0gRXh0VGFnLSBQaGFudEZ1bmMtIEF1eFB3ci0gTm9Tbm9vcCsNCgkJ
CU1heFBheWxvYWQgMTI4IGJ5dGVzLCBNYXhSZWFkUmVxIDUxMiBieXRlcw0KCQlEZXZTdGE6
CUNvcnJFcnItIFVuY29yckVyci0gRmF0YWxFcnItIFVuc3VwcFJlcS0gQXV4UHdyLSBUcmFu
c1BlbmQtDQoJCUxua0NhcDoJUG9ydCAjMSwgU3BlZWQgMi41R1QvcywgV2lkdGggeDEsIEFT
UE0gdW5rbm93biwgTGF0ZW5jeSBMMCA8NjRucywgTDEgdW5saW1pdGVkDQoJCQlDbG9ja1BN
KyBTdXJwcmlzZS0gTExBY3RSZXAtIEJ3Tm90LQ0KCQlMbmtDdGw6CUFTUE0gRGlzYWJsZWQ7
IFJDQiA2NCBieXRlcyBEaXNhYmxlZC0gUmV0cmFpbi0gQ29tbUNsay0NCgkJCUV4dFN5bmNo
LSBDbG9ja1BNLSBBdXRXaWREaXMtIEJXSW50LSBBdXRCV0ludC0NCgkJTG5rU3RhOglTcGVl
ZCAyLjVHVC9zLCBXaWR0aCB4MSwgVHJFcnItIFRyYWluLSBTbG90Q2xrLSBETEFjdGl2ZS0g
QldNZ210LSBBQldNZ210LQ0KCUtlcm5lbCBkcml2ZXIgaW4gdXNlOiBwY2liYWNrDQoNCjBh
OjAwLjMgVVNCIGNvbnRyb2xsZXIgWzBjMDNdOiBOZXRNb3MgVGVjaG5vbG9neSBNQ1M5OTkw
IFBDSWUgdG8gNOKAkFBvcnQgVVNCIDIuMCBIb3N0IENvbnRyb2xsZXIgWzk3MTA6OTk5MF0g
KHByb2ctaWYgMjAgW0VIQ0ldKQ0KCVN1YnN5c3RlbTogRGV2aWNlIFthMDAwOjQwMDBdDQoJ
Q29udHJvbDogSS9PLSBNZW0rIEJ1c01hc3RlcisgU3BlY0N5Y2xlLSBNZW1XSU5WLSBWR0FT
bm9vcC0gUGFyRXJyLSBTdGVwcGluZy0gU0VSUi0gRmFzdEIyQi0gRGlzSU5UeC0NCglTdGF0
dXM6IENhcCsgNjZNSHotIFVERi0gRmFzdEIyQi0gUGFyRXJyLSBERVZTRUw9ZmFzdCA+VEFi
b3J0LSA8VEFib3J0LSA8TUFib3J0LSA+U0VSUi0gPFBFUlItIElOVHgtDQoJTGF0ZW5jeTog
MCwgQ2FjaGUgTGluZSBTaXplOiA2NCBieXRlcw0KCUludGVycnVwdDogcGluIEIgcm91dGVk
IHRvIElSUSAyOQ0KCVJlZ2lvbiAwOiBNZW1vcnkgYXQgZjlmZmIwMDAgKDMyLWJpdCwgbm9u
LXByZWZldGNoYWJsZSkgW3NpemU9NEtdDQoJQ2FwYWJpbGl0aWVzOiBbNTBdIE1TSTogRW5h
YmxlLSBDb3VudD0xLzEgTWFza2FibGUtIDY0Yml0Kw0KCQlBZGRyZXNzOiAwMDAwMDAwMDAw
MDAwMDAwICBEYXRhOiAwMDAwDQoJQ2FwYWJpbGl0aWVzOiBbNzhdIFBvd2VyIE1hbmFnZW1l
bnQgdmVyc2lvbiAzDQoJCUZsYWdzOiBQTUVDbGstIERTSS0gRDErIEQyKyBBdXhDdXJyZW50
PTM3NW1BIFBNRShEMCssRDErLEQyKyxEM2hvdCssRDNjb2xkLSkNCgkJU3RhdHVzOiBEMCBO
b1NvZnRSc3QrIFBNRS1FbmFibGUtIERTZWw9MCBEU2NhbGU9MCBQTUUtDQoJQ2FwYWJpbGl0
aWVzOiBbODBdIEV4cHJlc3MgKHYxKSBFbmRwb2ludCwgTVNJIDAwDQoJCURldkNhcDoJTWF4
UGF5bG9hZCAyNTYgYnl0ZXMsIFBoYW50RnVuYyAwLCBMYXRlbmN5IEwwcyB1bmxpbWl0ZWQs
IEwxIHVubGltaXRlZA0KCQkJRXh0VGFnLSBBdHRuQnRuLSBBdHRuSW5kLSBQd3JJbmQtIFJC
RSsgRkxSZXNldC0NCgkJRGV2Q3RsOglSZXBvcnQgZXJyb3JzOiBDb3JyZWN0YWJsZS0gTm9u
LUZhdGFsLSBGYXRhbC0gVW5zdXBwb3J0ZWQtDQoJCQlSbHhkT3JkLSBFeHRUYWctIFBoYW50
RnVuYy0gQXV4UHdyLSBOb1Nub29wKw0KCQkJTWF4UGF5bG9hZCAxMjggYnl0ZXMsIE1heFJl
YWRSZXEgNTEyIGJ5dGVzDQoJCURldlN0YToJQ29yckVyci0gVW5jb3JyRXJyLSBGYXRhbEVy
ci0gVW5zdXBwUmVxLSBBdXhQd3ItIFRyYW5zUGVuZC0NCgkJTG5rQ2FwOglQb3J0ICMxLCBT
cGVlZCAyLjVHVC9zLCBXaWR0aCB4MSwgQVNQTSB1bmtub3duLCBMYXRlbmN5IEwwIDw2NG5z
LCBMMSB1bmxpbWl0ZWQNCgkJCUNsb2NrUE0rIFN1cnByaXNlLSBMTEFjdFJlcC0gQndOb3Qt
DQoJCUxua0N0bDoJQVNQTSBEaXNhYmxlZDsgUkNCIDY0IGJ5dGVzIERpc2FibGVkLSBSZXRy
YWluLSBDb21tQ2xrLQ0KCQkJRXh0U3luY2gtIENsb2NrUE0tIEF1dFdpZERpcy0gQldJbnQt
IEF1dEJXSW50LQ0KCQlMbmtTdGE6CVNwZWVkIDIuNUdUL3MsIFdpZHRoIHgxLCBUckVyci0g
VHJhaW4tIFNsb3RDbGstIERMQWN0aXZlLSBCV01nbXQtIEFCV01nbXQtDQoJS2VybmVsIGRy
aXZlciBpbiB1c2U6IHBjaWJhY2sNCg0KMGE6MDAuNCBVU0IgY29udHJvbGxlciBbMGMwM106
IE5ldE1vcyBUZWNobm9sb2d5IE1DUzk5OTAgUENJZSB0byA04oCQUG9ydCBVU0IgMi4wIEhv
c3QgQ29udHJvbGxlciBbOTcxMDo5OTkwXSAocHJvZy1pZiAxMCBbT0hDSV0pDQoJU3Vic3lz
dGVtOiBEZXZpY2UgW2EwMDA6NDAwMF0NCglDb250cm9sOiBJL08tIE1lbSsgQnVzTWFzdGVy
KyBTcGVjQ3ljbGUtIE1lbVdJTlYtIFZHQVNub29wLSBQYXJFcnItIFN0ZXBwaW5nLSBTRVJS
LSBGYXN0QjJCLSBEaXNJTlR4LQ0KCVN0YXR1czogQ2FwKyA2Nk1Iei0gVURGLSBGYXN0QjJC
LSBQYXJFcnItIERFVlNFTD1mYXN0ID5UQWJvcnQtIDxUQWJvcnQtIDxNQWJvcnQtID5TRVJS
LSA8UEVSUi0gSU5UeC0NCglMYXRlbmN5OiAwLCBDYWNoZSBMaW5lIFNpemU6IDY0IGJ5dGVz
DQoJSW50ZXJydXB0OiBwaW4gQyByb3V0ZWQgdG8gSVJRIDMwDQoJUmVnaW9uIDA6IE1lbW9y
eSBhdCBmOWZmYzAwMCAoMzItYml0LCBub24tcHJlZmV0Y2hhYmxlKSBbc2l6ZT00S10NCglD
YXBhYmlsaXRpZXM6IFs1MF0gTVNJOiBFbmFibGUtIENvdW50PTEvMSBNYXNrYWJsZS0gNjRi
aXQrDQoJCUFkZHJlc3M6IDAwMDAwMDAwMDAwMDAwMDAgIERhdGE6IDAwMDANCglDYXBhYmls
aXRpZXM6IFs3OF0gUG93ZXIgTWFuYWdlbWVudCB2ZXJzaW9uIDMNCgkJRmxhZ3M6IFBNRUNs
ay0gRFNJLSBEMSsgRDIrIEF1eEN1cnJlbnQ9Mzc1bUEgUE1FKEQwKyxEMSssRDIrLEQzaG90
KyxEM2NvbGQtKQ0KCQlTdGF0dXM6IEQwIE5vU29mdFJzdCsgUE1FLUVuYWJsZS0gRFNlbD0w
IERTY2FsZT0wIFBNRS0NCglDYXBhYmlsaXRpZXM6IFs4MF0gRXhwcmVzcyAodjEpIEVuZHBv
aW50LCBNU0kgMDANCgkJRGV2Q2FwOglNYXhQYXlsb2FkIDI1NiBieXRlcywgUGhhbnRGdW5j
IDAsIExhdGVuY3kgTDBzIHVubGltaXRlZCwgTDEgdW5saW1pdGVkDQoJCQlFeHRUYWctIEF0
dG5CdG4tIEF0dG5JbmQtIFB3ckluZC0gUkJFKyBGTFJlc2V0LQ0KCQlEZXZDdGw6CVJlcG9y
dCBlcnJvcnM6IENvcnJlY3RhYmxlLSBOb24tRmF0YWwtIEZhdGFsLSBVbnN1cHBvcnRlZC0N
CgkJCVJseGRPcmQtIEV4dFRhZy0gUGhhbnRGdW5jLSBBdXhQd3ItIE5vU25vb3ArDQoJCQlN
YXhQYXlsb2FkIDEyOCBieXRlcywgTWF4UmVhZFJlcSA1MTIgYnl0ZXMNCgkJRGV2U3RhOglD
b3JyRXJyLSBVbmNvcnJFcnItIEZhdGFsRXJyLSBVbnN1cHBSZXEtIEF1eFB3ci0gVHJhbnNQ
ZW5kLQ0KCQlMbmtDYXA6CVBvcnQgIzEsIFNwZWVkIDIuNUdUL3MsIFdpZHRoIHgxLCBBU1BN
IHVua25vd24sIExhdGVuY3kgTDAgPDY0bnMsIEwxIHVubGltaXRlZA0KCQkJQ2xvY2tQTSsg
U3VycHJpc2UtIExMQWN0UmVwLSBCd05vdC0NCgkJTG5rQ3RsOglBU1BNIERpc2FibGVkOyBS
Q0IgNjQgYnl0ZXMgRGlzYWJsZWQtIFJldHJhaW4tIENvbW1DbGstDQoJCQlFeHRTeW5jaC0g
Q2xvY2tQTS0gQXV0V2lkRGlzLSBCV0ludC0gQXV0QldJbnQtDQoJCUxua1N0YToJU3BlZWQg
Mi41R1QvcywgV2lkdGggeDEsIFRyRXJyLSBUcmFpbi0gU2xvdENsay0gRExBY3RpdmUtIEJX
TWdtdC0gQUJXTWdtdC0NCglLZXJuZWwgZHJpdmVyIGluIHVzZTogcGNpYmFjaw0KDQowYTow
MC41IFVTQiBjb250cm9sbGVyIFswYzAzXTogTmV0TW9zIFRlY2hub2xvZ3kgTUNTOTk5MCBQ
Q0llIHRvIDTigJBQb3J0IFVTQiAyLjAgSG9zdCBDb250cm9sbGVyIFs5NzEwOjk5OTBdIChw
cm9nLWlmIDIwIFtFSENJXSkNCglTdWJzeXN0ZW06IERldmljZSBbYTAwMDo0MDAwXQ0KCUNv
bnRyb2w6IEkvTy0gTWVtKyBCdXNNYXN0ZXIrIFNwZWNDeWNsZS0gTWVtV0lOVi0gVkdBU25v
b3AtIFBhckVyci0gU3RlcHBpbmctIFNFUlItIEZhc3RCMkItIERpc0lOVHgtDQoJU3RhdHVz
OiBDYXArIDY2TUh6LSBVREYtIEZhc3RCMkItIFBhckVyci0gREVWU0VMPWZhc3QgPlRBYm9y
dC0gPFRBYm9ydC0gPE1BYm9ydC0gPlNFUlItIDxQRVJSLSBJTlR4LQ0KCUxhdGVuY3k6IDAs
IENhY2hlIExpbmUgU2l6ZTogNjQgYnl0ZXMNCglJbnRlcnJ1cHQ6IHBpbiBDIHJvdXRlZCB0
byBJUlEgMzANCglSZWdpb24gMDogTWVtb3J5IGF0IGY5ZmZkMDAwICgzMi1iaXQsIG5vbi1w
cmVmZXRjaGFibGUpIFtzaXplPTRLXQ0KCUNhcGFiaWxpdGllczogWzUwXSBNU0k6IEVuYWJs
ZS0gQ291bnQ9MS8xIE1hc2thYmxlLSA2NGJpdCsNCgkJQWRkcmVzczogMDAwMDAwMDAwMDAw
MDAwMCAgRGF0YTogMDAwMA0KCUNhcGFiaWxpdGllczogWzc4XSBQb3dlciBNYW5hZ2VtZW50
IHZlcnNpb24gMw0KCQlGbGFnczogUE1FQ2xrLSBEU0ktIEQxKyBEMisgQXV4Q3VycmVudD0z
NzVtQSBQTUUoRDArLEQxKyxEMissRDNob3QrLEQzY29sZC0pDQoJCVN0YXR1czogRDAgTm9T
b2Z0UnN0KyBQTUUtRW5hYmxlLSBEU2VsPTAgRFNjYWxlPTAgUE1FLQ0KCUNhcGFiaWxpdGll
czogWzgwXSBFeHByZXNzICh2MSkgRW5kcG9pbnQsIE1TSSAwMA0KCQlEZXZDYXA6CU1heFBh
eWxvYWQgMjU2IGJ5dGVzLCBQaGFudEZ1bmMgMCwgTGF0ZW5jeSBMMHMgdW5saW1pdGVkLCBM
MSB1bmxpbWl0ZWQNCgkJCUV4dFRhZy0gQXR0bkJ0bi0gQXR0bkluZC0gUHdySW5kLSBSQkUr
IEZMUmVzZXQtDQoJCURldkN0bDoJUmVwb3J0IGVycm9yczogQ29ycmVjdGFibGUtIE5vbi1G
YXRhbC0gRmF0YWwtIFVuc3VwcG9ydGVkLQ0KCQkJUmx4ZE9yZC0gRXh0VGFnLSBQaGFudEZ1
bmMtIEF1eFB3ci0gTm9Tbm9vcCsNCgkJCU1heFBheWxvYWQgMTI4IGJ5dGVzLCBNYXhSZWFk
UmVxIDUxMiBieXRlcw0KCQlEZXZTdGE6CUNvcnJFcnItIFVuY29yckVyci0gRmF0YWxFcnIt
IFVuc3VwcFJlcS0gQXV4UHdyLSBUcmFuc1BlbmQtDQoJCUxua0NhcDoJUG9ydCAjMSwgU3Bl
ZWQgMi41R1QvcywgV2lkdGggeDEsIEFTUE0gdW5rbm93biwgTGF0ZW5jeSBMMCA8NjRucywg
TDEgdW5saW1pdGVkDQoJCQlDbG9ja1BNKyBTdXJwcmlzZS0gTExBY3RSZXAtIEJ3Tm90LQ0K
CQlMbmtDdGw6CUFTUE0gRGlzYWJsZWQ7IFJDQiA2NCBieXRlcyBEaXNhYmxlZC0gUmV0cmFp
bi0gQ29tbUNsay0NCgkJCUV4dFN5bmNoLSBDbG9ja1BNLSBBdXRXaWREaXMtIEJXSW50LSBB
dXRCV0ludC0NCgkJTG5rU3RhOglTcGVlZCAyLjVHVC9zLCBXaWR0aCB4MSwgVHJFcnItIFRy
YWluLSBTbG90Q2xrLSBETEFjdGl2ZS0gQldNZ210LSBBQldNZ210LQ0KCUtlcm5lbCBkcml2
ZXIgaW4gdXNlOiBwY2liYWNrDQoNCjBhOjAwLjYgVVNCIGNvbnRyb2xsZXIgWzBjMDNdOiBO
ZXRNb3MgVGVjaG5vbG9neSBNQ1M5OTkwIFBDSWUgdG8gNOKAkFBvcnQgVVNCIDIuMCBIb3N0
IENvbnRyb2xsZXIgWzk3MTA6OTk5MF0gKHByb2ctaWYgMTAgW09IQ0ldKQ0KCVN1YnN5c3Rl
bTogRGV2aWNlIFthMDAwOjQwMDBdDQoJQ29udHJvbDogSS9PLSBNZW0rIEJ1c01hc3Rlcisg
U3BlY0N5Y2xlLSBNZW1XSU5WLSBWR0FTbm9vcC0gUGFyRXJyLSBTdGVwcGluZy0gU0VSUi0g
RmFzdEIyQi0gRGlzSU5UeC0NCglTdGF0dXM6IENhcCsgNjZNSHotIFVERi0gRmFzdEIyQi0g
UGFyRXJyLSBERVZTRUw9ZmFzdCA+VEFib3J0LSA8VEFib3J0LSA8TUFib3J0LSA+U0VSUi0g
PFBFUlItIElOVHgtDQoJTGF0ZW5jeTogMCwgQ2FjaGUgTGluZSBTaXplOiA2NCBieXRlcw0K
CUludGVycnVwdDogcGluIEQgcm91dGVkIHRvIElSUSAzMQ0KCVJlZ2lvbiAwOiBNZW1vcnkg
YXQgZjlmZmUwMDAgKDMyLWJpdCwgbm9uLXByZWZldGNoYWJsZSkgW3NpemU9NEtdDQoJQ2Fw
YWJpbGl0aWVzOiBbNTBdIE1TSTogRW5hYmxlLSBDb3VudD0xLzEgTWFza2FibGUtIDY0Yml0
Kw0KCQlBZGRyZXNzOiAwMDAwMDAwMDAwMDAwMDAwICBEYXRhOiAwMDAwDQoJQ2FwYWJpbGl0
aWVzOiBbNzhdIFBvd2VyIE1hbmFnZW1lbnQgdmVyc2lvbiAzDQoJCUZsYWdzOiBQTUVDbGst
IERTSS0gRDErIEQyKyBBdXhDdXJyZW50PTM3NW1BIFBNRShEMCssRDErLEQyKyxEM2hvdCss
RDNjb2xkLSkNCgkJU3RhdHVzOiBEMCBOb1NvZnRSc3QrIFBNRS1FbmFibGUtIERTZWw9MCBE
U2NhbGU9MCBQTUUtDQoJQ2FwYWJpbGl0aWVzOiBbODBdIEV4cHJlc3MgKHYxKSBFbmRwb2lu
dCwgTVNJIDAwDQoJCURldkNhcDoJTWF4UGF5bG9hZCAyNTYgYnl0ZXMsIFBoYW50RnVuYyAw
LCBMYXRlbmN5IEwwcyB1bmxpbWl0ZWQsIEwxIHVubGltaXRlZA0KCQkJRXh0VGFnLSBBdHRu
QnRuLSBBdHRuSW5kLSBQd3JJbmQtIFJCRSsgRkxSZXNldC0NCgkJRGV2Q3RsOglSZXBvcnQg
ZXJyb3JzOiBDb3JyZWN0YWJsZS0gTm9uLUZhdGFsLSBGYXRhbC0gVW5zdXBwb3J0ZWQtDQoJ
CQlSbHhkT3JkLSBFeHRUYWctIFBoYW50RnVuYy0gQXV4UHdyLSBOb1Nub29wKw0KCQkJTWF4
UGF5bG9hZCAxMjggYnl0ZXMsIE1heFJlYWRSZXEgNTEyIGJ5dGVzDQoJCURldlN0YToJQ29y
ckVyci0gVW5jb3JyRXJyLSBGYXRhbEVyci0gVW5zdXBwUmVxLSBBdXhQd3ItIFRyYW5zUGVu
ZC0NCgkJTG5rQ2FwOglQb3J0ICMxLCBTcGVlZCAyLjVHVC9zLCBXaWR0aCB4MSwgQVNQTSB1
bmtub3duLCBMYXRlbmN5IEwwIDw2NG5zLCBMMSB1bmxpbWl0ZWQNCgkJCUNsb2NrUE0rIFN1
cnByaXNlLSBMTEFjdFJlcC0gQndOb3QtDQoJCUxua0N0bDoJQVNQTSBEaXNhYmxlZDsgUkNC
IDY0IGJ5dGVzIERpc2FibGVkLSBSZXRyYWluLSBDb21tQ2xrLQ0KCQkJRXh0U3luY2gtIENs
b2NrUE0tIEF1dFdpZERpcy0gQldJbnQtIEF1dEJXSW50LQ0KCQlMbmtTdGE6CVNwZWVkIDIu
NUdUL3MsIFdpZHRoIHgxLCBUckVyci0gVHJhaW4tIFNsb3RDbGstIERMQWN0aXZlLSBCV01n
bXQtIEFCV01nbXQtDQoJS2VybmVsIGRyaXZlciBpbiB1c2U6IHBjaWJhY2sNCg0KMGE6MDAu
NyBVU0IgY29udHJvbGxlciBbMGMwM106IE5ldE1vcyBUZWNobm9sb2d5IE1DUzk5OTAgUENJ
ZSB0byA04oCQUG9ydCBVU0IgMi4wIEhvc3QgQ29udHJvbGxlciBbOTcxMDo5OTkwXSAocHJv
Zy1pZiAyMCBbRUhDSV0pDQoJU3Vic3lzdGVtOiBEZXZpY2UgW2EwMDA6NDAwMF0NCglDb250
cm9sOiBJL08tIE1lbSsgQnVzTWFzdGVyKyBTcGVjQ3ljbGUtIE1lbVdJTlYtIFZHQVNub29w
LSBQYXJFcnItIFN0ZXBwaW5nLSBTRVJSLSBGYXN0QjJCLSBEaXNJTlR4LQ0KCVN0YXR1czog
Q2FwKyA2Nk1Iei0gVURGLSBGYXN0QjJCLSBQYXJFcnItIERFVlNFTD1mYXN0ID5UQWJvcnQt
IDxUQWJvcnQtIDxNQWJvcnQtID5TRVJSLSA8UEVSUi0gSU5UeC0NCglMYXRlbmN5OiAwLCBD
YWNoZSBMaW5lIFNpemU6IDY0IGJ5dGVzDQoJSW50ZXJydXB0OiBwaW4gRCByb3V0ZWQgdG8g
SVJRIDMxDQoJUmVnaW9uIDA6IE1lbW9yeSBhdCBmOWZmZjAwMCAoMzItYml0LCBub24tcHJl
ZmV0Y2hhYmxlKSBbc2l6ZT00S10NCglDYXBhYmlsaXRpZXM6IFs1MF0gTVNJOiBFbmFibGUt
IENvdW50PTEvMSBNYXNrYWJsZS0gNjRiaXQrDQoJCUFkZHJlc3M6IDAwMDAwMDAwMDAwMDAw
MDAgIERhdGE6IDAwMDANCglDYXBhYmlsaXRpZXM6IFs3OF0gUG93ZXIgTWFuYWdlbWVudCB2
ZXJzaW9uIDMNCgkJRmxhZ3M6IFBNRUNsay0gRFNJLSBEMSsgRDIrIEF1eEN1cnJlbnQ9Mzc1
bUEgUE1FKEQwKyxEMSssRDIrLEQzaG90KyxEM2NvbGQtKQ0KCQlTdGF0dXM6IEQwIE5vU29m
dFJzdCsgUE1FLUVuYWJsZS0gRFNlbD0wIERTY2FsZT0wIFBNRS0NCglDYXBhYmlsaXRpZXM6
IFs4MF0gRXhwcmVzcyAodjEpIEVuZHBvaW50LCBNU0kgMDANCgkJRGV2Q2FwOglNYXhQYXls
b2FkIDI1NiBieXRlcywgUGhhbnRGdW5jIDAsIExhdGVuY3kgTDBzIHVubGltaXRlZCwgTDEg
dW5saW1pdGVkDQoJCQlFeHRUYWctIEF0dG5CdG4tIEF0dG5JbmQtIFB3ckluZC0gUkJFKyBG
TFJlc2V0LQ0KCQlEZXZDdGw6CVJlcG9ydCBlcnJvcnM6IENvcnJlY3RhYmxlLSBOb24tRmF0
YWwtIEZhdGFsLSBVbnN1cHBvcnRlZC0NCgkJCVJseGRPcmQtIEV4dFRhZy0gUGhhbnRGdW5j
LSBBdXhQd3ItIE5vU25vb3ArDQoJCQlNYXhQYXlsb2FkIDEyOCBieXRlcywgTWF4UmVhZFJl
cSA1MTIgYnl0ZXMNCgkJRGV2U3RhOglDb3JyRXJyLSBVbmNvcnJFcnItIEZhdGFsRXJyLSBV
bnN1cHBSZXEtIEF1eFB3ci0gVHJhbnNQZW5kLQ0KCQlMbmtDYXA6CVBvcnQgIzEsIFNwZWVk
IDIuNUdUL3MsIFdpZHRoIHgxLCBBU1BNIHVua25vd24sIExhdGVuY3kgTDAgPDY0bnMsIEwx
IHVubGltaXRlZA0KCQkJQ2xvY2tQTSsgU3VycHJpc2UtIExMQWN0UmVwLSBCd05vdC0NCgkJ
TG5rQ3RsOglBU1BNIERpc2FibGVkOyBSQ0IgNjQgYnl0ZXMgRGlzYWJsZWQtIFJldHJhaW4t
IENvbW1DbGstDQoJCQlFeHRTeW5jaC0gQ2xvY2tQTS0gQXV0V2lkRGlzLSBCV0ludC0gQXV0
QldJbnQtDQoJCUxua1N0YToJU3BlZWQgMi41R1QvcywgV2lkdGggeDEsIFRyRXJyLSBUcmFp
bi0gU2xvdENsay0gRExBY3RpdmUtIEJXTWdtdC0gQUJXTWdtdC0NCglLZXJuZWwgZHJpdmVy
IGluIHVzZTogcGNpYmFjaw0KDQowYjowMC4wIFZHQSBjb21wYXRpYmxlIGNvbnRyb2xsZXIg
WzAzMDBdOiBuVmlkaWEgQ29ycG9yYXRpb24gRzk4IFtHZUZvcmNlIDg0MDAgR1NdIFsxMGRl
OjA2ZTRdIChyZXYgYTEpIChwcm9nLWlmIDAwIFtWR0EgY29udHJvbGxlcl0pDQoJU3Vic3lz
dGVtOiBBU1VTVGVLIENvbXB1dGVyIEluYy4gRGV2aWNlIFsxMDQzOjgyNjZdDQoJQ29udHJv
bDogSS9PKyBNZW0rIEJ1c01hc3RlcisgU3BlY0N5Y2xlLSBNZW1XSU5WLSBWR0FTbm9vcC0g
UGFyRXJyLSBTdGVwcGluZy0gU0VSUisgRmFzdEIyQi0gRGlzSU5UeC0NCglTdGF0dXM6IENh
cCsgNjZNSHotIFVERi0gRmFzdEIyQi0gUGFyRXJyLSBERVZTRUw9ZmFzdCA+VEFib3J0LSA8
VEFib3J0LSA8TUFib3J0LSA+U0VSUi0gPFBFUlItIElOVHgtDQoJTGF0ZW5jeTogMCwgQ2Fj
aGUgTGluZSBTaXplOiA2NCBieXRlcw0KCUludGVycnVwdDogcGluIEEgcm91dGVkIHRvIElS
USAxMA0KCVJlZ2lvbiAwOiBNZW1vcnkgYXQgZmQwMDAwMDAgKDMyLWJpdCwgbm9uLXByZWZl
dGNoYWJsZSkgW3NpemU9MTZNXQ0KCVJlZ2lvbiAxOiBNZW1vcnkgYXQgZDAwMDAwMDAgKDY0
LWJpdCwgcHJlZmV0Y2hhYmxlKSBbc2l6ZT0yNTZNXQ0KCVJlZ2lvbiAzOiBNZW1vcnkgYXQg
ZmEwMDAwMDAgKDY0LWJpdCwgbm9uLXByZWZldGNoYWJsZSkgW3NpemU9MzJNXQ0KCVJlZ2lv
biA1OiBJL08gcG9ydHMgYXQgZTgwMCBbc2l6ZT0xMjhdDQoJRXhwYW5zaW9uIFJPTSBhdCBm
ZTllMDAwMCBbZGlzYWJsZWRdIFtzaXplPTEyOEtdDQoJQ2FwYWJpbGl0aWVzOiBbNjBdIFBv
d2VyIE1hbmFnZW1lbnQgdmVyc2lvbiAzDQoJCUZsYWdzOiBQTUVDbGstIERTSS0gRDEtIEQy
LSBBdXhDdXJyZW50PTBtQSBQTUUoRDAtLEQxLSxEMi0sRDNob3QtLEQzY29sZC0pDQoJCVN0
YXR1czogRDAgTm9Tb2Z0UnN0KyBQTUUtRW5hYmxlLSBEU2VsPTAgRFNjYWxlPTAgUE1FLQ0K
CUNhcGFiaWxpdGllczogWzY4XSBNU0k6IEVuYWJsZS0gQ291bnQ9MS8xIE1hc2thYmxlLSA2
NGJpdCsNCgkJQWRkcmVzczogMDAwMDAwMDAwMDAwMDAwMCAgRGF0YTogMDAwMA0KCUNhcGFi
aWxpdGllczogWzc4XSBFeHByZXNzICh2MSkgRW5kcG9pbnQsIE1TSSAwMA0KCQlEZXZDYXA6
CU1heFBheWxvYWQgMTI4IGJ5dGVzLCBQaGFudEZ1bmMgMCwgTGF0ZW5jeSBMMHMgPDUxMm5z
LCBMMSA8NHVzDQoJCQlFeHRUYWcrIEF0dG5CdG4tIEF0dG5JbmQtIFB3ckluZC0gUkJFKyBG
TFJlc2V0LQ0KCQlEZXZDdGw6CVJlcG9ydCBlcnJvcnM6IENvcnJlY3RhYmxlLSBOb24tRmF0
YWwtIEZhdGFsLSBVbnN1cHBvcnRlZC0NCgkJCVJseGRPcmQtIEV4dFRhZy0gUGhhbnRGdW5j
LSBBdXhQd3ItIE5vU25vb3ArDQoJCQlNYXhQYXlsb2FkIDEyOCBieXRlcywgTWF4UmVhZFJl
cSA1MTIgYnl0ZXMNCgkJRGV2U3RhOglDb3JyRXJyLSBVbmNvcnJFcnItIEZhdGFsRXJyLSBV
bnN1cHBSZXEtIEF1eFB3ci0gVHJhbnNQZW5kLQ0KCQlMbmtDYXA6CVBvcnQgIzAsIFNwZWVk
IDIuNUdUL3MsIFdpZHRoIHgxNiwgQVNQTSBMMHMgTDEsIExhdGVuY3kgTDAgPDUxMm5zLCBM
MSA8MXVzDQoJCQlDbG9ja1BNLSBTdXJwcmlzZS0gTExBY3RSZXAtIEJ3Tm90LQ0KCQlMbmtD
dGw6CUFTUE0gRGlzYWJsZWQ7IFJDQiAxMjggYnl0ZXMgRGlzYWJsZWQtIFJldHJhaW4tIENv
bW1DbGsrDQoJCQlFeHRTeW5jaC0gQ2xvY2tQTS0gQXV0V2lkRGlzLSBCV0ludC0gQXV0QldJ
bnQtDQoJCUxua1N0YToJU3BlZWQgMi41R1QvcywgV2lkdGggeDgsIFRyRXJyLSBUcmFpbi0g
U2xvdENsaysgRExBY3RpdmUtIEJXTWdtdC0gQUJXTWdtdC0NCglDYXBhYmlsaXRpZXM6IFsx
MDAgdjFdIFZpcnR1YWwgQ2hhbm5lbA0KCQlDYXBzOglMUEVWQz0wIFJlZkNsaz0xMDBucyBQ
QVRFbnRyeUJpdHM9MQ0KCQlBcmI6CUZpeGVkLSBXUlIzMi0gV1JSNjQtIFdSUjEyOC0NCgkJ
Q3RybDoJQXJiU2VsZWN0PUZpeGVkDQoJCVN0YXR1czoJSW5Qcm9ncmVzcy0NCgkJVkMwOglD
YXBzOglQQVRPZmZzZXQ9MDAgTWF4VGltZVNsb3RzPTEgUmVqU25vb3BUcmFucy0NCgkJCUFy
YjoJRml4ZWQtIFdSUjMyLSBXUlI2NC0gV1JSMTI4LSBUV1JSMTI4LSBXUlIyNTYtDQoJCQlD
dHJsOglFbmFibGUrIElEPTAgQXJiU2VsZWN0PUZpeGVkIFRDL1ZDPWZmDQoJCQlTdGF0dXM6
CU5lZ29QZW5kaW5nLSBJblByb2dyZXNzLQ0KCUNhcGFiaWxpdGllczogWzEyOCB2MV0gUG93
ZXIgQnVkZ2V0aW5nIDw/Pg0KCUNhcGFiaWxpdGllczogWzYwMCB2MV0gVmVuZG9yIFNwZWNp
ZmljIEluZm9ybWF0aW9uOiBJRD0wMDAxIFJldj0xIExlbj0wMjQgPD8+DQoNCg==
------------0E902503E1C6BF83E
Content-Type: text/plain;
 name="lspci-4.2.txt"
Content-transfer-encoding: base64
Content-Disposition: attachment;
 filename="lspci-4.2.txt"

MDA6MDAuMCBIb3N0IGJyaWRnZSBbMDYwMF06IEFUSSBUZWNobm9sb2dpZXMgSW5jIFJEODkw
IE5vcnRoYnJpZGdlIG9ubHkgc2luZ2xlIHNsb3QgUENJLWUgR0ZYIEh5ZHJhIHBhcnQgWzEw
MDI6NWExMV0gKHJldiAwMikNCglTdWJzeXN0ZW06IEFUSSBUZWNobm9sb2dpZXMgSW5jIFJE
ODkwIE5vcnRoYnJpZGdlIG9ubHkgc2luZ2xlIHNsb3QgUENJLWUgR0ZYIEh5ZHJhIHBhcnQg
WzEwMDI6NWExMV0NCglDb250cm9sOiBJL08tIE1lbSsgQnVzTWFzdGVyLSBTcGVjQ3ljbGUt
IE1lbVdJTlYtIFZHQVNub29wLSBQYXJFcnItIFN0ZXBwaW5nLSBTRVJSLSBGYXN0QjJCLSBE
aXNJTlR4LQ0KCVN0YXR1czogQ2FwKyA2Nk1Iei0gVURGLSBGYXN0QjJCLSBQYXJFcnItIERF
VlNFTD1mYXN0ID5UQWJvcnQtIDxUQWJvcnQtIDxNQWJvcnQrID5TRVJSLSA8UEVSUi0gSU5U
eC0NCglDYXBhYmlsaXRpZXM6IFtmMF0gSHlwZXJUcmFuc3BvcnQ6IE1TSSBNYXBwaW5nIEVu
YWJsZSsgRml4ZWQrDQoJQ2FwYWJpbGl0aWVzOiBbYzRdIEh5cGVyVHJhbnNwb3J0OiBTbGF2
ZSBvciBQcmltYXJ5IEludGVyZmFjZQ0KCQlDb21tYW5kOiBCYXNlVW5pdElEPTAgVW5pdENu
dD0yMCBNYXN0SG9zdC0gRGVmRGlyLSBEVUwtDQoJCUxpbmsgQ29udHJvbCAwOiBDRmxFLSBD
U1QtIENGRS0gPExrRmFpbC0gSW5pdCsgRU9DLSBUWE8tIDxDUkNFcnI9MCBJc29jRW4tIExT
RW4tIEV4dENUTC0gNjRiLQ0KCQlMaW5rIENvbmZpZyAwOiBNTFdJPTE2Yml0IER3RmNJbi0g
TUxXTz0xNmJpdCBEd0ZjT3V0LSBMV0k9MTZiaXQgRHdGY0luRW4tIExXTz0xNmJpdCBEd0Zj
T3V0RW4tDQoJCUxpbmsgQ29udHJvbCAxOiBDRmxFLSBDU1QtIENGRS0gPExrRmFpbCsgSW5p
dC0gRU9DKyBUWE8rIDxDUkNFcnI9MCBJc29jRW4tIExTRW4tIEV4dENUTC0gNjRiLQ0KCQlM
aW5rIENvbmZpZyAxOiBNTFdJPThiaXQgRHdGY0luLSBNTFdPPThiaXQgRHdGY091dC0gTFdJ
PThiaXQgRHdGY0luRW4tIExXTz04Yml0IER3RmNPdXRFbi0NCgkJUmV2aXNpb24gSUQ6IDMu
MDANCgkJTGluayBGcmVxdWVuY3kgMDogW2JdDQoJCUxpbmsgRXJyb3IgMDogPFByb3QtIDxP
dmZsLSA8RU9DLSBDVExUbS0NCgkJTGluayBGcmVxdWVuY3kgQ2FwYWJpbGl0eSAwOiAyMDBN
SHorIDMwME1Iei0gNDAwTUh6KyA1MDBNSHotIDYwME1IeisgODAwTUh6KyAxLjBHSHorIDEu
MkdIeisgMS40R0h6LSAxLjZHSHotIFZlbmQtDQoJCUZlYXR1cmUgQ2FwYWJpbGl0eTogSXNv
Y0ZDKyBMRFRTVE9QKyBDUkNUTS0gRUNUTFQtIDY0YkErIFVJRFJELQ0KCQlMaW5rIEZyZXF1
ZW5jeSAxOiAyMDBNSHoNCgkJTGluayBFcnJvciAxOiA8UHJvdC0gPE92ZmwtIDxFT0MtIENU
TFRtLQ0KCQlMaW5rIEZyZXF1ZW5jeSBDYXBhYmlsaXR5IDE6IDIwME1Iei0gMzAwTUh6LSA0
MDBNSHotIDUwME1Iei0gNjAwTUh6LSA4MDBNSHotIDEuMEdIei0gMS4yR0h6LSAxLjRHSHot
IDEuNkdIei0gVmVuZC0NCgkJRXJyb3IgSGFuZGxpbmc6IFBGbEUtIE9GbEUtIFBGRS0gT0ZF
LSBFT0NGRS0gUkZFLSBDUkNGRS0gU0VSUkZFLSBDRi0gUkUtIFBORkUtIE9ORkUtIEVPQ05G
RS0gUk5GRS0gQ1JDTkZFLSBTRVJSTkZFLQ0KCQlQcmVmZXRjaGFibGUgbWVtb3J5IGJlaGlu
ZCBicmlkZ2UgVXBwZXI6IDAwLTAwDQoJCUJ1cyBOdW1iZXI6IDAwDQoJQ2FwYWJpbGl0aWVz
OiBbNDBdIEh5cGVyVHJhbnNwb3J0OiBSZXRyeSBNb2RlDQoJQ2FwYWJpbGl0aWVzOiBbNTRd
IEh5cGVyVHJhbnNwb3J0OiBVbml0SUQgQ2x1bXBpbmcNCglDYXBhYmlsaXRpZXM6IFs5Y10g
SHlwZXJUcmFuc3BvcnQ6ICMxYQ0KCUNhcGFiaWxpdGllczogWzcwXSBNU0k6IEVuYWJsZS0g
Q291bnQ9MS80IE1hc2thYmxlLSA2NGJpdC0NCgkJQWRkcmVzczogMDAwMDAwMDAgIERhdGE6
IDAwMDANCg0KMDA6MDAuMiBHZW5lcmljIHN5c3RlbSBwZXJpcGhlcmFsIFswODA2XTogQVRJ
IFRlY2hub2xvZ2llcyBJbmMgUkQ5OTAgSS9PIE1lbW9yeSBNYW5hZ2VtZW50IFVuaXQgKElP
TU1VKSBbMTAwMjo1YTIzXQ0KCVN1YnN5c3RlbTogQVRJIFRlY2hub2xvZ2llcyBJbmMgUkQ5
OTAgSS9PIE1lbW9yeSBNYW5hZ2VtZW50IFVuaXQgKElPTU1VKSBbMTAwMjo1YTIzXQ0KCUNv
bnRyb2w6IEkvTy0gTWVtLSBCdXNNYXN0ZXIrIFNwZWNDeWNsZS0gTWVtV0lOVi0gVkdBU25v
b3AtIFBhckVyci0gU3RlcHBpbmctIFNFUlItIEZhc3RCMkItIERpc0lOVHgtDQoJU3RhdHVz
OiBDYXArIDY2TUh6LSBVREYtIEZhc3RCMkItIFBhckVyci0gREVWU0VMPWZhc3QgPlRBYm9y
dC0gPFRBYm9ydC0gPE1BYm9ydC0gPlNFUlItIDxQRVJSLSBJTlR4LQ0KCUxhdGVuY3k6IDAN
CglJbnRlcnJ1cHQ6IHBpbiBBIHJvdXRlZCB0byBJUlEgMTANCglDYXBhYmlsaXRpZXM6IFs0
MF0gU2VjdXJlIGRldmljZSA8Pz4NCglDYXBhYmlsaXRpZXM6IFs1NF0gTVNJOiBFbmFibGUr
IENvdW50PTEvMSBNYXNrYWJsZS0gNjRiaXQrDQoJCUFkZHJlc3M6IDAwMDAwMDAwZmVlMDEw
MGMgIERhdGE6IDQxMjgNCglDYXBhYmlsaXRpZXM6IFs2NF0gSHlwZXJUcmFuc3BvcnQ6IE1T
SSBNYXBwaW5nIEVuYWJsZSsgRml4ZWQrDQoNCjAwOjAyLjAgUENJIGJyaWRnZSBbMDYwNF06
IEFUSSBUZWNobm9sb2dpZXMgSW5jIFJEODkwIFBDSSB0byBQQ0kgYnJpZGdlIChQQ0kgZXhw
cmVzcyBncHAgcG9ydCBCKSBbMTAwMjo1YTE2XSAocHJvZy1pZiAwMCBbTm9ybWFsIGRlY29k
ZV0pDQoJQ29udHJvbDogSS9PKyBNZW0rIEJ1c01hc3RlcisgU3BlY0N5Y2xlLSBNZW1XSU5W
LSBWR0FTbm9vcC0gUGFyRXJyLSBTdGVwcGluZy0gU0VSUisgRmFzdEIyQi0gRGlzSU5UeCsN
CglTdGF0dXM6IENhcCsgNjZNSHotIFVERi0gRmFzdEIyQi0gUGFyRXJyLSBERVZTRUw9ZmFz
dCA+VEFib3J0LSA8VEFib3J0LSA8TUFib3J0LSA+U0VSUi0gPFBFUlItIElOVHgtDQoJTGF0
ZW5jeTogMCwgQ2FjaGUgTGluZSBTaXplOiA2NCBieXRlcw0KCUJ1czogcHJpbWFyeT0wMCwg
c2Vjb25kYXJ5PTBiLCBzdWJvcmRpbmF0ZT0wYiwgc2VjLWxhdGVuY3k9MA0KCUkvTyBiZWhp
bmQgYnJpZGdlOiAwMDAwZTAwMC0wMDAwZWZmZg0KCU1lbW9yeSBiZWhpbmQgYnJpZGdlOiBm
YTAwMDAwMC1mZTlmZmZmZg0KCVByZWZldGNoYWJsZSBtZW1vcnkgYmVoaW5kIGJyaWRnZTog
MDAwMDAwMDBkMDAwMDAwMC0wMDAwMDAwMGRmZmZmZmZmDQoJU2Vjb25kYXJ5IHN0YXR1czog
NjZNSHotIEZhc3RCMkItIFBhckVyci0gREVWU0VMPWZhc3QgPlRBYm9ydC0gPFRBYm9ydC0g
PE1BYm9ydC0gPFNFUlItIDxQRVJSLQ0KCUJyaWRnZUN0bDogUGFyaXR5KyBTRVJSKyBOb0lT
QS0gVkdBKyBNQWJvcnQtID5SZXNldC0gRmFzdEIyQi0NCgkJUHJpRGlzY1Rtci0gU2VjRGlz
Y1Rtci0gRGlzY1RtclN0YXQtIERpc2NUbXJTRVJSRW4tDQoJQ2FwYWJpbGl0aWVzOiBbNTBd
IFBvd2VyIE1hbmFnZW1lbnQgdmVyc2lvbiAzDQoJCUZsYWdzOiBQTUVDbGstIERTSS0gRDEt
IEQyLSBBdXhDdXJyZW50PTBtQSBQTUUoRDArLEQxLSxEMi0sRDNob3QrLEQzY29sZCspDQoJ
CVN0YXR1czogRDAgTm9Tb2Z0UnN0LSBQTUUtRW5hYmxlLSBEU2VsPTAgRFNjYWxlPTAgUE1F
LQ0KCUNhcGFiaWxpdGllczogWzU4XSBFeHByZXNzICh2MikgUm9vdCBQb3J0IChTbG90Kyks
IE1TSSAwMA0KCQlEZXZDYXA6CU1heFBheWxvYWQgMTI4IGJ5dGVzLCBQaGFudEZ1bmMgMCwg
TGF0ZW5jeSBMMHMgPDY0bnMsIEwxIDwxdXMNCgkJCUV4dFRhZysgUkJFKyBGTFJlc2V0LQ0K
CQlEZXZDdGw6CVJlcG9ydCBlcnJvcnM6IENvcnJlY3RhYmxlLSBOb24tRmF0YWwtIEZhdGFs
LSBVbnN1cHBvcnRlZC0NCgkJCVJseGRPcmQrIEV4dFRhZy0gUGhhbnRGdW5jLSBBdXhQd3It
IE5vU25vb3ArDQoJCQlNYXhQYXlsb2FkIDEyOCBieXRlcywgTWF4UmVhZFJlcSAxMjggYnl0
ZXMNCgkJRGV2U3RhOglDb3JyRXJyLSBVbmNvcnJFcnItIEZhdGFsRXJyLSBVbnN1cHBSZXEt
IEF1eFB3ci0gVHJhbnNQZW5kLQ0KCQlMbmtDYXA6CVBvcnQgIzAsIFNwZWVkIDVHVC9zLCBX
aWR0aCB4OCwgQVNQTSBMMHMgTDEsIExhdGVuY3kgTDAgPDF1cywgTDEgPDh1cw0KCQkJQ2xv
Y2tQTS0gU3VycHJpc2UtIExMQWN0UmVwKyBCd05vdCsNCgkJTG5rQ3RsOglBU1BNIERpc2Fi
bGVkOyBSQ0IgNjQgYnl0ZXMgRGlzYWJsZWQtIFJldHJhaW4tIENvbW1DbGsrDQoJCQlFeHRT
eW5jaC0gQ2xvY2tQTS0gQXV0V2lkRGlzLSBCV0ludC0gQXV0QldJbnQtDQoJCUxua1N0YToJ
U3BlZWQgMi41R1QvcywgV2lkdGggeDgsIFRyRXJyLSBUcmFpbi0gU2xvdENsaysgRExBY3Rp
dmUrIEJXTWdtdCsgQUJXTWdtdC0NCgkJU2x0Q2FwOglBdHRuQnRuLSBQd3JDdHJsLSBNUkwt
IEF0dG5JbmQtIFB3ckluZC0gSG90UGx1Zy0gU3VycHJpc2UtDQoJCQlTbG90ICMxLCBQb3dl
ckxpbWl0IDI1LjAwMFc7IEludGVybG9jay0gTm9Db21wbCsNCgkJU2x0Q3RsOglFbmFibGU6
IEF0dG5CdG4tIFB3ckZsdC0gTVJMLSBQcmVzRGV0LSBDbWRDcGx0LSBIUElycS0gTGlua0No
Zy0NCgkJCUNvbnRyb2w6IEF0dG5JbmQgVW5rbm93biwgUHdySW5kIFVua25vd24sIFBvd2Vy
LSBJbnRlcmxvY2stDQoJCVNsdFN0YToJU3RhdHVzOiBBdHRuQnRuLSBQb3dlckZsdC0gTVJM
LSBDbWRDcGx0LSBQcmVzRGV0KyBJbnRlcmxvY2stDQoJCQlDaGFuZ2VkOiBNUkwtIFByZXNE
ZXQrIExpbmtTdGF0ZSsNCgkJUm9vdEN0bDogRXJyQ29ycmVjdGFibGUtIEVyck5vbi1GYXRh
bC0gRXJyRmF0YWwtIFBNRUludEVuYS0gQ1JTVmlzaWJsZS0NCgkJUm9vdENhcDogQ1JTVmlz
aWJsZS0NCgkJUm9vdFN0YTogUE1FIFJlcUlEIDAwMDAsIFBNRVN0YXR1cy0gUE1FUGVuZGlu
Zy0NCgkJRGV2Q2FwMjogQ29tcGxldGlvbiBUaW1lb3V0OiBSYW5nZSBBQkNELCBUaW1lb3V0
RGlzKyBBUklGd2QrDQoJCURldkN0bDI6IENvbXBsZXRpb24gVGltZW91dDogNjVtcyB0byAy
MTBtcywgVGltZW91dERpcy0gQVJJRndkLQ0KCQlMbmtDdGwyOiBUYXJnZXQgTGluayBTcGVl
ZDogNUdUL3MsIEVudGVyQ29tcGxpYW5jZS0gU3BlZWREaXMtLCBTZWxlY3RhYmxlIERlLWVt
cGhhc2lzOiAtMy41ZEINCgkJCSBUcmFuc21pdCBNYXJnaW46IE5vcm1hbCBPcGVyYXRpbmcg
UmFuZ2UsIEVudGVyTW9kaWZpZWRDb21wbGlhbmNlLSBDb21wbGlhbmNlU09TLQ0KCQkJIENv
bXBsaWFuY2UgRGUtZW1waGFzaXM6IC02ZEINCgkJTG5rU3RhMjogQ3VycmVudCBEZS1lbXBo
YXNpcyBMZXZlbDogLTMuNWRCDQoJQ2FwYWJpbGl0aWVzOiBbYTBdIE1TSTogRW5hYmxlKyBD
b3VudD0xLzEgTWFza2FibGUtIDY0Yml0LQ0KCQlBZGRyZXNzOiBmZWUzZjAwYyAgRGF0YTog
NDE1MQ0KCUNhcGFiaWxpdGllczogW2IwXSBTdWJzeXN0ZW06IEFUSSBUZWNobm9sb2dpZXMg
SW5jIERldmljZSBbMTAwMjo1YTExXQ0KCUNhcGFiaWxpdGllczogW2I4XSBIeXBlclRyYW5z
cG9ydDogTVNJIE1hcHBpbmcgRW5hYmxlKyBGaXhlZCsNCglDYXBhYmlsaXRpZXM6IFsxMDAg
djFdIFZlbmRvciBTcGVjaWZpYyBJbmZvcm1hdGlvbjogSUQ9MDAwMSBSZXY9MSBMZW49MDEw
IDw/Pg0KCUNhcGFiaWxpdGllczogWzE5MCB2MV0gQWNjZXNzIENvbnRyb2wgU2VydmljZXMN
CgkJQUNTQ2FwOglTcmNWYWxpZCsgVHJhbnNCbGsrIFJlcVJlZGlyKyBDbXBsdFJlZGlyKyBV
cHN0cmVhbUZ3ZCsgRWdyZXNzQ3RybC0gRGlyZWN0VHJhbnMrDQoJCUFDU0N0bDoJU3JjVmFs
aWQrIFRyYW5zQmxrLSBSZXFSZWRpcisgQ21wbHRSZWRpcisgVXBzdHJlYW1Gd2QrIEVncmVz
c0N0cmwtIERpcmVjdFRyYW5zLQ0KCUtlcm5lbCBkcml2ZXIgaW4gdXNlOiBwY2llcG9ydA0K
DQowMDowMy4wIFBDSSBicmlkZ2UgWzA2MDRdOiBBVEkgVGVjaG5vbG9naWVzIEluYyBSRDg5
MCBQQ0kgdG8gUENJIGJyaWRnZSAoUENJIGV4cHJlc3MgZ3BwIHBvcnQgQykgWzEwMDI6NWEx
N10gKHByb2ctaWYgMDAgW05vcm1hbCBkZWNvZGVdKQ0KCUNvbnRyb2w6IEkvTy0gTWVtKyBC
dXNNYXN0ZXIrIFNwZWNDeWNsZS0gTWVtV0lOVi0gVkdBU25vb3AtIFBhckVyci0gU3RlcHBp
bmctIFNFUlIrIEZhc3RCMkItIERpc0lOVHgrDQoJU3RhdHVzOiBDYXArIDY2TUh6LSBVREYt
IEZhc3RCMkItIFBhckVyci0gREVWU0VMPWZhc3QgPlRBYm9ydC0gPFRBYm9ydCsgPE1BYm9y
dC0gPlNFUlItIDxQRVJSLSBJTlR4LQ0KCUxhdGVuY3k6IDAsIENhY2hlIExpbmUgU2l6ZTog
NjQgYnl0ZXMNCglCdXM6IHByaW1hcnk9MDAsIHNlY29uZGFyeT0wYSwgc3Vib3JkaW5hdGU9
MGEsIHNlYy1sYXRlbmN5PTANCglJL08gYmVoaW5kIGJyaWRnZTogMDAwMGYwMDAtMDAwMDBm
ZmYNCglNZW1vcnkgYmVoaW5kIGJyaWRnZTogZjlmMDAwMDAtZjlmZmZmZmYNCglQcmVmZXRj
aGFibGUgbWVtb3J5IGJlaGluZCBicmlkZ2U6IDAwMDAwMDAwZmZmMDAwMDAtMDAwMDAwMDAw
MDBmZmZmZg0KCVNlY29uZGFyeSBzdGF0dXM6IDY2TUh6LSBGYXN0QjJCLSBQYXJFcnItIERF
VlNFTD1mYXN0ID5UQWJvcnQrIDxUQWJvcnQtIDxNQWJvcnQtIDxTRVJSLSA8UEVSUi0NCglC
cmlkZ2VDdGw6IFBhcml0eSsgU0VSUisgTm9JU0ErIFZHQS0gTUFib3J0LSA+UmVzZXQtIEZh
c3RCMkItDQoJCVByaURpc2NUbXItIFNlY0Rpc2NUbXItIERpc2NUbXJTdGF0LSBEaXNjVG1y
U0VSUkVuLQ0KCUNhcGFiaWxpdGllczogWzUwXSBQb3dlciBNYW5hZ2VtZW50IHZlcnNpb24g
Mw0KCQlGbGFnczogUE1FQ2xrLSBEU0ktIEQxLSBEMi0gQXV4Q3VycmVudD0wbUEgUE1FKEQw
KyxEMS0sRDItLEQzaG90KyxEM2NvbGQrKQ0KCQlTdGF0dXM6IEQwIE5vU29mdFJzdC0gUE1F
LUVuYWJsZS0gRFNlbD0wIERTY2FsZT0wIFBNRS0NCglDYXBhYmlsaXRpZXM6IFs1OF0gRXhw
cmVzcyAodjIpIFJvb3QgUG9ydCAoU2xvdCspLCBNU0kgMDANCgkJRGV2Q2FwOglNYXhQYXls
b2FkIDEyOCBieXRlcywgUGhhbnRGdW5jIDAsIExhdGVuY3kgTDBzIDw2NG5zLCBMMSA8MXVz
DQoJCQlFeHRUYWcrIFJCRSsgRkxSZXNldC0NCgkJRGV2Q3RsOglSZXBvcnQgZXJyb3JzOiBD
b3JyZWN0YWJsZS0gTm9uLUZhdGFsLSBGYXRhbC0gVW5zdXBwb3J0ZWQtDQoJCQlSbHhkT3Jk
KyBFeHRUYWctIFBoYW50RnVuYy0gQXV4UHdyLSBOb1Nub29wKw0KCQkJTWF4UGF5bG9hZCAx
MjggYnl0ZXMsIE1heFJlYWRSZXEgMTI4IGJ5dGVzDQoJCURldlN0YToJQ29yckVyci0gVW5j
b3JyRXJyLSBGYXRhbEVyci0gVW5zdXBwUmVxLSBBdXhQd3ItIFRyYW5zUGVuZC0NCgkJTG5r
Q2FwOglQb3J0ICMxLCBTcGVlZCA1R1QvcywgV2lkdGggeDgsIEFTUE0gTDBzIEwxLCBMYXRl
bmN5IEwwIDwxdXMsIEwxIDw4dXMNCgkJCUNsb2NrUE0tIFN1cnByaXNlLSBMTEFjdFJlcCsg
QndOb3QrDQoJCUxua0N0bDoJQVNQTSBEaXNhYmxlZDsgUkNCIDY0IGJ5dGVzIERpc2FibGVk
LSBSZXRyYWluLSBDb21tQ2xrLQ0KCQkJRXh0U3luY2gtIENsb2NrUE0tIEF1dFdpZERpcy0g
QldJbnQtIEF1dEJXSW50LQ0KCQlMbmtTdGE6CVNwZWVkIDIuNUdUL3MsIFdpZHRoIHgxLCBU
ckVyci0gVHJhaW4tIFNsb3RDbGsrIERMQWN0aXZlKyBCV01nbXQrIEFCV01nbXQtDQoJCVNs
dENhcDoJQXR0bkJ0bi0gUHdyQ3RybC0gTVJMLSBBdHRuSW5kLSBQd3JJbmQtIEhvdFBsdWct
IFN1cnByaXNlLQ0KCQkJU2xvdCAjMywgUG93ZXJMaW1pdCAxMC4wMDBXOyBJbnRlcmxvY2st
IE5vQ29tcGwrDQoJCVNsdEN0bDoJRW5hYmxlOiBBdHRuQnRuLSBQd3JGbHQtIE1STC0gUHJl
c0RldC0gQ21kQ3BsdC0gSFBJcnEtIExpbmtDaGctDQoJCQlDb250cm9sOiBBdHRuSW5kIFVu
a25vd24sIFB3ckluZCBVbmtub3duLCBQb3dlci0gSW50ZXJsb2NrLQ0KCQlTbHRTdGE6CVN0
YXR1czogQXR0bkJ0bi0gUG93ZXJGbHQtIE1STC0gQ21kQ3BsdC0gUHJlc0RldCsgSW50ZXJs
b2NrLQ0KCQkJQ2hhbmdlZDogTVJMLSBQcmVzRGV0KyBMaW5rU3RhdGUrDQoJCVJvb3RDdGw6
IEVyckNvcnJlY3RhYmxlLSBFcnJOb24tRmF0YWwtIEVyckZhdGFsLSBQTUVJbnRFbmEtIENS
U1Zpc2libGUtDQoJCVJvb3RDYXA6IENSU1Zpc2libGUtDQoJCVJvb3RTdGE6IFBNRSBSZXFJ
RCAwMDAwLCBQTUVTdGF0dXMtIFBNRVBlbmRpbmctDQoJCURldkNhcDI6IENvbXBsZXRpb24g
VGltZW91dDogUmFuZ2UgQUJDRCwgVGltZW91dERpcysgQVJJRndkKw0KCQlEZXZDdGwyOiBD
b21wbGV0aW9uIFRpbWVvdXQ6IDY1bXMgdG8gMjEwbXMsIFRpbWVvdXREaXMtIEFSSUZ3ZC0N
CgkJTG5rQ3RsMjogVGFyZ2V0IExpbmsgU3BlZWQ6IDVHVC9zLCBFbnRlckNvbXBsaWFuY2Ut
IFNwZWVkRGlzLSwgU2VsZWN0YWJsZSBEZS1lbXBoYXNpczogLTMuNWRCDQoJCQkgVHJhbnNt
aXQgTWFyZ2luOiBOb3JtYWwgT3BlcmF0aW5nIFJhbmdlLCBFbnRlck1vZGlmaWVkQ29tcGxp
YW5jZS0gQ29tcGxpYW5jZVNPUy0NCgkJCSBDb21wbGlhbmNlIERlLWVtcGhhc2lzOiAtNmRC
DQoJCUxua1N0YTI6IEN1cnJlbnQgRGUtZW1waGFzaXMgTGV2ZWw6IC0zLjVkQg0KCUNhcGFi
aWxpdGllczogW2EwXSBNU0k6IEVuYWJsZSsgQ291bnQ9MS8xIE1hc2thYmxlLSA2NGJpdC0N
CgkJQWRkcmVzczogZmVlM2YwMGMgIERhdGE6IDQxNTkNCglDYXBhYmlsaXRpZXM6IFtiMF0g
U3Vic3lzdGVtOiBBVEkgVGVjaG5vbG9naWVzIEluYyBEZXZpY2UgWzEwMDI6NWExMV0NCglD
YXBhYmlsaXRpZXM6IFtiOF0gSHlwZXJUcmFuc3BvcnQ6IE1TSSBNYXBwaW5nIEVuYWJsZSsg
Rml4ZWQrDQoJQ2FwYWJpbGl0aWVzOiBbMTAwIHYxXSBWZW5kb3IgU3BlY2lmaWMgSW5mb3Jt
YXRpb246IElEPTAwMDEgUmV2PTEgTGVuPTAxMCA8Pz4NCglDYXBhYmlsaXRpZXM6IFsxOTAg
djFdIEFjY2VzcyBDb250cm9sIFNlcnZpY2VzDQoJCUFDU0NhcDoJU3JjVmFsaWQrIFRyYW5z
QmxrKyBSZXFSZWRpcisgQ21wbHRSZWRpcisgVXBzdHJlYW1Gd2QrIEVncmVzc0N0cmwtIERp
cmVjdFRyYW5zKw0KCQlBQ1NDdGw6CVNyY1ZhbGlkKyBUcmFuc0Jsay0gUmVxUmVkaXIrIENt
cGx0UmVkaXIrIFVwc3RyZWFtRndkKyBFZ3Jlc3NDdHJsLSBEaXJlY3RUcmFucy0NCglLZXJu
ZWwgZHJpdmVyIGluIHVzZTogcGNpZXBvcnQNCg0KMDA6MDUuMCBQQ0kgYnJpZGdlIFswNjA0
XTogQVRJIFRlY2hub2xvZ2llcyBJbmMgUkQ4OTAgUENJIHRvIFBDSSBicmlkZ2UgKFBDSSBl
eHByZXNzIGdwcCBwb3J0IEUpIFsxMDAyOjVhMTldIChwcm9nLWlmIDAwIFtOb3JtYWwgZGVj
b2RlXSkNCglDb250cm9sOiBJL08rIE1lbSsgQnVzTWFzdGVyKyBTcGVjQ3ljbGUtIE1lbVdJ
TlYtIFZHQVNub29wLSBQYXJFcnItIFN0ZXBwaW5nLSBTRVJSKyBGYXN0QjJCLSBEaXNJTlR4
Kw0KCVN0YXR1czogQ2FwKyA2Nk1Iei0gVURGLSBGYXN0QjJCLSBQYXJFcnItIERFVlNFTD1m
YXN0ID5UQWJvcnQtIDxUQWJvcnQtIDxNQWJvcnQtID5TRVJSLSA8UEVSUi0gSU5UeC0NCglM
YXRlbmN5OiAwLCBDYWNoZSBMaW5lIFNpemU6IDY0IGJ5dGVzDQoJQnVzOiBwcmltYXJ5PTAw
LCBzZWNvbmRhcnk9MDksIHN1Ym9yZGluYXRlPTA5LCBzZWMtbGF0ZW5jeT0wDQoJSS9PIGJl
aGluZCBicmlkZ2U6IDAwMDBkMDAwLTAwMDBkZmZmDQoJTWVtb3J5IGJlaGluZCBicmlkZ2U6
IGY5ZTAwMDAwLWY5ZWZmZmZmDQoJUHJlZmV0Y2hhYmxlIG1lbW9yeSBiZWhpbmQgYnJpZGdl
OiAwMDAwMDAwMGNmZjAwMDAwLTAwMDAwMDAwY2ZmZmZmZmYNCglTZWNvbmRhcnkgc3RhdHVz
OiA2Nk1Iei0gRmFzdEIyQi0gUGFyRXJyLSBERVZTRUw9ZmFzdCA+VEFib3J0LSA8VEFib3J0
LSA8TUFib3J0LSA8U0VSUi0gPFBFUlItDQoJQnJpZGdlQ3RsOiBQYXJpdHkrIFNFUlIrIE5v
SVNBKyBWR0EtIE1BYm9ydC0gPlJlc2V0LSBGYXN0QjJCLQ0KCQlQcmlEaXNjVG1yLSBTZWNE
aXNjVG1yLSBEaXNjVG1yU3RhdC0gRGlzY1RtclNFUlJFbi0NCglDYXBhYmlsaXRpZXM6IFs1
MF0gUG93ZXIgTWFuYWdlbWVudCB2ZXJzaW9uIDMNCgkJRmxhZ3M6IFBNRUNsay0gRFNJLSBE
MS0gRDItIEF1eEN1cnJlbnQ9MG1BIFBNRShEMCssRDEtLEQyLSxEM2hvdCssRDNjb2xkKykN
CgkJU3RhdHVzOiBEMCBOb1NvZnRSc3QtIFBNRS1FbmFibGUtIERTZWw9MCBEU2NhbGU9MCBQ
TUUtDQoJQ2FwYWJpbGl0aWVzOiBbNThdIEV4cHJlc3MgKHYyKSBSb290IFBvcnQgKFNsb3Qr
KSwgTVNJIDAwDQoJCURldkNhcDoJTWF4UGF5bG9hZCAxMjggYnl0ZXMsIFBoYW50RnVuYyAw
LCBMYXRlbmN5IEwwcyA8NjRucywgTDEgPDF1cw0KCQkJRXh0VGFnKyBSQkUrIEZMUmVzZXQt
DQoJCURldkN0bDoJUmVwb3J0IGVycm9yczogQ29ycmVjdGFibGUtIE5vbi1GYXRhbC0gRmF0
YWwtIFVuc3VwcG9ydGVkLQ0KCQkJUmx4ZE9yZCsgRXh0VGFnLSBQaGFudEZ1bmMtIEF1eFB3
ci0gTm9Tbm9vcCsNCgkJCU1heFBheWxvYWQgMTI4IGJ5dGVzLCBNYXhSZWFkUmVxIDEyOCBi
eXRlcw0KCQlEZXZTdGE6CUNvcnJFcnItIFVuY29yckVyci0gRmF0YWxFcnItIFVuc3VwcFJl
cS0gQXV4UHdyLSBUcmFuc1BlbmQtDQoJCUxua0NhcDoJUG9ydCAjMSwgU3BlZWQgNUdUL3Ms
IFdpZHRoIHgxLCBBU1BNIEwwcyBMMSwgTGF0ZW5jeSBMMCA8MXVzLCBMMSA8OHVzDQoJCQlD
bG9ja1BNLSBTdXJwcmlzZS0gTExBY3RSZXArIEJ3Tm90Kw0KCQlMbmtDdGw6CUFTUE0gRGlz
YWJsZWQ7IFJDQiA2NCBieXRlcyBEaXNhYmxlZC0gUmV0cmFpbi0gQ29tbUNsaysNCgkJCUV4
dFN5bmNoLSBDbG9ja1BNLSBBdXRXaWREaXMtIEJXSW50LSBBdXRCV0ludC0NCgkJTG5rU3Rh
OglTcGVlZCAyLjVHVC9zLCBXaWR0aCB4MSwgVHJFcnItIFRyYWluLSBTbG90Q2xrKyBETEFj
dGl2ZSsgQldNZ210KyBBQldNZ210LQ0KCQlTbHRDYXA6CUF0dG5CdG4tIFB3ckN0cmwtIE1S
TC0gQXR0bkluZC0gUHdySW5kLSBIb3RQbHVnLSBTdXJwcmlzZS0NCgkJCVNsb3QgIzUsIFBv
d2VyTGltaXQgNzUuMDAwVzsgSW50ZXJsb2NrLSBOb0NvbXBsKw0KCQlTbHRDdGw6CUVuYWJs
ZTogQXR0bkJ0bi0gUHdyRmx0LSBNUkwtIFByZXNEZXQtIENtZENwbHQtIEhQSXJxLSBMaW5r
Q2hnLQ0KCQkJQ29udHJvbDogQXR0bkluZCBVbmtub3duLCBQd3JJbmQgVW5rbm93biwgUG93
ZXItIEludGVybG9jay0NCgkJU2x0U3RhOglTdGF0dXM6IEF0dG5CdG4tIFBvd2VyRmx0LSBN
UkwtIENtZENwbHQtIFByZXNEZXQrIEludGVybG9jay0NCgkJCUNoYW5nZWQ6IE1STC0gUHJl
c0RldCsgTGlua1N0YXRlKw0KCQlSb290Q3RsOiBFcnJDb3JyZWN0YWJsZS0gRXJyTm9uLUZh
dGFsLSBFcnJGYXRhbC0gUE1FSW50RW5hLSBDUlNWaXNpYmxlLQ0KCQlSb290Q2FwOiBDUlNW
aXNpYmxlLQ0KCQlSb290U3RhOiBQTUUgUmVxSUQgMDAwMCwgUE1FU3RhdHVzLSBQTUVQZW5k
aW5nLQ0KCQlEZXZDYXAyOiBDb21wbGV0aW9uIFRpbWVvdXQ6IFJhbmdlIEFCQ0QsIFRpbWVv
dXREaXMrIEFSSUZ3ZCsNCgkJRGV2Q3RsMjogQ29tcGxldGlvbiBUaW1lb3V0OiA2NW1zIHRv
IDIxMG1zLCBUaW1lb3V0RGlzLSBBUklGd2QtDQoJCUxua0N0bDI6IFRhcmdldCBMaW5rIFNw
ZWVkOiA1R1QvcywgRW50ZXJDb21wbGlhbmNlLSBTcGVlZERpcy0sIFNlbGVjdGFibGUgRGUt
ZW1waGFzaXM6IC0zLjVkQg0KCQkJIFRyYW5zbWl0IE1hcmdpbjogTm9ybWFsIE9wZXJhdGlu
ZyBSYW5nZSwgRW50ZXJNb2RpZmllZENvbXBsaWFuY2UtIENvbXBsaWFuY2VTT1MtDQoJCQkg
Q29tcGxpYW5jZSBEZS1lbXBoYXNpczogLTZkQg0KCQlMbmtTdGEyOiBDdXJyZW50IERlLWVt
cGhhc2lzIExldmVsOiAtMy41ZEINCglDYXBhYmlsaXRpZXM6IFthMF0gTVNJOiBFbmFibGUr
IENvdW50PTEvMSBNYXNrYWJsZS0gNjRiaXQtDQoJCUFkZHJlc3M6IGZlZTNmMDBjICBEYXRh
OiA0MTYxDQoJQ2FwYWJpbGl0aWVzOiBbYjBdIFN1YnN5c3RlbTogQVRJIFRlY2hub2xvZ2ll
cyBJbmMgRGV2aWNlIFsxMDAyOjVhMTFdDQoJQ2FwYWJpbGl0aWVzOiBbYjhdIEh5cGVyVHJh
bnNwb3J0OiBNU0kgTWFwcGluZyBFbmFibGUrIEZpeGVkKw0KCUNhcGFiaWxpdGllczogWzEw
MCB2MV0gVmVuZG9yIFNwZWNpZmljIEluZm9ybWF0aW9uOiBJRD0wMDAxIFJldj0xIExlbj0w
MTAgPD8+DQoJQ2FwYWJpbGl0aWVzOiBbMTkwIHYxXSBBY2Nlc3MgQ29udHJvbCBTZXJ2aWNl
cw0KCQlBQ1NDYXA6CVNyY1ZhbGlkKyBUcmFuc0JsaysgUmVxUmVkaXIrIENtcGx0UmVkaXIr
IFVwc3RyZWFtRndkKyBFZ3Jlc3NDdHJsLSBEaXJlY3RUcmFucysNCgkJQUNTQ3RsOglTcmNW
YWxpZCsgVHJhbnNCbGstIFJlcVJlZGlyKyBDbXBsdFJlZGlyKyBVcHN0cmVhbUZ3ZCsgRWdy
ZXNzQ3RybC0gRGlyZWN0VHJhbnMtDQoJS2VybmVsIGRyaXZlciBpbiB1c2U6IHBjaWVwb3J0
DQoNCjAwOjA2LjAgUENJIGJyaWRnZSBbMDYwNF06IEFUSSBUZWNobm9sb2dpZXMgSW5jIFJE
ODkwIFBDSSB0byBQQ0kgYnJpZGdlIChQQ0kgZXhwcmVzcyBncHAgcG9ydCBGKSBbMTAwMjo1
YTFhXSAocHJvZy1pZiAwMCBbTm9ybWFsIGRlY29kZV0pDQoJQ29udHJvbDogSS9PKyBNZW0r
IEJ1c01hc3RlcisgU3BlY0N5Y2xlLSBNZW1XSU5WLSBWR0FTbm9vcC0gUGFyRXJyLSBTdGVw
cGluZy0gU0VSUisgRmFzdEIyQi0gRGlzSU5UeCsNCglTdGF0dXM6IENhcCsgNjZNSHotIFVE
Ri0gRmFzdEIyQi0gUGFyRXJyLSBERVZTRUw9ZmFzdCA+VEFib3J0LSA8VEFib3J0LSA8TUFi
b3J0LSA+U0VSUi0gPFBFUlItIElOVHgtDQoJTGF0ZW5jeTogMCwgQ2FjaGUgTGluZSBTaXpl
OiA2NCBieXRlcw0KCUJ1czogcHJpbWFyeT0wMCwgc2Vjb25kYXJ5PTA4LCBzdWJvcmRpbmF0
ZT0wOCwgc2VjLWxhdGVuY3k9MA0KCUkvTyBiZWhpbmQgYnJpZGdlOiAwMDAwYzAwMC0wMDAw
Y2ZmZg0KCU1lbW9yeSBiZWhpbmQgYnJpZGdlOiBmOWQwMDAwMC1mOWRmZmZmZg0KCVByZWZl
dGNoYWJsZSBtZW1vcnkgYmVoaW5kIGJyaWRnZTogMDAwMDAwMDBjZmUwMDAwMC0wMDAwMDAw
MGNmZWZmZmZmDQoJU2Vjb25kYXJ5IHN0YXR1czogNjZNSHotIEZhc3RCMkItIFBhckVyci0g
REVWU0VMPWZhc3QgPlRBYm9ydC0gPFRBYm9ydC0gPE1BYm9ydC0gPFNFUlItIDxQRVJSLQ0K
CUJyaWRnZUN0bDogUGFyaXR5KyBTRVJSKyBOb0lTQSsgVkdBLSBNQWJvcnQtID5SZXNldC0g
RmFzdEIyQi0NCgkJUHJpRGlzY1Rtci0gU2VjRGlzY1Rtci0gRGlzY1RtclN0YXQtIERpc2NU
bXJTRVJSRW4tDQoJQ2FwYWJpbGl0aWVzOiBbNTBdIFBvd2VyIE1hbmFnZW1lbnQgdmVyc2lv
biAzDQoJCUZsYWdzOiBQTUVDbGstIERTSS0gRDEtIEQyLSBBdXhDdXJyZW50PTBtQSBQTUUo
RDArLEQxLSxEMi0sRDNob3QrLEQzY29sZCspDQoJCVN0YXR1czogRDAgTm9Tb2Z0UnN0LSBQ
TUUtRW5hYmxlLSBEU2VsPTAgRFNjYWxlPTAgUE1FLQ0KCUNhcGFiaWxpdGllczogWzU4XSBF
eHByZXNzICh2MikgUm9vdCBQb3J0IChTbG90KyksIE1TSSAwMA0KCQlEZXZDYXA6CU1heFBh
eWxvYWQgMTI4IGJ5dGVzLCBQaGFudEZ1bmMgMCwgTGF0ZW5jeSBMMHMgPDY0bnMsIEwxIDwx
dXMNCgkJCUV4dFRhZysgUkJFKyBGTFJlc2V0LQ0KCQlEZXZDdGw6CVJlcG9ydCBlcnJvcnM6
IENvcnJlY3RhYmxlLSBOb24tRmF0YWwtIEZhdGFsLSBVbnN1cHBvcnRlZC0NCgkJCVJseGRP
cmQrIEV4dFRhZy0gUGhhbnRGdW5jLSBBdXhQd3ItIE5vU25vb3ArDQoJCQlNYXhQYXlsb2Fk
IDEyOCBieXRlcywgTWF4UmVhZFJlcSAxMjggYnl0ZXMNCgkJRGV2U3RhOglDb3JyRXJyLSBV
bmNvcnJFcnItIEZhdGFsRXJyLSBVbnN1cHBSZXEtIEF1eFB3ci0gVHJhbnNQZW5kLQ0KCQlM
bmtDYXA6CVBvcnQgIzIsIFNwZWVkIDVHVC9zLCBXaWR0aCB4MSwgQVNQTSBMMHMgTDEsIExh
dGVuY3kgTDAgPDF1cywgTDEgPDh1cw0KCQkJQ2xvY2tQTS0gU3VycHJpc2UtIExMQWN0UmVw
KyBCd05vdCsNCgkJTG5rQ3RsOglBU1BNIERpc2FibGVkOyBSQ0IgNjQgYnl0ZXMgRGlzYWJs
ZWQtIFJldHJhaW4tIENvbW1DbGsrDQoJCQlFeHRTeW5jaC0gQ2xvY2tQTS0gQXV0V2lkRGlz
LSBCV0ludC0gQXV0QldJbnQtDQoJCUxua1N0YToJU3BlZWQgMi41R1QvcywgV2lkdGggeDEs
IFRyRXJyLSBUcmFpbi0gU2xvdENsaysgRExBY3RpdmUrIEJXTWdtdCsgQUJXTWdtdC0NCgkJ
U2x0Q2FwOglBdHRuQnRuLSBQd3JDdHJsLSBNUkwtIEF0dG5JbmQtIFB3ckluZC0gSG90UGx1
Zy0gU3VycHJpc2UtDQoJCQlTbG90ICM2LCBQb3dlckxpbWl0IDc1LjAwMFc7IEludGVybG9j
ay0gTm9Db21wbCsNCgkJU2x0Q3RsOglFbmFibGU6IEF0dG5CdG4tIFB3ckZsdC0gTVJMLSBQ
cmVzRGV0LSBDbWRDcGx0LSBIUElycS0gTGlua0NoZy0NCgkJCUNvbnRyb2w6IEF0dG5JbmQg
VW5rbm93biwgUHdySW5kIFVua25vd24sIFBvd2VyLSBJbnRlcmxvY2stDQoJCVNsdFN0YToJ
U3RhdHVzOiBBdHRuQnRuLSBQb3dlckZsdC0gTVJMLSBDbWRDcGx0LSBQcmVzRGV0KyBJbnRl
cmxvY2stDQoJCQlDaGFuZ2VkOiBNUkwtIFByZXNEZXQrIExpbmtTdGF0ZSsNCgkJUm9vdEN0
bDogRXJyQ29ycmVjdGFibGUtIEVyck5vbi1GYXRhbC0gRXJyRmF0YWwtIFBNRUludEVuYS0g
Q1JTVmlzaWJsZS0NCgkJUm9vdENhcDogQ1JTVmlzaWJsZS0NCgkJUm9vdFN0YTogUE1FIFJl
cUlEIDAwMDAsIFBNRVN0YXR1cy0gUE1FUGVuZGluZy0NCgkJRGV2Q2FwMjogQ29tcGxldGlv
biBUaW1lb3V0OiBSYW5nZSBBQkNELCBUaW1lb3V0RGlzKyBBUklGd2QrDQoJCURldkN0bDI6
IENvbXBsZXRpb24gVGltZW91dDogNjVtcyB0byAyMTBtcywgVGltZW91dERpcy0gQVJJRndk
LQ0KCQlMbmtDdGwyOiBUYXJnZXQgTGluayBTcGVlZDogNUdUL3MsIEVudGVyQ29tcGxpYW5j
ZS0gU3BlZWREaXMtLCBTZWxlY3RhYmxlIERlLWVtcGhhc2lzOiAtMy41ZEINCgkJCSBUcmFu
c21pdCBNYXJnaW46IE5vcm1hbCBPcGVyYXRpbmcgUmFuZ2UsIEVudGVyTW9kaWZpZWRDb21w
bGlhbmNlLSBDb21wbGlhbmNlU09TLQ0KCQkJIENvbXBsaWFuY2UgRGUtZW1waGFzaXM6IC02
ZEINCgkJTG5rU3RhMjogQ3VycmVudCBEZS1lbXBoYXNpcyBMZXZlbDogLTMuNWRCDQoJQ2Fw
YWJpbGl0aWVzOiBbYTBdIE1TSTogRW5hYmxlKyBDb3VudD0xLzEgTWFza2FibGUtIDY0Yml0
LQ0KCQlBZGRyZXNzOiBmZWUzZjAwYyAgRGF0YTogNDE2OQ0KCUNhcGFiaWxpdGllczogW2Iw
XSBTdWJzeXN0ZW06IEFUSSBUZWNobm9sb2dpZXMgSW5jIERldmljZSBbMTAwMjo1YTExXQ0K
CUNhcGFiaWxpdGllczogW2I4XSBIeXBlclRyYW5zcG9ydDogTVNJIE1hcHBpbmcgRW5hYmxl
KyBGaXhlZCsNCglDYXBhYmlsaXRpZXM6IFsxMDAgdjFdIFZlbmRvciBTcGVjaWZpYyBJbmZv
cm1hdGlvbjogSUQ9MDAwMSBSZXY9MSBMZW49MDEwIDw/Pg0KCUNhcGFiaWxpdGllczogWzE5
MCB2MV0gQWNjZXNzIENvbnRyb2wgU2VydmljZXMNCgkJQUNTQ2FwOglTcmNWYWxpZCsgVHJh
bnNCbGsrIFJlcVJlZGlyKyBDbXBsdFJlZGlyKyBVcHN0cmVhbUZ3ZCsgRWdyZXNzQ3RybC0g
RGlyZWN0VHJhbnMrDQoJCUFDU0N0bDoJU3JjVmFsaWQrIFRyYW5zQmxrLSBSZXFSZWRpcisg
Q21wbHRSZWRpcisgVXBzdHJlYW1Gd2QrIEVncmVzc0N0cmwtIERpcmVjdFRyYW5zLQ0KCUtl
cm5lbCBkcml2ZXIgaW4gdXNlOiBwY2llcG9ydA0KDQowMDowYS4wIFBDSSBicmlkZ2UgWzA2
MDRdOiBBVEkgVGVjaG5vbG9naWVzIEluYyBSRDg5MCBQQ0kgdG8gUENJIGJyaWRnZSAoZXh0
ZXJuYWwgZ2Z4MSBwb3J0IEEpIFsxMDAyOjVhMWRdIChwcm9nLWlmIDAwIFtOb3JtYWwgZGVj
b2RlXSkNCglDb250cm9sOiBJL08tIE1lbSsgQnVzTWFzdGVyKyBTcGVjQ3ljbGUtIE1lbVdJ
TlYtIFZHQVNub29wLSBQYXJFcnItIFN0ZXBwaW5nLSBTRVJSKyBGYXN0QjJCLSBEaXNJTlR4
Kw0KCVN0YXR1czogQ2FwKyA2Nk1Iei0gVURGLSBGYXN0QjJCLSBQYXJFcnItIERFVlNFTD1m
YXN0ID5UQWJvcnQtIDxUQWJvcnQtIDxNQWJvcnQtID5TRVJSLSA8UEVSUi0gSU5UeC0NCglM
YXRlbmN5OiAwLCBDYWNoZSBMaW5lIFNpemU6IDY0IGJ5dGVzDQoJQnVzOiBwcmltYXJ5PTAw
LCBzZWNvbmRhcnk9MDcsIHN1Ym9yZGluYXRlPTA3LCBzZWMtbGF0ZW5jeT0wDQoJSS9PIGJl
aGluZCBicmlkZ2U6IDAwMDBmMDAwLTAwMDAwZmZmDQoJTWVtb3J5IGJlaGluZCBicmlkZ2U6
IGY5YTAwMDAwLWY5YmZmZmZmDQoJUHJlZmV0Y2hhYmxlIG1lbW9yeSBiZWhpbmQgYnJpZGdl
OiAwMDAwMDAwMGZmZjAwMDAwLTAwMDAwMDAwMDAwZmZmZmYNCglTZWNvbmRhcnkgc3RhdHVz
OiA2Nk1Iei0gRmFzdEIyQi0gUGFyRXJyLSBERVZTRUw9ZmFzdCA+VEFib3J0LSA8VEFib3J0
LSA8TUFib3J0KyA8U0VSUi0gPFBFUlItDQoJQnJpZGdlQ3RsOiBQYXJpdHkrIFNFUlIrIE5v
SVNBKyBWR0EtIE1BYm9ydC0gPlJlc2V0LSBGYXN0QjJCLQ0KCQlQcmlEaXNjVG1yLSBTZWNE
aXNjVG1yLSBEaXNjVG1yU3RhdC0gRGlzY1RtclNFUlJFbi0NCglDYXBhYmlsaXRpZXM6IFs1
MF0gUG93ZXIgTWFuYWdlbWVudCB2ZXJzaW9uIDMNCgkJRmxhZ3M6IFBNRUNsay0gRFNJLSBE
MS0gRDItIEF1eEN1cnJlbnQ9MG1BIFBNRShEMCssRDEtLEQyLSxEM2hvdCssRDNjb2xkKykN
CgkJU3RhdHVzOiBEMCBOb1NvZnRSc3QtIFBNRS1FbmFibGUtIERTZWw9MCBEU2NhbGU9MCBQ
TUUtDQoJQ2FwYWJpbGl0aWVzOiBbNThdIEV4cHJlc3MgKHYyKSBSb290IFBvcnQgKFNsb3Qr
KSwgTVNJIDAwDQoJCURldkNhcDoJTWF4UGF5bG9hZCAxMjggYnl0ZXMsIFBoYW50RnVuYyAw
LCBMYXRlbmN5IEwwcyA8NjRucywgTDEgPDF1cw0KCQkJRXh0VGFnKyBSQkUrIEZMUmVzZXQt
DQoJCURldkN0bDoJUmVwb3J0IGVycm9yczogQ29ycmVjdGFibGUtIE5vbi1GYXRhbC0gRmF0
YWwtIFVuc3VwcG9ydGVkLQ0KCQkJUmx4ZE9yZCsgRXh0VGFnLSBQaGFudEZ1bmMtIEF1eFB3
ci0gTm9Tbm9vcCsNCgkJCU1heFBheWxvYWQgMTI4IGJ5dGVzLCBNYXhSZWFkUmVxIDEyOCBi
eXRlcw0KCQlEZXZTdGE6CUNvcnJFcnItIFVuY29yckVyci0gRmF0YWxFcnItIFVuc3VwcFJl
cS0gQXV4UHdyLSBUcmFuc1BlbmQtDQoJCUxua0NhcDoJUG9ydCAjNSwgU3BlZWQgMi41R1Qv
cywgV2lkdGggeDEsIEFTUE0gTDBzIEwxLCBMYXRlbmN5IEwwIDwxdXMsIEwxIDw4dXMNCgkJ
CUNsb2NrUE0tIFN1cnByaXNlLSBMTEFjdFJlcCsgQndOb3QrDQoJCUxua0N0bDoJQVNQTSBE
aXNhYmxlZDsgUkNCIDY0IGJ5dGVzIERpc2FibGVkLSBSZXRyYWluLSBDb21tQ2xrLQ0KCQkJ
RXh0U3luY2gtIENsb2NrUE0tIEF1dFdpZERpcy0gQldJbnQtIEF1dEJXSW50LQ0KCQlMbmtT
dGE6CVNwZWVkIDIuNUdUL3MsIFdpZHRoIHgxLCBUckVyci0gVHJhaW4tIFNsb3RDbGsrIERM
QWN0aXZlKyBCV01nbXQrIEFCV01nbXQtDQoJCVNsdENhcDoJQXR0bkJ0bi0gUHdyQ3RybC0g
TVJMLSBBdHRuSW5kLSBQd3JJbmQtIEhvdFBsdWctIFN1cnByaXNlLQ0KCQkJU2xvdCAjMiwg
UG93ZXJMaW1pdCA3NS4wMDBXOyBJbnRlcmxvY2stIE5vQ29tcGwrDQoJCVNsdEN0bDoJRW5h
YmxlOiBBdHRuQnRuLSBQd3JGbHQtIE1STC0gUHJlc0RldC0gQ21kQ3BsdC0gSFBJcnEtIExp
bmtDaGctDQoJCQlDb250cm9sOiBBdHRuSW5kIFVua25vd24sIFB3ckluZCBVbmtub3duLCBQ
b3dlci0gSW50ZXJsb2NrLQ0KCQlTbHRTdGE6CVN0YXR1czogQXR0bkJ0bi0gUG93ZXJGbHQt
IE1STC0gQ21kQ3BsdC0gUHJlc0RldCsgSW50ZXJsb2NrLQ0KCQkJQ2hhbmdlZDogTVJMLSBQ
cmVzRGV0KyBMaW5rU3RhdGUrDQoJCVJvb3RDdGw6IEVyckNvcnJlY3RhYmxlLSBFcnJOb24t
RmF0YWwtIEVyckZhdGFsLSBQTUVJbnRFbmEtIENSU1Zpc2libGUtDQoJCVJvb3RDYXA6IENS
U1Zpc2libGUtDQoJCVJvb3RTdGE6IFBNRSBSZXFJRCAwMDAwLCBQTUVTdGF0dXMtIFBNRVBl
bmRpbmctDQoJCURldkNhcDI6IENvbXBsZXRpb24gVGltZW91dDogUmFuZ2UgQUJDRCwgVGlt
ZW91dERpcysgQVJJRndkKw0KCQlEZXZDdGwyOiBDb21wbGV0aW9uIFRpbWVvdXQ6IDY1bXMg
dG8gMjEwbXMsIFRpbWVvdXREaXMtIEFSSUZ3ZC0NCgkJTG5rQ3RsMjogVGFyZ2V0IExpbmsg
U3BlZWQ6IDIuNUdUL3MsIEVudGVyQ29tcGxpYW5jZS0gU3BlZWREaXMtLCBTZWxlY3RhYmxl
IERlLWVtcGhhc2lzOiAtNmRCDQoJCQkgVHJhbnNtaXQgTWFyZ2luOiBOb3JtYWwgT3BlcmF0
aW5nIFJhbmdlLCBFbnRlck1vZGlmaWVkQ29tcGxpYW5jZS0gQ29tcGxpYW5jZVNPUy0NCgkJ
CSBDb21wbGlhbmNlIERlLWVtcGhhc2lzOiAtNmRCDQoJCUxua1N0YTI6IEN1cnJlbnQgRGUt
ZW1waGFzaXMgTGV2ZWw6IC02ZEINCglDYXBhYmlsaXRpZXM6IFthMF0gTVNJOiBFbmFibGUr
IENvdW50PTEvMSBNYXNrYWJsZS0gNjRiaXQtDQoJCUFkZHJlc3M6IGZlZTNmMDBjICBEYXRh
OiA0MTcxDQoJQ2FwYWJpbGl0aWVzOiBbYjBdIFN1YnN5c3RlbTogQVRJIFRlY2hub2xvZ2ll
cyBJbmMgRGV2aWNlIFsxMDAyOjVhMTFdDQoJQ2FwYWJpbGl0aWVzOiBbYjhdIEh5cGVyVHJh
bnNwb3J0OiBNU0kgTWFwcGluZyBFbmFibGUrIEZpeGVkKw0KCUNhcGFiaWxpdGllczogWzEw
MCB2MV0gVmVuZG9yIFNwZWNpZmljIEluZm9ybWF0aW9uOiBJRD0wMDAxIFJldj0xIExlbj0w
MTAgPD8+DQoJQ2FwYWJpbGl0aWVzOiBbMTkwIHYxXSBBY2Nlc3MgQ29udHJvbCBTZXJ2aWNl
cw0KCQlBQ1NDYXA6CVNyY1ZhbGlkKyBUcmFuc0JsaysgUmVxUmVkaXIrIENtcGx0UmVkaXIr
IFVwc3RyZWFtRndkKyBFZ3Jlc3NDdHJsLSBEaXJlY3RUcmFucysNCgkJQUNTQ3RsOglTcmNW
YWxpZCsgVHJhbnNCbGstIFJlcVJlZGlyKyBDbXBsdFJlZGlyKyBVcHN0cmVhbUZ3ZCsgRWdy
ZXNzQ3RybC0gRGlyZWN0VHJhbnMtDQoJS2VybmVsIGRyaXZlciBpbiB1c2U6IHBjaWVwb3J0
DQoNCjAwOjBiLjAgUENJIGJyaWRnZSBbMDYwNF06IEFUSSBUZWNobm9sb2dpZXMgSW5jIFJE
ODkwIFBDSSB0byBQQ0kgYnJpZGdlIChOQi1TQiBsaW5rKSBbMTAwMjo1YTFmXSAocHJvZy1p
ZiAwMCBbTm9ybWFsIGRlY29kZV0pDQoJQ29udHJvbDogSS9PKyBNZW0rIEJ1c01hc3Rlcisg
U3BlY0N5Y2xlLSBNZW1XSU5WLSBWR0FTbm9vcC0gUGFyRXJyLSBTdGVwcGluZy0gU0VSUisg
RmFzdEIyQi0gRGlzSU5UeCsNCglTdGF0dXM6IENhcCsgNjZNSHotIFVERi0gRmFzdEIyQi0g
UGFyRXJyLSBERVZTRUw9ZmFzdCA+VEFib3J0LSA8VEFib3J0LSA8TUFib3J0LSA+U0VSUi0g
PFBFUlItIElOVHgtDQoJTGF0ZW5jeTogMCwgQ2FjaGUgTGluZSBTaXplOiA2NCBieXRlcw0K
CUJ1czogcHJpbWFyeT0wMCwgc2Vjb25kYXJ5PTA2LCBzdWJvcmRpbmF0ZT0wNiwgc2VjLWxh
dGVuY3k9MA0KCUkvTyBiZWhpbmQgYnJpZGdlOiAwMDAwYjAwMC0wMDAwYmZmZg0KCU1lbW9y
eSBiZWhpbmQgYnJpZGdlOiBmOTkwMDAwMC1mOTlmZmZmZg0KCVByZWZldGNoYWJsZSBtZW1v
cnkgYmVoaW5kIGJyaWRnZTogMDAwMDAwMDBiMDAwMDAwMC0wMDAwMDAwMGJmZmZmZmZmDQoJ
U2Vjb25kYXJ5IHN0YXR1czogNjZNSHotIEZhc3RCMkItIFBhckVyci0gREVWU0VMPWZhc3Qg
PlRBYm9ydC0gPFRBYm9ydC0gPE1BYm9ydC0gPFNFUlItIDxQRVJSLQ0KCUJyaWRnZUN0bDog
UGFyaXR5KyBTRVJSKyBOb0lTQSsgVkdBLSBNQWJvcnQtID5SZXNldC0gRmFzdEIyQi0NCgkJ
UHJpRGlzY1Rtci0gU2VjRGlzY1Rtci0gRGlzY1RtclN0YXQtIERpc2NUbXJTRVJSRW4tDQoJ
Q2FwYWJpbGl0aWVzOiBbNTBdIFBvd2VyIE1hbmFnZW1lbnQgdmVyc2lvbiAzDQoJCUZsYWdz
OiBQTUVDbGstIERTSS0gRDEtIEQyLSBBdXhDdXJyZW50PTBtQSBQTUUoRDArLEQxLSxEMi0s
RDNob3QrLEQzY29sZCspDQoJCVN0YXR1czogRDAgTm9Tb2Z0UnN0LSBQTUUtRW5hYmxlLSBE
U2VsPTAgRFNjYWxlPTAgUE1FLQ0KCUNhcGFiaWxpdGllczogWzU4XSBFeHByZXNzICh2Mikg
Um9vdCBQb3J0IChTbG90KyksIE1TSSAwMA0KCQlEZXZDYXA6CU1heFBheWxvYWQgMTI4IGJ5
dGVzLCBQaGFudEZ1bmMgMCwgTGF0ZW5jeSBMMHMgPDY0bnMsIEwxIDwxdXMNCgkJCUV4dFRh
ZysgUkJFKyBGTFJlc2V0LQ0KCQlEZXZDdGw6CVJlcG9ydCBlcnJvcnM6IENvcnJlY3RhYmxl
LSBOb24tRmF0YWwtIEZhdGFsLSBVbnN1cHBvcnRlZC0NCgkJCVJseGRPcmQrIEV4dFRhZy0g
UGhhbnRGdW5jLSBBdXhQd3ItIE5vU25vb3ArDQoJCQlNYXhQYXlsb2FkIDEyOCBieXRlcywg
TWF4UmVhZFJlcSAxMjggYnl0ZXMNCgkJRGV2U3RhOglDb3JyRXJyLSBVbmNvcnJFcnItIEZh
dGFsRXJyLSBVbnN1cHBSZXEtIEF1eFB3ci0gVHJhbnNQZW5kLQ0KCQlMbmtDYXA6CVBvcnQg
IzAsIFNwZWVkIDVHVC9zLCBXaWR0aCB4OCwgQVNQTSBMMHMgTDEsIExhdGVuY3kgTDAgPDF1
cywgTDEgPDh1cw0KCQkJQ2xvY2tQTS0gU3VycHJpc2UtIExMQWN0UmVwKyBCd05vdCsNCgkJ
TG5rQ3RsOglBU1BNIERpc2FibGVkOyBSQ0IgNjQgYnl0ZXMgRGlzYWJsZWQtIFJldHJhaW4t
IENvbW1DbGsrDQoJCQlFeHRTeW5jaC0gQ2xvY2tQTS0gQXV0V2lkRGlzLSBCV0ludC0gQXV0
QldJbnQtDQoJCUxua1N0YToJU3BlZWQgMi41R1QvcywgV2lkdGggeDEsIFRyRXJyLSBUcmFp
bi0gU2xvdENsaysgRExBY3RpdmUrIEJXTWdtdCsgQUJXTWdtdC0NCgkJU2x0Q2FwOglBdHRu
QnRuLSBQd3JDdHJsLSBNUkwtIEF0dG5JbmQtIFB3ckluZC0gSG90UGx1Zy0gU3VycHJpc2Ut
DQoJCQlTbG90ICM1LCBQb3dlckxpbWl0IDMxLjAwMFc7IEludGVybG9jay0gTm9Db21wbCsN
CgkJU2x0Q3RsOglFbmFibGU6IEF0dG5CdG4tIFB3ckZsdC0gTVJMLSBQcmVzRGV0LSBDbWRD
cGx0LSBIUElycS0gTGlua0NoZy0NCgkJCUNvbnRyb2w6IEF0dG5JbmQgVW5rbm93biwgUHdy
SW5kIFVua25vd24sIFBvd2VyLSBJbnRlcmxvY2stDQoJCVNsdFN0YToJU3RhdHVzOiBBdHRu
QnRuLSBQb3dlckZsdC0gTVJMLSBDbWRDcGx0LSBQcmVzRGV0KyBJbnRlcmxvY2stDQoJCQlD
aGFuZ2VkOiBNUkwtIFByZXNEZXQrIExpbmtTdGF0ZSsNCgkJUm9vdEN0bDogRXJyQ29ycmVj
dGFibGUtIEVyck5vbi1GYXRhbC0gRXJyRmF0YWwtIFBNRUludEVuYS0gQ1JTVmlzaWJsZS0N
CgkJUm9vdENhcDogQ1JTVmlzaWJsZS0NCgkJUm9vdFN0YTogUE1FIFJlcUlEIDAwMDAsIFBN
RVN0YXR1cy0gUE1FUGVuZGluZy0NCgkJRGV2Q2FwMjogQ29tcGxldGlvbiBUaW1lb3V0OiBS
YW5nZSBBQkNELCBUaW1lb3V0RGlzKyBBUklGd2QrDQoJCURldkN0bDI6IENvbXBsZXRpb24g
VGltZW91dDogNjVtcyB0byAyMTBtcywgVGltZW91dERpcy0gQVJJRndkLQ0KCQlMbmtDdGwy
OiBUYXJnZXQgTGluayBTcGVlZDogNUdUL3MsIEVudGVyQ29tcGxpYW5jZS0gU3BlZWREaXMt
LCBTZWxlY3RhYmxlIERlLWVtcGhhc2lzOiAtMy41ZEINCgkJCSBUcmFuc21pdCBNYXJnaW46
IE5vcm1hbCBPcGVyYXRpbmcgUmFuZ2UsIEVudGVyTW9kaWZpZWRDb21wbGlhbmNlLSBDb21w
bGlhbmNlU09TLQ0KCQkJIENvbXBsaWFuY2UgRGUtZW1waGFzaXM6IC02ZEINCgkJTG5rU3Rh
MjogQ3VycmVudCBEZS1lbXBoYXNpcyBMZXZlbDogLTMuNWRCDQoJQ2FwYWJpbGl0aWVzOiBb
YTBdIE1TSTogRW5hYmxlKyBDb3VudD0xLzEgTWFza2FibGUtIDY0Yml0LQ0KCQlBZGRyZXNz
OiBmZWUzZjAwYyAgRGF0YTogNDE3OQ0KCUNhcGFiaWxpdGllczogW2IwXSBTdWJzeXN0ZW06
IEFUSSBUZWNobm9sb2dpZXMgSW5jIERldmljZSBbMTAwMjo1YTExXQ0KCUNhcGFiaWxpdGll
czogW2I4XSBIeXBlclRyYW5zcG9ydDogTVNJIE1hcHBpbmcgRW5hYmxlKyBGaXhlZCsNCglD
YXBhYmlsaXRpZXM6IFsxMDAgdjFdIFZlbmRvciBTcGVjaWZpYyBJbmZvcm1hdGlvbjogSUQ9
MDAwMSBSZXY9MSBMZW49MDEwIDw/Pg0KCUNhcGFiaWxpdGllczogWzE5MCB2MV0gQWNjZXNz
IENvbnRyb2wgU2VydmljZXMNCgkJQUNTQ2FwOglTcmNWYWxpZCsgVHJhbnNCbGsrIFJlcVJl
ZGlyKyBDbXBsdFJlZGlyKyBVcHN0cmVhbUZ3ZCsgRWdyZXNzQ3RybC0gRGlyZWN0VHJhbnMr
DQoJCUFDU0N0bDoJU3JjVmFsaWQrIFRyYW5zQmxrLSBSZXFSZWRpcisgQ21wbHRSZWRpcisg
VXBzdHJlYW1Gd2QrIEVncmVzc0N0cmwtIERpcmVjdFRyYW5zLQ0KCUtlcm5lbCBkcml2ZXIg
aW4gdXNlOiBwY2llcG9ydA0KDQowMDowYy4wIFBDSSBicmlkZ2UgWzA2MDRdOiBBVEkgVGVj
aG5vbG9naWVzIEluYyBEZXZpY2UgWzEwMDI6NWEyMF0gKHByb2ctaWYgMDAgW05vcm1hbCBk
ZWNvZGVdKQ0KCUNvbnRyb2w6IEkvTy0gTWVtKyBCdXNNYXN0ZXIrIFNwZWNDeWNsZS0gTWVt
V0lOVi0gVkdBU25vb3AtIFBhckVyci0gU3RlcHBpbmctIFNFUlIrIEZhc3RCMkItIERpc0lO
VHgrDQoJU3RhdHVzOiBDYXArIDY2TUh6LSBVREYtIEZhc3RCMkItIFBhckVyci0gREVWU0VM
PWZhc3QgPlRBYm9ydC0gPFRBYm9ydC0gPE1BYm9ydC0gPlNFUlItIDxQRVJSLSBJTlR4LQ0K
CUxhdGVuY3k6IDAsIENhY2hlIExpbmUgU2l6ZTogNjQgYnl0ZXMNCglCdXM6IHByaW1hcnk9
MDAsIHNlY29uZGFyeT0wNSwgc3Vib3JkaW5hdGU9MDUsIHNlYy1sYXRlbmN5PTANCglJL08g
YmVoaW5kIGJyaWRnZTogMDAwMGYwMDAtMDAwMDBmZmYNCglNZW1vcnkgYmVoaW5kIGJyaWRn
ZTogZjk2MDAwMDAtZjk3ZmZmZmYNCglQcmVmZXRjaGFibGUgbWVtb3J5IGJlaGluZCBicmlk
Z2U6IDAwMDAwMDAwZmZmMDAwMDAtMDAwMDAwMDAwMDBmZmZmZg0KCVNlY29uZGFyeSBzdGF0
dXM6IDY2TUh6LSBGYXN0QjJCLSBQYXJFcnItIERFVlNFTD1mYXN0ID5UQWJvcnQtIDxUQWJv
cnQtIDxNQWJvcnQrIDxTRVJSLSA8UEVSUi0NCglCcmlkZ2VDdGw6IFBhcml0eSsgU0VSUisg
Tm9JU0ErIFZHQS0gTUFib3J0LSA+UmVzZXQtIEZhc3RCMkItDQoJCVByaURpc2NUbXItIFNl
Y0Rpc2NUbXItIERpc2NUbXJTdGF0LSBEaXNjVG1yU0VSUkVuLQ0KCUNhcGFiaWxpdGllczog
WzUwXSBQb3dlciBNYW5hZ2VtZW50IHZlcnNpb24gMw0KCQlGbGFnczogUE1FQ2xrLSBEU0kt
IEQxLSBEMi0gQXV4Q3VycmVudD0wbUEgUE1FKEQwKyxEMS0sRDItLEQzaG90KyxEM2NvbGQr
KQ0KCQlTdGF0dXM6IEQwIE5vU29mdFJzdC0gUE1FLUVuYWJsZS0gRFNlbD0wIERTY2FsZT0w
IFBNRS0NCglDYXBhYmlsaXRpZXM6IFs1OF0gRXhwcmVzcyAodjIpIFJvb3QgUG9ydCAoU2xv
dCspLCBNU0kgMDANCgkJRGV2Q2FwOglNYXhQYXlsb2FkIDEyOCBieXRlcywgUGhhbnRGdW5j
IDAsIExhdGVuY3kgTDBzIDw2NG5zLCBMMSA8MXVzDQoJCQlFeHRUYWcrIFJCRSsgRkxSZXNl
dC0NCgkJRGV2Q3RsOglSZXBvcnQgZXJyb3JzOiBDb3JyZWN0YWJsZS0gTm9uLUZhdGFsLSBG
YXRhbC0gVW5zdXBwb3J0ZWQtDQoJCQlSbHhkT3JkKyBFeHRUYWctIFBoYW50RnVuYy0gQXV4
UHdyLSBOb1Nub29wKw0KCQkJTWF4UGF5bG9hZCAxMjggYnl0ZXMsIE1heFJlYWRSZXEgMTI4
IGJ5dGVzDQoJCURldlN0YToJQ29yckVyci0gVW5jb3JyRXJyLSBGYXRhbEVyci0gVW5zdXBw
UmVxLSBBdXhQd3ItIFRyYW5zUGVuZC0NCgkJTG5rQ2FwOglQb3J0ICMxLCBTcGVlZCA1R1Qv
cywgV2lkdGggeDgsIEFTUE0gTDBzIEwxLCBMYXRlbmN5IEwwIDwxdXMsIEwxIDw4dXMNCgkJ
CUNsb2NrUE0tIFN1cnByaXNlLSBMTEFjdFJlcCsgQndOb3QrDQoJCUxua0N0bDoJQVNQTSBE
aXNhYmxlZDsgUkNCIDY0IGJ5dGVzIERpc2FibGVkLSBSZXRyYWluLSBDb21tQ2xrLQ0KCQkJ
RXh0U3luY2gtIENsb2NrUE0tIEF1dFdpZERpcy0gQldJbnQtIEF1dEJXSW50LQ0KCQlMbmtT
dGE6CVNwZWVkIDIuNUdUL3MsIFdpZHRoIHgxLCBUckVyci0gVHJhaW4tIFNsb3RDbGsrIERM
QWN0aXZlKyBCV01nbXQrIEFCV01nbXQtDQoJCVNsdENhcDoJQXR0bkJ0bi0gUHdyQ3RybC0g
TVJMLSBBdHRuSW5kLSBQd3JJbmQtIEhvdFBsdWctIFN1cnByaXNlLQ0KCQkJU2xvdCAjNiwg
UG93ZXJMaW1pdCAxNC4wMDBXOyBJbnRlcmxvY2stIE5vQ29tcGwrDQoJCVNsdEN0bDoJRW5h
YmxlOiBBdHRuQnRuLSBQd3JGbHQtIE1STC0gUHJlc0RldC0gQ21kQ3BsdC0gSFBJcnEtIExp
bmtDaGctDQoJCQlDb250cm9sOiBBdHRuSW5kIFVua25vd24sIFB3ckluZCBVbmtub3duLCBQ
b3dlci0gSW50ZXJsb2NrLQ0KCQlTbHRTdGE6CVN0YXR1czogQXR0bkJ0bi0gUG93ZXJGbHQt
IE1STC0gQ21kQ3BsdC0gUHJlc0RldCsgSW50ZXJsb2NrLQ0KCQkJQ2hhbmdlZDogTVJMLSBQ
cmVzRGV0KyBMaW5rU3RhdGUrDQoJCVJvb3RDdGw6IEVyckNvcnJlY3RhYmxlLSBFcnJOb24t
RmF0YWwtIEVyckZhdGFsLSBQTUVJbnRFbmEtIENSU1Zpc2libGUtDQoJCVJvb3RDYXA6IENS
U1Zpc2libGUtDQoJCVJvb3RTdGE6IFBNRSBSZXFJRCAwMDAwLCBQTUVTdGF0dXMtIFBNRVBl
bmRpbmctDQoJCURldkNhcDI6IENvbXBsZXRpb24gVGltZW91dDogUmFuZ2UgQUJDRCwgVGlt
ZW91dERpcysgQVJJRndkKw0KCQlEZXZDdGwyOiBDb21wbGV0aW9uIFRpbWVvdXQ6IDY1bXMg
dG8gMjEwbXMsIFRpbWVvdXREaXMtIEFSSUZ3ZC0NCgkJTG5rQ3RsMjogVGFyZ2V0IExpbmsg
U3BlZWQ6IDVHVC9zLCBFbnRlckNvbXBsaWFuY2UtIFNwZWVkRGlzLSwgU2VsZWN0YWJsZSBE
ZS1lbXBoYXNpczogLTMuNWRCDQoJCQkgVHJhbnNtaXQgTWFyZ2luOiBOb3JtYWwgT3BlcmF0
aW5nIFJhbmdlLCBFbnRlck1vZGlmaWVkQ29tcGxpYW5jZS0gQ29tcGxpYW5jZVNPUy0NCgkJ
CSBDb21wbGlhbmNlIERlLWVtcGhhc2lzOiAtNmRCDQoJCUxua1N0YTI6IEN1cnJlbnQgRGUt
ZW1waGFzaXMgTGV2ZWw6IC0zLjVkQg0KCUNhcGFiaWxpdGllczogW2EwXSBNU0k6IEVuYWJs
ZSsgQ291bnQ9MS8xIE1hc2thYmxlLSA2NGJpdC0NCgkJQWRkcmVzczogZmVlM2YwMGMgIERh
dGE6IDQxODENCglDYXBhYmlsaXRpZXM6IFtiMF0gU3Vic3lzdGVtOiBBVEkgVGVjaG5vbG9n
aWVzIEluYyBEZXZpY2UgWzEwMDI6NWExMV0NCglDYXBhYmlsaXRpZXM6IFtiOF0gSHlwZXJU
cmFuc3BvcnQ6IE1TSSBNYXBwaW5nIEVuYWJsZSsgRml4ZWQrDQoJQ2FwYWJpbGl0aWVzOiBb
MTAwIHYxXSBWZW5kb3IgU3BlY2lmaWMgSW5mb3JtYXRpb246IElEPTAwMDEgUmV2PTEgTGVu
PTAxMCA8Pz4NCglDYXBhYmlsaXRpZXM6IFsxOTAgdjFdIEFjY2VzcyBDb250cm9sIFNlcnZp
Y2VzDQoJCUFDU0NhcDoJU3JjVmFsaWQrIFRyYW5zQmxrKyBSZXFSZWRpcisgQ21wbHRSZWRp
cisgVXBzdHJlYW1Gd2QrIEVncmVzc0N0cmwtIERpcmVjdFRyYW5zKw0KCQlBQ1NDdGw6CVNy
Y1ZhbGlkKyBUcmFuc0Jsay0gUmVxUmVkaXIrIENtcGx0UmVkaXIrIFVwc3RyZWFtRndkKyBF
Z3Jlc3NDdHJsLSBEaXJlY3RUcmFucy0NCglLZXJuZWwgZHJpdmVyIGluIHVzZTogcGNpZXBv
cnQNCg0KMDA6MGQuMCBQQ0kgYnJpZGdlIFswNjA0XTogQVRJIFRlY2hub2xvZ2llcyBJbmMg
UkQ4OTAgUENJIHRvIFBDSSBicmlkZ2UgKGV4dGVybmFsIGdmeDEgcG9ydCBCKSBbMTAwMjo1
YTFlXSAocHJvZy1pZiAwMCBbTm9ybWFsIGRlY29kZV0pDQoJQ29udHJvbDogSS9PLSBNZW0r
IEJ1c01hc3RlcisgU3BlY0N5Y2xlLSBNZW1XSU5WLSBWR0FTbm9vcC0gUGFyRXJyLSBTdGVw
cGluZy0gU0VSUisgRmFzdEIyQi0gRGlzSU5UeCsNCglTdGF0dXM6IENhcCsgNjZNSHotIFVE
Ri0gRmFzdEIyQi0gUGFyRXJyLSBERVZTRUw9ZmFzdCA+VEFib3J0LSA8VEFib3J0LSA8TUFi
b3J0LSA+U0VSUi0gPFBFUlItIElOVHgtDQoJTGF0ZW5jeTogMCwgQ2FjaGUgTGluZSBTaXpl
OiA2NCBieXRlcw0KCUJ1czogcHJpbWFyeT0wMCwgc2Vjb25kYXJ5PTA0LCBzdWJvcmRpbmF0
ZT0wNCwgc2VjLWxhdGVuY3k9MA0KCUkvTyBiZWhpbmQgYnJpZGdlOiAwMDAwZjAwMC0wMDAw
MGZmZg0KCU1lbW9yeSBiZWhpbmQgYnJpZGdlOiBmOTUwMDAwMC1mOTVmZmZmZg0KCVByZWZl
dGNoYWJsZSBtZW1vcnkgYmVoaW5kIGJyaWRnZTogMDAwMDAwMDBmZmYwMDAwMC0wMDAwMDAw
MDAwMGZmZmZmDQoJU2Vjb25kYXJ5IHN0YXR1czogNjZNSHotIEZhc3RCMkItIFBhckVyci0g
REVWU0VMPWZhc3QgPlRBYm9ydC0gPFRBYm9ydC0gPE1BYm9ydC0gPFNFUlItIDxQRVJSLQ0K
CUJyaWRnZUN0bDogUGFyaXR5KyBTRVJSKyBOb0lTQSsgVkdBLSBNQWJvcnQtID5SZXNldC0g
RmFzdEIyQi0NCgkJUHJpRGlzY1Rtci0gU2VjRGlzY1Rtci0gRGlzY1RtclN0YXQtIERpc2NU
bXJTRVJSRW4tDQoJQ2FwYWJpbGl0aWVzOiBbNTBdIFBvd2VyIE1hbmFnZW1lbnQgdmVyc2lv
biAzDQoJCUZsYWdzOiBQTUVDbGstIERTSS0gRDEtIEQyLSBBdXhDdXJyZW50PTBtQSBQTUUo
RDArLEQxLSxEMi0sRDNob3QrLEQzY29sZCspDQoJCVN0YXR1czogRDAgTm9Tb2Z0UnN0LSBQ
TUUtRW5hYmxlLSBEU2VsPTAgRFNjYWxlPTAgUE1FLQ0KCUNhcGFiaWxpdGllczogWzU4XSBF
eHByZXNzICh2MikgUm9vdCBQb3J0IChTbG90KyksIE1TSSAwMA0KCQlEZXZDYXA6CU1heFBh
eWxvYWQgMTI4IGJ5dGVzLCBQaGFudEZ1bmMgMCwgTGF0ZW5jeSBMMHMgPDY0bnMsIEwxIDwx
dXMNCgkJCUV4dFRhZysgUkJFKyBGTFJlc2V0LQ0KCQlEZXZDdGw6CVJlcG9ydCBlcnJvcnM6
IENvcnJlY3RhYmxlLSBOb24tRmF0YWwtIEZhdGFsLSBVbnN1cHBvcnRlZC0NCgkJCVJseGRP
cmQrIEV4dFRhZy0gUGhhbnRGdW5jLSBBdXhQd3ItIE5vU25vb3ArDQoJCQlNYXhQYXlsb2Fk
IDEyOCBieXRlcywgTWF4UmVhZFJlcSAxMjggYnl0ZXMNCgkJRGV2U3RhOglDb3JyRXJyLSBV
bmNvcnJFcnItIEZhdGFsRXJyLSBVbnN1cHBSZXEtIEF1eFB3ci0gVHJhbnNQZW5kLQ0KCQlM
bmtDYXA6CVBvcnQgIzAsIFNwZWVkIDVHVC9zLCBXaWR0aCB4NCwgQVNQTSBMMHMgTDEsIExh
dGVuY3kgTDAgPDF1cywgTDEgPDh1cw0KCQkJQ2xvY2tQTS0gU3VycHJpc2UtIExMQWN0UmVw
KyBCd05vdCsNCgkJTG5rQ3RsOglBU1BNIERpc2FibGVkOyBSQ0IgNjQgYnl0ZXMgRGlzYWJs
ZWQtIFJldHJhaW4tIENvbW1DbGstDQoJCQlFeHRTeW5jaC0gQ2xvY2tQTS0gQXV0V2lkRGlz
LSBCV0ludC0gQXV0QldJbnQtDQoJCUxua1N0YToJU3BlZWQgMi41R1QvcywgV2lkdGggeDEs
IFRyRXJyLSBUcmFpbi0gU2xvdENsaysgRExBY3RpdmUrIEJXTWdtdCsgQUJXTWdtdC0NCgkJ
U2x0Q2FwOglBdHRuQnRuLSBQd3JDdHJsLSBNUkwtIEF0dG5JbmQtIFB3ckluZC0gSG90UGx1
Zy0gU3VycHJpc2UtDQoJCQlTbG90ICM0LCBQb3dlckxpbWl0IDc1LjAwMFc7IEludGVybG9j
ay0gTm9Db21wbCsNCgkJU2x0Q3RsOglFbmFibGU6IEF0dG5CdG4tIFB3ckZsdC0gTVJMLSBQ
cmVzRGV0LSBDbWRDcGx0LSBIUElycS0gTGlua0NoZy0NCgkJCUNvbnRyb2w6IEF0dG5JbmQg
VW5rbm93biwgUHdySW5kIFVua25vd24sIFBvd2VyLSBJbnRlcmxvY2stDQoJCVNsdFN0YToJ
U3RhdHVzOiBBdHRuQnRuLSBQb3dlckZsdC0gTVJMLSBDbWRDcGx0LSBQcmVzRGV0KyBJbnRl
cmxvY2stDQoJCQlDaGFuZ2VkOiBNUkwtIFByZXNEZXQrIExpbmtTdGF0ZSsNCgkJUm9vdEN0
bDogRXJyQ29ycmVjdGFibGUtIEVyck5vbi1GYXRhbC0gRXJyRmF0YWwtIFBNRUludEVuYS0g
Q1JTVmlzaWJsZS0NCgkJUm9vdENhcDogQ1JTVmlzaWJsZS0NCgkJUm9vdFN0YTogUE1FIFJl
cUlEIDAwMDAsIFBNRVN0YXR1cy0gUE1FUGVuZGluZy0NCgkJRGV2Q2FwMjogQ29tcGxldGlv
biBUaW1lb3V0OiBSYW5nZSBBQkNELCBUaW1lb3V0RGlzKyBBUklGd2QrDQoJCURldkN0bDI6
IENvbXBsZXRpb24gVGltZW91dDogNjVtcyB0byAyMTBtcywgVGltZW91dERpcy0gQVJJRndk
LQ0KCQlMbmtDdGwyOiBUYXJnZXQgTGluayBTcGVlZDogNUdUL3MsIEVudGVyQ29tcGxpYW5j
ZS0gU3BlZWREaXMtLCBTZWxlY3RhYmxlIERlLWVtcGhhc2lzOiAtMy41ZEINCgkJCSBUcmFu
c21pdCBNYXJnaW46IE5vcm1hbCBPcGVyYXRpbmcgUmFuZ2UsIEVudGVyTW9kaWZpZWRDb21w
bGlhbmNlLSBDb21wbGlhbmNlU09TLQ0KCQkJIENvbXBsaWFuY2UgRGUtZW1waGFzaXM6IC02
ZEINCgkJTG5rU3RhMjogQ3VycmVudCBEZS1lbXBoYXNpcyBMZXZlbDogLTMuNWRCDQoJQ2Fw
YWJpbGl0aWVzOiBbYTBdIE1TSTogRW5hYmxlKyBDb3VudD0xLzEgTWFza2FibGUtIDY0Yml0
LQ0KCQlBZGRyZXNzOiBmZWUzZjAwYyAgRGF0YTogNDE4OQ0KCUNhcGFiaWxpdGllczogW2Iw
XSBTdWJzeXN0ZW06IEFUSSBUZWNobm9sb2dpZXMgSW5jIERldmljZSBbMTAwMjo1YTExXQ0K
CUNhcGFiaWxpdGllczogW2I4XSBIeXBlclRyYW5zcG9ydDogTVNJIE1hcHBpbmcgRW5hYmxl
KyBGaXhlZCsNCglDYXBhYmlsaXRpZXM6IFsxMDAgdjFdIFZlbmRvciBTcGVjaWZpYyBJbmZv
cm1hdGlvbjogSUQ9MDAwMSBSZXY9MSBMZW49MDEwIDw/Pg0KCUNhcGFiaWxpdGllczogWzE5
MCB2MV0gQWNjZXNzIENvbnRyb2wgU2VydmljZXMNCgkJQUNTQ2FwOglTcmNWYWxpZCsgVHJh
bnNCbGsrIFJlcVJlZGlyKyBDbXBsdFJlZGlyKyBVcHN0cmVhbUZ3ZCsgRWdyZXNzQ3RybC0g
RGlyZWN0VHJhbnMrDQoJCUFDU0N0bDoJU3JjVmFsaWQrIFRyYW5zQmxrLSBSZXFSZWRpcisg
Q21wbHRSZWRpcisgVXBzdHJlYW1Gd2QrIEVncmVzc0N0cmwtIERpcmVjdFRyYW5zLQ0KCUtl
cm5lbCBkcml2ZXIgaW4gdXNlOiBwY2llcG9ydA0KDQowMDoxMS4wIFNBVEEgY29udHJvbGxl
ciBbMDEwNl06IEFUSSBUZWNobm9sb2dpZXMgSW5jIFNCN3gwL1NCOHgwL1NCOXgwIFNBVEEg
Q29udHJvbGxlciBbQUhDSSBtb2RlXSBbMTAwMjo0MzkxXSAocmV2IDQwKSAocHJvZy1pZiAw
MSBbQUhDSSAxLjBdKQ0KCVN1YnN5c3RlbTogTWljcm8tU3RhciBJbnRlcm5hdGlvbmFsIENv
LiwgTHRkLiBEZXZpY2UgWzE0NjI6NzY0MF0NCglDb250cm9sOiBJL08rIE1lbSsgQnVzTWFz
dGVyKyBTcGVjQ3ljbGUtIE1lbVdJTlYtIFZHQVNub29wLSBQYXJFcnItIFN0ZXBwaW5nLSBT
RVJSKyBGYXN0QjJCLSBEaXNJTlR4Kw0KCVN0YXR1czogQ2FwKyA2Nk1IeisgVURGLSBGYXN0
QjJCLSBQYXJFcnItIERFVlNFTD1tZWRpdW0gPlRBYm9ydC0gPFRBYm9ydC0gPE1BYm9ydC0g
PlNFUlItIDxQRVJSLSBJTlR4LQ0KCUxhdGVuY3k6IDY0LCBDYWNoZSBMaW5lIFNpemU6IDY0
IGJ5dGVzDQoJSW50ZXJydXB0OiBwaW4gQSByb3V0ZWQgdG8gSVJRIDEyMA0KCVJlZ2lvbiAw
OiBJL08gcG9ydHMgYXQgNzAwMCBbc2l6ZT04XQ0KCVJlZ2lvbiAxOiBJL08gcG9ydHMgYXQg
NjAwMCBbc2l6ZT00XQ0KCVJlZ2lvbiAyOiBJL08gcG9ydHMgYXQgNTAwMCBbc2l6ZT04XQ0K
CVJlZ2lvbiAzOiBJL08gcG9ydHMgYXQgMzAwMCBbc2l6ZT00XQ0KCVJlZ2lvbiA0OiBJL08g
cG9ydHMgYXQgMjAwMCBbc2l6ZT0xNl0NCglSZWdpb24gNTogTWVtb3J5IGF0IGY5M2ZmMDAw
ICgzMi1iaXQsIG5vbi1wcmVmZXRjaGFibGUpIFtzaXplPTFLXQ0KCUNhcGFiaWxpdGllczog
WzUwXSBNU0k6IEVuYWJsZSsgQ291bnQ9MS84IE1hc2thYmxlLSA2NGJpdCsNCgkJQWRkcmVz
czogMDAwMDAwMDBmZWUwMTAwYyAgRGF0YTogNDFiOQ0KCUNhcGFiaWxpdGllczogWzcwXSBT
QVRBIEhCQSB2MS4wIEluQ2ZnU3BhY2UNCglDYXBhYmlsaXRpZXM6IFthNF0gUENJIEFkdmFu
Y2VkIEZlYXR1cmVzDQoJCUFGQ2FwOiBUUCsgRkxSKw0KCQlBRkN0cmw6IEZMUi0NCgkJQUZT
dGF0dXM6IFRQKw0KCUtlcm5lbCBkcml2ZXIgaW4gdXNlOiBhaGNpDQoNCjAwOjEyLjAgVVNC
IGNvbnRyb2xsZXIgWzBjMDNdOiBBVEkgVGVjaG5vbG9naWVzIEluYyBTQjd4MC9TQjh4MC9T
Qjl4MCBVU0IgT0hDSTAgQ29udHJvbGxlciBbMTAwMjo0Mzk3XSAocHJvZy1pZiAxMCBbT0hD
SV0pDQoJU3Vic3lzdGVtOiBNaWNyby1TdGFyIEludGVybmF0aW9uYWwgQ28uLCBMdGQuIERl
dmljZSBbMTQ2Mjo3NjQwXQ0KCUNvbnRyb2w6IEkvTysgTWVtKyBCdXNNYXN0ZXIrIFNwZWND
eWNsZS0gTWVtV0lOVisgVkdBU25vb3AtIFBhckVyci0gU3RlcHBpbmctIFNFUlIrIEZhc3RC
MkItIERpc0lOVHgtDQoJU3RhdHVzOiBDYXAtIDY2TUh6KyBVREYtIEZhc3RCMkIrIFBhckVy
ci0gREVWU0VMPW1lZGl1bSA+VEFib3J0LSA8VEFib3J0LSA8TUFib3J0LSA+U0VSUi0gPFBF
UlItIElOVHgtDQoJTGF0ZW5jeTogNjQsIENhY2hlIExpbmUgU2l6ZTogNjQgYnl0ZXMNCglJ
bnRlcnJ1cHQ6IHBpbiBBIHJvdXRlZCB0byBJUlEgMTgNCglSZWdpb24gMDogTWVtb3J5IGF0
IGY5M2ZiMDAwICgzMi1iaXQsIG5vbi1wcmVmZXRjaGFibGUpIFtzaXplPTRLXQ0KCUtlcm5l
bCBkcml2ZXIgaW4gdXNlOiBvaGNpX2hjZA0KDQowMDoxMi4yIFVTQiBjb250cm9sbGVyIFsw
YzAzXTogQVRJIFRlY2hub2xvZ2llcyBJbmMgU0I3eDAvU0I4eDAvU0I5eDAgVVNCIEVIQ0kg
Q29udHJvbGxlciBbMTAwMjo0Mzk2XSAocHJvZy1pZiAyMCBbRUhDSV0pDQoJU3Vic3lzdGVt
OiBNaWNyby1TdGFyIEludGVybmF0aW9uYWwgQ28uLCBMdGQuIERldmljZSBbMTQ2Mjo3NjQw
XQ0KCUNvbnRyb2w6IEkvTy0gTWVtKyBCdXNNYXN0ZXIrIFNwZWNDeWNsZS0gTWVtV0lOVisg
VkdBU25vb3AtIFBhckVyci0gU3RlcHBpbmctIFNFUlIrIEZhc3RCMkItIERpc0lOVHgtDQoJ
U3RhdHVzOiBDYXArIDY2TUh6KyBVREYtIEZhc3RCMkIrIFBhckVyci0gREVWU0VMPW1lZGl1
bSA+VEFib3J0LSA8VEFib3J0LSA8TUFib3J0LSA+U0VSUi0gPFBFUlItIElOVHgtDQoJTGF0
ZW5jeTogNjQsIENhY2hlIExpbmUgU2l6ZTogNjQgYnl0ZXMNCglJbnRlcnJ1cHQ6IHBpbiBC
IHJvdXRlZCB0byBJUlEgMTcNCglSZWdpb24gMDogTWVtb3J5IGF0IGY5M2ZmNDAwICgzMi1i
aXQsIG5vbi1wcmVmZXRjaGFibGUpIFtzaXplPTI1Nl0NCglDYXBhYmlsaXRpZXM6IFtjMF0g
UG93ZXIgTWFuYWdlbWVudCB2ZXJzaW9uIDINCgkJRmxhZ3M6IFBNRUNsay0gRFNJLSBEMSsg
RDIrIEF1eEN1cnJlbnQ9MG1BIFBNRShEMCssRDErLEQyKyxEM2hvdCssRDNjb2xkLSkNCgkJ
U3RhdHVzOiBEMCBOb1NvZnRSc3QtIFBNRS1FbmFibGUtIERTZWw9MCBEU2NhbGU9MCBQTUUt
DQoJCUJyaWRnZTogUE0tIEIzKw0KCUNhcGFiaWxpdGllczogW2U0XSBEZWJ1ZyBwb3J0OiBC
QVI9MSBvZmZzZXQ9MDBlMA0KCUtlcm5lbCBkcml2ZXIgaW4gdXNlOiBlaGNpX2hjZA0KDQow
MDoxMy4wIFVTQiBjb250cm9sbGVyIFswYzAzXTogQVRJIFRlY2hub2xvZ2llcyBJbmMgU0I3
eDAvU0I4eDAvU0I5eDAgVVNCIE9IQ0kwIENvbnRyb2xsZXIgWzEwMDI6NDM5N10gKHByb2ct
aWYgMTAgW09IQ0ldKQ0KCVN1YnN5c3RlbTogTWljcm8tU3RhciBJbnRlcm5hdGlvbmFsIENv
LiwgTHRkLiBEZXZpY2UgWzE0NjI6NzY0MF0NCglDb250cm9sOiBJL08rIE1lbSsgQnVzTWFz
dGVyKyBTcGVjQ3ljbGUtIE1lbVdJTlYrIFZHQVNub29wLSBQYXJFcnItIFN0ZXBwaW5nLSBT
RVJSKyBGYXN0QjJCLSBEaXNJTlR4LQ0KCVN0YXR1czogQ2FwLSA2Nk1IeisgVURGLSBGYXN0
QjJCKyBQYXJFcnItIERFVlNFTD1tZWRpdW0gPlRBYm9ydC0gPFRBYm9ydC0gPE1BYm9ydC0g
PlNFUlItIDxQRVJSLSBJTlR4LQ0KCUxhdGVuY3k6IDY0LCBDYWNoZSBMaW5lIFNpemU6IDY0
IGJ5dGVzDQoJSW50ZXJydXB0OiBwaW4gQSByb3V0ZWQgdG8gSVJRIDE4DQoJUmVnaW9uIDA6
IE1lbW9yeSBhdCBmOTNmYzAwMCAoMzItYml0LCBub24tcHJlZmV0Y2hhYmxlKSBbc2l6ZT00
S10NCglLZXJuZWwgZHJpdmVyIGluIHVzZTogb2hjaV9oY2QNCg0KMDA6MTMuMiBVU0IgY29u
dHJvbGxlciBbMGMwM106IEFUSSBUZWNobm9sb2dpZXMgSW5jIFNCN3gwL1NCOHgwL1NCOXgw
IFVTQiBFSENJIENvbnRyb2xsZXIgWzEwMDI6NDM5Nl0gKHByb2ctaWYgMjAgW0VIQ0ldKQ0K
CVN1YnN5c3RlbTogTWljcm8tU3RhciBJbnRlcm5hdGlvbmFsIENvLiwgTHRkLiBEZXZpY2Ug
WzE0NjI6NzY0MF0NCglDb250cm9sOiBJL08tIE1lbSsgQnVzTWFzdGVyKyBTcGVjQ3ljbGUt
IE1lbVdJTlYrIFZHQVNub29wLSBQYXJFcnItIFN0ZXBwaW5nLSBTRVJSKyBGYXN0QjJCLSBE
aXNJTlR4LQ0KCVN0YXR1czogQ2FwKyA2Nk1IeisgVURGLSBGYXN0QjJCKyBQYXJFcnItIERF
VlNFTD1tZWRpdW0gPlRBYm9ydC0gPFRBYm9ydC0gPE1BYm9ydC0gPlNFUlItIDxQRVJSLSBJ
TlR4LQ0KCUxhdGVuY3k6IDY0LCBDYWNoZSBMaW5lIFNpemU6IDY0IGJ5dGVzDQoJSW50ZXJy
dXB0OiBwaW4gQiByb3V0ZWQgdG8gSVJRIDE3DQoJUmVnaW9uIDA6IE1lbW9yeSBhdCBmOTNm
ZjgwMCAoMzItYml0LCBub24tcHJlZmV0Y2hhYmxlKSBbc2l6ZT0yNTZdDQoJQ2FwYWJpbGl0
aWVzOiBbYzBdIFBvd2VyIE1hbmFnZW1lbnQgdmVyc2lvbiAyDQoJCUZsYWdzOiBQTUVDbGst
IERTSS0gRDErIEQyKyBBdXhDdXJyZW50PTBtQSBQTUUoRDArLEQxKyxEMissRDNob3QrLEQz
Y29sZC0pDQoJCVN0YXR1czogRDAgTm9Tb2Z0UnN0LSBQTUUtRW5hYmxlLSBEU2VsPTAgRFNj
YWxlPTAgUE1FLQ0KCQlCcmlkZ2U6IFBNLSBCMysNCglDYXBhYmlsaXRpZXM6IFtlNF0gRGVi
dWcgcG9ydDogQkFSPTEgb2Zmc2V0PTAwZTANCglLZXJuZWwgZHJpdmVyIGluIHVzZTogZWhj
aV9oY2QNCg0KMDA6MTQuMCBTTUJ1cyBbMGMwNV06IEFUSSBUZWNobm9sb2dpZXMgSW5jIFNC
eDAwIFNNQnVzIENvbnRyb2xsZXIgWzEwMDI6NDM4NV0gKHJldiA0MSkNCglDb250cm9sOiBJ
L08rIE1lbSsgQnVzTWFzdGVyLSBTcGVjQ3ljbGUtIE1lbVdJTlYtIFZHQVNub29wLSBQYXJF
cnItIFN0ZXBwaW5nLSBTRVJSLSBGYXN0QjJCLSBEaXNJTlR4Kw0KCVN0YXR1czogQ2FwLSA2
Nk1IeisgVURGLSBGYXN0QjJCLSBQYXJFcnItIERFVlNFTD1tZWRpdW0gPlRBYm9ydC0gPFRB
Ym9ydC0gPE1BYm9ydC0gPlNFUlItIDxQRVJSLSBJTlR4LQ0KDQowMDoxNC4zIElTQSBicmlk
Z2UgWzA2MDFdOiBBVEkgVGVjaG5vbG9naWVzIEluYyBTQjd4MC9TQjh4MC9TQjl4MCBMUEMg
aG9zdCBjb250cm9sbGVyIFsxMDAyOjQzOWRdIChyZXYgNDApDQoJU3Vic3lzdGVtOiBNaWNy
by1TdGFyIEludGVybmF0aW9uYWwgQ28uLCBMdGQuIERldmljZSBbMTQ2Mjo3NjQwXQ0KCUNv
bnRyb2w6IEkvTysgTWVtKyBCdXNNYXN0ZXIrIFNwZWNDeWNsZSsgTWVtV0lOVi0gVkdBU25v
b3AtIFBhckVyci0gU3RlcHBpbmctIFNFUlItIEZhc3RCMkItIERpc0lOVHgtDQoJU3RhdHVz
OiBDYXAtIDY2TUh6KyBVREYtIEZhc3RCMkItIFBhckVyci0gREVWU0VMPW1lZGl1bSA+VEFi
b3J0LSA8VEFib3J0LSA8TUFib3J0LSA+U0VSUi0gPFBFUlItIElOVHgtDQoJTGF0ZW5jeTog
MA0KDQowMDoxNC40IFBDSSBicmlkZ2UgWzA2MDRdOiBBVEkgVGVjaG5vbG9naWVzIEluYyBT
QngwMCBQQ0kgdG8gUENJIEJyaWRnZSBbMTAwMjo0Mzg0XSAocmV2IDQwKSAocHJvZy1pZiAw
MSBbU3VidHJhY3RpdmUgZGVjb2RlXSkNCglDb250cm9sOiBJL08rIE1lbS0gQnVzTWFzdGVy
KyBTcGVjQ3ljbGUtIE1lbVdJTlYtIFZHQVNub29wLSBQYXJFcnItIFN0ZXBwaW5nLSBTRVJS
KyBGYXN0QjJCLSBEaXNJTlR4LQ0KCVN0YXR1czogQ2FwLSA2Nk1IeisgVURGLSBGYXN0QjJC
KyBQYXJFcnItIERFVlNFTD1tZWRpdW0gPlRBYm9ydC0gPFRBYm9ydC0gPE1BYm9ydC0gPlNF
UlItIDxQRVJSLSBJTlR4LQ0KCUxhdGVuY3k6IDY0DQoJQnVzOiBwcmltYXJ5PTAwLCBzZWNv
bmRhcnk9MDMsIHN1Ym9yZGluYXRlPTAzLCBzZWMtbGF0ZW5jeT02NA0KCUkvTyBiZWhpbmQg
YnJpZGdlOiAwMDAwYTAwMC0wMDAwYWZmZg0KCU1lbW9yeSBiZWhpbmQgYnJpZGdlOiBmZmYw
MDAwMC0wMDBmZmZmZg0KCVByZWZldGNoYWJsZSBtZW1vcnkgYmVoaW5kIGJyaWRnZTogZmZm
MDAwMDAtMDAwZmZmZmYNCglTZWNvbmRhcnkgc3RhdHVzOiA2Nk1Iei0gRmFzdEIyQisgUGFy
RXJyLSBERVZTRUw9bWVkaXVtID5UQWJvcnQtIDxUQWJvcnQtIDxNQWJvcnQrIDxTRVJSLSA8
UEVSUi0NCglCcmlkZ2VDdGw6IFBhcml0eSsgU0VSUisgTm9JU0ErIFZHQS0gTUFib3J0LSA+
UmVzZXQtIEZhc3RCMkItDQoJCVByaURpc2NUbXItIFNlY0Rpc2NUbXItIERpc2NUbXJTdGF0
LSBEaXNjVG1yU0VSUkVuLQ0KDQowMDoxNC41IFVTQiBjb250cm9sbGVyIFswYzAzXTogQVRJ
IFRlY2hub2xvZ2llcyBJbmMgU0I3eDAvU0I4eDAvU0I5eDAgVVNCIE9IQ0kyIENvbnRyb2xs
ZXIgWzEwMDI6NDM5OV0gKHByb2ctaWYgMTAgW09IQ0ldKQ0KCVN1YnN5c3RlbTogTWljcm8t
U3RhciBJbnRlcm5hdGlvbmFsIENvLiwgTHRkLiBEZXZpY2UgWzE0NjI6NzY0MF0NCglDb250
cm9sOiBJL08rIE1lbSsgQnVzTWFzdGVyKyBTcGVjQ3ljbGUtIE1lbVdJTlYrIFZHQVNub29w
LSBQYXJFcnItIFN0ZXBwaW5nLSBTRVJSKyBGYXN0QjJCLSBEaXNJTlR4LQ0KCVN0YXR1czog
Q2FwLSA2Nk1IeisgVURGLSBGYXN0QjJCKyBQYXJFcnItIERFVlNFTD1tZWRpdW0gPlRBYm9y
dC0gPFRBYm9ydC0gPE1BYm9ydC0gPlNFUlItIDxQRVJSLSBJTlR4LQ0KCUxhdGVuY3k6IDY0
LCBDYWNoZSBMaW5lIFNpemU6IDY0IGJ5dGVzDQoJSW50ZXJydXB0OiBwaW4gQyByb3V0ZWQg
dG8gSVJRIDE4DQoJUmVnaW9uIDA6IE1lbW9yeSBhdCBmOTNmZDAwMCAoMzItYml0LCBub24t
cHJlZmV0Y2hhYmxlKSBbc2l6ZT00S10NCglLZXJuZWwgZHJpdmVyIGluIHVzZTogb2hjaV9o
Y2QNCg0KMDA6MTUuMCBQQ0kgYnJpZGdlIFswNjA0XTogQVRJIFRlY2hub2xvZ2llcyBJbmMg
U0I3MDAvU0I4MDAvU0I5MDAgUENJIHRvIFBDSSBicmlkZ2UgKFBDSUUgcG9ydCAwKSBbMTAw
Mjo0M2EwXSAocHJvZy1pZiAwMCBbTm9ybWFsIGRlY29kZV0pDQoJQ29udHJvbDogSS9PLSBN
ZW0tIEJ1c01hc3RlcisgU3BlY0N5Y2xlLSBNZW1XSU5WLSBWR0FTbm9vcC0gUGFyRXJyLSBT
dGVwcGluZy0gU0VSUisgRmFzdEIyQi0gRGlzSU5UeCsNCglTdGF0dXM6IENhcCsgNjZNSHot
IFVERi0gRmFzdEIyQi0gUGFyRXJyLSBERVZTRUw9ZmFzdCA+VEFib3J0LSA8VEFib3J0LSA8
TUFib3J0LSA+U0VSUi0gPFBFUlItIElOVHgtDQoJTGF0ZW5jeTogMCwgQ2FjaGUgTGluZSBT
aXplOiA2NCBieXRlcw0KCUJ1czogcHJpbWFyeT0wMCwgc2Vjb25kYXJ5PTAyLCBzdWJvcmRp
bmF0ZT0wMiwgc2VjLWxhdGVuY3k9MA0KCUkvTyBiZWhpbmQgYnJpZGdlOiAwMDAwZjAwMC0w
MDAwMGZmZg0KCU1lbW9yeSBiZWhpbmQgYnJpZGdlOiBmZmYwMDAwMC0wMDBmZmZmZg0KCVBy
ZWZldGNoYWJsZSBtZW1vcnkgYmVoaW5kIGJyaWRnZTogMDAwMDAwMDBmZmYwMDAwMC0wMDAw
MDAwMDAwMGZmZmZmDQoJU2Vjb25kYXJ5IHN0YXR1czogNjZNSHotIEZhc3RCMkItIFBhckVy
ci0gREVWU0VMPWZhc3QgPlRBYm9ydC0gPFRBYm9ydC0gPE1BYm9ydC0gPFNFUlItIDxQRVJS
LQ0KCUJyaWRnZUN0bDogUGFyaXR5KyBTRVJSKyBOb0lTQSsgVkdBLSBNQWJvcnQtID5SZXNl
dC0gRmFzdEIyQi0NCgkJUHJpRGlzY1Rtci0gU2VjRGlzY1Rtci0gRGlzY1RtclN0YXQtIERp
c2NUbXJTRVJSRW4tDQoJQ2FwYWJpbGl0aWVzOiBbNTBdIFBvd2VyIE1hbmFnZW1lbnQgdmVy
c2lvbiAzDQoJCUZsYWdzOiBQTUVDbGstIERTSS0gRDErIEQyKyBBdXhDdXJyZW50PTBtQSBQ
TUUoRDAtLEQxLSxEMi0sRDNob3QtLEQzY29sZC0pDQoJCVN0YXR1czogRDAgTm9Tb2Z0UnN0
LSBQTUUtRW5hYmxlLSBEU2VsPTAgRFNjYWxlPTAgUE1FLQ0KCUNhcGFiaWxpdGllczogWzU4
XSBFeHByZXNzICh2MikgUm9vdCBQb3J0IChTbG90KyksIE1TSSAwMA0KCQlEZXZDYXA6CU1h
eFBheWxvYWQgMTI4IGJ5dGVzLCBQaGFudEZ1bmMgMCwgTGF0ZW5jeSBMMHMgPDY0bnMsIEwx
IDwxdXMNCgkJCUV4dFRhZysgUkJFKyBGTFJlc2V0LQ0KCQlEZXZDdGw6CVJlcG9ydCBlcnJv
cnM6IENvcnJlY3RhYmxlLSBOb24tRmF0YWwtIEZhdGFsLSBVbnN1cHBvcnRlZC0NCgkJCVJs
eGRPcmQrIEV4dFRhZy0gUGhhbnRGdW5jLSBBdXhQd3ItIE5vU25vb3ArDQoJCQlNYXhQYXls
b2FkIDEyOCBieXRlcywgTWF4UmVhZFJlcSAxMjggYnl0ZXMNCgkJRGV2U3RhOglDb3JyRXJy
LSBVbmNvcnJFcnItIEZhdGFsRXJyLSBVbnN1cHBSZXEtIEF1eFB3ci0gVHJhbnNQZW5kLQ0K
CQlMbmtDYXA6CVBvcnQgIzI0NywgU3BlZWQgMi41R1QvcywgV2lkdGggeDEsIEFTUE0gTDBz
IEwxLCBMYXRlbmN5IEwwIDw2NG5zLCBMMSA8MXVzDQoJCQlDbG9ja1BNLSBTdXJwcmlzZS0g
TExBY3RSZXArIEJ3Tm90Kw0KCQlMbmtDdGw6CUFTUE0gRGlzYWJsZWQ7IFJDQiA2NCBieXRl
cyBEaXNhYmxlZC0gUmV0cmFpbi0gQ29tbUNsay0NCgkJCUV4dFN5bmNoLSBDbG9ja1BNLSBB
dXRXaWREaXMtIEJXSW50LSBBdXRCV0ludC0NCgkJTG5rU3RhOglTcGVlZCB1bmtub3duLCBX
aWR0aCB4MTYsIFRyRXJyLSBUcmFpbi0gU2xvdENsaysgRExBY3RpdmUtIEJXTWdtdC0gQUJX
TWdtdC0NCgkJU2x0Q2FwOglBdHRuQnRuLSBQd3JDdHJsLSBNUkwtIEF0dG5JbmQtIFB3cklu
ZC0gSG90UGx1Zy0gU3VycHJpc2UtDQoJCQlTbG90ICMzMiwgUG93ZXJMaW1pdCA3NS4wMDBX
OyBJbnRlcmxvY2stIE5vQ29tcGwrDQoJCVNsdEN0bDoJRW5hYmxlOiBBdHRuQnRuLSBQd3JG
bHQtIE1STC0gUHJlc0RldC0gQ21kQ3BsdC0gSFBJcnEtIExpbmtDaGctDQoJCQlDb250cm9s
OiBBdHRuSW5kIFVua25vd24sIFB3ckluZCBVbmtub3duLCBQb3dlci0gSW50ZXJsb2NrLQ0K
CQlTbHRTdGE6CVN0YXR1czogQXR0bkJ0bi0gUG93ZXJGbHQtIE1STC0gQ21kQ3BsdC0gUHJl
c0RldC0gSW50ZXJsb2NrLQ0KCQkJQ2hhbmdlZDogTVJMLSBQcmVzRGV0LSBMaW5rU3RhdGUt
DQoJCVJvb3RDdGw6IEVyckNvcnJlY3RhYmxlLSBFcnJOb24tRmF0YWwtIEVyckZhdGFsLSBQ
TUVJbnRFbmEtIENSU1Zpc2libGUtDQoJCVJvb3RDYXA6IENSU1Zpc2libGUtDQoJCVJvb3RT
dGE6IFBNRSBSZXFJRCAwMDAwLCBQTUVTdGF0dXMtIFBNRVBlbmRpbmctDQoJCURldkNhcDI6
IENvbXBsZXRpb24gVGltZW91dDogUmFuZ2UgQUJDRCwgVGltZW91dERpcysgQVJJRndkLQ0K
CQlEZXZDdGwyOiBDb21wbGV0aW9uIFRpbWVvdXQ6IDY1bXMgdG8gMjEwbXMsIFRpbWVvdXRE
aXMtIEFSSUZ3ZC0NCgkJTG5rQ3RsMjogVGFyZ2V0IExpbmsgU3BlZWQ6IDIuNUdUL3MsIEVu
dGVyQ29tcGxpYW5jZS0gU3BlZWREaXMtLCBTZWxlY3RhYmxlIERlLWVtcGhhc2lzOiAtMy41
ZEINCgkJCSBUcmFuc21pdCBNYXJnaW46IE5vcm1hbCBPcGVyYXRpbmcgUmFuZ2UsIEVudGVy
TW9kaWZpZWRDb21wbGlhbmNlLSBDb21wbGlhbmNlU09TLQ0KCQkJIENvbXBsaWFuY2UgRGUt
ZW1waGFzaXM6IC02ZEINCgkJTG5rU3RhMjogQ3VycmVudCBEZS1lbXBoYXNpcyBMZXZlbDog
LTZkQg0KCUNhcGFiaWxpdGllczogW2EwXSBNU0k6IEVuYWJsZSsgQ291bnQ9MS8xIE1hc2th
YmxlLSA2NGJpdCsNCgkJQWRkcmVzczogMDAwMDAwMDBmZWUzZjAwYyAgRGF0YTogNDE5MQ0K
CUNhcGFiaWxpdGllczogW2IwXSBTdWJzeXN0ZW06IEFUSSBUZWNobm9sb2dpZXMgSW5jIERl
dmljZSBbMTAwMjowMDAwXQ0KCUNhcGFiaWxpdGllczogW2I4XSBIeXBlclRyYW5zcG9ydDog
TVNJIE1hcHBpbmcgRW5hYmxlKyBGaXhlZCsNCglDYXBhYmlsaXRpZXM6IFsxMDAgdjFdIFZl
bmRvciBTcGVjaWZpYyBJbmZvcm1hdGlvbjogSUQ9MDAwMSBSZXY9MSBMZW49MDEwIDw/Pg0K
CUtlcm5lbCBkcml2ZXIgaW4gdXNlOiBwY2llcG9ydA0KDQowMDoxNi4wIFVTQiBjb250cm9s
bGVyIFswYzAzXTogQVRJIFRlY2hub2xvZ2llcyBJbmMgU0I3eDAvU0I4eDAvU0I5eDAgVVNC
IE9IQ0kwIENvbnRyb2xsZXIgWzEwMDI6NDM5N10gKHByb2ctaWYgMTAgW09IQ0ldKQ0KCVN1
YnN5c3RlbTogTWljcm8tU3RhciBJbnRlcm5hdGlvbmFsIENvLiwgTHRkLiBEZXZpY2UgWzE0
NjI6NzY0MF0NCglDb250cm9sOiBJL08rIE1lbSsgQnVzTWFzdGVyKyBTcGVjQ3ljbGUtIE1l
bVdJTlYrIFZHQVNub29wLSBQYXJFcnItIFN0ZXBwaW5nLSBTRVJSKyBGYXN0QjJCLSBEaXNJ
TlR4LQ0KCVN0YXR1czogQ2FwLSA2Nk1IeisgVURGLSBGYXN0QjJCKyBQYXJFcnItIERFVlNF
TD1tZWRpdW0gPlRBYm9ydC0gPFRBYm9ydC0gPE1BYm9ydC0gPlNFUlItIDxQRVJSLSBJTlR4
LQ0KCUxhdGVuY3k6IDY0LCBDYWNoZSBMaW5lIFNpemU6IDY0IGJ5dGVzDQoJSW50ZXJydXB0
OiBwaW4gQSByb3V0ZWQgdG8gSVJRIDE4DQoJUmVnaW9uIDA6IE1lbW9yeSBhdCBmOTNmZTAw
MCAoMzItYml0LCBub24tcHJlZmV0Y2hhYmxlKSBbc2l6ZT00S10NCglLZXJuZWwgZHJpdmVy
IGluIHVzZTogb2hjaV9oY2QNCg0KMDA6MTYuMiBVU0IgY29udHJvbGxlciBbMGMwM106IEFU
SSBUZWNobm9sb2dpZXMgSW5jIFNCN3gwL1NCOHgwL1NCOXgwIFVTQiBFSENJIENvbnRyb2xs
ZXIgWzEwMDI6NDM5Nl0gKHByb2ctaWYgMjAgW0VIQ0ldKQ0KCVN1YnN5c3RlbTogTWljcm8t
U3RhciBJbnRlcm5hdGlvbmFsIENvLiwgTHRkLiBEZXZpY2UgWzE0NjI6NzY0MF0NCglDb250
cm9sOiBJL08tIE1lbSsgQnVzTWFzdGVyKyBTcGVjQ3ljbGUtIE1lbVdJTlYrIFZHQVNub29w
LSBQYXJFcnItIFN0ZXBwaW5nLSBTRVJSKyBGYXN0QjJCLSBEaXNJTlR4LQ0KCVN0YXR1czog
Q2FwKyA2Nk1IeisgVURGLSBGYXN0QjJCKyBQYXJFcnItIERFVlNFTD1tZWRpdW0gPlRBYm9y
dC0gPFRBYm9ydC0gPE1BYm9ydC0gPlNFUlItIDxQRVJSLSBJTlR4LQ0KCUxhdGVuY3k6IDY0
LCBDYWNoZSBMaW5lIFNpemU6IDY0IGJ5dGVzDQoJSW50ZXJydXB0OiBwaW4gQiByb3V0ZWQg
dG8gSVJRIDE3DQoJUmVnaW9uIDA6IE1lbW9yeSBhdCBmOTNmZmMwMCAoMzItYml0LCBub24t
cHJlZmV0Y2hhYmxlKSBbc2l6ZT0yNTZdDQoJQ2FwYWJpbGl0aWVzOiBbYzBdIFBvd2VyIE1h
bmFnZW1lbnQgdmVyc2lvbiAyDQoJCUZsYWdzOiBQTUVDbGstIERTSS0gRDErIEQyKyBBdXhD
dXJyZW50PTBtQSBQTUUoRDArLEQxKyxEMissRDNob3QrLEQzY29sZC0pDQoJCVN0YXR1czog
RDAgTm9Tb2Z0UnN0LSBQTUUtRW5hYmxlLSBEU2VsPTAgRFNjYWxlPTAgUE1FLQ0KCQlCcmlk
Z2U6IFBNLSBCMysNCglDYXBhYmlsaXRpZXM6IFtlNF0gRGVidWcgcG9ydDogQkFSPTEgb2Zm
c2V0PTAwZTANCglLZXJuZWwgZHJpdmVyIGluIHVzZTogZWhjaV9oY2QNCg0KMDA6MTguMCBI
b3N0IGJyaWRnZSBbMDYwMF06IEFkdmFuY2VkIE1pY3JvIERldmljZXMgW0FNRF0gRmFtaWx5
IDEwaCBQcm9jZXNzb3IgSHlwZXJUcmFuc3BvcnQgQ29uZmlndXJhdGlvbiBbMTAyMjoxMjAw
XQ0KCUNvbnRyb2w6IEkvTy0gTWVtLSBCdXNNYXN0ZXItIFNwZWNDeWNsZS0gTWVtV0lOVi0g
VkdBU25vb3AtIFBhckVyci0gU3RlcHBpbmctIFNFUlItIEZhc3RCMkItIERpc0lOVHgtDQoJ
U3RhdHVzOiBDYXArIDY2TUh6LSBVREYtIEZhc3RCMkItIFBhckVyci0gREVWU0VMPWZhc3Qg
PlRBYm9ydC0gPFRBYm9ydC0gPE1BYm9ydC0gPlNFUlItIDxQRVJSLSBJTlR4LQ0KCUNhcGFi
aWxpdGllczogWzgwXSBIeXBlclRyYW5zcG9ydDogSG9zdCBvciBTZWNvbmRhcnkgSW50ZXJm
YWNlDQoJCUNvbW1hbmQ6IFdhcm1Sc3QrIERibEVuZC0gRGV2TnVtPTAgQ2hhaW5TaWRlLSBI
b3N0SGlkZSsgU2xhdmUtIDxFT0NFcnItIERVTC0NCgkJTGluayBDb250cm9sOiBDRmxFLSBD
U1QtIENGRS0gPExrRmFpbC0gSW5pdCsgRU9DLSBUWE8tIDxDUkNFcnI9MCBJc29jRW4tIExT
RW4rIEV4dENUTC0gNjRiLQ0KCQlMaW5rIENvbmZpZzogTUxXST0xNmJpdCBEd0ZjSW4tIE1M
V089MTZiaXQgRHdGY091dC0gTFdJPTE2Yml0IER3RmNJbkVuLSBMV089MTZiaXQgRHdGY091
dEVuLQ0KCQlSZXZpc2lvbiBJRDogMy4wMA0KCQlMaW5rIEZyZXF1ZW5jeTogW2JdDQoJCUxp
bmsgRXJyb3I6IDxQcm90LSA8T3ZmbC0gPEVPQy0gQ1RMVG0tDQoJCUxpbmsgRnJlcXVlbmN5
IENhcGFiaWxpdHk6IDIwME1IeisgMzAwTUh6LSA0MDBNSHorIDUwME1Iei0gNjAwTUh6KyA4
MDBNSHorIDEuMEdIeisgMS4yR0h6KyAxLjRHSHotIDEuNkdIei0gVmVuZC0NCgkJRmVhdHVy
ZSBDYXBhYmlsaXR5OiBJc29jRkMrIExEVFNUT1ArIENSQ1RNLSBFQ1RMVC0gNjRiQSsgVUlE
UkQtIEV4dFJTLSBVQ25mRS0NCg0KMDA6MTguMSBIb3N0IGJyaWRnZSBbMDYwMF06IEFkdmFu
Y2VkIE1pY3JvIERldmljZXMgW0FNRF0gRmFtaWx5IDEwaCBQcm9jZXNzb3IgQWRkcmVzcyBN
YXAgWzEwMjI6MTIwMV0NCglDb250cm9sOiBJL08tIE1lbS0gQnVzTWFzdGVyLSBTcGVjQ3lj
bGUtIE1lbVdJTlYtIFZHQVNub29wLSBQYXJFcnItIFN0ZXBwaW5nLSBTRVJSLSBGYXN0QjJC
LSBEaXNJTlR4LQ0KCVN0YXR1czogQ2FwLSA2Nk1Iei0gVURGLSBGYXN0QjJCLSBQYXJFcnIt
IERFVlNFTD1mYXN0ID5UQWJvcnQtIDxUQWJvcnQtIDxNQWJvcnQtID5TRVJSLSA8UEVSUi0g
SU5UeC0NCg0KMDA6MTguMiBIb3N0IGJyaWRnZSBbMDYwMF06IEFkdmFuY2VkIE1pY3JvIERl
dmljZXMgW0FNRF0gRmFtaWx5IDEwaCBQcm9jZXNzb3IgRFJBTSBDb250cm9sbGVyIFsxMDIy
OjEyMDJdDQoJQ29udHJvbDogSS9PLSBNZW0tIEJ1c01hc3Rlci0gU3BlY0N5Y2xlLSBNZW1X
SU5WLSBWR0FTbm9vcC0gUGFyRXJyLSBTdGVwcGluZy0gU0VSUi0gRmFzdEIyQi0gRGlzSU5U
eC0NCglTdGF0dXM6IENhcC0gNjZNSHotIFVERi0gRmFzdEIyQi0gUGFyRXJyLSBERVZTRUw9
ZmFzdCA+VEFib3J0LSA8VEFib3J0LSA8TUFib3J0LSA+U0VSUi0gPFBFUlItIElOVHgtDQoN
CjAwOjE4LjMgSG9zdCBicmlkZ2UgWzA2MDBdOiBBZHZhbmNlZCBNaWNybyBEZXZpY2VzIFtB
TURdIEZhbWlseSAxMGggUHJvY2Vzc29yIE1pc2NlbGxhbmVvdXMgQ29udHJvbCBbMTAyMjox
MjAzXQ0KCUNvbnRyb2w6IEkvTy0gTWVtLSBCdXNNYXN0ZXItIFNwZWNDeWNsZS0gTWVtV0lO
Vi0gVkdBU25vb3AtIFBhckVyci0gU3RlcHBpbmctIFNFUlItIEZhc3RCMkItIERpc0lOVHgt
DQoJU3RhdHVzOiBDYXArIDY2TUh6LSBVREYtIEZhc3RCMkItIFBhckVyci0gREVWU0VMPWZh
c3QgPlRBYm9ydC0gPFRBYm9ydC0gPE1BYm9ydC0gPlNFUlItIDxQRVJSLSBJTlR4LQ0KCUNh
cGFiaWxpdGllczogW2YwXSBTZWN1cmUgZGV2aWNlIDw/Pg0KCUtlcm5lbCBkcml2ZXIgaW4g
dXNlOiBrMTB0ZW1wDQoNCjAwOjE4LjQgSG9zdCBicmlkZ2UgWzA2MDBdOiBBZHZhbmNlZCBN
aWNybyBEZXZpY2VzIFtBTURdIEZhbWlseSAxMGggUHJvY2Vzc29yIExpbmsgQ29udHJvbCBb
MTAyMjoxMjA0XQ0KCUNvbnRyb2w6IEkvTy0gTWVtLSBCdXNNYXN0ZXItIFNwZWNDeWNsZS0g
TWVtV0lOVi0gVkdBU25vb3AtIFBhckVyci0gU3RlcHBpbmctIFNFUlItIEZhc3RCMkItIERp
c0lOVHgtDQoJU3RhdHVzOiBDYXAtIDY2TUh6LSBVREYtIEZhc3RCMkItIFBhckVyci0gREVW
U0VMPWZhc3QgPlRBYm9ydC0gPFRBYm9ydC0gPE1BYm9ydC0gPlNFUlItIDxQRVJSLSBJTlR4
LQ0KDQowMzowNi4wIE11bHRpbWVkaWEgYXVkaW8gY29udHJvbGxlciBbMDQwMV06IEMtTWVk
aWEgRWxlY3Ryb25pY3MgSW5jIENNODczOCBbMTNmNjowMTExXSAocmV2IDEwKQ0KCVN1YnN5
c3RlbTogQy1NZWRpYSBFbGVjdHJvbmljcyBJbmMgQ01JODczOC9DM0RYIFBDSSBBdWRpbyBE
ZXZpY2UgWzEzZjY6MDExMV0NCglDb250cm9sOiBJL08rIE1lbS0gQnVzTWFzdGVyKyBTcGVj
Q3ljbGUtIE1lbVdJTlYtIFZHQVNub29wLSBQYXJFcnItIFN0ZXBwaW5nLSBTRVJSLSBGYXN0
QjJCLSBEaXNJTlR4LQ0KCVN0YXR1czogQ2FwKyA2Nk1Iei0gVURGLSBGYXN0QjJCLSBQYXJF
cnItIERFVlNFTD1tZWRpdW0gPlRBYm9ydC0gPFRBYm9ydC0gPE1BYm9ydC0gPlNFUlItIDxQ
RVJSLSBJTlR4LQ0KCUxhdGVuY3k6IDY0ICg1MDBucyBtaW4sIDYwMDBucyBtYXgpDQoJSW50
ZXJydXB0OiBwaW4gQSByb3V0ZWQgdG8gSVJRIDIyDQoJUmVnaW9uIDA6IEkvTyBwb3J0cyBh
dCBhODAwIFtzaXplPTI1Nl0NCglDYXBhYmlsaXRpZXM6IFtjMF0gUG93ZXIgTWFuYWdlbWVu
dCB2ZXJzaW9uIDINCgkJRmxhZ3M6IFBNRUNsay0gRFNJLSBEMSsgRDIrIEF1eEN1cnJlbnQ9
MG1BIFBNRShEMC0sRDEtLEQyLSxEM2hvdC0sRDNjb2xkLSkNCgkJU3RhdHVzOiBEMCBOb1Nv
ZnRSc3QtIFBNRS1FbmFibGUtIERTZWw9MCBEU2NhbGU9MCBQTUUtDQoJS2VybmVsIGRyaXZl
ciBpbiB1c2U6IHBjaWJhY2sNCg0KMDQ6MDAuMCBVU0IgY29udHJvbGxlciBbMGMwM106IE5l
dE1vcyBUZWNobm9sb2d5IE1DUzk5OTAgUENJZSB0byA04oCQUG9ydCBVU0IgMi4wIEhvc3Qg
Q29udHJvbGxlciBbOTcxMDo5OTkwXSAocHJvZy1pZiAxMCBbT0hDSV0pDQoJU3Vic3lzdGVt
OiBEZXZpY2UgW2EwMDA6NDAwMF0NCglDb250cm9sOiBJL08tIE1lbS0gQnVzTWFzdGVyLSBT
cGVjQ3ljbGUtIE1lbVdJTlYtIFZHQVNub29wLSBQYXJFcnItIFN0ZXBwaW5nLSBTRVJSLSBG
YXN0QjJCLSBEaXNJTlR4LQ0KCVN0YXR1czogQ2FwKyA2Nk1Iei0gVURGLSBGYXN0QjJCLSBQ
YXJFcnItIERFVlNFTD1mYXN0ID5UQWJvcnQtIDxUQWJvcnQtIDxNQWJvcnQtID5TRVJSLSA8
UEVSUi0gSU5UeC0NCglJbnRlcnJ1cHQ6IHBpbiBBIHJvdXRlZCB0byBJUlEgNDANCglSZWdp
b24gMDogTWVtb3J5IGF0IGY5NWY4MDAwICgzMi1iaXQsIG5vbi1wcmVmZXRjaGFibGUpIFtk
aXNhYmxlZF0gW3NpemU9NEtdDQoJQ2FwYWJpbGl0aWVzOiBbNTBdIE1TSTogRW5hYmxlLSBD
b3VudD0xLzEgTWFza2FibGUtIDY0Yml0Kw0KCQlBZGRyZXNzOiAwMDAwMDAwMDAwMDAwMDAw
ICBEYXRhOiAwMDAwDQoJQ2FwYWJpbGl0aWVzOiBbNzhdIFBvd2VyIE1hbmFnZW1lbnQgdmVy
c2lvbiAzDQoJCUZsYWdzOiBQTUVDbGstIERTSS0gRDErIEQyKyBBdXhDdXJyZW50PTM3NW1B
IFBNRShEMCssRDErLEQyKyxEM2hvdCssRDNjb2xkLSkNCgkJU3RhdHVzOiBEMCBOb1NvZnRS
c3QrIFBNRS1FbmFibGUtIERTZWw9MCBEU2NhbGU9MCBQTUUtDQoJQ2FwYWJpbGl0aWVzOiBb
ODBdIEV4cHJlc3MgKHYxKSBFbmRwb2ludCwgTVNJIDAwDQoJCURldkNhcDoJTWF4UGF5bG9h
ZCAyNTYgYnl0ZXMsIFBoYW50RnVuYyAwLCBMYXRlbmN5IEwwcyB1bmxpbWl0ZWQsIEwxIHVu
bGltaXRlZA0KCQkJRXh0VGFnLSBBdHRuQnRuLSBBdHRuSW5kLSBQd3JJbmQtIFJCRSsgRkxS
ZXNldC0NCgkJRGV2Q3RsOglSZXBvcnQgZXJyb3JzOiBDb3JyZWN0YWJsZS0gTm9uLUZhdGFs
LSBGYXRhbC0gVW5zdXBwb3J0ZWQtDQoJCQlSbHhkT3JkLSBFeHRUYWctIFBoYW50RnVuYy0g
QXV4UHdyLSBOb1Nub29wKw0KCQkJTWF4UGF5bG9hZCAxMjggYnl0ZXMsIE1heFJlYWRSZXEg
NTEyIGJ5dGVzDQoJCURldlN0YToJQ29yckVyci0gVW5jb3JyRXJyLSBGYXRhbEVyci0gVW5z
dXBwUmVxLSBBdXhQd3ItIFRyYW5zUGVuZC0NCgkJTG5rQ2FwOglQb3J0ICMxLCBTcGVlZCAy
LjVHVC9zLCBXaWR0aCB4MSwgQVNQTSB1bmtub3duLCBMYXRlbmN5IEwwIDw2NG5zLCBMMSB1
bmxpbWl0ZWQNCgkJCUNsb2NrUE0rIFN1cnByaXNlLSBMTEFjdFJlcC0gQndOb3QtDQoJCUxu
a0N0bDoJQVNQTSBEaXNhYmxlZDsgUkNCIDY0IGJ5dGVzIERpc2FibGVkLSBSZXRyYWluLSBD
b21tQ2xrLQ0KCQkJRXh0U3luY2gtIENsb2NrUE0tIEF1dFdpZERpcy0gQldJbnQtIEF1dEJX
SW50LQ0KCQlMbmtTdGE6CVNwZWVkIDIuNUdUL3MsIFdpZHRoIHgxLCBUckVyci0gVHJhaW4t
IFNsb3RDbGstIERMQWN0aXZlLSBCV01nbXQtIEFCV01nbXQtDQoJQ2FwYWJpbGl0aWVzOiBb
MTAwIHYxXSBWaXJ0dWFsIENoYW5uZWwNCgkJQ2FwczoJTFBFVkM9MCBSZWZDbGs9MTAwbnMg
UEFURW50cnlCaXRzPTENCgkJQXJiOglGaXhlZC0gV1JSMzItIFdSUjY0LSBXUlIxMjgtDQoJ
CUN0cmw6CUFyYlNlbGVjdD1GaXhlZA0KCQlTdGF0dXM6CUluUHJvZ3Jlc3MtDQoJCVZDMDoJ
Q2FwczoJUEFUT2Zmc2V0PTAwIE1heFRpbWVTbG90cz0xIFJlalNub29wVHJhbnMtDQoJCQlB
cmI6CUZpeGVkLSBXUlIzMi0gV1JSNjQtIFdSUjEyOC0gVFdSUjEyOC0gV1JSMjU2LQ0KCQkJ
Q3RybDoJRW5hYmxlKyBJRD0wIEFyYlNlbGVjdD1GaXhlZCBUQy9WQz1mZg0KCQkJU3RhdHVz
OglOZWdvUGVuZGluZy0gSW5Qcm9ncmVzcy0NCglLZXJuZWwgZHJpdmVyIGluIHVzZTogcGNp
YmFjaw0KDQowNDowMC4xIFVTQiBjb250cm9sbGVyIFswYzAzXTogTmV0TW9zIFRlY2hub2xv
Z3kgTUNTOTk5MCBQQ0llIHRvIDTigJBQb3J0IFVTQiAyLjAgSG9zdCBDb250cm9sbGVyIFs5
NzEwOjk5OTBdIChwcm9nLWlmIDIwIFtFSENJXSkNCglTdWJzeXN0ZW06IERldmljZSBbYTAw
MDo0MDAwXQ0KCUNvbnRyb2w6IEkvTy0gTWVtLSBCdXNNYXN0ZXItIFNwZWNDeWNsZS0gTWVt
V0lOVi0gVkdBU25vb3AtIFBhckVyci0gU3RlcHBpbmctIFNFUlItIEZhc3RCMkItIERpc0lO
VHgtDQoJU3RhdHVzOiBDYXArIDY2TUh6LSBVREYtIEZhc3RCMkItIFBhckVyci0gREVWU0VM
PWZhc3QgPlRBYm9ydC0gPFRBYm9ydC0gPE1BYm9ydC0gPlNFUlItIDxQRVJSLSBJTlR4LQ0K
CUludGVycnVwdDogcGluIEEgcm91dGVkIHRvIElSUSA0MA0KCVJlZ2lvbiAwOiBNZW1vcnkg
YXQgZjk1ZjkwMDAgKDMyLWJpdCwgbm9uLXByZWZldGNoYWJsZSkgW2Rpc2FibGVkXSBbc2l6
ZT00S10NCglDYXBhYmlsaXRpZXM6IFs1MF0gTVNJOiBFbmFibGUtIENvdW50PTEvMSBNYXNr
YWJsZS0gNjRiaXQrDQoJCUFkZHJlc3M6IDAwMDAwMDAwMDAwMDAwMDAgIERhdGE6IDAwMDAN
CglDYXBhYmlsaXRpZXM6IFs3OF0gUG93ZXIgTWFuYWdlbWVudCB2ZXJzaW9uIDMNCgkJRmxh
Z3M6IFBNRUNsay0gRFNJLSBEMSsgRDIrIEF1eEN1cnJlbnQ9Mzc1bUEgUE1FKEQwKyxEMSss
RDIrLEQzaG90KyxEM2NvbGQtKQ0KCQlTdGF0dXM6IEQwIE5vU29mdFJzdCsgUE1FLUVuYWJs
ZS0gRFNlbD0wIERTY2FsZT0wIFBNRS0NCglDYXBhYmlsaXRpZXM6IFs4MF0gRXhwcmVzcyAo
djEpIEVuZHBvaW50LCBNU0kgMDANCgkJRGV2Q2FwOglNYXhQYXlsb2FkIDI1NiBieXRlcywg
UGhhbnRGdW5jIDAsIExhdGVuY3kgTDBzIHVubGltaXRlZCwgTDEgdW5saW1pdGVkDQoJCQlF
eHRUYWctIEF0dG5CdG4tIEF0dG5JbmQtIFB3ckluZC0gUkJFKyBGTFJlc2V0LQ0KCQlEZXZD
dGw6CVJlcG9ydCBlcnJvcnM6IENvcnJlY3RhYmxlLSBOb24tRmF0YWwtIEZhdGFsLSBVbnN1
cHBvcnRlZC0NCgkJCVJseGRPcmQtIEV4dFRhZy0gUGhhbnRGdW5jLSBBdXhQd3ItIE5vU25v
b3ArDQoJCQlNYXhQYXlsb2FkIDEyOCBieXRlcywgTWF4UmVhZFJlcSA1MTIgYnl0ZXMNCgkJ
RGV2U3RhOglDb3JyRXJyLSBVbmNvcnJFcnItIEZhdGFsRXJyLSBVbnN1cHBSZXEtIEF1eFB3
ci0gVHJhbnNQZW5kLQ0KCQlMbmtDYXA6CVBvcnQgIzEsIFNwZWVkIDIuNUdUL3MsIFdpZHRo
IHgxLCBBU1BNIHVua25vd24sIExhdGVuY3kgTDAgPDY0bnMsIEwxIHVubGltaXRlZA0KCQkJ
Q2xvY2tQTSsgU3VycHJpc2UtIExMQWN0UmVwLSBCd05vdC0NCgkJTG5rQ3RsOglBU1BNIERp
c2FibGVkOyBSQ0IgNjQgYnl0ZXMgRGlzYWJsZWQtIFJldHJhaW4tIENvbW1DbGstDQoJCQlF
eHRTeW5jaC0gQ2xvY2tQTS0gQXV0V2lkRGlzLSBCV0ludC0gQXV0QldJbnQtDQoJCUxua1N0
YToJU3BlZWQgMi41R1QvcywgV2lkdGggeDEsIFRyRXJyLSBUcmFpbi0gU2xvdENsay0gRExB
Y3RpdmUtIEJXTWdtdC0gQUJXTWdtdC0NCglLZXJuZWwgZHJpdmVyIGluIHVzZTogcGNpYmFj
aw0KDQowNDowMC4yIFVTQiBjb250cm9sbGVyIFswYzAzXTogTmV0TW9zIFRlY2hub2xvZ3kg
TUNTOTk5MCBQQ0llIHRvIDTigJBQb3J0IFVTQiAyLjAgSG9zdCBDb250cm9sbGVyIFs5NzEw
Ojk5OTBdIChwcm9nLWlmIDEwIFtPSENJXSkNCglTdWJzeXN0ZW06IERldmljZSBbYTAwMDo0
MDAwXQ0KCUNvbnRyb2w6IEkvTy0gTWVtLSBCdXNNYXN0ZXItIFNwZWNDeWNsZS0gTWVtV0lO
Vi0gVkdBU25vb3AtIFBhckVyci0gU3RlcHBpbmctIFNFUlItIEZhc3RCMkItIERpc0lOVHgt
DQoJU3RhdHVzOiBDYXArIDY2TUh6LSBVREYtIEZhc3RCMkItIFBhckVyci0gREVWU0VMPWZh
c3QgPlRBYm9ydC0gPFRBYm9ydC0gPE1BYm9ydC0gPlNFUlItIDxQRVJSLSBJTlR4LQ0KCUlu
dGVycnVwdDogcGluIEIgcm91dGVkIHRvIElSUSA0MQ0KCVJlZ2lvbiAwOiBNZW1vcnkgYXQg
Zjk1ZmEwMDAgKDMyLWJpdCwgbm9uLXByZWZldGNoYWJsZSkgW2Rpc2FibGVkXSBbc2l6ZT00
S10NCglDYXBhYmlsaXRpZXM6IFs1MF0gTVNJOiBFbmFibGUtIENvdW50PTEvMSBNYXNrYWJs
ZS0gNjRiaXQrDQoJCUFkZHJlc3M6IDAwMDAwMDAwMDAwMDAwMDAgIERhdGE6IDAwMDANCglD
YXBhYmlsaXRpZXM6IFs3OF0gUG93ZXIgTWFuYWdlbWVudCB2ZXJzaW9uIDMNCgkJRmxhZ3M6
IFBNRUNsay0gRFNJLSBEMSsgRDIrIEF1eEN1cnJlbnQ9Mzc1bUEgUE1FKEQwKyxEMSssRDIr
LEQzaG90KyxEM2NvbGQtKQ0KCQlTdGF0dXM6IEQwIE5vU29mdFJzdCsgUE1FLUVuYWJsZS0g
RFNlbD0wIERTY2FsZT0wIFBNRS0NCglDYXBhYmlsaXRpZXM6IFs4MF0gRXhwcmVzcyAodjEp
IEVuZHBvaW50LCBNU0kgMDANCgkJRGV2Q2FwOglNYXhQYXlsb2FkIDI1NiBieXRlcywgUGhh
bnRGdW5jIDAsIExhdGVuY3kgTDBzIHVubGltaXRlZCwgTDEgdW5saW1pdGVkDQoJCQlFeHRU
YWctIEF0dG5CdG4tIEF0dG5JbmQtIFB3ckluZC0gUkJFKyBGTFJlc2V0LQ0KCQlEZXZDdGw6
CVJlcG9ydCBlcnJvcnM6IENvcnJlY3RhYmxlLSBOb24tRmF0YWwtIEZhdGFsLSBVbnN1cHBv
cnRlZC0NCgkJCVJseGRPcmQtIEV4dFRhZy0gUGhhbnRGdW5jLSBBdXhQd3ItIE5vU25vb3Ar
DQoJCQlNYXhQYXlsb2FkIDEyOCBieXRlcywgTWF4UmVhZFJlcSA1MTIgYnl0ZXMNCgkJRGV2
U3RhOglDb3JyRXJyLSBVbmNvcnJFcnItIEZhdGFsRXJyLSBVbnN1cHBSZXEtIEF1eFB3ci0g
VHJhbnNQZW5kLQ0KCQlMbmtDYXA6CVBvcnQgIzEsIFNwZWVkIDIuNUdUL3MsIFdpZHRoIHgx
LCBBU1BNIHVua25vd24sIExhdGVuY3kgTDAgPDY0bnMsIEwxIHVubGltaXRlZA0KCQkJQ2xv
Y2tQTSsgU3VycHJpc2UtIExMQWN0UmVwLSBCd05vdC0NCgkJTG5rQ3RsOglBU1BNIERpc2Fi
bGVkOyBSQ0IgNjQgYnl0ZXMgRGlzYWJsZWQtIFJldHJhaW4tIENvbW1DbGstDQoJCQlFeHRT
eW5jaC0gQ2xvY2tQTS0gQXV0V2lkRGlzLSBCV0ludC0gQXV0QldJbnQtDQoJCUxua1N0YToJ
U3BlZWQgMi41R1QvcywgV2lkdGggeDEsIFRyRXJyLSBUcmFpbi0gU2xvdENsay0gRExBY3Rp
dmUtIEJXTWdtdC0gQUJXTWdtdC0NCglLZXJuZWwgZHJpdmVyIGluIHVzZTogcGNpYmFjaw0K
DQowNDowMC4zIFVTQiBjb250cm9sbGVyIFswYzAzXTogTmV0TW9zIFRlY2hub2xvZ3kgTUNT
OTk5MCBQQ0llIHRvIDTigJBQb3J0IFVTQiAyLjAgSG9zdCBDb250cm9sbGVyIFs5NzEwOjk5
OTBdIChwcm9nLWlmIDIwIFtFSENJXSkNCglTdWJzeXN0ZW06IERldmljZSBbYTAwMDo0MDAw
XQ0KCUNvbnRyb2w6IEkvTy0gTWVtLSBCdXNNYXN0ZXItIFNwZWNDeWNsZS0gTWVtV0lOVi0g
VkdBU25vb3AtIFBhckVyci0gU3RlcHBpbmctIFNFUlItIEZhc3RCMkItIERpc0lOVHgtDQoJ
U3RhdHVzOiBDYXArIDY2TUh6LSBVREYtIEZhc3RCMkItIFBhckVyci0gREVWU0VMPWZhc3Qg
PlRBYm9ydC0gPFRBYm9ydC0gPE1BYm9ydC0gPlNFUlItIDxQRVJSLSBJTlR4LQ0KCUludGVy
cnVwdDogcGluIEIgcm91dGVkIHRvIElSUSA0MQ0KCVJlZ2lvbiAwOiBNZW1vcnkgYXQgZjk1
ZmIwMDAgKDMyLWJpdCwgbm9uLXByZWZldGNoYWJsZSkgW2Rpc2FibGVkXSBbc2l6ZT00S10N
CglDYXBhYmlsaXRpZXM6IFs1MF0gTVNJOiBFbmFibGUtIENvdW50PTEvMSBNYXNrYWJsZS0g
NjRiaXQrDQoJCUFkZHJlc3M6IDAwMDAwMDAwMDAwMDAwMDAgIERhdGE6IDAwMDANCglDYXBh
YmlsaXRpZXM6IFs3OF0gUG93ZXIgTWFuYWdlbWVudCB2ZXJzaW9uIDMNCgkJRmxhZ3M6IFBN
RUNsay0gRFNJLSBEMSsgRDIrIEF1eEN1cnJlbnQ9Mzc1bUEgUE1FKEQwKyxEMSssRDIrLEQz
aG90KyxEM2NvbGQtKQ0KCQlTdGF0dXM6IEQwIE5vU29mdFJzdCsgUE1FLUVuYWJsZS0gRFNl
bD0wIERTY2FsZT0wIFBNRS0NCglDYXBhYmlsaXRpZXM6IFs4MF0gRXhwcmVzcyAodjEpIEVu
ZHBvaW50LCBNU0kgMDANCgkJRGV2Q2FwOglNYXhQYXlsb2FkIDI1NiBieXRlcywgUGhhbnRG
dW5jIDAsIExhdGVuY3kgTDBzIHVubGltaXRlZCwgTDEgdW5saW1pdGVkDQoJCQlFeHRUYWct
IEF0dG5CdG4tIEF0dG5JbmQtIFB3ckluZC0gUkJFKyBGTFJlc2V0LQ0KCQlEZXZDdGw6CVJl
cG9ydCBlcnJvcnM6IENvcnJlY3RhYmxlLSBOb24tRmF0YWwtIEZhdGFsLSBVbnN1cHBvcnRl
ZC0NCgkJCVJseGRPcmQtIEV4dFRhZy0gUGhhbnRGdW5jLSBBdXhQd3ItIE5vU25vb3ArDQoJ
CQlNYXhQYXlsb2FkIDEyOCBieXRlcywgTWF4UmVhZFJlcSA1MTIgYnl0ZXMNCgkJRGV2U3Rh
OglDb3JyRXJyLSBVbmNvcnJFcnItIEZhdGFsRXJyLSBVbnN1cHBSZXEtIEF1eFB3ci0gVHJh
bnNQZW5kLQ0KCQlMbmtDYXA6CVBvcnQgIzEsIFNwZWVkIDIuNUdUL3MsIFdpZHRoIHgxLCBB
U1BNIHVua25vd24sIExhdGVuY3kgTDAgPDY0bnMsIEwxIHVubGltaXRlZA0KCQkJQ2xvY2tQ
TSsgU3VycHJpc2UtIExMQWN0UmVwLSBCd05vdC0NCgkJTG5rQ3RsOglBU1BNIERpc2FibGVk
OyBSQ0IgNjQgYnl0ZXMgRGlzYWJsZWQtIFJldHJhaW4tIENvbW1DbGstDQoJCQlFeHRTeW5j
aC0gQ2xvY2tQTS0gQXV0V2lkRGlzLSBCV0ludC0gQXV0QldJbnQtDQoJCUxua1N0YToJU3Bl
ZWQgMi41R1QvcywgV2lkdGggeDEsIFRyRXJyLSBUcmFpbi0gU2xvdENsay0gRExBY3RpdmUt
IEJXTWdtdC0gQUJXTWdtdC0NCglLZXJuZWwgZHJpdmVyIGluIHVzZTogcGNpYmFjaw0KDQow
NDowMC40IFVTQiBjb250cm9sbGVyIFswYzAzXTogTmV0TW9zIFRlY2hub2xvZ3kgTUNTOTk5
MCBQQ0llIHRvIDTigJBQb3J0IFVTQiAyLjAgSG9zdCBDb250cm9sbGVyIFs5NzEwOjk5OTBd
IChwcm9nLWlmIDEwIFtPSENJXSkNCglTdWJzeXN0ZW06IERldmljZSBbYTAwMDo0MDAwXQ0K
CUNvbnRyb2w6IEkvTy0gTWVtLSBCdXNNYXN0ZXItIFNwZWNDeWNsZS0gTWVtV0lOVi0gVkdB
U25vb3AtIFBhckVyci0gU3RlcHBpbmctIFNFUlItIEZhc3RCMkItIERpc0lOVHgtDQoJU3Rh
dHVzOiBDYXArIDY2TUh6LSBVREYtIEZhc3RCMkItIFBhckVyci0gREVWU0VMPWZhc3QgPlRB
Ym9ydC0gPFRBYm9ydC0gPE1BYm9ydC0gPlNFUlItIDxQRVJSLSBJTlR4LQ0KCUludGVycnVw
dDogcGluIEMgcm91dGVkIHRvIElSUSA0Mg0KCVJlZ2lvbiAwOiBNZW1vcnkgYXQgZjk1ZmMw
MDAgKDMyLWJpdCwgbm9uLXByZWZldGNoYWJsZSkgW2Rpc2FibGVkXSBbc2l6ZT00S10NCglD
YXBhYmlsaXRpZXM6IFs1MF0gTVNJOiBFbmFibGUtIENvdW50PTEvMSBNYXNrYWJsZS0gNjRi
aXQrDQoJCUFkZHJlc3M6IDAwMDAwMDAwMDAwMDAwMDAgIERhdGE6IDAwMDANCglDYXBhYmls
aXRpZXM6IFs3OF0gUG93ZXIgTWFuYWdlbWVudCB2ZXJzaW9uIDMNCgkJRmxhZ3M6IFBNRUNs
ay0gRFNJLSBEMSsgRDIrIEF1eEN1cnJlbnQ9Mzc1bUEgUE1FKEQwKyxEMSssRDIrLEQzaG90
KyxEM2NvbGQtKQ0KCQlTdGF0dXM6IEQwIE5vU29mdFJzdCsgUE1FLUVuYWJsZS0gRFNlbD0w
IERTY2FsZT0wIFBNRS0NCglDYXBhYmlsaXRpZXM6IFs4MF0gRXhwcmVzcyAodjEpIEVuZHBv
aW50LCBNU0kgMDANCgkJRGV2Q2FwOglNYXhQYXlsb2FkIDI1NiBieXRlcywgUGhhbnRGdW5j
IDAsIExhdGVuY3kgTDBzIHVubGltaXRlZCwgTDEgdW5saW1pdGVkDQoJCQlFeHRUYWctIEF0
dG5CdG4tIEF0dG5JbmQtIFB3ckluZC0gUkJFKyBGTFJlc2V0LQ0KCQlEZXZDdGw6CVJlcG9y
dCBlcnJvcnM6IENvcnJlY3RhYmxlLSBOb24tRmF0YWwtIEZhdGFsLSBVbnN1cHBvcnRlZC0N
CgkJCVJseGRPcmQtIEV4dFRhZy0gUGhhbnRGdW5jLSBBdXhQd3ItIE5vU25vb3ArDQoJCQlN
YXhQYXlsb2FkIDEyOCBieXRlcywgTWF4UmVhZFJlcSA1MTIgYnl0ZXMNCgkJRGV2U3RhOglD
b3JyRXJyLSBVbmNvcnJFcnItIEZhdGFsRXJyLSBVbnN1cHBSZXEtIEF1eFB3ci0gVHJhbnNQ
ZW5kLQ0KCQlMbmtDYXA6CVBvcnQgIzEsIFNwZWVkIDIuNUdUL3MsIFdpZHRoIHgxLCBBU1BN
IHVua25vd24sIExhdGVuY3kgTDAgPDY0bnMsIEwxIHVubGltaXRlZA0KCQkJQ2xvY2tQTSsg
U3VycHJpc2UtIExMQWN0UmVwLSBCd05vdC0NCgkJTG5rQ3RsOglBU1BNIERpc2FibGVkOyBS
Q0IgNjQgYnl0ZXMgRGlzYWJsZWQtIFJldHJhaW4tIENvbW1DbGstDQoJCQlFeHRTeW5jaC0g
Q2xvY2tQTS0gQXV0V2lkRGlzLSBCV0ludC0gQXV0QldJbnQtDQoJCUxua1N0YToJU3BlZWQg
Mi41R1QvcywgV2lkdGggeDEsIFRyRXJyLSBUcmFpbi0gU2xvdENsay0gRExBY3RpdmUtIEJX
TWdtdC0gQUJXTWdtdC0NCglLZXJuZWwgZHJpdmVyIGluIHVzZTogcGNpYmFjaw0KDQowNDow
MC41IFVTQiBjb250cm9sbGVyIFswYzAzXTogTmV0TW9zIFRlY2hub2xvZ3kgTUNTOTk5MCBQ
Q0llIHRvIDTigJBQb3J0IFVTQiAyLjAgSG9zdCBDb250cm9sbGVyIFs5NzEwOjk5OTBdIChw
cm9nLWlmIDIwIFtFSENJXSkNCglTdWJzeXN0ZW06IERldmljZSBbYTAwMDo0MDAwXQ0KCUNv
bnRyb2w6IEkvTy0gTWVtLSBCdXNNYXN0ZXItIFNwZWNDeWNsZS0gTWVtV0lOVi0gVkdBU25v
b3AtIFBhckVyci0gU3RlcHBpbmctIFNFUlItIEZhc3RCMkItIERpc0lOVHgtDQoJU3RhdHVz
OiBDYXArIDY2TUh6LSBVREYtIEZhc3RCMkItIFBhckVyci0gREVWU0VMPWZhc3QgPlRBYm9y
dC0gPFRBYm9ydC0gPE1BYm9ydC0gPlNFUlItIDxQRVJSLSBJTlR4LQ0KCUludGVycnVwdDog
cGluIEMgcm91dGVkIHRvIElSUSA0Mg0KCVJlZ2lvbiAwOiBNZW1vcnkgYXQgZjk1ZmQwMDAg
KDMyLWJpdCwgbm9uLXByZWZldGNoYWJsZSkgW2Rpc2FibGVkXSBbc2l6ZT00S10NCglDYXBh
YmlsaXRpZXM6IFs1MF0gTVNJOiBFbmFibGUtIENvdW50PTEvMSBNYXNrYWJsZS0gNjRiaXQr
DQoJCUFkZHJlc3M6IDAwMDAwMDAwMDAwMDAwMDAgIERhdGE6IDAwMDANCglDYXBhYmlsaXRp
ZXM6IFs3OF0gUG93ZXIgTWFuYWdlbWVudCB2ZXJzaW9uIDMNCgkJRmxhZ3M6IFBNRUNsay0g
RFNJLSBEMSsgRDIrIEF1eEN1cnJlbnQ9Mzc1bUEgUE1FKEQwKyxEMSssRDIrLEQzaG90KyxE
M2NvbGQtKQ0KCQlTdGF0dXM6IEQwIE5vU29mdFJzdCsgUE1FLUVuYWJsZS0gRFNlbD0wIERT
Y2FsZT0wIFBNRS0NCglDYXBhYmlsaXRpZXM6IFs4MF0gRXhwcmVzcyAodjEpIEVuZHBvaW50
LCBNU0kgMDANCgkJRGV2Q2FwOglNYXhQYXlsb2FkIDI1NiBieXRlcywgUGhhbnRGdW5jIDAs
IExhdGVuY3kgTDBzIHVubGltaXRlZCwgTDEgdW5saW1pdGVkDQoJCQlFeHRUYWctIEF0dG5C
dG4tIEF0dG5JbmQtIFB3ckluZC0gUkJFKyBGTFJlc2V0LQ0KCQlEZXZDdGw6CVJlcG9ydCBl
cnJvcnM6IENvcnJlY3RhYmxlLSBOb24tRmF0YWwtIEZhdGFsLSBVbnN1cHBvcnRlZC0NCgkJ
CVJseGRPcmQtIEV4dFRhZy0gUGhhbnRGdW5jLSBBdXhQd3ItIE5vU25vb3ArDQoJCQlNYXhQ
YXlsb2FkIDEyOCBieXRlcywgTWF4UmVhZFJlcSA1MTIgYnl0ZXMNCgkJRGV2U3RhOglDb3Jy
RXJyLSBVbmNvcnJFcnItIEZhdGFsRXJyLSBVbnN1cHBSZXEtIEF1eFB3ci0gVHJhbnNQZW5k
LQ0KCQlMbmtDYXA6CVBvcnQgIzEsIFNwZWVkIDIuNUdUL3MsIFdpZHRoIHgxLCBBU1BNIHVu
a25vd24sIExhdGVuY3kgTDAgPDY0bnMsIEwxIHVubGltaXRlZA0KCQkJQ2xvY2tQTSsgU3Vy
cHJpc2UtIExMQWN0UmVwLSBCd05vdC0NCgkJTG5rQ3RsOglBU1BNIERpc2FibGVkOyBSQ0Ig
NjQgYnl0ZXMgRGlzYWJsZWQtIFJldHJhaW4tIENvbW1DbGstDQoJCQlFeHRTeW5jaC0gQ2xv
Y2tQTS0gQXV0V2lkRGlzLSBCV0ludC0gQXV0QldJbnQtDQoJCUxua1N0YToJU3BlZWQgMi41
R1QvcywgV2lkdGggeDEsIFRyRXJyLSBUcmFpbi0gU2xvdENsay0gRExBY3RpdmUtIEJXTWdt
dC0gQUJXTWdtdC0NCglLZXJuZWwgZHJpdmVyIGluIHVzZTogcGNpYmFjaw0KDQowNDowMC42
IFVTQiBjb250cm9sbGVyIFswYzAzXTogTmV0TW9zIFRlY2hub2xvZ3kgTUNTOTk5MCBQQ0ll
IHRvIDTigJBQb3J0IFVTQiAyLjAgSG9zdCBDb250cm9sbGVyIFs5NzEwOjk5OTBdIChwcm9n
LWlmIDEwIFtPSENJXSkNCglTdWJzeXN0ZW06IERldmljZSBbYTAwMDo0MDAwXQ0KCUNvbnRy
b2w6IEkvTy0gTWVtLSBCdXNNYXN0ZXItIFNwZWNDeWNsZS0gTWVtV0lOVi0gVkdBU25vb3At
IFBhckVyci0gU3RlcHBpbmctIFNFUlItIEZhc3RCMkItIERpc0lOVHgtDQoJU3RhdHVzOiBD
YXArIDY2TUh6LSBVREYtIEZhc3RCMkItIFBhckVyci0gREVWU0VMPWZhc3QgPlRBYm9ydC0g
PFRBYm9ydC0gPE1BYm9ydC0gPlNFUlItIDxQRVJSLSBJTlR4LQ0KCUludGVycnVwdDogcGlu
IEQgcm91dGVkIHRvIElSUSA0Mw0KCVJlZ2lvbiAwOiBNZW1vcnkgYXQgZjk1ZmUwMDAgKDMy
LWJpdCwgbm9uLXByZWZldGNoYWJsZSkgW2Rpc2FibGVkXSBbc2l6ZT00S10NCglDYXBhYmls
aXRpZXM6IFs1MF0gTVNJOiBFbmFibGUtIENvdW50PTEvMSBNYXNrYWJsZS0gNjRiaXQrDQoJ
CUFkZHJlc3M6IDAwMDAwMDAwMDAwMDAwMDAgIERhdGE6IDAwMDANCglDYXBhYmlsaXRpZXM6
IFs3OF0gUG93ZXIgTWFuYWdlbWVudCB2ZXJzaW9uIDMNCgkJRmxhZ3M6IFBNRUNsay0gRFNJ
LSBEMSsgRDIrIEF1eEN1cnJlbnQ9Mzc1bUEgUE1FKEQwKyxEMSssRDIrLEQzaG90KyxEM2Nv
bGQtKQ0KCQlTdGF0dXM6IEQwIE5vU29mdFJzdCsgUE1FLUVuYWJsZS0gRFNlbD0wIERTY2Fs
ZT0wIFBNRS0NCglDYXBhYmlsaXRpZXM6IFs4MF0gRXhwcmVzcyAodjEpIEVuZHBvaW50LCBN
U0kgMDANCgkJRGV2Q2FwOglNYXhQYXlsb2FkIDI1NiBieXRlcywgUGhhbnRGdW5jIDAsIExh
dGVuY3kgTDBzIHVubGltaXRlZCwgTDEgdW5saW1pdGVkDQoJCQlFeHRUYWctIEF0dG5CdG4t
IEF0dG5JbmQtIFB3ckluZC0gUkJFKyBGTFJlc2V0LQ0KCQlEZXZDdGw6CVJlcG9ydCBlcnJv
cnM6IENvcnJlY3RhYmxlLSBOb24tRmF0YWwtIEZhdGFsLSBVbnN1cHBvcnRlZC0NCgkJCVJs
eGRPcmQtIEV4dFRhZy0gUGhhbnRGdW5jLSBBdXhQd3ItIE5vU25vb3ArDQoJCQlNYXhQYXls
b2FkIDEyOCBieXRlcywgTWF4UmVhZFJlcSA1MTIgYnl0ZXMNCgkJRGV2U3RhOglDb3JyRXJy
LSBVbmNvcnJFcnItIEZhdGFsRXJyLSBVbnN1cHBSZXEtIEF1eFB3ci0gVHJhbnNQZW5kLQ0K
CQlMbmtDYXA6CVBvcnQgIzEsIFNwZWVkIDIuNUdUL3MsIFdpZHRoIHgxLCBBU1BNIHVua25v
d24sIExhdGVuY3kgTDAgPDY0bnMsIEwxIHVubGltaXRlZA0KCQkJQ2xvY2tQTSsgU3VycHJp
c2UtIExMQWN0UmVwLSBCd05vdC0NCgkJTG5rQ3RsOglBU1BNIERpc2FibGVkOyBSQ0IgNjQg
Ynl0ZXMgRGlzYWJsZWQtIFJldHJhaW4tIENvbW1DbGstDQoJCQlFeHRTeW5jaC0gQ2xvY2tQ
TS0gQXV0V2lkRGlzLSBCV0ludC0gQXV0QldJbnQtDQoJCUxua1N0YToJU3BlZWQgMi41R1Qv
cywgV2lkdGggeDEsIFRyRXJyLSBUcmFpbi0gU2xvdENsay0gRExBY3RpdmUtIEJXTWdtdC0g
QUJXTWdtdC0NCglLZXJuZWwgZHJpdmVyIGluIHVzZTogcGNpYmFjaw0KDQowNDowMC43IFVT
QiBjb250cm9sbGVyIFswYzAzXTogTmV0TW9zIFRlY2hub2xvZ3kgTUNTOTk5MCBQQ0llIHRv
IDTigJBQb3J0IFVTQiAyLjAgSG9zdCBDb250cm9sbGVyIFs5NzEwOjk5OTBdIChwcm9nLWlm
IDIwIFtFSENJXSkNCglTdWJzeXN0ZW06IERldmljZSBbYTAwMDo0MDAwXQ0KCUNvbnRyb2w6
IEkvTy0gTWVtLSBCdXNNYXN0ZXItIFNwZWNDeWNsZS0gTWVtV0lOVi0gVkdBU25vb3AtIFBh
ckVyci0gU3RlcHBpbmctIFNFUlItIEZhc3RCMkItIERpc0lOVHgtDQoJU3RhdHVzOiBDYXAr
IDY2TUh6LSBVREYtIEZhc3RCMkItIFBhckVyci0gREVWU0VMPWZhc3QgPlRBYm9ydC0gPFRB
Ym9ydC0gPE1BYm9ydC0gPlNFUlItIDxQRVJSLSBJTlR4LQ0KCUludGVycnVwdDogcGluIEQg
cm91dGVkIHRvIElSUSA0Mw0KCVJlZ2lvbiAwOiBNZW1vcnkgYXQgZjk1ZmYwMDAgKDMyLWJp
dCwgbm9uLXByZWZldGNoYWJsZSkgW2Rpc2FibGVkXSBbc2l6ZT00S10NCglDYXBhYmlsaXRp
ZXM6IFs1MF0gTVNJOiBFbmFibGUtIENvdW50PTEvMSBNYXNrYWJsZS0gNjRiaXQrDQoJCUFk
ZHJlc3M6IDAwMDAwMDAwMDAwMDAwMDAgIERhdGE6IDAwMDANCglDYXBhYmlsaXRpZXM6IFs3
OF0gUG93ZXIgTWFuYWdlbWVudCB2ZXJzaW9uIDMNCgkJRmxhZ3M6IFBNRUNsay0gRFNJLSBE
MSsgRDIrIEF1eEN1cnJlbnQ9Mzc1bUEgUE1FKEQwKyxEMSssRDIrLEQzaG90KyxEM2NvbGQt
KQ0KCQlTdGF0dXM6IEQwIE5vU29mdFJzdCsgUE1FLUVuYWJsZS0gRFNlbD0wIERTY2FsZT0w
IFBNRS0NCglDYXBhYmlsaXRpZXM6IFs4MF0gRXhwcmVzcyAodjEpIEVuZHBvaW50LCBNU0kg
MDANCgkJRGV2Q2FwOglNYXhQYXlsb2FkIDI1NiBieXRlcywgUGhhbnRGdW5jIDAsIExhdGVu
Y3kgTDBzIHVubGltaXRlZCwgTDEgdW5saW1pdGVkDQoJCQlFeHRUYWctIEF0dG5CdG4tIEF0
dG5JbmQtIFB3ckluZC0gUkJFKyBGTFJlc2V0LQ0KCQlEZXZDdGw6CVJlcG9ydCBlcnJvcnM6
IENvcnJlY3RhYmxlLSBOb24tRmF0YWwtIEZhdGFsLSBVbnN1cHBvcnRlZC0NCgkJCVJseGRP
cmQtIEV4dFRhZy0gUGhhbnRGdW5jLSBBdXhQd3ItIE5vU25vb3ArDQoJCQlNYXhQYXlsb2Fk
IDEyOCBieXRlcywgTWF4UmVhZFJlcSA1MTIgYnl0ZXMNCgkJRGV2U3RhOglDb3JyRXJyLSBV
bmNvcnJFcnItIEZhdGFsRXJyLSBVbnN1cHBSZXEtIEF1eFB3ci0gVHJhbnNQZW5kLQ0KCQlM
bmtDYXA6CVBvcnQgIzEsIFNwZWVkIDIuNUdUL3MsIFdpZHRoIHgxLCBBU1BNIHVua25vd24s
IExhdGVuY3kgTDAgPDY0bnMsIEwxIHVubGltaXRlZA0KCQkJQ2xvY2tQTSsgU3VycHJpc2Ut
IExMQWN0UmVwLSBCd05vdC0NCgkJTG5rQ3RsOglBU1BNIERpc2FibGVkOyBSQ0IgNjQgYnl0
ZXMgRGlzYWJsZWQtIFJldHJhaW4tIENvbW1DbGstDQoJCQlFeHRTeW5jaC0gQ2xvY2tQTS0g
QXV0V2lkRGlzLSBCV0ludC0gQXV0QldJbnQtDQoJCUxua1N0YToJU3BlZWQgMi41R1Qvcywg
V2lkdGggeDEsIFRyRXJyLSBUcmFpbi0gU2xvdENsay0gRExBY3RpdmUtIEJXTWdtdC0gQUJX
TWdtdC0NCglLZXJuZWwgZHJpdmVyIGluIHVzZTogcGNpYmFjaw0KDQowNTowMC4wIE11bHRp
bWVkaWEgdmlkZW8gY29udHJvbGxlciBbMDQwMF06IENvbmV4YW50IFN5c3RlbXMsIEluYy4g
Q1gyNTg1MCBbMTRmMTo4MjAwXQ0KCUNvbnRyb2w6IEkvTy0gTWVtLSBCdXNNYXN0ZXItIFNw
ZWNDeWNsZS0gTWVtV0lOVi0gVkdBU25vb3AtIFBhckVyci0gU3RlcHBpbmctIFNFUlItIEZh
c3RCMkItIERpc0lOVHgtDQoJU3RhdHVzOiBDYXArIDY2TUh6LSBVREYtIEZhc3RCMkItIFBh
ckVyci0gREVWU0VMPWZhc3QgPlRBYm9ydC0gPFRBYm9ydC0gPE1BYm9ydC0gPlNFUlItIDxQ
RVJSLSBJTlR4LQ0KCUludGVycnVwdDogcGluIEEgcm91dGVkIHRvIElSUSAzNg0KCVJlZ2lv
biAwOiBNZW1vcnkgYXQgZjk2MDAwMDAgKDY0LWJpdCwgbm9uLXByZWZldGNoYWJsZSkgW2Rp
c2FibGVkXSBbc2l6ZT0yTV0NCglDYXBhYmlsaXRpZXM6IFs0MF0gRXhwcmVzcyAodjEpIEVu
ZHBvaW50LCBNU0kgMDANCgkJRGV2Q2FwOglNYXhQYXlsb2FkIDEyOCBieXRlcywgUGhhbnRG
dW5jIDAsIExhdGVuY3kgTDBzIDw2NG5zLCBMMSA8MXVzDQoJCQlFeHRUYWctIEF0dG5CdG4t
IEF0dG5JbmQtIFB3ckluZC0gUkJFKyBGTFJlc2V0LQ0KCQlEZXZDdGw6CVJlcG9ydCBlcnJv
cnM6IENvcnJlY3RhYmxlLSBOb24tRmF0YWwtIEZhdGFsLSBVbnN1cHBvcnRlZC0NCgkJCVJs
eGRPcmQrIEV4dFRhZy0gUGhhbnRGdW5jLSBBdXhQd3ItIE5vU25vb3ArDQoJCQlNYXhQYXls
b2FkIDEyOCBieXRlcywgTWF4UmVhZFJlcSA1MTIgYnl0ZXMNCgkJRGV2U3RhOglDb3JyRXJy
LSBVbmNvcnJFcnItIEZhdGFsRXJyLSBVbnN1cHBSZXEtIEF1eFB3ci0gVHJhbnNQZW5kLQ0K
CQlMbmtDYXA6CVBvcnQgIzAsIFNwZWVkIDIuNUdUL3MsIFdpZHRoIHgxLCBBU1BNIEwwcyBM
MSwgTGF0ZW5jeSBMMCA8MnVzLCBMMSA8NHVzDQoJCQlDbG9ja1BNLSBTdXJwcmlzZS0gTExB
Y3RSZXAtIEJ3Tm90LQ0KCQlMbmtDdGw6CUFTUE0gRGlzYWJsZWQ7IFJDQiA2NCBieXRlcyBE
aXNhYmxlZC0gUmV0cmFpbi0gQ29tbUNsay0NCgkJCUV4dFN5bmNoLSBDbG9ja1BNLSBBdXRX
aWREaXMtIEJXSW50LSBBdXRCV0ludC0NCgkJTG5rU3RhOglTcGVlZCAyLjVHVC9zLCBXaWR0
aCB4MSwgVHJFcnItIFRyYWluLSBTbG90Q2xrLSBETEFjdGl2ZS0gQldNZ210LSBBQldNZ210
LQ0KCUNhcGFiaWxpdGllczogWzgwXSBQb3dlciBNYW5hZ2VtZW50IHZlcnNpb24gMw0KCQlG
bGFnczogUE1FQ2xrLSBEU0krIEQxKyBEMisgQXV4Q3VycmVudD0wbUEgUE1FKEQwKyxEMSss
RDIrLEQzaG90KyxEM2NvbGQtKQ0KCQlTdGF0dXM6IEQwIE5vU29mdFJzdCsgUE1FLUVuYWJs
ZS0gRFNlbD0wIERTY2FsZT0wIFBNRS0NCglDYXBhYmlsaXRpZXM6IFs5MF0gVml0YWwgUHJv
ZHVjdCBEYXRhDQoJCVVua25vd24gc21hbGwgcmVzb3VyY2UgdHlwZSAwMCwgd2lsbCBub3Qg
ZGVjb2RlIG1vcmUuDQoJQ2FwYWJpbGl0aWVzOiBbYTBdIE1TSTogRW5hYmxlLSBDb3VudD0x
LzEgTWFza2FibGUtIDY0Yml0Kw0KCQlBZGRyZXNzOiAwMDAwMDAwMDAwMDAwMDAwICBEYXRh
OiAwMDAwDQoJQ2FwYWJpbGl0aWVzOiBbMTAwIHYxXSBBZHZhbmNlZCBFcnJvciBSZXBvcnRp
bmcNCgkJVUVTdGE6CURMUC0gU0RFUy0gVExQLSBGQ1AtIENtcGx0VE8tIENtcGx0QWJydC0g
VW54Q21wbHQtIFJ4T0YtIE1hbGZUTFAtIEVDUkMtIFVuc3VwUmVxLSBBQ1NWaW9sLQ0KCQlV
RU1zazoJRExQLSBTREVTLSBUTFAtIEZDUC0gQ21wbHRUTy0gQ21wbHRBYnJ0LSBVbnhDbXBs
dC0gUnhPRi0gTWFsZlRMUC0gRUNSQy0gVW5zdXBSZXEtIEFDU1Zpb2wtDQoJCVVFU3ZydDoJ
RExQKyBTREVTLSBUTFAtIEZDUCsgQ21wbHRUTy0gQ21wbHRBYnJ0LSBVbnhDbXBsdC0gUnhP
RisgTWFsZlRMUCsgRUNSQy0gVW5zdXBSZXEtIEFDU1Zpb2wtDQoJCUNFU3RhOglSeEVyci0g
QmFkVExQLSBCYWRETExQLSBSb2xsb3Zlci0gVGltZW91dC0gTm9uRmF0YWxFcnIrDQoJCUNF
TXNrOglSeEVyci0gQmFkVExQLSBCYWRETExQLSBSb2xsb3Zlci0gVGltZW91dC0gTm9uRmF0
YWxFcnIrDQoJCUFFUkNhcDoJRmlyc3QgRXJyb3IgUG9pbnRlcjogMDAsIEdlbkNhcC0gQ0dl
bkVuLSBDaGtDYXAtIENoa0VuLQ0KCUNhcGFiaWxpdGllczogWzIwMCB2MV0gVmlydHVhbCBD
aGFubmVsDQoJCUNhcHM6CUxQRVZDPTEgUmVmQ2xrPTEwMG5zIFBBVEVudHJ5Qml0cz0xDQoJ
CUFyYjoJRml4ZWQrIFdSUjMyKyBXUlI2NCsgV1JSMTI4LQ0KCQlDdHJsOglBcmJTZWxlY3Q9
V1JSNjQNCgkJU3RhdHVzOglJblByb2dyZXNzLQ0KCQlQb3J0IEFyYml0cmF0aW9uIFRhYmxl
IFsyNDBdIDw/Pg0KCQlWQzA6CUNhcHM6CVBBVE9mZnNldD0wMCBNYXhUaW1lU2xvdHM9MSBS
ZWpTbm9vcFRyYW5zLQ0KCQkJQXJiOglGaXhlZC0gV1JSMzItIFdSUjY0LSBXUlIxMjgtIFRX
UlIxMjgtIFdSUjI1Ni0NCgkJCUN0cmw6CUVuYWJsZSsgSUQ9MCBBcmJTZWxlY3Q9Rml4ZWQg
VEMvVkM9ZmYNCgkJCVN0YXR1czoJTmVnb1BlbmRpbmctIEluUHJvZ3Jlc3MtDQoJCVZDMToJ
Q2FwczoJUEFUT2Zmc2V0PTAwIE1heFRpbWVTbG90cz0xIFJlalNub29wVHJhbnMtDQoJCQlB
cmI6CUZpeGVkLSBXUlIzMi0gV1JSNjQtIFdSUjEyOC0gVFdSUjEyOC0gV1JSMjU2LQ0KCQkJ
Q3RybDoJRW5hYmxlLSBJRD0xIEFyYlNlbGVjdD1GaXhlZCBUQy9WQz0wMA0KCQkJU3RhdHVz
OglOZWdvUGVuZGluZy0gSW5Qcm9ncmVzcy0NCglLZXJuZWwgZHJpdmVyIGluIHVzZTogcGNp
YmFjaw0KDQowNjowMC4wIFZHQSBjb21wYXRpYmxlIGNvbnRyb2xsZXIgWzAzMDBdOiBBVEkg
VGVjaG5vbG9naWVzIEluYyBSVjYyMCBMRSBbUmFkZW9uIEhEIDM0NTBdIFsxMDAyOjk1YzVd
IChwcm9nLWlmIDAwIFtWR0EgY29udHJvbGxlcl0pDQoJU3Vic3lzdGVtOiBBU1VTVGVLIENv
bXB1dGVyIEluYy4gRGV2aWNlIFsxMDQzOjAxZDRdDQoJQ29udHJvbDogSS9PLSBNZW0tIEJ1
c01hc3Rlci0gU3BlY0N5Y2xlLSBNZW1XSU5WLSBWR0FTbm9vcC0gUGFyRXJyLSBTdGVwcGlu
Zy0gU0VSUi0gRmFzdEIyQi0gRGlzSU5UeC0NCglTdGF0dXM6IENhcCsgNjZNSHotIFVERi0g
RmFzdEIyQi0gUGFyRXJyLSBERVZTRUw9ZmFzdCA+VEFib3J0LSA8VEFib3J0LSA8TUFib3J0
LSA+U0VSUi0gPFBFUlItIElOVHgtDQoJSW50ZXJydXB0OiBwaW4gQSByb3V0ZWQgdG8gSVJR
IDEwDQoJUmVnaW9uIDA6IE1lbW9yeSBhdCBiMDAwMDAwMCAoNjQtYml0LCBwcmVmZXRjaGFi
bGUpIFtkaXNhYmxlZF0gW3NpemU9MjU2TV0NCglSZWdpb24gMjogTWVtb3J5IGF0IGY5OWUw
MDAwICg2NC1iaXQsIG5vbi1wcmVmZXRjaGFibGUpIFtkaXNhYmxlZF0gW3NpemU9NjRLXQ0K
CVJlZ2lvbiA0OiBJL08gcG9ydHMgYXQgYjAwMCBbZGlzYWJsZWRdIFtzaXplPTI1Nl0NCglF
eHBhbnNpb24gUk9NIGF0IGY5OWMwMDAwIFtkaXNhYmxlZF0gW3NpemU9MTI4S10NCglDYXBh
YmlsaXRpZXM6IFs1MF0gUG93ZXIgTWFuYWdlbWVudCB2ZXJzaW9uIDMNCgkJRmxhZ3M6IFBN
RUNsay0gRFNJLSBEMSsgRDIrIEF1eEN1cnJlbnQ9MG1BIFBNRShEMC0sRDEtLEQyLSxEM2hv
dC0sRDNjb2xkLSkNCgkJU3RhdHVzOiBEMCBOb1NvZnRSc3QtIFBNRS1FbmFibGUtIERTZWw9
MCBEU2NhbGU9MCBQTUUtDQoJQ2FwYWJpbGl0aWVzOiBbNThdIEV4cHJlc3MgKHYyKSBMZWdh
Y3kgRW5kcG9pbnQsIE1TSSAwMA0KCQlEZXZDYXA6CU1heFBheWxvYWQgMTI4IGJ5dGVzLCBQ
aGFudEZ1bmMgMCwgTGF0ZW5jeSBMMHMgPDR1cywgTDEgdW5saW1pdGVkDQoJCQlFeHRUYWcr
IEF0dG5CdG4tIEF0dG5JbmQtIFB3ckluZC0gUkJFKyBGTFJlc2V0LQ0KCQlEZXZDdGw6CVJl
cG9ydCBlcnJvcnM6IENvcnJlY3RhYmxlLSBOb24tRmF0YWwtIEZhdGFsLSBVbnN1cHBvcnRl
ZC0NCgkJCVJseGRPcmQrIEV4dFRhZy0gUGhhbnRGdW5jLSBBdXhQd3ItIE5vU25vb3ArDQoJ
CQlNYXhQYXlsb2FkIDEyOCBieXRlcywgTWF4UmVhZFJlcSAxMjggYnl0ZXMNCgkJRGV2U3Rh
OglDb3JyRXJyLSBVbmNvcnJFcnItIEZhdGFsRXJyLSBVbnN1cHBSZXEtIEF1eFB3ci0gVHJh
bnNQZW5kLQ0KCQlMbmtDYXA6CVBvcnQgIzAsIFNwZWVkIDIuNUdUL3MsIFdpZHRoIHgxNiwg
QVNQTSBMMHMgTDEsIExhdGVuY3kgTDAgPDY0bnMsIEwxIDwxdXMNCgkJCUNsb2NrUE0tIFN1
cnByaXNlLSBMTEFjdFJlcC0gQndOb3QtDQoJCUxua0N0bDoJQVNQTSBEaXNhYmxlZDsgUkNC
IDY0IGJ5dGVzIERpc2FibGVkLSBSZXRyYWluLSBDb21tQ2xrKw0KCQkJRXh0U3luY2gtIENs
b2NrUE0tIEF1dFdpZERpcy0gQldJbnQtIEF1dEJXSW50LQ0KCQlMbmtTdGE6CVNwZWVkIDIu
NUdUL3MsIFdpZHRoIHgxLCBUckVyci0gVHJhaW4tIFNsb3RDbGsrIERMQWN0aXZlLSBCV01n
bXQtIEFCV01nbXQtDQoJCURldkNhcDI6IENvbXBsZXRpb24gVGltZW91dDogTm90IFN1cHBv
cnRlZCwgVGltZW91dERpcy0NCgkJRGV2Q3RsMjogQ29tcGxldGlvbiBUaW1lb3V0OiA1MHVz
IHRvIDUwbXMsIFRpbWVvdXREaXMtDQoJCUxua0N0bDI6IFRhcmdldCBMaW5rIFNwZWVkOiAy
LjVHVC9zLCBFbnRlckNvbXBsaWFuY2UtIFNwZWVkRGlzLSwgU2VsZWN0YWJsZSBEZS1lbXBo
YXNpczogLTZkQg0KCQkJIFRyYW5zbWl0IE1hcmdpbjogTm9ybWFsIE9wZXJhdGluZyBSYW5n
ZSwgRW50ZXJNb2RpZmllZENvbXBsaWFuY2UtIENvbXBsaWFuY2VTT1MtDQoJCQkgQ29tcGxp
YW5jZSBEZS1lbXBoYXNpczogLTZkQg0KCQlMbmtTdGEyOiBDdXJyZW50IERlLWVtcGhhc2lz
IExldmVsOiAtNmRCDQoJQ2FwYWJpbGl0aWVzOiBbYTBdIE1TSTogRW5hYmxlLSBDb3VudD0x
LzEgTWFza2FibGUtIDY0Yml0Kw0KCQlBZGRyZXNzOiAwMDAwMDAwMDAwMDAwMDAwICBEYXRh
OiAwMDAwDQoJQ2FwYWJpbGl0aWVzOiBbMTAwIHYxXSBWZW5kb3IgU3BlY2lmaWMgSW5mb3Jt
YXRpb246IElEPTAwMDEgUmV2PTEgTGVuPTAxMCA8Pz4NCg0KMDY6MDAuMSBBdWRpbyBkZXZp
Y2UgWzA0MDNdOiBBVEkgVGVjaG5vbG9naWVzIEluYyBSVjYyMCBBdWRpbyBkZXZpY2UgW1Jh
ZGVvbiBIRCAzNHh4IFNlcmllc10gWzEwMDI6YWEyOF0NCglTdWJzeXN0ZW06IEFTVVNUZUsg
Q29tcHV0ZXIgSW5jLiBEZXZpY2UgWzEwNDM6YWEyOF0NCglDb250cm9sOiBJL08rIE1lbSsg
QnVzTWFzdGVyKyBTcGVjQ3ljbGUtIE1lbVdJTlYtIFZHQVNub29wLSBQYXJFcnItIFN0ZXBw
aW5nLSBTRVJSKyBGYXN0QjJCLSBEaXNJTlR4Kw0KCVN0YXR1czogQ2FwKyA2Nk1Iei0gVURG
LSBGYXN0QjJCLSBQYXJFcnItIERFVlNFTD1mYXN0ID5UQWJvcnQtIDxUQWJvcnQtIDxNQWJv
cnQtID5TRVJSLSA8UEVSUi0gSU5UeC0NCglMYXRlbmN5OiAwLCBDYWNoZSBMaW5lIFNpemU6
IDY0IGJ5dGVzDQoJSW50ZXJydXB0OiBwaW4gQiByb3V0ZWQgdG8gSVJRIDEyMw0KCVJlZ2lv
biAwOiBNZW1vcnkgYXQgZjk5ZmMwMDAgKDY0LWJpdCwgbm9uLXByZWZldGNoYWJsZSkgW3Np
emU9MTZLXQ0KCUNhcGFiaWxpdGllczogWzUwXSBQb3dlciBNYW5hZ2VtZW50IHZlcnNpb24g
Mw0KCQlGbGFnczogUE1FQ2xrLSBEU0ktIEQxKyBEMisgQXV4Q3VycmVudD0wbUEgUE1FKEQw
LSxEMS0sRDItLEQzaG90LSxEM2NvbGQtKQ0KCQlTdGF0dXM6IEQwIE5vU29mdFJzdC0gUE1F
LUVuYWJsZS0gRFNlbD0wIERTY2FsZT0wIFBNRS0NCglDYXBhYmlsaXRpZXM6IFs1OF0gRXhw
cmVzcyAodjIpIExlZ2FjeSBFbmRwb2ludCwgTVNJIDAwDQoJCURldkNhcDoJTWF4UGF5bG9h
ZCAxMjggYnl0ZXMsIFBoYW50RnVuYyAwLCBMYXRlbmN5IEwwcyA8NHVzLCBMMSB1bmxpbWl0
ZWQNCgkJCUV4dFRhZysgQXR0bkJ0bi0gQXR0bkluZC0gUHdySW5kLSBSQkUrIEZMUmVzZXQt
DQoJCURldkN0bDoJUmVwb3J0IGVycm9yczogQ29ycmVjdGFibGUtIE5vbi1GYXRhbC0gRmF0
YWwtIFVuc3VwcG9ydGVkLQ0KCQkJUmx4ZE9yZCsgRXh0VGFnLSBQaGFudEZ1bmMtIEF1eFB3
ci0gTm9Tbm9vcCsNCgkJCU1heFBheWxvYWQgMTI4IGJ5dGVzLCBNYXhSZWFkUmVxIDEyOCBi
eXRlcw0KCQlEZXZTdGE6CUNvcnJFcnItIFVuY29yckVyci0gRmF0YWxFcnItIFVuc3VwcFJl
cS0gQXV4UHdyLSBUcmFuc1BlbmQtDQoJCUxua0NhcDoJUG9ydCAjMCwgU3BlZWQgMi41R1Qv
cywgV2lkdGggeDE2LCBBU1BNIEwwcyBMMSwgTGF0ZW5jeSBMMCA8NjRucywgTDEgPDF1cw0K
CQkJQ2xvY2tQTS0gU3VycHJpc2UtIExMQWN0UmVwLSBCd05vdC0NCgkJTG5rQ3RsOglBU1BN
IERpc2FibGVkOyBSQ0IgNjQgYnl0ZXMgRGlzYWJsZWQtIFJldHJhaW4tIENvbW1DbGsrDQoJ
CQlFeHRTeW5jaC0gQ2xvY2tQTS0gQXV0V2lkRGlzLSBCV0ludC0gQXV0QldJbnQtDQoJCUxu
a1N0YToJU3BlZWQgMi41R1QvcywgV2lkdGggeDEsIFRyRXJyLSBUcmFpbi0gU2xvdENsaysg
RExBY3RpdmUtIEJXTWdtdC0gQUJXTWdtdC0NCgkJRGV2Q2FwMjogQ29tcGxldGlvbiBUaW1l
b3V0OiBOb3QgU3VwcG9ydGVkLCBUaW1lb3V0RGlzLQ0KCQlEZXZDdGwyOiBDb21wbGV0aW9u
IFRpbWVvdXQ6IDUwdXMgdG8gNTBtcywgVGltZW91dERpcy0NCgkJTG5rQ3RsMjogVGFyZ2V0
IExpbmsgU3BlZWQ6IDIuNUdUL3MsIEVudGVyQ29tcGxpYW5jZS0gU3BlZWREaXMtLCBTZWxl
Y3RhYmxlIERlLWVtcGhhc2lzOiAtNmRCDQoJCQkgVHJhbnNtaXQgTWFyZ2luOiBOb3JtYWwg
T3BlcmF0aW5nIFJhbmdlLCBFbnRlck1vZGlmaWVkQ29tcGxpYW5jZS0gQ29tcGxpYW5jZVNP
Uy0NCgkJCSBDb21wbGlhbmNlIERlLWVtcGhhc2lzOiAtNmRCDQoJCUxua1N0YTI6IEN1cnJl
bnQgRGUtZW1waGFzaXMgTGV2ZWw6IC02ZEINCglDYXBhYmlsaXRpZXM6IFthMF0gTVNJOiBF
bmFibGUrIENvdW50PTEvMSBNYXNrYWJsZS0gNjRiaXQrDQoJCUFkZHJlc3M6IDAwMDAwMDAw
ZmVlMDEwMGMgIERhdGE6IDQxMmENCglDYXBhYmlsaXRpZXM6IFsxMDAgdjFdIFZlbmRvciBT
cGVjaWZpYyBJbmZvcm1hdGlvbjogSUQ9MDAwMSBSZXY9MSBMZW49MDEwIDw/Pg0KCUtlcm5l
bCBkcml2ZXIgaW4gdXNlOiBzbmRfaGRhX2ludGVsDQoNCjA3OjAwLjAgTXVsdGltZWRpYSB2
aWRlbyBjb250cm9sbGVyIFswNDAwXTogQ29uZXhhbnQgU3lzdGVtcywgSW5jLiBEZXZpY2Ug
WzE0ZjE6ODIxMF0NCglDb250cm9sOiBJL08tIE1lbSsgQnVzTWFzdGVyKyBTcGVjQ3ljbGUt
IE1lbVdJTlYtIFZHQVNub29wLSBQYXJFcnItIFN0ZXBwaW5nLSBTRVJSLSBGYXN0QjJCLSBE
aXNJTlR4LQ0KCVN0YXR1czogQ2FwKyA2Nk1Iei0gVURGLSBGYXN0QjJCLSBQYXJFcnItIERF
VlNFTD1mYXN0ID5UQWJvcnQtIDxUQWJvcnQtIDxNQWJvcnQtID5TRVJSLSA8UEVSUi0gSU5U
eC0NCglMYXRlbmN5OiAwDQoJSW50ZXJydXB0OiBwaW4gQSByb3V0ZWQgdG8gSVJRIDQ3DQoJ
UmVnaW9uIDA6IE1lbW9yeSBhdCBmOWEwMDAwMCAoNjQtYml0LCBub24tcHJlZmV0Y2hhYmxl
KSBbc2l6ZT0yTV0NCglDYXBhYmlsaXRpZXM6IFs0MF0gRXhwcmVzcyAodjEpIEVuZHBvaW50
LCBNU0kgMDANCgkJRGV2Q2FwOglNYXhQYXlsb2FkIDEyOCBieXRlcywgUGhhbnRGdW5jIDAs
IExhdGVuY3kgTDBzIDw2NG5zLCBMMSA8MXVzDQoJCQlFeHRUYWctIEF0dG5CdG4tIEF0dG5J
bmQtIFB3ckluZC0gUkJFKyBGTFJlc2V0LQ0KCQlEZXZDdGw6CVJlcG9ydCBlcnJvcnM6IENv
cnJlY3RhYmxlLSBOb24tRmF0YWwtIEZhdGFsLSBVbnN1cHBvcnRlZC0NCgkJCVJseGRPcmQr
IEV4dFRhZy0gUGhhbnRGdW5jLSBBdXhQd3ItIE5vU25vb3ArDQoJCQlNYXhQYXlsb2FkIDEy
OCBieXRlcywgTWF4UmVhZFJlcSA1MTIgYnl0ZXMNCgkJRGV2U3RhOglDb3JyRXJyLSBVbmNv
cnJFcnItIEZhdGFsRXJyLSBVbnN1cHBSZXEtIEF1eFB3ci0gVHJhbnNQZW5kLQ0KCQlMbmtD
YXA6CVBvcnQgIzAsIFNwZWVkIDIuNUdUL3MsIFdpZHRoIHgxLCBBU1BNIEwwcyBMMSwgTGF0
ZW5jeSBMMCA8MnVzLCBMMSA8NHVzDQoJCQlDbG9ja1BNLSBTdXJwcmlzZS0gTExBY3RSZXAt
IEJ3Tm90LQ0KCQlMbmtDdGw6CUFTUE0gRGlzYWJsZWQ7IFJDQiA2NCBieXRlcyBEaXNhYmxl
ZC0gUmV0cmFpbi0gQ29tbUNsay0NCgkJCUV4dFN5bmNoLSBDbG9ja1BNLSBBdXRXaWREaXMt
IEJXSW50LSBBdXRCV0ludC0NCgkJTG5rU3RhOglTcGVlZCAyLjVHVC9zLCBXaWR0aCB4MSwg
VHJFcnItIFRyYWluLSBTbG90Q2xrLSBETEFjdGl2ZS0gQldNZ210LSBBQldNZ210LQ0KCUNh
cGFiaWxpdGllczogWzgwXSBQb3dlciBNYW5hZ2VtZW50IHZlcnNpb24gMw0KCQlGbGFnczog
UE1FQ2xrLSBEU0krIEQxKyBEMisgQXV4Q3VycmVudD0wbUEgUE1FKEQwKyxEMSssRDIrLEQz
aG90KyxEM2NvbGQtKQ0KCQlTdGF0dXM6IEQwIE5vU29mdFJzdCsgUE1FLUVuYWJsZS0gRFNl
bD0wIERTY2FsZT0wIFBNRS0NCglDYXBhYmlsaXRpZXM6IFs5MF0gVml0YWwgUHJvZHVjdCBE
YXRhDQoJCVVua25vd24gc21hbGwgcmVzb3VyY2UgdHlwZSAwMiwgd2lsbCBub3QgZGVjb2Rl
IG1vcmUuDQoJQ2FwYWJpbGl0aWVzOiBbYTBdIE1TSTogRW5hYmxlLSBDb3VudD0xLzEgTWFz
a2FibGUtIDY0Yml0Kw0KCQlBZGRyZXNzOiAwMDAwMDAwMDAwMDAwMDAwICBEYXRhOiAwMDAw
DQoJQ2FwYWJpbGl0aWVzOiBbMTAwIHYxXSBBZHZhbmNlZCBFcnJvciBSZXBvcnRpbmcNCgkJ
VUVTdGE6CURMUC0gU0RFUy0gVExQLSBGQ1AtIENtcGx0VE8tIENtcGx0QWJydC0gVW54Q21w
bHQtIFJ4T0YtIE1hbGZUTFAtIEVDUkMtIFVuc3VwUmVxLSBBQ1NWaW9sLQ0KCQlVRU1zazoJ
RExQLSBTREVTLSBUTFAtIEZDUC0gQ21wbHRUTy0gQ21wbHRBYnJ0LSBVbnhDbXBsdC0gUnhP
Ri0gTWFsZlRMUC0gRUNSQy0gVW5zdXBSZXEtIEFDU1Zpb2wtDQoJCVVFU3ZydDoJRExQKyBT
REVTLSBUTFAtIEZDUCsgQ21wbHRUTy0gQ21wbHRBYnJ0LSBVbnhDbXBsdC0gUnhPRisgTWFs
ZlRMUCsgRUNSQy0gVW5zdXBSZXEtIEFDU1Zpb2wtDQoJCUNFU3RhOglSeEVyci0gQmFkVExQ
LSBCYWRETExQLSBSb2xsb3Zlci0gVGltZW91dC0gTm9uRmF0YWxFcnIrDQoJCUNFTXNrOglS
eEVyci0gQmFkVExQLSBCYWRETExQLSBSb2xsb3Zlci0gVGltZW91dC0gTm9uRmF0YWxFcnIr
DQoJCUFFUkNhcDoJRmlyc3QgRXJyb3IgUG9pbnRlcjogMDAsIEdlbkNhcC0gQ0dlbkVuLSBD
aGtDYXAtIENoa0VuLQ0KCUNhcGFiaWxpdGllczogWzIwMCB2MV0gVmlydHVhbCBDaGFubmVs
DQoJCUNhcHM6CUxQRVZDPTEgUmVmQ2xrPTEwMG5zIFBBVEVudHJ5Qml0cz0xDQoJCUFyYjoJ
Rml4ZWQrIFdSUjMyKyBXUlI2NCsgV1JSMTI4LQ0KCQlDdHJsOglBcmJTZWxlY3Q9V1JSNjQN
CgkJU3RhdHVzOglJblByb2dyZXNzLQ0KCQlQb3J0IEFyYml0cmF0aW9uIFRhYmxlIFsyNDBd
IDw/Pg0KCQlWQzA6CUNhcHM6CVBBVE9mZnNldD0wMCBNYXhUaW1lU2xvdHM9MSBSZWpTbm9v
cFRyYW5zLQ0KCQkJQXJiOglGaXhlZC0gV1JSMzItIFdSUjY0LSBXUlIxMjgtIFRXUlIxMjgt
IFdSUjI1Ni0NCgkJCUN0cmw6CUVuYWJsZSsgSUQ9MCBBcmJTZWxlY3Q9Rml4ZWQgVEMvVkM9
ZmYNCgkJCVN0YXR1czoJTmVnb1BlbmRpbmctIEluUHJvZ3Jlc3MtDQoJCVZDMToJQ2FwczoJ
UEFUT2Zmc2V0PTAwIE1heFRpbWVTbG90cz0xIFJlalNub29wVHJhbnMtDQoJCQlBcmI6CUZp
eGVkLSBXUlIzMi0gV1JSNjQtIFdSUjEyOC0gVFdSUjEyOC0gV1JSMjU2LQ0KCQkJQ3RybDoJ
RW5hYmxlLSBJRD0xIEFyYlNlbGVjdD1GaXhlZCBUQy9WQz0wMA0KCQkJU3RhdHVzOglOZWdv
UGVuZGluZy0gSW5Qcm9ncmVzcy0NCglLZXJuZWwgZHJpdmVyIGluIHVzZTogcGNpYmFjaw0K
DQowODowMC4wIEV0aGVybmV0IGNvbnRyb2xsZXIgWzAyMDBdOiBSZWFsdGVrIFNlbWljb25k
dWN0b3IgQ28uLCBMdGQuIFJUTDgxMTEvODE2OEIgUENJIEV4cHJlc3MgR2lnYWJpdCBFdGhl
cm5ldCBjb250cm9sbGVyIFsxMGVjOjgxNjhdIChyZXYgMDMpDQoJU3Vic3lzdGVtOiBNaWNy
by1TdGFyIEludGVybmF0aW9uYWwgQ28uLCBMdGQuIERldmljZSBbMTQ2Mjo3NjQwXQ0KCUNv
bnRyb2w6IEkvTysgTWVtKyBCdXNNYXN0ZXIrIFNwZWNDeWNsZS0gTWVtV0lOVi0gVkdBU25v
b3AtIFBhckVyci0gU3RlcHBpbmctIFNFUlIrIEZhc3RCMkItIERpc0lOVHgrDQoJU3RhdHVz
OiBDYXArIDY2TUh6LSBVREYtIEZhc3RCMkItIFBhckVyci0gREVWU0VMPWZhc3QgPlRBYm9y
dC0gPFRBYm9ydC0gPE1BYm9ydC0gPlNFUlItIDxQRVJSLSBJTlR4LQ0KCUxhdGVuY3k6IDAs
IENhY2hlIExpbmUgU2l6ZTogNjQgYnl0ZXMNCglJbnRlcnJ1cHQ6IHBpbiBBIHJvdXRlZCB0
byBJUlEgMTIyDQoJUmVnaW9uIDA6IEkvTyBwb3J0cyBhdCBjODAwIFtzaXplPTI1Nl0NCglS
ZWdpb24gMjogTWVtb3J5IGF0IGNmZWZmMDAwICg2NC1iaXQsIHByZWZldGNoYWJsZSkgW3Np
emU9NEtdDQoJUmVnaW9uIDQ6IE1lbW9yeSBhdCBjZmVmODAwMCAoNjQtYml0LCBwcmVmZXRj
aGFibGUpIFtzaXplPTE2S10NCglFeHBhbnNpb24gUk9NIGF0IGY5ZGUwMDAwIFtkaXNhYmxl
ZF0gW3NpemU9MTI4S10NCglDYXBhYmlsaXRpZXM6IFs0MF0gUG93ZXIgTWFuYWdlbWVudCB2
ZXJzaW9uIDMNCgkJRmxhZ3M6IFBNRUNsay0gRFNJLSBEMSsgRDIrIEF1eEN1cnJlbnQ9Mzc1
bUEgUE1FKEQwKyxEMSssRDIrLEQzaG90KyxEM2NvbGQrKQ0KCQlTdGF0dXM6IEQwIE5vU29m
dFJzdCsgUE1FLUVuYWJsZS0gRFNlbD0wIERTY2FsZT0wIFBNRS0NCglDYXBhYmlsaXRpZXM6
IFs1MF0gTVNJOiBFbmFibGUrIENvdW50PTEvMSBNYXNrYWJsZS0gNjRiaXQrDQoJCUFkZHJl
c3M6IDAwMDAwMDAwZmVlMDEwMGMgIERhdGE6IDQxZDkNCglDYXBhYmlsaXRpZXM6IFs3MF0g
RXhwcmVzcyAodjIpIEVuZHBvaW50LCBNU0kgMDENCgkJRGV2Q2FwOglNYXhQYXlsb2FkIDI1
NiBieXRlcywgUGhhbnRGdW5jIDAsIExhdGVuY3kgTDBzIDw1MTJucywgTDEgPDY0dXMNCgkJ
CUV4dFRhZy0gQXR0bkJ0bi0gQXR0bkluZC0gUHdySW5kLSBSQkUrIEZMUmVzZXQtDQoJCURl
dkN0bDoJUmVwb3J0IGVycm9yczogQ29ycmVjdGFibGUtIE5vbi1GYXRhbC0gRmF0YWwtIFVu
c3VwcG9ydGVkLQ0KCQkJUmx4ZE9yZC0gRXh0VGFnLSBQaGFudEZ1bmMtIEF1eFB3ci0gTm9T
bm9vcC0NCgkJCU1heFBheWxvYWQgMTI4IGJ5dGVzLCBNYXhSZWFkUmVxIDUxMiBieXRlcw0K
CQlEZXZTdGE6CUNvcnJFcnIrIFVuY29yckVyci0gRmF0YWxFcnItIFVuc3VwcFJlcSsgQXV4
UHdyKyBUcmFuc1BlbmQtDQoJCUxua0NhcDoJUG9ydCAjMCwgU3BlZWQgMi41R1QvcywgV2lk
dGggeDEsIEFTUE0gTDBzIEwxLCBMYXRlbmN5IEwwIDw1MTJucywgTDEgPDY0dXMNCgkJCUNs
b2NrUE0rIFN1cnByaXNlLSBMTEFjdFJlcC0gQndOb3QtDQoJCUxua0N0bDoJQVNQTSBEaXNh
YmxlZDsgUkNCIDY0IGJ5dGVzIERpc2FibGVkLSBSZXRyYWluLSBDb21tQ2xrKw0KCQkJRXh0
U3luY2gtIENsb2NrUE0tIEF1dFdpZERpcy0gQldJbnQtIEF1dEJXSW50LQ0KCQlMbmtTdGE6
CVNwZWVkIDIuNUdUL3MsIFdpZHRoIHgxLCBUckVyci0gVHJhaW4tIFNsb3RDbGsrIERMQWN0
aXZlLSBCV01nbXQtIEFCV01nbXQtDQoJCURldkNhcDI6IENvbXBsZXRpb24gVGltZW91dDog
Tm90IFN1cHBvcnRlZCwgVGltZW91dERpcysNCgkJRGV2Q3RsMjogQ29tcGxldGlvbiBUaW1l
b3V0OiA1MHVzIHRvIDUwbXMsIFRpbWVvdXREaXMtDQoJCUxua0N0bDI6IFRhcmdldCBMaW5r
IFNwZWVkOiAyLjVHVC9zLCBFbnRlckNvbXBsaWFuY2UtIFNwZWVkRGlzLSwgU2VsZWN0YWJs
ZSBEZS1lbXBoYXNpczogLTZkQg0KCQkJIFRyYW5zbWl0IE1hcmdpbjogTm9ybWFsIE9wZXJh
dGluZyBSYW5nZSwgRW50ZXJNb2RpZmllZENvbXBsaWFuY2UtIENvbXBsaWFuY2VTT1MtDQoJ
CQkgQ29tcGxpYW5jZSBEZS1lbXBoYXNpczogLTZkQg0KCQlMbmtTdGEyOiBDdXJyZW50IERl
LWVtcGhhc2lzIExldmVsOiAtNmRCDQoJQ2FwYWJpbGl0aWVzOiBbYWNdIE1TSS1YOiBFbmFi
bGUtIENvdW50PTQgTWFza2VkLQ0KCQlWZWN0b3IgdGFibGU6IEJBUj00IG9mZnNldD0wMDAw
MDAwMA0KCQlQQkE6IEJBUj00IG9mZnNldD0wMDAwMDgwMA0KCUNhcGFiaWxpdGllczogW2Nj
XSBWaXRhbCBQcm9kdWN0IERhdGENCgkJVW5rbm93biBzbWFsbCByZXNvdXJjZSB0eXBlIDAw
LCB3aWxsIG5vdCBkZWNvZGUgbW9yZS4NCglDYXBhYmlsaXRpZXM6IFsxMDAgdjFdIEFkdmFu
Y2VkIEVycm9yIFJlcG9ydGluZw0KCQlVRVN0YToJRExQLSBTREVTLSBUTFAtIEZDUC0gQ21w
bHRUTy0gQ21wbHRBYnJ0LSBVbnhDbXBsdC0gUnhPRi0gTWFsZlRMUC0gRUNSQy0gVW5zdXBS
ZXEtIEFDU1Zpb2wtDQoJCVVFTXNrOglETFAtIFNERVMtIFRMUC0gRkNQLSBDbXBsdFRPLSBD
bXBsdEFicnQtIFVueENtcGx0LSBSeE9GLSBNYWxmVExQLSBFQ1JDLSBVbnN1cFJlcS0gQUNT
VmlvbC0NCgkJVUVTdnJ0OglETFArIFNERVMrIFRMUC0gRkNQKyBDbXBsdFRPLSBDbXBsdEFi
cnQtIFVueENtcGx0LSBSeE9GKyBNYWxmVExQKyBFQ1JDLSBVbnN1cFJlcS0gQUNTVmlvbC0N
CgkJQ0VTdGE6CVJ4RXJyKyBCYWRUTFAtIEJhZERMTFAtIFJvbGxvdmVyLSBUaW1lb3V0LSBO
b25GYXRhbEVycisNCgkJQ0VNc2s6CVJ4RXJyLSBCYWRUTFAtIEJhZERMTFAtIFJvbGxvdmVy
LSBUaW1lb3V0LSBOb25GYXRhbEVycisNCgkJQUVSQ2FwOglGaXJzdCBFcnJvciBQb2ludGVy
OiAwMCwgR2VuQ2FwKyBDR2VuRW4tIENoa0NhcCsgQ2hrRW4tDQoJQ2FwYWJpbGl0aWVzOiBb
MTQwIHYxXSBWaXJ0dWFsIENoYW5uZWwNCgkJQ2FwczoJTFBFVkM9MCBSZWZDbGs9MTAwbnMg
UEFURW50cnlCaXRzPTENCgkJQXJiOglGaXhlZC0gV1JSMzItIFdSUjY0LSBXUlIxMjgtDQoJ
CUN0cmw6CUFyYlNlbGVjdD1GaXhlZA0KCQlTdGF0dXM6CUluUHJvZ3Jlc3MtDQoJCVZDMDoJ
Q2FwczoJUEFUT2Zmc2V0PTAwIE1heFRpbWVTbG90cz0xIFJlalNub29wVHJhbnMtDQoJCQlB
cmI6CUZpeGVkLSBXUlIzMi0gV1JSNjQtIFdSUjEyOC0gVFdSUjEyOC0gV1JSMjU2LQ0KCQkJ
Q3RybDoJRW5hYmxlKyBJRD0wIEFyYlNlbGVjdD1GaXhlZCBUQy9WQz1mZg0KCQkJU3RhdHVz
OglOZWdvUGVuZGluZy0gSW5Qcm9ncmVzcy0NCglDYXBhYmlsaXRpZXM6IFsxNjAgdjFdIERl
dmljZSBTZXJpYWwgTnVtYmVyIDAzLTAwLTAwLTAwLTY4LTRjLWUwLTAwDQoJS2VybmVsIGRy
aXZlciBpbiB1c2U6IHI4MTY5DQoNCjA5OjAwLjAgRXRoZXJuZXQgY29udHJvbGxlciBbMDIw
MF06IFJlYWx0ZWsgU2VtaWNvbmR1Y3RvciBDby4sIEx0ZC4gUlRMODExMS84MTY4QiBQQ0kg
RXhwcmVzcyBHaWdhYml0IEV0aGVybmV0IGNvbnRyb2xsZXIgWzEwZWM6ODE2OF0gKHJldiAw
MykNCglTdWJzeXN0ZW06IE1pY3JvLVN0YXIgSW50ZXJuYXRpb25hbCBDby4sIEx0ZC4gRGV2
aWNlIFsxNDYyOjc2NDBdDQoJQ29udHJvbDogSS9PKyBNZW0rIEJ1c01hc3RlcisgU3BlY0N5
Y2xlLSBNZW1XSU5WLSBWR0FTbm9vcC0gUGFyRXJyLSBTdGVwcGluZy0gU0VSUisgRmFzdEIy
Qi0gRGlzSU5UeCsNCglTdGF0dXM6IENhcCsgNjZNSHotIFVERi0gRmFzdEIyQi0gUGFyRXJy
LSBERVZTRUw9ZmFzdCA+VEFib3J0LSA8VEFib3J0LSA8TUFib3J0LSA+U0VSUi0gPFBFUlIt
IElOVHgtDQoJTGF0ZW5jeTogMCwgQ2FjaGUgTGluZSBTaXplOiA2NCBieXRlcw0KCUludGVy
cnVwdDogcGluIEEgcm91dGVkIHRvIElSUSAxMjENCglSZWdpb24gMDogSS9PIHBvcnRzIGF0
IGQ4MDAgW3NpemU9MjU2XQ0KCVJlZ2lvbiAyOiBNZW1vcnkgYXQgY2ZmZmYwMDAgKDY0LWJp
dCwgcHJlZmV0Y2hhYmxlKSBbc2l6ZT00S10NCglSZWdpb24gNDogTWVtb3J5IGF0IGNmZmY4
MDAwICg2NC1iaXQsIHByZWZldGNoYWJsZSkgW3NpemU9MTZLXQ0KCUV4cGFuc2lvbiBST00g
YXQgZjllZTAwMDAgW2Rpc2FibGVkXSBbc2l6ZT0xMjhLXQ0KCUNhcGFiaWxpdGllczogWzQw
XSBQb3dlciBNYW5hZ2VtZW50IHZlcnNpb24gMw0KCQlGbGFnczogUE1FQ2xrLSBEU0ktIEQx
KyBEMisgQXV4Q3VycmVudD0zNzVtQSBQTUUoRDArLEQxKyxEMissRDNob3QrLEQzY29sZCsp
DQoJCVN0YXR1czogRDAgTm9Tb2Z0UnN0KyBQTUUtRW5hYmxlLSBEU2VsPTAgRFNjYWxlPTAg
UE1FLQ0KCUNhcGFiaWxpdGllczogWzUwXSBNU0k6IEVuYWJsZSsgQ291bnQ9MS8xIE1hc2th
YmxlLSA2NGJpdCsNCgkJQWRkcmVzczogMDAwMDAwMDBmZWUwMTAwYyAgRGF0YTogNDFjOQ0K
CUNhcGFiaWxpdGllczogWzcwXSBFeHByZXNzICh2MikgRW5kcG9pbnQsIE1TSSAwMQ0KCQlE
ZXZDYXA6CU1heFBheWxvYWQgMjU2IGJ5dGVzLCBQaGFudEZ1bmMgMCwgTGF0ZW5jeSBMMHMg
PDUxMm5zLCBMMSA8NjR1cw0KCQkJRXh0VGFnLSBBdHRuQnRuLSBBdHRuSW5kLSBQd3JJbmQt
IFJCRSsgRkxSZXNldC0NCgkJRGV2Q3RsOglSZXBvcnQgZXJyb3JzOiBDb3JyZWN0YWJsZS0g
Tm9uLUZhdGFsLSBGYXRhbC0gVW5zdXBwb3J0ZWQtDQoJCQlSbHhkT3JkLSBFeHRUYWctIFBo
YW50RnVuYy0gQXV4UHdyLSBOb1Nub29wLQ0KCQkJTWF4UGF5bG9hZCAxMjggYnl0ZXMsIE1h
eFJlYWRSZXEgNDA5NiBieXRlcw0KCQlEZXZTdGE6CUNvcnJFcnIrIFVuY29yckVyci0gRmF0
YWxFcnItIFVuc3VwcFJlcSsgQXV4UHdyKyBUcmFuc1BlbmQtDQoJCUxua0NhcDoJUG9ydCAj
MCwgU3BlZWQgMi41R1QvcywgV2lkdGggeDEsIEFTUE0gTDBzIEwxLCBMYXRlbmN5IEwwIDw1
MTJucywgTDEgPDY0dXMNCgkJCUNsb2NrUE0rIFN1cnByaXNlLSBMTEFjdFJlcC0gQndOb3Qt
DQoJCUxua0N0bDoJQVNQTSBEaXNhYmxlZDsgUkNCIDY0IGJ5dGVzIERpc2FibGVkLSBSZXRy
YWluLSBDb21tQ2xrKw0KCQkJRXh0U3luY2gtIENsb2NrUE0tIEF1dFdpZERpcy0gQldJbnQt
IEF1dEJXSW50LQ0KCQlMbmtTdGE6CVNwZWVkIDIuNUdUL3MsIFdpZHRoIHgxLCBUckVyci0g
VHJhaW4tIFNsb3RDbGsrIERMQWN0aXZlLSBCV01nbXQtIEFCV01nbXQtDQoJCURldkNhcDI6
IENvbXBsZXRpb24gVGltZW91dDogTm90IFN1cHBvcnRlZCwgVGltZW91dERpcysNCgkJRGV2
Q3RsMjogQ29tcGxldGlvbiBUaW1lb3V0OiA1MHVzIHRvIDUwbXMsIFRpbWVvdXREaXMtDQoJ
CUxua0N0bDI6IFRhcmdldCBMaW5rIFNwZWVkOiAyLjVHVC9zLCBFbnRlckNvbXBsaWFuY2Ut
IFNwZWVkRGlzLSwgU2VsZWN0YWJsZSBEZS1lbXBoYXNpczogLTZkQg0KCQkJIFRyYW5zbWl0
IE1hcmdpbjogTm9ybWFsIE9wZXJhdGluZyBSYW5nZSwgRW50ZXJNb2RpZmllZENvbXBsaWFu
Y2UtIENvbXBsaWFuY2VTT1MtDQoJCQkgQ29tcGxpYW5jZSBEZS1lbXBoYXNpczogLTZkQg0K
CQlMbmtTdGEyOiBDdXJyZW50IERlLWVtcGhhc2lzIExldmVsOiAtNmRCDQoJQ2FwYWJpbGl0
aWVzOiBbYWNdIE1TSS1YOiBFbmFibGUtIENvdW50PTQgTWFza2VkLQ0KCQlWZWN0b3IgdGFi
bGU6IEJBUj00IG9mZnNldD0wMDAwMDAwMA0KCQlQQkE6IEJBUj00IG9mZnNldD0wMDAwMDgw
MA0KCUNhcGFiaWxpdGllczogW2NjXSBWaXRhbCBQcm9kdWN0IERhdGENCgkJVW5rbm93biBz
bWFsbCByZXNvdXJjZSB0eXBlIDAwLCB3aWxsIG5vdCBkZWNvZGUgbW9yZS4NCglDYXBhYmls
aXRpZXM6IFsxMDAgdjFdIEFkdmFuY2VkIEVycm9yIFJlcG9ydGluZw0KCQlVRVN0YToJRExQ
LSBTREVTLSBUTFAtIEZDUC0gQ21wbHRUTy0gQ21wbHRBYnJ0LSBVbnhDbXBsdC0gUnhPRi0g
TWFsZlRMUC0gRUNSQy0gVW5zdXBSZXEtIEFDU1Zpb2wtDQoJCVVFTXNrOglETFAtIFNERVMt
IFRMUC0gRkNQLSBDbXBsdFRPLSBDbXBsdEFicnQtIFVueENtcGx0LSBSeE9GLSBNYWxmVExQ
LSBFQ1JDLSBVbnN1cFJlcS0gQUNTVmlvbC0NCgkJVUVTdnJ0OglETFArIFNERVMrIFRMUC0g
RkNQKyBDbXBsdFRPLSBDbXBsdEFicnQtIFVueENtcGx0LSBSeE9GKyBNYWxmVExQKyBFQ1JD
LSBVbnN1cFJlcS0gQUNTVmlvbC0NCgkJQ0VTdGE6CVJ4RXJyKyBCYWRUTFAtIEJhZERMTFAt
IFJvbGxvdmVyLSBUaW1lb3V0LSBOb25GYXRhbEVycisNCgkJQ0VNc2s6CVJ4RXJyLSBCYWRU
TFAtIEJhZERMTFAtIFJvbGxvdmVyLSBUaW1lb3V0LSBOb25GYXRhbEVycisNCgkJQUVSQ2Fw
OglGaXJzdCBFcnJvciBQb2ludGVyOiAwMCwgR2VuQ2FwKyBDR2VuRW4tIENoa0NhcCsgQ2hr
RW4tDQoJQ2FwYWJpbGl0aWVzOiBbMTQwIHYxXSBWaXJ0dWFsIENoYW5uZWwNCgkJQ2FwczoJ
TFBFVkM9MCBSZWZDbGs9MTAwbnMgUEFURW50cnlCaXRzPTENCgkJQXJiOglGaXhlZC0gV1JS
MzItIFdSUjY0LSBXUlIxMjgtDQoJCUN0cmw6CUFyYlNlbGVjdD1GaXhlZA0KCQlTdGF0dXM6
CUluUHJvZ3Jlc3MtDQoJCVZDMDoJQ2FwczoJUEFUT2Zmc2V0PTAwIE1heFRpbWVTbG90cz0x
IFJlalNub29wVHJhbnMtDQoJCQlBcmI6CUZpeGVkLSBXUlIzMi0gV1JSNjQtIFdSUjEyOC0g
VFdSUjEyOC0gV1JSMjU2LQ0KCQkJQ3RybDoJRW5hYmxlKyBJRD0wIEFyYlNlbGVjdD1GaXhl
ZCBUQy9WQz1mZg0KCQkJU3RhdHVzOglOZWdvUGVuZGluZy0gSW5Qcm9ncmVzcy0NCglDYXBh
YmlsaXRpZXM6IFsxNjAgdjFdIERldmljZSBTZXJpYWwgTnVtYmVyIDA0LTAwLTAwLTAwLTY4
LTRjLWUwLTAwDQoJS2VybmVsIGRyaXZlciBpbiB1c2U6IHI4MTY5DQoNCjBhOjAwLjAgVVNC
IGNvbnRyb2xsZXIgWzBjMDNdOiBOZXRNb3MgVGVjaG5vbG9neSBNQ1M5OTkwIFBDSWUgdG8g
NOKAkFBvcnQgVVNCIDIuMCBIb3N0IENvbnRyb2xsZXIgWzk3MTA6OTk5MF0gKHByb2ctaWYg
MTAgW09IQ0ldKQ0KCVN1YnN5c3RlbTogRGV2aWNlIFthMDAwOjQwMDBdDQoJQ29udHJvbDog
SS9PLSBNZW0rIEJ1c01hc3RlcisgU3BlY0N5Y2xlLSBNZW1XSU5WLSBWR0FTbm9vcC0gUGFy
RXJyLSBTdGVwcGluZy0gU0VSUi0gRmFzdEIyQi0gRGlzSU5UeC0NCglTdGF0dXM6IENhcCsg
NjZNSHotIFVERi0gRmFzdEIyQi0gUGFyRXJyLSBERVZTRUw9ZmFzdCA+VEFib3J0LSA8VEFi
b3J0KyA8TUFib3J0LSA+U0VSUi0gPFBFUlItIElOVHgtDQoJTGF0ZW5jeTogMCwgQ2FjaGUg
TGluZSBTaXplOiA2NCBieXRlcw0KCUludGVycnVwdDogcGluIEEgcm91dGVkIHRvIElSUSAy
OA0KCVJlZ2lvbiAwOiBNZW1vcnkgYXQgZjlmZjgwMDAgKDMyLWJpdCwgbm9uLXByZWZldGNo
YWJsZSkgW3NpemU9NEtdDQoJQ2FwYWJpbGl0aWVzOiBbNTBdIE1TSTogRW5hYmxlLSBDb3Vu
dD0xLzEgTWFza2FibGUtIDY0Yml0Kw0KCQlBZGRyZXNzOiAwMDAwMDAwMDAwMDAwMDAwICBE
YXRhOiAwMDAwDQoJQ2FwYWJpbGl0aWVzOiBbNzhdIFBvd2VyIE1hbmFnZW1lbnQgdmVyc2lv
biAzDQoJCUZsYWdzOiBQTUVDbGstIERTSS0gRDErIEQyKyBBdXhDdXJyZW50PTM3NW1BIFBN
RShEMCssRDErLEQyKyxEM2hvdCssRDNjb2xkLSkNCgkJU3RhdHVzOiBEMCBOb1NvZnRSc3Qr
IFBNRS1FbmFibGUtIERTZWw9MCBEU2NhbGU9MCBQTUUtDQoJQ2FwYWJpbGl0aWVzOiBbODBd
IEV4cHJlc3MgKHYxKSBFbmRwb2ludCwgTVNJIDAwDQoJCURldkNhcDoJTWF4UGF5bG9hZCAy
NTYgYnl0ZXMsIFBoYW50RnVuYyAwLCBMYXRlbmN5IEwwcyB1bmxpbWl0ZWQsIEwxIHVubGlt
aXRlZA0KCQkJRXh0VGFnLSBBdHRuQnRuLSBBdHRuSW5kLSBQd3JJbmQtIFJCRSsgRkxSZXNl
dC0NCgkJRGV2Q3RsOglSZXBvcnQgZXJyb3JzOiBDb3JyZWN0YWJsZS0gTm9uLUZhdGFsLSBG
YXRhbC0gVW5zdXBwb3J0ZWQtDQoJCQlSbHhkT3JkLSBFeHRUYWctIFBoYW50RnVuYy0gQXV4
UHdyLSBOb1Nub29wKw0KCQkJTWF4UGF5bG9hZCAxMjggYnl0ZXMsIE1heFJlYWRSZXEgNTEy
IGJ5dGVzDQoJCURldlN0YToJQ29yckVyci0gVW5jb3JyRXJyLSBGYXRhbEVyci0gVW5zdXBw
UmVxLSBBdXhQd3ItIFRyYW5zUGVuZC0NCgkJTG5rQ2FwOglQb3J0ICMxLCBTcGVlZCAyLjVH
VC9zLCBXaWR0aCB4MSwgQVNQTSB1bmtub3duLCBMYXRlbmN5IEwwIDw2NG5zLCBMMSB1bmxp
bWl0ZWQNCgkJCUNsb2NrUE0rIFN1cnByaXNlLSBMTEFjdFJlcC0gQndOb3QtDQoJCUxua0N0
bDoJQVNQTSBEaXNhYmxlZDsgUkNCIDY0IGJ5dGVzIERpc2FibGVkLSBSZXRyYWluLSBDb21t
Q2xrLQ0KCQkJRXh0U3luY2gtIENsb2NrUE0tIEF1dFdpZERpcy0gQldJbnQtIEF1dEJXSW50
LQ0KCQlMbmtTdGE6CVNwZWVkIDIuNUdUL3MsIFdpZHRoIHgxLCBUckVyci0gVHJhaW4tIFNs
b3RDbGstIERMQWN0aXZlLSBCV01nbXQtIEFCV01nbXQtDQoJQ2FwYWJpbGl0aWVzOiBbMTAw
IHYxXSBWaXJ0dWFsIENoYW5uZWwNCgkJQ2FwczoJTFBFVkM9MCBSZWZDbGs9MTAwbnMgUEFU
RW50cnlCaXRzPTENCgkJQXJiOglGaXhlZC0gV1JSMzItIFdSUjY0LSBXUlIxMjgtDQoJCUN0
cmw6CUFyYlNlbGVjdD1GaXhlZA0KCQlTdGF0dXM6CUluUHJvZ3Jlc3MtDQoJCVZDMDoJQ2Fw
czoJUEFUT2Zmc2V0PTAwIE1heFRpbWVTbG90cz0xIFJlalNub29wVHJhbnMtDQoJCQlBcmI6
CUZpeGVkLSBXUlIzMi0gV1JSNjQtIFdSUjEyOC0gVFdSUjEyOC0gV1JSMjU2LQ0KCQkJQ3Ry
bDoJRW5hYmxlKyBJRD0wIEFyYlNlbGVjdD1GaXhlZCBUQy9WQz1mZg0KCQkJU3RhdHVzOglO
ZWdvUGVuZGluZy0gSW5Qcm9ncmVzcy0NCglLZXJuZWwgZHJpdmVyIGluIHVzZTogcGNpYmFj
aw0KDQowYTowMC4xIFVTQiBjb250cm9sbGVyIFswYzAzXTogTmV0TW9zIFRlY2hub2xvZ3kg
TUNTOTk5MCBQQ0llIHRvIDTigJBQb3J0IFVTQiAyLjAgSG9zdCBDb250cm9sbGVyIFs5NzEw
Ojk5OTBdIChwcm9nLWlmIDIwIFtFSENJXSkNCglTdWJzeXN0ZW06IERldmljZSBbYTAwMDo0
MDAwXQ0KCUNvbnRyb2w6IEkvTy0gTWVtKyBCdXNNYXN0ZXIrIFNwZWNDeWNsZS0gTWVtV0lO
Vi0gVkdBU25vb3AtIFBhckVyci0gU3RlcHBpbmctIFNFUlItIEZhc3RCMkItIERpc0lOVHgt
DQoJU3RhdHVzOiBDYXArIDY2TUh6LSBVREYtIEZhc3RCMkItIFBhckVyci0gREVWU0VMPWZh
c3QgPlRBYm9ydC0gPFRBYm9ydCsgPE1BYm9ydC0gPlNFUlItIDxQRVJSLSBJTlR4LQ0KCUxh
dGVuY3k6IDAsIENhY2hlIExpbmUgU2l6ZTogNjQgYnl0ZXMNCglJbnRlcnJ1cHQ6IHBpbiBB
IHJvdXRlZCB0byBJUlEgMjgNCglSZWdpb24gMDogTWVtb3J5IGF0IGY5ZmY5MDAwICgzMi1i
aXQsIG5vbi1wcmVmZXRjaGFibGUpIFtzaXplPTRLXQ0KCUNhcGFiaWxpdGllczogWzUwXSBN
U0k6IEVuYWJsZS0gQ291bnQ9MS8xIE1hc2thYmxlLSA2NGJpdCsNCgkJQWRkcmVzczogMDAw
MDAwMDAwMDAwMDAwMCAgRGF0YTogMDAwMA0KCUNhcGFiaWxpdGllczogWzc4XSBQb3dlciBN
YW5hZ2VtZW50IHZlcnNpb24gMw0KCQlGbGFnczogUE1FQ2xrLSBEU0ktIEQxKyBEMisgQXV4
Q3VycmVudD0zNzVtQSBQTUUoRDArLEQxKyxEMissRDNob3QrLEQzY29sZC0pDQoJCVN0YXR1
czogRDAgTm9Tb2Z0UnN0KyBQTUUtRW5hYmxlLSBEU2VsPTAgRFNjYWxlPTAgUE1FLQ0KCUNh
cGFiaWxpdGllczogWzgwXSBFeHByZXNzICh2MSkgRW5kcG9pbnQsIE1TSSAwMA0KCQlEZXZD
YXA6CU1heFBheWxvYWQgMjU2IGJ5dGVzLCBQaGFudEZ1bmMgMCwgTGF0ZW5jeSBMMHMgdW5s
aW1pdGVkLCBMMSB1bmxpbWl0ZWQNCgkJCUV4dFRhZy0gQXR0bkJ0bi0gQXR0bkluZC0gUHdy
SW5kLSBSQkUrIEZMUmVzZXQtDQoJCURldkN0bDoJUmVwb3J0IGVycm9yczogQ29ycmVjdGFi
bGUtIE5vbi1GYXRhbC0gRmF0YWwtIFVuc3VwcG9ydGVkLQ0KCQkJUmx4ZE9yZC0gRXh0VGFn
LSBQaGFudEZ1bmMtIEF1eFB3ci0gTm9Tbm9vcCsNCgkJCU1heFBheWxvYWQgMTI4IGJ5dGVz
LCBNYXhSZWFkUmVxIDUxMiBieXRlcw0KCQlEZXZTdGE6CUNvcnJFcnItIFVuY29yckVyci0g
RmF0YWxFcnItIFVuc3VwcFJlcS0gQXV4UHdyLSBUcmFuc1BlbmQtDQoJCUxua0NhcDoJUG9y
dCAjMSwgU3BlZWQgMi41R1QvcywgV2lkdGggeDEsIEFTUE0gdW5rbm93biwgTGF0ZW5jeSBM
MCA8NjRucywgTDEgdW5saW1pdGVkDQoJCQlDbG9ja1BNKyBTdXJwcmlzZS0gTExBY3RSZXAt
IEJ3Tm90LQ0KCQlMbmtDdGw6CUFTUE0gRGlzYWJsZWQ7IFJDQiA2NCBieXRlcyBEaXNhYmxl
ZC0gUmV0cmFpbi0gQ29tbUNsay0NCgkJCUV4dFN5bmNoLSBDbG9ja1BNLSBBdXRXaWREaXMt
IEJXSW50LSBBdXRCV0ludC0NCgkJTG5rU3RhOglTcGVlZCAyLjVHVC9zLCBXaWR0aCB4MSwg
VHJFcnItIFRyYWluLSBTbG90Q2xrLSBETEFjdGl2ZS0gQldNZ210LSBBQldNZ210LQ0KCUtl
cm5lbCBkcml2ZXIgaW4gdXNlOiBwY2liYWNrDQoNCjBhOjAwLjIgVVNCIGNvbnRyb2xsZXIg
WzBjMDNdOiBOZXRNb3MgVGVjaG5vbG9neSBNQ1M5OTkwIFBDSWUgdG8gNOKAkFBvcnQgVVNC
IDIuMCBIb3N0IENvbnRyb2xsZXIgWzk3MTA6OTk5MF0gKHByb2ctaWYgMTAgW09IQ0ldKQ0K
CVN1YnN5c3RlbTogRGV2aWNlIFthMDAwOjQwMDBdDQoJQ29udHJvbDogSS9PLSBNZW0rIEJ1
c01hc3RlcisgU3BlY0N5Y2xlLSBNZW1XSU5WLSBWR0FTbm9vcC0gUGFyRXJyLSBTdGVwcGlu
Zy0gU0VSUi0gRmFzdEIyQi0gRGlzSU5UeC0NCglTdGF0dXM6IENhcCsgNjZNSHotIFVERi0g
RmFzdEIyQi0gUGFyRXJyLSBERVZTRUw9ZmFzdCA+VEFib3J0LSA8VEFib3J0KyA8TUFib3J0
LSA+U0VSUi0gPFBFUlItIElOVHgtDQoJTGF0ZW5jeTogMCwgQ2FjaGUgTGluZSBTaXplOiA2
NCBieXRlcw0KCUludGVycnVwdDogcGluIEIgcm91dGVkIHRvIElSUSAyOQ0KCVJlZ2lvbiAw
OiBNZW1vcnkgYXQgZjlmZmEwMDAgKDMyLWJpdCwgbm9uLXByZWZldGNoYWJsZSkgW3NpemU9
NEtdDQoJQ2FwYWJpbGl0aWVzOiBbNTBdIE1TSTogRW5hYmxlLSBDb3VudD0xLzEgTWFza2Fi
bGUtIDY0Yml0Kw0KCQlBZGRyZXNzOiAwMDAwMDAwMDAwMDAwMDAwICBEYXRhOiAwMDAwDQoJ
Q2FwYWJpbGl0aWVzOiBbNzhdIFBvd2VyIE1hbmFnZW1lbnQgdmVyc2lvbiAzDQoJCUZsYWdz
OiBQTUVDbGstIERTSS0gRDErIEQyKyBBdXhDdXJyZW50PTM3NW1BIFBNRShEMCssRDErLEQy
KyxEM2hvdCssRDNjb2xkLSkNCgkJU3RhdHVzOiBEMCBOb1NvZnRSc3QrIFBNRS1FbmFibGUt
IERTZWw9MCBEU2NhbGU9MCBQTUUtDQoJQ2FwYWJpbGl0aWVzOiBbODBdIEV4cHJlc3MgKHYx
KSBFbmRwb2ludCwgTVNJIDAwDQoJCURldkNhcDoJTWF4UGF5bG9hZCAyNTYgYnl0ZXMsIFBo
YW50RnVuYyAwLCBMYXRlbmN5IEwwcyB1bmxpbWl0ZWQsIEwxIHVubGltaXRlZA0KCQkJRXh0
VGFnLSBBdHRuQnRuLSBBdHRuSW5kLSBQd3JJbmQtIFJCRSsgRkxSZXNldC0NCgkJRGV2Q3Rs
OglSZXBvcnQgZXJyb3JzOiBDb3JyZWN0YWJsZS0gTm9uLUZhdGFsLSBGYXRhbC0gVW5zdXBw
b3J0ZWQtDQoJCQlSbHhkT3JkLSBFeHRUYWctIFBoYW50RnVuYy0gQXV4UHdyLSBOb1Nub29w
Kw0KCQkJTWF4UGF5bG9hZCAxMjggYnl0ZXMsIE1heFJlYWRSZXEgNTEyIGJ5dGVzDQoJCURl
dlN0YToJQ29yckVyci0gVW5jb3JyRXJyLSBGYXRhbEVyci0gVW5zdXBwUmVxLSBBdXhQd3It
IFRyYW5zUGVuZC0NCgkJTG5rQ2FwOglQb3J0ICMxLCBTcGVlZCAyLjVHVC9zLCBXaWR0aCB4
MSwgQVNQTSB1bmtub3duLCBMYXRlbmN5IEwwIDw2NG5zLCBMMSB1bmxpbWl0ZWQNCgkJCUNs
b2NrUE0rIFN1cnByaXNlLSBMTEFjdFJlcC0gQndOb3QtDQoJCUxua0N0bDoJQVNQTSBEaXNh
YmxlZDsgUkNCIDY0IGJ5dGVzIERpc2FibGVkLSBSZXRyYWluLSBDb21tQ2xrLQ0KCQkJRXh0
U3luY2gtIENsb2NrUE0tIEF1dFdpZERpcy0gQldJbnQtIEF1dEJXSW50LQ0KCQlMbmtTdGE6
CVNwZWVkIDIuNUdUL3MsIFdpZHRoIHgxLCBUckVyci0gVHJhaW4tIFNsb3RDbGstIERMQWN0
aXZlLSBCV01nbXQtIEFCV01nbXQtDQoJS2VybmVsIGRyaXZlciBpbiB1c2U6IHBjaWJhY2sN
Cg0KMGE6MDAuMyBVU0IgY29udHJvbGxlciBbMGMwM106IE5ldE1vcyBUZWNobm9sb2d5IE1D
Uzk5OTAgUENJZSB0byA04oCQUG9ydCBVU0IgMi4wIEhvc3QgQ29udHJvbGxlciBbOTcxMDo5
OTkwXSAocHJvZy1pZiAyMCBbRUhDSV0pDQoJU3Vic3lzdGVtOiBEZXZpY2UgW2EwMDA6NDAw
MF0NCglDb250cm9sOiBJL08tIE1lbSsgQnVzTWFzdGVyKyBTcGVjQ3ljbGUtIE1lbVdJTlYt
IFZHQVNub29wLSBQYXJFcnItIFN0ZXBwaW5nLSBTRVJSLSBGYXN0QjJCLSBEaXNJTlR4LQ0K
CVN0YXR1czogQ2FwKyA2Nk1Iei0gVURGLSBGYXN0QjJCLSBQYXJFcnItIERFVlNFTD1mYXN0
ID5UQWJvcnQtIDxUQWJvcnQrIDxNQWJvcnQtID5TRVJSLSA8UEVSUi0gSU5UeC0NCglMYXRl
bmN5OiAwLCBDYWNoZSBMaW5lIFNpemU6IDY0IGJ5dGVzDQoJSW50ZXJydXB0OiBwaW4gQiBy
b3V0ZWQgdG8gSVJRIDI5DQoJUmVnaW9uIDA6IE1lbW9yeSBhdCBmOWZmYjAwMCAoMzItYml0
LCBub24tcHJlZmV0Y2hhYmxlKSBbc2l6ZT00S10NCglDYXBhYmlsaXRpZXM6IFs1MF0gTVNJ
OiBFbmFibGUtIENvdW50PTEvMSBNYXNrYWJsZS0gNjRiaXQrDQoJCUFkZHJlc3M6IDAwMDAw
MDAwMDAwMDAwMDAgIERhdGE6IDAwMDANCglDYXBhYmlsaXRpZXM6IFs3OF0gUG93ZXIgTWFu
YWdlbWVudCB2ZXJzaW9uIDMNCgkJRmxhZ3M6IFBNRUNsay0gRFNJLSBEMSsgRDIrIEF1eEN1
cnJlbnQ9Mzc1bUEgUE1FKEQwKyxEMSssRDIrLEQzaG90KyxEM2NvbGQtKQ0KCQlTdGF0dXM6
IEQwIE5vU29mdFJzdCsgUE1FLUVuYWJsZS0gRFNlbD0wIERTY2FsZT0wIFBNRS0NCglDYXBh
YmlsaXRpZXM6IFs4MF0gRXhwcmVzcyAodjEpIEVuZHBvaW50LCBNU0kgMDANCgkJRGV2Q2Fw
OglNYXhQYXlsb2FkIDI1NiBieXRlcywgUGhhbnRGdW5jIDAsIExhdGVuY3kgTDBzIHVubGlt
aXRlZCwgTDEgdW5saW1pdGVkDQoJCQlFeHRUYWctIEF0dG5CdG4tIEF0dG5JbmQtIFB3cklu
ZC0gUkJFKyBGTFJlc2V0LQ0KCQlEZXZDdGw6CVJlcG9ydCBlcnJvcnM6IENvcnJlY3RhYmxl
LSBOb24tRmF0YWwtIEZhdGFsLSBVbnN1cHBvcnRlZC0NCgkJCVJseGRPcmQtIEV4dFRhZy0g
UGhhbnRGdW5jLSBBdXhQd3ItIE5vU25vb3ArDQoJCQlNYXhQYXlsb2FkIDEyOCBieXRlcywg
TWF4UmVhZFJlcSA1MTIgYnl0ZXMNCgkJRGV2U3RhOglDb3JyRXJyLSBVbmNvcnJFcnItIEZh
dGFsRXJyLSBVbnN1cHBSZXEtIEF1eFB3ci0gVHJhbnNQZW5kLQ0KCQlMbmtDYXA6CVBvcnQg
IzEsIFNwZWVkIDIuNUdUL3MsIFdpZHRoIHgxLCBBU1BNIHVua25vd24sIExhdGVuY3kgTDAg
PDY0bnMsIEwxIHVubGltaXRlZA0KCQkJQ2xvY2tQTSsgU3VycHJpc2UtIExMQWN0UmVwLSBC
d05vdC0NCgkJTG5rQ3RsOglBU1BNIERpc2FibGVkOyBSQ0IgNjQgYnl0ZXMgRGlzYWJsZWQt
IFJldHJhaW4tIENvbW1DbGstDQoJCQlFeHRTeW5jaC0gQ2xvY2tQTS0gQXV0V2lkRGlzLSBC
V0ludC0gQXV0QldJbnQtDQoJCUxua1N0YToJU3BlZWQgMi41R1QvcywgV2lkdGggeDEsIFRy
RXJyLSBUcmFpbi0gU2xvdENsay0gRExBY3RpdmUtIEJXTWdtdC0gQUJXTWdtdC0NCglLZXJu
ZWwgZHJpdmVyIGluIHVzZTogcGNpYmFjaw0KDQowYTowMC40IFVTQiBjb250cm9sbGVyIFsw
YzAzXTogTmV0TW9zIFRlY2hub2xvZ3kgTUNTOTk5MCBQQ0llIHRvIDTigJBQb3J0IFVTQiAy
LjAgSG9zdCBDb250cm9sbGVyIFs5NzEwOjk5OTBdIChwcm9nLWlmIDEwIFtPSENJXSkNCglT
dWJzeXN0ZW06IERldmljZSBbYTAwMDo0MDAwXQ0KCUNvbnRyb2w6IEkvTy0gTWVtKyBCdXNN
YXN0ZXIrIFNwZWNDeWNsZS0gTWVtV0lOVi0gVkdBU25vb3AtIFBhckVyci0gU3RlcHBpbmct
IFNFUlItIEZhc3RCMkItIERpc0lOVHgtDQoJU3RhdHVzOiBDYXArIDY2TUh6LSBVREYtIEZh
c3RCMkItIFBhckVyci0gREVWU0VMPWZhc3QgPlRBYm9ydC0gPFRBYm9ydCsgPE1BYm9ydC0g
PlNFUlItIDxQRVJSLSBJTlR4LQ0KCUxhdGVuY3k6IDAsIENhY2hlIExpbmUgU2l6ZTogNjQg
Ynl0ZXMNCglJbnRlcnJ1cHQ6IHBpbiBDIHJvdXRlZCB0byBJUlEgMzANCglSZWdpb24gMDog
TWVtb3J5IGF0IGY5ZmZjMDAwICgzMi1iaXQsIG5vbi1wcmVmZXRjaGFibGUpIFtzaXplPTRL
XQ0KCUNhcGFiaWxpdGllczogWzUwXSBNU0k6IEVuYWJsZS0gQ291bnQ9MS8xIE1hc2thYmxl
LSA2NGJpdCsNCgkJQWRkcmVzczogMDAwMDAwMDAwMDAwMDAwMCAgRGF0YTogMDAwMA0KCUNh
cGFiaWxpdGllczogWzc4XSBQb3dlciBNYW5hZ2VtZW50IHZlcnNpb24gMw0KCQlGbGFnczog
UE1FQ2xrLSBEU0ktIEQxKyBEMisgQXV4Q3VycmVudD0zNzVtQSBQTUUoRDArLEQxKyxEMiss
RDNob3QrLEQzY29sZC0pDQoJCVN0YXR1czogRDAgTm9Tb2Z0UnN0KyBQTUUtRW5hYmxlLSBE
U2VsPTAgRFNjYWxlPTAgUE1FLQ0KCUNhcGFiaWxpdGllczogWzgwXSBFeHByZXNzICh2MSkg
RW5kcG9pbnQsIE1TSSAwMA0KCQlEZXZDYXA6CU1heFBheWxvYWQgMjU2IGJ5dGVzLCBQaGFu
dEZ1bmMgMCwgTGF0ZW5jeSBMMHMgdW5saW1pdGVkLCBMMSB1bmxpbWl0ZWQNCgkJCUV4dFRh
Zy0gQXR0bkJ0bi0gQXR0bkluZC0gUHdySW5kLSBSQkUrIEZMUmVzZXQtDQoJCURldkN0bDoJ
UmVwb3J0IGVycm9yczogQ29ycmVjdGFibGUtIE5vbi1GYXRhbC0gRmF0YWwtIFVuc3VwcG9y
dGVkLQ0KCQkJUmx4ZE9yZC0gRXh0VGFnLSBQaGFudEZ1bmMtIEF1eFB3ci0gTm9Tbm9vcCsN
CgkJCU1heFBheWxvYWQgMTI4IGJ5dGVzLCBNYXhSZWFkUmVxIDUxMiBieXRlcw0KCQlEZXZT
dGE6CUNvcnJFcnItIFVuY29yckVyci0gRmF0YWxFcnItIFVuc3VwcFJlcS0gQXV4UHdyLSBU
cmFuc1BlbmQtDQoJCUxua0NhcDoJUG9ydCAjMSwgU3BlZWQgMi41R1QvcywgV2lkdGggeDEs
IEFTUE0gdW5rbm93biwgTGF0ZW5jeSBMMCA8NjRucywgTDEgdW5saW1pdGVkDQoJCQlDbG9j
a1BNKyBTdXJwcmlzZS0gTExBY3RSZXAtIEJ3Tm90LQ0KCQlMbmtDdGw6CUFTUE0gRGlzYWJs
ZWQ7IFJDQiA2NCBieXRlcyBEaXNhYmxlZC0gUmV0cmFpbi0gQ29tbUNsay0NCgkJCUV4dFN5
bmNoLSBDbG9ja1BNLSBBdXRXaWREaXMtIEJXSW50LSBBdXRCV0ludC0NCgkJTG5rU3RhOglT
cGVlZCAyLjVHVC9zLCBXaWR0aCB4MSwgVHJFcnItIFRyYWluLSBTbG90Q2xrLSBETEFjdGl2
ZS0gQldNZ210LSBBQldNZ210LQ0KCUtlcm5lbCBkcml2ZXIgaW4gdXNlOiBwY2liYWNrDQoN
CjBhOjAwLjUgVVNCIGNvbnRyb2xsZXIgWzBjMDNdOiBOZXRNb3MgVGVjaG5vbG9neSBNQ1M5
OTkwIFBDSWUgdG8gNOKAkFBvcnQgVVNCIDIuMCBIb3N0IENvbnRyb2xsZXIgWzk3MTA6OTk5
MF0gKHByb2ctaWYgMjAgW0VIQ0ldKQ0KCVN1YnN5c3RlbTogRGV2aWNlIFthMDAwOjQwMDBd
DQoJQ29udHJvbDogSS9PLSBNZW0rIEJ1c01hc3RlcisgU3BlY0N5Y2xlLSBNZW1XSU5WLSBW
R0FTbm9vcC0gUGFyRXJyLSBTdGVwcGluZy0gU0VSUi0gRmFzdEIyQi0gRGlzSU5UeC0NCglT
dGF0dXM6IENhcCsgNjZNSHotIFVERi0gRmFzdEIyQi0gUGFyRXJyLSBERVZTRUw9ZmFzdCA+
VEFib3J0LSA8VEFib3J0KyA8TUFib3J0LSA+U0VSUi0gPFBFUlItIElOVHgtDQoJTGF0ZW5j
eTogMCwgQ2FjaGUgTGluZSBTaXplOiA2NCBieXRlcw0KCUludGVycnVwdDogcGluIEMgcm91
dGVkIHRvIElSUSAzMA0KCVJlZ2lvbiAwOiBNZW1vcnkgYXQgZjlmZmQwMDAgKDMyLWJpdCwg
bm9uLXByZWZldGNoYWJsZSkgW3NpemU9NEtdDQoJQ2FwYWJpbGl0aWVzOiBbNTBdIE1TSTog
RW5hYmxlLSBDb3VudD0xLzEgTWFza2FibGUtIDY0Yml0Kw0KCQlBZGRyZXNzOiAwMDAwMDAw
MDAwMDAwMDAwICBEYXRhOiAwMDAwDQoJQ2FwYWJpbGl0aWVzOiBbNzhdIFBvd2VyIE1hbmFn
ZW1lbnQgdmVyc2lvbiAzDQoJCUZsYWdzOiBQTUVDbGstIERTSS0gRDErIEQyKyBBdXhDdXJy
ZW50PTM3NW1BIFBNRShEMCssRDErLEQyKyxEM2hvdCssRDNjb2xkLSkNCgkJU3RhdHVzOiBE
MCBOb1NvZnRSc3QrIFBNRS1FbmFibGUtIERTZWw9MCBEU2NhbGU9MCBQTUUtDQoJQ2FwYWJp
bGl0aWVzOiBbODBdIEV4cHJlc3MgKHYxKSBFbmRwb2ludCwgTVNJIDAwDQoJCURldkNhcDoJ
TWF4UGF5bG9hZCAyNTYgYnl0ZXMsIFBoYW50RnVuYyAwLCBMYXRlbmN5IEwwcyB1bmxpbWl0
ZWQsIEwxIHVubGltaXRlZA0KCQkJRXh0VGFnLSBBdHRuQnRuLSBBdHRuSW5kLSBQd3JJbmQt
IFJCRSsgRkxSZXNldC0NCgkJRGV2Q3RsOglSZXBvcnQgZXJyb3JzOiBDb3JyZWN0YWJsZS0g
Tm9uLUZhdGFsLSBGYXRhbC0gVW5zdXBwb3J0ZWQtDQoJCQlSbHhkT3JkLSBFeHRUYWctIFBo
YW50RnVuYy0gQXV4UHdyLSBOb1Nub29wKw0KCQkJTWF4UGF5bG9hZCAxMjggYnl0ZXMsIE1h
eFJlYWRSZXEgNTEyIGJ5dGVzDQoJCURldlN0YToJQ29yckVyci0gVW5jb3JyRXJyLSBGYXRh
bEVyci0gVW5zdXBwUmVxLSBBdXhQd3ItIFRyYW5zUGVuZC0NCgkJTG5rQ2FwOglQb3J0ICMx
LCBTcGVlZCAyLjVHVC9zLCBXaWR0aCB4MSwgQVNQTSB1bmtub3duLCBMYXRlbmN5IEwwIDw2
NG5zLCBMMSB1bmxpbWl0ZWQNCgkJCUNsb2NrUE0rIFN1cnByaXNlLSBMTEFjdFJlcC0gQndO
b3QtDQoJCUxua0N0bDoJQVNQTSBEaXNhYmxlZDsgUkNCIDY0IGJ5dGVzIERpc2FibGVkLSBS
ZXRyYWluLSBDb21tQ2xrLQ0KCQkJRXh0U3luY2gtIENsb2NrUE0tIEF1dFdpZERpcy0gQldJ
bnQtIEF1dEJXSW50LQ0KCQlMbmtTdGE6CVNwZWVkIDIuNUdUL3MsIFdpZHRoIHgxLCBUckVy
ci0gVHJhaW4tIFNsb3RDbGstIERMQWN0aXZlLSBCV01nbXQtIEFCV01nbXQtDQoJS2VybmVs
IGRyaXZlciBpbiB1c2U6IHBjaWJhY2sNCg0KMGE6MDAuNiBVU0IgY29udHJvbGxlciBbMGMw
M106IE5ldE1vcyBUZWNobm9sb2d5IE1DUzk5OTAgUENJZSB0byA04oCQUG9ydCBVU0IgMi4w
IEhvc3QgQ29udHJvbGxlciBbOTcxMDo5OTkwXSAocHJvZy1pZiAxMCBbT0hDSV0pDQoJU3Vi
c3lzdGVtOiBEZXZpY2UgW2EwMDA6NDAwMF0NCglDb250cm9sOiBJL08tIE1lbSsgQnVzTWFz
dGVyKyBTcGVjQ3ljbGUtIE1lbVdJTlYtIFZHQVNub29wLSBQYXJFcnItIFN0ZXBwaW5nLSBT
RVJSLSBGYXN0QjJCLSBEaXNJTlR4LQ0KCVN0YXR1czogQ2FwKyA2Nk1Iei0gVURGLSBGYXN0
QjJCLSBQYXJFcnItIERFVlNFTD1mYXN0ID5UQWJvcnQtIDxUQWJvcnQrIDxNQWJvcnQtID5T
RVJSLSA8UEVSUi0gSU5UeC0NCglMYXRlbmN5OiAwLCBDYWNoZSBMaW5lIFNpemU6IDY0IGJ5
dGVzDQoJSW50ZXJydXB0OiBwaW4gRCByb3V0ZWQgdG8gSVJRIDMxDQoJUmVnaW9uIDA6IE1l
bW9yeSBhdCBmOWZmZTAwMCAoMzItYml0LCBub24tcHJlZmV0Y2hhYmxlKSBbc2l6ZT00S10N
CglDYXBhYmlsaXRpZXM6IFs1MF0gTVNJOiBFbmFibGUtIENvdW50PTEvMSBNYXNrYWJsZS0g
NjRiaXQrDQoJCUFkZHJlc3M6IDAwMDAwMDAwMDAwMDAwMDAgIERhdGE6IDAwMDANCglDYXBh
YmlsaXRpZXM6IFs3OF0gUG93ZXIgTWFuYWdlbWVudCB2ZXJzaW9uIDMNCgkJRmxhZ3M6IFBN
RUNsay0gRFNJLSBEMSsgRDIrIEF1eEN1cnJlbnQ9Mzc1bUEgUE1FKEQwKyxEMSssRDIrLEQz
aG90KyxEM2NvbGQtKQ0KCQlTdGF0dXM6IEQwIE5vU29mdFJzdCsgUE1FLUVuYWJsZS0gRFNl
bD0wIERTY2FsZT0wIFBNRS0NCglDYXBhYmlsaXRpZXM6IFs4MF0gRXhwcmVzcyAodjEpIEVu
ZHBvaW50LCBNU0kgMDANCgkJRGV2Q2FwOglNYXhQYXlsb2FkIDI1NiBieXRlcywgUGhhbnRG
dW5jIDAsIExhdGVuY3kgTDBzIHVubGltaXRlZCwgTDEgdW5saW1pdGVkDQoJCQlFeHRUYWct
IEF0dG5CdG4tIEF0dG5JbmQtIFB3ckluZC0gUkJFKyBGTFJlc2V0LQ0KCQlEZXZDdGw6CVJl
cG9ydCBlcnJvcnM6IENvcnJlY3RhYmxlLSBOb24tRmF0YWwtIEZhdGFsLSBVbnN1cHBvcnRl
ZC0NCgkJCVJseGRPcmQtIEV4dFRhZy0gUGhhbnRGdW5jLSBBdXhQd3ItIE5vU25vb3ArDQoJ
CQlNYXhQYXlsb2FkIDEyOCBieXRlcywgTWF4UmVhZFJlcSA1MTIgYnl0ZXMNCgkJRGV2U3Rh
OglDb3JyRXJyLSBVbmNvcnJFcnItIEZhdGFsRXJyLSBVbnN1cHBSZXEtIEF1eFB3ci0gVHJh
bnNQZW5kLQ0KCQlMbmtDYXA6CVBvcnQgIzEsIFNwZWVkIDIuNUdUL3MsIFdpZHRoIHgxLCBB
U1BNIHVua25vd24sIExhdGVuY3kgTDAgPDY0bnMsIEwxIHVubGltaXRlZA0KCQkJQ2xvY2tQ
TSsgU3VycHJpc2UtIExMQWN0UmVwLSBCd05vdC0NCgkJTG5rQ3RsOglBU1BNIERpc2FibGVk
OyBSQ0IgNjQgYnl0ZXMgRGlzYWJsZWQtIFJldHJhaW4tIENvbW1DbGstDQoJCQlFeHRTeW5j
aC0gQ2xvY2tQTS0gQXV0V2lkRGlzLSBCV0ludC0gQXV0QldJbnQtDQoJCUxua1N0YToJU3Bl
ZWQgMi41R1QvcywgV2lkdGggeDEsIFRyRXJyLSBUcmFpbi0gU2xvdENsay0gRExBY3RpdmUt
IEJXTWdtdC0gQUJXTWdtdC0NCglLZXJuZWwgZHJpdmVyIGluIHVzZTogcGNpYmFjaw0KDQow
YTowMC43IFVTQiBjb250cm9sbGVyIFswYzAzXTogTmV0TW9zIFRlY2hub2xvZ3kgTUNTOTk5
MCBQQ0llIHRvIDTigJBQb3J0IFVTQiAyLjAgSG9zdCBDb250cm9sbGVyIFs5NzEwOjk5OTBd
IChwcm9nLWlmIDIwIFtFSENJXSkNCglTdWJzeXN0ZW06IERldmljZSBbYTAwMDo0MDAwXQ0K
CUNvbnRyb2w6IEkvTy0gTWVtKyBCdXNNYXN0ZXIrIFNwZWNDeWNsZS0gTWVtV0lOVi0gVkdB
U25vb3AtIFBhckVyci0gU3RlcHBpbmctIFNFUlItIEZhc3RCMkItIERpc0lOVHgtDQoJU3Rh
dHVzOiBDYXArIDY2TUh6LSBVREYtIEZhc3RCMkItIFBhckVyci0gREVWU0VMPWZhc3QgPlRB
Ym9ydC0gPFRBYm9ydCsgPE1BYm9ydC0gPlNFUlItIDxQRVJSLSBJTlR4LQ0KCUxhdGVuY3k6
IDAsIENhY2hlIExpbmUgU2l6ZTogNjQgYnl0ZXMNCglJbnRlcnJ1cHQ6IHBpbiBEIHJvdXRl
ZCB0byBJUlEgMzENCglSZWdpb24gMDogTWVtb3J5IGF0IGY5ZmZmMDAwICgzMi1iaXQsIG5v
bi1wcmVmZXRjaGFibGUpIFtzaXplPTRLXQ0KCUNhcGFiaWxpdGllczogWzUwXSBNU0k6IEVu
YWJsZS0gQ291bnQ9MS8xIE1hc2thYmxlLSA2NGJpdCsNCgkJQWRkcmVzczogMDAwMDAwMDAw
MDAwMDAwMCAgRGF0YTogMDAwMA0KCUNhcGFiaWxpdGllczogWzc4XSBQb3dlciBNYW5hZ2Vt
ZW50IHZlcnNpb24gMw0KCQlGbGFnczogUE1FQ2xrLSBEU0ktIEQxKyBEMisgQXV4Q3VycmVu
dD0zNzVtQSBQTUUoRDArLEQxKyxEMissRDNob3QrLEQzY29sZC0pDQoJCVN0YXR1czogRDAg
Tm9Tb2Z0UnN0KyBQTUUtRW5hYmxlLSBEU2VsPTAgRFNjYWxlPTAgUE1FLQ0KCUNhcGFiaWxp
dGllczogWzgwXSBFeHByZXNzICh2MSkgRW5kcG9pbnQsIE1TSSAwMA0KCQlEZXZDYXA6CU1h
eFBheWxvYWQgMjU2IGJ5dGVzLCBQaGFudEZ1bmMgMCwgTGF0ZW5jeSBMMHMgdW5saW1pdGVk
LCBMMSB1bmxpbWl0ZWQNCgkJCUV4dFRhZy0gQXR0bkJ0bi0gQXR0bkluZC0gUHdySW5kLSBS
QkUrIEZMUmVzZXQtDQoJCURldkN0bDoJUmVwb3J0IGVycm9yczogQ29ycmVjdGFibGUtIE5v
bi1GYXRhbC0gRmF0YWwtIFVuc3VwcG9ydGVkLQ0KCQkJUmx4ZE9yZC0gRXh0VGFnLSBQaGFu
dEZ1bmMtIEF1eFB3ci0gTm9Tbm9vcCsNCgkJCU1heFBheWxvYWQgMTI4IGJ5dGVzLCBNYXhS
ZWFkUmVxIDUxMiBieXRlcw0KCQlEZXZTdGE6CUNvcnJFcnItIFVuY29yckVyci0gRmF0YWxF
cnItIFVuc3VwcFJlcS0gQXV4UHdyLSBUcmFuc1BlbmQtDQoJCUxua0NhcDoJUG9ydCAjMSwg
U3BlZWQgMi41R1QvcywgV2lkdGggeDEsIEFTUE0gdW5rbm93biwgTGF0ZW5jeSBMMCA8NjRu
cywgTDEgdW5saW1pdGVkDQoJCQlDbG9ja1BNKyBTdXJwcmlzZS0gTExBY3RSZXAtIEJ3Tm90
LQ0KCQlMbmtDdGw6CUFTUE0gRGlzYWJsZWQ7IFJDQiA2NCBieXRlcyBEaXNhYmxlZC0gUmV0
cmFpbi0gQ29tbUNsay0NCgkJCUV4dFN5bmNoLSBDbG9ja1BNLSBBdXRXaWREaXMtIEJXSW50
LSBBdXRCV0ludC0NCgkJTG5rU3RhOglTcGVlZCAyLjVHVC9zLCBXaWR0aCB4MSwgVHJFcnIt
IFRyYWluLSBTbG90Q2xrLSBETEFjdGl2ZS0gQldNZ210LSBBQldNZ210LQ0KCUtlcm5lbCBk
cml2ZXIgaW4gdXNlOiBwY2liYWNrDQoNCjBiOjAwLjAgVkdBIGNvbXBhdGlibGUgY29udHJv
bGxlciBbMDMwMF06IG5WaWRpYSBDb3Jwb3JhdGlvbiBHOTggW0dlRm9yY2UgODQwMCBHU10g
WzEwZGU6MDZlNF0gKHJldiBhMSkgKHByb2ctaWYgMDAgW1ZHQSBjb250cm9sbGVyXSkNCglT
dWJzeXN0ZW06IEFTVVNUZUsgQ29tcHV0ZXIgSW5jLiBEZXZpY2UgWzEwNDM6ODI2Nl0NCglD
b250cm9sOiBJL08rIE1lbSsgQnVzTWFzdGVyKyBTcGVjQ3ljbGUtIE1lbVdJTlYtIFZHQVNu
b29wLSBQYXJFcnItIFN0ZXBwaW5nLSBTRVJSKyBGYXN0QjJCLSBEaXNJTlR4LQ0KCVN0YXR1
czogQ2FwKyA2Nk1Iei0gVURGLSBGYXN0QjJCLSBQYXJFcnItIERFVlNFTD1mYXN0ID5UQWJv
cnQtIDxUQWJvcnQtIDxNQWJvcnQtID5TRVJSLSA8UEVSUi0gSU5UeC0NCglMYXRlbmN5OiAw
LCBDYWNoZSBMaW5lIFNpemU6IDY0IGJ5dGVzDQoJSW50ZXJydXB0OiBwaW4gQSByb3V0ZWQg
dG8gSVJRIDEwDQoJUmVnaW9uIDA6IE1lbW9yeSBhdCBmZDAwMDAwMCAoMzItYml0LCBub24t
cHJlZmV0Y2hhYmxlKSBbc2l6ZT0xNk1dDQoJUmVnaW9uIDE6IE1lbW9yeSBhdCBkMDAwMDAw
MCAoNjQtYml0LCBwcmVmZXRjaGFibGUpIFtzaXplPTI1Nk1dDQoJUmVnaW9uIDM6IE1lbW9y
eSBhdCBmYTAwMDAwMCAoNjQtYml0LCBub24tcHJlZmV0Y2hhYmxlKSBbc2l6ZT0zMk1dDQoJ
UmVnaW9uIDU6IEkvTyBwb3J0cyBhdCBlODAwIFtzaXplPTEyOF0NCglFeHBhbnNpb24gUk9N
IGF0IGZlOWUwMDAwIFtkaXNhYmxlZF0gW3NpemU9MTI4S10NCglDYXBhYmlsaXRpZXM6IFs2
MF0gUG93ZXIgTWFuYWdlbWVudCB2ZXJzaW9uIDMNCgkJRmxhZ3M6IFBNRUNsay0gRFNJLSBE
MS0gRDItIEF1eEN1cnJlbnQ9MG1BIFBNRShEMC0sRDEtLEQyLSxEM2hvdC0sRDNjb2xkLSkN
CgkJU3RhdHVzOiBEMCBOb1NvZnRSc3QrIFBNRS1FbmFibGUtIERTZWw9MCBEU2NhbGU9MCBQ
TUUtDQoJQ2FwYWJpbGl0aWVzOiBbNjhdIE1TSTogRW5hYmxlLSBDb3VudD0xLzEgTWFza2Fi
bGUtIDY0Yml0Kw0KCQlBZGRyZXNzOiAwMDAwMDAwMDAwMDAwMDAwICBEYXRhOiAwMDAwDQoJ
Q2FwYWJpbGl0aWVzOiBbNzhdIEV4cHJlc3MgKHYxKSBFbmRwb2ludCwgTVNJIDAwDQoJCURl
dkNhcDoJTWF4UGF5bG9hZCAxMjggYnl0ZXMsIFBoYW50RnVuYyAwLCBMYXRlbmN5IEwwcyA8
NTEybnMsIEwxIDw0dXMNCgkJCUV4dFRhZysgQXR0bkJ0bi0gQXR0bkluZC0gUHdySW5kLSBS
QkUrIEZMUmVzZXQtDQoJCURldkN0bDoJUmVwb3J0IGVycm9yczogQ29ycmVjdGFibGUtIE5v
bi1GYXRhbC0gRmF0YWwtIFVuc3VwcG9ydGVkLQ0KCQkJUmx4ZE9yZC0gRXh0VGFnLSBQaGFu
dEZ1bmMtIEF1eFB3ci0gTm9Tbm9vcCsNCgkJCU1heFBheWxvYWQgMTI4IGJ5dGVzLCBNYXhS
ZWFkUmVxIDUxMiBieXRlcw0KCQlEZXZTdGE6CUNvcnJFcnItIFVuY29yckVyci0gRmF0YWxF
cnItIFVuc3VwcFJlcS0gQXV4UHdyLSBUcmFuc1BlbmQtDQoJCUxua0NhcDoJUG9ydCAjMCwg
U3BlZWQgMi41R1QvcywgV2lkdGggeDE2LCBBU1BNIEwwcyBMMSwgTGF0ZW5jeSBMMCA8NTEy
bnMsIEwxIDwxdXMNCgkJCUNsb2NrUE0tIFN1cnByaXNlLSBMTEFjdFJlcC0gQndOb3QtDQoJ
CUxua0N0bDoJQVNQTSBEaXNhYmxlZDsgUkNCIDEyOCBieXRlcyBEaXNhYmxlZC0gUmV0cmFp
bi0gQ29tbUNsaysNCgkJCUV4dFN5bmNoLSBDbG9ja1BNLSBBdXRXaWREaXMtIEJXSW50LSBB
dXRCV0ludC0NCgkJTG5rU3RhOglTcGVlZCAyLjVHVC9zLCBXaWR0aCB4OCwgVHJFcnItIFRy
YWluLSBTbG90Q2xrKyBETEFjdGl2ZS0gQldNZ210LSBBQldNZ210LQ0KCUNhcGFiaWxpdGll
czogWzEwMCB2MV0gVmlydHVhbCBDaGFubmVsDQoJCUNhcHM6CUxQRVZDPTAgUmVmQ2xrPTEw
MG5zIFBBVEVudHJ5Qml0cz0xDQoJCUFyYjoJRml4ZWQtIFdSUjMyLSBXUlI2NC0gV1JSMTI4
LQ0KCQlDdHJsOglBcmJTZWxlY3Q9Rml4ZWQNCgkJU3RhdHVzOglJblByb2dyZXNzLQ0KCQlW
QzA6CUNhcHM6CVBBVE9mZnNldD0wMCBNYXhUaW1lU2xvdHM9MSBSZWpTbm9vcFRyYW5zLQ0K
CQkJQXJiOglGaXhlZC0gV1JSMzItIFdSUjY0LSBXUlIxMjgtIFRXUlIxMjgtIFdSUjI1Ni0N
CgkJCUN0cmw6CUVuYWJsZSsgSUQ9MCBBcmJTZWxlY3Q9Rml4ZWQgVEMvVkM9ZmYNCgkJCVN0
YXR1czoJTmVnb1BlbmRpbmctIEluUHJvZ3Jlc3MtDQoJQ2FwYWJpbGl0aWVzOiBbMTI4IHYx
XSBQb3dlciBCdWRnZXRpbmcgPD8+DQoJQ2FwYWJpbGl0aWVzOiBbNjAwIHYxXSBWZW5kb3Ig
U3BlY2lmaWMgSW5mb3JtYXRpb246IElEPTAwMDEgUmV2PTEgTGVuPTAyNCA8Pz4NCg0K
------------0E902503E1C6BF83E
Content-Type: text/plain;
 name="xl-dmesg-4.2.txt"
Content-transfer-encoding: base64
Content-Disposition: attachment;
 filename="xl-dmesg-4.2.txt"

IF9fICBfXyAgICAgICAgICAgIF8gIF8gICAgX19fXyAgICBfX18gICAgICAgICAgICAgIF8g
IF8gICAgICAgICAgICAgICAgICAgICANCiBcIFwvIC9fX18gXyBfXyAgIHwgfHwgfCAgfF9f
XyBcICAvIF8gXCAgICBfIF9fIF9fX3wgfHwgfCAgICAgXyBfXyAgXyBfXyBfX18gDQogIFwg
IC8vIF8gXCAnXyBcICB8IHx8IHxfICAgX18pIHx8IHwgfCB8X198ICdfXy8gX198IHx8IHxf
IF9ffCAnXyBcfCAnX18vIF8gXA0KICAvICBcICBfXy8gfCB8IHwgfF9fICAgX3wgLyBfXy8g
fCB8X3wgfF9ffCB8IHwgKF9ffF9fICAgX3xfX3wgfF8pIHwgfCB8ICBfXy8NCiAvXy9cX1xf
X198X3wgfF98ICAgIHxffChfKV9fX19fKF8pX19fLyAgIHxffCAgXF9fX3wgIHxffCAgICB8
IC5fXy98X3wgIFxfX198DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgfF98ICAgICAgICAgICAgIA0KKFhFTikgWGVuIHZl
cnNpb24gNC4yLjAtcmM0LXByZSAocm9vdEBkeW5kbnMub3JnKSAoZ2NjIChEZWJpYW4gNC40
LjUtOCkgNC40LjUpIFdlZCBTZXAgIDUgMTc6MjY6NDAgQ0VTVCAyMDEyDQooWEVOKSBMYXRl
c3QgQ2hhbmdlU2V0OiBUdWUgQXVnIDI4IDIyOjQwOjQ1IDIwMTIgKzAxMDAgMjU3ODY6YTBi
NWY4MTAyYTAwDQooWEVOKSBCb290bG9hZGVyOiBHUlVCIDEuOTgrMjAxMDA4MDQtMTQrc3F1
ZWV6ZTENCihYRU4pIENvbW1hbmQgbGluZTogZG9tMF9tZW09MTAyNE0sbWF4OjEwMjRNIGxv
Z2x2bD1hbGwgbG9nbHZsX2d1ZXN0PWFsbCBjb25zb2xlX3RpbWVzdGFtcHMgdmdhPWdmeC0x
MjgweDEwMjR4MzIgY3B1aWRsZSBjcHVmcmVxPXhlbiBub3JlYm9vdCBkZWJ1ZyBsYXBpYz1k
ZWJ1ZyBhcGljX3ZlcmJvc2l0eT1kZWJ1ZyBhcGljPWRlYnVnIGlvbW11PW9uLHZlcmJvc2Us
ZGVidWcgY29tMT0zODQwMCw4bjEgY29uc29sZT12Z2EsY29tMQ0KKFhFTikgVmlkZW8gaW5m
b3JtYXRpb246DQooWEVOKSAgVkdBIGlzIGdyYXBoaWNzIG1vZGUgMTI4MHgxMDI0LCAzMiBi
cHANCihYRU4pICBWQkUvRERDIG1ldGhvZHM6IFYyOyBFRElEIHRyYW5zZmVyIHRpbWU6IDEg
c2Vjb25kcw0KKFhFTikgRGlzYyBpbmZvcm1hdGlvbjoNCihYRU4pICBGb3VuZCAyIE1CUiBz
aWduYXR1cmVzDQooWEVOKSAgRm91bmQgMiBFREQgaW5mb3JtYXRpb24gc3RydWN0dXJlcw0K
KFhFTikgWGVuLWU4MjAgUkFNIG1hcDoNCihYRU4pICAwMDAwMDAwMDAwMDAwMDAwIC0gMDAw
MDAwMDAwMDA5YjAwMCAodXNhYmxlKQ0KKFhFTikgIDAwMDAwMDAwMDAwOWIwMDAgLSAwMDAw
MDAwMDAwMGEwMDAwIChyZXNlcnZlZCkNCihYRU4pICAwMDAwMDAwMDAwMGU0MDAwIC0gMDAw
MDAwMDAwMDEwMDAwMCAocmVzZXJ2ZWQpDQooWEVOKSAgMDAwMDAwMDAwMDEwMDAwMCAtIDAw
MDAwMDAwYWZlOTAwMDAgKHVzYWJsZSkNCihYRU4pICAwMDAwMDAwMGFmZTkwMDAwIC0gMDAw
MDAwMDBhZmU5ZTAwMCAoQUNQSSBkYXRhKQ0KKFhFTikgIDAwMDAwMDAwYWZlOWUwMDAgLSAw
MDAwMDAwMGFmZWUwMDAwIChBQ1BJIE5WUykNCihYRU4pICAwMDAwMDAwMGFmZWUwMDAwIC0g
MDAwMDAwMDBhZmYwMDAwMCAocmVzZXJ2ZWQpDQooWEVOKSAgMDAwMDAwMDBmZmUwMDAwMCAt
IDAwMDAwMDAxMDAwMDAwMDAgKHJlc2VydmVkKQ0KKFhFTikgIDAwMDAwMDAxMDAwMDAwMDAg
LSAwMDAwMDAwMjUwMDAwMDAwICh1c2FibGUpDQooWEVOKSBBQ1BJOiBSU0RQIDAwMEZCMTIw
LCAwMDE0IChyMCBBQ1BJQU0pDQooWEVOKSBBQ1BJOiBSU0RUIEFGRTkwMDAwLCAwMDQ4IChy
MSBNU0kgICAgT0VNU0xJQyAgMjAxMDA2MjIgTVNGVCAgICAgICA5NykNCihYRU4pIEFDUEk6
IEZBQ1AgQUZFOTAyMDAsIDAwODQgKHIxIDc2NDBNUyBBNzY0MDEwMCAyMDEwMDYyMiBNU0ZU
ICAgICAgIDk3KQ0KKFhFTikgQUNQSTogRFNEVCBBRkU5MDVFMCwgOTQ0OSAocjEgIEE3NjQw
IEE3NjQwMTAwICAgICAgMTAwIElOVEwgMjAwNTExMTcpDQooWEVOKSBBQ1BJOiBGQUNTIEFG
RTlFMDAwLCAwMDQwDQooWEVOKSBBQ1BJOiBBUElDIEFGRTkwMzkwLCAwMDg4IChyMSA3NjQw
TVMgQTc2NDAxMDAgMjAxMDA2MjIgTVNGVCAgICAgICA5NykNCihYRU4pIEFDUEk6IE1DRkcg
QUZFOTA0MjAsIDAwM0MgKHIxIDc2NDBNUyBPRU1NQ0ZHICAyMDEwMDYyMiBNU0ZUICAgICAg
IDk3KQ0KKFhFTikgQUNQSTogU0xJQyBBRkU5MDQ2MCwgMDE3NiAocjEgTVNJICAgIE9FTVNM
SUMgIDIwMTAwNjIyIE1TRlQgICAgICAgOTcpDQooWEVOKSBBQ1BJOiBPRU1CIEFGRTlFMDQw
LCAwMDcyIChyMSA3NjQwTVMgQTc2NDAxMDAgMjAxMDA2MjIgTVNGVCAgICAgICA5NykNCihY
RU4pIEFDUEk6IFNSQVQgQUZFOUE1RTAsIDAxMDggKHIzIEFNRCAgICBGQU1fRl8xMCAgICAg
ICAgMiBBTUQgICAgICAgICAxKQ0KKFhFTikgQUNQSTogSFBFVCBBRkU5QTZGMCwgMDAzOCAo
cjEgNzY0ME1TIE9FTUhQRVQgIDIwMTAwNjIyIE1TRlQgICAgICAgOTcpDQooWEVOKSBBQ1BJ
OiBJVlJTIEFGRTlBNzMwLCAwMEY4IChyMSAgQU1EICAgICBSRDg5MFMgICAyMDIwMzEgQU1E
ICAgICAgICAgMCkNCihYRU4pIEFDUEk6IFNTRFQgQUZFOUE4MzAsIDBEQTQgKHIxIEEgTSBJ
ICBQT1dFUk5PVyAgICAgICAgMSBBTUQgICAgICAgICAxKQ0KKFhFTikgU3lzdGVtIFJBTTog
ODE5ME1CICg4Mzg2NzMya0IpDQooWEVOKSBTUkFUOiBQWE0gMCAtPiBBUElDIDAgLT4gTm9k
ZSAwDQooWEVOKSBTUkFUOiBQWE0gMCAtPiBBUElDIDEgLT4gTm9kZSAwDQooWEVOKSBTUkFU
OiBQWE0gMCAtPiBBUElDIDIgLT4gTm9kZSAwDQooWEVOKSBTUkFUOiBQWE0gMCAtPiBBUElD
IDMgLT4gTm9kZSAwDQooWEVOKSBTUkFUOiBQWE0gMCAtPiBBUElDIDQgLT4gTm9kZSAwDQoo
WEVOKSBTUkFUOiBQWE0gMCAtPiBBUElDIDUgLT4gTm9kZSAwDQooWEVOKSBTUkFUOiBOb2Rl
IDAgUFhNIDAgMC1hMDAwMA0KKFhFTikgU1JBVDogTm9kZSAwIFBYTSAwIDEwMDAwMC1iMDAw
MDAwMA0KKFhFTikgU1JBVDogTm9kZSAwIFBYTSAwIDEwMDAwMDAwMC0yNTAwMDAwMDANCihY
RU4pIE5VTUE6IEFsbG9jYXRlZCBtZW1ub2RlbWFwIGZyb20gMjRkOWE0MDAwIC0gMjRkOWE3
MDAwDQooWEVOKSBOVU1BOiBVc2luZyA4IGZvciB0aGUgaGFzaCBzaGlmdC4NCihYRU4pIERv
bWFpbiBoZWFwIGluaXRpYWxpc2VkDQooWEVOKSB2ZXNhZmI6IGZyYW1lYnVmZmVyIGF0IDB4
ZmIwMDAwMDAsIG1hcHBlZCB0byAweGZmZmY4MmMwMDAwMDAwMDAsIHVzaW5nIDYxNDRrLCB0
b3RhbCAxNDMzNmsNCihYRU4pIHZlc2FmYjogbW9kZSBpcyAxMjgweDEwMjR4MzIsIGxpbmVs
ZW5ndGg9NTEyMCwgZm9udCA4eDE2DQooWEVOKSB2ZXNhZmI6IFRydWVjb2xvcjogc2l6ZT04
Ojg6ODo4LCBzaGlmdD0yNDoxNjo4OjANCihYRU4pIGZvdW5kIFNNUCBNUC10YWJsZSBhdCAw
MDBmZjc4MA0KKFhFTikgRE1JIHByZXNlbnQuDQooWEVOKSBBUElDIGJvb3Qgc3RhdGUgaXMg
J3hhcGljJw0KKFhFTikgVXNpbmcgQVBJQyBkcml2ZXIgZGVmYXVsdA0KKFhFTikgQUNQSTog
UE0tVGltZXIgSU8gUG9ydDogMHg4MDgNCihYRU4pIEFDUEk6IEFDUEkgU0xFRVAgSU5GTzog
cG0xeF9jbnRbODA0LDBdLCBwbTF4X2V2dFs4MDAsMF0NCihYRU4pIEFDUEk6ICAgICAgICAg
ICAgICAgICAgd2FrZXVwX3ZlY1thZmU5ZTAwY10sIHZlY19zaXplWzIwXQ0KKFhFTikgQUNQ
STogTG9jYWwgQVBJQyBhZGRyZXNzIDB4ZmVlMDAwMDANCihYRU4pIEFDUEk6IExBUElDIChh
Y3BpX2lkWzB4MDFdIGxhcGljX2lkWzB4MDBdIGVuYWJsZWQpDQooWEVOKSBQcm9jZXNzb3Ig
IzAgMDoxMCBBUElDIHZlcnNpb24gMTYNCihYRU4pIEFDUEk6IExBUElDIChhY3BpX2lkWzB4
MDJdIGxhcGljX2lkWzB4MDFdIGVuYWJsZWQpDQooWEVOKSBQcm9jZXNzb3IgIzEgMDoxMCBB
UElDIHZlcnNpb24gMTYNCihYRU4pIEFDUEk6IExBUElDIChhY3BpX2lkWzB4MDNdIGxhcGlj
X2lkWzB4MDJdIGVuYWJsZWQpDQooWEVOKSBQcm9jZXNzb3IgIzIgMDoxMCBBUElDIHZlcnNp
b24gMTYNCihYRU4pIEFDUEk6IExBUElDIChhY3BpX2lkWzB4MDRdIGxhcGljX2lkWzB4MDNd
IGVuYWJsZWQpDQooWEVOKSBQcm9jZXNzb3IgIzMgMDoxMCBBUElDIHZlcnNpb24gMTYNCihY
RU4pIEFDUEk6IExBUElDIChhY3BpX2lkWzB4MDVdIGxhcGljX2lkWzB4MDRdIGVuYWJsZWQp
DQooWEVOKSBQcm9jZXNzb3IgIzQgMDoxMCBBUElDIHZlcnNpb24gMTYNCihYRU4pIEFDUEk6
IExBUElDIChhY3BpX2lkWzB4MDZdIGxhcGljX2lkWzB4MDVdIGVuYWJsZWQpDQooWEVOKSBQ
cm9jZXNzb3IgIzUgMDoxMCBBUElDIHZlcnNpb24gMTYNCihYRU4pIEFDUEk6IElPQVBJQyAo
aWRbMHgwNl0gYWRkcmVzc1sweGZlYzAwMDAwXSBnc2lfYmFzZVswXSkNCihYRU4pIElPQVBJ
Q1swXTogYXBpY19pZCA2LCB2ZXJzaW9uIDMzLCBhZGRyZXNzIDB4ZmVjMDAwMDAsIEdTSSAw
LTIzDQooWEVOKSBBQ1BJOiBJT0FQSUMgKGlkWzB4MDddIGFkZHJlc3NbMHhmZWMyMDAwMF0g
Z3NpX2Jhc2VbMjRdKQ0KKFhFTikgSU9BUElDWzFdOiBhcGljX2lkIDcsIHZlcnNpb24gMzMs
IGFkZHJlc3MgMHhmZWMyMDAwMCwgR1NJIDI0LTU1DQooWEVOKSBBQ1BJOiBJTlRfU1JDX09W
UiAoYnVzIDAgYnVzX2lycSAwIGdsb2JhbF9pcnEgMiBkZmwgZGZsKQ0KKFhFTikgQUNQSTog
SU5UX1NSQ19PVlIgKGJ1cyAwIGJ1c19pcnEgOSBnbG9iYWxfaXJxIDkgbG93IGxldmVsKQ0K
KFhFTikgQUNQSTogSVJRMCB1c2VkIGJ5IG92ZXJyaWRlLg0KKFhFTikgQUNQSTogSVJRMiB1
c2VkIGJ5IG92ZXJyaWRlLg0KKFhFTikgQUNQSTogSVJROSB1c2VkIGJ5IG92ZXJyaWRlLg0K
KFhFTikgRW5hYmxpbmcgQVBJQyBtb2RlOiAgRmxhdC4gIFVzaW5nIDIgSS9PIEFQSUNzDQoo
WEVOKSBBQ1BJOiBIUEVUIGlkOiAweDgzMDAgYmFzZTogMHhmZWQwMDAwMA0KKFhFTikgVGFi
bGUgaXMgbm90IGZvdW5kIQ0KKFhFTikgVXNpbmcgQUNQSSAoTUFEVCkgZm9yIFNNUCBjb25m
aWd1cmF0aW9uIGluZm9ybWF0aW9uDQooWEVOKSBTTVA6IEFsbG93aW5nIDYgQ1BVcyAoMCBo
b3RwbHVnIENQVXMpDQooWEVOKSBtYXBwZWQgQVBJQyB0byBmZmZmODJjM2ZmZGZlMDAwIChm
ZWUwMDAwMCkNCihYRU4pIG1hcHBlZCBJT0FQSUMgdG8gZmZmZjgyYzNmZmRmZDAwMCAoZmVj
MDAwMDApDQooWEVOKSBtYXBwZWQgSU9BUElDIHRvIGZmZmY4MmMzZmZkZmMwMDAgKGZlYzIw
MDAwKQ0KKFhFTikgSVJRIGxpbWl0czogNTYgR1NJLCAxMTEyIE1TSS9NU0ktWA0KKFhFTikg
VXNpbmcgc2NoZWR1bGVyOiBTTVAgQ3JlZGl0IFNjaGVkdWxlciAoY3JlZGl0KQ0KKFhFTikg
RGV0ZWN0ZWQgMzIwMC4xNDQgTUh6IHByb2Nlc3Nvci4NCihYRU4pIEluaXRpbmcgbWVtb3J5
IHNoYXJpbmcuDQooWEVOKSBBTUQgRmFtMTBoIG1hY2hpbmUgY2hlY2sgcmVwb3J0aW5nIGVu
YWJsZWQNCihYRU4pIFBDSTogTUNGRyBjb25maWd1cmF0aW9uIDA6IGJhc2UgZTAwMDAwMDAg
c2VnbWVudCAwMDAwIGJ1c2VzIDAwIC0gZmYNCihYRU4pIFBDSTogTm90IHVzaW5nIE1DRkcg
Zm9yIHNlZ21lbnQgMDAwMCBidXMgMDAtZmYNCihYRU4pIEFNRC1WaTogRm91bmQgTVNJIGNh
cGFiaWxpdHkgYmxvY2sgYXQgMHg1NA0KKFhFTikgQU1ELVZpOiBBQ1BJIFRhYmxlOg0KKFhF
TikgQU1ELVZpOiAgU2lnbmF0dXJlIElWUlMNCihYRU4pIEFNRC1WaTogIExlbmd0aCAweGY4
DQooWEVOKSBBTUQtVmk6ICBSZXZpc2lvbiAweDENCihYRU4pIEFNRC1WaTogIENoZWNrU3Vt
IDB4NmUNCihYRU4pIEFNRC1WaTogIE9FTV9JZCBBTUQgIA0KKFhFTikgQU1ELVZpOiAgT0VN
X1RhYmxlX0lkIFJEODkwUw0KKFhFTikgQU1ELVZpOiAgT0VNX1JldmlzaW9uIDB4MjAyMDMx
DQooWEVOKSBBTUQtVmk6ICBDcmVhdG9yX0lkIEFNRCANCihYRU4pIEFNRC1WaTogIENyZWF0
b3JfUmV2aXNpb24gMHgwDQooWEVOKSBBTUQtVmk6IElWUlMgQmxvY2s6DQooWEVOKSBBTUQt
Vmk6ICBUeXBlIDB4MTANCihYRU4pIEFNRC1WaTogIEZsYWdzIDB4M2UNCihYRU4pIEFNRC1W
aTogIExlbmd0aCAweGM4DQooWEVOKSBBTUQtVmk6ICBEZXZfSWQgMHgyDQooWEVOKSBBTUQt
Vmk6IElWSEQgRGV2aWNlIEVudHJ5Og0KKFhFTikgQU1ELVZpOiAgVHlwZSAweDMNCihYRU4p
IEFNRC1WaTogIERldl9JZCAweDANCihYRU4pIEFNRC1WaTogIEZsYWdzIDB4MA0KKFhFTikg
QU1ELVZpOiAgRGV2X0lkIFJhbmdlOiAweDAgLT4gMHgyDQooWEVOKSBBTUQtVmk6IElWSEQg
RGV2aWNlIEVudHJ5Og0KKFhFTikgQU1ELVZpOiAgVHlwZSAweDINCihYRU4pIEFNRC1WaTog
IERldl9JZCAweDEwDQooWEVOKSBBTUQtVmk6ICBGbGFncyAweDANCihYRU4pIEFNRC1WaTog
SVZIRCBEZXZpY2UgRW50cnk6DQooWEVOKSBBTUQtVmk6ICBUeXBlIDB4Mg0KKFhFTikgQU1E
LVZpOiAgRGV2X0lkIDB4YjAwDQooWEVOKSBBTUQtVmk6ICBGbGFncyAweDANCihYRU4pIEFN
RC1WaTogSVZIRCBEZXZpY2UgRW50cnk6DQooWEVOKSBBTUQtVmk6ICBUeXBlIDB4Mg0KKFhF
TikgQU1ELVZpOiAgRGV2X0lkIDB4MTgNCihYRU4pIEFNRC1WaTogIEZsYWdzIDB4MA0KKFhF
TikgQU1ELVZpOiBJVkhEIERldmljZSBFbnRyeToNCihYRU4pIEFNRC1WaTogIFR5cGUgMHgz
DQooWEVOKSBBTUQtVmk6ICBEZXZfSWQgMHhhMDANCihYRU4pIEFNRC1WaTogIEZsYWdzIDB4
MA0KKFhFTikgQU1ELVZpOiAgRGV2X0lkIFJhbmdlOiAweGEwMCAtPiAweGEwNw0KKFhFTikg
QU1ELVZpOiBJVkhEIERldmljZSBFbnRyeToNCihYRU4pIEFNRC1WaTogIFR5cGUgMHgyDQoo
WEVOKSBBTUQtVmk6ICBEZXZfSWQgMHgyOA0KKFhFTikgQU1ELVZpOiAgRmxhZ3MgMHgwDQoo
WEVOKSBBTUQtVmk6IElWSEQgRGV2aWNlIEVudHJ5Og0KKFhFTikgQU1ELVZpOiAgVHlwZSAw
eDINCihYRU4pIEFNRC1WaTogIERldl9JZCAweDkwMA0KKFhFTikgQU1ELVZpOiAgRmxhZ3Mg
MHgwDQooWEVOKSBBTUQtVmk6IElWSEQgRGV2aWNlIEVudHJ5Og0KKFhFTikgQU1ELVZpOiAg
VHlwZSAweDINCihYRU4pIEFNRC1WaTogIERldl9JZCAweDMwDQooWEVOKSBBTUQtVmk6ICBG
bGFncyAweDANCihYRU4pIEFNRC1WaTogSVZIRCBEZXZpY2UgRW50cnk6DQooWEVOKSBBTUQt
Vmk6ICBUeXBlIDB4Mg0KKFhFTikgQU1ELVZpOiAgRGV2X0lkIDB4ODAwDQooWEVOKSBBTUQt
Vmk6ICBGbGFncyAweDANCihYRU4pIEFNRC1WaTogSVZIRCBEZXZpY2UgRW50cnk6DQooWEVO
KSBBTUQtVmk6ICBUeXBlIDB4Mg0KKFhFTikgQU1ELVZpOiAgRGV2X0lkIDB4NTANCihYRU4p
IEFNRC1WaTogIEZsYWdzIDB4MA0KKFhFTikgQU1ELVZpOiBJVkhEIERldmljZSBFbnRyeToN
CihYRU4pIEFNRC1WaTogIFR5cGUgMHgyDQooWEVOKSBBTUQtVmk6ICBEZXZfSWQgMHg3MDAN
CihYRU4pIEFNRC1WaTogIEZsYWdzIDB4MA0KKFhFTikgQU1ELVZpOiBJVkhEIERldmljZSBF
bnRyeToNCihYRU4pIEFNRC1WaTogIFR5cGUgMHgyDQooWEVOKSBBTUQtVmk6ICBEZXZfSWQg
MHg1OA0KKFhFTikgQU1ELVZpOiAgRmxhZ3MgMHgwDQooWEVOKSBBTUQtVmk6IElWSEQgRGV2
aWNlIEVudHJ5Og0KKFhFTikgQU1ELVZpOiAgVHlwZSAweDMNCihYRU4pIEFNRC1WaTogIERl
dl9JZCAweDYwMA0KKFhFTikgQU1ELVZpOiAgRmxhZ3MgMHgwDQooWEVOKSBBTUQtVmk6ICBE
ZXZfSWQgUmFuZ2U6IDB4NjAwIC0+IDB4NjAxDQooWEVOKSBBTUQtVmk6IElWSEQgRGV2aWNl
IEVudHJ5Og0KKFhFTikgQU1ELVZpOiAgVHlwZSAweDINCihYRU4pIEFNRC1WaTogIERldl9J
ZCAweDYwDQooWEVOKSBBTUQtVmk6ICBGbGFncyAweDANCihYRU4pIEFNRC1WaTogSVZIRCBE
ZXZpY2UgRW50cnk6DQooWEVOKSBBTUQtVmk6ICBUeXBlIDB4Mg0KKFhFTikgQU1ELVZpOiAg
RGV2X0lkIDB4NTAwDQooWEVOKSBBTUQtVmk6ICBGbGFncyAweDANCihYRU4pIEFNRC1WaTog
SVZIRCBEZXZpY2UgRW50cnk6DQooWEVOKSBBTUQtVmk6ICBUeXBlIDB4Mg0KKFhFTikgQU1E
LVZpOiAgRGV2X0lkIDB4NjgNCihYRU4pIEFNRC1WaTogIEZsYWdzIDB4MA0KKFhFTikgQU1E
LVZpOiBJVkhEIERldmljZSBFbnRyeToNCihYRU4pIEFNRC1WaTogIFR5cGUgMHgzDQooWEVO
KSBBTUQtVmk6ICBEZXZfSWQgMHg0MDANCihYRU4pIEFNRC1WaTogIEZsYWdzIDB4MA0KKFhF
TikgQU1ELVZpOiAgRGV2X0lkIFJhbmdlOiAweDQwMCAtPiAweDQwNw0KKFhFTikgQU1ELVZp
OiBJVkhEIERldmljZSBFbnRyeToNCihYRU4pIEFNRC1WaTogIFR5cGUgMHgyDQooWEVOKSBB
TUQtVmk6ICBEZXZfSWQgMHg4OA0KKFhFTikgQU1ELVZpOiAgRmxhZ3MgMHgwDQooWEVOKSBB
TUQtVmk6IElWSEQgRGV2aWNlIEVudHJ5Og0KKFhFTikgQU1ELVZpOiAgVHlwZSAweDMNCihY
RU4pIEFNRC1WaTogIERldl9JZCAweDkwDQooWEVOKSBBTUQtVmk6ICBGbGFncyAweDANCihY
RU4pIEFNRC1WaTogIERldl9JZCBSYW5nZTogMHg5MCAtPiAweDkyDQooWEVOKSBBTUQtVmk6
IElWSEQgRGV2aWNlIEVudHJ5Og0KKFhFTikgQU1ELVZpOiAgVHlwZSAweDMNCihYRU4pIEFN
RC1WaTogIERldl9JZCAweDk4DQooWEVOKSBBTUQtVmk6ICBGbGFncyAweDANCihYRU4pIEFN
RC1WaTogIERldl9JZCBSYW5nZTogMHg5OCAtPiAweDlhDQooWEVOKSBBTUQtVmk6IElWSEQg
RGV2aWNlIEVudHJ5Og0KKFhFTikgQU1ELVZpOiAgVHlwZSAweDINCihYRU4pIEFNRC1WaTog
IERldl9JZCAweGEwDQooWEVOKSBBTUQtVmk6ICBGbGFncyAweGQ3DQooWEVOKSBBTUQtVmk6
IElWSEQgRGV2aWNlIEVudHJ5Og0KKFhFTikgQU1ELVZpOiAgVHlwZSAweDINCihYRU4pIEFN
RC1WaTogIERldl9JZCAweGEzDQooWEVOKSBBTUQtVmk6ICBGbGFncyAweDANCihYRU4pIEFN
RC1WaTogSVZIRCBEZXZpY2UgRW50cnk6DQooWEVOKSBBTUQtVmk6ICBUeXBlIDB4Mg0KKFhF
TikgQU1ELVZpOiAgRGV2X0lkIDB4YTQNCihYRU4pIEFNRC1WaTogIEZsYWdzIDB4MA0KKFhF
TikgQU1ELVZpOiBJVkhEIERldmljZSBFbnRyeToNCihYRU4pIEFNRC1WaTogIFR5cGUgMHgw
DQooWEVOKSBBTUQtVmk6ICBEZXZfSWQgMHgwDQooWEVOKSBBTUQtVmk6ICBGbGFncyAweDAN
CihYRU4pIEFNRC1WaTogSVZIRCBEZXZpY2UgRW50cnk6DQooWEVOKSBBTUQtVmk6ICBUeXBl
IDB4NDMNCihYRU4pIEFNRC1WaTogIERldl9JZCAweDMwMA0KKFhFTikgQU1ELVZpOiAgRmxh
Z3MgMHgwDQooWEVOKSBBTUQtVmk6ICBEZXZfSWQgUmFuZ2U6IDB4MzAwIC0+IDB4M2ZmDQoo
WEVOKSBBTUQtVmk6ICBEZXZfSWQgQWxpYXM6IDB4YTQNCihYRU4pIEFNRC1WaTogSVZIRCBE
ZXZpY2UgRW50cnk6DQooWEVOKSBBTUQtVmk6ICBUeXBlIDB4Mg0KKFhFTikgQU1ELVZpOiAg
RGV2X0lkIDB4YTUNCihYRU4pIEFNRC1WaTogIEZsYWdzIDB4MA0KKFhFTikgQU1ELVZpOiBJ
VkhEIERldmljZSBFbnRyeToNCihYRU4pIEFNRC1WaTogIFR5cGUgMHgyDQooWEVOKSBBTUQt
Vmk6ICBEZXZfSWQgMHhhOA0KKFhFTikgQU1ELVZpOiAgRmxhZ3MgMHgwDQooWEVOKSBBTUQt
Vmk6IElWSEQgRGV2aWNlIEVudHJ5Og0KKFhFTikgQU1ELVZpOiAgVHlwZSAweDINCihYRU4p
IEFNRC1WaTogIERldl9JZCAweGE5DQooWEVOKSBBTUQtVmk6ICBGbGFncyAweDANCihYRU4p
IEFNRC1WaTogSVZIRCBEZXZpY2UgRW50cnk6DQooWEVOKSBBTUQtVmk6ICBUeXBlIDB4Mg0K
KFhFTikgQU1ELVZpOiAgRGV2X0lkIDB4MTAwDQooWEVOKSBzcHVyaW91cyA4MjU5QSBpbnRl
cnJ1cHQ6IElSUTcuDQooWEVOKSBBTUQtVmk6ICBGbGFncyAweDANCihYRU4pIEFNRC1WaTog
SVZIRCBEZXZpY2UgRW50cnk6DQooWEVOKSBBTUQtVmk6ICBUeXBlIDB4Mw0KKFhFTikgQU1E
LVZpOiAgRGV2X0lkIDB4YjANCihYRU4pIEFNRC1WaTogIEZsYWdzIDB4MA0KKFhFTikgQU1E
LVZpOiAgRGV2X0lkIFJhbmdlOiAweGIwIC0+IDB4YjINCihYRU4pIEFNRC1WaTogSVZIRCBE
ZXZpY2UgRW50cnk6DQooWEVOKSBBTUQtVmk6ICBUeXBlIDB4MA0KKFhFTikgQU1ELVZpOiAg
RGV2X0lkIDB4MA0KKFhFTikgQU1ELVZpOiAgRmxhZ3MgMHgwDQooWEVOKSBBTUQtVmk6IElW
SEQgRGV2aWNlIEVudHJ5Og0KKFhFTikgQU1ELVZpOiAgVHlwZSAweDQ4DQooWEVOKSBBTUQt
Vmk6ICBEZXZfSWQgMHgwDQooWEVOKSBBTUQtVmk6ICBGbGFncyAweGQ3DQooWEVOKSBBTUQt
Vmk6IElWSEQgRGV2aWNlIEVudHJ5Og0KKFhFTikgQU1ELVZpOiAgVHlwZSAweDQ4DQooWEVO
KSBBTUQtVmk6ICBEZXZfSWQgMHgwDQooWEVOKSBBTUQtVmk6ICBGbGFncyAweDANCihYRU4p
IEFNRC1WaTogSU9NTVUgMCBFbmFibGVkLg0KKFhFTikgQU1ELVZpOiBFbmFibGluZyBnbG9i
YWwgdmVjdG9yIG1hcA0KKFhFTikgSS9PIHZpcnR1YWxpc2F0aW9uIGVuYWJsZWQNCihYRU4p
ICAtIERvbTAgbW9kZTogUmVsYXhlZA0KKFhFTikgR2V0dGluZyBWRVJTSU9OOiA4MDA1MDAx
MA0KKFhFTikgR2V0dGluZyBWRVJTSU9OOiA4MDA1MDAxMA0KKFhFTikgR2V0dGluZyBJRDog
MA0KKFhFTikgR2V0dGluZyBMVlQwOiA3MDANCihYRU4pIEdldHRpbmcgTFZUMTogNDAwDQoo
WEVOKSBlbmFibGVkIEV4dElOVCBvbiBDUFUjMA0KKFhFTikgRVNSIHZhbHVlIGJlZm9yZSBl
bmFibGluZyB2ZWN0b3I6IDB4MDAwMDAwMDQgIGFmdGVyOiAweDAwMDAwMDAwDQooWEVOKSBF
TkFCTElORyBJTy1BUElDIElSUXMNCihYRU4pICAtPiBVc2luZyBuZXcgQUNLIG1ldGhvZA0K
KFhFTikgaW5pdCBJT19BUElDIElSUXMNCihYRU4pICBJTy1BUElDIChhcGljaWQtcGluKSA2
LTAsIDYtMTYsIDYtMTcsIDYtMTgsIDYtMTksIDYtMjAsIDYtMjEsIDYtMjIsIDYtMjMsIDct
MCwgNy0xLCA3LTIsIDctMywgNy00LCA3LTUsIDctNiwgNy03LCA3LTgsIDctOSwgNy0xMCwg
Ny0xMSwgNy0xMiwgNy0xMywgNy0xNCwgNy0xNSwgNy0xNiwgNy0xNywgNy0xOCwgNy0xOSwg
Ny0yMCwgNy0yMSwgNy0yMiwgNy0yMywgNy0yNCwgNy0yNSwgNy0yNiwgNy0yNywgNy0yOCwg
Ny0yOSwgNy0zMCwgNy0zMSBub3QgY29ubmVjdGVkLg0KKFhFTikgLi5USU1FUjogdmVjdG9y
PTB4RjAgYXBpYzE9MCBwaW4xPTIgYXBpYzI9LTEgcGluMj0tMQ0KKFhFTikgbnVtYmVyIG9m
IE1QIElSUSBzb3VyY2VzOiAxNS4NCihYRU4pIG51bWJlciBvZiBJTy1BUElDICM2IHJlZ2lz
dGVyczogMjQuDQooWEVOKSBudW1iZXIgb2YgSU8tQVBJQyAjNyByZWdpc3RlcnM6IDMyLg0K
KFhFTikgdGVzdGluZyB0aGUgSU8gQVBJQy4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uDQooWEVO
KSBJTyBBUElDICM2Li4uLi4uDQooWEVOKSAuLi4uIHJlZ2lzdGVyICMwMDogMDYwMDAwMDAN
CihYRU4pIC4uLi4uLi4gICAgOiBwaHlzaWNhbCBBUElDIGlkOiAwNg0KKFhFTikgLi4uLi4u
LiAgICA6IERlbGl2ZXJ5IFR5cGU6IDANCihYRU4pIC4uLi4uLi4gICAgOiBMVFMgICAgICAg
ICAgOiAwDQooWEVOKSAuLi4uIHJlZ2lzdGVyICMwMTogMDAxNzgwMjENCihYRU4pIC4uLi4u
Li4gICAgIDogbWF4IHJlZGlyZWN0aW9uIGVudHJpZXM6IDAwMTcNCihYRU4pIC4uLi4uLi4g
ICAgIDogUFJRIGltcGxlbWVudGVkOiAxDQooWEVOKSAuLi4uLi4uICAgICA6IElPIEFQSUMg
dmVyc2lvbjogMDAyMQ0KKFhFTikgLi4uLiByZWdpc3RlciAjMDI6IDA2MDAwMDAwDQooWEVO
KSAuLi4uLi4uICAgICA6IGFyYml0cmF0aW9uOiAwNg0KKFhFTikgLi4uLiByZWdpc3RlciAj
MDM6IDA3MDAwMDAwDQooWEVOKSAuLi4uLi4uICAgICA6IEJvb3QgRFQgICAgOiAwDQooWEVO
KSAuLi4uIElSUSByZWRpcmVjdGlvbiB0YWJsZToNCihYRU4pICBOUiBMb2cgUGh5IE1hc2sg
VHJpZyBJUlIgUG9sIFN0YXQgRGVzdCBEZWxpIFZlY3Q6ICAgDQooWEVOKSAgMDAgMDAwIDAw
ICAxICAgIDAgICAgMCAgIDAgICAwICAgIDAgICAgMCAgICAwMA0KKFhFTikgIDAxIDAwMSAw
MSAgMCAgICAwICAgIDAgICAwICAgMCAgICAxICAgIDEgICAgMzANCihYRU4pICAwMiAwMDEg
MDEgIDAgICAgMCAgICAwICAgMCAgIDAgICAgMSAgICAxICAgIEYwDQooWEVOKSAgMDMgMDAx
IDAxICAwICAgIDAgICAgMCAgIDAgICAwICAgIDEgICAgMSAgICAzOA0KKFhFTikgIDA0IDAw
MSAwMSAgMCAgICAwICAgIDAgICAwICAgMCAgICAxICAgIDEgICAgRjENCihYRU4pICAwNSAw
MDEgMDEgIDAgICAgMCAgICAwICAgMCAgIDAgICAgMSAgICAxICAgIDQwDQooWEVOKSAgMDYg
MDAxIDAxICAwICAgIDAgICAgMCAgIDAgICAwICAgIDEgICAgMSAgICA0OA0KKFhFTikgIDA3
IDAwMSAwMSAgMCAgICAwICAgIDAgICAwICAgMCAgICAxICAgIDEgICAgNTANCihYRU4pICAw
OCAwMDEgMDEgIDAgICAgMCAgICAwICAgMCAgIDAgICAgMSAgICAxICAgIDU4DQooWEVOKSAg
MDkgMDAxIDAxICAxICAgIDEgICAgMCAgIDEgICAwICAgIDEgICAgMSAgICA2MA0KKFhFTikg
IDBhIDAwMSAwMSAgMCAgICAwICAgIDAgICAwICAgMCAgICAxICAgIDEgICAgNjgNCihYRU4p
ICAwYiAwMDEgMDEgIDAgICAgMCAgICAwICAgMCAgIDAgICAgMSAgICAxICAgIDcwDQooWEVO
KSAgMGMgMDAxIDAxICAwICAgIDAgICAgMCAgIDAgICAwICAgIDEgICAgMSAgICA3OA0KKFhF
TikgIDBkIDAwMSAwMSAgMCAgICAwICAgIDAgICAwICAgMCAgICAxICAgIDEgICAgODgNCihY
RU4pICAwZSAwMDEgMDEgIDAgICAgMCAgICAwICAgMCAgIDAgICAgMSAgICAxICAgIDkwDQoo
WEVOKSAgMGYgMDAxIDAxICAwICAgIDAgICAgMCAgIDAgICAwICAgIDEgICAgMSAgICA5OA0K
KFhFTikgIDEwIDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDAgICAgMDAN
CihYRU4pICAxMSAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAw
DQooWEVOKSAgMTIgMDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAwICAgIDAgICAgMCAgICAw
MA0KKFhFTikgIDEzIDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDAgICAg
MDANCihYRU4pICAxNCAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAg
IDAwDQooWEVOKSAgMTUgMDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAwICAgIDAgICAgMCAg
ICAwMA0KKFhFTikgIDE2IDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDAg
ICAgMDANCihYRU4pICAxNyAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAw
ICAgIDAwDQooWEVOKSBJTyBBUElDICM3Li4uLi4uDQooWEVOKSAuLi4uIHJlZ2lzdGVyICMw
MDogMDcwMDAwMDANCihYRU4pIC4uLi4uLi4gICAgOiBwaHlzaWNhbCBBUElDIGlkOiAwNw0K
KFhFTikgLi4uLi4uLiAgICA6IERlbGl2ZXJ5IFR5cGU6IDANCihYRU4pIC4uLi4uLi4gICAg
OiBMVFMgICAgICAgICAgOiAwDQooWEVOKSAuLi4uIHJlZ2lzdGVyICMwMTogMDAxRjgwMjEN
CihYRU4pIC4uLi4uLi4gICAgIDogbWF4IHJlZGlyZWN0aW9uIGVudHJpZXM6IDAwMUYNCihY
RU4pIC4uLi4uLi4gICAgIDogUFJRIGltcGxlbWVudGVkOiAxDQooWEVOKSAuLi4uLi4uICAg
ICA6IElPIEFQSUMgdmVyc2lvbjogMDAyMQ0KKFhFTikgLi4uLiByZWdpc3RlciAjMDI6IDAw
MDAwMDAwDQooWEVOKSAuLi4uLi4uICAgICA6IGFyYml0cmF0aW9uOiAwMA0KKFhFTikgLi4u
LiBJUlEgcmVkaXJlY3Rpb24gdGFibGU6DQooWEVOKSAgTlIgTG9nIFBoeSBNYXNrIFRyaWcg
SVJSIFBvbCBTdGF0IERlc3QgRGVsaSBWZWN0OiAgIA0KKFhFTikgIDAwIDAwMCAwMCAgMSAg
ICAwICAgIDAgICAwICAgMCAgICAwICAgIDAgICAgMDANCihYRU4pICAwMSAwMDAgMDAgIDEg
ICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwDQooWEVOKSAgMDIgMDAwIDAwICAx
ICAgIDAgICAgMCAgIDAgICAwICAgIDAgICAgMCAgICAwMA0KKFhFTikgIDAzIDAwMCAwMCAg
MSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDAgICAgMDANCihYRU4pICAwNCAwMDAgMDAg
IDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwDQooWEVOKSAgMDUgMDAwIDAw
ICAxICAgIDAgICAgMCAgIDAgICAwICAgIDAgICAgMCAgICAwMA0KKFhFTikgIDA2IDAwMCAw
MCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDAgICAgMDANCihYRU4pICAwNyAwMDAg
MDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwDQooWEVOKSAgMDggMDAw
IDAwICAxICAgIDAgICAgMCAgIDAgICAwICAgIDAgICAgMCAgICAwMA0KKFhFTikgIDA5IDAw
MCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDAgICAgMDANCihYRU4pICAwYSAw
MDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwDQooWEVOKSAgMGIg
MDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAwICAgIDAgICAgMCAgICAwMA0KKFhFTikgIDBj
IDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDAgICAgMDANCihYRU4pICAw
ZCAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwDQooWEVOKSAg
MGUgMDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAwICAgIDAgICAgMCAgICAwMA0KKFhFTikg
IDBmIDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDAgICAgMDANCihYRU4p
ICAxMCAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwDQooWEVO
KSAgMTEgMDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAwICAgIDAgICAgMCAgICAwMA0KKFhF
TikgIDEyIDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDAgICAgMDANCihY
RU4pICAxMyAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwDQoo
WEVOKSAgMTQgMDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAwICAgIDAgICAgMCAgICAwMA0K
KFhFTikgIDE1IDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDAgICAgMDAN
CihYRU4pICAxNiAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAw
DQooWEVOKSAgMTcgMDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAwICAgIDAgICAgMCAgICAw
MA0KKFhFTikgIDE4IDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDAgICAg
MDANCihYRU4pICAxOSAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAg
IDAwDQooWEVOKSAgMWEgMDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAwICAgIDAgICAgMCAg
ICAwMA0KKFhFTikgIDFiIDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDAg
ICAgMDANCihYRU4pICAxYyAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAw
ICAgIDAwDQooWEVOKSAgMWQgMDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAwICAgIDAgICAg
MCAgICAwMA0KKFhFTikgIDFlIDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAg
IDAgICAgMDANCihYRU4pICAxZiAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAg
ICAwICAgIDAwDQooWEVOKSBVc2luZyB2ZWN0b3ItYmFzZWQgaW5kZXhpbmcNCihYRU4pIElS
USB0byBwaW4gbWFwcGluZ3M6DQooWEVOKSBJUlEyNDAgLT4gMDoyDQooWEVOKSBJUlE0OCAt
PiAwOjENCihYRU4pIElSUTU2IC0+IDA6Mw0KKFhFTikgSVJRMjQxIC0+IDA6NA0KKFhFTikg
SVJRNjQgLT4gMDo1DQooWEVOKSBJUlE3MiAtPiAwOjYNCihYRU4pIElSUTgwIC0+IDA6Nw0K
KFhFTikgSVJRODggLT4gMDo4DQooWEVOKSBJUlE5NiAtPiAwOjkNCihYRU4pIElSUTEwNCAt
PiAwOjEwDQooWEVOKSBJUlExMTIgLT4gMDoxMQ0KKFhFTikgSVJRMTIwIC0+IDA6MTINCihY
RU4pIElSUTEzNiAtPiAwOjEzDQooWEVOKSBJUlExNDQgLT4gMDoxNA0KKFhFTikgSVJRMTUy
IC0+IDA6MTUNCihYRU4pIC4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLiBk
b25lLg0KKFhFTikgVXNpbmcgbG9jYWwgQVBJQyB0aW1lciBpbnRlcnJ1cHRzLg0KKFhFTikg
Y2FsaWJyYXRpbmcgQVBJQyB0aW1lciAuLi4NCihYRU4pIC4uLi4uIENQVSBjbG9jayBzcGVl
ZCBpcyAzMjAwLjEyNDggTUh6Lg0KKFhFTikgLi4uLi4gaG9zdCBidXMgY2xvY2sgc3BlZWQg
aXMgMjAwLjAwNzcgTUh6Lg0KKFhFTikgLi4uLi4gYnVzX3NjYWxlID0gMHgwMDAwQ0NENw0K
KFhFTikgWzIwMTItMDktMDYgMjA6MDk6MDZdIFBsYXRmb3JtIHRpbWVyIGlzIDE0LjMxOE1I
eiBIUEVUDQooWEVOKSBbMjAxMi0wOS0wNiAyMDowOTowNl0gQWxsb2NhdGVkIGNvbnNvbGUg
cmluZyBvZiA2NCBLaUIuDQooWEVOKSBbMjAxMi0wOS0wNiAyMDowOTowNl0gSFZNOiBBU0lE
cyBlbmFibGVkLg0KKFhFTikgWzIwMTItMDktMDYgMjA6MDk6MDZdIFNWTTogU3VwcG9ydGVk
IGFkdmFuY2VkIGZlYXR1cmVzOg0KKFhFTikgWzIwMTItMDktMDYgMjA6MDk6MDZdICAtIE5l
c3RlZCBQYWdlIFRhYmxlcyAoTlBUKQ0KKFhFTikgWzIwMTItMDktMDYgMjA6MDk6MDZdICAt
IExhc3QgQnJhbmNoIFJlY29yZCAoTEJSKSBWaXJ0dWFsaXNhdGlvbg0KKFhFTikgWzIwMTIt
MDktMDYgMjA6MDk6MDZdICAtIE5leHQtUklQIFNhdmVkIG9uICNWTUVYSVQNCihYRU4pIFsy
MDEyLTA5LTA2IDIwOjA5OjA2XSAgLSBQYXVzZS1JbnRlcmNlcHQgRmlsdGVyDQooWEVOKSBb
MjAxMi0wOS0wNiAyMDowOTowNl0gSFZNOiBTVk0gZW5hYmxlZA0KKFhFTikgWzIwMTItMDkt
MDYgMjA6MDk6MDZdIEhWTTogSGFyZHdhcmUgQXNzaXN0ZWQgUGFnaW5nIChIQVApIGRldGVj
dGVkDQooWEVOKSBbMjAxMi0wOS0wNiAyMDowOTowNl0gSFZNOiBIQVAgcGFnZSBzaXplczog
NGtCLCAyTUIsIDFHQg0KKFhFTikgWzIwMTItMDktMDYgMjA6MDk6MDVdIG1hc2tlZCBFeHRJ
TlQgb24gQ1BVIzENCihYRU4pIFsyMDEyLTA5LTA2IDIwOjA5OjA2XSBtaWNyb2NvZGU6IGNv
bGxlY3RfY3B1X2luZm86IHBhdGNoX2lkPTB4MTAwMDBiZg0KKFhFTikgWzIwMTItMDktMDYg
MjA6MDk6MDVdIG1hc2tlZCBFeHRJTlQgb24gQ1BVIzINCihYRU4pIFsyMDEyLTA5LTA2IDIw
OjA5OjA2XSBtaWNyb2NvZGU6IGNvbGxlY3RfY3B1X2luZm86IHBhdGNoX2lkPTB4MTAwMDBi
Zg0KKFhFTikgWzIwMTItMDktMDYgMjA6MDk6MDVdIG1hc2tlZCBFeHRJTlQgb24gQ1BVIzMN
CihYRU4pIFsyMDEyLTA5LTA2IDIwOjA5OjA2XSBtaWNyb2NvZGU6IGNvbGxlY3RfY3B1X2lu
Zm86IHBhdGNoX2lkPTB4MTAwMDBiZg0KKFhFTikgWzIwMTItMDktMDYgMjA6MDk6MDVdIG1h
c2tlZCBFeHRJTlQgb24gQ1BVIzQNCihYRU4pIFsyMDEyLTA5LTA2IDIwOjA5OjA2XSBtaWNy
b2NvZGU6IGNvbGxlY3RfY3B1X2luZm86IHBhdGNoX2lkPTB4MTAwMDBiZg0KKFhFTikgWzIw
MTItMDktMDYgMjA6MDk6MDVdIG1hc2tlZCBFeHRJTlQgb24gQ1BVIzUNCihYRU4pIFsyMDEy
LTA5LTA2IDIwOjA5OjA2XSBCcm91Z2h0IHVwIDYgQ1BVcw0KKFhFTikgWzIwMTItMDktMDYg
MjA6MDk6MDZdIG1pY3JvY29kZTogY29sbGVjdF9jcHVfaW5mbzogcGF0Y2hfaWQ9MHgxMDAw
MGJmDQooWEVOKSBbMjAxMi0wOS0wNiAyMDowOTowNl0gSFBFVCdzIE1TSSBtb2RlIGhhc24n
dCBiZWVuIHN1cHBvcnRlZCB3aGVuIEludGVycnVwdCBSZW1hcHBpbmcgaXMgZW5hYmxlZC4N
CihYRU4pIFsyMDEyLTA5LTA2IDIwOjA5OjA2XSBBQ1BJIHNsZWVwIG1vZGVzOiBTMw0KKFhF
TikgWzIwMTItMDktMDYgMjA6MDk6MDZdIE1DQTogVXNlIGh3IHRocmVzaG9sZGluZyB0byBh
ZGp1c3QgcG9sbGluZyBmcmVxdWVuY3kNCihYRU4pIFsyMDEyLTA5LTA2IDIwOjA5OjA2XSBt
Y2hlY2tfcG9sbDogTWFjaGluZSBjaGVjayBwb2xsaW5nIHRpbWVyIHN0YXJ0ZWQuDQooWEVO
KSBbMjAxMi0wOS0wNiAyMDowOTowNl0gWGVub3Byb2ZpbGU6IEZhaWxlZCB0byBzZXR1cCBJ
QlMgTFZUIG9mZnNldCwgSUJTQ1RMID0gMHhmZmZmZmZmZg0KKFhFTikgWzIwMTItMDktMDYg
MjA6MDk6MDZdICoqKiBMT0FESU5HIERPTUFJTiAwICoqKg0KKFhFTikgWzIwMTItMDktMDYg
MjA6MDk6MDZdIGVsZl9wYXJzZV9iaW5hcnk6IHBoZHI6IHBhZGRyPTB4MTAwMDAwMCBtZW1z
ej0weGQ2YTAwMA0KKFhFTikgWzIwMTItMDktMDYgMjA6MDk6MDZdIGVsZl9wYXJzZV9iaW5h
cnk6IHBoZHI6IHBhZGRyPTB4MWUwMDAwMCBtZW1zej0weGRiMGU4DQooWEVOKSBbMjAxMi0w
OS0wNiAyMDowOTowNl0gZWxmX3BhcnNlX2JpbmFyeTogcGhkcjogcGFkZHI9MHgxZWRjMDAw
IG1lbXN6PTB4MTNjMDANCihYRU4pIFsyMDEyLTA5LTA2IDIwOjA5OjA2XSBlbGZfcGFyc2Vf
YmluYXJ5OiBwaGRyOiBwYWRkcj0weDFlZjAwMDAgbWVtc3o9MHhkZTUwMDANCihYRU4pIFsy
MDEyLTA5LTA2IDIwOjA5OjA2XSBlbGZfcGFyc2VfYmluYXJ5OiBtZW1vcnk6IDB4MTAwMDAw
MCAtPiAweDJjZDUwMDANCihYRU4pIFsyMDEyLTA5LTA2IDIwOjA5OjA2XSBlbGZfeGVuX3Bh
cnNlX25vdGU6IEdVRVNUX09TID0gImxpbnV4Ig0KKFhFTikgWzIwMTItMDktMDYgMjA6MDk6
MDZdIGVsZl94ZW5fcGFyc2Vfbm90ZTogR1VFU1RfVkVSU0lPTiA9ICIyLjYiDQooWEVOKSBb
MjAxMi0wOS0wNiAyMDowOTowNl0gZWxmX3hlbl9wYXJzZV9ub3RlOiBYRU5fVkVSU0lPTiA9
ICJ4ZW4tMy4wIg0KKFhFTikgWzIwMTItMDktMDYgMjA6MDk6MDZdIGVsZl94ZW5fcGFyc2Vf
bm90ZTogVklSVF9CQVNFID0gMHhmZmZmZmZmZjgwMDAwMDAwDQooWEVOKSBbMjAxMi0wOS0w
NiAyMDowOTowNl0gZWxmX3hlbl9wYXJzZV9ub3RlOiBFTlRSWSA9IDB4ZmZmZmZmZmY4MWVm
MDIxMA0KKFhFTikgWzIwMTItMDktMDYgMjA6MDk6MDZdIGVsZl94ZW5fcGFyc2Vfbm90ZTog
SFlQRVJDQUxMX1BBR0UgPSAweGZmZmZmZmZmODEwMDEwMDANCihYRU4pIFsyMDEyLTA5LTA2
IDIwOjA5OjA2XSBlbGZfeGVuX3BhcnNlX25vdGU6IEZFQVRVUkVTID0gIiF3cml0YWJsZV9w
YWdlX3RhYmxlc3xwYWVfcGdkaXJfYWJvdmVfNGdiIg0KKFhFTikgWzIwMTItMDktMDYgMjA6
MDk6MDZdIGVsZl94ZW5fcGFyc2Vfbm90ZTogUEFFX01PREUgPSAieWVzIg0KKFhFTikgWzIw
MTItMDktMDYgMjA6MDk6MDZdIGVsZl94ZW5fcGFyc2Vfbm90ZTogTE9BREVSID0gImdlbmVy
aWMiDQooWEVOKSBbMjAxMi0wOS0wNiAyMDowOTowNl0gZWxmX3hlbl9wYXJzZV9ub3RlOiB1
bmtub3duIHhlbiBlbGYgbm90ZSAoMHhkKQ0KKFhFTikgWzIwMTItMDktMDYgMjA6MDk6MDZd
IGVsZl94ZW5fcGFyc2Vfbm90ZTogU1VTUEVORF9DQU5DRUwgPSAweDENCihYRU4pIFsyMDEy
LTA5LTA2IDIwOjA5OjA2XSBlbGZfeGVuX3BhcnNlX25vdGU6IEhWX1NUQVJUX0xPVyA9IDB4
ZmZmZjgwMDAwMDAwMDAwMA0KKFhFTikgWzIwMTItMDktMDYgMjA6MDk6MDZdIGVsZl94ZW5f
cGFyc2Vfbm90ZTogUEFERFJfT0ZGU0VUID0gMHgwDQooWEVOKSBbMjAxMi0wOS0wNiAyMDow
OTowNl0gZWxmX3hlbl9hZGRyX2NhbGNfY2hlY2s6IGFkZHJlc3NlczoNCihYRU4pIFsyMDEy
LTA5LTA2IDIwOjA5OjA2XSAgICAgdmlydF9iYXNlICAgICAgICA9IDB4ZmZmZmZmZmY4MDAw
MDAwMA0KKFhFTikgWzIwMTItMDktMDYgMjA6MDk6MDZdICAgICBlbGZfcGFkZHJfb2Zmc2V0
ID0gMHgwDQooWEVOKSBbMjAxMi0wOS0wNiAyMDowOTowNl0gICAgIHZpcnRfb2Zmc2V0ICAg
ICAgPSAweGZmZmZmZmZmODAwMDAwMDANCihYRU4pIFsyMDEyLTA5LTA2IDIwOjA5OjA2XSAg
ICAgdmlydF9rc3RhcnQgICAgICA9IDB4ZmZmZmZmZmY4MTAwMDAwMA0KKFhFTikgWzIwMTIt
MDktMDYgMjA6MDk6MDZdICAgICB2aXJ0X2tlbmQgICAgICAgID0gMHhmZmZmZmZmZjgyY2Q1
MDAwDQooWEVOKSBbMjAxMi0wOS0wNiAyMDowOTowNl0gICAgIHZpcnRfZW50cnkgICAgICAg
PSAweGZmZmZmZmZmODFlZjAyMTANCihYRU4pIFsyMDEyLTA5LTA2IDIwOjA5OjA2XSAgICAg
cDJtX2Jhc2UgICAgICAgICA9IDB4ZmZmZmZmZmZmZmZmZmZmZg0KKFhFTikgWzIwMTItMDkt
MDYgMjA6MDk6MDZdICBYZW4gIGtlcm5lbDogNjQtYml0LCBsc2IsIGNvbXBhdDMyDQooWEVO
KSBbMjAxMi0wOS0wNiAyMDowOTowNl0gIERvbTAga2VybmVsOiA2NC1iaXQsIFBBRSwgbHNi
LCBwYWRkciAweDEwMDAwMDAgLT4gMHgyY2Q1MDAwDQooWEVOKSBbMjAxMi0wOS0wNiAyMDow
OTowNl0gUEhZU0lDQUwgTUVNT1JZIEFSUkFOR0VNRU5UOg0KKFhFTikgWzIwMTItMDktMDYg
MjA6MDk6MDZdICBEb20wIGFsbG9jLjogICAwMDAwMDAwMjQwMDAwMDAwLT4wMDAwMDAwMjQ0
MDAwMDAwICgyNDI0MjggcGFnZXMgdG8gYmUgYWxsb2NhdGVkKQ0KKFhFTikgWzIwMTItMDkt
MDYgMjA6MDk6MDZdICBJbml0LiByYW1kaXNrOiAwMDAwMDAwMjRmMmZjMDAwLT4wMDAwMDAw
MjRmZmZmODAwDQooWEVOKSBbMjAxMi0wOS0wNiAyMDowOTowNl0gVklSVFVBTCBNRU1PUlkg
QVJSQU5HRU1FTlQ6DQooWEVOKSBbMjAxMi0wOS0wNiAyMDowOTowNl0gIExvYWRlZCBrZXJu
ZWw6IGZmZmZmZmZmODEwMDAwMDAtPmZmZmZmZmZmODJjZDUwMDANCihYRU4pIFsyMDEyLTA5
LTA2IDIwOjA5OjA2XSAgSW5pdC4gcmFtZGlzazogZmZmZmZmZmY4MmNkNTAwMC0+ZmZmZmZm
ZmY4MzlkODgwMA0KKFhFTikgWzIwMTItMDktMDYgMjA6MDk6MDZdICBQaHlzLU1hY2ggbWFw
OiBmZmZmZmZmZjgzOWQ5MDAwLT5mZmZmZmZmZjgzYmQ5MDAwDQooWEVOKSBbMjAxMi0wOS0w
NiAyMDowOTowNl0gIFN0YXJ0IGluZm86ICAgIGZmZmZmZmZmODNiZDkwMDAtPmZmZmZmZmZm
ODNiZDk0YjQNCihYRU4pIFsyMDEyLTA5LTA2IDIwOjA5OjA2XSAgUGFnZSB0YWJsZXM6ICAg
ZmZmZmZmZmY4M2JkYTAwMC0+ZmZmZmZmZmY4M2JmZDAwMA0KKFhFTikgWzIwMTItMDktMDYg
MjA6MDk6MDZdICBCb290IHN0YWNrOiAgICBmZmZmZmZmZjgzYmZkMDAwLT5mZmZmZmZmZjgz
YmZlMDAwDQooWEVOKSBbMjAxMi0wOS0wNiAyMDowOTowNl0gIFRPVEFMOiAgICAgICAgIGZm
ZmZmZmZmODAwMDAwMDAtPmZmZmZmZmZmODQwMDAwMDANCihYRU4pIFsyMDEyLTA5LTA2IDIw
OjA5OjA2XSAgRU5UUlkgQUREUkVTUzogZmZmZmZmZmY4MWVmMDIxMA0KKFhFTikgWzIwMTIt
MDktMDYgMjA6MDk6MDZdIERvbTAgaGFzIG1heGltdW0gNiBWQ1BVcw0KKFhFTikgWzIwMTIt
MDktMDYgMjA6MDk6MDZdIGVsZl9sb2FkX2JpbmFyeTogcGhkciAwIGF0IDB4ZmZmZmZmZmY4
MTAwMDAwMCAtPiAweGZmZmZmZmZmODFkNmEwMDANCihYRU4pIFsyMDEyLTA5LTA2IDIwOjA5
OjA2XSBlbGZfbG9hZF9iaW5hcnk6IHBoZHIgMSBhdCAweGZmZmZmZmZmODFlMDAwMDAgLT4g
MHhmZmZmZmZmZjgxZWRiMGU4DQooWEVOKSBbMjAxMi0wOS0wNiAyMDowOTowNl0gZWxmX2xv
YWRfYmluYXJ5OiBwaGRyIDIgYXQgMHhmZmZmZmZmZjgxZWRjMDAwIC0+IDB4ZmZmZmZmZmY4
MWVlZmMwMA0KKFhFTikgWzIwMTItMDktMDYgMjA6MDk6MDZdIGVsZl9sb2FkX2JpbmFyeTog
cGhkciAzIGF0IDB4ZmZmZmZmZmY4MWVmMDAwMCAtPiAweGZmZmZmZmZmODFmODkwMDANCihY
RU4pIFsyMDEyLTA5LTA2IDIwOjA5OjA3XSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxl
OiBkZXZpY2UgaWQgPSAweDAwMDAsIHJvb3QgdGFibGUgPSAweDI0ZDg0YjAwMCwgZG9tYWlu
ID0gMCwgcGFnaW5nIG1vZGUgPSAzDQooWEVOKSBbMjAxMi0wOS0wNiAyMDowOTowN10gQU1E
LVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHgwMDAyLCByb290IHRh
YmxlID0gMHgyNGQ4NGIwMDAsIGRvbWFpbiA9IDAsIHBhZ2luZyBtb2RlID0gMw0KKFhFTikg
WzIwMTItMDktMDYgMjA6MDk6MDddIEFNRC1WaTogU2V0dXAgSS9PIHBhZ2UgdGFibGU6IGRl
dmljZSBpZCA9IDB4MDAxMCwgcm9vdCB0YWJsZSA9IDB4MjRkODRiMDAwLCBkb21haW4gPSAw
LCBwYWdpbmcgbW9kZSA9IDMNCihYRU4pIFsyMDEyLTA5LTA2IDIwOjA5OjA3XSBBTUQtVmk6
IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweDAwMTgsIHJvb3QgdGFibGUg
PSAweDI0ZDg0YjAwMCwgZG9tYWluID0gMCwgcGFnaW5nIG1vZGUgPSAzDQooWEVOKSBbMjAx
Mi0wOS0wNiAyMDowOTowN10gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNl
IGlkID0gMHgwMDI4LCByb290IHRhYmxlID0gMHgyNGQ4NGIwMDAsIGRvbWFpbiA9IDAsIHBh
Z2luZyBtb2RlID0gMw0KKFhFTikgWzIwMTItMDktMDYgMjA6MDk6MDddIEFNRC1WaTogU2V0
dXAgSS9PIHBhZ2UgdGFibGU6IGRldmljZSBpZCA9IDB4MDAzMCwgcm9vdCB0YWJsZSA9IDB4
MjRkODRiMDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMNCihYRU4pIFsyMDEyLTA5
LTA2IDIwOjA5OjA3XSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQg
PSAweDAwNTAsIHJvb3QgdGFibGUgPSAweDI0ZDg0YjAwMCwgZG9tYWluID0gMCwgcGFnaW5n
IG1vZGUgPSAzDQooWEVOKSBbMjAxMi0wOS0wNiAyMDowOTowN10gQU1ELVZpOiBTZXR1cCBJ
L08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHgwMDU4LCByb290IHRhYmxlID0gMHgyNGQ4
NGIwMDAsIGRvbWFpbiA9IDAsIHBhZ2luZyBtb2RlID0gMw0KKFhFTikgWzIwMTItMDktMDYg
MjA6MDk6MDddIEFNRC1WaTogU2V0dXAgSS9PIHBhZ2UgdGFibGU6IGRldmljZSBpZCA9IDB4
MDA2MCwgcm9vdCB0YWJsZSA9IDB4MjRkODRiMDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9k
ZSA9IDMNCihYRU4pIFsyMDEyLTA5LTA2IDIwOjA5OjA3XSBBTUQtVmk6IFNldHVwIEkvTyBw
YWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweDAwNjgsIHJvb3QgdGFibGUgPSAweDI0ZDg0YjAw
MCwgZG9tYWluID0gMCwgcGFnaW5nIG1vZGUgPSAzDQooWEVOKSBbMjAxMi0wOS0wNiAyMDow
OTowN10gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHgwMDg4
LCByb290IHRhYmxlID0gMHgyNGQ4NGIwMDAsIGRvbWFpbiA9IDAsIHBhZ2luZyBtb2RlID0g
Mw0KKFhFTikgWzIwMTItMDktMDYgMjA6MDk6MDddIEFNRC1WaTogU2V0dXAgSS9PIHBhZ2Ug
dGFibGU6IGRldmljZSBpZCA9IDB4MDA5MCwgcm9vdCB0YWJsZSA9IDB4MjRkODRiMDAwLCBk
b21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMNCihYRU4pIFsyMDEyLTA5LTA2IDIwOjA5OjA3
XSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweDAwOTIsIHJv
b3QgdGFibGUgPSAweDI0ZDg0YjAwMCwgZG9tYWluID0gMCwgcGFnaW5nIG1vZGUgPSAzDQoo
WEVOKSBbMjAxMi0wOS0wNiAyMDowOTowN10gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJs
ZTogZGV2aWNlIGlkID0gMHgwMDk4LCByb290IHRhYmxlID0gMHgyNGQ4NGIwMDAsIGRvbWFp
biA9IDAsIHBhZ2luZyBtb2RlID0gMw0KKFhFTikgWzIwMTItMDktMDYgMjA6MDk6MDddIEFN
RC1WaTogU2V0dXAgSS9PIHBhZ2UgdGFibGU6IGRldmljZSBpZCA9IDB4MDA5YSwgcm9vdCB0
YWJsZSA9IDB4MjRkODRiMDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMNCihYRU4p
IFsyMDEyLTA5LTA2IDIwOjA5OjA3XSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBk
ZXZpY2UgaWQgPSAweDAwYTAsIHJvb3QgdGFibGUgPSAweDI0ZDg0YjAwMCwgZG9tYWluID0g
MCwgcGFnaW5nIG1vZGUgPSAzDQooWEVOKSBbMjAxMi0wOS0wNiAyMDowOTowN10gQU1ELVZp
OiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHgwMGEzLCByb290IHRhYmxl
ID0gMHgyNGQ4NGIwMDAsIGRvbWFpbiA9IDAsIHBhZ2luZyBtb2RlID0gMw0KKFhFTikgWzIw
MTItMDktMDYgMjA6MDk6MDddIEFNRC1WaTogU2V0dXAgSS9PIHBhZ2UgdGFibGU6IGRldmlj
ZSBpZCA9IDB4MDBhNCwgcm9vdCB0YWJsZSA9IDB4MjRkODRiMDAwLCBkb21haW4gPSAwLCBw
YWdpbmcgbW9kZSA9IDMNCihYRU4pIFsyMDEyLTA5LTA2IDIwOjA5OjA3XSBBTUQtVmk6IFNl
dHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweDAwYTUsIHJvb3QgdGFibGUgPSAw
eDI0ZDg0YjAwMCwgZG9tYWluID0gMCwgcGFnaW5nIG1vZGUgPSAzDQooWEVOKSBbMjAxMi0w
OS0wNiAyMDowOTowN10gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlk
ID0gMHgwMGE4LCByb290IHRhYmxlID0gMHgyNGQ4NGIwMDAsIGRvbWFpbiA9IDAsIHBhZ2lu
ZyBtb2RlID0gMw0KKFhFTikgWzIwMTItMDktMDYgMjA6MDk6MDddIEFNRC1WaTogU2V0dXAg
SS9PIHBhZ2UgdGFibGU6IGRldmljZSBpZCA9IDB4MDBiMCwgcm9vdCB0YWJsZSA9IDB4MjRk
ODRiMDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMNCihYRU4pIFsyMDEyLTA5LTA2
IDIwOjA5OjA3XSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAw
eDAwYjIsIHJvb3QgdGFibGUgPSAweDI0ZDg0YjAwMCwgZG9tYWluID0gMCwgcGFnaW5nIG1v
ZGUgPSAzDQooWEVOKSBbMjAxMi0wOS0wNiAyMDowOTowN10gQU1ELVZpOiBObyBpb21tdSBm
b3IgZGV2aWNlIDAwMDA6MDA6MTguMA0KKFhFTikgWzIwMTItMDktMDYgMjA6MDk6MDddIEFN
RC1WaTogTm8gaW9tbXUgZm9yIGRldmljZSAwMDAwOjAwOjE4LjENCihYRU4pIFsyMDEyLTA5
LTA2IDIwOjA5OjA3XSBBTUQtVmk6IE5vIGlvbW11IGZvciBkZXZpY2UgMDAwMDowMDoxOC4y
DQooWEVOKSBbMjAxMi0wOS0wNiAyMDowOTowN10gQU1ELVZpOiBObyBpb21tdSBmb3IgZGV2
aWNlIDAwMDA6MDA6MTguMw0KKFhFTikgWzIwMTItMDktMDYgMjA6MDk6MDddIEFNRC1WaTog
Tm8gaW9tbXUgZm9yIGRldmljZSAwMDAwOjAwOjE4LjQNCihYRU4pIFsyMDEyLTA5LTA2IDIw
OjA5OjA3XSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweDA0
MDAsIHJvb3QgdGFibGUgPSAweDI0ZDg0YjAwMCwgZG9tYWluID0gMCwgcGFnaW5nIG1vZGUg
PSAzDQooWEVOKSBbMjAxMi0wOS0wNiAyMDowOTowN10gQU1ELVZpOiBTZXR1cCBJL08gcGFn
ZSB0YWJsZTogZGV2aWNlIGlkID0gMHgwNDAxLCByb290IHRhYmxlID0gMHgyNGQ4NGIwMDAs
IGRvbWFpbiA9IDAsIHBhZ2luZyBtb2RlID0gMw0KKFhFTikgWzIwMTItMDktMDYgMjA6MDk6
MDddIEFNRC1WaTogU2V0dXAgSS9PIHBhZ2UgdGFibGU6IGRldmljZSBpZCA9IDB4MDQwMiwg
cm9vdCB0YWJsZSA9IDB4MjRkODRiMDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMN
CihYRU4pIFsyMDEyLTA5LTA2IDIwOjA5OjA3XSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRh
YmxlOiBkZXZpY2UgaWQgPSAweDA0MDMsIHJvb3QgdGFibGUgPSAweDI0ZDg0YjAwMCwgZG9t
YWluID0gMCwgcGFnaW5nIG1vZGUgPSAzDQooWEVOKSBbMjAxMi0wOS0wNiAyMDowOTowN10g
QU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHgwNDA0LCByb290
IHRhYmxlID0gMHgyNGQ4NGIwMDAsIGRvbWFpbiA9IDAsIHBhZ2luZyBtb2RlID0gMw0KKFhF
TikgWzIwMTItMDktMDYgMjA6MDk6MDddIEFNRC1WaTogU2V0dXAgSS9PIHBhZ2UgdGFibGU6
IGRldmljZSBpZCA9IDB4MDQwNSwgcm9vdCB0YWJsZSA9IDB4MjRkODRiMDAwLCBkb21haW4g
PSAwLCBwYWdpbmcgbW9kZSA9IDMNCihYRU4pIFsyMDEyLTA5LTA2IDIwOjA5OjA3XSBBTUQt
Vmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweDA0MDYsIHJvb3QgdGFi
bGUgPSAweDI0ZDg0YjAwMCwgZG9tYWluID0gMCwgcGFnaW5nIG1vZGUgPSAzDQooWEVOKSBb
MjAxMi0wOS0wNiAyMDowOTowN10gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2
aWNlIGlkID0gMHgwNDA3LCByb290IHRhYmxlID0gMHgyNGQ4NGIwMDAsIGRvbWFpbiA9IDAs
IHBhZ2luZyBtb2RlID0gMw0KKFhFTikgWzIwMTItMDktMDYgMjA6MDk6MDddIEFNRC1WaTog
U2V0dXAgSS9PIHBhZ2UgdGFibGU6IGRldmljZSBpZCA9IDB4MDUwMCwgcm9vdCB0YWJsZSA9
IDB4MjRkODRiMDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMNCihYRU4pIFsyMDEy
LTA5LTA2IDIwOjA5OjA3XSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2Ug
aWQgPSAweDA2MDAsIHJvb3QgdGFibGUgPSAweDI0ZDg0YjAwMCwgZG9tYWluID0gMCwgcGFn
aW5nIG1vZGUgPSAzDQooWEVOKSBbMjAxMi0wOS0wNiAyMDowOTowN10gQU1ELVZpOiBTZXR1
cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHgwNjAxLCByb290IHRhYmxlID0gMHgy
NGQ4NGIwMDAsIGRvbWFpbiA9IDAsIHBhZ2luZyBtb2RlID0gMw0KKFhFTikgWzIwMTItMDkt
MDYgMjA6MDk6MDddIEFNRC1WaTogU2V0dXAgSS9PIHBhZ2UgdGFibGU6IGRldmljZSBpZCA9
IDB4MDcwMCwgcm9vdCB0YWJsZSA9IDB4MjRkODRiMDAwLCBkb21haW4gPSAwLCBwYWdpbmcg
bW9kZSA9IDMNCihYRU4pIFsyMDEyLTA5LTA2IDIwOjA5OjA3XSBBTUQtVmk6IFNldHVwIEkv
TyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweDA4MDAsIHJvb3QgdGFibGUgPSAweDI0ZDg0
YjAwMCwgZG9tYWluID0gMCwgcGFnaW5nIG1vZGUgPSAzDQooWEVOKSBbMjAxMi0wOS0wNiAy
MDowOTowN10gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHgw
OTAwLCByb290IHRhYmxlID0gMHgyNGQ4NGIwMDAsIGRvbWFpbiA9IDAsIHBhZ2luZyBtb2Rl
ID0gMw0KKFhFTikgWzIwMTItMDktMDYgMjA6MDk6MDddIEFNRC1WaTogU2V0dXAgSS9PIHBh
Z2UgdGFibGU6IGRldmljZSBpZCA9IDB4MGEwMCwgcm9vdCB0YWJsZSA9IDB4MjRkODRiMDAw
LCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMNCihYRU4pIFsyMDEyLTA5LTA2IDIwOjA5
OjA3XSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweDBhMDEs
IHJvb3QgdGFibGUgPSAweDI0ZDg0YjAwMCwgZG9tYWluID0gMCwgcGFnaW5nIG1vZGUgPSAz
DQooWEVOKSBbMjAxMi0wOS0wNiAyMDowOTowN10gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0
YWJsZTogZGV2aWNlIGlkID0gMHgwYTAyLCByb290IHRhYmxlID0gMHgyNGQ4NGIwMDAsIGRv
bWFpbiA9IDAsIHBhZ2luZyBtb2RlID0gMw0KKFhFTikgWzIwMTItMDktMDYgMjA6MDk6MDdd
IEFNRC1WaTogU2V0dXAgSS9PIHBhZ2UgdGFibGU6IGRldmljZSBpZCA9IDB4MGEwMywgcm9v
dCB0YWJsZSA9IDB4MjRkODRiMDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMNCihY
RU4pIFsyMDEyLTA5LTA2IDIwOjA5OjA3XSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxl
OiBkZXZpY2UgaWQgPSAweDBhMDQsIHJvb3QgdGFibGUgPSAweDI0ZDg0YjAwMCwgZG9tYWlu
ID0gMCwgcGFnaW5nIG1vZGUgPSAzDQooWEVOKSBbMjAxMi0wOS0wNiAyMDowOTowN10gQU1E
LVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHgwYTA1LCByb290IHRh
YmxlID0gMHgyNGQ4NGIwMDAsIGRvbWFpbiA9IDAsIHBhZ2luZyBtb2RlID0gMw0KKFhFTikg
WzIwMTItMDktMDYgMjA6MDk6MDddIEFNRC1WaTogU2V0dXAgSS9PIHBhZ2UgdGFibGU6IGRl
dmljZSBpZCA9IDB4MGEwNiwgcm9vdCB0YWJsZSA9IDB4MjRkODRiMDAwLCBkb21haW4gPSAw
LCBwYWdpbmcgbW9kZSA9IDMNCihYRU4pIFsyMDEyLTA5LTA2IDIwOjA5OjA3XSBBTUQtVmk6
IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweDBhMDcsIHJvb3QgdGFibGUg
PSAweDI0ZDg0YjAwMCwgZG9tYWluID0gMCwgcGFnaW5nIG1vZGUgPSAzDQooWEVOKSBbMjAx
Mi0wOS0wNiAyMDowOTowN10gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNl
IGlkID0gMHgwYjAwLCByb290IHRhYmxlID0gMHgyNGQ4NGIwMDAsIGRvbWFpbiA9IDAsIHBh
Z2luZyBtb2RlID0gMw0KKFhFTikgWzIwMTItMDktMDYgMjA6MDk6MDddIFNjcnViYmluZyBG
cmVlIFJBTTogLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi48MD5BTUQtVmk6IElPX1BBR0Vf
RkFVTFQ6IGRvbWFpbiA9IDAsIGRldmljZSBpZCA9IDB4MGEwNiwgZmF1bHQgYWRkcmVzcyA9
IDB4YzJjMmMyYzAsIGZsYWdzID0gMHgwMDANCihYRU4pIFsyMDEyLTA5LTA2IDIwOjA5OjA4
XSAuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi5kb25lLg0K
KFhFTikgWzIwMTItMDktMDYgMjA6MDk6MDldIEluaXRpYWwgbG93IG1lbW9yeSB2aXJxIHRo
cmVzaG9sZCBzZXQgYXQgMHg0MDAwIHBhZ2VzLg0KKFhFTikgWzIwMTItMDktMDYgMjA6MDk6
MDldIFN0ZC4gTG9nbGV2ZWw6IEFsbA0KKFhFTikgWzIwMTItMDktMDYgMjA6MDk6MDldIEd1
ZXN0IExvZ2xldmVsOiBBbGwNCihYRU4pIFsyMDEyLTA5LTA2IDIwOjA5OjA5XSBYZW4gaXMg
cmVsaW5xdWlzaGluZyBWR0EgY29uc29sZS4NCihYRU4pIFsyMDEyLTA5LTA2IDIwOjA5OjA5
XSAqKiogU2VyaWFsIGlucHV0IC0+IERPTTAgKHR5cGUgJ0NUUkwtYScgdGhyZWUgdGltZXMg
dG8gc3dpdGNoIGlucHV0IHRvIFhlbikNCihYRU4pIFsyMDEyLTA5LTA2IDIwOjA5OjA5XSBG
cmVlZCAyNTZrQiBpbml0IG1lbW9yeS4NCihYRU4pIFsyMDEyLTA5LTA2IDIwOjA5OjA5XSBJ
T0FQSUNbMF06IFNldCBQQ0kgcm91dGluZyBlbnRyeSAoNi05IC0+IDB4NjAgLT4gSVJRIDkg
TW9kZToxIEFjdGl2ZToxKQ0KKFhFTikgWzIwMTItMDktMDYgMjA6MDk6MDldIHRyYXBzLmM6
MjU4NDpkMCBEb21haW4gYXR0ZW1wdGVkIFdSTVNSIDAwMDAwMDAwYzAwMDA0MDggZnJvbSAw
eGMwMDAwMDAwMDEwMDAwMDAgdG8gMHhjMDA4MDAwMDAxMDAwMDAwLg0KKFhFTikgWzIwMTIt
MDktMDYgMjA6MDk6MDldIHRyYXBzLmM6MjU4NDpkMCBEb21haW4gYXR0ZW1wdGVkIFdSTVNS
IDAwMDAwMDAwYzAwMDA0MDkgZnJvbSAweGMwMDAwMDAwMDEwMDAwMDAgdG8gMHhjMDA4MDAw
MDAxMDAwMDAwLg0KKFhFTikgWzIwMTItMDktMDYgMjA6MDk6MDldIHRyYXBzLmM6MjU4NDpk
MCBEb21haW4gYXR0ZW1wdGVkIFdSTVNSIDAwMDAwMDAwYzAwMTAwMDQgZnJvbSAweDAwMDBl
ZmYwYmRmYjFmY2UgdG8gMHgwMDAwMDAwMDAwMDBhYmNkLg0KKFhFTikgWzIwMTItMDktMDYg
MjA6MDk6MDldIHRyYXBzLmM6MjU4NDpkMCBEb21haW4gYXR0ZW1wdGVkIFdSTVNSIDAwMDAw
MDAwYzAwMDA0MDggZnJvbSAweGMwMDAwMDAwMDEwMDAwMDAgdG8gMHhjMDA4MDAwMDAxMDAw
MDAwLg0KKFhFTikgWzIwMTItMDktMDYgMjA6MDk6MDldIHRyYXBzLmM6MjU4NDpkMCBEb21h
aW4gYXR0ZW1wdGVkIFdSTVNSIDAwMDAwMDAwYzAwMDA0MDkgZnJvbSAweGMwMDAwMDAwMDEw
MDAwMDAgdG8gMHhjMDA4MDAwMDAxMDAwMDAwLg0KKFhFTikgWzIwMTItMDktMDYgMjA6MDk6
MDldIHRyYXBzLmM6MjU4NDpkMCBEb21haW4gYXR0ZW1wdGVkIFdSTVNSIDAwMDAwMDAwYzAw
MDA0MDggZnJvbSAweGMwMDAwMDAwMDEwMDAwMDAgdG8gMHhjMDA4MDAwMDAxMDAwMDAwLg0K
KFhFTikgWzIwMTItMDktMDYgMjA6MDk6MDldIHRyYXBzLmM6MjU4NDpkMCBEb21haW4gYXR0
ZW1wdGVkIFdSTVNSIDAwMDAwMDAwYzAwMDA0MDkgZnJvbSAweGMwMDAwMDAwMDEwMDAwMDAg
dG8gMHhjMDA4MDAwMDAxMDAwMDAwLg0KKFhFTikgWzIwMTItMDktMDYgMjA6MDk6MDldIHRy
YXBzLmM6MjU4NDpkMCBEb21haW4gYXR0ZW1wdGVkIFdSTVNSIDAwMDAwMDAwYzAwMDA0MDgg
ZnJvbSAweGMwMDAwMDAwMDEwMDAwMDAgdG8gMHhjMDA4MDAwMDAxMDAwMDAwLg0KKFhFTikg
WzIwMTItMDktMDYgMjA6MDk6MDldIHRyYXBzLmM6MjU4NDpkMCBEb21haW4gYXR0ZW1wdGVk
IFdSTVNSIDAwMDAwMDAwYzAwMDA0MDkgZnJvbSAweGMwMDAwMDAwMDEwMDAwMDAgdG8gMHhj
MDA4MDAwMDAxMDAwMDAwLg0KKFhFTikgWzIwMTItMDktMDYgMjA6MDk6MDldIHRyYXBzLmM6
MjU4NDpkMCBEb21haW4gYXR0ZW1wdGVkIFdSTVNSIDAwMDAwMDAwYzAwMDA0MDggZnJvbSAw
eGMwMDAwMDAwMDEwMDAwMDAgdG8gMHhjMDA4MDAwMDAxMDAwMDAwLg0KKFhFTikgWzIwMTIt
MDktMDYgMjA6MDk6MDldIHRyYXBzLmM6MjU4NDpkMCBEb21haW4gYXR0ZW1wdGVkIFdSTVNS
IDAwMDAwMDAwYzAwMDA0MDkgZnJvbSAweGMwMDAwMDAwMDEwMDAwMDAgdG8gMHhjMDA4MDAw
MDAxMDAwMDAwLg0KKFhFTikgWzIwMTItMDktMDYgMjA6MDk6MDldIHRyYXBzLmM6MjU4NDpk
MCBEb21haW4gYXR0ZW1wdGVkIFdSTVNSIDAwMDAwMDAwYzAwMDA0MDggZnJvbSAweGMwMDAw
MDAwMDEwMDAwMDAgdG8gMHhjMDA4MDAwMDAxMDAwMDAwLg0KKFhFTikgWzIwMTItMDktMDYg
MjA6MDk6MDldIHRyYXBzLmM6MjU4NDpkMCBEb21haW4gYXR0ZW1wdGVkIFdSTVNSIDAwMDAw
MDAwYzAwMDA0MDkgZnJvbSAweGMwMDAwMDAwMDEwMDAwMDAgdG8gMHhjMDA4MDAwMDAxMDAw
MDAwLg0KKFhFTikgWzIwMTItMDktMDYgMjA6MDk6MTBdIFBDSSBhZGQgZGV2aWNlIDAwMDA6
MDA6MDAuMA0KKFhFTikgWzIwMTItMDktMDYgMjA6MDk6MTBdIFBDSSBhZGQgZGV2aWNlIDAw
MDA6MDA6MDAuMg0KKFhFTikgWzIwMTItMDktMDYgMjA6MDk6MTBdIFBDSSBhZGQgZGV2aWNl
IDAwMDA6MDA6MDIuMA0KKFhFTikgWzIwMTItMDktMDYgMjA6MDk6MTBdIFBDSSBhZGQgZGV2
aWNlIDAwMDA6MDA6MDMuMA0KKFhFTikgWzIwMTItMDktMDYgMjA6MDk6MTBdIFBDSSBhZGQg
ZGV2aWNlIDAwMDA6MDA6MDUuMA0KKFhFTikgWzIwMTItMDktMDYgMjA6MDk6MTBdIFBDSSBh
ZGQgZGV2aWNlIDAwMDA6MDA6MDYuMA0KKFhFTikgWzIwMTItMDktMDYgMjA6MDk6MTBdIFBD
SSBhZGQgZGV2aWNlIDAwMDA6MDA6MGEuMA0KKFhFTikgWzIwMTItMDktMDYgMjA6MDk6MTBd
IFBDSSBhZGQgZGV2aWNlIDAwMDA6MDA6MGIuMA0KKFhFTikgWzIwMTItMDktMDYgMjA6MDk6
MTBdIFBDSSBhZGQgZGV2aWNlIDAwMDA6MDA6MGMuMA0KKFhFTikgWzIwMTItMDktMDYgMjA6
MDk6MTBdIFBDSSBhZGQgZGV2aWNlIDAwMDA6MDA6MGQuMA0KKFhFTikgWzIwMTItMDktMDYg
MjA6MDk6MTBdIFBDSSBhZGQgZGV2aWNlIDAwMDA6MDA6MTEuMA0KKFhFTikgWzIwMTItMDkt
MDYgMjA6MDk6MTBdIFBDSSBhZGQgZGV2aWNlIDAwMDA6MDA6MTIuMA0KKFhFTikgWzIwMTIt
MDktMDYgMjA6MDk6MTBdIFBDSSBhZGQgZGV2aWNlIDAwMDA6MDA6MTIuMg0KKFhFTikgWzIw
MTItMDktMDYgMjA6MDk6MTBdIFBDSSBhZGQgZGV2aWNlIDAwMDA6MDA6MTMuMA0KKFhFTikg
WzIwMTItMDktMDYgMjA6MDk6MTBdIFBDSSBhZGQgZGV2aWNlIDAwMDA6MDA6MTMuMg0KKFhF
TikgWzIwMTItMDktMDYgMjA6MDk6MTBdIFBDSSBhZGQgZGV2aWNlIDAwMDA6MDA6MTQuMA0K
KFhFTikgWzIwMTItMDktMDYgMjA6MDk6MTBdIFBDSSBhZGQgZGV2aWNlIDAwMDA6MDA6MTQu
Mw0KKFhFTikgWzIwMTItMDktMDYgMjA6MDk6MTBdIFBDSSBhZGQgZGV2aWNlIDAwMDA6MDA6
MTQuNA0KKFhFTikgWzIwMTItMDktMDYgMjA6MDk6MTBdIFBDSSBhZGQgZGV2aWNlIDAwMDA6
MDA6MTQuNQ0KKFhFTikgWzIwMTItMDktMDYgMjA6MDk6MTBdIFBDSSBhZGQgZGV2aWNlIDAw
MDA6MDA6MTUuMA0KKFhFTikgWzIwMTItMDktMDYgMjA6MDk6MTBdIFBDSSBhZGQgZGV2aWNl
IDAwMDA6MDA6MTYuMA0KKFhFTikgWzIwMTItMDktMDYgMjA6MDk6MTBdIFBDSSBhZGQgZGV2
aWNlIDAwMDA6MDA6MTYuMg0KKFhFTikgWzIwMTItMDktMDYgMjA6MDk6MTBdIFBDSSBhZGQg
ZGV2aWNlIDAwMDA6MDA6MTguMA0KKFhFTikgWzIwMTItMDktMDYgMjA6MDk6MTBdIFBDSSBh
ZGQgZGV2aWNlIDAwMDA6MDA6MTguMQ0KKFhFTikgWzIwMTItMDktMDYgMjA6MDk6MTBdIFBD
SSBhZGQgZGV2aWNlIDAwMDA6MDA6MTguMg0KKFhFTikgWzIwMTItMDktMDYgMjA6MDk6MTBd
IFBDSSBhZGQgZGV2aWNlIDAwMDA6MDA6MTguMw0KKFhFTikgWzIwMTItMDktMDYgMjA6MDk6
MTBdIFBDSSBhZGQgZGV2aWNlIDAwMDA6MDA6MTguNA0KKFhFTikgWzIwMTItMDktMDYgMjA6
MDk6MTBdIFBDSSBhZGQgZGV2aWNlIDAwMDA6MGI6MDAuMA0KKFhFTikgWzIwMTItMDktMDYg
MjA6MDk6MTBdIFBDSSBhZGQgZGV2aWNlIDAwMDA6MGE6MDAuMA0KKFhFTikgWzIwMTItMDkt
MDYgMjA6MDk6MTBdIFBDSSBhZGQgZGV2aWNlIDAwMDA6MGE6MDAuMQ0KKFhFTikgWzIwMTIt
MDktMDYgMjA6MDk6MTBdIFBDSSBhZGQgZGV2aWNlIDAwMDA6MGE6MDAuMg0KKFhFTikgWzIw
MTItMDktMDYgMjA6MDk6MTBdIFBDSSBhZGQgZGV2aWNlIDAwMDA6MGE6MDAuMw0KKFhFTikg
WzIwMTItMDktMDYgMjA6MDk6MTBdIFBDSSBhZGQgZGV2aWNlIDAwMDA6MGE6MDAuNA0KKFhF
TikgWzIwMTItMDktMDYgMjA6MDk6MTBdIFBDSSBhZGQgZGV2aWNlIDAwMDA6MGE6MDAuNQ0K
KFhFTikgWzIwMTItMDktMDYgMjA6MDk6MTBdIFBDSSBhZGQgZGV2aWNlIDAwMDA6MGE6MDAu
Ng0KKFhFTikgWzIwMTItMDktMDYgMjA6MDk6MTBdIFBDSSBhZGQgZGV2aWNlIDAwMDA6MGE6
MDAuNw0KKFhFTikgWzIwMTItMDktMDYgMjA6MDk6MTBdIFBDSSBhZGQgZGV2aWNlIDAwMDA6
MDk6MDAuMA0KKFhFTikgWzIwMTItMDktMDYgMjA6MDk6MTBdIFBDSSBhZGQgZGV2aWNlIDAw
MDA6MDg6MDAuMA0KKFhFTikgWzIwMTItMDktMDYgMjA6MDk6MTBdIFBDSSBhZGQgZGV2aWNl
IDAwMDA6MDc6MDAuMA0KKFhFTikgWzIwMTItMDktMDYgMjA6MDk6MTBdIFBDSSBhZGQgZGV2
aWNlIDAwMDA6MDY6MDAuMA0KKFhFTikgWzIwMTItMDktMDYgMjA6MDk6MTBdIFBDSSBhZGQg
ZGV2aWNlIDAwMDA6MDY6MDAuMQ0KKFhFTikgWzIwMTItMDktMDYgMjA6MDk6MTBdIFBDSSBh
ZGQgZGV2aWNlIDAwMDA6MDU6MDAuMA0KKFhFTikgWzIwMTItMDktMDYgMjA6MDk6MTBdIFBD
SSBhZGQgZGV2aWNlIDAwMDA6MDQ6MDAuMA0KKFhFTikgWzIwMTItMDktMDYgMjA6MDk6MTBd
IFBDSSBhZGQgZGV2aWNlIDAwMDA6MDQ6MDAuMQ0KKFhFTikgWzIwMTItMDktMDYgMjA6MDk6
MTBdIFBDSSBhZGQgZGV2aWNlIDAwMDA6MDQ6MDAuMg0KKFhFTikgWzIwMTItMDktMDYgMjA6
MDk6MTBdIFBDSSBhZGQgZGV2aWNlIDAwMDA6MDQ6MDAuMw0KKFhFTikgWzIwMTItMDktMDYg
MjA6MDk6MTBdIFBDSSBhZGQgZGV2aWNlIDAwMDA6MDQ6MDAuNA0KKFhFTikgWzIwMTItMDkt
MDYgMjA6MDk6MTBdIFBDSSBhZGQgZGV2aWNlIDAwMDA6MDQ6MDAuNQ0KKFhFTikgWzIwMTIt
MDktMDYgMjA6MDk6MTBdIFBDSSBhZGQgZGV2aWNlIDAwMDA6MDQ6MDAuNg0KKFhFTikgWzIw
MTItMDktMDYgMjA6MDk6MTBdIFBDSSBhZGQgZGV2aWNlIDAwMDA6MDQ6MDAuNw0KKFhFTikg
WzIwMTItMDktMDYgMjA6MDk6MTBdIFBDSSBhZGQgZGV2aWNlIDAwMDA6MDM6MDYuMA0KKFhF
TikgWzIwMTItMDktMDYgMjA6MDk6MTBdIElPQVBJQ1swXTogU2V0IFBDSSByb3V0aW5nIGVu
dHJ5ICg2LTggLT4gMHg1OCAtPiBJUlEgOCBNb2RlOjAgQWN0aXZlOjApDQooWEVOKSBbMjAx
Mi0wOS0wNiAyMDowOToxMF0gSU9BUElDWzBdOiBTZXQgUENJIHJvdXRpbmcgZW50cnkgKDYt
MTMgLT4gMHg4OCAtPiBJUlEgMTMgTW9kZTowIEFjdGl2ZTowKQ0KKFhFTikgWzIwMTItMDkt
MDYgMjA6MDk6MTBdIElPQVBJQ1sxXTogU2V0IFBDSSByb3V0aW5nIGVudHJ5ICg3LTI4IC0+
IDB4YTAgLT4gSVJRIDUyIE1vZGU6MSBBY3RpdmU6MSkNCihYRU4pIFsyMDEyLTA5LTA2IDIw
OjA5OjEwXSBJT0FQSUNbMV06IFNldCBQQ0kgcm91dGluZyBlbnRyeSAoNy0yOSAtPiAweGE4
IC0+IElSUSA1MyBNb2RlOjEgQWN0aXZlOjEpDQooWEVOKSBbMjAxMi0wOS0wNiAyMDowOTox
MF0gSU9BUElDWzFdOiBTZXQgUENJIHJvdXRpbmcgZW50cnkgKDctMzAgLT4gMHhiMCAtPiBJ
UlEgNTQgTW9kZToxIEFjdGl2ZToxKQ0KKFhFTikgWzIwMTItMDktMDYgMjA6MDk6MTBdIElP
QVBJQ1swXTogU2V0IFBDSSByb3V0aW5nIGVudHJ5ICg2LTE2IC0+IDB4YjggLT4gSVJRIDE2
IE1vZGU6MSBBY3RpdmU6MSkNCihYRU4pIFsyMDEyLTA5LTA2IDIwOjA5OjEwXSBJT0FQSUNb
MF06IFNldCBQQ0kgcm91dGluZyBlbnRyeSAoNi0xOCAtPiAweGMwIC0+IElSUSAxOCBNb2Rl
OjEgQWN0aXZlOjEpDQooWEVOKSBbMjAxMi0wOS0wNiAyMDowOToxMF0gSU9BUElDWzBdOiBT
ZXQgUENJIHJvdXRpbmcgZW50cnkgKDYtMTcgLT4gMHhjOCAtPiBJUlEgMTcgTW9kZToxIEFj
dGl2ZToxKQ0KKFhFTikgWzIwMTItMDktMDYgMjA6MDk6MTBdIElPQVBJQ1sxXTogU2V0IFBD
SSByb3V0aW5nIGVudHJ5ICg3LTQgLT4gMHhkMCAtPiBJUlEgMjggTW9kZToxIEFjdGl2ZTox
KQ0KKFhFTikgWzIwMTItMDktMDYgMjA6MDk6MTBdIElPQVBJQ1sxXTogU2V0IFBDSSByb3V0
aW5nIGVudHJ5ICg3LTUgLT4gMHhkOCAtPiBJUlEgMjkgTW9kZToxIEFjdGl2ZToxKQ0KKFhF
TikgWzIwMTItMDktMDYgMjA6MDk6MTBdIElPQVBJQ1sxXTogU2V0IFBDSSByb3V0aW5nIGVu
dHJ5ICg3LTYgLT4gMHgyMSAtPiBJUlEgMzAgTW9kZToxIEFjdGl2ZToxKQ0KKFhFTikgWzIw
MTItMDktMDYgMjA6MDk6MTBdIElPQVBJQ1sxXTogU2V0IFBDSSByb3V0aW5nIGVudHJ5ICg3
LTcgLT4gMHgyOSAtPiBJUlEgMzEgTW9kZToxIEFjdGl2ZToxKQ0KKFhFTikgWzIwMTItMDkt
MDYgMjA6MDk6MTBdIElPQVBJQ1sxXTogU2V0IFBDSSByb3V0aW5nIGVudHJ5ICg3LTE2IC0+
IDB4MzEgLT4gSVJRIDQwIE1vZGU6MSBBY3RpdmU6MSkNCihYRU4pIFsyMDEyLTA5LTA2IDIw
OjA5OjEwXSBJT0FQSUNbMV06IFNldCBQQ0kgcm91dGluZyBlbnRyeSAoNy0xNyAtPiAweDM5
IC0+IElSUSA0MSBNb2RlOjEgQWN0aXZlOjEpDQooWEVOKSBbMjAxMi0wOS0wNiAyMDowOTox
MF0gSU9BUElDWzFdOiBTZXQgUENJIHJvdXRpbmcgZW50cnkgKDctMTggLT4gMHg0MSAtPiBJ
UlEgNDIgTW9kZToxIEFjdGl2ZToxKQ0KKFhFTikgWzIwMTItMDktMDYgMjA6MDk6MTBdIElP
QVBJQ1sxXTogU2V0IFBDSSByb3V0aW5nIGVudHJ5ICg3LTE5IC0+IDB4NDkgLT4gSVJRIDQz
IE1vZGU6MSBBY3RpdmU6MSkNCihYRU4pIFsyMDEyLTA5LTA2IDIwOjA5OjExXSBJT0FQSUNb
MF06IFNldCBQQ0kgcm91dGluZyBlbnRyeSAoNi0yMiAtPiAweDk5IC0+IElSUSAyMiBNb2Rl
OjEgQWN0aXZlOjEpDQooWEVOKSBbMjAxMi0wOS0wNiAyMDowOToxMV0gSU9BUElDWzFdOiBT
ZXQgUENJIHJvdXRpbmcgZW50cnkgKDctMTIgLT4gMHhhMSAtPiBJUlEgMzYgTW9kZToxIEFj
dGl2ZToxKQ0KKFhFTikgWzIwMTItMDktMDYgMjA6MDk6MTFdIElPQVBJQ1sxXTogU2V0IFBD
SSByb3V0aW5nIGVudHJ5ICg3LTIzIC0+IDB4YTkgLT4gSVJRIDQ3IE1vZGU6MSBBY3RpdmU6
MSkNCihYRU4pIFsyMDEyLTA5LTA2IDIwOjA5OjExXSBJT0FQSUNbMF06IFNldCBQQ0kgcm91
dGluZyBlbnRyeSAoNi0xOSAtPiAweGIxIC0+IElSUSAxOSBNb2RlOjEgQWN0aXZlOjEpDQoo
WEVOKSBbMjAxMi0wOS0wNiAyMDowOToxMV0gSU9BUElDWzFdOiBTZXQgUENJIHJvdXRpbmcg
ZW50cnkgKDctMjIgLT4gMHhjMSAtPiBJUlEgNDYgTW9kZToxIEFjdGl2ZToxKQ0KKFhFTikg
WzIwMTItMDktMDYgMjA6MDk6MTFdIElPQVBJQ1sxXTogU2V0IFBDSSByb3V0aW5nIGVudHJ5
ICg3LTI3IC0+IDB4ZDEgLT4gSVJRIDUxIE1vZGU6MSBBY3RpdmU6MSkNCihYRU4pIFsyMDEy
LTA5LTA2IDIwOjA5OjEzXSBJT0FQSUNbMV06IFNldCBQQ0kgcm91dGluZyBlbnRyeSAoNy05
IC0+IDB4MjIgLT4gSVJRIDMzIE1vZGU6MSBBY3RpdmU6MSkNCihYRU4pIFsyMDEyLTA5LTA2
IDIwOjEwOjE5XSB0cmFwcy5jOjI1ODQ6ZDEgRG9tYWluIGF0dGVtcHRlZCBXUk1TUiAwMDAw
MDAwMGMwMDEwMDA0IGZyb20gMHgwMDAwNmZiMDM5ZGU3OTAwIHRvIDB4MDAwMDAwMDAwMDAw
YWJjZC4NCihYRU4pIFsyMDEyLTA5LTA2IDIwOjEwOjI1XSB0cmFwcy5jOjI1ODQ6ZDIgRG9t
YWluIGF0dGVtcHRlZCBXUk1TUiAwMDAwMDAwMGMwMDEwMDA0IGZyb20gMHgwMDAwYTE5NWM0
MGY2MThmIHRvIDB4MDAwMDAwMDAwMDAwYWJjZC4NCihYRU4pIFsyMDEyLTA5LTA2IDIwOjEw
OjM3XSB0cmFwcy5jOjI1ODQ6ZDMgRG9tYWluIGF0dGVtcHRlZCBXUk1TUiAwMDAwMDAwMGMw
MDEwMDA0IGZyb20gMHgwMDAwNDIzNDVhMGRhNTQ1IHRvIDB4MDAwMDAwMDAwMDAwYWJjZC4N
CihYRU4pIFsyMDEyLTA5LTA2IDIwOjEwOjM3XSB0cmFwcy5jOjI1ODQ6ZDQgRG9tYWluIGF0
dGVtcHRlZCBXUk1TUiAwMDAwMDAwMGMwMDEwMDA0IGZyb20gMHgwMDAwYTE5NWM0MGY2MThm
IHRvIDB4MDAwMDAwMDAwMDAwYWJjZC4NCihYRU4pIFsyMDEyLTA5LTA2IDIwOjEwOjQ0XSB0
cmFwcy5jOjI1ODQ6ZDUgRG9tYWluIGF0dGVtcHRlZCBXUk1TUiAwMDAwMDAwMGMwMDEwMDA0
IGZyb20gMHgwMDAwNmZiMDM5ZGU3OTAwIHRvIDB4MDAwMDAwMDAwMDAwYWJjZC4NCihYRU4p
IFsyMDEyLTA5LTA2IDIwOjEwOjQ5XSB0cmFwcy5jOjI1ODQ6ZDYgRG9tYWluIGF0dGVtcHRl
ZCBXUk1TUiAwMDAwMDAwMGMwMDEwMDA0IGZyb20gMHgwMDAwNDIzNDVhMGRhNTQ1IHRvIDB4
MDAwMDAwMDAwMDAwYWJjZC4NCihYRU4pIFsyMDEyLTA5LTA2IDIwOjEwOjU2XSB0cmFwcy5j
OjI1ODQ6ZDcgRG9tYWluIGF0dGVtcHRlZCBXUk1TUiAwMDAwMDAwMGMwMDEwMDA0IGZyb20g
MHgwMDAwNDIzNDVhMGRhNTQ1IHRvIDB4MDAwMDAwMDAwMDAwYWJjZC4NCihYRU4pIFsyMDEy
LTA5LTA2IDIwOjExOjAyXSB0cmFwcy5jOjI1ODQ6ZDggRG9tYWluIGF0dGVtcHRlZCBXUk1T
UiAwMDAwMDAwMGMwMDEwMDA0IGZyb20gMHgwMDAwNmZiMDM5ZGU3OTAwIHRvIDB4MDAwMDAw
MDAwMDAwYWJjZC4NCihYRU4pIFsyMDEyLTA5LTA2IDIwOjExOjA4XSB0cmFwcy5jOjI1ODQ6
ZDkgRG9tYWluIGF0dGVtcHRlZCBXUk1TUiAwMDAwMDAwMGMwMDEwMDA0IGZyb20gMHgwMDAw
ODY3OWMwMmI0MTY1IHRvIDB4MDAwMDAwMDAwMDAwYWJjZC4NCihYRU4pIFsyMDEyLTA5LTA2
IDIwOjExOjE1XSB0cmFwcy5jOjI1ODQ6ZDEwIERvbWFpbiBhdHRlbXB0ZWQgV1JNU1IgMDAw
MDAwMDBjMDAxMDAwNCBmcm9tIDB4MDAwMDQyMzQ1YTBkYTU0NSB0byAweDAwMDAwMDAwMDAw
MGFiY2QuDQooWEVOKSBbMjAxMi0wOS0wNiAyMDoxMToyNF0gQU1ELVZpOiBEaXNhYmxlOiBk
ZXZpY2UgaWQgPSAweDAwYTQsIGRvbWFpbiA9IDAsIHBhZ2luZyBtb2RlID0gMw0KKFhFTikg
WzIwMTItMDktMDYgMjA6MTE6MjRdIEFNRC1WaTogU2V0dXAgSS9PIHBhZ2UgdGFibGU6IGRl
dmljZSBpZCA9IDB4MDBhNCwgcm9vdCB0YWJsZSA9IDB4MThlMGExMDAwLCBkb21haW4gPSAx
MSwgcGFnaW5nIG1vZGUgPSAzDQooWEVOKSBbMjAxMi0wOS0wNiAyMDoxMToyNF0gQU1ELVZp
OiBSZS1hc3NpZ24gMDAwMDowMzowNi4wIGZyb20gZG9tMCB0byBkb20xMQ0KKFhFTikgWzIw
MTItMDktMDYgMjA6MTE6MjVdIHRyYXBzLmM6MjU4NDpkMTEgRG9tYWluIGF0dGVtcHRlZCBX
Uk1TUiAwMDAwMDAwMGMwMDEwMDA0IGZyb20gMHgwMDAwYTE5NWM0MGY2MThmIHRvIDB4MDAw
MDAwMDAwMDAwYWJjZC4NCihYRU4pIFsyMDEyLTA5LTA2IDIwOjExOjMxXSB0cmFwcy5jOjI1
ODQ6ZDEyIERvbWFpbiBhdHRlbXB0ZWQgV1JNU1IgMDAwMDAwMDBjMDAxMDAwNCBmcm9tIDB4
MDAwMDg2NzljMDJiNDE2NSB0byAweDAwMDAwMDAwMDAwMGFiY2QuDQooWEVOKSBbMjAxMi0w
OS0wNiAyMDoxMTozOF0gdHJhcHMuYzoyNTg0OmQxMyBEb21haW4gYXR0ZW1wdGVkIFdSTVNS
IDAwMDAwMDAwYzAwMTAwMDQgZnJvbSAweDAwMDBhMTk1YzQwZjYxOGYgdG8gMHgwMDAwMDAw
MDAwMDBhYmNkLg0KKFhFTikgWzIwMTItMDktMDYgMjA6MTE6NDVdIEFNRC1WaTogRGlzYWJs
ZTogZGV2aWNlIGlkID0gMHgwYTAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMNCihY
RU4pIFsyMDEyLTA5LTA2IDIwOjExOjQ1XSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxl
OiBkZXZpY2UgaWQgPSAweDBhMDAsIHJvb3QgdGFibGUgPSAweDFlMWZjMDAwMCwgZG9tYWlu
ID0gMTQsIHBhZ2luZyBtb2RlID0gMw0KKFhFTikgWzIwMTItMDktMDYgMjA6MTE6NDVdIEFN
RC1WaTogUmUtYXNzaWduIDAwMDA6MGE6MDAuMCBmcm9tIGRvbTAgdG8gZG9tMTQNCihYRU4p
IFsyMDEyLTA5LTA2IDIwOjExOjQ1XSBBTUQtVmk6IERpc2FibGU6IGRldmljZSBpZCA9IDB4
MGEwMSwgZG9tYWluID0gMCwgcGFnaW5nIG1vZGUgPSAzDQooWEVOKSBbMjAxMi0wOS0wNiAy
MDoxMTo0NV0gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHgw
YTAxLCByb290IHRhYmxlID0gMHgxZTFmYzAwMDAsIGRvbWFpbiA9IDE0LCBwYWdpbmcgbW9k
ZSA9IDMNCihYRU4pIFsyMDEyLTA5LTA2IDIwOjExOjQ1XSBBTUQtVmk6IFJlLWFzc2lnbiAw
MDAwOjBhOjAwLjEgZnJvbSBkb20wIHRvIGRvbTE0DQooWEVOKSBbMjAxMi0wOS0wNiAyMDox
MTo0NV0gQU1ELVZpOiBEaXNhYmxlOiBkZXZpY2UgaWQgPSAweDBhMDIsIGRvbWFpbiA9IDAs
IHBhZ2luZyBtb2RlID0gMw0KKFhFTikgWzIwMTItMDktMDYgMjA6MTE6NDVdIEFNRC1WaTog
U2V0dXAgSS9PIHBhZ2UgdGFibGU6IGRldmljZSBpZCA9IDB4MGEwMiwgcm9vdCB0YWJsZSA9
IDB4MWUxZmMwMDAwLCBkb21haW4gPSAxNCwgcGFnaW5nIG1vZGUgPSAzDQooWEVOKSBbMjAx
Mi0wOS0wNiAyMDoxMTo0NV0gQU1ELVZpOiBSZS1hc3NpZ24gMDAwMDowYTowMC4yIGZyb20g
ZG9tMCB0byBkb20xNA0KKFhFTikgWzIwMTItMDktMDYgMjA6MTE6NDVdIEFNRC1WaTogRGlz
YWJsZTogZGV2aWNlIGlkID0gMHgwYTAzLCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMN
CihYRU4pIFsyMDEyLTA5LTA2IDIwOjExOjQ1XSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRh
YmxlOiBkZXZpY2UgaWQgPSAweDBhMDMsIHJvb3QgdGFibGUgPSAweDFlMWZjMDAwMCwgZG9t
YWluID0gMTQsIHBhZ2luZyBtb2RlID0gMw0KKFhFTikgWzIwMTItMDktMDYgMjA6MTE6NDVd
IEFNRC1WaTogUmUtYXNzaWduIDAwMDA6MGE6MDAuMyBmcm9tIGRvbTAgdG8gZG9tMTQNCihY
RU4pIFsyMDEyLTA5LTA2IDIwOjExOjQ1XSBBTUQtVmk6IERpc2FibGU6IGRldmljZSBpZCA9
IDB4MGEwNCwgZG9tYWluID0gMCwgcGFnaW5nIG1vZGUgPSAzDQooWEVOKSBbMjAxMi0wOS0w
NiAyMDoxMTo0NV0gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0g
MHgwYTA0LCByb290IHRhYmxlID0gMHgxZTFmYzAwMDAsIGRvbWFpbiA9IDE0LCBwYWdpbmcg
bW9kZSA9IDMNCihYRU4pIFsyMDEyLTA5LTA2IDIwOjExOjQ1XSBBTUQtVmk6IFJlLWFzc2ln
biAwMDAwOjBhOjAwLjQgZnJvbSBkb20wIHRvIGRvbTE0DQooWEVOKSBbMjAxMi0wOS0wNiAy
MDoxMTo0NV0gQU1ELVZpOiBEaXNhYmxlOiBkZXZpY2UgaWQgPSAweDBhMDUsIGRvbWFpbiA9
IDAsIHBhZ2luZyBtb2RlID0gMw0KKFhFTikgWzIwMTItMDktMDYgMjA6MTE6NDVdIEFNRC1W
aTogU2V0dXAgSS9PIHBhZ2UgdGFibGU6IGRldmljZSBpZCA9IDB4MGEwNSwgcm9vdCB0YWJs
ZSA9IDB4MWUxZmMwMDAwLCBkb21haW4gPSAxNCwgcGFnaW5nIG1vZGUgPSAzDQooWEVOKSBb
MjAxMi0wOS0wNiAyMDoxMTo0NV0gQU1ELVZpOiBSZS1hc3NpZ24gMDAwMDowYTowMC41IGZy
b20gZG9tMCB0byBkb20xNA0KKFhFTikgWzIwMTItMDktMDYgMjA6MTE6NDVdIEFNRC1WaTog
RGlzYWJsZTogZGV2aWNlIGlkID0gMHgwYTA2LCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9
IDMNCihYRU4pIFsyMDEyLTA5LTA2IDIwOjExOjQ1XSBBTUQtVmk6IFNldHVwIEkvTyBwYWdl
IHRhYmxlOiBkZXZpY2UgaWQgPSAweDBhMDYsIHJvb3QgdGFibGUgPSAweDFlMWZjMDAwMCwg
ZG9tYWluID0gMTQsIHBhZ2luZyBtb2RlID0gMw0KKFhFTikgWzIwMTItMDktMDYgMjA6MTE6
NDVdIEFNRC1WaTogUmUtYXNzaWduIDAwMDA6MGE6MDAuNiBmcm9tIGRvbTAgdG8gZG9tMTQN
CihYRU4pIFsyMDEyLTA5LTA2IDIwOjExOjQ1XSBBTUQtVmk6IERpc2FibGU6IGRldmljZSBp
ZCA9IDB4MGEwNywgZG9tYWluID0gMCwgcGFnaW5nIG1vZGUgPSAzDQooWEVOKSBbMjAxMi0w
OS0wNiAyMDoxMTo0NV0gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlk
ID0gMHgwYTA3LCByb290IHRhYmxlID0gMHgxZTFmYzAwMDAsIGRvbWFpbiA9IDE0LCBwYWdp
bmcgbW9kZSA9IDMNCihYRU4pIFsyMDEyLTA5LTA2IDIwOjExOjQ1XSBBTUQtVmk6IFJlLWFz
c2lnbiAwMDAwOjBhOjAwLjcgZnJvbSBkb20wIHRvIGRvbTE0DQooWEVOKSBbMjAxMi0wOS0w
NiAyMDoxMTo0NV0gQU1ELVZpOiBEaXNhYmxlOiBkZXZpY2UgaWQgPSAweDA3MDAsIGRvbWFp
biA9IDAsIHBhZ2luZyBtb2RlID0gMw0KKFhFTikgWzIwMTItMDktMDYgMjA6MTE6NDVdIEFN
RC1WaTogU2V0dXAgSS9PIHBhZ2UgdGFibGU6IGRldmljZSBpZCA9IDB4MDcwMCwgcm9vdCB0
YWJsZSA9IDB4MWUxZmMwMDAwLCBkb21haW4gPSAxNCwgcGFnaW5nIG1vZGUgPSAzDQooWEVO
KSBbMjAxMi0wOS0wNiAyMDoxMTo0NV0gQU1ELVZpOiBSZS1hc3NpZ24gMDAwMDowNzowMC4w
IGZyb20gZG9tMCB0byBkb20xNA0KKFhFTikgWzIwMTItMDktMDYgMjA6MTE6NDVdIHRyYXBz
LmM6MjU4NDpkMTQgRG9tYWluIGF0dGVtcHRlZCBXUk1TUiAwMDAwMDAwMGMwMDEwMDA0IGZy
b20gMHgwMDAwNzg1MTkwZmI0ZTBmIHRvIDB4MDAwMDAwMDAwMDAwYWJjZC4NCihYRU4pIFsy
MDEyLTA5LTA2IDIwOjExOjUxXSBBTUQtVmk6IFNoYXJlIHAybSB0YWJsZSB3aXRoIGlvbW11
OiBwMm0gdGFibGUgPSAweGE3N2E4DQooWEVOKSBbMjAxMi0wOS0wNiAyMDoxMTo1Nl0gSFZN
MTU6IEhWTSBMb2FkZXINCihYRU4pIFsyMDEyLTA5LTA2IDIwOjExOjU2XSBIVk0xNTogRGV0
ZWN0ZWQgWGVuIHY0LjIuMC1yYzQtcHJlDQooWEVOKSBbMjAxMi0wOS0wNiAyMDoxMTo1Nl0g
SFZNMTU6IFhlbmJ1cyByaW5ncyBAMHhmZWZmYzAwMCwgZXZlbnQgY2hhbm5lbCA0DQooWEVO
KSBbMjAxMi0wOS0wNiAyMDoxMTo1Nl0gSFZNMTU6IFN5c3RlbSByZXF1ZXN0ZWQgUk9NQklP
Uw0KKFhFTikgWzIwMTItMDktMDYgMjA6MTE6NTZdIEhWTTE1OiBDUFUgc3BlZWQgaXMgMzIw
MCBNSHoNCihYRU4pIFsyMDEyLTA5LTA2IDIwOjExOjU2XSBpcnEuYzoyNzA6IERvbTE1IFBD
SSBsaW5rIDAgY2hhbmdlZCAwIC0+IDUNCihYRU4pIFsyMDEyLTA5LTA2IDIwOjExOjU2XSBI
Vk0xNTogUENJLUlTQSBsaW5rIDAgcm91dGVkIHRvIElSUTUNCihYRU4pIFsyMDEyLTA5LTA2
IDIwOjExOjU2XSBpcnEuYzoyNzA6IERvbTE1IFBDSSBsaW5rIDEgY2hhbmdlZCAwIC0+IDEw
DQooWEVOKSBbMjAxMi0wOS0wNiAyMDoxMTo1Nl0gSFZNMTU6IFBDSS1JU0EgbGluayAxIHJv
dXRlZCB0byBJUlExMA0KKFhFTikgWzIwMTItMDktMDYgMjA6MTE6NTZdIGlycS5jOjI3MDog
RG9tMTUgUENJIGxpbmsgMiBjaGFuZ2VkIDAgLT4gMTENCihYRU4pIFsyMDEyLTA5LTA2IDIw
OjExOjU2XSBIVk0xNTogUENJLUlTQSBsaW5rIDIgcm91dGVkIHRvIElSUTExDQooWEVOKSBb
MjAxMi0wOS0wNiAyMDoxMTo1Nl0gaXJxLmM6MjcwOiBEb20xNSBQQ0kgbGluayAzIGNoYW5n
ZWQgMCAtPiA1DQooWEVOKSBbMjAxMi0wOS0wNiAyMDoxMTo1Nl0gSFZNMTU6IFBDSS1JU0Eg
bGluayAzIHJvdXRlZCB0byBJUlE1DQooWEVOKSBbMjAxMi0wOS0wNiAyMDoxMTo1Nl0gSFZN
MTU6IHBjaSBkZXYgMDE6MiBJTlRELT5JUlE1DQooWEVOKSBbMjAxMi0wOS0wNiAyMDoxMTo1
Nl0gSFZNMTU6IHBjaSBkZXYgMDE6MyBJTlRBLT5JUlExMA0KKFhFTikgWzIwMTItMDktMDYg
MjA6MTE6NTZdIEhWTTE1OiBwY2kgZGV2IDAzOjAgSU5UQS0+SVJRNQ0KKFhFTikgWzIwMTIt
MDktMDYgMjA6MTE6NTZdIEhWTTE1OiBwY2kgZGV2IDA0OjAgSU5UQS0+SVJRNQ0KKFhFTikg
WzIwMTItMDktMDYgMjA6MTE6NTZdIEhWTTE1OiBwY2kgZGV2IDAyOjAgYmFyIDEwIHNpemUg
MDIwMDAwMDA6IGYwMDAwMDA4DQooWEVOKSBbMjAxMi0wOS0wNiAyMDoxMTo1Nl0gSFZNMTU6
IHBjaSBkZXYgMDM6MCBiYXIgMTQgc2l6ZSAwMTAwMDAwMDogZjIwMDAwMDgNCihYRU4pIFsy
MDEyLTA5LTA2IDIwOjExOjU2XSBIVk0xNTogcGNpIGRldiAwNDowIGJhciAxMCBzaXplIDAw
MDIwMDAwOiBmMzAwMDAwMA0KKFhFTikgWzIwMTItMDktMDYgMjA6MTE6NTZdIEhWTTE1OiBw
Y2kgZGV2IDAyOjAgYmFyIDE0IHNpemUgMDAwMDEwMDA6IGYzMDIwMDAwDQooWEVOKSBbMjAx
Mi0wOS0wNiAyMDoxMTo1Nl0gSFZNMTU6IHBjaSBkZXYgMDM6MCBiYXIgMTAgc2l6ZSAwMDAw
MDEwMDogMDAwMGMwMDENCihYRU4pIFsyMDEyLTA5LTA2IDIwOjExOjU2XSBIVk0xNTogcGNp
IGRldiAwNDowIGJhciAxNCBzaXplIDAwMDAwMDQwOiAwMDAwYzEwMQ0KKFhFTikgWzIwMTIt
MDktMDYgMjA6MTE6NTZdIEhWTTE1OiBwY2kgZGV2IDAxOjIgYmFyIDIwIHNpemUgMDAwMDAw
MjA6IDAwMDBjMTQxDQooWEVOKSBbMjAxMi0wOS0wNiAyMDoxMTo1Nl0gSFZNMTU6IHBjaSBk
ZXYgMDE6MSBiYXIgMjAgc2l6ZSAwMDAwMDAxMDogMDAwMGMxNjENCihYRU4pIFsyMDEyLTA5
LTA2IDIwOjExOjU2XSBIVk0xNTogTXVsdGlwcm9jZXNzb3IgaW5pdGlhbGlzYXRpb246DQoo
WEVOKSBbMjAxMi0wOS0wNiAyMDoxMTo1Nl0gSFZNMTU6ICAtIENQVTAgLi4uIDQ4LWJpdCBw
aHlzIC4uLiBmaXhlZCBNVFJScyAuLi4gdmFyIE1UUlJzIFsyLzhdIC4uLiBkb25lLg0KKFhF
TikgWzIwMTItMDktMDYgMjA6MTE6NTZdIEhWTTE1OiAgLSBDUFUxIC4uLiA0OC1iaXQgcGh5
cyAuLi4gZml4ZWQgTVRSUnMgLi4uIHZhciBNVFJScyBbMi84XSAuLi4gZG9uZS4NCihYRU4p
IFsyMDEyLTA5LTA2IDIwOjExOjU2XSBIVk0xNTogVGVzdGluZyBIVk0gZW52aXJvbm1lbnQ6
DQooWEVOKSBbMjAxMi0wOS0wNiAyMDoxMTo1Nl0gSFZNMTU6ICAtIFJFUCBJTlNCIGFjcm9z
cyBwYWdlIGJvdW5kYXJpZXMgLi4uIHBhc3NlZA0KKFhFTikgWzIwMTItMDktMDYgMjA6MTE6
NTZdIEhWTTE1OiAgLSBHUyBiYXNlIE1TUnMgYW5kIFNXQVBHUyAuLi4gcGFzc2VkDQooWEVO
KSBbMjAxMi0wOS0wNiAyMDoxMTo1Nl0gSFZNMTU6IFBhc3NlZCAyIG9mIDIgdGVzdHMNCihY
RU4pIFsyMDEyLTA5LTA2IDIwOjExOjU2XSBIVk0xNTogV3JpdGluZyBTTUJJT1MgdGFibGVz
IC4uLg0KKFhFTikgWzIwMTItMDktMDYgMjA6MTE6NTZdIEhWTTE1OiBMb2FkaW5nIFJPTUJJ
T1MgLi4uDQooWEVOKSBbMjAxMi0wOS0wNiAyMDoxMTo1Nl0gSFZNMTU6IDk2NjAgYnl0ZXMg
b2YgUk9NQklPUyBoaWdoLW1lbW9yeSBleHRlbnNpb25zOg0KKFhFTikgWzIwMTItMDktMDYg
MjA6MTE6NTZdIEhWTTE1OiAgIFJlbG9jYXRpbmcgdG8gMHhmYzAwMTAwMC0weGZjMDAzNWJj
IC4uLiBkb25lDQooWEVOKSBbMjAxMi0wOS0wNiAyMDoxMTo1Nl0gSFZNMTU6IENyZWF0aW5n
IE1QIHRhYmxlcyAuLi4NCihYRU4pIFsyMDEyLTA5LTA2IDIwOjExOjU2XSBIVk0xNTogTG9h
ZGluZyBDaXJydXMgVkdBQklPUyAuLi4NCihYRU4pIFsyMDEyLTA5LTA2IDIwOjExOjU2XSBI
Vk0xNTogTG9hZGluZyBQQ0kgT3B0aW9uIFJPTSAuLi4NCihYRU4pIFsyMDEyLTA5LTA2IDIw
OjExOjU2XSBIVk0xNTogIC0gTWFudWZhY3R1cmVyOiBodHRwOi8vaXB4ZS5vcmcNCihYRU4p
IFsyMDEyLTA5LTA2IDIwOjExOjU2XSBIVk0xNTogIC0gUHJvZHVjdCBuYW1lOiBpUFhFDQoo
WEVOKSBbMjAxMi0wOS0wNiAyMDoxMTo1N10gSFZNMTU6IE9wdGlvbiBST01zOg0KKFhFTikg
WzIwMTItMDktMDYgMjA6MTE6NTddIEhWTTE1OiAgYzAwMDAtYzhmZmY6IFZHQSBCSU9TDQoo
WEVOKSBbMjAxMi0wOS0wNiAyMDoxMTo1N10gSFZNMTU6ICBjOTAwMC1kOWZmZjogRXRoZXJi
b290IFJPTQ0KKFhFTikgWzIwMTItMDktMDYgMjA6MTE6NTddIEhWTTE1OiBMb2FkaW5nIEFD
UEkgLi4uDQooWEVOKSBbMjAxMi0wOS0wNiAyMDoxMTo1N10gSFZNMTU6IHZtODYgVFNTIGF0
IGZjMDBmNjgwDQooWEVOKSBbMjAxMi0wOS0wNiAyMDoxMTo1N10gSFZNMTU6IEJJT1MgbWFw
Og0KKFhFTikgWzIwMTItMDktMDYgMjA6MTE6NTddIEhWTTE1OiAgZjAwMDAtZmZmZmY6IE1h
aW4gQklPUw0KKFhFTikgWzIwMTItMDktMDYgMjA6MTE6NTddIEhWTTE1OiBFODIwIHRhYmxl
Og0KKFhFTikgWzIwMTItMDktMDYgMjA6MTE6NTddIEhWTTE1OiAgWzAwXTogMDAwMDAwMDA6
MDAwMDAwMDAgLSAwMDAwMDAwMDowMDA5ZTAwMDogUkFNDQooWEVOKSBbMjAxMi0wOS0wNiAy
MDoxMTo1N10gSFZNMTU6ICBbMDFdOiAwMDAwMDAwMDowMDA5ZTAwMCAtIDAwMDAwMDAwOjAw
MGEwMDAwOiBSRVNFUlZFRA0KKFhFTikgWzIwMTItMDktMDYgMjA6MTE6NTddIEhWTTE1OiAg
SE9MRTogMDAwMDAwMDA6MDAwYTAwMDAgLSAwMDAwMDAwMDowMDBlMDAwMA0KKFhFTikgWzIw
MTItMDktMDYgMjA6MTE6NTddIEhWTTE1OiAgWzAyXTogMDAwMDAwMDA6MDAwZTAwMDAgLSAw
MDAwMDAwMDowMDEwMDAwMDogUkVTRVJWRUQNCihYRU4pIFsyMDEyLTA5LTA2IDIwOjExOjU3
XSBIVk0xNTogIFswM106IDAwMDAwMDAwOjAwMTAwMDAwIC0gMDAwMDAwMDA6MWY4MDAwMDA6
IFJBTQ0KKFhFTikgWzIwMTItMDktMDYgMjA6MTE6NTddIEhWTTE1OiAgSE9MRTogMDAwMDAw
MDA6MWY4MDAwMDAgLSAwMDAwMDAwMDpmYzAwMDAwMA0KKFhFTikgWzIwMTItMDktMDYgMjA6
MTE6NTddIEhWTTE1OiAgWzA0XTogMDAwMDAwMDA6ZmMwMDAwMDAgLSAwMDAwMDAwMTowMDAw
MDAwMDogUkVTRVJWRUQNCihYRU4pIFsyMDEyLTA5LTA2IDIwOjExOjU3XSBIVk0xNTogSW52
b2tpbmcgUk9NQklPUyAuLi4NCihYRU4pIFsyMDEyLTA5LTA2IDIwOjExOjU3XSBIVk0xNTog
JFJldmlzaW9uOiAxLjIyMSAkICREYXRlOiAyMDA4LzEyLzA3IDE3OjMyOjI5ICQNCihYRU4p
IFsyMDEyLTA5LTA2IDIwOjExOjU3XSBzdGR2Z2EuYzoxNDc6ZDE1IGVudGVyaW5nIHN0ZHZn
YSBhbmQgY2FjaGluZyBtb2Rlcw0KKFhFTikgWzIwMTItMDktMDYgMjA6MTE6NTddIEhWTTE1
OiBWR0FCaW9zICRJZDogdmdhYmlvcy5jLHYgMS42NyAyMDA4LzAxLzI3IDA5OjQ0OjEyIHZy
dXBwZXJ0IEV4cCAkDQooWEVOKSBbMjAxMi0wOS0wNiAyMDoxMTo1N10gSFZNMTU6IEJvY2hz
IEJJT1MgLSBidWlsZDogMDYvMjMvOTkNCihYRU4pIFsyMDEyLTA5LTA2IDIwOjExOjU3XSBI
Vk0xNTogJFJldmlzaW9uOiAxLjIyMSAkICREYXRlOiAyMDA4LzEyLzA3IDE3OjMyOjI5ICQN
CihYRU4pIFsyMDEyLTA5LTA2IDIwOjExOjU3XSBIVk0xNTogT3B0aW9uczogYXBtYmlvcyBw
Y2liaW9zIGVsdG9yaXRvIFBNTSANCihYRU4pIFsyMDEyLTA5LTA2IDIwOjExOjU3XSBIVk0x
NTogDQooWEVOKSBbMjAxMi0wOS0wNiAyMDoxMTo1N10gSFZNMTU6IGF0YTAtMDogUENIUz0x
NjM4My8xNi82MyB0cmFuc2xhdGlvbj1sYmEgTENIUz0xMDI0LzI1NS82Mw0KKFhFTikgWzIw
MTItMDktMDYgMjA6MTE6NTddIEhWTTE1OiBhdGEwIG1hc3RlcjogUUVNVSBIQVJERElTSyBB
VEEtNyBIYXJkLURpc2sgKDU3MjQ0IE1CeXRlcykNCihYRU4pIFsyMDEyLTA5LTA2IDIwOjEx
OjU4XSBIVk0xNTogSURFIHRpbWUgb3V0DQooWEVOKSBbMjAxMi0wOS0wNiAyMDoxMTo1OF0g
SFZNMTU6IGF0YTEgbWFzdGVyOiBRRU1VIERWRC1ST00gQVRBUEktNCBDRC1Sb20vRFZELVJv
bQ0KKFhFTikgWzIwMTItMDktMDYgMjA6MTI6MDBdIEhWTTE1OiBJREUgdGltZSBvdXQNCihY
RU4pIFsyMDEyLTA5LTA2IDIwOjEyOjAwXSBIVk0xNTogDQooWEVOKSBbMjAxMi0wOS0wNiAy
MDoxMjowMF0gSFZNMTU6IA0KKFhFTikgWzIwMTItMDktMDYgMjA6MTI6MDBdIEhWTTE1OiAN
CihYRU4pIFsyMDEyLTA5LTA2IDIwOjEyOjAwXSBIVk0xNTogUHJlc3MgRjEyIGZvciBib290
IG1lbnUuDQooWEVOKSBbMjAxMi0wOS0wNiAyMDoxMjowMF0gSFZNMTU6IA0KKFhFTikgWzIw
MTItMDktMDYgMjA6MTI6MDBdIEhWTTE1OiBCb290aW5nIGZyb20gSGFyZCBEaXNrLi4uDQoo
WEVOKSBbMjAxMi0wOS0wNiAyMDoxMjowMF0gSFZNMTU6IEJvb3RpbmcgZnJvbSAwMDAwOjdj
MDANCihYRU4pIFsyMDEyLTA5LTA2IDIwOjEyOjA0XSB0cmFwcy5jOjI1ODQ6ZDE2IERvbWFp
biBhdHRlbXB0ZWQgV1JNU1IgMDAwMDAwMDBjMDAxMDAwNCBmcm9tIDB4MDAwMDQyMzQ1YTBk
YTU0NSB0byAweDAwMDAwMDAwMDAwMGFiY2QuDQooWEVOKSBbMjAxMi0wOS0wNiAyMDoxMjoy
N10gaXJxLmM6MjcwOiBEb20xNSBQQ0kgbGluayAwIGNoYW5nZWQgNSAtPiAwDQooWEVOKSBb
MjAxMi0wOS0wNiAyMDoxMjoyN10gaXJxLmM6MjcwOiBEb20xNSBQQ0kgbGluayAxIGNoYW5n
ZWQgMTAgLT4gMA0KKFhFTikgWzIwMTItMDktMDYgMjA6MTI6MjddIGlycS5jOjI3MDogRG9t
MTUgUENJIGxpbmsgMiBjaGFuZ2VkIDExIC0+IDANCihYRU4pIFsyMDEyLTA5LTA2IDIwOjEy
OjI3XSBpcnEuYzoyNzA6IERvbTE1IFBDSSBsaW5rIDMgY2hhbmdlZCA1IC0+IDANCihYRU4p
IFsyMDEyLTA5LTA2IDIwOjEyOjI4XSBodm0uYzoyNDM1OmQxNSBndWVzdCBhdHRlbXB0ZWQg
d3JpdGUgdG8gcmVhZC1vbmx5IG1lbW9yeSBwYWdlLiBnZm49MHhkYywgbWZuPTB4YTRhMGIN
CihYRU4pIFsyMDEyLTA5LTA2IDIwOjEyOjI4XSBodm0uYzoyNDM1OmQxNSBndWVzdCBhdHRl
bXB0ZWQgd3JpdGUgdG8gcmVhZC1vbmx5IG1lbW9yeSBwYWdlLiBnZm49MHhkZCwgbWZuPTB4
YTRhMGENCihYRU4pIFsyMDEyLTA5LTA2IDIwOjEyOjI4XSBodm0uYzoyNDM1OmQxNSBndWVz
dCBhdHRlbXB0ZWQgd3JpdGUgdG8gcmVhZC1vbmx5IG1lbW9yeSBwYWdlLiBnZm49MHhkZSwg
bWZuPTB4YTRhMDkNCihYRU4pIFsyMDEyLTA5LTA2IDIwOjEyOjI4XSBodm0uYzoyNDM1OmQx
NSBndWVzdCBhdHRlbXB0ZWQgd3JpdGUgdG8gcmVhZC1vbmx5IG1lbW9yeSBwYWdlLiBnZm49
MHhkZCwgbWZuPTB4YTRhMGENCihYRU4pIFsyMDEyLTA5LTA2IDIwOjEyOjI4XSBodm0uYzoy
NDM1OmQxNSBndWVzdCBhdHRlbXB0ZWQgd3JpdGUgdG8gcmVhZC1vbmx5IG1lbW9yeSBwYWdl
LiBnZm49MHhkYywgbWZuPTB4YTRhMGINCihYRU4pIFsyMDEyLTA5LTA2IDIwOjEyOjI4XSBo
dm0uYzoyNDM1OmQxNSBndWVzdCBhdHRlbXB0ZWQgd3JpdGUgdG8gcmVhZC1vbmx5IG1lbW9y
eSBwYWdlLiBnZm49MHhkZSwgbWZuPTB4YTRhMDkNCihYRU4pIFsyMDEyLTA5LTA2IDIwOjEy
OjI4XSBodm0uYzoyNDM1OmQxNSBndWVzdCBhdHRlbXB0ZWQgd3JpdGUgdG8gcmVhZC1vbmx5
IG1lbW9yeSBwYWdlLiBnZm49MHhkZCwgbWZuPTB4YTRhMGENCihYRU4pIFsyMDEyLTA5LTA2
IDIwOjEyOjI4XSBodm0uYzoyNDM1OmQxNSBndWVzdCBhdHRlbXB0ZWQgd3JpdGUgdG8gcmVh
ZC1vbmx5IG1lbW9yeSBwYWdlLiBnZm49MHhkZSwgbWZuPTB4YTRhMDkNCihYRU4pIFsyMDEy
LTA5LTA2IDIwOjEyOjI4XSBodm0uYzoyNDM1OmQxNSBndWVzdCBhdHRlbXB0ZWQgd3JpdGUg
dG8gcmVhZC1vbmx5IG1lbW9yeSBwYWdlLiBnZm49MHhkYywgbWZuPTB4YTRhMGINCihYRU4p
IFsyMDEyLTA5LTA2IDIwOjEyOjI4XSBodm0uYzoyNDM1OmQxNSBndWVzdCBhdHRlbXB0ZWQg
d3JpdGUgdG8gcmVhZC1vbmx5IG1lbW9yeSBwYWdlLiBnZm49MHhkZCwgbWZuPTB4YTRhMGEN
CihYRU4pIFsyMDEyLTA5LTA2IDIwOjEyOjI4XSBodm0uYzoyNDM1OmQxNSBndWVzdCBhdHRl
bXB0ZWQgd3JpdGUgdG8gcmVhZC1vbmx5IG1lbW9yeSBwYWdlLiBnZm49MHhkYywgbWZuPTB4
YTRhMGINCihYRU4pIFsyMDEyLTA5LTA2IDIwOjEyOjI4XSBodm0uYzoyNDM1OmQxNSBndWVz
dCBhdHRlbXB0ZWQgd3JpdGUgdG8gcmVhZC1vbmx5IG1lbW9yeSBwYWdlLiBnZm49MHhkZCwg
bWZuPTB4YTRhMGENCihYRU4pIFsyMDEyLTA5LTA2IDIwOjEyOjI4XSBodm0uYzoyNDM1OmQx
NSBndWVzdCBhdHRlbXB0ZWQgd3JpdGUgdG8gcmVhZC1vbmx5IG1lbW9yeSBwYWdlLiBnZm49
MHhkZSwgbWZuPTB4YTRhMDkNCihYRU4pIFsyMDEyLTA5LTA2IDIwOjEyOjI4XSBodm0uYzoy
NDM1OmQxNSBndWVzdCBhdHRlbXB0ZWQgd3JpdGUgdG8gcmVhZC1vbmx5IG1lbW9yeSBwYWdl
LiBnZm49MHhkZCwgbWZuPTB4YTRhMGENCihYRU4pIFsyMDEyLTA5LTA2IDIwOjEyOjI4XSBo
dm0uYzoyNDM1OmQxNSBndWVzdCBhdHRlbXB0ZWQgd3JpdGUgdG8gcmVhZC1vbmx5IG1lbW9y
eSBwYWdlLiBnZm49MHhkYywgbWZuPTB4YTRhMGINCihYRU4pIFsyMDEyLTA5LTA2IDIwOjEy
OjI4XSBodm0uYzoyNDM1OmQxNSBndWVzdCBhdHRlbXB0ZWQgd3JpdGUgdG8gcmVhZC1vbmx5
IG1lbW9yeSBwYWdlLiBnZm49MHhkZCwgbWZuPTB4YTRhMGENCihYRU4pIFsyMDEyLTA5LTA2
IDIwOjEyOjI4XSBodm0uYzoyNDM1OmQxNSBndWVzdCBhdHRlbXB0ZWQgd3JpdGUgdG8gcmVh
ZC1vbmx5IG1lbW9yeSBwYWdlLiBnZm49MHhkYywgbWZuPTB4YTRhMGINCihYRU4pIFsyMDEy
LTA5LTA2IDIwOjEyOjI4XSBodm0uYzoyNDM1OmQxNSBndWVzdCBhdHRlbXB0ZWQgd3JpdGUg
dG8gcmVhZC1vbmx5IG1lbW9yeSBwYWdlLiBnZm49MHhkZCwgbWZuPTB4YTRhMGENCihYRU4p
IFsyMDEyLTA5LTA2IDIwOjEyOjMxXSBodm0uYzoyNDM1OmQxNSBndWVzdCBhdHRlbXB0ZWQg
d3JpdGUgdG8gcmVhZC1vbmx5IG1lbW9yeSBwYWdlLiBnZm49MHhjOSwgbWZuPTB4YTRhMWUN
CihYRU4pIFsyMDEyLTA5LTA2IDIwOjEyOjMxXSBodm0uYzoyNDM1OmQxNSBndWVzdCBhdHRl
bXB0ZWQgd3JpdGUgdG8gcmVhZC1vbmx5IG1lbW9yeSBwYWdlLiBnZm49MHhjYiwgbWZuPTB4
YTRhMWMNCihYRU4pIFsyMDEyLTA5LTA2IDIwOjEyOjMxXSBodm0uYzoyNDM1OmQxNSBndWVz
dCBhdHRlbXB0ZWQgd3JpdGUgdG8gcmVhZC1vbmx5IG1lbW9yeSBwYWdlLiBnZm49MHhjZCwg
bWZuPTB4YTRhMWENCihYRU4pIFsyMDEyLTA5LTA2IDIwOjEyOjMxXSBodm0uYzoyNDM1OmQx
NSBndWVzdCBhdHRlbXB0ZWQgd3JpdGUgdG8gcmVhZC1vbmx5IG1lbW9yeSBwYWdlLiBnZm49
MHhjZiwgbWZuPTB4YTRhMTgNCihYRU4pIFsyMDEyLTA5LTA2IDIwOjEyOjMxXSBodm0uYzoy
NDM1OmQxNSBndWVzdCBhdHRlbXB0ZWQgd3JpdGUgdG8gcmVhZC1vbmx5IG1lbW9yeSBwYWdl
LiBnZm49MHhkMSwgbWZuPTB4YTRhMTYNCihYRU4pIFsyMDEyLTA5LTA2IDIwOjEyOjMxXSBo
dm0uYzoyNDM1OmQxNSBndWVzdCBhdHRlbXB0ZWQgd3JpdGUgdG8gcmVhZC1vbmx5IG1lbW9y
eSBwYWdlLiBnZm49MHhkMywgbWZuPTB4YTRhMTQNCihYRU4pIFsyMDEyLTA5LTA2IDIwOjEy
OjMxXSBodm0uYzoyNDM1OmQxNSBndWVzdCBhdHRlbXB0ZWQgd3JpdGUgdG8gcmVhZC1vbmx5
IG1lbW9yeSBwYWdlLiBnZm49MHhkNSwgbWZuPTB4YTRhMTINCihYRU4pIFsyMDEyLTA5LTA2
IDIwOjEyOjMxXSBodm0uYzoyNDM1OmQxNSBndWVzdCBhdHRlbXB0ZWQgd3JpdGUgdG8gcmVh
ZC1vbmx5IG1lbW9yeSBwYWdlLiBnZm49MHhkNywgbWZuPTB4YTRhMTANCihYRU4pIFsyMDEy
LTA5LTA2IDIwOjEyOjMxXSBodm0uYzoyNDM1OmQxNSBndWVzdCBhdHRlbXB0ZWQgd3JpdGUg
dG8gcmVhZC1vbmx5IG1lbW9yeSBwYWdlLiBnZm49MHhkOSwgbWZuPTB4YTRhMGUNCihYRU4p
IFsyMDEyLTA5LTA2IDIwOjEyOjMxXSBodm0uYzoyNDM1OmQxNSBndWVzdCBhdHRlbXB0ZWQg
d3JpdGUgdG8gcmVhZC1vbmx5IG1lbW9yeSBwYWdlLiBnZm49MHhkYiwgbWZuPTB4YTRhMGMN
CihYRU4pIFsyMDEyLTA5LTA2IDIwOjEyOjMxXSBodm0uYzoyNDM1OmQxNSBndWVzdCBhdHRl
bXB0ZWQgd3JpdGUgdG8gcmVhZC1vbmx5IG1lbW9yeSBwYWdlLiBnZm49MHhkZCwgbWZuPTB4
YTRhMGENCihYRU4pIFsyMDEyLTA5LTA2IDIwOjEyOjMxXSBodm0uYzoyNDM1OmQxNSBndWVz
dCBhdHRlbXB0ZWQgd3JpdGUgdG8gcmVhZC1vbmx5IG1lbW9yeSBwYWdlLiBnZm49MHhkZiwg
bWZuPTB4YTRhMDgNCihYRU4pIFsyMDEyLTA5LTA2IDIwOjEyOjMxXSBodm0uYzoyNDM1OmQx
NSBndWVzdCBhdHRlbXB0ZWQgd3JpdGUgdG8gcmVhZC1vbmx5IG1lbW9yeSBwYWdlLiBnZm49
MHhlMSwgbWZuPTB4YTRhMDYNCihYRU4pIFsyMDEyLTA5LTA2IDIwOjEyOjMxXSBodm0uYzoy
NDM1OmQxNSBndWVzdCBhdHRlbXB0ZWQgd3JpdGUgdG8gcmVhZC1vbmx5IG1lbW9yeSBwYWdl
LiBnZm49MHhlMywgbWZuPTB4YTRhMDQNCihYRU4pIFsyMDEyLTA5LTA2IDIwOjEyOjMxXSBo
dm0uYzoyNDM1OmQxNSBndWVzdCBhdHRlbXB0ZWQgd3JpdGUgdG8gcmVhZC1vbmx5IG1lbW9y
eSBwYWdlLiBnZm49MHhlNSwgbWZuPTB4YTRhMDINCihYRU4pIFsyMDEyLTA5LTA2IDIwOjEy
OjMxXSBodm0uYzoyNDM1OmQxNSBndWVzdCBhdHRlbXB0ZWQgd3JpdGUgdG8gcmVhZC1vbmx5
IG1lbW9yeSBwYWdlLiBnZm49MHhlNywgbWZuPTB4YTRhMDANCihYRU4pIFsyMDEyLTA5LTA2
IDIwOjEyOjMxXSBodm0uYzoyNDM1OmQxNSBndWVzdCBhdHRlbXB0ZWQgd3JpdGUgdG8gcmVh
ZC1vbmx5IG1lbW9yeSBwYWdlLiBnZm49MHhlOSwgbWZuPTB4YTQ2M2UNCihYRU4pIFsyMDEy
LTA5LTA2IDIwOjEyOjMxXSBodm0uYzoyNDM1OmQxNSBndWVzdCBhdHRlbXB0ZWQgd3JpdGUg
dG8gcmVhZC1vbmx5IG1lbW9yeSBwYWdlLiBnZm49MHhlYiwgbWZuPTB4YTQ2M2MNCihYRU4p
IFsyMDEyLTA5LTA2IDIwOjEyOjMxXSBodm0uYzoyNDM1OmQxNSBndWVzdCBhdHRlbXB0ZWQg
d3JpdGUgdG8gcmVhZC1vbmx5IG1lbW9yeSBwYWdlLiBnZm49MHhlZCwgbWZuPTB4YTQ2M2EN
CihYRU4pIFsyMDEyLTA5LTA2IDIwOjEyOjMxXSBodm0uYzoyNDM1OmQxNSBndWVzdCBhdHRl
bXB0ZWQgd3JpdGUgdG8gcmVhZC1vbmx5IG1lbW9yeSBwYWdlLiBnZm49MHhlZiwgbWZuPTB4
YTQ2MzgNCihYRU4pIFsyMDEyLTA5LTA2IDIwOjE3OjE5XSB0cmFwcy5jOjMxNTY6IEdQRiAo
MDA2MCk6IGZmZmY4MmM0ODAxNWM5ZmUgLT4gZmZmZjgyYzQ4MDIyNGI4Mw0KKFhFTikgWzIw
MTItMDktMDYgMjA6MTc6MTldIHRyYXBzLmM6MzE1NzogIHNob3dfZXhlY3V0aW9uX3N0YXRl
KHJlZ3MpOiANCihYRU4pIFsyMDEyLTA5LTA2IDIwOjE3OjE5XSAtLS0tWyBYZW4tNC4yLjAt
cmM0LXByZSAgeDg2XzY0ICBkZWJ1Zz15ICBOb3QgdGFpbnRlZCBdLS0tLQ0KKFhFTikgWzIw
MTItMDktMDYgMjA6MTc6MTldIENQVTogICAgNA0KKFhFTikgWzIwMTItMDktMDYgMjA6MTc6
MTldIFJJUDogICAgZTAwODpbPGZmZmY4MmM0ODAxNWM5ZmU+XSBjb250ZXh0X3N3aXRjaCsw
eDM5NC8weGVlYg0KKFhFTikgWzIwMTItMDktMDYgMjA6MTc6MTldIFJGTEFHUzogMDAwMDAw
MDAwMDAxMDI0NiAgIENPTlRFWFQ6IGh5cGVydmlzb3INCihYRU4pIFsyMDEyLTA5LTA2IDIw
OjE3OjE5XSByYXg6IDAwMDAwMDAwMDAwMDAwMDEgICByYng6IGZmZmY4MzAwYTUyZGEwMDAg
ICByY3g6IDAwMDAwMDAwMDAwMDAwMDENCihYRU4pIFsyMDEyLTA5LTA2IDIwOjE3OjE5XSBy
ZHg6IDAwMDAwMDAwMDAwMDAwNjMgICByc2k6IDAwMDAwMDAwMDAwMDAwMDEgICByZGk6IDAw
MDAwMDAwMDAwMDAxMmINCihYRU4pIFsyMDEyLTA5LTA2IDIwOjE3OjE5XSByYnA6IGZmZmY4
MzAyNGQ4OTdlMjggICByc3A6IGZmZmY4MzAyNGQ4OTdkODggICByODogIDAwMDAwMDAwMDAw
MDAwMDYNCihYRU4pIFsyMDEyLTA5LTA2IDIwOjE3OjE5XSByOTogIGZmZmY4MzAwYWZkMTUw
NjAgICByMTA6IDAwMDAwMDAwZGVhZGJlZWYgICByMTE6IDAwMDAwMDAwMDAwMDAyNDYNCihY
RU4pIFsyMDEyLTA5LTA2IDIwOjE3OjE5XSByMTI6IGZmZmY4MzAwYWZkMTUwMDAgICByMTM6
IDAwMDAwMDAwMDAwMDAwMDQgICByMTQ6IDAwMDAwMDAwMDAwMDAwMDQNCihYRU4pIFsyMDEy
LTA5LTA2IDIwOjE3OjE5XSByMTU6IGZmZmY4MzAyNGQ4OWMwNDggICBjcjA6IDAwMDAwMDAw
ODAwNTAwM2IgICBjcjQ6IDAwMDAwMDAwMDAwMDA2ZjANCihYRU4pIFsyMDEyLTA5LTA2IDIw
OjE3OjE5XSBjcjM6IDAwMDAwMDAwNjhhNGEwMDAgICBjcjI6IGZmZmY4ODAwMWZjMGJkNDAN
CihYRU4pIFsyMDEyLTA5LTA2IDIwOjE3OjE5XSBkczogMDAwMCAgIGVzOiAwMDAwICAgZnM6
IDAwMDAgICBnczogMDAwMCAgIHNzOiBlMDEwICAgY3M6IGUwMDgNCihYRU4pIFsyMDEyLTA5
LTA2IDIwOjE3OjE5XSBYZW4gc3RhY2sgdHJhY2UgZnJvbSByc3A9ZmZmZjgzMDI0ZDg5N2Q4
ODoNCihYRU4pIFsyMDEyLTA5LTA2IDIwOjE3OjE5XSAgICBmZmZmODJjNDgwMzAyN2IwIGZm
ZmY4MmY2MDMyMTZiYzAgMDAwMDAwMWU5ZTBmNzAwMCAwMDAwMDAwMDAwMDAwMDAyDQooWEVO
KSBbMjAxMi0wOS0wNiAyMDoxNzoxOV0gICAgZmZmZjgzMDI0ZDg5N2RiOCBmZmZmODMwMjRk
ODljMDYwIGZmZmY4MzAyNGQ4OTdlMTggZmZmZjgyYzQ4MDE4MDViZQ0KKFhFTikgWzIwMTIt
MDktMDYgMjA6MTc6MTldICAgIDAwMDAwMDAwMDAwMDBjYjIgMDAwMDAxOGExNjBkNTliMiAw
MDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDANCihYRU4pIFsyMDEyLTA5LTA2IDIw
OjE3OjE5XSAgICAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDAgZmZmZjgzMDI0
ZDg5N2UyOCBmZmZmODMwMGFmZDE1MDAwDQooWEVOKSBbMjAxMi0wOS0wNiAyMDoxNzoxOV0g
ICAgZmZmZjgzMDBhNTJkYTAwMCAwMDAwMDA3MmQzZGRjMTNmIDAwMDAwMDAwMDAwMDAwMDIg
ZmZmZjgzMDI0ZDg5YzA0OA0KKFhFTikgWzIwMTItMDktMDYgMjA6MTc6MTldICAgIGZmZmY4
MzAyNGQ4OTdlYjggZmZmZjgyYzQ4MDEyNGE3MCAwMGZmODMwMjRkODk3ZTg4IGZmZmY4MzAy
NGQ4OWMwNDANCihYRU4pIFsyMDEyLTA5LTA2IDIwOjE3OjE5XSAgICAwMDAwMDAwNGRkYWQz
YTc5IDAwMDAwMDcyZDNkZGMxM2YgZmZmZjgzMDI0ZDg5N2U4OCBmZmZmZmZmZmZmZmZmZmMy
DQooWEVOKSBbMjAxMi0wOS0wNiAyMDoxNzoxOV0gICAgZmZmZjgzMDBhNTJkYTAwMCAwMDAw
MDAwMDAxYzljMzgwIGZmZmY4MzAyNGQ4OTdlMDAgZmZmZjgyYzQ4MDEyMjZjZQ0KKFhFTikg
WzIwMTItMDktMDYgMjA6MTc6MTldICAgIGZmZmY4MzAyNGQ4OTdlZjggZmZmZjgyYzQ4MDJk
ODIwMCAwMDAwMDAwMGZmZmZmZmZmIGZmZmY4MmM0ODAyZDgwMDANCihYRU4pIFsyMDEyLTA5
LTA2IDIwOjE3OjE5XSAgICBmZmZmODMwMjRkODk3ZjE4IGZmZmZmZmZmZmZmZmZmZmYgZmZm
ZjgzMDI0ZDg5N2VmOCBmZmZmODJjNDgwMTI1ZTMxDQooWEVOKSBbMjAxMi0wOS0wNiAyMDox
NzoxOV0gICAgZmZmZjgzMDI0ZDg5N2VkOCBmZmZmODMwMGFmZDE1MDAwIGZmZmZmZmZmODFl
Y2U1ZDggZmZmZmZmZmY4MWY0MjBjMA0KKFhFTikgWzIwMTItMDktMDYgMjA6MTc6MTldICAg
IDAwMDAwMDAwMDAwMDAwMDAgMDAwMDAwMDAwMDAwMDAwMCBmZmZmODMwMjRkODk3ZjA4IGZm
ZmY4MmM0ODAxMjVlNjgNCihYRU4pIFsyMDEyLTA5LTA2IDIwOjE3OjE5XSAgICAwMDAwN2Nm
ZGIyNzY4MGM3IGZmZmY4MmM0ODAyMjJmMDYgMDAwMDAwMDAwMDAwMDAwMCBmZmZmODgwMDFl
YWQyNGUwDQooWEVOKSBbMjAxMi0wOS0wNiAyMDoxNzoxOV0gICAgMDAwMDAwMDAwMDAwMDAw
MCBmZmZmODgwMDFkMzQwMGQ4IGZmZmY4ODAwMWNjMmZiZjAgZmZmZjg4MDAxZmMwYjEwMA0K
KFhFTikgWzIwMTItMDktMDYgMjA6MTc6MTldICAgIDAwMDAwMDAwMDAwMDAyMDIgMDAwMDAw
MDAwMDAwMDAwMCAwMDAwMDAwMDAwMDAwMDAwIDAwMDAwMDAwMDAwMDAwMDANCihYRU4pIFsy
MDEyLTA5LTA2IDIwOjE3OjE5XSAgICAwMDAwMDAwMDAwMDAwMDAwIGZmZmZmZmZmODEwMDEx
YWEgZmZmZjg4MDAxZWI4YjBjMCAwMDAwMDAwMGRlYWRiZWVmDQooWEVOKSBbMjAxMi0wOS0w
NiAyMDoxNzoxOV0gICAgMDAwMDAwMDBkZWFkYmVlZiAwMDAwMDBmYTAwMDAwMDAwIGZmZmZm
ZmZmODEwMDExYWEgMDAwMDAwMDAwMDAwZTAzMw0KKFhFTikgWzIwMTItMDktMDYgMjA6MTc6
MTldICAgIDAwMDAwMDAwMDAwMDAyMDIgZmZmZjg4MDAxY2MyZmJiOCAwMDAwMDAwMDAwMDBl
MDJiIDAwMDA0YmZkMDAwMGJlZWYNCihYRU4pIFsyMDEyLTA5LTA2IDIwOjE3OjE5XSAgICA4
MDAwMDAwMDAwMDBiZWVmIDc0MDAwMDAwMDAwMGJlZWYgMDAwMDAwMDAwMDE4YmVlZiAwMDAw
NGJmZTAwMDAwMDA0DQooWEVOKSBbMjAxMi0wOS0wNiAyMDoxNzoxOV0gICAgZmZmZjgzMDBh
NTJkYTAwMCAwMDAwMDAzZGNkNTlhNjgwIDAwMDAwMDAwMDAxOGUwYzkNCihYRU4pIFsyMDEy
LTA5LTA2IDIwOjE3OjE5XSBYZW4gY2FsbCB0cmFjZToNCihYRU4pIFsyMDEyLTA5LTA2IDIw
OjE3OjE5XSAgICBbPGZmZmY4MmM0ODAxNWM5ZmU+XSBjb250ZXh0X3N3aXRjaCsweDM5NC8w
eGVlYg0KKFhFTikgWzIwMTItMDktMDYgMjA6MTc6MTldICAgIFs8ZmZmZjgyYzQ4MDEyNGE3
MD5dIHNjaGVkdWxlKzB4NjY2LzB4Njc1DQooWEVOKSBbMjAxMi0wOS0wNiAyMDoxNzoxOV0g
ICAgWzxmZmZmODJjNDgwMTI1ZTMxPl0gX19kb19zb2Z0aXJxKzB4YTQvMHhiNQ0KKFhFTikg
WzIwMTItMDktMDYgMjA6MTc6MTldICAgIFs8ZmZmZjgyYzQ4MDEyNWU2OD5dIGRvX3NvZnRp
cnErMHgyNi8weDI4DQooWEVOKSBbMjAxMi0wOS0wNiAyMDoxNzoxOV0gICAgDQooWEVOKSBb
MjAxMi0wOS0wNiAyMDoxNzoxOV0gdHJhcHMuYzozMTU5OiAgIHNob3dfZXhlY3V0aW9uX3N0
YXRlKGd1ZXN0X2NwdV91c2VyX3JlZ3MoKSk6IA0KKFhFTikgWzIwMTItMDktMDYgMjA6MTc6
MTldIC0tLS1bIFhlbi00LjIuMC1yYzQtcHJlICB4ODZfNjQgIGRlYnVnPXkgIE5vdCB0YWlu
dGVkIF0tLS0tDQooWEVOKSBbMjAxMi0wOS0wNiAyMDoxNzoxOV0gQ1BVOiAgICA0DQooWEVO
KSBbMjAxMi0wOS0wNiAyMDoxNzoxOV0gUklQOiAgICBlMDMzOls8ZmZmZmZmZmY4MTAwMTFh
YT5dDQooWEVOKSBbMjAxMi0wOS0wNiAyMDoxNzoxOV0gUkZMQUdTOiAwMDAwMDAwMDAwMDAw
MjAyICAgRU06IDEgICBDT05URVhUOiBwdiBndWVzdA0KKFhFTikgWzIwMTItMDktMDYgMjA6
MTc6MTldIHJheDogMDAwMDAwMDAwMDAwMDAwMCAgIHJieDogZmZmZjg4MDAxZmMwYjEwMCAg
IHJjeDogZmZmZmZmZmY4MTAwMTFhYQ0KKFhFTikgWzIwMTItMDktMDYgMjA6MTc6MTldIHJk
eDogZmZmZjg4MDAxZWI4YjBjMCAgIHJzaTogMDAwMDAwMDBkZWFkYmVlZiAgIHJkaTogMDAw
MDAwMDBkZWFkYmVlZg0KKFhFTikgWzIwMTItMDktMDYgMjA6MTc6MTldIHJicDogZmZmZjg4
MDAxY2MyZmJmMCAgIHJzcDogZmZmZjg4MDAxY2MyZmJiOCAgIHI4OiAgMDAwMDAwMDAwMDAw
MDAwMA0KKFhFTikgWzIwMTItMDktMDYgMjA6MTc6MTldIHI5OiAgMDAwMDAwMDAwMDAwMDAw
MCAgIHIxMDogMDAwMDAwMDAwMDAwMDAwMCAgIHIxMTogMDAwMDAwMDAwMDAwMDIwMg0KKFhF
TikgWzIwMTItMDktMDYgMjA6MTc6MTldIHIxMjogZmZmZjg4MDAxZDM0MDBkOCAgIHIxMzog
MDAwMDAwMDAwMDAwMDAwMCAgIHIxNDogZmZmZjg4MDAxZWFkMjRlMA0KKFhFTikgWzIwMTIt
MDktMDYgMjA6MTc6MTldIHIxNTogMDAwMDAwMDAwMDAwMDAwMCAgIGNyMDogMDAwMDAwMDA4
MDA1MDAzYiAgIGNyNDogMDAwMDAwMDAwMDAwMDZmMA0KKFhFTikgWzIwMTItMDktMDYgMjA6
MTc6MTldIGNyMzogMDAwMDAwMDA2OGE0YTAwMCAgIGNyMjogMDAwMDAwMDBmNmIyMDBhYw0K
KFhFTikgWzIwMTItMDktMDYgMjA6MTc6MTldIGRzOiAwMDAwICAgZXM6IDAwMDAgICBmczog
MDAwMCAgIGdzOiAwMDAwICAgc3M6IGUwMmIgICBjczogZTAzMw0KKFhFTikgWzIwMTItMDkt
MDYgMjA6MTc6MTldIEd1ZXN0IHN0YWNrIHRyYWNlIGZyb20gcnNwPWZmZmY4ODAwMWNjMmZi
Yjg6DQooWEVOKSBbMjAxMi0wOS0wNiAyMDoxNzoxOV0gICAgMDAwMDAwMDAwMDAwMDAwMCAw
MDAwMDAwMDAwMDAwMDAxIGZmZmZmZmZmODEwMDQ5NDIgZmZmZjg4MDAxZWFkMjA4MA0KKFhF
TikgWzIwMTItMDktMDYgMjA6MTc6MTldICAgIGZmZmY4ODAwMWViOGIwYzAgMDAwMDAwMDAw
MDAwMDAwMCBmZmZmODgwMDFlYWQyNGUwIGZmZmY4ODAwMWNjMmZjMTANCihYRU4pIFsyMDEy
LTA5LTA2IDIwOjE3OjE5XSAgICBmZmZmZmZmZjgxMDAzOTQxIGZmZmY4ODAwMWViOGIwYzAg
ZmZmZjg4MDAxZWFkMjA4MCBmZmZmODgwMDFjYzJmYzcwDQooWEVOKSBbMjAxMi0wOS0wNiAy
MDoxNzoxOV0gICAgZmZmZmZmZmY4MTAwYjg1MCBmZmZmODgwMDFlYWQyMDgwIGZmZmY4ODAw
MWQzYjAwMDAgMDAwMDAwMDAwMDAwMDA2Mw0KKFhFTikgWzIwMTItMDktMDYgMjA6MTc6MTld
ICAgIGZmZmY4ODAwMWZjMTBhODAgZmZmZjg4MDAxY2MyZmM4MCBmZmZmODgwMDFmYzEyZTgw
IDAwMDAwMDAwMDAwMDAwMDANCihYRU4pIFsyMDEyLTA5LTA2IDIwOjE3OjE5XSAgICBmZmZm
ODgwMDFkM2I2NDAwIGZmZmY4ODAwMWQzNjc4MDAgZmZmZmZmZmZmZmZmMDAwMCBmZmZmODgw
MDFlYWQyMDgwDQooWEVOKSBbMjAxMi0wOS0wNiAyMDoxNzoxOV0gICAgZmZmZmZmZmY4MTdm
YTJmNSBmZmZmODgwMDFjYzJmZGQwIDAwMDAwMDAwMDAwMDAyMTYgZmZmZmZmZmY4MTA3MDBm
ZQ0KKFhFTikgWzIwMTItMDktMDYgMjA6MTc6MTldICAgIGZmZmY4ODAwMWZjMGUwMTggZmZm
Zjg4MDAxZWFkMjA4MCAwMDAwMDAwMDAwMDEyZTgwIGZmZmY4ODAwMWNjMmZmZDgNCihYRU4p
IFsyMDEyLTA5LTA2IDIwOjE3OjE5XSAgICBmZmZmODgwMDFjYzJlMDEwIDAwMDAwMDAwMDAw
MTJlODAgMDAwMDAwMDAwMDAxMmU4MCBmZmZmODgwMDFjYzJmZmQ4DQooWEVOKSBbMjAxMi0w
OS0wNiAyMDoxNzoxOV0gICAgMDAwMDAwMDAwMDAxMmU4MCBmZmZmODgwMDFlYjhiMGMwIGZm
ZmY4ODAwMWVhZDIwODAgZmZmZjg4MDAwMDAwMDAwMA0KKFhFTikgWzIwMTItMDktMDYgMjA6
MTc6MTldICAgIGZmZmY4ODAwMDAwMDAwMDAgZmZmZjg4MDAxZmMwZTAwMCBmZmZmODgwMDFj
Y2VjMGMwIGZmZmY4ODAwMWZjMTZlMDANCihYRU4pIFsyMDEyLTA5LTA2IDIwOjE3OjE5XSAg
ICBmZmZmODgwMDFmYzBlMDAwIGZmZmY4ODAwMWNjMmZkNTAgZmZmZmZmZmY4MTdmYjYxNCBm
ZmZmODgwMDFkMGUwMTQwDQooWEVOKSBbMjAxMi0wOS0wNiAyMDoxNzoxOV0gICAgZmZmZjg4
MDAxY2NlYzBjMCBmZmZmODgwMDFmYzE2ZTAwIGZmZmY4ODAwMWZjMGUwMDAgZmZmZjg4MDAx
Y2MyZmRlMA0KKFhFTikgWzIwMTItMDktMDYgMjA6MTc6MTldICAgIGZmZmZmZmZmODEwN2Yw
NTkgZmZmZjg4MDAxZWFkMjA4MCBmZmZmODgwMDFlYWQyMDgwIGZmZmZmZmZmODE3ZmJlN2IN
CihYRU4pIFsyMDEyLTA5LTA2IDIwOjE3OjE5XSAgICBmZmZmODgwMDFmYzBlNDQ4IGZmZmY4
ODAwMWVhZDIwODAgZmZmZjg4MDAxY2NlYzBlMCBmZmZmODgwMDFjYzJmZGIwDQooWEVOKSBb
MjAxMi0wOS0wNiAyMDoxNzoxOV0gICAgZmZmZmZmZmY4MTBhY2I3OCBmZmZmODgwMDFmYzBl
MDAwIGZmZmY4ODAwMWNjZWMwYzAgZmZmZjg4MDAxZmMwZTQzOA0KKFhFTikgWzIwMTItMDkt
MDYgMjA6MTc6MTldICAgIGZmZmY4ODAwMWZjMGU0NDggZmZmZjg4MDAxZWFkMjA4MCBmZmZm
ODgwMDFjY2VjMGUwIGZmZmY4ODAwMWNjMmZkZTANCihYRU4pIFsyMDEyLTA5LTA2IDIwOjE3
OjE5XSAgICBmZmZmZmZmZjgxN2ZhODE0IGZmZmY4ODAwMWNjMmZlYjAgZmZmZmZmZmY4MTA3
ZjZmOSAwMDAwMDAwMDAwMDAwMDAwDQooWEVOKSBbMjAxMi0wOS0wNiAyMDoxNzoxOV0gICAg
ZmZmZjg4MDAxY2MyZmU1MCBmZmZmODgwMDFlYWQyMDgwIGZmZmY4ODAwMWNjMmUwMTAgZmZm
Zjg4MDAxZWFkMDI4MA0KKFhFTikgWzIwMTItMDktMDYgMjA6MTc6MTldICAgIGZmZmY4ODAw
MWNjMmZlNjggZmZmZjg4MDAxZWFkMjA4MCBmZmZmODgwMDFlYWQyMDgwIGZmZmY4ODAwMWVh
ZDIwODANCg==
------------0E902503E1C6BF83E
Content-Type: text/plain;
 name="xm-dmesg-4.1.txt"
Content-transfer-encoding: base64
Content-Disposition: attachment;
 filename="xm-dmesg-4.1.txt"

DQooWEVOKSBBQ1BJOiBMb2NhbCBBUElDIGFkZHJlc3MgMHhmZWUwMDAwMA0KKFhFTikgQUNQ
STogTEFQSUMgKGFjcGlfaWRbMHgwMV0gbGFwaWNfaWRbMHgwMF0gZW5hYmxlZCkNCihYRU4p
IFByb2Nlc3NvciAjMCAwOjEwIEFQSUMgdmVyc2lvbiAxNg0KKFhFTikgQUNQSTogTEFQSUMg
KGFjcGlfaWRbMHgwMl0gbGFwaWNfaWRbMHgwMV0gZW5hYmxlZCkNCihYRU4pIFByb2Nlc3Nv
ciAjMSAwOjEwIEFQSUMgdmVyc2lvbiAxNg0KKFhFTikgQUNQSTogTEFQSUMgKGFjcGlfaWRb
MHgwM10gbGFwaWNfaWRbMHgwMl0gZW5hYmxlZCkNCihYRU4pIFByb2Nlc3NvciAjMiAwOjEw
IEFQSUMgdmVyc2lvbiAxNg0KKFhFTikgQUNQSTogTEFQSUMgKGFjcGlfaWRbMHgwNF0gbGFw
aWNfaWRbMHgwM10gZW5hYmxlZCkNCihYRU4pIFByb2Nlc3NvciAjMyAwOjEwIEFQSUMgdmVy
c2lvbiAxNg0KKFhFTikgQUNQSTogTEFQSUMgKGFjcGlfaWRbMHgwNV0gbGFwaWNfaWRbMHgw
NF0gZW5hYmxlZCkNCihYRU4pIFByb2Nlc3NvciAjNCAwOjEwIEFQSUMgdmVyc2lvbiAxNg0K
KFhFTikgQUNQSTogTEFQSUMgKGFjcGlfaWRbMHgwNl0gbGFwaWNfaWRbMHgwNV0gZW5hYmxl
ZCkNCihYRU4pIFByb2Nlc3NvciAjNSAwOjEwIEFQSUMgdmVyc2lvbiAxNg0KKFhFTikgQUNQ
STogSU9BUElDIChpZFsweDA2XSBhZGRyZXNzWzB4ZmVjMDAwMDBdIGdzaV9iYXNlWzBdKQ0K
KFhFTikgSU9BUElDWzBdOiBhcGljX2lkIDYsIHZlcnNpb24gMzMsIGFkZHJlc3MgMHhmZWMw
MDAwMCwgR1NJIDAtMjMNCihYRU4pIEFDUEk6IElPQVBJQyAoaWRbMHgwN10gYWRkcmVzc1sw
eGZlYzIwMDAwXSBnc2lfYmFzZVsyNF0pDQooWEVOKSBJT0FQSUNbMV06IGFwaWNfaWQgNywg
dmVyc2lvbiAzMywgYWRkcmVzcyAweGZlYzIwMDAwLCBHU0kgMjQtNTUNCihYRU4pIEFDUEk6
IElOVF9TUkNfT1ZSIChidXMgMCBidXNfaXJxIDAgZ2xvYmFsX2lycSAyIGRmbCBkZmwpDQoo
WEVOKSBBQ1BJOiBJTlRfU1JDX09WUiAoYnVzIDAgYnVzX2lycSA5IGdsb2JhbF9pcnEgOSBs
b3cgbGV2ZWwpDQooWEVOKSBBQ1BJOiBJUlEwIHVzZWQgYnkgb3ZlcnJpZGUuDQooWEVOKSBB
Q1BJOiBJUlEyIHVzZWQgYnkgb3ZlcnJpZGUuDQooWEVOKSBBQ1BJOiBJUlE5IHVzZWQgYnkg
b3ZlcnJpZGUuDQooWEVOKSBFbmFibGluZyBBUElDIG1vZGU6ICBGbGF0LiAgVXNpbmcgMiBJ
L08gQVBJQ3MNCihYRU4pIEFDUEk6IEhQRVQgaWQ6IDB4ODMwMCBiYXNlOiAweGZlZDAwMDAw
DQooWEVOKSBQQ0k6IE1DRkcgY29uZmlndXJhdGlvbiAwOiBiYXNlIGUwMDAwMDAwIHNlZ21l
bnQgMCBidXNlcyAwIC0gMjU1DQooWEVOKSBQQ0k6IE5vdCB1c2luZyBNTUNPTkZJRy4NCihY
RU4pIFRhYmxlIGlzIG5vdCBmb3VuZCENCihYRU4pIFVzaW5nIEFDUEkgKE1BRFQpIGZvciBT
TVAgY29uZmlndXJhdGlvbiBpbmZvcm1hdGlvbg0KKFhFTikgbWFwcGVkIEFQSUMgdG8gZmZm
ZjgyYzNmZmZmZTAwMCAoZmVlMDAwMDApDQooWEVOKSBtYXBwZWQgSU9BUElDIHRvIGZmZmY4
MmMzZmZmZmQwMDAgKGZlYzAwMDAwKQ0KKFhFTikgbWFwcGVkIElPQVBJQyB0byBmZmZmODJj
M2ZmZmZjMDAwIChmZWMyMDAwMCkNCihYRU4pIElSUSBsaW1pdHM6IDU2IEdTSSwgMTExMiBN
U0kvTVNJLVgNCihYRU4pIFVzaW5nIHNjaGVkdWxlcjogU01QIENyZWRpdCBTY2hlZHVsZXIg
KGNyZWRpdCkNCihYRU4pIERldGVjdGVkIDMyMDAuMTc2IE1IeiBwcm9jZXNzb3IuDQooWEVO
KSBJbml0aW5nIG1lbW9yeSBzaGFyaW5nLg0KKFhFTikgQU1EIEZhbTEwaCBtYWNoaW5lIGNo
ZWNrIHJlcG9ydGluZyBlbmFibGVkDQooWEVOKSBBTUQtVmk6IEZvdW5kIE1TSSBjYXBhYmls
aXR5IGJsb2NrIA0KKFhFTikgQU1ELVZpOiBBQ1BJIFRhYmxlOg0KKFhFTikgQU1ELVZpOiAg
U2lnbmF0dXJlIElWUlMNCihYRU4pIEFNRC1WaTogIExlbmd0aCAweGY4DQooWEVOKSBBTUQt
Vmk6ICBSZXZpc2lvbiAweDENCihYRU4pIEFNRC1WaTogIENoZWNrU3VtIDB4NmUNCihYRU4p
IEFNRC1WaTogIE9FTV9JZCBBTUQgIA0KKFhFTikgQU1ELVZpOiAgT0VNX1RhYmxlX0lkIFJE
ODkwUw0KKFhFTikgQU1ELVZpOiAgT0VNX1JldmlzaW9uIDB4MjAyMDMxDQooWEVOKSBBTUQt
Vmk6ICBDcmVhdG9yX0lkIEFNRCANCihYRU4pIEFNRC1WaTogIENyZWF0b3JfUmV2aXNpb24g
MHgwDQooWEVOKSBBTUQtVmk6IElWUlMgQmxvY2s6DQooWEVOKSBBTUQtVmk6ICBUeXBlIDB4
MTANCihYRU4pIEFNRC1WaTogIEZsYWdzIDB4M2UNCihYRU4pIEFNRC1WaTogIExlbmd0aCAw
eGM4DQooWEVOKSBBTUQtVmk6ICBEZXZfSWQgMHgyDQooWEVOKSBBTUQtVmk6IElWSEQgRGV2
aWNlIEVudHJ5Og0KKFhFTikgQU1ELVZpOiAgVHlwZSAweDMNCihYRU4pIEFNRC1WaTogIERl
dl9JZCAweDANCihYRU4pIEFNRC1WaTogIEZsYWdzIDB4MA0KKFhFTikgQU1ELVZpOiAgRGV2
X0lkIFJhbmdlOiAweDAgLT4gMHgyDQooWEVOKSBBTUQtVmk6IElWSEQgRGV2aWNlIEVudHJ5
Og0KKFhFTikgQU1ELVZpOiAgVHlwZSAweDINCihYRU4pIEFNRC1WaTogIERldl9JZCAweDEw
DQooWEVOKSBBTUQtVmk6ICBGbGFncyAweDANCihYRU4pIEFNRC1WaTogSVZIRCBEZXZpY2Ug
RW50cnk6DQooWEVOKSBBTUQtVmk6ICBUeXBlIDB4Mg0KKFhFTikgQU1ELVZpOiAgRGV2X0lk
IDB4YjAwDQooWEVOKSBBTUQtVmk6ICBGbGFncyAweDANCihYRU4pIEFNRC1WaTogSVZIRCBE
ZXZpY2UgRW50cnk6DQooWEVOKSBBTUQtVmk6ICBUeXBlIDB4Mg0KKFhFTikgQU1ELVZpOiAg
RGV2X0lkIDB4MTgNCihYRU4pIEFNRC1WaTogIEZsYWdzIDB4MA0KKFhFTikgQU1ELVZpOiBJ
VkhEIERldmljZSBFbnRyeToNCihYRU4pIEFNRC1WaTogIFR5cGUgMHgzDQooWEVOKSBBTUQt
Vmk6ICBEZXZfSWQgMHhhMDANCihYRU4pIEFNRC1WaTogIEZsYWdzIDB4MA0KKFhFTikgQU1E
LVZpOiAgRGV2X0lkIFJhbmdlOiAweGEwMCAtPiAweGEwNw0KKFhFTikgQU1ELVZpOiBJVkhE
IERldmljZSBFbnRyeToNCihYRU4pIEFNRC1WaTogIFR5cGUgMHgyDQooWEVOKSBBTUQtVmk6
ICBEZXZfSWQgMHgyOA0KKFhFTikgQU1ELVZpOiAgRmxhZ3MgMHgwDQooWEVOKSBBTUQtVmk6
IElWSEQgRGV2aWNlIEVudHJ5Og0KKFhFTikgQU1ELVZpOiAgVHlwZSAweDINCihYRU4pIEFN
RC1WaTogIERldl9JZCAweDkwMA0KKFhFTikgQU1ELVZpOiAgRmxhZ3MgMHgwDQooWEVOKSBB
TUQtVmk6IElWSEQgRGV2aWNlIEVudHJ5Og0KKFhFTikgQU1ELVZpOiAgVHlwZSAweDINCihY
RU4pIEFNRC1WaTogIERldl9JZCAweDMwDQooWEVOKSBBTUQtVmk6ICBGbGFncyAweDANCihY
RU4pIEFNRC1WaTogSVZIRCBEZXZpY2UgRW50cnk6DQooWEVOKSBBTUQtVmk6ICBUeXBlIDB4
Mg0KKFhFTikgQU1ELVZpOiAgRGV2X0lkIDB4ODAwDQooWEVOKSBBTUQtVmk6ICBGbGFncyAw
eDANCihYRU4pIEFNRC1WaTogSVZIRCBEZXZpY2UgRW50cnk6DQooWEVOKSBBTUQtVmk6ICBU
eXBlIDB4Mg0KKFhFTikgQU1ELVZpOiAgRGV2X0lkIDB4NTANCihYRU4pIEFNRC1WaTogIEZs
YWdzIDB4MA0KKFhFTikgQU1ELVZpOiBJVkhEIERldmljZSBFbnRyeToNCihYRU4pIEFNRC1W
aTogIFR5cGUgMHgyDQooWEVOKSBBTUQtVmk6ICBEZXZfSWQgMHg3MDANCihYRU4pIEFNRC1W
aTogIEZsYWdzIDB4MA0KKFhFTikgQU1ELVZpOiBJVkhEIERldmljZSBFbnRyeToNCihYRU4p
IEFNRC1WaTogIFR5cGUgMHgyDQooWEVOKSBBTUQtVmk6ICBEZXZfSWQgMHg1OA0KKFhFTikg
QU1ELVZpOiAgRmxhZ3MgMHgwDQooWEVOKSBBTUQtVmk6IElWSEQgRGV2aWNlIEVudHJ5Og0K
KFhFTikgQU1ELVZpOiAgVHlwZSAweDMNCihYRU4pIEFNRC1WaTogIERldl9JZCAweDYwMA0K
KFhFTikgQU1ELVZpOiAgRmxhZ3MgMHgwDQooWEVOKSBBTUQtVmk6ICBEZXZfSWQgUmFuZ2U6
IDB4NjAwIC0+IDB4NjAxDQooWEVOKSBBTUQtVmk6IElWSEQgRGV2aWNlIEVudHJ5Og0KKFhF
TikgQU1ELVZpOiAgVHlwZSAweDINCihYRU4pIEFNRC1WaTogIERldl9JZCAweDYwDQooWEVO
KSBBTUQtVmk6ICBGbGFncyAweDANCihYRU4pIEFNRC1WaTogSVZIRCBEZXZpY2UgRW50cnk6
DQooWEVOKSBBTUQtVmk6ICBUeXBlIDB4Mg0KKFhFTikgQU1ELVZpOiAgRGV2X0lkIDB4NTAw
DQooWEVOKSBBTUQtVmk6ICBGbGFncyAweDANCihYRU4pIEFNRC1WaTogSVZIRCBEZXZpY2Ug
RW50cnk6DQooWEVOKSBBTUQtVmk6ICBUeXBlIDB4Mg0KKFhFTikgQU1ELVZpOiAgRGV2X0lk
IDB4NjgNCihYRU4pIEFNRC1WaTogIEZsYWdzIDB4MA0KKFhFTikgQU1ELVZpOiBJVkhEIERl
dmljZSBFbnRyeToNCihYRU4pIEFNRC1WaTogIFR5cGUgMHgzDQooWEVOKSBBTUQtVmk6ICBE
ZXZfSWQgMHg0MDANCihYRU4pIEFNRC1WaTogIEZsYWdzIDB4MA0KKFhFTikgQU1ELVZpOiAg
RGV2X0lkIFJhbmdlOiAweDQwMCAtPiAweDQwNw0KKFhFTikgQU1ELVZpOiBJVkhEIERldmlj
ZSBFbnRyeToNCihYRU4pIEFNRC1WaTogIFR5cGUgMHgyDQooWEVOKSBBTUQtVmk6ICBEZXZf
SWQgMHg4OA0KKFhFTikgQU1ELVZpOiAgRmxhZ3MgMHgwDQooWEVOKSBBTUQtVmk6IElWSEQg
RGV2aWNlIEVudHJ5Og0KKFhFTikgQU1ELVZpOiAgVHlwZSAweDMNCihYRU4pIEFNRC1WaTog
IERldl9JZCAweDkwDQooWEVOKSBBTUQtVmk6ICBGbGFncyAweDANCihYRU4pIEFNRC1WaTog
IERldl9JZCBSYW5nZTogMHg5MCAtPiAweDkyDQooWEVOKSBBTUQtVmk6IElWSEQgRGV2aWNl
IEVudHJ5Og0KKFhFTikgQU1ELVZpOiAgVHlwZSAweDMNCihYRU4pIEFNRC1WaTogIERldl9J
ZCAweDk4DQooWEVOKSBBTUQtVmk6ICBGbGFncyAweDANCihYRU4pIEFNRC1WaTogIERldl9J
ZCBSYW5nZTogMHg5OCAtPiAweDlhDQooWEVOKSBBTUQtVmk6IElWSEQgRGV2aWNlIEVudHJ5
Og0KKFhFTikgQU1ELVZpOiAgVHlwZSAweDINCihYRU4pIEFNRC1WaTogIERldl9JZCAweGEw
DQooWEVOKSBBTUQtVmk6ICBGbGFncyAweGQ3DQooWEVOKSBBTUQtVmk6IElWSEQgRGV2aWNl
IEVudHJ5Og0KKFhFTikgQU1ELVZpOiAgVHlwZSAweDINCihYRU4pIEFNRC1WaTogIERldl9J
ZCAweGEzDQooWEVOKSBBTUQtVmk6ICBGbGFncyAweDANCihYRU4pIEFNRC1WaTogSVZIRCBE
ZXZpY2UgRW50cnk6DQooWEVOKSBBTUQtVmk6ICBUeXBlIDB4Mg0KKFhFTikgQU1ELVZpOiAg
RGV2X0lkIDB4YTQNCihYRU4pIEFNRC1WaTogIEZsYWdzIDB4MA0KKFhFTikgQU1ELVZpOiBJ
VkhEIERldmljZSBFbnRyeToNCihYRU4pIEFNRC1WaTogIFR5cGUgMHgwDQooWEVOKSBBTUQt
Vmk6ICBEZXZfSWQgMHgwDQooWEVOKSBBTUQtVmk6ICBGbGFncyAweDANCihYRU4pIEFNRC1W
aTogSVZIRCBEZXZpY2UgRW50cnk6DQooWEVOKSBBTUQtVmk6ICBUeXBlIDB4NDMNCihYRU4p
IEFNRC1WaTogIERldl9JZCAweDMwMA0KKFhFTikgQU1ELVZpOiAgRmxhZ3MgMHgwDQooWEVO
KSBBTUQtVmk6ICBEZXZfSWQgUmFuZ2U6IDB4MzAwIC0+IDB4M2ZmDQooWEVOKSBBTUQtVmk6
ICBEZXZfSWQgQWxpYXM6IDB4YTQNCihYRU4pIEFNRC1WaTogSVZIRCBEZXZpY2UgRW50cnk6
DQooWEVOKSBBTUQtVmk6ICBUeXBlIDB4Mg0KKFhFTikgQU1ELVZpOiAgRGV2X0lkIDB4YTUN
CihYRU4pIEFNRC1WaTogIEZsYWdzIDB4MA0KKFhFTikgQU1ELVZpOiBJVkhEIERldmljZSBF
bnRyeToNCihYRU4pIEFNRC1WaTogIFR5cGUgMHgyDQooWEVOKSBBTUQtVmk6ICBEZXZfSWQg
MHhhOA0KKFhFTikgQU1ELVZpOiAgRmxhZ3MgMHgwDQooWEVOKSBBTUQtVmk6IElWSEQgRGV2
aWNlIEVudHJ5Og0KKFhFTikgQU1ELVZpOiAgVHlwZSAweDINCihYRU4pIEFNRC1WaTogIERl
dl9JZCAweGE5DQooWEVOKSBBTUQtVmk6ICBGbGFncyAweDANCihYRU4pIEFNRC1WaTogSVZI
RCBEZXZpY2UgRW50cnk6DQooWEVOKSBBTUQtVmk6ICBUeXBlIDB4Mg0KKFhFTikgQU1ELVZp
OiAgRGV2X0lkIDB4MTAwDQooWEVOKSBBTUQtVmk6ICBGbGFncyAweDANCihYRU4pIEFNRC1W
aTogSVZIRCBEZXZpY2UgRW50cnk6DQooWEVOKSBBTUQtVmk6ICBUeXBlIDB4Mw0KKFhFTikg
QU1ELVZpOiAgRGV2X0lkIDB4YjANCihYRU4pIEFNRC1WaTogIEZsYWdzIDB4MA0KKFhFTikg
QU1ELVZpOiAgRGV2X0lkIFJhbmdlOiAweGIwIC0+IDB4YjINCihYRU4pIEFNRC1WaTogSVZI
RCBEZXZpY2UgRW50cnk6DQooWEVOKSBBTUQtVmk6ICBUeXBlIDB4MA0KKFhFTikgQU1ELVZp
OiAgRGV2X0lkIDB4MA0KKFhFTikgQU1ELVZpOiAgRmxhZ3MgMHgwDQooWEVOKSBBTUQtVmk6
IElWSEQgRGV2aWNlIEVudHJ5Og0KKFhFTikgQU1ELVZpOiAgVHlwZSAweDQ4DQooWEVOKSBB
TUQtVmk6ICBEZXZfSWQgMHgwDQooWEVOKSBBTUQtVmk6ICBGbGFncyAweGQ3DQooWEVOKSBB
TUQtVmk6IElWSEQgRGV2aWNlIEVudHJ5Og0KKFhFTikgQU1ELVZpOiAgVHlwZSAweDQ4DQoo
WEVOKSBBTUQtVmk6ICBEZXZfSWQgMHgwDQooWEVOKSBBTUQtVmk6ICBGbGFncyAweDANCihY
RU4pIEFNRC1WaTogQWRkIGRldmljZSB0YWJsZSBlbnRyeTogZGV2aWNlIGlkID0gMHgwMDAw
LCBpbnRlcnVwdCB0YWJsZSA9IDB4MjRkOTgwMDAwDQooWEVOKSBBTUQtVmk6IEFkZCBkZXZp
Y2UgdGFibGUgZW50cnk6IGRldmljZSBpZCA9IDB4MDAwMSwgaW50ZXJ1cHQgdGFibGUgPSAw
eDI0ZDk4MDAwMA0KKFhFTikgQU1ELVZpOiBBZGQgZGV2aWNlIHRhYmxlIGVudHJ5OiBkZXZp
Y2UgaWQgPSAweDAwMDIsIGludGVydXB0IHRhYmxlID0gMHgyNGQ5ODAwMDANCihYRU4pIEFN
RC1WaTogQWRkIGRldmljZSB0YWJsZSBlbnRyeTogZGV2aWNlIGlkID0gMHgwMDEwLCBpbnRl
cnVwdCB0YWJsZSA9IDB4MjRkOTgwMDAwDQooWEVOKSBBTUQtVmk6IEFkZCBkZXZpY2UgdGFi
bGUgZW50cnk6IGRldmljZSBpZCA9IDB4MDAxOCwgaW50ZXJ1cHQgdGFibGUgPSAweDI0ZDk4
MDAwMA0KKFhFTikgQU1ELVZpOiBBZGQgZGV2aWNlIHRhYmxlIGVudHJ5OiBkZXZpY2UgaWQg
PSAweDAwMjgsIGludGVydXB0IHRhYmxlID0gMHgyNGQ5ODAwMDANCihYRU4pIEFNRC1WaTog
QWRkIGRldmljZSB0YWJsZSBlbnRyeTogZGV2aWNlIGlkID0gMHgwMDMwLCBpbnRlcnVwdCB0
YWJsZSA9IDB4MjRkOTgwMDAwDQooWEVOKSBBTUQtVmk6IEFkZCBkZXZpY2UgdGFibGUgZW50
cnk6IGRldmljZSBpZCA9IDB4MDA1MCwgaW50ZXJ1cHQgdGFibGUgPSAweDI0ZDk4MDAwMA0K
KFhFTikgQU1ELVZpOiBBZGQgZGV2aWNlIHRhYmxlIGVudHJ5OiBkZXZpY2UgaWQgPSAweDAw
NTgsIGludGVydXB0IHRhYmxlID0gMHgyNGQ5ODAwMDANCihYRU4pIEFNRC1WaTogQWRkIGRl
dmljZSB0YWJsZSBlbnRyeTogZGV2aWNlIGlkID0gMHgwMDYwLCBpbnRlcnVwdCB0YWJsZSA9
IDB4MjRkOTgwMDAwDQooWEVOKSBBTUQtVmk6IEFkZCBkZXZpY2UgdGFibGUgZW50cnk6IGRl
dmljZSBpZCA9IDB4MDA2OCwgaW50ZXJ1cHQgdGFibGUgPSAweDI0ZDk4MDAwMA0KKFhFTikg
QU1ELVZpOiBBZGQgZGV2aWNlIHRhYmxlIGVudHJ5OiBkZXZpY2UgaWQgPSAweDAwODgsIGlu
dGVydXB0IHRhYmxlID0gMHgyNGQ5ODAwMDANCihYRU4pIEFNRC1WaTogQWRkIGRldmljZSB0
YWJsZSBlbnRyeTogZGV2aWNlIGlkID0gMHgwMDkwLCBpbnRlcnVwdCB0YWJsZSA9IDB4MjRk
OTgwMDAwDQooWEVOKSBBTUQtVmk6IEFkZCBkZXZpY2UgdGFibGUgZW50cnk6IGRldmljZSBp
ZCA9IDB4MDA5MSwgaW50ZXJ1cHQgdGFibGUgPSAweDI0ZDk4MDAwMA0KKFhFTikgQU1ELVZp
OiBBZGQgZGV2aWNlIHRhYmxlIGVudHJ5OiBkZXZpY2UgaWQgPSAweDAwOTIsIGludGVydXB0
IHRhYmxlID0gMHgyNGQ5ODAwMDANCihYRU4pIEFNRC1WaTogQWRkIGRldmljZSB0YWJsZSBl
bnRyeTogZGV2aWNlIGlkID0gMHgwMDk4LCBpbnRlcnVwdCB0YWJsZSA9IDB4MjRkOTgwMDAw
DQooWEVOKSBBTUQtVmk6IEFkZCBkZXZpY2UgdGFibGUgZW50cnk6IGRldmljZSBpZCA9IDB4
MDA5OSwgaW50ZXJ1cHQgdGFibGUgPSAweDI0ZDk4MDAwMA0KKFhFTikgQU1ELVZpOiBBZGQg
ZGV2aWNlIHRhYmxlIGVudHJ5OiBkZXZpY2UgaWQgPSAweDAwOWEsIGludGVydXB0IHRhYmxl
ID0gMHgyNGQ5ODAwMDANCihYRU4pIEFNRC1WaTogQWRkIGRldmljZSB0YWJsZSBlbnRyeTog
ZGV2aWNlIGlkID0gMHgwMGEwLCBpbnRlcnVwdCB0YWJsZSA9IDB4MjRkOTgwMDAwDQooWEVO
KSBBTUQtVmk6IEFkZCBkZXZpY2UgdGFibGUgZW50cnk6IGRldmljZSBpZCA9IDB4MDBhMywg
aW50ZXJ1cHQgdGFibGUgPSAweDI0ZDk4MDAwMA0KKFhFTikgQU1ELVZpOiBBZGQgZGV2aWNl
IHRhYmxlIGVudHJ5OiBkZXZpY2UgaWQgPSAweDAwYTQsIGludGVydXB0IHRhYmxlID0gMHgy
NGQ5ODAwMDANCihYRU4pIEFNRC1WaTogQWRkIGRldmljZSB0YWJsZSBlbnRyeTogZGV2aWNl
IGlkID0gMHgwMGE1LCBpbnRlcnVwdCB0YWJsZSA9IDB4MjRkOTgwMDAwDQooWEVOKSBBTUQt
Vmk6IEFkZCBkZXZpY2UgdGFibGUgZW50cnk6IGRldmljZSBpZCA9IDB4MDBhOCwgaW50ZXJ1
cHQgdGFibGUgPSAweDI0ZDk4MDAwMA0KKFhFTikgQU1ELVZpOiBBZGQgZGV2aWNlIHRhYmxl
IGVudHJ5OiBkZXZpY2UgaWQgPSAweDAwYTksIGludGVydXB0IHRhYmxlID0gMHgyNGQ5ODAw
MDANCihYRU4pIEFNRC1WaTogQWRkIGRldmljZSB0YWJsZSBlbnRyeTogZGV2aWNlIGlkID0g
MHgwMGIwLCBpbnRlcnVwdCB0YWJsZSA9IDB4MjRkOTgwMDAwDQooWEVOKSBBTUQtVmk6IEFk
ZCBkZXZpY2UgdGFibGUgZW50cnk6IGRldmljZSBpZCA9IDB4MDBiMSwgaW50ZXJ1cHQgdGFi
bGUgPSAweDI0ZDk4MDAwMA0KKFhFTikgQU1ELVZpOiBBZGQgZGV2aWNlIHRhYmxlIGVudHJ5
OiBkZXZpY2UgaWQgPSAweDAwYjIsIGludGVydXB0IHRhYmxlID0gMHgyNGQ5ODAwMDANCihY
RU4pIEFNRC1WaTogQWRkIGRldmljZSB0YWJsZSBlbnRyeTogZGV2aWNlIGlkID0gMHgwMTAw
LCBpbnRlcnVwdCB0YWJsZSA9IDB4MjRkOTgwMDAwDQooWEVOKSBBTUQtVmk6IEFkZCBkZXZp
Y2UgdGFibGUgZW50cnk6IGRldmljZSBpZCA9IDB4MDQwMCwgaW50ZXJ1cHQgdGFibGUgPSAw
eDI0ZDk4MDAwMA0KKFhFTikgQU1ELVZpOiBBZGQgZGV2aWNlIHRhYmxlIGVudHJ5OiBkZXZp
Y2UgaWQgPSAweDA0MDEsIGludGVydXB0IHRhYmxlID0gMHgyNGQ5ODAwMDANCihYRU4pIEFN
RC1WaTogQWRkIGRldmljZSB0YWJsZSBlbnRyeTogZGV2aWNlIGlkID0gMHgwNDAyLCBpbnRl
cnVwdCB0YWJsZSA9IDB4MjRkOTgwMDAwDQooWEVOKSBBTUQtVmk6IEFkZCBkZXZpY2UgdGFi
bGUgZW50cnk6IGRldmljZSBpZCA9IDB4MDQwMywgaW50ZXJ1cHQgdGFibGUgPSAweDI0ZDk4
MDAwMA0KKFhFTikgQU1ELVZpOiBBZGQgZGV2aWNlIHRhYmxlIGVudHJ5OiBkZXZpY2UgaWQg
PSAweDA0MDQsIGludGVydXB0IHRhYmxlID0gMHgyNGQ5ODAwMDANCihYRU4pIEFNRC1WaTog
QWRkIGRldmljZSB0YWJsZSBlbnRyeTogZGV2aWNlIGlkID0gMHgwNDA1LCBpbnRlcnVwdCB0
YWJsZSA9IDB4MjRkOTgwMDAwDQooWEVOKSBBTUQtVmk6IEFkZCBkZXZpY2UgdGFibGUgZW50
cnk6IGRldmljZSBpZCA9IDB4MDQwNiwgaW50ZXJ1cHQgdGFibGUgPSAweDI0ZDk4MDAwMA0K
KFhFTikgQU1ELVZpOiBBZGQgZGV2aWNlIHRhYmxlIGVudHJ5OiBkZXZpY2UgaWQgPSAweDA0
MDcsIGludGVydXB0IHRhYmxlID0gMHgyNGQ5ODAwMDANCihYRU4pIEFNRC1WaTogQWRkIGRl
dmljZSB0YWJsZSBlbnRyeTogZGV2aWNlIGlkID0gMHgwNTAwLCBpbnRlcnVwdCB0YWJsZSA9
IDB4MjRkOTgwMDAwDQooWEVOKSBBTUQtVmk6IEFkZCBkZXZpY2UgdGFibGUgZW50cnk6IGRl
dmljZSBpZCA9IDB4MDYwMCwgaW50ZXJ1cHQgdGFibGUgPSAweDI0ZDk4MDAwMA0KKFhFTikg
QU1ELVZpOiBBZGQgZGV2aWNlIHRhYmxlIGVudHJ5OiBkZXZpY2UgaWQgPSAweDA2MDEsIGlu
dGVydXB0IHRhYmxlID0gMHgyNGQ5ODAwMDANCihYRU4pIEFNRC1WaTogQWRkIGRldmljZSB0
YWJsZSBlbnRyeTogZGV2aWNlIGlkID0gMHgwNzAwLCBpbnRlcnVwdCB0YWJsZSA9IDB4MjRk
OTgwMDAwDQooWEVOKSBBTUQtVmk6IEFkZCBkZXZpY2UgdGFibGUgZW50cnk6IGRldmljZSBp
ZCA9IDB4MDgwMCwgaW50ZXJ1cHQgdGFibGUgPSAweDI0ZDk4MDAwMA0KKFhFTikgQU1ELVZp
OiBBZGQgZGV2aWNlIHRhYmxlIGVudHJ5OiBkZXZpY2UgaWQgPSAweDA5MDAsIGludGVydXB0
IHRhYmxlID0gMHgyNGQ5ODAwMDANCihYRU4pIEFNRC1WaTogQWRkIGRldmljZSB0YWJsZSBl
bnRyeTogZGV2aWNlIGlkID0gMHgwYTAwLCBpbnRlcnVwdCB0YWJsZSA9IDB4MjRkOTgwMDAw
DQooWEVOKSBBTUQtVmk6IEFkZCBkZXZpY2UgdGFibGUgZW50cnk6IGRldmljZSBpZCA9IDB4
MGEwMSwgaW50ZXJ1cHQgdGFibGUgPSAweDI0ZDk4MDAwMA0KKFhFTikgQU1ELVZpOiBBZGQg
ZGV2aWNlIHRhYmxlIGVudHJ5OiBkZXZpY2UgaWQgPSAweDBhMDIsIGludGVydXB0IHRhYmxl
ID0gMHgyNGQ5ODAwMDANCihYRU4pIEFNRC1WaTogQWRkIGRldmljZSB0YWJsZSBlbnRyeTog
ZGV2aWNlIGlkID0gMHgwYTAzLCBpbnRlcnVwdCB0YWJsZSA9IDB4MjRkOTgwMDAwDQooWEVO
KSBBTUQtVmk6IEFkZCBkZXZpY2UgdGFibGUgZW50cnk6IGRldmljZSBpZCA9IDB4MGEwNCwg
aW50ZXJ1cHQgdGFibGUgPSAweDI0ZDk4MDAwMA0KKFhFTikgQU1ELVZpOiBBZGQgZGV2aWNl
IHRhYmxlIGVudHJ5OiBkZXZpY2UgaWQgPSAweDBhMDUsIGludGVydXB0IHRhYmxlID0gMHgy
NGQ5ODAwMDANCihYRU4pIEFNRC1WaTogQWRkIGRldmljZSB0YWJsZSBlbnRyeTogZGV2aWNl
IGlkID0gMHgwYTA2LCBpbnRlcnVwdCB0YWJsZSA9IDB4MjRkOTgwMDAwDQooWEVOKSBBTUQt
Vmk6IEFkZCBkZXZpY2UgdGFibGUgZW50cnk6IGRldmljZSBpZCA9IDB4MGEwNywgaW50ZXJ1
cHQgdGFibGUgPSAweDI0ZDk4MDAwMA0KKFhFTikgQU1ELVZpOiBBZGQgZGV2aWNlIHRhYmxl
IGVudHJ5OiBkZXZpY2UgaWQgPSAweDBiMDAsIGludGVydXB0IHRhYmxlID0gMHgyNGQ5ODAw
MDANCihYRU4pIEFNRC1WaTogSU9NTVUgMCBFbmFibGVkLg0KKFhFTikgQU1ELVZpOiBFbmFi
bGluZyBnbG9iYWwgdmVjdG9yIG1hcA0KKFhFTikgSS9PIHZpcnR1YWxpc2F0aW9uIGVuYWJs
ZWQNCihYRU4pICAtIERvbTAgbW9kZTogUmVsYXhlZA0KKFhFTikgR2V0dGluZyBWRVJTSU9O
OiA4MDA1MDAxMA0KKFhFTikgR2V0dGluZyBWRVJTSU9OOiA4MDA1MDAxMA0KKFhFTikgR2V0
dGluZyBJRDogMA0KKFhFTikgR2V0dGluZyBMVlQwOiA3MDANCihYRU4pIEdldHRpbmcgTFZU
MTogNDAwDQooWEVOKSBlbmFibGVkIEV4dElOVCBvbiBDUFUjMA0KKFhFTikgRVNSIHZhbHVl
IGJlZm9yZSBlbmFibGluZyB2ZWN0b3I6IDB4MDAwMDAwMDQgIGFmdGVyOiAweDAwMDAwMDAw
DQooWEVOKSBFTkFCTElORyBJTy1BUElDIElSUXMNCihYRU4pICAtPiBVc2luZyBuZXcgQUNL
IG1ldGhvZA0KKFhFTikgaW5pdCBJT19BUElDIElSUXMNCihYRU4pICBJTy1BUElDIChhcGlj
aWQtcGluKSA2LTAsIDYtMTYsIDYtMTcsIDYtMTgsIDYtMTksIDYtMjAsIDYtMjEsIDYtMjIs
IDYtMjMsIDctMCwgNy0xLCA3LTIsIDctMywgNy00LCA3LTUsIDctNiwgNy03LCA3LTgsIDct
OSwgNy0xMCwgNy0xMSwgNy0xMiwgNy0xMywgNy0xNCwgNy0xNSwgNy0xNiwgNy0xNywgNy0x
OCwgNy0xOSwgNy0yMCwgNy0yMSwgNy0yMiwgNy0yMywgNy0yNCwgNy0yNSwgNy0yNiwgNy0y
NywgNy0yOCwgNy0yOSwgNy0zMCwgNy0zMSBub3QgY29ubmVjdGVkLg0KKFhFTikgLi5USU1F
UjogdmVjdG9yPTB4RjAgYXBpYzE9MCBwaW4xPTIgYXBpYzI9LTEgcGluMj0tMQ0KKFhFTikg
bnVtYmVyIG9mIE1QIElSUSBzb3VyY2VzOiAxNS4NCihYRU4pIG51bWJlciBvZiBJTy1BUElD
ICM2IHJlZ2lzdGVyczogMjQuDQooWEVOKSBudW1iZXIgb2YgSU8tQVBJQyAjNyByZWdpc3Rl
cnM6IDMyLg0KKFhFTikgdGVzdGluZyB0aGUgSU8gQVBJQy4uLi4uLi4uLi4uLi4uLi4uLi4u
Li4uDQooWEVOKSBJTyBBUElDICM2Li4uLi4uDQooWEVOKSAuLi4uIHJlZ2lzdGVyICMwMDog
MDYwMDAwMDANCihYRU4pIC4uLi4uLi4gICAgOiBwaHlzaWNhbCBBUElDIGlkOiAwNg0KKFhF
TikgLi4uLi4uLiAgICA6IERlbGl2ZXJ5IFR5cGU6IDANCihYRU4pIC4uLi4uLi4gICAgOiBM
VFMgICAgICAgICAgOiAwDQooWEVOKSAuLi4uIHJlZ2lzdGVyICMwMTogMDAxNzgwMjENCihY
RU4pIC4uLi4uLi4gICAgIDogbWF4IHJlZGlyZWN0aW9uIGVudHJpZXM6IDAwMTcNCihYRU4p
IC4uLi4uLi4gICAgIDogUFJRIGltcGxlbWVudGVkOiAxDQooWEVOKSAuLi4uLi4uICAgICA6
IElPIEFQSUMgdmVyc2lvbjogMDAyMQ0KKFhFTikgLi4uLiByZWdpc3RlciAjMDI6IDA2MDAw
MDAwDQooWEVOKSAuLi4uLi4uICAgICA6IGFyYml0cmF0aW9uOiAwNg0KKFhFTikgLi4uLiBy
ZWdpc3RlciAjMDM6IDA3MDAwMDAwDQooWEVOKSAuLi4uLi4uICAgICA6IEJvb3QgRFQgICAg
OiAwDQooWEVOKSAuLi4uIElSUSByZWRpcmVjdGlvbiB0YWJsZToNCihYRU4pICBOUiBMb2cg
UGh5IE1hc2sgVHJpZyBJUlIgUG9sIFN0YXQgRGVzdCBEZWxpIFZlY3Q6ICAgDQooWEVOKSAg
MDAgMDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAwICAgIDAgICAgMCAgICAwMA0KKFhFTikg
IDAxIDAwMSAwMSAgMCAgICAwICAgIDAgICAwICAgMCAgICAxICAgIDEgICAgMzANCihYRU4p
ICAwMiAwMDEgMDEgIDAgICAgMCAgICAwICAgMCAgIDAgICAgMSAgICAxICAgIEYwDQooWEVO
KSAgMDMgMDAxIDAxICAwICAgIDAgICAgMCAgIDAgICAwICAgIDEgICAgMSAgICAzOA0KKFhF
TikgIDA0IDAwMSAwMSAgMCAgICAwICAgIDAgICAwICAgMCAgICAxICAgIDEgICAgRjENCihY
RU4pICAwNSAwMDEgMDEgIDAgICAgMCAgICAwICAgMCAgIDAgICAgMSAgICAxICAgIDQwDQoo
WEVOKSAgMDYgMDAxIDAxICAwICAgIDAgICAgMCAgIDAgICAwICAgIDEgICAgMSAgICA0OA0K
KFhFTikgIDA3IDAwMSAwMSAgMCAgICAwICAgIDAgICAwICAgMCAgICAxICAgIDEgICAgNTAN
CihYRU4pICAwOCAwMDEgMDEgIDAgICAgMCAgICAwICAgMCAgIDAgICAgMSAgICAxICAgIDU4
DQooWEVOKSAgMDkgMDAxIDAxICAxICAgIDEgICAgMCAgIDEgICAwICAgIDEgICAgMSAgICA2
MA0KKFhFTikgIDBhIDAwMSAwMSAgMCAgICAwICAgIDAgICAwICAgMCAgICAxICAgIDEgICAg
NjgNCihYRU4pICAwYiAwMDEgMDEgIDAgICAgMCAgICAwICAgMCAgIDAgICAgMSAgICAxICAg
IDcwDQooWEVOKSAgMGMgMDAxIDAxICAwICAgIDAgICAgMCAgIDAgICAwICAgIDEgICAgMSAg
ICA3OA0KKFhFTikgIDBkIDAwMSAwMSAgMCAgICAwICAgIDAgICAwICAgMCAgICAxICAgIDEg
ICAgODgNCihYRU4pICAwZSAwMDEgMDEgIDAgICAgMCAgICAwICAgMCAgIDAgICAgMSAgICAx
ICAgIDkwDQooWEVOKSAgMGYgMDAxIDAxICAwICAgIDAgICAgMCAgIDAgICAwICAgIDEgICAg
MSAgICA5OA0KKFhFTikgIDEwIDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAg
IDAgICAgMDANCihYRU4pICAxMSAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAg
ICAwICAgIDAwDQooWEVOKSAgMTIgMDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAwICAgIDAg
ICAgMCAgICAwMA0KKFhFTikgIDEzIDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAw
ICAgIDAgICAgMDANCihYRU4pICAxNCAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAg
MCAgICAwICAgIDAwDQooWEVOKSAgMTUgMDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAwICAg
IDAgICAgMCAgICAwMA0KKFhFTikgIDE2IDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAg
ICAwICAgIDAgICAgMDANCihYRU4pICAxNyAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAg
ICAgMCAgICAwICAgIDAwDQooWEVOKSBJTyBBUElDICM3Li4uLi4uDQooWEVOKSAuLi4uIHJl
Z2lzdGVyICMwMDogMDcwMDAwMDANCihYRU4pIC4uLi4uLi4gICAgOiBwaHlzaWNhbCBBUElD
IGlkOiAwNw0KKFhFTikgLi4uLi4uLiAgICA6IERlbGl2ZXJ5IFR5cGU6IDANCihYRU4pIC4u
Li4uLi4gICAgOiBMVFMgICAgICAgICAgOiAwDQooWEVOKSAuLi4uIHJlZ2lzdGVyICMwMTog
MDAxRjgwMjENCihYRU4pIC4uLi4uLi4gICAgIDogbWF4IHJlZGlyZWN0aW9uIGVudHJpZXM6
IDAwMUYNCihYRU4pIC4uLi4uLi4gICAgIDogUFJRIGltcGxlbWVudGVkOiAxDQooWEVOKSAu
Li4uLi4uICAgICA6IElPIEFQSUMgdmVyc2lvbjogMDAyMQ0KKFhFTikgLi4uLiByZWdpc3Rl
ciAjMDI6IDAwMDAwMDAwDQooWEVOKSAuLi4uLi4uICAgICA6IGFyYml0cmF0aW9uOiAwMA0K
KFhFTikgLi4uLiBJUlEgcmVkaXJlY3Rpb24gdGFibGU6DQooWEVOKSAgTlIgTG9nIFBoeSBN
YXNrIFRyaWcgSVJSIFBvbCBTdGF0IERlc3QgRGVsaSBWZWN0OiAgIA0KKFhFTikgIDAwIDAw
MCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDAgICAgMDANCihYRU4pICAwMSAw
MDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwDQooWEVOKSAgMDIg
MDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAwICAgIDAgICAgMCAgICAwMA0KKFhFTikgIDAz
IDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDAgICAgMDANCihYRU4pICAw
NCAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwDQooWEVOKSAg
MDUgMDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAwICAgIDAgICAgMCAgICAwMA0KKFhFTikg
IDA2IDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDAgICAgMDANCihYRU4p
ICAwNyAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwDQooWEVO
KSAgMDggMDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAwICAgIDAgICAgMCAgICAwMA0KKFhF
TikgIDA5IDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDAgICAgMDANCihY
RU4pICAwYSAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwDQoo
WEVOKSAgMGIgMDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAwICAgIDAgICAgMCAgICAwMA0K
KFhFTikgIDBjIDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDAgICAgMDAN
CihYRU4pICAwZCAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAw
DQooWEVOKSAgMGUgMDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAwICAgIDAgICAgMCAgICAw
MA0KKFhFTikgIDBmIDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDAgICAg
MDANCihYRU4pICAxMCAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAg
IDAwDQooWEVOKSAgMTEgMDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAwICAgIDAgICAgMCAg
ICAwMA0KKFhFTikgIDEyIDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDAg
ICAgMDANCihYRU4pICAxMyAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAw
ICAgIDAwDQooWEVOKSAgMTQgMDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAwICAgIDAgICAg
MCAgICAwMA0KKFhFTikgIDE1IDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAg
IDAgICAgMDANCihYRU4pICAxNiAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAg
ICAwICAgIDAwDQooWEVOKSAgMTcgMDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAwICAgIDAg
ICAgMCAgICAwMA0KKFhFTikgIDE4IDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAw
ICAgIDAgICAgMDANCihYRU4pICAxOSAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAg
MCAgICAwICAgIDAwDQooWEVOKSAgMWEgMDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAwICAg
IDAgICAgMCAgICAwMA0KKFhFTikgIDFiIDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAg
ICAwICAgIDAgICAgMDANCihYRU4pICAxYyAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAg
ICAgMCAgICAwICAgIDAwDQooWEVOKSAgMWQgMDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAw
ICAgIDAgICAgMCAgICAwMA0KKFhFTikgIDFlIDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAg
MCAgICAwICAgIDAgICAgMDANCihYRU4pICAxZiAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAg
IDAgICAgMCAgICAwICAgIDAwDQooWEVOKSBVc2luZyB2ZWN0b3ItYmFzZWQgaW5kZXhpbmcN
CihYRU4pIElSUSB0byBwaW4gbWFwcGluZ3M6DQooWEVOKSBJUlEyNDAgLT4gMDoyDQooWEVO
KSBJUlE0OCAtPiAwOjENCihYRU4pIElSUTU2IC0+IDA6Mw0KKFhFTikgSVJRMjQxIC0+IDA6
NA0KKFhFTikgSVJRNjQgLT4gMDo1DQooWEVOKSBJUlE3MiAtPiAwOjYNCihYRU4pIElSUTgw
IC0+IDA6Nw0KKFhFTikgSVJRODggLT4gMDo4DQooWEVOKSBJUlE5NiAtPiAwOjkNCihYRU4p
IElSUTEwNCAtPiAwOjEwDQooWEVOKSBJUlExMTIgLT4gMDoxMQ0KKFhFTikgSVJRMTIwIC0+
IDA6MTINCihYRU4pIElSUTEzNiAtPiAwOjEzDQooWEVOKSBJUlExNDQgLT4gMDoxNA0KKFhF
TikgSVJRMTUyIC0+IDA6MTUNCihYRU4pIC4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u
Li4uLi4uLiBkb25lLg0KKFhFTikgVXNpbmcgbG9jYWwgQVBJQyB0aW1lciBpbnRlcnJ1cHRz
Lg0KKFhFTikgY2FsaWJyYXRpbmcgQVBJQyB0aW1lciAuLi4NCihYRU4pIC4uLi4uIENQVSBj
bG9jayBzcGVlZCBpcyAzMjAwLjIwNDAgTUh6Lg0KKFhFTikgLi4uLi4gaG9zdCBidXMgY2xv
Y2sgc3BlZWQgaXMgMjAwLjAxMjYgTUh6Lg0KKFhFTikgLi4uLi4gYnVzX3NjYWxlID0gMHgw
MDAwQ0NENw0KKFhFTikgWzIwMTItMDktMDYgMjI6MTQ6MzNdIFBsYXRmb3JtIHRpbWVyIGlz
IDE0LjMxOE1IeiBIUEVUDQooWEVOKSBbMjAxMi0wOS0wNiAyMjoxNDozM10gQWxsb2NhdGVk
IGNvbnNvbGUgcmluZyBvZiA2NCBLaUIuDQooWEVOKSBbMjAxMi0wOS0wNiAyMjoxNDozM10g
SFZNOiBBU0lEcyBlbmFibGVkLg0KKFhFTikgWzIwMTItMDktMDYgMjI6MTQ6MzNdIFNWTTog
U3VwcG9ydGVkIGFkdmFuY2VkIGZlYXR1cmVzOg0KKFhFTikgWzIwMTItMDktMDYgMjI6MTQ6
MzNdICAtIE5lc3RlZCBQYWdlIFRhYmxlcyAoTlBUKQ0KKFhFTikgWzIwMTItMDktMDYgMjI6
MTQ6MzNdICAtIExhc3QgQnJhbmNoIFJlY29yZCAoTEJSKSBWaXJ0dWFsaXNhdGlvbg0KKFhF
TikgWzIwMTItMDktMDYgMjI6MTQ6MzNdICAtIE5leHQtUklQIFNhdmVkIG9uICNWTUVYSVQN
CihYRU4pIFsyMDEyLTA5LTA2IDIyOjE0OjMzXSAgLSBQYXVzZS1JbnRlcmNlcHQgRmlsdGVy
DQooWEVOKSBbMjAxMi0wOS0wNiAyMjoxNDozM10gSFZNOiBTVk0gZW5hYmxlZA0KKFhFTikg
WzIwMTItMDktMDYgMjI6MTQ6MzNdIEhWTTogSGFyZHdhcmUgQXNzaXN0ZWQgUGFnaW5nIChI
QVApIGRldGVjdGVkDQooWEVOKSBbMjAxMi0wOS0wNiAyMjoxNDozM10gSFZNOiBIQVAgcGFn
ZSBzaXplczogNGtCLCAyTUIsIDFHQg0KKFhFTikgWzIwMTItMDktMDYgMjI6MTQ6MzJdIG1h
c2tlZCBFeHRJTlQgb24gQ1BVIzENCihYRU4pIFsyMDEyLTA5LTA2IDIyOjE0OjMyXSBtYXNr
ZWQgRXh0SU5UIG9uIENQVSMyDQooWEVOKSBbMjAxMi0wOS0wNiAyMjoxNDozMl0gbWFza2Vk
IEV4dElOVCBvbiBDUFUjMw0KKFhFTikgWzIwMTItMDktMDYgMjI6MTQ6MzJdIG1hc2tlZCBF
eHRJTlQgb24gQ1BVIzQNCihYRU4pIFsyMDEyLTA5LTA2IDIyOjE0OjMyXSBtYXNrZWQgRXh0
SU5UIG9uIENQVSM1DQooWEVOKSBbMjAxMi0wOS0wNiAyMjoxNDozM10gQnJvdWdodCB1cCA2
IENQVXMNCihYRU4pIFsyMDEyLTA5LTA2IDIyOjE0OjMzXSBIUEVUXDA0N3MgTVNJIG1vZGUg
aGFzblwwNDd0IGJlZW4gc3VwcG9ydGVkIHdoZW4gSW50ZXJydXB0IFJlbWFwcGluZyBpcyBl
bmFibGVkLg0KKFhFTikgWzIwMTItMDktMDYgMjI6MTQ6MzNdIEFDUEkgc2xlZXAgbW9kZXM6
IFMzDQooWEVOKSBbMjAxMi0wOS0wNiAyMjoxNDozM10gTUNBOiBVc2UgaHcgdGhyZXNob2xk
aW5nIHRvIGFkanVzdCBwb2xsaW5nIGZyZXF1ZW5jeQ0KKFhFTikgWzIwMTItMDktMDYgMjI6
MTQ6MzNdIG1jaGVja19wb2xsOiBNYWNoaW5lIGNoZWNrIHBvbGxpbmcgdGltZXIgc3RhcnRl
ZC4NCihYRU4pIFsyMDEyLTA5LTA2IDIyOjE0OjMzXSBYZW5vcHJvZmlsZTogRmFpbGVkIHRv
IHNldHVwIElCUyBMVlQgb2Zmc2V0LCBJQlNDVEwgPSAweGZmZmZmZmZmDQooWEVOKSBbMjAx
Mi0wOS0wNiAyMjoxNDozM10gKioqIExPQURJTkcgRE9NQUlOIDAgKioqDQooWEVOKSBbMjAx
Mi0wOS0wNiAyMjoxNDozM10gZWxmX3BhcnNlX2JpbmFyeTogcGhkcjogcGFkZHI9MHgxMDAw
MDAwIG1lbXN6PTB4ZDZhMDAwDQooWEVOKSBbMjAxMi0wOS0wNiAyMjoxNDozM10gZWxmX3Bh
cnNlX2JpbmFyeTogcGhkcjogcGFkZHI9MHgxZTAwMDAwIG1lbXN6PTB4ZGIwZTgNCihYRU4p
IFsyMDEyLTA5LTA2IDIyOjE0OjMzXSBlbGZfcGFyc2VfYmluYXJ5OiBwaGRyOiBwYWRkcj0w
eDFlZGMwMDAgbWVtc3o9MHgxM2MwMA0KKFhFTikgWzIwMTItMDktMDYgMjI6MTQ6MzNdIGVs
Zl9wYXJzZV9iaW5hcnk6IHBoZHI6IHBhZGRyPTB4MWVmMDAwMCBtZW1zej0weGRlNTAwMA0K
KFhFTikgWzIwMTItMDktMDYgMjI6MTQ6MzNdIGVsZl9wYXJzZV9iaW5hcnk6IG1lbW9yeTog
MHgxMDAwMDAwIC0+IDB4MmNkNTAwMA0KKFhFTikgWzIwMTItMDktMDYgMjI6MTQ6MzNdIGVs
Zl94ZW5fcGFyc2Vfbm90ZTogR1VFU1RfT1MgPSAibGludXgiDQooWEVOKSBbMjAxMi0wOS0w
NiAyMjoxNDozM10gZWxmX3hlbl9wYXJzZV9ub3RlOiBHVUVTVF9WRVJTSU9OID0gIjIuNiIN
CihYRU4pIFsyMDEyLTA5LTA2IDIyOjE0OjMzXSBlbGZfeGVuX3BhcnNlX25vdGU6IFhFTl9W
RVJTSU9OID0gInhlbi0zLjAiDQooWEVOKSBbMjAxMi0wOS0wNiAyMjoxNDozM10gZWxmX3hl
bl9wYXJzZV9ub3RlOiBWSVJUX0JBU0UgPSAweGZmZmZmZmZmODAwMDAwMDANCihYRU4pIFsy
MDEyLTA5LTA2IDIyOjE0OjMzXSBlbGZfeGVuX3BhcnNlX25vdGU6IEVOVFJZID0gMHhmZmZm
ZmZmZjgxZWYwMjEwDQooWEVOKSBbMjAxMi0wOS0wNiAyMjoxNDozM10gZWxmX3hlbl9wYXJz
ZV9ub3RlOiBIWVBFUkNBTExfUEFHRSA9IDB4ZmZmZmZmZmY4MTAwMTAwMA0KKFhFTikgWzIw
MTItMDktMDYgMjI6MTQ6MzNdIGVsZl94ZW5fcGFyc2Vfbm90ZTogRkVBVFVSRVMgPSAiIXdy
aXRhYmxlX3BhZ2VfdGFibGVzfHBhZV9wZ2Rpcl9hYm92ZV80Z2IiDQooWEVOKSBbMjAxMi0w
OS0wNiAyMjoxNDozM10gZWxmX3hlbl9wYXJzZV9ub3RlOiBQQUVfTU9ERSA9ICJ5ZXMiDQoo
WEVOKSBbMjAxMi0wOS0wNiAyMjoxNDozM10gZWxmX3hlbl9wYXJzZV9ub3RlOiBMT0FERVIg
PSAiZ2VuZXJpYyINCihYRU4pIFsyMDEyLTA5LTA2IDIyOjE0OjMzXSBlbGZfeGVuX3BhcnNl
X25vdGU6IHVua25vd24geGVuIGVsZiBub3RlICgweGQpDQooWEVOKSBbMjAxMi0wOS0wNiAy
MjoxNDozM10gZWxmX3hlbl9wYXJzZV9ub3RlOiBTVVNQRU5EX0NBTkNFTCA9IDB4MQ0KKFhF
TikgWzIwMTItMDktMDYgMjI6MTQ6MzNdIGVsZl94ZW5fcGFyc2Vfbm90ZTogSFZfU1RBUlRf
TE9XID0gMHhmZmZmODAwMDAwMDAwMDAwDQooWEVOKSBbMjAxMi0wOS0wNiAyMjoxNDozM10g
ZWxmX3hlbl9wYXJzZV9ub3RlOiBQQUREUl9PRkZTRVQgPSAweDANCihYRU4pIFsyMDEyLTA5
LTA2IDIyOjE0OjMzXSBlbGZfeGVuX2FkZHJfY2FsY19jaGVjazogYWRkcmVzc2VzOg0KKFhF
TikgWzIwMTItMDktMDYgMjI6MTQ6MzNdICAgICB2aXJ0X2Jhc2UgICAgICAgID0gMHhmZmZm
ZmZmZjgwMDAwMDAwDQooWEVOKSBbMjAxMi0wOS0wNiAyMjoxNDozM10gICAgIGVsZl9wYWRk
cl9vZmZzZXQgPSAweDANCihYRU4pIFsyMDEyLTA5LTA2IDIyOjE0OjMzXSAgICAgdmlydF9v
ZmZzZXQgICAgICA9IDB4ZmZmZmZmZmY4MDAwMDAwMA0KKFhFTikgWzIwMTItMDktMDYgMjI6
MTQ6MzNdICAgICB2aXJ0X2tzdGFydCAgICAgID0gMHhmZmZmZmZmZjgxMDAwMDAwDQooWEVO
KSBbMjAxMi0wOS0wNiAyMjoxNDozM10gICAgIHZpcnRfa2VuZCAgICAgICAgPSAweGZmZmZm
ZmZmODJjZDUwMDANCihYRU4pIFsyMDEyLTA5LTA2IDIyOjE0OjMzXSAgICAgdmlydF9lbnRy
eSAgICAgICA9IDB4ZmZmZmZmZmY4MWVmMDIxMA0KKFhFTikgWzIwMTItMDktMDYgMjI6MTQ6
MzNdICAgICBwMm1fYmFzZSAgICAgICAgID0gMHhmZmZmZmZmZmZmZmZmZmZmDQooWEVOKSBb
MjAxMi0wOS0wNiAyMjoxNDozM10gIFhlbiAga2VybmVsOiA2NC1iaXQsIGxzYiwgY29tcGF0
MzINCihYRU4pIFsyMDEyLTA5LTA2IDIyOjE0OjMzXSAgRG9tMCBrZXJuZWw6IDY0LWJpdCwg
UEFFLCBsc2IsIHBhZGRyIDB4MTAwMDAwMCAtPiAweDJjZDUwMDANCihYRU4pIFsyMDEyLTA5
LTA2IDIyOjE0OjMzXSBQSFlTSUNBTCBNRU1PUlkgQVJSQU5HRU1FTlQ6DQooWEVOKSBbMjAx
Mi0wOS0wNiAyMjoxNDozM10gIERvbTAgYWxsb2MuOiAgIDAwMDAwMDAyNDAwMDAwMDAtPjAw
MDAwMDAyNDQwMDAwMDAgKDI0MjQyOCBwYWdlcyB0byBiZSBhbGxvY2F0ZWQpDQooWEVOKSBb
MjAxMi0wOS0wNiAyMjoxNDozM10gIEluaXQuIHJhbWRpc2s6IDAwMDAwMDAyNGYyZmMwMDAt
PjAwMDAwMDAyNGZmZmY4MDANCihYRU4pIFsyMDEyLTA5LTA2IDIyOjE0OjMzXSBWSVJUVUFM
IE1FTU9SWSBBUlJBTkdFTUVOVDoNCihYRU4pIFsyMDEyLTA5LTA2IDIyOjE0OjMzXSAgTG9h
ZGVkIGtlcm5lbDogZmZmZmZmZmY4MTAwMDAwMC0+ZmZmZmZmZmY4MmNkNTAwMA0KKFhFTikg
WzIwMTItMDktMDYgMjI6MTQ6MzNdICBJbml0LiByYW1kaXNrOiBmZmZmZmZmZjgyY2Q1MDAw
LT5mZmZmZmZmZjgzOWQ4ODAwDQooWEVOKSBbMjAxMi0wOS0wNiAyMjoxNDozM10gIFBoeXMt
TWFjaCBtYXA6IGZmZmZmZmZmODM5ZDkwMDAtPmZmZmZmZmZmODNiZDkwMDANCihYRU4pIFsy
MDEyLTA5LTA2IDIyOjE0OjMzXSAgU3RhcnQgaW5mbzogICAgZmZmZmZmZmY4M2JkOTAwMC0+
ZmZmZmZmZmY4M2JkOTRiNA0KKFhFTikgWzIwMTItMDktMDYgMjI6MTQ6MzNdICBQYWdlIHRh
YmxlczogICBmZmZmZmZmZjgzYmRhMDAwLT5mZmZmZmZmZjgzYmZkMDAwDQooWEVOKSBbMjAx
Mi0wOS0wNiAyMjoxNDozM10gIEJvb3Qgc3RhY2s6ICAgIGZmZmZmZmZmODNiZmQwMDAtPmZm
ZmZmZmZmODNiZmUwMDANCihYRU4pIFsyMDEyLTA5LTA2IDIyOjE0OjMzXSAgVE9UQUw6ICAg
ICAgICAgZmZmZmZmZmY4MDAwMDAwMC0+ZmZmZmZmZmY4NDAwMDAwMA0KKFhFTikgWzIwMTIt
MDktMDYgMjI6MTQ6MzNdICBFTlRSWSBBRERSRVNTOiBmZmZmZmZmZjgxZWYwMjEwDQooWEVO
KSBbMjAxMi0wOS0wNiAyMjoxNDozM10gRG9tMCBoYXMgbWF4aW11bSA2IFZDUFVzDQooWEVO
KSBbMjAxMi0wOS0wNiAyMjoxNDozM10gZWxmX2xvYWRfYmluYXJ5OiBwaGRyIDAgYXQgMHhm
ZmZmZmZmZjgxMDAwMDAwIC0+IDB4ZmZmZmZmZmY4MWQ2YTAwMA0KKFhFTikgWzIwMTItMDkt
MDYgMjI6MTQ6MzRdIGVsZl9sb2FkX2JpbmFyeTogcGhkciAxIGF0IDB4ZmZmZmZmZmY4MWUw
MDAwMCAtPiAweGZmZmZmZmZmODFlZGIwZTgNCihYRU4pIFsyMDEyLTA5LTA2IDIyOjE0OjM0
XSBlbGZfbG9hZF9iaW5hcnk6IHBoZHIgMiBhdCAweGZmZmZmZmZmODFlZGMwMDAgLT4gMHhm
ZmZmZmZmZjgxZWVmYzAwDQooWEVOKSBbMjAxMi0wOS0wNiAyMjoxNDozNF0gZWxmX2xvYWRf
YmluYXJ5OiBwaGRyIDMgYXQgMHhmZmZmZmZmZjgxZWYwMDAwIC0+IDB4ZmZmZmZmZmY4MWY4
OTAwMA0KKFhFTikgWzIwMTItMDktMDYgMjI6MTQ6MzRdIEFNRC1WaTogU2V0dXAgSS9PIHBh
Z2UgdGFibGU6IGRldmljZSBpZCA9IDB4MDAwMCwgcm9vdCB0YWJsZSA9IDB4MjRkODIzMDAw
LCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMNCihYRU4pIFsyMDEyLTA5LTA2IDIyOjE0
OjM0XSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweDAwMDIs
IHJvb3QgdGFibGUgPSAweDI0ZDgyMzAwMCwgZG9tYWluID0gMCwgcGFnaW5nIG1vZGUgPSAz
DQooWEVOKSBbMjAxMi0wOS0wNiAyMjoxNDozNF0gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0
YWJsZTogZGV2aWNlIGlkID0gMHgwMDEwLCByb290IHRhYmxlID0gMHgyNGQ4MjMwMDAsIGRv
bWFpbiA9IDAsIHBhZ2luZyBtb2RlID0gMw0KKFhFTikgWzIwMTItMDktMDYgMjI6MTQ6MzRd
IEFNRC1WaTogU2V0dXAgSS9PIHBhZ2UgdGFibGU6IGRldmljZSBpZCA9IDB4MDAxOCwgcm9v
dCB0YWJsZSA9IDB4MjRkODIzMDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMNCihY
RU4pIFsyMDEyLTA5LTA2IDIyOjE0OjM0XSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxl
OiBkZXZpY2UgaWQgPSAweDAwMjgsIHJvb3QgdGFibGUgPSAweDI0ZDgyMzAwMCwgZG9tYWlu
ID0gMCwgcGFnaW5nIG1vZGUgPSAzDQooWEVOKSBbMjAxMi0wOS0wNiAyMjoxNDozNF0gQU1E
LVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHgwMDMwLCByb290IHRh
YmxlID0gMHgyNGQ4MjMwMDAsIGRvbWFpbiA9IDAsIHBhZ2luZyBtb2RlID0gMw0KKFhFTikg
WzIwMTItMDktMDYgMjI6MTQ6MzRdIEFNRC1WaTogU2V0dXAgSS9PIHBhZ2UgdGFibGU6IGRl
dmljZSBpZCA9IDB4MDA1MCwgcm9vdCB0YWJsZSA9IDB4MjRkODIzMDAwLCBkb21haW4gPSAw
LCBwYWdpbmcgbW9kZSA9IDMNCihYRU4pIFsyMDEyLTA5LTA2IDIyOjE0OjM0XSBBTUQtVmk6
IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweDAwNTgsIHJvb3QgdGFibGUg
PSAweDI0ZDgyMzAwMCwgZG9tYWluID0gMCwgcGFnaW5nIG1vZGUgPSAzDQooWEVOKSBbMjAx
Mi0wOS0wNiAyMjoxNDozNF0gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNl
IGlkID0gMHgwMDYwLCByb290IHRhYmxlID0gMHgyNGQ4MjMwMDAsIGRvbWFpbiA9IDAsIHBh
Z2luZyBtb2RlID0gMw0KKFhFTikgWzIwMTItMDktMDYgMjI6MTQ6MzRdIEFNRC1WaTogU2V0
dXAgSS9PIHBhZ2UgdGFibGU6IGRldmljZSBpZCA9IDB4MDA2OCwgcm9vdCB0YWJsZSA9IDB4
MjRkODIzMDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMNCihYRU4pIFsyMDEyLTA5
LTA2IDIyOjE0OjM0XSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQg
PSAweDAwODgsIHJvb3QgdGFibGUgPSAweDI0ZDgyMzAwMCwgZG9tYWluID0gMCwgcGFnaW5n
IG1vZGUgPSAzDQooWEVOKSBbMjAxMi0wOS0wNiAyMjoxNDozNF0gQU1ELVZpOiBTZXR1cCBJ
L08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHgwMDkwLCByb290IHRhYmxlID0gMHgyNGQ4
MjMwMDAsIGRvbWFpbiA9IDAsIHBhZ2luZyBtb2RlID0gMw0KKFhFTikgWzIwMTItMDktMDYg
MjI6MTQ6MzRdIEFNRC1WaTogU2V0dXAgSS9PIHBhZ2UgdGFibGU6IGRldmljZSBpZCA9IDB4
MDA5Miwgcm9vdCB0YWJsZSA9IDB4MjRkODIzMDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9k
ZSA9IDMNCihYRU4pIFsyMDEyLTA5LTA2IDIyOjE0OjM0XSBBTUQtVmk6IFNldHVwIEkvTyBw
YWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweDAwOTgsIHJvb3QgdGFibGUgPSAweDI0ZDgyMzAw
MCwgZG9tYWluID0gMCwgcGFnaW5nIG1vZGUgPSAzDQooWEVOKSBbMjAxMi0wOS0wNiAyMjox
NDozNF0gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHgwMDlh
LCByb290IHRhYmxlID0gMHgyNGQ4MjMwMDAsIGRvbWFpbiA9IDAsIHBhZ2luZyBtb2RlID0g
Mw0KKFhFTikgWzIwMTItMDktMDYgMjI6MTQ6MzRdIEFNRC1WaTogU2V0dXAgSS9PIHBhZ2Ug
dGFibGU6IGRldmljZSBpZCA9IDB4MDBhMCwgcm9vdCB0YWJsZSA9IDB4MjRkODIzMDAwLCBk
b21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMNCihYRU4pIFsyMDEyLTA5LTA2IDIyOjE0OjM0
XSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweDAwYTMsIHJv
b3QgdGFibGUgPSAweDI0ZDgyMzAwMCwgZG9tYWluID0gMCwgcGFnaW5nIG1vZGUgPSAzDQoo
WEVOKSBbMjAxMi0wOS0wNiAyMjoxNDozNF0gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJs
ZTogZGV2aWNlIGlkID0gMHgwMGE0LCByb290IHRhYmxlID0gMHgyNGQ4MjMwMDAsIGRvbWFp
biA9IDAsIHBhZ2luZyBtb2RlID0gMw0KKFhFTikgWzIwMTItMDktMDYgMjI6MTQ6MzRdIEFN
RC1WaTogU2V0dXAgSS9PIHBhZ2UgdGFibGU6IGRldmljZSBpZCA9IDB4MDBhNSwgcm9vdCB0
YWJsZSA9IDB4MjRkODIzMDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMNCihYRU4p
IFsyMDEyLTA5LTA2IDIyOjE0OjM0XSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBk
ZXZpY2UgaWQgPSAweDAwYTgsIHJvb3QgdGFibGUgPSAweDI0ZDgyMzAwMCwgZG9tYWluID0g
MCwgcGFnaW5nIG1vZGUgPSAzDQooWEVOKSBbMjAxMi0wOS0wNiAyMjoxNDozNF0gQU1ELVZp
OiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHgwMGIwLCByb290IHRhYmxl
ID0gMHgyNGQ4MjMwMDAsIGRvbWFpbiA9IDAsIHBhZ2luZyBtb2RlID0gMw0KKFhFTikgWzIw
MTItMDktMDYgMjI6MTQ6MzRdIEFNRC1WaTogU2V0dXAgSS9PIHBhZ2UgdGFibGU6IGRldmlj
ZSBpZCA9IDB4MDBiMiwgcm9vdCB0YWJsZSA9IDB4MjRkODIzMDAwLCBkb21haW4gPSAwLCBw
YWdpbmcgbW9kZSA9IDMNCihYRU4pIFsyMDEyLTA5LTA2IDIyOjE0OjM0XSBBTUQtVmk6IE5v
IGlvbW11IGZvciBkZXZpY2UgMDA6MTguMA0KKFhFTikgWzIwMTItMDktMDYgMjI6MTQ6MzRd
IEFNRC1WaTogTm8gaW9tbXUgZm9yIGRldmljZSAwMDoxOC4xDQooWEVOKSBbMjAxMi0wOS0w
NiAyMjoxNDozNF0gQU1ELVZpOiBObyBpb21tdSBmb3IgZGV2aWNlIDAwOjE4LjINCihYRU4p
IFsyMDEyLTA5LTA2IDIyOjE0OjM0XSBBTUQtVmk6IE5vIGlvbW11IGZvciBkZXZpY2UgMDA6
MTguMw0KKFhFTikgWzIwMTItMDktMDYgMjI6MTQ6MzRdIEFNRC1WaTogTm8gaW9tbXUgZm9y
IGRldmljZSAwMDoxOC40DQooWEVOKSBbMjAxMi0wOS0wNiAyMjoxNDozNF0gQU1ELVZpOiBT
ZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHgwNDAwLCByb290IHRhYmxlID0g
MHgyNGQ4MjMwMDAsIGRvbWFpbiA9IDAsIHBhZ2luZyBtb2RlID0gMw0KKFhFTikgWzIwMTIt
MDktMDYgMjI6MTQ6MzRdIEFNRC1WaTogU2V0dXAgSS9PIHBhZ2UgdGFibGU6IGRldmljZSBp
ZCA9IDB4MDQwMSwgcm9vdCB0YWJsZSA9IDB4MjRkODIzMDAwLCBkb21haW4gPSAwLCBwYWdp
bmcgbW9kZSA9IDMNCihYRU4pIFsyMDEyLTA5LTA2IDIyOjE0OjM0XSBBTUQtVmk6IFNldHVw
IEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweDA0MDIsIHJvb3QgdGFibGUgPSAweDI0
ZDgyMzAwMCwgZG9tYWluID0gMCwgcGFnaW5nIG1vZGUgPSAzDQooWEVOKSBbMjAxMi0wOS0w
NiAyMjoxNDozNF0gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0g
MHgwNDAzLCByb290IHRhYmxlID0gMHgyNGQ4MjMwMDAsIGRvbWFpbiA9IDAsIHBhZ2luZyBt
b2RlID0gMw0KKFhFTikgWzIwMTItMDktMDYgMjI6MTQ6MzRdIEFNRC1WaTogU2V0dXAgSS9P
IHBhZ2UgdGFibGU6IGRldmljZSBpZCA9IDB4MDQwNCwgcm9vdCB0YWJsZSA9IDB4MjRkODIz
MDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMNCihYRU4pIFsyMDEyLTA5LTA2IDIy
OjE0OjM0XSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweDA0
MDUsIHJvb3QgdGFibGUgPSAweDI0ZDgyMzAwMCwgZG9tYWluID0gMCwgcGFnaW5nIG1vZGUg
PSAzDQooWEVOKSBbMjAxMi0wOS0wNiAyMjoxNDozNF0gQU1ELVZpOiBTZXR1cCBJL08gcGFn
ZSB0YWJsZTogZGV2aWNlIGlkID0gMHgwNDA2LCByb290IHRhYmxlID0gMHgyNGQ4MjMwMDAs
IGRvbWFpbiA9IDAsIHBhZ2luZyBtb2RlID0gMw0KKFhFTikgWzIwMTItMDktMDYgMjI6MTQ6
MzRdIEFNRC1WaTogU2V0dXAgSS9PIHBhZ2UgdGFibGU6IGRldmljZSBpZCA9IDB4MDQwNywg
cm9vdCB0YWJsZSA9IDB4MjRkODIzMDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMN
CihYRU4pIFsyMDEyLTA5LTA2IDIyOjE0OjM0XSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRh
YmxlOiBkZXZpY2UgaWQgPSAweDA1MDAsIHJvb3QgdGFibGUgPSAweDI0ZDgyMzAwMCwgZG9t
YWluID0gMCwgcGFnaW5nIG1vZGUgPSAzDQooWEVOKSBbMjAxMi0wOS0wNiAyMjoxNDozNF0g
QU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHgwNjAwLCByb290
IHRhYmxlID0gMHgyNGQ4MjMwMDAsIGRvbWFpbiA9IDAsIHBhZ2luZyBtb2RlID0gMw0KKFhF
TikgWzIwMTItMDktMDYgMjI6MTQ6MzRdIEFNRC1WaTogU2V0dXAgSS9PIHBhZ2UgdGFibGU6
IGRldmljZSBpZCA9IDB4MDYwMSwgcm9vdCB0YWJsZSA9IDB4MjRkODIzMDAwLCBkb21haW4g
PSAwLCBwYWdpbmcgbW9kZSA9IDMNCihYRU4pIFsyMDEyLTA5LTA2IDIyOjE0OjM0XSBBTUQt
Vmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweDA3MDAsIHJvb3QgdGFi
bGUgPSAweDI0ZDgyMzAwMCwgZG9tYWluID0gMCwgcGFnaW5nIG1vZGUgPSAzDQooWEVOKSBb
MjAxMi0wOS0wNiAyMjoxNDozNF0gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2
aWNlIGlkID0gMHgwODAwLCByb290IHRhYmxlID0gMHgyNGQ4MjMwMDAsIGRvbWFpbiA9IDAs
IHBhZ2luZyBtb2RlID0gMw0KKFhFTikgWzIwMTItMDktMDYgMjI6MTQ6MzRdIEFNRC1WaTog
U2V0dXAgSS9PIHBhZ2UgdGFibGU6IGRldmljZSBpZCA9IDB4MDkwMCwgcm9vdCB0YWJsZSA9
IDB4MjRkODIzMDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMNCihYRU4pIFsyMDEy
LTA5LTA2IDIyOjE0OjM0XSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2Ug
aWQgPSAweDBhMDAsIHJvb3QgdGFibGUgPSAweDI0ZDgyMzAwMCwgZG9tYWluID0gMCwgcGFn
aW5nIG1vZGUgPSAzDQooWEVOKSBbMjAxMi0wOS0wNiAyMjoxNDozNF0gQU1ELVZpOiBTZXR1
cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHgwYTAxLCByb290IHRhYmxlID0gMHgy
NGQ4MjMwMDAsIGRvbWFpbiA9IDAsIHBhZ2luZyBtb2RlID0gMw0KKFhFTikgWzIwMTItMDkt
MDYgMjI6MTQ6MzRdIEFNRC1WaTogU2V0dXAgSS9PIHBhZ2UgdGFibGU6IGRldmljZSBpZCA9
IDB4MGEwMiwgcm9vdCB0YWJsZSA9IDB4MjRkODIzMDAwLCBkb21haW4gPSAwLCBwYWdpbmcg
bW9kZSA9IDMNCihYRU4pIFsyMDEyLTA5LTA2IDIyOjE0OjM0XSBBTUQtVmk6IFNldHVwIEkv
TyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweDBhMDMsIHJvb3QgdGFibGUgPSAweDI0ZDgy
MzAwMCwgZG9tYWluID0gMCwgcGFnaW5nIG1vZGUgPSAzDQooWEVOKSBbMjAxMi0wOS0wNiAy
MjoxNDozNF0gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHgw
YTA0LCByb290IHRhYmxlID0gMHgyNGQ4MjMwMDAsIGRvbWFpbiA9IDAsIHBhZ2luZyBtb2Rl
ID0gMw0KKFhFTikgWzIwMTItMDktMDYgMjI6MTQ6MzRdIEFNRC1WaTogU2V0dXAgSS9PIHBh
Z2UgdGFibGU6IGRldmljZSBpZCA9IDB4MGEwNSwgcm9vdCB0YWJsZSA9IDB4MjRkODIzMDAw
LCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMNCihYRU4pIFsyMDEyLTA5LTA2IDIyOjE0
OjM0XSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweDBhMDYs
IHJvb3QgdGFibGUgPSAweDI0ZDgyMzAwMCwgZG9tYWluID0gMCwgcGFnaW5nIG1vZGUgPSAz
DQooWEVOKSBbMjAxMi0wOS0wNiAyMjoxNDozNF0gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0
YWJsZTogZGV2aWNlIGlkID0gMHgwYTA3LCByb290IHRhYmxlID0gMHgyNGQ4MjMwMDAsIGRv
bWFpbiA9IDAsIHBhZ2luZyBtb2RlID0gMw0KKFhFTikgWzIwMTItMDktMDYgMjI6MTQ6MzRd
IEFNRC1WaTogU2V0dXAgSS9PIHBhZ2UgdGFibGU6IGRldmljZSBpZCA9IDB4MGIwMCwgcm9v
dCB0YWJsZSA9IDB4MjRkODIzMDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMNCihY
RU4pIFsyMDEyLTA5LTA2IDIyOjE0OjM0XSBTY3J1YmJpbmcgRnJlZSBSQU06IC4uLi4uLi4u
Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u
Li4uLi4uLi4uZG9uZS4NCihYRU4pIFsyMDEyLTA5LTA2IDIyOjE0OjM2XSBYZW4gdHJhY2Ug
YnVmZmVyczogZGlzYWJsZWQNCihYRU4pIFsyMDEyLTA5LTA2IDIyOjE0OjM2XSBTdGQuIExv
Z2xldmVsOiBBbGwNCihYRU4pIFsyMDEyLTA5LTA2IDIyOjE0OjM2XSBHdWVzdCBMb2dsZXZl
bDogQWxsDQooWEVOKSBbMjAxMi0wOS0wNiAyMjoxNDozNl0gWGVuIGlzIHJlbGlucXVpc2hp
bmcgVkdBIGNvbnNvbGUuDQooWEVOKSBbMjAxMi0wOS0wNiAyMjoxNDozNl0gKioqIFNlcmlh
bCBpbnB1dCAtPiBET00wICh0eXBlIFwwNDdDVFJMLWFcMDQ3IHRocmVlIHRpbWVzIHRvIHN3
aXRjaCBpbnB1dCB0byBYZW4pDQooWEVOKSBbMjAxMi0wOS0wNiAyMjoxNDozNl0gRnJlZWQg
MTk2a0IgaW5pdCBtZW1vcnkuDQooWEVOKSBbMjAxMi0wOS0wNiAyMjoxNDozNl0gSU9BUElD
WzBdOiBTZXQgUENJIHJvdXRpbmcgZW50cnkgKDYtOSAtPiAweDYwIC0+IElSUSA5IE1vZGU6
MSBBY3RpdmU6MSkNCihYRU4pIFsyMDEyLTA5LTA2IDIyOjE0OjM2XSB0cmFwcy5jOjI0ODk6
ZDAgRG9tYWluIGF0dGVtcHRlZCBXUk1TUiAwMDAwMDAwMGMwMDEwMDA0IGZyb20gMHgwMDAw
ZWZmMGJkZmIxZmI4IHRvIDB4MDAwMDAwMDAwMDAwYWJjZC4NCihYRU4pIFsyMDEyLTA5LTA2
IDIyOjE0OjM3XSBQQ0kgYWRkIGRldmljZSAwMDowMC4wDQooWEVOKSBbMjAxMi0wOS0wNiAy
MjoxNDozN10gUENJIGFkZCBkZXZpY2UgMDA6MDAuMg0KKFhFTikgWzIwMTItMDktMDYgMjI6
MTQ6MzddIFBDSSBhZGQgZGV2aWNlIDAwOjAyLjANCihYRU4pIFsyMDEyLTA5LTA2IDIyOjE0
OjM3XSBQQ0kgYWRkIGRldmljZSAwMDowMy4wDQooWEVOKSBbMjAxMi0wOS0wNiAyMjoxNDoz
N10gUENJIGFkZCBkZXZpY2UgMDA6MDUuMA0KKFhFTikgWzIwMTItMDktMDYgMjI6MTQ6Mzdd
IFBDSSBhZGQgZGV2aWNlIDAwOjA2LjANCihYRU4pIFsyMDEyLTA5LTA2IDIyOjE0OjM3XSBQ
Q0kgYWRkIGRldmljZSAwMDowYS4wDQooWEVOKSBbMjAxMi0wOS0wNiAyMjoxNDozN10gUENJ
IGFkZCBkZXZpY2UgMDA6MGIuMA0KKFhFTikgWzIwMTItMDktMDYgMjI6MTQ6MzddIFBDSSBh
ZGQgZGV2aWNlIDAwOjBjLjANCihYRU4pIFsyMDEyLTA5LTA2IDIyOjE0OjM3XSBQQ0kgYWRk
IGRldmljZSAwMDowZC4wDQooWEVOKSBbMjAxMi0wOS0wNiAyMjoxNDozN10gUENJIGFkZCBk
ZXZpY2UgMDA6MTEuMA0KKFhFTikgWzIwMTItMDktMDYgMjI6MTQ6MzddIFBDSSBhZGQgZGV2
aWNlIDAwOjEyLjANCihYRU4pIFsyMDEyLTA5LTA2IDIyOjE0OjM3XSBQQ0kgYWRkIGRldmlj
ZSAwMDoxMi4yDQooWEVOKSBbMjAxMi0wOS0wNiAyMjoxNDozN10gUENJIGFkZCBkZXZpY2Ug
MDA6MTMuMA0KKFhFTikgWzIwMTItMDktMDYgMjI6MTQ6MzddIFBDSSBhZGQgZGV2aWNlIDAw
OjEzLjINCihYRU4pIFsyMDEyLTA5LTA2IDIyOjE0OjM3XSBQQ0kgYWRkIGRldmljZSAwMDox
NC4wDQooWEVOKSBbMjAxMi0wOS0wNiAyMjoxNDozN10gUENJIGFkZCBkZXZpY2UgMDA6MTQu
Mw0KKFhFTikgWzIwMTItMDktMDYgMjI6MTQ6MzddIFBDSSBhZGQgZGV2aWNlIDAwOjE0LjQN
CihYRU4pIFsyMDEyLTA5LTA2IDIyOjE0OjM3XSBQQ0kgYWRkIGRldmljZSAwMDoxNC41DQoo
WEVOKSBbMjAxMi0wOS0wNiAyMjoxNDozN10gUENJIGFkZCBkZXZpY2UgMDA6MTUuMA0KKFhF
TikgWzIwMTItMDktMDYgMjI6MTQ6MzddIFBDSSBhZGQgZGV2aWNlIDAwOjE2LjANCihYRU4p
IFsyMDEyLTA5LTA2IDIyOjE0OjM3XSBQQ0kgYWRkIGRldmljZSAwMDoxNi4yDQooWEVOKSBb
MjAxMi0wOS0wNiAyMjoxNDozN10gUENJIGFkZCBkZXZpY2UgMDA6MTguMA0KKFhFTikgWzIw
MTItMDktMDYgMjI6MTQ6MzddIFBDSSBhZGQgZGV2aWNlIDAwOjE4LjENCihYRU4pIFsyMDEy
LTA5LTA2IDIyOjE0OjM3XSBQQ0kgYWRkIGRldmljZSAwMDoxOC4yDQooWEVOKSBbMjAxMi0w
OS0wNiAyMjoxNDozN10gUENJIGFkZCBkZXZpY2UgMDA6MTguMw0KKFhFTikgWzIwMTItMDkt
MDYgMjI6MTQ6MzddIFBDSSBhZGQgZGV2aWNlIDAwOjE4LjQNCihYRU4pIFsyMDEyLTA5LTA2
IDIyOjE0OjM3XSBQQ0kgYWRkIGRldmljZSAwYjowMC4wDQooWEVOKSBbMjAxMi0wOS0wNiAy
MjoxNDozN10gUENJIGFkZCBkZXZpY2UgMGE6MDAuMA0KKFhFTikgWzIwMTItMDktMDYgMjI6
MTQ6MzddIFBDSSBhZGQgZGV2aWNlIDBhOjAwLjENCihYRU4pIFsyMDEyLTA5LTA2IDIyOjE0
OjM3XSBQQ0kgYWRkIGRldmljZSAwYTowMC4yDQooWEVOKSBbMjAxMi0wOS0wNiAyMjoxNDoz
N10gUENJIGFkZCBkZXZpY2UgMGE6MDAuMw0KKFhFTikgWzIwMTItMDktMDYgMjI6MTQ6Mzdd
IFBDSSBhZGQgZGV2aWNlIDBhOjAwLjQNCihYRU4pIFsyMDEyLTA5LTA2IDIyOjE0OjM3XSBQ
Q0kgYWRkIGRldmljZSAwYTowMC41DQooWEVOKSBbMjAxMi0wOS0wNiAyMjoxNDozN10gUENJ
IGFkZCBkZXZpY2UgMGE6MDAuNg0KKFhFTikgWzIwMTItMDktMDYgMjI6MTQ6MzddIFBDSSBh
ZGQgZGV2aWNlIDBhOjAwLjcNCihYRU4pIFsyMDEyLTA5LTA2IDIyOjE0OjM3XSBQQ0kgYWRk
IGRldmljZSAwOTowMC4wDQooWEVOKSBbMjAxMi0wOS0wNiAyMjoxNDozN10gUENJIGFkZCBk
ZXZpY2UgMDg6MDAuMA0KKFhFTikgWzIwMTItMDktMDYgMjI6MTQ6MzddIFBDSSBhZGQgZGV2
aWNlIDA3OjAwLjANCihYRU4pIFsyMDEyLTA5LTA2IDIyOjE0OjM3XSBQQ0kgYWRkIGRldmlj
ZSAwNjowMC4wDQooWEVOKSBbMjAxMi0wOS0wNiAyMjoxNDozN10gUENJIGFkZCBkZXZpY2Ug
MDY6MDAuMQ0KKFhFTikgWzIwMTItMDktMDYgMjI6MTQ6MzddIFBDSSBhZGQgZGV2aWNlIDA1
OjAwLjANCihYRU4pIFsyMDEyLTA5LTA2IDIyOjE0OjM3XSBQQ0kgYWRkIGRldmljZSAwNDow
MC4wDQooWEVOKSBbMjAxMi0wOS0wNiAyMjoxNDozN10gUENJIGFkZCBkZXZpY2UgMDQ6MDAu
MQ0KKFhFTikgWzIwMTItMDktMDYgMjI6MTQ6MzddIFBDSSBhZGQgZGV2aWNlIDA0OjAwLjIN
CihYRU4pIFsyMDEyLTA5LTA2IDIyOjE0OjM3XSBQQ0kgYWRkIGRldmljZSAwNDowMC4zDQoo
WEVOKSBbMjAxMi0wOS0wNiAyMjoxNDozN10gUENJIGFkZCBkZXZpY2UgMDQ6MDAuNA0KKFhF
TikgWzIwMTItMDktMDYgMjI6MTQ6MzddIFBDSSBhZGQgZGV2aWNlIDA0OjAwLjUNCihYRU4p
IFsyMDEyLTA5LTA2IDIyOjE0OjM3XSBQQ0kgYWRkIGRldmljZSAwNDowMC42DQooWEVOKSBb
MjAxMi0wOS0wNiAyMjoxNDozN10gUENJIGFkZCBkZXZpY2UgMDQ6MDAuNw0KKFhFTikgWzIw
MTItMDktMDYgMjI6MTQ6MzddIFBDSSBhZGQgZGV2aWNlIDAzOjA2LjANCihYRU4pIFsyMDEy
LTA5LTA2IDIyOjE0OjM3XSBJT0FQSUNbMF06IFNldCBQQ0kgcm91dGluZyBlbnRyeSAoNi04
IC0+IDB4NTggLT4gSVJRIDggTW9kZTowIEFjdGl2ZTowKQ0KKFhFTikgWzIwMTItMDktMDYg
MjI6MTQ6MzddIElPQVBJQ1swXTogU2V0IFBDSSByb3V0aW5nIGVudHJ5ICg2LTEzIC0+IDB4
ODggLT4gSVJRIDEzIE1vZGU6MCBBY3RpdmU6MCkNCihYRU4pIFsyMDEyLTA5LTA2IDIyOjE0
OjM3XSBJT0FQSUNbMV06IFNldCBQQ0kgcm91dGluZyBlbnRyeSAoNy0yOCAtPiAweGEwIC0+
IElSUSA1MiBNb2RlOjEgQWN0aXZlOjEpDQooWEVOKSBbMjAxMi0wOS0wNiAyMjoxNDozN10g
SU9BUElDWzFdOiBTZXQgUENJIHJvdXRpbmcgZW50cnkgKDctMjkgLT4gMHhhOCAtPiBJUlEg
NTMgTW9kZToxIEFjdGl2ZToxKQ0KKFhFTikgWzIwMTItMDktMDYgMjI6MTQ6MzddIElPQVBJ
Q1sxXTogU2V0IFBDSSByb3V0aW5nIGVudHJ5ICg3LTMwIC0+IDB4YjAgLT4gSVJRIDU0IE1v
ZGU6MSBBY3RpdmU6MSkNCihYRU4pIFsyMDEyLTA5LTA2IDIyOjE0OjM3XSBJT0FQSUNbMF06
IFNldCBQQ0kgcm91dGluZyBlbnRyeSAoNi0xNiAtPiAweGI4IC0+IElSUSAxNiBNb2RlOjEg
QWN0aXZlOjEpDQooWEVOKSBbMjAxMi0wOS0wNiAyMjoxNDozN10gSU9BUElDWzBdOiBTZXQg
UENJIHJvdXRpbmcgZW50cnkgKDYtMTggLT4gMHhjMCAtPiBJUlEgMTggTW9kZToxIEFjdGl2
ZToxKQ0KKFhFTikgWzIwMTItMDktMDYgMjI6MTQ6MzddIElPQVBJQ1swXTogU2V0IFBDSSBy
b3V0aW5nIGVudHJ5ICg2LTE3IC0+IDB4YzggLT4gSVJRIDE3IE1vZGU6MSBBY3RpdmU6MSkN
CihYRU4pIFsyMDEyLTA5LTA2IDIyOjE0OjM3XSBJT0FQSUNbMV06IFNldCBQQ0kgcm91dGlu
ZyBlbnRyeSAoNy00IC0+IDB4ZDAgLT4gSVJRIDI4IE1vZGU6MSBBY3RpdmU6MSkNCihYRU4p
IFsyMDEyLTA5LTA2IDIyOjE0OjM3XSBJT0FQSUNbMV06IFNldCBQQ0kgcm91dGluZyBlbnRy
eSAoNy01IC0+IDB4ZDggLT4gSVJRIDI5IE1vZGU6MSBBY3RpdmU6MSkNCihYRU4pIFsyMDEy
LTA5LTA2IDIyOjE0OjM3XSBJT0FQSUNbMV06IFNldCBQQ0kgcm91dGluZyBlbnRyeSAoNy02
IC0+IDB4MjEgLT4gSVJRIDMwIE1vZGU6MSBBY3RpdmU6MSkNCihYRU4pIFsyMDEyLTA5LTA2
IDIyOjE0OjM3XSBJT0FQSUNbMV06IFNldCBQQ0kgcm91dGluZyBlbnRyeSAoNy03IC0+IDB4
MjkgLT4gSVJRIDMxIE1vZGU6MSBBY3RpdmU6MSkNCihYRU4pIFsyMDEyLTA5LTA2IDIyOjE0
OjM3XSBJT0FQSUNbMV06IFNldCBQQ0kgcm91dGluZyBlbnRyeSAoNy0xNiAtPiAweDMxIC0+
IElSUSA0MCBNb2RlOjEgQWN0aXZlOjEpDQooWEVOKSBbMjAxMi0wOS0wNiAyMjoxNDozN10g
SU9BUElDWzFdOiBTZXQgUENJIHJvdXRpbmcgZW50cnkgKDctMTcgLT4gMHgzOSAtPiBJUlEg
NDEgTW9kZToxIEFjdGl2ZToxKQ0KKFhFTikgWzIwMTItMDktMDYgMjI6MTQ6MzddIElPQVBJ
Q1sxXTogU2V0IFBDSSByb3V0aW5nIGVudHJ5ICg3LTE4IC0+IDB4NDEgLT4gSVJRIDQyIE1v
ZGU6MSBBY3RpdmU6MSkNCihYRU4pIFsyMDEyLTA5LTA2IDIyOjE0OjM3XSBJT0FQSUNbMV06
IFNldCBQQ0kgcm91dGluZyBlbnRyeSAoNy0xOSAtPiAweDQ5IC0+IElSUSA0MyBNb2RlOjEg
QWN0aXZlOjEpDQooWEVOKSBbMjAxMi0wOS0wNiAyMjoxNDozN10gcGh5c2Rldi5jOjE3MTog
ZG9tMDogd3JvbmcgbWFwX3BpcnEgdHlwZSAzDQooWEVOKSBbMjAxMi0wOS0wNiAyMjoxNDoz
N10gSU9BUElDWzBdOiBTZXQgUENJIHJvdXRpbmcgZW50cnkgKDYtMjIgLT4gMHg5OSAtPiBJ
UlEgMjIgTW9kZToxIEFjdGl2ZToxKQ0KKFhFTikgWzIwMTItMDktMDYgMjI6MTQ6MzddIElP
QVBJQ1sxXTogU2V0IFBDSSByb3V0aW5nIGVudHJ5ICg3LTEyIC0+IDB4YTEgLT4gSVJRIDM2
IE1vZGU6MSBBY3RpdmU6MSkNCihYRU4pIFsyMDEyLTA5LTA2IDIyOjE0OjM3XSBJT0FQSUNb
MV06IFNldCBQQ0kgcm91dGluZyBlbnRyeSAoNy0yMyAtPiAweGE5IC0+IElSUSA0NyBNb2Rl
OjEgQWN0aXZlOjEpDQooWEVOKSBbMjAxMi0wOS0wNiAyMjoxNDozOF0gSU9BUElDWzBdOiBT
ZXQgUENJIHJvdXRpbmcgZW50cnkgKDYtMTkgLT4gMHhiMSAtPiBJUlEgMTkgTW9kZToxIEFj
dGl2ZToxKQ0KKFhFTikgWzIwMTItMDktMDYgMjI6MTQ6MzhdIElPQVBJQ1sxXTogU2V0IFBD
SSByb3V0aW5nIGVudHJ5ICg3LTIyIC0+IDB4YzEgLT4gSVJRIDQ2IE1vZGU6MSBBY3RpdmU6
MSkNCihYRU4pIFsyMDEyLTA5LTA2IDIyOjE0OjM4XSBJT0FQSUNbMV06IFNldCBQQ0kgcm91
dGluZyBlbnRyeSAoNy0yNyAtPiAweGQxIC0+IElSUSA1MSBNb2RlOjEgQWN0aXZlOjEpDQoo
WEVOKSBbMjAxMi0wOS0wNiAyMjoxNDo0MF0gSU9BUElDWzFdOiBTZXQgUENJIHJvdXRpbmcg
ZW50cnkgKDctOSAtPiAweDIyIC0+IElSUSAzMyBNb2RlOjEgQWN0aXZlOjEpDQooWEVOKSBb
MjAxMi0wOS0wNiAyMjoxNTo0NV0gdHJhcHMuYzoyNDg5OmQxIERvbWFpbiBhdHRlbXB0ZWQg
V1JNU1IgMDAwMDAwMDBjMDAxMDAwNCBmcm9tIDB4MDAwMGVkZjAzZGRlNzg0MCB0byAweDAw
MDAwMDAwMDAwMGFiY2QuDQooWEVOKSBbMjAxMi0wOS0wNiAyMjoxNTo1NF0gdHJhcHMuYzoy
NDg5OmQyIERvbWFpbiBhdHRlbXB0ZWQgV1JNU1IgMDAwMDAwMDBjMDAxMDAwNCBmcm9tIDB4
MDAwMDg0N2NjMDM5NDE0MyB0byAweDAwMDAwMDAwMDAwMGFiY2QuDQooWEVOKSBbMjAxMi0w
OS0wNiAyMjoxNjoxNF0gdHJhcHMuYzoyNDg5OmQzIERvbWFpbiBhdHRlbXB0ZWQgV1JNU1Ig
MDAwMDAwMDBjMDAxMDAwNCBmcm9tIDB4MDAwMDIxOTVjNDBmNjM4ZiB0byAweDAwMDAwMDAw
MDAwMGFiY2QuDQooWEVOKSBbMjAxMi0wOS0wNiAyMjoxNjoxNl0gdHJhcHMuYzoyNDg5OmQ0
IERvbWFpbiBhdHRlbXB0ZWQgV1JNU1IgMDAwMDAwMDBjMDAxMDAwNCBmcm9tIDB4MDAwMDg0
N2NjMDM5NDE0MyB0byAweDAwMDAwMDAwMDAwMGFiY2QuDQooWEVOKSBbMjAxMi0wOS0wNiAy
MjoxNjoyNl0gdHJhcHMuYzoyNDg5OmQ1IERvbWFpbiBhdHRlbXB0ZWQgV1JNU1IgMDAwMDAw
MDBjMDAxMDAwNCBmcm9tIDB4MDAwMDIxOTVjNDBmNjM4ZiB0byAweDAwMDAwMDAwMDAwMGFi
Y2QuDQooWEVOKSBbMjAxMi0wOS0wNiAyMjoxNjozNF0gdHJhcHMuYzoyNDg5OmQ2IERvbWFp
biBhdHRlbXB0ZWQgV1JNU1IgMDAwMDAwMDBjMDAxMDAwNCBmcm9tIDB4MDAwMDg0N2NjMDM5
NDE0MyB0byAweDAwMDAwMDAwMDAwMGFiY2QuDQooWEVOKSBbMjAxMi0wOS0wNiAyMjoxNjo1
Ml0gdHJhcHMuYzoyNDg5OmQ3IERvbWFpbiBhdHRlbXB0ZWQgV1JNU1IgMDAwMDAwMDBjMDAx
MDAwNCBmcm9tIDB4MDAwMDIxOTVjNDBmNjM4ZiB0byAweDAwMDAwMDAwMDAwMGFiY2QuDQoo
WEVOKSBbMjAxMi0wOS0wNiAyMjoxNzowOF0gdHJhcHMuYzoyNDg5OmQ4IERvbWFpbiBhdHRl
bXB0ZWQgV1JNU1IgMDAwMDAwMDBjMDAxMDAwNCBmcm9tIDB4MDAwMDQwYjQ1MzBkYTE2NSB0
byAweDAwMDAwMDAwMDAwMGFiY2QuDQooWEVOKSBbMjAxMi0wOS0wNiAyMjoxNzoxOV0gdHJh
cHMuYzoyNDg5OmQ5IERvbWFpbiBhdHRlbXB0ZWQgV1JNU1IgMDAwMDAwMDBjMDAxMDAwNCBm
cm9tIDB4MDAwMDg0N2NjMDM5NDE0MyB0byAweDAwMDAwMDAwMDAwMGFiY2QuDQooWEVOKSBb
MjAxMi0wOS0wNiAyMjoxNzozM10gdHJhcHMuYzoyNDg5OmQxMCBEb21haW4gYXR0ZW1wdGVk
IFdSTVNSIDAwMDAwMDAwYzAwMTAwMDQgZnJvbSAweDAwMDBlZGYwM2RkZTc4NDAgdG8gMHgw
MDAwMDAwMDAwMDBhYmNkLg0KKFhFTikgWzIwMTItMDktMDYgMjI6MTc6NDJdIEFNRC1WaTog
RGlzYWJsZTogZGV2aWNlIGlkID0gMHgwMGE0LCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9
IDMNCihYRU4pIFsyMDEyLTA5LTA2IDIyOjE3OjQyXSBBTUQtVmk6IFNldHVwIEkvTyBwYWdl
IHRhYmxlOiBkZXZpY2UgaWQgPSAweDAwYTQsIHJvb3QgdGFibGUgPSAweDE4Y2U0ZjAwMCwg
ZG9tYWluID0gMTEsIHBhZ2luZyBtb2RlID0gMw0KKFhFTikgWzIwMTItMDktMDYgMjI6MTc6
NDJdIEFNRC1WaTogUmUtYXNzaWduIDAzOjA2LjAgZnJvbSBkb21haW4gMCB0byBkb21haW4g
MTENCihYRU4pIFsyMDEyLTA5LTA2IDIyOjE3OjQ0XSB0cmFwcy5jOjI0ODk6ZDExIERvbWFp
biBhdHRlbXB0ZWQgV1JNU1IgMDAwMDAwMDBjMDAxMDAwNCBmcm9tIDB4MDAwMDIxOTVjNDBm
NjM4ZiB0byAweDAwMDAwMDAwMDAwMGFiY2QuDQooWEVOKSBbMjAxMi0wOS0wNiAyMjoxODoz
M10gdHJhcHMuYzoyNDg5OmQxMiBEb21haW4gYXR0ZW1wdGVkIFdSTVNSIDAwMDAwMDAwYzAw
MTAwMDQgZnJvbSAweDAwMDAyMTk1YzQwZjYzOGYgdG8gMHgwMDAwMDAwMDAwMDBhYmNkLg0K
KFhFTikgWzIwMTItMDktMDYgMjI6MTg6NDNdIHRyYXBzLmM6MjQ4OTpkMTMgRG9tYWluIGF0
dGVtcHRlZCBXUk1TUiAwMDAwMDAwMGMwMDEwMDA0IGZyb20gMHgwMDAwNDBiNDUzMGRhMTY1
IHRvIDB4MDAwMDAwMDAwMDAwYWJjZC4NCihYRU4pIFsyMDEyLTA5LTA2IDIyOjE5OjI5XSBB
TUQtVmk6IERpc2FibGU6IGRldmljZSBpZCA9IDB4MGEwMCwgZG9tYWluID0gMCwgcGFnaW5n
IG1vZGUgPSAzDQooWEVOKSBbMjAxMi0wOS0wNiAyMjoxOToyOV0gQU1ELVZpOiBTZXR1cCBJ
L08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHgwYTAwLCByb290IHRhYmxlID0gMHgxZTBk
ODMwMDAsIGRvbWFpbiA9IDE0LCBwYWdpbmcgbW9kZSA9IDMNCihYRU4pIFsyMDEyLTA5LTA2
IDIyOjE5OjI5XSBBTUQtVmk6IFJlLWFzc2lnbiAwYTowMC4wIGZyb20gZG9tYWluIDAgdG8g
ZG9tYWluIDE0DQooWEVOKSBbMjAxMi0wOS0wNiAyMjoxOToyOV0gQU1ELVZpOiBEaXNhYmxl
OiBkZXZpY2UgaWQgPSAweDBhMDEsIGRvbWFpbiA9IDAsIHBhZ2luZyBtb2RlID0gMw0KKFhF
TikgWzIwMTItMDktMDYgMjI6MTk6MjldIEFNRC1WaTogU2V0dXAgSS9PIHBhZ2UgdGFibGU6
IGRldmljZSBpZCA9IDB4MGEwMSwgcm9vdCB0YWJsZSA9IDB4MWUwZDgzMDAwLCBkb21haW4g
PSAxNCwgcGFnaW5nIG1vZGUgPSAzDQooWEVOKSBbMjAxMi0wOS0wNiAyMjoxOToyOV0gQU1E
LVZpOiBSZS1hc3NpZ24gMGE6MDAuMSBmcm9tIGRvbWFpbiAwIHRvIGRvbWFpbiAxNA0KKFhF
TikgWzIwMTItMDktMDYgMjI6MTk6MjldIEFNRC1WaTogRGlzYWJsZTogZGV2aWNlIGlkID0g
MHgwYTAyLCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMNCihYRU4pIFsyMDEyLTA5LTA2
IDIyOjE5OjI5XSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAw
eDBhMDIsIHJvb3QgdGFibGUgPSAweDFlMGQ4MzAwMCwgZG9tYWluID0gMTQsIHBhZ2luZyBt
b2RlID0gMw0KKFhFTikgWzIwMTItMDktMDYgMjI6MTk6MjldIEFNRC1WaTogUmUtYXNzaWdu
IDBhOjAwLjIgZnJvbSBkb21haW4gMCB0byBkb21haW4gMTQNCihYRU4pIFsyMDEyLTA5LTA2
IDIyOjE5OjI5XSBBTUQtVmk6IERpc2FibGU6IGRldmljZSBpZCA9IDB4MGEwMywgZG9tYWlu
ID0gMCwgcGFnaW5nIG1vZGUgPSAzDQooWEVOKSBbMjAxMi0wOS0wNiAyMjoxOToyOV0gQU1E
LVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHgwYTAzLCByb290IHRh
YmxlID0gMHgxZTBkODMwMDAsIGRvbWFpbiA9IDE0LCBwYWdpbmcgbW9kZSA9IDMNCihYRU4p
IFsyMDEyLTA5LTA2IDIyOjE5OjI5XSBBTUQtVmk6IFJlLWFzc2lnbiAwYTowMC4zIGZyb20g
ZG9tYWluIDAgdG8gZG9tYWluIDE0DQooWEVOKSBbMjAxMi0wOS0wNiAyMjoxOToyOV0gQU1E
LVZpOiBEaXNhYmxlOiBkZXZpY2UgaWQgPSAweDBhMDQsIGRvbWFpbiA9IDAsIHBhZ2luZyBt
b2RlID0gMw0KKFhFTikgWzIwMTItMDktMDYgMjI6MTk6MjldIEFNRC1WaTogU2V0dXAgSS9P
IHBhZ2UgdGFibGU6IGRldmljZSBpZCA9IDB4MGEwNCwgcm9vdCB0YWJsZSA9IDB4MWUwZDgz
MDAwLCBkb21haW4gPSAxNCwgcGFnaW5nIG1vZGUgPSAzDQooWEVOKSBbMjAxMi0wOS0wNiAy
MjoxOToyOV0gQU1ELVZpOiBSZS1hc3NpZ24gMGE6MDAuNCBmcm9tIGRvbWFpbiAwIHRvIGRv
bWFpbiAxNA0KKFhFTikgWzIwMTItMDktMDYgMjI6MTk6MjldIEFNRC1WaTogRGlzYWJsZTog
ZGV2aWNlIGlkID0gMHgwYTA1LCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMNCihYRU4p
IFsyMDEyLTA5LTA2IDIyOjE5OjI5XSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBk
ZXZpY2UgaWQgPSAweDBhMDUsIHJvb3QgdGFibGUgPSAweDFlMGQ4MzAwMCwgZG9tYWluID0g
MTQsIHBhZ2luZyBtb2RlID0gMw0KKFhFTikgWzIwMTItMDktMDYgMjI6MTk6MjldIEFNRC1W
aTogUmUtYXNzaWduIDBhOjAwLjUgZnJvbSBkb21haW4gMCB0byBkb21haW4gMTQNCihYRU4p
IFsyMDEyLTA5LTA2IDIyOjE5OjI5XSBBTUQtVmk6IERpc2FibGU6IGRldmljZSBpZCA9IDB4
MGEwNiwgZG9tYWluID0gMCwgcGFnaW5nIG1vZGUgPSAzDQooWEVOKSBbMjAxMi0wOS0wNiAy
MjoxOToyOV0gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHgw
YTA2LCByb290IHRhYmxlID0gMHgxZTBkODMwMDAsIGRvbWFpbiA9IDE0LCBwYWdpbmcgbW9k
ZSA9IDMNCihYRU4pIFsyMDEyLTA5LTA2IDIyOjE5OjI5XSBBTUQtVmk6IFJlLWFzc2lnbiAw
YTowMC42IGZyb20gZG9tYWluIDAgdG8gZG9tYWluIDE0DQooWEVOKSBbMjAxMi0wOS0wNiAy
MjoxOToyOV0gQU1ELVZpOiBEaXNhYmxlOiBkZXZpY2UgaWQgPSAweDBhMDcsIGRvbWFpbiA9
IDAsIHBhZ2luZyBtb2RlID0gMw0KKFhFTikgWzIwMTItMDktMDYgMjI6MTk6MjldIEFNRC1W
aTogU2V0dXAgSS9PIHBhZ2UgdGFibGU6IGRldmljZSBpZCA9IDB4MGEwNywgcm9vdCB0YWJs
ZSA9IDB4MWUwZDgzMDAwLCBkb21haW4gPSAxNCwgcGFnaW5nIG1vZGUgPSAzDQooWEVOKSBb
MjAxMi0wOS0wNiAyMjoxOToyOV0gQU1ELVZpOiBSZS1hc3NpZ24gMGE6MDAuNyBmcm9tIGRv
bWFpbiAwIHRvIGRvbWFpbiAxNA0KKFhFTikgWzIwMTItMDktMDYgMjI6MTk6MzBdIEFNRC1W
aTogRGlzYWJsZTogZGV2aWNlIGlkID0gMHgwNzAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9k
ZSA9IDMNCihYRU4pIFsyMDEyLTA5LTA2IDIyOjE5OjMwXSBBTUQtVmk6IFNldHVwIEkvTyBw
YWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweDA3MDAsIHJvb3QgdGFibGUgPSAweDFlMGQ4MzAw
MCwgZG9tYWluID0gMTQsIHBhZ2luZyBtb2RlID0gMw0KKFhFTikgWzIwMTItMDktMDYgMjI6
MTk6MzBdIEFNRC1WaTogUmUtYXNzaWduIDA3OjAwLjAgZnJvbSBkb21haW4gMCB0byBkb21h
aW4gMTQNCihYRU4pIFsyMDEyLTA5LTA2IDIyOjE5OjQ0XSB0cmFwcy5jOjI0ODk6ZDE0IERv
bWFpbiBhdHRlbXB0ZWQgV1JNU1IgMDAwMDAwMDBjMDAxMDAwNCBmcm9tIDB4MDAwMDc4NzEx
MGZkMGU4ZiB0byAweDAwMDAwMDAwMDAwMGFiY2QuDQo=
------------0E902503E1C6BF83E
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

------------0E902503E1C6BF83E--



From xen-devel-bounces@lists.xen.org Fri Sep 07 08:01:27 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Sep 2012 08:01:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9tUs-0002Az-I0; Fri, 07 Sep 2012 08:01:02 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1T9tUr-0002Au-66
	for xen-devel@lists.xen.org; Fri, 07 Sep 2012 08:01:01 +0000
Received: from [85.158.143.35:4044] by server-1.bemta-4.messagelabs.com id
	1C/2D-12504-CB9A9405; Fri, 07 Sep 2012 08:01:00 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1347004846!17113052!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM4Nzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19108 invoked from network); 7 Sep 2012 08:00:47 -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;
	7 Sep 2012 08:00:47 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 07 Sep 2012 09:00:46 +0100
Message-Id: <5049C60402000078000999A8@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 07 Sep 2012 09:01:40 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Dan Magenheimer" <dan.magenheimer@oracle.com>
References: <5047639E0200007800098DD1@nat28.tlf.novell.com>
	<c0ecf9e3-e9d1-4fc8-8427-88aff3441c33@default>
	<50486B560200007800099177@nat28.tlf.novell.com>
	<66d49024-8337-4e68-b204-45cdf8fcf5cc@default>
In-Reply-To: <66d49024-8337-4e68-b204-45cdf8fcf5cc@default>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Konrad Wilk <konrad.wilk@oracle.com>,
	Zhenzhong Duan <zhenzhong.duan@oracle.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 05/11] tmem: don't access guest memory
 without using the accessors intended for this
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.09.12 at 17:44, Dan Magenheimer <dan.magenheimer@oracle.com> wrote:
>> > I'm a bit baffled by all the unrelated changes and cleanups, but
>> > they all appear to be valid fixes and, most importantly, the
>> > related security issues appear to be resolved.
>> 
>> Having gone through the patch once more, I'd be really
>> curious where you spotted unrelated changes (apart from
>> e.g. adding proper white space use on lines that needed
>> changing anyway).
>> 
>> With the size of the patch, and with this one having been
>> done when we still thought we would issue the patches
>> together with the advisory, I would really hope not to be
>> caught to have done unnecessary changes here (while
>> still preserving generic style of the code, see below).
> 
> Again, I am not criticizing the end result or any part of
> the patch, just noting that some of it _could_ have been
> separated to a different patch, which would have made it
> _much_ more obvious what was the core fix for the security issue.
> No need to reiterate your reasons, I'm only providing more
> detail here because it sounds as if you are asking sincerely,
> not defensively.

With the below, I'm afraid you didn't review the patch
properly, or am still having problems understanding the
security aspects here.

> - changing NULL to tmh_cli_buf_null

The latter is not a simple #define of NULL.

> - changing parameter void *cva to tmem_cli_va_t clibuf,
>   which results in

Similarly, tmem_cli_va_t is not an equivalent of "void *".

>   - changing all lines that use that that parameter
>    which gave you the license to

Preserving the name of the parameter was just calling for
overlooking things. Hence, with the type change I also
changed the name (and where necessary introduced new
local variables with the old type and name, serving the
original purpose).

>    - cleanup the whitespace in all those lines

As said, I permitted myself to do this on lines I had to touch
anyway.

> - all code using -EFAULT that you changed to "< 0"
>   works correctly (though is admittedly fragile)

I don't think so - note that the changes were to "<= 0", as some
of the functions only return 1 as success indicator (and pass 0
apparently to indicate didn't do anything or some such - this
aspect of the original code was confusing me quite a bit, and
I can't exclude I broke something there).

> - inlining the use of the bool "tmemc"

Yes, this one could have been preserved, but (almost) all of its
uses would have required changes anyway.

> - the addition of scratch (which I think I understand may
>   patch a security hole undocumented in the commit comment?)

No, this was a requirement for fixing what the comment says is
being fixed: Not being allowed to directly access guest memory,
scratch space is needed for calling the compression functions.
The alternative would have been to pass guest handles to the
compression code, which would have implied touching that
code too. I think you agree that would have been a much worse
choice.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 07 08:01:27 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Sep 2012 08:01:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9tUs-0002Az-I0; Fri, 07 Sep 2012 08:01:02 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1T9tUr-0002Au-66
	for xen-devel@lists.xen.org; Fri, 07 Sep 2012 08:01:01 +0000
Received: from [85.158.143.35:4044] by server-1.bemta-4.messagelabs.com id
	1C/2D-12504-CB9A9405; Fri, 07 Sep 2012 08:01:00 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1347004846!17113052!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM4Nzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19108 invoked from network); 7 Sep 2012 08:00:47 -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;
	7 Sep 2012 08:00:47 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 07 Sep 2012 09:00:46 +0100
Message-Id: <5049C60402000078000999A8@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 07 Sep 2012 09:01:40 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Dan Magenheimer" <dan.magenheimer@oracle.com>
References: <5047639E0200007800098DD1@nat28.tlf.novell.com>
	<c0ecf9e3-e9d1-4fc8-8427-88aff3441c33@default>
	<50486B560200007800099177@nat28.tlf.novell.com>
	<66d49024-8337-4e68-b204-45cdf8fcf5cc@default>
In-Reply-To: <66d49024-8337-4e68-b204-45cdf8fcf5cc@default>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Konrad Wilk <konrad.wilk@oracle.com>,
	Zhenzhong Duan <zhenzhong.duan@oracle.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 05/11] tmem: don't access guest memory
 without using the accessors intended for this
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.09.12 at 17:44, Dan Magenheimer <dan.magenheimer@oracle.com> wrote:
>> > I'm a bit baffled by all the unrelated changes and cleanups, but
>> > they all appear to be valid fixes and, most importantly, the
>> > related security issues appear to be resolved.
>> 
>> Having gone through the patch once more, I'd be really
>> curious where you spotted unrelated changes (apart from
>> e.g. adding proper white space use on lines that needed
>> changing anyway).
>> 
>> With the size of the patch, and with this one having been
>> done when we still thought we would issue the patches
>> together with the advisory, I would really hope not to be
>> caught to have done unnecessary changes here (while
>> still preserving generic style of the code, see below).
> 
> Again, I am not criticizing the end result or any part of
> the patch, just noting that some of it _could_ have been
> separated to a different patch, which would have made it
> _much_ more obvious what was the core fix for the security issue.
> No need to reiterate your reasons, I'm only providing more
> detail here because it sounds as if you are asking sincerely,
> not defensively.

With the below, I'm afraid you didn't review the patch
properly, or am still having problems understanding the
security aspects here.

> - changing NULL to tmh_cli_buf_null

The latter is not a simple #define of NULL.

> - changing parameter void *cva to tmem_cli_va_t clibuf,
>   which results in

Similarly, tmem_cli_va_t is not an equivalent of "void *".

>   - changing all lines that use that that parameter
>    which gave you the license to

Preserving the name of the parameter was just calling for
overlooking things. Hence, with the type change I also
changed the name (and where necessary introduced new
local variables with the old type and name, serving the
original purpose).

>    - cleanup the whitespace in all those lines

As said, I permitted myself to do this on lines I had to touch
anyway.

> - all code using -EFAULT that you changed to "< 0"
>   works correctly (though is admittedly fragile)

I don't think so - note that the changes were to "<= 0", as some
of the functions only return 1 as success indicator (and pass 0
apparently to indicate didn't do anything or some such - this
aspect of the original code was confusing me quite a bit, and
I can't exclude I broke something there).

> - inlining the use of the bool "tmemc"

Yes, this one could have been preserved, but (almost) all of its
uses would have required changes anyway.

> - the addition of scratch (which I think I understand may
>   patch a security hole undocumented in the commit comment?)

No, this was a requirement for fixing what the comment says is
being fixed: Not being allowed to directly access guest memory,
scratch space is needed for calling the compression functions.
The alternative would have been to pass guest handles to the
compression code, which would have implied touching that
code too. I think you agree that would have been a much worse
choice.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 07 08:02:19 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Sep 2012 08: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 1T9tVi-0002DX-Vn; Fri, 07 Sep 2012 08:01:54 +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 1T9tVh-0002DM-1F
	for xen-devel@lists.xen.org; Fri, 07 Sep 2012 08:01:53 +0000
Received: from [85.158.139.83:54126] by server-8.bemta-5.messagelabs.com id
	57/2A-17085-0F9A9405; Fri, 07 Sep 2012 08:01:52 +0000
X-Env-Sender: yongjie.ren@intel.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1347004909!21885418!1
X-Originating-IP: [134.134.136.24]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjQgPT4gMzQwMjE0\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6673 invoked from network); 7 Sep 2012 08:01:51 -0000
Received: from mga09.intel.com (HELO mga09.intel.com) (134.134.136.24)
	by server-11.tower-182.messagelabs.com with SMTP;
	7 Sep 2012 08:01:51 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga102.jf.intel.com with ESMTP; 07 Sep 2012 01:01:43 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.80,384,1344236400"; d="scan'208";a="198546522"
Received: from fmsmsx108.amr.corp.intel.com ([10.19.9.228])
	by orsmga002.jf.intel.com with ESMTP; 07 Sep 2012 01:01:48 -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; Fri, 7 Sep 2012 01:01:40 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.239]) by
	SHSMSX102.ccr.corp.intel.com ([169.254.2.92]) with mapi id
	14.01.0355.002; Fri, 7 Sep 2012 16:01:38 +0800
From: "Ren, Yongjie" <yongjie.ren@intel.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Thread-Topic: [Xen-devel] Xen4.2-rc3 test result
Thread-Index: Ac2HShtAedsoaH/XR0eHCAg2EulTuAAEEXiAASd316D//8o/AP/+bs1A
Date: Fri, 7 Sep 2012 08:01:37 +0000
Message-ID: <1B4B44D9196EFF41AE41FDA404FC0A10194823@SHSMSX101.ccr.corp.intel.com>
References: <1B4B44D9196EFF41AE41FDA404FC0A1018AF31@SHSMSX101.ccr.corp.intel.com>
	<20120831172410.GA19756@localhost.localdomain>
	<1B4B44D9196EFF41AE41FDA404FC0A10190E9D@SHSMSX101.ccr.corp.intel.com>
	<20120906111158.GF3668@phenom.dumpdata.com>
In-Reply-To: <20120906111158.GF3668@phenom.dumpdata.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: Konrad Rzeszutek Wilk <konrad@kernel.org>, 'Keir Fraser' <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] Xen4.2-rc3 test result
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> -----Original Message-----
> From: Konrad Rzeszutek Wilk [mailto:konrad.wilk@oracle.com]
> Sent: Thursday, September 06, 2012 7:12 PM
> To: Ren, Yongjie
> Cc: Konrad Rzeszutek Wilk; 'xen-devel'; 'Keir Fraser'; 'Ian Campbell'; 'Jan
> Beulich'
> Subject: Re: [Xen-devel] Xen4.2-rc3 test result
> 
> On Thu, Sep 06, 2012 at 08:18:16AM +0000, Ren, Yongjie wrote:
> > > -----Original Message-----
> > > From: Konrad Rzeszutek [mailto:ketuzsezr@gmail.com] On Behalf Of
> > > Konrad Rzeszutek Wilk
> > > Sent: Saturday, September 01, 2012 1:24 AM
> > > To: Ren, Yongjie
> > > Cc: 'xen-devel'; 'Keir Fraser'; 'Ian Campbell'; 'Jan Beulich'; 'Konrad
> > > Rzeszutek Wilk'
> > > Subject: Re: [Xen-devel] Xen4.2-rc3 test result
> >
> > > > 5. Dom0 cannot be shutdown before PCI detachment from guest and
> > > when pci assignment conflicts
> > > >   http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1826
> > >
> > > Um, so you are assigning the same VF to two guests. I am surprised
> that
> > > the tools even allowed you to do that. Was 'xm' allowing you to do
> that?
> > >
> > No, 'xl' doesn't allow me to do that. We can't assignment a device to
> different guests.
> > Sorry, the description of this bug is not accurate. I changed its title to
> "Dom0 cannot be shut down before PCI device detachment from a guest".
> > If a guest (with a PCI device assigned) is running, Dom0 will panic when
> shutting down.
> 
> And does it panic if you use the 'irqpoll' option it asks for?
>
Adding 'irqpoll' makes no change.

It should be a regression for Xen from 4.1 to 4.2.
I didn't meet this issue with 4.2 Xen and 3.5.3 Dom0.

> Xen-pciback has no involvment as:
> 
> 
> [  283.747488] xenbus_dev_shutdown: backend/pci/1/0: Initialised !=
> Connected, skipping
> 
> and the guest still keeps on getting interrupts.
> 
> What is the stack at the hang?
>
[  283.747488] xenbus_dev_shutdown: backend/pci/1/0: Initialised != Connected,
skipping
[  283.747505] xenbus_dev_shutdown: backend/vkbd/2/0: Initialising !=
Connected, skipping
[  283.747515] xenbus_dev_shutdown: backend/console/2/0: Initialising !=
Connected, skipping
[  380.236571] irq 16: nobody cared (try booting with the "irqpoll" option)
[  380.236588] Pid: 0, comm: swapper/0 Not tainted 3.4.4 #1
[  380.236596] Call Trace:
[  380.236601]  <IRQ>  [<ffffffff8110b538>] __report_bad_irq+0x38/0xd0
[  380.236626]  [<ffffffff8110b72c>] note_interrupt+0x15c/0x210
[  380.236637]  [<ffffffff81108ffa>] handle_irq_event_percpu+0xca/0x230
[  380.236648]  [<ffffffff811091b6>] handle_irq_event+0x56/0x90
[  380.236658]  [<ffffffff8110bde3>] handle_fasteoi_irq+0x63/0x120
[  380.236671]  [<ffffffff8131c8f1>] __xen_evtchn_do_upcall+0x1b1/0x280
[  380.236703]  [<ffffffff8131d51a>] xen_evtchn_do_upcall+0x2a/0x40
[  380.236716]  [<ffffffff816bc36e>] xen_do_hypervisor_callback+0x1e/0x30
[  380.236723]  <EOI>  [<ffffffff810013aa>] ? hypercall_page+0x3aa/0x1000
[  380.236742]  [<ffffffff810013aa>] ? hypercall_page+0x3aa/0x1000
[  380.236754]  [<ffffffff810538d0>] ? xen_safe_halt+0x10/0x20
[  380.236768]  [<ffffffff81067c9a>] ? default_idle+0x6a/0x1d0
[  380.236778]  [<ffffffff81067256>] ? cpu_idle+0x96/0xf0
[  380.236789]  [<ffffffff81689a18>] ? rest_init+0x68/0x70
[  380.236800]  [<ffffffff81ca9e33>] ? start_kernel+0x407/0x414
[  380.236810]  [<ffffffff81ca984a>] ? kernel_init+0x1e1/0x1e1
[  380.236821]  [<ffffffff81ca9346>] ? x86_64_start_reservations+0x131/0x136
[  380.236833]  [<ffffffff81cade7a>] ? xen_start_kernel+0x621/0x628
[  380.236841] handlers:
[  380.236850] [<ffffffff81428d80>] usb_hcd_irq
[  380.236860] Disabling IRQ #16



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 07 08:02:19 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Sep 2012 08: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 1T9tVi-0002DX-Vn; Fri, 07 Sep 2012 08:01:54 +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 1T9tVh-0002DM-1F
	for xen-devel@lists.xen.org; Fri, 07 Sep 2012 08:01:53 +0000
Received: from [85.158.139.83:54126] by server-8.bemta-5.messagelabs.com id
	57/2A-17085-0F9A9405; Fri, 07 Sep 2012 08:01:52 +0000
X-Env-Sender: yongjie.ren@intel.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1347004909!21885418!1
X-Originating-IP: [134.134.136.24]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjQgPT4gMzQwMjE0\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6673 invoked from network); 7 Sep 2012 08:01:51 -0000
Received: from mga09.intel.com (HELO mga09.intel.com) (134.134.136.24)
	by server-11.tower-182.messagelabs.com with SMTP;
	7 Sep 2012 08:01:51 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga102.jf.intel.com with ESMTP; 07 Sep 2012 01:01:43 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.80,384,1344236400"; d="scan'208";a="198546522"
Received: from fmsmsx108.amr.corp.intel.com ([10.19.9.228])
	by orsmga002.jf.intel.com with ESMTP; 07 Sep 2012 01:01:48 -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; Fri, 7 Sep 2012 01:01:40 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.239]) by
	SHSMSX102.ccr.corp.intel.com ([169.254.2.92]) with mapi id
	14.01.0355.002; Fri, 7 Sep 2012 16:01:38 +0800
From: "Ren, Yongjie" <yongjie.ren@intel.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Thread-Topic: [Xen-devel] Xen4.2-rc3 test result
Thread-Index: Ac2HShtAedsoaH/XR0eHCAg2EulTuAAEEXiAASd316D//8o/AP/+bs1A
Date: Fri, 7 Sep 2012 08:01:37 +0000
Message-ID: <1B4B44D9196EFF41AE41FDA404FC0A10194823@SHSMSX101.ccr.corp.intel.com>
References: <1B4B44D9196EFF41AE41FDA404FC0A1018AF31@SHSMSX101.ccr.corp.intel.com>
	<20120831172410.GA19756@localhost.localdomain>
	<1B4B44D9196EFF41AE41FDA404FC0A10190E9D@SHSMSX101.ccr.corp.intel.com>
	<20120906111158.GF3668@phenom.dumpdata.com>
In-Reply-To: <20120906111158.GF3668@phenom.dumpdata.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: Konrad Rzeszutek Wilk <konrad@kernel.org>, 'Keir Fraser' <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] Xen4.2-rc3 test result
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> -----Original Message-----
> From: Konrad Rzeszutek Wilk [mailto:konrad.wilk@oracle.com]
> Sent: Thursday, September 06, 2012 7:12 PM
> To: Ren, Yongjie
> Cc: Konrad Rzeszutek Wilk; 'xen-devel'; 'Keir Fraser'; 'Ian Campbell'; 'Jan
> Beulich'
> Subject: Re: [Xen-devel] Xen4.2-rc3 test result
> 
> On Thu, Sep 06, 2012 at 08:18:16AM +0000, Ren, Yongjie wrote:
> > > -----Original Message-----
> > > From: Konrad Rzeszutek [mailto:ketuzsezr@gmail.com] On Behalf Of
> > > Konrad Rzeszutek Wilk
> > > Sent: Saturday, September 01, 2012 1:24 AM
> > > To: Ren, Yongjie
> > > Cc: 'xen-devel'; 'Keir Fraser'; 'Ian Campbell'; 'Jan Beulich'; 'Konrad
> > > Rzeszutek Wilk'
> > > Subject: Re: [Xen-devel] Xen4.2-rc3 test result
> >
> > > > 5. Dom0 cannot be shutdown before PCI detachment from guest and
> > > when pci assignment conflicts
> > > >   http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1826
> > >
> > > Um, so you are assigning the same VF to two guests. I am surprised
> that
> > > the tools even allowed you to do that. Was 'xm' allowing you to do
> that?
> > >
> > No, 'xl' doesn't allow me to do that. We can't assignment a device to
> different guests.
> > Sorry, the description of this bug is not accurate. I changed its title to
> "Dom0 cannot be shut down before PCI device detachment from a guest".
> > If a guest (with a PCI device assigned) is running, Dom0 will panic when
> shutting down.
> 
> And does it panic if you use the 'irqpoll' option it asks for?
>
Adding 'irqpoll' makes no change.

It should be a regression for Xen from 4.1 to 4.2.
I didn't meet this issue with 4.2 Xen and 3.5.3 Dom0.

> Xen-pciback has no involvment as:
> 
> 
> [  283.747488] xenbus_dev_shutdown: backend/pci/1/0: Initialised !=
> Connected, skipping
> 
> and the guest still keeps on getting interrupts.
> 
> What is the stack at the hang?
>
[  283.747488] xenbus_dev_shutdown: backend/pci/1/0: Initialised != Connected,
skipping
[  283.747505] xenbus_dev_shutdown: backend/vkbd/2/0: Initialising !=
Connected, skipping
[  283.747515] xenbus_dev_shutdown: backend/console/2/0: Initialising !=
Connected, skipping
[  380.236571] irq 16: nobody cared (try booting with the "irqpoll" option)
[  380.236588] Pid: 0, comm: swapper/0 Not tainted 3.4.4 #1
[  380.236596] Call Trace:
[  380.236601]  <IRQ>  [<ffffffff8110b538>] __report_bad_irq+0x38/0xd0
[  380.236626]  [<ffffffff8110b72c>] note_interrupt+0x15c/0x210
[  380.236637]  [<ffffffff81108ffa>] handle_irq_event_percpu+0xca/0x230
[  380.236648]  [<ffffffff811091b6>] handle_irq_event+0x56/0x90
[  380.236658]  [<ffffffff8110bde3>] handle_fasteoi_irq+0x63/0x120
[  380.236671]  [<ffffffff8131c8f1>] __xen_evtchn_do_upcall+0x1b1/0x280
[  380.236703]  [<ffffffff8131d51a>] xen_evtchn_do_upcall+0x2a/0x40
[  380.236716]  [<ffffffff816bc36e>] xen_do_hypervisor_callback+0x1e/0x30
[  380.236723]  <EOI>  [<ffffffff810013aa>] ? hypercall_page+0x3aa/0x1000
[  380.236742]  [<ffffffff810013aa>] ? hypercall_page+0x3aa/0x1000
[  380.236754]  [<ffffffff810538d0>] ? xen_safe_halt+0x10/0x20
[  380.236768]  [<ffffffff81067c9a>] ? default_idle+0x6a/0x1d0
[  380.236778]  [<ffffffff81067256>] ? cpu_idle+0x96/0xf0
[  380.236789]  [<ffffffff81689a18>] ? rest_init+0x68/0x70
[  380.236800]  [<ffffffff81ca9e33>] ? start_kernel+0x407/0x414
[  380.236810]  [<ffffffff81ca984a>] ? kernel_init+0x1e1/0x1e1
[  380.236821]  [<ffffffff81ca9346>] ? x86_64_start_reservations+0x131/0x136
[  380.236833]  [<ffffffff81cade7a>] ? xen_start_kernel+0x621/0x628
[  380.236841] handlers:
[  380.236850] [<ffffffff81428d80>] usb_hcd_irq
[  380.236860] Disabling IRQ #16



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 07 08:17:02 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Sep 2012 08:17:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9tjw-0002c0-Dh; Fri, 07 Sep 2012 08:16: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 1T9tjv-0002bv-Et
	for xen-devel@lists.xen.org; Fri, 07 Sep 2012 08:16:35 +0000
Received: from [85.158.143.99:31969] by server-3.bemta-4.messagelabs.com id
	D3/77-08232-26DA9405; Fri, 07 Sep 2012 08:16:34 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1347005794!29084467!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM4Nzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22950 invoked from network); 7 Sep 2012 08:16:34 -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;
	7 Sep 2012 08:16:34 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 07 Sep 2012 09:16:34 +0100
Message-Id: <5049C9AE02000078000999F5@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 07 Sep 2012 09:17:18 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Campbell" <Ian.Campbell@citrix.com>
References: <22d5e100131d1576d455.1346932605@cosworth.uk.xensource.com>
	<5048B1C4020000780009952E@nat28.tlf.novell.com>
	<1346939323.30018.12.camel@zakaz.uk.xensource.com>
	<5048D39D0200007800099684@nat28.tlf.novell.com>
	<1346948428.10570.33.camel@dagon.hellion.org.uk>
In-Reply-To: <1346948428.10570.33.camel@dagon.hellion.org.uk>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "Tim \(Xen.org\)" <tim@xen.org>, 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] [PATCH] xen: clamp bitmaps to correct number of bits
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.09.12 at 18:20, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> On Thu, 2012-09-06 at 15:47 +0100, Jan Beulich wrote:
>>  nor did you insert whitespace into the expressions. If I
>> were the one to commit this, I would do the adjustment while
>> committing...
> 
> This whole file seems to use Linux coding style which is why I omitted
> spaces inside the if. I made the mask "(1U << remainder) - 1" and
> simultaneously drop the superfluous extra brackets in v2 left over from
> removing &0xff. 

Oh yes, that's what I meant; I didn't want to you add white
space that the Xen coding style asks for, but Linux'es doesn't.

>> Anyway, as long as there's no easily visible tools side bug
>> addressed by this, I would think we should rather leave this
>> for after branching - Keir?
> 
> I'm fine with that.

Fell free to put my ack on it when committing (but you'll need
a separate ack from Keir anyway I believe).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 07 08:17:02 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Sep 2012 08:17:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9tjw-0002c0-Dh; Fri, 07 Sep 2012 08:16: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 1T9tjv-0002bv-Et
	for xen-devel@lists.xen.org; Fri, 07 Sep 2012 08:16:35 +0000
Received: from [85.158.143.99:31969] by server-3.bemta-4.messagelabs.com id
	D3/77-08232-26DA9405; Fri, 07 Sep 2012 08:16:34 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1347005794!29084467!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM4Nzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22950 invoked from network); 7 Sep 2012 08:16:34 -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;
	7 Sep 2012 08:16:34 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 07 Sep 2012 09:16:34 +0100
Message-Id: <5049C9AE02000078000999F5@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 07 Sep 2012 09:17:18 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Campbell" <Ian.Campbell@citrix.com>
References: <22d5e100131d1576d455.1346932605@cosworth.uk.xensource.com>
	<5048B1C4020000780009952E@nat28.tlf.novell.com>
	<1346939323.30018.12.camel@zakaz.uk.xensource.com>
	<5048D39D0200007800099684@nat28.tlf.novell.com>
	<1346948428.10570.33.camel@dagon.hellion.org.uk>
In-Reply-To: <1346948428.10570.33.camel@dagon.hellion.org.uk>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "Tim \(Xen.org\)" <tim@xen.org>, 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] [PATCH] xen: clamp bitmaps to correct number of bits
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.09.12 at 18:20, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> On Thu, 2012-09-06 at 15:47 +0100, Jan Beulich wrote:
>>  nor did you insert whitespace into the expressions. If I
>> were the one to commit this, I would do the adjustment while
>> committing...
> 
> This whole file seems to use Linux coding style which is why I omitted
> spaces inside the if. I made the mask "(1U << remainder) - 1" and
> simultaneously drop the superfluous extra brackets in v2 left over from
> removing &0xff. 

Oh yes, that's what I meant; I didn't want to you add white
space that the Xen coding style asks for, but Linux'es doesn't.

>> Anyway, as long as there's no easily visible tools side bug
>> addressed by this, I would think we should rather leave this
>> for after branching - Keir?
> 
> I'm fine with that.

Fell free to put my ack on it when committing (but you'll need
a separate ack from Keir anyway I believe).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 07 08:23:58 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Sep 2012 08:23:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9tql-0002l9-9O; Fri, 07 Sep 2012 08:23:39 +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 1T9tqk-0002l4-8B
	for xen-devel@lists.xen.org; Fri, 07 Sep 2012 08:23:38 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1347006211!9996551!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTIxNDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12116 invoked from network); 7 Sep 2012 08:23:31 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Sep 2012 08:23:31 -0000
X-IronPort-AV: E=Sophos;i="4.80,384,1344211200"; d="scan'208";a="14402341"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Sep 2012 08:23: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.279.1; Fri, 7 Sep 2012
	09:23:30 +0100
Message-ID: <1347006208.30018.33.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Fri, 7 Sep 2012 09:23:28 +0100
In-Reply-To: <5049C9AE02000078000999F5@nat28.tlf.novell.com>
References: <22d5e100131d1576d455.1346932605@cosworth.uk.xensource.com>
	<5048B1C4020000780009952E@nat28.tlf.novell.com>
	<1346939323.30018.12.camel@zakaz.uk.xensource.com>
	<5048D39D0200007800099684@nat28.tlf.novell.com>
	<1346948428.10570.33.camel@dagon.hellion.org.uk>
	<5049C9AE02000078000999F5@nat28.tlf.novell.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "Tim \(Xen.org\)" <tim@xen.org>, 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] [PATCH] xen: clamp bitmaps to correct number of bits
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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-09-07 at 09:17 +0100, Jan Beulich wrote:
> >>> On 06.09.12 at 18:20, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> > On Thu, 2012-09-06 at 15:47 +0100, Jan Beulich wrote:
> >>  nor did you insert whitespace into the expressions. If I
> >> were the one to commit this, I would do the adjustment while
> >> committing...
> > 
> > This whole file seems to use Linux coding style which is why I omitted
> > spaces inside the if. I made the mask "(1U << remainder) - 1" and
> > simultaneously drop the superfluous extra brackets in v2 left over from
> > removing &0xff. 
> 
> Oh yes, that's what I meant; I didn't want to you add white
> space that the Xen coding style asks for, but Linux'es doesn't.
> 
> >> Anyway, as long as there's no easily visible tools side bug
> >> addressed by this, I would think we should rather leave this
> >> for after branching - Keir?
> > 
> > I'm fine with that.
> 
> Fell free to put my ack on it when committing (but you'll need
> a separate ack from Keir anyway I believe).

Right, I wouldn't normally commit to the xen subtree even with Acks from
you both anyway, but an explicit "please commit" would cause me to do
so.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 07 08:23:58 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Sep 2012 08:23:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9tql-0002l9-9O; Fri, 07 Sep 2012 08:23:39 +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 1T9tqk-0002l4-8B
	for xen-devel@lists.xen.org; Fri, 07 Sep 2012 08:23:38 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1347006211!9996551!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTIxNDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12116 invoked from network); 7 Sep 2012 08:23:31 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Sep 2012 08:23:31 -0000
X-IronPort-AV: E=Sophos;i="4.80,384,1344211200"; d="scan'208";a="14402341"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Sep 2012 08:23: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.279.1; Fri, 7 Sep 2012
	09:23:30 +0100
Message-ID: <1347006208.30018.33.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Fri, 7 Sep 2012 09:23:28 +0100
In-Reply-To: <5049C9AE02000078000999F5@nat28.tlf.novell.com>
References: <22d5e100131d1576d455.1346932605@cosworth.uk.xensource.com>
	<5048B1C4020000780009952E@nat28.tlf.novell.com>
	<1346939323.30018.12.camel@zakaz.uk.xensource.com>
	<5048D39D0200007800099684@nat28.tlf.novell.com>
	<1346948428.10570.33.camel@dagon.hellion.org.uk>
	<5049C9AE02000078000999F5@nat28.tlf.novell.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "Tim \(Xen.org\)" <tim@xen.org>, 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] [PATCH] xen: clamp bitmaps to correct number of bits
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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-09-07 at 09:17 +0100, Jan Beulich wrote:
> >>> On 06.09.12 at 18:20, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> > On Thu, 2012-09-06 at 15:47 +0100, Jan Beulich wrote:
> >>  nor did you insert whitespace into the expressions. If I
> >> were the one to commit this, I would do the adjustment while
> >> committing...
> > 
> > This whole file seems to use Linux coding style which is why I omitted
> > spaces inside the if. I made the mask "(1U << remainder) - 1" and
> > simultaneously drop the superfluous extra brackets in v2 left over from
> > removing &0xff. 
> 
> Oh yes, that's what I meant; I didn't want to you add white
> space that the Xen coding style asks for, but Linux'es doesn't.
> 
> >> Anyway, as long as there's no easily visible tools side bug
> >> addressed by this, I would think we should rather leave this
> >> for after branching - Keir?
> > 
> > I'm fine with that.
> 
> Fell free to put my ack on it when committing (but you'll need
> a separate ack from Keir anyway I believe).

Right, I wouldn't normally commit to the xen subtree even with Acks from
you both anyway, but an explicit "please commit" would cause me to do
so.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 07 08:33:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Sep 2012 08:33:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9tzb-0002uy-AX; Fri, 07 Sep 2012 08:32: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 1T9tzZ-0002um-Qx
	for xen-devel@lists.xen.org; Fri, 07 Sep 2012 08:32:45 +0000
Received: from [85.158.143.99:50265] by server-1.bemta-4.messagelabs.com id
	88/28-12504-D21B9405; Fri, 07 Sep 2012 08:32:45 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1347006764!28721010!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM4Nzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26291 invoked from network); 7 Sep 2012 08:32:44 -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;
	7 Sep 2012 08:32:44 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 07 Sep 2012 09:32:45 +0100
Message-Id: <5049CD810200007800099A25@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 07 Sep 2012 09:33:37 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Campbell" <Ian.Campbell@citrix.com>, "Keir (Xen.org)" <keir@xen.org>
References: <22d5e100131d1576d455.1346932605@cosworth.uk.xensource.com>
	<5048B1C4020000780009952E@nat28.tlf.novell.com>
	<1346939323.30018.12.camel@zakaz.uk.xensource.com>
	<5048D39D0200007800099684@nat28.tlf.novell.com>
	<1346948428.10570.33.camel@dagon.hellion.org.uk>
	<5049C9AE02000078000999F5@nat28.tlf.novell.com>
	<1347006208.30018.33.camel@zakaz.uk.xensource.com>
In-Reply-To: <1347006208.30018.33.camel@zakaz.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Dario Faggioli <dario.faggioli@citrix.com>, "Tim \(Xen.org\)" <tim@xen.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] xen: clamp bitmaps to correct number of bits
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.09.12 at 10:23, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> Right, I wouldn't normally commit to the xen subtree even with Acks from
> you both anyway, but an explicit "please commit" would cause me to do
> so.

I think both Keir and I imply permission to commit with an ack (in
my case, that permission of course is limited to the portions of
the tree for which I'm listed as maintainer). Keir, please correct
me if that's a wrong understanding of mine.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 07 08:33:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Sep 2012 08:33:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9tzb-0002uy-AX; Fri, 07 Sep 2012 08:32: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 1T9tzZ-0002um-Qx
	for xen-devel@lists.xen.org; Fri, 07 Sep 2012 08:32:45 +0000
Received: from [85.158.143.99:50265] by server-1.bemta-4.messagelabs.com id
	88/28-12504-D21B9405; Fri, 07 Sep 2012 08:32:45 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1347006764!28721010!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM4Nzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26291 invoked from network); 7 Sep 2012 08:32:44 -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;
	7 Sep 2012 08:32:44 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 07 Sep 2012 09:32:45 +0100
Message-Id: <5049CD810200007800099A25@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 07 Sep 2012 09:33:37 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Campbell" <Ian.Campbell@citrix.com>, "Keir (Xen.org)" <keir@xen.org>
References: <22d5e100131d1576d455.1346932605@cosworth.uk.xensource.com>
	<5048B1C4020000780009952E@nat28.tlf.novell.com>
	<1346939323.30018.12.camel@zakaz.uk.xensource.com>
	<5048D39D0200007800099684@nat28.tlf.novell.com>
	<1346948428.10570.33.camel@dagon.hellion.org.uk>
	<5049C9AE02000078000999F5@nat28.tlf.novell.com>
	<1347006208.30018.33.camel@zakaz.uk.xensource.com>
In-Reply-To: <1347006208.30018.33.camel@zakaz.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Dario Faggioli <dario.faggioli@citrix.com>, "Tim \(Xen.org\)" <tim@xen.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] xen: clamp bitmaps to correct number of bits
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.09.12 at 10:23, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> Right, I wouldn't normally commit to the xen subtree even with Acks from
> you both anyway, but an explicit "please commit" would cause me to do
> so.

I think both Keir and I imply permission to commit with an ack (in
my case, that permission of course is limited to the portions of
the tree for which I'm listed as maintainer). Keir, please correct
me if that's a wrong understanding of mine.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 07 08:33:06 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Sep 2012 08: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 1T9tzd-0002vl-O6; Fri, 07 Sep 2012 08:32:49 +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 1T9tzd-0002ub-0X
	for xen-devel@lists.xen.org; Fri, 07 Sep 2012 08:32:49 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1347006759!3034028!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTIxNDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18003 invoked from network); 7 Sep 2012 08:32:39 -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;
	7 Sep 2012 08:32:39 -0000
X-IronPort-AV: E=Sophos;i="4.80,384,1344211200"; d="scan'208";a="14402556"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Sep 2012 08:32: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.279.1; Fri, 7 Sep 2012
	09:32:28 +0100
Message-ID: <1347006747.30018.37.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Olaf Hering <olaf@aepfle.de>
Date: Fri, 7 Sep 2012 09:32:27 +0100
In-Reply-To: <8a2eef481d3ab3ca5692.1346945346@probook.site>
References: <8a2eef481d3ab3ca5692.1346945346@probook.site>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] pygrub: always append --args
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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-09-06 at 16:29 +0100, Olaf Hering wrote:
> # HG changeset patch
> # User Olaf Hering <olaf@aepfle.de>
> # Date 1346945306 -7200
> # Node ID 8a2eef481d3ab3ca5692dd0083c95cf314fe1da3
> # Parent  19d367bf07b7687b831c212a57a70e73ea14d3b7
> pygrub: always append --args
> 
> If a bootloader entry in menu.lst has no additional kernel command line
> options listed and the domU.cfg has 'bootargs="--args=something"' the
> additional arguments from the config file are not passed to the kernel.
> The reason for that incorrect behaviour is that run_grub appends arg
> only if the parsed config file has arguments listed.
> 
> Fix this by appending args from image section and the config file separatly.
> To avoid adding to a NoneType initialize grubcfg['args'] to an empty string.
> This does not change behaviour but simplifies the code which appends the
> string.
> 
> Signed-off-by: Olaf Hering <olaf@aepfle.de>

This has to be 4.3 at this point.

> 
> diff -r 19d367bf07b7 -r 8a2eef481d3a tools/pygrub/src/pygrub
> --- a/tools/pygrub/src/pygrub
> +++ b/tools/pygrub/src/pygrub
> @@ -615,13 +615,15 @@ def run_grub(file, entry, fs, arg):
>      except IndexError:
>          img = g.cf.images[0]
>  
> -    grubcfg = { "kernel": None, "ramdisk": None, "args": None }
> +    grubcfg = { "kernel": None, "ramdisk": None, "args": "" }
>  
>      grubcfg["kernel"] = img.kernel[1]
>      if img.initrd:
>          grubcfg["ramdisk"] = img.initrd[1]
>      if img.args:

With the above change isn't this always true?

It probably should have read
	if img.args is not None
in the first place.

> -        grubcfg["args"] = img.args + " " + arg
> +        grubcfg["args"] += img.args
> +    if arg:
> +        grubcfg["args"] += " " + args

>  
>      return grubcfg
>  
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Sep 07 08:33:06 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Sep 2012 08: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 1T9tzd-0002vl-O6; Fri, 07 Sep 2012 08:32:49 +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 1T9tzd-0002ub-0X
	for xen-devel@lists.xen.org; Fri, 07 Sep 2012 08:32:49 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1347006759!3034028!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTIxNDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18003 invoked from network); 7 Sep 2012 08:32:39 -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;
	7 Sep 2012 08:32:39 -0000
X-IronPort-AV: E=Sophos;i="4.80,384,1344211200"; d="scan'208";a="14402556"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Sep 2012 08:32: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.279.1; Fri, 7 Sep 2012
	09:32:28 +0100
Message-ID: <1347006747.30018.37.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Olaf Hering <olaf@aepfle.de>
Date: Fri, 7 Sep 2012 09:32:27 +0100
In-Reply-To: <8a2eef481d3ab3ca5692.1346945346@probook.site>
References: <8a2eef481d3ab3ca5692.1346945346@probook.site>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] pygrub: always append --args
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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-09-06 at 16:29 +0100, Olaf Hering wrote:
> # HG changeset patch
> # User Olaf Hering <olaf@aepfle.de>
> # Date 1346945306 -7200
> # Node ID 8a2eef481d3ab3ca5692dd0083c95cf314fe1da3
> # Parent  19d367bf07b7687b831c212a57a70e73ea14d3b7
> pygrub: always append --args
> 
> If a bootloader entry in menu.lst has no additional kernel command line
> options listed and the domU.cfg has 'bootargs="--args=something"' the
> additional arguments from the config file are not passed to the kernel.
> The reason for that incorrect behaviour is that run_grub appends arg
> only if the parsed config file has arguments listed.
> 
> Fix this by appending args from image section and the config file separatly.
> To avoid adding to a NoneType initialize grubcfg['args'] to an empty string.
> This does not change behaviour but simplifies the code which appends the
> string.
> 
> Signed-off-by: Olaf Hering <olaf@aepfle.de>

This has to be 4.3 at this point.

> 
> diff -r 19d367bf07b7 -r 8a2eef481d3a tools/pygrub/src/pygrub
> --- a/tools/pygrub/src/pygrub
> +++ b/tools/pygrub/src/pygrub
> @@ -615,13 +615,15 @@ def run_grub(file, entry, fs, arg):
>      except IndexError:
>          img = g.cf.images[0]
>  
> -    grubcfg = { "kernel": None, "ramdisk": None, "args": None }
> +    grubcfg = { "kernel": None, "ramdisk": None, "args": "" }
>  
>      grubcfg["kernel"] = img.kernel[1]
>      if img.initrd:
>          grubcfg["ramdisk"] = img.initrd[1]
>      if img.args:

With the above change isn't this always true?

It probably should have read
	if img.args is not None
in the first place.

> -        grubcfg["args"] = img.args + " " + arg
> +        grubcfg["args"] += img.args
> +    if arg:
> +        grubcfg["args"] += " " + args

>  
>      return grubcfg
>  
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Sep 07 08:38:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Sep 2012 08:38:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9u4Q-0003Ib-Gi; Fri, 07 Sep 2012 08:37: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 1T9u4P-0003IS-Lw
	for xen-devel@lists.xen.org; Fri, 07 Sep 2012 08:37:45 +0000
Received: from [85.158.143.99:55874] by server-3.bemta-4.messagelabs.com id
	3C/80-08232-952B9405; Fri, 07 Sep 2012 08:37:45 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1347007064!21531584!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM4Nzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16156 invoked from network); 7 Sep 2012 08:37:44 -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;
	7 Sep 2012 08:37:44 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 07 Sep 2012 09:37:44 +0100
Message-Id: <5049CEAE0200007800099A33@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 07 Sep 2012 09:38:38 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ben Guthro" <ben@guthro.net>
References: <CAOvdn6WwgBD-2yf1uu3m9-16=Tb5KUrybXf2KibtnxKbP7YtwA@mail.gmail.com>
	<CAOvdn6UBW-yTOMd3YSf5M9JiHLRivyaKL-qzcKG8epszqaKmGg@mail.gmail.com>
	<20120807163320.GC15053@phenom.dumpdata.com>
	<CAOvdn6XcRGKtJxGwJO8J+ZBJr89wfTLc1woW5rhtMM540H9h1w@mail.gmail.com>
	<CAOvdn6XUoSeGoo7X=AJ1kpDxZB9HZEv+TJ4v-=FHcyR4=CHK-w@mail.gmail.com>
	<502240F302000078000937A6@nat28.tlf.novell.com>
	<CAOvdn6WN3kxC8Bb9g6MpfLULu47EGSGCtajPc-SFeJ-8VSUQDQ@mail.gmail.com>
	<CAOvdn6Xk1inm1hU55i0phU2qvSWyJLNoyDdn43biBAY2OewPtw@mail.gmail.com>
	<5023F5400200007800093F4E@nat28.tlf.novell.com>
	<CAOvdn6U-f3C4U8xVPvDyRFkFFLkbfiCXg_n+9zgA9V5u+q5jfw@mail.gmail.com>
	<5023F8B80200007800093F8C@nat28.tlf.novell.com>
	<CAOvdn6XKHfete_+=Hkvt20G7_cJ-4i8+9j9YD30OxzQ16Ru-+g@mail.gmail.com>
	<5024CB720200007800094124@nat28.tlf.novell.com>
	<CAOvdn6VVJdhWVYa-gNVt3euE4AbGi1TijUCUd1wGzv0SCWEUYA@mail.gmail.com>
	<CAOvdn6USnG9Y4MNBhrDZmob0oJ8BgFfKTvFEhcKbXDxNmzfZ-Q@mail.gmail.com>
	<502B75BA0200007800094FD4@nat28.tlf.novell.com>
	<CAOvdn6Ww5oEj6Xg=XT4dWCYWUBuOdPqLz-CqNjz4HmCScE+==g@mail.gmail.com>
	<CAOvdn6Wsjds_dmZ0dwDTYmD-o-OqjBH5-b9mitAuUADE+A4_ag@mail.gmail.com>
	<502BB8FD02000078000951E0@nat28.tlf.novell.com>
	<CAOvdn6VD6bp13F-tvYdkBsj4hkhE7PTGZrapndtdHrDKeZqccg@mail.gmail.com>
	<502CCC0002000078000955C4@nat28.tlf.novell.com>
	<CAOvdn6VEuX7R2_wz74ZvCxMjC-=YUir9kP5sdxEVaKVspRUd_w@mail.gmail.com>
	<502CF0A8020000780009574E@nat28.tlf.novell.com>
	<CAOvdn6VsZvn_1TCWYeuyY5YuTcP8=miK2KwE4583nsj6Qjb_vg@mail.gmail.com>
	<504494FB0200007800098398@nat28.tlf.novell.com>
	<CAOvdn6UT13qvWbMyfZkWND03RoVKVSgb6wW4yqTUpuBYEX01Dg@mail.gmail.com>
	<5048958D02000078000993EB@nat28.tlf.novell.com>
	<CAOvdn6WrNK1Jn_Y_P7C3AwX6ApVcgzacLA_x-u=xBQtebnuPxA@mail.gmail.com>
	<CAOvdn6U_Z=KdEo56nqe7jN54BwiesRJqDOz_VzVNpkWGfFRd2A@mail.gmail.com>
In-Reply-To: <CAOvdn6U_Z=KdEo56nqe7jN54BwiesRJqDOz_VzVNpkWGfFRd2A@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>, john.baboval@citrix.com,
	Thomas Goetz <thomas.goetz@citrix.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen4.2 S3 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.09.12 at 18:42, Ben Guthro <ben@guthro.net> wrote:
> Odd.
> The behavior seems to change, when not running with serial output.

Odd indeed. Could you (unless you are already) try running the
serial console in polling mode (i.e. without IRQ), to see whether
the IRQs coming from it somehow keep the system alive at a
certain point?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 07 08:38:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Sep 2012 08:38:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9u4Q-0003Ib-Gi; Fri, 07 Sep 2012 08:37: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 1T9u4P-0003IS-Lw
	for xen-devel@lists.xen.org; Fri, 07 Sep 2012 08:37:45 +0000
Received: from [85.158.143.99:55874] by server-3.bemta-4.messagelabs.com id
	3C/80-08232-952B9405; Fri, 07 Sep 2012 08:37:45 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1347007064!21531584!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM4Nzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16156 invoked from network); 7 Sep 2012 08:37:44 -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;
	7 Sep 2012 08:37:44 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 07 Sep 2012 09:37:44 +0100
Message-Id: <5049CEAE0200007800099A33@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 07 Sep 2012 09:38:38 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ben Guthro" <ben@guthro.net>
References: <CAOvdn6WwgBD-2yf1uu3m9-16=Tb5KUrybXf2KibtnxKbP7YtwA@mail.gmail.com>
	<CAOvdn6UBW-yTOMd3YSf5M9JiHLRivyaKL-qzcKG8epszqaKmGg@mail.gmail.com>
	<20120807163320.GC15053@phenom.dumpdata.com>
	<CAOvdn6XcRGKtJxGwJO8J+ZBJr89wfTLc1woW5rhtMM540H9h1w@mail.gmail.com>
	<CAOvdn6XUoSeGoo7X=AJ1kpDxZB9HZEv+TJ4v-=FHcyR4=CHK-w@mail.gmail.com>
	<502240F302000078000937A6@nat28.tlf.novell.com>
	<CAOvdn6WN3kxC8Bb9g6MpfLULu47EGSGCtajPc-SFeJ-8VSUQDQ@mail.gmail.com>
	<CAOvdn6Xk1inm1hU55i0phU2qvSWyJLNoyDdn43biBAY2OewPtw@mail.gmail.com>
	<5023F5400200007800093F4E@nat28.tlf.novell.com>
	<CAOvdn6U-f3C4U8xVPvDyRFkFFLkbfiCXg_n+9zgA9V5u+q5jfw@mail.gmail.com>
	<5023F8B80200007800093F8C@nat28.tlf.novell.com>
	<CAOvdn6XKHfete_+=Hkvt20G7_cJ-4i8+9j9YD30OxzQ16Ru-+g@mail.gmail.com>
	<5024CB720200007800094124@nat28.tlf.novell.com>
	<CAOvdn6VVJdhWVYa-gNVt3euE4AbGi1TijUCUd1wGzv0SCWEUYA@mail.gmail.com>
	<CAOvdn6USnG9Y4MNBhrDZmob0oJ8BgFfKTvFEhcKbXDxNmzfZ-Q@mail.gmail.com>
	<502B75BA0200007800094FD4@nat28.tlf.novell.com>
	<CAOvdn6Ww5oEj6Xg=XT4dWCYWUBuOdPqLz-CqNjz4HmCScE+==g@mail.gmail.com>
	<CAOvdn6Wsjds_dmZ0dwDTYmD-o-OqjBH5-b9mitAuUADE+A4_ag@mail.gmail.com>
	<502BB8FD02000078000951E0@nat28.tlf.novell.com>
	<CAOvdn6VD6bp13F-tvYdkBsj4hkhE7PTGZrapndtdHrDKeZqccg@mail.gmail.com>
	<502CCC0002000078000955C4@nat28.tlf.novell.com>
	<CAOvdn6VEuX7R2_wz74ZvCxMjC-=YUir9kP5sdxEVaKVspRUd_w@mail.gmail.com>
	<502CF0A8020000780009574E@nat28.tlf.novell.com>
	<CAOvdn6VsZvn_1TCWYeuyY5YuTcP8=miK2KwE4583nsj6Qjb_vg@mail.gmail.com>
	<504494FB0200007800098398@nat28.tlf.novell.com>
	<CAOvdn6UT13qvWbMyfZkWND03RoVKVSgb6wW4yqTUpuBYEX01Dg@mail.gmail.com>
	<5048958D02000078000993EB@nat28.tlf.novell.com>
	<CAOvdn6WrNK1Jn_Y_P7C3AwX6ApVcgzacLA_x-u=xBQtebnuPxA@mail.gmail.com>
	<CAOvdn6U_Z=KdEo56nqe7jN54BwiesRJqDOz_VzVNpkWGfFRd2A@mail.gmail.com>
In-Reply-To: <CAOvdn6U_Z=KdEo56nqe7jN54BwiesRJqDOz_VzVNpkWGfFRd2A@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>, john.baboval@citrix.com,
	Thomas Goetz <thomas.goetz@citrix.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen4.2 S3 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.09.12 at 18:42, Ben Guthro <ben@guthro.net> wrote:
> Odd.
> The behavior seems to change, when not running with serial output.

Odd indeed. Could you (unless you are already) try running the
serial console in polling mode (i.e. without IRQ), to see whether
the IRQs coming from it somehow keep the system alive at a
certain point?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 07 08:41:32 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Sep 2012 08:41: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 1T9u7o-0003UJ-Ex; Fri, 07 Sep 2012 08:41: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 1T9u7m-0003UA-Rx
	for xen-devel@lists.xen.org; Fri, 07 Sep 2012 08:41:15 +0000
Received: from [85.158.143.35:24165] by server-3.bemta-4.messagelabs.com id
	75/67-08232-A23B9405; Fri, 07 Sep 2012 08:41:14 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1347007261!17120988!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTIyMTE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25834 invoked from network); 7 Sep 2012 08:41:11 -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 Sep 2012 08:41:11 -0000
X-IronPort-AV: E=Sophos;i="4.80,384,1344211200"; d="scan'208";a="14402919"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Sep 2012 08:41: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.279.1; Fri, 7 Sep 2012
	09:41:01 +0100
Message-ID: <1347007260.30018.39.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Olaf Hering <olaf@aepfle.de>, Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Fri, 7 Sep 2012 09:41:00 +0100
In-Reply-To: <cc71fe7029b27cb95d26.1346951697@probook.site>
References: <cc71fe7029b27cb95d26.1346951697@probook.site>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] libxl: add missing dependencies of libxl.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, 2012-09-06 at 18:14 +0100, Olaf Hering wrote:
> # HG changeset patch
> # User Olaf Hering <olaf@aepfle.de>
> # Date 1346951410 -7200
> # Node ID cc71fe7029b27cb95d268b99e136c445903af927
> # Parent  8a2eef481d3ab3ca5692dd0083c95cf314fe1da3
> libxl: add missing dependencies of libxl.h
> 
> libxl.h includes generated files, but the Makefile lists no dependency on
> these files. As a result compilation may fail like this:
> 
> [  379s] make -C libxl install
> [  379s] make[3]: Entering directory `/usr/src/packages/BUILD/xen-4.2.25821/non-dbg/tools/libxl'
> [  379s] /usr/bin/perl /usr/src/packages/BUILD/xen-4.2.25821/non-dbg/tools/libxl/../../tools/include/xen-external/bsd-sys-queue-h-seddery /usr/src/packages/BUILD/xen-4.2.25821/non-dbg/tools/libxl/../../tools/include/xen-external/bsd-sys-queue.h --prefix=libxl >_libxl_list.h.new
> ...
> [  380s] 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.api-for-check.d  -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -fno-optimize-sibling-calls -fmessage-length=0 -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables -fasynchronous-unwind-tables -Werror -Wno-format-zero-length -Wmissing-declarations -Wno-declaration-after-statement -Wformat-nonliteral -I. -fPIC -pthread -I/usr/src/packages/BUILD/xen-4.2.25821/non-dbg/tools/libxl/../../tools/libxc -I/usr/src/packages/BUILD/xen-4.2.25821/non-dbg/tools/libxl/../../tools/include  -I/usr/src/packages/BUILD/xen-4.2.25821/non-dbg/tools/libxl/../../tools/libxl -I/usr/src/packages/BUILD/xen-4.2.25821/non-dbg/tools/libxl/../../tools/libxc -I/usr/src/packages/BUILD/xen-4.2.25821/non-dbg/tools/libxl/../../tools/include -I/usr/src/packages/BUILD/xen-4.2.25821/non-dbg/tools/libxl/../../tools/include -include /usr/src/packages/BUILD/xen-4.2.25821/non-dbg/tools/libxl/../../tools/config.h  -I/usr/src/packages/BUILD/xen-4.2.25821/non-dbg/tools/libxl/../../tools/libxc -I/usr/src/packages/BUILD/xen-4.2.25821/non-dbg/tools/libxl/../../tools/include   -c -E libxl.h  \
> [  380s] -DLIBXL_EXTERNAL_CALLERS_ONLY=LIBXL_EXTERNAL_CALLERS_ONLY \
> [  380s] >_libxl.api-for-check.new
> ...
> [  380s] libxl.h:260:25: fatal error: _libxl_list.h: No such file or directory
> [  380s] compilation terminated.
> [  380s] make[3]: *** [_libxl.api-for-check] Error 1
> [  381s] if ! cmp -s _libxl_list.h.new _libxl_list.h; then mv -f _libxl_list.h.new _libxl_list.h; else rm -f _libxl_list.h.new; fi
> 
> 
> Fix this be extending the existing libxl.h dependency with the generated file
> _libxl_list.h, and also with the existing libxl_event.h.
> 
> Signed-off-by: Olaf Hering <olaf@aepfle.de>
> 
> diff -r 8a2eef481d3a -r cc71fe7029b2 tools/libxl/Makefile
> --- a/tools/libxl/Makefile
> +++ b/tools/libxl/Makefile
> @@ -140,7 +140,7 @@ _libxl_save_msgs_helper.h _libxl_save_ms
>  	$(PERL) -w $< $@ >$@.new
>  	$(call move-if-changed,$@.new,$@)
>  
> -libxl.h: _libxl_types.h
> +libxl.h: _libxl_types.h _libxl_list.h libxl_event.h

You don't need libxl_event.h here (it's not autogenerated).

I'm not sure if $(AUTOINCS) should be used here. Ian J probably has an
opinion.

>  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
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Sep 07 08:41:32 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Sep 2012 08:41: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 1T9u7o-0003UJ-Ex; Fri, 07 Sep 2012 08:41: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 1T9u7m-0003UA-Rx
	for xen-devel@lists.xen.org; Fri, 07 Sep 2012 08:41:15 +0000
Received: from [85.158.143.35:24165] by server-3.bemta-4.messagelabs.com id
	75/67-08232-A23B9405; Fri, 07 Sep 2012 08:41:14 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1347007261!17120988!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTIyMTE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25834 invoked from network); 7 Sep 2012 08:41:11 -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 Sep 2012 08:41:11 -0000
X-IronPort-AV: E=Sophos;i="4.80,384,1344211200"; d="scan'208";a="14402919"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Sep 2012 08:41: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.279.1; Fri, 7 Sep 2012
	09:41:01 +0100
Message-ID: <1347007260.30018.39.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Olaf Hering <olaf@aepfle.de>, Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Fri, 7 Sep 2012 09:41:00 +0100
In-Reply-To: <cc71fe7029b27cb95d26.1346951697@probook.site>
References: <cc71fe7029b27cb95d26.1346951697@probook.site>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] libxl: add missing dependencies of libxl.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, 2012-09-06 at 18:14 +0100, Olaf Hering wrote:
> # HG changeset patch
> # User Olaf Hering <olaf@aepfle.de>
> # Date 1346951410 -7200
> # Node ID cc71fe7029b27cb95d268b99e136c445903af927
> # Parent  8a2eef481d3ab3ca5692dd0083c95cf314fe1da3
> libxl: add missing dependencies of libxl.h
> 
> libxl.h includes generated files, but the Makefile lists no dependency on
> these files. As a result compilation may fail like this:
> 
> [  379s] make -C libxl install
> [  379s] make[3]: Entering directory `/usr/src/packages/BUILD/xen-4.2.25821/non-dbg/tools/libxl'
> [  379s] /usr/bin/perl /usr/src/packages/BUILD/xen-4.2.25821/non-dbg/tools/libxl/../../tools/include/xen-external/bsd-sys-queue-h-seddery /usr/src/packages/BUILD/xen-4.2.25821/non-dbg/tools/libxl/../../tools/include/xen-external/bsd-sys-queue.h --prefix=libxl >_libxl_list.h.new
> ...
> [  380s] 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.api-for-check.d  -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -fno-optimize-sibling-calls -fmessage-length=0 -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables -fasynchronous-unwind-tables -Werror -Wno-format-zero-length -Wmissing-declarations -Wno-declaration-after-statement -Wformat-nonliteral -I. -fPIC -pthread -I/usr/src/packages/BUILD/xen-4.2.25821/non-dbg/tools/libxl/../../tools/libxc -I/usr/src/packages/BUILD/xen-4.2.25821/non-dbg/tools/libxl/../../tools/include  -I/usr/src/packages/BUILD/xen-4.2.25821/non-dbg/tools/libxl/../../tools/libxl -I/usr/src/packages/BUILD/xen-4.2.25821/non-dbg/tools/libxl/../../tools/libxc -I/usr/src/packages/BUILD/xen-4.2.25821/non-dbg/tools/libxl/../../tools/include -I/usr/src/packages/BUILD/xen-4.2.25821/non-dbg/tools/libxl/../../tools/include -include /usr/src/packages/BUILD/xen-4.2.25821/non-dbg/tools/libxl/../../tools/config.h  -I/usr/src/packages/BUILD/xen-4.2.25821/non-dbg/tools/libxl/../../tools/libxc -I/usr/src/packages/BUILD/xen-4.2.25821/non-dbg/tools/libxl/../../tools/include   -c -E libxl.h  \
> [  380s] -DLIBXL_EXTERNAL_CALLERS_ONLY=LIBXL_EXTERNAL_CALLERS_ONLY \
> [  380s] >_libxl.api-for-check.new
> ...
> [  380s] libxl.h:260:25: fatal error: _libxl_list.h: No such file or directory
> [  380s] compilation terminated.
> [  380s] make[3]: *** [_libxl.api-for-check] Error 1
> [  381s] if ! cmp -s _libxl_list.h.new _libxl_list.h; then mv -f _libxl_list.h.new _libxl_list.h; else rm -f _libxl_list.h.new; fi
> 
> 
> Fix this be extending the existing libxl.h dependency with the generated file
> _libxl_list.h, and also with the existing libxl_event.h.
> 
> Signed-off-by: Olaf Hering <olaf@aepfle.de>
> 
> diff -r 8a2eef481d3a -r cc71fe7029b2 tools/libxl/Makefile
> --- a/tools/libxl/Makefile
> +++ b/tools/libxl/Makefile
> @@ -140,7 +140,7 @@ _libxl_save_msgs_helper.h _libxl_save_ms
>  	$(PERL) -w $< $@ >$@.new
>  	$(call move-if-changed,$@.new,$@)
>  
> -libxl.h: _libxl_types.h
> +libxl.h: _libxl_types.h _libxl_list.h libxl_event.h

You don't need libxl_event.h here (it's not autogenerated).

I'm not sure if $(AUTOINCS) should be used here. Ian J probably has an
opinion.

>  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
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Sep 07 08:51:00 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Sep 2012 08: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 1T9uGu-0003ft-Iv; Fri, 07 Sep 2012 08:50:40 +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 1T9uGs-0003fo-WB
	for xen-devel@lists.xen.org; Fri, 07 Sep 2012 08:50:39 +0000
Received: from [85.158.139.83:43598] by server-2.bemta-5.messagelabs.com id
	B9/D3-11456-E55B9405; Fri, 07 Sep 2012 08:50:38 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-15.tower-182.messagelabs.com!1347007837!29036330!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14769 invoked from network); 7 Sep 2012 08:50:37 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-15.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 7 Sep 2012 08:50:37 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1T9uGr-000Iij-0p; Fri, 07 Sep 2012 08:50:37 +0000
Date: Fri, 7 Sep 2012 09:50:36 +0100
From: Tim Deegan <tim@xen.org>
To: Jeffrey Karrels <karrelsj@gmail.com>
Message-ID: <20120907085036.GA71093@ocelot.phlegethon.org>
References: <CAFw--Dd0k7L+T_UJc0yHAkUGrY_-GDHaQjK3OM-1UdOp=J-wAQ@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAFw--Dd0k7L+T_UJc0yHAkUGrY_-GDHaQjK3OM-1UdOp=J-wAQ@mail.gmail.com>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Clang/LLVM version requirements
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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:32 -0700 on 06 Sep (1346945573), Jeffrey Karrels wrote:
> Is there a required Clang and LLVM version one needs to do a 'make
> xen-dist clang=y'?
> 
> I recently tried and the process failed. I haven't begun debugging as
> I figured I would ask the obvious first. The build failed with the
> following:

Looks like the clang build has bitrotted a little - sorry.  It's too
late to fix this for 4.2 now but we can sort it out after we branch
(i.e. next week) and backport any build fixes for 4.2.1.

I have: 
  Debian clang version 3.0-6 (tags/RELEASE_30/final) (based on LLVM 3.0)
  Target: x86_64-pc-linux-gnu
  Thread model: posix

which can build _almost_ everything but chokes on a new .subsection rune
in inline asm.  It builds and boots with the change below.  Building
lto=y isn't working (GOLD is choking on the final link).  I'll look into
that next week.

Jan, would you object to some other way of checking for .bss in reloc.c?
Could we just objcopy it out so any BSS symbols make it fail at link
time?  In any case we probably ought to check for stray .data symbols too.

Cheers,

Tim.

diff -r ec23c2a11f6f xen/arch/x86/boot/reloc.c
--- a/xen/arch/x86/boot/reloc.c	Thu Sep 06 17:08:44 2012 +0100
+++ b/xen/arch/x86/boot/reloc.c	Fri Sep 07 09:30:13 2012 +0100
@@ -18,10 +18,7 @@ asm (
     "    call 1f                       \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"
+    "    jmp  reloc                    \n"
     );
 
 /* This is our data.  Because the code must be relocatable, no BSS is
@@ -30,9 +27,6 @@ asm (
 asm (
     "alloc:                            \n"
     "    .long 0                       \n"
-    "    .subsection 1                 \n"
-    "    .p2align 4, 0xcc              \n"
-    "    .subsection 0                 \n"
     );
 
 typedef unsigned int u32;

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 07 08:51:00 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Sep 2012 08: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 1T9uGu-0003ft-Iv; Fri, 07 Sep 2012 08:50:40 +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 1T9uGs-0003fo-WB
	for xen-devel@lists.xen.org; Fri, 07 Sep 2012 08:50:39 +0000
Received: from [85.158.139.83:43598] by server-2.bemta-5.messagelabs.com id
	B9/D3-11456-E55B9405; Fri, 07 Sep 2012 08:50:38 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-15.tower-182.messagelabs.com!1347007837!29036330!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14769 invoked from network); 7 Sep 2012 08:50:37 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-15.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 7 Sep 2012 08:50:37 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1T9uGr-000Iij-0p; Fri, 07 Sep 2012 08:50:37 +0000
Date: Fri, 7 Sep 2012 09:50:36 +0100
From: Tim Deegan <tim@xen.org>
To: Jeffrey Karrels <karrelsj@gmail.com>
Message-ID: <20120907085036.GA71093@ocelot.phlegethon.org>
References: <CAFw--Dd0k7L+T_UJc0yHAkUGrY_-GDHaQjK3OM-1UdOp=J-wAQ@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAFw--Dd0k7L+T_UJc0yHAkUGrY_-GDHaQjK3OM-1UdOp=J-wAQ@mail.gmail.com>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Clang/LLVM version requirements
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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:32 -0700 on 06 Sep (1346945573), Jeffrey Karrels wrote:
> Is there a required Clang and LLVM version one needs to do a 'make
> xen-dist clang=y'?
> 
> I recently tried and the process failed. I haven't begun debugging as
> I figured I would ask the obvious first. The build failed with the
> following:

Looks like the clang build has bitrotted a little - sorry.  It's too
late to fix this for 4.2 now but we can sort it out after we branch
(i.e. next week) and backport any build fixes for 4.2.1.

I have: 
  Debian clang version 3.0-6 (tags/RELEASE_30/final) (based on LLVM 3.0)
  Target: x86_64-pc-linux-gnu
  Thread model: posix

which can build _almost_ everything but chokes on a new .subsection rune
in inline asm.  It builds and boots with the change below.  Building
lto=y isn't working (GOLD is choking on the final link).  I'll look into
that next week.

Jan, would you object to some other way of checking for .bss in reloc.c?
Could we just objcopy it out so any BSS symbols make it fail at link
time?  In any case we probably ought to check for stray .data symbols too.

Cheers,

Tim.

diff -r ec23c2a11f6f xen/arch/x86/boot/reloc.c
--- a/xen/arch/x86/boot/reloc.c	Thu Sep 06 17:08:44 2012 +0100
+++ b/xen/arch/x86/boot/reloc.c	Fri Sep 07 09:30:13 2012 +0100
@@ -18,10 +18,7 @@ asm (
     "    call 1f                       \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"
+    "    jmp  reloc                    \n"
     );
 
 /* This is our data.  Because the code must be relocatable, no BSS is
@@ -30,9 +27,6 @@ asm (
 asm (
     "alloc:                            \n"
     "    .long 0                       \n"
-    "    .subsection 1                 \n"
-    "    .p2align 4, 0xcc              \n"
-    "    .subsection 0                 \n"
     );
 
 typedef unsigned int u32;

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 07 08:52:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Sep 2012 08:52:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9uI8-0003jw-1t; Fri, 07 Sep 2012 08:51:56 +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 1T9uI6-0003jU-VP
	for xen-devel@lists.xen.org; Fri, 07 Sep 2012 08:51:55 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1347007907!10001635!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTIxNDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7514 invoked from network); 7 Sep 2012 08:51:48 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Sep 2012 08:51:48 -0000
X-IronPort-AV: E=Sophos;i="4.80,384,1344211200"; d="scan'208";a="14403232"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Sep 2012 08:51: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.279.1; Fri, 7 Sep 2012
	09:51:47 +0100
Message-ID: <1347007906.30018.43.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Matt Wilson <msw@amazon.com>
Date: Fri, 7 Sep 2012 09:51:46 +0100
In-Reply-To: <patchbomb.1346992557@u002268147cd4502c336d.ant.amazon.com>
References: <patchbomb.1346992557@u002268147cd4502c336d.ant.amazon.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-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 0 of 2 v3] improve checking for
 documentation tools and formatting
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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-09-07 at 05:35 +0100, Matt Wilson wrote:
> This version addresses feedback from v2. Please let me know if there
> are any other concerns.

In general I think I'm happy to take docs updates right up to the
release, but in this case since it also involves changes to autoconf and
the build system I think is now 4.3 material.

(I've not actually looked at the patches yet, just the diffstat)

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 07 08:52:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Sep 2012 08:52:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9uI8-0003jw-1t; Fri, 07 Sep 2012 08:51:56 +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 1T9uI6-0003jU-VP
	for xen-devel@lists.xen.org; Fri, 07 Sep 2012 08:51:55 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1347007907!10001635!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTIxNDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7514 invoked from network); 7 Sep 2012 08:51:48 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Sep 2012 08:51:48 -0000
X-IronPort-AV: E=Sophos;i="4.80,384,1344211200"; d="scan'208";a="14403232"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Sep 2012 08:51: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.279.1; Fri, 7 Sep 2012
	09:51:47 +0100
Message-ID: <1347007906.30018.43.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Matt Wilson <msw@amazon.com>
Date: Fri, 7 Sep 2012 09:51:46 +0100
In-Reply-To: <patchbomb.1346992557@u002268147cd4502c336d.ant.amazon.com>
References: <patchbomb.1346992557@u002268147cd4502c336d.ant.amazon.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-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 0 of 2 v3] improve checking for
 documentation tools and formatting
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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-09-07 at 05:35 +0100, Matt Wilson wrote:
> This version addresses feedback from v2. Please let me know if there
> are any other concerns.

In general I think I'm happy to take docs updates right up to the
release, but in this case since it also involves changes to autoconf and
the build system I think is now 4.3 material.

(I've not actually looked at the patches yet, just the diffstat)

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 07 08:53:48 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Sep 2012 08:53:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9uJn-0003qz-Ht; Fri, 07 Sep 2012 08:53: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 1T9uJl-0003qn-L5
	for xen-devel@lists.xensource.com; Fri, 07 Sep 2012 08:53:38 +0000
Received: from [85.158.143.99:4888] by server-1.bemta-4.messagelabs.com id
	C6/5F-12504-016B9405; Fri, 07 Sep 2012 08:53:36 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1347008015!17855966!1
X-Originating-IP: [213.199.154.206]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20738 invoked from network); 7 Sep 2012 08:53:36 -0000
Received: from am1ehsobe003.messaging.microsoft.com (HELO
	am1outboundpool.messaging.microsoft.com) (213.199.154.206)
	by server-16.tower-216.messagelabs.com with AES128-SHA encrypted SMTP;
	7 Sep 2012 08:53:36 -0000
Received: from mail112-am1-R.bigfish.com (10.3.201.250) by
	AM1EHSOBE010.bigfish.com (10.3.204.30) with Microsoft SMTP Server id
	14.1.225.23; Fri, 7 Sep 2012 08:53:35 +0000
Received: from mail112-am1 (localhost [127.0.0.1])	by
	mail112-am1-R.bigfish.com (Postfix) with ESMTP id 2B40A1C0123;
	Fri,  7 Sep 2012 08:53:35 +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: -6
X-BigFish: VPS-6(zzbb2dI98dI9371I936eI1432I4015Izz1202hzz8275bhz2dh668h839hd25he5bhf0ah107ah1288h1155h)
Received: from mail112-am1 (localhost.localdomain [127.0.0.1]) by mail112-am1
	(MessageSwitch) id 1347008013505720_6321;
	Fri,  7 Sep 2012 08:53:33 +0000 (UTC)
Received: from AM1EHSMHS003.bigfish.com (unknown [10.3.201.229])	by
	mail112-am1.bigfish.com (Postfix) with ESMTP id 793E3A0048;
	Fri,  7 Sep 2012 08:53:33 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	AM1EHSMHS003.bigfish.com (10.3.207.103) with Microsoft SMTP Server id
	14.1.225.23; Fri, 7 Sep 2012 08:53:32 +0000
X-WSS-ID: 0M9Z213-02-0K1-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 2ED18C8055;	Fri,  7 Sep 2012 03:53:26 -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;
	Fri, 7 Sep 2012 03:53:49 -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;
	Fri, 7 Sep 2012 03:53:29 -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, 7 Sep 2012
	04:53:28 -0400
Received: from [165.204.15.57] (gran.osrc.amd.com [165.204.15.57])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id BBE5849C5E4; Fri,  7 Sep 2012
	09:53:26 +0100 (BST)
Message-ID: <5049B650.4080101@amd.com>
Date: Fri, 7 Sep 2012 10:54: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: Sander Eikelenboom <linux@eikelenboom.it>
References: <504764E2.4000809@amd.com>
	<326589347.20120906005936@eikelenboom.it>
	<5048A603.3070207@amd.com>
	<483486315.20120906155001@eikelenboom.it>
	<5048BB29.4040900@amd.com>
	<488803362.20120907093241@eikelenboom.it>
In-Reply-To: <488803362.20120907093241@eikelenboom.it>
X-OriginatorOrg: amd.com
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH] amd iommu: Dump flags of IO page faults
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 09/07/2012 09:32 AM, Sander Eikelenboom wrote:
>
> Thursday, September 6, 2012, 5:03:05 PM, you wrote:
>
>> On 09/06/2012 03:50 PM, Sander Eikelenboom wrote:
>>>
>>> Thursday, September 6, 2012, 3:32:51 PM, you wrote:
>>>
>>>> On 09/06/2012 12:59 AM, Sander Eikelenboom wrote:
>>>>>
>>>>> Wednesday, September 5, 2012, 4:42:42 PM, you wrote:
>>>>>
>>>>>> Hi Jan,
>>>>>> Attached patch dumps io page fault flags. The flags show the reason of
>>>>>> the fault and tell us if this is an unmapped interrupt fault or a DMA fault.
>>>>>
>>>>>> Thanks,
>>>>>> Wei
>>>>>
>>>>>> signed-off-by: Wei Wang<wei.wang2@amd.com>
>>>>>
>>>>>
>>>>> I have applied the patch and the flags seem to differ between the faults:
>>>>>
>>>>> AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0a06, fault address = 0xc2c2c2c0, flags = 0x000
>>>>> (XEN) [2012-09-05 20:54:16] AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0a06, fault address = 0xc2c2c2c0, flags = 0x000
>>>>> (XEN) [2012-09-05 20:54:16] AMD-Vi: IO_PAGE_FAULT: domain = 14, device id = 0x0700, fault address = 0xa8d339e0, flags = 0x020
>>>>> (XEN) [2012-09-05 20:54:16] AMD-Vi: IO_PAGE_FAULT: domain = 14, device id = 0x0700, fault address = 0xa8d33a40, flags = 0x020
>>>
>>>> OK, so they are not interrupt requests. I guess further information from
>>>> your system would be helpful to debug this issue:
>>>> 1) xl info
>>>> 2) xl list
>>>> 3) lscpi -vvv (NOTE: not in dom0 but in your guest)
>>>> 4) cat /proc/iomem (in both dom0 and your hvm guest)
>>>
>>> dom14 is not a HVM guest,it's a PV guest.
>
>> Ah, I see. PV guest is quite different than hvm, it does use p2m tables
>> as io page tables. So no-sharept option does not work in this case. PV
>> guests always use separated io page tables. There might be some
>> incorrect mappings on the page tables. I will check this on my side.
>
> I have reverted the machine to xen-4.1.4-pre (changeset 23353) and kept everything else the same.
> I haven't seen any IO PAGE FAULTS after that.
>
> I did spot some differences in the output from lspci between xen 4.1 and 4.2, related to MSI enabled or not for the IOMMU device.
> Have attached the xl/xm dmesg and lspci from booting with both versions.
>
> lspci:
>
> 00:00.2 Generic system peripheral [0806]: ATI Technologies Inc RD990 I/O Memory Management Unit (IOMMU) [1002:5a23]
>          Subsystem: ATI Technologies Inc RD990 I/O Memory Management Unit (IOMMU) [1002:5a23]
>          Control: I/O- Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
>          Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast>TAbort-<TAbort-<MAbort->SERR-<PERR- INTx-
>          Latency: 0
>          Interrupt: pin A routed to IRQ 10
>          Capabilities: [40] Secure device<?>
> 4.1:    Capabilities: [54] MSI: Enable- Count=1/1 Maskable- 64bit+

Eh... That is interesting. So which dom0 are you using?  There is a c/s 
in 4.2 to prevent recent dom0 to disable iommu interrupt (changeset 
25492:61844569a432) Otherwise, iommu cannot send any events including IO 
PAGE faults. You could try to revert dom0 to an old version like 2.6 
pv_ops to see if you really have no io page faults on 4.1


> 4.2:    Capabilities: [54] MSI: Enable+ Count=1/1 Maskable- 64bit+
>                  Address: 00000000fee0100c  Data: 4128
>          Capabilities: [64] HyperTransport: MSI Mapping Enable+ Fixed+
>
> Although it seems enabled, shouldn't the IRQ number used be much higher than 10 for MSI interrupts ?

The IRQ number is fine. MSI vector is stored at  Data: 4128

>
> There is another difference in the bridge device that's in front of the  0a:00.6 device that faults before the kernel is even booted.
>
> 00:03.0 PCI bridge [0604]: ATI Technologies Inc RD890 PCI to PCI bridge (PCI express gpp port C) [1002:5a17] (prog-if 00 [Normal decode])
>          Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx+
> 4.1:    Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast>TAbort-<TAbort-<MAbort->SERR-<PERR- INTx-
> 4.2:    Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast>TAbort-<TAbort+<MAbort->SERR-<PERR- INTx-
>          Latency: 0, Cache Line Size: 64 bytes
>          Bus: primary=00, secondary=0a, subordinate=0a, sec-latency=0
>          I/O behind bridge: 0000f000-00000fff
>          Memory behind bridge: f9f00000-f9ffffff
>          Prefetchable memory behind bridge: 00000000fff00000-00000000000fffff
> 4.1:    Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast>TAbort-<TAbort-<MAbort-<SERR-<PERR-
> 4.2:    Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast>TAbort+<TAbort-<MAbort-<SERR-<PERR-
>          BridgeCtl: Parity+ SERR+ NoISA+ VGA- MAbort->Reset- FastB2B-
>                  PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
>          Capabilities: [50] Power Management version 3
>                  Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
>                  Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
>          Capabilities: [58] Express (v2) Root Port (Slot+), MSI 00
>                  DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s<64ns, L1<1us
>                          ExtTag+ RBE+ FLReset-
>                  DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
>                          RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+
>                          MaxPayload 128 bytes, MaxReadReq 128 bytes
>                  DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr- TransPend-
>                  LnkCap: Port #1, Speed 5GT/s, Width x8, ASPM L0s L1, Latency L0<1us, L1<8us
>                          ClockPM- Surprise- LLActRep+ BwNot+
>                  LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommClk-
>                          ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
>                  LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive+ BWMgmt+ ABWMgmt-
>                  SltCap: AttnBtn- PwrCtrl- MRL- AttnInd- PwrInd- HotPlug- Surprise-
>                          Slot #3, PowerLimit 10.000W; Interlock- NoCompl+
>                  SltCtl: Enable: AttnBtn- PwrFlt- MRL- PresDet- CmdCplt- HPIrq- LinkChg-
>                          Control: AttnInd Unknown, PwrInd Unknown, Power- Interlock-
>                  SltSta: Status: AttnBtn- PowerFlt- MRL- CmdCplt- PresDet+ Interlock-
>                          Changed: MRL- PresDet+ LinkState+

The probably because of the IO_PAGE_FAULT.

Thanks,
Wei

> serveerstertje:~# lspci -t
> -[0000:00]-+-00.0
>             +-00.2
>             +-02.0-[0b]----00.0
>             +-03.0-[0a]--+-00.0
>             |            +-00.1
>             |            +-00.2
>             |            +-00.3
>             |            +-00.4
>             |            +-00.5
>             |            +-00.6
>             |            \-00.7
>             +-05.0-[09]----00.0
>             +-06.0-[08]----00.0
>             +-0a.0-[07]----00.0
>             +-0b.0-[06]--+-00.0
>             |            \-00.1
>             +-0c.0-[05]----00.0
>             +-0d.0-[04]--+-00.0
>             |            +-00.1
>             |            +-00.2
>             |            +-00.3
>             |            +-00.4
>             |            +-00.5
>             |            +-00.6
>             |            \-00.7
>             +-11.0
>             +-12.0
>             +-12.2
>             +-13.0
>             +-13.2
>             +-14.0
>             +-14.3
>             +-14.4-[03]----06.0
>             +-14.5
>             +-15.0-[02]--
>             +-16.0
>             +-16.2
>             +-18.0
>             +-18.1
>             +-18.2
>             +-18.3
>             \-18.4
>
>
>
>
>
>> Thanks,
>> Wei
>
>>> I will try to make a complete package, and try with one pv domain only where the devices are being passed through just to simplify the setup.
>>>
>>>
>>>> * I would also like to know the symptoms of device 0x0700 when IO_PF
>>>> happened. Did it stop working?
>>>
>>> Yes it stops working, the video capture just freezes, but the driver doesn't bail out.
>>> For the USB controller (0x0a06) it starts to give errors for usbdev_open in the guest.
>>>
>>>> (BTW: I copied a few options from your boot cmd line and it worked with
>>>> my RD890 system
>>>
>>>> dom0_mem=1024M,max:1024M loglvl=all loglvl_guest=all console_timestamps
>>>> cpuidle cpufreq=xen noreboot debug lapic=debug apic_verbosity=debug
>>>> apic=debug iommu=on,verbose,debug,no-sharept
>>>
>>>> * so, what OEM board you have?)
>>>
>>> MSI 890FXA-GD70
>>>
>>>> Also from your log, these lines looks very strange:
>>>
>>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>>>> read-only memory page. gfn=0xd5, mfn=0xa4a11
>>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>>>> read-only memory page. gfn=0xd7, mfn=0xa4a0f
>>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>>>> read-only memory page. gfn=0xd9, mfn=0xa4a0d
>>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>>>> read-only memory page. gfn=0xdb, mfn=0xa4a0b
>>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>>>> read-only memory page. gfn=0xdd, mfn=0xa4a09
>>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>>>> read-only memory page. gfn=0xdf, mfn=0xa4a07
>>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>>>> read-only memory page. gfn=0xe1, mfn=0xa4a05
>>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>>>> read-only memory page. gfn=0xe3, mfn=0xa4a03
>>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>>>> read-only memory page. gfn=0xe5, mfn=0xa4a01
>>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>>>> read-only memory page. gfn=0xe7, mfn=0xa463f
>>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>>>> read-only memory page. gfn=0xe9, mfn=0xa463d
>>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>>>> read-only memory page. gfn=0xeb, mfn=0xa463b
>>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>>>> read-only memory page. gfn=0xed, mfn=0xa4639
>>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>>>> read-only memory page. gfn=0xef, mfn=0xa4637
>>>> (XEN) [2012-09-04 16:13:56] AMD-Vi: IO_PAGE_FAULT: domain = 0, device id
>>>> = 0x0a06, fault address = 0xc2c2c2c0
>>>> (XEN) [2012-09-04 16:13:56] AMD-Vi: IO_PAGE_FAULT: domain = 14, device
>>>> id = 0x0700, fault address = 0xa90f8300
>>>> (XEN) [2012-09-04 16:13:56] AMD-Vi: IO_PAGE_FAULT: domain = 14, device
>>>> id = 0x0700, fault address = 0xa90f8340
>>>> (XEN) [2012-09-04 16:13:56] AMD-Vi: IO_PAGE_FAULT: domain = 14, device
>>>> id = 0x0700, fault address = 0xa90f8380
>>>> (XEN) [2012-09-04 16:13:56] AMD-Vi: IO_PAGE_FAULT: domain = 14, device
>>>> id = 0x0700, fault address = 0xa90f83c0
>>>
>>>> * they are just followed by the IO PAGE fault. Do you know where are
>>>> they from? Your video card driver maybe?
>>>
>>>    From a HVM domain with a old (3.0.3) kernel, but the faults also occur without this domain being started.
>>>
>>>
>>>> Thanks,
>>>> Wei
>>>
>>>
>>>>> Complete xl dmesg and lspci -vvvknn attached.
>>>>>
>>>>> Thx
>>>>>
>>>>> --
>>>>> Sander
>>>
>>>
>>>
>>>
>>>
>
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 07 08:53:48 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Sep 2012 08:53:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9uJn-0003qz-Ht; Fri, 07 Sep 2012 08:53: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 1T9uJl-0003qn-L5
	for xen-devel@lists.xensource.com; Fri, 07 Sep 2012 08:53:38 +0000
Received: from [85.158.143.99:4888] by server-1.bemta-4.messagelabs.com id
	C6/5F-12504-016B9405; Fri, 07 Sep 2012 08:53:36 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1347008015!17855966!1
X-Originating-IP: [213.199.154.206]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20738 invoked from network); 7 Sep 2012 08:53:36 -0000
Received: from am1ehsobe003.messaging.microsoft.com (HELO
	am1outboundpool.messaging.microsoft.com) (213.199.154.206)
	by server-16.tower-216.messagelabs.com with AES128-SHA encrypted SMTP;
	7 Sep 2012 08:53:36 -0000
Received: from mail112-am1-R.bigfish.com (10.3.201.250) by
	AM1EHSOBE010.bigfish.com (10.3.204.30) with Microsoft SMTP Server id
	14.1.225.23; Fri, 7 Sep 2012 08:53:35 +0000
Received: from mail112-am1 (localhost [127.0.0.1])	by
	mail112-am1-R.bigfish.com (Postfix) with ESMTP id 2B40A1C0123;
	Fri,  7 Sep 2012 08:53:35 +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: -6
X-BigFish: VPS-6(zzbb2dI98dI9371I936eI1432I4015Izz1202hzz8275bhz2dh668h839hd25he5bhf0ah107ah1288h1155h)
Received: from mail112-am1 (localhost.localdomain [127.0.0.1]) by mail112-am1
	(MessageSwitch) id 1347008013505720_6321;
	Fri,  7 Sep 2012 08:53:33 +0000 (UTC)
Received: from AM1EHSMHS003.bigfish.com (unknown [10.3.201.229])	by
	mail112-am1.bigfish.com (Postfix) with ESMTP id 793E3A0048;
	Fri,  7 Sep 2012 08:53:33 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	AM1EHSMHS003.bigfish.com (10.3.207.103) with Microsoft SMTP Server id
	14.1.225.23; Fri, 7 Sep 2012 08:53:32 +0000
X-WSS-ID: 0M9Z213-02-0K1-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 2ED18C8055;	Fri,  7 Sep 2012 03:53:26 -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;
	Fri, 7 Sep 2012 03:53:49 -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;
	Fri, 7 Sep 2012 03:53:29 -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, 7 Sep 2012
	04:53:28 -0400
Received: from [165.204.15.57] (gran.osrc.amd.com [165.204.15.57])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id BBE5849C5E4; Fri,  7 Sep 2012
	09:53:26 +0100 (BST)
Message-ID: <5049B650.4080101@amd.com>
Date: Fri, 7 Sep 2012 10:54: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: Sander Eikelenboom <linux@eikelenboom.it>
References: <504764E2.4000809@amd.com>
	<326589347.20120906005936@eikelenboom.it>
	<5048A603.3070207@amd.com>
	<483486315.20120906155001@eikelenboom.it>
	<5048BB29.4040900@amd.com>
	<488803362.20120907093241@eikelenboom.it>
In-Reply-To: <488803362.20120907093241@eikelenboom.it>
X-OriginatorOrg: amd.com
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH] amd iommu: Dump flags of IO page faults
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 09/07/2012 09:32 AM, Sander Eikelenboom wrote:
>
> Thursday, September 6, 2012, 5:03:05 PM, you wrote:
>
>> On 09/06/2012 03:50 PM, Sander Eikelenboom wrote:
>>>
>>> Thursday, September 6, 2012, 3:32:51 PM, you wrote:
>>>
>>>> On 09/06/2012 12:59 AM, Sander Eikelenboom wrote:
>>>>>
>>>>> Wednesday, September 5, 2012, 4:42:42 PM, you wrote:
>>>>>
>>>>>> Hi Jan,
>>>>>> Attached patch dumps io page fault flags. The flags show the reason of
>>>>>> the fault and tell us if this is an unmapped interrupt fault or a DMA fault.
>>>>>
>>>>>> Thanks,
>>>>>> Wei
>>>>>
>>>>>> signed-off-by: Wei Wang<wei.wang2@amd.com>
>>>>>
>>>>>
>>>>> I have applied the patch and the flags seem to differ between the faults:
>>>>>
>>>>> AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0a06, fault address = 0xc2c2c2c0, flags = 0x000
>>>>> (XEN) [2012-09-05 20:54:16] AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0a06, fault address = 0xc2c2c2c0, flags = 0x000
>>>>> (XEN) [2012-09-05 20:54:16] AMD-Vi: IO_PAGE_FAULT: domain = 14, device id = 0x0700, fault address = 0xa8d339e0, flags = 0x020
>>>>> (XEN) [2012-09-05 20:54:16] AMD-Vi: IO_PAGE_FAULT: domain = 14, device id = 0x0700, fault address = 0xa8d33a40, flags = 0x020
>>>
>>>> OK, so they are not interrupt requests. I guess further information from
>>>> your system would be helpful to debug this issue:
>>>> 1) xl info
>>>> 2) xl list
>>>> 3) lscpi -vvv (NOTE: not in dom0 but in your guest)
>>>> 4) cat /proc/iomem (in both dom0 and your hvm guest)
>>>
>>> dom14 is not a HVM guest,it's a PV guest.
>
>> Ah, I see. PV guest is quite different than hvm, it does use p2m tables
>> as io page tables. So no-sharept option does not work in this case. PV
>> guests always use separated io page tables. There might be some
>> incorrect mappings on the page tables. I will check this on my side.
>
> I have reverted the machine to xen-4.1.4-pre (changeset 23353) and kept everything else the same.
> I haven't seen any IO PAGE FAULTS after that.
>
> I did spot some differences in the output from lspci between xen 4.1 and 4.2, related to MSI enabled or not for the IOMMU device.
> Have attached the xl/xm dmesg and lspci from booting with both versions.
>
> lspci:
>
> 00:00.2 Generic system peripheral [0806]: ATI Technologies Inc RD990 I/O Memory Management Unit (IOMMU) [1002:5a23]
>          Subsystem: ATI Technologies Inc RD990 I/O Memory Management Unit (IOMMU) [1002:5a23]
>          Control: I/O- Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
>          Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast>TAbort-<TAbort-<MAbort->SERR-<PERR- INTx-
>          Latency: 0
>          Interrupt: pin A routed to IRQ 10
>          Capabilities: [40] Secure device<?>
> 4.1:    Capabilities: [54] MSI: Enable- Count=1/1 Maskable- 64bit+

Eh... That is interesting. So which dom0 are you using?  There is a c/s 
in 4.2 to prevent recent dom0 to disable iommu interrupt (changeset 
25492:61844569a432) Otherwise, iommu cannot send any events including IO 
PAGE faults. You could try to revert dom0 to an old version like 2.6 
pv_ops to see if you really have no io page faults on 4.1


> 4.2:    Capabilities: [54] MSI: Enable+ Count=1/1 Maskable- 64bit+
>                  Address: 00000000fee0100c  Data: 4128
>          Capabilities: [64] HyperTransport: MSI Mapping Enable+ Fixed+
>
> Although it seems enabled, shouldn't the IRQ number used be much higher than 10 for MSI interrupts ?

The IRQ number is fine. MSI vector is stored at  Data: 4128

>
> There is another difference in the bridge device that's in front of the  0a:00.6 device that faults before the kernel is even booted.
>
> 00:03.0 PCI bridge [0604]: ATI Technologies Inc RD890 PCI to PCI bridge (PCI express gpp port C) [1002:5a17] (prog-if 00 [Normal decode])
>          Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx+
> 4.1:    Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast>TAbort-<TAbort-<MAbort->SERR-<PERR- INTx-
> 4.2:    Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast>TAbort-<TAbort+<MAbort->SERR-<PERR- INTx-
>          Latency: 0, Cache Line Size: 64 bytes
>          Bus: primary=00, secondary=0a, subordinate=0a, sec-latency=0
>          I/O behind bridge: 0000f000-00000fff
>          Memory behind bridge: f9f00000-f9ffffff
>          Prefetchable memory behind bridge: 00000000fff00000-00000000000fffff
> 4.1:    Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast>TAbort-<TAbort-<MAbort-<SERR-<PERR-
> 4.2:    Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast>TAbort+<TAbort-<MAbort-<SERR-<PERR-
>          BridgeCtl: Parity+ SERR+ NoISA+ VGA- MAbort->Reset- FastB2B-
>                  PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
>          Capabilities: [50] Power Management version 3
>                  Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
>                  Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
>          Capabilities: [58] Express (v2) Root Port (Slot+), MSI 00
>                  DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s<64ns, L1<1us
>                          ExtTag+ RBE+ FLReset-
>                  DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
>                          RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+
>                          MaxPayload 128 bytes, MaxReadReq 128 bytes
>                  DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr- TransPend-
>                  LnkCap: Port #1, Speed 5GT/s, Width x8, ASPM L0s L1, Latency L0<1us, L1<8us
>                          ClockPM- Surprise- LLActRep+ BwNot+
>                  LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommClk-
>                          ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
>                  LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive+ BWMgmt+ ABWMgmt-
>                  SltCap: AttnBtn- PwrCtrl- MRL- AttnInd- PwrInd- HotPlug- Surprise-
>                          Slot #3, PowerLimit 10.000W; Interlock- NoCompl+
>                  SltCtl: Enable: AttnBtn- PwrFlt- MRL- PresDet- CmdCplt- HPIrq- LinkChg-
>                          Control: AttnInd Unknown, PwrInd Unknown, Power- Interlock-
>                  SltSta: Status: AttnBtn- PowerFlt- MRL- CmdCplt- PresDet+ Interlock-
>                          Changed: MRL- PresDet+ LinkState+

The probably because of the IO_PAGE_FAULT.

Thanks,
Wei

> serveerstertje:~# lspci -t
> -[0000:00]-+-00.0
>             +-00.2
>             +-02.0-[0b]----00.0
>             +-03.0-[0a]--+-00.0
>             |            +-00.1
>             |            +-00.2
>             |            +-00.3
>             |            +-00.4
>             |            +-00.5
>             |            +-00.6
>             |            \-00.7
>             +-05.0-[09]----00.0
>             +-06.0-[08]----00.0
>             +-0a.0-[07]----00.0
>             +-0b.0-[06]--+-00.0
>             |            \-00.1
>             +-0c.0-[05]----00.0
>             +-0d.0-[04]--+-00.0
>             |            +-00.1
>             |            +-00.2
>             |            +-00.3
>             |            +-00.4
>             |            +-00.5
>             |            +-00.6
>             |            \-00.7
>             +-11.0
>             +-12.0
>             +-12.2
>             +-13.0
>             +-13.2
>             +-14.0
>             +-14.3
>             +-14.4-[03]----06.0
>             +-14.5
>             +-15.0-[02]--
>             +-16.0
>             +-16.2
>             +-18.0
>             +-18.1
>             +-18.2
>             +-18.3
>             \-18.4
>
>
>
>
>
>> Thanks,
>> Wei
>
>>> I will try to make a complete package, and try with one pv domain only where the devices are being passed through just to simplify the setup.
>>>
>>>
>>>> * I would also like to know the symptoms of device 0x0700 when IO_PF
>>>> happened. Did it stop working?
>>>
>>> Yes it stops working, the video capture just freezes, but the driver doesn't bail out.
>>> For the USB controller (0x0a06) it starts to give errors for usbdev_open in the guest.
>>>
>>>> (BTW: I copied a few options from your boot cmd line and it worked with
>>>> my RD890 system
>>>
>>>> dom0_mem=1024M,max:1024M loglvl=all loglvl_guest=all console_timestamps
>>>> cpuidle cpufreq=xen noreboot debug lapic=debug apic_verbosity=debug
>>>> apic=debug iommu=on,verbose,debug,no-sharept
>>>
>>>> * so, what OEM board you have?)
>>>
>>> MSI 890FXA-GD70
>>>
>>>> Also from your log, these lines looks very strange:
>>>
>>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>>>> read-only memory page. gfn=0xd5, mfn=0xa4a11
>>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>>>> read-only memory page. gfn=0xd7, mfn=0xa4a0f
>>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>>>> read-only memory page. gfn=0xd9, mfn=0xa4a0d
>>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>>>> read-only memory page. gfn=0xdb, mfn=0xa4a0b
>>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>>>> read-only memory page. gfn=0xdd, mfn=0xa4a09
>>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>>>> read-only memory page. gfn=0xdf, mfn=0xa4a07
>>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>>>> read-only memory page. gfn=0xe1, mfn=0xa4a05
>>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>>>> read-only memory page. gfn=0xe3, mfn=0xa4a03
>>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>>>> read-only memory page. gfn=0xe5, mfn=0xa4a01
>>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>>>> read-only memory page. gfn=0xe7, mfn=0xa463f
>>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>>>> read-only memory page. gfn=0xe9, mfn=0xa463d
>>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>>>> read-only memory page. gfn=0xeb, mfn=0xa463b
>>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>>>> read-only memory page. gfn=0xed, mfn=0xa4639
>>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>>>> read-only memory page. gfn=0xef, mfn=0xa4637
>>>> (XEN) [2012-09-04 16:13:56] AMD-Vi: IO_PAGE_FAULT: domain = 0, device id
>>>> = 0x0a06, fault address = 0xc2c2c2c0
>>>> (XEN) [2012-09-04 16:13:56] AMD-Vi: IO_PAGE_FAULT: domain = 14, device
>>>> id = 0x0700, fault address = 0xa90f8300
>>>> (XEN) [2012-09-04 16:13:56] AMD-Vi: IO_PAGE_FAULT: domain = 14, device
>>>> id = 0x0700, fault address = 0xa90f8340
>>>> (XEN) [2012-09-04 16:13:56] AMD-Vi: IO_PAGE_FAULT: domain = 14, device
>>>> id = 0x0700, fault address = 0xa90f8380
>>>> (XEN) [2012-09-04 16:13:56] AMD-Vi: IO_PAGE_FAULT: domain = 14, device
>>>> id = 0x0700, fault address = 0xa90f83c0
>>>
>>>> * they are just followed by the IO PAGE fault. Do you know where are
>>>> they from? Your video card driver maybe?
>>>
>>>    From a HVM domain with a old (3.0.3) kernel, but the faults also occur without this domain being started.
>>>
>>>
>>>> Thanks,
>>>> Wei
>>>
>>>
>>>>> Complete xl dmesg and lspci -vvvknn attached.
>>>>>
>>>>> Thx
>>>>>
>>>>> --
>>>>> Sander
>>>
>>>
>>>
>>>
>>>
>
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 07 08:58:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Sep 2012 08: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 1T9uO2-00044y-8x; Fri, 07 Sep 2012 08:58:02 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1T9uNz-00044t-Te
	for xen-devel@lists.xensource.com; Fri, 07 Sep 2012 08:58:00 +0000
Received: from [85.158.143.99:62905] by server-3.bemta-4.messagelabs.com id
	1C/38-08232-717B9405; Fri, 07 Sep 2012 08:57:59 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1347008278!21536578!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTIxNDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27443 invoked from network); 7 Sep 2012 08:57:58 -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 Sep 2012 08:57:58 -0000
X-IronPort-AV: E=Sophos;i="4.80,384,1344211200"; d="scan'208";a="14403401"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Sep 2012 08:57:33 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Fri, 7 Sep 2012
	09:57:33 +0100
Message-ID: <1347008251.30018.46.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Sander Eikelenboom <linux@eikelenboom.it>
Date: Fri, 7 Sep 2012 09:57:31 +0100
In-Reply-To: <780eae92908a911f63f7.1346960488@xentest.example.org>
References: <patchbomb.1346960486@xentest.example.org>
	<780eae92908a911f63f7.1346960488@xentest.example.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 2 of 3] xl: Introduce reboot xm
 compatibility option -a and -w
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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-09-06 at 20:41 +0100, Sander Eikelenboom wrote:
> * Add missing option -a to reboot all guest domains
>   * Add missing option -w to wait for the domain to reboot before returning

If, as I suspect, the code to do this waiting is a cut-and-paste of the
same code in the shutdown case please can you refactor it into
domain_wait_shutdown and call it from both places.

> 
> 
> Signed-off-by: Sander Eikelenboom <linux@eikelenboom.it>
> 
> diff -r 4c3d49787cea -r 780eae92908a docs/man/xl.pod.1
> --- a/docs/man/xl.pod.1	Thu Sep 06 21:36:14 2012 +0200
> +++ b/docs/man/xl.pod.1	Thu Sep 06 21:36:41 2012 +0200
> @@ -432,7 +432,7 @@ Pause a domain.  When in a paused state 
>  allocated resources such as memory, but will not be eligible for
>  scheduling by the Xen hypervisor.
>  
> -=item B<reboot> [I<OPTIONS>] I<domain-id>
> +=item B<reboot> [I<OPTIONS>] I<-a|domain-id>
>  
>  Reboot a domain.  This acts just as if the domain had the B<reboot>
>  command run from the console.  The command returns as soon as it has
> @@ -452,6 +452,12 @@ B<OPTIONS>
>  
>  =over 4
>  
> +-a  Shutdown all guest domains.  Often used when doing a complete shutdown of a Xen system.

Please can you wrap to < 80 columns. (and in patch 1/3 and your commit
messages too)

Thanks,
Ian.

> +
> +=item B<-w>
> +
> +Wait for the domain to complete shutdown before returning.
> +
>  =item B<-F>
>  
>  If the guest does not support PV reboot control then fallback to
> diff -r 4c3d49787cea -r 780eae92908a tools/libxl/xl_cmdimpl.c
> --- a/tools/libxl/xl_cmdimpl.c	Thu Sep 06 21:36:14 2012 +0200
> +++ b/tools/libxl/xl_cmdimpl.c	Thu Sep 06 21:36:41 2012 +0200
> @@ -2743,11 +2743,14 @@ static void shutdown_domain(uint32_t dom
>      }
>  }
>  
> -static void reboot_domain(const char *p, int fallback_trigger)
> +static void reboot_domain(uint32_t domain_id, int wait, int fallback_trigger)
>  {
>      int rc;
> -    find_domain(p);
> -    rc=libxl_domain_reboot(ctx, domid);
> +    libxl_event *event;
> +
> +    domid = domain_id;
> +    rc = libxl_domain_reboot(ctx, domid);
> +    
>      if (rc == ERROR_NOPARAVIRT) {
>          if (fallback_trigger) {
>              fprintf(stderr, "PV control interface not available:"
> @@ -2762,6 +2765,42 @@ static void reboot_domain(const char *p,
>      if (rc) {
>          fprintf(stderr,"reboot failed (rc=%d)\n",rc);exit(-1);
>      }
> +
> +    if (wait) {
> +        libxl_evgen_domain_death *deathw;
> +
> +        rc = libxl_evenable_domain_death(ctx, domid, 0, &deathw);
> +        if (rc) {
> +            fprintf(stderr,"wait for death failed (evgen, rc=%d)\n",rc);
> +            exit(-1);
> +        }
> +
> +        for (;;) {
> +            rc = domain_wait_event(&event);
> +            if (rc) exit(-1);
> +
> +            switch (event->type) {
> +
> +            case LIBXL_EVENT_TYPE_DOMAIN_DEATH:
> +                LOG("Domain %d has been destroyed", domid);
> +                goto done;
> +
> +            case LIBXL_EVENT_TYPE_DOMAIN_SHUTDOWN:
> +                LOG("Domain %d has been shut down, reason code %d %x", domid,
> +                    event->u.domain_shutdown.shutdown_reason,
> +                    event->u.domain_shutdown.shutdown_reason);
> +                goto done;
> +
> +            default:
> +                LOG("Unexpected event type %d", event->type);
> +                break;
> +            }
> +            libxl_event_free(ctx, event);
> +        }
> +    done:
> +        libxl_event_free(ctx, event);
> +        libxl_evdisable_domain_death(ctx, deathw);
> +    }
>  }
>  
>  static void list_domains_details(const libxl_dominfo *info, int nb_domain)
> @@ -3722,20 +3761,52 @@ int main_shutdown(int argc, char **argv)
>  
>  int main_reboot(int argc, char **argv)
>  {
> -    int opt;
> +    libxl_dominfo *dominfo;
> +    int opt, i, nb_domain;
> +    int all = 0;
> +    int wait = 0;
>      int fallback_trigger = 0;
>  
> -    while ((opt = def_getopt(argc, argv, "F", "reboot", 1)) != -1) {
> +    while ((opt = def_getopt(argc, argv, "awF", "reboot", 0)) != -1) {
>          switch (opt) {
>          case 0: case 2:
>              return opt;
> +        case 'a':
> +            all = 1;
> +            break;
> +        case 'w':
> +            wait = 1;
> +            break;
>          case 'F':
>              fallback_trigger = 1;
>              break;
>          }
>      }
>  
> -    reboot_domain(argv[optind], fallback_trigger);
> +    if (!argv[optind] && !all) {
> +        fprintf(stderr, "You must specify -a or a domain id.\n\n");
> +        return opt;
> +    }
> +
> +    if (all) {
> +        if (!(dominfo = libxl_list_domain(ctx, &nb_domain))) {
> +            fprintf(stderr, "libxl_list_domain failed.\n");
> +            return -1;
> +        }
> +
> +        for (i = 0; i<nb_domain; i++) {
> +            if (dominfo[i].domid == 0)
> +                continue;
> +
> +            reboot_domain(dominfo[i].domid, wait, fallback_trigger);
> +        }
> +
> +        libxl_dominfo_list_free(dominfo, nb_domain);
> +    } else {
> +        find_domain(argv[optind]);
> +        reboot_domain(domid, wait, fallback_trigger);
> +    }
> +
>      return 0;
>  }
>  
> diff -r 4c3d49787cea -r 780eae92908a tools/libxl/xl_cmdtable.c
> --- a/tools/libxl/xl_cmdtable.c	Thu Sep 06 21:36:14 2012 +0200
> +++ b/tools/libxl/xl_cmdtable.c	Thu Sep 06 21:36:41 2012 +0200
> @@ -70,10 +70,12 @@ struct cmd_spec cmd_table[] = {
>      { "reboot",
>        &main_reboot, 0, 1,
>        "Issue a reboot signal to a domain",
> -      "[options] <Domain>",
> +      "[options] <-a|Domain>",
> +      "-a                      Reboot all guest domains.\n"
>        "-h                      Print this help.\n"
>        "-F                      Fallback to ACPI reset event for HVM guests with\n"
>        "                        no PV drivers.\n"
> +      "-w                      Wait for guest to reboot.\n"
>      },
>      { "pci-attach",
>        &main_pciattach, 0, 1,



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 07 08:58:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Sep 2012 08: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 1T9uO2-00044y-8x; Fri, 07 Sep 2012 08:58:02 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1T9uNz-00044t-Te
	for xen-devel@lists.xensource.com; Fri, 07 Sep 2012 08:58:00 +0000
Received: from [85.158.143.99:62905] by server-3.bemta-4.messagelabs.com id
	1C/38-08232-717B9405; Fri, 07 Sep 2012 08:57:59 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1347008278!21536578!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTIxNDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27443 invoked from network); 7 Sep 2012 08:57:58 -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 Sep 2012 08:57:58 -0000
X-IronPort-AV: E=Sophos;i="4.80,384,1344211200"; d="scan'208";a="14403401"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Sep 2012 08:57:33 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Fri, 7 Sep 2012
	09:57:33 +0100
Message-ID: <1347008251.30018.46.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Sander Eikelenboom <linux@eikelenboom.it>
Date: Fri, 7 Sep 2012 09:57:31 +0100
In-Reply-To: <780eae92908a911f63f7.1346960488@xentest.example.org>
References: <patchbomb.1346960486@xentest.example.org>
	<780eae92908a911f63f7.1346960488@xentest.example.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 2 of 3] xl: Introduce reboot xm
 compatibility option -a and -w
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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-09-06 at 20:41 +0100, Sander Eikelenboom wrote:
> * Add missing option -a to reboot all guest domains
>   * Add missing option -w to wait for the domain to reboot before returning

If, as I suspect, the code to do this waiting is a cut-and-paste of the
same code in the shutdown case please can you refactor it into
domain_wait_shutdown and call it from both places.

> 
> 
> Signed-off-by: Sander Eikelenboom <linux@eikelenboom.it>
> 
> diff -r 4c3d49787cea -r 780eae92908a docs/man/xl.pod.1
> --- a/docs/man/xl.pod.1	Thu Sep 06 21:36:14 2012 +0200
> +++ b/docs/man/xl.pod.1	Thu Sep 06 21:36:41 2012 +0200
> @@ -432,7 +432,7 @@ Pause a domain.  When in a paused state 
>  allocated resources such as memory, but will not be eligible for
>  scheduling by the Xen hypervisor.
>  
> -=item B<reboot> [I<OPTIONS>] I<domain-id>
> +=item B<reboot> [I<OPTIONS>] I<-a|domain-id>
>  
>  Reboot a domain.  This acts just as if the domain had the B<reboot>
>  command run from the console.  The command returns as soon as it has
> @@ -452,6 +452,12 @@ B<OPTIONS>
>  
>  =over 4
>  
> +-a  Shutdown all guest domains.  Often used when doing a complete shutdown of a Xen system.

Please can you wrap to < 80 columns. (and in patch 1/3 and your commit
messages too)

Thanks,
Ian.

> +
> +=item B<-w>
> +
> +Wait for the domain to complete shutdown before returning.
> +
>  =item B<-F>
>  
>  If the guest does not support PV reboot control then fallback to
> diff -r 4c3d49787cea -r 780eae92908a tools/libxl/xl_cmdimpl.c
> --- a/tools/libxl/xl_cmdimpl.c	Thu Sep 06 21:36:14 2012 +0200
> +++ b/tools/libxl/xl_cmdimpl.c	Thu Sep 06 21:36:41 2012 +0200
> @@ -2743,11 +2743,14 @@ static void shutdown_domain(uint32_t dom
>      }
>  }
>  
> -static void reboot_domain(const char *p, int fallback_trigger)
> +static void reboot_domain(uint32_t domain_id, int wait, int fallback_trigger)
>  {
>      int rc;
> -    find_domain(p);
> -    rc=libxl_domain_reboot(ctx, domid);
> +    libxl_event *event;
> +
> +    domid = domain_id;
> +    rc = libxl_domain_reboot(ctx, domid);
> +    
>      if (rc == ERROR_NOPARAVIRT) {
>          if (fallback_trigger) {
>              fprintf(stderr, "PV control interface not available:"
> @@ -2762,6 +2765,42 @@ static void reboot_domain(const char *p,
>      if (rc) {
>          fprintf(stderr,"reboot failed (rc=%d)\n",rc);exit(-1);
>      }
> +
> +    if (wait) {
> +        libxl_evgen_domain_death *deathw;
> +
> +        rc = libxl_evenable_domain_death(ctx, domid, 0, &deathw);
> +        if (rc) {
> +            fprintf(stderr,"wait for death failed (evgen, rc=%d)\n",rc);
> +            exit(-1);
> +        }
> +
> +        for (;;) {
> +            rc = domain_wait_event(&event);
> +            if (rc) exit(-1);
> +
> +            switch (event->type) {
> +
> +            case LIBXL_EVENT_TYPE_DOMAIN_DEATH:
> +                LOG("Domain %d has been destroyed", domid);
> +                goto done;
> +
> +            case LIBXL_EVENT_TYPE_DOMAIN_SHUTDOWN:
> +                LOG("Domain %d has been shut down, reason code %d %x", domid,
> +                    event->u.domain_shutdown.shutdown_reason,
> +                    event->u.domain_shutdown.shutdown_reason);
> +                goto done;
> +
> +            default:
> +                LOG("Unexpected event type %d", event->type);
> +                break;
> +            }
> +            libxl_event_free(ctx, event);
> +        }
> +    done:
> +        libxl_event_free(ctx, event);
> +        libxl_evdisable_domain_death(ctx, deathw);
> +    }
>  }
>  
>  static void list_domains_details(const libxl_dominfo *info, int nb_domain)
> @@ -3722,20 +3761,52 @@ int main_shutdown(int argc, char **argv)
>  
>  int main_reboot(int argc, char **argv)
>  {
> -    int opt;
> +    libxl_dominfo *dominfo;
> +    int opt, i, nb_domain;
> +    int all = 0;
> +    int wait = 0;
>      int fallback_trigger = 0;
>  
> -    while ((opt = def_getopt(argc, argv, "F", "reboot", 1)) != -1) {
> +    while ((opt = def_getopt(argc, argv, "awF", "reboot", 0)) != -1) {
>          switch (opt) {
>          case 0: case 2:
>              return opt;
> +        case 'a':
> +            all = 1;
> +            break;
> +        case 'w':
> +            wait = 1;
> +            break;
>          case 'F':
>              fallback_trigger = 1;
>              break;
>          }
>      }
>  
> -    reboot_domain(argv[optind], fallback_trigger);
> +    if (!argv[optind] && !all) {
> +        fprintf(stderr, "You must specify -a or a domain id.\n\n");
> +        return opt;
> +    }
> +
> +    if (all) {
> +        if (!(dominfo = libxl_list_domain(ctx, &nb_domain))) {
> +            fprintf(stderr, "libxl_list_domain failed.\n");
> +            return -1;
> +        }
> +
> +        for (i = 0; i<nb_domain; i++) {
> +            if (dominfo[i].domid == 0)
> +                continue;
> +
> +            reboot_domain(dominfo[i].domid, wait, fallback_trigger);
> +        }
> +
> +        libxl_dominfo_list_free(dominfo, nb_domain);
> +    } else {
> +        find_domain(argv[optind]);
> +        reboot_domain(domid, wait, fallback_trigger);
> +    }
> +
>      return 0;
>  }
>  
> diff -r 4c3d49787cea -r 780eae92908a tools/libxl/xl_cmdtable.c
> --- a/tools/libxl/xl_cmdtable.c	Thu Sep 06 21:36:14 2012 +0200
> +++ b/tools/libxl/xl_cmdtable.c	Thu Sep 06 21:36:41 2012 +0200
> @@ -70,10 +70,12 @@ struct cmd_spec cmd_table[] = {
>      { "reboot",
>        &main_reboot, 0, 1,
>        "Issue a reboot signal to a domain",
> -      "[options] <Domain>",
> +      "[options] <-a|Domain>",
> +      "-a                      Reboot all guest domains.\n"
>        "-h                      Print this help.\n"
>        "-F                      Fallback to ACPI reset event for HVM guests with\n"
>        "                        no PV drivers.\n"
> +      "-w                      Wait for guest to reboot.\n"
>      },
>      { "pci-attach",
>        &main_pciattach, 0, 1,



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 07 09:01:07 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Sep 2012 09: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 1T9uQr-0004GS-0D; Fri, 07 Sep 2012 09:00:57 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1T9uQp-0004GK-IZ
	for xen-devel@lists.xen.org; Fri, 07 Sep 2012 09:00:55 +0000
Received: from [85.158.143.35:7790] by server-3.bemta-4.messagelabs.com id
	AF/3F-08232-6C7B9405; Fri, 07 Sep 2012 09:00:54 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1347008441!13768486!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM4ODU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8865 invoked from network); 7 Sep 2012 09:00:42 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-3.tower-21.messagelabs.com with SMTP;
	7 Sep 2012 09:00:42 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 07 Sep 2012 10:00:41 +0100
Message-Id: <5049D4100200007800099A91@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 07 Sep 2012 10:01:36 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Konrad Rzeszutek Wilk" <konrad@kernel.org>
References: <1343745804-28028-1-git-send-email-konrad.wilk@oracle.com>
	<20120801155040.GB15812@phenom.dumpdata.com>
	<501A5EF7020000780009219C@nat28.tlf.novell.com>
	<20120802141710.GF16749@phenom.dumpdata.com>
	<20120802160403.02de484e@mantra.us.oracle.com>
	<20120803133001.GA13750@andromeda.dapyr.net>
	<501BF44602000078000928B4@nat28.tlf.novell.com>
	<CAPbh3rsXaqQS9WQQmJ2uQ46LZdyFzkbSodUabGDAyFS+qTEwUg@mail.gmail.com>
	<5028CEE70200007800094623@nat28.tlf.novell.com>
	<50446B5402000078000981F4@nat28.tlf.novell.com>
	<20120906210323.GA303@phenom.dumpdata.com>
In-Reply-To: <20120906210323.GA303@phenom.dumpdata.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: konrad@darnok.org, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Ping: Re: [PATCH] Boot PV guests with more than
 128GB (v2) for 3.7
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.09.12 at 23:03, Konrad Rzeszutek Wilk <konrad@kernel.org> wrote:
> On Mon, Sep 03, 2012 at 07:33:24AM +0100, Jan Beulich wrote:
>> >>> On 13.08.12 at 09:54, "Jan Beulich" <JBeulich@suse.com> wrote:
>> >>>> On 03.08.12 at 16:46, Konrad Rzeszutek Wilk <konrad@darnok.org> wrote:
>> >> Didn't get to it yet. Sorry for top posting. If you have a patch ready I
>> >> can test it on Monday - travelling now.
>> > 
>> > So here's what I was thinking of (compile tested only).
>> 
>> Obviously, if this works, I'd like to see this included in 4.2 (and
>> 4.1-testing).
> 
> No luck. I still get:
> 
> (XEN) Pagetable walk from ffff8800443da070:
> (XEN)  L4[0x110] = 0000009342f95067 0000000000001a0c
> (XEN)  L3[0x001] = 0000000000000000 ffffffffffffffff

And I can't see why. I wasn't able to track down the original
stack trace you saw on the archives - was that identical to
this one (i.e. nothing changed at all)? If so (please forgive
that I'm asking, I just know that I happen to fall into this trap
once in a while myself), did you indeed build and install the
patched tools? In that case, adding some logging to the code
in question is presumably the only alternative, short of
anyone else seeing anything further wrong with that code.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 07 09:01:07 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Sep 2012 09: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 1T9uQr-0004GS-0D; Fri, 07 Sep 2012 09:00:57 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1T9uQp-0004GK-IZ
	for xen-devel@lists.xen.org; Fri, 07 Sep 2012 09:00:55 +0000
Received: from [85.158.143.35:7790] by server-3.bemta-4.messagelabs.com id
	AF/3F-08232-6C7B9405; Fri, 07 Sep 2012 09:00:54 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1347008441!13768486!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM4ODU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8865 invoked from network); 7 Sep 2012 09:00:42 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-3.tower-21.messagelabs.com with SMTP;
	7 Sep 2012 09:00:42 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 07 Sep 2012 10:00:41 +0100
Message-Id: <5049D4100200007800099A91@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 07 Sep 2012 10:01:36 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Konrad Rzeszutek Wilk" <konrad@kernel.org>
References: <1343745804-28028-1-git-send-email-konrad.wilk@oracle.com>
	<20120801155040.GB15812@phenom.dumpdata.com>
	<501A5EF7020000780009219C@nat28.tlf.novell.com>
	<20120802141710.GF16749@phenom.dumpdata.com>
	<20120802160403.02de484e@mantra.us.oracle.com>
	<20120803133001.GA13750@andromeda.dapyr.net>
	<501BF44602000078000928B4@nat28.tlf.novell.com>
	<CAPbh3rsXaqQS9WQQmJ2uQ46LZdyFzkbSodUabGDAyFS+qTEwUg@mail.gmail.com>
	<5028CEE70200007800094623@nat28.tlf.novell.com>
	<50446B5402000078000981F4@nat28.tlf.novell.com>
	<20120906210323.GA303@phenom.dumpdata.com>
In-Reply-To: <20120906210323.GA303@phenom.dumpdata.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: konrad@darnok.org, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Ping: Re: [PATCH] Boot PV guests with more than
 128GB (v2) for 3.7
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.09.12 at 23:03, Konrad Rzeszutek Wilk <konrad@kernel.org> wrote:
> On Mon, Sep 03, 2012 at 07:33:24AM +0100, Jan Beulich wrote:
>> >>> On 13.08.12 at 09:54, "Jan Beulich" <JBeulich@suse.com> wrote:
>> >>>> On 03.08.12 at 16:46, Konrad Rzeszutek Wilk <konrad@darnok.org> wrote:
>> >> Didn't get to it yet. Sorry for top posting. If you have a patch ready I
>> >> can test it on Monday - travelling now.
>> > 
>> > So here's what I was thinking of (compile tested only).
>> 
>> Obviously, if this works, I'd like to see this included in 4.2 (and
>> 4.1-testing).
> 
> No luck. I still get:
> 
> (XEN) Pagetable walk from ffff8800443da070:
> (XEN)  L4[0x110] = 0000009342f95067 0000000000001a0c
> (XEN)  L3[0x001] = 0000000000000000 ffffffffffffffff

And I can't see why. I wasn't able to track down the original
stack trace you saw on the archives - was that identical to
this one (i.e. nothing changed at all)? If so (please forgive
that I'm asking, I just know that I happen to fall into this trap
once in a while myself), did you indeed build and install the
patched tools? In that case, adding some logging to the code
in question is presumably the only alternative, short of
anyone else seeing anything further wrong with that code.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 07 09:15:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Sep 2012 09:15:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9ueN-0004cK-FQ; Fri, 07 Sep 2012 09:14:55 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1T9ueL-0004cF-Px
	for xen-devel@lists.xen.org; Fri, 07 Sep 2012 09:14:53 +0000
Received: from [85.158.143.35:62232] by server-3.bemta-4.messagelabs.com id
	2B/1F-08232-D0BB9405; Fri, 07 Sep 2012 09:14:53 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-14.tower-21.messagelabs.com!1347009273!17197554!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiA0MjAxNDM=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiA0MjAxNDM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1972 invoked from network); 7 Sep 2012 09:14:34 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-14.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 7 Sep 2012 09:14:34 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/lr0M7qFlg=
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-069-014.pools.arcor-ip.net [84.57.69.14])
	by smtp.strato.de (joses mo49) (RZmta 30.14 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id Y01d4bo878slvt ;
	Fri, 7 Sep 2012 11:14:33 +0200 (CEST)
Received: by probook.site (Postfix, from userid 1000)
	id 563FF183AD; Fri,  7 Sep 2012 11:14:28 +0200 (CEST)
Date: Fri, 7 Sep 2012 11:14:28 +0200
From: Olaf Hering <olaf@aepfle.de>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120907091428.GA12925@aepfle.de>
References: <8a2eef481d3ab3ca5692.1346945346@probook.site>
	<1347006747.30018.37.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1347006747.30018.37.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.5.21.rev5555 (2012-07-20)
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] pygrub: always append --args
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Sep 07, Ian Campbell wrote:

> >      except IndexError:
> >          img = g.cf.images[0]
> >  
> > -    grubcfg = { "kernel": None, "ramdisk": None, "args": None }
> > +    grubcfg = { "kernel": None, "ramdisk": None, "args": "" }
> >  
> >      grubcfg["kernel"] = img.kernel[1]
> >      if img.initrd:
> >          grubcfg["ramdisk"] = img.initrd[1]
> >      if img.args:
> 
> With the above change isn't this always true?

img.args comes from img = g.cf.images[sel]?

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 07 09:15:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Sep 2012 09:15:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9ueN-0004cK-FQ; Fri, 07 Sep 2012 09:14:55 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1T9ueL-0004cF-Px
	for xen-devel@lists.xen.org; Fri, 07 Sep 2012 09:14:53 +0000
Received: from [85.158.143.35:62232] by server-3.bemta-4.messagelabs.com id
	2B/1F-08232-D0BB9405; Fri, 07 Sep 2012 09:14:53 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-14.tower-21.messagelabs.com!1347009273!17197554!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiA0MjAxNDM=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiA0MjAxNDM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1972 invoked from network); 7 Sep 2012 09:14:34 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-14.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 7 Sep 2012 09:14:34 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/lr0M7qFlg=
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-069-014.pools.arcor-ip.net [84.57.69.14])
	by smtp.strato.de (joses mo49) (RZmta 30.14 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id Y01d4bo878slvt ;
	Fri, 7 Sep 2012 11:14:33 +0200 (CEST)
Received: by probook.site (Postfix, from userid 1000)
	id 563FF183AD; Fri,  7 Sep 2012 11:14:28 +0200 (CEST)
Date: Fri, 7 Sep 2012 11:14:28 +0200
From: Olaf Hering <olaf@aepfle.de>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120907091428.GA12925@aepfle.de>
References: <8a2eef481d3ab3ca5692.1346945346@probook.site>
	<1347006747.30018.37.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1347006747.30018.37.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.5.21.rev5555 (2012-07-20)
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] pygrub: always append --args
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Sep 07, Ian Campbell wrote:

> >      except IndexError:
> >          img = g.cf.images[0]
> >  
> > -    grubcfg = { "kernel": None, "ramdisk": None, "args": None }
> > +    grubcfg = { "kernel": None, "ramdisk": None, "args": "" }
> >  
> >      grubcfg["kernel"] = img.kernel[1]
> >      if img.initrd:
> >          grubcfg["ramdisk"] = img.initrd[1]
> >      if img.args:
> 
> With the above change isn't this always true?

img.args comes from img = g.cf.images[sel]?

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 07 09:17:41 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Sep 2012 09: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 1T9ugr-0004ml-9R; Fri, 07 Sep 2012 09:17:29 +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 1T9ugp-0004me-Ut
	for xen-devel@lists.xensource.com; Fri, 07 Sep 2012 09:17:28 +0000
Received: from [85.158.143.99:8935] by server-3.bemta-4.messagelabs.com id
	A5/F4-08232-7ABB9405; Fri, 07 Sep 2012 09:17:27 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1347009444!28493437!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNjk1ODQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1641 invoked from network); 7 Sep 2012 09:17:26 -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;
	7 Sep 2012 09:17:26 -0000
X-IronPort-AV: E=Sophos;i="4.80,384,1344211200"; d="scan'208";a="37095748"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Sep 2012 09:17:24 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Fri, 7 Sep 2012 05:17: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 1T9ugl-0001bl-CZ;
	Fri, 07 Sep 2012 10:17:23 +0100
Message-ID: <5049BBA3.80204@citrix.com>
Date: Fri, 7 Sep 2012 10:17:23 +0100
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:14.0) Gecko/20120714 Thunderbird/14.0
MIME-Version: 1.0
To: Sander Eikelenboom <linux@eikelenboom.it>
References: <504764E2.4000809@amd.com>
	<326589347.20120906005936@eikelenboom.it>	<5048A603.3070207@amd.com>
	<483486315.20120906155001@eikelenboom.it>	<5048BB29.4040900@amd.com>
	<488803362.20120907093241@eikelenboom.it>
In-Reply-To: <488803362.20120907093241@eikelenboom.it>
X-Enigmail-Version: 1.4.4
Cc: Wei Wang <wei.wang2@amd.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH] amd iommu: Dump flags of IO page faults
 (off topic - 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 07/09/12 08:32, Sander Eikelenboom wrote:
> Thursday, September 6, 2012, 5:03:05 PM, you wrote:
>
>> On 09/06/2012 03:50 PM, Sander Eikelenboom wrote:
>>> Thursday, September 6, 2012, 3:32:51 PM, you wrote:
>>>
>>>> On 09/06/2012 12:59 AM, Sander Eikelenboom wrote:
>>>>> Wednesday, September 5, 2012, 4:42:42 PM, you wrote:
>>>>>
>>>>>> Hi Jan,
>>>>>> Attached patch dumps io page fault flags. The flags show the reason of
>>>>>> the fault and tell us if this is an unmapped interrupt fault or a DMA fault.
>>>>>> Thanks,
>>>>>> Wei
>>>>>> signed-off-by: Wei Wang<wei.wang2@amd.com>
>>>>>
>>>>> I have applied the patch and the flags seem to differ between the faults:
>>>>>
>>>>> AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0a06, fault address = 0xc2c2c2c0, flags = 0x000
>>>>> (XEN) [2012-09-05 20:54:16] AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0a06, fault address = 0xc2c2c2c0, flags = 0x000
>>>>> (XEN) [2012-09-05 20:54:16] AMD-Vi: IO_PAGE_FAULT: domain = 14, device id = 0x0700, fault address = 0xa8d339e0, flags = 0x020
>>>>> (XEN) [2012-09-05 20:54:16] AMD-Vi: IO_PAGE_FAULT: domain = 14, device id = 0x0700, fault address = 0xa8d33a40, flags = 0x020
>>>> OK, so they are not interrupt requests. I guess further information from
>>>> your system would be helpful to debug this issue:
>>>> 1) xl info
>>>> 2) xl list
>>>> 3) lscpi -vvv (NOTE: not in dom0 but in your guest)
>>>> 4) cat /proc/iomem (in both dom0 and your hvm guest)
>>> dom14 is not a HVM guest,it's a PV guest.
>> Ah, I see. PV guest is quite different than hvm, it does use p2m tables
>> as io page tables. So no-sharept option does not work in this case. PV
>> guests always use separated io page tables. There might be some
>> incorrect mappings on the page tables. I will check this on my side.
> I have reverted the machine to xen-4.1.4-pre (changeset 23353) and kept everything else the same.
> I haven't seen any IO PAGE FAULTS after that.
>
> I did spot some differences in the output from lspci between xen 4.1 and 4.2, related to MSI enabled or not for the IOMMU device.
> Have attached the xl/xm dmesg and lspci from booting with both versions.
>
> lspci:
>
> 00:00.2 Generic system peripheral [0806]: ATI Technologies Inc RD990 I/O Memory Management Unit (IOMMU) [1002:5a23]
>         Subsystem: ATI Technologies Inc RD990 I/O Memory Management Unit (IOMMU) [1002:5a23]
>         Control: I/O- Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
>         Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
>         Latency: 0
>         Interrupt: pin A routed to IRQ 10
>         Capabilities: [40] Secure device <?>
> 4.1:    Capabilities: [54] MSI: Enable- Count=1/1 Maskable- 64bit+
> 4.2:    Capabilities: [54] MSI: Enable+ Count=1/1 Maskable- 64bit+
>                 Address: 00000000fee0100c  Data: 4128
>         Capabilities: [64] HyperTransport: MSI Mapping Enable+ Fixed+
>
> Although it seems enabled, shouldn't the IRQ number used be much higher than 10 for MSI interrupts ?

For compatibility reasons, all real PCI devices have to have the ability
to fall back to legacy line level interrupts.  This is the IRQ10 which
you see, which is #INTA in perhaps more recognizable notation.  The line
interrupt(s) will only be used if MSI and MSI-x interrupts are disabled.

You should find that all devices in lspci show between 1 and 4 #INTs (a
thru d), with the exception of SRIOV virtual function which are
specified to only support MSI/MSI-x

~Andrew

>
> There is another difference in the bridge device that's in front of the  0a:00.6 device that faults before the kernel is even booted.
>
> 00:03.0 PCI bridge [0604]: ATI Technologies Inc RD890 PCI to PCI bridge (PCI express gpp port C) [1002:5a17] (prog-if 00 [Normal decode])
>         Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx+
> 4.1:    Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
> 4.2:    Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort+ <MAbort- >SERR- <PERR- INTx-
>         Latency: 0, Cache Line Size: 64 bytes
>         Bus: primary=00, secondary=0a, subordinate=0a, sec-latency=0
>         I/O behind bridge: 0000f000-00000fff
>         Memory behind bridge: f9f00000-f9ffffff
>         Prefetchable memory behind bridge: 00000000fff00000-00000000000fffff
> 4.1:    Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- <SERR- <PERR-
> 4.2:    Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort+ <TAbort- <MAbort- <SERR- <PERR-
>         BridgeCtl: Parity+ SERR+ NoISA+ VGA- MAbort- >Reset- FastB2B-
>                 PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
>         Capabilities: [50] Power Management version 3
>                 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
>                 Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
>         Capabilities: [58] Express (v2) Root Port (Slot+), MSI 00
>                 DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s <64ns, L1 <1us
>                         ExtTag+ RBE+ FLReset-
>                 DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
>                         RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+
>                         MaxPayload 128 bytes, MaxReadReq 128 bytes
>                 DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr- TransPend-
>                 LnkCap: Port #1, Speed 5GT/s, Width x8, ASPM L0s L1, Latency L0 <1us, L1 <8us
>                         ClockPM- Surprise- LLActRep+ BwNot+
>                 LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommClk-
>                         ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
>                 LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive+ BWMgmt+ ABWMgmt-
>                 SltCap: AttnBtn- PwrCtrl- MRL- AttnInd- PwrInd- HotPlug- Surprise-
>                         Slot #3, PowerLimit 10.000W; Interlock- NoCompl+
>                 SltCtl: Enable: AttnBtn- PwrFlt- MRL- PresDet- CmdCplt- HPIrq- LinkChg-
>                         Control: AttnInd Unknown, PwrInd Unknown, Power- Interlock-
>                 SltSta: Status: AttnBtn- PowerFlt- MRL- CmdCplt- PresDet+ Interlock-
>                         Changed: MRL- PresDet+ LinkState+
>
> serveerstertje:~# lspci -t
> -[0000:00]-+-00.0
>            +-00.2
>            +-02.0-[0b]----00.0
>            +-03.0-[0a]--+-00.0
>            |            +-00.1
>            |            +-00.2
>            |            +-00.3
>            |            +-00.4
>            |            +-00.5
>            |            +-00.6
>            |            \-00.7
>            +-05.0-[09]----00.0
>            +-06.0-[08]----00.0
>            +-0a.0-[07]----00.0
>            +-0b.0-[06]--+-00.0
>            |            \-00.1
>            +-0c.0-[05]----00.0
>            +-0d.0-[04]--+-00.0
>            |            +-00.1
>            |            +-00.2
>            |            +-00.3
>            |            +-00.4
>            |            +-00.5
>            |            +-00.6
>            |            \-00.7
>            +-11.0
>            +-12.0
>            +-12.2
>            +-13.0
>            +-13.2
>            +-14.0
>            +-14.3
>            +-14.4-[03]----06.0
>            +-14.5
>            +-15.0-[02]--
>            +-16.0
>            +-16.2
>            +-18.0
>            +-18.1
>            +-18.2
>            +-18.3
>            \-18.4
>
>
>
>
>
>> Thanks,
>> Wei
>>> I will try to make a complete package, and try with one pv domain only where the devices are being passed through just to simplify the setup.
>>>
>>>
>>>> * I would also like to know the symptoms of device 0x0700 when IO_PF
>>>> happened. Did it stop working?
>>> Yes it stops working, the video capture just freezes, but the driver doesn't bail out.
>>> For the USB controller (0x0a06) it starts to give errors for usbdev_open in the guest.
>>>
>>>> (BTW: I copied a few options from your boot cmd line and it worked with
>>>> my RD890 system
>>>> dom0_mem=1024M,max:1024M loglvl=all loglvl_guest=all console_timestamps
>>>> cpuidle cpufreq=xen noreboot debug lapic=debug apic_verbosity=debug
>>>> apic=debug iommu=on,verbose,debug,no-sharept
>>>> * so, what OEM board you have?)
>>> MSI 890FXA-GD70
>>>
>>>> Also from your log, these lines looks very strange:
>>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>>>> read-only memory page. gfn=0xd5, mfn=0xa4a11
>>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>>>> read-only memory page. gfn=0xd7, mfn=0xa4a0f
>>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>>>> read-only memory page. gfn=0xd9, mfn=0xa4a0d
>>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>>>> read-only memory page. gfn=0xdb, mfn=0xa4a0b
>>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>>>> read-only memory page. gfn=0xdd, mfn=0xa4a09
>>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>>>> read-only memory page. gfn=0xdf, mfn=0xa4a07
>>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>>>> read-only memory page. gfn=0xe1, mfn=0xa4a05
>>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>>>> read-only memory page. gfn=0xe3, mfn=0xa4a03
>>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>>>> read-only memory page. gfn=0xe5, mfn=0xa4a01
>>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>>>> read-only memory page. gfn=0xe7, mfn=0xa463f
>>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>>>> read-only memory page. gfn=0xe9, mfn=0xa463d
>>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>>>> read-only memory page. gfn=0xeb, mfn=0xa463b
>>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>>>> read-only memory page. gfn=0xed, mfn=0xa4639
>>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>>>> read-only memory page. gfn=0xef, mfn=0xa4637
>>>> (XEN) [2012-09-04 16:13:56] AMD-Vi: IO_PAGE_FAULT: domain = 0, device id
>>>> = 0x0a06, fault address = 0xc2c2c2c0
>>>> (XEN) [2012-09-04 16:13:56] AMD-Vi: IO_PAGE_FAULT: domain = 14, device
>>>> id = 0x0700, fault address = 0xa90f8300
>>>> (XEN) [2012-09-04 16:13:56] AMD-Vi: IO_PAGE_FAULT: domain = 14, device
>>>> id = 0x0700, fault address = 0xa90f8340
>>>> (XEN) [2012-09-04 16:13:56] AMD-Vi: IO_PAGE_FAULT: domain = 14, device
>>>> id = 0x0700, fault address = 0xa90f8380
>>>> (XEN) [2012-09-04 16:13:56] AMD-Vi: IO_PAGE_FAULT: domain = 14, device
>>>> id = 0x0700, fault address = 0xa90f83c0
>>>> * they are just followed by the IO PAGE fault. Do you know where are
>>>> they from? Your video card driver maybe?
>>>  From a HVM domain with a old (3.0.3) kernel, but the faults also occur without this domain being started.
>>>
>>>
>>>> Thanks,
>>>> Wei
>>>
>>>>> Complete xl dmesg and lspci -vvvknn attached.
>>>>>
>>>>> Thx
>>>>>
>>>>> --
>>>>> Sander
>>>
>>>
>>>
>>>
>

-- 
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 Sep 07 09:17:41 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Sep 2012 09: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 1T9ugr-0004ml-9R; Fri, 07 Sep 2012 09:17:29 +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 1T9ugp-0004me-Ut
	for xen-devel@lists.xensource.com; Fri, 07 Sep 2012 09:17:28 +0000
Received: from [85.158.143.99:8935] by server-3.bemta-4.messagelabs.com id
	A5/F4-08232-7ABB9405; Fri, 07 Sep 2012 09:17:27 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1347009444!28493437!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNjk1ODQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1641 invoked from network); 7 Sep 2012 09:17:26 -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;
	7 Sep 2012 09:17:26 -0000
X-IronPort-AV: E=Sophos;i="4.80,384,1344211200"; d="scan'208";a="37095748"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Sep 2012 09:17:24 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Fri, 7 Sep 2012 05:17: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 1T9ugl-0001bl-CZ;
	Fri, 07 Sep 2012 10:17:23 +0100
Message-ID: <5049BBA3.80204@citrix.com>
Date: Fri, 7 Sep 2012 10:17:23 +0100
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:14.0) Gecko/20120714 Thunderbird/14.0
MIME-Version: 1.0
To: Sander Eikelenboom <linux@eikelenboom.it>
References: <504764E2.4000809@amd.com>
	<326589347.20120906005936@eikelenboom.it>	<5048A603.3070207@amd.com>
	<483486315.20120906155001@eikelenboom.it>	<5048BB29.4040900@amd.com>
	<488803362.20120907093241@eikelenboom.it>
In-Reply-To: <488803362.20120907093241@eikelenboom.it>
X-Enigmail-Version: 1.4.4
Cc: Wei Wang <wei.wang2@amd.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH] amd iommu: Dump flags of IO page faults
 (off topic - 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 07/09/12 08:32, Sander Eikelenboom wrote:
> Thursday, September 6, 2012, 5:03:05 PM, you wrote:
>
>> On 09/06/2012 03:50 PM, Sander Eikelenboom wrote:
>>> Thursday, September 6, 2012, 3:32:51 PM, you wrote:
>>>
>>>> On 09/06/2012 12:59 AM, Sander Eikelenboom wrote:
>>>>> Wednesday, September 5, 2012, 4:42:42 PM, you wrote:
>>>>>
>>>>>> Hi Jan,
>>>>>> Attached patch dumps io page fault flags. The flags show the reason of
>>>>>> the fault and tell us if this is an unmapped interrupt fault or a DMA fault.
>>>>>> Thanks,
>>>>>> Wei
>>>>>> signed-off-by: Wei Wang<wei.wang2@amd.com>
>>>>>
>>>>> I have applied the patch and the flags seem to differ between the faults:
>>>>>
>>>>> AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0a06, fault address = 0xc2c2c2c0, flags = 0x000
>>>>> (XEN) [2012-09-05 20:54:16] AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0a06, fault address = 0xc2c2c2c0, flags = 0x000
>>>>> (XEN) [2012-09-05 20:54:16] AMD-Vi: IO_PAGE_FAULT: domain = 14, device id = 0x0700, fault address = 0xa8d339e0, flags = 0x020
>>>>> (XEN) [2012-09-05 20:54:16] AMD-Vi: IO_PAGE_FAULT: domain = 14, device id = 0x0700, fault address = 0xa8d33a40, flags = 0x020
>>>> OK, so they are not interrupt requests. I guess further information from
>>>> your system would be helpful to debug this issue:
>>>> 1) xl info
>>>> 2) xl list
>>>> 3) lscpi -vvv (NOTE: not in dom0 but in your guest)
>>>> 4) cat /proc/iomem (in both dom0 and your hvm guest)
>>> dom14 is not a HVM guest,it's a PV guest.
>> Ah, I see. PV guest is quite different than hvm, it does use p2m tables
>> as io page tables. So no-sharept option does not work in this case. PV
>> guests always use separated io page tables. There might be some
>> incorrect mappings on the page tables. I will check this on my side.
> I have reverted the machine to xen-4.1.4-pre (changeset 23353) and kept everything else the same.
> I haven't seen any IO PAGE FAULTS after that.
>
> I did spot some differences in the output from lspci between xen 4.1 and 4.2, related to MSI enabled or not for the IOMMU device.
> Have attached the xl/xm dmesg and lspci from booting with both versions.
>
> lspci:
>
> 00:00.2 Generic system peripheral [0806]: ATI Technologies Inc RD990 I/O Memory Management Unit (IOMMU) [1002:5a23]
>         Subsystem: ATI Technologies Inc RD990 I/O Memory Management Unit (IOMMU) [1002:5a23]
>         Control: I/O- Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
>         Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
>         Latency: 0
>         Interrupt: pin A routed to IRQ 10
>         Capabilities: [40] Secure device <?>
> 4.1:    Capabilities: [54] MSI: Enable- Count=1/1 Maskable- 64bit+
> 4.2:    Capabilities: [54] MSI: Enable+ Count=1/1 Maskable- 64bit+
>                 Address: 00000000fee0100c  Data: 4128
>         Capabilities: [64] HyperTransport: MSI Mapping Enable+ Fixed+
>
> Although it seems enabled, shouldn't the IRQ number used be much higher than 10 for MSI interrupts ?

For compatibility reasons, all real PCI devices have to have the ability
to fall back to legacy line level interrupts.  This is the IRQ10 which
you see, which is #INTA in perhaps more recognizable notation.  The line
interrupt(s) will only be used if MSI and MSI-x interrupts are disabled.

You should find that all devices in lspci show between 1 and 4 #INTs (a
thru d), with the exception of SRIOV virtual function which are
specified to only support MSI/MSI-x

~Andrew

>
> There is another difference in the bridge device that's in front of the  0a:00.6 device that faults before the kernel is even booted.
>
> 00:03.0 PCI bridge [0604]: ATI Technologies Inc RD890 PCI to PCI bridge (PCI express gpp port C) [1002:5a17] (prog-if 00 [Normal decode])
>         Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx+
> 4.1:    Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
> 4.2:    Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort+ <MAbort- >SERR- <PERR- INTx-
>         Latency: 0, Cache Line Size: 64 bytes
>         Bus: primary=00, secondary=0a, subordinate=0a, sec-latency=0
>         I/O behind bridge: 0000f000-00000fff
>         Memory behind bridge: f9f00000-f9ffffff
>         Prefetchable memory behind bridge: 00000000fff00000-00000000000fffff
> 4.1:    Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- <SERR- <PERR-
> 4.2:    Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort+ <TAbort- <MAbort- <SERR- <PERR-
>         BridgeCtl: Parity+ SERR+ NoISA+ VGA- MAbort- >Reset- FastB2B-
>                 PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
>         Capabilities: [50] Power Management version 3
>                 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
>                 Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
>         Capabilities: [58] Express (v2) Root Port (Slot+), MSI 00
>                 DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s <64ns, L1 <1us
>                         ExtTag+ RBE+ FLReset-
>                 DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
>                         RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+
>                         MaxPayload 128 bytes, MaxReadReq 128 bytes
>                 DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr- TransPend-
>                 LnkCap: Port #1, Speed 5GT/s, Width x8, ASPM L0s L1, Latency L0 <1us, L1 <8us
>                         ClockPM- Surprise- LLActRep+ BwNot+
>                 LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommClk-
>                         ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
>                 LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive+ BWMgmt+ ABWMgmt-
>                 SltCap: AttnBtn- PwrCtrl- MRL- AttnInd- PwrInd- HotPlug- Surprise-
>                         Slot #3, PowerLimit 10.000W; Interlock- NoCompl+
>                 SltCtl: Enable: AttnBtn- PwrFlt- MRL- PresDet- CmdCplt- HPIrq- LinkChg-
>                         Control: AttnInd Unknown, PwrInd Unknown, Power- Interlock-
>                 SltSta: Status: AttnBtn- PowerFlt- MRL- CmdCplt- PresDet+ Interlock-
>                         Changed: MRL- PresDet+ LinkState+
>
> serveerstertje:~# lspci -t
> -[0000:00]-+-00.0
>            +-00.2
>            +-02.0-[0b]----00.0
>            +-03.0-[0a]--+-00.0
>            |            +-00.1
>            |            +-00.2
>            |            +-00.3
>            |            +-00.4
>            |            +-00.5
>            |            +-00.6
>            |            \-00.7
>            +-05.0-[09]----00.0
>            +-06.0-[08]----00.0
>            +-0a.0-[07]----00.0
>            +-0b.0-[06]--+-00.0
>            |            \-00.1
>            +-0c.0-[05]----00.0
>            +-0d.0-[04]--+-00.0
>            |            +-00.1
>            |            +-00.2
>            |            +-00.3
>            |            +-00.4
>            |            +-00.5
>            |            +-00.6
>            |            \-00.7
>            +-11.0
>            +-12.0
>            +-12.2
>            +-13.0
>            +-13.2
>            +-14.0
>            +-14.3
>            +-14.4-[03]----06.0
>            +-14.5
>            +-15.0-[02]--
>            +-16.0
>            +-16.2
>            +-18.0
>            +-18.1
>            +-18.2
>            +-18.3
>            \-18.4
>
>
>
>
>
>> Thanks,
>> Wei
>>> I will try to make a complete package, and try with one pv domain only where the devices are being passed through just to simplify the setup.
>>>
>>>
>>>> * I would also like to know the symptoms of device 0x0700 when IO_PF
>>>> happened. Did it stop working?
>>> Yes it stops working, the video capture just freezes, but the driver doesn't bail out.
>>> For the USB controller (0x0a06) it starts to give errors for usbdev_open in the guest.
>>>
>>>> (BTW: I copied a few options from your boot cmd line and it worked with
>>>> my RD890 system
>>>> dom0_mem=1024M,max:1024M loglvl=all loglvl_guest=all console_timestamps
>>>> cpuidle cpufreq=xen noreboot debug lapic=debug apic_verbosity=debug
>>>> apic=debug iommu=on,verbose,debug,no-sharept
>>>> * so, what OEM board you have?)
>>> MSI 890FXA-GD70
>>>
>>>> Also from your log, these lines looks very strange:
>>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>>>> read-only memory page. gfn=0xd5, mfn=0xa4a11
>>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>>>> read-only memory page. gfn=0xd7, mfn=0xa4a0f
>>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>>>> read-only memory page. gfn=0xd9, mfn=0xa4a0d
>>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>>>> read-only memory page. gfn=0xdb, mfn=0xa4a0b
>>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>>>> read-only memory page. gfn=0xdd, mfn=0xa4a09
>>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>>>> read-only memory page. gfn=0xdf, mfn=0xa4a07
>>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>>>> read-only memory page. gfn=0xe1, mfn=0xa4a05
>>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>>>> read-only memory page. gfn=0xe3, mfn=0xa4a03
>>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>>>> read-only memory page. gfn=0xe5, mfn=0xa4a01
>>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>>>> read-only memory page. gfn=0xe7, mfn=0xa463f
>>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>>>> read-only memory page. gfn=0xe9, mfn=0xa463d
>>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>>>> read-only memory page. gfn=0xeb, mfn=0xa463b
>>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>>>> read-only memory page. gfn=0xed, mfn=0xa4639
>>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>>>> read-only memory page. gfn=0xef, mfn=0xa4637
>>>> (XEN) [2012-09-04 16:13:56] AMD-Vi: IO_PAGE_FAULT: domain = 0, device id
>>>> = 0x0a06, fault address = 0xc2c2c2c0
>>>> (XEN) [2012-09-04 16:13:56] AMD-Vi: IO_PAGE_FAULT: domain = 14, device
>>>> id = 0x0700, fault address = 0xa90f8300
>>>> (XEN) [2012-09-04 16:13:56] AMD-Vi: IO_PAGE_FAULT: domain = 14, device
>>>> id = 0x0700, fault address = 0xa90f8340
>>>> (XEN) [2012-09-04 16:13:56] AMD-Vi: IO_PAGE_FAULT: domain = 14, device
>>>> id = 0x0700, fault address = 0xa90f8380
>>>> (XEN) [2012-09-04 16:13:56] AMD-Vi: IO_PAGE_FAULT: domain = 14, device
>>>> id = 0x0700, fault address = 0xa90f83c0
>>>> * they are just followed by the IO PAGE fault. Do you know where are
>>>> they from? Your video card driver maybe?
>>>  From a HVM domain with a old (3.0.3) kernel, but the faults also occur without this domain being started.
>>>
>>>
>>>> Thanks,
>>>> Wei
>>>
>>>>> Complete xl dmesg and lspci -vvvknn attached.
>>>>>
>>>>> Thx
>>>>>
>>>>> --
>>>>> Sander
>>>
>>>
>>>
>>>
>

-- 
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 Sep 07 09:21:28 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Sep 2012 09:21: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 1T9ukQ-0004z1-1I; Fri, 07 Sep 2012 09:21:10 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1T9ukP-0004yu-7F
	for xen-devel@lists.xen.org; Fri, 07 Sep 2012 09:21:09 +0000
Received: from [85.158.143.99:24434] by server-3.bemta-4.messagelabs.com id
	03/EC-08232-48CB9405; Fri, 07 Sep 2012 09:21:08 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1347009667!23793750!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTIyMTE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15869 invoked from network); 7 Sep 2012 09:21:07 -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 Sep 2012 09:21:07 -0000
X-IronPort-AV: E=Sophos;i="4.80,384,1344211200"; d="scan'208";a="14404119"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Sep 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.279.1; Fri, 7 Sep 2012
	10:21:06 +0100
Message-ID: <1347009665.30018.48.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Olaf Hering <olaf@aepfle.de>
Date: Fri, 7 Sep 2012 10:21:05 +0100
In-Reply-To: <20120907091428.GA12925@aepfle.de>
References: <8a2eef481d3ab3ca5692.1346945346@probook.site>
	<1347006747.30018.37.camel@zakaz.uk.xensource.com>
	<20120907091428.GA12925@aepfle.de>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] pygrub: always append --args
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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-09-07 at 10:14 +0100, Olaf Hering wrote:
> On Fri, Sep 07, Ian Campbell wrote:
> 
> > >      except IndexError:
> > >          img = g.cf.images[0]
> > >  
> > > -    grubcfg = { "kernel": None, "ramdisk": None, "args": None }
> > > +    grubcfg = { "kernel": None, "ramdisk": None, "args": "" }
> > >  
> > >      grubcfg["kernel"] = img.kernel[1]
> > >      if img.initrd:
> > >          grubcfg["ramdisk"] = img.initrd[1]
> > >      if img.args:
> > 
> > With the above change isn't this always true?
> 
> img.args comes from img = g.cf.images[sel]?

Oh sorry, for some reason I did s/grubcfg/img/ in my head in that
assignment.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 07 09:21:28 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Sep 2012 09:21: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 1T9ukQ-0004z1-1I; Fri, 07 Sep 2012 09:21:10 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1T9ukP-0004yu-7F
	for xen-devel@lists.xen.org; Fri, 07 Sep 2012 09:21:09 +0000
Received: from [85.158.143.99:24434] by server-3.bemta-4.messagelabs.com id
	03/EC-08232-48CB9405; Fri, 07 Sep 2012 09:21:08 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1347009667!23793750!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTIyMTE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15869 invoked from network); 7 Sep 2012 09:21:07 -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 Sep 2012 09:21:07 -0000
X-IronPort-AV: E=Sophos;i="4.80,384,1344211200"; d="scan'208";a="14404119"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Sep 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.279.1; Fri, 7 Sep 2012
	10:21:06 +0100
Message-ID: <1347009665.30018.48.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Olaf Hering <olaf@aepfle.de>
Date: Fri, 7 Sep 2012 10:21:05 +0100
In-Reply-To: <20120907091428.GA12925@aepfle.de>
References: <8a2eef481d3ab3ca5692.1346945346@probook.site>
	<1347006747.30018.37.camel@zakaz.uk.xensource.com>
	<20120907091428.GA12925@aepfle.de>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] pygrub: always append --args
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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-09-07 at 10:14 +0100, Olaf Hering wrote:
> On Fri, Sep 07, Ian Campbell wrote:
> 
> > >      except IndexError:
> > >          img = g.cf.images[0]
> > >  
> > > -    grubcfg = { "kernel": None, "ramdisk": None, "args": None }
> > > +    grubcfg = { "kernel": None, "ramdisk": None, "args": "" }
> > >  
> > >      grubcfg["kernel"] = img.kernel[1]
> > >      if img.initrd:
> > >          grubcfg["ramdisk"] = img.initrd[1]
> > >      if img.args:
> > 
> > With the above change isn't this always true?
> 
> img.args comes from img = g.cf.images[sel]?

Oh sorry, for some reason I did s/grubcfg/img/ in my head in that
assignment.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 07 09:21:56 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Sep 2012 09:21:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9ukw-00051l-F5; Fri, 07 Sep 2012 09:21:42 +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 1T9ukv-00051a-2u
	for xen-devel@lists.xen.org; Fri, 07 Sep 2012 09:21:41 +0000
Received: from [85.158.138.51:27478] by server-6.bemta-3.messagelabs.com id
	29/5A-29694-4ACB9405; Fri, 07 Sep 2012 09:21:40 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1347009662!28735849!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-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29997 invoked from network); 7 Sep 2012 09:21:02 -0000
Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com)
	(74.125.83.45)
	by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Sep 2012 09:21:02 -0000
Received: by eeke53 with SMTP id e53so1181596eek.32
	for <xen-devel@lists.xen.org>; Fri, 07 Sep 2012 02:21: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=joFn2mgMe/MaJTEMDJTz5Id31onoSx/ulL39PvInhRQ=;
	b=rELmRFMbU2TE1jUDgzbgkVWxrKTj9xu/U6dpEPCm4qxM1NuP7ZTbaqvcsIDj7pLAMu
	Q9PASoDuYSRmFRosfEGeuqhePJWY8IlPuZ1iqnAQlmlBownD5uEM8TpeCpCpALIbwNLA
	OYyBmGOsXI21naCPky+5as8MfXuweIyF8DZmt2jxMNWvykduPss4NCobpYGwphLiQwSS
	5eO8dSv7bZWyZBDE7Z/4xI76SZT98d1mBhkv1RJbTahPJmBpe4qUpM/wih3Ldo6sy2ud
	5/vZBRfgSphPq1MhgDcSD+N80rVU3A8WAScIebuSltTQb9h7XAaBmmhSerDXS3+E32Gh
	81kA==
Received: by 10.14.0.198 with SMTP id 46mr6848990eeb.30.1347009662183;
	Fri, 07 Sep 2012 02:21:02 -0700 (PDT)
Received: from [192.168.1.69] (host86-184-74-117.range86-184.btcentralplus.com.
	[86.184.74.117])
	by mx.google.com with ESMTPS id i8sm12915483eeo.16.2012.09.07.02.20.59
	(version=SSLv3 cipher=OTHER); Fri, 07 Sep 2012 02:21:01 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Fri, 07 Sep 2012 10:20:51 +0100
From: Keir Fraser <keir.xen@gmail.com>
To: Jan Beulich <JBeulich@suse.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <CC6F7B03.3E00C%keir.xen@gmail.com>
Thread-Topic: [PATCH] xen: clamp bitmaps to correct number of bits
Thread-Index: Ac2M2hLQjuKQoHmfh0SuMuO094R91Q==
In-Reply-To: <5049CD810200007800099A25@nat28.tlf.novell.com>
Mime-version: 1.0
Cc: Dario Faggioli <dario.faggioli@citrix.com>, "Tim \(Xen.org\)" <tim@xen.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] xen: clamp bitmaps to correct number of bits
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/09/2012 09:33, "Jan Beulich" <JBeulich@suse.com> wrote:

>>>> On 07.09.12 at 10:23, Ian Campbell <Ian.Campbell@citrix.com> wrote:
>> Right, I wouldn't normally commit to the xen subtree even with Acks from
>> you both anyway, but an explicit "please commit" would cause me to do
>> so.
> 
> I think both Keir and I imply permission to commit with an ack (in
> my case, that permission of course is limited to the portions of
> the tree for which I'm listed as maintainer). Keir, please correct
> me if that's a wrong understanding of mine.

I'm not too strict, but I'd say that it takes very little to add "and please
commit", and avoids confusion where both try to commit at the same time.

For this specific patch, I expect Jan to commit it, as he has a couple of
trivial cleanups he wants to do at the same time. And with that:
Acked-by: Keir Fraser <keir@xen.org>

Jan, you can check it in as soon as 4.3 development opens (hopefully later
today!).

 -- 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 Sep 07 09:21:56 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Sep 2012 09:21:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9ukw-00051l-F5; Fri, 07 Sep 2012 09:21:42 +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 1T9ukv-00051a-2u
	for xen-devel@lists.xen.org; Fri, 07 Sep 2012 09:21:41 +0000
Received: from [85.158.138.51:27478] by server-6.bemta-3.messagelabs.com id
	29/5A-29694-4ACB9405; Fri, 07 Sep 2012 09:21:40 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1347009662!28735849!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-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29997 invoked from network); 7 Sep 2012 09:21:02 -0000
Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com)
	(74.125.83.45)
	by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Sep 2012 09:21:02 -0000
Received: by eeke53 with SMTP id e53so1181596eek.32
	for <xen-devel@lists.xen.org>; Fri, 07 Sep 2012 02:21: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=joFn2mgMe/MaJTEMDJTz5Id31onoSx/ulL39PvInhRQ=;
	b=rELmRFMbU2TE1jUDgzbgkVWxrKTj9xu/U6dpEPCm4qxM1NuP7ZTbaqvcsIDj7pLAMu
	Q9PASoDuYSRmFRosfEGeuqhePJWY8IlPuZ1iqnAQlmlBownD5uEM8TpeCpCpALIbwNLA
	OYyBmGOsXI21naCPky+5as8MfXuweIyF8DZmt2jxMNWvykduPss4NCobpYGwphLiQwSS
	5eO8dSv7bZWyZBDE7Z/4xI76SZT98d1mBhkv1RJbTahPJmBpe4qUpM/wih3Ldo6sy2ud
	5/vZBRfgSphPq1MhgDcSD+N80rVU3A8WAScIebuSltTQb9h7XAaBmmhSerDXS3+E32Gh
	81kA==
Received: by 10.14.0.198 with SMTP id 46mr6848990eeb.30.1347009662183;
	Fri, 07 Sep 2012 02:21:02 -0700 (PDT)
Received: from [192.168.1.69] (host86-184-74-117.range86-184.btcentralplus.com.
	[86.184.74.117])
	by mx.google.com with ESMTPS id i8sm12915483eeo.16.2012.09.07.02.20.59
	(version=SSLv3 cipher=OTHER); Fri, 07 Sep 2012 02:21:01 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Fri, 07 Sep 2012 10:20:51 +0100
From: Keir Fraser <keir.xen@gmail.com>
To: Jan Beulich <JBeulich@suse.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <CC6F7B03.3E00C%keir.xen@gmail.com>
Thread-Topic: [PATCH] xen: clamp bitmaps to correct number of bits
Thread-Index: Ac2M2hLQjuKQoHmfh0SuMuO094R91Q==
In-Reply-To: <5049CD810200007800099A25@nat28.tlf.novell.com>
Mime-version: 1.0
Cc: Dario Faggioli <dario.faggioli@citrix.com>, "Tim \(Xen.org\)" <tim@xen.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] xen: clamp bitmaps to correct number of bits
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/09/2012 09:33, "Jan Beulich" <JBeulich@suse.com> wrote:

>>>> On 07.09.12 at 10:23, Ian Campbell <Ian.Campbell@citrix.com> wrote:
>> Right, I wouldn't normally commit to the xen subtree even with Acks from
>> you both anyway, but an explicit "please commit" would cause me to do
>> so.
> 
> I think both Keir and I imply permission to commit with an ack (in
> my case, that permission of course is limited to the portions of
> the tree for which I'm listed as maintainer). Keir, please correct
> me if that's a wrong understanding of mine.

I'm not too strict, but I'd say that it takes very little to add "and please
commit", and avoids confusion where both try to commit at the same time.

For this specific patch, I expect Jan to commit it, as he has a couple of
trivial cleanups he wants to do at the same time. And with that:
Acked-by: Keir Fraser <keir@xen.org>

Jan, you can check it in as soon as 4.3 development opens (hopefully later
today!).

 -- 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 Sep 07 09:24:09 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Sep 2012 09:24:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9un6-0005CY-0Z; Fri, 07 Sep 2012 09:23:56 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <bvanassche@acm.org>) id 1T9un4-0005CM-Gn
	for xen-devel@lists.xen.org; Fri, 07 Sep 2012 09:23:54 +0000
Received: from [85.158.143.99:46863] by server-2.bemta-4.messagelabs.com id
	17/CC-21239-92DB9405; Fri, 07 Sep 2012 09:23:53 +0000
X-Env-Sender: bvanassche@acm.org
X-Msg-Ref: server-10.tower-216.messagelabs.com!1347009832!22685641!1
X-Originating-IP: [195.130.132.50]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTk1LjEzMC4xMzIuNTAgPT4gMjI0OTUx\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23858 invoked from network); 7 Sep 2012 09:23:53 -0000
Received: from jacques.telenet-ops.be (HELO jacques.telenet-ops.be)
	(195.130.132.50) by server-10.tower-216.messagelabs.com with SMTP;
	7 Sep 2012 09:23:53 -0000
Received: from [192.168.1.101] ([178.119.64.133])
	by jacques.telenet-ops.be with bizsmtp
	id w9Pp1j00o2sVyXE0J9PpjV; Fri, 07 Sep 2012 11:23:51 +0200
Message-ID: <5049BD25.8010408@acm.org>
Date: Fri, 07 Sep 2012 11:23:49 +0200
From: Bart Van Assche <bvanassche@acm.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120825 Thunderbird/15.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <1346775635.6712.63.camel@zakaz.uk.xensource.com>
In-Reply-To: <1346775635.6712.63.camel@zakaz.uk.xensource.com>
X-Enigmail-Version: 1.4.4
Cc: "valgrind-developers@lists.sourceforge.net"
	<valgrind-developers@lists.sourceforge.net>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [Valgrind-developers] [PATCH] valgrind: Support for
 ioctls used by Xen toolstack processes.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 09/04/12 18:20, Ian Campbell wrote:
> One issue is that the hypercalls which are exlusively used by the
> toolstacks (as opposed to those used by guest operating systems) are
> not considered a stable ABI, since the hypervisor and the lowlevel
> tools are considered a matched pair. This covers the sysctl and
> domctl hypercalls which are a fairly large chunk of the support
> here. I'm not sure how to solve this without invoking a massive
> amount of duplication. Right now this targets the Xen unstable
> interface (which will shortly be released as Xen 4.2), perhaps I can
> get away with deferring this problem until the first change ;-).

Does this mean the Xen interface is not backwards compatible ? If so,
are you sure you want to add support for an unstable API in Valgrind ?

> There are some other wrinkles here I've not been sure how to solve:
> 
> Firstly, di_notify_mmap tries to read from the magic proc device:
>      --20208-- WARNING: Serious error when reading debug info
>      --20208-- When reading debug info from /proc/xen/privcmd:
>      --20208-- can't read file to inspect ELF header
> 
> I've hacked around this with an explicit check for /proc/xen.
> Hopefully someone can point to the right solution.

The changes for avoiding reading debuginfo from /proc/xen/privcmd look
fine to me.

Bart.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 07 09:24:09 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Sep 2012 09:24:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9un6-0005CY-0Z; Fri, 07 Sep 2012 09:23:56 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <bvanassche@acm.org>) id 1T9un4-0005CM-Gn
	for xen-devel@lists.xen.org; Fri, 07 Sep 2012 09:23:54 +0000
Received: from [85.158.143.99:46863] by server-2.bemta-4.messagelabs.com id
	17/CC-21239-92DB9405; Fri, 07 Sep 2012 09:23:53 +0000
X-Env-Sender: bvanassche@acm.org
X-Msg-Ref: server-10.tower-216.messagelabs.com!1347009832!22685641!1
X-Originating-IP: [195.130.132.50]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTk1LjEzMC4xMzIuNTAgPT4gMjI0OTUx\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23858 invoked from network); 7 Sep 2012 09:23:53 -0000
Received: from jacques.telenet-ops.be (HELO jacques.telenet-ops.be)
	(195.130.132.50) by server-10.tower-216.messagelabs.com with SMTP;
	7 Sep 2012 09:23:53 -0000
Received: from [192.168.1.101] ([178.119.64.133])
	by jacques.telenet-ops.be with bizsmtp
	id w9Pp1j00o2sVyXE0J9PpjV; Fri, 07 Sep 2012 11:23:51 +0200
Message-ID: <5049BD25.8010408@acm.org>
Date: Fri, 07 Sep 2012 11:23:49 +0200
From: Bart Van Assche <bvanassche@acm.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120825 Thunderbird/15.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <1346775635.6712.63.camel@zakaz.uk.xensource.com>
In-Reply-To: <1346775635.6712.63.camel@zakaz.uk.xensource.com>
X-Enigmail-Version: 1.4.4
Cc: "valgrind-developers@lists.sourceforge.net"
	<valgrind-developers@lists.sourceforge.net>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [Valgrind-developers] [PATCH] valgrind: Support for
 ioctls used by Xen toolstack processes.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 09/04/12 18:20, Ian Campbell wrote:
> One issue is that the hypercalls which are exlusively used by the
> toolstacks (as opposed to those used by guest operating systems) are
> not considered a stable ABI, since the hypervisor and the lowlevel
> tools are considered a matched pair. This covers the sysctl and
> domctl hypercalls which are a fairly large chunk of the support
> here. I'm not sure how to solve this without invoking a massive
> amount of duplication. Right now this targets the Xen unstable
> interface (which will shortly be released as Xen 4.2), perhaps I can
> get away with deferring this problem until the first change ;-).

Does this mean the Xen interface is not backwards compatible ? If so,
are you sure you want to add support for an unstable API in Valgrind ?

> There are some other wrinkles here I've not been sure how to solve:
> 
> Firstly, di_notify_mmap tries to read from the magic proc device:
>      --20208-- WARNING: Serious error when reading debug info
>      --20208-- When reading debug info from /proc/xen/privcmd:
>      --20208-- can't read file to inspect ELF header
> 
> I've hacked around this with an explicit check for /proc/xen.
> Hopefully someone can point to the right solution.

The changes for avoiding reading debuginfo from /proc/xen/privcmd look
fine to me.

Bart.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 07 09:26:20 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Sep 2012 09:26:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9upE-0005Od-MX; Fri, 07 Sep 2012 09:26:08 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1T9upD-0005OW-Fj
	for xen-devel@lists.xen.org; Fri, 07 Sep 2012 09:26:07 +0000
Received: from [85.158.143.99:3002] by server-1.bemta-4.messagelabs.com id
	F4/01-12504-EADB9405; Fri, 07 Sep 2012 09:26:06 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-10.tower-216.messagelabs.com!1347009961!22686214!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiA0MjAxNDM=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiA0MjAxNDM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2908 invoked from network); 7 Sep 2012 09:26:02 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-10.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 7 Sep 2012 09:26:02 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/lr0M7qFlg=
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-069-014.pools.arcor-ip.net [84.57.69.14])
	by smtp.strato.de (jored mo29) (RZmta 30.14 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id u0275eo879Dxel
	for <xen-devel@lists.xen.org>; Fri, 7 Sep 2012 11:26:01 +0200 (CEST)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id D97BA183A5
	for <xen-devel@lists.xen.org>; Fri,  7 Sep 2012 11:25:54 +0200 (CEST)
MIME-Version: 1.0
X-Mercurial-Node: da03cd98d2fbc6c3a176f34b17cb6184a518525e
Message-Id: <da03cd98d2fbc6c3a176.1347009954@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Fri, 07 Sep 2012 11:25:54 +0200
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH] libxl: add missing dependencies of libxl.h
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

# HG changeset patch
# User Olaf Hering <olaf@aepfle.de>
# Date 1347009935 -7200
# Node ID da03cd98d2fbc6c3a176f34b17cb6184a518525e
# Parent  ec23c2a11f6fa55bd0472377a7324d67cdf86248
libxl: add missing dependencies of libxl.h

libxl.h includes generated files, but the Makefile lists no dependency
on these files. As a result compilation may fail like this:

[  379s] make -C libxl install
[  379s] make[3]: Entering directory `/usr/src/packages/BUILD/xen-4.2.25821/non-dbg/tools/libxl'
[  379s] /usr/bin/perl
/usr/src/packages/BUILD/xen-4.2.25821/non-dbg/tools/libxl/../../tools/include/xen-external/bsd-sys-queue-h-seddery
/usr/src/packages/BUILD/xen-4.2.25821/non-dbg/tools/libxl/../../tools/include/xen-external/bsd-sys-queue.h
--prefix=libxl >_libxl_list.h.new
...
[  380s] 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.api-for-check.d  -D_LARGEFILE_SOURCE
-D_LARGEFILE64_SOURCE -fno-optimize-sibling-calls -fmessage-length=0 -O2
-Wall -D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables
-fasynchronous-unwind-tables -Werror -Wno-format-zero-length
-Wmissing-declarations -Wno-declaration-after-statement
-Wformat-nonliteral -I. -fPIC -pthread
-I/usr/src/packages/BUILD/xen-4.2.25821/non-dbg/tools/libxl/../../tools/libxc
-I/usr/src/packages/BUILD/xen-4.2.25821/non-dbg/tools/libxl/../../tools/include
-I/usr/src/packages/BUILD/xen-4.2.25821/non-dbg/tools/libxl/../../tools/libxl
-I/usr/src/packages/BUILD/xen-4.2.25821/non-dbg/tools/libxl/../../tools/libxc
-I/usr/src/packages/BUILD/xen-4.2.25821/non-dbg/tools/libxl/../../tools/include
-I/usr/src/packages/BUILD/xen-4.2.25821/non-dbg/tools/libxl/../../tools/include
-include
/usr/src/packages/BUILD/xen-4.2.25821/non-dbg/tools/libxl/../../tools/config.h
-I/usr/src/packages/BUILD/xen-4.2.25821/non-dbg/tools/libxl/../../tools/libxc
-I/usr/src/packages/BUILD/xen-4.2.25821/non-dbg/tools/libxl/../../tools/include
-c -E libxl.h  \
[  380s] -DLIBXL_EXTERNAL_CALLERS_ONLY=LIBXL_EXTERNAL_CALLERS_ONLY \
[  380s] >_libxl.api-for-check.new
...
[  380s] libxl.h:260:25: fatal error: _libxl_list.h: No such file or directory
[  380s] compilation terminated.
[  380s] make[3]: *** [_libxl.api-for-check] Error 1
[  381s] if ! cmp -s _libxl_list.h.new _libxl_list.h; then mv -f
_libxl_list.h.new _libxl_list.h; else rm -f _libxl_list.h.new; fi


Fix this be extending the existing libxl.h dependency with the generated
file _libxl_list.h.

Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r ec23c2a11f6f -r da03cd98d2fb tools/libxl/Makefile
--- a/tools/libxl/Makefile
+++ b/tools/libxl/Makefile
@@ -140,7 +140,7 @@ _libxl_save_msgs_helper.h _libxl_save_ms
 	$(PERL) -w $< $@ >$@.new
 	$(call move-if-changed,$@.new,$@)
 
-libxl.h: _libxl_types.h
+libxl.h: _libxl_types.h _libxl_list.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

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 07 09:26:20 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Sep 2012 09:26:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9upE-0005Od-MX; Fri, 07 Sep 2012 09:26:08 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1T9upD-0005OW-Fj
	for xen-devel@lists.xen.org; Fri, 07 Sep 2012 09:26:07 +0000
Received: from [85.158.143.99:3002] by server-1.bemta-4.messagelabs.com id
	F4/01-12504-EADB9405; Fri, 07 Sep 2012 09:26:06 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-10.tower-216.messagelabs.com!1347009961!22686214!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiA0MjAxNDM=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiA0MjAxNDM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2908 invoked from network); 7 Sep 2012 09:26:02 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-10.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 7 Sep 2012 09:26:02 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/lr0M7qFlg=
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-069-014.pools.arcor-ip.net [84.57.69.14])
	by smtp.strato.de (jored mo29) (RZmta 30.14 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id u0275eo879Dxel
	for <xen-devel@lists.xen.org>; Fri, 7 Sep 2012 11:26:01 +0200 (CEST)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id D97BA183A5
	for <xen-devel@lists.xen.org>; Fri,  7 Sep 2012 11:25:54 +0200 (CEST)
MIME-Version: 1.0
X-Mercurial-Node: da03cd98d2fbc6c3a176f34b17cb6184a518525e
Message-Id: <da03cd98d2fbc6c3a176.1347009954@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Fri, 07 Sep 2012 11:25:54 +0200
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH] libxl: add missing dependencies of libxl.h
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

# HG changeset patch
# User Olaf Hering <olaf@aepfle.de>
# Date 1347009935 -7200
# Node ID da03cd98d2fbc6c3a176f34b17cb6184a518525e
# Parent  ec23c2a11f6fa55bd0472377a7324d67cdf86248
libxl: add missing dependencies of libxl.h

libxl.h includes generated files, but the Makefile lists no dependency
on these files. As a result compilation may fail like this:

[  379s] make -C libxl install
[  379s] make[3]: Entering directory `/usr/src/packages/BUILD/xen-4.2.25821/non-dbg/tools/libxl'
[  379s] /usr/bin/perl
/usr/src/packages/BUILD/xen-4.2.25821/non-dbg/tools/libxl/../../tools/include/xen-external/bsd-sys-queue-h-seddery
/usr/src/packages/BUILD/xen-4.2.25821/non-dbg/tools/libxl/../../tools/include/xen-external/bsd-sys-queue.h
--prefix=libxl >_libxl_list.h.new
...
[  380s] 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.api-for-check.d  -D_LARGEFILE_SOURCE
-D_LARGEFILE64_SOURCE -fno-optimize-sibling-calls -fmessage-length=0 -O2
-Wall -D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables
-fasynchronous-unwind-tables -Werror -Wno-format-zero-length
-Wmissing-declarations -Wno-declaration-after-statement
-Wformat-nonliteral -I. -fPIC -pthread
-I/usr/src/packages/BUILD/xen-4.2.25821/non-dbg/tools/libxl/../../tools/libxc
-I/usr/src/packages/BUILD/xen-4.2.25821/non-dbg/tools/libxl/../../tools/include
-I/usr/src/packages/BUILD/xen-4.2.25821/non-dbg/tools/libxl/../../tools/libxl
-I/usr/src/packages/BUILD/xen-4.2.25821/non-dbg/tools/libxl/../../tools/libxc
-I/usr/src/packages/BUILD/xen-4.2.25821/non-dbg/tools/libxl/../../tools/include
-I/usr/src/packages/BUILD/xen-4.2.25821/non-dbg/tools/libxl/../../tools/include
-include
/usr/src/packages/BUILD/xen-4.2.25821/non-dbg/tools/libxl/../../tools/config.h
-I/usr/src/packages/BUILD/xen-4.2.25821/non-dbg/tools/libxl/../../tools/libxc
-I/usr/src/packages/BUILD/xen-4.2.25821/non-dbg/tools/libxl/../../tools/include
-c -E libxl.h  \
[  380s] -DLIBXL_EXTERNAL_CALLERS_ONLY=LIBXL_EXTERNAL_CALLERS_ONLY \
[  380s] >_libxl.api-for-check.new
...
[  380s] libxl.h:260:25: fatal error: _libxl_list.h: No such file or directory
[  380s] compilation terminated.
[  380s] make[3]: *** [_libxl.api-for-check] Error 1
[  381s] if ! cmp -s _libxl_list.h.new _libxl_list.h; then mv -f
_libxl_list.h.new _libxl_list.h; else rm -f _libxl_list.h.new; fi


Fix this be extending the existing libxl.h dependency with the generated
file _libxl_list.h.

Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r ec23c2a11f6f -r da03cd98d2fb tools/libxl/Makefile
--- a/tools/libxl/Makefile
+++ b/tools/libxl/Makefile
@@ -140,7 +140,7 @@ _libxl_save_msgs_helper.h _libxl_save_ms
 	$(PERL) -w $< $@ >$@.new
 	$(call move-if-changed,$@.new,$@)
 
-libxl.h: _libxl_types.h
+libxl.h: _libxl_types.h _libxl_list.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

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 07 09:37:37 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Sep 2012 09: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 1T9v01-0005n7-VJ; Fri, 07 Sep 2012 09:37: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 1T9v00-0005mv-IN
	for xen-devel@lists.xen.org; Fri, 07 Sep 2012 09:37:16 +0000
Received: from [85.158.143.35:30833] by server-1.bemta-4.messagelabs.com id
	91/77-12504-B40C9405; Fri, 07 Sep 2012 09:37:15 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1347010627!15771777!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM4ODU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6470 invoked from network); 7 Sep 2012 09:37:07 -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;
	7 Sep 2012 09:37:07 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 07 Sep 2012 10:37:07 +0100
Message-Id: <5049DC990200007800099AEF@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 07 Sep 2012 10:38:01 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
References: <osstest-13658-mainreport@xen.org>
In-Reply-To: <osstest-13658-mainreport@xen.org>
Mime-Version: 1.0
Content-Disposition: inline
Cc: ian.jackson@eu.citrix.com
Subject: Re: [Xen-devel] [xen-unstable test] 13658: tolerable FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 07.09.12 at 00:55, xen.org <ian.jackson@eu.citrix.com> wrote:
> flight 13658 xen-unstable real [real]
> http://www.chiark.greenend.org.uk/~xensrcts/logs/13658/ 
> 
> Failures :-/ but no regressions.
> 
> Regressions which are regarded as allowable (not blocking):
>  test-amd64-amd64-xl-sedf-pin 10 guest-saverestore            fail   like 13656
>  test-i386-i386-xl-qemuu-winxpsp3  9 guest-localmigrate         fail like 13656
>  test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail like 13656
>  test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail like 13656

Are we not concerned about these recurring failures for
the release?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 07 09:37:37 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Sep 2012 09: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 1T9v01-0005n7-VJ; Fri, 07 Sep 2012 09:37: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 1T9v00-0005mv-IN
	for xen-devel@lists.xen.org; Fri, 07 Sep 2012 09:37:16 +0000
Received: from [85.158.143.35:30833] by server-1.bemta-4.messagelabs.com id
	91/77-12504-B40C9405; Fri, 07 Sep 2012 09:37:15 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1347010627!15771777!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM4ODU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6470 invoked from network); 7 Sep 2012 09:37:07 -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;
	7 Sep 2012 09:37:07 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 07 Sep 2012 10:37:07 +0100
Message-Id: <5049DC990200007800099AEF@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 07 Sep 2012 10:38:01 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
References: <osstest-13658-mainreport@xen.org>
In-Reply-To: <osstest-13658-mainreport@xen.org>
Mime-Version: 1.0
Content-Disposition: inline
Cc: ian.jackson@eu.citrix.com
Subject: Re: [Xen-devel] [xen-unstable test] 13658: tolerable FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 07.09.12 at 00:55, xen.org <ian.jackson@eu.citrix.com> wrote:
> flight 13658 xen-unstable real [real]
> http://www.chiark.greenend.org.uk/~xensrcts/logs/13658/ 
> 
> Failures :-/ but no regressions.
> 
> Regressions which are regarded as allowable (not blocking):
>  test-amd64-amd64-xl-sedf-pin 10 guest-saverestore            fail   like 13656
>  test-i386-i386-xl-qemuu-winxpsp3  9 guest-localmigrate         fail like 13656
>  test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail like 13656
>  test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail like 13656

Are we not concerned about these recurring failures for
the release?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 07 09:47:59 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Sep 2012 09: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 1T9vA9-0005wg-3z; Fri, 07 Sep 2012 09:47:45 +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 1T9vA7-0005wb-Bg
	for xen-devel@lists.xen.org; Fri, 07 Sep 2012 09:47:43 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1347011257!3061226!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTIyMTE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26460 invoked from network); 7 Sep 2012 09:47:37 -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;
	7 Sep 2012 09:47:37 -0000
X-IronPort-AV: E=Sophos;i="4.80,384,1344211200"; d="scan'208";a="14404934"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Sep 2012 09:46: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.279.1; Fri, 7 Sep 2012
	10:46:54 +0100
Message-ID: <1347011213.30018.60.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Fri, 7 Sep 2012 10:46:53 +0100
In-Reply-To: <5049DC990200007800099AEF@nat28.tlf.novell.com>
References: <osstest-13658-mainreport@xen.org>
	<5049DC990200007800099AEF@nat28.tlf.novell.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [xen-unstable test] 13658: tolerable FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-09-07 at 10:38 +0100, Jan Beulich wrote:
> >>> On 07.09.12 at 00:55, xen.org <ian.jackson@eu.citrix.com> wrote:
> > flight 13658 xen-unstable real [real]
> > http://www.chiark.greenend.org.uk/~xensrcts/logs/13658/ 
> > 
> > Failures :-/ but no regressions.
> > 
> > Regressions which are regarded as allowable (not blocking):
> >  test-amd64-amd64-xl-sedf-pin 10 guest-saverestore            fail   like 13656
> >  test-i386-i386-xl-qemuu-winxpsp3  9 guest-localmigrate         fail like 13656
> >  test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail like 13656
> >  test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail like 13656
> 
> Are we not concerned about these recurring failures for
> the release?

Migration is not supported with qemuu (the upstream qemu) since logdirty
is not yet implemented there (Anthony has patches though). Since qemuu
isn't the default this is ok.

We also decided a while back that the sedf pinning bugs were not release
critical (I forget why, someone would have to search the archives to
remember).

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 07 09:47:59 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Sep 2012 09: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 1T9vA9-0005wg-3z; Fri, 07 Sep 2012 09:47:45 +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 1T9vA7-0005wb-Bg
	for xen-devel@lists.xen.org; Fri, 07 Sep 2012 09:47:43 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1347011257!3061226!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTIyMTE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26460 invoked from network); 7 Sep 2012 09:47:37 -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;
	7 Sep 2012 09:47:37 -0000
X-IronPort-AV: E=Sophos;i="4.80,384,1344211200"; d="scan'208";a="14404934"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Sep 2012 09:46: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.279.1; Fri, 7 Sep 2012
	10:46:54 +0100
Message-ID: <1347011213.30018.60.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Fri, 7 Sep 2012 10:46:53 +0100
In-Reply-To: <5049DC990200007800099AEF@nat28.tlf.novell.com>
References: <osstest-13658-mainreport@xen.org>
	<5049DC990200007800099AEF@nat28.tlf.novell.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [xen-unstable test] 13658: tolerable FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-09-07 at 10:38 +0100, Jan Beulich wrote:
> >>> On 07.09.12 at 00:55, xen.org <ian.jackson@eu.citrix.com> wrote:
> > flight 13658 xen-unstable real [real]
> > http://www.chiark.greenend.org.uk/~xensrcts/logs/13658/ 
> > 
> > Failures :-/ but no regressions.
> > 
> > Regressions which are regarded as allowable (not blocking):
> >  test-amd64-amd64-xl-sedf-pin 10 guest-saverestore            fail   like 13656
> >  test-i386-i386-xl-qemuu-winxpsp3  9 guest-localmigrate         fail like 13656
> >  test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail like 13656
> >  test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail like 13656
> 
> Are we not concerned about these recurring failures for
> the release?

Migration is not supported with qemuu (the upstream qemu) since logdirty
is not yet implemented there (Anthony has patches though). Since qemuu
isn't the default this is ok.

We also decided a while back that the sedf pinning bugs were not release
critical (I forget why, someone would have to search the archives to
remember).

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 07 09:53:00 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Sep 2012 09:53:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9vF2-00065W-Rs; Fri, 07 Sep 2012 09:52:48 +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 1T9vF2-00065E-7Z
	for xen-devel@lists.xensource.com; Fri, 07 Sep 2012 09:52:48 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1347011562!3047363!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM4ODU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25289 invoked from network); 7 Sep 2012 09:52:42 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-15.tower-27.messagelabs.com with SMTP;
	7 Sep 2012 09:52:42 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 07 Sep 2012 10:52:45 +0100
Message-Id: <5049E0400200007800099B05@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 07 Sep 2012 10:53:36 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Wei Wang" <wei.wang2@amd.com>, "Sander Eikelenboom" <linux@eikelenboom.it>
References: <504764E2.4000809@amd.com>
	<326589347.20120906005936@eikelenboom.it> <5048A603.3070207@amd.com>
	<483486315.20120906155001@eikelenboom.it> <5048BB29.4040900@amd.com>
	<488803362.20120907093241@eikelenboom.it>
In-Reply-To: <488803362.20120907093241@eikelenboom.it>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] amd iommu: Dump flags of IO page faults
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.09.12 at 09:32, Sander Eikelenboom <linux@eikelenboom.it> wrote:
> 4.1:    Capabilities: [54] MSI: Enable- Count=1/1 Maskable- 64bit+
> 4.2:    Capabilities: [54] MSI: Enable+ Count=1/1 Maskable- 64bit+

No surprise you're not seeing any faults on 4.1 - there's no way
they could get reported. I'm somewhat hesitant to pull the
workaround patch from 4.2 into 4.1, as it's wrong for the kernel
to touch the MSI setting of the IOMMU (which is under the
control of Xen) in the first place, but the kernel side patch I had
submitted a while ago wasn't received well. And that patch isn't
really small, and it would remain to be seen what other
dependencies it would have...

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 07 09:53:00 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Sep 2012 09:53:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9vF2-00065W-Rs; Fri, 07 Sep 2012 09:52:48 +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 1T9vF2-00065E-7Z
	for xen-devel@lists.xensource.com; Fri, 07 Sep 2012 09:52:48 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1347011562!3047363!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM4ODU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25289 invoked from network); 7 Sep 2012 09:52:42 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-15.tower-27.messagelabs.com with SMTP;
	7 Sep 2012 09:52:42 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 07 Sep 2012 10:52:45 +0100
Message-Id: <5049E0400200007800099B05@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 07 Sep 2012 10:53:36 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Wei Wang" <wei.wang2@amd.com>, "Sander Eikelenboom" <linux@eikelenboom.it>
References: <504764E2.4000809@amd.com>
	<326589347.20120906005936@eikelenboom.it> <5048A603.3070207@amd.com>
	<483486315.20120906155001@eikelenboom.it> <5048BB29.4040900@amd.com>
	<488803362.20120907093241@eikelenboom.it>
In-Reply-To: <488803362.20120907093241@eikelenboom.it>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] amd iommu: Dump flags of IO page faults
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.09.12 at 09:32, Sander Eikelenboom <linux@eikelenboom.it> wrote:
> 4.1:    Capabilities: [54] MSI: Enable- Count=1/1 Maskable- 64bit+
> 4.2:    Capabilities: [54] MSI: Enable+ Count=1/1 Maskable- 64bit+

No surprise you're not seeing any faults on 4.1 - there's no way
they could get reported. I'm somewhat hesitant to pull the
workaround patch from 4.2 into 4.1, as it's wrong for the kernel
to touch the MSI setting of the IOMMU (which is under the
control of Xen) in the first place, but the kernel side patch I had
submitted a while ago wasn't received well. And that patch isn't
really small, and it would remain to be seen what other
dependencies it would have...

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 07 10:01:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Sep 2012 10:01:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9vMs-0006JY-Qh; Fri, 07 Sep 2012 10:00:54 +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 1T9vMr-0006JT-RE
	for xen-devel@lists.xensource.com; Fri, 07 Sep 2012 10:00:54 +0000
Received: from [85.158.143.99:3798] by server-1.bemta-4.messagelabs.com id
	82/13-12504-5D5C9405; Fri, 07 Sep 2012 10:00:53 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-12.tower-216.messagelabs.com!1347012046!23840708!1
X-Originating-IP: [188.40.164.121]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4356 invoked from network); 7 Sep 2012 10:00:47 -0000
Received: from static.121.164.40.188.clients.your-server.de (HELO
	smtp.eikelenboom.it) (188.40.164.121)
	by server-12.tower-216.messagelabs.com with AES256-SHA encrypted SMTP;
	7 Sep 2012 10:00:47 -0000
Received: from 128-64-ftth.onsneteindhoven.nl ([88.159.64.128]:51482
	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 1T9vMn-000852-Tt; Fri, 07 Sep 2012 12:00:50 +0200
Date: Fri, 7 Sep 2012 12:00:41 +0200
From: Sander Eikelenboom <linux@eikelenboom.it>
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <1188497031.20120907120041@eikelenboom.it>
To: "Jan Beulich" <JBeulich@suse.com>
In-Reply-To: <5049E0400200007800099B05@nat28.tlf.novell.com>
References: <504764E2.4000809@amd.com>
	<326589347.20120906005936@eikelenboom.it>
	<5048A603.3070207@amd.com>
	<483486315.20120906155001@eikelenboom.it>
	<5048BB29.4040900@amd.com>
	<488803362.20120907093241@eikelenboom.it>
	<5049E0400200007800099B05@nat28.tlf.novell.com>
MIME-Version: 1.0
Cc: Wei Wang <wei.wang2@amd.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] amd iommu: Dump flags of IO page faults
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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, September 7, 2012, 11:53:36 AM, you wrote:

>>>> On 07.09.12 at 09:32, Sander Eikelenboom <linux@eikelenboom.it> wrote:
>> 4.1:    Capabilities: [54] MSI: Enable- Count=1/1 Maskable- 64bit+
>> 4.2:    Capabilities: [54] MSI: Enable+ Count=1/1 Maskable- 64bit+

> No surprise you're not seeing any faults on 4.1 - there's no way
> they could get reported. I'm somewhat hesitant to pull the
> workaround patch from 4.2 into 4.1, as it's wrong for the kernel
> to touch the MSI setting of the IOMMU (which is under the
> control of Xen) in the first place, but the kernel side patch I had
> submitted a while ago wasn't received well. And that patch isn't
> really small, and it would remain to be seen what other
> dependencies it would have...

Ok so that would mean that in the 4.1 case, the IOMMU is doing nothing ?

Because if the IOMMU is working, i  would say:
           a) isn't it a bit strange that everything keeps working, although it should report the IO PAGE FAULT ?
           b) is the IO PAGE FAULT correct anyway, since the device keeps working fine ?


> Jan




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 07 10:01:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Sep 2012 10:01:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9vMs-0006JY-Qh; Fri, 07 Sep 2012 10:00:54 +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 1T9vMr-0006JT-RE
	for xen-devel@lists.xensource.com; Fri, 07 Sep 2012 10:00:54 +0000
Received: from [85.158.143.99:3798] by server-1.bemta-4.messagelabs.com id
	82/13-12504-5D5C9405; Fri, 07 Sep 2012 10:00:53 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-12.tower-216.messagelabs.com!1347012046!23840708!1
X-Originating-IP: [188.40.164.121]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4356 invoked from network); 7 Sep 2012 10:00:47 -0000
Received: from static.121.164.40.188.clients.your-server.de (HELO
	smtp.eikelenboom.it) (188.40.164.121)
	by server-12.tower-216.messagelabs.com with AES256-SHA encrypted SMTP;
	7 Sep 2012 10:00:47 -0000
Received: from 128-64-ftth.onsneteindhoven.nl ([88.159.64.128]:51482
	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 1T9vMn-000852-Tt; Fri, 07 Sep 2012 12:00:50 +0200
Date: Fri, 7 Sep 2012 12:00:41 +0200
From: Sander Eikelenboom <linux@eikelenboom.it>
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <1188497031.20120907120041@eikelenboom.it>
To: "Jan Beulich" <JBeulich@suse.com>
In-Reply-To: <5049E0400200007800099B05@nat28.tlf.novell.com>
References: <504764E2.4000809@amd.com>
	<326589347.20120906005936@eikelenboom.it>
	<5048A603.3070207@amd.com>
	<483486315.20120906155001@eikelenboom.it>
	<5048BB29.4040900@amd.com>
	<488803362.20120907093241@eikelenboom.it>
	<5049E0400200007800099B05@nat28.tlf.novell.com>
MIME-Version: 1.0
Cc: Wei Wang <wei.wang2@amd.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] amd iommu: Dump flags of IO page faults
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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, September 7, 2012, 11:53:36 AM, you wrote:

>>>> On 07.09.12 at 09:32, Sander Eikelenboom <linux@eikelenboom.it> wrote:
>> 4.1:    Capabilities: [54] MSI: Enable- Count=1/1 Maskable- 64bit+
>> 4.2:    Capabilities: [54] MSI: Enable+ Count=1/1 Maskable- 64bit+

> No surprise you're not seeing any faults on 4.1 - there's no way
> they could get reported. I'm somewhat hesitant to pull the
> workaround patch from 4.2 into 4.1, as it's wrong for the kernel
> to touch the MSI setting of the IOMMU (which is under the
> control of Xen) in the first place, but the kernel side patch I had
> submitted a while ago wasn't received well. And that patch isn't
> really small, and it would remain to be seen what other
> dependencies it would have...

Ok so that would mean that in the 4.1 case, the IOMMU is doing nothing ?

Because if the IOMMU is working, i  would say:
           a) isn't it a bit strange that everything keeps working, although it should report the IO PAGE FAULT ?
           b) is the IO PAGE FAULT correct anyway, since the device keeps working fine ?


> Jan




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 07 10:01:54 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Sep 2012 10: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 1T9vNe-0006M8-8H; Fri, 07 Sep 2012 10:01:42 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <linux@eikelenboom.it>) id 1T9vNc-0006M0-2x
	for xen-devel@lists.xensource.com; Fri, 07 Sep 2012 10:01:40 +0000
Received: from [85.158.139.83:49836] by server-1.bemta-5.messagelabs.com id
	11/B9-32692-306C9405; Fri, 07 Sep 2012 10:01:39 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-13.tower-182.messagelabs.com!1347012097!28602868!1
X-Originating-IP: [188.40.164.121]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18616 invoked from network); 7 Sep 2012 10:01:38 -0000
Received: from static.121.164.40.188.clients.your-server.de (HELO
	smtp.eikelenboom.it) (188.40.164.121)
	by server-13.tower-182.messagelabs.com with AES256-SHA encrypted SMTP;
	7 Sep 2012 10:01:38 -0000
Received: from 128-64-ftth.onsneteindhoven.nl ([88.159.64.128]:51486
	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 1T9vNd-00085E-5D; Fri, 07 Sep 2012 12:01:41 +0200
Date: Fri, 7 Sep 2012 12:01:33 +0200
From: Sander Eikelenboom <linux@eikelenboom.it>
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <1144069450.20120907120133@eikelenboom.it>
To: Wei Wang <wei.wang2@amd.com>
In-Reply-To: <5049B650.4080101@amd.com>
References: <504764E2.4000809@amd.com>
	<326589347.20120906005936@eikelenboom.it>
	<5048A603.3070207@amd.com>
	<483486315.20120906155001@eikelenboom.it>
	<5048BB29.4040900@amd.com>
	<488803362.20120907093241@eikelenboom.it>
	<5049B650.4080101@amd.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH] amd iommu: Dump flags of IO page faults
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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, September 7, 2012, 10:54:40 AM, you wrote:

> On 09/07/2012 09:32 AM, Sander Eikelenboom wrote:
>>
>> Thursday, September 6, 2012, 5:03:05 PM, you wrote:
>>
>>> On 09/06/2012 03:50 PM, Sander Eikelenboom wrote:
>>>>
>>>> Thursday, September 6, 2012, 3:32:51 PM, you wrote:
>>>>
>>>>> On 09/06/2012 12:59 AM, Sander Eikelenboom wrote:
>>>>>>
>>>>>> Wednesday, September 5, 2012, 4:42:42 PM, you wrote:
>>>>>>
>>>>>>> Hi Jan,
>>>>>>> Attached patch dumps io page fault flags. The flags show the reason of
>>>>>>> the fault and tell us if this is an unmapped interrupt fault or a DMA fault.
>>>>>>
>>>>>>> Thanks,
>>>>>>> Wei
>>>>>>
>>>>>>> signed-off-by: Wei Wang<wei.wang2@amd.com>
>>>>>>
>>>>>>
>>>>>> I have applied the patch and the flags seem to differ between the faults:
>>>>>>
>>>>>> AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0a06, fault address = 0xc2c2c2c0, flags = 0x000
>>>>>> (XEN) [2012-09-05 20:54:16] AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0a06, fault address = 0xc2c2c2c0, flags = 0x000
>>>>>> (XEN) [2012-09-05 20:54:16] AMD-Vi: IO_PAGE_FAULT: domain = 14, device id = 0x0700, fault address = 0xa8d339e0, flags = 0x020
>>>>>> (XEN) [2012-09-05 20:54:16] AMD-Vi: IO_PAGE_FAULT: domain = 14, device id = 0x0700, fault address = 0xa8d33a40, flags = 0x020
>>>>
>>>>> OK, so they are not interrupt requests. I guess further information from
>>>>> your system would be helpful to debug this issue:
>>>>> 1) xl info
>>>>> 2) xl list
>>>>> 3) lscpi -vvv (NOTE: not in dom0 but in your guest)
>>>>> 4) cat /proc/iomem (in both dom0 and your hvm guest)
>>>>
>>>> dom14 is not a HVM guest,it's a PV guest.
>>
>>> Ah, I see. PV guest is quite different than hvm, it does use p2m tables
>>> as io page tables. So no-sharept option does not work in this case. PV
>>> guests always use separated io page tables. There might be some
>>> incorrect mappings on the page tables. I will check this on my side.
>>
>> I have reverted the machine to xen-4.1.4-pre (changeset 23353) and kept everything else the same.
>> I haven't seen any IO PAGE FAULTS after that.
>>
>> I did spot some differences in the output from lspci between xen 4.1 and 4.2, related to MSI enabled or not for the IOMMU device.
>> Have attached the xl/xm dmesg and lspci from booting with both versions.
>>
>> lspci:
>>
>> 00:00.2 Generic system peripheral [0806]: ATI Technologies Inc RD990 I/O Memory Management Unit (IOMMU) [1002:5a23]
>>          Subsystem: ATI Technologies Inc RD990 I/O Memory Management Unit (IOMMU) [1002:5a23]
>>          Control: I/O- Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
>>          Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast>TAbort-<TAbort-<MAbort->SERR-<PERR- INTx-
>>          Latency: 0
>>          Interrupt: pin A routed to IRQ 10
>>          Capabilities: [40] Secure device<?>
>> 4.1:    Capabilities: [54] MSI: Enable- Count=1/1 Maskable- 64bit+

> Eh... That is interesting. So which dom0 are you using?  There is a c/s 
> in 4.2 to prevent recent dom0 to disable iommu interrupt (changeset 
> 25492:61844569a432) Otherwise, iommu cannot send any events including IO 
> PAGE faults. You could try to revert dom0 to an old version like 2.6 
> pv_ops to see if you really have no io page faults on 4.1

Ok i will give that a try, only dom0 will have to be a 2.6 pv_ops i assume ?


>> 4.2:    Capabilities: [54] MSI: Enable+ Count=1/1 Maskable- 64bit+
>>                  Address: 00000000fee0100c  Data: 4128
>>          Capabilities: [64] HyperTransport: MSI Mapping Enable+ Fixed+
>>
>> Although it seems enabled, shouldn't the IRQ number used be much higher than 10 for MSI interrupts ?

> The IRQ number is fine. MSI vector is stored at  Data: 4128

>>
>> There is another difference in the bridge device that's in front of the  0a:00.6 device that faults before the kernel is even booted.
>>
>> 00:03.0 PCI bridge [0604]: ATI Technologies Inc RD890 PCI to PCI bridge (PCI express gpp port C) [1002:5a17] (prog-if 00 [Normal decode])
>>          Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx+
>> 4.1:    Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast>TAbort-<TAbort-<MAbort->SERR-<PERR- INTx-
>> 4.2:    Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast>TAbort-<TAbort+<MAbort->SERR-<PERR- INTx-
>>          Latency: 0, Cache Line Size: 64 bytes
>>          Bus: primary=00, secondary=0a, subordinate=0a, sec-latency=0
>>          I/O behind bridge: 0000f000-00000fff
>>          Memory behind bridge: f9f00000-f9ffffff
>>          Prefetchable memory behind bridge: 00000000fff00000-00000000000fffff
>> 4.1:    Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast>TAbort-<TAbort-<MAbort-<SERR-<PERR-
>> 4.2:    Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast>TAbort+<TAbort-<MAbort-<SERR-<PERR-
>>          BridgeCtl: Parity+ SERR+ NoISA+ VGA- MAbort->Reset- FastB2B-
>>                  PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
>>          Capabilities: [50] Power Management version 3
>>                  Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
>>                  Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
>>          Capabilities: [58] Express (v2) Root Port (Slot+), MSI 00
>>                  DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s<64ns, L1<1us
>>                          ExtTag+ RBE+ FLReset-
>>                  DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
>>                          RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+
>>                          MaxPayload 128 bytes, MaxReadReq 128 bytes
>>                  DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr- TransPend-
>>                  LnkCap: Port #1, Speed 5GT/s, Width x8, ASPM L0s L1, Latency L0<1us, L1<8us
>>                          ClockPM- Surprise- LLActRep+ BwNot+
>>                  LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommClk-
>>                          ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
>>                  LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive+ BWMgmt+ ABWMgmt-
>>                  SltCap: AttnBtn- PwrCtrl- MRL- AttnInd- PwrInd- HotPlug- Surprise-
>>                          Slot #3, PowerLimit 10.000W; Interlock- NoCompl+
>>                  SltCtl: Enable: AttnBtn- PwrFlt- MRL- PresDet- CmdCplt- HPIrq- LinkChg-
>>                          Control: AttnInd Unknown, PwrInd Unknown, Power- Interlock-
>>                  SltSta: Status: AttnBtn- PowerFlt- MRL- CmdCplt- PresDet+ Interlock-
>>                          Changed: MRL- PresDet+ LinkState+

> The probably because of the IO_PAGE_FAULT.

> Thanks,
> Wei

>> serveerstertje:~# lspci -t
>> -[0000:00]-+-00.0
>>             +-00.2
>>             +-02.0-[0b]----00.0
>>             +-03.0-[0a]--+-00.0
>>             |            +-00.1
>>             |            +-00.2
>>             |            +-00.3
>>             |            +-00.4
>>             |            +-00.5
>>             |            +-00.6
>>             |            \-00.7
>>             +-05.0-[09]----00.0
>>             +-06.0-[08]----00.0
>>             +-0a.0-[07]----00.0
>>             +-0b.0-[06]--+-00.0
>>             |            \-00.1
>>             +-0c.0-[05]----00.0
>>             +-0d.0-[04]--+-00.0
>>             |            +-00.1
>>             |            +-00.2
>>             |            +-00.3
>>             |            +-00.4
>>             |            +-00.5
>>             |            +-00.6
>>             |            \-00.7
>>             +-11.0
>>             +-12.0
>>             +-12.2
>>             +-13.0
>>             +-13.2
>>             +-14.0
>>             +-14.3
>>             +-14.4-[03]----06.0
>>             +-14.5
>>             +-15.0-[02]--
>>             +-16.0
>>             +-16.2
>>             +-18.0
>>             +-18.1
>>             +-18.2
>>             +-18.3
>>             \-18.4
>>
>>
>>
>>
>>
>>> Thanks,
>>> Wei
>>
>>>> I will try to make a complete package, and try with one pv domain only where the devices are being passed through just to simplify the setup.
>>>>
>>>>
>>>>> * I would also like to know the symptoms of device 0x0700 when IO_PF
>>>>> happened. Did it stop working?
>>>>
>>>> Yes it stops working, the video capture just freezes, but the driver doesn't bail out.
>>>> For the USB controller (0x0a06) it starts to give errors for usbdev_open in the guest.
>>>>
>>>>> (BTW: I copied a few options from your boot cmd line and it worked with
>>>>> my RD890 system
>>>>
>>>>> dom0_mem=1024M,max:1024M loglvl=all loglvl_guest=all console_timestamps
>>>>> cpuidle cpufreq=xen noreboot debug lapic=debug apic_verbosity=debug
>>>>> apic=debug iommu=on,verbose,debug,no-sharept
>>>>
>>>>> * so, what OEM board you have?)
>>>>
>>>> MSI 890FXA-GD70
>>>>
>>>>> Also from your log, these lines looks very strange:
>>>>
>>>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>>>>> read-only memory page. gfn=0xd5, mfn=0xa4a11
>>>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>>>>> read-only memory page. gfn=0xd7, mfn=0xa4a0f
>>>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>>>>> read-only memory page. gfn=0xd9, mfn=0xa4a0d
>>>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>>>>> read-only memory page. gfn=0xdb, mfn=0xa4a0b
>>>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>>>>> read-only memory page. gfn=0xdd, mfn=0xa4a09
>>>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>>>>> read-only memory page. gfn=0xdf, mfn=0xa4a07
>>>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>>>>> read-only memory page. gfn=0xe1, mfn=0xa4a05
>>>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>>>>> read-only memory page. gfn=0xe3, mfn=0xa4a03
>>>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>>>>> read-only memory page. gfn=0xe5, mfn=0xa4a01
>>>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>>>>> read-only memory page. gfn=0xe7, mfn=0xa463f
>>>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>>>>> read-only memory page. gfn=0xe9, mfn=0xa463d
>>>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>>>>> read-only memory page. gfn=0xeb, mfn=0xa463b
>>>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>>>>> read-only memory page. gfn=0xed, mfn=0xa4639
>>>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>>>>> read-only memory page. gfn=0xef, mfn=0xa4637
>>>>> (XEN) [2012-09-04 16:13:56] AMD-Vi: IO_PAGE_FAULT: domain = 0, device id
>>>>> = 0x0a06, fault address = 0xc2c2c2c0
>>>>> (XEN) [2012-09-04 16:13:56] AMD-Vi: IO_PAGE_FAULT: domain = 14, device
>>>>> id = 0x0700, fault address = 0xa90f8300
>>>>> (XEN) [2012-09-04 16:13:56] AMD-Vi: IO_PAGE_FAULT: domain = 14, device
>>>>> id = 0x0700, fault address = 0xa90f8340
>>>>> (XEN) [2012-09-04 16:13:56] AMD-Vi: IO_PAGE_FAULT: domain = 14, device
>>>>> id = 0x0700, fault address = 0xa90f8380
>>>>> (XEN) [2012-09-04 16:13:56] AMD-Vi: IO_PAGE_FAULT: domain = 14, device
>>>>> id = 0x0700, fault address = 0xa90f83c0
>>>>
>>>>> * they are just followed by the IO PAGE fault. Do you know where are
>>>>> they from? Your video card driver maybe?
>>>>
>>>>    From a HVM domain with a old (3.0.3) kernel, but the faults also occur without this domain being started.
>>>>
>>>>
>>>>> Thanks,
>>>>> Wei
>>>>
>>>>
>>>>>> Complete xl dmesg and lspci -vvvknn attached.
>>>>>>
>>>>>> Thx
>>>>>>
>>>>>> --
>>>>>> Sander
>>>>
>>>>
>>>>
>>>>
>>>>
>>
>>





_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 07 10:01:54 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Sep 2012 10: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 1T9vNe-0006M8-8H; Fri, 07 Sep 2012 10:01:42 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <linux@eikelenboom.it>) id 1T9vNc-0006M0-2x
	for xen-devel@lists.xensource.com; Fri, 07 Sep 2012 10:01:40 +0000
Received: from [85.158.139.83:49836] by server-1.bemta-5.messagelabs.com id
	11/B9-32692-306C9405; Fri, 07 Sep 2012 10:01:39 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-13.tower-182.messagelabs.com!1347012097!28602868!1
X-Originating-IP: [188.40.164.121]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18616 invoked from network); 7 Sep 2012 10:01:38 -0000
Received: from static.121.164.40.188.clients.your-server.de (HELO
	smtp.eikelenboom.it) (188.40.164.121)
	by server-13.tower-182.messagelabs.com with AES256-SHA encrypted SMTP;
	7 Sep 2012 10:01:38 -0000
Received: from 128-64-ftth.onsneteindhoven.nl ([88.159.64.128]:51486
	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 1T9vNd-00085E-5D; Fri, 07 Sep 2012 12:01:41 +0200
Date: Fri, 7 Sep 2012 12:01:33 +0200
From: Sander Eikelenboom <linux@eikelenboom.it>
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <1144069450.20120907120133@eikelenboom.it>
To: Wei Wang <wei.wang2@amd.com>
In-Reply-To: <5049B650.4080101@amd.com>
References: <504764E2.4000809@amd.com>
	<326589347.20120906005936@eikelenboom.it>
	<5048A603.3070207@amd.com>
	<483486315.20120906155001@eikelenboom.it>
	<5048BB29.4040900@amd.com>
	<488803362.20120907093241@eikelenboom.it>
	<5049B650.4080101@amd.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH] amd iommu: Dump flags of IO page faults
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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, September 7, 2012, 10:54:40 AM, you wrote:

> On 09/07/2012 09:32 AM, Sander Eikelenboom wrote:
>>
>> Thursday, September 6, 2012, 5:03:05 PM, you wrote:
>>
>>> On 09/06/2012 03:50 PM, Sander Eikelenboom wrote:
>>>>
>>>> Thursday, September 6, 2012, 3:32:51 PM, you wrote:
>>>>
>>>>> On 09/06/2012 12:59 AM, Sander Eikelenboom wrote:
>>>>>>
>>>>>> Wednesday, September 5, 2012, 4:42:42 PM, you wrote:
>>>>>>
>>>>>>> Hi Jan,
>>>>>>> Attached patch dumps io page fault flags. The flags show the reason of
>>>>>>> the fault and tell us if this is an unmapped interrupt fault or a DMA fault.
>>>>>>
>>>>>>> Thanks,
>>>>>>> Wei
>>>>>>
>>>>>>> signed-off-by: Wei Wang<wei.wang2@amd.com>
>>>>>>
>>>>>>
>>>>>> I have applied the patch and the flags seem to differ between the faults:
>>>>>>
>>>>>> AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0a06, fault address = 0xc2c2c2c0, flags = 0x000
>>>>>> (XEN) [2012-09-05 20:54:16] AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0a06, fault address = 0xc2c2c2c0, flags = 0x000
>>>>>> (XEN) [2012-09-05 20:54:16] AMD-Vi: IO_PAGE_FAULT: domain = 14, device id = 0x0700, fault address = 0xa8d339e0, flags = 0x020
>>>>>> (XEN) [2012-09-05 20:54:16] AMD-Vi: IO_PAGE_FAULT: domain = 14, device id = 0x0700, fault address = 0xa8d33a40, flags = 0x020
>>>>
>>>>> OK, so they are not interrupt requests. I guess further information from
>>>>> your system would be helpful to debug this issue:
>>>>> 1) xl info
>>>>> 2) xl list
>>>>> 3) lscpi -vvv (NOTE: not in dom0 but in your guest)
>>>>> 4) cat /proc/iomem (in both dom0 and your hvm guest)
>>>>
>>>> dom14 is not a HVM guest,it's a PV guest.
>>
>>> Ah, I see. PV guest is quite different than hvm, it does use p2m tables
>>> as io page tables. So no-sharept option does not work in this case. PV
>>> guests always use separated io page tables. There might be some
>>> incorrect mappings on the page tables. I will check this on my side.
>>
>> I have reverted the machine to xen-4.1.4-pre (changeset 23353) and kept everything else the same.
>> I haven't seen any IO PAGE FAULTS after that.
>>
>> I did spot some differences in the output from lspci between xen 4.1 and 4.2, related to MSI enabled or not for the IOMMU device.
>> Have attached the xl/xm dmesg and lspci from booting with both versions.
>>
>> lspci:
>>
>> 00:00.2 Generic system peripheral [0806]: ATI Technologies Inc RD990 I/O Memory Management Unit (IOMMU) [1002:5a23]
>>          Subsystem: ATI Technologies Inc RD990 I/O Memory Management Unit (IOMMU) [1002:5a23]
>>          Control: I/O- Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
>>          Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast>TAbort-<TAbort-<MAbort->SERR-<PERR- INTx-
>>          Latency: 0
>>          Interrupt: pin A routed to IRQ 10
>>          Capabilities: [40] Secure device<?>
>> 4.1:    Capabilities: [54] MSI: Enable- Count=1/1 Maskable- 64bit+

> Eh... That is interesting. So which dom0 are you using?  There is a c/s 
> in 4.2 to prevent recent dom0 to disable iommu interrupt (changeset 
> 25492:61844569a432) Otherwise, iommu cannot send any events including IO 
> PAGE faults. You could try to revert dom0 to an old version like 2.6 
> pv_ops to see if you really have no io page faults on 4.1

Ok i will give that a try, only dom0 will have to be a 2.6 pv_ops i assume ?


>> 4.2:    Capabilities: [54] MSI: Enable+ Count=1/1 Maskable- 64bit+
>>                  Address: 00000000fee0100c  Data: 4128
>>          Capabilities: [64] HyperTransport: MSI Mapping Enable+ Fixed+
>>
>> Although it seems enabled, shouldn't the IRQ number used be much higher than 10 for MSI interrupts ?

> The IRQ number is fine. MSI vector is stored at  Data: 4128

>>
>> There is another difference in the bridge device that's in front of the  0a:00.6 device that faults before the kernel is even booted.
>>
>> 00:03.0 PCI bridge [0604]: ATI Technologies Inc RD890 PCI to PCI bridge (PCI express gpp port C) [1002:5a17] (prog-if 00 [Normal decode])
>>          Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx+
>> 4.1:    Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast>TAbort-<TAbort-<MAbort->SERR-<PERR- INTx-
>> 4.2:    Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast>TAbort-<TAbort+<MAbort->SERR-<PERR- INTx-
>>          Latency: 0, Cache Line Size: 64 bytes
>>          Bus: primary=00, secondary=0a, subordinate=0a, sec-latency=0
>>          I/O behind bridge: 0000f000-00000fff
>>          Memory behind bridge: f9f00000-f9ffffff
>>          Prefetchable memory behind bridge: 00000000fff00000-00000000000fffff
>> 4.1:    Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast>TAbort-<TAbort-<MAbort-<SERR-<PERR-
>> 4.2:    Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast>TAbort+<TAbort-<MAbort-<SERR-<PERR-
>>          BridgeCtl: Parity+ SERR+ NoISA+ VGA- MAbort->Reset- FastB2B-
>>                  PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
>>          Capabilities: [50] Power Management version 3
>>                  Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
>>                  Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
>>          Capabilities: [58] Express (v2) Root Port (Slot+), MSI 00
>>                  DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s<64ns, L1<1us
>>                          ExtTag+ RBE+ FLReset-
>>                  DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
>>                          RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+
>>                          MaxPayload 128 bytes, MaxReadReq 128 bytes
>>                  DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr- TransPend-
>>                  LnkCap: Port #1, Speed 5GT/s, Width x8, ASPM L0s L1, Latency L0<1us, L1<8us
>>                          ClockPM- Surprise- LLActRep+ BwNot+
>>                  LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommClk-
>>                          ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
>>                  LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive+ BWMgmt+ ABWMgmt-
>>                  SltCap: AttnBtn- PwrCtrl- MRL- AttnInd- PwrInd- HotPlug- Surprise-
>>                          Slot #3, PowerLimit 10.000W; Interlock- NoCompl+
>>                  SltCtl: Enable: AttnBtn- PwrFlt- MRL- PresDet- CmdCplt- HPIrq- LinkChg-
>>                          Control: AttnInd Unknown, PwrInd Unknown, Power- Interlock-
>>                  SltSta: Status: AttnBtn- PowerFlt- MRL- CmdCplt- PresDet+ Interlock-
>>                          Changed: MRL- PresDet+ LinkState+

> The probably because of the IO_PAGE_FAULT.

> Thanks,
> Wei

>> serveerstertje:~# lspci -t
>> -[0000:00]-+-00.0
>>             +-00.2
>>             +-02.0-[0b]----00.0
>>             +-03.0-[0a]--+-00.0
>>             |            +-00.1
>>             |            +-00.2
>>             |            +-00.3
>>             |            +-00.4
>>             |            +-00.5
>>             |            +-00.6
>>             |            \-00.7
>>             +-05.0-[09]----00.0
>>             +-06.0-[08]----00.0
>>             +-0a.0-[07]----00.0
>>             +-0b.0-[06]--+-00.0
>>             |            \-00.1
>>             +-0c.0-[05]----00.0
>>             +-0d.0-[04]--+-00.0
>>             |            +-00.1
>>             |            +-00.2
>>             |            +-00.3
>>             |            +-00.4
>>             |            +-00.5
>>             |            +-00.6
>>             |            \-00.7
>>             +-11.0
>>             +-12.0
>>             +-12.2
>>             +-13.0
>>             +-13.2
>>             +-14.0
>>             +-14.3
>>             +-14.4-[03]----06.0
>>             +-14.5
>>             +-15.0-[02]--
>>             +-16.0
>>             +-16.2
>>             +-18.0
>>             +-18.1
>>             +-18.2
>>             +-18.3
>>             \-18.4
>>
>>
>>
>>
>>
>>> Thanks,
>>> Wei
>>
>>>> I will try to make a complete package, and try with one pv domain only where the devices are being passed through just to simplify the setup.
>>>>
>>>>
>>>>> * I would also like to know the symptoms of device 0x0700 when IO_PF
>>>>> happened. Did it stop working?
>>>>
>>>> Yes it stops working, the video capture just freezes, but the driver doesn't bail out.
>>>> For the USB controller (0x0a06) it starts to give errors for usbdev_open in the guest.
>>>>
>>>>> (BTW: I copied a few options from your boot cmd line and it worked with
>>>>> my RD890 system
>>>>
>>>>> dom0_mem=1024M,max:1024M loglvl=all loglvl_guest=all console_timestamps
>>>>> cpuidle cpufreq=xen noreboot debug lapic=debug apic_verbosity=debug
>>>>> apic=debug iommu=on,verbose,debug,no-sharept
>>>>
>>>>> * so, what OEM board you have?)
>>>>
>>>> MSI 890FXA-GD70
>>>>
>>>>> Also from your log, these lines looks very strange:
>>>>
>>>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>>>>> read-only memory page. gfn=0xd5, mfn=0xa4a11
>>>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>>>>> read-only memory page. gfn=0xd7, mfn=0xa4a0f
>>>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>>>>> read-only memory page. gfn=0xd9, mfn=0xa4a0d
>>>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>>>>> read-only memory page. gfn=0xdb, mfn=0xa4a0b
>>>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>>>>> read-only memory page. gfn=0xdd, mfn=0xa4a09
>>>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>>>>> read-only memory page. gfn=0xdf, mfn=0xa4a07
>>>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>>>>> read-only memory page. gfn=0xe1, mfn=0xa4a05
>>>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>>>>> read-only memory page. gfn=0xe3, mfn=0xa4a03
>>>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>>>>> read-only memory page. gfn=0xe5, mfn=0xa4a01
>>>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>>>>> read-only memory page. gfn=0xe7, mfn=0xa463f
>>>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>>>>> read-only memory page. gfn=0xe9, mfn=0xa463d
>>>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>>>>> read-only memory page. gfn=0xeb, mfn=0xa463b
>>>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>>>>> read-only memory page. gfn=0xed, mfn=0xa4639
>>>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>>>>> read-only memory page. gfn=0xef, mfn=0xa4637
>>>>> (XEN) [2012-09-04 16:13:56] AMD-Vi: IO_PAGE_FAULT: domain = 0, device id
>>>>> = 0x0a06, fault address = 0xc2c2c2c0
>>>>> (XEN) [2012-09-04 16:13:56] AMD-Vi: IO_PAGE_FAULT: domain = 14, device
>>>>> id = 0x0700, fault address = 0xa90f8300
>>>>> (XEN) [2012-09-04 16:13:56] AMD-Vi: IO_PAGE_FAULT: domain = 14, device
>>>>> id = 0x0700, fault address = 0xa90f8340
>>>>> (XEN) [2012-09-04 16:13:56] AMD-Vi: IO_PAGE_FAULT: domain = 14, device
>>>>> id = 0x0700, fault address = 0xa90f8380
>>>>> (XEN) [2012-09-04 16:13:56] AMD-Vi: IO_PAGE_FAULT: domain = 14, device
>>>>> id = 0x0700, fault address = 0xa90f83c0
>>>>
>>>>> * they are just followed by the IO PAGE fault. Do you know where are
>>>>> they from? Your video card driver maybe?
>>>>
>>>>    From a HVM domain with a old (3.0.3) kernel, but the faults also occur without this domain being started.
>>>>
>>>>
>>>>> Thanks,
>>>>> Wei
>>>>
>>>>
>>>>>> Complete xl dmesg and lspci -vvvknn attached.
>>>>>>
>>>>>> Thx
>>>>>>
>>>>>> --
>>>>>> Sander
>>>>
>>>>
>>>>
>>>>
>>>>
>>
>>





_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 07 10:03:46 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Sep 2012 10:03: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 1T9vPN-0006Wc-UA; Fri, 07 Sep 2012 10:03: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 1T9vPN-0006WD-4u
	for xen-devel@lists.xen.org; Fri, 07 Sep 2012 10:03:29 +0000
Received: from [85.158.143.35:48571] by server-2.bemta-4.messagelabs.com id
	3D/F8-21239-076C9405; Fri, 07 Sep 2012 10:03:28 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1347012207!6100300!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM4ODU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26911 invoked from network); 7 Sep 2012 10:03:28 -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;
	7 Sep 2012 10:03:28 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 07 Sep 2012 11:03:34 +0100
Message-Id: <5049E2C70200007800099B21@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 07 Sep 2012 11:04:23 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Tim Deegan" <tim@xen.org>
References: <CAFw--Dd0k7L+T_UJc0yHAkUGrY_-GDHaQjK3OM-1UdOp=J-wAQ@mail.gmail.com>
	<20120907085036.GA71093@ocelot.phlegethon.org>
In-Reply-To: <20120907085036.GA71093@ocelot.phlegethon.org>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Jeffrey Karrels <karrelsj@gmail.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Clang/LLVM version requirements
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.09.12 at 10:50, Tim Deegan <tim@xen.org> wrote:
> Jan, would you object to some other way of checking for .bss in reloc.c?

No, if you have a better idea.

> Could we just objcopy it out so any BSS symbols make it fail at link
> time?

Would that reliably fail with all linker versions?

> In any case we probably ought to check for stray .data symbols too.

Not really, no. Those would still be present in reloc.bin, and
hence make it into reloc.S.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 07 10:03:46 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Sep 2012 10:03: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 1T9vPN-0006Wc-UA; Fri, 07 Sep 2012 10:03: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 1T9vPN-0006WD-4u
	for xen-devel@lists.xen.org; Fri, 07 Sep 2012 10:03:29 +0000
Received: from [85.158.143.35:48571] by server-2.bemta-4.messagelabs.com id
	3D/F8-21239-076C9405; Fri, 07 Sep 2012 10:03:28 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1347012207!6100300!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM4ODU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26911 invoked from network); 7 Sep 2012 10:03:28 -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;
	7 Sep 2012 10:03:28 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 07 Sep 2012 11:03:34 +0100
Message-Id: <5049E2C70200007800099B21@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 07 Sep 2012 11:04:23 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Tim Deegan" <tim@xen.org>
References: <CAFw--Dd0k7L+T_UJc0yHAkUGrY_-GDHaQjK3OM-1UdOp=J-wAQ@mail.gmail.com>
	<20120907085036.GA71093@ocelot.phlegethon.org>
In-Reply-To: <20120907085036.GA71093@ocelot.phlegethon.org>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Jeffrey Karrels <karrelsj@gmail.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Clang/LLVM version requirements
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.09.12 at 10:50, Tim Deegan <tim@xen.org> wrote:
> Jan, would you object to some other way of checking for .bss in reloc.c?

No, if you have a better idea.

> Could we just objcopy it out so any BSS symbols make it fail at link
> time?

Would that reliably fail with all linker versions?

> In any case we probably ought to check for stray .data symbols too.

Not really, no. Those would still be present in reloc.bin, and
hence make it into reloc.S.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 07 10:05:55 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Sep 2012 10:05:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9vRY-0006o9-JG; Fri, 07 Sep 2012 10:05: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 1T9vRW-0006nv-U4
	for xen-devel@lists.xensource.com; Fri, 07 Sep 2012 10:05:43 +0000
Received: from [85.158.143.35:5592] by server-3.bemta-4.messagelabs.com id
	83/A8-08232-6F6C9405; Fri, 07 Sep 2012 10:05:42 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1347012341!11999631!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM4ODU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22920 invoked from network); 7 Sep 2012 10:05:41 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-11.tower-21.messagelabs.com with SMTP;
	7 Sep 2012 10:05:41 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 07 Sep 2012 11:05:43 +0100
Message-Id: <5049E3470200007800099B3F@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 07 Sep 2012 11:06:31 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Sander Eikelenboom" <linux@eikelenboom.it>
References: <504764E2.4000809@amd.com>
	<326589347.20120906005936@eikelenboom.it> <5048A603.3070207@amd.com>
	<483486315.20120906155001@eikelenboom.it> <5048BB29.4040900@amd.com>
	<488803362.20120907093241@eikelenboom.it>
	<5049E0400200007800099B05@nat28.tlf.novell.com>
	<1188497031.20120907120041@eikelenboom.it>
In-Reply-To: <1188497031.20120907120041@eikelenboom.it>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Wei Wang <wei.wang2@amd.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] amd iommu: Dump flags of IO page faults
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.09.12 at 12:00, Sander Eikelenboom <linux@eikelenboom.it> wrote:

> Friday, September 7, 2012, 11:53:36 AM, you wrote:
> 
>>>>> On 07.09.12 at 09:32, Sander Eikelenboom <linux@eikelenboom.it> wrote:
>>> 4.1:    Capabilities: [54] MSI: Enable- Count=1/1 Maskable- 64bit+
>>> 4.2:    Capabilities: [54] MSI: Enable+ Count=1/1 Maskable- 64bit+
> 
>> No surprise you're not seeing any faults on 4.1 - there's no way
>> they could get reported. I'm somewhat hesitant to pull the
>> workaround patch from 4.2 into 4.1, as it's wrong for the kernel
>> to touch the MSI setting of the IOMMU (which is under the
>> control of Xen) in the first place, but the kernel side patch I had
>> submitted a while ago wasn't received well. And that patch isn't
>> really small, and it would remain to be seen what other
>> dependencies it would have...
> 
> Ok so that would mean that in the 4.1 case, the IOMMU is doing nothing ?

No, it just can't report faults (they would need to be polled for).
Also, saying "in the 4.1 case" is wrong here - this really depends
on whether you have an affected Dom0 kernel. Things work fine
if the Dom0 kernel doesn't trample over Xen's setup.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 07 10:05:55 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Sep 2012 10:05:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9vRY-0006o9-JG; Fri, 07 Sep 2012 10:05: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 1T9vRW-0006nv-U4
	for xen-devel@lists.xensource.com; Fri, 07 Sep 2012 10:05:43 +0000
Received: from [85.158.143.35:5592] by server-3.bemta-4.messagelabs.com id
	83/A8-08232-6F6C9405; Fri, 07 Sep 2012 10:05:42 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1347012341!11999631!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM4ODU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22920 invoked from network); 7 Sep 2012 10:05:41 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-11.tower-21.messagelabs.com with SMTP;
	7 Sep 2012 10:05:41 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 07 Sep 2012 11:05:43 +0100
Message-Id: <5049E3470200007800099B3F@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 07 Sep 2012 11:06:31 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Sander Eikelenboom" <linux@eikelenboom.it>
References: <504764E2.4000809@amd.com>
	<326589347.20120906005936@eikelenboom.it> <5048A603.3070207@amd.com>
	<483486315.20120906155001@eikelenboom.it> <5048BB29.4040900@amd.com>
	<488803362.20120907093241@eikelenboom.it>
	<5049E0400200007800099B05@nat28.tlf.novell.com>
	<1188497031.20120907120041@eikelenboom.it>
In-Reply-To: <1188497031.20120907120041@eikelenboom.it>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Wei Wang <wei.wang2@amd.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] amd iommu: Dump flags of IO page faults
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.09.12 at 12:00, Sander Eikelenboom <linux@eikelenboom.it> wrote:

> Friday, September 7, 2012, 11:53:36 AM, you wrote:
> 
>>>>> On 07.09.12 at 09:32, Sander Eikelenboom <linux@eikelenboom.it> wrote:
>>> 4.1:    Capabilities: [54] MSI: Enable- Count=1/1 Maskable- 64bit+
>>> 4.2:    Capabilities: [54] MSI: Enable+ Count=1/1 Maskable- 64bit+
> 
>> No surprise you're not seeing any faults on 4.1 - there's no way
>> they could get reported. I'm somewhat hesitant to pull the
>> workaround patch from 4.2 into 4.1, as it's wrong for the kernel
>> to touch the MSI setting of the IOMMU (which is under the
>> control of Xen) in the first place, but the kernel side patch I had
>> submitted a while ago wasn't received well. And that patch isn't
>> really small, and it would remain to be seen what other
>> dependencies it would have...
> 
> Ok so that would mean that in the 4.1 case, the IOMMU is doing nothing ?

No, it just can't report faults (they would need to be polled for).
Also, saying "in the 4.1 case" is wrong here - this really depends
on whether you have an affected Dom0 kernel. Things work fine
if the Dom0 kernel doesn't trample over Xen's setup.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 07 10:15:32 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Sep 2012 10:15:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9vap-00075C-MA; Fri, 07 Sep 2012 10:15:19 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <linux@eikelenboom.it>) id 1T9vao-000757-FP
	for xen-devel@lists.xensource.com; Fri, 07 Sep 2012 10:15:18 +0000
Received: from [85.158.139.83:39239] by server-3.bemta-5.messagelabs.com id
	6A/DA-21836-539C9405; Fri, 07 Sep 2012 10:15:17 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-16.tower-182.messagelabs.com!1347012916!21794547!1
X-Originating-IP: [188.40.164.121]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5503 invoked from network); 7 Sep 2012 10:15:17 -0000
Received: from static.121.164.40.188.clients.your-server.de (HELO
	smtp.eikelenboom.it) (188.40.164.121)
	by server-16.tower-182.messagelabs.com with AES256-SHA encrypted SMTP;
	7 Sep 2012 10:15:17 -0000
Received: from 128-64-ftth.onsneteindhoven.nl ([88.159.64.128]:51492
	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 1T9vap-00089d-78; Fri, 07 Sep 2012 12:15:19 +0200
Date: Fri, 7 Sep 2012 12:15:11 +0200
From: Sander Eikelenboom <linux@eikelenboom.it>
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <148712299.20120907121511@eikelenboom.it>
To: "Jan Beulich" <JBeulich@suse.com>
In-Reply-To: <5049E3470200007800099B3F@nat28.tlf.novell.com>
References: <504764E2.4000809@amd.com>
	<326589347.20120906005936@eikelenboom.it>
	<5048A603.3070207@amd.com>
	<483486315.20120906155001@eikelenboom.it>
	<5048BB29.4040900@amd.com>
	<488803362.20120907093241@eikelenboom.it>
	<5049E0400200007800099B05@nat28.tlf.novell.com>
	<1188497031.20120907120041@eikelenboom.it>
	<5049E3470200007800099B3F@nat28.tlf.novell.com>
MIME-Version: 1.0
Cc: Wei Wang <wei.wang2@amd.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] amd iommu: Dump flags of IO page faults
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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, September 7, 2012, 12:06:31 PM, you wrote:

>>>> On 07.09.12 at 12:00, Sander Eikelenboom <linux@eikelenboom.it> wrote:

>> Friday, September 7, 2012, 11:53:36 AM, you wrote:
>> 
>>>>>> On 07.09.12 at 09:32, Sander Eikelenboom <linux@eikelenboom.it> wrote:
>>>> 4.1:    Capabilities: [54] MSI: Enable- Count=1/1 Maskable- 64bit+
>>>> 4.2:    Capabilities: [54] MSI: Enable+ Count=1/1 Maskable- 64bit+
>> 
>>> No surprise you're not seeing any faults on 4.1 - there's no way
>>> they could get reported. I'm somewhat hesitant to pull the
>>> workaround patch from 4.2 into 4.1, as it's wrong for the kernel
>>> to touch the MSI setting of the IOMMU (which is under the
>>> control of Xen) in the first place, but the kernel side patch I had
>>> submitted a while ago wasn't received well. And that patch isn't
>>> really small, and it would remain to be seen what other
>>> dependencies it would have...
>> 
>> Ok so that would mean that in the 4.1 case, the IOMMU is doing nothing ?

> No, it just can't report faults (they would need to be polled for).
> Also, saying "in the 4.1 case" is wrong here - this really depends
> on whether you have an affected Dom0 kernel. Things work fine
> if the Dom0 kernel doesn't trample over Xen's setup.

Except for the IO PAGE FAULT in xl dmesg, which is reported before the kernel even gets loaded with xen-4.2.
I don't see that one on 4.1 either, so that wouldn't add up to it being a dom0 kernel problem only ...


> Jan




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 07 10:15:32 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Sep 2012 10:15:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9vap-00075C-MA; Fri, 07 Sep 2012 10:15:19 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <linux@eikelenboom.it>) id 1T9vao-000757-FP
	for xen-devel@lists.xensource.com; Fri, 07 Sep 2012 10:15:18 +0000
Received: from [85.158.139.83:39239] by server-3.bemta-5.messagelabs.com id
	6A/DA-21836-539C9405; Fri, 07 Sep 2012 10:15:17 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-16.tower-182.messagelabs.com!1347012916!21794547!1
X-Originating-IP: [188.40.164.121]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5503 invoked from network); 7 Sep 2012 10:15:17 -0000
Received: from static.121.164.40.188.clients.your-server.de (HELO
	smtp.eikelenboom.it) (188.40.164.121)
	by server-16.tower-182.messagelabs.com with AES256-SHA encrypted SMTP;
	7 Sep 2012 10:15:17 -0000
Received: from 128-64-ftth.onsneteindhoven.nl ([88.159.64.128]:51492
	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 1T9vap-00089d-78; Fri, 07 Sep 2012 12:15:19 +0200
Date: Fri, 7 Sep 2012 12:15:11 +0200
From: Sander Eikelenboom <linux@eikelenboom.it>
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <148712299.20120907121511@eikelenboom.it>
To: "Jan Beulich" <JBeulich@suse.com>
In-Reply-To: <5049E3470200007800099B3F@nat28.tlf.novell.com>
References: <504764E2.4000809@amd.com>
	<326589347.20120906005936@eikelenboom.it>
	<5048A603.3070207@amd.com>
	<483486315.20120906155001@eikelenboom.it>
	<5048BB29.4040900@amd.com>
	<488803362.20120907093241@eikelenboom.it>
	<5049E0400200007800099B05@nat28.tlf.novell.com>
	<1188497031.20120907120041@eikelenboom.it>
	<5049E3470200007800099B3F@nat28.tlf.novell.com>
MIME-Version: 1.0
Cc: Wei Wang <wei.wang2@amd.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] amd iommu: Dump flags of IO page faults
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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, September 7, 2012, 12:06:31 PM, you wrote:

>>>> On 07.09.12 at 12:00, Sander Eikelenboom <linux@eikelenboom.it> wrote:

>> Friday, September 7, 2012, 11:53:36 AM, you wrote:
>> 
>>>>>> On 07.09.12 at 09:32, Sander Eikelenboom <linux@eikelenboom.it> wrote:
>>>> 4.1:    Capabilities: [54] MSI: Enable- Count=1/1 Maskable- 64bit+
>>>> 4.2:    Capabilities: [54] MSI: Enable+ Count=1/1 Maskable- 64bit+
>> 
>>> No surprise you're not seeing any faults on 4.1 - there's no way
>>> they could get reported. I'm somewhat hesitant to pull the
>>> workaround patch from 4.2 into 4.1, as it's wrong for the kernel
>>> to touch the MSI setting of the IOMMU (which is under the
>>> control of Xen) in the first place, but the kernel side patch I had
>>> submitted a while ago wasn't received well. And that patch isn't
>>> really small, and it would remain to be seen what other
>>> dependencies it would have...
>> 
>> Ok so that would mean that in the 4.1 case, the IOMMU is doing nothing ?

> No, it just can't report faults (they would need to be polled for).
> Also, saying "in the 4.1 case" is wrong here - this really depends
> on whether you have an affected Dom0 kernel. Things work fine
> if the Dom0 kernel doesn't trample over Xen's setup.

Except for the IO PAGE FAULT in xl dmesg, which is reported before the kernel even gets loaded with xen-4.2.
I don't see that one on 4.1 either, so that wouldn't add up to it being a dom0 kernel problem only ...


> Jan




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 07 10:21:27 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Sep 2012 10:21: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 1T9vgW-0007EM-EQ; Fri, 07 Sep 2012 10:21: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 1T9vgV-0007EG-2I
	for xen-devel@lists.xen.org; Fri, 07 Sep 2012 10:21:11 +0000
Received: from [85.158.143.99:63843] by server-1.bemta-4.messagelabs.com id
	BA/1B-12504-69AC9405; Fri, 07 Sep 2012 10:21:10 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1347013268!19471332!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTIyMTE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29605 invoked from network); 7 Sep 2012 10:21:08 -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;
	7 Sep 2012 10:21:08 -0000
X-IronPort-AV: E=Sophos;i="4.80,384,1344211200"; d="scan'208";a="14405887"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Sep 2012 10:21: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.279.1; Fri, 7 Sep 2012
	11:21:08 +0100
Message-ID: <1347013266.30018.85.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Bart Van Assche <bvanassche@acm.org>
Date: Fri, 7 Sep 2012 11:21:06 +0100
In-Reply-To: <5049BD25.8010408@acm.org>
References: <1346775635.6712.63.camel@zakaz.uk.xensource.com>
	<5049BD25.8010408@acm.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "valgrind-developers@lists.sourceforge.net"
	<valgrind-developers@lists.sourceforge.net>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [Valgrind-developers] [PATCH] valgrind: Support for
 ioctls used by Xen toolstack processes.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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-09-07 at 10:23 +0100, Bart Van Assche wrote:
> On 09/04/12 18:20, Ian Campbell wrote:
> > One issue is that the hypercalls which are exlusively used by the
> > toolstacks (as opposed to those used by guest operating systems) are
> > not considered a stable ABI, since the hypervisor and the lowlevel
> > tools are considered a matched pair. This covers the sysctl and
> > domctl hypercalls which are a fairly large chunk of the support
> > here. I'm not sure how to solve this without invoking a massive
> > amount of duplication. Right now this targets the Xen unstable
> > interface (which will shortly be released as Xen 4.2), perhaps I can
> > get away with deferring this problem until the first change ;-).
> 
> Does this mean the Xen interface is not backwards compatible ?

The hypercall interfaces used by solely by the toolstack are not stable.
Xen considers the toolstack and the hypervisor to be a matched pair, the
toolstack libraries are where the API stabilises.

Interfaces used by guests are stable, but those aren't terribly
interesting from a valgrind PoV (or at least, running valgrind on a
complete guest OS is a much bigger/very different project ;-)).

That said the non-stable interfaces are versioned, since there's a
version field at a stable location in both the domctl and sysctl
argument structs. In practice it is pretty rare for them to change other
than adding new sub commands.

> If so, are you sure you want to add support for an unstable API in
> Valgrind ?

Indeed, this was my concern.

As I say they don't change that often, and they do have a version field
in a static place so when they do change it should be possible to fix
valgrind to support both variants.

I'm not sure how much work that will be in practice, but I think it
won't be too much. By way of some data it looks like the last
incompatible change to sysctl was in November 2011 and the one before
was April 2010. Likewise domctl was September 2011 and before that April
2010. Currently:
        #define XEN_DOMCTL_INTERFACE_VERSION 0x00000008
    #define XEN_SYSCTL_INTERFACE_VERSION 0x00000009
these interfaces were added with 0x1 in August 2006 so it's something
like an update every 10 months or so (and I expect the rate has slowed
since they were first added).

I'm willing to do the necessary legwork to keep valgrind up to date.

BTW I've already found a few bugs with this stuff, including a
hypervisor issue exposed via the resultant misbehaviour of the
toolstack:
        http://lists.xen.org/archives/html/xen-devel/2012-09/msg00336.html
        http://lists.xen.org/archives/html/xen-devel/2012-09/msg00331.html
(nothing major there, but I've actually had this patch sitting around
for, /me looks, urk 2 years! So I have run it before and fixed a bunch
of stuff then too and other folks have occasionally used the patch too)

> 
> > There are some other wrinkles here I've not been sure how to solve:
> > 
> > Firstly, di_notify_mmap tries to read from the magic proc device:
> >      --20208-- WARNING: Serious error when reading debug info
> >      --20208-- When reading debug info from /proc/xen/privcmd:
> >      --20208-- can't read file to inspect ELF header
> > 
> > I've hacked around this with an explicit check for /proc/xen.
> > Hopefully someone can point to the right solution.
> 
> The changes for avoiding reading debuginfo from /proc/xen/privcmd look
> fine to me.

Great!

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 Sep 07 10:21:27 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Sep 2012 10:21: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 1T9vgW-0007EM-EQ; Fri, 07 Sep 2012 10:21: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 1T9vgV-0007EG-2I
	for xen-devel@lists.xen.org; Fri, 07 Sep 2012 10:21:11 +0000
Received: from [85.158.143.99:63843] by server-1.bemta-4.messagelabs.com id
	BA/1B-12504-69AC9405; Fri, 07 Sep 2012 10:21:10 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1347013268!19471332!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTIyMTE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29605 invoked from network); 7 Sep 2012 10:21:08 -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;
	7 Sep 2012 10:21:08 -0000
X-IronPort-AV: E=Sophos;i="4.80,384,1344211200"; d="scan'208";a="14405887"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Sep 2012 10:21: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.279.1; Fri, 7 Sep 2012
	11:21:08 +0100
Message-ID: <1347013266.30018.85.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Bart Van Assche <bvanassche@acm.org>
Date: Fri, 7 Sep 2012 11:21:06 +0100
In-Reply-To: <5049BD25.8010408@acm.org>
References: <1346775635.6712.63.camel@zakaz.uk.xensource.com>
	<5049BD25.8010408@acm.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "valgrind-developers@lists.sourceforge.net"
	<valgrind-developers@lists.sourceforge.net>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [Valgrind-developers] [PATCH] valgrind: Support for
 ioctls used by Xen toolstack processes.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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-09-07 at 10:23 +0100, Bart Van Assche wrote:
> On 09/04/12 18:20, Ian Campbell wrote:
> > One issue is that the hypercalls which are exlusively used by the
> > toolstacks (as opposed to those used by guest operating systems) are
> > not considered a stable ABI, since the hypervisor and the lowlevel
> > tools are considered a matched pair. This covers the sysctl and
> > domctl hypercalls which are a fairly large chunk of the support
> > here. I'm not sure how to solve this without invoking a massive
> > amount of duplication. Right now this targets the Xen unstable
> > interface (which will shortly be released as Xen 4.2), perhaps I can
> > get away with deferring this problem until the first change ;-).
> 
> Does this mean the Xen interface is not backwards compatible ?

The hypercall interfaces used by solely by the toolstack are not stable.
Xen considers the toolstack and the hypervisor to be a matched pair, the
toolstack libraries are where the API stabilises.

Interfaces used by guests are stable, but those aren't terribly
interesting from a valgrind PoV (or at least, running valgrind on a
complete guest OS is a much bigger/very different project ;-)).

That said the non-stable interfaces are versioned, since there's a
version field at a stable location in both the domctl and sysctl
argument structs. In practice it is pretty rare for them to change other
than adding new sub commands.

> If so, are you sure you want to add support for an unstable API in
> Valgrind ?

Indeed, this was my concern.

As I say they don't change that often, and they do have a version field
in a static place so when they do change it should be possible to fix
valgrind to support both variants.

I'm not sure how much work that will be in practice, but I think it
won't be too much. By way of some data it looks like the last
incompatible change to sysctl was in November 2011 and the one before
was April 2010. Likewise domctl was September 2011 and before that April
2010. Currently:
        #define XEN_DOMCTL_INTERFACE_VERSION 0x00000008
    #define XEN_SYSCTL_INTERFACE_VERSION 0x00000009
these interfaces were added with 0x1 in August 2006 so it's something
like an update every 10 months or so (and I expect the rate has slowed
since they were first added).

I'm willing to do the necessary legwork to keep valgrind up to date.

BTW I've already found a few bugs with this stuff, including a
hypervisor issue exposed via the resultant misbehaviour of the
toolstack:
        http://lists.xen.org/archives/html/xen-devel/2012-09/msg00336.html
        http://lists.xen.org/archives/html/xen-devel/2012-09/msg00331.html
(nothing major there, but I've actually had this patch sitting around
for, /me looks, urk 2 years! So I have run it before and fixed a bunch
of stuff then too and other folks have occasionally used the patch too)

> 
> > There are some other wrinkles here I've not been sure how to solve:
> > 
> > Firstly, di_notify_mmap tries to read from the magic proc device:
> >      --20208-- WARNING: Serious error when reading debug info
> >      --20208-- When reading debug info from /proc/xen/privcmd:
> >      --20208-- can't read file to inspect ELF header
> > 
> > I've hacked around this with an explicit check for /proc/xen.
> > Hopefully someone can point to the right solution.
> 
> The changes for avoiding reading debuginfo from /proc/xen/privcmd look
> fine to me.

Great!

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 Sep 07 10:33:54 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Sep 2012 10: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 1T9vsU-0007Sr-N7; Fri, 07 Sep 2012 10:33:34 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1T9vsT-0007SL-Oc
	for xen-devel@lists.xen.org; Fri, 07 Sep 2012 10:33:33 +0000
Received: from [85.158.143.99:38992] by server-3.bemta-4.messagelabs.com id
	DF/A0-08232-D7DC9405; Fri, 07 Sep 2012 10:33:33 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1347014012!23849158!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTIyMTE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13809 invoked from network); 7 Sep 2012 10:33:32 -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;
	7 Sep 2012 10:33:32 -0000
X-IronPort-AV: E=Sophos;i="4.80,385,1344211200"; d="scan'208";a="14406211"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Sep 2012 10: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.279.1; Fri, 7 Sep 2012 11: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
	1T9vsR-0000Ka-3D; Fri, 07 Sep 2012 10:33:31 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1T9vsQ-0001k1-Vr;
	Fri, 07 Sep 2012 11:33:30 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20553.52602.892916.502689@mariner.uk.xensource.com>
Date: Fri, 7 Sep 2012 11:33:30 +0100
To: Olaf Hering <olaf@aepfle.de>
In-Reply-To: <1347007260.30018.39.camel@zakaz.uk.xensource.com>
References: <cc71fe7029b27cb95d26.1346951697@probook.site>
	<1347007260.30018.39.camel@zakaz.uk.xensource.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] libxl: add missing dependencies of libxl.h
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("Re: [Xen-devel] [PATCH] libxl: add missing dependencies of libxl.h"):
> On Thu, 2012-09-06 at 18:14 +0100, Olaf Hering wrote:
> > libxl: add missing dependencies of libxl.h

This is not correct.  A dependency in the sense of make is a thing
which is used to construct the target file, not a thing which the
target file's contents refers to.

The correct fix is, I think, this:

diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
index a9d9ec6..f48e304 100644
--- a/tools/libxl/Makefile
+++ b/tools/libxl/Makefile
@@ -119,7 +119,7 @@ libxl.api-ok: check-libxl-api-rules _libxl.api-for-check
 	$(PERL) $^
 	touch $@
 
-_%.api-for-check: %.h
+_%.api-for-check: %.h $(filter-out %.api-ok, $(AUTOINCS))
 	$(CC) $(CPPFLAGS) $(CFLAGS) $(CFLAGS_$*.o) -c -E $< $(APPEND_CFLAGS) \
 		-DLIBXL_EXTERNAL_CALLERS_ONLY=LIBXL_EXTERNAL_CALLERS_ONLY \
 		>$@.new

Can you confirm that this fixes it for you ?

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 07 10:33:54 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Sep 2012 10: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 1T9vsU-0007Sr-N7; Fri, 07 Sep 2012 10:33:34 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1T9vsT-0007SL-Oc
	for xen-devel@lists.xen.org; Fri, 07 Sep 2012 10:33:33 +0000
Received: from [85.158.143.99:38992] by server-3.bemta-4.messagelabs.com id
	DF/A0-08232-D7DC9405; Fri, 07 Sep 2012 10:33:33 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1347014012!23849158!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTIyMTE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13809 invoked from network); 7 Sep 2012 10:33:32 -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;
	7 Sep 2012 10:33:32 -0000
X-IronPort-AV: E=Sophos;i="4.80,385,1344211200"; d="scan'208";a="14406211"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Sep 2012 10: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.279.1; Fri, 7 Sep 2012 11: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
	1T9vsR-0000Ka-3D; Fri, 07 Sep 2012 10:33:31 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1T9vsQ-0001k1-Vr;
	Fri, 07 Sep 2012 11:33:30 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20553.52602.892916.502689@mariner.uk.xensource.com>
Date: Fri, 7 Sep 2012 11:33:30 +0100
To: Olaf Hering <olaf@aepfle.de>
In-Reply-To: <1347007260.30018.39.camel@zakaz.uk.xensource.com>
References: <cc71fe7029b27cb95d26.1346951697@probook.site>
	<1347007260.30018.39.camel@zakaz.uk.xensource.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] libxl: add missing dependencies of libxl.h
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("Re: [Xen-devel] [PATCH] libxl: add missing dependencies of libxl.h"):
> On Thu, 2012-09-06 at 18:14 +0100, Olaf Hering wrote:
> > libxl: add missing dependencies of libxl.h

This is not correct.  A dependency in the sense of make is a thing
which is used to construct the target file, not a thing which the
target file's contents refers to.

The correct fix is, I think, this:

diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
index a9d9ec6..f48e304 100644
--- a/tools/libxl/Makefile
+++ b/tools/libxl/Makefile
@@ -119,7 +119,7 @@ libxl.api-ok: check-libxl-api-rules _libxl.api-for-check
 	$(PERL) $^
 	touch $@
 
-_%.api-for-check: %.h
+_%.api-for-check: %.h $(filter-out %.api-ok, $(AUTOINCS))
 	$(CC) $(CPPFLAGS) $(CFLAGS) $(CFLAGS_$*.o) -c -E $< $(APPEND_CFLAGS) \
 		-DLIBXL_EXTERNAL_CALLERS_ONLY=LIBXL_EXTERNAL_CALLERS_ONLY \
 		>$@.new

Can you confirm that this fixes it for you ?

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 07 10:38:00 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Sep 2012 10:38: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 1T9vwX-0007f9-EK; Fri, 07 Sep 2012 10:37:45 +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 1T9vwW-0007f0-Dh
	for xen-devel@lists.xen.org; Fri, 07 Sep 2012 10:37:44 +0000
Received: from [85.158.143.35:54403] by server-1.bemta-4.messagelabs.com id
	BD/89-12504-77EC9405; Fri, 07 Sep 2012 10:37:43 +0000
X-Env-Sender: ben.guthro@gmail.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1347014261!11625523!1
X-Originating-IP: [209.85.223.173]
X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE,
	RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15684 invoked from network); 7 Sep 2012 10:37:42 -0000
Received: from mail-ie0-f173.google.com (HELO mail-ie0-f173.google.com)
	(209.85.223.173)
	by server-10.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Sep 2012 10:37:42 -0000
Received: by iebc10 with SMTP id c10so5815640ieb.32
	for <xen-devel@lists.xen.org>; Fri, 07 Sep 2012 03:37:41 -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=lwByWKKyy8y7nyQds7AS/EzUv6YYX9UdQmiM6qXARhI=;
	b=W2jtirHJz/ITtlwj8hNIKSPpciQPOqHCuZayDTgdneSjaRR1SoqQVcOF5EV5mxsL5F
	O59JRtD/ywfjQ7CSFXS/3JplrvyNIJgP5XdngaSeZD923EqePM9h1JBWJVwnbYfvVplx
	yQdIpIQVJZ8Vyb4kbh7LZiLP5qBPxD4JvUqHjMZIKsqj1IkVWPxZYf5YBxqs4oHq1i/q
	FL2yS19K2D/HxPQ/yua8jfQGGRK7x1Y1FZ0aFzLBMxJ5tvSR6IyNVrsFQ632m8zxjaWs
	Er2aBATn0Sm5GVsKX55PV17RW/HPoL/xfIJjk/f4XbRI1t617tHSNpy74rTBkAHzJyAy
	Nm7Q==
MIME-Version: 1.0
Received: by 10.50.95.231 with SMTP id dn7mr7921240igb.37.1347014260960; Fri,
	07 Sep 2012 03:37:40 -0700 (PDT)
Received: by 10.64.28.203 with HTTP; Fri, 7 Sep 2012 03:37:40 -0700 (PDT)
In-Reply-To: <5049CEAE0200007800099A33@nat28.tlf.novell.com>
References: <CAOvdn6WwgBD-2yf1uu3m9-16=Tb5KUrybXf2KibtnxKbP7YtwA@mail.gmail.com>
	<CAOvdn6UBW-yTOMd3YSf5M9JiHLRivyaKL-qzcKG8epszqaKmGg@mail.gmail.com>
	<20120807163320.GC15053@phenom.dumpdata.com>
	<CAOvdn6XcRGKtJxGwJO8J+ZBJr89wfTLc1woW5rhtMM540H9h1w@mail.gmail.com>
	<CAOvdn6XUoSeGoo7X=AJ1kpDxZB9HZEv+TJ4v-=FHcyR4=CHK-w@mail.gmail.com>
	<502240F302000078000937A6@nat28.tlf.novell.com>
	<CAOvdn6WN3kxC8Bb9g6MpfLULu47EGSGCtajPc-SFeJ-8VSUQDQ@mail.gmail.com>
	<CAOvdn6Xk1inm1hU55i0phU2qvSWyJLNoyDdn43biBAY2OewPtw@mail.gmail.com>
	<5023F5400200007800093F4E@nat28.tlf.novell.com>
	<CAOvdn6U-f3C4U8xVPvDyRFkFFLkbfiCXg_n+9zgA9V5u+q5jfw@mail.gmail.com>
	<5023F8B80200007800093F8C@nat28.tlf.novell.com>
	<CAOvdn6XKHfete_+=Hkvt20G7_cJ-4i8+9j9YD30OxzQ16Ru-+g@mail.gmail.com>
	<5024CB720200007800094124@nat28.tlf.novell.com>
	<CAOvdn6VVJdhWVYa-gNVt3euE4AbGi1TijUCUd1wGzv0SCWEUYA@mail.gmail.com>
	<CAOvdn6USnG9Y4MNBhrDZmob0oJ8BgFfKTvFEhcKbXDxNmzfZ-Q@mail.gmail.com>
	<502B75BA0200007800094FD4@nat28.tlf.novell.com>
	<CAOvdn6Ww5oEj6Xg=XT4dWCYWUBuOdPqLz-CqNjz4HmCScE+==g@mail.gmail.com>
	<CAOvdn6Wsjds_dmZ0dwDTYmD-o-OqjBH5-b9mitAuUADE+A4_ag@mail.gmail.com>
	<502BB8FD02000078000951E0@nat28.tlf.novell.com>
	<CAOvdn6VD6bp13F-tvYdkBsj4hkhE7PTGZrapndtdHrDKeZqccg@mail.gmail.com>
	<502CCC0002000078000955C4@nat28.tlf.novell.com>
	<CAOvdn6VEuX7R2_wz74ZvCxMjC-=YUir9kP5sdxEVaKVspRUd_w@mail.gmail.com>
	<502CF0A8020000780009574E@nat28.tlf.novell.com>
	<CAOvdn6VsZvn_1TCWYeuyY5YuTcP8=miK2KwE4583nsj6Qjb_vg@mail.gmail.com>
	<504494FB0200007800098398@nat28.tlf.novell.com>
	<CAOvdn6UT13qvWbMyfZkWND03RoVKVSgb6wW4yqTUpuBYEX01Dg@mail.gmail.com>
	<5048958D02000078000993EB@nat28.tlf.novell.com>
	<CAOvdn6WrNK1Jn_Y_P7C3AwX6ApVcgzacLA_x-u=xBQtebnuPxA@mail.gmail.com>
	<CAOvdn6U_Z=KdEo56nqe7jN54BwiesRJqDOz_VzVNpkWGfFRd2A@mail.gmail.com>
	<5049CEAE0200007800099A33@nat28.tlf.novell.com>
Date: Fri, 7 Sep 2012 06:37:40 -0400
X-Google-Sender-Auth: oEkjp6CqagpHvsIsRmwn1WDeqr4
Message-ID: <CAOvdn6XmsEfs+aO7nqBHdA61HpT_n_8W95u0MMq5J21tZCFbzw@mail.gmail.com>
From: Ben Guthro <ben@guthro.net>
To: Jan Beulich <JBeulich@suse.com>
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>, john.baboval@citrix.com,
	Thomas Goetz <thomas.goetz@citrix.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen4.2 S3 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: multipart/mixed; boundary="===============6064809895409474512=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============6064809895409474512==
Content-Type: multipart/alternative; boundary=e89a8f2354bf882c0704c91a32c5

--e89a8f2354bf882c0704c91a32c5
Content-Type: text/plain; charset=ISO-8859-1

On Fri, Sep 7, 2012 at 4:38 AM, Jan Beulich <JBeulich@suse.com> wrote:

> >>> On 06.09.12 at 18:42, Ben Guthro <ben@guthro.net> wrote:
> > Odd.
> > The behavior seems to change, when not running with serial output.
>
> Odd indeed. Could you (unless you are already) try running the
> serial console in polling mode (i.e. without IRQ), to see whether
> the IRQs coming from it somehow keep the system alive at a
> certain point?
>
>
I tried to do this at the end of yesterday, since you had suggested it
previously, in this thread.

I did so by adding a ",0" to my com1 line, per the documentation - However,
I am running with a PCI serial card, and not an "on-board" one - so my
parameter looks like:

com1=115200,8n1,pci,0

I am not totally convinced that it is actually running in polling mode, and
started to investigate ns16550.c to verify it was. I plan on resuming this
investigation this morning.
If you have any pointers on what I should be looking for - I'd appreciate
any suggestions.


/btg

--e89a8f2354bf882c0704c91a32c5
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br><div class=3D"gmail_quote">On Fri, Sep 7, 2012 at 4:38 AM, 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><blockquote class=3D"gmail_quo=
te" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"=
>
<div class=3D"im">&gt;&gt;&gt; On 06.09.12 at 18:42, Ben Guthro &lt;<a href=
=3D"mailto:ben@guthro.net">ben@guthro.net</a>&gt; wrote:<br>
&gt; Odd.<br>
&gt; The behavior seems to change, when not running with serial output.<br>
<br>
</div>Odd indeed. Could you (unless you are already) try running the<br>
serial console in polling mode (i.e. without IRQ), to see whether<br>
the IRQs coming from it somehow keep the system alive at a<br>
certain point?<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br></font></span></blockquo=
te><div><br></div><div>I tried to do this at the end of yesterday, since yo=
u had suggested it previously, in this thread.</div><div><br></div><div>I d=
id so by adding a &quot;,0&quot; to my com1 line, per the documentation - H=
owever, I am running with a PCI serial card, and not an &quot;on-board&quot=
; one - so my parameter looks like:</div>
<div><br></div><div>com1=3D115200,8n1,pci,0</div><div><br></div><div>I am n=
ot totally convinced that it is actually running in polling mode, and start=
ed to investigate ns16550.c to verify it was. I plan on resuming this inves=
tigation this morning.</div>
<div>If you have any pointers on what I should be looking for - I&#39;d app=
reciate any suggestions.</div><div><br></div><div><br></div><div>/btg</div>=
<div><br></div><div><br></div></div>

--e89a8f2354bf882c0704c91a32c5--


--===============6064809895409474512==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============6064809895409474512==--


From xen-devel-bounces@lists.xen.org Fri Sep 07 10:38:00 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Sep 2012 10:38: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 1T9vwX-0007f9-EK; Fri, 07 Sep 2012 10:37:45 +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 1T9vwW-0007f0-Dh
	for xen-devel@lists.xen.org; Fri, 07 Sep 2012 10:37:44 +0000
Received: from [85.158.143.35:54403] by server-1.bemta-4.messagelabs.com id
	BD/89-12504-77EC9405; Fri, 07 Sep 2012 10:37:43 +0000
X-Env-Sender: ben.guthro@gmail.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1347014261!11625523!1
X-Originating-IP: [209.85.223.173]
X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE,
	RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15684 invoked from network); 7 Sep 2012 10:37:42 -0000
Received: from mail-ie0-f173.google.com (HELO mail-ie0-f173.google.com)
	(209.85.223.173)
	by server-10.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Sep 2012 10:37:42 -0000
Received: by iebc10 with SMTP id c10so5815640ieb.32
	for <xen-devel@lists.xen.org>; Fri, 07 Sep 2012 03:37:41 -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=lwByWKKyy8y7nyQds7AS/EzUv6YYX9UdQmiM6qXARhI=;
	b=W2jtirHJz/ITtlwj8hNIKSPpciQPOqHCuZayDTgdneSjaRR1SoqQVcOF5EV5mxsL5F
	O59JRtD/ywfjQ7CSFXS/3JplrvyNIJgP5XdngaSeZD923EqePM9h1JBWJVwnbYfvVplx
	yQdIpIQVJZ8Vyb4kbh7LZiLP5qBPxD4JvUqHjMZIKsqj1IkVWPxZYf5YBxqs4oHq1i/q
	FL2yS19K2D/HxPQ/yua8jfQGGRK7x1Y1FZ0aFzLBMxJ5tvSR6IyNVrsFQ632m8zxjaWs
	Er2aBATn0Sm5GVsKX55PV17RW/HPoL/xfIJjk/f4XbRI1t617tHSNpy74rTBkAHzJyAy
	Nm7Q==
MIME-Version: 1.0
Received: by 10.50.95.231 with SMTP id dn7mr7921240igb.37.1347014260960; Fri,
	07 Sep 2012 03:37:40 -0700 (PDT)
Received: by 10.64.28.203 with HTTP; Fri, 7 Sep 2012 03:37:40 -0700 (PDT)
In-Reply-To: <5049CEAE0200007800099A33@nat28.tlf.novell.com>
References: <CAOvdn6WwgBD-2yf1uu3m9-16=Tb5KUrybXf2KibtnxKbP7YtwA@mail.gmail.com>
	<CAOvdn6UBW-yTOMd3YSf5M9JiHLRivyaKL-qzcKG8epszqaKmGg@mail.gmail.com>
	<20120807163320.GC15053@phenom.dumpdata.com>
	<CAOvdn6XcRGKtJxGwJO8J+ZBJr89wfTLc1woW5rhtMM540H9h1w@mail.gmail.com>
	<CAOvdn6XUoSeGoo7X=AJ1kpDxZB9HZEv+TJ4v-=FHcyR4=CHK-w@mail.gmail.com>
	<502240F302000078000937A6@nat28.tlf.novell.com>
	<CAOvdn6WN3kxC8Bb9g6MpfLULu47EGSGCtajPc-SFeJ-8VSUQDQ@mail.gmail.com>
	<CAOvdn6Xk1inm1hU55i0phU2qvSWyJLNoyDdn43biBAY2OewPtw@mail.gmail.com>
	<5023F5400200007800093F4E@nat28.tlf.novell.com>
	<CAOvdn6U-f3C4U8xVPvDyRFkFFLkbfiCXg_n+9zgA9V5u+q5jfw@mail.gmail.com>
	<5023F8B80200007800093F8C@nat28.tlf.novell.com>
	<CAOvdn6XKHfete_+=Hkvt20G7_cJ-4i8+9j9YD30OxzQ16Ru-+g@mail.gmail.com>
	<5024CB720200007800094124@nat28.tlf.novell.com>
	<CAOvdn6VVJdhWVYa-gNVt3euE4AbGi1TijUCUd1wGzv0SCWEUYA@mail.gmail.com>
	<CAOvdn6USnG9Y4MNBhrDZmob0oJ8BgFfKTvFEhcKbXDxNmzfZ-Q@mail.gmail.com>
	<502B75BA0200007800094FD4@nat28.tlf.novell.com>
	<CAOvdn6Ww5oEj6Xg=XT4dWCYWUBuOdPqLz-CqNjz4HmCScE+==g@mail.gmail.com>
	<CAOvdn6Wsjds_dmZ0dwDTYmD-o-OqjBH5-b9mitAuUADE+A4_ag@mail.gmail.com>
	<502BB8FD02000078000951E0@nat28.tlf.novell.com>
	<CAOvdn6VD6bp13F-tvYdkBsj4hkhE7PTGZrapndtdHrDKeZqccg@mail.gmail.com>
	<502CCC0002000078000955C4@nat28.tlf.novell.com>
	<CAOvdn6VEuX7R2_wz74ZvCxMjC-=YUir9kP5sdxEVaKVspRUd_w@mail.gmail.com>
	<502CF0A8020000780009574E@nat28.tlf.novell.com>
	<CAOvdn6VsZvn_1TCWYeuyY5YuTcP8=miK2KwE4583nsj6Qjb_vg@mail.gmail.com>
	<504494FB0200007800098398@nat28.tlf.novell.com>
	<CAOvdn6UT13qvWbMyfZkWND03RoVKVSgb6wW4yqTUpuBYEX01Dg@mail.gmail.com>
	<5048958D02000078000993EB@nat28.tlf.novell.com>
	<CAOvdn6WrNK1Jn_Y_P7C3AwX6ApVcgzacLA_x-u=xBQtebnuPxA@mail.gmail.com>
	<CAOvdn6U_Z=KdEo56nqe7jN54BwiesRJqDOz_VzVNpkWGfFRd2A@mail.gmail.com>
	<5049CEAE0200007800099A33@nat28.tlf.novell.com>
Date: Fri, 7 Sep 2012 06:37:40 -0400
X-Google-Sender-Auth: oEkjp6CqagpHvsIsRmwn1WDeqr4
Message-ID: <CAOvdn6XmsEfs+aO7nqBHdA61HpT_n_8W95u0MMq5J21tZCFbzw@mail.gmail.com>
From: Ben Guthro <ben@guthro.net>
To: Jan Beulich <JBeulich@suse.com>
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>, john.baboval@citrix.com,
	Thomas Goetz <thomas.goetz@citrix.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen4.2 S3 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: multipart/mixed; boundary="===============6064809895409474512=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============6064809895409474512==
Content-Type: multipart/alternative; boundary=e89a8f2354bf882c0704c91a32c5

--e89a8f2354bf882c0704c91a32c5
Content-Type: text/plain; charset=ISO-8859-1

On Fri, Sep 7, 2012 at 4:38 AM, Jan Beulich <JBeulich@suse.com> wrote:

> >>> On 06.09.12 at 18:42, Ben Guthro <ben@guthro.net> wrote:
> > Odd.
> > The behavior seems to change, when not running with serial output.
>
> Odd indeed. Could you (unless you are already) try running the
> serial console in polling mode (i.e. without IRQ), to see whether
> the IRQs coming from it somehow keep the system alive at a
> certain point?
>
>
I tried to do this at the end of yesterday, since you had suggested it
previously, in this thread.

I did so by adding a ",0" to my com1 line, per the documentation - However,
I am running with a PCI serial card, and not an "on-board" one - so my
parameter looks like:

com1=115200,8n1,pci,0

I am not totally convinced that it is actually running in polling mode, and
started to investigate ns16550.c to verify it was. I plan on resuming this
investigation this morning.
If you have any pointers on what I should be looking for - I'd appreciate
any suggestions.


/btg

--e89a8f2354bf882c0704c91a32c5
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br><div class=3D"gmail_quote">On Fri, Sep 7, 2012 at 4:38 AM, 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><blockquote class=3D"gmail_quo=
te" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"=
>
<div class=3D"im">&gt;&gt;&gt; On 06.09.12 at 18:42, Ben Guthro &lt;<a href=
=3D"mailto:ben@guthro.net">ben@guthro.net</a>&gt; wrote:<br>
&gt; Odd.<br>
&gt; The behavior seems to change, when not running with serial output.<br>
<br>
</div>Odd indeed. Could you (unless you are already) try running the<br>
serial console in polling mode (i.e. without IRQ), to see whether<br>
the IRQs coming from it somehow keep the system alive at a<br>
certain point?<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br></font></span></blockquo=
te><div><br></div><div>I tried to do this at the end of yesterday, since yo=
u had suggested it previously, in this thread.</div><div><br></div><div>I d=
id so by adding a &quot;,0&quot; to my com1 line, per the documentation - H=
owever, I am running with a PCI serial card, and not an &quot;on-board&quot=
; one - so my parameter looks like:</div>
<div><br></div><div>com1=3D115200,8n1,pci,0</div><div><br></div><div>I am n=
ot totally convinced that it is actually running in polling mode, and start=
ed to investigate ns16550.c to verify it was. I plan on resuming this inves=
tigation this morning.</div>
<div>If you have any pointers on what I should be looking for - I&#39;d app=
reciate any suggestions.</div><div><br></div><div><br></div><div>/btg</div>=
<div><br></div><div><br></div></div>

--e89a8f2354bf882c0704c91a32c5--


--===============6064809895409474512==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============6064809895409474512==--


From xen-devel-bounces@lists.xen.org Fri Sep 07 10:38:01 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Sep 2012 10:38:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9vwY-0007fR-Qt; Fri, 07 Sep 2012 10:37:46 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <tobias.geiger@vido.info>) id 1T9vwX-0007f7-Av
	for xen-devel@lists.xen.org; Fri, 07 Sep 2012 10:37:45 +0000
Received: from [85.158.139.83:50635] by server-6.bemta-5.messagelabs.com id
	68/6F-21336-87EC9405; Fri, 07 Sep 2012 10:37:44 +0000
X-Env-Sender: tobias.geiger@vido.info
X-Msg-Ref: server-8.tower-182.messagelabs.com!1347014263!17863877!1
X-Originating-IP: [78.47.43.170]
X-SpamReason: No, hits=1.7 required=7.0 tests=INFO_TLD,
	MAILTO_TO_SPAM_ADDR,SUBJECT_EXCESS_QP,UNPARSEABLE_RELAY
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31624 invoked from network); 7 Sep 2012 10:37:43 -0000
Received: from mail.vido.info (HELO mail.vido.info) (78.47.43.170)
	by server-8.tower-182.messagelabs.com with SMTP;
	7 Sep 2012 10:37:43 -0000
Received: from localhost (ip6-localhost [127.0.0.1])
	by mail.vido.info (Postfix) with ESMTP id C6BD0D34298;
	Fri,  7 Sep 2012 12:37:28 +0200 (CEST)
X-Virus-Scanned: by amavis at mail.vido.info
Received: from mail.vido.info ([127.0.0.1])
	by localhost (mail.vido.info [127.0.0.1]) (amavisd-new, port 10024)
	with LMTP id 8Q5QOBSIVUyk; Fri,  7 Sep 2012 12:37:21 +0200 (CEST)
Received: from www.vido.info (www.vido.info [78.47.43.171])
	by mail.vido.info (Postfix) with ESMTP id 64D5FD3428A;
	Fri,  7 Sep 2012 12:37:21 +0200 (CEST)
Received: from L5jE52kQqxnOGl4NFOXRzeMVbQJlqn/fZ5jeoi+iaJ1/VXWrGLOIVA==
	(TdiVOeZB/lz4D6vwA08MFIDlemAMM1KF) by www.vido.info
	with HTTP (HTTP/1.1 POST); Fri, 07 Sep 2012 12:37:21 +0200
MIME-Version: 1.0
Date: Fri, 07 Sep 2012 12:37:21 +0200
From: Tobias Geiger <tobias.geiger@vido.info>
To: "Ren, Yongjie" <yongjie.ren@intel.com>
In-Reply-To: <1B4B44D9196EFF41AE41FDA404FC0A101933A2@SHSMSX101.ccr.corp.intel.com>
References: <1B4B44D9196EFF41AE41FDA404FC0A101881CE@SHSMSX101.ccr.corp.intel.com>
	<20120905185412.GA27077@phenom.dumpdata.com>
	<f74e17a2c22339a3eb0439a03bef10b1@vido.info>
	<1B4B44D9196EFF41AE41FDA404FC0A101933A2@SHSMSX101.ccr.corp.intel.com>
Message-ID: <cc83522f2f3490d6ede99e8681a222de@vido.info>
X-Sender: tobias.geiger@vido.info
User-Agent: Roundcube Webmail
Cc: Konrad Rzeszutek Wilk <konrad@kernel.org>, xen-devel@lists.xen.org,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel]
 =?utf-8?q?Regression_in_kernel_3=2E5_as_Dom0_regardin?=
 =?utf-8?q?g_PCI_Passthrough=3F!?=
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
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 07.09.2012 04:08, schrieb Ren, Yongjie:
>> -----Original Message-----
>> From: Tobias Geiger [mailto:tobias.geiger@vido.info]
>> Sent: Thursday, September 06, 2012 7:28 PM
>> To: Konrad Rzeszutek Wilk
>> Cc: Ren, Yongjie; Konrad Rzeszutek Wilk; xen-devel@lists.xen.org
>> Subject: Re: [Xen-devel] Regression in kernel 3.5 as Dom0 regarding 
>> PCI
>> Passthrough?!
>>
>> Hello Konrad,
>>
>> the patch helps regarding the USB-PCIController-Passthrough - this
>> works now in DomU.
>>
> Hi Tobias,
> In my testing, this patch can't work for a NIC pass-through.
> Could you have a try with a NIC pass-through?

Hi!

unfortunatly not - i have no physical access to the machine until the 
middle of next week.
and as so soon as i try to passthrough the only nic in this machine my 
remote access will die... :(

perhaps someone else can test nic-passthrough? if not i'll try it asap 
next week!

Greetings
Tobias

>
>> but i still get the Dom0 crash when shutting down DomU:
>>
>> Sep  6 13:26:19 pc kernel: [  361.011514]
>> xen-blkback:backend/vbd/1/832: prepare for reconnect
>> Sep  6 13:26:20 pc kernel: [  361.876395]
>> xen-blkback:backend/vbd/1/768: prepare for reconnect
>> Sep  6 13:26:21 pc kernel: [  362.682152] br0: port 3(vif1.0) 
>> entered
>> disabled state
>> Sep  6 13:26:21 pc kernel: [  362.682267] br0: port 3(vif1.0) 
>> entered
>> disabled state
>> Sep  6 13:26:24 pc kernel: [  365.541386] ------------[ cut here
>> ]------------
>> Sep  6 13:26:24 pc kernel: [  365.541411] invalid opcode: 0000 [#1]
>> PREEMPT SMP
>> Sep  6 13:26:24 pc kernel: [  365.541423] CPU 2
>> Sep  6 13:26:24 pc kernel: [  365.541427] Modules linked in: 
>> uvcvideo
>> snd_usb_audio snd_usbmidi_lib snd_seq_midi snd_hwd
>> ep snd_rawmidi videobuf2_vmalloc videobuf2_memops videobuf2_core
>> videodev gpio_ich joydev hid_generic [last unloaded: sc
>> si_wait_scan]
>> Sep  6 13:26:24 pc kernel: [  365.541474]
>> Sep  6 13:26:24 pc kernel: [  365.541477] Pid: 1208, comm: 
>> kworker/2:1
>> Not tainted 3.5.0 #3                  /DX58SO
>> Sep  6 13:26:24 pc kernel: [  365.541491] RIP:
>> e030:[<ffffffff81447f95>]  [<ffffffff81447f95>]
>> balloon_process+0x385/0x3
>> a0
>> Sep  6 13:26:24 pc kernel: [  365.541507] RSP: e02b:ffff88012e7abdc0
>> EFLAGS: 00010213
>> Sep  6 13:26:24 pc kernel: [  365.541515] RAX: 0000000220be7000 RBX:
>> 0000000000000000 RCX: 0000000000000008
>> Sep  6 13:26:24 pc kernel: [  365.541523] RDX: ffff88010d99a000 RSI:
>> 00000000000001df RDI: 000000000020efdf
>> Sep  6 13:26:24 pc kernel: [  365.541532] RBP: ffff88012e7abe20 R08:
>> ffff88014064e140 R09: 00000000fffffffe
>> Sep  6 13:26:24 pc kernel: [  365.541540] R10: 0000000000000001 R11:
>> 0000000000000000 R12: 0000160000000000
>> Sep  6 13:26:24 pc kernel: [  365.541548] R13: 0000000000000001 R14:
>> 000000000020efdf R15: ffffea00083bf7c0
>> Sep  6 13:26:24 pc kernel: [  365.541561] FS:  
>> 00007f79d32ce700(0000)
>> GS:ffff880140640000(0000) knlGS:0000000000000000
>> Sep  6 13:26:24 pc kernel: [  365.541571] CS:  e033 DS: 0000 ES: 
>> 0000
>> CR0: 000000008005003b
>> Sep  6 13:26:24 pc kernel: [  365.541578] CR2: 00007f79d2d6ce02 CR3:
>> 0000000001e0c000 CR4: 0000000000002660
>> Sep  6 13:26:24 pc kernel: [  365.541587] DR0: 0000000000000000 DR1:
>> 0000000000000000 DR2: 0000000000000000
>> Sep  6 13:26:24 pc kernel: [  365.541596] DR3: 0000000000000000 DR6:
>> 00000000ffff0ff0 DR7: 0000000000000400
>> Sep  6 13:26:24 pc kernel: [  365.541604] Process kworker/2:1 (pid:
>> 1208, threadinfo ffff88012e7aa000, task ffff88013101
>> c440)
>> Sep  6 13:26:24 pc kernel: [  365.541613] Stack:
>> Sep  6 13:26:24 pc kernel: [  365.541618]  000000000006877b
>> 0000000000000001 ffffffff8200ea80 0000000000000001
>> Sep  6 13:26:24 pc kernel: [  365.541649]  0000000000000000
>> 0000000000007ff0 ffff88012e7abe00 ffff8801302eee00
>> Sep  6 13:26:24 pc kernel: [  365.541664]  ffff880140657000
>> ffff88014064e140 0000000000000000 ffffffff81e587c0
>> Sep  6 13:26:24 pc kernel: [  365.541679] Call Trace:
>> Sep  6 13:26:24 pc kernel: [  365.541688]  [<ffffffff8106753b>]
>> process_one_work+0x12b/0x450
>> Sep  6 13:26:24 pc kernel: [  365.541697]  [<ffffffff81447c10>] ?
>> decrease_reservation+0x320/0x320
>> Sep  6 13:26:24 pc kernel: [  365.541706]  [<ffffffff810688be>]
>> worker_thread+0x12e/0x2d0
>> Sep  6 13:26:24 pc kernel: [  365.541715]  [<ffffffff81068790>] ?
>> manage_workers.isra.26+0x1f0/0x1f0
>> Sep  6 13:26:24 pc kernel: [  365.541725]  [<ffffffff8106db7e>]
>> kthread+0x8e/0xa0
>> Sep  6 13:26:24 pc kernel: [  365.541735]  [<ffffffff8184e3e4>]
>> kernel_thread_helper+0x4/0x10
>> Sep  6 13:26:24 pc kernel: [  365.541745]  [<ffffffff8184c87c>] ?
>> retint_restore_args+0x5/0x6
>> Sep  6 13:26:24 pc kernel: [  365.541754]  [<ffffffff8184e3e0>] ?
>> gs_change+0x13/0x13
>> Sep  6 13:26:24 pc kernel: [  365.541760] Code: 01 15 f0 6a bc 00 48 
>> 29
>> d0 48 89 05 ee 6a bc 00 e9 31 fd ff ff 0f 0b 0f
>> 0b 4c 89 f7 e8 85 34 bc ff 48 83 f8 ff 0f 84 2b fe ff ff <0f> 0b 66 
>> 0f
>> 1f 84 00 00 00 00 00 48 83 c1 01 e9 c2 fd ff ff 0
>> f
>> Sep  6 13:26:24 pc kernel: [  365.541898]  RSP <ffff88012e7abdc0>
>> Sep  6 13:26:24 pc kernel: [  365.565054] ---[ end trace
>> 25eb9ce0cc61c3a1 ]---
>> Sep  6 13:26:24 pc kernel: [  365.565101] PGD 1e0e067 PUD 1e0f067
>> PMD 0
>> Sep  6 13:26:24 pc kernel: [  365.565108] Oops: 0000 [#2] PREEMPT 
>> SMP
>> Sep  6 13:26:24 pc kernel: [  365.565115] CPU 2
>> Sep  6 13:26:24 pc kernel: [  365.565118] Modules linked in: 
>> uvcvideo
>> snd_usb_audio snd_usbmidi_lib snd_seq_midi snd_hwd
>> ep snd_rawmidi videobuf2_vmalloc videobuf2_memops videobuf2_core
>> videodev gpio_ich joydev hid_generic [last unloaded: sc
>> si_wait_scan]
>> Sep  6 13:26:24 pc kernel: [  365.565153]
>> Sep  6 13:26:24 pc kernel: [  365.565156] Pid: 1208, comm: 
>> kworker/2:1
>> Tainted: G      D      3.5.0 #3
>> /DX58SO
>> Sep  6 13:26:24 pc kernel: [  365.565176] RIP:
>> e030:[<ffffffff8106e08c>]  [<ffffffff8106e08c>] 
>> kthread_data+0xc/0x20
>> Sep  6 13:26:24 pc kernel: [  365.565194] RSP: e02b:ffff88012e7aba90
>> EFLAGS: 00010092
>> Sep  6 13:26:24 pc kernel: [  365.565205] RAX: 0000000000000000 RBX:
>> 0000000000000002 RCX: 0000000000000002
>> Sep  6 13:26:24 pc kernel: [  365.565219] RDX: ffffffff81fcba40 RSI:
>> 0000000000000002 RDI: ffff88013101c440
>> Sep  6 13:26:24 pc kernel: [  365.565233] RBP: ffff88012e7abaa8 R08:
>> 0000000000989680 R09: ffffffff81fcba40
>> Sep  6 13:26:24 pc kernel: [  365.565248] R10: ffffffff813b0c00 R11:
>> 0000000000000000 R12: ffff8801406536c0
>> Sep  6 13:26:24 pc kernel: [  365.565262] R13: 0000000000000002 R14:
>> ffff88013101c430 R15: ffff88013101c440
>> Sep  6 13:26:24 pc kernel: [  365.565280] FS:  
>> 00007f79d32ce700(0000)
>> GS:ffff880140640000(0000) knlGS:0000000000000000
>> Sep  6 13:26:24 pc kernel: [  365.565293] CS:  e033 DS: 0000 ES: 
>> 0000
>> CR0: 000000008005003b
>> Sep  6 13:26:24 pc kernel: [  365.565303] CR2: fffffffffffffff8 CR3:
>> 0000000001e0c000 CR4: 0000000000002660
>> Sep  6 13:26:24 pc kernel: [  365.565318] DR0: 0000000000000000 DR1:
>> 0000000000000000 DR2: 0000000000000000
>> Sep  6 13:26:24 pc kernel: [  365.565332] DR3: 0000000000000000 DR6:
>> 00000000ffff0ff0 DR7: 0000000000000400
>> Sep  6 13:26:24 pc kernel: [  365.565349] Process kworker/2:1 (pid:
>> 1208, threadinfo ffff88012e7aa000, task ffff88013101
>> c440)
>> Sep  6 13:26:24 pc kernel: [  365.565362] Stack:
>> Sep  6 13:26:24 pc kernel: [  365.565367]  ffffffff810698e0
>> ffff88012e7abaa8 ffff88013101c818 ffff88012e7abb18
>> Sep  6 13:26:24 pc kernel: [  365.565389]  ffffffff8184ae02
>> ffff88012e7abfd8 ffff88013101c440 ffff88012e7abfd8
>> Sep  6 13:26:24 pc kernel: [  365.565410]  ffff88012e7abfd8
>> ffff88012d8840c0 ffff88013101c440 ffff88013101ca30
>>
>>
>>
>> Perhaps this stacktrace helps...
>>
>> Thanks!
>>
>> Am 05.09.2012 20:54, schrieb Konrad Rzeszutek Wilk:
>> >> > > > And its due to a patch I added in v3.4
>> >> > > > (cd9db80e5257682a7f7ab245a2459648b3c8d268)
>> >> > > > - which did not work properly in v3.4, but with v3.5 got it
>> >> working
>> >> > > > (977f857ca566a1e68045fcbb7cfc9c4acb077cf0) which causes 
>> v3.5
>> >> to
>> >> > now
>> >> > > > work
>> >> > > > anymore.
>> >> > > >
>> >> > > > Anyhow, for right now jsut revert
>> >> > > > cd9db80e5257682a7f7ab245a2459648b3c8d268
>> >> > > > and it should work for you.
>> >> > > >
>> >> Confirmed, after reverting that commit, VT-d will work fine.
>> >> Will you fix this and push it to upstream Linux, Konrad?
>> >>
>> >> > > Also, our team reported a VT-d bug 2 months ago.
>> >> > > http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1824
>> >> >
>> >
>> > Can either one of you please test this patch, please:
>> >
>> >
>> > diff --git a/drivers/xen/xen-pciback/pci_stub.c
>> > b/drivers/xen/xen-pciback/pci_stub.c
>> > index 097e536..425bd0b 100644
>> > --- a/drivers/xen/xen-pciback/pci_stub.c
>> > +++ b/drivers/xen/xen-pciback/pci_stub.c
>> > @@ -4,6 +4,8 @@
>> >   * Ryan Wilson <hap9@epoch.ncsc.mil>
>> >   * Chris Bookholt <hap10@epoch.ncsc.mil>
>> >   */
>> > +#define DEBUG 1
>> > +
>> >  #include <linux/module.h>
>> >  #include <linux/init.h>
>> >  #include <linux/rwsem.h>
>> > @@ -97,13 +99,15 @@ static void pcistub_device_release(struct kref
>> > *kref)
>> >  	/* Call the reset function which does not take lock as this
>> >  	 * is called from "unbind" which takes a device_lock mutex.
>> >  	 */
>> > +	dev_dbg(&psdev->dev->dev, "FLR locked..\n");
>> >  	__pci_reset_function_locked(psdev->dev);
>> >  	if (pci_load_and_free_saved_state(psdev->dev,
>> >  					  &dev_data->pci_saved_state)) {
>> >  		dev_dbg(&psdev->dev->dev, "Could not reload PCI state\n");
>> > -	} else
>> > +	} else {
>> > +		dev_dbg(&psdev->dev->dev, "Reloading PCI state..\n");
>> >  		pci_restore_state(psdev->dev);
>> > -
>> > +	}
>> >  	/* Disable the device */
>> >  	xen_pcibk_reset_device(psdev->dev);
>> >
>> > @@ -353,16 +357,16 @@ static int __devinit 
>> pcistub_init_device(struct
>> > pci_dev *dev)
>> >  	if (err)
>> >  		goto config_release;
>> >
>> > -	dev_dbg(&dev->dev, "reseting (FLR, D3, etc) the device\n");
>> > -	__pci_reset_function_locked(dev);
>> > -
>> >  	/* We need the device active to save the state. */
>> >  	dev_dbg(&dev->dev, "save state of device\n");
>> >  	pci_save_state(dev);
>> >  	dev_data->pci_saved_state = pci_store_saved_state(dev);
>> >  	if (!dev_data->pci_saved_state)
>> >  		dev_err(&dev->dev, "Could not store PCI conf saved state!\n");
>> > -
>> > +	else {
>> > +		dev_dbg(&dev->dev, "reseting (FLR, D3, etc) the device\n");
>> > +		__pci_reset_function_locked(dev);
>> > +	}
>> >  	/* Now disable the device (this also ensures some private device
>> >  	 * data is setup before we export)
>> >  	 */


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 07 10:38:01 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Sep 2012 10:38:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9vwY-0007fR-Qt; Fri, 07 Sep 2012 10:37:46 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <tobias.geiger@vido.info>) id 1T9vwX-0007f7-Av
	for xen-devel@lists.xen.org; Fri, 07 Sep 2012 10:37:45 +0000
Received: from [85.158.139.83:50635] by server-6.bemta-5.messagelabs.com id
	68/6F-21336-87EC9405; Fri, 07 Sep 2012 10:37:44 +0000
X-Env-Sender: tobias.geiger@vido.info
X-Msg-Ref: server-8.tower-182.messagelabs.com!1347014263!17863877!1
X-Originating-IP: [78.47.43.170]
X-SpamReason: No, hits=1.7 required=7.0 tests=INFO_TLD,
	MAILTO_TO_SPAM_ADDR,SUBJECT_EXCESS_QP,UNPARSEABLE_RELAY
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31624 invoked from network); 7 Sep 2012 10:37:43 -0000
Received: from mail.vido.info (HELO mail.vido.info) (78.47.43.170)
	by server-8.tower-182.messagelabs.com with SMTP;
	7 Sep 2012 10:37:43 -0000
Received: from localhost (ip6-localhost [127.0.0.1])
	by mail.vido.info (Postfix) with ESMTP id C6BD0D34298;
	Fri,  7 Sep 2012 12:37:28 +0200 (CEST)
X-Virus-Scanned: by amavis at mail.vido.info
Received: from mail.vido.info ([127.0.0.1])
	by localhost (mail.vido.info [127.0.0.1]) (amavisd-new, port 10024)
	with LMTP id 8Q5QOBSIVUyk; Fri,  7 Sep 2012 12:37:21 +0200 (CEST)
Received: from www.vido.info (www.vido.info [78.47.43.171])
	by mail.vido.info (Postfix) with ESMTP id 64D5FD3428A;
	Fri,  7 Sep 2012 12:37:21 +0200 (CEST)
Received: from L5jE52kQqxnOGl4NFOXRzeMVbQJlqn/fZ5jeoi+iaJ1/VXWrGLOIVA==
	(TdiVOeZB/lz4D6vwA08MFIDlemAMM1KF) by www.vido.info
	with HTTP (HTTP/1.1 POST); Fri, 07 Sep 2012 12:37:21 +0200
MIME-Version: 1.0
Date: Fri, 07 Sep 2012 12:37:21 +0200
From: Tobias Geiger <tobias.geiger@vido.info>
To: "Ren, Yongjie" <yongjie.ren@intel.com>
In-Reply-To: <1B4B44D9196EFF41AE41FDA404FC0A101933A2@SHSMSX101.ccr.corp.intel.com>
References: <1B4B44D9196EFF41AE41FDA404FC0A101881CE@SHSMSX101.ccr.corp.intel.com>
	<20120905185412.GA27077@phenom.dumpdata.com>
	<f74e17a2c22339a3eb0439a03bef10b1@vido.info>
	<1B4B44D9196EFF41AE41FDA404FC0A101933A2@SHSMSX101.ccr.corp.intel.com>
Message-ID: <cc83522f2f3490d6ede99e8681a222de@vido.info>
X-Sender: tobias.geiger@vido.info
User-Agent: Roundcube Webmail
Cc: Konrad Rzeszutek Wilk <konrad@kernel.org>, xen-devel@lists.xen.org,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel]
 =?utf-8?q?Regression_in_kernel_3=2E5_as_Dom0_regardin?=
 =?utf-8?q?g_PCI_Passthrough=3F!?=
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
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 07.09.2012 04:08, schrieb Ren, Yongjie:
>> -----Original Message-----
>> From: Tobias Geiger [mailto:tobias.geiger@vido.info]
>> Sent: Thursday, September 06, 2012 7:28 PM
>> To: Konrad Rzeszutek Wilk
>> Cc: Ren, Yongjie; Konrad Rzeszutek Wilk; xen-devel@lists.xen.org
>> Subject: Re: [Xen-devel] Regression in kernel 3.5 as Dom0 regarding 
>> PCI
>> Passthrough?!
>>
>> Hello Konrad,
>>
>> the patch helps regarding the USB-PCIController-Passthrough - this
>> works now in DomU.
>>
> Hi Tobias,
> In my testing, this patch can't work for a NIC pass-through.
> Could you have a try with a NIC pass-through?

Hi!

unfortunatly not - i have no physical access to the machine until the 
middle of next week.
and as so soon as i try to passthrough the only nic in this machine my 
remote access will die... :(

perhaps someone else can test nic-passthrough? if not i'll try it asap 
next week!

Greetings
Tobias

>
>> but i still get the Dom0 crash when shutting down DomU:
>>
>> Sep  6 13:26:19 pc kernel: [  361.011514]
>> xen-blkback:backend/vbd/1/832: prepare for reconnect
>> Sep  6 13:26:20 pc kernel: [  361.876395]
>> xen-blkback:backend/vbd/1/768: prepare for reconnect
>> Sep  6 13:26:21 pc kernel: [  362.682152] br0: port 3(vif1.0) 
>> entered
>> disabled state
>> Sep  6 13:26:21 pc kernel: [  362.682267] br0: port 3(vif1.0) 
>> entered
>> disabled state
>> Sep  6 13:26:24 pc kernel: [  365.541386] ------------[ cut here
>> ]------------
>> Sep  6 13:26:24 pc kernel: [  365.541411] invalid opcode: 0000 [#1]
>> PREEMPT SMP
>> Sep  6 13:26:24 pc kernel: [  365.541423] CPU 2
>> Sep  6 13:26:24 pc kernel: [  365.541427] Modules linked in: 
>> uvcvideo
>> snd_usb_audio snd_usbmidi_lib snd_seq_midi snd_hwd
>> ep snd_rawmidi videobuf2_vmalloc videobuf2_memops videobuf2_core
>> videodev gpio_ich joydev hid_generic [last unloaded: sc
>> si_wait_scan]
>> Sep  6 13:26:24 pc kernel: [  365.541474]
>> Sep  6 13:26:24 pc kernel: [  365.541477] Pid: 1208, comm: 
>> kworker/2:1
>> Not tainted 3.5.0 #3                  /DX58SO
>> Sep  6 13:26:24 pc kernel: [  365.541491] RIP:
>> e030:[<ffffffff81447f95>]  [<ffffffff81447f95>]
>> balloon_process+0x385/0x3
>> a0
>> Sep  6 13:26:24 pc kernel: [  365.541507] RSP: e02b:ffff88012e7abdc0
>> EFLAGS: 00010213
>> Sep  6 13:26:24 pc kernel: [  365.541515] RAX: 0000000220be7000 RBX:
>> 0000000000000000 RCX: 0000000000000008
>> Sep  6 13:26:24 pc kernel: [  365.541523] RDX: ffff88010d99a000 RSI:
>> 00000000000001df RDI: 000000000020efdf
>> Sep  6 13:26:24 pc kernel: [  365.541532] RBP: ffff88012e7abe20 R08:
>> ffff88014064e140 R09: 00000000fffffffe
>> Sep  6 13:26:24 pc kernel: [  365.541540] R10: 0000000000000001 R11:
>> 0000000000000000 R12: 0000160000000000
>> Sep  6 13:26:24 pc kernel: [  365.541548] R13: 0000000000000001 R14:
>> 000000000020efdf R15: ffffea00083bf7c0
>> Sep  6 13:26:24 pc kernel: [  365.541561] FS:  
>> 00007f79d32ce700(0000)
>> GS:ffff880140640000(0000) knlGS:0000000000000000
>> Sep  6 13:26:24 pc kernel: [  365.541571] CS:  e033 DS: 0000 ES: 
>> 0000
>> CR0: 000000008005003b
>> Sep  6 13:26:24 pc kernel: [  365.541578] CR2: 00007f79d2d6ce02 CR3:
>> 0000000001e0c000 CR4: 0000000000002660
>> Sep  6 13:26:24 pc kernel: [  365.541587] DR0: 0000000000000000 DR1:
>> 0000000000000000 DR2: 0000000000000000
>> Sep  6 13:26:24 pc kernel: [  365.541596] DR3: 0000000000000000 DR6:
>> 00000000ffff0ff0 DR7: 0000000000000400
>> Sep  6 13:26:24 pc kernel: [  365.541604] Process kworker/2:1 (pid:
>> 1208, threadinfo ffff88012e7aa000, task ffff88013101
>> c440)
>> Sep  6 13:26:24 pc kernel: [  365.541613] Stack:
>> Sep  6 13:26:24 pc kernel: [  365.541618]  000000000006877b
>> 0000000000000001 ffffffff8200ea80 0000000000000001
>> Sep  6 13:26:24 pc kernel: [  365.541649]  0000000000000000
>> 0000000000007ff0 ffff88012e7abe00 ffff8801302eee00
>> Sep  6 13:26:24 pc kernel: [  365.541664]  ffff880140657000
>> ffff88014064e140 0000000000000000 ffffffff81e587c0
>> Sep  6 13:26:24 pc kernel: [  365.541679] Call Trace:
>> Sep  6 13:26:24 pc kernel: [  365.541688]  [<ffffffff8106753b>]
>> process_one_work+0x12b/0x450
>> Sep  6 13:26:24 pc kernel: [  365.541697]  [<ffffffff81447c10>] ?
>> decrease_reservation+0x320/0x320
>> Sep  6 13:26:24 pc kernel: [  365.541706]  [<ffffffff810688be>]
>> worker_thread+0x12e/0x2d0
>> Sep  6 13:26:24 pc kernel: [  365.541715]  [<ffffffff81068790>] ?
>> manage_workers.isra.26+0x1f0/0x1f0
>> Sep  6 13:26:24 pc kernel: [  365.541725]  [<ffffffff8106db7e>]
>> kthread+0x8e/0xa0
>> Sep  6 13:26:24 pc kernel: [  365.541735]  [<ffffffff8184e3e4>]
>> kernel_thread_helper+0x4/0x10
>> Sep  6 13:26:24 pc kernel: [  365.541745]  [<ffffffff8184c87c>] ?
>> retint_restore_args+0x5/0x6
>> Sep  6 13:26:24 pc kernel: [  365.541754]  [<ffffffff8184e3e0>] ?
>> gs_change+0x13/0x13
>> Sep  6 13:26:24 pc kernel: [  365.541760] Code: 01 15 f0 6a bc 00 48 
>> 29
>> d0 48 89 05 ee 6a bc 00 e9 31 fd ff ff 0f 0b 0f
>> 0b 4c 89 f7 e8 85 34 bc ff 48 83 f8 ff 0f 84 2b fe ff ff <0f> 0b 66 
>> 0f
>> 1f 84 00 00 00 00 00 48 83 c1 01 e9 c2 fd ff ff 0
>> f
>> Sep  6 13:26:24 pc kernel: [  365.541898]  RSP <ffff88012e7abdc0>
>> Sep  6 13:26:24 pc kernel: [  365.565054] ---[ end trace
>> 25eb9ce0cc61c3a1 ]---
>> Sep  6 13:26:24 pc kernel: [  365.565101] PGD 1e0e067 PUD 1e0f067
>> PMD 0
>> Sep  6 13:26:24 pc kernel: [  365.565108] Oops: 0000 [#2] PREEMPT 
>> SMP
>> Sep  6 13:26:24 pc kernel: [  365.565115] CPU 2
>> Sep  6 13:26:24 pc kernel: [  365.565118] Modules linked in: 
>> uvcvideo
>> snd_usb_audio snd_usbmidi_lib snd_seq_midi snd_hwd
>> ep snd_rawmidi videobuf2_vmalloc videobuf2_memops videobuf2_core
>> videodev gpio_ich joydev hid_generic [last unloaded: sc
>> si_wait_scan]
>> Sep  6 13:26:24 pc kernel: [  365.565153]
>> Sep  6 13:26:24 pc kernel: [  365.565156] Pid: 1208, comm: 
>> kworker/2:1
>> Tainted: G      D      3.5.0 #3
>> /DX58SO
>> Sep  6 13:26:24 pc kernel: [  365.565176] RIP:
>> e030:[<ffffffff8106e08c>]  [<ffffffff8106e08c>] 
>> kthread_data+0xc/0x20
>> Sep  6 13:26:24 pc kernel: [  365.565194] RSP: e02b:ffff88012e7aba90
>> EFLAGS: 00010092
>> Sep  6 13:26:24 pc kernel: [  365.565205] RAX: 0000000000000000 RBX:
>> 0000000000000002 RCX: 0000000000000002
>> Sep  6 13:26:24 pc kernel: [  365.565219] RDX: ffffffff81fcba40 RSI:
>> 0000000000000002 RDI: ffff88013101c440
>> Sep  6 13:26:24 pc kernel: [  365.565233] RBP: ffff88012e7abaa8 R08:
>> 0000000000989680 R09: ffffffff81fcba40
>> Sep  6 13:26:24 pc kernel: [  365.565248] R10: ffffffff813b0c00 R11:
>> 0000000000000000 R12: ffff8801406536c0
>> Sep  6 13:26:24 pc kernel: [  365.565262] R13: 0000000000000002 R14:
>> ffff88013101c430 R15: ffff88013101c440
>> Sep  6 13:26:24 pc kernel: [  365.565280] FS:  
>> 00007f79d32ce700(0000)
>> GS:ffff880140640000(0000) knlGS:0000000000000000
>> Sep  6 13:26:24 pc kernel: [  365.565293] CS:  e033 DS: 0000 ES: 
>> 0000
>> CR0: 000000008005003b
>> Sep  6 13:26:24 pc kernel: [  365.565303] CR2: fffffffffffffff8 CR3:
>> 0000000001e0c000 CR4: 0000000000002660
>> Sep  6 13:26:24 pc kernel: [  365.565318] DR0: 0000000000000000 DR1:
>> 0000000000000000 DR2: 0000000000000000
>> Sep  6 13:26:24 pc kernel: [  365.565332] DR3: 0000000000000000 DR6:
>> 00000000ffff0ff0 DR7: 0000000000000400
>> Sep  6 13:26:24 pc kernel: [  365.565349] Process kworker/2:1 (pid:
>> 1208, threadinfo ffff88012e7aa000, task ffff88013101
>> c440)
>> Sep  6 13:26:24 pc kernel: [  365.565362] Stack:
>> Sep  6 13:26:24 pc kernel: [  365.565367]  ffffffff810698e0
>> ffff88012e7abaa8 ffff88013101c818 ffff88012e7abb18
>> Sep  6 13:26:24 pc kernel: [  365.565389]  ffffffff8184ae02
>> ffff88012e7abfd8 ffff88013101c440 ffff88012e7abfd8
>> Sep  6 13:26:24 pc kernel: [  365.565410]  ffff88012e7abfd8
>> ffff88012d8840c0 ffff88013101c440 ffff88013101ca30
>>
>>
>>
>> Perhaps this stacktrace helps...
>>
>> Thanks!
>>
>> Am 05.09.2012 20:54, schrieb Konrad Rzeszutek Wilk:
>> >> > > > And its due to a patch I added in v3.4
>> >> > > > (cd9db80e5257682a7f7ab245a2459648b3c8d268)
>> >> > > > - which did not work properly in v3.4, but with v3.5 got it
>> >> working
>> >> > > > (977f857ca566a1e68045fcbb7cfc9c4acb077cf0) which causes 
>> v3.5
>> >> to
>> >> > now
>> >> > > > work
>> >> > > > anymore.
>> >> > > >
>> >> > > > Anyhow, for right now jsut revert
>> >> > > > cd9db80e5257682a7f7ab245a2459648b3c8d268
>> >> > > > and it should work for you.
>> >> > > >
>> >> Confirmed, after reverting that commit, VT-d will work fine.
>> >> Will you fix this and push it to upstream Linux, Konrad?
>> >>
>> >> > > Also, our team reported a VT-d bug 2 months ago.
>> >> > > http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1824
>> >> >
>> >
>> > Can either one of you please test this patch, please:
>> >
>> >
>> > diff --git a/drivers/xen/xen-pciback/pci_stub.c
>> > b/drivers/xen/xen-pciback/pci_stub.c
>> > index 097e536..425bd0b 100644
>> > --- a/drivers/xen/xen-pciback/pci_stub.c
>> > +++ b/drivers/xen/xen-pciback/pci_stub.c
>> > @@ -4,6 +4,8 @@
>> >   * Ryan Wilson <hap9@epoch.ncsc.mil>
>> >   * Chris Bookholt <hap10@epoch.ncsc.mil>
>> >   */
>> > +#define DEBUG 1
>> > +
>> >  #include <linux/module.h>
>> >  #include <linux/init.h>
>> >  #include <linux/rwsem.h>
>> > @@ -97,13 +99,15 @@ static void pcistub_device_release(struct kref
>> > *kref)
>> >  	/* Call the reset function which does not take lock as this
>> >  	 * is called from "unbind" which takes a device_lock mutex.
>> >  	 */
>> > +	dev_dbg(&psdev->dev->dev, "FLR locked..\n");
>> >  	__pci_reset_function_locked(psdev->dev);
>> >  	if (pci_load_and_free_saved_state(psdev->dev,
>> >  					  &dev_data->pci_saved_state)) {
>> >  		dev_dbg(&psdev->dev->dev, "Could not reload PCI state\n");
>> > -	} else
>> > +	} else {
>> > +		dev_dbg(&psdev->dev->dev, "Reloading PCI state..\n");
>> >  		pci_restore_state(psdev->dev);
>> > -
>> > +	}
>> >  	/* Disable the device */
>> >  	xen_pcibk_reset_device(psdev->dev);
>> >
>> > @@ -353,16 +357,16 @@ static int __devinit 
>> pcistub_init_device(struct
>> > pci_dev *dev)
>> >  	if (err)
>> >  		goto config_release;
>> >
>> > -	dev_dbg(&dev->dev, "reseting (FLR, D3, etc) the device\n");
>> > -	__pci_reset_function_locked(dev);
>> > -
>> >  	/* We need the device active to save the state. */
>> >  	dev_dbg(&dev->dev, "save state of device\n");
>> >  	pci_save_state(dev);
>> >  	dev_data->pci_saved_state = pci_store_saved_state(dev);
>> >  	if (!dev_data->pci_saved_state)
>> >  		dev_err(&dev->dev, "Could not store PCI conf saved state!\n");
>> > -
>> > +	else {
>> > +		dev_dbg(&dev->dev, "reseting (FLR, D3, etc) the device\n");
>> > +		__pci_reset_function_locked(dev);
>> > +	}
>> >  	/* Now disable the device (this also ensures some private device
>> >  	 * data is setup before we export)
>> >  	 */


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 07 10:49:35 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Sep 2012 10:49:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9w7k-0008Dz-9h; Fri, 07 Sep 2012 10:49:20 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <zhenzhong.duan@oracle.com>) id 1T9w7i-0008Dr-Qd
	for xen-devel@lists.xen.org; Fri, 07 Sep 2012 10:49:19 +0000
Received: from [85.158.143.35:9594] by server-1.bemta-4.messagelabs.com id
	0B/AD-12504-E21D9405; Fri, 07 Sep 2012 10:49:18 +0000
X-Env-Sender: zhenzhong.duan@oracle.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1347014956!14649135!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDc0NDUwMw==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10290 invoked from network); 7 Sep 2012 10:49:17 -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 Sep 2012 10:49:17 -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 q87AnDg7007222
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 7 Sep 2012 10:49:14 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
	q87AnBpm000862
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 7 Sep 2012 10:49:12 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
	q87AnBxK023783; Fri, 7 Sep 2012 05:49:11 -0500
Received: from [192.168.1.100] (/106.3.102.44)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 07 Sep 2012 03:49:11 -0700
Message-ID: <5049D16D.8060602@oracle.com>
Date: Fri, 07 Sep 2012 18:50:21 +0800
From: "zhenzhong.duan" <zhenzhong.duan@oracle.com>
Organization: oracle
User-Agent: Mozilla/5.0 (Windows NT 5.1;
	rv:12.0) Gecko/20120428 Thunderbird/12.0.1
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <504764510200007800098DE5@nat28.tlf.novell.com>
In-Reply-To: <504764510200007800098DE5@nat28.tlf.novell.com>
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: dan.magenheimer@oracle.com, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 10/11] tmem: fixup 2010 cleanup patch that
 breaks tmem save/restore
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: zhenzhong.duan@oracle.com
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 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

SGkgSmFuLCBEYW4KCldpdGggdGhpcyBwYXRjaCBhcHBsaWVkLCAneG0gc2F2ZScgd29ya2VkLCBy
ZXN0b3JlIGZhaWxlZC4gU2VlIGJlbG93Ogpbcm9vdEBzdXN0YWluaW5nMTMgT1ZNX09MNVU3X1g4
Nl82NF9QVk1fMTBHQl0jIHhtIGxpc3QKTmFtZSBJRCBNZW0gVkNQVXMgU3RhdGUgVGltZShzKQpE
b21haW4tMCAwIDUzNyAyIHItLS0tLSAyNTUuMwpPVk1fT0w1VTdfWDg2XzY0X1BWTV8xMEdCIDEg
MTAyNCAyIC1iLS0tLSA3Ni4yCltyb290QHN1c3RhaW5pbmcxMyBPVk1fT0w1VTdfWDg2XzY0X1BW
TV8xMEdCXSMgeG0gc2F2ZSAxIGRlbGV0ZQpbcm9vdEBzdXN0YWluaW5nMTMgT1ZNX09MNVU3X1g4
Nl82NF9QVk1fMTBHQl0jCltyb290QHN1c3RhaW5pbmcxMyBPVk1fT0w1VTdfWDg2XzY0X1BWTV8x
MEdCXSMgeG0gcmVzdG9yZSBkZWxldGUKRXJyb3I6IC91c3IvbGliNjQveGVuL2Jpbi94Y19yZXN0
b3JlIDQgMiAxIDIgMCAwIDAgMCBmYWlsZWQKVXNhZ2U6IHhtIHJlc3RvcmUgPENoZWNrcG9pbnRG
aWxlPiBbLXBdCgpSZXN0b3JlIGEgZG9tYWluIGZyb20gYSBzYXZlZCBzdGF0ZS4KLXAsIC0tcGF1
c2VkIERvIG5vdCB1bnBhdXNlIGRvbWFpbiBhZnRlciByZXN0b3JpbmcgaXQKW3Jvb3RAc3VzdGFp
bmluZzEzIE9WTV9PTDVVN19YODZfNjRfUFZNXzEwR0JdIyB4bSBkbWVzZzoKKFhFTikgdG1lbS5j
OjIwMzc6ZDAgdG1lbTogYWxsIHBvb2xzIGZyb3plbiBmb3IgYWxsIGRvbWFpbnMKKFhFTikgdG1l
bS5jOjIwMzc6ZDAgdG1lbTogYWxsIHBvb2xzIHRoYXdlZCBmb3IgYWxsIGRvbWFpbnMKKFhFTikg
dG1lbS5jOjIwMzc6ZDAgdG1lbTogYWxsIHBvb2xzIGZyb3plbiBmb3IgYWxsIGRvbWFpbnMKKFhF
TikgdG1lbS5jOjIwMzc6ZDAgdG1lbTogYWxsIHBvb2xzIHRoYXdlZCBmb3IgYWxsIGRvbWFpbnMK
KFhFTikgdG1lbS5jOjEyMjA6ZDEgdG1lbTogaW5pdGlhbGl6aW5nIHRtZW0gY2FwYWJpbGl0eSBm
b3IgCmRvbWlkPTEuLi48Rz48Mj50bWVtLmM6MTI1NjpkMSBvawooWEVOKSB0bWVtLmM6MTkxMjpk
MSB0bWVtOiBhbGxvY2F0aW5nIGVwaGVtZXJhbC1wcml2YXRlIHRtZW0gcG9vbCBmb3IgCmRvbWlk
PTEuLi48Rz48Mj50bWVtLmM6MjAxNDpkMSBwb29sX2lkPTAKKFhFTikgdG1lbS5jOjE5MTI6ZDEg
dG1lbTogYWxsb2NhdGluZyBlcGhlbWVyYWwtcHJpdmF0ZSB0bWVtIHBvb2wgZm9yIApkb21pZD0x
Li4uPEc+PDI+dG1lbS5jOjIwMTQ6ZDEgcG9vbF9pZD0xCihYRU4pIHRtZW0uYzoxOTEyOmQxIHRt
ZW06IGFsbG9jYXRpbmcgcGVyc2lzdGVudC1wcml2YXRlIHRtZW0gcG9vbCBmb3IgCmRvbWlkPTEu
Li48Rz48Mj50bWVtLmM6MjAxNDpkMSBwb29sX2lkPTIKKFhFTikgdG1lbS5jOjI4NTU6ZDAgdG1l
bTogZmx1c2hpbmcgdG1lbSBwb29scyBmb3IgZG9taWQ9MQooWEVOKSB0bWVtLmM6MTE5NzpkMCBk
ZXN0cm95aW5nIGVwaGVtZXJhbC1wcml2YXRlIHRtZW0gcG9vbCAKPEc+PDI+dG1lbS5jOjExOTg6
ZDAgZG9taWQ9MSBwb29sX2lkPTAKKFhFTikgdG1lbS5jOjExOTc6ZDAgZGVzdHJveWluZyBlcGhl
bWVyYWwtcHJpdmF0ZSB0bWVtIHBvb2wgCjxHPjwyPnRtZW0uYzoxMTk4OmQwIGRvbWlkPTEgcG9v
bF9pZD0xCihYRU4pIHRtZW0uYzoxMTk3OmQwIGRlc3Ryb3lpbmcgcGVyc2lzdGVudC1wcml2YXRl
IHRtZW0gcG9vbCAKPEc+PDI+dG1lbS5jOjExOTg6ZDAgZG9taWQ9MSBwb29sX2lkPTIKKFhFTikg
dG1lbS5jOjIwMzc6ZDAgdG1lbTogYWxsIHBvb2xzIGZyb3plbiBmb3IgYWxsIGRvbWFpbnMKKFhF
TikgdG1lbS5jOjIwMzc6ZDAgdG1lbTogYWxsIHBvb2xzIHRoYXdlZCBmb3IgYWxsIGRvbWFpbnMK
KFhFTikgdG1lbS5jOjIwMzc6ZDAgdG1lbTogYWxsIHBvb2xzIGZyb3plbiBmb3IgYWxsIGRvbWFp
bnMKKFhFTikgdG1lbS5jOjIwMzc6ZDAgdG1lbTogYWxsIHBvb2xzIHRoYXdlZCBmb3IgYWxsIGRv
bWFpbnMKKFhFTikgdG1lbS5jOjEyMjA6ZDAgdG1lbTogaW5pdGlhbGl6aW5nIHRtZW0gY2FwYWJp
bGl0eSBmb3IgCmRvbWlkPTIuLi48Rz48Mj50bWVtLmM6MTI1NjpkMCBvawooWEVOKSB0bWVtLmM6
MjI2ODpkMCB0bWVtOiB3ZWlnaHQgc2V0IHRvIDAgZm9yIGRvbWlkPTIKKFhFTikgdG1lbS5jOjIy
NzQ6ZDAgdG1lbTogY2FwIHNldCB0byAwIGZvciBkb21pZD0yCihYRU4pIHRtZW0uYzoxOTEyOmQw
IHRtZW06IGFsbG9jYXRpbmcgZXBoZW1lcmFsLXByaXZhdGUgdG1lbSBwb29sIGZvciAKZG9taWQ9
Mi4uLjxHPjwyPnRtZW0uYzoxOTE1OmQwIGZhaWxlZC4uLiB1bnN1cHBvcnRlZCBzcGVjIHZlcnNp
b24KCuS6jiAyMDEyLTA5LTA1IDIwOjQwLCBKYW4gQmV1bGljaCDlhpnpgZM6Cj4gMjA5MTg6YTNm
YTZkNDQ0YjI1ICJGaXggZG9tYWluIHJlZmVyZW5jZSBsZWFrcyIgKGluIEZlYiAyMDEwLCBieSBK
YW4pCj4gZG9lcyBzb21lIGNsZWFudXAgaW4gYWRkaXRpb24gdG8gdGhlIGxlYWsgZml4ZXMuICBV
bmZvcnR1bmF0ZWx5LCB0aGF0Cj4gY2xlYW51cCBpbmFkdmVydGVudGx5IHJlc3VsdGVkIGluIGFu
IGluY29ycmVjdCBmYWxsdGhyb3VnaCBpbiBhIHN3aXRjaAo+IHN0YXRlbWVudCB3aGljaCBicmVh
a3MgdG1lbSBzYXZlL3Jlc3RvcmUuCj4KPiBUaGF0IGJyb2tlbiBwYXRjaCB3YXMgYXBwYXJlbnRs
eSBhcHBsaWVkIHRvIDQuMC10ZXN0aW5nIGFuZCA0LjEtdGVzdGluZwo+IHNvIHRob3NlIGFyZSBi
cm9rZW4gYXMgd2VsbC4KPgo+IFdoYXQgaXMgdGhlIHByb2Nlc3Mgbm93IGZvciByZXF1ZXN0aW5n
IGJhY2stcGF0Y2hlcyB0byA0LjAgYW5kIDQuMT8KPgo+IChTaWRlIG5vdGU6IFRoaXMgZG9lcyBu
b3QgYnkgaXRzZWxmIGVudGlyZWx5IGZpeCBzYXZlL3Jlc3RvcmUgaW4gNC4yLikKPgo+IFNpZ25l
ZC1vZmYtYnk6IERhbiBNYWdlbmhlaW1lcjxkYW4ubWFnZW5oZWltZXJAb3JhY2xlLmNvbT4KPiBT
aWduZWQtb2ZmLWJ5OiBKYW4gQmV1bGljaDxqYmV1bGljaEBzdXNlLmNvbT4KPgo+IC0tLSBhL3hl
bi9jb21tb24vdG1lbS5jCj4gKysrIGIveGVuL2NvbW1vbi90bWVtLmMKPiBAQCAtMjQxNSw2ICsy
NDE1LDcgQEAgc3RhdGljIE5PSU5MSU5FIGludCB0bWVtY19zYXZlX3N1Ym9wKGludAo+ICAgICAg
ICAgICAgICAgIGJyZWFrOwo+ICAgICAgICAgICB0bWhfY29weV90b19jbGllbnRfYnVmKGJ1Ziwg
cG9vbC0+dXVpZCwgMik7Cj4gICAgICAgICAgIHJjID0gMDsKPiArICAgICAgICBicmVhazsKPiAg
ICAgICBjYXNlIFRNRU1DX1NBVkVfRU5EOgo+ICAgICAgICAgICBpZiAoIGNsaWVudCA9PSBOVUxM
ICkKPiAgICAgICAgICAgICAgIGJyZWFrOwo+IEBAIC0yNDI1LDYgKzI0MjYsNyBAQCBzdGF0aWMg
Tk9JTkxJTkUgaW50IHRtZW1jX3NhdmVfc3Vib3AoaW50Cj4gICAgICAgICAgICAgICAgICAgcGdw
X2ZyZWVfZnJvbV9pbnZfbGlzdChjbGllbnQscGdwKTsKPiAgICAgICAgICAgY2xpZW50LT5mcm96
ZW4gPSBjbGllbnQtPndhc19mcm96ZW47Cj4gICAgICAgICAgIHJjID0gMDsKPiArICAgICAgICBi
cmVhazsKPiAgICAgICB9Cj4gICAgICAgcmV0dXJuIHJjOwo+ICAgfQo+Cj4KPgoKX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxpbmcg
bGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwOi8vbGlzdHMueGVuLm9yZy94ZW4tZGV2
ZWwK

From xen-devel-bounces@lists.xen.org Fri Sep 07 10:49:35 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Sep 2012 10:49:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9w7k-0008Dz-9h; Fri, 07 Sep 2012 10:49:20 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <zhenzhong.duan@oracle.com>) id 1T9w7i-0008Dr-Qd
	for xen-devel@lists.xen.org; Fri, 07 Sep 2012 10:49:19 +0000
Received: from [85.158.143.35:9594] by server-1.bemta-4.messagelabs.com id
	0B/AD-12504-E21D9405; Fri, 07 Sep 2012 10:49:18 +0000
X-Env-Sender: zhenzhong.duan@oracle.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1347014956!14649135!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDc0NDUwMw==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10290 invoked from network); 7 Sep 2012 10:49:17 -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 Sep 2012 10:49:17 -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 q87AnDg7007222
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 7 Sep 2012 10:49:14 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
	q87AnBpm000862
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 7 Sep 2012 10:49:12 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
	q87AnBxK023783; Fri, 7 Sep 2012 05:49:11 -0500
Received: from [192.168.1.100] (/106.3.102.44)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 07 Sep 2012 03:49:11 -0700
Message-ID: <5049D16D.8060602@oracle.com>
Date: Fri, 07 Sep 2012 18:50:21 +0800
From: "zhenzhong.duan" <zhenzhong.duan@oracle.com>
Organization: oracle
User-Agent: Mozilla/5.0 (Windows NT 5.1;
	rv:12.0) Gecko/20120428 Thunderbird/12.0.1
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <504764510200007800098DE5@nat28.tlf.novell.com>
In-Reply-To: <504764510200007800098DE5@nat28.tlf.novell.com>
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: dan.magenheimer@oracle.com, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 10/11] tmem: fixup 2010 cleanup patch that
 breaks tmem save/restore
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: zhenzhong.duan@oracle.com
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 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

SGkgSmFuLCBEYW4KCldpdGggdGhpcyBwYXRjaCBhcHBsaWVkLCAneG0gc2F2ZScgd29ya2VkLCBy
ZXN0b3JlIGZhaWxlZC4gU2VlIGJlbG93Ogpbcm9vdEBzdXN0YWluaW5nMTMgT1ZNX09MNVU3X1g4
Nl82NF9QVk1fMTBHQl0jIHhtIGxpc3QKTmFtZSBJRCBNZW0gVkNQVXMgU3RhdGUgVGltZShzKQpE
b21haW4tMCAwIDUzNyAyIHItLS0tLSAyNTUuMwpPVk1fT0w1VTdfWDg2XzY0X1BWTV8xMEdCIDEg
MTAyNCAyIC1iLS0tLSA3Ni4yCltyb290QHN1c3RhaW5pbmcxMyBPVk1fT0w1VTdfWDg2XzY0X1BW
TV8xMEdCXSMgeG0gc2F2ZSAxIGRlbGV0ZQpbcm9vdEBzdXN0YWluaW5nMTMgT1ZNX09MNVU3X1g4
Nl82NF9QVk1fMTBHQl0jCltyb290QHN1c3RhaW5pbmcxMyBPVk1fT0w1VTdfWDg2XzY0X1BWTV8x
MEdCXSMgeG0gcmVzdG9yZSBkZWxldGUKRXJyb3I6IC91c3IvbGliNjQveGVuL2Jpbi94Y19yZXN0
b3JlIDQgMiAxIDIgMCAwIDAgMCBmYWlsZWQKVXNhZ2U6IHhtIHJlc3RvcmUgPENoZWNrcG9pbnRG
aWxlPiBbLXBdCgpSZXN0b3JlIGEgZG9tYWluIGZyb20gYSBzYXZlZCBzdGF0ZS4KLXAsIC0tcGF1
c2VkIERvIG5vdCB1bnBhdXNlIGRvbWFpbiBhZnRlciByZXN0b3JpbmcgaXQKW3Jvb3RAc3VzdGFp
bmluZzEzIE9WTV9PTDVVN19YODZfNjRfUFZNXzEwR0JdIyB4bSBkbWVzZzoKKFhFTikgdG1lbS5j
OjIwMzc6ZDAgdG1lbTogYWxsIHBvb2xzIGZyb3plbiBmb3IgYWxsIGRvbWFpbnMKKFhFTikgdG1l
bS5jOjIwMzc6ZDAgdG1lbTogYWxsIHBvb2xzIHRoYXdlZCBmb3IgYWxsIGRvbWFpbnMKKFhFTikg
dG1lbS5jOjIwMzc6ZDAgdG1lbTogYWxsIHBvb2xzIGZyb3plbiBmb3IgYWxsIGRvbWFpbnMKKFhF
TikgdG1lbS5jOjIwMzc6ZDAgdG1lbTogYWxsIHBvb2xzIHRoYXdlZCBmb3IgYWxsIGRvbWFpbnMK
KFhFTikgdG1lbS5jOjEyMjA6ZDEgdG1lbTogaW5pdGlhbGl6aW5nIHRtZW0gY2FwYWJpbGl0eSBm
b3IgCmRvbWlkPTEuLi48Rz48Mj50bWVtLmM6MTI1NjpkMSBvawooWEVOKSB0bWVtLmM6MTkxMjpk
MSB0bWVtOiBhbGxvY2F0aW5nIGVwaGVtZXJhbC1wcml2YXRlIHRtZW0gcG9vbCBmb3IgCmRvbWlk
PTEuLi48Rz48Mj50bWVtLmM6MjAxNDpkMSBwb29sX2lkPTAKKFhFTikgdG1lbS5jOjE5MTI6ZDEg
dG1lbTogYWxsb2NhdGluZyBlcGhlbWVyYWwtcHJpdmF0ZSB0bWVtIHBvb2wgZm9yIApkb21pZD0x
Li4uPEc+PDI+dG1lbS5jOjIwMTQ6ZDEgcG9vbF9pZD0xCihYRU4pIHRtZW0uYzoxOTEyOmQxIHRt
ZW06IGFsbG9jYXRpbmcgcGVyc2lzdGVudC1wcml2YXRlIHRtZW0gcG9vbCBmb3IgCmRvbWlkPTEu
Li48Rz48Mj50bWVtLmM6MjAxNDpkMSBwb29sX2lkPTIKKFhFTikgdG1lbS5jOjI4NTU6ZDAgdG1l
bTogZmx1c2hpbmcgdG1lbSBwb29scyBmb3IgZG9taWQ9MQooWEVOKSB0bWVtLmM6MTE5NzpkMCBk
ZXN0cm95aW5nIGVwaGVtZXJhbC1wcml2YXRlIHRtZW0gcG9vbCAKPEc+PDI+dG1lbS5jOjExOTg6
ZDAgZG9taWQ9MSBwb29sX2lkPTAKKFhFTikgdG1lbS5jOjExOTc6ZDAgZGVzdHJveWluZyBlcGhl
bWVyYWwtcHJpdmF0ZSB0bWVtIHBvb2wgCjxHPjwyPnRtZW0uYzoxMTk4OmQwIGRvbWlkPTEgcG9v
bF9pZD0xCihYRU4pIHRtZW0uYzoxMTk3OmQwIGRlc3Ryb3lpbmcgcGVyc2lzdGVudC1wcml2YXRl
IHRtZW0gcG9vbCAKPEc+PDI+dG1lbS5jOjExOTg6ZDAgZG9taWQ9MSBwb29sX2lkPTIKKFhFTikg
dG1lbS5jOjIwMzc6ZDAgdG1lbTogYWxsIHBvb2xzIGZyb3plbiBmb3IgYWxsIGRvbWFpbnMKKFhF
TikgdG1lbS5jOjIwMzc6ZDAgdG1lbTogYWxsIHBvb2xzIHRoYXdlZCBmb3IgYWxsIGRvbWFpbnMK
KFhFTikgdG1lbS5jOjIwMzc6ZDAgdG1lbTogYWxsIHBvb2xzIGZyb3plbiBmb3IgYWxsIGRvbWFp
bnMKKFhFTikgdG1lbS5jOjIwMzc6ZDAgdG1lbTogYWxsIHBvb2xzIHRoYXdlZCBmb3IgYWxsIGRv
bWFpbnMKKFhFTikgdG1lbS5jOjEyMjA6ZDAgdG1lbTogaW5pdGlhbGl6aW5nIHRtZW0gY2FwYWJp
bGl0eSBmb3IgCmRvbWlkPTIuLi48Rz48Mj50bWVtLmM6MTI1NjpkMCBvawooWEVOKSB0bWVtLmM6
MjI2ODpkMCB0bWVtOiB3ZWlnaHQgc2V0IHRvIDAgZm9yIGRvbWlkPTIKKFhFTikgdG1lbS5jOjIy
NzQ6ZDAgdG1lbTogY2FwIHNldCB0byAwIGZvciBkb21pZD0yCihYRU4pIHRtZW0uYzoxOTEyOmQw
IHRtZW06IGFsbG9jYXRpbmcgZXBoZW1lcmFsLXByaXZhdGUgdG1lbSBwb29sIGZvciAKZG9taWQ9
Mi4uLjxHPjwyPnRtZW0uYzoxOTE1OmQwIGZhaWxlZC4uLiB1bnN1cHBvcnRlZCBzcGVjIHZlcnNp
b24KCuS6jiAyMDEyLTA5LTA1IDIwOjQwLCBKYW4gQmV1bGljaCDlhpnpgZM6Cj4gMjA5MTg6YTNm
YTZkNDQ0YjI1ICJGaXggZG9tYWluIHJlZmVyZW5jZSBsZWFrcyIgKGluIEZlYiAyMDEwLCBieSBK
YW4pCj4gZG9lcyBzb21lIGNsZWFudXAgaW4gYWRkaXRpb24gdG8gdGhlIGxlYWsgZml4ZXMuICBV
bmZvcnR1bmF0ZWx5LCB0aGF0Cj4gY2xlYW51cCBpbmFkdmVydGVudGx5IHJlc3VsdGVkIGluIGFu
IGluY29ycmVjdCBmYWxsdGhyb3VnaCBpbiBhIHN3aXRjaAo+IHN0YXRlbWVudCB3aGljaCBicmVh
a3MgdG1lbSBzYXZlL3Jlc3RvcmUuCj4KPiBUaGF0IGJyb2tlbiBwYXRjaCB3YXMgYXBwYXJlbnRs
eSBhcHBsaWVkIHRvIDQuMC10ZXN0aW5nIGFuZCA0LjEtdGVzdGluZwo+IHNvIHRob3NlIGFyZSBi
cm9rZW4gYXMgd2VsbC4KPgo+IFdoYXQgaXMgdGhlIHByb2Nlc3Mgbm93IGZvciByZXF1ZXN0aW5n
IGJhY2stcGF0Y2hlcyB0byA0LjAgYW5kIDQuMT8KPgo+IChTaWRlIG5vdGU6IFRoaXMgZG9lcyBu
b3QgYnkgaXRzZWxmIGVudGlyZWx5IGZpeCBzYXZlL3Jlc3RvcmUgaW4gNC4yLikKPgo+IFNpZ25l
ZC1vZmYtYnk6IERhbiBNYWdlbmhlaW1lcjxkYW4ubWFnZW5oZWltZXJAb3JhY2xlLmNvbT4KPiBT
aWduZWQtb2ZmLWJ5OiBKYW4gQmV1bGljaDxqYmV1bGljaEBzdXNlLmNvbT4KPgo+IC0tLSBhL3hl
bi9jb21tb24vdG1lbS5jCj4gKysrIGIveGVuL2NvbW1vbi90bWVtLmMKPiBAQCAtMjQxNSw2ICsy
NDE1LDcgQEAgc3RhdGljIE5PSU5MSU5FIGludCB0bWVtY19zYXZlX3N1Ym9wKGludAo+ICAgICAg
ICAgICAgICAgIGJyZWFrOwo+ICAgICAgICAgICB0bWhfY29weV90b19jbGllbnRfYnVmKGJ1Ziwg
cG9vbC0+dXVpZCwgMik7Cj4gICAgICAgICAgIHJjID0gMDsKPiArICAgICAgICBicmVhazsKPiAg
ICAgICBjYXNlIFRNRU1DX1NBVkVfRU5EOgo+ICAgICAgICAgICBpZiAoIGNsaWVudCA9PSBOVUxM
ICkKPiAgICAgICAgICAgICAgIGJyZWFrOwo+IEBAIC0yNDI1LDYgKzI0MjYsNyBAQCBzdGF0aWMg
Tk9JTkxJTkUgaW50IHRtZW1jX3NhdmVfc3Vib3AoaW50Cj4gICAgICAgICAgICAgICAgICAgcGdw
X2ZyZWVfZnJvbV9pbnZfbGlzdChjbGllbnQscGdwKTsKPiAgICAgICAgICAgY2xpZW50LT5mcm96
ZW4gPSBjbGllbnQtPndhc19mcm96ZW47Cj4gICAgICAgICAgIHJjID0gMDsKPiArICAgICAgICBi
cmVhazsKPiAgICAgICB9Cj4gICAgICAgcmV0dXJuIHJjOwo+ICAgfQo+Cj4KPgoKX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxpbmcg
bGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwOi8vbGlzdHMueGVuLm9yZy94ZW4tZGV2
ZWwK

From xen-devel-bounces@lists.xen.org Fri Sep 07 11:01:50 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Sep 2012 11:01:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9wJZ-00005T-GL; Fri, 07 Sep 2012 11:01:33 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ianc@xenbits.xen.org>) id 1T9w04-0007wb-0y
	for xen-devel@lists.xen.org; Fri, 07 Sep 2012 10:41:24 +0000
Received: from [85.158.143.99:27931] by server-2.bemta-4.messagelabs.com id
	BF/E0-21239-15FC9405; Fri, 07 Sep 2012 10:41:21 +0000
X-Env-Sender: ianc@xenbits.xen.org
X-Msg-Ref: server-7.tower-216.messagelabs.com!1347014470!25727106!1
X-Originating-IP: [50.57.168.107]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15372 invoked from network); 7 Sep 2012 10:41:12 -0000
Received: from mail.xen.org (HELO mail.xen.org) (50.57.168.107)
	by server-7.tower-216.messagelabs.com with AES256-SHA encrypted SMTP;
	7 Sep 2012 10:41:12 -0000
Received: from xenbits.xen.org ([50.57.170.242])
	by mail.xen.org with esmtp (Exim 4.72)
	(envelope-from <ianc@xenbits.xen.org>)
	id 1T9vzi-0003JO-5i; Fri, 07 Sep 2012 10:41:02 +0000
Received: from ianc by xenbits.xen.org with local (Exim 4.72)
	(envelope-from <ianc@xenbits.xen.org>)
	id 1T9vzh-0000k0-IX; Fri, 07 Sep 2012 10:41:01 +0000
Date: Fri, 07 Sep 2012 10:41:01 +0000
Message-Id: <E1T9vzh-0000k0-IX@xenbits.xen.org>
Content-Type: multipart/mixed; boundary="=separator"; charset="utf-8"
Content-Transfer-Encoding: binary
MIME-Version: 1.0
X-Mailer: MIME-tools 5.428 (Entity 5.428)
To: xen-announce@lists.xen.org, xen-devel@lists.xen.org,
	xen-users@lists.xen.org, oss-security@lists.openwall.com
From: Xen.org security team <security@xen.org>
X-Mailman-Approved-At: Fri, 07 Sep 2012 11:01:31 +0000
Cc: "Xen.org security team" <security@xen.org>
Subject: [Xen-devel] Xen Security Advisory 19 (CVE-2012-4411) - guest
 administrator can access qemu monitor console
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--=separator
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

                 Xen Security Advisory CVE-2012-4411 / XSA-19
			      version 2

         guest administrator can access qemu monitor console

UPDATES IN VERSION 2
====================

We have now been issued with a CVE number.

ISSUE DESCRIPTION
=================

A guest administrator who is granted access to the graphical console
of a Xen guest can access the qemu monitor.  The monitor can be used
to access host resources.

IMPACT
======

A malicious guest administrator can access host resources (perhaps
belonging to other guests or the underlying system) and may be able to
escalate their privilege to that of the host.

VULNERABLE SYSTEMS
==================

Installations where guest administrators do not have access to a
domain's graphical console, or containing only PV domains configured
without a graphical console, are not vulnerable.

Installations where all guest administrators are trustworthy are not
vulnerable, even if the guest operating systems themselves are
untrusted.

Systems using xend/xm: At least all versions since Xen 4.0 are
affected.  Systems are vulnerable even if "monitor=no" is specified in
the xm domain configuration file - this configuration option is not
properly honoured in the vulnerable versions.

Systems using libxl/xl: All versions are affected.  The "monitor="
option is not understood, and is therefore ignored, by xl.  However,
systems using the experimental device model version based on upstream
qemu are NOT vulnerable; that is, Xen 4.2 RC systems with
device_model_version="qemu_xen" specified in the xl domain config
file.

Systems using libvirt are vulnerable.  For "xen:" URIs, see xend/xm,
above.  For "libxl:" URIs, all versions are affected.

Systems based on the Xen Cloud Platform are NOT vulnerable.

CONFIRMING VULNERABILITY
========================

Connect to the guest's VNC (or SDL) graphical display and make sure
your focus is in that window.  Hold down CTRL and ALT and press 2.
You will see a black screen showing one of "serial0", "parallel0" or
"QEMU <version> monitor".  Repeat this exercise for other digits 3 to
6.  CTRL+ALT+1 is the domain's normal graphical console.  Not all
numbers will have screens attached, but note that you must release and
re-press CTRL and ALT each time.

If one of the accessible screens shows "QEMU <version> monitor" then
you are vulnerable.  Otherwise you are not.

MITIGATION
==========

With xl in Xen 4.1 and later, supplying the following config
option in the VM configuration file will disable the monitor:
   device_model_args=["-monitor","null"]

With xend the following config option will disable the monitor:
   monitor_path="null"
Note that with a vulnerable version of the software specifying
"monitor=0" will NOT disable the monitor.

We are not currently aware of the availability of mitigation for
systems using libvirt.

NOTE REGARDING EMBARGO
======================

This issue was publicly discussed online by its discoverer.
There is therefore no embargo.

RESOLUTION
==========

The attached patch against qemu-xen-traditional
(qemu-xen-4.*-testing.git) resolves this issue.

$ sha256sum xsa19-qemu-all.patch
19fc5ff9334e7e7ad429388850dc6e52e7062c21a677082e7a89c2f2c91365fa  xsa19-qemu-all.patch
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iQEcBAEBAgAGBQJQSc6yAAoJEIP+FMlX6CvZ3MMIAJ3BfY4EXmye0ucZKU2zsrNx
R9w3AXdZWywf9qWX9DvgnJ0r4v/1wukqYwqpShAYNRHnbc3M15/ipEyLZDS2L4I2
On2mcaQeFAx5xIesRAaggyr4mQLoafCZxQO1ADPEIoyX97BBCJB85AjY5ctuoRX7
vDIUCwcXENsSVoDu3jJxqwwvbLbR7CA//V6RmCCIV9JKqcAdnrCTbRnoC7auDBzq
rbEqf9yyW2Md9Dul6S6j5RUim0CT7dJ7LlEbjRoyiDleHrK1T5UlfxHaCGhGa/ud
YRkW34PogsB1/boOi6T03Eir7svNNfN46ZS8Y+Pf6Dkv765BabIKwhhl7idIDUM=
=ayT8
-----END PGP SIGNATURE-----

--=separator
Content-Type: application/octet-stream; name="xsa19-qemu-all.patch"
Content-Disposition: attachment; filename="xsa19-qemu-all.patch"
Content-Transfer-Encoding: base64

RnJvbTogSWFuIEphY2tzb24gPGlhbi5qYWNrc29uQGV1LmNpdHJpeC5jb20+
CgpEaXNhYmxlIHFlbXUgbW9uaXRvciBieSBkZWZhdWx0LiAgVGhlIHFlbXUg
bW9uaXRvciBpcyBhbiBvdmVybHkKcG93ZXJmdWwgZmVhdHVyZSB3aGljaCBt
dXN0IGJlIHByb3RlY3RlZCBmcm9tIHVudHJ1c3RlZCAoZ3Vlc3QpCmFkbWlu
aXN0cmF0b3JzLgoKTmVpdGhlciB4bCBub3IgeGVuZCBleHBlY3QgcWVtdSB0
byBwcm9kdWNlIHRoaXMgbW9uaXRvciB1bmxlc3MgaXQgaXMKZXhwbGljaXRs
eSByZXF1ZXN0ZWQuCgpUaGlzIGlzIGEgc2VjdXJpdHkgcHJvYmxlbSwgWFNB
LTE5LiAgUHJldmlvdXNseSBpdCB3YXMgQ1ZFLTIwMDctMDk5OAppbiBSZWQg
SGF0IGJ1dCB3ZSBoYXZlbid0IGRlYWx0IHdpdGggaXQgaW4gdXBzdHJlYW0u
ICBXZSBob3BlIHRvIGhhdmUKYSBuZXcgQ1ZFIGZvciBpdCBoZXJlIGJ1dCB3
ZSBkb24ndCBoYXZlIG9uZSB5ZXQuCgpTaWduZWQtb2ZmLWJ5OiBJYW4gSmFj
a3NvbiA8aWFuLmphY2tzb25AZXUuY2l0cml4LmNvbT4KCmRpZmYgLS1naXQg
YS92bC5jIGIvdmwuYwppbmRleCBkMzBjYjJjLi5kMjFjM2FhIDEwMDY0NAot
LS0gYS92bC5jCisrKyBiL3ZsLmMKQEAgLTQ5MjAsNyArNDkyMCw3IEBAIGlu
dCBtYWluKGludCBhcmdjLCBjaGFyICoqYXJndiwgY2hhciAqKmVudnApCiAg
ICAga2VybmVsX2NtZGxpbmUgPSAiIjsKICAgICBjeWxzID0gaGVhZHMgPSBz
ZWNzID0gMDsKICAgICB0cmFuc2xhdGlvbiA9IEJJT1NfQVRBX1RSQU5TTEFU
SU9OX0FVVE87Ci0gICAgbW9uaXRvcl9kZXZpY2UgPSAidmM6ODBDeDI0QyI7
CisgICAgbW9uaXRvcl9kZXZpY2UgPSAibnVsbCI7CiAKICAgICBzZXJpYWxf
ZGV2aWNlc1swXSA9ICJ2Yzo4MEN4MjRDIjsKICAgICBmb3IoaSA9IDE7IGkg
PCBNQVhfU0VSSUFMX1BPUlRTOyBpKyspCg==

--=separator
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--=separator--


From xen-devel-bounces@lists.xen.org Fri Sep 07 11:01:50 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Sep 2012 11:01:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9wJZ-00005T-GL; Fri, 07 Sep 2012 11:01:33 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ianc@xenbits.xen.org>) id 1T9w04-0007wb-0y
	for xen-devel@lists.xen.org; Fri, 07 Sep 2012 10:41:24 +0000
Received: from [85.158.143.99:27931] by server-2.bemta-4.messagelabs.com id
	BF/E0-21239-15FC9405; Fri, 07 Sep 2012 10:41:21 +0000
X-Env-Sender: ianc@xenbits.xen.org
X-Msg-Ref: server-7.tower-216.messagelabs.com!1347014470!25727106!1
X-Originating-IP: [50.57.168.107]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15372 invoked from network); 7 Sep 2012 10:41:12 -0000
Received: from mail.xen.org (HELO mail.xen.org) (50.57.168.107)
	by server-7.tower-216.messagelabs.com with AES256-SHA encrypted SMTP;
	7 Sep 2012 10:41:12 -0000
Received: from xenbits.xen.org ([50.57.170.242])
	by mail.xen.org with esmtp (Exim 4.72)
	(envelope-from <ianc@xenbits.xen.org>)
	id 1T9vzi-0003JO-5i; Fri, 07 Sep 2012 10:41:02 +0000
Received: from ianc by xenbits.xen.org with local (Exim 4.72)
	(envelope-from <ianc@xenbits.xen.org>)
	id 1T9vzh-0000k0-IX; Fri, 07 Sep 2012 10:41:01 +0000
Date: Fri, 07 Sep 2012 10:41:01 +0000
Message-Id: <E1T9vzh-0000k0-IX@xenbits.xen.org>
Content-Type: multipart/mixed; boundary="=separator"; charset="utf-8"
Content-Transfer-Encoding: binary
MIME-Version: 1.0
X-Mailer: MIME-tools 5.428 (Entity 5.428)
To: xen-announce@lists.xen.org, xen-devel@lists.xen.org,
	xen-users@lists.xen.org, oss-security@lists.openwall.com
From: Xen.org security team <security@xen.org>
X-Mailman-Approved-At: Fri, 07 Sep 2012 11:01:31 +0000
Cc: "Xen.org security team" <security@xen.org>
Subject: [Xen-devel] Xen Security Advisory 19 (CVE-2012-4411) - guest
 administrator can access qemu monitor console
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--=separator
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

                 Xen Security Advisory CVE-2012-4411 / XSA-19
			      version 2

         guest administrator can access qemu monitor console

UPDATES IN VERSION 2
====================

We have now been issued with a CVE number.

ISSUE DESCRIPTION
=================

A guest administrator who is granted access to the graphical console
of a Xen guest can access the qemu monitor.  The monitor can be used
to access host resources.

IMPACT
======

A malicious guest administrator can access host resources (perhaps
belonging to other guests or the underlying system) and may be able to
escalate their privilege to that of the host.

VULNERABLE SYSTEMS
==================

Installations where guest administrators do not have access to a
domain's graphical console, or containing only PV domains configured
without a graphical console, are not vulnerable.

Installations where all guest administrators are trustworthy are not
vulnerable, even if the guest operating systems themselves are
untrusted.

Systems using xend/xm: At least all versions since Xen 4.0 are
affected.  Systems are vulnerable even if "monitor=no" is specified in
the xm domain configuration file - this configuration option is not
properly honoured in the vulnerable versions.

Systems using libxl/xl: All versions are affected.  The "monitor="
option is not understood, and is therefore ignored, by xl.  However,
systems using the experimental device model version based on upstream
qemu are NOT vulnerable; that is, Xen 4.2 RC systems with
device_model_version="qemu_xen" specified in the xl domain config
file.

Systems using libvirt are vulnerable.  For "xen:" URIs, see xend/xm,
above.  For "libxl:" URIs, all versions are affected.

Systems based on the Xen Cloud Platform are NOT vulnerable.

CONFIRMING VULNERABILITY
========================

Connect to the guest's VNC (or SDL) graphical display and make sure
your focus is in that window.  Hold down CTRL and ALT and press 2.
You will see a black screen showing one of "serial0", "parallel0" or
"QEMU <version> monitor".  Repeat this exercise for other digits 3 to
6.  CTRL+ALT+1 is the domain's normal graphical console.  Not all
numbers will have screens attached, but note that you must release and
re-press CTRL and ALT each time.

If one of the accessible screens shows "QEMU <version> monitor" then
you are vulnerable.  Otherwise you are not.

MITIGATION
==========

With xl in Xen 4.1 and later, supplying the following config
option in the VM configuration file will disable the monitor:
   device_model_args=["-monitor","null"]

With xend the following config option will disable the monitor:
   monitor_path="null"
Note that with a vulnerable version of the software specifying
"monitor=0" will NOT disable the monitor.

We are not currently aware of the availability of mitigation for
systems using libvirt.

NOTE REGARDING EMBARGO
======================

This issue was publicly discussed online by its discoverer.
There is therefore no embargo.

RESOLUTION
==========

The attached patch against qemu-xen-traditional
(qemu-xen-4.*-testing.git) resolves this issue.

$ sha256sum xsa19-qemu-all.patch
19fc5ff9334e7e7ad429388850dc6e52e7062c21a677082e7a89c2f2c91365fa  xsa19-qemu-all.patch
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iQEcBAEBAgAGBQJQSc6yAAoJEIP+FMlX6CvZ3MMIAJ3BfY4EXmye0ucZKU2zsrNx
R9w3AXdZWywf9qWX9DvgnJ0r4v/1wukqYwqpShAYNRHnbc3M15/ipEyLZDS2L4I2
On2mcaQeFAx5xIesRAaggyr4mQLoafCZxQO1ADPEIoyX97BBCJB85AjY5ctuoRX7
vDIUCwcXENsSVoDu3jJxqwwvbLbR7CA//V6RmCCIV9JKqcAdnrCTbRnoC7auDBzq
rbEqf9yyW2Md9Dul6S6j5RUim0CT7dJ7LlEbjRoyiDleHrK1T5UlfxHaCGhGa/ud
YRkW34PogsB1/boOi6T03Eir7svNNfN46ZS8Y+Pf6Dkv765BabIKwhhl7idIDUM=
=ayT8
-----END PGP SIGNATURE-----

--=separator
Content-Type: application/octet-stream; name="xsa19-qemu-all.patch"
Content-Disposition: attachment; filename="xsa19-qemu-all.patch"
Content-Transfer-Encoding: base64

RnJvbTogSWFuIEphY2tzb24gPGlhbi5qYWNrc29uQGV1LmNpdHJpeC5jb20+
CgpEaXNhYmxlIHFlbXUgbW9uaXRvciBieSBkZWZhdWx0LiAgVGhlIHFlbXUg
bW9uaXRvciBpcyBhbiBvdmVybHkKcG93ZXJmdWwgZmVhdHVyZSB3aGljaCBt
dXN0IGJlIHByb3RlY3RlZCBmcm9tIHVudHJ1c3RlZCAoZ3Vlc3QpCmFkbWlu
aXN0cmF0b3JzLgoKTmVpdGhlciB4bCBub3IgeGVuZCBleHBlY3QgcWVtdSB0
byBwcm9kdWNlIHRoaXMgbW9uaXRvciB1bmxlc3MgaXQgaXMKZXhwbGljaXRs
eSByZXF1ZXN0ZWQuCgpUaGlzIGlzIGEgc2VjdXJpdHkgcHJvYmxlbSwgWFNB
LTE5LiAgUHJldmlvdXNseSBpdCB3YXMgQ1ZFLTIwMDctMDk5OAppbiBSZWQg
SGF0IGJ1dCB3ZSBoYXZlbid0IGRlYWx0IHdpdGggaXQgaW4gdXBzdHJlYW0u
ICBXZSBob3BlIHRvIGhhdmUKYSBuZXcgQ1ZFIGZvciBpdCBoZXJlIGJ1dCB3
ZSBkb24ndCBoYXZlIG9uZSB5ZXQuCgpTaWduZWQtb2ZmLWJ5OiBJYW4gSmFj
a3NvbiA8aWFuLmphY2tzb25AZXUuY2l0cml4LmNvbT4KCmRpZmYgLS1naXQg
YS92bC5jIGIvdmwuYwppbmRleCBkMzBjYjJjLi5kMjFjM2FhIDEwMDY0NAot
LS0gYS92bC5jCisrKyBiL3ZsLmMKQEAgLTQ5MjAsNyArNDkyMCw3IEBAIGlu
dCBtYWluKGludCBhcmdjLCBjaGFyICoqYXJndiwgY2hhciAqKmVudnApCiAg
ICAga2VybmVsX2NtZGxpbmUgPSAiIjsKICAgICBjeWxzID0gaGVhZHMgPSBz
ZWNzID0gMDsKICAgICB0cmFuc2xhdGlvbiA9IEJJT1NfQVRBX1RSQU5TTEFU
SU9OX0FVVE87Ci0gICAgbW9uaXRvcl9kZXZpY2UgPSAidmM6ODBDeDI0QyI7
CisgICAgbW9uaXRvcl9kZXZpY2UgPSAibnVsbCI7CiAKICAgICBzZXJpYWxf
ZGV2aWNlc1swXSA9ICJ2Yzo4MEN4MjRDIjsKICAgICBmb3IoaSA9IDE7IGkg
PCBNQVhfU0VSSUFMX1BPUlRTOyBpKyspCg==

--=separator
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--=separator--


From xen-devel-bounces@lists.xen.org Fri Sep 07 11:02:55 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Sep 2012 11:02:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9wKW-00008j-Tr; Fri, 07 Sep 2012 11:02:32 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <lars.kurth.xen@gmail.com>) id 1T9wKW-00008V-8V
	for xen-devel@lists.xen.org; Fri, 07 Sep 2012 11:02:32 +0000
X-Env-Sender: lars.kurth.xen@gmail.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1347015739!9217601!1
X-Originating-IP: [74.125.83.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10123 invoked from network); 7 Sep 2012 11:02:19 -0000
Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com)
	(74.125.83.45)
	by server-3.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Sep 2012 11:02:19 -0000
Received: by eeke53 with SMTP id e53so1229326eek.32
	for <xen-devel@lists.xen.org>; Fri, 07 Sep 2012 04:02:19 -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=1UNf+zfuUWhsK3zbJCJ08TKsFEZSodnHupuWdEcknhk=;
	b=AUOawD51ryqP+i9DC4A5Isa1QYq15wg0bu+2BvjCeRxVhlxvFoTG+ZJ0nzge/5t5Db
	QZaklHBACYgCiEEW5XAlm6stXcasE8mYwkXUGTHUnhYOGmgZkbyjJoE5iqYzBSZP1lRv
	7LddIm2XO1QTvzPQh03SHOfpzc4dCgQ+PVzUjRv4PSUm/H/DpGRI7SETnmoI/4Sve3qq
	Nj2oigbrUi5LZmutguseb0sgKCzbeEOEyiWu9rdu8UupRfevTZWxu23oylwsdKDYUmmH
	iuq4zcNxuN2D6tD7le4Ivj97by/7GUcUSi4dphtER6nC92GEbGmB1A71tV4VPddEZjv3
	t/Uw==
Received: by 10.14.225.200 with SMTP id z48mr7151665eep.39.1347015739459;
	Fri, 07 Sep 2012 04:02:19 -0700 (PDT)
Received: from [172.16.26.11] (b0fb5b35.bb.sky.com. [176.251.91.53])
	by mx.google.com with ESMTPS id v3sm13678351eep.10.2012.09.07.04.02.18
	(version=SSLv3 cipher=OTHER); Fri, 07 Sep 2012 04:02:18 -0700 (PDT)
Message-ID: <5049D438.70403@xen.org>
Date: Fri, 07 Sep 2012 12:02:16 +0100
From: Lars Kurth <lars.kurth@xen.org>
User-Agent: Mozilla/5.0 (Windows NT 6.1;
	rv:14.0) Gecko/20120713 Thunderbird/14.0
MIME-Version: 1.0
To: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: [Xen-devel] Notes from 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

See 
http://wiki.xen.org/wiki/Xen_Maintainer,_Committer_and_Developer_Meeting/XenSummit_NA_2012
Feel free to correct if I misrepresented anything
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 Sep 07 11:02:55 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Sep 2012 11:02:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9wKW-00008j-Tr; Fri, 07 Sep 2012 11:02:32 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <lars.kurth.xen@gmail.com>) id 1T9wKW-00008V-8V
	for xen-devel@lists.xen.org; Fri, 07 Sep 2012 11:02:32 +0000
X-Env-Sender: lars.kurth.xen@gmail.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1347015739!9217601!1
X-Originating-IP: [74.125.83.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10123 invoked from network); 7 Sep 2012 11:02:19 -0000
Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com)
	(74.125.83.45)
	by server-3.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Sep 2012 11:02:19 -0000
Received: by eeke53 with SMTP id e53so1229326eek.32
	for <xen-devel@lists.xen.org>; Fri, 07 Sep 2012 04:02:19 -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=1UNf+zfuUWhsK3zbJCJ08TKsFEZSodnHupuWdEcknhk=;
	b=AUOawD51ryqP+i9DC4A5Isa1QYq15wg0bu+2BvjCeRxVhlxvFoTG+ZJ0nzge/5t5Db
	QZaklHBACYgCiEEW5XAlm6stXcasE8mYwkXUGTHUnhYOGmgZkbyjJoE5iqYzBSZP1lRv
	7LddIm2XO1QTvzPQh03SHOfpzc4dCgQ+PVzUjRv4PSUm/H/DpGRI7SETnmoI/4Sve3qq
	Nj2oigbrUi5LZmutguseb0sgKCzbeEOEyiWu9rdu8UupRfevTZWxu23oylwsdKDYUmmH
	iuq4zcNxuN2D6tD7le4Ivj97by/7GUcUSi4dphtER6nC92GEbGmB1A71tV4VPddEZjv3
	t/Uw==
Received: by 10.14.225.200 with SMTP id z48mr7151665eep.39.1347015739459;
	Fri, 07 Sep 2012 04:02:19 -0700 (PDT)
Received: from [172.16.26.11] (b0fb5b35.bb.sky.com. [176.251.91.53])
	by mx.google.com with ESMTPS id v3sm13678351eep.10.2012.09.07.04.02.18
	(version=SSLv3 cipher=OTHER); Fri, 07 Sep 2012 04:02:18 -0700 (PDT)
Message-ID: <5049D438.70403@xen.org>
Date: Fri, 07 Sep 2012 12:02:16 +0100
From: Lars Kurth <lars.kurth@xen.org>
User-Agent: Mozilla/5.0 (Windows NT 6.1;
	rv:14.0) Gecko/20120713 Thunderbird/14.0
MIME-Version: 1.0
To: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: [Xen-devel] Notes from 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

See 
http://wiki.xen.org/wiki/Xen_Maintainer,_Committer_and_Developer_Meeting/XenSummit_NA_2012
Feel free to correct if I misrepresented anything
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 Sep 07 11:12:21 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Sep 2012 11:12: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 1T9wTm-0000jh-Ls; Fri, 07 Sep 2012 11:12:06 +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 1T9wTl-0000jF-83
	for xen-devel@lists.xensource.com; Fri, 07 Sep 2012 11:12:05 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1347016318!8941610!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTIyMTE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15900 invoked from network); 7 Sep 2012 11:11:59 -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;
	7 Sep 2012 11:11:59 -0000
X-IronPort-AV: E=Sophos;i="4.80,385,1344211200"; d="scan'208";a="14407118"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Sep 2012 11:11: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.279.1; Fri, 7 Sep 2012 12:11: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 1T9wTe-0000hy-5o;
	Fri, 07 Sep 2012 11:11:58 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1T9wTd-000769-TA;
	Fri, 07 Sep 2012 12:11:58 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-13660-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 7 Sep 2012 12:11:57 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13660: 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 13660 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13660/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore            fail   like 13659
 test-i386-i386-xl-qemuu-winxpsp3  9 guest-localmigrate         fail like 13659
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail like 13659
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail like 13659

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-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
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass

version targeted for testing:
 xen                  ec23c2a11f6f
baseline version:
 xen                  ec23c2a11f6f

jobs:
 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                                 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                                     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 Sep 07 11:12:21 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Sep 2012 11:12: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 1T9wTm-0000jh-Ls; Fri, 07 Sep 2012 11:12:06 +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 1T9wTl-0000jF-83
	for xen-devel@lists.xensource.com; Fri, 07 Sep 2012 11:12:05 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1347016318!8941610!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTIyMTE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15900 invoked from network); 7 Sep 2012 11:11:59 -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;
	7 Sep 2012 11:11:59 -0000
X-IronPort-AV: E=Sophos;i="4.80,385,1344211200"; d="scan'208";a="14407118"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Sep 2012 11:11: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.279.1; Fri, 7 Sep 2012 12:11: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 1T9wTe-0000hy-5o;
	Fri, 07 Sep 2012 11:11:58 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1T9wTd-000769-TA;
	Fri, 07 Sep 2012 12:11:58 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-13660-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 7 Sep 2012 12:11:57 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13660: 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 13660 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13660/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore            fail   like 13659
 test-i386-i386-xl-qemuu-winxpsp3  9 guest-localmigrate         fail like 13659
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail like 13659
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail like 13659

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-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
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass

version targeted for testing:
 xen                  ec23c2a11f6f
baseline version:
 xen                  ec23c2a11f6f

jobs:
 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                                 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                                     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 Sep 07 11:15:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Sep 2012 11:15:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9wWM-0000zd-Aq; Fri, 07 Sep 2012 11:14: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 1T9wWL-0000zV-Kg
	for xen-devel@lists.xen.org; Fri, 07 Sep 2012 11:14:45 +0000
Received: from [85.158.143.35:54980] by server-2.bemta-4.messagelabs.com id
	0E/6D-21239-427D9405; Fri, 07 Sep 2012 11:14:44 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1347016484!17220877!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM4ODU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29873 invoked from network); 7 Sep 2012 11:14:44 -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;
	7 Sep 2012 11:14:44 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 07 Sep 2012 12:17:23 +0100
Message-Id: <5049F37A0200007800099BDA@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 07 Sep 2012 12:15:38 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ben Guthro" <ben@guthro.net>
References: <CAOvdn6WwgBD-2yf1uu3m9-16=Tb5KUrybXf2KibtnxKbP7YtwA@mail.gmail.com>
	<CAOvdn6UBW-yTOMd3YSf5M9JiHLRivyaKL-qzcKG8epszqaKmGg@mail.gmail.com>
	<20120807163320.GC15053@phenom.dumpdata.com>
	<CAOvdn6XcRGKtJxGwJO8J+ZBJr89wfTLc1woW5rhtMM540H9h1w@mail.gmail.com>
	<CAOvdn6XUoSeGoo7X=AJ1kpDxZB9HZEv+TJ4v-=FHcyR4=CHK-w@mail.gmail.com>
	<502240F302000078000937A6@nat28.tlf.novell.com>
	<CAOvdn6WN3kxC8Bb9g6MpfLULu47EGSGCtajPc-SFeJ-8VSUQDQ@mail.gmail.com>
	<CAOvdn6Xk1inm1hU55i0phU2qvSWyJLNoyDdn43biBAY2OewPtw@mail.gmail.com>
	<5023F5400200007800093F4E@nat28.tlf.novell.com>
	<CAOvdn6U-f3C4U8xVPvDyRFkFFLkbfiCXg_n+9zgA9V5u+q5jfw@mail.gmail.com>
	<5023F8B80200007800093F8C@nat28.tlf.novell.com>
	<CAOvdn6XKHfete_+=Hkvt20G7_cJ-4i8+9j9YD30OxzQ16Ru-+g@mail.gmail.com>
	<5024CB720200007800094124@nat28.tlf.novell.com>
	<CAOvdn6VVJdhWVYa-gNVt3euE4AbGi1TijUCUd1wGzv0SCWEUYA@mail.gmail.com>
	<CAOvdn6USnG9Y4MNBhrDZmob0oJ8BgFfKTvFEhcKbXDxNmzfZ-Q@mail.gmail.com>
	<502B75BA0200007800094FD4@nat28.tlf.novell.com>
	<CAOvdn6Ww5oEj6Xg=XT4dWCYWUBuOdPqLz-CqNjz4HmCScE+==g@mail.gmail.com>
	<CAOvdn6Wsjds_dmZ0dwDTYmD-o-OqjBH5-b9mitAuUADE+A4_ag@mail.gmail.com>
	<502BB8FD02000078000951E0@nat28.tlf.novell.com>
	<CAOvdn6VD6bp13F-tvYdkBsj4hkhE7PTGZrapndtdHrDKeZqccg@mail.gmail.com>
	<502CCC0002000078000955C4@nat28.tlf.novell.com>
	<CAOvdn6VEuX7R2_wz74ZvCxMjC-=YUir9kP5sdxEVaKVspRUd_w@mail.gmail.com>
	<502CF0A8020000780009574E@nat28.tlf.novell.com>
	<CAOvdn6VsZvn_1TCWYeuyY5YuTcP8=miK2KwE4583nsj6Qjb_vg@mail.gmail.com>
	<504494FB0200007800098398@nat28.tlf.novell.com>
	<CAOvdn6UT13qvWbMyfZkWND03RoVKVSgb6wW4yqTUpuBYEX01Dg@mail.gmail.com>
	<5048958D02000078000993EB@nat28.tlf.novell.com>
	<CAOvdn6WrNK1Jn_Y_P7C3AwX6ApVcgzacLA_x-u=xBQtebnuPxA@mail.gmail.com>
	<CAOvdn6U_Z=KdEo56nqe7jN54BwiesRJqDOz_VzVNpkWGfFRd2A@mail.gmail.com>
	<5049CEAE0200007800099A33@nat28.tlf.novell.com>
	<CAOvdn6XmsEfs+aO7nqBHdA61HpT_n_8W95u0MMq5J21tZCFbzw@mail.gmail.com>
In-Reply-To: <CAOvdn6XmsEfs+aO7nqBHdA61HpT_n_8W95u0MMq5J21tZCFbzw@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>, john.baboval@citrix.com,
	Thomas Goetz <thomas.goetz@citrix.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen4.2 S3 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 07.09.12 at 12:37, Ben Guthro <ben@guthro.net> wrote:
> On Fri, Sep 7, 2012 at 4:38 AM, Jan Beulich <JBeulich@suse.com> wrote:
> 
>> >>> On 06.09.12 at 18:42, Ben Guthro <ben@guthro.net> wrote:
>> > Odd.
>> > The behavior seems to change, when not running with serial output.
>>
>> Odd indeed. Could you (unless you are already) try running the
>> serial console in polling mode (i.e. without IRQ), to see whether
>> the IRQs coming from it somehow keep the system alive at a
>> certain point?
>>
>>
> I tried to do this at the end of yesterday, since you had suggested it
> previously, in this thread.
> 
> I did so by adding a ",0" to my com1 line, per the documentation - However,
> I am running with a PCI serial card, and not an "on-board" one - so my
> parameter looks like:
> 
> com1=115200,8n1,pci,0
> 
> I am not totally convinced that it is actually running in polling mode, and
> started to investigate ns16550.c to verify it was. I plan on resuming this
> investigation this morning.
> If you have any pointers on what I should be looking for - I'd appreciate
> any suggestions.
> 

The only thing you need to make sure is that at the end of
ns16550_parse_port_config() uart->irq is zero. But for PCI
that should be the default right now in -unstable (but I
think I have a patch pending to alter this in certain cases).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 07 11:15:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Sep 2012 11:15:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9wWM-0000zd-Aq; Fri, 07 Sep 2012 11:14: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 1T9wWL-0000zV-Kg
	for xen-devel@lists.xen.org; Fri, 07 Sep 2012 11:14:45 +0000
Received: from [85.158.143.35:54980] by server-2.bemta-4.messagelabs.com id
	0E/6D-21239-427D9405; Fri, 07 Sep 2012 11:14:44 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1347016484!17220877!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM4ODU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29873 invoked from network); 7 Sep 2012 11:14:44 -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;
	7 Sep 2012 11:14:44 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 07 Sep 2012 12:17:23 +0100
Message-Id: <5049F37A0200007800099BDA@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 07 Sep 2012 12:15:38 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ben Guthro" <ben@guthro.net>
References: <CAOvdn6WwgBD-2yf1uu3m9-16=Tb5KUrybXf2KibtnxKbP7YtwA@mail.gmail.com>
	<CAOvdn6UBW-yTOMd3YSf5M9JiHLRivyaKL-qzcKG8epszqaKmGg@mail.gmail.com>
	<20120807163320.GC15053@phenom.dumpdata.com>
	<CAOvdn6XcRGKtJxGwJO8J+ZBJr89wfTLc1woW5rhtMM540H9h1w@mail.gmail.com>
	<CAOvdn6XUoSeGoo7X=AJ1kpDxZB9HZEv+TJ4v-=FHcyR4=CHK-w@mail.gmail.com>
	<502240F302000078000937A6@nat28.tlf.novell.com>
	<CAOvdn6WN3kxC8Bb9g6MpfLULu47EGSGCtajPc-SFeJ-8VSUQDQ@mail.gmail.com>
	<CAOvdn6Xk1inm1hU55i0phU2qvSWyJLNoyDdn43biBAY2OewPtw@mail.gmail.com>
	<5023F5400200007800093F4E@nat28.tlf.novell.com>
	<CAOvdn6U-f3C4U8xVPvDyRFkFFLkbfiCXg_n+9zgA9V5u+q5jfw@mail.gmail.com>
	<5023F8B80200007800093F8C@nat28.tlf.novell.com>
	<CAOvdn6XKHfete_+=Hkvt20G7_cJ-4i8+9j9YD30OxzQ16Ru-+g@mail.gmail.com>
	<5024CB720200007800094124@nat28.tlf.novell.com>
	<CAOvdn6VVJdhWVYa-gNVt3euE4AbGi1TijUCUd1wGzv0SCWEUYA@mail.gmail.com>
	<CAOvdn6USnG9Y4MNBhrDZmob0oJ8BgFfKTvFEhcKbXDxNmzfZ-Q@mail.gmail.com>
	<502B75BA0200007800094FD4@nat28.tlf.novell.com>
	<CAOvdn6Ww5oEj6Xg=XT4dWCYWUBuOdPqLz-CqNjz4HmCScE+==g@mail.gmail.com>
	<CAOvdn6Wsjds_dmZ0dwDTYmD-o-OqjBH5-b9mitAuUADE+A4_ag@mail.gmail.com>
	<502BB8FD02000078000951E0@nat28.tlf.novell.com>
	<CAOvdn6VD6bp13F-tvYdkBsj4hkhE7PTGZrapndtdHrDKeZqccg@mail.gmail.com>
	<502CCC0002000078000955C4@nat28.tlf.novell.com>
	<CAOvdn6VEuX7R2_wz74ZvCxMjC-=YUir9kP5sdxEVaKVspRUd_w@mail.gmail.com>
	<502CF0A8020000780009574E@nat28.tlf.novell.com>
	<CAOvdn6VsZvn_1TCWYeuyY5YuTcP8=miK2KwE4583nsj6Qjb_vg@mail.gmail.com>
	<504494FB0200007800098398@nat28.tlf.novell.com>
	<CAOvdn6UT13qvWbMyfZkWND03RoVKVSgb6wW4yqTUpuBYEX01Dg@mail.gmail.com>
	<5048958D02000078000993EB@nat28.tlf.novell.com>
	<CAOvdn6WrNK1Jn_Y_P7C3AwX6ApVcgzacLA_x-u=xBQtebnuPxA@mail.gmail.com>
	<CAOvdn6U_Z=KdEo56nqe7jN54BwiesRJqDOz_VzVNpkWGfFRd2A@mail.gmail.com>
	<5049CEAE0200007800099A33@nat28.tlf.novell.com>
	<CAOvdn6XmsEfs+aO7nqBHdA61HpT_n_8W95u0MMq5J21tZCFbzw@mail.gmail.com>
In-Reply-To: <CAOvdn6XmsEfs+aO7nqBHdA61HpT_n_8W95u0MMq5J21tZCFbzw@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>, john.baboval@citrix.com,
	Thomas Goetz <thomas.goetz@citrix.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen4.2 S3 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 07.09.12 at 12:37, Ben Guthro <ben@guthro.net> wrote:
> On Fri, Sep 7, 2012 at 4:38 AM, Jan Beulich <JBeulich@suse.com> wrote:
> 
>> >>> On 06.09.12 at 18:42, Ben Guthro <ben@guthro.net> wrote:
>> > Odd.
>> > The behavior seems to change, when not running with serial output.
>>
>> Odd indeed. Could you (unless you are already) try running the
>> serial console in polling mode (i.e. without IRQ), to see whether
>> the IRQs coming from it somehow keep the system alive at a
>> certain point?
>>
>>
> I tried to do this at the end of yesterday, since you had suggested it
> previously, in this thread.
> 
> I did so by adding a ",0" to my com1 line, per the documentation - However,
> I am running with a PCI serial card, and not an "on-board" one - so my
> parameter looks like:
> 
> com1=115200,8n1,pci,0
> 
> I am not totally convinced that it is actually running in polling mode, and
> started to investigate ns16550.c to verify it was. I plan on resuming this
> investigation this morning.
> If you have any pointers on what I should be looking for - I'd appreciate
> any suggestions.
> 

The only thing you need to make sure is that at the end of
ns16550_parse_port_config() uart->irq is zero. But for PCI
that should be the default right now in -unstable (but I
think I have a patch pending to alter this in certain cases).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 07 11:16:36 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Sep 2012 11:16:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9wXq-0001AN-RR; Fri, 07 Sep 2012 11:16:18 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1T9wXp-0001AC-2t
	for xen-devel@lists.xensource.com; Fri, 07 Sep 2012 11:16:17 +0000
Received: from [85.158.139.83:16380] by server-9.bemta-5.messagelabs.com id
	C3/0A-20529-087D9405; Fri, 07 Sep 2012 11:16:16 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1347016575!29074752!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM4ODU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4417 invoked from network); 7 Sep 2012 11:16:15 -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;
	7 Sep 2012 11:16:15 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 07 Sep 2012 12:18:54 +0100
Message-Id: <5049F3D50200007800099BEA@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 07 Sep 2012 12:17:09 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Sander Eikelenboom" <linux@eikelenboom.it>
References: <504764E2.4000809@amd.com>
	<326589347.20120906005936@eikelenboom.it> <5048A603.3070207@amd.com>
	<483486315.20120906155001@eikelenboom.it> <5048BB29.4040900@amd.com>
	<488803362.20120907093241@eikelenboom.it>
	<5049E0400200007800099B05@nat28.tlf.novell.com>
	<1188497031.20120907120041@eikelenboom.it>
	<5049E3470200007800099B3F@nat28.tlf.novell.com>
	<148712299.20120907121511@eikelenboom.it>
In-Reply-To: <148712299.20120907121511@eikelenboom.it>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Wei Wang <wei.wang2@amd.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] amd iommu: Dump flags of IO page faults
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.09.12 at 12:15, Sander Eikelenboom <linux@eikelenboom.it> wrote:
>> No, it just can't report faults (they would need to be polled for).
>> Also, saying "in the 4.1 case" is wrong here - this really depends
>> on whether you have an affected Dom0 kernel. Things work fine
>> if the Dom0 kernel doesn't trample over Xen's setup.
> 
> Except for the IO PAGE FAULT in xl dmesg, which is reported before the 
> kernel even gets loaded with xen-4.2.
> I don't see that one on 4.1 either, so that wouldn't add up to it being a 
> dom0 kernel problem only ...

Oh, yes, that certainly is a hypervisor only bug (if a bug
under our control at all - as said before, a babbling device
- eg left active by BIOS - is likely beyond our control).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 07 11:16:36 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Sep 2012 11:16:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9wXq-0001AN-RR; Fri, 07 Sep 2012 11:16:18 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1T9wXp-0001AC-2t
	for xen-devel@lists.xensource.com; Fri, 07 Sep 2012 11:16:17 +0000
Received: from [85.158.139.83:16380] by server-9.bemta-5.messagelabs.com id
	C3/0A-20529-087D9405; Fri, 07 Sep 2012 11:16:16 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1347016575!29074752!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM4ODU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4417 invoked from network); 7 Sep 2012 11:16:15 -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;
	7 Sep 2012 11:16:15 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 07 Sep 2012 12:18:54 +0100
Message-Id: <5049F3D50200007800099BEA@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 07 Sep 2012 12:17:09 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Sander Eikelenboom" <linux@eikelenboom.it>
References: <504764E2.4000809@amd.com>
	<326589347.20120906005936@eikelenboom.it> <5048A603.3070207@amd.com>
	<483486315.20120906155001@eikelenboom.it> <5048BB29.4040900@amd.com>
	<488803362.20120907093241@eikelenboom.it>
	<5049E0400200007800099B05@nat28.tlf.novell.com>
	<1188497031.20120907120041@eikelenboom.it>
	<5049E3470200007800099B3F@nat28.tlf.novell.com>
	<148712299.20120907121511@eikelenboom.it>
In-Reply-To: <148712299.20120907121511@eikelenboom.it>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Wei Wang <wei.wang2@amd.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] amd iommu: Dump flags of IO page faults
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.09.12 at 12:15, Sander Eikelenboom <linux@eikelenboom.it> wrote:
>> No, it just can't report faults (they would need to be polled for).
>> Also, saying "in the 4.1 case" is wrong here - this really depends
>> on whether you have an affected Dom0 kernel. Things work fine
>> if the Dom0 kernel doesn't trample over Xen's setup.
> 
> Except for the IO PAGE FAULT in xl dmesg, which is reported before the 
> kernel even gets loaded with xen-4.2.
> I don't see that one on 4.1 either, so that wouldn't add up to it being a 
> dom0 kernel problem only ...

Oh, yes, that certainly is a hypervisor only bug (if a bug
under our control at all - as said before, a babbling device
- eg left active by BIOS - is likely beyond our control).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 07 11:29:11 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Sep 2012 11: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 1T9wk2-0001bL-Fc; Fri, 07 Sep 2012 11:28:54 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1T9wk1-0001bG-Qs
	for xen-devel@lists.xensource.com; Fri, 07 Sep 2012 11:28:54 +0000
Received: from [85.158.138.51:28349] by server-5.bemta-3.messagelabs.com id
	A8/90-13133-47AD9405; Fri, 07 Sep 2012 11:28:52 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1347017332!22912917!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM4ODU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3964 invoked from network); 7 Sep 2012 11:28:52 -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;
	7 Sep 2012 11:28:52 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 07 Sep 2012 12:31:31 +0100
Message-Id: <5049F6CB0200007800099C08@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 07 Sep 2012 12:29:47 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Sander Eikelenboom" <linux@eikelenboom.it>
References: <504764E2.4000809@amd.com>
	<326589347.20120906005936@eikelenboom.it> <5048A603.3070207@amd.com>
	<483486315.20120906155001@eikelenboom.it> <5048BB29.4040900@amd.com>
	<488803362.20120907093241@eikelenboom.it> <5049B650.4080101@amd.com>
	<1144069450.20120907120133@eikelenboom.it>
In-Reply-To: <1144069450.20120907120133@eikelenboom.it>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Wei Wang <wei.wang2@amd.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] amd iommu: Dump flags of IO page faults
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.09.12 at 12:01, Sander Eikelenboom <linux@eikelenboom.it> wrote:
>>> 4.1:    Capabilities: [54] MSI: Enable- Count=1/1 Maskable- 64bit+
> 
>> Eh... That is interesting. So which dom0 are you using?  There is a c/s 
>> in 4.2 to prevent recent dom0 to disable iommu interrupt (changeset 
>> 25492:61844569a432) Otherwise, iommu cannot send any events including IO 
>> PAGE faults. You could try to revert dom0 to an old version like 2.6 
>> pv_ops to see if you really have no io page faults on 4.1
> 
> Ok i will give that a try, only dom0 will have to be a 2.6 pv_ops i assume ?

You could also drop the patch below into a kernel that has
the problematic change. Will require

#define PCI_CLASS_SYSTEM_IOMMU		0x0806

to be added at a suitable spot in include/linux/pci_ids.h.

Jan

--- head.orig/drivers/pci/msi.c
+++ head/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);



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 07 11:29:11 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Sep 2012 11: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 1T9wk2-0001bL-Fc; Fri, 07 Sep 2012 11:28:54 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1T9wk1-0001bG-Qs
	for xen-devel@lists.xensource.com; Fri, 07 Sep 2012 11:28:54 +0000
Received: from [85.158.138.51:28349] by server-5.bemta-3.messagelabs.com id
	A8/90-13133-47AD9405; Fri, 07 Sep 2012 11:28:52 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1347017332!22912917!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM4ODU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3964 invoked from network); 7 Sep 2012 11:28:52 -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;
	7 Sep 2012 11:28:52 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 07 Sep 2012 12:31:31 +0100
Message-Id: <5049F6CB0200007800099C08@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 07 Sep 2012 12:29:47 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Sander Eikelenboom" <linux@eikelenboom.it>
References: <504764E2.4000809@amd.com>
	<326589347.20120906005936@eikelenboom.it> <5048A603.3070207@amd.com>
	<483486315.20120906155001@eikelenboom.it> <5048BB29.4040900@amd.com>
	<488803362.20120907093241@eikelenboom.it> <5049B650.4080101@amd.com>
	<1144069450.20120907120133@eikelenboom.it>
In-Reply-To: <1144069450.20120907120133@eikelenboom.it>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Wei Wang <wei.wang2@amd.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] amd iommu: Dump flags of IO page faults
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.09.12 at 12:01, Sander Eikelenboom <linux@eikelenboom.it> wrote:
>>> 4.1:    Capabilities: [54] MSI: Enable- Count=1/1 Maskable- 64bit+
> 
>> Eh... That is interesting. So which dom0 are you using?  There is a c/s 
>> in 4.2 to prevent recent dom0 to disable iommu interrupt (changeset 
>> 25492:61844569a432) Otherwise, iommu cannot send any events including IO 
>> PAGE faults. You could try to revert dom0 to an old version like 2.6 
>> pv_ops to see if you really have no io page faults on 4.1
> 
> Ok i will give that a try, only dom0 will have to be a 2.6 pv_ops i assume ?

You could also drop the patch below into a kernel that has
the problematic change. Will require

#define PCI_CLASS_SYSTEM_IOMMU		0x0806

to be added at a suitable spot in include/linux/pci_ids.h.

Jan

--- head.orig/drivers/pci/msi.c
+++ head/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);



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 07 11:39:23 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Sep 2012 11:39: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 1T9wtu-0001vx-KG; Fri, 07 Sep 2012 11:39:06 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1T9wtt-0001vs-FJ
	for xen-devel@lists.xen.org; Fri, 07 Sep 2012 11:39:05 +0000
Received: from [85.158.143.35:45557] by server-3.bemta-4.messagelabs.com id
	43/3D-08232-8DCD9405; Fri, 07 Sep 2012 11:39:04 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1347017944!17156903!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM4ODU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10777 invoked from network); 7 Sep 2012 11:39:04 -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;
	7 Sep 2012 11:39:04 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 07 Sep 2012 12:41:43 +0100
Message-Id: <5049F92E0200007800099C17@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 07 Sep 2012 12:39:58 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: <zhenzhong.duan@oracle.com>
References: <504764510200007800098DE5@nat28.tlf.novell.com>
	<5049D16D.8060602@oracle.com>
In-Reply-To: <5049D16D.8060602@oracle.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: dan.magenheimer@oracle.com, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 10/11] tmem: fixup 2010 cleanup patch that
 breaks tmem save/restore
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.09.12 at 12:50, "zhenzhong.duan" <zhenzhong.duan@oracle.com> wrote:
> With this patch applied, 'xm save' worked, restore failed. See below:
> [root@sustaining13 OVM_OL5U7_X86_64_PVM_10GB]# xm list
> Name ID Mem VCPUs State Time(s)
> Domain-0 0 537 2 r----- 255.3
> OVM_OL5U7_X86_64_PVM_10GB 1 1024 2 -b---- 76.2
> [root@sustaining13 OVM_OL5U7_X86_64_PVM_10GB]# xm save 1 delete
> [root@sustaining13 OVM_OL5U7_X86_64_PVM_10GB]#
> [root@sustaining13 OVM_OL5U7_X86_64_PVM_10GB]# xm restore delete
> Error: /usr/lib64/xen/bin/xc_restore 4 2 1 2 0 0 0 0 failed
> Usage: xm restore <CheckpointFile> [-p]
> 
> Restore a domain from a saved state.
> -p, --paused Do not unpause domain after restoring it
> [root@sustaining13 OVM_OL5U7_X86_64_PVM_10GB]# xm dmesg:
> (XEN) tmem.c:2037:d0 tmem: all pools frozen for all domains
> (XEN) tmem.c:2037:d0 tmem: all pools thawed for all domains
> (XEN) tmem.c:2037:d0 tmem: all pools frozen for all domains
> (XEN) tmem.c:2037:d0 tmem: all pools thawed for all domains
> (XEN) tmem.c:1220:d1 tmem: initializing tmem capability for 
> domid=1...<G><2>tmem.c:1256:d1 ok
> (XEN) tmem.c:1912:d1 tmem: allocating ephemeral-private tmem pool for 
> domid=1...<G><2>tmem.c:2014:d1 pool_id=0
> (XEN) tmem.c:1912:d1 tmem: allocating ephemeral-private tmem pool for 
> domid=1...<G><2>tmem.c:2014:d1 pool_id=1
> (XEN) tmem.c:1912:d1 tmem: allocating persistent-private tmem pool for 
> domid=1...<G><2>tmem.c:2014:d1 pool_id=2
> (XEN) tmem.c:2855:d0 tmem: flushing tmem pools for domid=1
> (XEN) tmem.c:1197:d0 destroying ephemeral-private tmem pool 
> <G><2>tmem.c:1198:d0 domid=1 pool_id=0
> (XEN) tmem.c:1197:d0 destroying ephemeral-private tmem pool 
> <G><2>tmem.c:1198:d0 domid=1 pool_id=1
> (XEN) tmem.c:1197:d0 destroying persistent-private tmem pool 
> <G><2>tmem.c:1198:d0 domid=1 pool_id=2
> (XEN) tmem.c:2037:d0 tmem: all pools frozen for all domains
> (XEN) tmem.c:2037:d0 tmem: all pools thawed for all domains
> (XEN) tmem.c:2037:d0 tmem: all pools frozen for all domains
> (XEN) tmem.c:2037:d0 tmem: all pools thawed for all domains
> (XEN) tmem.c:1220:d0 tmem: initializing tmem capability for 
> domid=2...<G><2>tmem.c:1256:d0 ok
> (XEN) tmem.c:2268:d0 tmem: weight set to 0 for domid=2
> (XEN) tmem.c:2274:d0 tmem: cap set to 0 for domid=2
> (XEN) tmem.c:1912:d0 tmem: allocating ephemeral-private tmem pool for 
> domid=2...<G><2>tmem.c:1915:d0 failed... unsupported spec version

Looks like Dan's patches to bump the tmem ABI from 0 to 1
(22136:b7f0ea22880d, 22137:fd2e5008c2e0 ) failed to fully
update tools/libxc/xc_tmem.c (xc_tmem_restore_new_pool()
in particular for the problem above).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 07 11:39:23 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Sep 2012 11:39: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 1T9wtu-0001vx-KG; Fri, 07 Sep 2012 11:39:06 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1T9wtt-0001vs-FJ
	for xen-devel@lists.xen.org; Fri, 07 Sep 2012 11:39:05 +0000
Received: from [85.158.143.35:45557] by server-3.bemta-4.messagelabs.com id
	43/3D-08232-8DCD9405; Fri, 07 Sep 2012 11:39:04 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1347017944!17156903!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM4ODU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10777 invoked from network); 7 Sep 2012 11:39:04 -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;
	7 Sep 2012 11:39:04 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 07 Sep 2012 12:41:43 +0100
Message-Id: <5049F92E0200007800099C17@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 07 Sep 2012 12:39:58 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: <zhenzhong.duan@oracle.com>
References: <504764510200007800098DE5@nat28.tlf.novell.com>
	<5049D16D.8060602@oracle.com>
In-Reply-To: <5049D16D.8060602@oracle.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: dan.magenheimer@oracle.com, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 10/11] tmem: fixup 2010 cleanup patch that
 breaks tmem save/restore
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.09.12 at 12:50, "zhenzhong.duan" <zhenzhong.duan@oracle.com> wrote:
> With this patch applied, 'xm save' worked, restore failed. See below:
> [root@sustaining13 OVM_OL5U7_X86_64_PVM_10GB]# xm list
> Name ID Mem VCPUs State Time(s)
> Domain-0 0 537 2 r----- 255.3
> OVM_OL5U7_X86_64_PVM_10GB 1 1024 2 -b---- 76.2
> [root@sustaining13 OVM_OL5U7_X86_64_PVM_10GB]# xm save 1 delete
> [root@sustaining13 OVM_OL5U7_X86_64_PVM_10GB]#
> [root@sustaining13 OVM_OL5U7_X86_64_PVM_10GB]# xm restore delete
> Error: /usr/lib64/xen/bin/xc_restore 4 2 1 2 0 0 0 0 failed
> Usage: xm restore <CheckpointFile> [-p]
> 
> Restore a domain from a saved state.
> -p, --paused Do not unpause domain after restoring it
> [root@sustaining13 OVM_OL5U7_X86_64_PVM_10GB]# xm dmesg:
> (XEN) tmem.c:2037:d0 tmem: all pools frozen for all domains
> (XEN) tmem.c:2037:d0 tmem: all pools thawed for all domains
> (XEN) tmem.c:2037:d0 tmem: all pools frozen for all domains
> (XEN) tmem.c:2037:d0 tmem: all pools thawed for all domains
> (XEN) tmem.c:1220:d1 tmem: initializing tmem capability for 
> domid=1...<G><2>tmem.c:1256:d1 ok
> (XEN) tmem.c:1912:d1 tmem: allocating ephemeral-private tmem pool for 
> domid=1...<G><2>tmem.c:2014:d1 pool_id=0
> (XEN) tmem.c:1912:d1 tmem: allocating ephemeral-private tmem pool for 
> domid=1...<G><2>tmem.c:2014:d1 pool_id=1
> (XEN) tmem.c:1912:d1 tmem: allocating persistent-private tmem pool for 
> domid=1...<G><2>tmem.c:2014:d1 pool_id=2
> (XEN) tmem.c:2855:d0 tmem: flushing tmem pools for domid=1
> (XEN) tmem.c:1197:d0 destroying ephemeral-private tmem pool 
> <G><2>tmem.c:1198:d0 domid=1 pool_id=0
> (XEN) tmem.c:1197:d0 destroying ephemeral-private tmem pool 
> <G><2>tmem.c:1198:d0 domid=1 pool_id=1
> (XEN) tmem.c:1197:d0 destroying persistent-private tmem pool 
> <G><2>tmem.c:1198:d0 domid=1 pool_id=2
> (XEN) tmem.c:2037:d0 tmem: all pools frozen for all domains
> (XEN) tmem.c:2037:d0 tmem: all pools thawed for all domains
> (XEN) tmem.c:2037:d0 tmem: all pools frozen for all domains
> (XEN) tmem.c:2037:d0 tmem: all pools thawed for all domains
> (XEN) tmem.c:1220:d0 tmem: initializing tmem capability for 
> domid=2...<G><2>tmem.c:1256:d0 ok
> (XEN) tmem.c:2268:d0 tmem: weight set to 0 for domid=2
> (XEN) tmem.c:2274:d0 tmem: cap set to 0 for domid=2
> (XEN) tmem.c:1912:d0 tmem: allocating ephemeral-private tmem pool for 
> domid=2...<G><2>tmem.c:1915:d0 failed... unsupported spec version

Looks like Dan's patches to bump the tmem ABI from 0 to 1
(22136:b7f0ea22880d, 22137:fd2e5008c2e0 ) failed to fully
update tools/libxc/xc_tmem.c (xc_tmem_restore_new_pool()
in particular for the problem above).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 07 11:41:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Sep 2012 11:41:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9wvd-000211-48; Fri, 07 Sep 2012 11:40:53 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <stefan.bader@canonical.com>) id 1T9wvb-00020t-7l
	for xen-devel@lists.xen.org; Fri, 07 Sep 2012 11:40:51 +0000
Received: from [85.158.143.35:62027] by server-2.bemta-4.messagelabs.com id
	C2/1B-21239-24DD9405; Fri, 07 Sep 2012 11:40:50 +0000
X-Env-Sender: stefan.bader@canonical.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1347018047!14659121!1
X-Originating-IP: [91.189.89.112]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9155 invoked from network); 7 Sep 2012 11:40:47 -0000
Received: from youngberry.canonical.com (HELO youngberry.canonical.com)
	(91.189.89.112) by server-16.tower-21.messagelabs.com with SMTP;
	7 Sep 2012 11:40:47 -0000
Received: from p5b2e2384.dip.t-dialin.net ([91.46.35.132] helo=canonical.com)
	by youngberry.canonical.com with esmtpsa
	(TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.71)
	(envelope-from <stefan.bader@canonical.com>)
	id 1T9wvU-0004g3-J1; Fri, 07 Sep 2012 11:40:44 +0000
From: Stefan Bader <stefan.bader@canonical.com>
To: xen-devel@lists.xen.org,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Date: Fri,  7 Sep 2012 13:40:43 +0200
Message-Id: <1347018043-21252-1-git-send-email-stefan.bader@canonical.com>
X-Mailer: git-send-email 1.7.9.5
Cc: Matt Wilson <msw@amazon.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: [Xen-devel] [PATCH/RFC] Fix xsave bug on older Xen hypervisors
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 writing unsupported flags into CR4 (for some time the
xen_write_cr4 function would refuse to do anything at all)
older Xen hypervisors (and patch can potentially be improved
by finding out what older means in version numbers) would
crash the guest.

Since Amazon EC2 would at least in the past be affected by that,
Fedora and Ubuntu were carrying a hack that would filter out
X86_CR4_OSXSAVE before writing to CR4. This would affect any
PV guest, even those running on a newer HV.

And this recently caused trouble because some user-space was
only partially checking (or maybe only looking at the cpuid
bits) and then trying to use xsave even though the OS support
was not set.

So I came up with a patch that would
- limit the work-around to certain Xen versions
- prevent the write to CR4 by unsetting xsave and osxsave in
  the cpuid bits

Doing things that way may actually allow this to be acceptable
upstream, so I am sending it around, now.
It probably could be improved when knowing the exact version
to test for but otherwise should allow to work around the guest
crash while not preventing xsave on Xen 4.x and newer hosts.

-Stefan


>From dff8885934d4e1274a69c4cedd28a4d18a1255e8 Mon Sep 17 00:00:00 2001
From: Stefan Bader <stefan.bader@canonical.com>
Date: Fri, 15 Jun 2012 11:54:59 +0200
Subject: [PATCH] xen: Mask xsave cpu capability on Xen host < 4

Older Xen hypervisors (like RHEL5 versions found to be used
on Amazon's EC2) did have a bug which would crash the domain
when trying to write unsupported CR4 values.
Newer versions of the Xen hypervisor do handle this correctly.
But when a 2.6.28 or later kernel (those seem to have
xen_write_cr4 and xsave support) is booted as a PV guest on EC2,
it potentially crashes when hitting the right CPU and the wrong
hypervisor.

We were using a patch (taken from Fedora) that did always filter
the OSXSAVE off the values written to CR4 when running as Xen PV
guest. While not completely wrong this creates an inconsistency
between the cpuid bits a guest sees and the CR4 settings.
But it prevents any use of xsave even on recent Xen hypervisors.
And this did recently cause problems because user-space was not
testing all bits when deciding to use certain features.

This patch will actually mask off the cpuid bits for XSAVE and
OSXSAVE, so generic code will not even try to set CR4. It is
limited to PV guests and (since we do not actually know the
exact version) Xen hypervisors before version 4.

Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
---
 arch/x86/xen/enlighten.c |   17 ++++++++++++++++-
 1 file changed, 16 insertions(+), 1 deletion(-)

diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
index 9642d4a..4241055 100644
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -210,6 +210,18 @@ void xen_vcpu_restore(void)
 	}
 }
 
+/*
+ * Older (with no clear statement about what old means) Xen hypervisors
+ * will crash a PV guest that tries to store OSXSAVE into CR4.
+ * To prevent this, we force the feature bits related to this off in the
+ * xen cpuid call. This inline function serves as a centralized test
+ * on whether the quirk should be done.
+ */
+static inline needs_xsave_quirk(unsigned version)
+{
+	return (xen_pv_domain() && ((version >> 16) < 4)) ? 1 : 0;
+}
+
 static void __init xen_banner(void)
 {
 	unsigned version = HYPERVISOR_xen_version(XENVER_version, NULL);
@@ -221,6 +233,8 @@ static void __init xen_banner(void)
 	printk(KERN_INFO "Xen version: %d.%d%s%s\n",
 	       version >> 16, version & 0xffff, extra.extraversion,
 	       xen_feature(XENFEAT_mmu_pt_update_preserve_ad) ? " (preserve-AD)" : "");
+	if (needs_xsave_quirk(version))
+		printk(KERN_INFO "Forcing xsave off due to Xen version.\n");
 }
 
 #define CPUID_THERM_POWER_LEAF 6
@@ -351,6 +365,7 @@ static bool __init xen_check_mwait(void)
 }
 static void __init xen_init_cpuid_mask(void)
 {
+	unsigned version = HYPERVISOR_xen_version(XENVER_version, NULL);
 	unsigned int ax, bx, cx, dx;
 	unsigned int xsave_mask;
 
@@ -371,7 +386,7 @@ static void __init xen_init_cpuid_mask(void)
 		(1 << (X86_FEATURE_OSXSAVE % 32));
 
 	/* Xen will set CR4.OSXSAVE if supported and not disabled by force */
-	if ((cx & xsave_mask) != xsave_mask)
+	if (((cx & xsave_mask) != xsave_mask) || needs_xsave_quirk(version))
 		cpuid_leaf1_ecx_mask &= ~xsave_mask; /* disable XSAVE & OSXSAVE */
 	if (xen_check_mwait())
 		cpuid_leaf1_ecx_set_mask = (1 << (X86_FEATURE_MWAIT % 32));
-- 
1.7.9.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 07 11:41:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Sep 2012 11:41:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9wvd-000211-48; Fri, 07 Sep 2012 11:40:53 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <stefan.bader@canonical.com>) id 1T9wvb-00020t-7l
	for xen-devel@lists.xen.org; Fri, 07 Sep 2012 11:40:51 +0000
Received: from [85.158.143.35:62027] by server-2.bemta-4.messagelabs.com id
	C2/1B-21239-24DD9405; Fri, 07 Sep 2012 11:40:50 +0000
X-Env-Sender: stefan.bader@canonical.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1347018047!14659121!1
X-Originating-IP: [91.189.89.112]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9155 invoked from network); 7 Sep 2012 11:40:47 -0000
Received: from youngberry.canonical.com (HELO youngberry.canonical.com)
	(91.189.89.112) by server-16.tower-21.messagelabs.com with SMTP;
	7 Sep 2012 11:40:47 -0000
Received: from p5b2e2384.dip.t-dialin.net ([91.46.35.132] helo=canonical.com)
	by youngberry.canonical.com with esmtpsa
	(TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.71)
	(envelope-from <stefan.bader@canonical.com>)
	id 1T9wvU-0004g3-J1; Fri, 07 Sep 2012 11:40:44 +0000
From: Stefan Bader <stefan.bader@canonical.com>
To: xen-devel@lists.xen.org,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Date: Fri,  7 Sep 2012 13:40:43 +0200
Message-Id: <1347018043-21252-1-git-send-email-stefan.bader@canonical.com>
X-Mailer: git-send-email 1.7.9.5
Cc: Matt Wilson <msw@amazon.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: [Xen-devel] [PATCH/RFC] Fix xsave bug on older Xen hypervisors
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 writing unsupported flags into CR4 (for some time the
xen_write_cr4 function would refuse to do anything at all)
older Xen hypervisors (and patch can potentially be improved
by finding out what older means in version numbers) would
crash the guest.

Since Amazon EC2 would at least in the past be affected by that,
Fedora and Ubuntu were carrying a hack that would filter out
X86_CR4_OSXSAVE before writing to CR4. This would affect any
PV guest, even those running on a newer HV.

And this recently caused trouble because some user-space was
only partially checking (or maybe only looking at the cpuid
bits) and then trying to use xsave even though the OS support
was not set.

So I came up with a patch that would
- limit the work-around to certain Xen versions
- prevent the write to CR4 by unsetting xsave and osxsave in
  the cpuid bits

Doing things that way may actually allow this to be acceptable
upstream, so I am sending it around, now.
It probably could be improved when knowing the exact version
to test for but otherwise should allow to work around the guest
crash while not preventing xsave on Xen 4.x and newer hosts.

-Stefan


>From dff8885934d4e1274a69c4cedd28a4d18a1255e8 Mon Sep 17 00:00:00 2001
From: Stefan Bader <stefan.bader@canonical.com>
Date: Fri, 15 Jun 2012 11:54:59 +0200
Subject: [PATCH] xen: Mask xsave cpu capability on Xen host < 4

Older Xen hypervisors (like RHEL5 versions found to be used
on Amazon's EC2) did have a bug which would crash the domain
when trying to write unsupported CR4 values.
Newer versions of the Xen hypervisor do handle this correctly.
But when a 2.6.28 or later kernel (those seem to have
xen_write_cr4 and xsave support) is booted as a PV guest on EC2,
it potentially crashes when hitting the right CPU and the wrong
hypervisor.

We were using a patch (taken from Fedora) that did always filter
the OSXSAVE off the values written to CR4 when running as Xen PV
guest. While not completely wrong this creates an inconsistency
between the cpuid bits a guest sees and the CR4 settings.
But it prevents any use of xsave even on recent Xen hypervisors.
And this did recently cause problems because user-space was not
testing all bits when deciding to use certain features.

This patch will actually mask off the cpuid bits for XSAVE and
OSXSAVE, so generic code will not even try to set CR4. It is
limited to PV guests and (since we do not actually know the
exact version) Xen hypervisors before version 4.

Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
---
 arch/x86/xen/enlighten.c |   17 ++++++++++++++++-
 1 file changed, 16 insertions(+), 1 deletion(-)

diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
index 9642d4a..4241055 100644
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -210,6 +210,18 @@ void xen_vcpu_restore(void)
 	}
 }
 
+/*
+ * Older (with no clear statement about what old means) Xen hypervisors
+ * will crash a PV guest that tries to store OSXSAVE into CR4.
+ * To prevent this, we force the feature bits related to this off in the
+ * xen cpuid call. This inline function serves as a centralized test
+ * on whether the quirk should be done.
+ */
+static inline needs_xsave_quirk(unsigned version)
+{
+	return (xen_pv_domain() && ((version >> 16) < 4)) ? 1 : 0;
+}
+
 static void __init xen_banner(void)
 {
 	unsigned version = HYPERVISOR_xen_version(XENVER_version, NULL);
@@ -221,6 +233,8 @@ static void __init xen_banner(void)
 	printk(KERN_INFO "Xen version: %d.%d%s%s\n",
 	       version >> 16, version & 0xffff, extra.extraversion,
 	       xen_feature(XENFEAT_mmu_pt_update_preserve_ad) ? " (preserve-AD)" : "");
+	if (needs_xsave_quirk(version))
+		printk(KERN_INFO "Forcing xsave off due to Xen version.\n");
 }
 
 #define CPUID_THERM_POWER_LEAF 6
@@ -351,6 +365,7 @@ static bool __init xen_check_mwait(void)
 }
 static void __init xen_init_cpuid_mask(void)
 {
+	unsigned version = HYPERVISOR_xen_version(XENVER_version, NULL);
 	unsigned int ax, bx, cx, dx;
 	unsigned int xsave_mask;
 
@@ -371,7 +386,7 @@ static void __init xen_init_cpuid_mask(void)
 		(1 << (X86_FEATURE_OSXSAVE % 32));
 
 	/* Xen will set CR4.OSXSAVE if supported and not disabled by force */
-	if ((cx & xsave_mask) != xsave_mask)
+	if (((cx & xsave_mask) != xsave_mask) || needs_xsave_quirk(version))
 		cpuid_leaf1_ecx_mask &= ~xsave_mask; /* disable XSAVE & OSXSAVE */
 	if (xen_check_mwait())
 		cpuid_leaf1_ecx_set_mask = (1 << (X86_FEATURE_MWAIT % 32));
-- 
1.7.9.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 07 11:51:53 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Sep 2012 11:51:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9x5w-0002EY-88; Fri, 07 Sep 2012 11:51:32 +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 1T9x5u-0002ET-Mf
	for xen-devel@lists.xen.org; Fri, 07 Sep 2012 11:51:30 +0000
Received: from [85.158.143.99:23085] by server-1.bemta-4.messagelabs.com id
	4F/5B-12504-2CFD9405; Fri, 07 Sep 2012 11:51:30 +0000
X-Env-Sender: ben.guthro@gmail.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1347018687!25742374!1
X-Originating-IP: [209.85.223.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18690 invoked from network); 7 Sep 2012 11:51:28 -0000
Received: from mail-ie0-f173.google.com (HELO mail-ie0-f173.google.com)
	(209.85.223.173)
	by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Sep 2012 11:51:28 -0000
Received: by iebc10 with SMTP id c10so5923988ieb.32
	for <xen-devel@lists.xen.org>; Fri, 07 Sep 2012 04:51: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;
	bh=XVPqlNBtCjopm0WtFIJSrQnLz8Hoskf/KU93U/EEevQ=;
	b=fvjxGrW47A/4hOYfoDHNCZgQ1M565foOP0XHEYowso1z6mBalniOXNENaeX9jeJ4aT
	ZwYvvPQr/bfhQAZdemxAX27RNJI8TptrsvMrX59IdgQJHdkp6hGevp5NIFDd+9s218F6
	+XKNu5hoSzsq9X4Vu5nSVQS1n8L2l+V55OaGnHksWWyxtnklIzrxRb+1Vbr4FQ5Ipc2L
	T99MrXrRxyDXgNXvKccJ4QNOrRvZ1rgcZeSdFUM7BcD/TnEQPbn27Uj85qWmOr+ePq3+
	e1NQ8SD3oP/k9N1zlEYHDwL6+Jl1NymPmf64fYwkQRiM//BFZiC0U6ZaavQz1et4G7CV
	V/iw==
MIME-Version: 1.0
Received: by 10.50.85.129 with SMTP id h1mr2324954igz.62.1347018686915; Fri,
	07 Sep 2012 04:51:26 -0700 (PDT)
Received: by 10.64.28.203 with HTTP; Fri, 7 Sep 2012 04:51:26 -0700 (PDT)
In-Reply-To: <5049F37A0200007800099BDA@nat28.tlf.novell.com>
References: <CAOvdn6WwgBD-2yf1uu3m9-16=Tb5KUrybXf2KibtnxKbP7YtwA@mail.gmail.com>
	<CAOvdn6UBW-yTOMd3YSf5M9JiHLRivyaKL-qzcKG8epszqaKmGg@mail.gmail.com>
	<20120807163320.GC15053@phenom.dumpdata.com>
	<CAOvdn6XcRGKtJxGwJO8J+ZBJr89wfTLc1woW5rhtMM540H9h1w@mail.gmail.com>
	<CAOvdn6XUoSeGoo7X=AJ1kpDxZB9HZEv+TJ4v-=FHcyR4=CHK-w@mail.gmail.com>
	<502240F302000078000937A6@nat28.tlf.novell.com>
	<CAOvdn6WN3kxC8Bb9g6MpfLULu47EGSGCtajPc-SFeJ-8VSUQDQ@mail.gmail.com>
	<CAOvdn6Xk1inm1hU55i0phU2qvSWyJLNoyDdn43biBAY2OewPtw@mail.gmail.com>
	<5023F5400200007800093F4E@nat28.tlf.novell.com>
	<CAOvdn6U-f3C4U8xVPvDyRFkFFLkbfiCXg_n+9zgA9V5u+q5jfw@mail.gmail.com>
	<5023F8B80200007800093F8C@nat28.tlf.novell.com>
	<CAOvdn6XKHfete_+=Hkvt20G7_cJ-4i8+9j9YD30OxzQ16Ru-+g@mail.gmail.com>
	<5024CB720200007800094124@nat28.tlf.novell.com>
	<CAOvdn6VVJdhWVYa-gNVt3euE4AbGi1TijUCUd1wGzv0SCWEUYA@mail.gmail.com>
	<CAOvdn6USnG9Y4MNBhrDZmob0oJ8BgFfKTvFEhcKbXDxNmzfZ-Q@mail.gmail.com>
	<502B75BA0200007800094FD4@nat28.tlf.novell.com>
	<CAOvdn6Ww5oEj6Xg=XT4dWCYWUBuOdPqLz-CqNjz4HmCScE+==g@mail.gmail.com>
	<CAOvdn6Wsjds_dmZ0dwDTYmD-o-OqjBH5-b9mitAuUADE+A4_ag@mail.gmail.com>
	<502BB8FD02000078000951E0@nat28.tlf.novell.com>
	<CAOvdn6VD6bp13F-tvYdkBsj4hkhE7PTGZrapndtdHrDKeZqccg@mail.gmail.com>
	<502CCC0002000078000955C4@nat28.tlf.novell.com>
	<CAOvdn6VEuX7R2_wz74ZvCxMjC-=YUir9kP5sdxEVaKVspRUd_w@mail.gmail.com>
	<502CF0A8020000780009574E@nat28.tlf.novell.com>
	<CAOvdn6VsZvn_1TCWYeuyY5YuTcP8=miK2KwE4583nsj6Qjb_vg@mail.gmail.com>
	<504494FB0200007800098398@nat28.tlf.novell.com>
	<CAOvdn6UT13qvWbMyfZkWND03RoVKVSgb6wW4yqTUpuBYEX01Dg@mail.gmail.com>
	<5048958D02000078000993EB@nat28.tlf.novell.com>
	<CAOvdn6WrNK1Jn_Y_P7C3AwX6ApVcgzacLA_x-u=xBQtebnuPxA@mail.gmail.com>
	<CAOvdn6U_Z=KdEo56nqe7jN54BwiesRJqDOz_VzVNpkWGfFRd2A@mail.gmail.com>
	<5049CEAE0200007800099A33@nat28.tlf.novell.com>
	<CAOvdn6XmsEfs+aO7nqBHdA61HpT_n_8W95u0MMq5J21tZCFbzw@mail.gmail.com>
	<5049F37A0200007800099BDA@nat28.tlf.novell.com>
Date: Fri, 7 Sep 2012 07:51:26 -0400
X-Google-Sender-Auth: VS2S1Lw6hdEW-VVN-kHcTjBWkbA
Message-ID: <CAOvdn6W+=OYTH3xTWBxUB8f_2tuZYKPTo-eJG0jfkaJ2rVutCA@mail.gmail.com>
From: Ben Guthro <ben@guthro.net>
To: Jan Beulich <JBeulich@suse.com>
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>, john.baboval@citrix.com,
	Thomas Goetz <thomas.goetz@citrix.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen4.2 S3 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

I have verified it is running with uart->irq == 0 when running on serial.

However, when I run with console=none, the observed behavior is very different.
The system seems to go to sleep successfully - but when I press the
power button to wake it up - the power comes on - the fans spin up -
but the system is unresponsive.
No video
No network
keyboard LEDs (Caps,Numlock) do not light up.


Alternate debugging strategies welcome.

/btg

On Fri, Sep 7, 2012 at 7:15 AM, Jan Beulich <JBeulich@suse.com> wrote:
>>>> On 07.09.12 at 12:37, Ben Guthro <ben@guthro.net> wrote:
>> On Fri, Sep 7, 2012 at 4:38 AM, Jan Beulich <JBeulich@suse.com> wrote:
>>
>>> >>> On 06.09.12 at 18:42, Ben Guthro <ben@guthro.net> wrote:
>>> > Odd.
>>> > The behavior seems to change, when not running with serial output.
>>>
>>> Odd indeed. Could you (unless you are already) try running the
>>> serial console in polling mode (i.e. without IRQ), to see whether
>>> the IRQs coming from it somehow keep the system alive at a
>>> certain point?
>>>
>>>
>> I tried to do this at the end of yesterday, since you had suggested it
>> previously, in this thread.
>>
>> I did so by adding a ",0" to my com1 line, per the documentation - However,
>> I am running with a PCI serial card, and not an "on-board" one - so my
>> parameter looks like:
>>
>> com1=115200,8n1,pci,0
>>
>> I am not totally convinced that it is actually running in polling mode, and
>> started to investigate ns16550.c to verify it was. I plan on resuming this
>> investigation this morning.
>> If you have any pointers on what I should be looking for - I'd appreciate
>> any suggestions.
>>
>
> The only thing you need to make sure is that at the end of
> ns16550_parse_port_config() uart->irq is zero. But for PCI
> that should be the default right now in -unstable (but I
> think I have a patch pending to alter this in certain cases).
>
> Jan
>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 07 11:51:53 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Sep 2012 11:51:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9x5w-0002EY-88; Fri, 07 Sep 2012 11:51:32 +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 1T9x5u-0002ET-Mf
	for xen-devel@lists.xen.org; Fri, 07 Sep 2012 11:51:30 +0000
Received: from [85.158.143.99:23085] by server-1.bemta-4.messagelabs.com id
	4F/5B-12504-2CFD9405; Fri, 07 Sep 2012 11:51:30 +0000
X-Env-Sender: ben.guthro@gmail.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1347018687!25742374!1
X-Originating-IP: [209.85.223.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18690 invoked from network); 7 Sep 2012 11:51:28 -0000
Received: from mail-ie0-f173.google.com (HELO mail-ie0-f173.google.com)
	(209.85.223.173)
	by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Sep 2012 11:51:28 -0000
Received: by iebc10 with SMTP id c10so5923988ieb.32
	for <xen-devel@lists.xen.org>; Fri, 07 Sep 2012 04:51: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;
	bh=XVPqlNBtCjopm0WtFIJSrQnLz8Hoskf/KU93U/EEevQ=;
	b=fvjxGrW47A/4hOYfoDHNCZgQ1M565foOP0XHEYowso1z6mBalniOXNENaeX9jeJ4aT
	ZwYvvPQr/bfhQAZdemxAX27RNJI8TptrsvMrX59IdgQJHdkp6hGevp5NIFDd+9s218F6
	+XKNu5hoSzsq9X4Vu5nSVQS1n8L2l+V55OaGnHksWWyxtnklIzrxRb+1Vbr4FQ5Ipc2L
	T99MrXrRxyDXgNXvKccJ4QNOrRvZ1rgcZeSdFUM7BcD/TnEQPbn27Uj85qWmOr+ePq3+
	e1NQ8SD3oP/k9N1zlEYHDwL6+Jl1NymPmf64fYwkQRiM//BFZiC0U6ZaavQz1et4G7CV
	V/iw==
MIME-Version: 1.0
Received: by 10.50.85.129 with SMTP id h1mr2324954igz.62.1347018686915; Fri,
	07 Sep 2012 04:51:26 -0700 (PDT)
Received: by 10.64.28.203 with HTTP; Fri, 7 Sep 2012 04:51:26 -0700 (PDT)
In-Reply-To: <5049F37A0200007800099BDA@nat28.tlf.novell.com>
References: <CAOvdn6WwgBD-2yf1uu3m9-16=Tb5KUrybXf2KibtnxKbP7YtwA@mail.gmail.com>
	<CAOvdn6UBW-yTOMd3YSf5M9JiHLRivyaKL-qzcKG8epszqaKmGg@mail.gmail.com>
	<20120807163320.GC15053@phenom.dumpdata.com>
	<CAOvdn6XcRGKtJxGwJO8J+ZBJr89wfTLc1woW5rhtMM540H9h1w@mail.gmail.com>
	<CAOvdn6XUoSeGoo7X=AJ1kpDxZB9HZEv+TJ4v-=FHcyR4=CHK-w@mail.gmail.com>
	<502240F302000078000937A6@nat28.tlf.novell.com>
	<CAOvdn6WN3kxC8Bb9g6MpfLULu47EGSGCtajPc-SFeJ-8VSUQDQ@mail.gmail.com>
	<CAOvdn6Xk1inm1hU55i0phU2qvSWyJLNoyDdn43biBAY2OewPtw@mail.gmail.com>
	<5023F5400200007800093F4E@nat28.tlf.novell.com>
	<CAOvdn6U-f3C4U8xVPvDyRFkFFLkbfiCXg_n+9zgA9V5u+q5jfw@mail.gmail.com>
	<5023F8B80200007800093F8C@nat28.tlf.novell.com>
	<CAOvdn6XKHfete_+=Hkvt20G7_cJ-4i8+9j9YD30OxzQ16Ru-+g@mail.gmail.com>
	<5024CB720200007800094124@nat28.tlf.novell.com>
	<CAOvdn6VVJdhWVYa-gNVt3euE4AbGi1TijUCUd1wGzv0SCWEUYA@mail.gmail.com>
	<CAOvdn6USnG9Y4MNBhrDZmob0oJ8BgFfKTvFEhcKbXDxNmzfZ-Q@mail.gmail.com>
	<502B75BA0200007800094FD4@nat28.tlf.novell.com>
	<CAOvdn6Ww5oEj6Xg=XT4dWCYWUBuOdPqLz-CqNjz4HmCScE+==g@mail.gmail.com>
	<CAOvdn6Wsjds_dmZ0dwDTYmD-o-OqjBH5-b9mitAuUADE+A4_ag@mail.gmail.com>
	<502BB8FD02000078000951E0@nat28.tlf.novell.com>
	<CAOvdn6VD6bp13F-tvYdkBsj4hkhE7PTGZrapndtdHrDKeZqccg@mail.gmail.com>
	<502CCC0002000078000955C4@nat28.tlf.novell.com>
	<CAOvdn6VEuX7R2_wz74ZvCxMjC-=YUir9kP5sdxEVaKVspRUd_w@mail.gmail.com>
	<502CF0A8020000780009574E@nat28.tlf.novell.com>
	<CAOvdn6VsZvn_1TCWYeuyY5YuTcP8=miK2KwE4583nsj6Qjb_vg@mail.gmail.com>
	<504494FB0200007800098398@nat28.tlf.novell.com>
	<CAOvdn6UT13qvWbMyfZkWND03RoVKVSgb6wW4yqTUpuBYEX01Dg@mail.gmail.com>
	<5048958D02000078000993EB@nat28.tlf.novell.com>
	<CAOvdn6WrNK1Jn_Y_P7C3AwX6ApVcgzacLA_x-u=xBQtebnuPxA@mail.gmail.com>
	<CAOvdn6U_Z=KdEo56nqe7jN54BwiesRJqDOz_VzVNpkWGfFRd2A@mail.gmail.com>
	<5049CEAE0200007800099A33@nat28.tlf.novell.com>
	<CAOvdn6XmsEfs+aO7nqBHdA61HpT_n_8W95u0MMq5J21tZCFbzw@mail.gmail.com>
	<5049F37A0200007800099BDA@nat28.tlf.novell.com>
Date: Fri, 7 Sep 2012 07:51:26 -0400
X-Google-Sender-Auth: VS2S1Lw6hdEW-VVN-kHcTjBWkbA
Message-ID: <CAOvdn6W+=OYTH3xTWBxUB8f_2tuZYKPTo-eJG0jfkaJ2rVutCA@mail.gmail.com>
From: Ben Guthro <ben@guthro.net>
To: Jan Beulich <JBeulich@suse.com>
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>, john.baboval@citrix.com,
	Thomas Goetz <thomas.goetz@citrix.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen4.2 S3 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

I have verified it is running with uart->irq == 0 when running on serial.

However, when I run with console=none, the observed behavior is very different.
The system seems to go to sleep successfully - but when I press the
power button to wake it up - the power comes on - the fans spin up -
but the system is unresponsive.
No video
No network
keyboard LEDs (Caps,Numlock) do not light up.


Alternate debugging strategies welcome.

/btg

On Fri, Sep 7, 2012 at 7:15 AM, Jan Beulich <JBeulich@suse.com> wrote:
>>>> On 07.09.12 at 12:37, Ben Guthro <ben@guthro.net> wrote:
>> On Fri, Sep 7, 2012 at 4:38 AM, Jan Beulich <JBeulich@suse.com> wrote:
>>
>>> >>> On 06.09.12 at 18:42, Ben Guthro <ben@guthro.net> wrote:
>>> > Odd.
>>> > The behavior seems to change, when not running with serial output.
>>>
>>> Odd indeed. Could you (unless you are already) try running the
>>> serial console in polling mode (i.e. without IRQ), to see whether
>>> the IRQs coming from it somehow keep the system alive at a
>>> certain point?
>>>
>>>
>> I tried to do this at the end of yesterday, since you had suggested it
>> previously, in this thread.
>>
>> I did so by adding a ",0" to my com1 line, per the documentation - However,
>> I am running with a PCI serial card, and not an "on-board" one - so my
>> parameter looks like:
>>
>> com1=115200,8n1,pci,0
>>
>> I am not totally convinced that it is actually running in polling mode, and
>> started to investigate ns16550.c to verify it was. I plan on resuming this
>> investigation this morning.
>> If you have any pointers on what I should be looking for - I'd appreciate
>> any suggestions.
>>
>
> The only thing you need to make sure is that at the end of
> ns16550_parse_port_config() uart->irq is zero. But for PCI
> that should be the default right now in -unstable (but I
> think I have a patch pending to alter this in certain cases).
>
> Jan
>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 07 11:52:25 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Sep 2012 11:52:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9x6X-0002GV-ME; Fri, 07 Sep 2012 11:52:09 +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 1T9x6W-0002GM-5A
	for xen-devel@lists.xen.org; Fri, 07 Sep 2012 11:52:08 +0000
Received: from [85.158.139.83:33744] by server-8.bemta-5.messagelabs.com id
	C1/D6-17085-7EFD9405; Fri, 07 Sep 2012 11:52:07 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1347018725!28994504!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-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12554 invoked from network); 7 Sep 2012 11:52:05 -0000
Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com)
	(74.125.83.45)
	by server-12.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Sep 2012 11:52:05 -0000
Received: by eeke53 with SMTP id e53so1251882eek.32
	for <xen-devel@lists.xen.org>; Fri, 07 Sep 2012 04:52:05 -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:mime-version:content-type:content-transfer-encoding;
	bh=UZUFoR6PDzzsdd8wQwW6hUc9nq1DgM4OMtsP7brSZ0w=;
	b=BhUPtVQEHlcfVxcquC3H75pibwue7peeRnhoyajBalJeCMo1r+qVANeI2czYf9O4aN
	BYX4b021NLzRqM6kOBz72uMahrpnbb0HO9J3lhfS5xq0sqPfMT33sB/ig4JtAmL00jXc
	MaRlfLdczvp8vYoA4TMhwbP3crqhXepcu1zEWvmjqLpdleptHY0d5y4jRpyJMx8E5y2t
	RfX0Q+6I6x9nN/5GTsEO+A6hggIlrPw6hV5XbWnXyIKmBAQmxT6kvvtbrUzISmXMZlTb
	2N4hu8pzGt7H/D5lYp3QyDMqrhBOE4a5trg8ygudm1xuFLRS2C6x49CtlVY0qm69cXe2
	qzXQ==
Received: by 10.14.0.198 with SMTP id 46mr7446391eeb.30.1347018725459;
	Fri, 07 Sep 2012 04:52:05 -0700 (PDT)
Received: from [192.168.1.69] (host86-184-74-117.range86-184.btcentralplus.com.
	[86.184.74.117])
	by mx.google.com with ESMTPS id l42sm14080147eep.1.2012.09.07.04.52.03
	(version=SSLv3 cipher=OTHER); Fri, 07 Sep 2012 04:52:04 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Fri, 07 Sep 2012 12:52:00 +0100
From: Keir Fraser <keir.xen@gmail.com>
To: <xen-devel@lists.xen.org>
Message-ID: <CC6F9E70.3E07C%keir.xen@gmail.com>
Thread-Topic: [ANNOUNCE] Xen 4.2.0 RC4 tagged
Thread-Index: Ac2M7zBb55qYXLbIxEumTlDzl3+ufg==
Mime-version: 1.0
Subject: [Xen-devel] [ANNOUNCE] Xen 4.2.0 RC4 tagged
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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,

The fourth release candidate is now available:

http://xenbits.xen.org/stagiung/xen-4.2-testing.hg (tag '4.2.0-rc4')

We plan to release a week on Monday. So please test this one!

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 07 11:52:25 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Sep 2012 11:52:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9x6X-0002GV-ME; Fri, 07 Sep 2012 11:52:09 +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 1T9x6W-0002GM-5A
	for xen-devel@lists.xen.org; Fri, 07 Sep 2012 11:52:08 +0000
Received: from [85.158.139.83:33744] by server-8.bemta-5.messagelabs.com id
	C1/D6-17085-7EFD9405; Fri, 07 Sep 2012 11:52:07 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1347018725!28994504!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-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12554 invoked from network); 7 Sep 2012 11:52:05 -0000
Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com)
	(74.125.83.45)
	by server-12.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Sep 2012 11:52:05 -0000
Received: by eeke53 with SMTP id e53so1251882eek.32
	for <xen-devel@lists.xen.org>; Fri, 07 Sep 2012 04:52:05 -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:mime-version:content-type:content-transfer-encoding;
	bh=UZUFoR6PDzzsdd8wQwW6hUc9nq1DgM4OMtsP7brSZ0w=;
	b=BhUPtVQEHlcfVxcquC3H75pibwue7peeRnhoyajBalJeCMo1r+qVANeI2czYf9O4aN
	BYX4b021NLzRqM6kOBz72uMahrpnbb0HO9J3lhfS5xq0sqPfMT33sB/ig4JtAmL00jXc
	MaRlfLdczvp8vYoA4TMhwbP3crqhXepcu1zEWvmjqLpdleptHY0d5y4jRpyJMx8E5y2t
	RfX0Q+6I6x9nN/5GTsEO+A6hggIlrPw6hV5XbWnXyIKmBAQmxT6kvvtbrUzISmXMZlTb
	2N4hu8pzGt7H/D5lYp3QyDMqrhBOE4a5trg8ygudm1xuFLRS2C6x49CtlVY0qm69cXe2
	qzXQ==
Received: by 10.14.0.198 with SMTP id 46mr7446391eeb.30.1347018725459;
	Fri, 07 Sep 2012 04:52:05 -0700 (PDT)
Received: from [192.168.1.69] (host86-184-74-117.range86-184.btcentralplus.com.
	[86.184.74.117])
	by mx.google.com with ESMTPS id l42sm14080147eep.1.2012.09.07.04.52.03
	(version=SSLv3 cipher=OTHER); Fri, 07 Sep 2012 04:52:04 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Fri, 07 Sep 2012 12:52:00 +0100
From: Keir Fraser <keir.xen@gmail.com>
To: <xen-devel@lists.xen.org>
Message-ID: <CC6F9E70.3E07C%keir.xen@gmail.com>
Thread-Topic: [ANNOUNCE] Xen 4.2.0 RC4 tagged
Thread-Index: Ac2M7zBb55qYXLbIxEumTlDzl3+ufg==
Mime-version: 1.0
Subject: [Xen-devel] [ANNOUNCE] Xen 4.2.0 RC4 tagged
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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,

The fourth release candidate is now available:

http://xenbits.xen.org/stagiung/xen-4.2-testing.hg (tag '4.2.0-rc4')

We plan to release a week on Monday. So please test this one!

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 07 11:54:35 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Sep 2012 11: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 1T9x8e-0002Pj-7G; Fri, 07 Sep 2012 11:54:20 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1T9x8c-0002PZ-KU
	for xen-devel@lists.xen.org; Fri, 07 Sep 2012 11:54:18 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1347018847!3029374!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-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4217 invoked from network); 7 Sep 2012 11:54:07 -0000
Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com)
	(74.125.83.45)
	by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Sep 2012 11:54:07 -0000
Received: by eeke53 with SMTP id e53so1252706eek.32
	for <xen-devel@lists.xen.org>; Fri, 07 Sep 2012 04:54:07 -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:mime-version:content-type:content-transfer-encoding;
	bh=R2N0Gj4gK+Xmoe4NRLdPHkkggmSBxaQJG+pl4V+RSuw=;
	b=F62k04UzUQaK8x2FN9bBEjTZq3QS2TjreHJwKlOSfOyolb8bdYB8x8p6eBqgq8NR0B
	VeZ8Cy7QrKL0QkVbzxfkUej+XnWx1c8Fzd+ZX76FcRArwOvbw5oCkzKZtBY9N0MHXyIe
	Qd/QWdgGoXHby7NMt4hxpGkWPH+l6oBQye8AhlVWar+wW6b4Za1fTkMj5AIXr+Zvig7y
	BNpMd45s1vurKK0cXWVLMKx3rnrd9p8BaBQvahZ2GSS2U5uHfmHYZ5N4+HZgj6Zb19Ij
	6NIpN7lOj4PbTXJFodvoKGnM85AWmzSXzfPUVyJi9t7LRqyqeL+LnDH6Xgk7bu5h9qzf
	M0hQ==
Received: by 10.14.213.137 with SMTP id a9mr7414679eep.38.1347018846973;
	Fri, 07 Sep 2012 04:54:06 -0700 (PDT)
Received: from [192.168.1.69] (host86-184-74-117.range86-184.btcentralplus.com.
	[86.184.74.117])
	by mx.google.com with ESMTPS id k49sm14078691een.4.2012.09.07.04.54.05
	(version=SSLv3 cipher=OTHER); Fri, 07 Sep 2012 04:54:06 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Fri, 07 Sep 2012 12:54:00 +0100
From: Keir Fraser <keir.xen@gmail.com>
To: <xen-devel@lists.xen.org>
Message-ID: <CC6F9EE8.3E07D%keir.xen@gmail.com>
Thread-Topic: [ANNOUNCE] Xen-unstable (to be 4.3) open for development!
Thread-Index: Ac2M73fiLlweobBCt0+t0jMadlKs3Q==
Mime-version: 1.0
Subject: [Xen-devel] [ANNOUNCE] Xen-unstable (to be 4.3) open for
	development!
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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,

With Xen 4.2 branch now cloned to its own repository, xen-unstable.hg is
open for general development! Let the patch shovelling commence! :)

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 07 11:54:35 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Sep 2012 11: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 1T9x8e-0002Pj-7G; Fri, 07 Sep 2012 11:54:20 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1T9x8c-0002PZ-KU
	for xen-devel@lists.xen.org; Fri, 07 Sep 2012 11:54:18 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1347018847!3029374!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-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4217 invoked from network); 7 Sep 2012 11:54:07 -0000
Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com)
	(74.125.83.45)
	by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Sep 2012 11:54:07 -0000
Received: by eeke53 with SMTP id e53so1252706eek.32
	for <xen-devel@lists.xen.org>; Fri, 07 Sep 2012 04:54:07 -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:mime-version:content-type:content-transfer-encoding;
	bh=R2N0Gj4gK+Xmoe4NRLdPHkkggmSBxaQJG+pl4V+RSuw=;
	b=F62k04UzUQaK8x2FN9bBEjTZq3QS2TjreHJwKlOSfOyolb8bdYB8x8p6eBqgq8NR0B
	VeZ8Cy7QrKL0QkVbzxfkUej+XnWx1c8Fzd+ZX76FcRArwOvbw5oCkzKZtBY9N0MHXyIe
	Qd/QWdgGoXHby7NMt4hxpGkWPH+l6oBQye8AhlVWar+wW6b4Za1fTkMj5AIXr+Zvig7y
	BNpMd45s1vurKK0cXWVLMKx3rnrd9p8BaBQvahZ2GSS2U5uHfmHYZ5N4+HZgj6Zb19Ij
	6NIpN7lOj4PbTXJFodvoKGnM85AWmzSXzfPUVyJi9t7LRqyqeL+LnDH6Xgk7bu5h9qzf
	M0hQ==
Received: by 10.14.213.137 with SMTP id a9mr7414679eep.38.1347018846973;
	Fri, 07 Sep 2012 04:54:06 -0700 (PDT)
Received: from [192.168.1.69] (host86-184-74-117.range86-184.btcentralplus.com.
	[86.184.74.117])
	by mx.google.com with ESMTPS id k49sm14078691een.4.2012.09.07.04.54.05
	(version=SSLv3 cipher=OTHER); Fri, 07 Sep 2012 04:54:06 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Fri, 07 Sep 2012 12:54:00 +0100
From: Keir Fraser <keir.xen@gmail.com>
To: <xen-devel@lists.xen.org>
Message-ID: <CC6F9EE8.3E07D%keir.xen@gmail.com>
Thread-Topic: [ANNOUNCE] Xen-unstable (to be 4.3) open for development!
Thread-Index: Ac2M73fiLlweobBCt0+t0jMadlKs3Q==
Mime-version: 1.0
Subject: [Xen-devel] [ANNOUNCE] Xen-unstable (to be 4.3) open for
	development!
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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,

With Xen 4.2 branch now cloned to its own repository, xen-unstable.hg is
open for general development! Let the patch shovelling commence! :)

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 07 12:16:18 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Sep 2012 12:16:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9xTd-0003AF-Gh; Fri, 07 Sep 2012 12:16:01 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1T9xTb-0003AA-FM
	for xen-devel@lists.xen.org; Fri, 07 Sep 2012 12:15:59 +0000
Received: from [85.158.143.35:19980] by server-2.bemta-4.messagelabs.com id
	5B/F6-21239-E75E9405; Fri, 07 Sep 2012 12:15:58 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1347020066!12023662!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM4ODU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17441 invoked from network); 7 Sep 2012 12:14:26 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-11.tower-21.messagelabs.com with SMTP;
	7 Sep 2012 12:14:26 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 07 Sep 2012 13:14:25 +0100
Message-Id: <504A01790200007800099C52@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 07 Sep 2012 13:15:21 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
References: <504764270200007800098DE1@nat28.tlf.novell.com>
In-Reply-To: <504764270200007800098DE1@nat28.tlf.novell.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__PartDDECC949.1__="
Cc: dan.magenheimer@oracle.com, Ian Campbell <ian.campbell@citrix.com>,
	Zhenzhong Duan <zhenzhong.duan@oracle.com>
Subject: [Xen-devel] [PATCH 09/11, v2] tmem: reduce severity of log messages
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

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.

--=__PartDDECC949.1__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Otherwise they can be used by a guest to spam the hypervisor log when
all settings are at their defaults.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
---
v2: As suggested by Ian, use separate abstraction for messages printed
    in result of client side operations (so that e.g. the init time
    system messages don't also get converted to guest level ones).

--- a/xen/common/tmem.c
+++ b/xen/common/tmem.c
@@ -1107,7 +1107,7 @@ static int shared_pool_join(pool_t *pool
     sl->client =3D new_client;
     list_add_tail(&sl->share_list, &pool->share_list);
     if ( new_client->cli_id !=3D pool->client->cli_id )
-        printk("adding new %s %d to shared pool owned by %s %d\n",
+        tmh_client_info("adding new %s %d to shared pool owned by %s =
%d\n",
             client_str, new_client->cli_id, client_str, pool->client->cli_=
id);
     return ++pool->shared_count;
 }
@@ -1137,7 +1137,7 @@ static NOINLINE void shared_pool_reassig
     old_client->eph_count -=3D _atomic_read(pool->pgp_count);
     list_splice_init(&old_client->ephemeral_page_list,
                      &new_client->ephemeral_page_list);
-    printk("reassigned shared pool from %s=3D%d to %s=3D%d pool_id=3D%d\n"=
,
+    tmh_client_info("reassigned shared pool from %s=3D%d to %s=3D%d =
pool_id=3D%d\n",
         cli_id_str, old_client->cli_id, cli_id_str, new_client->cli_id, =
poolid);
     pool->pool_id =3D poolid;
 }
@@ -1173,7 +1173,7 @@ static NOINLINE int shared_pool_quit(poo
             }
         return 0;
     }
-    printk("tmem: no match unsharing pool, %s=3D%d\n",
+    tmh_client_warn("tmem: no match unsharing pool, %s=3D%d\n",
         cli_id_str,pool->client->cli_id);
     return -1;
 }
@@ -1184,17 +1184,18 @@ static void pool_flush(pool_t *pool, cli
     ASSERT(pool !=3D NULL);
     if ( (is_shared(pool)) && (shared_pool_quit(pool,cli_id) > 0) )
     {
-        printk("tmem: %s=3D%d no longer using shared pool %d owned by =
%s=3D%d\n",
+        tmh_client_warn("tmem: %s=3D%d no longer using shared pool %d =
owned by %s=3D%d\n",
            cli_id_str, cli_id, pool->pool_id, cli_id_str,pool->client->cli=
_id);
         return;
     }
-    printk("%s %s-%s tmem pool ",destroy?"destroying":"flushing",
-        is_persistent(pool) ? "persistent" : "ephemeral" ,
-        is_shared(pool) ? "shared" : "private");
-    printk("%s=3D%d pool_id=3D%d\n", cli_id_str,pool->client->cli_id,pool-=
>pool_id);
+    tmh_client_info("%s %s-%s tmem pool %s=3D%d pool_id=3D%d\n",
+                    destroy ? "destroying" : "flushing",
+                    is_persistent(pool) ? "persistent" : "ephemeral" ,
+                    is_shared(pool) ? "shared" : "private",
+                    cli_id_str, pool->client->cli_id, pool->pool_id);
     if ( pool->client->live_migrating )
     {
-        printk("can't %s pool while %s is live-migrating\n",
+        tmh_client_warn("can't %s pool while %s is live-migrating\n",
                destroy?"destroy":"flush", client_str);
         return;
     }
@@ -1213,21 +1214,22 @@ static client_t *client_create(cli_id_t=20
     client_t *client =3D tmh_alloc_infra(sizeof(client_t),__alignof__(clie=
nt_t));
     int i;
=20
-    printk("tmem: initializing tmem capability for %s=3D%d...",cli_id_str,=
cli_id);
+    tmh_client_info("tmem: initializing tmem capability for %s=3D%d...",
+                    cli_id_str, cli_id);
     if ( client =3D=3D NULL )
     {
-        printk("failed... out of memory\n");
+        tmh_client_err("failed... out of memory\n");
         goto fail;
     }
     memset(client,0,sizeof(client_t));
     if ( (client->tmh =3D tmh_client_init(cli_id)) =3D=3D NULL )
     {
-        printk("failed... can't allocate host-dependent part of client\n")=
;
+        tmh_client_err("failed... can't allocate host-dependent part of =
client\n");
         goto fail;
     }
     if ( !tmh_set_client_from_id(client, client->tmh, cli_id) )
     {
-        printk("failed... can't set client\n");
+        tmh_client_err("failed... can't set client\n");
         goto fail;
     }
     client->cli_id =3D cli_id;
@@ -1249,7 +1251,7 @@ static client_t *client_create(cli_id_t=20
     client->eph_count =3D client->eph_count_max =3D 0;
     client->total_cycles =3D 0; client->succ_pers_puts =3D 0;
     client->succ_eph_gets =3D 0; client->succ_pers_gets =3D 0;
-    printk("ok\n");
+    tmh_client_info("ok\n");
     return client;
=20
  fail:
@@ -1903,32 +1905,33 @@ static NOINLINE int do_tmem_new_pool(cli
         cli_id =3D tmh_get_cli_id_from_current();
     else
         cli_id =3D this_cli_id;
-    printk("tmem: allocating %s-%s tmem pool for %s=3D%d...",
+    tmh_client_info("tmem: allocating %s-%s tmem pool for %s=3D%d...",
         persistent ? "persistent" : "ephemeral" ,
         shared ? "shared" : "private", cli_id_str, cli_id);
     if ( specversion !=3D TMEM_SPEC_VERSION )
     {
-        printk("failed... unsupported spec version\n");
+        tmh_client_err("failed... unsupported spec version\n");
         return -EPERM;
     }
     if ( pagebits !=3D (PAGE_SHIFT - 12) )
     {
-        printk("failed... unsupported pagesize %d\n",1<<(pagebits+12));
+        tmh_client_err("failed... unsupported pagesize %d\n",
+                       1 << (pagebits + 12));
         return -EPERM;
     }
     if ( flags & TMEM_POOL_PRECOMPRESSED )
     {
-        printk("failed... precompression flag set but unsupported\n");
+        tmh_client_err("failed... precompression flag set but unsupported\=
n");
         return -EPERM;
     }
     if ( flags & TMEM_POOL_RESERVED_BITS )
     {
-        printk("failed... reserved bits must be zero\n");
+        tmh_client_err("failed... reserved bits must be zero\n");
         return -EPERM;
     }
     if ( (pool =3D pool_alloc()) =3D=3D NULL )
     {
-        printk("failed... out of memory\n");
+        tmh_client_err("failed... out of memory\n");
         return -ENOMEM;
     }
     if ( this_cli_id !=3D CLI_ID_NULL )
@@ -1947,7 +1950,7 @@ static NOINLINE int do_tmem_new_pool(cli
                 break;
         if ( d_poolid >=3D MAX_POOLS_PER_DOMAIN )
         {
-            printk("failed... no more pool slots available for this =
%s\n",
+            tmh_client_err("failed... no more pool slots available for =
this %s\n",
                    client_str);
             goto fail;
         }
@@ -1977,9 +1980,8 @@ static NOINLINE int do_tmem_new_pool(cli
             {
                 if ( shpool->uuid[0] =3D=3D uuid_lo && shpool->uuid[1] =
=3D=3D uuid_hi )
                 {
-                    printk("(matches shared pool uuid=3D%"PRIx64".%"PRIx64=
") ",
-                        uuid_hi, uuid_lo);
-                    printk("pool_id=3D%d\n",d_poolid);
+                    tmh_client_info("(matches shared pool uuid=3D%"PRIx64"=
.%"PRIx64") pool_id=3D%d\n",
+                        uuid_hi, uuid_lo, d_poolid);
                     client->pools[d_poolid] =3D global_shared_pools[s_pool=
id];
                     shared_pool_join(global_shared_pools[s_poolid], =
client);
                     pool_free(pool);
@@ -1991,7 +1993,7 @@ static NOINLINE int do_tmem_new_pool(cli
         }
         if ( first_unused_s_poolid =3D=3D MAX_GLOBAL_SHARED_POOLS )
         {
-            printk("tmem: failed... no global shared pool slots available\=
n");
+            tmh_client_warn("tmem: failed... no global shared pool slots =
available\n");
             goto fail;
         }
         else
@@ -2007,7 +2009,7 @@ static NOINLINE int do_tmem_new_pool(cli
     pool->pool_id =3D d_poolid;
     pool->persistent =3D persistent;
     pool->uuid[0] =3D uuid_lo; pool->uuid[1] =3D uuid_hi;
-    printk("pool_id=3D%d\n",d_poolid);
+    tmh_client_info("pool_id=3D%d\n", d_poolid);
     return d_poolid;
=20
 fail:
@@ -2030,14 +2032,15 @@ static int tmemc_freeze_pools(cli_id_t c
     {
         list_for_each_entry(client,&global_client_list,client_list)
             client_freeze(client,freeze);
-        printk("tmem: all pools %s for all %ss\n",s,client_str);
+        tmh_client_info("tmem: all pools %s for all %ss\n", s, client_str)=
;
     }
     else
     {
         if ( (client =3D tmh_client_from_cli_id(cli_id)) =3D=3D NULL)
             return -1;
         client_freeze(client,freeze);
-        printk("tmem: all pools %s for %s=3D%d\n",s,cli_id_str,cli_id);
+        tmh_client_info("tmem: all pools %s for %s=3D%d\n",
+                         s, cli_id_str, cli_id);
     }
     return 0;
 }
@@ -2048,7 +2051,7 @@ static int tmemc_flush_mem(cli_id_t cli_
=20
     if ( cli_id !=3D CLI_ID_NULL )
     {
-        printk("tmem: %s-specific flush not supported yet, use --all\n",
+        tmh_client_warn("tmem: %s-specific flush not supported yet, use =
--all\n",
            client_str);
         return -1;
     }
@@ -2261,13 +2264,15 @@ static int tmemc_set_var_one(client_t *c
     case TMEMC_SET_WEIGHT:
         old_weight =3D client->weight;
         client->weight =3D arg1;
-        printk("tmem: weight set to %d for %s=3D%d\n",arg1,cli_id_str,cli_=
id);
+        tmh_client_info("tmem: weight set to %d for %s=3D%d\n",
+                        arg1, cli_id_str, cli_id);
         atomic_sub(old_weight,&client_weight_total);
         atomic_add(client->weight,&client_weight_total);
         break;
     case TMEMC_SET_CAP:
         client->cap =3D arg1;
-        printk("tmem: cap set to %d for %s=3D%d\n",arg1,cli_id_str,cli_id)=
;
+        tmh_client_info("tmem: cap set to %d for %s=3D%d\n",
+                        arg1, cli_id_str, cli_id);
         break;
     case TMEMC_SET_COMPRESS:
 #ifdef __i386__
@@ -2275,17 +2280,17 @@ static int tmemc_set_var_one(client_t *c
 #endif
         if ( tmh_dedup_enabled() )
         {
-            printk("tmem: compression %s for all %ss, cannot be changed "
-                   "when tmem_dedup is enabled\n",
-            tmh_compression_enabled() ? "enabled" : "disabled",client_str)=
;
+            tmh_client_warn("tmem: compression %s for all %ss, cannot be =
changed when tmem_dedup is enabled\n",
+                            tmh_compression_enabled() ? "enabled" : =
"disabled",
+                            client_str);
             return -1;
         }
         client->compress =3D arg1 ? 1 : 0;
-        printk("tmem: compression %s for %s=3D%d\n",
+        tmh_client_info("tmem: compression %s for %s=3D%d\n",
             arg1 ? "enabled" : "disabled",cli_id_str,cli_id);
         break;
     default:
-        printk("tmem: unknown subop %d for tmemc_set_var\n",subop);
+        tmh_client_warn("tmem: unknown subop %d for tmemc_set_var\n", =
subop);
         return -1;
     }
     return 0;
@@ -2668,7 +2673,7 @@ EXPORT long do_tmem_op(tmem_cli_op_t uop
=20
     if ( unlikely(tmh_get_tmemop_from_client(&op, uops) !=3D 0) )
     {
-        printk("tmem: can't get tmem struct from %s\n",client_str);
+        tmh_client_err("tmem: can't get tmem struct from %s\n", client_str=
);
         rc =3D -EFAULT;
         if ( !tmh_lock_all )
             goto simple_error;
@@ -2702,7 +2707,8 @@ EXPORT long do_tmem_op(tmem_cli_op_t uop
         tmem_write_lock_set =3D 1;
         if ( (client =3D client_create(tmh_get_cli_id_from_current())) =
=3D=3D NULL )
         {
-            printk("tmem: can't create tmem structure for %s\n",client_str=
);
+            tmh_client_err("tmem: can't create tmem structure for %s\n",
+                           client_str);
             rc =3D -ENOMEM;
             goto out;
         }
@@ -2726,8 +2732,8 @@ EXPORT long do_tmem_op(tmem_cli_op_t uop
         if ( ((uint32_t)op.pool_id >=3D MAX_POOLS_PER_DOMAIN) ||
              ((pool =3D client->pools[op.pool_id]) =3D=3D NULL) )
         {
+            tmh_client_err("tmem: operation requested on uncreated =
pool\n");
             rc =3D -ENODEV;
-            printk("tmem: operation requested on uncreated pool\n");
             goto out;
         }
         ASSERT_SENTINEL(pool,POOL);
@@ -2783,11 +2789,11 @@ EXPORT long do_tmem_op(tmem_cli_op_t uop
         break;
     case TMEM_XCHG:
         /* need to hold global lock to ensure xchg is atomic */
-        printk("tmem_xchg op not implemented yet\n");
+        tmh_client_warn("tmem_xchg op not implemented yet\n");
         rc =3D 0;
         break;
     default:
-        printk("tmem: op %d not implemented\n", op.cmd);
+        tmh_client_warn("tmem: op %d not implemented\n", op.cmd);
         rc =3D 0;
         break;
     }
--- a/xen/include/xen/tmem_xen.h
+++ b/xen/include/xen/tmem_xen.h
@@ -512,6 +512,9 @@ int tmh_copy_to_client(tmem_cli_mfn_t, p
=20
 extern int tmh_copy_tze_to_client(tmem_cli_mfn_t cmfn, void *tmem_va, =
pagesize_t len);
=20
+#define tmh_client_err(fmt, args...)  printk(XENLOG_G_ERR fmt, ##args)
+#define tmh_client_warn(fmt, args...) printk(XENLOG_G_WARNING fmt, =
##args)
+#define tmh_client_info(fmt, args...) printk(XENLOG_G_INFO fmt, ##args)
=20
 #define TMEM_PERF
 #ifdef TMEM_PERF



--=__PartDDECC949.1__=
Content-Type: text/plain; name="tmem-xsa-15-9.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="tmem-xsa-15-9.patch"

tmem: reduce severity of log messages=0A=0AOtherwise they can be used by a =
guest to spam the hypervisor log when=0Aall settings are at their =
defaults.=0A=0ASigned-off-by: Jan Beulich <jbeulich@suse.com>=0A---=0Av2: =
As suggested by Ian, use separate abstraction for messages printed=0A    =
in result of client side operations (so that e.g. the init time=0A    =
system messages don't also get converted to guest level ones).=0A=0A--- =
a/xen/common/tmem.c=0A+++ b/xen/common/tmem.c=0A@@ -1107,7 +1107,7 @@ =
static int shared_pool_join(pool_t *pool=0A     sl->client =3D new_client;=
=0A     list_add_tail(&sl->share_list, &pool->share_list);=0A     if ( =
new_client->cli_id !=3D pool->client->cli_id )=0A-        printk("adding =
new %s %d to shared pool owned by %s %d\n",=0A+        tmh_client_info("add=
ing new %s %d to shared pool owned by %s %d\n",=0A             client_str, =
new_client->cli_id, client_str, pool->client->cli_id);=0A     return =
++pool->shared_count;=0A }=0A@@ -1137,7 +1137,7 @@ static NOINLINE void =
shared_pool_reassig=0A     old_client->eph_count -=3D _atomic_read(pool->pg=
p_count);=0A     list_splice_init(&old_client->ephemeral_page_list,=0A     =
                 &new_client->ephemeral_page_list);=0A-    printk("reassign=
ed shared pool from %s=3D%d to %s=3D%d pool_id=3D%d\n",=0A+    tmh_client_i=
nfo("reassigned shared pool from %s=3D%d to %s=3D%d pool_id=3D%d\n",=0A    =
     cli_id_str, old_client->cli_id, cli_id_str, new_client->cli_id, =
poolid);=0A     pool->pool_id =3D poolid;=0A }=0A@@ -1173,7 +1173,7 @@ =
static NOINLINE int shared_pool_quit(poo=0A             }=0A         =
return 0;=0A     }=0A-    printk("tmem: no match unsharing pool, %s=3D%d\n"=
,=0A+    tmh_client_warn("tmem: no match unsharing pool, %s=3D%d\n",=0A    =
     cli_id_str,pool->client->cli_id);=0A     return -1;=0A }=0A@@ =
-1184,17 +1184,18 @@ static void pool_flush(pool_t *pool, cli=0A     =
ASSERT(pool !=3D NULL);=0A     if ( (is_shared(pool)) && (shared_pool_quit(=
pool,cli_id) > 0) )=0A     {=0A-        printk("tmem: %s=3D%d no longer =
using shared pool %d owned by %s=3D%d\n",=0A+        tmh_client_warn("tmem:=
 %s=3D%d no longer using shared pool %d owned by %s=3D%d\n",=0A            =
cli_id_str, cli_id, pool->pool_id, cli_id_str,pool->client->cli_id);=0A    =
     return;=0A     }=0A-    printk("%s %s-%s tmem pool ",destroy?"destroyi=
ng":"flushing",=0A-        is_persistent(pool) ? "persistent" : "ephemeral"=
 ,=0A-        is_shared(pool) ? "shared" : "private");=0A-    printk("%s=3D=
%d pool_id=3D%d\n", cli_id_str,pool->client->cli_id,pool->pool_id);=0A+    =
tmh_client_info("%s %s-%s tmem pool %s=3D%d pool_id=3D%d\n",=0A+           =
         destroy ? "destroying" : "flushing",=0A+                    =
is_persistent(pool) ? "persistent" : "ephemeral" ,=0A+                    =
is_shared(pool) ? "shared" : "private",=0A+                    cli_id_str, =
pool->client->cli_id, pool->pool_id);=0A     if ( pool->client->live_migrat=
ing )=0A     {=0A-        printk("can't %s pool while %s is live-migrating\=
n",=0A+        tmh_client_warn("can't %s pool while %s is live-migrating\n"=
,=0A                destroy?"destroy":"flush", client_str);=0A         =
return;=0A     }=0A@@ -1213,21 +1214,22 @@ static client_t *client_create(c=
li_id_t =0A     client_t *client =3D tmh_alloc_infra(sizeof(client_t),__ali=
gnof__(client_t));=0A     int i;=0A =0A-    printk("tmem: initializing =
tmem capability for %s=3D%d...",cli_id_str,cli_id);=0A+    tmh_client_info(=
"tmem: initializing tmem capability for %s=3D%d...",=0A+                   =
 cli_id_str, cli_id);=0A     if ( client =3D=3D NULL )=0A     {=0A-        =
printk("failed... out of memory\n");=0A+        tmh_client_err("failed... =
out of memory\n");=0A         goto fail;=0A     }=0A     memset(client,0,si=
zeof(client_t));=0A     if ( (client->tmh =3D tmh_client_init(cli_id)) =
=3D=3D NULL )=0A     {=0A-        printk("failed... can't allocate =
host-dependent part of client\n");=0A+        tmh_client_err("failed... =
can't allocate host-dependent part of client\n");=0A         goto fail;=0A =
    }=0A     if ( !tmh_set_client_from_id(client, client->tmh, cli_id) =
)=0A     {=0A-        printk("failed... can't set client\n");=0A+        =
tmh_client_err("failed... can't set client\n");=0A         goto fail;=0A   =
  }=0A     client->cli_id =3D cli_id;=0A@@ -1249,7 +1251,7 @@ static =
client_t *client_create(cli_id_t =0A     client->eph_count =3D client->eph_=
count_max =3D 0;=0A     client->total_cycles =3D 0; client->succ_pers_puts =
=3D 0;=0A     client->succ_eph_gets =3D 0; client->succ_pers_gets =3D =
0;=0A-    printk("ok\n");=0A+    tmh_client_info("ok\n");=0A     return =
client;=0A =0A  fail:=0A@@ -1903,32 +1905,33 @@ static NOINLINE int =
do_tmem_new_pool(cli=0A         cli_id =3D tmh_get_cli_id_from_current();=
=0A     else=0A         cli_id =3D this_cli_id;=0A-    printk("tmem: =
allocating %s-%s tmem pool for %s=3D%d...",=0A+    tmh_client_info("tmem: =
allocating %s-%s tmem pool for %s=3D%d...",=0A         persistent ? =
"persistent" : "ephemeral" ,=0A         shared ? "shared" : "private", =
cli_id_str, cli_id);=0A     if ( specversion !=3D TMEM_SPEC_VERSION )=0A   =
  {=0A-        printk("failed... unsupported spec version\n");=0A+        =
tmh_client_err("failed... unsupported spec version\n");=0A         return =
-EPERM;=0A     }=0A     if ( pagebits !=3D (PAGE_SHIFT - 12) )=0A     =
{=0A-        printk("failed... unsupported pagesize %d\n",1<<(pagebits+12))=
;=0A+        tmh_client_err("failed... unsupported pagesize %d\n",=0A+     =
                  1 << (pagebits + 12));=0A         return -EPERM;=0A     =
}=0A     if ( flags & TMEM_POOL_PRECOMPRESSED )=0A     {=0A-        =
printk("failed... precompression flag set but unsupported\n");=0A+        =
tmh_client_err("failed... precompression flag set but unsupported\n");=0A  =
       return -EPERM;=0A     }=0A     if ( flags & TMEM_POOL_RESERVED_BITS =
)=0A     {=0A-        printk("failed... reserved bits must be zero\n");=0A+=
        tmh_client_err("failed... reserved bits must be zero\n");=0A       =
  return -EPERM;=0A     }=0A     if ( (pool =3D pool_alloc()) =3D=3D NULL =
)=0A     {=0A-        printk("failed... out of memory\n");=0A+        =
tmh_client_err("failed... out of memory\n");=0A         return -ENOMEM;=0A =
    }=0A     if ( this_cli_id !=3D CLI_ID_NULL )=0A@@ -1947,7 +1950,7 @@ =
static NOINLINE int do_tmem_new_pool(cli=0A                 break;=0A      =
   if ( d_poolid >=3D MAX_POOLS_PER_DOMAIN )=0A         {=0A-            =
printk("failed... no more pool slots available for this %s\n",=0A+         =
   tmh_client_err("failed... no more pool slots available for this =
%s\n",=0A                    client_str);=0A             goto fail;=0A     =
    }=0A@@ -1977,9 +1980,8 @@ static NOINLINE int do_tmem_new_pool(cli=0A  =
           {=0A                 if ( shpool->uuid[0] =3D=3D uuid_lo && =
shpool->uuid[1] =3D=3D uuid_hi )=0A                 {=0A-                  =
  printk("(matches shared pool uuid=3D%"PRIx64".%"PRIx64") ",=0A-          =
              uuid_hi, uuid_lo);=0A-                    printk("pool_id=3D%=
d\n",d_poolid);=0A+                    tmh_client_info("(matches shared =
pool uuid=3D%"PRIx64".%"PRIx64") pool_id=3D%d\n",=0A+                      =
  uuid_hi, uuid_lo, d_poolid);=0A                     client->pools[d_pooli=
d] =3D global_shared_pools[s_poolid];=0A                     shared_pool_jo=
in(global_shared_pools[s_poolid], client);=0A                     =
pool_free(pool);=0A@@ -1991,7 +1993,7 @@ static NOINLINE int do_tmem_new_po=
ol(cli=0A         }=0A         if ( first_unused_s_poolid =3D=3D MAX_GLOBAL=
_SHARED_POOLS )=0A         {=0A-            printk("tmem: failed... no =
global shared pool slots available\n");=0A+            tmh_client_warn("tme=
m: failed... no global shared pool slots available\n");=0A             =
goto fail;=0A         }=0A         else=0A@@ -2007,7 +2009,7 @@ static =
NOINLINE int do_tmem_new_pool(cli=0A     pool->pool_id =3D d_poolid;=0A    =
 pool->persistent =3D persistent;=0A     pool->uuid[0] =3D uuid_lo; =
pool->uuid[1] =3D uuid_hi;=0A-    printk("pool_id=3D%d\n",d_poolid);=0A+   =
 tmh_client_info("pool_id=3D%d\n", d_poolid);=0A     return d_poolid;=0A =
=0A fail:=0A@@ -2030,14 +2032,15 @@ static int tmemc_freeze_pools(cli_id_t =
c=0A     {=0A         list_for_each_entry(client,&global_client_list,client=
_list)=0A             client_freeze(client,freeze);=0A-        printk("tmem=
: all pools %s for all %ss\n",s,client_str);=0A+        tmh_client_info("tm=
em: all pools %s for all %ss\n", s, client_str);=0A     }=0A     else=0A   =
  {=0A         if ( (client =3D tmh_client_from_cli_id(cli_id)) =3D=3D =
NULL)=0A             return -1;=0A         client_freeze(client,freeze);=0A=
-        printk("tmem: all pools %s for %s=3D%d\n",s,cli_id_str,cli_id);=0A=
+        tmh_client_info("tmem: all pools %s for %s=3D%d\n",=0A+           =
              s, cli_id_str, cli_id);=0A     }=0A     return 0;=0A }=0A@@ =
-2048,7 +2051,7 @@ static int tmemc_flush_mem(cli_id_t cli_=0A =0A     if =
( cli_id !=3D CLI_ID_NULL )=0A     {=0A-        printk("tmem: %s-specific =
flush not supported yet, use --all\n",=0A+        tmh_client_warn("tmem: =
%s-specific flush not supported yet, use --all\n",=0A            client_str=
);=0A         return -1;=0A     }=0A@@ -2261,13 +2264,15 @@ static int =
tmemc_set_var_one(client_t *c=0A     case TMEMC_SET_WEIGHT:=0A         =
old_weight =3D client->weight;=0A         client->weight =3D arg1;=0A-     =
   printk("tmem: weight set to %d for %s=3D%d\n",arg1,cli_id_str,cli_id);=
=0A+        tmh_client_info("tmem: weight set to %d for %s=3D%d\n",=0A+    =
                    arg1, cli_id_str, cli_id);=0A         atomic_sub(old_we=
ight,&client_weight_total);=0A         atomic_add(client->weight,&client_we=
ight_total);=0A         break;=0A     case TMEMC_SET_CAP:=0A         =
client->cap =3D arg1;=0A-        printk("tmem: cap set to %d for %s=3D%d\n"=
,arg1,cli_id_str,cli_id);=0A+        tmh_client_info("tmem: cap set to %d =
for %s=3D%d\n",=0A+                        arg1, cli_id_str, cli_id);=0A   =
      break;=0A     case TMEMC_SET_COMPRESS:=0A #ifdef __i386__=0A@@ =
-2275,17 +2280,17 @@ static int tmemc_set_var_one(client_t *c=0A #endif=0A =
        if ( tmh_dedup_enabled() )=0A         {=0A-            printk("tmem=
: compression %s for all %ss, cannot be changed "=0A-                   =
"when tmem_dedup is enabled\n",=0A-            tmh_compression_enabled() ? =
"enabled" : "disabled",client_str);=0A+            tmh_client_warn("tmem: =
compression %s for all %ss, cannot be changed when tmem_dedup is enabled\n"=
,=0A+                            tmh_compression_enabled() ? "enabled" : =
"disabled",=0A+                            client_str);=0A             =
return -1;=0A         }=0A         client->compress =3D arg1 ? 1 : 0;=0A-  =
      printk("tmem: compression %s for %s=3D%d\n",=0A+        tmh_client_in=
fo("tmem: compression %s for %s=3D%d\n",=0A             arg1 ? "enabled" : =
"disabled",cli_id_str,cli_id);=0A         break;=0A     default:=0A-       =
 printk("tmem: unknown subop %d for tmemc_set_var\n",subop);=0A+        =
tmh_client_warn("tmem: unknown subop %d for tmemc_set_var\n", subop);=0A   =
      return -1;=0A     }=0A     return 0;=0A@@ -2668,7 +2673,7 @@ EXPORT =
long do_tmem_op(tmem_cli_op_t uop=0A =0A     if ( unlikely(tmh_get_tmemop_f=
rom_client(&op, uops) !=3D 0) )=0A     {=0A-        printk("tmem: can't =
get tmem struct from %s\n",client_str);=0A+        tmh_client_err("tmem: =
can't get tmem struct from %s\n", client_str);=0A         rc =3D =
-EFAULT;=0A         if ( !tmh_lock_all )=0A             goto simple_error;=
=0A@@ -2702,7 +2707,8 @@ EXPORT long do_tmem_op(tmem_cli_op_t uop=0A       =
  tmem_write_lock_set =3D 1;=0A         if ( (client =3D client_create(tmh_=
get_cli_id_from_current())) =3D=3D NULL )=0A         {=0A-            =
printk("tmem: can't create tmem structure for %s\n",client_str);=0A+       =
     tmh_client_err("tmem: can't create tmem structure for %s\n",=0A+      =
                     client_str);=0A             rc =3D -ENOMEM;=0A        =
     goto out;=0A         }=0A@@ -2726,8 +2732,8 @@ EXPORT long do_tmem_op(=
tmem_cli_op_t uop=0A         if ( ((uint32_t)op.pool_id >=3D MAX_POOLS_PER_=
DOMAIN) ||=0A              ((pool =3D client->pools[op.pool_id]) =3D=3D =
NULL) )=0A         {=0A+            tmh_client_err("tmem: operation =
requested on uncreated pool\n");=0A             rc =3D -ENODEV;=0A-        =
    printk("tmem: operation requested on uncreated pool\n");=0A            =
 goto out;=0A         }=0A         ASSERT_SENTINEL(pool,POOL);=0A@@ =
-2783,11 +2789,11 @@ EXPORT long do_tmem_op(tmem_cli_op_t uop=0A         =
break;=0A     case TMEM_XCHG:=0A         /* need to hold global lock to =
ensure xchg is atomic */=0A-        printk("tmem_xchg op not implemented =
yet\n");=0A+        tmh_client_warn("tmem_xchg op not implemented =
yet\n");=0A         rc =3D 0;=0A         break;=0A     default:=0A-        =
printk("tmem: op %d not implemented\n", op.cmd);=0A+        tmh_client_warn=
("tmem: op %d not implemented\n", op.cmd);=0A         rc =3D 0;=0A         =
break;=0A     }=0A--- a/xen/include/xen/tmem_xen.h=0A+++ b/xen/include/xen/=
tmem_xen.h=0A@@ -512,6 +512,9 @@ int tmh_copy_to_client(tmem_cli_mfn_t, =
p=0A =0A extern int tmh_copy_tze_to_client(tmem_cli_mfn_t cmfn, void =
*tmem_va, pagesize_t len);=0A =0A+#define tmh_client_err(fmt, args...)  =
printk(XENLOG_G_ERR fmt, ##args)=0A+#define tmh_client_warn(fmt, args...) =
printk(XENLOG_G_WARNING fmt, ##args)=0A+#define tmh_client_info(fmt, =
args...) printk(XENLOG_G_INFO fmt, ##args)=0A =0A #define TMEM_PERF=0A =
#ifdef TMEM_PERF=0A
--=__PartDDECC949.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

--=__PartDDECC949.1__=--


From xen-devel-bounces@lists.xen.org Fri Sep 07 12:16:18 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Sep 2012 12:16:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9xTd-0003AF-Gh; Fri, 07 Sep 2012 12:16:01 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1T9xTb-0003AA-FM
	for xen-devel@lists.xen.org; Fri, 07 Sep 2012 12:15:59 +0000
Received: from [85.158.143.35:19980] by server-2.bemta-4.messagelabs.com id
	5B/F6-21239-E75E9405; Fri, 07 Sep 2012 12:15:58 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1347020066!12023662!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM4ODU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17441 invoked from network); 7 Sep 2012 12:14:26 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-11.tower-21.messagelabs.com with SMTP;
	7 Sep 2012 12:14:26 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 07 Sep 2012 13:14:25 +0100
Message-Id: <504A01790200007800099C52@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 07 Sep 2012 13:15:21 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
References: <504764270200007800098DE1@nat28.tlf.novell.com>
In-Reply-To: <504764270200007800098DE1@nat28.tlf.novell.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__PartDDECC949.1__="
Cc: dan.magenheimer@oracle.com, Ian Campbell <ian.campbell@citrix.com>,
	Zhenzhong Duan <zhenzhong.duan@oracle.com>
Subject: [Xen-devel] [PATCH 09/11, v2] tmem: reduce severity of log messages
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

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.

--=__PartDDECC949.1__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Otherwise they can be used by a guest to spam the hypervisor log when
all settings are at their defaults.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
---
v2: As suggested by Ian, use separate abstraction for messages printed
    in result of client side operations (so that e.g. the init time
    system messages don't also get converted to guest level ones).

--- a/xen/common/tmem.c
+++ b/xen/common/tmem.c
@@ -1107,7 +1107,7 @@ static int shared_pool_join(pool_t *pool
     sl->client =3D new_client;
     list_add_tail(&sl->share_list, &pool->share_list);
     if ( new_client->cli_id !=3D pool->client->cli_id )
-        printk("adding new %s %d to shared pool owned by %s %d\n",
+        tmh_client_info("adding new %s %d to shared pool owned by %s =
%d\n",
             client_str, new_client->cli_id, client_str, pool->client->cli_=
id);
     return ++pool->shared_count;
 }
@@ -1137,7 +1137,7 @@ static NOINLINE void shared_pool_reassig
     old_client->eph_count -=3D _atomic_read(pool->pgp_count);
     list_splice_init(&old_client->ephemeral_page_list,
                      &new_client->ephemeral_page_list);
-    printk("reassigned shared pool from %s=3D%d to %s=3D%d pool_id=3D%d\n"=
,
+    tmh_client_info("reassigned shared pool from %s=3D%d to %s=3D%d =
pool_id=3D%d\n",
         cli_id_str, old_client->cli_id, cli_id_str, new_client->cli_id, =
poolid);
     pool->pool_id =3D poolid;
 }
@@ -1173,7 +1173,7 @@ static NOINLINE int shared_pool_quit(poo
             }
         return 0;
     }
-    printk("tmem: no match unsharing pool, %s=3D%d\n",
+    tmh_client_warn("tmem: no match unsharing pool, %s=3D%d\n",
         cli_id_str,pool->client->cli_id);
     return -1;
 }
@@ -1184,17 +1184,18 @@ static void pool_flush(pool_t *pool, cli
     ASSERT(pool !=3D NULL);
     if ( (is_shared(pool)) && (shared_pool_quit(pool,cli_id) > 0) )
     {
-        printk("tmem: %s=3D%d no longer using shared pool %d owned by =
%s=3D%d\n",
+        tmh_client_warn("tmem: %s=3D%d no longer using shared pool %d =
owned by %s=3D%d\n",
            cli_id_str, cli_id, pool->pool_id, cli_id_str,pool->client->cli=
_id);
         return;
     }
-    printk("%s %s-%s tmem pool ",destroy?"destroying":"flushing",
-        is_persistent(pool) ? "persistent" : "ephemeral" ,
-        is_shared(pool) ? "shared" : "private");
-    printk("%s=3D%d pool_id=3D%d\n", cli_id_str,pool->client->cli_id,pool-=
>pool_id);
+    tmh_client_info("%s %s-%s tmem pool %s=3D%d pool_id=3D%d\n",
+                    destroy ? "destroying" : "flushing",
+                    is_persistent(pool) ? "persistent" : "ephemeral" ,
+                    is_shared(pool) ? "shared" : "private",
+                    cli_id_str, pool->client->cli_id, pool->pool_id);
     if ( pool->client->live_migrating )
     {
-        printk("can't %s pool while %s is live-migrating\n",
+        tmh_client_warn("can't %s pool while %s is live-migrating\n",
                destroy?"destroy":"flush", client_str);
         return;
     }
@@ -1213,21 +1214,22 @@ static client_t *client_create(cli_id_t=20
     client_t *client =3D tmh_alloc_infra(sizeof(client_t),__alignof__(clie=
nt_t));
     int i;
=20
-    printk("tmem: initializing tmem capability for %s=3D%d...",cli_id_str,=
cli_id);
+    tmh_client_info("tmem: initializing tmem capability for %s=3D%d...",
+                    cli_id_str, cli_id);
     if ( client =3D=3D NULL )
     {
-        printk("failed... out of memory\n");
+        tmh_client_err("failed... out of memory\n");
         goto fail;
     }
     memset(client,0,sizeof(client_t));
     if ( (client->tmh =3D tmh_client_init(cli_id)) =3D=3D NULL )
     {
-        printk("failed... can't allocate host-dependent part of client\n")=
;
+        tmh_client_err("failed... can't allocate host-dependent part of =
client\n");
         goto fail;
     }
     if ( !tmh_set_client_from_id(client, client->tmh, cli_id) )
     {
-        printk("failed... can't set client\n");
+        tmh_client_err("failed... can't set client\n");
         goto fail;
     }
     client->cli_id =3D cli_id;
@@ -1249,7 +1251,7 @@ static client_t *client_create(cli_id_t=20
     client->eph_count =3D client->eph_count_max =3D 0;
     client->total_cycles =3D 0; client->succ_pers_puts =3D 0;
     client->succ_eph_gets =3D 0; client->succ_pers_gets =3D 0;
-    printk("ok\n");
+    tmh_client_info("ok\n");
     return client;
=20
  fail:
@@ -1903,32 +1905,33 @@ static NOINLINE int do_tmem_new_pool(cli
         cli_id =3D tmh_get_cli_id_from_current();
     else
         cli_id =3D this_cli_id;
-    printk("tmem: allocating %s-%s tmem pool for %s=3D%d...",
+    tmh_client_info("tmem: allocating %s-%s tmem pool for %s=3D%d...",
         persistent ? "persistent" : "ephemeral" ,
         shared ? "shared" : "private", cli_id_str, cli_id);
     if ( specversion !=3D TMEM_SPEC_VERSION )
     {
-        printk("failed... unsupported spec version\n");
+        tmh_client_err("failed... unsupported spec version\n");
         return -EPERM;
     }
     if ( pagebits !=3D (PAGE_SHIFT - 12) )
     {
-        printk("failed... unsupported pagesize %d\n",1<<(pagebits+12));
+        tmh_client_err("failed... unsupported pagesize %d\n",
+                       1 << (pagebits + 12));
         return -EPERM;
     }
     if ( flags & TMEM_POOL_PRECOMPRESSED )
     {
-        printk("failed... precompression flag set but unsupported\n");
+        tmh_client_err("failed... precompression flag set but unsupported\=
n");
         return -EPERM;
     }
     if ( flags & TMEM_POOL_RESERVED_BITS )
     {
-        printk("failed... reserved bits must be zero\n");
+        tmh_client_err("failed... reserved bits must be zero\n");
         return -EPERM;
     }
     if ( (pool =3D pool_alloc()) =3D=3D NULL )
     {
-        printk("failed... out of memory\n");
+        tmh_client_err("failed... out of memory\n");
         return -ENOMEM;
     }
     if ( this_cli_id !=3D CLI_ID_NULL )
@@ -1947,7 +1950,7 @@ static NOINLINE int do_tmem_new_pool(cli
                 break;
         if ( d_poolid >=3D MAX_POOLS_PER_DOMAIN )
         {
-            printk("failed... no more pool slots available for this =
%s\n",
+            tmh_client_err("failed... no more pool slots available for =
this %s\n",
                    client_str);
             goto fail;
         }
@@ -1977,9 +1980,8 @@ static NOINLINE int do_tmem_new_pool(cli
             {
                 if ( shpool->uuid[0] =3D=3D uuid_lo && shpool->uuid[1] =
=3D=3D uuid_hi )
                 {
-                    printk("(matches shared pool uuid=3D%"PRIx64".%"PRIx64=
") ",
-                        uuid_hi, uuid_lo);
-                    printk("pool_id=3D%d\n",d_poolid);
+                    tmh_client_info("(matches shared pool uuid=3D%"PRIx64"=
.%"PRIx64") pool_id=3D%d\n",
+                        uuid_hi, uuid_lo, d_poolid);
                     client->pools[d_poolid] =3D global_shared_pools[s_pool=
id];
                     shared_pool_join(global_shared_pools[s_poolid], =
client);
                     pool_free(pool);
@@ -1991,7 +1993,7 @@ static NOINLINE int do_tmem_new_pool(cli
         }
         if ( first_unused_s_poolid =3D=3D MAX_GLOBAL_SHARED_POOLS )
         {
-            printk("tmem: failed... no global shared pool slots available\=
n");
+            tmh_client_warn("tmem: failed... no global shared pool slots =
available\n");
             goto fail;
         }
         else
@@ -2007,7 +2009,7 @@ static NOINLINE int do_tmem_new_pool(cli
     pool->pool_id =3D d_poolid;
     pool->persistent =3D persistent;
     pool->uuid[0] =3D uuid_lo; pool->uuid[1] =3D uuid_hi;
-    printk("pool_id=3D%d\n",d_poolid);
+    tmh_client_info("pool_id=3D%d\n", d_poolid);
     return d_poolid;
=20
 fail:
@@ -2030,14 +2032,15 @@ static int tmemc_freeze_pools(cli_id_t c
     {
         list_for_each_entry(client,&global_client_list,client_list)
             client_freeze(client,freeze);
-        printk("tmem: all pools %s for all %ss\n",s,client_str);
+        tmh_client_info("tmem: all pools %s for all %ss\n", s, client_str)=
;
     }
     else
     {
         if ( (client =3D tmh_client_from_cli_id(cli_id)) =3D=3D NULL)
             return -1;
         client_freeze(client,freeze);
-        printk("tmem: all pools %s for %s=3D%d\n",s,cli_id_str,cli_id);
+        tmh_client_info("tmem: all pools %s for %s=3D%d\n",
+                         s, cli_id_str, cli_id);
     }
     return 0;
 }
@@ -2048,7 +2051,7 @@ static int tmemc_flush_mem(cli_id_t cli_
=20
     if ( cli_id !=3D CLI_ID_NULL )
     {
-        printk("tmem: %s-specific flush not supported yet, use --all\n",
+        tmh_client_warn("tmem: %s-specific flush not supported yet, use =
--all\n",
            client_str);
         return -1;
     }
@@ -2261,13 +2264,15 @@ static int tmemc_set_var_one(client_t *c
     case TMEMC_SET_WEIGHT:
         old_weight =3D client->weight;
         client->weight =3D arg1;
-        printk("tmem: weight set to %d for %s=3D%d\n",arg1,cli_id_str,cli_=
id);
+        tmh_client_info("tmem: weight set to %d for %s=3D%d\n",
+                        arg1, cli_id_str, cli_id);
         atomic_sub(old_weight,&client_weight_total);
         atomic_add(client->weight,&client_weight_total);
         break;
     case TMEMC_SET_CAP:
         client->cap =3D arg1;
-        printk("tmem: cap set to %d for %s=3D%d\n",arg1,cli_id_str,cli_id)=
;
+        tmh_client_info("tmem: cap set to %d for %s=3D%d\n",
+                        arg1, cli_id_str, cli_id);
         break;
     case TMEMC_SET_COMPRESS:
 #ifdef __i386__
@@ -2275,17 +2280,17 @@ static int tmemc_set_var_one(client_t *c
 #endif
         if ( tmh_dedup_enabled() )
         {
-            printk("tmem: compression %s for all %ss, cannot be changed "
-                   "when tmem_dedup is enabled\n",
-            tmh_compression_enabled() ? "enabled" : "disabled",client_str)=
;
+            tmh_client_warn("tmem: compression %s for all %ss, cannot be =
changed when tmem_dedup is enabled\n",
+                            tmh_compression_enabled() ? "enabled" : =
"disabled",
+                            client_str);
             return -1;
         }
         client->compress =3D arg1 ? 1 : 0;
-        printk("tmem: compression %s for %s=3D%d\n",
+        tmh_client_info("tmem: compression %s for %s=3D%d\n",
             arg1 ? "enabled" : "disabled",cli_id_str,cli_id);
         break;
     default:
-        printk("tmem: unknown subop %d for tmemc_set_var\n",subop);
+        tmh_client_warn("tmem: unknown subop %d for tmemc_set_var\n", =
subop);
         return -1;
     }
     return 0;
@@ -2668,7 +2673,7 @@ EXPORT long do_tmem_op(tmem_cli_op_t uop
=20
     if ( unlikely(tmh_get_tmemop_from_client(&op, uops) !=3D 0) )
     {
-        printk("tmem: can't get tmem struct from %s\n",client_str);
+        tmh_client_err("tmem: can't get tmem struct from %s\n", client_str=
);
         rc =3D -EFAULT;
         if ( !tmh_lock_all )
             goto simple_error;
@@ -2702,7 +2707,8 @@ EXPORT long do_tmem_op(tmem_cli_op_t uop
         tmem_write_lock_set =3D 1;
         if ( (client =3D client_create(tmh_get_cli_id_from_current())) =
=3D=3D NULL )
         {
-            printk("tmem: can't create tmem structure for %s\n",client_str=
);
+            tmh_client_err("tmem: can't create tmem structure for %s\n",
+                           client_str);
             rc =3D -ENOMEM;
             goto out;
         }
@@ -2726,8 +2732,8 @@ EXPORT long do_tmem_op(tmem_cli_op_t uop
         if ( ((uint32_t)op.pool_id >=3D MAX_POOLS_PER_DOMAIN) ||
              ((pool =3D client->pools[op.pool_id]) =3D=3D NULL) )
         {
+            tmh_client_err("tmem: operation requested on uncreated =
pool\n");
             rc =3D -ENODEV;
-            printk("tmem: operation requested on uncreated pool\n");
             goto out;
         }
         ASSERT_SENTINEL(pool,POOL);
@@ -2783,11 +2789,11 @@ EXPORT long do_tmem_op(tmem_cli_op_t uop
         break;
     case TMEM_XCHG:
         /* need to hold global lock to ensure xchg is atomic */
-        printk("tmem_xchg op not implemented yet\n");
+        tmh_client_warn("tmem_xchg op not implemented yet\n");
         rc =3D 0;
         break;
     default:
-        printk("tmem: op %d not implemented\n", op.cmd);
+        tmh_client_warn("tmem: op %d not implemented\n", op.cmd);
         rc =3D 0;
         break;
     }
--- a/xen/include/xen/tmem_xen.h
+++ b/xen/include/xen/tmem_xen.h
@@ -512,6 +512,9 @@ int tmh_copy_to_client(tmem_cli_mfn_t, p
=20
 extern int tmh_copy_tze_to_client(tmem_cli_mfn_t cmfn, void *tmem_va, =
pagesize_t len);
=20
+#define tmh_client_err(fmt, args...)  printk(XENLOG_G_ERR fmt, ##args)
+#define tmh_client_warn(fmt, args...) printk(XENLOG_G_WARNING fmt, =
##args)
+#define tmh_client_info(fmt, args...) printk(XENLOG_G_INFO fmt, ##args)
=20
 #define TMEM_PERF
 #ifdef TMEM_PERF



--=__PartDDECC949.1__=
Content-Type: text/plain; name="tmem-xsa-15-9.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="tmem-xsa-15-9.patch"

tmem: reduce severity of log messages=0A=0AOtherwise they can be used by a =
guest to spam the hypervisor log when=0Aall settings are at their =
defaults.=0A=0ASigned-off-by: Jan Beulich <jbeulich@suse.com>=0A---=0Av2: =
As suggested by Ian, use separate abstraction for messages printed=0A    =
in result of client side operations (so that e.g. the init time=0A    =
system messages don't also get converted to guest level ones).=0A=0A--- =
a/xen/common/tmem.c=0A+++ b/xen/common/tmem.c=0A@@ -1107,7 +1107,7 @@ =
static int shared_pool_join(pool_t *pool=0A     sl->client =3D new_client;=
=0A     list_add_tail(&sl->share_list, &pool->share_list);=0A     if ( =
new_client->cli_id !=3D pool->client->cli_id )=0A-        printk("adding =
new %s %d to shared pool owned by %s %d\n",=0A+        tmh_client_info("add=
ing new %s %d to shared pool owned by %s %d\n",=0A             client_str, =
new_client->cli_id, client_str, pool->client->cli_id);=0A     return =
++pool->shared_count;=0A }=0A@@ -1137,7 +1137,7 @@ static NOINLINE void =
shared_pool_reassig=0A     old_client->eph_count -=3D _atomic_read(pool->pg=
p_count);=0A     list_splice_init(&old_client->ephemeral_page_list,=0A     =
                 &new_client->ephemeral_page_list);=0A-    printk("reassign=
ed shared pool from %s=3D%d to %s=3D%d pool_id=3D%d\n",=0A+    tmh_client_i=
nfo("reassigned shared pool from %s=3D%d to %s=3D%d pool_id=3D%d\n",=0A    =
     cli_id_str, old_client->cli_id, cli_id_str, new_client->cli_id, =
poolid);=0A     pool->pool_id =3D poolid;=0A }=0A@@ -1173,7 +1173,7 @@ =
static NOINLINE int shared_pool_quit(poo=0A             }=0A         =
return 0;=0A     }=0A-    printk("tmem: no match unsharing pool, %s=3D%d\n"=
,=0A+    tmh_client_warn("tmem: no match unsharing pool, %s=3D%d\n",=0A    =
     cli_id_str,pool->client->cli_id);=0A     return -1;=0A }=0A@@ =
-1184,17 +1184,18 @@ static void pool_flush(pool_t *pool, cli=0A     =
ASSERT(pool !=3D NULL);=0A     if ( (is_shared(pool)) && (shared_pool_quit(=
pool,cli_id) > 0) )=0A     {=0A-        printk("tmem: %s=3D%d no longer =
using shared pool %d owned by %s=3D%d\n",=0A+        tmh_client_warn("tmem:=
 %s=3D%d no longer using shared pool %d owned by %s=3D%d\n",=0A            =
cli_id_str, cli_id, pool->pool_id, cli_id_str,pool->client->cli_id);=0A    =
     return;=0A     }=0A-    printk("%s %s-%s tmem pool ",destroy?"destroyi=
ng":"flushing",=0A-        is_persistent(pool) ? "persistent" : "ephemeral"=
 ,=0A-        is_shared(pool) ? "shared" : "private");=0A-    printk("%s=3D=
%d pool_id=3D%d\n", cli_id_str,pool->client->cli_id,pool->pool_id);=0A+    =
tmh_client_info("%s %s-%s tmem pool %s=3D%d pool_id=3D%d\n",=0A+           =
         destroy ? "destroying" : "flushing",=0A+                    =
is_persistent(pool) ? "persistent" : "ephemeral" ,=0A+                    =
is_shared(pool) ? "shared" : "private",=0A+                    cli_id_str, =
pool->client->cli_id, pool->pool_id);=0A     if ( pool->client->live_migrat=
ing )=0A     {=0A-        printk("can't %s pool while %s is live-migrating\=
n",=0A+        tmh_client_warn("can't %s pool while %s is live-migrating\n"=
,=0A                destroy?"destroy":"flush", client_str);=0A         =
return;=0A     }=0A@@ -1213,21 +1214,22 @@ static client_t *client_create(c=
li_id_t =0A     client_t *client =3D tmh_alloc_infra(sizeof(client_t),__ali=
gnof__(client_t));=0A     int i;=0A =0A-    printk("tmem: initializing =
tmem capability for %s=3D%d...",cli_id_str,cli_id);=0A+    tmh_client_info(=
"tmem: initializing tmem capability for %s=3D%d...",=0A+                   =
 cli_id_str, cli_id);=0A     if ( client =3D=3D NULL )=0A     {=0A-        =
printk("failed... out of memory\n");=0A+        tmh_client_err("failed... =
out of memory\n");=0A         goto fail;=0A     }=0A     memset(client,0,si=
zeof(client_t));=0A     if ( (client->tmh =3D tmh_client_init(cli_id)) =
=3D=3D NULL )=0A     {=0A-        printk("failed... can't allocate =
host-dependent part of client\n");=0A+        tmh_client_err("failed... =
can't allocate host-dependent part of client\n");=0A         goto fail;=0A =
    }=0A     if ( !tmh_set_client_from_id(client, client->tmh, cli_id) =
)=0A     {=0A-        printk("failed... can't set client\n");=0A+        =
tmh_client_err("failed... can't set client\n");=0A         goto fail;=0A   =
  }=0A     client->cli_id =3D cli_id;=0A@@ -1249,7 +1251,7 @@ static =
client_t *client_create(cli_id_t =0A     client->eph_count =3D client->eph_=
count_max =3D 0;=0A     client->total_cycles =3D 0; client->succ_pers_puts =
=3D 0;=0A     client->succ_eph_gets =3D 0; client->succ_pers_gets =3D =
0;=0A-    printk("ok\n");=0A+    tmh_client_info("ok\n");=0A     return =
client;=0A =0A  fail:=0A@@ -1903,32 +1905,33 @@ static NOINLINE int =
do_tmem_new_pool(cli=0A         cli_id =3D tmh_get_cli_id_from_current();=
=0A     else=0A         cli_id =3D this_cli_id;=0A-    printk("tmem: =
allocating %s-%s tmem pool for %s=3D%d...",=0A+    tmh_client_info("tmem: =
allocating %s-%s tmem pool for %s=3D%d...",=0A         persistent ? =
"persistent" : "ephemeral" ,=0A         shared ? "shared" : "private", =
cli_id_str, cli_id);=0A     if ( specversion !=3D TMEM_SPEC_VERSION )=0A   =
  {=0A-        printk("failed... unsupported spec version\n");=0A+        =
tmh_client_err("failed... unsupported spec version\n");=0A         return =
-EPERM;=0A     }=0A     if ( pagebits !=3D (PAGE_SHIFT - 12) )=0A     =
{=0A-        printk("failed... unsupported pagesize %d\n",1<<(pagebits+12))=
;=0A+        tmh_client_err("failed... unsupported pagesize %d\n",=0A+     =
                  1 << (pagebits + 12));=0A         return -EPERM;=0A     =
}=0A     if ( flags & TMEM_POOL_PRECOMPRESSED )=0A     {=0A-        =
printk("failed... precompression flag set but unsupported\n");=0A+        =
tmh_client_err("failed... precompression flag set but unsupported\n");=0A  =
       return -EPERM;=0A     }=0A     if ( flags & TMEM_POOL_RESERVED_BITS =
)=0A     {=0A-        printk("failed... reserved bits must be zero\n");=0A+=
        tmh_client_err("failed... reserved bits must be zero\n");=0A       =
  return -EPERM;=0A     }=0A     if ( (pool =3D pool_alloc()) =3D=3D NULL =
)=0A     {=0A-        printk("failed... out of memory\n");=0A+        =
tmh_client_err("failed... out of memory\n");=0A         return -ENOMEM;=0A =
    }=0A     if ( this_cli_id !=3D CLI_ID_NULL )=0A@@ -1947,7 +1950,7 @@ =
static NOINLINE int do_tmem_new_pool(cli=0A                 break;=0A      =
   if ( d_poolid >=3D MAX_POOLS_PER_DOMAIN )=0A         {=0A-            =
printk("failed... no more pool slots available for this %s\n",=0A+         =
   tmh_client_err("failed... no more pool slots available for this =
%s\n",=0A                    client_str);=0A             goto fail;=0A     =
    }=0A@@ -1977,9 +1980,8 @@ static NOINLINE int do_tmem_new_pool(cli=0A  =
           {=0A                 if ( shpool->uuid[0] =3D=3D uuid_lo && =
shpool->uuid[1] =3D=3D uuid_hi )=0A                 {=0A-                  =
  printk("(matches shared pool uuid=3D%"PRIx64".%"PRIx64") ",=0A-          =
              uuid_hi, uuid_lo);=0A-                    printk("pool_id=3D%=
d\n",d_poolid);=0A+                    tmh_client_info("(matches shared =
pool uuid=3D%"PRIx64".%"PRIx64") pool_id=3D%d\n",=0A+                      =
  uuid_hi, uuid_lo, d_poolid);=0A                     client->pools[d_pooli=
d] =3D global_shared_pools[s_poolid];=0A                     shared_pool_jo=
in(global_shared_pools[s_poolid], client);=0A                     =
pool_free(pool);=0A@@ -1991,7 +1993,7 @@ static NOINLINE int do_tmem_new_po=
ol(cli=0A         }=0A         if ( first_unused_s_poolid =3D=3D MAX_GLOBAL=
_SHARED_POOLS )=0A         {=0A-            printk("tmem: failed... no =
global shared pool slots available\n");=0A+            tmh_client_warn("tme=
m: failed... no global shared pool slots available\n");=0A             =
goto fail;=0A         }=0A         else=0A@@ -2007,7 +2009,7 @@ static =
NOINLINE int do_tmem_new_pool(cli=0A     pool->pool_id =3D d_poolid;=0A    =
 pool->persistent =3D persistent;=0A     pool->uuid[0] =3D uuid_lo; =
pool->uuid[1] =3D uuid_hi;=0A-    printk("pool_id=3D%d\n",d_poolid);=0A+   =
 tmh_client_info("pool_id=3D%d\n", d_poolid);=0A     return d_poolid;=0A =
=0A fail:=0A@@ -2030,14 +2032,15 @@ static int tmemc_freeze_pools(cli_id_t =
c=0A     {=0A         list_for_each_entry(client,&global_client_list,client=
_list)=0A             client_freeze(client,freeze);=0A-        printk("tmem=
: all pools %s for all %ss\n",s,client_str);=0A+        tmh_client_info("tm=
em: all pools %s for all %ss\n", s, client_str);=0A     }=0A     else=0A   =
  {=0A         if ( (client =3D tmh_client_from_cli_id(cli_id)) =3D=3D =
NULL)=0A             return -1;=0A         client_freeze(client,freeze);=0A=
-        printk("tmem: all pools %s for %s=3D%d\n",s,cli_id_str,cli_id);=0A=
+        tmh_client_info("tmem: all pools %s for %s=3D%d\n",=0A+           =
              s, cli_id_str, cli_id);=0A     }=0A     return 0;=0A }=0A@@ =
-2048,7 +2051,7 @@ static int tmemc_flush_mem(cli_id_t cli_=0A =0A     if =
( cli_id !=3D CLI_ID_NULL )=0A     {=0A-        printk("tmem: %s-specific =
flush not supported yet, use --all\n",=0A+        tmh_client_warn("tmem: =
%s-specific flush not supported yet, use --all\n",=0A            client_str=
);=0A         return -1;=0A     }=0A@@ -2261,13 +2264,15 @@ static int =
tmemc_set_var_one(client_t *c=0A     case TMEMC_SET_WEIGHT:=0A         =
old_weight =3D client->weight;=0A         client->weight =3D arg1;=0A-     =
   printk("tmem: weight set to %d for %s=3D%d\n",arg1,cli_id_str,cli_id);=
=0A+        tmh_client_info("tmem: weight set to %d for %s=3D%d\n",=0A+    =
                    arg1, cli_id_str, cli_id);=0A         atomic_sub(old_we=
ight,&client_weight_total);=0A         atomic_add(client->weight,&client_we=
ight_total);=0A         break;=0A     case TMEMC_SET_CAP:=0A         =
client->cap =3D arg1;=0A-        printk("tmem: cap set to %d for %s=3D%d\n"=
,arg1,cli_id_str,cli_id);=0A+        tmh_client_info("tmem: cap set to %d =
for %s=3D%d\n",=0A+                        arg1, cli_id_str, cli_id);=0A   =
      break;=0A     case TMEMC_SET_COMPRESS:=0A #ifdef __i386__=0A@@ =
-2275,17 +2280,17 @@ static int tmemc_set_var_one(client_t *c=0A #endif=0A =
        if ( tmh_dedup_enabled() )=0A         {=0A-            printk("tmem=
: compression %s for all %ss, cannot be changed "=0A-                   =
"when tmem_dedup is enabled\n",=0A-            tmh_compression_enabled() ? =
"enabled" : "disabled",client_str);=0A+            tmh_client_warn("tmem: =
compression %s for all %ss, cannot be changed when tmem_dedup is enabled\n"=
,=0A+                            tmh_compression_enabled() ? "enabled" : =
"disabled",=0A+                            client_str);=0A             =
return -1;=0A         }=0A         client->compress =3D arg1 ? 1 : 0;=0A-  =
      printk("tmem: compression %s for %s=3D%d\n",=0A+        tmh_client_in=
fo("tmem: compression %s for %s=3D%d\n",=0A             arg1 ? "enabled" : =
"disabled",cli_id_str,cli_id);=0A         break;=0A     default:=0A-       =
 printk("tmem: unknown subop %d for tmemc_set_var\n",subop);=0A+        =
tmh_client_warn("tmem: unknown subop %d for tmemc_set_var\n", subop);=0A   =
      return -1;=0A     }=0A     return 0;=0A@@ -2668,7 +2673,7 @@ EXPORT =
long do_tmem_op(tmem_cli_op_t uop=0A =0A     if ( unlikely(tmh_get_tmemop_f=
rom_client(&op, uops) !=3D 0) )=0A     {=0A-        printk("tmem: can't =
get tmem struct from %s\n",client_str);=0A+        tmh_client_err("tmem: =
can't get tmem struct from %s\n", client_str);=0A         rc =3D =
-EFAULT;=0A         if ( !tmh_lock_all )=0A             goto simple_error;=
=0A@@ -2702,7 +2707,8 @@ EXPORT long do_tmem_op(tmem_cli_op_t uop=0A       =
  tmem_write_lock_set =3D 1;=0A         if ( (client =3D client_create(tmh_=
get_cli_id_from_current())) =3D=3D NULL )=0A         {=0A-            =
printk("tmem: can't create tmem structure for %s\n",client_str);=0A+       =
     tmh_client_err("tmem: can't create tmem structure for %s\n",=0A+      =
                     client_str);=0A             rc =3D -ENOMEM;=0A        =
     goto out;=0A         }=0A@@ -2726,8 +2732,8 @@ EXPORT long do_tmem_op(=
tmem_cli_op_t uop=0A         if ( ((uint32_t)op.pool_id >=3D MAX_POOLS_PER_=
DOMAIN) ||=0A              ((pool =3D client->pools[op.pool_id]) =3D=3D =
NULL) )=0A         {=0A+            tmh_client_err("tmem: operation =
requested on uncreated pool\n");=0A             rc =3D -ENODEV;=0A-        =
    printk("tmem: operation requested on uncreated pool\n");=0A            =
 goto out;=0A         }=0A         ASSERT_SENTINEL(pool,POOL);=0A@@ =
-2783,11 +2789,11 @@ EXPORT long do_tmem_op(tmem_cli_op_t uop=0A         =
break;=0A     case TMEM_XCHG:=0A         /* need to hold global lock to =
ensure xchg is atomic */=0A-        printk("tmem_xchg op not implemented =
yet\n");=0A+        tmh_client_warn("tmem_xchg op not implemented =
yet\n");=0A         rc =3D 0;=0A         break;=0A     default:=0A-        =
printk("tmem: op %d not implemented\n", op.cmd);=0A+        tmh_client_warn=
("tmem: op %d not implemented\n", op.cmd);=0A         rc =3D 0;=0A         =
break;=0A     }=0A--- a/xen/include/xen/tmem_xen.h=0A+++ b/xen/include/xen/=
tmem_xen.h=0A@@ -512,6 +512,9 @@ int tmh_copy_to_client(tmem_cli_mfn_t, =
p=0A =0A extern int tmh_copy_tze_to_client(tmem_cli_mfn_t cmfn, void =
*tmem_va, pagesize_t len);=0A =0A+#define tmh_client_err(fmt, args...)  =
printk(XENLOG_G_ERR fmt, ##args)=0A+#define tmh_client_warn(fmt, args...) =
printk(XENLOG_G_WARNING fmt, ##args)=0A+#define tmh_client_info(fmt, =
args...) printk(XENLOG_G_INFO fmt, ##args)=0A =0A #define TMEM_PERF=0A =
#ifdef TMEM_PERF=0A
--=__PartDDECC949.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

--=__PartDDECC949.1__=--


From xen-devel-bounces@lists.xen.org Fri Sep 07 12:19:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Sep 2012 12:19:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9xWG-0003Fm-39; Fri, 07 Sep 2012 12:18: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 1T9xWF-0003Fd-43
	for xen-devel@lists.xen.org; Fri, 07 Sep 2012 12:18:43 +0000
Received: from [85.158.143.35:58734] by server-2.bemta-4.messagelabs.com id
	1B/8B-21239-226E9405; Fri, 07 Sep 2012 12:18:42 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1347020279!11642364!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM4ODU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8937 invoked from network); 7 Sep 2012 12:17:59 -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;
	7 Sep 2012 12:17:59 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 07 Sep 2012 13:17:59 +0100
Message-Id: <504A024E0200007800099C5A@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 07 Sep 2012 13:18:54 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ben Guthro" <ben@guthro.net>
References: <CAOvdn6WwgBD-2yf1uu3m9-16=Tb5KUrybXf2KibtnxKbP7YtwA@mail.gmail.com>
	<CAOvdn6UBW-yTOMd3YSf5M9JiHLRivyaKL-qzcKG8epszqaKmGg@mail.gmail.com>
	<20120807163320.GC15053@phenom.dumpdata.com>
	<CAOvdn6XcRGKtJxGwJO8J+ZBJr89wfTLc1woW5rhtMM540H9h1w@mail.gmail.com>
	<CAOvdn6XUoSeGoo7X=AJ1kpDxZB9HZEv+TJ4v-=FHcyR4=CHK-w@mail.gmail.com>
	<502240F302000078000937A6@nat28.tlf.novell.com>
	<CAOvdn6WN3kxC8Bb9g6MpfLULu47EGSGCtajPc-SFeJ-8VSUQDQ@mail.gmail.com>
	<CAOvdn6Xk1inm1hU55i0phU2qvSWyJLNoyDdn43biBAY2OewPtw@mail.gmail.com>
	<5023F5400200007800093F4E@nat28.tlf.novell.com>
	<CAOvdn6U-f3C4U8xVPvDyRFkFFLkbfiCXg_n+9zgA9V5u+q5jfw@mail.gmail.com>
	<5023F8B80200007800093F8C@nat28.tlf.novell.com>
	<CAOvdn6XKHfete_+=Hkvt20G7_cJ-4i8+9j9YD30OxzQ16Ru-+g@mail.gmail.com>
	<5024CB720200007800094124@nat28.tlf.novell.com>
	<CAOvdn6VVJdhWVYa-gNVt3euE4AbGi1TijUCUd1wGzv0SCWEUYA@mail.gmail.com>
	<CAOvdn6USnG9Y4MNBhrDZmob0oJ8BgFfKTvFEhcKbXDxNmzfZ-Q@mail.gmail.com>
	<502B75BA0200007800094FD4@nat28.tlf.novell.com>
	<CAOvdn6Ww5oEj6Xg=XT4dWCYWUBuOdPqLz-CqNjz4HmCScE+==g@mail.gmail.com>
	<CAOvdn6Wsjds_dmZ0dwDTYmD-o-OqjBH5-b9mitAuUADE+A4_ag@mail.gmail.com>
	<502BB8FD02000078000951E0@nat28.tlf.novell.com>
	<CAOvdn6VD6bp13F-tvYdkBsj4hkhE7PTGZrapndtdHrDKeZqccg@mail.gmail.com>
	<502CCC0002000078000955C4@nat28.tlf.novell.com>
	<CAOvdn6VEuX7R2_wz74ZvCxMjC-=YUir9kP5sdxEVaKVspRUd_w@mail.gmail.com>
	<502CF0A8020000780009574E@nat28.tlf.novell.com>
	<CAOvdn6VsZvn_1TCWYeuyY5YuTcP8=miK2KwE4583nsj6Qjb_vg@mail.gmail.com>
	<504494FB0200007800098398@nat28.tlf.novell.com>
	<CAOvdn6UT13qvWbMyfZkWND03RoVKVSgb6wW4yqTUpuBYEX01Dg@mail.gmail.com>
	<5048958D02000078000993EB@nat28.tlf.novell.com>
	<CAOvdn6WrNK1Jn_Y_P7C3AwX6ApVcgzacLA_x-u=xBQtebnuPxA@mail.gmail.com>
	<CAOvdn6U_Z=KdEo56nqe7jN54BwiesRJqDOz_VzVNpkWGfFRd2A@mail.gmail.com>
	<5049CEAE0200007800099A33@nat28.tlf.novell.com>
	<CAOvdn6XmsEfs+aO7nqBHdA61HpT_n_8W95u0MMq5J21tZCFbzw@mail.gmail.com>
	<5049F37A0200007800099BDA@nat28.tlf.novell.com>
	<CAOvdn6W+=OYTH3xTWBxUB8f_2tuZYKPTo-eJG0jfkaJ2rVutCA@mail.gmail.com>
In-Reply-To: <CAOvdn6W+=OYTH3xTWBxUB8f_2tuZYKPTo-eJG0jfkaJ2rVutCA@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>, john.baboval@citrix.com,
	Thomas Goetz <thomas.goetz@citrix.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen4.2 S3 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 07.09.12 at 13:51, Ben Guthro <ben@guthro.net> wrote:
> However, when I run with console=none, the observed behavior is very 
> different.
> The system seems to go to sleep successfully - but when I press the
> power button to wake it up - the power comes on - the fans spin up -
> but the system is unresponsive.
> No video
> No network
> keyboard LEDs (Caps,Numlock) do not light up.
> 
> 
> Alternate debugging strategies welcome.

I'm afraid other than being lucky to spot something via code
inspection, the only alternative is an ITP/ICE. Maybe Intel folks
could help out debugging this if it's reproducible for them.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 07 12:19:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Sep 2012 12:19:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9xWG-0003Fm-39; Fri, 07 Sep 2012 12:18: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 1T9xWF-0003Fd-43
	for xen-devel@lists.xen.org; Fri, 07 Sep 2012 12:18:43 +0000
Received: from [85.158.143.35:58734] by server-2.bemta-4.messagelabs.com id
	1B/8B-21239-226E9405; Fri, 07 Sep 2012 12:18:42 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1347020279!11642364!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM4ODU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8937 invoked from network); 7 Sep 2012 12:17:59 -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;
	7 Sep 2012 12:17:59 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 07 Sep 2012 13:17:59 +0100
Message-Id: <504A024E0200007800099C5A@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 07 Sep 2012 13:18:54 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ben Guthro" <ben@guthro.net>
References: <CAOvdn6WwgBD-2yf1uu3m9-16=Tb5KUrybXf2KibtnxKbP7YtwA@mail.gmail.com>
	<CAOvdn6UBW-yTOMd3YSf5M9JiHLRivyaKL-qzcKG8epszqaKmGg@mail.gmail.com>
	<20120807163320.GC15053@phenom.dumpdata.com>
	<CAOvdn6XcRGKtJxGwJO8J+ZBJr89wfTLc1woW5rhtMM540H9h1w@mail.gmail.com>
	<CAOvdn6XUoSeGoo7X=AJ1kpDxZB9HZEv+TJ4v-=FHcyR4=CHK-w@mail.gmail.com>
	<502240F302000078000937A6@nat28.tlf.novell.com>
	<CAOvdn6WN3kxC8Bb9g6MpfLULu47EGSGCtajPc-SFeJ-8VSUQDQ@mail.gmail.com>
	<CAOvdn6Xk1inm1hU55i0phU2qvSWyJLNoyDdn43biBAY2OewPtw@mail.gmail.com>
	<5023F5400200007800093F4E@nat28.tlf.novell.com>
	<CAOvdn6U-f3C4U8xVPvDyRFkFFLkbfiCXg_n+9zgA9V5u+q5jfw@mail.gmail.com>
	<5023F8B80200007800093F8C@nat28.tlf.novell.com>
	<CAOvdn6XKHfete_+=Hkvt20G7_cJ-4i8+9j9YD30OxzQ16Ru-+g@mail.gmail.com>
	<5024CB720200007800094124@nat28.tlf.novell.com>
	<CAOvdn6VVJdhWVYa-gNVt3euE4AbGi1TijUCUd1wGzv0SCWEUYA@mail.gmail.com>
	<CAOvdn6USnG9Y4MNBhrDZmob0oJ8BgFfKTvFEhcKbXDxNmzfZ-Q@mail.gmail.com>
	<502B75BA0200007800094FD4@nat28.tlf.novell.com>
	<CAOvdn6Ww5oEj6Xg=XT4dWCYWUBuOdPqLz-CqNjz4HmCScE+==g@mail.gmail.com>
	<CAOvdn6Wsjds_dmZ0dwDTYmD-o-OqjBH5-b9mitAuUADE+A4_ag@mail.gmail.com>
	<502BB8FD02000078000951E0@nat28.tlf.novell.com>
	<CAOvdn6VD6bp13F-tvYdkBsj4hkhE7PTGZrapndtdHrDKeZqccg@mail.gmail.com>
	<502CCC0002000078000955C4@nat28.tlf.novell.com>
	<CAOvdn6VEuX7R2_wz74ZvCxMjC-=YUir9kP5sdxEVaKVspRUd_w@mail.gmail.com>
	<502CF0A8020000780009574E@nat28.tlf.novell.com>
	<CAOvdn6VsZvn_1TCWYeuyY5YuTcP8=miK2KwE4583nsj6Qjb_vg@mail.gmail.com>
	<504494FB0200007800098398@nat28.tlf.novell.com>
	<CAOvdn6UT13qvWbMyfZkWND03RoVKVSgb6wW4yqTUpuBYEX01Dg@mail.gmail.com>
	<5048958D02000078000993EB@nat28.tlf.novell.com>
	<CAOvdn6WrNK1Jn_Y_P7C3AwX6ApVcgzacLA_x-u=xBQtebnuPxA@mail.gmail.com>
	<CAOvdn6U_Z=KdEo56nqe7jN54BwiesRJqDOz_VzVNpkWGfFRd2A@mail.gmail.com>
	<5049CEAE0200007800099A33@nat28.tlf.novell.com>
	<CAOvdn6XmsEfs+aO7nqBHdA61HpT_n_8W95u0MMq5J21tZCFbzw@mail.gmail.com>
	<5049F37A0200007800099BDA@nat28.tlf.novell.com>
	<CAOvdn6W+=OYTH3xTWBxUB8f_2tuZYKPTo-eJG0jfkaJ2rVutCA@mail.gmail.com>
In-Reply-To: <CAOvdn6W+=OYTH3xTWBxUB8f_2tuZYKPTo-eJG0jfkaJ2rVutCA@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>, john.baboval@citrix.com,
	Thomas Goetz <thomas.goetz@citrix.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen4.2 S3 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 07.09.12 at 13:51, Ben Guthro <ben@guthro.net> wrote:
> However, when I run with console=none, the observed behavior is very 
> different.
> The system seems to go to sleep successfully - but when I press the
> power button to wake it up - the power comes on - the fans spin up -
> but the system is unresponsive.
> No video
> No network
> keyboard LEDs (Caps,Numlock) do not light up.
> 
> 
> Alternate debugging strategies welcome.

I'm afraid other than being lucky to spot something via code
inspection, the only alternative is an ITP/ICE. Maybe Intel folks
could help out debugging this if it's reproducible for them.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 07 12:33:10 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Sep 2012 12: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 1T9xju-0003VD-R1; Fri, 07 Sep 2012 12:32:50 +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 1T9xjs-0003V5-Hm
	for xen-devel@lists.xen.org; Fri, 07 Sep 2012 12:32:48 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1347021146!4444044!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM4ODU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2595 invoked from network); 7 Sep 2012 12:32:26 -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;
	7 Sep 2012 12:32:26 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 07 Sep 2012 13:32:25 +0100
Message-Id: <504A05B00200007800099C7B@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 07 Sep 2012 13:33:20 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Stefan Bader" <stefan.bader@canonical.com>
References: <1347018043-21252-1-git-send-email-stefan.bader@canonical.com>
In-Reply-To: <1347018043-21252-1-git-send-email-stefan.bader@canonical.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Matt Wilson <msw@amazon.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH/RFC] Fix xsave bug on older Xen hypervisors
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.09.12 at 13:40, Stefan Bader <stefan.bader@canonical.com> wrote:
> When writing unsupported flags into CR4 (for some time the
> xen_write_cr4 function would refuse to do anything at all)
> older Xen hypervisors (and patch can potentially be improved
> by finding out what older means in version numbers) would
> crash the guest.
> 
> Since Amazon EC2 would at least in the past be affected by that,
> Fedora and Ubuntu were carrying a hack that would filter out
> X86_CR4_OSXSAVE before writing to CR4. This would affect any
> PV guest, even those running on a newer HV.
> 
> And this recently caused trouble because some user-space was
> only partially checking (or maybe only looking at the cpuid
> bits) and then trying to use xsave even though the OS support
> was not set.
> 
> So I came up with a patch that would
> - limit the work-around to certain Xen versions
> - prevent the write to CR4 by unsetting xsave and osxsave in
>   the cpuid bits
> 
> Doing things that way may actually allow this to be acceptable
> upstream, so I am sending it around, now.
> It probably could be improved when knowing the exact version
> to test for but otherwise should allow to work around the guest
> crash while not preventing xsave on Xen 4.x and newer hosts.

Before considering a hack like this, I'd really like to see evidence
of the described behavior with an upstream kernel (i.e. not one
with that known broken hack patched in, which has never been
upstream afaict).

Jan

> From dff8885934d4e1274a69c4cedd28a4d18a1255e8 Mon Sep 17 00:00:00 2001
> From: Stefan Bader <stefan.bader@canonical.com>
> Date: Fri, 15 Jun 2012 11:54:59 +0200
> Subject: [PATCH] xen: Mask xsave cpu capability on Xen host < 4
> 
> Older Xen hypervisors (like RHEL5 versions found to be used
> on Amazon's EC2) did have a bug which would crash the domain
> when trying to write unsupported CR4 values.
> Newer versions of the Xen hypervisor do handle this correctly.
> But when a 2.6.28 or later kernel (those seem to have
> xen_write_cr4 and xsave support) is booted as a PV guest on EC2,
> it potentially crashes when hitting the right CPU and the wrong
> hypervisor.
> 
> We were using a patch (taken from Fedora) that did always filter
> the OSXSAVE off the values written to CR4 when running as Xen PV
> guest. While not completely wrong this creates an inconsistency
> between the cpuid bits a guest sees and the CR4 settings.
> But it prevents any use of xsave even on recent Xen hypervisors.
> And this did recently cause problems because user-space was not
> testing all bits when deciding to use certain features.
> 
> This patch will actually mask off the cpuid bits for XSAVE and
> OSXSAVE, so generic code will not even try to set CR4. It is
> limited to PV guests and (since we do not actually know the
> exact version) Xen hypervisors before version 4.
> 
> Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
> ---
>  arch/x86/xen/enlighten.c |   17 ++++++++++++++++-
>  1 file changed, 16 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
> index 9642d4a..4241055 100644
> --- a/arch/x86/xen/enlighten.c
> +++ b/arch/x86/xen/enlighten.c
> @@ -210,6 +210,18 @@ void xen_vcpu_restore(void)
>  	}
>  }
>  
> +/*
> + * Older (with no clear statement about what old means) Xen hypervisors
> + * will crash a PV guest that tries to store OSXSAVE into CR4.
> + * To prevent this, we force the feature bits related to this off in the
> + * xen cpuid call. This inline function serves as a centralized test
> + * on whether the quirk should be done.
> + */
> +static inline needs_xsave_quirk(unsigned version)
> +{
> +	return (xen_pv_domain() && ((version >> 16) < 4)) ? 1 : 0;
> +}
> +
>  static void __init xen_banner(void)
>  {
>  	unsigned version = HYPERVISOR_xen_version(XENVER_version, NULL);
> @@ -221,6 +233,8 @@ static void __init xen_banner(void)
>  	printk(KERN_INFO "Xen version: %d.%d%s%s\n",
>  	       version >> 16, version & 0xffff, extra.extraversion,
>  	       xen_feature(XENFEAT_mmu_pt_update_preserve_ad) ? " (preserve-AD)" : 
> "");
> +	if (needs_xsave_quirk(version))
> +		printk(KERN_INFO "Forcing xsave off due to Xen version.\n");
>  }
>  
>  #define CPUID_THERM_POWER_LEAF 6
> @@ -351,6 +365,7 @@ static bool __init xen_check_mwait(void)
>  }
>  static void __init xen_init_cpuid_mask(void)
>  {
> +	unsigned version = HYPERVISOR_xen_version(XENVER_version, NULL);
>  	unsigned int ax, bx, cx, dx;
>  	unsigned int xsave_mask;
>  
> @@ -371,7 +386,7 @@ static void __init xen_init_cpuid_mask(void)
>  		(1 << (X86_FEATURE_OSXSAVE % 32));
>  
>  	/* Xen will set CR4.OSXSAVE if supported and not disabled by force */
> -	if ((cx & xsave_mask) != xsave_mask)
> +	if (((cx & xsave_mask) != xsave_mask) || needs_xsave_quirk(version))
>  		cpuid_leaf1_ecx_mask &= ~xsave_mask; /* disable XSAVE & OSXSAVE */
>  	if (xen_check_mwait())
>  		cpuid_leaf1_ecx_set_mask = (1 << (X86_FEATURE_MWAIT % 32));
> -- 
> 1.7.9.5
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org 
> http://lists.xen.org/xen-devel 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 07 12:33:10 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Sep 2012 12: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 1T9xju-0003VD-R1; Fri, 07 Sep 2012 12:32:50 +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 1T9xjs-0003V5-Hm
	for xen-devel@lists.xen.org; Fri, 07 Sep 2012 12:32:48 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1347021146!4444044!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM4ODU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2595 invoked from network); 7 Sep 2012 12:32:26 -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;
	7 Sep 2012 12:32:26 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 07 Sep 2012 13:32:25 +0100
Message-Id: <504A05B00200007800099C7B@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 07 Sep 2012 13:33:20 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Stefan Bader" <stefan.bader@canonical.com>
References: <1347018043-21252-1-git-send-email-stefan.bader@canonical.com>
In-Reply-To: <1347018043-21252-1-git-send-email-stefan.bader@canonical.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Matt Wilson <msw@amazon.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH/RFC] Fix xsave bug on older Xen hypervisors
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.09.12 at 13:40, Stefan Bader <stefan.bader@canonical.com> wrote:
> When writing unsupported flags into CR4 (for some time the
> xen_write_cr4 function would refuse to do anything at all)
> older Xen hypervisors (and patch can potentially be improved
> by finding out what older means in version numbers) would
> crash the guest.
> 
> Since Amazon EC2 would at least in the past be affected by that,
> Fedora and Ubuntu were carrying a hack that would filter out
> X86_CR4_OSXSAVE before writing to CR4. This would affect any
> PV guest, even those running on a newer HV.
> 
> And this recently caused trouble because some user-space was
> only partially checking (or maybe only looking at the cpuid
> bits) and then trying to use xsave even though the OS support
> was not set.
> 
> So I came up with a patch that would
> - limit the work-around to certain Xen versions
> - prevent the write to CR4 by unsetting xsave and osxsave in
>   the cpuid bits
> 
> Doing things that way may actually allow this to be acceptable
> upstream, so I am sending it around, now.
> It probably could be improved when knowing the exact version
> to test for but otherwise should allow to work around the guest
> crash while not preventing xsave on Xen 4.x and newer hosts.

Before considering a hack like this, I'd really like to see evidence
of the described behavior with an upstream kernel (i.e. not one
with that known broken hack patched in, which has never been
upstream afaict).

Jan

> From dff8885934d4e1274a69c4cedd28a4d18a1255e8 Mon Sep 17 00:00:00 2001
> From: Stefan Bader <stefan.bader@canonical.com>
> Date: Fri, 15 Jun 2012 11:54:59 +0200
> Subject: [PATCH] xen: Mask xsave cpu capability on Xen host < 4
> 
> Older Xen hypervisors (like RHEL5 versions found to be used
> on Amazon's EC2) did have a bug which would crash the domain
> when trying to write unsupported CR4 values.
> Newer versions of the Xen hypervisor do handle this correctly.
> But when a 2.6.28 or later kernel (those seem to have
> xen_write_cr4 and xsave support) is booted as a PV guest on EC2,
> it potentially crashes when hitting the right CPU and the wrong
> hypervisor.
> 
> We were using a patch (taken from Fedora) that did always filter
> the OSXSAVE off the values written to CR4 when running as Xen PV
> guest. While not completely wrong this creates an inconsistency
> between the cpuid bits a guest sees and the CR4 settings.
> But it prevents any use of xsave even on recent Xen hypervisors.
> And this did recently cause problems because user-space was not
> testing all bits when deciding to use certain features.
> 
> This patch will actually mask off the cpuid bits for XSAVE and
> OSXSAVE, so generic code will not even try to set CR4. It is
> limited to PV guests and (since we do not actually know the
> exact version) Xen hypervisors before version 4.
> 
> Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
> ---
>  arch/x86/xen/enlighten.c |   17 ++++++++++++++++-
>  1 file changed, 16 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
> index 9642d4a..4241055 100644
> --- a/arch/x86/xen/enlighten.c
> +++ b/arch/x86/xen/enlighten.c
> @@ -210,6 +210,18 @@ void xen_vcpu_restore(void)
>  	}
>  }
>  
> +/*
> + * Older (with no clear statement about what old means) Xen hypervisors
> + * will crash a PV guest that tries to store OSXSAVE into CR4.
> + * To prevent this, we force the feature bits related to this off in the
> + * xen cpuid call. This inline function serves as a centralized test
> + * on whether the quirk should be done.
> + */
> +static inline needs_xsave_quirk(unsigned version)
> +{
> +	return (xen_pv_domain() && ((version >> 16) < 4)) ? 1 : 0;
> +}
> +
>  static void __init xen_banner(void)
>  {
>  	unsigned version = HYPERVISOR_xen_version(XENVER_version, NULL);
> @@ -221,6 +233,8 @@ static void __init xen_banner(void)
>  	printk(KERN_INFO "Xen version: %d.%d%s%s\n",
>  	       version >> 16, version & 0xffff, extra.extraversion,
>  	       xen_feature(XENFEAT_mmu_pt_update_preserve_ad) ? " (preserve-AD)" : 
> "");
> +	if (needs_xsave_quirk(version))
> +		printk(KERN_INFO "Forcing xsave off due to Xen version.\n");
>  }
>  
>  #define CPUID_THERM_POWER_LEAF 6
> @@ -351,6 +365,7 @@ static bool __init xen_check_mwait(void)
>  }
>  static void __init xen_init_cpuid_mask(void)
>  {
> +	unsigned version = HYPERVISOR_xen_version(XENVER_version, NULL);
>  	unsigned int ax, bx, cx, dx;
>  	unsigned int xsave_mask;
>  
> @@ -371,7 +386,7 @@ static void __init xen_init_cpuid_mask(void)
>  		(1 << (X86_FEATURE_OSXSAVE % 32));
>  
>  	/* Xen will set CR4.OSXSAVE if supported and not disabled by force */
> -	if ((cx & xsave_mask) != xsave_mask)
> +	if (((cx & xsave_mask) != xsave_mask) || needs_xsave_quirk(version))
>  		cpuid_leaf1_ecx_mask &= ~xsave_mask; /* disable XSAVE & OSXSAVE */
>  	if (xen_check_mwait())
>  		cpuid_leaf1_ecx_set_mask = (1 << (X86_FEATURE_MWAIT % 32));
> -- 
> 1.7.9.5
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org 
> http://lists.xen.org/xen-devel 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 07 12:38:50 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Sep 2012 12: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 1T9xpS-0003nx-Mp; Fri, 07 Sep 2012 12:38:34 +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 1T9xpR-0003np-Qs
	for xen-devel@lists.xen.org; Fri, 07 Sep 2012 12:38:34 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1347021507!3036604!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM4ODU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17183 invoked from network); 7 Sep 2012 12:38:27 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-14.tower-27.messagelabs.com with SMTP;
	7 Sep 2012 12:38:27 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 07 Sep 2012 13:38:27 +0100
Message-Id: <504A071B0200007800099C8C@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 07 Sep 2012 13:39:23 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part704164EB.0__="
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: [Xen-devel] [PATCH,
 resend] x86/32-on-64: adjust Dom0 initial page table layout
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
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.

--=__Part704164EB.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Drop the unnecessary reservation of the L4 page for 32on64 Dom0, and
allocate its L3 first (to match behavior when running identical bit-
width hypervisor and Dom0 kernel).

Reported-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/arch/x86/domain_build.c
+++ b/xen/arch/x86/domain_build.c
@@ -510,7 +510,7 @@ int __init construct_dom0(
 #define NR(_l,_h,_s) \
     (((((_h) + ((1UL<<(_s))-1)) & ~((1UL<<(_s))-1)) - \
        ((_l) & ~((1UL<<(_s))-1))) >> (_s))
-        if ( (1 + /* # L4 */
+        if ( (!is_pv_32on64_domain(d) + /* # L4 */
               NR(v_start, v_end, L4_PAGETABLE_SHIFT) + /* # L3 */
               (!is_pv_32on64_domain(d) ?
                NR(v_start, v_end, L3_PAGETABLE_SHIFT) : /* # L2 */
@@ -756,6 +756,8 @@ int __init construct_dom0(
             panic("Not enough RAM for domain 0 PML4.\n");
         page->u.inuse.type_info =3D PGT_l4_page_table|PGT_validated|1;
         l4start =3D l4tab =3D page_to_virt(page);
+        maddr_to_page(mpt_alloc)->u.inuse.type_info =3D PGT_l3_page_table;=

+        l3start =3D __va(mpt_alloc); mpt_alloc +=3D PAGE_SIZE;
     }
     copy_page(l4tab, idle_pg_table);
     l4tab[0] =3D l4e_empty(); /* zap trampoline mapping */
@@ -787,9 +789,13 @@ int __init construct_dom0(
                     l2tab +=3D l2_table_offset(v_start);
                 if ( !((unsigned long)l3tab & (PAGE_SIZE-1)) )
                 {
-                    maddr_to_page(mpt_alloc)->u.inuse.type_info =3D
-                        PGT_l3_page_table;
-                    l3start =3D l3tab =3D __va(mpt_alloc); mpt_alloc +=3D =
PAGE_SIZE;
+                    if ( count || !l3start )
+                    {
+                        maddr_to_page(mpt_alloc)->u.inuse.type_info =3D
+                            PGT_l3_page_table;
+                        l3start =3D __va(mpt_alloc); mpt_alloc +=3D =
PAGE_SIZE;
+                    }
+                    l3tab =3D l3start;
                     clear_page(l3tab);
                     if ( count =3D=3D 0 )
                         l3tab +=3D l3_table_offset(v_start);
@@ -938,7 +944,7 @@ int __init construct_dom0(
     if ( !vinitrd_start && initrd_len )
         si->flags   |=3D SIF_MOD_START_PFN;
     si->flags       |=3D (xen_processor_pmbits << 8) & SIF_PM_MASK;
-    si->pt_base      =3D vpt_start + 2 * PAGE_SIZE * !!is_pv_32on64_domain=
(d);
+    si->pt_base      =3D vpt_start;
     si->nr_pt_frames =3D nr_pt_pages;
     si->mfn_list     =3D vphysmap_start;
     snprintf(si->magic, sizeof(si->magic), "xen-3.0-x86_%d%s",




--=__Part704164EB.0__=
Content-Type: text/plain; name="32on64-bogus-pt_base-adjust.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="32on64-bogus-pt_base-adjust.patch"

x86/32-on-64: adjust Dom0 initial page table layout=0A=0ADrop the =
unnecessary reservation of the L4 page for 32on64 Dom0, and=0Aallocate its =
L3 first (to match behavior when running identical bit-=0Awidth hypervisor =
and Dom0 kernel).=0A=0AReported-by: Konrad Rzeszutek Wilk <konrad.wilk@orac=
le.com>=0ASigned-off-by: Jan Beulich <jbeulich@suse.com>=0A=0A--- =
a/xen/arch/x86/domain_build.c=0A+++ b/xen/arch/x86/domain_build.c=0A@@ =
-510,7 +510,7 @@ int __init construct_dom0(=0A #define NR(_l,_h,_s) \=0A   =
  (((((_h) + ((1UL<<(_s))-1)) & ~((1UL<<(_s))-1)) - \=0A        ((_l) & =
~((1UL<<(_s))-1))) >> (_s))=0A-        if ( (1 + /* # L4 */=0A+        if =
( (!is_pv_32on64_domain(d) + /* # L4 */=0A               NR(v_start, =
v_end, L4_PAGETABLE_SHIFT) + /* # L3 */=0A               (!is_pv_32on64_dom=
ain(d) ?=0A                NR(v_start, v_end, L3_PAGETABLE_SHIFT) : /* # =
L2 */=0A@@ -756,6 +756,8 @@ int __init construct_dom0(=0A             =
panic("Not enough RAM for domain 0 PML4.\n");=0A         page->u.inuse.type=
_info =3D PGT_l4_page_table|PGT_validated|1;=0A         l4start =3D l4tab =
=3D page_to_virt(page);=0A+        maddr_to_page(mpt_alloc)->u.inuse.type_i=
nfo =3D PGT_l3_page_table;=0A+        l3start =3D __va(mpt_alloc); =
mpt_alloc +=3D PAGE_SIZE;=0A     }=0A     copy_page(l4tab, idle_pg_table);=
=0A     l4tab[0] =3D l4e_empty(); /* zap trampoline mapping */=0A@@ -787,9 =
+789,13 @@ int __init construct_dom0(=0A                     l2tab +=3D =
l2_table_offset(v_start);=0A                 if ( !((unsigned long)l3tab & =
(PAGE_SIZE-1)) )=0A                 {=0A-                    maddr_to_page(=
mpt_alloc)->u.inuse.type_info =3D=0A-                        PGT_l3_page_ta=
ble;=0A-                    l3start =3D l3tab =3D __va(mpt_alloc); =
mpt_alloc +=3D PAGE_SIZE;=0A+                    if ( count || !l3start =
)=0A+                    {=0A+                        maddr_to_page(mpt_all=
oc)->u.inuse.type_info =3D=0A+                            PGT_l3_page_table=
;=0A+                        l3start =3D __va(mpt_alloc); mpt_alloc +=3D =
PAGE_SIZE;=0A+                    }=0A+                    l3tab =3D =
l3start;=0A                     clear_page(l3tab);=0A                     =
if ( count =3D=3D 0 )=0A                         l3tab +=3D l3_table_offset=
(v_start);=0A@@ -938,7 +944,7 @@ int __init construct_dom0(=0A     if ( =
!vinitrd_start && initrd_len )=0A         si->flags   |=3D SIF_MOD_START_PF=
N;=0A     si->flags       |=3D (xen_processor_pmbits << 8) & SIF_PM_MASK;=
=0A-    si->pt_base      =3D vpt_start + 2 * PAGE_SIZE * !!is_pv_32on64_dom=
ain(d);=0A+    si->pt_base      =3D vpt_start;=0A     si->nr_pt_frames =3D =
nr_pt_pages;=0A     si->mfn_list     =3D vphysmap_start;=0A     snprintf(si=
->magic, sizeof(si->magic), "xen-3.0-x86_%d%s",=0A
--=__Part704164EB.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

--=__Part704164EB.0__=--


From xen-devel-bounces@lists.xen.org Fri Sep 07 12:38:50 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Sep 2012 12: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 1T9xpS-0003nx-Mp; Fri, 07 Sep 2012 12:38:34 +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 1T9xpR-0003np-Qs
	for xen-devel@lists.xen.org; Fri, 07 Sep 2012 12:38:34 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1347021507!3036604!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM4ODU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17183 invoked from network); 7 Sep 2012 12:38:27 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-14.tower-27.messagelabs.com with SMTP;
	7 Sep 2012 12:38:27 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 07 Sep 2012 13:38:27 +0100
Message-Id: <504A071B0200007800099C8C@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 07 Sep 2012 13:39:23 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part704164EB.0__="
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: [Xen-devel] [PATCH,
 resend] x86/32-on-64: adjust Dom0 initial page table layout
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
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.

--=__Part704164EB.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Drop the unnecessary reservation of the L4 page for 32on64 Dom0, and
allocate its L3 first (to match behavior when running identical bit-
width hypervisor and Dom0 kernel).

Reported-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/arch/x86/domain_build.c
+++ b/xen/arch/x86/domain_build.c
@@ -510,7 +510,7 @@ int __init construct_dom0(
 #define NR(_l,_h,_s) \
     (((((_h) + ((1UL<<(_s))-1)) & ~((1UL<<(_s))-1)) - \
        ((_l) & ~((1UL<<(_s))-1))) >> (_s))
-        if ( (1 + /* # L4 */
+        if ( (!is_pv_32on64_domain(d) + /* # L4 */
               NR(v_start, v_end, L4_PAGETABLE_SHIFT) + /* # L3 */
               (!is_pv_32on64_domain(d) ?
                NR(v_start, v_end, L3_PAGETABLE_SHIFT) : /* # L2 */
@@ -756,6 +756,8 @@ int __init construct_dom0(
             panic("Not enough RAM for domain 0 PML4.\n");
         page->u.inuse.type_info =3D PGT_l4_page_table|PGT_validated|1;
         l4start =3D l4tab =3D page_to_virt(page);
+        maddr_to_page(mpt_alloc)->u.inuse.type_info =3D PGT_l3_page_table;=

+        l3start =3D __va(mpt_alloc); mpt_alloc +=3D PAGE_SIZE;
     }
     copy_page(l4tab, idle_pg_table);
     l4tab[0] =3D l4e_empty(); /* zap trampoline mapping */
@@ -787,9 +789,13 @@ int __init construct_dom0(
                     l2tab +=3D l2_table_offset(v_start);
                 if ( !((unsigned long)l3tab & (PAGE_SIZE-1)) )
                 {
-                    maddr_to_page(mpt_alloc)->u.inuse.type_info =3D
-                        PGT_l3_page_table;
-                    l3start =3D l3tab =3D __va(mpt_alloc); mpt_alloc +=3D =
PAGE_SIZE;
+                    if ( count || !l3start )
+                    {
+                        maddr_to_page(mpt_alloc)->u.inuse.type_info =3D
+                            PGT_l3_page_table;
+                        l3start =3D __va(mpt_alloc); mpt_alloc +=3D =
PAGE_SIZE;
+                    }
+                    l3tab =3D l3start;
                     clear_page(l3tab);
                     if ( count =3D=3D 0 )
                         l3tab +=3D l3_table_offset(v_start);
@@ -938,7 +944,7 @@ int __init construct_dom0(
     if ( !vinitrd_start && initrd_len )
         si->flags   |=3D SIF_MOD_START_PFN;
     si->flags       |=3D (xen_processor_pmbits << 8) & SIF_PM_MASK;
-    si->pt_base      =3D vpt_start + 2 * PAGE_SIZE * !!is_pv_32on64_domain=
(d);
+    si->pt_base      =3D vpt_start;
     si->nr_pt_frames =3D nr_pt_pages;
     si->mfn_list     =3D vphysmap_start;
     snprintf(si->magic, sizeof(si->magic), "xen-3.0-x86_%d%s",




--=__Part704164EB.0__=
Content-Type: text/plain; name="32on64-bogus-pt_base-adjust.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="32on64-bogus-pt_base-adjust.patch"

x86/32-on-64: adjust Dom0 initial page table layout=0A=0ADrop the =
unnecessary reservation of the L4 page for 32on64 Dom0, and=0Aallocate its =
L3 first (to match behavior when running identical bit-=0Awidth hypervisor =
and Dom0 kernel).=0A=0AReported-by: Konrad Rzeszutek Wilk <konrad.wilk@orac=
le.com>=0ASigned-off-by: Jan Beulich <jbeulich@suse.com>=0A=0A--- =
a/xen/arch/x86/domain_build.c=0A+++ b/xen/arch/x86/domain_build.c=0A@@ =
-510,7 +510,7 @@ int __init construct_dom0(=0A #define NR(_l,_h,_s) \=0A   =
  (((((_h) + ((1UL<<(_s))-1)) & ~((1UL<<(_s))-1)) - \=0A        ((_l) & =
~((1UL<<(_s))-1))) >> (_s))=0A-        if ( (1 + /* # L4 */=0A+        if =
( (!is_pv_32on64_domain(d) + /* # L4 */=0A               NR(v_start, =
v_end, L4_PAGETABLE_SHIFT) + /* # L3 */=0A               (!is_pv_32on64_dom=
ain(d) ?=0A                NR(v_start, v_end, L3_PAGETABLE_SHIFT) : /* # =
L2 */=0A@@ -756,6 +756,8 @@ int __init construct_dom0(=0A             =
panic("Not enough RAM for domain 0 PML4.\n");=0A         page->u.inuse.type=
_info =3D PGT_l4_page_table|PGT_validated|1;=0A         l4start =3D l4tab =
=3D page_to_virt(page);=0A+        maddr_to_page(mpt_alloc)->u.inuse.type_i=
nfo =3D PGT_l3_page_table;=0A+        l3start =3D __va(mpt_alloc); =
mpt_alloc +=3D PAGE_SIZE;=0A     }=0A     copy_page(l4tab, idle_pg_table);=
=0A     l4tab[0] =3D l4e_empty(); /* zap trampoline mapping */=0A@@ -787,9 =
+789,13 @@ int __init construct_dom0(=0A                     l2tab +=3D =
l2_table_offset(v_start);=0A                 if ( !((unsigned long)l3tab & =
(PAGE_SIZE-1)) )=0A                 {=0A-                    maddr_to_page(=
mpt_alloc)->u.inuse.type_info =3D=0A-                        PGT_l3_page_ta=
ble;=0A-                    l3start =3D l3tab =3D __va(mpt_alloc); =
mpt_alloc +=3D PAGE_SIZE;=0A+                    if ( count || !l3start =
)=0A+                    {=0A+                        maddr_to_page(mpt_all=
oc)->u.inuse.type_info =3D=0A+                            PGT_l3_page_table=
;=0A+                        l3start =3D __va(mpt_alloc); mpt_alloc +=3D =
PAGE_SIZE;=0A+                    }=0A+                    l3tab =3D =
l3start;=0A                     clear_page(l3tab);=0A                     =
if ( count =3D=3D 0 )=0A                         l3tab +=3D l3_table_offset=
(v_start);=0A@@ -938,7 +944,7 @@ int __init construct_dom0(=0A     if ( =
!vinitrd_start && initrd_len )=0A         si->flags   |=3D SIF_MOD_START_PF=
N;=0A     si->flags       |=3D (xen_processor_pmbits << 8) & SIF_PM_MASK;=
=0A-    si->pt_base      =3D vpt_start + 2 * PAGE_SIZE * !!is_pv_32on64_dom=
ain(d);=0A+    si->pt_base      =3D vpt_start;=0A     si->nr_pt_frames =3D =
nr_pt_pages;=0A     si->mfn_list     =3D vphysmap_start;=0A     snprintf(si=
->magic, sizeof(si->magic), "xen-3.0-x86_%d%s",=0A
--=__Part704164EB.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

--=__Part704164EB.0__=--


From xen-devel-bounces@lists.xen.org Fri Sep 07 12:42:59 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Sep 2012 12: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 1T9xtR-0003wT-FP; Fri, 07 Sep 2012 12:42:41 +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 1T9xtP-0003wM-Hm
	for xen-devel@lists.xen.org; Fri, 07 Sep 2012 12:42:39 +0000
Received: from [85.158.143.35:56939] by server-3.bemta-4.messagelabs.com id
	A5/FE-08232-EBBE9405; Fri, 07 Sep 2012 12:42:38 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1347021754!15385141!1
X-Originating-IP: [74.125.83.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13495 invoked from network); 7 Sep 2012 12:42:35 -0000
Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com)
	(74.125.83.45)
	by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Sep 2012 12:42:35 -0000
Received: by eeke53 with SMTP id e53so1275867eek.32
	for <xen-devel@lists.xen.org>; Fri, 07 Sep 2012 05:42:34 -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=a9nnzd8oTeDE+tLwiTMxOzp8t130rQ0wlrMPH+tUE74=;
	b=Hn7S92xIx+Ltd35cp7C2xfarq2yQST4vTshVXAk6t9zBIhEwpn0asb3V8j1AI0VCn/
	/B3ArDQ9iAITYBPgVqXzgNu6ZDWSJWtKS52K3tHQlwSaXJQapDrhZjnxeI4TqYd43KSw
	+FIILh7O5J/qUUem2aWNUYQDx4uohaevXpR+IPIlpsxfYF2/QVcsNFr3wTMnv7U8AWRd
	yqs9XooSGPo7fbVfHpA2FwN0ukZnDAJsTmpTFX56Z8J4I0cNpPAdpNX+/uhFDwRUoPHO
	CStHKQBB9TdWvL4lQ3JSxzfcHHrGe6dXTH5I3Am0+xSTcsM6OgJlP+zuiJap7SMFTt2A
	79rw==
Received: by 10.14.173.131 with SMTP id v3mr2100930eel.15.1347021754338;
	Fri, 07 Sep 2012 05:42:34 -0700 (PDT)
Received: from [192.168.1.3] (host86-184-74-117.range86-184.btcentralplus.com.
	[86.184.74.117])
	by mx.google.com with ESMTPS id e7sm14433496eep.2.2012.09.07.05.42.32
	(version=SSLv3 cipher=OTHER); Fri, 07 Sep 2012 05:42:33 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.33.0.120411
Date: Fri, 07 Sep 2012 13:42:26 +0100
From: Keir Fraser <keir@xen.org>
To: Jan Beulich <JBeulich@suse.com>,
	xen-devel <xen-devel@lists.xen.org>
Message-ID: <CC6FAA42.4AF4C%keir@xen.org>
Thread-Topic: [Xen-devel] [PATCH, resend] x86/32-on-64: adjust Dom0 initial
	page table layout
Thread-Index: Ac2M9jv+adK7BUGCQUCyoYHMa0zazA==
In-Reply-To: <504A071B0200007800099C8C@nat28.tlf.novell.com>
Mime-version: 1.0
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH,
 resend] x86/32-on-64: adjust Dom0 initial page table layout
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 07/09/2012 13:39, "Jan Beulich" <JBeulich@suse.com> wrote:

> Drop the unnecessary reservation of the L4 page for 32on64 Dom0, and
> allocate its L3 first (to match behavior when running identical bit-
> width hypervisor and Dom0 kernel).
> 
> Reported-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Acked-by: Keir Fraser <keir@xen.org>

Not for 4.2.0.

> --- a/xen/arch/x86/domain_build.c
> +++ b/xen/arch/x86/domain_build.c
> @@ -510,7 +510,7 @@ int __init construct_dom0(
>  #define NR(_l,_h,_s) \
>      (((((_h) + ((1UL<<(_s))-1)) & ~((1UL<<(_s))-1)) - \
>         ((_l) & ~((1UL<<(_s))-1))) >> (_s))
> -        if ( (1 + /* # L4 */
> +        if ( (!is_pv_32on64_domain(d) + /* # L4 */
>                NR(v_start, v_end, L4_PAGETABLE_SHIFT) + /* # L3 */
>                (!is_pv_32on64_domain(d) ?
>                 NR(v_start, v_end, L3_PAGETABLE_SHIFT) : /* # L2 */
> @@ -756,6 +756,8 @@ int __init construct_dom0(
>              panic("Not enough RAM for domain 0 PML4.\n");
>          page->u.inuse.type_info = PGT_l4_page_table|PGT_validated|1;
>          l4start = l4tab = page_to_virt(page);
> +        maddr_to_page(mpt_alloc)->u.inuse.type_info = PGT_l3_page_table;
> +        l3start = __va(mpt_alloc); mpt_alloc += PAGE_SIZE;
>      }
>      copy_page(l4tab, idle_pg_table);
>      l4tab[0] = l4e_empty(); /* zap trampoline mapping */
> @@ -787,9 +789,13 @@ int __init construct_dom0(
>                      l2tab += l2_table_offset(v_start);
>                  if ( !((unsigned long)l3tab & (PAGE_SIZE-1)) )
>                  {
> -                    maddr_to_page(mpt_alloc)->u.inuse.type_info =
> -                        PGT_l3_page_table;
> -                    l3start = l3tab = __va(mpt_alloc); mpt_alloc +=
> PAGE_SIZE;
> +                    if ( count || !l3start )
> +                    {
> +                        maddr_to_page(mpt_alloc)->u.inuse.type_info =
> +                            PGT_l3_page_table;
> +                        l3start = __va(mpt_alloc); mpt_alloc += PAGE_SIZE;
> +                    }
> +                    l3tab = l3start;
>                      clear_page(l3tab);
>                      if ( count == 0 )
>                          l3tab += l3_table_offset(v_start);
> @@ -938,7 +944,7 @@ int __init construct_dom0(
>      if ( !vinitrd_start && initrd_len )
>          si->flags   |= SIF_MOD_START_PFN;
>      si->flags       |= (xen_processor_pmbits << 8) & SIF_PM_MASK;
> -    si->pt_base      = vpt_start + 2 * PAGE_SIZE * !!is_pv_32on64_domain(d);
> +    si->pt_base      = vpt_start;
>      si->nr_pt_frames = nr_pt_pages;
>      si->mfn_list     = vphysmap_start;
>      snprintf(si->magic, sizeof(si->magic), "xen-3.0-x86_%d%s",
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Sep 07 12:42:59 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Sep 2012 12: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 1T9xtR-0003wT-FP; Fri, 07 Sep 2012 12:42:41 +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 1T9xtP-0003wM-Hm
	for xen-devel@lists.xen.org; Fri, 07 Sep 2012 12:42:39 +0000
Received: from [85.158.143.35:56939] by server-3.bemta-4.messagelabs.com id
	A5/FE-08232-EBBE9405; Fri, 07 Sep 2012 12:42:38 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1347021754!15385141!1
X-Originating-IP: [74.125.83.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13495 invoked from network); 7 Sep 2012 12:42:35 -0000
Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com)
	(74.125.83.45)
	by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Sep 2012 12:42:35 -0000
Received: by eeke53 with SMTP id e53so1275867eek.32
	for <xen-devel@lists.xen.org>; Fri, 07 Sep 2012 05:42:34 -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=a9nnzd8oTeDE+tLwiTMxOzp8t130rQ0wlrMPH+tUE74=;
	b=Hn7S92xIx+Ltd35cp7C2xfarq2yQST4vTshVXAk6t9zBIhEwpn0asb3V8j1AI0VCn/
	/B3ArDQ9iAITYBPgVqXzgNu6ZDWSJWtKS52K3tHQlwSaXJQapDrhZjnxeI4TqYd43KSw
	+FIILh7O5J/qUUem2aWNUYQDx4uohaevXpR+IPIlpsxfYF2/QVcsNFr3wTMnv7U8AWRd
	yqs9XooSGPo7fbVfHpA2FwN0ukZnDAJsTmpTFX56Z8J4I0cNpPAdpNX+/uhFDwRUoPHO
	CStHKQBB9TdWvL4lQ3JSxzfcHHrGe6dXTH5I3Am0+xSTcsM6OgJlP+zuiJap7SMFTt2A
	79rw==
Received: by 10.14.173.131 with SMTP id v3mr2100930eel.15.1347021754338;
	Fri, 07 Sep 2012 05:42:34 -0700 (PDT)
Received: from [192.168.1.3] (host86-184-74-117.range86-184.btcentralplus.com.
	[86.184.74.117])
	by mx.google.com with ESMTPS id e7sm14433496eep.2.2012.09.07.05.42.32
	(version=SSLv3 cipher=OTHER); Fri, 07 Sep 2012 05:42:33 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.33.0.120411
Date: Fri, 07 Sep 2012 13:42:26 +0100
From: Keir Fraser <keir@xen.org>
To: Jan Beulich <JBeulich@suse.com>,
	xen-devel <xen-devel@lists.xen.org>
Message-ID: <CC6FAA42.4AF4C%keir@xen.org>
Thread-Topic: [Xen-devel] [PATCH, resend] x86/32-on-64: adjust Dom0 initial
	page table layout
Thread-Index: Ac2M9jv+adK7BUGCQUCyoYHMa0zazA==
In-Reply-To: <504A071B0200007800099C8C@nat28.tlf.novell.com>
Mime-version: 1.0
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH,
 resend] x86/32-on-64: adjust Dom0 initial page table layout
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 07/09/2012 13:39, "Jan Beulich" <JBeulich@suse.com> wrote:

> Drop the unnecessary reservation of the L4 page for 32on64 Dom0, and
> allocate its L3 first (to match behavior when running identical bit-
> width hypervisor and Dom0 kernel).
> 
> Reported-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Acked-by: Keir Fraser <keir@xen.org>

Not for 4.2.0.

> --- a/xen/arch/x86/domain_build.c
> +++ b/xen/arch/x86/domain_build.c
> @@ -510,7 +510,7 @@ int __init construct_dom0(
>  #define NR(_l,_h,_s) \
>      (((((_h) + ((1UL<<(_s))-1)) & ~((1UL<<(_s))-1)) - \
>         ((_l) & ~((1UL<<(_s))-1))) >> (_s))
> -        if ( (1 + /* # L4 */
> +        if ( (!is_pv_32on64_domain(d) + /* # L4 */
>                NR(v_start, v_end, L4_PAGETABLE_SHIFT) + /* # L3 */
>                (!is_pv_32on64_domain(d) ?
>                 NR(v_start, v_end, L3_PAGETABLE_SHIFT) : /* # L2 */
> @@ -756,6 +756,8 @@ int __init construct_dom0(
>              panic("Not enough RAM for domain 0 PML4.\n");
>          page->u.inuse.type_info = PGT_l4_page_table|PGT_validated|1;
>          l4start = l4tab = page_to_virt(page);
> +        maddr_to_page(mpt_alloc)->u.inuse.type_info = PGT_l3_page_table;
> +        l3start = __va(mpt_alloc); mpt_alloc += PAGE_SIZE;
>      }
>      copy_page(l4tab, idle_pg_table);
>      l4tab[0] = l4e_empty(); /* zap trampoline mapping */
> @@ -787,9 +789,13 @@ int __init construct_dom0(
>                      l2tab += l2_table_offset(v_start);
>                  if ( !((unsigned long)l3tab & (PAGE_SIZE-1)) )
>                  {
> -                    maddr_to_page(mpt_alloc)->u.inuse.type_info =
> -                        PGT_l3_page_table;
> -                    l3start = l3tab = __va(mpt_alloc); mpt_alloc +=
> PAGE_SIZE;
> +                    if ( count || !l3start )
> +                    {
> +                        maddr_to_page(mpt_alloc)->u.inuse.type_info =
> +                            PGT_l3_page_table;
> +                        l3start = __va(mpt_alloc); mpt_alloc += PAGE_SIZE;
> +                    }
> +                    l3tab = l3start;
>                      clear_page(l3tab);
>                      if ( count == 0 )
>                          l3tab += l3_table_offset(v_start);
> @@ -938,7 +944,7 @@ int __init construct_dom0(
>      if ( !vinitrd_start && initrd_len )
>          si->flags   |= SIF_MOD_START_PFN;
>      si->flags       |= (xen_processor_pmbits << 8) & SIF_PM_MASK;
> -    si->pt_base      = vpt_start + 2 * PAGE_SIZE * !!is_pv_32on64_domain(d);
> +    si->pt_base      = vpt_start;
>      si->nr_pt_frames = nr_pt_pages;
>      si->mfn_list     = vphysmap_start;
>      snprintf(si->magic, sizeof(si->magic), "xen-3.0-x86_%d%s",
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Sep 07 12:44:27 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Sep 2012 12:44:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9xut-00042E-VR; Fri, 07 Sep 2012 12:44:11 +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 1T9xus-000423-3i
	for xen-devel@lists.xensource.com; Fri, 07 Sep 2012 12:44:10 +0000
Received: from [85.158.143.99:40114] by server-1.bemta-4.messagelabs.com id
	2E/77-12504-91CE9405; Fri, 07 Sep 2012 12:44:09 +0000
X-Env-Sender: fantonifabio@tiscali.it
X-Msg-Ref: server-11.tower-216.messagelabs.com!1347021847!21589683!1
X-Originating-IP: [94.23.245.208]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19341 invoked from network); 7 Sep 2012 12:44:07 -0000
Received: from lnx3.fantu.it (HELO lnx3.fantu.it) (94.23.245.208)
	by server-11.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 7 Sep 2012 12:44:07 -0000
Received: from localhost (localhost.localdomain [127.0.0.1])
	by lnx3.fantu.it (Postfix) with ESMTP id CED374015B1
	for <xen-devel@lists.xensource.com>;
	Fri,  7 Sep 2012 14:44:06 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at lnx3.fantu.it
Received: from lnx3.fantu.it ([127.0.0.1])
	by localhost (lnx3.fantu.it [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id lXNLNC4WMqF8 for <xen-devel@lists.xensource.com>;
	Fri,  7 Sep 2012 14:44:06 +0200 (CEST)
Received: from [192.168.178.50]
	(host159-164-dynamic.56-82-r.retail.telecomitalia.it [82.56.164.159])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: prova@fantu.it)
	by lnx3.fantu.it (Postfix) with ESMTPSA id 2695740130E
	for <xen-devel@lists.xensource.com>;
	Fri,  7 Sep 2012 14:44:06 +0200 (CEST)
Message-ID: <5049EC11.9080302@tiscali.it>
Date: Fri, 07 Sep 2012 14:44:01 +0200
From: Fabio Fantoni <fantonifabio@tiscali.it>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:14.0) Gecko/20120713 Thunderbird/14.0
MIME-Version: 1.0
To: xen-devel <xen-devel@lists.xensource.com>
Subject: [Xen-devel] Test report of xen 4.2.0-rc4
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="===============7578888010532444193=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Questo è un messaggio firmato digitalmente in formato MIME.

--===============7578888010532444193==
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms020308090302010502000504"

Questo è un messaggio firmato digitalmente in formato MIME.

--------------ms020308090302010502000504
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: quoted-printable

Dom0:
Wheezy 64 bit with kernel from package linux-image-3.2.0-3-amd64 version =

3.2.23-1, package blktap-dkms and all dependency packages for xen
hg clone http://xenbits.xen.org/hg/xen-unstable.hg (in this build=20
changeset is 25822:ec23c2a11f6f)
-------------------------
vi Config.mk
------------
PYTHON_PREFIX_ARG =3D
-------------------------
Added some patches:
- tools: Improve make deb
-------------------------
=2E/configure
-------------------------
make deb

-------------------------
Old issues not solved:
-------------
- IMPORTANT - On restore network is up but not working, tried with W7=20
pro 64 bit with gplpv last build (357) on qemu-xen-traditional
- Cdrom hotswap is not working, tried with W7 pro 64 bit with gplpv last =

build (357) on qemu-xen-traditional
xl -vvv cd-eject W7 hdb
libxl: debug: libxl.c:2143:libxl_cdrom_insert: ao 0x1461980: create:=20
how=3D(nil) callback=3D(nil) poller=3D0x14619e0
Errore di segmentazione
- Vnc is working but only with parameters not supplied as value to the=20
vfb key, but with vfb key is not working
-------------------------


--------------ms020308090302010502000504
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: Firma crittografica S/MIME

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINhjCC
BjQwggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT
DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp
Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3
MTAyNDIxMDI1NVoXDTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T
dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu
aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs
aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOM
KqANy9BV7V0igWdGxA8IU77L3aTxErQ+fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi
8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke/s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8M
DP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHksw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y
2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHHtOkzUreG//CsFnB9+uaYSlR65cdG
zTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB
Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd+q9rMfPIHeOsuzAfBgNV
HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH
MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3
dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu
c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v
c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0
dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93
d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqp
Jw3I07QWke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Mic
c/NXcs7kPBRdn6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9Jphw
UPTXwHovjavRnhUQHLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMc
p+reg9901zkyT3fDW/ivJVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT
+HBDYtbuvexNftwNQKD5193A7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1X
hwby6mLhkbaXslkVtwEWT3Van49rKjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvO
hNz/QplNa+VkIsrcp7+8ZhP1l1b2U6MaxIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC
0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqh
AChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H75dVCV33K6FuxZrf09yTz+Vx/PkdRUYk
XmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHSjCCBjKgAwIBAgICHmMwDQYJKoZIhvcNAQEF
BQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJT
ZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD
bGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0xMjAzMTgyMjE0MzBa
Fw0xNDAzMjAwODU3MDlaMIGMMRkwFwYDVQQNExBlQjZPRTM3UlJOUHlsNW0yMQswCQYDVQQG
EwJJVDEQMA4GA1UECBMHQmVyZ2FtbzEQMA4GA1UEBxMHUm92ZXR0YTEWMBQGA1UEAxMNRmFi
aW8gRmFudG9uaTEmMCQGCSqGSIb3DQEJARYXZmFudG9uaWZhYmlvQHRpc2NhbGkuaXQwggEi
MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC1XhckXsX23vgJq76s2f0KT8U8Msov5QgV
10eQBb2wL/TzcmqtZotI7ztKVhio3ehHg+mfu+3EqOkX9Umgut8rP0bPi7AGjkPXbOTT/cSU
Xz2Kw31VGOmiOVoUFGvpQitp3weCkhUJLBipI8EpNyBXpjtQ9yCpnIAqfuc77ybfSnCy7tTR
MBq1BUkfjH1+GL45riosuS4+F+MSUvlYzLiT4rAduAX1Y2IuORDsf9Bce8GBxa6syP9rCyzl
Vk7DIX5k8j2vlnyRATIypn5CQLQxGT6e0f6ac4gvWOHwO2QEBsmZKKs1ZidE4q/9OoNXYX6A
jnHtp1H1vcrek/vVcs19AgMBAAGjggOyMIIDrjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAd
BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFFan8cbEWWBmSTWFtLk2
YNdAcGUbMB8GA1UdIwQYMBaAFK5Vg2/sMcq59x36r2sx88gd46y7MCIGA1UdEQQbMBmBF2Zh
bnRvbmlmYWJpb0B0aXNjYWxpLml0MIICIQYDVR0gBIICGDCCAhQwggIQBgsrBgEEAYG1NwEC
AjCCAf8wLgYIKwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYw
NAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYw
gfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMC
AQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNjb3JkaW5nIHRvIHRoZSBDbGFz
cyAyIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3ks
IHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGluIGNvbXBsaWFuY2Ug
b2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMIGcBggrBgEFBQcCAjCBjzAnFiBT
dGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgECGmRMaWFiaWxpdHkgYW5kIHdh
cnJhbnRpZXMgYXJlIGxpbWl0ZWQhIFNlZSBzZWN0aW9uICJMZWdhbCBhbmQgTGltaXRhdGlv
bnMiIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3kuMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6
Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUyLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYI
KwYBBQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MyL2NsaWVudC9j
YTBCBggrBgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNz
Mi5jbGllbnQuY2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzAN
BgkqhkiG9w0BAQUFAAOCAQEAjzHNqifpDVMkH1TSPFZVIiQ4fh49/V5JMpstgqEZPDaDe5r8
h+fMBZtUa6LLMco03Z9BNEXlqlXKiFk8feVYB8obEjz7YYq1XhO9q7JUmkSs0WGIH4xU0XB1
kPC8T8H+5E//84poYSFHE4pA+Ff68UANP2/EuFJWMjegiefnOr8aM42OAcUkjEWSlautIIX8
oD2GizwQYjWdDDjEonbuMKFP6rY2xGI3PSLI3IVU2opb0/itNhQui3WRxafloJqTlriY8m8+
qSLr2HGftbBlbyzVWB8o//aW0H0LMabjkIvrm7Zmh2vcCxiSxGBwYASuSYXGuQiKAgGptUs1
XJLZuzGCA9owggPWAgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20g
THRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG
A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EC
Ah5jMAkGBSsOAwIaBQCgggIbMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcN
AQkFMQ8XDTEyMDkwNzEyNDQwMVowIwYJKoZIhvcNAQkEMRYEFDzlLWpY1NtwVM26xxH5BLID
NF87MGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggqhkiG
9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcN
AwICASgwgaQGCSsGAQQBgjcQBDGBljCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0
YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25p
bmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp
ZW50IENBAgIeYzCBpgYLKoZIhvcNAQkQAgsxgZaggZMwgYwxCzAJBgNVBAYTAklMMRYwFAYD
VQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0
ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRp
YXRlIENsaWVudCBDQQICHmMwDQYJKoZIhvcNAQEBBQAEggEAHtRhRWVrhDfwKdQHUyRxqXTJ
XY7rrtUOfe7Tvr/N/S0LRNrx/9dR0fORbPS7nY0ylrOY8kVlxUgAykJgsnqC/Z+CX+l3sQQJ
KvWE6Pr70IVNifb24q5lsnOChHLCSnLJGV4nFi9/Bi+q4OuphLfoI+uCcMBuyaDBwtA3JF9w
obQJj/6rgnqopc24O1vCUe0oWiVypp4m/eYURIRQH+wxZZZB2tNv9MvyJy+hmJ73ZhaJ2359
L8IxRwFFUpotUegO1TKo0xL0YNumQlZbE8Od12kF+UbW3U4kZdxWEgaooP1Q1Y/EwGtBZRi8
YWO0+gNgHzPMSTrcJmXTOakLA1t/bAAAAAAAAA==
--------------ms020308090302010502000504--


--===============7578888010532444193==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============7578888010532444193==--


From xen-devel-bounces@lists.xen.org Fri Sep 07 12:44:27 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Sep 2012 12:44:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9xut-00042E-VR; Fri, 07 Sep 2012 12:44:11 +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 1T9xus-000423-3i
	for xen-devel@lists.xensource.com; Fri, 07 Sep 2012 12:44:10 +0000
Received: from [85.158.143.99:40114] by server-1.bemta-4.messagelabs.com id
	2E/77-12504-91CE9405; Fri, 07 Sep 2012 12:44:09 +0000
X-Env-Sender: fantonifabio@tiscali.it
X-Msg-Ref: server-11.tower-216.messagelabs.com!1347021847!21589683!1
X-Originating-IP: [94.23.245.208]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19341 invoked from network); 7 Sep 2012 12:44:07 -0000
Received: from lnx3.fantu.it (HELO lnx3.fantu.it) (94.23.245.208)
	by server-11.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 7 Sep 2012 12:44:07 -0000
Received: from localhost (localhost.localdomain [127.0.0.1])
	by lnx3.fantu.it (Postfix) with ESMTP id CED374015B1
	for <xen-devel@lists.xensource.com>;
	Fri,  7 Sep 2012 14:44:06 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at lnx3.fantu.it
Received: from lnx3.fantu.it ([127.0.0.1])
	by localhost (lnx3.fantu.it [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id lXNLNC4WMqF8 for <xen-devel@lists.xensource.com>;
	Fri,  7 Sep 2012 14:44:06 +0200 (CEST)
Received: from [192.168.178.50]
	(host159-164-dynamic.56-82-r.retail.telecomitalia.it [82.56.164.159])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: prova@fantu.it)
	by lnx3.fantu.it (Postfix) with ESMTPSA id 2695740130E
	for <xen-devel@lists.xensource.com>;
	Fri,  7 Sep 2012 14:44:06 +0200 (CEST)
Message-ID: <5049EC11.9080302@tiscali.it>
Date: Fri, 07 Sep 2012 14:44:01 +0200
From: Fabio Fantoni <fantonifabio@tiscali.it>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:14.0) Gecko/20120713 Thunderbird/14.0
MIME-Version: 1.0
To: xen-devel <xen-devel@lists.xensource.com>
Subject: [Xen-devel] Test report of xen 4.2.0-rc4
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="===============7578888010532444193=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Questo è un messaggio firmato digitalmente in formato MIME.

--===============7578888010532444193==
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms020308090302010502000504"

Questo è un messaggio firmato digitalmente in formato MIME.

--------------ms020308090302010502000504
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: quoted-printable

Dom0:
Wheezy 64 bit with kernel from package linux-image-3.2.0-3-amd64 version =

3.2.23-1, package blktap-dkms and all dependency packages for xen
hg clone http://xenbits.xen.org/hg/xen-unstable.hg (in this build=20
changeset is 25822:ec23c2a11f6f)
-------------------------
vi Config.mk
------------
PYTHON_PREFIX_ARG =3D
-------------------------
Added some patches:
- tools: Improve make deb
-------------------------
=2E/configure
-------------------------
make deb

-------------------------
Old issues not solved:
-------------
- IMPORTANT - On restore network is up but not working, tried with W7=20
pro 64 bit with gplpv last build (357) on qemu-xen-traditional
- Cdrom hotswap is not working, tried with W7 pro 64 bit with gplpv last =

build (357) on qemu-xen-traditional
xl -vvv cd-eject W7 hdb
libxl: debug: libxl.c:2143:libxl_cdrom_insert: ao 0x1461980: create:=20
how=3D(nil) callback=3D(nil) poller=3D0x14619e0
Errore di segmentazione
- Vnc is working but only with parameters not supplied as value to the=20
vfb key, but with vfb key is not working
-------------------------


--------------ms020308090302010502000504
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: Firma crittografica S/MIME

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINhjCC
BjQwggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT
DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp
Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3
MTAyNDIxMDI1NVoXDTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T
dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu
aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs
aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOM
KqANy9BV7V0igWdGxA8IU77L3aTxErQ+fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi
8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke/s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8M
DP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHksw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y
2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHHtOkzUreG//CsFnB9+uaYSlR65cdG
zTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB
Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd+q9rMfPIHeOsuzAfBgNV
HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH
MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3
dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu
c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v
c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0
dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93
d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqp
Jw3I07QWke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Mic
c/NXcs7kPBRdn6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9Jphw
UPTXwHovjavRnhUQHLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMc
p+reg9901zkyT3fDW/ivJVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT
+HBDYtbuvexNftwNQKD5193A7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1X
hwby6mLhkbaXslkVtwEWT3Van49rKjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvO
hNz/QplNa+VkIsrcp7+8ZhP1l1b2U6MaxIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC
0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqh
AChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H75dVCV33K6FuxZrf09yTz+Vx/PkdRUYk
XmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHSjCCBjKgAwIBAgICHmMwDQYJKoZIhvcNAQEF
BQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJT
ZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD
bGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0xMjAzMTgyMjE0MzBa
Fw0xNDAzMjAwODU3MDlaMIGMMRkwFwYDVQQNExBlQjZPRTM3UlJOUHlsNW0yMQswCQYDVQQG
EwJJVDEQMA4GA1UECBMHQmVyZ2FtbzEQMA4GA1UEBxMHUm92ZXR0YTEWMBQGA1UEAxMNRmFi
aW8gRmFudG9uaTEmMCQGCSqGSIb3DQEJARYXZmFudG9uaWZhYmlvQHRpc2NhbGkuaXQwggEi
MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC1XhckXsX23vgJq76s2f0KT8U8Msov5QgV
10eQBb2wL/TzcmqtZotI7ztKVhio3ehHg+mfu+3EqOkX9Umgut8rP0bPi7AGjkPXbOTT/cSU
Xz2Kw31VGOmiOVoUFGvpQitp3weCkhUJLBipI8EpNyBXpjtQ9yCpnIAqfuc77ybfSnCy7tTR
MBq1BUkfjH1+GL45riosuS4+F+MSUvlYzLiT4rAduAX1Y2IuORDsf9Bce8GBxa6syP9rCyzl
Vk7DIX5k8j2vlnyRATIypn5CQLQxGT6e0f6ac4gvWOHwO2QEBsmZKKs1ZidE4q/9OoNXYX6A
jnHtp1H1vcrek/vVcs19AgMBAAGjggOyMIIDrjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAd
BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFFan8cbEWWBmSTWFtLk2
YNdAcGUbMB8GA1UdIwQYMBaAFK5Vg2/sMcq59x36r2sx88gd46y7MCIGA1UdEQQbMBmBF2Zh
bnRvbmlmYWJpb0B0aXNjYWxpLml0MIICIQYDVR0gBIICGDCCAhQwggIQBgsrBgEEAYG1NwEC
AjCCAf8wLgYIKwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYw
NAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYw
gfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMC
AQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNjb3JkaW5nIHRvIHRoZSBDbGFz
cyAyIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3ks
IHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGluIGNvbXBsaWFuY2Ug
b2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMIGcBggrBgEFBQcCAjCBjzAnFiBT
dGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgECGmRMaWFiaWxpdHkgYW5kIHdh
cnJhbnRpZXMgYXJlIGxpbWl0ZWQhIFNlZSBzZWN0aW9uICJMZWdhbCBhbmQgTGltaXRhdGlv
bnMiIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3kuMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6
Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUyLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYI
KwYBBQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MyL2NsaWVudC9j
YTBCBggrBgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNz
Mi5jbGllbnQuY2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzAN
BgkqhkiG9w0BAQUFAAOCAQEAjzHNqifpDVMkH1TSPFZVIiQ4fh49/V5JMpstgqEZPDaDe5r8
h+fMBZtUa6LLMco03Z9BNEXlqlXKiFk8feVYB8obEjz7YYq1XhO9q7JUmkSs0WGIH4xU0XB1
kPC8T8H+5E//84poYSFHE4pA+Ff68UANP2/EuFJWMjegiefnOr8aM42OAcUkjEWSlautIIX8
oD2GizwQYjWdDDjEonbuMKFP6rY2xGI3PSLI3IVU2opb0/itNhQui3WRxafloJqTlriY8m8+
qSLr2HGftbBlbyzVWB8o//aW0H0LMabjkIvrm7Zmh2vcCxiSxGBwYASuSYXGuQiKAgGptUs1
XJLZuzGCA9owggPWAgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20g
THRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG
A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EC
Ah5jMAkGBSsOAwIaBQCgggIbMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcN
AQkFMQ8XDTEyMDkwNzEyNDQwMVowIwYJKoZIhvcNAQkEMRYEFDzlLWpY1NtwVM26xxH5BLID
NF87MGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggqhkiG
9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcN
AwICASgwgaQGCSsGAQQBgjcQBDGBljCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0
YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25p
bmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp
ZW50IENBAgIeYzCBpgYLKoZIhvcNAQkQAgsxgZaggZMwgYwxCzAJBgNVBAYTAklMMRYwFAYD
VQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0
ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRp
YXRlIENsaWVudCBDQQICHmMwDQYJKoZIhvcNAQEBBQAEggEAHtRhRWVrhDfwKdQHUyRxqXTJ
XY7rrtUOfe7Tvr/N/S0LRNrx/9dR0fORbPS7nY0ylrOY8kVlxUgAykJgsnqC/Z+CX+l3sQQJ
KvWE6Pr70IVNifb24q5lsnOChHLCSnLJGV4nFi9/Bi+q4OuphLfoI+uCcMBuyaDBwtA3JF9w
obQJj/6rgnqopc24O1vCUe0oWiVypp4m/eYURIRQH+wxZZZB2tNv9MvyJy+hmJ73ZhaJ2359
L8IxRwFFUpotUegO1TKo0xL0YNumQlZbE8Od12kF+UbW3U4kZdxWEgaooP1Q1Y/EwGtBZRi8
YWO0+gNgHzPMSTrcJmXTOakLA1t/bAAAAAAAAA==
--------------ms020308090302010502000504--


--===============7578888010532444193==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============7578888010532444193==--


From xen-devel-bounces@lists.xen.org Fri Sep 07 12:45:00 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Sep 2012 12:45:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9xvT-000460-IK; Fri, 07 Sep 2012 12:44:47 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1T9xvS-00045h-Dx
	for xen-devel@lists.xen.org; Fri, 07 Sep 2012 12:44:46 +0000
Received: from [85.158.138.51:59857] by server-9.bemta-3.messagelabs.com id
	8A/B1-15390-D3CE9405; Fri, 07 Sep 2012 12:44:45 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1347021884!27593781!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM4ODU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8910 invoked from network); 7 Sep 2012 12:44: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;
	7 Sep 2012 12:44:44 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 07 Sep 2012 13:44:44 +0100
Message-Id: <504A08930200007800099C9A@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 07 Sep 2012 13:45:39 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__PartFECFEA63.1__="
Cc: xiantao.zhang@intel.com
Subject: [Xen-devel] [PATCH] VT-d: split .ack and .disable DMA-MSI actors
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<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.

--=__PartFECFEA63.1__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Calling irq_complete_move() from .disable is wrong, breaking S3 resume.

Comparing with all other .ack actors, it was also missing a call to
move_{native,masked}_irq(). As the actor is masking its interrupt
anyway (albeit it's not immediately obvious why), the latter is the
better choice.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/drivers/passthrough/vtd/iommu.c
+++ b/xen/drivers/passthrough/vtd/iommu.c
@@ -1039,8 +1039,6 @@ static void dma_msi_mask(struct irq_desc
     unsigned long flags;
     struct iommu *iommu =3D desc->action->dev_id;
=20
-    irq_complete_move(desc);
-
     /* mask it */
     spin_lock_irqsave(&iommu->register_lock, flags);
     dmar_writel(iommu->reg, DMAR_FECTL_REG, DMA_FECTL_IM);
@@ -1053,6 +1051,13 @@ static unsigned int dma_msi_startup(stru
     return 0;
 }
=20
+static void dma_msi_ack(struct irq_desc *desc)
+{
+    irq_complete_move(desc);
+    dma_msi_mask(desc);
+    move_masked_irq(desc);
+}
+
 static void dma_msi_end(struct irq_desc *desc, u8 vector)
 {
     dma_msi_unmask(desc);
@@ -1114,7 +1119,7 @@ static hw_irq_controller dma_msi_type =3D=20
     .shutdown =3D dma_msi_mask,
     .enable =3D dma_msi_unmask,
     .disable =3D dma_msi_mask,
-    .ack =3D dma_msi_mask,
+    .ack =3D dma_msi_ack,
     .end =3D dma_msi_end,
     .set_affinity =3D dma_msi_set_affinity,
 };




--=__PartFECFEA63.1__=
Content-Type: text/plain; name="VT-d-S3-MSI-resume.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="VT-d-S3-MSI-resume.patch"

VT-d: split .ack and .disable DMA-MSI actors=0A=0ACalling irq_complete_move=
() from .disable is wrong, breaking S3 resume.=0A=0AComparing with all =
other .ack actors, it was also missing a call to=0Amove_{native,masked}_irq=
(). As the actor is masking its interrupt=0Aanyway (albeit it's not =
immediately obvious why), the latter is the=0Abetter choice.=0A=0ASigned-of=
f-by: Jan Beulich <jbeulich@suse.com>=0A=0A--- a/xen/drivers/passthrough/vt=
d/iommu.c=0A+++ b/xen/drivers/passthrough/vtd/iommu.c=0A@@ -1039,8 +1039,6 =
@@ static void dma_msi_mask(struct irq_desc=0A     unsigned long flags;=0A =
    struct iommu *iommu =3D desc->action->dev_id;=0A =0A-    irq_complete_m=
ove(desc);=0A-=0A     /* mask it */=0A     spin_lock_irqsave(&iommu->regist=
er_lock, flags);=0A     dmar_writel(iommu->reg, DMAR_FECTL_REG, DMA_FECTL_I=
M);=0A@@ -1053,6 +1051,13 @@ static unsigned int dma_msi_startup(stru=0A   =
  return 0;=0A }=0A =0A+static void dma_msi_ack(struct irq_desc *desc)=0A+{=
=0A+    irq_complete_move(desc);=0A+    dma_msi_mask(desc);=0A+    =
move_masked_irq(desc);=0A+}=0A+=0A static void dma_msi_end(struct irq_desc =
*desc, u8 vector)=0A {=0A     dma_msi_unmask(desc);=0A@@ -1114,7 +1119,7 =
@@ static hw_irq_controller dma_msi_type =3D =0A     .shutdown =3D =
dma_msi_mask,=0A     .enable =3D dma_msi_unmask,=0A     .disable =3D =
dma_msi_mask,=0A-    .ack =3D dma_msi_mask,=0A+    .ack =3D dma_msi_ack,=0A=
     .end =3D dma_msi_end,=0A     .set_affinity =3D dma_msi_set_affinity,=
=0A };=0A
--=__PartFECFEA63.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

--=__PartFECFEA63.1__=--


From xen-devel-bounces@lists.xen.org Fri Sep 07 12:45:00 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Sep 2012 12:45:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9xvT-000460-IK; Fri, 07 Sep 2012 12:44:47 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1T9xvS-00045h-Dx
	for xen-devel@lists.xen.org; Fri, 07 Sep 2012 12:44:46 +0000
Received: from [85.158.138.51:59857] by server-9.bemta-3.messagelabs.com id
	8A/B1-15390-D3CE9405; Fri, 07 Sep 2012 12:44:45 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1347021884!27593781!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM4ODU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8910 invoked from network); 7 Sep 2012 12:44: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;
	7 Sep 2012 12:44:44 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 07 Sep 2012 13:44:44 +0100
Message-Id: <504A08930200007800099C9A@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 07 Sep 2012 13:45:39 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__PartFECFEA63.1__="
Cc: xiantao.zhang@intel.com
Subject: [Xen-devel] [PATCH] VT-d: split .ack and .disable DMA-MSI actors
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<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.

--=__PartFECFEA63.1__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Calling irq_complete_move() from .disable is wrong, breaking S3 resume.

Comparing with all other .ack actors, it was also missing a call to
move_{native,masked}_irq(). As the actor is masking its interrupt
anyway (albeit it's not immediately obvious why), the latter is the
better choice.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/drivers/passthrough/vtd/iommu.c
+++ b/xen/drivers/passthrough/vtd/iommu.c
@@ -1039,8 +1039,6 @@ static void dma_msi_mask(struct irq_desc
     unsigned long flags;
     struct iommu *iommu =3D desc->action->dev_id;
=20
-    irq_complete_move(desc);
-
     /* mask it */
     spin_lock_irqsave(&iommu->register_lock, flags);
     dmar_writel(iommu->reg, DMAR_FECTL_REG, DMA_FECTL_IM);
@@ -1053,6 +1051,13 @@ static unsigned int dma_msi_startup(stru
     return 0;
 }
=20
+static void dma_msi_ack(struct irq_desc *desc)
+{
+    irq_complete_move(desc);
+    dma_msi_mask(desc);
+    move_masked_irq(desc);
+}
+
 static void dma_msi_end(struct irq_desc *desc, u8 vector)
 {
     dma_msi_unmask(desc);
@@ -1114,7 +1119,7 @@ static hw_irq_controller dma_msi_type =3D=20
     .shutdown =3D dma_msi_mask,
     .enable =3D dma_msi_unmask,
     .disable =3D dma_msi_mask,
-    .ack =3D dma_msi_mask,
+    .ack =3D dma_msi_ack,
     .end =3D dma_msi_end,
     .set_affinity =3D dma_msi_set_affinity,
 };




--=__PartFECFEA63.1__=
Content-Type: text/plain; name="VT-d-S3-MSI-resume.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="VT-d-S3-MSI-resume.patch"

VT-d: split .ack and .disable DMA-MSI actors=0A=0ACalling irq_complete_move=
() from .disable is wrong, breaking S3 resume.=0A=0AComparing with all =
other .ack actors, it was also missing a call to=0Amove_{native,masked}_irq=
(). As the actor is masking its interrupt=0Aanyway (albeit it's not =
immediately obvious why), the latter is the=0Abetter choice.=0A=0ASigned-of=
f-by: Jan Beulich <jbeulich@suse.com>=0A=0A--- a/xen/drivers/passthrough/vt=
d/iommu.c=0A+++ b/xen/drivers/passthrough/vtd/iommu.c=0A@@ -1039,8 +1039,6 =
@@ static void dma_msi_mask(struct irq_desc=0A     unsigned long flags;=0A =
    struct iommu *iommu =3D desc->action->dev_id;=0A =0A-    irq_complete_m=
ove(desc);=0A-=0A     /* mask it */=0A     spin_lock_irqsave(&iommu->regist=
er_lock, flags);=0A     dmar_writel(iommu->reg, DMAR_FECTL_REG, DMA_FECTL_I=
M);=0A@@ -1053,6 +1051,13 @@ static unsigned int dma_msi_startup(stru=0A   =
  return 0;=0A }=0A =0A+static void dma_msi_ack(struct irq_desc *desc)=0A+{=
=0A+    irq_complete_move(desc);=0A+    dma_msi_mask(desc);=0A+    =
move_masked_irq(desc);=0A+}=0A+=0A static void dma_msi_end(struct irq_desc =
*desc, u8 vector)=0A {=0A     dma_msi_unmask(desc);=0A@@ -1114,7 +1119,7 =
@@ static hw_irq_controller dma_msi_type =3D =0A     .shutdown =3D =
dma_msi_mask,=0A     .enable =3D dma_msi_unmask,=0A     .disable =3D =
dma_msi_mask,=0A-    .ack =3D dma_msi_mask,=0A+    .ack =3D dma_msi_ack,=0A=
     .end =3D dma_msi_end,=0A     .set_affinity =3D dma_msi_set_affinity,=
=0A };=0A
--=__PartFECFEA63.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

--=__PartFECFEA63.1__=--


From xen-devel-bounces@lists.xen.org Fri Sep 07 12:45:40 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Sep 2012 12:45:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9xw8-0004C7-Vv; Fri, 07 Sep 2012 12:45: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 1T9xw7-0004Ba-Fg
	for xen-devel@lists.xen.org; Fri, 07 Sep 2012 12:45:27 +0000
Received: from [85.158.138.51:7537] by server-9.bemta-3.messagelabs.com id
	CF/73-15390-66CE9405; Fri, 07 Sep 2012 12:45:26 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1347021925!29264220!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTIyMTE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23915 invoked from network); 7 Sep 2012 12:45:26 -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;
	7 Sep 2012 12:45:26 -0000
X-IronPort-AV: E=Sophos;i="4.80,385,1344211200"; d="scan'208";a="14409255"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Sep 2012 12:45: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.279.1; Fri, 7 Sep 2012
	13:45:25 +0100
Message-ID: <1347021923.30018.89.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>, Jan Beulich
	<JBeulich@suse.com>
Date: Fri, 7 Sep 2012 13:45:23 +0100
In-Reply-To: <241186e96a1ece42ad3b.1346662698@cosworth.uk.xensource.com>
References: <241186e96a1ece42ad3b.1346662698@cosworth.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Andrew Cooper <Andrew.Cooper3@citrix.com>, Matt Wilson <msw@amazon.com>
Subject: Re: [Xen-devel] [PATCH] docs: remove WIP notive from command line
 docs
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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-09-03 at 09:58 +0100, Ian Campbell wrote:
> # HG changeset patch
> # User Ian Campbell <ian.campbell@citrix.com>
> # Date 1346662653 -3600
> # Node ID 241186e96a1ece42ad3bd14901b62d872f4abd9e
> # Parent  931134b81005ced9f3dc4080fbf66597da6aeb0e
> docs: remove WIP notive from command line docs.
> 
> I'm sure they aren't perfect but various people have done a pass over
> them recently and they are much improved. I don't think we need to
> continue to describe them so pessimistically.
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

Ian Jackson Acked this IRL and I have pushed it to unstable.

Jan, can we have this for 4.2 as well please.

Ian.

> 
> diff -r 931134b81005 -r 241186e96a1e docs/misc/xen-command-line.markdown
> --- a/docs/misc/xen-command-line.markdown	Mon Sep 03 09:55:37 2012 +0100
> +++ b/docs/misc/xen-command-line.markdown	Mon Sep 03 09:57:33 2012 +0100
> @@ -1,10 +1,5 @@
>  # Xen Hypervisor Command Line Options
>  
> -**This document is still a work in progress.  There are currently some
> -  command line options listed twice, and they are defined in separate
> -  arch trees, and some options are currently separate from their
> -  legacy versions.  Please remove this notice when complete.**
> -
>  This document covers the command line options which the Xen
>  Hypervisor.
>  
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Sep 07 12:45:40 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Sep 2012 12:45:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9xw8-0004C7-Vv; Fri, 07 Sep 2012 12:45: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 1T9xw7-0004Ba-Fg
	for xen-devel@lists.xen.org; Fri, 07 Sep 2012 12:45:27 +0000
Received: from [85.158.138.51:7537] by server-9.bemta-3.messagelabs.com id
	CF/73-15390-66CE9405; Fri, 07 Sep 2012 12:45:26 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1347021925!29264220!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTIyMTE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23915 invoked from network); 7 Sep 2012 12:45:26 -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;
	7 Sep 2012 12:45:26 -0000
X-IronPort-AV: E=Sophos;i="4.80,385,1344211200"; d="scan'208";a="14409255"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Sep 2012 12:45: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.279.1; Fri, 7 Sep 2012
	13:45:25 +0100
Message-ID: <1347021923.30018.89.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>, Jan Beulich
	<JBeulich@suse.com>
Date: Fri, 7 Sep 2012 13:45:23 +0100
In-Reply-To: <241186e96a1ece42ad3b.1346662698@cosworth.uk.xensource.com>
References: <241186e96a1ece42ad3b.1346662698@cosworth.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Andrew Cooper <Andrew.Cooper3@citrix.com>, Matt Wilson <msw@amazon.com>
Subject: Re: [Xen-devel] [PATCH] docs: remove WIP notive from command line
 docs
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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-09-03 at 09:58 +0100, Ian Campbell wrote:
> # HG changeset patch
> # User Ian Campbell <ian.campbell@citrix.com>
> # Date 1346662653 -3600
> # Node ID 241186e96a1ece42ad3bd14901b62d872f4abd9e
> # Parent  931134b81005ced9f3dc4080fbf66597da6aeb0e
> docs: remove WIP notive from command line docs.
> 
> I'm sure they aren't perfect but various people have done a pass over
> them recently and they are much improved. I don't think we need to
> continue to describe them so pessimistically.
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

Ian Jackson Acked this IRL and I have pushed it to unstable.

Jan, can we have this for 4.2 as well please.

Ian.

> 
> diff -r 931134b81005 -r 241186e96a1e docs/misc/xen-command-line.markdown
> --- a/docs/misc/xen-command-line.markdown	Mon Sep 03 09:55:37 2012 +0100
> +++ b/docs/misc/xen-command-line.markdown	Mon Sep 03 09:57:33 2012 +0100
> @@ -1,10 +1,5 @@
>  # Xen Hypervisor Command Line Options
>  
> -**This document is still a work in progress.  There are currently some
> -  command line options listed twice, and they are defined in separate
> -  arch trees, and some options are currently separate from their
> -  legacy versions.  Please remove this notice when complete.**
> -
>  This document covers the command line options which the Xen
>  Hypervisor.
>  
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Sep 07 12:48:42 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Sep 2012 12:48:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9xz4-0004UV-Jy; Fri, 07 Sep 2012 12:48: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 1T9xz2-0004UL-SB
	for xen-devel@lists.xen.org; Fri, 07 Sep 2012 12:48:29 +0000
Received: from [85.158.138.51:37329] by server-4.bemta-3.messagelabs.com id
	9D/15-24831-B1DE9405; Fri, 07 Sep 2012 12:48:27 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1347022107!21196226!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM4ODU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11839 invoked from network); 7 Sep 2012 12:48:27 -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;
	7 Sep 2012 12:48:27 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 07 Sep 2012 13:48:26 +0100
Message-Id: <504A09720200007800099CBD@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 07 Sep 2012 13:49:22 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__PartDEEFCA42.0__="
Subject: [Xen-devel] [PATCH] x86/MSI: fix 2nd S3 resume with interrupt
 remapping 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>
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.

--=__PartDEEFCA42.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

The first resume from S3 was corrupting internal data structures (in
that pci_restore_msi_state() updated the globally stored MSI message
from traditional to interrupt remapped format, which would then be
translated a second time during the second resume, breaking interrupt
delivery).

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- 2012-08-08.orig/xen/arch/x86/msi.c	2012-09-07 13:39:02.000000000 =
+0200
+++ 2012-08-08/xen/arch/x86/msi.c	2012-09-06 12:04:11.000000000 =
+0200
@@ -210,7 +210,10 @@ static void write_msi_msg(struct msi_des
     entry->msg =3D *msg;
=20
     if ( iommu_enabled )
+    {
+        ASSERT(msg !=3D &entry->msg);
         iommu_update_ire_from_msi(entry, msg);
+    }
=20
     switch ( entry->msi_attrib.type )
     {
@@ -996,6 +999,7 @@ int pci_restore_msi_state(struct pci_dev
     int ret;
     struct msi_desc *entry, *tmp;
     struct irq_desc *desc;
+    struct msi_msg msg;
=20
     ASSERT(spin_is_locked(&pcidevs_lock));
=20
@@ -1030,7 +1034,8 @@ int pci_restore_msi_state(struct pci_dev
         else if ( entry->msi_attrib.type =3D=3D PCI_CAP_ID_MSIX )
             msix_set_enable(pdev, 0);
=20
-        write_msi_msg(entry, &entry->msg);
+        msg =3D entry->msg;
+        write_msi_msg(entry, &msg);
=20
         msi_set_mask_bit(desc, entry->msi_attrib.masked);
=20




--=__PartDEEFCA42.0__=
Content-Type: text/plain; name="x86-S3-MSI-resume.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="x86-S3-MSI-resume.patch"

x86/MSI: fix 2nd S3 resume with interrupt remapping enabled=0A=0AThe first =
resume from S3 was corrupting internal data structures (in=0Athat =
pci_restore_msi_state() updated the globally stored MSI message=0Afrom =
traditional to interrupt remapped format, which would then be=0Atranslated =
a second time during the second resume, breaking interrupt=0Adelivery).=0A=
=0ASigned-off-by: Jan Beulich <jbeulich@suse.com>=0A=0A--- 2012-08-08.orig/=
xen/arch/x86/msi.c	2012-09-07 13:39:02.000000000 +0200=0A+++ =
2012-08-08/xen/arch/x86/msi.c	2012-09-06 12:04:11.000000000 +0200=0A@@ =
-210,7 +210,10 @@ static void write_msi_msg(struct msi_des=0A     =
entry->msg =3D *msg;=0A =0A     if ( iommu_enabled )=0A+    {=0A+        =
ASSERT(msg !=3D &entry->msg);=0A         iommu_update_ire_from_msi(entry, =
msg);=0A+    }=0A =0A     switch ( entry->msi_attrib.type )=0A     {=0A@@ =
-996,6 +999,7 @@ int pci_restore_msi_state(struct pci_dev=0A     int =
ret;=0A     struct msi_desc *entry, *tmp;=0A     struct irq_desc *desc;=0A+=
    struct msi_msg msg;=0A =0A     ASSERT(spin_is_locked(&pcidevs_lock));=
=0A =0A@@ -1030,7 +1034,8 @@ int pci_restore_msi_state(struct pci_dev=0A   =
      else if ( entry->msi_attrib.type =3D=3D PCI_CAP_ID_MSIX )=0A         =
    msix_set_enable(pdev, 0);=0A =0A-        write_msi_msg(entry, =
&entry->msg);=0A+        msg =3D entry->msg;=0A+        write_msi_msg(entry=
, &msg);=0A =0A         msi_set_mask_bit(desc, entry->msi_attrib.masked);=
=0A =0A
--=__PartDEEFCA42.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

--=__PartDEEFCA42.0__=--


From xen-devel-bounces@lists.xen.org Fri Sep 07 12:48:42 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Sep 2012 12:48:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9xz4-0004UV-Jy; Fri, 07 Sep 2012 12:48: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 1T9xz2-0004UL-SB
	for xen-devel@lists.xen.org; Fri, 07 Sep 2012 12:48:29 +0000
Received: from [85.158.138.51:37329] by server-4.bemta-3.messagelabs.com id
	9D/15-24831-B1DE9405; Fri, 07 Sep 2012 12:48:27 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1347022107!21196226!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM4ODU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11839 invoked from network); 7 Sep 2012 12:48:27 -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;
	7 Sep 2012 12:48:27 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 07 Sep 2012 13:48:26 +0100
Message-Id: <504A09720200007800099CBD@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 07 Sep 2012 13:49:22 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__PartDEEFCA42.0__="
Subject: [Xen-devel] [PATCH] x86/MSI: fix 2nd S3 resume with interrupt
 remapping 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>
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.

--=__PartDEEFCA42.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

The first resume from S3 was corrupting internal data structures (in
that pci_restore_msi_state() updated the globally stored MSI message
from traditional to interrupt remapped format, which would then be
translated a second time during the second resume, breaking interrupt
delivery).

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- 2012-08-08.orig/xen/arch/x86/msi.c	2012-09-07 13:39:02.000000000 =
+0200
+++ 2012-08-08/xen/arch/x86/msi.c	2012-09-06 12:04:11.000000000 =
+0200
@@ -210,7 +210,10 @@ static void write_msi_msg(struct msi_des
     entry->msg =3D *msg;
=20
     if ( iommu_enabled )
+    {
+        ASSERT(msg !=3D &entry->msg);
         iommu_update_ire_from_msi(entry, msg);
+    }
=20
     switch ( entry->msi_attrib.type )
     {
@@ -996,6 +999,7 @@ int pci_restore_msi_state(struct pci_dev
     int ret;
     struct msi_desc *entry, *tmp;
     struct irq_desc *desc;
+    struct msi_msg msg;
=20
     ASSERT(spin_is_locked(&pcidevs_lock));
=20
@@ -1030,7 +1034,8 @@ int pci_restore_msi_state(struct pci_dev
         else if ( entry->msi_attrib.type =3D=3D PCI_CAP_ID_MSIX )
             msix_set_enable(pdev, 0);
=20
-        write_msi_msg(entry, &entry->msg);
+        msg =3D entry->msg;
+        write_msi_msg(entry, &msg);
=20
         msi_set_mask_bit(desc, entry->msi_attrib.masked);
=20




--=__PartDEEFCA42.0__=
Content-Type: text/plain; name="x86-S3-MSI-resume.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="x86-S3-MSI-resume.patch"

x86/MSI: fix 2nd S3 resume with interrupt remapping enabled=0A=0AThe first =
resume from S3 was corrupting internal data structures (in=0Athat =
pci_restore_msi_state() updated the globally stored MSI message=0Afrom =
traditional to interrupt remapped format, which would then be=0Atranslated =
a second time during the second resume, breaking interrupt=0Adelivery).=0A=
=0ASigned-off-by: Jan Beulich <jbeulich@suse.com>=0A=0A--- 2012-08-08.orig/=
xen/arch/x86/msi.c	2012-09-07 13:39:02.000000000 +0200=0A+++ =
2012-08-08/xen/arch/x86/msi.c	2012-09-06 12:04:11.000000000 +0200=0A@@ =
-210,7 +210,10 @@ static void write_msi_msg(struct msi_des=0A     =
entry->msg =3D *msg;=0A =0A     if ( iommu_enabled )=0A+    {=0A+        =
ASSERT(msg !=3D &entry->msg);=0A         iommu_update_ire_from_msi(entry, =
msg);=0A+    }=0A =0A     switch ( entry->msi_attrib.type )=0A     {=0A@@ =
-996,6 +999,7 @@ int pci_restore_msi_state(struct pci_dev=0A     int =
ret;=0A     struct msi_desc *entry, *tmp;=0A     struct irq_desc *desc;=0A+=
    struct msi_msg msg;=0A =0A     ASSERT(spin_is_locked(&pcidevs_lock));=
=0A =0A@@ -1030,7 +1034,8 @@ int pci_restore_msi_state(struct pci_dev=0A   =
      else if ( entry->msi_attrib.type =3D=3D PCI_CAP_ID_MSIX )=0A         =
    msix_set_enable(pdev, 0);=0A =0A-        write_msi_msg(entry, =
&entry->msg);=0A+        msg =3D entry->msg;=0A+        write_msi_msg(entry=
, &msg);=0A =0A         msi_set_mask_bit(desc, entry->msi_attrib.masked);=
=0A =0A
--=__PartDEEFCA42.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

--=__PartDEEFCA42.0__=--


From xen-devel-bounces@lists.xen.org Fri Sep 07 12:55:45 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Sep 2012 12:55:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9y5s-0004hb-GQ; Fri, 07 Sep 2012 12:55:32 +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 1T9y5r-0004hW-73
	for xen-devel@lists.xen.org; Fri, 07 Sep 2012 12:55:31 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1347022521!9485422!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM4ODU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25656 invoked from network); 7 Sep 2012 12:55:21 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-4.tower-27.messagelabs.com with SMTP;
	7 Sep 2012 12:55:21 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 07 Sep 2012 13:55:20 +0100
Message-Id: <504A0B110200007800099CCD@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 07 Sep 2012 13:56:17 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part7E4F6AE1.0__="
Subject: [Xen-devel] [PATCH] adjust a few RCU domain locking calls
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
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.

--=__Part7E4F6AE1.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

x86's do_physdev_op() had a case where the locking was entirely
superfluous. Its physdev_map_pirq() further had a case where the lock
was being obtained too early, needlessly complicating early exit paths.

Grant table code had two open coded instances of
rcu_lock_target_domain_by_id(), and a third code section could be
consolidated by using the newly introduced helper function.

The memory hypercall code had two more instances of open coding
rcu_lock_target_domain_by_id(), but note that here this is not just
cleanup, but also fixes an error return path in memory_exchange() to
actually return an error.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/arch/x86/physdev.c
+++ b/xen/arch/x86/physdev.c
@@ -90,14 +90,10 @@ static int physdev_hvm_map_pirq(
 int physdev_map_pirq(domid_t domid, int type, int *index, int *pirq_p,
                      struct msi_info *msi)
 {
-    struct domain *d;
+    struct domain *d =3D current->domain;
     int pirq, irq, ret =3D 0;
     void *map_data =3D NULL;
=20
-    ret =3D rcu_lock_target_domain_by_id(domid, &d);
-    if ( ret )
-        return ret;
-
     if ( domid =3D=3D DOMID_SELF && is_hvm_domain(d) )
     {
         /*
@@ -105,14 +101,15 @@ int physdev_map_pirq(domid_t domid, int=20
          * calls back into itself and deadlocks on hvm_domain.irq_lock.
          */
         if ( !is_hvm_pv_evtchn_domain(d) )
-        {
-            ret =3D -EINVAL;
-            goto free_domain;
-        }
-        ret =3D physdev_hvm_map_pirq(d, type, index, pirq_p);
-        goto free_domain;
+            return -EINVAL;
+
+        return physdev_hvm_map_pirq(d, type, index, pirq_p);
     }
=20
+    ret =3D rcu_lock_target_domain_by_id(domid, &d);
+    if ( ret )
+        return ret;
+
     if ( !IS_PRIV_FOR(current->domain, d) )
     {
         ret =3D -EPERM;
@@ -696,13 +693,12 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_H
     }
     case PHYSDEVOP_get_free_pirq: {
         struct physdev_get_free_pirq out;
-        struct domain *d;
+        struct domain *d =3D v->domain;
=20
         ret =3D -EFAULT;
         if ( copy_from_guest(&out, arg, 1) !=3D 0 )
             break;
=20
-        d =3D rcu_lock_current_domain();
         spin_lock(&d->event_lock);
=20
         ret =3D get_free_pirq(d, out.type);
@@ -717,7 +713,6 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_H
         }
=20
         spin_unlock(&d->event_lock);
-        rcu_unlock_domain(d);
=20
         if ( ret >=3D 0 )
         {
--- a/xen/common/grant_table.c
+++ b/xen/common/grant_table.c
@@ -24,7 +24,7 @@
  * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  =
USA
  */
=20
-#include <xen/config.h>
+#include <xen/err.h>
 #include <xen/iocap.h>
 #include <xen/lib.h>
 #include <xen/sched.h>
@@ -195,6 +195,30 @@ double_gt_unlock(struct grant_table *lgt
         spin_unlock(&rgt->lock);
 }
=20
+static struct domain *gt_lock_target_domain_by_id(domid_t dom)
+{
+    struct domain *d;
+    int rc =3D GNTST_general_error;
+
+    switch ( rcu_lock_target_domain_by_id(dom, &d) )
+    {
+    case 0:
+        return d;
+
+    case -ESRCH:
+        gdprintk(XENLOG_INFO, "Bad domid %d.\n", dom);
+        rc =3D GNTST_bad_domain;
+        break;
+
+    case -EPERM:
+        rc =3D GNTST_permission_denied;
+        break;
+    }
+
+    ASSERT(rc < 0 && -rc <=3D MAX_ERRNO);
+    return ERR_PTR(rc);
+}
+
 static inline int
 __get_maptrack_handle(
     struct grant_table *t)
@@ -1261,7 +1285,6 @@ gnttab_setup_table(
     struct grant_table *gt;
     int            i;
     unsigned long  gmfn;
-    domid_t        dom;
=20
     if ( count !=3D 1 )
         return -EINVAL;
@@ -1281,25 +1304,11 @@ gnttab_setup_table(
         goto out1;
     }
=20
-    dom =3D op.dom;
-    if ( dom =3D=3D DOMID_SELF )
+    d =3D gt_lock_target_domain_by_id(op.dom);
+    if ( IS_ERR(d) )
     {
-        d =3D rcu_lock_current_domain();
-    }
-    else
-    {
-        if ( unlikely((d =3D rcu_lock_domain_by_id(dom)) =3D=3D NULL) )
-        {
-            gdprintk(XENLOG_INFO, "Bad domid %d.\n", dom);
-            op.status =3D GNTST_bad_domain;
-            goto out1;
-        }
-
-        if ( unlikely(!IS_PRIV_FOR(current->domain, d)) )
-        {
-            op.status =3D GNTST_permission_denied;
-            goto out2;
-        }
+        op.status =3D PTR_ERR(d);
+        goto out1;
     }
=20
     if ( xsm_grant_setup(current->domain, d) )
@@ -1352,7 +1361,6 @@ gnttab_query_size(
 {
     struct gnttab_query_size op;
     struct domain *d;
-    domid_t        dom;
     int rc;
=20
     if ( count !=3D 1 )
@@ -1364,25 +1372,11 @@ gnttab_query_size(
         return -EFAULT;
     }
=20
-    dom =3D op.dom;
-    if ( dom =3D=3D DOMID_SELF )
-    {
-        d =3D rcu_lock_current_domain();
-    }
-    else
+    d =3D gt_lock_target_domain_by_id(op.dom);
+    if ( IS_ERR(d) )
     {
-        if ( unlikely((d =3D rcu_lock_domain_by_id(dom)) =3D=3D NULL) )
-        {
-            gdprintk(XENLOG_INFO, "Bad domid %d.\n", dom);
-            op.status =3D GNTST_bad_domain;
-            goto query_out;
-        }
-
-        if ( unlikely(!IS_PRIV_FOR(current->domain, d)) )
-        {
-            op.status =3D GNTST_permission_denied;
-            goto query_out_unlock;
-        }
+        op.status =3D PTR_ERR(d);
+        goto query_out;
     }
=20
     rc =3D xsm_grant_query_size(current->domain, d);
@@ -2240,15 +2234,10 @@ gnttab_get_status_frames(XEN_GUEST_HANDL
         return -EFAULT;
     }
=20
-    rc =3D rcu_lock_target_domain_by_id(op.dom, &d);
-    if ( rc < 0 )
+    d =3D gt_lock_target_domain_by_id(op.dom);
+    if ( IS_ERR(d) )
     {
-        if ( rc =3D=3D -ESRCH )
-            op.status =3D GNTST_bad_domain;
-        else if ( rc =3D=3D -EPERM )
-            op.status =3D GNTST_permission_denied;
-        else
-            op.status =3D GNTST_general_error;
+        op.status =3D PTR_ERR(d);
         goto out1;
     }
     rc =3D xsm_grant_setup(current->domain, d);
--- a/xen/common/memory.c
+++ b/xen/common/memory.c
@@ -329,22 +329,9 @@ static long memory_exchange(XEN_GUEST_HA
         out_chunk_order =3D exch.in.extent_order - exch.out.extent_order;
     }
=20
-    if ( likely(exch.in.domid =3D=3D DOMID_SELF) )
-    {
-        d =3D rcu_lock_current_domain();
-    }
-    else
-    {
-        if ( (d =3D rcu_lock_domain_by_id(exch.in.domid)) =3D=3D NULL )
-            goto fail_early;
-
-        if ( !IS_PRIV_FOR(current->domain, d) )
-        {
-            rcu_unlock_domain(d);
-            rc =3D -EPERM;
-            goto fail_early;
-        }
-    }
+    rc =3D rcu_lock_target_domain_by_id(exch.in.domid, &d);
+    if ( rc )
+        goto fail_early;
=20
     memflags |=3D MEMF_bits(domain_clamp_alloc_bitsize(
         d,
@@ -583,20 +570,8 @@ long do_memory_op(unsigned long cmd, XEN
              && (reservation.mem_flags & XENMEMF_populate_on_demand) )
             args.memflags |=3D MEMF_populate_on_demand;
=20
-        if ( likely(reservation.domid =3D=3D DOMID_SELF) )
-        {
-            d =3D rcu_lock_current_domain();
-        }
-        else
-        {
-            if ( (d =3D rcu_lock_domain_by_id(reservation.domid)) =3D=3D =
NULL )
-                return start_extent;
-            if ( !IS_PRIV_FOR(current->domain, d) )
-            {
-                rcu_unlock_domain(d);
-                return start_extent;
-            }
-        }
+        if ( unlikely(rcu_lock_target_domain_by_id(reservation.domid, =
&d)) )
+            return start_extent;
         args.domain =3D d;
=20
         rc =3D xsm_memory_adjust_reservation(current->domain, d);



--=__Part7E4F6AE1.0__=
Content-Type: text/plain; name="adjust-rcu-lock-domain.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="adjust-rcu-lock-domain.patch"

adjust a few RCU domain locking calls=0A=0Ax86's do_physdev_op() had a =
case where the locking was entirely=0Asuperfluous. Its physdev_map_pirq() =
further had a case where the lock=0Awas being obtained too early, =
needlessly complicating early exit paths.=0A=0AGrant table code had two =
open coded instances of=0Arcu_lock_target_domain_by_id(), and a third code =
section could be=0Aconsolidated by using the newly introduced helper =
function.=0A=0AThe memory hypercall code had two more instances of open =
coding=0Arcu_lock_target_domain_by_id(), but note that here this is not =
just=0Acleanup, but also fixes an error return path in memory_exchange() =
to=0Aactually return an error.=0A=0ASigned-off-by: Jan Beulich <jbeulich@su=
se.com>=0A=0A--- a/xen/arch/x86/physdev.c=0A+++ b/xen/arch/x86/physdev.c=0A=
@@ -90,14 +90,10 @@ static int physdev_hvm_map_pirq(=0A int physdev_map_pir=
q(domid_t domid, int type, int *index, int *pirq_p,=0A                     =
 struct msi_info *msi)=0A {=0A-    struct domain *d;=0A+    struct domain =
*d =3D current->domain;=0A     int pirq, irq, ret =3D 0;=0A     void =
*map_data =3D NULL;=0A =0A-    ret =3D rcu_lock_target_domain_by_id(domid, =
&d);=0A-    if ( ret )=0A-        return ret;=0A-=0A     if ( domid =3D=3D =
DOMID_SELF && is_hvm_domain(d) )=0A     {=0A         /*=0A@@ -105,14 =
+101,15 @@ int physdev_map_pirq(domid_t domid, int =0A          * calls =
back into itself and deadlocks on hvm_domain.irq_lock.=0A          */=0A   =
      if ( !is_hvm_pv_evtchn_domain(d) )=0A-        {=0A-            ret =
=3D -EINVAL;=0A-            goto free_domain;=0A-        }=0A-        ret =
=3D physdev_hvm_map_pirq(d, type, index, pirq_p);=0A-        goto =
free_domain;=0A+            return -EINVAL;=0A+=0A+        return =
physdev_hvm_map_pirq(d, type, index, pirq_p);=0A     }=0A =0A+    ret =3D =
rcu_lock_target_domain_by_id(domid, &d);=0A+    if ( ret )=0A+        =
return ret;=0A+=0A     if ( !IS_PRIV_FOR(current->domain, d) )=0A     {=0A =
        ret =3D -EPERM;=0A@@ -696,13 +693,12 @@ ret_t do_physdev_op(int =
cmd, XEN_GUEST_H=0A     }=0A     case PHYSDEVOP_get_free_pirq: {=0A        =
 struct physdev_get_free_pirq out;=0A-        struct domain *d;=0A+        =
struct domain *d =3D v->domain;=0A =0A         ret =3D -EFAULT;=0A         =
if ( copy_from_guest(&out, arg, 1) !=3D 0 )=0A             break;=0A =0A-  =
      d =3D rcu_lock_current_domain();=0A         spin_lock(&d->event_lock)=
;=0A =0A         ret =3D get_free_pirq(d, out.type);=0A@@ -717,7 +713,6 @@ =
ret_t do_physdev_op(int cmd, XEN_GUEST_H=0A         }=0A =0A         =
spin_unlock(&d->event_lock);=0A-        rcu_unlock_domain(d);=0A =0A       =
  if ( ret >=3D 0 )=0A         {=0A--- a/xen/common/grant_table.c=0A+++ =
b/xen/common/grant_table.c=0A@@ -24,7 +24,7 @@=0A  * Foundation, Inc., 59 =
Temple Place, Suite 330, Boston, MA  02111-1307  USA=0A  */=0A =0A-#include=
 <xen/config.h>=0A+#include <xen/err.h>=0A #include <xen/iocap.h>=0A =
#include <xen/lib.h>=0A #include <xen/sched.h>=0A@@ -195,6 +195,30 @@ =
double_gt_unlock(struct grant_table *lgt=0A         spin_unlock(&rgt->lock)=
;=0A }=0A =0A+static struct domain *gt_lock_target_domain_by_id(domid_t =
dom)=0A+{=0A+    struct domain *d;=0A+    int rc =3D GNTST_general_error;=
=0A+=0A+    switch ( rcu_lock_target_domain_by_id(dom, &d) )=0A+    {=0A+  =
  case 0:=0A+        return d;=0A+=0A+    case -ESRCH:=0A+        =
gdprintk(XENLOG_INFO, "Bad domid %d.\n", dom);=0A+        rc =3D GNTST_bad_=
domain;=0A+        break;=0A+=0A+    case -EPERM:=0A+        rc =3D =
GNTST_permission_denied;=0A+        break;=0A+    }=0A+=0A+    ASSERT(rc < =
0 && -rc <=3D MAX_ERRNO);=0A+    return ERR_PTR(rc);=0A+}=0A+=0A static =
inline int=0A __get_maptrack_handle(=0A     struct grant_table *t)=0A@@ =
-1261,7 +1285,6 @@ gnttab_setup_table(=0A     struct grant_table *gt;=0A   =
  int            i;=0A     unsigned long  gmfn;=0A-    domid_t        =
dom;=0A =0A     if ( count !=3D 1 )=0A         return -EINVAL;=0A@@ =
-1281,25 +1304,11 @@ gnttab_setup_table(=0A         goto out1;=0A     }=0A =
=0A-    dom =3D op.dom;=0A-    if ( dom =3D=3D DOMID_SELF )=0A+    d =3D =
gt_lock_target_domain_by_id(op.dom);=0A+    if ( IS_ERR(d) )=0A     {=0A-  =
      d =3D rcu_lock_current_domain();=0A-    }=0A-    else=0A-    {=0A-   =
     if ( unlikely((d =3D rcu_lock_domain_by_id(dom)) =3D=3D NULL) )=0A-   =
     {=0A-            gdprintk(XENLOG_INFO, "Bad domid %d.\n", dom);=0A-   =
         op.status =3D GNTST_bad_domain;=0A-            goto out1;=0A-     =
   }=0A-=0A-        if ( unlikely(!IS_PRIV_FOR(current->domain, d)) )=0A-  =
      {=0A-            op.status =3D GNTST_permission_denied;=0A-          =
  goto out2;=0A-        }=0A+        op.status =3D PTR_ERR(d);=0A+        =
goto out1;=0A     }=0A =0A     if ( xsm_grant_setup(current->domain, d) =
)=0A@@ -1352,7 +1361,6 @@ gnttab_query_size(=0A {=0A     struct gnttab_quer=
y_size op;=0A     struct domain *d;=0A-    domid_t        dom;=0A     int =
rc;=0A =0A     if ( count !=3D 1 )=0A@@ -1364,25 +1372,11 @@ gnttab_query_s=
ize(=0A         return -EFAULT;=0A     }=0A =0A-    dom =3D op.dom;=0A-    =
if ( dom =3D=3D DOMID_SELF )=0A-    {=0A-        d =3D rcu_lock_current_dom=
ain();=0A-    }=0A-    else=0A+    d =3D gt_lock_target_domain_by_id(op.dom=
);=0A+    if ( IS_ERR(d) )=0A     {=0A-        if ( unlikely((d =3D =
rcu_lock_domain_by_id(dom)) =3D=3D NULL) )=0A-        {=0A-            =
gdprintk(XENLOG_INFO, "Bad domid %d.\n", dom);=0A-            op.status =
=3D GNTST_bad_domain;=0A-            goto query_out;=0A-        }=0A-=0A-  =
      if ( unlikely(!IS_PRIV_FOR(current->domain, d)) )=0A-        {=0A-   =
         op.status =3D GNTST_permission_denied;=0A-            goto =
query_out_unlock;=0A-        }=0A+        op.status =3D PTR_ERR(d);=0A+    =
    goto query_out;=0A     }=0A =0A     rc =3D xsm_grant_query_size(current=
->domain, d);=0A@@ -2240,15 +2234,10 @@ gnttab_get_status_frames(XEN_GUEST_=
HANDL=0A         return -EFAULT;=0A     }=0A =0A-    rc =3D rcu_lock_target=
_domain_by_id(op.dom, &d);=0A-    if ( rc < 0 )=0A+    d =3D gt_lock_target=
_domain_by_id(op.dom);=0A+    if ( IS_ERR(d) )=0A     {=0A-        if ( rc =
=3D=3D -ESRCH )=0A-            op.status =3D GNTST_bad_domain;=0A-        =
else if ( rc =3D=3D -EPERM )=0A-            op.status =3D GNTST_permission_=
denied;=0A-        else=0A-            op.status =3D GNTST_general_error;=
=0A+        op.status =3D PTR_ERR(d);=0A         goto out1;=0A     }=0A    =
 rc =3D xsm_grant_setup(current->domain, d);=0A--- a/xen/common/memory.c=0A=
+++ b/xen/common/memory.c=0A@@ -329,22 +329,9 @@ static long memory_exchang=
e(XEN_GUEST_HA=0A         out_chunk_order =3D exch.in.extent_order - =
exch.out.extent_order;=0A     }=0A =0A-    if ( likely(exch.in.domid =
=3D=3D DOMID_SELF) )=0A-    {=0A-        d =3D rcu_lock_current_domain();=
=0A-    }=0A-    else=0A-    {=0A-        if ( (d =3D rcu_lock_domain_by_id=
(exch.in.domid)) =3D=3D NULL )=0A-            goto fail_early;=0A-=0A-     =
   if ( !IS_PRIV_FOR(current->domain, d) )=0A-        {=0A-            =
rcu_unlock_domain(d);=0A-            rc =3D -EPERM;=0A-            goto =
fail_early;=0A-        }=0A-    }=0A+    rc =3D rcu_lock_target_domain_by_i=
d(exch.in.domid, &d);=0A+    if ( rc )=0A+        goto fail_early;=0A =0A  =
   memflags |=3D MEMF_bits(domain_clamp_alloc_bitsize(=0A         d,=0A@@ =
-583,20 +570,8 @@ long do_memory_op(unsigned long cmd, XEN=0A              =
&& (reservation.mem_flags & XENMEMF_populate_on_demand) )=0A             =
args.memflags |=3D MEMF_populate_on_demand;=0A =0A-        if ( likely(rese=
rvation.domid =3D=3D DOMID_SELF) )=0A-        {=0A-            d =3D =
rcu_lock_current_domain();=0A-        }=0A-        else=0A-        {=0A-   =
         if ( (d =3D rcu_lock_domain_by_id(reservation.domid)) =3D=3D NULL =
)=0A-                return start_extent;=0A-            if ( !IS_PRIV_FOR(=
current->domain, d) )=0A-            {=0A-                rcu_unlock_domain=
(d);=0A-                return start_extent;=0A-            }=0A-        =
}=0A+        if ( unlikely(rcu_lock_target_domain_by_id(reservation.domid, =
&d)) )=0A+            return start_extent;=0A         args.domain =3D =
d;=0A =0A         rc =3D xsm_memory_adjust_reservation(current->domain, =
d);=0A
--=__Part7E4F6AE1.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

--=__Part7E4F6AE1.0__=--


From xen-devel-bounces@lists.xen.org Fri Sep 07 12:55:45 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Sep 2012 12:55:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9y5s-0004hb-GQ; Fri, 07 Sep 2012 12:55:32 +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 1T9y5r-0004hW-73
	for xen-devel@lists.xen.org; Fri, 07 Sep 2012 12:55:31 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1347022521!9485422!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM4ODU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25656 invoked from network); 7 Sep 2012 12:55:21 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-4.tower-27.messagelabs.com with SMTP;
	7 Sep 2012 12:55:21 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 07 Sep 2012 13:55:20 +0100
Message-Id: <504A0B110200007800099CCD@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 07 Sep 2012 13:56:17 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part7E4F6AE1.0__="
Subject: [Xen-devel] [PATCH] adjust a few RCU domain locking calls
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
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.

--=__Part7E4F6AE1.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

x86's do_physdev_op() had a case where the locking was entirely
superfluous. Its physdev_map_pirq() further had a case where the lock
was being obtained too early, needlessly complicating early exit paths.

Grant table code had two open coded instances of
rcu_lock_target_domain_by_id(), and a third code section could be
consolidated by using the newly introduced helper function.

The memory hypercall code had two more instances of open coding
rcu_lock_target_domain_by_id(), but note that here this is not just
cleanup, but also fixes an error return path in memory_exchange() to
actually return an error.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/arch/x86/physdev.c
+++ b/xen/arch/x86/physdev.c
@@ -90,14 +90,10 @@ static int physdev_hvm_map_pirq(
 int physdev_map_pirq(domid_t domid, int type, int *index, int *pirq_p,
                      struct msi_info *msi)
 {
-    struct domain *d;
+    struct domain *d =3D current->domain;
     int pirq, irq, ret =3D 0;
     void *map_data =3D NULL;
=20
-    ret =3D rcu_lock_target_domain_by_id(domid, &d);
-    if ( ret )
-        return ret;
-
     if ( domid =3D=3D DOMID_SELF && is_hvm_domain(d) )
     {
         /*
@@ -105,14 +101,15 @@ int physdev_map_pirq(domid_t domid, int=20
          * calls back into itself and deadlocks on hvm_domain.irq_lock.
          */
         if ( !is_hvm_pv_evtchn_domain(d) )
-        {
-            ret =3D -EINVAL;
-            goto free_domain;
-        }
-        ret =3D physdev_hvm_map_pirq(d, type, index, pirq_p);
-        goto free_domain;
+            return -EINVAL;
+
+        return physdev_hvm_map_pirq(d, type, index, pirq_p);
     }
=20
+    ret =3D rcu_lock_target_domain_by_id(domid, &d);
+    if ( ret )
+        return ret;
+
     if ( !IS_PRIV_FOR(current->domain, d) )
     {
         ret =3D -EPERM;
@@ -696,13 +693,12 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_H
     }
     case PHYSDEVOP_get_free_pirq: {
         struct physdev_get_free_pirq out;
-        struct domain *d;
+        struct domain *d =3D v->domain;
=20
         ret =3D -EFAULT;
         if ( copy_from_guest(&out, arg, 1) !=3D 0 )
             break;
=20
-        d =3D rcu_lock_current_domain();
         spin_lock(&d->event_lock);
=20
         ret =3D get_free_pirq(d, out.type);
@@ -717,7 +713,6 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_H
         }
=20
         spin_unlock(&d->event_lock);
-        rcu_unlock_domain(d);
=20
         if ( ret >=3D 0 )
         {
--- a/xen/common/grant_table.c
+++ b/xen/common/grant_table.c
@@ -24,7 +24,7 @@
  * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  =
USA
  */
=20
-#include <xen/config.h>
+#include <xen/err.h>
 #include <xen/iocap.h>
 #include <xen/lib.h>
 #include <xen/sched.h>
@@ -195,6 +195,30 @@ double_gt_unlock(struct grant_table *lgt
         spin_unlock(&rgt->lock);
 }
=20
+static struct domain *gt_lock_target_domain_by_id(domid_t dom)
+{
+    struct domain *d;
+    int rc =3D GNTST_general_error;
+
+    switch ( rcu_lock_target_domain_by_id(dom, &d) )
+    {
+    case 0:
+        return d;
+
+    case -ESRCH:
+        gdprintk(XENLOG_INFO, "Bad domid %d.\n", dom);
+        rc =3D GNTST_bad_domain;
+        break;
+
+    case -EPERM:
+        rc =3D GNTST_permission_denied;
+        break;
+    }
+
+    ASSERT(rc < 0 && -rc <=3D MAX_ERRNO);
+    return ERR_PTR(rc);
+}
+
 static inline int
 __get_maptrack_handle(
     struct grant_table *t)
@@ -1261,7 +1285,6 @@ gnttab_setup_table(
     struct grant_table *gt;
     int            i;
     unsigned long  gmfn;
-    domid_t        dom;
=20
     if ( count !=3D 1 )
         return -EINVAL;
@@ -1281,25 +1304,11 @@ gnttab_setup_table(
         goto out1;
     }
=20
-    dom =3D op.dom;
-    if ( dom =3D=3D DOMID_SELF )
+    d =3D gt_lock_target_domain_by_id(op.dom);
+    if ( IS_ERR(d) )
     {
-        d =3D rcu_lock_current_domain();
-    }
-    else
-    {
-        if ( unlikely((d =3D rcu_lock_domain_by_id(dom)) =3D=3D NULL) )
-        {
-            gdprintk(XENLOG_INFO, "Bad domid %d.\n", dom);
-            op.status =3D GNTST_bad_domain;
-            goto out1;
-        }
-
-        if ( unlikely(!IS_PRIV_FOR(current->domain, d)) )
-        {
-            op.status =3D GNTST_permission_denied;
-            goto out2;
-        }
+        op.status =3D PTR_ERR(d);
+        goto out1;
     }
=20
     if ( xsm_grant_setup(current->domain, d) )
@@ -1352,7 +1361,6 @@ gnttab_query_size(
 {
     struct gnttab_query_size op;
     struct domain *d;
-    domid_t        dom;
     int rc;
=20
     if ( count !=3D 1 )
@@ -1364,25 +1372,11 @@ gnttab_query_size(
         return -EFAULT;
     }
=20
-    dom =3D op.dom;
-    if ( dom =3D=3D DOMID_SELF )
-    {
-        d =3D rcu_lock_current_domain();
-    }
-    else
+    d =3D gt_lock_target_domain_by_id(op.dom);
+    if ( IS_ERR(d) )
     {
-        if ( unlikely((d =3D rcu_lock_domain_by_id(dom)) =3D=3D NULL) )
-        {
-            gdprintk(XENLOG_INFO, "Bad domid %d.\n", dom);
-            op.status =3D GNTST_bad_domain;
-            goto query_out;
-        }
-
-        if ( unlikely(!IS_PRIV_FOR(current->domain, d)) )
-        {
-            op.status =3D GNTST_permission_denied;
-            goto query_out_unlock;
-        }
+        op.status =3D PTR_ERR(d);
+        goto query_out;
     }
=20
     rc =3D xsm_grant_query_size(current->domain, d);
@@ -2240,15 +2234,10 @@ gnttab_get_status_frames(XEN_GUEST_HANDL
         return -EFAULT;
     }
=20
-    rc =3D rcu_lock_target_domain_by_id(op.dom, &d);
-    if ( rc < 0 )
+    d =3D gt_lock_target_domain_by_id(op.dom);
+    if ( IS_ERR(d) )
     {
-        if ( rc =3D=3D -ESRCH )
-            op.status =3D GNTST_bad_domain;
-        else if ( rc =3D=3D -EPERM )
-            op.status =3D GNTST_permission_denied;
-        else
-            op.status =3D GNTST_general_error;
+        op.status =3D PTR_ERR(d);
         goto out1;
     }
     rc =3D xsm_grant_setup(current->domain, d);
--- a/xen/common/memory.c
+++ b/xen/common/memory.c
@@ -329,22 +329,9 @@ static long memory_exchange(XEN_GUEST_HA
         out_chunk_order =3D exch.in.extent_order - exch.out.extent_order;
     }
=20
-    if ( likely(exch.in.domid =3D=3D DOMID_SELF) )
-    {
-        d =3D rcu_lock_current_domain();
-    }
-    else
-    {
-        if ( (d =3D rcu_lock_domain_by_id(exch.in.domid)) =3D=3D NULL )
-            goto fail_early;
-
-        if ( !IS_PRIV_FOR(current->domain, d) )
-        {
-            rcu_unlock_domain(d);
-            rc =3D -EPERM;
-            goto fail_early;
-        }
-    }
+    rc =3D rcu_lock_target_domain_by_id(exch.in.domid, &d);
+    if ( rc )
+        goto fail_early;
=20
     memflags |=3D MEMF_bits(domain_clamp_alloc_bitsize(
         d,
@@ -583,20 +570,8 @@ long do_memory_op(unsigned long cmd, XEN
              && (reservation.mem_flags & XENMEMF_populate_on_demand) )
             args.memflags |=3D MEMF_populate_on_demand;
=20
-        if ( likely(reservation.domid =3D=3D DOMID_SELF) )
-        {
-            d =3D rcu_lock_current_domain();
-        }
-        else
-        {
-            if ( (d =3D rcu_lock_domain_by_id(reservation.domid)) =3D=3D =
NULL )
-                return start_extent;
-            if ( !IS_PRIV_FOR(current->domain, d) )
-            {
-                rcu_unlock_domain(d);
-                return start_extent;
-            }
-        }
+        if ( unlikely(rcu_lock_target_domain_by_id(reservation.domid, =
&d)) )
+            return start_extent;
         args.domain =3D d;
=20
         rc =3D xsm_memory_adjust_reservation(current->domain, d);



--=__Part7E4F6AE1.0__=
Content-Type: text/plain; name="adjust-rcu-lock-domain.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="adjust-rcu-lock-domain.patch"

adjust a few RCU domain locking calls=0A=0Ax86's do_physdev_op() had a =
case where the locking was entirely=0Asuperfluous. Its physdev_map_pirq() =
further had a case where the lock=0Awas being obtained too early, =
needlessly complicating early exit paths.=0A=0AGrant table code had two =
open coded instances of=0Arcu_lock_target_domain_by_id(), and a third code =
section could be=0Aconsolidated by using the newly introduced helper =
function.=0A=0AThe memory hypercall code had two more instances of open =
coding=0Arcu_lock_target_domain_by_id(), but note that here this is not =
just=0Acleanup, but also fixes an error return path in memory_exchange() =
to=0Aactually return an error.=0A=0ASigned-off-by: Jan Beulich <jbeulich@su=
se.com>=0A=0A--- a/xen/arch/x86/physdev.c=0A+++ b/xen/arch/x86/physdev.c=0A=
@@ -90,14 +90,10 @@ static int physdev_hvm_map_pirq(=0A int physdev_map_pir=
q(domid_t domid, int type, int *index, int *pirq_p,=0A                     =
 struct msi_info *msi)=0A {=0A-    struct domain *d;=0A+    struct domain =
*d =3D current->domain;=0A     int pirq, irq, ret =3D 0;=0A     void =
*map_data =3D NULL;=0A =0A-    ret =3D rcu_lock_target_domain_by_id(domid, =
&d);=0A-    if ( ret )=0A-        return ret;=0A-=0A     if ( domid =3D=3D =
DOMID_SELF && is_hvm_domain(d) )=0A     {=0A         /*=0A@@ -105,14 =
+101,15 @@ int physdev_map_pirq(domid_t domid, int =0A          * calls =
back into itself and deadlocks on hvm_domain.irq_lock.=0A          */=0A   =
      if ( !is_hvm_pv_evtchn_domain(d) )=0A-        {=0A-            ret =
=3D -EINVAL;=0A-            goto free_domain;=0A-        }=0A-        ret =
=3D physdev_hvm_map_pirq(d, type, index, pirq_p);=0A-        goto =
free_domain;=0A+            return -EINVAL;=0A+=0A+        return =
physdev_hvm_map_pirq(d, type, index, pirq_p);=0A     }=0A =0A+    ret =3D =
rcu_lock_target_domain_by_id(domid, &d);=0A+    if ( ret )=0A+        =
return ret;=0A+=0A     if ( !IS_PRIV_FOR(current->domain, d) )=0A     {=0A =
        ret =3D -EPERM;=0A@@ -696,13 +693,12 @@ ret_t do_physdev_op(int =
cmd, XEN_GUEST_H=0A     }=0A     case PHYSDEVOP_get_free_pirq: {=0A        =
 struct physdev_get_free_pirq out;=0A-        struct domain *d;=0A+        =
struct domain *d =3D v->domain;=0A =0A         ret =3D -EFAULT;=0A         =
if ( copy_from_guest(&out, arg, 1) !=3D 0 )=0A             break;=0A =0A-  =
      d =3D rcu_lock_current_domain();=0A         spin_lock(&d->event_lock)=
;=0A =0A         ret =3D get_free_pirq(d, out.type);=0A@@ -717,7 +713,6 @@ =
ret_t do_physdev_op(int cmd, XEN_GUEST_H=0A         }=0A =0A         =
spin_unlock(&d->event_lock);=0A-        rcu_unlock_domain(d);=0A =0A       =
  if ( ret >=3D 0 )=0A         {=0A--- a/xen/common/grant_table.c=0A+++ =
b/xen/common/grant_table.c=0A@@ -24,7 +24,7 @@=0A  * Foundation, Inc., 59 =
Temple Place, Suite 330, Boston, MA  02111-1307  USA=0A  */=0A =0A-#include=
 <xen/config.h>=0A+#include <xen/err.h>=0A #include <xen/iocap.h>=0A =
#include <xen/lib.h>=0A #include <xen/sched.h>=0A@@ -195,6 +195,30 @@ =
double_gt_unlock(struct grant_table *lgt=0A         spin_unlock(&rgt->lock)=
;=0A }=0A =0A+static struct domain *gt_lock_target_domain_by_id(domid_t =
dom)=0A+{=0A+    struct domain *d;=0A+    int rc =3D GNTST_general_error;=
=0A+=0A+    switch ( rcu_lock_target_domain_by_id(dom, &d) )=0A+    {=0A+  =
  case 0:=0A+        return d;=0A+=0A+    case -ESRCH:=0A+        =
gdprintk(XENLOG_INFO, "Bad domid %d.\n", dom);=0A+        rc =3D GNTST_bad_=
domain;=0A+        break;=0A+=0A+    case -EPERM:=0A+        rc =3D =
GNTST_permission_denied;=0A+        break;=0A+    }=0A+=0A+    ASSERT(rc < =
0 && -rc <=3D MAX_ERRNO);=0A+    return ERR_PTR(rc);=0A+}=0A+=0A static =
inline int=0A __get_maptrack_handle(=0A     struct grant_table *t)=0A@@ =
-1261,7 +1285,6 @@ gnttab_setup_table(=0A     struct grant_table *gt;=0A   =
  int            i;=0A     unsigned long  gmfn;=0A-    domid_t        =
dom;=0A =0A     if ( count !=3D 1 )=0A         return -EINVAL;=0A@@ =
-1281,25 +1304,11 @@ gnttab_setup_table(=0A         goto out1;=0A     }=0A =
=0A-    dom =3D op.dom;=0A-    if ( dom =3D=3D DOMID_SELF )=0A+    d =3D =
gt_lock_target_domain_by_id(op.dom);=0A+    if ( IS_ERR(d) )=0A     {=0A-  =
      d =3D rcu_lock_current_domain();=0A-    }=0A-    else=0A-    {=0A-   =
     if ( unlikely((d =3D rcu_lock_domain_by_id(dom)) =3D=3D NULL) )=0A-   =
     {=0A-            gdprintk(XENLOG_INFO, "Bad domid %d.\n", dom);=0A-   =
         op.status =3D GNTST_bad_domain;=0A-            goto out1;=0A-     =
   }=0A-=0A-        if ( unlikely(!IS_PRIV_FOR(current->domain, d)) )=0A-  =
      {=0A-            op.status =3D GNTST_permission_denied;=0A-          =
  goto out2;=0A-        }=0A+        op.status =3D PTR_ERR(d);=0A+        =
goto out1;=0A     }=0A =0A     if ( xsm_grant_setup(current->domain, d) =
)=0A@@ -1352,7 +1361,6 @@ gnttab_query_size(=0A {=0A     struct gnttab_quer=
y_size op;=0A     struct domain *d;=0A-    domid_t        dom;=0A     int =
rc;=0A =0A     if ( count !=3D 1 )=0A@@ -1364,25 +1372,11 @@ gnttab_query_s=
ize(=0A         return -EFAULT;=0A     }=0A =0A-    dom =3D op.dom;=0A-    =
if ( dom =3D=3D DOMID_SELF )=0A-    {=0A-        d =3D rcu_lock_current_dom=
ain();=0A-    }=0A-    else=0A+    d =3D gt_lock_target_domain_by_id(op.dom=
);=0A+    if ( IS_ERR(d) )=0A     {=0A-        if ( unlikely((d =3D =
rcu_lock_domain_by_id(dom)) =3D=3D NULL) )=0A-        {=0A-            =
gdprintk(XENLOG_INFO, "Bad domid %d.\n", dom);=0A-            op.status =
=3D GNTST_bad_domain;=0A-            goto query_out;=0A-        }=0A-=0A-  =
      if ( unlikely(!IS_PRIV_FOR(current->domain, d)) )=0A-        {=0A-   =
         op.status =3D GNTST_permission_denied;=0A-            goto =
query_out_unlock;=0A-        }=0A+        op.status =3D PTR_ERR(d);=0A+    =
    goto query_out;=0A     }=0A =0A     rc =3D xsm_grant_query_size(current=
->domain, d);=0A@@ -2240,15 +2234,10 @@ gnttab_get_status_frames(XEN_GUEST_=
HANDL=0A         return -EFAULT;=0A     }=0A =0A-    rc =3D rcu_lock_target=
_domain_by_id(op.dom, &d);=0A-    if ( rc < 0 )=0A+    d =3D gt_lock_target=
_domain_by_id(op.dom);=0A+    if ( IS_ERR(d) )=0A     {=0A-        if ( rc =
=3D=3D -ESRCH )=0A-            op.status =3D GNTST_bad_domain;=0A-        =
else if ( rc =3D=3D -EPERM )=0A-            op.status =3D GNTST_permission_=
denied;=0A-        else=0A-            op.status =3D GNTST_general_error;=
=0A+        op.status =3D PTR_ERR(d);=0A         goto out1;=0A     }=0A    =
 rc =3D xsm_grant_setup(current->domain, d);=0A--- a/xen/common/memory.c=0A=
+++ b/xen/common/memory.c=0A@@ -329,22 +329,9 @@ static long memory_exchang=
e(XEN_GUEST_HA=0A         out_chunk_order =3D exch.in.extent_order - =
exch.out.extent_order;=0A     }=0A =0A-    if ( likely(exch.in.domid =
=3D=3D DOMID_SELF) )=0A-    {=0A-        d =3D rcu_lock_current_domain();=
=0A-    }=0A-    else=0A-    {=0A-        if ( (d =3D rcu_lock_domain_by_id=
(exch.in.domid)) =3D=3D NULL )=0A-            goto fail_early;=0A-=0A-     =
   if ( !IS_PRIV_FOR(current->domain, d) )=0A-        {=0A-            =
rcu_unlock_domain(d);=0A-            rc =3D -EPERM;=0A-            goto =
fail_early;=0A-        }=0A-    }=0A+    rc =3D rcu_lock_target_domain_by_i=
d(exch.in.domid, &d);=0A+    if ( rc )=0A+        goto fail_early;=0A =0A  =
   memflags |=3D MEMF_bits(domain_clamp_alloc_bitsize(=0A         d,=0A@@ =
-583,20 +570,8 @@ long do_memory_op(unsigned long cmd, XEN=0A              =
&& (reservation.mem_flags & XENMEMF_populate_on_demand) )=0A             =
args.memflags |=3D MEMF_populate_on_demand;=0A =0A-        if ( likely(rese=
rvation.domid =3D=3D DOMID_SELF) )=0A-        {=0A-            d =3D =
rcu_lock_current_domain();=0A-        }=0A-        else=0A-        {=0A-   =
         if ( (d =3D rcu_lock_domain_by_id(reservation.domid)) =3D=3D NULL =
)=0A-                return start_extent;=0A-            if ( !IS_PRIV_FOR(=
current->domain, d) )=0A-            {=0A-                rcu_unlock_domain=
(d);=0A-                return start_extent;=0A-            }=0A-        =
}=0A+        if ( unlikely(rcu_lock_target_domain_by_id(reservation.domid, =
&d)) )=0A+            return start_extent;=0A         args.domain =3D =
d;=0A =0A         rc =3D xsm_memory_adjust_reservation(current->domain, =
d);=0A
--=__Part7E4F6AE1.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

--=__Part7E4F6AE1.0__=--


From xen-devel-bounces@lists.xen.org Fri Sep 07 12:58:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Sep 2012 12: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 1T9y8V-0004pk-6d; Fri, 07 Sep 2012 12:58:15 +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 1T9y8T-0004pa-AU
	for xen-devel@lists.xen.org; Fri, 07 Sep 2012 12:58:13 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1347022685!9485836!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM4ODU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9383 invoked from network); 7 Sep 2012 12:58:05 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-4.tower-27.messagelabs.com with SMTP;
	7 Sep 2012 12:58:05 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 07 Sep 2012 13:58:05 +0100
Message-Id: <504A0BB50200007800099CD2@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 07 Sep 2012 13:59:01 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part1B2A0F85.1__="
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH] x86/hvm: don't give vector callback higher
 priority than NMI/MCE
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<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.

--=__Part1B2A0F85.1__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Those two should always be delivered first imo.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/arch/x86/hvm/irq.c
+++ b/xen/arch/x86/hvm/irq.c
@@ -395,16 +395,16 @@ struct hvm_intack hvm_vcpu_has_pending_i
     struct hvm_domain *plat =3D &v->domain->arch.hvm_domain;
     int vector;
=20
-    if ( (plat->irq.callback_via_type =3D=3D HVMIRQ_callback_vector)
-         && vcpu_info(v, evtchn_upcall_pending) )
-        return hvm_intack_vector(plat->irq.callback_via.vector);
-
     if ( unlikely(v->nmi_pending) )
         return hvm_intack_nmi;
=20
     if ( unlikely(v->mce_pending) )
         return hvm_intack_mce;
=20
+    if ( (plat->irq.callback_via_type =3D=3D HVMIRQ_callback_vector)
+         && vcpu_info(v, evtchn_upcall_pending) )
+        return hvm_intack_vector(plat->irq.callback_via.vector);
+
     if ( vlapic_accept_pic_intr(v) && plat->vpic[0].int_output )
         return hvm_intack_pic(0);
=20




--=__Part1B2A0F85.1__=
Content-Type: text/plain; name="x86-hvm-vector-delivery.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="x86-hvm-vector-delivery.patch"

x86/hvm: don't give vector callback higher priority than NMI/MCE=0A=0AThose=
 two should always be delivered first imo.=0A=0ASigned-off-by: Jan Beulich =
<jbeulich@suse.com>=0A=0A--- a/xen/arch/x86/hvm/irq.c=0A+++ b/xen/arch/x86/=
hvm/irq.c=0A@@ -395,16 +395,16 @@ struct hvm_intack hvm_vcpu_has_pending_i=
=0A     struct hvm_domain *plat =3D &v->domain->arch.hvm_domain;=0A     =
int vector;=0A =0A-    if ( (plat->irq.callback_via_type =3D=3D HVMIRQ_call=
back_vector)=0A-         && vcpu_info(v, evtchn_upcall_pending) )=0A-      =
  return hvm_intack_vector(plat->irq.callback_via.vector);=0A-=0A     if ( =
unlikely(v->nmi_pending) )=0A         return hvm_intack_nmi;=0A =0A     if =
( unlikely(v->mce_pending) )=0A         return hvm_intack_mce;=0A =0A+    =
if ( (plat->irq.callback_via_type =3D=3D HVMIRQ_callback_vector)=0A+       =
  && vcpu_info(v, evtchn_upcall_pending) )=0A+        return hvm_intack_vec=
tor(plat->irq.callback_via.vector);=0A+=0A     if ( vlapic_accept_pic_intr(=
v) && plat->vpic[0].int_output )=0A         return hvm_intack_pic(0);=0A =
=0A
--=__Part1B2A0F85.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

--=__Part1B2A0F85.1__=--


From xen-devel-bounces@lists.xen.org Fri Sep 07 12:58:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Sep 2012 12: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 1T9y8V-0004pk-6d; Fri, 07 Sep 2012 12:58:15 +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 1T9y8T-0004pa-AU
	for xen-devel@lists.xen.org; Fri, 07 Sep 2012 12:58:13 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1347022685!9485836!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM4ODU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9383 invoked from network); 7 Sep 2012 12:58:05 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-4.tower-27.messagelabs.com with SMTP;
	7 Sep 2012 12:58:05 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 07 Sep 2012 13:58:05 +0100
Message-Id: <504A0BB50200007800099CD2@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 07 Sep 2012 13:59:01 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part1B2A0F85.1__="
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH] x86/hvm: don't give vector callback higher
 priority than NMI/MCE
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<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.

--=__Part1B2A0F85.1__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Those two should always be delivered first imo.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/arch/x86/hvm/irq.c
+++ b/xen/arch/x86/hvm/irq.c
@@ -395,16 +395,16 @@ struct hvm_intack hvm_vcpu_has_pending_i
     struct hvm_domain *plat =3D &v->domain->arch.hvm_domain;
     int vector;
=20
-    if ( (plat->irq.callback_via_type =3D=3D HVMIRQ_callback_vector)
-         && vcpu_info(v, evtchn_upcall_pending) )
-        return hvm_intack_vector(plat->irq.callback_via.vector);
-
     if ( unlikely(v->nmi_pending) )
         return hvm_intack_nmi;
=20
     if ( unlikely(v->mce_pending) )
         return hvm_intack_mce;
=20
+    if ( (plat->irq.callback_via_type =3D=3D HVMIRQ_callback_vector)
+         && vcpu_info(v, evtchn_upcall_pending) )
+        return hvm_intack_vector(plat->irq.callback_via.vector);
+
     if ( vlapic_accept_pic_intr(v) && plat->vpic[0].int_output )
         return hvm_intack_pic(0);
=20




--=__Part1B2A0F85.1__=
Content-Type: text/plain; name="x86-hvm-vector-delivery.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="x86-hvm-vector-delivery.patch"

x86/hvm: don't give vector callback higher priority than NMI/MCE=0A=0AThose=
 two should always be delivered first imo.=0A=0ASigned-off-by: Jan Beulich =
<jbeulich@suse.com>=0A=0A--- a/xen/arch/x86/hvm/irq.c=0A+++ b/xen/arch/x86/=
hvm/irq.c=0A@@ -395,16 +395,16 @@ struct hvm_intack hvm_vcpu_has_pending_i=
=0A     struct hvm_domain *plat =3D &v->domain->arch.hvm_domain;=0A     =
int vector;=0A =0A-    if ( (plat->irq.callback_via_type =3D=3D HVMIRQ_call=
back_vector)=0A-         && vcpu_info(v, evtchn_upcall_pending) )=0A-      =
  return hvm_intack_vector(plat->irq.callback_via.vector);=0A-=0A     if ( =
unlikely(v->nmi_pending) )=0A         return hvm_intack_nmi;=0A =0A     if =
( unlikely(v->mce_pending) )=0A         return hvm_intack_mce;=0A =0A+    =
if ( (plat->irq.callback_via_type =3D=3D HVMIRQ_callback_vector)=0A+       =
  && vcpu_info(v, evtchn_upcall_pending) )=0A+        return hvm_intack_vec=
tor(plat->irq.callback_via.vector);=0A+=0A     if ( vlapic_accept_pic_intr(=
v) && plat->vpic[0].int_output )=0A         return hvm_intack_pic(0);=0A =
=0A
--=__Part1B2A0F85.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

--=__Part1B2A0F85.1__=--


From xen-devel-bounces@lists.xen.org Fri Sep 07 13:01:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Sep 2012 13: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 1T9yBC-000510-PS; Fri, 07 Sep 2012 13:01:02 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1T9yBB-00050p-4v
	for xen-devel@lists.xen.org; Fri, 07 Sep 2012 13:01:01 +0000
Received: from [85.158.143.99:35889] by server-2.bemta-4.messagelabs.com id
	B3/05-21239-C00F9405; Fri, 07 Sep 2012 13:01:00 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1347022827!29113976!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM4ODU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28384 invoked from network); 7 Sep 2012 13:00:34 -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;
	7 Sep 2012 13:00:34 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 07 Sep 2012 14:00:27 +0100
Message-Id: <504A0C420200007800099CD6@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 07 Sep 2012 14:01:22 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__PartB382A732.0__="
Subject: [Xen-devel] [PATCH, v3] x86/HVM: assorted RTC emulation adjustments
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=__PartB382A732.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

- don't look at RTC_PIE in rtc_timer_update(), and hence don't call the
  function on REG_B writes at all
- only call alarm_timer_update() on REG_B writes when relevant bits
  change
- only call check_update_timer() on REG_B writes when SET changes
- instead properly handle AF and PF when the guest is not also setting
  AIE/PIE respectively (for UF this was already the case, only a
  comment was slightly inaccurate)
- raise the RTC IRQ not only when UIE gets set while UF was already
  set, but generalize this to cover AIE and PIE as well
- properly mask off bit 7 when retrieving the hour values in
  alarm_timer_update(), and properly use RTC_HOURS_ALARM's bit 7 when
  converting from 12- to 24-hour value
- also handle the two other possible clock bases
- use RTC_* names in a couple of places where literal numbers were used
  so far

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/arch/x86/hvm/rtc.c
+++ b/xen/arch/x86/hvm/rtc.c
@@ -50,11 +50,24 @@ static void rtc_set_time(RTCState *s);
 static inline int from_bcd(RTCState *s, int a);
 static inline int convert_hour(RTCState *s, int hour);
=20
-static void rtc_periodic_cb(struct vcpu *v, void *opaque)
+static void rtc_toggle_irq(RTCState *s)
+{
+    struct domain *d =3D vrtc_domain(s);
+
+    ASSERT(spin_is_locked(&s->lock));
+    s->hw.cmos_data[RTC_REG_C] |=3D RTC_IRQF;
+    hvm_isa_irq_deassert(d, RTC_IRQ);
+    hvm_isa_irq_assert(d, RTC_IRQ);
+}
+
+void rtc_periodic_interrupt(void *opaque)
 {
     RTCState *s =3D opaque;
+
     spin_lock(&s->lock);
-    s->hw.cmos_data[RTC_REG_C] |=3D 0xc0;
+    s->hw.cmos_data[RTC_REG_C] |=3D RTC_PF;
+    if ( s->hw.cmos_data[RTC_REG_B] & RTC_PIE )
+        rtc_toggle_irq(s);
     spin_unlock(&s->lock);
 }
=20
@@ -68,19 +81,25 @@ static void rtc_timer_update(RTCState *s
     ASSERT(spin_is_locked(&s->lock));
=20
     period_code =3D s->hw.cmos_data[RTC_REG_A] & RTC_RATE_SELECT;
-    if ( (period_code !=3D 0) && (s->hw.cmos_data[RTC_REG_B] & RTC_PIE) )
+    switch ( s->hw.cmos_data[RTC_REG_A] & RTC_DIV_CTL )
     {
-        if ( period_code <=3D 2 )
+    case RTC_REF_CLCK_32KHZ:
+        if ( (period_code !=3D 0) && (period_code <=3D 2) )
             period_code +=3D 7;
-
-        period =3D 1 << (period_code - 1); /* period in 32 Khz cycles */
-        period =3D DIV_ROUND((period * 1000000000ULL), 32768); /* period =
in ns */
-        create_periodic_time(v, &s->pt, period, period, RTC_IRQ,
-                             rtc_periodic_cb, s);
-    }
-    else
-    {
+        /* fall through */
+    case RTC_REF_CLCK_1MHZ:
+    case RTC_REF_CLCK_4MHZ:
+        if ( period_code !=3D 0 )
+        {
+            period =3D 1 << (period_code - 1); /* period in 32 Khz cycles =
*/
+            period =3D DIV_ROUND(period * 1000000000ULL, 32768); /* in ns =
*/
+            create_periodic_time(v, &s->pt, period, period, RTC_IRQ, =
NULL, s);
+            break;
+        }
+        /* fall through */
+    default:
         destroy_periodic_time(&s->pt);
+        break;
     }
 }
=20
@@ -102,7 +121,7 @@ static void check_update_timer(RTCState=20
         guest_usec =3D get_localtime_us(d) % USEC_PER_SEC;
         if (guest_usec >=3D (USEC_PER_SEC - 244))
         {
-            /* RTC is in update cycle when enabling UIE */
+            /* RTC is in update cycle */
             s->hw.cmos_data[RTC_REG_A] |=3D RTC_UIP;
             next_update_time =3D (USEC_PER_SEC - guest_usec) * NS_PER_USEC=
;
             expire_time =3D NOW() + next_update_time;
@@ -144,7 +163,6 @@ static void rtc_update_timer(void *opaqu
 static void rtc_update_timer2(void *opaque)
 {
     RTCState *s =3D opaque;
-    struct domain *d =3D vrtc_domain(s);
=20
     spin_lock(&s->lock);
     if (!(s->hw.cmos_data[RTC_REG_B] & RTC_SET))
@@ -152,11 +170,7 @@ static void rtc_update_timer2(void *opaq
         s->hw.cmos_data[RTC_REG_C] |=3D RTC_UF;
         s->hw.cmos_data[RTC_REG_A] &=3D ~RTC_UIP;
         if ((s->hw.cmos_data[RTC_REG_B] & RTC_UIE))
-        {
-            s->hw.cmos_data[RTC_REG_C] |=3D RTC_IRQF;
-            hvm_isa_irq_deassert(d, RTC_IRQ);
-            hvm_isa_irq_assert(d, RTC_IRQ);
-        }
+            rtc_toggle_irq(s);
         check_update_timer(s);
     }
     spin_unlock(&s->lock);
@@ -175,21 +189,18 @@ static void alarm_timer_update(RTCState=20
=20
     stop_timer(&s->alarm_timer);
=20
-    if ((s->hw.cmos_data[RTC_REG_B] & RTC_AIE) &&
-            !(s->hw.cmos_data[RTC_REG_B] & RTC_SET))
+    if ( !(s->hw.cmos_data[RTC_REG_B] & RTC_SET) )
     {
         s->current_tm =3D gmtime(get_localtime(d));
         rtc_copy_date(s);
=20
         alarm_sec =3D from_bcd(s, s->hw.cmos_data[RTC_SECONDS_ALARM]);
         alarm_min =3D from_bcd(s, s->hw.cmos_data[RTC_MINUTES_ALARM]);
-        alarm_hour =3D from_bcd(s, s->hw.cmos_data[RTC_HOURS_ALARM]);
-        alarm_hour =3D convert_hour(s, alarm_hour);
+        alarm_hour =3D convert_hour(s, s->hw.cmos_data[RTC_HOURS_ALARM]);
=20
         cur_sec =3D from_bcd(s, s->hw.cmos_data[RTC_SECONDS]);
         cur_min =3D from_bcd(s, s->hw.cmos_data[RTC_MINUTES]);
-        cur_hour =3D from_bcd(s, s->hw.cmos_data[RTC_HOURS]);
-        cur_hour =3D convert_hour(s, cur_hour);
+        cur_hour =3D convert_hour(s, s->hw.cmos_data[RTC_HOURS]);
=20
         next_update_time =3D USEC_PER_SEC - (get_localtime_us(d) % =
USEC_PER_SEC);
         next_update_time =3D next_update_time * NS_PER_USEC + NOW();
@@ -343,7 +354,6 @@ static void alarm_timer_update(RTCState=20
 static void rtc_alarm_cb(void *opaque)
 {
     RTCState *s =3D opaque;
-    struct domain *d =3D vrtc_domain(s);
=20
     spin_lock(&s->lock);
     if (!(s->hw.cmos_data[RTC_REG_B] & RTC_SET))
@@ -351,11 +361,7 @@ static void rtc_alarm_cb(void *opaque)
         s->hw.cmos_data[RTC_REG_C] |=3D RTC_AF;
         /* alarm interrupt */
         if (s->hw.cmos_data[RTC_REG_B] & RTC_AIE)
-        {
-            s->hw.cmos_data[RTC_REG_C] |=3D RTC_IRQF;
-            hvm_isa_irq_deassert(d, RTC_IRQ);
-            hvm_isa_irq_assert(d, RTC_IRQ);
-        }
+            rtc_toggle_irq(s);
         alarm_timer_update(s);
     }
     spin_unlock(&s->lock);
@@ -365,7 +371,7 @@ static int rtc_ioport_write(void *opaque
 {
     RTCState *s =3D opaque;
     struct domain *d =3D vrtc_domain(s);
-    uint32_t orig;
+    uint32_t orig, mask;
=20
     spin_lock(&s->lock);
=20
@@ -417,7 +423,7 @@ static int rtc_ioport_write(void *opaque
             /* set mode: reset UIP mode */
             s->hw.cmos_data[RTC_REG_A] &=3D ~RTC_UIP;
             /* adjust cmos before stopping */
-            if (!(s->hw.cmos_data[RTC_REG_B] & RTC_SET))
+            if (!(orig & RTC_SET))
             {
                 s->current_tm =3D gmtime(get_localtime(d));
                 rtc_copy_date(s);
@@ -426,22 +432,26 @@ static int rtc_ioport_write(void *opaque
         else
         {
             /* if disabling set mode, update the time */
-            if ( s->hw.cmos_data[RTC_REG_B] & RTC_SET )
+            if ( orig & RTC_SET )
                 rtc_set_time(s);
         }
-        /* if the interrupt is already set when the interrupt become
-         * enabled, raise an interrupt immediately*/
-        if ((data & RTC_UIE) && !(s->hw.cmos_data[RTC_REG_B] & RTC_UIE))
-            if (s->hw.cmos_data[RTC_REG_C] & RTC_UF)
+        /*
+         * If the interrupt is already set when the interrupt becomes
+         * enabled, raise an interrupt immediately.
+         * NB: RTC_{A,P,U}IE =3D=3D RTC_{A,P,U}F respectively.
+         */
+        for ( mask =3D RTC_UIE; mask <=3D RTC_PIE; mask <<=3D 1 )
+            if ( (data & mask) && !(orig & mask) &&
+                 (s->hw.cmos_data[RTC_REG_C] & mask) )
             {
-                hvm_isa_irq_deassert(d, RTC_IRQ);
-                hvm_isa_irq_assert(d, RTC_IRQ);
+                rtc_toggle_irq(s);
+                break;
             }
         s->hw.cmos_data[RTC_REG_B] =3D data;
-        if ( (data ^ orig) & RTC_PIE )
-            rtc_timer_update(s);
-        check_update_timer(s);
-        alarm_timer_update(s);
+        if ( (data ^ orig) & RTC_SET )
+            check_update_timer(s);
+        if ( (data ^ orig) & (RTC_24H | RTC_DM_BINARY | RTC_SET) )
+            alarm_timer_update(s);
         break;
     case RTC_REG_C:
     case RTC_REG_D:
@@ -456,7 +466,7 @@ static int rtc_ioport_write(void *opaque
=20
 static inline int to_bcd(RTCState *s, int a)
 {
-    if ( s->hw.cmos_data[RTC_REG_B] & 0x04 )
+    if ( s->hw.cmos_data[RTC_REG_B] & RTC_DM_BINARY )
         return a;
     else
         return ((a / 10) << 4) | (a % 10);
@@ -464,7 +474,7 @@ static inline int to_bcd(RTCState *s, in
=20
 static inline int from_bcd(RTCState *s, int a)
 {
-    if ( s->hw.cmos_data[RTC_REG_B] & 0x04 )
+    if ( s->hw.cmos_data[RTC_REG_B] & RTC_DM_BINARY )
         return a;
     else
         return ((a >> 4) * 10) + (a & 0x0f);
@@ -472,12 +482,14 @@ static inline int from_bcd(RTCState *s,=20
=20
 /* Hours in 12 hour mode are in 1-12 range, not 0-11.
  * So we need convert it before using it*/
-static inline int convert_hour(RTCState *s, int hour)
+static inline int convert_hour(RTCState *s, int raw)
 {
+    int hour =3D from_bcd(s, raw & 0x7f);
+
     if (!(s->hw.cmos_data[RTC_REG_B] & RTC_24H))
     {
         hour %=3D 12;
-        if (s->hw.cmos_data[RTC_HOURS] & 0x80)
+        if (raw & 0x80)
             hour +=3D 12;
     }
     return hour;
@@ -496,8 +508,7 @@ static void rtc_set_time(RTCState *s)
    =20
     tm->tm_sec =3D from_bcd(s, s->hw.cmos_data[RTC_SECONDS]);
     tm->tm_min =3D from_bcd(s, s->hw.cmos_data[RTC_MINUTES]);
-    tm->tm_hour =3D from_bcd(s, s->hw.cmos_data[RTC_HOURS] & 0x7f);
-    tm->tm_hour =3D convert_hour(s, tm->tm_hour);
+    tm->tm_hour =3D convert_hour(s, s->hw.cmos_data[RTC_HOURS]);
     tm->tm_wday =3D from_bcd(s, s->hw.cmos_data[RTC_DAY_OF_WEEK]);
     tm->tm_mday =3D from_bcd(s, s->hw.cmos_data[RTC_DAY_OF_MONTH]);
     tm->tm_mon =3D from_bcd(s, s->hw.cmos_data[RTC_MONTH]) - 1;
--- a/xen/arch/x86/hvm/vpt.c
+++ b/xen/arch/x86/hvm/vpt.c
@@ -22,6 +22,7 @@
 #include <asm/hvm/vpt.h>
 #include <asm/event.h>
 #include <asm/apic.h>
+#include <asm/mc146818rtc.h>
=20
 #define mode_is(d, name) \
     ((d)->arch.hvm_domain.params[HVM_PARAM_TIMER_MODE] =3D=3D HVMPTM_##nam=
e)
@@ -218,6 +219,7 @@ void pt_update_irq(struct vcpu *v)
     struct periodic_time *pt, *temp, *earliest_pt =3D NULL;
     uint64_t max_lag =3D -1ULL;
     int irq, is_lapic;
+    void *pt_priv;
=20
     spin_lock(&v->arch.hvm_vcpu.tm_lock);
=20
@@ -251,13 +253,14 @@ void pt_update_irq(struct vcpu *v)
     earliest_pt->irq_issued =3D 1;
     irq =3D earliest_pt->irq;
     is_lapic =3D (earliest_pt->source =3D=3D PTSRC_lapic);
+    pt_priv =3D earliest_pt->priv;
=20
     spin_unlock(&v->arch.hvm_vcpu.tm_lock);
=20
     if ( is_lapic )
-    {
         vlapic_set_irq(vcpu_vlapic(v), irq, 0);
-    }
+    else if ( irq =3D=3D RTC_IRQ && pt_priv )
+        rtc_periodic_interrupt(pt_priv);
     else
     {
         hvm_isa_irq_deassert(v->domain, irq);
--- a/xen/include/asm-x86/hvm/vpt.h
+++ b/xen/include/asm-x86/hvm/vpt.h
@@ -181,6 +181,7 @@ void rtc_migrate_timers(struct vcpu *v);
 void rtc_deinit(struct domain *d);
 void rtc_reset(struct domain *d);
 void rtc_update_clock(struct domain *d);
+void rtc_periodic_interrupt(void *);
=20
 void pmtimer_init(struct vcpu *v);
 void pmtimer_deinit(struct domain *d);



--=__PartB382A732.0__=
Content-Type: text/plain; name="x86-hvm-rtc.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="x86-hvm-rtc.patch"

x86/HVM: assorted RTC emulation adjustments=0A=0A- don't look at RTC_PIE =
in rtc_timer_update(), and hence don't call the=0A  function on REG_B =
writes at all=0A- only call alarm_timer_update() on REG_B writes when =
relevant bits=0A  change=0A- only call check_update_timer() on REG_B =
writes when SET changes=0A- instead properly handle AF and PF when the =
guest is not also setting=0A  AIE/PIE respectively (for UF this was =
already the case, only a=0A  comment was slightly inaccurate)=0A- raise =
the RTC IRQ not only when UIE gets set while UF was already=0A  set, but =
generalize this to cover AIE and PIE as well=0A- properly mask off bit 7 =
when retrieving the hour values in=0A  alarm_timer_update(), and properly =
use RTC_HOURS_ALARM's bit 7 when=0A  converting from 12- to 24-hour =
value=0A- also handle the two other possible clock bases=0A- use RTC_* =
names in a couple of places where literal numbers were used=0A  so =
far=0A=0ASigned-off-by: Jan Beulich <jbeulich@suse.com>=0A=0A--- a/xen/arch=
/x86/hvm/rtc.c=0A+++ b/xen/arch/x86/hvm/rtc.c=0A@@ -50,11 +50,24 @@ static =
void rtc_set_time(RTCState *s);=0A static inline int from_bcd(RTCState *s, =
int a);=0A static inline int convert_hour(RTCState *s, int hour);=0A =
=0A-static void rtc_periodic_cb(struct vcpu *v, void *opaque)=0A+static =
void rtc_toggle_irq(RTCState *s)=0A+{=0A+    struct domain *d =3D =
vrtc_domain(s);=0A+=0A+    ASSERT(spin_is_locked(&s->lock));=0A+    =
s->hw.cmos_data[RTC_REG_C] |=3D RTC_IRQF;=0A+    hvm_isa_irq_deassert(d, =
RTC_IRQ);=0A+    hvm_isa_irq_assert(d, RTC_IRQ);=0A+}=0A+=0A+void =
rtc_periodic_interrupt(void *opaque)=0A {=0A     RTCState *s =3D opaque;=0A=
+=0A     spin_lock(&s->lock);=0A-    s->hw.cmos_data[RTC_REG_C] |=3D =
0xc0;=0A+    s->hw.cmos_data[RTC_REG_C] |=3D RTC_PF;=0A+    if ( s->hw.cmos=
_data[RTC_REG_B] & RTC_PIE )=0A+        rtc_toggle_irq(s);=0A     =
spin_unlock(&s->lock);=0A }=0A =0A@@ -68,19 +81,25 @@ static void =
rtc_timer_update(RTCState *s=0A     ASSERT(spin_is_locked(&s->lock));=0A =
=0A     period_code =3D s->hw.cmos_data[RTC_REG_A] & RTC_RATE_SELECT;=0A-  =
  if ( (period_code !=3D 0) && (s->hw.cmos_data[RTC_REG_B] & RTC_PIE) =
)=0A+    switch ( s->hw.cmos_data[RTC_REG_A] & RTC_DIV_CTL )=0A     {=0A-  =
      if ( period_code <=3D 2 )=0A+    case RTC_REF_CLCK_32KHZ:=0A+        =
if ( (period_code !=3D 0) && (period_code <=3D 2) )=0A             =
period_code +=3D 7;=0A-=0A-        period =3D 1 << (period_code - 1); /* =
period in 32 Khz cycles */=0A-        period =3D DIV_ROUND((period * =
1000000000ULL), 32768); /* period in ns */=0A-        create_periodic_time(=
v, &s->pt, period, period, RTC_IRQ,=0A-                             =
rtc_periodic_cb, s);=0A-    }=0A-    else=0A-    {=0A+        /* fall =
through */=0A+    case RTC_REF_CLCK_1MHZ:=0A+    case RTC_REF_CLCK_4MHZ:=0A=
+        if ( period_code !=3D 0 )=0A+        {=0A+            period =3D =
1 << (period_code - 1); /* period in 32 Khz cycles */=0A+            =
period =3D DIV_ROUND(period * 1000000000ULL, 32768); /* in ns */=0A+       =
     create_periodic_time(v, &s->pt, period, period, RTC_IRQ, NULL, =
s);=0A+            break;=0A+        }=0A+        /* fall through */=0A+   =
 default:=0A         destroy_periodic_time(&s->pt);=0A+        break;=0A   =
  }=0A }=0A =0A@@ -102,7 +121,7 @@ static void check_update_timer(RTCState =
=0A         guest_usec =3D get_localtime_us(d) % USEC_PER_SEC;=0A         =
if (guest_usec >=3D (USEC_PER_SEC - 244))=0A         {=0A-            /* =
RTC is in update cycle when enabling UIE */=0A+            /* RTC is in =
update cycle */=0A             s->hw.cmos_data[RTC_REG_A] |=3D RTC_UIP;=0A =
            next_update_time =3D (USEC_PER_SEC - guest_usec) * NS_PER_USEC;=
=0A             expire_time =3D NOW() + next_update_time;=0A@@ -144,7 =
+163,6 @@ static void rtc_update_timer(void *opaqu=0A static void =
rtc_update_timer2(void *opaque)=0A {=0A     RTCState *s =3D opaque;=0A-    =
struct domain *d =3D vrtc_domain(s);=0A =0A     spin_lock(&s->lock);=0A    =
 if (!(s->hw.cmos_data[RTC_REG_B] & RTC_SET))=0A@@ -152,11 +170,7 @@ =
static void rtc_update_timer2(void *opaq=0A         s->hw.cmos_data[RTC_REG=
_C] |=3D RTC_UF;=0A         s->hw.cmos_data[RTC_REG_A] &=3D ~RTC_UIP;=0A   =
      if ((s->hw.cmos_data[RTC_REG_B] & RTC_UIE))=0A-        {=0A-         =
   s->hw.cmos_data[RTC_REG_C] |=3D RTC_IRQF;=0A-            hvm_isa_irq_dea=
ssert(d, RTC_IRQ);=0A-            hvm_isa_irq_assert(d, RTC_IRQ);=0A-      =
  }=0A+            rtc_toggle_irq(s);=0A         check_update_timer(s);=0A =
    }=0A     spin_unlock(&s->lock);=0A@@ -175,21 +189,18 @@ static void =
alarm_timer_update(RTCState =0A =0A     stop_timer(&s->alarm_timer);=0A =
=0A-    if ((s->hw.cmos_data[RTC_REG_B] & RTC_AIE) &&=0A-            =
!(s->hw.cmos_data[RTC_REG_B] & RTC_SET))=0A+    if ( !(s->hw.cmos_data[RTC_=
REG_B] & RTC_SET) )=0A     {=0A         s->current_tm =3D gmtime(get_localt=
ime(d));=0A         rtc_copy_date(s);=0A =0A         alarm_sec =3D =
from_bcd(s, s->hw.cmos_data[RTC_SECONDS_ALARM]);=0A         alarm_min =3D =
from_bcd(s, s->hw.cmos_data[RTC_MINUTES_ALARM]);=0A-        alarm_hour =3D =
from_bcd(s, s->hw.cmos_data[RTC_HOURS_ALARM]);=0A-        alarm_hour =3D =
convert_hour(s, alarm_hour);=0A+        alarm_hour =3D convert_hour(s, =
s->hw.cmos_data[RTC_HOURS_ALARM]);=0A =0A         cur_sec =3D from_bcd(s, =
s->hw.cmos_data[RTC_SECONDS]);=0A         cur_min =3D from_bcd(s, =
s->hw.cmos_data[RTC_MINUTES]);=0A-        cur_hour =3D from_bcd(s, =
s->hw.cmos_data[RTC_HOURS]);=0A-        cur_hour =3D convert_hour(s, =
cur_hour);=0A+        cur_hour =3D convert_hour(s, s->hw.cmos_data[RTC_HOUR=
S]);=0A =0A         next_update_time =3D USEC_PER_SEC - (get_localtime_us(d=
) % USEC_PER_SEC);=0A         next_update_time =3D next_update_time * =
NS_PER_USEC + NOW();=0A@@ -343,7 +354,6 @@ static void alarm_timer_update(R=
TCState =0A static void rtc_alarm_cb(void *opaque)=0A {=0A     RTCState *s =
=3D opaque;=0A-    struct domain *d =3D vrtc_domain(s);=0A =0A     =
spin_lock(&s->lock);=0A     if (!(s->hw.cmos_data[RTC_REG_B] & RTC_SET))=0A=
@@ -351,11 +361,7 @@ static void rtc_alarm_cb(void *opaque)=0A         =
s->hw.cmos_data[RTC_REG_C] |=3D RTC_AF;=0A         /* alarm interrupt =
*/=0A         if (s->hw.cmos_data[RTC_REG_B] & RTC_AIE)=0A-        {=0A-   =
         s->hw.cmos_data[RTC_REG_C] |=3D RTC_IRQF;=0A-            =
hvm_isa_irq_deassert(d, RTC_IRQ);=0A-            hvm_isa_irq_assert(d, =
RTC_IRQ);=0A-        }=0A+            rtc_toggle_irq(s);=0A         =
alarm_timer_update(s);=0A     }=0A     spin_unlock(&s->lock);=0A@@ -365,7 =
+371,7 @@ static int rtc_ioport_write(void *opaque=0A {=0A     RTCState *s =
=3D opaque;=0A     struct domain *d =3D vrtc_domain(s);=0A-    uint32_t =
orig;=0A+    uint32_t orig, mask;=0A =0A     spin_lock(&s->lock);=0A =0A@@ =
-417,7 +423,7 @@ static int rtc_ioport_write(void *opaque=0A             =
/* set mode: reset UIP mode */=0A             s->hw.cmos_data[RTC_REG_A] =
&=3D ~RTC_UIP;=0A             /* adjust cmos before stopping */=0A-        =
    if (!(s->hw.cmos_data[RTC_REG_B] & RTC_SET))=0A+            if (!(orig =
& RTC_SET))=0A             {=0A                 s->current_tm =3D =
gmtime(get_localtime(d));=0A                 rtc_copy_date(s);=0A@@ =
-426,22 +432,26 @@ static int rtc_ioport_write(void *opaque=0A         =
else=0A         {=0A             /* if disabling set mode, update the time =
*/=0A-            if ( s->hw.cmos_data[RTC_REG_B] & RTC_SET )=0A+          =
  if ( orig & RTC_SET )=0A                 rtc_set_time(s);=0A         =
}=0A-        /* if the interrupt is already set when the interrupt =
become=0A-         * enabled, raise an interrupt immediately*/=0A-        =
if ((data & RTC_UIE) && !(s->hw.cmos_data[RTC_REG_B] & RTC_UIE))=0A-       =
     if (s->hw.cmos_data[RTC_REG_C] & RTC_UF)=0A+        /*=0A+         * =
If the interrupt is already set when the interrupt becomes=0A+         * =
enabled, raise an interrupt immediately.=0A+         * NB: RTC_{A,P,U}IE =
=3D=3D RTC_{A,P,U}F respectively.=0A+         */=0A+        for ( mask =3D =
RTC_UIE; mask <=3D RTC_PIE; mask <<=3D 1 )=0A+            if ( (data & =
mask) && !(orig & mask) &&=0A+                 (s->hw.cmos_data[RTC_REG_C] =
& mask) )=0A             {=0A-                hvm_isa_irq_deassert(d, =
RTC_IRQ);=0A-                hvm_isa_irq_assert(d, RTC_IRQ);=0A+           =
     rtc_toggle_irq(s);=0A+                break;=0A             }=0A      =
   s->hw.cmos_data[RTC_REG_B] =3D data;=0A-        if ( (data ^ orig) & =
RTC_PIE )=0A-            rtc_timer_update(s);=0A-        check_update_timer=
(s);=0A-        alarm_timer_update(s);=0A+        if ( (data ^ orig) & =
RTC_SET )=0A+            check_update_timer(s);=0A+        if ( (data ^ =
orig) & (RTC_24H | RTC_DM_BINARY | RTC_SET) )=0A+            alarm_timer_up=
date(s);=0A         break;=0A     case RTC_REG_C:=0A     case RTC_REG_D:=0A=
@@ -456,7 +466,7 @@ static int rtc_ioport_write(void *opaque=0A =0A static =
inline int to_bcd(RTCState *s, int a)=0A {=0A-    if ( s->hw.cmos_data[RTC_=
REG_B] & 0x04 )=0A+    if ( s->hw.cmos_data[RTC_REG_B] & RTC_DM_BINARY =
)=0A         return a;=0A     else=0A         return ((a / 10) << 4) | (a =
% 10);=0A@@ -464,7 +474,7 @@ static inline int to_bcd(RTCState *s, in=0A =
=0A static inline int from_bcd(RTCState *s, int a)=0A {=0A-    if ( =
s->hw.cmos_data[RTC_REG_B] & 0x04 )=0A+    if ( s->hw.cmos_data[RTC_REG_B] =
& RTC_DM_BINARY )=0A         return a;=0A     else=0A         return ((a =
>> 4) * 10) + (a & 0x0f);=0A@@ -472,12 +482,14 @@ static inline int =
from_bcd(RTCState *s, =0A =0A /* Hours in 12 hour mode are in 1-12 range, =
not 0-11.=0A  * So we need convert it before using it*/=0A-static inline =
int convert_hour(RTCState *s, int hour)=0A+static inline int convert_hour(R=
TCState *s, int raw)=0A {=0A+    int hour =3D from_bcd(s, raw & 0x7f);=0A+=
=0A     if (!(s->hw.cmos_data[RTC_REG_B] & RTC_24H))=0A     {=0A         =
hour %=3D 12;=0A-        if (s->hw.cmos_data[RTC_HOURS] & 0x80)=0A+        =
if (raw & 0x80)=0A             hour +=3D 12;=0A     }=0A     return =
hour;=0A@@ -496,8 +508,7 @@ static void rtc_set_time(RTCState *s)=0A     =
=0A     tm->tm_sec =3D from_bcd(s, s->hw.cmos_data[RTC_SECONDS]);=0A     =
tm->tm_min =3D from_bcd(s, s->hw.cmos_data[RTC_MINUTES]);=0A-    tm->tm_hou=
r =3D from_bcd(s, s->hw.cmos_data[RTC_HOURS] & 0x7f);=0A-    tm->tm_hour =
=3D convert_hour(s, tm->tm_hour);=0A+    tm->tm_hour =3D convert_hour(s, =
s->hw.cmos_data[RTC_HOURS]);=0A     tm->tm_wday =3D from_bcd(s, s->hw.cmos_=
data[RTC_DAY_OF_WEEK]);=0A     tm->tm_mday =3D from_bcd(s, s->hw.cmos_data[=
RTC_DAY_OF_MONTH]);=0A     tm->tm_mon =3D from_bcd(s, s->hw.cmos_data[RTC_M=
ONTH]) - 1;=0A--- a/xen/arch/x86/hvm/vpt.c=0A+++ b/xen/arch/x86/hvm/vpt.c=
=0A@@ -22,6 +22,7 @@=0A #include <asm/hvm/vpt.h>=0A #include <asm/event.h>=
=0A #include <asm/apic.h>=0A+#include <asm/mc146818rtc.h>=0A =0A #define =
mode_is(d, name) \=0A     ((d)->arch.hvm_domain.params[HVM_PARAM_TIMER_MODE=
] =3D=3D HVMPTM_##name)=0A@@ -218,6 +219,7 @@ void pt_update_irq(struct =
vcpu *v)=0A     struct periodic_time *pt, *temp, *earliest_pt =3D NULL;=0A =
    uint64_t max_lag =3D -1ULL;=0A     int irq, is_lapic;=0A+    void =
*pt_priv;=0A =0A     spin_lock(&v->arch.hvm_vcpu.tm_lock);=0A =0A@@ =
-251,13 +253,14 @@ void pt_update_irq(struct vcpu *v)=0A     earliest_pt->i=
rq_issued =3D 1;=0A     irq =3D earliest_pt->irq;=0A     is_lapic =3D =
(earliest_pt->source =3D=3D PTSRC_lapic);=0A+    pt_priv =3D earliest_pt->p=
riv;=0A =0A     spin_unlock(&v->arch.hvm_vcpu.tm_lock);=0A =0A     if ( =
is_lapic )=0A-    {=0A         vlapic_set_irq(vcpu_vlapic(v), irq, 0);=0A- =
   }=0A+    else if ( irq =3D=3D RTC_IRQ && pt_priv )=0A+        rtc_period=
ic_interrupt(pt_priv);=0A     else=0A     {=0A         hvm_isa_irq_deassert=
(v->domain, irq);=0A--- a/xen/include/asm-x86/hvm/vpt.h=0A+++ b/xen/include=
/asm-x86/hvm/vpt.h=0A@@ -181,6 +181,7 @@ void rtc_migrate_timers(struct =
vcpu *v);=0A void rtc_deinit(struct domain *d);=0A void rtc_reset(struct =
domain *d);=0A void rtc_update_clock(struct domain *d);=0A+void rtc_periodi=
c_interrupt(void *);=0A =0A void pmtimer_init(struct vcpu *v);=0A void =
pmtimer_deinit(struct domain *d);=0A
--=__PartB382A732.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

--=__PartB382A732.0__=--


From xen-devel-bounces@lists.xen.org Fri Sep 07 13:01:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Sep 2012 13: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 1T9yBC-000510-PS; Fri, 07 Sep 2012 13:01:02 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1T9yBB-00050p-4v
	for xen-devel@lists.xen.org; Fri, 07 Sep 2012 13:01:01 +0000
Received: from [85.158.143.99:35889] by server-2.bemta-4.messagelabs.com id
	B3/05-21239-C00F9405; Fri, 07 Sep 2012 13:01:00 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1347022827!29113976!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM4ODU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28384 invoked from network); 7 Sep 2012 13:00:34 -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;
	7 Sep 2012 13:00:34 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 07 Sep 2012 14:00:27 +0100
Message-Id: <504A0C420200007800099CD6@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 07 Sep 2012 14:01:22 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__PartB382A732.0__="
Subject: [Xen-devel] [PATCH, v3] x86/HVM: assorted RTC emulation adjustments
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=__PartB382A732.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

- don't look at RTC_PIE in rtc_timer_update(), and hence don't call the
  function on REG_B writes at all
- only call alarm_timer_update() on REG_B writes when relevant bits
  change
- only call check_update_timer() on REG_B writes when SET changes
- instead properly handle AF and PF when the guest is not also setting
  AIE/PIE respectively (for UF this was already the case, only a
  comment was slightly inaccurate)
- raise the RTC IRQ not only when UIE gets set while UF was already
  set, but generalize this to cover AIE and PIE as well
- properly mask off bit 7 when retrieving the hour values in
  alarm_timer_update(), and properly use RTC_HOURS_ALARM's bit 7 when
  converting from 12- to 24-hour value
- also handle the two other possible clock bases
- use RTC_* names in a couple of places where literal numbers were used
  so far

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/arch/x86/hvm/rtc.c
+++ b/xen/arch/x86/hvm/rtc.c
@@ -50,11 +50,24 @@ static void rtc_set_time(RTCState *s);
 static inline int from_bcd(RTCState *s, int a);
 static inline int convert_hour(RTCState *s, int hour);
=20
-static void rtc_periodic_cb(struct vcpu *v, void *opaque)
+static void rtc_toggle_irq(RTCState *s)
+{
+    struct domain *d =3D vrtc_domain(s);
+
+    ASSERT(spin_is_locked(&s->lock));
+    s->hw.cmos_data[RTC_REG_C] |=3D RTC_IRQF;
+    hvm_isa_irq_deassert(d, RTC_IRQ);
+    hvm_isa_irq_assert(d, RTC_IRQ);
+}
+
+void rtc_periodic_interrupt(void *opaque)
 {
     RTCState *s =3D opaque;
+
     spin_lock(&s->lock);
-    s->hw.cmos_data[RTC_REG_C] |=3D 0xc0;
+    s->hw.cmos_data[RTC_REG_C] |=3D RTC_PF;
+    if ( s->hw.cmos_data[RTC_REG_B] & RTC_PIE )
+        rtc_toggle_irq(s);
     spin_unlock(&s->lock);
 }
=20
@@ -68,19 +81,25 @@ static void rtc_timer_update(RTCState *s
     ASSERT(spin_is_locked(&s->lock));
=20
     period_code =3D s->hw.cmos_data[RTC_REG_A] & RTC_RATE_SELECT;
-    if ( (period_code !=3D 0) && (s->hw.cmos_data[RTC_REG_B] & RTC_PIE) )
+    switch ( s->hw.cmos_data[RTC_REG_A] & RTC_DIV_CTL )
     {
-        if ( period_code <=3D 2 )
+    case RTC_REF_CLCK_32KHZ:
+        if ( (period_code !=3D 0) && (period_code <=3D 2) )
             period_code +=3D 7;
-
-        period =3D 1 << (period_code - 1); /* period in 32 Khz cycles */
-        period =3D DIV_ROUND((period * 1000000000ULL), 32768); /* period =
in ns */
-        create_periodic_time(v, &s->pt, period, period, RTC_IRQ,
-                             rtc_periodic_cb, s);
-    }
-    else
-    {
+        /* fall through */
+    case RTC_REF_CLCK_1MHZ:
+    case RTC_REF_CLCK_4MHZ:
+        if ( period_code !=3D 0 )
+        {
+            period =3D 1 << (period_code - 1); /* period in 32 Khz cycles =
*/
+            period =3D DIV_ROUND(period * 1000000000ULL, 32768); /* in ns =
*/
+            create_periodic_time(v, &s->pt, period, period, RTC_IRQ, =
NULL, s);
+            break;
+        }
+        /* fall through */
+    default:
         destroy_periodic_time(&s->pt);
+        break;
     }
 }
=20
@@ -102,7 +121,7 @@ static void check_update_timer(RTCState=20
         guest_usec =3D get_localtime_us(d) % USEC_PER_SEC;
         if (guest_usec >=3D (USEC_PER_SEC - 244))
         {
-            /* RTC is in update cycle when enabling UIE */
+            /* RTC is in update cycle */
             s->hw.cmos_data[RTC_REG_A] |=3D RTC_UIP;
             next_update_time =3D (USEC_PER_SEC - guest_usec) * NS_PER_USEC=
;
             expire_time =3D NOW() + next_update_time;
@@ -144,7 +163,6 @@ static void rtc_update_timer(void *opaqu
 static void rtc_update_timer2(void *opaque)
 {
     RTCState *s =3D opaque;
-    struct domain *d =3D vrtc_domain(s);
=20
     spin_lock(&s->lock);
     if (!(s->hw.cmos_data[RTC_REG_B] & RTC_SET))
@@ -152,11 +170,7 @@ static void rtc_update_timer2(void *opaq
         s->hw.cmos_data[RTC_REG_C] |=3D RTC_UF;
         s->hw.cmos_data[RTC_REG_A] &=3D ~RTC_UIP;
         if ((s->hw.cmos_data[RTC_REG_B] & RTC_UIE))
-        {
-            s->hw.cmos_data[RTC_REG_C] |=3D RTC_IRQF;
-            hvm_isa_irq_deassert(d, RTC_IRQ);
-            hvm_isa_irq_assert(d, RTC_IRQ);
-        }
+            rtc_toggle_irq(s);
         check_update_timer(s);
     }
     spin_unlock(&s->lock);
@@ -175,21 +189,18 @@ static void alarm_timer_update(RTCState=20
=20
     stop_timer(&s->alarm_timer);
=20
-    if ((s->hw.cmos_data[RTC_REG_B] & RTC_AIE) &&
-            !(s->hw.cmos_data[RTC_REG_B] & RTC_SET))
+    if ( !(s->hw.cmos_data[RTC_REG_B] & RTC_SET) )
     {
         s->current_tm =3D gmtime(get_localtime(d));
         rtc_copy_date(s);
=20
         alarm_sec =3D from_bcd(s, s->hw.cmos_data[RTC_SECONDS_ALARM]);
         alarm_min =3D from_bcd(s, s->hw.cmos_data[RTC_MINUTES_ALARM]);
-        alarm_hour =3D from_bcd(s, s->hw.cmos_data[RTC_HOURS_ALARM]);
-        alarm_hour =3D convert_hour(s, alarm_hour);
+        alarm_hour =3D convert_hour(s, s->hw.cmos_data[RTC_HOURS_ALARM]);
=20
         cur_sec =3D from_bcd(s, s->hw.cmos_data[RTC_SECONDS]);
         cur_min =3D from_bcd(s, s->hw.cmos_data[RTC_MINUTES]);
-        cur_hour =3D from_bcd(s, s->hw.cmos_data[RTC_HOURS]);
-        cur_hour =3D convert_hour(s, cur_hour);
+        cur_hour =3D convert_hour(s, s->hw.cmos_data[RTC_HOURS]);
=20
         next_update_time =3D USEC_PER_SEC - (get_localtime_us(d) % =
USEC_PER_SEC);
         next_update_time =3D next_update_time * NS_PER_USEC + NOW();
@@ -343,7 +354,6 @@ static void alarm_timer_update(RTCState=20
 static void rtc_alarm_cb(void *opaque)
 {
     RTCState *s =3D opaque;
-    struct domain *d =3D vrtc_domain(s);
=20
     spin_lock(&s->lock);
     if (!(s->hw.cmos_data[RTC_REG_B] & RTC_SET))
@@ -351,11 +361,7 @@ static void rtc_alarm_cb(void *opaque)
         s->hw.cmos_data[RTC_REG_C] |=3D RTC_AF;
         /* alarm interrupt */
         if (s->hw.cmos_data[RTC_REG_B] & RTC_AIE)
-        {
-            s->hw.cmos_data[RTC_REG_C] |=3D RTC_IRQF;
-            hvm_isa_irq_deassert(d, RTC_IRQ);
-            hvm_isa_irq_assert(d, RTC_IRQ);
-        }
+            rtc_toggle_irq(s);
         alarm_timer_update(s);
     }
     spin_unlock(&s->lock);
@@ -365,7 +371,7 @@ static int rtc_ioport_write(void *opaque
 {
     RTCState *s =3D opaque;
     struct domain *d =3D vrtc_domain(s);
-    uint32_t orig;
+    uint32_t orig, mask;
=20
     spin_lock(&s->lock);
=20
@@ -417,7 +423,7 @@ static int rtc_ioport_write(void *opaque
             /* set mode: reset UIP mode */
             s->hw.cmos_data[RTC_REG_A] &=3D ~RTC_UIP;
             /* adjust cmos before stopping */
-            if (!(s->hw.cmos_data[RTC_REG_B] & RTC_SET))
+            if (!(orig & RTC_SET))
             {
                 s->current_tm =3D gmtime(get_localtime(d));
                 rtc_copy_date(s);
@@ -426,22 +432,26 @@ static int rtc_ioport_write(void *opaque
         else
         {
             /* if disabling set mode, update the time */
-            if ( s->hw.cmos_data[RTC_REG_B] & RTC_SET )
+            if ( orig & RTC_SET )
                 rtc_set_time(s);
         }
-        /* if the interrupt is already set when the interrupt become
-         * enabled, raise an interrupt immediately*/
-        if ((data & RTC_UIE) && !(s->hw.cmos_data[RTC_REG_B] & RTC_UIE))
-            if (s->hw.cmos_data[RTC_REG_C] & RTC_UF)
+        /*
+         * If the interrupt is already set when the interrupt becomes
+         * enabled, raise an interrupt immediately.
+         * NB: RTC_{A,P,U}IE =3D=3D RTC_{A,P,U}F respectively.
+         */
+        for ( mask =3D RTC_UIE; mask <=3D RTC_PIE; mask <<=3D 1 )
+            if ( (data & mask) && !(orig & mask) &&
+                 (s->hw.cmos_data[RTC_REG_C] & mask) )
             {
-                hvm_isa_irq_deassert(d, RTC_IRQ);
-                hvm_isa_irq_assert(d, RTC_IRQ);
+                rtc_toggle_irq(s);
+                break;
             }
         s->hw.cmos_data[RTC_REG_B] =3D data;
-        if ( (data ^ orig) & RTC_PIE )
-            rtc_timer_update(s);
-        check_update_timer(s);
-        alarm_timer_update(s);
+        if ( (data ^ orig) & RTC_SET )
+            check_update_timer(s);
+        if ( (data ^ orig) & (RTC_24H | RTC_DM_BINARY | RTC_SET) )
+            alarm_timer_update(s);
         break;
     case RTC_REG_C:
     case RTC_REG_D:
@@ -456,7 +466,7 @@ static int rtc_ioport_write(void *opaque
=20
 static inline int to_bcd(RTCState *s, int a)
 {
-    if ( s->hw.cmos_data[RTC_REG_B] & 0x04 )
+    if ( s->hw.cmos_data[RTC_REG_B] & RTC_DM_BINARY )
         return a;
     else
         return ((a / 10) << 4) | (a % 10);
@@ -464,7 +474,7 @@ static inline int to_bcd(RTCState *s, in
=20
 static inline int from_bcd(RTCState *s, int a)
 {
-    if ( s->hw.cmos_data[RTC_REG_B] & 0x04 )
+    if ( s->hw.cmos_data[RTC_REG_B] & RTC_DM_BINARY )
         return a;
     else
         return ((a >> 4) * 10) + (a & 0x0f);
@@ -472,12 +482,14 @@ static inline int from_bcd(RTCState *s,=20
=20
 /* Hours in 12 hour mode are in 1-12 range, not 0-11.
  * So we need convert it before using it*/
-static inline int convert_hour(RTCState *s, int hour)
+static inline int convert_hour(RTCState *s, int raw)
 {
+    int hour =3D from_bcd(s, raw & 0x7f);
+
     if (!(s->hw.cmos_data[RTC_REG_B] & RTC_24H))
     {
         hour %=3D 12;
-        if (s->hw.cmos_data[RTC_HOURS] & 0x80)
+        if (raw & 0x80)
             hour +=3D 12;
     }
     return hour;
@@ -496,8 +508,7 @@ static void rtc_set_time(RTCState *s)
    =20
     tm->tm_sec =3D from_bcd(s, s->hw.cmos_data[RTC_SECONDS]);
     tm->tm_min =3D from_bcd(s, s->hw.cmos_data[RTC_MINUTES]);
-    tm->tm_hour =3D from_bcd(s, s->hw.cmos_data[RTC_HOURS] & 0x7f);
-    tm->tm_hour =3D convert_hour(s, tm->tm_hour);
+    tm->tm_hour =3D convert_hour(s, s->hw.cmos_data[RTC_HOURS]);
     tm->tm_wday =3D from_bcd(s, s->hw.cmos_data[RTC_DAY_OF_WEEK]);
     tm->tm_mday =3D from_bcd(s, s->hw.cmos_data[RTC_DAY_OF_MONTH]);
     tm->tm_mon =3D from_bcd(s, s->hw.cmos_data[RTC_MONTH]) - 1;
--- a/xen/arch/x86/hvm/vpt.c
+++ b/xen/arch/x86/hvm/vpt.c
@@ -22,6 +22,7 @@
 #include <asm/hvm/vpt.h>
 #include <asm/event.h>
 #include <asm/apic.h>
+#include <asm/mc146818rtc.h>
=20
 #define mode_is(d, name) \
     ((d)->arch.hvm_domain.params[HVM_PARAM_TIMER_MODE] =3D=3D HVMPTM_##nam=
e)
@@ -218,6 +219,7 @@ void pt_update_irq(struct vcpu *v)
     struct periodic_time *pt, *temp, *earliest_pt =3D NULL;
     uint64_t max_lag =3D -1ULL;
     int irq, is_lapic;
+    void *pt_priv;
=20
     spin_lock(&v->arch.hvm_vcpu.tm_lock);
=20
@@ -251,13 +253,14 @@ void pt_update_irq(struct vcpu *v)
     earliest_pt->irq_issued =3D 1;
     irq =3D earliest_pt->irq;
     is_lapic =3D (earliest_pt->source =3D=3D PTSRC_lapic);
+    pt_priv =3D earliest_pt->priv;
=20
     spin_unlock(&v->arch.hvm_vcpu.tm_lock);
=20
     if ( is_lapic )
-    {
         vlapic_set_irq(vcpu_vlapic(v), irq, 0);
-    }
+    else if ( irq =3D=3D RTC_IRQ && pt_priv )
+        rtc_periodic_interrupt(pt_priv);
     else
     {
         hvm_isa_irq_deassert(v->domain, irq);
--- a/xen/include/asm-x86/hvm/vpt.h
+++ b/xen/include/asm-x86/hvm/vpt.h
@@ -181,6 +181,7 @@ void rtc_migrate_timers(struct vcpu *v);
 void rtc_deinit(struct domain *d);
 void rtc_reset(struct domain *d);
 void rtc_update_clock(struct domain *d);
+void rtc_periodic_interrupt(void *);
=20
 void pmtimer_init(struct vcpu *v);
 void pmtimer_deinit(struct domain *d);



--=__PartB382A732.0__=
Content-Type: text/plain; name="x86-hvm-rtc.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="x86-hvm-rtc.patch"

x86/HVM: assorted RTC emulation adjustments=0A=0A- don't look at RTC_PIE =
in rtc_timer_update(), and hence don't call the=0A  function on REG_B =
writes at all=0A- only call alarm_timer_update() on REG_B writes when =
relevant bits=0A  change=0A- only call check_update_timer() on REG_B =
writes when SET changes=0A- instead properly handle AF and PF when the =
guest is not also setting=0A  AIE/PIE respectively (for UF this was =
already the case, only a=0A  comment was slightly inaccurate)=0A- raise =
the RTC IRQ not only when UIE gets set while UF was already=0A  set, but =
generalize this to cover AIE and PIE as well=0A- properly mask off bit 7 =
when retrieving the hour values in=0A  alarm_timer_update(), and properly =
use RTC_HOURS_ALARM's bit 7 when=0A  converting from 12- to 24-hour =
value=0A- also handle the two other possible clock bases=0A- use RTC_* =
names in a couple of places where literal numbers were used=0A  so =
far=0A=0ASigned-off-by: Jan Beulich <jbeulich@suse.com>=0A=0A--- a/xen/arch=
/x86/hvm/rtc.c=0A+++ b/xen/arch/x86/hvm/rtc.c=0A@@ -50,11 +50,24 @@ static =
void rtc_set_time(RTCState *s);=0A static inline int from_bcd(RTCState *s, =
int a);=0A static inline int convert_hour(RTCState *s, int hour);=0A =
=0A-static void rtc_periodic_cb(struct vcpu *v, void *opaque)=0A+static =
void rtc_toggle_irq(RTCState *s)=0A+{=0A+    struct domain *d =3D =
vrtc_domain(s);=0A+=0A+    ASSERT(spin_is_locked(&s->lock));=0A+    =
s->hw.cmos_data[RTC_REG_C] |=3D RTC_IRQF;=0A+    hvm_isa_irq_deassert(d, =
RTC_IRQ);=0A+    hvm_isa_irq_assert(d, RTC_IRQ);=0A+}=0A+=0A+void =
rtc_periodic_interrupt(void *opaque)=0A {=0A     RTCState *s =3D opaque;=0A=
+=0A     spin_lock(&s->lock);=0A-    s->hw.cmos_data[RTC_REG_C] |=3D =
0xc0;=0A+    s->hw.cmos_data[RTC_REG_C] |=3D RTC_PF;=0A+    if ( s->hw.cmos=
_data[RTC_REG_B] & RTC_PIE )=0A+        rtc_toggle_irq(s);=0A     =
spin_unlock(&s->lock);=0A }=0A =0A@@ -68,19 +81,25 @@ static void =
rtc_timer_update(RTCState *s=0A     ASSERT(spin_is_locked(&s->lock));=0A =
=0A     period_code =3D s->hw.cmos_data[RTC_REG_A] & RTC_RATE_SELECT;=0A-  =
  if ( (period_code !=3D 0) && (s->hw.cmos_data[RTC_REG_B] & RTC_PIE) =
)=0A+    switch ( s->hw.cmos_data[RTC_REG_A] & RTC_DIV_CTL )=0A     {=0A-  =
      if ( period_code <=3D 2 )=0A+    case RTC_REF_CLCK_32KHZ:=0A+        =
if ( (period_code !=3D 0) && (period_code <=3D 2) )=0A             =
period_code +=3D 7;=0A-=0A-        period =3D 1 << (period_code - 1); /* =
period in 32 Khz cycles */=0A-        period =3D DIV_ROUND((period * =
1000000000ULL), 32768); /* period in ns */=0A-        create_periodic_time(=
v, &s->pt, period, period, RTC_IRQ,=0A-                             =
rtc_periodic_cb, s);=0A-    }=0A-    else=0A-    {=0A+        /* fall =
through */=0A+    case RTC_REF_CLCK_1MHZ:=0A+    case RTC_REF_CLCK_4MHZ:=0A=
+        if ( period_code !=3D 0 )=0A+        {=0A+            period =3D =
1 << (period_code - 1); /* period in 32 Khz cycles */=0A+            =
period =3D DIV_ROUND(period * 1000000000ULL, 32768); /* in ns */=0A+       =
     create_periodic_time(v, &s->pt, period, period, RTC_IRQ, NULL, =
s);=0A+            break;=0A+        }=0A+        /* fall through */=0A+   =
 default:=0A         destroy_periodic_time(&s->pt);=0A+        break;=0A   =
  }=0A }=0A =0A@@ -102,7 +121,7 @@ static void check_update_timer(RTCState =
=0A         guest_usec =3D get_localtime_us(d) % USEC_PER_SEC;=0A         =
if (guest_usec >=3D (USEC_PER_SEC - 244))=0A         {=0A-            /* =
RTC is in update cycle when enabling UIE */=0A+            /* RTC is in =
update cycle */=0A             s->hw.cmos_data[RTC_REG_A] |=3D RTC_UIP;=0A =
            next_update_time =3D (USEC_PER_SEC - guest_usec) * NS_PER_USEC;=
=0A             expire_time =3D NOW() + next_update_time;=0A@@ -144,7 =
+163,6 @@ static void rtc_update_timer(void *opaqu=0A static void =
rtc_update_timer2(void *opaque)=0A {=0A     RTCState *s =3D opaque;=0A-    =
struct domain *d =3D vrtc_domain(s);=0A =0A     spin_lock(&s->lock);=0A    =
 if (!(s->hw.cmos_data[RTC_REG_B] & RTC_SET))=0A@@ -152,11 +170,7 @@ =
static void rtc_update_timer2(void *opaq=0A         s->hw.cmos_data[RTC_REG=
_C] |=3D RTC_UF;=0A         s->hw.cmos_data[RTC_REG_A] &=3D ~RTC_UIP;=0A   =
      if ((s->hw.cmos_data[RTC_REG_B] & RTC_UIE))=0A-        {=0A-         =
   s->hw.cmos_data[RTC_REG_C] |=3D RTC_IRQF;=0A-            hvm_isa_irq_dea=
ssert(d, RTC_IRQ);=0A-            hvm_isa_irq_assert(d, RTC_IRQ);=0A-      =
  }=0A+            rtc_toggle_irq(s);=0A         check_update_timer(s);=0A =
    }=0A     spin_unlock(&s->lock);=0A@@ -175,21 +189,18 @@ static void =
alarm_timer_update(RTCState =0A =0A     stop_timer(&s->alarm_timer);=0A =
=0A-    if ((s->hw.cmos_data[RTC_REG_B] & RTC_AIE) &&=0A-            =
!(s->hw.cmos_data[RTC_REG_B] & RTC_SET))=0A+    if ( !(s->hw.cmos_data[RTC_=
REG_B] & RTC_SET) )=0A     {=0A         s->current_tm =3D gmtime(get_localt=
ime(d));=0A         rtc_copy_date(s);=0A =0A         alarm_sec =3D =
from_bcd(s, s->hw.cmos_data[RTC_SECONDS_ALARM]);=0A         alarm_min =3D =
from_bcd(s, s->hw.cmos_data[RTC_MINUTES_ALARM]);=0A-        alarm_hour =3D =
from_bcd(s, s->hw.cmos_data[RTC_HOURS_ALARM]);=0A-        alarm_hour =3D =
convert_hour(s, alarm_hour);=0A+        alarm_hour =3D convert_hour(s, =
s->hw.cmos_data[RTC_HOURS_ALARM]);=0A =0A         cur_sec =3D from_bcd(s, =
s->hw.cmos_data[RTC_SECONDS]);=0A         cur_min =3D from_bcd(s, =
s->hw.cmos_data[RTC_MINUTES]);=0A-        cur_hour =3D from_bcd(s, =
s->hw.cmos_data[RTC_HOURS]);=0A-        cur_hour =3D convert_hour(s, =
cur_hour);=0A+        cur_hour =3D convert_hour(s, s->hw.cmos_data[RTC_HOUR=
S]);=0A =0A         next_update_time =3D USEC_PER_SEC - (get_localtime_us(d=
) % USEC_PER_SEC);=0A         next_update_time =3D next_update_time * =
NS_PER_USEC + NOW();=0A@@ -343,7 +354,6 @@ static void alarm_timer_update(R=
TCState =0A static void rtc_alarm_cb(void *opaque)=0A {=0A     RTCState *s =
=3D opaque;=0A-    struct domain *d =3D vrtc_domain(s);=0A =0A     =
spin_lock(&s->lock);=0A     if (!(s->hw.cmos_data[RTC_REG_B] & RTC_SET))=0A=
@@ -351,11 +361,7 @@ static void rtc_alarm_cb(void *opaque)=0A         =
s->hw.cmos_data[RTC_REG_C] |=3D RTC_AF;=0A         /* alarm interrupt =
*/=0A         if (s->hw.cmos_data[RTC_REG_B] & RTC_AIE)=0A-        {=0A-   =
         s->hw.cmos_data[RTC_REG_C] |=3D RTC_IRQF;=0A-            =
hvm_isa_irq_deassert(d, RTC_IRQ);=0A-            hvm_isa_irq_assert(d, =
RTC_IRQ);=0A-        }=0A+            rtc_toggle_irq(s);=0A         =
alarm_timer_update(s);=0A     }=0A     spin_unlock(&s->lock);=0A@@ -365,7 =
+371,7 @@ static int rtc_ioport_write(void *opaque=0A {=0A     RTCState *s =
=3D opaque;=0A     struct domain *d =3D vrtc_domain(s);=0A-    uint32_t =
orig;=0A+    uint32_t orig, mask;=0A =0A     spin_lock(&s->lock);=0A =0A@@ =
-417,7 +423,7 @@ static int rtc_ioport_write(void *opaque=0A             =
/* set mode: reset UIP mode */=0A             s->hw.cmos_data[RTC_REG_A] =
&=3D ~RTC_UIP;=0A             /* adjust cmos before stopping */=0A-        =
    if (!(s->hw.cmos_data[RTC_REG_B] & RTC_SET))=0A+            if (!(orig =
& RTC_SET))=0A             {=0A                 s->current_tm =3D =
gmtime(get_localtime(d));=0A                 rtc_copy_date(s);=0A@@ =
-426,22 +432,26 @@ static int rtc_ioport_write(void *opaque=0A         =
else=0A         {=0A             /* if disabling set mode, update the time =
*/=0A-            if ( s->hw.cmos_data[RTC_REG_B] & RTC_SET )=0A+          =
  if ( orig & RTC_SET )=0A                 rtc_set_time(s);=0A         =
}=0A-        /* if the interrupt is already set when the interrupt =
become=0A-         * enabled, raise an interrupt immediately*/=0A-        =
if ((data & RTC_UIE) && !(s->hw.cmos_data[RTC_REG_B] & RTC_UIE))=0A-       =
     if (s->hw.cmos_data[RTC_REG_C] & RTC_UF)=0A+        /*=0A+         * =
If the interrupt is already set when the interrupt becomes=0A+         * =
enabled, raise an interrupt immediately.=0A+         * NB: RTC_{A,P,U}IE =
=3D=3D RTC_{A,P,U}F respectively.=0A+         */=0A+        for ( mask =3D =
RTC_UIE; mask <=3D RTC_PIE; mask <<=3D 1 )=0A+            if ( (data & =
mask) && !(orig & mask) &&=0A+                 (s->hw.cmos_data[RTC_REG_C] =
& mask) )=0A             {=0A-                hvm_isa_irq_deassert(d, =
RTC_IRQ);=0A-                hvm_isa_irq_assert(d, RTC_IRQ);=0A+           =
     rtc_toggle_irq(s);=0A+                break;=0A             }=0A      =
   s->hw.cmos_data[RTC_REG_B] =3D data;=0A-        if ( (data ^ orig) & =
RTC_PIE )=0A-            rtc_timer_update(s);=0A-        check_update_timer=
(s);=0A-        alarm_timer_update(s);=0A+        if ( (data ^ orig) & =
RTC_SET )=0A+            check_update_timer(s);=0A+        if ( (data ^ =
orig) & (RTC_24H | RTC_DM_BINARY | RTC_SET) )=0A+            alarm_timer_up=
date(s);=0A         break;=0A     case RTC_REG_C:=0A     case RTC_REG_D:=0A=
@@ -456,7 +466,7 @@ static int rtc_ioport_write(void *opaque=0A =0A static =
inline int to_bcd(RTCState *s, int a)=0A {=0A-    if ( s->hw.cmos_data[RTC_=
REG_B] & 0x04 )=0A+    if ( s->hw.cmos_data[RTC_REG_B] & RTC_DM_BINARY =
)=0A         return a;=0A     else=0A         return ((a / 10) << 4) | (a =
% 10);=0A@@ -464,7 +474,7 @@ static inline int to_bcd(RTCState *s, in=0A =
=0A static inline int from_bcd(RTCState *s, int a)=0A {=0A-    if ( =
s->hw.cmos_data[RTC_REG_B] & 0x04 )=0A+    if ( s->hw.cmos_data[RTC_REG_B] =
& RTC_DM_BINARY )=0A         return a;=0A     else=0A         return ((a =
>> 4) * 10) + (a & 0x0f);=0A@@ -472,12 +482,14 @@ static inline int =
from_bcd(RTCState *s, =0A =0A /* Hours in 12 hour mode are in 1-12 range, =
not 0-11.=0A  * So we need convert it before using it*/=0A-static inline =
int convert_hour(RTCState *s, int hour)=0A+static inline int convert_hour(R=
TCState *s, int raw)=0A {=0A+    int hour =3D from_bcd(s, raw & 0x7f);=0A+=
=0A     if (!(s->hw.cmos_data[RTC_REG_B] & RTC_24H))=0A     {=0A         =
hour %=3D 12;=0A-        if (s->hw.cmos_data[RTC_HOURS] & 0x80)=0A+        =
if (raw & 0x80)=0A             hour +=3D 12;=0A     }=0A     return =
hour;=0A@@ -496,8 +508,7 @@ static void rtc_set_time(RTCState *s)=0A     =
=0A     tm->tm_sec =3D from_bcd(s, s->hw.cmos_data[RTC_SECONDS]);=0A     =
tm->tm_min =3D from_bcd(s, s->hw.cmos_data[RTC_MINUTES]);=0A-    tm->tm_hou=
r =3D from_bcd(s, s->hw.cmos_data[RTC_HOURS] & 0x7f);=0A-    tm->tm_hour =
=3D convert_hour(s, tm->tm_hour);=0A+    tm->tm_hour =3D convert_hour(s, =
s->hw.cmos_data[RTC_HOURS]);=0A     tm->tm_wday =3D from_bcd(s, s->hw.cmos_=
data[RTC_DAY_OF_WEEK]);=0A     tm->tm_mday =3D from_bcd(s, s->hw.cmos_data[=
RTC_DAY_OF_MONTH]);=0A     tm->tm_mon =3D from_bcd(s, s->hw.cmos_data[RTC_M=
ONTH]) - 1;=0A--- a/xen/arch/x86/hvm/vpt.c=0A+++ b/xen/arch/x86/hvm/vpt.c=
=0A@@ -22,6 +22,7 @@=0A #include <asm/hvm/vpt.h>=0A #include <asm/event.h>=
=0A #include <asm/apic.h>=0A+#include <asm/mc146818rtc.h>=0A =0A #define =
mode_is(d, name) \=0A     ((d)->arch.hvm_domain.params[HVM_PARAM_TIMER_MODE=
] =3D=3D HVMPTM_##name)=0A@@ -218,6 +219,7 @@ void pt_update_irq(struct =
vcpu *v)=0A     struct periodic_time *pt, *temp, *earliest_pt =3D NULL;=0A =
    uint64_t max_lag =3D -1ULL;=0A     int irq, is_lapic;=0A+    void =
*pt_priv;=0A =0A     spin_lock(&v->arch.hvm_vcpu.tm_lock);=0A =0A@@ =
-251,13 +253,14 @@ void pt_update_irq(struct vcpu *v)=0A     earliest_pt->i=
rq_issued =3D 1;=0A     irq =3D earliest_pt->irq;=0A     is_lapic =3D =
(earliest_pt->source =3D=3D PTSRC_lapic);=0A+    pt_priv =3D earliest_pt->p=
riv;=0A =0A     spin_unlock(&v->arch.hvm_vcpu.tm_lock);=0A =0A     if ( =
is_lapic )=0A-    {=0A         vlapic_set_irq(vcpu_vlapic(v), irq, 0);=0A- =
   }=0A+    else if ( irq =3D=3D RTC_IRQ && pt_priv )=0A+        rtc_period=
ic_interrupt(pt_priv);=0A     else=0A     {=0A         hvm_isa_irq_deassert=
(v->domain, irq);=0A--- a/xen/include/asm-x86/hvm/vpt.h=0A+++ b/xen/include=
/asm-x86/hvm/vpt.h=0A@@ -181,6 +181,7 @@ void rtc_migrate_timers(struct =
vcpu *v);=0A void rtc_deinit(struct domain *d);=0A void rtc_reset(struct =
domain *d);=0A void rtc_update_clock(struct domain *d);=0A+void rtc_periodi=
c_interrupt(void *);=0A =0A void pmtimer_init(struct vcpu *v);=0A void =
pmtimer_deinit(struct domain *d);=0A
--=__PartB382A732.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

--=__PartB382A732.0__=--


From xen-devel-bounces@lists.xen.org Fri Sep 07 13:05:50 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Sep 2012 13: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 1T9yFd-0005Di-Gy; Fri, 07 Sep 2012 13:05: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 1T9yFb-0005Dd-Vj
	for xen-devel@lists.xen.org; Fri, 07 Sep 2012 13:05:36 +0000
Received: from [85.158.143.99:11556] by server-1.bemta-4.messagelabs.com id
	E4/7E-12504-F11F9405; Fri, 07 Sep 2012 13:05:35 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1347023132!19362079!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNjk1ODQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18136 invoked from network); 7 Sep 2012 13:05:33 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-8.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Sep 2012 13:05:33 -0000
X-IronPort-AV: E=Sophos;i="4.80,385,1344211200"; d="scan'208";a="37113172"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Sep 2012 13:05:20 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Fri, 7 Sep 2012 09:05:19 -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 1T9yFL-0005KJ-Hg;
	Fri, 07 Sep 2012 14:05:19 +0100
Message-ID: <5049F10F.5010801@citrix.com>
Date: Fri, 7 Sep 2012 14:05:19 +0100
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:14.0) Gecko/20120714 Thunderbird/14.0
MIME-Version: 1.0
To: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>, Keir Fraser
	<keir@xen.org>, Jan Beulich <jbeulich@suse.com>
X-Enigmail-Version: 1.4.4
Content-Type: multipart/mixed; boundary="------------010804020906090301080001"
Subject: [Xen-devel] [PATCH] kexec/noreboot: Don't kexec_crash() if noreboot
 has been requested.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--------------010804020906090301080001
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit

This issue came up when debugging pcpu linked list corruption (patches
for that issue to follow).

-- 
Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
T: +44 (0)1223 225 900, http://www.citrix.com


--------------010804020906090301080001
Content-Type: text/x-patch; name="noreboot.patch"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="noreboot.patch"

# HG changeset patch
# Parent 1126b3079bef37e1bb5a97b90c14a51d4e1c91c3
kexec/noreboot: Don't kexec_crash() if noreboot has been requested.

The noreboot option is for debugging, to be able to see the dying output.  To
that end, continuing and possibly booting into the crash kernel defeats one of
the purposes of noreboot.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>

diff -r 1126b3079bef xen/drivers/char/console.c
--- a/xen/drivers/char/console.c
+++ b/xen/drivers/char/console.c
@@ -963,16 +963,15 @@ void panic(const char *fmt, ...)
 
     debugger_trap_immediate();
 
-#ifdef CONFIG_KEXEC
-    kexec_crash();
-#endif
-
     if ( opt_noreboot )
     {
         machine_halt();
     }
     else
     {
+#ifdef CONFIG_KEXEC
+        kexec_crash();
+#endif
         watchdog_disable();
         machine_restart(5000);
     }

--------------010804020906090301080001
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--------------010804020906090301080001--


From xen-devel-bounces@lists.xen.org Fri Sep 07 13:05:50 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Sep 2012 13: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 1T9yFd-0005Di-Gy; Fri, 07 Sep 2012 13:05: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 1T9yFb-0005Dd-Vj
	for xen-devel@lists.xen.org; Fri, 07 Sep 2012 13:05:36 +0000
Received: from [85.158.143.99:11556] by server-1.bemta-4.messagelabs.com id
	E4/7E-12504-F11F9405; Fri, 07 Sep 2012 13:05:35 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1347023132!19362079!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNjk1ODQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18136 invoked from network); 7 Sep 2012 13:05:33 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-8.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Sep 2012 13:05:33 -0000
X-IronPort-AV: E=Sophos;i="4.80,385,1344211200"; d="scan'208";a="37113172"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Sep 2012 13:05:20 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Fri, 7 Sep 2012 09:05:19 -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 1T9yFL-0005KJ-Hg;
	Fri, 07 Sep 2012 14:05:19 +0100
Message-ID: <5049F10F.5010801@citrix.com>
Date: Fri, 7 Sep 2012 14:05:19 +0100
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:14.0) Gecko/20120714 Thunderbird/14.0
MIME-Version: 1.0
To: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>, Keir Fraser
	<keir@xen.org>, Jan Beulich <jbeulich@suse.com>
X-Enigmail-Version: 1.4.4
Content-Type: multipart/mixed; boundary="------------010804020906090301080001"
Subject: [Xen-devel] [PATCH] kexec/noreboot: Don't kexec_crash() if noreboot
 has been requested.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--------------010804020906090301080001
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit

This issue came up when debugging pcpu linked list corruption (patches
for that issue to follow).

-- 
Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
T: +44 (0)1223 225 900, http://www.citrix.com


--------------010804020906090301080001
Content-Type: text/x-patch; name="noreboot.patch"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="noreboot.patch"

# HG changeset patch
# Parent 1126b3079bef37e1bb5a97b90c14a51d4e1c91c3
kexec/noreboot: Don't kexec_crash() if noreboot has been requested.

The noreboot option is for debugging, to be able to see the dying output.  To
that end, continuing and possibly booting into the crash kernel defeats one of
the purposes of noreboot.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>

diff -r 1126b3079bef xen/drivers/char/console.c
--- a/xen/drivers/char/console.c
+++ b/xen/drivers/char/console.c
@@ -963,16 +963,15 @@ void panic(const char *fmt, ...)
 
     debugger_trap_immediate();
 
-#ifdef CONFIG_KEXEC
-    kexec_crash();
-#endif
-
     if ( opt_noreboot )
     {
         machine_halt();
     }
     else
     {
+#ifdef CONFIG_KEXEC
+        kexec_crash();
+#endif
         watchdog_disable();
         machine_restart(5000);
     }

--------------010804020906090301080001
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--------------010804020906090301080001--


From xen-devel-bounces@lists.xen.org Fri Sep 07 13:05:54 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Sep 2012 13:05: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 1T9yFl-0005El-3E; Fri, 07 Sep 2012 13:05: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 1T9yFj-0005Ea-U6
	for xen-devel@lists.xen.org; Fri, 07 Sep 2012 13:05:44 +0000
Received: from [85.158.143.99:62476] by server-1.bemta-4.messagelabs.com id
	3B/BE-12504-721F9405; Fri, 07 Sep 2012 13:05:43 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1347023136!23798358!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM4ODU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6640 invoked from network); 7 Sep 2012 13:05:37 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-2.tower-216.messagelabs.com with SMTP;
	7 Sep 2012 13:05:37 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 07 Sep 2012 14:05:36 +0100
Message-Id: <504A0D760200007800099CEE@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 07 Sep 2012 14:06:30 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Keir Fraser" <keir@xen.org>
References: <504A071B0200007800099C8C@nat28.tlf.novell.com>
	<CC6FAA42.4AF4C%keir@xen.org>
In-Reply-To: <CC6FAA42.4AF4C%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] [PATCH,
 resend] x86/32-on-64: adjust Dom0 initial page table layout
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 07.09.12 at 14:42, Keir Fraser <keir@xen.org> wrote:
> On 07/09/2012 13:39, "Jan Beulich" <JBeulich@suse.com> wrote:
> 
>> Drop the unnecessary reservation of the L4 page for 32on64 Dom0, and
>> allocate its L3 first (to match behavior when running identical bit-
>> width hypervisor and Dom0 kernel).
>> 
>> Reported-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> 
> Acked-by: Keir Fraser <keir@xen.org>
> 
> Not for 4.2.0.

Of course, that's why we held it back. I think that ought to be
the default until the release, and we want to explicitly name the
ones we want ported over.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 07 13:05:54 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Sep 2012 13:05: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 1T9yFl-0005El-3E; Fri, 07 Sep 2012 13:05: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 1T9yFj-0005Ea-U6
	for xen-devel@lists.xen.org; Fri, 07 Sep 2012 13:05:44 +0000
Received: from [85.158.143.99:62476] by server-1.bemta-4.messagelabs.com id
	3B/BE-12504-721F9405; Fri, 07 Sep 2012 13:05:43 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1347023136!23798358!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM4ODU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6640 invoked from network); 7 Sep 2012 13:05:37 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-2.tower-216.messagelabs.com with SMTP;
	7 Sep 2012 13:05:37 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 07 Sep 2012 14:05:36 +0100
Message-Id: <504A0D760200007800099CEE@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 07 Sep 2012 14:06:30 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Keir Fraser" <keir@xen.org>
References: <504A071B0200007800099C8C@nat28.tlf.novell.com>
	<CC6FAA42.4AF4C%keir@xen.org>
In-Reply-To: <CC6FAA42.4AF4C%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] [PATCH,
 resend] x86/32-on-64: adjust Dom0 initial page table layout
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 07.09.12 at 14:42, Keir Fraser <keir@xen.org> wrote:
> On 07/09/2012 13:39, "Jan Beulich" <JBeulich@suse.com> wrote:
> 
>> Drop the unnecessary reservation of the L4 page for 32on64 Dom0, and
>> allocate its L3 first (to match behavior when running identical bit-
>> width hypervisor and Dom0 kernel).
>> 
>> Reported-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> 
> Acked-by: Keir Fraser <keir@xen.org>
> 
> Not for 4.2.0.

Of course, that's why we held it back. I think that ought to be
the default until the release, and we want to explicitly name the
ones we want ported over.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 07 13:16:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Sep 2012 13:16:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9yPZ-0005hO-8I; Fri, 07 Sep 2012 13:15: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 1T9yPY-0005hJ-Op
	for xen-devel@lists.xen.org; Fri, 07 Sep 2012 13:15:52 +0000
Received: from [85.158.143.35:41118] by server-2.bemta-4.messagelabs.com id
	BE/60-21239-883F9405; Fri, 07 Sep 2012 13:15:52 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1347023747!13902054!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM4ODU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28333 invoked from network); 7 Sep 2012 13:15:51 -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;
	7 Sep 2012 13:15:51 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 07 Sep 2012 14:15:46 +0100
Message-Id: <504A0FDA0200007800099D10@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 07 Sep 2012 14:16:42 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Andrew Cooper" <andrew.cooper3@citrix.com>
References: <5049F10F.5010801@citrix.com>
In-Reply-To: <5049F10F.5010801@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Keir Fraser <keir@xen.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] kexec/noreboot: Don't kexec_crash() if
 noreboot has been requested.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.09.12 at 15:05, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
> This issue came up when debugging pcpu linked list corruption (patches
> for that issue to follow).

Hmm, that's a matter of taste of course. Nor is running kdump
really a (direct) reboot action. Both ways have their reasoning
imo, so I'm not sure whether keeping things as is or applying the
patch is the better thing.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 07 13:16:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Sep 2012 13:16:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9yPZ-0005hO-8I; Fri, 07 Sep 2012 13:15: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 1T9yPY-0005hJ-Op
	for xen-devel@lists.xen.org; Fri, 07 Sep 2012 13:15:52 +0000
Received: from [85.158.143.35:41118] by server-2.bemta-4.messagelabs.com id
	BE/60-21239-883F9405; Fri, 07 Sep 2012 13:15:52 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1347023747!13902054!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM4ODU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28333 invoked from network); 7 Sep 2012 13:15:51 -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;
	7 Sep 2012 13:15:51 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 07 Sep 2012 14:15:46 +0100
Message-Id: <504A0FDA0200007800099D10@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 07 Sep 2012 14:16:42 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Andrew Cooper" <andrew.cooper3@citrix.com>
References: <5049F10F.5010801@citrix.com>
In-Reply-To: <5049F10F.5010801@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Keir Fraser <keir@xen.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] kexec/noreboot: Don't kexec_crash() if
 noreboot has been requested.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.09.12 at 15:05, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
> This issue came up when debugging pcpu linked list corruption (patches
> for that issue to follow).

Hmm, that's a matter of taste of course. Nor is running kdump
really a (direct) reboot action. Both ways have their reasoning
imo, so I'm not sure whether keeping things as is or applying the
patch is the better thing.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 07 13:22:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Sep 2012 13:22:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9yVS-0005uu-9s; Fri, 07 Sep 2012 13:21:58 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <stefan.bader@canonical.com>) id 1T9yVQ-0005up-H5
	for xen-devel@lists.xen.org; Fri, 07 Sep 2012 13:21:56 +0000
Received: from [85.158.143.99:2736] by server-2.bemta-4.messagelabs.com id
	ED/8B-21239-2F4F9405; Fri, 07 Sep 2012 13:21:54 +0000
X-Env-Sender: stefan.bader@canonical.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1347024113!19365353!1
X-Originating-IP: [91.189.89.112]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1733 invoked from network); 7 Sep 2012 13:21:53 -0000
Received: from youngberry.canonical.com (HELO youngberry.canonical.com)
	(91.189.89.112) by server-8.tower-216.messagelabs.com with SMTP;
	7 Sep 2012 13:21:53 -0000
Received: from p5b2e2384.dip.t-dialin.net ([91.46.35.132] 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 1T9yVG-0002hv-V4; Fri, 07 Sep 2012 13:21:47 +0000
Message-ID: <5049F4E9.9050306@canonical.com>
Date: Fri, 07 Sep 2012 15:21:45 +0200
From: Stefan Bader <stefan.bader@canonical.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120827 Thunderbird/15.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <1347018043-21252-1-git-send-email-stefan.bader@canonical.com>
	<504A05B00200007800099C7B@nat28.tlf.novell.com>
In-Reply-To: <504A05B00200007800099C7B@nat28.tlf.novell.com>
X-Enigmail-Version: 1.4.4
Cc: xen-devel@lists.xen.org,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Matt Wilson <msw@amazon.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH/RFC] Fix xsave bug on older Xen hypervisors
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============5660692614958532387=="
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)
--===============5660692614958532387==
Content-Type: multipart/signed; micalg=pgp-sha512;
 protocol="application/pgp-signature";
 boundary="------------enigFEC341DE9F4CC3FEA7524E82"

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigFEC341DE9F4CC3FEA7524E82
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On 07.09.2012 14:33, Jan Beulich wrote:
>>>> On 07.09.12 at 13:40, Stefan Bader <stefan.bader@canonical.com> wrot=
e:
>> When writing unsupported flags into CR4 (for some time the
>> xen_write_cr4 function would refuse to do anything at all)
>> older Xen hypervisors (and patch can potentially be improved
>> by finding out what older means in version numbers) would
>> crash the guest.
>>
>> Since Amazon EC2 would at least in the past be affected by that,
>> Fedora and Ubuntu were carrying a hack that would filter out
>> X86_CR4_OSXSAVE before writing to CR4. This would affect any
>> PV guest, even those running on a newer HV.
>>
>> And this recently caused trouble because some user-space was
>> only partially checking (or maybe only looking at the cpuid
>> bits) and then trying to use xsave even though the OS support
>> was not set.
>>
>> So I came up with a patch that would
>> - limit the work-around to certain Xen versions
>> - prevent the write to CR4 by unsetting xsave and osxsave in
>>   the cpuid bits
>>
>> Doing things that way may actually allow this to be acceptable
>> upstream, so I am sending it around, now.
>> It probably could be improved when knowing the exact version
>> to test for but otherwise should allow to work around the guest
>> crash while not preventing xsave on Xen 4.x and newer hosts.
>=20
> Before considering a hack like this, I'd really like to see evidence
> of the described behavior with an upstream kernel (i.e. not one
> with that known broken hack patched in, which has never been
> upstream afaict).

This is the reason I wrote that Fedora and Ubuntu were carrying it. It ne=
ver has
been send upstream (the other version) because it would filter the CR4 wr=
ite for
any PV guest regardless of host version.

Gathering the evidence is a bit of a problem: First you need a host which=
 has
the xsave support, then that has to run the affected Xen version (which I=
 do not
know) and lastly run a PV guest kernel trying to write OSXSAVE into CR4
(probably 2.6.28 onwards, we were facing those random early crashes with =
2.6.32
on EC2 in some cases).

-Stefan

>=20
> Jan
>=20
>> From dff8885934d4e1274a69c4cedd28a4d18a1255e8 Mon Sep 17 00:00:00 2001=

>> From: Stefan Bader <stefan.bader@canonical.com>
>> Date: Fri, 15 Jun 2012 11:54:59 +0200
>> Subject: [PATCH] xen: Mask xsave cpu capability on Xen host < 4
>>
>> Older Xen hypervisors (like RHEL5 versions found to be used
>> on Amazon's EC2) did have a bug which would crash the domain
>> when trying to write unsupported CR4 values.
>> Newer versions of the Xen hypervisor do handle this correctly.
>> But when a 2.6.28 or later kernel (those seem to have
>> xen_write_cr4 and xsave support) is booted as a PV guest on EC2,
>> it potentially crashes when hitting the right CPU and the wrong
>> hypervisor.
>>
>> We were using a patch (taken from Fedora) that did always filter
>> the OSXSAVE off the values written to CR4 when running as Xen PV
>> guest. While not completely wrong this creates an inconsistency
>> between the cpuid bits a guest sees and the CR4 settings.
>> But it prevents any use of xsave even on recent Xen hypervisors.
>> And this did recently cause problems because user-space was not
>> testing all bits when deciding to use certain features.
>>
>> This patch will actually mask off the cpuid bits for XSAVE and
>> OSXSAVE, so generic code will not even try to set CR4. It is
>> limited to PV guests and (since we do not actually know the
>> exact version) Xen hypervisors before version 4.
>>
>> Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
>> ---
>>  arch/x86/xen/enlighten.c |   17 ++++++++++++++++-
>>  1 file changed, 16 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
>> index 9642d4a..4241055 100644
>> --- a/arch/x86/xen/enlighten.c
>> +++ b/arch/x86/xen/enlighten.c
>> @@ -210,6 +210,18 @@ void xen_vcpu_restore(void)
>>  	}
>>  }
>> =20
>> +/*
>> + * Older (with no clear statement about what old means) Xen hyperviso=
rs
>> + * will crash a PV guest that tries to store OSXSAVE into CR4.
>> + * To prevent this, we force the feature bits related to this off in =
the
>> + * xen cpuid call. This inline function serves as a centralized test
>> + * on whether the quirk should be done.
>> + */
>> +static inline needs_xsave_quirk(unsigned version)
>> +{
>> +	return (xen_pv_domain() && ((version >> 16) < 4)) ? 1 : 0;
>> +}
>> +
>>  static void __init xen_banner(void)
>>  {
>>  	unsigned version =3D HYPERVISOR_xen_version(XENVER_version, NULL);
>> @@ -221,6 +233,8 @@ static void __init xen_banner(void)
>>  	printk(KERN_INFO "Xen version: %d.%d%s%s\n",
>>  	       version >> 16, version & 0xffff, extra.extraversion,
>>  	       xen_feature(XENFEAT_mmu_pt_update_preserve_ad) ? " (preserve-=
AD)" :=20
>> "");
>> +	if (needs_xsave_quirk(version))
>> +		printk(KERN_INFO "Forcing xsave off due to Xen version.\n");
>>  }
>> =20
>>  #define CPUID_THERM_POWER_LEAF 6
>> @@ -351,6 +365,7 @@ static bool __init xen_check_mwait(void)
>>  }
>>  static void __init xen_init_cpuid_mask(void)
>>  {
>> +	unsigned version =3D HYPERVISOR_xen_version(XENVER_version, NULL);
>>  	unsigned int ax, bx, cx, dx;
>>  	unsigned int xsave_mask;
>> =20
>> @@ -371,7 +386,7 @@ static void __init xen_init_cpuid_mask(void)
>>  		(1 << (X86_FEATURE_OSXSAVE % 32));
>> =20
>>  	/* Xen will set CR4.OSXSAVE if supported and not disabled by force *=
/
>> -	if ((cx & xsave_mask) !=3D xsave_mask)
>> +	if (((cx & xsave_mask) !=3D xsave_mask) || needs_xsave_quirk(version=
))
>>  		cpuid_leaf1_ecx_mask &=3D ~xsave_mask; /* disable XSAVE & OSXSAVE *=
/
>>  	if (xen_check_mwait())
>>  		cpuid_leaf1_ecx_set_mask =3D (1 << (X86_FEATURE_MWAIT % 32));
>> --=20
>> 1.7.9.5
>>
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xen.org=20
>> http://lists.xen.org/xen-devel=20
>=20
>=20
>=20
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
>=20



--------------enigFEC341DE9F4CC3FEA7524E82
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://www.enigmail.net/

iQIcBAEBCgAGBQJQSfTpAAoJEOhnXe7L7s6jEdkP/0/UK0Ybd9uHcfShLGFtAsxP
veyXp3Ac2AQpneuevLZGDLjlkRzn14O2bbB5TewrF+2sSUWz5tOC0tsoS9V2ZVNC
PCfAGMptjNPbVK1S3e9nMuEz0qOeL02cW6rv0nupkmA76gFMcNdTwDq5wpxkA2cC
CzWiIk3pJ6fGo/gQfOu+4rzAO+VlZY8TZP0zyAc09oZhoJuAxyh2Iw5/4I/Fi0d9
DYtI5rhNhKRia6YcuAP7jUlk5T6+j6gcGT2ewdbu+03YMjuLaDFuWaTfMx1iAre4
yF3BnZKKf6D+y+N2vtgpA6XGuwUwWLrxY6do073J0Rr8kOi3m5SD0V/gxGFe+qz+
gIjC6IPIp0Gqbr+4icqa/hSF++YUnsitvOFXMAi1y+ox2AUQcO6N1SSwIVvfmGBO
ytwT4EQ9P7GCr1L6HnAoZys+vP6OrtiirJhj0yw1Zxk0Ae/y1vqutButGzey7eFa
RiSkVJgZ0kDDTs4fBKNMxXj1ZRByrerb/8Ih14flL9wK3ILbROYhq/Dt9Ebr0xGp
OXnlXicWyWu2qHECoPdGMrowRlVpYzOLoB3HX56Lm7x5FbPbFX1BdYr0pEabKNgg
Z4vNyyo3LlOVUlDvEz/6POV62yeKRDaJKUuQf8BbvsUEvO6jiczAYPcLvSzdfCtG
O8alNGMm9R7ngXLFdVOA
=wXZf
-----END PGP SIGNATURE-----

--------------enigFEC341DE9F4CC3FEA7524E82--


--===============5660692614958532387==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============5660692614958532387==--


From xen-devel-bounces@lists.xen.org Fri Sep 07 13:22:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Sep 2012 13:22:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9yVS-0005uu-9s; Fri, 07 Sep 2012 13:21:58 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <stefan.bader@canonical.com>) id 1T9yVQ-0005up-H5
	for xen-devel@lists.xen.org; Fri, 07 Sep 2012 13:21:56 +0000
Received: from [85.158.143.99:2736] by server-2.bemta-4.messagelabs.com id
	ED/8B-21239-2F4F9405; Fri, 07 Sep 2012 13:21:54 +0000
X-Env-Sender: stefan.bader@canonical.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1347024113!19365353!1
X-Originating-IP: [91.189.89.112]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1733 invoked from network); 7 Sep 2012 13:21:53 -0000
Received: from youngberry.canonical.com (HELO youngberry.canonical.com)
	(91.189.89.112) by server-8.tower-216.messagelabs.com with SMTP;
	7 Sep 2012 13:21:53 -0000
Received: from p5b2e2384.dip.t-dialin.net ([91.46.35.132] 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 1T9yVG-0002hv-V4; Fri, 07 Sep 2012 13:21:47 +0000
Message-ID: <5049F4E9.9050306@canonical.com>
Date: Fri, 07 Sep 2012 15:21:45 +0200
From: Stefan Bader <stefan.bader@canonical.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120827 Thunderbird/15.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <1347018043-21252-1-git-send-email-stefan.bader@canonical.com>
	<504A05B00200007800099C7B@nat28.tlf.novell.com>
In-Reply-To: <504A05B00200007800099C7B@nat28.tlf.novell.com>
X-Enigmail-Version: 1.4.4
Cc: xen-devel@lists.xen.org,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Matt Wilson <msw@amazon.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH/RFC] Fix xsave bug on older Xen hypervisors
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============5660692614958532387=="
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)
--===============5660692614958532387==
Content-Type: multipart/signed; micalg=pgp-sha512;
 protocol="application/pgp-signature";
 boundary="------------enigFEC341DE9F4CC3FEA7524E82"

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigFEC341DE9F4CC3FEA7524E82
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On 07.09.2012 14:33, Jan Beulich wrote:
>>>> On 07.09.12 at 13:40, Stefan Bader <stefan.bader@canonical.com> wrot=
e:
>> When writing unsupported flags into CR4 (for some time the
>> xen_write_cr4 function would refuse to do anything at all)
>> older Xen hypervisors (and patch can potentially be improved
>> by finding out what older means in version numbers) would
>> crash the guest.
>>
>> Since Amazon EC2 would at least in the past be affected by that,
>> Fedora and Ubuntu were carrying a hack that would filter out
>> X86_CR4_OSXSAVE before writing to CR4. This would affect any
>> PV guest, even those running on a newer HV.
>>
>> And this recently caused trouble because some user-space was
>> only partially checking (or maybe only looking at the cpuid
>> bits) and then trying to use xsave even though the OS support
>> was not set.
>>
>> So I came up with a patch that would
>> - limit the work-around to certain Xen versions
>> - prevent the write to CR4 by unsetting xsave and osxsave in
>>   the cpuid bits
>>
>> Doing things that way may actually allow this to be acceptable
>> upstream, so I am sending it around, now.
>> It probably could be improved when knowing the exact version
>> to test for but otherwise should allow to work around the guest
>> crash while not preventing xsave on Xen 4.x and newer hosts.
>=20
> Before considering a hack like this, I'd really like to see evidence
> of the described behavior with an upstream kernel (i.e. not one
> with that known broken hack patched in, which has never been
> upstream afaict).

This is the reason I wrote that Fedora and Ubuntu were carrying it. It ne=
ver has
been send upstream (the other version) because it would filter the CR4 wr=
ite for
any PV guest regardless of host version.

Gathering the evidence is a bit of a problem: First you need a host which=
 has
the xsave support, then that has to run the affected Xen version (which I=
 do not
know) and lastly run a PV guest kernel trying to write OSXSAVE into CR4
(probably 2.6.28 onwards, we were facing those random early crashes with =
2.6.32
on EC2 in some cases).

-Stefan

>=20
> Jan
>=20
>> From dff8885934d4e1274a69c4cedd28a4d18a1255e8 Mon Sep 17 00:00:00 2001=

>> From: Stefan Bader <stefan.bader@canonical.com>
>> Date: Fri, 15 Jun 2012 11:54:59 +0200
>> Subject: [PATCH] xen: Mask xsave cpu capability on Xen host < 4
>>
>> Older Xen hypervisors (like RHEL5 versions found to be used
>> on Amazon's EC2) did have a bug which would crash the domain
>> when trying to write unsupported CR4 values.
>> Newer versions of the Xen hypervisor do handle this correctly.
>> But when a 2.6.28 or later kernel (those seem to have
>> xen_write_cr4 and xsave support) is booted as a PV guest on EC2,
>> it potentially crashes when hitting the right CPU and the wrong
>> hypervisor.
>>
>> We were using a patch (taken from Fedora) that did always filter
>> the OSXSAVE off the values written to CR4 when running as Xen PV
>> guest. While not completely wrong this creates an inconsistency
>> between the cpuid bits a guest sees and the CR4 settings.
>> But it prevents any use of xsave even on recent Xen hypervisors.
>> And this did recently cause problems because user-space was not
>> testing all bits when deciding to use certain features.
>>
>> This patch will actually mask off the cpuid bits for XSAVE and
>> OSXSAVE, so generic code will not even try to set CR4. It is
>> limited to PV guests and (since we do not actually know the
>> exact version) Xen hypervisors before version 4.
>>
>> Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
>> ---
>>  arch/x86/xen/enlighten.c |   17 ++++++++++++++++-
>>  1 file changed, 16 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
>> index 9642d4a..4241055 100644
>> --- a/arch/x86/xen/enlighten.c
>> +++ b/arch/x86/xen/enlighten.c
>> @@ -210,6 +210,18 @@ void xen_vcpu_restore(void)
>>  	}
>>  }
>> =20
>> +/*
>> + * Older (with no clear statement about what old means) Xen hyperviso=
rs
>> + * will crash a PV guest that tries to store OSXSAVE into CR4.
>> + * To prevent this, we force the feature bits related to this off in =
the
>> + * xen cpuid call. This inline function serves as a centralized test
>> + * on whether the quirk should be done.
>> + */
>> +static inline needs_xsave_quirk(unsigned version)
>> +{
>> +	return (xen_pv_domain() && ((version >> 16) < 4)) ? 1 : 0;
>> +}
>> +
>>  static void __init xen_banner(void)
>>  {
>>  	unsigned version =3D HYPERVISOR_xen_version(XENVER_version, NULL);
>> @@ -221,6 +233,8 @@ static void __init xen_banner(void)
>>  	printk(KERN_INFO "Xen version: %d.%d%s%s\n",
>>  	       version >> 16, version & 0xffff, extra.extraversion,
>>  	       xen_feature(XENFEAT_mmu_pt_update_preserve_ad) ? " (preserve-=
AD)" :=20
>> "");
>> +	if (needs_xsave_quirk(version))
>> +		printk(KERN_INFO "Forcing xsave off due to Xen version.\n");
>>  }
>> =20
>>  #define CPUID_THERM_POWER_LEAF 6
>> @@ -351,6 +365,7 @@ static bool __init xen_check_mwait(void)
>>  }
>>  static void __init xen_init_cpuid_mask(void)
>>  {
>> +	unsigned version =3D HYPERVISOR_xen_version(XENVER_version, NULL);
>>  	unsigned int ax, bx, cx, dx;
>>  	unsigned int xsave_mask;
>> =20
>> @@ -371,7 +386,7 @@ static void __init xen_init_cpuid_mask(void)
>>  		(1 << (X86_FEATURE_OSXSAVE % 32));
>> =20
>>  	/* Xen will set CR4.OSXSAVE if supported and not disabled by force *=
/
>> -	if ((cx & xsave_mask) !=3D xsave_mask)
>> +	if (((cx & xsave_mask) !=3D xsave_mask) || needs_xsave_quirk(version=
))
>>  		cpuid_leaf1_ecx_mask &=3D ~xsave_mask; /* disable XSAVE & OSXSAVE *=
/
>>  	if (xen_check_mwait())
>>  		cpuid_leaf1_ecx_set_mask =3D (1 << (X86_FEATURE_MWAIT % 32));
>> --=20
>> 1.7.9.5
>>
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xen.org=20
>> http://lists.xen.org/xen-devel=20
>=20
>=20
>=20
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
>=20



--------------enigFEC341DE9F4CC3FEA7524E82
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://www.enigmail.net/

iQIcBAEBCgAGBQJQSfTpAAoJEOhnXe7L7s6jEdkP/0/UK0Ybd9uHcfShLGFtAsxP
veyXp3Ac2AQpneuevLZGDLjlkRzn14O2bbB5TewrF+2sSUWz5tOC0tsoS9V2ZVNC
PCfAGMptjNPbVK1S3e9nMuEz0qOeL02cW6rv0nupkmA76gFMcNdTwDq5wpxkA2cC
CzWiIk3pJ6fGo/gQfOu+4rzAO+VlZY8TZP0zyAc09oZhoJuAxyh2Iw5/4I/Fi0d9
DYtI5rhNhKRia6YcuAP7jUlk5T6+j6gcGT2ewdbu+03YMjuLaDFuWaTfMx1iAre4
yF3BnZKKf6D+y+N2vtgpA6XGuwUwWLrxY6do073J0Rr8kOi3m5SD0V/gxGFe+qz+
gIjC6IPIp0Gqbr+4icqa/hSF++YUnsitvOFXMAi1y+ox2AUQcO6N1SSwIVvfmGBO
ytwT4EQ9P7GCr1L6HnAoZys+vP6OrtiirJhj0yw1Zxk0Ae/y1vqutButGzey7eFa
RiSkVJgZ0kDDTs4fBKNMxXj1ZRByrerb/8Ih14flL9wK3ILbROYhq/Dt9Ebr0xGp
OXnlXicWyWu2qHECoPdGMrowRlVpYzOLoB3HX56Lm7x5FbPbFX1BdYr0pEabKNgg
Z4vNyyo3LlOVUlDvEz/6POV62yeKRDaJKUuQf8BbvsUEvO6jiczAYPcLvSzdfCtG
O8alNGMm9R7ngXLFdVOA
=wXZf
-----END PGP SIGNATURE-----

--------------enigFEC341DE9F4CC3FEA7524E82--


--===============5660692614958532387==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============5660692614958532387==--


From xen-devel-bounces@lists.xen.org Fri Sep 07 13:28:42 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Sep 2012 13:28:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9ybm-0006Aw-Pi; Fri, 07 Sep 2012 13:28: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 1T9ybl-0006An-8V
	for xen-devel@lists.xen.org; Fri, 07 Sep 2012 13:28:29 +0000
Received: from [85.158.143.99:52655] by server-1.bemta-4.messagelabs.com id
	84/17-12504-C76F9405; Fri, 07 Sep 2012 13:28:28 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-7.tower-216.messagelabs.com!1347024506!25765008!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiA0MzAyNjk=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiA0MzAyNjk=\n,UPPERCASE_25_50
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14774 invoked from network); 7 Sep 2012 13:28:27 -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; 7 Sep 2012 13:28:27 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/lr0M7qFlg=
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-069-014.pools.arcor-ip.net [84.57.69.14])
	by smtp.strato.de (joses mo35) (RZmta 30.14 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id a01943o87Cb4WH ;
	Fri, 7 Sep 2012 15:28:26 +0200 (CEST)
Received: by probook.site (Postfix, from userid 1000)
	id 4F86C183AD; Fri,  7 Sep 2012 15:28:24 +0200 (CEST)
Date: Fri, 7 Sep 2012 15:28:24 +0200
From: Olaf Hering <olaf@aepfle.de>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Message-ID: <20120907132824.GA18208@aepfle.de>
References: <cc71fe7029b27cb95d26.1346951697@probook.site>
	<1347007260.30018.39.camel@zakaz.uk.xensource.com>
	<20553.52602.892916.502689@mariner.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20553.52602.892916.502689@mariner.uk.xensource.com>
User-Agent: Mutt/1.5.21.rev5555 (2012-07-20)
Cc: Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] libxl: add missing dependencies of libxl.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, Sep 07, Ian Jackson wrote:

> -_%.api-for-check: %.h
> +_%.api-for-check: %.h $(filter-out %.api-ok, $(AUTOINCS))
>  	$(CC) $(CPPFLAGS) $(CFLAGS) $(CFLAGS_$*.o) -c -E $< $(APPEND_CFLAGS) \
>  		-DLIBXL_EXTERNAL_CALLERS_ONLY=LIBXL_EXTERNAL_CALLERS_ONLY \
>  		>$@.new
> 
> Can you confirm that this fixes it for you ?

The package builds fine with this change.
The failure if fixes happend only once.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 07 13:28:42 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Sep 2012 13:28:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9ybm-0006Aw-Pi; Fri, 07 Sep 2012 13:28: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 1T9ybl-0006An-8V
	for xen-devel@lists.xen.org; Fri, 07 Sep 2012 13:28:29 +0000
Received: from [85.158.143.99:52655] by server-1.bemta-4.messagelabs.com id
	84/17-12504-C76F9405; Fri, 07 Sep 2012 13:28:28 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-7.tower-216.messagelabs.com!1347024506!25765008!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiA0MzAyNjk=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiA0MzAyNjk=\n,UPPERCASE_25_50
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14774 invoked from network); 7 Sep 2012 13:28:27 -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; 7 Sep 2012 13:28:27 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/lr0M7qFlg=
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-069-014.pools.arcor-ip.net [84.57.69.14])
	by smtp.strato.de (joses mo35) (RZmta 30.14 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id a01943o87Cb4WH ;
	Fri, 7 Sep 2012 15:28:26 +0200 (CEST)
Received: by probook.site (Postfix, from userid 1000)
	id 4F86C183AD; Fri,  7 Sep 2012 15:28:24 +0200 (CEST)
Date: Fri, 7 Sep 2012 15:28:24 +0200
From: Olaf Hering <olaf@aepfle.de>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Message-ID: <20120907132824.GA18208@aepfle.de>
References: <cc71fe7029b27cb95d26.1346951697@probook.site>
	<1347007260.30018.39.camel@zakaz.uk.xensource.com>
	<20553.52602.892916.502689@mariner.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20553.52602.892916.502689@mariner.uk.xensource.com>
User-Agent: Mutt/1.5.21.rev5555 (2012-07-20)
Cc: Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] libxl: add missing dependencies of libxl.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, Sep 07, Ian Jackson wrote:

> -_%.api-for-check: %.h
> +_%.api-for-check: %.h $(filter-out %.api-ok, $(AUTOINCS))
>  	$(CC) $(CPPFLAGS) $(CFLAGS) $(CFLAGS_$*.o) -c -E $< $(APPEND_CFLAGS) \
>  		-DLIBXL_EXTERNAL_CALLERS_ONLY=LIBXL_EXTERNAL_CALLERS_ONLY \
>  		>$@.new
> 
> Can you confirm that this fixes it for you ?

The package builds fine with this change.
The failure if fixes happend only once.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 07 13:33:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Sep 2012 13:33:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9ygh-0006Vj-Hu; Fri, 07 Sep 2012 13:33:35 +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 1T9ygf-0006Vd-QY
	for xen-devel@lists.xen.org; Fri, 07 Sep 2012 13:33:34 +0000
Received: from [85.158.143.35:33164] by server-2.bemta-4.messagelabs.com id
	F2/50-21239-DA7F9405; Fri, 07 Sep 2012 13:33:33 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1347024802!17246248!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNjk1ODQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18945 invoked from network); 7 Sep 2012 13:33:23 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-14.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Sep 2012 13:33:23 -0000
X-IronPort-AV: E=Sophos;i="4.80,385,1344211200"; d="scan'208";a="37117058"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Sep 2012 13:28:31 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Fri, 7 Sep 2012 09:28:30 -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 1T9ybm-0005hp-Lz;
	Fri, 07 Sep 2012 14:28:30 +0100
Message-ID: <5049F67E.3080709@citrix.com>
Date: Fri, 7 Sep 2012 14:28:30 +0100
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:14.0) Gecko/20120714 Thunderbird/14.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <5049F10F.5010801@citrix.com>
	<504A0FDA0200007800099D10@nat28.tlf.novell.com>
In-Reply-To: <504A0FDA0200007800099D10@nat28.tlf.novell.com>
X-Enigmail-Version: 1.4.4
Cc: "Keir \(Xen.org\)" <keir@xen.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] kexec/noreboot: Don't kexec_crash() if
 noreboot has been requested.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/09/12 14:16, Jan Beulich wrote:
>>>> On 07.09.12 at 15:05, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
>> This issue came up when debugging pcpu linked list corruption (patches
>> for that issue to follow).
> Hmm, that's a matter of taste of course. Nor is running kdump
> really a (direct) reboot action. Both ways have their reasoning
> imo, so I'm not sure whether keeping things as is or applying the
> patch is the better thing.
>
> Jan

Hmm yes - I guess its not as clean cut as I thought, but I would still
argue that this patch is the lest surprising alternative.

One tweak I am thinking of working on soon is a "pause-on-reboot"
feature which is a bit like noreboot, but will accept a passphrase and
continue with the reboot, so you can 'pause', see the dying panic then
reboot without needing to invoke the server power management.

(This may have been as a result of being given details for the wrong
server power management interface IP address when debugging a server in
a data center 7 time zones away, and getting rather confused when it
didn't make any attempt to reboot.  I imagine someone else might get
equally irate if their server was rebooting without warning.)

~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 Fri Sep 07 13:33:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Sep 2012 13:33:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9ygh-0006Vj-Hu; Fri, 07 Sep 2012 13:33:35 +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 1T9ygf-0006Vd-QY
	for xen-devel@lists.xen.org; Fri, 07 Sep 2012 13:33:34 +0000
Received: from [85.158.143.35:33164] by server-2.bemta-4.messagelabs.com id
	F2/50-21239-DA7F9405; Fri, 07 Sep 2012 13:33:33 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1347024802!17246248!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNjk1ODQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18945 invoked from network); 7 Sep 2012 13:33:23 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-14.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Sep 2012 13:33:23 -0000
X-IronPort-AV: E=Sophos;i="4.80,385,1344211200"; d="scan'208";a="37117058"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Sep 2012 13:28:31 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Fri, 7 Sep 2012 09:28:30 -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 1T9ybm-0005hp-Lz;
	Fri, 07 Sep 2012 14:28:30 +0100
Message-ID: <5049F67E.3080709@citrix.com>
Date: Fri, 7 Sep 2012 14:28:30 +0100
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:14.0) Gecko/20120714 Thunderbird/14.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <5049F10F.5010801@citrix.com>
	<504A0FDA0200007800099D10@nat28.tlf.novell.com>
In-Reply-To: <504A0FDA0200007800099D10@nat28.tlf.novell.com>
X-Enigmail-Version: 1.4.4
Cc: "Keir \(Xen.org\)" <keir@xen.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] kexec/noreboot: Don't kexec_crash() if
 noreboot has been requested.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/09/12 14:16, Jan Beulich wrote:
>>>> On 07.09.12 at 15:05, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
>> This issue came up when debugging pcpu linked list corruption (patches
>> for that issue to follow).
> Hmm, that's a matter of taste of course. Nor is running kdump
> really a (direct) reboot action. Both ways have their reasoning
> imo, so I'm not sure whether keeping things as is or applying the
> patch is the better thing.
>
> Jan

Hmm yes - I guess its not as clean cut as I thought, but I would still
argue that this patch is the lest surprising alternative.

One tweak I am thinking of working on soon is a "pause-on-reboot"
feature which is a bit like noreboot, but will accept a passphrase and
continue with the reboot, so you can 'pause', see the dying panic then
reboot without needing to invoke the server power management.

(This may have been as a result of being given details for the wrong
server power management interface IP address when debugging a server in
a data center 7 time zones away, and getting rather confused when it
didn't make any attempt to reboot.  I imagine someone else might get
equally irate if their server was rebooting without warning.)

~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 Fri Sep 07 13:51:06 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Sep 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 1T9yxP-0006rH-6B; Fri, 07 Sep 2012 13:50: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 1T9yxM-0006rC-TC
	for xen-devel@lists.xen.org; Fri, 07 Sep 2012 13:50:49 +0000
Received: from [85.158.143.99:25677] by server-2.bemta-4.messagelabs.com id
	3B/3F-21239-8BBF9405; Fri, 07 Sep 2012 13:50:48 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1347025842!29125449!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzM0MTMw\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11732 invoked from network); 7 Sep 2012 13:50:44 -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; 7 Sep 2012 13:50:44 -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 q87DoQIV026673
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 7 Sep 2012 13:50:27 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
	q87DoOGD014835
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 7 Sep 2012 13:50:24 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
	q87DoNs4003491; Fri, 7 Sep 2012 08:50:24 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 07 Sep 2012 06:50:22 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id CA13F402E4; Fri,  7 Sep 2012 09:39:47 -0400 (EDT)
Date: Fri, 7 Sep 2012 09:39:47 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20120907133947.GD2870@phenom.dumpdata.com>
References: <501A5EF7020000780009219C@nat28.tlf.novell.com>
	<20120802141710.GF16749@phenom.dumpdata.com>
	<20120802160403.02de484e@mantra.us.oracle.com>
	<20120803133001.GA13750@andromeda.dapyr.net>
	<501BF44602000078000928B4@nat28.tlf.novell.com>
	<CAPbh3rsXaqQS9WQQmJ2uQ46LZdyFzkbSodUabGDAyFS+qTEwUg@mail.gmail.com>
	<5028CEE70200007800094623@nat28.tlf.novell.com>
	<50446B5402000078000981F4@nat28.tlf.novell.com>
	<20120906210323.GA303@phenom.dumpdata.com>
	<5049D4100200007800099A91@nat28.tlf.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <5049D4100200007800099A91@nat28.tlf.novell.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: Konrad Rzeszutek Wilk <konrad@kernel.org>,
	xen-devel <xen-devel@lists.xen.org>, konrad@darnok.org
Subject: Re: [Xen-devel] Ping: Re: [PATCH] Boot PV guests with more than
 128GB (v2) for 3.7
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Sep 07, 2012 at 10:01:36AM +0100, Jan Beulich wrote:
> >>> On 06.09.12 at 23:03, Konrad Rzeszutek Wilk <konrad@kernel.org> wrote:
> > On Mon, Sep 03, 2012 at 07:33:24AM +0100, Jan Beulich wrote:
> >> >>> On 13.08.12 at 09:54, "Jan Beulich" <JBeulich@suse.com> wrote:
> >> >>>> On 03.08.12 at 16:46, Konrad Rzeszutek Wilk <konrad@darnok.org> wrote:
> >> >> Didn't get to it yet. Sorry for top posting. If you have a patch ready I
> >> >> can test it on Monday - travelling now.
> >> > 
> >> > So here's what I was thinking of (compile tested only).
> >> 
> >> Obviously, if this works, I'd like to see this included in 4.2 (and
> >> 4.1-testing).
> > 
> > No luck. I still get:
> > 
> > (XEN) Pagetable walk from ffff8800443da070:
> > (XEN)  L4[0x110] = 0000009342f95067 0000000000001a0c
> > (XEN)  L3[0x001] = 0000000000000000 ffffffffffffffff
> 
> And I can't see why. I wasn't able to track down the original
> stack trace you saw on the archives - was that identical to
> this one (i.e. nothing changed at all)? If so (please forgive

It does look identical.

> that I'm asking, I just know that I happen to fall into this trap
> once in a while myself), did you indeed build and install the

I know. I did double check - as I couldn't install wholesale the
new RPM (owner of the box needed the old version of it), instead
I did this bit of hack:

xend stop
cd /konrad
rpmcpio xen-*konrad* | cpio -id
tar -czvf /xen.orig.tgz /usr/lib64/*xen*
rm -Rf /usr/lib64/*xen*
mv /usr/lib/python2.4/site-packages/xen /usr/lib/python2.4/site-packages/xen.old
ln -s /konrad/usr/lib/python2.4/site-packages/xen  /usr/lib/python2.4/site-packages/xen 
export PATH=/konrad/usr/bin:/konrad/usr/sbin:$PATH
export LD_LIBRARY_PATH=/konrad/usr/lib64

xend start
xm create /konrad/test.xm

Which _should_ have taken care of all in the toolstack.

> patched tools? In that case, adding some logging to the code
> in question is presumably the only alternative, short of
> anyone else seeing anything further wrong with that code.

That was my next thought too.. also that would verify that
my hac^H^H^Hinstallation worked properly.

> 
> Jan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 07 13:51:06 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Sep 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 1T9yxP-0006rH-6B; Fri, 07 Sep 2012 13:50: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 1T9yxM-0006rC-TC
	for xen-devel@lists.xen.org; Fri, 07 Sep 2012 13:50:49 +0000
Received: from [85.158.143.99:25677] by server-2.bemta-4.messagelabs.com id
	3B/3F-21239-8BBF9405; Fri, 07 Sep 2012 13:50:48 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1347025842!29125449!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzM0MTMw\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11732 invoked from network); 7 Sep 2012 13:50:44 -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; 7 Sep 2012 13:50:44 -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 q87DoQIV026673
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 7 Sep 2012 13:50:27 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
	q87DoOGD014835
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 7 Sep 2012 13:50:24 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
	q87DoNs4003491; Fri, 7 Sep 2012 08:50:24 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 07 Sep 2012 06:50:22 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id CA13F402E4; Fri,  7 Sep 2012 09:39:47 -0400 (EDT)
Date: Fri, 7 Sep 2012 09:39:47 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20120907133947.GD2870@phenom.dumpdata.com>
References: <501A5EF7020000780009219C@nat28.tlf.novell.com>
	<20120802141710.GF16749@phenom.dumpdata.com>
	<20120802160403.02de484e@mantra.us.oracle.com>
	<20120803133001.GA13750@andromeda.dapyr.net>
	<501BF44602000078000928B4@nat28.tlf.novell.com>
	<CAPbh3rsXaqQS9WQQmJ2uQ46LZdyFzkbSodUabGDAyFS+qTEwUg@mail.gmail.com>
	<5028CEE70200007800094623@nat28.tlf.novell.com>
	<50446B5402000078000981F4@nat28.tlf.novell.com>
	<20120906210323.GA303@phenom.dumpdata.com>
	<5049D4100200007800099A91@nat28.tlf.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <5049D4100200007800099A91@nat28.tlf.novell.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: Konrad Rzeszutek Wilk <konrad@kernel.org>,
	xen-devel <xen-devel@lists.xen.org>, konrad@darnok.org
Subject: Re: [Xen-devel] Ping: Re: [PATCH] Boot PV guests with more than
 128GB (v2) for 3.7
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Sep 07, 2012 at 10:01:36AM +0100, Jan Beulich wrote:
> >>> On 06.09.12 at 23:03, Konrad Rzeszutek Wilk <konrad@kernel.org> wrote:
> > On Mon, Sep 03, 2012 at 07:33:24AM +0100, Jan Beulich wrote:
> >> >>> On 13.08.12 at 09:54, "Jan Beulich" <JBeulich@suse.com> wrote:
> >> >>>> On 03.08.12 at 16:46, Konrad Rzeszutek Wilk <konrad@darnok.org> wrote:
> >> >> Didn't get to it yet. Sorry for top posting. If you have a patch ready I
> >> >> can test it on Monday - travelling now.
> >> > 
> >> > So here's what I was thinking of (compile tested only).
> >> 
> >> Obviously, if this works, I'd like to see this included in 4.2 (and
> >> 4.1-testing).
> > 
> > No luck. I still get:
> > 
> > (XEN) Pagetable walk from ffff8800443da070:
> > (XEN)  L4[0x110] = 0000009342f95067 0000000000001a0c
> > (XEN)  L3[0x001] = 0000000000000000 ffffffffffffffff
> 
> And I can't see why. I wasn't able to track down the original
> stack trace you saw on the archives - was that identical to
> this one (i.e. nothing changed at all)? If so (please forgive

It does look identical.

> that I'm asking, I just know that I happen to fall into this trap
> once in a while myself), did you indeed build and install the

I know. I did double check - as I couldn't install wholesale the
new RPM (owner of the box needed the old version of it), instead
I did this bit of hack:

xend stop
cd /konrad
rpmcpio xen-*konrad* | cpio -id
tar -czvf /xen.orig.tgz /usr/lib64/*xen*
rm -Rf /usr/lib64/*xen*
mv /usr/lib/python2.4/site-packages/xen /usr/lib/python2.4/site-packages/xen.old
ln -s /konrad/usr/lib/python2.4/site-packages/xen  /usr/lib/python2.4/site-packages/xen 
export PATH=/konrad/usr/bin:/konrad/usr/sbin:$PATH
export LD_LIBRARY_PATH=/konrad/usr/lib64

xend start
xm create /konrad/test.xm

Which _should_ have taken care of all in the toolstack.

> patched tools? In that case, adding some logging to the code
> in question is presumably the only alternative, short of
> anyone else seeing anything further wrong with that code.

That was my next thought too.. also that would verify that
my hac^H^H^Hinstallation worked properly.

> 
> Jan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 07 13:58:02 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Sep 2012 13: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 1T9z47-00070b-2I; Fri, 07 Sep 2012 13:57:47 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1T9z46-00070W-5d
	for xen-devel@lists.xen.org; Fri, 07 Sep 2012 13:57:46 +0000
Received: from [85.158.139.83:53236] by server-11.bemta-5.messagelabs.com id
	2B/AB-24658-95DF9405; Fri, 07 Sep 2012 13:57:45 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1347026263!29175440!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzM0MTMw\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3139 invoked from network); 7 Sep 2012 13:57:44 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-3.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 7 Sep 2012 13:57:44 -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 q87DvcI2002137
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 7 Sep 2012 13:57:39 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q87DvbAj028998
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 7 Sep 2012 13:57:37 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
	q87DvawV012683; Fri, 7 Sep 2012 08:57:36 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 07 Sep 2012 06:57:36 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 94896402E4; Fri,  7 Sep 2012 09:47:01 -0400 (EDT)
Date: Fri, 7 Sep 2012 09:47:01 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Stefan Bader <stefan.bader@canonical.com>
Message-ID: <20120907134701.GF2870@phenom.dumpdata.com>
References: <1347018043-21252-1-git-send-email-stefan.bader@canonical.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1347018043-21252-1-git-send-email-stefan.bader@canonical.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Matt Wilson <msw@amazon.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH/RFC] Fix xsave bug on older Xen hypervisors
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Sep 07, 2012 at 01:40:43PM +0200, Stefan Bader wrote:
> When writing unsupported flags into CR4 (for some time the
> xen_write_cr4 function would refuse to do anything at all)
> older Xen hypervisors (and patch can potentially be improved
> by finding out what older means in version numbers) would
> crash the guest.
> 
> Since Amazon EC2 would at least in the past be affected by that,
> Fedora and Ubuntu were carrying a hack that would filter out
> X86_CR4_OSXSAVE before writing to CR4. This would affect any
> PV guest, even those running on a newer HV.
> 
> And this recently caused trouble because some user-space was
> only partially checking (or maybe only looking at the cpuid
> bits) and then trying to use xsave even though the OS support
> was not set.
> 
> So I came up with a patch that would
> - limit the work-around to certain Xen versions
> - prevent the write to CR4 by unsetting xsave and osxsave in
>   the cpuid bits
> 
> Doing things that way may actually allow this to be acceptable
> upstream, so I am sending it around, now.
> It probably could be improved when knowing the exact version
> to test for but otherwise should allow to work around the guest
> crash while not preventing xsave on Xen 4.x and newer hosts.

Perhaps Matt can give us some hints here.. but otherwise this
"quirk" should fix this. It should also allow one to run a virgin
kernel on Amazon EC2 - and we can ask the distros to ditch their
existing work-arounds for this..


> 
> -Stefan
> 
> 
> >From dff8885934d4e1274a69c4cedd28a4d18a1255e8 Mon Sep 17 00:00:00 2001
> From: Stefan Bader <stefan.bader@canonical.com>
> Date: Fri, 15 Jun 2012 11:54:59 +0200
> Subject: [PATCH] xen: Mask xsave cpu capability on Xen host < 4
> 
> Older Xen hypervisors (like RHEL5 versions found to be used
> on Amazon's EC2) did have a bug which would crash the domain
> when trying to write unsupported CR4 values.
> Newer versions of the Xen hypervisor do handle this correctly.
> But when a 2.6.28 or later kernel (those seem to have
> xen_write_cr4 and xsave support) is booted as a PV guest on EC2,
> it potentially crashes when hitting the right CPU and the wrong
> hypervisor.
> 
> We were using a patch (taken from Fedora) that did always filter
> the OSXSAVE off the values written to CR4 when running as Xen PV
> guest. While not completely wrong this creates an inconsistency
> between the cpuid bits a guest sees and the CR4 settings.
> But it prevents any use of xsave even on recent Xen hypervisors.
> And this did recently cause problems because user-space was not
> testing all bits when deciding to use certain features.
> 
> This patch will actually mask off the cpuid bits for XSAVE and
> OSXSAVE, so generic code will not even try to set CR4. It is
> limited to PV guests and (since we do not actually know the
> exact version) Xen hypervisors before version 4.
> 
> Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
> ---
>  arch/x86/xen/enlighten.c |   17 ++++++++++++++++-
>  1 file changed, 16 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
> index 9642d4a..4241055 100644
> --- a/arch/x86/xen/enlighten.c
> +++ b/arch/x86/xen/enlighten.c
> @@ -210,6 +210,18 @@ void xen_vcpu_restore(void)
>  	}
>  }
>  
> +/*
> + * Older (with no clear statement about what old means) Xen hypervisors
> + * will crash a PV guest that tries to store OSXSAVE into CR4.
> + * To prevent this, we force the feature bits related to this off in the
> + * xen cpuid call. This inline function serves as a centralized test
> + * on whether the quirk should be done.
> + */
> +static inline needs_xsave_quirk(unsigned version)
> +{
> +	return (xen_pv_domain() && ((version >> 16) < 4)) ? 1 : 0;
> +}
> +
>  static void __init xen_banner(void)
>  {
>  	unsigned version = HYPERVISOR_xen_version(XENVER_version, NULL);
> @@ -221,6 +233,8 @@ static void __init xen_banner(void)
>  	printk(KERN_INFO "Xen version: %d.%d%s%s\n",
>  	       version >> 16, version & 0xffff, extra.extraversion,
>  	       xen_feature(XENFEAT_mmu_pt_update_preserve_ad) ? " (preserve-AD)" : "");
> +	if (needs_xsave_quirk(version))
> +		printk(KERN_INFO "Forcing xsave off due to Xen version.\n");
>  }
>  
>  #define CPUID_THERM_POWER_LEAF 6
> @@ -351,6 +365,7 @@ static bool __init xen_check_mwait(void)
>  }
>  static void __init xen_init_cpuid_mask(void)
>  {
> +	unsigned version = HYPERVISOR_xen_version(XENVER_version, NULL);
>  	unsigned int ax, bx, cx, dx;
>  	unsigned int xsave_mask;
>  
> @@ -371,7 +386,7 @@ static void __init xen_init_cpuid_mask(void)
>  		(1 << (X86_FEATURE_OSXSAVE % 32));
>  
>  	/* Xen will set CR4.OSXSAVE if supported and not disabled by force */
> -	if ((cx & xsave_mask) != xsave_mask)
> +	if (((cx & xsave_mask) != xsave_mask) || needs_xsave_quirk(version))
>  		cpuid_leaf1_ecx_mask &= ~xsave_mask; /* disable XSAVE & OSXSAVE */
>  	if (xen_check_mwait())
>  		cpuid_leaf1_ecx_set_mask = (1 << (X86_FEATURE_MWAIT % 32));
> -- 
> 1.7.9.5

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 07 13:58:02 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Sep 2012 13: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 1T9z47-00070b-2I; Fri, 07 Sep 2012 13:57:47 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1T9z46-00070W-5d
	for xen-devel@lists.xen.org; Fri, 07 Sep 2012 13:57:46 +0000
Received: from [85.158.139.83:53236] by server-11.bemta-5.messagelabs.com id
	2B/AB-24658-95DF9405; Fri, 07 Sep 2012 13:57:45 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1347026263!29175440!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzM0MTMw\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3139 invoked from network); 7 Sep 2012 13:57:44 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-3.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 7 Sep 2012 13:57:44 -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 q87DvcI2002137
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 7 Sep 2012 13:57:39 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q87DvbAj028998
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 7 Sep 2012 13:57:37 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
	q87DvawV012683; Fri, 7 Sep 2012 08:57:36 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 07 Sep 2012 06:57:36 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 94896402E4; Fri,  7 Sep 2012 09:47:01 -0400 (EDT)
Date: Fri, 7 Sep 2012 09:47:01 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Stefan Bader <stefan.bader@canonical.com>
Message-ID: <20120907134701.GF2870@phenom.dumpdata.com>
References: <1347018043-21252-1-git-send-email-stefan.bader@canonical.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1347018043-21252-1-git-send-email-stefan.bader@canonical.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Matt Wilson <msw@amazon.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH/RFC] Fix xsave bug on older Xen hypervisors
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Sep 07, 2012 at 01:40:43PM +0200, Stefan Bader wrote:
> When writing unsupported flags into CR4 (for some time the
> xen_write_cr4 function would refuse to do anything at all)
> older Xen hypervisors (and patch can potentially be improved
> by finding out what older means in version numbers) would
> crash the guest.
> 
> Since Amazon EC2 would at least in the past be affected by that,
> Fedora and Ubuntu were carrying a hack that would filter out
> X86_CR4_OSXSAVE before writing to CR4. This would affect any
> PV guest, even those running on a newer HV.
> 
> And this recently caused trouble because some user-space was
> only partially checking (or maybe only looking at the cpuid
> bits) and then trying to use xsave even though the OS support
> was not set.
> 
> So I came up with a patch that would
> - limit the work-around to certain Xen versions
> - prevent the write to CR4 by unsetting xsave and osxsave in
>   the cpuid bits
> 
> Doing things that way may actually allow this to be acceptable
> upstream, so I am sending it around, now.
> It probably could be improved when knowing the exact version
> to test for but otherwise should allow to work around the guest
> crash while not preventing xsave on Xen 4.x and newer hosts.

Perhaps Matt can give us some hints here.. but otherwise this
"quirk" should fix this. It should also allow one to run a virgin
kernel on Amazon EC2 - and we can ask the distros to ditch their
existing work-arounds for this..


> 
> -Stefan
> 
> 
> >From dff8885934d4e1274a69c4cedd28a4d18a1255e8 Mon Sep 17 00:00:00 2001
> From: Stefan Bader <stefan.bader@canonical.com>
> Date: Fri, 15 Jun 2012 11:54:59 +0200
> Subject: [PATCH] xen: Mask xsave cpu capability on Xen host < 4
> 
> Older Xen hypervisors (like RHEL5 versions found to be used
> on Amazon's EC2) did have a bug which would crash the domain
> when trying to write unsupported CR4 values.
> Newer versions of the Xen hypervisor do handle this correctly.
> But when a 2.6.28 or later kernel (those seem to have
> xen_write_cr4 and xsave support) is booted as a PV guest on EC2,
> it potentially crashes when hitting the right CPU and the wrong
> hypervisor.
> 
> We were using a patch (taken from Fedora) that did always filter
> the OSXSAVE off the values written to CR4 when running as Xen PV
> guest. While not completely wrong this creates an inconsistency
> between the cpuid bits a guest sees and the CR4 settings.
> But it prevents any use of xsave even on recent Xen hypervisors.
> And this did recently cause problems because user-space was not
> testing all bits when deciding to use certain features.
> 
> This patch will actually mask off the cpuid bits for XSAVE and
> OSXSAVE, so generic code will not even try to set CR4. It is
> limited to PV guests and (since we do not actually know the
> exact version) Xen hypervisors before version 4.
> 
> Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
> ---
>  arch/x86/xen/enlighten.c |   17 ++++++++++++++++-
>  1 file changed, 16 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
> index 9642d4a..4241055 100644
> --- a/arch/x86/xen/enlighten.c
> +++ b/arch/x86/xen/enlighten.c
> @@ -210,6 +210,18 @@ void xen_vcpu_restore(void)
>  	}
>  }
>  
> +/*
> + * Older (with no clear statement about what old means) Xen hypervisors
> + * will crash a PV guest that tries to store OSXSAVE into CR4.
> + * To prevent this, we force the feature bits related to this off in the
> + * xen cpuid call. This inline function serves as a centralized test
> + * on whether the quirk should be done.
> + */
> +static inline needs_xsave_quirk(unsigned version)
> +{
> +	return (xen_pv_domain() && ((version >> 16) < 4)) ? 1 : 0;
> +}
> +
>  static void __init xen_banner(void)
>  {
>  	unsigned version = HYPERVISOR_xen_version(XENVER_version, NULL);
> @@ -221,6 +233,8 @@ static void __init xen_banner(void)
>  	printk(KERN_INFO "Xen version: %d.%d%s%s\n",
>  	       version >> 16, version & 0xffff, extra.extraversion,
>  	       xen_feature(XENFEAT_mmu_pt_update_preserve_ad) ? " (preserve-AD)" : "");
> +	if (needs_xsave_quirk(version))
> +		printk(KERN_INFO "Forcing xsave off due to Xen version.\n");
>  }
>  
>  #define CPUID_THERM_POWER_LEAF 6
> @@ -351,6 +365,7 @@ static bool __init xen_check_mwait(void)
>  }
>  static void __init xen_init_cpuid_mask(void)
>  {
> +	unsigned version = HYPERVISOR_xen_version(XENVER_version, NULL);
>  	unsigned int ax, bx, cx, dx;
>  	unsigned int xsave_mask;
>  
> @@ -371,7 +386,7 @@ static void __init xen_init_cpuid_mask(void)
>  		(1 << (X86_FEATURE_OSXSAVE % 32));
>  
>  	/* Xen will set CR4.OSXSAVE if supported and not disabled by force */
> -	if ((cx & xsave_mask) != xsave_mask)
> +	if (((cx & xsave_mask) != xsave_mask) || needs_xsave_quirk(version))
>  		cpuid_leaf1_ecx_mask &= ~xsave_mask; /* disable XSAVE & OSXSAVE */
>  	if (xen_check_mwait())
>  		cpuid_leaf1_ecx_set_mask = (1 << (X86_FEATURE_MWAIT % 32));
> -- 
> 1.7.9.5

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 07 14:01:55 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Sep 2012 14: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 1T9z7q-0007Dr-V0; Fri, 07 Sep 2012 14:01:38 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1T9z7o-0007Dl-SN
	for xen-devel@lists.xen.org; Fri, 07 Sep 2012 14:01:37 +0000
Received: from [85.158.143.35:9816] by server-3.bemta-4.messagelabs.com id
	EF/43-08232-04EF9405; Fri, 07 Sep 2012 14:01:36 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1347026495!13824761!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM4ODU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30454 invoked from network); 7 Sep 2012 14:01:35 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-3.tower-21.messagelabs.com with SMTP;
	7 Sep 2012 14:01:35 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 07 Sep 2012 15:01:34 +0100
Message-Id: <504A1A950200007800099D4C@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 07 Sep 2012 15:02:29 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Stefan Bader" <stefan.bader@canonical.com>
References: <1347018043-21252-1-git-send-email-stefan.bader@canonical.com>
	<504A05B00200007800099C7B@nat28.tlf.novell.com>
	<5049F4E9.9050306@canonical.com>
In-Reply-To: <5049F4E9.9050306@canonical.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Matt Wilson <msw@amazon.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH/RFC] Fix xsave bug on older Xen hypervisors
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.09.12 at 15:21, Stefan Bader <stefan.bader@canonical.com> wrote:
> On 07.09.2012 14:33, Jan Beulich wrote:
>>>>> On 07.09.12 at 13:40, Stefan Bader <stefan.bader@canonical.com> wrote:
>>> When writing unsupported flags into CR4 (for some time the
>>> xen_write_cr4 function would refuse to do anything at all)
>>> older Xen hypervisors (and patch can potentially be improved
>>> by finding out what older means in version numbers) would
>>> crash the guest.
>>>
>>> Since Amazon EC2 would at least in the past be affected by that,
>>> Fedora and Ubuntu were carrying a hack that would filter out
>>> X86_CR4_OSXSAVE before writing to CR4. This would affect any
>>> PV guest, even those running on a newer HV.
>>>
>>> And this recently caused trouble because some user-space was
>>> only partially checking (or maybe only looking at the cpuid
>>> bits) and then trying to use xsave even though the OS support
>>> was not set.
>>>
>>> So I came up with a patch that would
>>> - limit the work-around to certain Xen versions
>>> - prevent the write to CR4 by unsetting xsave and osxsave in
>>>   the cpuid bits
>>>
>>> Doing things that way may actually allow this to be acceptable
>>> upstream, so I am sending it around, now.
>>> It probably could be improved when knowing the exact version
>>> to test for but otherwise should allow to work around the guest
>>> crash while not preventing xsave on Xen 4.x and newer hosts.
>> 
>> Before considering a hack like this, I'd really like to see evidence
>> of the described behavior with an upstream kernel (i.e. not one
>> with that known broken hack patched in, which has never been
>> upstream afaict).
> 
> This is the reason I wrote that Fedora and Ubuntu were carrying it. It never 
> has
> been send upstream (the other version) because it would filter the CR4 write 
> for
> any PV guest regardless of host version.

But iirc that bad patch is a Linux side one (i.e. you're trying to fix
something upstream that isn't upstream)?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 07 14:01:55 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Sep 2012 14: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 1T9z7q-0007Dr-V0; Fri, 07 Sep 2012 14:01:38 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1T9z7o-0007Dl-SN
	for xen-devel@lists.xen.org; Fri, 07 Sep 2012 14:01:37 +0000
Received: from [85.158.143.35:9816] by server-3.bemta-4.messagelabs.com id
	EF/43-08232-04EF9405; Fri, 07 Sep 2012 14:01:36 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1347026495!13824761!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM4ODU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30454 invoked from network); 7 Sep 2012 14:01:35 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-3.tower-21.messagelabs.com with SMTP;
	7 Sep 2012 14:01:35 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 07 Sep 2012 15:01:34 +0100
Message-Id: <504A1A950200007800099D4C@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 07 Sep 2012 15:02:29 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Stefan Bader" <stefan.bader@canonical.com>
References: <1347018043-21252-1-git-send-email-stefan.bader@canonical.com>
	<504A05B00200007800099C7B@nat28.tlf.novell.com>
	<5049F4E9.9050306@canonical.com>
In-Reply-To: <5049F4E9.9050306@canonical.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Matt Wilson <msw@amazon.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH/RFC] Fix xsave bug on older Xen hypervisors
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.09.12 at 15:21, Stefan Bader <stefan.bader@canonical.com> wrote:
> On 07.09.2012 14:33, Jan Beulich wrote:
>>>>> On 07.09.12 at 13:40, Stefan Bader <stefan.bader@canonical.com> wrote:
>>> When writing unsupported flags into CR4 (for some time the
>>> xen_write_cr4 function would refuse to do anything at all)
>>> older Xen hypervisors (and patch can potentially be improved
>>> by finding out what older means in version numbers) would
>>> crash the guest.
>>>
>>> Since Amazon EC2 would at least in the past be affected by that,
>>> Fedora and Ubuntu were carrying a hack that would filter out
>>> X86_CR4_OSXSAVE before writing to CR4. This would affect any
>>> PV guest, even those running on a newer HV.
>>>
>>> And this recently caused trouble because some user-space was
>>> only partially checking (or maybe only looking at the cpuid
>>> bits) and then trying to use xsave even though the OS support
>>> was not set.
>>>
>>> So I came up with a patch that would
>>> - limit the work-around to certain Xen versions
>>> - prevent the write to CR4 by unsetting xsave and osxsave in
>>>   the cpuid bits
>>>
>>> Doing things that way may actually allow this to be acceptable
>>> upstream, so I am sending it around, now.
>>> It probably could be improved when knowing the exact version
>>> to test for but otherwise should allow to work around the guest
>>> crash while not preventing xsave on Xen 4.x and newer hosts.
>> 
>> Before considering a hack like this, I'd really like to see evidence
>> of the described behavior with an upstream kernel (i.e. not one
>> with that known broken hack patched in, which has never been
>> upstream afaict).
> 
> This is the reason I wrote that Fedora and Ubuntu were carrying it. It never 
> has
> been send upstream (the other version) because it would filter the CR4 write 
> for
> any PV guest regardless of host version.

But iirc that bad patch is a Linux side one (i.e. you're trying to fix
something upstream that isn't upstream)?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 07 14:08:28 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Sep 2012 14: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 1T9zEB-0007Yi-Pk; Fri, 07 Sep 2012 14:08:11 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1T9zEA-0007Ya-1w
	for xen-devel@lists.xen.org; Fri, 07 Sep 2012 14:08:10 +0000
Received: from [85.158.143.35:4953] by server-3.bemta-4.messagelabs.com id
	B1/70-08232-9CFF9405; Fri, 07 Sep 2012 14:08:09 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1347026887!11661847!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM4ODU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2201 invoked from network); 7 Sep 2012 14:08:08 -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;
	7 Sep 2012 14:08:08 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 07 Sep 2012 15:08:06 +0100
Message-Id: <504A1C1C0200007800099D64@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 07 Sep 2012 15:09:00 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>
References: <501A5EF7020000780009219C@nat28.tlf.novell.com>
	<20120802141710.GF16749@phenom.dumpdata.com>
	<20120802160403.02de484e@mantra.us.oracle.com>
	<20120803133001.GA13750@andromeda.dapyr.net>
	<501BF44602000078000928B4@nat28.tlf.novell.com>
	<CAPbh3rsXaqQS9WQQmJ2uQ46LZdyFzkbSodUabGDAyFS+qTEwUg@mail.gmail.com>
	<5028CEE70200007800094623@nat28.tlf.novell.com>
	<50446B5402000078000981F4@nat28.tlf.novell.com>
	<20120906210323.GA303@phenom.dumpdata.com>
	<5049D4100200007800099A91@nat28.tlf.novell.com>
	<20120907133947.GD2870@phenom.dumpdata.com>
In-Reply-To: <20120907133947.GD2870@phenom.dumpdata.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: konrad@darnok.org, xen-devel <xen-devel@lists.xen.org>,
	Konrad Rzeszutek Wilk <konrad@kernel.org>
Subject: Re: [Xen-devel] Ping: Re: [PATCH] Boot PV guests with more than
 128GB (v2) for 3.7
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.09.12 at 15:39, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
> On Fri, Sep 07, 2012 at 10:01:36AM +0100, Jan Beulich wrote:
>> that I'm asking, I just know that I happen to fall into this trap
>> once in a while myself), did you indeed build and install the
> 
> I know. I did double check - as I couldn't install wholesale the
> new RPM (owner of the box needed the old version of it), instead
> I did this bit of hack:
> 
> xend stop
> cd /konrad
> rpmcpio xen-*konrad* | cpio -id
> tar -czvf /xen.orig.tgz /usr/lib64/*xen*
> rm -Rf /usr/lib64/*xen*

So here you removed the old libraries. But where did you drop in
the new ones? Did you just forget to list this here?

> mv /usr/lib/python2.4/site-packages/xen /usr/lib/python2.4/site-packages/xen.old
> ln -s /konrad/usr/lib/python2.4/site-packages/xen  /usr/lib/python2.4/site-packages/xen 
> export PATH=/konrad/usr/bin:/konrad/usr/sbin:$PATH
> export LD_LIBRARY_PATH=/konrad/usr/lib64
> 
> xend start
> xm create /konrad/test.xm

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 07 14:08:28 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Sep 2012 14: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 1T9zEB-0007Yi-Pk; Fri, 07 Sep 2012 14:08:11 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1T9zEA-0007Ya-1w
	for xen-devel@lists.xen.org; Fri, 07 Sep 2012 14:08:10 +0000
Received: from [85.158.143.35:4953] by server-3.bemta-4.messagelabs.com id
	B1/70-08232-9CFF9405; Fri, 07 Sep 2012 14:08:09 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1347026887!11661847!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM4ODU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2201 invoked from network); 7 Sep 2012 14:08:08 -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;
	7 Sep 2012 14:08:08 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 07 Sep 2012 15:08:06 +0100
Message-Id: <504A1C1C0200007800099D64@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 07 Sep 2012 15:09:00 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>
References: <501A5EF7020000780009219C@nat28.tlf.novell.com>
	<20120802141710.GF16749@phenom.dumpdata.com>
	<20120802160403.02de484e@mantra.us.oracle.com>
	<20120803133001.GA13750@andromeda.dapyr.net>
	<501BF44602000078000928B4@nat28.tlf.novell.com>
	<CAPbh3rsXaqQS9WQQmJ2uQ46LZdyFzkbSodUabGDAyFS+qTEwUg@mail.gmail.com>
	<5028CEE70200007800094623@nat28.tlf.novell.com>
	<50446B5402000078000981F4@nat28.tlf.novell.com>
	<20120906210323.GA303@phenom.dumpdata.com>
	<5049D4100200007800099A91@nat28.tlf.novell.com>
	<20120907133947.GD2870@phenom.dumpdata.com>
In-Reply-To: <20120907133947.GD2870@phenom.dumpdata.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: konrad@darnok.org, xen-devel <xen-devel@lists.xen.org>,
	Konrad Rzeszutek Wilk <konrad@kernel.org>
Subject: Re: [Xen-devel] Ping: Re: [PATCH] Boot PV guests with more than
 128GB (v2) for 3.7
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.09.12 at 15:39, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
> On Fri, Sep 07, 2012 at 10:01:36AM +0100, Jan Beulich wrote:
>> that I'm asking, I just know that I happen to fall into this trap
>> once in a while myself), did you indeed build and install the
> 
> I know. I did double check - as I couldn't install wholesale the
> new RPM (owner of the box needed the old version of it), instead
> I did this bit of hack:
> 
> xend stop
> cd /konrad
> rpmcpio xen-*konrad* | cpio -id
> tar -czvf /xen.orig.tgz /usr/lib64/*xen*
> rm -Rf /usr/lib64/*xen*

So here you removed the old libraries. But where did you drop in
the new ones? Did you just forget to list this here?

> mv /usr/lib/python2.4/site-packages/xen /usr/lib/python2.4/site-packages/xen.old
> ln -s /konrad/usr/lib/python2.4/site-packages/xen  /usr/lib/python2.4/site-packages/xen 
> export PATH=/konrad/usr/bin:/konrad/usr/sbin:$PATH
> export LD_LIBRARY_PATH=/konrad/usr/lib64
> 
> xend start
> xm create /konrad/test.xm

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 07 14:09:30 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Sep 2012 14:09:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9zFD-0007bj-8e; Fri, 07 Sep 2012 14:09:15 +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 1T9zFB-0007bV-G0
	for xen-devel@lists.xen.org; Fri, 07 Sep 2012 14:09:13 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1347026781!8788563!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzM0MTMw\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17008 invoked from network); 7 Sep 2012 14:06:23 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-9.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 7 Sep 2012 14:06:23 -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 q87E6FGL011921
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 7 Sep 2012 14:06:16 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
	q87E6FLo029726
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 7 Sep 2012 14:06:15 GMT
Received: from abhmt102.oracle.com (abhmt102.oracle.com [141.146.116.54])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q87E6EZK020821; Fri, 7 Sep 2012 09:06:14 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 07 Sep 2012 07:06:14 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 6357C402E4; Fri,  7 Sep 2012 09:55:39 -0400 (EDT)
Date: Fri, 7 Sep 2012 09:55:39 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: "Ren, Yongjie" <yongjie.ren@intel.com>
Message-ID: <20120907135539.GI2870@phenom.dumpdata.com>
References: <1B4B44D9196EFF41AE41FDA404FC0A1018AF31@SHSMSX101.ccr.corp.intel.com>
	<20120831172410.GA19756@localhost.localdomain>
	<1B4B44D9196EFF41AE41FDA404FC0A10190E9D@SHSMSX101.ccr.corp.intel.com>
	<20120906111158.GF3668@phenom.dumpdata.com>
	<1B4B44D9196EFF41AE41FDA404FC0A10194823@SHSMSX101.ccr.corp.intel.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1B4B44D9196EFF41AE41FDA404FC0A10194823@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: Konrad Rzeszutek Wilk <konrad@kernel.org>, 'Keir Fraser' <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] Xen4.2-rc3 test result
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Sep 07, 2012 at 08:01:37AM +0000, Ren, Yongjie wrote:
> > -----Original Message-----
> > From: Konrad Rzeszutek Wilk [mailto:konrad.wilk@oracle.com]
> > Sent: Thursday, September 06, 2012 7:12 PM
> > To: Ren, Yongjie
> > Cc: Konrad Rzeszutek Wilk; 'xen-devel'; 'Keir Fraser'; 'Ian Campbell'; 'Jan
> > Beulich'
> > Subject: Re: [Xen-devel] Xen4.2-rc3 test result
> > 
> > On Thu, Sep 06, 2012 at 08:18:16AM +0000, Ren, Yongjie wrote:
> > > > -----Original Message-----
> > > > From: Konrad Rzeszutek [mailto:ketuzsezr@gmail.com] On Behalf Of
> > > > Konrad Rzeszutek Wilk
> > > > Sent: Saturday, September 01, 2012 1:24 AM
> > > > To: Ren, Yongjie
> > > > Cc: 'xen-devel'; 'Keir Fraser'; 'Ian Campbell'; 'Jan Beulich'; 'Konrad
> > > > Rzeszutek Wilk'
> > > > Subject: Re: [Xen-devel] Xen4.2-rc3 test result
> > >
> > > > > 5. Dom0 cannot be shutdown before PCI detachment from guest and
> > > > when pci assignment conflicts
> > > > >   http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1826
> > > >
> > > > Um, so you are assigning the same VF to two guests. I am surprised
> > that
> > > > the tools even allowed you to do that. Was 'xm' allowing you to do
> > that?
> > > >
> > > No, 'xl' doesn't allow me to do that. We can't assignment a device to
> > different guests.
> > > Sorry, the description of this bug is not accurate. I changed its title to
> > "Dom0 cannot be shut down before PCI device detachment from a guest".
> > > If a guest (with a PCI device assigned) is running, Dom0 will panic when
> > shutting down.
> > 
> > And does it panic if you use the 'irqpoll' option it asks for?
> >
> Adding 'irqpoll' makes no change.
> 
> It should be a regression for Xen from 4.1 to 4.2.
> I didn't meet this issue with 4.2 Xen and 3.5.3 Dom0.

Aaah. That was not clear from the bugzilla.

> 
> > Xen-pciback has no involvment as:
> > 
> > 
> > [  283.747488] xenbus_dev_shutdown: backend/pci/1/0: Initialised !=
> > Connected, skipping
> > 
> > and the guest still keeps on getting interrupts.
> > 
> > What is the stack at the hang?
> >
> [  283.747488] xenbus_dev_shutdown: backend/pci/1/0: Initialised != Connected,
> skipping
> [  283.747505] xenbus_dev_shutdown: backend/vkbd/2/0: Initialising !=
> Connected, skipping
> [  283.747515] xenbus_dev_shutdown: backend/console/2/0: Initialising !=
> Connected, skipping
> [  380.236571] irq 16: nobody cared (try booting with the "irqpoll" option)
> [  380.236588] Pid: 0, comm: swapper/0 Not tainted 3.4.4 #1
> [  380.236596] Call Trace:
> [  380.236601]  <IRQ>  [<ffffffff8110b538>] __report_bad_irq+0x38/0xd0
> [  380.236626]  [<ffffffff8110b72c>] note_interrupt+0x15c/0x210
> [  380.236637]  [<ffffffff81108ffa>] handle_irq_event_percpu+0xca/0x230
> [  380.236648]  [<ffffffff811091b6>] handle_irq_event+0x56/0x90
> [  380.236658]  [<ffffffff8110bde3>] handle_fasteoi_irq+0x63/0x120
> [  380.236671]  [<ffffffff8131c8f1>] __xen_evtchn_do_upcall+0x1b1/0x280
> [  380.236703]  [<ffffffff8131d51a>] xen_evtchn_do_upcall+0x2a/0x40
> [  380.236716]  [<ffffffff816bc36e>] xen_do_hypervisor_callback+0x1e/0x30
> [  380.236723]  <EOI>  [<ffffffff810013aa>] ? hypercall_page+0x3aa/0x1000
> [  380.236742]  [<ffffffff810013aa>] ? hypercall_page+0x3aa/0x1000
> [  380.236754]  [<ffffffff810538d0>] ? xen_safe_halt+0x10/0x20
> [  380.236768]  [<ffffffff81067c9a>] ? default_idle+0x6a/0x1d0
> [  380.236778]  [<ffffffff81067256>] ? cpu_idle+0x96/0xf0
> [  380.236789]  [<ffffffff81689a18>] ? rest_init+0x68/0x70
> [  380.236800]  [<ffffffff81ca9e33>] ? start_kernel+0x407/0x414
> [  380.236810]  [<ffffffff81ca984a>] ? kernel_init+0x1e1/0x1e1
> [  380.236821]  [<ffffffff81ca9346>] ? x86_64_start_reservations+0x131/0x136
> [  380.236833]  [<ffffffff81cade7a>] ? xen_start_kernel+0x621/0x628
> [  380.236841] handlers:
> [  380.236850] [<ffffffff81428d80>] usb_hcd_irq
> [  380.236860] Disabling IRQ #16

That is not the hang stack. That is the kernel telling you that something
has gone astray with an interrupt. But its unclear what happend _after_ that.

It might be that the system called the proper shutdown hypercall and its
waiting for the hypervisor to do its stuff. Can you try using the 'q' to get
a stack dump of the dom0 and see where its spinning/sitting please?
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 07 14:09:30 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Sep 2012 14:09:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9zFD-0007bj-8e; Fri, 07 Sep 2012 14:09:15 +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 1T9zFB-0007bV-G0
	for xen-devel@lists.xen.org; Fri, 07 Sep 2012 14:09:13 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1347026781!8788563!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzM0MTMw\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17008 invoked from network); 7 Sep 2012 14:06:23 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-9.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 7 Sep 2012 14:06:23 -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 q87E6FGL011921
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 7 Sep 2012 14:06:16 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
	q87E6FLo029726
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 7 Sep 2012 14:06:15 GMT
Received: from abhmt102.oracle.com (abhmt102.oracle.com [141.146.116.54])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q87E6EZK020821; Fri, 7 Sep 2012 09:06:14 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 07 Sep 2012 07:06:14 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 6357C402E4; Fri,  7 Sep 2012 09:55:39 -0400 (EDT)
Date: Fri, 7 Sep 2012 09:55:39 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: "Ren, Yongjie" <yongjie.ren@intel.com>
Message-ID: <20120907135539.GI2870@phenom.dumpdata.com>
References: <1B4B44D9196EFF41AE41FDA404FC0A1018AF31@SHSMSX101.ccr.corp.intel.com>
	<20120831172410.GA19756@localhost.localdomain>
	<1B4B44D9196EFF41AE41FDA404FC0A10190E9D@SHSMSX101.ccr.corp.intel.com>
	<20120906111158.GF3668@phenom.dumpdata.com>
	<1B4B44D9196EFF41AE41FDA404FC0A10194823@SHSMSX101.ccr.corp.intel.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1B4B44D9196EFF41AE41FDA404FC0A10194823@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: Konrad Rzeszutek Wilk <konrad@kernel.org>, 'Keir Fraser' <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] Xen4.2-rc3 test result
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Sep 07, 2012 at 08:01:37AM +0000, Ren, Yongjie wrote:
> > -----Original Message-----
> > From: Konrad Rzeszutek Wilk [mailto:konrad.wilk@oracle.com]
> > Sent: Thursday, September 06, 2012 7:12 PM
> > To: Ren, Yongjie
> > Cc: Konrad Rzeszutek Wilk; 'xen-devel'; 'Keir Fraser'; 'Ian Campbell'; 'Jan
> > Beulich'
> > Subject: Re: [Xen-devel] Xen4.2-rc3 test result
> > 
> > On Thu, Sep 06, 2012 at 08:18:16AM +0000, Ren, Yongjie wrote:
> > > > -----Original Message-----
> > > > From: Konrad Rzeszutek [mailto:ketuzsezr@gmail.com] On Behalf Of
> > > > Konrad Rzeszutek Wilk
> > > > Sent: Saturday, September 01, 2012 1:24 AM
> > > > To: Ren, Yongjie
> > > > Cc: 'xen-devel'; 'Keir Fraser'; 'Ian Campbell'; 'Jan Beulich'; 'Konrad
> > > > Rzeszutek Wilk'
> > > > Subject: Re: [Xen-devel] Xen4.2-rc3 test result
> > >
> > > > > 5. Dom0 cannot be shutdown before PCI detachment from guest and
> > > > when pci assignment conflicts
> > > > >   http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1826
> > > >
> > > > Um, so you are assigning the same VF to two guests. I am surprised
> > that
> > > > the tools even allowed you to do that. Was 'xm' allowing you to do
> > that?
> > > >
> > > No, 'xl' doesn't allow me to do that. We can't assignment a device to
> > different guests.
> > > Sorry, the description of this bug is not accurate. I changed its title to
> > "Dom0 cannot be shut down before PCI device detachment from a guest".
> > > If a guest (with a PCI device assigned) is running, Dom0 will panic when
> > shutting down.
> > 
> > And does it panic if you use the 'irqpoll' option it asks for?
> >
> Adding 'irqpoll' makes no change.
> 
> It should be a regression for Xen from 4.1 to 4.2.
> I didn't meet this issue with 4.2 Xen and 3.5.3 Dom0.

Aaah. That was not clear from the bugzilla.

> 
> > Xen-pciback has no involvment as:
> > 
> > 
> > [  283.747488] xenbus_dev_shutdown: backend/pci/1/0: Initialised !=
> > Connected, skipping
> > 
> > and the guest still keeps on getting interrupts.
> > 
> > What is the stack at the hang?
> >
> [  283.747488] xenbus_dev_shutdown: backend/pci/1/0: Initialised != Connected,
> skipping
> [  283.747505] xenbus_dev_shutdown: backend/vkbd/2/0: Initialising !=
> Connected, skipping
> [  283.747515] xenbus_dev_shutdown: backend/console/2/0: Initialising !=
> Connected, skipping
> [  380.236571] irq 16: nobody cared (try booting with the "irqpoll" option)
> [  380.236588] Pid: 0, comm: swapper/0 Not tainted 3.4.4 #1
> [  380.236596] Call Trace:
> [  380.236601]  <IRQ>  [<ffffffff8110b538>] __report_bad_irq+0x38/0xd0
> [  380.236626]  [<ffffffff8110b72c>] note_interrupt+0x15c/0x210
> [  380.236637]  [<ffffffff81108ffa>] handle_irq_event_percpu+0xca/0x230
> [  380.236648]  [<ffffffff811091b6>] handle_irq_event+0x56/0x90
> [  380.236658]  [<ffffffff8110bde3>] handle_fasteoi_irq+0x63/0x120
> [  380.236671]  [<ffffffff8131c8f1>] __xen_evtchn_do_upcall+0x1b1/0x280
> [  380.236703]  [<ffffffff8131d51a>] xen_evtchn_do_upcall+0x2a/0x40
> [  380.236716]  [<ffffffff816bc36e>] xen_do_hypervisor_callback+0x1e/0x30
> [  380.236723]  <EOI>  [<ffffffff810013aa>] ? hypercall_page+0x3aa/0x1000
> [  380.236742]  [<ffffffff810013aa>] ? hypercall_page+0x3aa/0x1000
> [  380.236754]  [<ffffffff810538d0>] ? xen_safe_halt+0x10/0x20
> [  380.236768]  [<ffffffff81067c9a>] ? default_idle+0x6a/0x1d0
> [  380.236778]  [<ffffffff81067256>] ? cpu_idle+0x96/0xf0
> [  380.236789]  [<ffffffff81689a18>] ? rest_init+0x68/0x70
> [  380.236800]  [<ffffffff81ca9e33>] ? start_kernel+0x407/0x414
> [  380.236810]  [<ffffffff81ca984a>] ? kernel_init+0x1e1/0x1e1
> [  380.236821]  [<ffffffff81ca9346>] ? x86_64_start_reservations+0x131/0x136
> [  380.236833]  [<ffffffff81cade7a>] ? xen_start_kernel+0x621/0x628
> [  380.236841] handlers:
> [  380.236850] [<ffffffff81428d80>] usb_hcd_irq
> [  380.236860] Disabling IRQ #16

That is not the hang stack. That is the kernel telling you that something
has gone astray with an interrupt. But its unclear what happend _after_ that.

It might be that the system called the proper shutdown hypercall and its
waiting for the hypervisor to do its stuff. Can you try using the 'q' to get
a stack dump of the dom0 and see where its spinning/sitting please?
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 07 14:15:28 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Sep 2012 14:15: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 1T9zKy-0007qx-5h; Fri, 07 Sep 2012 14:15:12 +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 1T9zKw-0007qs-L3
	for xen-devel@lists.xen.org; Fri, 07 Sep 2012 14:15:11 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1347027298!8969108!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTIyMTE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7488 invoked from network); 7 Sep 2012 14:14:58 -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;
	7 Sep 2012 14:14:58 -0000
X-IronPort-AV: E=Sophos;i="4.80,387,1344211200"; d="scan'208";a="14411810"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Sep 2012 14:14: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.279.1; Fri, 7 Sep 2012
	15:14:58 +0100
Message-ID: <1347027296.30018.108.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: xen-devel <xen-devel@lists.xen.org>
Date: Fri, 7 Sep 2012 15:14:56 +0100
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Subject: [Xen-devel] Xen 4.2 new features and status -- please help me make
	a list
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi all,

I've been trawling the mercurial logs looking for interesting new
features to update http://wiki.xen.org/wiki/Xen_4.2_Feature_List and
http://wiki.xen.org/wiki/Xen_Release_Features and have come up with a
list of interesting things which I need to know more about before I can
say stuff.

I've bcc'd people who I think might know about one or more of the
following. If you do then please can you tell me:

      * What is the feature, what is the impact for the end user?
      * What is it's status in 4.2? Is it a proof of concept, an
        experimental feature, tech preview or a finished completed
        feature.
      * Is it new in 4.2? If it isn't new what was it's status in 4.1
        and 4.0 (i.e. from the list in the previous item).

Of course if you know of a feature in 4.2 which isn't mentioned but
which you think is worthwhile please let me know. I'm sure there are
plenty which I missed.

Also feel free to edit the wiki instead....

TIA for your help.

Ian.

Nested Virtualisation: Allow HVM guests to use virtualisation hardware
(e.g. Windows 7 compat mode)
        Tech Preview, new in 4.2
        
vMSI: ? Emulated (or real?) MSIs for guests?
        State? New in 4.2?
        
vMCE: Forward MCE (Machine Check Exceptions) to guests
        New in 4.2? Preview or complete? I know improvements are pending
        to migration in 4.3.
        
AMD OSVW: What is this?
        Seems to be new in 4.2?
        
xenpaging: Page HVM guest pages to disk
        Was marked as tech preview in 4.1 and earlier, still is?
        
memsharing: Sharing of HVM guest pages.
        Was marked as tech preview in 4.1 and earlier, still is?

Intel HLE: What is this?
        Seems to be new in 4.2?
        
Intel TRM: What is this?
        Seems to be new in 4.2?

OVMF support for HVM guests.
        New in 4.2, but disabled by default => Tech preview?
        
vPMU: Power Management?
        New in 4.2?
        
ASID support:
        4.2 gained an option to control this but I think it was
        pre-existing. When was it first introduced? 4.1 or 4.0 or
        before?
        
Core parking: Offlining CPUs for power reasons?
        New in 4.2?
        
PV netboot: Network boot for PV guests
        New in 4.2



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 07 14:15:28 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Sep 2012 14:15: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 1T9zKy-0007qx-5h; Fri, 07 Sep 2012 14:15:12 +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 1T9zKw-0007qs-L3
	for xen-devel@lists.xen.org; Fri, 07 Sep 2012 14:15:11 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1347027298!8969108!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTIyMTE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7488 invoked from network); 7 Sep 2012 14:14:58 -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;
	7 Sep 2012 14:14:58 -0000
X-IronPort-AV: E=Sophos;i="4.80,387,1344211200"; d="scan'208";a="14411810"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Sep 2012 14:14: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.279.1; Fri, 7 Sep 2012
	15:14:58 +0100
Message-ID: <1347027296.30018.108.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: xen-devel <xen-devel@lists.xen.org>
Date: Fri, 7 Sep 2012 15:14:56 +0100
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Subject: [Xen-devel] Xen 4.2 new features and status -- please help me make
	a list
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi all,

I've been trawling the mercurial logs looking for interesting new
features to update http://wiki.xen.org/wiki/Xen_4.2_Feature_List and
http://wiki.xen.org/wiki/Xen_Release_Features and have come up with a
list of interesting things which I need to know more about before I can
say stuff.

I've bcc'd people who I think might know about one or more of the
following. If you do then please can you tell me:

      * What is the feature, what is the impact for the end user?
      * What is it's status in 4.2? Is it a proof of concept, an
        experimental feature, tech preview or a finished completed
        feature.
      * Is it new in 4.2? If it isn't new what was it's status in 4.1
        and 4.0 (i.e. from the list in the previous item).

Of course if you know of a feature in 4.2 which isn't mentioned but
which you think is worthwhile please let me know. I'm sure there are
plenty which I missed.

Also feel free to edit the wiki instead....

TIA for your help.

Ian.

Nested Virtualisation: Allow HVM guests to use virtualisation hardware
(e.g. Windows 7 compat mode)
        Tech Preview, new in 4.2
        
vMSI: ? Emulated (or real?) MSIs for guests?
        State? New in 4.2?
        
vMCE: Forward MCE (Machine Check Exceptions) to guests
        New in 4.2? Preview or complete? I know improvements are pending
        to migration in 4.3.
        
AMD OSVW: What is this?
        Seems to be new in 4.2?
        
xenpaging: Page HVM guest pages to disk
        Was marked as tech preview in 4.1 and earlier, still is?
        
memsharing: Sharing of HVM guest pages.
        Was marked as tech preview in 4.1 and earlier, still is?

Intel HLE: What is this?
        Seems to be new in 4.2?
        
Intel TRM: What is this?
        Seems to be new in 4.2?

OVMF support for HVM guests.
        New in 4.2, but disabled by default => Tech preview?
        
vPMU: Power Management?
        New in 4.2?
        
ASID support:
        4.2 gained an option to control this but I think it was
        pre-existing. When was it first introduced? 4.1 or 4.0 or
        before?
        
Core parking: Offlining CPUs for power reasons?
        New in 4.2?
        
PV netboot: Network boot for PV guests
        New in 4.2



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 07 14:21:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Sep 2012 14:21:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9zQS-00080S-Ua; Fri, 07 Sep 2012 14:20:52 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <daniel.lezcano@linaro.org>) id 1T9zQR-00080N-GE
	for xen-devel@lists.xensource.com; Fri, 07 Sep 2012 14:20:51 +0000
Received: from [85.158.138.51:42812] by server-5.bemta-3.messagelabs.com id
	B1/88-13133-2C20A405; Fri, 07 Sep 2012 14:20:50 +0000
X-Env-Sender: daniel.lezcano@linaro.org
X-Msg-Ref: server-6.tower-174.messagelabs.com!1347027649!21268413!1
X-Originating-IP: [209.85.215.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29391 invoked from network); 7 Sep 2012 14:20:49 -0000
Received: from mail-ey0-f171.google.com (HELO mail-ey0-f171.google.com)
	(209.85.215.171)
	by server-6.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Sep 2012 14:20:49 -0000
Received: by eaah11 with SMTP id h11so997518eaa.30
	for <xen-devel@lists.xensource.com>;
	Fri, 07 Sep 2012 07:20:49 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=message-id:date:from:user-agent:mime-version:to:cc:subject
	:references:in-reply-to:content-type:content-transfer-encoding
	:x-gm-message-state;
	bh=TI1YKWf/K7YFuHlU+fg5fgKOujmInhyS4SEAPu+Hgzs=;
	b=mPjJ60fhGOlq6uJec8Cz2cIyPNFs9/JStEtDoHch6pV0VfzVJpj7C4wTKRDqTS3QOY
	KpVvR78Et2WIq+e4Vhkcial/P86/0BcVHwwk7rd9W8jcFrtm0tFWSn8aELBLrx0Iw2RI
	1RcSMuZ3O3PDvLdWT23xUsVhnaE2hvqMnHSOoCYKzpCxvRW7a4/XwBm3qSUbPPuMmCTv
	UX1gQVTeR8zrh+3DhLAuw6c4LRrfums0qfs0J6Rf57P9l1pVyHTpyzMa0YPytXWzBxwv
	+af96P6dh0XPayZd45pmse3MoasrvYLqk8mq7aBZg/d11hxGqHf0Ok66qLkazKCiU4b/
	z4wg==
Received: by 10.14.4.201 with SMTP id 49mr8295996eej.0.1347027648772;
	Fri, 07 Sep 2012 07:20:48 -0700 (PDT)
Received: from [192.168.1.14] (AToulouse-651-1-16-21.w92-149.abo.wanadoo.fr.
	[92.149.191.21])
	by mx.google.com with ESMTPS id e42sm13139343eem.8.2012.09.07.07.20.46
	(version=SSLv3 cipher=OTHER); Fri, 07 Sep 2012 07:20:47 -0700 (PDT)
Message-ID: <504A02BD.4000805@linaro.org>
Date: Fri, 07 Sep 2012 16:20:45 +0200
From: Daniel Lezcano <daniel.lezcano@linaro.org>
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:12.0) Gecko/20120430 Thunderbird/12.0.1
MIME-Version: 1.0
To: "Rafael J. Wysocki" <rjw@sisk.pl>
References: <1343164349-28550-1-git-send-email-daniel.lezcano@linaro.org>
	<201209062204.11288.rjw@sisk.pl> <50490920.9070204@linaro.org>
	<201209062318.42874.rjw@sisk.pl>
In-Reply-To: <201209062318.42874.rjw@sisk.pl>
X-Gm-Message-State: ALoCoQkbnOOJEQq3OQMFX4iKswBghDq48ccjNtLslDs27/jZ9X9HONqAPimJWDerkNZbP+Elf5uL
Cc: prarit@redhat.com, xen-devel@lists.xensource.com,
	linaro-dev@lists.linaro.org, Peter Zijlstra <a.p.zijlstra@chello.nl>,
	linux-pm@vger.kernel.org, Frederic Weisbecker <fweisbec@gmail.com>,
	richardcochran@gmail.com, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	linux-acpi@vger.kernel.org, john.stultz@linaro.org,
	Thomas Gleixner <tglx@linutronix.de>, mingo@kernel.org, lenb@kernel.org
Subject: Re: [Xen-devel] CONFIG_NO_HZ + CONFIG_CPU_IDLE freeze the system
 (Was Re: [PATCH] acpi : remove power from acpi_processor_cx structure)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gMDkvMDYvMjAxMiAxMToxOCBQTSwgUmFmYWVsIEouIFd5c29ja2kgd3JvdGU6Cj4gT24gVGh1
cnNkYXksIFNlcHRlbWJlciAwNiwgMjAxMiwgRGFuaWVsIExlemNhbm8gd3JvdGU6Cj4+IE9uIDA5
LzA2LzIwMTIgMTA6MDQgUE0sIFJhZmFlbCBKLiBXeXNvY2tpIHdyb3RlOgo+Pj4gT24gVGh1cnNk
YXksIFNlcHRlbWJlciAwNiwgMjAxMiwgRGFuaWVsIExlemNhbm8gd3JvdGU6Cj4+Pj4gT24gMDkv
MDYvMjAxMiAwOTo1NCBBTSwgRGFuaWVsIExlemNhbm8gd3JvdGU6Cj4+Pj4+IE9uIDA5LzA1LzIw
MTIgMDM6NDEgUE0sIFJhZmFlbCBKLiBXeXNvY2tpIHdyb3RlOgo+Pj4+Pj4gT24gU2F0dXJkYXks
IFNlcHRlbWJlciAwMSwgMjAxMiwgUmFmYWVsIEouIFd5c29ja2kgd3JvdGU6Cj4+Pj4+Pj4gT24g
RnJpZGF5LCBBdWd1c3QgMzEsIDIwMTIsIERhbmllbCBMZXpjYW5vIHdyb3RlOgo+Pj4+Pj4+PiBP
biAwNy8yNC8yMDEyIDExOjA2IFBNLCBLb25yYWQgUnplc3p1dGVrIFdpbGsgd3JvdGU6Cj4+Pj4+
Pj4+PiBPbiBUdWUsIEp1bCAyNCwgMjAxMiBhdCAxMToxMjoyOVBNICswMjAwLCBEYW5pZWwgTGV6
Y2FubyB3cm90ZToKPj4+Pj4+Pj4+PiBSZW1vdmUgdGhlIHBvd2VyIGZpZWxkIGFzIGl0IGlzIG5v
dCB1c2VkLgo+Pj4+Pj4+Pj4+Cj4+Pj4+Pj4+Pj4gU2lnbmVkLW9mZi1ieTogRGFuaWVsIExlemNh
bm8gPGRhbmllbC5sZXpjYW5vQGxpbmFyby5vcmc+Cj4+Pj4+Pj4+Pj4gQ2M6IEtvbnJhZCBSemVz
enV0ZWsgV2lsayA8a29ucmFkLndpbGtAb3JhY2xlLmNvbT4KPj4+Pj4+Pj4+IEFja2VkLgo+Pj4+
Pj4+PiBIaSBSYWZhZWwsCj4+Pj4+Pj4+Cj4+Pj4+Pj4+IEkgZGlkIG5vdCBzZWUgdGhpcyBwYXRj
aCBnb2luZyBpbi4gSXMgaXQgcG9zc2libGUgdG8gbWVyZ2UgaXQgPwo+Pj4+Pj4+IEkgdGhpbmsg
c28uICBJJ2xsIHRha2UgY2FyZSBvZiBpdCB3aGVuIEkgZ2V0IGJhY2sgZnJvbSBMaW51eENvbi9Q
bHVtYmVycyBDb25mLgo+Pj4+Pj4+IChlYXJseSBuZXh0IHdlZWspLgo+Pj4+Pj4gQXBwbGllZCB0
byB0aGUgbGludXgtbmV4dCBicmFuY2ggb2YgdGhlIGxpbnV4LXBtLmdpdCB0cmVlIGFzIHYzLjcg
bWF0ZXJpYWwuCj4+Pj4+IFRoYW5rcyBSYWZhZWwuCj4+Pj4+Cj4+Pj4+PiBBcmUgdGhlcmUgYW55
IG90aGVyIHBhdGNoZXMgeW91IHdhbnQgbWUgdG8gY29uc2lkZXIgZm9yIHYzLjc/Cj4+Pj4+IFll
cyBwbGVhc2UsIEkgaGF2ZSB0aGUgcGVyIGNwdSBsYXRlbmNpZXMgcmVhZHkgdG8gYmUgc3VibWl0
dGVkIGJ1dCBJCj4+Pj4+IHdhbnQgdG8gZG8gZXh0cmEgdGVzdGluZyBiZWZvcmUuIFVuZm9ydHVu
YXRlbHksIHRoZSBsaW51eC1wbS1uZXh0IGhhbmdzCj4+Pj4+IGF0IGJvb3QgdGltZSBvbiBteSBp
bnRlbCBkdWFsIGNvcmUgKG5vdCByZWxhdGVkIHRvIHRoZSBwYXRjaHNldCkuCj4+Pj4+Cj4+Pj4+
IEkgYW0gZ2l0IGJpc2VjdGluZyByaWdodCBub3cuCj4+Pj4KPj4+PiBJIGZvdW5kIHRoZSBjdWxw
cml0LiBUaGlzIGlzIG5vdCByZWxhdGVkIHRvIHRoZSBsaW51eC1wbSB0cmVlIGJ1dCB3aXRoCj4+
Pj4gbmV0LW5leHQuCj4+Pj4gVGhlIGZvbGxvd2luZyBwYXRjaCBpbnRyb2R1Y2VkIHRoZSBpc3N1
ZS4KPj4+Pgo+Pj4+IGNvbW1pdCA2YmRiN2ZlMzEwNDZhYzUwYjQ3ZTgzYzM1Y2Q2YzZiNjE2MGE0
NzVkCj4+Pj4gQXV0aG9yOiBBbWVyaWdvIFdhbmcgPGFtd2FuZ0ByZWRoYXQuY29tPgo+Pj4+IERh
dGU6ICAgRnJpIEF1ZyAxMCAwMToyNDo1MCAyMDEyICswMDAwCj4+Pj4KPj4+PiAgICAgbmV0cG9s
bDogcmUtZW5hYmxlIGlycSBpbiBwb2xsX25hcGkoKQo+Pj4+ICAgIAo+Pj4+ICAgICBuYXBpLT5w
b2xsKCkgbmVlZHMgSVJRIGVuYWJsZWQsIHNvIHdlIGhhdmUgdG8gcmUtZW5hYmxlIElSUSBiZWZv
cmUKPj4+PiAgICAgY2FsbGluZyBpdC4KPj4+PiAgICAKPj4+PiAgICAgQ2M6IERhdmlkIE1pbGxl
ciA8ZGF2ZW1AZGF2ZW1sb2Z0Lm5ldD4KPj4+PiAgICAgU2lnbmVkLW9mZi1ieTogQ29uZyBXYW5n
IDxhbXdhbmdAcmVkaGF0LmNvbT4KPj4+PiAgICAgU2lnbmVkLW9mZi1ieTogRGF2aWQgUy4gTWls
bGVyIDxkYXZlbUBkYXZlbWxvZnQubmV0Pgo+Pj4+Cj4+Pj4gQUZBSUNTLCBpdCBoYXMgYmVlbiBm
aXhlZCBieSBjb21taXQKPj4+PiAwNzJhOWM0ODYwMDQwOWQ3MmFlYjBkNWIyOWZiYjc1ODYxYTA2
NjMxIHdoaWNoIGlzIG5vdCB5ZXQgaW4gbGludXgtcG0tbmV4dC4KPj4+Cj4+PiBJZiBpdCBpcyBw
cmVzZW50IGluIHRoZSBjdXJyZW50IExpbnVzJyB0cmVlLCB5b3UgY2FuIGp1c3QgcHVsbCB0aGlz
IG9uZQo+Pj4gYW5kIG1lcmdlIGxpbnV4LXBtLW5leHQgaW50byBpdC4gIEl0IHNob3VsZCBtZXJn
ZSB3aXRob3V0IGNvbmZsaWN0cy4KPj4KPj4gT2ssIHRoYW5rcy4KPj4KPj4+PiBJIGZhbGwgaW50
byB0aGlzIGlzc3VlIGJlY2F1c2UgTkVUQ09OU09MRSBpcyBzZXQsIGRpc2FibGluZyBpdCBhbGxv
d2VkCj4+Pj4gbWUgdG8gZ28gZnVydGhlci4KPj4+Pgo+Pj4+IFVuZm9ydHVuYXRlbHkgSSBhbSBm
YWNpbmcgdG8gc29tZSByYW5kb20gZnJlZXplIG9uIHRoZSBzeXN0ZW0gd2hpY2gKPj4+PiBzZWVt
cyB0byBiZSByZWxhdGVkIHRvIENPTkZJR19OT19IWj15IGFuZCBDT05GSUdfQ1BVX0lETEU9eS4K
Pj4+Pgo+Pj4+IERpc2FibGluZyBvbmUgb2YgdGhlbSwgbWFrZSB0aGUgZnJlZXplcyB0byBkaXNh
cHBlYXIuCj4+Pj4KPj4+PiBJcyBpdCBhIGtub3duIGlzc3VlID8KPj4+Cj4+PiBXZWxsLCB0aGVy
ZSBhcmUgc3lzdGVtcyBoYXZpbmcgcHJvYmxlbXMgd2l0aCB0aGlzIGNvbmZpZ3VyYXRpb24sIGJ1
dCB0aGV5Cj4+PiBzaG91bGQgYmUgZXhjZXB0aW9uYWwuICBXaGF0IHN5c3RlbSBpcyB0aGF0Pwo+
Pgo+PiBJdCBpcyBhIGxhcHRvcCBUNjFwIHdpdGggYSBDb3JlIDIgRHVvIFQ5NTAwLiBOb3RoaW5n
IGV4Y2VwdGlvbmFsIEkKPj4gYmVsaWV2ZS4gTWF5YmUgc29tZW9uZSBnb3QgdGhlIHNhbWUgaXNz
dWUgPwo+IAo+IElzIGl0IGEgcmVncmVzc2lvbiBmb3IgeW91PwoKWWVzLCBJIHRoaW5rIHNvLiBU
aGUgaXNzdWUgYXBwZWFycyBiZXR3ZWVuIHYzLjUgYW5kIHYzLjYtcmMxLgoKSXQgaXMgbm90IGVh
c3kgdG8gcmVwcm9kdWNlIGJ1dCBhZnRlciB0YWtpbmcgc29tZSB0aW1lIHRvIGRpZywgaXQgc2Vl
bXMKdG8gYXBwZWFyIHdpdGggdGhpcyBjb21taXQ6CgoxZTc1ZmE4YmU5ZmI2MWUxYWY0NmI1YjNi
MTc2MzQ3YTRjOTU4Y2ExIGlzIHRoZSBmaXJzdCBiYWQgY29tbWl0CmNvbW1pdCAxZTc1ZmE4YmU5
ZmI2MWUxYWY0NmI1YjNiMTc2MzQ3YTRjOTU4Y2ExCkF1dGhvcjogSm9obiBTdHVsdHogPGpvaG4u
c3R1bHR6QGxpbmFyby5vcmc+CkRhdGU6ICAgRnJpIEp1bCAxMyAwMToyMTo1MyAyMDEyIC0wNDAw
CgogICAgdGltZTogQ29uZGVuc2UgdGltZWtlZXBlci54dGltZSBpbnRvIHh0aW1lX3NlYwoKICAg
IFRoZSB0aW1la2VlcGVyIHN0cnVjdCBoYXMgYSB4dGltZV9uc2VjLCB3aGljaCBrZWVwcyB0aGUK
ICAgIHN1Yi1uYW5vc2Vjb25kIHJlbWFpbmRlci4gIFRoaXMgZW5kcyB1cCBiZWluZyBzb21ld2hh
dAogICAgZHVwbGljYXRpdmUgb2YgdGhlIHRpbWVrZWVwZXIueHRpbWUudHZfbnNlYyB2YWx1ZSwg
YW5kIHdlCiAgICBoYXZlIHRvIGRvIGV4dHJhIHdvcmsgdG8ga2VlcCB0aGVtIGFwYXJ0LCBjb3B5
aW5nIHRoZSBmdWxsCiAgICBuc2VjIHBvcnRpb24gb3V0IGFuZCBiYWNrIGluIG92ZXIgYW5kIG92
ZXIuCgogICAgVGhpcyBwYXRjaCBzaW1wbGlmaWVzIHNvbWUgb2YgdGhlIGxvZ2ljIGJ5IHRha2lu
ZyB0aGUgdGltZWtlZXBlcgogICAgeHRpbWUgdmFsdWUgYW5kIHNwbGl0dGluZyBpdCBpbnRvIHRp
bWVrZWVwZXIueHRpbWVfc2VjIGFuZAogICAgcmV1c2VzIHRoZSB0aW1la2VlcGVyLnh0aW1lX25z
ZWMgZm9yIHRoZSBzdWItc2Vjb25kIHBvcnRpb24KICAgIChzdG9yZWQgaW4gaGlnaGVyIHJlcyBz
aGlmdGVkIG5hbm9zZWNvbmRzKS4KCiAgICBUaGlzIHNpbXBsaWZpZXMgc29tZSBvZiB0aGUgYWNj
dW11bGF0aW9uIGxvZ2ljLiBBbmQgd2lsbAogICAgYWxsb3cgZm9yIG1vcmUgYWNjdXJhdGUgdGlt
ZWtlZXBpbmcgb25jZSB0aGUgdnN5c2NhbGwgY29kZQogICAgaXMgdXBkYXRlZCB0byB1c2UgdGhl
IHNoaWZ0ZWQgbmFub3NlY29uZCByZW1haW5kZXIuCgogICAgU2lnbmVkLW9mZi1ieTogSm9obiBT
dHVsdHogPGpvaG4uc3R1bHR6QGxpbmFyby5vcmc+CiAgICBSZXZpZXdlZC1ieTogSW5nbyBNb2xu
YXIgPG1pbmdvQGtlcm5lbC5vcmc+CiAgICBDYzogUGV0ZXIgWmlqbHN0cmEgPGEucC56aWpsc3Ry
YUBjaGVsbG8ubmw+CiAgICBDYzogUmljaGFyZCBDb2NocmFuIDxyaWNoYXJkY29jaHJhbkBnbWFp
bC5jb20+CiAgICBDYzogUHJhcml0IEJoYXJnYXZhIDxwcmFyaXRAcmVkaGF0LmNvbT4KICAgIExp
bms6Cmh0dHA6Ly9sa21sLmtlcm5lbC5vcmcvci8xMzQyMTU2OTE3LTI1MDkyLTUtZ2l0LXNlbmQt
ZW1haWwtam9obi5zdHVsdHpAbGluYXJvLm9yZwogICAgU2lnbmVkLW9mZi1ieTogVGhvbWFzIEds
ZWl4bmVyIDx0Z2x4QGxpbnV0cm9uaXguZGU+Cgo6MDQwMDAwIDA0MDAwMCA0ZDY1NDFhYzFmNjA3
NWQ3YWRlZTFlZWY0OTRiMzFhMGNiZGEwOTM0CmRjNTcwOGJjNzM4YWY2OTVmMDkyYmY4MjI4MDli
MTNhMWRhMTA0YjYgTQlrZXJuZWwKCkhvdyB0byByZXByb2R1Y2U6IHdpdGggYSBsYXB0b3AgVDYx
cCwgd2l0aCBhIENvcmUgMiBEdW8uIEkgYm9vdCB0aGUKa2VybmVsIGluIGJ1c3lib3ggYW5kIHdh
aXQgc29tZSBtaW51dGVzIGJlZm9yZSB3cml0aW5nIHNvbWV0aGluZyBpbiB0aGUKY29uc29sZS4g
QXQgdGhpcyBtb21lbnQsIG5vdGhpbmcgYXBwZWFycyB0byB0aGUgY29uc29sZSBidXQgdGhlCmNo
YXJhY3RlcnMgYXJlIGVjaG8nZWQgc2V2ZXJhbCBzZWNvbmRzIGxhdGVyIChjb3VsZCBiZSAxLCA1
LCBvciAxMCBzZWNzCm9yIG1vcmUpLgoKVGhhdCBoYXBwZW5zIHdoZW4gQ09ORklHX0NQVV9JRExF
IGFuZCBDT05GSUdfTk9fSFogYXJlIHNldC4gRGlzYWJsaW5nCm9uZSBvZiB0aGVtLCB0aGUgaXNz
dWUgZG9lcyBub3QgYXBwZWFyLgoKVGhhbmtzCiAgLS0gRGFuaWVsCgotLSAKIDxodHRwOi8vd3d3
LmxpbmFyby5vcmcvPiBMaW5hcm8ub3JnIOKUgiBPcGVuIHNvdXJjZSBzb2Z0d2FyZSBmb3IgQVJN
IFNvQ3MKCkZvbGxvdyBMaW5hcm86ICA8aHR0cDovL3d3dy5mYWNlYm9vay5jb20vcGFnZXMvTGlu
YXJvPiBGYWNlYm9vayB8CjxodHRwOi8vdHdpdHRlci5jb20vIyEvbGluYXJvb3JnPiBUd2l0dGVy
IHwKPGh0dHA6Ly93d3cubGluYXJvLm9yZy9saW5hcm8tYmxvZy8+IEJsb2cKCgpfX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpYZW4tZGV2ZWwgbWFpbGluZyBs
aXN0Clhlbi1kZXZlbEBsaXN0cy54ZW4ub3JnCmh0dHA6Ly9saXN0cy54ZW4ub3JnL3hlbi1kZXZl
bAo=

From xen-devel-bounces@lists.xen.org Fri Sep 07 14:21:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Sep 2012 14:21:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9zQS-00080S-Ua; Fri, 07 Sep 2012 14:20:52 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <daniel.lezcano@linaro.org>) id 1T9zQR-00080N-GE
	for xen-devel@lists.xensource.com; Fri, 07 Sep 2012 14:20:51 +0000
Received: from [85.158.138.51:42812] by server-5.bemta-3.messagelabs.com id
	B1/88-13133-2C20A405; Fri, 07 Sep 2012 14:20:50 +0000
X-Env-Sender: daniel.lezcano@linaro.org
X-Msg-Ref: server-6.tower-174.messagelabs.com!1347027649!21268413!1
X-Originating-IP: [209.85.215.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29391 invoked from network); 7 Sep 2012 14:20:49 -0000
Received: from mail-ey0-f171.google.com (HELO mail-ey0-f171.google.com)
	(209.85.215.171)
	by server-6.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Sep 2012 14:20:49 -0000
Received: by eaah11 with SMTP id h11so997518eaa.30
	for <xen-devel@lists.xensource.com>;
	Fri, 07 Sep 2012 07:20:49 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=message-id:date:from:user-agent:mime-version:to:cc:subject
	:references:in-reply-to:content-type:content-transfer-encoding
	:x-gm-message-state;
	bh=TI1YKWf/K7YFuHlU+fg5fgKOujmInhyS4SEAPu+Hgzs=;
	b=mPjJ60fhGOlq6uJec8Cz2cIyPNFs9/JStEtDoHch6pV0VfzVJpj7C4wTKRDqTS3QOY
	KpVvR78Et2WIq+e4Vhkcial/P86/0BcVHwwk7rd9W8jcFrtm0tFWSn8aELBLrx0Iw2RI
	1RcSMuZ3O3PDvLdWT23xUsVhnaE2hvqMnHSOoCYKzpCxvRW7a4/XwBm3qSUbPPuMmCTv
	UX1gQVTeR8zrh+3DhLAuw6c4LRrfums0qfs0J6Rf57P9l1pVyHTpyzMa0YPytXWzBxwv
	+af96P6dh0XPayZd45pmse3MoasrvYLqk8mq7aBZg/d11hxGqHf0Ok66qLkazKCiU4b/
	z4wg==
Received: by 10.14.4.201 with SMTP id 49mr8295996eej.0.1347027648772;
	Fri, 07 Sep 2012 07:20:48 -0700 (PDT)
Received: from [192.168.1.14] (AToulouse-651-1-16-21.w92-149.abo.wanadoo.fr.
	[92.149.191.21])
	by mx.google.com with ESMTPS id e42sm13139343eem.8.2012.09.07.07.20.46
	(version=SSLv3 cipher=OTHER); Fri, 07 Sep 2012 07:20:47 -0700 (PDT)
Message-ID: <504A02BD.4000805@linaro.org>
Date: Fri, 07 Sep 2012 16:20:45 +0200
From: Daniel Lezcano <daniel.lezcano@linaro.org>
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:12.0) Gecko/20120430 Thunderbird/12.0.1
MIME-Version: 1.0
To: "Rafael J. Wysocki" <rjw@sisk.pl>
References: <1343164349-28550-1-git-send-email-daniel.lezcano@linaro.org>
	<201209062204.11288.rjw@sisk.pl> <50490920.9070204@linaro.org>
	<201209062318.42874.rjw@sisk.pl>
In-Reply-To: <201209062318.42874.rjw@sisk.pl>
X-Gm-Message-State: ALoCoQkbnOOJEQq3OQMFX4iKswBghDq48ccjNtLslDs27/jZ9X9HONqAPimJWDerkNZbP+Elf5uL
Cc: prarit@redhat.com, xen-devel@lists.xensource.com,
	linaro-dev@lists.linaro.org, Peter Zijlstra <a.p.zijlstra@chello.nl>,
	linux-pm@vger.kernel.org, Frederic Weisbecker <fweisbec@gmail.com>,
	richardcochran@gmail.com, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	linux-acpi@vger.kernel.org, john.stultz@linaro.org,
	Thomas Gleixner <tglx@linutronix.de>, mingo@kernel.org, lenb@kernel.org
Subject: Re: [Xen-devel] CONFIG_NO_HZ + CONFIG_CPU_IDLE freeze the system
 (Was Re: [PATCH] acpi : remove power from acpi_processor_cx structure)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gMDkvMDYvMjAxMiAxMToxOCBQTSwgUmFmYWVsIEouIFd5c29ja2kgd3JvdGU6Cj4gT24gVGh1
cnNkYXksIFNlcHRlbWJlciAwNiwgMjAxMiwgRGFuaWVsIExlemNhbm8gd3JvdGU6Cj4+IE9uIDA5
LzA2LzIwMTIgMTA6MDQgUE0sIFJhZmFlbCBKLiBXeXNvY2tpIHdyb3RlOgo+Pj4gT24gVGh1cnNk
YXksIFNlcHRlbWJlciAwNiwgMjAxMiwgRGFuaWVsIExlemNhbm8gd3JvdGU6Cj4+Pj4gT24gMDkv
MDYvMjAxMiAwOTo1NCBBTSwgRGFuaWVsIExlemNhbm8gd3JvdGU6Cj4+Pj4+IE9uIDA5LzA1LzIw
MTIgMDM6NDEgUE0sIFJhZmFlbCBKLiBXeXNvY2tpIHdyb3RlOgo+Pj4+Pj4gT24gU2F0dXJkYXks
IFNlcHRlbWJlciAwMSwgMjAxMiwgUmFmYWVsIEouIFd5c29ja2kgd3JvdGU6Cj4+Pj4+Pj4gT24g
RnJpZGF5LCBBdWd1c3QgMzEsIDIwMTIsIERhbmllbCBMZXpjYW5vIHdyb3RlOgo+Pj4+Pj4+PiBP
biAwNy8yNC8yMDEyIDExOjA2IFBNLCBLb25yYWQgUnplc3p1dGVrIFdpbGsgd3JvdGU6Cj4+Pj4+
Pj4+PiBPbiBUdWUsIEp1bCAyNCwgMjAxMiBhdCAxMToxMjoyOVBNICswMjAwLCBEYW5pZWwgTGV6
Y2FubyB3cm90ZToKPj4+Pj4+Pj4+PiBSZW1vdmUgdGhlIHBvd2VyIGZpZWxkIGFzIGl0IGlzIG5v
dCB1c2VkLgo+Pj4+Pj4+Pj4+Cj4+Pj4+Pj4+Pj4gU2lnbmVkLW9mZi1ieTogRGFuaWVsIExlemNh
bm8gPGRhbmllbC5sZXpjYW5vQGxpbmFyby5vcmc+Cj4+Pj4+Pj4+Pj4gQ2M6IEtvbnJhZCBSemVz
enV0ZWsgV2lsayA8a29ucmFkLndpbGtAb3JhY2xlLmNvbT4KPj4+Pj4+Pj4+IEFja2VkLgo+Pj4+
Pj4+PiBIaSBSYWZhZWwsCj4+Pj4+Pj4+Cj4+Pj4+Pj4+IEkgZGlkIG5vdCBzZWUgdGhpcyBwYXRj
aCBnb2luZyBpbi4gSXMgaXQgcG9zc2libGUgdG8gbWVyZ2UgaXQgPwo+Pj4+Pj4+IEkgdGhpbmsg
c28uICBJJ2xsIHRha2UgY2FyZSBvZiBpdCB3aGVuIEkgZ2V0IGJhY2sgZnJvbSBMaW51eENvbi9Q
bHVtYmVycyBDb25mLgo+Pj4+Pj4+IChlYXJseSBuZXh0IHdlZWspLgo+Pj4+Pj4gQXBwbGllZCB0
byB0aGUgbGludXgtbmV4dCBicmFuY2ggb2YgdGhlIGxpbnV4LXBtLmdpdCB0cmVlIGFzIHYzLjcg
bWF0ZXJpYWwuCj4+Pj4+IFRoYW5rcyBSYWZhZWwuCj4+Pj4+Cj4+Pj4+PiBBcmUgdGhlcmUgYW55
IG90aGVyIHBhdGNoZXMgeW91IHdhbnQgbWUgdG8gY29uc2lkZXIgZm9yIHYzLjc/Cj4+Pj4+IFll
cyBwbGVhc2UsIEkgaGF2ZSB0aGUgcGVyIGNwdSBsYXRlbmNpZXMgcmVhZHkgdG8gYmUgc3VibWl0
dGVkIGJ1dCBJCj4+Pj4+IHdhbnQgdG8gZG8gZXh0cmEgdGVzdGluZyBiZWZvcmUuIFVuZm9ydHVu
YXRlbHksIHRoZSBsaW51eC1wbS1uZXh0IGhhbmdzCj4+Pj4+IGF0IGJvb3QgdGltZSBvbiBteSBp
bnRlbCBkdWFsIGNvcmUgKG5vdCByZWxhdGVkIHRvIHRoZSBwYXRjaHNldCkuCj4+Pj4+Cj4+Pj4+
IEkgYW0gZ2l0IGJpc2VjdGluZyByaWdodCBub3cuCj4+Pj4KPj4+PiBJIGZvdW5kIHRoZSBjdWxw
cml0LiBUaGlzIGlzIG5vdCByZWxhdGVkIHRvIHRoZSBsaW51eC1wbSB0cmVlIGJ1dCB3aXRoCj4+
Pj4gbmV0LW5leHQuCj4+Pj4gVGhlIGZvbGxvd2luZyBwYXRjaCBpbnRyb2R1Y2VkIHRoZSBpc3N1
ZS4KPj4+Pgo+Pj4+IGNvbW1pdCA2YmRiN2ZlMzEwNDZhYzUwYjQ3ZTgzYzM1Y2Q2YzZiNjE2MGE0
NzVkCj4+Pj4gQXV0aG9yOiBBbWVyaWdvIFdhbmcgPGFtd2FuZ0ByZWRoYXQuY29tPgo+Pj4+IERh
dGU6ICAgRnJpIEF1ZyAxMCAwMToyNDo1MCAyMDEyICswMDAwCj4+Pj4KPj4+PiAgICAgbmV0cG9s
bDogcmUtZW5hYmxlIGlycSBpbiBwb2xsX25hcGkoKQo+Pj4+ICAgIAo+Pj4+ICAgICBuYXBpLT5w
b2xsKCkgbmVlZHMgSVJRIGVuYWJsZWQsIHNvIHdlIGhhdmUgdG8gcmUtZW5hYmxlIElSUSBiZWZv
cmUKPj4+PiAgICAgY2FsbGluZyBpdC4KPj4+PiAgICAKPj4+PiAgICAgQ2M6IERhdmlkIE1pbGxl
ciA8ZGF2ZW1AZGF2ZW1sb2Z0Lm5ldD4KPj4+PiAgICAgU2lnbmVkLW9mZi1ieTogQ29uZyBXYW5n
IDxhbXdhbmdAcmVkaGF0LmNvbT4KPj4+PiAgICAgU2lnbmVkLW9mZi1ieTogRGF2aWQgUy4gTWls
bGVyIDxkYXZlbUBkYXZlbWxvZnQubmV0Pgo+Pj4+Cj4+Pj4gQUZBSUNTLCBpdCBoYXMgYmVlbiBm
aXhlZCBieSBjb21taXQKPj4+PiAwNzJhOWM0ODYwMDQwOWQ3MmFlYjBkNWIyOWZiYjc1ODYxYTA2
NjMxIHdoaWNoIGlzIG5vdCB5ZXQgaW4gbGludXgtcG0tbmV4dC4KPj4+Cj4+PiBJZiBpdCBpcyBw
cmVzZW50IGluIHRoZSBjdXJyZW50IExpbnVzJyB0cmVlLCB5b3UgY2FuIGp1c3QgcHVsbCB0aGlz
IG9uZQo+Pj4gYW5kIG1lcmdlIGxpbnV4LXBtLW5leHQgaW50byBpdC4gIEl0IHNob3VsZCBtZXJn
ZSB3aXRob3V0IGNvbmZsaWN0cy4KPj4KPj4gT2ssIHRoYW5rcy4KPj4KPj4+PiBJIGZhbGwgaW50
byB0aGlzIGlzc3VlIGJlY2F1c2UgTkVUQ09OU09MRSBpcyBzZXQsIGRpc2FibGluZyBpdCBhbGxv
d2VkCj4+Pj4gbWUgdG8gZ28gZnVydGhlci4KPj4+Pgo+Pj4+IFVuZm9ydHVuYXRlbHkgSSBhbSBm
YWNpbmcgdG8gc29tZSByYW5kb20gZnJlZXplIG9uIHRoZSBzeXN0ZW0gd2hpY2gKPj4+PiBzZWVt
cyB0byBiZSByZWxhdGVkIHRvIENPTkZJR19OT19IWj15IGFuZCBDT05GSUdfQ1BVX0lETEU9eS4K
Pj4+Pgo+Pj4+IERpc2FibGluZyBvbmUgb2YgdGhlbSwgbWFrZSB0aGUgZnJlZXplcyB0byBkaXNh
cHBlYXIuCj4+Pj4KPj4+PiBJcyBpdCBhIGtub3duIGlzc3VlID8KPj4+Cj4+PiBXZWxsLCB0aGVy
ZSBhcmUgc3lzdGVtcyBoYXZpbmcgcHJvYmxlbXMgd2l0aCB0aGlzIGNvbmZpZ3VyYXRpb24sIGJ1
dCB0aGV5Cj4+PiBzaG91bGQgYmUgZXhjZXB0aW9uYWwuICBXaGF0IHN5c3RlbSBpcyB0aGF0Pwo+
Pgo+PiBJdCBpcyBhIGxhcHRvcCBUNjFwIHdpdGggYSBDb3JlIDIgRHVvIFQ5NTAwLiBOb3RoaW5n
IGV4Y2VwdGlvbmFsIEkKPj4gYmVsaWV2ZS4gTWF5YmUgc29tZW9uZSBnb3QgdGhlIHNhbWUgaXNz
dWUgPwo+IAo+IElzIGl0IGEgcmVncmVzc2lvbiBmb3IgeW91PwoKWWVzLCBJIHRoaW5rIHNvLiBU
aGUgaXNzdWUgYXBwZWFycyBiZXR3ZWVuIHYzLjUgYW5kIHYzLjYtcmMxLgoKSXQgaXMgbm90IGVh
c3kgdG8gcmVwcm9kdWNlIGJ1dCBhZnRlciB0YWtpbmcgc29tZSB0aW1lIHRvIGRpZywgaXQgc2Vl
bXMKdG8gYXBwZWFyIHdpdGggdGhpcyBjb21taXQ6CgoxZTc1ZmE4YmU5ZmI2MWUxYWY0NmI1YjNi
MTc2MzQ3YTRjOTU4Y2ExIGlzIHRoZSBmaXJzdCBiYWQgY29tbWl0CmNvbW1pdCAxZTc1ZmE4YmU5
ZmI2MWUxYWY0NmI1YjNiMTc2MzQ3YTRjOTU4Y2ExCkF1dGhvcjogSm9obiBTdHVsdHogPGpvaG4u
c3R1bHR6QGxpbmFyby5vcmc+CkRhdGU6ICAgRnJpIEp1bCAxMyAwMToyMTo1MyAyMDEyIC0wNDAw
CgogICAgdGltZTogQ29uZGVuc2UgdGltZWtlZXBlci54dGltZSBpbnRvIHh0aW1lX3NlYwoKICAg
IFRoZSB0aW1la2VlcGVyIHN0cnVjdCBoYXMgYSB4dGltZV9uc2VjLCB3aGljaCBrZWVwcyB0aGUK
ICAgIHN1Yi1uYW5vc2Vjb25kIHJlbWFpbmRlci4gIFRoaXMgZW5kcyB1cCBiZWluZyBzb21ld2hh
dAogICAgZHVwbGljYXRpdmUgb2YgdGhlIHRpbWVrZWVwZXIueHRpbWUudHZfbnNlYyB2YWx1ZSwg
YW5kIHdlCiAgICBoYXZlIHRvIGRvIGV4dHJhIHdvcmsgdG8ga2VlcCB0aGVtIGFwYXJ0LCBjb3B5
aW5nIHRoZSBmdWxsCiAgICBuc2VjIHBvcnRpb24gb3V0IGFuZCBiYWNrIGluIG92ZXIgYW5kIG92
ZXIuCgogICAgVGhpcyBwYXRjaCBzaW1wbGlmaWVzIHNvbWUgb2YgdGhlIGxvZ2ljIGJ5IHRha2lu
ZyB0aGUgdGltZWtlZXBlcgogICAgeHRpbWUgdmFsdWUgYW5kIHNwbGl0dGluZyBpdCBpbnRvIHRp
bWVrZWVwZXIueHRpbWVfc2VjIGFuZAogICAgcmV1c2VzIHRoZSB0aW1la2VlcGVyLnh0aW1lX25z
ZWMgZm9yIHRoZSBzdWItc2Vjb25kIHBvcnRpb24KICAgIChzdG9yZWQgaW4gaGlnaGVyIHJlcyBz
aGlmdGVkIG5hbm9zZWNvbmRzKS4KCiAgICBUaGlzIHNpbXBsaWZpZXMgc29tZSBvZiB0aGUgYWNj
dW11bGF0aW9uIGxvZ2ljLiBBbmQgd2lsbAogICAgYWxsb3cgZm9yIG1vcmUgYWNjdXJhdGUgdGlt
ZWtlZXBpbmcgb25jZSB0aGUgdnN5c2NhbGwgY29kZQogICAgaXMgdXBkYXRlZCB0byB1c2UgdGhl
IHNoaWZ0ZWQgbmFub3NlY29uZCByZW1haW5kZXIuCgogICAgU2lnbmVkLW9mZi1ieTogSm9obiBT
dHVsdHogPGpvaG4uc3R1bHR6QGxpbmFyby5vcmc+CiAgICBSZXZpZXdlZC1ieTogSW5nbyBNb2xu
YXIgPG1pbmdvQGtlcm5lbC5vcmc+CiAgICBDYzogUGV0ZXIgWmlqbHN0cmEgPGEucC56aWpsc3Ry
YUBjaGVsbG8ubmw+CiAgICBDYzogUmljaGFyZCBDb2NocmFuIDxyaWNoYXJkY29jaHJhbkBnbWFp
bC5jb20+CiAgICBDYzogUHJhcml0IEJoYXJnYXZhIDxwcmFyaXRAcmVkaGF0LmNvbT4KICAgIExp
bms6Cmh0dHA6Ly9sa21sLmtlcm5lbC5vcmcvci8xMzQyMTU2OTE3LTI1MDkyLTUtZ2l0LXNlbmQt
ZW1haWwtam9obi5zdHVsdHpAbGluYXJvLm9yZwogICAgU2lnbmVkLW9mZi1ieTogVGhvbWFzIEds
ZWl4bmVyIDx0Z2x4QGxpbnV0cm9uaXguZGU+Cgo6MDQwMDAwIDA0MDAwMCA0ZDY1NDFhYzFmNjA3
NWQ3YWRlZTFlZWY0OTRiMzFhMGNiZGEwOTM0CmRjNTcwOGJjNzM4YWY2OTVmMDkyYmY4MjI4MDli
MTNhMWRhMTA0YjYgTQlrZXJuZWwKCkhvdyB0byByZXByb2R1Y2U6IHdpdGggYSBsYXB0b3AgVDYx
cCwgd2l0aCBhIENvcmUgMiBEdW8uIEkgYm9vdCB0aGUKa2VybmVsIGluIGJ1c3lib3ggYW5kIHdh
aXQgc29tZSBtaW51dGVzIGJlZm9yZSB3cml0aW5nIHNvbWV0aGluZyBpbiB0aGUKY29uc29sZS4g
QXQgdGhpcyBtb21lbnQsIG5vdGhpbmcgYXBwZWFycyB0byB0aGUgY29uc29sZSBidXQgdGhlCmNo
YXJhY3RlcnMgYXJlIGVjaG8nZWQgc2V2ZXJhbCBzZWNvbmRzIGxhdGVyIChjb3VsZCBiZSAxLCA1
LCBvciAxMCBzZWNzCm9yIG1vcmUpLgoKVGhhdCBoYXBwZW5zIHdoZW4gQ09ORklHX0NQVV9JRExF
IGFuZCBDT05GSUdfTk9fSFogYXJlIHNldC4gRGlzYWJsaW5nCm9uZSBvZiB0aGVtLCB0aGUgaXNz
dWUgZG9lcyBub3QgYXBwZWFyLgoKVGhhbmtzCiAgLS0gRGFuaWVsCgotLSAKIDxodHRwOi8vd3d3
LmxpbmFyby5vcmcvPiBMaW5hcm8ub3JnIOKUgiBPcGVuIHNvdXJjZSBzb2Z0d2FyZSBmb3IgQVJN
IFNvQ3MKCkZvbGxvdyBMaW5hcm86ICA8aHR0cDovL3d3dy5mYWNlYm9vay5jb20vcGFnZXMvTGlu
YXJvPiBGYWNlYm9vayB8CjxodHRwOi8vdHdpdHRlci5jb20vIyEvbGluYXJvb3JnPiBUd2l0dGVy
IHwKPGh0dHA6Ly93d3cubGluYXJvLm9yZy9saW5hcm8tYmxvZy8+IEJsb2cKCgpfX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpYZW4tZGV2ZWwgbWFpbGluZyBs
aXN0Clhlbi1kZXZlbEBsaXN0cy54ZW4ub3JnCmh0dHA6Ly9saXN0cy54ZW4ub3JnL3hlbi1kZXZl
bAo=

From xen-devel-bounces@lists.xen.org Fri Sep 07 14:22:31 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Sep 2012 14:22: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 1T9zRp-00084P-DU; Fri, 07 Sep 2012 14:22:17 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ketuzsezr@gmail.com>) id 1T9zRn-000842-GE
	for xen-devel@lists.xen.org; Fri, 07 Sep 2012 14:22:15 +0000
X-Env-Sender: ketuzsezr@gmail.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1347027728!8790633!1
X-Originating-IP: [209.85.216.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1459 invoked from network); 7 Sep 2012 14:22:09 -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;
	7 Sep 2012 14:22:09 -0000
Received: by qcab12 with SMTP id b12so1845445qca.32
	for <xen-devel@lists.xen.org>; Fri, 07 Sep 2012 07:22:08 -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=0ut+k2O2SfEjCD3adDk1DZuwpH1x/lP5RXRpNyPmDc0=;
	b=E2iQ1b2TZ+pnc548liLEjAXoRgfA3t7pPOtFlVKWoWgyyOWngpQuB28nk+NQNq4i5b
	VESqsWE0xUteB+EIRIrRgh7aE2FngKT+5655wAokG3QcPIymSZ3XUyD10fOkDNJElGMb
	G+G4pppMV/P5eSA3dt1lj4Ab0cEK3P3uV5b/YbNNMrTW9fR/nTRdMLcIZIHbjUsPS46y
	oCAtEU/cV8i6ywHP6kcGaCq0oQ7Jy7F2Knr13UxJJK8ceG6Z1DI+0qX7eUGsJRPyNifg
	+ARJyTm5LBbHAsabpr5A2ZnGjUnAtnB4cG7U/06iZDU7vKqWEOROwQX+A/RxSVv0yLZ+
	Huqw==
Received: by 10.224.184.72 with SMTP id cj8mr7978531qab.11.1347027728124;
	Fri, 07 Sep 2012 07:22:08 -0700 (PDT)
Received: from phenom.dumpdata.com
	(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 o10sm2440514qaj.4.2012.09.07.07.22.06
	(version=TLSv1/SSLv3 cipher=OTHER);
	Fri, 07 Sep 2012 07:22:07 -0700 (PDT)
Date: Fri, 7 Sep 2012 10:11:30 -0400
From: Konrad Rzeszutek Wilk <konrad@kernel.org>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20120907141129.GA2763@phenom.dumpdata.com>
References: <20120802160403.02de484e@mantra.us.oracle.com>
	<20120803133001.GA13750@andromeda.dapyr.net>
	<501BF44602000078000928B4@nat28.tlf.novell.com>
	<CAPbh3rsXaqQS9WQQmJ2uQ46LZdyFzkbSodUabGDAyFS+qTEwUg@mail.gmail.com>
	<5028CEE70200007800094623@nat28.tlf.novell.com>
	<50446B5402000078000981F4@nat28.tlf.novell.com>
	<20120906210323.GA303@phenom.dumpdata.com>
	<5049D4100200007800099A91@nat28.tlf.novell.com>
	<20120907133947.GD2870@phenom.dumpdata.com>
	<504A1C1C0200007800099D64@nat28.tlf.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <504A1C1C0200007800099D64@nat28.tlf.novell.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: konrad@darnok.org, xen-devel <xen-devel@lists.xen.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] Ping: Re: [PATCH] Boot PV guests with more than
 128GB (v2) for 3.7
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Sep 07, 2012 at 03:09:00PM +0100, Jan Beulich wrote:
> >>> On 07.09.12 at 15:39, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
> > On Fri, Sep 07, 2012 at 10:01:36AM +0100, Jan Beulich wrote:
> >> that I'm asking, I just know that I happen to fall into this trap
> >> once in a while myself), did you indeed build and install the
> > 
> > I know. I did double check - as I couldn't install wholesale the
> > new RPM (owner of the box needed the old version of it), instead
> > I did this bit of hack:
> > 
> > xend stop
> > cd /konrad
> > rpmcpio xen-*konrad* | cpio -id
> > tar -czvf /xen.orig.tgz /usr/lib64/*xen*
> > rm -Rf /usr/lib64/*xen*
> 
> So here you removed the old libraries. But where did you drop in
> the new ones? Did you just forget to list this here?

There was no need since the LD_LIBRARY_PATH did the over-write.
This was to make double sure that the old libs wouldn't be called.

> 
> > mv /usr/lib/python2.4/site-packages/xen /usr/lib/python2.4/site-packages/xen.old
> > ln -s /konrad/usr/lib/python2.4/site-packages/xen  /usr/lib/python2.4/site-packages/xen 
> > export PATH=/konrad/usr/bin:/konrad/usr/sbin:$PATH
> > export LD_LIBRARY_PATH=/konrad/usr/lib64
> > 
> > xend start
> > xm create /konrad/test.xm
> 
> Jan
> 
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 07 14:22:31 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Sep 2012 14:22: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 1T9zRp-00084P-DU; Fri, 07 Sep 2012 14:22:17 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ketuzsezr@gmail.com>) id 1T9zRn-000842-GE
	for xen-devel@lists.xen.org; Fri, 07 Sep 2012 14:22:15 +0000
X-Env-Sender: ketuzsezr@gmail.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1347027728!8790633!1
X-Originating-IP: [209.85.216.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1459 invoked from network); 7 Sep 2012 14:22:09 -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;
	7 Sep 2012 14:22:09 -0000
Received: by qcab12 with SMTP id b12so1845445qca.32
	for <xen-devel@lists.xen.org>; Fri, 07 Sep 2012 07:22:08 -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=0ut+k2O2SfEjCD3adDk1DZuwpH1x/lP5RXRpNyPmDc0=;
	b=E2iQ1b2TZ+pnc548liLEjAXoRgfA3t7pPOtFlVKWoWgyyOWngpQuB28nk+NQNq4i5b
	VESqsWE0xUteB+EIRIrRgh7aE2FngKT+5655wAokG3QcPIymSZ3XUyD10fOkDNJElGMb
	G+G4pppMV/P5eSA3dt1lj4Ab0cEK3P3uV5b/YbNNMrTW9fR/nTRdMLcIZIHbjUsPS46y
	oCAtEU/cV8i6ywHP6kcGaCq0oQ7Jy7F2Knr13UxJJK8ceG6Z1DI+0qX7eUGsJRPyNifg
	+ARJyTm5LBbHAsabpr5A2ZnGjUnAtnB4cG7U/06iZDU7vKqWEOROwQX+A/RxSVv0yLZ+
	Huqw==
Received: by 10.224.184.72 with SMTP id cj8mr7978531qab.11.1347027728124;
	Fri, 07 Sep 2012 07:22:08 -0700 (PDT)
Received: from phenom.dumpdata.com
	(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 o10sm2440514qaj.4.2012.09.07.07.22.06
	(version=TLSv1/SSLv3 cipher=OTHER);
	Fri, 07 Sep 2012 07:22:07 -0700 (PDT)
Date: Fri, 7 Sep 2012 10:11:30 -0400
From: Konrad Rzeszutek Wilk <konrad@kernel.org>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20120907141129.GA2763@phenom.dumpdata.com>
References: <20120802160403.02de484e@mantra.us.oracle.com>
	<20120803133001.GA13750@andromeda.dapyr.net>
	<501BF44602000078000928B4@nat28.tlf.novell.com>
	<CAPbh3rsXaqQS9WQQmJ2uQ46LZdyFzkbSodUabGDAyFS+qTEwUg@mail.gmail.com>
	<5028CEE70200007800094623@nat28.tlf.novell.com>
	<50446B5402000078000981F4@nat28.tlf.novell.com>
	<20120906210323.GA303@phenom.dumpdata.com>
	<5049D4100200007800099A91@nat28.tlf.novell.com>
	<20120907133947.GD2870@phenom.dumpdata.com>
	<504A1C1C0200007800099D64@nat28.tlf.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <504A1C1C0200007800099D64@nat28.tlf.novell.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: konrad@darnok.org, xen-devel <xen-devel@lists.xen.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] Ping: Re: [PATCH] Boot PV guests with more than
 128GB (v2) for 3.7
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Sep 07, 2012 at 03:09:00PM +0100, Jan Beulich wrote:
> >>> On 07.09.12 at 15:39, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
> > On Fri, Sep 07, 2012 at 10:01:36AM +0100, Jan Beulich wrote:
> >> that I'm asking, I just know that I happen to fall into this trap
> >> once in a while myself), did you indeed build and install the
> > 
> > I know. I did double check - as I couldn't install wholesale the
> > new RPM (owner of the box needed the old version of it), instead
> > I did this bit of hack:
> > 
> > xend stop
> > cd /konrad
> > rpmcpio xen-*konrad* | cpio -id
> > tar -czvf /xen.orig.tgz /usr/lib64/*xen*
> > rm -Rf /usr/lib64/*xen*
> 
> So here you removed the old libraries. But where did you drop in
> the new ones? Did you just forget to list this here?

There was no need since the LD_LIBRARY_PATH did the over-write.
This was to make double sure that the old libs wouldn't be called.

> 
> > mv /usr/lib/python2.4/site-packages/xen /usr/lib/python2.4/site-packages/xen.old
> > ln -s /konrad/usr/lib/python2.4/site-packages/xen  /usr/lib/python2.4/site-packages/xen 
> > export PATH=/konrad/usr/bin:/konrad/usr/sbin:$PATH
> > export LD_LIBRARY_PATH=/konrad/usr/lib64
> > 
> > xend start
> > xm create /konrad/test.xm
> 
> Jan
> 
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 07 14:23:24 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Sep 2012 14:23: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 1T9zSg-00089v-WC; Fri, 07 Sep 2012 14:23:10 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jmforbes@linuxtx.org>) id 1T9zSf-00089J-B8
	for xen-devel@lists.xen.org; Fri, 07 Sep 2012 14:23:09 +0000
X-Env-Sender: jmforbes@linuxtx.org
X-Msg-Ref: server-12.tower-27.messagelabs.com!1347027778!10068312!1
X-Originating-IP: [209.85.214.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32566 invoked from network); 7 Sep 2012 14:22:59 -0000
Received: from mail-ob0-f173.google.com (HELO mail-ob0-f173.google.com)
	(209.85.214.173)
	by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Sep 2012 14:22:59 -0000
Received: by obbta14 with SMTP id ta14so5829163obb.32
	for <xen-devel@lists.xen.org>; Fri, 07 Sep 2012 07:22:57 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=date:from:to:cc:subject:message-id:references:mime-version
	:content-type:content-disposition:in-reply-to:user-agent
	:x-gm-message-state;
	bh=1as3AX6TtICEIbk+E3FrGPDORV96pR3DPCeOMR+x0z8=;
	b=Z00PLUjQEeGybEwO8mQdtuh1Fa6hEzC+04WAcV0hJtqwxNnv038l+AQpUVJ3U0iBNu
	a4FBXRjNj+IIi54+ujzKaW/apNmKQk+97//Qk3kgYxQlDW9YQrf9l6TSW5gmJnA2Yt/j
	CXMsypHveeCGIGb8snKx35r1vZ1R49MoK+CJk+S/ZD21oiECtX5s1/890O48w6Cn5qSo
	0ML/9s+vBr57qBFQOBRSpI//qRxHKD4sem5YMV8iPLnJ6rXcg1JV5GLherf1JcIG88c8
	msAl33QB2AxD9SVeZz4V+t/YAW2L5bHFjUfKCM6fT1hf1znSv96w1kcyoPLXCKGYH1l1
	CSYQ==
Received: by 10.182.85.8 with SMTP id d8mr6062696obz.70.1347027777704;
	Fri, 07 Sep 2012 07:22:57 -0700 (PDT)
Received: from linuxtx.org (108-232-88-112.lightspeed.rcsntx.sbcglobal.net.
	[108.232.88.112])
	by mx.google.com with ESMTPS id k8sm3869843oeh.9.2012.09.07.07.22.54
	(version=TLSv1/SSLv3 cipher=OTHER);
	Fri, 07 Sep 2012 07:22:55 -0700 (PDT)
Date: Fri, 7 Sep 2012 09:22:51 -0500
From: "Justin M. Forbes" <jmforbes@linuxtx.org>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20120907142251.GA20096@linuxtx.org>
References: <1347018043-21252-1-git-send-email-stefan.bader@canonical.com>
	<504A05B00200007800099C7B@nat28.tlf.novell.com>
	<5049F4E9.9050306@canonical.com>
	<504A1A950200007800099D4C@nat28.tlf.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <504A1A950200007800099D4C@nat28.tlf.novell.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Gm-Message-State: ALoCoQkQ571aRJLkbgKuXTTC3nol1awA2RZ3LM2mU3Z7K2S1maSUywDikHRBez6ywacXUqXoeeyX
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Matt Wilson <msw@amazon.com>, Stefan Bader <stefan.bader@canonical.com>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH/RFC] Fix xsave bug on older Xen hypervisors
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Sep 07, 2012 at 03:02:29PM +0100, Jan Beulich wrote:
> >>> On 07.09.12 at 15:21, Stefan Bader <stefan.bader@canonical.com> wrote:
> > On 07.09.2012 14:33, Jan Beulich wrote:
> >>>>> On 07.09.12 at 13:40, Stefan Bader <stefan.bader@canonical.com> wrote:
> >>> When writing unsupported flags into CR4 (for some time the
> >>> xen_write_cr4 function would refuse to do anything at all)
> >>> older Xen hypervisors (and patch can potentially be improved
> >>> by finding out what older means in version numbers) would
> >>> crash the guest.
> >>>
> >>> Since Amazon EC2 would at least in the past be affected by that,
> >>> Fedora and Ubuntu were carrying a hack that would filter out
> >>> X86_CR4_OSXSAVE before writing to CR4. This would affect any
> >>> PV guest, even those running on a newer HV.
> >>>
> >>> And this recently caused trouble because some user-space was
> >>> only partially checking (or maybe only looking at the cpuid
> >>> bits) and then trying to use xsave even though the OS support
> >>> was not set.
> >>>
> >>> So I came up with a patch that would
> >>> - limit the work-around to certain Xen versions
> >>> - prevent the write to CR4 by unsetting xsave and osxsave in
> >>>   the cpuid bits
> >>>
> >>> Doing things that way may actually allow this to be acceptable
> >>> upstream, so I am sending it around, now.
> >>> It probably could be improved when knowing the exact version
> >>> to test for but otherwise should allow to work around the guest
> >>> crash while not preventing xsave on Xen 4.x and newer hosts.
> >> 
> >> Before considering a hack like this, I'd really like to see evidence
> >> of the described behavior with an upstream kernel (i.e. not one
> >> with that known broken hack patched in, which has never been
> >> upstream afaict).
> > 
> > This is the reason I wrote that Fedora and Ubuntu were carrying it. It never 
> > has
> > been send upstream (the other version) because it would filter the CR4 write 
> > for
> > any PV guest regardless of host version.
> 
> But iirc that bad patch is a Linux side one (i.e. you're trying to fix
> something upstream that isn't upstream)?
> 
Right, so the patch that this improves upon, and that Fedora and Ubuntu are
currently carrying is not upstream because:

a) It's crap, it cripples upstream xen users, but doesn't impact RHEL xen
users because xsave was never supported there.

b) The hypervisor was patched to make it unnecessary quite some time ago,
and we hoped EC2 would eventually pick up that correct patch and we could
drop the crap kernel patch.

Unfortunately this has not happened. We are at a point where EC2 really is
a quirk that has to be worked around. Distros do not want to maintain
a separate EC2 build of the kernel, so the easiest way is to cripple
current upstream xen users.  This quirk is unfortunately the best possible
solution.  Having it upstream also makes it possible for any user to build
an upstream kernel that will run on EC2 without having to dig a random
patch out of a vendor kernel.

Justin

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 07 14:23:24 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Sep 2012 14:23: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 1T9zSg-00089v-WC; Fri, 07 Sep 2012 14:23:10 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jmforbes@linuxtx.org>) id 1T9zSf-00089J-B8
	for xen-devel@lists.xen.org; Fri, 07 Sep 2012 14:23:09 +0000
X-Env-Sender: jmforbes@linuxtx.org
X-Msg-Ref: server-12.tower-27.messagelabs.com!1347027778!10068312!1
X-Originating-IP: [209.85.214.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32566 invoked from network); 7 Sep 2012 14:22:59 -0000
Received: from mail-ob0-f173.google.com (HELO mail-ob0-f173.google.com)
	(209.85.214.173)
	by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Sep 2012 14:22:59 -0000
Received: by obbta14 with SMTP id ta14so5829163obb.32
	for <xen-devel@lists.xen.org>; Fri, 07 Sep 2012 07:22:57 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=date:from:to:cc:subject:message-id:references:mime-version
	:content-type:content-disposition:in-reply-to:user-agent
	:x-gm-message-state;
	bh=1as3AX6TtICEIbk+E3FrGPDORV96pR3DPCeOMR+x0z8=;
	b=Z00PLUjQEeGybEwO8mQdtuh1Fa6hEzC+04WAcV0hJtqwxNnv038l+AQpUVJ3U0iBNu
	a4FBXRjNj+IIi54+ujzKaW/apNmKQk+97//Qk3kgYxQlDW9YQrf9l6TSW5gmJnA2Yt/j
	CXMsypHveeCGIGb8snKx35r1vZ1R49MoK+CJk+S/ZD21oiECtX5s1/890O48w6Cn5qSo
	0ML/9s+vBr57qBFQOBRSpI//qRxHKD4sem5YMV8iPLnJ6rXcg1JV5GLherf1JcIG88c8
	msAl33QB2AxD9SVeZz4V+t/YAW2L5bHFjUfKCM6fT1hf1znSv96w1kcyoPLXCKGYH1l1
	CSYQ==
Received: by 10.182.85.8 with SMTP id d8mr6062696obz.70.1347027777704;
	Fri, 07 Sep 2012 07:22:57 -0700 (PDT)
Received: from linuxtx.org (108-232-88-112.lightspeed.rcsntx.sbcglobal.net.
	[108.232.88.112])
	by mx.google.com with ESMTPS id k8sm3869843oeh.9.2012.09.07.07.22.54
	(version=TLSv1/SSLv3 cipher=OTHER);
	Fri, 07 Sep 2012 07:22:55 -0700 (PDT)
Date: Fri, 7 Sep 2012 09:22:51 -0500
From: "Justin M. Forbes" <jmforbes@linuxtx.org>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20120907142251.GA20096@linuxtx.org>
References: <1347018043-21252-1-git-send-email-stefan.bader@canonical.com>
	<504A05B00200007800099C7B@nat28.tlf.novell.com>
	<5049F4E9.9050306@canonical.com>
	<504A1A950200007800099D4C@nat28.tlf.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <504A1A950200007800099D4C@nat28.tlf.novell.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Gm-Message-State: ALoCoQkQ571aRJLkbgKuXTTC3nol1awA2RZ3LM2mU3Z7K2S1maSUywDikHRBez6ywacXUqXoeeyX
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Matt Wilson <msw@amazon.com>, Stefan Bader <stefan.bader@canonical.com>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH/RFC] Fix xsave bug on older Xen hypervisors
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Sep 07, 2012 at 03:02:29PM +0100, Jan Beulich wrote:
> >>> On 07.09.12 at 15:21, Stefan Bader <stefan.bader@canonical.com> wrote:
> > On 07.09.2012 14:33, Jan Beulich wrote:
> >>>>> On 07.09.12 at 13:40, Stefan Bader <stefan.bader@canonical.com> wrote:
> >>> When writing unsupported flags into CR4 (for some time the
> >>> xen_write_cr4 function would refuse to do anything at all)
> >>> older Xen hypervisors (and patch can potentially be improved
> >>> by finding out what older means in version numbers) would
> >>> crash the guest.
> >>>
> >>> Since Amazon EC2 would at least in the past be affected by that,
> >>> Fedora and Ubuntu were carrying a hack that would filter out
> >>> X86_CR4_OSXSAVE before writing to CR4. This would affect any
> >>> PV guest, even those running on a newer HV.
> >>>
> >>> And this recently caused trouble because some user-space was
> >>> only partially checking (or maybe only looking at the cpuid
> >>> bits) and then trying to use xsave even though the OS support
> >>> was not set.
> >>>
> >>> So I came up with a patch that would
> >>> - limit the work-around to certain Xen versions
> >>> - prevent the write to CR4 by unsetting xsave and osxsave in
> >>>   the cpuid bits
> >>>
> >>> Doing things that way may actually allow this to be acceptable
> >>> upstream, so I am sending it around, now.
> >>> It probably could be improved when knowing the exact version
> >>> to test for but otherwise should allow to work around the guest
> >>> crash while not preventing xsave on Xen 4.x and newer hosts.
> >> 
> >> Before considering a hack like this, I'd really like to see evidence
> >> of the described behavior with an upstream kernel (i.e. not one
> >> with that known broken hack patched in, which has never been
> >> upstream afaict).
> > 
> > This is the reason I wrote that Fedora and Ubuntu were carrying it. It never 
> > has
> > been send upstream (the other version) because it would filter the CR4 write 
> > for
> > any PV guest regardless of host version.
> 
> But iirc that bad patch is a Linux side one (i.e. you're trying to fix
> something upstream that isn't upstream)?
> 
Right, so the patch that this improves upon, and that Fedora and Ubuntu are
currently carrying is not upstream because:

a) It's crap, it cripples upstream xen users, but doesn't impact RHEL xen
users because xsave was never supported there.

b) The hypervisor was patched to make it unnecessary quite some time ago,
and we hoped EC2 would eventually pick up that correct patch and we could
drop the crap kernel patch.

Unfortunately this has not happened. We are at a point where EC2 really is
a quirk that has to be worked around. Distros do not want to maintain
a separate EC2 build of the kernel, so the easiest way is to cripple
current upstream xen users.  This quirk is unfortunately the best possible
solution.  Having it upstream also makes it possible for any user to build
an upstream kernel that will run on EC2 without having to dig a random
patch out of a vendor kernel.

Justin

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 07 14:27:34 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Sep 2012 14:27:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9zWh-0008ST-Ln; Fri, 07 Sep 2012 14:27:19 +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 1T9zWg-0008SM-7h
	for xen-devel@lists.xen.org; Fri, 07 Sep 2012 14:27:18 +0000
Received: from [85.158.143.99:34058] by server-2.bemta-4.messagelabs.com id
	C6/9E-21239-5440A405; Fri, 07 Sep 2012 14:27:17 +0000
X-Env-Sender: Christoph.Egger@amd.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1347028033!25777855!1
X-Originating-IP: [216.32.181.182]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5951 invoked from network); 7 Sep 2012 14:27:14 -0000
Received: from ch1ehsobe002.messaging.microsoft.com (HELO
	ch1outboundpool.messaging.microsoft.com) (216.32.181.182)
	by server-7.tower-216.messagelabs.com with AES128-SHA encrypted SMTP;
	7 Sep 2012 14:27:14 -0000
Received: from mail128-ch1-R.bigfish.com (10.43.68.234) by
	CH1EHSOBE016.bigfish.com (10.43.70.66) with Microsoft SMTP Server id
	14.1.225.23; Fri, 7 Sep 2012 14:27:12 +0000
Received: from mail128-ch1 (localhost [127.0.0.1])	by
	mail128-ch1-R.bigfish.com (Postfix) with ESMTP id BE27F200096;
	Fri,  7 Sep 2012 14:27:12 +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: -2
X-BigFish: VPS-2(z4772kzbb2dI98dI1454I1432I14ffIzz1202hzz8275dhz2dh668h839h93fhd25he5bhf0ah107ah1288h1155h)
Received: from mail128-ch1 (localhost.localdomain [127.0.0.1]) by mail128-ch1
	(MessageSwitch) id 1347028021312775_9306;
	Fri,  7 Sep 2012 14:27:01 +0000 (UTC)
Received: from CH1EHSMHS039.bigfish.com (snatpool2.int.messaging.microsoft.com
	[10.43.68.237])	by mail128-ch1.bigfish.com (Postfix) with ESMTP id
	B4EB04005A;	Fri,  7 Sep 2012 14:26:51 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	CH1EHSMHS039.bigfish.com (10.43.69.248) with Microsoft SMTP Server id
	14.1.225.23; Fri, 7 Sep 2012 14:26:50 +0000
X-WSS-ID: 0M9ZHGQ-02-BWS-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 2D1A6C8055;	Fri,  7 Sep 2012 09:26:49 -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;
	Fri, 7 Sep 2012 09:40:17 -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;
	Fri, 7 Sep 2012 09:26:49 -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, 7 Sep 2012
	10:26:48 -0400
Message-ID: <504A0426.2090607@amd.com>
Date: Fri, 7 Sep 2012 16:26:46 +0200
From: Christoph Egger <Christoph.Egger@amd.com>
User-Agent: Mozilla/5.0 (X11; NetBSD amd64;
	rv:11.0) Gecko/20120404 Thunderbird/11.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <1347027296.30018.108.camel@zakaz.uk.xensource.com>
In-Reply-To: <1347027296.30018.108.camel@zakaz.uk.xensource.com>
X-OriginatorOrg: amd.com
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.2 new features and status -- please help me
	make a list
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 09/07/12 16:14, Ian Campbell wrote:

> Hi all,
> 
> I've been trawling the mercurial logs looking for interesting new
> features to update http://wiki.xen.org/wiki/Xen_4.2_Feature_List and
> http://wiki.xen.org/wiki/Xen_Release_Features and have come up with a
> list of interesting things which I need to know more about before I can
> say stuff.
> 
> I've bcc'd people who I think might know about one or more of the
> following. If you do then please can you tell me:
> 
>       * What is the feature, what is the impact for the end user?
>       * What is it's status in 4.2? Is it a proof of concept, an
>         experimental feature, tech preview or a finished completed
>         feature.
>       * Is it new in 4.2? If it isn't new what was it's status in 4.1
>         and 4.0 (i.e. from the list in the previous item).
> 
> Of course if you know of a feature in 4.2 which isn't mentioned but
> which you think is worthwhile please let me know. I'm sure there are
> plenty which I missed.
> 
> Also feel free to edit the wiki instead....
> 
> TIA for your help.
> 
> Ian.
> 
> Nested Virtualisation: Allow HVM guests to use virtualisation hardware
> (e.g. Windows 7 compat mode)
>         Tech Preview, new in 4.2
>         
> vMSI: ? Emulated (or real?) MSIs for guests?
>         State? New in 4.2?
>         
> vMCE: Forward MCE (Machine Check Exceptions) to guests
>         New in 4.2? Preview or complete? I know improvements are pending
>         to migration in 4.3.
>         
> AMD OSVW: What is this?
>         Seems to be new in 4.2?


OSVW (OS Visible Workarounds): Support for guests has been added
to make them disable workarounds for hw bugs not emulated/present
for guests.

Christoph


>         
> xenpaging: Page HVM guest pages to disk
>         Was marked as tech preview in 4.1 and earlier, still is?
>         
> memsharing: Sharing of HVM guest pages.
>         Was marked as tech preview in 4.1 and earlier, still is?
> 
> Intel HLE: What is this?
>         Seems to be new in 4.2?
>         
> Intel TRM: What is this?
>         Seems to be new in 4.2?
> 
> OVMF support for HVM guests.
>         New in 4.2, but disabled by default => Tech preview?
>         
> vPMU: Power Management?
>         New in 4.2?
>         
> ASID support:
>         4.2 gained an option to control this but I think it was
>         pre-existing. When was it first introduced? 4.1 or 4.0 or
>         before?
>         
> Core parking: Offlining CPUs for power reasons?
>         New in 4.2?
>         
> PV netboot: Network boot for PV guests
>         New in 4.2
> 
> 
> 



-- 
---to satisfy European Law for business letters:
Advanced Micro Devices GmbH
Einsteinring 24, 85689 Dornach b. Muenchen
Geschaeftsfuehrer: Alberto Bozzo
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 Sep 07 14:27:34 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Sep 2012 14:27:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9zWh-0008ST-Ln; Fri, 07 Sep 2012 14:27:19 +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 1T9zWg-0008SM-7h
	for xen-devel@lists.xen.org; Fri, 07 Sep 2012 14:27:18 +0000
Received: from [85.158.143.99:34058] by server-2.bemta-4.messagelabs.com id
	C6/9E-21239-5440A405; Fri, 07 Sep 2012 14:27:17 +0000
X-Env-Sender: Christoph.Egger@amd.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1347028033!25777855!1
X-Originating-IP: [216.32.181.182]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5951 invoked from network); 7 Sep 2012 14:27:14 -0000
Received: from ch1ehsobe002.messaging.microsoft.com (HELO
	ch1outboundpool.messaging.microsoft.com) (216.32.181.182)
	by server-7.tower-216.messagelabs.com with AES128-SHA encrypted SMTP;
	7 Sep 2012 14:27:14 -0000
Received: from mail128-ch1-R.bigfish.com (10.43.68.234) by
	CH1EHSOBE016.bigfish.com (10.43.70.66) with Microsoft SMTP Server id
	14.1.225.23; Fri, 7 Sep 2012 14:27:12 +0000
Received: from mail128-ch1 (localhost [127.0.0.1])	by
	mail128-ch1-R.bigfish.com (Postfix) with ESMTP id BE27F200096;
	Fri,  7 Sep 2012 14:27:12 +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: -2
X-BigFish: VPS-2(z4772kzbb2dI98dI1454I1432I14ffIzz1202hzz8275dhz2dh668h839h93fhd25he5bhf0ah107ah1288h1155h)
Received: from mail128-ch1 (localhost.localdomain [127.0.0.1]) by mail128-ch1
	(MessageSwitch) id 1347028021312775_9306;
	Fri,  7 Sep 2012 14:27:01 +0000 (UTC)
Received: from CH1EHSMHS039.bigfish.com (snatpool2.int.messaging.microsoft.com
	[10.43.68.237])	by mail128-ch1.bigfish.com (Postfix) with ESMTP id
	B4EB04005A;	Fri,  7 Sep 2012 14:26:51 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	CH1EHSMHS039.bigfish.com (10.43.69.248) with Microsoft SMTP Server id
	14.1.225.23; Fri, 7 Sep 2012 14:26:50 +0000
X-WSS-ID: 0M9ZHGQ-02-BWS-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 2D1A6C8055;	Fri,  7 Sep 2012 09:26:49 -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;
	Fri, 7 Sep 2012 09:40:17 -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;
	Fri, 7 Sep 2012 09:26:49 -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, 7 Sep 2012
	10:26:48 -0400
Message-ID: <504A0426.2090607@amd.com>
Date: Fri, 7 Sep 2012 16:26:46 +0200
From: Christoph Egger <Christoph.Egger@amd.com>
User-Agent: Mozilla/5.0 (X11; NetBSD amd64;
	rv:11.0) Gecko/20120404 Thunderbird/11.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <1347027296.30018.108.camel@zakaz.uk.xensource.com>
In-Reply-To: <1347027296.30018.108.camel@zakaz.uk.xensource.com>
X-OriginatorOrg: amd.com
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.2 new features and status -- please help me
	make a list
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 09/07/12 16:14, Ian Campbell wrote:

> Hi all,
> 
> I've been trawling the mercurial logs looking for interesting new
> features to update http://wiki.xen.org/wiki/Xen_4.2_Feature_List and
> http://wiki.xen.org/wiki/Xen_Release_Features and have come up with a
> list of interesting things which I need to know more about before I can
> say stuff.
> 
> I've bcc'd people who I think might know about one or more of the
> following. If you do then please can you tell me:
> 
>       * What is the feature, what is the impact for the end user?
>       * What is it's status in 4.2? Is it a proof of concept, an
>         experimental feature, tech preview or a finished completed
>         feature.
>       * Is it new in 4.2? If it isn't new what was it's status in 4.1
>         and 4.0 (i.e. from the list in the previous item).
> 
> Of course if you know of a feature in 4.2 which isn't mentioned but
> which you think is worthwhile please let me know. I'm sure there are
> plenty which I missed.
> 
> Also feel free to edit the wiki instead....
> 
> TIA for your help.
> 
> Ian.
> 
> Nested Virtualisation: Allow HVM guests to use virtualisation hardware
> (e.g. Windows 7 compat mode)
>         Tech Preview, new in 4.2
>         
> vMSI: ? Emulated (or real?) MSIs for guests?
>         State? New in 4.2?
>         
> vMCE: Forward MCE (Machine Check Exceptions) to guests
>         New in 4.2? Preview or complete? I know improvements are pending
>         to migration in 4.3.
>         
> AMD OSVW: What is this?
>         Seems to be new in 4.2?


OSVW (OS Visible Workarounds): Support for guests has been added
to make them disable workarounds for hw bugs not emulated/present
for guests.

Christoph


>         
> xenpaging: Page HVM guest pages to disk
>         Was marked as tech preview in 4.1 and earlier, still is?
>         
> memsharing: Sharing of HVM guest pages.
>         Was marked as tech preview in 4.1 and earlier, still is?
> 
> Intel HLE: What is this?
>         Seems to be new in 4.2?
>         
> Intel TRM: What is this?
>         Seems to be new in 4.2?
> 
> OVMF support for HVM guests.
>         New in 4.2, but disabled by default => Tech preview?
>         
> vPMU: Power Management?
>         New in 4.2?
>         
> ASID support:
>         4.2 gained an option to control this but I think it was
>         pre-existing. When was it first introduced? 4.1 or 4.0 or
>         before?
>         
> Core parking: Offlining CPUs for power reasons?
>         New in 4.2?
>         
> PV netboot: Network boot for PV guests
>         New in 4.2
> 
> 
> 



-- 
---to satisfy European Law for business letters:
Advanced Micro Devices GmbH
Einsteinring 24, 85689 Dornach b. Muenchen
Geschaeftsfuehrer: Alberto Bozzo
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 Sep 07 14:34:33 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Sep 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 1T9zdU-0000OD-64; Fri, 07 Sep 2012 14:34:20 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andres.lagarcavilla@gmail.com>) id 1T9zdS-0000Nj-Vh
	for xen-devel@lists.xen.org; Fri, 07 Sep 2012 14:34:19 +0000
X-Env-Sender: andres.lagarcavilla@gmail.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1347028450!8792652!1
X-Originating-IP: [209.85.223.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19244 invoked from network); 7 Sep 2012 14:34:12 -0000
Received: from mail-ie0-f173.google.com (HELO mail-ie0-f173.google.com)
	(209.85.223.173)
	by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Sep 2012 14:34:12 -0000
Received: by iebc10 with SMTP id c10so6259176ieb.32
	for <xen-devel@lists.xen.org>; Fri, 07 Sep 2012 07:34:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=subject:mime-version:content-type:from:in-reply-to:date:cc
	:content-transfer-encoding:message-id:references:to:x-mailer;
	bh=BdHFXNFa+bmpHI8LjQGCpd0X+HufHbpsCThmx0zYXXg=;
	b=08nkELwDnwE3Qr3k7vPWzrYrWjTjP6rqkfvKkK2wHMU6zgDgLm5vh3yiOi2aDEV1K8
	TrsLOq2WEYTJCOmMmKe7qFrHNalt/iUaeL654d8BTprXim5D8tf6B1Q5ykd2fiLhwQc6
	WbSVdQdyVfKTks3qMTrteySDIp/dgnR3LgnD7r4dj20AZAPVAlm6537cQ+dfvd3xEne+
	uDC3lZp6rBRGAK0bqjLvx4qMgmSIMQ/K52/EbdDnpmIlvYVJgZF2sd0i7Et7fqlt2Dtw
	EyqeKhnai99z+ZQv029unIHKWy6SEuqOvgWzsC2ksFrwYHH9qLOdVrHh+on5qh3R5Ncf
	/rsA==
Received: by 10.50.173.71 with SMTP id bi7mr8952171igc.3.1347028450467;
	Fri, 07 Sep 2012 07:34:10 -0700 (PDT)
Received: from [192.168.7.210] ([206.223.182.18])
	by mx.google.com with ESMTPS id q1sm13201620igj.15.2012.09.07.07.34.08
	(version=TLSv1/SSLv3 cipher=OTHER);
	Fri, 07 Sep 2012 07:34:09 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1278)
From: Andres Lagar-Cavilla <andres.lagarcavilla@gmail.com>
In-Reply-To: <1347027296.30018.108.camel@zakaz.uk.xensource.com>
Date: Fri, 7 Sep 2012 10:34:10 -0400
Message-Id: <8149449A-BB9D-40AE-945F-ACED38979F19@gmail.com>
References: <1347027296.30018.108.camel@zakaz.uk.xensource.com>
To: Ian Campbell <ian.campbell@citrix.com>
X-Mailer: Apple Mail (2.1278)
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.2 new features and status -- please help me
	make a list
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


On Sep 7, 2012, at 10:14 AM, Ian Campbell wrote:

> Hi all,
> 
> I've been trawling the mercurial logs looking for interesting new
> features to update http://wiki.xen.org/wiki/Xen_4.2_Feature_List and
> http://wiki.xen.org/wiki/Xen_Release_Features and have come up with a
> list of interesting things which I need to know more about before I can
> say stuff.
> 
> I've bcc'd people who I think might know about one or more of the
> following. If you do then please can you tell me:
> 
>      * What is the feature, what is the impact for the end user?
>      * What is it's status in 4.2? Is it a proof of concept, an
>        experimental feature, tech preview or a finished completed
>        feature.
>      * Is it new in 4.2? If it isn't new what was it's status in 4.1
>        and 4.0 (i.e. from the list in the previous item).
> 
> Of course if you know of a feature in 4.2 which isn't mentioned but
> which you think is worthwhile please let me know. I'm sure there are
> plenty which I missed.
> 
> Also feel free to edit the wiki instead....
> 
> TIA for your help.
> 
> Ian.
> 
> Nested Virtualisation: Allow HVM guests to use virtualisation hardware
> (e.g. Windows 7 compat mode)
>        Tech Preview, new in 4.2
> 
> vMSI: ? Emulated (or real?) MSIs for guests?
>        State? New in 4.2?
> 
> vMCE: Forward MCE (Machine Check Exceptions) to guests
>        New in 4.2? Preview or complete? I know improvements are pending
>        to migration in 4.3.
> 
> AMD OSVW: What is this?
>        Seems to be new in 4.2?
> 
> xenpaging: Page HVM guest pages to disk
>        Was marked as tech preview in 4.1 and earlier, still is?
> 
> memsharing: Sharing of HVM guest pages.
>        Was marked as tech preview in 4.1 and earlier, still is?

Both xenpaging and memsharing are functional as far as I am concerned. Intel EPT is the platform of choice. There are many reports of success on AMD insofar xenpaging goes, but I haven't gotten good traction with either xen{paging/sharing} on AMD. 

Please note that memsharing has been significantly overhauled both at an interface and internals level. It bears almost no resemblance to the 4.1 release.

Xen{paging/sharing} still have border conditions in which domains are crashed. They are rare enough that I have not experienced them in practice. This is due to a need for more mature wait queue code in the hypervisor. The plan is to address this in 4.3.

Finally, mem-access has seen improvements and extensions. Now you can get a log of all memory accesses by a guest (if you so wished) using the n2rwx mode.

Cheers,
Andres

> 
> Intel HLE: What is this?
>        Seems to be new in 4.2?
> 
> Intel TRM: What is this?
>        Seems to be new in 4.2?
> 
> OVMF support for HVM guests.
>        New in 4.2, but disabled by default => Tech preview?
> 
> vPMU: Power Management?
>        New in 4.2?
> 
> ASID support:
>        4.2 gained an option to control this but I think it was
>        pre-existing. When was it first introduced? 4.1 or 4.0 or
>        before?
> 
> Core parking: Offlining CPUs for power reasons?
>        New in 4.2?
> 
> PV netboot: Network boot for PV guests
>        New in 4.2
> 
> 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 07 14:34:33 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Sep 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 1T9zdU-0000OD-64; Fri, 07 Sep 2012 14:34:20 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andres.lagarcavilla@gmail.com>) id 1T9zdS-0000Nj-Vh
	for xen-devel@lists.xen.org; Fri, 07 Sep 2012 14:34:19 +0000
X-Env-Sender: andres.lagarcavilla@gmail.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1347028450!8792652!1
X-Originating-IP: [209.85.223.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19244 invoked from network); 7 Sep 2012 14:34:12 -0000
Received: from mail-ie0-f173.google.com (HELO mail-ie0-f173.google.com)
	(209.85.223.173)
	by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Sep 2012 14:34:12 -0000
Received: by iebc10 with SMTP id c10so6259176ieb.32
	for <xen-devel@lists.xen.org>; Fri, 07 Sep 2012 07:34:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=subject:mime-version:content-type:from:in-reply-to:date:cc
	:content-transfer-encoding:message-id:references:to:x-mailer;
	bh=BdHFXNFa+bmpHI8LjQGCpd0X+HufHbpsCThmx0zYXXg=;
	b=08nkELwDnwE3Qr3k7vPWzrYrWjTjP6rqkfvKkK2wHMU6zgDgLm5vh3yiOi2aDEV1K8
	TrsLOq2WEYTJCOmMmKe7qFrHNalt/iUaeL654d8BTprXim5D8tf6B1Q5ykd2fiLhwQc6
	WbSVdQdyVfKTks3qMTrteySDIp/dgnR3LgnD7r4dj20AZAPVAlm6537cQ+dfvd3xEne+
	uDC3lZp6rBRGAK0bqjLvx4qMgmSIMQ/K52/EbdDnpmIlvYVJgZF2sd0i7Et7fqlt2Dtw
	EyqeKhnai99z+ZQv029unIHKWy6SEuqOvgWzsC2ksFrwYHH9qLOdVrHh+on5qh3R5Ncf
	/rsA==
Received: by 10.50.173.71 with SMTP id bi7mr8952171igc.3.1347028450467;
	Fri, 07 Sep 2012 07:34:10 -0700 (PDT)
Received: from [192.168.7.210] ([206.223.182.18])
	by mx.google.com with ESMTPS id q1sm13201620igj.15.2012.09.07.07.34.08
	(version=TLSv1/SSLv3 cipher=OTHER);
	Fri, 07 Sep 2012 07:34:09 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1278)
From: Andres Lagar-Cavilla <andres.lagarcavilla@gmail.com>
In-Reply-To: <1347027296.30018.108.camel@zakaz.uk.xensource.com>
Date: Fri, 7 Sep 2012 10:34:10 -0400
Message-Id: <8149449A-BB9D-40AE-945F-ACED38979F19@gmail.com>
References: <1347027296.30018.108.camel@zakaz.uk.xensource.com>
To: Ian Campbell <ian.campbell@citrix.com>
X-Mailer: Apple Mail (2.1278)
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.2 new features and status -- please help me
	make a list
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


On Sep 7, 2012, at 10:14 AM, Ian Campbell wrote:

> Hi all,
> 
> I've been trawling the mercurial logs looking for interesting new
> features to update http://wiki.xen.org/wiki/Xen_4.2_Feature_List and
> http://wiki.xen.org/wiki/Xen_Release_Features and have come up with a
> list of interesting things which I need to know more about before I can
> say stuff.
> 
> I've bcc'd people who I think might know about one or more of the
> following. If you do then please can you tell me:
> 
>      * What is the feature, what is the impact for the end user?
>      * What is it's status in 4.2? Is it a proof of concept, an
>        experimental feature, tech preview or a finished completed
>        feature.
>      * Is it new in 4.2? If it isn't new what was it's status in 4.1
>        and 4.0 (i.e. from the list in the previous item).
> 
> Of course if you know of a feature in 4.2 which isn't mentioned but
> which you think is worthwhile please let me know. I'm sure there are
> plenty which I missed.
> 
> Also feel free to edit the wiki instead....
> 
> TIA for your help.
> 
> Ian.
> 
> Nested Virtualisation: Allow HVM guests to use virtualisation hardware
> (e.g. Windows 7 compat mode)
>        Tech Preview, new in 4.2
> 
> vMSI: ? Emulated (or real?) MSIs for guests?
>        State? New in 4.2?
> 
> vMCE: Forward MCE (Machine Check Exceptions) to guests
>        New in 4.2? Preview or complete? I know improvements are pending
>        to migration in 4.3.
> 
> AMD OSVW: What is this?
>        Seems to be new in 4.2?
> 
> xenpaging: Page HVM guest pages to disk
>        Was marked as tech preview in 4.1 and earlier, still is?
> 
> memsharing: Sharing of HVM guest pages.
>        Was marked as tech preview in 4.1 and earlier, still is?

Both xenpaging and memsharing are functional as far as I am concerned. Intel EPT is the platform of choice. There are many reports of success on AMD insofar xenpaging goes, but I haven't gotten good traction with either xen{paging/sharing} on AMD. 

Please note that memsharing has been significantly overhauled both at an interface and internals level. It bears almost no resemblance to the 4.1 release.

Xen{paging/sharing} still have border conditions in which domains are crashed. They are rare enough that I have not experienced them in practice. This is due to a need for more mature wait queue code in the hypervisor. The plan is to address this in 4.3.

Finally, mem-access has seen improvements and extensions. Now you can get a log of all memory accesses by a guest (if you so wished) using the n2rwx mode.

Cheers,
Andres

> 
> Intel HLE: What is this?
>        Seems to be new in 4.2?
> 
> Intel TRM: What is this?
>        Seems to be new in 4.2?
> 
> OVMF support for HVM guests.
>        New in 4.2, but disabled by default => Tech preview?
> 
> vPMU: Power Management?
>        New in 4.2?
> 
> ASID support:
>        4.2 gained an option to control this but I think it was
>        pre-existing. When was it first introduced? 4.1 or 4.0 or
>        before?
> 
> Core parking: Offlining CPUs for power reasons?
>        New in 4.2?
> 
> PV netboot: Network boot for PV guests
>        New in 4.2
> 
> 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 07 14:44:35 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Sep 2012 14:44: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 1T9znA-00012s-7f; Fri, 07 Sep 2012 14:44:20 +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 1T9zn8-00012j-IK
	for xen-devel@lists.xen.org; Fri, 07 Sep 2012 14:44:18 +0000
Received: from [85.158.138.51:10615] by server-11.bemta-3.messagelabs.com id
	36/2B-30250-1480A405; Fri, 07 Sep 2012 14:44:17 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1347029056!21273807!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-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30778 invoked from network); 7 Sep 2012 14:44:17 -0000
Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com)
	(74.125.83.45)
	by server-6.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Sep 2012 14:44:17 -0000
Received: by eeke53 with SMTP id e53so1340654eek.32
	for <xen-devel@lists.xen.org>; Fri, 07 Sep 2012 07:44:16 -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=ColfSfZk9SsoqjS9ytTDaS994cg/G89D/GRuPX+zw9o=;
	b=nAJg78myPuqn3yzaAsemAPysd4dhbvp7jJP4f+1jgTfFiY9fweO5dyYY+sTGM8b+bx
	bH3dkyvKBJQSmm56VmiMiby3uc6kl+WLAkUsUrZ2nqYfYtoLMdE/T92jQCGIAHKLbtQI
	2zpbYHEUH0Jq64UQeX77lPx941z+al/1S8A4bOrLG/x6PZHf7IIV54sw7uC8NgFQdW9r
	Knw1lh1IDhA6YW1tMdTeJaG9/b7UQzsWLj9KpxATDuHR0i0lCYsmAHGwlSr9frR7zS/Z
	zzLxuc2E1El8aieQFVHjKWU7MFWHGZw1wJPKdTUBxHdafjy0QFlauY5Ya1sOUUL9DHmk
	WuGQ==
Received: by 10.14.179.136 with SMTP id h8mr8262635eem.6.1347029056868;
	Fri, 07 Sep 2012 07:44:16 -0700 (PDT)
Received: from [192.168.1.69] (host86-184-74-117.range86-184.btcentralplus.com.
	[86.184.74.117])
	by mx.google.com with ESMTPS id v3sm15252711eep.10.2012.09.07.07.44.14
	(version=SSLv3 cipher=OTHER); Fri, 07 Sep 2012 07:44:16 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Fri, 07 Sep 2012 15:44:07 +0100
From: Keir Fraser <keir.xen@gmail.com>
To: Jan Beulich <JBeulich@suse.com>,
	xen-devel <xen-devel@lists.xen.org>
Message-ID: <CC6FC6C7.3E09E%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [PATCH] x86/MSI: fix 2nd S3 resume with interrupt
	remapping enabled
Thread-Index: Ac2NBzu6HFhflZg5ZE2771p8GER13Q==
In-Reply-To: <504A09720200007800099CBD@nat28.tlf.novell.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] [PATCH] x86/MSI: fix 2nd S3 resume with interrupt
 remapping 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 07/09/2012 13:49, "Jan Beulich" <JBeulich@suse.com> wrote:

> The first resume from S3 was corrupting internal data structures (in
> that pci_restore_msi_state() updated the globally stored MSI message
> from traditional to interrupt remapped format, which would then be
> translated a second time during the second resume, breaking interrupt
> delivery).

Doesn't that mean write_msi_msg() has a bit of a hideous interface?

> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Acked-by: Keir Fraser <keir@xen.org>

Looks pretty safe for 4.2.0.

> --- 2012-08-08.orig/xen/arch/x86/msi.c 2012-09-07 13:39:02.000000000 +0200
> +++ 2012-08-08/xen/arch/x86/msi.c 2012-09-06 12:04:11.000000000 +0200
> @@ -210,7 +210,10 @@ static void write_msi_msg(struct msi_des
>      entry->msg = *msg;
>  
>      if ( iommu_enabled )
> +    {
> +        ASSERT(msg != &entry->msg);
>          iommu_update_ire_from_msi(entry, msg);
> +    }
>  
>      switch ( entry->msi_attrib.type )
>      {
> @@ -996,6 +999,7 @@ int pci_restore_msi_state(struct pci_dev
>      int ret;
>      struct msi_desc *entry, *tmp;
>      struct irq_desc *desc;
> +    struct msi_msg msg;
>  
>      ASSERT(spin_is_locked(&pcidevs_lock));
>  
> @@ -1030,7 +1034,8 @@ int pci_restore_msi_state(struct pci_dev
>          else if ( entry->msi_attrib.type == PCI_CAP_ID_MSIX )
>              msix_set_enable(pdev, 0);
>  
> -        write_msi_msg(entry, &entry->msg);
> +        msg = entry->msg;
> +        write_msi_msg(entry, &msg);
>  
>          msi_set_mask_bit(desc, entry->msi_attrib.masked);
>  
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Sep 07 14:44:35 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Sep 2012 14:44: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 1T9znA-00012s-7f; Fri, 07 Sep 2012 14:44:20 +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 1T9zn8-00012j-IK
	for xen-devel@lists.xen.org; Fri, 07 Sep 2012 14:44:18 +0000
Received: from [85.158.138.51:10615] by server-11.bemta-3.messagelabs.com id
	36/2B-30250-1480A405; Fri, 07 Sep 2012 14:44:17 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1347029056!21273807!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-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30778 invoked from network); 7 Sep 2012 14:44:17 -0000
Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com)
	(74.125.83.45)
	by server-6.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Sep 2012 14:44:17 -0000
Received: by eeke53 with SMTP id e53so1340654eek.32
	for <xen-devel@lists.xen.org>; Fri, 07 Sep 2012 07:44:16 -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=ColfSfZk9SsoqjS9ytTDaS994cg/G89D/GRuPX+zw9o=;
	b=nAJg78myPuqn3yzaAsemAPysd4dhbvp7jJP4f+1jgTfFiY9fweO5dyYY+sTGM8b+bx
	bH3dkyvKBJQSmm56VmiMiby3uc6kl+WLAkUsUrZ2nqYfYtoLMdE/T92jQCGIAHKLbtQI
	2zpbYHEUH0Jq64UQeX77lPx941z+al/1S8A4bOrLG/x6PZHf7IIV54sw7uC8NgFQdW9r
	Knw1lh1IDhA6YW1tMdTeJaG9/b7UQzsWLj9KpxATDuHR0i0lCYsmAHGwlSr9frR7zS/Z
	zzLxuc2E1El8aieQFVHjKWU7MFWHGZw1wJPKdTUBxHdafjy0QFlauY5Ya1sOUUL9DHmk
	WuGQ==
Received: by 10.14.179.136 with SMTP id h8mr8262635eem.6.1347029056868;
	Fri, 07 Sep 2012 07:44:16 -0700 (PDT)
Received: from [192.168.1.69] (host86-184-74-117.range86-184.btcentralplus.com.
	[86.184.74.117])
	by mx.google.com with ESMTPS id v3sm15252711eep.10.2012.09.07.07.44.14
	(version=SSLv3 cipher=OTHER); Fri, 07 Sep 2012 07:44:16 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Fri, 07 Sep 2012 15:44:07 +0100
From: Keir Fraser <keir.xen@gmail.com>
To: Jan Beulich <JBeulich@suse.com>,
	xen-devel <xen-devel@lists.xen.org>
Message-ID: <CC6FC6C7.3E09E%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [PATCH] x86/MSI: fix 2nd S3 resume with interrupt
	remapping enabled
Thread-Index: Ac2NBzu6HFhflZg5ZE2771p8GER13Q==
In-Reply-To: <504A09720200007800099CBD@nat28.tlf.novell.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] [PATCH] x86/MSI: fix 2nd S3 resume with interrupt
 remapping 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 07/09/2012 13:49, "Jan Beulich" <JBeulich@suse.com> wrote:

> The first resume from S3 was corrupting internal data structures (in
> that pci_restore_msi_state() updated the globally stored MSI message
> from traditional to interrupt remapped format, which would then be
> translated a second time during the second resume, breaking interrupt
> delivery).

Doesn't that mean write_msi_msg() has a bit of a hideous interface?

> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Acked-by: Keir Fraser <keir@xen.org>

Looks pretty safe for 4.2.0.

> --- 2012-08-08.orig/xen/arch/x86/msi.c 2012-09-07 13:39:02.000000000 +0200
> +++ 2012-08-08/xen/arch/x86/msi.c 2012-09-06 12:04:11.000000000 +0200
> @@ -210,7 +210,10 @@ static void write_msi_msg(struct msi_des
>      entry->msg = *msg;
>  
>      if ( iommu_enabled )
> +    {
> +        ASSERT(msg != &entry->msg);
>          iommu_update_ire_from_msi(entry, msg);
> +    }
>  
>      switch ( entry->msi_attrib.type )
>      {
> @@ -996,6 +999,7 @@ int pci_restore_msi_state(struct pci_dev
>      int ret;
>      struct msi_desc *entry, *tmp;
>      struct irq_desc *desc;
> +    struct msi_msg msg;
>  
>      ASSERT(spin_is_locked(&pcidevs_lock));
>  
> @@ -1030,7 +1034,8 @@ int pci_restore_msi_state(struct pci_dev
>          else if ( entry->msi_attrib.type == PCI_CAP_ID_MSIX )
>              msix_set_enable(pdev, 0);
>  
> -        write_msi_msg(entry, &entry->msg);
> +        msg = entry->msg;
> +        write_msi_msg(entry, &msg);
>  
>          msi_set_mask_bit(desc, entry->msi_attrib.masked);
>  
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Sep 07 14:48:09 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Sep 2012 14:48: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 1T9zqY-0001Ec-S2; Fri, 07 Sep 2012 14:47:50 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1T9zqW-0001EP-Tp
	for xen-devel@lists.xen.org; Fri, 07 Sep 2012 14:47:49 +0000
Received: from [85.158.139.83:35651] by server-5.bemta-5.messagelabs.com id
	AB/B7-30514-4190A405; Fri, 07 Sep 2012 14:47:48 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1347029266!17923098!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-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27916 invoked from network); 7 Sep 2012 14:47:47 -0000
Received: from mail-ey0-f173.google.com (HELO mail-ey0-f173.google.com)
	(209.85.215.173)
	by server-8.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Sep 2012 14:47:47 -0000
Received: by eaac13 with SMTP id c13so1024697eaa.32
	for <xen-devel@lists.xen.org>; Fri, 07 Sep 2012 07:47:46 -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=d8WlZUTLrrEbj3bQHqLrc3dtE/U7gXkGRBQzaBJQZ+Q=;
	b=V3MHR6bNJT4hYCXONahQCYFq55SJBaLO6WAVs0ilyvYZny4CR/3I3AccmgOeKZ7J/8
	YN7X+FsWXJZNHDTSbSpsDtNfxm4GmyVSYU50pZboGIpE9FH9tWoj7pY3od+9oR5SkrKr
	ycPme6GPxMX79l8ehhkkOHXtMus2IBWQKhcmjIxraZkazzCe2y81UfBMfQkMG3rh4UiD
	tGraJVj6QBQ8zBGhZYGISa0jvOsJpdK4LiZGiX+mZQkmCb9YH2orTMkNgrKmWYX7+Udv
	K/haLKRJZQ77AJ06v4rrfyXlUGNVzJLgLNZ07nBw0GTw19/Y6gdodfspLQv8u/iraqct
	3Lsw==
Received: by 10.14.177.193 with SMTP id d41mr8240209eem.19.1347029266811;
	Fri, 07 Sep 2012 07:47:46 -0700 (PDT)
Received: from [192.168.1.69] (host86-184-74-117.range86-184.btcentralplus.com.
	[86.184.74.117])
	by mx.google.com with ESMTPS id a7sm15258141eep.14.2012.09.07.07.47.43
	(version=SSLv3 cipher=OTHER); Fri, 07 Sep 2012 07:47:46 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Fri, 07 Sep 2012 15:47:40 +0100
From: Keir Fraser <keir.xen@gmail.com>
To: Jan Beulich <JBeulich@suse.com>,
	xen-devel <xen-devel@lists.xen.org>
Message-ID: <CC6FC79C.3E0B5%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [PATCH] adjust a few RCU domain locking calls
Thread-Index: Ac2NB7qwu+5lcvA5BUOYr9XmKfdcDg==
In-Reply-To: <504A0B110200007800099CCD@nat28.tlf.novell.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] [PATCH] adjust a few RCU domain locking calls
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 07/09/2012 13:56, "Jan Beulich" <JBeulich@suse.com> wrote:

> x86's do_physdev_op() had a case where the locking was entirely
> superfluous. Its physdev_map_pirq() further had a case where the lock
> was being obtained too early, needlessly complicating early exit paths.
> 
> Grant table code had two open coded instances of
> rcu_lock_target_domain_by_id(), and a third code section could be
> consolidated by using the newly introduced helper function.
> 
> The memory hypercall code had two more instances of open coding
> rcu_lock_target_domain_by_id(), but note that here this is not just
> cleanup, but also fixes an error return path in memory_exchange() to
> actually return an error.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Acked-by: Keir Fraser <keir@xen.org>

> --- a/xen/arch/x86/physdev.c
> +++ b/xen/arch/x86/physdev.c
> @@ -90,14 +90,10 @@ static int physdev_hvm_map_pirq(
>  int physdev_map_pirq(domid_t domid, int type, int *index, int *pirq_p,
>                       struct msi_info *msi)
>  {
> -    struct domain *d;
> +    struct domain *d = current->domain;
>      int pirq, irq, ret = 0;
>      void *map_data = NULL;
>  
> -    ret = rcu_lock_target_domain_by_id(domid, &d);
> -    if ( ret )
> -        return ret;
> -
>      if ( domid == DOMID_SELF && is_hvm_domain(d) )
>      {
>          /*
> @@ -105,14 +101,15 @@ int physdev_map_pirq(domid_t domid, int
>           * calls back into itself and deadlocks on hvm_domain.irq_lock.
>           */
>          if ( !is_hvm_pv_evtchn_domain(d) )
> -        {
> -            ret = -EINVAL;
> -            goto free_domain;
> -        }
> -        ret = physdev_hvm_map_pirq(d, type, index, pirq_p);
> -        goto free_domain;
> +            return -EINVAL;
> +
> +        return physdev_hvm_map_pirq(d, type, index, pirq_p);
>      }
>  
> +    ret = rcu_lock_target_domain_by_id(domid, &d);
> +    if ( ret )
> +        return ret;
> +
>      if ( !IS_PRIV_FOR(current->domain, d) )
>      {
>          ret = -EPERM;
> @@ -696,13 +693,12 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_H
>      }
>      case PHYSDEVOP_get_free_pirq: {
>          struct physdev_get_free_pirq out;
> -        struct domain *d;
> +        struct domain *d = v->domain;
>  
>          ret = -EFAULT;
>          if ( copy_from_guest(&out, arg, 1) != 0 )
>              break;
>  
> -        d = rcu_lock_current_domain();
>          spin_lock(&d->event_lock);
>  
>          ret = get_free_pirq(d, out.type);
> @@ -717,7 +713,6 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_H
>          }
>  
>          spin_unlock(&d->event_lock);
> -        rcu_unlock_domain(d);
>  
>          if ( ret >= 0 )
>          {
> --- a/xen/common/grant_table.c
> +++ b/xen/common/grant_table.c
> @@ -24,7 +24,7 @@
>   * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
>   */
>  
> -#include <xen/config.h>
> +#include <xen/err.h>
>  #include <xen/iocap.h>
>  #include <xen/lib.h>
>  #include <xen/sched.h>
> @@ -195,6 +195,30 @@ double_gt_unlock(struct grant_table *lgt
>          spin_unlock(&rgt->lock);
>  }
>  
> +static struct domain *gt_lock_target_domain_by_id(domid_t dom)
> +{
> +    struct domain *d;
> +    int rc = GNTST_general_error;
> +
> +    switch ( rcu_lock_target_domain_by_id(dom, &d) )
> +    {
> +    case 0:
> +        return d;
> +
> +    case -ESRCH:
> +        gdprintk(XENLOG_INFO, "Bad domid %d.\n", dom);
> +        rc = GNTST_bad_domain;
> +        break;
> +
> +    case -EPERM:
> +        rc = GNTST_permission_denied;
> +        break;
> +    }
> +
> +    ASSERT(rc < 0 && -rc <= MAX_ERRNO);
> +    return ERR_PTR(rc);
> +}
> +
>  static inline int
>  __get_maptrack_handle(
>      struct grant_table *t)
> @@ -1261,7 +1285,6 @@ gnttab_setup_table(
>      struct grant_table *gt;
>      int            i;
>      unsigned long  gmfn;
> -    domid_t        dom;
>  
>      if ( count != 1 )
>          return -EINVAL;
> @@ -1281,25 +1304,11 @@ gnttab_setup_table(
>          goto out1;
>      }
>  
> -    dom = op.dom;
> -    if ( dom == DOMID_SELF )
> +    d = gt_lock_target_domain_by_id(op.dom);
> +    if ( IS_ERR(d) )
>      {
> -        d = rcu_lock_current_domain();
> -    }
> -    else
> -    {
> -        if ( unlikely((d = rcu_lock_domain_by_id(dom)) == NULL) )
> -        {
> -            gdprintk(XENLOG_INFO, "Bad domid %d.\n", dom);
> -            op.status = GNTST_bad_domain;
> -            goto out1;
> -        }
> -
> -        if ( unlikely(!IS_PRIV_FOR(current->domain, d)) )
> -        {
> -            op.status = GNTST_permission_denied;
> -            goto out2;
> -        }
> +        op.status = PTR_ERR(d);
> +        goto out1;
>      }
>  
>      if ( xsm_grant_setup(current->domain, d) )
> @@ -1352,7 +1361,6 @@ gnttab_query_size(
>  {
>      struct gnttab_query_size op;
>      struct domain *d;
> -    domid_t        dom;
>      int rc;
>  
>      if ( count != 1 )
> @@ -1364,25 +1372,11 @@ gnttab_query_size(
>          return -EFAULT;
>      }
>  
> -    dom = op.dom;
> -    if ( dom == DOMID_SELF )
> -    {
> -        d = rcu_lock_current_domain();
> -    }
> -    else
> +    d = gt_lock_target_domain_by_id(op.dom);
> +    if ( IS_ERR(d) )
>      {
> -        if ( unlikely((d = rcu_lock_domain_by_id(dom)) == NULL) )
> -        {
> -            gdprintk(XENLOG_INFO, "Bad domid %d.\n", dom);
> -            op.status = GNTST_bad_domain;
> -            goto query_out;
> -        }
> -
> -        if ( unlikely(!IS_PRIV_FOR(current->domain, d)) )
> -        {
> -            op.status = GNTST_permission_denied;
> -            goto query_out_unlock;
> -        }
> +        op.status = PTR_ERR(d);
> +        goto query_out;
>      }
>  
>      rc = xsm_grant_query_size(current->domain, d);
> @@ -2240,15 +2234,10 @@ gnttab_get_status_frames(XEN_GUEST_HANDL
>          return -EFAULT;
>      }
>  
> -    rc = rcu_lock_target_domain_by_id(op.dom, &d);
> -    if ( rc < 0 )
> +    d = gt_lock_target_domain_by_id(op.dom);
> +    if ( IS_ERR(d) )
>      {
> -        if ( rc == -ESRCH )
> -            op.status = GNTST_bad_domain;
> -        else if ( rc == -EPERM )
> -            op.status = GNTST_permission_denied;
> -        else
> -            op.status = GNTST_general_error;
> +        op.status = PTR_ERR(d);
>          goto out1;
>      }
>      rc = xsm_grant_setup(current->domain, d);
> --- a/xen/common/memory.c
> +++ b/xen/common/memory.c
> @@ -329,22 +329,9 @@ static long memory_exchange(XEN_GUEST_HA
>          out_chunk_order = exch.in.extent_order - exch.out.extent_order;
>      }
>  
> -    if ( likely(exch.in.domid == DOMID_SELF) )
> -    {
> -        d = rcu_lock_current_domain();
> -    }
> -    else
> -    {
> -        if ( (d = rcu_lock_domain_by_id(exch.in.domid)) == NULL )
> -            goto fail_early;
> -
> -        if ( !IS_PRIV_FOR(current->domain, d) )
> -        {
> -            rcu_unlock_domain(d);
> -            rc = -EPERM;
> -            goto fail_early;
> -        }
> -    }
> +    rc = rcu_lock_target_domain_by_id(exch.in.domid, &d);
> +    if ( rc )
> +        goto fail_early;
>  
>      memflags |= MEMF_bits(domain_clamp_alloc_bitsize(
>          d,
> @@ -583,20 +570,8 @@ long do_memory_op(unsigned long cmd, XEN
>               && (reservation.mem_flags & XENMEMF_populate_on_demand) )
>              args.memflags |= MEMF_populate_on_demand;
>  
> -        if ( likely(reservation.domid == DOMID_SELF) )
> -        {
> -            d = rcu_lock_current_domain();
> -        }
> -        else
> -        {
> -            if ( (d = rcu_lock_domain_by_id(reservation.domid)) == NULL )
> -                return start_extent;
> -            if ( !IS_PRIV_FOR(current->domain, d) )
> -            {
> -                rcu_unlock_domain(d);
> -                return start_extent;
> -            }
> -        }
> +        if ( unlikely(rcu_lock_target_domain_by_id(reservation.domid, &d)) )
> +            return start_extent;
>          args.domain = d;
>  
>          rc = xsm_memory_adjust_reservation(current->domain, d);
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 07 14:48:09 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Sep 2012 14:48: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 1T9zqY-0001Ec-S2; Fri, 07 Sep 2012 14:47:50 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1T9zqW-0001EP-Tp
	for xen-devel@lists.xen.org; Fri, 07 Sep 2012 14:47:49 +0000
Received: from [85.158.139.83:35651] by server-5.bemta-5.messagelabs.com id
	AB/B7-30514-4190A405; Fri, 07 Sep 2012 14:47:48 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1347029266!17923098!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-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27916 invoked from network); 7 Sep 2012 14:47:47 -0000
Received: from mail-ey0-f173.google.com (HELO mail-ey0-f173.google.com)
	(209.85.215.173)
	by server-8.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Sep 2012 14:47:47 -0000
Received: by eaac13 with SMTP id c13so1024697eaa.32
	for <xen-devel@lists.xen.org>; Fri, 07 Sep 2012 07:47:46 -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=d8WlZUTLrrEbj3bQHqLrc3dtE/U7gXkGRBQzaBJQZ+Q=;
	b=V3MHR6bNJT4hYCXONahQCYFq55SJBaLO6WAVs0ilyvYZny4CR/3I3AccmgOeKZ7J/8
	YN7X+FsWXJZNHDTSbSpsDtNfxm4GmyVSYU50pZboGIpE9FH9tWoj7pY3od+9oR5SkrKr
	ycPme6GPxMX79l8ehhkkOHXtMus2IBWQKhcmjIxraZkazzCe2y81UfBMfQkMG3rh4UiD
	tGraJVj6QBQ8zBGhZYGISa0jvOsJpdK4LiZGiX+mZQkmCb9YH2orTMkNgrKmWYX7+Udv
	K/haLKRJZQ77AJ06v4rrfyXlUGNVzJLgLNZ07nBw0GTw19/Y6gdodfspLQv8u/iraqct
	3Lsw==
Received: by 10.14.177.193 with SMTP id d41mr8240209eem.19.1347029266811;
	Fri, 07 Sep 2012 07:47:46 -0700 (PDT)
Received: from [192.168.1.69] (host86-184-74-117.range86-184.btcentralplus.com.
	[86.184.74.117])
	by mx.google.com with ESMTPS id a7sm15258141eep.14.2012.09.07.07.47.43
	(version=SSLv3 cipher=OTHER); Fri, 07 Sep 2012 07:47:46 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Fri, 07 Sep 2012 15:47:40 +0100
From: Keir Fraser <keir.xen@gmail.com>
To: Jan Beulich <JBeulich@suse.com>,
	xen-devel <xen-devel@lists.xen.org>
Message-ID: <CC6FC79C.3E0B5%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [PATCH] adjust a few RCU domain locking calls
Thread-Index: Ac2NB7qwu+5lcvA5BUOYr9XmKfdcDg==
In-Reply-To: <504A0B110200007800099CCD@nat28.tlf.novell.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] [PATCH] adjust a few RCU domain locking calls
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 07/09/2012 13:56, "Jan Beulich" <JBeulich@suse.com> wrote:

> x86's do_physdev_op() had a case where the locking was entirely
> superfluous. Its physdev_map_pirq() further had a case where the lock
> was being obtained too early, needlessly complicating early exit paths.
> 
> Grant table code had two open coded instances of
> rcu_lock_target_domain_by_id(), and a third code section could be
> consolidated by using the newly introduced helper function.
> 
> The memory hypercall code had two more instances of open coding
> rcu_lock_target_domain_by_id(), but note that here this is not just
> cleanup, but also fixes an error return path in memory_exchange() to
> actually return an error.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Acked-by: Keir Fraser <keir@xen.org>

> --- a/xen/arch/x86/physdev.c
> +++ b/xen/arch/x86/physdev.c
> @@ -90,14 +90,10 @@ static int physdev_hvm_map_pirq(
>  int physdev_map_pirq(domid_t domid, int type, int *index, int *pirq_p,
>                       struct msi_info *msi)
>  {
> -    struct domain *d;
> +    struct domain *d = current->domain;
>      int pirq, irq, ret = 0;
>      void *map_data = NULL;
>  
> -    ret = rcu_lock_target_domain_by_id(domid, &d);
> -    if ( ret )
> -        return ret;
> -
>      if ( domid == DOMID_SELF && is_hvm_domain(d) )
>      {
>          /*
> @@ -105,14 +101,15 @@ int physdev_map_pirq(domid_t domid, int
>           * calls back into itself and deadlocks on hvm_domain.irq_lock.
>           */
>          if ( !is_hvm_pv_evtchn_domain(d) )
> -        {
> -            ret = -EINVAL;
> -            goto free_domain;
> -        }
> -        ret = physdev_hvm_map_pirq(d, type, index, pirq_p);
> -        goto free_domain;
> +            return -EINVAL;
> +
> +        return physdev_hvm_map_pirq(d, type, index, pirq_p);
>      }
>  
> +    ret = rcu_lock_target_domain_by_id(domid, &d);
> +    if ( ret )
> +        return ret;
> +
>      if ( !IS_PRIV_FOR(current->domain, d) )
>      {
>          ret = -EPERM;
> @@ -696,13 +693,12 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_H
>      }
>      case PHYSDEVOP_get_free_pirq: {
>          struct physdev_get_free_pirq out;
> -        struct domain *d;
> +        struct domain *d = v->domain;
>  
>          ret = -EFAULT;
>          if ( copy_from_guest(&out, arg, 1) != 0 )
>              break;
>  
> -        d = rcu_lock_current_domain();
>          spin_lock(&d->event_lock);
>  
>          ret = get_free_pirq(d, out.type);
> @@ -717,7 +713,6 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_H
>          }
>  
>          spin_unlock(&d->event_lock);
> -        rcu_unlock_domain(d);
>  
>          if ( ret >= 0 )
>          {
> --- a/xen/common/grant_table.c
> +++ b/xen/common/grant_table.c
> @@ -24,7 +24,7 @@
>   * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
>   */
>  
> -#include <xen/config.h>
> +#include <xen/err.h>
>  #include <xen/iocap.h>
>  #include <xen/lib.h>
>  #include <xen/sched.h>
> @@ -195,6 +195,30 @@ double_gt_unlock(struct grant_table *lgt
>          spin_unlock(&rgt->lock);
>  }
>  
> +static struct domain *gt_lock_target_domain_by_id(domid_t dom)
> +{
> +    struct domain *d;
> +    int rc = GNTST_general_error;
> +
> +    switch ( rcu_lock_target_domain_by_id(dom, &d) )
> +    {
> +    case 0:
> +        return d;
> +
> +    case -ESRCH:
> +        gdprintk(XENLOG_INFO, "Bad domid %d.\n", dom);
> +        rc = GNTST_bad_domain;
> +        break;
> +
> +    case -EPERM:
> +        rc = GNTST_permission_denied;
> +        break;
> +    }
> +
> +    ASSERT(rc < 0 && -rc <= MAX_ERRNO);
> +    return ERR_PTR(rc);
> +}
> +
>  static inline int
>  __get_maptrack_handle(
>      struct grant_table *t)
> @@ -1261,7 +1285,6 @@ gnttab_setup_table(
>      struct grant_table *gt;
>      int            i;
>      unsigned long  gmfn;
> -    domid_t        dom;
>  
>      if ( count != 1 )
>          return -EINVAL;
> @@ -1281,25 +1304,11 @@ gnttab_setup_table(
>          goto out1;
>      }
>  
> -    dom = op.dom;
> -    if ( dom == DOMID_SELF )
> +    d = gt_lock_target_domain_by_id(op.dom);
> +    if ( IS_ERR(d) )
>      {
> -        d = rcu_lock_current_domain();
> -    }
> -    else
> -    {
> -        if ( unlikely((d = rcu_lock_domain_by_id(dom)) == NULL) )
> -        {
> -            gdprintk(XENLOG_INFO, "Bad domid %d.\n", dom);
> -            op.status = GNTST_bad_domain;
> -            goto out1;
> -        }
> -
> -        if ( unlikely(!IS_PRIV_FOR(current->domain, d)) )
> -        {
> -            op.status = GNTST_permission_denied;
> -            goto out2;
> -        }
> +        op.status = PTR_ERR(d);
> +        goto out1;
>      }
>  
>      if ( xsm_grant_setup(current->domain, d) )
> @@ -1352,7 +1361,6 @@ gnttab_query_size(
>  {
>      struct gnttab_query_size op;
>      struct domain *d;
> -    domid_t        dom;
>      int rc;
>  
>      if ( count != 1 )
> @@ -1364,25 +1372,11 @@ gnttab_query_size(
>          return -EFAULT;
>      }
>  
> -    dom = op.dom;
> -    if ( dom == DOMID_SELF )
> -    {
> -        d = rcu_lock_current_domain();
> -    }
> -    else
> +    d = gt_lock_target_domain_by_id(op.dom);
> +    if ( IS_ERR(d) )
>      {
> -        if ( unlikely((d = rcu_lock_domain_by_id(dom)) == NULL) )
> -        {
> -            gdprintk(XENLOG_INFO, "Bad domid %d.\n", dom);
> -            op.status = GNTST_bad_domain;
> -            goto query_out;
> -        }
> -
> -        if ( unlikely(!IS_PRIV_FOR(current->domain, d)) )
> -        {
> -            op.status = GNTST_permission_denied;
> -            goto query_out_unlock;
> -        }
> +        op.status = PTR_ERR(d);
> +        goto query_out;
>      }
>  
>      rc = xsm_grant_query_size(current->domain, d);
> @@ -2240,15 +2234,10 @@ gnttab_get_status_frames(XEN_GUEST_HANDL
>          return -EFAULT;
>      }
>  
> -    rc = rcu_lock_target_domain_by_id(op.dom, &d);
> -    if ( rc < 0 )
> +    d = gt_lock_target_domain_by_id(op.dom);
> +    if ( IS_ERR(d) )
>      {
> -        if ( rc == -ESRCH )
> -            op.status = GNTST_bad_domain;
> -        else if ( rc == -EPERM )
> -            op.status = GNTST_permission_denied;
> -        else
> -            op.status = GNTST_general_error;
> +        op.status = PTR_ERR(d);
>          goto out1;
>      }
>      rc = xsm_grant_setup(current->domain, d);
> --- a/xen/common/memory.c
> +++ b/xen/common/memory.c
> @@ -329,22 +329,9 @@ static long memory_exchange(XEN_GUEST_HA
>          out_chunk_order = exch.in.extent_order - exch.out.extent_order;
>      }
>  
> -    if ( likely(exch.in.domid == DOMID_SELF) )
> -    {
> -        d = rcu_lock_current_domain();
> -    }
> -    else
> -    {
> -        if ( (d = rcu_lock_domain_by_id(exch.in.domid)) == NULL )
> -            goto fail_early;
> -
> -        if ( !IS_PRIV_FOR(current->domain, d) )
> -        {
> -            rcu_unlock_domain(d);
> -            rc = -EPERM;
> -            goto fail_early;
> -        }
> -    }
> +    rc = rcu_lock_target_domain_by_id(exch.in.domid, &d);
> +    if ( rc )
> +        goto fail_early;
>  
>      memflags |= MEMF_bits(domain_clamp_alloc_bitsize(
>          d,
> @@ -583,20 +570,8 @@ long do_memory_op(unsigned long cmd, XEN
>               && (reservation.mem_flags & XENMEMF_populate_on_demand) )
>              args.memflags |= MEMF_populate_on_demand;
>  
> -        if ( likely(reservation.domid == DOMID_SELF) )
> -        {
> -            d = rcu_lock_current_domain();
> -        }
> -        else
> -        {
> -            if ( (d = rcu_lock_domain_by_id(reservation.domid)) == NULL )
> -                return start_extent;
> -            if ( !IS_PRIV_FOR(current->domain, d) )
> -            {
> -                rcu_unlock_domain(d);
> -                return start_extent;
> -            }
> -        }
> +        if ( unlikely(rcu_lock_target_domain_by_id(reservation.domid, &d)) )
> +            return start_extent;
>          args.domain = d;
>  
>          rc = xsm_memory_adjust_reservation(current->domain, d);
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 07 14:48:18 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Sep 2012 14:48:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9zqn-0001Fx-Bp; Fri, 07 Sep 2012 14:48:05 +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 1T9zqi-0001Fq-4C
	for xen-devel@lists.xen.org; Fri, 07 Sep 2012 14:48:00 +0000
Received: from [85.158.139.83:36685] by server-11.bemta-5.messagelabs.com id
	A1/CD-24658-F190A405; Fri, 07 Sep 2012 14:47:59 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1347029278!24942986!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-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27605 invoked from network); 7 Sep 2012 14:47:58 -0000
Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com)
	(74.125.83.45)
	by server-14.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Sep 2012 14:47:58 -0000
Received: by eeke53 with SMTP id e53so1342438eek.32
	for <xen-devel@lists.xen.org>; Fri, 07 Sep 2012 07:47:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=1qLR07dsJRPIeQMCGAwnqctLDwpIGCRGzwYtAPLr7T0=;
	b=JnZp7rffzRu0rJpH9a8Z2CEZOpKcipnS9v8BdIbwvtPyqYNXI4kuwp9mtklgTx9yhF
	rMtpAUOWt9mIqP+/M8FeEGWT+gNiO0kk6Zpu/zhrFVdD3ksw8SAlKzkFuMG3Jgdx+/Iy
	Luv1VtwWHXBvjvfT9CWfpozfT6walhsBjINoW3myHHhe2wZq3L78oDjzw2CdegGo+Cqq
	q4KPF0LfCnkidNoFTYidn6wHg9eADOrVNUS5946YXMmm2lKr+lCw3UsS7weLsezvheaF
	QTEmUuxouXsOOBVq9fDHzRV2ab8+B5eha46I5a0PN6PMhu8EUhFDr14A+miieoviczx8
	+DaQ==
Received: by 10.14.211.3 with SMTP id v3mr8240349eeo.43.1347029278511;
	Fri, 07 Sep 2012 07:47:58 -0700 (PDT)
Received: from [192.168.1.69] (host86-184-74-117.range86-184.btcentralplus.com.
	[86.184.74.117])
	by mx.google.com with ESMTPS id i41sm15293519eem.7.2012.09.07.07.47.56
	(version=SSLv3 cipher=OTHER); Fri, 07 Sep 2012 07:47:57 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Fri, 07 Sep 2012 15:47:54 +0100
From: Keir Fraser <keir.xen@gmail.com>
To: Jan Beulich <JBeulich@suse.com>,
	xen-devel <xen-devel@lists.xen.org>
Message-ID: <CC6FC7AA.3E0B6%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [PATCH] x86/hvm: don't give vector callback higher
	priority than NMI/MCE
Thread-Index: Ac2NB8MIawh6YlzPM06KcB40T1xhVA==
In-Reply-To: <504A0BB50200007800099CD2@nat28.tlf.novell.com>
Mime-version: 1.0
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] x86/hvm: don't give vector callback higher
 priority than NMI/MCE
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/09/2012 13:59, "Jan Beulich" <JBeulich@suse.com> wrote:

> Those two should always be delivered first imo.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Acked-by: Keir Fraser <keir@xen.org>

> --- a/xen/arch/x86/hvm/irq.c
> +++ b/xen/arch/x86/hvm/irq.c
> @@ -395,16 +395,16 @@ struct hvm_intack hvm_vcpu_has_pending_i
>      struct hvm_domain *plat = &v->domain->arch.hvm_domain;
>      int vector;
>  
> -    if ( (plat->irq.callback_via_type == HVMIRQ_callback_vector)
> -         && vcpu_info(v, evtchn_upcall_pending) )
> -        return hvm_intack_vector(plat->irq.callback_via.vector);
> -
>      if ( unlikely(v->nmi_pending) )
>          return hvm_intack_nmi;
>  
>      if ( unlikely(v->mce_pending) )
>          return hvm_intack_mce;
>  
> +    if ( (plat->irq.callback_via_type == HVMIRQ_callback_vector)
> +         && vcpu_info(v, evtchn_upcall_pending) )
> +        return hvm_intack_vector(plat->irq.callback_via.vector);
> +
>      if ( vlapic_accept_pic_intr(v) && plat->vpic[0].int_output )
>          return hvm_intack_pic(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 Sep 07 14:48:18 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Sep 2012 14:48:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1T9zqn-0001Fx-Bp; Fri, 07 Sep 2012 14:48:05 +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 1T9zqi-0001Fq-4C
	for xen-devel@lists.xen.org; Fri, 07 Sep 2012 14:48:00 +0000
Received: from [85.158.139.83:36685] by server-11.bemta-5.messagelabs.com id
	A1/CD-24658-F190A405; Fri, 07 Sep 2012 14:47:59 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1347029278!24942986!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-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27605 invoked from network); 7 Sep 2012 14:47:58 -0000
Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com)
	(74.125.83.45)
	by server-14.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Sep 2012 14:47:58 -0000
Received: by eeke53 with SMTP id e53so1342438eek.32
	for <xen-devel@lists.xen.org>; Fri, 07 Sep 2012 07:47:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=1qLR07dsJRPIeQMCGAwnqctLDwpIGCRGzwYtAPLr7T0=;
	b=JnZp7rffzRu0rJpH9a8Z2CEZOpKcipnS9v8BdIbwvtPyqYNXI4kuwp9mtklgTx9yhF
	rMtpAUOWt9mIqP+/M8FeEGWT+gNiO0kk6Zpu/zhrFVdD3ksw8SAlKzkFuMG3Jgdx+/Iy
	Luv1VtwWHXBvjvfT9CWfpozfT6walhsBjINoW3myHHhe2wZq3L78oDjzw2CdegGo+Cqq
	q4KPF0LfCnkidNoFTYidn6wHg9eADOrVNUS5946YXMmm2lKr+lCw3UsS7weLsezvheaF
	QTEmUuxouXsOOBVq9fDHzRV2ab8+B5eha46I5a0PN6PMhu8EUhFDr14A+miieoviczx8
	+DaQ==
Received: by 10.14.211.3 with SMTP id v3mr8240349eeo.43.1347029278511;
	Fri, 07 Sep 2012 07:47:58 -0700 (PDT)
Received: from [192.168.1.69] (host86-184-74-117.range86-184.btcentralplus.com.
	[86.184.74.117])
	by mx.google.com with ESMTPS id i41sm15293519eem.7.2012.09.07.07.47.56
	(version=SSLv3 cipher=OTHER); Fri, 07 Sep 2012 07:47:57 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Fri, 07 Sep 2012 15:47:54 +0100
From: Keir Fraser <keir.xen@gmail.com>
To: Jan Beulich <JBeulich@suse.com>,
	xen-devel <xen-devel@lists.xen.org>
Message-ID: <CC6FC7AA.3E0B6%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [PATCH] x86/hvm: don't give vector callback higher
	priority than NMI/MCE
Thread-Index: Ac2NB8MIawh6YlzPM06KcB40T1xhVA==
In-Reply-To: <504A0BB50200007800099CD2@nat28.tlf.novell.com>
Mime-version: 1.0
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] x86/hvm: don't give vector callback higher
 priority than NMI/MCE
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/09/2012 13:59, "Jan Beulich" <JBeulich@suse.com> wrote:

> Those two should always be delivered first imo.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Acked-by: Keir Fraser <keir@xen.org>

> --- a/xen/arch/x86/hvm/irq.c
> +++ b/xen/arch/x86/hvm/irq.c
> @@ -395,16 +395,16 @@ struct hvm_intack hvm_vcpu_has_pending_i
>      struct hvm_domain *plat = &v->domain->arch.hvm_domain;
>      int vector;
>  
> -    if ( (plat->irq.callback_via_type == HVMIRQ_callback_vector)
> -         && vcpu_info(v, evtchn_upcall_pending) )
> -        return hvm_intack_vector(plat->irq.callback_via.vector);
> -
>      if ( unlikely(v->nmi_pending) )
>          return hvm_intack_nmi;
>  
>      if ( unlikely(v->mce_pending) )
>          return hvm_intack_mce;
>  
> +    if ( (plat->irq.callback_via_type == HVMIRQ_callback_vector)
> +         && vcpu_info(v, evtchn_upcall_pending) )
> +        return hvm_intack_vector(plat->irq.callback_via.vector);
> +
>      if ( vlapic_accept_pic_intr(v) && plat->vpic[0].int_output )
>          return hvm_intack_pic(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 Sep 07 15:04:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Sep 2012 15:04:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TA065-0001iu-6y; Fri, 07 Sep 2012 15:03:53 +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 1TA063-0001ip-UE
	for xen-devel@lists.xen.org; Fri, 07 Sep 2012 15:03:52 +0000
Received: from [85.158.138.51:9708] by server-8.bemta-3.messagelabs.com id
	B0/34-24700-7DC0A405; Fri, 07 Sep 2012 15:03:51 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1347030230!27536374!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-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25824 invoked from network); 7 Sep 2012 15:03:50 -0000
Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com)
	(74.125.83.45)
	by server-15.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Sep 2012 15:03:50 -0000
Received: by eeke53 with SMTP id e53so1350338eek.32
	for <xen-devel@lists.xen.org>; Fri, 07 Sep 2012 08:03:50 -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=WAyzBH57cJx5zg4BxB+c+uk7iKkb4yv9w2qABRRUG1A=;
	b=RuOgkh5Mi1qU4WBhkMWvRLDkHuIObsIaJqIJOIOQeJbeQLPprDB1giW2qLv401YOSn
	tiesqJApWZfZnITHYNM95+vrFiwyqewz2/t2PHehGbBRP2bulM7H5WLwrv1KHPEnHFe2
	LNi+zPJLFEWaEWN8JYe+5I4C/DLKSoh8Vjb7u6zWeRcQAwNnyxyIpgVGQhfuV7S7mqaw
	nYSnZRxP3XoXHmghQHm0213it61HVSVZg8XP5jpPcE5na/h3jGzm0DP1TcR4ENJq1DG1
	1/qeRRRdLtaTIhYQr6QrVjxhuRpaVAiUbYKVyBiW3+g7lA9KKNwazpQyDx9AOieRMS79
	lcRQ==
Received: by 10.14.203.70 with SMTP id e46mr8515886eeo.2.1347030230410;
	Fri, 07 Sep 2012 08:03:50 -0700 (PDT)
Received: from [192.168.1.69] (host86-184-74-117.range86-184.btcentralplus.com.
	[86.184.74.117])
	by mx.google.com with ESMTPS id y1sm15441112eel.0.2012.09.07.08.03.47
	(version=SSLv3 cipher=OTHER); Fri, 07 Sep 2012 08:03:49 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Fri, 07 Sep 2012 16:03:44 +0100
From: Keir Fraser <keir.xen@gmail.com>
To: Jan Beulich <JBeulich@suse.com>, Andrew Cooper <andrew.cooper3@citrix.com>
Message-ID: <CC6FCB60.3E0B9%keir.xen@gmail.com>
Thread-Topic: [PATCH] kexec/noreboot: Don't kexec_crash() if noreboot has been
	requested.
Thread-Index: Ac2NCflGpYFSIhc6KUSQymlXdZsW1g==
In-Reply-To: <504A0FDA0200007800099D10@nat28.tlf.novell.com>
Mime-version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] kexec/noreboot: Don't kexec_crash() if
 noreboot has been requested.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/09/2012 14:16, "Jan Beulich" <JBeulich@suse.com> wrote:

>>>> On 07.09.12 at 15:05, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
>> This issue came up when debugging pcpu linked list corruption (patches
>> for that issue to follow).
> 
> Hmm, that's a matter of taste of course. Nor is running kdump
> really a (direct) reboot action. Both ways have their reasoning
> imo, so I'm not sure whether keeping things as is or applying the
> patch is the better thing.

I note though that kexec_crash() should be stubbed out in the header file
when !CONFIG_KEXEC, rather than ifdef at the caller. By the by.

 -- 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 Sep 07 15:04:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Sep 2012 15:04:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TA065-0001iu-6y; Fri, 07 Sep 2012 15:03:53 +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 1TA063-0001ip-UE
	for xen-devel@lists.xen.org; Fri, 07 Sep 2012 15:03:52 +0000
Received: from [85.158.138.51:9708] by server-8.bemta-3.messagelabs.com id
	B0/34-24700-7DC0A405; Fri, 07 Sep 2012 15:03:51 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1347030230!27536374!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-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25824 invoked from network); 7 Sep 2012 15:03:50 -0000
Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com)
	(74.125.83.45)
	by server-15.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Sep 2012 15:03:50 -0000
Received: by eeke53 with SMTP id e53so1350338eek.32
	for <xen-devel@lists.xen.org>; Fri, 07 Sep 2012 08:03:50 -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=WAyzBH57cJx5zg4BxB+c+uk7iKkb4yv9w2qABRRUG1A=;
	b=RuOgkh5Mi1qU4WBhkMWvRLDkHuIObsIaJqIJOIOQeJbeQLPprDB1giW2qLv401YOSn
	tiesqJApWZfZnITHYNM95+vrFiwyqewz2/t2PHehGbBRP2bulM7H5WLwrv1KHPEnHFe2
	LNi+zPJLFEWaEWN8JYe+5I4C/DLKSoh8Vjb7u6zWeRcQAwNnyxyIpgVGQhfuV7S7mqaw
	nYSnZRxP3XoXHmghQHm0213it61HVSVZg8XP5jpPcE5na/h3jGzm0DP1TcR4ENJq1DG1
	1/qeRRRdLtaTIhYQr6QrVjxhuRpaVAiUbYKVyBiW3+g7lA9KKNwazpQyDx9AOieRMS79
	lcRQ==
Received: by 10.14.203.70 with SMTP id e46mr8515886eeo.2.1347030230410;
	Fri, 07 Sep 2012 08:03:50 -0700 (PDT)
Received: from [192.168.1.69] (host86-184-74-117.range86-184.btcentralplus.com.
	[86.184.74.117])
	by mx.google.com with ESMTPS id y1sm15441112eel.0.2012.09.07.08.03.47
	(version=SSLv3 cipher=OTHER); Fri, 07 Sep 2012 08:03:49 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Fri, 07 Sep 2012 16:03:44 +0100
From: Keir Fraser <keir.xen@gmail.com>
To: Jan Beulich <JBeulich@suse.com>, Andrew Cooper <andrew.cooper3@citrix.com>
Message-ID: <CC6FCB60.3E0B9%keir.xen@gmail.com>
Thread-Topic: [PATCH] kexec/noreboot: Don't kexec_crash() if noreboot has been
	requested.
Thread-Index: Ac2NCflGpYFSIhc6KUSQymlXdZsW1g==
In-Reply-To: <504A0FDA0200007800099D10@nat28.tlf.novell.com>
Mime-version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] kexec/noreboot: Don't kexec_crash() if
 noreboot has been requested.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/09/2012 14:16, "Jan Beulich" <JBeulich@suse.com> wrote:

>>>> On 07.09.12 at 15:05, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
>> This issue came up when debugging pcpu linked list corruption (patches
>> for that issue to follow).
> 
> Hmm, that's a matter of taste of course. Nor is running kdump
> really a (direct) reboot action. Both ways have their reasoning
> imo, so I'm not sure whether keeping things as is or applying the
> patch is the better thing.

I note though that kexec_crash() should be stubbed out in the header file
when !CONFIG_KEXEC, rather than ifdef at the caller. By the by.

 -- 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 Sep 07 15:05:40 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Sep 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 1TA07T-0001mr-MF; Fri, 07 Sep 2012 15:05:19 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1TA07S-0001mk-Ry
	for xen-devel@lists.xen.org; Fri, 07 Sep 2012 15:05:19 +0000
Received: from [85.158.138.51:7237] by server-4.bemta-3.messagelabs.com id
	9B/07-24831-D2D0A405; Fri, 07 Sep 2012 15:05:17 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1347030315!29261969!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzM0MTMw\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27638 invoked from network); 7 Sep 2012 15:05:17 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-8.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 7 Sep 2012 15:05: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 q87F594Q019837
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 7 Sep 2012 15:05:10 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q87F58eg015774
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 7 Sep 2012 15:05:09 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
	q87F58oG031870; Fri, 7 Sep 2012 10:05:08 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 07 Sep 2012 08:05:08 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 78F08402E4; Fri,  7 Sep 2012 10:54:33 -0400 (EDT)
Date: Fri, 7 Sep 2012 10:54:33 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: "Justin M. Forbes" <jmforbes@linuxtx.org>
Message-ID: <20120907145433.GA5378@phenom.dumpdata.com>
References: <1347018043-21252-1-git-send-email-stefan.bader@canonical.com>
	<504A05B00200007800099C7B@nat28.tlf.novell.com>
	<5049F4E9.9050306@canonical.com>
	<504A1A950200007800099D4C@nat28.tlf.novell.com>
	<20120907142251.GA20096@linuxtx.org>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120907142251.GA20096@linuxtx.org>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Matt Wilson <msw@amazon.com>, Stefan Bader <stefan.bader@canonical.com>,
	Jan Beulich <JBeulich@suse.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH/RFC] Fix xsave bug on older Xen hypervisors
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> > But iirc that bad patch is a Linux side one (i.e. you're trying to fix
> > something upstream that isn't upstream)?
> > 
> Right, so the patch that this improves upon, and that Fedora and Ubuntu are
> currently carrying is not upstream because:
> 
> a) It's crap, it cripples upstream xen users, but doesn't impact RHEL xen
> users because xsave was never supported there.
> 
> b) The hypervisor was patched to make it unnecessary quite some time ago,
> and we hoped EC2 would eventually pick up that correct patch and we could
> drop the crap kernel patch.
> 
> Unfortunately this has not happened. We are at a point where EC2 really is
> a quirk that has to be worked around. Distros do not want to maintain
> a separate EC2 build of the kernel, so the easiest way is to cripple
> current upstream xen users.  This quirk is unfortunately the best possible
> solution.  Having it upstream also makes it possible for any user to build
> an upstream kernel that will run on EC2 without having to dig a random
> patch out of a vendor kernel.

Sure. Jan is asking though for actual confirmation that the upstream kernel
does indeed go belly up without a workaround.
And whether this patch (which I would did since Canonical is carrying it) does
fix the issue.

I am still a newbie on the Amazon EC2 upload your kernel thing (hint, would
appreciate somebody taking this patch and trying it out).

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 07 15:05:40 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Sep 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 1TA07T-0001mr-MF; Fri, 07 Sep 2012 15:05:19 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1TA07S-0001mk-Ry
	for xen-devel@lists.xen.org; Fri, 07 Sep 2012 15:05:19 +0000
Received: from [85.158.138.51:7237] by server-4.bemta-3.messagelabs.com id
	9B/07-24831-D2D0A405; Fri, 07 Sep 2012 15:05:17 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1347030315!29261969!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzM0MTMw\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27638 invoked from network); 7 Sep 2012 15:05:17 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-8.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 7 Sep 2012 15:05: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 q87F594Q019837
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 7 Sep 2012 15:05:10 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q87F58eg015774
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 7 Sep 2012 15:05:09 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
	q87F58oG031870; Fri, 7 Sep 2012 10:05:08 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 07 Sep 2012 08:05:08 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 78F08402E4; Fri,  7 Sep 2012 10:54:33 -0400 (EDT)
Date: Fri, 7 Sep 2012 10:54:33 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: "Justin M. Forbes" <jmforbes@linuxtx.org>
Message-ID: <20120907145433.GA5378@phenom.dumpdata.com>
References: <1347018043-21252-1-git-send-email-stefan.bader@canonical.com>
	<504A05B00200007800099C7B@nat28.tlf.novell.com>
	<5049F4E9.9050306@canonical.com>
	<504A1A950200007800099D4C@nat28.tlf.novell.com>
	<20120907142251.GA20096@linuxtx.org>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120907142251.GA20096@linuxtx.org>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Matt Wilson <msw@amazon.com>, Stefan Bader <stefan.bader@canonical.com>,
	Jan Beulich <JBeulich@suse.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH/RFC] Fix xsave bug on older Xen hypervisors
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> > But iirc that bad patch is a Linux side one (i.e. you're trying to fix
> > something upstream that isn't upstream)?
> > 
> Right, so the patch that this improves upon, and that Fedora and Ubuntu are
> currently carrying is not upstream because:
> 
> a) It's crap, it cripples upstream xen users, but doesn't impact RHEL xen
> users because xsave was never supported there.
> 
> b) The hypervisor was patched to make it unnecessary quite some time ago,
> and we hoped EC2 would eventually pick up that correct patch and we could
> drop the crap kernel patch.
> 
> Unfortunately this has not happened. We are at a point where EC2 really is
> a quirk that has to be worked around. Distros do not want to maintain
> a separate EC2 build of the kernel, so the easiest way is to cripple
> current upstream xen users.  This quirk is unfortunately the best possible
> solution.  Having it upstream also makes it possible for any user to build
> an upstream kernel that will run on EC2 without having to dig a random
> patch out of a vendor kernel.

Sure. Jan is asking though for actual confirmation that the upstream kernel
does indeed go belly up without a workaround.
And whether this patch (which I would did since Canonical is carrying it) does
fix the issue.

I am still a newbie on the Amazon EC2 upload your kernel thing (hint, would
appreciate somebody taking this patch and trying it out).

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 07 15:06:11 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Sep 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 1TA084-0001qH-3P; Fri, 07 Sep 2012 15:05:56 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1TA082-0001pa-Fd
	for xen-devel@lists.xen.org; Fri, 07 Sep 2012 15:05:54 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1347030333!8976595!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-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26404 invoked from network); 7 Sep 2012 15:05:34 -0000
Received: from mail-ey0-f173.google.com (HELO mail-ey0-f173.google.com)
	(209.85.215.173)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Sep 2012 15:05:34 -0000
Received: by eaac13 with SMTP id c13so1030792eaa.32
	for <xen-devel@lists.xen.org>; Fri, 07 Sep 2012 08:05:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=ldBTuB4gZQXbiG/Lffll6VGOlsfDot8m2hMec8ax/R4=;
	b=bvNgbxxPxeoXBSUfEVqn2D9eqcliQDORZwDGZM7E+l3QzWdCe5Rg+yQMZkQoseJK2z
	1oncsgjgZgW04zNTiq1dgx0Gd8Bp+wcTiTsfkuWyMQcpl1mvk0vHHfhLH/iyZwyG4peH
	5GFQR+A1upVKBxf1+TciE2IIo5vgW1ygCIVDH963bQEpqtKceS1jcpkOPWLe2W3ij9mH
	oxrxA73+b6L0J8mb5bq1i4unWIiym+qdS7toDF23ynpfPiGAovV+8bHs2fNCXBHfONVa
	qy979kvlKI2ltPRgiFHhLZUOr3ze93DUtrqlivGvXJ9fTOBk8AIcywkTzfobGeVpKa+V
	zrYQ==
Received: by 10.14.213.137 with SMTP id a9mr8341236eep.38.1347030333615;
	Fri, 07 Sep 2012 08:05:33 -0700 (PDT)
Received: from [192.168.1.69] (host86-184-74-117.range86-184.btcentralplus.com.
	[86.184.74.117])
	by mx.google.com with ESMTPS id k49sm15433013een.4.2012.09.07.08.05.32
	(version=SSLv3 cipher=OTHER); Fri, 07 Sep 2012 08:05:33 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Fri, 07 Sep 2012 16:05:29 +0100
From: Keir Fraser <keir.xen@gmail.com>
To: Jan Beulich <JBeulich@suse.com>,
	xen-devel <xen-devel@lists.xen.org>
Message-ID: <CC6FCBC9.3E0BB%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [PATCH] VT-d: split .ack and .disable DMA-MSI actors
Thread-Index: Ac2NCjfci5Z07jaCaEmZy2kTz8SqLw==
In-Reply-To: <504A08930200007800099C9A@nat28.tlf.novell.com>
Mime-version: 1.0
Cc: xiantao.zhang@intel.com
Subject: Re: [Xen-devel] [PATCH] VT-d: split .ack and .disable DMA-MSI actors
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/09/2012 13:45, "Jan Beulich" <JBeulich@suse.com> wrote:

> Calling irq_complete_move() from .disable is wrong, breaking S3 resume.
> 
> Comparing with all other .ack actors, it was also missing a call to
> move_{native,masked}_irq(). As the actor is masking its interrupt
> anyway (albeit it's not immediately obvious why), the latter is the
> better choice.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

As far as I understand it
Acked-by: Keir Fraser <keir@xen.org>

I guess you are looking for an Intel ack as well.

 -- Keir

> --- a/xen/drivers/passthrough/vtd/iommu.c
> +++ b/xen/drivers/passthrough/vtd/iommu.c
> @@ -1039,8 +1039,6 @@ static void dma_msi_mask(struct irq_desc
>      unsigned long flags;
>      struct iommu *iommu = desc->action->dev_id;
>  
> -    irq_complete_move(desc);
> -
>      /* mask it */
>      spin_lock_irqsave(&iommu->register_lock, flags);
>      dmar_writel(iommu->reg, DMAR_FECTL_REG, DMA_FECTL_IM);
> @@ -1053,6 +1051,13 @@ static unsigned int dma_msi_startup(stru
>      return 0;
>  }
>  
> +static void dma_msi_ack(struct irq_desc *desc)
> +{
> +    irq_complete_move(desc);
> +    dma_msi_mask(desc);
> +    move_masked_irq(desc);
> +}
> +
>  static void dma_msi_end(struct irq_desc *desc, u8 vector)
>  {
>      dma_msi_unmask(desc);
> @@ -1114,7 +1119,7 @@ static hw_irq_controller dma_msi_type =
>      .shutdown = dma_msi_mask,
>      .enable = dma_msi_unmask,
>      .disable = dma_msi_mask,
> -    .ack = dma_msi_mask,
> +    .ack = dma_msi_ack,
>      .end = dma_msi_end,
>      .set_affinity = dma_msi_set_affinity,
>  };
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Sep 07 15:06:11 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Sep 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 1TA084-0001qH-3P; Fri, 07 Sep 2012 15:05:56 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1TA082-0001pa-Fd
	for xen-devel@lists.xen.org; Fri, 07 Sep 2012 15:05:54 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1347030333!8976595!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-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26404 invoked from network); 7 Sep 2012 15:05:34 -0000
Received: from mail-ey0-f173.google.com (HELO mail-ey0-f173.google.com)
	(209.85.215.173)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Sep 2012 15:05:34 -0000
Received: by eaac13 with SMTP id c13so1030792eaa.32
	for <xen-devel@lists.xen.org>; Fri, 07 Sep 2012 08:05:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=ldBTuB4gZQXbiG/Lffll6VGOlsfDot8m2hMec8ax/R4=;
	b=bvNgbxxPxeoXBSUfEVqn2D9eqcliQDORZwDGZM7E+l3QzWdCe5Rg+yQMZkQoseJK2z
	1oncsgjgZgW04zNTiq1dgx0Gd8Bp+wcTiTsfkuWyMQcpl1mvk0vHHfhLH/iyZwyG4peH
	5GFQR+A1upVKBxf1+TciE2IIo5vgW1ygCIVDH963bQEpqtKceS1jcpkOPWLe2W3ij9mH
	oxrxA73+b6L0J8mb5bq1i4unWIiym+qdS7toDF23ynpfPiGAovV+8bHs2fNCXBHfONVa
	qy979kvlKI2ltPRgiFHhLZUOr3ze93DUtrqlivGvXJ9fTOBk8AIcywkTzfobGeVpKa+V
	zrYQ==
Received: by 10.14.213.137 with SMTP id a9mr8341236eep.38.1347030333615;
	Fri, 07 Sep 2012 08:05:33 -0700 (PDT)
Received: from [192.168.1.69] (host86-184-74-117.range86-184.btcentralplus.com.
	[86.184.74.117])
	by mx.google.com with ESMTPS id k49sm15433013een.4.2012.09.07.08.05.32
	(version=SSLv3 cipher=OTHER); Fri, 07 Sep 2012 08:05:33 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Fri, 07 Sep 2012 16:05:29 +0100
From: Keir Fraser <keir.xen@gmail.com>
To: Jan Beulich <JBeulich@suse.com>,
	xen-devel <xen-devel@lists.xen.org>
Message-ID: <CC6FCBC9.3E0BB%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [PATCH] VT-d: split .ack and .disable DMA-MSI actors
Thread-Index: Ac2NCjfci5Z07jaCaEmZy2kTz8SqLw==
In-Reply-To: <504A08930200007800099C9A@nat28.tlf.novell.com>
Mime-version: 1.0
Cc: xiantao.zhang@intel.com
Subject: Re: [Xen-devel] [PATCH] VT-d: split .ack and .disable DMA-MSI actors
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/09/2012 13:45, "Jan Beulich" <JBeulich@suse.com> wrote:

> Calling irq_complete_move() from .disable is wrong, breaking S3 resume.
> 
> Comparing with all other .ack actors, it was also missing a call to
> move_{native,masked}_irq(). As the actor is masking its interrupt
> anyway (albeit it's not immediately obvious why), the latter is the
> better choice.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

As far as I understand it
Acked-by: Keir Fraser <keir@xen.org>

I guess you are looking for an Intel ack as well.

 -- Keir

> --- a/xen/drivers/passthrough/vtd/iommu.c
> +++ b/xen/drivers/passthrough/vtd/iommu.c
> @@ -1039,8 +1039,6 @@ static void dma_msi_mask(struct irq_desc
>      unsigned long flags;
>      struct iommu *iommu = desc->action->dev_id;
>  
> -    irq_complete_move(desc);
> -
>      /* mask it */
>      spin_lock_irqsave(&iommu->register_lock, flags);
>      dmar_writel(iommu->reg, DMAR_FECTL_REG, DMA_FECTL_IM);
> @@ -1053,6 +1051,13 @@ static unsigned int dma_msi_startup(stru
>      return 0;
>  }
>  
> +static void dma_msi_ack(struct irq_desc *desc)
> +{
> +    irq_complete_move(desc);
> +    dma_msi_mask(desc);
> +    move_masked_irq(desc);
> +}
> +
>  static void dma_msi_end(struct irq_desc *desc, u8 vector)
>  {
>      dma_msi_unmask(desc);
> @@ -1114,7 +1119,7 @@ static hw_irq_controller dma_msi_type =
>      .shutdown = dma_msi_mask,
>      .enable = dma_msi_unmask,
>      .disable = dma_msi_mask,
> -    .ack = dma_msi_mask,
> +    .ack = dma_msi_ack,
>      .end = dma_msi_end,
>      .set_affinity = dma_msi_set_affinity,
>  };
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Sep 07 15:07:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Sep 2012 15: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 1TA09c-000207-JW; Fri, 07 Sep 2012 15:07:32 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1TA09Z-0001zc-IW
	for xen-devel@lists.xen.org; Fri, 07 Sep 2012 15:07:31 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1347030435!6651670!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-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29997 invoked from network); 7 Sep 2012 15:07:15 -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;
	7 Sep 2012 15:07:15 -0000
Received: by eaac13 with SMTP id c13so1031406eaa.32
	for <xen-devel@lists.xen.org>; Fri, 07 Sep 2012 08:07:15 -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=VsRGgC+Y61P8F3I4XWJcOuDkRdkHvGGq5J7pJo6u1/8=;
	b=SmIyEu+EtzQlRXkm/SP6O2QlA405+GsWSvq8PH3TZbzos1hG8DByYZlwm5pBl3yK4E
	vd+RQe8BWJpY6oFupQEDuZsdWJhdT1HivwZ1lEoLY+7SwOViRYoGOUXlU+dc3xz1nME/
	jjtnNz6mJKPg+E2/PBYzMVqQBlEDpSexj7fI9V15MhE7Zr1W9AQ060SiW+FpevaEfl3I
	2SI/qz3bMFU5K5ZGjeb7B1cFGZxR/BDt97IhnjtMiu+giZhwYQm6xL41uA+2C1eIF+jk
	tA+rZ7K7eGHWKGmN26znYqe21SgaeFxbg7s7KltfxpZxTrLSG/+fPe0KqvrPwPnFqHTZ
	+86A==
Received: by 10.14.204.200 with SMTP id h48mr8506767eeo.7.1347030435437;
	Fri, 07 Sep 2012 08:07:15 -0700 (PDT)
Received: from [192.168.1.69] (host86-184-74-117.range86-184.btcentralplus.com.
	[86.184.74.117])
	by mx.google.com with ESMTPS id h2sm15448549eeo.3.2012.09.07.08.07.12
	(version=SSLv3 cipher=OTHER); Fri, 07 Sep 2012 08:07:14 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Fri, 07 Sep 2012 16:07:05 +0100
From: Keir Fraser <keir.xen@gmail.com>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <CC6FCC29.3E0ED%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [PATCH, resend] x86/32-on-64: adjust Dom0 initial
	page table layout
Thread-Index: Ac2NCnEUjKdibl1sdkCo0r5RbUi27w==
In-Reply-To: <504A0D760200007800099CEE@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] [PATCH,
 resend] x86/32-on-64: adjust Dom0 initial page table layout
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 07/09/2012 14:06, "Jan Beulich" <JBeulich@suse.com> wrote:

>>>> On 07.09.12 at 14:42, Keir Fraser <keir@xen.org> wrote:
>> On 07/09/2012 13:39, "Jan Beulich" <JBeulich@suse.com> wrote:
>> 
>>> Drop the unnecessary reservation of the L4 page for 32on64 Dom0, and
>>> allocate its L3 first (to match behavior when running identical bit-
>>> width hypervisor and Dom0 kernel).
>>> 
>>> Reported-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
>>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
>> 
>> Acked-by: Keir Fraser <keir@xen.org>
>> 
>> Not for 4.2.0.
> 
> Of course, that's why we held it back. I think that ought to be
> the default until the release, and we want to explicitly name the
> ones we want ported over.

Yes, good.

 -- 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 Sep 07 15:07:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Sep 2012 15: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 1TA09c-000207-JW; Fri, 07 Sep 2012 15:07:32 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1TA09Z-0001zc-IW
	for xen-devel@lists.xen.org; Fri, 07 Sep 2012 15:07:31 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1347030435!6651670!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-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29997 invoked from network); 7 Sep 2012 15:07:15 -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;
	7 Sep 2012 15:07:15 -0000
Received: by eaac13 with SMTP id c13so1031406eaa.32
	for <xen-devel@lists.xen.org>; Fri, 07 Sep 2012 08:07:15 -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=VsRGgC+Y61P8F3I4XWJcOuDkRdkHvGGq5J7pJo6u1/8=;
	b=SmIyEu+EtzQlRXkm/SP6O2QlA405+GsWSvq8PH3TZbzos1hG8DByYZlwm5pBl3yK4E
	vd+RQe8BWJpY6oFupQEDuZsdWJhdT1HivwZ1lEoLY+7SwOViRYoGOUXlU+dc3xz1nME/
	jjtnNz6mJKPg+E2/PBYzMVqQBlEDpSexj7fI9V15MhE7Zr1W9AQ060SiW+FpevaEfl3I
	2SI/qz3bMFU5K5ZGjeb7B1cFGZxR/BDt97IhnjtMiu+giZhwYQm6xL41uA+2C1eIF+jk
	tA+rZ7K7eGHWKGmN26znYqe21SgaeFxbg7s7KltfxpZxTrLSG/+fPe0KqvrPwPnFqHTZ
	+86A==
Received: by 10.14.204.200 with SMTP id h48mr8506767eeo.7.1347030435437;
	Fri, 07 Sep 2012 08:07:15 -0700 (PDT)
Received: from [192.168.1.69] (host86-184-74-117.range86-184.btcentralplus.com.
	[86.184.74.117])
	by mx.google.com with ESMTPS id h2sm15448549eeo.3.2012.09.07.08.07.12
	(version=SSLv3 cipher=OTHER); Fri, 07 Sep 2012 08:07:14 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Fri, 07 Sep 2012 16:07:05 +0100
From: Keir Fraser <keir.xen@gmail.com>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <CC6FCC29.3E0ED%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [PATCH, resend] x86/32-on-64: adjust Dom0 initial
	page table layout
Thread-Index: Ac2NCnEUjKdibl1sdkCo0r5RbUi27w==
In-Reply-To: <504A0D760200007800099CEE@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] [PATCH,
 resend] x86/32-on-64: adjust Dom0 initial page table layout
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 07/09/2012 14:06, "Jan Beulich" <JBeulich@suse.com> wrote:

>>>> On 07.09.12 at 14:42, Keir Fraser <keir@xen.org> wrote:
>> On 07/09/2012 13:39, "Jan Beulich" <JBeulich@suse.com> wrote:
>> 
>>> Drop the unnecessary reservation of the L4 page for 32on64 Dom0, and
>>> allocate its L3 first (to match behavior when running identical bit-
>>> width hypervisor and Dom0 kernel).
>>> 
>>> Reported-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
>>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
>> 
>> Acked-by: Keir Fraser <keir@xen.org>
>> 
>> Not for 4.2.0.
> 
> Of course, that's why we held it back. I think that ought to be
> the default until the release, and we want to explicitly name the
> ones we want ported over.

Yes, good.

 -- 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 Sep 07 15:09:19 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Sep 2012 15:09:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TA0B9-0002AW-3j; Fri, 07 Sep 2012 15:09:07 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <thanos.makatos@citrix.com>) id 1TA0B8-0002AP-H8
	for xen-devel@lists.xensource.com; Fri, 07 Sep 2012 15:09:06 +0000
Received: from [85.158.143.99:51718] by server-1.bemta-4.messagelabs.com id
	C3/0D-12504-11E0A405; Fri, 07 Sep 2012 15:09:05 +0000
X-Env-Sender: thanos.makatos@citrix.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1347030545!28569822!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTIyMTE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18724 invoked from network); 7 Sep 2012 15:09:05 -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;
	7 Sep 2012 15:09:05 -0000
X-IronPort-AV: E=Sophos;i="4.80,387,1344211200"; d="scan'208";a="14413319"
Received: from lonpmailmx02.citrite.net ([10.30.203.163])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Sep 2012 15:08:52 +0000
Received: from LONPMAILBOX01.citrite.net ([10.30.224.160]) by
	LONPMAILMX02.citrite.net ([10.30.203.163]) with mapi; Fri, 7 Sep 2012
	16:08:52 +0100
From: Thanos Makatos <thanos.makatos@citrix.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Date: Fri, 7 Sep 2012 16:08:51 +0100
Thread-Topic: blktap3 in C++?
Thread-Index: Ac2NCrBr5o+jaK0ZTumGtQ28appYgw==
Message-ID: <4B45B535F7F6BE4CB1C044ED5115CDDE011A6DAD77DF@LONPMAILBOX01.citrite.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Subject: [Xen-devel] blktap3 in C++?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

I was wondering whether it would make sense to have blktap3 in C++. I don't have very strong feelings about it; I'd prefer to have it in C++, but it's already written in C and it works. The benefits of having it in C++ would be code clarity and maintainability. I bring this up now because I'm currently cleaning it up, so it's the best time to do it, should we decide to do so.

--
Thanos Makatos



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 07 15:09:19 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Sep 2012 15:09:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TA0B9-0002AW-3j; Fri, 07 Sep 2012 15:09:07 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <thanos.makatos@citrix.com>) id 1TA0B8-0002AP-H8
	for xen-devel@lists.xensource.com; Fri, 07 Sep 2012 15:09:06 +0000
Received: from [85.158.143.99:51718] by server-1.bemta-4.messagelabs.com id
	C3/0D-12504-11E0A405; Fri, 07 Sep 2012 15:09:05 +0000
X-Env-Sender: thanos.makatos@citrix.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1347030545!28569822!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTIyMTE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18724 invoked from network); 7 Sep 2012 15:09:05 -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;
	7 Sep 2012 15:09:05 -0000
X-IronPort-AV: E=Sophos;i="4.80,387,1344211200"; d="scan'208";a="14413319"
Received: from lonpmailmx02.citrite.net ([10.30.203.163])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Sep 2012 15:08:52 +0000
Received: from LONPMAILBOX01.citrite.net ([10.30.224.160]) by
	LONPMAILMX02.citrite.net ([10.30.203.163]) with mapi; Fri, 7 Sep 2012
	16:08:52 +0100
From: Thanos Makatos <thanos.makatos@citrix.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Date: Fri, 7 Sep 2012 16:08:51 +0100
Thread-Topic: blktap3 in C++?
Thread-Index: Ac2NCrBr5o+jaK0ZTumGtQ28appYgw==
Message-ID: <4B45B535F7F6BE4CB1C044ED5115CDDE011A6DAD77DF@LONPMAILBOX01.citrite.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Subject: [Xen-devel] blktap3 in C++?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

I was wondering whether it would make sense to have blktap3 in C++. I don't have very strong feelings about it; I'd prefer to have it in C++, but it's already written in C and it works. The benefits of having it in C++ would be code clarity and maintainability. I bring this up now because I'm currently cleaning it up, so it's the best time to do it, should we decide to do so.

--
Thanos Makatos



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 07 15:16:17 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Sep 2012 15:16: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 1TA0Hn-0002Zo-Vo; Fri, 07 Sep 2012 15:15: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 1TA0Hm-0002Zj-V7
	for xen-devel@lists.xensource.com; Fri, 07 Sep 2012 15:15:59 +0000
Received: from [85.158.138.51:36814] by server-6.bemta-3.messagelabs.com id
	15/1A-29694-DAF0A405; Fri, 07 Sep 2012 15:15:57 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1347030957!29220406!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTIyMTE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7733 invoked from network); 7 Sep 2012 15:15:57 -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;
	7 Sep 2012 15:15:57 -0000
X-IronPort-AV: E=Sophos;i="4.80,387,1344211200"; d="scan'208";a="14413463"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Sep 2012 15:15: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.279.1; Fri, 7 Sep 2012
	16:15:56 +0100
Message-ID: <1347030955.30018.115.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "fantonifabio@tiscali.it" <fantonifabio@tiscali.it>
Date: Fri, 7 Sep 2012 16:15:55 +0100
In-Reply-To: <5049EC11.9080302@tiscali.it>
References: <5049EC11.9080302@tiscali.it>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Test report of xen 4.2.0-rc4
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 testing.

On Fri, 2012-09-07 at 13:44 +0100, Fabio Fantoni wrote:
> - IMPORTANT - On restore network is up but not working, tried with W7 
> pro 64 bit with gplpv last build (357) on qemu-xen-traditional

Our automated tests aren't seeing this, might it be a GPLPV issue? Can
you reproduce with e.g. PV Linux (or PVHVM Linux for that matter)?

> - Cdrom hotswap is not working, tried with W7 pro 64 bit with gplpv last 
> build (357) on qemu-xen-traditional
> xl -vvv cd-eject W7 hdb
> libxl: debug: libxl.c:2143:libxl_cdrom_insert: ao 0x1461980: create: 
> how=(nil) callback=(nil) poller=0x14619e0
> Errore di segmentazione

This doesn't happen for me. Please can you run this one under gdb and
when it fails type "bt" to get a backtrace.

> - Vnc is working but only with parameters not supplied as value to the 
> vfb key, but with vfb key is not working

Whether or not that works is very much a function of exactly what the
rest of your guest config looks like (it depends on PV for HVM for one
thing).

You've reported enough bugs now that I shouldn't need to remind you
about providing guest config files or link to
http://wiki.xen.org/wiki/Reporting_Bugs_against_Xen again.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 07 15:16:17 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Sep 2012 15:16: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 1TA0Hn-0002Zo-Vo; Fri, 07 Sep 2012 15:15: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 1TA0Hm-0002Zj-V7
	for xen-devel@lists.xensource.com; Fri, 07 Sep 2012 15:15:59 +0000
Received: from [85.158.138.51:36814] by server-6.bemta-3.messagelabs.com id
	15/1A-29694-DAF0A405; Fri, 07 Sep 2012 15:15:57 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1347030957!29220406!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTIyMTE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7733 invoked from network); 7 Sep 2012 15:15:57 -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;
	7 Sep 2012 15:15:57 -0000
X-IronPort-AV: E=Sophos;i="4.80,387,1344211200"; d="scan'208";a="14413463"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Sep 2012 15:15: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.279.1; Fri, 7 Sep 2012
	16:15:56 +0100
Message-ID: <1347030955.30018.115.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "fantonifabio@tiscali.it" <fantonifabio@tiscali.it>
Date: Fri, 7 Sep 2012 16:15:55 +0100
In-Reply-To: <5049EC11.9080302@tiscali.it>
References: <5049EC11.9080302@tiscali.it>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Test report of xen 4.2.0-rc4
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 testing.

On Fri, 2012-09-07 at 13:44 +0100, Fabio Fantoni wrote:
> - IMPORTANT - On restore network is up but not working, tried with W7 
> pro 64 bit with gplpv last build (357) on qemu-xen-traditional

Our automated tests aren't seeing this, might it be a GPLPV issue? Can
you reproduce with e.g. PV Linux (or PVHVM Linux for that matter)?

> - Cdrom hotswap is not working, tried with W7 pro 64 bit with gplpv last 
> build (357) on qemu-xen-traditional
> xl -vvv cd-eject W7 hdb
> libxl: debug: libxl.c:2143:libxl_cdrom_insert: ao 0x1461980: create: 
> how=(nil) callback=(nil) poller=0x14619e0
> Errore di segmentazione

This doesn't happen for me. Please can you run this one under gdb and
when it fails type "bt" to get a backtrace.

> - Vnc is working but only with parameters not supplied as value to the 
> vfb key, but with vfb key is not working

Whether or not that works is very much a function of exactly what the
rest of your guest config looks like (it depends on PV for HVM for one
thing).

You've reported enough bugs now that I shouldn't need to remind you
about providing guest config files or link to
http://wiki.xen.org/wiki/Reporting_Bugs_against_Xen again.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 07 15:19:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Sep 2012 15:19:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TA0LB-0002hL-KD; Fri, 07 Sep 2012 15:19: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 1TA0LA-0002hE-7l
	for xen-devel@lists.xensource.com; Fri, 07 Sep 2012 15:19:28 +0000
Received: from [85.158.143.35:55356] by server-2.bemta-4.messagelabs.com id
	7B/40-21239-F701A405; Fri, 07 Sep 2012 15:19:27 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1347031148!14696833!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTIyMTE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3589 invoked from network); 7 Sep 2012 15:19:08 -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 Sep 2012 15:19:08 -0000
X-IronPort-AV: E=Sophos;i="4.80,387,1344211200"; d="scan'208";a="14413510"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Sep 2012 15:19: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.279.1; Fri, 7 Sep 2012 16:19: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 1TA0Kq-0004jg-3J;
	Fri, 07 Sep 2012 15:19:08 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1TA0Kp-0005Sx-Pl;
	Fri, 07 Sep 2012 16:19:07 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-13663-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 7 Sep 2012 16:19:07 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.2-testing baseline test] 13663: tolerable
	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

"Old" tested version had not actually been tested; therefore in this
flight we test it, rather than a new candidate.  The baseline, if
any, is the most recent actually tested revision.

flight 13663 xen-4.2-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13663/

Failures :-/ but no regressions.

Tests which did not succeed,
including tests which could not be run:
 test-amd64-amd64-pv           1 xen-build-check(1)          blocked never pass
 test-amd64-i386-rhel6hvm-intel  1 xen-build-check(1)        blocked never pass
 test-amd64-i386-pv            1 xen-build-check(1)          blocked never pass
 test-amd64-i386-qemuu-rhel6hvm-amd  1 xen-build-check(1)    blocked never pass
 test-amd64-amd64-xl-winxpsp3  1 xen-build-check(1)          blocked never pass
 test-amd64-amd64-xl-sedf      1 xen-build-check(1)          blocked never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  1 xen-build-check(1)    blocked never pass
 test-amd64-i386-xl-credit2    1 xen-build-check(1)          blocked never pass
 test-amd64-i386-rhel6hvm-amd  1 xen-build-check(1)          blocked never pass
 test-amd64-amd64-xl-sedf-pin  1 xen-build-check(1)          blocked never pass
 test-amd64-amd64-win          1 xen-build-check(1)          blocked never pass
 test-i386-i386-xl-qemuu-winxpsp3  1 xen-build-check(1)      blocked never pass
 test-i386-i386-win            1 xen-build-check(1)          blocked never pass
 test-amd64-i386-xl-winxpsp3-vcpus1  1 xen-build-check(1)    blocked never pass
 test-amd64-amd64-xl-pcipt-intel  1 xen-build-check(1)       blocked never pass
 test-amd64-i386-xl-win-vcpus1  1 xen-build-check(1)         blocked never pass
 test-amd64-i386-xl-multivcpu  1 xen-build-check(1)          blocked never pass
 test-i386-i386-pv             1 xen-build-check(1)          blocked never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  1 xen-build-check(1)  blocked never pass
 test-amd64-i386-win-vcpus1    1 xen-build-check(1)          blocked never pass
 test-amd64-i386-xl-win7-amd64  1 xen-build-check(1)         blocked never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  1 xen-build-check(1)  blocked never pass
 test-i386-i386-xl-win         1 xen-build-check(1)          blocked never pass
 test-amd64-amd64-xl-win7-amd64  1 xen-build-check(1)        blocked never pass
 test-amd64-i386-win           1 xen-build-check(1)          blocked never pass
 test-amd64-i386-pair          1 xen-build-check(1)          blocked never pass
 test-amd64-i386-xend-winxpsp3  1 xen-build-check(1)         blocked never pass
 test-i386-i386-xl             1 xen-build-check(1)          blocked never pass
 test-i386-i386-xl-winxpsp3    1 xen-build-check(1)          blocked never pass
 test-amd64-amd64-xl           1 xen-build-check(1)          blocked never pass
 test-amd64-amd64-xl-win       1 xen-build-check(1)          blocked never pass
 test-amd64-i386-xl            1 xen-build-check(1)          blocked never pass
 test-i386-i386-pair           1 xen-build-check(1)          blocked never pass
 test-amd64-amd64-pair         1 xen-build-check(1)          blocked never pass
 build-amd64                   4 xen-build                    fail   never pass
 build-amd64-oldkern           4 xen-build                    fail   never pass
 build-i386-pvops              4 kernel-build                 fail   never pass
 build-amd64-pvops             4 kernel-build                 fail   never pass
 build-i386                    4 xen-build                    fail   never pass
 build-i386-oldkern            4 xen-build                    fail   never pass

version targeted for testing:
 xen                  ec23c2a11f6f

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


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 Sep 07 15:19:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Sep 2012 15:19:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TA0LB-0002hL-KD; Fri, 07 Sep 2012 15:19: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 1TA0LA-0002hE-7l
	for xen-devel@lists.xensource.com; Fri, 07 Sep 2012 15:19:28 +0000
Received: from [85.158.143.35:55356] by server-2.bemta-4.messagelabs.com id
	7B/40-21239-F701A405; Fri, 07 Sep 2012 15:19:27 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1347031148!14696833!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTIyMTE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3589 invoked from network); 7 Sep 2012 15:19:08 -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 Sep 2012 15:19:08 -0000
X-IronPort-AV: E=Sophos;i="4.80,387,1344211200"; d="scan'208";a="14413510"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Sep 2012 15:19: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.279.1; Fri, 7 Sep 2012 16:19: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 1TA0Kq-0004jg-3J;
	Fri, 07 Sep 2012 15:19:08 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1TA0Kp-0005Sx-Pl;
	Fri, 07 Sep 2012 16:19:07 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-13663-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 7 Sep 2012 16:19:07 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.2-testing baseline test] 13663: tolerable
	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

"Old" tested version had not actually been tested; therefore in this
flight we test it, rather than a new candidate.  The baseline, if
any, is the most recent actually tested revision.

flight 13663 xen-4.2-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13663/

Failures :-/ but no regressions.

Tests which did not succeed,
including tests which could not be run:
 test-amd64-amd64-pv           1 xen-build-check(1)          blocked never pass
 test-amd64-i386-rhel6hvm-intel  1 xen-build-check(1)        blocked never pass
 test-amd64-i386-pv            1 xen-build-check(1)          blocked never pass
 test-amd64-i386-qemuu-rhel6hvm-amd  1 xen-build-check(1)    blocked never pass
 test-amd64-amd64-xl-winxpsp3  1 xen-build-check(1)          blocked never pass
 test-amd64-amd64-xl-sedf      1 xen-build-check(1)          blocked never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  1 xen-build-check(1)    blocked never pass
 test-amd64-i386-xl-credit2    1 xen-build-check(1)          blocked never pass
 test-amd64-i386-rhel6hvm-amd  1 xen-build-check(1)          blocked never pass
 test-amd64-amd64-xl-sedf-pin  1 xen-build-check(1)          blocked never pass
 test-amd64-amd64-win          1 xen-build-check(1)          blocked never pass
 test-i386-i386-xl-qemuu-winxpsp3  1 xen-build-check(1)      blocked never pass
 test-i386-i386-win            1 xen-build-check(1)          blocked never pass
 test-amd64-i386-xl-winxpsp3-vcpus1  1 xen-build-check(1)    blocked never pass
 test-amd64-amd64-xl-pcipt-intel  1 xen-build-check(1)       blocked never pass
 test-amd64-i386-xl-win-vcpus1  1 xen-build-check(1)         blocked never pass
 test-amd64-i386-xl-multivcpu  1 xen-build-check(1)          blocked never pass
 test-i386-i386-pv             1 xen-build-check(1)          blocked never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  1 xen-build-check(1)  blocked never pass
 test-amd64-i386-win-vcpus1    1 xen-build-check(1)          blocked never pass
 test-amd64-i386-xl-win7-amd64  1 xen-build-check(1)         blocked never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  1 xen-build-check(1)  blocked never pass
 test-i386-i386-xl-win         1 xen-build-check(1)          blocked never pass
 test-amd64-amd64-xl-win7-amd64  1 xen-build-check(1)        blocked never pass
 test-amd64-i386-win           1 xen-build-check(1)          blocked never pass
 test-amd64-i386-pair          1 xen-build-check(1)          blocked never pass
 test-amd64-i386-xend-winxpsp3  1 xen-build-check(1)         blocked never pass
 test-i386-i386-xl             1 xen-build-check(1)          blocked never pass
 test-i386-i386-xl-winxpsp3    1 xen-build-check(1)          blocked never pass
 test-amd64-amd64-xl           1 xen-build-check(1)          blocked never pass
 test-amd64-amd64-xl-win       1 xen-build-check(1)          blocked never pass
 test-amd64-i386-xl            1 xen-build-check(1)          blocked never pass
 test-i386-i386-pair           1 xen-build-check(1)          blocked never pass
 test-amd64-amd64-pair         1 xen-build-check(1)          blocked never pass
 build-amd64                   4 xen-build                    fail   never pass
 build-amd64-oldkern           4 xen-build                    fail   never pass
 build-i386-pvops              4 kernel-build                 fail   never pass
 build-amd64-pvops             4 kernel-build                 fail   never pass
 build-i386                    4 xen-build                    fail   never pass
 build-i386-oldkern            4 xen-build                    fail   never pass

version targeted for testing:
 xen                  ec23c2a11f6f

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


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 Sep 07 15:22:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Sep 2012 15:22:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TA0NZ-0002qE-BX; Fri, 07 Sep 2012 15:21:57 +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 1TA0NX-0002q5-SQ
	for xen-devel@lists.xensource.com; Fri, 07 Sep 2012 15:21:56 +0000
Received: from [85.158.138.51:4184] by server-6.bemta-3.messagelabs.com id
	31/74-29694-3111A405; Fri, 07 Sep 2012 15:21:55 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1347031314!29265667!1
X-Originating-IP: [209.85.215.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9753 invoked from network); 7 Sep 2012 15:21:54 -0000
Received: from mail-ey0-f171.google.com (HELO mail-ey0-f171.google.com)
	(209.85.215.171)
	by server-8.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Sep 2012 15:21:54 -0000
Received: by eaah11 with SMTP id h11so1018802eaa.30
	for <xen-devel@lists.xensource.com>;
	Fri, 07 Sep 2012 08:21:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:user-agent:date:subject:from:to:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=ZclzWN2IFe72OAlShpHunizmKGmeyYbtLnShomhuVgo=;
	b=kdft5F7pB2hDLP/AMir55aswwatbBqQKOT2yw2Xejii9T1RZUALZFjauW1qxKuzEFF
	DP/XcxuMdl4g4T91w8/cOIoW5sFbRfYQa/Grnp23yi95SQJqhtk6U22rNjgKiPiDbA69
	qIvdb0bXJ22Xw5viK+KzSxrJS+fYgKsXLZZtdItPvlcwlE1DOtUZjPplMK28KjesKk6D
	X96lMeJnYUYNaMOIG+DCPCOSYYUaUlhhHomgU8rBTZ+RR2ICK9GezvcYokG7Hjz9fk69
	uQG5T4BFRcYAIp4MALORlkV/qx5G3CTOsP/oaBhu4wYkAJSnysgs0PozoQYTh8fx2Isj
	EexQ==
Received: by 10.14.204.72 with SMTP id g48mr8460262eeo.45.1347031314231;
	Fri, 07 Sep 2012 08:21:54 -0700 (PDT)
Received: from [192.168.1.3] (host86-184-74-117.range86-184.btcentralplus.com.
	[86.184.74.117])
	by mx.google.com with ESMTPS id e7sm15552878eep.2.2012.09.07.08.21.52
	(version=SSLv3 cipher=OTHER); Fri, 07 Sep 2012 08:21:53 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.33.0.120411
Date: Fri, 07 Sep 2012 16:21:44 +0100
From: Keir Fraser <keir@xen.org>
To: Thanos Makatos <thanos.makatos@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Message-ID: <CC6FCF98.4AF76%keir@xen.org>
Thread-Topic: [Xen-devel] blktap3 in C++?
Thread-Index: Ac2NCrBr5o+jaK0ZTumGtQ28appYgwAAcyWK
In-Reply-To: <4B45B535F7F6BE4CB1C044ED5115CDDE011A6DAD77DF@LONPMAILBOX01.citrite.net>
Mime-version: 1.0
Subject: Re: [Xen-devel] blktap3 in C++?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 07/09/2012 16:08, "Thanos Makatos" <thanos.makatos@citrix.com> wrote:

> I was wondering whether it would make sense to have blktap3 in C++. I don't
> have very strong feelings about it; I'd prefer to have it in C++, but it's
> already written in C and it works. The benefits of having it in C++ would be
> code clarity and maintainability. I bring this up now because I'm currently
> cleaning it up, so it's the best time to do it, should we decide to do so.

Leave it be, and learn how to write maintainable C code!

> --
> Thanos Makatos
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Sep 07 15:22:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Sep 2012 15:22:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TA0NZ-0002qE-BX; Fri, 07 Sep 2012 15:21:57 +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 1TA0NX-0002q5-SQ
	for xen-devel@lists.xensource.com; Fri, 07 Sep 2012 15:21:56 +0000
Received: from [85.158.138.51:4184] by server-6.bemta-3.messagelabs.com id
	31/74-29694-3111A405; Fri, 07 Sep 2012 15:21:55 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1347031314!29265667!1
X-Originating-IP: [209.85.215.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9753 invoked from network); 7 Sep 2012 15:21:54 -0000
Received: from mail-ey0-f171.google.com (HELO mail-ey0-f171.google.com)
	(209.85.215.171)
	by server-8.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Sep 2012 15:21:54 -0000
Received: by eaah11 with SMTP id h11so1018802eaa.30
	for <xen-devel@lists.xensource.com>;
	Fri, 07 Sep 2012 08:21:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:user-agent:date:subject:from:to:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=ZclzWN2IFe72OAlShpHunizmKGmeyYbtLnShomhuVgo=;
	b=kdft5F7pB2hDLP/AMir55aswwatbBqQKOT2yw2Xejii9T1RZUALZFjauW1qxKuzEFF
	DP/XcxuMdl4g4T91w8/cOIoW5sFbRfYQa/Grnp23yi95SQJqhtk6U22rNjgKiPiDbA69
	qIvdb0bXJ22Xw5viK+KzSxrJS+fYgKsXLZZtdItPvlcwlE1DOtUZjPplMK28KjesKk6D
	X96lMeJnYUYNaMOIG+DCPCOSYYUaUlhhHomgU8rBTZ+RR2ICK9GezvcYokG7Hjz9fk69
	uQG5T4BFRcYAIp4MALORlkV/qx5G3CTOsP/oaBhu4wYkAJSnysgs0PozoQYTh8fx2Isj
	EexQ==
Received: by 10.14.204.72 with SMTP id g48mr8460262eeo.45.1347031314231;
	Fri, 07 Sep 2012 08:21:54 -0700 (PDT)
Received: from [192.168.1.3] (host86-184-74-117.range86-184.btcentralplus.com.
	[86.184.74.117])
	by mx.google.com with ESMTPS id e7sm15552878eep.2.2012.09.07.08.21.52
	(version=SSLv3 cipher=OTHER); Fri, 07 Sep 2012 08:21:53 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.33.0.120411
Date: Fri, 07 Sep 2012 16:21:44 +0100
From: Keir Fraser <keir@xen.org>
To: Thanos Makatos <thanos.makatos@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Message-ID: <CC6FCF98.4AF76%keir@xen.org>
Thread-Topic: [Xen-devel] blktap3 in C++?
Thread-Index: Ac2NCrBr5o+jaK0ZTumGtQ28appYgwAAcyWK
In-Reply-To: <4B45B535F7F6BE4CB1C044ED5115CDDE011A6DAD77DF@LONPMAILBOX01.citrite.net>
Mime-version: 1.0
Subject: Re: [Xen-devel] blktap3 in C++?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 07/09/2012 16:08, "Thanos Makatos" <thanos.makatos@citrix.com> wrote:

> I was wondering whether it would make sense to have blktap3 in C++. I don't
> have very strong feelings about it; I'd prefer to have it in C++, but it's
> already written in C and it works. The benefits of having it in C++ would be
> code clarity and maintainability. I bring this up now because I'm currently
> cleaning it up, so it's the best time to do it, should we decide to do so.

Leave it be, and learn how to write maintainable C code!

> --
> Thanos Makatos
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Sep 07 15:22:30 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Sep 2012 15:22:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TA0Nu-0002s8-Of; Fri, 07 Sep 2012 15:22:18 +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 1TA0Nt-0002rF-8R
	for xen-devel@lists.xen.org; Fri, 07 Sep 2012 15:22:17 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1347031322!2386865!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM4ODU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27067 invoked from network); 7 Sep 2012 15:22:04 -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;
	7 Sep 2012 15:22:04 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 07 Sep 2012 16:22:02 +0100
Message-Id: <504A2D710200007800099E11@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 07 Sep 2012 16:22:57 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Campbell" <Ian.Campbell@citrix.com>
References: <1347027296.30018.108.camel@zakaz.uk.xensource.com>
In-Reply-To: <1347027296.30018.108.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 new features and status -- please help me
 make a list
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 07.09.12 at 16:14, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> vMSI: ? Emulated (or real?) MSIs for guests?
>         State? New in 4.2?

Not sure what you're referring to here. There certainly was a
xen/arch/x86/hvm/vmsi.c in 4.1 already.

> vMCE: Forward MCE (Machine Check Exceptions) to guests
>         New in 4.2? Preview or complete? I know improvements are pending
>         to migration in 4.3.

Should be in reasonable state; certainly not a preview.

> AMD OSVW: What is this?
>         Seems to be new in 4.2?

OS Visible Workaround. A little bit of virtualization of this for
HVM guests got added. Nothing end user visible though.

> Intel HLE: What is this?
>         Seems to be new in 4.2?

Something like "Hardware Lock Elision".

I don't think there's any support for this, just white-listing the
feature for (HVM) guests.

> Intel TRM: What is this?
>         Seems to be new in 4.2?

"Restricted Transactional Memory"

Implementation-wise same as above.

> OVMF support for HVM guests.
>         New in 4.2, but disabled by default => Tech preview?

Wasn't it that this doesn't even build?

> vPMU: Power Management?
>         New in 4.2?

Enhanced iirc.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 07 15:22:30 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Sep 2012 15:22:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TA0Nu-0002s8-Of; Fri, 07 Sep 2012 15:22:18 +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 1TA0Nt-0002rF-8R
	for xen-devel@lists.xen.org; Fri, 07 Sep 2012 15:22:17 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1347031322!2386865!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM4ODU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27067 invoked from network); 7 Sep 2012 15:22:04 -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;
	7 Sep 2012 15:22:04 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 07 Sep 2012 16:22:02 +0100
Message-Id: <504A2D710200007800099E11@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 07 Sep 2012 16:22:57 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Campbell" <Ian.Campbell@citrix.com>
References: <1347027296.30018.108.camel@zakaz.uk.xensource.com>
In-Reply-To: <1347027296.30018.108.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 new features and status -- please help me
 make a list
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 07.09.12 at 16:14, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> vMSI: ? Emulated (or real?) MSIs for guests?
>         State? New in 4.2?

Not sure what you're referring to here. There certainly was a
xen/arch/x86/hvm/vmsi.c in 4.1 already.

> vMCE: Forward MCE (Machine Check Exceptions) to guests
>         New in 4.2? Preview or complete? I know improvements are pending
>         to migration in 4.3.

Should be in reasonable state; certainly not a preview.

> AMD OSVW: What is this?
>         Seems to be new in 4.2?

OS Visible Workaround. A little bit of virtualization of this for
HVM guests got added. Nothing end user visible though.

> Intel HLE: What is this?
>         Seems to be new in 4.2?

Something like "Hardware Lock Elision".

I don't think there's any support for this, just white-listing the
feature for (HVM) guests.

> Intel TRM: What is this?
>         Seems to be new in 4.2?

"Restricted Transactional Memory"

Implementation-wise same as above.

> OVMF support for HVM guests.
>         New in 4.2, but disabled by default => Tech preview?

Wasn't it that this doesn't even build?

> vPMU: Power Management?
>         New in 4.2?

Enhanced iirc.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 07 15:28:32 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Sep 2012 15:28:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TA0Ti-0003Bc-Lk; Fri, 07 Sep 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.Jackson@eu.citrix.com>) id 1TA0Th-0003BX-GJ
	for xen-devel@lists.xensource.com; Fri, 07 Sep 2012 15:28:17 +0000
Received: from [85.158.139.83:65372] by server-11.bemta-5.messagelabs.com id
	4E/FE-24658-0921A405; Fri, 07 Sep 2012 15:28:16 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1347031695!29196825!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTIyMTE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22952 invoked from network); 7 Sep 2012 15:28:16 -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 Sep 2012 15:28:16 -0000
X-IronPort-AV: E=Sophos;i="4.80,387,1344211200"; d="scan'208";a="14413747"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Sep 2012 15:28: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.279.1; Fri, 7 Sep 2012 16:28: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
	1TA0Td-0004nG-58; Fri, 07 Sep 2012 15:28:13 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1TA0Tc-0002CV-Vj;
	Fri, 07 Sep 2012 16:28:13 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20554.4748.853110.970488@mariner.uk.xensource.com>
Date: Fri, 7 Sep 2012 16:28:12 +0100
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
In-Reply-To: <osstest-13663-mainreport@xen.org>
References: <osstest-13663-mainreport@xen.org>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Keir Fraser <keir.xen@gmail.com>, Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [xen-4.2-testing baseline test] 13663: tolerable
 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

xen.org writes ("[xen-4.2-testing baseline test] 13663: tolerable trouble: blocked/fail"):
>  build-i386                    4 xen-build                fail   never pass

+ hg clone http://xenbits.xen.org/staging/xen-4.2-testing.hg xen-unstable
abort: HTTP Error 404: Not Found

This is because all previous trees have had urls of the form
   http://xenbits.xen.org/[staging/]xen-VERSION-testing.hg
but this was daft and caused trouble for the xenbits webserver config
so nowadays we prefer
   http://xenbits.xen.org/hg/[staging/]xen-VERSION-testing.hg

I will fix this in the tester, but can I request that we don't throw
any actual changes into xen-4.2-testing.hg until I get this fixed and
we get a more plausible test baseline ?

With the situation as it currently is, any changes we put into 4.2
won't have the benefit of the push gate.

Apologies,
Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 07 15:28:32 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Sep 2012 15:28:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TA0Ti-0003Bc-Lk; Fri, 07 Sep 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.Jackson@eu.citrix.com>) id 1TA0Th-0003BX-GJ
	for xen-devel@lists.xensource.com; Fri, 07 Sep 2012 15:28:17 +0000
Received: from [85.158.139.83:65372] by server-11.bemta-5.messagelabs.com id
	4E/FE-24658-0921A405; Fri, 07 Sep 2012 15:28:16 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1347031695!29196825!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTIyMTE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22952 invoked from network); 7 Sep 2012 15:28:16 -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 Sep 2012 15:28:16 -0000
X-IronPort-AV: E=Sophos;i="4.80,387,1344211200"; d="scan'208";a="14413747"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Sep 2012 15:28: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.279.1; Fri, 7 Sep 2012 16:28: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
	1TA0Td-0004nG-58; Fri, 07 Sep 2012 15:28:13 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1TA0Tc-0002CV-Vj;
	Fri, 07 Sep 2012 16:28:13 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20554.4748.853110.970488@mariner.uk.xensource.com>
Date: Fri, 7 Sep 2012 16:28:12 +0100
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
In-Reply-To: <osstest-13663-mainreport@xen.org>
References: <osstest-13663-mainreport@xen.org>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Keir Fraser <keir.xen@gmail.com>, Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [xen-4.2-testing baseline test] 13663: tolerable
 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

xen.org writes ("[xen-4.2-testing baseline test] 13663: tolerable trouble: blocked/fail"):
>  build-i386                    4 xen-build                fail   never pass

+ hg clone http://xenbits.xen.org/staging/xen-4.2-testing.hg xen-unstable
abort: HTTP Error 404: Not Found

This is because all previous trees have had urls of the form
   http://xenbits.xen.org/[staging/]xen-VERSION-testing.hg
but this was daft and caused trouble for the xenbits webserver config
so nowadays we prefer
   http://xenbits.xen.org/hg/[staging/]xen-VERSION-testing.hg

I will fix this in the tester, but can I request that we don't throw
any actual changes into xen-4.2-testing.hg until I get this fixed and
we get a more plausible test baseline ?

With the situation as it currently is, any changes we put into 4.2
won't have the benefit of the push gate.

Apologies,
Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 07 15:35:43 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Sep 2012 15:35:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TA0af-0003PN-Lv; Fri, 07 Sep 2012 15:35:29 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1TA0ae-0003PI-Er
	for xen-devel@lists.xen.org; Fri, 07 Sep 2012 15:35:28 +0000
Received: from [85.158.138.51:60960] by server-2.bemta-3.messagelabs.com id
	3C/46-04862-F341A405; Fri, 07 Sep 2012 15:35:27 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-2.tower-174.messagelabs.com!1347032126!29327397!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26462 invoked from network); 7 Sep 2012 15:35:27 -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 Sep 2012 15:35:27 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1TA0aZ-0005QP-Tq; Fri, 07 Sep 2012 15:35:23 +0000
Date: Fri, 7 Sep 2012 16:35:23 +0100
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120907153523.GB71093@ocelot.phlegethon.org>
References: <1347027296.30018.108.camel@zakaz.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1347027296.30018.108.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 new features and status -- please help me
	make a list
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At 15:14 +0100 on 07 Sep (1347030896), Ian Campbell wrote:
> ASID support:
>         4.2 gained an option to control this but I think it was
>         pre-existing. When was it first introduced? 4.1 or 4.0 or
>         before?

Long before.  3.0.x of some kind for AMD; 3.3 for Intel (as 'vpid'). 

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 07 15:35:43 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Sep 2012 15:35:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TA0af-0003PN-Lv; Fri, 07 Sep 2012 15:35:29 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1TA0ae-0003PI-Er
	for xen-devel@lists.xen.org; Fri, 07 Sep 2012 15:35:28 +0000
Received: from [85.158.138.51:60960] by server-2.bemta-3.messagelabs.com id
	3C/46-04862-F341A405; Fri, 07 Sep 2012 15:35:27 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-2.tower-174.messagelabs.com!1347032126!29327397!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26462 invoked from network); 7 Sep 2012 15:35:27 -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 Sep 2012 15:35:27 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1TA0aZ-0005QP-Tq; Fri, 07 Sep 2012 15:35:23 +0000
Date: Fri, 7 Sep 2012 16:35:23 +0100
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120907153523.GB71093@ocelot.phlegethon.org>
References: <1347027296.30018.108.camel@zakaz.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1347027296.30018.108.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 new features and status -- please help me
	make a list
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At 15:14 +0100 on 07 Sep (1347030896), Ian Campbell wrote:
> ASID support:
>         4.2 gained an option to control this but I think it was
>         pre-existing. When was it first introduced? 4.1 or 4.0 or
>         before?

Long before.  3.0.x of some kind for AMD; 3.3 for Intel (as 'vpid'). 

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 07 15:35:52 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Sep 2012 15: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 1TA0aj-0003Pe-2D; Fri, 07 Sep 2012 15:35:33 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1TA0ai-0003PX-7O
	for xen-devel@lists.xen.org; Fri, 07 Sep 2012 15:35:32 +0000
Received: from [85.158.143.99:12708] by server-3.bemta-4.messagelabs.com id
	0F/FB-08232-3441A405; Fri, 07 Sep 2012 15:35:31 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1347032130!25791211!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM4ODU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22472 invoked from network); 7 Sep 2012 15:35:30 -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;
	7 Sep 2012 15:35:30 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 07 Sep 2012 16:35:30 +0100
Message-Id: <504A309A0200007800099E2B@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 07 Sep 2012 16:36:26 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Campbell" <Ian.Campbell@citrix.com>
References: <1347027296.30018.108.camel@zakaz.uk.xensource.com>
In-Reply-To: <1347027296.30018.108.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 new features and status -- please help me
 make a list
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 07.09.12 at 16:14, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> Of course if you know of a feature in 4.2 which isn't mentioned but
> which you think is worthwhile please let me know. I'm sure there are
> plenty which I missed.

Not sure whether boot time CPU microcode patching is worth
mentioning. Certainly this is nothing user visible.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 07 15:35:52 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Sep 2012 15: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 1TA0aj-0003Pe-2D; Fri, 07 Sep 2012 15:35:33 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1TA0ai-0003PX-7O
	for xen-devel@lists.xen.org; Fri, 07 Sep 2012 15:35:32 +0000
Received: from [85.158.143.99:12708] by server-3.bemta-4.messagelabs.com id
	0F/FB-08232-3441A405; Fri, 07 Sep 2012 15:35:31 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1347032130!25791211!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM4ODU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22472 invoked from network); 7 Sep 2012 15:35:30 -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;
	7 Sep 2012 15:35:30 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 07 Sep 2012 16:35:30 +0100
Message-Id: <504A309A0200007800099E2B@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 07 Sep 2012 16:36:26 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Campbell" <Ian.Campbell@citrix.com>
References: <1347027296.30018.108.camel@zakaz.uk.xensource.com>
In-Reply-To: <1347027296.30018.108.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 new features and status -- please help me
 make a list
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 07.09.12 at 16:14, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> Of course if you know of a feature in 4.2 which isn't mentioned but
> which you think is worthwhile please let me know. I'm sure there are
> plenty which I missed.

Not sure whether boot time CPU microcode patching is worth
mentioning. Certainly this is nothing user visible.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 07 15:39:40 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Sep 2012 15:39:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TA0eV-0003eV-N6; Fri, 07 Sep 2012 15:39: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 1TA0eU-0003eO-DN
	for xen-devel@lists.xen.org; Fri, 07 Sep 2012 15:39:26 +0000
Received: from [85.158.143.35:56203] by server-2.bemta-4.messagelabs.com id
	B7/1B-21239-D251A405; Fri, 07 Sep 2012 15:39:25 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1347032365!15414774!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTIyMTE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27187 invoked from network); 7 Sep 2012 15:39:25 -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;
	7 Sep 2012 15:39:25 -0000
X-IronPort-AV: E=Sophos;i="4.80,387,1344211200"; d="scan'208";a="14413964"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Sep 2012 15:39: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.279.1; Fri, 7 Sep 2012
	16:39:24 +0100
Message-ID: <1347032363.30018.120.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Fri, 7 Sep 2012 16:39:23 +0100
In-Reply-To: <504A2D710200007800099E11@nat28.tlf.novell.com>
References: <1347027296.30018.108.camel@zakaz.uk.xensource.com>
	<504A2D710200007800099E11@nat28.tlf.novell.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.2 new features and status -- please help me
	make a list
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-09-07 at 16:22 +0100, Jan Beulich wrote:
> >>> On 07.09.12 at 16:14, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> > vMSI: ? Emulated (or real?) MSIs for guests?
> >         State? New in 4.2?
> 
> Not sure what you're referring to here. There certainly was a
> xen/arch/x86/hvm/vmsi.c in 4.1 already.

OK, thanks. 4.0 too by the looks of it.

What exactly is this? Is it about injection of MSIs from real
(passthrough) hardware devices to guests (only HVM ones?) or is about
MSIs generated by emulated devices (or both)?

> 
> > vMCE: Forward MCE (Machine Check Exceptions) to guests
> >         New in 4.2? Preview or complete? I know improvements are pending
> >         to migration in 4.3.
> 
> Should be in reasonable state; certainly not a preview.

Thanks.

> > AMD OSVW: What is this?
> >         Seems to be new in 4.2?
> 
> OS Visible Workaround. A little bit of virtualization of this for
> HVM guests got added. Nothing end user visible though.
> 
> > Intel HLE: What is this?
> >         Seems to be new in 4.2?
> 
> Something like "Hardware Lock Elision".
> 
> I don't think there's any support for this, just white-listing the
> feature for (HVM) guests.
> 
> > Intel TRM: What is this?
> >         Seems to be new in 4.2?
> 
> "Restricted Transactional Memory"
> 
> Implementation-wise same as above.

OK. I don't think "expose an underlying hardware feature to guests" is
very interesting from a feature list PoV so I'll omit both of these.

> 
> > OVMF support for HVM guests.
> >         New in 4.2, but disabled by default => Tech preview?
> 
> Wasn't it that this doesn't even build?

Something like that. Or maybe only with certain compilers or something.
Unless Atillio says otherwise I'll mark it as a preview.

> 
> > vPMU: Power Management?
> >         New in 4.2?
> 
> Enhanced iirc.

But already a full feature in 4.1 and 4.0?

This lets HVM guests thing they have power management hardware, and
tickling it does what?

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 Sep 07 15:39:40 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Sep 2012 15:39:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TA0eV-0003eV-N6; Fri, 07 Sep 2012 15:39: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 1TA0eU-0003eO-DN
	for xen-devel@lists.xen.org; Fri, 07 Sep 2012 15:39:26 +0000
Received: from [85.158.143.35:56203] by server-2.bemta-4.messagelabs.com id
	B7/1B-21239-D251A405; Fri, 07 Sep 2012 15:39:25 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1347032365!15414774!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTIyMTE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27187 invoked from network); 7 Sep 2012 15:39:25 -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;
	7 Sep 2012 15:39:25 -0000
X-IronPort-AV: E=Sophos;i="4.80,387,1344211200"; d="scan'208";a="14413964"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Sep 2012 15:39: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.279.1; Fri, 7 Sep 2012
	16:39:24 +0100
Message-ID: <1347032363.30018.120.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Fri, 7 Sep 2012 16:39:23 +0100
In-Reply-To: <504A2D710200007800099E11@nat28.tlf.novell.com>
References: <1347027296.30018.108.camel@zakaz.uk.xensource.com>
	<504A2D710200007800099E11@nat28.tlf.novell.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.2 new features and status -- please help me
	make a list
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-09-07 at 16:22 +0100, Jan Beulich wrote:
> >>> On 07.09.12 at 16:14, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> > vMSI: ? Emulated (or real?) MSIs for guests?
> >         State? New in 4.2?
> 
> Not sure what you're referring to here. There certainly was a
> xen/arch/x86/hvm/vmsi.c in 4.1 already.

OK, thanks. 4.0 too by the looks of it.

What exactly is this? Is it about injection of MSIs from real
(passthrough) hardware devices to guests (only HVM ones?) or is about
MSIs generated by emulated devices (or both)?

> 
> > vMCE: Forward MCE (Machine Check Exceptions) to guests
> >         New in 4.2? Preview or complete? I know improvements are pending
> >         to migration in 4.3.
> 
> Should be in reasonable state; certainly not a preview.

Thanks.

> > AMD OSVW: What is this?
> >         Seems to be new in 4.2?
> 
> OS Visible Workaround. A little bit of virtualization of this for
> HVM guests got added. Nothing end user visible though.
> 
> > Intel HLE: What is this?
> >         Seems to be new in 4.2?
> 
> Something like "Hardware Lock Elision".
> 
> I don't think there's any support for this, just white-listing the
> feature for (HVM) guests.
> 
> > Intel TRM: What is this?
> >         Seems to be new in 4.2?
> 
> "Restricted Transactional Memory"
> 
> Implementation-wise same as above.

OK. I don't think "expose an underlying hardware feature to guests" is
very interesting from a feature list PoV so I'll omit both of these.

> 
> > OVMF support for HVM guests.
> >         New in 4.2, but disabled by default => Tech preview?
> 
> Wasn't it that this doesn't even build?

Something like that. Or maybe only with certain compilers or something.
Unless Atillio says otherwise I'll mark it as a preview.

> 
> > vPMU: Power Management?
> >         New in 4.2?
> 
> Enhanced iirc.

But already a full feature in 4.1 and 4.0?

This lets HVM guests thing they have power management hardware, and
tickling it does what?

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 Sep 07 15:42:36 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Sep 2012 15:42:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TA0hN-0003nW-A9; Fri, 07 Sep 2012 15:42:25 +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 1TA0hL-0003nL-6W
	for xen-devel@lists.xen.org; Fri, 07 Sep 2012 15:42:23 +0000
Received: from [85.158.139.83:26073] by server-8.bemta-5.messagelabs.com id
	20/F2-17085-ED51A405; Fri, 07 Sep 2012 15:42:22 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1347032540!29046195!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNzc0ODA=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13212 invoked from network); 7 Sep 2012 15:42:21 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-12.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Sep 2012 15:42:21 -0000
X-IronPort-AV: E=Sophos;i="4.80,387,1344211200"; d="scan'208";a="207424237"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Sep 2012 15:42:20 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1;
	Fri, 7 Sep 2012 11:42:20 -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 1TA0hH-0007vG-N4;
	Fri, 07 Sep 2012 16:42:19 +0100
Message-ID: <504A15DB.1010706@citrix.com>
Date: Fri, 7 Sep 2012 16:42:19 +0100
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:14.0) Gecko/20120714 Thunderbird/14.0
MIME-Version: 1.0
To: Keir Fraser <keir.xen@gmail.com>
References: <CC6FCB60.3E0B9%keir.xen@gmail.com>
In-Reply-To: <CC6FCB60.3E0B9%keir.xen@gmail.com>
X-Enigmail-Version: 1.4.4
Cc: Jan Beulich <JBeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] kexec/noreboot: Don't kexec_crash() if
 noreboot has been requested.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/09/12 16:03, Keir Fraser wrote:
> On 07/09/2012 14:16, "Jan Beulich" <JBeulich@suse.com> wrote:
>
>>>>> On 07.09.12 at 15:05, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
>>> This issue came up when debugging pcpu linked list corruption (patches
>>> for that issue to follow).
>> Hmm, that's a matter of taste of course. Nor is running kdump
>> really a (direct) reboot action. Both ways have their reasoning
>> imo, so I'm not sure whether keeping things as is or applying the
>> patch is the better thing.
> I note though that kexec_crash() should be stubbed out in the header file
> when !CONFIG_KEXEC, rather than ifdef at the caller. By the by.
>
>  -- Keir

Agreed - I will put it on my todo list to fix.  (I think its elsewhere
in the codebase as well)

~Andrew

>
>> Jan
>>
>

-- 
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 Sep 07 15:42:36 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Sep 2012 15:42:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TA0hN-0003nW-A9; Fri, 07 Sep 2012 15:42:25 +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 1TA0hL-0003nL-6W
	for xen-devel@lists.xen.org; Fri, 07 Sep 2012 15:42:23 +0000
Received: from [85.158.139.83:26073] by server-8.bemta-5.messagelabs.com id
	20/F2-17085-ED51A405; Fri, 07 Sep 2012 15:42:22 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1347032540!29046195!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNzc0ODA=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13212 invoked from network); 7 Sep 2012 15:42:21 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-12.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Sep 2012 15:42:21 -0000
X-IronPort-AV: E=Sophos;i="4.80,387,1344211200"; d="scan'208";a="207424237"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Sep 2012 15:42:20 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1;
	Fri, 7 Sep 2012 11:42:20 -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 1TA0hH-0007vG-N4;
	Fri, 07 Sep 2012 16:42:19 +0100
Message-ID: <504A15DB.1010706@citrix.com>
Date: Fri, 7 Sep 2012 16:42:19 +0100
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:14.0) Gecko/20120714 Thunderbird/14.0
MIME-Version: 1.0
To: Keir Fraser <keir.xen@gmail.com>
References: <CC6FCB60.3E0B9%keir.xen@gmail.com>
In-Reply-To: <CC6FCB60.3E0B9%keir.xen@gmail.com>
X-Enigmail-Version: 1.4.4
Cc: Jan Beulich <JBeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] kexec/noreboot: Don't kexec_crash() if
 noreboot has been requested.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/09/12 16:03, Keir Fraser wrote:
> On 07/09/2012 14:16, "Jan Beulich" <JBeulich@suse.com> wrote:
>
>>>>> On 07.09.12 at 15:05, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
>>> This issue came up when debugging pcpu linked list corruption (patches
>>> for that issue to follow).
>> Hmm, that's a matter of taste of course. Nor is running kdump
>> really a (direct) reboot action. Both ways have their reasoning
>> imo, so I'm not sure whether keeping things as is or applying the
>> patch is the better thing.
> I note though that kexec_crash() should be stubbed out in the header file
> when !CONFIG_KEXEC, rather than ifdef at the caller. By the by.
>
>  -- Keir

Agreed - I will put it on my todo list to fix.  (I think its elsewhere
in the codebase as well)

~Andrew

>
>> Jan
>>
>

-- 
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 Sep 07 15:43:17 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Sep 2012 15:43:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TA0i2-0003r5-O8; Fri, 07 Sep 2012 15:43:06 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <stefan.bader@canonical.com>) id 1TA0i0-0003qt-HJ
	for xen-devel@lists.xen.org; Fri, 07 Sep 2012 15:43:04 +0000
Received: from [85.158.143.99:32377] by server-1.bemta-4.messagelabs.com id
	9C/9B-12504-7061A405; Fri, 07 Sep 2012 15:43:03 +0000
X-Env-Sender: stefan.bader@canonical.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1347032582!28818479!1
X-Originating-IP: [91.189.89.112]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7956 invoked from network); 7 Sep 2012 15:43:03 -0000
Received: from youngberry.canonical.com (HELO youngberry.canonical.com)
	(91.189.89.112) by server-5.tower-216.messagelabs.com with SMTP;
	7 Sep 2012 15:43:03 -0000
Received: from p5b2e2384.dip.t-dialin.net ([91.46.35.132] 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 1TA0hy-0006fS-I6
	for xen-devel@lists.xen.org; Fri, 07 Sep 2012 15:43:02 +0000
Message-ID: <504A1604.5030103@canonical.com>
Date: Fri, 07 Sep 2012 17:43:00 +0200
From: Stefan Bader <stefan.bader@canonical.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120827 Thunderbird/15.0
MIME-Version: 1.0
To: xen-devel@lists.xen.org
References: <1347018043-21252-1-git-send-email-stefan.bader@canonical.com>
	<504A05B00200007800099C7B@nat28.tlf.novell.com>
	<5049F4E9.9050306@canonical.com>
	<504A1A950200007800099D4C@nat28.tlf.novell.com>
	<20120907142251.GA20096@linuxtx.org>
	<20120907145433.GA5378@phenom.dumpdata.com>
In-Reply-To: <20120907145433.GA5378@phenom.dumpdata.com>
X-Enigmail-Version: 1.4.4
Subject: Re: [Xen-devel] [PATCH/RFC] Fix xsave bug on older Xen hypervisors
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============7317408952724608783=="
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)
--===============7317408952724608783==
Content-Type: multipart/signed; micalg=pgp-sha512;
 protocol="application/pgp-signature";
 boundary="------------enigF04701155E33776907F5DA0F"

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigF04701155E33776907F5DA0F
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On 07.09.2012 16:54, Konrad Rzeszutek Wilk wrote:
>>> But iirc that bad patch is a Linux side one (i.e. you're trying to fi=
x
>>> something upstream that isn't upstream)?
>>>
>> Right, so the patch that this improves upon, and that Fedora and Ubunt=
u are
>> currently carrying is not upstream because:
>>
>> a) It's crap, it cripples upstream xen users, but doesn't impact RHEL =
xen
>> users because xsave was never supported there.
>>
>> b) The hypervisor was patched to make it unnecessary quite some time a=
go,
>> and we hoped EC2 would eventually pick up that correct patch and we co=
uld
>> drop the crap kernel patch.
>>
>> Unfortunately this has not happened. We are at a point where EC2 reall=
y is
>> a quirk that has to be worked around. Distros do not want to maintain
>> a separate EC2 build of the kernel, so the easiest way is to cripple
>> current upstream xen users.  This quirk is unfortunately the best poss=
ible
>> solution.  Having it upstream also makes it possible for any user to b=
uild
>> an upstream kernel that will run on EC2 without having to dig a random=

>> patch out of a vendor kernel.
>=20
> Sure. Jan is asking though for actual confirmation that the upstream ke=
rnel
> does indeed go belly up without a workaround.
> And whether this patch (which I would did since Canonical is carrying i=
t) does
> fix the issue.

It is really hard to tell. It might even be that all of the hosts on EC2 =
are now
upgraded. There might be different version around. Even back when the pro=
blem
was found it would not always happen.

So it is, still a bit hackish, an attempt to play safe. All that is known=
 is
that there happened to be hosts running Xen 3.something which would do th=
at.
Historical evidence might be:

commit 389a3c02496dd1b399bb0efd005e9fa2be24e9ee
Author: Jeremy Fitzhardinge <jeremy@goop.org>
Date:   Tue Sep 18 22:46:33 2007 -0700

    xen: don't bother trying to set cr4

    Xen ignores all updates to cr4, and some versions will kill the domai=
n if
    you try to change its value.  Just ignore all changes.

Of course this is ancient v2.6.23 and it was later relaxed to just filter=
 out
some flags:

commit 2956a3511c8c5dccb1d4739ead17c7c3c23a24b7
Author: Jeremy Fitzhardinge <jeremy@goop.org>
Date:   Mon May 26 23:31:04 2008 +0100

    xen: allow some cr4 updates

    The guest can legitimately change things like cr4.OSFXSR and
    OSXMMEXCPT, so let it.

But whether there are still hosts out there running a bad version of the =
HV is
hard to say. EC2 may or may not be the only case (or not at all anymore).=
 For
upstream Linux it would be a valid decision either way. Not adding a quir=
k
because the use-case is so small. Or adding it because it avoids special =
patches
in distros and forcing those bits off on Xen 3 hosts is an acceptable dra=
wback.

At least posting it here would allow those who carry the older more intru=
sive
hack to replace that. So we do not run again into that mess like when xsa=
ve was
half-disabled by guests with that patch and hosts supporting it.

>=20
> I am still a newbie on the Amazon EC2 upload your kernel thing (hint, w=
ould
> appreciate somebody taking this patch and trying it out).
>=20
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
>=20



--------------enigF04701155E33776907F5DA0F
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://www.enigmail.net/

iQIcBAEBCgAGBQJQShYEAAoJEOhnXe7L7s6je7EP+wWVUwEZtLfe5lmf2UbhmbTW
G0I1LxsrduIjDq1HiIlUsH733LGxWKOheg/jd6x/3D3i2+dhC8h8DIvzuEnZkaUQ
iHUjmgiQAne/Qcm+qMtjtriVfNNqBw+MGCDu18Sk2JumMafxptrULTe7012VUJrd
dPWpBrQlVbuT7b8oDoCSa+Sv2rJSIvu80k8Hsf5U1HND+Sy7xxhBSZYYQQ2/7Zvt
4Lg65Ldz7bD/9N25s1JStyVVP8wmJV4o3wFeNzDXHYdX96ADQA03/X+/tzEK3GhM
ZUEtNtXudVE94YtMZkpu31mkRfDQEQeJfS3hWBBUfuRV42/N9wuoW59esLZgoE2H
TI4GNjK+K0KTYdANx/QmlHh8Z4RTQPPeQEzkekJA84+wmDpq20p5VsEEWrgP7WF3
z4knzmPSA2vRrlWTUbR0UUmhoIvU//W1s+AiJqGUvpwLClnUlf55LG5FUBA05mV/
JPaSGR1U8Un9B+b4NRqKuleRvFPInqTJYWFJ0w/ngzq0DJm5RNdu1pK5Oj9Xr3mq
aw4aGBprzlEaee3kZgRqFR8jy1epzFXszBDst4fnxWmz8TETGTaB4bQ8SMRp2mGi
XvB7Kliv5G6PbBEUM7js+drjWFHRbgpsw7nFOFbXklATx0lCFkwGZSc+0oqgFrQT
vAbZBpXUwAb0eH3ovA+Z
=Wi7N
-----END PGP SIGNATURE-----

--------------enigF04701155E33776907F5DA0F--


--===============7317408952724608783==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============7317408952724608783==--


From xen-devel-bounces@lists.xen.org Fri Sep 07 15:43:17 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Sep 2012 15:43:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TA0i2-0003r5-O8; Fri, 07 Sep 2012 15:43:06 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <stefan.bader@canonical.com>) id 1TA0i0-0003qt-HJ
	for xen-devel@lists.xen.org; Fri, 07 Sep 2012 15:43:04 +0000
Received: from [85.158.143.99:32377] by server-1.bemta-4.messagelabs.com id
	9C/9B-12504-7061A405; Fri, 07 Sep 2012 15:43:03 +0000
X-Env-Sender: stefan.bader@canonical.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1347032582!28818479!1
X-Originating-IP: [91.189.89.112]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7956 invoked from network); 7 Sep 2012 15:43:03 -0000
Received: from youngberry.canonical.com (HELO youngberry.canonical.com)
	(91.189.89.112) by server-5.tower-216.messagelabs.com with SMTP;
	7 Sep 2012 15:43:03 -0000
Received: from p5b2e2384.dip.t-dialin.net ([91.46.35.132] 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 1TA0hy-0006fS-I6
	for xen-devel@lists.xen.org; Fri, 07 Sep 2012 15:43:02 +0000
Message-ID: <504A1604.5030103@canonical.com>
Date: Fri, 07 Sep 2012 17:43:00 +0200
From: Stefan Bader <stefan.bader@canonical.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120827 Thunderbird/15.0
MIME-Version: 1.0
To: xen-devel@lists.xen.org
References: <1347018043-21252-1-git-send-email-stefan.bader@canonical.com>
	<504A05B00200007800099C7B@nat28.tlf.novell.com>
	<5049F4E9.9050306@canonical.com>
	<504A1A950200007800099D4C@nat28.tlf.novell.com>
	<20120907142251.GA20096@linuxtx.org>
	<20120907145433.GA5378@phenom.dumpdata.com>
In-Reply-To: <20120907145433.GA5378@phenom.dumpdata.com>
X-Enigmail-Version: 1.4.4
Subject: Re: [Xen-devel] [PATCH/RFC] Fix xsave bug on older Xen hypervisors
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============7317408952724608783=="
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)
--===============7317408952724608783==
Content-Type: multipart/signed; micalg=pgp-sha512;
 protocol="application/pgp-signature";
 boundary="------------enigF04701155E33776907F5DA0F"

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigF04701155E33776907F5DA0F
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On 07.09.2012 16:54, Konrad Rzeszutek Wilk wrote:
>>> But iirc that bad patch is a Linux side one (i.e. you're trying to fi=
x
>>> something upstream that isn't upstream)?
>>>
>> Right, so the patch that this improves upon, and that Fedora and Ubunt=
u are
>> currently carrying is not upstream because:
>>
>> a) It's crap, it cripples upstream xen users, but doesn't impact RHEL =
xen
>> users because xsave was never supported there.
>>
>> b) The hypervisor was patched to make it unnecessary quite some time a=
go,
>> and we hoped EC2 would eventually pick up that correct patch and we co=
uld
>> drop the crap kernel patch.
>>
>> Unfortunately this has not happened. We are at a point where EC2 reall=
y is
>> a quirk that has to be worked around. Distros do not want to maintain
>> a separate EC2 build of the kernel, so the easiest way is to cripple
>> current upstream xen users.  This quirk is unfortunately the best poss=
ible
>> solution.  Having it upstream also makes it possible for any user to b=
uild
>> an upstream kernel that will run on EC2 without having to dig a random=

>> patch out of a vendor kernel.
>=20
> Sure. Jan is asking though for actual confirmation that the upstream ke=
rnel
> does indeed go belly up without a workaround.
> And whether this patch (which I would did since Canonical is carrying i=
t) does
> fix the issue.

It is really hard to tell. It might even be that all of the hosts on EC2 =
are now
upgraded. There might be different version around. Even back when the pro=
blem
was found it would not always happen.

So it is, still a bit hackish, an attempt to play safe. All that is known=
 is
that there happened to be hosts running Xen 3.something which would do th=
at.
Historical evidence might be:

commit 389a3c02496dd1b399bb0efd005e9fa2be24e9ee
Author: Jeremy Fitzhardinge <jeremy@goop.org>
Date:   Tue Sep 18 22:46:33 2007 -0700

    xen: don't bother trying to set cr4

    Xen ignores all updates to cr4, and some versions will kill the domai=
n if
    you try to change its value.  Just ignore all changes.

Of course this is ancient v2.6.23 and it was later relaxed to just filter=
 out
some flags:

commit 2956a3511c8c5dccb1d4739ead17c7c3c23a24b7
Author: Jeremy Fitzhardinge <jeremy@goop.org>
Date:   Mon May 26 23:31:04 2008 +0100

    xen: allow some cr4 updates

    The guest can legitimately change things like cr4.OSFXSR and
    OSXMMEXCPT, so let it.

But whether there are still hosts out there running a bad version of the =
HV is
hard to say. EC2 may or may not be the only case (or not at all anymore).=
 For
upstream Linux it would be a valid decision either way. Not adding a quir=
k
because the use-case is so small. Or adding it because it avoids special =
patches
in distros and forcing those bits off on Xen 3 hosts is an acceptable dra=
wback.

At least posting it here would allow those who carry the older more intru=
sive
hack to replace that. So we do not run again into that mess like when xsa=
ve was
half-disabled by guests with that patch and hosts supporting it.

>=20
> I am still a newbie on the Amazon EC2 upload your kernel thing (hint, w=
ould
> appreciate somebody taking this patch and trying it out).
>=20
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
>=20



--------------enigF04701155E33776907F5DA0F
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://www.enigmail.net/

iQIcBAEBCgAGBQJQShYEAAoJEOhnXe7L7s6je7EP+wWVUwEZtLfe5lmf2UbhmbTW
G0I1LxsrduIjDq1HiIlUsH733LGxWKOheg/jd6x/3D3i2+dhC8h8DIvzuEnZkaUQ
iHUjmgiQAne/Qcm+qMtjtriVfNNqBw+MGCDu18Sk2JumMafxptrULTe7012VUJrd
dPWpBrQlVbuT7b8oDoCSa+Sv2rJSIvu80k8Hsf5U1HND+Sy7xxhBSZYYQQ2/7Zvt
4Lg65Ldz7bD/9N25s1JStyVVP8wmJV4o3wFeNzDXHYdX96ADQA03/X+/tzEK3GhM
ZUEtNtXudVE94YtMZkpu31mkRfDQEQeJfS3hWBBUfuRV42/N9wuoW59esLZgoE2H
TI4GNjK+K0KTYdANx/QmlHh8Z4RTQPPeQEzkekJA84+wmDpq20p5VsEEWrgP7WF3
z4knzmPSA2vRrlWTUbR0UUmhoIvU//W1s+AiJqGUvpwLClnUlf55LG5FUBA05mV/
JPaSGR1U8Un9B+b4NRqKuleRvFPInqTJYWFJ0w/ngzq0DJm5RNdu1pK5Oj9Xr3mq
aw4aGBprzlEaee3kZgRqFR8jy1epzFXszBDst4fnxWmz8TETGTaB4bQ8SMRp2mGi
XvB7Kliv5G6PbBEUM7js+drjWFHRbgpsw7nFOFbXklATx0lCFkwGZSc+0oqgFrQT
vAbZBpXUwAb0eH3ovA+Z
=Wi7N
-----END PGP SIGNATURE-----

--------------enigF04701155E33776907F5DA0F--


--===============7317408952724608783==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============7317408952724608783==--


From xen-devel-bounces@lists.xen.org Fri Sep 07 15:43:58 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Sep 2012 15:43: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 1TA0ib-0003vh-C7; Fri, 07 Sep 2012 15:43:41 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1TA0ia-0003vR-51
	for xen-devel@lists.xen.org; Fri, 07 Sep 2012 15:43:40 +0000
Received: from [85.158.138.51:60846] by server-3.bemta-3.messagelabs.com id
	9F/7E-21322-B261A405; Fri, 07 Sep 2012 15:43:39 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1347032618!27632411!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM4ODU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9210 invoked from network); 7 Sep 2012 15:43:38 -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;
	7 Sep 2012 15:43:38 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 07 Sep 2012 16:43:38 +0100
Message-Id: <504A32800200007800099E40@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 07 Sep 2012 16:44:32 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Justin M. Forbes" <jmforbes@linuxtx.org>
References: <1347018043-21252-1-git-send-email-stefan.bader@canonical.com>
	<504A05B00200007800099C7B@nat28.tlf.novell.com>
	<5049F4E9.9050306@canonical.com>
	<504A1A950200007800099D4C@nat28.tlf.novell.com>
	<20120907142251.GA20096@linuxtx.org>
In-Reply-To: <20120907142251.GA20096@linuxtx.org>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Stefan Bader <stefan.bader@canonical.com>,
	Matt Wilson <msw@amazon.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH/RFC] Fix xsave bug on older Xen hypervisors
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.09.12 at 16:22, "Justin M. Forbes" <jmforbes@linuxtx.org> wrote:
> On Fri, Sep 07, 2012 at 03:02:29PM +0100, Jan Beulich wrote:
>> >>> On 07.09.12 at 15:21, Stefan Bader <stefan.bader@canonical.com> wrote:
>> > On 07.09.2012 14:33, Jan Beulich wrote:
>> >>>>> On 07.09.12 at 13:40, Stefan Bader <stefan.bader@canonical.com> wrote:
>> >>> When writing unsupported flags into CR4 (for some time the
>> >>> xen_write_cr4 function would refuse to do anything at all)
>> >>> older Xen hypervisors (and patch can potentially be improved
>> >>> by finding out what older means in version numbers) would
>> >>> crash the guest.
>> >>>
>> >>> Since Amazon EC2 would at least in the past be affected by that,
>> >>> Fedora and Ubuntu were carrying a hack that would filter out
>> >>> X86_CR4_OSXSAVE before writing to CR4. This would affect any
>> >>> PV guest, even those running on a newer HV.
>> >>>
>> >>> And this recently caused trouble because some user-space was
>> >>> only partially checking (or maybe only looking at the cpuid
>> >>> bits) and then trying to use xsave even though the OS support
>> >>> was not set.
>> >>>
>> >>> So I came up with a patch that would
>> >>> - limit the work-around to certain Xen versions
>> >>> - prevent the write to CR4 by unsetting xsave and osxsave in
>> >>>   the cpuid bits
>> >>>
>> >>> Doing things that way may actually allow this to be acceptable
>> >>> upstream, so I am sending it around, now.
>> >>> It probably could be improved when knowing the exact version
>> >>> to test for but otherwise should allow to work around the guest
>> >>> crash while not preventing xsave on Xen 4.x and newer hosts.
>> >> 
>> >> Before considering a hack like this, I'd really like to see evidence
>> >> of the described behavior with an upstream kernel (i.e. not one
>> >> with that known broken hack patched in, which has never been
>> >> upstream afaict).
>> > 
>> > This is the reason I wrote that Fedora and Ubuntu were carrying it. It 
> never 
>> > has
>> > been send upstream (the other version) because it would filter the CR4 
> write 
>> > for
>> > any PV guest regardless of host version.
>> 
>> But iirc that bad patch is a Linux side one (i.e. you're trying to fix
>> something upstream that isn't upstream)?
>> 
> Right, so the patch that this improves upon, and that Fedora and Ubuntu are
> currently carrying is not upstream because:
> 
> a) It's crap, it cripples upstream xen users, but doesn't impact RHEL xen
> users because xsave was never supported there.
> 
> b) The hypervisor was patched to make it unnecessary quite some time ago,
> and we hoped EC2 would eventually pick up that correct patch and we could
> drop the crap kernel patch.
> 
> Unfortunately this has not happened. We are at a point where EC2 really is
> a quirk that has to be worked around. Distros do not want to maintain
> a separate EC2 build of the kernel, so the easiest way is to cripple
> current upstream xen users.  This quirk is unfortunately the best possible
> solution.  Having it upstream also makes it possible for any user to build
> an upstream kernel that will run on EC2 without having to dig a random
> patch out of a vendor kernel.

All of this still doesn't provide evidence that a plain upstream
kernel is actually having any problems in the first place. Further,
if you say EC2 has a crippled hypervisor patch - is that patch
available for looking at somewhere?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 07 15:43:58 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Sep 2012 15:43: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 1TA0ib-0003vh-C7; Fri, 07 Sep 2012 15:43:41 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1TA0ia-0003vR-51
	for xen-devel@lists.xen.org; Fri, 07 Sep 2012 15:43:40 +0000
Received: from [85.158.138.51:60846] by server-3.bemta-3.messagelabs.com id
	9F/7E-21322-B261A405; Fri, 07 Sep 2012 15:43:39 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1347032618!27632411!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM4ODU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9210 invoked from network); 7 Sep 2012 15:43:38 -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;
	7 Sep 2012 15:43:38 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 07 Sep 2012 16:43:38 +0100
Message-Id: <504A32800200007800099E40@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 07 Sep 2012 16:44:32 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Justin M. Forbes" <jmforbes@linuxtx.org>
References: <1347018043-21252-1-git-send-email-stefan.bader@canonical.com>
	<504A05B00200007800099C7B@nat28.tlf.novell.com>
	<5049F4E9.9050306@canonical.com>
	<504A1A950200007800099D4C@nat28.tlf.novell.com>
	<20120907142251.GA20096@linuxtx.org>
In-Reply-To: <20120907142251.GA20096@linuxtx.org>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Stefan Bader <stefan.bader@canonical.com>,
	Matt Wilson <msw@amazon.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH/RFC] Fix xsave bug on older Xen hypervisors
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.09.12 at 16:22, "Justin M. Forbes" <jmforbes@linuxtx.org> wrote:
> On Fri, Sep 07, 2012 at 03:02:29PM +0100, Jan Beulich wrote:
>> >>> On 07.09.12 at 15:21, Stefan Bader <stefan.bader@canonical.com> wrote:
>> > On 07.09.2012 14:33, Jan Beulich wrote:
>> >>>>> On 07.09.12 at 13:40, Stefan Bader <stefan.bader@canonical.com> wrote:
>> >>> When writing unsupported flags into CR4 (for some time the
>> >>> xen_write_cr4 function would refuse to do anything at all)
>> >>> older Xen hypervisors (and patch can potentially be improved
>> >>> by finding out what older means in version numbers) would
>> >>> crash the guest.
>> >>>
>> >>> Since Amazon EC2 would at least in the past be affected by that,
>> >>> Fedora and Ubuntu were carrying a hack that would filter out
>> >>> X86_CR4_OSXSAVE before writing to CR4. This would affect any
>> >>> PV guest, even those running on a newer HV.
>> >>>
>> >>> And this recently caused trouble because some user-space was
>> >>> only partially checking (or maybe only looking at the cpuid
>> >>> bits) and then trying to use xsave even though the OS support
>> >>> was not set.
>> >>>
>> >>> So I came up with a patch that would
>> >>> - limit the work-around to certain Xen versions
>> >>> - prevent the write to CR4 by unsetting xsave and osxsave in
>> >>>   the cpuid bits
>> >>>
>> >>> Doing things that way may actually allow this to be acceptable
>> >>> upstream, so I am sending it around, now.
>> >>> It probably could be improved when knowing the exact version
>> >>> to test for but otherwise should allow to work around the guest
>> >>> crash while not preventing xsave on Xen 4.x and newer hosts.
>> >> 
>> >> Before considering a hack like this, I'd really like to see evidence
>> >> of the described behavior with an upstream kernel (i.e. not one
>> >> with that known broken hack patched in, which has never been
>> >> upstream afaict).
>> > 
>> > This is the reason I wrote that Fedora and Ubuntu were carrying it. It 
> never 
>> > has
>> > been send upstream (the other version) because it would filter the CR4 
> write 
>> > for
>> > any PV guest regardless of host version.
>> 
>> But iirc that bad patch is a Linux side one (i.e. you're trying to fix
>> something upstream that isn't upstream)?
>> 
> Right, so the patch that this improves upon, and that Fedora and Ubuntu are
> currently carrying is not upstream because:
> 
> a) It's crap, it cripples upstream xen users, but doesn't impact RHEL xen
> users because xsave was never supported there.
> 
> b) The hypervisor was patched to make it unnecessary quite some time ago,
> and we hoped EC2 would eventually pick up that correct patch and we could
> drop the crap kernel patch.
> 
> Unfortunately this has not happened. We are at a point where EC2 really is
> a quirk that has to be worked around. Distros do not want to maintain
> a separate EC2 build of the kernel, so the easiest way is to cripple
> current upstream xen users.  This quirk is unfortunately the best possible
> solution.  Having it upstream also makes it possible for any user to build
> an upstream kernel that will run on EC2 without having to dig a random
> patch out of a vendor kernel.

All of this still doesn't provide evidence that a plain upstream
kernel is actually having any problems in the first place. Further,
if you say EC2 has a crippled hypervisor patch - is that patch
available for looking at somewhere?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 07 15:44:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Sep 2012 15:44:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TA0in-0003xk-Pb; Fri, 07 Sep 2012 15:43:53 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1TA0il-0003xE-Nl
	for xen-devel@lists.xen.org; Fri, 07 Sep 2012 15:43:51 +0000
Received: from [85.158.138.51:63763] by server-4.bemta-3.messagelabs.com id
	B7/3B-24831-6361A405; Fri, 07 Sep 2012 15:43:50 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1347032623!29328918!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTIyMTE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20661 invoked from network); 7 Sep 2012 15:43:44 -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 Sep 2012 15:43:44 -0000
X-IronPort-AV: E=Sophos;i="4.80,387,1344211200"; d="scan'208";a="14414050"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Sep 2012 15:43: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.279.1; Fri, 7 Sep 2012
	16:43:10 +0100
Message-ID: <1347032589.30018.122.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Fri, 7 Sep 2012 16:43:09 +0100
In-Reply-To: <504A309A0200007800099E2B@nat28.tlf.novell.com>
References: <1347027296.30018.108.camel@zakaz.uk.xensource.com>
	<504A309A0200007800099E2B@nat28.tlf.novell.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.2 new features and status -- please help me
	make a list
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-09-07 at 16:36 +0100, Jan Beulich wrote:
> >>> On 07.09.12 at 16:14, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> > Of course if you know of a feature in 4.2 which isn't mentioned but
> > which you think is worthwhile please let me know. I'm sure there are
> > plenty which I missed.
> 
> Not sure whether boot time CPU microcode patching is worth
> mentioning. Certainly this is nothing user visible.

This is the thing which can load microcode without needing to wait for
the dom0 kernel to pass it up a blob?

I'm not sure about the feature lists (I suppose it is useful to mention)
but extracting the commit log of 24315:3e5683b6b37f into some doc
somewhere might be useful for users?

(unless you did already and I failed to find it, of course)

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 07 15:44:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Sep 2012 15:44:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TA0in-0003xk-Pb; Fri, 07 Sep 2012 15:43:53 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1TA0il-0003xE-Nl
	for xen-devel@lists.xen.org; Fri, 07 Sep 2012 15:43:51 +0000
Received: from [85.158.138.51:63763] by server-4.bemta-3.messagelabs.com id
	B7/3B-24831-6361A405; Fri, 07 Sep 2012 15:43:50 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1347032623!29328918!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTIyMTE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20661 invoked from network); 7 Sep 2012 15:43:44 -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 Sep 2012 15:43:44 -0000
X-IronPort-AV: E=Sophos;i="4.80,387,1344211200"; d="scan'208";a="14414050"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Sep 2012 15:43: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.279.1; Fri, 7 Sep 2012
	16:43:10 +0100
Message-ID: <1347032589.30018.122.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Fri, 7 Sep 2012 16:43:09 +0100
In-Reply-To: <504A309A0200007800099E2B@nat28.tlf.novell.com>
References: <1347027296.30018.108.camel@zakaz.uk.xensource.com>
	<504A309A0200007800099E2B@nat28.tlf.novell.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.2 new features and status -- please help me
	make a list
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-09-07 at 16:36 +0100, Jan Beulich wrote:
> >>> On 07.09.12 at 16:14, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> > Of course if you know of a feature in 4.2 which isn't mentioned but
> > which you think is worthwhile please let me know. I'm sure there are
> > plenty which I missed.
> 
> Not sure whether boot time CPU microcode patching is worth
> mentioning. Certainly this is nothing user visible.

This is the thing which can load microcode without needing to wait for
the dom0 kernel to pass it up a blob?

I'm not sure about the feature lists (I suppose it is useful to mention)
but extracting the commit log of 24315:3e5683b6b37f into some doc
somewhere might be useful for users?

(unless you did already and I failed to find it, of course)

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 07 15:44:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Sep 2012 15:44:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TA0iq-0003yI-6G; Fri, 07 Sep 2012 15:43:56 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1TA0ip-0003y1-8D
	for xen-devel@lists.xen.org; Fri, 07 Sep 2012 15:43:55 +0000
Received: from [85.158.139.83:44487] by server-11.bemta-5.messagelabs.com id
	2C/87-24658-A361A405; Fri, 07 Sep 2012 15:43:54 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1347032633!28969644!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTIyMTE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10373 invoked from network); 7 Sep 2012 15:43:54 -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 Sep 2012 15:43:54 -0000
X-IronPort-AV: E=Sophos;i="4.80,387,1344211200"; d="scan'208";a="14414072"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Sep 2012 15:43: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.279.1; Fri, 7 Sep 2012
	16:43:53 +0100
Message-ID: <1347032632.30018.123.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Christoph Egger <Christoph.Egger@amd.com>
Date: Fri, 7 Sep 2012 16:43:52 +0100
In-Reply-To: <504A0426.2090607@amd.com>
References: <1347027296.30018.108.camel@zakaz.uk.xensource.com>
	<504A0426.2090607@amd.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.2 new features and status -- please help me
 make a list
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-09-07 at 15:26 +0100, Christoph Egger wrote:

> > AMD OSVW: What is this?
> >         Seems to be new in 4.2?
> 
> 
> OSVW (OS Visible Workarounds): Support for guests has been added
> to make them disable workarounds for hw bugs not emulated/present
> for guests.

Makes sense, thanks!



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 07 15:44:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Sep 2012 15:44:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TA0iq-0003yI-6G; Fri, 07 Sep 2012 15:43:56 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1TA0ip-0003y1-8D
	for xen-devel@lists.xen.org; Fri, 07 Sep 2012 15:43:55 +0000
Received: from [85.158.139.83:44487] by server-11.bemta-5.messagelabs.com id
	2C/87-24658-A361A405; Fri, 07 Sep 2012 15:43:54 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1347032633!28969644!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTIyMTE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10373 invoked from network); 7 Sep 2012 15:43:54 -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 Sep 2012 15:43:54 -0000
X-IronPort-AV: E=Sophos;i="4.80,387,1344211200"; d="scan'208";a="14414072"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Sep 2012 15:43: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.279.1; Fri, 7 Sep 2012
	16:43:53 +0100
Message-ID: <1347032632.30018.123.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Christoph Egger <Christoph.Egger@amd.com>
Date: Fri, 7 Sep 2012 16:43:52 +0100
In-Reply-To: <504A0426.2090607@amd.com>
References: <1347027296.30018.108.camel@zakaz.uk.xensource.com>
	<504A0426.2090607@amd.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.2 new features and status -- please help me
 make a list
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-09-07 at 15:26 +0100, Christoph Egger wrote:

> > AMD OSVW: What is this?
> >         Seems to be new in 4.2?
> 
> 
> OSVW (OS Visible Workarounds): Support for guests has been added
> to make them disable workarounds for hw bugs not emulated/present
> for guests.

Makes sense, thanks!



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 07 15:48:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Sep 2012 15:48:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TA0mo-0004cx-Tn; Fri, 07 Sep 2012 15:48:02 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1TA0mn-0004cl-NC
	for xen-devel@lists.xen.org; Fri, 07 Sep 2012 15:48:01 +0000
Received: from [85.158.138.51:34149] by server-7.bemta-3.messagelabs.com id
	2B/05-32000-0371A405; Fri, 07 Sep 2012 15:48:00 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1347032879!10637879!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTIyMTE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7191 invoked from network); 7 Sep 2012 15:48:00 -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 Sep 2012 15:48:00 -0000
X-IronPort-AV: E=Sophos;i="4.80,387,1344211200"; d="scan'208";a="14414167"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Sep 2012 15: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.279.1; Fri, 7 Sep 2012
	16:47:59 +0100
Message-ID: <1347032878.30018.127.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Andres Lagar-Cavilla <andres.lagarcavilla@gmail.com>
Date: Fri, 7 Sep 2012 16:47:58 +0100
In-Reply-To: <8149449A-BB9D-40AE-945F-ACED38979F19@gmail.com>
References: <1347027296.30018.108.camel@zakaz.uk.xensource.com>
	<8149449A-BB9D-40AE-945F-ACED38979F19@gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Olaf Hering <olaf@aepfle.de>, Tim
	Deegan <tim@xen.org>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.2 new features and status -- please help me
	make a list
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-09-07 at 15:34 +0100, Andres Lagar-Cavilla wrote:

> > xenpaging: Page HVM guest pages to disk
> >        Was marked as tech preview in 4.1 and earlier, still is?
> > 
> > memsharing: Sharing of HVM guest pages.
> >        Was marked as tech preview in 4.1 and earlier, still is?
> 
> Both xenpaging and memsharing are functional as far as I am concerned.

This is on the hypervisor side I guess? Or are the tools as supplied in
the xen tree useful too?

It's a tricky one in terms of how to describe it on xen.org if not. I'd
be inclined to go "yes" on the basis of the hypervisor side being solid,
apart from the two caveats you then mention below (mainly the border
conditions one).

>  Intel EPT is the platform of choice. There are many reports of
> success on AMD insofar xenpaging goes, but I haven't gotten good
> traction with either xen{paging/sharing} on AMD. 
> 
> Please note that memsharing has been significantly overhauled both at
> an interface and internals level. It bears almost no resemblance to
> the 4.1 release.

I'll mention that somewhere too.

> Xen{paging/sharing} still have border conditions in which domains are
> crashed. They are rare enough that I have not experienced them in
> practice. This is due to a need for more mature wait queue code in the
> hypervisor. The plan is to address this in 4.3.

Perhaps that's an argument for leaving it as tech-preview until 4.3
then?

> Finally, mem-access has seen improvements and extensions. Now you can
> get a log of all memory accesses by a guest (if you so wished) using
> the n2rwx mode.

thanks, I'll be sure to mention that.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 07 15:48:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Sep 2012 15:48:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TA0mo-0004cx-Tn; Fri, 07 Sep 2012 15:48:02 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1TA0mn-0004cl-NC
	for xen-devel@lists.xen.org; Fri, 07 Sep 2012 15:48:01 +0000
Received: from [85.158.138.51:34149] by server-7.bemta-3.messagelabs.com id
	2B/05-32000-0371A405; Fri, 07 Sep 2012 15:48:00 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1347032879!10637879!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTIyMTE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7191 invoked from network); 7 Sep 2012 15:48:00 -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 Sep 2012 15:48:00 -0000
X-IronPort-AV: E=Sophos;i="4.80,387,1344211200"; d="scan'208";a="14414167"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Sep 2012 15: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.279.1; Fri, 7 Sep 2012
	16:47:59 +0100
Message-ID: <1347032878.30018.127.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Andres Lagar-Cavilla <andres.lagarcavilla@gmail.com>
Date: Fri, 7 Sep 2012 16:47:58 +0100
In-Reply-To: <8149449A-BB9D-40AE-945F-ACED38979F19@gmail.com>
References: <1347027296.30018.108.camel@zakaz.uk.xensource.com>
	<8149449A-BB9D-40AE-945F-ACED38979F19@gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Olaf Hering <olaf@aepfle.de>, Tim
	Deegan <tim@xen.org>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.2 new features and status -- please help me
	make a list
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-09-07 at 15:34 +0100, Andres Lagar-Cavilla wrote:

> > xenpaging: Page HVM guest pages to disk
> >        Was marked as tech preview in 4.1 and earlier, still is?
> > 
> > memsharing: Sharing of HVM guest pages.
> >        Was marked as tech preview in 4.1 and earlier, still is?
> 
> Both xenpaging and memsharing are functional as far as I am concerned.

This is on the hypervisor side I guess? Or are the tools as supplied in
the xen tree useful too?

It's a tricky one in terms of how to describe it on xen.org if not. I'd
be inclined to go "yes" on the basis of the hypervisor side being solid,
apart from the two caveats you then mention below (mainly the border
conditions one).

>  Intel EPT is the platform of choice. There are many reports of
> success on AMD insofar xenpaging goes, but I haven't gotten good
> traction with either xen{paging/sharing} on AMD. 
> 
> Please note that memsharing has been significantly overhauled both at
> an interface and internals level. It bears almost no resemblance to
> the 4.1 release.

I'll mention that somewhere too.

> Xen{paging/sharing} still have border conditions in which domains are
> crashed. They are rare enough that I have not experienced them in
> practice. This is due to a need for more mature wait queue code in the
> hypervisor. The plan is to address this in 4.3.

Perhaps that's an argument for leaving it as tech-preview until 4.3
then?

> Finally, mem-access has seen improvements and extensions. Now you can
> get a log of all memory accesses by a guest (if you so wished) using
> the n2rwx mode.

thanks, I'll be sure to mention that.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 07 15:48:18 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Sep 2012 15:48:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TA0mv-0004dp-A9; Fri, 07 Sep 2012 15:48:09 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <stefan.bader@canonical.com>) id 1TA0mt-0004cr-CL
	for xen-devel@lists.xen.org; Fri, 07 Sep 2012 15:48:07 +0000
X-Env-Sender: stefan.bader@canonical.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1347032880!8803184!1
X-Originating-IP: [91.189.89.112]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18546 invoked from network); 7 Sep 2012 15:48:00 -0000
Received: from youngberry.canonical.com (HELO youngberry.canonical.com)
	(91.189.89.112) by server-9.tower-27.messagelabs.com with SMTP;
	7 Sep 2012 15:48:00 -0000
Received: from p5b2e2384.dip.t-dialin.net ([91.46.35.132] 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 1TA0mj-0006rb-Di; Fri, 07 Sep 2012 15:47:57 +0000
Message-ID: <504A172B.5020005@canonical.com>
Date: Fri, 07 Sep 2012 17:47:55 +0200
From: Stefan Bader <stefan.bader@canonical.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120827 Thunderbird/15.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <1347018043-21252-1-git-send-email-stefan.bader@canonical.com>
	<504A05B00200007800099C7B@nat28.tlf.novell.com>
	<5049F4E9.9050306@canonical.com>
	<504A1A950200007800099D4C@nat28.tlf.novell.com>
	<20120907142251.GA20096@linuxtx.org>
	<504A32800200007800099E40@nat28.tlf.novell.com>
In-Reply-To: <504A32800200007800099E40@nat28.tlf.novell.com>
X-Enigmail-Version: 1.4.4
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"Justin M. Forbes" <jmforbes@linuxtx.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Matt Wilson <msw@amazon.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH/RFC] Fix xsave bug on older Xen hypervisors
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============6818452496314499670=="
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)
--===============6818452496314499670==
Content-Type: multipart/signed; micalg=pgp-sha512;
 protocol="application/pgp-signature";
 boundary="------------enig1CE0EE74CDFE79A5EB5D6AA5"

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig1CE0EE74CDFE79A5EB5D6AA5
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On 07.09.2012 17:44, Jan Beulich wrote:
>>>> On 07.09.12 at 16:22, "Justin M. Forbes" <jmforbes@linuxtx.org> wrot=
e:
>> On Fri, Sep 07, 2012 at 03:02:29PM +0100, Jan Beulich wrote:
>>>>>> On 07.09.12 at 15:21, Stefan Bader <stefan.bader@canonical.com> wr=
ote:
>>>> On 07.09.2012 14:33, Jan Beulich wrote:
>>>>>>>> On 07.09.12 at 13:40, Stefan Bader <stefan.bader@canonical.com> =
wrote:
>>>>>> When writing unsupported flags into CR4 (for some time the
>>>>>> xen_write_cr4 function would refuse to do anything at all)
>>>>>> older Xen hypervisors (and patch can potentially be improved
>>>>>> by finding out what older means in version numbers) would
>>>>>> crash the guest.
>>>>>>
>>>>>> Since Amazon EC2 would at least in the past be affected by that,
>>>>>> Fedora and Ubuntu were carrying a hack that would filter out
>>>>>> X86_CR4_OSXSAVE before writing to CR4. This would affect any
>>>>>> PV guest, even those running on a newer HV.
>>>>>>
>>>>>> And this recently caused trouble because some user-space was
>>>>>> only partially checking (or maybe only looking at the cpuid
>>>>>> bits) and then trying to use xsave even though the OS support
>>>>>> was not set.
>>>>>>
>>>>>> So I came up with a patch that would
>>>>>> - limit the work-around to certain Xen versions
>>>>>> - prevent the write to CR4 by unsetting xsave and osxsave in
>>>>>>   the cpuid bits
>>>>>>
>>>>>> Doing things that way may actually allow this to be acceptable
>>>>>> upstream, so I am sending it around, now.
>>>>>> It probably could be improved when knowing the exact version
>>>>>> to test for but otherwise should allow to work around the guest
>>>>>> crash while not preventing xsave on Xen 4.x and newer hosts.
>>>>>
>>>>> Before considering a hack like this, I'd really like to see evidenc=
e
>>>>> of the described behavior with an upstream kernel (i.e. not one
>>>>> with that known broken hack patched in, which has never been
>>>>> upstream afaict).
>>>>
>>>> This is the reason I wrote that Fedora and Ubuntu were carrying it. =
It=20
>> never=20
>>>> has
>>>> been send upstream (the other version) because it would filter the C=
R4=20
>> write=20
>>>> for
>>>> any PV guest regardless of host version.
>>>
>>> But iirc that bad patch is a Linux side one (i.e. you're trying to fi=
x
>>> something upstream that isn't upstream)?
>>>
>> Right, so the patch that this improves upon, and that Fedora and Ubunt=
u are
>> currently carrying is not upstream because:
>>
>> a) It's crap, it cripples upstream xen users, but doesn't impact RHEL =
xen
>> users because xsave was never supported there.
>>
>> b) The hypervisor was patched to make it unnecessary quite some time a=
go,
>> and we hoped EC2 would eventually pick up that correct patch and we co=
uld
>> drop the crap kernel patch.
>>
>> Unfortunately this has not happened. We are at a point where EC2 reall=
y is
>> a quirk that has to be worked around. Distros do not want to maintain
>> a separate EC2 build of the kernel, so the easiest way is to cripple
>> current upstream xen users.  This quirk is unfortunately the best poss=
ible
>> solution.  Having it upstream also makes it possible for any user to b=
uild
>> an upstream kernel that will run on EC2 without having to dig a random=

>> patch out of a vendor kernel.
>=20
> All of this still doesn't provide evidence that a plain upstream
> kernel is actually having any problems in the first place. Further,
> if you say EC2 has a crippled hypervisor patch - is that patch
> available for looking at somewhere?

It was not a hypervisor patch. It was one for the guest. This was the hac=
k:

=46rom 57bb316c938a9ad65a8093f0584fd22eda88521f Mon Sep 17 00:00:00 2001
From: John Johansen <john.johansen@canonical.com>
Date: Tue, 27 Jul 2010 06:06:07 -0700
Subject: [PATCH] UBUNTU: SAUCE: fix pv-ops for legacy Xen

Import fix_xen_guest_on_old_EC2.patch from fedora 14

Legacy hypervisors (RHEL 5.0 and RHEL 5.1) do not handle guest writes to
cr4 gracefully. If a guest attempts to write a bit of cr4 that is
unsupported, then the HV is so offended it crashes the domain. While
later guest kernels (such as RHEL6) don't assume the HV supports all
features, they do expect nicer responses. That assumption introduced
code that probes whether or not xsave is supported early in the boot. So
now when attempting to boot a RHEL6 guest on RHEL5.0 or RHEL5.1 an early
crash will occur.

This patch is quite obviously an undesirable hack. The real fix for this
problem should be in the HV, and is, in later HVs. However, to support
running on old HVs, RHEL6 can take this small change. No impact will
occur for running on any RHEL HV (not even RHEL 5.5 supports xsave).
There is only potential for guest performance loss on upstream Xen.

All this by way of explanation for why is this patch not going upstream.

Signed-off-by: John Johansen <john.johansen@canonical.com>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Signed-off-by: Leann Ogasawara <leann.ogasawara@canonical.com>
---
 arch/x86/xen/enlighten.c |    1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
index 1f92865..9043464 100644
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -806,6 +806,7 @@ static void xen_write_cr4(unsigned long cr4)
 {
 	cr4 &=3D ~X86_CR4_PGE;
 	cr4 &=3D ~X86_CR4_PSE;
+	cr4 &=3D ~X86_CR4_OSXSAVE;

 	native_write_cr4(cr4);
 }
--=20
1.7.9.5

>=20
> Jan
>=20



--------------enig1CE0EE74CDFE79A5EB5D6AA5
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://www.enigmail.net/

iQIcBAEBCgAGBQJQShcrAAoJEOhnXe7L7s6jFYQQAI7ZytEr9xU0BgscmruP4EAK
nqFeGDmjCwY2NBBq5O+oLVUAxchSMPmmcu7Lfm46abYxdmOiXJRLyIY3rc8k7DV3
7RKszXVgzZ8+56Y5ier6oXCSERPqYHtx0Iw6fn4s/XexWtBHe7YeFmOUVF3XXSv0
gqycW770GhpIPOynIfuCe9XGdnUcDS3UBdSAHF6z39qD6hOx1Zywv1MArcPXFTbq
LOnZr39Gowu+WrEKgvSu4IB7jNvz0184uplrgZlBilL1MO2znG9AOEZB+OZIf0PV
oiVEfolQztHOPZ9juDBU65IWUWqlqcJ/YQ5KGXIAN7V0YeJ5Hwfnl7jNe4nBVZVh
BQHKysCgiyPFj3pt7JQAlTz/VRl+4dxGmjl21EhuNfvMYy4nriIytslXUCwXzG8Z
yFl+xKegHbI3lybkFu/VMDYuARkjZdK3X7OYaP8123L6PRUs96xhqJVvP7MF1dBu
cqe4rh0rBJQFOvh+H2zl4V48GUhpV2qQK0rxE9o+wwi8EPC82UMSZ3oICbiuROBK
zWb5uYbQY2T6IiZtyTvLVzGyYkoBmbIXrDoQt7gYjwlF09UoFW12dYeR0zAmLdT9
iM2T6Ss3+9F5mkJkGPC0Cx2mT2XlLv09YqGppxeHY1fGE3EFvQ8+jy7Go6EdGMtD
fIXR2mXNMOigfH4Lo81Y
=rjU0
-----END PGP SIGNATURE-----

--------------enig1CE0EE74CDFE79A5EB5D6AA5--


--===============6818452496314499670==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============6818452496314499670==--


From xen-devel-bounces@lists.xen.org Fri Sep 07 15:48:18 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Sep 2012 15:48:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TA0mv-0004dp-A9; Fri, 07 Sep 2012 15:48:09 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <stefan.bader@canonical.com>) id 1TA0mt-0004cr-CL
	for xen-devel@lists.xen.org; Fri, 07 Sep 2012 15:48:07 +0000
X-Env-Sender: stefan.bader@canonical.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1347032880!8803184!1
X-Originating-IP: [91.189.89.112]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18546 invoked from network); 7 Sep 2012 15:48:00 -0000
Received: from youngberry.canonical.com (HELO youngberry.canonical.com)
	(91.189.89.112) by server-9.tower-27.messagelabs.com with SMTP;
	7 Sep 2012 15:48:00 -0000
Received: from p5b2e2384.dip.t-dialin.net ([91.46.35.132] 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 1TA0mj-0006rb-Di; Fri, 07 Sep 2012 15:47:57 +0000
Message-ID: <504A172B.5020005@canonical.com>
Date: Fri, 07 Sep 2012 17:47:55 +0200
From: Stefan Bader <stefan.bader@canonical.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120827 Thunderbird/15.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <1347018043-21252-1-git-send-email-stefan.bader@canonical.com>
	<504A05B00200007800099C7B@nat28.tlf.novell.com>
	<5049F4E9.9050306@canonical.com>
	<504A1A950200007800099D4C@nat28.tlf.novell.com>
	<20120907142251.GA20096@linuxtx.org>
	<504A32800200007800099E40@nat28.tlf.novell.com>
In-Reply-To: <504A32800200007800099E40@nat28.tlf.novell.com>
X-Enigmail-Version: 1.4.4
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"Justin M. Forbes" <jmforbes@linuxtx.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Matt Wilson <msw@amazon.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH/RFC] Fix xsave bug on older Xen hypervisors
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============6818452496314499670=="
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)
--===============6818452496314499670==
Content-Type: multipart/signed; micalg=pgp-sha512;
 protocol="application/pgp-signature";
 boundary="------------enig1CE0EE74CDFE79A5EB5D6AA5"

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig1CE0EE74CDFE79A5EB5D6AA5
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On 07.09.2012 17:44, Jan Beulich wrote:
>>>> On 07.09.12 at 16:22, "Justin M. Forbes" <jmforbes@linuxtx.org> wrot=
e:
>> On Fri, Sep 07, 2012 at 03:02:29PM +0100, Jan Beulich wrote:
>>>>>> On 07.09.12 at 15:21, Stefan Bader <stefan.bader@canonical.com> wr=
ote:
>>>> On 07.09.2012 14:33, Jan Beulich wrote:
>>>>>>>> On 07.09.12 at 13:40, Stefan Bader <stefan.bader@canonical.com> =
wrote:
>>>>>> When writing unsupported flags into CR4 (for some time the
>>>>>> xen_write_cr4 function would refuse to do anything at all)
>>>>>> older Xen hypervisors (and patch can potentially be improved
>>>>>> by finding out what older means in version numbers) would
>>>>>> crash the guest.
>>>>>>
>>>>>> Since Amazon EC2 would at least in the past be affected by that,
>>>>>> Fedora and Ubuntu were carrying a hack that would filter out
>>>>>> X86_CR4_OSXSAVE before writing to CR4. This would affect any
>>>>>> PV guest, even those running on a newer HV.
>>>>>>
>>>>>> And this recently caused trouble because some user-space was
>>>>>> only partially checking (or maybe only looking at the cpuid
>>>>>> bits) and then trying to use xsave even though the OS support
>>>>>> was not set.
>>>>>>
>>>>>> So I came up with a patch that would
>>>>>> - limit the work-around to certain Xen versions
>>>>>> - prevent the write to CR4 by unsetting xsave and osxsave in
>>>>>>   the cpuid bits
>>>>>>
>>>>>> Doing things that way may actually allow this to be acceptable
>>>>>> upstream, so I am sending it around, now.
>>>>>> It probably could be improved when knowing the exact version
>>>>>> to test for but otherwise should allow to work around the guest
>>>>>> crash while not preventing xsave on Xen 4.x and newer hosts.
>>>>>
>>>>> Before considering a hack like this, I'd really like to see evidenc=
e
>>>>> of the described behavior with an upstream kernel (i.e. not one
>>>>> with that known broken hack patched in, which has never been
>>>>> upstream afaict).
>>>>
>>>> This is the reason I wrote that Fedora and Ubuntu were carrying it. =
It=20
>> never=20
>>>> has
>>>> been send upstream (the other version) because it would filter the C=
R4=20
>> write=20
>>>> for
>>>> any PV guest regardless of host version.
>>>
>>> But iirc that bad patch is a Linux side one (i.e. you're trying to fi=
x
>>> something upstream that isn't upstream)?
>>>
>> Right, so the patch that this improves upon, and that Fedora and Ubunt=
u are
>> currently carrying is not upstream because:
>>
>> a) It's crap, it cripples upstream xen users, but doesn't impact RHEL =
xen
>> users because xsave was never supported there.
>>
>> b) The hypervisor was patched to make it unnecessary quite some time a=
go,
>> and we hoped EC2 would eventually pick up that correct patch and we co=
uld
>> drop the crap kernel patch.
>>
>> Unfortunately this has not happened. We are at a point where EC2 reall=
y is
>> a quirk that has to be worked around. Distros do not want to maintain
>> a separate EC2 build of the kernel, so the easiest way is to cripple
>> current upstream xen users.  This quirk is unfortunately the best poss=
ible
>> solution.  Having it upstream also makes it possible for any user to b=
uild
>> an upstream kernel that will run on EC2 without having to dig a random=

>> patch out of a vendor kernel.
>=20
> All of this still doesn't provide evidence that a plain upstream
> kernel is actually having any problems in the first place. Further,
> if you say EC2 has a crippled hypervisor patch - is that patch
> available for looking at somewhere?

It was not a hypervisor patch. It was one for the guest. This was the hac=
k:

=46rom 57bb316c938a9ad65a8093f0584fd22eda88521f Mon Sep 17 00:00:00 2001
From: John Johansen <john.johansen@canonical.com>
Date: Tue, 27 Jul 2010 06:06:07 -0700
Subject: [PATCH] UBUNTU: SAUCE: fix pv-ops for legacy Xen

Import fix_xen_guest_on_old_EC2.patch from fedora 14

Legacy hypervisors (RHEL 5.0 and RHEL 5.1) do not handle guest writes to
cr4 gracefully. If a guest attempts to write a bit of cr4 that is
unsupported, then the HV is so offended it crashes the domain. While
later guest kernels (such as RHEL6) don't assume the HV supports all
features, they do expect nicer responses. That assumption introduced
code that probes whether or not xsave is supported early in the boot. So
now when attempting to boot a RHEL6 guest on RHEL5.0 or RHEL5.1 an early
crash will occur.

This patch is quite obviously an undesirable hack. The real fix for this
problem should be in the HV, and is, in later HVs. However, to support
running on old HVs, RHEL6 can take this small change. No impact will
occur for running on any RHEL HV (not even RHEL 5.5 supports xsave).
There is only potential for guest performance loss on upstream Xen.

All this by way of explanation for why is this patch not going upstream.

Signed-off-by: John Johansen <john.johansen@canonical.com>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Signed-off-by: Leann Ogasawara <leann.ogasawara@canonical.com>
---
 arch/x86/xen/enlighten.c |    1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
index 1f92865..9043464 100644
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -806,6 +806,7 @@ static void xen_write_cr4(unsigned long cr4)
 {
 	cr4 &=3D ~X86_CR4_PGE;
 	cr4 &=3D ~X86_CR4_PSE;
+	cr4 &=3D ~X86_CR4_OSXSAVE;

 	native_write_cr4(cr4);
 }
--=20
1.7.9.5

>=20
> Jan
>=20



--------------enig1CE0EE74CDFE79A5EB5D6AA5
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://www.enigmail.net/

iQIcBAEBCgAGBQJQShcrAAoJEOhnXe7L7s6jFYQQAI7ZytEr9xU0BgscmruP4EAK
nqFeGDmjCwY2NBBq5O+oLVUAxchSMPmmcu7Lfm46abYxdmOiXJRLyIY3rc8k7DV3
7RKszXVgzZ8+56Y5ier6oXCSERPqYHtx0Iw6fn4s/XexWtBHe7YeFmOUVF3XXSv0
gqycW770GhpIPOynIfuCe9XGdnUcDS3UBdSAHF6z39qD6hOx1Zywv1MArcPXFTbq
LOnZr39Gowu+WrEKgvSu4IB7jNvz0184uplrgZlBilL1MO2znG9AOEZB+OZIf0PV
oiVEfolQztHOPZ9juDBU65IWUWqlqcJ/YQ5KGXIAN7V0YeJ5Hwfnl7jNe4nBVZVh
BQHKysCgiyPFj3pt7JQAlTz/VRl+4dxGmjl21EhuNfvMYy4nriIytslXUCwXzG8Z
yFl+xKegHbI3lybkFu/VMDYuARkjZdK3X7OYaP8123L6PRUs96xhqJVvP7MF1dBu
cqe4rh0rBJQFOvh+H2zl4V48GUhpV2qQK0rxE9o+wwi8EPC82UMSZ3oICbiuROBK
zWb5uYbQY2T6IiZtyTvLVzGyYkoBmbIXrDoQt7gYjwlF09UoFW12dYeR0zAmLdT9
iM2T6Ss3+9F5mkJkGPC0Cx2mT2XlLv09YqGppxeHY1fGE3EFvQ8+jy7Go6EdGMtD
fIXR2mXNMOigfH4Lo81Y
=rjU0
-----END PGP SIGNATURE-----

--------------enig1CE0EE74CDFE79A5EB5D6AA5--


--===============6818452496314499670==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============6818452496314499670==--


From xen-devel-bounces@lists.xen.org Fri Sep 07 15:49:59 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Sep 2012 15: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 1TA0oX-0004ox-Tq; Fri, 07 Sep 2012 15:49:49 +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 1TA0oX-0004oZ-D7
	for xen-devel@lists.xen.org; Fri, 07 Sep 2012 15:49:49 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1347032892!3103323!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM4ODU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2111 invoked from network); 7 Sep 2012 15:48:12 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-15.tower-27.messagelabs.com with SMTP;
	7 Sep 2012 15:48:12 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 07 Sep 2012 16:48:11 +0100
Message-Id: <504A33930200007800099E5A@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 07 Sep 2012 16:49:07 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Campbell" <Ian.Campbell@citrix.com>
References: <1347027296.30018.108.camel@zakaz.uk.xensource.com>
	<504A2D710200007800099E11@nat28.tlf.novell.com>
	<1347032363.30018.120.camel@zakaz.uk.xensource.com>
In-Reply-To: <1347032363.30018.120.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 new features and status -- please help me
 make a list
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 07.09.12 at 17:39, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> On Fri, 2012-09-07 at 16:22 +0100, Jan Beulich wrote:
>> >>> On 07.09.12 at 16:14, Ian Campbell <Ian.Campbell@citrix.com> wrote:
>> > vMSI: ? Emulated (or real?) MSIs for guests?
>> >         State? New in 4.2?
>> 
>> Not sure what you're referring to here. There certainly was a
>> xen/arch/x86/hvm/vmsi.c in 4.1 already.
> 
> OK, thanks. 4.0 too by the looks of it.
> 
> What exactly is this? Is it about injection of MSIs from real
> (passthrough) hardware devices to guests (only HVM ones?) or is about
> MSIs generated by emulated devices (or both)?

I don't think emulated devices genera MSIs, so to me this is
just for passthrough. But I may be wrong.

>> > vPMU: Power Management?
>> >         New in 4.2?
>> 
>> Enhanced iirc.
> 
> But already a full feature in 4.1 and 4.0?
> 
> This lets HVM guests thing they have power management hardware, and
> tickling it does what?

Oh, I didn't pay close enough attention - PM stands for
Performance Monitor here. Iirc e.g. Fujitsu have been using
this even in 4.0 already.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 07 15:49:59 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Sep 2012 15: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 1TA0oX-0004ox-Tq; Fri, 07 Sep 2012 15:49:49 +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 1TA0oX-0004oZ-D7
	for xen-devel@lists.xen.org; Fri, 07 Sep 2012 15:49:49 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1347032892!3103323!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM4ODU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2111 invoked from network); 7 Sep 2012 15:48:12 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-15.tower-27.messagelabs.com with SMTP;
	7 Sep 2012 15:48:12 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 07 Sep 2012 16:48:11 +0100
Message-Id: <504A33930200007800099E5A@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 07 Sep 2012 16:49:07 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Campbell" <Ian.Campbell@citrix.com>
References: <1347027296.30018.108.camel@zakaz.uk.xensource.com>
	<504A2D710200007800099E11@nat28.tlf.novell.com>
	<1347032363.30018.120.camel@zakaz.uk.xensource.com>
In-Reply-To: <1347032363.30018.120.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 new features and status -- please help me
 make a list
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 07.09.12 at 17:39, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> On Fri, 2012-09-07 at 16:22 +0100, Jan Beulich wrote:
>> >>> On 07.09.12 at 16:14, Ian Campbell <Ian.Campbell@citrix.com> wrote:
>> > vMSI: ? Emulated (or real?) MSIs for guests?
>> >         State? New in 4.2?
>> 
>> Not sure what you're referring to here. There certainly was a
>> xen/arch/x86/hvm/vmsi.c in 4.1 already.
> 
> OK, thanks. 4.0 too by the looks of it.
> 
> What exactly is this? Is it about injection of MSIs from real
> (passthrough) hardware devices to guests (only HVM ones?) or is about
> MSIs generated by emulated devices (or both)?

I don't think emulated devices genera MSIs, so to me this is
just for passthrough. But I may be wrong.

>> > vPMU: Power Management?
>> >         New in 4.2?
>> 
>> Enhanced iirc.
> 
> But already a full feature in 4.1 and 4.0?
> 
> This lets HVM guests thing they have power management hardware, and
> tickling it does what?

Oh, I didn't pay close enough attention - PM stands for
Performance Monitor here. Iirc e.g. Fujitsu have been using
this even in 4.0 already.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 07 15:50:01 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Sep 2012 15:50:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TA0oc-0004pd-AC; Fri, 07 Sep 2012 15:49:54 +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 1TA0ob-0004op-Cy
	for xen-devel@lists.xen.org; Fri, 07 Sep 2012 15:49:53 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1347032987!9264368!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM4ODU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1470 invoked from network); 7 Sep 2012 15:49:47 -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;
	7 Sep 2012 15:49:47 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 07 Sep 2012 16:49:47 +0100
Message-Id: <504A33F20200007800099E8C@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 07 Sep 2012 16:50:42 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Keir Fraser" <keir.xen@gmail.com>
References: <504A09720200007800099CBD@nat28.tlf.novell.com>
	<CC6FC6C7.3E09E%keir.xen@gmail.com>
In-Reply-To: <CC6FC6C7.3E09E%keir.xen@gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] x86/MSI: fix 2nd S3 resume with interrupt
 remapping 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 07.09.12 at 16:44, Keir Fraser <keir.xen@gmail.com> wrote:
> On 07/09/2012 13:49, "Jan Beulich" <JBeulich@suse.com> wrote:
> 
>> The first resume from S3 was corrupting internal data structures (in
>> that pci_restore_msi_state() updated the globally stored MSI message
>> from traditional to interrupt remapped format, which would then be
>> translated a second time during the second resume, breaking interrupt
>> delivery).
> 
> Doesn't that mean write_msi_msg() has a bit of a hideous interface?

It does, and we may want to clean that up. But at least this won't
go unnoticed in debug builds anymore with the added assertion,
should anyone re-add a bad use 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 Sep 07 15:50:01 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Sep 2012 15:50:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TA0oc-0004pd-AC; Fri, 07 Sep 2012 15:49:54 +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 1TA0ob-0004op-Cy
	for xen-devel@lists.xen.org; Fri, 07 Sep 2012 15:49:53 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1347032987!9264368!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM4ODU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1470 invoked from network); 7 Sep 2012 15:49:47 -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;
	7 Sep 2012 15:49:47 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 07 Sep 2012 16:49:47 +0100
Message-Id: <504A33F20200007800099E8C@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 07 Sep 2012 16:50:42 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Keir Fraser" <keir.xen@gmail.com>
References: <504A09720200007800099CBD@nat28.tlf.novell.com>
	<CC6FC6C7.3E09E%keir.xen@gmail.com>
In-Reply-To: <CC6FC6C7.3E09E%keir.xen@gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] x86/MSI: fix 2nd S3 resume with interrupt
 remapping 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 07.09.12 at 16:44, Keir Fraser <keir.xen@gmail.com> wrote:
> On 07/09/2012 13:49, "Jan Beulich" <JBeulich@suse.com> wrote:
> 
>> The first resume from S3 was corrupting internal data structures (in
>> that pci_restore_msi_state() updated the globally stored MSI message
>> from traditional to interrupt remapped format, which would then be
>> translated a second time during the second resume, breaking interrupt
>> delivery).
> 
> Doesn't that mean write_msi_msg() has a bit of a hideous interface?

It does, and we may want to clean that up. But at least this won't
go unnoticed in debug builds anymore with the added assertion,
should anyone re-add a bad use 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 Sep 07 15:50:54 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Sep 2012 15:50:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TA0pS-0004zg-V3; Fri, 07 Sep 2012 15:50:46 +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 1TA0pR-0004yR-Ji
	for xen-devel@lists.xen.org; Fri, 07 Sep 2012 15:50:45 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1347033037!3103660!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM4ODU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10492 invoked from network); 7 Sep 2012 15:50:38 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-15.tower-27.messagelabs.com with SMTP;
	7 Sep 2012 15:50:38 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 07 Sep 2012 16:50:37 +0100
Message-Id: <504A34250200007800099E8F@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 07 Sep 2012 16:51:33 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Keir Fraser" <keir.xen@gmail.com>, "xen-devel" <xen-devel@lists.xen.org>
References: <504A08930200007800099C9A@nat28.tlf.novell.com>
	<CC6FCBC9.3E0BB%keir.xen@gmail.com>
In-Reply-To: <CC6FCBC9.3E0BB%keir.xen@gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xiantao.zhang@intel.com
Subject: Re: [Xen-devel] [PATCH] VT-d: split .ack and .disable DMA-MSI actors
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.09.12 at 17:05, Keir Fraser <keir.xen@gmail.com> wrote:
> On 07/09/2012 13:45, "Jan Beulich" <JBeulich@suse.com> wrote:
> 
>> Calling irq_complete_move() from .disable is wrong, breaking S3 resume.
>> 
>> Comparing with all other .ack actors, it was also missing a call to
>> move_{native,masked}_irq(). As the actor is masking its interrupt
>> anyway (albeit it's not immediately obvious why), the latter is the
>> better choice.
>> 
>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> 
> As far as I understand it
> Acked-by: Keir Fraser <keir@xen.org>
> 
> I guess you are looking for an Intel ack as well.

Yes, that's why I Cc-ed Xiantao.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 07 15:50:54 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Sep 2012 15:50:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TA0pS-0004zg-V3; Fri, 07 Sep 2012 15:50:46 +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 1TA0pR-0004yR-Ji
	for xen-devel@lists.xen.org; Fri, 07 Sep 2012 15:50:45 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1347033037!3103660!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM4ODU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10492 invoked from network); 7 Sep 2012 15:50:38 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-15.tower-27.messagelabs.com with SMTP;
	7 Sep 2012 15:50:38 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 07 Sep 2012 16:50:37 +0100
Message-Id: <504A34250200007800099E8F@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 07 Sep 2012 16:51:33 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Keir Fraser" <keir.xen@gmail.com>, "xen-devel" <xen-devel@lists.xen.org>
References: <504A08930200007800099C9A@nat28.tlf.novell.com>
	<CC6FCBC9.3E0BB%keir.xen@gmail.com>
In-Reply-To: <CC6FCBC9.3E0BB%keir.xen@gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xiantao.zhang@intel.com
Subject: Re: [Xen-devel] [PATCH] VT-d: split .ack and .disable DMA-MSI actors
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.09.12 at 17:05, Keir Fraser <keir.xen@gmail.com> wrote:
> On 07/09/2012 13:45, "Jan Beulich" <JBeulich@suse.com> wrote:
> 
>> Calling irq_complete_move() from .disable is wrong, breaking S3 resume.
>> 
>> Comparing with all other .ack actors, it was also missing a call to
>> move_{native,masked}_irq(). As the actor is masking its interrupt
>> anyway (albeit it's not immediately obvious why), the latter is the
>> better choice.
>> 
>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> 
> As far as I understand it
> Acked-by: Keir Fraser <keir@xen.org>
> 
> I guess you are looking for an Intel ack as well.

Yes, that's why I Cc-ed Xiantao.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 07 15:51:35 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Sep 2012 15:51:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TA0qA-00059G-BP; Fri, 07 Sep 2012 15:51: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 1TA0q9-00058u-B2
	for xen-devel@lists.xen.org; Fri, 07 Sep 2012 15:51:29 +0000
Received: from [85.158.143.35:52003] by server-2.bemta-4.messagelabs.com id
	26/1A-21239-0081A405; Fri, 07 Sep 2012 15:51:28 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1347033076!14701352!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTIyMTE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16429 invoked from network); 7 Sep 2012 15:51:17 -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;
	7 Sep 2012 15:51:17 -0000
X-IronPort-AV: E=Sophos;i="4.80,387,1344211200"; d="scan'208";a="14414310"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Sep 2012 15:51:16 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Fri, 7 Sep 2012
	16:51:16 +0100
Message-ID: <1347033075.30018.128.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Fri, 7 Sep 2012 16:51:15 +0100
In-Reply-To: <504A33930200007800099E5A@nat28.tlf.novell.com>
References: <1347027296.30018.108.camel@zakaz.uk.xensource.com>
	<504A2D710200007800099E11@nat28.tlf.novell.com>
	<1347032363.30018.120.camel@zakaz.uk.xensource.com>
	<504A33930200007800099E5A@nat28.tlf.novell.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.2 new features and status -- please help me
	make a list
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-09-07 at 16:49 +0100, Jan Beulich wrote:
> >>> On 07.09.12 at 17:39, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> > On Fri, 2012-09-07 at 16:22 +0100, Jan Beulich wrote:
> >> >>> On 07.09.12 at 16:14, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> >> > vMSI: ? Emulated (or real?) MSIs for guests?
> >> >         State? New in 4.2?
> >> 
> >> Not sure what you're referring to here. There certainly was a
> >> xen/arch/x86/hvm/vmsi.c in 4.1 already.
> > 
> > OK, thanks. 4.0 too by the looks of it.
> > 
> > What exactly is this? Is it about injection of MSIs from real
> > (passthrough) hardware devices to guests (only HVM ones?) or is about
> > MSIs generated by emulated devices (or both)?
> 
> I don't think emulated devices genera MSIs, so to me this is
> just for passthrough. But I may be wrong.

It sounds plausible to me ;-)

> 
> >> > vPMU: Power Management?
> >> >         New in 4.2?
> >> 
> >> Enhanced iirc.
> > 
> > But already a full feature in 4.1 and 4.0?
> > 
> > This lets HVM guests thing they have power management hardware, and
> > tickling it does what?
> 
> Oh, I didn't pay close enough attention - PM stands for
> Performance Monitor here. Iirc e.g. Fujitsu have been using
> this even in 4.0 already.

perf monitoring makes more sense as a guest accessible thing.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 07 15:51:35 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Sep 2012 15:51:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TA0qA-00059G-BP; Fri, 07 Sep 2012 15:51: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 1TA0q9-00058u-B2
	for xen-devel@lists.xen.org; Fri, 07 Sep 2012 15:51:29 +0000
Received: from [85.158.143.35:52003] by server-2.bemta-4.messagelabs.com id
	26/1A-21239-0081A405; Fri, 07 Sep 2012 15:51:28 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1347033076!14701352!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTIyMTE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16429 invoked from network); 7 Sep 2012 15:51:17 -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;
	7 Sep 2012 15:51:17 -0000
X-IronPort-AV: E=Sophos;i="4.80,387,1344211200"; d="scan'208";a="14414310"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Sep 2012 15:51:16 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Fri, 7 Sep 2012
	16:51:16 +0100
Message-ID: <1347033075.30018.128.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Fri, 7 Sep 2012 16:51:15 +0100
In-Reply-To: <504A33930200007800099E5A@nat28.tlf.novell.com>
References: <1347027296.30018.108.camel@zakaz.uk.xensource.com>
	<504A2D710200007800099E11@nat28.tlf.novell.com>
	<1347032363.30018.120.camel@zakaz.uk.xensource.com>
	<504A33930200007800099E5A@nat28.tlf.novell.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.2 new features and status -- please help me
	make a list
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-09-07 at 16:49 +0100, Jan Beulich wrote:
> >>> On 07.09.12 at 17:39, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> > On Fri, 2012-09-07 at 16:22 +0100, Jan Beulich wrote:
> >> >>> On 07.09.12 at 16:14, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> >> > vMSI: ? Emulated (or real?) MSIs for guests?
> >> >         State? New in 4.2?
> >> 
> >> Not sure what you're referring to here. There certainly was a
> >> xen/arch/x86/hvm/vmsi.c in 4.1 already.
> > 
> > OK, thanks. 4.0 too by the looks of it.
> > 
> > What exactly is this? Is it about injection of MSIs from real
> > (passthrough) hardware devices to guests (only HVM ones?) or is about
> > MSIs generated by emulated devices (or both)?
> 
> I don't think emulated devices genera MSIs, so to me this is
> just for passthrough. But I may be wrong.

It sounds plausible to me ;-)

> 
> >> > vPMU: Power Management?
> >> >         New in 4.2?
> >> 
> >> Enhanced iirc.
> > 
> > But already a full feature in 4.1 and 4.0?
> > 
> > This lets HVM guests thing they have power management hardware, and
> > tickling it does what?
> 
> Oh, I didn't pay close enough attention - PM stands for
> Performance Monitor here. Iirc e.g. Fujitsu have been using
> this even in 4.0 already.

perf monitoring makes more sense as a guest accessible thing.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 07 15:52:24 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Sep 2012 15:52:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TA0qq-0005Hg-QI; Fri, 07 Sep 2012 15:52:12 +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 1TA0qp-0005GV-54
	for xen-devel@lists.xen.org; Fri, 07 Sep 2012 15:52:11 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1347033124!3066762!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM4ODU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25716 invoked from network); 7 Sep 2012 15:52:04 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-14.tower-27.messagelabs.com with SMTP;
	7 Sep 2012 15:52:04 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 07 Sep 2012 16:52:03 +0100
Message-Id: <504A347B0200007800099E92@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 07 Sep 2012 16:52:59 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Stefan Bader" <stefan.bader@canonical.com>
References: <1347018043-21252-1-git-send-email-stefan.bader@canonical.com>
	<504A05B00200007800099C7B@nat28.tlf.novell.com>
	<5049F4E9.9050306@canonical.com>
	<504A1A950200007800099D4C@nat28.tlf.novell.com>
	<20120907142251.GA20096@linuxtx.org>
	<504A32800200007800099E40@nat28.tlf.novell.com>
	<504A172B.5020005@canonical.com>
In-Reply-To: <504A172B.5020005@canonical.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"Justin M. Forbes" <jmforbes@linuxtx.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Matt Wilson <msw@amazon.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH/RFC] Fix xsave bug on older Xen hypervisors
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.09.12 at 17:47, Stefan Bader <stefan.bader@canonical.com> wrote:
> On 07.09.2012 17:44, Jan Beulich wrote:
>> All of this still doesn't provide evidence that a plain upstream
>> kernel is actually having any problems in the first place. Further,
>> if you say EC2 has a crippled hypervisor patch - is that patch
>> available for looking at somewhere?
> 
> It was not a hypervisor patch. It was one for the guest. This was the hack:

So then why do you want to patch the upstream kernel? It won't
make that hack go away, nor will it help any existing kernels.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 07 15:52:24 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Sep 2012 15:52:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TA0qq-0005Hg-QI; Fri, 07 Sep 2012 15:52:12 +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 1TA0qp-0005GV-54
	for xen-devel@lists.xen.org; Fri, 07 Sep 2012 15:52:11 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1347033124!3066762!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM4ODU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25716 invoked from network); 7 Sep 2012 15:52:04 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-14.tower-27.messagelabs.com with SMTP;
	7 Sep 2012 15:52:04 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 07 Sep 2012 16:52:03 +0100
Message-Id: <504A347B0200007800099E92@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 07 Sep 2012 16:52:59 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Stefan Bader" <stefan.bader@canonical.com>
References: <1347018043-21252-1-git-send-email-stefan.bader@canonical.com>
	<504A05B00200007800099C7B@nat28.tlf.novell.com>
	<5049F4E9.9050306@canonical.com>
	<504A1A950200007800099D4C@nat28.tlf.novell.com>
	<20120907142251.GA20096@linuxtx.org>
	<504A32800200007800099E40@nat28.tlf.novell.com>
	<504A172B.5020005@canonical.com>
In-Reply-To: <504A172B.5020005@canonical.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"Justin M. Forbes" <jmforbes@linuxtx.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Matt Wilson <msw@amazon.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH/RFC] Fix xsave bug on older Xen hypervisors
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.09.12 at 17:47, Stefan Bader <stefan.bader@canonical.com> wrote:
> On 07.09.2012 17:44, Jan Beulich wrote:
>> All of this still doesn't provide evidence that a plain upstream
>> kernel is actually having any problems in the first place. Further,
>> if you say EC2 has a crippled hypervisor patch - is that patch
>> available for looking at somewhere?
> 
> It was not a hypervisor patch. It was one for the guest. This was the hack:

So then why do you want to patch the upstream kernel? It won't
make that hack go away, nor will it help any existing kernels.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 07 15:55:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Sep 2012 15: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 1TA0ta-0005eY-NL; Fri, 07 Sep 2012 15:55:02 +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 1TA0tY-0005e2-0Z
	for xen-devel@lists.xen.org; Fri, 07 Sep 2012 15:55:00 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1347033290!10080963!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTIyMTE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24632 invoked from network); 7 Sep 2012 15:54:50 -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;
	7 Sep 2012 15:54:50 -0000
X-IronPort-AV: E=Sophos;i="4.80,387,1344211200"; d="scan'208";a="14414455"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Sep 2012 15:54: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.279.1; Fri, 7 Sep 2012
	16:54:50 +0100
Message-ID: <1347033288.30018.130.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefan Bader <stefan.bader@canonical.com>
Date: Fri, 7 Sep 2012 16:54:48 +0100
In-Reply-To: <504A172B.5020005@canonical.com>
References: <1347018043-21252-1-git-send-email-stefan.bader@canonical.com>
	<504A05B00200007800099C7B@nat28.tlf.novell.com>
	<5049F4E9.9050306@canonical.com>
	<504A1A950200007800099D4C@nat28.tlf.novell.com>
	<20120907142251.GA20096@linuxtx.org>
	<504A32800200007800099E40@nat28.tlf.novell.com>
	<504A172B.5020005@canonical.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Jan Beulich <JBeulich@suse.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"Justin M. Forbes" <jmforbes@linuxtx.org>, Linux
	Kernel Mailing List <linux-kernel@vger.kernel.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Matt Wilson <msw@amazon.com>
Subject: Re: [Xen-devel] [PATCH/RFC] Fix xsave bug on older Xen hypervisors
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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-09-07 at 16:47 +0100, Stefan Bader wrote:
> On 07.09.2012 17:44, Jan Beulich wrote:
> >>>> On 07.09.12 at 16:22, "Justin M. Forbes" <jmforbes@linuxtx.org> wrote:
> >> On Fri, Sep 07, 2012 at 03:02:29PM +0100, Jan Beulich wrote:
> >>>>>> On 07.09.12 at 15:21, Stefan Bader <stefan.bader@canonical.com> wrote:
> >>>> On 07.09.2012 14:33, Jan Beulich wrote:
> >>>>>>>> On 07.09.12 at 13:40, Stefan Bader <stefan.bader@canonical.com> wrote:
> >>>>>> When writing unsupported flags into CR4 (for some time the
> >>>>>> xen_write_cr4 function would refuse to do anything at all)
> >>>>>> older Xen hypervisors (and patch can potentially be improved
> >>>>>> by finding out what older means in version numbers) would
> >>>>>> crash the guest.
> >>>>>>
> >>>>>> Since Amazon EC2 would at least in the past be affected by that,
> >>>>>> Fedora and Ubuntu were carrying a hack that would filter out
> >>>>>> X86_CR4_OSXSAVE before writing to CR4. This would affect any
> >>>>>> PV guest, even those running on a newer HV.
> >>>>>>
> >>>>>> And this recently caused trouble because some user-space was
> >>>>>> only partially checking (or maybe only looking at the cpuid
> >>>>>> bits) and then trying to use xsave even though the OS support
> >>>>>> was not set.
> >>>>>>
> >>>>>> So I came up with a patch that would
> >>>>>> - limit the work-around to certain Xen versions
> >>>>>> - prevent the write to CR4 by unsetting xsave and osxsave in
> >>>>>>   the cpuid bits
> >>>>>>
> >>>>>> Doing things that way may actually allow this to be acceptable
> >>>>>> upstream, so I am sending it around, now.
> >>>>>> It probably could be improved when knowing the exact version
> >>>>>> to test for but otherwise should allow to work around the guest
> >>>>>> crash while not preventing xsave on Xen 4.x and newer hosts.
> >>>>>
> >>>>> Before considering a hack like this, I'd really like to see evidence
> >>>>> of the described behavior with an upstream kernel (i.e. not one
> >>>>> with that known broken hack patched in, which has never been
> >>>>> upstream afaict).
> >>>>
> >>>> This is the reason I wrote that Fedora and Ubuntu were carrying it. It 
> >> never 
> >>>> has
> >>>> been send upstream (the other version) because it would filter the CR4 
> >> write 
> >>>> for
> >>>> any PV guest regardless of host version.
> >>>
> >>> But iirc that bad patch is a Linux side one (i.e. you're trying to fix
> >>> something upstream that isn't upstream)?
> >>>
> >> Right, so the patch that this improves upon, and that Fedora and Ubuntu are
> >> currently carrying is not upstream because:
> >>
> >> a) It's crap, it cripples upstream xen users, but doesn't impact RHEL xen
> >> users because xsave was never supported there.
> >>
> >> b) The hypervisor was patched to make it unnecessary quite some time ago,
> >> and we hoped EC2 would eventually pick up that correct patch and we could
> >> drop the crap kernel patch.
> >>
> >> Unfortunately this has not happened. We are at a point where EC2 really is
> >> a quirk that has to be worked around. Distros do not want to maintain
> >> a separate EC2 build of the kernel, so the easiest way is to cripple
> >> current upstream xen users.  This quirk is unfortunately the best possible
> >> solution.  Having it upstream also makes it possible for any user to build
> >> an upstream kernel that will run on EC2 without having to dig a random
> >> patch out of a vendor kernel.
> > 
> > All of this still doesn't provide evidence that a plain upstream
> > kernel is actually having any problems in the first place. Further,
> > if you say EC2 has a crippled hypervisor patch - is that patch
> > available for looking at somewhere?
> 
> It was not a hypervisor patch. It was one for the guest. This was the hack:
> 
> From 57bb316c938a9ad65a8093f0584fd22eda88521f Mon Sep 17 00:00:00 2001
> From: John Johansen <john.johansen@canonical.com>
> Date: Tue, 27 Jul 2010 06:06:07 -0700
> Subject: [PATCH] UBUNTU: SAUCE: fix pv-ops for legacy Xen
> 
> Import fix_xen_guest_on_old_EC2.patch from fedora 14
> 
> Legacy hypervisors (RHEL 5.0 and RHEL 5.1) do not handle guest writes to
> cr4 gracefully. If a guest attempts to write a bit of cr4 that is
> unsupported, then the HV is so offended it crashes the domain.

For completeness, was the hypervisor fix this one:

        changeset:   19288:9ed53e602119
        user:        Keir Fraser <keir.fraser@citrix.com>
        date:        Mon Mar 09 08:54:19 2009 +0000
        files:       [...]
        description:
        x86: Mask X86_FEATURE_XSAVE in cpuid leaf 1, ecx, as we don't allow
        guests to use it (by setting cr4.OSXSAVE).
        
        This prevents crashes in pvops kernels, as new versions of Linux
        try to use this feature.
        
        Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
        Signed-off-by: Keir Fraser <keir.fraser@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 Sep 07 15:55:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Sep 2012 15: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 1TA0ta-0005eY-NL; Fri, 07 Sep 2012 15:55:02 +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 1TA0tY-0005e2-0Z
	for xen-devel@lists.xen.org; Fri, 07 Sep 2012 15:55:00 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1347033290!10080963!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTIyMTE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24632 invoked from network); 7 Sep 2012 15:54:50 -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;
	7 Sep 2012 15:54:50 -0000
X-IronPort-AV: E=Sophos;i="4.80,387,1344211200"; d="scan'208";a="14414455"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Sep 2012 15:54: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.279.1; Fri, 7 Sep 2012
	16:54:50 +0100
Message-ID: <1347033288.30018.130.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefan Bader <stefan.bader@canonical.com>
Date: Fri, 7 Sep 2012 16:54:48 +0100
In-Reply-To: <504A172B.5020005@canonical.com>
References: <1347018043-21252-1-git-send-email-stefan.bader@canonical.com>
	<504A05B00200007800099C7B@nat28.tlf.novell.com>
	<5049F4E9.9050306@canonical.com>
	<504A1A950200007800099D4C@nat28.tlf.novell.com>
	<20120907142251.GA20096@linuxtx.org>
	<504A32800200007800099E40@nat28.tlf.novell.com>
	<504A172B.5020005@canonical.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Jan Beulich <JBeulich@suse.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"Justin M. Forbes" <jmforbes@linuxtx.org>, Linux
	Kernel Mailing List <linux-kernel@vger.kernel.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Matt Wilson <msw@amazon.com>
Subject: Re: [Xen-devel] [PATCH/RFC] Fix xsave bug on older Xen hypervisors
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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-09-07 at 16:47 +0100, Stefan Bader wrote:
> On 07.09.2012 17:44, Jan Beulich wrote:
> >>>> On 07.09.12 at 16:22, "Justin M. Forbes" <jmforbes@linuxtx.org> wrote:
> >> On Fri, Sep 07, 2012 at 03:02:29PM +0100, Jan Beulich wrote:
> >>>>>> On 07.09.12 at 15:21, Stefan Bader <stefan.bader@canonical.com> wrote:
> >>>> On 07.09.2012 14:33, Jan Beulich wrote:
> >>>>>>>> On 07.09.12 at 13:40, Stefan Bader <stefan.bader@canonical.com> wrote:
> >>>>>> When writing unsupported flags into CR4 (for some time the
> >>>>>> xen_write_cr4 function would refuse to do anything at all)
> >>>>>> older Xen hypervisors (and patch can potentially be improved
> >>>>>> by finding out what older means in version numbers) would
> >>>>>> crash the guest.
> >>>>>>
> >>>>>> Since Amazon EC2 would at least in the past be affected by that,
> >>>>>> Fedora and Ubuntu were carrying a hack that would filter out
> >>>>>> X86_CR4_OSXSAVE before writing to CR4. This would affect any
> >>>>>> PV guest, even those running on a newer HV.
> >>>>>>
> >>>>>> And this recently caused trouble because some user-space was
> >>>>>> only partially checking (or maybe only looking at the cpuid
> >>>>>> bits) and then trying to use xsave even though the OS support
> >>>>>> was not set.
> >>>>>>
> >>>>>> So I came up with a patch that would
> >>>>>> - limit the work-around to certain Xen versions
> >>>>>> - prevent the write to CR4 by unsetting xsave and osxsave in
> >>>>>>   the cpuid bits
> >>>>>>
> >>>>>> Doing things that way may actually allow this to be acceptable
> >>>>>> upstream, so I am sending it around, now.
> >>>>>> It probably could be improved when knowing the exact version
> >>>>>> to test for but otherwise should allow to work around the guest
> >>>>>> crash while not preventing xsave on Xen 4.x and newer hosts.
> >>>>>
> >>>>> Before considering a hack like this, I'd really like to see evidence
> >>>>> of the described behavior with an upstream kernel (i.e. not one
> >>>>> with that known broken hack patched in, which has never been
> >>>>> upstream afaict).
> >>>>
> >>>> This is the reason I wrote that Fedora and Ubuntu were carrying it. It 
> >> never 
> >>>> has
> >>>> been send upstream (the other version) because it would filter the CR4 
> >> write 
> >>>> for
> >>>> any PV guest regardless of host version.
> >>>
> >>> But iirc that bad patch is a Linux side one (i.e. you're trying to fix
> >>> something upstream that isn't upstream)?
> >>>
> >> Right, so the patch that this improves upon, and that Fedora and Ubuntu are
> >> currently carrying is not upstream because:
> >>
> >> a) It's crap, it cripples upstream xen users, but doesn't impact RHEL xen
> >> users because xsave was never supported there.
> >>
> >> b) The hypervisor was patched to make it unnecessary quite some time ago,
> >> and we hoped EC2 would eventually pick up that correct patch and we could
> >> drop the crap kernel patch.
> >>
> >> Unfortunately this has not happened. We are at a point where EC2 really is
> >> a quirk that has to be worked around. Distros do not want to maintain
> >> a separate EC2 build of the kernel, so the easiest way is to cripple
> >> current upstream xen users.  This quirk is unfortunately the best possible
> >> solution.  Having it upstream also makes it possible for any user to build
> >> an upstream kernel that will run on EC2 without having to dig a random
> >> patch out of a vendor kernel.
> > 
> > All of this still doesn't provide evidence that a plain upstream
> > kernel is actually having any problems in the first place. Further,
> > if you say EC2 has a crippled hypervisor patch - is that patch
> > available for looking at somewhere?
> 
> It was not a hypervisor patch. It was one for the guest. This was the hack:
> 
> From 57bb316c938a9ad65a8093f0584fd22eda88521f Mon Sep 17 00:00:00 2001
> From: John Johansen <john.johansen@canonical.com>
> Date: Tue, 27 Jul 2010 06:06:07 -0700
> Subject: [PATCH] UBUNTU: SAUCE: fix pv-ops for legacy Xen
> 
> Import fix_xen_guest_on_old_EC2.patch from fedora 14
> 
> Legacy hypervisors (RHEL 5.0 and RHEL 5.1) do not handle guest writes to
> cr4 gracefully. If a guest attempts to write a bit of cr4 that is
> unsupported, then the HV is so offended it crashes the domain.

For completeness, was the hypervisor fix this one:

        changeset:   19288:9ed53e602119
        user:        Keir Fraser <keir.fraser@citrix.com>
        date:        Mon Mar 09 08:54:19 2009 +0000
        files:       [...]
        description:
        x86: Mask X86_FEATURE_XSAVE in cpuid leaf 1, ecx, as we don't allow
        guests to use it (by setting cr4.OSXSAVE).
        
        This prevents crashes in pvops kernels, as new versions of Linux
        try to use this feature.
        
        Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
        Signed-off-by: Keir Fraser <keir.fraser@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 Sep 07 15:56:27 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Sep 2012 15:56: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 1TA0ul-0005kp-5R; Fri, 07 Sep 2012 15:56:15 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1TA0uk-0005kj-Ns
	for xen-devel@lists.xen.org; Fri, 07 Sep 2012 15:56:14 +0000
Received: from [85.158.143.35:6787] by server-1.bemta-4.messagelabs.com id
	0F/1C-12504-D191A405; Fri, 07 Sep 2012 15:56:13 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1347033369!11740940!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM4ODU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24500 invoked from network); 7 Sep 2012 15:56:12 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-7.tower-21.messagelabs.com with SMTP;
	7 Sep 2012 15:56:12 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 07 Sep 2012 16:56:08 +0100
Message-Id: <504A356F0200007800099EC9@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 07 Sep 2012 16:57:03 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Campbell" <Ian.Campbell@citrix.com>
References: <1347027296.30018.108.camel@zakaz.uk.xensource.com>
	<504A309A0200007800099E2B@nat28.tlf.novell.com>
	<1347032589.30018.122.camel@zakaz.uk.xensource.com>
In-Reply-To: <1347032589.30018.122.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 new features and status -- please help me
 make a list
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 07.09.12 at 17:43, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> On Fri, 2012-09-07 at 16:36 +0100, Jan Beulich wrote:
>> Not sure whether boot time CPU microcode patching is worth
>> mentioning. Certainly this is nothing user visible.
> 
> This is the thing which can load microcode without needing to wait for
> the dom0 kernel to pass it up a blob?

Yes.

> I'm not sure about the feature lists (I suppose it is useful to mention)
> but extracting the commit log of 24315:3e5683b6b37f into some doc
> somewhere might be useful for users?
> 
> (unless you did already and I failed to find it, of course)

No, I didn't. I see that docs/misc/xen-command-line.markdown
only mentions the option, without description. I'll see to get
that changed 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 Fri Sep 07 15:56:27 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Sep 2012 15:56: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 1TA0ul-0005kp-5R; Fri, 07 Sep 2012 15:56:15 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1TA0uk-0005kj-Ns
	for xen-devel@lists.xen.org; Fri, 07 Sep 2012 15:56:14 +0000
Received: from [85.158.143.35:6787] by server-1.bemta-4.messagelabs.com id
	0F/1C-12504-D191A405; Fri, 07 Sep 2012 15:56:13 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1347033369!11740940!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM4ODU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24500 invoked from network); 7 Sep 2012 15:56:12 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-7.tower-21.messagelabs.com with SMTP;
	7 Sep 2012 15:56:12 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 07 Sep 2012 16:56:08 +0100
Message-Id: <504A356F0200007800099EC9@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 07 Sep 2012 16:57:03 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Campbell" <Ian.Campbell@citrix.com>
References: <1347027296.30018.108.camel@zakaz.uk.xensource.com>
	<504A309A0200007800099E2B@nat28.tlf.novell.com>
	<1347032589.30018.122.camel@zakaz.uk.xensource.com>
In-Reply-To: <1347032589.30018.122.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 new features and status -- please help me
 make a list
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 07.09.12 at 17:43, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> On Fri, 2012-09-07 at 16:36 +0100, Jan Beulich wrote:
>> Not sure whether boot time CPU microcode patching is worth
>> mentioning. Certainly this is nothing user visible.
> 
> This is the thing which can load microcode without needing to wait for
> the dom0 kernel to pass it up a blob?

Yes.

> I'm not sure about the feature lists (I suppose it is useful to mention)
> but extracting the commit log of 24315:3e5683b6b37f into some doc
> somewhere might be useful for users?
> 
> (unless you did already and I failed to find it, of course)

No, I didn't. I see that docs/misc/xen-command-line.markdown
only mentions the option, without description. I'll see to get
that changed 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 Fri Sep 07 15:58:10 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Sep 2012 15:58:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TA0wT-0005tp-MN; Fri, 07 Sep 2012 15:58:01 +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 1TA0wS-0005tS-EN
	for xen-devel@lists.xen.org; Fri, 07 Sep 2012 15:58:00 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1347033474!9512733!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTIyMTE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6196 invoked from network); 7 Sep 2012 15:57:54 -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 Sep 2012 15:57:54 -0000
X-IronPort-AV: E=Sophos;i="4.80,387,1344211200"; d="scan'208";a="14414536"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Sep 2012 15:57: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.279.1; Fri, 7 Sep 2012
	16:57:54 +0100
Message-ID: <1347033473.30018.131.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Fri, 7 Sep 2012 16:57:53 +0100
In-Reply-To: <504A356F0200007800099EC9@nat28.tlf.novell.com>
References: <1347027296.30018.108.camel@zakaz.uk.xensource.com>
	<504A309A0200007800099E2B@nat28.tlf.novell.com>
	<1347032589.30018.122.camel@zakaz.uk.xensource.com>
	<504A356F0200007800099EC9@nat28.tlf.novell.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.2 new features and status -- please help me
	make a list
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-09-07 at 16:57 +0100, Jan Beulich wrote:
> >>> On 07.09.12 at 17:43, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> > On Fri, 2012-09-07 at 16:36 +0100, Jan Beulich wrote:
> >> Not sure whether boot time CPU microcode patching is worth
> >> mentioning. Certainly this is nothing user visible.
> > 
> > This is the thing which can load microcode without needing to wait for
> > the dom0 kernel to pass it up a blob?
> 
> Yes.
> 
> > I'm not sure about the feature lists (I suppose it is useful to mention)
> > but extracting the commit log of 24315:3e5683b6b37f into some doc
> > somewhere might be useful for users?
> > 
> > (unless you did already and I failed to find it, of course)
> 
> No, I didn't. I see that docs/misc/xen-command-line.markdown
> only mentions the option, without description. I'll see to get
> that changed early next week.

Smashing, 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 Sep 07 15:58:10 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Sep 2012 15:58:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TA0wT-0005tp-MN; Fri, 07 Sep 2012 15:58:01 +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 1TA0wS-0005tS-EN
	for xen-devel@lists.xen.org; Fri, 07 Sep 2012 15:58:00 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1347033474!9512733!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTIyMTE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6196 invoked from network); 7 Sep 2012 15:57:54 -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 Sep 2012 15:57:54 -0000
X-IronPort-AV: E=Sophos;i="4.80,387,1344211200"; d="scan'208";a="14414536"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Sep 2012 15:57: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.279.1; Fri, 7 Sep 2012
	16:57:54 +0100
Message-ID: <1347033473.30018.131.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Fri, 7 Sep 2012 16:57:53 +0100
In-Reply-To: <504A356F0200007800099EC9@nat28.tlf.novell.com>
References: <1347027296.30018.108.camel@zakaz.uk.xensource.com>
	<504A309A0200007800099E2B@nat28.tlf.novell.com>
	<1347032589.30018.122.camel@zakaz.uk.xensource.com>
	<504A356F0200007800099EC9@nat28.tlf.novell.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.2 new features and status -- please help me
	make a list
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-09-07 at 16:57 +0100, Jan Beulich wrote:
> >>> On 07.09.12 at 17:43, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> > On Fri, 2012-09-07 at 16:36 +0100, Jan Beulich wrote:
> >> Not sure whether boot time CPU microcode patching is worth
> >> mentioning. Certainly this is nothing user visible.
> > 
> > This is the thing which can load microcode without needing to wait for
> > the dom0 kernel to pass it up a blob?
> 
> Yes.
> 
> > I'm not sure about the feature lists (I suppose it is useful to mention)
> > but extracting the commit log of 24315:3e5683b6b37f into some doc
> > somewhere might be useful for users?
> > 
> > (unless you did already and I failed to find it, of course)
> 
> No, I didn't. I see that docs/misc/xen-command-line.markdown
> only mentions the option, without description. I'll see to get
> that changed early next week.

Smashing, 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 Sep 07 15:59:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Sep 2012 15:59:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TA0xi-00062O-FT; Fri, 07 Sep 2012 15:59:18 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <karrelsj@gmail.com>) id 1TA0xg-00061t-Pm
	for xen-devel@lists.xen.org; Fri, 07 Sep 2012 15:59:16 +0000
X-Env-Sender: karrelsj@gmail.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1347033550!3067609!1
X-Originating-IP: [209.85.212.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10837 invoked from network); 7 Sep 2012 15:59:10 -0000
Received: from mail-wi0-f173.google.com (HELO mail-wi0-f173.google.com)
	(209.85.212.173)
	by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Sep 2012 15:59:10 -0000
Received: by wibhm6 with SMTP id hm6so6483059wib.14
	for <xen-devel@lists.xen.org>; Fri, 07 Sep 2012 08:59:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to
	:cc:content-type;
	bh=3HFpXpDrVK5FaZE5QvckQW0oTjAePGklQKs/No+5a7c=;
	b=ujJRr9fYKLCcyJwbKJguHzVqPNJwjQU8BtHurrshgkys+KRS1MdvTTsWfF98RN+hrm
	7bwIfyFOT40dHg9d6rUm/0CZSQ/fEnmIV98mSuLd6ep7fdhdxA5/086SgevAv34NlAlq
	A3aLTpiibwoYYMUAOmaFhFwLplsYQ/j8GmZ8lI2Ibgh93nu9ORM+DsO/dQ7VZDOwkzpz
	NQ2AGuS1Ln0WXl7sLQ8FL4bSMle5JXFphS4KfskJRQQKTj0iJ2FK8SoQGKcSKLyiX/0/
	NSqmMx1GqtlsfrllIIv9H9rCCGQs3WGXMLGP1Nt6CJKVgI1HYOrhoeda1ueO0l77C4sP
	QgzQ==
Received: by 10.216.30.83 with SMTP id j61mr3411634wea.168.1347033550672; Fri,
	07 Sep 2012 08:59:10 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.216.255.79 with HTTP; Fri, 7 Sep 2012 08:58:50 -0700 (PDT)
In-Reply-To: <20120907085036.GA71093@ocelot.phlegethon.org>
References: <CAFw--Dd0k7L+T_UJc0yHAkUGrY_-GDHaQjK3OM-1UdOp=J-wAQ@mail.gmail.com>
	<20120907085036.GA71093@ocelot.phlegethon.org>
From: Jeffrey Karrels <karrelsj@gmail.com>
Date: Fri, 7 Sep 2012 08:58:50 -0700
Message-ID: <CAFw--DdYkAo79TeZKDFZ5ZdaN4KiLmW2qcceY+cTxuLMdE3QGA@mail.gmail.com>
To: Tim Deegan <tim@xen.org>
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Clang/LLVM version requirements
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> Looks like the clang build has bitrotted a little - sorry.  It's too
> late to fix this for 4.2 now but we can sort it out after we branch
> (i.e. next week) and backport any build fixes for 4.2.1.
>

No worries. I can try and help out on this. Do you think it is
worthwhile to start a Wiki page for this type of work. I was working
with cppcheck, sparse, clang on/for xen...

Jeff

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 07 15:59:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Sep 2012 15:59:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TA0xi-00062O-FT; Fri, 07 Sep 2012 15:59:18 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <karrelsj@gmail.com>) id 1TA0xg-00061t-Pm
	for xen-devel@lists.xen.org; Fri, 07 Sep 2012 15:59:16 +0000
X-Env-Sender: karrelsj@gmail.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1347033550!3067609!1
X-Originating-IP: [209.85.212.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10837 invoked from network); 7 Sep 2012 15:59:10 -0000
Received: from mail-wi0-f173.google.com (HELO mail-wi0-f173.google.com)
	(209.85.212.173)
	by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Sep 2012 15:59:10 -0000
Received: by wibhm6 with SMTP id hm6so6483059wib.14
	for <xen-devel@lists.xen.org>; Fri, 07 Sep 2012 08:59:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to
	:cc:content-type;
	bh=3HFpXpDrVK5FaZE5QvckQW0oTjAePGklQKs/No+5a7c=;
	b=ujJRr9fYKLCcyJwbKJguHzVqPNJwjQU8BtHurrshgkys+KRS1MdvTTsWfF98RN+hrm
	7bwIfyFOT40dHg9d6rUm/0CZSQ/fEnmIV98mSuLd6ep7fdhdxA5/086SgevAv34NlAlq
	A3aLTpiibwoYYMUAOmaFhFwLplsYQ/j8GmZ8lI2Ibgh93nu9ORM+DsO/dQ7VZDOwkzpz
	NQ2AGuS1Ln0WXl7sLQ8FL4bSMle5JXFphS4KfskJRQQKTj0iJ2FK8SoQGKcSKLyiX/0/
	NSqmMx1GqtlsfrllIIv9H9rCCGQs3WGXMLGP1Nt6CJKVgI1HYOrhoeda1ueO0l77C4sP
	QgzQ==
Received: by 10.216.30.83 with SMTP id j61mr3411634wea.168.1347033550672; Fri,
	07 Sep 2012 08:59:10 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.216.255.79 with HTTP; Fri, 7 Sep 2012 08:58:50 -0700 (PDT)
In-Reply-To: <20120907085036.GA71093@ocelot.phlegethon.org>
References: <CAFw--Dd0k7L+T_UJc0yHAkUGrY_-GDHaQjK3OM-1UdOp=J-wAQ@mail.gmail.com>
	<20120907085036.GA71093@ocelot.phlegethon.org>
From: Jeffrey Karrels <karrelsj@gmail.com>
Date: Fri, 7 Sep 2012 08:58:50 -0700
Message-ID: <CAFw--DdYkAo79TeZKDFZ5ZdaN4KiLmW2qcceY+cTxuLMdE3QGA@mail.gmail.com>
To: Tim Deegan <tim@xen.org>
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Clang/LLVM version requirements
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> Looks like the clang build has bitrotted a little - sorry.  It's too
> late to fix this for 4.2 now but we can sort it out after we branch
> (i.e. next week) and backport any build fixes for 4.2.1.
>

No worries. I can try and help out on this. Do you think it is
worthwhile to start a Wiki page for this type of work. I was working
with cppcheck, sparse, clang on/for xen...

Jeff

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 07 15:59:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Sep 2012 15:59:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TA0xi-00062V-Rd; Fri, 07 Sep 2012 15:59:18 +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 1TA0xh-00061u-2N
	for xen-devel@lists.xen.org; Fri, 07 Sep 2012 15:59:17 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1347033549!8650302!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDc0NDUwMw==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11277 invoked from network); 7 Sep 2012 15:59:10 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-16.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 7 Sep 2012 15:59:10 -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 q87Fx3RB020661
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 7 Sep 2012 15:59:04 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
	q87Fx24W009695
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 7 Sep 2012 15:59:03 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
	q87Fx23Y006037; Fri, 7 Sep 2012 10:59:02 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 07 Sep 2012 08:59:02 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 57906402E4; Fri,  7 Sep 2012 11:48:27 -0400 (EDT)
Date: Fri, 7 Sep 2012 11:48:27 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20120907154827.GA6059@phenom.dumpdata.com>
References: <1347018043-21252-1-git-send-email-stefan.bader@canonical.com>
	<504A05B00200007800099C7B@nat28.tlf.novell.com>
	<5049F4E9.9050306@canonical.com>
	<504A1A950200007800099D4C@nat28.tlf.novell.com>
	<20120907142251.GA20096@linuxtx.org>
	<504A32800200007800099E40@nat28.tlf.novell.com>
	<504A172B.5020005@canonical.com>
	<504A347B0200007800099E92@nat28.tlf.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <504A347B0200007800099E92@nat28.tlf.novell.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	"Justin M. Forbes" <jmforbes@linuxtx.org>, Matt Wilson <msw@amazon.com>,
	Stefan Bader <stefan.bader@canonical.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH/RFC] Fix xsave bug on older Xen hypervisors
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Sep 07, 2012 at 04:52:59PM +0100, Jan Beulich wrote:
> >>> On 07.09.12 at 17:47, Stefan Bader <stefan.bader@canonical.com> wrote:
> > On 07.09.2012 17:44, Jan Beulich wrote:
> >> All of this still doesn't provide evidence that a plain upstream
> >> kernel is actually having any problems in the first place. Further,
> >> if you say EC2 has a crippled hypervisor patch - is that patch
> >> available for looking at somewhere?
> > 
> > It was not a hypervisor patch. It was one for the guest. This was the hack:
> 
> So then why do you want to patch the upstream kernel? It won't
> make that hack go away, nor will it help any existing kernels.

It will make both distro ditch that patch - and instead they can use this.
[As we can ask them to ditch their crippled patch and they can rest
safely knowing that the upstream kernel has a quirk workaround for what
they had been hitting for ages]

Also with this patch any upstream kernel that runs on Amazon EC2 will not
run in-to the issue that Fedora and Canonical ran with an virgin kernel
when they were deploying it first time. The Amazon EC2 guidelines have it
spelled out somewhere that one can't depend on certain things  - even if
they are detected. This was one of them, and MWAIT I believe was the other.

It won't fix existing kernels - that is true but that is not what the
purpose of this patch is.

> 
> Jan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 07 15:59:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Sep 2012 15:59:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TA0xi-00062V-Rd; Fri, 07 Sep 2012 15:59:18 +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 1TA0xh-00061u-2N
	for xen-devel@lists.xen.org; Fri, 07 Sep 2012 15:59:17 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1347033549!8650302!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDc0NDUwMw==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11277 invoked from network); 7 Sep 2012 15:59:10 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-16.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 7 Sep 2012 15:59:10 -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 q87Fx3RB020661
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 7 Sep 2012 15:59:04 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
	q87Fx24W009695
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 7 Sep 2012 15:59:03 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
	q87Fx23Y006037; Fri, 7 Sep 2012 10:59:02 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 07 Sep 2012 08:59:02 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 57906402E4; Fri,  7 Sep 2012 11:48:27 -0400 (EDT)
Date: Fri, 7 Sep 2012 11:48:27 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20120907154827.GA6059@phenom.dumpdata.com>
References: <1347018043-21252-1-git-send-email-stefan.bader@canonical.com>
	<504A05B00200007800099C7B@nat28.tlf.novell.com>
	<5049F4E9.9050306@canonical.com>
	<504A1A950200007800099D4C@nat28.tlf.novell.com>
	<20120907142251.GA20096@linuxtx.org>
	<504A32800200007800099E40@nat28.tlf.novell.com>
	<504A172B.5020005@canonical.com>
	<504A347B0200007800099E92@nat28.tlf.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <504A347B0200007800099E92@nat28.tlf.novell.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	"Justin M. Forbes" <jmforbes@linuxtx.org>, Matt Wilson <msw@amazon.com>,
	Stefan Bader <stefan.bader@canonical.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH/RFC] Fix xsave bug on older Xen hypervisors
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Sep 07, 2012 at 04:52:59PM +0100, Jan Beulich wrote:
> >>> On 07.09.12 at 17:47, Stefan Bader <stefan.bader@canonical.com> wrote:
> > On 07.09.2012 17:44, Jan Beulich wrote:
> >> All of this still doesn't provide evidence that a plain upstream
> >> kernel is actually having any problems in the first place. Further,
> >> if you say EC2 has a crippled hypervisor patch - is that patch
> >> available for looking at somewhere?
> > 
> > It was not a hypervisor patch. It was one for the guest. This was the hack:
> 
> So then why do you want to patch the upstream kernel? It won't
> make that hack go away, nor will it help any existing kernels.

It will make both distro ditch that patch - and instead they can use this.
[As we can ask them to ditch their crippled patch and they can rest
safely knowing that the upstream kernel has a quirk workaround for what
they had been hitting for ages]

Also with this patch any upstream kernel that runs on Amazon EC2 will not
run in-to the issue that Fedora and Canonical ran with an virgin kernel
when they were deploying it first time. The Amazon EC2 guidelines have it
spelled out somewhere that one can't depend on certain things  - even if
they are detected. This was one of them, and MWAIT I believe was the other.

It won't fix existing kernels - that is true but that is not what the
purpose of this patch is.

> 
> Jan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 07 15:59:52 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Sep 2012 15: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 1TA0yB-00069d-P3; Fri, 07 Sep 2012 15:59:47 +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 1TA0y9-000697-Us
	for xen-devel@lists.xen.org; Fri, 07 Sep 2012 15:59:46 +0000
Received: from [85.158.143.99:13088] by server-1.bemta-4.messagelabs.com id
	34/60-12504-1F91A405; Fri, 07 Sep 2012 15:59:45 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-15.tower-216.messagelabs.com!1347033584!29151147!1
X-Originating-IP: [81.169.146.162]
X-SpamReason: No, hits=0.5 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiA0MDE0ODQ=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiA0MDE0ODQ=\n,BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11268 invoked from network); 7 Sep 2012 15:59:44 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162)
	by server-15.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 7 Sep 2012 15:59:44 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/lr0M7qFlg=
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-069-014.pools.arcor-ip.net [84.57.69.14])
	by smtp.strato.de (josoe mo18) (RZmta 30.14 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id 50795eo87EHN83 ;
	Fri, 7 Sep 2012 17:59:44 +0200 (CEST)
Received: by probook.site (Postfix, from userid 1000)
	id 221D3183AD; Fri,  7 Sep 2012 17:59:42 +0200 (CEST)
Date: Fri, 7 Sep 2012 17:59:42 +0200
From: Olaf Hering <olaf@aepfle.de>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120907155942.GA28841@aepfle.de>
References: <1347027296.30018.108.camel@zakaz.uk.xensource.com>
	<8149449A-BB9D-40AE-945F-ACED38979F19@gmail.com>
	<1347032878.30018.127.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1347032878.30018.127.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.5.21.rev5555 (2012-07-20)
Cc: Andres Lagar-Cavilla <andres.lagarcavilla@gmail.com>,
	Tim Deegan <tim@xen.org>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.2 new features and status -- please help me
	make a list
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Sep 07, Ian Campbell wrote:

> On Fri, 2012-09-07 at 15:34 +0100, Andres Lagar-Cavilla wrote:
> 
> > > xenpaging: Page HVM guest pages to disk
> > >        Was marked as tech preview in 4.1 and earlier, still is?
> > > 
> > > memsharing: Sharing of HVM guest pages.
> > >        Was marked as tech preview in 4.1 and earlier, still is?
> > 
> > Both xenpaging and memsharing are functional as far as I am concerned.
> 
> This is on the hypervisor side I guess? Or are the tools as supplied in
> the xen tree useful too?

xenpaging and the hypervisor work ok. The lack of xend/libxl integration
causes small inconvenience because the actual memory footprint has to be
set manually with xenstore-write. And until a target is set in xenstore
the tool does a busyloop. This is fixed with this patch, sent a few days
ago: <b088e473c7fb1a47b957.1346142770@probook.site>


> > Xen{paging/sharing} still have border conditions in which domains are
> > crashed. They are rare enough that I have not experienced them in
> > practice. This is due to a need for more mature wait queue code in the
> > hypervisor. The plan is to address this in 4.3.
> 
> Perhaps that's an argument for leaving it as tech-preview until 4.3
> then?

I would say yes, at least for paging.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 07 15:59:52 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Sep 2012 15: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 1TA0yB-00069d-P3; Fri, 07 Sep 2012 15:59:47 +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 1TA0y9-000697-Us
	for xen-devel@lists.xen.org; Fri, 07 Sep 2012 15:59:46 +0000
Received: from [85.158.143.99:13088] by server-1.bemta-4.messagelabs.com id
	34/60-12504-1F91A405; Fri, 07 Sep 2012 15:59:45 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-15.tower-216.messagelabs.com!1347033584!29151147!1
X-Originating-IP: [81.169.146.162]
X-SpamReason: No, hits=0.5 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiA0MDE0ODQ=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiA0MDE0ODQ=\n,BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11268 invoked from network); 7 Sep 2012 15:59:44 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162)
	by server-15.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 7 Sep 2012 15:59:44 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/lr0M7qFlg=
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-069-014.pools.arcor-ip.net [84.57.69.14])
	by smtp.strato.de (josoe mo18) (RZmta 30.14 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id 50795eo87EHN83 ;
	Fri, 7 Sep 2012 17:59:44 +0200 (CEST)
Received: by probook.site (Postfix, from userid 1000)
	id 221D3183AD; Fri,  7 Sep 2012 17:59:42 +0200 (CEST)
Date: Fri, 7 Sep 2012 17:59:42 +0200
From: Olaf Hering <olaf@aepfle.de>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120907155942.GA28841@aepfle.de>
References: <1347027296.30018.108.camel@zakaz.uk.xensource.com>
	<8149449A-BB9D-40AE-945F-ACED38979F19@gmail.com>
	<1347032878.30018.127.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1347032878.30018.127.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.5.21.rev5555 (2012-07-20)
Cc: Andres Lagar-Cavilla <andres.lagarcavilla@gmail.com>,
	Tim Deegan <tim@xen.org>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.2 new features and status -- please help me
	make a list
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Sep 07, Ian Campbell wrote:

> On Fri, 2012-09-07 at 15:34 +0100, Andres Lagar-Cavilla wrote:
> 
> > > xenpaging: Page HVM guest pages to disk
> > >        Was marked as tech preview in 4.1 and earlier, still is?
> > > 
> > > memsharing: Sharing of HVM guest pages.
> > >        Was marked as tech preview in 4.1 and earlier, still is?
> > 
> > Both xenpaging and memsharing are functional as far as I am concerned.
> 
> This is on the hypervisor side I guess? Or are the tools as supplied in
> the xen tree useful too?

xenpaging and the hypervisor work ok. The lack of xend/libxl integration
causes small inconvenience because the actual memory footprint has to be
set manually with xenstore-write. And until a target is set in xenstore
the tool does a busyloop. This is fixed with this patch, sent a few days
ago: <b088e473c7fb1a47b957.1346142770@probook.site>


> > Xen{paging/sharing} still have border conditions in which domains are
> > crashed. They are rare enough that I have not experienced them in
> > practice. This is due to a need for more mature wait queue code in the
> > hypervisor. The plan is to address this in 4.3.
> 
> Perhaps that's an argument for leaving it as tech-preview until 4.3
> then?

I would say yes, at least for paging.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 07 16:00:39 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Sep 2012 16: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 1TA0yv-0006j6-Eq; Fri, 07 Sep 2012 16:00:33 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jmforbes@linuxtx.org>) id 1TA0yu-0006ih-00
	for xen-devel@lists.xen.org; Fri, 07 Sep 2012 16:00:32 +0000
Received: from [85.158.138.51:20543] by server-9.bemta-3.messagelabs.com id
	69/BD-15390-F1A1A405; Fri, 07 Sep 2012 16:00:31 +0000
X-Env-Sender: jmforbes@linuxtx.org
X-Msg-Ref: server-12.tower-174.messagelabs.com!1347033628!21381588!1
X-Originating-IP: [209.85.214.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26745 invoked from network); 7 Sep 2012 16:00:29 -0000
Received: from mail-ob0-f173.google.com (HELO mail-ob0-f173.google.com)
	(209.85.214.173)
	by server-12.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Sep 2012 16:00:29 -0000
Received: by obbta14 with SMTP id ta14so6073845obb.32
	for <xen-devel@lists.xen.org>; Fri, 07 Sep 2012 09:00:28 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=message-id:subject:from:to:cc:date:in-reply-to:references
	:content-type:x-mailer:mime-version:content-transfer-encoding
	:x-gm-message-state;
	bh=wkGq+zsPGf8PU2tzLBwlaCsTtRSM1xdDsdwCYQt+Mc8=;
	b=BGQo5EXdInsDbZj2cR8iEMJhLyNC663+kEPWzJLEtOi7lJybapIGmqlt4PHYKcOaIE
	RpmdOgYH68pqmGuQ4fPx+OOsgEe9dSR6ZW5TWAVYCMRf0mUJUBc4obgwdiFyftVk2G33
	HKY8Ity8JwfJ9mlFHP1rogSf+//wN91SL+BEe8J0GPKTe+KdThrgaK9xNoJzrXCPQcHk
	0jRPBPdk2rkjhiwzoC7f/7e/h6675r5rIHaCm7tmtyIV3xddHomWywr/NFAVYTRk9Pp7
	XU47jCzax5I6PGH4WWpH+il0gQIaHBMTgtm4J68tRlCJIcDXADp4VJ/GnmzCKez6zNV4
	+Z5Q==
Received: by 10.182.174.68 with SMTP id bq4mr6644245obc.53.1347033627995;
	Fri, 07 Sep 2012 09:00:27 -0700 (PDT)
Received: from [192.168.1.164] (108-232-88-112.lightspeed.rcsntx.sbcglobal.net.
	[108.232.88.112])
	by mx.google.com with ESMTPS id l10sm4021383oeb.13.2012.09.07.09.00.23
	(version=SSLv3 cipher=OTHER); Fri, 07 Sep 2012 09:00:24 -0700 (PDT)
Message-ID: <1347033622.2980.12.camel@fedora64.linuxtx.org>
From: "Justin M. Forbes" <jmforbes@linuxtx.org>
To: Jan Beulich <JBeulich@suse.com>
Date: Fri, 07 Sep 2012 11:00:22 -0500
In-Reply-To: <504A32800200007800099E40@nat28.tlf.novell.com>
References: <1347018043-21252-1-git-send-email-stefan.bader@canonical.com>
	<504A05B00200007800099C7B@nat28.tlf.novell.com>
	<5049F4E9.9050306@canonical.com>
	<504A1A950200007800099D4C@nat28.tlf.novell.com>
	<20120907142251.GA20096@linuxtx.org>
	<504A32800200007800099E40@nat28.tlf.novell.com>
X-Mailer: Evolution 3.4.4 (3.4.4-1.fc17) 
Mime-Version: 1.0
X-Gm-Message-State: ALoCoQljaKl+ZzsDetpebCjujQ3Y78OGmwP520XRHTdBmP7GAwy6RnngYGW1Tg2EbZ0KHyn12nW+
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Stefan Bader <stefan.bader@canonical.com>,
	Matt Wilson <msw@amazon.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH/RFC] Fix xsave bug on older Xen hypervisors
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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-09-07 at 16:44 +0100, Jan Beulich wrote:
> >>> On 07.09.12 at 16:22, "Justin M. Forbes" <jmforbes@linuxtx.org> wrote:
> > On Fri, Sep 07, 2012 at 03:02:29PM +0100, Jan Beulich wrote:
> >> >>> On 07.09.12 at 15:21, Stefan Bader <stefan.bader@canonical.com> wrote:
> >> > On 07.09.2012 14:33, Jan Beulich wrote:
> >> >>>>> On 07.09.12 at 13:40, Stefan Bader <stefan.bader@canonical.com> wrote:
> >> >>> When writing unsupported flags into CR4 (for some time the
> >> >>> xen_write_cr4 function would refuse to do anything at all)
> >> >>> older Xen hypervisors (and patch can potentially be improved
> >> >>> by finding out what older means in version numbers) would
> >> >>> crash the guest.
> >> >>>
> >> >>> Since Amazon EC2 would at least in the past be affected by that,
> >> >>> Fedora and Ubuntu were carrying a hack that would filter out
> >> >>> X86_CR4_OSXSAVE before writing to CR4. This would affect any
> >> >>> PV guest, even those running on a newer HV.
> >> >>>
> >> >>> And this recently caused trouble because some user-space was
> >> >>> only partially checking (or maybe only looking at the cpuid
> >> >>> bits) and then trying to use xsave even though the OS support
> >> >>> was not set.
> >> >>>
> >> >>> So I came up with a patch that would
> >> >>> - limit the work-around to certain Xen versions
> >> >>> - prevent the write to CR4 by unsetting xsave and osxsave in
> >> >>>   the cpuid bits
> >> >>>
> >> >>> Doing things that way may actually allow this to be acceptable
> >> >>> upstream, so I am sending it around, now.
> >> >>> It probably could be improved when knowing the exact version
> >> >>> to test for but otherwise should allow to work around the guest
> >> >>> crash while not preventing xsave on Xen 4.x and newer hosts.
> >> >> 
> >> >> Before considering a hack like this, I'd really like to see evidence
> >> >> of the described behavior with an upstream kernel (i.e. not one
> >> >> with that known broken hack patched in, which has never been
> >> >> upstream afaict).
> >> > 
> >> > This is the reason I wrote that Fedora and Ubuntu were carrying it. It 
> > never 
> >> > has
> >> > been send upstream (the other version) because it would filter the CR4 
> > write 
> >> > for
> >> > any PV guest regardless of host version.
> >> 
> >> But iirc that bad patch is a Linux side one (i.e. you're trying to fix
> >> something upstream that isn't upstream)?
> >> 
> > Right, so the patch that this improves upon, and that Fedora and Ubuntu are
> > currently carrying is not upstream because:
> > 
> > a) It's crap, it cripples upstream xen users, but doesn't impact RHEL xen
> > users because xsave was never supported there.
> > 
> > b) The hypervisor was patched to make it unnecessary quite some time ago,
> > and we hoped EC2 would eventually pick up that correct patch and we could
> > drop the crap kernel patch.
> > 
> > Unfortunately this has not happened. We are at a point where EC2 really is
> > a quirk that has to be worked around. Distros do not want to maintain
> > a separate EC2 build of the kernel, so the easiest way is to cripple
> > current upstream xen users.  This quirk is unfortunately the best possible
> > solution.  Having it upstream also makes it possible for any user to build
> > an upstream kernel that will run on EC2 without having to dig a random
> > patch out of a vendor kernel.
> 
> All of this still doesn't provide evidence that a plain upstream
> kernel is actually having any problems in the first place. Further,
> if you say EC2 has a crippled hypervisor patch - is that patch
> available for looking at somewhere?

Yes, I can verify that a plain upstream kernel has problems in the first
place, which is why we are carrying a patch to simply disable xsave all
together in the pv guest.
EC2 is not carrying a patch to cripple the hypervisor, there was an old
xen bug that makes all this fail.  The correct fix for that bug is to
patch the hypervisor, but they have not done so. Upstream xen has had
the fix for quite some time, but that doesn't change the fact that a lot
of xen guest usage these days is on EC2.  This is no different than
putting in a quirk to work around a firmware bug in common use.

Justin



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 07 16:00:39 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Sep 2012 16: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 1TA0yv-0006j6-Eq; Fri, 07 Sep 2012 16:00:33 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jmforbes@linuxtx.org>) id 1TA0yu-0006ih-00
	for xen-devel@lists.xen.org; Fri, 07 Sep 2012 16:00:32 +0000
Received: from [85.158.138.51:20543] by server-9.bemta-3.messagelabs.com id
	69/BD-15390-F1A1A405; Fri, 07 Sep 2012 16:00:31 +0000
X-Env-Sender: jmforbes@linuxtx.org
X-Msg-Ref: server-12.tower-174.messagelabs.com!1347033628!21381588!1
X-Originating-IP: [209.85.214.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26745 invoked from network); 7 Sep 2012 16:00:29 -0000
Received: from mail-ob0-f173.google.com (HELO mail-ob0-f173.google.com)
	(209.85.214.173)
	by server-12.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Sep 2012 16:00:29 -0000
Received: by obbta14 with SMTP id ta14so6073845obb.32
	for <xen-devel@lists.xen.org>; Fri, 07 Sep 2012 09:00:28 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=message-id:subject:from:to:cc:date:in-reply-to:references
	:content-type:x-mailer:mime-version:content-transfer-encoding
	:x-gm-message-state;
	bh=wkGq+zsPGf8PU2tzLBwlaCsTtRSM1xdDsdwCYQt+Mc8=;
	b=BGQo5EXdInsDbZj2cR8iEMJhLyNC663+kEPWzJLEtOi7lJybapIGmqlt4PHYKcOaIE
	RpmdOgYH68pqmGuQ4fPx+OOsgEe9dSR6ZW5TWAVYCMRf0mUJUBc4obgwdiFyftVk2G33
	HKY8Ity8JwfJ9mlFHP1rogSf+//wN91SL+BEe8J0GPKTe+KdThrgaK9xNoJzrXCPQcHk
	0jRPBPdk2rkjhiwzoC7f/7e/h6675r5rIHaCm7tmtyIV3xddHomWywr/NFAVYTRk9Pp7
	XU47jCzax5I6PGH4WWpH+il0gQIaHBMTgtm4J68tRlCJIcDXADp4VJ/GnmzCKez6zNV4
	+Z5Q==
Received: by 10.182.174.68 with SMTP id bq4mr6644245obc.53.1347033627995;
	Fri, 07 Sep 2012 09:00:27 -0700 (PDT)
Received: from [192.168.1.164] (108-232-88-112.lightspeed.rcsntx.sbcglobal.net.
	[108.232.88.112])
	by mx.google.com with ESMTPS id l10sm4021383oeb.13.2012.09.07.09.00.23
	(version=SSLv3 cipher=OTHER); Fri, 07 Sep 2012 09:00:24 -0700 (PDT)
Message-ID: <1347033622.2980.12.camel@fedora64.linuxtx.org>
From: "Justin M. Forbes" <jmforbes@linuxtx.org>
To: Jan Beulich <JBeulich@suse.com>
Date: Fri, 07 Sep 2012 11:00:22 -0500
In-Reply-To: <504A32800200007800099E40@nat28.tlf.novell.com>
References: <1347018043-21252-1-git-send-email-stefan.bader@canonical.com>
	<504A05B00200007800099C7B@nat28.tlf.novell.com>
	<5049F4E9.9050306@canonical.com>
	<504A1A950200007800099D4C@nat28.tlf.novell.com>
	<20120907142251.GA20096@linuxtx.org>
	<504A32800200007800099E40@nat28.tlf.novell.com>
X-Mailer: Evolution 3.4.4 (3.4.4-1.fc17) 
Mime-Version: 1.0
X-Gm-Message-State: ALoCoQljaKl+ZzsDetpebCjujQ3Y78OGmwP520XRHTdBmP7GAwy6RnngYGW1Tg2EbZ0KHyn12nW+
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Stefan Bader <stefan.bader@canonical.com>,
	Matt Wilson <msw@amazon.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH/RFC] Fix xsave bug on older Xen hypervisors
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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-09-07 at 16:44 +0100, Jan Beulich wrote:
> >>> On 07.09.12 at 16:22, "Justin M. Forbes" <jmforbes@linuxtx.org> wrote:
> > On Fri, Sep 07, 2012 at 03:02:29PM +0100, Jan Beulich wrote:
> >> >>> On 07.09.12 at 15:21, Stefan Bader <stefan.bader@canonical.com> wrote:
> >> > On 07.09.2012 14:33, Jan Beulich wrote:
> >> >>>>> On 07.09.12 at 13:40, Stefan Bader <stefan.bader@canonical.com> wrote:
> >> >>> When writing unsupported flags into CR4 (for some time the
> >> >>> xen_write_cr4 function would refuse to do anything at all)
> >> >>> older Xen hypervisors (and patch can potentially be improved
> >> >>> by finding out what older means in version numbers) would
> >> >>> crash the guest.
> >> >>>
> >> >>> Since Amazon EC2 would at least in the past be affected by that,
> >> >>> Fedora and Ubuntu were carrying a hack that would filter out
> >> >>> X86_CR4_OSXSAVE before writing to CR4. This would affect any
> >> >>> PV guest, even those running on a newer HV.
> >> >>>
> >> >>> And this recently caused trouble because some user-space was
> >> >>> only partially checking (or maybe only looking at the cpuid
> >> >>> bits) and then trying to use xsave even though the OS support
> >> >>> was not set.
> >> >>>
> >> >>> So I came up with a patch that would
> >> >>> - limit the work-around to certain Xen versions
> >> >>> - prevent the write to CR4 by unsetting xsave and osxsave in
> >> >>>   the cpuid bits
> >> >>>
> >> >>> Doing things that way may actually allow this to be acceptable
> >> >>> upstream, so I am sending it around, now.
> >> >>> It probably could be improved when knowing the exact version
> >> >>> to test for but otherwise should allow to work around the guest
> >> >>> crash while not preventing xsave on Xen 4.x and newer hosts.
> >> >> 
> >> >> Before considering a hack like this, I'd really like to see evidence
> >> >> of the described behavior with an upstream kernel (i.e. not one
> >> >> with that known broken hack patched in, which has never been
> >> >> upstream afaict).
> >> > 
> >> > This is the reason I wrote that Fedora and Ubuntu were carrying it. It 
> > never 
> >> > has
> >> > been send upstream (the other version) because it would filter the CR4 
> > write 
> >> > for
> >> > any PV guest regardless of host version.
> >> 
> >> But iirc that bad patch is a Linux side one (i.e. you're trying to fix
> >> something upstream that isn't upstream)?
> >> 
> > Right, so the patch that this improves upon, and that Fedora and Ubuntu are
> > currently carrying is not upstream because:
> > 
> > a) It's crap, it cripples upstream xen users, but doesn't impact RHEL xen
> > users because xsave was never supported there.
> > 
> > b) The hypervisor was patched to make it unnecessary quite some time ago,
> > and we hoped EC2 would eventually pick up that correct patch and we could
> > drop the crap kernel patch.
> > 
> > Unfortunately this has not happened. We are at a point where EC2 really is
> > a quirk that has to be worked around. Distros do not want to maintain
> > a separate EC2 build of the kernel, so the easiest way is to cripple
> > current upstream xen users.  This quirk is unfortunately the best possible
> > solution.  Having it upstream also makes it possible for any user to build
> > an upstream kernel that will run on EC2 without having to dig a random
> > patch out of a vendor kernel.
> 
> All of this still doesn't provide evidence that a plain upstream
> kernel is actually having any problems in the first place. Further,
> if you say EC2 has a crippled hypervisor patch - is that patch
> available for looking at somewhere?

Yes, I can verify that a plain upstream kernel has problems in the first
place, which is why we are carrying a patch to simply disable xsave all
together in the pv guest.
EC2 is not carrying a patch to cripple the hypervisor, there was an old
xen bug that makes all this fail.  The correct fix for that bug is to
patch the hypervisor, but they have not done so. Upstream xen has had
the fix for quite some time, but that doesn't change the fact that a lot
of xen guest usage these days is on EC2.  This is no different than
putting in a quirk to work around a firmware bug in common use.

Justin



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 07 16:06:10 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Sep 2012 16:06:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TA14D-0007Er-AN; Fri, 07 Sep 2012 16:06: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 1TA14B-0007Em-JT
	for xen-devel@lists.xen.org; Fri, 07 Sep 2012 16:05:59 +0000
Received: from [85.158.143.35:42685] by server-2.bemta-4.messagelabs.com id
	71/BD-21239-66B1A405; Fri, 07 Sep 2012 16:05:58 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1347033950!6247351!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTIyMTE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12611 invoked from network); 7 Sep 2012 16:05:51 -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;
	7 Sep 2012 16:05:51 -0000
X-IronPort-AV: E=Sophos;i="4.80,387,1344211200"; d="scan'208";a="14414709"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Sep 2012 16:05:38 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Fri, 7 Sep 2012
	17:05:38 +0100
Message-ID: <1347033936.30018.134.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Olaf Hering <olaf@aepfle.de>
Date: Fri, 7 Sep 2012 17:05:36 +0100
In-Reply-To: <b088e473c7fb1a47b957.1346142770@probook.site>
References: <b088e473c7fb1a47b957.1346142770@probook.site>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] xenpaging: use poll timeout if no paging
 target 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 Tue, 2012-08-28 at 09:32 +0100, Olaf Hering wrote:
> # HG changeset patch
> # User Olaf Hering <olaf@aepfle.de>
> # Date 1346142745 -7200
> # Node ID b088e473c7fb1a47b9578693c1750cd27767cc25
> # Parent  03ef29089830b119b6efd87db8ab5c38b7428938
> xenpaging: use poll timeout if no paging target exists
> 
> Currently xenpaging will use 100% cpu time if a paging target is not yet
> set via xenstore. The reason is that ->use_poll_timeout is initialized
> to zero. Another case is when the paging target is set to zero. In this
> case ->use_poll_timeout will not be set to 1.
> 
> Fix the first case by initializing use_poll_timeout to 1 in
> xenpaging_init. The second case is fixed by setting use_poll_timeout in
> case the target is zero and there are no more pages left to resume.
> 
> Signed-off-by: Olaf Hering <olaf@aepfle.de>
> 
> diff -r 03ef29089830 -r b088e473c7fb tools/xenpaging/xenpaging.c
> --- a/tools/xenpaging/xenpaging.c
> +++ b/tools/xenpaging/xenpaging.c
> @@ -482,6 +482,9 @@ static struct xenpaging *xenpaging_init(
>          goto err;
>      }
>  
> +    /* Use a poll timeout until xenpaging got a target from xenstore */
> +    paging->use_poll_timeout = 1;

Don't you want a negative (== infinite) timeout in this case?

> +
>      return paging;
>  
>   err:
> @@ -1019,6 +1022,8 @@ int main(int argc, char *argv[])
>          {
>              if ( paging->num_paged_out )
>                  resume_pages(paging, paging->num_paged_out);
> +            else
> +                paging->use_poll_timeout = 1;
>          }
>          /* Evict more pages if target not reached */
>          else if ( tot_pages > paging->target_tot_pages )
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 07 16:06:10 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Sep 2012 16:06:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TA14D-0007Er-AN; Fri, 07 Sep 2012 16:06: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 1TA14B-0007Em-JT
	for xen-devel@lists.xen.org; Fri, 07 Sep 2012 16:05:59 +0000
Received: from [85.158.143.35:42685] by server-2.bemta-4.messagelabs.com id
	71/BD-21239-66B1A405; Fri, 07 Sep 2012 16:05:58 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1347033950!6247351!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTIyMTE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12611 invoked from network); 7 Sep 2012 16:05:51 -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;
	7 Sep 2012 16:05:51 -0000
X-IronPort-AV: E=Sophos;i="4.80,387,1344211200"; d="scan'208";a="14414709"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Sep 2012 16:05:38 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1; Fri, 7 Sep 2012
	17:05:38 +0100
Message-ID: <1347033936.30018.134.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Olaf Hering <olaf@aepfle.de>
Date: Fri, 7 Sep 2012 17:05:36 +0100
In-Reply-To: <b088e473c7fb1a47b957.1346142770@probook.site>
References: <b088e473c7fb1a47b957.1346142770@probook.site>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] xenpaging: use poll timeout if no paging
 target 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 Tue, 2012-08-28 at 09:32 +0100, Olaf Hering wrote:
> # HG changeset patch
> # User Olaf Hering <olaf@aepfle.de>
> # Date 1346142745 -7200
> # Node ID b088e473c7fb1a47b9578693c1750cd27767cc25
> # Parent  03ef29089830b119b6efd87db8ab5c38b7428938
> xenpaging: use poll timeout if no paging target exists
> 
> Currently xenpaging will use 100% cpu time if a paging target is not yet
> set via xenstore. The reason is that ->use_poll_timeout is initialized
> to zero. Another case is when the paging target is set to zero. In this
> case ->use_poll_timeout will not be set to 1.
> 
> Fix the first case by initializing use_poll_timeout to 1 in
> xenpaging_init. The second case is fixed by setting use_poll_timeout in
> case the target is zero and there are no more pages left to resume.
> 
> Signed-off-by: Olaf Hering <olaf@aepfle.de>
> 
> diff -r 03ef29089830 -r b088e473c7fb tools/xenpaging/xenpaging.c
> --- a/tools/xenpaging/xenpaging.c
> +++ b/tools/xenpaging/xenpaging.c
> @@ -482,6 +482,9 @@ static struct xenpaging *xenpaging_init(
>          goto err;
>      }
>  
> +    /* Use a poll timeout until xenpaging got a target from xenstore */
> +    paging->use_poll_timeout = 1;

Don't you want a negative (== infinite) timeout in this case?

> +
>      return paging;
>  
>   err:
> @@ -1019,6 +1022,8 @@ int main(int argc, char *argv[])
>          {
>              if ( paging->num_paged_out )
>                  resume_pages(paging, paging->num_paged_out);
> +            else
> +                paging->use_poll_timeout = 1;
>          }
>          /* Evict more pages if target not reached */
>          else if ( tot_pages > paging->target_tot_pages )
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 07 16:06:39 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Sep 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 1TA14d-0007Gz-NM; Fri, 07 Sep 2012 16:06:27 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ben.guthro@gmail.com>) id 1TA14c-0007GQ-Vn
	for xen-devel@lists.xen.org; Fri, 07 Sep 2012 16:06:27 +0000
X-Env-Sender: ben.guthro@gmail.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1347033979!4896304!1
X-Originating-IP: [209.85.223.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15790 invoked from network); 7 Sep 2012 16:06:20 -0000
Received: from mail-ie0-f173.google.com (HELO mail-ie0-f173.google.com)
	(209.85.223.173)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Sep 2012 16:06:20 -0000
Received: by iebc10 with SMTP id c10so6468756ieb.32
	for <xen-devel@lists.xen.org>; Fri, 07 Sep 2012 09:06:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
	bh=gqhwePn78I10GZkTguWrY8Yz6xcWUuo17vBr2RxP1hQ=;
	b=K+Ka2qxZjX2jxhm5c4IVIR7tgiwdtalxi7JrvxYKoNanCAhJV450v/TZ/zB8nNv1Q7
	VzLUbaL2IrzY2fDLpIbBhJJ/2kNSkX0exmx/KY2C+lYX/0AGIu8XMFUkeehIm049QLSG
	5IEYetwh5H0ASYzrcFyWGRrr95SAJewMGoGc9756Sf1o+gkffbfbIbx3hf1j+QQc6pB1
	OXDCFjFhFhheyIu/TDT2B6DU2urRcA84Q1lFm6zw5gt6znlzFx1T222FP7BkF1h8FGtN
	j56T8+l4iKoTA5EKAxrjGEfLSlaDf5yE1bGUwsdAYFw9Hr9fcuE2QtmWzuM2eSigJTdP
	356g==
MIME-Version: 1.0
Received: by 10.50.173.69 with SMTP id bi5mr9574147igc.37.1347033978789; Fri,
	07 Sep 2012 09:06:18 -0700 (PDT)
Received: by 10.64.28.203 with HTTP; Fri, 7 Sep 2012 09:06:18 -0700 (PDT)
In-Reply-To: <504A024E0200007800099C5A@nat28.tlf.novell.com>
References: <CAOvdn6WwgBD-2yf1uu3m9-16=Tb5KUrybXf2KibtnxKbP7YtwA@mail.gmail.com>
	<CAOvdn6UBW-yTOMd3YSf5M9JiHLRivyaKL-qzcKG8epszqaKmGg@mail.gmail.com>
	<20120807163320.GC15053@phenom.dumpdata.com>
	<CAOvdn6XcRGKtJxGwJO8J+ZBJr89wfTLc1woW5rhtMM540H9h1w@mail.gmail.com>
	<CAOvdn6XUoSeGoo7X=AJ1kpDxZB9HZEv+TJ4v-=FHcyR4=CHK-w@mail.gmail.com>
	<502240F302000078000937A6@nat28.tlf.novell.com>
	<CAOvdn6WN3kxC8Bb9g6MpfLULu47EGSGCtajPc-SFeJ-8VSUQDQ@mail.gmail.com>
	<CAOvdn6Xk1inm1hU55i0phU2qvSWyJLNoyDdn43biBAY2OewPtw@mail.gmail.com>
	<5023F5400200007800093F4E@nat28.tlf.novell.com>
	<CAOvdn6U-f3C4U8xVPvDyRFkFFLkbfiCXg_n+9zgA9V5u+q5jfw@mail.gmail.com>
	<5023F8B80200007800093F8C@nat28.tlf.novell.com>
	<CAOvdn6XKHfete_+=Hkvt20G7_cJ-4i8+9j9YD30OxzQ16Ru-+g@mail.gmail.com>
	<5024CB720200007800094124@nat28.tlf.novell.com>
	<CAOvdn6VVJdhWVYa-gNVt3euE4AbGi1TijUCUd1wGzv0SCWEUYA@mail.gmail.com>
	<CAOvdn6USnG9Y4MNBhrDZmob0oJ8BgFfKTvFEhcKbXDxNmzfZ-Q@mail.gmail.com>
	<502B75BA0200007800094FD4@nat28.tlf.novell.com>
	<CAOvdn6Ww5oEj6Xg=XT4dWCYWUBuOdPqLz-CqNjz4HmCScE+==g@mail.gmail.com>
	<CAOvdn6Wsjds_dmZ0dwDTYmD-o-OqjBH5-b9mitAuUADE+A4_ag@mail.gmail.com>
	<502BB8FD02000078000951E0@nat28.tlf.novell.com>
	<CAOvdn6VD6bp13F-tvYdkBsj4hkhE7PTGZrapndtdHrDKeZqccg@mail.gmail.com>
	<502CCC0002000078000955C4@nat28.tlf.novell.com>
	<CAOvdn6VEuX7R2_wz74ZvCxMjC-=YUir9kP5sdxEVaKVspRUd_w@mail.gmail.com>
	<502CF0A8020000780009574E@nat28.tlf.novell.com>
	<CAOvdn6VsZvn_1TCWYeuyY5YuTcP8=miK2KwE4583nsj6Qjb_vg@mail.gmail.com>
	<504494FB0200007800098398@nat28.tlf.novell.com>
	<CAOvdn6UT13qvWbMyfZkWND03RoVKVSgb6wW4yqTUpuBYEX01Dg@mail.gmail.com>
	<5048958D02000078000993EB@nat28.tlf.novell.com>
	<CAOvdn6WrNK1Jn_Y_P7C3AwX6ApVcgzacLA_x-u=xBQtebnuPxA@mail.gmail.com>
	<CAOvdn6U_Z=KdEo56nqe7jN54BwiesRJqDOz_VzVNpkWGfFRd2A@mail.gmail.com>
	<5049CEAE0200007800099A33@nat28.tlf.novell.com>
	<CAOvdn6XmsEfs+aO7nqBHdA61HpT_n_8W95u0MMq5J21tZCFbzw@mail.gmail.com>
	<5049F37A0200007800099BDA@nat28.tlf.novell.com>
	<CAOvdn6W+=OYTH3xTWBxUB8f_2tuZYKPTo-eJG0jfkaJ2rVutCA@mail.gmail.com>
	<504A024E0200007800099C5A@nat28.tlf.novell.com>
Date: Fri, 7 Sep 2012 12:06:18 -0400
X-Google-Sender-Auth: fO0IzPqnFV1kpUneurX_VloSArc
Message-ID: <CAOvdn6XYjyYEgtrPskjCLK4BZWaPyriNGSVGzumdOP8-6=P_=Q@mail.gmail.com>
From: Ben Guthro <ben@guthro.net>
To: Jan Beulich <JBeulich@suse.com>
Content-Type: multipart/mixed; boundary=e89a8f5034fece607604c91ec930
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>, john.baboval@citrix.com,
	Thomas Goetz <thomas.goetz@citrix.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen4.2 S3 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>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--e89a8f5034fece607604c91ec930
Content-Type: text/plain; charset=ISO-8859-1

I'll work on getting a JTAG, ICE, or something else - it is on an
Intel SDP - so it should have the ports for it.

My current suspicion on this is that the hardware registers are not
being programmed the same way as they were in 4.0.x
(Since the "pulsing power button LED" on the laptops, and the behavior
of the Desktop SDP are now similar)

Once again - I don't have a lot of evidence to back this up - however,
if I ifdef out the register writes that actually start the low level
suspend - in
xen/arch/x86/acpi/power.c  acpi_enter_sleep_state() - the rest of the
suspend process completes as though the machine suspended, and then
immediately resumed.

In this case - the system seems to be functioning properly.





Hack to prevent low level S3 attached.



On Fri, Sep 7, 2012 at 8:18 AM, Jan Beulich <JBeulich@suse.com> wrote:
>>>> On 07.09.12 at 13:51, Ben Guthro <ben@guthro.net> wrote:
>> However, when I run with console=none, the observed behavior is very
>> different.
>> The system seems to go to sleep successfully - but when I press the
>> power button to wake it up - the power comes on - the fans spin up -
>> but the system is unresponsive.
>> No video
>> No network
>> keyboard LEDs (Caps,Numlock) do not light up.
>>
>>
>> Alternate debugging strategies welcome.
>
> I'm afraid other than being lucky to spot something via code
> inspection, the only alternative is an ITP/ICE. Maybe Intel folks
> could help out debugging this if it's reproducible for them.
>
> Jan
>

--e89a8f5034fece607604c91ec930
Content-Type: application/octet-stream; name="prevent-s3-lowlevel.patch"
Content-Disposition: attachment; filename="prevent-s3-lowlevel.patch"
Content-Transfer-Encoding: base64
X-Attachment-Id: f_h6th8imm0

ZGlmZiAtLWdpdCBhL3hlbi9hcmNoL3g4Ni9hY3BpL3Bvd2VyLmMgYi94ZW4vYXJjaC94ODYvYWNw
aS9wb3dlci5jCmluZGV4IGRlODZjNDYuLjkyMzFiNDggMTAwNjQ0Ci0tLSBhL3hlbi9hcmNoL3g4
Ni9hY3BpL3Bvd2VyLmMKKysrIGIveGVuL2FyY2gveDg2L2FjcGkvcG93ZXIuYwpAQCAtMjUzLDYg
KzI1Myw3IEBAIGludCBhY3BpX2VudGVyX3NsZWVwKHN0cnVjdCB4ZW5wZl9lbnRlcl9hY3BpX3Ns
ZWVwICpzbGVlcCkKICAgICByZXR1cm4gY29udGludWVfaHlwZXJjYWxsX29uX2NwdSgwLCBlbnRl
cl9zdGF0ZV9oZWxwZXIsICZhY3BpX3NpbmZvKTsKIH0KIAorI2lmIDAKIHN0YXRpYyBpbnQgYWNw
aV9nZXRfd2FrZV9zdGF0dXModm9pZCkKIHsKICAgICB1aW50MzJfdCB2YWw7CkBAIC0yNjcsNiAr
MjY4LDcgQEAgc3RhdGljIGludCBhY3BpX2dldF93YWtlX3N0YXR1cyh2b2lkKQogICAgIHZhbCA+
Pj0gQUNQSV9CSVRQT1NJVElPTl9XQUtFX1NUQVRVUzsKICAgICByZXR1cm4gdmFsOwogfQorI2Vu
ZGlmCiAKIHN0YXRpYyB2b2lkIHRib290X3NsZWVwKHU4IHNsZWVwX3N0YXRlKQogewpAQCAtMzE2
LDcgKzMxOCw3IEBAIHN0YXRpYyB2b2lkIHRib290X3NsZWVwKHU4IHNsZWVwX3N0YXRlKQogLyog
U3lzdGVtIGlzIHJlYWxseSBwdXQgaW50byBzbGVlcCBzdGF0ZSBieSB0aGlzIHN0dWIgKi8KIGFj
cGlfc3RhdHVzIGFjcGlfZW50ZXJfc2xlZXBfc3RhdGUodTggc2xlZXBfc3RhdGUpCiB7Ci0gICAg
YWNwaV9zdGF0dXMgc3RhdHVzOworICAgIC8qIGFjcGlfc3RhdHVzIHN0YXR1czsgKi8KIAogICAg
IGlmICggdGJvb3RfaW5fbWVhc3VyZWRfZW52KCkgKQogICAgIHsKQEAgLTMyNiw3ICszMjgsNyBA
QCBhY3BpX3N0YXR1cyBhY3BpX2VudGVyX3NsZWVwX3N0YXRlKHU4IHNsZWVwX3N0YXRlKQogICAg
IH0KIAogICAgIEFDUElfRkxVU0hfQ1BVX0NBQ0hFKCk7Ci0KKyNpZiAwCiAgICAgc3RhdHVzID0g
YWNwaV9od19yZWdpc3Rlcl93cml0ZShBQ1BJX1JFR0lTVEVSX1BNMUFfQ09OVFJPTCwgCiAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBhY3BpX3NpbmZvLnBtMWFfY250X3ZhbCk7
CiAgICAgaWYgKCBBQ1BJX0ZBSUxVUkUoc3RhdHVzKSApCkBAIC0zNDMsNyArMzQ1LDcgQEAgYWNw
aV9zdGF0dXMgYWNwaV9lbnRlcl9zbGVlcF9zdGF0ZSh1OCBzbGVlcF9zdGF0ZSkKICAgICAvKiBX
YWl0IHVudGlsIHdlIGVudGVyIHNsZWVwIHN0YXRlLCBhbmQgc3BpbiB1bnRpbCB3ZSB3YWtlICov
CiAgICAgd2hpbGUgKCAhYWNwaV9nZXRfd2FrZV9zdGF0dXMoKSApCiAgICAgICAgIGNvbnRpbnVl
OwotCisjZW5kaWYKICAgICByZXR1cm5fQUNQSV9TVEFUVVMoQUVfT0spOwogfQogCg==
--e89a8f5034fece607604c91ec930
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--e89a8f5034fece607604c91ec930--


From xen-devel-bounces@lists.xen.org Fri Sep 07 16:06:39 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Sep 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 1TA14d-0007Gz-NM; Fri, 07 Sep 2012 16:06:27 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ben.guthro@gmail.com>) id 1TA14c-0007GQ-Vn
	for xen-devel@lists.xen.org; Fri, 07 Sep 2012 16:06:27 +0000
X-Env-Sender: ben.guthro@gmail.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1347033979!4896304!1
X-Originating-IP: [209.85.223.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15790 invoked from network); 7 Sep 2012 16:06:20 -0000
Received: from mail-ie0-f173.google.com (HELO mail-ie0-f173.google.com)
	(209.85.223.173)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Sep 2012 16:06:20 -0000
Received: by iebc10 with SMTP id c10so6468756ieb.32
	for <xen-devel@lists.xen.org>; Fri, 07 Sep 2012 09:06:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
	bh=gqhwePn78I10GZkTguWrY8Yz6xcWUuo17vBr2RxP1hQ=;
	b=K+Ka2qxZjX2jxhm5c4IVIR7tgiwdtalxi7JrvxYKoNanCAhJV450v/TZ/zB8nNv1Q7
	VzLUbaL2IrzY2fDLpIbBhJJ/2kNSkX0exmx/KY2C+lYX/0AGIu8XMFUkeehIm049QLSG
	5IEYetwh5H0ASYzrcFyWGRrr95SAJewMGoGc9756Sf1o+gkffbfbIbx3hf1j+QQc6pB1
	OXDCFjFhFhheyIu/TDT2B6DU2urRcA84Q1lFm6zw5gt6znlzFx1T222FP7BkF1h8FGtN
	j56T8+l4iKoTA5EKAxrjGEfLSlaDf5yE1bGUwsdAYFw9Hr9fcuE2QtmWzuM2eSigJTdP
	356g==
MIME-Version: 1.0
Received: by 10.50.173.69 with SMTP id bi5mr9574147igc.37.1347033978789; Fri,
	07 Sep 2012 09:06:18 -0700 (PDT)
Received: by 10.64.28.203 with HTTP; Fri, 7 Sep 2012 09:06:18 -0700 (PDT)
In-Reply-To: <504A024E0200007800099C5A@nat28.tlf.novell.com>
References: <CAOvdn6WwgBD-2yf1uu3m9-16=Tb5KUrybXf2KibtnxKbP7YtwA@mail.gmail.com>
	<CAOvdn6UBW-yTOMd3YSf5M9JiHLRivyaKL-qzcKG8epszqaKmGg@mail.gmail.com>
	<20120807163320.GC15053@phenom.dumpdata.com>
	<CAOvdn6XcRGKtJxGwJO8J+ZBJr89wfTLc1woW5rhtMM540H9h1w@mail.gmail.com>
	<CAOvdn6XUoSeGoo7X=AJ1kpDxZB9HZEv+TJ4v-=FHcyR4=CHK-w@mail.gmail.com>
	<502240F302000078000937A6@nat28.tlf.novell.com>
	<CAOvdn6WN3kxC8Bb9g6MpfLULu47EGSGCtajPc-SFeJ-8VSUQDQ@mail.gmail.com>
	<CAOvdn6Xk1inm1hU55i0phU2qvSWyJLNoyDdn43biBAY2OewPtw@mail.gmail.com>
	<5023F5400200007800093F4E@nat28.tlf.novell.com>
	<CAOvdn6U-f3C4U8xVPvDyRFkFFLkbfiCXg_n+9zgA9V5u+q5jfw@mail.gmail.com>
	<5023F8B80200007800093F8C@nat28.tlf.novell.com>
	<CAOvdn6XKHfete_+=Hkvt20G7_cJ-4i8+9j9YD30OxzQ16Ru-+g@mail.gmail.com>
	<5024CB720200007800094124@nat28.tlf.novell.com>
	<CAOvdn6VVJdhWVYa-gNVt3euE4AbGi1TijUCUd1wGzv0SCWEUYA@mail.gmail.com>
	<CAOvdn6USnG9Y4MNBhrDZmob0oJ8BgFfKTvFEhcKbXDxNmzfZ-Q@mail.gmail.com>
	<502B75BA0200007800094FD4@nat28.tlf.novell.com>
	<CAOvdn6Ww5oEj6Xg=XT4dWCYWUBuOdPqLz-CqNjz4HmCScE+==g@mail.gmail.com>
	<CAOvdn6Wsjds_dmZ0dwDTYmD-o-OqjBH5-b9mitAuUADE+A4_ag@mail.gmail.com>
	<502BB8FD02000078000951E0@nat28.tlf.novell.com>
	<CAOvdn6VD6bp13F-tvYdkBsj4hkhE7PTGZrapndtdHrDKeZqccg@mail.gmail.com>
	<502CCC0002000078000955C4@nat28.tlf.novell.com>
	<CAOvdn6VEuX7R2_wz74ZvCxMjC-=YUir9kP5sdxEVaKVspRUd_w@mail.gmail.com>
	<502CF0A8020000780009574E@nat28.tlf.novell.com>
	<CAOvdn6VsZvn_1TCWYeuyY5YuTcP8=miK2KwE4583nsj6Qjb_vg@mail.gmail.com>
	<504494FB0200007800098398@nat28.tlf.novell.com>
	<CAOvdn6UT13qvWbMyfZkWND03RoVKVSgb6wW4yqTUpuBYEX01Dg@mail.gmail.com>
	<5048958D02000078000993EB@nat28.tlf.novell.com>
	<CAOvdn6WrNK1Jn_Y_P7C3AwX6ApVcgzacLA_x-u=xBQtebnuPxA@mail.gmail.com>
	<CAOvdn6U_Z=KdEo56nqe7jN54BwiesRJqDOz_VzVNpkWGfFRd2A@mail.gmail.com>
	<5049CEAE0200007800099A33@nat28.tlf.novell.com>
	<CAOvdn6XmsEfs+aO7nqBHdA61HpT_n_8W95u0MMq5J21tZCFbzw@mail.gmail.com>
	<5049F37A0200007800099BDA@nat28.tlf.novell.com>
	<CAOvdn6W+=OYTH3xTWBxUB8f_2tuZYKPTo-eJG0jfkaJ2rVutCA@mail.gmail.com>
	<504A024E0200007800099C5A@nat28.tlf.novell.com>
Date: Fri, 7 Sep 2012 12:06:18 -0400
X-Google-Sender-Auth: fO0IzPqnFV1kpUneurX_VloSArc
Message-ID: <CAOvdn6XYjyYEgtrPskjCLK4BZWaPyriNGSVGzumdOP8-6=P_=Q@mail.gmail.com>
From: Ben Guthro <ben@guthro.net>
To: Jan Beulich <JBeulich@suse.com>
Content-Type: multipart/mixed; boundary=e89a8f5034fece607604c91ec930
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>, john.baboval@citrix.com,
	Thomas Goetz <thomas.goetz@citrix.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen4.2 S3 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>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--e89a8f5034fece607604c91ec930
Content-Type: text/plain; charset=ISO-8859-1

I'll work on getting a JTAG, ICE, or something else - it is on an
Intel SDP - so it should have the ports for it.

My current suspicion on this is that the hardware registers are not
being programmed the same way as they were in 4.0.x
(Since the "pulsing power button LED" on the laptops, and the behavior
of the Desktop SDP are now similar)

Once again - I don't have a lot of evidence to back this up - however,
if I ifdef out the register writes that actually start the low level
suspend - in
xen/arch/x86/acpi/power.c  acpi_enter_sleep_state() - the rest of the
suspend process completes as though the machine suspended, and then
immediately resumed.

In this case - the system seems to be functioning properly.





Hack to prevent low level S3 attached.



On Fri, Sep 7, 2012 at 8:18 AM, Jan Beulich <JBeulich@suse.com> wrote:
>>>> On 07.09.12 at 13:51, Ben Guthro <ben@guthro.net> wrote:
>> However, when I run with console=none, the observed behavior is very
>> different.
>> The system seems to go to sleep successfully - but when I press the
>> power button to wake it up - the power comes on - the fans spin up -
>> but the system is unresponsive.
>> No video
>> No network
>> keyboard LEDs (Caps,Numlock) do not light up.
>>
>>
>> Alternate debugging strategies welcome.
>
> I'm afraid other than being lucky to spot something via code
> inspection, the only alternative is an ITP/ICE. Maybe Intel folks
> could help out debugging this if it's reproducible for them.
>
> Jan
>

--e89a8f5034fece607604c91ec930
Content-Type: application/octet-stream; name="prevent-s3-lowlevel.patch"
Content-Disposition: attachment; filename="prevent-s3-lowlevel.patch"
Content-Transfer-Encoding: base64
X-Attachment-Id: f_h6th8imm0

ZGlmZiAtLWdpdCBhL3hlbi9hcmNoL3g4Ni9hY3BpL3Bvd2VyLmMgYi94ZW4vYXJjaC94ODYvYWNw
aS9wb3dlci5jCmluZGV4IGRlODZjNDYuLjkyMzFiNDggMTAwNjQ0Ci0tLSBhL3hlbi9hcmNoL3g4
Ni9hY3BpL3Bvd2VyLmMKKysrIGIveGVuL2FyY2gveDg2L2FjcGkvcG93ZXIuYwpAQCAtMjUzLDYg
KzI1Myw3IEBAIGludCBhY3BpX2VudGVyX3NsZWVwKHN0cnVjdCB4ZW5wZl9lbnRlcl9hY3BpX3Ns
ZWVwICpzbGVlcCkKICAgICByZXR1cm4gY29udGludWVfaHlwZXJjYWxsX29uX2NwdSgwLCBlbnRl
cl9zdGF0ZV9oZWxwZXIsICZhY3BpX3NpbmZvKTsKIH0KIAorI2lmIDAKIHN0YXRpYyBpbnQgYWNw
aV9nZXRfd2FrZV9zdGF0dXModm9pZCkKIHsKICAgICB1aW50MzJfdCB2YWw7CkBAIC0yNjcsNiAr
MjY4LDcgQEAgc3RhdGljIGludCBhY3BpX2dldF93YWtlX3N0YXR1cyh2b2lkKQogICAgIHZhbCA+
Pj0gQUNQSV9CSVRQT1NJVElPTl9XQUtFX1NUQVRVUzsKICAgICByZXR1cm4gdmFsOwogfQorI2Vu
ZGlmCiAKIHN0YXRpYyB2b2lkIHRib290X3NsZWVwKHU4IHNsZWVwX3N0YXRlKQogewpAQCAtMzE2
LDcgKzMxOCw3IEBAIHN0YXRpYyB2b2lkIHRib290X3NsZWVwKHU4IHNsZWVwX3N0YXRlKQogLyog
U3lzdGVtIGlzIHJlYWxseSBwdXQgaW50byBzbGVlcCBzdGF0ZSBieSB0aGlzIHN0dWIgKi8KIGFj
cGlfc3RhdHVzIGFjcGlfZW50ZXJfc2xlZXBfc3RhdGUodTggc2xlZXBfc3RhdGUpCiB7Ci0gICAg
YWNwaV9zdGF0dXMgc3RhdHVzOworICAgIC8qIGFjcGlfc3RhdHVzIHN0YXR1czsgKi8KIAogICAg
IGlmICggdGJvb3RfaW5fbWVhc3VyZWRfZW52KCkgKQogICAgIHsKQEAgLTMyNiw3ICszMjgsNyBA
QCBhY3BpX3N0YXR1cyBhY3BpX2VudGVyX3NsZWVwX3N0YXRlKHU4IHNsZWVwX3N0YXRlKQogICAg
IH0KIAogICAgIEFDUElfRkxVU0hfQ1BVX0NBQ0hFKCk7Ci0KKyNpZiAwCiAgICAgc3RhdHVzID0g
YWNwaV9od19yZWdpc3Rlcl93cml0ZShBQ1BJX1JFR0lTVEVSX1BNMUFfQ09OVFJPTCwgCiAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBhY3BpX3NpbmZvLnBtMWFfY250X3ZhbCk7
CiAgICAgaWYgKCBBQ1BJX0ZBSUxVUkUoc3RhdHVzKSApCkBAIC0zNDMsNyArMzQ1LDcgQEAgYWNw
aV9zdGF0dXMgYWNwaV9lbnRlcl9zbGVlcF9zdGF0ZSh1OCBzbGVlcF9zdGF0ZSkKICAgICAvKiBX
YWl0IHVudGlsIHdlIGVudGVyIHNsZWVwIHN0YXRlLCBhbmQgc3BpbiB1bnRpbCB3ZSB3YWtlICov
CiAgICAgd2hpbGUgKCAhYWNwaV9nZXRfd2FrZV9zdGF0dXMoKSApCiAgICAgICAgIGNvbnRpbnVl
OwotCisjZW5kaWYKICAgICByZXR1cm5fQUNQSV9TVEFUVVMoQUVfT0spOwogfQogCg==
--e89a8f5034fece607604c91ec930
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--e89a8f5034fece607604c91ec930--


From xen-devel-bounces@lists.xen.org Fri Sep 07 16:14:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Sep 2012 16: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 1TA1Bx-0007bj-Ta; Fri, 07 Sep 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 <stefan.bader@canonical.com>) id 1TA1Bx-0007bW-49
	for xen-devel@lists.xen.org; Fri, 07 Sep 2012 16:14:01 +0000
Received: from [85.158.143.99:38421] by server-3.bemta-4.messagelabs.com id
	90/8E-08232-84D1A405; Fri, 07 Sep 2012 16:14:00 +0000
X-Env-Sender: stefan.bader@canonical.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1347034439!21632987!1
X-Originating-IP: [91.189.89.112]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30531 invoked from network); 7 Sep 2012 16:13:59 -0000
Received: from youngberry.canonical.com (HELO youngberry.canonical.com)
	(91.189.89.112) by server-11.tower-216.messagelabs.com with SMTP;
	7 Sep 2012 16:13:59 -0000
Received: from p5b2e2384.dip.t-dialin.net ([91.46.35.132] 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 1TA1Bs-0007ZL-RS; Fri, 07 Sep 2012 16:13:56 +0000
Message-ID: <504A1D43.2050909@canonical.com>
Date: Fri, 07 Sep 2012 18:13:55 +0200
From: Stefan Bader <stefan.bader@canonical.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120827 Thunderbird/15.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <1347018043-21252-1-git-send-email-stefan.bader@canonical.com>
	<504A05B00200007800099C7B@nat28.tlf.novell.com>
	<5049F4E9.9050306@canonical.com>
	<504A1A950200007800099D4C@nat28.tlf.novell.com>
	<20120907142251.GA20096@linuxtx.org>
	<504A32800200007800099E40@nat28.tlf.novell.com>
	<504A172B.5020005@canonical.com>
	<504A347B0200007800099E92@nat28.tlf.novell.com>
In-Reply-To: <504A347B0200007800099E92@nat28.tlf.novell.com>
X-Enigmail-Version: 1.4.4
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"Justin M. Forbes" <jmforbes@linuxtx.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Matt Wilson <msw@amazon.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH/RFC] Fix xsave bug on older Xen hypervisors
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1202760482856868663=="
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)
--===============1202760482856868663==
Content-Type: multipart/signed; micalg=pgp-sha512;
 protocol="application/pgp-signature";
 boundary="------------enig702662897FA34D13DEE46969"

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig702662897FA34D13DEE46969
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On 07.09.2012 17:52, Jan Beulich wrote:
>>>> On 07.09.12 at 17:47, Stefan Bader <stefan.bader@canonical.com> wrot=
e:
>> On 07.09.2012 17:44, Jan Beulich wrote:
>>> All of this still doesn't provide evidence that a plain upstream
>>> kernel is actually having any problems in the first place. Further,
>>> if you say EC2 has a crippled hypervisor patch - is that patch
>>> available for looking at somewhere?
>>
>> It was not a hypervisor patch. It was one for the guest. This was the =
hack:
>=20
> So then why do you want to patch the upstream kernel? It won't
> make that hack go away, nor will it help any existing kernels.
>=20
> Jan
>=20

It would not make it go away automatically, but whoever uses it could dro=
p it.
It was unpatched upstream kernels that would have the problem. However, w=
hile
reading again through all the changelogs I noticed

commit 61f4237d5b005767a76f4f3694e68e6f78f392d9
Author: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
Date:   Sat Sep 18 22:25:30 2010 -0700

    xen: just completely disable XSAVE

    Some (old) versions of Xen just kill the domain if it tries to set an=
y
    unknown bits in CR4, so we can't reliably probe for OSXSAVE in
    CR4.

    Since Xen doesn't support XSAVE for guests at the moment, and no such=

    support is being worked on, there's no downside in just unconditional=
ly
    masking XSAVE support.

    Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
    Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

So until then the write to CR4 was deliberately done to probe the feature=
=2E This
was changed by

commit 947ccf9c3c30307b774af3666ee74fcd9f47f646
Author: Shan Haitao <haitao.shan@intel.com>
Date:   Tue Nov 9 11:43:36 2010 -0800

    xen: Allow PV-OPS kernel to detect whether XSAVE is supported

    Xen fails to mask XSAVE from the cpuid feature, despite not historica=
lly
    supporting guest use of XSAVE.  However, now that XSAVE support has b=
een
    added to Xen, we need to reliably detect its presence.

    The most reliable way to do this is to look at the OSXSAVE feature in=

    cpuid which is set iff the OS (Xen, in this case), has set
    CR4.OSXSAVE.

    [ Cleaned up conditional a bit. - Jeremy ]

    Signed-off-by: Shan Haitao <haitao.shan@intel.com>
    Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
    Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

This would make it save again _if_ the HV failing to handle the writes to=
 CR4
(which iirc the kernel code still does when the cpuid bit is set) does ha=
ve at
least the patch to mask off the cpuid bits (the one Ian mentioned)

Probably a lot of hand wavy iffs... :/


--------------enig702662897FA34D13DEE46969
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://www.enigmail.net/

iQIcBAEBCgAGBQJQSh1DAAoJEOhnXe7L7s6jHgIQAI2CnLJw/evY3fpxZiEi6FKE
fH9jRgbMI9EXuLIAgP4nuYpU0tnNQ0N13dhWpq8A88Qj1+YhY0IyqqBM5JUarWBn
DHWDTmMhnnQQrl+B09gfKX2izFZTrovD+eF0OJo/TTdG7CvZ4J0CC16JiUxRGymp
GN0+dv9aac75keFKq63OlRkhYXwCl7f8BzCJpDAymHWK64ASn0sJXra3msx/Sjra
kKTP1kPyEf9c1BTGRqVQBsaPrX7dhluGGa0cMH5sJa0SR3FyE3nNes5/EcIUqaXr
EZ0pjKXWZOD3vHWwk3/0alJ/+ahIUX2NGp1wpuXAvXLd61uTRHWZpJjdmUC/ljL/
G6dhXj2PIgjgLkiKto/RedrYs9Ma13ZU37ADfkgLh4aMwcD1BsYNN2WhVtKag6IS
NCE9JoMx6BGrZuY0RDo7l30sqjwZxwULMEmH0YUHnfoBJp+M1N11kbSznOhQ7C3t
EDXi1x+Lvd+Inv6NqteBUuEG1f2G0GjiPFjTtajh4Fu9lybxzdFbnylLw8eJdl1Q
HN4e102qfRXnkDe+ENUSbQJ9x5VnG3Bzmy1GuTmXcxO7aqVTyQX0dN9XRgFMQRkc
QFfCa2bM9svxc1w5psYufa6xZHC3PQCt6FxAInukfIrGs+iIyx4JaXCjdE9Lr1GG
lY8VQ6H+cEP3XT6OOKPa
=lva4
-----END PGP SIGNATURE-----

--------------enig702662897FA34D13DEE46969--


--===============1202760482856868663==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============1202760482856868663==--


From xen-devel-bounces@lists.xen.org Fri Sep 07 16:14:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Sep 2012 16: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 1TA1Bx-0007bj-Ta; Fri, 07 Sep 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 <stefan.bader@canonical.com>) id 1TA1Bx-0007bW-49
	for xen-devel@lists.xen.org; Fri, 07 Sep 2012 16:14:01 +0000
Received: from [85.158.143.99:38421] by server-3.bemta-4.messagelabs.com id
	90/8E-08232-84D1A405; Fri, 07 Sep 2012 16:14:00 +0000
X-Env-Sender: stefan.bader@canonical.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1347034439!21632987!1
X-Originating-IP: [91.189.89.112]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30531 invoked from network); 7 Sep 2012 16:13:59 -0000
Received: from youngberry.canonical.com (HELO youngberry.canonical.com)
	(91.189.89.112) by server-11.tower-216.messagelabs.com with SMTP;
	7 Sep 2012 16:13:59 -0000
Received: from p5b2e2384.dip.t-dialin.net ([91.46.35.132] 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 1TA1Bs-0007ZL-RS; Fri, 07 Sep 2012 16:13:56 +0000
Message-ID: <504A1D43.2050909@canonical.com>
Date: Fri, 07 Sep 2012 18:13:55 +0200
From: Stefan Bader <stefan.bader@canonical.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120827 Thunderbird/15.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <1347018043-21252-1-git-send-email-stefan.bader@canonical.com>
	<504A05B00200007800099C7B@nat28.tlf.novell.com>
	<5049F4E9.9050306@canonical.com>
	<504A1A950200007800099D4C@nat28.tlf.novell.com>
	<20120907142251.GA20096@linuxtx.org>
	<504A32800200007800099E40@nat28.tlf.novell.com>
	<504A172B.5020005@canonical.com>
	<504A347B0200007800099E92@nat28.tlf.novell.com>
In-Reply-To: <504A347B0200007800099E92@nat28.tlf.novell.com>
X-Enigmail-Version: 1.4.4
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"Justin M. Forbes" <jmforbes@linuxtx.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Matt Wilson <msw@amazon.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH/RFC] Fix xsave bug on older Xen hypervisors
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1202760482856868663=="
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)
--===============1202760482856868663==
Content-Type: multipart/signed; micalg=pgp-sha512;
 protocol="application/pgp-signature";
 boundary="------------enig702662897FA34D13DEE46969"

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig702662897FA34D13DEE46969
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On 07.09.2012 17:52, Jan Beulich wrote:
>>>> On 07.09.12 at 17:47, Stefan Bader <stefan.bader@canonical.com> wrot=
e:
>> On 07.09.2012 17:44, Jan Beulich wrote:
>>> All of this still doesn't provide evidence that a plain upstream
>>> kernel is actually having any problems in the first place. Further,
>>> if you say EC2 has a crippled hypervisor patch - is that patch
>>> available for looking at somewhere?
>>
>> It was not a hypervisor patch. It was one for the guest. This was the =
hack:
>=20
> So then why do you want to patch the upstream kernel? It won't
> make that hack go away, nor will it help any existing kernels.
>=20
> Jan
>=20

It would not make it go away automatically, but whoever uses it could dro=
p it.
It was unpatched upstream kernels that would have the problem. However, w=
hile
reading again through all the changelogs I noticed

commit 61f4237d5b005767a76f4f3694e68e6f78f392d9
Author: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
Date:   Sat Sep 18 22:25:30 2010 -0700

    xen: just completely disable XSAVE

    Some (old) versions of Xen just kill the domain if it tries to set an=
y
    unknown bits in CR4, so we can't reliably probe for OSXSAVE in
    CR4.

    Since Xen doesn't support XSAVE for guests at the moment, and no such=

    support is being worked on, there's no downside in just unconditional=
ly
    masking XSAVE support.

    Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
    Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

So until then the write to CR4 was deliberately done to probe the feature=
=2E This
was changed by

commit 947ccf9c3c30307b774af3666ee74fcd9f47f646
Author: Shan Haitao <haitao.shan@intel.com>
Date:   Tue Nov 9 11:43:36 2010 -0800

    xen: Allow PV-OPS kernel to detect whether XSAVE is supported

    Xen fails to mask XSAVE from the cpuid feature, despite not historica=
lly
    supporting guest use of XSAVE.  However, now that XSAVE support has b=
een
    added to Xen, we need to reliably detect its presence.

    The most reliable way to do this is to look at the OSXSAVE feature in=

    cpuid which is set iff the OS (Xen, in this case), has set
    CR4.OSXSAVE.

    [ Cleaned up conditional a bit. - Jeremy ]

    Signed-off-by: Shan Haitao <haitao.shan@intel.com>
    Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
    Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

This would make it save again _if_ the HV failing to handle the writes to=
 CR4
(which iirc the kernel code still does when the cpuid bit is set) does ha=
ve at
least the patch to mask off the cpuid bits (the one Ian mentioned)

Probably a lot of hand wavy iffs... :/


--------------enig702662897FA34D13DEE46969
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://www.enigmail.net/

iQIcBAEBCgAGBQJQSh1DAAoJEOhnXe7L7s6jHgIQAI2CnLJw/evY3fpxZiEi6FKE
fH9jRgbMI9EXuLIAgP4nuYpU0tnNQ0N13dhWpq8A88Qj1+YhY0IyqqBM5JUarWBn
DHWDTmMhnnQQrl+B09gfKX2izFZTrovD+eF0OJo/TTdG7CvZ4J0CC16JiUxRGymp
GN0+dv9aac75keFKq63OlRkhYXwCl7f8BzCJpDAymHWK64ASn0sJXra3msx/Sjra
kKTP1kPyEf9c1BTGRqVQBsaPrX7dhluGGa0cMH5sJa0SR3FyE3nNes5/EcIUqaXr
EZ0pjKXWZOD3vHWwk3/0alJ/+ahIUX2NGp1wpuXAvXLd61uTRHWZpJjdmUC/ljL/
G6dhXj2PIgjgLkiKto/RedrYs9Ma13ZU37ADfkgLh4aMwcD1BsYNN2WhVtKag6IS
NCE9JoMx6BGrZuY0RDo7l30sqjwZxwULMEmH0YUHnfoBJp+M1N11kbSznOhQ7C3t
EDXi1x+Lvd+Inv6NqteBUuEG1f2G0GjiPFjTtajh4Fu9lybxzdFbnylLw8eJdl1Q
HN4e102qfRXnkDe+ENUSbQJ9x5VnG3Bzmy1GuTmXcxO7aqVTyQX0dN9XRgFMQRkc
QFfCa2bM9svxc1w5psYufa6xZHC3PQCt6FxAInukfIrGs+iIyx4JaXCjdE9Lr1GG
lY8VQ6H+cEP3XT6OOKPa
=lva4
-----END PGP SIGNATURE-----

--------------enig702662897FA34D13DEE46969--


--===============1202760482856868663==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============1202760482856868663==--


From xen-devel-bounces@lists.xen.org Fri Sep 07 16:14:55 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Sep 2012 16:14: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 1TA1Ce-0007go-JE; Fri, 07 Sep 2012 16:14:44 +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 1TA1Cc-0007gd-Il
	for xen-devel@lists.xen.org; Fri, 07 Sep 2012 16:14:42 +0000
Received: from [85.158.138.51:37508] by server-3.bemta-3.messagelabs.com id
	9D/7F-21322-17D1A405; Fri, 07 Sep 2012 16:14:41 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-15.tower-174.messagelabs.com!1347034481!27548376!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiA0MjAxNDM=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiA0MjAxNDM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17020 invoked from network); 7 Sep 2012 16:14:41 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-15.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 7 Sep 2012 16:14:41 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/lr0M7qFlg=
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-069-014.pools.arcor-ip.net [84.57.69.14])
	by smtp.strato.de (jorabe mo29) (RZmta 30.14 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id u071f3o87FwVHD ;
	Fri, 7 Sep 2012 18:14:41 +0200 (CEST)
Received: by probook.site (Postfix, from userid 1000)
	id 5CA5B183AD; Fri,  7 Sep 2012 18:14:40 +0200 (CEST)
Date: Fri, 7 Sep 2012 18:14:40 +0200
From: Olaf Hering <olaf@aepfle.de>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120907161440.GA30695@aepfle.de>
References: <b088e473c7fb1a47b957.1346142770@probook.site>
	<1347033936.30018.134.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1347033936.30018.134.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.5.21.rev5555 (2012-07-20)
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] xenpaging: use poll timeout if no paging
 target 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, Sep 07, Ian Campbell wrote:

> > +    /* Use a poll timeout until xenpaging got a target from xenstore */
> > +    paging->use_poll_timeout = 1;
> 
> Don't you want a negative (== infinite) timeout in this case?

Maybe, but this change is the simplest fix for the isse.
Waiting forever may have bad side effects, this is something to consider
for 4.3.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 07 16:14:55 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Sep 2012 16:14: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 1TA1Ce-0007go-JE; Fri, 07 Sep 2012 16:14:44 +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 1TA1Cc-0007gd-Il
	for xen-devel@lists.xen.org; Fri, 07 Sep 2012 16:14:42 +0000
Received: from [85.158.138.51:37508] by server-3.bemta-3.messagelabs.com id
	9D/7F-21322-17D1A405; Fri, 07 Sep 2012 16:14:41 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-15.tower-174.messagelabs.com!1347034481!27548376!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiA0MjAxNDM=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiA0MjAxNDM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17020 invoked from network); 7 Sep 2012 16:14:41 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-15.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 7 Sep 2012 16:14:41 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/lr0M7qFlg=
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-069-014.pools.arcor-ip.net [84.57.69.14])
	by smtp.strato.de (jorabe mo29) (RZmta 30.14 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id u071f3o87FwVHD ;
	Fri, 7 Sep 2012 18:14:41 +0200 (CEST)
Received: by probook.site (Postfix, from userid 1000)
	id 5CA5B183AD; Fri,  7 Sep 2012 18:14:40 +0200 (CEST)
Date: Fri, 7 Sep 2012 18:14:40 +0200
From: Olaf Hering <olaf@aepfle.de>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120907161440.GA30695@aepfle.de>
References: <b088e473c7fb1a47b957.1346142770@probook.site>
	<1347033936.30018.134.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1347033936.30018.134.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.5.21.rev5555 (2012-07-20)
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] xenpaging: use poll timeout if no paging
 target 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, Sep 07, Ian Campbell wrote:

> > +    /* Use a poll timeout until xenpaging got a target from xenstore */
> > +    paging->use_poll_timeout = 1;
> 
> Don't you want a negative (== infinite) timeout in this case?

Maybe, but this change is the simplest fix for the isse.
Waiting forever may have bad side effects, this is something to consider
for 4.3.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 07 17:09:27 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Sep 2012 17: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 1TA238-00004y-2u; Fri, 07 Sep 2012 17:08:58 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1TA237-00004t-6M
	for xen-devel@lists.xensource.com; Fri, 07 Sep 2012 17:08:57 +0000
Received: from [85.158.139.83:31556] by server-9.bemta-5.messagelabs.com id
	A2/3A-20529-82A2A405; Fri, 07 Sep 2012 17:08:56 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1347037735!22009201!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTIyMTE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16114 invoked from network); 7 Sep 2012 17:08:55 -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 Sep 2012 17:08:55 -0000
X-IronPort-AV: E=Sophos;i="4.80,387,1344211200"; d="scan'208";a="14415729"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Sep 2012 17:08: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.279.1; Fri, 7 Sep 2012 18:08: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 1TA234-0006Dp-Pn;
	Fri, 07 Sep 2012 17:08:54 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1TA234-0005jq-KO;
	Fri, 07 Sep 2012 18:08:54 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-13661-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 7 Sep 2012 18:08:54 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13661: 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 13661 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13661/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore            fail   like 13660
 test-i386-i386-xl-qemuu-winxpsp3  9 guest-localmigrate         fail like 13660
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail like 13660
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail like 13660

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-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
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass

version targeted for testing:
 xen                  a64f4e107951
baseline version:
 xen                  ec23c2a11f6f

------------------------------------------------------------
People who touched revisions under test:
  Ian Jackson <ian.jackson@eu.citrix.com>
  Keir Fraser <keir@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                                 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                                     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=a64f4e107951
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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 a64f4e107951
+ branch=xen-unstable
+ revision=a64f4e107951
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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 a64f4e107951 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 Fri Sep 07 17:09:27 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Sep 2012 17: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 1TA238-00004y-2u; Fri, 07 Sep 2012 17:08:58 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1TA237-00004t-6M
	for xen-devel@lists.xensource.com; Fri, 07 Sep 2012 17:08:57 +0000
Received: from [85.158.139.83:31556] by server-9.bemta-5.messagelabs.com id
	A2/3A-20529-82A2A405; Fri, 07 Sep 2012 17:08:56 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1347037735!22009201!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTIyMTE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16114 invoked from network); 7 Sep 2012 17:08:55 -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 Sep 2012 17:08:55 -0000
X-IronPort-AV: E=Sophos;i="4.80,387,1344211200"; d="scan'208";a="14415729"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Sep 2012 17:08: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.279.1; Fri, 7 Sep 2012 18:08: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 1TA234-0006Dp-Pn;
	Fri, 07 Sep 2012 17:08:54 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1TA234-0005jq-KO;
	Fri, 07 Sep 2012 18:08:54 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-13661-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 7 Sep 2012 18:08:54 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13661: 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 13661 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13661/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore            fail   like 13660
 test-i386-i386-xl-qemuu-winxpsp3  9 guest-localmigrate         fail like 13660
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail like 13660
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail like 13660

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-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
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass

version targeted for testing:
 xen                  a64f4e107951
baseline version:
 xen                  ec23c2a11f6f

------------------------------------------------------------
People who touched revisions under test:
  Ian Jackson <ian.jackson@eu.citrix.com>
  Keir Fraser <keir@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                                 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                                     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=a64f4e107951
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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 a64f4e107951
+ branch=xen-unstable
+ revision=a64f4e107951
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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 a64f4e107951 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 Fri Sep 07 17:17:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Sep 2012 17:17:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TA2AT-0000Gb-21; Fri, 07 Sep 2012 17:16:33 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1TA2AR-0000GW-DB
	for xen-devel@lists.xen.org; Fri, 07 Sep 2012 17:16:31 +0000
Received: from [85.158.138.51:14416] by server-2.bemta-3.messagelabs.com id
	C4/CF-04862-EEB2A405; Fri, 07 Sep 2012 17:16:30 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-16.tower-174.messagelabs.com!1347038190!29238660!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=2.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiA0MjAxNDM=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiA0MjAxNDM=\n,SUBJECT_RANDOMQ,
	UPPERCASE_25_50
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24122 invoked from network); 7 Sep 2012 17:16:30 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-16.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 7 Sep 2012 17:16:30 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/lr0M7qFlg=
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-069-014.pools.arcor-ip.net [84.57.69.14])
	by smtp.strato.de (jored mo8) (RZmta 30.14 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id f02230o87FOq0T
	for <xen-devel@lists.xen.org>; Fri, 7 Sep 2012 19:16:29 +0200 (CEST)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id 23F2F183A5
	for <xen-devel@lists.xen.org>; Fri,  7 Sep 2012 19:16:29 +0200 (CEST)
MIME-Version: 1.0
X-Mercurial-Node: bfa53b123b12884aa564a47104ad1373d8d16157
Message-Id: <bfa53b123b12884aa564.1347038187@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Fri, 07 Sep 2012 19:16:27 +0200
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH] unmodified_drivers: handle IRQF_SAMPLE_RANDOM
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 1347038133 -7200
# Node ID bfa53b123b12884aa564a47104ad1373d8d16157
# Parent  bb85bbccb1c9d802c92dd3fe00841368966ff623
unmodified_drivers: handle IRQF_SAMPLE_RANDOM

The flag IRQF_SAMPLE_RANDOM was removed in 3.6-rc1. Add it only if it is
defined. An additional call to add_interrupt_randomness is appearently
not needed because its now called unconditionally in
handle_irq_event_percpu().

Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r bb85bbccb1c9 -r bfa53b123b12 unmodified_drivers/linux-2.6/platform-pci/evtchn.c
--- a/unmodified_drivers/linux-2.6/platform-pci/evtchn.c
+++ b/unmodified_drivers/linux-2.6/platform-pci/evtchn.c
@@ -350,7 +350,11 @@ int xen_irq_init(struct pci_dev *pdev)
 #if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,22)
 			   SA_SHIRQ | SA_SAMPLE_RANDOM | SA_INTERRUPT,
 #else
-			   IRQF_SHARED | IRQF_SAMPLE_RANDOM | IRQF_DISABLED,
+			   IRQF_SHARED |
+#ifdef IRQF_SAMPLE_RANDOM
+			   IRQF_SAMPLE_RANDOM |
+#endif
+			   IRQF_DISABLED,
 #endif
 			   "xen-platform-pci", pdev);
 }

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 07 17:17:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Sep 2012 17:17:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TA2AT-0000Gb-21; Fri, 07 Sep 2012 17:16:33 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1TA2AR-0000GW-DB
	for xen-devel@lists.xen.org; Fri, 07 Sep 2012 17:16:31 +0000
Received: from [85.158.138.51:14416] by server-2.bemta-3.messagelabs.com id
	C4/CF-04862-EEB2A405; Fri, 07 Sep 2012 17:16:30 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-16.tower-174.messagelabs.com!1347038190!29238660!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=2.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiA0MjAxNDM=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiA0MjAxNDM=\n,SUBJECT_RANDOMQ,
	UPPERCASE_25_50
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24122 invoked from network); 7 Sep 2012 17:16:30 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-16.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 7 Sep 2012 17:16:30 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/lr0M7qFlg=
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-069-014.pools.arcor-ip.net [84.57.69.14])
	by smtp.strato.de (jored mo8) (RZmta 30.14 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id f02230o87FOq0T
	for <xen-devel@lists.xen.org>; Fri, 7 Sep 2012 19:16:29 +0200 (CEST)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id 23F2F183A5
	for <xen-devel@lists.xen.org>; Fri,  7 Sep 2012 19:16:29 +0200 (CEST)
MIME-Version: 1.0
X-Mercurial-Node: bfa53b123b12884aa564a47104ad1373d8d16157
Message-Id: <bfa53b123b12884aa564.1347038187@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Fri, 07 Sep 2012 19:16:27 +0200
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH] unmodified_drivers: handle IRQF_SAMPLE_RANDOM
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 1347038133 -7200
# Node ID bfa53b123b12884aa564a47104ad1373d8d16157
# Parent  bb85bbccb1c9d802c92dd3fe00841368966ff623
unmodified_drivers: handle IRQF_SAMPLE_RANDOM

The flag IRQF_SAMPLE_RANDOM was removed in 3.6-rc1. Add it only if it is
defined. An additional call to add_interrupt_randomness is appearently
not needed because its now called unconditionally in
handle_irq_event_percpu().

Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r bb85bbccb1c9 -r bfa53b123b12 unmodified_drivers/linux-2.6/platform-pci/evtchn.c
--- a/unmodified_drivers/linux-2.6/platform-pci/evtchn.c
+++ b/unmodified_drivers/linux-2.6/platform-pci/evtchn.c
@@ -350,7 +350,11 @@ int xen_irq_init(struct pci_dev *pdev)
 #if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,22)
 			   SA_SHIRQ | SA_SAMPLE_RANDOM | SA_INTERRUPT,
 #else
-			   IRQF_SHARED | IRQF_SAMPLE_RANDOM | IRQF_DISABLED,
+			   IRQF_SHARED |
+#ifdef IRQF_SAMPLE_RANDOM
+			   IRQF_SAMPLE_RANDOM |
+#endif
+			   IRQF_DISABLED,
 #endif
 			   "xen-platform-pci", pdev);
 }

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 07 17:23:34 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Sep 2012 17:23:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TA2Gu-0000QV-SX; Fri, 07 Sep 2012 17:23:12 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <john.stultz@linaro.org>) id 1TA2Gt-0000QQ-50
	for xen-devel@lists.xensource.com; Fri, 07 Sep 2012 17:23:11 +0000
Received: from [85.158.139.83:30364] by server-10.bemta-5.messagelabs.com id
	13/B9-10969-E7D2A405; Fri, 07 Sep 2012 17:23:10 +0000
X-Env-Sender: john.stultz@linaro.org
X-Msg-Ref: server-16.tower-182.messagelabs.com!1347038588!21886495!1
X-Originating-IP: [32.97.182.137]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMzIuOTcuMTgyLjEzNyA9PiAzOTgyNDQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10402 invoked from network); 7 Sep 2012 17:23:09 -0000
Received: from e7.ny.us.ibm.com (HELO e7.ny.us.ibm.com) (32.97.182.137)
	by server-16.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 7 Sep 2012 17:23:09 -0000
Received: from /spool/local
	by e7.ny.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only!
	Violators will be prosecuted
	for <xen-devel@lists.xensource.com> from <john.stultz@linaro.org>;
	Fri, 7 Sep 2012 13:23:08 -0400
Received: from d01dlp02.pok.ibm.com (9.56.250.167)
	by e7.ny.us.ibm.com (192.168.1.107) with IBM ESMTP SMTP Gateway:
	Authorized Use Only! Violators will be prosecuted; 
	Fri, 7 Sep 2012 13:23:05 -0400
Received: from d01relay05.pok.ibm.com (d01relay05.pok.ibm.com [9.56.227.237])
	by d01dlp02.pok.ibm.com (Postfix) with ESMTP id 3E81E6E805E
	for <xen-devel@lists.xensource.com>;
	Fri,  7 Sep 2012 13:23:04 -0400 (EDT)
Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64])
	by d01relay05.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id
	q87HN3Xr157814
	for <xen-devel@lists.xensource.com>; Fri, 7 Sep 2012 13:23:04 -0400
Received: from d01av04.pok.ibm.com (loopback [127.0.0.1])
	by d01av04.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id
	q87HN2Cx027636
	for <xen-devel@lists.xensource.com>; Fri, 7 Sep 2012 13:23:03 -0400
Received: from [9.65.121.68] (sig-9-65-121-68.mts.ibm.com [9.65.121.68])
	by d01av04.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id
	q87HMxMs027218; Fri, 7 Sep 2012 13:23:00 -0400
Message-ID: <504A2D73.3010702@linaro.org>
Date: Fri, 07 Sep 2012 10:22:59 -0700
From: John Stultz <john.stultz@linaro.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120827 Thunderbird/15.0
MIME-Version: 1.0
To: Daniel Lezcano <daniel.lezcano@linaro.org>
References: <1343164349-28550-1-git-send-email-daniel.lezcano@linaro.org>
	<201209062204.11288.rjw@sisk.pl> <50490920.9070204@linaro.org>
	<201209062318.42874.rjw@sisk.pl> <504A02BD.4000805@linaro.org>
In-Reply-To: <504A02BD.4000805@linaro.org>
X-Content-Scanned: Fidelis XPS MAILER
x-cbid: 12090717-5806-0000-0000-0000194F770A
Cc: prarit@redhat.com, xen-devel@lists.xensource.com,
	linaro-dev@lists.linaro.org, Peter Zijlstra <a.p.zijlstra@chello.nl>,
	linux-pm@vger.kernel.org, Frederic Weisbecker <fweisbec@gmail.com>,
	richardcochran@gmail.com, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	"Rafael J. Wysocki" <rjw@sisk.pl>, linux-acpi@vger.kernel.org,
	Thomas Gleixner <tglx@linutronix.de>, mingo@kernel.org, lenb@kernel.org
Subject: Re: [Xen-devel] CONFIG_NO_HZ + CONFIG_CPU_IDLE freeze the system
 (Was Re: [PATCH] acpi : remove power from acpi_processor_cx structure)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 09/07/2012 07:20 AM, Daniel Lezcano wrote:
> On 09/06/2012 11:18 PM, Rafael J. Wysocki wrote:
>> On Thursday, September 06, 2012, Daniel Lezcano wrote:
>>> On 09/06/2012 10:04 PM, Rafael J. Wysocki wrote:
>>>> On Thursday, September 06, 2012, Daniel Lezcano wrote:
>>>>> On 09/06/2012 09:54 AM, Daniel Lezcano wrote:
>>>>> I fall into this issue because NETCONSOLE is set, disabling it allowed
>>>>> me to go further.
>>>>>
>>>>> Unfortunately I am facing to some random freeze on the system which
>>>>> seems to be related to CONFIG_NO_HZ=y and CONFIG_CPU_IDLE=y.
>>>>>
>>>>> Disabling one of them, make the freezes to disappear.
>>>>>
>>>>> Is it a known issue ?
>>>> Well, there are systems having problems with this configuration, but they
>>>> should be exceptional.  What system is that?
>>> It is a laptop T61p with a Core 2 Duo T9500. Nothing exceptional I
>>> believe. Maybe someone got the same issue ?
>> Is it a regression for you?
> Yes, I think so. The issue appears between v3.5 and v3.6-rc1.
>
> It is not easy to reproduce but after taking some time to dig, it seems
> to appear with this commit:
>
> 1e75fa8be9fb61e1af46b5b3b176347a4c958ca1 is the first bad commit
> commit 1e75fa8be9fb61e1af46b5b3b176347a4c958ca1
> Author: John Stultz <john.stultz@linaro.org>
> Date:   Fri Jul 13 01:21:53 2012 -0400
>
>      time: Condense timekeeper.xtime into xtime_sec
>
>      The timekeeper struct has a xtime_nsec, which keeps the
>      sub-nanosecond remainder.  This ends up being somewhat
>      duplicative of the timekeeper.xtime.tv_nsec value, and we
>      have to do extra work to keep them apart, copying the full
>      nsec portion out and back in over and over.
>
>      This patch simplifies some of the logic by taking the timekeeper
>      xtime value and splitting it into timekeeper.xtime_sec and
>      reuses the timekeeper.xtime_nsec for the sub-second portion
>      (stored in higher res shifted nanoseconds).
>
>      This simplifies some of the accumulation logic. And will
>      allow for more accurate timekeeping once the vsyscall code
>      is updated to use the shifted nanosecond remainder.
>
>      Signed-off-by: John Stultz <john.stultz@linaro.org>
>      Reviewed-by: Ingo Molnar <mingo@kernel.org>
>      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
>      Cc: Richard Cochran <richardcochran@gmail.com>
>      Cc: Prarit Bhargava <prarit@redhat.com>
>      Link:
> http://lkml.kernel.org/r/1342156917-25092-5-git-send-email-john.stultz@linaro.org
>      Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
>
> :040000 040000 4d6541ac1f6075d7adee1eef494b31a0cbda0934
> dc5708bc738af695f092bf822809b13a1da104b6 M	kernel
>
> How to reproduce: with a laptop T61p, with a Core 2 Duo. I boot the
> kernel in busybox and wait some minutes before writing something in the
> console. At this moment, nothing appears to the console but the
> characters are echo'ed several seconds later (could be 1, 5, or 10 secs
> or more).
>
> That happens when CONFIG_CPU_IDLE and CONFIG_NO_HZ are set. Disabling
> one of them, the issue does not appear.

Thanks for bisecting this down and the heads up!

Right off I can't see what might be causing this.  Bunch of questions:

Is this a 32 or 64 bit kernel?

By your description above, it sounds like the system is still 
functioning, but there's just a high latency for key-input. Is that right?

Are other things on the system happening slowly?

Does generating interrupts by hitting/holding down the ctrl key make the 
system respond faster?

Is there any dmesg output near when it occurs?

If you don't wait that minute after boot before typing anything, does it 
still trigger later? (or is it tied to early boot?)

On a whim, does the patch below avoid the problem?

thanks
-john

diff --git a/kernel/time/timekeeping.c b/kernel/time/timekeeping.c
index 34e5eac..2fa0e52 100644
--- a/kernel/time/timekeeping.c
+++ b/kernel/time/timekeeping.c
@@ -1179,6 +1179,7 @@ static void update_wall_time(void)
  	timekeeping_adjust(tk, offset);
  
  
+#if 0
  	/*
  	* Store only full nanoseconds into xtime_nsec after rounding
  	* it up and add the remainder to the error difference.
@@ -1192,6 +1193,7 @@ static void update_wall_time(void)
  	tk->xtime_nsec -= remainder;
  	tk->xtime_nsec += 1ULL << tk->shift;
  	tk->ntp_error += remainder << tk->ntp_error_shift;
+#endif
  
  	/*
  	 * Finally, make sure that after the rounding


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 07 17:23:34 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Sep 2012 17:23:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TA2Gu-0000QV-SX; Fri, 07 Sep 2012 17:23:12 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <john.stultz@linaro.org>) id 1TA2Gt-0000QQ-50
	for xen-devel@lists.xensource.com; Fri, 07 Sep 2012 17:23:11 +0000
Received: from [85.158.139.83:30364] by server-10.bemta-5.messagelabs.com id
	13/B9-10969-E7D2A405; Fri, 07 Sep 2012 17:23:10 +0000
X-Env-Sender: john.stultz@linaro.org
X-Msg-Ref: server-16.tower-182.messagelabs.com!1347038588!21886495!1
X-Originating-IP: [32.97.182.137]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMzIuOTcuMTgyLjEzNyA9PiAzOTgyNDQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10402 invoked from network); 7 Sep 2012 17:23:09 -0000
Received: from e7.ny.us.ibm.com (HELO e7.ny.us.ibm.com) (32.97.182.137)
	by server-16.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 7 Sep 2012 17:23:09 -0000
Received: from /spool/local
	by e7.ny.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only!
	Violators will be prosecuted
	for <xen-devel@lists.xensource.com> from <john.stultz@linaro.org>;
	Fri, 7 Sep 2012 13:23:08 -0400
Received: from d01dlp02.pok.ibm.com (9.56.250.167)
	by e7.ny.us.ibm.com (192.168.1.107) with IBM ESMTP SMTP Gateway:
	Authorized Use Only! Violators will be prosecuted; 
	Fri, 7 Sep 2012 13:23:05 -0400
Received: from d01relay05.pok.ibm.com (d01relay05.pok.ibm.com [9.56.227.237])
	by d01dlp02.pok.ibm.com (Postfix) with ESMTP id 3E81E6E805E
	for <xen-devel@lists.xensource.com>;
	Fri,  7 Sep 2012 13:23:04 -0400 (EDT)
Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64])
	by d01relay05.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id
	q87HN3Xr157814
	for <xen-devel@lists.xensource.com>; Fri, 7 Sep 2012 13:23:04 -0400
Received: from d01av04.pok.ibm.com (loopback [127.0.0.1])
	by d01av04.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id
	q87HN2Cx027636
	for <xen-devel@lists.xensource.com>; Fri, 7 Sep 2012 13:23:03 -0400
Received: from [9.65.121.68] (sig-9-65-121-68.mts.ibm.com [9.65.121.68])
	by d01av04.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id
	q87HMxMs027218; Fri, 7 Sep 2012 13:23:00 -0400
Message-ID: <504A2D73.3010702@linaro.org>
Date: Fri, 07 Sep 2012 10:22:59 -0700
From: John Stultz <john.stultz@linaro.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120827 Thunderbird/15.0
MIME-Version: 1.0
To: Daniel Lezcano <daniel.lezcano@linaro.org>
References: <1343164349-28550-1-git-send-email-daniel.lezcano@linaro.org>
	<201209062204.11288.rjw@sisk.pl> <50490920.9070204@linaro.org>
	<201209062318.42874.rjw@sisk.pl> <504A02BD.4000805@linaro.org>
In-Reply-To: <504A02BD.4000805@linaro.org>
X-Content-Scanned: Fidelis XPS MAILER
x-cbid: 12090717-5806-0000-0000-0000194F770A
Cc: prarit@redhat.com, xen-devel@lists.xensource.com,
	linaro-dev@lists.linaro.org, Peter Zijlstra <a.p.zijlstra@chello.nl>,
	linux-pm@vger.kernel.org, Frederic Weisbecker <fweisbec@gmail.com>,
	richardcochran@gmail.com, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	"Rafael J. Wysocki" <rjw@sisk.pl>, linux-acpi@vger.kernel.org,
	Thomas Gleixner <tglx@linutronix.de>, mingo@kernel.org, lenb@kernel.org
Subject: Re: [Xen-devel] CONFIG_NO_HZ + CONFIG_CPU_IDLE freeze the system
 (Was Re: [PATCH] acpi : remove power from acpi_processor_cx structure)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 09/07/2012 07:20 AM, Daniel Lezcano wrote:
> On 09/06/2012 11:18 PM, Rafael J. Wysocki wrote:
>> On Thursday, September 06, 2012, Daniel Lezcano wrote:
>>> On 09/06/2012 10:04 PM, Rafael J. Wysocki wrote:
>>>> On Thursday, September 06, 2012, Daniel Lezcano wrote:
>>>>> On 09/06/2012 09:54 AM, Daniel Lezcano wrote:
>>>>> I fall into this issue because NETCONSOLE is set, disabling it allowed
>>>>> me to go further.
>>>>>
>>>>> Unfortunately I am facing to some random freeze on the system which
>>>>> seems to be related to CONFIG_NO_HZ=y and CONFIG_CPU_IDLE=y.
>>>>>
>>>>> Disabling one of them, make the freezes to disappear.
>>>>>
>>>>> Is it a known issue ?
>>>> Well, there are systems having problems with this configuration, but they
>>>> should be exceptional.  What system is that?
>>> It is a laptop T61p with a Core 2 Duo T9500. Nothing exceptional I
>>> believe. Maybe someone got the same issue ?
>> Is it a regression for you?
> Yes, I think so. The issue appears between v3.5 and v3.6-rc1.
>
> It is not easy to reproduce but after taking some time to dig, it seems
> to appear with this commit:
>
> 1e75fa8be9fb61e1af46b5b3b176347a4c958ca1 is the first bad commit
> commit 1e75fa8be9fb61e1af46b5b3b176347a4c958ca1
> Author: John Stultz <john.stultz@linaro.org>
> Date:   Fri Jul 13 01:21:53 2012 -0400
>
>      time: Condense timekeeper.xtime into xtime_sec
>
>      The timekeeper struct has a xtime_nsec, which keeps the
>      sub-nanosecond remainder.  This ends up being somewhat
>      duplicative of the timekeeper.xtime.tv_nsec value, and we
>      have to do extra work to keep them apart, copying the full
>      nsec portion out and back in over and over.
>
>      This patch simplifies some of the logic by taking the timekeeper
>      xtime value and splitting it into timekeeper.xtime_sec and
>      reuses the timekeeper.xtime_nsec for the sub-second portion
>      (stored in higher res shifted nanoseconds).
>
>      This simplifies some of the accumulation logic. And will
>      allow for more accurate timekeeping once the vsyscall code
>      is updated to use the shifted nanosecond remainder.
>
>      Signed-off-by: John Stultz <john.stultz@linaro.org>
>      Reviewed-by: Ingo Molnar <mingo@kernel.org>
>      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
>      Cc: Richard Cochran <richardcochran@gmail.com>
>      Cc: Prarit Bhargava <prarit@redhat.com>
>      Link:
> http://lkml.kernel.org/r/1342156917-25092-5-git-send-email-john.stultz@linaro.org
>      Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
>
> :040000 040000 4d6541ac1f6075d7adee1eef494b31a0cbda0934
> dc5708bc738af695f092bf822809b13a1da104b6 M	kernel
>
> How to reproduce: with a laptop T61p, with a Core 2 Duo. I boot the
> kernel in busybox and wait some minutes before writing something in the
> console. At this moment, nothing appears to the console but the
> characters are echo'ed several seconds later (could be 1, 5, or 10 secs
> or more).
>
> That happens when CONFIG_CPU_IDLE and CONFIG_NO_HZ are set. Disabling
> one of them, the issue does not appear.

Thanks for bisecting this down and the heads up!

Right off I can't see what might be causing this.  Bunch of questions:

Is this a 32 or 64 bit kernel?

By your description above, it sounds like the system is still 
functioning, but there's just a high latency for key-input. Is that right?

Are other things on the system happening slowly?

Does generating interrupts by hitting/holding down the ctrl key make the 
system respond faster?

Is there any dmesg output near when it occurs?

If you don't wait that minute after boot before typing anything, does it 
still trigger later? (or is it tied to early boot?)

On a whim, does the patch below avoid the problem?

thanks
-john

diff --git a/kernel/time/timekeeping.c b/kernel/time/timekeeping.c
index 34e5eac..2fa0e52 100644
--- a/kernel/time/timekeeping.c
+++ b/kernel/time/timekeeping.c
@@ -1179,6 +1179,7 @@ static void update_wall_time(void)
  	timekeeping_adjust(tk, offset);
  
  
+#if 0
  	/*
  	* Store only full nanoseconds into xtime_nsec after rounding
  	* it up and add the remainder to the error difference.
@@ -1192,6 +1193,7 @@ static void update_wall_time(void)
  	tk->xtime_nsec -= remainder;
  	tk->xtime_nsec += 1ULL << tk->shift;
  	tk->ntp_error += remainder << tk->ntp_error_shift;
+#endif
  
  	/*
  	 * Finally, make sure that after the rounding


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 07 18:00:44 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Sep 2012 18:00:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TA2qr-0000vz-50; Fri, 07 Sep 2012 18:00:21 +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 1TA2qq-0000vu-5a
	for xen-devel@lists.xen.org; Fri, 07 Sep 2012 18:00:20 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1347040810!8662644!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzM0MTMw\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31349 invoked from network); 7 Sep 2012 18:00:11 -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 Sep 2012 18:00:11 -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 q87I00QF001275
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 7 Sep 2012 18:00:01 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q87HxxIg018805
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 7 Sep 2012 18:00:00 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
	q87Hxv6s023851; Fri, 7 Sep 2012 12:59:57 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 07 Sep 2012 10:59:57 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 7BB1B402E4; Fri,  7 Sep 2012 13:49:22 -0400 (EDT)
Date: Fri, 7 Sep 2012 13:49:22 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: "Duan, Ronghui" <ronghui.duan@intel.com>
Message-ID: <20120907174922.GA13040@phenom.dumpdata.com>
References: <A21691DE07B84740B5F0B81466D5148A23BCF1DF@SHSMSX102.ccr.corp.intel.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <A21691DE07B84740B5F0B81466D5148A23BCF1DF@SHSMSX102.ccr.corp.intel.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: "Stefano.Stabellini@eu.citrix.com" <Stefano.Stabellini@eu.citrix.com>,
	"Ian.Jackson@eu.citrix.com" <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [RFC v1 0/5] VBD: enlarge max segment per request
 in blkfront
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Aug 16, 2012 at 10:22:56AM +0000, Duan, Ronghui wrote:
> Hi, list.
> The max segments for request in VBD queue is 11, while for Linux OS/ other VMM, the parameter is set to 128 in default. This may be caused by the limited size of ring between Front/Back. So I guess whether we can put segment data into another ring and dynamic use them for the single request's need. Here is prototype which don't do much test, but it can work on Linux 64 bits 3.4.6 kernel. I can see the CPU% can be reduced to 1/3 compared to original in sequential test. But it bring some overhead which will make random IO's cpu utilization increase a little.
> 
> Here is a short version data use only 1K random read and 64K sequential read in direct mode. Testing a physical SSD disk as blkback in backend. CPU% is got form xentop.
> Read 1K random	IOPS	   Dom0 CPU	DomU CPU%
> 		W	52005.9	86.6	71
> 		W/O	52123.1	85.8	66.9

So I am getting some different numbers. I tried a simple 4K read:

[/dev/xvda1]
bssplit=4K
rw=read
direct=1
size=4g
ioengine=libaio
iodepth=64

And with your patch got:
  read : io=4096.0MB, bw=92606KB/s, iops=23151 , runt= 45292msec

without:
  read : io=4096.0MB, bw=145187KB/s, iops=36296 , runt= 28889msec


> 			
> Read 64K seq	BW MB/s	Dom0 CPU	DomU CPU%
> 	W	250		27.1	       10.6
> 	W/O	250		62.6	       31.1

Hadn't tried that yet.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 07 18:00:44 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Sep 2012 18:00:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TA2qr-0000vz-50; Fri, 07 Sep 2012 18:00:21 +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 1TA2qq-0000vu-5a
	for xen-devel@lists.xen.org; Fri, 07 Sep 2012 18:00:20 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1347040810!8662644!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzM0MTMw\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31349 invoked from network); 7 Sep 2012 18:00:11 -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 Sep 2012 18:00:11 -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 q87I00QF001275
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 7 Sep 2012 18:00:01 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q87HxxIg018805
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 7 Sep 2012 18:00:00 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
	q87Hxv6s023851; Fri, 7 Sep 2012 12:59:57 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 07 Sep 2012 10:59:57 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 7BB1B402E4; Fri,  7 Sep 2012 13:49:22 -0400 (EDT)
Date: Fri, 7 Sep 2012 13:49:22 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: "Duan, Ronghui" <ronghui.duan@intel.com>
Message-ID: <20120907174922.GA13040@phenom.dumpdata.com>
References: <A21691DE07B84740B5F0B81466D5148A23BCF1DF@SHSMSX102.ccr.corp.intel.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <A21691DE07B84740B5F0B81466D5148A23BCF1DF@SHSMSX102.ccr.corp.intel.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: "Stefano.Stabellini@eu.citrix.com" <Stefano.Stabellini@eu.citrix.com>,
	"Ian.Jackson@eu.citrix.com" <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [RFC v1 0/5] VBD: enlarge max segment per request
 in blkfront
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Aug 16, 2012 at 10:22:56AM +0000, Duan, Ronghui wrote:
> Hi, list.
> The max segments for request in VBD queue is 11, while for Linux OS/ other VMM, the parameter is set to 128 in default. This may be caused by the limited size of ring between Front/Back. So I guess whether we can put segment data into another ring and dynamic use them for the single request's need. Here is prototype which don't do much test, but it can work on Linux 64 bits 3.4.6 kernel. I can see the CPU% can be reduced to 1/3 compared to original in sequential test. But it bring some overhead which will make random IO's cpu utilization increase a little.
> 
> Here is a short version data use only 1K random read and 64K sequential read in direct mode. Testing a physical SSD disk as blkback in backend. CPU% is got form xentop.
> Read 1K random	IOPS	   Dom0 CPU	DomU CPU%
> 		W	52005.9	86.6	71
> 		W/O	52123.1	85.8	66.9

So I am getting some different numbers. I tried a simple 4K read:

[/dev/xvda1]
bssplit=4K
rw=read
direct=1
size=4g
ioengine=libaio
iodepth=64

And with your patch got:
  read : io=4096.0MB, bw=92606KB/s, iops=23151 , runt= 45292msec

without:
  read : io=4096.0MB, bw=145187KB/s, iops=36296 , runt= 28889msec


> 			
> Read 64K seq	BW MB/s	Dom0 CPU	DomU CPU%
> 	W	250		27.1	       10.6
> 	W/O	250		62.6	       31.1

Hadn't tried that yet.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 07 18:04:49 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Sep 2012 18: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 1TA2ui-0001Cx-QW; Fri, 07 Sep 2012 18:04:20 +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 1TA2uh-0001Cr-8K
	for xen-devel@lists.xen.org; Fri, 07 Sep 2012 18:04:19 +0000
Received: from [85.158.143.35:43594] by server-2.bemta-4.messagelabs.com id
	BE/E6-21239-2273A405; Fri, 07 Sep 2012 18:04:18 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1347041056!11691933!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNzc0ODA=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30349 invoked from network); 7 Sep 2012 18:04:17 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-10.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Sep 2012 18:04:17 -0000
X-IronPort-AV: E=Sophos;i="4.80,387,1344211200"; 
	d="log'?scan'208";a="207441108"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Sep 2012 18:04:15 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1;
	Fri, 7 Sep 2012 14:04:15 -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 1TA2ud-0001eQ-4p;
	Fri, 07 Sep 2012 19:04:15 +0100
Message-ID: <504A371F.7000808@citrix.com>
Date: Fri, 7 Sep 2012 19:04:15 +0100
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:14.0) Gecko/20120714 Thunderbird/14.0
MIME-Version: 1.0
To: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>, Keir Fraser
	<keir@xen.org>, Jan Beulich <jbeulich@suse.com>
X-Enigmail-Version: 1.4.4
Content-Type: multipart/mixed; boundary="------------040106020207030903020401"
Subject: [Xen-devel] Hypervisor memory leak/corruption because of guest 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>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--------------040106020207030903020401
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit

Hello,

I appear to have opened a can of worms here.  This was discovered when
turning on ASSERT()s, looking for another crash (and adding in 98 new
ASSERTs, along with some 'type checking' magic constants)

The issue has been discovered against Xen 4.1.3, but a cursory
inspection of unstable shows no signs of it being fixed. The relevant
assertion (which I added) is attached.  (In the process of debugging, I
also developed the ASSERT_PRINTK(bool, fmt, ...) macro which will be
upstreamed in due course.)

The root cause of the problem is the compelete abuse of the
irq_desc->action pointer being cast to a irq_guest_action_t* when
in-fact it is an irqaction*, but the (correct) solution is not easy.

destroy_irq() calls dynamic_irq_cleanup() which xfree()'s desc->action. 
This would be all well and fine if it were only an irqaction pointer. 
However, in this case, it is actually an irq_guest_action_t pointer,
meaning that we have free()'d an inactive timer, which is on a pcpu's
inactive timer linked list.  This means that as soon as the free()'d
memory is reused for something new, the linked list gets trashed, which
which point all bets are off with regards to the validity of hypervisor
memory.

As far as I can tell, this bug only manifests in combination with PCI
Passthrough, as we only perform cleanup of guest irqs when a domain with
passthrough is shut down.  The issue was first found by the ASSERT()s in
__list_del(), when something tried to use the pcpu inactive timer list,
after the free()'d memory was reused.

In this specific case, a quick and dirty hack would be to check every
time we free an action and possibly kill the timer if it is a guest irq.

Having said that, it is not a correct fix; the utter abuse of
irq_desc->action has been a ticking timebomb for a long time. 
irq_guest_action_t is private to the 2nd half of irq.c(x86), whereas
irqaction is common and architecture independent.  The only acceptable
solution I see is to re-architect a substantial proportion of the irq code.

Am I missing something obvious? or is the best way to continue (in which
case I have my work cut out as, it is currently affecting XenServer
customers) ?

-- 
Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
T: +44 (0)1223 225 900, http://www.citrix.com


--------------040106020207030903020401
Content-Type: text/x-log; name="hypervisor-panic.log"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="hypervisor-panic.log"

(XEN) [2012-09-07 11:35:18] Assertion '! (t->status == 1 || t->status == 3 || t->status == 4)' failed, line 229, file irq.c
(XEN) [2012-09-07 11:35:18] will free action with timer in status 1
(XEN) [2012-09-07 11:35:18] Xen BUG at irq.c:229
(XEN) [2012-09-07 11:35:18] ----[ Xen-4.1.3  x86_64  debug=n  Tainted:    C ]----
(XEN) [2012-09-07 11:35:18] CPU:    0
(XEN) [2012-09-07 11:35:18] RIP:    e008:[<ffff82c48016d89e>] destroy_irq+0x1ae/0x210
(XEN) [2012-09-07 11:35:18] RFLAGS: 0000000000010082   CONTEXT: hypervisor
(XEN) [2012-09-07 11:35:18] rax: 0000000000000000   rbx: ffff83083fe04800   rcx: 0000000000000000
(XEN) [2012-09-07 11:35:19] rdx: 000000000000000a   rsi: 000000000000000a   rdi: ffff82c4802662c4
(XEN) [2012-09-07 11:35:19] rbp: ffff830993cd77f0   rsp: ffff82c4802b7d88   r8:  0000000000000000
(XEN) [2012-09-07 11:35:19] r9:  0000000000000000   r10: 00000000ffffffff   r11: ffff82c480141560
(XEN) [2012-09-07 11:35:19] r12: 000000000000008f   r13: ffff83083fe04834   r14: 0000000000000286
(XEN) [2012-09-07 11:35:19] r15: ffff830993cd7810   cr0: 0000000080050033   cr4: 00000000000026f0
(XEN) [2012-09-07 11:35:19] cr3: 00000008369ae000   cr2: 00000000e9925e68
(XEN) [2012-09-07 11:35:19] ds: 007b   es: 007b   fs: 00d8   gs: 0033   ss: 0000   cs: e008
(XEN) [2012-09-07 11:35:19] Xen stack trace from rsp=ffff82c4802b7d88:
(XEN) [2012-09-07 11:35:19]    0000000000000000 ffff8303c40757d0 ffff830895660000 000000000000004f
(XEN) [2012-09-07 11:35:19]    ffff8303c40757d0 000000000000008f ffff83083fe04834 ffff82c480169647
(XEN) [2012-09-07 11:35:20]    ffff8303c40757d0 ffff830895660000 000000000000004f ffff83083fe04800
(XEN) [2012-09-07 11:35:20]    000000000000008f ffff82c48016e491 000000000000004f 000000000000013c
(XEN) [2012-09-07 11:35:20]    000000000000008f ffff830895660000 000000000000004f 000000000000013c
(XEN) [2012-09-07 11:35:20]    ffff830895660188 ffff82c4802d4600 0000000000000000 ffff82c48016e71a
(XEN) [2012-09-07 11:35:20]    ffff830895660000 ffff8300be6ac000 ffff830895660000 00000000ffffffff
(XEN) [2012-09-07 11:35:20]    ffff830895660000 ffff82c48015efb2 00000000ffffffff ffff8300be6ac000
(XEN) [2012-09-07 11:35:20]    fffffffffffffff8 ffff82c480104a80 ffff82c4802f4060 0000000000000000
(XEN) [2012-09-07 11:35:20]    0000000000000001 ffff82c4802f4320 ffff82c4802d0600 ffff82c480130191
(XEN) [2012-09-07 11:35:20]    0000000000000000 ffffffffffffffff ffff82c4802b7f18 ffff82c480126f85
(XEN) [2012-09-07 11:35:20]    ffff8300bf2d8000 00000000e98dde14 0000000000000000 0000000000000000
(XEN) [2012-09-07 11:35:21]    0000000000000000 ffff82c480223b26 0000000000000000 0000000000000000
(XEN) [2012-09-07 11:35:21]    0000000000000000 0000000000000000 00000000e98dde14 00000000e913584c
(XEN) [2012-09-07 11:35:21]    0000000000000000 0000000000000000 0000000000000000 0000000000000000
(XEN) [2012-09-07 11:35:21]    0000000000000008 00000000e9135878 0000000000000000 00000000e9135854
(XEN) [2012-09-07 11:35:21]    00000000e98ddec4 000000f900000000 00000000c01d68f9 0000000000000061
(XEN) [2012-09-07 11:35:21]    0000000000000202 00000000e98dde0c 0000000000000069 0000000000000000
(XEN) [2012-09-07 11:35:21]    0000000000000000 0000000000000000 0000000000000000 0000000000000000
(XEN) [2012-09-07 11:35:21]    ffff8300bf2d8000 0000000000000000 0000000000000000
(XEN) [2012-09-07 11:35:21] Xen call trace:
(XEN) [2012-09-07 11:35:21]       [<ffff82c48016d89e>] destroy_irq+0x1ae/0x210
(XEN) [2012-09-07 11:35:22]      7[<ffff82c480169647>] msi_free_irq+0x27/0x210
(XEN) [2012-09-07 11:35:22]     13[<ffff82c48016e491>] unmap_domain_pirq+0x181/0x3b0
(XEN) [2012-09-07 11:35:22]     23[<ffff82c48016e71a>] free_domain_pirqs+0x5a/0x90
(XEN) [2012-09-07 11:35:22]     29[<ffff82c48015efb2>] arch_domain_destroy+0x32/0x330
(XEN) [2012-09-07 11:35:22]     33[<ffff82c480104a80>] complete_domain_destroy+0x80/0x150
(XEN) [2012-09-07 11:35:22]     39[<ffff82c480130191>] rcu_process_callbacks+0xa1/0x200
(XEN) [2012-09-07 11:35:22]     43[<ffff82c480126f85>] __do_softirq+0x65/0x90
(XEN) [2012-09-07 11:35:22]     49[<ffff82c480223b26>] compat_process_softirqs+0x6/0x10
(XEN) [2012-09-07 11:35:22]    
(XEN) [2012-09-07 11:35:22] 
(XEN) [2012-09-07 11:35:22] ****************************************
(XEN) [2012-09-07 11:35:22] Panic on CPU 0:
(XEN) [2012-09-07 11:35:22] Xen BUG at irq.c:229
(XEN) [2012-09-07 11:35:22] ****************************************
(XEN) [2012-09-07 11:35:23] 
(XEN) [2012-09-07 11:35:23] Manual reset required ('noreboot' specified)

--------------040106020207030903020401
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--------------040106020207030903020401--


From xen-devel-bounces@lists.xen.org Fri Sep 07 18:04:49 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Sep 2012 18: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 1TA2ui-0001Cx-QW; Fri, 07 Sep 2012 18:04:20 +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 1TA2uh-0001Cr-8K
	for xen-devel@lists.xen.org; Fri, 07 Sep 2012 18:04:19 +0000
Received: from [85.158.143.35:43594] by server-2.bemta-4.messagelabs.com id
	BE/E6-21239-2273A405; Fri, 07 Sep 2012 18:04:18 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1347041056!11691933!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNzc0ODA=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30349 invoked from network); 7 Sep 2012 18:04:17 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-10.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Sep 2012 18:04:17 -0000
X-IronPort-AV: E=Sophos;i="4.80,387,1344211200"; 
	d="log'?scan'208";a="207441108"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Sep 2012 18:04:15 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1;
	Fri, 7 Sep 2012 14:04:15 -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 1TA2ud-0001eQ-4p;
	Fri, 07 Sep 2012 19:04:15 +0100
Message-ID: <504A371F.7000808@citrix.com>
Date: Fri, 7 Sep 2012 19:04:15 +0100
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:14.0) Gecko/20120714 Thunderbird/14.0
MIME-Version: 1.0
To: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>, Keir Fraser
	<keir@xen.org>, Jan Beulich <jbeulich@suse.com>
X-Enigmail-Version: 1.4.4
Content-Type: multipart/mixed; boundary="------------040106020207030903020401"
Subject: [Xen-devel] Hypervisor memory leak/corruption because of guest 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>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--------------040106020207030903020401
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit

Hello,

I appear to have opened a can of worms here.  This was discovered when
turning on ASSERT()s, looking for another crash (and adding in 98 new
ASSERTs, along with some 'type checking' magic constants)

The issue has been discovered against Xen 4.1.3, but a cursory
inspection of unstable shows no signs of it being fixed. The relevant
assertion (which I added) is attached.  (In the process of debugging, I
also developed the ASSERT_PRINTK(bool, fmt, ...) macro which will be
upstreamed in due course.)

The root cause of the problem is the compelete abuse of the
irq_desc->action pointer being cast to a irq_guest_action_t* when
in-fact it is an irqaction*, but the (correct) solution is not easy.

destroy_irq() calls dynamic_irq_cleanup() which xfree()'s desc->action. 
This would be all well and fine if it were only an irqaction pointer. 
However, in this case, it is actually an irq_guest_action_t pointer,
meaning that we have free()'d an inactive timer, which is on a pcpu's
inactive timer linked list.  This means that as soon as the free()'d
memory is reused for something new, the linked list gets trashed, which
which point all bets are off with regards to the validity of hypervisor
memory.

As far as I can tell, this bug only manifests in combination with PCI
Passthrough, as we only perform cleanup of guest irqs when a domain with
passthrough is shut down.  The issue was first found by the ASSERT()s in
__list_del(), when something tried to use the pcpu inactive timer list,
after the free()'d memory was reused.

In this specific case, a quick and dirty hack would be to check every
time we free an action and possibly kill the timer if it is a guest irq.

Having said that, it is not a correct fix; the utter abuse of
irq_desc->action has been a ticking timebomb for a long time. 
irq_guest_action_t is private to the 2nd half of irq.c(x86), whereas
irqaction is common and architecture independent.  The only acceptable
solution I see is to re-architect a substantial proportion of the irq code.

Am I missing something obvious? or is the best way to continue (in which
case I have my work cut out as, it is currently affecting XenServer
customers) ?

-- 
Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
T: +44 (0)1223 225 900, http://www.citrix.com


--------------040106020207030903020401
Content-Type: text/x-log; name="hypervisor-panic.log"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="hypervisor-panic.log"

(XEN) [2012-09-07 11:35:18] Assertion '! (t->status == 1 || t->status == 3 || t->status == 4)' failed, line 229, file irq.c
(XEN) [2012-09-07 11:35:18] will free action with timer in status 1
(XEN) [2012-09-07 11:35:18] Xen BUG at irq.c:229
(XEN) [2012-09-07 11:35:18] ----[ Xen-4.1.3  x86_64  debug=n  Tainted:    C ]----
(XEN) [2012-09-07 11:35:18] CPU:    0
(XEN) [2012-09-07 11:35:18] RIP:    e008:[<ffff82c48016d89e>] destroy_irq+0x1ae/0x210
(XEN) [2012-09-07 11:35:18] RFLAGS: 0000000000010082   CONTEXT: hypervisor
(XEN) [2012-09-07 11:35:18] rax: 0000000000000000   rbx: ffff83083fe04800   rcx: 0000000000000000
(XEN) [2012-09-07 11:35:19] rdx: 000000000000000a   rsi: 000000000000000a   rdi: ffff82c4802662c4
(XEN) [2012-09-07 11:35:19] rbp: ffff830993cd77f0   rsp: ffff82c4802b7d88   r8:  0000000000000000
(XEN) [2012-09-07 11:35:19] r9:  0000000000000000   r10: 00000000ffffffff   r11: ffff82c480141560
(XEN) [2012-09-07 11:35:19] r12: 000000000000008f   r13: ffff83083fe04834   r14: 0000000000000286
(XEN) [2012-09-07 11:35:19] r15: ffff830993cd7810   cr0: 0000000080050033   cr4: 00000000000026f0
(XEN) [2012-09-07 11:35:19] cr3: 00000008369ae000   cr2: 00000000e9925e68
(XEN) [2012-09-07 11:35:19] ds: 007b   es: 007b   fs: 00d8   gs: 0033   ss: 0000   cs: e008
(XEN) [2012-09-07 11:35:19] Xen stack trace from rsp=ffff82c4802b7d88:
(XEN) [2012-09-07 11:35:19]    0000000000000000 ffff8303c40757d0 ffff830895660000 000000000000004f
(XEN) [2012-09-07 11:35:19]    ffff8303c40757d0 000000000000008f ffff83083fe04834 ffff82c480169647
(XEN) [2012-09-07 11:35:20]    ffff8303c40757d0 ffff830895660000 000000000000004f ffff83083fe04800
(XEN) [2012-09-07 11:35:20]    000000000000008f ffff82c48016e491 000000000000004f 000000000000013c
(XEN) [2012-09-07 11:35:20]    000000000000008f ffff830895660000 000000000000004f 000000000000013c
(XEN) [2012-09-07 11:35:20]    ffff830895660188 ffff82c4802d4600 0000000000000000 ffff82c48016e71a
(XEN) [2012-09-07 11:35:20]    ffff830895660000 ffff8300be6ac000 ffff830895660000 00000000ffffffff
(XEN) [2012-09-07 11:35:20]    ffff830895660000 ffff82c48015efb2 00000000ffffffff ffff8300be6ac000
(XEN) [2012-09-07 11:35:20]    fffffffffffffff8 ffff82c480104a80 ffff82c4802f4060 0000000000000000
(XEN) [2012-09-07 11:35:20]    0000000000000001 ffff82c4802f4320 ffff82c4802d0600 ffff82c480130191
(XEN) [2012-09-07 11:35:20]    0000000000000000 ffffffffffffffff ffff82c4802b7f18 ffff82c480126f85
(XEN) [2012-09-07 11:35:20]    ffff8300bf2d8000 00000000e98dde14 0000000000000000 0000000000000000
(XEN) [2012-09-07 11:35:21]    0000000000000000 ffff82c480223b26 0000000000000000 0000000000000000
(XEN) [2012-09-07 11:35:21]    0000000000000000 0000000000000000 00000000e98dde14 00000000e913584c
(XEN) [2012-09-07 11:35:21]    0000000000000000 0000000000000000 0000000000000000 0000000000000000
(XEN) [2012-09-07 11:35:21]    0000000000000008 00000000e9135878 0000000000000000 00000000e9135854
(XEN) [2012-09-07 11:35:21]    00000000e98ddec4 000000f900000000 00000000c01d68f9 0000000000000061
(XEN) [2012-09-07 11:35:21]    0000000000000202 00000000e98dde0c 0000000000000069 0000000000000000
(XEN) [2012-09-07 11:35:21]    0000000000000000 0000000000000000 0000000000000000 0000000000000000
(XEN) [2012-09-07 11:35:21]    ffff8300bf2d8000 0000000000000000 0000000000000000
(XEN) [2012-09-07 11:35:21] Xen call trace:
(XEN) [2012-09-07 11:35:21]       [<ffff82c48016d89e>] destroy_irq+0x1ae/0x210
(XEN) [2012-09-07 11:35:22]      7[<ffff82c480169647>] msi_free_irq+0x27/0x210
(XEN) [2012-09-07 11:35:22]     13[<ffff82c48016e491>] unmap_domain_pirq+0x181/0x3b0
(XEN) [2012-09-07 11:35:22]     23[<ffff82c48016e71a>] free_domain_pirqs+0x5a/0x90
(XEN) [2012-09-07 11:35:22]     29[<ffff82c48015efb2>] arch_domain_destroy+0x32/0x330
(XEN) [2012-09-07 11:35:22]     33[<ffff82c480104a80>] complete_domain_destroy+0x80/0x150
(XEN) [2012-09-07 11:35:22]     39[<ffff82c480130191>] rcu_process_callbacks+0xa1/0x200
(XEN) [2012-09-07 11:35:22]     43[<ffff82c480126f85>] __do_softirq+0x65/0x90
(XEN) [2012-09-07 11:35:22]     49[<ffff82c480223b26>] compat_process_softirqs+0x6/0x10
(XEN) [2012-09-07 11:35:22]    
(XEN) [2012-09-07 11:35:22] 
(XEN) [2012-09-07 11:35:22] ****************************************
(XEN) [2012-09-07 11:35:22] Panic on CPU 0:
(XEN) [2012-09-07 11:35:22] Xen BUG at irq.c:229
(XEN) [2012-09-07 11:35:22] ****************************************
(XEN) [2012-09-07 11:35:23] 
(XEN) [2012-09-07 11:35:23] Manual reset required ('noreboot' specified)

--------------040106020207030903020401
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--------------040106020207030903020401--


From xen-devel-bounces@lists.xen.org Fri Sep 07 18:42:45 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Sep 2012 18:42:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TA3VS-0001d2-Bs; Fri, 07 Sep 2012 18:42:18 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1TA3VR-0001cx-1j
	for xen-devel@lists.xen.org; Fri, 07 Sep 2012 18:42:17 +0000
Received: from [85.158.139.83:16717] by server-4.bemta-5.messagelabs.com id
	92/2C-23042-8004A405; Fri, 07 Sep 2012 18:42:16 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1347043335!25290880!1
X-Originating-IP: [209.85.215.173]
X-SpamReason: No, hits=2.8 required=7.0 tests=BODY_RANDOM_LONG,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,SUBJECT_RANDOMQ,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17362 invoked from network); 7 Sep 2012 18:42:15 -0000
Received: from mail-ey0-f173.google.com (HELO mail-ey0-f173.google.com)
	(209.85.215.173)
	by server-7.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Sep 2012 18:42:15 -0000
Received: by eaac13 with SMTP id c13so1119314eaa.32
	for <xen-devel@lists.xen.org>; Fri, 07 Sep 2012 11:42:15 -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=n0kjEUYIRaQVCT4UQfqHoA2LU3X98g016OlpkFQFdgU=;
	b=lZ5YBnVvXeOgfRYaGZ7BiOCIFW6/0bGX3HkFezqp41iH5lrd3trdMAlcGkKi3mDpqY
	iUcNvkZFxbBSIUtfgkNtud86G92AN9d2tnupzNJlRoB5RRJsDNfVRSF6VyahvGGCI3gD
	/hoGsW2s1DTxGWiOtOzk6C3mas83ELSgDNZ13bF+cMn3HYYDjj5esYnPqV5IgzB3nTGm
	XcBeDVScXGE3NxLkz7kpUK68XSlmBK0KWhx8tSu+70znJnVCTYsy0bJRO6l/4C8C71Ms
	C29URIm/V+W3JtPMaP0e98B3YoNKlZXXq9FnlU9gIgJ+acm2r22b7B6xB4ksX9ZYnjeY
	mXRg==
Received: by 10.14.173.9 with SMTP id u9mr9483522eel.8.1347043335143;
	Fri, 07 Sep 2012 11:42:15 -0700 (PDT)
Received: from [192.168.1.69] (host86-184-74-117.range86-184.btcentralplus.com.
	[86.184.74.117])
	by mx.google.com with ESMTPS id z3sm16903985eel.15.2012.09.07.11.42.11
	(version=SSLv3 cipher=OTHER); Fri, 07 Sep 2012 11:42:14 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Fri, 07 Sep 2012 19:42:06 +0100
From: Keir Fraser <keir.xen@gmail.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Keir Fraser <keir@xen.org>, Jan Beulich <jbeulich@suse.com>
Message-ID: <CC6FFE8E.3E156%keir.xen@gmail.com>
Thread-Topic: Hypervisor memory leak/corruption because of guest irqs
Thread-Index: Ac2NKHqt7yYwI3nMgU6KA8ke66Xwjw==
In-Reply-To: <504A371F.7000808@citrix.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] Hypervisor memory leak/corruption because of guest
	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

Seems it means noone thought properly about teardown of guest-bound irqs.
Probably because a lot of that code was dumbly ported over from Linux later.

As for abuse of desc->action, you could turn that field explicitly into a
discriminated union; it is already precisely discriminated by
desc->status&IRQ_GUEST. Apart from that syntactic sugar, the idea of having
that pointer point at two different things dependent on irq type doesn't
seem ugly to me -- if it's irq-bound then it does not have, nor does it
need, an irqaction. But the irq_guest_action of course has to be dealt with
and your problem is that noone has thought about it!

 -- Keir

On 07/09/2012 19:04, "Andrew Cooper" <andrew.cooper3@citrix.com> wrote:

> Hello,
> 
> I appear to have opened a can of worms here.  This was discovered when
> turning on ASSERT()s, looking for another crash (and adding in 98 new
> ASSERTs, along with some 'type checking' magic constants)
> 
> The issue has been discovered against Xen 4.1.3, but a cursory
> inspection of unstable shows no signs of it being fixed. The relevant
> assertion (which I added) is attached.  (In the process of debugging, I
> also developed the ASSERT_PRINTK(bool, fmt, ...) macro which will be
> upstreamed in due course.)
> 
> The root cause of the problem is the compelete abuse of the
> irq_desc->action pointer being cast to a irq_guest_action_t* when
> in-fact it is an irqaction*, but the (correct) solution is not easy.
> 
> destroy_irq() calls dynamic_irq_cleanup() which xfree()'s desc->action.
> This would be all well and fine if it were only an irqaction pointer.
> However, in this case, it is actually an irq_guest_action_t pointer,
> meaning that we have free()'d an inactive timer, which is on a pcpu's
> inactive timer linked list.  This means that as soon as the free()'d
> memory is reused for something new, the linked list gets trashed, which
> which point all bets are off with regards to the validity of hypervisor
> memory.
> 
> As far as I can tell, this bug only manifests in combination with PCI
> Passthrough, as we only perform cleanup of guest irqs when a domain with
> passthrough is shut down.  The issue was first found by the ASSERT()s in
> __list_del(), when something tried to use the pcpu inactive timer list,
> after the free()'d memory was reused.
> 
> In this specific case, a quick and dirty hack would be to check every
> time we free an action and possibly kill the timer if it is a guest irq.
> 
> Having said that, it is not a correct fix; the utter abuse of
> irq_desc->action has been a ticking timebomb for a long time.
> irq_guest_action_t is private to the 2nd half of irq.c(x86), whereas
> irqaction is common and architecture independent.  The only acceptable
> solution I see is to re-architect a substantial proportion of the irq code.
> 
> Am I missing something obvious? or is the best way to continue (in which
> case I have my work cut out as, it is currently affecting XenServer
> customers) ?



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 07 18:42:45 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Sep 2012 18:42:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TA3VS-0001d2-Bs; Fri, 07 Sep 2012 18:42:18 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1TA3VR-0001cx-1j
	for xen-devel@lists.xen.org; Fri, 07 Sep 2012 18:42:17 +0000
Received: from [85.158.139.83:16717] by server-4.bemta-5.messagelabs.com id
	92/2C-23042-8004A405; Fri, 07 Sep 2012 18:42:16 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1347043335!25290880!1
X-Originating-IP: [209.85.215.173]
X-SpamReason: No, hits=2.8 required=7.0 tests=BODY_RANDOM_LONG,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,SUBJECT_RANDOMQ,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17362 invoked from network); 7 Sep 2012 18:42:15 -0000
Received: from mail-ey0-f173.google.com (HELO mail-ey0-f173.google.com)
	(209.85.215.173)
	by server-7.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Sep 2012 18:42:15 -0000
Received: by eaac13 with SMTP id c13so1119314eaa.32
	for <xen-devel@lists.xen.org>; Fri, 07 Sep 2012 11:42:15 -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=n0kjEUYIRaQVCT4UQfqHoA2LU3X98g016OlpkFQFdgU=;
	b=lZ5YBnVvXeOgfRYaGZ7BiOCIFW6/0bGX3HkFezqp41iH5lrd3trdMAlcGkKi3mDpqY
	iUcNvkZFxbBSIUtfgkNtud86G92AN9d2tnupzNJlRoB5RRJsDNfVRSF6VyahvGGCI3gD
	/hoGsW2s1DTxGWiOtOzk6C3mas83ELSgDNZ13bF+cMn3HYYDjj5esYnPqV5IgzB3nTGm
	XcBeDVScXGE3NxLkz7kpUK68XSlmBK0KWhx8tSu+70znJnVCTYsy0bJRO6l/4C8C71Ms
	C29URIm/V+W3JtPMaP0e98B3YoNKlZXXq9FnlU9gIgJ+acm2r22b7B6xB4ksX9ZYnjeY
	mXRg==
Received: by 10.14.173.9 with SMTP id u9mr9483522eel.8.1347043335143;
	Fri, 07 Sep 2012 11:42:15 -0700 (PDT)
Received: from [192.168.1.69] (host86-184-74-117.range86-184.btcentralplus.com.
	[86.184.74.117])
	by mx.google.com with ESMTPS id z3sm16903985eel.15.2012.09.07.11.42.11
	(version=SSLv3 cipher=OTHER); Fri, 07 Sep 2012 11:42:14 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Fri, 07 Sep 2012 19:42:06 +0100
From: Keir Fraser <keir.xen@gmail.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Keir Fraser <keir@xen.org>, Jan Beulich <jbeulich@suse.com>
Message-ID: <CC6FFE8E.3E156%keir.xen@gmail.com>
Thread-Topic: Hypervisor memory leak/corruption because of guest irqs
Thread-Index: Ac2NKHqt7yYwI3nMgU6KA8ke66Xwjw==
In-Reply-To: <504A371F.7000808@citrix.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] Hypervisor memory leak/corruption because of guest
	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

Seems it means noone thought properly about teardown of guest-bound irqs.
Probably because a lot of that code was dumbly ported over from Linux later.

As for abuse of desc->action, you could turn that field explicitly into a
discriminated union; it is already precisely discriminated by
desc->status&IRQ_GUEST. Apart from that syntactic sugar, the idea of having
that pointer point at two different things dependent on irq type doesn't
seem ugly to me -- if it's irq-bound then it does not have, nor does it
need, an irqaction. But the irq_guest_action of course has to be dealt with
and your problem is that noone has thought about it!

 -- Keir

On 07/09/2012 19:04, "Andrew Cooper" <andrew.cooper3@citrix.com> wrote:

> Hello,
> 
> I appear to have opened a can of worms here.  This was discovered when
> turning on ASSERT()s, looking for another crash (and adding in 98 new
> ASSERTs, along with some 'type checking' magic constants)
> 
> The issue has been discovered against Xen 4.1.3, but a cursory
> inspection of unstable shows no signs of it being fixed. The relevant
> assertion (which I added) is attached.  (In the process of debugging, I
> also developed the ASSERT_PRINTK(bool, fmt, ...) macro which will be
> upstreamed in due course.)
> 
> The root cause of the problem is the compelete abuse of the
> irq_desc->action pointer being cast to a irq_guest_action_t* when
> in-fact it is an irqaction*, but the (correct) solution is not easy.
> 
> destroy_irq() calls dynamic_irq_cleanup() which xfree()'s desc->action.
> This would be all well and fine if it were only an irqaction pointer.
> However, in this case, it is actually an irq_guest_action_t pointer,
> meaning that we have free()'d an inactive timer, which is on a pcpu's
> inactive timer linked list.  This means that as soon as the free()'d
> memory is reused for something new, the linked list gets trashed, which
> which point all bets are off with regards to the validity of hypervisor
> memory.
> 
> As far as I can tell, this bug only manifests in combination with PCI
> Passthrough, as we only perform cleanup of guest irqs when a domain with
> passthrough is shut down.  The issue was first found by the ASSERT()s in
> __list_del(), when something tried to use the pcpu inactive timer list,
> after the free()'d memory was reused.
> 
> In this specific case, a quick and dirty hack would be to check every
> time we free an action and possibly kill the timer if it is a guest irq.
> 
> Having said that, it is not a correct fix; the utter abuse of
> irq_desc->action has been a ticking timebomb for a long time.
> irq_guest_action_t is private to the 2nd half of irq.c(x86), whereas
> irqaction is common and architecture independent.  The only acceptable
> solution I see is to re-architect a substantial proportion of the irq code.
> 
> Am I missing something obvious? or is the best way to continue (in which
> case I have my work cut out as, it is currently affecting XenServer
> customers) ?



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 07 19:08:42 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Sep 2012 19:08:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TA3uY-0001zu-HK; Fri, 07 Sep 2012 19:08:14 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1TA3uX-0001zp-0B
	for xen-devel@lists.xen.org; Fri, 07 Sep 2012 19:08:13 +0000
Received: from [85.158.143.35:47338] by server-1.bemta-4.messagelabs.com id
	87/7F-12504-C164A405; Fri, 07 Sep 2012 19:08:12 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1347044890!15857562!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNjk1ODQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9319 invoked from network); 7 Sep 2012 19:08:11 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-13.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Sep 2012 19:08:11 -0000
X-IronPort-AV: E=Sophos;i="4.80,387,1344211200"; d="scan'208";a="37165744"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Sep 2012 19:08:10 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1;
	Fri, 7 Sep 2012 15:08: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 1TA3uT-0002eo-32;
	Fri, 07 Sep 2012 20:08:09 +0100
Message-ID: <504A4619.90707@citrix.com>
Date: Fri, 7 Sep 2012 20:08:09 +0100
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:14.0) Gecko/20120714 Thunderbird/14.0
MIME-Version: 1.0
To: Keir Fraser <keir.xen@gmail.com>
References: <CC6FFE8E.3E156%keir.xen@gmail.com>
In-Reply-To: <CC6FFE8E.3E156%keir.xen@gmail.com>
X-Enigmail-Version: 1.4.4
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] Hypervisor memory leak/corruption because of guest
	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 07/09/12 19:42, Keir Fraser wrote:
> Seems it means noone thought properly about teardown of guest-bound irqs.
> Probably because a lot of that code was dumbly ported over from Linux later.
>
> As for abuse of desc->action, you could turn that field explicitly into a
> discriminated union; it is already precisely discriminated by
> desc->status&IRQ_GUEST. Apart from that syntactic sugar, the idea of having
> that pointer point at two different things dependent on irq type doesn't
> seem ugly to me -- if it's irq-bound then it does not have, nor does it
> need, an irqaction. But the irq_guest_action of course has to be dealt with
> and your problem is that noone has thought about it!
>
>  -- Keir

Its not completely trivial to turn it into a discriminated union (in an
acceptable way), as irq_desc and irqaction is common while
irq_guest_action_t is x86 specific (and irq.c private, currently),
meaning the introduction of an arch_irqaction.

Now that the two actions are different, you could perhaps convert
__do_IRQ_guest() to be the 'handler' of the irqaction, which appears to
cause large amounts of "if(desc->status & IRQ_GUEST) then do something"
code to fall out.  Continuing along this line leads to large amounts of
code change.

I will see about working on a bare minimum patch to make the teardown of
guest IRQs safe, but I dont think it will be very small, and it will
open the way for some cleanup.

~Andrew

>
> On 07/09/2012 19:04, "Andrew Cooper" <andrew.cooper3@citrix.com> wrote:
>
>> Hello,
>>
>> I appear to have opened a can of worms here.  This was discovered when
>> turning on ASSERT()s, looking for another crash (and adding in 98 new
>> ASSERTs, along with some 'type checking' magic constants)
>>
>> The issue has been discovered against Xen 4.1.3, but a cursory
>> inspection of unstable shows no signs of it being fixed. The relevant
>> assertion (which I added) is attached.  (In the process of debugging, I
>> also developed the ASSERT_PRINTK(bool, fmt, ...) macro which will be
>> upstreamed in due course.)
>>
>> The root cause of the problem is the compelete abuse of the
>> irq_desc->action pointer being cast to a irq_guest_action_t* when
>> in-fact it is an irqaction*, but the (correct) solution is not easy.
>>
>> destroy_irq() calls dynamic_irq_cleanup() which xfree()'s desc->action.
>> This would be all well and fine if it were only an irqaction pointer.
>> However, in this case, it is actually an irq_guest_action_t pointer,
>> meaning that we have free()'d an inactive timer, which is on a pcpu's
>> inactive timer linked list.  This means that as soon as the free()'d
>> memory is reused for something new, the linked list gets trashed, which
>> which point all bets are off with regards to the validity of hypervisor
>> memory.
>>
>> As far as I can tell, this bug only manifests in combination with PCI
>> Passthrough, as we only perform cleanup of guest irqs when a domain with
>> passthrough is shut down.  The issue was first found by the ASSERT()s in
>> __list_del(), when something tried to use the pcpu inactive timer list,
>> after the free()'d memory was reused.
>>
>> In this specific case, a quick and dirty hack would be to check every
>> time we free an action and possibly kill the timer if it is a guest irq.
>>
>> Having said that, it is not a correct fix; the utter abuse of
>> irq_desc->action has been a ticking timebomb for a long time.
>> irq_guest_action_t is private to the 2nd half of irq.c(x86), whereas
>> irqaction is common and architecture independent.  The only acceptable
>> solution I see is to re-architect a substantial proportion of the irq code.
>>
>> Am I missing something obvious? or is the best way to continue (in which
>> case I have my work cut out as, it is currently affecting XenServer
>> customers) ?
>

-- 
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 Sep 07 19:08:42 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Sep 2012 19:08:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TA3uY-0001zu-HK; Fri, 07 Sep 2012 19:08:14 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1TA3uX-0001zp-0B
	for xen-devel@lists.xen.org; Fri, 07 Sep 2012 19:08:13 +0000
Received: from [85.158.143.35:47338] by server-1.bemta-4.messagelabs.com id
	87/7F-12504-C164A405; Fri, 07 Sep 2012 19:08:12 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1347044890!15857562!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNjk1ODQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9319 invoked from network); 7 Sep 2012 19:08:11 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-13.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Sep 2012 19:08:11 -0000
X-IronPort-AV: E=Sophos;i="4.80,387,1344211200"; d="scan'208";a="37165744"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Sep 2012 19:08:10 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1;
	Fri, 7 Sep 2012 15:08: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 1TA3uT-0002eo-32;
	Fri, 07 Sep 2012 20:08:09 +0100
Message-ID: <504A4619.90707@citrix.com>
Date: Fri, 7 Sep 2012 20:08:09 +0100
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:14.0) Gecko/20120714 Thunderbird/14.0
MIME-Version: 1.0
To: Keir Fraser <keir.xen@gmail.com>
References: <CC6FFE8E.3E156%keir.xen@gmail.com>
In-Reply-To: <CC6FFE8E.3E156%keir.xen@gmail.com>
X-Enigmail-Version: 1.4.4
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] Hypervisor memory leak/corruption because of guest
	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 07/09/12 19:42, Keir Fraser wrote:
> Seems it means noone thought properly about teardown of guest-bound irqs.
> Probably because a lot of that code was dumbly ported over from Linux later.
>
> As for abuse of desc->action, you could turn that field explicitly into a
> discriminated union; it is already precisely discriminated by
> desc->status&IRQ_GUEST. Apart from that syntactic sugar, the idea of having
> that pointer point at two different things dependent on irq type doesn't
> seem ugly to me -- if it's irq-bound then it does not have, nor does it
> need, an irqaction. But the irq_guest_action of course has to be dealt with
> and your problem is that noone has thought about it!
>
>  -- Keir

Its not completely trivial to turn it into a discriminated union (in an
acceptable way), as irq_desc and irqaction is common while
irq_guest_action_t is x86 specific (and irq.c private, currently),
meaning the introduction of an arch_irqaction.

Now that the two actions are different, you could perhaps convert
__do_IRQ_guest() to be the 'handler' of the irqaction, which appears to
cause large amounts of "if(desc->status & IRQ_GUEST) then do something"
code to fall out.  Continuing along this line leads to large amounts of
code change.

I will see about working on a bare minimum patch to make the teardown of
guest IRQs safe, but I dont think it will be very small, and it will
open the way for some cleanup.

~Andrew

>
> On 07/09/2012 19:04, "Andrew Cooper" <andrew.cooper3@citrix.com> wrote:
>
>> Hello,
>>
>> I appear to have opened a can of worms here.  This was discovered when
>> turning on ASSERT()s, looking for another crash (and adding in 98 new
>> ASSERTs, along with some 'type checking' magic constants)
>>
>> The issue has been discovered against Xen 4.1.3, but a cursory
>> inspection of unstable shows no signs of it being fixed. The relevant
>> assertion (which I added) is attached.  (In the process of debugging, I
>> also developed the ASSERT_PRINTK(bool, fmt, ...) macro which will be
>> upstreamed in due course.)
>>
>> The root cause of the problem is the compelete abuse of the
>> irq_desc->action pointer being cast to a irq_guest_action_t* when
>> in-fact it is an irqaction*, but the (correct) solution is not easy.
>>
>> destroy_irq() calls dynamic_irq_cleanup() which xfree()'s desc->action.
>> This would be all well and fine if it were only an irqaction pointer.
>> However, in this case, it is actually an irq_guest_action_t pointer,
>> meaning that we have free()'d an inactive timer, which is on a pcpu's
>> inactive timer linked list.  This means that as soon as the free()'d
>> memory is reused for something new, the linked list gets trashed, which
>> which point all bets are off with regards to the validity of hypervisor
>> memory.
>>
>> As far as I can tell, this bug only manifests in combination with PCI
>> Passthrough, as we only perform cleanup of guest irqs when a domain with
>> passthrough is shut down.  The issue was first found by the ASSERT()s in
>> __list_del(), when something tried to use the pcpu inactive timer list,
>> after the free()'d memory was reused.
>>
>> In this specific case, a quick and dirty hack would be to check every
>> time we free an action and possibly kill the timer if it is a guest irq.
>>
>> Having said that, it is not a correct fix; the utter abuse of
>> irq_desc->action has been a ticking timebomb for a long time.
>> irq_guest_action_t is private to the 2nd half of irq.c(x86), whereas
>> irqaction is common and architecture independent.  The only acceptable
>> solution I see is to re-architect a substantial proportion of the irq code.
>>
>> Am I missing something obvious? or is the best way to continue (in which
>> case I have my work cut out as, it is currently affecting XenServer
>> customers) ?
>

-- 
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 Sep 07 19:34:20 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Sep 2012 19:34:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TA4JQ-0002CI-E6; Fri, 07 Sep 2012 19:33:56 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <nathan@gt.net>) id 1TA4JN-0002By-T1
	for xen-devel@lists.xen.org; Fri, 07 Sep 2012 19:33:54 +0000
Received: from [85.158.143.99:10769] by server-3.bemta-4.messagelabs.com id
	76/D7-08232-12C4A405; Fri, 07 Sep 2012 19:33:53 +0000
X-Env-Sender: nathan@gt.net
X-Msg-Ref: server-12.tower-216.messagelabs.com!1347046429!23942024!1
X-Originating-IP: [208.70.244.21]
X-SpamReason: No, hits=1.1 required=7.0 tests=BODY_RANDOM_LONG,
	HTML_40_50,HTML_MESSAGE
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12765 invoked from network); 7 Sep 2012 19:33:51 -0000
Received: from gossamer.nmsrv.com (HELO gossamer.nmsrv.com) (208.70.244.21)
	by server-12.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 7 Sep 2012 19:33:51 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gt.net; h=from:to:subject
	:cc:date:content-type:in-reply-to:message-id:mime-version
	:reply-to; s=mail; bh=b90i7uN2i9o2+wIG6MIdi8KrZns=; b=iBqchG4wFw
	pa4bU908XT0bizkXD2QxYbgzEa16lJCTkD6Dj74ddVqXxOgsaW7PnMFfikkc8lEv
	d2YZc21UwWrZtp26qxG9zqZL4I0AgDRp74qEoenytZ7EwREJu2LdXogWVXhiJlwB
	uybypho9cYOgtoEvtX5NIPFE+KVTI9q+4=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gt.net; h=from:to:subject:cc
	:date:content-type:in-reply-to:message-id:mime-version:reply-to;
	q=dns; s=mail; b=TCPqKQn7vG+NNnDgw1PoKboCnibOotDHx+lZo39bsMmv7X
	kfYWVGrnv7CoJKUV0xe3X0JeGFjGIYCaTqo5VQqYlpDC0MZ4cZjr9djYtb7ELQpR
	ZZae1Hrcntr/fSJZzT+AaSLBU37bIgq7QvoxzDBG4gJm82AvAq5e9YqpzEweU=
Received: (qmail 24889 invoked from network); 7 Sep 2012 19:33:48 -0000
X-AntiVirus: Clean
Received: from gateway.gossamer-threads.com (HELO ?192.168.1.152?)
	(nathan@gt.net@208.70.247.145)
	by gossamer.nmsrv.com with ESMTPSA (AES128-SHA encrypted);
	7 Sep 2012 19:33:48 -0000
From: "Nathan March" <nathan@gt.net>
To: "Xen.org security team" <security@xen.org>, xen-devel@lists.xen.org,
	xen-users@lists.xen.org, oss-security@lists.openwall.com
Date: Fri, 07 Sep 2012 19:33:42 +0000
In-Reply-To: <E1T9DXL-0005Qu-97@xenbits.xen.org>
Message-Id: <emd0d6024e-114e-4969-a7b2-ef30ed5138a5@nathan>
Mime-Version: 1.0
User-Agent: eM_Client/4.0.15145.0
Cc: "Xen.org security team" <security@xen.org>
Subject: Re: [Xen-devel] [Xen-users] Xen Security Advisory 17
 (CVE-2012-3515) - Qemu VT100 emulation vulnerability
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: Nathan March <nathan@gt.net>
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============4802264192683208083=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--===============4802264192683208083==
Content-Type: multipart/alternative;
 boundary="------=_MB49CA08F0-682A-4135-A2F6-956DD7751BF1"


--------=_MB49CA08F0-682A-4135-A2F6-956DD7751BF1
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; format=flowed; charset=utf-8

=EF=BB=BFHi All,

I'm guessing this wasn't intentional, but the patch for xsa17 does not=20
contain a complete path to the tools/ioemu-qemu-xen/ path:

--- a/console.c
+++ b/console.c

Compared to all the other patches which provide a full path to the=20
patched file:

--- a/xen/include/asm-x86/debugreg.h Mon Aug 06 12:28:03 2012 +0100
+++ b/xen/include/asm-x86/debugreg.h Wed Aug 15 12:00:21 2012 +0100

Little annoying since it means you have to track down which console.c=20
is being patched instead of just applying from the root xen build dir.

- Nathan


------ Original Message ------
From: "Xen.org security team" <security@xen.org>
To:=20
xen-announce@lists.xen.org;xen-devel@lists.xen.org;xen-users@lists.xen.org;=
oss-security@lists.openwall.com
Cc: "Xen.org security team" <security@xen.org>
Sent: 9/5/2012 4:12:47 AM
Subject: [Xen-users] Xen Security Advisory 17 (CVE-2012-3515) - Qemu=20
VT100 emulation vulnerability
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>           Xen Security Advisory CVE-2012-3515 / XSA-17
>                          version 2
>
>              Qemu VT100 emulation vulnerability
>
>UPDATES IN VERSION 2
>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>
>Public release.
>
>ISSUE DESCRIPTION
>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>
>The device model used by fully virtualised (HVM) domains, qemu, does
>not properly handle escape VT100 sequences when emulating certain
>devices with a virtual console backend.
>
>IMPACT
>=3D=3D=3D=3D=3D=3D
>
>An attacker who has sufficient privilege to access a vulnerable device
>within a guest can overwrite portions of the device model's address
>space. This can allow them to escalate their privileges to that of the
>device model process.
>
>VULNERABLE SYSTEMS
>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>
>All Xen systems running HVM guests are potentially vulnerable to this
>depending on the specific guest configuration. The default
>configuration is vulnerable.
>
>Guests using either the traditional "qemu-xen" or upstream qemu device
>models are vulnerable.
>
>MITIGATION
>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>
>This issue can be avoided by only running PV guests or by configuring
>HVM guests to not use the virtual console('vc') backend for any device.
>
>For serial devices specify in your guest configuration:
>    serial =3D 'none'
>in your guest configuration.
>
>For parallel port devices the syntax is toolstack specific.
>For xend specify in your guest configuration:
>    parallel =3D 'none'
>For xl specify in your guest configuration:
>    xl: device_model_args =3D ['-parallel', 'none']
>
>In both cases the default is to use the vulnerable 'vc' mode.
>
>You can confirm whether or not you are vulnerable by pressing
>Ctrl-Alt-<N> (for digit N) while connected to either the VNC or SDL
>console. If you are able to switch to a window displaying "serial" or
>"parallel" then you are vulnerable.
>
>The issue can also be mitigated by enabling the stub domain device
>model. In this case the attacked can only potentially gain control of
>the stub domain and not of the entire system.
>
>To enable stub domains specify in your guest configuration:
>   device_model =3D "stubdom-dm"
>
>RESOLUTION
>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>
>Applying the appropriate attached patch(es) will resolve the issue.
>
>PATCH INFORMATION
>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>
>The attached patches resolve this issue
>
>Traditional qemu tree
>  Xen 4.0, 4.1 and unstable         xsa17-qemu-xen-traditional-all.patch
>
>Upstream qemu tree (present in unstable only)
>  Xen unstable                      xsa17-qemu-xen-unstable.patch
>
>$ sha256sum xsa17-*.patch
>60215322d3fbbc2054dfc160a20d9e0811af88487c4edc2f6ea81dcd5cedf039  xsa17-qe=
mu-xen-traditional-all.patch
>7b4bb59e7757080e7806a8b8eeb6b78fa0ffdfbfb28a7a379f7edff285bffd88  xsa17-qe=
mu-xen-unstable.patch
>-----BEGIN PGP SIGNATURE-----
>Version: GnuPG v1.4.10 (GNU/Linux)
>
>iQEcBAEBAgAGBQJQRx1PAAoJEIP+FMlX6CvZUqUH/jeAAvQnoBp6YKzm78XSnnmk
>GI2C/LhH0xqR3wFoEmWeMsiO4lrGrASX6T31NTvHa8sOtFqlNpTfRhwQybwYR3aa
>cz9/4y2a54hD95P1nVmPF0PddmSP47QSpRdCj0projq1UGxIdwEhkNeSoM8h7dXO
>MegqZClsvJMKd8XEcjBF5Qg7u9vLrXilCx5+It7XNE31Jxpkr/fozBb7FnNtDGJj
>s4RN/UDU4Pu68XyZ7Dc5xEFdJW48tz4BIlxxXavILBRFSE1VEf7Gc8H9CsUtBPWB
>C/LCUjpHkAOmqdgFhiLnZ2u+2s79U0dtPDJMNmqaGgWH+AqGkU9Nq8XXODTyY9k=3D
>=3DgnuE
>-----END PGP SIGNATURE-----
>
>

--------=_MB49CA08F0-682A-4135-A2F6-956DD7751BF1
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=utf-8

<HTML><HEAD>
<STYLE id=3DeMClientCss>BLOCKQUOTE.cite {
	BORDER-LEFT: #000000 1px solid; PADDING-LEFT: 10px; PADDING-RIGHT: 0px;=
 MARGIN-LEFT: 5px; MARGIN-RIGHT: 0px
}
.plain PRE {
	FONT-STYLE: normal; FONT-FAMILY: monospace; FONT-SIZE: 100%; FONT-WEIGHT:=
 normal
}
BODY {
	FONT-FAMILY: Tahoma; FONT-SIZE: 10pt
}
.plain PRE {
	FONT-FAMILY: Tahoma; FONT-SIZE: 10pt
}
#263c15780ff94333aaaf17642dbbef06 BLOCKQUOTE.cite {
	BORDER-LEFT: #000000 1px solid; PADDING-LEFT: 10px; PADDING-RIGHT: 0px;=
 MARGIN-LEFT: 5px; MARGIN-RIGHT: 0px
}
#263c15780ff94333aaaf17642dbbef06 .plain PRE {
	FONT-STYLE: normal; FONT-FAMILY: monospace; FONT-SIZE: 100%; FONT-WEIGHT:=
 normal
}
#263c15780ff94333aaaf17642dbbef06 {
	FONT-FAMILY: Tahoma; FONT-SIZE: 10pt
}
#263c15780ff94333aaaf17642dbbef06 .plain PRE {
	FONT-FAMILY: Tahoma; FONT-SIZE: 10pt
}
UNKNOWN {
	BORDER-LEFT: #000000 1px solid; PADDING-LEFT: 10px; PADDING-RIGHT: 0px;=
 MARGIN-LEFT: 5px; MARGIN-RIGHT: 0px
}
#1bd758ae7bd34680b7bcf93f3cde9dd9 .plain PRE {
	FONT-STYLE: normal; FONT-FAMILY: monospace; FONT-SIZE: 100%; FONT-WEIGHT:=
 normal
}
#1bd758ae7bd34680b7bcf93f3cde9dd9 {
	FONT-FAMILY: Tahoma; FONT-SIZE: 10pt
}
#1bd758ae7bd34680b7bcf93f3cde9dd9 .plain PRE {
	FONT-FAMILY: Tahoma; FONT-SIZE: 10pt
}
#1bd758ae7bd34680b7bcf93f3cde9dd9 #263c15780ff94333aaaf17642dbbef06 BLOCKQU=
OTE.cite {
	BORDER-LEFT: #000000 1px solid; PADDING-LEFT: 10px; PADDING-RIGHT: 0px;=
 MARGIN-LEFT: 5px; MARGIN-RIGHT: 0px
}
#1bd758ae7bd34680b7bcf93f3cde9dd9 #263c15780ff94333aaaf17642dbbef06 .plain=
 PRE {
	FONT-STYLE: normal; FONT-FAMILY: monospace; FONT-SIZE: 100%; FONT-WEIGHT:=
 normal
}
#1bd758ae7bd34680b7bcf93f3cde9dd9 #263c15780ff94333aaaf17642dbbef06 {
	FONT-FAMILY: Tahoma; FONT-SIZE: 10pt
}
#1bd758ae7bd34680b7bcf93f3cde9dd9 #263c15780ff94333aaaf17642dbbef06 .plain=
 PRE {
	FONT-FAMILY: Tahoma; FONT-SIZE: 10pt
}
</STYLE>

<META content=3Dtext/html;charset=3Dutf-8 http-equiv=3DContent-Type></HEAD>
<BODY scroll=3Dauto class>
<DIV>Hi All,</DIV>
<DIV>&nbsp;</DIV>
<DIV>I'm guessing this wasn't intentional, but the patch for xsa17 does =
not contain a complete path to the tools/ioemu-qemu-xen/ path:</DIV>
<DIV>&nbsp;</DIV>
<DIV>--- a/console.c<BR>+++ b/console.c</DIV>
<DIV>&nbsp;</DIV>
<DIV>Compared to all the other patches <SPAN id=3D1bd758ae7bd34680b7bcf93f3=
cde9dd9>which provide a full path to the patched file:</SPAN></DIV>
<DIV>&nbsp;</DIV>
<DIV>--- a/xen/include/asm-x86/debugreg.h Mon Aug 06 12:28:03 2012 +0100<BR=
>+++ b/xen/include/asm-x86/debugreg.h Wed Aug 15 12:00:21 2012 +0100</DIV>
<DIV>&nbsp;</DIV>
<DIV>Little annoying since it means you have to track down which console.c=
 is being patched instead of just applying from the root xen build dir.</DI=
V>
<DIV>&nbsp;</DIV>
<DIV>- Nathan</DIV>
<DIV>&nbsp;</DIV>
<DIV><BR>------ Original Message ------<BR>From: "Xen.org security team"=
 &lt;security@xen.org&gt;<BR>To: xen-announce@lists.xen.org;xen-devel@lists=
.xen.org;xen-users@lists.xen.org;oss-security@lists.openwall.com<BR>Cc: =
"Xen.org security team" &lt;security@xen.org&gt;<BR>Sent: 9/5/2012 4:12:47=
 AM<BR>Subject: [Xen-users] Xen Security Advisory 17 (CVE-2012-3515) - Qemu=
 VT100 emulation vulnerability<BR></DIV>
<BLOCKQUOTE class=3Dcite cite=3DE1T9DXL-0005Qu-97@xenbits.xen.org type=3D=
"cite">
<DIV id=3D263c15780ff94333aaaf17642dbbef06><PRE style=3D"WORD-WRAP: break-w=
ord">-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Xen Secur=
ity Advisory CVE-2012-3515 / XSA-17
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;version 2

&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;Qemu VT100 emulation vulnerability

UPDATES IN VERSION 2
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Public release.

ISSUE DESCRIPTION
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

The device model used by fully virtualised (HVM) domains, qemu, does
not properly handle escape VT100 sequences when emulating certain
devices with a virtual console backend.

IMPACT
=3D=3D=3D=3D=3D=3D

An attacker who has sufficient privilege to access a vulnerable device
within a guest can overwrite portions of the device model's address
space. This can allow them to escalate their privileges to that of the
device model process.

VULNERABLE SYSTEMS
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

All Xen systems running HVM guests are potentially vulnerable to this
depending on the specific guest configuration. The default
configuration is vulnerable.

Guests using either the traditional "qemu-xen" or upstream qemu device
models are vulnerable.

MITIGATION
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

This issue can be avoided by only running PV guests or by configuring
HVM guests to not use the virtual console('vc') backend for any device.

For serial devices specify in your guest configuration:
&nbsp;&nbsp;&nbsp;&nbsp;serial =3D 'none'
in your guest configuration.

For parallel port devices the syntax is toolstack specific.
For xend specify in your guest configuration:
&nbsp;&nbsp;&nbsp;&nbsp;parallel =3D 'none'
For xl specify in your guest configuration:
&nbsp;&nbsp;&nbsp;&nbsp;xl: device_model_args =3D ['-parallel', 'none']

In both cases the default is to use the vulnerable 'vc' mode.

You can confirm whether or not you are vulnerable by pressing
Ctrl-Alt-&lt;N&gt; (for digit N) while connected to either the VNC or SDL
console. If you are able to switch to a window displaying "serial" or
"parallel" then you are vulnerable.

The issue can also be mitigated by enabling the stub domain device
model. In this case the attacked can only potentially gain control of
the stub domain and not of the entire system.

To enable stub domains specify in your guest configuration:
&nbsp;&nbsp;&nbsp;device_model =3D "stubdom-dm"

RESOLUTION
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Applying the appropriate attached patch(es) will resolve the issue.

PATCH INFORMATION
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

The attached patches resolve this issue

Traditional qemu tree
&nbsp;&nbsp;Xen 4.0, 4.1 and unstable         xsa17-qemu-xen-traditional-al=
l.patch

Upstream qemu tree (present in unstable only)
&nbsp;&nbsp;Xen unstable                      xsa17-qemu-xen-unstable.patch

$ sha256sum xsa17-*.patch
60215322d3fbbc2054dfc160a20d9e0811af88487c4edc2f6ea81dcd5cedf039  xsa17-qem=
u-xen-traditional-all.patch
7b4bb59e7757080e7806a8b8eeb6b78fa0ffdfbfb28a7a379f7edff285bffd88  xsa17-qem=
u-xen-unstable.patch
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iQEcBAEBAgAGBQJQRx1PAAoJEIP+FMlX6CvZUqUH/jeAAvQnoBp6YKzm78XSnnmk
GI2C/LhH0xqR3wFoEmWeMsiO4lrGrASX6T31NTvHa8sOtFqlNpTfRhwQybwYR3aa
cz9/4y2a54hD95P1nVmPF0PddmSP47QSpRdCj0projq1UGxIdwEhkNeSoM8h7dXO
MegqZClsvJMKd8XEcjBF5Qg7u9vLrXilCx5+It7XNE31Jxpkr/fozBb7FnNtDGJj
s4RN/UDU4Pu68XyZ7Dc5xEFdJW48tz4BIlxxXavILBRFSE1VEf7Gc8H9CsUtBPWB
C/LCUjpHkAOmqdgFhiLnZ2u+2s79U0dtPDJMNmqaGgWH+AqGkU9Nq8XXODTyY9k=3D
=3DgnuE
-----END PGP SIGNATURE-----
</PRE></DIV></BLOCKQUOTE></BODY></HTML>
--------=_MB49CA08F0-682A-4135-A2F6-956DD7751BF1--



--===============4802264192683208083==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============4802264192683208083==--



From xen-devel-bounces@lists.xen.org Fri Sep 07 19:34:20 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Sep 2012 19:34:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TA4JQ-0002CI-E6; Fri, 07 Sep 2012 19:33:56 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <nathan@gt.net>) id 1TA4JN-0002By-T1
	for xen-devel@lists.xen.org; Fri, 07 Sep 2012 19:33:54 +0000
Received: from [85.158.143.99:10769] by server-3.bemta-4.messagelabs.com id
	76/D7-08232-12C4A405; Fri, 07 Sep 2012 19:33:53 +0000
X-Env-Sender: nathan@gt.net
X-Msg-Ref: server-12.tower-216.messagelabs.com!1347046429!23942024!1
X-Originating-IP: [208.70.244.21]
X-SpamReason: No, hits=1.1 required=7.0 tests=BODY_RANDOM_LONG,
	HTML_40_50,HTML_MESSAGE
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12765 invoked from network); 7 Sep 2012 19:33:51 -0000
Received: from gossamer.nmsrv.com (HELO gossamer.nmsrv.com) (208.70.244.21)
	by server-12.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 7 Sep 2012 19:33:51 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gt.net; h=from:to:subject
	:cc:date:content-type:in-reply-to:message-id:mime-version
	:reply-to; s=mail; bh=b90i7uN2i9o2+wIG6MIdi8KrZns=; b=iBqchG4wFw
	pa4bU908XT0bizkXD2QxYbgzEa16lJCTkD6Dj74ddVqXxOgsaW7PnMFfikkc8lEv
	d2YZc21UwWrZtp26qxG9zqZL4I0AgDRp74qEoenytZ7EwREJu2LdXogWVXhiJlwB
	uybypho9cYOgtoEvtX5NIPFE+KVTI9q+4=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gt.net; h=from:to:subject:cc
	:date:content-type:in-reply-to:message-id:mime-version:reply-to;
	q=dns; s=mail; b=TCPqKQn7vG+NNnDgw1PoKboCnibOotDHx+lZo39bsMmv7X
	kfYWVGrnv7CoJKUV0xe3X0JeGFjGIYCaTqo5VQqYlpDC0MZ4cZjr9djYtb7ELQpR
	ZZae1Hrcntr/fSJZzT+AaSLBU37bIgq7QvoxzDBG4gJm82AvAq5e9YqpzEweU=
Received: (qmail 24889 invoked from network); 7 Sep 2012 19:33:48 -0000
X-AntiVirus: Clean
Received: from gateway.gossamer-threads.com (HELO ?192.168.1.152?)
	(nathan@gt.net@208.70.247.145)
	by gossamer.nmsrv.com with ESMTPSA (AES128-SHA encrypted);
	7 Sep 2012 19:33:48 -0000
From: "Nathan March" <nathan@gt.net>
To: "Xen.org security team" <security@xen.org>, xen-devel@lists.xen.org,
	xen-users@lists.xen.org, oss-security@lists.openwall.com
Date: Fri, 07 Sep 2012 19:33:42 +0000
In-Reply-To: <E1T9DXL-0005Qu-97@xenbits.xen.org>
Message-Id: <emd0d6024e-114e-4969-a7b2-ef30ed5138a5@nathan>
Mime-Version: 1.0
User-Agent: eM_Client/4.0.15145.0
Cc: "Xen.org security team" <security@xen.org>
Subject: Re: [Xen-devel] [Xen-users] Xen Security Advisory 17
 (CVE-2012-3515) - Qemu VT100 emulation vulnerability
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: Nathan March <nathan@gt.net>
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============4802264192683208083=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--===============4802264192683208083==
Content-Type: multipart/alternative;
 boundary="------=_MB49CA08F0-682A-4135-A2F6-956DD7751BF1"


--------=_MB49CA08F0-682A-4135-A2F6-956DD7751BF1
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; format=flowed; charset=utf-8

=EF=BB=BFHi All,

I'm guessing this wasn't intentional, but the patch for xsa17 does not=20
contain a complete path to the tools/ioemu-qemu-xen/ path:

--- a/console.c
+++ b/console.c

Compared to all the other patches which provide a full path to the=20
patched file:

--- a/xen/include/asm-x86/debugreg.h Mon Aug 06 12:28:03 2012 +0100
+++ b/xen/include/asm-x86/debugreg.h Wed Aug 15 12:00:21 2012 +0100

Little annoying since it means you have to track down which console.c=20
is being patched instead of just applying from the root xen build dir.

- Nathan


------ Original Message ------
From: "Xen.org security team" <security@xen.org>
To:=20
xen-announce@lists.xen.org;xen-devel@lists.xen.org;xen-users@lists.xen.org;=
oss-security@lists.openwall.com
Cc: "Xen.org security team" <security@xen.org>
Sent: 9/5/2012 4:12:47 AM
Subject: [Xen-users] Xen Security Advisory 17 (CVE-2012-3515) - Qemu=20
VT100 emulation vulnerability
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>           Xen Security Advisory CVE-2012-3515 / XSA-17
>                          version 2
>
>              Qemu VT100 emulation vulnerability
>
>UPDATES IN VERSION 2
>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>
>Public release.
>
>ISSUE DESCRIPTION
>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>
>The device model used by fully virtualised (HVM) domains, qemu, does
>not properly handle escape VT100 sequences when emulating certain
>devices with a virtual console backend.
>
>IMPACT
>=3D=3D=3D=3D=3D=3D
>
>An attacker who has sufficient privilege to access a vulnerable device
>within a guest can overwrite portions of the device model's address
>space. This can allow them to escalate their privileges to that of the
>device model process.
>
>VULNERABLE SYSTEMS
>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>
>All Xen systems running HVM guests are potentially vulnerable to this
>depending on the specific guest configuration. The default
>configuration is vulnerable.
>
>Guests using either the traditional "qemu-xen" or upstream qemu device
>models are vulnerable.
>
>MITIGATION
>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>
>This issue can be avoided by only running PV guests or by configuring
>HVM guests to not use the virtual console('vc') backend for any device.
>
>For serial devices specify in your guest configuration:
>    serial =3D 'none'
>in your guest configuration.
>
>For parallel port devices the syntax is toolstack specific.
>For xend specify in your guest configuration:
>    parallel =3D 'none'
>For xl specify in your guest configuration:
>    xl: device_model_args =3D ['-parallel', 'none']
>
>In both cases the default is to use the vulnerable 'vc' mode.
>
>You can confirm whether or not you are vulnerable by pressing
>Ctrl-Alt-<N> (for digit N) while connected to either the VNC or SDL
>console. If you are able to switch to a window displaying "serial" or
>"parallel" then you are vulnerable.
>
>The issue can also be mitigated by enabling the stub domain device
>model. In this case the attacked can only potentially gain control of
>the stub domain and not of the entire system.
>
>To enable stub domains specify in your guest configuration:
>   device_model =3D "stubdom-dm"
>
>RESOLUTION
>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>
>Applying the appropriate attached patch(es) will resolve the issue.
>
>PATCH INFORMATION
>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>
>The attached patches resolve this issue
>
>Traditional qemu tree
>  Xen 4.0, 4.1 and unstable         xsa17-qemu-xen-traditional-all.patch
>
>Upstream qemu tree (present in unstable only)
>  Xen unstable                      xsa17-qemu-xen-unstable.patch
>
>$ sha256sum xsa17-*.patch
>60215322d3fbbc2054dfc160a20d9e0811af88487c4edc2f6ea81dcd5cedf039  xsa17-qe=
mu-xen-traditional-all.patch
>7b4bb59e7757080e7806a8b8eeb6b78fa0ffdfbfb28a7a379f7edff285bffd88  xsa17-qe=
mu-xen-unstable.patch
>-----BEGIN PGP SIGNATURE-----
>Version: GnuPG v1.4.10 (GNU/Linux)
>
>iQEcBAEBAgAGBQJQRx1PAAoJEIP+FMlX6CvZUqUH/jeAAvQnoBp6YKzm78XSnnmk
>GI2C/LhH0xqR3wFoEmWeMsiO4lrGrASX6T31NTvHa8sOtFqlNpTfRhwQybwYR3aa
>cz9/4y2a54hD95P1nVmPF0PddmSP47QSpRdCj0projq1UGxIdwEhkNeSoM8h7dXO
>MegqZClsvJMKd8XEcjBF5Qg7u9vLrXilCx5+It7XNE31Jxpkr/fozBb7FnNtDGJj
>s4RN/UDU4Pu68XyZ7Dc5xEFdJW48tz4BIlxxXavILBRFSE1VEf7Gc8H9CsUtBPWB
>C/LCUjpHkAOmqdgFhiLnZ2u+2s79U0dtPDJMNmqaGgWH+AqGkU9Nq8XXODTyY9k=3D
>=3DgnuE
>-----END PGP SIGNATURE-----
>
>

--------=_MB49CA08F0-682A-4135-A2F6-956DD7751BF1
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=utf-8

<HTML><HEAD>
<STYLE id=3DeMClientCss>BLOCKQUOTE.cite {
	BORDER-LEFT: #000000 1px solid; PADDING-LEFT: 10px; PADDING-RIGHT: 0px;=
 MARGIN-LEFT: 5px; MARGIN-RIGHT: 0px
}
.plain PRE {
	FONT-STYLE: normal; FONT-FAMILY: monospace; FONT-SIZE: 100%; FONT-WEIGHT:=
 normal
}
BODY {
	FONT-FAMILY: Tahoma; FONT-SIZE: 10pt
}
.plain PRE {
	FONT-FAMILY: Tahoma; FONT-SIZE: 10pt
}
#263c15780ff94333aaaf17642dbbef06 BLOCKQUOTE.cite {
	BORDER-LEFT: #000000 1px solid; PADDING-LEFT: 10px; PADDING-RIGHT: 0px;=
 MARGIN-LEFT: 5px; MARGIN-RIGHT: 0px
}
#263c15780ff94333aaaf17642dbbef06 .plain PRE {
	FONT-STYLE: normal; FONT-FAMILY: monospace; FONT-SIZE: 100%; FONT-WEIGHT:=
 normal
}
#263c15780ff94333aaaf17642dbbef06 {
	FONT-FAMILY: Tahoma; FONT-SIZE: 10pt
}
#263c15780ff94333aaaf17642dbbef06 .plain PRE {
	FONT-FAMILY: Tahoma; FONT-SIZE: 10pt
}
UNKNOWN {
	BORDER-LEFT: #000000 1px solid; PADDING-LEFT: 10px; PADDING-RIGHT: 0px;=
 MARGIN-LEFT: 5px; MARGIN-RIGHT: 0px
}
#1bd758ae7bd34680b7bcf93f3cde9dd9 .plain PRE {
	FONT-STYLE: normal; FONT-FAMILY: monospace; FONT-SIZE: 100%; FONT-WEIGHT:=
 normal
}
#1bd758ae7bd34680b7bcf93f3cde9dd9 {
	FONT-FAMILY: Tahoma; FONT-SIZE: 10pt
}
#1bd758ae7bd34680b7bcf93f3cde9dd9 .plain PRE {
	FONT-FAMILY: Tahoma; FONT-SIZE: 10pt
}
#1bd758ae7bd34680b7bcf93f3cde9dd9 #263c15780ff94333aaaf17642dbbef06 BLOCKQU=
OTE.cite {
	BORDER-LEFT: #000000 1px solid; PADDING-LEFT: 10px; PADDING-RIGHT: 0px;=
 MARGIN-LEFT: 5px; MARGIN-RIGHT: 0px
}
#1bd758ae7bd34680b7bcf93f3cde9dd9 #263c15780ff94333aaaf17642dbbef06 .plain=
 PRE {
	FONT-STYLE: normal; FONT-FAMILY: monospace; FONT-SIZE: 100%; FONT-WEIGHT:=
 normal
}
#1bd758ae7bd34680b7bcf93f3cde9dd9 #263c15780ff94333aaaf17642dbbef06 {
	FONT-FAMILY: Tahoma; FONT-SIZE: 10pt
}
#1bd758ae7bd34680b7bcf93f3cde9dd9 #263c15780ff94333aaaf17642dbbef06 .plain=
 PRE {
	FONT-FAMILY: Tahoma; FONT-SIZE: 10pt
}
</STYLE>

<META content=3Dtext/html;charset=3Dutf-8 http-equiv=3DContent-Type></HEAD>
<BODY scroll=3Dauto class>
<DIV>Hi All,</DIV>
<DIV>&nbsp;</DIV>
<DIV>I'm guessing this wasn't intentional, but the patch for xsa17 does =
not contain a complete path to the tools/ioemu-qemu-xen/ path:</DIV>
<DIV>&nbsp;</DIV>
<DIV>--- a/console.c<BR>+++ b/console.c</DIV>
<DIV>&nbsp;</DIV>
<DIV>Compared to all the other patches <SPAN id=3D1bd758ae7bd34680b7bcf93f3=
cde9dd9>which provide a full path to the patched file:</SPAN></DIV>
<DIV>&nbsp;</DIV>
<DIV>--- a/xen/include/asm-x86/debugreg.h Mon Aug 06 12:28:03 2012 +0100<BR=
>+++ b/xen/include/asm-x86/debugreg.h Wed Aug 15 12:00:21 2012 +0100</DIV>
<DIV>&nbsp;</DIV>
<DIV>Little annoying since it means you have to track down which console.c=
 is being patched instead of just applying from the root xen build dir.</DI=
V>
<DIV>&nbsp;</DIV>
<DIV>- Nathan</DIV>
<DIV>&nbsp;</DIV>
<DIV><BR>------ Original Message ------<BR>From: "Xen.org security team"=
 &lt;security@xen.org&gt;<BR>To: xen-announce@lists.xen.org;xen-devel@lists=
.xen.org;xen-users@lists.xen.org;oss-security@lists.openwall.com<BR>Cc: =
"Xen.org security team" &lt;security@xen.org&gt;<BR>Sent: 9/5/2012 4:12:47=
 AM<BR>Subject: [Xen-users] Xen Security Advisory 17 (CVE-2012-3515) - Qemu=
 VT100 emulation vulnerability<BR></DIV>
<BLOCKQUOTE class=3Dcite cite=3DE1T9DXL-0005Qu-97@xenbits.xen.org type=3D=
"cite">
<DIV id=3D263c15780ff94333aaaf17642dbbef06><PRE style=3D"WORD-WRAP: break-w=
ord">-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Xen Secur=
ity Advisory CVE-2012-3515 / XSA-17
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;version 2

&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;Qemu VT100 emulation vulnerability

UPDATES IN VERSION 2
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Public release.

ISSUE DESCRIPTION
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

The device model used by fully virtualised (HVM) domains, qemu, does
not properly handle escape VT100 sequences when emulating certain
devices with a virtual console backend.

IMPACT
=3D=3D=3D=3D=3D=3D

An attacker who has sufficient privilege to access a vulnerable device
within a guest can overwrite portions of the device model's address
space. This can allow them to escalate their privileges to that of the
device model process.

VULNERABLE SYSTEMS
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

All Xen systems running HVM guests are potentially vulnerable to this
depending on the specific guest configuration. The default
configuration is vulnerable.

Guests using either the traditional "qemu-xen" or upstream qemu device
models are vulnerable.

MITIGATION
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

This issue can be avoided by only running PV guests or by configuring
HVM guests to not use the virtual console('vc') backend for any device.

For serial devices specify in your guest configuration:
&nbsp;&nbsp;&nbsp;&nbsp;serial =3D 'none'
in your guest configuration.

For parallel port devices the syntax is toolstack specific.
For xend specify in your guest configuration:
&nbsp;&nbsp;&nbsp;&nbsp;parallel =3D 'none'
For xl specify in your guest configuration:
&nbsp;&nbsp;&nbsp;&nbsp;xl: device_model_args =3D ['-parallel', 'none']

In both cases the default is to use the vulnerable 'vc' mode.

You can confirm whether or not you are vulnerable by pressing
Ctrl-Alt-&lt;N&gt; (for digit N) while connected to either the VNC or SDL
console. If you are able to switch to a window displaying "serial" or
"parallel" then you are vulnerable.

The issue can also be mitigated by enabling the stub domain device
model. In this case the attacked can only potentially gain control of
the stub domain and not of the entire system.

To enable stub domains specify in your guest configuration:
&nbsp;&nbsp;&nbsp;device_model =3D "stubdom-dm"

RESOLUTION
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Applying the appropriate attached patch(es) will resolve the issue.

PATCH INFORMATION
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

The attached patches resolve this issue

Traditional qemu tree
&nbsp;&nbsp;Xen 4.0, 4.1 and unstable         xsa17-qemu-xen-traditional-al=
l.patch

Upstream qemu tree (present in unstable only)
&nbsp;&nbsp;Xen unstable                      xsa17-qemu-xen-unstable.patch

$ sha256sum xsa17-*.patch
60215322d3fbbc2054dfc160a20d9e0811af88487c4edc2f6ea81dcd5cedf039  xsa17-qem=
u-xen-traditional-all.patch
7b4bb59e7757080e7806a8b8eeb6b78fa0ffdfbfb28a7a379f7edff285bffd88  xsa17-qem=
u-xen-unstable.patch
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iQEcBAEBAgAGBQJQRx1PAAoJEIP+FMlX6CvZUqUH/jeAAvQnoBp6YKzm78XSnnmk
GI2C/LhH0xqR3wFoEmWeMsiO4lrGrASX6T31NTvHa8sOtFqlNpTfRhwQybwYR3aa
cz9/4y2a54hD95P1nVmPF0PddmSP47QSpRdCj0projq1UGxIdwEhkNeSoM8h7dXO
MegqZClsvJMKd8XEcjBF5Qg7u9vLrXilCx5+It7XNE31Jxpkr/fozBb7FnNtDGJj
s4RN/UDU4Pu68XyZ7Dc5xEFdJW48tz4BIlxxXavILBRFSE1VEf7Gc8H9CsUtBPWB
C/LCUjpHkAOmqdgFhiLnZ2u+2s79U0dtPDJMNmqaGgWH+AqGkU9Nq8XXODTyY9k=3D
=3DgnuE
-----END PGP SIGNATURE-----
</PRE></DIV></BLOCKQUOTE></BODY></HTML>
--------=_MB49CA08F0-682A-4135-A2F6-956DD7751BF1--



--===============4802264192683208083==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============4802264192683208083==--



From xen-devel-bounces@lists.xen.org Fri Sep 07 19:38:46 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Sep 2012 19: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 1TA4Nl-0002cT-4n; Fri, 07 Sep 2012 19:38:25 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <nathan@gt.net>) id 1TA4Nj-0002cF-8M
	for xen-devel@lists.xen.org; Fri, 07 Sep 2012 19:38:23 +0000
Received: from [85.158.143.35:5643] by server-2.bemta-4.messagelabs.com id
	1C/A0-21239-E2D4A405; Fri, 07 Sep 2012 19:38:22 +0000
X-Env-Sender: nathan@gt.net
X-Msg-Ref: server-16.tower-21.messagelabs.com!1347046698!14722890!1
X-Originating-IP: [208.70.244.21]
X-SpamReason: No, hits=0.6 required=7.0 tests=BODY_RANDOM_LONG,
	HTML_50_60,HTML_MESSAGE
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18430 invoked from network); 7 Sep 2012 19:38:19 -0000
Received: from gossamer.nmsrv.com (HELO gossamer.nmsrv.com) (208.70.244.21)
	by server-16.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 7 Sep 2012 19:38:19 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gt.net; h=from:to:subject
	:date:content-type:in-reply-to:message-id:mime-version:reply-to;
	s=mail; bh=eccYW+NXSWljr1MDEIF1jjR1CLM=; b=K5lRpDAYj/iBP+Y0xUab
	vrjqkhoqU70k662PajUijouj/lLP0jMebtKJ7SHKHdLN0YX+soD+xCsaTzlWLwTO
	8sO41hLmkGpB+RCBy0KErmECUOuMka3GKk3ADjL5YNhaA2poxIQd+zkaDKgfYw+i
	8TXh36KhyMxMrAccB+X+0O4=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gt.net; h=from:to:subject
	:date:content-type:in-reply-to:message-id:mime-version:reply-to;
	q=dns; s=mail; b=fPcpUzhlk83c52TEpI4sE7dKEHVXJn76J2D4kulLjOvVV8
	nWQCGF9M31bZmPNunhpfZE+3Ugsd29Gv1vkRGla+Bd+ADmhNtOuYwVpFaM3OwHxP
	BJcsn1uOCIRoZnnN1b2R8j1wrspO0is+HFVseVbxDf9fNKo722A0AuJlxphEY=
Received: (qmail 26415 invoked from network); 7 Sep 2012 19:38:17 -0000
X-AntiVirus: Clean
Received: from gateway.gossamer-threads.com (HELO ?192.168.1.152?)
	(nathan@gt.net@208.70.247.145)
	by gossamer.nmsrv.com with ESMTPSA (AES128-SHA encrypted);
	7 Sep 2012 19:38:17 -0000
From: "Nathan March" <nathan@gt.net>
To: "Xen.org security team" <security@xen.org>, xen-devel@lists.xen.org,
	xen-users@lists.xen.org
Date: Fri, 07 Sep 2012 19:38:12 +0000
In-Reply-To: <emd0d6024e-114e-4969-a7b2-ef30ed5138a5@nathan>
Message-Id: <em31bfd957-9d6c-4b59-8e1c-ba1352e8d02c@nathan>
Mime-Version: 1.0
User-Agent: eM_Client/4.0.15145.0
Subject: Re: [Xen-devel] [Xen-users] Xen Security Advisory 17
 (CVE-2012-3515) - Qemu VT100 emulation vulnerability
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: Nathan March <nathan@gt.net>
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============4490533618569957710=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--===============4490533618569957710==
Content-Type: multipart/alternative;
 boundary="------=_MB8E0CD934-91C9-4BEF-81FF-850F253CC118"


--------=_MB8E0CD934-91C9-4BEF-81FF-850F253CC118
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; format=flowed; charset=utf-8

Same issue also applies to the xsa-19 patch.

- Nathan

------ Original Message ------
From: "Nathan March" <nathan@gt.net>
To: "Xen.org security team"=20
<security@xen.org>;xen-devel@lists.xen.org;xen-users@lists.xen.org;oss-secu=
rity@lists.openwall.com
Cc: "Xen.org security team" <security@xen.org>
Sent: 9/7/2012 12:33:42 PM
Subject: Re: [Xen-devel] [Xen-users] Xen Security Advisory 17=20
(CVE-2012-3515) - Qemu VT100 emulation vulnerability
>Hi All,

>I'm guessing this wasn't intentional, but the patch for xsa17 does not=20
>contain a complete path to the tools/ioemu-qemu-xen/ path:

>--- a/console.c
>+++ b/console.c

>Compared to all the other patches which provide a full path to the=20
>patched file:

>--- a/xen/include/asm-x86/debugreg.h Mon Aug 06 12:28:03 2012 +0100
>+++ b/xen/include/asm-x86/debugreg.h Wed Aug 15 12:00:21 2012 +0100

>Little annoying since it means you have to track down which console.c=20
>is being patched instead of just applying from the root xen build dir.

>- Nathan

>
>------ Original Message ------
>From: "Xen.org security team" <security@xen.org>
>To: xen-announce@lists.xen.org;xen-devel@lists.xen.org;xen-users@lists.xen=
.org;oss-security@lists.openwall.com
>Cc: "Xen.org security team" <security@xen.org>
>Sent: 9/5/2012 4:12:47 AM
>Subject: [Xen-users] Xen Security Advisory 17 (CVE-2012-3515) - Qemu=20
>VT100 emulation vulnerability
>>-----BEGIN PGP SIGNED MESSAGE-----
>>Hash: SHA1
>>
>>           Xen Security Advisory CVE-2012-3515 / XSA-17
>>                          version 2
>>
>>              Qemu VT100 emulation vulnerability
>>
>>UPDATES IN VERSION 2
>>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>>
>>Public release.
>>
>>ISSUE DESCRIPTION
>>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>>
>>The device model used by fully virtualised (HVM) domains, qemu, does
>>not properly handle escape VT100 sequences when emulating certain
>>devices with a virtual console backend.
>>
>>IMPACT
>>=3D=3D=3D=3D=3D=3D
>>
>>An attacker who has sufficient privilege to access a vulnerable device
>>within a guest can overwrite portions of the device model's address
>>space. This can allow them to escalate their privileges to that of the
>>device model process.
>>
>>VULNERABLE SYSTEMS
>>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>>
>>All Xen systems running HVM guests are potentially vulnerable to this
>>depending on the specific guest configuration. The default
>>configuration is vulnerable.
>>
>>Guests using either the traditional "qemu-xen" or upstream qemu device
>>models are vulnerable.
>>
>>MITIGATION
>>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>>
>>This issue can be avoided by only running PV guests or by configuring
>>HVM guests to not use the virtual console('vc') backend for any device.
>>
>>For serial devices specify in your guest configuration:
>>    serial =3D 'none'
>>in your guest configuration.
>>
>>For parallel port devices the syntax is toolstack specific.
>>For xend specify in your guest configuration:
>>    parallel =3D 'none'
>>For xl specify in your guest configuration:
>>    xl: device_model_args =3D ['-parallel', 'none']
>>
>>In both cases the default is to use the vulnerable 'vc' mode.
>>
>>You can confirm whether or not you are vulnerable by pressing
>>Ctrl-Alt-<N> (for digit N) while connected to either the VNC or SDL
>>console. If you are able to switch to a window displaying "serial" or
>>"parallel" then you are vulnerable.
>>
>>The issue can also be mitigated by enabling the stub domain device
>>model. In this case the attacked can only potentially gain control of
>>the stub domain and not of the entire system.
>>
>>To enable stub domains specify in your guest configuration:
>>   device_model =3D "stubdom-dm"
>>
>>RESOLUTION
>>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>>
>>Applying the appropriate attached patch(es) will resolve the issue.
>>
>>PATCH INFORMATION
>>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>>
>>The attached patches resolve this issue
>>
>>Traditional qemu tree
>>  Xen 4.0, 4.1 and unstable         xsa17-qemu-xen-traditional-all.patch
>>
>>Upstream qemu tree (present in unstable only)
>>  Xen unstable                      xsa17-qemu-xen-unstable.patch
>>
>>$ sha256sum xsa17-*.patch
>>60215322d3fbbc2054dfc160a20d9e0811af88487c4edc2f6ea81dcd5cedf039  xsa17-q=
emu-xen-traditional-all.patch
>>7b4bb59e7757080e7806a8b8eeb6b78fa0ffdfbfb28a7a379f7edff285bffd88  xsa17-q=
emu-xen-unstable.patch
>>-----BEGIN PGP SIGNATURE-----
>>Version: GnuPG v1.4.10 (GNU/Linux)
>>
>>iQEcBAEBAgAGBQJQRx1PAAoJEIP+FMlX6CvZUqUH/jeAAvQnoBp6YKzm78XSnnmk
>>GI2C/LhH0xqR3wFoEmWeMsiO4lrGrASX6T31NTvHa8sOtFqlNpTfRhwQybwYR3aa
>>cz9/4y2a54hD95P1nVmPF0PddmSP47QSpRdCj0projq1UGxIdwEhkNeSoM8h7dXO
>>MegqZClsvJMKd8XEcjBF5Qg7u9vLrXilCx5+It7XNE31Jxpkr/fozBb7FnNtDGJj
>>s4RN/UDU4Pu68XyZ7Dc5xEFdJW48tz4BIlxxXavILBRFSE1VEf7Gc8H9CsUtBPWB
>>C/LCUjpHkAOmqdgFhiLnZ2u+2s79U0dtPDJMNmqaGgWH+AqGkU9Nq8XXODTyY9k=3D
>>=3DgnuE
>>-----END PGP SIGNATURE-----
>>
>>

--------=_MB8E0CD934-91C9-4BEF-81FF-850F253CC118
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=utf-8

<HTML><HEAD>
<STYLE id=3DeMClientCss>blockquote.cite { margin-left: 5px; margin-right:=
 0px; padding-left: 10px; padding-right:0px; border-left: 1px solid #000000=
 }
.plain pre { font-family: monospace; font-size: 100%; font-weight: normal;=
 font-style: normal; }
body {font-family: Tahoma;font-size: 10pt;}
.plain pre {font-family: Tahoma;font-size: 10pt;}

#e41a6e6545f44911964222cfaeec7392 BLOCKQUOTE.cite
{BORDER-LEFT: #000000 1px solid; PADDING-LEFT: 10px; PADDING-RIGHT: 0px;=
 MARGIN-LEFT: 5px; MARGIN-RIGHT: 0px}
#e41a6e6545f44911964222cfaeec7392 .plain PRE
{FONT-STYLE: normal; FONT-FAMILY: monospace; FONT-SIZE: 100%; FONT-WEIGHT:=
 normal}
#e41a6e6545f44911964222cfaeec7392 BLOCKQUOTE.cite
{BORDER-LEFT: #000000 1px solid; PADDING-LEFT: 10px; PADDING-RIGHT: 0px;=
 MARGIN-LEFT: 5px; MARGIN-RIGHT: 0px}
#e41a6e6545f44911964222cfaeec7392 .plain PRE
{FONT-STYLE: normal; FONT-FAMILY: monospace; FONT-SIZE: 100%; FONT-WEIGHT:=
 normal}
#e41a6e6545f44911964222cfaeec7392=20
{FONT-FAMILY: Tahoma; FONT-SIZE: 10pt}
#e41a6e6545f44911964222cfaeec7392 .plain PRE
{FONT-FAMILY: Tahoma; FONT-SIZE: 10pt}
#e41a6e6545f44911964222cfaeec7392 #263c15780ff94333aaaf17642dbbef06 BLOCKQU=
OTE.cite
{BORDER-LEFT: #000000 1px solid; PADDING-LEFT: 10px; PADDING-RIGHT: 0px;=
 MARGIN-LEFT: 5px; MARGIN-RIGHT: 0px}
#e41a6e6545f44911964222cfaeec7392 #263c15780ff94333aaaf17642dbbef06 .plain=
 PRE
{FONT-STYLE: normal; FONT-FAMILY: monospace; FONT-SIZE: 100%; FONT-WEIGHT:=
 normal}
#e41a6e6545f44911964222cfaeec7392 #263c15780ff94333aaaf17642dbbef06
{FONT-FAMILY: Tahoma; FONT-SIZE: 10pt}
#e41a6e6545f44911964222cfaeec7392 #263c15780ff94333aaaf17642dbbef06 .plain=
 PRE
{FONT-FAMILY: Tahoma; FONT-SIZE: 10pt}
#e41a6e6545f44911964222cfaeec7392 UNKNOWN
{BORDER-LEFT: #000000 1px solid; PADDING-LEFT: 10px; PADDING-RIGHT: 0px;=
 MARGIN-LEFT: 5px; MARGIN-RIGHT: 0px}
#e41a6e6545f44911964222cfaeec7392 #1bd758ae7bd34680b7bcf93f3cde9dd9 .plain=
 PRE
{FONT-STYLE: normal; FONT-FAMILY: monospace; FONT-SIZE: 100%; FONT-WEIGHT:=
 normal}
#e41a6e6545f44911964222cfaeec7392 #1bd758ae7bd34680b7bcf93f3cde9dd9
{FONT-FAMILY: Tahoma; FONT-SIZE: 10pt}
#e41a6e6545f44911964222cfaeec7392 #1bd758ae7bd34680b7bcf93f3cde9dd9 .plain=
 PRE
{FONT-FAMILY: Tahoma; FONT-SIZE: 10pt}
#e41a6e6545f44911964222cfaeec7392 #1bd758ae7bd34680b7bcf93f3cde9dd9 #263c15=
780ff94333aaaf17642dbbef06 BLOCKQUOTE.cite
{BORDER-LEFT: #000000 1px solid; PADDING-LEFT: 10px; PADDING-RIGHT: 0px;=
 MARGIN-LEFT: 5px; MARGIN-RIGHT: 0px}
#e41a6e6545f44911964222cfaeec7392 #1bd758ae7bd34680b7bcf93f3cde9dd9 #263c15=
780ff94333aaaf17642dbbef06 .plain PRE
{FONT-STYLE: normal; FONT-FAMILY: monospace; FONT-SIZE: 100%; FONT-WEIGHT:=
 normal}
#e41a6e6545f44911964222cfaeec7392 #1bd758ae7bd34680b7bcf93f3cde9dd9 #263c15=
780ff94333aaaf17642dbbef06
{FONT-FAMILY: Tahoma; FONT-SIZE: 10pt}
#e41a6e6545f44911964222cfaeec7392 #1bd758ae7bd34680b7bcf93f3cde9dd9 #263c15=
780ff94333aaaf17642dbbef06 .plain PRE
{FONT-FAMILY: Tahoma; FONT-SIZE: 10pt}</STYLE>

<META content=3Dtext/html;charset=3Dutf-8 http-equiv=3DContent-Type></HEAD>
<BODY scroll=3Dauto class>
<DIV>Same issue also applies to the xsa-19 patch.</DIV>
<DIV>&nbsp;</DIV>
<DIV>- Nathan</DIV>
<DIV><BR>------ Original Message ------<BR>From: "Nathan March" &lt;nathan@=
gt.net&gt;<BR>To: "Xen.org security team" &lt;security@xen.org&gt;;xen-deve=
l@lists.xen.org;xen-users@lists.xen.org;oss-security@lists.openwall.com<BR>=
Cc: "Xen.org security team" &lt;security@xen.org&gt;<BR>Sent: 9/7/2012 12:3=
3:42 PM<BR>Subject: Re: [Xen-devel] [Xen-users] Xen Security Advisory 17=
 (CVE-2012-3515) - Qemu VT100 emulation vulnerability<BR></DIV>
<BLOCKQUOTE class=3Dcite cite=3Demd0d6024e-114e-4969-a7b2-ef30ed5138a5@nath=
an type=3D"cite">
<DIV id=3De41a6e6545f44911964222cfaeec7392>
<DIV>Hi All,</DIV>
<DIV>&nbsp;</DIV>
<DIV>I'm guessing this wasn't intentional, but the patch for xsa17 does =
not contain a complete path to the tools/ioemu-qemu-xen/ path:</DIV>
<DIV>&nbsp;</DIV>
<DIV>--- a/console.c<BR>+++ b/console.c</DIV>
<DIV>&nbsp;</DIV>
<DIV>Compared to all the other patches <SPAN id=3D1bd758ae7bd34680b7bcf93f3=
cde9dd9>which provide a full path to the patched file:</SPAN></DIV>
<DIV>&nbsp;</DIV>
<DIV>--- a/xen/include/asm-x86/debugreg.h Mon Aug 06 12:28:03 2012 +0100<BR=
>+++ b/xen/include/asm-x86/debugreg.h Wed Aug 15 12:00:21 2012 +0100</DIV>
<DIV>&nbsp;</DIV>
<DIV>Little annoying since it means you have to track down which console.c=
 is being patched instead of just applying from the root xen build dir.</DI=
V>
<DIV>&nbsp;</DIV>
<DIV>- Nathan</DIV>
<DIV>&nbsp;</DIV>
<DIV><BR>------ Original Message ------<BR>From: "Xen.org security team"=
 &lt;<A href=3D"mailto:security@xen.org"><A href=3D"mailto:security@xen.org=
">security@xen.org</A></A>&gt;<BR>To: <A href=3D"mailto:xen-announce@lists.=
xen.org"><A href=3D"mailto:xen-announce@lists.xen.org">xen-announce@lists.x=
en.org</A></A>;<A href=3D"mailto:xen-devel@lists.xen.org"><A href=3D"mailto=
:xen-devel@lists.xen.org">xen-devel@lists.xen.org</A></A>;<A href=3D"mailto=
:xen-users@lists.xen.org"><A href=3D"mailto:xen-users@lists.xen.org">xen-us=
ers@lists.xen.org</A></A>;<A href=3D"mailto:oss-security@lists.openwall.com=
"><A href=3D"mailto:oss-security@lists.openwall.com">oss-security@lists.ope=
nwall.com</A></A><BR>Cc: "Xen.org security team" &lt;<A href=3D"mailto:secu=
rity@xen.org"><A href=3D"mailto:security@xen.org">security@xen.org</A></A>&=
gt;<BR>Sent: 9/5/2012 4:12:47 AM<BR>Subject: [Xen-users] Xen Security Advis=
ory 17 (CVE-2012-3515) - Qemu VT100 emulation vulnerability<BR></DIV>
<BLOCKQUOTE class=3Dcite cite=3DE1T9DXL-0005Qu-97@xenbits.xen.org type=3D=
"cite">
<DIV id=3D263c15780ff94333aaaf17642dbbef06><PRE style=3D"WORD-WRAP: break-w=
ord">-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Xen Secur=
ity Advisory CVE-2012-3515 / XSA-17
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;version 2

&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;Qemu VT100 emulation vulnerability

UPDATES IN VERSION 2
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Public release.

ISSUE DESCRIPTION
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

The device model used by fully virtualised (HVM) domains, qemu, does
not properly handle escape VT100 sequences when emulating certain
devices with a virtual console backend.

IMPACT
=3D=3D=3D=3D=3D=3D

An attacker who has sufficient privilege to access a vulnerable device
within a guest can overwrite portions of the device model's address
space. This can allow them to escalate their privileges to that of the
device model process.

VULNERABLE SYSTEMS
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

All Xen systems running HVM guests are potentially vulnerable to this
depending on the specific guest configuration. The default
configuration is vulnerable.

Guests using either the traditional "qemu-xen" or upstream qemu device
models are vulnerable.

MITIGATION
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

This issue can be avoided by only running PV guests or by configuring
HVM guests to not use the virtual console('vc') backend for any device.

For serial devices specify in your guest configuration:
&nbsp;&nbsp;&nbsp;&nbsp;serial =3D 'none'
in your guest configuration.

For parallel port devices the syntax is toolstack specific.
For xend specify in your guest configuration:
&nbsp;&nbsp;&nbsp;&nbsp;parallel =3D 'none'
For xl specify in your guest configuration:
&nbsp;&nbsp;&nbsp;&nbsp;xl: device_model_args =3D ['-parallel', 'none']

In both cases the default is to use the vulnerable 'vc' mode.

You can confirm whether or not you are vulnerable by pressing
Ctrl-Alt-&lt;N&gt; (for digit N) while connected to either the VNC or SDL
console. If you are able to switch to a window displaying "serial" or
"parallel" then you are vulnerable.

The issue can also be mitigated by enabling the stub domain device
model. In this case the attacked can only potentially gain control of
the stub domain and not of the entire system.

To enable stub domains specify in your guest configuration:
&nbsp;&nbsp;&nbsp;device_model =3D "stubdom-dm"

RESOLUTION
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Applying the appropriate attached patch(es) will resolve the issue.

PATCH INFORMATION
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

The attached patches resolve this issue

Traditional qemu tree
&nbsp;&nbsp;Xen 4.0, 4.1 and unstable         xsa17-qemu-xen-traditional-al=
l.patch

Upstream qemu tree (present in unstable only)
&nbsp;&nbsp;Xen unstable                      xsa17-qemu-xen-unstable.patch

$ sha256sum xsa17-*.patch
60215322d3fbbc2054dfc160a20d9e0811af88487c4edc2f6ea81dcd5cedf039  xsa17-qem=
u-xen-traditional-all.patch
7b4bb59e7757080e7806a8b8eeb6b78fa0ffdfbfb28a7a379f7edff285bffd88  xsa17-qem=
u-xen-unstable.patch
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iQEcBAEBAgAGBQJQRx1PAAoJEIP+FMlX6CvZUqUH/jeAAvQnoBp6YKzm78XSnnmk
GI2C/LhH0xqR3wFoEmWeMsiO4lrGrASX6T31NTvHa8sOtFqlNpTfRhwQybwYR3aa
cz9/4y2a54hD95P1nVmPF0PddmSP47QSpRdCj0projq1UGxIdwEhkNeSoM8h7dXO
MegqZClsvJMKd8XEcjBF5Qg7u9vLrXilCx5+It7XNE31Jxpkr/fozBb7FnNtDGJj
s4RN/UDU4Pu68XyZ7Dc5xEFdJW48tz4BIlxxXavILBRFSE1VEf7Gc8H9CsUtBPWB
C/LCUjpHkAOmqdgFhiLnZ2u+2s79U0dtPDJMNmqaGgWH+AqGkU9Nq8XXODTyY9k=3D
=3DgnuE
-----END PGP SIGNATURE-----
</PRE></DIV></BLOCKQUOTE></DIV></BLOCKQUOTE></BODY></HTML>
--------=_MB8E0CD934-91C9-4BEF-81FF-850F253CC118--



--===============4490533618569957710==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============4490533618569957710==--



From xen-devel-bounces@lists.xen.org Fri Sep 07 19:38:46 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Sep 2012 19: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 1TA4Nl-0002cT-4n; Fri, 07 Sep 2012 19:38:25 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <nathan@gt.net>) id 1TA4Nj-0002cF-8M
	for xen-devel@lists.xen.org; Fri, 07 Sep 2012 19:38:23 +0000
Received: from [85.158.143.35:5643] by server-2.bemta-4.messagelabs.com id
	1C/A0-21239-E2D4A405; Fri, 07 Sep 2012 19:38:22 +0000
X-Env-Sender: nathan@gt.net
X-Msg-Ref: server-16.tower-21.messagelabs.com!1347046698!14722890!1
X-Originating-IP: [208.70.244.21]
X-SpamReason: No, hits=0.6 required=7.0 tests=BODY_RANDOM_LONG,
	HTML_50_60,HTML_MESSAGE
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18430 invoked from network); 7 Sep 2012 19:38:19 -0000
Received: from gossamer.nmsrv.com (HELO gossamer.nmsrv.com) (208.70.244.21)
	by server-16.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 7 Sep 2012 19:38:19 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gt.net; h=from:to:subject
	:date:content-type:in-reply-to:message-id:mime-version:reply-to;
	s=mail; bh=eccYW+NXSWljr1MDEIF1jjR1CLM=; b=K5lRpDAYj/iBP+Y0xUab
	vrjqkhoqU70k662PajUijouj/lLP0jMebtKJ7SHKHdLN0YX+soD+xCsaTzlWLwTO
	8sO41hLmkGpB+RCBy0KErmECUOuMka3GKk3ADjL5YNhaA2poxIQd+zkaDKgfYw+i
	8TXh36KhyMxMrAccB+X+0O4=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gt.net; h=from:to:subject
	:date:content-type:in-reply-to:message-id:mime-version:reply-to;
	q=dns; s=mail; b=fPcpUzhlk83c52TEpI4sE7dKEHVXJn76J2D4kulLjOvVV8
	nWQCGF9M31bZmPNunhpfZE+3Ugsd29Gv1vkRGla+Bd+ADmhNtOuYwVpFaM3OwHxP
	BJcsn1uOCIRoZnnN1b2R8j1wrspO0is+HFVseVbxDf9fNKo722A0AuJlxphEY=
Received: (qmail 26415 invoked from network); 7 Sep 2012 19:38:17 -0000
X-AntiVirus: Clean
Received: from gateway.gossamer-threads.com (HELO ?192.168.1.152?)
	(nathan@gt.net@208.70.247.145)
	by gossamer.nmsrv.com with ESMTPSA (AES128-SHA encrypted);
	7 Sep 2012 19:38:17 -0000
From: "Nathan March" <nathan@gt.net>
To: "Xen.org security team" <security@xen.org>, xen-devel@lists.xen.org,
	xen-users@lists.xen.org
Date: Fri, 07 Sep 2012 19:38:12 +0000
In-Reply-To: <emd0d6024e-114e-4969-a7b2-ef30ed5138a5@nathan>
Message-Id: <em31bfd957-9d6c-4b59-8e1c-ba1352e8d02c@nathan>
Mime-Version: 1.0
User-Agent: eM_Client/4.0.15145.0
Subject: Re: [Xen-devel] [Xen-users] Xen Security Advisory 17
 (CVE-2012-3515) - Qemu VT100 emulation vulnerability
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: Nathan March <nathan@gt.net>
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============4490533618569957710=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--===============4490533618569957710==
Content-Type: multipart/alternative;
 boundary="------=_MB8E0CD934-91C9-4BEF-81FF-850F253CC118"


--------=_MB8E0CD934-91C9-4BEF-81FF-850F253CC118
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; format=flowed; charset=utf-8

Same issue also applies to the xsa-19 patch.

- Nathan

------ Original Message ------
From: "Nathan March" <nathan@gt.net>
To: "Xen.org security team"=20
<security@xen.org>;xen-devel@lists.xen.org;xen-users@lists.xen.org;oss-secu=
rity@lists.openwall.com
Cc: "Xen.org security team" <security@xen.org>
Sent: 9/7/2012 12:33:42 PM
Subject: Re: [Xen-devel] [Xen-users] Xen Security Advisory 17=20
(CVE-2012-3515) - Qemu VT100 emulation vulnerability
>Hi All,

>I'm guessing this wasn't intentional, but the patch for xsa17 does not=20
>contain a complete path to the tools/ioemu-qemu-xen/ path:

>--- a/console.c
>+++ b/console.c

>Compared to all the other patches which provide a full path to the=20
>patched file:

>--- a/xen/include/asm-x86/debugreg.h Mon Aug 06 12:28:03 2012 +0100
>+++ b/xen/include/asm-x86/debugreg.h Wed Aug 15 12:00:21 2012 +0100

>Little annoying since it means you have to track down which console.c=20
>is being patched instead of just applying from the root xen build dir.

>- Nathan

>
>------ Original Message ------
>From: "Xen.org security team" <security@xen.org>
>To: xen-announce@lists.xen.org;xen-devel@lists.xen.org;xen-users@lists.xen=
.org;oss-security@lists.openwall.com
>Cc: "Xen.org security team" <security@xen.org>
>Sent: 9/5/2012 4:12:47 AM
>Subject: [Xen-users] Xen Security Advisory 17 (CVE-2012-3515) - Qemu=20
>VT100 emulation vulnerability
>>-----BEGIN PGP SIGNED MESSAGE-----
>>Hash: SHA1
>>
>>           Xen Security Advisory CVE-2012-3515 / XSA-17
>>                          version 2
>>
>>              Qemu VT100 emulation vulnerability
>>
>>UPDATES IN VERSION 2
>>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>>
>>Public release.
>>
>>ISSUE DESCRIPTION
>>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>>
>>The device model used by fully virtualised (HVM) domains, qemu, does
>>not properly handle escape VT100 sequences when emulating certain
>>devices with a virtual console backend.
>>
>>IMPACT
>>=3D=3D=3D=3D=3D=3D
>>
>>An attacker who has sufficient privilege to access a vulnerable device
>>within a guest can overwrite portions of the device model's address
>>space. This can allow them to escalate their privileges to that of the
>>device model process.
>>
>>VULNERABLE SYSTEMS
>>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>>
>>All Xen systems running HVM guests are potentially vulnerable to this
>>depending on the specific guest configuration. The default
>>configuration is vulnerable.
>>
>>Guests using either the traditional "qemu-xen" or upstream qemu device
>>models are vulnerable.
>>
>>MITIGATION
>>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>>
>>This issue can be avoided by only running PV guests or by configuring
>>HVM guests to not use the virtual console('vc') backend for any device.
>>
>>For serial devices specify in your guest configuration:
>>    serial =3D 'none'
>>in your guest configuration.
>>
>>For parallel port devices the syntax is toolstack specific.
>>For xend specify in your guest configuration:
>>    parallel =3D 'none'
>>For xl specify in your guest configuration:
>>    xl: device_model_args =3D ['-parallel', 'none']
>>
>>In both cases the default is to use the vulnerable 'vc' mode.
>>
>>You can confirm whether or not you are vulnerable by pressing
>>Ctrl-Alt-<N> (for digit N) while connected to either the VNC or SDL
>>console. If you are able to switch to a window displaying "serial" or
>>"parallel" then you are vulnerable.
>>
>>The issue can also be mitigated by enabling the stub domain device
>>model. In this case the attacked can only potentially gain control of
>>the stub domain and not of the entire system.
>>
>>To enable stub domains specify in your guest configuration:
>>   device_model =3D "stubdom-dm"
>>
>>RESOLUTION
>>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>>
>>Applying the appropriate attached patch(es) will resolve the issue.
>>
>>PATCH INFORMATION
>>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>>
>>The attached patches resolve this issue
>>
>>Traditional qemu tree
>>  Xen 4.0, 4.1 and unstable         xsa17-qemu-xen-traditional-all.patch
>>
>>Upstream qemu tree (present in unstable only)
>>  Xen unstable                      xsa17-qemu-xen-unstable.patch
>>
>>$ sha256sum xsa17-*.patch
>>60215322d3fbbc2054dfc160a20d9e0811af88487c4edc2f6ea81dcd5cedf039  xsa17-q=
emu-xen-traditional-all.patch
>>7b4bb59e7757080e7806a8b8eeb6b78fa0ffdfbfb28a7a379f7edff285bffd88  xsa17-q=
emu-xen-unstable.patch
>>-----BEGIN PGP SIGNATURE-----
>>Version: GnuPG v1.4.10 (GNU/Linux)
>>
>>iQEcBAEBAgAGBQJQRx1PAAoJEIP+FMlX6CvZUqUH/jeAAvQnoBp6YKzm78XSnnmk
>>GI2C/LhH0xqR3wFoEmWeMsiO4lrGrASX6T31NTvHa8sOtFqlNpTfRhwQybwYR3aa
>>cz9/4y2a54hD95P1nVmPF0PddmSP47QSpRdCj0projq1UGxIdwEhkNeSoM8h7dXO
>>MegqZClsvJMKd8XEcjBF5Qg7u9vLrXilCx5+It7XNE31Jxpkr/fozBb7FnNtDGJj
>>s4RN/UDU4Pu68XyZ7Dc5xEFdJW48tz4BIlxxXavILBRFSE1VEf7Gc8H9CsUtBPWB
>>C/LCUjpHkAOmqdgFhiLnZ2u+2s79U0dtPDJMNmqaGgWH+AqGkU9Nq8XXODTyY9k=3D
>>=3DgnuE
>>-----END PGP SIGNATURE-----
>>
>>

--------=_MB8E0CD934-91C9-4BEF-81FF-850F253CC118
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=utf-8

<HTML><HEAD>
<STYLE id=3DeMClientCss>blockquote.cite { margin-left: 5px; margin-right:=
 0px; padding-left: 10px; padding-right:0px; border-left: 1px solid #000000=
 }
.plain pre { font-family: monospace; font-size: 100%; font-weight: normal;=
 font-style: normal; }
body {font-family: Tahoma;font-size: 10pt;}
.plain pre {font-family: Tahoma;font-size: 10pt;}

#e41a6e6545f44911964222cfaeec7392 BLOCKQUOTE.cite
{BORDER-LEFT: #000000 1px solid; PADDING-LEFT: 10px; PADDING-RIGHT: 0px;=
 MARGIN-LEFT: 5px; MARGIN-RIGHT: 0px}
#e41a6e6545f44911964222cfaeec7392 .plain PRE
{FONT-STYLE: normal; FONT-FAMILY: monospace; FONT-SIZE: 100%; FONT-WEIGHT:=
 normal}
#e41a6e6545f44911964222cfaeec7392 BLOCKQUOTE.cite
{BORDER-LEFT: #000000 1px solid; PADDING-LEFT: 10px; PADDING-RIGHT: 0px;=
 MARGIN-LEFT: 5px; MARGIN-RIGHT: 0px}
#e41a6e6545f44911964222cfaeec7392 .plain PRE
{FONT-STYLE: normal; FONT-FAMILY: monospace; FONT-SIZE: 100%; FONT-WEIGHT:=
 normal}
#e41a6e6545f44911964222cfaeec7392=20
{FONT-FAMILY: Tahoma; FONT-SIZE: 10pt}
#e41a6e6545f44911964222cfaeec7392 .plain PRE
{FONT-FAMILY: Tahoma; FONT-SIZE: 10pt}
#e41a6e6545f44911964222cfaeec7392 #263c15780ff94333aaaf17642dbbef06 BLOCKQU=
OTE.cite
{BORDER-LEFT: #000000 1px solid; PADDING-LEFT: 10px; PADDING-RIGHT: 0px;=
 MARGIN-LEFT: 5px; MARGIN-RIGHT: 0px}
#e41a6e6545f44911964222cfaeec7392 #263c15780ff94333aaaf17642dbbef06 .plain=
 PRE
{FONT-STYLE: normal; FONT-FAMILY: monospace; FONT-SIZE: 100%; FONT-WEIGHT:=
 normal}
#e41a6e6545f44911964222cfaeec7392 #263c15780ff94333aaaf17642dbbef06
{FONT-FAMILY: Tahoma; FONT-SIZE: 10pt}
#e41a6e6545f44911964222cfaeec7392 #263c15780ff94333aaaf17642dbbef06 .plain=
 PRE
{FONT-FAMILY: Tahoma; FONT-SIZE: 10pt}
#e41a6e6545f44911964222cfaeec7392 UNKNOWN
{BORDER-LEFT: #000000 1px solid; PADDING-LEFT: 10px; PADDING-RIGHT: 0px;=
 MARGIN-LEFT: 5px; MARGIN-RIGHT: 0px}
#e41a6e6545f44911964222cfaeec7392 #1bd758ae7bd34680b7bcf93f3cde9dd9 .plain=
 PRE
{FONT-STYLE: normal; FONT-FAMILY: monospace; FONT-SIZE: 100%; FONT-WEIGHT:=
 normal}
#e41a6e6545f44911964222cfaeec7392 #1bd758ae7bd34680b7bcf93f3cde9dd9
{FONT-FAMILY: Tahoma; FONT-SIZE: 10pt}
#e41a6e6545f44911964222cfaeec7392 #1bd758ae7bd34680b7bcf93f3cde9dd9 .plain=
 PRE
{FONT-FAMILY: Tahoma; FONT-SIZE: 10pt}
#e41a6e6545f44911964222cfaeec7392 #1bd758ae7bd34680b7bcf93f3cde9dd9 #263c15=
780ff94333aaaf17642dbbef06 BLOCKQUOTE.cite
{BORDER-LEFT: #000000 1px solid; PADDING-LEFT: 10px; PADDING-RIGHT: 0px;=
 MARGIN-LEFT: 5px; MARGIN-RIGHT: 0px}
#e41a6e6545f44911964222cfaeec7392 #1bd758ae7bd34680b7bcf93f3cde9dd9 #263c15=
780ff94333aaaf17642dbbef06 .plain PRE
{FONT-STYLE: normal; FONT-FAMILY: monospace; FONT-SIZE: 100%; FONT-WEIGHT:=
 normal}
#e41a6e6545f44911964222cfaeec7392 #1bd758ae7bd34680b7bcf93f3cde9dd9 #263c15=
780ff94333aaaf17642dbbef06
{FONT-FAMILY: Tahoma; FONT-SIZE: 10pt}
#e41a6e6545f44911964222cfaeec7392 #1bd758ae7bd34680b7bcf93f3cde9dd9 #263c15=
780ff94333aaaf17642dbbef06 .plain PRE
{FONT-FAMILY: Tahoma; FONT-SIZE: 10pt}</STYLE>

<META content=3Dtext/html;charset=3Dutf-8 http-equiv=3DContent-Type></HEAD>
<BODY scroll=3Dauto class>
<DIV>Same issue also applies to the xsa-19 patch.</DIV>
<DIV>&nbsp;</DIV>
<DIV>- Nathan</DIV>
<DIV><BR>------ Original Message ------<BR>From: "Nathan March" &lt;nathan@=
gt.net&gt;<BR>To: "Xen.org security team" &lt;security@xen.org&gt;;xen-deve=
l@lists.xen.org;xen-users@lists.xen.org;oss-security@lists.openwall.com<BR>=
Cc: "Xen.org security team" &lt;security@xen.org&gt;<BR>Sent: 9/7/2012 12:3=
3:42 PM<BR>Subject: Re: [Xen-devel] [Xen-users] Xen Security Advisory 17=
 (CVE-2012-3515) - Qemu VT100 emulation vulnerability<BR></DIV>
<BLOCKQUOTE class=3Dcite cite=3Demd0d6024e-114e-4969-a7b2-ef30ed5138a5@nath=
an type=3D"cite">
<DIV id=3De41a6e6545f44911964222cfaeec7392>
<DIV>Hi All,</DIV>
<DIV>&nbsp;</DIV>
<DIV>I'm guessing this wasn't intentional, but the patch for xsa17 does =
not contain a complete path to the tools/ioemu-qemu-xen/ path:</DIV>
<DIV>&nbsp;</DIV>
<DIV>--- a/console.c<BR>+++ b/console.c</DIV>
<DIV>&nbsp;</DIV>
<DIV>Compared to all the other patches <SPAN id=3D1bd758ae7bd34680b7bcf93f3=
cde9dd9>which provide a full path to the patched file:</SPAN></DIV>
<DIV>&nbsp;</DIV>
<DIV>--- a/xen/include/asm-x86/debugreg.h Mon Aug 06 12:28:03 2012 +0100<BR=
>+++ b/xen/include/asm-x86/debugreg.h Wed Aug 15 12:00:21 2012 +0100</DIV>
<DIV>&nbsp;</DIV>
<DIV>Little annoying since it means you have to track down which console.c=
 is being patched instead of just applying from the root xen build dir.</DI=
V>
<DIV>&nbsp;</DIV>
<DIV>- Nathan</DIV>
<DIV>&nbsp;</DIV>
<DIV><BR>------ Original Message ------<BR>From: "Xen.org security team"=
 &lt;<A href=3D"mailto:security@xen.org"><A href=3D"mailto:security@xen.org=
">security@xen.org</A></A>&gt;<BR>To: <A href=3D"mailto:xen-announce@lists.=
xen.org"><A href=3D"mailto:xen-announce@lists.xen.org">xen-announce@lists.x=
en.org</A></A>;<A href=3D"mailto:xen-devel@lists.xen.org"><A href=3D"mailto=
:xen-devel@lists.xen.org">xen-devel@lists.xen.org</A></A>;<A href=3D"mailto=
:xen-users@lists.xen.org"><A href=3D"mailto:xen-users@lists.xen.org">xen-us=
ers@lists.xen.org</A></A>;<A href=3D"mailto:oss-security@lists.openwall.com=
"><A href=3D"mailto:oss-security@lists.openwall.com">oss-security@lists.ope=
nwall.com</A></A><BR>Cc: "Xen.org security team" &lt;<A href=3D"mailto:secu=
rity@xen.org"><A href=3D"mailto:security@xen.org">security@xen.org</A></A>&=
gt;<BR>Sent: 9/5/2012 4:12:47 AM<BR>Subject: [Xen-users] Xen Security Advis=
ory 17 (CVE-2012-3515) - Qemu VT100 emulation vulnerability<BR></DIV>
<BLOCKQUOTE class=3Dcite cite=3DE1T9DXL-0005Qu-97@xenbits.xen.org type=3D=
"cite">
<DIV id=3D263c15780ff94333aaaf17642dbbef06><PRE style=3D"WORD-WRAP: break-w=
ord">-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Xen Secur=
ity Advisory CVE-2012-3515 / XSA-17
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;version 2

&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;Qemu VT100 emulation vulnerability

UPDATES IN VERSION 2
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Public release.

ISSUE DESCRIPTION
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

The device model used by fully virtualised (HVM) domains, qemu, does
not properly handle escape VT100 sequences when emulating certain
devices with a virtual console backend.

IMPACT
=3D=3D=3D=3D=3D=3D

An attacker who has sufficient privilege to access a vulnerable device
within a guest can overwrite portions of the device model's address
space. This can allow them to escalate their privileges to that of the
device model process.

VULNERABLE SYSTEMS
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

All Xen systems running HVM guests are potentially vulnerable to this
depending on the specific guest configuration. The default
configuration is vulnerable.

Guests using either the traditional "qemu-xen" or upstream qemu device
models are vulnerable.

MITIGATION
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

This issue can be avoided by only running PV guests or by configuring
HVM guests to not use the virtual console('vc') backend for any device.

For serial devices specify in your guest configuration:
&nbsp;&nbsp;&nbsp;&nbsp;serial =3D 'none'
in your guest configuration.

For parallel port devices the syntax is toolstack specific.
For xend specify in your guest configuration:
&nbsp;&nbsp;&nbsp;&nbsp;parallel =3D 'none'
For xl specify in your guest configuration:
&nbsp;&nbsp;&nbsp;&nbsp;xl: device_model_args =3D ['-parallel', 'none']

In both cases the default is to use the vulnerable 'vc' mode.

You can confirm whether or not you are vulnerable by pressing
Ctrl-Alt-&lt;N&gt; (for digit N) while connected to either the VNC or SDL
console. If you are able to switch to a window displaying "serial" or
"parallel" then you are vulnerable.

The issue can also be mitigated by enabling the stub domain device
model. In this case the attacked can only potentially gain control of
the stub domain and not of the entire system.

To enable stub domains specify in your guest configuration:
&nbsp;&nbsp;&nbsp;device_model =3D "stubdom-dm"

RESOLUTION
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Applying the appropriate attached patch(es) will resolve the issue.

PATCH INFORMATION
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

The attached patches resolve this issue

Traditional qemu tree
&nbsp;&nbsp;Xen 4.0, 4.1 and unstable         xsa17-qemu-xen-traditional-al=
l.patch

Upstream qemu tree (present in unstable only)
&nbsp;&nbsp;Xen unstable                      xsa17-qemu-xen-unstable.patch

$ sha256sum xsa17-*.patch
60215322d3fbbc2054dfc160a20d9e0811af88487c4edc2f6ea81dcd5cedf039  xsa17-qem=
u-xen-traditional-all.patch
7b4bb59e7757080e7806a8b8eeb6b78fa0ffdfbfb28a7a379f7edff285bffd88  xsa17-qem=
u-xen-unstable.patch
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iQEcBAEBAgAGBQJQRx1PAAoJEIP+FMlX6CvZUqUH/jeAAvQnoBp6YKzm78XSnnmk
GI2C/LhH0xqR3wFoEmWeMsiO4lrGrASX6T31NTvHa8sOtFqlNpTfRhwQybwYR3aa
cz9/4y2a54hD95P1nVmPF0PddmSP47QSpRdCj0projq1UGxIdwEhkNeSoM8h7dXO
MegqZClsvJMKd8XEcjBF5Qg7u9vLrXilCx5+It7XNE31Jxpkr/fozBb7FnNtDGJj
s4RN/UDU4Pu68XyZ7Dc5xEFdJW48tz4BIlxxXavILBRFSE1VEf7Gc8H9CsUtBPWB
C/LCUjpHkAOmqdgFhiLnZ2u+2s79U0dtPDJMNmqaGgWH+AqGkU9Nq8XXODTyY9k=3D
=3DgnuE
-----END PGP SIGNATURE-----
</PRE></DIV></BLOCKQUOTE></DIV></BLOCKQUOTE></BODY></HTML>
--------=_MB8E0CD934-91C9-4BEF-81FF-850F253CC118--



--===============4490533618569957710==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============4490533618569957710==--



From xen-devel-bounces@lists.xen.org Fri Sep 07 19:40:28 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Sep 2012 19: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 1TA4PO-0002rI-Fx; Fri, 07 Sep 2012 19:40:06 +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 1TA4PM-0002r0-UN
	for xen-devel@lists.xen.org; Fri, 07 Sep 2012 19:40:05 +0000
Received: from [85.158.139.83:61858] by server-6.bemta-5.messagelabs.com id
	D7/1D-21336-39D4A405; Fri, 07 Sep 2012 19:40:03 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1347046791!17961623!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNzc0ODA=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3414 invoked from network); 7 Sep 2012 19:39:52 -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;
	7 Sep 2012 19:39:52 -0000
X-IronPort-AV: E=Sophos;i="4.80,387,1344211200"; 
	d="scan'208,217";a="207452757"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Sep 2012 19:39:50 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1;
	Fri, 7 Sep 2012 15:39:50 -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 1TA4P7-000385-Nj	for
	xen-devel@lists.xen.org; Fri, 07 Sep 2012 20:39:49 +0100
Message-ID: <504A4D85.9080705@citrix.com>
Date: Fri, 7 Sep 2012 20:39:49 +0100
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:14.0) Gecko/20120714 Thunderbird/14.0
MIME-Version: 1.0
To: xen-devel@lists.xen.org
References: <emd0d6024e-114e-4969-a7b2-ef30ed5138a5@nathan>
In-Reply-To: <emd0d6024e-114e-4969-a7b2-ef30ed5138a5@nathan>
X-Enigmail-Version: 1.4.4
Subject: Re: [Xen-devel] [Xen-users] Xen Security Advisory 17
 (CVE-2012-3515) - Qemu VT100 emulation vulnerability
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0732460400532653199=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============0732460400532653199==
Content-Type: multipart/alternative;
	boundary="------------070604010102000502080808"

--------------070604010102000502080808
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit

On 07/09/12 20:33, Nathan March wrote:
> Hi All,
>
> I'm guessing this wasn't intentional, but the patch for xsa17 does not
contain a complete path to the tools/ioemu-qemu-xen/ path:

This is because it applies to the qemu repository, not the xen repository.

It just so happens that the xen repository build system will pull it
into a subdir to build it, if you dont do so manually.

~Andrew

> 
> --- a/console.c
> +++ b/console.c
>
> Compared to all the other patches which provide a full path to the
patched file:
>
> --- a/xen/include/asm-x86/debugreg.h Mon Aug 06 12:28:03 2012 +0100
> +++ b/xen/include/asm-x86/debugreg.h Wed Aug 15 12:00:21 2012 +0100
>
> Little annoying since it means you have to track down which console.c
is being patched instead of just applying from the root xen build dir.
>
> - Nathan
>
>
> ------ Original Message ------
> From: "Xen.org security team" <security@xen.org>
> To:
xen-announce@lists.xen.org;xen-devel@lists.xen.org;xen-users@lists.xen.org;oss-security@lists.openwall.com
> Cc: "Xen.org security team" <security@xen.org>
> Sent: 9/5/2012 4:12:47 AM
> Subject: [Xen-users] Xen Security Advisory 17 (CVE-2012-3515) - Qemu
VT100 emulation vulnerability
>            Xen Security Advisory CVE-2012-3515 / XSA-17
>                           version 2
>
>               Qemu VT100 emulation vulnerability
>
> UPDATES IN VERSION 2
> ====================
>
> Public release.
>
> ISSUE DESCRIPTION
> =================
>
> The device model used by fully virtualised (HVM) domains, qemu, does
> not properly handle escape VT100 sequences when emulating certain
> devices with a virtual console backend.
>
> IMPACT
> ======
>
> An attacker who has sufficient privilege to access a vulnerable device
> within a guest can overwrite portions of the device model's address
> space. This can allow them to escalate their privileges to that of the
> device model process.
>
> VULNERABLE SYSTEMS
> ==================
>
> All Xen systems running HVM guests are potentially vulnerable to this
> depending on the specific guest configuration. The default
> configuration is vulnerable.
>
> Guests using either the traditional "qemu-xen" or upstream qemu device
> models are vulnerable.
>
> MITIGATION
> ==========
>
> This issue can be avoided by only running PV guests or by configuring
> HVM guests to not use the virtual console('vc') backend for any device.
>
> For serial devices specify in your guest configuration:
>     serial = 'none'
> in your guest configuration.
>
> For parallel port devices the syntax is toolstack specific.
> For xend specify in your guest configuration:
>     parallel = 'none'
> For xl specify in your guest configuration:
>     xl: device_model_args = ['-parallel', 'none']
>
> In both cases the default is to use the vulnerable 'vc' mode.
>
> You can confirm whether or not you are vulnerable by pressing
> Ctrl-Alt-<N> (for digit N) while connected to either the VNC or SDL
> console. If you are able to switch to a window displaying "serial" or
> "parallel" then you are vulnerable.
>
> The issue can also be mitigated by enabling the stub domain device
> model. In this case the attacked can only potentially gain control of
> the stub domain and not of the entire system.
>
> To enable stub domains specify in your guest configuration:
>    device_model = "stubdom-dm"
>
> RESOLUTION
> ==========
>
> Applying the appropriate attached patch(es) will resolve the issue.
>
> PATCH INFORMATION
> =================
>
> The attached patches resolve this issue
>
> Traditional qemu tree
>   Xen 4.0, 4.1 and unstable         xsa17-qemu-xen-traditional-all.patch
>
> Upstream qemu tree (present in unstable only)
>   Xen unstable                      xsa17-qemu-xen-unstable.patch
>
> $ sha256sum xsa17-*.patch
> 60215322d3fbbc2054dfc160a20d9e0811af88487c4edc2f6ea81dcd5cedf039 
> xsa17-qemu-xen-traditional-all.patch
> 7b4bb59e7757080e7806a8b8eeb6b78fa0ffdfbfb28a7a379f7edff285bffd88 
> xsa17-qemu-xen-unstable.patch

-- 
Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
T: +44 (0)1223 225 900, http://www.citrix.com


--------------070604010102000502080808
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: 8bit

<html>
  <head>
    <meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    On 07/09/12 20:33, Nathan March wrote:<br>
    <span style="white-space: pre;">&gt; Hi All,<br>
      &gt; <br>
      &gt; I'm guessing this wasn't intentional, but the patch for xsa17
      does not contain a complete path to the tools/ioemu-qemu-xen/
      path:<br>
    </span><br>
    This is because it applies to the qemu repository, not the xen
    repository.<br>
    <br>
    It just so happens that the xen repository build system will pull it
    into a subdir to build it, if you dont do so manually.<br>
    <br>
    ~Andrew<br>
    <br>
    <span style="white-space: pre;">&gt; <br>
      &gt; --- a/console.c<br>
      &gt; +++ b/console.c<br>
      &gt; <br>
      &gt; Compared to all the other patches which provide a full path
      to the patched file:<br>
      &gt; <br>
      &gt; --- a/xen/include/asm-x86/debugreg.h Mon Aug 06 12:28:03 2012
      +0100<br>
      &gt; +++ b/xen/include/asm-x86/debugreg.h Wed Aug 15 12:00:21 2012
      +0100<br>
      &gt; <br>
      &gt; Little annoying since it means you have to track down which
      console.c is being patched instead of just applying from the root
      xen build dir.<br>
      &gt; <br>
      &gt; - Nathan<br>
      &gt; <br>
      &gt;<br>
      &gt; ------ Original Message ------<br>
      &gt; From: "Xen.org security team" <a class="moz-txt-link-rfc2396E" href="mailto:security@xen.org">&lt;security@xen.org&gt;</a><br>
      &gt; To:
<a class="moz-txt-link-abbreviated" href="mailto:xen-announce@lists.xen.org;xen-devel@lists.xen.org;xen-users@lists.xen.org;oss-security@lists.openwall.com">xen-announce@lists.xen.org;xen-devel@lists.xen.org;xen-users@lists.xen.org;oss-security@lists.openwall.com</a><br>
      &gt; Cc: "Xen.org security team" <a class="moz-txt-link-rfc2396E" href="mailto:security@xen.org">&lt;security@xen.org&gt;</a><br>
      &gt; Sent: 9/5/2012 4:12:47 AM<br>
      &gt; Subject: [Xen-users] Xen Security Advisory 17 (CVE-2012-3515)
      - Qemu VT100 emulation vulnerability</span><br>
    <blockquote type="cite">           Xen Security Advisory
      CVE-2012-3515 / XSA-17<br>
                                version 2<br>
      <br>
                    Qemu VT100 emulation vulnerability<br>
      <br>
      UPDATES IN VERSION 2<br>
      ====================<br>
      <br>
      Public release.<br>
      <br>
      ISSUE DESCRIPTION<br>
      =================<br>
      <br>
      The device model used by fully virtualised (HVM) domains, qemu,
      does<br>
      not properly handle escape VT100 sequences when emulating certain<br>
      devices with a virtual console backend.<br>
      <br>
      IMPACT<br>
      ======<br>
      <br>
      An attacker who has sufficient privilege to access a vulnerable
      device<br>
      within a guest can overwrite portions of the device model's
      address<br>
      space. This can allow them to escalate their privileges to that of
      the<br>
      device model process.<br>
      <br>
      VULNERABLE SYSTEMS<br>
      ==================<br>
      <br>
      All Xen systems running HVM guests are potentially vulnerable to
      this<br>
      depending on the specific guest configuration. The default<br>
      configuration is vulnerable.<br>
      <br>
      Guests using either the traditional "qemu-xen" or upstream qemu
      device<br>
      models are vulnerable.<br>
      <br>
      MITIGATION<br>
      ==========<br>
      <br>
      This issue can be avoided by only running PV guests or by
      configuring<br>
      HVM guests to not use the virtual console('vc') backend for any
      device.<br>
      <br>
      For serial devices specify in your guest configuration:<br>
          serial = 'none'<br>
      in your guest configuration.<br>
      <br>
      For parallel port devices the syntax is toolstack specific.<br>
      For xend specify in your guest configuration:<br>
          parallel = 'none'<br>
      For xl specify in your guest configuration:<br>
          xl: device_model_args = ['-parallel', 'none']<br>
      <br>
      In both cases the default is to use the vulnerable 'vc' mode.<br>
      <br>
      You can confirm whether or not you are vulnerable by pressing<br>
      Ctrl-Alt-&lt;N&gt; (for digit N) while connected to either the VNC
      or SDL<br>
      console. If you are able to switch to a window displaying "serial"
      or<br>
      "parallel" then you are vulnerable.<br>
      <br>
      The issue can also be mitigated by enabling the stub domain device<br>
      model. In this case the attacked can only potentially gain control
      of<br>
      the stub domain and not of the entire system.<br>
      <br>
      To enable stub domains specify in your guest configuration:<br>
         device_model = "stubdom-dm"<br>
      <br>
      RESOLUTION<br>
      ==========<br>
      <br>
      Applying the appropriate attached patch(es) will resolve the
      issue.<br>
      <br>
      PATCH INFORMATION<br>
      =================<br>
      <br>
      The attached patches resolve this issue<br>
      <br>
      Traditional qemu tree<br>
        Xen 4.0, 4.1 and unstable        
      xsa17-qemu-xen-traditional-all.patch<br>
      <br>
      Upstream qemu tree (present in unstable only)<br>
        Xen unstable                      xsa17-qemu-xen-unstable.patch<br>
      <br>
      $ sha256sum xsa17-*.patch<br>
      60215322d3fbbc2054dfc160a20d9e0811af88487c4edc2f6ea81dcd5cedf039 
      xsa17-qemu-xen-traditional-all.patch<br>
      7b4bb59e7757080e7806a8b8eeb6b78fa0ffdfbfb28a7a379f7edff285bffd88 
      xsa17-qemu-xen-unstable.patch<br>
    </blockquote>
    <br>
    -- <br>
    Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer<br>
    T: +44 (0)1223 225 900, <a class="moz-txt-link-freetext" href="http://www.citrix.com">http://www.citrix.com</a><br>
    <br>
  </body>
</html>

--------------070604010102000502080808--


--===============0732460400532653199==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============0732460400532653199==--


From xen-devel-bounces@lists.xen.org Fri Sep 07 19:40:28 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Sep 2012 19: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 1TA4PO-0002rI-Fx; Fri, 07 Sep 2012 19:40:06 +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 1TA4PM-0002r0-UN
	for xen-devel@lists.xen.org; Fri, 07 Sep 2012 19:40:05 +0000
Received: from [85.158.139.83:61858] by server-6.bemta-5.messagelabs.com id
	D7/1D-21336-39D4A405; Fri, 07 Sep 2012 19:40:03 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1347046791!17961623!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNzc0ODA=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3414 invoked from network); 7 Sep 2012 19:39:52 -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;
	7 Sep 2012 19:39:52 -0000
X-IronPort-AV: E=Sophos;i="4.80,387,1344211200"; 
	d="scan'208,217";a="207452757"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Sep 2012 19:39:50 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1;
	Fri, 7 Sep 2012 15:39:50 -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 1TA4P7-000385-Nj	for
	xen-devel@lists.xen.org; Fri, 07 Sep 2012 20:39:49 +0100
Message-ID: <504A4D85.9080705@citrix.com>
Date: Fri, 7 Sep 2012 20:39:49 +0100
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:14.0) Gecko/20120714 Thunderbird/14.0
MIME-Version: 1.0
To: xen-devel@lists.xen.org
References: <emd0d6024e-114e-4969-a7b2-ef30ed5138a5@nathan>
In-Reply-To: <emd0d6024e-114e-4969-a7b2-ef30ed5138a5@nathan>
X-Enigmail-Version: 1.4.4
Subject: Re: [Xen-devel] [Xen-users] Xen Security Advisory 17
 (CVE-2012-3515) - Qemu VT100 emulation vulnerability
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0732460400532653199=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============0732460400532653199==
Content-Type: multipart/alternative;
	boundary="------------070604010102000502080808"

--------------070604010102000502080808
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit

On 07/09/12 20:33, Nathan March wrote:
> Hi All,
>
> I'm guessing this wasn't intentional, but the patch for xsa17 does not
contain a complete path to the tools/ioemu-qemu-xen/ path:

This is because it applies to the qemu repository, not the xen repository.

It just so happens that the xen repository build system will pull it
into a subdir to build it, if you dont do so manually.

~Andrew

> 
> --- a/console.c
> +++ b/console.c
>
> Compared to all the other patches which provide a full path to the
patched file:
>
> --- a/xen/include/asm-x86/debugreg.h Mon Aug 06 12:28:03 2012 +0100
> +++ b/xen/include/asm-x86/debugreg.h Wed Aug 15 12:00:21 2012 +0100
>
> Little annoying since it means you have to track down which console.c
is being patched instead of just applying from the root xen build dir.
>
> - Nathan
>
>
> ------ Original Message ------
> From: "Xen.org security team" <security@xen.org>
> To:
xen-announce@lists.xen.org;xen-devel@lists.xen.org;xen-users@lists.xen.org;oss-security@lists.openwall.com
> Cc: "Xen.org security team" <security@xen.org>
> Sent: 9/5/2012 4:12:47 AM
> Subject: [Xen-users] Xen Security Advisory 17 (CVE-2012-3515) - Qemu
VT100 emulation vulnerability
>            Xen Security Advisory CVE-2012-3515 / XSA-17
>                           version 2
>
>               Qemu VT100 emulation vulnerability
>
> UPDATES IN VERSION 2
> ====================
>
> Public release.
>
> ISSUE DESCRIPTION
> =================
>
> The device model used by fully virtualised (HVM) domains, qemu, does
> not properly handle escape VT100 sequences when emulating certain
> devices with a virtual console backend.
>
> IMPACT
> ======
>
> An attacker who has sufficient privilege to access a vulnerable device
> within a guest can overwrite portions of the device model's address
> space. This can allow them to escalate their privileges to that of the
> device model process.
>
> VULNERABLE SYSTEMS
> ==================
>
> All Xen systems running HVM guests are potentially vulnerable to this
> depending on the specific guest configuration. The default
> configuration is vulnerable.
>
> Guests using either the traditional "qemu-xen" or upstream qemu device
> models are vulnerable.
>
> MITIGATION
> ==========
>
> This issue can be avoided by only running PV guests or by configuring
> HVM guests to not use the virtual console('vc') backend for any device.
>
> For serial devices specify in your guest configuration:
>     serial = 'none'
> in your guest configuration.
>
> For parallel port devices the syntax is toolstack specific.
> For xend specify in your guest configuration:
>     parallel = 'none'
> For xl specify in your guest configuration:
>     xl: device_model_args = ['-parallel', 'none']
>
> In both cases the default is to use the vulnerable 'vc' mode.
>
> You can confirm whether or not you are vulnerable by pressing
> Ctrl-Alt-<N> (for digit N) while connected to either the VNC or SDL
> console. If you are able to switch to a window displaying "serial" or
> "parallel" then you are vulnerable.
>
> The issue can also be mitigated by enabling the stub domain device
> model. In this case the attacked can only potentially gain control of
> the stub domain and not of the entire system.
>
> To enable stub domains specify in your guest configuration:
>    device_model = "stubdom-dm"
>
> RESOLUTION
> ==========
>
> Applying the appropriate attached patch(es) will resolve the issue.
>
> PATCH INFORMATION
> =================
>
> The attached patches resolve this issue
>
> Traditional qemu tree
>   Xen 4.0, 4.1 and unstable         xsa17-qemu-xen-traditional-all.patch
>
> Upstream qemu tree (present in unstable only)
>   Xen unstable                      xsa17-qemu-xen-unstable.patch
>
> $ sha256sum xsa17-*.patch
> 60215322d3fbbc2054dfc160a20d9e0811af88487c4edc2f6ea81dcd5cedf039 
> xsa17-qemu-xen-traditional-all.patch
> 7b4bb59e7757080e7806a8b8eeb6b78fa0ffdfbfb28a7a379f7edff285bffd88 
> xsa17-qemu-xen-unstable.patch

-- 
Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
T: +44 (0)1223 225 900, http://www.citrix.com


--------------070604010102000502080808
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: 8bit

<html>
  <head>
    <meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    On 07/09/12 20:33, Nathan March wrote:<br>
    <span style="white-space: pre;">&gt; Hi All,<br>
      &gt; <br>
      &gt; I'm guessing this wasn't intentional, but the patch for xsa17
      does not contain a complete path to the tools/ioemu-qemu-xen/
      path:<br>
    </span><br>
    This is because it applies to the qemu repository, not the xen
    repository.<br>
    <br>
    It just so happens that the xen repository build system will pull it
    into a subdir to build it, if you dont do so manually.<br>
    <br>
    ~Andrew<br>
    <br>
    <span style="white-space: pre;">&gt; <br>
      &gt; --- a/console.c<br>
      &gt; +++ b/console.c<br>
      &gt; <br>
      &gt; Compared to all the other patches which provide a full path
      to the patched file:<br>
      &gt; <br>
      &gt; --- a/xen/include/asm-x86/debugreg.h Mon Aug 06 12:28:03 2012
      +0100<br>
      &gt; +++ b/xen/include/asm-x86/debugreg.h Wed Aug 15 12:00:21 2012
      +0100<br>
      &gt; <br>
      &gt; Little annoying since it means you have to track down which
      console.c is being patched instead of just applying from the root
      xen build dir.<br>
      &gt; <br>
      &gt; - Nathan<br>
      &gt; <br>
      &gt;<br>
      &gt; ------ Original Message ------<br>
      &gt; From: "Xen.org security team" <a class="moz-txt-link-rfc2396E" href="mailto:security@xen.org">&lt;security@xen.org&gt;</a><br>
      &gt; To:
<a class="moz-txt-link-abbreviated" href="mailto:xen-announce@lists.xen.org;xen-devel@lists.xen.org;xen-users@lists.xen.org;oss-security@lists.openwall.com">xen-announce@lists.xen.org;xen-devel@lists.xen.org;xen-users@lists.xen.org;oss-security@lists.openwall.com</a><br>
      &gt; Cc: "Xen.org security team" <a class="moz-txt-link-rfc2396E" href="mailto:security@xen.org">&lt;security@xen.org&gt;</a><br>
      &gt; Sent: 9/5/2012 4:12:47 AM<br>
      &gt; Subject: [Xen-users] Xen Security Advisory 17 (CVE-2012-3515)
      - Qemu VT100 emulation vulnerability</span><br>
    <blockquote type="cite">           Xen Security Advisory
      CVE-2012-3515 / XSA-17<br>
                                version 2<br>
      <br>
                    Qemu VT100 emulation vulnerability<br>
      <br>
      UPDATES IN VERSION 2<br>
      ====================<br>
      <br>
      Public release.<br>
      <br>
      ISSUE DESCRIPTION<br>
      =================<br>
      <br>
      The device model used by fully virtualised (HVM) domains, qemu,
      does<br>
      not properly handle escape VT100 sequences when emulating certain<br>
      devices with a virtual console backend.<br>
      <br>
      IMPACT<br>
      ======<br>
      <br>
      An attacker who has sufficient privilege to access a vulnerable
      device<br>
      within a guest can overwrite portions of the device model's
      address<br>
      space. This can allow them to escalate their privileges to that of
      the<br>
      device model process.<br>
      <br>
      VULNERABLE SYSTEMS<br>
      ==================<br>
      <br>
      All Xen systems running HVM guests are potentially vulnerable to
      this<br>
      depending on the specific guest configuration. The default<br>
      configuration is vulnerable.<br>
      <br>
      Guests using either the traditional "qemu-xen" or upstream qemu
      device<br>
      models are vulnerable.<br>
      <br>
      MITIGATION<br>
      ==========<br>
      <br>
      This issue can be avoided by only running PV guests or by
      configuring<br>
      HVM guests to not use the virtual console('vc') backend for any
      device.<br>
      <br>
      For serial devices specify in your guest configuration:<br>
          serial = 'none'<br>
      in your guest configuration.<br>
      <br>
      For parallel port devices the syntax is toolstack specific.<br>
      For xend specify in your guest configuration:<br>
          parallel = 'none'<br>
      For xl specify in your guest configuration:<br>
          xl: device_model_args = ['-parallel', 'none']<br>
      <br>
      In both cases the default is to use the vulnerable 'vc' mode.<br>
      <br>
      You can confirm whether or not you are vulnerable by pressing<br>
      Ctrl-Alt-&lt;N&gt; (for digit N) while connected to either the VNC
      or SDL<br>
      console. If you are able to switch to a window displaying "serial"
      or<br>
      "parallel" then you are vulnerable.<br>
      <br>
      The issue can also be mitigated by enabling the stub domain device<br>
      model. In this case the attacked can only potentially gain control
      of<br>
      the stub domain and not of the entire system.<br>
      <br>
      To enable stub domains specify in your guest configuration:<br>
         device_model = "stubdom-dm"<br>
      <br>
      RESOLUTION<br>
      ==========<br>
      <br>
      Applying the appropriate attached patch(es) will resolve the
      issue.<br>
      <br>
      PATCH INFORMATION<br>
      =================<br>
      <br>
      The attached patches resolve this issue<br>
      <br>
      Traditional qemu tree<br>
        Xen 4.0, 4.1 and unstable        
      xsa17-qemu-xen-traditional-all.patch<br>
      <br>
      Upstream qemu tree (present in unstable only)<br>
        Xen unstable                      xsa17-qemu-xen-unstable.patch<br>
      <br>
      $ sha256sum xsa17-*.patch<br>
      60215322d3fbbc2054dfc160a20d9e0811af88487c4edc2f6ea81dcd5cedf039 
      xsa17-qemu-xen-traditional-all.patch<br>
      7b4bb59e7757080e7806a8b8eeb6b78fa0ffdfbfb28a7a379f7edff285bffd88 
      xsa17-qemu-xen-unstable.patch<br>
    </blockquote>
    <br>
    -- <br>
    Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer<br>
    T: +44 (0)1223 225 900, <a class="moz-txt-link-freetext" href="http://www.citrix.com">http://www.citrix.com</a><br>
    <br>
  </body>
</html>

--------------070604010102000502080808--


--===============0732460400532653199==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============0732460400532653199==--


From xen-devel-bounces@lists.xen.org Fri Sep 07 20:21:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Sep 2012 20:21:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TA52e-0003hM-51; Fri, 07 Sep 2012 20:20:40 +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 1TA52d-0003hH-KP
	for xen-devel@lists.xen.org; Fri, 07 Sep 2012 20:20:39 +0000
Received: from [85.158.143.35:8597] by server-2.bemta-4.messagelabs.com id
	D1/81-21239-6175A405; Fri, 07 Sep 2012 20:20:38 +0000
X-Env-Sender: msw@amazon.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1347049225!17222519!1
X-Originating-IP: [72.21.198.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNzIuMjEuMTk4LjI1ID0+IDE3NDE3MQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25848 invoked from network); 7 Sep 2012 20:20:30 -0000
Received: from smtp-fw-4101.amazon.com (HELO smtp-fw-4101.amazon.com)
	(72.21.198.25)
	by server-6.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Sep 2012 20:20:30 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=amazon.com; i=msw@amazon.com; q=dns/txt; s=rte02;
	t=1347049230; x=1378585230;
	h=date:from:to:cc:subject:message-id:references:
	mime-version:in-reply-to;
	bh=asWErkTb26zhhEwNxS/43KcrT2IPo2NghjjRJmWJV2A=;
	b=e5odf6HFplQb9i8hKy1RTcRPKqnRI9wYqg4lpO7/DWI1/AvNA0I4SRw3
	f50fqCK7tho7ILlqHJpsnYAs/o3tow==;
X-IronPort-AV: E=Sophos;i="4.80,388,1344211200"; d="scan'208";a="793066391"
Received: from smtp-in-0191.sea3.amazon.com ([10.224.12.28])
	by smtp-border-fw-out-4101.iad4.amazon.com with
	ESMTP/TLS/DHE-RSA-AES256-SHA; 07 Sep 2012 20:20:21 +0000
Received: from ex10-hub-31005.ant.amazon.com (ex10-hub-31005.sea31.amazon.com
	[10.185.176.12])
	by smtp-in-0191.sea3.amazon.com (8.13.8/8.13.8) with ESMTP id
	q87KKIGn024822
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL);
	Fri, 7 Sep 2012 20:20:19 GMT
Received: from u002268147cd4502c336d.ant.amazon.com (10.224.80.38) by
	ex10-hub-31005.ant.amazon.com (10.185.176.12) with Microsoft SMTP
	Server id 14.2.247.3; Fri, 7 Sep 2012 13:20:05 -0700
Received: by u002268147cd4502c336d.ant.amazon.com (sSMTP sendmail emulation); 
	Fri, 07 Sep 2012 13:20:05 -0700
Date: Fri, 7 Sep 2012 13:20:05 -0700
From: Matt Wilson <msw@amazon.com>
To: Lars Kurth <lars.kurth@xen.org>
Message-ID: <20120907202002.GA4288@u002268147cd4502c336d.ant.amazon.com>
References: <5049D438.70403@xen.org>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <5049D438.70403@xen.org>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Notes from Xen Maintainer,
 Committer and Developer Meeting @ XenSummit NA 2012
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Sep 07, 2012 at 12:02:16PM +0100, Lars Kurth wrote:
> See http://wiki.xen.org/wiki/Xen_Maintainer,_Committer_and_Developer_Meeting/XenSummit_NA_2012

ACTION: Matt Wilson to send round links to reference HW for EFI

You can purchase a UEFI 2.3.1 development platform from Hard Drives
Northwest. Link: http://tunnelmountain.net/

More information from Intel is here: http://uefidk.com/develop/development-kit

Matt

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 07 20:21:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Sep 2012 20:21:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TA52e-0003hM-51; Fri, 07 Sep 2012 20:20:40 +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 1TA52d-0003hH-KP
	for xen-devel@lists.xen.org; Fri, 07 Sep 2012 20:20:39 +0000
Received: from [85.158.143.35:8597] by server-2.bemta-4.messagelabs.com id
	D1/81-21239-6175A405; Fri, 07 Sep 2012 20:20:38 +0000
X-Env-Sender: msw@amazon.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1347049225!17222519!1
X-Originating-IP: [72.21.198.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNzIuMjEuMTk4LjI1ID0+IDE3NDE3MQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25848 invoked from network); 7 Sep 2012 20:20:30 -0000
Received: from smtp-fw-4101.amazon.com (HELO smtp-fw-4101.amazon.com)
	(72.21.198.25)
	by server-6.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Sep 2012 20:20:30 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=amazon.com; i=msw@amazon.com; q=dns/txt; s=rte02;
	t=1347049230; x=1378585230;
	h=date:from:to:cc:subject:message-id:references:
	mime-version:in-reply-to;
	bh=asWErkTb26zhhEwNxS/43KcrT2IPo2NghjjRJmWJV2A=;
	b=e5odf6HFplQb9i8hKy1RTcRPKqnRI9wYqg4lpO7/DWI1/AvNA0I4SRw3
	f50fqCK7tho7ILlqHJpsnYAs/o3tow==;
X-IronPort-AV: E=Sophos;i="4.80,388,1344211200"; d="scan'208";a="793066391"
Received: from smtp-in-0191.sea3.amazon.com ([10.224.12.28])
	by smtp-border-fw-out-4101.iad4.amazon.com with
	ESMTP/TLS/DHE-RSA-AES256-SHA; 07 Sep 2012 20:20:21 +0000
Received: from ex10-hub-31005.ant.amazon.com (ex10-hub-31005.sea31.amazon.com
	[10.185.176.12])
	by smtp-in-0191.sea3.amazon.com (8.13.8/8.13.8) with ESMTP id
	q87KKIGn024822
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL);
	Fri, 7 Sep 2012 20:20:19 GMT
Received: from u002268147cd4502c336d.ant.amazon.com (10.224.80.38) by
	ex10-hub-31005.ant.amazon.com (10.185.176.12) with Microsoft SMTP
	Server id 14.2.247.3; Fri, 7 Sep 2012 13:20:05 -0700
Received: by u002268147cd4502c336d.ant.amazon.com (sSMTP sendmail emulation); 
	Fri, 07 Sep 2012 13:20:05 -0700
Date: Fri, 7 Sep 2012 13:20:05 -0700
From: Matt Wilson <msw@amazon.com>
To: Lars Kurth <lars.kurth@xen.org>
Message-ID: <20120907202002.GA4288@u002268147cd4502c336d.ant.amazon.com>
References: <5049D438.70403@xen.org>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <5049D438.70403@xen.org>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Notes from Xen Maintainer,
 Committer and Developer Meeting @ XenSummit NA 2012
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Sep 07, 2012 at 12:02:16PM +0100, Lars Kurth wrote:
> See http://wiki.xen.org/wiki/Xen_Maintainer,_Committer_and_Developer_Meeting/XenSummit_NA_2012

ACTION: Matt Wilson to send round links to reference HW for EFI

You can purchase a UEFI 2.3.1 development platform from Hard Drives
Northwest. Link: http://tunnelmountain.net/

More information from Intel is here: http://uefidk.com/develop/development-kit

Matt

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 07 20:28:43 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Sep 2012 20:28:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TA5A5-0003r7-2Y; Fri, 07 Sep 2012 20:28:21 +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 1TA5A3-0003r2-Bz
	for xen-devel@lists.xen.org; Fri, 07 Sep 2012 20:28:19 +0000
Received: from [85.158.138.51:7694] by server-11.bemta-3.messagelabs.com id
	AE/C2-30250-2E85A405; Fri, 07 Sep 2012 20:28:18 +0000
X-Env-Sender: msw@amazon.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1347049696!27664901!1
X-Originating-IP: [72.21.198.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNzIuMjEuMTk4LjI1ID0+IDE3NDE3MQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23554 invoked from network); 7 Sep 2012 20:28:17 -0000
Received: from smtp-fw-4101.amazon.com (HELO smtp-fw-4101.amazon.com)
	(72.21.198.25)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Sep 2012 20:28:17 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=amazon.com; i=msw@amazon.com; q=dns/txt; s=rte02;
	t=1347049697; x=1378585697;
	h=date:from:to:cc:subject:message-id:references:
	mime-version:in-reply-to;
	bh=zZzBSENiUi1SJchQD/VpC8cvy3aw5za04frz6c/kJg4=;
	b=SbinzhuJfDvjxQtUKdMik4xSB9Q06kbOHgAsfqpH1iqNHesySTODHIvU
	lqy/9e1miXxHkhnI2Hikd+vTQ7wIAw==;
X-IronPort-AV: E=Sophos;i="4.80,388,1344211200"; d="scan'208";a="793070210"
Received: from smtp-in-9002.sea19.amazon.com ([10.186.174.20])
	by smtp-border-fw-out-4101.iad4.amazon.com with
	ESMTP/TLS/DHE-RSA-AES256-SHA; 07 Sep 2012 20:28:16 +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
	q87KSFYr020838
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL);
	Fri, 7 Sep 2012 20:28:15 GMT
Received: from u002268147cd4502c336d.ant.amazon.com (10.224.80.43) by
	ex10-hub-31006.ant.amazon.com (10.185.176.13) with Microsoft SMTP
	Server id 14.2.247.3; Fri, 7 Sep 2012 13:28:11 -0700
Received: by u002268147cd4502c336d.ant.amazon.com (sSMTP sendmail emulation); 
	Fri, 07 Sep 2012 13:28:11 -0700
Date: Fri, 7 Sep 2012 13:28:11 -0700
From: Matt Wilson <msw@amazon.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120907202810.GB4288@u002268147cd4502c336d.ant.amazon.com>
References: <patchbomb.1346992557@u002268147cd4502c336d.ant.amazon.com>
	<1347007906.30018.43.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1347007906.30018.43.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 0 of 2 v3] improve checking for
 documentation tools and formatting
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Sep 07, 2012 at 09:51:46AM +0100, Ian Campbell wrote:
> On Fri, 2012-09-07 at 05:35 +0100, Matt Wilson wrote:
> > This version addresses feedback from v2. Please let me know if there
> > are any other concerns.
> 
> In general I think I'm happy to take docs updates right up to the
> release, but in this case since it also involves changes to autoconf and
> the build system I think is now 4.3 material.

Well, I provided a patch that produced formatted text from markdown
that didn't change autoconf and the build system all that much, but
IanJ asked:
> Firstly, why lynx and not w3m ?  Is lynx even maintained upstream
> any more ?  Secondly, shouldn't we do the testing for the presence
> of markdown and the html formatter in configure ?
> Ian.

I think that there's very little risk in these changes, even at this
late stage for 4.2.0.

Matt

> (I've not actually looked at the patches yet, just the diffstat)
> 
> Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 07 20:28:43 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Sep 2012 20:28:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TA5A5-0003r7-2Y; Fri, 07 Sep 2012 20:28:21 +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 1TA5A3-0003r2-Bz
	for xen-devel@lists.xen.org; Fri, 07 Sep 2012 20:28:19 +0000
Received: from [85.158.138.51:7694] by server-11.bemta-3.messagelabs.com id
	AE/C2-30250-2E85A405; Fri, 07 Sep 2012 20:28:18 +0000
X-Env-Sender: msw@amazon.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1347049696!27664901!1
X-Originating-IP: [72.21.198.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNzIuMjEuMTk4LjI1ID0+IDE3NDE3MQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23554 invoked from network); 7 Sep 2012 20:28:17 -0000
Received: from smtp-fw-4101.amazon.com (HELO smtp-fw-4101.amazon.com)
	(72.21.198.25)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Sep 2012 20:28:17 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=amazon.com; i=msw@amazon.com; q=dns/txt; s=rte02;
	t=1347049697; x=1378585697;
	h=date:from:to:cc:subject:message-id:references:
	mime-version:in-reply-to;
	bh=zZzBSENiUi1SJchQD/VpC8cvy3aw5za04frz6c/kJg4=;
	b=SbinzhuJfDvjxQtUKdMik4xSB9Q06kbOHgAsfqpH1iqNHesySTODHIvU
	lqy/9e1miXxHkhnI2Hikd+vTQ7wIAw==;
X-IronPort-AV: E=Sophos;i="4.80,388,1344211200"; d="scan'208";a="793070210"
Received: from smtp-in-9002.sea19.amazon.com ([10.186.174.20])
	by smtp-border-fw-out-4101.iad4.amazon.com with
	ESMTP/TLS/DHE-RSA-AES256-SHA; 07 Sep 2012 20:28:16 +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
	q87KSFYr020838
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL);
	Fri, 7 Sep 2012 20:28:15 GMT
Received: from u002268147cd4502c336d.ant.amazon.com (10.224.80.43) by
	ex10-hub-31006.ant.amazon.com (10.185.176.13) with Microsoft SMTP
	Server id 14.2.247.3; Fri, 7 Sep 2012 13:28:11 -0700
Received: by u002268147cd4502c336d.ant.amazon.com (sSMTP sendmail emulation); 
	Fri, 07 Sep 2012 13:28:11 -0700
Date: Fri, 7 Sep 2012 13:28:11 -0700
From: Matt Wilson <msw@amazon.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120907202810.GB4288@u002268147cd4502c336d.ant.amazon.com>
References: <patchbomb.1346992557@u002268147cd4502c336d.ant.amazon.com>
	<1347007906.30018.43.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1347007906.30018.43.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 0 of 2 v3] improve checking for
 documentation tools and formatting
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Sep 07, 2012 at 09:51:46AM +0100, Ian Campbell wrote:
> On Fri, 2012-09-07 at 05:35 +0100, Matt Wilson wrote:
> > This version addresses feedback from v2. Please let me know if there
> > are any other concerns.
> 
> In general I think I'm happy to take docs updates right up to the
> release, but in this case since it also involves changes to autoconf and
> the build system I think is now 4.3 material.

Well, I provided a patch that produced formatted text from markdown
that didn't change autoconf and the build system all that much, but
IanJ asked:
> Firstly, why lynx and not w3m ?  Is lynx even maintained upstream
> any more ?  Secondly, shouldn't we do the testing for the presence
> of markdown and the html formatter in configure ?
> Ian.

I think that there's very little risk in these changes, even at this
late stage for 4.2.0.

Matt

> (I've not actually looked at the patches yet, just the diffstat)
> 
> Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 07 21:02:32 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Sep 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 1TA5gj-0004EV-5W; Fri, 07 Sep 2012 21:02:05 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ketuzsezr@gmail.com>) id 1TA5gi-0004EQ-5M
	for xen-devel@lists.xensource.com; Fri, 07 Sep 2012 21:02:04 +0000
Received: from [85.158.143.35:23429] by server-3.bemta-4.messagelabs.com id
	34/4E-08232-BC06A405; Fri, 07 Sep 2012 21:02:03 +0000
X-Env-Sender: ketuzsezr@gmail.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1347051719!5533740!1
X-Originating-IP: [209.85.216.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11980 invoked from network); 7 Sep 2012 21:02:00 -0000
Received: from mail-qa0-f43.google.com (HELO mail-qa0-f43.google.com)
	(209.85.216.43)
	by server-4.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Sep 2012 21:02:00 -0000
Received: by qatk31 with SMTP id k31so170067qat.9
	for <xen-devel@lists.xensource.com>;
	Fri, 07 Sep 2012 14:01:59 -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=g2csRg46taKGgAzoGpdwjlaZnSXAxNsUqR1jxfbjRsg=;
	b=o+fwXUwk9PGIuKEQR9tYPIEulfph07sreDWCTTMs5IQpHNJ7j+Xu1F7RcSGQ/jZWPo
	GX92An+Q+sj/IeXgUfBypoGFeGHpi8bmNjDh6NwS2/noobqmH5tLQVC5/JdKs/Pje5Oi
	9s5VVWoCVgVrq77AXjmd+CCsomBcTHhxiWoHKZWuVSjK5owrmcNtM44cPa/Bnz921vgw
	CTJ215cN/XubGy+DS0HFyZB7iJ+voB438f6Yxsd1XKf07TYgKjC36+foDqDemDxK85DR
	teFtJqe6Yqceub5Su99T8akaKOsuXwF28Qix7AeNqyXsbfmM+UMRlgkjhzIblIjWw34L
	xNZA==
Received: by 10.224.45.4 with SMTP id c4mr9327800qaf.29.1347051719356;
	Fri, 07 Sep 2012 14:01:59 -0700 (PDT)
Received: from phenom.dumpdata.com
	(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 gx4sm3253344qab.3.2012.09.07.14.01.58
	(version=TLSv1/SSLv3 cipher=OTHER);
	Fri, 07 Sep 2012 14:01:58 -0700 (PDT)
Date: Fri, 7 Sep 2012 16:51:22 -0400
From: Konrad Rzeszutek Wilk <konrad@kernel.org>
To: Sander Eikelenboom <linux@eikelenboom.it>
Message-ID: <20120907205120.GA25238@phenom.dumpdata.com>
References: <504764E2.4000809@amd.com>
	<326589347.20120906005936@eikelenboom.it>
	<5048A603.3070207@amd.com>
	<483486315.20120906155001@eikelenboom.it>
	<5048BB29.4040900@amd.com>
	<488803362.20120907093241@eikelenboom.it>
	<5049B650.4080101@amd.com>
	<1144069450.20120907120133@eikelenboom.it>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1144069450.20120907120133@eikelenboom.it>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: Wei Wang <wei.wang2@amd.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH] amd iommu: Dump flags of IO page faults
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Sep 07, 2012 at 12:01:33PM +0200, Sander Eikelenboom wrote:
> 
> Friday, September 7, 2012, 10:54:40 AM, you wrote:
> 
> > On 09/07/2012 09:32 AM, Sander Eikelenboom wrote:
> >>
> >> Thursday, September 6, 2012, 5:03:05 PM, you wrote:
> >>
> >>> On 09/06/2012 03:50 PM, Sander Eikelenboom wrote:
> >>>>
> >>>> Thursday, September 6, 2012, 3:32:51 PM, you wrote:
> >>>>
> >>>>> On 09/06/2012 12:59 AM, Sander Eikelenboom wrote:
> >>>>>>
> >>>>>> Wednesday, September 5, 2012, 4:42:42 PM, you wrote:
> >>>>>>
> >>>>>>> Hi Jan,
> >>>>>>> Attached patch dumps io page fault flags. The flags show the reason of
> >>>>>>> the fault and tell us if this is an unmapped interrupt fault or a DMA fault.
> >>>>>>
> >>>>>>> Thanks,
> >>>>>>> Wei
> >>>>>>
> >>>>>>> signed-off-by: Wei Wang<wei.wang2@amd.com>
> >>>>>>
> >>>>>>
> >>>>>> I have applied the patch and the flags seem to differ between the faults:
> >>>>>>
> >>>>>> AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0a06, fault address = 0xc2c2c2c0, flags = 0x000
> >>>>>> (XEN) [2012-09-05 20:54:16] AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0a06, fault address = 0xc2c2c2c0, flags = 0x000
> >>>>>> (XEN) [2012-09-05 20:54:16] AMD-Vi: IO_PAGE_FAULT: domain = 14, device id = 0x0700, fault address = 0xa8d339e0, flags = 0x020
> >>>>>> (XEN) [2012-09-05 20:54:16] AMD-Vi: IO_PAGE_FAULT: domain = 14, device id = 0x0700, fault address = 0xa8d33a40, flags = 0x020
> >>>>
> >>>>> OK, so they are not interrupt requests. I guess further information from
> >>>>> your system would be helpful to debug this issue:
> >>>>> 1) xl info
> >>>>> 2) xl list
> >>>>> 3) lscpi -vvv (NOTE: not in dom0 but in your guest)
> >>>>> 4) cat /proc/iomem (in both dom0 and your hvm guest)
> >>>>
> >>>> dom14 is not a HVM guest,it's a PV guest.
> >>
> >>> Ah, I see. PV guest is quite different than hvm, it does use p2m tables
> >>> as io page tables. So no-sharept option does not work in this case. PV
> >>> guests always use separated io page tables. There might be some
> >>> incorrect mappings on the page tables. I will check this on my side.
> >>
> >> I have reverted the machine to xen-4.1.4-pre (changeset 23353) and kept everything else the same.
> >> I haven't seen any IO PAGE FAULTS after that.
> >>
> >> I did spot some differences in the output from lspci between xen 4.1 and 4.2, related to MSI enabled or not for the IOMMU device.
> >> Have attached the xl/xm dmesg and lspci from booting with both versions.
> >>
> >> lspci:
> >>
> >> 00:00.2 Generic system peripheral [0806]: ATI Technologies Inc RD990 I/O Memory Management Unit (IOMMU) [1002:5a23]
> >>          Subsystem: ATI Technologies Inc RD990 I/O Memory Management Unit (IOMMU) [1002:5a23]
> >>          Control: I/O- Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
> >>          Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast>TAbort-<TAbort-<MAbort->SERR-<PERR- INTx-
> >>          Latency: 0
> >>          Interrupt: pin A routed to IRQ 10
> >>          Capabilities: [40] Secure device<?>
> >> 4.1:    Capabilities: [54] MSI: Enable- Count=1/1 Maskable- 64bit+
> 
> > Eh... That is interesting. So which dom0 are you using?  There is a c/s 
> > in 4.2 to prevent recent dom0 to disable iommu interrupt (changeset 
> > 25492:61844569a432) Otherwise, iommu cannot send any events including IO 
> > PAGE faults. You could try to revert dom0 to an old version like 2.6 
> > pv_ops to see if you really have no io page faults on 4.1
> 
> Ok i will give that a try, only dom0 will have to be a 2.6 pv_ops i assume ?
> 

So the failure they are describing is due to:
http://lists.xen.org/archives/html/xen-devel/2012-06/msg00668.html

Or you can use the patch that Jan posted
http://lists.xen.org/archives/html/xen-devel/2012-06/msg01196.html

and use the existing kernel.. But more interesting - is this device
(00:00.2) in the Xen-pciback.hide arguments (if not, then don't worry)?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 07 21:02:32 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Sep 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 1TA5gj-0004EV-5W; Fri, 07 Sep 2012 21:02:05 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ketuzsezr@gmail.com>) id 1TA5gi-0004EQ-5M
	for xen-devel@lists.xensource.com; Fri, 07 Sep 2012 21:02:04 +0000
Received: from [85.158.143.35:23429] by server-3.bemta-4.messagelabs.com id
	34/4E-08232-BC06A405; Fri, 07 Sep 2012 21:02:03 +0000
X-Env-Sender: ketuzsezr@gmail.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1347051719!5533740!1
X-Originating-IP: [209.85.216.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11980 invoked from network); 7 Sep 2012 21:02:00 -0000
Received: from mail-qa0-f43.google.com (HELO mail-qa0-f43.google.com)
	(209.85.216.43)
	by server-4.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Sep 2012 21:02:00 -0000
Received: by qatk31 with SMTP id k31so170067qat.9
	for <xen-devel@lists.xensource.com>;
	Fri, 07 Sep 2012 14:01:59 -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=g2csRg46taKGgAzoGpdwjlaZnSXAxNsUqR1jxfbjRsg=;
	b=o+fwXUwk9PGIuKEQR9tYPIEulfph07sreDWCTTMs5IQpHNJ7j+Xu1F7RcSGQ/jZWPo
	GX92An+Q+sj/IeXgUfBypoGFeGHpi8bmNjDh6NwS2/noobqmH5tLQVC5/JdKs/Pje5Oi
	9s5VVWoCVgVrq77AXjmd+CCsomBcTHhxiWoHKZWuVSjK5owrmcNtM44cPa/Bnz921vgw
	CTJ215cN/XubGy+DS0HFyZB7iJ+voB438f6Yxsd1XKf07TYgKjC36+foDqDemDxK85DR
	teFtJqe6Yqceub5Su99T8akaKOsuXwF28Qix7AeNqyXsbfmM+UMRlgkjhzIblIjWw34L
	xNZA==
Received: by 10.224.45.4 with SMTP id c4mr9327800qaf.29.1347051719356;
	Fri, 07 Sep 2012 14:01:59 -0700 (PDT)
Received: from phenom.dumpdata.com
	(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 gx4sm3253344qab.3.2012.09.07.14.01.58
	(version=TLSv1/SSLv3 cipher=OTHER);
	Fri, 07 Sep 2012 14:01:58 -0700 (PDT)
Date: Fri, 7 Sep 2012 16:51:22 -0400
From: Konrad Rzeszutek Wilk <konrad@kernel.org>
To: Sander Eikelenboom <linux@eikelenboom.it>
Message-ID: <20120907205120.GA25238@phenom.dumpdata.com>
References: <504764E2.4000809@amd.com>
	<326589347.20120906005936@eikelenboom.it>
	<5048A603.3070207@amd.com>
	<483486315.20120906155001@eikelenboom.it>
	<5048BB29.4040900@amd.com>
	<488803362.20120907093241@eikelenboom.it>
	<5049B650.4080101@amd.com>
	<1144069450.20120907120133@eikelenboom.it>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1144069450.20120907120133@eikelenboom.it>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: Wei Wang <wei.wang2@amd.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH] amd iommu: Dump flags of IO page faults
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Sep 07, 2012 at 12:01:33PM +0200, Sander Eikelenboom wrote:
> 
> Friday, September 7, 2012, 10:54:40 AM, you wrote:
> 
> > On 09/07/2012 09:32 AM, Sander Eikelenboom wrote:
> >>
> >> Thursday, September 6, 2012, 5:03:05 PM, you wrote:
> >>
> >>> On 09/06/2012 03:50 PM, Sander Eikelenboom wrote:
> >>>>
> >>>> Thursday, September 6, 2012, 3:32:51 PM, you wrote:
> >>>>
> >>>>> On 09/06/2012 12:59 AM, Sander Eikelenboom wrote:
> >>>>>>
> >>>>>> Wednesday, September 5, 2012, 4:42:42 PM, you wrote:
> >>>>>>
> >>>>>>> Hi Jan,
> >>>>>>> Attached patch dumps io page fault flags. The flags show the reason of
> >>>>>>> the fault and tell us if this is an unmapped interrupt fault or a DMA fault.
> >>>>>>
> >>>>>>> Thanks,
> >>>>>>> Wei
> >>>>>>
> >>>>>>> signed-off-by: Wei Wang<wei.wang2@amd.com>
> >>>>>>
> >>>>>>
> >>>>>> I have applied the patch and the flags seem to differ between the faults:
> >>>>>>
> >>>>>> AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0a06, fault address = 0xc2c2c2c0, flags = 0x000
> >>>>>> (XEN) [2012-09-05 20:54:16] AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0a06, fault address = 0xc2c2c2c0, flags = 0x000
> >>>>>> (XEN) [2012-09-05 20:54:16] AMD-Vi: IO_PAGE_FAULT: domain = 14, device id = 0x0700, fault address = 0xa8d339e0, flags = 0x020
> >>>>>> (XEN) [2012-09-05 20:54:16] AMD-Vi: IO_PAGE_FAULT: domain = 14, device id = 0x0700, fault address = 0xa8d33a40, flags = 0x020
> >>>>
> >>>>> OK, so they are not interrupt requests. I guess further information from
> >>>>> your system would be helpful to debug this issue:
> >>>>> 1) xl info
> >>>>> 2) xl list
> >>>>> 3) lscpi -vvv (NOTE: not in dom0 but in your guest)
> >>>>> 4) cat /proc/iomem (in both dom0 and your hvm guest)
> >>>>
> >>>> dom14 is not a HVM guest,it's a PV guest.
> >>
> >>> Ah, I see. PV guest is quite different than hvm, it does use p2m tables
> >>> as io page tables. So no-sharept option does not work in this case. PV
> >>> guests always use separated io page tables. There might be some
> >>> incorrect mappings on the page tables. I will check this on my side.
> >>
> >> I have reverted the machine to xen-4.1.4-pre (changeset 23353) and kept everything else the same.
> >> I haven't seen any IO PAGE FAULTS after that.
> >>
> >> I did spot some differences in the output from lspci between xen 4.1 and 4.2, related to MSI enabled or not for the IOMMU device.
> >> Have attached the xl/xm dmesg and lspci from booting with both versions.
> >>
> >> lspci:
> >>
> >> 00:00.2 Generic system peripheral [0806]: ATI Technologies Inc RD990 I/O Memory Management Unit (IOMMU) [1002:5a23]
> >>          Subsystem: ATI Technologies Inc RD990 I/O Memory Management Unit (IOMMU) [1002:5a23]
> >>          Control: I/O- Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
> >>          Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast>TAbort-<TAbort-<MAbort->SERR-<PERR- INTx-
> >>          Latency: 0
> >>          Interrupt: pin A routed to IRQ 10
> >>          Capabilities: [40] Secure device<?>
> >> 4.1:    Capabilities: [54] MSI: Enable- Count=1/1 Maskable- 64bit+
> 
> > Eh... That is interesting. So which dom0 are you using?  There is a c/s 
> > in 4.2 to prevent recent dom0 to disable iommu interrupt (changeset 
> > 25492:61844569a432) Otherwise, iommu cannot send any events including IO 
> > PAGE faults. You could try to revert dom0 to an old version like 2.6 
> > pv_ops to see if you really have no io page faults on 4.1
> 
> Ok i will give that a try, only dom0 will have to be a 2.6 pv_ops i assume ?
> 

So the failure they are describing is due to:
http://lists.xen.org/archives/html/xen-devel/2012-06/msg00668.html

Or you can use the patch that Jan posted
http://lists.xen.org/archives/html/xen-devel/2012-06/msg01196.html

and use the existing kernel.. But more interesting - is this device
(00:00.2) in the Xen-pciback.hide arguments (if not, then don't worry)?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 07 21:09:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Sep 2012 21: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 1TA5nA-0004WT-0X; Fri, 07 Sep 2012 21:08:44 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <joseph.glanville@orionvm.com.au>) id 1TA5n7-0004WM-RV
	for xen-devel@lists.xensource.com; Fri, 07 Sep 2012 21:08:42 +0000
Received: from [85.158.139.83:64301] by server-10.bemta-5.messagelabs.com id
	4E/2A-10969-9526A405; Fri, 07 Sep 2012 21:08:41 +0000
X-Env-Sender: joseph.glanville@orionvm.com.au
X-Msg-Ref: server-7.tower-182.messagelabs.com!1347052119!25303673!1
X-Originating-IP: [209.85.214.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28712 invoked from network); 7 Sep 2012 21:08:40 -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;
	7 Sep 2012 21:08:40 -0000
Received: by obqv19 with SMTP id v19so46600obq.30
	for <xen-devel@lists.xensource.com>;
	Fri, 07 Sep 2012 14:08:39 -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=8xGCgPioGPayXxRZih72FvFBTIEXYx9sNLHBuLlykLs=;
	b=nX/xzbVYKVD+CP6TUGoH1pIKPs3Tca7gX8Y/oyocNseHhDzDWbUlL3LNLNw0dje9Dl
	j5u2jcdkmZjF6MJkBkanow/0WucMZc+KUloZoxhOHsOUjNYFAktV87/TYXqc60VwK2zo
	Jvl5kPDqpBEZMRKhIAYpJSyGywUTAfPhhKoaQw15tUIS9O7z6bBZhFKttMuvzu9Isb3U
	Rgr5+QCEHJ5HCAU5MA3vMcUZ7oyF5/qTcOovetVS5gUQhnCJa0lrmSJsBDSjXZUXZ1E5
	+1+k3PvkijATQ10NLR2XgUPSiuamkQJppiTxLcbZ7FcmXh6dnDk0+1jcLHYo97Fz26gz
	i3Tw==
MIME-Version: 1.0
Received: by 10.60.154.198 with SMTP id vq6mr7681219oeb.20.1347052118832; Fri,
	07 Sep 2012 14:08:38 -0700 (PDT)
Received: by 10.182.80.200 with HTTP; Fri, 7 Sep 2012 14:08:38 -0700 (PDT)
X-Originating-IP: [121.44.62.75]
In-Reply-To: <CC6FCF98.4AF76%keir@xen.org>
References: <4B45B535F7F6BE4CB1C044ED5115CDDE011A6DAD77DF@LONPMAILBOX01.citrite.net>
	<CC6FCF98.4AF76%keir@xen.org>
Date: Sat, 8 Sep 2012 07:08:38 +1000
Message-ID: <CAOzFzEhVuWAhQfQKQSS5ztWaWUTTBfn_1eKqJqit3EX-sK-DOA@mail.gmail.com>
From: Joseph Glanville <joseph.glanville@orionvm.com.au>
To: Keir Fraser <keir@xen.org>
X-Gm-Message-State: ALoCoQn1OAbkLEBKN/5GBmi+niH68CPeQ2HVzgZYJMayfKuhLMTprxVq1TuaM3a/bIWbOZylE162
Cc: Thanos Makatos <thanos.makatos@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] blktap3 in C++?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 8 September 2012 01:21, Keir Fraser <keir@xen.org> wrote:
> On 07/09/2012 16:08, "Thanos Makatos" <thanos.makatos@citrix.com> wrote:
>
>> I was wondering whether it would make sense to have blktap3 in C++. I don't
>> have very strong feelings about it; I'd prefer to have it in C++, but it's
>> already written in C and it works. The benefits of having it in C++ would be
>> code clarity and maintainability. I bring this up now because I'm currently
>> cleaning it up, so it's the best time to do it, should we decide to do so.
>
> Leave it be, and learn how to write maintainable C code!

Hehe a personal opinion is that C is a more readable/maintainable
language because it is fundamentally simpler. :)

With that said, where can I find the source for blktap3? is it in the
xen-unstable.hg?

>
>> --
>> Thanos Makatos

Cheers,

Joseph.

-- 
CTO | Orion Virtualisation Solutions | www.orionvm.com.au
Phone: 1300 56 99 52 | Mobile: 0428 754 846

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 07 21:09:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Sep 2012 21: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 1TA5nA-0004WT-0X; Fri, 07 Sep 2012 21:08:44 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <joseph.glanville@orionvm.com.au>) id 1TA5n7-0004WM-RV
	for xen-devel@lists.xensource.com; Fri, 07 Sep 2012 21:08:42 +0000
Received: from [85.158.139.83:64301] by server-10.bemta-5.messagelabs.com id
	4E/2A-10969-9526A405; Fri, 07 Sep 2012 21:08:41 +0000
X-Env-Sender: joseph.glanville@orionvm.com.au
X-Msg-Ref: server-7.tower-182.messagelabs.com!1347052119!25303673!1
X-Originating-IP: [209.85.214.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28712 invoked from network); 7 Sep 2012 21:08:40 -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;
	7 Sep 2012 21:08:40 -0000
Received: by obqv19 with SMTP id v19so46600obq.30
	for <xen-devel@lists.xensource.com>;
	Fri, 07 Sep 2012 14:08:39 -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=8xGCgPioGPayXxRZih72FvFBTIEXYx9sNLHBuLlykLs=;
	b=nX/xzbVYKVD+CP6TUGoH1pIKPs3Tca7gX8Y/oyocNseHhDzDWbUlL3LNLNw0dje9Dl
	j5u2jcdkmZjF6MJkBkanow/0WucMZc+KUloZoxhOHsOUjNYFAktV87/TYXqc60VwK2zo
	Jvl5kPDqpBEZMRKhIAYpJSyGywUTAfPhhKoaQw15tUIS9O7z6bBZhFKttMuvzu9Isb3U
	Rgr5+QCEHJ5HCAU5MA3vMcUZ7oyF5/qTcOovetVS5gUQhnCJa0lrmSJsBDSjXZUXZ1E5
	+1+k3PvkijATQ10NLR2XgUPSiuamkQJppiTxLcbZ7FcmXh6dnDk0+1jcLHYo97Fz26gz
	i3Tw==
MIME-Version: 1.0
Received: by 10.60.154.198 with SMTP id vq6mr7681219oeb.20.1347052118832; Fri,
	07 Sep 2012 14:08:38 -0700 (PDT)
Received: by 10.182.80.200 with HTTP; Fri, 7 Sep 2012 14:08:38 -0700 (PDT)
X-Originating-IP: [121.44.62.75]
In-Reply-To: <CC6FCF98.4AF76%keir@xen.org>
References: <4B45B535F7F6BE4CB1C044ED5115CDDE011A6DAD77DF@LONPMAILBOX01.citrite.net>
	<CC6FCF98.4AF76%keir@xen.org>
Date: Sat, 8 Sep 2012 07:08:38 +1000
Message-ID: <CAOzFzEhVuWAhQfQKQSS5ztWaWUTTBfn_1eKqJqit3EX-sK-DOA@mail.gmail.com>
From: Joseph Glanville <joseph.glanville@orionvm.com.au>
To: Keir Fraser <keir@xen.org>
X-Gm-Message-State: ALoCoQn1OAbkLEBKN/5GBmi+niH68CPeQ2HVzgZYJMayfKuhLMTprxVq1TuaM3a/bIWbOZylE162
Cc: Thanos Makatos <thanos.makatos@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] blktap3 in C++?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 8 September 2012 01:21, Keir Fraser <keir@xen.org> wrote:
> On 07/09/2012 16:08, "Thanos Makatos" <thanos.makatos@citrix.com> wrote:
>
>> I was wondering whether it would make sense to have blktap3 in C++. I don't
>> have very strong feelings about it; I'd prefer to have it in C++, but it's
>> already written in C and it works. The benefits of having it in C++ would be
>> code clarity and maintainability. I bring this up now because I'm currently
>> cleaning it up, so it's the best time to do it, should we decide to do so.
>
> Leave it be, and learn how to write maintainable C code!

Hehe a personal opinion is that C is a more readable/maintainable
language because it is fundamentally simpler. :)

With that said, where can I find the source for blktap3? is it in the
xen-unstable.hg?

>
>> --
>> Thanos Makatos

Cheers,

Joseph.

-- 
CTO | Orion Virtualisation Solutions | www.orionvm.com.au
Phone: 1300 56 99 52 | Mobile: 0428 754 846

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 07 21:35:58 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Sep 2012 21: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 1TA6D9-0004su-MX; Fri, 07 Sep 2012 21:35:35 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <daniel.lezcano@linaro.org>) id 1TA6D8-0004sp-UJ
	for xen-devel@lists.xensource.com; Fri, 07 Sep 2012 21:35:35 +0000
Received: from [85.158.138.51:35902] by server-10.bemta-3.messagelabs.com id
	B7/00-10411-6A86A405; Fri, 07 Sep 2012 21:35:34 +0000
X-Env-Sender: daniel.lezcano@linaro.org
X-Msg-Ref: server-15.tower-174.messagelabs.com!1347053732!27582208!1
X-Originating-IP: [74.125.82.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3786 invoked from network); 7 Sep 2012 21:35:32 -0000
Received: from mail-we0-f171.google.com (HELO mail-we0-f171.google.com)
	(74.125.82.171)
	by server-15.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Sep 2012 21:35:32 -0000
Received: by weys43 with SMTP id s43so28109wey.30
	for <xen-devel@lists.xensource.com>;
	Fri, 07 Sep 2012 14:35:32 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=message-id:date:from:user-agent:mime-version:to:cc:subject
	:references:in-reply-to:content-type:content-transfer-encoding
	:x-gm-message-state;
	bh=/ux9Pp5sOmqj6/e7/cL3S/rk9z1f+WoutlWpXrOvtEE=;
	b=Bbhc5KZd9KQK0w9QTWx4R5MHAdrmYFVmqpcBNmkiqlmtk/d12rM4THZ9Jp5foqYXNy
	jtFASrFUODHEkFAqIJ6U13YWb3s6NsgT9JT5I29LNu8To5Ah6dmiK3ROqhP7veT+YBAr
	36593+5/klbAYl0VOy0jQ65UEXEoqcBVbmAF8wk52wTcNjsIAcw1Lx2xFgRweVzv8TGH
	VEsOlJgwRYCFhXloE3NXvfPXs3Iu4TyU34PgKNCOCOgPii2fmn2A5PPnXCazxBCUYDhC
	5m7GMg76tcnNj75gDIFDQ1K6v3rsG4bHD6TnnF2hDswhFcAR4Aw98tzGHUc4XO2014GW
	68PQ==
Received: by 10.216.138.200 with SMTP id a50mr3871941wej.155.1347053731963;
	Fri, 07 Sep 2012 14:35:31 -0700 (PDT)
Received: from [192.168.1.11] (AToulouse-651-1-16-21.w92-149.abo.wanadoo.fr.
	[92.149.191.21])
	by mx.google.com with ESMTPS id cu1sm961400wib.6.2012.09.07.14.35.29
	(version=SSLv3 cipher=OTHER); Fri, 07 Sep 2012 14:35:30 -0700 (PDT)
Message-ID: <504A68A0.7010907@linaro.org>
Date: Fri, 07 Sep 2012 23:35:28 +0200
From: Daniel Lezcano <daniel.lezcano@linaro.org>
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:12.0) Gecko/20120430 Thunderbird/12.0.1
MIME-Version: 1.0
To: John Stultz <john.stultz@linaro.org>
References: <1343164349-28550-1-git-send-email-daniel.lezcano@linaro.org>
	<201209062204.11288.rjw@sisk.pl> <50490920.9070204@linaro.org>
	<201209062318.42874.rjw@sisk.pl> <504A02BD.4000805@linaro.org>
	<504A2D73.3010702@linaro.org>
In-Reply-To: <504A2D73.3010702@linaro.org>
X-Gm-Message-State: ALoCoQnHbgjHoxHRmACowi1OjLpjBKZeFEmH1GEEmoHGAriB7GwXhiyu+MTxgUkH5RQGuGoqTTAP
Cc: prarit@redhat.com, xen-devel@lists.xensource.com,
	linaro-dev@lists.linaro.org, Peter Zijlstra <a.p.zijlstra@chello.nl>,
	linux-pm@vger.kernel.org, Frederic Weisbecker <fweisbec@gmail.com>,
	richardcochran@gmail.com, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	"Rafael J. Wysocki" <rjw@sisk.pl>, linux-acpi@vger.kernel.org,
	Thomas Gleixner <tglx@linutronix.de>, mingo@kernel.org, lenb@kernel.org
Subject: Re: [Xen-devel] CONFIG_NO_HZ + CONFIG_CPU_IDLE freeze the system
 (Was Re: [PATCH] acpi : remove power from acpi_processor_cx structure)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gMDkvMDcvMjAxMiAwNzoyMiBQTSwgSm9obiBTdHVsdHogd3JvdGU6Cj4gT24gMDkvMDcvMjAx
MiAwNzoyMCBBTSwgRGFuaWVsIExlemNhbm8gd3JvdGU6Cj4+IE9uIDA5LzA2LzIwMTIgMTE6MTgg
UE0sIFJhZmFlbCBKLiBXeXNvY2tpIHdyb3RlOgo+Pj4gT24gVGh1cnNkYXksIFNlcHRlbWJlciAw
NiwgMjAxMiwgRGFuaWVsIExlemNhbm8gd3JvdGU6Cj4+Pj4gT24gMDkvMDYvMjAxMiAxMDowNCBQ
TSwgUmFmYWVsIEouIFd5c29ja2kgd3JvdGU6Cj4+Pj4+IE9uIFRodXJzZGF5LCBTZXB0ZW1iZXIg
MDYsIDIwMTIsIERhbmllbCBMZXpjYW5vIHdyb3RlOgo+Pj4+Pj4gT24gMDkvMDYvMjAxMiAwOTo1
NCBBTSwgRGFuaWVsIExlemNhbm8gd3JvdGU6Cj4+Pj4+PiBJIGZhbGwgaW50byB0aGlzIGlzc3Vl
IGJlY2F1c2UgTkVUQ09OU09MRSBpcyBzZXQsIGRpc2FibGluZyBpdAo+Pj4+Pj4gYWxsb3dlZAo+
Pj4+Pj4gbWUgdG8gZ28gZnVydGhlci4KPj4+Pj4+Cj4+Pj4+PiBVbmZvcnR1bmF0ZWx5IEkgYW0g
ZmFjaW5nIHRvIHNvbWUgcmFuZG9tIGZyZWV6ZSBvbiB0aGUgc3lzdGVtIHdoaWNoCj4+Pj4+PiBz
ZWVtcyB0byBiZSByZWxhdGVkIHRvIENPTkZJR19OT19IWj15IGFuZCBDT05GSUdfQ1BVX0lETEU9
eS4KPj4+Pj4+Cj4+Pj4+PiBEaXNhYmxpbmcgb25lIG9mIHRoZW0sIG1ha2UgdGhlIGZyZWV6ZXMg
dG8gZGlzYXBwZWFyLgo+Pj4+Pj4KPj4+Pj4+IElzIGl0IGEga25vd24gaXNzdWUgPwo+Pj4+PiBX
ZWxsLCB0aGVyZSBhcmUgc3lzdGVtcyBoYXZpbmcgcHJvYmxlbXMgd2l0aCB0aGlzIGNvbmZpZ3Vy
YXRpb24sCj4+Pj4+IGJ1dCB0aGV5Cj4+Pj4+IHNob3VsZCBiZSBleGNlcHRpb25hbC4gIFdoYXQg
c3lzdGVtIGlzIHRoYXQ/Cj4+Pj4gSXQgaXMgYSBsYXB0b3AgVDYxcCB3aXRoIGEgQ29yZSAyIER1
byBUOTUwMC4gTm90aGluZyBleGNlcHRpb25hbCBJCj4+Pj4gYmVsaWV2ZS4gTWF5YmUgc29tZW9u
ZSBnb3QgdGhlIHNhbWUgaXNzdWUgPwo+Pj4gSXMgaXQgYSByZWdyZXNzaW9uIGZvciB5b3U/Cj4+
IFllcywgSSB0aGluayBzby4gVGhlIGlzc3VlIGFwcGVhcnMgYmV0d2VlbiB2My41IGFuZCB2My42
LXJjMS4KPj4KPj4gSXQgaXMgbm90IGVhc3kgdG8gcmVwcm9kdWNlIGJ1dCBhZnRlciB0YWtpbmcg
c29tZSB0aW1lIHRvIGRpZywgaXQgc2VlbXMKPj4gdG8gYXBwZWFyIHdpdGggdGhpcyBjb21taXQ6
Cj4+Cj4+IDFlNzVmYThiZTlmYjYxZTFhZjQ2YjViM2IxNzYzNDdhNGM5NThjYTEgaXMgdGhlIGZp
cnN0IGJhZCBjb21taXQKPj4gY29tbWl0IDFlNzVmYThiZTlmYjYxZTFhZjQ2YjViM2IxNzYzNDdh
NGM5NThjYTEKPj4gQXV0aG9yOiBKb2huIFN0dWx0eiA8am9obi5zdHVsdHpAbGluYXJvLm9yZz4K
Pj4gRGF0ZTogICBGcmkgSnVsIDEzIDAxOjIxOjUzIDIwMTIgLTA0MDAKPj4KPj4gICAgICB0aW1l
OiBDb25kZW5zZSB0aW1la2VlcGVyLnh0aW1lIGludG8geHRpbWVfc2VjCj4+Cj4+ICAgICAgVGhl
IHRpbWVrZWVwZXIgc3RydWN0IGhhcyBhIHh0aW1lX25zZWMsIHdoaWNoIGtlZXBzIHRoZQo+PiAg
ICAgIHN1Yi1uYW5vc2Vjb25kIHJlbWFpbmRlci4gIFRoaXMgZW5kcyB1cCBiZWluZyBzb21ld2hh
dAo+PiAgICAgIGR1cGxpY2F0aXZlIG9mIHRoZSB0aW1la2VlcGVyLnh0aW1lLnR2X25zZWMgdmFs
dWUsIGFuZCB3ZQo+PiAgICAgIGhhdmUgdG8gZG8gZXh0cmEgd29yayB0byBrZWVwIHRoZW0gYXBh
cnQsIGNvcHlpbmcgdGhlIGZ1bGwKPj4gICAgICBuc2VjIHBvcnRpb24gb3V0IGFuZCBiYWNrIGlu
IG92ZXIgYW5kIG92ZXIuCj4+Cj4+ICAgICAgVGhpcyBwYXRjaCBzaW1wbGlmaWVzIHNvbWUgb2Yg
dGhlIGxvZ2ljIGJ5IHRha2luZyB0aGUgdGltZWtlZXBlcgo+PiAgICAgIHh0aW1lIHZhbHVlIGFu
ZCBzcGxpdHRpbmcgaXQgaW50byB0aW1la2VlcGVyLnh0aW1lX3NlYyBhbmQKPj4gICAgICByZXVz
ZXMgdGhlIHRpbWVrZWVwZXIueHRpbWVfbnNlYyBmb3IgdGhlIHN1Yi1zZWNvbmQgcG9ydGlvbgo+
PiAgICAgIChzdG9yZWQgaW4gaGlnaGVyIHJlcyBzaGlmdGVkIG5hbm9zZWNvbmRzKS4KPj4KPj4g
ICAgICBUaGlzIHNpbXBsaWZpZXMgc29tZSBvZiB0aGUgYWNjdW11bGF0aW9uIGxvZ2ljLiBBbmQg
d2lsbAo+PiAgICAgIGFsbG93IGZvciBtb3JlIGFjY3VyYXRlIHRpbWVrZWVwaW5nIG9uY2UgdGhl
IHZzeXNjYWxsIGNvZGUKPj4gICAgICBpcyB1cGRhdGVkIHRvIHVzZSB0aGUgc2hpZnRlZCBuYW5v
c2Vjb25kIHJlbWFpbmRlci4KPj4KPj4gICAgICBTaWduZWQtb2ZmLWJ5OiBKb2huIFN0dWx0eiA8
am9obi5zdHVsdHpAbGluYXJvLm9yZz4KPj4gICAgICBSZXZpZXdlZC1ieTogSW5nbyBNb2xuYXIg
PG1pbmdvQGtlcm5lbC5vcmc+Cj4+ICAgICAgQ2M6IFBldGVyIFppamxzdHJhIDxhLnAuemlqbHN0
cmFAY2hlbGxvLm5sPgo+PiAgICAgIENjOiBSaWNoYXJkIENvY2hyYW4gPHJpY2hhcmRjb2NocmFu
QGdtYWlsLmNvbT4KPj4gICAgICBDYzogUHJhcml0IEJoYXJnYXZhIDxwcmFyaXRAcmVkaGF0LmNv
bT4KPj4gICAgICBMaW5rOgo+PiBodHRwOi8vbGttbC5rZXJuZWwub3JnL3IvMTM0MjE1NjkxNy0y
NTA5Mi01LWdpdC1zZW5kLWVtYWlsLWpvaG4uc3R1bHR6QGxpbmFyby5vcmcKPj4KPj4gICAgICBT
aWduZWQtb2ZmLWJ5OiBUaG9tYXMgR2xlaXhuZXIgPHRnbHhAbGludXRyb25peC5kZT4KPj4KPj4g
OjA0MDAwMCAwNDAwMDAgNGQ2NTQxYWMxZjYwNzVkN2FkZWUxZWVmNDk0YjMxYTBjYmRhMDkzNAo+
PiBkYzU3MDhiYzczOGFmNjk1ZjA5MmJmODIyODA5YjEzYTFkYTEwNGI2IE0gICAga2VybmVsCj4+
Cj4+IEhvdyB0byByZXByb2R1Y2U6IHdpdGggYSBsYXB0b3AgVDYxcCwgd2l0aCBhIENvcmUgMiBE
dW8uIEkgYm9vdCB0aGUKPj4ga2VybmVsIGluIGJ1c3lib3ggYW5kIHdhaXQgc29tZSBtaW51dGVz
IGJlZm9yZSB3cml0aW5nIHNvbWV0aGluZyBpbiB0aGUKPj4gY29uc29sZS4gQXQgdGhpcyBtb21l
bnQsIG5vdGhpbmcgYXBwZWFycyB0byB0aGUgY29uc29sZSBidXQgdGhlCj4+IGNoYXJhY3RlcnMg
YXJlIGVjaG8nZWQgc2V2ZXJhbCBzZWNvbmRzIGxhdGVyIChjb3VsZCBiZSAxLCA1LCBvciAxMCBz
ZWNzCj4+IG9yIG1vcmUpLgo+Pgo+PiBUaGF0IGhhcHBlbnMgd2hlbiBDT05GSUdfQ1BVX0lETEUg
YW5kIENPTkZJR19OT19IWiBhcmUgc2V0LiBEaXNhYmxpbmcKPj4gb25lIG9mIHRoZW0sIHRoZSBp
c3N1ZSBkb2VzIG5vdCBhcHBlYXIuCj4gCj4gVGhhbmtzIGZvciBiaXNlY3RpbmcgdGhpcyBkb3du
IGFuZCB0aGUgaGVhZHMgdXAhCj4gCj4gUmlnaHQgb2ZmIEkgY2FuJ3Qgc2VlIHdoYXQgbWlnaHQg
YmUgY2F1c2luZyB0aGlzLiAgQnVuY2ggb2YgcXVlc3Rpb25zOgo+IAo+IElzIHRoaXMgYSAzMiBv
ciA2NCBiaXQga2VybmVsPwoKSXQgaXMgYSAzMiBiaXQga2VybmVsLgoKPiBCeSB5b3VyIGRlc2Ny
aXB0aW9uIGFib3ZlLCBpdCBzb3VuZHMgbGlrZSB0aGUgc3lzdGVtIGlzIHN0aWxsCj4gZnVuY3Rp
b25pbmcsIGJ1dCB0aGVyZSdzIGp1c3QgYSBoaWdoIGxhdGVuY3kgZm9yIGtleS1pbnB1dC4gSXMg
dGhhdCByaWdodD8KClllcyB0aGF0J3MgY29ycmVjdCBidXQgbm90IG9ubHkuIER1cmluZyB0aGlz
IGZyZWV6ZSB0aW1lLCBJIGNhbid0IHBpbmcKdGhlIGhvc3QuIFdoZW4gdGhlIG91dHB1dCBpcyBl
Y2hvJ2VkLCB0aGUgcGluZyB3b3JrcyBhZ2Fpbi4KCkJ1dCBpZiBJIHBpbmcgdGhlIGhvc3QgaW5k
ZWZpbml0ZWx5LCBpdCBkb2VzIG5vdCBmcmVlemUgYW5kIHRoZSBjb25zb2xlCmlzIGVjaG8nZWQg
d2l0aG91dCBwcm9ibGVtLgoKPiBBcmUgb3RoZXIgdGhpbmdzIG9uIHRoZSBzeXN0ZW0gaGFwcGVu
aW5nIHNsb3dseT8KCkkgaGF2ZSBhIHZlcnkgbWluaW1hbCBzeXN0ZW0gYnV0IGF0IHRoZSBmaXJz
dCBnbGFuY2Ugd2hlbiBpdCBpcyBub3QgZnJvemVuCgo+IERvZXMgZ2VuZXJhdGluZyBpbnRlcnJ1
cHRzIGJ5IGhpdHRpbmcvaG9sZGluZyBkb3duIHRoZSBjdHJsIGtleSBtYWtlIHRoZQo+IHN5c3Rl
bSByZXNwb25kIGZhc3Rlcj8KCm5vLgoKPiBJcyB0aGVyZSBhbnkgZG1lc2cgb3V0cHV0IG5lYXIg
d2hlbiBpdCBvY2N1cnM/Cgpuby4KCj4gSWYgeW91IGRvbid0IHdhaXQgdGhhdCBtaW51dGUgYWZ0
ZXIgYm9vdCBiZWZvcmUgdHlwaW5nIGFueXRoaW5nLCBkb2VzIGl0Cj4gc3RpbGwgdHJpZ2dlciBs
YXRlcj8gKG9yIGlzIGl0IHRpZWQgdG8gZWFybHkgYm9vdD8pCgpUaGF0IGRlcGVuZHMsIHRoYXQg
Y291bGQgaGFwcGVuIGltbWVkaWF0ZWx5IG9yIGxhdGVyLiBJdCBpcyBtb3JlIG9yIGxlc3MKcmFu
ZG9tLgoKPiBPbiBhIHdoaW0sIGRvZXMgdGhlIHBhdGNoIGJlbG93IGF2b2lkIHRoZSBwcm9ibGVt
PwoKTm9wZSwgc2FtZSBpc3N1ZSA6LwoKVGhhbmtzCiAgLS0gRGFuaWVsCgo+IAo+IHRoYW5rcwo+
IC1qb2huCj4gCj4gZGlmZiAtLWdpdCBhL2tlcm5lbC90aW1lL3RpbWVrZWVwaW5nLmMgYi9rZXJu
ZWwvdGltZS90aW1la2VlcGluZy5jCj4gaW5kZXggMzRlNWVhYy4uMmZhMGU1MiAxMDA2NDQKPiAt
LS0gYS9rZXJuZWwvdGltZS90aW1la2VlcGluZy5jCj4gKysrIGIva2VybmVsL3RpbWUvdGltZWtl
ZXBpbmcuYwo+IEBAIC0xMTc5LDYgKzExNzksNyBAQCBzdGF0aWMgdm9pZCB1cGRhdGVfd2FsbF90
aW1lKHZvaWQpCj4gICAgICB0aW1la2VlcGluZ19hZGp1c3QodGssIG9mZnNldCk7Cj4gIAo+ICAK
PiArI2lmIDAKPiAgICAgIC8qCj4gICAgICAqIFN0b3JlIG9ubHkgZnVsbCBuYW5vc2Vjb25kcyBp
bnRvIHh0aW1lX25zZWMgYWZ0ZXIgcm91bmRpbmcKPiAgICAgICogaXQgdXAgYW5kIGFkZCB0aGUg
cmVtYWluZGVyIHRvIHRoZSBlcnJvciBkaWZmZXJlbmNlLgo+IEBAIC0xMTkyLDYgKzExOTMsNyBA
QCBzdGF0aWMgdm9pZCB1cGRhdGVfd2FsbF90aW1lKHZvaWQpCj4gICAgICB0ay0+eHRpbWVfbnNl
YyAtPSByZW1haW5kZXI7Cj4gICAgICB0ay0+eHRpbWVfbnNlYyArPSAxVUxMIDw8IHRrLT5zaGlm
dDsKPiAgICAgIHRrLT5udHBfZXJyb3IgKz0gcmVtYWluZGVyIDw8IHRrLT5udHBfZXJyb3Jfc2hp
ZnQ7Cj4gKyNlbmRpZgo+ICAKPiAgICAgIC8qCj4gICAgICAgKiBGaW5hbGx5LCBtYWtlIHN1cmUg
dGhhdCBhZnRlciB0aGUgcm91bmRpbmcKPiAKCgotLSAKIDxodHRwOi8vd3d3LmxpbmFyby5vcmcv
PiBMaW5hcm8ub3JnIOKUgiBPcGVuIHNvdXJjZSBzb2Z0d2FyZSBmb3IgQVJNIFNvQ3MKCkZvbGxv
dyBMaW5hcm86ICA8aHR0cDovL3d3dy5mYWNlYm9vay5jb20vcGFnZXMvTGluYXJvPiBGYWNlYm9v
ayB8CjxodHRwOi8vdHdpdHRlci5jb20vIyEvbGluYXJvb3JnPiBUd2l0dGVyIHwKPGh0dHA6Ly93
d3cubGluYXJvLm9yZy9saW5hcm8tYmxvZy8+IEJsb2cKCgpfX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fXwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZl
bEBsaXN0cy54ZW4ub3JnCmh0dHA6Ly9saXN0cy54ZW4ub3JnL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xen.org Fri Sep 07 21:35:58 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 07 Sep 2012 21: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 1TA6D9-0004su-MX; Fri, 07 Sep 2012 21:35:35 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <daniel.lezcano@linaro.org>) id 1TA6D8-0004sp-UJ
	for xen-devel@lists.xensource.com; Fri, 07 Sep 2012 21:35:35 +0000
Received: from [85.158.138.51:35902] by server-10.bemta-3.messagelabs.com id
	B7/00-10411-6A86A405; Fri, 07 Sep 2012 21:35:34 +0000
X-Env-Sender: daniel.lezcano@linaro.org
X-Msg-Ref: server-15.tower-174.messagelabs.com!1347053732!27582208!1
X-Originating-IP: [74.125.82.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3786 invoked from network); 7 Sep 2012 21:35:32 -0000
Received: from mail-we0-f171.google.com (HELO mail-we0-f171.google.com)
	(74.125.82.171)
	by server-15.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Sep 2012 21:35:32 -0000
Received: by weys43 with SMTP id s43so28109wey.30
	for <xen-devel@lists.xensource.com>;
	Fri, 07 Sep 2012 14:35:32 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=message-id:date:from:user-agent:mime-version:to:cc:subject
	:references:in-reply-to:content-type:content-transfer-encoding
	:x-gm-message-state;
	bh=/ux9Pp5sOmqj6/e7/cL3S/rk9z1f+WoutlWpXrOvtEE=;
	b=Bbhc5KZd9KQK0w9QTWx4R5MHAdrmYFVmqpcBNmkiqlmtk/d12rM4THZ9Jp5foqYXNy
	jtFASrFUODHEkFAqIJ6U13YWb3s6NsgT9JT5I29LNu8To5Ah6dmiK3ROqhP7veT+YBAr
	36593+5/klbAYl0VOy0jQ65UEXEoqcBVbmAF8wk52wTcNjsIAcw1Lx2xFgRweVzv8TGH
	VEsOlJgwRYCFhXloE3NXvfPXs3Iu4TyU34PgKNCOCOgPii2fmn2A5PPnXCazxBCUYDhC
	5m7GMg76tcnNj75gDIFDQ1K6v3rsG4bHD6TnnF2hDswhFcAR4Aw98tzGHUc4XO2014GW
	68PQ==
Received: by 10.216.138.200 with SMTP id a50mr3871941wej.155.1347053731963;
	Fri, 07 Sep 2012 14:35:31 -0700 (PDT)
Received: from [192.168.1.11] (AToulouse-651-1-16-21.w92-149.abo.wanadoo.fr.
	[92.149.191.21])
	by mx.google.com with ESMTPS id cu1sm961400wib.6.2012.09.07.14.35.29
	(version=SSLv3 cipher=OTHER); Fri, 07 Sep 2012 14:35:30 -0700 (PDT)
Message-ID: <504A68A0.7010907@linaro.org>
Date: Fri, 07 Sep 2012 23:35:28 +0200
From: Daniel Lezcano <daniel.lezcano@linaro.org>
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:12.0) Gecko/20120430 Thunderbird/12.0.1
MIME-Version: 1.0
To: John Stultz <john.stultz@linaro.org>
References: <1343164349-28550-1-git-send-email-daniel.lezcano@linaro.org>
	<201209062204.11288.rjw@sisk.pl> <50490920.9070204@linaro.org>
	<201209062318.42874.rjw@sisk.pl> <504A02BD.4000805@linaro.org>
	<504A2D73.3010702@linaro.org>
In-Reply-To: <504A2D73.3010702@linaro.org>
X-Gm-Message-State: ALoCoQnHbgjHoxHRmACowi1OjLpjBKZeFEmH1GEEmoHGAriB7GwXhiyu+MTxgUkH5RQGuGoqTTAP
Cc: prarit@redhat.com, xen-devel@lists.xensource.com,
	linaro-dev@lists.linaro.org, Peter Zijlstra <a.p.zijlstra@chello.nl>,
	linux-pm@vger.kernel.org, Frederic Weisbecker <fweisbec@gmail.com>,
	richardcochran@gmail.com, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	"Rafael J. Wysocki" <rjw@sisk.pl>, linux-acpi@vger.kernel.org,
	Thomas Gleixner <tglx@linutronix.de>, mingo@kernel.org, lenb@kernel.org
Subject: Re: [Xen-devel] CONFIG_NO_HZ + CONFIG_CPU_IDLE freeze the system
 (Was Re: [PATCH] acpi : remove power from acpi_processor_cx structure)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gMDkvMDcvMjAxMiAwNzoyMiBQTSwgSm9obiBTdHVsdHogd3JvdGU6Cj4gT24gMDkvMDcvMjAx
MiAwNzoyMCBBTSwgRGFuaWVsIExlemNhbm8gd3JvdGU6Cj4+IE9uIDA5LzA2LzIwMTIgMTE6MTgg
UE0sIFJhZmFlbCBKLiBXeXNvY2tpIHdyb3RlOgo+Pj4gT24gVGh1cnNkYXksIFNlcHRlbWJlciAw
NiwgMjAxMiwgRGFuaWVsIExlemNhbm8gd3JvdGU6Cj4+Pj4gT24gMDkvMDYvMjAxMiAxMDowNCBQ
TSwgUmFmYWVsIEouIFd5c29ja2kgd3JvdGU6Cj4+Pj4+IE9uIFRodXJzZGF5LCBTZXB0ZW1iZXIg
MDYsIDIwMTIsIERhbmllbCBMZXpjYW5vIHdyb3RlOgo+Pj4+Pj4gT24gMDkvMDYvMjAxMiAwOTo1
NCBBTSwgRGFuaWVsIExlemNhbm8gd3JvdGU6Cj4+Pj4+PiBJIGZhbGwgaW50byB0aGlzIGlzc3Vl
IGJlY2F1c2UgTkVUQ09OU09MRSBpcyBzZXQsIGRpc2FibGluZyBpdAo+Pj4+Pj4gYWxsb3dlZAo+
Pj4+Pj4gbWUgdG8gZ28gZnVydGhlci4KPj4+Pj4+Cj4+Pj4+PiBVbmZvcnR1bmF0ZWx5IEkgYW0g
ZmFjaW5nIHRvIHNvbWUgcmFuZG9tIGZyZWV6ZSBvbiB0aGUgc3lzdGVtIHdoaWNoCj4+Pj4+PiBz
ZWVtcyB0byBiZSByZWxhdGVkIHRvIENPTkZJR19OT19IWj15IGFuZCBDT05GSUdfQ1BVX0lETEU9
eS4KPj4+Pj4+Cj4+Pj4+PiBEaXNhYmxpbmcgb25lIG9mIHRoZW0sIG1ha2UgdGhlIGZyZWV6ZXMg
dG8gZGlzYXBwZWFyLgo+Pj4+Pj4KPj4+Pj4+IElzIGl0IGEga25vd24gaXNzdWUgPwo+Pj4+PiBX
ZWxsLCB0aGVyZSBhcmUgc3lzdGVtcyBoYXZpbmcgcHJvYmxlbXMgd2l0aCB0aGlzIGNvbmZpZ3Vy
YXRpb24sCj4+Pj4+IGJ1dCB0aGV5Cj4+Pj4+IHNob3VsZCBiZSBleGNlcHRpb25hbC4gIFdoYXQg
c3lzdGVtIGlzIHRoYXQ/Cj4+Pj4gSXQgaXMgYSBsYXB0b3AgVDYxcCB3aXRoIGEgQ29yZSAyIER1
byBUOTUwMC4gTm90aGluZyBleGNlcHRpb25hbCBJCj4+Pj4gYmVsaWV2ZS4gTWF5YmUgc29tZW9u
ZSBnb3QgdGhlIHNhbWUgaXNzdWUgPwo+Pj4gSXMgaXQgYSByZWdyZXNzaW9uIGZvciB5b3U/Cj4+
IFllcywgSSB0aGluayBzby4gVGhlIGlzc3VlIGFwcGVhcnMgYmV0d2VlbiB2My41IGFuZCB2My42
LXJjMS4KPj4KPj4gSXQgaXMgbm90IGVhc3kgdG8gcmVwcm9kdWNlIGJ1dCBhZnRlciB0YWtpbmcg
c29tZSB0aW1lIHRvIGRpZywgaXQgc2VlbXMKPj4gdG8gYXBwZWFyIHdpdGggdGhpcyBjb21taXQ6
Cj4+Cj4+IDFlNzVmYThiZTlmYjYxZTFhZjQ2YjViM2IxNzYzNDdhNGM5NThjYTEgaXMgdGhlIGZp
cnN0IGJhZCBjb21taXQKPj4gY29tbWl0IDFlNzVmYThiZTlmYjYxZTFhZjQ2YjViM2IxNzYzNDdh
NGM5NThjYTEKPj4gQXV0aG9yOiBKb2huIFN0dWx0eiA8am9obi5zdHVsdHpAbGluYXJvLm9yZz4K
Pj4gRGF0ZTogICBGcmkgSnVsIDEzIDAxOjIxOjUzIDIwMTIgLTA0MDAKPj4KPj4gICAgICB0aW1l
OiBDb25kZW5zZSB0aW1la2VlcGVyLnh0aW1lIGludG8geHRpbWVfc2VjCj4+Cj4+ICAgICAgVGhl
IHRpbWVrZWVwZXIgc3RydWN0IGhhcyBhIHh0aW1lX25zZWMsIHdoaWNoIGtlZXBzIHRoZQo+PiAg
ICAgIHN1Yi1uYW5vc2Vjb25kIHJlbWFpbmRlci4gIFRoaXMgZW5kcyB1cCBiZWluZyBzb21ld2hh
dAo+PiAgICAgIGR1cGxpY2F0aXZlIG9mIHRoZSB0aW1la2VlcGVyLnh0aW1lLnR2X25zZWMgdmFs
dWUsIGFuZCB3ZQo+PiAgICAgIGhhdmUgdG8gZG8gZXh0cmEgd29yayB0byBrZWVwIHRoZW0gYXBh
cnQsIGNvcHlpbmcgdGhlIGZ1bGwKPj4gICAgICBuc2VjIHBvcnRpb24gb3V0IGFuZCBiYWNrIGlu
IG92ZXIgYW5kIG92ZXIuCj4+Cj4+ICAgICAgVGhpcyBwYXRjaCBzaW1wbGlmaWVzIHNvbWUgb2Yg
dGhlIGxvZ2ljIGJ5IHRha2luZyB0aGUgdGltZWtlZXBlcgo+PiAgICAgIHh0aW1lIHZhbHVlIGFu
ZCBzcGxpdHRpbmcgaXQgaW50byB0aW1la2VlcGVyLnh0aW1lX3NlYyBhbmQKPj4gICAgICByZXVz
ZXMgdGhlIHRpbWVrZWVwZXIueHRpbWVfbnNlYyBmb3IgdGhlIHN1Yi1zZWNvbmQgcG9ydGlvbgo+
PiAgICAgIChzdG9yZWQgaW4gaGlnaGVyIHJlcyBzaGlmdGVkIG5hbm9zZWNvbmRzKS4KPj4KPj4g
ICAgICBUaGlzIHNpbXBsaWZpZXMgc29tZSBvZiB0aGUgYWNjdW11bGF0aW9uIGxvZ2ljLiBBbmQg
d2lsbAo+PiAgICAgIGFsbG93IGZvciBtb3JlIGFjY3VyYXRlIHRpbWVrZWVwaW5nIG9uY2UgdGhl
IHZzeXNjYWxsIGNvZGUKPj4gICAgICBpcyB1cGRhdGVkIHRvIHVzZSB0aGUgc2hpZnRlZCBuYW5v
c2Vjb25kIHJlbWFpbmRlci4KPj4KPj4gICAgICBTaWduZWQtb2ZmLWJ5OiBKb2huIFN0dWx0eiA8
am9obi5zdHVsdHpAbGluYXJvLm9yZz4KPj4gICAgICBSZXZpZXdlZC1ieTogSW5nbyBNb2xuYXIg
PG1pbmdvQGtlcm5lbC5vcmc+Cj4+ICAgICAgQ2M6IFBldGVyIFppamxzdHJhIDxhLnAuemlqbHN0
cmFAY2hlbGxvLm5sPgo+PiAgICAgIENjOiBSaWNoYXJkIENvY2hyYW4gPHJpY2hhcmRjb2NocmFu
QGdtYWlsLmNvbT4KPj4gICAgICBDYzogUHJhcml0IEJoYXJnYXZhIDxwcmFyaXRAcmVkaGF0LmNv
bT4KPj4gICAgICBMaW5rOgo+PiBodHRwOi8vbGttbC5rZXJuZWwub3JnL3IvMTM0MjE1NjkxNy0y
NTA5Mi01LWdpdC1zZW5kLWVtYWlsLWpvaG4uc3R1bHR6QGxpbmFyby5vcmcKPj4KPj4gICAgICBT
aWduZWQtb2ZmLWJ5OiBUaG9tYXMgR2xlaXhuZXIgPHRnbHhAbGludXRyb25peC5kZT4KPj4KPj4g
OjA0MDAwMCAwNDAwMDAgNGQ2NTQxYWMxZjYwNzVkN2FkZWUxZWVmNDk0YjMxYTBjYmRhMDkzNAo+
PiBkYzU3MDhiYzczOGFmNjk1ZjA5MmJmODIyODA5YjEzYTFkYTEwNGI2IE0gICAga2VybmVsCj4+
Cj4+IEhvdyB0byByZXByb2R1Y2U6IHdpdGggYSBsYXB0b3AgVDYxcCwgd2l0aCBhIENvcmUgMiBE
dW8uIEkgYm9vdCB0aGUKPj4ga2VybmVsIGluIGJ1c3lib3ggYW5kIHdhaXQgc29tZSBtaW51dGVz
IGJlZm9yZSB3cml0aW5nIHNvbWV0aGluZyBpbiB0aGUKPj4gY29uc29sZS4gQXQgdGhpcyBtb21l
bnQsIG5vdGhpbmcgYXBwZWFycyB0byB0aGUgY29uc29sZSBidXQgdGhlCj4+IGNoYXJhY3RlcnMg
YXJlIGVjaG8nZWQgc2V2ZXJhbCBzZWNvbmRzIGxhdGVyIChjb3VsZCBiZSAxLCA1LCBvciAxMCBz
ZWNzCj4+IG9yIG1vcmUpLgo+Pgo+PiBUaGF0IGhhcHBlbnMgd2hlbiBDT05GSUdfQ1BVX0lETEUg
YW5kIENPTkZJR19OT19IWiBhcmUgc2V0LiBEaXNhYmxpbmcKPj4gb25lIG9mIHRoZW0sIHRoZSBp
c3N1ZSBkb2VzIG5vdCBhcHBlYXIuCj4gCj4gVGhhbmtzIGZvciBiaXNlY3RpbmcgdGhpcyBkb3du
IGFuZCB0aGUgaGVhZHMgdXAhCj4gCj4gUmlnaHQgb2ZmIEkgY2FuJ3Qgc2VlIHdoYXQgbWlnaHQg
YmUgY2F1c2luZyB0aGlzLiAgQnVuY2ggb2YgcXVlc3Rpb25zOgo+IAo+IElzIHRoaXMgYSAzMiBv
ciA2NCBiaXQga2VybmVsPwoKSXQgaXMgYSAzMiBiaXQga2VybmVsLgoKPiBCeSB5b3VyIGRlc2Ny
aXB0aW9uIGFib3ZlLCBpdCBzb3VuZHMgbGlrZSB0aGUgc3lzdGVtIGlzIHN0aWxsCj4gZnVuY3Rp
b25pbmcsIGJ1dCB0aGVyZSdzIGp1c3QgYSBoaWdoIGxhdGVuY3kgZm9yIGtleS1pbnB1dC4gSXMg
dGhhdCByaWdodD8KClllcyB0aGF0J3MgY29ycmVjdCBidXQgbm90IG9ubHkuIER1cmluZyB0aGlz
IGZyZWV6ZSB0aW1lLCBJIGNhbid0IHBpbmcKdGhlIGhvc3QuIFdoZW4gdGhlIG91dHB1dCBpcyBl
Y2hvJ2VkLCB0aGUgcGluZyB3b3JrcyBhZ2Fpbi4KCkJ1dCBpZiBJIHBpbmcgdGhlIGhvc3QgaW5k
ZWZpbml0ZWx5LCBpdCBkb2VzIG5vdCBmcmVlemUgYW5kIHRoZSBjb25zb2xlCmlzIGVjaG8nZWQg
d2l0aG91dCBwcm9ibGVtLgoKPiBBcmUgb3RoZXIgdGhpbmdzIG9uIHRoZSBzeXN0ZW0gaGFwcGVu
aW5nIHNsb3dseT8KCkkgaGF2ZSBhIHZlcnkgbWluaW1hbCBzeXN0ZW0gYnV0IGF0IHRoZSBmaXJz
dCBnbGFuY2Ugd2hlbiBpdCBpcyBub3QgZnJvemVuCgo+IERvZXMgZ2VuZXJhdGluZyBpbnRlcnJ1
cHRzIGJ5IGhpdHRpbmcvaG9sZGluZyBkb3duIHRoZSBjdHJsIGtleSBtYWtlIHRoZQo+IHN5c3Rl
bSByZXNwb25kIGZhc3Rlcj8KCm5vLgoKPiBJcyB0aGVyZSBhbnkgZG1lc2cgb3V0cHV0IG5lYXIg
d2hlbiBpdCBvY2N1cnM/Cgpuby4KCj4gSWYgeW91IGRvbid0IHdhaXQgdGhhdCBtaW51dGUgYWZ0
ZXIgYm9vdCBiZWZvcmUgdHlwaW5nIGFueXRoaW5nLCBkb2VzIGl0Cj4gc3RpbGwgdHJpZ2dlciBs
YXRlcj8gKG9yIGlzIGl0IHRpZWQgdG8gZWFybHkgYm9vdD8pCgpUaGF0IGRlcGVuZHMsIHRoYXQg
Y291bGQgaGFwcGVuIGltbWVkaWF0ZWx5IG9yIGxhdGVyLiBJdCBpcyBtb3JlIG9yIGxlc3MKcmFu
ZG9tLgoKPiBPbiBhIHdoaW0sIGRvZXMgdGhlIHBhdGNoIGJlbG93IGF2b2lkIHRoZSBwcm9ibGVt
PwoKTm9wZSwgc2FtZSBpc3N1ZSA6LwoKVGhhbmtzCiAgLS0gRGFuaWVsCgo+IAo+IHRoYW5rcwo+
IC1qb2huCj4gCj4gZGlmZiAtLWdpdCBhL2tlcm5lbC90aW1lL3RpbWVrZWVwaW5nLmMgYi9rZXJu
ZWwvdGltZS90aW1la2VlcGluZy5jCj4gaW5kZXggMzRlNWVhYy4uMmZhMGU1MiAxMDA2NDQKPiAt
LS0gYS9rZXJuZWwvdGltZS90aW1la2VlcGluZy5jCj4gKysrIGIva2VybmVsL3RpbWUvdGltZWtl
ZXBpbmcuYwo+IEBAIC0xMTc5LDYgKzExNzksNyBAQCBzdGF0aWMgdm9pZCB1cGRhdGVfd2FsbF90
aW1lKHZvaWQpCj4gICAgICB0aW1la2VlcGluZ19hZGp1c3QodGssIG9mZnNldCk7Cj4gIAo+ICAK
PiArI2lmIDAKPiAgICAgIC8qCj4gICAgICAqIFN0b3JlIG9ubHkgZnVsbCBuYW5vc2Vjb25kcyBp
bnRvIHh0aW1lX25zZWMgYWZ0ZXIgcm91bmRpbmcKPiAgICAgICogaXQgdXAgYW5kIGFkZCB0aGUg
cmVtYWluZGVyIHRvIHRoZSBlcnJvciBkaWZmZXJlbmNlLgo+IEBAIC0xMTkyLDYgKzExOTMsNyBA
QCBzdGF0aWMgdm9pZCB1cGRhdGVfd2FsbF90aW1lKHZvaWQpCj4gICAgICB0ay0+eHRpbWVfbnNl
YyAtPSByZW1haW5kZXI7Cj4gICAgICB0ay0+eHRpbWVfbnNlYyArPSAxVUxMIDw8IHRrLT5zaGlm
dDsKPiAgICAgIHRrLT5udHBfZXJyb3IgKz0gcmVtYWluZGVyIDw8IHRrLT5udHBfZXJyb3Jfc2hp
ZnQ7Cj4gKyNlbmRpZgo+ICAKPiAgICAgIC8qCj4gICAgICAgKiBGaW5hbGx5LCBtYWtlIHN1cmUg
dGhhdCBhZnRlciB0aGUgcm91bmRpbmcKPiAKCgotLSAKIDxodHRwOi8vd3d3LmxpbmFyby5vcmcv
PiBMaW5hcm8ub3JnIOKUgiBPcGVuIHNvdXJjZSBzb2Z0d2FyZSBmb3IgQVJNIFNvQ3MKCkZvbGxv
dyBMaW5hcm86ICA8aHR0cDovL3d3dy5mYWNlYm9vay5jb20vcGFnZXMvTGluYXJvPiBGYWNlYm9v
ayB8CjxodHRwOi8vdHdpdHRlci5jb20vIyEvbGluYXJvb3JnPiBUd2l0dGVyIHwKPGh0dHA6Ly93
d3cubGluYXJvLm9yZy9saW5hcm8tYmxvZy8+IEJsb2cKCgpfX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fXwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZl
bEBsaXN0cy54ZW4ub3JnCmh0dHA6Ly9saXN0cy54ZW4ub3JnL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xen.org Sat Sep 08 05:40:00 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 08 Sep 2012 05:40:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TADlD-0004dN-Uc; Sat, 08 Sep 2012 05: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.Campbell@citrix.com>) id 1TADlC-0004dI-2Z
	for xen-devel@lists.xen.org; Sat, 08 Sep 2012 05:39:14 +0000
Received: from [85.158.143.99:31204] by server-3.bemta-4.messagelabs.com id
	56/FF-08232-10ADA405; Sat, 08 Sep 2012 05:39:13 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1347082752!22836383!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTIyNzM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23591 invoked from network); 8 Sep 2012 05:39:12 -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 Sep 2012 05:39:12 -0000
X-IronPort-AV: E=Sophos;i="4.80,390,1344211200"; d="scan'208";a="14421217"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Sep 2012 05:39: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.279.1; Sat, 8 Sep 2012
	06:39:11 +0100
Message-ID: <1347082751.10570.57.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Date: Sat, 8 Sep 2012 06:39:11 +0100
In-Reply-To: <504A4D85.9080705@citrix.com>
References: <emd0d6024e-114e-4969-a7b2-ef30ed5138a5@nathan>
	<504A4D85.9080705@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [Xen-users] Xen Security Advisory 17
 (CVE-2012-3515) - Qemu VT100 emulation vulnerability
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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-09-07 at 20:39 +0100, Andrew Cooper wrote:
> On 07/09/12 20:33, Nathan March wrote:
> > Hi All,
> > 
> > I'm guessing this wasn't intentional, but the patch for xsa17 does
> not contain a complete path to the tools/ioemu-qemu-xen/ path:
> 
> This is because it applies to the qemu repository, not the xen
> repository.
> 
> It just so happens that the xen repository build system will pull it
> into a subdir to build it, if you dont do so manually.

It's also the case the in the tarball releases where qemu is
"pre-cloned" to that location.

We can't easily satisfy both the repo and tarball scenarios in one patch
but this is something we could clarify in the advisory text in the
future.

Ian.

> 
> ~Andrew
> 
> > 
> > --- a/console.c
> > +++ b/console.c
> > 
> > Compared to all the other patches which provide a full path to the
> patched file:
> > 
> > --- a/xen/include/asm-x86/debugreg.h Mon Aug 06 12:28:03 2012 +0100
> > +++ b/xen/include/asm-x86/debugreg.h Wed Aug 15 12:00:21 2012 +0100
> > 
> > Little annoying since it means you have to track down which
> console.c is being patched instead of just applying from the root xen
> build dir.
> > 
> > - Nathan
> > 
> >
> > ------ Original Message ------
> > From: "Xen.org security team" <security@xen.org>
> > To:
> xen-announce@lists.xen.org;xen-devel@lists.xen.org;xen-users@lists.xen.org;oss-security@lists.openwall.com
> > Cc: "Xen.org security team" <security@xen.org>
> > Sent: 9/5/2012 4:12:47 AM
> > Subject: [Xen-users] Xen Security Advisory 17 (CVE-2012-3515) - Qemu
> VT100 emulation vulnerability
> >            Xen Security Advisory CVE-2012-3515 / XSA-17
> >                           version 2
> > 
> >               Qemu VT100 emulation vulnerability
> > 
> > UPDATES IN VERSION 2
> > ====================
> > 
> > Public release.
> > 
> > ISSUE DESCRIPTION
> > =================
> > 
> > The device model used by fully virtualised (HVM) domains, qemu, does
> > not properly handle escape VT100 sequences when emulating certain
> > devices with a virtual console backend.
> > 
> > IMPACT
> > ======
> > 
> > An attacker who has sufficient privilege to access a vulnerable
> > device
> > within a guest can overwrite portions of the device model's address
> > space. This can allow them to escalate their privileges to that of
> > the
> > device model process.
> > 
> > VULNERABLE SYSTEMS
> > ==================
> > 
> > All Xen systems running HVM guests are potentially vulnerable to
> > this
> > depending on the specific guest configuration. The default
> > configuration is vulnerable.
> > 
> > Guests using either the traditional "qemu-xen" or upstream qemu
> > device
> > models are vulnerable.
> > 
> > MITIGATION
> > ==========
> > 
> > This issue can be avoided by only running PV guests or by
> > configuring
> > HVM guests to not use the virtual console('vc') backend for any
> > device.
> > 
> > For serial devices specify in your guest configuration:
> >     serial = 'none'
> > in your guest configuration.
> > 
> > For parallel port devices the syntax is toolstack specific.
> > For xend specify in your guest configuration:
> >     parallel = 'none'
> > For xl specify in your guest configuration:
> >     xl: device_model_args = ['-parallel', 'none']
> > 
> > In both cases the default is to use the vulnerable 'vc' mode.
> > 
> > You can confirm whether or not you are vulnerable by pressing
> > Ctrl-Alt-<N> (for digit N) while connected to either the VNC or SDL
> > console. If you are able to switch to a window displaying "serial"
> > or
> > "parallel" then you are vulnerable.
> > 
> > The issue can also be mitigated by enabling the stub domain device
> > model. In this case the attacked can only potentially gain control
> > of
> > the stub domain and not of the entire system.
> > 
> > To enable stub domains specify in your guest configuration:
> >    device_model = "stubdom-dm"
> > 
> > RESOLUTION
> > ==========
> > 
> > Applying the appropriate attached patch(es) will resolve the issue.
> > 
> > PATCH INFORMATION
> > =================
> > 
> > The attached patches resolve this issue
> > 
> > Traditional qemu tree
> >   Xen 4.0, 4.1 and unstable
> > xsa17-qemu-xen-traditional-all.patch
> > 
> > Upstream qemu tree (present in unstable only)
> >   Xen unstable                      xsa17-qemu-xen-unstable.patch
> > 
> > $ sha256sum xsa17-*.patch
> > 60215322d3fbbc2054dfc160a20d9e0811af88487c4edc2f6ea81dcd5cedf039
> > xsa17-qemu-xen-traditional-all.patch
> > 7b4bb59e7757080e7806a8b8eeb6b78fa0ffdfbfb28a7a379f7edff285bffd88
> > xsa17-qemu-xen-unstable.patch
> 
> -- 
> 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 Sat Sep 08 05:40:00 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 08 Sep 2012 05:40:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TADlD-0004dN-Uc; Sat, 08 Sep 2012 05: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.Campbell@citrix.com>) id 1TADlC-0004dI-2Z
	for xen-devel@lists.xen.org; Sat, 08 Sep 2012 05:39:14 +0000
Received: from [85.158.143.99:31204] by server-3.bemta-4.messagelabs.com id
	56/FF-08232-10ADA405; Sat, 08 Sep 2012 05:39:13 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1347082752!22836383!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTIyNzM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23591 invoked from network); 8 Sep 2012 05:39:12 -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 Sep 2012 05:39:12 -0000
X-IronPort-AV: E=Sophos;i="4.80,390,1344211200"; d="scan'208";a="14421217"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Sep 2012 05:39: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.279.1; Sat, 8 Sep 2012
	06:39:11 +0100
Message-ID: <1347082751.10570.57.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Date: Sat, 8 Sep 2012 06:39:11 +0100
In-Reply-To: <504A4D85.9080705@citrix.com>
References: <emd0d6024e-114e-4969-a7b2-ef30ed5138a5@nathan>
	<504A4D85.9080705@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [Xen-users] Xen Security Advisory 17
 (CVE-2012-3515) - Qemu VT100 emulation vulnerability
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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-09-07 at 20:39 +0100, Andrew Cooper wrote:
> On 07/09/12 20:33, Nathan March wrote:
> > Hi All,
> > 
> > I'm guessing this wasn't intentional, but the patch for xsa17 does
> not contain a complete path to the tools/ioemu-qemu-xen/ path:
> 
> This is because it applies to the qemu repository, not the xen
> repository.
> 
> It just so happens that the xen repository build system will pull it
> into a subdir to build it, if you dont do so manually.

It's also the case the in the tarball releases where qemu is
"pre-cloned" to that location.

We can't easily satisfy both the repo and tarball scenarios in one patch
but this is something we could clarify in the advisory text in the
future.

Ian.

> 
> ~Andrew
> 
> > 
> > --- a/console.c
> > +++ b/console.c
> > 
> > Compared to all the other patches which provide a full path to the
> patched file:
> > 
> > --- a/xen/include/asm-x86/debugreg.h Mon Aug 06 12:28:03 2012 +0100
> > +++ b/xen/include/asm-x86/debugreg.h Wed Aug 15 12:00:21 2012 +0100
> > 
> > Little annoying since it means you have to track down which
> console.c is being patched instead of just applying from the root xen
> build dir.
> > 
> > - Nathan
> > 
> >
> > ------ Original Message ------
> > From: "Xen.org security team" <security@xen.org>
> > To:
> xen-announce@lists.xen.org;xen-devel@lists.xen.org;xen-users@lists.xen.org;oss-security@lists.openwall.com
> > Cc: "Xen.org security team" <security@xen.org>
> > Sent: 9/5/2012 4:12:47 AM
> > Subject: [Xen-users] Xen Security Advisory 17 (CVE-2012-3515) - Qemu
> VT100 emulation vulnerability
> >            Xen Security Advisory CVE-2012-3515 / XSA-17
> >                           version 2
> > 
> >               Qemu VT100 emulation vulnerability
> > 
> > UPDATES IN VERSION 2
> > ====================
> > 
> > Public release.
> > 
> > ISSUE DESCRIPTION
> > =================
> > 
> > The device model used by fully virtualised (HVM) domains, qemu, does
> > not properly handle escape VT100 sequences when emulating certain
> > devices with a virtual console backend.
> > 
> > IMPACT
> > ======
> > 
> > An attacker who has sufficient privilege to access a vulnerable
> > device
> > within a guest can overwrite portions of the device model's address
> > space. This can allow them to escalate their privileges to that of
> > the
> > device model process.
> > 
> > VULNERABLE SYSTEMS
> > ==================
> > 
> > All Xen systems running HVM guests are potentially vulnerable to
> > this
> > depending on the specific guest configuration. The default
> > configuration is vulnerable.
> > 
> > Guests using either the traditional "qemu-xen" or upstream qemu
> > device
> > models are vulnerable.
> > 
> > MITIGATION
> > ==========
> > 
> > This issue can be avoided by only running PV guests or by
> > configuring
> > HVM guests to not use the virtual console('vc') backend for any
> > device.
> > 
> > For serial devices specify in your guest configuration:
> >     serial = 'none'
> > in your guest configuration.
> > 
> > For parallel port devices the syntax is toolstack specific.
> > For xend specify in your guest configuration:
> >     parallel = 'none'
> > For xl specify in your guest configuration:
> >     xl: device_model_args = ['-parallel', 'none']
> > 
> > In both cases the default is to use the vulnerable 'vc' mode.
> > 
> > You can confirm whether or not you are vulnerable by pressing
> > Ctrl-Alt-<N> (for digit N) while connected to either the VNC or SDL
> > console. If you are able to switch to a window displaying "serial"
> > or
> > "parallel" then you are vulnerable.
> > 
> > The issue can also be mitigated by enabling the stub domain device
> > model. In this case the attacked can only potentially gain control
> > of
> > the stub domain and not of the entire system.
> > 
> > To enable stub domains specify in your guest configuration:
> >    device_model = "stubdom-dm"
> > 
> > RESOLUTION
> > ==========
> > 
> > Applying the appropriate attached patch(es) will resolve the issue.
> > 
> > PATCH INFORMATION
> > =================
> > 
> > The attached patches resolve this issue
> > 
> > Traditional qemu tree
> >   Xen 4.0, 4.1 and unstable
> > xsa17-qemu-xen-traditional-all.patch
> > 
> > Upstream qemu tree (present in unstable only)
> >   Xen unstable                      xsa17-qemu-xen-unstable.patch
> > 
> > $ sha256sum xsa17-*.patch
> > 60215322d3fbbc2054dfc160a20d9e0811af88487c4edc2f6ea81dcd5cedf039
> > xsa17-qemu-xen-traditional-all.patch
> > 7b4bb59e7757080e7806a8b8eeb6b78fa0ffdfbfb28a7a379f7edff285bffd88
> > xsa17-qemu-xen-unstable.patch
> 
> -- 
> 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 Sat Sep 08 05:44:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 08 Sep 2012 05:44:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TADoZ-0004j2-Iz; Sat, 08 Sep 2012 05:42:43 +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 1TADoY-0004iq-FG
	for xen-devel@lists.xen.org; Sat, 08 Sep 2012 05:42:42 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1347082956!6717982!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTIyNzM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30568 invoked from network); 8 Sep 2012 05:42:36 -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;
	8 Sep 2012 05:42:36 -0000
X-IronPort-AV: E=Sophos;i="4.80,390,1344211200"; d="scan'208";a="14421230"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Sep 2012 05:42:36 +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.279.1; Sat, 8 Sep 2012
	06:42:35 +0100
Message-ID: <1347082955.10570.59.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Matt Wilson <msw@amazon.com>
Date: Sat, 8 Sep 2012 06:42:35 +0100
In-Reply-To: <20120907202810.GB4288@u002268147cd4502c336d.ant.amazon.com>
References: <patchbomb.1346992557@u002268147cd4502c336d.ant.amazon.com>
	<1347007906.30018.43.camel@zakaz.uk.xensource.com>
	<20120907202810.GB4288@u002268147cd4502c336d.ant.amazon.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-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 0 of 2 v3] improve checking for
 documentation tools and formatting
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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-09-07 at 21:28 +0100, Matt Wilson wrote:
> On Fri, Sep 07, 2012 at 09:51:46AM +0100, Ian Campbell wrote:
> > On Fri, 2012-09-07 at 05:35 +0100, Matt Wilson wrote:
> > > This version addresses feedback from v2. Please let me know if there
> > > are any other concerns.
> > 
> > In general I think I'm happy to take docs updates right up to the
> > release, but in this case since it also involves changes to autoconf and
> > the build system I think is now 4.3 material.
> 
> Well, I provided a patch that produced formatted text from markdown
> that didn't change autoconf and the build system all that much, but
> IanJ asked:
> > Firstly, why lynx and not w3m ?  Is lynx even maintained upstream
> > any more ?  Secondly, shouldn't we do the testing for the presence
> > of markdown and the html formatter in configure ?

I know this, and I think this patch is the right approach, it's just
unfortunately missed the 4.2.0 boat.

> I think that there's very little risk in these changes, even at this
> late stage for 4.2.0.

I think autoconf and build system changes are 4.3 material (and a
candidate for 4.2.1) at this point. Changing these has had unexpected
consequences numerous times.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Sep 08 05:44:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 08 Sep 2012 05:44:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TADoZ-0004j2-Iz; Sat, 08 Sep 2012 05:42:43 +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 1TADoY-0004iq-FG
	for xen-devel@lists.xen.org; Sat, 08 Sep 2012 05:42:42 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1347082956!6717982!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTIyNzM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30568 invoked from network); 8 Sep 2012 05:42:36 -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;
	8 Sep 2012 05:42:36 -0000
X-IronPort-AV: E=Sophos;i="4.80,390,1344211200"; d="scan'208";a="14421230"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Sep 2012 05:42:36 +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.279.1; Sat, 8 Sep 2012
	06:42:35 +0100
Message-ID: <1347082955.10570.59.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Matt Wilson <msw@amazon.com>
Date: Sat, 8 Sep 2012 06:42:35 +0100
In-Reply-To: <20120907202810.GB4288@u002268147cd4502c336d.ant.amazon.com>
References: <patchbomb.1346992557@u002268147cd4502c336d.ant.amazon.com>
	<1347007906.30018.43.camel@zakaz.uk.xensource.com>
	<20120907202810.GB4288@u002268147cd4502c336d.ant.amazon.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-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 0 of 2 v3] improve checking for
 documentation tools and formatting
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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-09-07 at 21:28 +0100, Matt Wilson wrote:
> On Fri, Sep 07, 2012 at 09:51:46AM +0100, Ian Campbell wrote:
> > On Fri, 2012-09-07 at 05:35 +0100, Matt Wilson wrote:
> > > This version addresses feedback from v2. Please let me know if there
> > > are any other concerns.
> > 
> > In general I think I'm happy to take docs updates right up to the
> > release, but in this case since it also involves changes to autoconf and
> > the build system I think is now 4.3 material.
> 
> Well, I provided a patch that produced formatted text from markdown
> that didn't change autoconf and the build system all that much, but
> IanJ asked:
> > Firstly, why lynx and not w3m ?  Is lynx even maintained upstream
> > any more ?  Secondly, shouldn't we do the testing for the presence
> > of markdown and the html formatter in configure ?

I know this, and I think this patch is the right approach, it's just
unfortunately missed the 4.2.0 boat.

> I think that there's very little risk in these changes, even at this
> late stage for 4.2.0.

I think autoconf and build system changes are 4.3 material (and a
candidate for 4.2.1) at this point. Changing these has had unexpected
consequences numerous times.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Sep 08 05:45:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 08 Sep 2012 05:45:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TADqW-0004pd-3h; Sat, 08 Sep 2012 05: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.Campbell@citrix.com>) id 1TADqU-0004pV-Am
	for xen-devel@lists.xen.org; Sat, 08 Sep 2012 05:44:42 +0000
Received: from [85.158.139.83:54673] by server-12.bemta-5.messagelabs.com id
	79/FA-18300-94BDA405; Sat, 08 Sep 2012 05:44:41 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1347083080!29120966!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTIyNzM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16182 invoked from network); 8 Sep 2012 05:44: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;
	8 Sep 2012 05:44:41 -0000
X-IronPort-AV: E=Sophos;i="4.80,390,1344211200"; d="scan'208";a="14421244"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Sep 2012 05:44: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.279.1; Sat, 8 Sep 2012
	06:44:40 +0100
Message-ID: <1347083080.10570.61.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Olaf Hering <olaf@aepfle.de>
Date: Sat, 8 Sep 2012 06:44:40 +0100
In-Reply-To: <20120907161440.GA30695@aepfle.de>
References: <b088e473c7fb1a47b957.1346142770@probook.site>
	<1347033936.30018.134.camel@zakaz.uk.xensource.com>
	<20120907161440.GA30695@aepfle.de>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] xenpaging: use poll timeout if no paging
 target 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-09-07 at 17:14 +0100, Olaf Hering wrote:
> On Fri, Sep 07, Ian Campbell wrote:
> 
> > > +    /* Use a poll timeout until xenpaging got a target from xenstore */
> > > +    paging->use_poll_timeout = 1;
> > 
> > Don't you want a negative (== infinite) timeout in this case?
> 
> Maybe, but this change is the simplest fix for the isse.
> Waiting forever may have bad side effects, this is something to consider
> for 4.3.

We are in the 4.3 development window now, and this patch didn't say
anything about being for 4.2.

I think this fix (or the larger one) are 4.2.1 material at this point.

Ian


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Sep 08 05:45:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 08 Sep 2012 05:45:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TADqW-0004pd-3h; Sat, 08 Sep 2012 05: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.Campbell@citrix.com>) id 1TADqU-0004pV-Am
	for xen-devel@lists.xen.org; Sat, 08 Sep 2012 05:44:42 +0000
Received: from [85.158.139.83:54673] by server-12.bemta-5.messagelabs.com id
	79/FA-18300-94BDA405; Sat, 08 Sep 2012 05:44:41 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1347083080!29120966!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTIyNzM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16182 invoked from network); 8 Sep 2012 05:44: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;
	8 Sep 2012 05:44:41 -0000
X-IronPort-AV: E=Sophos;i="4.80,390,1344211200"; d="scan'208";a="14421244"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Sep 2012 05:44: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.279.1; Sat, 8 Sep 2012
	06:44:40 +0100
Message-ID: <1347083080.10570.61.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Olaf Hering <olaf@aepfle.de>
Date: Sat, 8 Sep 2012 06:44:40 +0100
In-Reply-To: <20120907161440.GA30695@aepfle.de>
References: <b088e473c7fb1a47b957.1346142770@probook.site>
	<1347033936.30018.134.camel@zakaz.uk.xensource.com>
	<20120907161440.GA30695@aepfle.de>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] xenpaging: use poll timeout if no paging
 target 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-09-07 at 17:14 +0100, Olaf Hering wrote:
> On Fri, Sep 07, Ian Campbell wrote:
> 
> > > +    /* Use a poll timeout until xenpaging got a target from xenstore */
> > > +    paging->use_poll_timeout = 1;
> > 
> > Don't you want a negative (== infinite) timeout in this case?
> 
> Maybe, but this change is the simplest fix for the isse.
> Waiting forever may have bad side effects, this is something to consider
> for 4.3.

We are in the 4.3 development window now, and this patch didn't say
anything about being for 4.2.

I think this fix (or the larger one) are 4.2.1 material at this point.

Ian


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Sep 08 09:02:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 08 Sep 2012 09:02:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TAGv7-0007JY-Gm; Sat, 08 Sep 2012 09:01:41 +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 1TAGv6-0007JT-6t
	for xen-devel@lists.xen.org; Sat, 08 Sep 2012 09:01:40 +0000
Received: from [85.158.143.99:53578] by server-2.bemta-4.messagelabs.com id
	36/5F-21239-3790B405; Sat, 08 Sep 2012 09:01:39 +0000
X-Env-Sender: msw@amazon.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1347094897!23967223!1
X-Originating-IP: [207.171.178.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA3LjE3MS4xNzguMjUgPT4gNjY3NzI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3612 invoked from network); 8 Sep 2012 09:01:38 -0000
Received: from smtp-fw-31001.amazon.com (HELO smtp-fw-31001.amazon.com)
	(207.171.178.25)
	by server-4.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Sep 2012 09:01:38 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=amazon.com; i=msw@amazon.com; q=dns/txt; s=rte02;
	t=1347094898; x=1378630898;
	h=mime-version:content-transfer-encoding:subject:
	message-id:date:from:to:cc;
	bh=uBc3csOg4P+Rfs4N2YrUg5e9sfhrfuKOkq8tFScgovQ=;
	b=DoYy/IPeP6VQXuy6aS2DRwKAWFsG7GLuDpLUXJMhccQL2Ygrr4vOktf0
	C/Z4ID8s0BzIp0NLLUHI4m+Jq+kZ2Q==;
X-IronPort-AV: E=Sophos;i="4.80,391,1344211200"; d="scan'208";a="291545098"
Received: from smtp-in-9003.sea19.amazon.com ([10.186.104.20])
	by smtp-border-fw-out-31001.sea31.amazon.com with
	ESMTP/TLS/DHE-RSA-AES256-SHA; 08 Sep 2012 09:01:35 +0000
Received: from ex10-hub-31006.ant.amazon.com (ex10-hub-31006.sea31.amazon.com
	[10.185.176.13])
	by smtp-in-9003.sea19.amazon.com (8.13.8/8.13.8) with ESMTP id
	q8891Z8c005236
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL);
	Sat, 8 Sep 2012 09:01:35 GMT
Received: from u002268147cd4502c336d.ant.amazon.com (10.224.80.42) by
	ex10-hub-31006.ant.amazon.com (10.185.176.13) with Microsoft SMTP
	Server id 14.2.247.3; Sat, 8 Sep 2012 02:01:27 -0700
MIME-Version: 1.0
Message-ID: <patchbomb.1347094753@u002268147cd4502c336d.ant.amazon.com>
User-Agent: Mercurial-patchbomb/2.3.1
Date: Sat, 8 Sep 2012 01:59:13 -0700
From: Matt Wilson <msw@amazon.com>
To: Ian Campbell <Ian.Campbell@citrix.com>, Ian Jackson
	<Ian.Jackson@eu.citrix.com>
Cc: xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH 0 of 2] improve xmdomain.cfg and xl.cfg
	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

Here are two patches to the man pages. Please apply for 4.2.0.

Matt

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Sep 08 09:02:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 08 Sep 2012 09:02:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TAGv7-0007JY-Gm; Sat, 08 Sep 2012 09:01:41 +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 1TAGv6-0007JT-6t
	for xen-devel@lists.xen.org; Sat, 08 Sep 2012 09:01:40 +0000
Received: from [85.158.143.99:53578] by server-2.bemta-4.messagelabs.com id
	36/5F-21239-3790B405; Sat, 08 Sep 2012 09:01:39 +0000
X-Env-Sender: msw@amazon.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1347094897!23967223!1
X-Originating-IP: [207.171.178.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA3LjE3MS4xNzguMjUgPT4gNjY3NzI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3612 invoked from network); 8 Sep 2012 09:01:38 -0000
Received: from smtp-fw-31001.amazon.com (HELO smtp-fw-31001.amazon.com)
	(207.171.178.25)
	by server-4.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Sep 2012 09:01:38 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=amazon.com; i=msw@amazon.com; q=dns/txt; s=rte02;
	t=1347094898; x=1378630898;
	h=mime-version:content-transfer-encoding:subject:
	message-id:date:from:to:cc;
	bh=uBc3csOg4P+Rfs4N2YrUg5e9sfhrfuKOkq8tFScgovQ=;
	b=DoYy/IPeP6VQXuy6aS2DRwKAWFsG7GLuDpLUXJMhccQL2Ygrr4vOktf0
	C/Z4ID8s0BzIp0NLLUHI4m+Jq+kZ2Q==;
X-IronPort-AV: E=Sophos;i="4.80,391,1344211200"; d="scan'208";a="291545098"
Received: from smtp-in-9003.sea19.amazon.com ([10.186.104.20])
	by smtp-border-fw-out-31001.sea31.amazon.com with
	ESMTP/TLS/DHE-RSA-AES256-SHA; 08 Sep 2012 09:01:35 +0000
Received: from ex10-hub-31006.ant.amazon.com (ex10-hub-31006.sea31.amazon.com
	[10.185.176.13])
	by smtp-in-9003.sea19.amazon.com (8.13.8/8.13.8) with ESMTP id
	q8891Z8c005236
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL);
	Sat, 8 Sep 2012 09:01:35 GMT
Received: from u002268147cd4502c336d.ant.amazon.com (10.224.80.42) by
	ex10-hub-31006.ant.amazon.com (10.185.176.13) with Microsoft SMTP
	Server id 14.2.247.3; Sat, 8 Sep 2012 02:01:27 -0700
MIME-Version: 1.0
Message-ID: <patchbomb.1347094753@u002268147cd4502c336d.ant.amazon.com>
User-Agent: Mercurial-patchbomb/2.3.1
Date: Sat, 8 Sep 2012 01:59:13 -0700
From: Matt Wilson <msw@amazon.com>
To: Ian Campbell <Ian.Campbell@citrix.com>, Ian Jackson
	<Ian.Jackson@eu.citrix.com>
Cc: xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH 0 of 2] improve xmdomain.cfg and xl.cfg
	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

Here are two patches to the man pages. Please apply for 4.2.0.

Matt

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Sep 08 09:02:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 08 Sep 2012 09:02:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TAGvB-0007Jn-TX; Sat, 08 Sep 2012 09:01:45 +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 1TAGvA-0007Jf-26
	for xen-devel@lists.xen.org; Sat, 08 Sep 2012 09:01:44 +0000
Received: from [85.158.139.83:44908] by server-4.bemta-5.messagelabs.com id
	88/BB-23042-7790B405; Sat, 08 Sep 2012 09:01:43 +0000
X-Env-Sender: msw@amazon.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1347094901!29061359!1
X-Originating-IP: [72.21.196.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNzIuMjEuMTk2LjI1ID0+IDEyNDAxOQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2582 invoked from network); 8 Sep 2012 09:01:42 -0000
Received: from smtp-fw-2101.amazon.com (HELO smtp-fw-2101.amazon.com)
	(72.21.196.25)
	by server-5.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Sep 2012 09:01:42 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=amazon.com; i=msw@amazon.com; q=dns/txt; s=rte02;
	t=1347094902; x=1378630902;
	h=mime-version:content-transfer-encoding:subject:
	message-id:in-reply-to:references:date:from:to:cc;
	bh=WTcYZ3DpmHLo2UHRFo8DiFW5HS32MceFXWIiA5fjv04=;
	b=Msrz70l1rJ38rPKLLYxhCUhSgLBCpn0x8WnH9eSfKsFiKsx2NENWnxM0
	2VQ0itdUsU3x/FufXKiz4slK5km+mw==;
X-IronPort-AV: E=Sophos;i="4.80,391,1344211200"; d="scan'208";a="436733658"
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; 08 Sep 2012 09:01:40 +0000
Received: from ex10-hub-31006.ant.amazon.com (ex10-hub-31006.sea31.amazon.com
	[10.185.176.13])
	by smtp-in-9003.sea19.amazon.com (8.13.8/8.13.8) with ESMTP id
	q8891dX8005626
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL);
	Sat, 8 Sep 2012 09:01:39 GMT
Received: from u002268147cd4502c336d.ant.amazon.com (10.224.80.42) by
	ex10-hub-31006.ant.amazon.com (10.185.176.13) with Microsoft SMTP
	Server id 14.2.247.3; Sat, 8 Sep 2012 02:01:36 -0700
MIME-Version: 1.0
X-Mercurial-Node: 8218753a8e3f9285dc68a951976610c828d2cded
Message-ID: <8218753a8e3f9285dc68.1347094754@u002268147cd4502c336d.ant.amazon.com>
In-Reply-To: <patchbomb.1347094753@u002268147cd4502c336d.ant.amazon.com>
References: <patchbomb.1347094753@u002268147cd4502c336d.ant.amazon.com>
User-Agent: Mercurial-patchbomb/2.3.1
Date: Sat, 8 Sep 2012 01:59:14 -0700
From: Matt Wilson <msw@amazon.com>
To: Ian Campbell <Ian.Campbell@citrix.com>, Ian Jackson
	<Ian.Jackson@eu.citrix.com>
Cc: xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH 1 of 2] docs: correct formatting errors in
	xmdomain.cfg
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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 corrects the following errors produced by pod2man:

Hey! The above document had some coding errors, which are explained
below:

Around line 301:
    You can't have =items (as at line 305) unless the first thing after
    the =over is an =item

Around line 311:
    '=item' outside of any '=over'

Signed-off-by: Matt Wilson <msw@amazon.com>

diff -r 6a1ee7eacd9c -r 8218753a8e3f docs/man/xmdomain.cfg.pod.5
--- a/docs/man/xmdomain.cfg.pod.5	Thu Sep 06 21:33:05 2012 -0700
+++ b/docs/man/xmdomain.cfg.pod.5	Sat Sep 08 01:43:36 2012 -0700
@@ -298,16 +298,14 @@
 
 =back
 
+Additionally, the "on_crash" event can also take:
+
 =over 4
 
-Additionally, the "on_crash" event can also take:
-
 =item B<coredump-destroy>
 
 Dump the crashed domain's core and then destroy it.
 
-=back
-
 =item B<coredump-restart>
 
 Dump the crashed domain's core and then restart it.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Sep 08 09:02:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 08 Sep 2012 09:02:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TAGvB-0007Jn-TX; Sat, 08 Sep 2012 09:01:45 +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 1TAGvA-0007Jf-26
	for xen-devel@lists.xen.org; Sat, 08 Sep 2012 09:01:44 +0000
Received: from [85.158.139.83:44908] by server-4.bemta-5.messagelabs.com id
	88/BB-23042-7790B405; Sat, 08 Sep 2012 09:01:43 +0000
X-Env-Sender: msw@amazon.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1347094901!29061359!1
X-Originating-IP: [72.21.196.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNzIuMjEuMTk2LjI1ID0+IDEyNDAxOQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2582 invoked from network); 8 Sep 2012 09:01:42 -0000
Received: from smtp-fw-2101.amazon.com (HELO smtp-fw-2101.amazon.com)
	(72.21.196.25)
	by server-5.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Sep 2012 09:01:42 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=amazon.com; i=msw@amazon.com; q=dns/txt; s=rte02;
	t=1347094902; x=1378630902;
	h=mime-version:content-transfer-encoding:subject:
	message-id:in-reply-to:references:date:from:to:cc;
	bh=WTcYZ3DpmHLo2UHRFo8DiFW5HS32MceFXWIiA5fjv04=;
	b=Msrz70l1rJ38rPKLLYxhCUhSgLBCpn0x8WnH9eSfKsFiKsx2NENWnxM0
	2VQ0itdUsU3x/FufXKiz4slK5km+mw==;
X-IronPort-AV: E=Sophos;i="4.80,391,1344211200"; d="scan'208";a="436733658"
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; 08 Sep 2012 09:01:40 +0000
Received: from ex10-hub-31006.ant.amazon.com (ex10-hub-31006.sea31.amazon.com
	[10.185.176.13])
	by smtp-in-9003.sea19.amazon.com (8.13.8/8.13.8) with ESMTP id
	q8891dX8005626
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL);
	Sat, 8 Sep 2012 09:01:39 GMT
Received: from u002268147cd4502c336d.ant.amazon.com (10.224.80.42) by
	ex10-hub-31006.ant.amazon.com (10.185.176.13) with Microsoft SMTP
	Server id 14.2.247.3; Sat, 8 Sep 2012 02:01:36 -0700
MIME-Version: 1.0
X-Mercurial-Node: 8218753a8e3f9285dc68a951976610c828d2cded
Message-ID: <8218753a8e3f9285dc68.1347094754@u002268147cd4502c336d.ant.amazon.com>
In-Reply-To: <patchbomb.1347094753@u002268147cd4502c336d.ant.amazon.com>
References: <patchbomb.1347094753@u002268147cd4502c336d.ant.amazon.com>
User-Agent: Mercurial-patchbomb/2.3.1
Date: Sat, 8 Sep 2012 01:59:14 -0700
From: Matt Wilson <msw@amazon.com>
To: Ian Campbell <Ian.Campbell@citrix.com>, Ian Jackson
	<Ian.Jackson@eu.citrix.com>
Cc: xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH 1 of 2] docs: correct formatting errors in
	xmdomain.cfg
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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 corrects the following errors produced by pod2man:

Hey! The above document had some coding errors, which are explained
below:

Around line 301:
    You can't have =items (as at line 305) unless the first thing after
    the =over is an =item

Around line 311:
    '=item' outside of any '=over'

Signed-off-by: Matt Wilson <msw@amazon.com>

diff -r 6a1ee7eacd9c -r 8218753a8e3f docs/man/xmdomain.cfg.pod.5
--- a/docs/man/xmdomain.cfg.pod.5	Thu Sep 06 21:33:05 2012 -0700
+++ b/docs/man/xmdomain.cfg.pod.5	Sat Sep 08 01:43:36 2012 -0700
@@ -298,16 +298,14 @@
 
 =back
 
+Additionally, the "on_crash" event can also take:
+
 =over 4
 
-Additionally, the "on_crash" event can also take:
-
 =item B<coredump-destroy>
 
 Dump the crashed domain's core and then destroy it.
 
-=back
-
 =item B<coredump-restart>
 
 Dump the crashed domain's core and then restart it.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Sep 08 09:02:18 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 08 Sep 2012 09:02:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TAGvJ-0007L6-EQ; Sat, 08 Sep 2012 09:01:53 +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 1TAGvI-0007Kk-41
	for xen-devel@lists.xen.org; Sat, 08 Sep 2012 09:01:52 +0000
Received: from [85.158.143.99:20054] by server-3.bemta-4.messagelabs.com id
	41/3B-08232-F790B405; Sat, 08 Sep 2012 09:01:51 +0000
X-Env-Sender: msw@amazon.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1347094908!22852813!1
X-Originating-IP: [207.171.184.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA3LjE3MS4xODQuMjUgPT4gMzE2MzQ4\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29118 invoked from network); 8 Sep 2012 09:01:49 -0000
Received: from smtp-fw-9101.amazon.com (HELO smtp-fw-9101.amazon.com)
	(207.171.184.25)
	by server-10.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Sep 2012 09:01: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=1347094909; x=1378630909;
	h=mime-version:content-transfer-encoding:subject:
	message-id:in-reply-to:references:date:from:to:cc;
	bh=kvAJoLrVzgH+LKMnTHmywFWxu3GYs1GXcQFMuEWfXcc=;
	b=fj+IiX7LxujDzyE3hOB/eIuubVq1Q2EByVEOrUwFRNLxRUa7akpi+eSo
	qCfpgLb40JhKfEGDHb39Fzjs/jF+hw==;
X-IronPort-AV: E=Sophos;i="4.80,391,1344211200"; d="scan'208";a="1023338304"
Received: from smtp-in-1104.vdc.amazon.com ([10.140.10.25])
	by smtp-border-fw-out-9101.sea19.amazon.com with
	ESMTP/TLS/DHE-RSA-AES256-SHA; 08 Sep 2012 09:01:46 +0000
Received: from ex10-hub-31006.ant.amazon.com (ex10-hub-31006.sea31.amazon.com
	[10.185.176.13])
	by smtp-in-1104.vdc.amazon.com (8.13.8/8.13.8) with ESMTP id
	q8891ie4027414
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL);
	Sat, 8 Sep 2012 09:01:45 GMT
Received: from u002268147cd4502c336d.ant.amazon.com (10.224.80.42) by
	ex10-hub-31006.ant.amazon.com (10.185.176.13) with Microsoft SMTP
	Server id 14.2.247.3; Sat, 8 Sep 2012 02:01:39 -0700
MIME-Version: 1.0
X-Mercurial-Node: 9c9981ddbfd5c0ccaea77003a6aeeb2a0d309600
Message-ID: <9c9981ddbfd5c0ccaea7.1347094755@u002268147cd4502c336d.ant.amazon.com>
In-Reply-To: <patchbomb.1347094753@u002268147cd4502c336d.ant.amazon.com>
References: <patchbomb.1347094753@u002268147cd4502c336d.ant.amazon.com>
User-Agent: Mercurial-patchbomb/2.3.1
Date: Sat, 8 Sep 2012 01:59:15 -0700
From: Matt Wilson <msw@amazon.com>
To: Ian Campbell <Ian.Campbell@citrix.com>, Ian Jackson
	<Ian.Jackson@eu.citrix.com>
Cc: xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH 2 of 2] docs: flesh out xl.cfg documentation,
 correct typos, reorganize
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Some highlights:
 * Correct some markup errors:
       Around line 663:
           '=item' outside of any '=over'
       Around line 671:
           You forgot a '=back' before '=head3'
 * Add documentation for msitranslate, power_mgnt, acpi_s3, aspi_s4,
   gfx_passthru, nomigrate, etc.
 * Reorganize items in "unclassified" sections like cpuid,
   gfx_passthru to where they belong
 * Correct link L<> references so they can be resolved within the
   document
 * Remove placeholders for deprecated options device_model and vif2
 * Remove placeholder for "sched" and "node", as these are options for
   cpupool configuration. Perhaps cpupool configuration deserves
   a section in this document.
 * Rename "global" options to "general"
 * Add section headers to group general VM options.

Signed-off-by: Matt Wilson <msw@amazon.com>

diff -r 8218753a8e3f -r 9c9981ddbfd5 docs/man/xl.cfg.pod.5
--- a/docs/man/xl.cfg.pod.5	Sat Sep 08 01:43:36 2012 -0700
+++ b/docs/man/xl.cfg.pod.5	Sat Sep 08 01:54:46 2012 -0700
@@ -17,7 +17,7 @@
 
 A domain config file consists of a series of C<KEY=VALUE> pairs.
 
-Some C<KEY>s are mandatory, others are global options which apply to
+Some C<KEY>s are mandatory, others are general options which apply to
 any guest type while others relate only to specific guest types
 (e.g. PV or HVM guests).
 
@@ -80,21 +80,14 @@
 
 =back
 
-=head2 Global Options
+=head2 General Options
 
 The following options apply to guests of any type.
 
+=head3 CPU Allocation
+
 =over 4
 
-=item B<uuid="UUID">
-
-Specifies the UUID of the domain.  If not specified, a fresh unique
-UUID will be generated.
-
-=item B<vncviewer=BOOLEAN>
-
-Automatically spawn a vncviewer when creating/restoring a guest
-
 =item B<pool="CPUPOOLNAME">
 
 Put the guest's vcpus into the named cpu pool.
@@ -138,6 +131,12 @@
 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.
 
+=back
+
+=head3 CPU Scheduling
+
+=over 4
+
 =item B<cpu_weight=WEIGHT>
 
 A domain with a weight of 512 will get twice as much CPU as a domain
@@ -176,6 +175,12 @@
 Flag for allowing domain to run in extra time.
 Honoured by the sedf scheduler.
 
+=back
+
+=head3 Memory Allocation
+
+=over 4
+
 =item B<memory=MBYTES>
 
 Start the guest with MBYTES megabytes of RAM.
@@ -190,6 +195,12 @@
 A "pre-ballooned" HVM guest needs a balloon driver, without a balloon driver
 it will crash.
 
+=back
+
+=head3 Event Actions
+
+=over 4
+
 =item B<on_poweroff="ACTION">
 
 Specifies what should be done with the domain if it shuts itself down.
@@ -200,12 +211,12 @@
 =item B<destroy>
 
 destroy the domain
-     
+
 =item B<restart>
 
 destroy the domain and immediately create a new domain with the same
 configuration
-        
+
 =item B<rename-restart>
 
 rename the domain which terminated, and then immediately create a new
@@ -244,10 +255,28 @@
 
 Action to take if the domain crashes.  Default is C<destroy>.
 
+=back
+
+=head3 Other Options
+
+=over 4
+
+=item B<uuid="UUID">
+
+Specifies the UUID of the domain.  If not specified, a fresh unique
+UUID will be generated.
+
 =item B<seclabel="LABEL">
 
 Assign an XSM security label to this domain.
 
+=item B<nomigrate=BOOLEAN>
+
+Disable migration of this domain.  This enables certain other features
+which are incompatible with migration. Currently this is limited to
+enabling the invariant TSC feature flag in cpuid results when TSC is
+not emulated.
+
 =back
 
 =head2 Devices
@@ -309,7 +338,20 @@
 =item C<sdl=BOOLEAN>
 
 Specifies that the display should be presented via an X window (using
-Simple DirectMedia Layer). The default is to not enable this mode
+Simple DirectMedia Layer). The default is to not enable this mode.
+
+=item C<display=DISPLAY>
+
+Specifies the X Window display that should be used when the sdl option
+is used. Note: passing this value to the device-model is not currently
+implemented, so providing this option will have no effect.
+
+=item C<xauthority=XAUTHORITY>
+
+Specifies the path to the X authorty file that should be used to
+connect to the X server when the sdl option is used. Note: passing
+this value to the device-model is not currently implemented, so
+providing this option will have no effect.
 
 =item C<opengl=BOOLEAN>
 
@@ -324,19 +366,9 @@
 (e.g. this is often the case when using VNC) then this allows us to
 correctly map the input keys into keycodes seen by the guest. The
 specific values which are accepted are defined by the version of the
-device-model which you are using. See L<Keymaps> below or consult the
+device-model which you are using. See L</"Keymaps"> below or consult the
 L<qemu(1)> manpage. The default is B<en-us>.
 
-=item C<display=XXX>
-
-XXX written to xenstore backend for vfb but does not appear to be used
-anywhere?
-
-=item C<authority=XXX>
-
-XXX written to xenstore backend for vfb but does not appear to be used
-anywhere?
-
 =back
 
 =item B<pci=[ "PCI_SPEC_STRING", "PCI_SPEC_STRING", ... ]>
@@ -348,7 +380,7 @@
 
 =item B<DDDD:BB:DD.F>
 
-identifies the PCI device from the host perspective in domain
+Identifies the PCI device from the host perspective in domain
 (B<DDDD>), Bus (B<BB>), Device (B<DD>) and Function (B<F>) syntax. This is
 the same scheme as used in the output of C<lspci> for the device in
 question. Note: By default C<lspci> will omit the domain (B<DDDD>) if it
@@ -357,9 +389,9 @@
 
 =item B<@VSLOT>
 
-specifies the virtual device where the guest will see this
+Specifies the virtual device where the guest will see this
 device. This is equivalent to the B<DD> which the guest sees. In a
-guest B<DDDD> and B<BB> are C<0000:00>. XXX how does this really work?
+guest B<DDDD> and B<BB> are C<0000:00>.
 
 =item B<KEY=VALUE>
 
@@ -367,14 +399,6 @@
 
 =over 4
 
-=item B<msitranslate=BOOLEAN>
-
-XXX
-
-=item B<power_mgmt=BOOLEAN>
-
-XXX
-
 =item B<permissive=BOOLEAN>
 
 (PV only) By default pciback only allows PV guests to write "known
@@ -386,6 +410,19 @@
 may have security or stability implications.  It is recommended to
 enable this option only for trusted VMs under administrator control.
 
+=item B<msitranslate=BOOLEAN>
+
+Specifies that MSI-INTx translation should be turned on for the PCI
+device. When enabled, MSI-INTx translation will always enable MSI on
+the PCI device regardless whether the guest uses INTx or MSI. Some
+device drivers, such as NVIDIA's, detect an inconsistency and do not
+function when this option is enabled. Therefore the default is 0.
+
+=item B<power_mgmt=BOOLEAN>
+
+(HVM only) Specifies that the VM should be able to program the
+D0-D3hot power management states for the PCI device. 0 by default.
+
 =back
 
 =back
@@ -393,12 +430,27 @@
 =item B<pci_permissive=BOOLEAN>
 
 (PV only) Changes the default value of 'permissive' for all PCI
-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
-for trusted VMs under administrator control.  See the "pci=" section
-for more information on the "permissive" flag.
+devices passed through to this VM. See L<permissive|/"permissive_boolean">
+above.
+
+=item B<pci_msitranslate=BOOLEAN>
+
+Changes the default value of 'msitranslate' for all PCI devices passed
+through to this VM. See L<msitranslate|/"msitranslate_boolean"> above.
+
+=item B<pci_power_mgmt=BOOLEAN>
+
+(HVM only) Changes the default value of 'power_mgmt' for all PCI
+devices passed through to this VM. See L<power_mgt|/"power_mgmt_boolean">
+above.
+
+=item B<gfx_passthru=BOOLEAN>
+
+(HVM only) Enable graphic device PCI passthrough. If a system's
+primary graphics adapter PCI device is specified in the
+L<pci|/"pci_pci_spec_string_pci_spec_string"> section above, enabling
+this option will cause the device to be used as the primary graphics
+adapter in the guest. 0 by default.
 
 =back
 
@@ -447,12 +499,12 @@
 option is specified the virtual e820 instead reflects the host e820
 and contains the same PCI holes. The total amount of RAM represented
 by the memory map is always the same, this option configures only how
-it is layed out.
+it is laid 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 Operating System dependant whether this
+PCI devices. It is guest Operating System dependent 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 configured and false otherwise. If you do not
@@ -576,6 +628,16 @@
 default and usually you should omit it. However it may be necessary to
 disable ACPI for compatibility with some guest Operating Systems.
 
+=item B<acpi_s3=BOOLEAN>
+
+Include the S3 (suspend-to-ram) power state in the virtual firmware
+ACPI table. 1 by default.
+
+=item B<acpi_s4=BOOLEAN>
+
+Include S4 (suspend-to-disk) power state in the virtual firmware ACPI
+table. 1 by default.
+
 =item B<apic=BOOLEAN>
 
 Include information regarding APIC (Advanced Programmable Interrupt
@@ -613,6 +675,54 @@
 which uses hardware virtualisation extensions (e.g. Windows XP
 compatibility mode on more modern Windows OS).
 
+=item B<cpuid="LIBXL_STRING"> or B<cpuid=[ "XEND_STRING", "XEND_STRING" ]>
+
+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>
+
 =back 
 
 =head3 Guest Virtual Time Controls
@@ -656,8 +766,6 @@
 
 =back
 
-=back
-
 Please see F<docs/misc/tscmode.txt> for more information on this option.
 
 =item B<localtime=BOOLEAN>
@@ -668,6 +776,50 @@
 
 Set the real time clock offset in seconds. 0 by default.
 
+
+=item B<vpt_align=BOOLEAN>
+
+Specifies that periodic Virtual Platform Timers should be aligned to
+reduce guest interrupts. Enabling this option can reduce power
+consumption, especially when a guest uses a high timer interrupt
+frequency (HZ) values. The default is 1.
+
+=item B<timer_mode=MODE>
+
+Specifies the mode for Virtual Timers. The valid values are as follows:
+
+=over 4
+
+=item B<"delay_for_missed_ticks">
+
+Delay for missed ticks. Do not advance a vcpu's time beyond the
+correct delivery time for interrupts that have been missed due to
+preemption. Deliver missed interrupts when the vcpu is rescheduled and
+advance the vcpu's virtual time stepwise for each one.
+
+=item B<"no_delay_for_missed_ticks">
+
+No delay for missed ticks. As above, missed interrupts are delivered,
+but guest time always tracks wallclock (i.e., real) time while doing
+so.
+
+=item B<"no_missed_ticks_pending">
+
+No missed interrupts are held pending. Instead, to ensure ticks are
+delivered at some non-zero rate, if we detect missed ticks then the
+internal tick alarm is not disabled if the VCPU is preempted during
+the next tick period.
+
+=item B<"one_missed_tick_pending">
+
+One missed tick pending. Missed interrupts are collapsed
+together and delivered as one 'late tick'.  Guest time always tracks
+wallclock (i.e., real) time.
+
+=back
+
+=back
+
 =head3 Support for Paravirtualisation of HVM Guests
 
 The following options allow Paravirtualised features (such as devices)
@@ -733,6 +885,10 @@
 Allow access to the display via the VNC protocol.  This enables the
 other VNC-related settings.  The default is to enable this.
 
+=item B<vncviewer=BOOLEAN>
+
+Automatically spawn a vncviewer when creating/restoring a guest.
+
 =item B<vnclisten="ADDRESS[:DISPLAYNUM]">
 
 Specifies the IP address, and optionally VNC display number, to use.
@@ -758,7 +914,7 @@
 (e.g. this is often the case when using VNC) then this allows us to
 correctly map the input keys into keycodes seen by the guest. The
 specific values which are accepted are defined by the version of the
-device-model which you are using. See L<Keymaps> below of consult the
+device-model which you are using. See L</"Keymaps"> below or consult the
 L<qemu(1)> manpage. The default is B<en-us>.
 
 =item B<sdl=BOOLEAN>
@@ -770,7 +926,7 @@
 
 Enable OpenGL acceleration of the SDL display. Only effects machines
 using B<device_model_version="qemu-xen-traditional"> and only if the
-device-model was compiled with OpenGL support. Disabled by default.
+device-model was compiled with OpenGL support. 0 by default.
 
 =item B<nographic=BOOLEAN>
 
@@ -854,28 +1010,7 @@
 function better than relative coordinate devices (such as a standard
 mouse) since many methods of exporting guest graphics (such as VNC)
 work better in this mode. Note that this is independent of the actual
-pointer device you are using on the host/client side. XXX should/could
-be a list of devices.
-
-=back
-
-=head3 Unclassified HVM Specific Options
-
-These HVM specific options have not yet been documented or
-classified. They almost certainly belong in a more appropriate
-section.
-
-=over 4
-
-=item B<vpt_align=BOOLEAN>
-
-Align the Virtual Platform Timer ??? XXX Reduces interrupts?
-
-=item B<timer_mode=NUMBER>
-
-Set mode for Virtual Timers XXX ??? should be an enum of particular
-values. See C<HVM_PARAM_TIMER_MODE> in
-F<xen/include/public/hvm/params.h>.
+pointer device you are using on the host/client side.
 
 =back
 
@@ -950,105 +1085,6 @@
 
 =back
 
-=head2 Unclassified General Options
-
-These have not yet been fully documented or classified. They almost
-certainly belong in a more appropriate section.
-
-=over 4
-
-=item B<gfx_passthru=BOOLEAN>
-
-Enable graphics device PCI passthrough. XXX which device is passed through ?
-
-=item B<nomigrate=BOOLEAN>
-
-Disable migration of this domain.  This enables certain other features
-which are incompatible with migration (currently certain TSC modes XXX
-?).
-
-=item B<pci_msitranslate=BOOLEAN>
-
-XXX
-
-=item B<pci_power_mgmt=BOOLEAN>
-
-XXX
-
-=item B<cpuid="LIBXL_STRING"> or B<cpuid=[ "XEND_STRING", "XEND_STRING" ]>
-
-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>
-
-XXX
-
-=item B<acpi_s3=BOOLEAN>
-
-XXX
-
-=item B<nodes=XXX>
-
-XXX
-
-=item B<sched=XXX>
-
-XXX
-
-=item B<device_model=XXX>
-
-XXX deprecated
-
-=item B<vif2=XXX>
-
-XXX deprecated
-
-=back
-
 =head2 Keymaps
 
 The keymaps available are defined by the device-model which you are
@@ -1083,9 +1119,9 @@
 =head1 BUGS
 
 This document is a work in progress and contains items which require
-further documentation and which are generally incomplete (marked with
-XXX).  However all options are included here whether or not they are
-fully documented.
+further documentation and which are generally incomplete.  However all
+supported options are included here whether or not they are fully
+documented.
 
 Patches to improve incomplete items (or any other item) would be
 gratefully received on the xen-devel@lists.xen.org mailing

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Sep 08 09:02:18 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 08 Sep 2012 09:02:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TAGvJ-0007L6-EQ; Sat, 08 Sep 2012 09:01:53 +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 1TAGvI-0007Kk-41
	for xen-devel@lists.xen.org; Sat, 08 Sep 2012 09:01:52 +0000
Received: from [85.158.143.99:20054] by server-3.bemta-4.messagelabs.com id
	41/3B-08232-F790B405; Sat, 08 Sep 2012 09:01:51 +0000
X-Env-Sender: msw@amazon.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1347094908!22852813!1
X-Originating-IP: [207.171.184.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA3LjE3MS4xODQuMjUgPT4gMzE2MzQ4\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29118 invoked from network); 8 Sep 2012 09:01:49 -0000
Received: from smtp-fw-9101.amazon.com (HELO smtp-fw-9101.amazon.com)
	(207.171.184.25)
	by server-10.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Sep 2012 09:01: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=1347094909; x=1378630909;
	h=mime-version:content-transfer-encoding:subject:
	message-id:in-reply-to:references:date:from:to:cc;
	bh=kvAJoLrVzgH+LKMnTHmywFWxu3GYs1GXcQFMuEWfXcc=;
	b=fj+IiX7LxujDzyE3hOB/eIuubVq1Q2EByVEOrUwFRNLxRUa7akpi+eSo
	qCfpgLb40JhKfEGDHb39Fzjs/jF+hw==;
X-IronPort-AV: E=Sophos;i="4.80,391,1344211200"; d="scan'208";a="1023338304"
Received: from smtp-in-1104.vdc.amazon.com ([10.140.10.25])
	by smtp-border-fw-out-9101.sea19.amazon.com with
	ESMTP/TLS/DHE-RSA-AES256-SHA; 08 Sep 2012 09:01:46 +0000
Received: from ex10-hub-31006.ant.amazon.com (ex10-hub-31006.sea31.amazon.com
	[10.185.176.13])
	by smtp-in-1104.vdc.amazon.com (8.13.8/8.13.8) with ESMTP id
	q8891ie4027414
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL);
	Sat, 8 Sep 2012 09:01:45 GMT
Received: from u002268147cd4502c336d.ant.amazon.com (10.224.80.42) by
	ex10-hub-31006.ant.amazon.com (10.185.176.13) with Microsoft SMTP
	Server id 14.2.247.3; Sat, 8 Sep 2012 02:01:39 -0700
MIME-Version: 1.0
X-Mercurial-Node: 9c9981ddbfd5c0ccaea77003a6aeeb2a0d309600
Message-ID: <9c9981ddbfd5c0ccaea7.1347094755@u002268147cd4502c336d.ant.amazon.com>
In-Reply-To: <patchbomb.1347094753@u002268147cd4502c336d.ant.amazon.com>
References: <patchbomb.1347094753@u002268147cd4502c336d.ant.amazon.com>
User-Agent: Mercurial-patchbomb/2.3.1
Date: Sat, 8 Sep 2012 01:59:15 -0700
From: Matt Wilson <msw@amazon.com>
To: Ian Campbell <Ian.Campbell@citrix.com>, Ian Jackson
	<Ian.Jackson@eu.citrix.com>
Cc: xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH 2 of 2] docs: flesh out xl.cfg documentation,
 correct typos, reorganize
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Some highlights:
 * Correct some markup errors:
       Around line 663:
           '=item' outside of any '=over'
       Around line 671:
           You forgot a '=back' before '=head3'
 * Add documentation for msitranslate, power_mgnt, acpi_s3, aspi_s4,
   gfx_passthru, nomigrate, etc.
 * Reorganize items in "unclassified" sections like cpuid,
   gfx_passthru to where they belong
 * Correct link L<> references so they can be resolved within the
   document
 * Remove placeholders for deprecated options device_model and vif2
 * Remove placeholder for "sched" and "node", as these are options for
   cpupool configuration. Perhaps cpupool configuration deserves
   a section in this document.
 * Rename "global" options to "general"
 * Add section headers to group general VM options.

Signed-off-by: Matt Wilson <msw@amazon.com>

diff -r 8218753a8e3f -r 9c9981ddbfd5 docs/man/xl.cfg.pod.5
--- a/docs/man/xl.cfg.pod.5	Sat Sep 08 01:43:36 2012 -0700
+++ b/docs/man/xl.cfg.pod.5	Sat Sep 08 01:54:46 2012 -0700
@@ -17,7 +17,7 @@
 
 A domain config file consists of a series of C<KEY=VALUE> pairs.
 
-Some C<KEY>s are mandatory, others are global options which apply to
+Some C<KEY>s are mandatory, others are general options which apply to
 any guest type while others relate only to specific guest types
 (e.g. PV or HVM guests).
 
@@ -80,21 +80,14 @@
 
 =back
 
-=head2 Global Options
+=head2 General Options
 
 The following options apply to guests of any type.
 
+=head3 CPU Allocation
+
 =over 4
 
-=item B<uuid="UUID">
-
-Specifies the UUID of the domain.  If not specified, a fresh unique
-UUID will be generated.
-
-=item B<vncviewer=BOOLEAN>
-
-Automatically spawn a vncviewer when creating/restoring a guest
-
 =item B<pool="CPUPOOLNAME">
 
 Put the guest's vcpus into the named cpu pool.
@@ -138,6 +131,12 @@
 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.
 
+=back
+
+=head3 CPU Scheduling
+
+=over 4
+
 =item B<cpu_weight=WEIGHT>
 
 A domain with a weight of 512 will get twice as much CPU as a domain
@@ -176,6 +175,12 @@
 Flag for allowing domain to run in extra time.
 Honoured by the sedf scheduler.
 
+=back
+
+=head3 Memory Allocation
+
+=over 4
+
 =item B<memory=MBYTES>
 
 Start the guest with MBYTES megabytes of RAM.
@@ -190,6 +195,12 @@
 A "pre-ballooned" HVM guest needs a balloon driver, without a balloon driver
 it will crash.
 
+=back
+
+=head3 Event Actions
+
+=over 4
+
 =item B<on_poweroff="ACTION">
 
 Specifies what should be done with the domain if it shuts itself down.
@@ -200,12 +211,12 @@
 =item B<destroy>
 
 destroy the domain
-     
+
 =item B<restart>
 
 destroy the domain and immediately create a new domain with the same
 configuration
-        
+
 =item B<rename-restart>
 
 rename the domain which terminated, and then immediately create a new
@@ -244,10 +255,28 @@
 
 Action to take if the domain crashes.  Default is C<destroy>.
 
+=back
+
+=head3 Other Options
+
+=over 4
+
+=item B<uuid="UUID">
+
+Specifies the UUID of the domain.  If not specified, a fresh unique
+UUID will be generated.
+
 =item B<seclabel="LABEL">
 
 Assign an XSM security label to this domain.
 
+=item B<nomigrate=BOOLEAN>
+
+Disable migration of this domain.  This enables certain other features
+which are incompatible with migration. Currently this is limited to
+enabling the invariant TSC feature flag in cpuid results when TSC is
+not emulated.
+
 =back
 
 =head2 Devices
@@ -309,7 +338,20 @@
 =item C<sdl=BOOLEAN>
 
 Specifies that the display should be presented via an X window (using
-Simple DirectMedia Layer). The default is to not enable this mode
+Simple DirectMedia Layer). The default is to not enable this mode.
+
+=item C<display=DISPLAY>
+
+Specifies the X Window display that should be used when the sdl option
+is used. Note: passing this value to the device-model is not currently
+implemented, so providing this option will have no effect.
+
+=item C<xauthority=XAUTHORITY>
+
+Specifies the path to the X authorty file that should be used to
+connect to the X server when the sdl option is used. Note: passing
+this value to the device-model is not currently implemented, so
+providing this option will have no effect.
 
 =item C<opengl=BOOLEAN>
 
@@ -324,19 +366,9 @@
 (e.g. this is often the case when using VNC) then this allows us to
 correctly map the input keys into keycodes seen by the guest. The
 specific values which are accepted are defined by the version of the
-device-model which you are using. See L<Keymaps> below or consult the
+device-model which you are using. See L</"Keymaps"> below or consult the
 L<qemu(1)> manpage. The default is B<en-us>.
 
-=item C<display=XXX>
-
-XXX written to xenstore backend for vfb but does not appear to be used
-anywhere?
-
-=item C<authority=XXX>
-
-XXX written to xenstore backend for vfb but does not appear to be used
-anywhere?
-
 =back
 
 =item B<pci=[ "PCI_SPEC_STRING", "PCI_SPEC_STRING", ... ]>
@@ -348,7 +380,7 @@
 
 =item B<DDDD:BB:DD.F>
 
-identifies the PCI device from the host perspective in domain
+Identifies the PCI device from the host perspective in domain
 (B<DDDD>), Bus (B<BB>), Device (B<DD>) and Function (B<F>) syntax. This is
 the same scheme as used in the output of C<lspci> for the device in
 question. Note: By default C<lspci> will omit the domain (B<DDDD>) if it
@@ -357,9 +389,9 @@
 
 =item B<@VSLOT>
 
-specifies the virtual device where the guest will see this
+Specifies the virtual device where the guest will see this
 device. This is equivalent to the B<DD> which the guest sees. In a
-guest B<DDDD> and B<BB> are C<0000:00>. XXX how does this really work?
+guest B<DDDD> and B<BB> are C<0000:00>.
 
 =item B<KEY=VALUE>
 
@@ -367,14 +399,6 @@
 
 =over 4
 
-=item B<msitranslate=BOOLEAN>
-
-XXX
-
-=item B<power_mgmt=BOOLEAN>
-
-XXX
-
 =item B<permissive=BOOLEAN>
 
 (PV only) By default pciback only allows PV guests to write "known
@@ -386,6 +410,19 @@
 may have security or stability implications.  It is recommended to
 enable this option only for trusted VMs under administrator control.
 
+=item B<msitranslate=BOOLEAN>
+
+Specifies that MSI-INTx translation should be turned on for the PCI
+device. When enabled, MSI-INTx translation will always enable MSI on
+the PCI device regardless whether the guest uses INTx or MSI. Some
+device drivers, such as NVIDIA's, detect an inconsistency and do not
+function when this option is enabled. Therefore the default is 0.
+
+=item B<power_mgmt=BOOLEAN>
+
+(HVM only) Specifies that the VM should be able to program the
+D0-D3hot power management states for the PCI device. 0 by default.
+
 =back
 
 =back
@@ -393,12 +430,27 @@
 =item B<pci_permissive=BOOLEAN>
 
 (PV only) Changes the default value of 'permissive' for all PCI
-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
-for trusted VMs under administrator control.  See the "pci=" section
-for more information on the "permissive" flag.
+devices passed through to this VM. See L<permissive|/"permissive_boolean">
+above.
+
+=item B<pci_msitranslate=BOOLEAN>
+
+Changes the default value of 'msitranslate' for all PCI devices passed
+through to this VM. See L<msitranslate|/"msitranslate_boolean"> above.
+
+=item B<pci_power_mgmt=BOOLEAN>
+
+(HVM only) Changes the default value of 'power_mgmt' for all PCI
+devices passed through to this VM. See L<power_mgt|/"power_mgmt_boolean">
+above.
+
+=item B<gfx_passthru=BOOLEAN>
+
+(HVM only) Enable graphic device PCI passthrough. If a system's
+primary graphics adapter PCI device is specified in the
+L<pci|/"pci_pci_spec_string_pci_spec_string"> section above, enabling
+this option will cause the device to be used as the primary graphics
+adapter in the guest. 0 by default.
 
 =back
 
@@ -447,12 +499,12 @@
 option is specified the virtual e820 instead reflects the host e820
 and contains the same PCI holes. The total amount of RAM represented
 by the memory map is always the same, this option configures only how
-it is layed out.
+it is laid 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 Operating System dependant whether this
+PCI devices. It is guest Operating System dependent 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 configured and false otherwise. If you do not
@@ -576,6 +628,16 @@
 default and usually you should omit it. However it may be necessary to
 disable ACPI for compatibility with some guest Operating Systems.
 
+=item B<acpi_s3=BOOLEAN>
+
+Include the S3 (suspend-to-ram) power state in the virtual firmware
+ACPI table. 1 by default.
+
+=item B<acpi_s4=BOOLEAN>
+
+Include S4 (suspend-to-disk) power state in the virtual firmware ACPI
+table. 1 by default.
+
 =item B<apic=BOOLEAN>
 
 Include information regarding APIC (Advanced Programmable Interrupt
@@ -613,6 +675,54 @@
 which uses hardware virtualisation extensions (e.g. Windows XP
 compatibility mode on more modern Windows OS).
 
+=item B<cpuid="LIBXL_STRING"> or B<cpuid=[ "XEND_STRING", "XEND_STRING" ]>
+
+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>
+
 =back 
 
 =head3 Guest Virtual Time Controls
@@ -656,8 +766,6 @@
 
 =back
 
-=back
-
 Please see F<docs/misc/tscmode.txt> for more information on this option.
 
 =item B<localtime=BOOLEAN>
@@ -668,6 +776,50 @@
 
 Set the real time clock offset in seconds. 0 by default.
 
+
+=item B<vpt_align=BOOLEAN>
+
+Specifies that periodic Virtual Platform Timers should be aligned to
+reduce guest interrupts. Enabling this option can reduce power
+consumption, especially when a guest uses a high timer interrupt
+frequency (HZ) values. The default is 1.
+
+=item B<timer_mode=MODE>
+
+Specifies the mode for Virtual Timers. The valid values are as follows:
+
+=over 4
+
+=item B<"delay_for_missed_ticks">
+
+Delay for missed ticks. Do not advance a vcpu's time beyond the
+correct delivery time for interrupts that have been missed due to
+preemption. Deliver missed interrupts when the vcpu is rescheduled and
+advance the vcpu's virtual time stepwise for each one.
+
+=item B<"no_delay_for_missed_ticks">
+
+No delay for missed ticks. As above, missed interrupts are delivered,
+but guest time always tracks wallclock (i.e., real) time while doing
+so.
+
+=item B<"no_missed_ticks_pending">
+
+No missed interrupts are held pending. Instead, to ensure ticks are
+delivered at some non-zero rate, if we detect missed ticks then the
+internal tick alarm is not disabled if the VCPU is preempted during
+the next tick period.
+
+=item B<"one_missed_tick_pending">
+
+One missed tick pending. Missed interrupts are collapsed
+together and delivered as one 'late tick'.  Guest time always tracks
+wallclock (i.e., real) time.
+
+=back
+
+=back
+
 =head3 Support for Paravirtualisation of HVM Guests
 
 The following options allow Paravirtualised features (such as devices)
@@ -733,6 +885,10 @@
 Allow access to the display via the VNC protocol.  This enables the
 other VNC-related settings.  The default is to enable this.
 
+=item B<vncviewer=BOOLEAN>
+
+Automatically spawn a vncviewer when creating/restoring a guest.
+
 =item B<vnclisten="ADDRESS[:DISPLAYNUM]">
 
 Specifies the IP address, and optionally VNC display number, to use.
@@ -758,7 +914,7 @@
 (e.g. this is often the case when using VNC) then this allows us to
 correctly map the input keys into keycodes seen by the guest. The
 specific values which are accepted are defined by the version of the
-device-model which you are using. See L<Keymaps> below of consult the
+device-model which you are using. See L</"Keymaps"> below or consult the
 L<qemu(1)> manpage. The default is B<en-us>.
 
 =item B<sdl=BOOLEAN>
@@ -770,7 +926,7 @@
 
 Enable OpenGL acceleration of the SDL display. Only effects machines
 using B<device_model_version="qemu-xen-traditional"> and only if the
-device-model was compiled with OpenGL support. Disabled by default.
+device-model was compiled with OpenGL support. 0 by default.
 
 =item B<nographic=BOOLEAN>
 
@@ -854,28 +1010,7 @@
 function better than relative coordinate devices (such as a standard
 mouse) since many methods of exporting guest graphics (such as VNC)
 work better in this mode. Note that this is independent of the actual
-pointer device you are using on the host/client side. XXX should/could
-be a list of devices.
-
-=back
-
-=head3 Unclassified HVM Specific Options
-
-These HVM specific options have not yet been documented or
-classified. They almost certainly belong in a more appropriate
-section.
-
-=over 4
-
-=item B<vpt_align=BOOLEAN>
-
-Align the Virtual Platform Timer ??? XXX Reduces interrupts?
-
-=item B<timer_mode=NUMBER>
-
-Set mode for Virtual Timers XXX ??? should be an enum of particular
-values. See C<HVM_PARAM_TIMER_MODE> in
-F<xen/include/public/hvm/params.h>.
+pointer device you are using on the host/client side.
 
 =back
 
@@ -950,105 +1085,6 @@
 
 =back
 
-=head2 Unclassified General Options
-
-These have not yet been fully documented or classified. They almost
-certainly belong in a more appropriate section.
-
-=over 4
-
-=item B<gfx_passthru=BOOLEAN>
-
-Enable graphics device PCI passthrough. XXX which device is passed through ?
-
-=item B<nomigrate=BOOLEAN>
-
-Disable migration of this domain.  This enables certain other features
-which are incompatible with migration (currently certain TSC modes XXX
-?).
-
-=item B<pci_msitranslate=BOOLEAN>
-
-XXX
-
-=item B<pci_power_mgmt=BOOLEAN>
-
-XXX
-
-=item B<cpuid="LIBXL_STRING"> or B<cpuid=[ "XEND_STRING", "XEND_STRING" ]>
-
-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>
-
-XXX
-
-=item B<acpi_s3=BOOLEAN>
-
-XXX
-
-=item B<nodes=XXX>
-
-XXX
-
-=item B<sched=XXX>
-
-XXX
-
-=item B<device_model=XXX>
-
-XXX deprecated
-
-=item B<vif2=XXX>
-
-XXX deprecated
-
-=back
-
 =head2 Keymaps
 
 The keymaps available are defined by the device-model which you are
@@ -1083,9 +1119,9 @@
 =head1 BUGS
 
 This document is a work in progress and contains items which require
-further documentation and which are generally incomplete (marked with
-XXX).  However all options are included here whether or not they are
-fully documented.
+further documentation and which are generally incomplete.  However all
+supported options are included here whether or not they are fully
+documented.
 
 Patches to improve incomplete items (or any other item) would be
 gratefully received on the xen-devel@lists.xen.org mailing

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Sep 08 09:52:53 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 08 Sep 2012 09:52:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TAHiF-00088i-EG; Sat, 08 Sep 2012 09:52:27 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dan.carpenter@oracle.com>) id 1TAHiE-00088d-CK
	for xen-devel@lists.xensource.com; Sat, 08 Sep 2012 09:52:26 +0000
Received: from [85.158.143.35:8001] by server-1.bemta-4.messagelabs.com id
	4E/8F-12504-9551B405; Sat, 08 Sep 2012 09:52:25 +0000
X-Env-Sender: dan.carpenter@oracle.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1347097943!17349782!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDc0Njg4Ng==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25459 invoked from network); 8 Sep 2012 09:52:25 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-14.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 8 Sep 2012 09:52: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 q889qGID011657
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Sat, 8 Sep 2012 09:52:17 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q889qEA1012572
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Sat, 8 Sep 2012 09:52:15 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
	q889qBM9005886; Sat, 8 Sep 2012 04:52:11 -0500
Received: from elgon.mountain (/41.212.103.53)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Sat, 08 Sep 2012 02:52:11 -0700
Date: Sat, 8 Sep 2012 12:52:08 +0300
From: Dan Carpenter <dan.carpenter@oracle.com>
To: Andres Lagar-Cavilla <andreslc@gridcentric.ca>
Message-ID: <20120908095208.GA608@elgon.mountain>
MIME-Version: 1.0
Content-Disposition: inline
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: kernel-janitors@vger.kernel.org, Jeremy Fitzhardinge <jeremy@goop.org>,
	xen-devel@lists.xensource.com, virtualization@lists.linux-foundation.org,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: [Xen-devel] [patch 1/3] xen/privcmd: check for integer overflow in
	ioctl
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 m.num is too large then the "m.num * sizeof(*m.arr)" multiplication
could overflow and the access_ok() check wouldn't test the right size.

Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
---
Only needed in linux-next.

diff --git a/drivers/xen/privcmd.c b/drivers/xen/privcmd.c
index 215a3c0..fdff8f9 100644
--- a/drivers/xen/privcmd.c
+++ b/drivers/xen/privcmd.c
@@ -325,6 +325,8 @@ static long privcmd_ioctl_mmap_batch(void __user *udata, int version)
 			return -EFAULT;
 		/* Returns per-frame error in m.arr. */
 		m.err = NULL;
+		if (m.num > SIZE_MAX / sizeof(*m.arr))
+			return -EINVAL;
 		if (!access_ok(VERIFY_WRITE, m.arr, m.num * sizeof(*m.arr)))
 			return -EFAULT;
 		break;
@@ -332,6 +334,8 @@ static long privcmd_ioctl_mmap_batch(void __user *udata, int version)
 		if (copy_from_user(&m, udata, sizeof(struct privcmd_mmapbatch_v2)))
 			return -EFAULT;
 		/* Returns per-frame error code in m.err. */
+		if (m.num > SIZE_MAX / sizeof(*m.err))
+			return -EINVAL;
 		if (!access_ok(VERIFY_WRITE, m.err, m.num * (sizeof(*m.err))))
 			return -EFAULT;
 		break;

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Sep 08 09:52:53 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 08 Sep 2012 09:52:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TAHiF-00088i-EG; Sat, 08 Sep 2012 09:52:27 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dan.carpenter@oracle.com>) id 1TAHiE-00088d-CK
	for xen-devel@lists.xensource.com; Sat, 08 Sep 2012 09:52:26 +0000
Received: from [85.158.143.35:8001] by server-1.bemta-4.messagelabs.com id
	4E/8F-12504-9551B405; Sat, 08 Sep 2012 09:52:25 +0000
X-Env-Sender: dan.carpenter@oracle.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1347097943!17349782!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDc0Njg4Ng==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25459 invoked from network); 8 Sep 2012 09:52:25 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-14.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 8 Sep 2012 09:52: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 q889qGID011657
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Sat, 8 Sep 2012 09:52:17 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q889qEA1012572
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Sat, 8 Sep 2012 09:52:15 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
	q889qBM9005886; Sat, 8 Sep 2012 04:52:11 -0500
Received: from elgon.mountain (/41.212.103.53)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Sat, 08 Sep 2012 02:52:11 -0700
Date: Sat, 8 Sep 2012 12:52:08 +0300
From: Dan Carpenter <dan.carpenter@oracle.com>
To: Andres Lagar-Cavilla <andreslc@gridcentric.ca>
Message-ID: <20120908095208.GA608@elgon.mountain>
MIME-Version: 1.0
Content-Disposition: inline
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: kernel-janitors@vger.kernel.org, Jeremy Fitzhardinge <jeremy@goop.org>,
	xen-devel@lists.xensource.com, virtualization@lists.linux-foundation.org,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: [Xen-devel] [patch 1/3] xen/privcmd: check for integer overflow in
	ioctl
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 m.num is too large then the "m.num * sizeof(*m.arr)" multiplication
could overflow and the access_ok() check wouldn't test the right size.

Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
---
Only needed in linux-next.

diff --git a/drivers/xen/privcmd.c b/drivers/xen/privcmd.c
index 215a3c0..fdff8f9 100644
--- a/drivers/xen/privcmd.c
+++ b/drivers/xen/privcmd.c
@@ -325,6 +325,8 @@ static long privcmd_ioctl_mmap_batch(void __user *udata, int version)
 			return -EFAULT;
 		/* Returns per-frame error in m.arr. */
 		m.err = NULL;
+		if (m.num > SIZE_MAX / sizeof(*m.arr))
+			return -EINVAL;
 		if (!access_ok(VERIFY_WRITE, m.arr, m.num * sizeof(*m.arr)))
 			return -EFAULT;
 		break;
@@ -332,6 +334,8 @@ static long privcmd_ioctl_mmap_batch(void __user *udata, int version)
 		if (copy_from_user(&m, udata, sizeof(struct privcmd_mmapbatch_v2)))
 			return -EFAULT;
 		/* Returns per-frame error code in m.err. */
+		if (m.num > SIZE_MAX / sizeof(*m.err))
+			return -EINVAL;
 		if (!access_ok(VERIFY_WRITE, m.err, m.num * (sizeof(*m.err))))
 			return -EFAULT;
 		break;

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Sep 08 09:58:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 08 Sep 2012 09:58:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TAHnT-0008Gn-6i; Sat, 08 Sep 2012 09:57:51 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dan.carpenter@oracle.com>) id 1TAHnR-0008Gg-OM
	for xen-devel@lists.xensource.com; Sat, 08 Sep 2012 09:57:49 +0000
Received: from [85.158.143.35:17421] by server-1.bemta-4.messagelabs.com id
	E6/71-12504-D961B405; Sat, 08 Sep 2012 09:57:49 +0000
X-Env-Sender: dan.carpenter@oracle.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1347098266!6327562!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzM1MzU4\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20093 invoked from network); 8 Sep 2012 09:57:48 -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; 8 Sep 2012 09:57:48 -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 q889vfHb004293
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Sat, 8 Sep 2012 09:57:42 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
	q889vd0R018334
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Sat, 8 Sep 2012 09:57:40 GMT
Received: from abhmt107.oracle.com (abhmt107.oracle.com [141.146.116.59])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q889vdKI004996; Sat, 8 Sep 2012 04:57:39 -0500
Received: from elgon.mountain (/41.212.103.53)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Sat, 08 Sep 2012 02:57:38 -0700
Date: Sat, 8 Sep 2012 12:57:35 +0300
From: Dan Carpenter <dan.carpenter@oracle.com>
To: Andres Lagar-Cavilla <andreslc@gridcentric.ca>
Message-ID: <20120908095735.GB608@elgon.mountain>
MIME-Version: 1.0
Content-Disposition: inline
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: kernel-janitors@vger.kernel.org, Jeremy Fitzhardinge <jeremy@goop.org>,
	xen-devel@lists.xensource.com, virtualization@lists.linux-foundation.org,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: [Xen-devel] [patch 2/3] xen/privcmd: return -EFAULT on 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

__copy_to_user() returns the number of bytes remaining to be copied but
we want to return a negative error code here.

Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>

diff --git a/drivers/xen/privcmd.c b/drivers/xen/privcmd.c
index fdff8f9..0ce006a 100644
--- a/drivers/xen/privcmd.c
+++ b/drivers/xen/privcmd.c
@@ -393,8 +393,11 @@ static long privcmd_ioctl_mmap_batch(void __user *udata, int version)
 		state.err      = err_array;
 		ret = traverse_pages(m.num, sizeof(xen_pfn_t),
 				     &pagelist, mmap_return_errors_v1, &state);
-	} else if (version == 2)
+	} else if (version == 2) {
 		ret = __copy_to_user(m.err, err_array, m.num * sizeof(int));
+		if (ret)
+			ret = -EFAULT;
+	}
 
 	/* If we have not had any EFAULT-like global errors then set the global
 	 * error to -ENOENT if necessary. */

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Sep 08 09:58:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 08 Sep 2012 09:58:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TAHnT-0008Gn-6i; Sat, 08 Sep 2012 09:57:51 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dan.carpenter@oracle.com>) id 1TAHnR-0008Gg-OM
	for xen-devel@lists.xensource.com; Sat, 08 Sep 2012 09:57:49 +0000
Received: from [85.158.143.35:17421] by server-1.bemta-4.messagelabs.com id
	E6/71-12504-D961B405; Sat, 08 Sep 2012 09:57:49 +0000
X-Env-Sender: dan.carpenter@oracle.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1347098266!6327562!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzM1MzU4\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20093 invoked from network); 8 Sep 2012 09:57:48 -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; 8 Sep 2012 09:57:48 -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 q889vfHb004293
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Sat, 8 Sep 2012 09:57:42 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
	q889vd0R018334
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Sat, 8 Sep 2012 09:57:40 GMT
Received: from abhmt107.oracle.com (abhmt107.oracle.com [141.146.116.59])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q889vdKI004996; Sat, 8 Sep 2012 04:57:39 -0500
Received: from elgon.mountain (/41.212.103.53)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Sat, 08 Sep 2012 02:57:38 -0700
Date: Sat, 8 Sep 2012 12:57:35 +0300
From: Dan Carpenter <dan.carpenter@oracle.com>
To: Andres Lagar-Cavilla <andreslc@gridcentric.ca>
Message-ID: <20120908095735.GB608@elgon.mountain>
MIME-Version: 1.0
Content-Disposition: inline
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: kernel-janitors@vger.kernel.org, Jeremy Fitzhardinge <jeremy@goop.org>,
	xen-devel@lists.xensource.com, virtualization@lists.linux-foundation.org,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: [Xen-devel] [patch 2/3] xen/privcmd: return -EFAULT on 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

__copy_to_user() returns the number of bytes remaining to be copied but
we want to return a negative error code here.

Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>

diff --git a/drivers/xen/privcmd.c b/drivers/xen/privcmd.c
index fdff8f9..0ce006a 100644
--- a/drivers/xen/privcmd.c
+++ b/drivers/xen/privcmd.c
@@ -393,8 +393,11 @@ static long privcmd_ioctl_mmap_batch(void __user *udata, int version)
 		state.err      = err_array;
 		ret = traverse_pages(m.num, sizeof(xen_pfn_t),
 				     &pagelist, mmap_return_errors_v1, &state);
-	} else if (version == 2)
+	} else if (version == 2) {
 		ret = __copy_to_user(m.err, err_array, m.num * sizeof(int));
+		if (ret)
+			ret = -EFAULT;
+	}
 
 	/* If we have not had any EFAULT-like global errors then set the global
 	 * error to -ENOENT if necessary. */

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Sep 08 09:58:43 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 08 Sep 2012 09:58: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 1TAHnw-0008Iu-Jc; Sat, 08 Sep 2012 09:58:20 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dan.carpenter@oracle.com>) id 1TAHnv-0008Ii-1W
	for xen-devel@lists.xensource.com; Sat, 08 Sep 2012 09:58:19 +0000
Received: from [85.158.138.51:16987] by server-10.bemta-3.messagelabs.com id
	9D/63-10411-AB61B405; Sat, 08 Sep 2012 09:58:18 +0000
X-Env-Sender: dan.carpenter@oracle.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1347098296!20523098!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzM2NTc5\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12992 invoked from network); 8 Sep 2012 09:58:17 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-7.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 8 Sep 2012 09:58:17 -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 q889wCLY004552
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Sat, 8 Sep 2012 09:58:12 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
	q889wBcA009932
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Sat, 8 Sep 2012 09:58:11 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
	q889wBgL000759; Sat, 8 Sep 2012 04:58:11 -0500
Received: from elgon.mountain (/41.212.103.53)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Sat, 08 Sep 2012 02:58:10 -0700
Date: Sat, 8 Sep 2012 12:58:08 +0300
From: Dan Carpenter <dan.carpenter@oracle.com>
To: Andres Lagar-Cavilla <andreslc@gridcentric.ca>
Message-ID: <20120908095808.GC608@elgon.mountain>
MIME-Version: 1.0
Content-Disposition: inline
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: kernel-janitors@vger.kernel.org, Jeremy Fitzhardinge <jeremy@goop.org>,
	xen-devel@lists.xensource.com, virtualization@lists.linux-foundation.org,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: [Xen-devel] [patch 3/3] xen/privcmd: remove const modifier from
	declaration
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

When we use this pointer, we cast away the const modifier and modify the
data.  I think it was an accident to declare it as const.

Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>

diff --git a/include/xen/privcmd.h b/include/xen/privcmd.h
index a853168..58ed953 100644
--- a/include/xen/privcmd.h
+++ b/include/xen/privcmd.h
@@ -69,7 +69,7 @@ struct privcmd_mmapbatch_v2 {
 	unsigned int num; /* number of pages to populate */
 	domid_t dom;      /* target domain */
 	__u64 addr;       /* virtual address */
-	const xen_pfn_t __user *arr; /* array of mfns */
+	xen_pfn_t __user *arr; /* array of mfns */
 	int __user *err;  /* array of error codes */
 };
 
diff --git a/drivers/xen/privcmd.c b/drivers/xen/privcmd.c
index 0ce006a..fceb83e 100644
--- a/drivers/xen/privcmd.c
+++ b/drivers/xen/privcmd.c
@@ -389,7 +389,7 @@ static long privcmd_ioctl_mmap_batch(void __user *udata, int version)
 
 	if (state.global_error && (version == 1)) {
 		/* Write back errors in second pass. */
-		state.user_mfn = (xen_pfn_t *)m.arr;
+		state.user_mfn = m.arr;
 		state.err      = err_array;
 		ret = traverse_pages(m.num, sizeof(xen_pfn_t),
 				     &pagelist, mmap_return_errors_v1, &state);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Sep 08 09:58:43 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 08 Sep 2012 09:58: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 1TAHnw-0008Iu-Jc; Sat, 08 Sep 2012 09:58:20 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dan.carpenter@oracle.com>) id 1TAHnv-0008Ii-1W
	for xen-devel@lists.xensource.com; Sat, 08 Sep 2012 09:58:19 +0000
Received: from [85.158.138.51:16987] by server-10.bemta-3.messagelabs.com id
	9D/63-10411-AB61B405; Sat, 08 Sep 2012 09:58:18 +0000
X-Env-Sender: dan.carpenter@oracle.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1347098296!20523098!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzM2NTc5\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12992 invoked from network); 8 Sep 2012 09:58:17 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-7.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 8 Sep 2012 09:58:17 -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 q889wCLY004552
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Sat, 8 Sep 2012 09:58:12 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
	q889wBcA009932
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Sat, 8 Sep 2012 09:58:11 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
	q889wBgL000759; Sat, 8 Sep 2012 04:58:11 -0500
Received: from elgon.mountain (/41.212.103.53)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Sat, 08 Sep 2012 02:58:10 -0700
Date: Sat, 8 Sep 2012 12:58:08 +0300
From: Dan Carpenter <dan.carpenter@oracle.com>
To: Andres Lagar-Cavilla <andreslc@gridcentric.ca>
Message-ID: <20120908095808.GC608@elgon.mountain>
MIME-Version: 1.0
Content-Disposition: inline
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: kernel-janitors@vger.kernel.org, Jeremy Fitzhardinge <jeremy@goop.org>,
	xen-devel@lists.xensource.com, virtualization@lists.linux-foundation.org,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: [Xen-devel] [patch 3/3] xen/privcmd: remove const modifier from
	declaration
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

When we use this pointer, we cast away the const modifier and modify the
data.  I think it was an accident to declare it as const.

Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>

diff --git a/include/xen/privcmd.h b/include/xen/privcmd.h
index a853168..58ed953 100644
--- a/include/xen/privcmd.h
+++ b/include/xen/privcmd.h
@@ -69,7 +69,7 @@ struct privcmd_mmapbatch_v2 {
 	unsigned int num; /* number of pages to populate */
 	domid_t dom;      /* target domain */
 	__u64 addr;       /* virtual address */
-	const xen_pfn_t __user *arr; /* array of mfns */
+	xen_pfn_t __user *arr; /* array of mfns */
 	int __user *err;  /* array of error codes */
 };
 
diff --git a/drivers/xen/privcmd.c b/drivers/xen/privcmd.c
index 0ce006a..fceb83e 100644
--- a/drivers/xen/privcmd.c
+++ b/drivers/xen/privcmd.c
@@ -389,7 +389,7 @@ static long privcmd_ioctl_mmap_batch(void __user *udata, int version)
 
 	if (state.global_error && (version == 1)) {
 		/* Write back errors in second pass. */
-		state.user_mfn = (xen_pfn_t *)m.arr;
+		state.user_mfn = m.arr;
 		state.err      = err_array;
 		ret = traverse_pages(m.num, sizeof(xen_pfn_t),
 				     &pagelist, mmap_return_errors_v1, &state);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Sep 08 10:18:36 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 08 Sep 2012 10: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 1TAI7E-0000Oe-KD; Sat, 08 Sep 2012 10:18:16 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <paolo.bonzini@gmail.com>) id 1TAI7D-0000OW-99
	for xen-devel@lists.xen.org; Sat, 08 Sep 2012 10:18:15 +0000
X-Env-Sender: paolo.bonzini@gmail.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1347099488!3181168!1
X-Originating-IP: [74.125.82.51]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28995 invoked from network); 8 Sep 2012 10:18:09 -0000
Received: from mail-wg0-f51.google.com (HELO mail-wg0-f51.google.com)
	(74.125.82.51)
	by server-15.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Sep 2012 10:18:09 -0000
Received: by wgbed3 with SMTP id ed3so270943wgb.32
	for <xen-devel@lists.xen.org>; Sat, 08 Sep 2012 03:18:08 -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=p5f4aX8Z9vkKJ72spI5eHvkD1fOhdBHUgnt6juOSbEw=;
	b=wCPXvDtN9jiyV9Dz3bFgovYZuiPGgCRWylRKVN/0S5U8M5rdxm2WmUz5fMw0aO7l2p
	g9rJHhdM6U9QHClxp+BHsNynZF3PyIoqrJ8xqv0ZETS8PjC8jlk0k5VWsliYX7jFBUqh
	evr1uieyNxkINVdZt71D/zTEuFlNXBGHSuI+v5vWGsdAMvBxNMGqLXMfUjzFZR9GMP5D
	812wzVUAgqcBnUvqnyjfYmm5GADKqrFB5LY93gI4rM59riPPfoAvu/OlH98z+vuKeP0P
	LEOw6C4UuhCuoCcx6eHvZONpptVJpi3HWQwIIRvlQS+QTktPfHdKlDXYgOfmuuhIkSHa
	G5RA==
Received: by 10.216.99.199 with SMTP id x49mr4898671wef.171.1347099488578;
	Sat, 08 Sep 2012 03:18:08 -0700 (PDT)
Received: from yakj.usersys.redhat.com (93-34-169-1.ip50.fastwebnet.it.
	[93.34.169.1])
	by mx.google.com with ESMTPS id w7sm4079490wiz.0.2012.09.08.03.18.02
	(version=TLSv1/SSLv3 cipher=OTHER);
	Sat, 08 Sep 2012 03:18:07 -0700 (PDT)
Message-ID: <504B1B58.4030103@redhat.com>
Date: Sat, 08 Sep 2012 12:18:00 +0200
From: Paolo Bonzini <pbonzini@redhat.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:14.0) Gecko/20120717 Thunderbird/14.0
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
References: <1347018043-21252-1-git-send-email-stefan.bader@canonical.com>
	<504A05B00200007800099C7B@nat28.tlf.novell.com>
	<5049F4E9.9050306@canonical.com>
	<504A1A950200007800099D4C@nat28.tlf.novell.com>
	<20120907142251.GA20096@linuxtx.org>
	<20120907145433.GA5378@phenom.dumpdata.com>
In-Reply-To: <20120907145433.GA5378@phenom.dumpdata.com>
Cc: Jan Beulich <JBeulich@suse.com>, "Justin M. Forbes" <jmforbes@linuxtx.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Stefan Bader <stefan.bader@canonical.com>,
	xen-devel@lists.xen.org, Matt Wilson <msw@amazon.com>
Subject: Re: [Xen-devel] [PATCH/RFC] Fix xsave bug on older Xen hypervisors
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Il 07/09/2012 16:54, Konrad Rzeszutek Wilk ha scritto:
>>> But iirc that bad patch is a Linux side one (i.e. you're trying to fix
>>> something upstream that isn't upstream)?
>>>
>> Right, so the patch that this improves upon, and that Fedora and Ubuntu are
>> currently carrying is not upstream because:
>>
>> a) It's crap, it cripples upstream xen users, but doesn't impact RHEL xen
>> users because xsave was never supported there.
>>
>> b) The hypervisor was patched to make it unnecessary quite some time ago,
>> and we hoped EC2 would eventually pick up that correct patch and we could
>> drop the crap kernel patch.
>>
>> Unfortunately this has not happened. We are at a point where EC2 really is
>> a quirk that has to be worked around. Distros do not want to maintain
>> a separate EC2 build of the kernel, so the easiest way is to cripple
>> current upstream xen users.  This quirk is unfortunately the best possible
>> solution.  Having it upstream also makes it possible for any user to build
>> an upstream kernel that will run on EC2 without having to dig a random
>> patch out of a vendor kernel.
> 
> Sure. Jan is asking though for actual confirmation that the upstream kernel
> does indeed go belly up without a workaround.
> And whether this patch (which I would did since Canonical is carrying it) does
> fix the issue.
> 
> I am still a newbie on the Amazon EC2 upload your kernel thing (hint, would
> appreciate somebody taking this patch and trying it out).

You can just pick an old version of the CentOS kernel package, for
example 2.6.18-128.el5 or 2.6.18-164.el5 (respectively CentOS/RHEL 5.3
and 5.4).

Paolo


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Sep 08 10:18:36 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 08 Sep 2012 10: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 1TAI7E-0000Oe-KD; Sat, 08 Sep 2012 10:18:16 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <paolo.bonzini@gmail.com>) id 1TAI7D-0000OW-99
	for xen-devel@lists.xen.org; Sat, 08 Sep 2012 10:18:15 +0000
X-Env-Sender: paolo.bonzini@gmail.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1347099488!3181168!1
X-Originating-IP: [74.125.82.51]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28995 invoked from network); 8 Sep 2012 10:18:09 -0000
Received: from mail-wg0-f51.google.com (HELO mail-wg0-f51.google.com)
	(74.125.82.51)
	by server-15.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Sep 2012 10:18:09 -0000
Received: by wgbed3 with SMTP id ed3so270943wgb.32
	for <xen-devel@lists.xen.org>; Sat, 08 Sep 2012 03:18:08 -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=p5f4aX8Z9vkKJ72spI5eHvkD1fOhdBHUgnt6juOSbEw=;
	b=wCPXvDtN9jiyV9Dz3bFgovYZuiPGgCRWylRKVN/0S5U8M5rdxm2WmUz5fMw0aO7l2p
	g9rJHhdM6U9QHClxp+BHsNynZF3PyIoqrJ8xqv0ZETS8PjC8jlk0k5VWsliYX7jFBUqh
	evr1uieyNxkINVdZt71D/zTEuFlNXBGHSuI+v5vWGsdAMvBxNMGqLXMfUjzFZR9GMP5D
	812wzVUAgqcBnUvqnyjfYmm5GADKqrFB5LY93gI4rM59riPPfoAvu/OlH98z+vuKeP0P
	LEOw6C4UuhCuoCcx6eHvZONpptVJpi3HWQwIIRvlQS+QTktPfHdKlDXYgOfmuuhIkSHa
	G5RA==
Received: by 10.216.99.199 with SMTP id x49mr4898671wef.171.1347099488578;
	Sat, 08 Sep 2012 03:18:08 -0700 (PDT)
Received: from yakj.usersys.redhat.com (93-34-169-1.ip50.fastwebnet.it.
	[93.34.169.1])
	by mx.google.com with ESMTPS id w7sm4079490wiz.0.2012.09.08.03.18.02
	(version=TLSv1/SSLv3 cipher=OTHER);
	Sat, 08 Sep 2012 03:18:07 -0700 (PDT)
Message-ID: <504B1B58.4030103@redhat.com>
Date: Sat, 08 Sep 2012 12:18:00 +0200
From: Paolo Bonzini <pbonzini@redhat.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:14.0) Gecko/20120717 Thunderbird/14.0
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
References: <1347018043-21252-1-git-send-email-stefan.bader@canonical.com>
	<504A05B00200007800099C7B@nat28.tlf.novell.com>
	<5049F4E9.9050306@canonical.com>
	<504A1A950200007800099D4C@nat28.tlf.novell.com>
	<20120907142251.GA20096@linuxtx.org>
	<20120907145433.GA5378@phenom.dumpdata.com>
In-Reply-To: <20120907145433.GA5378@phenom.dumpdata.com>
Cc: Jan Beulich <JBeulich@suse.com>, "Justin M. Forbes" <jmforbes@linuxtx.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Stefan Bader <stefan.bader@canonical.com>,
	xen-devel@lists.xen.org, Matt Wilson <msw@amazon.com>
Subject: Re: [Xen-devel] [PATCH/RFC] Fix xsave bug on older Xen hypervisors
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Il 07/09/2012 16:54, Konrad Rzeszutek Wilk ha scritto:
>>> But iirc that bad patch is a Linux side one (i.e. you're trying to fix
>>> something upstream that isn't upstream)?
>>>
>> Right, so the patch that this improves upon, and that Fedora and Ubuntu are
>> currently carrying is not upstream because:
>>
>> a) It's crap, it cripples upstream xen users, but doesn't impact RHEL xen
>> users because xsave was never supported there.
>>
>> b) The hypervisor was patched to make it unnecessary quite some time ago,
>> and we hoped EC2 would eventually pick up that correct patch and we could
>> drop the crap kernel patch.
>>
>> Unfortunately this has not happened. We are at a point where EC2 really is
>> a quirk that has to be worked around. Distros do not want to maintain
>> a separate EC2 build of the kernel, so the easiest way is to cripple
>> current upstream xen users.  This quirk is unfortunately the best possible
>> solution.  Having it upstream also makes it possible for any user to build
>> an upstream kernel that will run on EC2 without having to dig a random
>> patch out of a vendor kernel.
> 
> Sure. Jan is asking though for actual confirmation that the upstream kernel
> does indeed go belly up without a workaround.
> And whether this patch (which I would did since Canonical is carrying it) does
> fix the issue.
> 
> I am still a newbie on the Amazon EC2 upload your kernel thing (hint, would
> appreciate somebody taking this patch and trying it out).

You can just pick an old version of the CentOS kernel package, for
example 2.6.18-128.el5 or 2.6.18-164.el5 (respectively CentOS/RHEL 5.3
and 5.4).

Paolo


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Sep 08 10:20:45 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 08 Sep 2012 10:20: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 1TAI9K-0000Tj-4n; Sat, 08 Sep 2012 10:20:26 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <paolo.bonzini@gmail.com>) id 1TAI9I-0000Td-3a
	for xen-devel@lists.xen.org; Sat, 08 Sep 2012 10:20:24 +0000
Received: from [85.158.143.99:15062] by server-1.bemta-4.messagelabs.com id
	4D/CA-12504-7EB1B405; Sat, 08 Sep 2012 10:20:23 +0000
X-Env-Sender: paolo.bonzini@gmail.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1347099622!19633603!1
X-Originating-IP: [74.125.82.51]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25111 invoked from network); 8 Sep 2012 10:20:22 -0000
Received: from mail-wg0-f51.google.com (HELO mail-wg0-f51.google.com)
	(74.125.82.51)
	by server-14.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Sep 2012 10:20:22 -0000
Received: by wgbed3 with SMTP id ed3so271680wgb.32
	for <xen-devel@lists.xen.org>; Sat, 08 Sep 2012 03:20:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject
	:references:in-reply-to:content-type:content-transfer-encoding;
	bh=ch7lJchooDdfLihNR5CuQm0petZ+D6/nxaaxPA8QiW4=;
	b=Dwj9U7C2Wapvjoyzq99ZofZ6VcGIeOmeCxon9gX5Fa7ZpNiCsTl3BwlUb3RQsBeOn1
	uhKlJD0DbWVCd+HhjJod//+4E6b+FYxeHPxqGppAn6nXstUWhL6m4ym3oOU+l4XiCZzX
	44Z9T7DKjcnigkQ/kFFv9TMx4Ywkt/2xmeaVgW2SeC8CCdesMizCJUGF7FK9ythm+E0w
	Bi03F8K1AmakkadMbQM93GmLWkgt4uwuWF+iptRnm27PwasXF30YfLh9oJxLAbiXs4Z1
	v+O5VyU6wQDvxGVt9nOt+hJM7fpr0PsaSK3O2XzH+TV2b+d1EnOrPgt+Aa9oN4HTXydP
	+Kow==
Received: by 10.180.78.40 with SMTP id y8mr4244145wiw.7.1347099622351;
	Sat, 08 Sep 2012 03:20:22 -0700 (PDT)
Received: from yakj.usersys.redhat.com (93-34-169-1.ip50.fastwebnet.it.
	[93.34.169.1])
	by mx.google.com with ESMTPS id o2sm6086481wiz.11.2012.09.08.03.20.17
	(version=TLSv1/SSLv3 cipher=OTHER);
	Sat, 08 Sep 2012 03:20:21 -0700 (PDT)
Message-ID: <504B1BE0.9040901@redhat.com>
Date: Sat, 08 Sep 2012 12:20:16 +0200
From: Paolo Bonzini <pbonzini@redhat.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:14.0) Gecko/20120717 Thunderbird/14.0
MIME-Version: 1.0
To: Stefan Bader <stefan.bader@canonical.com>
References: <1347018043-21252-1-git-send-email-stefan.bader@canonical.com>
	<504A05B00200007800099C7B@nat28.tlf.novell.com>
	<5049F4E9.9050306@canonical.com>
	<504A1A950200007800099D4C@nat28.tlf.novell.com>
	<20120907142251.GA20096@linuxtx.org>
	<504A32800200007800099E40@nat28.tlf.novell.com>
	<504A172B.5020005@canonical.com>
In-Reply-To: <504A172B.5020005@canonical.com>
Cc: Jan Beulich <JBeulich@suse.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"Justin M. Forbes" <jmforbes@linuxtx.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	xen-devel@lists.xen.org, Matt Wilson <msw@amazon.com>
Subject: Re: [Xen-devel] [PATCH/RFC] Fix xsave bug on older Xen hypervisors
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Il 07/09/2012 17:47, Stefan Bader ha scritto:
> 
> Legacy hypervisors (RHEL 5.0 and RHEL 5.1) do not handle guest writes to
> cr4 gracefully. If a guest attempts to write a bit of cr4 that is
> unsupported, then the HV is so offended it crashes the domain. While
> later guest kernels (such as RHEL6) don't assume the HV supports all
> features, they do expect nicer responses. That assumption introduced
> code that probes whether or not xsave is supported early in the boot. So
> now when attempting to boot a RHEL6 guest on RHEL5.0 or RHEL5.1 an early
> crash will occur.
> 
> This patch is quite obviously an undesirable hack. The real fix for this
> problem should be in the HV, and is, in later HVs. However, to support
> running on old HVs, RHEL6 can take this small change. No impact will
> occur for running on any RHEL HV (not even RHEL 5.5 supports xsave).
> There is only potential for guest performance loss on upstream Xen.
> 
> All this by way of explanation for why is this patch not going upstream.

If it is just 5.0 and 5.1, you can restrict the patch to Xen 3.0.

5.2 switched to Xen 3.1, which has been subsequently patched to death
without rebasing.

Paolo

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Sep 08 10:20:45 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 08 Sep 2012 10:20: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 1TAI9K-0000Tj-4n; Sat, 08 Sep 2012 10:20:26 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <paolo.bonzini@gmail.com>) id 1TAI9I-0000Td-3a
	for xen-devel@lists.xen.org; Sat, 08 Sep 2012 10:20:24 +0000
Received: from [85.158.143.99:15062] by server-1.bemta-4.messagelabs.com id
	4D/CA-12504-7EB1B405; Sat, 08 Sep 2012 10:20:23 +0000
X-Env-Sender: paolo.bonzini@gmail.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1347099622!19633603!1
X-Originating-IP: [74.125.82.51]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25111 invoked from network); 8 Sep 2012 10:20:22 -0000
Received: from mail-wg0-f51.google.com (HELO mail-wg0-f51.google.com)
	(74.125.82.51)
	by server-14.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Sep 2012 10:20:22 -0000
Received: by wgbed3 with SMTP id ed3so271680wgb.32
	for <xen-devel@lists.xen.org>; Sat, 08 Sep 2012 03:20:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject
	:references:in-reply-to:content-type:content-transfer-encoding;
	bh=ch7lJchooDdfLihNR5CuQm0petZ+D6/nxaaxPA8QiW4=;
	b=Dwj9U7C2Wapvjoyzq99ZofZ6VcGIeOmeCxon9gX5Fa7ZpNiCsTl3BwlUb3RQsBeOn1
	uhKlJD0DbWVCd+HhjJod//+4E6b+FYxeHPxqGppAn6nXstUWhL6m4ym3oOU+l4XiCZzX
	44Z9T7DKjcnigkQ/kFFv9TMx4Ywkt/2xmeaVgW2SeC8CCdesMizCJUGF7FK9ythm+E0w
	Bi03F8K1AmakkadMbQM93GmLWkgt4uwuWF+iptRnm27PwasXF30YfLh9oJxLAbiXs4Z1
	v+O5VyU6wQDvxGVt9nOt+hJM7fpr0PsaSK3O2XzH+TV2b+d1EnOrPgt+Aa9oN4HTXydP
	+Kow==
Received: by 10.180.78.40 with SMTP id y8mr4244145wiw.7.1347099622351;
	Sat, 08 Sep 2012 03:20:22 -0700 (PDT)
Received: from yakj.usersys.redhat.com (93-34-169-1.ip50.fastwebnet.it.
	[93.34.169.1])
	by mx.google.com with ESMTPS id o2sm6086481wiz.11.2012.09.08.03.20.17
	(version=TLSv1/SSLv3 cipher=OTHER);
	Sat, 08 Sep 2012 03:20:21 -0700 (PDT)
Message-ID: <504B1BE0.9040901@redhat.com>
Date: Sat, 08 Sep 2012 12:20:16 +0200
From: Paolo Bonzini <pbonzini@redhat.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:14.0) Gecko/20120717 Thunderbird/14.0
MIME-Version: 1.0
To: Stefan Bader <stefan.bader@canonical.com>
References: <1347018043-21252-1-git-send-email-stefan.bader@canonical.com>
	<504A05B00200007800099C7B@nat28.tlf.novell.com>
	<5049F4E9.9050306@canonical.com>
	<504A1A950200007800099D4C@nat28.tlf.novell.com>
	<20120907142251.GA20096@linuxtx.org>
	<504A32800200007800099E40@nat28.tlf.novell.com>
	<504A172B.5020005@canonical.com>
In-Reply-To: <504A172B.5020005@canonical.com>
Cc: Jan Beulich <JBeulich@suse.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"Justin M. Forbes" <jmforbes@linuxtx.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	xen-devel@lists.xen.org, Matt Wilson <msw@amazon.com>
Subject: Re: [Xen-devel] [PATCH/RFC] Fix xsave bug on older Xen hypervisors
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Il 07/09/2012 17:47, Stefan Bader ha scritto:
> 
> Legacy hypervisors (RHEL 5.0 and RHEL 5.1) do not handle guest writes to
> cr4 gracefully. If a guest attempts to write a bit of cr4 that is
> unsupported, then the HV is so offended it crashes the domain. While
> later guest kernels (such as RHEL6) don't assume the HV supports all
> features, they do expect nicer responses. That assumption introduced
> code that probes whether or not xsave is supported early in the boot. So
> now when attempting to boot a RHEL6 guest on RHEL5.0 or RHEL5.1 an early
> crash will occur.
> 
> This patch is quite obviously an undesirable hack. The real fix for this
> problem should be in the HV, and is, in later HVs. However, to support
> running on old HVs, RHEL6 can take this small change. No impact will
> occur for running on any RHEL HV (not even RHEL 5.5 supports xsave).
> There is only potential for guest performance loss on upstream Xen.
> 
> All this by way of explanation for why is this patch not going upstream.

If it is just 5.0 and 5.1, you can restrict the patch to Xen 3.0.

5.2 switched to Xen 3.1, which has been subsequently patched to death
without rebasing.

Paolo

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Sep 08 10:28:39 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 08 Sep 2012 10:28: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 1TAIH3-0000gX-3A; Sat, 08 Sep 2012 10:28:25 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <paolo.bonzini@gmail.com>) id 1TAIH1-0000gS-QW
	for xen-devel@lists.xen.org; Sat, 08 Sep 2012 10:28:24 +0000
Received: from [85.158.143.99:18212] by server-1.bemta-4.messagelabs.com id
	4A/AD-12504-7CD1B405; Sat, 08 Sep 2012 10:28:23 +0000
X-Env-Sender: paolo.bonzini@gmail.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1347100102!28913030!1
X-Originating-IP: [74.125.82.51]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29987 invoked from network); 8 Sep 2012 10:28:22 -0000
Received: from mail-wg0-f51.google.com (HELO mail-wg0-f51.google.com)
	(74.125.82.51)
	by server-5.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Sep 2012 10:28:22 -0000
Received: by wgbed3 with SMTP id ed3so274289wgb.32
	for <xen-devel@lists.xen.org>; Sat, 08 Sep 2012 03:28:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject
	:references:in-reply-to:content-type:content-transfer-encoding;
	bh=jYB5eBGgyqgEZx0kR0puQfa2ecKQrFv2RczXrM10em4=;
	b=GP/NN7jbRMX3q+MK69+E5A63mjRgTDXUurYXbb2KxaBNZmAhueIhy46ZN/frYVUEJG
	955MfSjash6nTGkFQdVJcy6caoQXfo/3TuZOQGHZhi2kV+9vc8q9x/tiJfzC7vKPXEC8
	sVQ3A6usgYdKxM130hS/UpL11vMjaOuCkR/ChvMbpXVbAZBjCjt0dhS9mF3dhh8C7Z8S
	Ve4is4B0tzyyp+zfDnA8kuVJ8z1wbxDo+DSALQJ2ZGSFk+f+PbEX1t65Fr24lh+OLYb5
	q6wuvNP40szIXCmdn3nitQD7dbTopQ3KpMnLj8gxsh8hcl4lMyYAUAdUw5gMgBZeoHJ0
	A9hQ==
Received: by 10.216.136.230 with SMTP id w80mr4922094wei.199.1347100102383;
	Sat, 08 Sep 2012 03:28:22 -0700 (PDT)
Received: from yakj.usersys.redhat.com (93-34-169-1.ip50.fastwebnet.it.
	[93.34.169.1])
	by mx.google.com with ESMTPS id el6sm4096051wib.8.2012.09.08.03.28.20
	(version=TLSv1/SSLv3 cipher=OTHER);
	Sat, 08 Sep 2012 03:28:21 -0700 (PDT)
Message-ID: <504B1DC3.1000604@redhat.com>
Date: Sat, 08 Sep 2012 12:28:19 +0200
From: Paolo Bonzini <pbonzini@redhat.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:14.0) Gecko/20120717 Thunderbird/14.0
MIME-Version: 1.0
To: Stefan Bader <stefan.bader@canonical.com>
References: <1347018043-21252-1-git-send-email-stefan.bader@canonical.com>
	<504A05B00200007800099C7B@nat28.tlf.novell.com>
	<5049F4E9.9050306@canonical.com>
	<504A1A950200007800099D4C@nat28.tlf.novell.com>
	<20120907142251.GA20096@linuxtx.org>
	<504A32800200007800099E40@nat28.tlf.novell.com>
	<504A172B.5020005@canonical.com>
	<504A347B0200007800099E92@nat28.tlf.novell.com>
	<504A1D43.2050909@canonical.com>
In-Reply-To: <504A1D43.2050909@canonical.com>
Cc: Jan Beulich <JBeulich@suse.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"Justin M. Forbes" <jmforbes@linuxtx.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	xen-devel@lists.xen.org, Matt Wilson <msw@amazon.com>
Subject: Re: [Xen-devel] [PATCH/RFC] Fix xsave bug on older Xen hypervisors
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Il 07/09/2012 18:13, Stefan Bader ha scritto:
> This would make it save again _if_ the HV failing to handle the writes to CR4
> (which iirc the kernel code still does when the cpuid bit is set) does have at
> least the patch to mask off the cpuid bits (the one Ian mentioned)

Given how old it is, that's very unlikely.  You can download CentOS 5.0
from http://mirror.stanford.edu/yum/pub/centos/5/isos/x86_64/ or get the
source RPM for the RHEL5.0 kernel (including the Xen hypervisor) at
ftp://ftp.redhat.com/redhat/linux/enterprise/5Client/en/os/SRPMS/kernel-2.6.18-8.el5.src.rpm

Paolo

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Sep 08 10:28:39 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 08 Sep 2012 10:28: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 1TAIH3-0000gX-3A; Sat, 08 Sep 2012 10:28:25 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <paolo.bonzini@gmail.com>) id 1TAIH1-0000gS-QW
	for xen-devel@lists.xen.org; Sat, 08 Sep 2012 10:28:24 +0000
Received: from [85.158.143.99:18212] by server-1.bemta-4.messagelabs.com id
	4A/AD-12504-7CD1B405; Sat, 08 Sep 2012 10:28:23 +0000
X-Env-Sender: paolo.bonzini@gmail.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1347100102!28913030!1
X-Originating-IP: [74.125.82.51]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29987 invoked from network); 8 Sep 2012 10:28:22 -0000
Received: from mail-wg0-f51.google.com (HELO mail-wg0-f51.google.com)
	(74.125.82.51)
	by server-5.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Sep 2012 10:28:22 -0000
Received: by wgbed3 with SMTP id ed3so274289wgb.32
	for <xen-devel@lists.xen.org>; Sat, 08 Sep 2012 03:28:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject
	:references:in-reply-to:content-type:content-transfer-encoding;
	bh=jYB5eBGgyqgEZx0kR0puQfa2ecKQrFv2RczXrM10em4=;
	b=GP/NN7jbRMX3q+MK69+E5A63mjRgTDXUurYXbb2KxaBNZmAhueIhy46ZN/frYVUEJG
	955MfSjash6nTGkFQdVJcy6caoQXfo/3TuZOQGHZhi2kV+9vc8q9x/tiJfzC7vKPXEC8
	sVQ3A6usgYdKxM130hS/UpL11vMjaOuCkR/ChvMbpXVbAZBjCjt0dhS9mF3dhh8C7Z8S
	Ve4is4B0tzyyp+zfDnA8kuVJ8z1wbxDo+DSALQJ2ZGSFk+f+PbEX1t65Fr24lh+OLYb5
	q6wuvNP40szIXCmdn3nitQD7dbTopQ3KpMnLj8gxsh8hcl4lMyYAUAdUw5gMgBZeoHJ0
	A9hQ==
Received: by 10.216.136.230 with SMTP id w80mr4922094wei.199.1347100102383;
	Sat, 08 Sep 2012 03:28:22 -0700 (PDT)
Received: from yakj.usersys.redhat.com (93-34-169-1.ip50.fastwebnet.it.
	[93.34.169.1])
	by mx.google.com with ESMTPS id el6sm4096051wib.8.2012.09.08.03.28.20
	(version=TLSv1/SSLv3 cipher=OTHER);
	Sat, 08 Sep 2012 03:28:21 -0700 (PDT)
Message-ID: <504B1DC3.1000604@redhat.com>
Date: Sat, 08 Sep 2012 12:28:19 +0200
From: Paolo Bonzini <pbonzini@redhat.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:14.0) Gecko/20120717 Thunderbird/14.0
MIME-Version: 1.0
To: Stefan Bader <stefan.bader@canonical.com>
References: <1347018043-21252-1-git-send-email-stefan.bader@canonical.com>
	<504A05B00200007800099C7B@nat28.tlf.novell.com>
	<5049F4E9.9050306@canonical.com>
	<504A1A950200007800099D4C@nat28.tlf.novell.com>
	<20120907142251.GA20096@linuxtx.org>
	<504A32800200007800099E40@nat28.tlf.novell.com>
	<504A172B.5020005@canonical.com>
	<504A347B0200007800099E92@nat28.tlf.novell.com>
	<504A1D43.2050909@canonical.com>
In-Reply-To: <504A1D43.2050909@canonical.com>
Cc: Jan Beulich <JBeulich@suse.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"Justin M. Forbes" <jmforbes@linuxtx.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	xen-devel@lists.xen.org, Matt Wilson <msw@amazon.com>
Subject: Re: [Xen-devel] [PATCH/RFC] Fix xsave bug on older Xen hypervisors
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Il 07/09/2012 18:13, Stefan Bader ha scritto:
> This would make it save again _if_ the HV failing to handle the writes to CR4
> (which iirc the kernel code still does when the cpuid bit is set) does have at
> least the patch to mask off the cpuid bits (the one Ian mentioned)

Given how old it is, that's very unlikely.  You can download CentOS 5.0
from http://mirror.stanford.edu/yum/pub/centos/5/isos/x86_64/ or get the
source RPM for the RHEL5.0 kernel (including the Xen hypervisor) at
ftp://ftp.redhat.com/redhat/linux/enterprise/5Client/en/os/SRPMS/kernel-2.6.18-8.el5.src.rpm

Paolo

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Sep 08 12:23:43 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 08 Sep 2012 12:23:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TAK48-0001oU-Md; Sat, 08 Sep 2012 12:23:12 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ben.guthro@gmail.com>) id 1TAK47-0001oM-S4
	for xen-devel@lists.xen.org; Sat, 08 Sep 2012 12:23:12 +0000
X-Env-Sender: ben.guthro@gmail.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1347106984!4561663!1
X-Originating-IP: [209.85.210.173]
X-SpamReason: No, hits=0.9 required=7.0 tests=HTML_40_50,HTML_MESSAGE,
	RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7730 invoked from network); 8 Sep 2012 12:23:05 -0000
Received: from mail-iy0-f173.google.com (HELO mail-iy0-f173.google.com)
	(209.85.210.173)
	by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Sep 2012 12:23:05 -0000
Received: by iakx26 with SMTP id x26so484448iak.32
	for <xen-devel@lists.xen.org>; Sat, 08 Sep 2012 05:23:04 -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=0h52s449wMsvrSXVTqdHDOkWWZN3bxMMwxbieEBJajo=;
	b=gO23ds6To/K3kmoMp8A9hFmJ2xuATnJHbkaDCH2IlkMdM1UY0luEE1ew/xfANhdgoa
	kRq1a4SeGQx40Ce33XGs/IXMVo//FD9aTuwBXIV2AAdz7GTjq625xNg+6dBUoVOoN25Z
	SQBIxlCYyyCFT2og3L1auXHIe2o386LQDa5RhiIzPjjdUutuXMnw4XUPyb35APzEeUzq
	Ptbwp+6C3yhTDcnLsHRQu+VQq/QI31lwj7MxPuWKulTBIIiWvHXXdXsXqUxjiZRO23Io
	fofhi55AVHaVMn20q3QYPU6E8JWiO0REagXdcciFkHPR++IbB6oKnCYC94CXcxwNAczj
	TkJg==
MIME-Version: 1.0
Received: by 10.50.180.129 with SMTP id do1mr2313105igc.28.1347106984002; Sat,
	08 Sep 2012 05:23:04 -0700 (PDT)
Received: by 10.64.28.203 with HTTP; Sat, 8 Sep 2012 05:23:03 -0700 (PDT)
In-Reply-To: <502E212E.6070306@citrix.com>
References: <502E212E.6070306@citrix.com>
Date: Sat, 8 Sep 2012 08:23:03 -0400
X-Google-Sender-Auth: huqDawpy9xcfSOrBhe2ciL1x6mI
Message-ID: <CAOvdn6WD31pQVbZNSMc8JTKfNQKOEWUkHpvpqPq=kcAUBC5QHQ@mail.gmail.com>
From: Ben Guthro <ben@guthro.net>
To: Anthony PERARD <anthony.perard@citrix.com>
Cc: Xen Devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [ANNOUNCE] Git mirror of Xen repositories available
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============4733258323953169297=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============4733258323953169297==
Content-Type: multipart/alternative; boundary=14dae9340a7541851004c92fc964

--14dae9340a7541851004c92fc964
Content-Type: text/plain; charset=ISO-8859-1

Anthony -

Will this git mirror pick up a stable-4.2 branch, now that the
xen-4.2-testing.hg branch has been forked off?

Thanks for your efforts here.

Ben

On Fri, Aug 17, 2012 at 6:47 AM, Anthony PERARD
<anthony.perard@citrix.com>wrote:

> Hi everyone,
>
> I'm pleased to announce that a Git mirror repository is now available (and
> up-to-date). This one contains several branches:
>
>  * master --> xen-unstable.hg
>  * staging --> staging/xen-unstable.hg
>  * stable-4.0 --> xen-4.0-testing.hg
>  * stable-4.1 --> xen-4.1-testing.hg
>
> http://xenbits.xen.org/gitweb/**?p=xen.git<http://xenbits.xen.org/gitweb/?p=xen.git>
> git://xenbits.xen.org/xen.git
>
> Regards,
>
> --
> Anthony PERARD
>
> ______________________________**_________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
>

--14dae9340a7541851004c92fc964
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Anthony -=A0<div><br></div><div>Will this git mirror pick up a stable-4.2 b=
ranch, now that the xen-4.2-testing.hg branch has been forked off?</div><di=
v><br></div><div>Thanks for your efforts here.</div><div><br></div><div>Ben=
<br>
<br><div class=3D"gmail_quote">On Fri, Aug 17, 2012 at 6:47 AM, Anthony PER=
ARD <span dir=3D"ltr">&lt;<a href=3D"mailto:anthony.perard@citrix.com" targ=
et=3D"_blank">anthony.perard@citrix.com</a>&gt;</span> wrote:<br><blockquot=
e class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc sol=
id;padding-left:1ex">
Hi everyone,<br>
<br>
I&#39;m pleased to announce that a Git mirror repository is now available (=
and up-to-date). This one contains several branches:<br>
<br>
=A0* master --&gt; xen-unstable.hg<br>
=A0* staging --&gt; staging/xen-unstable.hg<br>
=A0* stable-4.0 --&gt; xen-4.0-testing.hg<br>
=A0* stable-4.1 --&gt; xen-4.1-testing.hg<br>
<br>
<a href=3D"http://xenbits.xen.org/gitweb/?p=3Dxen.git" target=3D"_blank">ht=
tp://xenbits.xen.org/gitweb/<u></u>?p=3Dxen.git</a><br>
git://<a href=3D"http://xenbits.xen.org/xen.git" target=3D"_blank">xenbits.=
xen.org/xen.git</a><br>
<br>
Regards,<span class=3D"HOEnZb"><font color=3D"#888888"><br>
<br>
-- <br>
Anthony PERARD<br>
<br>
______________________________<u></u>_________________<br>
Xen-devel mailing list<br>
<a href=3D"mailto:Xen-devel@lists.xen.org" target=3D"_blank">Xen-devel@list=
s.xen.org</a><br>
<a href=3D"http://lists.xen.org/xen-devel" target=3D"_blank">http://lists.x=
en.org/xen-devel</a><br>
</font></span></blockquote></div><br></div>

--14dae9340a7541851004c92fc964--


--===============4733258323953169297==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============4733258323953169297==--


From xen-devel-bounces@lists.xen.org Sat Sep 08 12:23:43 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 08 Sep 2012 12:23:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TAK48-0001oU-Md; Sat, 08 Sep 2012 12:23:12 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ben.guthro@gmail.com>) id 1TAK47-0001oM-S4
	for xen-devel@lists.xen.org; Sat, 08 Sep 2012 12:23:12 +0000
X-Env-Sender: ben.guthro@gmail.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1347106984!4561663!1
X-Originating-IP: [209.85.210.173]
X-SpamReason: No, hits=0.9 required=7.0 tests=HTML_40_50,HTML_MESSAGE,
	RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7730 invoked from network); 8 Sep 2012 12:23:05 -0000
Received: from mail-iy0-f173.google.com (HELO mail-iy0-f173.google.com)
	(209.85.210.173)
	by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Sep 2012 12:23:05 -0000
Received: by iakx26 with SMTP id x26so484448iak.32
	for <xen-devel@lists.xen.org>; Sat, 08 Sep 2012 05:23:04 -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=0h52s449wMsvrSXVTqdHDOkWWZN3bxMMwxbieEBJajo=;
	b=gO23ds6To/K3kmoMp8A9hFmJ2xuATnJHbkaDCH2IlkMdM1UY0luEE1ew/xfANhdgoa
	kRq1a4SeGQx40Ce33XGs/IXMVo//FD9aTuwBXIV2AAdz7GTjq625xNg+6dBUoVOoN25Z
	SQBIxlCYyyCFT2og3L1auXHIe2o386LQDa5RhiIzPjjdUutuXMnw4XUPyb35APzEeUzq
	Ptbwp+6C3yhTDcnLsHRQu+VQq/QI31lwj7MxPuWKulTBIIiWvHXXdXsXqUxjiZRO23Io
	fofhi55AVHaVMn20q3QYPU6E8JWiO0REagXdcciFkHPR++IbB6oKnCYC94CXcxwNAczj
	TkJg==
MIME-Version: 1.0
Received: by 10.50.180.129 with SMTP id do1mr2313105igc.28.1347106984002; Sat,
	08 Sep 2012 05:23:04 -0700 (PDT)
Received: by 10.64.28.203 with HTTP; Sat, 8 Sep 2012 05:23:03 -0700 (PDT)
In-Reply-To: <502E212E.6070306@citrix.com>
References: <502E212E.6070306@citrix.com>
Date: Sat, 8 Sep 2012 08:23:03 -0400
X-Google-Sender-Auth: huqDawpy9xcfSOrBhe2ciL1x6mI
Message-ID: <CAOvdn6WD31pQVbZNSMc8JTKfNQKOEWUkHpvpqPq=kcAUBC5QHQ@mail.gmail.com>
From: Ben Guthro <ben@guthro.net>
To: Anthony PERARD <anthony.perard@citrix.com>
Cc: Xen Devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [ANNOUNCE] Git mirror of Xen repositories available
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============4733258323953169297=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============4733258323953169297==
Content-Type: multipart/alternative; boundary=14dae9340a7541851004c92fc964

--14dae9340a7541851004c92fc964
Content-Type: text/plain; charset=ISO-8859-1

Anthony -

Will this git mirror pick up a stable-4.2 branch, now that the
xen-4.2-testing.hg branch has been forked off?

Thanks for your efforts here.

Ben

On Fri, Aug 17, 2012 at 6:47 AM, Anthony PERARD
<anthony.perard@citrix.com>wrote:

> Hi everyone,
>
> I'm pleased to announce that a Git mirror repository is now available (and
> up-to-date). This one contains several branches:
>
>  * master --> xen-unstable.hg
>  * staging --> staging/xen-unstable.hg
>  * stable-4.0 --> xen-4.0-testing.hg
>  * stable-4.1 --> xen-4.1-testing.hg
>
> http://xenbits.xen.org/gitweb/**?p=xen.git<http://xenbits.xen.org/gitweb/?p=xen.git>
> git://xenbits.xen.org/xen.git
>
> Regards,
>
> --
> Anthony PERARD
>
> ______________________________**_________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
>

--14dae9340a7541851004c92fc964
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Anthony -=A0<div><br></div><div>Will this git mirror pick up a stable-4.2 b=
ranch, now that the xen-4.2-testing.hg branch has been forked off?</div><di=
v><br></div><div>Thanks for your efforts here.</div><div><br></div><div>Ben=
<br>
<br><div class=3D"gmail_quote">On Fri, Aug 17, 2012 at 6:47 AM, Anthony PER=
ARD <span dir=3D"ltr">&lt;<a href=3D"mailto:anthony.perard@citrix.com" targ=
et=3D"_blank">anthony.perard@citrix.com</a>&gt;</span> wrote:<br><blockquot=
e class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc sol=
id;padding-left:1ex">
Hi everyone,<br>
<br>
I&#39;m pleased to announce that a Git mirror repository is now available (=
and up-to-date). This one contains several branches:<br>
<br>
=A0* master --&gt; xen-unstable.hg<br>
=A0* staging --&gt; staging/xen-unstable.hg<br>
=A0* stable-4.0 --&gt; xen-4.0-testing.hg<br>
=A0* stable-4.1 --&gt; xen-4.1-testing.hg<br>
<br>
<a href=3D"http://xenbits.xen.org/gitweb/?p=3Dxen.git" target=3D"_blank">ht=
tp://xenbits.xen.org/gitweb/<u></u>?p=3Dxen.git</a><br>
git://<a href=3D"http://xenbits.xen.org/xen.git" target=3D"_blank">xenbits.=
xen.org/xen.git</a><br>
<br>
Regards,<span class=3D"HOEnZb"><font color=3D"#888888"><br>
<br>
-- <br>
Anthony PERARD<br>
<br>
______________________________<u></u>_________________<br>
Xen-devel mailing list<br>
<a href=3D"mailto:Xen-devel@lists.xen.org" target=3D"_blank">Xen-devel@list=
s.xen.org</a><br>
<a href=3D"http://lists.xen.org/xen-devel" target=3D"_blank">http://lists.x=
en.org/xen-devel</a><br>
</font></span></blockquote></div><br></div>

--14dae9340a7541851004c92fc964--


--===============4733258323953169297==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============4733258323953169297==--


From xen-devel-bounces@lists.xen.org Sat Sep 08 12:26:39 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 08 Sep 2012 12:26:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TAK76-0001tz-9s; Sat, 08 Sep 2012 12:26:16 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <glguida@cr3.tlbflush.org>) id 1TAK75-0001ts-BR
	for xen-devel@lists.xen.org; Sat, 08 Sep 2012 12:26:15 +0000
Received: from [85.158.143.99:45377] by server-1.bemta-4.messagelabs.com id
	54/C5-12504-6693B405; Sat, 08 Sep 2012 12:26:14 +0000
X-Env-Sender: glguida@cr3.tlbflush.org
X-Msg-Ref: server-5.tower-216.messagelabs.com!1347107173!28922394!1
X-Originating-IP: [72.52.97.68]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15790 invoked from network); 8 Sep 2012 12:26:13 -0000
Received: from unknown (HELO invlpg.tlbflush.org) (72.52.97.68)
	by server-5.tower-216.messagelabs.com with SMTP;
	8 Sep 2012 12:26:13 -0000
Received: by invlpg.tlbflush.org (Postfix, from userid 66)
	id D646A11947C; Fri,  7 Sep 2012 16:02:03 -0700 (PDT)
Received: by cr3.tlbflush.org (Postfix, from userid 1000)
	id 933A97E9431; Sat,  8 Sep 2012 14:26:28 +0200 (CEST)
Date: Sat, 8 Sep 2012 14:26:28 +0200
From: Gianluca Guida <glguida@tlbflush.org>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120908122628.GA545@cr3>
References: <1347027296.30018.108.camel@zakaz.uk.xensource.com>
	<504A2D710200007800099E11@nat28.tlf.novell.com>
	<1347032363.30018.120.camel@zakaz.uk.xensource.com>
	<504A33930200007800099E5A@nat28.tlf.novell.com>
	<1347033075.30018.128.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1347033075.30018.128.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: Jan Beulich <JBeulich@suse.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.2 new features and status -- please help me
 make a list
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Sep 07, 2012 at 04:51:15PM +0100, Ian Campbell wrote:
> On Fri, 2012-09-07 at 16:49 +0100, Jan Beulich wrote:
> > >>> On 07.09.12 at 17:39, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> > >> > vMSI: ? Emulated (or real?) MSIs for guests?
> > >> >         State? New in 4.2?
> > >> 
> > >> Not sure what you're referring to here. There certainly was a
> > >> xen/arch/x86/hvm/vmsi.c in 4.1 already.
> > > 
> > > OK, thanks. 4.0 too by the looks of it.
> > > 
> > > What exactly is this? Is it about injection of MSIs from real
> > > (passthrough) hardware devices to guests (only HVM ones?) or is about
> > > MSIs generated by emulated devices (or both)?
> > 
> > I don't think emulated devices genera MSIs, so to me this is
> > just for passthrough. But I may be wrong.
> 
> It sounds plausible to me ;-)

There is in 4.2 an HVM op to generate MSIs from emulated devices, added
at changeset 23413.
The passthrough part was already present before.

Thanks,
Gianluca

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Sep 08 12:26:39 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 08 Sep 2012 12:26:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TAK76-0001tz-9s; Sat, 08 Sep 2012 12:26:16 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <glguida@cr3.tlbflush.org>) id 1TAK75-0001ts-BR
	for xen-devel@lists.xen.org; Sat, 08 Sep 2012 12:26:15 +0000
Received: from [85.158.143.99:45377] by server-1.bemta-4.messagelabs.com id
	54/C5-12504-6693B405; Sat, 08 Sep 2012 12:26:14 +0000
X-Env-Sender: glguida@cr3.tlbflush.org
X-Msg-Ref: server-5.tower-216.messagelabs.com!1347107173!28922394!1
X-Originating-IP: [72.52.97.68]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15790 invoked from network); 8 Sep 2012 12:26:13 -0000
Received: from unknown (HELO invlpg.tlbflush.org) (72.52.97.68)
	by server-5.tower-216.messagelabs.com with SMTP;
	8 Sep 2012 12:26:13 -0000
Received: by invlpg.tlbflush.org (Postfix, from userid 66)
	id D646A11947C; Fri,  7 Sep 2012 16:02:03 -0700 (PDT)
Received: by cr3.tlbflush.org (Postfix, from userid 1000)
	id 933A97E9431; Sat,  8 Sep 2012 14:26:28 +0200 (CEST)
Date: Sat, 8 Sep 2012 14:26:28 +0200
From: Gianluca Guida <glguida@tlbflush.org>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120908122628.GA545@cr3>
References: <1347027296.30018.108.camel@zakaz.uk.xensource.com>
	<504A2D710200007800099E11@nat28.tlf.novell.com>
	<1347032363.30018.120.camel@zakaz.uk.xensource.com>
	<504A33930200007800099E5A@nat28.tlf.novell.com>
	<1347033075.30018.128.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1347033075.30018.128.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: Jan Beulich <JBeulich@suse.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.2 new features and status -- please help me
 make a list
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Sep 07, 2012 at 04:51:15PM +0100, Ian Campbell wrote:
> On Fri, 2012-09-07 at 16:49 +0100, Jan Beulich wrote:
> > >>> On 07.09.12 at 17:39, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> > >> > vMSI: ? Emulated (or real?) MSIs for guests?
> > >> >         State? New in 4.2?
> > >> 
> > >> Not sure what you're referring to here. There certainly was a
> > >> xen/arch/x86/hvm/vmsi.c in 4.1 already.
> > > 
> > > OK, thanks. 4.0 too by the looks of it.
> > > 
> > > What exactly is this? Is it about injection of MSIs from real
> > > (passthrough) hardware devices to guests (only HVM ones?) or is about
> > > MSIs generated by emulated devices (or both)?
> > 
> > I don't think emulated devices genera MSIs, so to me this is
> > just for passthrough. But I may be wrong.
> 
> It sounds plausible to me ;-)

There is in 4.2 an HVM op to generate MSIs from emulated devices, added
at changeset 23413.
The passthrough part was already present before.

Thanks,
Gianluca

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Sep 08 20:55:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 08 Sep 2012 20: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 1TAS2o-0006VI-OO; Sat, 08 Sep 2012 20:54:22 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <giamteckchoon@gmail.com>) id 1TAS2n-0006VD-5h
	for xen-devel@lists.xen.org; Sat, 08 Sep 2012 20:54:21 +0000
X-Env-Sender: giamteckchoon@gmail.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1347137653!8767801!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-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27618 invoked from network); 8 Sep 2012 20:54:14 -0000
Received: from mail-pb0-f45.google.com (HELO mail-pb0-f45.google.com)
	(209.85.160.45)
	by server-16.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Sep 2012 20:54:14 -0000
Received: by pbbjt11 with SMTP id jt11so1159161pbb.32
	for <xen-devel@lists.xen.org>; Sat, 08 Sep 2012 13:54:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=kBNWlmTP5j0dgmwxh3rII7u7sQ/PsPRcrNdA4KbfQds=;
	b=TJUPcOWfS6/cFvLGF4QCr1ZXq2RHPifxYt3fPRlSCX7tlvVivuHw9TJTmI+8uq5C5S
	5mlfiALTbfnpGAJVV6CXT4rkzt6j8+QhCDEHL/gM36cBFtPtfCXToV7oiMhfXMSghO71
	ZY2zZVQviJzHBiWMnOERcwuv3JyRZTUvFbLFD+zQIlu88tRayUB/Ni3JygVpwREjLMyu
	d2/5un7sqKYud23TMJ03EXRz9yx8kJAPZ8bYGATu70dgcZYbr3UlUuy3EQJXHnNACnDP
	kj/AecrXJJ4YzbwiuD+T8u3fktSOta2ONBGMo3qpeskleDtrIbDb8OFeynWNXxgr7cIo
	Zkzg==
MIME-Version: 1.0
Received: by 10.68.225.233 with SMTP id rn9mr17141088pbc.135.1347137652543;
	Sat, 08 Sep 2012 13:54:12 -0700 (PDT)
Received: by 10.68.212.39 with HTTP; Sat, 8 Sep 2012 13:54:12 -0700 (PDT)
In-Reply-To: <CC6F9E70.3E07C%keir.xen@gmail.com>
References: <CC6F9E70.3E07C%keir.xen@gmail.com>
Date: Sun, 9 Sep 2012 04:54:12 +0800
Message-ID: <CAEwRVpNTkyTO8-=Uca1L_na1_hGDf2awfPkJNKTQ+0QdykPtSg@mail.gmail.com>
From: Teck Choon Giam <giamteckchoon@gmail.com>
To: Keir Fraser <keir.xen@gmail.com>
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [ANNOUNCE] Xen 4.2.0 RC4 tagged
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Sep 7, 2012 at 7:52 PM, Keir Fraser <keir.xen@gmail.com> wrote:
> Folks,
>
> The fourth release candidate is now available:
>
> http://xenbits.xen.org/stagiung/xen-4.2-testing.hg (tag '4.2.0-rc4')

I guess you mean:

http://xenbits.xen.org/hg/staging/xen-4.2-testing.hg/

Thanks.

Kindest regards,
Giam Teck Choon


>
> We plan to release a week on Monday. So please test this one!
>
>  -- Keir
>
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Sep 08 20:55:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 08 Sep 2012 20: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 1TAS2o-0006VI-OO; Sat, 08 Sep 2012 20:54:22 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <giamteckchoon@gmail.com>) id 1TAS2n-0006VD-5h
	for xen-devel@lists.xen.org; Sat, 08 Sep 2012 20:54:21 +0000
X-Env-Sender: giamteckchoon@gmail.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1347137653!8767801!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-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27618 invoked from network); 8 Sep 2012 20:54:14 -0000
Received: from mail-pb0-f45.google.com (HELO mail-pb0-f45.google.com)
	(209.85.160.45)
	by server-16.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Sep 2012 20:54:14 -0000
Received: by pbbjt11 with SMTP id jt11so1159161pbb.32
	for <xen-devel@lists.xen.org>; Sat, 08 Sep 2012 13:54:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=kBNWlmTP5j0dgmwxh3rII7u7sQ/PsPRcrNdA4KbfQds=;
	b=TJUPcOWfS6/cFvLGF4QCr1ZXq2RHPifxYt3fPRlSCX7tlvVivuHw9TJTmI+8uq5C5S
	5mlfiALTbfnpGAJVV6CXT4rkzt6j8+QhCDEHL/gM36cBFtPtfCXToV7oiMhfXMSghO71
	ZY2zZVQviJzHBiWMnOERcwuv3JyRZTUvFbLFD+zQIlu88tRayUB/Ni3JygVpwREjLMyu
	d2/5un7sqKYud23TMJ03EXRz9yx8kJAPZ8bYGATu70dgcZYbr3UlUuy3EQJXHnNACnDP
	kj/AecrXJJ4YzbwiuD+T8u3fktSOta2ONBGMo3qpeskleDtrIbDb8OFeynWNXxgr7cIo
	Zkzg==
MIME-Version: 1.0
Received: by 10.68.225.233 with SMTP id rn9mr17141088pbc.135.1347137652543;
	Sat, 08 Sep 2012 13:54:12 -0700 (PDT)
Received: by 10.68.212.39 with HTTP; Sat, 8 Sep 2012 13:54:12 -0700 (PDT)
In-Reply-To: <CC6F9E70.3E07C%keir.xen@gmail.com>
References: <CC6F9E70.3E07C%keir.xen@gmail.com>
Date: Sun, 9 Sep 2012 04:54:12 +0800
Message-ID: <CAEwRVpNTkyTO8-=Uca1L_na1_hGDf2awfPkJNKTQ+0QdykPtSg@mail.gmail.com>
From: Teck Choon Giam <giamteckchoon@gmail.com>
To: Keir Fraser <keir.xen@gmail.com>
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [ANNOUNCE] Xen 4.2.0 RC4 tagged
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Sep 7, 2012 at 7:52 PM, Keir Fraser <keir.xen@gmail.com> wrote:
> Folks,
>
> The fourth release candidate is now available:
>
> http://xenbits.xen.org/stagiung/xen-4.2-testing.hg (tag '4.2.0-rc4')

I guess you mean:

http://xenbits.xen.org/hg/staging/xen-4.2-testing.hg/

Thanks.

Kindest regards,
Giam Teck Choon


>
> We plan to release a week on Monday. So please test this one!
>
>  -- Keir
>
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Sep 09 06:34:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 09 Sep 2012 06:34:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TAb5F-0007FN-Gu; Sun, 09 Sep 2012 06:33:29 +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 1TAb5E-0007FI-17
	for xen-devel@lists.xen.org; Sun, 09 Sep 2012 06:33:28 +0000
Received: from [85.158.143.35:39431] by server-3.bemta-4.messagelabs.com id
	E8/10-08232-7383C405; Sun, 09 Sep 2012 06:33:27 +0000
X-Env-Sender: ddebroy@gmail.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1347172405!14857516!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-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17617 invoked from network); 9 Sep 2012 06:33:26 -0000
Received: from mail-qc0-f173.google.com (HELO mail-qc0-f173.google.com)
	(209.85.216.173)
	by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Sep 2012 06:33:26 -0000
Received: by qcab12 with SMTP id b12so737079qca.32
	for <xen-devel@lists.xen.org>; Sat, 08 Sep 2012 23:33: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
	:content-type; bh=qHZ965SKyp86kUfBtPAQpfPWpAiBt3XUoFXiCQMdMwI=;
	b=XH6Hz3s2d/VP32lzVeQOBTFNGE4Am2ssBkdBQHtVZ9jKpCfLgg6fKY5eF1M3m5zpT/
	D6PYS6mYDES/MrBeJnS2Xc5tElKkcm+XYp0N7bS+x+N3j2B5SU2t9gW4XGIwvJPK9bi8
	Qy6IzmCfMJfTMQL2Ydy0BCDQvl7IUblcQWhpQJh24vDrYnWroACXXXs7C7U09jGdwP6N
	6/w5qlmTRShUpdCQ4uoDnjKbrpsbJ54lF/ee0XXHVslMI4FlOlS4VfCtqWaZ7+vllvEB
	4flTC0x7ryDNkHkSVqqlj/2d8WjzFiZ6U/m4/23H9TNxaSCJkR5lwL2s4Ej+qfCsunhm
	1Bkg==
MIME-Version: 1.0
Received: by 10.229.135.134 with SMTP id n6mr3185117qct.140.1347172405459;
	Sat, 08 Sep 2012 23:33:25 -0700 (PDT)
Received: by 10.49.59.8 with HTTP; Sat, 8 Sep 2012 23:33:25 -0700 (PDT)
In-Reply-To: <20120908122628.GA545@cr3>
References: <1347027296.30018.108.camel@zakaz.uk.xensource.com>
	<504A2D710200007800099E11@nat28.tlf.novell.com>
	<1347032363.30018.120.camel@zakaz.uk.xensource.com>
	<504A33930200007800099E5A@nat28.tlf.novell.com>
	<1347033075.30018.128.camel@zakaz.uk.xensource.com>
	<20120908122628.GA545@cr3>
Date: Sat, 8 Sep 2012 23:33:25 -0700
Message-ID: <CABg=H3NfPqDFkrJBeyfTy0sWhbYDnrR2dQnPg18gRrYJ0FeYCA@mail.gmail.com>
From: Deep Debroy <ddebroy@gmail.com>
To: Gianluca Guida <glguida@tlbflush.org>, xen-devel <xen-devel@lists.xen.org>,
	Ian Campbell <Ian.Campbell@citrix.com>, Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] Xen 4.2 new features and status -- please help me
 make a list
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Sat, Sep 8, 2012 at 5:26 AM, Gianluca Guida <glguida@tlbflush.org> wrote:
>
> On Fri, Sep 07, 2012 at 04:51:15PM +0100, Ian Campbell wrote:
> > On Fri, 2012-09-07 at 16:49 +0100, Jan Beulich wrote:
> > > >>> On 07.09.12 at 17:39, Ian Campbell <Ian.Campbell@citrix.com>
> > > >>> wrote:
> > > >> > vMSI: ? Emulated (or real?) MSIs for guests?
> > > >> >         State? New in 4.2?
> > > >>
> > > >> Not sure what you're referring to here. There certainly was a
> > > >> xen/arch/x86/hvm/vmsi.c in 4.1 already.
> > > >
> > > > OK, thanks. 4.0 too by the looks of it.
> > > >
> > > > What exactly is this? Is it about injection of MSIs from real
> > > > (passthrough) hardware devices to guests (only HVM ones?) or is
> > > > about
> > > > MSIs generated by emulated devices (or both)?
> > >
> > > I don't think emulated devices genera MSIs, so to me this is
> > > just for passthrough. But I may be wrong.
> >
> > It sounds plausible to me ;-)
>
> There is in 4.2 an HVM op to generate MSIs from emulated devices, added
> at changeset 23413.
> The passthrough part was already present before.

Quick clarification about emulated devices using MSI: the emulation of
vmware's paravirtualized scsi controller, pvscsi, in qemu (submitted
as patches but not in the official qemu tree yet) uses MSI. Changeset
25588 was necessary in xen to get MSIs to flow from the pvscsi
emulation in qemu to xen vms running the upstream vmware pvscsi driver
in the linux kernel.

Thanks,
Deep

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Sep 09 06:34:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 09 Sep 2012 06:34:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TAb5F-0007FN-Gu; Sun, 09 Sep 2012 06:33:29 +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 1TAb5E-0007FI-17
	for xen-devel@lists.xen.org; Sun, 09 Sep 2012 06:33:28 +0000
Received: from [85.158.143.35:39431] by server-3.bemta-4.messagelabs.com id
	E8/10-08232-7383C405; Sun, 09 Sep 2012 06:33:27 +0000
X-Env-Sender: ddebroy@gmail.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1347172405!14857516!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-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17617 invoked from network); 9 Sep 2012 06:33:26 -0000
Received: from mail-qc0-f173.google.com (HELO mail-qc0-f173.google.com)
	(209.85.216.173)
	by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Sep 2012 06:33:26 -0000
Received: by qcab12 with SMTP id b12so737079qca.32
	for <xen-devel@lists.xen.org>; Sat, 08 Sep 2012 23:33: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
	:content-type; bh=qHZ965SKyp86kUfBtPAQpfPWpAiBt3XUoFXiCQMdMwI=;
	b=XH6Hz3s2d/VP32lzVeQOBTFNGE4Am2ssBkdBQHtVZ9jKpCfLgg6fKY5eF1M3m5zpT/
	D6PYS6mYDES/MrBeJnS2Xc5tElKkcm+XYp0N7bS+x+N3j2B5SU2t9gW4XGIwvJPK9bi8
	Qy6IzmCfMJfTMQL2Ydy0BCDQvl7IUblcQWhpQJh24vDrYnWroACXXXs7C7U09jGdwP6N
	6/w5qlmTRShUpdCQ4uoDnjKbrpsbJ54lF/ee0XXHVslMI4FlOlS4VfCtqWaZ7+vllvEB
	4flTC0x7ryDNkHkSVqqlj/2d8WjzFiZ6U/m4/23H9TNxaSCJkR5lwL2s4Ej+qfCsunhm
	1Bkg==
MIME-Version: 1.0
Received: by 10.229.135.134 with SMTP id n6mr3185117qct.140.1347172405459;
	Sat, 08 Sep 2012 23:33:25 -0700 (PDT)
Received: by 10.49.59.8 with HTTP; Sat, 8 Sep 2012 23:33:25 -0700 (PDT)
In-Reply-To: <20120908122628.GA545@cr3>
References: <1347027296.30018.108.camel@zakaz.uk.xensource.com>
	<504A2D710200007800099E11@nat28.tlf.novell.com>
	<1347032363.30018.120.camel@zakaz.uk.xensource.com>
	<504A33930200007800099E5A@nat28.tlf.novell.com>
	<1347033075.30018.128.camel@zakaz.uk.xensource.com>
	<20120908122628.GA545@cr3>
Date: Sat, 8 Sep 2012 23:33:25 -0700
Message-ID: <CABg=H3NfPqDFkrJBeyfTy0sWhbYDnrR2dQnPg18gRrYJ0FeYCA@mail.gmail.com>
From: Deep Debroy <ddebroy@gmail.com>
To: Gianluca Guida <glguida@tlbflush.org>, xen-devel <xen-devel@lists.xen.org>,
	Ian Campbell <Ian.Campbell@citrix.com>, Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] Xen 4.2 new features and status -- please help me
 make a list
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Sat, Sep 8, 2012 at 5:26 AM, Gianluca Guida <glguida@tlbflush.org> wrote:
>
> On Fri, Sep 07, 2012 at 04:51:15PM +0100, Ian Campbell wrote:
> > On Fri, 2012-09-07 at 16:49 +0100, Jan Beulich wrote:
> > > >>> On 07.09.12 at 17:39, Ian Campbell <Ian.Campbell@citrix.com>
> > > >>> wrote:
> > > >> > vMSI: ? Emulated (or real?) MSIs for guests?
> > > >> >         State? New in 4.2?
> > > >>
> > > >> Not sure what you're referring to here. There certainly was a
> > > >> xen/arch/x86/hvm/vmsi.c in 4.1 already.
> > > >
> > > > OK, thanks. 4.0 too by the looks of it.
> > > >
> > > > What exactly is this? Is it about injection of MSIs from real
> > > > (passthrough) hardware devices to guests (only HVM ones?) or is
> > > > about
> > > > MSIs generated by emulated devices (or both)?
> > >
> > > I don't think emulated devices genera MSIs, so to me this is
> > > just for passthrough. But I may be wrong.
> >
> > It sounds plausible to me ;-)
>
> There is in 4.2 an HVM op to generate MSIs from emulated devices, added
> at changeset 23413.
> The passthrough part was already present before.

Quick clarification about emulated devices using MSI: the emulation of
vmware's paravirtualized scsi controller, pvscsi, in qemu (submitted
as patches but not in the official qemu tree yet) uses MSI. Changeset
25588 was necessary in xen to get MSIs to flow from the pvscsi
emulation in qemu to xen vms running the upstream vmware pvscsi driver
in the linux kernel.

Thanks,
Deep

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Sep 09 10:27:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 09 Sep 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 1TAeij-000191-9e; Sun, 09 Sep 2012 10:26:29 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <aware.why@gmail.com>) id 1TAeih-00018w-IG
	for xen-devel@lists.xensource.com; Sun, 09 Sep 2012 10:26:27 +0000
Received: from [85.158.139.83:15977] by server-7.bemta-5.messagelabs.com id
	72/39-19703-2DE6C405; Sun, 09 Sep 2012 10:26:26 +0000
X-Env-Sender: aware.why@gmail.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1347186386!24890401!1
X-Originating-IP: [209.85.215.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-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31011 invoked from network); 9 Sep 2012 10:26:26 -0000
Received: from mail-ey0-f171.google.com (HELO mail-ey0-f171.google.com)
	(209.85.215.171)
	by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Sep 2012 10:26:26 -0000
Received: by eaah11 with SMTP id h11so415931eaa.30
	for <xen-devel@lists.xensource.com>;
	Sun, 09 Sep 2012 03:26:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:date:message-id:subject:from:to:content-type;
	bh=g5lVUmVroQW3MTB0f7sTFvDXvxy2sZ6UCSpMOAbi8jU=;
	b=QyBEK+LGcKaGyru3UBi0nGDGRe7pOxUzT2LqwlAgnM9um84YZEbtJ3hYImVpcWkLOV
	dmUpyXxL2do1oeXoeUvcZq+wBG/Sbyxjbbmd838id7EyQODFdEuXImZyK5H7zfSJofFc
	wrSjcyF7VhSC/6fVH2pOLb6FIlQ35m2ZoIrwZKrPrzRGijNfLp+Q66cRPzWjxiDrYv/F
	V5hqbfSPUIaSs+r0ibICMvfGJFP1ytRjYfFLAFcTjK+9VWUUelLYwBpQP7l8ncO7jRim
	LJkx1/mIO3H10z44tCbrFgWh/IxdvHRQASUJ+rkocUXwHyNKps1ZdktOlOPZljE4ei+/
	qBOQ==
MIME-Version: 1.0
Received: by 10.14.223.9 with SMTP id u9mr14832332eep.10.1347186385705; Sun,
	09 Sep 2012 03:26:25 -0700 (PDT)
Received: by 10.14.100.71 with HTTP; Sun, 9 Sep 2012 03:26:25 -0700 (PDT)
Date: Sun, 9 Sep 2012 18:26:25 +0800
Message-ID: <CA+ePHTAYB9mXpUg-sAtN=hdQ2UAuBYcQvWhAFNt755eRdA-Cnw@mail.gmail.com>
From: =?UTF-8?B?6ams56OK?= <aware.why@gmail.com>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [help] why `xl restore` always return error for `xc:
 error: do_evtchn_op: HYPERVISOR_event_channel_op failed: -1: Internal
 error`
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============4201608652258172052=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============4201608652258172052==
Content-Type: multipart/alternative; boundary=047d7b670a9df75b6804c9424513

--047d7b670a9df75b6804c9424513
Content-Type: text/plain; charset=ISO-8859-1

Hi all:
    This is my running environment:  there are multiple processes, each
process will create a vm by `xl restore`;
 after running for a long time, it will easily get error for
` HYPERVISOR_event_channel_op failed: -1`.
    I don't understand much about that.
    Looking forward to your reply. Thanks.

bruce

--047d7b670a9df75b6804c9424513
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi all:<div>=A0 =A0 This is my running environment: =A0there are multiple p=
rocesses, each process will create a vm by `xl restore`;</div><div>=A0after=
 running for a long time, it will easily get error for `=A0HYPERVISOR_event=
_channel_op failed: -1`.</div>
<div>=A0 =A0 I don&#39;t understand much about that.</div><div>=A0 =A0 Look=
ing forward to your reply. Thanks.</div><div><br></div><div>bruce</div><div=
>=A0 =A0=A0</div>

--047d7b670a9df75b6804c9424513--


--===============4201608652258172052==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============4201608652258172052==--


From xen-devel-bounces@lists.xen.org Sun Sep 09 10:27:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 09 Sep 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 1TAeij-000191-9e; Sun, 09 Sep 2012 10:26:29 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <aware.why@gmail.com>) id 1TAeih-00018w-IG
	for xen-devel@lists.xensource.com; Sun, 09 Sep 2012 10:26:27 +0000
Received: from [85.158.139.83:15977] by server-7.bemta-5.messagelabs.com id
	72/39-19703-2DE6C405; Sun, 09 Sep 2012 10:26:26 +0000
X-Env-Sender: aware.why@gmail.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1347186386!24890401!1
X-Originating-IP: [209.85.215.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-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31011 invoked from network); 9 Sep 2012 10:26:26 -0000
Received: from mail-ey0-f171.google.com (HELO mail-ey0-f171.google.com)
	(209.85.215.171)
	by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Sep 2012 10:26:26 -0000
Received: by eaah11 with SMTP id h11so415931eaa.30
	for <xen-devel@lists.xensource.com>;
	Sun, 09 Sep 2012 03:26:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:date:message-id:subject:from:to:content-type;
	bh=g5lVUmVroQW3MTB0f7sTFvDXvxy2sZ6UCSpMOAbi8jU=;
	b=QyBEK+LGcKaGyru3UBi0nGDGRe7pOxUzT2LqwlAgnM9um84YZEbtJ3hYImVpcWkLOV
	dmUpyXxL2do1oeXoeUvcZq+wBG/Sbyxjbbmd838id7EyQODFdEuXImZyK5H7zfSJofFc
	wrSjcyF7VhSC/6fVH2pOLb6FIlQ35m2ZoIrwZKrPrzRGijNfLp+Q66cRPzWjxiDrYv/F
	V5hqbfSPUIaSs+r0ibICMvfGJFP1ytRjYfFLAFcTjK+9VWUUelLYwBpQP7l8ncO7jRim
	LJkx1/mIO3H10z44tCbrFgWh/IxdvHRQASUJ+rkocUXwHyNKps1ZdktOlOPZljE4ei+/
	qBOQ==
MIME-Version: 1.0
Received: by 10.14.223.9 with SMTP id u9mr14832332eep.10.1347186385705; Sun,
	09 Sep 2012 03:26:25 -0700 (PDT)
Received: by 10.14.100.71 with HTTP; Sun, 9 Sep 2012 03:26:25 -0700 (PDT)
Date: Sun, 9 Sep 2012 18:26:25 +0800
Message-ID: <CA+ePHTAYB9mXpUg-sAtN=hdQ2UAuBYcQvWhAFNt755eRdA-Cnw@mail.gmail.com>
From: =?UTF-8?B?6ams56OK?= <aware.why@gmail.com>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [help] why `xl restore` always return error for `xc:
 error: do_evtchn_op: HYPERVISOR_event_channel_op failed: -1: Internal
 error`
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============4201608652258172052=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============4201608652258172052==
Content-Type: multipart/alternative; boundary=047d7b670a9df75b6804c9424513

--047d7b670a9df75b6804c9424513
Content-Type: text/plain; charset=ISO-8859-1

Hi all:
    This is my running environment:  there are multiple processes, each
process will create a vm by `xl restore`;
 after running for a long time, it will easily get error for
` HYPERVISOR_event_channel_op failed: -1`.
    I don't understand much about that.
    Looking forward to your reply. Thanks.

bruce

--047d7b670a9df75b6804c9424513
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi all:<div>=A0 =A0 This is my running environment: =A0there are multiple p=
rocesses, each process will create a vm by `xl restore`;</div><div>=A0after=
 running for a long time, it will easily get error for `=A0HYPERVISOR_event=
_channel_op failed: -1`.</div>
<div>=A0 =A0 I don&#39;t understand much about that.</div><div>=A0 =A0 Look=
ing forward to your reply. Thanks.</div><div><br></div><div>bruce</div><div=
>=A0 =A0=A0</div>

--047d7b670a9df75b6804c9424513--


--===============4201608652258172052==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============4201608652258172052==--


From xen-devel-bounces@lists.xen.org Sun Sep 09 11:12:20 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 09 Sep 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 1TAfQZ-0001ge-Vv; Sun, 09 Sep 2012 11:11:47 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1TAfQY-0001gW-24
	for xen-devel@lists.xen.org; Sun, 09 Sep 2012 11:11:46 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1347189099!10197919!1
X-Originating-IP: [209.85.212.179]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6655 invoked from network); 9 Sep 2012 11:11:39 -0000
Received: from mail-wi0-f179.google.com (HELO mail-wi0-f179.google.com)
	(209.85.212.179)
	by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Sep 2012 11:11:39 -0000
Received: by wibhq4 with SMTP id hq4so888480wib.14
	for <xen-devel@lists.xen.org>; Sun, 09 Sep 2012 04:11:38 -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:mime-version:content-type:content-transfer-encoding;
	bh=2hII/fU0iO4N+MM2uXdesD1sHIlUgdTnbt8Nk4CAanA=;
	b=M+KRMBG16n6Czs5d90Ccp6xpyHDHpuAtyVls6DbzRZOPsI5yumQb1iFNs+HusmrEyA
	npwT6G+NAv532l1WdJU5O+dAKG8rgMOHt359ow+tj7EpXybgSM8SRt3jX1zjLzf1yp+l
	aViKulGbKOcKEezzb166pyBxN8jtdjaH07or/yO0cDOyrKzyPYaNqjXpYK3sLmRXG76X
	YFw70mT6k8BcQBbPb2wCCBRBeqftz69OA2xmMZTzizUtjAt9LnIZ78NKnLopBRMQInqR
	JQVm/oi/xEwt3o+lAi0C83b09q2CyeHaZ7ZAfTwQe5Mrqne5p8fRe7G9MDdLzxqvv5dE
	WreQ==
Received: by 10.180.83.66 with SMTP id o2mr9908804wiy.14.1347189098763;
	Sun, 09 Sep 2012 04:11:38 -0700 (PDT)
Received: from [192.168.1.69] (host86-184-74-117.range86-184.btcentralplus.com.
	[86.184.74.117])
	by mx.google.com with ESMTPS id h9sm10704208wiz.1.2012.09.09.04.11.35
	(version=SSLv3 cipher=OTHER); Sun, 09 Sep 2012 04:11:37 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Sun, 09 Sep 2012 12:11:31 +0100
From: Keir Fraser <keir.xen@gmail.com>
To: <xen-devel@lists.xen.org>
Message-ID: <CC7237F3.3E2CD%keir.xen@gmail.com>
Thread-Topic: [ANNOUNCE] Xen x86 32-bit hypervisor end of life after 4.2
Thread-Index: Ac2Oe91j9M1uXMmVDU+bWl7qtvqJWA==
Mime-version: 1.0
Subject: [Xen-devel] [ANNOUNCE] Xen x86 32-bit hypervisor end of life after
	4.2
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Folks,

With 64-bit support well established in the x86 world these days, the number
of x86 production environments that cannot run a 64-bit hypervisor is pretty
much nil. Maintaining the 32-bit x86 port, and implementing new features for
it, is an ongoing development burden which could be more usefully directed
elsewhere. Therefore, 32-bit x86 will be considered obsolete in the 4.3
development branch, and removed.

32-bit x86 will continue to be maintained and supported (insofar as it has
been recently) in the supported stable branches: 3.4, 4.1, and 4.2.

Furthermore, 32-bit guests (including 32-bit PV guests) will continue to be
supported on the 64-bit hypervisor, as they always have been.

 Regards,
 Keir & The Xen Team



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Sep 09 11:12:20 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 09 Sep 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 1TAfQZ-0001ge-Vv; Sun, 09 Sep 2012 11:11:47 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1TAfQY-0001gW-24
	for xen-devel@lists.xen.org; Sun, 09 Sep 2012 11:11:46 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1347189099!10197919!1
X-Originating-IP: [209.85.212.179]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6655 invoked from network); 9 Sep 2012 11:11:39 -0000
Received: from mail-wi0-f179.google.com (HELO mail-wi0-f179.google.com)
	(209.85.212.179)
	by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Sep 2012 11:11:39 -0000
Received: by wibhq4 with SMTP id hq4so888480wib.14
	for <xen-devel@lists.xen.org>; Sun, 09 Sep 2012 04:11:38 -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:mime-version:content-type:content-transfer-encoding;
	bh=2hII/fU0iO4N+MM2uXdesD1sHIlUgdTnbt8Nk4CAanA=;
	b=M+KRMBG16n6Czs5d90Ccp6xpyHDHpuAtyVls6DbzRZOPsI5yumQb1iFNs+HusmrEyA
	npwT6G+NAv532l1WdJU5O+dAKG8rgMOHt359ow+tj7EpXybgSM8SRt3jX1zjLzf1yp+l
	aViKulGbKOcKEezzb166pyBxN8jtdjaH07or/yO0cDOyrKzyPYaNqjXpYK3sLmRXG76X
	YFw70mT6k8BcQBbPb2wCCBRBeqftz69OA2xmMZTzizUtjAt9LnIZ78NKnLopBRMQInqR
	JQVm/oi/xEwt3o+lAi0C83b09q2CyeHaZ7ZAfTwQe5Mrqne5p8fRe7G9MDdLzxqvv5dE
	WreQ==
Received: by 10.180.83.66 with SMTP id o2mr9908804wiy.14.1347189098763;
	Sun, 09 Sep 2012 04:11:38 -0700 (PDT)
Received: from [192.168.1.69] (host86-184-74-117.range86-184.btcentralplus.com.
	[86.184.74.117])
	by mx.google.com with ESMTPS id h9sm10704208wiz.1.2012.09.09.04.11.35
	(version=SSLv3 cipher=OTHER); Sun, 09 Sep 2012 04:11:37 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Sun, 09 Sep 2012 12:11:31 +0100
From: Keir Fraser <keir.xen@gmail.com>
To: <xen-devel@lists.xen.org>
Message-ID: <CC7237F3.3E2CD%keir.xen@gmail.com>
Thread-Topic: [ANNOUNCE] Xen x86 32-bit hypervisor end of life after 4.2
Thread-Index: Ac2Oe91j9M1uXMmVDU+bWl7qtvqJWA==
Mime-version: 1.0
Subject: [Xen-devel] [ANNOUNCE] Xen x86 32-bit hypervisor end of life after
	4.2
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Folks,

With 64-bit support well established in the x86 world these days, the number
of x86 production environments that cannot run a 64-bit hypervisor is pretty
much nil. Maintaining the 32-bit x86 port, and implementing new features for
it, is an ongoing development burden which could be more usefully directed
elsewhere. Therefore, 32-bit x86 will be considered obsolete in the 4.3
development branch, and removed.

32-bit x86 will continue to be maintained and supported (insofar as it has
been recently) in the supported stable branches: 3.4, 4.1, and 4.2.

Furthermore, 32-bit guests (including 32-bit PV guests) will continue to be
supported on the 64-bit hypervisor, as they always have been.

 Regards,
 Keir & The Xen Team



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Sep 09 11:16:54 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 09 Sep 2012 11:16:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TAfUx-0001ny-M4; Sun, 09 Sep 2012 11:16:19 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1TAfUw-0001nt-PJ
	for xen-devel@lists.xen.org; Sun, 09 Sep 2012 11:16:19 +0000
Received: from [85.158.138.51:37364] by server-6.bemta-3.messagelabs.com id
	BB/A5-29694-18A7C405; Sun, 09 Sep 2012 11:16:17 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1347189377!29596542!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-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10175 invoked from network); 9 Sep 2012 11:16:17 -0000
Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com)
	(74.125.83.45)
	by server-5.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Sep 2012 11:16:17 -0000
Received: by eeke53 with SMTP id e53so528698eek.32
	for <xen-devel@lists.xen.org>; Sun, 09 Sep 2012 04:16: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:message-id:thread-topic
	:thread-index:mime-version:content-type:content-transfer-encoding;
	bh=SuY9JModSW+T8a9uT19XPXwwIo2zopAN6zsEjlNuMWM=;
	b=i9lxy9ihCXBMMm1KpqbJb+MQa8Tyw80U6UcTl6IY0x21cZqkYNr5X/t36+vKYwkXML
	nBALCsRKCb/2X/J+ADqM6bDNbrXvElgVXr8Pp6xquOet1o3n542QdHdjJw02R2r2jErw
	VW4k5Cjg/d2ITM+sWnXmyEzBLp2jEiJDSJHxThn8NyNj5OopTdJAZsWBwY1+ctqBTxtp
	+qF74FICfBSBAVkB6VsHqKk/XeVa02et763fKnUqLmMtkF/HTD7JHgMrjWrxAWM/2OA2
	Duk/8+IDi5ZqRidZPgMNpMN9BXjfkEMzUWgInc9Io2V1El59RemeWE/ZG2IqRd8zK+vK
	NaAQ==
Received: by 10.14.182.134 with SMTP id o6mr14855390eem.26.1347189377076;
	Sun, 09 Sep 2012 04:16:17 -0700 (PDT)
Received: from [192.168.1.69] (host86-184-74-117.range86-184.btcentralplus.com.
	[86.184.74.117])
	by mx.google.com with ESMTPS id k49sm29029313een.4.2012.09.09.04.16.15
	(version=SSLv3 cipher=OTHER); Sun, 09 Sep 2012 04:16:16 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Sun, 09 Sep 2012 12:16:11 +0100
From: Keir Fraser <keir.xen@gmail.com>
To: <xen-devel@lists.xen.org>
Message-ID: <CC72390B.3E2D0%keir.xen@gmail.com>
Thread-Topic: [ANNOUNCE] Switching to git for primary Xen repositories
Thread-Index: Ac2OfIRH+w9gYspcZEaiRNVrDr+z/Q==
Mime-version: 1.0
Subject: [Xen-devel] [ANNOUNCE] Switching to git for primary Xen repositories
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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,

The Xen project has used mercurial for the primary repositories for many
years. However, with external projects (including Linux and qemu) using git,
this has led to us using and supporting two revision-control systems. Our
plan therefore, with the 4.2.0 release soon out of the way, is to switch to
git for all of our primary repositories. We will plan to mirror development
activity into the old mercurial repositories at least in the short term.

We will make a further announcement nearer to the time of the switchover.

 Regards,
 Keir & The Xen Team



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Sep 09 11:16:54 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 09 Sep 2012 11:16:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TAfUx-0001ny-M4; Sun, 09 Sep 2012 11:16:19 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1TAfUw-0001nt-PJ
	for xen-devel@lists.xen.org; Sun, 09 Sep 2012 11:16:19 +0000
Received: from [85.158.138.51:37364] by server-6.bemta-3.messagelabs.com id
	BB/A5-29694-18A7C405; Sun, 09 Sep 2012 11:16:17 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1347189377!29596542!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-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10175 invoked from network); 9 Sep 2012 11:16:17 -0000
Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com)
	(74.125.83.45)
	by server-5.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Sep 2012 11:16:17 -0000
Received: by eeke53 with SMTP id e53so528698eek.32
	for <xen-devel@lists.xen.org>; Sun, 09 Sep 2012 04:16: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:message-id:thread-topic
	:thread-index:mime-version:content-type:content-transfer-encoding;
	bh=SuY9JModSW+T8a9uT19XPXwwIo2zopAN6zsEjlNuMWM=;
	b=i9lxy9ihCXBMMm1KpqbJb+MQa8Tyw80U6UcTl6IY0x21cZqkYNr5X/t36+vKYwkXML
	nBALCsRKCb/2X/J+ADqM6bDNbrXvElgVXr8Pp6xquOet1o3n542QdHdjJw02R2r2jErw
	VW4k5Cjg/d2ITM+sWnXmyEzBLp2jEiJDSJHxThn8NyNj5OopTdJAZsWBwY1+ctqBTxtp
	+qF74FICfBSBAVkB6VsHqKk/XeVa02et763fKnUqLmMtkF/HTD7JHgMrjWrxAWM/2OA2
	Duk/8+IDi5ZqRidZPgMNpMN9BXjfkEMzUWgInc9Io2V1El59RemeWE/ZG2IqRd8zK+vK
	NaAQ==
Received: by 10.14.182.134 with SMTP id o6mr14855390eem.26.1347189377076;
	Sun, 09 Sep 2012 04:16:17 -0700 (PDT)
Received: from [192.168.1.69] (host86-184-74-117.range86-184.btcentralplus.com.
	[86.184.74.117])
	by mx.google.com with ESMTPS id k49sm29029313een.4.2012.09.09.04.16.15
	(version=SSLv3 cipher=OTHER); Sun, 09 Sep 2012 04:16:16 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Sun, 09 Sep 2012 12:16:11 +0100
From: Keir Fraser <keir.xen@gmail.com>
To: <xen-devel@lists.xen.org>
Message-ID: <CC72390B.3E2D0%keir.xen@gmail.com>
Thread-Topic: [ANNOUNCE] Switching to git for primary Xen repositories
Thread-Index: Ac2OfIRH+w9gYspcZEaiRNVrDr+z/Q==
Mime-version: 1.0
Subject: [Xen-devel] [ANNOUNCE] Switching to git for primary Xen repositories
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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,

The Xen project has used mercurial for the primary repositories for many
years. However, with external projects (including Linux and qemu) using git,
this has led to us using and supporting two revision-control systems. Our
plan therefore, with the 4.2.0 release soon out of the way, is to switch to
git for all of our primary repositories. We will plan to mirror development
activity into the old mercurial repositories at least in the short term.

We will make a further announcement nearer to the time of the switchover.

 Regards,
 Keir & The Xen Team



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Sep 09 19:50:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 09 Sep 2012 19:50:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TAnVV-0004NG-Bo; Sun, 09 Sep 2012 19:49:25 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andreslc@gridcentric.ca>) id 1TAnVT-0004N9-MX
	for xen-devel@lists.xensource.com; Sun, 09 Sep 2012 19:49:23 +0000
Received: from [85.158.138.51:27977] by server-3.bemta-3.messagelabs.com id
	57/28-21322-2C2FC405; Sun, 09 Sep 2012 19:49:22 +0000
X-Env-Sender: andreslc@gridcentric.ca
X-Msg-Ref: server-7.tower-174.messagelabs.com!1347220160!20662865!1
X-Originating-IP: [209.85.210.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6343 invoked from network); 9 Sep 2012 19:49:22 -0000
Received: from mail-iy0-f171.google.com (HELO mail-iy0-f171.google.com)
	(209.85.210.171)
	by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Sep 2012 19:49:22 -0000
Received: by iabz25 with SMTP id z25so1486407iab.30
	for <xen-devel@lists.xensource.com>;
	Sun, 09 Sep 2012 12:49:20 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=subject:mime-version:content-type:from:in-reply-to:date:cc
	:content-transfer-encoding:message-id:references:to:x-mailer
	:x-gm-message-state;
	bh=Y6UyCEF9qMIiW+RTLPSNGg/dP4vNsANsZsDPfW7Ayng=;
	b=J1Iop4lmyUBNjh4x5EF7n0ZLI/Upm8fyn62jcIhmL6yt91r23/u3umgkEMtqk4/URV
	RDscIrBlIF3RAys+do6qn2GZl+cVJH320jivwZLUn7A1oZ5vQOB3Tx1ml5wYDIg7jSa3
	sBF9Ms6NJU4f7kMXDqXvS0aj05425zEGdsLHnH/s8xFYiLyY2KzLpuZULGwZnZIcK1OS
	+5h50vc/s8M3zNNXQAtNKz4ax8PhA9DOWaDm/OIr38NahEp1c8p48k6TJVJdM/yaFYXy
	abvXDvXVP6e3UbRL0tDoFl4h9l6dek7HMNqxdkG7knwUnLuxNxpABFLtTXPBYg2q4l0+
	GxyQ==
Received: by 10.42.156.1 with SMTP id x1mr14759230icw.51.1347220160458;
	Sun, 09 Sep 2012 12:49:20 -0700 (PDT)
Received: from [192.168.1.100] (69-196-182-10.dsl.teksavvy.com.
	[69.196.182.10])
	by mx.google.com with ESMTPS id bp8sm15180424igb.12.2012.09.09.12.49.18
	(version=TLSv1/SSLv3 cipher=OTHER);
	Sun, 09 Sep 2012 12:49:19 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1278)
From: Andres Lagar-Cavilla <andreslc@gridcentric.ca>
In-Reply-To: <20120908095208.GA608@elgon.mountain>
Date: Sun, 9 Sep 2012 15:49:17 -0400
Message-Id: <61BA4F5D-682D-4D29-92E5-70299C0D9A70@gridcentric.ca>
References: <20120908095208.GA608@elgon.mountain>
To: Dan Carpenter <dan.carpenter@oracle.com>
X-Mailer: Apple Mail (2.1278)
X-Gm-Message-State: ALoCoQlqzJSNVh80P/RDn5cr5l6xxlBUZW3V1XdKehc0qzPbHeC7QZyDy6N934Y5c80J53KX94lQ
Cc: Jeremy Fitzhardinge <jeremy@goop.org>, xen-devel@lists.xensource.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Andres Lagar-Cavilla <andreslc@gridcentric.ca>,
	kernel-janitors@vger.kernel.org, virtualization@lists.linux-foundation.org
Subject: Re: [Xen-devel] [patch 1/3] xen/privcmd: check for integer overflow
	in ioctl
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Sep 8, 2012, at 5:52 AM, Dan Carpenter wrote:

> If m.num is too large then the "m.num * sizeof(*m.arr)" multiplication
> could overflow and the access_ok() check wouldn't test the right size.
> 
> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Acked-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
> ---
> Only needed in linux-next.
> 
> diff --git a/drivers/xen/privcmd.c b/drivers/xen/privcmd.c
> index 215a3c0..fdff8f9 100644
> --- a/drivers/xen/privcmd.c
> +++ b/drivers/xen/privcmd.c
> @@ -325,6 +325,8 @@ static long privcmd_ioctl_mmap_batch(void __user *udata, int version)
> 			return -EFAULT;
> 		/* Returns per-frame error in m.arr. */
> 		m.err = NULL;
> +		if (m.num > SIZE_MAX / sizeof(*m.arr))
> +			return -EINVAL;
> 		if (!access_ok(VERIFY_WRITE, m.arr, m.num * sizeof(*m.arr)))
> 			return -EFAULT;
> 		break;
> @@ -332,6 +334,8 @@ static long privcmd_ioctl_mmap_batch(void __user *udata, int version)
> 		if (copy_from_user(&m, udata, sizeof(struct privcmd_mmapbatch_v2)))
> 			return -EFAULT;
> 		/* Returns per-frame error code in m.err. */
> +		if (m.num > SIZE_MAX / sizeof(*m.err))
> +			return -EINVAL;
> 		if (!access_ok(VERIFY_WRITE, m.err, m.num * (sizeof(*m.err))))
> 			return -EFAULT;
> 		break;


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Sep 09 19:50:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 09 Sep 2012 19:50:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TAnVV-0004NG-Bo; Sun, 09 Sep 2012 19:49:25 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andreslc@gridcentric.ca>) id 1TAnVT-0004N9-MX
	for xen-devel@lists.xensource.com; Sun, 09 Sep 2012 19:49:23 +0000
Received: from [85.158.138.51:27977] by server-3.bemta-3.messagelabs.com id
	57/28-21322-2C2FC405; Sun, 09 Sep 2012 19:49:22 +0000
X-Env-Sender: andreslc@gridcentric.ca
X-Msg-Ref: server-7.tower-174.messagelabs.com!1347220160!20662865!1
X-Originating-IP: [209.85.210.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6343 invoked from network); 9 Sep 2012 19:49:22 -0000
Received: from mail-iy0-f171.google.com (HELO mail-iy0-f171.google.com)
	(209.85.210.171)
	by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Sep 2012 19:49:22 -0000
Received: by iabz25 with SMTP id z25so1486407iab.30
	for <xen-devel@lists.xensource.com>;
	Sun, 09 Sep 2012 12:49:20 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=subject:mime-version:content-type:from:in-reply-to:date:cc
	:content-transfer-encoding:message-id:references:to:x-mailer
	:x-gm-message-state;
	bh=Y6UyCEF9qMIiW+RTLPSNGg/dP4vNsANsZsDPfW7Ayng=;
	b=J1Iop4lmyUBNjh4x5EF7n0ZLI/Upm8fyn62jcIhmL6yt91r23/u3umgkEMtqk4/URV
	RDscIrBlIF3RAys+do6qn2GZl+cVJH320jivwZLUn7A1oZ5vQOB3Tx1ml5wYDIg7jSa3
	sBF9Ms6NJU4f7kMXDqXvS0aj05425zEGdsLHnH/s8xFYiLyY2KzLpuZULGwZnZIcK1OS
	+5h50vc/s8M3zNNXQAtNKz4ax8PhA9DOWaDm/OIr38NahEp1c8p48k6TJVJdM/yaFYXy
	abvXDvXVP6e3UbRL0tDoFl4h9l6dek7HMNqxdkG7knwUnLuxNxpABFLtTXPBYg2q4l0+
	GxyQ==
Received: by 10.42.156.1 with SMTP id x1mr14759230icw.51.1347220160458;
	Sun, 09 Sep 2012 12:49:20 -0700 (PDT)
Received: from [192.168.1.100] (69-196-182-10.dsl.teksavvy.com.
	[69.196.182.10])
	by mx.google.com with ESMTPS id bp8sm15180424igb.12.2012.09.09.12.49.18
	(version=TLSv1/SSLv3 cipher=OTHER);
	Sun, 09 Sep 2012 12:49:19 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1278)
From: Andres Lagar-Cavilla <andreslc@gridcentric.ca>
In-Reply-To: <20120908095208.GA608@elgon.mountain>
Date: Sun, 9 Sep 2012 15:49:17 -0400
Message-Id: <61BA4F5D-682D-4D29-92E5-70299C0D9A70@gridcentric.ca>
References: <20120908095208.GA608@elgon.mountain>
To: Dan Carpenter <dan.carpenter@oracle.com>
X-Mailer: Apple Mail (2.1278)
X-Gm-Message-State: ALoCoQlqzJSNVh80P/RDn5cr5l6xxlBUZW3V1XdKehc0qzPbHeC7QZyDy6N934Y5c80J53KX94lQ
Cc: Jeremy Fitzhardinge <jeremy@goop.org>, xen-devel@lists.xensource.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Andres Lagar-Cavilla <andreslc@gridcentric.ca>,
	kernel-janitors@vger.kernel.org, virtualization@lists.linux-foundation.org
Subject: Re: [Xen-devel] [patch 1/3] xen/privcmd: check for integer overflow
	in ioctl
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Sep 8, 2012, at 5:52 AM, Dan Carpenter wrote:

> If m.num is too large then the "m.num * sizeof(*m.arr)" multiplication
> could overflow and the access_ok() check wouldn't test the right size.
> 
> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Acked-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
> ---
> Only needed in linux-next.
> 
> diff --git a/drivers/xen/privcmd.c b/drivers/xen/privcmd.c
> index 215a3c0..fdff8f9 100644
> --- a/drivers/xen/privcmd.c
> +++ b/drivers/xen/privcmd.c
> @@ -325,6 +325,8 @@ static long privcmd_ioctl_mmap_batch(void __user *udata, int version)
> 			return -EFAULT;
> 		/* Returns per-frame error in m.arr. */
> 		m.err = NULL;
> +		if (m.num > SIZE_MAX / sizeof(*m.arr))
> +			return -EINVAL;
> 		if (!access_ok(VERIFY_WRITE, m.arr, m.num * sizeof(*m.arr)))
> 			return -EFAULT;
> 		break;
> @@ -332,6 +334,8 @@ static long privcmd_ioctl_mmap_batch(void __user *udata, int version)
> 		if (copy_from_user(&m, udata, sizeof(struct privcmd_mmapbatch_v2)))
> 			return -EFAULT;
> 		/* Returns per-frame error code in m.err. */
> +		if (m.num > SIZE_MAX / sizeof(*m.err))
> +			return -EINVAL;
> 		if (!access_ok(VERIFY_WRITE, m.err, m.num * (sizeof(*m.err))))
> 			return -EFAULT;
> 		break;


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Sep 09 19:50:09 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 09 Sep 2012 19: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 1TAnVk-0004O4-Oe; Sun, 09 Sep 2012 19:49:40 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andreslc@gridcentric.ca>) id 1TAnVj-0004Ni-AY
	for xen-devel@lists.xensource.com; Sun, 09 Sep 2012 19:49:39 +0000
X-Env-Sender: andreslc@gridcentric.ca
X-Msg-Ref: server-4.tower-27.messagelabs.com!1347220171!9703015!1
X-Originating-IP: [209.85.223.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24412 invoked from network); 9 Sep 2012 19:49:33 -0000
Received: from mail-ie0-f171.google.com (HELO mail-ie0-f171.google.com)
	(209.85.223.171)
	by server-4.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Sep 2012 19:49:33 -0000
Received: by ieje14 with SMTP id e14so2410274iej.30
	for <xen-devel@lists.xensource.com>;
	Sun, 09 Sep 2012 12:49:31 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=subject:mime-version:content-type:from:in-reply-to:date:cc
	:content-transfer-encoding:message-id:references:to:x-mailer
	:x-gm-message-state;
	bh=vn/+hPNvyDfXu1Se9QakaS3h65Imdqi7AYRW/oP5ocY=;
	b=ljQIr1TFT9uCgCVYt+RdlHxrIT3tUwQn5+XqkOnufz+XD00/dZd5rBzs+Kw1mW6Bv1
	DaYXQgBOco/RdvLDcKvY3hzUKi+EreX29seD4QVt28hsmRbabNZXM3Jx85FRCB5PwV5Z
	a7gwDS9A+QJP69DMnVZ6f1mi+Cel0XUE4NLmQu6nIFm60IacmgmCQWr7yIyOyxIPm747
	EOCdc6yRji84d3Zi5LVk+n3hYwpETPDVH29gCNYz6sTdWxEDxyHmH/jPOwUfkLBFo0tr
	juUl+yjNvo0zvCjcxgnGDtgk5LUEh7JlgAYGOoNBoqM0N8qbqbSjEnt74RtBAmsKvFjK
	Vqhw==
Received: by 10.43.16.67 with SMTP id px3mr6341870icb.17.1347220171419;
	Sun, 09 Sep 2012 12:49:31 -0700 (PDT)
Received: from [192.168.1.100] (69-196-182-10.dsl.teksavvy.com.
	[69.196.182.10])
	by mx.google.com with ESMTPS id bp8sm15180424igb.12.2012.09.09.12.49.29
	(version=TLSv1/SSLv3 cipher=OTHER);
	Sun, 09 Sep 2012 12:49:31 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1278)
From: Andres Lagar-Cavilla <andreslc@gridcentric.ca>
In-Reply-To: <20120908095735.GB608@elgon.mountain>
Date: Sun, 9 Sep 2012 15:49:29 -0400
Message-Id: <CBDACA0A-1E68-4FFE-860B-2801019E03E2@gridcentric.ca>
References: <20120908095735.GB608@elgon.mountain>
To: Dan Carpenter <dan.carpenter@oracle.com>
X-Mailer: Apple Mail (2.1278)
X-Gm-Message-State: ALoCoQkkUdlGkuwUT5pWzkRzJHMeU45ybVLIm2x3OWI/75U5B2DaS8uR0lrFfqnmnwZXmM9zFVkT
Cc: Jeremy Fitzhardinge <jeremy@goop.org>, xen-devel@lists.xensource.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Andres Lagar-Cavilla <andreslc@gridcentric.ca>,
	kernel-janitors@vger.kernel.org, virtualization@lists.linux-foundation.org
Subject: Re: [Xen-devel] [patch 2/3] xen/privcmd: return -EFAULT on 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 Sep 8, 2012, at 5:57 AM, Dan Carpenter wrote:

> __copy_to_user() returns the number of bytes remaining to be copied but
> we want to return a negative error code here.
> 
> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Acked-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
> 
> diff --git a/drivers/xen/privcmd.c b/drivers/xen/privcmd.c
> index fdff8f9..0ce006a 100644
> --- a/drivers/xen/privcmd.c
> +++ b/drivers/xen/privcmd.c
> @@ -393,8 +393,11 @@ static long privcmd_ioctl_mmap_batch(void __user *udata, int version)
> 		state.err      = err_array;
> 		ret = traverse_pages(m.num, sizeof(xen_pfn_t),
> 				     &pagelist, mmap_return_errors_v1, &state);
> -	} else if (version == 2)
> +	} else if (version == 2) {
> 		ret = __copy_to_user(m.err, err_array, m.num * sizeof(int));
> +		if (ret)
> +			ret = -EFAULT;
> +	}
> 
> 	/* If we have not had any EFAULT-like global errors then set the global
> 	 * error to -ENOENT if necessary. */


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Sep 09 19:50:09 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 09 Sep 2012 19: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 1TAnVk-0004O4-Oe; Sun, 09 Sep 2012 19:49:40 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andreslc@gridcentric.ca>) id 1TAnVj-0004Ni-AY
	for xen-devel@lists.xensource.com; Sun, 09 Sep 2012 19:49:39 +0000
X-Env-Sender: andreslc@gridcentric.ca
X-Msg-Ref: server-4.tower-27.messagelabs.com!1347220171!9703015!1
X-Originating-IP: [209.85.223.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24412 invoked from network); 9 Sep 2012 19:49:33 -0000
Received: from mail-ie0-f171.google.com (HELO mail-ie0-f171.google.com)
	(209.85.223.171)
	by server-4.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Sep 2012 19:49:33 -0000
Received: by ieje14 with SMTP id e14so2410274iej.30
	for <xen-devel@lists.xensource.com>;
	Sun, 09 Sep 2012 12:49:31 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=subject:mime-version:content-type:from:in-reply-to:date:cc
	:content-transfer-encoding:message-id:references:to:x-mailer
	:x-gm-message-state;
	bh=vn/+hPNvyDfXu1Se9QakaS3h65Imdqi7AYRW/oP5ocY=;
	b=ljQIr1TFT9uCgCVYt+RdlHxrIT3tUwQn5+XqkOnufz+XD00/dZd5rBzs+Kw1mW6Bv1
	DaYXQgBOco/RdvLDcKvY3hzUKi+EreX29seD4QVt28hsmRbabNZXM3Jx85FRCB5PwV5Z
	a7gwDS9A+QJP69DMnVZ6f1mi+Cel0XUE4NLmQu6nIFm60IacmgmCQWr7yIyOyxIPm747
	EOCdc6yRji84d3Zi5LVk+n3hYwpETPDVH29gCNYz6sTdWxEDxyHmH/jPOwUfkLBFo0tr
	juUl+yjNvo0zvCjcxgnGDtgk5LUEh7JlgAYGOoNBoqM0N8qbqbSjEnt74RtBAmsKvFjK
	Vqhw==
Received: by 10.43.16.67 with SMTP id px3mr6341870icb.17.1347220171419;
	Sun, 09 Sep 2012 12:49:31 -0700 (PDT)
Received: from [192.168.1.100] (69-196-182-10.dsl.teksavvy.com.
	[69.196.182.10])
	by mx.google.com with ESMTPS id bp8sm15180424igb.12.2012.09.09.12.49.29
	(version=TLSv1/SSLv3 cipher=OTHER);
	Sun, 09 Sep 2012 12:49:31 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1278)
From: Andres Lagar-Cavilla <andreslc@gridcentric.ca>
In-Reply-To: <20120908095735.GB608@elgon.mountain>
Date: Sun, 9 Sep 2012 15:49:29 -0400
Message-Id: <CBDACA0A-1E68-4FFE-860B-2801019E03E2@gridcentric.ca>
References: <20120908095735.GB608@elgon.mountain>
To: Dan Carpenter <dan.carpenter@oracle.com>
X-Mailer: Apple Mail (2.1278)
X-Gm-Message-State: ALoCoQkkUdlGkuwUT5pWzkRzJHMeU45ybVLIm2x3OWI/75U5B2DaS8uR0lrFfqnmnwZXmM9zFVkT
Cc: Jeremy Fitzhardinge <jeremy@goop.org>, xen-devel@lists.xensource.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Andres Lagar-Cavilla <andreslc@gridcentric.ca>,
	kernel-janitors@vger.kernel.org, virtualization@lists.linux-foundation.org
Subject: Re: [Xen-devel] [patch 2/3] xen/privcmd: return -EFAULT on 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 Sep 8, 2012, at 5:57 AM, Dan Carpenter wrote:

> __copy_to_user() returns the number of bytes remaining to be copied but
> we want to return a negative error code here.
> 
> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Acked-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
> 
> diff --git a/drivers/xen/privcmd.c b/drivers/xen/privcmd.c
> index fdff8f9..0ce006a 100644
> --- a/drivers/xen/privcmd.c
> +++ b/drivers/xen/privcmd.c
> @@ -393,8 +393,11 @@ static long privcmd_ioctl_mmap_batch(void __user *udata, int version)
> 		state.err      = err_array;
> 		ret = traverse_pages(m.num, sizeof(xen_pfn_t),
> 				     &pagelist, mmap_return_errors_v1, &state);
> -	} else if (version == 2)
> +	} else if (version == 2) {
> 		ret = __copy_to_user(m.err, err_array, m.num * sizeof(int));
> +		if (ret)
> +			ret = -EFAULT;
> +	}
> 
> 	/* If we have not had any EFAULT-like global errors then set the global
> 	 * error to -ENOENT if necessary. */


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Sep 09 19:50:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 09 Sep 2012 19: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 1TAnWa-0004TY-5o; Sun, 09 Sep 2012 19:50:32 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andreslc@gridcentric.ca>) id 1TAnWY-0004TO-T5
	for xen-devel@lists.xensource.com; Sun, 09 Sep 2012 19:50:31 +0000
Received: from [85.158.143.99:21972] by server-3.bemta-4.messagelabs.com id
	16/84-08232-603FC405; Sun, 09 Sep 2012 19:50:30 +0000
X-Env-Sender: andreslc@gridcentric.ca
X-Msg-Ref: server-6.tower-216.messagelabs.com!1347220227!22366496!1
X-Originating-IP: [209.85.223.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8829 invoked from network); 9 Sep 2012 19:50:29 -0000
Received: from mail-ie0-f171.google.com (HELO mail-ie0-f171.google.com)
	(209.85.223.171)
	by server-6.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Sep 2012 19:50:29 -0000
Received: by ieje14 with SMTP id e14so2411084iej.30
	for <xen-devel@lists.xensource.com>;
	Sun, 09 Sep 2012 12:50:27 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=subject:mime-version:content-type:from:in-reply-to:date:cc
	:content-transfer-encoding:message-id:references:to:x-mailer
	:x-gm-message-state;
	bh=brkPceHlRANBE0+pYpFacYfHTeQDWRv4G6d0giQDJhk=;
	b=m3xf64K7iHrwMpNcsxKtLdb3us/agac8PrsPWVXam6zOfOvO35nHVM4j4XQAuRd1dt
	vxHxUtQATgBhs5rPpcaTFJPGHl+02j9VwfO1Xqzi0qg59BqL1axPMl1kwATZwNkjja2F
	+KRv46PaSOxphdp34k804sIpfW0+F8C8cBgYnCwHlux7nTnTaiLlTArMmCzHS5MxYvQ3
	hqj32ClnDVsVejoWD3KXzjzV9t3fBOUUvVc3XA8c9ZVnxgwKCanzRClqqiwk29H64ks6
	h+xDPmIJtRutlA4rZYzOz8tBRE0O9y/aMvkWjS3NxCfwVQ+0c03ktNJ/r5Mdby7bAM38
	AOSQ==
Received: by 10.50.51.234 with SMTP id n10mr8251761igo.74.1347220227630;
	Sun, 09 Sep 2012 12:50:27 -0700 (PDT)
Received: from [192.168.1.100] (69-196-182-10.dsl.teksavvy.com.
	[69.196.182.10])
	by mx.google.com with ESMTPS id bp8sm15180424igb.12.2012.09.09.12.50.26
	(version=TLSv1/SSLv3 cipher=OTHER);
	Sun, 09 Sep 2012 12:50:27 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1278)
From: Andres Lagar-Cavilla <andreslc@gridcentric.ca>
In-Reply-To: <20120908095808.GC608@elgon.mountain>
Date: Sun, 9 Sep 2012 15:50:26 -0400
Message-Id: <F9C8B0B7-7A32-44A9-9A6D-05A2E680E047@gridcentric.ca>
References: <20120908095808.GC608@elgon.mountain>
To: Dan Carpenter <dan.carpenter@oracle.com>
X-Mailer: Apple Mail (2.1278)
X-Gm-Message-State: ALoCoQnItYaLVlO4WrsHq6BE0coiBYs98IlXOALoHKJA6aFM+h0MasATf5ImuE8yC/qOeO0IO6cP
Cc: Jeremy Fitzhardinge <jeremy@goop.org>, xen-devel@lists.xensource.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Andres Lagar-Cavilla <andreslc@gridcentric.ca>,
	kernel-janitors@vger.kernel.org, virtualization@lists.linux-foundation.org
Subject: Re: [Xen-devel] [patch 3/3] xen/privcmd: remove const modifier from
	declaration
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Sep 8, 2012, at 5:58 AM, Dan Carpenter wrote:

> When we use this pointer, we cast away the const modifier and modify the
> data.  I think it was an accident to declare it as const.
> 
> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Acked-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

Thanks for the careful review & hardening.
Andres

> 
> diff --git a/include/xen/privcmd.h b/include/xen/privcmd.h
> index a853168..58ed953 100644
> --- a/include/xen/privcmd.h
> +++ b/include/xen/privcmd.h
> @@ -69,7 +69,7 @@ struct privcmd_mmapbatch_v2 {
> 	unsigned int num; /* number of pages to populate */
> 	domid_t dom;      /* target domain */
> 	__u64 addr;       /* virtual address */
> -	const xen_pfn_t __user *arr; /* array of mfns */
> +	xen_pfn_t __user *arr; /* array of mfns */
> 	int __user *err;  /* array of error codes */
> };
> 
> diff --git a/drivers/xen/privcmd.c b/drivers/xen/privcmd.c
> index 0ce006a..fceb83e 100644
> --- a/drivers/xen/privcmd.c
> +++ b/drivers/xen/privcmd.c
> @@ -389,7 +389,7 @@ static long privcmd_ioctl_mmap_batch(void __user *udata, int version)
> 
> 	if (state.global_error && (version == 1)) {
> 		/* Write back errors in second pass. */
> -		state.user_mfn = (xen_pfn_t *)m.arr;
> +		state.user_mfn = m.arr;
> 		state.err      = err_array;
> 		ret = traverse_pages(m.num, sizeof(xen_pfn_t),
> 				     &pagelist, mmap_return_errors_v1, &state);


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Sep 09 19:50:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 09 Sep 2012 19: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 1TAnWa-0004TY-5o; Sun, 09 Sep 2012 19:50:32 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andreslc@gridcentric.ca>) id 1TAnWY-0004TO-T5
	for xen-devel@lists.xensource.com; Sun, 09 Sep 2012 19:50:31 +0000
Received: from [85.158.143.99:21972] by server-3.bemta-4.messagelabs.com id
	16/84-08232-603FC405; Sun, 09 Sep 2012 19:50:30 +0000
X-Env-Sender: andreslc@gridcentric.ca
X-Msg-Ref: server-6.tower-216.messagelabs.com!1347220227!22366496!1
X-Originating-IP: [209.85.223.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8829 invoked from network); 9 Sep 2012 19:50:29 -0000
Received: from mail-ie0-f171.google.com (HELO mail-ie0-f171.google.com)
	(209.85.223.171)
	by server-6.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Sep 2012 19:50:29 -0000
Received: by ieje14 with SMTP id e14so2411084iej.30
	for <xen-devel@lists.xensource.com>;
	Sun, 09 Sep 2012 12:50:27 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=subject:mime-version:content-type:from:in-reply-to:date:cc
	:content-transfer-encoding:message-id:references:to:x-mailer
	:x-gm-message-state;
	bh=brkPceHlRANBE0+pYpFacYfHTeQDWRv4G6d0giQDJhk=;
	b=m3xf64K7iHrwMpNcsxKtLdb3us/agac8PrsPWVXam6zOfOvO35nHVM4j4XQAuRd1dt
	vxHxUtQATgBhs5rPpcaTFJPGHl+02j9VwfO1Xqzi0qg59BqL1axPMl1kwATZwNkjja2F
	+KRv46PaSOxphdp34k804sIpfW0+F8C8cBgYnCwHlux7nTnTaiLlTArMmCzHS5MxYvQ3
	hqj32ClnDVsVejoWD3KXzjzV9t3fBOUUvVc3XA8c9ZVnxgwKCanzRClqqiwk29H64ks6
	h+xDPmIJtRutlA4rZYzOz8tBRE0O9y/aMvkWjS3NxCfwVQ+0c03ktNJ/r5Mdby7bAM38
	AOSQ==
Received: by 10.50.51.234 with SMTP id n10mr8251761igo.74.1347220227630;
	Sun, 09 Sep 2012 12:50:27 -0700 (PDT)
Received: from [192.168.1.100] (69-196-182-10.dsl.teksavvy.com.
	[69.196.182.10])
	by mx.google.com with ESMTPS id bp8sm15180424igb.12.2012.09.09.12.50.26
	(version=TLSv1/SSLv3 cipher=OTHER);
	Sun, 09 Sep 2012 12:50:27 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1278)
From: Andres Lagar-Cavilla <andreslc@gridcentric.ca>
In-Reply-To: <20120908095808.GC608@elgon.mountain>
Date: Sun, 9 Sep 2012 15:50:26 -0400
Message-Id: <F9C8B0B7-7A32-44A9-9A6D-05A2E680E047@gridcentric.ca>
References: <20120908095808.GC608@elgon.mountain>
To: Dan Carpenter <dan.carpenter@oracle.com>
X-Mailer: Apple Mail (2.1278)
X-Gm-Message-State: ALoCoQnItYaLVlO4WrsHq6BE0coiBYs98IlXOALoHKJA6aFM+h0MasATf5ImuE8yC/qOeO0IO6cP
Cc: Jeremy Fitzhardinge <jeremy@goop.org>, xen-devel@lists.xensource.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Andres Lagar-Cavilla <andreslc@gridcentric.ca>,
	kernel-janitors@vger.kernel.org, virtualization@lists.linux-foundation.org
Subject: Re: [Xen-devel] [patch 3/3] xen/privcmd: remove const modifier from
	declaration
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Sep 8, 2012, at 5:58 AM, Dan Carpenter wrote:

> When we use this pointer, we cast away the const modifier and modify the
> data.  I think it was an accident to declare it as const.
> 
> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Acked-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

Thanks for the careful review & hardening.
Andres

> 
> diff --git a/include/xen/privcmd.h b/include/xen/privcmd.h
> index a853168..58ed953 100644
> --- a/include/xen/privcmd.h
> +++ b/include/xen/privcmd.h
> @@ -69,7 +69,7 @@ struct privcmd_mmapbatch_v2 {
> 	unsigned int num; /* number of pages to populate */
> 	domid_t dom;      /* target domain */
> 	__u64 addr;       /* virtual address */
> -	const xen_pfn_t __user *arr; /* array of mfns */
> +	xen_pfn_t __user *arr; /* array of mfns */
> 	int __user *err;  /* array of error codes */
> };
> 
> diff --git a/drivers/xen/privcmd.c b/drivers/xen/privcmd.c
> index 0ce006a..fceb83e 100644
> --- a/drivers/xen/privcmd.c
> +++ b/drivers/xen/privcmd.c
> @@ -389,7 +389,7 @@ static long privcmd_ioctl_mmap_batch(void __user *udata, int version)
> 
> 	if (state.global_error && (version == 1)) {
> 		/* Write back errors in second pass. */
> -		state.user_mfn = (xen_pfn_t *)m.arr;
> +		state.user_mfn = m.arr;
> 		state.err      = err_array;
> 		ret = traverse_pages(m.num, sizeof(xen_pfn_t),
> 				     &pagelist, mmap_return_errors_v1, &state);


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 10 02:29:10 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Sep 2012 02: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 1TAtjj-000331-W2; Mon, 10 Sep 2012 02:28:31 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xiantao.zhang@intel.com>) id 1TAtji-00032w-KQ
	for xen-devel@lists.xen.org; Mon, 10 Sep 2012 02:28:30 +0000
Received: from [85.158.143.35:30662] by server-3.bemta-4.messagelabs.com id
	9F/69-08232-D405D405; Mon, 10 Sep 2012 02:28:29 +0000
X-Env-Sender: xiantao.zhang@intel.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1347244108!14931239!1
X-Originating-IP: [192.55.52.93]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjkzID0+IDM0NjgzMg==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8420 invoked from network); 10 Sep 2012 02:28:29 -0000
Received: from mga11.intel.com (HELO mga11.intel.com) (192.55.52.93)
	by server-16.tower-21.messagelabs.com with SMTP;
	10 Sep 2012 02:28:29 -0000
Received: from fmsmga002.fm.intel.com ([10.253.24.26])
	by fmsmga102.fm.intel.com with ESMTP; 09 Sep 2012 19:28:28 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.80,396,1344236400"; d="scan'208";a="219857960"
Received: from fmsmsx107.amr.corp.intel.com ([10.19.9.54])
	by fmsmga002.fm.intel.com with ESMTP; 09 Sep 2012 19:28:27 -0700
Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by
	FMSMSX107.amr.corp.intel.com (10.19.9.54) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Sun, 9 Sep 2012 19:28:27 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.239]) by
	SHSMSX102.ccr.corp.intel.com ([169.254.2.92]) with mapi id
	14.01.0355.002; Mon, 10 Sep 2012 10:28:26 +0800
From: "Zhang, Xiantao" <xiantao.zhang@intel.com>
To: Jan Beulich <JBeulich@suse.com>, Keir Fraser <keir.xen@gmail.com>,
	xen-devel <xen-devel@lists.xen.org>
Thread-Topic: [Xen-devel] [PATCH] VT-d: split .ack and .disable DMA-MSI actors
Thread-Index: AQHNjRCKcYs6tod0vkOIEG1EpUWMspeC3WUg
Date: Mon, 10 Sep 2012 02:28:25 +0000
Message-ID: <B6C2EB9186482D47BD0C5A9A48345644032F387D@SHSMSX101.ccr.corp.intel.com>
References: <504A08930200007800099C9A@nat28.tlf.novell.com>
	<CC6FCBC9.3E0BB%keir.xen@gmail.com>
	<504A34250200007800099E8F@nat28.tlf.novell.com>
In-Reply-To: <504A34250200007800099E8F@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: "Zhang, Xiantao" <xiantao.zhang@intel.com>
Subject: Re: [Xen-devel] [PATCH] VT-d: split .ack and .disable DMA-MSI actors
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org



> -----Original Message-----
> From: Jan Beulich [mailto:JBeulich@suse.com]
> Sent: Friday, September 07, 2012 11:52 PM
> To: Keir Fraser; xen-devel
> Cc: Zhang, Xiantao
> Subject: Re: [Xen-devel] [PATCH] VT-d: split .ack and .disable DMA-MSI
> actors
> 
> >>> On 07.09.12 at 17:05, Keir Fraser <keir.xen@gmail.com> wrote:
> > On 07/09/2012 13:45, "Jan Beulich" <JBeulich@suse.com> wrote:
> >
> >> Calling irq_complete_move() from .disable is wrong, breaking S3 resume.
> >>
> >> Comparing with all other .ack actors, it was also missing a call to
> >> move_{native,masked}_irq(). As the actor is masking its interrupt
> >> anyway (albeit it's not immediately obvious why), the latter is the
> >> better choice.
> >>
> >> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> >
> > As far as I understand it
> > Acked-by: Keir Fraser <keir@xen.org>
> >
> > I guess you are looking for an Intel ack as well.
> 
> Yes, that's why I Cc-ed Xiantao.
Thanks for the fix!  
Acked-by Xiantao Zhang <xiantao.zhang@intel.com>!  
Xiantao

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 10 02:29:10 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Sep 2012 02: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 1TAtjj-000331-W2; Mon, 10 Sep 2012 02:28:31 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xiantao.zhang@intel.com>) id 1TAtji-00032w-KQ
	for xen-devel@lists.xen.org; Mon, 10 Sep 2012 02:28:30 +0000
Received: from [85.158.143.35:30662] by server-3.bemta-4.messagelabs.com id
	9F/69-08232-D405D405; Mon, 10 Sep 2012 02:28:29 +0000
X-Env-Sender: xiantao.zhang@intel.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1347244108!14931239!1
X-Originating-IP: [192.55.52.93]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjkzID0+IDM0NjgzMg==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8420 invoked from network); 10 Sep 2012 02:28:29 -0000
Received: from mga11.intel.com (HELO mga11.intel.com) (192.55.52.93)
	by server-16.tower-21.messagelabs.com with SMTP;
	10 Sep 2012 02:28:29 -0000
Received: from fmsmga002.fm.intel.com ([10.253.24.26])
	by fmsmga102.fm.intel.com with ESMTP; 09 Sep 2012 19:28:28 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.80,396,1344236400"; d="scan'208";a="219857960"
Received: from fmsmsx107.amr.corp.intel.com ([10.19.9.54])
	by fmsmga002.fm.intel.com with ESMTP; 09 Sep 2012 19:28:27 -0700
Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by
	FMSMSX107.amr.corp.intel.com (10.19.9.54) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Sun, 9 Sep 2012 19:28:27 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.239]) by
	SHSMSX102.ccr.corp.intel.com ([169.254.2.92]) with mapi id
	14.01.0355.002; Mon, 10 Sep 2012 10:28:26 +0800
From: "Zhang, Xiantao" <xiantao.zhang@intel.com>
To: Jan Beulich <JBeulich@suse.com>, Keir Fraser <keir.xen@gmail.com>,
	xen-devel <xen-devel@lists.xen.org>
Thread-Topic: [Xen-devel] [PATCH] VT-d: split .ack and .disable DMA-MSI actors
Thread-Index: AQHNjRCKcYs6tod0vkOIEG1EpUWMspeC3WUg
Date: Mon, 10 Sep 2012 02:28:25 +0000
Message-ID: <B6C2EB9186482D47BD0C5A9A48345644032F387D@SHSMSX101.ccr.corp.intel.com>
References: <504A08930200007800099C9A@nat28.tlf.novell.com>
	<CC6FCBC9.3E0BB%keir.xen@gmail.com>
	<504A34250200007800099E8F@nat28.tlf.novell.com>
In-Reply-To: <504A34250200007800099E8F@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: "Zhang, Xiantao" <xiantao.zhang@intel.com>
Subject: Re: [Xen-devel] [PATCH] VT-d: split .ack and .disable DMA-MSI actors
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org



> -----Original Message-----
> From: Jan Beulich [mailto:JBeulich@suse.com]
> Sent: Friday, September 07, 2012 11:52 PM
> To: Keir Fraser; xen-devel
> Cc: Zhang, Xiantao
> Subject: Re: [Xen-devel] [PATCH] VT-d: split .ack and .disable DMA-MSI
> actors
> 
> >>> On 07.09.12 at 17:05, Keir Fraser <keir.xen@gmail.com> wrote:
> > On 07/09/2012 13:45, "Jan Beulich" <JBeulich@suse.com> wrote:
> >
> >> Calling irq_complete_move() from .disable is wrong, breaking S3 resume.
> >>
> >> Comparing with all other .ack actors, it was also missing a call to
> >> move_{native,masked}_irq(). As the actor is masking its interrupt
> >> anyway (albeit it's not immediately obvious why), the latter is the
> >> better choice.
> >>
> >> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> >
> > As far as I understand it
> > Acked-by: Keir Fraser <keir@xen.org>
> >
> > I guess you are looking for an Intel ack as well.
> 
> Yes, that's why I Cc-ed Xiantao.
Thanks for the fix!  
Acked-by Xiantao Zhang <xiantao.zhang@intel.com>!  
Xiantao

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 10 06:03:30 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Sep 2012 06:03:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TAx5A-0004N9-2A; Mon, 10 Sep 2012 06:02:52 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dongxiao.xu@intel.com>) id 1TAx58-0004N4-5u
	for xen-devel@lists.xen.org; Mon, 10 Sep 2012 06:02:50 +0000
Received: from [85.158.138.51:32511] by server-9.bemta-3.messagelabs.com id
	3D/C8-15390-9828D405; Mon, 10 Sep 2012 06:02:49 +0000
X-Env-Sender: dongxiao.xu@intel.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1347256967!29678081!1
X-Originating-IP: [143.182.124.21]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMjEgPT4gMTk5MDIw\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30119 invoked from network); 10 Sep 2012 06:02:48 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (143.182.124.21)
	by server-5.tower-174.messagelabs.com with SMTP;
	10 Sep 2012 06:02:48 -0000
Received: from azsmga002.ch.intel.com ([10.2.17.35])
	by azsmga101.ch.intel.com with ESMTP; 09 Sep 2012 23:02:43 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.80,396,1344236400"; d="scan'208";a="143228735"
Received: from fmsmsx105.amr.corp.intel.com ([10.19.9.36])
	by AZSMGA002.ch.intel.com with ESMTP; 09 Sep 2012 23:02: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; Sun, 9 Sep 2012 23:02:42 -0700
Received: from shsmsx102.ccr.corp.intel.com ([169.254.2.92]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.175]) with mapi id
	14.01.0355.002; Mon, 10 Sep 2012 14:02:41 +0800
From: "Xu, Dongxiao" <dongxiao.xu@intel.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Thread-Topic: [Xen-devel] [PATCH v2] QEMU/helper2.c: Fix multiply issue for
	int and uint types
Thread-Index: AQHNhHdrsXuOhAVdY0qodBlTqsyjTpd7G+uQgAgNbqA=
Date: Mon, 10 Sep 2012 06:02:40 +0000
Message-ID: <40776A41FC278F40B59438AD47D147A90FE33BC3@SHSMSX102.ccr.corp.intel.com>
References: <40776A41FC278F40B59438AD47D147A90FE17D93@SHSMSX102.ccr.corp.intel.com>
	<alpine.DEB.2.02.1208201621330.15568@kaball.uk.xensource.com>
	<40776A41FC278F40B59438AD47D147A90FE1D78C@SHSMSX102.ccr.corp.intel.com>
	<alpine.DEB.2.02.1208241220400.15568@kaball.uk.xensource.com>
	<40776A41FC278F40B59438AD47D147A90FE1F771@SHSMSX102.ccr.corp.intel.com>
	<alpine.DEB.2.02.1208271812020.15568@kaball.uk.xensource.com> 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>, "Keir \(Xen.org\)" <keir@xen.org>,
	"Dugger, Donald D" <donald.d.dugger@intel.com>,
	Jan Beulich <JBeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v2] QEMU/helper2.c: Fix multiply issue for
 int and uint types
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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: Xu, Dongxiao
> Sent: Wednesday, September 05, 2012 11:01 AM
> To: Stefano Stabellini
> Cc: Keir (Xen.org); Jan Beulich; Ian Jackson; xen-devel@lists.xen.org
> Subject: RE: [Xen-devel] [PATCH v2] QEMU/helper2.c: Fix multiply issue for int
> and uint types
> 
> > On Mon, 27 Aug 2012, Xu, Dongxiao wrote:
> > > > -----Original Message-----
> > > > From: Stefano Stabellini [mailto:stefano.stabellini@eu.citrix.com]
> > > > Sent: Friday, August 24, 2012 7:25 PM
> > > > To: Xu, Dongxiao
> > > > Cc: Stefano Stabellini; Keir (Xen.org); Jan Beulich; Ian Jackson;
> > > > xen-devel@lists.xen.org
> > > > Subject: RE: [Xen-devel] [PATCH v2] QEMU/helper2.c: Fix multiply
> > > > issue for int and uint types
> > > >
> > > >
> > > > I can only speak for qemu-upstream-unstable, but I'll certainly
> > > > backport the int/uint fix as soon as it gets accepted in QEMU upstream.
> > > >
> > > > Regarding the other patches, if any of them are for
> > > > qemu-upstream-unstable, I am going to backport them only if they
> > > > are
> > bugfixes.
> > >
> > > It seems that the int/uint patch is already merged by Anthony L, see
> > > commit
> > b100fcfe4966aa41d4d6908d0c4c510bcf8f82dd.
> >
> > Thanks for letting me know.
> > I am current away on a conference but I'll try to get the backport
> > done by the end of the week nonetheless.
> 
> Hi Stefano,
> 
> It seems that the patch is still not in qemu-xen repo, could you help to backport
> it?

I saw both Xen and qemu-xen are tagged as RC4, however this fix is still not there. 

Without this fix, I think L1 Xen could not boot on L0 Xen successfully.

Thanks,
Dongxiao

> 
> Thanks,
> Dongxiao
> 
> >
> >
> > > Sorry I have been running away from Xen list for a long time and not
> > > familiar
> > with the current rules.
> > > For QEMU bug fixes, is it the regulation that patch developer need
> > > to fix the
> > QEMU upstream, and Stefano will be in charge to backport it? Or patch
> > developer needs to fix both?
> >
> > That's right: fix needs to be upstream first then I'll backport it.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 10 06:03:30 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Sep 2012 06:03:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TAx5A-0004N9-2A; Mon, 10 Sep 2012 06:02:52 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dongxiao.xu@intel.com>) id 1TAx58-0004N4-5u
	for xen-devel@lists.xen.org; Mon, 10 Sep 2012 06:02:50 +0000
Received: from [85.158.138.51:32511] by server-9.bemta-3.messagelabs.com id
	3D/C8-15390-9828D405; Mon, 10 Sep 2012 06:02:49 +0000
X-Env-Sender: dongxiao.xu@intel.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1347256967!29678081!1
X-Originating-IP: [143.182.124.21]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMjEgPT4gMTk5MDIw\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30119 invoked from network); 10 Sep 2012 06:02:48 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (143.182.124.21)
	by server-5.tower-174.messagelabs.com with SMTP;
	10 Sep 2012 06:02:48 -0000
Received: from azsmga002.ch.intel.com ([10.2.17.35])
	by azsmga101.ch.intel.com with ESMTP; 09 Sep 2012 23:02:43 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.80,396,1344236400"; d="scan'208";a="143228735"
Received: from fmsmsx105.amr.corp.intel.com ([10.19.9.36])
	by AZSMGA002.ch.intel.com with ESMTP; 09 Sep 2012 23:02: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; Sun, 9 Sep 2012 23:02:42 -0700
Received: from shsmsx102.ccr.corp.intel.com ([169.254.2.92]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.175]) with mapi id
	14.01.0355.002; Mon, 10 Sep 2012 14:02:41 +0800
From: "Xu, Dongxiao" <dongxiao.xu@intel.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Thread-Topic: [Xen-devel] [PATCH v2] QEMU/helper2.c: Fix multiply issue for
	int and uint types
Thread-Index: AQHNhHdrsXuOhAVdY0qodBlTqsyjTpd7G+uQgAgNbqA=
Date: Mon, 10 Sep 2012 06:02:40 +0000
Message-ID: <40776A41FC278F40B59438AD47D147A90FE33BC3@SHSMSX102.ccr.corp.intel.com>
References: <40776A41FC278F40B59438AD47D147A90FE17D93@SHSMSX102.ccr.corp.intel.com>
	<alpine.DEB.2.02.1208201621330.15568@kaball.uk.xensource.com>
	<40776A41FC278F40B59438AD47D147A90FE1D78C@SHSMSX102.ccr.corp.intel.com>
	<alpine.DEB.2.02.1208241220400.15568@kaball.uk.xensource.com>
	<40776A41FC278F40B59438AD47D147A90FE1F771@SHSMSX102.ccr.corp.intel.com>
	<alpine.DEB.2.02.1208271812020.15568@kaball.uk.xensource.com> 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>, "Keir \(Xen.org\)" <keir@xen.org>,
	"Dugger, Donald D" <donald.d.dugger@intel.com>,
	Jan Beulich <JBeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v2] QEMU/helper2.c: Fix multiply issue for
 int and uint types
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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: Xu, Dongxiao
> Sent: Wednesday, September 05, 2012 11:01 AM
> To: Stefano Stabellini
> Cc: Keir (Xen.org); Jan Beulich; Ian Jackson; xen-devel@lists.xen.org
> Subject: RE: [Xen-devel] [PATCH v2] QEMU/helper2.c: Fix multiply issue for int
> and uint types
> 
> > On Mon, 27 Aug 2012, Xu, Dongxiao wrote:
> > > > -----Original Message-----
> > > > From: Stefano Stabellini [mailto:stefano.stabellini@eu.citrix.com]
> > > > Sent: Friday, August 24, 2012 7:25 PM
> > > > To: Xu, Dongxiao
> > > > Cc: Stefano Stabellini; Keir (Xen.org); Jan Beulich; Ian Jackson;
> > > > xen-devel@lists.xen.org
> > > > Subject: RE: [Xen-devel] [PATCH v2] QEMU/helper2.c: Fix multiply
> > > > issue for int and uint types
> > > >
> > > >
> > > > I can only speak for qemu-upstream-unstable, but I'll certainly
> > > > backport the int/uint fix as soon as it gets accepted in QEMU upstream.
> > > >
> > > > Regarding the other patches, if any of them are for
> > > > qemu-upstream-unstable, I am going to backport them only if they
> > > > are
> > bugfixes.
> > >
> > > It seems that the int/uint patch is already merged by Anthony L, see
> > > commit
> > b100fcfe4966aa41d4d6908d0c4c510bcf8f82dd.
> >
> > Thanks for letting me know.
> > I am current away on a conference but I'll try to get the backport
> > done by the end of the week nonetheless.
> 
> Hi Stefano,
> 
> It seems that the patch is still not in qemu-xen repo, could you help to backport
> it?

I saw both Xen and qemu-xen are tagged as RC4, however this fix is still not there. 

Without this fix, I think L1 Xen could not boot on L0 Xen successfully.

Thanks,
Dongxiao

> 
> Thanks,
> Dongxiao
> 
> >
> >
> > > Sorry I have been running away from Xen list for a long time and not
> > > familiar
> > with the current rules.
> > > For QEMU bug fixes, is it the regulation that patch developer need
> > > to fix the
> > QEMU upstream, and Stefano will be in charge to backport it? Or patch
> > developer needs to fix both?
> >
> > That's right: fix needs to be upstream first then I'll backport it.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 10 08:38:46 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Sep 2012 08:38:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TAzVP-0005Tq-OH; Mon, 10 Sep 2012 08:38:07 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <thanos.makatos@citrix.com>) id 1TAzVO-0005Tl-Tv
	for xen-devel@lists.xensource.com; Mon, 10 Sep 2012 08:38:07 +0000
Received: from [85.158.139.83:58779] by server-11.bemta-5.messagelabs.com id
	B8/8F-24658-EE6AD405; Mon, 10 Sep 2012 08:38:06 +0000
X-Env-Sender: thanos.makatos@citrix.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1347266285!29366331!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTIzMzg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13095 invoked from network); 10 Sep 2012 08:38:05 -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;
	10 Sep 2012 08:38:05 -0000
X-IronPort-AV: E=Sophos;i="4.80,396,1344211200"; d="scan'208";a="14435189"
Received: from lonpmailmx02.citrite.net ([10.30.203.163])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Sep 2012 08:38:04 +0000
Received: from LONPMAILBOX01.citrite.net ([10.30.224.160]) by
	LONPMAILMX02.citrite.net ([10.30.203.163]) with mapi; Mon, 10 Sep 2012
	09:38:05 +0100
From: Thanos Makatos <thanos.makatos@citrix.com>
To: Joseph Glanville <joseph.glanville@orionvm.com.au>, "Keir (Xen.org)"
	<keir@xen.org>
Date: Mon, 10 Sep 2012 09:38:02 +0100
Thread-Topic: [Xen-devel] blktap3 in C++?
Thread-Index: Ac2NPPWDIAELvE8kR9ik4cAIRSrY5AB8oxCg
Message-ID: <4B45B535F7F6BE4CB1C044ED5115CDDE011A6DAD78D4@LONPMAILBOX01.citrite.net>
References: <4B45B535F7F6BE4CB1C044ED5115CDDE011A6DAD77DF@LONPMAILBOX01.citrite.net>
	<CC6FCF98.4AF76%keir@xen.org>
	<CAOzFzEhVuWAhQfQKQSS5ztWaWUTTBfn_1eKqJqit3EX-sK-DOA@mail.gmail.com>
In-Reply-To: <CAOzFzEhVuWAhQfQKQSS5ztWaWUTTBfn_1eKqJqit3EX-sK-DOA@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] blktap3 in C++?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Blktap3 is not yet in xen-unstable, I'm working on cleaning it up. You can find it here: http://lists.xen.org/archives/html/xen-devel/2012-08/msg00853.html

> -----Original Message-----
> From: Joseph Glanville [mailto:joseph.glanville@orionvm.com.au]
> Sent: 07 September 2012 22:09
> To: Keir (Xen.org)
> Cc: Thanos Makatos; xen-devel@lists.xensource.com
> Subject: Re: [Xen-devel] blktap3 in C++?
> 
> On 8 September 2012 01:21, Keir Fraser <keir@xen.org> wrote:
> > On 07/09/2012 16:08, "Thanos Makatos" <thanos.makatos@citrix.com>
> wrote:
> >
> >> I was wondering whether it would make sense to have blktap3 in C++.
> I
> >> don't have very strong feelings about it; I'd prefer to have it in
> >> C++, but it's already written in C and it works. The benefits of
> >> having it in C++ would be code clarity and maintainability. I bring
> >> this up now because I'm currently cleaning it up, so it's the best
> time to do it, should we decide to do so.
> >
> > Leave it be, and learn how to write maintainable C code!
> 
> Hehe a personal opinion is that C is a more readable/maintainable
> language because it is fundamentally simpler. :)
> 
> With that said, where can I find the source for blktap3? is it in the
> xen-unstable.hg?
> 
> >
> >> --
> >> Thanos Makatos
> 
> Cheers,
> 
> Joseph.
> 
> --
> CTO | Orion Virtualisation Solutions | www.orionvm.com.au
> Phone: 1300 56 99 52 | Mobile: 0428 754 846

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 10 08:38:46 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Sep 2012 08:38:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TAzVP-0005Tq-OH; Mon, 10 Sep 2012 08:38:07 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <thanos.makatos@citrix.com>) id 1TAzVO-0005Tl-Tv
	for xen-devel@lists.xensource.com; Mon, 10 Sep 2012 08:38:07 +0000
Received: from [85.158.139.83:58779] by server-11.bemta-5.messagelabs.com id
	B8/8F-24658-EE6AD405; Mon, 10 Sep 2012 08:38:06 +0000
X-Env-Sender: thanos.makatos@citrix.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1347266285!29366331!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTIzMzg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13095 invoked from network); 10 Sep 2012 08:38:05 -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;
	10 Sep 2012 08:38:05 -0000
X-IronPort-AV: E=Sophos;i="4.80,396,1344211200"; d="scan'208";a="14435189"
Received: from lonpmailmx02.citrite.net ([10.30.203.163])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Sep 2012 08:38:04 +0000
Received: from LONPMAILBOX01.citrite.net ([10.30.224.160]) by
	LONPMAILMX02.citrite.net ([10.30.203.163]) with mapi; Mon, 10 Sep 2012
	09:38:05 +0100
From: Thanos Makatos <thanos.makatos@citrix.com>
To: Joseph Glanville <joseph.glanville@orionvm.com.au>, "Keir (Xen.org)"
	<keir@xen.org>
Date: Mon, 10 Sep 2012 09:38:02 +0100
Thread-Topic: [Xen-devel] blktap3 in C++?
Thread-Index: Ac2NPPWDIAELvE8kR9ik4cAIRSrY5AB8oxCg
Message-ID: <4B45B535F7F6BE4CB1C044ED5115CDDE011A6DAD78D4@LONPMAILBOX01.citrite.net>
References: <4B45B535F7F6BE4CB1C044ED5115CDDE011A6DAD77DF@LONPMAILBOX01.citrite.net>
	<CC6FCF98.4AF76%keir@xen.org>
	<CAOzFzEhVuWAhQfQKQSS5ztWaWUTTBfn_1eKqJqit3EX-sK-DOA@mail.gmail.com>
In-Reply-To: <CAOzFzEhVuWAhQfQKQSS5ztWaWUTTBfn_1eKqJqit3EX-sK-DOA@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] blktap3 in C++?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Blktap3 is not yet in xen-unstable, I'm working on cleaning it up. You can find it here: http://lists.xen.org/archives/html/xen-devel/2012-08/msg00853.html

> -----Original Message-----
> From: Joseph Glanville [mailto:joseph.glanville@orionvm.com.au]
> Sent: 07 September 2012 22:09
> To: Keir (Xen.org)
> Cc: Thanos Makatos; xen-devel@lists.xensource.com
> Subject: Re: [Xen-devel] blktap3 in C++?
> 
> On 8 September 2012 01:21, Keir Fraser <keir@xen.org> wrote:
> > On 07/09/2012 16:08, "Thanos Makatos" <thanos.makatos@citrix.com>
> wrote:
> >
> >> I was wondering whether it would make sense to have blktap3 in C++.
> I
> >> don't have very strong feelings about it; I'd prefer to have it in
> >> C++, but it's already written in C and it works. The benefits of
> >> having it in C++ would be code clarity and maintainability. I bring
> >> this up now because I'm currently cleaning it up, so it's the best
> time to do it, should we decide to do so.
> >
> > Leave it be, and learn how to write maintainable C code!
> 
> Hehe a personal opinion is that C is a more readable/maintainable
> language because it is fundamentally simpler. :)
> 
> With that said, where can I find the source for blktap3? is it in the
> xen-unstable.hg?
> 
> >
> >> --
> >> Thanos Makatos
> 
> Cheers,
> 
> Joseph.
> 
> --
> CTO | Orion Virtualisation Solutions | www.orionvm.com.au
> Phone: 1300 56 99 52 | Mobile: 0428 754 846

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 10 08:53:24 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Sep 2012 08:53:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TAzjj-0005tV-Ol; Mon, 10 Sep 2012 08:52:55 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <aware.why@gmail.com>) id 1TAzjh-0005tF-EI
	for xen-devel@lists.xensource.com; Mon, 10 Sep 2012 08:52:53 +0000
X-Env-Sender: aware.why@gmail.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1347267166!2645056!1
X-Originating-IP: [74.125.82.43]
X-SpamReason: No, hits=0.9 required=7.0 tests=HTML_60_70,HTML_MESSAGE,
	MIME_BASE64_TEXT,ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8037 invoked from network); 10 Sep 2012 08:52:46 -0000
Received: from mail-wg0-f43.google.com (HELO mail-wg0-f43.google.com)
	(74.125.82.43)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Sep 2012 08:52:46 -0000
Received: by wgbdr1 with SMTP id dr1so1262312wgb.24
	for <xen-devel@lists.xensource.com>;
	Mon, 10 Sep 2012 01:52: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=wbJpfAaVK7v1tfrMSctnJHZnsXTlh8Fz5U7k5sK5/rA=;
	b=MFtcVvSb54IxqIwHho+RlZXacen+uIV8NkjahWNzMP7+tkQQRtL/9e6KcL/OS5HMOZ
	1+U4372fg4jpMO0sl+hm5naM6KPOwF65tIRTgmmTVyK8gRoqSNYx6OCCJO5siwGIfEAv
	/5x8+eyukPzv9h0MqeRppywvOEFpXXZkTzmZYRFT/IDaSW6ahhmZOnxYoiO+Ap6Ak01c
	rTDVPi8R6J2vDhjZ0+iB08ZoM9YFctHGfkVvjWAGnO543mfu/naxPHJpRxweL7dAILzN
	lsX7cmdZdq6WrQxWDm+M4TOzhSnhfqZtLWwJhgd66k0b/OBavUhAvzFc6/AcEjEgLgOp
	G0Rg==
MIME-Version: 1.0
Received: by 10.216.235.197 with SMTP id u47mr7699523weq.180.1347267164998;
	Mon, 10 Sep 2012 01:52:44 -0700 (PDT)
Received: by 10.223.12.69 with HTTP; Mon, 10 Sep 2012 01:52:44 -0700 (PDT)
Date: Mon, 10 Sep 2012 16:52:44 +0800
Message-ID: <CA+ePHTCoBnoBRsjGVsMtY3B4BPMA6FopjkF4DGCoX+Mn1JiAfQ@mail.gmail.com>
From: =?UTF-8?B?6ams56OK?= <aware.why@gmail.com>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [Problem with xen-4.1.2] Creating device model failed
 when disable `-vnc` related options in qemu-dm
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============2658105266713236670=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============2658105266713236670==
Content-Type: multipart/alternative; boundary=001517573c88c98e4304c9551406

--001517573c88c98e4304c9551406
Content-Type: text/plain; charset=ISO-8859-1

Hi all,
    In xen-4.1.2 src/tools/libxl/libxl_dm.c, there is a function called
`libxl_build_device_model_args_old`,  the func will build qemu-dm cmdline
args according to
the xl-formated configuration file specified by xl create command. There
are several lines related to vnc option:

 76    if (info->vnc || info->vncdisplay || info->vnclisten ||
info->vncunused ) {


 77        char *vncarg;



 78        if (ctx->disable_vnc)



 79          {



 80            INFO("skipped vnc...");



 81            goto skip_vnc;



 82          }



 83          ...skip....


the red part above is added by me for testing forcing to disable vnc in
consideration of performance.
But what I got was that the qemu-dm without vnc related options failed to
create device model.

In my case, the vm id is 2, the* qemu-dm log info*(not truncated) is as
follows:


domid: 2
-videoram option does not work with cirrus vga device model. Videoram set
to 4M.
Strip off blktap sub-type prefix to /home/malei/c2.delta.img (drv 'qcow2')
Using file /home/malei/c2.delta.img in read-write mode
Strip off blktap sub-type prefix to /home/malei/d2.delta.img (drv 'qcow2')
Using file /home/malei/d2.delta.img in read-write 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/4
qemu_map_cache_init nr_buckets = 10000 size 4194304
shared page at pfn feffd
buffered io page at pfn feffb
Guest uuid = d06b08f0-491f-43d6-9a01-ac317aea5034
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.
qemu: match NIC model: rtl8139
pci_rtl8139_init: s->macaddr: 0 16 3e eb ca 66
xs_read(/local/domain/0/device-model/2/xen_extended_power_mgmt): read
error

* (stop here, but the normal log should contains other lines like *
*device model state set to running*

*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/1/log-throttling): read error*

*qemu: ignoring not-understood drive `/local/domain/1/log-throttling'*

*medium change watch on `/local/domain/1/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.)*


and the* xl log info* is:


Waiting for domain xp-102 (domid 2) to die [pid 14006]
Domain 2 is dead
Unknown shutdown reason code 255. Destroying domain.
Action for shutdown reason code 255 is destroy
Domain 2 needs to be cleaned up: destroying the domain
libxl: error: libxl_dm.c:779:libxl__destroy_device_model Couldn't find
device model's pid: No such file or directory
libxl: error: libxl.c:752:libxl_domain_destroy libxl__destroy_device_model
failed for 2
Done. Exiting now


I dig into the src/tools/ioemu-qemu-xen/i386-dm/helper2.c,  found  the
function :

553-int main_loop(void)



554{



555    CPUState *env = cpu_single_env;



556    int evtchn_fd = xce_handle == NULL ? -1 : xc_evtchn_fd(xce_handle);



557    char *qemu_file;



558    fd_set fds;



559



560    main_loop_prepare();



561



562    buffered_io_timer = qemu_new_timer(rt_clock, handle_buffered_io,



563                                       cpu_single_env);



564    qemu_mod_timer(buffered_io_timer, qemu_get_clock(rt_clock));



565



566    if (evtchn_fd != -1)



567        qemu_set_fd_handler(evtchn_fd, cpu_handle_ioreq, NULL, env);



568



569    fprintf(logfile, "device model state set to running\n");



570    xenstore_record_dm_state("running");
*
*

*In normal circumstance, the qemu-dm log info will record the red line
above, but when disable vnc, it seems that it didn't go  into the function
`main_loop` and didn't see that line.*
*What happend to that and How to disable the vnc ?*

--001517573c88c98e4304c9551406
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: base64

SGkgYWxsLDxkaXY+oCCgIEluIHhlbi00LjEuMiBzcmMvdG9vbHMvbGlieGwvbGlieGxfZG0uYywg
dGhlcmUgaXMgYSBmdW5jdGlvbiBjYWxsZWQgYGxpYnhsX2J1aWxkX2RldmljZV9tb2RlbF9hcmdz
X29sZGAsIKB0aGUgZnVuYyB3aWxsIGJ1aWxkIHFlbXUtZG0gY21kbGluZSBhcmdzIGFjY29yZGlu
ZyB0bzwvZGl2PjxkaXY+dGhlIHhsLWZvcm1hdGVkIGNvbmZpZ3VyYXRpb24gZmlsZSBzcGVjaWZp
ZWQgYnkgeGwgY3JlYXRlIGNvbW1hbmQuIFRoZXJlIGFyZSBzZXZlcmFsIGxpbmVzIHJlbGF0ZWQg
dG8gdm5jIG9wdGlvbjo8L2Rpdj4KPGRpdj48YnI+PC9kaXY+PGJsb2NrcXVvdGUgc3R5bGU9Im1h
cmdpbjowIDAgMCA0MHB4O2JvcmRlcjpub25lO3BhZGRpbmc6MHB4Ij48ZGl2PjxkaXY+oDc2IKAg
oGlmIChpbmZvLSZndDt2bmMgfHwgaW5mby0mZ3Q7dm5jZGlzcGxheSB8fCBpbmZvLSZndDt2bmNs
aXN0ZW4gfHwgaW5mby0mZ3Q7dm5jdW51c2VkICkgeyCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCg
IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAg
oCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCg
IKAgoCCgIKAgoCCgIKA8L2Rpdj4KPC9kaXY+PGRpdj48ZGl2PqA3NyCgIKAgoCCgY2hhciAqdm5j
YXJnOyCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAg
oCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCg
IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAg
oCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgPC9kaXY+CjwvZGl2
PjxkaXY+PGRpdj6gPGZvbnQgY29sb3I9IiNmZjAwMDAiPjc4IKAgoCCgIKBpZiAoY3R4LSZndDtk
aXNhYmxlX3ZuYykgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCg
IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAg
oCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCg
IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKA8L2ZvbnQ+PC9kaXY+
CjwvZGl2PjxkaXY+PGRpdj48Zm9udCBjb2xvcj0iI2ZmMDAwMCI+oDc5IKAgoCCgIKAgoHsgoCCg
IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAg
oCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCg
IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAg
oCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKA8L2ZvbnQ+PC9k
aXY+CjwvZGl2PjxkaXY+PGRpdj48Zm9udCBjb2xvcj0iI2ZmMDAwMCI+oDgwIKAgoCCgIKAgoCCg
SU5GTygmcXVvdDtza2lwcGVkIHZuYy4uLiZxdW90Oyk7IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCg
IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAg
oCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCg
IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAg
oCCgPC9mb250PjwvZGl2Pgo8L2Rpdj48ZGl2PjxkaXY+PGZvbnQgY29sb3I9IiNmZjAwMDAiPqA4
MSCgIKAgoCCgIKAgoGdvdG8gc2tpcF92bmM7IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCg
IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAg
oCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCg
IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAg
oCCgIKCgPC9mb250PjwvZGl2Pgo8L2Rpdj48ZGl2PjxkaXY+PGZvbnQgY29sb3I9IiNmZjAwMDAi
PqA4MiCgIKAgoCCgIKB9IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCA8L2ZvbnQ+PC9kaXY+oCCgIKAg
oCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCg
IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAg
oCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCg
IKAgoCCgIKAgoCCgIKAgoCCgIKAgoDwvZGl2Pgo8ZGl2PjxkaXY+oDgzIKAgoCCgIKAgoC4uLnNr
aXAuLi4uIKAgoCCgIKAgoCCgIKAgoCCgPC9kaXY+PC9kaXY+PC9ibG9ja3F1b3RlPjxkaXY+PGJy
PjwvZGl2PjxkaXY+dGhlIHJlZCBwYXJ0IGFib3ZlIGlzIGFkZGVkIGJ5IG1lIGZvciB0ZXN0aW5n
IGZvcmNpbmcgdG8gZGlzYWJsZSB2bmMgaW4gY29uc2lkZXJhdGlvbiBvZiBwZXJmb3JtYW5jZS48
L2Rpdj48ZGl2PkJ1dCB3aGF0IEkgZ290IHdhcyB0aGF0IHRoZSBxZW11LWRtIHdpdGhvdXQgdm5j
IHJlbGF0ZWQgb3B0aW9ucyBmYWlsZWQgdG8gY3JlYXRlIGRldmljZSBtb2RlbC48L2Rpdj4KPGRp
dj48YnI+PC9kaXY+PGRpdj5JbiBteSBjYXNlLCB0aGUgdm0gaWQgaXMgMiwgdGhlPGI+IHFlbXUt
ZG0gbG9nIGluZm88L2I+KG5vdCB0cnVuY2F0ZWQpIGlzIGFzIGZvbGxvd3M6PC9kaXY+PGRpdj6g
PC9kaXY+PGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbjowIDAgMCA0MHB4O2JvcmRlcjpub25lO3Bh
ZGRpbmc6MHB4Ij48ZGl2PmRvbWlkOiAyPC9kaXY+PGRpdj4tdmlkZW9yYW0gb3B0aW9uIGRvZXMg
bm90IHdvcmsgd2l0aCBjaXJydXMgdmdhIGRldmljZSBtb2RlbC4gVmlkZW9yYW0gc2V0IHRvIDRN
LjwvZGl2Pgo8ZGl2PlN0cmlwIG9mZiBibGt0YXAgc3ViLXR5cGUgcHJlZml4IHRvIC9ob21lL21h
bGVpL2MyLmRlbHRhLmltZyAoZHJ2ICYjMzk7cWNvdzImIzM5Oyk8L2Rpdj48ZGl2PlVzaW5nIGZp
bGUgL2hvbWUvbWFsZWkvYzIuZGVsdGEuaW1nIGluIHJlYWQtd3JpdGUgbW9kZTwvZGl2PjxkaXY+
U3RyaXAgb2ZmIGJsa3RhcCBzdWItdHlwZSBwcmVmaXggdG8gL2hvbWUvbWFsZWkvZDIuZGVsdGEu
aW1nIChkcnYgJiMzOTtxY293MiYjMzk7KTwvZGl2Pgo8ZGl2PlVzaW5nIGZpbGUgL2hvbWUvbWFs
ZWkvZDIuZGVsdGEuaW1nIGluIHJlYWQtd3JpdGUgbW9kZTwvZGl2PjxkaXY+V2F0Y2hpbmcgL2xv
Y2FsL2RvbWFpbi8wL2RldmljZS1tb2RlbC8yL2xvZ2RpcnR5L2NtZDwvZGl2PjxkaXY+V2F0Y2hp
bmcgL2xvY2FsL2RvbWFpbi8wL2RldmljZS1tb2RlbC8yL2NvbW1hbmQ8L2Rpdj48ZGl2PldhdGNo
aW5nIC9sb2NhbC9kb21haW4vMi9jcHU8L2Rpdj4KPGRpdj5jaGFyIGRldmljZSByZWRpcmVjdGVk
IHRvIC9kZXYvcHRzLzQ8L2Rpdj48ZGl2PnFlbXVfbWFwX2NhY2hlX2luaXQgbnJfYnVja2V0cyA9
IDEwMDAwIHNpemUgNDE5NDMwNDwvZGl2PjxkaXY+c2hhcmVkIHBhZ2UgYXQgcGZuIGZlZmZkPC9k
aXY+PGRpdj5idWZmZXJlZCBpbyBwYWdlIGF0IHBmbiBmZWZmYjwvZGl2PjxkaXY+R3Vlc3QgdXVp
ZCA9IGQwNmIwOGYwLTQ5MWYtNDNkNi05YTAxLWFjMzE3YWVhNTAzNDwvZGl2Pgo8ZGl2PnBvcHVs
YXRpbmcgdmlkZW8gUkFNIGF0IGZmMDAwMDAwPC9kaXY+PGRpdj5tYXBwaW5nIHZpZGVvIFJBTSBm
cm9tIGZmMDAwMDAwPC9kaXY+PGRpdj5SZWdpc3RlciB4ZW4gcGxhdGZvcm0uPC9kaXY+PGRpdj5E
b25lIHJlZ2lzdGVyIHBsYXRmb3JtLjwvZGl2PjxkaXY+cGxhdGZvcm1fZml4ZWRfaW9wb3J0OiBj
aGFuZ2VkIHJvL3J3IHN0YXRlIG9mIFJPTSBtZW1vcnkgYXJlYS4gbm93IGlzIHJ3IHN0YXRlLjwv
ZGl2Pgo8ZGl2PnFlbXU6IG1hdGNoIE5JQyBtb2RlbDogcnRsODEzOTwvZGl2PjxkaXY+cGNpX3J0
bDgxMzlfaW5pdDogcy0mZ3Q7bWFjYWRkcjogMCAxNiAzZSBlYiBjYSA2NjwvZGl2PjxkaXY+eHNf
cmVhZCgvbG9jYWwvZG9tYWluLzAvZGV2aWNlLW1vZGVsLzIveGVuX2V4dGVuZGVkX3Bvd2VyX21n
bXQpOiByZWFkIGVycm9yoCCgoDwvZGl2PjwvYmxvY2txdW90ZT48YmxvY2txdW90ZSBzdHlsZT0i
bWFyZ2luOjAgMCAwIDQwcHg7Ym9yZGVyOm5vbmU7cGFkZGluZzowcHgiPgo8YmxvY2txdW90ZSBz
dHlsZT0ibWFyZ2luOjAgMCAwIDQwcHg7Ym9yZGVyOm5vbmU7cGFkZGluZzowcHgiPjxkaXY+PHU+
oCg8c3BhbiBzdHlsZT0iYmFja2dyb3VuZC1jb2xvcjpyZ2IoMjU1LDEwMiwxMDIpIj5zdG9wIGhl
cmUsIGJ1dCB0aGUgbm9ybWFsIGxvZyBzaG91bGQgY29udGFpbnMgb3RoZXIgbGluZXMgbGlrZTwv
c3Bhbj6gPC91PjwvZGl2PjxkaXY+PHU+ZGV2aWNlIG1vZGVsIHN0YXRlIHNldCB0byBydW5uaW5n
PC91PjwvZGl2Pgo8L2Jsb2NrcXVvdGU+PGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbjowIDAgMCA0
MHB4O2JvcmRlcjpub25lO3BhZGRpbmc6MHB4Ij48ZGl2Pjx1PkxvZy1kaXJ0eTogbm8gY29tbWFu
ZCB5ZXQuPC91PjwvZGl2PjwvYmxvY2txdW90ZT48YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luOjAg
MCAwIDQwcHg7Ym9yZGVyOm5vbmU7cGFkZGluZzowcHgiPjxkaXY+PHU+SS9PIHJlcXVlc3Qgbm90
IHJlYWR5OiAwLCBwdHI6IDAsIHBvcnQ6IDAsIGRhdGE6IDAsIGNvdW50OiAwLCBzaXplOiAwPC91
PjwvZGl2Pgo8L2Jsb2NrcXVvdGU+PGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbjowIDAgMCA0MHB4
O2JvcmRlcjpub25lO3BhZGRpbmc6MHB4Ij48ZGl2Pjx1PnZjcHUtc2V0OiB3YXRjaCBub2RlIGVy
cm9yLjwvdT48L2Rpdj48L2Jsb2NrcXVvdGU+PGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbjowIDAg
MCA0MHB4O2JvcmRlcjpub25lO3BhZGRpbmc6MHB4Ij48ZGl2Pjx1PnhzX3JlYWQoL2xvY2FsL2Rv
bWFpbi8xL2xvZy10aHJvdHRsaW5nKTogcmVhZCBlcnJvcjwvdT48L2Rpdj4KPC9ibG9ja3F1b3Rl
PjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW46MCAwIDAgNDBweDtib3JkZXI6bm9uZTtwYWRkaW5n
OjBweCI+PGRpdj48dT5xZW11OiBpZ25vcmluZyBub3QtdW5kZXJzdG9vZCBkcml2ZSBgL2xvY2Fs
L2RvbWFpbi8xL2xvZy10aHJvdHRsaW5nJiMzOTs8L3U+PC9kaXY+PC9ibG9ja3F1b3RlPjxibG9j
a3F1b3RlIHN0eWxlPSJtYXJnaW46MCAwIDAgNDBweDtib3JkZXI6bm9uZTtwYWRkaW5nOjBweCI+
CjxkaXY+PHU+bWVkaXVtIGNoYW5nZSB3YXRjaCBvbiBgL2xvY2FsL2RvbWFpbi8xL2xvZy10aHJv
dHRsaW5nJiMzOTsgLSB1bmtub3duIGRldmljZSwgaWdub3JlZDwvdT48L2Rpdj48L2Jsb2NrcXVv
dGU+PGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbjowIDAgMCA0MHB4O2JvcmRlcjpub25lO3BhZGRp
bmc6MHB4Ij48ZGl2Pjx1PmNpcnJ1cyB2Z2EgbWFwIGNoYW5nZSB3aGlsZSBvbiBsZmIgbW9kZTwv
dT48L2Rpdj4KPC9ibG9ja3F1b3RlPjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW46MCAwIDAgNDBw
eDtib3JkZXI6bm9uZTtwYWRkaW5nOjBweCI+PGRpdj48dT5tYXBwaW5nIHZyYW0gdG8gZjAwMDAw
MDAgLSBmMDQwMDAwMDwvdT48L2Rpdj48L2Jsb2NrcXVvdGU+PGJsb2NrcXVvdGUgc3R5bGU9Im1h
cmdpbjowIDAgMCA0MHB4O2JvcmRlcjpub25lO3BhZGRpbmc6MHB4Ij48ZGl2Pjx1PnBsYXRmb3Jt
X2ZpeGVkX2lvcG9ydDogY2hhbmdlZCByby9ydyBzdGF0ZSBvZiBST00gbWVtb3J5IGFyZWEuIG5v
dyBpcyBydyBzdGF0ZS48L3U+PC9kaXY+CjwvYmxvY2txdW90ZT48YmxvY2txdW90ZSBzdHlsZT0i
bWFyZ2luOjAgMCAwIDQwcHg7Ym9yZGVyOm5vbmU7cGFkZGluZzowcHgiPjxkaXY+PHU+cGxhdGZv
cm1fZml4ZWRfaW9wb3J0OiBjaGFuZ2VkIHJvL3J3IHN0YXRlIG9mIFJPTSBtZW1vcnkgYXJlYS4g
bm93IGlzIHJvIHN0YXRlLik8L3U+PC9kaXY+PC9ibG9ja3F1b3RlPjwvYmxvY2txdW90ZT48ZGl2
Pjxicj48L2Rpdj48ZGl2PmFuZCB0aGU8Yj4geGwgbG9nIGluZm88L2I+IGlzOjwvZGl2Pgo8ZGl2
PjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW46MCAwIDAgNDBweDtib3JkZXI6bm9uZTtwYWRkaW5n
OjBweCI+PGRpdj48YnI+PC9kaXY+PGRpdj48ZGl2PldhaXRpbmcgZm9yIGRvbWFpbiB4cC0xMDIg
KGRvbWlkIDIpIHRvIGRpZSBbcGlkIDE0MDA2XTwvZGl2PjwvZGl2PjxkaXY+PGRpdj5Eb21haW4g
MiBpcyBkZWFkPC9kaXY+PC9kaXY+PGRpdj48ZGl2PlVua25vd24gc2h1dGRvd24gcmVhc29uIGNv
ZGUgMjU1LiBEZXN0cm95aW5nIGRvbWFpbi48L2Rpdj4KPC9kaXY+PGRpdj48ZGl2PkFjdGlvbiBm
b3Igc2h1dGRvd24gcmVhc29uIGNvZGUgMjU1IGlzIGRlc3Ryb3k8L2Rpdj48L2Rpdj48ZGl2Pjxk
aXY+RG9tYWluIDIgbmVlZHMgdG8gYmUgY2xlYW5lZCB1cDogZGVzdHJveWluZyB0aGUgZG9tYWlu
PC9kaXY+PC9kaXY+PGRpdj48ZGl2PmxpYnhsOiBlcnJvcjogbGlieGxfZG0uYzo3Nzk6bGlieGxf
X2Rlc3Ryb3lfZGV2aWNlX21vZGVsIENvdWxkbiYjMzk7dCBmaW5kIGRldmljZSBtb2RlbCYjMzk7
cyBwaWQ6IE5vIHN1Y2ggZmlsZSBvciBkaXJlY3Rvcnk8L2Rpdj4KPC9kaXY+PGRpdj48ZGl2Pmxp
YnhsOiBlcnJvcjogbGlieGwuYzo3NTI6bGlieGxfZG9tYWluX2Rlc3Ryb3kgbGlieGxfX2Rlc3Ry
b3lfZGV2aWNlX21vZGVsIGZhaWxlZCBmb3IgMjwvZGl2PjwvZGl2PjxkaXY+PGRpdj5Eb25lLiBF
eGl0aW5nIG5vdzwvZGl2PjwvZGl2PjxkaXY+PGJyPjwvZGl2PjwvYmxvY2txdW90ZT48YnI+PC9k
aXY+PGRpdj5JIGRpZyBpbnRvIHRoZSBzcmMvdG9vbHMvaW9lbXUtcWVtdS14ZW4vaTM4Ni1kbS9o
ZWxwZXIyLmMsIKBmb3VuZCCgdGhlIGZ1bmN0aW9uIDo8L2Rpdj4KPGJsb2NrcXVvdGUgc3R5bGU9
Im1hcmdpbjowIDAgMCA0MHB4O2JvcmRlcjpub25lO3BhZGRpbmc6MHB4Ij48ZGl2PjxkaXY+NTUz
LWludCBtYWluX2xvb3Aodm9pZCkgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAg
oCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCg
IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAg
oCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCg
IKAgoKA8L2Rpdj4KPC9kaXY+PGRpdj48ZGl2PjU1NHsgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAg
oCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCg
IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAg
oCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCg
IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgPC9kaXY+CjwvZGl2PjxkaXY+PGRp
dj41NTUgoCCgQ1BVU3RhdGUgKmVudiA9IGNwdV9zaW5nbGVfZW52OyCgIKAgoCCgIKAgoCCgIKAg
oCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCg
IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAg
oCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCg
IKAgoCCgIKAgoDwvZGl2Pgo8L2Rpdj48ZGl2PjxkaXY+NTU2IKAgoGludCBldnRjaG5fZmQgPSB4
Y2VfaGFuZGxlID09IE5VTEwgPyAtMSA6IHhjX2V2dGNobl9mZCh4Y2VfaGFuZGxlKTsgoCCgIKAg
oCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCg
IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAg
oCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKA8L2Rpdj4KPC9kaXY+PGRp
dj48ZGl2PjU1NyCgIKBjaGFyICpxZW11X2ZpbGU7IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAg
oCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCg
IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAg
oCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCg
IKAgoCCgIKAgoCCgIKCgPC9kaXY+CjwvZGl2PjxkaXY+PGRpdj41NTggoCCgZmRfc2V0IGZkczsg
oCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCg
IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAg
oCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCg
IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoDwvZGl2Pgo8L2Rp
dj48ZGl2PjxkaXY+NTU5IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCg
IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAg
oCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCg
IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAg
oCCgIKAgoCCgIKAgoCCgIKAgoKA8L2Rpdj4KPC9kaXY+PGRpdj48ZGl2PjU2MCCgIKBtYWluX2xv
b3BfcHJlcGFyZSgpOyCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCg
IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAg
oCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCg
IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKCgPC9kaXY+
CjwvZGl2PjxkaXY+PGRpdj41NjEgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAg
oCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCg
IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAg
oCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCg
IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgoDwvZGl2Pgo8L2Rpdj48ZGl2PjxkaXY+NTYyIKAgoGJ1
ZmZlcmVkX2lvX3RpbWVyID0gcWVtdV9uZXdfdGltZXIocnRfY2xvY2ssIGhhbmRsZV9idWZmZXJl
ZF9pbywgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCg
IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAg
oCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoKA8
L2Rpdj4KPC9kaXY+PGRpdj48ZGl2PjU2MyCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCg
IKAgoCCgIGNwdV9zaW5nbGVfZW52KTsgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCg
IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAg
oCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCg
IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgPC9kaXY+CjwvZGl2PjxkaXY+PGRpdj41NjQg
oCCgcWVtdV9tb2RfdGltZXIoYnVmZmVyZWRfaW9fdGltZXIsIHFlbXVfZ2V0X2Nsb2NrKHJ0X2Ns
b2NrKSk7IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAg
oCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCg
IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAg
oCCgoDwvZGl2Pgo8L2Rpdj48ZGl2PjxkaXY+NTY1IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAg
oCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCg
IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAg
oCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCg
IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoKA8L2Rpdj4KPC9kaXY+PGRpdj48ZGl2
PjU2NiCgIKBpZiAoZXZ0Y2huX2ZkICE9IC0xKSCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAg
oCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCg
IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAg
oCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCg
IKAgoCCgIKCgPC9kaXY+CjwvZGl2PjxkaXY+PGRpdj41NjcgoCCgIKAgoHFlbXVfc2V0X2ZkX2hh
bmRsZXIoZXZ0Y2huX2ZkLCBjcHVfaGFuZGxlX2lvcmVxLCBOVUxMLCBlbnYpOyCgIKAgoCCgIKAg
oCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCg
IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAg
oCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgoDwvZGl2Pgo8L2Rpdj48ZGl2
PjxkaXY+NTY4IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCg
IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAg
oCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCg
IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAg
oCCgIKAgoCCgIKAgoKA8L2Rpdj4KPC9kaXY+PGRpdj48ZGl2PjU2OSCgIDxmb250IGNvbG9yPSIj
ZmY2NjY2Ij6gZnByaW50Zihsb2dmaWxlLCAmcXVvdDtkZXZpY2UgbW9kZWwgc3RhdGUgc2V0IHRv
IHJ1bm5pbmdcbiZxdW90Oyk7IKAgoCCgIKAgPC9mb250PqAgoCCgIKAgoCCgIKAgoCCgIKAgoCCg
IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAg
oCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCg
IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKCgPC9kaXY+CjwvZGl2PjxkaXY+PGRpdj41NzAgoCCg
eGVuc3RvcmVfcmVjb3JkX2RtX3N0YXRlKCZxdW90O3J1bm5pbmcmcXVvdDspOyCgPC9kaXY+PC9k
aXY+PGRpdj48Yj48YnI+PC9iPjwvZGl2PjwvYmxvY2txdW90ZT48Yj5JbiBub3JtYWwgY2lyY3Vt
c3RhbmNlLCB0aGUgcWVtdS1kbSBsb2cgaW5mbyB3aWxsIHJlY29yZCB0aGUgcmVkIGxpbmUgYWJv
dmUsIGJ1dCB3aGVuIGRpc2FibGUgdm5jLCBpdCBzZWVtcyB0aGF0IGl0IGRpZG4mIzM5O3QgZ28g
oGludG8gdGhlIGZ1bmN0aW9uIGBtYWluX2xvb3BgIGFuZCBkaWRuJiMzOTt0IHNlZSB0aGF0IGxp
bmUuPC9iPjxkaXY+CjxiPldoYXQgaGFwcGVuZCB0byB0aGF0IGFuZCBIb3cgdG8gZGlzYWJsZSB0
aGUgdm5jID88L2I+PGJyPjxkaXY+PGJyPjwvZGl2PjwvZGl2Pgo=
--001517573c88c98e4304c9551406--


--===============2658105266713236670==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============2658105266713236670==--


From xen-devel-bounces@lists.xen.org Mon Sep 10 08:53:24 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Sep 2012 08:53:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TAzjj-0005tV-Ol; Mon, 10 Sep 2012 08:52:55 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <aware.why@gmail.com>) id 1TAzjh-0005tF-EI
	for xen-devel@lists.xensource.com; Mon, 10 Sep 2012 08:52:53 +0000
X-Env-Sender: aware.why@gmail.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1347267166!2645056!1
X-Originating-IP: [74.125.82.43]
X-SpamReason: No, hits=0.9 required=7.0 tests=HTML_60_70,HTML_MESSAGE,
	MIME_BASE64_TEXT,ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8037 invoked from network); 10 Sep 2012 08:52:46 -0000
Received: from mail-wg0-f43.google.com (HELO mail-wg0-f43.google.com)
	(74.125.82.43)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Sep 2012 08:52:46 -0000
Received: by wgbdr1 with SMTP id dr1so1262312wgb.24
	for <xen-devel@lists.xensource.com>;
	Mon, 10 Sep 2012 01:52: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=wbJpfAaVK7v1tfrMSctnJHZnsXTlh8Fz5U7k5sK5/rA=;
	b=MFtcVvSb54IxqIwHho+RlZXacen+uIV8NkjahWNzMP7+tkQQRtL/9e6KcL/OS5HMOZ
	1+U4372fg4jpMO0sl+hm5naM6KPOwF65tIRTgmmTVyK8gRoqSNYx6OCCJO5siwGIfEAv
	/5x8+eyukPzv9h0MqeRppywvOEFpXXZkTzmZYRFT/IDaSW6ahhmZOnxYoiO+Ap6Ak01c
	rTDVPi8R6J2vDhjZ0+iB08ZoM9YFctHGfkVvjWAGnO543mfu/naxPHJpRxweL7dAILzN
	lsX7cmdZdq6WrQxWDm+M4TOzhSnhfqZtLWwJhgd66k0b/OBavUhAvzFc6/AcEjEgLgOp
	G0Rg==
MIME-Version: 1.0
Received: by 10.216.235.197 with SMTP id u47mr7699523weq.180.1347267164998;
	Mon, 10 Sep 2012 01:52:44 -0700 (PDT)
Received: by 10.223.12.69 with HTTP; Mon, 10 Sep 2012 01:52:44 -0700 (PDT)
Date: Mon, 10 Sep 2012 16:52:44 +0800
Message-ID: <CA+ePHTCoBnoBRsjGVsMtY3B4BPMA6FopjkF4DGCoX+Mn1JiAfQ@mail.gmail.com>
From: =?UTF-8?B?6ams56OK?= <aware.why@gmail.com>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [Problem with xen-4.1.2] Creating device model failed
 when disable `-vnc` related options in qemu-dm
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============2658105266713236670=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============2658105266713236670==
Content-Type: multipart/alternative; boundary=001517573c88c98e4304c9551406

--001517573c88c98e4304c9551406
Content-Type: text/plain; charset=ISO-8859-1

Hi all,
    In xen-4.1.2 src/tools/libxl/libxl_dm.c, there is a function called
`libxl_build_device_model_args_old`,  the func will build qemu-dm cmdline
args according to
the xl-formated configuration file specified by xl create command. There
are several lines related to vnc option:

 76    if (info->vnc || info->vncdisplay || info->vnclisten ||
info->vncunused ) {


 77        char *vncarg;



 78        if (ctx->disable_vnc)



 79          {



 80            INFO("skipped vnc...");



 81            goto skip_vnc;



 82          }



 83          ...skip....


the red part above is added by me for testing forcing to disable vnc in
consideration of performance.
But what I got was that the qemu-dm without vnc related options failed to
create device model.

In my case, the vm id is 2, the* qemu-dm log info*(not truncated) is as
follows:


domid: 2
-videoram option does not work with cirrus vga device model. Videoram set
to 4M.
Strip off blktap sub-type prefix to /home/malei/c2.delta.img (drv 'qcow2')
Using file /home/malei/c2.delta.img in read-write mode
Strip off blktap sub-type prefix to /home/malei/d2.delta.img (drv 'qcow2')
Using file /home/malei/d2.delta.img in read-write 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/4
qemu_map_cache_init nr_buckets = 10000 size 4194304
shared page at pfn feffd
buffered io page at pfn feffb
Guest uuid = d06b08f0-491f-43d6-9a01-ac317aea5034
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.
qemu: match NIC model: rtl8139
pci_rtl8139_init: s->macaddr: 0 16 3e eb ca 66
xs_read(/local/domain/0/device-model/2/xen_extended_power_mgmt): read
error

* (stop here, but the normal log should contains other lines like *
*device model state set to running*

*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/1/log-throttling): read error*

*qemu: ignoring not-understood drive `/local/domain/1/log-throttling'*

*medium change watch on `/local/domain/1/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.)*


and the* xl log info* is:


Waiting for domain xp-102 (domid 2) to die [pid 14006]
Domain 2 is dead
Unknown shutdown reason code 255. Destroying domain.
Action for shutdown reason code 255 is destroy
Domain 2 needs to be cleaned up: destroying the domain
libxl: error: libxl_dm.c:779:libxl__destroy_device_model Couldn't find
device model's pid: No such file or directory
libxl: error: libxl.c:752:libxl_domain_destroy libxl__destroy_device_model
failed for 2
Done. Exiting now


I dig into the src/tools/ioemu-qemu-xen/i386-dm/helper2.c,  found  the
function :

553-int main_loop(void)



554{



555    CPUState *env = cpu_single_env;



556    int evtchn_fd = xce_handle == NULL ? -1 : xc_evtchn_fd(xce_handle);



557    char *qemu_file;



558    fd_set fds;



559



560    main_loop_prepare();



561



562    buffered_io_timer = qemu_new_timer(rt_clock, handle_buffered_io,



563                                       cpu_single_env);



564    qemu_mod_timer(buffered_io_timer, qemu_get_clock(rt_clock));



565



566    if (evtchn_fd != -1)



567        qemu_set_fd_handler(evtchn_fd, cpu_handle_ioreq, NULL, env);



568



569    fprintf(logfile, "device model state set to running\n");



570    xenstore_record_dm_state("running");
*
*

*In normal circumstance, the qemu-dm log info will record the red line
above, but when disable vnc, it seems that it didn't go  into the function
`main_loop` and didn't see that line.*
*What happend to that and How to disable the vnc ?*

--001517573c88c98e4304c9551406
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: base64

SGkgYWxsLDxkaXY+oCCgIEluIHhlbi00LjEuMiBzcmMvdG9vbHMvbGlieGwvbGlieGxfZG0uYywg
dGhlcmUgaXMgYSBmdW5jdGlvbiBjYWxsZWQgYGxpYnhsX2J1aWxkX2RldmljZV9tb2RlbF9hcmdz
X29sZGAsIKB0aGUgZnVuYyB3aWxsIGJ1aWxkIHFlbXUtZG0gY21kbGluZSBhcmdzIGFjY29yZGlu
ZyB0bzwvZGl2PjxkaXY+dGhlIHhsLWZvcm1hdGVkIGNvbmZpZ3VyYXRpb24gZmlsZSBzcGVjaWZp
ZWQgYnkgeGwgY3JlYXRlIGNvbW1hbmQuIFRoZXJlIGFyZSBzZXZlcmFsIGxpbmVzIHJlbGF0ZWQg
dG8gdm5jIG9wdGlvbjo8L2Rpdj4KPGRpdj48YnI+PC9kaXY+PGJsb2NrcXVvdGUgc3R5bGU9Im1h
cmdpbjowIDAgMCA0MHB4O2JvcmRlcjpub25lO3BhZGRpbmc6MHB4Ij48ZGl2PjxkaXY+oDc2IKAg
oGlmIChpbmZvLSZndDt2bmMgfHwgaW5mby0mZ3Q7dm5jZGlzcGxheSB8fCBpbmZvLSZndDt2bmNs
aXN0ZW4gfHwgaW5mby0mZ3Q7dm5jdW51c2VkICkgeyCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCg
IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAg
oCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCg
IKAgoCCgIKAgoCCgIKA8L2Rpdj4KPC9kaXY+PGRpdj48ZGl2PqA3NyCgIKAgoCCgY2hhciAqdm5j
YXJnOyCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAg
oCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCg
IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAg
oCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgPC9kaXY+CjwvZGl2
PjxkaXY+PGRpdj6gPGZvbnQgY29sb3I9IiNmZjAwMDAiPjc4IKAgoCCgIKBpZiAoY3R4LSZndDtk
aXNhYmxlX3ZuYykgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCg
IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAg
oCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCg
IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKA8L2ZvbnQ+PC9kaXY+
CjwvZGl2PjxkaXY+PGRpdj48Zm9udCBjb2xvcj0iI2ZmMDAwMCI+oDc5IKAgoCCgIKAgoHsgoCCg
IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAg
oCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCg
IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAg
oCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKA8L2ZvbnQ+PC9k
aXY+CjwvZGl2PjxkaXY+PGRpdj48Zm9udCBjb2xvcj0iI2ZmMDAwMCI+oDgwIKAgoCCgIKAgoCCg
SU5GTygmcXVvdDtza2lwcGVkIHZuYy4uLiZxdW90Oyk7IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCg
IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAg
oCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCg
IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAg
oCCgPC9mb250PjwvZGl2Pgo8L2Rpdj48ZGl2PjxkaXY+PGZvbnQgY29sb3I9IiNmZjAwMDAiPqA4
MSCgIKAgoCCgIKAgoGdvdG8gc2tpcF92bmM7IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCg
IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAg
oCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCg
IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAg
oCCgIKCgPC9mb250PjwvZGl2Pgo8L2Rpdj48ZGl2PjxkaXY+PGZvbnQgY29sb3I9IiNmZjAwMDAi
PqA4MiCgIKAgoCCgIKB9IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCA8L2ZvbnQ+PC9kaXY+oCCgIKAg
oCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCg
IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAg
oCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCg
IKAgoCCgIKAgoCCgIKAgoCCgIKAgoDwvZGl2Pgo8ZGl2PjxkaXY+oDgzIKAgoCCgIKAgoC4uLnNr
aXAuLi4uIKAgoCCgIKAgoCCgIKAgoCCgPC9kaXY+PC9kaXY+PC9ibG9ja3F1b3RlPjxkaXY+PGJy
PjwvZGl2PjxkaXY+dGhlIHJlZCBwYXJ0IGFib3ZlIGlzIGFkZGVkIGJ5IG1lIGZvciB0ZXN0aW5n
IGZvcmNpbmcgdG8gZGlzYWJsZSB2bmMgaW4gY29uc2lkZXJhdGlvbiBvZiBwZXJmb3JtYW5jZS48
L2Rpdj48ZGl2PkJ1dCB3aGF0IEkgZ290IHdhcyB0aGF0IHRoZSBxZW11LWRtIHdpdGhvdXQgdm5j
IHJlbGF0ZWQgb3B0aW9ucyBmYWlsZWQgdG8gY3JlYXRlIGRldmljZSBtb2RlbC48L2Rpdj4KPGRp
dj48YnI+PC9kaXY+PGRpdj5JbiBteSBjYXNlLCB0aGUgdm0gaWQgaXMgMiwgdGhlPGI+IHFlbXUt
ZG0gbG9nIGluZm88L2I+KG5vdCB0cnVuY2F0ZWQpIGlzIGFzIGZvbGxvd3M6PC9kaXY+PGRpdj6g
PC9kaXY+PGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbjowIDAgMCA0MHB4O2JvcmRlcjpub25lO3Bh
ZGRpbmc6MHB4Ij48ZGl2PmRvbWlkOiAyPC9kaXY+PGRpdj4tdmlkZW9yYW0gb3B0aW9uIGRvZXMg
bm90IHdvcmsgd2l0aCBjaXJydXMgdmdhIGRldmljZSBtb2RlbC4gVmlkZW9yYW0gc2V0IHRvIDRN
LjwvZGl2Pgo8ZGl2PlN0cmlwIG9mZiBibGt0YXAgc3ViLXR5cGUgcHJlZml4IHRvIC9ob21lL21h
bGVpL2MyLmRlbHRhLmltZyAoZHJ2ICYjMzk7cWNvdzImIzM5Oyk8L2Rpdj48ZGl2PlVzaW5nIGZp
bGUgL2hvbWUvbWFsZWkvYzIuZGVsdGEuaW1nIGluIHJlYWQtd3JpdGUgbW9kZTwvZGl2PjxkaXY+
U3RyaXAgb2ZmIGJsa3RhcCBzdWItdHlwZSBwcmVmaXggdG8gL2hvbWUvbWFsZWkvZDIuZGVsdGEu
aW1nIChkcnYgJiMzOTtxY293MiYjMzk7KTwvZGl2Pgo8ZGl2PlVzaW5nIGZpbGUgL2hvbWUvbWFs
ZWkvZDIuZGVsdGEuaW1nIGluIHJlYWQtd3JpdGUgbW9kZTwvZGl2PjxkaXY+V2F0Y2hpbmcgL2xv
Y2FsL2RvbWFpbi8wL2RldmljZS1tb2RlbC8yL2xvZ2RpcnR5L2NtZDwvZGl2PjxkaXY+V2F0Y2hp
bmcgL2xvY2FsL2RvbWFpbi8wL2RldmljZS1tb2RlbC8yL2NvbW1hbmQ8L2Rpdj48ZGl2PldhdGNo
aW5nIC9sb2NhbC9kb21haW4vMi9jcHU8L2Rpdj4KPGRpdj5jaGFyIGRldmljZSByZWRpcmVjdGVk
IHRvIC9kZXYvcHRzLzQ8L2Rpdj48ZGl2PnFlbXVfbWFwX2NhY2hlX2luaXQgbnJfYnVja2V0cyA9
IDEwMDAwIHNpemUgNDE5NDMwNDwvZGl2PjxkaXY+c2hhcmVkIHBhZ2UgYXQgcGZuIGZlZmZkPC9k
aXY+PGRpdj5idWZmZXJlZCBpbyBwYWdlIGF0IHBmbiBmZWZmYjwvZGl2PjxkaXY+R3Vlc3QgdXVp
ZCA9IGQwNmIwOGYwLTQ5MWYtNDNkNi05YTAxLWFjMzE3YWVhNTAzNDwvZGl2Pgo8ZGl2PnBvcHVs
YXRpbmcgdmlkZW8gUkFNIGF0IGZmMDAwMDAwPC9kaXY+PGRpdj5tYXBwaW5nIHZpZGVvIFJBTSBm
cm9tIGZmMDAwMDAwPC9kaXY+PGRpdj5SZWdpc3RlciB4ZW4gcGxhdGZvcm0uPC9kaXY+PGRpdj5E
b25lIHJlZ2lzdGVyIHBsYXRmb3JtLjwvZGl2PjxkaXY+cGxhdGZvcm1fZml4ZWRfaW9wb3J0OiBj
aGFuZ2VkIHJvL3J3IHN0YXRlIG9mIFJPTSBtZW1vcnkgYXJlYS4gbm93IGlzIHJ3IHN0YXRlLjwv
ZGl2Pgo8ZGl2PnFlbXU6IG1hdGNoIE5JQyBtb2RlbDogcnRsODEzOTwvZGl2PjxkaXY+cGNpX3J0
bDgxMzlfaW5pdDogcy0mZ3Q7bWFjYWRkcjogMCAxNiAzZSBlYiBjYSA2NjwvZGl2PjxkaXY+eHNf
cmVhZCgvbG9jYWwvZG9tYWluLzAvZGV2aWNlLW1vZGVsLzIveGVuX2V4dGVuZGVkX3Bvd2VyX21n
bXQpOiByZWFkIGVycm9yoCCgoDwvZGl2PjwvYmxvY2txdW90ZT48YmxvY2txdW90ZSBzdHlsZT0i
bWFyZ2luOjAgMCAwIDQwcHg7Ym9yZGVyOm5vbmU7cGFkZGluZzowcHgiPgo8YmxvY2txdW90ZSBz
dHlsZT0ibWFyZ2luOjAgMCAwIDQwcHg7Ym9yZGVyOm5vbmU7cGFkZGluZzowcHgiPjxkaXY+PHU+
oCg8c3BhbiBzdHlsZT0iYmFja2dyb3VuZC1jb2xvcjpyZ2IoMjU1LDEwMiwxMDIpIj5zdG9wIGhl
cmUsIGJ1dCB0aGUgbm9ybWFsIGxvZyBzaG91bGQgY29udGFpbnMgb3RoZXIgbGluZXMgbGlrZTwv
c3Bhbj6gPC91PjwvZGl2PjxkaXY+PHU+ZGV2aWNlIG1vZGVsIHN0YXRlIHNldCB0byBydW5uaW5n
PC91PjwvZGl2Pgo8L2Jsb2NrcXVvdGU+PGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbjowIDAgMCA0
MHB4O2JvcmRlcjpub25lO3BhZGRpbmc6MHB4Ij48ZGl2Pjx1PkxvZy1kaXJ0eTogbm8gY29tbWFu
ZCB5ZXQuPC91PjwvZGl2PjwvYmxvY2txdW90ZT48YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luOjAg
MCAwIDQwcHg7Ym9yZGVyOm5vbmU7cGFkZGluZzowcHgiPjxkaXY+PHU+SS9PIHJlcXVlc3Qgbm90
IHJlYWR5OiAwLCBwdHI6IDAsIHBvcnQ6IDAsIGRhdGE6IDAsIGNvdW50OiAwLCBzaXplOiAwPC91
PjwvZGl2Pgo8L2Jsb2NrcXVvdGU+PGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbjowIDAgMCA0MHB4
O2JvcmRlcjpub25lO3BhZGRpbmc6MHB4Ij48ZGl2Pjx1PnZjcHUtc2V0OiB3YXRjaCBub2RlIGVy
cm9yLjwvdT48L2Rpdj48L2Jsb2NrcXVvdGU+PGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbjowIDAg
MCA0MHB4O2JvcmRlcjpub25lO3BhZGRpbmc6MHB4Ij48ZGl2Pjx1PnhzX3JlYWQoL2xvY2FsL2Rv
bWFpbi8xL2xvZy10aHJvdHRsaW5nKTogcmVhZCBlcnJvcjwvdT48L2Rpdj4KPC9ibG9ja3F1b3Rl
PjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW46MCAwIDAgNDBweDtib3JkZXI6bm9uZTtwYWRkaW5n
OjBweCI+PGRpdj48dT5xZW11OiBpZ25vcmluZyBub3QtdW5kZXJzdG9vZCBkcml2ZSBgL2xvY2Fs
L2RvbWFpbi8xL2xvZy10aHJvdHRsaW5nJiMzOTs8L3U+PC9kaXY+PC9ibG9ja3F1b3RlPjxibG9j
a3F1b3RlIHN0eWxlPSJtYXJnaW46MCAwIDAgNDBweDtib3JkZXI6bm9uZTtwYWRkaW5nOjBweCI+
CjxkaXY+PHU+bWVkaXVtIGNoYW5nZSB3YXRjaCBvbiBgL2xvY2FsL2RvbWFpbi8xL2xvZy10aHJv
dHRsaW5nJiMzOTsgLSB1bmtub3duIGRldmljZSwgaWdub3JlZDwvdT48L2Rpdj48L2Jsb2NrcXVv
dGU+PGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbjowIDAgMCA0MHB4O2JvcmRlcjpub25lO3BhZGRp
bmc6MHB4Ij48ZGl2Pjx1PmNpcnJ1cyB2Z2EgbWFwIGNoYW5nZSB3aGlsZSBvbiBsZmIgbW9kZTwv
dT48L2Rpdj4KPC9ibG9ja3F1b3RlPjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW46MCAwIDAgNDBw
eDtib3JkZXI6bm9uZTtwYWRkaW5nOjBweCI+PGRpdj48dT5tYXBwaW5nIHZyYW0gdG8gZjAwMDAw
MDAgLSBmMDQwMDAwMDwvdT48L2Rpdj48L2Jsb2NrcXVvdGU+PGJsb2NrcXVvdGUgc3R5bGU9Im1h
cmdpbjowIDAgMCA0MHB4O2JvcmRlcjpub25lO3BhZGRpbmc6MHB4Ij48ZGl2Pjx1PnBsYXRmb3Jt
X2ZpeGVkX2lvcG9ydDogY2hhbmdlZCByby9ydyBzdGF0ZSBvZiBST00gbWVtb3J5IGFyZWEuIG5v
dyBpcyBydyBzdGF0ZS48L3U+PC9kaXY+CjwvYmxvY2txdW90ZT48YmxvY2txdW90ZSBzdHlsZT0i
bWFyZ2luOjAgMCAwIDQwcHg7Ym9yZGVyOm5vbmU7cGFkZGluZzowcHgiPjxkaXY+PHU+cGxhdGZv
cm1fZml4ZWRfaW9wb3J0OiBjaGFuZ2VkIHJvL3J3IHN0YXRlIG9mIFJPTSBtZW1vcnkgYXJlYS4g
bm93IGlzIHJvIHN0YXRlLik8L3U+PC9kaXY+PC9ibG9ja3F1b3RlPjwvYmxvY2txdW90ZT48ZGl2
Pjxicj48L2Rpdj48ZGl2PmFuZCB0aGU8Yj4geGwgbG9nIGluZm88L2I+IGlzOjwvZGl2Pgo8ZGl2
PjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW46MCAwIDAgNDBweDtib3JkZXI6bm9uZTtwYWRkaW5n
OjBweCI+PGRpdj48YnI+PC9kaXY+PGRpdj48ZGl2PldhaXRpbmcgZm9yIGRvbWFpbiB4cC0xMDIg
KGRvbWlkIDIpIHRvIGRpZSBbcGlkIDE0MDA2XTwvZGl2PjwvZGl2PjxkaXY+PGRpdj5Eb21haW4g
MiBpcyBkZWFkPC9kaXY+PC9kaXY+PGRpdj48ZGl2PlVua25vd24gc2h1dGRvd24gcmVhc29uIGNv
ZGUgMjU1LiBEZXN0cm95aW5nIGRvbWFpbi48L2Rpdj4KPC9kaXY+PGRpdj48ZGl2PkFjdGlvbiBm
b3Igc2h1dGRvd24gcmVhc29uIGNvZGUgMjU1IGlzIGRlc3Ryb3k8L2Rpdj48L2Rpdj48ZGl2Pjxk
aXY+RG9tYWluIDIgbmVlZHMgdG8gYmUgY2xlYW5lZCB1cDogZGVzdHJveWluZyB0aGUgZG9tYWlu
PC9kaXY+PC9kaXY+PGRpdj48ZGl2PmxpYnhsOiBlcnJvcjogbGlieGxfZG0uYzo3Nzk6bGlieGxf
X2Rlc3Ryb3lfZGV2aWNlX21vZGVsIENvdWxkbiYjMzk7dCBmaW5kIGRldmljZSBtb2RlbCYjMzk7
cyBwaWQ6IE5vIHN1Y2ggZmlsZSBvciBkaXJlY3Rvcnk8L2Rpdj4KPC9kaXY+PGRpdj48ZGl2Pmxp
YnhsOiBlcnJvcjogbGlieGwuYzo3NTI6bGlieGxfZG9tYWluX2Rlc3Ryb3kgbGlieGxfX2Rlc3Ry
b3lfZGV2aWNlX21vZGVsIGZhaWxlZCBmb3IgMjwvZGl2PjwvZGl2PjxkaXY+PGRpdj5Eb25lLiBF
eGl0aW5nIG5vdzwvZGl2PjwvZGl2PjxkaXY+PGJyPjwvZGl2PjwvYmxvY2txdW90ZT48YnI+PC9k
aXY+PGRpdj5JIGRpZyBpbnRvIHRoZSBzcmMvdG9vbHMvaW9lbXUtcWVtdS14ZW4vaTM4Ni1kbS9o
ZWxwZXIyLmMsIKBmb3VuZCCgdGhlIGZ1bmN0aW9uIDo8L2Rpdj4KPGJsb2NrcXVvdGUgc3R5bGU9
Im1hcmdpbjowIDAgMCA0MHB4O2JvcmRlcjpub25lO3BhZGRpbmc6MHB4Ij48ZGl2PjxkaXY+NTUz
LWludCBtYWluX2xvb3Aodm9pZCkgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAg
oCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCg
IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAg
oCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCg
IKAgoKA8L2Rpdj4KPC9kaXY+PGRpdj48ZGl2PjU1NHsgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAg
oCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCg
IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAg
oCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCg
IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgPC9kaXY+CjwvZGl2PjxkaXY+PGRp
dj41NTUgoCCgQ1BVU3RhdGUgKmVudiA9IGNwdV9zaW5nbGVfZW52OyCgIKAgoCCgIKAgoCCgIKAg
oCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCg
IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAg
oCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCg
IKAgoCCgIKAgoDwvZGl2Pgo8L2Rpdj48ZGl2PjxkaXY+NTU2IKAgoGludCBldnRjaG5fZmQgPSB4
Y2VfaGFuZGxlID09IE5VTEwgPyAtMSA6IHhjX2V2dGNobl9mZCh4Y2VfaGFuZGxlKTsgoCCgIKAg
oCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCg
IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAg
oCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKA8L2Rpdj4KPC9kaXY+PGRp
dj48ZGl2PjU1NyCgIKBjaGFyICpxZW11X2ZpbGU7IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAg
oCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCg
IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAg
oCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCg
IKAgoCCgIKAgoCCgIKCgPC9kaXY+CjwvZGl2PjxkaXY+PGRpdj41NTggoCCgZmRfc2V0IGZkczsg
oCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCg
IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAg
oCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCg
IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoDwvZGl2Pgo8L2Rp
dj48ZGl2PjxkaXY+NTU5IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCg
IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAg
oCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCg
IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAg
oCCgIKAgoCCgIKAgoCCgIKAgoKA8L2Rpdj4KPC9kaXY+PGRpdj48ZGl2PjU2MCCgIKBtYWluX2xv
b3BfcHJlcGFyZSgpOyCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCg
IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAg
oCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCg
IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKCgPC9kaXY+
CjwvZGl2PjxkaXY+PGRpdj41NjEgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAg
oCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCg
IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAg
oCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCg
IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgoDwvZGl2Pgo8L2Rpdj48ZGl2PjxkaXY+NTYyIKAgoGJ1
ZmZlcmVkX2lvX3RpbWVyID0gcWVtdV9uZXdfdGltZXIocnRfY2xvY2ssIGhhbmRsZV9idWZmZXJl
ZF9pbywgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCg
IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAg
oCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoKA8
L2Rpdj4KPC9kaXY+PGRpdj48ZGl2PjU2MyCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCg
IKAgoCCgIGNwdV9zaW5nbGVfZW52KTsgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCg
IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAg
oCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCg
IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgPC9kaXY+CjwvZGl2PjxkaXY+PGRpdj41NjQg
oCCgcWVtdV9tb2RfdGltZXIoYnVmZmVyZWRfaW9fdGltZXIsIHFlbXVfZ2V0X2Nsb2NrKHJ0X2Ns
b2NrKSk7IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAg
oCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCg
IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAg
oCCgoDwvZGl2Pgo8L2Rpdj48ZGl2PjxkaXY+NTY1IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAg
oCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCg
IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAg
oCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCg
IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoKA8L2Rpdj4KPC9kaXY+PGRpdj48ZGl2
PjU2NiCgIKBpZiAoZXZ0Y2huX2ZkICE9IC0xKSCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAg
oCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCg
IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAg
oCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCg
IKAgoCCgIKCgPC9kaXY+CjwvZGl2PjxkaXY+PGRpdj41NjcgoCCgIKAgoHFlbXVfc2V0X2ZkX2hh
bmRsZXIoZXZ0Y2huX2ZkLCBjcHVfaGFuZGxlX2lvcmVxLCBOVUxMLCBlbnYpOyCgIKAgoCCgIKAg
oCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCg
IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAg
oCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgoDwvZGl2Pgo8L2Rpdj48ZGl2
PjxkaXY+NTY4IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCg
IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAg
oCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCg
IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAg
oCCgIKAgoCCgIKAgoKA8L2Rpdj4KPC9kaXY+PGRpdj48ZGl2PjU2OSCgIDxmb250IGNvbG9yPSIj
ZmY2NjY2Ij6gZnByaW50Zihsb2dmaWxlLCAmcXVvdDtkZXZpY2UgbW9kZWwgc3RhdGUgc2V0IHRv
IHJ1bm5pbmdcbiZxdW90Oyk7IKAgoCCgIKAgPC9mb250PqAgoCCgIKAgoCCgIKAgoCCgIKAgoCCg
IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAg
oCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCg
IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKCgPC9kaXY+CjwvZGl2PjxkaXY+PGRpdj41NzAgoCCg
eGVuc3RvcmVfcmVjb3JkX2RtX3N0YXRlKCZxdW90O3J1bm5pbmcmcXVvdDspOyCgPC9kaXY+PC9k
aXY+PGRpdj48Yj48YnI+PC9iPjwvZGl2PjwvYmxvY2txdW90ZT48Yj5JbiBub3JtYWwgY2lyY3Vt
c3RhbmNlLCB0aGUgcWVtdS1kbSBsb2cgaW5mbyB3aWxsIHJlY29yZCB0aGUgcmVkIGxpbmUgYWJv
dmUsIGJ1dCB3aGVuIGRpc2FibGUgdm5jLCBpdCBzZWVtcyB0aGF0IGl0IGRpZG4mIzM5O3QgZ28g
oGludG8gdGhlIGZ1bmN0aW9uIGBtYWluX2xvb3BgIGFuZCBkaWRuJiMzOTt0IHNlZSB0aGF0IGxp
bmUuPC9iPjxkaXY+CjxiPldoYXQgaGFwcGVuZCB0byB0aGF0IGFuZCBIb3cgdG8gZGlzYWJsZSB0
aGUgdm5jID88L2I+PGJyPjxkaXY+PGJyPjwvZGl2PjwvZGl2Pgo=
--001517573c88c98e4304c9551406--


--===============2658105266713236670==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============2658105266713236670==--


From xen-devel-bounces@lists.xen.org Mon Sep 10 08:53:24 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Sep 2012 08:53:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TAzjq-0005uP-Af; Mon, 10 Sep 2012 08:53:02 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <aware.why@gmail.com>) id 1TAzjp-0005uD-7p
	for xen-devel@lists.xensource.com; Mon, 10 Sep 2012 08:53:01 +0000
Received: from [85.158.138.51:12877] by server-3.bemta-3.messagelabs.com id
	17/E1-21322-C6AAD405; Mon, 10 Sep 2012 08:53:00 +0000
X-Env-Sender: aware.why@gmail.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1347267179!29619393!1
X-Originating-IP: [74.125.82.171]
X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_20_30,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27615 invoked from network); 10 Sep 2012 08:52:59 -0000
Received: from mail-we0-f171.google.com (HELO mail-we0-f171.google.com)
	(74.125.82.171)
	by server-11.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Sep 2012 08:52:59 -0000
Received: by weys43 with SMTP id s43so1279796wey.30
	for <xen-devel@lists.xensource.com>;
	Mon, 10 Sep 2012 01:52:59 -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=VkxqA3O1Jv0IFy9MRHfCs/ytWuXSnYRCpYFxhPoU5gI=;
	b=ovige46bSbwm3HSyRw8EwPlDj3iAneI4MWrXQsfkjJtY9JGE5pRLxGT+G4h7vdBPM0
	S2thBwz3BJ2N7XRjEehhxFGa6Hj4b4mE5Y1eQTpxdGVOXx9wUmbta8gKY7C3kbC7EVR/
	8QvQbKdPEmsMi0/HIRMgY0LA6IFnOzjkFt9hpj26RzyyJUGelFBTRKfu43miXzUrtL9P
	ZjNnKmy3fKgu5rrsdyNfx8dNp207vhIuTw05wAjOOaJ6q6jKWjN3IYoQ6XwdbGbf/icB
	OB3CxiUhq54yhPwhDohSn6Bj1p3VXbTOjvweEac4RhmfLI8aAeVWVhz3fQjtCDa0N2W3
	JZEA==
MIME-Version: 1.0
Received: by 10.217.4.139 with SMTP id u11mr7333972wes.190.1347267179376; Mon,
	10 Sep 2012 01:52:59 -0700 (PDT)
Received: by 10.223.12.69 with HTTP; Mon, 10 Sep 2012 01:52:59 -0700 (PDT)
Date: Mon, 10 Sep 2012 16:52:59 +0800
Message-ID: <CA+ePHTCmeGqphc1K0-WBfGScuYrmHobQqNnqwckkW2D=yCuWrg@mail.gmail.com>
From: =?UTF-8?B?6ams56OK?= <aware.why@gmail.com>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [Problem with xen-4.1.2] Creating device model failed
 when disable `-vnc` related option in qemu-dm
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============6834100057854305485=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============6834100057854305485==
Content-Type: multipart/alternative; boundary=20cf301e2f7ba4f1ef04c95515e2

--20cf301e2f7ba4f1ef04c95515e2
Content-Type: text/plain; charset=ISO-8859-1

Hi all,
    In xen-4.1.2 src/tools/libxl/libxl_dm.c, there is a function called
`libxl_build_device_model_args_old`,  the func will build qemu-dm cmdline
args according to
the xl-formated configuration file specified by xl create










domid: 2
-videoram option does not work with cirrus vga device model. Videoram set
to 4M.
Strip off blktap sub-type prefix to /home/malei/c2.delta.img (drv 'qcow2')
Using file /home/malei/c2.delta.img in read-write mode
Strip off blktap sub-type prefix to /home/malei/d2.delta.img (drv 'qcow2')
Using file /home/malei/d2.delta.img in read-write 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/4
qemu_map_cache_init nr_buckets = 10000 size 4194304
shared page at pfn feffd
buffered io page at pfn feffb
Guest uuid = d06b08f0-491f-43d6-9a01-ac317aea5034
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.
qemu: match NIC model: rtl8139
pci_rtl8139_init: s->macaddr: 0 16 3e eb ca 66
xs_read(/local/domain/0/device-model/2/xen_extended_power_mgmt): read
error

--20cf301e2f7ba4f1ef04c95515e2
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi all,<div>=A0 =A0 In xen-4.1.2 src/tools/libxl/libxl_dm.c, there is a fun=
ction called `libxl_build_device_model_args_old`, =A0the func will build qe=
mu-dm cmdline args according to</div><div>the xl-formated configuration fil=
e specified by xl create</div>

<div><br></div><div><br></div><div><br></div><div><br></div><div><br></div>=
<div><br></div><div><br></div><div><br></div><div><br></div><div><br></div>=
<div>domid: 2</div><div>-videoram option does not work with cirrus vga devi=
ce model. Videoram set to 4M.</div>

<div>Strip off blktap sub-type prefix to /home/malei/c2.delta.img (drv &#39=
;qcow2&#39;)</div><div>Using file /home/malei/c2.delta.img in read-write mo=
de</div><div>Strip off blktap sub-type prefix to /home/malei/d2.delta.img (=
drv &#39;qcow2&#39;)</div>

<div>Using file /home/malei/d2.delta.img in read-write mode</div><div>Watch=
ing /local/domain/0/device-model/2/logdirty/cmd</div><div>Watching /local/d=
omain/0/device-model/2/command</div><div>Watching /local/domain/2/cpu</div>

<div>char device redirected to /dev/pts/4</div><div>qemu_map_cache_init nr_=
buckets =3D 10000 size 4194304</div><div>shared page at pfn feffd</div><div=
>buffered io page at pfn feffb</div><div>Guest uuid =3D d06b08f0-491f-43d6-=
9a01-ac317aea5034</div>

<div>populating video RAM at ff000000</div><div>mapping video RAM from ff00=
0000</div><div>Register xen platform.</div><div>Done register platform.</di=
v><div>platform_fixed_ioport: changed ro/rw state of ROM memory area. now i=
s rw state.</div>

<div>qemu: match NIC model: rtl8139</div><div>pci_rtl8139_init: s-&gt;macad=
dr: 0 16 3e eb ca 66</div><div>xs_read(/local/domain/0/device-model/2/xen_e=
xtended_power_mgmt): read error=A0 =A0=A0</div><div><br></div><div><br></di=
v>


--20cf301e2f7ba4f1ef04c95515e2--


--===============6834100057854305485==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============6834100057854305485==--


From xen-devel-bounces@lists.xen.org Mon Sep 10 08:53:24 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Sep 2012 08:53:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TAzjq-0005uP-Af; Mon, 10 Sep 2012 08:53:02 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <aware.why@gmail.com>) id 1TAzjp-0005uD-7p
	for xen-devel@lists.xensource.com; Mon, 10 Sep 2012 08:53:01 +0000
Received: from [85.158.138.51:12877] by server-3.bemta-3.messagelabs.com id
	17/E1-21322-C6AAD405; Mon, 10 Sep 2012 08:53:00 +0000
X-Env-Sender: aware.why@gmail.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1347267179!29619393!1
X-Originating-IP: [74.125.82.171]
X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_20_30,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27615 invoked from network); 10 Sep 2012 08:52:59 -0000
Received: from mail-we0-f171.google.com (HELO mail-we0-f171.google.com)
	(74.125.82.171)
	by server-11.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Sep 2012 08:52:59 -0000
Received: by weys43 with SMTP id s43so1279796wey.30
	for <xen-devel@lists.xensource.com>;
	Mon, 10 Sep 2012 01:52:59 -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=VkxqA3O1Jv0IFy9MRHfCs/ytWuXSnYRCpYFxhPoU5gI=;
	b=ovige46bSbwm3HSyRw8EwPlDj3iAneI4MWrXQsfkjJtY9JGE5pRLxGT+G4h7vdBPM0
	S2thBwz3BJ2N7XRjEehhxFGa6Hj4b4mE5Y1eQTpxdGVOXx9wUmbta8gKY7C3kbC7EVR/
	8QvQbKdPEmsMi0/HIRMgY0LA6IFnOzjkFt9hpj26RzyyJUGelFBTRKfu43miXzUrtL9P
	ZjNnKmy3fKgu5rrsdyNfx8dNp207vhIuTw05wAjOOaJ6q6jKWjN3IYoQ6XwdbGbf/icB
	OB3CxiUhq54yhPwhDohSn6Bj1p3VXbTOjvweEac4RhmfLI8aAeVWVhz3fQjtCDa0N2W3
	JZEA==
MIME-Version: 1.0
Received: by 10.217.4.139 with SMTP id u11mr7333972wes.190.1347267179376; Mon,
	10 Sep 2012 01:52:59 -0700 (PDT)
Received: by 10.223.12.69 with HTTP; Mon, 10 Sep 2012 01:52:59 -0700 (PDT)
Date: Mon, 10 Sep 2012 16:52:59 +0800
Message-ID: <CA+ePHTCmeGqphc1K0-WBfGScuYrmHobQqNnqwckkW2D=yCuWrg@mail.gmail.com>
From: =?UTF-8?B?6ams56OK?= <aware.why@gmail.com>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [Problem with xen-4.1.2] Creating device model failed
 when disable `-vnc` related option in qemu-dm
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============6834100057854305485=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============6834100057854305485==
Content-Type: multipart/alternative; boundary=20cf301e2f7ba4f1ef04c95515e2

--20cf301e2f7ba4f1ef04c95515e2
Content-Type: text/plain; charset=ISO-8859-1

Hi all,
    In xen-4.1.2 src/tools/libxl/libxl_dm.c, there is a function called
`libxl_build_device_model_args_old`,  the func will build qemu-dm cmdline
args according to
the xl-formated configuration file specified by xl create










domid: 2
-videoram option does not work with cirrus vga device model. Videoram set
to 4M.
Strip off blktap sub-type prefix to /home/malei/c2.delta.img (drv 'qcow2')
Using file /home/malei/c2.delta.img in read-write mode
Strip off blktap sub-type prefix to /home/malei/d2.delta.img (drv 'qcow2')
Using file /home/malei/d2.delta.img in read-write 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/4
qemu_map_cache_init nr_buckets = 10000 size 4194304
shared page at pfn feffd
buffered io page at pfn feffb
Guest uuid = d06b08f0-491f-43d6-9a01-ac317aea5034
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.
qemu: match NIC model: rtl8139
pci_rtl8139_init: s->macaddr: 0 16 3e eb ca 66
xs_read(/local/domain/0/device-model/2/xen_extended_power_mgmt): read
error

--20cf301e2f7ba4f1ef04c95515e2
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi all,<div>=A0 =A0 In xen-4.1.2 src/tools/libxl/libxl_dm.c, there is a fun=
ction called `libxl_build_device_model_args_old`, =A0the func will build qe=
mu-dm cmdline args according to</div><div>the xl-formated configuration fil=
e specified by xl create</div>

<div><br></div><div><br></div><div><br></div><div><br></div><div><br></div>=
<div><br></div><div><br></div><div><br></div><div><br></div><div><br></div>=
<div>domid: 2</div><div>-videoram option does not work with cirrus vga devi=
ce model. Videoram set to 4M.</div>

<div>Strip off blktap sub-type prefix to /home/malei/c2.delta.img (drv &#39=
;qcow2&#39;)</div><div>Using file /home/malei/c2.delta.img in read-write mo=
de</div><div>Strip off blktap sub-type prefix to /home/malei/d2.delta.img (=
drv &#39;qcow2&#39;)</div>

<div>Using file /home/malei/d2.delta.img in read-write mode</div><div>Watch=
ing /local/domain/0/device-model/2/logdirty/cmd</div><div>Watching /local/d=
omain/0/device-model/2/command</div><div>Watching /local/domain/2/cpu</div>

<div>char device redirected to /dev/pts/4</div><div>qemu_map_cache_init nr_=
buckets =3D 10000 size 4194304</div><div>shared page at pfn feffd</div><div=
>buffered io page at pfn feffb</div><div>Guest uuid =3D d06b08f0-491f-43d6-=
9a01-ac317aea5034</div>

<div>populating video RAM at ff000000</div><div>mapping video RAM from ff00=
0000</div><div>Register xen platform.</div><div>Done register platform.</di=
v><div>platform_fixed_ioport: changed ro/rw state of ROM memory area. now i=
s rw state.</div>

<div>qemu: match NIC model: rtl8139</div><div>pci_rtl8139_init: s-&gt;macad=
dr: 0 16 3e eb ca 66</div><div>xs_read(/local/domain/0/device-model/2/xen_e=
xtended_power_mgmt): read error=A0 =A0=A0</div><div><br></div><div><br></di=
v>


--20cf301e2f7ba4f1ef04c95515e2--


--===============6834100057854305485==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============6834100057854305485==--


From xen-devel-bounces@lists.xen.org Mon Sep 10 08:55:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Sep 2012 08: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 1TAzld-00067s-R1; Mon, 10 Sep 2012 08:54:53 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <aware.why@gmail.com>) id 1TAzlc-00067i-Jr
	for xen-devel@lists.xensource.com; Mon, 10 Sep 2012 08:54:52 +0000
Received: from [85.158.143.99:44907] by server-2.bemta-4.messagelabs.com id
	6C/E2-21239-ADAAD405; Mon, 10 Sep 2012 08:54:50 +0000
X-Env-Sender: aware.why@gmail.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1347267290!26099891!1
X-Originating-IP: [209.85.212.177]
X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23631 invoked from network); 10 Sep 2012 08:54:50 -0000
Received: from mail-wi0-f177.google.com (HELO mail-wi0-f177.google.com)
	(209.85.212.177)
	by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Sep 2012 08:54:50 -0000
Received: by wibhn17 with SMTP id hn17so1481803wib.6
	for <xen-devel@lists.xensource.com>;
	Mon, 10 Sep 2012 01:54: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
	:content-type; bh=jtdcjfFZLSV2nB1ZNJJY7iHqTqRyAVid2O75lrt5a68=;
	b=d3uvpr9qocRhU4V/HVg6NCDekH4eMvRQZtF48k5yZRflnE+9GM7iP2ZXRifVbp6zOZ
	XDAnhUgEc6PLuAqulT/cRTMfWbZIe8VI7NDirfWL5CPWS+ZreWgCXAcxRBvkReRjMemA
	Va6Ju3uB/KwagYZSe/7HgqJ35514FdhUuM/BEt8n1FiJbw301wyIXhgLYRtb3YeKJB7h
	jxY1ODZIwJ2x0YYp1/qWjaAQxIdfSSjgEYX61Fjnggc0fkrgodWK/+p4dy0Gxv2axHCY
	DEzSf7zk3kDGRA/XAGupvyMIK3erm+248mP8vNITXCDStn9RdH/Bw5qr4KFq0M0AFFQT
	FLrA==
MIME-Version: 1.0
Received: by 10.216.235.197 with SMTP id u47mr7702770weq.180.1347267289814;
	Mon, 10 Sep 2012 01:54:49 -0700 (PDT)
Received: by 10.223.12.69 with HTTP; Mon, 10 Sep 2012 01:54:49 -0700 (PDT)
In-Reply-To: <CA+ePHTCmeGqphc1K0-WBfGScuYrmHobQqNnqwckkW2D=yCuWrg@mail.gmail.com>
References: <CA+ePHTCmeGqphc1K0-WBfGScuYrmHobQqNnqwckkW2D=yCuWrg@mail.gmail.com>
Date: Mon, 10 Sep 2012 16:54:49 +0800
Message-ID: <CA+ePHTDkEXtfYkc+WH5DZq-W7u=5fNsTbpYzOJx=xZsW=cCHEQ@mail.gmail.com>
From: =?UTF-8?B?6ams56OK?= <aware.why@gmail.com>
To: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [Problem with xen-4.1.2] Creating device model
 failed when disable `-vnc` related option in qemu-dm
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1725537387482843170=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============1725537387482843170==
Content-Type: multipart/alternative; boundary=001517573c883a1a0004c9551cb8

--001517573c883a1a0004c9551cb8
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Mon, Sep 10, 2012 at 4:52 PM, =E9=A9=AC=E7=A3=8A <aware.why@gmail.com> w=
rote:

> Hi all,
>     In xen-4.1.2 src/tools/libxl/libxl_dm.c, there is a function called
> `libxl_build_device_model_args_old`,  the func will build qemu-dm cmdline
> args according to
> the xl-formated configuration file specified by xl create
>
>
>
>
>
>
>
>
>
>
> domid: 2
> -videoram option does not work with cirrus vga device model. Videoram set
> to 4M.
> Strip off blktap sub-type prefix to /home/malei/c2.delta.img (drv 'qcow2'=
)
> Using file /home/malei/c2.delta.img in read-write mode
> Strip off blktap sub-type prefix to /home/malei/d2.delta.img (drv 'qcow2'=
)
> Using file /home/malei/d2.delta.img in read-write 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/4
> qemu_map_cache_init nr_buckets =3D 10000 size 4194304
> shared page at pfn feffd
> buffered io page at pfn feffb
> Guest uuid =3D d06b08f0-491f-43d6-9a01-ac317aea5034
> 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.
> qemu: match NIC model: rtl8139
> pci_rtl8139_init: s->macaddr: 0 16 3e eb ca 66
> xs_read(/local/domain/0/device-model/2/xen_extended_power_mgmt): read
> error
>
>
> sorry for that this one is not complete, look another one with the same
subject

--001517573c883a1a0004c9551cb8
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<br><br><div class=3D"gmail_quote">On Mon, Sep 10, 2012 at 4:52 PM, =E9=A9=
=AC=E7=A3=8A <span dir=3D"ltr">&lt;<a href=3D"mailto:aware.why@gmail.com" t=
arget=3D"_blank">aware.why@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">
Hi all,<div>=C2=A0 =C2=A0 In xen-4.1.2 src/tools/libxl/libxl_dm.c, there is=
 a function called `libxl_build_device_model_args_old`, =C2=A0the func will=
 build qemu-dm cmdline args according to</div><div>the xl-formated configur=
ation file specified by xl create</div>


<div><br></div><div><br></div><div><br></div><div><br></div><div><br></div>=
<div><br></div><div><br></div><div><br></div><div><br></div><div><br></div>=
<div>domid: 2</div><div>-videoram option does not work with cirrus vga devi=
ce model. Videoram set to 4M.</div>


<div>Strip off blktap sub-type prefix to /home/malei/c2.delta.img (drv &#39=
;qcow2&#39;)</div><div>Using file /home/malei/c2.delta.img in read-write mo=
de</div><div>Strip off blktap sub-type prefix to /home/malei/d2.delta.img (=
drv &#39;qcow2&#39;)</div>


<div>Using file /home/malei/d2.delta.img in read-write mode</div><div>Watch=
ing /local/domain/0/device-model/2/logdirty/cmd</div><div>Watching /local/d=
omain/0/device-model/2/command</div><div>Watching /local/domain/2/cpu</div>


<div>char device redirected to /dev/pts/4</div><div>qemu_map_cache_init nr_=
buckets =3D 10000 size 4194304</div><div>shared page at pfn feffd</div><div=
>buffered io page at pfn feffb</div><div>Guest uuid =3D d06b08f0-491f-43d6-=
9a01-ac317aea5034</div>


<div>populating video RAM at ff000000</div><div>mapping video RAM from ff00=
0000</div><div>Register xen platform.</div><div>Done register platform.</di=
v><div>platform_fixed_ioport: changed ro/rw state of ROM memory area. now i=
s rw state.</div>


<div>qemu: match NIC model: rtl8139</div><div>pci_rtl8139_init: s-&gt;macad=
dr: 0 16 3e eb ca 66</div><div>xs_read(/local/domain/0/device-model/2/xen_e=
xtended_power_mgmt): read error=C2=A0 =C2=A0=C2=A0</div><div><br></div><div=
><br></div>


</blockquote></div>sorry for that this one is not complete, look another on=
e with the same subject

--001517573c883a1a0004c9551cb8--


--===============1725537387482843170==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============1725537387482843170==--


From xen-devel-bounces@lists.xen.org Mon Sep 10 08:55:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Sep 2012 08: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 1TAzld-00067s-R1; Mon, 10 Sep 2012 08:54:53 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <aware.why@gmail.com>) id 1TAzlc-00067i-Jr
	for xen-devel@lists.xensource.com; Mon, 10 Sep 2012 08:54:52 +0000
Received: from [85.158.143.99:44907] by server-2.bemta-4.messagelabs.com id
	6C/E2-21239-ADAAD405; Mon, 10 Sep 2012 08:54:50 +0000
X-Env-Sender: aware.why@gmail.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1347267290!26099891!1
X-Originating-IP: [209.85.212.177]
X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23631 invoked from network); 10 Sep 2012 08:54:50 -0000
Received: from mail-wi0-f177.google.com (HELO mail-wi0-f177.google.com)
	(209.85.212.177)
	by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Sep 2012 08:54:50 -0000
Received: by wibhn17 with SMTP id hn17so1481803wib.6
	for <xen-devel@lists.xensource.com>;
	Mon, 10 Sep 2012 01:54: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
	:content-type; bh=jtdcjfFZLSV2nB1ZNJJY7iHqTqRyAVid2O75lrt5a68=;
	b=d3uvpr9qocRhU4V/HVg6NCDekH4eMvRQZtF48k5yZRflnE+9GM7iP2ZXRifVbp6zOZ
	XDAnhUgEc6PLuAqulT/cRTMfWbZIe8VI7NDirfWL5CPWS+ZreWgCXAcxRBvkReRjMemA
	Va6Ju3uB/KwagYZSe/7HgqJ35514FdhUuM/BEt8n1FiJbw301wyIXhgLYRtb3YeKJB7h
	jxY1ODZIwJ2x0YYp1/qWjaAQxIdfSSjgEYX61Fjnggc0fkrgodWK/+p4dy0Gxv2axHCY
	DEzSf7zk3kDGRA/XAGupvyMIK3erm+248mP8vNITXCDStn9RdH/Bw5qr4KFq0M0AFFQT
	FLrA==
MIME-Version: 1.0
Received: by 10.216.235.197 with SMTP id u47mr7702770weq.180.1347267289814;
	Mon, 10 Sep 2012 01:54:49 -0700 (PDT)
Received: by 10.223.12.69 with HTTP; Mon, 10 Sep 2012 01:54:49 -0700 (PDT)
In-Reply-To: <CA+ePHTCmeGqphc1K0-WBfGScuYrmHobQqNnqwckkW2D=yCuWrg@mail.gmail.com>
References: <CA+ePHTCmeGqphc1K0-WBfGScuYrmHobQqNnqwckkW2D=yCuWrg@mail.gmail.com>
Date: Mon, 10 Sep 2012 16:54:49 +0800
Message-ID: <CA+ePHTDkEXtfYkc+WH5DZq-W7u=5fNsTbpYzOJx=xZsW=cCHEQ@mail.gmail.com>
From: =?UTF-8?B?6ams56OK?= <aware.why@gmail.com>
To: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [Problem with xen-4.1.2] Creating device model
 failed when disable `-vnc` related option in qemu-dm
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1725537387482843170=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============1725537387482843170==
Content-Type: multipart/alternative; boundary=001517573c883a1a0004c9551cb8

--001517573c883a1a0004c9551cb8
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Mon, Sep 10, 2012 at 4:52 PM, =E9=A9=AC=E7=A3=8A <aware.why@gmail.com> w=
rote:

> Hi all,
>     In xen-4.1.2 src/tools/libxl/libxl_dm.c, there is a function called
> `libxl_build_device_model_args_old`,  the func will build qemu-dm cmdline
> args according to
> the xl-formated configuration file specified by xl create
>
>
>
>
>
>
>
>
>
>
> domid: 2
> -videoram option does not work with cirrus vga device model. Videoram set
> to 4M.
> Strip off blktap sub-type prefix to /home/malei/c2.delta.img (drv 'qcow2'=
)
> Using file /home/malei/c2.delta.img in read-write mode
> Strip off blktap sub-type prefix to /home/malei/d2.delta.img (drv 'qcow2'=
)
> Using file /home/malei/d2.delta.img in read-write 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/4
> qemu_map_cache_init nr_buckets =3D 10000 size 4194304
> shared page at pfn feffd
> buffered io page at pfn feffb
> Guest uuid =3D d06b08f0-491f-43d6-9a01-ac317aea5034
> 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.
> qemu: match NIC model: rtl8139
> pci_rtl8139_init: s->macaddr: 0 16 3e eb ca 66
> xs_read(/local/domain/0/device-model/2/xen_extended_power_mgmt): read
> error
>
>
> sorry for that this one is not complete, look another one with the same
subject

--001517573c883a1a0004c9551cb8
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<br><br><div class=3D"gmail_quote">On Mon, Sep 10, 2012 at 4:52 PM, =E9=A9=
=AC=E7=A3=8A <span dir=3D"ltr">&lt;<a href=3D"mailto:aware.why@gmail.com" t=
arget=3D"_blank">aware.why@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">
Hi all,<div>=C2=A0 =C2=A0 In xen-4.1.2 src/tools/libxl/libxl_dm.c, there is=
 a function called `libxl_build_device_model_args_old`, =C2=A0the func will=
 build qemu-dm cmdline args according to</div><div>the xl-formated configur=
ation file specified by xl create</div>


<div><br></div><div><br></div><div><br></div><div><br></div><div><br></div>=
<div><br></div><div><br></div><div><br></div><div><br></div><div><br></div>=
<div>domid: 2</div><div>-videoram option does not work with cirrus vga devi=
ce model. Videoram set to 4M.</div>


<div>Strip off blktap sub-type prefix to /home/malei/c2.delta.img (drv &#39=
;qcow2&#39;)</div><div>Using file /home/malei/c2.delta.img in read-write mo=
de</div><div>Strip off blktap sub-type prefix to /home/malei/d2.delta.img (=
drv &#39;qcow2&#39;)</div>


<div>Using file /home/malei/d2.delta.img in read-write mode</div><div>Watch=
ing /local/domain/0/device-model/2/logdirty/cmd</div><div>Watching /local/d=
omain/0/device-model/2/command</div><div>Watching /local/domain/2/cpu</div>


<div>char device redirected to /dev/pts/4</div><div>qemu_map_cache_init nr_=
buckets =3D 10000 size 4194304</div><div>shared page at pfn feffd</div><div=
>buffered io page at pfn feffb</div><div>Guest uuid =3D d06b08f0-491f-43d6-=
9a01-ac317aea5034</div>


<div>populating video RAM at ff000000</div><div>mapping video RAM from ff00=
0000</div><div>Register xen platform.</div><div>Done register platform.</di=
v><div>platform_fixed_ioport: changed ro/rw state of ROM memory area. now i=
s rw state.</div>


<div>qemu: match NIC model: rtl8139</div><div>pci_rtl8139_init: s-&gt;macad=
dr: 0 16 3e eb ca 66</div><div>xs_read(/local/domain/0/device-model/2/xen_e=
xtended_power_mgmt): read error=C2=A0 =C2=A0=C2=A0</div><div><br></div><div=
><br></div>


</blockquote></div>sorry for that this one is not complete, look another on=
e with the same subject

--001517573c883a1a0004c9551cb8--


--===============1725537387482843170==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============1725537387482843170==--


From xen-devel-bounces@lists.xen.org Mon Sep 10 09:05:55 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Sep 2012 09:05:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TAzvz-0006cK-Ma; Mon, 10 Sep 2012 09:05:35 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1TAzvy-0006cA-41
	for xen-devel@lists.xensource.com; Mon, 10 Sep 2012 09:05:34 +0000
Received: from [85.158.143.99:46066] by server-3.bemta-4.messagelabs.com id
	ED/CA-08232-D5DAD405; Mon, 10 Sep 2012 09:05:33 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1347267931!29497122!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM5OTA=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22474 invoked from network); 10 Sep 2012 09:05:32 -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;
	10 Sep 2012 09:05:32 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 10 Sep 2012 10:03:30 +0100
Message-Id: <504DC8FE020000780009A190@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 10 Sep 2012 10:03:26 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Andres Lagar-Cavilla" <andreslc@gridcentric.ca>,
	"Dan Carpenter" <dan.carpenter@oracle.com>
References: <20120908095808.GC608@elgon.mountain>
In-Reply-To: <20120908095808.GC608@elgon.mountain>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Jeremy Fitzhardinge <jeremy@goop.org>, xen-devel@lists.xensource.com,
	kernel-janitors@vger.kernel.org,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	virtualization@lists.linux-foundation.org
Subject: Re: [Xen-devel] [patch 3/3] xen/privcmd: remove const modifier from
 declaration
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.09.12 at 11:58, Dan Carpenter <dan.carpenter@oracle.com> wrote:
> When we use this pointer, we cast away the const modifier and modify the
> data.  I think it was an accident to declare it as const.

NAK - the const is very valid here, as the v2 interface (as opposed
to the v1 one) does _not_ modify this array (or if it does, it's a
bug). This is a guarantee made to user mode, so it should also be
expressed that way in the interface.

But of course the cast used before this patch isn't right either, as
it indeed inappropriately discards the qualifier. Afaiu this was done
to simplify the internal workings of the code, but I don't think it's
desirable to sacrifice type safety for implementation simplicity.

Jan

> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
> 
> diff --git a/include/xen/privcmd.h b/include/xen/privcmd.h
> index a853168..58ed953 100644
> --- a/include/xen/privcmd.h
> +++ b/include/xen/privcmd.h
> @@ -69,7 +69,7 @@ struct privcmd_mmapbatch_v2 {
>  	unsigned int num; /* number of pages to populate */
>  	domid_t dom;      /* target domain */
>  	__u64 addr;       /* virtual address */
> -	const xen_pfn_t __user *arr; /* array of mfns */
> +	xen_pfn_t __user *arr; /* array of mfns */
>  	int __user *err;  /* array of error codes */
>  };
>  
> diff --git a/drivers/xen/privcmd.c b/drivers/xen/privcmd.c
> index 0ce006a..fceb83e 100644
> --- a/drivers/xen/privcmd.c
> +++ b/drivers/xen/privcmd.c
> @@ -389,7 +389,7 @@ static long privcmd_ioctl_mmap_batch(void __user *udata, 
> int version)
>  
>  	if (state.global_error && (version == 1)) {
>  		/* Write back errors in second pass. */
> -		state.user_mfn = (xen_pfn_t *)m.arr;
> +		state.user_mfn = m.arr;
>  		state.err      = err_array;
>  		ret = traverse_pages(m.num, sizeof(xen_pfn_t),
>  				     &pagelist, mmap_return_errors_v1, &state);
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org 
> http://lists.xen.org/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 Sep 10 09:05:55 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Sep 2012 09:05:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TAzvz-0006cK-Ma; Mon, 10 Sep 2012 09:05:35 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1TAzvy-0006cA-41
	for xen-devel@lists.xensource.com; Mon, 10 Sep 2012 09:05:34 +0000
Received: from [85.158.143.99:46066] by server-3.bemta-4.messagelabs.com id
	ED/CA-08232-D5DAD405; Mon, 10 Sep 2012 09:05:33 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1347267931!29497122!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM5OTA=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22474 invoked from network); 10 Sep 2012 09:05:32 -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;
	10 Sep 2012 09:05:32 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 10 Sep 2012 10:03:30 +0100
Message-Id: <504DC8FE020000780009A190@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 10 Sep 2012 10:03:26 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Andres Lagar-Cavilla" <andreslc@gridcentric.ca>,
	"Dan Carpenter" <dan.carpenter@oracle.com>
References: <20120908095808.GC608@elgon.mountain>
In-Reply-To: <20120908095808.GC608@elgon.mountain>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Jeremy Fitzhardinge <jeremy@goop.org>, xen-devel@lists.xensource.com,
	kernel-janitors@vger.kernel.org,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	virtualization@lists.linux-foundation.org
Subject: Re: [Xen-devel] [patch 3/3] xen/privcmd: remove const modifier from
 declaration
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.09.12 at 11:58, Dan Carpenter <dan.carpenter@oracle.com> wrote:
> When we use this pointer, we cast away the const modifier and modify the
> data.  I think it was an accident to declare it as const.

NAK - the const is very valid here, as the v2 interface (as opposed
to the v1 one) does _not_ modify this array (or if it does, it's a
bug). This is a guarantee made to user mode, so it should also be
expressed that way in the interface.

But of course the cast used before this patch isn't right either, as
it indeed inappropriately discards the qualifier. Afaiu this was done
to simplify the internal workings of the code, but I don't think it's
desirable to sacrifice type safety for implementation simplicity.

Jan

> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
> 
> diff --git a/include/xen/privcmd.h b/include/xen/privcmd.h
> index a853168..58ed953 100644
> --- a/include/xen/privcmd.h
> +++ b/include/xen/privcmd.h
> @@ -69,7 +69,7 @@ struct privcmd_mmapbatch_v2 {
>  	unsigned int num; /* number of pages to populate */
>  	domid_t dom;      /* target domain */
>  	__u64 addr;       /* virtual address */
> -	const xen_pfn_t __user *arr; /* array of mfns */
> +	xen_pfn_t __user *arr; /* array of mfns */
>  	int __user *err;  /* array of error codes */
>  };
>  
> diff --git a/drivers/xen/privcmd.c b/drivers/xen/privcmd.c
> index 0ce006a..fceb83e 100644
> --- a/drivers/xen/privcmd.c
> +++ b/drivers/xen/privcmd.c
> @@ -389,7 +389,7 @@ static long privcmd_ioctl_mmap_batch(void __user *udata, 
> int version)
>  
>  	if (state.global_error && (version == 1)) {
>  		/* Write back errors in second pass. */
> -		state.user_mfn = (xen_pfn_t *)m.arr;
> +		state.user_mfn = m.arr;
>  		state.err      = err_array;
>  		ret = traverse_pages(m.num, sizeof(xen_pfn_t),
>  				     &pagelist, mmap_return_errors_v1, &state);
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org 
> http://lists.xen.org/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 Sep 10 09:24:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Sep 2012 09:24:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TB0DR-0006yp-BR; Mon, 10 Sep 2012 09:23:37 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1TB0DP-0006yk-Nr
	for xen-devel@lists.xensource.com; Mon, 10 Sep 2012 09:23:36 +0000
X-Env-Sender: fantonifabio@tiscali.it
X-Msg-Ref: server-11.tower-27.messagelabs.com!1347268970!3377252!1
X-Originating-IP: [94.23.245.208]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG,
	ML_RADAR_SPEW_LINKS_14,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14710 invoked from network); 10 Sep 2012 09:22:51 -0000
Received: from lnx3.fantu.it (HELO lnx3.fantu.it) (94.23.245.208)
	by server-11.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 10 Sep 2012 09:22:51 -0000
Received: from localhost (localhost.localdomain [127.0.0.1])
	by lnx3.fantu.it (Postfix) with ESMTP id B7CBB401E7C;
	Mon, 10 Sep 2012 11:22:49 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at lnx3.fantu.it
Received: from lnx3.fantu.it ([127.0.0.1])
	by localhost (lnx3.fantu.it [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id Jq4QG-ZE6pRT; Mon, 10 Sep 2012 11:22:48 +0200 (CEST)
Received: from [192.168.178.50]
	(host159-164-dynamic.56-82-r.retail.telecomitalia.it [82.56.164.159])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: prova@fantu.it)
	by lnx3.fantu.it (Postfix) with ESMTPSA id 684B440021F;
	Mon, 10 Sep 2012 11:22:48 +0200 (CEST)
Message-ID: <504DB165.6040500@tiscali.it>
Date: Mon, 10 Sep 2012 11:22:45 +0200
From: Fabio Fantoni <fantonifabio@tiscali.it>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:14.0) Gecko/20120713 Thunderbird/14.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <5049EC11.9080302@tiscali.it>
	<1347030955.30018.115.camel@zakaz.uk.xensource.com>
In-Reply-To: <1347030955.30018.115.camel@zakaz.uk.xensource.com>
Cc: xen-devel <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Test report of xen 4.2.0-rc4
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="===============8263248512349386712=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Questo è un messaggio firmato digitalmente in formato MIME.

--===============8263248512349386712==
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms080202000103000704060806"

Questo è un messaggio firmato digitalmente in formato MIME.

--------------ms080202000103000704060806
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable

Il 07/09/2012 17:15, Ian Campbell ha scritto:
> Thanks for testing.
>
> On Fri, 2012-09-07 at 13:44 +0100, Fabio Fantoni wrote:
>> - IMPORTANT - On restore network is up but not working, tried with W7
>> pro 64 bit with gplpv last build (357) on qemu-xen-traditional
> Our automated tests aren't seeing this, might it be a GPLPV issue? Can
> you reproduce with e.g. PV Linux (or PVHVM Linux for that matter)?
>
>> - Cdrom hotswap is not working, tried with W7 pro 64 bit with gplpv la=
st
>> build (357) on qemu-xen-traditional
>> xl -vvv cd-eject W7 hdb
>> libxl: debug: libxl.c:2143:libxl_cdrom_insert: ao 0x1461980: create:
>> how=3D(nil) callback=3D(nil) poller=3D0x14619e0
>> Errore di segmentazione
> This doesn't happen for me. Please can you run this one under gdb and
> when it fails type "bt" to get a backtrace.
>
>> - Vnc is working but only with parameters not supplied as value to the=

>> vfb key, but with vfb key is not working
> Whether or not that works is very much a function of exactly what the
> rest of your guest config looks like (it depends on PV for HVM for one
> thing).
>
> You've reported enough bugs now that I shouldn't need to remind you
> about providing guest config files or link to
> http://wiki.xen.org/wiki/Reporting_Bugs_against_Xen again.
>
> Ian.
>
>
>
>
> -----
> Nessun virus nel messaggio.
> Controllato da AVG - www.avg.com
> Versione: 2012.0.2197 / Database dei virus: 2437/5254 -  Data di rilasc=
io: 07/09/2012
>
>
Thanks for reply, here the xl configuration file:

-------------------------
W7.cfg
------
name=3D'W7'
builder=3D"hvm"
memory=3D2048
vcpus=3D2
vif=3D['bridge=3Dxenbr0']
#vfb=3D['vnc=3D1,vncunused=3D1,vnclisten=3D"0.0.0.0",keymap=3Dit']
disk=3D['/mnt/vm/disks/W7.disk1.xm,raw,hda,rw','/mnt/vm/iso/XPSP3PRO.iso,=
raw,hdb,ro,cdrom']
#disk=3D['/mnt/vm/disks/W7.disk1.xm,raw,hda,rw','/dev/sr0,raw,hdb,ro,cdro=
m']
boot=3D'cd'
device_model_version=3D"qemu-xen-traditional"
vnc=3D1
vncunused=3D1
vnclisten=3D"0.0.0.0"
keymap=3D"it"
#on_poweroff=3D"destroy"
on_reboot=3D"restart"
on_crash=3D"destroy"
stdvga=3D1
-------------------------

I don't know exactly how to use gdbsx, tried with:
gdbsx -a 1 64 9999
Listening on port 9999
doesn't show nothing also after cd-eject

I not found howto about gdbsx, can you tell me how to use it please?

xl -vvv cd-eject W7 hdb
libxl: debug: libxl.c:2143:libxl_cdrom_insert: ao 0x7b4980: create:=20
how=3D(nil) callback=3D(nil) poller=3D0x7b49e0
libxl: debug: libxl_device.c:229:libxl__device_disk_set_backend: Disk=20
vdev=3Dhdb spec.backend=3Dunknown
libxl: debug: libxl_device.c:175:disk_try_backend: Disk vdev=3Dhdb,=20
backend phy unsuitable as phys path not a block device
libxl: debug: libxl_device.c:210:disk_try_backend: Disk vdev=3Dhdb,=20
backend tap unsuitable due to format empty
libxl: debug: libxl_device.c:265:libxl__device_disk_set_backend: Disk=20
vdev=3Dhdb, using backend qdisk
libxl: debug: libxl_event.c:1497:libxl__ao_complete: ao 0x7b4980:=20
complete, rc=3D0
libxl: debug: libxl.c:2236:libxl_cdrom_insert: ao 0x7b4980: inprogress:=20
poller=3D0x7b49e0, flags=3Dic
libxl: debug: libxl_event.c:1469:libxl__ao__destroy: ao 0x7b4980: destroy=

xc: debug: hypercall buffer: total allocations:4 total releases:4
xc: debug: hypercall buffer: current allocations:0 maximum allocations:2
xc: debug: hypercall buffer: cache current size:2
xc: debug: hypercall buffer: cache hits:1 misses:2 toobig:1

This time domU seem also freeze

-------------------------
qemu-dm-W7.log
----------
domid: 1
Using file /dev/xen/blktap-2/tapdev0 in read-write mode
Using file /dev/xen/blktap-2/tapdev1 in read-only mode
Watching /local/domain/0/device-model/1/logdirty/cmd
Watching /local/domain/0/device-model/1/command
Watching /local/domain/1/cpu
qemu_map_cache_init nr_buckets =3D 10000 size 4194304
shared page at pfn feffd
buffered io page at pfn feffb
Guest uuid =3D dfc1d327-23c4-4cf1-9683-4b92a7ca2eb1
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/1/xen_extended_power_mgmt): read err=
or
xs_read(): vncpasswd get error.=20
/vm/dfc1d327-23c4-4cf1-9683-4b92a7ca2eb1/vncpasswd.
medium change watch on `hdb' (index: 1): /dev/xen/blktap-2/tapdev1
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
Log-dirty: no command yet.
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
vcpu-set: watch node error.
xs_read(/local/domain/1/log-throttling): read error
qemu: ignoring not-understood drive `/local/domain/1/log-throttling'
medium change watch on `/local/domain/1/log-throttling' - unknown=20
device, ignored
vga s->lfb_addr =3D f1000000 s->lfb_end =3D f1800000
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.
mapping vram to f1000000 - f1800000
Unknown PV product 2 loaded in guest
PV driver build 1
region type 1 at [c100,c200).
region type 0 at [f1800000,f1800100).
squash iomem [f1800000, f1800100).
vga s->lfb_addr =3D f1000000 s->lfb_end =3D f1800000
vga s->lfb_addr =3D f1000000 s->lfb_end =3D f1800000
xc: error: linux_gnttab_set_max_grants: ioctl SET_MAX_GRANTS failed (22=20
=3D Invalid argument): Internal error
xen be: qdisk-832: xen be: qdisk-832: xc_gnttab_set_max_grants failed:=20
Invalid argument
xc_gnttab_set_max_grants failed: Invalid argument
xen be: qdisk-832: xen be: qdisk-832: reading backend state failed
reading backend state failed
xen be: qdisk-832: xen be: qdisk-832: reading backend state failed
reading backend state failed
-------------------------

-------------------------
xl-W7.log
----------
Waiting for domain W7 (domid 1) to die [pid 4029]
-------------------------

Can you post me details and versions  of your system installation (dom0=20
domU GPLPV) with which you have cd-eject and network on restore working, =

please?


--------------ms080202000103000704060806
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: Firma crittografica S/MIME

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINhjCC
BjQwggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT
DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp
Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3
MTAyNDIxMDI1NVoXDTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T
dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu
aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs
aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOM
KqANy9BV7V0igWdGxA8IU77L3aTxErQ+fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi
8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke/s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8M
DP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHksw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y
2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHHtOkzUreG//CsFnB9+uaYSlR65cdG
zTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB
Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd+q9rMfPIHeOsuzAfBgNV
HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH
MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3
dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu
c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v
c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0
dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93
d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqp
Jw3I07QWke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Mic
c/NXcs7kPBRdn6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9Jphw
UPTXwHovjavRnhUQHLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMc
p+reg9901zkyT3fDW/ivJVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT
+HBDYtbuvexNftwNQKD5193A7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1X
hwby6mLhkbaXslkVtwEWT3Van49rKjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvO
hNz/QplNa+VkIsrcp7+8ZhP1l1b2U6MaxIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC
0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqh
AChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H75dVCV33K6FuxZrf09yTz+Vx/PkdRUYk
XmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHSjCCBjKgAwIBAgICHmMwDQYJKoZIhvcNAQEF
BQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJT
ZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD
bGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0xMjAzMTgyMjE0MzBa
Fw0xNDAzMjAwODU3MDlaMIGMMRkwFwYDVQQNExBlQjZPRTM3UlJOUHlsNW0yMQswCQYDVQQG
EwJJVDEQMA4GA1UECBMHQmVyZ2FtbzEQMA4GA1UEBxMHUm92ZXR0YTEWMBQGA1UEAxMNRmFi
aW8gRmFudG9uaTEmMCQGCSqGSIb3DQEJARYXZmFudG9uaWZhYmlvQHRpc2NhbGkuaXQwggEi
MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC1XhckXsX23vgJq76s2f0KT8U8Msov5QgV
10eQBb2wL/TzcmqtZotI7ztKVhio3ehHg+mfu+3EqOkX9Umgut8rP0bPi7AGjkPXbOTT/cSU
Xz2Kw31VGOmiOVoUFGvpQitp3weCkhUJLBipI8EpNyBXpjtQ9yCpnIAqfuc77ybfSnCy7tTR
MBq1BUkfjH1+GL45riosuS4+F+MSUvlYzLiT4rAduAX1Y2IuORDsf9Bce8GBxa6syP9rCyzl
Vk7DIX5k8j2vlnyRATIypn5CQLQxGT6e0f6ac4gvWOHwO2QEBsmZKKs1ZidE4q/9OoNXYX6A
jnHtp1H1vcrek/vVcs19AgMBAAGjggOyMIIDrjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAd
BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFFan8cbEWWBmSTWFtLk2
YNdAcGUbMB8GA1UdIwQYMBaAFK5Vg2/sMcq59x36r2sx88gd46y7MCIGA1UdEQQbMBmBF2Zh
bnRvbmlmYWJpb0B0aXNjYWxpLml0MIICIQYDVR0gBIICGDCCAhQwggIQBgsrBgEEAYG1NwEC
AjCCAf8wLgYIKwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYw
NAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYw
gfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMC
AQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNjb3JkaW5nIHRvIHRoZSBDbGFz
cyAyIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3ks
IHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGluIGNvbXBsaWFuY2Ug
b2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMIGcBggrBgEFBQcCAjCBjzAnFiBT
dGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgECGmRMaWFiaWxpdHkgYW5kIHdh
cnJhbnRpZXMgYXJlIGxpbWl0ZWQhIFNlZSBzZWN0aW9uICJMZWdhbCBhbmQgTGltaXRhdGlv
bnMiIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3kuMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6
Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUyLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYI
KwYBBQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MyL2NsaWVudC9j
YTBCBggrBgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNz
Mi5jbGllbnQuY2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzAN
BgkqhkiG9w0BAQUFAAOCAQEAjzHNqifpDVMkH1TSPFZVIiQ4fh49/V5JMpstgqEZPDaDe5r8
h+fMBZtUa6LLMco03Z9BNEXlqlXKiFk8feVYB8obEjz7YYq1XhO9q7JUmkSs0WGIH4xU0XB1
kPC8T8H+5E//84poYSFHE4pA+Ff68UANP2/EuFJWMjegiefnOr8aM42OAcUkjEWSlautIIX8
oD2GizwQYjWdDDjEonbuMKFP6rY2xGI3PSLI3IVU2opb0/itNhQui3WRxafloJqTlriY8m8+
qSLr2HGftbBlbyzVWB8o//aW0H0LMabjkIvrm7Zmh2vcCxiSxGBwYASuSYXGuQiKAgGptUs1
XJLZuzGCA9owggPWAgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20g
THRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG
A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EC
Ah5jMAkGBSsOAwIaBQCgggIbMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcN
AQkFMQ8XDTEyMDkxMDA5MjI0NVowIwYJKoZIhvcNAQkEMRYEFATS+XbxufU+PEcakHENv3aK
FiDfMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggqhkiG
9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcN
AwICASgwgaQGCSsGAQQBgjcQBDGBljCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0
YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25p
bmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp
ZW50IENBAgIeYzCBpgYLKoZIhvcNAQkQAgsxgZaggZMwgYwxCzAJBgNVBAYTAklMMRYwFAYD
VQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0
ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRp
YXRlIENsaWVudCBDQQICHmMwDQYJKoZIhvcNAQEBBQAEggEAbBq93w0pNCvEYVk3pCmjZnp8
SSpFbbZT3W7xnSt60hhnf7XEzqPFqTKXWutDRegpIS76tmnt57QYBbUq7/FXIP/ezP+wLFaG
Vxpa2Jya1KjSnS/aNxbN2uzORTRbg0vmJK0ESm8lCuUmBpar49oWO0mCG/Vtzp3P1vv6/IM/
4E8in8JUijuqc0g31M3UHLLJJoucpqTMOtPqCQKaZHT9UBtUKqMla5Fk8muPeUDiSGtWwnMJ
rEk+iwvZvs9disovObNjkWL1e1kaeBJOmfAubCs9JGb0/Lhpim/QJi2c8RkRK7ZBeXYout7H
noJ0zrk26sXtpsC4/FymATkRFB8JYQAAAAAAAA==
--------------ms080202000103000704060806--


--===============8263248512349386712==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============8263248512349386712==--


From xen-devel-bounces@lists.xen.org Mon Sep 10 09:24:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Sep 2012 09:24:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TB0DR-0006yp-BR; Mon, 10 Sep 2012 09:23:37 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1TB0DP-0006yk-Nr
	for xen-devel@lists.xensource.com; Mon, 10 Sep 2012 09:23:36 +0000
X-Env-Sender: fantonifabio@tiscali.it
X-Msg-Ref: server-11.tower-27.messagelabs.com!1347268970!3377252!1
X-Originating-IP: [94.23.245.208]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG,
	ML_RADAR_SPEW_LINKS_14,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14710 invoked from network); 10 Sep 2012 09:22:51 -0000
Received: from lnx3.fantu.it (HELO lnx3.fantu.it) (94.23.245.208)
	by server-11.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 10 Sep 2012 09:22:51 -0000
Received: from localhost (localhost.localdomain [127.0.0.1])
	by lnx3.fantu.it (Postfix) with ESMTP id B7CBB401E7C;
	Mon, 10 Sep 2012 11:22:49 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at lnx3.fantu.it
Received: from lnx3.fantu.it ([127.0.0.1])
	by localhost (lnx3.fantu.it [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id Jq4QG-ZE6pRT; Mon, 10 Sep 2012 11:22:48 +0200 (CEST)
Received: from [192.168.178.50]
	(host159-164-dynamic.56-82-r.retail.telecomitalia.it [82.56.164.159])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: prova@fantu.it)
	by lnx3.fantu.it (Postfix) with ESMTPSA id 684B440021F;
	Mon, 10 Sep 2012 11:22:48 +0200 (CEST)
Message-ID: <504DB165.6040500@tiscali.it>
Date: Mon, 10 Sep 2012 11:22:45 +0200
From: Fabio Fantoni <fantonifabio@tiscali.it>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:14.0) Gecko/20120713 Thunderbird/14.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <5049EC11.9080302@tiscali.it>
	<1347030955.30018.115.camel@zakaz.uk.xensource.com>
In-Reply-To: <1347030955.30018.115.camel@zakaz.uk.xensource.com>
Cc: xen-devel <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Test report of xen 4.2.0-rc4
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="===============8263248512349386712=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Questo è un messaggio firmato digitalmente in formato MIME.

--===============8263248512349386712==
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms080202000103000704060806"

Questo è un messaggio firmato digitalmente in formato MIME.

--------------ms080202000103000704060806
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable

Il 07/09/2012 17:15, Ian Campbell ha scritto:
> Thanks for testing.
>
> On Fri, 2012-09-07 at 13:44 +0100, Fabio Fantoni wrote:
>> - IMPORTANT - On restore network is up but not working, tried with W7
>> pro 64 bit with gplpv last build (357) on qemu-xen-traditional
> Our automated tests aren't seeing this, might it be a GPLPV issue? Can
> you reproduce with e.g. PV Linux (or PVHVM Linux for that matter)?
>
>> - Cdrom hotswap is not working, tried with W7 pro 64 bit with gplpv la=
st
>> build (357) on qemu-xen-traditional
>> xl -vvv cd-eject W7 hdb
>> libxl: debug: libxl.c:2143:libxl_cdrom_insert: ao 0x1461980: create:
>> how=3D(nil) callback=3D(nil) poller=3D0x14619e0
>> Errore di segmentazione
> This doesn't happen for me. Please can you run this one under gdb and
> when it fails type "bt" to get a backtrace.
>
>> - Vnc is working but only with parameters not supplied as value to the=

>> vfb key, but with vfb key is not working
> Whether or not that works is very much a function of exactly what the
> rest of your guest config looks like (it depends on PV for HVM for one
> thing).
>
> You've reported enough bugs now that I shouldn't need to remind you
> about providing guest config files or link to
> http://wiki.xen.org/wiki/Reporting_Bugs_against_Xen again.
>
> Ian.
>
>
>
>
> -----
> Nessun virus nel messaggio.
> Controllato da AVG - www.avg.com
> Versione: 2012.0.2197 / Database dei virus: 2437/5254 -  Data di rilasc=
io: 07/09/2012
>
>
Thanks for reply, here the xl configuration file:

-------------------------
W7.cfg
------
name=3D'W7'
builder=3D"hvm"
memory=3D2048
vcpus=3D2
vif=3D['bridge=3Dxenbr0']
#vfb=3D['vnc=3D1,vncunused=3D1,vnclisten=3D"0.0.0.0",keymap=3Dit']
disk=3D['/mnt/vm/disks/W7.disk1.xm,raw,hda,rw','/mnt/vm/iso/XPSP3PRO.iso,=
raw,hdb,ro,cdrom']
#disk=3D['/mnt/vm/disks/W7.disk1.xm,raw,hda,rw','/dev/sr0,raw,hdb,ro,cdro=
m']
boot=3D'cd'
device_model_version=3D"qemu-xen-traditional"
vnc=3D1
vncunused=3D1
vnclisten=3D"0.0.0.0"
keymap=3D"it"
#on_poweroff=3D"destroy"
on_reboot=3D"restart"
on_crash=3D"destroy"
stdvga=3D1
-------------------------

I don't know exactly how to use gdbsx, tried with:
gdbsx -a 1 64 9999
Listening on port 9999
doesn't show nothing also after cd-eject

I not found howto about gdbsx, can you tell me how to use it please?

xl -vvv cd-eject W7 hdb
libxl: debug: libxl.c:2143:libxl_cdrom_insert: ao 0x7b4980: create:=20
how=3D(nil) callback=3D(nil) poller=3D0x7b49e0
libxl: debug: libxl_device.c:229:libxl__device_disk_set_backend: Disk=20
vdev=3Dhdb spec.backend=3Dunknown
libxl: debug: libxl_device.c:175:disk_try_backend: Disk vdev=3Dhdb,=20
backend phy unsuitable as phys path not a block device
libxl: debug: libxl_device.c:210:disk_try_backend: Disk vdev=3Dhdb,=20
backend tap unsuitable due to format empty
libxl: debug: libxl_device.c:265:libxl__device_disk_set_backend: Disk=20
vdev=3Dhdb, using backend qdisk
libxl: debug: libxl_event.c:1497:libxl__ao_complete: ao 0x7b4980:=20
complete, rc=3D0
libxl: debug: libxl.c:2236:libxl_cdrom_insert: ao 0x7b4980: inprogress:=20
poller=3D0x7b49e0, flags=3Dic
libxl: debug: libxl_event.c:1469:libxl__ao__destroy: ao 0x7b4980: destroy=

xc: debug: hypercall buffer: total allocations:4 total releases:4
xc: debug: hypercall buffer: current allocations:0 maximum allocations:2
xc: debug: hypercall buffer: cache current size:2
xc: debug: hypercall buffer: cache hits:1 misses:2 toobig:1

This time domU seem also freeze

-------------------------
qemu-dm-W7.log
----------
domid: 1
Using file /dev/xen/blktap-2/tapdev0 in read-write mode
Using file /dev/xen/blktap-2/tapdev1 in read-only mode
Watching /local/domain/0/device-model/1/logdirty/cmd
Watching /local/domain/0/device-model/1/command
Watching /local/domain/1/cpu
qemu_map_cache_init nr_buckets =3D 10000 size 4194304
shared page at pfn feffd
buffered io page at pfn feffb
Guest uuid =3D dfc1d327-23c4-4cf1-9683-4b92a7ca2eb1
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/1/xen_extended_power_mgmt): read err=
or
xs_read(): vncpasswd get error.=20
/vm/dfc1d327-23c4-4cf1-9683-4b92a7ca2eb1/vncpasswd.
medium change watch on `hdb' (index: 1): /dev/xen/blktap-2/tapdev1
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
Log-dirty: no command yet.
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
vcpu-set: watch node error.
xs_read(/local/domain/1/log-throttling): read error
qemu: ignoring not-understood drive `/local/domain/1/log-throttling'
medium change watch on `/local/domain/1/log-throttling' - unknown=20
device, ignored
vga s->lfb_addr =3D f1000000 s->lfb_end =3D f1800000
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.
mapping vram to f1000000 - f1800000
Unknown PV product 2 loaded in guest
PV driver build 1
region type 1 at [c100,c200).
region type 0 at [f1800000,f1800100).
squash iomem [f1800000, f1800100).
vga s->lfb_addr =3D f1000000 s->lfb_end =3D f1800000
vga s->lfb_addr =3D f1000000 s->lfb_end =3D f1800000
xc: error: linux_gnttab_set_max_grants: ioctl SET_MAX_GRANTS failed (22=20
=3D Invalid argument): Internal error
xen be: qdisk-832: xen be: qdisk-832: xc_gnttab_set_max_grants failed:=20
Invalid argument
xc_gnttab_set_max_grants failed: Invalid argument
xen be: qdisk-832: xen be: qdisk-832: reading backend state failed
reading backend state failed
xen be: qdisk-832: xen be: qdisk-832: reading backend state failed
reading backend state failed
-------------------------

-------------------------
xl-W7.log
----------
Waiting for domain W7 (domid 1) to die [pid 4029]
-------------------------

Can you post me details and versions  of your system installation (dom0=20
domU GPLPV) with which you have cd-eject and network on restore working, =

please?


--------------ms080202000103000704060806
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: Firma crittografica S/MIME

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINhjCC
BjQwggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT
DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp
Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3
MTAyNDIxMDI1NVoXDTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T
dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu
aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs
aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOM
KqANy9BV7V0igWdGxA8IU77L3aTxErQ+fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi
8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke/s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8M
DP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHksw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y
2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHHtOkzUreG//CsFnB9+uaYSlR65cdG
zTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB
Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd+q9rMfPIHeOsuzAfBgNV
HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH
MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3
dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu
c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v
c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0
dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93
d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqp
Jw3I07QWke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Mic
c/NXcs7kPBRdn6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9Jphw
UPTXwHovjavRnhUQHLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMc
p+reg9901zkyT3fDW/ivJVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT
+HBDYtbuvexNftwNQKD5193A7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1X
hwby6mLhkbaXslkVtwEWT3Van49rKjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvO
hNz/QplNa+VkIsrcp7+8ZhP1l1b2U6MaxIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC
0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqh
AChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H75dVCV33K6FuxZrf09yTz+Vx/PkdRUYk
XmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHSjCCBjKgAwIBAgICHmMwDQYJKoZIhvcNAQEF
BQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJT
ZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD
bGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0xMjAzMTgyMjE0MzBa
Fw0xNDAzMjAwODU3MDlaMIGMMRkwFwYDVQQNExBlQjZPRTM3UlJOUHlsNW0yMQswCQYDVQQG
EwJJVDEQMA4GA1UECBMHQmVyZ2FtbzEQMA4GA1UEBxMHUm92ZXR0YTEWMBQGA1UEAxMNRmFi
aW8gRmFudG9uaTEmMCQGCSqGSIb3DQEJARYXZmFudG9uaWZhYmlvQHRpc2NhbGkuaXQwggEi
MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC1XhckXsX23vgJq76s2f0KT8U8Msov5QgV
10eQBb2wL/TzcmqtZotI7ztKVhio3ehHg+mfu+3EqOkX9Umgut8rP0bPi7AGjkPXbOTT/cSU
Xz2Kw31VGOmiOVoUFGvpQitp3weCkhUJLBipI8EpNyBXpjtQ9yCpnIAqfuc77ybfSnCy7tTR
MBq1BUkfjH1+GL45riosuS4+F+MSUvlYzLiT4rAduAX1Y2IuORDsf9Bce8GBxa6syP9rCyzl
Vk7DIX5k8j2vlnyRATIypn5CQLQxGT6e0f6ac4gvWOHwO2QEBsmZKKs1ZidE4q/9OoNXYX6A
jnHtp1H1vcrek/vVcs19AgMBAAGjggOyMIIDrjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAd
BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFFan8cbEWWBmSTWFtLk2
YNdAcGUbMB8GA1UdIwQYMBaAFK5Vg2/sMcq59x36r2sx88gd46y7MCIGA1UdEQQbMBmBF2Zh
bnRvbmlmYWJpb0B0aXNjYWxpLml0MIICIQYDVR0gBIICGDCCAhQwggIQBgsrBgEEAYG1NwEC
AjCCAf8wLgYIKwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYw
NAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYw
gfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMC
AQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNjb3JkaW5nIHRvIHRoZSBDbGFz
cyAyIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3ks
IHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGluIGNvbXBsaWFuY2Ug
b2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMIGcBggrBgEFBQcCAjCBjzAnFiBT
dGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgECGmRMaWFiaWxpdHkgYW5kIHdh
cnJhbnRpZXMgYXJlIGxpbWl0ZWQhIFNlZSBzZWN0aW9uICJMZWdhbCBhbmQgTGltaXRhdGlv
bnMiIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3kuMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6
Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUyLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYI
KwYBBQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MyL2NsaWVudC9j
YTBCBggrBgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNz
Mi5jbGllbnQuY2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzAN
BgkqhkiG9w0BAQUFAAOCAQEAjzHNqifpDVMkH1TSPFZVIiQ4fh49/V5JMpstgqEZPDaDe5r8
h+fMBZtUa6LLMco03Z9BNEXlqlXKiFk8feVYB8obEjz7YYq1XhO9q7JUmkSs0WGIH4xU0XB1
kPC8T8H+5E//84poYSFHE4pA+Ff68UANP2/EuFJWMjegiefnOr8aM42OAcUkjEWSlautIIX8
oD2GizwQYjWdDDjEonbuMKFP6rY2xGI3PSLI3IVU2opb0/itNhQui3WRxafloJqTlriY8m8+
qSLr2HGftbBlbyzVWB8o//aW0H0LMabjkIvrm7Zmh2vcCxiSxGBwYASuSYXGuQiKAgGptUs1
XJLZuzGCA9owggPWAgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20g
THRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG
A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EC
Ah5jMAkGBSsOAwIaBQCgggIbMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcN
AQkFMQ8XDTEyMDkxMDA5MjI0NVowIwYJKoZIhvcNAQkEMRYEFATS+XbxufU+PEcakHENv3aK
FiDfMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggqhkiG
9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcN
AwICASgwgaQGCSsGAQQBgjcQBDGBljCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0
YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25p
bmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp
ZW50IENBAgIeYzCBpgYLKoZIhvcNAQkQAgsxgZaggZMwgYwxCzAJBgNVBAYTAklMMRYwFAYD
VQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0
ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRp
YXRlIENsaWVudCBDQQICHmMwDQYJKoZIhvcNAQEBBQAEggEAbBq93w0pNCvEYVk3pCmjZnp8
SSpFbbZT3W7xnSt60hhnf7XEzqPFqTKXWutDRegpIS76tmnt57QYBbUq7/FXIP/ezP+wLFaG
Vxpa2Jya1KjSnS/aNxbN2uzORTRbg0vmJK0ESm8lCuUmBpar49oWO0mCG/Vtzp3P1vv6/IM/
4E8in8JUijuqc0g31M3UHLLJJoucpqTMOtPqCQKaZHT9UBtUKqMla5Fk8muPeUDiSGtWwnMJ
rEk+iwvZvs9disovObNjkWL1e1kaeBJOmfAubCs9JGb0/Lhpim/QJi2c8RkRK7ZBeXYout7H
noJ0zrk26sXtpsC4/FymATkRFB8JYQAAAAAAAA==
--------------ms080202000103000704060806--


--===============8263248512349386712==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============8263248512349386712==--


From xen-devel-bounces@lists.xen.org Mon Sep 10 09:29:55 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Sep 2012 09:29: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 1TB0JF-00078k-Aj; Mon, 10 Sep 2012 09:29: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 1TB0JE-00078d-A0
	for xen-devel@lists.xensource.com; Mon, 10 Sep 2012 09:29:36 +0000
Received: from [85.158.143.35:28384] by server-1.bemta-4.messagelabs.com id
	DB/F4-12504-FF2BD405; Mon, 10 Sep 2012 09:29:35 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1347269373!5783712!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTIyODk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14512 invoked from network); 10 Sep 2012 09:29:35 -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;
	10 Sep 2012 09:29:35 -0000
X-IronPort-AV: E=Sophos;i="4.80,396,1344211200"; d="scan'208";a="14436903"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Sep 2012 09:29: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.279.1;
	Mon, 10 Sep 2012 10:29:23 +0100
Message-ID: <1347269362.5305.39.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "fantonifabio@tiscali.it" <fantonifabio@tiscali.it>
Date: Mon, 10 Sep 2012 10:29:22 +0100
In-Reply-To: <504DB165.6040500@tiscali.it>
References: <5049EC11.9080302@tiscali.it>
	<1347030955.30018.115.camel@zakaz.uk.xensource.com>
	<504DB165.6040500@tiscali.it>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Test report of xen 4.2.0-rc4
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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-09-10 at 10:22 +0100, Fabio Fantoni wrote:
> Il 07/09/2012 17:15, Ian Campbell ha scritto:
> > Thanks for testing.
> >
> > On Fri, 2012-09-07 at 13:44 +0100, Fabio Fantoni wrote:
> >> - IMPORTANT - On restore network is up but not working, tried with W7
> >> pro 64 bit with gplpv last build (357) on qemu-xen-traditional
> > Our automated tests aren't seeing this, might it be a GPLPV issue? Can
> > you reproduce with e.g. PV Linux (or PVHVM Linux for that matter)?
> >
> >> - Cdrom hotswap is not working, tried with W7 pro 64 bit with gplpv last
> >> build (357) on qemu-xen-traditional
> >> xl -vvv cd-eject W7 hdb
> >> libxl: debug: libxl.c:2143:libxl_cdrom_insert: ao 0x1461980: create:
> >> how=(nil) callback=(nil) poller=0x14619e0
> >> Errore di segmentazione
> > This doesn't happen for me. Please can you run this one under gdb and
> > when it fails type "bt" to get a backtrace.
> >
> >> - Vnc is working but only with parameters not supplied as value to the
> >> vfb key, but with vfb key is not working
> > Whether or not that works is very much a function of exactly what the
> > rest of your guest config looks like (it depends on PV for HVM for one
> > thing).
> >
> > You've reported enough bugs now that I shouldn't need to remind you
> > about providing guest config files or link to
> > http://wiki.xen.org/wiki/Reporting_Bugs_against_Xen again.
> >
> > Ian.
> >
> >
> >
> >
> > -----
> > Nessun virus nel messaggio.
> > Controllato da AVG - www.avg.com
> > Versione: 2012.0.2197 / Database dei virus: 2437/5254 -  Data di rilascio: 07/09/2012
> >
> >
> Thanks for reply, here the xl configuration file:
> 
> -------------------------
> W7.cfg
> ------
> name='W7'
> builder="hvm"
> memory=2048
> vcpus=2
> vif=['bridge=xenbr0']
> #vfb=['vnc=1,vncunused=1,vnclisten="0.0.0.0",keymap=it']

I don't think it is expected that this line (even if uncommented) would
do anything for Windows unless you have a PV FB frontend driver, which
I'm fairly certain doesn't exist. So I think:
> Vnc is working but only with parameters not supplied as value to the 
> vfb key, but with vfb key is not working

is entirely expected.

The vfb line is for use with PV guests which have a PVFB driver.

[...]
> -------------------------
> 
> I don't know exactly how to use gdbsx,

You just need regular gdb not gdbsx.

Run it as eg.g.
	gdb --args xl cd-eject <aprams>

then when it crashes type "bt".

> Can you post me details and versions  of your system installation (dom0 
> domU GPLPV) with which you have cd-eject and network on restore working, 
> please?

I tested this with Linux HVM. I don't have any Windows domUs.

Does this work without GPLPV drivers? The CDROM device should be
emulated even if those are installed anyway.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 10 09:29:55 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Sep 2012 09:29: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 1TB0JF-00078k-Aj; Mon, 10 Sep 2012 09:29: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 1TB0JE-00078d-A0
	for xen-devel@lists.xensource.com; Mon, 10 Sep 2012 09:29:36 +0000
Received: from [85.158.143.35:28384] by server-1.bemta-4.messagelabs.com id
	DB/F4-12504-FF2BD405; Mon, 10 Sep 2012 09:29:35 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1347269373!5783712!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTIyODk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14512 invoked from network); 10 Sep 2012 09:29:35 -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;
	10 Sep 2012 09:29:35 -0000
X-IronPort-AV: E=Sophos;i="4.80,396,1344211200"; d="scan'208";a="14436903"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Sep 2012 09:29: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.279.1;
	Mon, 10 Sep 2012 10:29:23 +0100
Message-ID: <1347269362.5305.39.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "fantonifabio@tiscali.it" <fantonifabio@tiscali.it>
Date: Mon, 10 Sep 2012 10:29:22 +0100
In-Reply-To: <504DB165.6040500@tiscali.it>
References: <5049EC11.9080302@tiscali.it>
	<1347030955.30018.115.camel@zakaz.uk.xensource.com>
	<504DB165.6040500@tiscali.it>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Test report of xen 4.2.0-rc4
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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-09-10 at 10:22 +0100, Fabio Fantoni wrote:
> Il 07/09/2012 17:15, Ian Campbell ha scritto:
> > Thanks for testing.
> >
> > On Fri, 2012-09-07 at 13:44 +0100, Fabio Fantoni wrote:
> >> - IMPORTANT - On restore network is up but not working, tried with W7
> >> pro 64 bit with gplpv last build (357) on qemu-xen-traditional
> > Our automated tests aren't seeing this, might it be a GPLPV issue? Can
> > you reproduce with e.g. PV Linux (or PVHVM Linux for that matter)?
> >
> >> - Cdrom hotswap is not working, tried with W7 pro 64 bit with gplpv last
> >> build (357) on qemu-xen-traditional
> >> xl -vvv cd-eject W7 hdb
> >> libxl: debug: libxl.c:2143:libxl_cdrom_insert: ao 0x1461980: create:
> >> how=(nil) callback=(nil) poller=0x14619e0
> >> Errore di segmentazione
> > This doesn't happen for me. Please can you run this one under gdb and
> > when it fails type "bt" to get a backtrace.
> >
> >> - Vnc is working but only with parameters not supplied as value to the
> >> vfb key, but with vfb key is not working
> > Whether or not that works is very much a function of exactly what the
> > rest of your guest config looks like (it depends on PV for HVM for one
> > thing).
> >
> > You've reported enough bugs now that I shouldn't need to remind you
> > about providing guest config files or link to
> > http://wiki.xen.org/wiki/Reporting_Bugs_against_Xen again.
> >
> > Ian.
> >
> >
> >
> >
> > -----
> > Nessun virus nel messaggio.
> > Controllato da AVG - www.avg.com
> > Versione: 2012.0.2197 / Database dei virus: 2437/5254 -  Data di rilascio: 07/09/2012
> >
> >
> Thanks for reply, here the xl configuration file:
> 
> -------------------------
> W7.cfg
> ------
> name='W7'
> builder="hvm"
> memory=2048
> vcpus=2
> vif=['bridge=xenbr0']
> #vfb=['vnc=1,vncunused=1,vnclisten="0.0.0.0",keymap=it']

I don't think it is expected that this line (even if uncommented) would
do anything for Windows unless you have a PV FB frontend driver, which
I'm fairly certain doesn't exist. So I think:
> Vnc is working but only with parameters not supplied as value to the 
> vfb key, but with vfb key is not working

is entirely expected.

The vfb line is for use with PV guests which have a PVFB driver.

[...]
> -------------------------
> 
> I don't know exactly how to use gdbsx,

You just need regular gdb not gdbsx.

Run it as eg.g.
	gdb --args xl cd-eject <aprams>

then when it crashes type "bt".

> Can you post me details and versions  of your system installation (dom0 
> domU GPLPV) with which you have cd-eject and network on restore working, 
> please?

I tested this with Linux HVM. I don't have any Windows domUs.

Does this work without GPLPV drivers? The CDROM device should be
emulated even if those are installed anyway.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 10 09:40:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Sep 2012 09: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 1TB0TH-0007Lh-FG; Mon, 10 Sep 2012 09:39:59 +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 1TB0TG-0007Lc-4f
	for xen-devel@lists.xen.org; Mon, 10 Sep 2012 09:39:58 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1347269990!2655262!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM5OTE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2891 invoked from network); 10 Sep 2012 09:39:50 -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;
	10 Sep 2012 09:39:50 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 10 Sep 2012 10:39:49 +0100
Message-Id: <504DD183020000780009A1B6@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 10 Sep 2012 10:39: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="=__PartB382A373.0__="
Subject: [Xen-devel] [PATCH] docs: document "ucode=" hypervisor command line
	option
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
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.

--=__PartB382A373.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/docs/misc/xen-command-line.markdown
+++ b/docs/misc/xen-command-line.markdown
@@ -785,6 +785,19 @@ Specify the per-cpu trace buffer size in
 > `=3D unstable | skewed`
=20
 ### ucode
+> `=3D <integer>`
+
+Specify the CPU microcode update blob module index. When positive, this
+specifies the n-th module (in the GrUB entry, zero based) to be used
+for updating CPU micrcode. When negative, counting starts at the end of
+the modules in the GrUB entry (so with the blob commonly being last,
+one could specify `ucode=3D-1`). Note that the value of zero is not valid
+here (entry zero, i.e. the first module, is always the Dom0 kernel
+image). Note further that use of this option has an unspecified effect
+when used with xen.efi (there the concept of modules doesn't exist, and
+the blob gets specified via the `ucode=3D<filename>` config file/section
+entry; see [EFI configuration file description](efi.html)).
+
 ### unrestricted\_guest
 > `=3D <boolean>`
=20




--=__PartB382A373.0__=
Content-Type: text/plain; name="ucode-option-doc.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="ucode-option-doc.patch"

docs: document "ucode=3D" hypervisor command line option=0A=0ASigned-off-by=
: Jan Beulich <jbeulich@suse.com>=0A=0A--- a/docs/misc/xen-command-line.mar=
kdown=0A+++ b/docs/misc/xen-command-line.markdown=0A@@ -785,6 +785,19 @@ =
Specify the per-cpu trace buffer size in=0A > `=3D unstable | skewed`=0A =
=0A ### ucode=0A+> `=3D <integer>`=0A+=0A+Specify the CPU microcode update =
blob module index. When positive, this=0A+specifies the n-th module (in =
the GrUB entry, zero based) to be used=0A+for updating CPU micrcode. When =
negative, counting starts at the end of=0A+the modules in the GrUB entry =
(so with the blob commonly being last,=0A+one could specify `ucode=3D-1`). =
Note that the value of zero is not valid=0A+here (entry zero, i.e. the =
first module, is always the Dom0 kernel=0A+image). Note further that use =
of this option has an unspecified effect=0A+when used with xen.efi (there =
the concept of modules doesn't exist, and=0A+the blob gets specified via =
the `ucode=3D<filename>` config file/section=0A+entry; see [EFI configurati=
on file description](efi.html)).=0A+=0A ### unrestricted\_guest=0A > `=3D =
<boolean>`=0A =0A
--=__PartB382A373.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

--=__PartB382A373.0__=--


From xen-devel-bounces@lists.xen.org Mon Sep 10 09:40:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Sep 2012 09: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 1TB0TH-0007Lh-FG; Mon, 10 Sep 2012 09:39:59 +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 1TB0TG-0007Lc-4f
	for xen-devel@lists.xen.org; Mon, 10 Sep 2012 09:39:58 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1347269990!2655262!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM5OTE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2891 invoked from network); 10 Sep 2012 09:39:50 -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;
	10 Sep 2012 09:39:50 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 10 Sep 2012 10:39:49 +0100
Message-Id: <504DD183020000780009A1B6@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 10 Sep 2012 10:39: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="=__PartB382A373.0__="
Subject: [Xen-devel] [PATCH] docs: document "ucode=" hypervisor command line
	option
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
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.

--=__PartB382A373.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/docs/misc/xen-command-line.markdown
+++ b/docs/misc/xen-command-line.markdown
@@ -785,6 +785,19 @@ Specify the per-cpu trace buffer size in
 > `=3D unstable | skewed`
=20
 ### ucode
+> `=3D <integer>`
+
+Specify the CPU microcode update blob module index. When positive, this
+specifies the n-th module (in the GrUB entry, zero based) to be used
+for updating CPU micrcode. When negative, counting starts at the end of
+the modules in the GrUB entry (so with the blob commonly being last,
+one could specify `ucode=3D-1`). Note that the value of zero is not valid
+here (entry zero, i.e. the first module, is always the Dom0 kernel
+image). Note further that use of this option has an unspecified effect
+when used with xen.efi (there the concept of modules doesn't exist, and
+the blob gets specified via the `ucode=3D<filename>` config file/section
+entry; see [EFI configuration file description](efi.html)).
+
 ### unrestricted\_guest
 > `=3D <boolean>`
=20




--=__PartB382A373.0__=
Content-Type: text/plain; name="ucode-option-doc.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="ucode-option-doc.patch"

docs: document "ucode=3D" hypervisor command line option=0A=0ASigned-off-by=
: Jan Beulich <jbeulich@suse.com>=0A=0A--- a/docs/misc/xen-command-line.mar=
kdown=0A+++ b/docs/misc/xen-command-line.markdown=0A@@ -785,6 +785,19 @@ =
Specify the per-cpu trace buffer size in=0A > `=3D unstable | skewed`=0A =
=0A ### ucode=0A+> `=3D <integer>`=0A+=0A+Specify the CPU microcode update =
blob module index. When positive, this=0A+specifies the n-th module (in =
the GrUB entry, zero based) to be used=0A+for updating CPU micrcode. When =
negative, counting starts at the end of=0A+the modules in the GrUB entry =
(so with the blob commonly being last,=0A+one could specify `ucode=3D-1`). =
Note that the value of zero is not valid=0A+here (entry zero, i.e. the =
first module, is always the Dom0 kernel=0A+image). Note further that use =
of this option has an unspecified effect=0A+when used with xen.efi (there =
the concept of modules doesn't exist, and=0A+the blob gets specified via =
the `ucode=3D<filename>` config file/section=0A+entry; see [EFI configurati=
on file description](efi.html)).=0A+=0A ### unrestricted\_guest=0A > `=3D =
<boolean>`=0A =0A
--=__PartB382A373.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

--=__PartB382A373.0__=--


From xen-devel-bounces@lists.xen.org Mon Sep 10 09:44:39 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Sep 2012 09:44: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 1TB0XX-0007TP-5m; Mon, 10 Sep 2012 09:44:23 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <aware.why@gmail.com>) id 1TB0XU-0007TG-MU
	for xen-devel@lists.xensource.com; Mon, 10 Sep 2012 09:44:22 +0000
Received: from [85.158.138.51:56140] by server-4.bemta-3.messagelabs.com id
	7B/B3-24831-376BD405; Mon, 10 Sep 2012 09:44:19 +0000
X-Env-Sender: aware.why@gmail.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1347270258!21616708!1
X-Originating-IP: [209.85.212.171]
X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18809 invoked from network); 10 Sep 2012 09:44:18 -0000
Received: from mail-wi0-f171.google.com (HELO mail-wi0-f171.google.com)
	(209.85.212.171)
	by server-6.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Sep 2012 09:44:18 -0000
Received: by wibhq4 with SMTP id hq4so1585001wib.6
	for <xen-devel@lists.xensource.com>;
	Mon, 10 Sep 2012 02:44:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:content-type; bh=rxzV0nyp2/R3J4lhnuW5ORqz8C8KPYEaE+yk0Tljo0o=;
	b=VGkbUUxgY73/7J2mlbLDFzWdlzMJhNHGXaA0d+2BrpmDxm0nHdCvP48MQ9Mr1u73g7
	R/tag5+V/nRRW8Bwaqf/rH3iLIQ/ZYoH1kngN+BaAu/REPVsP/e0ENMZM2VeOaLgU6r9
	/YK6sthLMXygqOn4P7cVzBveMRI4JPAjGJuiQts2Jrcd7S8jI5bjKJddXzkMAfeIlqKb
	IryID7DSygF+API5NEUOqi25weGXsKDVgyIX6RgLf+HVwboLHxYp9dN5/rmp/FzfsGJr
	nAxODIuAAXA3SQ0ucTyEjNZXE0R/4BROA5T3Lvl01gmvDAt28Z7lxjHtuZEVijg2NISO
	j2SA==
MIME-Version: 1.0
Received: by 10.216.235.197 with SMTP id u47mr7785070weq.180.1347270257760;
	Mon, 10 Sep 2012 02:44:17 -0700 (PDT)
Received: by 10.223.12.69 with HTTP; Mon, 10 Sep 2012 02:44:17 -0700 (PDT)
In-Reply-To: <CA+ePHTCoBnoBRsjGVsMtY3B4BPMA6FopjkF4DGCoX+Mn1JiAfQ@mail.gmail.com>
References: <CA+ePHTCoBnoBRsjGVsMtY3B4BPMA6FopjkF4DGCoX+Mn1JiAfQ@mail.gmail.com>
Date: Mon, 10 Sep 2012 17:44:17 +0800
Message-ID: <CA+ePHTBonmHOrZBxYYTQDMi0FwumBBshr+4yJv_nJq_rZpP4Nw@mail.gmail.com>
From: =?UTF-8?B?6ams56OK?= <aware.why@gmail.com>
To: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [Problem with xen-4.1.2] Creating device model
 failed when disable `-vnc` related options in qemu-dm
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============2331233611765085454=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============2331233611765085454==
Content-Type: multipart/alternative; boundary=001517573c8821590e04c955cd37

--001517573c8821590e04c955cd37
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Mon, Sep 10, 2012 at 4:52 PM, =E9=A9=AC=E7=A3=8A <aware.why@gmail.com> w=
rote:

> Hi all,
>     In xen-4.1.2 src/tools/libxl/libxl_dm.c, there is a function called
> `libxl_build_device_model_args_old`,  the func will build qemu-dm cmdline
> args according to
> the xl-formated configuration file specified by xl create command. There
> are several lines related to vnc option:
>
>  76    if (info->vnc || info->vncdisplay || info->vnclisten ||
> info->vncunused ) {
>
>
>  77        char *vncarg;
>
>
>
>  78        if (ctx->disable_vnc)
>
>
>
>  79          {
>
>
>
>  80            INFO("skipped vnc...");
>
>
>
>  81            goto skip_vnc;
>
>
>
>  82          }
>
>
>
>  83          ...skip....
>
>
> the red part above is added by me for testing forcing to disable vnc in
> consideration of performance.
> But what I got was that the qemu-dm without vnc related options failed to
> create device model.
>
> In my case, the vm id is 2, the* qemu-dm log info*(not truncated) is as
> follows:
>
>
> domid: 2
> -videoram option does not work with cirrus vga device model. Videoram set
> to 4M.
> Strip off blktap sub-type prefix to /home/malei/c2.delta.img (drv 'qcow2'=
)
> Using file /home/malei/c2.delta.img in read-write mode
> Strip off blktap sub-type prefix to /home/malei/d2.delta.img (drv 'qcow2'=
)
> Using file /home/malei/d2.delta.img in read-write 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/4
> qemu_map_cache_init nr_buckets =3D 10000 size 4194304
> shared page at pfn feffd
> buffered io page at pfn feffb
> Guest uuid =3D d06b08f0-491f-43d6-9a01-ac317aea5034
> 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.
> qemu: match NIC model: rtl8139
> pci_rtl8139_init: s->macaddr: 0 16 3e eb ca 66
> xs_read(/local/domain/0/device-model/2/xen_extended_power_mgmt): read
> error
>
> * (stop here, but the normal log should contains other lines like *
> *device model state set to running*
>
> *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/1/log-throttling): read error*
>
> *qemu: ignoring not-understood drive `/local/domain/1/log-throttling'*
>
> *medium change watch on `/local/domain/1/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.)*
>
>
> and the* xl log info* is:
>
>
> Waiting for domain xp-102 (domid 2) to die [pid 14006]
> Domain 2 is dead
> Unknown shutdown reason code 255. Destroying domain.
> Action for shutdown reason code 255 is destroy
> Domain 2 needs to be cleaned up: destroying the domain
> libxl: error: libxl_dm.c:779:libxl__destroy_device_model Couldn't find
> device model's pid: No such file or directory
> libxl: error: libxl.c:752:libxl_domain_destroy libxl__destroy_device_mode=
l
> failed for 2
> Done. Exiting now
>
>
> I dig into the src/tools/ioemu-qemu-xen/i386-dm/helper2.c,  found  the
> function :
>
> 553-int main_loop(void)
>
>
>
> 554{
>
>
>
> 555    CPUState *env =3D cpu_single_env;
>
>
>
> 556    int evtchn_fd =3D xce_handle =3D=3D NULL ? -1 : xc_evtchn_fd(xce_h=
andle);
>
>
>
> 557    char *qemu_file;
>
>
>
> 558    fd_set fds;
>
>
>
> 559
>
>
>
> 560    main_loop_prepare();
>
>
>
> 561
>
>
>
> 562    buffered_io_timer =3D qemu_new_timer(rt_clock, handle_buffered_io,
>
>
>
> 563                                       cpu_single_env);
>
>
>
> 564    qemu_mod_timer(buffered_io_timer, qemu_get_clock(rt_clock));
>
>
>
> 565
>
>
>
> 566    if (evtchn_fd !=3D -1)
>
>
>
> 567        qemu_set_fd_handler(evtchn_fd, cpu_handle_ioreq, NULL, env);
>
>
>
> 568
>
>
>
> 569    fprintf(logfile, "device model state set to running\n");
>
>
>
> 570    xenstore_record_dm_state("running");
> *
> *
>
> *In normal circumstance, the qemu-dm log info will record the red line
> above, but when disable vnc, it seems that it didn't go  into the functio=
n
> `main_loop` and didn't see that line.*
> *What happend to that and How to disable the vnc ?*
>
>
I try to inspect the source code, but reap nothing...

--001517573c8821590e04c955cd37
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: base64

PGJyPjxicj48ZGl2IGNsYXNzPSJnbWFpbF9xdW90ZSI+T24gTW9uLCBTZXAgMTAsIDIwMTIgYXQg
NDo1MiBQTSwg6ams56OKIDxzcGFuIGRpcj0ibHRyIj4mbHQ7PGEgaHJlZj0ibWFpbHRvOmF3YXJl
LndoeUBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5hd2FyZS53aHlAZ21haWwuY29tPC9hPiZn
dDs8L3NwYW4+IHdyb3RlOjxicj48YmxvY2txdW90ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0eWxl
PSJtYXJnaW46MCAwIDAgLjhleDtib3JkZXItbGVmdDoxcHggI2NjYyBzb2xpZDtwYWRkaW5nLWxl
ZnQ6MWV4Ij4KSGkgYWxsLDxkaXY+wqAgwqAgSW4geGVuLTQuMS4yIHNyYy90b29scy9saWJ4bC9s
aWJ4bF9kbS5jLCB0aGVyZSBpcyBhIGZ1bmN0aW9uIGNhbGxlZCBgbGlieGxfYnVpbGRfZGV2aWNl
X21vZGVsX2FyZ3Nfb2xkYCwgwqB0aGUgZnVuYyB3aWxsIGJ1aWxkIHFlbXUtZG0gY21kbGluZSBh
cmdzIGFjY29yZGluZyB0bzwvZGl2PjxkaXY+dGhlIHhsLWZvcm1hdGVkIGNvbmZpZ3VyYXRpb24g
ZmlsZSBzcGVjaWZpZWQgYnkgeGwgY3JlYXRlIGNvbW1hbmQuIFRoZXJlIGFyZSBzZXZlcmFsIGxp
bmVzIHJlbGF0ZWQgdG8gdm5jIG9wdGlvbjo8L2Rpdj4KCjxkaXY+PGJyPjwvZGl2PjxibG9ja3F1
b3RlIHN0eWxlPSJtYXJnaW46MCAwIDAgNDBweDtib3JkZXI6bm9uZTtwYWRkaW5nOjBweCI+PGRp
dj48ZGl2PsKgNzYgwqAgwqBpZiAoaW5mby0mZ3Q7dm5jIHx8IGluZm8tJmd0O3ZuY2Rpc3BsYXkg
fHwgaW5mby0mZ3Q7dm5jbGlzdGVuIHx8IGluZm8tJmd0O3ZuY3VudXNlZCApIHsgwqAgwqAgwqAg
wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg
wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg
wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg
wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqA8L2Rpdj4K
CjwvZGl2PjxkaXY+PGRpdj7CoDc3IMKgIMKgIMKgIMKgY2hhciAqdm5jYXJnOyDCoCDCoCDCoCDC
oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC
oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC
oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC
oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC
oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC
oCDCoCDCoCDCoCDCoCDCoCDCoCDCoDwvZGl2PgoKPC9kaXY+PGRpdj48ZGl2PsKgPGZvbnQgY29s
b3I9IiNmZjAwMDAiPjc4IMKgIMKgIMKgIMKgaWYgKGN0eC0mZ3Q7ZGlzYWJsZV92bmMpIMKgIMKg
IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg
IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg
IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg
IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg
IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg
IMKgIMKgIMKgIMKgIMKgPC9mb250PjwvZGl2PgoKPC9kaXY+PGRpdj48ZGl2Pjxmb250IGNvbG9y
PSIjZmYwMDAwIj7CoDc5IMKgIMKgIMKgIMKgIMKgeyDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC
oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC
oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC
oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC
oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC
oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC
oCDCoCDCoCDCoCDCoCDCoCDCoCDCoDwvZm9udD48L2Rpdj4KCjwvZGl2PjxkaXY+PGRpdj48Zm9u
dCBjb2xvcj0iI2ZmMDAwMCI+wqA4MCDCoCDCoCDCoCDCoCDCoCDCoElORk8oJnF1b3Q7c2tpcHBl
ZCB2bmMuLi4mcXVvdDspOyDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC
oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC
oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC
oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC
oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC
oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoDwvZm9udD48L2Rpdj4KCjwvZGl2PjxkaXY+PGRp
dj48Zm9udCBjb2xvcj0iI2ZmMDAwMCI+wqA4MSDCoCDCoCDCoCDCoCDCoCDCoGdvdG8gc2tpcF92
bmM7IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg
IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg
IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg
IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg
IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg
IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgwqA8L2ZvbnQ+PC9kaXY+Cgo8L2Rpdj48ZGl2Pjxk
aXY+PGZvbnQgY29sb3I9IiNmZjAwMDAiPsKgODIgwqAgwqAgwqAgwqAgwqB9IMKgIMKgIMKgIMKg
IMKgIMKgIMKgIMKgIMKgIMKgIMKgIDwvZm9udD48L2Rpdj7CoCDCoCDCoCDCoCDCoCDCoCDCoCDC
oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC
oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC
oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC
oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC
oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoDwvZGl2PgoK
PGRpdj48ZGl2PsKgODMgwqAgwqAgwqAgwqAgwqAuLi5za2lwLi4uLiDCoCDCoCDCoCDCoCDCoCDC
oCDCoCDCoCDCoDwvZGl2PjwvZGl2PjwvYmxvY2txdW90ZT48ZGl2Pjxicj48L2Rpdj48ZGl2PnRo
ZSByZWQgcGFydCBhYm92ZSBpcyBhZGRlZCBieSBtZSBmb3IgdGVzdGluZyBmb3JjaW5nIHRvIGRp
c2FibGUgdm5jIGluIGNvbnNpZGVyYXRpb24gb2YgcGVyZm9ybWFuY2UuPC9kaXY+PGRpdj5CdXQg
d2hhdCBJIGdvdCB3YXMgdGhhdCB0aGUgcWVtdS1kbSB3aXRob3V0IHZuYyByZWxhdGVkIG9wdGlv
bnMgZmFpbGVkIHRvIGNyZWF0ZSBkZXZpY2UgbW9kZWwuPC9kaXY+Cgo8ZGl2Pjxicj48L2Rpdj48
ZGl2PkluIG15IGNhc2UsIHRoZSB2bSBpZCBpcyAyLCB0aGU8Yj4gcWVtdS1kbSBsb2cgaW5mbzwv
Yj4obm90IHRydW5jYXRlZCkgaXMgYXMgZm9sbG93czo8L2Rpdj48ZGl2PsKgPC9kaXY+PGJsb2Nr
cXVvdGUgc3R5bGU9Im1hcmdpbjowIDAgMCA0MHB4O2JvcmRlcjpub25lO3BhZGRpbmc6MHB4Ij48
ZGl2PmRvbWlkOiAyPC9kaXY+PGRpdj4tdmlkZW9yYW0gb3B0aW9uIGRvZXMgbm90IHdvcmsgd2l0
aCBjaXJydXMgdmdhIGRldmljZSBtb2RlbC4gVmlkZW9yYW0gc2V0IHRvIDRNLjwvZGl2PgoKPGRp
dj5TdHJpcCBvZmYgYmxrdGFwIHN1Yi10eXBlIHByZWZpeCB0byAvaG9tZS9tYWxlaS9jMi5kZWx0
YS5pbWcgKGRydiAmIzM5O3Fjb3cyJiMzOTspPC9kaXY+PGRpdj5Vc2luZyBmaWxlIC9ob21lL21h
bGVpL2MyLmRlbHRhLmltZyBpbiByZWFkLXdyaXRlIG1vZGU8L2Rpdj48ZGl2PlN0cmlwIG9mZiBi
bGt0YXAgc3ViLXR5cGUgcHJlZml4IHRvIC9ob21lL21hbGVpL2QyLmRlbHRhLmltZyAoZHJ2ICYj
Mzk7cWNvdzImIzM5Oyk8L2Rpdj4KCjxkaXY+VXNpbmcgZmlsZSAvaG9tZS9tYWxlaS9kMi5kZWx0
YS5pbWcgaW4gcmVhZC13cml0ZSBtb2RlPC9kaXY+PGRpdj5XYXRjaGluZyAvbG9jYWwvZG9tYWlu
LzAvZGV2aWNlLW1vZGVsLzIvbG9nZGlydHkvY21kPC9kaXY+PGRpdj5XYXRjaGluZyAvbG9jYWwv
ZG9tYWluLzAvZGV2aWNlLW1vZGVsLzIvY29tbWFuZDwvZGl2PjxkaXY+V2F0Y2hpbmcgL2xvY2Fs
L2RvbWFpbi8yL2NwdTwvZGl2PgoKPGRpdj5jaGFyIGRldmljZSByZWRpcmVjdGVkIHRvIC9kZXYv
cHRzLzQ8L2Rpdj48ZGl2PnFlbXVfbWFwX2NhY2hlX2luaXQgbnJfYnVja2V0cyA9IDEwMDAwIHNp
emUgNDE5NDMwNDwvZGl2PjxkaXY+c2hhcmVkIHBhZ2UgYXQgcGZuIGZlZmZkPC9kaXY+PGRpdj5i
dWZmZXJlZCBpbyBwYWdlIGF0IHBmbiBmZWZmYjwvZGl2PjxkaXY+R3Vlc3QgdXVpZCA9IGQwNmIw
OGYwLTQ5MWYtNDNkNi05YTAxLWFjMzE3YWVhNTAzNDwvZGl2PgoKPGRpdj5wb3B1bGF0aW5nIHZp
ZGVvIFJBTSBhdCBmZjAwMDAwMDwvZGl2PjxkaXY+bWFwcGluZyB2aWRlbyBSQU0gZnJvbSBmZjAw
MDAwMDwvZGl2PjxkaXY+UmVnaXN0ZXIgeGVuIHBsYXRmb3JtLjwvZGl2PjxkaXY+RG9uZSByZWdp
c3RlciBwbGF0Zm9ybS48L2Rpdj48ZGl2PnBsYXRmb3JtX2ZpeGVkX2lvcG9ydDogY2hhbmdlZCBy
by9ydyBzdGF0ZSBvZiBST00gbWVtb3J5IGFyZWEuIG5vdyBpcyBydyBzdGF0ZS48L2Rpdj4KCjxk
aXY+cWVtdTogbWF0Y2ggTklDIG1vZGVsOiBydGw4MTM5PC9kaXY+PGRpdj5wY2lfcnRsODEzOV9p
bml0OiBzLSZndDttYWNhZGRyOiAwIDE2IDNlIGViIGNhIDY2PC9kaXY+PGRpdj54c19yZWFkKC9s
b2NhbC9kb21haW4vMC9kZXZpY2UtbW9kZWwvMi94ZW5fZXh0ZW5kZWRfcG93ZXJfbWdtdCk6IHJl
YWQgZXJyb3LCoCDCoMKgPC9kaXY+PC9ibG9ja3F1b3RlPjxibG9ja3F1b3RlIHN0eWxlPSJtYXJn
aW46MCAwIDAgNDBweDtib3JkZXI6bm9uZTtwYWRkaW5nOjBweCI+Cgo8YmxvY2txdW90ZSBzdHls
ZT0ibWFyZ2luOjAgMCAwIDQwcHg7Ym9yZGVyOm5vbmU7cGFkZGluZzowcHgiPjxkaXY+PHU+wqAo
PHNwYW4gc3R5bGU9ImJhY2tncm91bmQtY29sb3I6cmdiKDI1NSwxMDIsMTAyKSI+c3RvcCBoZXJl
LCBidXQgdGhlIG5vcm1hbCBsb2cgc2hvdWxkIGNvbnRhaW5zIG90aGVyIGxpbmVzIGxpa2U8L3Nw
YW4+wqA8L3U+PC9kaXY+PGRpdj48dT5kZXZpY2UgbW9kZWwgc3RhdGUgc2V0IHRvIHJ1bm5pbmc8
L3U+PC9kaXY+Cgo8L2Jsb2NrcXVvdGU+PGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbjowIDAgMCA0
MHB4O2JvcmRlcjpub25lO3BhZGRpbmc6MHB4Ij48ZGl2Pjx1PkxvZy1kaXJ0eTogbm8gY29tbWFu
ZCB5ZXQuPC91PjwvZGl2PjwvYmxvY2txdW90ZT48YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luOjAg
MCAwIDQwcHg7Ym9yZGVyOm5vbmU7cGFkZGluZzowcHgiPjxkaXY+PHU+SS9PIHJlcXVlc3Qgbm90
IHJlYWR5OiAwLCBwdHI6IDAsIHBvcnQ6IDAsIGRhdGE6IDAsIGNvdW50OiAwLCBzaXplOiAwPC91
PjwvZGl2PgoKPC9ibG9ja3F1b3RlPjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW46MCAwIDAgNDBw
eDtib3JkZXI6bm9uZTtwYWRkaW5nOjBweCI+PGRpdj48dT52Y3B1LXNldDogd2F0Y2ggbm9kZSBl
cnJvci48L3U+PC9kaXY+PC9ibG9ja3F1b3RlPjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW46MCAw
IDAgNDBweDtib3JkZXI6bm9uZTtwYWRkaW5nOjBweCI+PGRpdj48dT54c19yZWFkKC9sb2NhbC9k
b21haW4vMS9sb2ctdGhyb3R0bGluZyk6IHJlYWQgZXJyb3I8L3U+PC9kaXY+Cgo8L2Jsb2NrcXVv
dGU+PGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbjowIDAgMCA0MHB4O2JvcmRlcjpub25lO3BhZGRp
bmc6MHB4Ij48ZGl2Pjx1PnFlbXU6IGlnbm9yaW5nIG5vdC11bmRlcnN0b29kIGRyaXZlIGAvbG9j
YWwvZG9tYWluLzEvbG9nLXRocm90dGxpbmcmIzM5OzwvdT48L2Rpdj48L2Jsb2NrcXVvdGU+PGJs
b2NrcXVvdGUgc3R5bGU9Im1hcmdpbjowIDAgMCA0MHB4O2JvcmRlcjpub25lO3BhZGRpbmc6MHB4
Ij4KCjxkaXY+PHU+bWVkaXVtIGNoYW5nZSB3YXRjaCBvbiBgL2xvY2FsL2RvbWFpbi8xL2xvZy10
aHJvdHRsaW5nJiMzOTsgLSB1bmtub3duIGRldmljZSwgaWdub3JlZDwvdT48L2Rpdj48L2Jsb2Nr
cXVvdGU+PGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbjowIDAgMCA0MHB4O2JvcmRlcjpub25lO3Bh
ZGRpbmc6MHB4Ij48ZGl2Pjx1PmNpcnJ1cyB2Z2EgbWFwIGNoYW5nZSB3aGlsZSBvbiBsZmIgbW9k
ZTwvdT48L2Rpdj4KCjwvYmxvY2txdW90ZT48YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luOjAgMCAw
IDQwcHg7Ym9yZGVyOm5vbmU7cGFkZGluZzowcHgiPjxkaXY+PHU+bWFwcGluZyB2cmFtIHRvIGYw
MDAwMDAwIC0gZjA0MDAwMDA8L3U+PC9kaXY+PC9ibG9ja3F1b3RlPjxibG9ja3F1b3RlIHN0eWxl
PSJtYXJnaW46MCAwIDAgNDBweDtib3JkZXI6bm9uZTtwYWRkaW5nOjBweCI+PGRpdj48dT5wbGF0
Zm9ybV9maXhlZF9pb3BvcnQ6IGNoYW5nZWQgcm8vcncgc3RhdGUgb2YgUk9NIG1lbW9yeSBhcmVh
LiBub3cgaXMgcncgc3RhdGUuPC91PjwvZGl2PgoKPC9ibG9ja3F1b3RlPjxibG9ja3F1b3RlIHN0
eWxlPSJtYXJnaW46MCAwIDAgNDBweDtib3JkZXI6bm9uZTtwYWRkaW5nOjBweCI+PGRpdj48dT5w
bGF0Zm9ybV9maXhlZF9pb3BvcnQ6IGNoYW5nZWQgcm8vcncgc3RhdGUgb2YgUk9NIG1lbW9yeSBh
cmVhLiBub3cgaXMgcm8gc3RhdGUuKTwvdT48L2Rpdj48L2Jsb2NrcXVvdGU+PC9ibG9ja3F1b3Rl
PjxkaXY+PGJyPjwvZGl2PjxkaXY+YW5kIHRoZTxiPiB4bCBsb2cgaW5mbzwvYj4gaXM6PC9kaXY+
Cgo8ZGl2PjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW46MCAwIDAgNDBweDtib3JkZXI6bm9uZTtw
YWRkaW5nOjBweCI+PGRpdj48YnI+PC9kaXY+PGRpdj48ZGl2PldhaXRpbmcgZm9yIGRvbWFpbiB4
cC0xMDIgKGRvbWlkIDIpIHRvIGRpZSBbcGlkIDE0MDA2XTwvZGl2PjwvZGl2PjxkaXY+PGRpdj5E
b21haW4gMiBpcyBkZWFkPC9kaXY+PC9kaXY+PGRpdj48ZGl2PlVua25vd24gc2h1dGRvd24gcmVh
c29uIGNvZGUgMjU1LiBEZXN0cm95aW5nIGRvbWFpbi48L2Rpdj4KCjwvZGl2PjxkaXY+PGRpdj5B
Y3Rpb24gZm9yIHNodXRkb3duIHJlYXNvbiBjb2RlIDI1NSBpcyBkZXN0cm95PC9kaXY+PC9kaXY+
PGRpdj48ZGl2PkRvbWFpbiAyIG5lZWRzIHRvIGJlIGNsZWFuZWQgdXA6IGRlc3Ryb3lpbmcgdGhl
IGRvbWFpbjwvZGl2PjwvZGl2PjxkaXY+PGRpdj5saWJ4bDogZXJyb3I6IGxpYnhsX2RtLmM6Nzc5
OmxpYnhsX19kZXN0cm95X2RldmljZV9tb2RlbCBDb3VsZG4mIzM5O3QgZmluZCBkZXZpY2UgbW9k
ZWwmIzM5O3MgcGlkOiBObyBzdWNoIGZpbGUgb3IgZGlyZWN0b3J5PC9kaXY+Cgo8L2Rpdj48ZGl2
PjxkaXY+bGlieGw6IGVycm9yOiBsaWJ4bC5jOjc1MjpsaWJ4bF9kb21haW5fZGVzdHJveSBsaWJ4
bF9fZGVzdHJveV9kZXZpY2VfbW9kZWwgZmFpbGVkIGZvciAyPC9kaXY+PC9kaXY+PGRpdj48ZGl2
PkRvbmUuIEV4aXRpbmcgbm93PC9kaXY+PC9kaXY+PGRpdj48YnI+PC9kaXY+PC9ibG9ja3F1b3Rl
Pjxicj48L2Rpdj48ZGl2PkkgZGlnIGludG8gdGhlIHNyYy90b29scy9pb2VtdS1xZW11LXhlbi9p
Mzg2LWRtL2hlbHBlcjIuYywgwqBmb3VuZCDCoHRoZSBmdW5jdGlvbiA6PC9kaXY+Cgo8YmxvY2tx
dW90ZSBzdHlsZT0ibWFyZ2luOjAgMCAwIDQwcHg7Ym9yZGVyOm5vbmU7cGFkZGluZzowcHgiPjxk
aXY+PGRpdj41NTMtaW50IG1haW5fbG9vcCh2b2lkKSDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC
oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC
oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC
oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC
oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC
oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC
oCDCoCDCoMKgPC9kaXY+Cgo8L2Rpdj48ZGl2PjxkaXY+NTU0eyDCoCDCoCDCoCDCoCDCoCDCoCDC
oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC
oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC
oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC
oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC
oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC
oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoDwvZGl2PgoKPC9kaXY+
PGRpdj48ZGl2PjU1NSDCoCDCoENQVVN0YXRlICplbnYgPSBjcHVfc2luZ2xlX2VudjsgwqAgwqAg
wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg
wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg
wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg
wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg
wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg
wqAgwqA8L2Rpdj4KCjwvZGl2PjxkaXY+PGRpdj41NTYgwqAgwqBpbnQgZXZ0Y2huX2ZkID0geGNl
X2hhbmRsZSA9PSBOVUxMID8gLTEgOiB4Y19ldnRjaG5fZmQoeGNlX2hhbmRsZSk7IMKgIMKgIMKg
IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg
IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg
IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg
IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg
IMKgIMKgPC9kaXY+Cgo8L2Rpdj48ZGl2PjxkaXY+NTU3IMKgIMKgY2hhciAqcWVtdV9maWxlOyDC
oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC
oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC
oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC
oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC
oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC
oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoMKgPC9kaXY+Cgo8L2Rpdj48ZGl2PjxkaXY+
NTU4IMKgIMKgZmRfc2V0IGZkczsgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg
wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg
wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg
wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg
wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg
wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg
wqAgwqA8L2Rpdj4KCjwvZGl2PjxkaXY+PGRpdj41NTkgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg
wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg
wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg
wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg
wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg
wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg
wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDCoDwvZGl2PgoKPC9kaXY+PGRp
dj48ZGl2PjU2MCDCoCDCoG1haW5fbG9vcF9wcmVwYXJlKCk7IMKgIMKgIMKgIMKgIMKgIMKgIMKg
IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg
IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg
IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg
IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg
IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg
IMKgIMKgwqA8L2Rpdj4KCjwvZGl2PjxkaXY+PGRpdj41NjEgwqAgwqAgwqAgwqAgwqAgwqAgwqAg
wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg
wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg
wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg
wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg
wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg
wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDCoDwvZGl2PgoKPC9kaXY+
PGRpdj48ZGl2PjU2MiDCoCDCoGJ1ZmZlcmVkX2lvX3RpbWVyID0gcWVtdV9uZXdfdGltZXIocnRf
Y2xvY2ssIGhhbmRsZV9idWZmZXJlZF9pbywgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg
wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg
wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg
wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg
wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDCoDwvZGl2PgoKPC9k
aXY+PGRpdj48ZGl2PjU2MyDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC
oCDCoCDCoCDCoCDCoCDCoCBjcHVfc2luZ2xlX2Vudik7IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg
IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg
IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg
IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg
IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg
IMKgIMKgIMKgIMKgIMKgPC9kaXY+Cgo8L2Rpdj48ZGl2PjxkaXY+NTY0IMKgIMKgcWVtdV9tb2Rf
dGltZXIoYnVmZmVyZWRfaW9fdGltZXIsIHFlbXVfZ2V0X2Nsb2NrKHJ0X2Nsb2NrKSk7IMKgIMKg
IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg
IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg
IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg
IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg
IMKgIMKgIMKgIMKgIMKgIMKgwqA8L2Rpdj4KCjwvZGl2PjxkaXY+PGRpdj41NjUgwqAgwqAgwqAg
wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg
wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg
wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg
wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg
wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg
wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDCoDwv
ZGl2PgoKPC9kaXY+PGRpdj48ZGl2PjU2NiDCoCDCoGlmIChldnRjaG5fZmQgIT0gLTEpIMKgIMKg
IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg
IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg
IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg
IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg
IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg
IMKgIMKgIMKgIMKgIMKgIMKgIMKgwqA8L2Rpdj4KCjwvZGl2PjxkaXY+PGRpdj41NjcgwqAgwqAg
wqAgwqBxZW11X3NldF9mZF9oYW5kbGVyKGV2dGNobl9mZCwgY3B1X2hhbmRsZV9pb3JlcSwgTlVM
TCwgZW52KTsgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg
wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg
wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg
wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg
wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDCoDwvZGl2PgoKPC9kaXY+PGRpdj48ZGl2PjU2OCDC
oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC
oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC
oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC
oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC
oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC
oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC
oCDCoMKgPC9kaXY+Cgo8L2Rpdj48ZGl2PjxkaXY+NTY5IMKgIDxmb250IGNvbG9yPSIjZmY2NjY2
Ij7CoGZwcmludGYobG9nZmlsZSwgJnF1b3Q7ZGV2aWNlIG1vZGVsIHN0YXRlIHNldCB0byBydW5u
aW5nXG4mcXVvdDspOyDCoCDCoCDCoCDCoCA8L2ZvbnQ+wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg
wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg
wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg
wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg
wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDCoDwvZGl2
PgoKPC9kaXY+PGRpdj48ZGl2PjU3MCDCoCDCoHhlbnN0b3JlX3JlY29yZF9kbV9zdGF0ZSgmcXVv
dDtydW5uaW5nJnF1b3Q7KTsgwqA8L2Rpdj48L2Rpdj48ZGl2PjxiPjxicj48L2I+PC9kaXY+PC9i
bG9ja3F1b3RlPjxiPkluIG5vcm1hbCBjaXJjdW1zdGFuY2UsIHRoZSBxZW11LWRtIGxvZyBpbmZv
IHdpbGwgcmVjb3JkIHRoZSByZWQgbGluZSBhYm92ZSwgYnV0IHdoZW4gZGlzYWJsZSB2bmMsIGl0
IHNlZW1zIHRoYXQgaXQgZGlkbiYjMzk7dCBnbyDCoGludG8gdGhlIGZ1bmN0aW9uIGBtYWluX2xv
b3BgIGFuZCBkaWRuJiMzOTt0IHNlZSB0aGF0IGxpbmUuPC9iPjxkaXY+Cgo8Yj5XaGF0IGhhcHBl
bmQgdG8gdGhhdCBhbmQgSG93IHRvIGRpc2FibGUgdGhlIHZuYyA/PC9iPjxicj48ZGl2Pjxicj48
L2Rpdj48L2Rpdj4KPC9ibG9ja3F1b3RlPjwvZGl2Pjxicj48ZGl2PkkgdHJ5IHRvIGluc3BlY3Qg
dGhlIHNvdXJjZSBjb2RlLCBidXQgcmVhcCBub3RoaW5nLi4uPC9kaXY+Cg==
--001517573c8821590e04c955cd37--


--===============2331233611765085454==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============2331233611765085454==--


From xen-devel-bounces@lists.xen.org Mon Sep 10 09:44:39 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Sep 2012 09:44: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 1TB0XX-0007TP-5m; Mon, 10 Sep 2012 09:44:23 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <aware.why@gmail.com>) id 1TB0XU-0007TG-MU
	for xen-devel@lists.xensource.com; Mon, 10 Sep 2012 09:44:22 +0000
Received: from [85.158.138.51:56140] by server-4.bemta-3.messagelabs.com id
	7B/B3-24831-376BD405; Mon, 10 Sep 2012 09:44:19 +0000
X-Env-Sender: aware.why@gmail.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1347270258!21616708!1
X-Originating-IP: [209.85.212.171]
X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18809 invoked from network); 10 Sep 2012 09:44:18 -0000
Received: from mail-wi0-f171.google.com (HELO mail-wi0-f171.google.com)
	(209.85.212.171)
	by server-6.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Sep 2012 09:44:18 -0000
Received: by wibhq4 with SMTP id hq4so1585001wib.6
	for <xen-devel@lists.xensource.com>;
	Mon, 10 Sep 2012 02:44:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:content-type; bh=rxzV0nyp2/R3J4lhnuW5ORqz8C8KPYEaE+yk0Tljo0o=;
	b=VGkbUUxgY73/7J2mlbLDFzWdlzMJhNHGXaA0d+2BrpmDxm0nHdCvP48MQ9Mr1u73g7
	R/tag5+V/nRRW8Bwaqf/rH3iLIQ/ZYoH1kngN+BaAu/REPVsP/e0ENMZM2VeOaLgU6r9
	/YK6sthLMXygqOn4P7cVzBveMRI4JPAjGJuiQts2Jrcd7S8jI5bjKJddXzkMAfeIlqKb
	IryID7DSygF+API5NEUOqi25weGXsKDVgyIX6RgLf+HVwboLHxYp9dN5/rmp/FzfsGJr
	nAxODIuAAXA3SQ0ucTyEjNZXE0R/4BROA5T3Lvl01gmvDAt28Z7lxjHtuZEVijg2NISO
	j2SA==
MIME-Version: 1.0
Received: by 10.216.235.197 with SMTP id u47mr7785070weq.180.1347270257760;
	Mon, 10 Sep 2012 02:44:17 -0700 (PDT)
Received: by 10.223.12.69 with HTTP; Mon, 10 Sep 2012 02:44:17 -0700 (PDT)
In-Reply-To: <CA+ePHTCoBnoBRsjGVsMtY3B4BPMA6FopjkF4DGCoX+Mn1JiAfQ@mail.gmail.com>
References: <CA+ePHTCoBnoBRsjGVsMtY3B4BPMA6FopjkF4DGCoX+Mn1JiAfQ@mail.gmail.com>
Date: Mon, 10 Sep 2012 17:44:17 +0800
Message-ID: <CA+ePHTBonmHOrZBxYYTQDMi0FwumBBshr+4yJv_nJq_rZpP4Nw@mail.gmail.com>
From: =?UTF-8?B?6ams56OK?= <aware.why@gmail.com>
To: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [Problem with xen-4.1.2] Creating device model
 failed when disable `-vnc` related options in qemu-dm
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============2331233611765085454=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============2331233611765085454==
Content-Type: multipart/alternative; boundary=001517573c8821590e04c955cd37

--001517573c8821590e04c955cd37
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Mon, Sep 10, 2012 at 4:52 PM, =E9=A9=AC=E7=A3=8A <aware.why@gmail.com> w=
rote:

> Hi all,
>     In xen-4.1.2 src/tools/libxl/libxl_dm.c, there is a function called
> `libxl_build_device_model_args_old`,  the func will build qemu-dm cmdline
> args according to
> the xl-formated configuration file specified by xl create command. There
> are several lines related to vnc option:
>
>  76    if (info->vnc || info->vncdisplay || info->vnclisten ||
> info->vncunused ) {
>
>
>  77        char *vncarg;
>
>
>
>  78        if (ctx->disable_vnc)
>
>
>
>  79          {
>
>
>
>  80            INFO("skipped vnc...");
>
>
>
>  81            goto skip_vnc;
>
>
>
>  82          }
>
>
>
>  83          ...skip....
>
>
> the red part above is added by me for testing forcing to disable vnc in
> consideration of performance.
> But what I got was that the qemu-dm without vnc related options failed to
> create device model.
>
> In my case, the vm id is 2, the* qemu-dm log info*(not truncated) is as
> follows:
>
>
> domid: 2
> -videoram option does not work with cirrus vga device model. Videoram set
> to 4M.
> Strip off blktap sub-type prefix to /home/malei/c2.delta.img (drv 'qcow2'=
)
> Using file /home/malei/c2.delta.img in read-write mode
> Strip off blktap sub-type prefix to /home/malei/d2.delta.img (drv 'qcow2'=
)
> Using file /home/malei/d2.delta.img in read-write 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/4
> qemu_map_cache_init nr_buckets =3D 10000 size 4194304
> shared page at pfn feffd
> buffered io page at pfn feffb
> Guest uuid =3D d06b08f0-491f-43d6-9a01-ac317aea5034
> 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.
> qemu: match NIC model: rtl8139
> pci_rtl8139_init: s->macaddr: 0 16 3e eb ca 66
> xs_read(/local/domain/0/device-model/2/xen_extended_power_mgmt): read
> error
>
> * (stop here, but the normal log should contains other lines like *
> *device model state set to running*
>
> *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/1/log-throttling): read error*
>
> *qemu: ignoring not-understood drive `/local/domain/1/log-throttling'*
>
> *medium change watch on `/local/domain/1/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.)*
>
>
> and the* xl log info* is:
>
>
> Waiting for domain xp-102 (domid 2) to die [pid 14006]
> Domain 2 is dead
> Unknown shutdown reason code 255. Destroying domain.
> Action for shutdown reason code 255 is destroy
> Domain 2 needs to be cleaned up: destroying the domain
> libxl: error: libxl_dm.c:779:libxl__destroy_device_model Couldn't find
> device model's pid: No such file or directory
> libxl: error: libxl.c:752:libxl_domain_destroy libxl__destroy_device_mode=
l
> failed for 2
> Done. Exiting now
>
>
> I dig into the src/tools/ioemu-qemu-xen/i386-dm/helper2.c,  found  the
> function :
>
> 553-int main_loop(void)
>
>
>
> 554{
>
>
>
> 555    CPUState *env =3D cpu_single_env;
>
>
>
> 556    int evtchn_fd =3D xce_handle =3D=3D NULL ? -1 : xc_evtchn_fd(xce_h=
andle);
>
>
>
> 557    char *qemu_file;
>
>
>
> 558    fd_set fds;
>
>
>
> 559
>
>
>
> 560    main_loop_prepare();
>
>
>
> 561
>
>
>
> 562    buffered_io_timer =3D qemu_new_timer(rt_clock, handle_buffered_io,
>
>
>
> 563                                       cpu_single_env);
>
>
>
> 564    qemu_mod_timer(buffered_io_timer, qemu_get_clock(rt_clock));
>
>
>
> 565
>
>
>
> 566    if (evtchn_fd !=3D -1)
>
>
>
> 567        qemu_set_fd_handler(evtchn_fd, cpu_handle_ioreq, NULL, env);
>
>
>
> 568
>
>
>
> 569    fprintf(logfile, "device model state set to running\n");
>
>
>
> 570    xenstore_record_dm_state("running");
> *
> *
>
> *In normal circumstance, the qemu-dm log info will record the red line
> above, but when disable vnc, it seems that it didn't go  into the functio=
n
> `main_loop` and didn't see that line.*
> *What happend to that and How to disable the vnc ?*
>
>
I try to inspect the source code, but reap nothing...

--001517573c8821590e04c955cd37
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: base64

PGJyPjxicj48ZGl2IGNsYXNzPSJnbWFpbF9xdW90ZSI+T24gTW9uLCBTZXAgMTAsIDIwMTIgYXQg
NDo1MiBQTSwg6ams56OKIDxzcGFuIGRpcj0ibHRyIj4mbHQ7PGEgaHJlZj0ibWFpbHRvOmF3YXJl
LndoeUBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5hd2FyZS53aHlAZ21haWwuY29tPC9hPiZn
dDs8L3NwYW4+IHdyb3RlOjxicj48YmxvY2txdW90ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0eWxl
PSJtYXJnaW46MCAwIDAgLjhleDtib3JkZXItbGVmdDoxcHggI2NjYyBzb2xpZDtwYWRkaW5nLWxl
ZnQ6MWV4Ij4KSGkgYWxsLDxkaXY+wqAgwqAgSW4geGVuLTQuMS4yIHNyYy90b29scy9saWJ4bC9s
aWJ4bF9kbS5jLCB0aGVyZSBpcyBhIGZ1bmN0aW9uIGNhbGxlZCBgbGlieGxfYnVpbGRfZGV2aWNl
X21vZGVsX2FyZ3Nfb2xkYCwgwqB0aGUgZnVuYyB3aWxsIGJ1aWxkIHFlbXUtZG0gY21kbGluZSBh
cmdzIGFjY29yZGluZyB0bzwvZGl2PjxkaXY+dGhlIHhsLWZvcm1hdGVkIGNvbmZpZ3VyYXRpb24g
ZmlsZSBzcGVjaWZpZWQgYnkgeGwgY3JlYXRlIGNvbW1hbmQuIFRoZXJlIGFyZSBzZXZlcmFsIGxp
bmVzIHJlbGF0ZWQgdG8gdm5jIG9wdGlvbjo8L2Rpdj4KCjxkaXY+PGJyPjwvZGl2PjxibG9ja3F1
b3RlIHN0eWxlPSJtYXJnaW46MCAwIDAgNDBweDtib3JkZXI6bm9uZTtwYWRkaW5nOjBweCI+PGRp
dj48ZGl2PsKgNzYgwqAgwqBpZiAoaW5mby0mZ3Q7dm5jIHx8IGluZm8tJmd0O3ZuY2Rpc3BsYXkg
fHwgaW5mby0mZ3Q7dm5jbGlzdGVuIHx8IGluZm8tJmd0O3ZuY3VudXNlZCApIHsgwqAgwqAgwqAg
wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg
wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg
wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg
wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqA8L2Rpdj4K
CjwvZGl2PjxkaXY+PGRpdj7CoDc3IMKgIMKgIMKgIMKgY2hhciAqdm5jYXJnOyDCoCDCoCDCoCDC
oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC
oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC
oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC
oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC
oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC
oCDCoCDCoCDCoCDCoCDCoCDCoCDCoDwvZGl2PgoKPC9kaXY+PGRpdj48ZGl2PsKgPGZvbnQgY29s
b3I9IiNmZjAwMDAiPjc4IMKgIMKgIMKgIMKgaWYgKGN0eC0mZ3Q7ZGlzYWJsZV92bmMpIMKgIMKg
IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg
IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg
IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg
IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg
IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg
IMKgIMKgIMKgIMKgIMKgPC9mb250PjwvZGl2PgoKPC9kaXY+PGRpdj48ZGl2Pjxmb250IGNvbG9y
PSIjZmYwMDAwIj7CoDc5IMKgIMKgIMKgIMKgIMKgeyDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC
oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC
oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC
oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC
oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC
oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC
oCDCoCDCoCDCoCDCoCDCoCDCoCDCoDwvZm9udD48L2Rpdj4KCjwvZGl2PjxkaXY+PGRpdj48Zm9u
dCBjb2xvcj0iI2ZmMDAwMCI+wqA4MCDCoCDCoCDCoCDCoCDCoCDCoElORk8oJnF1b3Q7c2tpcHBl
ZCB2bmMuLi4mcXVvdDspOyDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC
oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC
oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC
oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC
oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC
oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoDwvZm9udD48L2Rpdj4KCjwvZGl2PjxkaXY+PGRp
dj48Zm9udCBjb2xvcj0iI2ZmMDAwMCI+wqA4MSDCoCDCoCDCoCDCoCDCoCDCoGdvdG8gc2tpcF92
bmM7IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg
IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg
IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg
IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg
IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg
IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgwqA8L2ZvbnQ+PC9kaXY+Cgo8L2Rpdj48ZGl2Pjxk
aXY+PGZvbnQgY29sb3I9IiNmZjAwMDAiPsKgODIgwqAgwqAgwqAgwqAgwqB9IMKgIMKgIMKgIMKg
IMKgIMKgIMKgIMKgIMKgIMKgIMKgIDwvZm9udD48L2Rpdj7CoCDCoCDCoCDCoCDCoCDCoCDCoCDC
oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC
oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC
oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC
oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC
oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoDwvZGl2PgoK
PGRpdj48ZGl2PsKgODMgwqAgwqAgwqAgwqAgwqAuLi5za2lwLi4uLiDCoCDCoCDCoCDCoCDCoCDC
oCDCoCDCoCDCoDwvZGl2PjwvZGl2PjwvYmxvY2txdW90ZT48ZGl2Pjxicj48L2Rpdj48ZGl2PnRo
ZSByZWQgcGFydCBhYm92ZSBpcyBhZGRlZCBieSBtZSBmb3IgdGVzdGluZyBmb3JjaW5nIHRvIGRp
c2FibGUgdm5jIGluIGNvbnNpZGVyYXRpb24gb2YgcGVyZm9ybWFuY2UuPC9kaXY+PGRpdj5CdXQg
d2hhdCBJIGdvdCB3YXMgdGhhdCB0aGUgcWVtdS1kbSB3aXRob3V0IHZuYyByZWxhdGVkIG9wdGlv
bnMgZmFpbGVkIHRvIGNyZWF0ZSBkZXZpY2UgbW9kZWwuPC9kaXY+Cgo8ZGl2Pjxicj48L2Rpdj48
ZGl2PkluIG15IGNhc2UsIHRoZSB2bSBpZCBpcyAyLCB0aGU8Yj4gcWVtdS1kbSBsb2cgaW5mbzwv
Yj4obm90IHRydW5jYXRlZCkgaXMgYXMgZm9sbG93czo8L2Rpdj48ZGl2PsKgPC9kaXY+PGJsb2Nr
cXVvdGUgc3R5bGU9Im1hcmdpbjowIDAgMCA0MHB4O2JvcmRlcjpub25lO3BhZGRpbmc6MHB4Ij48
ZGl2PmRvbWlkOiAyPC9kaXY+PGRpdj4tdmlkZW9yYW0gb3B0aW9uIGRvZXMgbm90IHdvcmsgd2l0
aCBjaXJydXMgdmdhIGRldmljZSBtb2RlbC4gVmlkZW9yYW0gc2V0IHRvIDRNLjwvZGl2PgoKPGRp
dj5TdHJpcCBvZmYgYmxrdGFwIHN1Yi10eXBlIHByZWZpeCB0byAvaG9tZS9tYWxlaS9jMi5kZWx0
YS5pbWcgKGRydiAmIzM5O3Fjb3cyJiMzOTspPC9kaXY+PGRpdj5Vc2luZyBmaWxlIC9ob21lL21h
bGVpL2MyLmRlbHRhLmltZyBpbiByZWFkLXdyaXRlIG1vZGU8L2Rpdj48ZGl2PlN0cmlwIG9mZiBi
bGt0YXAgc3ViLXR5cGUgcHJlZml4IHRvIC9ob21lL21hbGVpL2QyLmRlbHRhLmltZyAoZHJ2ICYj
Mzk7cWNvdzImIzM5Oyk8L2Rpdj4KCjxkaXY+VXNpbmcgZmlsZSAvaG9tZS9tYWxlaS9kMi5kZWx0
YS5pbWcgaW4gcmVhZC13cml0ZSBtb2RlPC9kaXY+PGRpdj5XYXRjaGluZyAvbG9jYWwvZG9tYWlu
LzAvZGV2aWNlLW1vZGVsLzIvbG9nZGlydHkvY21kPC9kaXY+PGRpdj5XYXRjaGluZyAvbG9jYWwv
ZG9tYWluLzAvZGV2aWNlLW1vZGVsLzIvY29tbWFuZDwvZGl2PjxkaXY+V2F0Y2hpbmcgL2xvY2Fs
L2RvbWFpbi8yL2NwdTwvZGl2PgoKPGRpdj5jaGFyIGRldmljZSByZWRpcmVjdGVkIHRvIC9kZXYv
cHRzLzQ8L2Rpdj48ZGl2PnFlbXVfbWFwX2NhY2hlX2luaXQgbnJfYnVja2V0cyA9IDEwMDAwIHNp
emUgNDE5NDMwNDwvZGl2PjxkaXY+c2hhcmVkIHBhZ2UgYXQgcGZuIGZlZmZkPC9kaXY+PGRpdj5i
dWZmZXJlZCBpbyBwYWdlIGF0IHBmbiBmZWZmYjwvZGl2PjxkaXY+R3Vlc3QgdXVpZCA9IGQwNmIw
OGYwLTQ5MWYtNDNkNi05YTAxLWFjMzE3YWVhNTAzNDwvZGl2PgoKPGRpdj5wb3B1bGF0aW5nIHZp
ZGVvIFJBTSBhdCBmZjAwMDAwMDwvZGl2PjxkaXY+bWFwcGluZyB2aWRlbyBSQU0gZnJvbSBmZjAw
MDAwMDwvZGl2PjxkaXY+UmVnaXN0ZXIgeGVuIHBsYXRmb3JtLjwvZGl2PjxkaXY+RG9uZSByZWdp
c3RlciBwbGF0Zm9ybS48L2Rpdj48ZGl2PnBsYXRmb3JtX2ZpeGVkX2lvcG9ydDogY2hhbmdlZCBy
by9ydyBzdGF0ZSBvZiBST00gbWVtb3J5IGFyZWEuIG5vdyBpcyBydyBzdGF0ZS48L2Rpdj4KCjxk
aXY+cWVtdTogbWF0Y2ggTklDIG1vZGVsOiBydGw4MTM5PC9kaXY+PGRpdj5wY2lfcnRsODEzOV9p
bml0OiBzLSZndDttYWNhZGRyOiAwIDE2IDNlIGViIGNhIDY2PC9kaXY+PGRpdj54c19yZWFkKC9s
b2NhbC9kb21haW4vMC9kZXZpY2UtbW9kZWwvMi94ZW5fZXh0ZW5kZWRfcG93ZXJfbWdtdCk6IHJl
YWQgZXJyb3LCoCDCoMKgPC9kaXY+PC9ibG9ja3F1b3RlPjxibG9ja3F1b3RlIHN0eWxlPSJtYXJn
aW46MCAwIDAgNDBweDtib3JkZXI6bm9uZTtwYWRkaW5nOjBweCI+Cgo8YmxvY2txdW90ZSBzdHls
ZT0ibWFyZ2luOjAgMCAwIDQwcHg7Ym9yZGVyOm5vbmU7cGFkZGluZzowcHgiPjxkaXY+PHU+wqAo
PHNwYW4gc3R5bGU9ImJhY2tncm91bmQtY29sb3I6cmdiKDI1NSwxMDIsMTAyKSI+c3RvcCBoZXJl
LCBidXQgdGhlIG5vcm1hbCBsb2cgc2hvdWxkIGNvbnRhaW5zIG90aGVyIGxpbmVzIGxpa2U8L3Nw
YW4+wqA8L3U+PC9kaXY+PGRpdj48dT5kZXZpY2UgbW9kZWwgc3RhdGUgc2V0IHRvIHJ1bm5pbmc8
L3U+PC9kaXY+Cgo8L2Jsb2NrcXVvdGU+PGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbjowIDAgMCA0
MHB4O2JvcmRlcjpub25lO3BhZGRpbmc6MHB4Ij48ZGl2Pjx1PkxvZy1kaXJ0eTogbm8gY29tbWFu
ZCB5ZXQuPC91PjwvZGl2PjwvYmxvY2txdW90ZT48YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luOjAg
MCAwIDQwcHg7Ym9yZGVyOm5vbmU7cGFkZGluZzowcHgiPjxkaXY+PHU+SS9PIHJlcXVlc3Qgbm90
IHJlYWR5OiAwLCBwdHI6IDAsIHBvcnQ6IDAsIGRhdGE6IDAsIGNvdW50OiAwLCBzaXplOiAwPC91
PjwvZGl2PgoKPC9ibG9ja3F1b3RlPjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW46MCAwIDAgNDBw
eDtib3JkZXI6bm9uZTtwYWRkaW5nOjBweCI+PGRpdj48dT52Y3B1LXNldDogd2F0Y2ggbm9kZSBl
cnJvci48L3U+PC9kaXY+PC9ibG9ja3F1b3RlPjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW46MCAw
IDAgNDBweDtib3JkZXI6bm9uZTtwYWRkaW5nOjBweCI+PGRpdj48dT54c19yZWFkKC9sb2NhbC9k
b21haW4vMS9sb2ctdGhyb3R0bGluZyk6IHJlYWQgZXJyb3I8L3U+PC9kaXY+Cgo8L2Jsb2NrcXVv
dGU+PGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbjowIDAgMCA0MHB4O2JvcmRlcjpub25lO3BhZGRp
bmc6MHB4Ij48ZGl2Pjx1PnFlbXU6IGlnbm9yaW5nIG5vdC11bmRlcnN0b29kIGRyaXZlIGAvbG9j
YWwvZG9tYWluLzEvbG9nLXRocm90dGxpbmcmIzM5OzwvdT48L2Rpdj48L2Jsb2NrcXVvdGU+PGJs
b2NrcXVvdGUgc3R5bGU9Im1hcmdpbjowIDAgMCA0MHB4O2JvcmRlcjpub25lO3BhZGRpbmc6MHB4
Ij4KCjxkaXY+PHU+bWVkaXVtIGNoYW5nZSB3YXRjaCBvbiBgL2xvY2FsL2RvbWFpbi8xL2xvZy10
aHJvdHRsaW5nJiMzOTsgLSB1bmtub3duIGRldmljZSwgaWdub3JlZDwvdT48L2Rpdj48L2Jsb2Nr
cXVvdGU+PGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbjowIDAgMCA0MHB4O2JvcmRlcjpub25lO3Bh
ZGRpbmc6MHB4Ij48ZGl2Pjx1PmNpcnJ1cyB2Z2EgbWFwIGNoYW5nZSB3aGlsZSBvbiBsZmIgbW9k
ZTwvdT48L2Rpdj4KCjwvYmxvY2txdW90ZT48YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luOjAgMCAw
IDQwcHg7Ym9yZGVyOm5vbmU7cGFkZGluZzowcHgiPjxkaXY+PHU+bWFwcGluZyB2cmFtIHRvIGYw
MDAwMDAwIC0gZjA0MDAwMDA8L3U+PC9kaXY+PC9ibG9ja3F1b3RlPjxibG9ja3F1b3RlIHN0eWxl
PSJtYXJnaW46MCAwIDAgNDBweDtib3JkZXI6bm9uZTtwYWRkaW5nOjBweCI+PGRpdj48dT5wbGF0
Zm9ybV9maXhlZF9pb3BvcnQ6IGNoYW5nZWQgcm8vcncgc3RhdGUgb2YgUk9NIG1lbW9yeSBhcmVh
LiBub3cgaXMgcncgc3RhdGUuPC91PjwvZGl2PgoKPC9ibG9ja3F1b3RlPjxibG9ja3F1b3RlIHN0
eWxlPSJtYXJnaW46MCAwIDAgNDBweDtib3JkZXI6bm9uZTtwYWRkaW5nOjBweCI+PGRpdj48dT5w
bGF0Zm9ybV9maXhlZF9pb3BvcnQ6IGNoYW5nZWQgcm8vcncgc3RhdGUgb2YgUk9NIG1lbW9yeSBh
cmVhLiBub3cgaXMgcm8gc3RhdGUuKTwvdT48L2Rpdj48L2Jsb2NrcXVvdGU+PC9ibG9ja3F1b3Rl
PjxkaXY+PGJyPjwvZGl2PjxkaXY+YW5kIHRoZTxiPiB4bCBsb2cgaW5mbzwvYj4gaXM6PC9kaXY+
Cgo8ZGl2PjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW46MCAwIDAgNDBweDtib3JkZXI6bm9uZTtw
YWRkaW5nOjBweCI+PGRpdj48YnI+PC9kaXY+PGRpdj48ZGl2PldhaXRpbmcgZm9yIGRvbWFpbiB4
cC0xMDIgKGRvbWlkIDIpIHRvIGRpZSBbcGlkIDE0MDA2XTwvZGl2PjwvZGl2PjxkaXY+PGRpdj5E
b21haW4gMiBpcyBkZWFkPC9kaXY+PC9kaXY+PGRpdj48ZGl2PlVua25vd24gc2h1dGRvd24gcmVh
c29uIGNvZGUgMjU1LiBEZXN0cm95aW5nIGRvbWFpbi48L2Rpdj4KCjwvZGl2PjxkaXY+PGRpdj5B
Y3Rpb24gZm9yIHNodXRkb3duIHJlYXNvbiBjb2RlIDI1NSBpcyBkZXN0cm95PC9kaXY+PC9kaXY+
PGRpdj48ZGl2PkRvbWFpbiAyIG5lZWRzIHRvIGJlIGNsZWFuZWQgdXA6IGRlc3Ryb3lpbmcgdGhl
IGRvbWFpbjwvZGl2PjwvZGl2PjxkaXY+PGRpdj5saWJ4bDogZXJyb3I6IGxpYnhsX2RtLmM6Nzc5
OmxpYnhsX19kZXN0cm95X2RldmljZV9tb2RlbCBDb3VsZG4mIzM5O3QgZmluZCBkZXZpY2UgbW9k
ZWwmIzM5O3MgcGlkOiBObyBzdWNoIGZpbGUgb3IgZGlyZWN0b3J5PC9kaXY+Cgo8L2Rpdj48ZGl2
PjxkaXY+bGlieGw6IGVycm9yOiBsaWJ4bC5jOjc1MjpsaWJ4bF9kb21haW5fZGVzdHJveSBsaWJ4
bF9fZGVzdHJveV9kZXZpY2VfbW9kZWwgZmFpbGVkIGZvciAyPC9kaXY+PC9kaXY+PGRpdj48ZGl2
PkRvbmUuIEV4aXRpbmcgbm93PC9kaXY+PC9kaXY+PGRpdj48YnI+PC9kaXY+PC9ibG9ja3F1b3Rl
Pjxicj48L2Rpdj48ZGl2PkkgZGlnIGludG8gdGhlIHNyYy90b29scy9pb2VtdS1xZW11LXhlbi9p
Mzg2LWRtL2hlbHBlcjIuYywgwqBmb3VuZCDCoHRoZSBmdW5jdGlvbiA6PC9kaXY+Cgo8YmxvY2tx
dW90ZSBzdHlsZT0ibWFyZ2luOjAgMCAwIDQwcHg7Ym9yZGVyOm5vbmU7cGFkZGluZzowcHgiPjxk
aXY+PGRpdj41NTMtaW50IG1haW5fbG9vcCh2b2lkKSDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC
oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC
oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC
oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC
oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC
oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC
oCDCoCDCoMKgPC9kaXY+Cgo8L2Rpdj48ZGl2PjxkaXY+NTU0eyDCoCDCoCDCoCDCoCDCoCDCoCDC
oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC
oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC
oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC
oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC
oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC
oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoDwvZGl2PgoKPC9kaXY+
PGRpdj48ZGl2PjU1NSDCoCDCoENQVVN0YXRlICplbnYgPSBjcHVfc2luZ2xlX2VudjsgwqAgwqAg
wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg
wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg
wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg
wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg
wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg
wqAgwqA8L2Rpdj4KCjwvZGl2PjxkaXY+PGRpdj41NTYgwqAgwqBpbnQgZXZ0Y2huX2ZkID0geGNl
X2hhbmRsZSA9PSBOVUxMID8gLTEgOiB4Y19ldnRjaG5fZmQoeGNlX2hhbmRsZSk7IMKgIMKgIMKg
IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg
IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg
IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg
IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg
IMKgIMKgPC9kaXY+Cgo8L2Rpdj48ZGl2PjxkaXY+NTU3IMKgIMKgY2hhciAqcWVtdV9maWxlOyDC
oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC
oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC
oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC
oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC
oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC
oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoMKgPC9kaXY+Cgo8L2Rpdj48ZGl2PjxkaXY+
NTU4IMKgIMKgZmRfc2V0IGZkczsgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg
wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg
wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg
wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg
wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg
wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg
wqAgwqA8L2Rpdj4KCjwvZGl2PjxkaXY+PGRpdj41NTkgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg
wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg
wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg
wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg
wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg
wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg
wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDCoDwvZGl2PgoKPC9kaXY+PGRp
dj48ZGl2PjU2MCDCoCDCoG1haW5fbG9vcF9wcmVwYXJlKCk7IMKgIMKgIMKgIMKgIMKgIMKgIMKg
IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg
IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg
IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg
IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg
IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg
IMKgIMKgwqA8L2Rpdj4KCjwvZGl2PjxkaXY+PGRpdj41NjEgwqAgwqAgwqAgwqAgwqAgwqAgwqAg
wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg
wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg
wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg
wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg
wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg
wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDCoDwvZGl2PgoKPC9kaXY+
PGRpdj48ZGl2PjU2MiDCoCDCoGJ1ZmZlcmVkX2lvX3RpbWVyID0gcWVtdV9uZXdfdGltZXIocnRf
Y2xvY2ssIGhhbmRsZV9idWZmZXJlZF9pbywgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg
wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg
wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg
wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg
wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDCoDwvZGl2PgoKPC9k
aXY+PGRpdj48ZGl2PjU2MyDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC
oCDCoCDCoCDCoCDCoCDCoCBjcHVfc2luZ2xlX2Vudik7IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg
IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg
IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg
IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg
IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg
IMKgIMKgIMKgIMKgIMKgPC9kaXY+Cgo8L2Rpdj48ZGl2PjxkaXY+NTY0IMKgIMKgcWVtdV9tb2Rf
dGltZXIoYnVmZmVyZWRfaW9fdGltZXIsIHFlbXVfZ2V0X2Nsb2NrKHJ0X2Nsb2NrKSk7IMKgIMKg
IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg
IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg
IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg
IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg
IMKgIMKgIMKgIMKgIMKgIMKgwqA8L2Rpdj4KCjwvZGl2PjxkaXY+PGRpdj41NjUgwqAgwqAgwqAg
wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg
wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg
wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg
wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg
wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg
wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDCoDwv
ZGl2PgoKPC9kaXY+PGRpdj48ZGl2PjU2NiDCoCDCoGlmIChldnRjaG5fZmQgIT0gLTEpIMKgIMKg
IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg
IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg
IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg
IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg
IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg
IMKgIMKgIMKgIMKgIMKgIMKgIMKgwqA8L2Rpdj4KCjwvZGl2PjxkaXY+PGRpdj41NjcgwqAgwqAg
wqAgwqBxZW11X3NldF9mZF9oYW5kbGVyKGV2dGNobl9mZCwgY3B1X2hhbmRsZV9pb3JlcSwgTlVM
TCwgZW52KTsgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg
wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg
wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg
wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg
wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDCoDwvZGl2PgoKPC9kaXY+PGRpdj48ZGl2PjU2OCDC
oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC
oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC
oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC
oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC
oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC
oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC
oCDCoMKgPC9kaXY+Cgo8L2Rpdj48ZGl2PjxkaXY+NTY5IMKgIDxmb250IGNvbG9yPSIjZmY2NjY2
Ij7CoGZwcmludGYobG9nZmlsZSwgJnF1b3Q7ZGV2aWNlIG1vZGVsIHN0YXRlIHNldCB0byBydW5u
aW5nXG4mcXVvdDspOyDCoCDCoCDCoCDCoCA8L2ZvbnQ+wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg
wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg
wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg
wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg
wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDCoDwvZGl2
PgoKPC9kaXY+PGRpdj48ZGl2PjU3MCDCoCDCoHhlbnN0b3JlX3JlY29yZF9kbV9zdGF0ZSgmcXVv
dDtydW5uaW5nJnF1b3Q7KTsgwqA8L2Rpdj48L2Rpdj48ZGl2PjxiPjxicj48L2I+PC9kaXY+PC9i
bG9ja3F1b3RlPjxiPkluIG5vcm1hbCBjaXJjdW1zdGFuY2UsIHRoZSBxZW11LWRtIGxvZyBpbmZv
IHdpbGwgcmVjb3JkIHRoZSByZWQgbGluZSBhYm92ZSwgYnV0IHdoZW4gZGlzYWJsZSB2bmMsIGl0
IHNlZW1zIHRoYXQgaXQgZGlkbiYjMzk7dCBnbyDCoGludG8gdGhlIGZ1bmN0aW9uIGBtYWluX2xv
b3BgIGFuZCBkaWRuJiMzOTt0IHNlZSB0aGF0IGxpbmUuPC9iPjxkaXY+Cgo8Yj5XaGF0IGhhcHBl
bmQgdG8gdGhhdCBhbmQgSG93IHRvIGRpc2FibGUgdGhlIHZuYyA/PC9iPjxicj48ZGl2Pjxicj48
L2Rpdj48L2Rpdj4KPC9ibG9ja3F1b3RlPjwvZGl2Pjxicj48ZGl2PkkgdHJ5IHRvIGluc3BlY3Qg
dGhlIHNvdXJjZSBjb2RlLCBidXQgcmVhcCBub3RoaW5nLi4uPC9kaXY+Cg==
--001517573c8821590e04c955cd37--


--===============2331233611765085454==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============2331233611765085454==--


From xen-devel-bounces@lists.xen.org Mon Sep 10 09:46:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Sep 2012 09: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 1TB0Z4-0007aE-S0; Mon, 10 Sep 2012 09:45:58 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1TB0Z4-0007a3-2V
	for xen-devel@lists.xensource.com; Mon, 10 Sep 2012 09:45:58 +0000
Received: from [85.158.138.51:15610] by server-7.bemta-3.messagelabs.com id
	17/36-32000-5D6BD405; Mon, 10 Sep 2012 09:45:57 +0000
X-Env-Sender: fantonifabio@tiscali.it
X-Msg-Ref: server-11.tower-174.messagelabs.com!1347270355!29633058!1
X-Originating-IP: [94.23.245.208]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG,
	ML_RADAR_SPEW_LINKS_14,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10846 invoked from network); 10 Sep 2012 09:45:55 -0000
Received: from lnx3.fantu.it (HELO lnx3.fantu.it) (94.23.245.208)
	by server-11.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 10 Sep 2012 09:45:55 -0000
Received: from localhost (localhost.localdomain [127.0.0.1])
	by lnx3.fantu.it (Postfix) with ESMTP id B265D401FCE
	for <xen-devel@lists.xensource.com>;
	Mon, 10 Sep 2012 11:45:55 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at lnx3.fantu.it
Received: from lnx3.fantu.it ([127.0.0.1])
	by localhost (lnx3.fantu.it [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id iYYTC5SKPfPq for <xen-devel@lists.xensource.com>;
	Mon, 10 Sep 2012 11:45:55 +0200 (CEST)
Received: from [192.168.178.50]
	(host159-164-dynamic.56-82-r.retail.telecomitalia.it [82.56.164.159])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: prova@fantu.it)
	by lnx3.fantu.it (Postfix) with ESMTPSA id D8DE8401F25
	for <xen-devel@lists.xensource.com>;
	Mon, 10 Sep 2012 11:45:54 +0200 (CEST)
Message-ID: <504DB6D0.3050900@tiscali.it>
Date: Mon, 10 Sep 2012 11:45:52 +0200
From: Fabio Fantoni <fantonifabio@tiscali.it>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:14.0) Gecko/20120713 Thunderbird/14.0
MIME-Version: 1.0
To: xen-devel <xen-devel@lists.xensource.com>
Subject: [Xen-devel] Openvswitch error on shutdown/destroy
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="===============7478955774450348560=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Questo è un messaggio firmato digitalmente in formato MIME.

--===============7478955774450348560==
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms060807010403020103010204"

Questo è un messaggio firmato digitalmente in formato MIME.

--------------ms060807010403020103010204
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: quoted-printable

I retried openvswitch on Wheezy 64 bit dom0 with xen 4.2.0-rc4 from sourc=
e

vif script taken from here:
http://xen.1045712.n5.nabble.com/openvswitch-on-xen-4-x-td4662995.html

Network works on dom0 and domU hvm windows 7 but on shutdown/destroy=20
shows this error:

xl destroy W7
libxl: error: libxl_exec.c:118:libxl_report_child_exitstatus:=20
/etc/xen/scripts/vif-bridgeovs offline [4266] exited with error status 1
libxl: error: libxl_device.c:978:device_hotplug_child_death_cb: script:=20
/etc/xen/scripts/vif-bridgeovs failed; error detected.

Probably script need to be updated for xen 4.2 but I don't know exactly

Here my dom0 network configuration:
--------------------------------------------------
/etc/network/interfaces
---------------------------------
auto eth0
allow-hotplug eth0
iface eth0 inet manual
         up ip link set up dev eth0
         down ip link set down dev eth0

auto eth1
allow-hotplug eth1
iface eth1 inet manual
         up ip link set up dev eth1
         down ip link set down dev eth1

allow-ovs xenbr0
iface xenbr0 inet static
      address 192.168.1.30
      netmask 255.255.255.0
      network 192.168.1.0
      broadcast 192.168.1.255
      gateway 192.168.1.200
      ovs_type OVSBridge
      ovs_ports bond0

allow-xenbr0 bond0
iface bond0 inet manual
      ovs_bridge xenbr0
      ovs_type OVSBond
      ovs_bonds eth0 eth1
      ovs_options bond_mode=3Dbalance-tcp lacp=3Dactive
--------------------------------------------------
ifup --allow=3Dovs xenbr0 for start network


--------------ms060807010403020103010204
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: Firma crittografica S/MIME

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINhjCC
BjQwggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT
DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp
Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3
MTAyNDIxMDI1NVoXDTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T
dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu
aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs
aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOM
KqANy9BV7V0igWdGxA8IU77L3aTxErQ+fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi
8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke/s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8M
DP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHksw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y
2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHHtOkzUreG//CsFnB9+uaYSlR65cdG
zTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB
Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd+q9rMfPIHeOsuzAfBgNV
HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH
MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3
dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu
c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v
c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0
dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93
d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqp
Jw3I07QWke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Mic
c/NXcs7kPBRdn6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9Jphw
UPTXwHovjavRnhUQHLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMc
p+reg9901zkyT3fDW/ivJVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT
+HBDYtbuvexNftwNQKD5193A7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1X
hwby6mLhkbaXslkVtwEWT3Van49rKjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvO
hNz/QplNa+VkIsrcp7+8ZhP1l1b2U6MaxIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC
0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqh
AChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H75dVCV33K6FuxZrf09yTz+Vx/PkdRUYk
XmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHSjCCBjKgAwIBAgICHmMwDQYJKoZIhvcNAQEF
BQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJT
ZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD
bGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0xMjAzMTgyMjE0MzBa
Fw0xNDAzMjAwODU3MDlaMIGMMRkwFwYDVQQNExBlQjZPRTM3UlJOUHlsNW0yMQswCQYDVQQG
EwJJVDEQMA4GA1UECBMHQmVyZ2FtbzEQMA4GA1UEBxMHUm92ZXR0YTEWMBQGA1UEAxMNRmFi
aW8gRmFudG9uaTEmMCQGCSqGSIb3DQEJARYXZmFudG9uaWZhYmlvQHRpc2NhbGkuaXQwggEi
MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC1XhckXsX23vgJq76s2f0KT8U8Msov5QgV
10eQBb2wL/TzcmqtZotI7ztKVhio3ehHg+mfu+3EqOkX9Umgut8rP0bPi7AGjkPXbOTT/cSU
Xz2Kw31VGOmiOVoUFGvpQitp3weCkhUJLBipI8EpNyBXpjtQ9yCpnIAqfuc77ybfSnCy7tTR
MBq1BUkfjH1+GL45riosuS4+F+MSUvlYzLiT4rAduAX1Y2IuORDsf9Bce8GBxa6syP9rCyzl
Vk7DIX5k8j2vlnyRATIypn5CQLQxGT6e0f6ac4gvWOHwO2QEBsmZKKs1ZidE4q/9OoNXYX6A
jnHtp1H1vcrek/vVcs19AgMBAAGjggOyMIIDrjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAd
BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFFan8cbEWWBmSTWFtLk2
YNdAcGUbMB8GA1UdIwQYMBaAFK5Vg2/sMcq59x36r2sx88gd46y7MCIGA1UdEQQbMBmBF2Zh
bnRvbmlmYWJpb0B0aXNjYWxpLml0MIICIQYDVR0gBIICGDCCAhQwggIQBgsrBgEEAYG1NwEC
AjCCAf8wLgYIKwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYw
NAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYw
gfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMC
AQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNjb3JkaW5nIHRvIHRoZSBDbGFz
cyAyIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3ks
IHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGluIGNvbXBsaWFuY2Ug
b2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMIGcBggrBgEFBQcCAjCBjzAnFiBT
dGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgECGmRMaWFiaWxpdHkgYW5kIHdh
cnJhbnRpZXMgYXJlIGxpbWl0ZWQhIFNlZSBzZWN0aW9uICJMZWdhbCBhbmQgTGltaXRhdGlv
bnMiIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3kuMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6
Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUyLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYI
KwYBBQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MyL2NsaWVudC9j
YTBCBggrBgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNz
Mi5jbGllbnQuY2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzAN
BgkqhkiG9w0BAQUFAAOCAQEAjzHNqifpDVMkH1TSPFZVIiQ4fh49/V5JMpstgqEZPDaDe5r8
h+fMBZtUa6LLMco03Z9BNEXlqlXKiFk8feVYB8obEjz7YYq1XhO9q7JUmkSs0WGIH4xU0XB1
kPC8T8H+5E//84poYSFHE4pA+Ff68UANP2/EuFJWMjegiefnOr8aM42OAcUkjEWSlautIIX8
oD2GizwQYjWdDDjEonbuMKFP6rY2xGI3PSLI3IVU2opb0/itNhQui3WRxafloJqTlriY8m8+
qSLr2HGftbBlbyzVWB8o//aW0H0LMabjkIvrm7Zmh2vcCxiSxGBwYASuSYXGuQiKAgGptUs1
XJLZuzGCA9owggPWAgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20g
THRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG
A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EC
Ah5jMAkGBSsOAwIaBQCgggIbMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcN
AQkFMQ8XDTEyMDkxMDA5NDU1MlowIwYJKoZIhvcNAQkEMRYEFFlld5rEgrrIknicD/E0XFZ0
UpfAMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggqhkiG
9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcN
AwICASgwgaQGCSsGAQQBgjcQBDGBljCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0
YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25p
bmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp
ZW50IENBAgIeYzCBpgYLKoZIhvcNAQkQAgsxgZaggZMwgYwxCzAJBgNVBAYTAklMMRYwFAYD
VQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0
ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRp
YXRlIENsaWVudCBDQQICHmMwDQYJKoZIhvcNAQEBBQAEggEAA7EqjklvrdRpNMGBMB09dTQ2
l1VTF4l8YpzbZhtlH75to6pBbxoIwutHeBtpo8PfJ0cYXbTlCQB3BtBXuHuIlqwn3PqroCNk
AIWsbhdGMyniUFOCMvGtU1rrDttXZ2F0o5x5hoILsPygf6HTuXl3sqXrYBCjrBNjbp4sEfIl
N91jOgLtW33RPAHWY4UtDoWihsdNG5IjCUKmSM/JPw3I2Xi5oIt6Ro/sWNvQpPLLXk++ilOG
1A8Do5YY1gPitmWFBqEDO6lDQm20nuAgbkwmA41KUvxDtbjWCyV6CGLZH3kOEOup/Zy3arHv
t2iAD+77h57a12cvRlSTOW/eFgMfYAAAAAAAAA==
--------------ms060807010403020103010204--


--===============7478955774450348560==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============7478955774450348560==--


From xen-devel-bounces@lists.xen.org Mon Sep 10 09:46:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Sep 2012 09: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 1TB0Z4-0007aE-S0; Mon, 10 Sep 2012 09:45:58 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1TB0Z4-0007a3-2V
	for xen-devel@lists.xensource.com; Mon, 10 Sep 2012 09:45:58 +0000
Received: from [85.158.138.51:15610] by server-7.bemta-3.messagelabs.com id
	17/36-32000-5D6BD405; Mon, 10 Sep 2012 09:45:57 +0000
X-Env-Sender: fantonifabio@tiscali.it
X-Msg-Ref: server-11.tower-174.messagelabs.com!1347270355!29633058!1
X-Originating-IP: [94.23.245.208]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG,
	ML_RADAR_SPEW_LINKS_14,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10846 invoked from network); 10 Sep 2012 09:45:55 -0000
Received: from lnx3.fantu.it (HELO lnx3.fantu.it) (94.23.245.208)
	by server-11.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 10 Sep 2012 09:45:55 -0000
Received: from localhost (localhost.localdomain [127.0.0.1])
	by lnx3.fantu.it (Postfix) with ESMTP id B265D401FCE
	for <xen-devel@lists.xensource.com>;
	Mon, 10 Sep 2012 11:45:55 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at lnx3.fantu.it
Received: from lnx3.fantu.it ([127.0.0.1])
	by localhost (lnx3.fantu.it [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id iYYTC5SKPfPq for <xen-devel@lists.xensource.com>;
	Mon, 10 Sep 2012 11:45:55 +0200 (CEST)
Received: from [192.168.178.50]
	(host159-164-dynamic.56-82-r.retail.telecomitalia.it [82.56.164.159])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: prova@fantu.it)
	by lnx3.fantu.it (Postfix) with ESMTPSA id D8DE8401F25
	for <xen-devel@lists.xensource.com>;
	Mon, 10 Sep 2012 11:45:54 +0200 (CEST)
Message-ID: <504DB6D0.3050900@tiscali.it>
Date: Mon, 10 Sep 2012 11:45:52 +0200
From: Fabio Fantoni <fantonifabio@tiscali.it>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:14.0) Gecko/20120713 Thunderbird/14.0
MIME-Version: 1.0
To: xen-devel <xen-devel@lists.xensource.com>
Subject: [Xen-devel] Openvswitch error on shutdown/destroy
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="===============7478955774450348560=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Questo è un messaggio firmato digitalmente in formato MIME.

--===============7478955774450348560==
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms060807010403020103010204"

Questo è un messaggio firmato digitalmente in formato MIME.

--------------ms060807010403020103010204
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: quoted-printable

I retried openvswitch on Wheezy 64 bit dom0 with xen 4.2.0-rc4 from sourc=
e

vif script taken from here:
http://xen.1045712.n5.nabble.com/openvswitch-on-xen-4-x-td4662995.html

Network works on dom0 and domU hvm windows 7 but on shutdown/destroy=20
shows this error:

xl destroy W7
libxl: error: libxl_exec.c:118:libxl_report_child_exitstatus:=20
/etc/xen/scripts/vif-bridgeovs offline [4266] exited with error status 1
libxl: error: libxl_device.c:978:device_hotplug_child_death_cb: script:=20
/etc/xen/scripts/vif-bridgeovs failed; error detected.

Probably script need to be updated for xen 4.2 but I don't know exactly

Here my dom0 network configuration:
--------------------------------------------------
/etc/network/interfaces
---------------------------------
auto eth0
allow-hotplug eth0
iface eth0 inet manual
         up ip link set up dev eth0
         down ip link set down dev eth0

auto eth1
allow-hotplug eth1
iface eth1 inet manual
         up ip link set up dev eth1
         down ip link set down dev eth1

allow-ovs xenbr0
iface xenbr0 inet static
      address 192.168.1.30
      netmask 255.255.255.0
      network 192.168.1.0
      broadcast 192.168.1.255
      gateway 192.168.1.200
      ovs_type OVSBridge
      ovs_ports bond0

allow-xenbr0 bond0
iface bond0 inet manual
      ovs_bridge xenbr0
      ovs_type OVSBond
      ovs_bonds eth0 eth1
      ovs_options bond_mode=3Dbalance-tcp lacp=3Dactive
--------------------------------------------------
ifup --allow=3Dovs xenbr0 for start network


--------------ms060807010403020103010204
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: Firma crittografica S/MIME

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINhjCC
BjQwggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT
DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp
Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3
MTAyNDIxMDI1NVoXDTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T
dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu
aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs
aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOM
KqANy9BV7V0igWdGxA8IU77L3aTxErQ+fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi
8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke/s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8M
DP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHksw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y
2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHHtOkzUreG//CsFnB9+uaYSlR65cdG
zTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB
Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd+q9rMfPIHeOsuzAfBgNV
HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH
MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3
dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu
c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v
c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0
dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93
d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqp
Jw3I07QWke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Mic
c/NXcs7kPBRdn6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9Jphw
UPTXwHovjavRnhUQHLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMc
p+reg9901zkyT3fDW/ivJVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT
+HBDYtbuvexNftwNQKD5193A7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1X
hwby6mLhkbaXslkVtwEWT3Van49rKjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvO
hNz/QplNa+VkIsrcp7+8ZhP1l1b2U6MaxIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC
0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqh
AChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H75dVCV33K6FuxZrf09yTz+Vx/PkdRUYk
XmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHSjCCBjKgAwIBAgICHmMwDQYJKoZIhvcNAQEF
BQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJT
ZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD
bGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0xMjAzMTgyMjE0MzBa
Fw0xNDAzMjAwODU3MDlaMIGMMRkwFwYDVQQNExBlQjZPRTM3UlJOUHlsNW0yMQswCQYDVQQG
EwJJVDEQMA4GA1UECBMHQmVyZ2FtbzEQMA4GA1UEBxMHUm92ZXR0YTEWMBQGA1UEAxMNRmFi
aW8gRmFudG9uaTEmMCQGCSqGSIb3DQEJARYXZmFudG9uaWZhYmlvQHRpc2NhbGkuaXQwggEi
MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC1XhckXsX23vgJq76s2f0KT8U8Msov5QgV
10eQBb2wL/TzcmqtZotI7ztKVhio3ehHg+mfu+3EqOkX9Umgut8rP0bPi7AGjkPXbOTT/cSU
Xz2Kw31VGOmiOVoUFGvpQitp3weCkhUJLBipI8EpNyBXpjtQ9yCpnIAqfuc77ybfSnCy7tTR
MBq1BUkfjH1+GL45riosuS4+F+MSUvlYzLiT4rAduAX1Y2IuORDsf9Bce8GBxa6syP9rCyzl
Vk7DIX5k8j2vlnyRATIypn5CQLQxGT6e0f6ac4gvWOHwO2QEBsmZKKs1ZidE4q/9OoNXYX6A
jnHtp1H1vcrek/vVcs19AgMBAAGjggOyMIIDrjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAd
BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFFan8cbEWWBmSTWFtLk2
YNdAcGUbMB8GA1UdIwQYMBaAFK5Vg2/sMcq59x36r2sx88gd46y7MCIGA1UdEQQbMBmBF2Zh
bnRvbmlmYWJpb0B0aXNjYWxpLml0MIICIQYDVR0gBIICGDCCAhQwggIQBgsrBgEEAYG1NwEC
AjCCAf8wLgYIKwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYw
NAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYw
gfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMC
AQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNjb3JkaW5nIHRvIHRoZSBDbGFz
cyAyIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3ks
IHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGluIGNvbXBsaWFuY2Ug
b2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMIGcBggrBgEFBQcCAjCBjzAnFiBT
dGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgECGmRMaWFiaWxpdHkgYW5kIHdh
cnJhbnRpZXMgYXJlIGxpbWl0ZWQhIFNlZSBzZWN0aW9uICJMZWdhbCBhbmQgTGltaXRhdGlv
bnMiIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3kuMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6
Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUyLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYI
KwYBBQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MyL2NsaWVudC9j
YTBCBggrBgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNz
Mi5jbGllbnQuY2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzAN
BgkqhkiG9w0BAQUFAAOCAQEAjzHNqifpDVMkH1TSPFZVIiQ4fh49/V5JMpstgqEZPDaDe5r8
h+fMBZtUa6LLMco03Z9BNEXlqlXKiFk8feVYB8obEjz7YYq1XhO9q7JUmkSs0WGIH4xU0XB1
kPC8T8H+5E//84poYSFHE4pA+Ff68UANP2/EuFJWMjegiefnOr8aM42OAcUkjEWSlautIIX8
oD2GizwQYjWdDDjEonbuMKFP6rY2xGI3PSLI3IVU2opb0/itNhQui3WRxafloJqTlriY8m8+
qSLr2HGftbBlbyzVWB8o//aW0H0LMabjkIvrm7Zmh2vcCxiSxGBwYASuSYXGuQiKAgGptUs1
XJLZuzGCA9owggPWAgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20g
THRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG
A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EC
Ah5jMAkGBSsOAwIaBQCgggIbMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcN
AQkFMQ8XDTEyMDkxMDA5NDU1MlowIwYJKoZIhvcNAQkEMRYEFFlld5rEgrrIknicD/E0XFZ0
UpfAMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggqhkiG
9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcN
AwICASgwgaQGCSsGAQQBgjcQBDGBljCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0
YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25p
bmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp
ZW50IENBAgIeYzCBpgYLKoZIhvcNAQkQAgsxgZaggZMwgYwxCzAJBgNVBAYTAklMMRYwFAYD
VQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0
ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRp
YXRlIENsaWVudCBDQQICHmMwDQYJKoZIhvcNAQEBBQAEggEAA7EqjklvrdRpNMGBMB09dTQ2
l1VTF4l8YpzbZhtlH75to6pBbxoIwutHeBtpo8PfJ0cYXbTlCQB3BtBXuHuIlqwn3PqroCNk
AIWsbhdGMyniUFOCMvGtU1rrDttXZ2F0o5x5hoILsPygf6HTuXl3sqXrYBCjrBNjbp4sEfIl
N91jOgLtW33RPAHWY4UtDoWihsdNG5IjCUKmSM/JPw3I2Xi5oIt6Ro/sWNvQpPLLXk++ilOG
1A8Do5YY1gPitmWFBqEDO6lDQm20nuAgbkwmA41KUvxDtbjWCyV6CGLZH3kOEOup/Zy3arHv
t2iAD+77h57a12cvRlSTOW/eFgMfYAAAAAAAAA==
--------------ms060807010403020103010204--


--===============7478955774450348560==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============7478955774450348560==--


From xen-devel-bounces@lists.xen.org Mon Sep 10 10:15:32 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Sep 2012 10:15:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TB11H-0007y5-Rg; Mon, 10 Sep 2012 10:15: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 1TB11F-0007xp-Ro
	for xen-devel@lists.xen.org; Mon, 10 Sep 2012 10:15:05 +0000
Received: from [85.158.143.99:27137] by server-1.bemta-4.messagelabs.com id
	CA/3A-12504-9ADBD405; Mon, 10 Sep 2012 10:15:05 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1347272103!23092138!2
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTIyODk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20635 invoked from network); 10 Sep 2012 10:15:04 -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;
	10 Sep 2012 10:15:04 -0000
X-IronPort-AV: E=Sophos;i="4.80,396,1344211200"; d="scan'208";a="14438277"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Sep 2012 10:15: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.279.1;
	Mon, 10 Sep 2012 11:15:04 +0100
Message-ID: <1347272103.5305.51.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Roger Pau Monne <roger.pau@citrix.com>
Date: Mon, 10 Sep 2012 11:15:03 +0100
In-Reply-To: <1346772546-98864-1-git-send-email-roger.pau@citrix.com>
References: <1346772546-98864-1-git-send-email-roger.pau@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Jan Beulich <JBeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] libxl: fix error message in
 device_backend_callback
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-09-04 at 16:29 +0100, Roger Pau Monne wrote:
> device_backend_callback error path always says "unable to disconnect",
> but this can also happen during the connection of a device. Fix the
> error message using the information in aodev->action.
> 
> Signed-off-by: Roger Pau Monne <roger.pau@citrix.com>

Acked-by: Ian Campbell <ian.campbell@citrix.com>
and applied.

Jan, can we consider this one for 4.2.1 please.

Ian.

> ---
>  tools/libxl/libxl_device.c |    3 ++-
>  1 files changed, 2 insertions(+), 1 deletions(-)
> 
> diff --git a/tools/libxl/libxl_device.c b/tools/libxl/libxl_device.c
> index 8e8410e..c3283f1 100644
> --- a/tools/libxl/libxl_device.c
> +++ b/tools/libxl/libxl_device.c
> @@ -854,7 +854,8 @@ static void device_backend_callback(libxl__egc *egc, libxl__ev_devstate *ds,
>      }
>  
>      if (rc) {
> -        LOG(ERROR, "unable to disconnect device with path %s",
> +        LOG(ERROR, "unable to %s device with path %s",
> +                   aodev->action == DEVICE_CONNECT ? "connect" : "disconnect",
>                     libxl__device_backend_path(gc, aodev->dev));
>          goto out;
>      }



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 10 10:15:32 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Sep 2012 10:15:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TB11H-0007y5-Rg; Mon, 10 Sep 2012 10:15: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 1TB11F-0007xp-Ro
	for xen-devel@lists.xen.org; Mon, 10 Sep 2012 10:15:05 +0000
Received: from [85.158.143.99:27137] by server-1.bemta-4.messagelabs.com id
	CA/3A-12504-9ADBD405; Mon, 10 Sep 2012 10:15:05 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1347272103!23092138!2
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTIyODk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20635 invoked from network); 10 Sep 2012 10:15:04 -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;
	10 Sep 2012 10:15:04 -0000
X-IronPort-AV: E=Sophos;i="4.80,396,1344211200"; d="scan'208";a="14438277"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Sep 2012 10:15: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.279.1;
	Mon, 10 Sep 2012 11:15:04 +0100
Message-ID: <1347272103.5305.51.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Roger Pau Monne <roger.pau@citrix.com>
Date: Mon, 10 Sep 2012 11:15:03 +0100
In-Reply-To: <1346772546-98864-1-git-send-email-roger.pau@citrix.com>
References: <1346772546-98864-1-git-send-email-roger.pau@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Jan Beulich <JBeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] libxl: fix error message in
 device_backend_callback
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-09-04 at 16:29 +0100, Roger Pau Monne wrote:
> device_backend_callback error path always says "unable to disconnect",
> but this can also happen during the connection of a device. Fix the
> error message using the information in aodev->action.
> 
> Signed-off-by: Roger Pau Monne <roger.pau@citrix.com>

Acked-by: Ian Campbell <ian.campbell@citrix.com>
and applied.

Jan, can we consider this one for 4.2.1 please.

Ian.

> ---
>  tools/libxl/libxl_device.c |    3 ++-
>  1 files changed, 2 insertions(+), 1 deletions(-)
> 
> diff --git a/tools/libxl/libxl_device.c b/tools/libxl/libxl_device.c
> index 8e8410e..c3283f1 100644
> --- a/tools/libxl/libxl_device.c
> +++ b/tools/libxl/libxl_device.c
> @@ -854,7 +854,8 @@ static void device_backend_callback(libxl__egc *egc, libxl__ev_devstate *ds,
>      }
>  
>      if (rc) {
> -        LOG(ERROR, "unable to disconnect device with path %s",
> +        LOG(ERROR, "unable to %s device with path %s",
> +                   aodev->action == DEVICE_CONNECT ? "connect" : "disconnect",
>                     libxl__device_backend_path(gc, aodev->dev));
>          goto out;
>      }



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 10 10:15:37 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Sep 2012 10:15:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TB11G-0007xy-F3; Mon, 10 Sep 2012 10:15: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 1TB11E-0007xp-I0
	for xen-devel@lists.xen.org; Mon, 10 Sep 2012 10:15:04 +0000
Received: from [85.158.143.99:11555] by server-1.bemta-4.messagelabs.com id
	34/2A-12504-7ADBD405; Mon, 10 Sep 2012 10:15:03 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1347272103!23092138!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTIyODk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20511 invoked from network); 10 Sep 2012 10:15:03 -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;
	10 Sep 2012 10:15:03 -0000
X-IronPort-AV: E=Sophos;i="4.80,396,1344211200"; d="scan'208";a="14438276"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Sep 2012 10:15: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.279.1;
	Mon, 10 Sep 2012 11:15:00 +0100
Message-ID: <1347272099.5305.50.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Matt Wilson <msw@amazon.com>
Date: Mon, 10 Sep 2012 11:14:59 +0100
In-Reply-To: <9c9981ddbfd5c0ccaea7.1347094755@u002268147cd4502c336d.ant.amazon.com>
References: <patchbomb.1347094753@u002268147cd4502c336d.ant.amazon.com>
	<9c9981ddbfd5c0ccaea7.1347094755@u002268147cd4502c336d.ant.amazon.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 2 of 2] docs: flesh out xl.cfg documentation,
 correct typos, reorganize
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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-09-08 at 09:59 +0100, Matt Wilson wrote:
>  * Add documentation for msitranslate, power_mgnt, acpi_s3, aspi_s4,
>    gfx_passthru, nomigrate, etc.

>  * Reorganize items in "unclassified" sections like cpuid,
>    gfx_passthru to where they belong

I tried to apply this but it conflicts with Pasi's "xl.cfg: gfx_passthru
documentation improvements" patch which I've already applied.

I had intended to just drop that hunk and apply the rest but the .rej
was pretty big due to the movement etc and I wasn't sure exactly what
the right fix was, so I'm punting it back to you, sorry ;-).

>  * Correct link L<> references so they can be resolved within the
>    document
>  * Remove placeholders for deprecated options device_model and vif2
>  * Remove placeholder for "sched" and "node", as these are options for
>    cpupool configuration. Perhaps cpupool configuration deserves
>    a section in this document.

We have xlcpupool.cfg.pod.5 which you could refer too?

[...]
> +=item C<xauthority=XAUTHORITY>
> +
> +Specifies the path to the X authorty file that should be used to

                              authority

(probably copied from the original location?)

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 10 10:15:37 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Sep 2012 10:15:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TB11G-0007xy-F3; Mon, 10 Sep 2012 10:15: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 1TB11E-0007xp-I0
	for xen-devel@lists.xen.org; Mon, 10 Sep 2012 10:15:04 +0000
Received: from [85.158.143.99:11555] by server-1.bemta-4.messagelabs.com id
	34/2A-12504-7ADBD405; Mon, 10 Sep 2012 10:15:03 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1347272103!23092138!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTIyODk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20511 invoked from network); 10 Sep 2012 10:15:03 -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;
	10 Sep 2012 10:15:03 -0000
X-IronPort-AV: E=Sophos;i="4.80,396,1344211200"; d="scan'208";a="14438276"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Sep 2012 10:15: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.279.1;
	Mon, 10 Sep 2012 11:15:00 +0100
Message-ID: <1347272099.5305.50.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Matt Wilson <msw@amazon.com>
Date: Mon, 10 Sep 2012 11:14:59 +0100
In-Reply-To: <9c9981ddbfd5c0ccaea7.1347094755@u002268147cd4502c336d.ant.amazon.com>
References: <patchbomb.1347094753@u002268147cd4502c336d.ant.amazon.com>
	<9c9981ddbfd5c0ccaea7.1347094755@u002268147cd4502c336d.ant.amazon.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 2 of 2] docs: flesh out xl.cfg documentation,
 correct typos, reorganize
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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-09-08 at 09:59 +0100, Matt Wilson wrote:
>  * Add documentation for msitranslate, power_mgnt, acpi_s3, aspi_s4,
>    gfx_passthru, nomigrate, etc.

>  * Reorganize items in "unclassified" sections like cpuid,
>    gfx_passthru to where they belong

I tried to apply this but it conflicts with Pasi's "xl.cfg: gfx_passthru
documentation improvements" patch which I've already applied.

I had intended to just drop that hunk and apply the rest but the .rej
was pretty big due to the movement etc and I wasn't sure exactly what
the right fix was, so I'm punting it back to you, sorry ;-).

>  * Correct link L<> references so they can be resolved within the
>    document
>  * Remove placeholders for deprecated options device_model and vif2
>  * Remove placeholder for "sched" and "node", as these are options for
>    cpupool configuration. Perhaps cpupool configuration deserves
>    a section in this document.

We have xlcpupool.cfg.pod.5 which you could refer too?

[...]
> +=item C<xauthority=XAUTHORITY>
> +
> +Specifies the path to the X authorty file that should be used to

                              authority

(probably copied from the original location?)

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 10 10:15:45 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Sep 2012 10:15:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TB11b-0007za-KF; Mon, 10 Sep 2012 10:15: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 1TB11a-0007zG-LG
	for xen-devel@lists.xen.org; Mon, 10 Sep 2012 10:15:26 +0000
Received: from [85.158.143.99:13216] by server-3.bemta-4.messagelabs.com id
	F7/E6-08232-EBDBD405; Mon, 10 Sep 2012 10:15:26 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1347272112!22469026!2
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTIyODk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22147 invoked from network); 10 Sep 2012 10:15:23 -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;
	10 Sep 2012 10:15:23 -0000
X-IronPort-AV: E=Sophos;i="4.80,396,1344211200"; d="scan'208";a="14438308"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Sep 2012 10:15: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.279.1;
	Mon, 10 Sep 2012 11:15:16 +0100
Message-ID: <1347272115.5305.53.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Matt Wilson <msw@amazon.com>
Date: Mon, 10 Sep 2012 11:15:15 +0100
In-Reply-To: <8218753a8e3f9285dc68.1347094754@u002268147cd4502c336d.ant.amazon.com>
References: <patchbomb.1347094753@u002268147cd4502c336d.ant.amazon.com>
	<8218753a8e3f9285dc68.1347094754@u002268147cd4502c336d.ant.amazon.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-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] [PATCH 1 of 2] docs: correct formatting errors in
	xmdomain.cfg
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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-09-08 at 09:59 +0100, Matt Wilson wrote:
> This patch corrects the following errors produced by pod2man:
> 
> Hey! The above document had some coding errors, which are explained
> below:
> 
> Around line 301:
>     You can't have =items (as at line 305) unless the first thing after
>     the =over is an =item
> 
> Around line 311:
>     '=item' outside of any '=over'
> 
> Signed-off-by: Matt Wilson <msw@amazon.com>

Acked + applied, thanks.

Jan -- another docs patch for 4.2.0 if poss and 4.2.1 if not.

> 
> diff -r 6a1ee7eacd9c -r 8218753a8e3f docs/man/xmdomain.cfg.pod.5
> --- a/docs/man/xmdomain.cfg.pod.5	Thu Sep 06 21:33:05 2012 -0700
> +++ b/docs/man/xmdomain.cfg.pod.5	Sat Sep 08 01:43:36 2012 -0700
> @@ -298,16 +298,14 @@
>  
>  =back
>  
> +Additionally, the "on_crash" event can also take:
> +
>  =over 4
>  
> -Additionally, the "on_crash" event can also take:
> -
>  =item B<coredump-destroy>
>  
>  Dump the crashed domain's core and then destroy it.
>  
> -=back
> -
>  =item B<coredump-restart>
>  
>  Dump the crashed domain's core and then restart it.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 10 10:15:45 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Sep 2012 10:15:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TB11b-0007za-KF; Mon, 10 Sep 2012 10:15: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 1TB11a-0007zG-LG
	for xen-devel@lists.xen.org; Mon, 10 Sep 2012 10:15:26 +0000
Received: from [85.158.143.99:13216] by server-3.bemta-4.messagelabs.com id
	F7/E6-08232-EBDBD405; Mon, 10 Sep 2012 10:15:26 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1347272112!22469026!2
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTIyODk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22147 invoked from network); 10 Sep 2012 10:15:23 -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;
	10 Sep 2012 10:15:23 -0000
X-IronPort-AV: E=Sophos;i="4.80,396,1344211200"; d="scan'208";a="14438308"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Sep 2012 10:15: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.279.1;
	Mon, 10 Sep 2012 11:15:16 +0100
Message-ID: <1347272115.5305.53.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Matt Wilson <msw@amazon.com>
Date: Mon, 10 Sep 2012 11:15:15 +0100
In-Reply-To: <8218753a8e3f9285dc68.1347094754@u002268147cd4502c336d.ant.amazon.com>
References: <patchbomb.1347094753@u002268147cd4502c336d.ant.amazon.com>
	<8218753a8e3f9285dc68.1347094754@u002268147cd4502c336d.ant.amazon.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-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] [PATCH 1 of 2] docs: correct formatting errors in
	xmdomain.cfg
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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-09-08 at 09:59 +0100, Matt Wilson wrote:
> This patch corrects the following errors produced by pod2man:
> 
> Hey! The above document had some coding errors, which are explained
> below:
> 
> Around line 301:
>     You can't have =items (as at line 305) unless the first thing after
>     the =over is an =item
> 
> Around line 311:
>     '=item' outside of any '=over'
> 
> Signed-off-by: Matt Wilson <msw@amazon.com>

Acked + applied, thanks.

Jan -- another docs patch for 4.2.0 if poss and 4.2.1 if not.

> 
> diff -r 6a1ee7eacd9c -r 8218753a8e3f docs/man/xmdomain.cfg.pod.5
> --- a/docs/man/xmdomain.cfg.pod.5	Thu Sep 06 21:33:05 2012 -0700
> +++ b/docs/man/xmdomain.cfg.pod.5	Sat Sep 08 01:43:36 2012 -0700
> @@ -298,16 +298,14 @@
>  
>  =back
>  
> +Additionally, the "on_crash" event can also take:
> +
>  =over 4
>  
> -Additionally, the "on_crash" event can also take:
> -
>  =item B<coredump-destroy>
>  
>  Dump the crashed domain's core and then destroy it.
>  
> -=back
> -
>  =item B<coredump-restart>
>  
>  Dump the crashed domain's core and then restart it.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 10 10:15:49 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Sep 2012 10:15:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TB11g-00080M-1P; Mon, 10 Sep 2012 10:15: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 1TB11e-0007zE-5q
	for xen-devel@lists.xen.org; Mon, 10 Sep 2012 10:15:30 +0000
Received: from [85.158.143.99:13531] by server-1.bemta-4.messagelabs.com id
	66/0B-12504-1CDBD405; Mon, 10 Sep 2012 10:15:29 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1347272112!22469026!3
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTIyODk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22900 invoked from network); 10 Sep 2012 10:15:28 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Sep 2012 10:15:28 -0000
X-IronPort-AV: E=Sophos;i="4.80,396,1344211200"; d="scan'208";a="14438313"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Sep 2012 10:15: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.279.1;
	Mon, 10 Sep 2012 11:15:28 +0100
Message-ID: <1347272127.5305.54.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Mon, 10 Sep 2012 11:15:27 +0100
In-Reply-To: <504DD183020000780009A1B6@nat28.tlf.novell.com>
References: <504DD183020000780009A1B6@nat28.tlf.novell.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] docs: document "ucode=" hypervisor command
 line option
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2012-09-10 at 10:39 +0100, Jan Beulich wrote:
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Acked and applied. Thanks.

Can/will you take this for 4.2.0 too?

> 
> --- a/docs/misc/xen-command-line.markdown
> +++ b/docs/misc/xen-command-line.markdown
> @@ -785,6 +785,19 @@ Specify the per-cpu trace buffer size in
>  > `= unstable | skewed`
>  
>  ### ucode
> +> `= <integer>`
> +
> +Specify the CPU microcode update blob module index. When positive, this
> +specifies the n-th module (in the GrUB entry, zero based) to be used
> +for updating CPU micrcode. When negative, counting starts at the end of
> +the modules in the GrUB entry (so with the blob commonly being last,
> +one could specify `ucode=-1`). Note that the value of zero is not valid
> +here (entry zero, i.e. the first module, is always the Dom0 kernel
> +image). Note further that use of this option has an unspecified effect
> +when used with xen.efi (there the concept of modules doesn't exist, and
> +the blob gets specified via the `ucode=<filename>` config file/section
> +entry; see [EFI configuration file description](efi.html)).
> +
>  ### unrestricted\_guest
>  > `= <boolean>`
>  
> 
> 
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 10 10:15:49 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Sep 2012 10:15:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TB11g-00080M-1P; Mon, 10 Sep 2012 10:15: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 1TB11e-0007zE-5q
	for xen-devel@lists.xen.org; Mon, 10 Sep 2012 10:15:30 +0000
Received: from [85.158.143.99:13531] by server-1.bemta-4.messagelabs.com id
	66/0B-12504-1CDBD405; Mon, 10 Sep 2012 10:15:29 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1347272112!22469026!3
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTIyODk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22900 invoked from network); 10 Sep 2012 10:15:28 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Sep 2012 10:15:28 -0000
X-IronPort-AV: E=Sophos;i="4.80,396,1344211200"; d="scan'208";a="14438313"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Sep 2012 10:15: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.279.1;
	Mon, 10 Sep 2012 11:15:28 +0100
Message-ID: <1347272127.5305.54.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Mon, 10 Sep 2012 11:15:27 +0100
In-Reply-To: <504DD183020000780009A1B6@nat28.tlf.novell.com>
References: <504DD183020000780009A1B6@nat28.tlf.novell.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] docs: document "ucode=" hypervisor command
 line option
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2012-09-10 at 10:39 +0100, Jan Beulich wrote:
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Acked and applied. Thanks.

Can/will you take this for 4.2.0 too?

> 
> --- a/docs/misc/xen-command-line.markdown
> +++ b/docs/misc/xen-command-line.markdown
> @@ -785,6 +785,19 @@ Specify the per-cpu trace buffer size in
>  > `= unstable | skewed`
>  
>  ### ucode
> +> `= <integer>`
> +
> +Specify the CPU microcode update blob module index. When positive, this
> +specifies the n-th module (in the GrUB entry, zero based) to be used
> +for updating CPU micrcode. When negative, counting starts at the end of
> +the modules in the GrUB entry (so with the blob commonly being last,
> +one could specify `ucode=-1`). Note that the value of zero is not valid
> +here (entry zero, i.e. the first module, is always the Dom0 kernel
> +image). Note further that use of this option has an unspecified effect
> +when used with xen.efi (there the concept of modules doesn't exist, and
> +the blob gets specified via the `ucode=<filename>` config file/section
> +entry; see [EFI configuration file description](efi.html)).
> +
>  ### unrestricted\_guest
>  > `= <boolean>`
>  
> 
> 
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 10 10:15:51 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Sep 2012 10:15:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TB11b-0007zS-7S; Mon, 10 Sep 2012 10:15: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 1TB11a-0007zE-I5
	for xen-devel@lists.xen.org; Mon, 10 Sep 2012 10:15:26 +0000
Received: from [85.158.143.99:32545] by server-1.bemta-4.messagelabs.com id
	70/EA-12504-DBDBD405; Mon, 10 Sep 2012 10:15:25 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1347272112!22469026!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTIyODk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21720 invoked from network); 10 Sep 2012 10:15:16 -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;
	10 Sep 2012 10:15:16 -0000
X-IronPort-AV: E=Sophos;i="4.80,396,1344211200"; d="scan'208";a="14438283"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Sep 2012 10:15: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.279.1;
	Mon, 10 Sep 2012 11:15:12 +0100
Message-ID: <1347272111.5305.52.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: Mon, 10 Sep 2012 11:15:11 +0100
In-Reply-To: <20120905200858.GP8912@reaktio.net>
References: <20120902053549.GF8912@reaktio.net>
	<1346667053.25864.21.camel@zakaz.uk.xensource.com>
	<20120904191229.GH8912@reaktio.net>
	<1346834000.17325.4.camel@zakaz.uk.xensource.com>
	<20120905200858.GP8912@reaktio.net>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Jan Beulich <JBeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v2] xl.cfg: gfx_passthru documentation
	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="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gV2VkLCAyMDEyLTA5LTA1IGF0IDIxOjA4ICswMTAwLCBQYXNpIEvDpHJra8OkaW5lbiB3cm90
ZToKPiBIZWxsbywKPiAKPiB2MjogYWRkcmVzcyByZXZpZXcgY29tbWVudHMuCj4gCj4geGwuY2Zn
LnBvZC41IGRvY3VtZW50YXRpb24gaW1wcm92ZW1lbnRzOgo+IAo+IC0gZ2Z4X3Bhc3N0aHJ1OiBE
b2N1bWVudCBnZnhfcGFzc3RocnUgbWFrZXMgdGhlIEdQVSBiZWNvbWUgcHJpbWFyeSBpbiB0aGUg
Z3Vlc3QKPiAgIGFuZCBvdGhlciBnZW5lcmljIGluZm8gYWJvdXQgZ2Z4X3Bhc3N0aHJ1Lgo+IAo+
IFNpZ25lZC1vZmYtYnk6IFBhc2kgS8Okcmtrw6RpbmVuIDxwYXNpa0Bpa2kuZmk+CgpBY2tlZCAr
IGFwcGxpZWQsIHRoYW5rcy4KCkphbiwgSSB0aGluayB0aGlzIGRvY3Mgb25seSBjaGFuZ2UgY2Fu
IGJlIGEgY2FuZGlkYXRlIGZvciA0LjIuMCwgYnV0IGlmCm5vdCB0aGVuIDQuMi4xIHdvdWxkIGJl
IGdvb2QuIAoKSWFuLgoKPiAKPiAKPiAtLS0geGVuLXVuc3RhYmxlLmhnL2RvY3MvbWFuL3hsLmNm
Zy5wb2QuNS5vcmlnICAyMDEyLTA5LTA1IDIyOjUxOjM5Ljc0NTEzNzA3NiArMDMwMAo+ICsrKyB4
ZW4tdW5zdGFibGUuaGcvZG9jcy9tYW4veGwuY2ZnLnBvZC41ICAgICAgIDIwMTItMDktMDUgMjM6
MDI6MjkuNzQ2MjAzMzY0ICswMzAwCj4gQEAgLTk5Miw3ICs5OTIsNDQgQEAKPiAKPiAgPWl0ZW0g
QjxnZnhfcGFzc3RocnU9Qk9PTEVBTj4KPiAKPiAtRW5hYmxlIGdyYXBoaWNzIGRldmljZSBQQ0kg
cGFzc3Rocm91Z2guIFhYWCB3aGljaCBkZXZpY2UgaXMgcGFzc2VkIHRocm91Z2ggPwo+ICtFbmFi
bGUgZ3JhcGhpY3MgZGV2aWNlIFBDSSBwYXNzdGhyb3VnaC4gVGhpcyBvcHRpb24gbWFrZXMgdGhl
IHBhc3N0aHJ1Cj4gK2dyYXBoaWNzIGNhcmQgYmVjb21lIHByaW1hcnkgZ3JhcGhpY3MgY2FyZCBp
biB0aGUgVk0sIHNvIHRoZSBRZW11IGVtdWxhdGVkCj4gK2dyYXBoaWNzIGFkYXB0ZXIgaXMgZGlz
YWJsZWQsIGFuZCB0aGUgVk5DIGNvbnNvbGUgZm9yIHRoZSBWTSB3b24ndCBoYXZlCj4gK2FueSBn
cmFwaGljcyBvdXRwdXQuIEFsbCBncmFwaGljcyBvdXRwdXQsIGluY2x1ZGluZyBib290IHRpbWUg
UWVtdSBCSU9TCj4gK21lc3NhZ2VzIGZyb20gdGhlIFZNLCB3aWxsIGdvIHRvIHRoZSBwaHlzaWNh
bCBvdXRwdXRzIG9mIHRoZSBwYXNzZWQgdGhydQo+ICtwaHlzaWNhbCBncmFwaGljcyBjYXJkLgo+
ICsKPiArR3JhcGhpY3MgY2FyZCBQQ0kgZGV2aWNlIHRvIHBhc3N0aHJ1IGlzIGNob3NlbiB3aXRo
IEI8cGNpPiBvcHRpb24sCj4gK2V4YWN0bHkgaW4gdGhlIHNhbWUgd2F5IGFzIG5vcm1hbCBYZW4g
UENJIGRldmljZSBwYXNzdGhydS9hc3NpZ25tZW50IGlzIGRvbmUuCj4gK05vdGUgdGhhdCBnZnhf
cGFzc3RocnUgZG9lc24ndCBkbyBhbnkga2luZCBvZiBzaGFyaW5nCj4gK29mIHRoZSBHUFUsIHNv
IHlvdSBjYW4gb25seSBhc3NpZ24gdGhlIEdQVSB0byBvbmUgc2luZ2xlIFZNIGF0IGEgdGltZS4K
PiArCj4gK2dmeF9wYXNzdGhydSBhbHNvIGVuYWJsZXMgdmFyaW91cyBsZWdhY3kgVkdBIG1lbW9y
eSByYW5nZXMsIEJBUnMsIE1NSU9zLAo+ICthbmQgaW9wb3J0cyB0byBiZSBwYXNzZWQgdGhydSB0
byB0aGUgVk0sIHNpbmNlIHRob3NlIGFyZSByZXF1aXJlZAo+ICtmb3IgY29ycmVjdCBvcGVyYXRp
b24gb2YgdGhpbmdzIGxpa2UgVkdBIEJJT1MsIHRleHQgbW9kZSwgVkJFLCBldGMuCj4gKwo+ICtF
bmFibGluZyBnZnhfcGFzc3RocnUgb3B0aW9uIGFsc28gY29waWVzIHRoZSBwaHlzaWNhbCBncmFw
aGljcyBjYXJkCj4gK3ZpZGVvIEJJT1MgdG8gdGhlIGd1ZXN0IG1lbW9yeSwgYW5kIGV4ZWN1dGVz
IHRoZSBWQklPUyBpbiB0aGUgZ3Vlc3QKPiArdG8gZ2V0IHRoZSBncmFwaGljcyBjYXJkIGluaXRp
YWxpemVkLgo+ICsKPiArTW9zdCBncmFwaGljcyBhZGFwdGVycyByZXF1aXJlIHZlbmRvciBzcGVj
aWZpYyB0d2Vha3MgZm9yIHByb3Blcmx5Cj4gK3dvcmtpbmcgZ3JhcGhpY3MgcGFzc3RocnUuIFNl
ZSB0aGUgWGVuVkdBUGFzc3Rocm91Z2hUZXN0ZWRBZGFwdGVycwo+ICtMPGh0dHA6Ly93aWtpLnhl
bi5vcmcvd2lraS9YZW5WR0FQYXNzdGhyb3VnaFRlc3RlZEFkYXB0ZXJzPgo+ICt3aWtpIHBhZ2Ug
Zm9yIGN1cnJlbnRseSBzdXBwb3J0ZWQgZ3JhcGhpY3MgY2FyZHMgZm9yIGdmeF9wYXNzdGhydS4K
PiArCj4gK2dmeF9wYXNzdGhydSBpcyBjdXJyZW50bHkgb25seSBzdXBwb3J0ZWQgd2l0aCB0aGUg
cWVtdS14ZW4tdHJhZGl0aW9uYWwKPiArZGV2aWNlLW1vZGVsLiBVcHN0cmVhbSBxZW11LXhlbiBk
ZXZpY2UtbW9kZWwgY3VycmVudGx5IGRvZXNuJ3QgaGF2ZQo+ICtzdXBwb3J0IGZvciBnZnhfcGFz
c3RocnUuCj4gKwo+ICtOb3RlIHRoYXQgc29tZSBncmFwaGljcyBhZGFwdGVycyAoQU1EL0FUSSBj
YXJkcywgZm9yIGV4YW1wbGUpIGRvbid0Cj4gK25lY2Vzc2FyaWx5IHJlcXVpcmUgZ2Z4X3Bhc3N0
aHJ1IG9wdGlvbiwgc28geW91IGNhbiB1c2UgdGhlIG5vcm1hbAo+ICtYZW4gUENJIHBhc3N0aHJ1
IHRvIGFzc2lnbiB0aGUgZ3JhcGhpY3MgY2FyZCBhcyBhIHNlY29uZGFyeSBncmFwaGljcyBjYXJk
Cj4gK3RvIHRoZSBWTS4gUWVtdSBlbXVsYXRlZCBncmFwaGljcyBjYXJkIHN0YXlzIGFzIHRoZSBw
cmltYXJ5IGdyYXBoaWNzIGNhcmQsCj4gK2FuZCB5b3UgZ2V0IFZOQyBvdXRwdXQgZnJvbSB0aGUg
UWVtdS1lbXVsYXRlZCBwcmltYXJ5IGFkYXB0ZXIuCj4gKwo+ICtNb3JlIGluZm9ybWF0aW9uIGFi
b3V0IFhlbiBnZnhfcGFzc3RocnUgZmVhdHVyZSBpcyBhdmFpbGFibGUKPiArb24gdGhlIFhlblZH
QVBhc3N0aHJvdWdoIEw8aHR0cDovL3dpa2kueGVuLm9yZy93aWtpL1hlblZHQVBhc3N0aHJvdWdo
Pgo+ICt3aWtpIHBhZ2UuCj4gCj4gID1pdGVtIEI8bm9taWdyYXRlPUJPT0xFQU4+Cj4gCgoKCl9f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fClhlbi1kZXZlbCBt
YWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbi5vcmcKaHR0cDovL2xpc3RzLnhlbi5vcmcv
eGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Mon Sep 10 10:15:51 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Sep 2012 10:15:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TB11b-0007zS-7S; Mon, 10 Sep 2012 10:15: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 1TB11a-0007zE-I5
	for xen-devel@lists.xen.org; Mon, 10 Sep 2012 10:15:26 +0000
Received: from [85.158.143.99:32545] by server-1.bemta-4.messagelabs.com id
	70/EA-12504-DBDBD405; Mon, 10 Sep 2012 10:15:25 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1347272112!22469026!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTIyODk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21720 invoked from network); 10 Sep 2012 10:15:16 -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;
	10 Sep 2012 10:15:16 -0000
X-IronPort-AV: E=Sophos;i="4.80,396,1344211200"; d="scan'208";a="14438283"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Sep 2012 10:15: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.279.1;
	Mon, 10 Sep 2012 11:15:12 +0100
Message-ID: <1347272111.5305.52.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: Mon, 10 Sep 2012 11:15:11 +0100
In-Reply-To: <20120905200858.GP8912@reaktio.net>
References: <20120902053549.GF8912@reaktio.net>
	<1346667053.25864.21.camel@zakaz.uk.xensource.com>
	<20120904191229.GH8912@reaktio.net>
	<1346834000.17325.4.camel@zakaz.uk.xensource.com>
	<20120905200858.GP8912@reaktio.net>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Jan Beulich <JBeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v2] xl.cfg: gfx_passthru documentation
	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="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gV2VkLCAyMDEyLTA5LTA1IGF0IDIxOjA4ICswMTAwLCBQYXNpIEvDpHJra8OkaW5lbiB3cm90
ZToKPiBIZWxsbywKPiAKPiB2MjogYWRkcmVzcyByZXZpZXcgY29tbWVudHMuCj4gCj4geGwuY2Zn
LnBvZC41IGRvY3VtZW50YXRpb24gaW1wcm92ZW1lbnRzOgo+IAo+IC0gZ2Z4X3Bhc3N0aHJ1OiBE
b2N1bWVudCBnZnhfcGFzc3RocnUgbWFrZXMgdGhlIEdQVSBiZWNvbWUgcHJpbWFyeSBpbiB0aGUg
Z3Vlc3QKPiAgIGFuZCBvdGhlciBnZW5lcmljIGluZm8gYWJvdXQgZ2Z4X3Bhc3N0aHJ1Lgo+IAo+
IFNpZ25lZC1vZmYtYnk6IFBhc2kgS8Okcmtrw6RpbmVuIDxwYXNpa0Bpa2kuZmk+CgpBY2tlZCAr
IGFwcGxpZWQsIHRoYW5rcy4KCkphbiwgSSB0aGluayB0aGlzIGRvY3Mgb25seSBjaGFuZ2UgY2Fu
IGJlIGEgY2FuZGlkYXRlIGZvciA0LjIuMCwgYnV0IGlmCm5vdCB0aGVuIDQuMi4xIHdvdWxkIGJl
IGdvb2QuIAoKSWFuLgoKPiAKPiAKPiAtLS0geGVuLXVuc3RhYmxlLmhnL2RvY3MvbWFuL3hsLmNm
Zy5wb2QuNS5vcmlnICAyMDEyLTA5LTA1IDIyOjUxOjM5Ljc0NTEzNzA3NiArMDMwMAo+ICsrKyB4
ZW4tdW5zdGFibGUuaGcvZG9jcy9tYW4veGwuY2ZnLnBvZC41ICAgICAgIDIwMTItMDktMDUgMjM6
MDI6MjkuNzQ2MjAzMzY0ICswMzAwCj4gQEAgLTk5Miw3ICs5OTIsNDQgQEAKPiAKPiAgPWl0ZW0g
QjxnZnhfcGFzc3RocnU9Qk9PTEVBTj4KPiAKPiAtRW5hYmxlIGdyYXBoaWNzIGRldmljZSBQQ0kg
cGFzc3Rocm91Z2guIFhYWCB3aGljaCBkZXZpY2UgaXMgcGFzc2VkIHRocm91Z2ggPwo+ICtFbmFi
bGUgZ3JhcGhpY3MgZGV2aWNlIFBDSSBwYXNzdGhyb3VnaC4gVGhpcyBvcHRpb24gbWFrZXMgdGhl
IHBhc3N0aHJ1Cj4gK2dyYXBoaWNzIGNhcmQgYmVjb21lIHByaW1hcnkgZ3JhcGhpY3MgY2FyZCBp
biB0aGUgVk0sIHNvIHRoZSBRZW11IGVtdWxhdGVkCj4gK2dyYXBoaWNzIGFkYXB0ZXIgaXMgZGlz
YWJsZWQsIGFuZCB0aGUgVk5DIGNvbnNvbGUgZm9yIHRoZSBWTSB3b24ndCBoYXZlCj4gK2FueSBn
cmFwaGljcyBvdXRwdXQuIEFsbCBncmFwaGljcyBvdXRwdXQsIGluY2x1ZGluZyBib290IHRpbWUg
UWVtdSBCSU9TCj4gK21lc3NhZ2VzIGZyb20gdGhlIFZNLCB3aWxsIGdvIHRvIHRoZSBwaHlzaWNh
bCBvdXRwdXRzIG9mIHRoZSBwYXNzZWQgdGhydQo+ICtwaHlzaWNhbCBncmFwaGljcyBjYXJkLgo+
ICsKPiArR3JhcGhpY3MgY2FyZCBQQ0kgZGV2aWNlIHRvIHBhc3N0aHJ1IGlzIGNob3NlbiB3aXRo
IEI8cGNpPiBvcHRpb24sCj4gK2V4YWN0bHkgaW4gdGhlIHNhbWUgd2F5IGFzIG5vcm1hbCBYZW4g
UENJIGRldmljZSBwYXNzdGhydS9hc3NpZ25tZW50IGlzIGRvbmUuCj4gK05vdGUgdGhhdCBnZnhf
cGFzc3RocnUgZG9lc24ndCBkbyBhbnkga2luZCBvZiBzaGFyaW5nCj4gK29mIHRoZSBHUFUsIHNv
IHlvdSBjYW4gb25seSBhc3NpZ24gdGhlIEdQVSB0byBvbmUgc2luZ2xlIFZNIGF0IGEgdGltZS4K
PiArCj4gK2dmeF9wYXNzdGhydSBhbHNvIGVuYWJsZXMgdmFyaW91cyBsZWdhY3kgVkdBIG1lbW9y
eSByYW5nZXMsIEJBUnMsIE1NSU9zLAo+ICthbmQgaW9wb3J0cyB0byBiZSBwYXNzZWQgdGhydSB0
byB0aGUgVk0sIHNpbmNlIHRob3NlIGFyZSByZXF1aXJlZAo+ICtmb3IgY29ycmVjdCBvcGVyYXRp
b24gb2YgdGhpbmdzIGxpa2UgVkdBIEJJT1MsIHRleHQgbW9kZSwgVkJFLCBldGMuCj4gKwo+ICtF
bmFibGluZyBnZnhfcGFzc3RocnUgb3B0aW9uIGFsc28gY29waWVzIHRoZSBwaHlzaWNhbCBncmFw
aGljcyBjYXJkCj4gK3ZpZGVvIEJJT1MgdG8gdGhlIGd1ZXN0IG1lbW9yeSwgYW5kIGV4ZWN1dGVz
IHRoZSBWQklPUyBpbiB0aGUgZ3Vlc3QKPiArdG8gZ2V0IHRoZSBncmFwaGljcyBjYXJkIGluaXRp
YWxpemVkLgo+ICsKPiArTW9zdCBncmFwaGljcyBhZGFwdGVycyByZXF1aXJlIHZlbmRvciBzcGVj
aWZpYyB0d2Vha3MgZm9yIHByb3Blcmx5Cj4gK3dvcmtpbmcgZ3JhcGhpY3MgcGFzc3RocnUuIFNl
ZSB0aGUgWGVuVkdBUGFzc3Rocm91Z2hUZXN0ZWRBZGFwdGVycwo+ICtMPGh0dHA6Ly93aWtpLnhl
bi5vcmcvd2lraS9YZW5WR0FQYXNzdGhyb3VnaFRlc3RlZEFkYXB0ZXJzPgo+ICt3aWtpIHBhZ2Ug
Zm9yIGN1cnJlbnRseSBzdXBwb3J0ZWQgZ3JhcGhpY3MgY2FyZHMgZm9yIGdmeF9wYXNzdGhydS4K
PiArCj4gK2dmeF9wYXNzdGhydSBpcyBjdXJyZW50bHkgb25seSBzdXBwb3J0ZWQgd2l0aCB0aGUg
cWVtdS14ZW4tdHJhZGl0aW9uYWwKPiArZGV2aWNlLW1vZGVsLiBVcHN0cmVhbSBxZW11LXhlbiBk
ZXZpY2UtbW9kZWwgY3VycmVudGx5IGRvZXNuJ3QgaGF2ZQo+ICtzdXBwb3J0IGZvciBnZnhfcGFz
c3RocnUuCj4gKwo+ICtOb3RlIHRoYXQgc29tZSBncmFwaGljcyBhZGFwdGVycyAoQU1EL0FUSSBj
YXJkcywgZm9yIGV4YW1wbGUpIGRvbid0Cj4gK25lY2Vzc2FyaWx5IHJlcXVpcmUgZ2Z4X3Bhc3N0
aHJ1IG9wdGlvbiwgc28geW91IGNhbiB1c2UgdGhlIG5vcm1hbAo+ICtYZW4gUENJIHBhc3N0aHJ1
IHRvIGFzc2lnbiB0aGUgZ3JhcGhpY3MgY2FyZCBhcyBhIHNlY29uZGFyeSBncmFwaGljcyBjYXJk
Cj4gK3RvIHRoZSBWTS4gUWVtdSBlbXVsYXRlZCBncmFwaGljcyBjYXJkIHN0YXlzIGFzIHRoZSBw
cmltYXJ5IGdyYXBoaWNzIGNhcmQsCj4gK2FuZCB5b3UgZ2V0IFZOQyBvdXRwdXQgZnJvbSB0aGUg
UWVtdS1lbXVsYXRlZCBwcmltYXJ5IGFkYXB0ZXIuCj4gKwo+ICtNb3JlIGluZm9ybWF0aW9uIGFi
b3V0IFhlbiBnZnhfcGFzc3RocnUgZmVhdHVyZSBpcyBhdmFpbGFibGUKPiArb24gdGhlIFhlblZH
QVBhc3N0aHJvdWdoIEw8aHR0cDovL3dpa2kueGVuLm9yZy93aWtpL1hlblZHQVBhc3N0aHJvdWdo
Pgo+ICt3aWtpIHBhZ2UuCj4gCj4gID1pdGVtIEI8bm9taWdyYXRlPUJPT0xFQU4+Cj4gCgoKCl9f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fClhlbi1kZXZlbCBt
YWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbi5vcmcKaHR0cDovL2xpc3RzLnhlbi5vcmcv
eGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Mon Sep 10 10:21:38 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Sep 2012 10: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 1TB17O-0000Pc-LB; Mon, 10 Sep 2012 10:21:26 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dan.carpenter@oracle.com>) id 1TB17N-0000PD-6G
	for xen-devel@lists.xensource.com; Mon, 10 Sep 2012 10:21:25 +0000
Received: from [85.158.138.51:9282] by server-12.bemta-3.messagelabs.com id
	3A/EC-10384-32FBD405; Mon, 10 Sep 2012 10:21:23 +0000
X-Env-Sender: dan.carpenter@oracle.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1347272481!29568144!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzM3MzI2\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25241 invoked from network); 10 Sep 2012 10:21:23 -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; 10 Sep 2012 10:21:23 -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 q8AALE1q019169
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 10 Sep 2012 10:21:15 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
	q8AALDQU018760
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 10 Sep 2012 10:21:13 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
	q8AALBKl007008; Mon, 10 Sep 2012 05:21:11 -0500
Received: from mwanda (/41.212.103.53) by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 10 Sep 2012 03:21:10 -0700
Date: Mon, 10 Sep 2012 13:21:07 +0300
From: Dan Carpenter <dan.carpenter@oracle.com>
To: Andres Lagar-Cavilla <andreslc@gridcentric.ca>
Message-ID: <20120910102107.GA27456@mwanda>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <504DC8FE020000780009A190@nat28.tlf.novell.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: kernel-janitors@vger.kernel.org, Jeremy Fitzhardinge <jeremy@goop.org>,
	xen-devel@lists.xensource.com, virtualization@lists.linux-foundation.org,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: [Xen-devel] [patch 3/3 v2] xen/privcmd: add a __user annotation to
	a 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

Sparse complains that we lose the __user annotation in the cast here.

drivers/xen/privcmd.c:388:35: warning: cast removes address space of expression
drivers/xen/privcmd.c:388:32: warning: incorrect type in assignment (different address spaces)
drivers/xen/privcmd.c:388:32:    expected unsigned long [noderef] [usertype] <asn:1>*[addressable] [assigned] user_mfn
drivers/xen/privcmd.c:388:32:    got unsigned long [usertype] *<noident>

Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
---
v2: In v1 I removed the const from the declaration but now I just removed it
from the cast.  This data can either be a v1 or a v2 type struct.  The m.arr
data is const in version 2 but not in version 1.

diff --git a/drivers/xen/privcmd.c b/drivers/xen/privcmd.c
index 0ce006a..fceb83e 100644
--- a/drivers/xen/privcmd.c
+++ b/drivers/xen/privcmd.c
@@ -389,7 +389,7 @@ static long privcmd_ioctl_mmap_batch(void __user *udata, int version)
 
 	if (state.global_error && (version == 1)) {
 		/* Write back errors in second pass. */
-		state.user_mfn = (xen_pfn_t *)m.arr;
+		state.user_mfn = (xen_pfn_t __user *)m.arr;
 		state.err      = err_array;
 		ret = traverse_pages(m.num, sizeof(xen_pfn_t),
 				     &pagelist, mmap_return_errors_v1, &state);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 10 10:21:38 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Sep 2012 10: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 1TB17O-0000Pc-LB; Mon, 10 Sep 2012 10:21:26 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dan.carpenter@oracle.com>) id 1TB17N-0000PD-6G
	for xen-devel@lists.xensource.com; Mon, 10 Sep 2012 10:21:25 +0000
Received: from [85.158.138.51:9282] by server-12.bemta-3.messagelabs.com id
	3A/EC-10384-32FBD405; Mon, 10 Sep 2012 10:21:23 +0000
X-Env-Sender: dan.carpenter@oracle.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1347272481!29568144!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzM3MzI2\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25241 invoked from network); 10 Sep 2012 10:21:23 -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; 10 Sep 2012 10:21:23 -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 q8AALE1q019169
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 10 Sep 2012 10:21:15 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
	q8AALDQU018760
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 10 Sep 2012 10:21:13 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
	q8AALBKl007008; Mon, 10 Sep 2012 05:21:11 -0500
Received: from mwanda (/41.212.103.53) by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 10 Sep 2012 03:21:10 -0700
Date: Mon, 10 Sep 2012 13:21:07 +0300
From: Dan Carpenter <dan.carpenter@oracle.com>
To: Andres Lagar-Cavilla <andreslc@gridcentric.ca>
Message-ID: <20120910102107.GA27456@mwanda>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <504DC8FE020000780009A190@nat28.tlf.novell.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: kernel-janitors@vger.kernel.org, Jeremy Fitzhardinge <jeremy@goop.org>,
	xen-devel@lists.xensource.com, virtualization@lists.linux-foundation.org,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: [Xen-devel] [patch 3/3 v2] xen/privcmd: add a __user annotation to
	a 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

Sparse complains that we lose the __user annotation in the cast here.

drivers/xen/privcmd.c:388:35: warning: cast removes address space of expression
drivers/xen/privcmd.c:388:32: warning: incorrect type in assignment (different address spaces)
drivers/xen/privcmd.c:388:32:    expected unsigned long [noderef] [usertype] <asn:1>*[addressable] [assigned] user_mfn
drivers/xen/privcmd.c:388:32:    got unsigned long [usertype] *<noident>

Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
---
v2: In v1 I removed the const from the declaration but now I just removed it
from the cast.  This data can either be a v1 or a v2 type struct.  The m.arr
data is const in version 2 but not in version 1.

diff --git a/drivers/xen/privcmd.c b/drivers/xen/privcmd.c
index 0ce006a..fceb83e 100644
--- a/drivers/xen/privcmd.c
+++ b/drivers/xen/privcmd.c
@@ -389,7 +389,7 @@ static long privcmd_ioctl_mmap_batch(void __user *udata, int version)
 
 	if (state.global_error && (version == 1)) {
 		/* Write back errors in second pass. */
-		state.user_mfn = (xen_pfn_t *)m.arr;
+		state.user_mfn = (xen_pfn_t __user *)m.arr;
 		state.err      = err_array;
 		ret = traverse_pages(m.num, sizeof(xen_pfn_t),
 				     &pagelist, mmap_return_errors_v1, &state);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 10 10:24:52 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Sep 2012 10: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 1TB1AV-0000d3-En; Mon, 10 Sep 2012 10:24:39 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ashok.anand@gmail.com>) id 1TB1AT-0000cw-Su
	for xen-devel@lists.xen.org; Mon, 10 Sep 2012 10:24:38 +0000
Received: from [85.158.143.35:26581] by server-3.bemta-4.messagelabs.com id
	60/CB-08232-5EFBD405; Mon, 10 Sep 2012 10:24:37 +0000
X-Env-Sender: ashok.anand@gmail.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1347272675!14998616!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-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20462 invoked from network); 10 Sep 2012 10:24:36 -0000
Received: from mail-ob0-f173.google.com (HELO mail-ob0-f173.google.com)
	(209.85.214.173)
	by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Sep 2012 10:24:36 -0000
Received: by obbta14 with SMTP id ta14so3529735obb.32
	for <xen-devel@lists.xen.org>; Mon, 10 Sep 2012 03:24:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:content-type; bh=wCtc4KTApKMFj4FHjtuJH/tZrIkUTSNMwzH97ZI6CGs=;
	b=H4jjyf97E5gTmJtqUGXKj6eCDHMvMgsYIhdZ18imcs0Zk60P3zewnSeF5H2RCBlRzv
	KF92wfNq67iEePiiW4eBmJvQVQcNEMYt9d+Uzzm3ypHWhOVdGwePO54IKcz+Zzkvd05Q
	jTtHcMdkKG+MyKtzxgApOtvNO/PdgXy16IObjK5kb469dkVvuEk1ImO9BPSCx5es8fJK
	mmi5/DwMKoYWx2MxgtO1seSSk/DB4BTizs7th7m0ggyIbyKMPi8rheP12ixJaimkCLRz
	YnVlKVY3rE1qcGnfjmBWJfp9zJ7qQlnIPYLHhtYwWODAAx+LzCDvzNnwp56Co16bW4++
	3heA==
MIME-Version: 1.0
Received: by 10.182.190.69 with SMTP id go5mr13785016obc.43.1347272674937;
	Mon, 10 Sep 2012 03:24:34 -0700 (PDT)
Received: by 10.182.32.102 with HTTP; Mon, 10 Sep 2012 03:24:34 -0700 (PDT)
In-Reply-To: <CALQsBOWDE_KqpntG8WJo86omLP3+rhQ0LDMW5vB752ubpF1FAA@mail.gmail.com>
References: <CALQsBOWDE_KqpntG8WJo86omLP3+rhQ0LDMW5vB752ubpF1FAA@mail.gmail.com>
Date: Mon, 10 Sep 2012 15:54:34 +0530
Message-ID: <CALQsBOXFVM+cdhmke5JDJmns2XUpHjyDOVN6R5qrrY9nTOR3SQ@mail.gmail.com>
From: Ashok Anand <ashok.anand@gmail.com>
To: xen-devel@lists.xen.org
Subject: [Xen-devel] issue using SRIOV "Unable to start - perhaps the PF
 driver is not up yet", while PF driver is actually up
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============2699084713964537592=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============2699084713964537592==
Content-Type: multipart/alternative; boundary=f46d04426d22348a2104c9565da8

--f46d04426d22348a2104c9565da8
Content-Type: text/plain; charset=ISO-8859-1

Hi,

I am trying to use SRIOV, usnig xen 4.0 on debian.

On my dom0, xm pci-list-assignable-devices show that
0000:0f:10.0
0000:0f:10.2
0000:0f:10.4
0000:0f:10.6
0000:0f:11.2
0000:0f:11.4
0000:0f:11.6

these virtual interfaces correspond to eth2,

i attach 0f:10.0 to a domU ubuntu machine, xm pci-attach ubuntu 0f:10.0

on my dom0 machine, i can ping other machine using eth2, (implying PF on
eth2 is active)

on my domU machine, when i attach the virtual function, i get the following
messages

[ 2282.688356] ixgbevf 0000:00:00.0: Xen PCI mapped GSI0 to IRQ28
[ 2282.688470] ixgbevf 0000:00:00.0: setting latency timer to 64
[ 2282.690187] ixgbevf 0000:00:00.0: PF still in reset state, assigning new
address

while PF on eth2 is  there and active, since i can ping other machine.

Now, when I try to bring up the VF interface on domU,
 i get the following error

 2476.295582] Unable to start - perhaps the PF Driver isn't up yet
SIOCSIFFLAGS: Network is down
[ 2476.296917] Unable to start - perhaps the PF Driver isn't up yet
SIOCSIFFLAGS: Network is down

and on dmesg on domU,
[ 2476.295582] Unable to start - perhaps the PF Driver isn't up yet
[ 2476.296917] Unable to start - perhaps the PF Driver isn't up yet


Any thoughts on what could be wrong? I have been struggling with this for
quite some time
and would really appreciate your thoughts on it.

Thanks,
Ashok

--f46d04426d22348a2104c9565da8
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div class=3D"gmail_quote">Hi,=A0<div><br></div><div>I am trying to use SRI=
OV, usnig xen 4.0 on debian.=A0</div><div><br></div><div>On my dom0, xm pci=
-list-assignable-devices show that</div><div><div>0000:0f:10.0</div><div>00=
00:0f:10.2</div>
<div>0000:0f:10.4</div>
<div>0000:0f:10.6</div><div>0000:0f:11.2</div><div>0000:0f:11.4</div><div>0=
000:0f:11.6</div></div><div><br></div><div>these virtual interfaces corresp=
ond to eth2,=A0</div><div><br></div><div>i attach 0f:10.0 to a domU ubuntu =
machine,=A0xm pci-attach ubuntu 0f:10.0</div>

<div><br></div><div>on my dom0 machine, i can ping other machine using eth2=
, (implying PF on eth2 is active)</div><div><br></div><div>on my domU machi=
ne, when i attach the virtual function, i get the following messages</div>

<div><br></div><div><div><a href=3D"tel:%5B%202282.688356" value=3D"+122826=
88356" target=3D"_blank">[ 2282.688356</a>] ixgbevf 0000:00:00.0: Xen PCI m=
apped GSI0 to IRQ28</div><div><a href=3D"tel:%5B%202282.688470" value=3D"+1=
2282688470" target=3D"_blank">[ 2282.688470</a>] ixgbevf 0000:00:00.0: sett=
ing latency timer to 64</div>
<div><a href=3D"tel:%5B%202282.690187" value=3D"+12282690187" target=3D"_bl=
ank">[ 2282.690187</a>] ixgbevf 0000:00:00.0: PF still in reset state, assi=
gning new address</div>
</div><div><br></div><div>while PF on eth2 is =A0there and active, since i =
can ping other machine.</div><div><br></div><div>Now, when I try to bring u=
p the VF interface on domU,=A0</div><div>=A0i get the following error</div>=
<div>

<br></div><div><div>=A02476.295582] Unable to start - perhaps the PF Driver=
 isn&#39;t up yet</div><div>SIOCSIFFLAGS: Network is down</div><div>[ 2476.=
296917] Unable to start - perhaps the PF Driver isn&#39;t up yet</div><div>

SIOCSIFFLAGS: Network is down</div></div><div><br></div><div>and on dmesg o=
n domU,=A0</div><div><div>[ 2476.295582] Unable to start - perhaps the PF D=
river isn&#39;t up yet</div><div>[ 2476.296917] Unable to start - perhaps t=
he PF Driver isn&#39;t up yet</div>

</div><div><br></div><div><br></div><div>Any thoughts on what could be wron=
g? I have been struggling with this for quite some time</div><div>and would=
 really appreciate your thoughts on it.</div><div><br></div><div>Thanks,=A0=
</div>
<span class=3D"HOEnZb"><font color=3D"#888888">
<div>Ashok</div><div><br></div><div><br></div><div><br></div><div><br></div=
><div><br></div>
</font></span></div><br>

--f46d04426d22348a2104c9565da8--


--===============2699084713964537592==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============2699084713964537592==--


From xen-devel-bounces@lists.xen.org Mon Sep 10 10:24:52 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Sep 2012 10: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 1TB1AV-0000d3-En; Mon, 10 Sep 2012 10:24:39 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ashok.anand@gmail.com>) id 1TB1AT-0000cw-Su
	for xen-devel@lists.xen.org; Mon, 10 Sep 2012 10:24:38 +0000
Received: from [85.158.143.35:26581] by server-3.bemta-4.messagelabs.com id
	60/CB-08232-5EFBD405; Mon, 10 Sep 2012 10:24:37 +0000
X-Env-Sender: ashok.anand@gmail.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1347272675!14998616!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-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20462 invoked from network); 10 Sep 2012 10:24:36 -0000
Received: from mail-ob0-f173.google.com (HELO mail-ob0-f173.google.com)
	(209.85.214.173)
	by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Sep 2012 10:24:36 -0000
Received: by obbta14 with SMTP id ta14so3529735obb.32
	for <xen-devel@lists.xen.org>; Mon, 10 Sep 2012 03:24:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:content-type; bh=wCtc4KTApKMFj4FHjtuJH/tZrIkUTSNMwzH97ZI6CGs=;
	b=H4jjyf97E5gTmJtqUGXKj6eCDHMvMgsYIhdZ18imcs0Zk60P3zewnSeF5H2RCBlRzv
	KF92wfNq67iEePiiW4eBmJvQVQcNEMYt9d+Uzzm3ypHWhOVdGwePO54IKcz+Zzkvd05Q
	jTtHcMdkKG+MyKtzxgApOtvNO/PdgXy16IObjK5kb469dkVvuEk1ImO9BPSCx5es8fJK
	mmi5/DwMKoYWx2MxgtO1seSSk/DB4BTizs7th7m0ggyIbyKMPi8rheP12ixJaimkCLRz
	YnVlKVY3rE1qcGnfjmBWJfp9zJ7qQlnIPYLHhtYwWODAAx+LzCDvzNnwp56Co16bW4++
	3heA==
MIME-Version: 1.0
Received: by 10.182.190.69 with SMTP id go5mr13785016obc.43.1347272674937;
	Mon, 10 Sep 2012 03:24:34 -0700 (PDT)
Received: by 10.182.32.102 with HTTP; Mon, 10 Sep 2012 03:24:34 -0700 (PDT)
In-Reply-To: <CALQsBOWDE_KqpntG8WJo86omLP3+rhQ0LDMW5vB752ubpF1FAA@mail.gmail.com>
References: <CALQsBOWDE_KqpntG8WJo86omLP3+rhQ0LDMW5vB752ubpF1FAA@mail.gmail.com>
Date: Mon, 10 Sep 2012 15:54:34 +0530
Message-ID: <CALQsBOXFVM+cdhmke5JDJmns2XUpHjyDOVN6R5qrrY9nTOR3SQ@mail.gmail.com>
From: Ashok Anand <ashok.anand@gmail.com>
To: xen-devel@lists.xen.org
Subject: [Xen-devel] issue using SRIOV "Unable to start - perhaps the PF
 driver is not up yet", while PF driver is actually up
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============2699084713964537592=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============2699084713964537592==
Content-Type: multipart/alternative; boundary=f46d04426d22348a2104c9565da8

--f46d04426d22348a2104c9565da8
Content-Type: text/plain; charset=ISO-8859-1

Hi,

I am trying to use SRIOV, usnig xen 4.0 on debian.

On my dom0, xm pci-list-assignable-devices show that
0000:0f:10.0
0000:0f:10.2
0000:0f:10.4
0000:0f:10.6
0000:0f:11.2
0000:0f:11.4
0000:0f:11.6

these virtual interfaces correspond to eth2,

i attach 0f:10.0 to a domU ubuntu machine, xm pci-attach ubuntu 0f:10.0

on my dom0 machine, i can ping other machine using eth2, (implying PF on
eth2 is active)

on my domU machine, when i attach the virtual function, i get the following
messages

[ 2282.688356] ixgbevf 0000:00:00.0: Xen PCI mapped GSI0 to IRQ28
[ 2282.688470] ixgbevf 0000:00:00.0: setting latency timer to 64
[ 2282.690187] ixgbevf 0000:00:00.0: PF still in reset state, assigning new
address

while PF on eth2 is  there and active, since i can ping other machine.

Now, when I try to bring up the VF interface on domU,
 i get the following error

 2476.295582] Unable to start - perhaps the PF Driver isn't up yet
SIOCSIFFLAGS: Network is down
[ 2476.296917] Unable to start - perhaps the PF Driver isn't up yet
SIOCSIFFLAGS: Network is down

and on dmesg on domU,
[ 2476.295582] Unable to start - perhaps the PF Driver isn't up yet
[ 2476.296917] Unable to start - perhaps the PF Driver isn't up yet


Any thoughts on what could be wrong? I have been struggling with this for
quite some time
and would really appreciate your thoughts on it.

Thanks,
Ashok

--f46d04426d22348a2104c9565da8
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div class=3D"gmail_quote">Hi,=A0<div><br></div><div>I am trying to use SRI=
OV, usnig xen 4.0 on debian.=A0</div><div><br></div><div>On my dom0, xm pci=
-list-assignable-devices show that</div><div><div>0000:0f:10.0</div><div>00=
00:0f:10.2</div>
<div>0000:0f:10.4</div>
<div>0000:0f:10.6</div><div>0000:0f:11.2</div><div>0000:0f:11.4</div><div>0=
000:0f:11.6</div></div><div><br></div><div>these virtual interfaces corresp=
ond to eth2,=A0</div><div><br></div><div>i attach 0f:10.0 to a domU ubuntu =
machine,=A0xm pci-attach ubuntu 0f:10.0</div>

<div><br></div><div>on my dom0 machine, i can ping other machine using eth2=
, (implying PF on eth2 is active)</div><div><br></div><div>on my domU machi=
ne, when i attach the virtual function, i get the following messages</div>

<div><br></div><div><div><a href=3D"tel:%5B%202282.688356" value=3D"+122826=
88356" target=3D"_blank">[ 2282.688356</a>] ixgbevf 0000:00:00.0: Xen PCI m=
apped GSI0 to IRQ28</div><div><a href=3D"tel:%5B%202282.688470" value=3D"+1=
2282688470" target=3D"_blank">[ 2282.688470</a>] ixgbevf 0000:00:00.0: sett=
ing latency timer to 64</div>
<div><a href=3D"tel:%5B%202282.690187" value=3D"+12282690187" target=3D"_bl=
ank">[ 2282.690187</a>] ixgbevf 0000:00:00.0: PF still in reset state, assi=
gning new address</div>
</div><div><br></div><div>while PF on eth2 is =A0there and active, since i =
can ping other machine.</div><div><br></div><div>Now, when I try to bring u=
p the VF interface on domU,=A0</div><div>=A0i get the following error</div>=
<div>

<br></div><div><div>=A02476.295582] Unable to start - perhaps the PF Driver=
 isn&#39;t up yet</div><div>SIOCSIFFLAGS: Network is down</div><div>[ 2476.=
296917] Unable to start - perhaps the PF Driver isn&#39;t up yet</div><div>

SIOCSIFFLAGS: Network is down</div></div><div><br></div><div>and on dmesg o=
n domU,=A0</div><div><div>[ 2476.295582] Unable to start - perhaps the PF D=
river isn&#39;t up yet</div><div>[ 2476.296917] Unable to start - perhaps t=
he PF Driver isn&#39;t up yet</div>

</div><div><br></div><div><br></div><div>Any thoughts on what could be wron=
g? I have been struggling with this for quite some time</div><div>and would=
 really appreciate your thoughts on it.</div><div><br></div><div>Thanks,=A0=
</div>
<span class=3D"HOEnZb"><font color=3D"#888888">
<div>Ashok</div><div><br></div><div><br></div><div><br></div><div><br></div=
><div><br></div>
</font></span></div><br>

--f46d04426d22348a2104c9565da8--


--===============2699084713964537592==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============2699084713964537592==--


From xen-devel-bounces@lists.xen.org Mon Sep 10 10:26:52 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Sep 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 1TB1CR-0000lP-W6; Mon, 10 Sep 2012 10:26:39 +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 1TB1CR-0000lH-3M
	for xen-devel@lists.xen.org; Mon, 10 Sep 2012 10:26:39 +0000
Received: from [85.158.143.99:30441] by server-3.bemta-4.messagelabs.com id
	E8/40-08232-E50CD405; Mon, 10 Sep 2012 10:26:38 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1347272794!24208796!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzAwNzQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8700 invoked from network); 10 Sep 2012 10:26:35 -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;
	10 Sep 2012 10:26:35 -0000
X-IronPort-AV: E=Sophos;i="4.80,396,1344211200"; d="scan'208,217";a="37295010"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Sep 2012 10:26:34 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Mon, 10 Sep 2012 06:26:33 -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 1TB1CL-0006Oe-77	for
	xen-devel@lists.xen.org; Mon, 10 Sep 2012 11:26:33 +0100
Message-ID: <504DC059.4070003@citrix.com>
Date: Mon, 10 Sep 2012 11:26:33 +0100
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:14.0) Gecko/20120714 Thunderbird/14.0
MIME-Version: 1.0
To: xen-devel@lists.xen.org
References: <CALQsBOWDE_KqpntG8WJo86omLP3+rhQ0LDMW5vB752ubpF1FAA@mail.gmail.com>
	<CALQsBOXFVM+cdhmke5JDJmns2XUpHjyDOVN6R5qrrY9nTOR3SQ@mail.gmail.com>
In-Reply-To: <CALQsBOXFVM+cdhmke5JDJmns2XUpHjyDOVN6R5qrrY9nTOR3SQ@mail.gmail.com>
X-Enigmail-Version: 1.4.4
Subject: Re: [Xen-devel] issue using SRIOV "Unable to start - perhaps the PF
 driver is not up yet", while PF driver is actually up
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============6736997857128962086=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============6736997857128962086==
Content-Type: multipart/alternative;
	boundary="------------070502040207030606070503"

--------------070502040207030606070503
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit


On 10/09/12 11:24, Ashok Anand wrote:
> Hi, 
>
> I am trying to use SRIOV, usnig xen 4.0 on debian. 
>
> On my dom0, xm pci-list-assignable-devices show that
> 0000:0f:10.0
> 0000:0f:10.2
> 0000:0f:10.4
> 0000:0f:10.6
> 0000:0f:11.2
> 0000:0f:11.4
> 0000:0f:11.6
>
> these virtual interfaces correspond to eth2,

Are you sure?  0f:10.0 is probably the physical function which you must
keep in dom0.

~Andrew

>
> i attach 0f:10.0 to a domU ubuntu machine, xm pci-attach ubuntu 0f:10.0
>
> on my dom0 machine, i can ping other machine using eth2, (implying PF
> on eth2 is active)
>
> on my domU machine, when i attach the virtual function, i get the
> following messages
>
> [ 2282.688356 <tel:%5B%202282.688356>] ixgbevf 0000:00:00.0: Xen PCI
> mapped GSI0 to IRQ28
> [ 2282.688470 <tel:%5B%202282.688470>] ixgbevf 0000:00:00.0: setting
> latency timer to 64
> [ 2282.690187 <tel:%5B%202282.690187>] ixgbevf 0000:00:00.0: PF still
> in reset state, assigning new address
>
> while PF on eth2 is  there and active, since i can ping other machine.
>
> Now, when I try to bring up the VF interface on domU, 
>  i get the following error
>
>  2476.295582] Unable to start - perhaps the PF Driver isn't up yet
> SIOCSIFFLAGS: Network is down
> [ 2476.296917] Unable to start - perhaps the PF Driver isn't up yet
> SIOCSIFFLAGS: Network is down
>
> and on dmesg on domU, 
> [ 2476.295582] Unable to start - perhaps the PF Driver isn't up yet
> [ 2476.296917] Unable to start - perhaps the PF Driver isn't up yet
>
>
> Any thoughts on what could be wrong? I have been struggling with this
> for quite some time
> and would really appreciate your thoughts on it.
>
> Thanks, 
> Ashok
>
>
>
>
>
>

-- 
Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
T: +44 (0)1223 225 900, http://www.citrix.com


--------------070502040207030606070503
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">
    <br>
    <div class="moz-cite-prefix">On 10/09/12 11:24, Ashok Anand wrote:<br>
    </div>
    <blockquote
cite="mid:CALQsBOXFVM+cdhmke5JDJmns2XUpHjyDOVN6R5qrrY9nTOR3SQ@mail.gmail.com"
      type="cite">
      <div class="gmail_quote">Hi,&nbsp;
        <div><br>
        </div>
        <div>I am trying to use SRIOV, usnig xen 4.0 on debian.&nbsp;</div>
        <div><br>
        </div>
        <div>On my dom0, xm pci-list-assignable-devices show that</div>
        <div>
          <div>0000:0f:10.0</div>
          <div>0000:0f:10.2</div>
          <div>0000:0f:10.4</div>
          <div>0000:0f:10.6</div>
          <div>0000:0f:11.2</div>
          <div>0000:0f:11.4</div>
          <div>0000:0f:11.6</div>
        </div>
        <div><br>
        </div>
        <div>these virtual interfaces correspond to eth2, <br>
        </div>
      </div>
    </blockquote>
    <br>
    Are you sure?&nbsp; 0f:10.0 is probably the physical function which you
    must keep in dom0.<br>
    <br>
    ~Andrew<br>
    <br>
    <blockquote
cite="mid:CALQsBOXFVM+cdhmke5JDJmns2XUpHjyDOVN6R5qrrY9nTOR3SQ@mail.gmail.com"
      type="cite">
      <div class="gmail_quote">
        <div><br>
        </div>
        <div>i attach 0f:10.0 to a domU ubuntu machine,&nbsp;xm pci-attach
          ubuntu 0f:10.0</div>
        <div><br>
        </div>
        <div>on my dom0 machine, i can ping other machine using eth2,
          (implying PF on eth2 is active)</div>
        <div><br>
        </div>
        <div>on my domU machine, when i attach the virtual function, i
          get the following messages</div>
        <div><br>
        </div>
        <div>
          <div><a moz-do-not-send="true" href="tel:%5B%202282.688356"
              value="+12282688356" target="_blank">[ 2282.688356</a>]
            ixgbevf 0000:00:00.0: Xen PCI mapped GSI0 to IRQ28</div>
          <div><a moz-do-not-send="true" href="tel:%5B%202282.688470"
              value="+12282688470" target="_blank">[ 2282.688470</a>]
            ixgbevf 0000:00:00.0: setting latency timer to 64</div>
          <div><a moz-do-not-send="true" href="tel:%5B%202282.690187"
              value="+12282690187" target="_blank">[ 2282.690187</a>]
            ixgbevf 0000:00:00.0: PF still in reset state, assigning new
            address</div>
        </div>
        <div><br>
        </div>
        <div>while PF on eth2 is &nbsp;there and active, since i can ping
          other machine.</div>
        <div><br>
        </div>
        <div>Now, when I try to bring up the VF interface on domU,&nbsp;</div>
        <div>&nbsp;i get the following error</div>
        <div>
          <br>
        </div>
        <div>
          <div>&nbsp;2476.295582] Unable to start - perhaps the PF Driver
            isn't up yet</div>
          <div>SIOCSIFFLAGS: Network is down</div>
          <div>[ 2476.296917] Unable to start - perhaps the PF Driver
            isn't up yet</div>
          <div>
            SIOCSIFFLAGS: Network is down</div>
        </div>
        <div><br>
        </div>
        <div>and on dmesg on domU,&nbsp;</div>
        <div>
          <div>[ 2476.295582] Unable to start - perhaps the PF Driver
            isn't up yet</div>
          <div>[ 2476.296917] Unable to start - perhaps the PF Driver
            isn't up yet</div>
        </div>
        <div><br>
        </div>
        <div><br>
        </div>
        <div>Any thoughts on what could be wrong? I have been struggling
          with this for quite some time</div>
        <div>and would really appreciate your thoughts on it.</div>
        <div><br>
        </div>
        <div>Thanks,&nbsp;</div>
        <span class="HOEnZb"><font color="#888888">
            <div>Ashok</div>
            <div><br>
            </div>
            <div><br>
            </div>
            <div><br>
            </div>
            <div><br>
            </div>
            <div><br>
            </div>
          </font></span></div>
      <br>
    </blockquote>
    <br>
    <pre class="moz-signature" cols="72">-- 
Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
T: +44 (0)1223 225 900, <a class="moz-txt-link-freetext" href="http://www.citrix.com">http://www.citrix.com</a></pre>
  </body>
</html>

--------------070502040207030606070503--


--===============6736997857128962086==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============6736997857128962086==--


From xen-devel-bounces@lists.xen.org Mon Sep 10 10:26:52 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Sep 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 1TB1CR-0000lP-W6; Mon, 10 Sep 2012 10:26:39 +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 1TB1CR-0000lH-3M
	for xen-devel@lists.xen.org; Mon, 10 Sep 2012 10:26:39 +0000
Received: from [85.158.143.99:30441] by server-3.bemta-4.messagelabs.com id
	E8/40-08232-E50CD405; Mon, 10 Sep 2012 10:26:38 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1347272794!24208796!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzAwNzQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8700 invoked from network); 10 Sep 2012 10:26:35 -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;
	10 Sep 2012 10:26:35 -0000
X-IronPort-AV: E=Sophos;i="4.80,396,1344211200"; d="scan'208,217";a="37295010"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Sep 2012 10:26:34 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Mon, 10 Sep 2012 06:26:33 -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 1TB1CL-0006Oe-77	for
	xen-devel@lists.xen.org; Mon, 10 Sep 2012 11:26:33 +0100
Message-ID: <504DC059.4070003@citrix.com>
Date: Mon, 10 Sep 2012 11:26:33 +0100
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:14.0) Gecko/20120714 Thunderbird/14.0
MIME-Version: 1.0
To: xen-devel@lists.xen.org
References: <CALQsBOWDE_KqpntG8WJo86omLP3+rhQ0LDMW5vB752ubpF1FAA@mail.gmail.com>
	<CALQsBOXFVM+cdhmke5JDJmns2XUpHjyDOVN6R5qrrY9nTOR3SQ@mail.gmail.com>
In-Reply-To: <CALQsBOXFVM+cdhmke5JDJmns2XUpHjyDOVN6R5qrrY9nTOR3SQ@mail.gmail.com>
X-Enigmail-Version: 1.4.4
Subject: Re: [Xen-devel] issue using SRIOV "Unable to start - perhaps the PF
 driver is not up yet", while PF driver is actually up
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============6736997857128962086=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============6736997857128962086==
Content-Type: multipart/alternative;
	boundary="------------070502040207030606070503"

--------------070502040207030606070503
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit


On 10/09/12 11:24, Ashok Anand wrote:
> Hi, 
>
> I am trying to use SRIOV, usnig xen 4.0 on debian. 
>
> On my dom0, xm pci-list-assignable-devices show that
> 0000:0f:10.0
> 0000:0f:10.2
> 0000:0f:10.4
> 0000:0f:10.6
> 0000:0f:11.2
> 0000:0f:11.4
> 0000:0f:11.6
>
> these virtual interfaces correspond to eth2,

Are you sure?  0f:10.0 is probably the physical function which you must
keep in dom0.

~Andrew

>
> i attach 0f:10.0 to a domU ubuntu machine, xm pci-attach ubuntu 0f:10.0
>
> on my dom0 machine, i can ping other machine using eth2, (implying PF
> on eth2 is active)
>
> on my domU machine, when i attach the virtual function, i get the
> following messages
>
> [ 2282.688356 <tel:%5B%202282.688356>] ixgbevf 0000:00:00.0: Xen PCI
> mapped GSI0 to IRQ28
> [ 2282.688470 <tel:%5B%202282.688470>] ixgbevf 0000:00:00.0: setting
> latency timer to 64
> [ 2282.690187 <tel:%5B%202282.690187>] ixgbevf 0000:00:00.0: PF still
> in reset state, assigning new address
>
> while PF on eth2 is  there and active, since i can ping other machine.
>
> Now, when I try to bring up the VF interface on domU, 
>  i get the following error
>
>  2476.295582] Unable to start - perhaps the PF Driver isn't up yet
> SIOCSIFFLAGS: Network is down
> [ 2476.296917] Unable to start - perhaps the PF Driver isn't up yet
> SIOCSIFFLAGS: Network is down
>
> and on dmesg on domU, 
> [ 2476.295582] Unable to start - perhaps the PF Driver isn't up yet
> [ 2476.296917] Unable to start - perhaps the PF Driver isn't up yet
>
>
> Any thoughts on what could be wrong? I have been struggling with this
> for quite some time
> and would really appreciate your thoughts on it.
>
> Thanks, 
> Ashok
>
>
>
>
>
>

-- 
Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
T: +44 (0)1223 225 900, http://www.citrix.com


--------------070502040207030606070503
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">
    <br>
    <div class="moz-cite-prefix">On 10/09/12 11:24, Ashok Anand wrote:<br>
    </div>
    <blockquote
cite="mid:CALQsBOXFVM+cdhmke5JDJmns2XUpHjyDOVN6R5qrrY9nTOR3SQ@mail.gmail.com"
      type="cite">
      <div class="gmail_quote">Hi,&nbsp;
        <div><br>
        </div>
        <div>I am trying to use SRIOV, usnig xen 4.0 on debian.&nbsp;</div>
        <div><br>
        </div>
        <div>On my dom0, xm pci-list-assignable-devices show that</div>
        <div>
          <div>0000:0f:10.0</div>
          <div>0000:0f:10.2</div>
          <div>0000:0f:10.4</div>
          <div>0000:0f:10.6</div>
          <div>0000:0f:11.2</div>
          <div>0000:0f:11.4</div>
          <div>0000:0f:11.6</div>
        </div>
        <div><br>
        </div>
        <div>these virtual interfaces correspond to eth2, <br>
        </div>
      </div>
    </blockquote>
    <br>
    Are you sure?&nbsp; 0f:10.0 is probably the physical function which you
    must keep in dom0.<br>
    <br>
    ~Andrew<br>
    <br>
    <blockquote
cite="mid:CALQsBOXFVM+cdhmke5JDJmns2XUpHjyDOVN6R5qrrY9nTOR3SQ@mail.gmail.com"
      type="cite">
      <div class="gmail_quote">
        <div><br>
        </div>
        <div>i attach 0f:10.0 to a domU ubuntu machine,&nbsp;xm pci-attach
          ubuntu 0f:10.0</div>
        <div><br>
        </div>
        <div>on my dom0 machine, i can ping other machine using eth2,
          (implying PF on eth2 is active)</div>
        <div><br>
        </div>
        <div>on my domU machine, when i attach the virtual function, i
          get the following messages</div>
        <div><br>
        </div>
        <div>
          <div><a moz-do-not-send="true" href="tel:%5B%202282.688356"
              value="+12282688356" target="_blank">[ 2282.688356</a>]
            ixgbevf 0000:00:00.0: Xen PCI mapped GSI0 to IRQ28</div>
          <div><a moz-do-not-send="true" href="tel:%5B%202282.688470"
              value="+12282688470" target="_blank">[ 2282.688470</a>]
            ixgbevf 0000:00:00.0: setting latency timer to 64</div>
          <div><a moz-do-not-send="true" href="tel:%5B%202282.690187"
              value="+12282690187" target="_blank">[ 2282.690187</a>]
            ixgbevf 0000:00:00.0: PF still in reset state, assigning new
            address</div>
        </div>
        <div><br>
        </div>
        <div>while PF on eth2 is &nbsp;there and active, since i can ping
          other machine.</div>
        <div><br>
        </div>
        <div>Now, when I try to bring up the VF interface on domU,&nbsp;</div>
        <div>&nbsp;i get the following error</div>
        <div>
          <br>
        </div>
        <div>
          <div>&nbsp;2476.295582] Unable to start - perhaps the PF Driver
            isn't up yet</div>
          <div>SIOCSIFFLAGS: Network is down</div>
          <div>[ 2476.296917] Unable to start - perhaps the PF Driver
            isn't up yet</div>
          <div>
            SIOCSIFFLAGS: Network is down</div>
        </div>
        <div><br>
        </div>
        <div>and on dmesg on domU,&nbsp;</div>
        <div>
          <div>[ 2476.295582] Unable to start - perhaps the PF Driver
            isn't up yet</div>
          <div>[ 2476.296917] Unable to start - perhaps the PF Driver
            isn't up yet</div>
        </div>
        <div><br>
        </div>
        <div><br>
        </div>
        <div>Any thoughts on what could be wrong? I have been struggling
          with this for quite some time</div>
        <div>and would really appreciate your thoughts on it.</div>
        <div><br>
        </div>
        <div>Thanks,&nbsp;</div>
        <span class="HOEnZb"><font color="#888888">
            <div>Ashok</div>
            <div><br>
            </div>
            <div><br>
            </div>
            <div><br>
            </div>
            <div><br>
            </div>
            <div><br>
            </div>
          </font></span></div>
      <br>
    </blockquote>
    <br>
    <pre class="moz-signature" cols="72">-- 
Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
T: +44 (0)1223 225 900, <a class="moz-txt-link-freetext" href="http://www.citrix.com">http://www.citrix.com</a></pre>
  </body>
</html>

--------------070502040207030606070503--


--===============6736997857128962086==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============6736997857128962086==--


From xen-devel-bounces@lists.xen.org Mon Sep 10 10:27:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Sep 2012 10: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 1TB1Cn-0000nh-KW; Mon, 10 Sep 2012 10:27:01 +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 1TB1Cm-0000nQ-BS
	for xen-devel@lists.xen.org; Mon, 10 Sep 2012 10:27:00 +0000
Received: from [85.158.143.99:39408] by server-3.bemta-4.messagelabs.com id
	C9/F0-08232-370CD405; Mon, 10 Sep 2012 10:26:59 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-11.tower-216.messagelabs.com!1347272818!21960109!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA1MDk2MzM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7130 invoked from network); 10 Sep 2012 10:26:59 -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; 10 Sep 2012 10:26:59 -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 30BA71C43;
	Mon, 10 Sep 2012 13:26:58 +0300 (EEST)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id E9F0D2005D; Mon, 10 Sep 2012 13:26:57 +0300 (EEST)
Date: Mon, 10 Sep 2012 13:26:57 +0300
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20120910102657.GF8912@reaktio.net>
References: <504DD183020000780009A1B6@nat28.tlf.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <504DD183020000780009A1B6@nat28.tlf.novell.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] docs: document "ucode=" hypervisor command
 line option
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Sep 10, 2012 at 10:39:47AM +0100, Jan Beulich wrote:
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> 
> --- a/docs/misc/xen-command-line.markdown
> +++ b/docs/misc/xen-command-line.markdown
> @@ -785,6 +785,19 @@ Specify the per-cpu trace buffer size in
>  > `= unstable | skewed`
>  
>  ### ucode
> +> `= <integer>`
> +
> +Specify the CPU microcode update blob module index. When positive, this
> +specifies the n-th module (in the GrUB entry, zero based) to be used
> +for updating CPU micrcode. When negative, counting starts at the end of
                        ^
typo here, should be "microcode", obviously.

-- Pasi

> +the modules in the GrUB entry (so with the blob commonly being last,
> +one could specify `ucode=-1`). Note that the value of zero is not valid
> +here (entry zero, i.e. the first module, is always the Dom0 kernel
> +image). Note further that use of this option has an unspecified effect
> +when used with xen.efi (there the concept of modules doesn't exist, and
> +the blob gets specified via the `ucode=<filename>` config file/section
> +entry; see [EFI configuration file description](efi.html)).
> +
>  ### unrestricted\_guest
>  > `= <boolean>`
>  
> 
> 
> 

> docs: document "ucode=" hypervisor command line option
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> 
> --- a/docs/misc/xen-command-line.markdown
> +++ b/docs/misc/xen-command-line.markdown
> @@ -785,6 +785,19 @@ Specify the per-cpu trace buffer size in
>  > `= unstable | skewed`
>  
>  ### ucode
> +> `= <integer>`
> +
> +Specify the CPU microcode update blob module index. When positive, this
> +specifies the n-th module (in the GrUB entry, zero based) to be used
> +for updating CPU micrcode. When negative, counting starts at the end of
> +the modules in the GrUB entry (so with the blob commonly being last,
> +one could specify `ucode=-1`). Note that the value of zero is not valid
> +here (entry zero, i.e. the first module, is always the Dom0 kernel
> +image). Note further that use of this option has an unspecified effect
> +when used with xen.efi (there the concept of modules doesn't exist, and
> +the blob gets specified via the `ucode=<filename>` config file/section
> +entry; see [EFI configuration file description](efi.html)).
> +
>  ### unrestricted\_guest
>  > `= <boolean>`
>  

> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Sep 10 10:27:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Sep 2012 10: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 1TB1Cn-0000nh-KW; Mon, 10 Sep 2012 10:27:01 +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 1TB1Cm-0000nQ-BS
	for xen-devel@lists.xen.org; Mon, 10 Sep 2012 10:27:00 +0000
Received: from [85.158.143.99:39408] by server-3.bemta-4.messagelabs.com id
	C9/F0-08232-370CD405; Mon, 10 Sep 2012 10:26:59 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-11.tower-216.messagelabs.com!1347272818!21960109!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA1MDk2MzM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7130 invoked from network); 10 Sep 2012 10:26:59 -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; 10 Sep 2012 10:26:59 -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 30BA71C43;
	Mon, 10 Sep 2012 13:26:58 +0300 (EEST)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id E9F0D2005D; Mon, 10 Sep 2012 13:26:57 +0300 (EEST)
Date: Mon, 10 Sep 2012 13:26:57 +0300
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20120910102657.GF8912@reaktio.net>
References: <504DD183020000780009A1B6@nat28.tlf.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <504DD183020000780009A1B6@nat28.tlf.novell.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] docs: document "ucode=" hypervisor command
 line option
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Sep 10, 2012 at 10:39:47AM +0100, Jan Beulich wrote:
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> 
> --- a/docs/misc/xen-command-line.markdown
> +++ b/docs/misc/xen-command-line.markdown
> @@ -785,6 +785,19 @@ Specify the per-cpu trace buffer size in
>  > `= unstable | skewed`
>  
>  ### ucode
> +> `= <integer>`
> +
> +Specify the CPU microcode update blob module index. When positive, this
> +specifies the n-th module (in the GrUB entry, zero based) to be used
> +for updating CPU micrcode. When negative, counting starts at the end of
                        ^
typo here, should be "microcode", obviously.

-- Pasi

> +the modules in the GrUB entry (so with the blob commonly being last,
> +one could specify `ucode=-1`). Note that the value of zero is not valid
> +here (entry zero, i.e. the first module, is always the Dom0 kernel
> +image). Note further that use of this option has an unspecified effect
> +when used with xen.efi (there the concept of modules doesn't exist, and
> +the blob gets specified via the `ucode=<filename>` config file/section
> +entry; see [EFI configuration file description](efi.html)).
> +
>  ### unrestricted\_guest
>  > `= <boolean>`
>  
> 
> 
> 

> docs: document "ucode=" hypervisor command line option
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> 
> --- a/docs/misc/xen-command-line.markdown
> +++ b/docs/misc/xen-command-line.markdown
> @@ -785,6 +785,19 @@ Specify the per-cpu trace buffer size in
>  > `= unstable | skewed`
>  
>  ### ucode
> +> `= <integer>`
> +
> +Specify the CPU microcode update blob module index. When positive, this
> +specifies the n-th module (in the GrUB entry, zero based) to be used
> +for updating CPU micrcode. When negative, counting starts at the end of
> +the modules in the GrUB entry (so with the blob commonly being last,
> +one could specify `ucode=-1`). Note that the value of zero is not valid
> +here (entry zero, i.e. the first module, is always the Dom0 kernel
> +image). Note further that use of this option has an unspecified effect
> +when used with xen.efi (there the concept of modules doesn't exist, and
> +the blob gets specified via the `ucode=<filename>` config file/section
> +entry; see [EFI configuration file description](efi.html)).
> +
>  ### unrestricted\_guest
>  > `= <boolean>`
>  

> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Sep 10 10:28:19 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Sep 2012 10: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 1TB1Dr-0000yC-52; Mon, 10 Sep 2012 10:28:07 +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 1TB1Dq-0000y1-2V
	for xen-devel@lists.xen.org; Mon, 10 Sep 2012 10:28:06 +0000
Received: from [85.158.143.35:18221] by server-3.bemta-4.messagelabs.com id
	AE/13-08232-5B0CD405; Mon, 10 Sep 2012 10:28:05 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-6.tower-21.messagelabs.com!1347272857!17488990!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA1MDk2MzM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1709 invoked from network); 10 Sep 2012 10:27:38 -0000
Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25)
	by server-6.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 10 Sep 2012 10:27:38 -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 AF0152FB7;
	Mon, 10 Sep 2012 13:27:37 +0300 (EEST)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id 82D802005D; Mon, 10 Sep 2012 13:27:37 +0300 (EEST)
Date: Mon, 10 Sep 2012 13:27:37 +0300
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: Ashok Anand <ashok.anand@gmail.com>
Message-ID: <20120910102737.GG8912@reaktio.net>
References: <CALQsBOWDE_KqpntG8WJo86omLP3+rhQ0LDMW5vB752ubpF1FAA@mail.gmail.com>
	<CALQsBOXFVM+cdhmke5JDJmns2XUpHjyDOVN6R5qrrY9nTOR3SQ@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CALQsBOXFVM+cdhmke5JDJmns2XUpHjyDOVN6R5qrrY9nTOR3SQ@mail.gmail.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] issue using SRIOV "Unable to start - perhaps the PF
 driver is not up yet", while PF driver is actually up
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Sep 10, 2012 at 03:54:34PM +0530, Ashok Anand wrote:
>    Hi,
>    I am trying to use SRIOV, usnig xen 4.0 on debian.
>    On my dom0, xm pci-list-assignable-devices show that
>    0000:0f:10.0
>    0000:0f:10.2
>    0000:0f:10.4
>    0000:0f:10.6
>    0000:0f:11.2
>    0000:0f:11.4
>    0000:0f:11.6
>    these virtual interfaces correspond to eth2,
>    i attach 0f:10.0 to a domU ubuntu machine, xm pci-attach ubuntu 0f:10.0
>    on my dom0 machine, i can ping other machine using eth2, (implying PF on
>    eth2 is active)
>    on my domU machine, when i attach the virtual function, i get the
>    following messages
>    [1][ 2282.688356] ixgbevf 0000:00:00.0: Xen PCI mapped GSI0 to IRQ28
>    [2][ 2282.688470] ixgbevf 0000:00:00.0: setting latency timer to 64
>    [3][ 2282.690187] ixgbevf 0000:00:00.0: PF still in reset state, assigning
>    new address
>    while PF on eth2 is  there and active, since i can ping other machine.
>    Now, when I try to bring up the VF interface on domU,
>     i get the following error
>     2476.295582] Unable to start - perhaps the PF Driver isn't up yet
>    SIOCSIFFLAGS: Network is down
>    [ 2476.296917] Unable to start - perhaps the PF Driver isn't up yet
>    SIOCSIFFLAGS: Network is down
>    and on dmesg on domU,
>    [ 2476.295582] Unable to start - perhaps the PF Driver isn't up yet
>    [ 2476.296917] Unable to start - perhaps the PF Driver isn't up yet
>    Any thoughts on what could be wrong? I have been struggling with this for
>    quite some time
>    and would really appreciate your thoughts on it.
>

Did you do "ifconfig ethX up" in dom0? 

-- Pasi


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 10 10:28:19 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Sep 2012 10: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 1TB1Dr-0000yC-52; Mon, 10 Sep 2012 10:28:07 +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 1TB1Dq-0000y1-2V
	for xen-devel@lists.xen.org; Mon, 10 Sep 2012 10:28:06 +0000
Received: from [85.158.143.35:18221] by server-3.bemta-4.messagelabs.com id
	AE/13-08232-5B0CD405; Mon, 10 Sep 2012 10:28:05 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-6.tower-21.messagelabs.com!1347272857!17488990!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA1MDk2MzM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1709 invoked from network); 10 Sep 2012 10:27:38 -0000
Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25)
	by server-6.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 10 Sep 2012 10:27:38 -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 AF0152FB7;
	Mon, 10 Sep 2012 13:27:37 +0300 (EEST)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id 82D802005D; Mon, 10 Sep 2012 13:27:37 +0300 (EEST)
Date: Mon, 10 Sep 2012 13:27:37 +0300
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: Ashok Anand <ashok.anand@gmail.com>
Message-ID: <20120910102737.GG8912@reaktio.net>
References: <CALQsBOWDE_KqpntG8WJo86omLP3+rhQ0LDMW5vB752ubpF1FAA@mail.gmail.com>
	<CALQsBOXFVM+cdhmke5JDJmns2XUpHjyDOVN6R5qrrY9nTOR3SQ@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CALQsBOXFVM+cdhmke5JDJmns2XUpHjyDOVN6R5qrrY9nTOR3SQ@mail.gmail.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] issue using SRIOV "Unable to start - perhaps the PF
 driver is not up yet", while PF driver is actually up
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Sep 10, 2012 at 03:54:34PM +0530, Ashok Anand wrote:
>    Hi,
>    I am trying to use SRIOV, usnig xen 4.0 on debian.
>    On my dom0, xm pci-list-assignable-devices show that
>    0000:0f:10.0
>    0000:0f:10.2
>    0000:0f:10.4
>    0000:0f:10.6
>    0000:0f:11.2
>    0000:0f:11.4
>    0000:0f:11.6
>    these virtual interfaces correspond to eth2,
>    i attach 0f:10.0 to a domU ubuntu machine, xm pci-attach ubuntu 0f:10.0
>    on my dom0 machine, i can ping other machine using eth2, (implying PF on
>    eth2 is active)
>    on my domU machine, when i attach the virtual function, i get the
>    following messages
>    [1][ 2282.688356] ixgbevf 0000:00:00.0: Xen PCI mapped GSI0 to IRQ28
>    [2][ 2282.688470] ixgbevf 0000:00:00.0: setting latency timer to 64
>    [3][ 2282.690187] ixgbevf 0000:00:00.0: PF still in reset state, assigning
>    new address
>    while PF on eth2 is  there and active, since i can ping other machine.
>    Now, when I try to bring up the VF interface on domU,
>     i get the following error
>     2476.295582] Unable to start - perhaps the PF Driver isn't up yet
>    SIOCSIFFLAGS: Network is down
>    [ 2476.296917] Unable to start - perhaps the PF Driver isn't up yet
>    SIOCSIFFLAGS: Network is down
>    and on dmesg on domU,
>    [ 2476.295582] Unable to start - perhaps the PF Driver isn't up yet
>    [ 2476.296917] Unable to start - perhaps the PF Driver isn't up yet
>    Any thoughts on what could be wrong? I have been struggling with this for
>    quite some time
>    and would really appreciate your thoughts on it.
>

Did you do "ifconfig ethX up" in dom0? 

-- Pasi


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 10 10:34:18 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Sep 2012 10:34: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 1TB1Jd-0001N9-Uf; Mon, 10 Sep 2012 10:34:05 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ashok.anand@gmail.com>) id 1TB1Jc-0001N4-No
	for xen-devel@lists.xen.org; Mon, 10 Sep 2012 10:34:05 +0000
Received: from [85.158.138.51:25512] by server-2.bemta-3.messagelabs.com id
	32/8B-04862-C12CD405; Mon, 10 Sep 2012 10:34:04 +0000
X-Env-Sender: ashok.anand@gmail.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1347273241!20771034!1
X-Originating-IP: [209.85.214.173]
X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_50_60,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24766 invoked from network); 10 Sep 2012 10:34:03 -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;
	10 Sep 2012 10:34:03 -0000
Received: by obbta14 with SMTP id ta14so3543045obb.32
	for <xen-devel@lists.xen.org>; Mon, 10 Sep 2012 03:34:01 -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=EjJmUSHVRZpZYHZocPK2dmEYyK8VMQ3bl6dpAQ4WB1Y=;
	b=psuPuTW7uvl92hkD33/a0c+FBLHfpFbKxxU49/WcWhh+3zfGB9xZ5bsOn/qMlsfDH8
	n9zkiKQbiTfEDGqsd6rIMpVI/8pX5VM10GBEPYlbBGA2Qxuzc3ypqPpr8UR4EkBcjmRU
	U9gIBHEZnk8FPaE27HzR4SuSIsFhtFqbFnH7IoCvwg9ScNF64ZEST8Bk+vJ74ezAOU7p
	2Brj6enn9z6vc7YFCWL/EOxnG0CnqKIS12pXf6C3typtNZB4GFlfHJ0pHXQo7NZaRO2U
	CU2abetdlhwtL1ycPzLz5avxkI1qOAT33AxNgR/sIm/HsjTpJeq8stz1xtAYqmcEf1ZJ
	njNg==
MIME-Version: 1.0
Received: by 10.60.12.167 with SMTP id z7mr13745151oeb.121.1347273241373; Mon,
	10 Sep 2012 03:34:01 -0700 (PDT)
Received: by 10.182.32.102 with HTTP; Mon, 10 Sep 2012 03:34:01 -0700 (PDT)
In-Reply-To: <504DC059.4070003@citrix.com>
References: <CALQsBOWDE_KqpntG8WJo86omLP3+rhQ0LDMW5vB752ubpF1FAA@mail.gmail.com>
	<CALQsBOXFVM+cdhmke5JDJmns2XUpHjyDOVN6R5qrrY9nTOR3SQ@mail.gmail.com>
	<504DC059.4070003@citrix.com>
Date: Mon, 10 Sep 2012 16:04:01 +0530
Message-ID: <CALQsBOV0EsUY+eYWqtL-FVuTOWOk_MLPnC2CYYPhNU9t=sxt9g@mail.gmail.com>
From: Ashok Anand <ashok.anand@gmail.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] issue using SRIOV "Unable to start - perhaps the PF
 driver is not up yet", while PF driver is actually up
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============3633803858675574930=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============3633803858675574930==
Content-Type: multipart/alternative; boundary=e89a8fb1efa4f7ac5604c9567e47

--e89a8fb1efa4f7ac5604c9567e47
Content-Type: text/plain; charset=ISO-8859-1

Are you sure?  0f:10.0 is probably the physical function which you must
> keep in dom0.
>
> ~Andrew
>

I find from xm pci-list-assignable-devices  that 0f:10.0 is available - it
is also hidden from dom0 (using pciback.hide in kernel arguments)

if that is not the case, which physical function i can assign to domU?
i tried with 0f:11.6, and others too, but i got similar messages.


>
>
>  i attach 0f:10.0 to a domU ubuntu machine, xm pci-attach ubuntu 0f:10.0
>
>  on my dom0 machine, i can ping other machine using eth2, (implying PF on
> eth2 is active)
>
>  on my domU machine, when i attach the virtual function, i get the
> following messages
>
>  [ 2282.688356] ixgbevf 0000:00:00.0: Xen PCI mapped GSI0 to IRQ28
> [ 2282.688470] ixgbevf 0000:00:00.0: setting latency timer to 64
> [ 2282.690187] ixgbevf 0000:00:00.0: PF still in reset state, assigning
> new address
>
>  while PF on eth2 is  there and active, since i can ping other machine.
>
>  Now, when I try to bring up the VF interface on domU,
>  i get the following error
>
>   2476.295582] Unable to start - perhaps the PF Driver isn't up yet
> SIOCSIFFLAGS: Network is down
> [ 2476.296917] Unable to start - perhaps the PF Driver isn't up yet
>  SIOCSIFFLAGS: Network is down
>
>  and on dmesg on domU,
>  [ 2476.295582] Unable to start - perhaps the PF Driver isn't up yet
> [ 2476.296917] Unable to start - perhaps the PF Driver isn't up yet
>
>
>  Any thoughts on what could be wrong? I have been struggling with this
> for quite some time
> and would really appreciate your thoughts on it.
>
>  Thanks,
>  Ashok
>
>
>
>
>
>
>
> --
> 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
>
>

--e89a8fb1efa4f7ac5604c9567e47
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br><br><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgc=
olor=3D"#FFFFFF" text=3D"#000000">
    Are you sure?=A0 0f:10.0 is probably the physical function which you
    must keep in dom0.<br>
    <br>
    ~Andrew</div></blockquote><div><br></div><div>I find from xm pci-list-a=
ssignable-devices =A0that 0f:10.0 is available - it is also hidden from dom=
0 (using pciback.hide in kernel arguments)</div><div><br></div><div>if that=
 is not the case, which physical function i can assign to domU?</div>
<div>i tried with 0f:11.6, and others too, but i got similar messages.</div=
><div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8e=
x;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor=3D"#FFFFFF" tex=
t=3D"#000000">
<div class=3D"im"><br>
    <br>
    <blockquote type=3D"cite">
      <div class=3D"gmail_quote">
        <div><br>
        </div>
        <div>i attach 0f:10.0 to a domU ubuntu machine,=A0xm pci-attach
          ubuntu 0f:10.0</div>
        <div><br>
        </div>
        <div>on my dom0 machine, i can ping other machine using eth2,
          (implying PF on eth2 is active)</div>
        <div><br>
        </div>
        <div>on my domU machine, when i attach the virtual function, i
          get the following messages</div>
        <div><br>
        </div>
        <div>
          <div><a href=3D"tel:%5B%202282.688356" value=3D"+12282688356" tar=
get=3D"_blank">[ 2282.688356</a>]
            ixgbevf 0000:00:00.0: Xen PCI mapped GSI0 to IRQ28</div>
          <div><a href=3D"tel:%5B%202282.688470" value=3D"+12282688470" tar=
get=3D"_blank">[ 2282.688470</a>]
            ixgbevf 0000:00:00.0: setting latency timer to 64</div>
          <div><a href=3D"tel:%5B%202282.690187" value=3D"+12282690187" tar=
get=3D"_blank">[ 2282.690187</a>]
            ixgbevf 0000:00:00.0: PF still in reset state, assigning new
            address</div>
        </div>
        <div><br>
        </div>
        <div>while PF on eth2 is =A0there and active, since i can ping
          other machine.</div>
        <div><br>
        </div>
        <div>Now, when I try to bring up the VF interface on domU,=A0</div>
        <div>=A0i get the following error</div>
        <div>
          <br>
        </div>
        <div>
          <div>=A02476.295582] Unable to start - perhaps the PF Driver
            isn&#39;t up yet</div>
          <div>SIOCSIFFLAGS: Network is down</div>
          <div>[ 2476.296917] Unable to start - perhaps the PF Driver
            isn&#39;t up yet</div>
          <div>
            SIOCSIFFLAGS: Network is down</div>
        </div>
        <div><br>
        </div>
        <div>and on dmesg on domU,=A0</div>
        <div>
          <div>[ 2476.295582] Unable to start - perhaps the PF Driver
            isn&#39;t up yet</div>
          <div>[ 2476.296917] Unable to start - perhaps the PF Driver
            isn&#39;t up yet</div>
        </div>
        <div><br>
        </div>
        <div><br>
        </div>
        <div>Any thoughts on what could be wrong? I have been struggling
          with this for quite some time</div>
        <div>and would really appreciate your thoughts on it.</div>
        <div><br>
        </div>
        <div>Thanks,=A0</div>
        <span><font color=3D"#888888">
            <div>Ashok</div>
            <div><br>
            </div>
            <div><br>
            </div>
            <div><br>
            </div>
            <div><br>
            </div>
            <div><br>
            </div>
          </font></span></div>
      <br>
    </blockquote>
    <br>
    </div><span class=3D"HOEnZb"><font color=3D"#888888"><pre cols=3D"72">-=
-=20
Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
T: <a href=3D"tel:%2B44%20%280%291223%20225%20900" value=3D"+441223225900" =
target=3D"_blank">+44 (0)1223 225 900</a>, <a href=3D"http://www.citrix.com=
" target=3D"_blank">http://www.citrix.com</a></pre>
  </font></span></div>

<br>_______________________________________________<br>
Xen-devel mailing list<br>
<a href=3D"mailto:Xen-devel@lists.xen.org">Xen-devel@lists.xen.org</a><br>
<a href=3D"http://lists.xen.org/xen-devel" target=3D"_blank">http://lists.x=
en.org/xen-devel</a><br>
<br></blockquote></div><br>

--e89a8fb1efa4f7ac5604c9567e47--


--===============3633803858675574930==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============3633803858675574930==--


From xen-devel-bounces@lists.xen.org Mon Sep 10 10:34:18 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Sep 2012 10:34: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 1TB1Jd-0001N9-Uf; Mon, 10 Sep 2012 10:34:05 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ashok.anand@gmail.com>) id 1TB1Jc-0001N4-No
	for xen-devel@lists.xen.org; Mon, 10 Sep 2012 10:34:05 +0000
Received: from [85.158.138.51:25512] by server-2.bemta-3.messagelabs.com id
	32/8B-04862-C12CD405; Mon, 10 Sep 2012 10:34:04 +0000
X-Env-Sender: ashok.anand@gmail.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1347273241!20771034!1
X-Originating-IP: [209.85.214.173]
X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_50_60,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24766 invoked from network); 10 Sep 2012 10:34:03 -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;
	10 Sep 2012 10:34:03 -0000
Received: by obbta14 with SMTP id ta14so3543045obb.32
	for <xen-devel@lists.xen.org>; Mon, 10 Sep 2012 03:34:01 -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=EjJmUSHVRZpZYHZocPK2dmEYyK8VMQ3bl6dpAQ4WB1Y=;
	b=psuPuTW7uvl92hkD33/a0c+FBLHfpFbKxxU49/WcWhh+3zfGB9xZ5bsOn/qMlsfDH8
	n9zkiKQbiTfEDGqsd6rIMpVI/8pX5VM10GBEPYlbBGA2Qxuzc3ypqPpr8UR4EkBcjmRU
	U9gIBHEZnk8FPaE27HzR4SuSIsFhtFqbFnH7IoCvwg9ScNF64ZEST8Bk+vJ74ezAOU7p
	2Brj6enn9z6vc7YFCWL/EOxnG0CnqKIS12pXf6C3typtNZB4GFlfHJ0pHXQo7NZaRO2U
	CU2abetdlhwtL1ycPzLz5avxkI1qOAT33AxNgR/sIm/HsjTpJeq8stz1xtAYqmcEf1ZJ
	njNg==
MIME-Version: 1.0
Received: by 10.60.12.167 with SMTP id z7mr13745151oeb.121.1347273241373; Mon,
	10 Sep 2012 03:34:01 -0700 (PDT)
Received: by 10.182.32.102 with HTTP; Mon, 10 Sep 2012 03:34:01 -0700 (PDT)
In-Reply-To: <504DC059.4070003@citrix.com>
References: <CALQsBOWDE_KqpntG8WJo86omLP3+rhQ0LDMW5vB752ubpF1FAA@mail.gmail.com>
	<CALQsBOXFVM+cdhmke5JDJmns2XUpHjyDOVN6R5qrrY9nTOR3SQ@mail.gmail.com>
	<504DC059.4070003@citrix.com>
Date: Mon, 10 Sep 2012 16:04:01 +0530
Message-ID: <CALQsBOV0EsUY+eYWqtL-FVuTOWOk_MLPnC2CYYPhNU9t=sxt9g@mail.gmail.com>
From: Ashok Anand <ashok.anand@gmail.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] issue using SRIOV "Unable to start - perhaps the PF
 driver is not up yet", while PF driver is actually up
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============3633803858675574930=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============3633803858675574930==
Content-Type: multipart/alternative; boundary=e89a8fb1efa4f7ac5604c9567e47

--e89a8fb1efa4f7ac5604c9567e47
Content-Type: text/plain; charset=ISO-8859-1

Are you sure?  0f:10.0 is probably the physical function which you must
> keep in dom0.
>
> ~Andrew
>

I find from xm pci-list-assignable-devices  that 0f:10.0 is available - it
is also hidden from dom0 (using pciback.hide in kernel arguments)

if that is not the case, which physical function i can assign to domU?
i tried with 0f:11.6, and others too, but i got similar messages.


>
>
>  i attach 0f:10.0 to a domU ubuntu machine, xm pci-attach ubuntu 0f:10.0
>
>  on my dom0 machine, i can ping other machine using eth2, (implying PF on
> eth2 is active)
>
>  on my domU machine, when i attach the virtual function, i get the
> following messages
>
>  [ 2282.688356] ixgbevf 0000:00:00.0: Xen PCI mapped GSI0 to IRQ28
> [ 2282.688470] ixgbevf 0000:00:00.0: setting latency timer to 64
> [ 2282.690187] ixgbevf 0000:00:00.0: PF still in reset state, assigning
> new address
>
>  while PF on eth2 is  there and active, since i can ping other machine.
>
>  Now, when I try to bring up the VF interface on domU,
>  i get the following error
>
>   2476.295582] Unable to start - perhaps the PF Driver isn't up yet
> SIOCSIFFLAGS: Network is down
> [ 2476.296917] Unable to start - perhaps the PF Driver isn't up yet
>  SIOCSIFFLAGS: Network is down
>
>  and on dmesg on domU,
>  [ 2476.295582] Unable to start - perhaps the PF Driver isn't up yet
> [ 2476.296917] Unable to start - perhaps the PF Driver isn't up yet
>
>
>  Any thoughts on what could be wrong? I have been struggling with this
> for quite some time
> and would really appreciate your thoughts on it.
>
>  Thanks,
>  Ashok
>
>
>
>
>
>
>
> --
> 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
>
>

--e89a8fb1efa4f7ac5604c9567e47
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br><br><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgc=
olor=3D"#FFFFFF" text=3D"#000000">
    Are you sure?=A0 0f:10.0 is probably the physical function which you
    must keep in dom0.<br>
    <br>
    ~Andrew</div></blockquote><div><br></div><div>I find from xm pci-list-a=
ssignable-devices =A0that 0f:10.0 is available - it is also hidden from dom=
0 (using pciback.hide in kernel arguments)</div><div><br></div><div>if that=
 is not the case, which physical function i can assign to domU?</div>
<div>i tried with 0f:11.6, and others too, but i got similar messages.</div=
><div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8e=
x;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor=3D"#FFFFFF" tex=
t=3D"#000000">
<div class=3D"im"><br>
    <br>
    <blockquote type=3D"cite">
      <div class=3D"gmail_quote">
        <div><br>
        </div>
        <div>i attach 0f:10.0 to a domU ubuntu machine,=A0xm pci-attach
          ubuntu 0f:10.0</div>
        <div><br>
        </div>
        <div>on my dom0 machine, i can ping other machine using eth2,
          (implying PF on eth2 is active)</div>
        <div><br>
        </div>
        <div>on my domU machine, when i attach the virtual function, i
          get the following messages</div>
        <div><br>
        </div>
        <div>
          <div><a href=3D"tel:%5B%202282.688356" value=3D"+12282688356" tar=
get=3D"_blank">[ 2282.688356</a>]
            ixgbevf 0000:00:00.0: Xen PCI mapped GSI0 to IRQ28</div>
          <div><a href=3D"tel:%5B%202282.688470" value=3D"+12282688470" tar=
get=3D"_blank">[ 2282.688470</a>]
            ixgbevf 0000:00:00.0: setting latency timer to 64</div>
          <div><a href=3D"tel:%5B%202282.690187" value=3D"+12282690187" tar=
get=3D"_blank">[ 2282.690187</a>]
            ixgbevf 0000:00:00.0: PF still in reset state, assigning new
            address</div>
        </div>
        <div><br>
        </div>
        <div>while PF on eth2 is =A0there and active, since i can ping
          other machine.</div>
        <div><br>
        </div>
        <div>Now, when I try to bring up the VF interface on domU,=A0</div>
        <div>=A0i get the following error</div>
        <div>
          <br>
        </div>
        <div>
          <div>=A02476.295582] Unable to start - perhaps the PF Driver
            isn&#39;t up yet</div>
          <div>SIOCSIFFLAGS: Network is down</div>
          <div>[ 2476.296917] Unable to start - perhaps the PF Driver
            isn&#39;t up yet</div>
          <div>
            SIOCSIFFLAGS: Network is down</div>
        </div>
        <div><br>
        </div>
        <div>and on dmesg on domU,=A0</div>
        <div>
          <div>[ 2476.295582] Unable to start - perhaps the PF Driver
            isn&#39;t up yet</div>
          <div>[ 2476.296917] Unable to start - perhaps the PF Driver
            isn&#39;t up yet</div>
        </div>
        <div><br>
        </div>
        <div><br>
        </div>
        <div>Any thoughts on what could be wrong? I have been struggling
          with this for quite some time</div>
        <div>and would really appreciate your thoughts on it.</div>
        <div><br>
        </div>
        <div>Thanks,=A0</div>
        <span><font color=3D"#888888">
            <div>Ashok</div>
            <div><br>
            </div>
            <div><br>
            </div>
            <div><br>
            </div>
            <div><br>
            </div>
            <div><br>
            </div>
          </font></span></div>
      <br>
    </blockquote>
    <br>
    </div><span class=3D"HOEnZb"><font color=3D"#888888"><pre cols=3D"72">-=
-=20
Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
T: <a href=3D"tel:%2B44%20%280%291223%20225%20900" value=3D"+441223225900" =
target=3D"_blank">+44 (0)1223 225 900</a>, <a href=3D"http://www.citrix.com=
" target=3D"_blank">http://www.citrix.com</a></pre>
  </font></span></div>

<br>_______________________________________________<br>
Xen-devel mailing list<br>
<a href=3D"mailto:Xen-devel@lists.xen.org">Xen-devel@lists.xen.org</a><br>
<a href=3D"http://lists.xen.org/xen-devel" target=3D"_blank">http://lists.x=
en.org/xen-devel</a><br>
<br></blockquote></div><br>

--e89a8fb1efa4f7ac5604c9567e47--


--===============3633803858675574930==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============3633803858675574930==--


From xen-devel-bounces@lists.xen.org Mon Sep 10 10:35:41 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Sep 2012 10:35:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TB1L2-0001Te-KX; Mon, 10 Sep 2012 10:35:32 +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 1TB1L0-0001TU-Cs
	for xen-devel@lists.xensource.com; Mon, 10 Sep 2012 10:35:30 +0000
Received: from [85.158.143.99:9345] by server-1.bemta-4.messagelabs.com id
	1E/16-12504-172CD405; Mon, 10 Sep 2012 10:35:29 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1347273326!24245569!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzAwNzQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18272 invoked from network); 10 Sep 2012 10:35:28 -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;
	10 Sep 2012 10:35:28 -0000
X-IronPort-AV: E=Sophos;i="4.80,396,1344211200"; d="scan'208";a="37295501"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Sep 2012 10:35:13 +0000
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.279.1; Mon, 10 Sep 2012
	06:35:13 -0400
Message-ID: <504DC25F.7000508@citrix.com>
Date: Mon, 10 Sep 2012 11:35: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 Iceowl/1.0b1 Icedove/3.0.11
MIME-Version: 1.0
To: Dan Carpenter <dan.carpenter@oracle.com>
References: <20120908095208.GA608@elgon.mountain>
In-Reply-To: <20120908095208.GA608@elgon.mountain>
Cc: Jeremy Fitzhardinge <jeremy@goop.org>, xen-devel@lists.xensource.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Andres Lagar-Cavilla <andreslc@gridcentric.ca>,
	kernel-janitors@vger.kernel.org, virtualization@lists.linux-foundation.org
Subject: Re: [Xen-devel] [patch 1/3] xen/privcmd: check for integer overflow
 in	ioctl
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/09/12 10:52, Dan Carpenter wrote:
> If m.num is too large then the "m.num * sizeof(*m.arr)" multiplication
> could overflow and the access_ok() check wouldn't test the right size.

m.num is range checked later on so it doesn't matter that the
access_ok() checks might be wrong.  A bit subtle, perhaps.

David

> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
> ---
> Only needed in linux-next.
> 
> diff --git a/drivers/xen/privcmd.c b/drivers/xen/privcmd.c
> index 215a3c0..fdff8f9 100644
> --- a/drivers/xen/privcmd.c
> +++ b/drivers/xen/privcmd.c
> @@ -325,6 +325,8 @@ static long privcmd_ioctl_mmap_batch(void __user *udata, int version)
>  			return -EFAULT;
>  		/* Returns per-frame error in m.arr. */
>  		m.err = NULL;
> +		if (m.num > SIZE_MAX / sizeof(*m.arr))
> +			return -EINVAL;
>  		if (!access_ok(VERIFY_WRITE, m.arr, m.num * sizeof(*m.arr)))
>  			return -EFAULT;
>  		break;
> @@ -332,6 +334,8 @@ static long privcmd_ioctl_mmap_batch(void __user *udata, int version)
>  		if (copy_from_user(&m, udata, sizeof(struct privcmd_mmapbatch_v2)))
>  			return -EFAULT;
>  		/* Returns per-frame error code in m.err. */
> +		if (m.num > SIZE_MAX / sizeof(*m.err))
> +			return -EINVAL;
>  		if (!access_ok(VERIFY_WRITE, m.err, m.num * (sizeof(*m.err))))
>  			return -EFAULT;
>  		break;
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Sep 10 10:35:41 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Sep 2012 10:35:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TB1L2-0001Te-KX; Mon, 10 Sep 2012 10:35:32 +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 1TB1L0-0001TU-Cs
	for xen-devel@lists.xensource.com; Mon, 10 Sep 2012 10:35:30 +0000
Received: from [85.158.143.99:9345] by server-1.bemta-4.messagelabs.com id
	1E/16-12504-172CD405; Mon, 10 Sep 2012 10:35:29 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1347273326!24245569!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzAwNzQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18272 invoked from network); 10 Sep 2012 10:35:28 -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;
	10 Sep 2012 10:35:28 -0000
X-IronPort-AV: E=Sophos;i="4.80,396,1344211200"; d="scan'208";a="37295501"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Sep 2012 10:35:13 +0000
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.279.1; Mon, 10 Sep 2012
	06:35:13 -0400
Message-ID: <504DC25F.7000508@citrix.com>
Date: Mon, 10 Sep 2012 11:35: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 Iceowl/1.0b1 Icedove/3.0.11
MIME-Version: 1.0
To: Dan Carpenter <dan.carpenter@oracle.com>
References: <20120908095208.GA608@elgon.mountain>
In-Reply-To: <20120908095208.GA608@elgon.mountain>
Cc: Jeremy Fitzhardinge <jeremy@goop.org>, xen-devel@lists.xensource.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Andres Lagar-Cavilla <andreslc@gridcentric.ca>,
	kernel-janitors@vger.kernel.org, virtualization@lists.linux-foundation.org
Subject: Re: [Xen-devel] [patch 1/3] xen/privcmd: check for integer overflow
 in	ioctl
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/09/12 10:52, Dan Carpenter wrote:
> If m.num is too large then the "m.num * sizeof(*m.arr)" multiplication
> could overflow and the access_ok() check wouldn't test the right size.

m.num is range checked later on so it doesn't matter that the
access_ok() checks might be wrong.  A bit subtle, perhaps.

David

> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
> ---
> Only needed in linux-next.
> 
> diff --git a/drivers/xen/privcmd.c b/drivers/xen/privcmd.c
> index 215a3c0..fdff8f9 100644
> --- a/drivers/xen/privcmd.c
> +++ b/drivers/xen/privcmd.c
> @@ -325,6 +325,8 @@ static long privcmd_ioctl_mmap_batch(void __user *udata, int version)
>  			return -EFAULT;
>  		/* Returns per-frame error in m.arr. */
>  		m.err = NULL;
> +		if (m.num > SIZE_MAX / sizeof(*m.arr))
> +			return -EINVAL;
>  		if (!access_ok(VERIFY_WRITE, m.arr, m.num * sizeof(*m.arr)))
>  			return -EFAULT;
>  		break;
> @@ -332,6 +334,8 @@ static long privcmd_ioctl_mmap_batch(void __user *udata, int version)
>  		if (copy_from_user(&m, udata, sizeof(struct privcmd_mmapbatch_v2)))
>  			return -EFAULT;
>  		/* Returns per-frame error code in m.err. */
> +		if (m.num > SIZE_MAX / sizeof(*m.err))
> +			return -EINVAL;
>  		if (!access_ok(VERIFY_WRITE, m.err, m.num * (sizeof(*m.err))))
>  			return -EFAULT;
>  		break;
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Sep 10 10:40:18 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Sep 2012 10:40:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TB1PQ-0001fm-BJ; Mon, 10 Sep 2012 10:40:04 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1TB1PP-0001fh-1H
	for xen-devel@lists.xen.org; Mon, 10 Sep 2012 10:40:03 +0000
Received: from [85.158.138.51:21168] by server-5.bemta-3.messagelabs.com id
	BD/BF-13133-283CD405; Mon, 10 Sep 2012 10:40:02 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1347273599!10983282!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNzc5Njk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2320 invoked from network); 10 Sep 2012 10:40:00 -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;
	10 Sep 2012 10:40:00 -0000
X-IronPort-AV: E=Sophos;i="4.80,396,1344211200"; 
	d="scan'208,217";a="207562769"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Sep 2012 10:38:45 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Mon, 10 Sep 2012 06:38:45 -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 1TB1O8-0006ZA-U0;
	Mon, 10 Sep 2012 11:38:44 +0100
Message-ID: <504DC334.6060201@citrix.com>
Date: Mon, 10 Sep 2012 11:38:44 +0100
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:14.0) Gecko/20120714 Thunderbird/14.0
MIME-Version: 1.0
To: Ashok Anand <ashok.anand@gmail.com>
References: <CALQsBOWDE_KqpntG8WJo86omLP3+rhQ0LDMW5vB752ubpF1FAA@mail.gmail.com>
	<CALQsBOXFVM+cdhmke5JDJmns2XUpHjyDOVN6R5qrrY9nTOR3SQ@mail.gmail.com>
	<504DC059.4070003@citrix.com>
	<CALQsBOV0EsUY+eYWqtL-FVuTOWOk_MLPnC2CYYPhNU9t=sxt9g@mail.gmail.com>
In-Reply-To: <CALQsBOV0EsUY+eYWqtL-FVuTOWOk_MLPnC2CYYPhNU9t=sxt9g@mail.gmail.com>
X-Enigmail-Version: 1.4.4
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] issue using SRIOV "Unable to start - perhaps the PF
 driver is not up yet", while PF driver is actually up
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============7699979477034878547=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============7699979477034878547==
Content-Type: multipart/alternative;
	boundary="------------090908030301000108080305"

--------------090908030301000108080305
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit

On 10/09/12 11:34, Ashok Anand wrote:
>
>
>     Are you sure?  0f:10.0 is probably the physical function which you
>     must keep in dom0.
>
>     ~Andrew
>
>
> I find from xm pci-list-assignable-devices  that 0f:10.0 is available
> - it is also hidden from dom0 (using pciback.hide in kernel arguments)
>
> if that is not the case, which physical function i can assign to domU?
> i tried with 0f:11.6, and others too, but i got similar messages.

What does lspci -vv for the physical function say?

As for the physical function: it is unsafe to pass physical functions to
a non-trusted guest, as the physical function has complete control over
the all the virtual functions, even if they are passed through to other
guests.  For that reason, the physical function should remain in dom0
(or a device driver domain if you are going for disaggregation).

>
>
>
>>
>>     i attach 0f:10.0 to a domU ubuntu machine, xm pci-attach ubuntu
>>     0f:10.0
>>
>>     on my dom0 machine, i can ping other machine using eth2,
>>     (implying PF on eth2 is active)
>>
>>     on my domU machine, when i attach the virtual function, i get the
>>     following messages
>>
>>     [ 2282.688356 <tel:%5B%202282.688356>] ixgbevf 0000:00:00.0: Xen
>>     PCI mapped GSI0 to IRQ28
>>     [ 2282.688470 <tel:%5B%202282.688470>] ixgbevf 0000:00:00.0:
>>     setting latency timer to 64
>>     [ 2282.690187 <tel:%5B%202282.690187>] ixgbevf 0000:00:00.0: PF
>>     still in reset state, assigning new address
>>
>>     while PF on eth2 is  there and active, since i can ping other
>>     machine.
>>
>>     Now, when I try to bring up the VF interface on domU, 
>>      i get the following error
>>
>>      2476.295582] Unable to start - perhaps the PF Driver isn't up yet
>>     SIOCSIFFLAGS: Network is down
>>     [ 2476.296917] Unable to start - perhaps the PF Driver isn't up yet
>>     SIOCSIFFLAGS: Network is down
>>
>>     and on dmesg on domU, 
>>     [ 2476.295582] Unable to start - perhaps the PF Driver isn't up yet
>>     [ 2476.296917] Unable to start - perhaps the PF Driver isn't up yet
>>
>>
>>     Any thoughts on what could be wrong? I have been struggling with
>>     this for quite some time
>>     and would really appreciate your thoughts on it.
>>
>>     Thanks, 
>>     Ashok
>>
>>
>>
>>
>>
>>
>
>     -- 
>     Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
>     T: +44 (0)1223 225 900 <tel:%2B44%20%280%291223%20225%20900>, http://www.citrix.com
>
>
>     _______________________________________________
>     Xen-devel mailing list
>     Xen-devel@lists.xen.org <mailto: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


--------------090908030301000108080305
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 10/09/12 11:34, Ashok Anand wrote:<br>
    <blockquote
cite="mid:CALQsBOV0EsUY+eYWqtL-FVuTOWOk_MLPnC2CYYPhNU9t=sxt9g@mail.gmail.com"
      type="cite"><br>
      <br>
      <div class="gmail_quote">
        <blockquote class="gmail_quote" style="margin:0 0 0
          .8ex;border-left:1px #ccc solid;padding-left:1ex">
          <div bgcolor="#FFFFFF" text="#000000"> Are you sure?&nbsp; 0f:10.0
            is probably the physical function which you must keep in
            dom0.<br>
            <br>
            ~Andrew</div>
        </blockquote>
        <div><br>
        </div>
        <div>I find from xm pci-list-assignable-devices &nbsp;that 0f:10.0 is
          available - it is also hidden from dom0 (using pciback.hide in
          kernel arguments)</div>
        <div><br>
        </div>
        <div>if that is not the case, which physical function i can
          assign to domU?</div>
        <div>i tried with 0f:11.6, and others too, but i got similar
          messages.</div>
      </div>
    </blockquote>
    <br>
    What does lspci -vv for the physical function say?<br>
    <br>
    As for the physical function: it is unsafe to pass physical
    functions to a non-trusted guest, as the physical function has
    complete control over the all the virtual functions, even if they
    are passed through to other guests.&nbsp; For that reason, the physical
    function should remain in dom0 (or a device driver domain if you are
    going for disaggregation).<br>
    <br>
    <blockquote
cite="mid:CALQsBOV0EsUY+eYWqtL-FVuTOWOk_MLPnC2CYYPhNU9t=sxt9g@mail.gmail.com"
      type="cite">
      <div class="gmail_quote">
        <div><br>
        </div>
        <blockquote class="gmail_quote" style="margin:0 0 0
          .8ex;border-left:1px #ccc solid;padding-left:1ex">
          <div bgcolor="#FFFFFF" text="#000000">
            <div class="im"><br>
              <br>
              <blockquote type="cite">
                <div class="gmail_quote">
                  <div><br>
                  </div>
                  <div>i attach 0f:10.0 to a domU ubuntu machine,&nbsp;xm
                    pci-attach ubuntu 0f:10.0</div>
                  <div><br>
                  </div>
                  <div>on my dom0 machine, i can ping other machine
                    using eth2, (implying PF on eth2 is active)</div>
                  <div><br>
                  </div>
                  <div>on my domU machine, when i attach the virtual
                    function, i get the following messages</div>
                  <div><br>
                  </div>
                  <div>
                    <div><a moz-do-not-send="true"
                        href="tel:%5B%202282.688356"
                        value="+12282688356" target="_blank">[
                        2282.688356</a>] ixgbevf 0000:00:00.0: Xen PCI
                      mapped GSI0 to IRQ28</div>
                    <div><a moz-do-not-send="true"
                        href="tel:%5B%202282.688470"
                        value="+12282688470" target="_blank">[
                        2282.688470</a>] ixgbevf 0000:00:00.0: setting
                      latency timer to 64</div>
                    <div><a moz-do-not-send="true"
                        href="tel:%5B%202282.690187"
                        value="+12282690187" target="_blank">[
                        2282.690187</a>] ixgbevf 0000:00:00.0: PF still
                      in reset state, assigning new address</div>
                  </div>
                  <div><br>
                  </div>
                  <div>while PF on eth2 is &nbsp;there and active, since i
                    can ping other machine.</div>
                  <div><br>
                  </div>
                  <div>Now, when I try to bring up the VF interface on
                    domU,&nbsp;</div>
                  <div>&nbsp;i get the following error</div>
                  <div> <br>
                  </div>
                  <div>
                    <div>&nbsp;2476.295582] Unable to start - perhaps the PF
                      Driver isn't up yet</div>
                    <div>SIOCSIFFLAGS: Network is down</div>
                    <div>[ 2476.296917] Unable to start - perhaps the PF
                      Driver isn't up yet</div>
                    <div> SIOCSIFFLAGS: Network is down</div>
                  </div>
                  <div><br>
                  </div>
                  <div>and on dmesg on domU,&nbsp;</div>
                  <div>
                    <div>[ 2476.295582] Unable to start - perhaps the PF
                      Driver isn't up yet</div>
                    <div>[ 2476.296917] Unable to start - perhaps the PF
                      Driver isn't up yet</div>
                  </div>
                  <div><br>
                  </div>
                  <div><br>
                  </div>
                  <div>Any thoughts on what could be wrong? I have been
                    struggling with this for quite some time</div>
                  <div>and would really appreciate your thoughts on it.</div>
                  <div><br>
                  </div>
                  <div>Thanks,&nbsp;</div>
                  <span><font color="#888888">
                      <div>Ashok</div>
                      <div><br>
                      </div>
                      <div><br>
                      </div>
                      <div><br>
                      </div>
                      <div><br>
                      </div>
                      <div><br>
                      </div>
                    </font></span></div>
                <br>
              </blockquote>
              <br>
            </div>
            <span class="HOEnZb"><font color="#888888">
                <pre cols="72">-- 
Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
T: <a moz-do-not-send="true" href="tel:%2B44%20%280%291223%20225%20900" value="+441223225900" target="_blank">+44 (0)1223 225 900</a>, <a moz-do-not-send="true" href="http://www.citrix.com" target="_blank">http://www.citrix.com</a></pre>
              </font></span></div>
          <br>
          _______________________________________________<br>
          Xen-devel mailing list<br>
          <a moz-do-not-send="true"
            href="mailto:Xen-devel@lists.xen.org">Xen-devel@lists.xen.org</a><br>
          <a moz-do-not-send="true"
            href="http://lists.xen.org/xen-devel" target="_blank">http://lists.xen.org/xen-devel</a><br>
          <br>
        </blockquote>
      </div>
      <br>
    </blockquote>
    <br>
    <pre class="moz-signature" cols="72">-- 
Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
T: +44 (0)1223 225 900, <a class="moz-txt-link-freetext" href="http://www.citrix.com">http://www.citrix.com</a></pre>
  </body>
</html>

--------------090908030301000108080305--


--===============7699979477034878547==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============7699979477034878547==--


From xen-devel-bounces@lists.xen.org Mon Sep 10 10:40:18 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Sep 2012 10:40:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TB1PQ-0001fm-BJ; Mon, 10 Sep 2012 10:40:04 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1TB1PP-0001fh-1H
	for xen-devel@lists.xen.org; Mon, 10 Sep 2012 10:40:03 +0000
Received: from [85.158.138.51:21168] by server-5.bemta-3.messagelabs.com id
	BD/BF-13133-283CD405; Mon, 10 Sep 2012 10:40:02 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1347273599!10983282!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNzc5Njk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2320 invoked from network); 10 Sep 2012 10:40:00 -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;
	10 Sep 2012 10:40:00 -0000
X-IronPort-AV: E=Sophos;i="4.80,396,1344211200"; 
	d="scan'208,217";a="207562769"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Sep 2012 10:38:45 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Mon, 10 Sep 2012 06:38:45 -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 1TB1O8-0006ZA-U0;
	Mon, 10 Sep 2012 11:38:44 +0100
Message-ID: <504DC334.6060201@citrix.com>
Date: Mon, 10 Sep 2012 11:38:44 +0100
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:14.0) Gecko/20120714 Thunderbird/14.0
MIME-Version: 1.0
To: Ashok Anand <ashok.anand@gmail.com>
References: <CALQsBOWDE_KqpntG8WJo86omLP3+rhQ0LDMW5vB752ubpF1FAA@mail.gmail.com>
	<CALQsBOXFVM+cdhmke5JDJmns2XUpHjyDOVN6R5qrrY9nTOR3SQ@mail.gmail.com>
	<504DC059.4070003@citrix.com>
	<CALQsBOV0EsUY+eYWqtL-FVuTOWOk_MLPnC2CYYPhNU9t=sxt9g@mail.gmail.com>
In-Reply-To: <CALQsBOV0EsUY+eYWqtL-FVuTOWOk_MLPnC2CYYPhNU9t=sxt9g@mail.gmail.com>
X-Enigmail-Version: 1.4.4
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] issue using SRIOV "Unable to start - perhaps the PF
 driver is not up yet", while PF driver is actually up
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============7699979477034878547=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============7699979477034878547==
Content-Type: multipart/alternative;
	boundary="------------090908030301000108080305"

--------------090908030301000108080305
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit

On 10/09/12 11:34, Ashok Anand wrote:
>
>
>     Are you sure?  0f:10.0 is probably the physical function which you
>     must keep in dom0.
>
>     ~Andrew
>
>
> I find from xm pci-list-assignable-devices  that 0f:10.0 is available
> - it is also hidden from dom0 (using pciback.hide in kernel arguments)
>
> if that is not the case, which physical function i can assign to domU?
> i tried with 0f:11.6, and others too, but i got similar messages.

What does lspci -vv for the physical function say?

As for the physical function: it is unsafe to pass physical functions to
a non-trusted guest, as the physical function has complete control over
the all the virtual functions, even if they are passed through to other
guests.  For that reason, the physical function should remain in dom0
(or a device driver domain if you are going for disaggregation).

>
>
>
>>
>>     i attach 0f:10.0 to a domU ubuntu machine, xm pci-attach ubuntu
>>     0f:10.0
>>
>>     on my dom0 machine, i can ping other machine using eth2,
>>     (implying PF on eth2 is active)
>>
>>     on my domU machine, when i attach the virtual function, i get the
>>     following messages
>>
>>     [ 2282.688356 <tel:%5B%202282.688356>] ixgbevf 0000:00:00.0: Xen
>>     PCI mapped GSI0 to IRQ28
>>     [ 2282.688470 <tel:%5B%202282.688470>] ixgbevf 0000:00:00.0:
>>     setting latency timer to 64
>>     [ 2282.690187 <tel:%5B%202282.690187>] ixgbevf 0000:00:00.0: PF
>>     still in reset state, assigning new address
>>
>>     while PF on eth2 is  there and active, since i can ping other
>>     machine.
>>
>>     Now, when I try to bring up the VF interface on domU, 
>>      i get the following error
>>
>>      2476.295582] Unable to start - perhaps the PF Driver isn't up yet
>>     SIOCSIFFLAGS: Network is down
>>     [ 2476.296917] Unable to start - perhaps the PF Driver isn't up yet
>>     SIOCSIFFLAGS: Network is down
>>
>>     and on dmesg on domU, 
>>     [ 2476.295582] Unable to start - perhaps the PF Driver isn't up yet
>>     [ 2476.296917] Unable to start - perhaps the PF Driver isn't up yet
>>
>>
>>     Any thoughts on what could be wrong? I have been struggling with
>>     this for quite some time
>>     and would really appreciate your thoughts on it.
>>
>>     Thanks, 
>>     Ashok
>>
>>
>>
>>
>>
>>
>
>     -- 
>     Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
>     T: +44 (0)1223 225 900 <tel:%2B44%20%280%291223%20225%20900>, http://www.citrix.com
>
>
>     _______________________________________________
>     Xen-devel mailing list
>     Xen-devel@lists.xen.org <mailto: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


--------------090908030301000108080305
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 10/09/12 11:34, Ashok Anand wrote:<br>
    <blockquote
cite="mid:CALQsBOV0EsUY+eYWqtL-FVuTOWOk_MLPnC2CYYPhNU9t=sxt9g@mail.gmail.com"
      type="cite"><br>
      <br>
      <div class="gmail_quote">
        <blockquote class="gmail_quote" style="margin:0 0 0
          .8ex;border-left:1px #ccc solid;padding-left:1ex">
          <div bgcolor="#FFFFFF" text="#000000"> Are you sure?&nbsp; 0f:10.0
            is probably the physical function which you must keep in
            dom0.<br>
            <br>
            ~Andrew</div>
        </blockquote>
        <div><br>
        </div>
        <div>I find from xm pci-list-assignable-devices &nbsp;that 0f:10.0 is
          available - it is also hidden from dom0 (using pciback.hide in
          kernel arguments)</div>
        <div><br>
        </div>
        <div>if that is not the case, which physical function i can
          assign to domU?</div>
        <div>i tried with 0f:11.6, and others too, but i got similar
          messages.</div>
      </div>
    </blockquote>
    <br>
    What does lspci -vv for the physical function say?<br>
    <br>
    As for the physical function: it is unsafe to pass physical
    functions to a non-trusted guest, as the physical function has
    complete control over the all the virtual functions, even if they
    are passed through to other guests.&nbsp; For that reason, the physical
    function should remain in dom0 (or a device driver domain if you are
    going for disaggregation).<br>
    <br>
    <blockquote
cite="mid:CALQsBOV0EsUY+eYWqtL-FVuTOWOk_MLPnC2CYYPhNU9t=sxt9g@mail.gmail.com"
      type="cite">
      <div class="gmail_quote">
        <div><br>
        </div>
        <blockquote class="gmail_quote" style="margin:0 0 0
          .8ex;border-left:1px #ccc solid;padding-left:1ex">
          <div bgcolor="#FFFFFF" text="#000000">
            <div class="im"><br>
              <br>
              <blockquote type="cite">
                <div class="gmail_quote">
                  <div><br>
                  </div>
                  <div>i attach 0f:10.0 to a domU ubuntu machine,&nbsp;xm
                    pci-attach ubuntu 0f:10.0</div>
                  <div><br>
                  </div>
                  <div>on my dom0 machine, i can ping other machine
                    using eth2, (implying PF on eth2 is active)</div>
                  <div><br>
                  </div>
                  <div>on my domU machine, when i attach the virtual
                    function, i get the following messages</div>
                  <div><br>
                  </div>
                  <div>
                    <div><a moz-do-not-send="true"
                        href="tel:%5B%202282.688356"
                        value="+12282688356" target="_blank">[
                        2282.688356</a>] ixgbevf 0000:00:00.0: Xen PCI
                      mapped GSI0 to IRQ28</div>
                    <div><a moz-do-not-send="true"
                        href="tel:%5B%202282.688470"
                        value="+12282688470" target="_blank">[
                        2282.688470</a>] ixgbevf 0000:00:00.0: setting
                      latency timer to 64</div>
                    <div><a moz-do-not-send="true"
                        href="tel:%5B%202282.690187"
                        value="+12282690187" target="_blank">[
                        2282.690187</a>] ixgbevf 0000:00:00.0: PF still
                      in reset state, assigning new address</div>
                  </div>
                  <div><br>
                  </div>
                  <div>while PF on eth2 is &nbsp;there and active, since i
                    can ping other machine.</div>
                  <div><br>
                  </div>
                  <div>Now, when I try to bring up the VF interface on
                    domU,&nbsp;</div>
                  <div>&nbsp;i get the following error</div>
                  <div> <br>
                  </div>
                  <div>
                    <div>&nbsp;2476.295582] Unable to start - perhaps the PF
                      Driver isn't up yet</div>
                    <div>SIOCSIFFLAGS: Network is down</div>
                    <div>[ 2476.296917] Unable to start - perhaps the PF
                      Driver isn't up yet</div>
                    <div> SIOCSIFFLAGS: Network is down</div>
                  </div>
                  <div><br>
                  </div>
                  <div>and on dmesg on domU,&nbsp;</div>
                  <div>
                    <div>[ 2476.295582] Unable to start - perhaps the PF
                      Driver isn't up yet</div>
                    <div>[ 2476.296917] Unable to start - perhaps the PF
                      Driver isn't up yet</div>
                  </div>
                  <div><br>
                  </div>
                  <div><br>
                  </div>
                  <div>Any thoughts on what could be wrong? I have been
                    struggling with this for quite some time</div>
                  <div>and would really appreciate your thoughts on it.</div>
                  <div><br>
                  </div>
                  <div>Thanks,&nbsp;</div>
                  <span><font color="#888888">
                      <div>Ashok</div>
                      <div><br>
                      </div>
                      <div><br>
                      </div>
                      <div><br>
                      </div>
                      <div><br>
                      </div>
                      <div><br>
                      </div>
                    </font></span></div>
                <br>
              </blockquote>
              <br>
            </div>
            <span class="HOEnZb"><font color="#888888">
                <pre cols="72">-- 
Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
T: <a moz-do-not-send="true" href="tel:%2B44%20%280%291223%20225%20900" value="+441223225900" target="_blank">+44 (0)1223 225 900</a>, <a moz-do-not-send="true" href="http://www.citrix.com" target="_blank">http://www.citrix.com</a></pre>
              </font></span></div>
          <br>
          _______________________________________________<br>
          Xen-devel mailing list<br>
          <a moz-do-not-send="true"
            href="mailto:Xen-devel@lists.xen.org">Xen-devel@lists.xen.org</a><br>
          <a moz-do-not-send="true"
            href="http://lists.xen.org/xen-devel" target="_blank">http://lists.xen.org/xen-devel</a><br>
          <br>
        </blockquote>
      </div>
      <br>
    </blockquote>
    <br>
    <pre class="moz-signature" cols="72">-- 
Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
T: +44 (0)1223 225 900, <a class="moz-txt-link-freetext" href="http://www.citrix.com">http://www.citrix.com</a></pre>
  </body>
</html>

--------------090908030301000108080305--


--===============7699979477034878547==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============7699979477034878547==--


From xen-devel-bounces@lists.xen.org Mon Sep 10 10:42:58 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Sep 2012 10:42:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TB1Rx-0001ms-UF; Mon, 10 Sep 2012 10:42:41 +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 1TB1Rw-0001mk-VH
	for xen-devel@lists.xen.org; Mon, 10 Sep 2012 10:42:41 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1347273754!9257289!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM5OTE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3113 invoked from network); 10 Sep 2012 10:42:35 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-13.tower-27.messagelabs.com with SMTP;
	10 Sep 2012 10:42:35 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 10 Sep 2012 11:42:34 +0100
Message-Id: <504DE037020000780009A22B@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 10 Sep 2012 11:42:31 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Campbell" <Ian.Campbell@citrix.com>
References: <504DD183020000780009A1B6@nat28.tlf.novell.com>
	<1347272127.5305.54.camel@zakaz.uk.xensource.com>
In-Reply-To: <1347272127.5305.54.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] docs: document "ucode=" hypervisor command
 line option
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 10.09.12 at 12:15, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> On Mon, 2012-09-10 at 10:39 +0100, Jan Beulich wrote:
>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> 
> Acked and applied. Thanks.
> 
> Can/will you take this for 4.2.0 too?

Sure, once I'm allowed to put things there.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 10 10:42:58 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Sep 2012 10:42:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TB1Rx-0001ms-UF; Mon, 10 Sep 2012 10:42:41 +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 1TB1Rw-0001mk-VH
	for xen-devel@lists.xen.org; Mon, 10 Sep 2012 10:42:41 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1347273754!9257289!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM5OTE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3113 invoked from network); 10 Sep 2012 10:42:35 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-13.tower-27.messagelabs.com with SMTP;
	10 Sep 2012 10:42:35 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 10 Sep 2012 11:42:34 +0100
Message-Id: <504DE037020000780009A22B@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 10 Sep 2012 11:42:31 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Campbell" <Ian.Campbell@citrix.com>
References: <504DD183020000780009A1B6@nat28.tlf.novell.com>
	<1347272127.5305.54.camel@zakaz.uk.xensource.com>
In-Reply-To: <1347272127.5305.54.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] docs: document "ucode=" hypervisor command
 line option
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 10.09.12 at 12:15, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> On Mon, 2012-09-10 at 10:39 +0100, Jan Beulich wrote:
>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> 
> Acked and applied. Thanks.
> 
> Can/will you take this for 4.2.0 too?

Sure, once I'm allowed to put things there.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 10 10:43:48 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Sep 2012 10: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 1TB1Ss-0001rr-Bs; Mon, 10 Sep 2012 10:43:38 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1TB1Sq-0001rI-Fm
	for xen-devel@lists.xensource.com; Mon, 10 Sep 2012 10:43:36 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1347273801!3343499!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNzc5Njk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23974 invoked from network); 10 Sep 2012 10:43:23 -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;
	10 Sep 2012 10:43:23 -0000
X-IronPort-AV: E=Sophos;i="4.80,396,1344211200"; d="scan'208";a="207562960"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Sep 2012 10:43:21 +0000
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.279.1; Mon, 10 Sep 2012
	06:43:20 -0400
Message-ID: <504DC447.9010301@citrix.com>
Date: Mon, 10 Sep 2012 11:43: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 Iceowl/1.0b1 Icedove/3.0.11
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <20120908095808.GC608@elgon.mountain>
	<504DC8FE020000780009A190@nat28.tlf.novell.com>
In-Reply-To: <504DC8FE020000780009A190@nat28.tlf.novell.com>
Cc: Jeremy Fitzhardinge <jeremy@goop.org>, xen-devel@lists.xensource.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Andres Lagar-Cavilla <andreslc@gridcentric.ca>,
	kernel-janitors@vger.kernel.org, virtualization@lists.linux-foundation.org,
	Dan Carpenter <dan.carpenter@oracle.com>
Subject: Re: [Xen-devel] [patch 3/3] xen/privcmd: remove const modifier from
 declaration
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/09/12 10:03, Jan Beulich wrote:
>>>> On 08.09.12 at 11:58, Dan Carpenter <dan.carpenter@oracle.com> wrote:
>> When we use this pointer, we cast away the const modifier and modify the
>> data.  I think it was an accident to declare it as const.
> 
> NAK - the const is very valid here, as the v2 interface (as opposed
> to the v1 one) does _not_ modify this array (or if it does, it's a
> bug). This is a guarantee made to user mode, so it should also be
> expressed that way in the interface.
> 
> But of course the cast used before this patch isn't right either, as
> it indeed inappropriately discards the qualifier. Afaiu this was done
> to simplify the internal workings of the code, but I don't think it's
> desirable to sacrifice type safety for implementation simplicity.

m.arr here isn't const as m is really the V1 structure where m.arr is
non-const.

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 10 10:43:48 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Sep 2012 10: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 1TB1Ss-0001rr-Bs; Mon, 10 Sep 2012 10:43:38 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1TB1Sq-0001rI-Fm
	for xen-devel@lists.xensource.com; Mon, 10 Sep 2012 10:43:36 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1347273801!3343499!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNzc5Njk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23974 invoked from network); 10 Sep 2012 10:43:23 -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;
	10 Sep 2012 10:43:23 -0000
X-IronPort-AV: E=Sophos;i="4.80,396,1344211200"; d="scan'208";a="207562960"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Sep 2012 10:43:21 +0000
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.279.1; Mon, 10 Sep 2012
	06:43:20 -0400
Message-ID: <504DC447.9010301@citrix.com>
Date: Mon, 10 Sep 2012 11:43: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 Iceowl/1.0b1 Icedove/3.0.11
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <20120908095808.GC608@elgon.mountain>
	<504DC8FE020000780009A190@nat28.tlf.novell.com>
In-Reply-To: <504DC8FE020000780009A190@nat28.tlf.novell.com>
Cc: Jeremy Fitzhardinge <jeremy@goop.org>, xen-devel@lists.xensource.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Andres Lagar-Cavilla <andreslc@gridcentric.ca>,
	kernel-janitors@vger.kernel.org, virtualization@lists.linux-foundation.org,
	Dan Carpenter <dan.carpenter@oracle.com>
Subject: Re: [Xen-devel] [patch 3/3] xen/privcmd: remove const modifier from
 declaration
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/09/12 10:03, Jan Beulich wrote:
>>>> On 08.09.12 at 11:58, Dan Carpenter <dan.carpenter@oracle.com> wrote:
>> When we use this pointer, we cast away the const modifier and modify the
>> data.  I think it was an accident to declare it as const.
> 
> NAK - the const is very valid here, as the v2 interface (as opposed
> to the v1 one) does _not_ modify this array (or if it does, it's a
> bug). This is a guarantee made to user mode, so it should also be
> expressed that way in the interface.
> 
> But of course the cast used before this patch isn't right either, as
> it indeed inappropriately discards the qualifier. Afaiu this was done
> to simplify the internal workings of the code, but I don't think it's
> desirable to sacrifice type safety for implementation simplicity.

m.arr here isn't const as m is really the V1 structure where m.arr is
non-const.

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 10 10:47:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Sep 2012 10: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 1TB1W1-0002EP-Mo; Mon, 10 Sep 2012 10:46:53 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ashok.anand@gmail.com>) id 1TB1Vz-0002EF-Kp
	for xen-devel@lists.xen.org; Mon, 10 Sep 2012 10:46:52 +0000
Received: from [85.158.138.51:27760] by server-4.bemta-3.messagelabs.com id
	FB/B3-24831-A15CD405; Mon, 10 Sep 2012 10:46:50 +0000
X-Env-Sender: ashok.anand@gmail.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1347274008!29169578!1
X-Originating-IP: [209.85.214.173]
X-SpamReason: No, hits=0.9 required=7.0 tests=BODY_RANDOM_LONG,
	HTML_50_60, HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14, RCVD_BY_IP,
	spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 965 invoked from network); 10 Sep 2012 10:46:49 -0000
Received: from mail-ob0-f173.google.com (HELO mail-ob0-f173.google.com)
	(209.85.214.173)
	by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Sep 2012 10:46:49 -0000
Received: by obbta14 with SMTP id ta14so3560923obb.32
	for <xen-devel@lists.xen.org>; Mon, 10 Sep 2012 03:46:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=kmfy658GdHsnmYAHmK/pyOwfFRJ7B5K54VG+2WEcOSM=;
	b=sJgyr5rd27OWHneF+oRP75Rv/5bLYxyI/8IZsfMkPDsmraJCHI1R01elYUAZnUaVUX
	d8ybvz/NgMXSA5yWGS+YCXQBvfmkYePW//sDbnjp4c9uBQFkU/dJFjQ93IiEF8u9z2Rf
	VgzCvLBRshi+iVqf0q82r2qH/ZLNDjwVAsiiWzjGMBsKwPIQUWc8Df5ruIvVCT2hDNsT
	dq5lLzF8/c/0y55ddH4RKxGvg/XMQqWmzXP5rd9IODhybKhWk5oM3Rt0F+bBm/gCR/C2
	Ko8A5d3RCQmls9agnVg3cb4Fmo4b4nnC53TYiqLJsoT0bpXIO/YrpMpDRrjjilNMQNsu
	a7eQ==
MIME-Version: 1.0
Received: by 10.60.0.161 with SMTP id 1mr13834982oef.83.1347274007813; Mon, 10
	Sep 2012 03:46:47 -0700 (PDT)
Received: by 10.182.32.102 with HTTP; Mon, 10 Sep 2012 03:46:47 -0700 (PDT)
In-Reply-To: <504DC334.6060201@citrix.com>
References: <CALQsBOWDE_KqpntG8WJo86omLP3+rhQ0LDMW5vB752ubpF1FAA@mail.gmail.com>
	<CALQsBOXFVM+cdhmke5JDJmns2XUpHjyDOVN6R5qrrY9nTOR3SQ@mail.gmail.com>
	<504DC059.4070003@citrix.com>
	<CALQsBOV0EsUY+eYWqtL-FVuTOWOk_MLPnC2CYYPhNU9t=sxt9g@mail.gmail.com>
	<504DC334.6060201@citrix.com>
Date: Mon, 10 Sep 2012 16:16:47 +0530
Message-ID: <CALQsBOXqT39-ZkOuTT-c58qUW6dihuXWfUi08YzjmgJzaW9YAA@mail.gmail.com>
From: Ashok Anand <ashok.anand@gmail.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] issue using SRIOV "Unable to start - perhaps the PF
 driver is not up yet", while PF driver is actually up
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============3163611272199496851=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============3163611272199496851==
Content-Type: multipart/alternative; boundary=e89a8fb1ffc2a69dac04c956ac5c

--e89a8fb1ffc2a69dac04c956ac5c
Content-Type: text/plain; charset=ISO-8859-1

I am passing virtual functions. please see below ,based on the message from
lspci.

> What does lspci -vv for the physical function say?
>
> As for the physical function: it is unsafe to pass physical functions to a
> non-trusted guest, as the physical function has complete control over the
> all the virtual functions, even if they are passed through to other
> guests.  For that reason, the physical function should remain in dom0 (or a
> device driver domain if you are going for disaggregation).
>

here is the message lspci -vv | grep Eth gives me,

0f:00.0 Ethernet controller: Intel Corporation 82599EB 10-Gigabit SFI/SFP+
Network Connection (rev 01)
Subsystem: Intel Corporation Ethernet Server Adapter X520-2
0f:00.1 Ethernet controller: Intel Corporation 82599EB 10-Gigabit SFI/SFP+
Network Connection (rev 01)
Subsystem: Intel Corporation Ethernet Server Adapter X520-2
0f:10.0 Ethernet controller: Intel Corporation 82599 Ethernet Controller
Virtual Function (rev 01)
0f:10.2 Ethernet controller: Intel Corporation 82599 Ethernet Controller
Virtual Function (rev 01)
0f:10.4 Ethernet controller: Intel Corporation 82599 Ethernet Controller
Virtual Function (rev 01)
0f:10.6 Ethernet controller: Intel Corporation 82599 Ethernet Controller
Virtual Function (rev 01)
0f:11.0 Ethernet controller: Intel Corporation 82599 Ethernet Controller
Virtual Function (rev 01)
0f:11.2 Ethernet controller: Intel Corporation 82599 Ethernet Controller
Virtual Function (rev 01)
0f:11.4 Ethernet controller: Intel Corporation 82599 Ethernet Controller
Virtual Function (rev 01)
0f:11.6 Ethernet controller: Intel Corporation 82599 Ethernet Controller
Virtual Function (rev 01)

Here, 0f:00.0 is the physical function, while 0f:10.0 and others are
virtual functions -- so I am attaching virtual functions.




>
>
>
>
>>
>>
>>  i attach 0f:10.0 to a domU ubuntu machine, xm pci-attach ubuntu 0f:10.0
>>
>>  on my dom0 machine, i can ping other machine using eth2, (implying PF
>> on eth2 is active)
>>
>>  on my domU machine, when i attach the virtual function, i get the
>> following messages
>>
>>  [ 2282.688356 <%5B%202282.688356>] ixgbevf 0000:00:00.0: Xen PCI mapped
>> GSI0 to IRQ28
>> [ 2282.688470 <%5B%202282.688470>] ixgbevf 0000:00:00.0: setting latency
>> timer to 64
>> [ 2282.690187 <%5B%202282.690187>] ixgbevf 0000:00:00.0: PF still in
>> reset state, assigning new address
>>
>>  while PF on eth2 is  there and active, since i can ping other machine.
>>
>>  Now, when I try to bring up the VF interface on domU,
>>  i get the following error
>>
>>   2476.295582] Unable to start - perhaps the PF Driver isn't up yet
>> SIOCSIFFLAGS: Network is down
>> [ 2476.296917] Unable to start - perhaps the PF Driver isn't up yet
>>  SIOCSIFFLAGS: Network is down
>>
>>  and on dmesg on domU,
>>  [ 2476.295582] Unable to start - perhaps the PF Driver isn't up yet
>> [ 2476.296917] Unable to start - perhaps the PF Driver isn't up yet
>>
>>
>>  Any thoughts on what could be wrong? I have been struggling with this
>> for quite some time
>> and would really appreciate your thoughts on it.
>>
>>  Thanks,
>>  Ashok
>>
>>
>>
>>
>>
>>
>>
>>  --
>> 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
>>
>>
>
> --
> Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
> T: +44 (0)1223 225 900, http://www.citrix.com
>
>

--e89a8fb1ffc2a69dac04c956ac5c
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div class=3D"gmail_quote"><div><br></div><div>I am passing virtual functio=
ns. please see below ,based on the message from lspci.=A0</div><blockquote =
class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid=
;padding-left:1ex">
<div bgcolor=3D"#FFFFFF" text=3D"#000000">What does lspci -vv for the physi=
cal function say?<br>
    <br>
    As for the physical function: it is unsafe to pass physical
    functions to a non-trusted guest, as the physical function has
    complete control over the all the virtual functions, even if they
    are passed through to other guests.=A0 For that reason, the physical
    function should remain in dom0 (or a device driver domain if you are
    going for disaggregation).</div></blockquote><div><br></div><div>here i=
s the message lspci -vv | grep Eth gives me,=A0</div><div><br></div><div><d=
iv>0f:00.0 Ethernet controller: Intel Corporation 82599EB 10-Gigabit SFI/SF=
P+ Network Connection (rev 01)</div>
<div><span class=3D"Apple-tab-span" style=3D"white-space:pre">	</span>Subsy=
stem: Intel Corporation Ethernet Server Adapter X520-2</div><div>0f:00.1 Et=
hernet controller: Intel Corporation 82599EB 10-Gigabit SFI/SFP+ Network Co=
nnection (rev 01)</div>
<div><span class=3D"Apple-tab-span" style=3D"white-space:pre">	</span>Subsy=
stem: Intel Corporation Ethernet Server Adapter X520-2</div><div>0f:10.0 Et=
hernet controller: Intel Corporation 82599 Ethernet Controller Virtual Func=
tion (rev 01)</div>
<div>0f:10.2 Ethernet controller: Intel Corporation 82599 Ethernet Controll=
er Virtual Function (rev 01)</div><div>0f:10.4 Ethernet controller: Intel C=
orporation 82599 Ethernet Controller Virtual Function (rev 01)</div><div>
0f:10.6 Ethernet controller: Intel Corporation 82599 Ethernet Controller Vi=
rtual Function (rev 01)</div><div>0f:11.0 Ethernet controller: Intel Corpor=
ation 82599 Ethernet Controller Virtual Function (rev 01)</div><div>0f:11.2=
 Ethernet controller: Intel Corporation 82599 Ethernet Controller Virtual F=
unction (rev 01)</div>
<div>0f:11.4 Ethernet controller: Intel Corporation 82599 Ethernet Controll=
er Virtual Function (rev 01)</div><div>0f:11.6 Ethernet controller: Intel C=
orporation 82599 Ethernet Controller Virtual Function (rev 01)</div></div>
<div><br></div><div>Here, 0f:00.0 is the physical function, while 0f:10.0 a=
nd others are virtual functions -- so I am attaching virtual functions.=A0<=
/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 bgcolor=3D"#FFFFFF" text=3D"#000000"><div><div class=3D"h5"><br>
    <br>
    <blockquote type=3D"cite">
      <div class=3D"gmail_quote">
        <div><br>
        </div>
        <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border=
-left:1px #ccc solid;padding-left:1ex">
          <div bgcolor=3D"#FFFFFF" text=3D"#000000">
            <div><br>
              <br>
              <blockquote type=3D"cite">
                <div class=3D"gmail_quote">
                  <div><br>
                  </div>
                  <div>i attach 0f:10.0 to a domU ubuntu machine,=A0xm
                    pci-attach ubuntu 0f:10.0</div>
                  <div><br>
                  </div>
                  <div>on my dom0 machine, i can ping other machine
                    using eth2, (implying PF on eth2 is active)</div>
                  <div><br>
                  </div>
                  <div>on my domU machine, when i attach the virtual
                    function, i get the following messages</div>
                  <div><br>
                  </div>
                  <div>
                    <div><a href=3D"tel:%5B%202282.688356" value=3D"+122826=
88356" target=3D"_blank">[
                        2282.688356</a>] ixgbevf 0000:00:00.0: Xen PCI
                      mapped GSI0 to IRQ28</div>
                    <div><a href=3D"tel:%5B%202282.688470" value=3D"+122826=
88470" target=3D"_blank">[
                        2282.688470</a>] ixgbevf 0000:00:00.0: setting
                      latency timer to 64</div>
                    <div><a href=3D"tel:%5B%202282.690187" value=3D"+122826=
90187" target=3D"_blank">[
                        2282.690187</a>] ixgbevf 0000:00:00.0: PF still
                      in reset state, assigning new address</div>
                  </div>
                  <div><br>
                  </div>
                  <div>while PF on eth2 is =A0there and active, since i
                    can ping other machine.</div>
                  <div><br>
                  </div>
                  <div>Now, when I try to bring up the VF interface on
                    domU,=A0</div>
                  <div>=A0i get the following error</div>
                  <div> <br>
                  </div>
                  <div>
                    <div>=A02476.295582] Unable to start - perhaps the PF
                      Driver isn&#39;t up yet</div>
                    <div>SIOCSIFFLAGS: Network is down</div>
                    <div>[ 2476.296917] Unable to start - perhaps the PF
                      Driver isn&#39;t up yet</div>
                    <div> SIOCSIFFLAGS: Network is down</div>
                  </div>
                  <div><br>
                  </div>
                  <div>and on dmesg on domU,=A0</div>
                  <div>
                    <div>[ 2476.295582] Unable to start - perhaps the PF
                      Driver isn&#39;t up yet</div>
                    <div>[ 2476.296917] Unable to start - perhaps the PF
                      Driver isn&#39;t up yet</div>
                  </div>
                  <div><br>
                  </div>
                  <div><br>
                  </div>
                  <div>Any thoughts on what could be wrong? I have been
                    struggling with this for quite some time</div>
                  <div>and would really appreciate your thoughts on it.</di=
v>
                  <div><br>
                  </div>
                  <div>Thanks,=A0</div>
                  <span><font color=3D"#888888">
                      <div>Ashok</div>
                      <div><br>
                      </div>
                      <div><br>
                      </div>
                      <div><br>
                      </div>
                      <div><br>
                      </div>
                      <div><br>
                      </div>
                    </font></span></div>
                <br>
              </blockquote>
              <br>
            </div>
            <span><font color=3D"#888888">
                <pre cols=3D"72">--=20
Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
T: <a href=3D"tel:%2B44%20%280%291223%20225%20900" value=3D"+441223225900" =
target=3D"_blank">+44 (0)1223 225 900</a>, <a href=3D"http://www.citrix.com=
" target=3D"_blank">http://www.citrix.com</a></pre>
              </font></span></div>
          <br>
          _______________________________________________<br>
          Xen-devel mailing list<br>
          <a href=3D"mailto:Xen-devel@lists.xen.org" target=3D"_blank">Xen-=
devel@lists.xen.org</a><br>
          <a href=3D"http://lists.xen.org/xen-devel" target=3D"_blank">http=
://lists.xen.org/xen-devel</a><br>
          <br>
        </blockquote>
      </div>
      <br>
    </blockquote>
    <br>
    <pre cols=3D"72">--=20
Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
T: <a href=3D"tel:%2B44%20%280%291223%20225%20900" value=3D"+441223225900" =
target=3D"_blank">+44 (0)1223 225 900</a>, <a href=3D"http://www.citrix.com=
" target=3D"_blank">http://www.citrix.com</a></pre>
  </div></div></div>

</blockquote></div><br>

--e89a8fb1ffc2a69dac04c956ac5c--


--===============3163611272199496851==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============3163611272199496851==--


From xen-devel-bounces@lists.xen.org Mon Sep 10 10:47:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Sep 2012 10: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 1TB1W1-0002EP-Mo; Mon, 10 Sep 2012 10:46:53 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ashok.anand@gmail.com>) id 1TB1Vz-0002EF-Kp
	for xen-devel@lists.xen.org; Mon, 10 Sep 2012 10:46:52 +0000
Received: from [85.158.138.51:27760] by server-4.bemta-3.messagelabs.com id
	FB/B3-24831-A15CD405; Mon, 10 Sep 2012 10:46:50 +0000
X-Env-Sender: ashok.anand@gmail.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1347274008!29169578!1
X-Originating-IP: [209.85.214.173]
X-SpamReason: No, hits=0.9 required=7.0 tests=BODY_RANDOM_LONG,
	HTML_50_60, HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14, RCVD_BY_IP,
	spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 965 invoked from network); 10 Sep 2012 10:46:49 -0000
Received: from mail-ob0-f173.google.com (HELO mail-ob0-f173.google.com)
	(209.85.214.173)
	by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Sep 2012 10:46:49 -0000
Received: by obbta14 with SMTP id ta14so3560923obb.32
	for <xen-devel@lists.xen.org>; Mon, 10 Sep 2012 03:46:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=kmfy658GdHsnmYAHmK/pyOwfFRJ7B5K54VG+2WEcOSM=;
	b=sJgyr5rd27OWHneF+oRP75Rv/5bLYxyI/8IZsfMkPDsmraJCHI1R01elYUAZnUaVUX
	d8ybvz/NgMXSA5yWGS+YCXQBvfmkYePW//sDbnjp4c9uBQFkU/dJFjQ93IiEF8u9z2Rf
	VgzCvLBRshi+iVqf0q82r2qH/ZLNDjwVAsiiWzjGMBsKwPIQUWc8Df5ruIvVCT2hDNsT
	dq5lLzF8/c/0y55ddH4RKxGvg/XMQqWmzXP5rd9IODhybKhWk5oM3Rt0F+bBm/gCR/C2
	Ko8A5d3RCQmls9agnVg3cb4Fmo4b4nnC53TYiqLJsoT0bpXIO/YrpMpDRrjjilNMQNsu
	a7eQ==
MIME-Version: 1.0
Received: by 10.60.0.161 with SMTP id 1mr13834982oef.83.1347274007813; Mon, 10
	Sep 2012 03:46:47 -0700 (PDT)
Received: by 10.182.32.102 with HTTP; Mon, 10 Sep 2012 03:46:47 -0700 (PDT)
In-Reply-To: <504DC334.6060201@citrix.com>
References: <CALQsBOWDE_KqpntG8WJo86omLP3+rhQ0LDMW5vB752ubpF1FAA@mail.gmail.com>
	<CALQsBOXFVM+cdhmke5JDJmns2XUpHjyDOVN6R5qrrY9nTOR3SQ@mail.gmail.com>
	<504DC059.4070003@citrix.com>
	<CALQsBOV0EsUY+eYWqtL-FVuTOWOk_MLPnC2CYYPhNU9t=sxt9g@mail.gmail.com>
	<504DC334.6060201@citrix.com>
Date: Mon, 10 Sep 2012 16:16:47 +0530
Message-ID: <CALQsBOXqT39-ZkOuTT-c58qUW6dihuXWfUi08YzjmgJzaW9YAA@mail.gmail.com>
From: Ashok Anand <ashok.anand@gmail.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] issue using SRIOV "Unable to start - perhaps the PF
 driver is not up yet", while PF driver is actually up
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============3163611272199496851=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============3163611272199496851==
Content-Type: multipart/alternative; boundary=e89a8fb1ffc2a69dac04c956ac5c

--e89a8fb1ffc2a69dac04c956ac5c
Content-Type: text/plain; charset=ISO-8859-1

I am passing virtual functions. please see below ,based on the message from
lspci.

> What does lspci -vv for the physical function say?
>
> As for the physical function: it is unsafe to pass physical functions to a
> non-trusted guest, as the physical function has complete control over the
> all the virtual functions, even if they are passed through to other
> guests.  For that reason, the physical function should remain in dom0 (or a
> device driver domain if you are going for disaggregation).
>

here is the message lspci -vv | grep Eth gives me,

0f:00.0 Ethernet controller: Intel Corporation 82599EB 10-Gigabit SFI/SFP+
Network Connection (rev 01)
Subsystem: Intel Corporation Ethernet Server Adapter X520-2
0f:00.1 Ethernet controller: Intel Corporation 82599EB 10-Gigabit SFI/SFP+
Network Connection (rev 01)
Subsystem: Intel Corporation Ethernet Server Adapter X520-2
0f:10.0 Ethernet controller: Intel Corporation 82599 Ethernet Controller
Virtual Function (rev 01)
0f:10.2 Ethernet controller: Intel Corporation 82599 Ethernet Controller
Virtual Function (rev 01)
0f:10.4 Ethernet controller: Intel Corporation 82599 Ethernet Controller
Virtual Function (rev 01)
0f:10.6 Ethernet controller: Intel Corporation 82599 Ethernet Controller
Virtual Function (rev 01)
0f:11.0 Ethernet controller: Intel Corporation 82599 Ethernet Controller
Virtual Function (rev 01)
0f:11.2 Ethernet controller: Intel Corporation 82599 Ethernet Controller
Virtual Function (rev 01)
0f:11.4 Ethernet controller: Intel Corporation 82599 Ethernet Controller
Virtual Function (rev 01)
0f:11.6 Ethernet controller: Intel Corporation 82599 Ethernet Controller
Virtual Function (rev 01)

Here, 0f:00.0 is the physical function, while 0f:10.0 and others are
virtual functions -- so I am attaching virtual functions.




>
>
>
>
>>
>>
>>  i attach 0f:10.0 to a domU ubuntu machine, xm pci-attach ubuntu 0f:10.0
>>
>>  on my dom0 machine, i can ping other machine using eth2, (implying PF
>> on eth2 is active)
>>
>>  on my domU machine, when i attach the virtual function, i get the
>> following messages
>>
>>  [ 2282.688356 <%5B%202282.688356>] ixgbevf 0000:00:00.0: Xen PCI mapped
>> GSI0 to IRQ28
>> [ 2282.688470 <%5B%202282.688470>] ixgbevf 0000:00:00.0: setting latency
>> timer to 64
>> [ 2282.690187 <%5B%202282.690187>] ixgbevf 0000:00:00.0: PF still in
>> reset state, assigning new address
>>
>>  while PF on eth2 is  there and active, since i can ping other machine.
>>
>>  Now, when I try to bring up the VF interface on domU,
>>  i get the following error
>>
>>   2476.295582] Unable to start - perhaps the PF Driver isn't up yet
>> SIOCSIFFLAGS: Network is down
>> [ 2476.296917] Unable to start - perhaps the PF Driver isn't up yet
>>  SIOCSIFFLAGS: Network is down
>>
>>  and on dmesg on domU,
>>  [ 2476.295582] Unable to start - perhaps the PF Driver isn't up yet
>> [ 2476.296917] Unable to start - perhaps the PF Driver isn't up yet
>>
>>
>>  Any thoughts on what could be wrong? I have been struggling with this
>> for quite some time
>> and would really appreciate your thoughts on it.
>>
>>  Thanks,
>>  Ashok
>>
>>
>>
>>
>>
>>
>>
>>  --
>> 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
>>
>>
>
> --
> Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
> T: +44 (0)1223 225 900, http://www.citrix.com
>
>

--e89a8fb1ffc2a69dac04c956ac5c
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div class=3D"gmail_quote"><div><br></div><div>I am passing virtual functio=
ns. please see below ,based on the message from lspci.=A0</div><blockquote =
class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid=
;padding-left:1ex">
<div bgcolor=3D"#FFFFFF" text=3D"#000000">What does lspci -vv for the physi=
cal function say?<br>
    <br>
    As for the physical function: it is unsafe to pass physical
    functions to a non-trusted guest, as the physical function has
    complete control over the all the virtual functions, even if they
    are passed through to other guests.=A0 For that reason, the physical
    function should remain in dom0 (or a device driver domain if you are
    going for disaggregation).</div></blockquote><div><br></div><div>here i=
s the message lspci -vv | grep Eth gives me,=A0</div><div><br></div><div><d=
iv>0f:00.0 Ethernet controller: Intel Corporation 82599EB 10-Gigabit SFI/SF=
P+ Network Connection (rev 01)</div>
<div><span class=3D"Apple-tab-span" style=3D"white-space:pre">	</span>Subsy=
stem: Intel Corporation Ethernet Server Adapter X520-2</div><div>0f:00.1 Et=
hernet controller: Intel Corporation 82599EB 10-Gigabit SFI/SFP+ Network Co=
nnection (rev 01)</div>
<div><span class=3D"Apple-tab-span" style=3D"white-space:pre">	</span>Subsy=
stem: Intel Corporation Ethernet Server Adapter X520-2</div><div>0f:10.0 Et=
hernet controller: Intel Corporation 82599 Ethernet Controller Virtual Func=
tion (rev 01)</div>
<div>0f:10.2 Ethernet controller: Intel Corporation 82599 Ethernet Controll=
er Virtual Function (rev 01)</div><div>0f:10.4 Ethernet controller: Intel C=
orporation 82599 Ethernet Controller Virtual Function (rev 01)</div><div>
0f:10.6 Ethernet controller: Intel Corporation 82599 Ethernet Controller Vi=
rtual Function (rev 01)</div><div>0f:11.0 Ethernet controller: Intel Corpor=
ation 82599 Ethernet Controller Virtual Function (rev 01)</div><div>0f:11.2=
 Ethernet controller: Intel Corporation 82599 Ethernet Controller Virtual F=
unction (rev 01)</div>
<div>0f:11.4 Ethernet controller: Intel Corporation 82599 Ethernet Controll=
er Virtual Function (rev 01)</div><div>0f:11.6 Ethernet controller: Intel C=
orporation 82599 Ethernet Controller Virtual Function (rev 01)</div></div>
<div><br></div><div>Here, 0f:00.0 is the physical function, while 0f:10.0 a=
nd others are virtual functions -- so I am attaching virtual functions.=A0<=
/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 bgcolor=3D"#FFFFFF" text=3D"#000000"><div><div class=3D"h5"><br>
    <br>
    <blockquote type=3D"cite">
      <div class=3D"gmail_quote">
        <div><br>
        </div>
        <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border=
-left:1px #ccc solid;padding-left:1ex">
          <div bgcolor=3D"#FFFFFF" text=3D"#000000">
            <div><br>
              <br>
              <blockquote type=3D"cite">
                <div class=3D"gmail_quote">
                  <div><br>
                  </div>
                  <div>i attach 0f:10.0 to a domU ubuntu machine,=A0xm
                    pci-attach ubuntu 0f:10.0</div>
                  <div><br>
                  </div>
                  <div>on my dom0 machine, i can ping other machine
                    using eth2, (implying PF on eth2 is active)</div>
                  <div><br>
                  </div>
                  <div>on my domU machine, when i attach the virtual
                    function, i get the following messages</div>
                  <div><br>
                  </div>
                  <div>
                    <div><a href=3D"tel:%5B%202282.688356" value=3D"+122826=
88356" target=3D"_blank">[
                        2282.688356</a>] ixgbevf 0000:00:00.0: Xen PCI
                      mapped GSI0 to IRQ28</div>
                    <div><a href=3D"tel:%5B%202282.688470" value=3D"+122826=
88470" target=3D"_blank">[
                        2282.688470</a>] ixgbevf 0000:00:00.0: setting
                      latency timer to 64</div>
                    <div><a href=3D"tel:%5B%202282.690187" value=3D"+122826=
90187" target=3D"_blank">[
                        2282.690187</a>] ixgbevf 0000:00:00.0: PF still
                      in reset state, assigning new address</div>
                  </div>
                  <div><br>
                  </div>
                  <div>while PF on eth2 is =A0there and active, since i
                    can ping other machine.</div>
                  <div><br>
                  </div>
                  <div>Now, when I try to bring up the VF interface on
                    domU,=A0</div>
                  <div>=A0i get the following error</div>
                  <div> <br>
                  </div>
                  <div>
                    <div>=A02476.295582] Unable to start - perhaps the PF
                      Driver isn&#39;t up yet</div>
                    <div>SIOCSIFFLAGS: Network is down</div>
                    <div>[ 2476.296917] Unable to start - perhaps the PF
                      Driver isn&#39;t up yet</div>
                    <div> SIOCSIFFLAGS: Network is down</div>
                  </div>
                  <div><br>
                  </div>
                  <div>and on dmesg on domU,=A0</div>
                  <div>
                    <div>[ 2476.295582] Unable to start - perhaps the PF
                      Driver isn&#39;t up yet</div>
                    <div>[ 2476.296917] Unable to start - perhaps the PF
                      Driver isn&#39;t up yet</div>
                  </div>
                  <div><br>
                  </div>
                  <div><br>
                  </div>
                  <div>Any thoughts on what could be wrong? I have been
                    struggling with this for quite some time</div>
                  <div>and would really appreciate your thoughts on it.</di=
v>
                  <div><br>
                  </div>
                  <div>Thanks,=A0</div>
                  <span><font color=3D"#888888">
                      <div>Ashok</div>
                      <div><br>
                      </div>
                      <div><br>
                      </div>
                      <div><br>
                      </div>
                      <div><br>
                      </div>
                      <div><br>
                      </div>
                    </font></span></div>
                <br>
              </blockquote>
              <br>
            </div>
            <span><font color=3D"#888888">
                <pre cols=3D"72">--=20
Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
T: <a href=3D"tel:%2B44%20%280%291223%20225%20900" value=3D"+441223225900" =
target=3D"_blank">+44 (0)1223 225 900</a>, <a href=3D"http://www.citrix.com=
" target=3D"_blank">http://www.citrix.com</a></pre>
              </font></span></div>
          <br>
          _______________________________________________<br>
          Xen-devel mailing list<br>
          <a href=3D"mailto:Xen-devel@lists.xen.org" target=3D"_blank">Xen-=
devel@lists.xen.org</a><br>
          <a href=3D"http://lists.xen.org/xen-devel" target=3D"_blank">http=
://lists.xen.org/xen-devel</a><br>
          <br>
        </blockquote>
      </div>
      <br>
    </blockquote>
    <br>
    <pre cols=3D"72">--=20
Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
T: <a href=3D"tel:%2B44%20%280%291223%20225%20900" value=3D"+441223225900" =
target=3D"_blank">+44 (0)1223 225 900</a>, <a href=3D"http://www.citrix.com=
" target=3D"_blank">http://www.citrix.com</a></pre>
  </div></div></div>

</blockquote></div><br>

--e89a8fb1ffc2a69dac04c956ac5c--


--===============3163611272199496851==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============3163611272199496851==--


From xen-devel-bounces@lists.xen.org Mon Sep 10 11:21:55 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Sep 2012 11: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 1TB23c-0002sI-Tt; Mon, 10 Sep 2012 11:21:36 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dan.carpenter@oracle.com>) id 1TB23b-0002sD-Dp
	for xen-devel@lists.xensource.com; Mon, 10 Sep 2012 11:21:35 +0000
Received: from [85.158.139.83:19789] by server-10.bemta-5.messagelabs.com id
	20/E2-10969-E3DCD405; Mon, 10 Sep 2012 11:21:34 +0000
X-Env-Sender: dan.carpenter@oracle.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1347276072!25633277!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDc0NzYwMw==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23319 invoked from network); 10 Sep 2012 11:21:15 -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; 10 Sep 2012 11:21:15 -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 q8ABL19Y028782
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 10 Sep 2012 11:21:02 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
	q8ABL0hl005159
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 10 Sep 2012 11:21:00 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
	q8ABKwTR027920; Mon, 10 Sep 2012 06:20:58 -0500
Received: from mwanda (/41.212.103.53) by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 10 Sep 2012 04:20:57 -0700
Date: Mon, 10 Sep 2012 14:20:54 +0300
From: Dan Carpenter <dan.carpenter@oracle.com>
To: David Vrabel <david.vrabel@citrix.com>
Message-ID: <20120910112053.GW19410@mwanda>
References: <20120908095208.GA608@elgon.mountain> <504DC25F.7000508@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <504DC25F.7000508@citrix.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,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Andres Lagar-Cavilla <andreslc@gridcentric.ca>,
	kernel-janitors@vger.kernel.org, virtualization@lists.linux-foundation.org
Subject: Re: [Xen-devel] [patch 1/3] xen/privcmd: check for integer overflow
 in	ioctl
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Sep 10, 2012 at 11:35:11AM +0100, David Vrabel wrote:
> On 08/09/12 10:52, Dan Carpenter wrote:
> > If m.num is too large then the "m.num * sizeof(*m.arr)" multiplication
> > could overflow and the access_ok() check wouldn't test the right size.
> 
> m.num is range checked later on so it doesn't matter that the
> access_ok() checks might be wrong.  A bit subtle, perhaps.
> 

Yeah.  It's too subtle for my static checker but not so subtle for
a human being.  Laziness on my part.

Please drop this patch.

regards,
dan carpenter


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 10 11:21:55 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Sep 2012 11: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 1TB23c-0002sI-Tt; Mon, 10 Sep 2012 11:21:36 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dan.carpenter@oracle.com>) id 1TB23b-0002sD-Dp
	for xen-devel@lists.xensource.com; Mon, 10 Sep 2012 11:21:35 +0000
Received: from [85.158.139.83:19789] by server-10.bemta-5.messagelabs.com id
	20/E2-10969-E3DCD405; Mon, 10 Sep 2012 11:21:34 +0000
X-Env-Sender: dan.carpenter@oracle.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1347276072!25633277!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDc0NzYwMw==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23319 invoked from network); 10 Sep 2012 11:21:15 -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; 10 Sep 2012 11:21:15 -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 q8ABL19Y028782
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 10 Sep 2012 11:21:02 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
	q8ABL0hl005159
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 10 Sep 2012 11:21:00 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
	q8ABKwTR027920; Mon, 10 Sep 2012 06:20:58 -0500
Received: from mwanda (/41.212.103.53) by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 10 Sep 2012 04:20:57 -0700
Date: Mon, 10 Sep 2012 14:20:54 +0300
From: Dan Carpenter <dan.carpenter@oracle.com>
To: David Vrabel <david.vrabel@citrix.com>
Message-ID: <20120910112053.GW19410@mwanda>
References: <20120908095208.GA608@elgon.mountain> <504DC25F.7000508@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <504DC25F.7000508@citrix.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,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Andres Lagar-Cavilla <andreslc@gridcentric.ca>,
	kernel-janitors@vger.kernel.org, virtualization@lists.linux-foundation.org
Subject: Re: [Xen-devel] [patch 1/3] xen/privcmd: check for integer overflow
 in	ioctl
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Sep 10, 2012 at 11:35:11AM +0100, David Vrabel wrote:
> On 08/09/12 10:52, Dan Carpenter wrote:
> > If m.num is too large then the "m.num * sizeof(*m.arr)" multiplication
> > could overflow and the access_ok() check wouldn't test the right size.
> 
> m.num is range checked later on so it doesn't matter that the
> access_ok() checks might be wrong.  A bit subtle, perhaps.
> 

Yeah.  It's too subtle for my static checker but not so subtle for
a human being.  Laziness on my part.

Please drop this patch.

regards,
dan carpenter


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 10 11:58:42 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Sep 2012 11:58: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 1TB2dF-00038a-6l; Mon, 10 Sep 2012 11:58:25 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <SRS0=Ppt6=HJ=oracle.com=daniel.kiper@net-space.pl>)
	id 1TB2dD-00037n-PV
	for xen-devel@lists.xensource.com; Mon, 10 Sep 2012 11:58:23 +0000
Received: from [85.158.138.51:27248] by server-5.bemta-3.messagelabs.com id
	4F/42-13133-ED5DD405; Mon, 10 Sep 2012 11:58:22 +0000
X-Env-Sender: SRS0=Ppt6=HJ=oracle.com=daniel.kiper@net-space.pl
X-Msg-Ref: server-12.tower-174.messagelabs.com!1347278300!21748053!5
X-Originating-IP: [89.174.63.77]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16399 invoked from network); 10 Sep 2012 11:58:22 -0000
Received: from router-fw.net-space.pl (HELO router-fw.net-space.pl)
	(89.174.63.77)
	by server-12.tower-174.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 10 Sep 2012 11:58:22 -0000
Received: from dev-00.local.net-space.pl ([192.168.1.5]:48176 "EHLO
	localhost.localdomain" TLS-CIPHER: <none>)
	by router-fw-old.local.net-space.pl with ESMTP id S1621606Ab2IJL5w
	(ORCPT <rfc822;xen-devel@lists.xensource.com>);
	Mon, 10 Sep 2012 13:57:52 +0200
From: Daniel Kiper <daniel.kiper@oracle.com>
To: konrad.wilk@oracle.com, andrew.cooper3@citrix.com, olaf@aepfle.de,
	jbeulich@suse.com, ptesarik@suse.cz, kexec@lists.infradead.org,
	xen-devel@lists.xensource.com
Date: Mon, 10 Sep 2012 13:57:49 +0200
Message-Id: <1347278271-5211-6-git-send-email-daniel.kiper@oracle.com>
X-Mailer: git-send-email 1.5.6.5
In-Reply-To: <1347278271-5211-5-git-send-email-daniel.kiper@oracle.com>
References: <1347278271-5211-1-git-send-email-daniel.kiper@oracle.com>
	<1347278271-5211-2-git-send-email-daniel.kiper@oracle.com>
	<1347278271-5211-3-git-send-email-daniel.kiper@oracle.com>
	<1347278271-5211-4-git-send-email-daniel.kiper@oracle.com>
	<1347278271-5211-5-git-send-email-daniel.kiper@oracle.com>
X-Bogosity: No, spamicity=0.046968
Subject: [Xen-devel] [PATCH 5/7] kexec: Get backup area start address and
	size directly from mem_range
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Get backup area start address and size directly from mem_range.
Under Xen /proc/iomem contains invalid values.

Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
---
 kexec/arch/i386/crashdump-x86.c |   55 +++++++++++++-------------------------
 1 files changed, 19 insertions(+), 36 deletions(-)

diff --git a/kexec/arch/i386/crashdump-x86.c b/kexec/arch/i386/crashdump-x86.c
index 77a1329..56ef59e 100644
--- a/kexec/arch/i386/crashdump-x86.c
+++ b/kexec/arch/i386/crashdump-x86.c
@@ -667,44 +667,28 @@ static int cmdline_add_memmap_acpi(char *cmdline, unsigned long start,
 	return 0;
 }
 
-static void get_backup_area(unsigned long *start, unsigned long *end)
+static void get_backup_area(struct kexec_info *info,
+				struct memory_range *range, int ranges)
 {
-	const char *iomem = proc_iomem();
-	char line[MAX_LINE];
-	FILE *fp;
+	int i;
 
-	fp = fopen(iomem, "r");
-	if (!fp) {
-		fprintf(stderr, "Cannot open %s: %s\n",
-			iomem, strerror(errno));
-		return;
-	}
+	/* Look for first 640 KiB RAM region. */
+	for (i = 0; i < ranges; ++i) {
+		if (range[i].type != RANGE_RAM || range[i].end > 0xa0000)
+			continue;
 
-	while(fgets(line, sizeof(line), fp) != 0) {
-		char *str;
-		int count, consumed;
-		unsigned long mstart, mend;
+		info->backup_src_start = range[i].start;
+		info->backup_src_size = range[i].end - range[i].start + 1;
 
-		count = sscanf(line, "%lx-%lx : %n",
-			&mstart, &mend, &consumed);
-		if (count != 2)
-			continue;
-		str = line + consumed;
-		dbgprintf("%016lx-%016lx : %s",
-			mstart, mend, str);
-
-		/* Hopefully there is only one RAM region in the first 640K */
-		if (memcmp(str, "System RAM\n", 11) == 0 && mend <= 0xa0000 ) {
-			dbgprintf("%s: %016lx-%016lx : %s", __func__, mstart, mend, str);
-			*start = mstart;
-			*end = mend;
-			fclose(fp);
-			return;
-		}
+		dbgprintf("%s: %016llx-%016llx : System RAM\n", __func__,
+						range[i].start, range[i].end);
+
+		return;
 	}
-	*start = BACKUP_SRC_START;
-	*end = BACKUP_SRC_END;
-	fclose(fp);
+
+	/* First 640 KiB RAM region not found. Assume defaults. */
+	info->backup_src_start = BACKUP_SRC_START;
+	info->backup_src_size = BACKUP_SRC_END - BACKUP_SRC_START + 1;
 }
 
 /* Loads additional segments in case of a panic kernel is being loaded.
@@ -720,15 +704,12 @@ int load_crashdump_segments(struct kexec_info *info, char* mod_cmdline,
 	struct memory_range *mem_range, *memmap_p;
 	struct crash_elf_info elf_info;
 	unsigned kexec_arch;
-	unsigned long tmp_backup_end = 0;
 
 	memset(&elf_info, 0x0, sizeof(elf_info));
 
 	/* Constant parts of the elf_info */
 	memset(&elf_info, 0, sizeof(elf_info));
 	elf_info.data             = ELFDATA2LSB;
-	get_backup_area(&info->backup_src_start, &tmp_backup_end);
-	info->backup_src_size = tmp_backup_end - info->backup_src_start + 1;
 
 	/* Get the architecture of the running kernel */
 	kexec_arch = info->kexec_flags & KEXEC_ARCH_MASK;
@@ -756,6 +737,8 @@ int load_crashdump_segments(struct kexec_info *info, char* mod_cmdline,
 				    elf_info.lowmem_limit) < 0)
 		return -1;
 
+	get_backup_area(info, mem_range, nr_ranges);
+
 	/*
 	 * if the core type has not been set on command line, set it here
 	 * automatically
-- 
1.5.6.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 10 11:58:42 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Sep 2012 11:58: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 1TB2dF-00038a-6l; Mon, 10 Sep 2012 11:58:25 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <SRS0=Ppt6=HJ=oracle.com=daniel.kiper@net-space.pl>)
	id 1TB2dD-00037n-PV
	for xen-devel@lists.xensource.com; Mon, 10 Sep 2012 11:58:23 +0000
Received: from [85.158.138.51:27248] by server-5.bemta-3.messagelabs.com id
	4F/42-13133-ED5DD405; Mon, 10 Sep 2012 11:58:22 +0000
X-Env-Sender: SRS0=Ppt6=HJ=oracle.com=daniel.kiper@net-space.pl
X-Msg-Ref: server-12.tower-174.messagelabs.com!1347278300!21748053!5
X-Originating-IP: [89.174.63.77]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16399 invoked from network); 10 Sep 2012 11:58:22 -0000
Received: from router-fw.net-space.pl (HELO router-fw.net-space.pl)
	(89.174.63.77)
	by server-12.tower-174.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 10 Sep 2012 11:58:22 -0000
Received: from dev-00.local.net-space.pl ([192.168.1.5]:48176 "EHLO
	localhost.localdomain" TLS-CIPHER: <none>)
	by router-fw-old.local.net-space.pl with ESMTP id S1621606Ab2IJL5w
	(ORCPT <rfc822;xen-devel@lists.xensource.com>);
	Mon, 10 Sep 2012 13:57:52 +0200
From: Daniel Kiper <daniel.kiper@oracle.com>
To: konrad.wilk@oracle.com, andrew.cooper3@citrix.com, olaf@aepfle.de,
	jbeulich@suse.com, ptesarik@suse.cz, kexec@lists.infradead.org,
	xen-devel@lists.xensource.com
Date: Mon, 10 Sep 2012 13:57:49 +0200
Message-Id: <1347278271-5211-6-git-send-email-daniel.kiper@oracle.com>
X-Mailer: git-send-email 1.5.6.5
In-Reply-To: <1347278271-5211-5-git-send-email-daniel.kiper@oracle.com>
References: <1347278271-5211-1-git-send-email-daniel.kiper@oracle.com>
	<1347278271-5211-2-git-send-email-daniel.kiper@oracle.com>
	<1347278271-5211-3-git-send-email-daniel.kiper@oracle.com>
	<1347278271-5211-4-git-send-email-daniel.kiper@oracle.com>
	<1347278271-5211-5-git-send-email-daniel.kiper@oracle.com>
X-Bogosity: No, spamicity=0.046968
Subject: [Xen-devel] [PATCH 5/7] kexec: Get backup area start address and
	size directly from mem_range
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Get backup area start address and size directly from mem_range.
Under Xen /proc/iomem contains invalid values.

Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
---
 kexec/arch/i386/crashdump-x86.c |   55 +++++++++++++-------------------------
 1 files changed, 19 insertions(+), 36 deletions(-)

diff --git a/kexec/arch/i386/crashdump-x86.c b/kexec/arch/i386/crashdump-x86.c
index 77a1329..56ef59e 100644
--- a/kexec/arch/i386/crashdump-x86.c
+++ b/kexec/arch/i386/crashdump-x86.c
@@ -667,44 +667,28 @@ static int cmdline_add_memmap_acpi(char *cmdline, unsigned long start,
 	return 0;
 }
 
-static void get_backup_area(unsigned long *start, unsigned long *end)
+static void get_backup_area(struct kexec_info *info,
+				struct memory_range *range, int ranges)
 {
-	const char *iomem = proc_iomem();
-	char line[MAX_LINE];
-	FILE *fp;
+	int i;
 
-	fp = fopen(iomem, "r");
-	if (!fp) {
-		fprintf(stderr, "Cannot open %s: %s\n",
-			iomem, strerror(errno));
-		return;
-	}
+	/* Look for first 640 KiB RAM region. */
+	for (i = 0; i < ranges; ++i) {
+		if (range[i].type != RANGE_RAM || range[i].end > 0xa0000)
+			continue;
 
-	while(fgets(line, sizeof(line), fp) != 0) {
-		char *str;
-		int count, consumed;
-		unsigned long mstart, mend;
+		info->backup_src_start = range[i].start;
+		info->backup_src_size = range[i].end - range[i].start + 1;
 
-		count = sscanf(line, "%lx-%lx : %n",
-			&mstart, &mend, &consumed);
-		if (count != 2)
-			continue;
-		str = line + consumed;
-		dbgprintf("%016lx-%016lx : %s",
-			mstart, mend, str);
-
-		/* Hopefully there is only one RAM region in the first 640K */
-		if (memcmp(str, "System RAM\n", 11) == 0 && mend <= 0xa0000 ) {
-			dbgprintf("%s: %016lx-%016lx : %s", __func__, mstart, mend, str);
-			*start = mstart;
-			*end = mend;
-			fclose(fp);
-			return;
-		}
+		dbgprintf("%s: %016llx-%016llx : System RAM\n", __func__,
+						range[i].start, range[i].end);
+
+		return;
 	}
-	*start = BACKUP_SRC_START;
-	*end = BACKUP_SRC_END;
-	fclose(fp);
+
+	/* First 640 KiB RAM region not found. Assume defaults. */
+	info->backup_src_start = BACKUP_SRC_START;
+	info->backup_src_size = BACKUP_SRC_END - BACKUP_SRC_START + 1;
 }
 
 /* Loads additional segments in case of a panic kernel is being loaded.
@@ -720,15 +704,12 @@ int load_crashdump_segments(struct kexec_info *info, char* mod_cmdline,
 	struct memory_range *mem_range, *memmap_p;
 	struct crash_elf_info elf_info;
 	unsigned kexec_arch;
-	unsigned long tmp_backup_end = 0;
 
 	memset(&elf_info, 0x0, sizeof(elf_info));
 
 	/* Constant parts of the elf_info */
 	memset(&elf_info, 0, sizeof(elf_info));
 	elf_info.data             = ELFDATA2LSB;
-	get_backup_area(&info->backup_src_start, &tmp_backup_end);
-	info->backup_src_size = tmp_backup_end - info->backup_src_start + 1;
 
 	/* Get the architecture of the running kernel */
 	kexec_arch = info->kexec_flags & KEXEC_ARCH_MASK;
@@ -756,6 +737,8 @@ int load_crashdump_segments(struct kexec_info *info, char* mod_cmdline,
 				    elf_info.lowmem_limit) < 0)
 		return -1;
 
+	get_backup_area(info, mem_range, nr_ranges);
+
 	/*
 	 * if the core type has not been set on command line, set it here
 	 * automatically
-- 
1.5.6.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 10 11:58:42 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Sep 2012 11:58: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 1TB2dH-00039a-U6; Mon, 10 Sep 2012 11:58:27 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <SRS0=Ppt6=HJ=oracle.com=daniel.kiper@net-space.pl>)
	id 1TB2dG-00038l-6A
	for xen-devel@lists.xensource.com; Mon, 10 Sep 2012 11:58:26 +0000
Received: from [85.158.138.51:49341] by server-8.bemta-3.messagelabs.com id
	9C/3F-24700-ED5DD405; Mon, 10 Sep 2012 11:58:22 +0000
X-Env-Sender: SRS0=Ppt6=HJ=oracle.com=daniel.kiper@net-space.pl
X-Msg-Ref: server-12.tower-174.messagelabs.com!1347278300!21748053!3
X-Originating-IP: [89.174.63.77]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16307 invoked from network); 10 Sep 2012 11:58:21 -0000
Received: from router-fw.net-space.pl (HELO router-fw.net-space.pl)
	(89.174.63.77)
	by server-12.tower-174.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 10 Sep 2012 11:58:21 -0000
Received: from dev-00.local.net-space.pl ([192.168.1.5]:48176 "EHLO
	localhost.localdomain" TLS-CIPHER: <none>)
	by router-fw-old.local.net-space.pl with ESMTP id S1591756Ab2IJL5w
	(ORCPT <rfc822;xen-devel@lists.xensource.com>);
	Mon, 10 Sep 2012 13:57:52 +0200
From: Daniel Kiper <daniel.kiper@oracle.com>
To: konrad.wilk@oracle.com, andrew.cooper3@citrix.com, olaf@aepfle.de,
	jbeulich@suse.com, ptesarik@suse.cz, kexec@lists.infradead.org,
	xen-devel@lists.xensource.com
Date: Mon, 10 Sep 2012 13:57:44 +0200
Message-Id: <1347278271-5211-1-git-send-email-daniel.kiper@oracle.com>
X-Mailer: git-send-email 1.5.6.5
X-Bogosity: No, spamicity=0.010008
Subject: [Xen-devel] [PATCH 0/7] kdump: Xen 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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi,

Here I am sending Xen kdump fixes.

Daniel

Daniel Kiper (7):
      kexec: Define some constants and structures conditionally
      xen: Rename e820_to_kexec_type() to xen_e820_to_kexec_type() and export it
      kexec: Move crash kernel area placement and size detection to is_crashkernel_mem_reserved()
      kexec: Add segregate_lowmem_region()
      kexec: Get backup area start address and size directly from mem_range
      kexec: Move crash memory ranges logging
      xen: Fix Xen kdump support

 include/x86/x86-linux.h            |    7 +-
 kexec/arch/i386/crashdump-x86.c    |  322 +++++++++++++++++++++++++++--------
 kexec/arch/i386/kexec-x86-common.c |    6 +-
 kexec/arch/i386/kexec-x86.h        |    2 +
 4 files changed, 259 insertions(+), 78 deletions(-)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 10 11:58:42 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Sep 2012 11:58: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 1TB2dH-00039a-U6; Mon, 10 Sep 2012 11:58:27 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <SRS0=Ppt6=HJ=oracle.com=daniel.kiper@net-space.pl>)
	id 1TB2dG-00038l-6A
	for xen-devel@lists.xensource.com; Mon, 10 Sep 2012 11:58:26 +0000
Received: from [85.158.138.51:49341] by server-8.bemta-3.messagelabs.com id
	9C/3F-24700-ED5DD405; Mon, 10 Sep 2012 11:58:22 +0000
X-Env-Sender: SRS0=Ppt6=HJ=oracle.com=daniel.kiper@net-space.pl
X-Msg-Ref: server-12.tower-174.messagelabs.com!1347278300!21748053!3
X-Originating-IP: [89.174.63.77]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16307 invoked from network); 10 Sep 2012 11:58:21 -0000
Received: from router-fw.net-space.pl (HELO router-fw.net-space.pl)
	(89.174.63.77)
	by server-12.tower-174.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 10 Sep 2012 11:58:21 -0000
Received: from dev-00.local.net-space.pl ([192.168.1.5]:48176 "EHLO
	localhost.localdomain" TLS-CIPHER: <none>)
	by router-fw-old.local.net-space.pl with ESMTP id S1591756Ab2IJL5w
	(ORCPT <rfc822;xen-devel@lists.xensource.com>);
	Mon, 10 Sep 2012 13:57:52 +0200
From: Daniel Kiper <daniel.kiper@oracle.com>
To: konrad.wilk@oracle.com, andrew.cooper3@citrix.com, olaf@aepfle.de,
	jbeulich@suse.com, ptesarik@suse.cz, kexec@lists.infradead.org,
	xen-devel@lists.xensource.com
Date: Mon, 10 Sep 2012 13:57:44 +0200
Message-Id: <1347278271-5211-1-git-send-email-daniel.kiper@oracle.com>
X-Mailer: git-send-email 1.5.6.5
X-Bogosity: No, spamicity=0.010008
Subject: [Xen-devel] [PATCH 0/7] kdump: Xen 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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi,

Here I am sending Xen kdump fixes.

Daniel

Daniel Kiper (7):
      kexec: Define some constants and structures conditionally
      xen: Rename e820_to_kexec_type() to xen_e820_to_kexec_type() and export it
      kexec: Move crash kernel area placement and size detection to is_crashkernel_mem_reserved()
      kexec: Add segregate_lowmem_region()
      kexec: Get backup area start address and size directly from mem_range
      kexec: Move crash memory ranges logging
      xen: Fix Xen kdump support

 include/x86/x86-linux.h            |    7 +-
 kexec/arch/i386/crashdump-x86.c    |  322 +++++++++++++++++++++++++++--------
 kexec/arch/i386/kexec-x86-common.c |    6 +-
 kexec/arch/i386/kexec-x86.h        |    2 +
 4 files changed, 259 insertions(+), 78 deletions(-)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 10 11:58:42 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Sep 2012 11:58: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 1TB2dH-00039F-BX; Mon, 10 Sep 2012 11:58:27 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <SRS0=Ppt6=HJ=oracle.com=daniel.kiper@net-space.pl>)
	id 1TB2dE-000384-Mp
	for xen-devel@lists.xensource.com; Mon, 10 Sep 2012 11:58:24 +0000
Received: from [85.158.138.51:49449] by server-7.bemta-3.messagelabs.com id
	D4/BD-32000-FD5DD405; Mon, 10 Sep 2012 11:58:23 +0000
X-Env-Sender: SRS0=Ppt6=HJ=oracle.com=daniel.kiper@net-space.pl
X-Msg-Ref: server-12.tower-174.messagelabs.com!1347278300!21748053!6
X-Originating-IP: [89.174.63.77]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16430 invoked from network); 10 Sep 2012 11:58:22 -0000
Received: from router-fw.net-space.pl (HELO router-fw.net-space.pl)
	(89.174.63.77)
	by server-12.tower-174.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 10 Sep 2012 11:58:22 -0000
Received: from dev-00.local.net-space.pl ([192.168.1.5]:48176 "EHLO
	localhost.localdomain" TLS-CIPHER: <none>)
	by router-fw-old.local.net-space.pl with ESMTP id S1621607Ab2IJL5w
	(ORCPT <rfc822;xen-devel@lists.xensource.com>);
	Mon, 10 Sep 2012 13:57:52 +0200
From: Daniel Kiper <daniel.kiper@oracle.com>
To: konrad.wilk@oracle.com, andrew.cooper3@citrix.com, olaf@aepfle.de,
	jbeulich@suse.com, ptesarik@suse.cz, kexec@lists.infradead.org,
	xen-devel@lists.xensource.com
Date: Mon, 10 Sep 2012 13:57:50 +0200
Message-Id: <1347278271-5211-7-git-send-email-daniel.kiper@oracle.com>
X-Mailer: git-send-email 1.5.6.5
In-Reply-To: <1347278271-5211-6-git-send-email-daniel.kiper@oracle.com>
References: <1347278271-5211-1-git-send-email-daniel.kiper@oracle.com>
	<1347278271-5211-2-git-send-email-daniel.kiper@oracle.com>
	<1347278271-5211-3-git-send-email-daniel.kiper@oracle.com>
	<1347278271-5211-4-git-send-email-daniel.kiper@oracle.com>
	<1347278271-5211-5-git-send-email-daniel.kiper@oracle.com>
	<1347278271-5211-6-git-send-email-daniel.kiper@oracle.com>
X-Bogosity: No, spamicity=0.000704
Subject: [Xen-devel] [PATCH 6/7] kexec: Move crash memory ranges logging
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 crash memory ranges logging from get_crash_memory_ranges()
to load_crashdump_segments(). This solution will be used by
fixed Xen kdump support, too.

Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
---
 kexec/arch/i386/crashdump-x86.c |   13 +++++--------
 1 files changed, 5 insertions(+), 8 deletions(-)

diff --git a/kexec/arch/i386/crashdump-x86.c b/kexec/arch/i386/crashdump-x86.c
index 56ef59e..c6b9354 100644
--- a/kexec/arch/i386/crashdump-x86.c
+++ b/kexec/arch/i386/crashdump-x86.c
@@ -270,14 +270,6 @@ static int get_crash_memory_ranges(struct memory_range **range, int *ranges,
 	*range = crash_memory_range;
 	*ranges = memory_ranges;
 
-	int i;
-	dbgprintf("CRASH MEMORY RANGES\n");
-	for(i = 0; i < memory_ranges; i++) {
-		start = crash_memory_range[i].start;
-		end = crash_memory_range[i].end;
-		dbgprintf("%016Lx-%016Lx\n", start, end);
-	}
-
 	return 0;
 }
 
@@ -739,6 +731,11 @@ int load_crashdump_segments(struct kexec_info *info, char* mod_cmdline,
 
 	get_backup_area(info, mem_range, nr_ranges);
 
+	dbgprintf("CRASH MEMORY RANGES\n");
+
+	for(i = 0; i < nr_ranges; ++i)
+		dbgprintf("%016Lx-%016Lx\n", mem_range[i].start, mem_range[i].end);
+
 	/*
 	 * if the core type has not been set on command line, set it here
 	 * automatically
-- 
1.5.6.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 10 11:58:42 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Sep 2012 11:58: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 1TB2dH-00039F-BX; Mon, 10 Sep 2012 11:58:27 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <SRS0=Ppt6=HJ=oracle.com=daniel.kiper@net-space.pl>)
	id 1TB2dE-000384-Mp
	for xen-devel@lists.xensource.com; Mon, 10 Sep 2012 11:58:24 +0000
Received: from [85.158.138.51:49449] by server-7.bemta-3.messagelabs.com id
	D4/BD-32000-FD5DD405; Mon, 10 Sep 2012 11:58:23 +0000
X-Env-Sender: SRS0=Ppt6=HJ=oracle.com=daniel.kiper@net-space.pl
X-Msg-Ref: server-12.tower-174.messagelabs.com!1347278300!21748053!6
X-Originating-IP: [89.174.63.77]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16430 invoked from network); 10 Sep 2012 11:58:22 -0000
Received: from router-fw.net-space.pl (HELO router-fw.net-space.pl)
	(89.174.63.77)
	by server-12.tower-174.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 10 Sep 2012 11:58:22 -0000
Received: from dev-00.local.net-space.pl ([192.168.1.5]:48176 "EHLO
	localhost.localdomain" TLS-CIPHER: <none>)
	by router-fw-old.local.net-space.pl with ESMTP id S1621607Ab2IJL5w
	(ORCPT <rfc822;xen-devel@lists.xensource.com>);
	Mon, 10 Sep 2012 13:57:52 +0200
From: Daniel Kiper <daniel.kiper@oracle.com>
To: konrad.wilk@oracle.com, andrew.cooper3@citrix.com, olaf@aepfle.de,
	jbeulich@suse.com, ptesarik@suse.cz, kexec@lists.infradead.org,
	xen-devel@lists.xensource.com
Date: Mon, 10 Sep 2012 13:57:50 +0200
Message-Id: <1347278271-5211-7-git-send-email-daniel.kiper@oracle.com>
X-Mailer: git-send-email 1.5.6.5
In-Reply-To: <1347278271-5211-6-git-send-email-daniel.kiper@oracle.com>
References: <1347278271-5211-1-git-send-email-daniel.kiper@oracle.com>
	<1347278271-5211-2-git-send-email-daniel.kiper@oracle.com>
	<1347278271-5211-3-git-send-email-daniel.kiper@oracle.com>
	<1347278271-5211-4-git-send-email-daniel.kiper@oracle.com>
	<1347278271-5211-5-git-send-email-daniel.kiper@oracle.com>
	<1347278271-5211-6-git-send-email-daniel.kiper@oracle.com>
X-Bogosity: No, spamicity=0.000704
Subject: [Xen-devel] [PATCH 6/7] kexec: Move crash memory ranges logging
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 crash memory ranges logging from get_crash_memory_ranges()
to load_crashdump_segments(). This solution will be used by
fixed Xen kdump support, too.

Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
---
 kexec/arch/i386/crashdump-x86.c |   13 +++++--------
 1 files changed, 5 insertions(+), 8 deletions(-)

diff --git a/kexec/arch/i386/crashdump-x86.c b/kexec/arch/i386/crashdump-x86.c
index 56ef59e..c6b9354 100644
--- a/kexec/arch/i386/crashdump-x86.c
+++ b/kexec/arch/i386/crashdump-x86.c
@@ -270,14 +270,6 @@ static int get_crash_memory_ranges(struct memory_range **range, int *ranges,
 	*range = crash_memory_range;
 	*ranges = memory_ranges;
 
-	int i;
-	dbgprintf("CRASH MEMORY RANGES\n");
-	for(i = 0; i < memory_ranges; i++) {
-		start = crash_memory_range[i].start;
-		end = crash_memory_range[i].end;
-		dbgprintf("%016Lx-%016Lx\n", start, end);
-	}
-
 	return 0;
 }
 
@@ -739,6 +731,11 @@ int load_crashdump_segments(struct kexec_info *info, char* mod_cmdline,
 
 	get_backup_area(info, mem_range, nr_ranges);
 
+	dbgprintf("CRASH MEMORY RANGES\n");
+
+	for(i = 0; i < nr_ranges; ++i)
+		dbgprintf("%016Lx-%016Lx\n", mem_range[i].start, mem_range[i].end);
+
 	/*
 	 * if the core type has not been set on command line, set it here
 	 * automatically
-- 
1.5.6.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 10 11:58:42 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Sep 2012 11:58: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 1TB2dE-00038L-RN; Mon, 10 Sep 2012 11:58:24 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <SRS0=Ppt6=HJ=oracle.com=daniel.kiper@net-space.pl>)
	id 1TB2dD-00037i-6Z
	for xen-devel@lists.xensource.com; Mon, 10 Sep 2012 11:58:23 +0000
Received: from [85.158.138.51:49357] by server-11.bemta-3.messagelabs.com id
	66/A4-30250-ED5DD405; Mon, 10 Sep 2012 11:58:22 +0000
X-Env-Sender: SRS0=Ppt6=HJ=oracle.com=daniel.kiper@net-space.pl
X-Msg-Ref: server-12.tower-174.messagelabs.com!1347278300!21748053!4
X-Originating-IP: [89.174.63.77]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16351 invoked from network); 10 Sep 2012 11:58:21 -0000
Received: from router-fw.net-space.pl (HELO router-fw.net-space.pl)
	(89.174.63.77)
	by server-12.tower-174.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 10 Sep 2012 11:58:21 -0000
Received: from dev-00.local.net-space.pl ([192.168.1.5]:48176 "EHLO
	localhost.localdomain" TLS-CIPHER: <none>)
	by router-fw-old.local.net-space.pl with ESMTP id S1620320Ab2IJL5w
	(ORCPT <rfc822;xen-devel@lists.xensource.com>);
	Mon, 10 Sep 2012 13:57:52 +0200
From: Daniel Kiper <daniel.kiper@oracle.com>
To: konrad.wilk@oracle.com, andrew.cooper3@citrix.com, olaf@aepfle.de,
	jbeulich@suse.com, ptesarik@suse.cz, kexec@lists.infradead.org,
	xen-devel@lists.xensource.com
Date: Mon, 10 Sep 2012 13:57:45 +0200
Message-Id: <1347278271-5211-2-git-send-email-daniel.kiper@oracle.com>
X-Mailer: git-send-email 1.5.6.5
In-Reply-To: <1347278271-5211-1-git-send-email-daniel.kiper@oracle.com>
References: <1347278271-5211-1-git-send-email-daniel.kiper@oracle.com>
X-Bogosity: No, spamicity=0.113119
Subject: [Xen-devel] [PATCH 1/7] kexec: Define some constants and structures
	conditionally
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Some definitions in include/x86/x86-linux.h conflicts
with definitions placed in Xen headers. Make them
conditional. This patch is required by future
Xen kdump fixes.

Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
---
 include/x86/x86-linux.h |    7 ++++++-
 1 files changed, 6 insertions(+), 1 deletions(-)

diff --git a/include/x86/x86-linux.h b/include/x86/x86-linux.h
index 2ebcc3a..27af02b 100644
--- a/include/x86/x86-linux.h
+++ b/include/x86/x86-linux.h
@@ -4,13 +4,17 @@
 #define TENATIVE 0 /* Code that is tenatively correct but hasn't yet been officially accepted */
 
 #define E820MAP	0x2d0		/* our map */
-#define E820MAX	128		/* number of entries in E820MAP */
 #define E820NR	0x1e8		/* # entries in E820MAP */
 
+#ifndef E820MAX
+#define E820MAX	128		/* number of entries in E820MAP */
+#endif
+
 #ifndef ASSEMBLY
 
 #define PACKED __attribute__((packed))
 
+#ifndef E820_RAM
 struct e820entry {
 	uint64_t addr;	/* start of memory segment */
 	uint64_t size;	/* size of memory segment */
@@ -20,6 +24,7 @@ struct e820entry {
 #define E820_ACPI	3 /* usable as RAM once ACPI tables have been read */
 #define E820_NVS	4
 } PACKED;
+#endif
 
 /* FIXME expand on drive_info_)struct... */
 struct drive_info_struct {
-- 
1.5.6.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 10 11:58:42 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Sep 2012 11:58: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 1TB2dE-000382-3s; Mon, 10 Sep 2012 11:58:24 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <SRS0=Ppt6=HJ=oracle.com=daniel.kiper@net-space.pl>)
	id 1TB2dC-00037g-LE
	for xen-devel@lists.xensource.com; Mon, 10 Sep 2012 11:58:22 +0000
Received: from [85.158.138.51:49320] by server-6.bemta-3.messagelabs.com id
	BC/34-29694-DD5DD405; Mon, 10 Sep 2012 11:58:21 +0000
X-Env-Sender: SRS0=Ppt6=HJ=oracle.com=daniel.kiper@net-space.pl
X-Msg-Ref: server-12.tower-174.messagelabs.com!1347278300!21748053!1
X-Originating-IP: [89.174.63.77]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16246 invoked from network); 10 Sep 2012 11:58:21 -0000
Received: from router-fw.net-space.pl (HELO router-fw.net-space.pl)
	(89.174.63.77)
	by server-12.tower-174.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 10 Sep 2012 11:58:21 -0000
Received: from dev-00.local.net-space.pl ([192.168.1.5]:48176 "EHLO
	localhost.localdomain" TLS-CIPHER: <none>)
	by router-fw-old.local.net-space.pl with ESMTP id S1621314Ab2IJL5w
	(ORCPT <rfc822;xen-devel@lists.xensource.com>);
	Mon, 10 Sep 2012 13:57:52 +0200
From: Daniel Kiper <daniel.kiper@oracle.com>
To: konrad.wilk@oracle.com, andrew.cooper3@citrix.com, olaf@aepfle.de,
	jbeulich@suse.com, ptesarik@suse.cz, kexec@lists.infradead.org,
	xen-devel@lists.xensource.com
Date: Mon, 10 Sep 2012 13:57:46 +0200
Message-Id: <1347278271-5211-3-git-send-email-daniel.kiper@oracle.com>
X-Mailer: git-send-email 1.5.6.5
In-Reply-To: <1347278271-5211-2-git-send-email-daniel.kiper@oracle.com>
References: <1347278271-5211-1-git-send-email-daniel.kiper@oracle.com>
	<1347278271-5211-2-git-send-email-daniel.kiper@oracle.com>
X-Bogosity: No, spamicity=0.000000
Subject: [Xen-devel] [PATCH 2/7] xen: Rename e820_to_kexec_type() to
	xen_e820_to_kexec_type() and export 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>
MIME-Version: 1.0
Content-Type: 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 e820_to_kexec_type() to xen_e820_to_kexec_type() and export it.

Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
---
 kexec/arch/i386/kexec-x86-common.c |    6 +++---
 kexec/arch/i386/kexec-x86.h        |    2 ++
 2 files changed, 5 insertions(+), 3 deletions(-)

diff --git a/kexec/arch/i386/kexec-x86-common.c b/kexec/arch/i386/kexec-x86-common.c
index 609d35d..02471a8 100644
--- a/kexec/arch/i386/kexec-x86-common.c
+++ b/kexec/arch/i386/kexec-x86-common.c
@@ -151,7 +151,7 @@ static int get_memory_ranges_sysfs(struct memory_range **range, int *ranges)
 }
 
 #ifdef HAVE_LIBXENCTRL
-static unsigned e820_to_kexec_type(uint32_t type)
+unsigned xen_e820_to_kexec_type(uint32_t type)
 {
 	switch (type) {
 		case E820_RAM:
@@ -213,7 +213,7 @@ static int get_memory_ranges_xen(struct memory_range **range, int *ranges)
 	for (i = 0; i < rc; ++i) {
 		memory_range[i].start = e820entries[i].addr;
 		memory_range[i].end = e820entries[i].addr + e820entries[i].size;
-		memory_range[i].type = e820_to_kexec_type(e820entries[i].type);
+		memory_range[i].type = xen_e820_to_kexec_type(e820entries[i].type);
 	}
 
 	qsort(memory_range, rc, sizeof(struct memory_range), compare_ranges);
@@ -289,7 +289,7 @@ static int get_memory_ranges_xen(struct memory_range **range, int *ranges)
 	for (i = 0; i < xen_memory_map->nr_entries; ++i) {
 		memory_range[i].start = e820entries[i].addr;
 		memory_range[i].end = e820entries[i].addr + e820entries[i].size;
-		memory_range[i].type = e820_to_kexec_type(e820entries[i].type);
+		memory_range[i].type = xen_e820_to_kexec_type(e820entries[i].type);
 	}
 
 	qsort(memory_range, xen_memory_map->nr_entries, sizeof(struct memory_range), compare_ranges);
diff --git a/kexec/arch/i386/kexec-x86.h b/kexec/arch/i386/kexec-x86.h
index dfcc51d..5aa2a46 100644
--- a/kexec/arch/i386/kexec-x86.h
+++ b/kexec/arch/i386/kexec-x86.h
@@ -81,4 +81,6 @@ int nbi_probe(const char *buf, off_t len);
 int nbi_load(int argc, char **argv, const char *buf, off_t len,
 	struct kexec_info *info);
 void nbi_usage(void);
+
+extern unsigned xen_e820_to_kexec_type(uint32_t type);
 #endif /* KEXEC_X86_H */
-- 
1.5.6.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 10 11:58:42 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Sep 2012 11:58: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 1TB2dG-000396-VK; Mon, 10 Sep 2012 11:58:26 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <SRS0=Ppt6=HJ=oracle.com=daniel.kiper@net-space.pl>)
	id 1TB2dE-000381-Hd
	for xen-devel@lists.xensource.com; Mon, 10 Sep 2012 11:58:24 +0000
Received: from [85.158.138.51:49534] by server-9.bemta-3.messagelabs.com id
	93/9D-15390-FD5DD405; Mon, 10 Sep 2012 11:58:23 +0000
X-Env-Sender: SRS0=Ppt6=HJ=oracle.com=daniel.kiper@net-space.pl
X-Msg-Ref: server-12.tower-174.messagelabs.com!1347278300!21748053!8
X-Originating-IP: [89.174.63.77]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16493 invoked from network); 10 Sep 2012 11:58:22 -0000
Received: from router-fw.net-space.pl (HELO router-fw.net-space.pl)
	(89.174.63.77)
	by server-12.tower-174.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 10 Sep 2012 11:58:22 -0000
Received: from dev-00.local.net-space.pl ([192.168.1.5]:48176 "EHLO
	localhost.localdomain" TLS-CIPHER: <none>)
	by router-fw-old.local.net-space.pl with ESMTP id S1621611Ab2IJL5x
	(ORCPT <rfc822;xen-devel@lists.xensource.com>);
	Mon, 10 Sep 2012 13:57:53 +0200
From: Daniel Kiper <daniel.kiper@oracle.com>
To: konrad.wilk@oracle.com, andrew.cooper3@citrix.com, olaf@aepfle.de,
	jbeulich@suse.com, ptesarik@suse.cz, kexec@lists.infradead.org,
	xen-devel@lists.xensource.com
Date: Mon, 10 Sep 2012 13:57:51 +0200
Message-Id: <1347278271-5211-8-git-send-email-daniel.kiper@oracle.com>
X-Mailer: git-send-email 1.5.6.5
In-Reply-To: <1347278271-5211-7-git-send-email-daniel.kiper@oracle.com>
References: <1347278271-5211-1-git-send-email-daniel.kiper@oracle.com>
	<1347278271-5211-2-git-send-email-daniel.kiper@oracle.com>
	<1347278271-5211-3-git-send-email-daniel.kiper@oracle.com>
	<1347278271-5211-4-git-send-email-daniel.kiper@oracle.com>
	<1347278271-5211-5-git-send-email-daniel.kiper@oracle.com>
	<1347278271-5211-6-git-send-email-daniel.kiper@oracle.com>
	<1347278271-5211-7-git-send-email-daniel.kiper@oracle.com>
X-Bogosity: No, spamicity=0.000000
Subject: [Xen-devel] [PATCH 7/7] xen: Fix Xen kdump 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

get_crash_memory_ranges() is unreliable under Xen. Proper machine
memory map could be obtained under Xen by calling __HYPERVISOR_memory_op
hypercall with XENMEM_machine_memory_map argument. get_crash_memory_ranges_xen()
does that. It is implemented using ioctl() or libxenctrl interface.
This solution is compatible with 3.x and 4.x Xen versions.

Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
---
 kexec/arch/i386/crashdump-x86.c |  203 ++++++++++++++++++++++++++++++++++++---
 1 files changed, 191 insertions(+), 12 deletions(-)

diff --git a/kexec/arch/i386/crashdump-x86.c b/kexec/arch/i386/crashdump-x86.c
index c6b9354..09c3fd4 100644
--- a/kexec/arch/i386/crashdump-x86.c
+++ b/kexec/arch/i386/crashdump-x86.c
@@ -18,21 +18,41 @@
  * along with this program; if not, write to the Free Software
  * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
  */
+
+#define _XOPEN_SOURCE	600
+#define _BSD_SOURCE
+
+#include <fcntl.h>
 #include <stdio.h>
 #include <string.h>
 #include <stdlib.h>
 #include <errno.h>
 #include <limits.h>
 #include <elf.h>
+#include <sys/ioctl.h>
+#include <sys/mman.h>
 #include <sys/types.h>
 #include <sys/stat.h>
 #include <unistd.h>
 #include "../../kexec.h"
 #include "../../kexec-elf.h"
 #include "../../kexec-syscall.h"
+#include "../../firmware_memmap.h"
 #include "../../crashdump.h"
 #include "kexec-x86.h"
 #include "crashdump-x86.h"
+
+#ifdef HAVE_LIBXENCTRL
+#ifdef HAVE_XC_GET_MACHINE_MEMORY_MAP
+#include <xenctrl.h>
+#else
+#define __XEN_TOOLS__	1
+#include <xen/xen.h>
+#include <xen/memory.h>
+#include <xen/sys/privcmd.h>
+#endif /* HAVE_XC_GET_MACHINE_MEMORY_MAP */
+#endif /* HAVE_LIBXENCTRL */
+
 #include <x86/x86-linux.h>
 
 extern struct arch_options_t arch_options;
@@ -273,6 +293,162 @@ static int get_crash_memory_ranges(struct memory_range **range, int *ranges,
 	return 0;
 }
 
+#ifdef HAVE_LIBXENCTRL
+#ifdef HAVE_XC_GET_MACHINE_MEMORY_MAP
+static int get_crash_memory_ranges_xen(struct memory_range **range,
+					int *ranges, unsigned long lowmem_limit)
+{
+	int j, rc, ret = -1;
+	struct e820entry e820entries[CRASH_MAX_MEMORY_RANGES];
+	unsigned int i;
+#ifdef XENCTRL_HAS_XC_INTERFACE
+	xc_interface *xc;
+#else
+	int xc;
+#endif
+
+#ifdef XENCTRL_HAS_XC_INTERFACE
+	xc = xc_interface_open(NULL, NULL, 0);
+
+	if (!xc) {
+		fprintf(stderr, "%s: Failed to open Xen control interface\n", __func__);
+		goto err;
+	}
+#else
+	xc = xc_interface_open();
+
+	if (xc == -1) {
+		fprintf(stderr, "%s: Failed to open Xen control interface\n", __func__);
+		goto err;
+	}
+#endif
+
+	rc = xc_get_machine_memory_map(xc, e820entries, CRASH_MAX_MEMORY_RANGES);
+
+	if (rc < 0) {
+		fprintf(stderr, "%s: xc_get_machine_memory_map: %s\n", __func__, strerror(-rc));
+		goto err;
+	}
+
+	for (i = 0, j = 0; i < rc && j < CRASH_MAX_MEMORY_RANGES; ++i, ++j) {
+		crash_memory_range[j].start = e820entries[i].addr;
+		crash_memory_range[j].end = e820entries[i].addr + e820entries[i].size - 1;
+		crash_memory_range[j].type = xen_e820_to_kexec_type(e820entries[i].type);
+		segregate_lowmem_region(&j, lowmem_limit);
+	}
+
+	*range = crash_memory_range;
+	*ranges = j;
+
+	qsort(*range, *ranges, sizeof(struct memory_range), compare_ranges);
+
+	if (exclude_region(ranges, crash_reserved_mem.start,
+						crash_reserved_mem.end) < 0)
+		goto err;
+
+	ret = 0;
+
+err:
+	xc_interface_close(xc);
+
+	return ret;
+}
+#else
+static int get_crash_memory_ranges_xen(struct memory_range **range,
+					int *ranges, unsigned long lowmem_limit)
+{
+	int fd, j, rc, ret = -1;
+	privcmd_hypercall_t hypercall;
+	struct e820entry *e820entries = NULL;
+	struct xen_memory_map *xen_memory_map = NULL;
+	unsigned int i;
+
+	fd = open("/proc/xen/privcmd", O_RDWR);
+
+	if (fd == -1) {
+		fprintf(stderr, "%s: open(/proc/xen/privcmd): %m\n", __func__);
+		goto err;
+	}
+
+	rc = posix_memalign((void **)&e820entries, getpagesize(),
+			    sizeof(struct e820entry) * CRASH_MAX_MEMORY_RANGES);
+
+	if (rc) {
+		fprintf(stderr, "%s: posix_memalign(e820entries): %s\n", __func__, strerror(rc));
+		e820entries = NULL;
+		goto err;
+	}
+
+	rc = posix_memalign((void **)&xen_memory_map, getpagesize(),
+			    sizeof(struct xen_memory_map));
+
+	if (rc) {
+		fprintf(stderr, "%s: posix_memalign(xen_memory_map): %s\n", __func__, strerror(rc));
+		xen_memory_map = NULL;
+		goto err;
+	}
+
+	if (mlock(e820entries, sizeof(struct e820entry) * CRASH_MAX_MEMORY_RANGES) == -1) {
+		fprintf(stderr, "%s: mlock(e820entries): %m\n", __func__);
+		goto err;
+	}
+
+	if (mlock(xen_memory_map, sizeof(struct xen_memory_map)) == -1) {
+		fprintf(stderr, "%s: mlock(xen_memory_map): %m\n", __func__);
+		goto err;
+	}
+
+	xen_memory_map->nr_entries = CRASH_MAX_MEMORY_RANGES;
+	set_xen_guest_handle(xen_memory_map->buffer, e820entries);
+
+	hypercall.op = __HYPERVISOR_memory_op;
+	hypercall.arg[0] = XENMEM_machine_memory_map;
+	hypercall.arg[1] = (__u64)xen_memory_map;
+
+	rc = ioctl(fd, IOCTL_PRIVCMD_HYPERCALL, &hypercall);
+
+	if (rc == -1) {
+		fprintf(stderr, "%s: ioctl(IOCTL_PRIVCMD_HYPERCALL): %m\n", __func__);
+		goto err;
+	}
+
+	for (i = 0, j = 0; i < xen_memory_map->nr_entries &&
+				j < CRASH_MAX_MEMORY_RANGES; ++i, ++j) {
+		crash_memory_range[j].start = e820entries[i].addr;
+		crash_memory_range[j].end = e820entries[i].addr + e820entries[i].size - 1;
+		crash_memory_range[j].type = xen_e820_to_kexec_type(e820entries[i].type);
+		segregate_lowmem_region(&j, lowmem_limit);
+	}
+
+	*range = crash_memory_range;
+	*ranges = j;
+
+	qsort(*range, *ranges, sizeof(struct memory_range), compare_ranges);
+
+	if (exclude_region(ranges, crash_reserved_mem.start,
+						crash_reserved_mem.end) < 0)
+		goto err;
+
+	ret = 0;
+
+err:
+	munlock(xen_memory_map, sizeof(struct xen_memory_map));
+	munlock(e820entries, sizeof(struct e820entry) * CRASH_MAX_MEMORY_RANGES);
+	free(xen_memory_map);
+	free(e820entries);
+	close(fd);
+
+	return ret;
+}
+#endif /* HAVE_XC_GET_MACHINE_MEMORY_MAP */
+#else
+static int get_crash_memory_ranges_xen(struct memory_range **range,
+					int *ranges, unsigned long lowmem_limit)
+{
+	return 0;
+}
+#endif /* HAVE_LIBXENCTRL */
+
 static void segregate_lowmem_region(int *nr_ranges, unsigned long lowmem_limit)
 {
 	unsigned long long end, start;
@@ -724,10 +900,15 @@ int load_crashdump_segments(struct kexec_info *info, char* mod_cmdline,
 		return -1;
 	}
 
-	if (get_crash_memory_ranges(&mem_range, &nr_ranges,
-				    info->kexec_flags,
-				    elf_info.lowmem_limit) < 0)
-		return -1;
+	if (xen_present()) {
+		if (get_crash_memory_ranges_xen(&mem_range, &nr_ranges,
+						elf_info.lowmem_limit) < 0)
+			return -1;
+	} else
+		if (get_crash_memory_ranges(&mem_range, &nr_ranges,
+						info->kexec_flags,
+						elf_info.lowmem_limit) < 0)
+			return -1;
 
 	get_backup_area(info, mem_range, nr_ranges);
 
@@ -784,17 +965,15 @@ int load_crashdump_segments(struct kexec_info *info, char* mod_cmdline,
 
 	/* Create elf header segment and store crash image data. */
 	if (arch_options.core_header_type == CORE_TYPE_ELF64) {
-		if (crash_create_elf64_headers(info, &elf_info,
-					       crash_memory_range, nr_ranges,
-					       &tmp, &bufsz,
-					       ELF_CORE_HEADER_ALIGN) < 0)
+		if (crash_create_elf64_headers(info, &elf_info, mem_range,
+						nr_ranges, &tmp, &bufsz,
+						ELF_CORE_HEADER_ALIGN) < 0)
 			return EFAILED;
 	}
 	else {
-		if (crash_create_elf32_headers(info, &elf_info,
-					       crash_memory_range, nr_ranges,
-					       &tmp, &bufsz,
-					       ELF_CORE_HEADER_ALIGN) < 0)
+		if (crash_create_elf32_headers(info, &elf_info, mem_range,
+						nr_ranges, &tmp, &bufsz,
+						ELF_CORE_HEADER_ALIGN) < 0)
 			return EFAILED;
 	}
 	/* the size of the elf headers allocated is returned in 'bufsz' */
-- 
1.5.6.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 10 11:58:42 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Sep 2012 11:58: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 1TB2dG-000396-VK; Mon, 10 Sep 2012 11:58:26 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <SRS0=Ppt6=HJ=oracle.com=daniel.kiper@net-space.pl>)
	id 1TB2dE-000381-Hd
	for xen-devel@lists.xensource.com; Mon, 10 Sep 2012 11:58:24 +0000
Received: from [85.158.138.51:49534] by server-9.bemta-3.messagelabs.com id
	93/9D-15390-FD5DD405; Mon, 10 Sep 2012 11:58:23 +0000
X-Env-Sender: SRS0=Ppt6=HJ=oracle.com=daniel.kiper@net-space.pl
X-Msg-Ref: server-12.tower-174.messagelabs.com!1347278300!21748053!8
X-Originating-IP: [89.174.63.77]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16493 invoked from network); 10 Sep 2012 11:58:22 -0000
Received: from router-fw.net-space.pl (HELO router-fw.net-space.pl)
	(89.174.63.77)
	by server-12.tower-174.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 10 Sep 2012 11:58:22 -0000
Received: from dev-00.local.net-space.pl ([192.168.1.5]:48176 "EHLO
	localhost.localdomain" TLS-CIPHER: <none>)
	by router-fw-old.local.net-space.pl with ESMTP id S1621611Ab2IJL5x
	(ORCPT <rfc822;xen-devel@lists.xensource.com>);
	Mon, 10 Sep 2012 13:57:53 +0200
From: Daniel Kiper <daniel.kiper@oracle.com>
To: konrad.wilk@oracle.com, andrew.cooper3@citrix.com, olaf@aepfle.de,
	jbeulich@suse.com, ptesarik@suse.cz, kexec@lists.infradead.org,
	xen-devel@lists.xensource.com
Date: Mon, 10 Sep 2012 13:57:51 +0200
Message-Id: <1347278271-5211-8-git-send-email-daniel.kiper@oracle.com>
X-Mailer: git-send-email 1.5.6.5
In-Reply-To: <1347278271-5211-7-git-send-email-daniel.kiper@oracle.com>
References: <1347278271-5211-1-git-send-email-daniel.kiper@oracle.com>
	<1347278271-5211-2-git-send-email-daniel.kiper@oracle.com>
	<1347278271-5211-3-git-send-email-daniel.kiper@oracle.com>
	<1347278271-5211-4-git-send-email-daniel.kiper@oracle.com>
	<1347278271-5211-5-git-send-email-daniel.kiper@oracle.com>
	<1347278271-5211-6-git-send-email-daniel.kiper@oracle.com>
	<1347278271-5211-7-git-send-email-daniel.kiper@oracle.com>
X-Bogosity: No, spamicity=0.000000
Subject: [Xen-devel] [PATCH 7/7] xen: Fix Xen kdump 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

get_crash_memory_ranges() is unreliable under Xen. Proper machine
memory map could be obtained under Xen by calling __HYPERVISOR_memory_op
hypercall with XENMEM_machine_memory_map argument. get_crash_memory_ranges_xen()
does that. It is implemented using ioctl() or libxenctrl interface.
This solution is compatible with 3.x and 4.x Xen versions.

Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
---
 kexec/arch/i386/crashdump-x86.c |  203 ++++++++++++++++++++++++++++++++++++---
 1 files changed, 191 insertions(+), 12 deletions(-)

diff --git a/kexec/arch/i386/crashdump-x86.c b/kexec/arch/i386/crashdump-x86.c
index c6b9354..09c3fd4 100644
--- a/kexec/arch/i386/crashdump-x86.c
+++ b/kexec/arch/i386/crashdump-x86.c
@@ -18,21 +18,41 @@
  * along with this program; if not, write to the Free Software
  * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
  */
+
+#define _XOPEN_SOURCE	600
+#define _BSD_SOURCE
+
+#include <fcntl.h>
 #include <stdio.h>
 #include <string.h>
 #include <stdlib.h>
 #include <errno.h>
 #include <limits.h>
 #include <elf.h>
+#include <sys/ioctl.h>
+#include <sys/mman.h>
 #include <sys/types.h>
 #include <sys/stat.h>
 #include <unistd.h>
 #include "../../kexec.h"
 #include "../../kexec-elf.h"
 #include "../../kexec-syscall.h"
+#include "../../firmware_memmap.h"
 #include "../../crashdump.h"
 #include "kexec-x86.h"
 #include "crashdump-x86.h"
+
+#ifdef HAVE_LIBXENCTRL
+#ifdef HAVE_XC_GET_MACHINE_MEMORY_MAP
+#include <xenctrl.h>
+#else
+#define __XEN_TOOLS__	1
+#include <xen/xen.h>
+#include <xen/memory.h>
+#include <xen/sys/privcmd.h>
+#endif /* HAVE_XC_GET_MACHINE_MEMORY_MAP */
+#endif /* HAVE_LIBXENCTRL */
+
 #include <x86/x86-linux.h>
 
 extern struct arch_options_t arch_options;
@@ -273,6 +293,162 @@ static int get_crash_memory_ranges(struct memory_range **range, int *ranges,
 	return 0;
 }
 
+#ifdef HAVE_LIBXENCTRL
+#ifdef HAVE_XC_GET_MACHINE_MEMORY_MAP
+static int get_crash_memory_ranges_xen(struct memory_range **range,
+					int *ranges, unsigned long lowmem_limit)
+{
+	int j, rc, ret = -1;
+	struct e820entry e820entries[CRASH_MAX_MEMORY_RANGES];
+	unsigned int i;
+#ifdef XENCTRL_HAS_XC_INTERFACE
+	xc_interface *xc;
+#else
+	int xc;
+#endif
+
+#ifdef XENCTRL_HAS_XC_INTERFACE
+	xc = xc_interface_open(NULL, NULL, 0);
+
+	if (!xc) {
+		fprintf(stderr, "%s: Failed to open Xen control interface\n", __func__);
+		goto err;
+	}
+#else
+	xc = xc_interface_open();
+
+	if (xc == -1) {
+		fprintf(stderr, "%s: Failed to open Xen control interface\n", __func__);
+		goto err;
+	}
+#endif
+
+	rc = xc_get_machine_memory_map(xc, e820entries, CRASH_MAX_MEMORY_RANGES);
+
+	if (rc < 0) {
+		fprintf(stderr, "%s: xc_get_machine_memory_map: %s\n", __func__, strerror(-rc));
+		goto err;
+	}
+
+	for (i = 0, j = 0; i < rc && j < CRASH_MAX_MEMORY_RANGES; ++i, ++j) {
+		crash_memory_range[j].start = e820entries[i].addr;
+		crash_memory_range[j].end = e820entries[i].addr + e820entries[i].size - 1;
+		crash_memory_range[j].type = xen_e820_to_kexec_type(e820entries[i].type);
+		segregate_lowmem_region(&j, lowmem_limit);
+	}
+
+	*range = crash_memory_range;
+	*ranges = j;
+
+	qsort(*range, *ranges, sizeof(struct memory_range), compare_ranges);
+
+	if (exclude_region(ranges, crash_reserved_mem.start,
+						crash_reserved_mem.end) < 0)
+		goto err;
+
+	ret = 0;
+
+err:
+	xc_interface_close(xc);
+
+	return ret;
+}
+#else
+static int get_crash_memory_ranges_xen(struct memory_range **range,
+					int *ranges, unsigned long lowmem_limit)
+{
+	int fd, j, rc, ret = -1;
+	privcmd_hypercall_t hypercall;
+	struct e820entry *e820entries = NULL;
+	struct xen_memory_map *xen_memory_map = NULL;
+	unsigned int i;
+
+	fd = open("/proc/xen/privcmd", O_RDWR);
+
+	if (fd == -1) {
+		fprintf(stderr, "%s: open(/proc/xen/privcmd): %m\n", __func__);
+		goto err;
+	}
+
+	rc = posix_memalign((void **)&e820entries, getpagesize(),
+			    sizeof(struct e820entry) * CRASH_MAX_MEMORY_RANGES);
+
+	if (rc) {
+		fprintf(stderr, "%s: posix_memalign(e820entries): %s\n", __func__, strerror(rc));
+		e820entries = NULL;
+		goto err;
+	}
+
+	rc = posix_memalign((void **)&xen_memory_map, getpagesize(),
+			    sizeof(struct xen_memory_map));
+
+	if (rc) {
+		fprintf(stderr, "%s: posix_memalign(xen_memory_map): %s\n", __func__, strerror(rc));
+		xen_memory_map = NULL;
+		goto err;
+	}
+
+	if (mlock(e820entries, sizeof(struct e820entry) * CRASH_MAX_MEMORY_RANGES) == -1) {
+		fprintf(stderr, "%s: mlock(e820entries): %m\n", __func__);
+		goto err;
+	}
+
+	if (mlock(xen_memory_map, sizeof(struct xen_memory_map)) == -1) {
+		fprintf(stderr, "%s: mlock(xen_memory_map): %m\n", __func__);
+		goto err;
+	}
+
+	xen_memory_map->nr_entries = CRASH_MAX_MEMORY_RANGES;
+	set_xen_guest_handle(xen_memory_map->buffer, e820entries);
+
+	hypercall.op = __HYPERVISOR_memory_op;
+	hypercall.arg[0] = XENMEM_machine_memory_map;
+	hypercall.arg[1] = (__u64)xen_memory_map;
+
+	rc = ioctl(fd, IOCTL_PRIVCMD_HYPERCALL, &hypercall);
+
+	if (rc == -1) {
+		fprintf(stderr, "%s: ioctl(IOCTL_PRIVCMD_HYPERCALL): %m\n", __func__);
+		goto err;
+	}
+
+	for (i = 0, j = 0; i < xen_memory_map->nr_entries &&
+				j < CRASH_MAX_MEMORY_RANGES; ++i, ++j) {
+		crash_memory_range[j].start = e820entries[i].addr;
+		crash_memory_range[j].end = e820entries[i].addr + e820entries[i].size - 1;
+		crash_memory_range[j].type = xen_e820_to_kexec_type(e820entries[i].type);
+		segregate_lowmem_region(&j, lowmem_limit);
+	}
+
+	*range = crash_memory_range;
+	*ranges = j;
+
+	qsort(*range, *ranges, sizeof(struct memory_range), compare_ranges);
+
+	if (exclude_region(ranges, crash_reserved_mem.start,
+						crash_reserved_mem.end) < 0)
+		goto err;
+
+	ret = 0;
+
+err:
+	munlock(xen_memory_map, sizeof(struct xen_memory_map));
+	munlock(e820entries, sizeof(struct e820entry) * CRASH_MAX_MEMORY_RANGES);
+	free(xen_memory_map);
+	free(e820entries);
+	close(fd);
+
+	return ret;
+}
+#endif /* HAVE_XC_GET_MACHINE_MEMORY_MAP */
+#else
+static int get_crash_memory_ranges_xen(struct memory_range **range,
+					int *ranges, unsigned long lowmem_limit)
+{
+	return 0;
+}
+#endif /* HAVE_LIBXENCTRL */
+
 static void segregate_lowmem_region(int *nr_ranges, unsigned long lowmem_limit)
 {
 	unsigned long long end, start;
@@ -724,10 +900,15 @@ int load_crashdump_segments(struct kexec_info *info, char* mod_cmdline,
 		return -1;
 	}
 
-	if (get_crash_memory_ranges(&mem_range, &nr_ranges,
-				    info->kexec_flags,
-				    elf_info.lowmem_limit) < 0)
-		return -1;
+	if (xen_present()) {
+		if (get_crash_memory_ranges_xen(&mem_range, &nr_ranges,
+						elf_info.lowmem_limit) < 0)
+			return -1;
+	} else
+		if (get_crash_memory_ranges(&mem_range, &nr_ranges,
+						info->kexec_flags,
+						elf_info.lowmem_limit) < 0)
+			return -1;
 
 	get_backup_area(info, mem_range, nr_ranges);
 
@@ -784,17 +965,15 @@ int load_crashdump_segments(struct kexec_info *info, char* mod_cmdline,
 
 	/* Create elf header segment and store crash image data. */
 	if (arch_options.core_header_type == CORE_TYPE_ELF64) {
-		if (crash_create_elf64_headers(info, &elf_info,
-					       crash_memory_range, nr_ranges,
-					       &tmp, &bufsz,
-					       ELF_CORE_HEADER_ALIGN) < 0)
+		if (crash_create_elf64_headers(info, &elf_info, mem_range,
+						nr_ranges, &tmp, &bufsz,
+						ELF_CORE_HEADER_ALIGN) < 0)
 			return EFAILED;
 	}
 	else {
-		if (crash_create_elf32_headers(info, &elf_info,
-					       crash_memory_range, nr_ranges,
-					       &tmp, &bufsz,
-					       ELF_CORE_HEADER_ALIGN) < 0)
+		if (crash_create_elf32_headers(info, &elf_info, mem_range,
+						nr_ranges, &tmp, &bufsz,
+						ELF_CORE_HEADER_ALIGN) < 0)
 			return EFAILED;
 	}
 	/* the size of the elf headers allocated is returned in 'bufsz' */
-- 
1.5.6.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 10 11:58:42 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Sep 2012 11:58: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 1TB2dE-00038L-RN; Mon, 10 Sep 2012 11:58:24 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <SRS0=Ppt6=HJ=oracle.com=daniel.kiper@net-space.pl>)
	id 1TB2dD-00037i-6Z
	for xen-devel@lists.xensource.com; Mon, 10 Sep 2012 11:58:23 +0000
Received: from [85.158.138.51:49357] by server-11.bemta-3.messagelabs.com id
	66/A4-30250-ED5DD405; Mon, 10 Sep 2012 11:58:22 +0000
X-Env-Sender: SRS0=Ppt6=HJ=oracle.com=daniel.kiper@net-space.pl
X-Msg-Ref: server-12.tower-174.messagelabs.com!1347278300!21748053!4
X-Originating-IP: [89.174.63.77]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16351 invoked from network); 10 Sep 2012 11:58:21 -0000
Received: from router-fw.net-space.pl (HELO router-fw.net-space.pl)
	(89.174.63.77)
	by server-12.tower-174.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 10 Sep 2012 11:58:21 -0000
Received: from dev-00.local.net-space.pl ([192.168.1.5]:48176 "EHLO
	localhost.localdomain" TLS-CIPHER: <none>)
	by router-fw-old.local.net-space.pl with ESMTP id S1620320Ab2IJL5w
	(ORCPT <rfc822;xen-devel@lists.xensource.com>);
	Mon, 10 Sep 2012 13:57:52 +0200
From: Daniel Kiper <daniel.kiper@oracle.com>
To: konrad.wilk@oracle.com, andrew.cooper3@citrix.com, olaf@aepfle.de,
	jbeulich@suse.com, ptesarik@suse.cz, kexec@lists.infradead.org,
	xen-devel@lists.xensource.com
Date: Mon, 10 Sep 2012 13:57:45 +0200
Message-Id: <1347278271-5211-2-git-send-email-daniel.kiper@oracle.com>
X-Mailer: git-send-email 1.5.6.5
In-Reply-To: <1347278271-5211-1-git-send-email-daniel.kiper@oracle.com>
References: <1347278271-5211-1-git-send-email-daniel.kiper@oracle.com>
X-Bogosity: No, spamicity=0.113119
Subject: [Xen-devel] [PATCH 1/7] kexec: Define some constants and structures
	conditionally
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Some definitions in include/x86/x86-linux.h conflicts
with definitions placed in Xen headers. Make them
conditional. This patch is required by future
Xen kdump fixes.

Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
---
 include/x86/x86-linux.h |    7 ++++++-
 1 files changed, 6 insertions(+), 1 deletions(-)

diff --git a/include/x86/x86-linux.h b/include/x86/x86-linux.h
index 2ebcc3a..27af02b 100644
--- a/include/x86/x86-linux.h
+++ b/include/x86/x86-linux.h
@@ -4,13 +4,17 @@
 #define TENATIVE 0 /* Code that is tenatively correct but hasn't yet been officially accepted */
 
 #define E820MAP	0x2d0		/* our map */
-#define E820MAX	128		/* number of entries in E820MAP */
 #define E820NR	0x1e8		/* # entries in E820MAP */
 
+#ifndef E820MAX
+#define E820MAX	128		/* number of entries in E820MAP */
+#endif
+
 #ifndef ASSEMBLY
 
 #define PACKED __attribute__((packed))
 
+#ifndef E820_RAM
 struct e820entry {
 	uint64_t addr;	/* start of memory segment */
 	uint64_t size;	/* size of memory segment */
@@ -20,6 +24,7 @@ struct e820entry {
 #define E820_ACPI	3 /* usable as RAM once ACPI tables have been read */
 #define E820_NVS	4
 } PACKED;
+#endif
 
 /* FIXME expand on drive_info_)struct... */
 struct drive_info_struct {
-- 
1.5.6.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 10 11:58:42 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Sep 2012 11:58: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 1TB2dE-000382-3s; Mon, 10 Sep 2012 11:58:24 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <SRS0=Ppt6=HJ=oracle.com=daniel.kiper@net-space.pl>)
	id 1TB2dC-00037g-LE
	for xen-devel@lists.xensource.com; Mon, 10 Sep 2012 11:58:22 +0000
Received: from [85.158.138.51:49320] by server-6.bemta-3.messagelabs.com id
	BC/34-29694-DD5DD405; Mon, 10 Sep 2012 11:58:21 +0000
X-Env-Sender: SRS0=Ppt6=HJ=oracle.com=daniel.kiper@net-space.pl
X-Msg-Ref: server-12.tower-174.messagelabs.com!1347278300!21748053!1
X-Originating-IP: [89.174.63.77]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16246 invoked from network); 10 Sep 2012 11:58:21 -0000
Received: from router-fw.net-space.pl (HELO router-fw.net-space.pl)
	(89.174.63.77)
	by server-12.tower-174.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 10 Sep 2012 11:58:21 -0000
Received: from dev-00.local.net-space.pl ([192.168.1.5]:48176 "EHLO
	localhost.localdomain" TLS-CIPHER: <none>)
	by router-fw-old.local.net-space.pl with ESMTP id S1621314Ab2IJL5w
	(ORCPT <rfc822;xen-devel@lists.xensource.com>);
	Mon, 10 Sep 2012 13:57:52 +0200
From: Daniel Kiper <daniel.kiper@oracle.com>
To: konrad.wilk@oracle.com, andrew.cooper3@citrix.com, olaf@aepfle.de,
	jbeulich@suse.com, ptesarik@suse.cz, kexec@lists.infradead.org,
	xen-devel@lists.xensource.com
Date: Mon, 10 Sep 2012 13:57:46 +0200
Message-Id: <1347278271-5211-3-git-send-email-daniel.kiper@oracle.com>
X-Mailer: git-send-email 1.5.6.5
In-Reply-To: <1347278271-5211-2-git-send-email-daniel.kiper@oracle.com>
References: <1347278271-5211-1-git-send-email-daniel.kiper@oracle.com>
	<1347278271-5211-2-git-send-email-daniel.kiper@oracle.com>
X-Bogosity: No, spamicity=0.000000
Subject: [Xen-devel] [PATCH 2/7] xen: Rename e820_to_kexec_type() to
	xen_e820_to_kexec_type() and export 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>
MIME-Version: 1.0
Content-Type: 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 e820_to_kexec_type() to xen_e820_to_kexec_type() and export it.

Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
---
 kexec/arch/i386/kexec-x86-common.c |    6 +++---
 kexec/arch/i386/kexec-x86.h        |    2 ++
 2 files changed, 5 insertions(+), 3 deletions(-)

diff --git a/kexec/arch/i386/kexec-x86-common.c b/kexec/arch/i386/kexec-x86-common.c
index 609d35d..02471a8 100644
--- a/kexec/arch/i386/kexec-x86-common.c
+++ b/kexec/arch/i386/kexec-x86-common.c
@@ -151,7 +151,7 @@ static int get_memory_ranges_sysfs(struct memory_range **range, int *ranges)
 }
 
 #ifdef HAVE_LIBXENCTRL
-static unsigned e820_to_kexec_type(uint32_t type)
+unsigned xen_e820_to_kexec_type(uint32_t type)
 {
 	switch (type) {
 		case E820_RAM:
@@ -213,7 +213,7 @@ static int get_memory_ranges_xen(struct memory_range **range, int *ranges)
 	for (i = 0; i < rc; ++i) {
 		memory_range[i].start = e820entries[i].addr;
 		memory_range[i].end = e820entries[i].addr + e820entries[i].size;
-		memory_range[i].type = e820_to_kexec_type(e820entries[i].type);
+		memory_range[i].type = xen_e820_to_kexec_type(e820entries[i].type);
 	}
 
 	qsort(memory_range, rc, sizeof(struct memory_range), compare_ranges);
@@ -289,7 +289,7 @@ static int get_memory_ranges_xen(struct memory_range **range, int *ranges)
 	for (i = 0; i < xen_memory_map->nr_entries; ++i) {
 		memory_range[i].start = e820entries[i].addr;
 		memory_range[i].end = e820entries[i].addr + e820entries[i].size;
-		memory_range[i].type = e820_to_kexec_type(e820entries[i].type);
+		memory_range[i].type = xen_e820_to_kexec_type(e820entries[i].type);
 	}
 
 	qsort(memory_range, xen_memory_map->nr_entries, sizeof(struct memory_range), compare_ranges);
diff --git a/kexec/arch/i386/kexec-x86.h b/kexec/arch/i386/kexec-x86.h
index dfcc51d..5aa2a46 100644
--- a/kexec/arch/i386/kexec-x86.h
+++ b/kexec/arch/i386/kexec-x86.h
@@ -81,4 +81,6 @@ int nbi_probe(const char *buf, off_t len);
 int nbi_load(int argc, char **argv, const char *buf, off_t len,
 	struct kexec_info *info);
 void nbi_usage(void);
+
+extern unsigned xen_e820_to_kexec_type(uint32_t type);
 #endif /* KEXEC_X86_H */
-- 
1.5.6.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 10 11:58:42 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Sep 2012 11:58: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 1TB2dF-00038h-I7; Mon, 10 Sep 2012 11:58:25 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <SRS0=Ppt6=HJ=oracle.com=daniel.kiper@net-space.pl>)
	id 1TB2dE-00037w-7Z
	for xen-devel@lists.xensource.com; Mon, 10 Sep 2012 11:58:24 +0000
Received: from [85.158.138.51:49485] by server-3.bemta-3.messagelabs.com id
	54/70-21322-FD5DD405; Mon, 10 Sep 2012 11:58:23 +0000
X-Env-Sender: SRS0=Ppt6=HJ=oracle.com=daniel.kiper@net-space.pl
X-Msg-Ref: server-12.tower-174.messagelabs.com!1347278300!21748053!7
X-Originating-IP: [89.174.63.77]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16451 invoked from network); 10 Sep 2012 11:58:22 -0000
Received: from router-fw.net-space.pl (HELO router-fw.net-space.pl)
	(89.174.63.77)
	by server-12.tower-174.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 10 Sep 2012 11:58:22 -0000
Received: from dev-00.local.net-space.pl ([192.168.1.5]:48176 "EHLO
	localhost.localdomain" TLS-CIPHER: <none>)
	by router-fw-old.local.net-space.pl with ESMTP id S1621323Ab2IJL5w
	(ORCPT <rfc822;xen-devel@lists.xensource.com>);
	Mon, 10 Sep 2012 13:57:52 +0200
From: Daniel Kiper <daniel.kiper@oracle.com>
To: konrad.wilk@oracle.com, andrew.cooper3@citrix.com, olaf@aepfle.de,
	jbeulich@suse.com, ptesarik@suse.cz, kexec@lists.infradead.org,
	xen-devel@lists.xensource.com
Date: Mon, 10 Sep 2012 13:57:48 +0200
Message-Id: <1347278271-5211-5-git-send-email-daniel.kiper@oracle.com>
X-Mailer: git-send-email 1.5.6.5
In-Reply-To: <1347278271-5211-4-git-send-email-daniel.kiper@oracle.com>
References: <1347278271-5211-1-git-send-email-daniel.kiper@oracle.com>
	<1347278271-5211-2-git-send-email-daniel.kiper@oracle.com>
	<1347278271-5211-3-git-send-email-daniel.kiper@oracle.com>
	<1347278271-5211-4-git-send-email-daniel.kiper@oracle.com>
X-Bogosity: No, spamicity=0.044690
Subject: [Xen-devel] [PATCH 4/7] kexec: Add segregate_lowmem_region()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Extract code segregating lowmem region and move it to new
segregate_lowmem_region(). This function will be used by
fixed Xen kdump support, too.

Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
---
 kexec/arch/i386/crashdump-x86.c |   38 +++++++++++++++++++++++++++-----------
 1 files changed, 27 insertions(+), 11 deletions(-)

diff --git a/kexec/arch/i386/crashdump-x86.c b/kexec/arch/i386/crashdump-x86.c
index ec9432b..77a1329 100644
--- a/kexec/arch/i386/crashdump-x86.c
+++ b/kexec/arch/i386/crashdump-x86.c
@@ -159,6 +159,7 @@ static int get_kernel_vaddr_and_size(struct kexec_info *UNUSED(info),
 }
 
 /* Forward Declaration. */
+static void segregate_lowmem_region(int *nr_ranges, unsigned long lowmem_limit);
 static int exclude_region(int *nr_ranges, uint64_t start, uint64_t end);
 
 /* Stores a sorted list of RAM memory ranges for which to create elf headers.
@@ -235,19 +236,10 @@ static int get_crash_memory_ranges(struct memory_range **range, int *ranges,
 		crash_memory_range[memory_ranges].start = start;
 		crash_memory_range[memory_ranges].end = end;
 		crash_memory_range[memory_ranges].type = type;
-		memory_ranges++;
 
-		/* Segregate linearly mapped region. */
-		if (lowmem_limit &&
-		    (lowmem_limit - 1) >= start && (lowmem_limit - 1) <= end) {
-			crash_memory_range[memory_ranges-1].end = lowmem_limit -1;
+		segregate_lowmem_region(&memory_ranges, lowmem_limit);
 
-			/* Add segregated region. */
-			crash_memory_range[memory_ranges].start = lowmem_limit;
-			crash_memory_range[memory_ranges].end = end;
-			crash_memory_range[memory_ranges].type = type;
-			memory_ranges++;
-		}
+		memory_ranges++;
 	}
 	fclose(fp);
 	if (kexec_flags & KEXEC_PRESERVE_CONTEXT) {
@@ -289,6 +281,30 @@ static int get_crash_memory_ranges(struct memory_range **range, int *ranges,
 	return 0;
 }
 
+static void segregate_lowmem_region(int *nr_ranges, unsigned long lowmem_limit)
+{
+	unsigned long long end, start;
+	unsigned type;
+
+	start = crash_memory_range[*nr_ranges].start;
+	end = crash_memory_range[*nr_ranges].end;
+	type = crash_memory_range[*nr_ranges].type;
+
+	if (!(lowmem_limit && lowmem_limit > start && lowmem_limit < end))
+		return;
+
+	crash_memory_range[*nr_ranges].end = lowmem_limit - 1;
+
+	if (*nr_ranges >= CRASH_MAX_MEMORY_RANGES - 1)
+		return;
+
+	++*nr_ranges;
+
+	crash_memory_range[*nr_ranges].start = lowmem_limit;
+	crash_memory_range[*nr_ranges].end = end;
+	crash_memory_range[*nr_ranges].type = type;
+}
+
 /* Removes crash reserve region from list of memory chunks for whom elf program
  * headers have to be created. Assuming crash reserve region to be a single
  * continuous area fully contained inside one of the memory chunks */
-- 
1.5.6.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 10 11:58:42 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Sep 2012 11:58: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 1TB2dE-00038A-Ey; Mon, 10 Sep 2012 11:58:24 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <SRS0=Ppt6=HJ=oracle.com=daniel.kiper@net-space.pl>)
	id 1TB2dC-00037h-Pd
	for xen-devel@lists.xensource.com; Mon, 10 Sep 2012 11:58:23 +0000
Received: from [85.158.138.51:27202] by server-10.bemta-3.messagelabs.com id
	79/75-10411-ED5DD405; Mon, 10 Sep 2012 11:58:22 +0000
X-Env-Sender: SRS0=Ppt6=HJ=oracle.com=daniel.kiper@net-space.pl
X-Msg-Ref: server-12.tower-174.messagelabs.com!1347278300!21748053!2
X-Originating-IP: [89.174.63.77]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16282 invoked from network); 10 Sep 2012 11:58:21 -0000
Received: from router-fw.net-space.pl (HELO router-fw.net-space.pl)
	(89.174.63.77)
	by server-12.tower-174.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 10 Sep 2012 11:58:21 -0000
Received: from dev-00.local.net-space.pl ([192.168.1.5]:48176 "EHLO
	localhost.localdomain" TLS-CIPHER: <none>)
	by router-fw-old.local.net-space.pl with ESMTP id S1621318Ab2IJL5w
	(ORCPT <rfc822;xen-devel@lists.xensource.com>);
	Mon, 10 Sep 2012 13:57:52 +0200
From: Daniel Kiper <daniel.kiper@oracle.com>
To: konrad.wilk@oracle.com, andrew.cooper3@citrix.com, olaf@aepfle.de,
	jbeulich@suse.com, ptesarik@suse.cz, kexec@lists.infradead.org,
	xen-devel@lists.xensource.com
Date: Mon, 10 Sep 2012 13:57:47 +0200
Message-Id: <1347278271-5211-4-git-send-email-daniel.kiper@oracle.com>
X-Mailer: git-send-email 1.5.6.5
In-Reply-To: <1347278271-5211-3-git-send-email-daniel.kiper@oracle.com>
References: <1347278271-5211-1-git-send-email-daniel.kiper@oracle.com>
	<1347278271-5211-2-git-send-email-daniel.kiper@oracle.com>
	<1347278271-5211-3-git-send-email-daniel.kiper@oracle.com>
X-Bogosity: No, spamicity=0.388031
Subject: [Xen-devel] [PATCH 3/7] kexec: Move crash kernel area placement and
	size detection to is_crashkernel_mem_reserved()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 crash kernel area placement and size detection
from get_crash_memory_ranges() to is_crashkernel_mem_reserved().
Former one will not be used by fixed Xen kdump support.

Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
---
 kexec/arch/i386/crashdump-x86.c |   17 ++++++++---------
 1 files changed, 8 insertions(+), 9 deletions(-)

diff --git a/kexec/arch/i386/crashdump-x86.c b/kexec/arch/i386/crashdump-x86.c
index 2af090c..ec9432b 100644
--- a/kexec/arch/i386/crashdump-x86.c
+++ b/kexec/arch/i386/crashdump-x86.c
@@ -212,13 +212,6 @@ static int get_crash_memory_ranges(struct memory_range **range, int *ranges,
 		/* Only Dumping memory of type System RAM. */
 		if (memcmp(str, "System RAM\n", 11) == 0) {
 			type = RANGE_RAM;
-		} else if (memcmp(str, "Crash kernel\n", 13) == 0) {
-				/* Reserved memory region. New kernel can
-				 * use this region to boot into. */
-				crash_reserved_mem.start = start;
-				crash_reserved_mem.end = end;
-				crash_reserved_mem.type = RANGE_RAM;
-				continue;
 		} else if (memcmp(str, "ACPI Tables\n", 12) == 0) {
 			/*
 			 * ACPI Tables area need to be passed to new
@@ -849,6 +842,12 @@ int is_crashkernel_mem_reserved(void)
 {
 	uint64_t start, end;
 
-	return parse_iomem_single("Crash kernel\n", &start, &end) == 0 ?
-	  (start != end) : 0;
+	if (parse_iomem_single("Crash kernel\n", &start, &end) || start == end)
+		return 0;
+
+	crash_reserved_mem.start = start;
+	crash_reserved_mem.end = end;
+	crash_reserved_mem.type = RANGE_RAM;
+
+	return 1;
 }
-- 
1.5.6.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 10 11:58:42 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Sep 2012 11:58: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 1TB2dF-00038h-I7; Mon, 10 Sep 2012 11:58:25 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <SRS0=Ppt6=HJ=oracle.com=daniel.kiper@net-space.pl>)
	id 1TB2dE-00037w-7Z
	for xen-devel@lists.xensource.com; Mon, 10 Sep 2012 11:58:24 +0000
Received: from [85.158.138.51:49485] by server-3.bemta-3.messagelabs.com id
	54/70-21322-FD5DD405; Mon, 10 Sep 2012 11:58:23 +0000
X-Env-Sender: SRS0=Ppt6=HJ=oracle.com=daniel.kiper@net-space.pl
X-Msg-Ref: server-12.tower-174.messagelabs.com!1347278300!21748053!7
X-Originating-IP: [89.174.63.77]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16451 invoked from network); 10 Sep 2012 11:58:22 -0000
Received: from router-fw.net-space.pl (HELO router-fw.net-space.pl)
	(89.174.63.77)
	by server-12.tower-174.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 10 Sep 2012 11:58:22 -0000
Received: from dev-00.local.net-space.pl ([192.168.1.5]:48176 "EHLO
	localhost.localdomain" TLS-CIPHER: <none>)
	by router-fw-old.local.net-space.pl with ESMTP id S1621323Ab2IJL5w
	(ORCPT <rfc822;xen-devel@lists.xensource.com>);
	Mon, 10 Sep 2012 13:57:52 +0200
From: Daniel Kiper <daniel.kiper@oracle.com>
To: konrad.wilk@oracle.com, andrew.cooper3@citrix.com, olaf@aepfle.de,
	jbeulich@suse.com, ptesarik@suse.cz, kexec@lists.infradead.org,
	xen-devel@lists.xensource.com
Date: Mon, 10 Sep 2012 13:57:48 +0200
Message-Id: <1347278271-5211-5-git-send-email-daniel.kiper@oracle.com>
X-Mailer: git-send-email 1.5.6.5
In-Reply-To: <1347278271-5211-4-git-send-email-daniel.kiper@oracle.com>
References: <1347278271-5211-1-git-send-email-daniel.kiper@oracle.com>
	<1347278271-5211-2-git-send-email-daniel.kiper@oracle.com>
	<1347278271-5211-3-git-send-email-daniel.kiper@oracle.com>
	<1347278271-5211-4-git-send-email-daniel.kiper@oracle.com>
X-Bogosity: No, spamicity=0.044690
Subject: [Xen-devel] [PATCH 4/7] kexec: Add segregate_lowmem_region()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Extract code segregating lowmem region and move it to new
segregate_lowmem_region(). This function will be used by
fixed Xen kdump support, too.

Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
---
 kexec/arch/i386/crashdump-x86.c |   38 +++++++++++++++++++++++++++-----------
 1 files changed, 27 insertions(+), 11 deletions(-)

diff --git a/kexec/arch/i386/crashdump-x86.c b/kexec/arch/i386/crashdump-x86.c
index ec9432b..77a1329 100644
--- a/kexec/arch/i386/crashdump-x86.c
+++ b/kexec/arch/i386/crashdump-x86.c
@@ -159,6 +159,7 @@ static int get_kernel_vaddr_and_size(struct kexec_info *UNUSED(info),
 }
 
 /* Forward Declaration. */
+static void segregate_lowmem_region(int *nr_ranges, unsigned long lowmem_limit);
 static int exclude_region(int *nr_ranges, uint64_t start, uint64_t end);
 
 /* Stores a sorted list of RAM memory ranges for which to create elf headers.
@@ -235,19 +236,10 @@ static int get_crash_memory_ranges(struct memory_range **range, int *ranges,
 		crash_memory_range[memory_ranges].start = start;
 		crash_memory_range[memory_ranges].end = end;
 		crash_memory_range[memory_ranges].type = type;
-		memory_ranges++;
 
-		/* Segregate linearly mapped region. */
-		if (lowmem_limit &&
-		    (lowmem_limit - 1) >= start && (lowmem_limit - 1) <= end) {
-			crash_memory_range[memory_ranges-1].end = lowmem_limit -1;
+		segregate_lowmem_region(&memory_ranges, lowmem_limit);
 
-			/* Add segregated region. */
-			crash_memory_range[memory_ranges].start = lowmem_limit;
-			crash_memory_range[memory_ranges].end = end;
-			crash_memory_range[memory_ranges].type = type;
-			memory_ranges++;
-		}
+		memory_ranges++;
 	}
 	fclose(fp);
 	if (kexec_flags & KEXEC_PRESERVE_CONTEXT) {
@@ -289,6 +281,30 @@ static int get_crash_memory_ranges(struct memory_range **range, int *ranges,
 	return 0;
 }
 
+static void segregate_lowmem_region(int *nr_ranges, unsigned long lowmem_limit)
+{
+	unsigned long long end, start;
+	unsigned type;
+
+	start = crash_memory_range[*nr_ranges].start;
+	end = crash_memory_range[*nr_ranges].end;
+	type = crash_memory_range[*nr_ranges].type;
+
+	if (!(lowmem_limit && lowmem_limit > start && lowmem_limit < end))
+		return;
+
+	crash_memory_range[*nr_ranges].end = lowmem_limit - 1;
+
+	if (*nr_ranges >= CRASH_MAX_MEMORY_RANGES - 1)
+		return;
+
+	++*nr_ranges;
+
+	crash_memory_range[*nr_ranges].start = lowmem_limit;
+	crash_memory_range[*nr_ranges].end = end;
+	crash_memory_range[*nr_ranges].type = type;
+}
+
 /* Removes crash reserve region from list of memory chunks for whom elf program
  * headers have to be created. Assuming crash reserve region to be a single
  * continuous area fully contained inside one of the memory chunks */
-- 
1.5.6.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 10 11:58:42 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Sep 2012 11:58: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 1TB2dE-00038A-Ey; Mon, 10 Sep 2012 11:58:24 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <SRS0=Ppt6=HJ=oracle.com=daniel.kiper@net-space.pl>)
	id 1TB2dC-00037h-Pd
	for xen-devel@lists.xensource.com; Mon, 10 Sep 2012 11:58:23 +0000
Received: from [85.158.138.51:27202] by server-10.bemta-3.messagelabs.com id
	79/75-10411-ED5DD405; Mon, 10 Sep 2012 11:58:22 +0000
X-Env-Sender: SRS0=Ppt6=HJ=oracle.com=daniel.kiper@net-space.pl
X-Msg-Ref: server-12.tower-174.messagelabs.com!1347278300!21748053!2
X-Originating-IP: [89.174.63.77]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16282 invoked from network); 10 Sep 2012 11:58:21 -0000
Received: from router-fw.net-space.pl (HELO router-fw.net-space.pl)
	(89.174.63.77)
	by server-12.tower-174.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 10 Sep 2012 11:58:21 -0000
Received: from dev-00.local.net-space.pl ([192.168.1.5]:48176 "EHLO
	localhost.localdomain" TLS-CIPHER: <none>)
	by router-fw-old.local.net-space.pl with ESMTP id S1621318Ab2IJL5w
	(ORCPT <rfc822;xen-devel@lists.xensource.com>);
	Mon, 10 Sep 2012 13:57:52 +0200
From: Daniel Kiper <daniel.kiper@oracle.com>
To: konrad.wilk@oracle.com, andrew.cooper3@citrix.com, olaf@aepfle.de,
	jbeulich@suse.com, ptesarik@suse.cz, kexec@lists.infradead.org,
	xen-devel@lists.xensource.com
Date: Mon, 10 Sep 2012 13:57:47 +0200
Message-Id: <1347278271-5211-4-git-send-email-daniel.kiper@oracle.com>
X-Mailer: git-send-email 1.5.6.5
In-Reply-To: <1347278271-5211-3-git-send-email-daniel.kiper@oracle.com>
References: <1347278271-5211-1-git-send-email-daniel.kiper@oracle.com>
	<1347278271-5211-2-git-send-email-daniel.kiper@oracle.com>
	<1347278271-5211-3-git-send-email-daniel.kiper@oracle.com>
X-Bogosity: No, spamicity=0.388031
Subject: [Xen-devel] [PATCH 3/7] kexec: Move crash kernel area placement and
	size detection to is_crashkernel_mem_reserved()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 crash kernel area placement and size detection
from get_crash_memory_ranges() to is_crashkernel_mem_reserved().
Former one will not be used by fixed Xen kdump support.

Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
---
 kexec/arch/i386/crashdump-x86.c |   17 ++++++++---------
 1 files changed, 8 insertions(+), 9 deletions(-)

diff --git a/kexec/arch/i386/crashdump-x86.c b/kexec/arch/i386/crashdump-x86.c
index 2af090c..ec9432b 100644
--- a/kexec/arch/i386/crashdump-x86.c
+++ b/kexec/arch/i386/crashdump-x86.c
@@ -212,13 +212,6 @@ static int get_crash_memory_ranges(struct memory_range **range, int *ranges,
 		/* Only Dumping memory of type System RAM. */
 		if (memcmp(str, "System RAM\n", 11) == 0) {
 			type = RANGE_RAM;
-		} else if (memcmp(str, "Crash kernel\n", 13) == 0) {
-				/* Reserved memory region. New kernel can
-				 * use this region to boot into. */
-				crash_reserved_mem.start = start;
-				crash_reserved_mem.end = end;
-				crash_reserved_mem.type = RANGE_RAM;
-				continue;
 		} else if (memcmp(str, "ACPI Tables\n", 12) == 0) {
 			/*
 			 * ACPI Tables area need to be passed to new
@@ -849,6 +842,12 @@ int is_crashkernel_mem_reserved(void)
 {
 	uint64_t start, end;
 
-	return parse_iomem_single("Crash kernel\n", &start, &end) == 0 ?
-	  (start != end) : 0;
+	if (parse_iomem_single("Crash kernel\n", &start, &end) || start == end)
+		return 0;
+
+	crash_reserved_mem.start = start;
+	crash_reserved_mem.end = end;
+	crash_reserved_mem.type = RANGE_RAM;
+
+	return 1;
 }
-- 
1.5.6.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 10 12:06:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Sep 2012 12:06:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TB2lM-0004iL-Ap; Mon, 10 Sep 2012 12:06:48 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <daniel.kiper@oracle.com>) id 1TB2lL-0004iC-1k
	for xen-devel@lists.xensource.com; Mon, 10 Sep 2012 12:06:47 +0000
Received: from [85.158.139.83:55787] by server-9.bemta-5.messagelabs.com id
	88/2E-20529-6D7DD405; Mon, 10 Sep 2012 12:06:46 +0000
X-Env-Sender: daniel.kiper@oracle.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1347278804!27413308!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDc0NzYwMw==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27328 invoked from network); 10 Sep 2012 12:06:45 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-15.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 10 Sep 2012 12:06:45 -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 q8AC6ZId017802
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 10 Sep 2012 12:06:36 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
	q8AC6X87023666
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 10 Sep 2012 12:06:34 GMT
Received: from abhmt115.oracle.com (abhmt115.oracle.com [141.146.116.67])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q8AC6Vgw024607; Mon, 10 Sep 2012 07:06:31 -0500
MIME-Version: 1.0
Message-ID: <6b55cbb0-bef3-4105-b99d-69d4a610a7a5@default>
Date: Mon, 10 Sep 2012 05:06:31 -0700 (PDT)
From: Daniel Kiper <daniel.kiper@oracle.com>
To: <ptesarik@suse.cz>
X-Mailer: Zimbra on Oracle Beehive
Content-Disposition: inline
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: olaf@aepfle.de, xen-devel@lists.xensource.com, kexec@lists.infradead.org,
	horms@verge.net.au, konrad.wilk@oracle.com
Subject: Re: [Xen-devel] [PATCH] kexec-tools: Read always one vmcoreinfo file
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi Petr,

[...]

> > > As I know Petr was going to do some tests.
> > > I have not received any reply from him till now.
> > > Maybe he is busy or on vacation.
> >
> > According to automatic reply he is on vacation until 13/08/2012.
>
> Thanks. I guess we should wait then.

Have you done some tests of this patch?
Did you find any issues with it?

Daniel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 10 12:06:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Sep 2012 12:06:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TB2lM-0004iL-Ap; Mon, 10 Sep 2012 12:06:48 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <daniel.kiper@oracle.com>) id 1TB2lL-0004iC-1k
	for xen-devel@lists.xensource.com; Mon, 10 Sep 2012 12:06:47 +0000
Received: from [85.158.139.83:55787] by server-9.bemta-5.messagelabs.com id
	88/2E-20529-6D7DD405; Mon, 10 Sep 2012 12:06:46 +0000
X-Env-Sender: daniel.kiper@oracle.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1347278804!27413308!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDc0NzYwMw==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27328 invoked from network); 10 Sep 2012 12:06:45 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-15.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 10 Sep 2012 12:06:45 -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 q8AC6ZId017802
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 10 Sep 2012 12:06:36 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
	q8AC6X87023666
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 10 Sep 2012 12:06:34 GMT
Received: from abhmt115.oracle.com (abhmt115.oracle.com [141.146.116.67])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q8AC6Vgw024607; Mon, 10 Sep 2012 07:06:31 -0500
MIME-Version: 1.0
Message-ID: <6b55cbb0-bef3-4105-b99d-69d4a610a7a5@default>
Date: Mon, 10 Sep 2012 05:06:31 -0700 (PDT)
From: Daniel Kiper <daniel.kiper@oracle.com>
To: <ptesarik@suse.cz>
X-Mailer: Zimbra on Oracle Beehive
Content-Disposition: inline
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: olaf@aepfle.de, xen-devel@lists.xensource.com, kexec@lists.infradead.org,
	horms@verge.net.au, konrad.wilk@oracle.com
Subject: Re: [Xen-devel] [PATCH] kexec-tools: Read always one vmcoreinfo file
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi Petr,

[...]

> > > As I know Petr was going to do some tests.
> > > I have not received any reply from him till now.
> > > Maybe he is busy or on vacation.
> >
> > According to automatic reply he is on vacation until 13/08/2012.
>
> Thanks. I guess we should wait then.

Have you done some tests of this patch?
Did you find any issues with it?

Daniel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 10 12:21:24 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Sep 2012 12:21: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 1TB2zI-0005sb-A6; Mon, 10 Sep 2012 12:21:12 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ashok.anand@gmail.com>) id 1TB2zG-0005sJ-Qi
	for xen-devel@lists.xen.org; Mon, 10 Sep 2012 12:21:11 +0000
Received: from [85.158.139.83:9784] by server-7.bemta-5.messagelabs.com id
	59/15-19703-53BDD405; Mon, 10 Sep 2012 12:21:09 +0000
X-Env-Sender: ashok.anand@gmail.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1347279632!18312833!1
X-Originating-IP: [209.85.219.45]
X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_20_30,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31854 invoked from network); 10 Sep 2012 12:20:34 -0000
Received: from mail-oa0-f45.google.com (HELO mail-oa0-f45.google.com)
	(209.85.219.45)
	by server-8.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Sep 2012 12:20:34 -0000
Received: by oagn12 with SMTP id n12so637235oag.32
	for <multiple recipients>; Mon, 10 Sep 2012 05:20:32 -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=QYHCLmCYjBVljXrIHSZnh3NFMgo8HtYTtIf1KMcCu1M=;
	b=kxY4GVF/d7yafPh3nEwgRS9Ygn1RlXjTsoxgV9XZF5EDh1mNTiimIvVA35kbM/UOk0
	8T3CO3tGDpfEeFIlPE0uLhBgSZS4OI12Y/abZMcDpPr7tG9/hxmnsfx2QN8yXvijOzIP
	sLVfdDK3rDf8pTPFTChpvMjcIYn5PK5TcmMRGIreHkzV6w1AfOkEIWjQ+lM3+7Jq7NYt
	L4DVKsoXZ3X9KU2TqgRP/4A+1uA/+tl98dTviLJ+aCZqF1PQdUIGzgfhRgH1nfGnb1Km
	CpxKC+EFqNr18KhCdpD96i9U1DIDrj6/V3tJ5ubYepMxeyPbvfDmV9UmndVoww4reW4l
	82fQ==
MIME-Version: 1.0
Received: by 10.60.0.161 with SMTP id 1mr14193735oef.83.1347279632193; Mon, 10
	Sep 2012 05:20:32 -0700 (PDT)
Received: by 10.182.32.102 with HTTP; Mon, 10 Sep 2012 05:20:32 -0700 (PDT)
Date: Mon, 10 Sep 2012 17:50:32 +0530
Message-ID: <CALQsBOVDtcw35QTJ2xrbKLDfsmmwbyUS_y0TPObx65dVuNcVJQ@mail.gmail.com>
From: Ashok Anand <ashok.anand@gmail.com>
To: xen-devel@lists.xen.org, xen-users@lists.xen.org
Subject: [Xen-devel] memory snapshot
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1841784841484527799=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============1841784841484527799==
Content-Type: multipart/alternative; boundary=e89a8fb1ffc2e3d9d604c957fbd9

--e89a8fb1ffc2e3d9d604c957fbd9
Content-Type: text/plain; charset=ISO-8859-1

Hi,

I want to take the snapshot of only physical memory of a VM.
I know that we can take memory dump of a VM, using xm dump-core, or using
xm save.
However, with these tools, the dumped (or saved) file would have some
headers/metadata along with
the memory contents.
So, I am wondering if there is a tool, that can help me to give only memory
contents (headers removed),
or alternatively, if there is a tool that can remove these
headers/metadata, and give the memory content back.

Any thoughts?

Regards.,
Ashok

--e89a8fb1ffc2e3d9d604c957fbd9
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi,=A0<div><br></div><div>I want to take the snapshot of only physical memo=
ry of a VM.=A0</div><div>I know that we can take memory dump of a VM, using=
 xm dump-core, or using xm save.</div><div>However, with these tools, the d=
umped (or saved) file would have some headers/metadata along with</div>
<div>the memory contents.</div><div>So, I am wondering if there is a tool, =
that can help me to give only memory contents (headers removed),</div><div>=
or alternatively, if there is a tool that can remove these headers/metadata=
, and give the memory content back.</div>
<div><br></div><div>Any thoughts?</div><div><br></div><div>Regards.,</div><=
div>Ashok</div>

--e89a8fb1ffc2e3d9d604c957fbd9--


--===============1841784841484527799==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============1841784841484527799==--


From xen-devel-bounces@lists.xen.org Mon Sep 10 12:21:24 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Sep 2012 12:21: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 1TB2zI-0005sb-A6; Mon, 10 Sep 2012 12:21:12 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ashok.anand@gmail.com>) id 1TB2zG-0005sJ-Qi
	for xen-devel@lists.xen.org; Mon, 10 Sep 2012 12:21:11 +0000
Received: from [85.158.139.83:9784] by server-7.bemta-5.messagelabs.com id
	59/15-19703-53BDD405; Mon, 10 Sep 2012 12:21:09 +0000
X-Env-Sender: ashok.anand@gmail.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1347279632!18312833!1
X-Originating-IP: [209.85.219.45]
X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_20_30,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31854 invoked from network); 10 Sep 2012 12:20:34 -0000
Received: from mail-oa0-f45.google.com (HELO mail-oa0-f45.google.com)
	(209.85.219.45)
	by server-8.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Sep 2012 12:20:34 -0000
Received: by oagn12 with SMTP id n12so637235oag.32
	for <multiple recipients>; Mon, 10 Sep 2012 05:20:32 -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=QYHCLmCYjBVljXrIHSZnh3NFMgo8HtYTtIf1KMcCu1M=;
	b=kxY4GVF/d7yafPh3nEwgRS9Ygn1RlXjTsoxgV9XZF5EDh1mNTiimIvVA35kbM/UOk0
	8T3CO3tGDpfEeFIlPE0uLhBgSZS4OI12Y/abZMcDpPr7tG9/hxmnsfx2QN8yXvijOzIP
	sLVfdDK3rDf8pTPFTChpvMjcIYn5PK5TcmMRGIreHkzV6w1AfOkEIWjQ+lM3+7Jq7NYt
	L4DVKsoXZ3X9KU2TqgRP/4A+1uA/+tl98dTviLJ+aCZqF1PQdUIGzgfhRgH1nfGnb1Km
	CpxKC+EFqNr18KhCdpD96i9U1DIDrj6/V3tJ5ubYepMxeyPbvfDmV9UmndVoww4reW4l
	82fQ==
MIME-Version: 1.0
Received: by 10.60.0.161 with SMTP id 1mr14193735oef.83.1347279632193; Mon, 10
	Sep 2012 05:20:32 -0700 (PDT)
Received: by 10.182.32.102 with HTTP; Mon, 10 Sep 2012 05:20:32 -0700 (PDT)
Date: Mon, 10 Sep 2012 17:50:32 +0530
Message-ID: <CALQsBOVDtcw35QTJ2xrbKLDfsmmwbyUS_y0TPObx65dVuNcVJQ@mail.gmail.com>
From: Ashok Anand <ashok.anand@gmail.com>
To: xen-devel@lists.xen.org, xen-users@lists.xen.org
Subject: [Xen-devel] memory snapshot
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1841784841484527799=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============1841784841484527799==
Content-Type: multipart/alternative; boundary=e89a8fb1ffc2e3d9d604c957fbd9

--e89a8fb1ffc2e3d9d604c957fbd9
Content-Type: text/plain; charset=ISO-8859-1

Hi,

I want to take the snapshot of only physical memory of a VM.
I know that we can take memory dump of a VM, using xm dump-core, or using
xm save.
However, with these tools, the dumped (or saved) file would have some
headers/metadata along with
the memory contents.
So, I am wondering if there is a tool, that can help me to give only memory
contents (headers removed),
or alternatively, if there is a tool that can remove these
headers/metadata, and give the memory content back.

Any thoughts?

Regards.,
Ashok

--e89a8fb1ffc2e3d9d604c957fbd9
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi,=A0<div><br></div><div>I want to take the snapshot of only physical memo=
ry of a VM.=A0</div><div>I know that we can take memory dump of a VM, using=
 xm dump-core, or using xm save.</div><div>However, with these tools, the d=
umped (or saved) file would have some headers/metadata along with</div>
<div>the memory contents.</div><div>So, I am wondering if there is a tool, =
that can help me to give only memory contents (headers removed),</div><div>=
or alternatively, if there is a tool that can remove these headers/metadata=
, and give the memory content back.</div>
<div><br></div><div>Any thoughts?</div><div><br></div><div>Regards.,</div><=
div>Ashok</div>

--e89a8fb1ffc2e3d9d604c957fbd9--


--===============1841784841484527799==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============1841784841484527799==--


From xen-devel-bounces@lists.xen.org Mon Sep 10 12:47:51 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Sep 2012 12:47:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TB3Ol-0006rq-8s; Mon, 10 Sep 2012 12:47:31 +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 1TB3Oj-0006rl-Dj
	for xen-devel@lists.xensource.com; Mon, 10 Sep 2012 12:47:29 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1347281204!9100788!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTIyODk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30057 invoked from network); 10 Sep 2012 12:46:44 -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;
	10 Sep 2012 12:46:44 -0000
X-IronPort-AV: E=Sophos;i="4.80,398,1344211200"; d="scan'208";a="14442791"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Sep 2012 12:46: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.279.1; Mon, 10 Sep 2012 13:46: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 1TB3Nz-0003uw-PC;
	Mon, 10 Sep 2012 12:46:43 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1TB3Nz-0001Mk-Li;
	Mon, 10 Sep 2012 13:46:43 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-13666-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Mon, 10 Sep 2012 13:46:43 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.2-testing baseline test] 13666: tolerable FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

"Old" tested version had not actually been tested; therefore in this
flight we test it, rather than a new candidate.  The baseline, if
any, is the most recent actually tested revision.

flight 13666 xen-4.2-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13666/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-pv           1 xen-build-check(1)          blocked never pass
 test-amd64-i386-pv            1 xen-build-check(1)          blocked never pass
 test-amd64-i386-qemuu-rhel6hvm-amd  1 xen-build-check(1)    blocked never pass
 test-amd64-amd64-xl-sedf      1 xen-build-check(1)          blocked never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  1 xen-build-check(1)    blocked never pass
 test-amd64-i386-rhel6hvm-amd  1 xen-build-check(1)          blocked never pass
 test-amd64-amd64-win          1 xen-build-check(1)          blocked never pass
 test-i386-i386-xl-qemuu-winxpsp3  1 xen-build-check(1)      blocked never pass
 test-i386-i386-win            1 xen-build-check(1)          blocked never pass
 test-amd64-i386-xl-winxpsp3-vcpus1  1 xen-build-check(1)    blocked never pass
 test-amd64-amd64-xl-pcipt-intel  1 xen-build-check(1)       blocked never pass
 test-amd64-i386-xl-win-vcpus1  1 xen-build-check(1)         blocked never pass
 test-amd64-i386-xl-multivcpu  1 xen-build-check(1)          blocked never pass
 test-i386-i386-pv             1 xen-build-check(1)          blocked never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  1 xen-build-check(1)  blocked never pass
 test-amd64-i386-win-vcpus1    1 xen-build-check(1)          blocked never pass
 test-amd64-i386-xl-win7-amd64  1 xen-build-check(1)         blocked never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  1 xen-build-check(1)  blocked never pass
 test-amd64-i386-rhel6hvm-intel  1 xen-build-check(1)        blocked never pass
 test-i386-i386-xl-win         1 xen-build-check(1)          blocked never pass
 test-amd64-amd64-xl-win7-amd64  1 xen-build-check(1)        blocked never pass
 test-amd64-i386-win           1 xen-build-check(1)          blocked never pass
 test-amd64-amd64-xl-winxpsp3  1 xen-build-check(1)          blocked never pass
 test-amd64-i386-xend-winxpsp3  1 xen-build-check(1)         blocked never pass
 test-i386-i386-xl             1 xen-build-check(1)          blocked never pass
 test-i386-i386-xl-winxpsp3    1 xen-build-check(1)          blocked never pass
 test-amd64-amd64-xl           1 xen-build-check(1)          blocked never pass
 test-amd64-i386-xl-credit2    1 xen-build-check(1)          blocked never pass
 test-amd64-amd64-xl-win       1 xen-build-check(1)          blocked never pass
 test-amd64-i386-xl            1 xen-build-check(1)          blocked never pass
 test-i386-i386-pair           1 xen-build-check(1)          blocked never pass
 test-amd64-amd64-xl-sedf-pin  1 xen-build-check(1)          blocked never pass
 test-amd64-amd64-pair         1 xen-build-check(1)          blocked never pass
 test-amd64-i386-pair          1 xen-build-check(1)          blocked never pass
 build-i386                    4 xen-build                    fail   never pass
 build-i386-oldkern            4 xen-build                    fail   never pass
 build-amd64-oldkern           4 xen-build                    fail   never pass
 build-amd64                   4 xen-build                    fail   never pass

version targeted for testing:
 xen                  ec23c2a11f6f
baseline version:
 xen                  ec23c2a11f6f

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-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


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 Sep 10 12:47:51 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Sep 2012 12:47:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TB3Ol-0006rq-8s; Mon, 10 Sep 2012 12:47:31 +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 1TB3Oj-0006rl-Dj
	for xen-devel@lists.xensource.com; Mon, 10 Sep 2012 12:47:29 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1347281204!9100788!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTIyODk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30057 invoked from network); 10 Sep 2012 12:46:44 -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;
	10 Sep 2012 12:46:44 -0000
X-IronPort-AV: E=Sophos;i="4.80,398,1344211200"; d="scan'208";a="14442791"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Sep 2012 12:46: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.279.1; Mon, 10 Sep 2012 13:46: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 1TB3Nz-0003uw-PC;
	Mon, 10 Sep 2012 12:46:43 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1TB3Nz-0001Mk-Li;
	Mon, 10 Sep 2012 13:46:43 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-13666-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Mon, 10 Sep 2012 13:46:43 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.2-testing baseline test] 13666: tolerable FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

"Old" tested version had not actually been tested; therefore in this
flight we test it, rather than a new candidate.  The baseline, if
any, is the most recent actually tested revision.

flight 13666 xen-4.2-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13666/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-pv           1 xen-build-check(1)          blocked never pass
 test-amd64-i386-pv            1 xen-build-check(1)          blocked never pass
 test-amd64-i386-qemuu-rhel6hvm-amd  1 xen-build-check(1)    blocked never pass
 test-amd64-amd64-xl-sedf      1 xen-build-check(1)          blocked never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  1 xen-build-check(1)    blocked never pass
 test-amd64-i386-rhel6hvm-amd  1 xen-build-check(1)          blocked never pass
 test-amd64-amd64-win          1 xen-build-check(1)          blocked never pass
 test-i386-i386-xl-qemuu-winxpsp3  1 xen-build-check(1)      blocked never pass
 test-i386-i386-win            1 xen-build-check(1)          blocked never pass
 test-amd64-i386-xl-winxpsp3-vcpus1  1 xen-build-check(1)    blocked never pass
 test-amd64-amd64-xl-pcipt-intel  1 xen-build-check(1)       blocked never pass
 test-amd64-i386-xl-win-vcpus1  1 xen-build-check(1)         blocked never pass
 test-amd64-i386-xl-multivcpu  1 xen-build-check(1)          blocked never pass
 test-i386-i386-pv             1 xen-build-check(1)          blocked never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  1 xen-build-check(1)  blocked never pass
 test-amd64-i386-win-vcpus1    1 xen-build-check(1)          blocked never pass
 test-amd64-i386-xl-win7-amd64  1 xen-build-check(1)         blocked never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  1 xen-build-check(1)  blocked never pass
 test-amd64-i386-rhel6hvm-intel  1 xen-build-check(1)        blocked never pass
 test-i386-i386-xl-win         1 xen-build-check(1)          blocked never pass
 test-amd64-amd64-xl-win7-amd64  1 xen-build-check(1)        blocked never pass
 test-amd64-i386-win           1 xen-build-check(1)          blocked never pass
 test-amd64-amd64-xl-winxpsp3  1 xen-build-check(1)          blocked never pass
 test-amd64-i386-xend-winxpsp3  1 xen-build-check(1)         blocked never pass
 test-i386-i386-xl             1 xen-build-check(1)          blocked never pass
 test-i386-i386-xl-winxpsp3    1 xen-build-check(1)          blocked never pass
 test-amd64-amd64-xl           1 xen-build-check(1)          blocked never pass
 test-amd64-i386-xl-credit2    1 xen-build-check(1)          blocked never pass
 test-amd64-amd64-xl-win       1 xen-build-check(1)          blocked never pass
 test-amd64-i386-xl            1 xen-build-check(1)          blocked never pass
 test-i386-i386-pair           1 xen-build-check(1)          blocked never pass
 test-amd64-amd64-xl-sedf-pin  1 xen-build-check(1)          blocked never pass
 test-amd64-amd64-pair         1 xen-build-check(1)          blocked never pass
 test-amd64-i386-pair          1 xen-build-check(1)          blocked never pass
 build-i386                    4 xen-build                    fail   never pass
 build-i386-oldkern            4 xen-build                    fail   never pass
 build-amd64-oldkern           4 xen-build                    fail   never pass
 build-amd64                   4 xen-build                    fail   never pass

version targeted for testing:
 xen                  ec23c2a11f6f
baseline version:
 xen                  ec23c2a11f6f

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-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


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 Sep 10 12:49:00 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Sep 2012 12:49:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TB3Px-0006vH-Np; Mon, 10 Sep 2012 12:48:45 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <gbtju85@gmail.com>) id 1TB3Pw-0006v6-91
	for xen-devel@lists.xen.org; Mon, 10 Sep 2012 12:48:44 +0000
Received: from [85.158.143.35:21378] by server-3.bemta-4.messagelabs.com id
	D4/65-08232-BA1ED405; Mon, 10 Sep 2012 12:48:43 +0000
X-Env-Sender: gbtju85@gmail.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1347281321!15020173!1
X-Originating-IP: [209.85.217.173]
X-SpamReason: No, hits=0.9 required=7.0 tests=HTML_40_50,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 906 invoked from network); 10 Sep 2012 12:48:42 -0000
Received: from mail-lb0-f173.google.com (HELO mail-lb0-f173.google.com)
	(209.85.217.173)
	by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Sep 2012 12:48:42 -0000
Received: by lbbgm13 with SMTP id gm13so1450435lbb.32
	for <xen-devel@lists.xen.org>; Mon, 10 Sep 2012 05:48:41 -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=9ryq5C7q0EBrcn5iT1mfNwFlUVi83mxAKXiaQ4up/7M=;
	b=Zt93aMVzpsdiZYou7O5LKHSConGyc+6VPkY5RseGEFUxsodKnZjoSuZokIRWQkiMpP
	2yAGa6U8EOlX9pgbnxeIKbmn4EsiihOhz8QCH4HSz+S7T7vOIgoGGBu7sY26NyeGdsfO
	XeL9NJ4w7lrPJBn4LF3h7fTUjnxmC8zSjFYCai0S0d7eIUVZ0LV6slT7+M7xVIKbNLmP
	Ne8wwNcslxj0FfAzwsUkCodj1pf3dpoCuJGnOl8xcf8GyJNur8bQiZIXf3GZfZ5iB4XO
	C1Ob/R1qTW04zOV77V2IbKdvmihicGdSYBK9pAIH5xDaKChsdBwTBQFY4unNMC1hdI2E
	eQOg==
MIME-Version: 1.0
Received: by 10.152.103.11 with SMTP id fs11mr12401450lab.23.1347281321642;
	Mon, 10 Sep 2012 05:48:41 -0700 (PDT)
Received: by 10.114.2.193 with HTTP; Mon, 10 Sep 2012 05:48:41 -0700 (PDT)
Date: Mon, 10 Sep 2012 20:48:41 +0800
Message-ID: <CAEQjb-TO9wy74up6pGfaRj+FQH8SPJtLXngM70ivWwWaQ53QPA@mail.gmail.com>
From: Bei Guan <gbtju85@gmail.com>
To: xen-devel <xen-devel@lists.xen.org>
Subject: [Xen-devel] Any news or plan about Xen support the APU
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============4794528832237924586=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============4794528832237924586==
Content-Type: multipart/alternative; boundary=f46d040715c596ca1a04c958600c

--f46d040715c596ca1a04c958600c
Content-Type: text/plain; charset=ISO-8859-1

Hi,

Is there any news or plan about Xen support the latest AMD hardware APU
(Accelerated Processing Unit)? Any clue is appreciated.
Thank you very much.



Best Regards,
Bei Guan

--f46d040715c596ca1a04c958600c
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi,<div><br></div><div>Is there any news or plan about Xen support the late=
st=A0AMD=A0hardware APU (Accelerated Processing Unit)? Any clue is apprecia=
ted.=A0</div><div>Thank you very much.</div><div><div><span lang=3D"EN-US" =
style><br>
</span></div><div><span lang=3D"EN-US" style><br></span></div><div><br></di=
v>Best Regards,<div>Bei Guan</div><br>
</div>

--f46d040715c596ca1a04c958600c--


--===============4794528832237924586==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============4794528832237924586==--


From xen-devel-bounces@lists.xen.org Mon Sep 10 12:49:00 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Sep 2012 12:49:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TB3Px-0006vH-Np; Mon, 10 Sep 2012 12:48:45 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <gbtju85@gmail.com>) id 1TB3Pw-0006v6-91
	for xen-devel@lists.xen.org; Mon, 10 Sep 2012 12:48:44 +0000
Received: from [85.158.143.35:21378] by server-3.bemta-4.messagelabs.com id
	D4/65-08232-BA1ED405; Mon, 10 Sep 2012 12:48:43 +0000
X-Env-Sender: gbtju85@gmail.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1347281321!15020173!1
X-Originating-IP: [209.85.217.173]
X-SpamReason: No, hits=0.9 required=7.0 tests=HTML_40_50,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 906 invoked from network); 10 Sep 2012 12:48:42 -0000
Received: from mail-lb0-f173.google.com (HELO mail-lb0-f173.google.com)
	(209.85.217.173)
	by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Sep 2012 12:48:42 -0000
Received: by lbbgm13 with SMTP id gm13so1450435lbb.32
	for <xen-devel@lists.xen.org>; Mon, 10 Sep 2012 05:48:41 -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=9ryq5C7q0EBrcn5iT1mfNwFlUVi83mxAKXiaQ4up/7M=;
	b=Zt93aMVzpsdiZYou7O5LKHSConGyc+6VPkY5RseGEFUxsodKnZjoSuZokIRWQkiMpP
	2yAGa6U8EOlX9pgbnxeIKbmn4EsiihOhz8QCH4HSz+S7T7vOIgoGGBu7sY26NyeGdsfO
	XeL9NJ4w7lrPJBn4LF3h7fTUjnxmC8zSjFYCai0S0d7eIUVZ0LV6slT7+M7xVIKbNLmP
	Ne8wwNcslxj0FfAzwsUkCodj1pf3dpoCuJGnOl8xcf8GyJNur8bQiZIXf3GZfZ5iB4XO
	C1Ob/R1qTW04zOV77V2IbKdvmihicGdSYBK9pAIH5xDaKChsdBwTBQFY4unNMC1hdI2E
	eQOg==
MIME-Version: 1.0
Received: by 10.152.103.11 with SMTP id fs11mr12401450lab.23.1347281321642;
	Mon, 10 Sep 2012 05:48:41 -0700 (PDT)
Received: by 10.114.2.193 with HTTP; Mon, 10 Sep 2012 05:48:41 -0700 (PDT)
Date: Mon, 10 Sep 2012 20:48:41 +0800
Message-ID: <CAEQjb-TO9wy74up6pGfaRj+FQH8SPJtLXngM70ivWwWaQ53QPA@mail.gmail.com>
From: Bei Guan <gbtju85@gmail.com>
To: xen-devel <xen-devel@lists.xen.org>
Subject: [Xen-devel] Any news or plan about Xen support the APU
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============4794528832237924586=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============4794528832237924586==
Content-Type: multipart/alternative; boundary=f46d040715c596ca1a04c958600c

--f46d040715c596ca1a04c958600c
Content-Type: text/plain; charset=ISO-8859-1

Hi,

Is there any news or plan about Xen support the latest AMD hardware APU
(Accelerated Processing Unit)? Any clue is appreciated.
Thank you very much.



Best Regards,
Bei Guan

--f46d040715c596ca1a04c958600c
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi,<div><br></div><div>Is there any news or plan about Xen support the late=
st=A0AMD=A0hardware APU (Accelerated Processing Unit)? Any clue is apprecia=
ted.=A0</div><div>Thank you very much.</div><div><div><span lang=3D"EN-US" =
style><br>
</span></div><div><span lang=3D"EN-US" style><br></span></div><div><br></di=
v>Best Regards,<div>Bei Guan</div><br>
</div>

--f46d040715c596ca1a04c958600c--


--===============4794528832237924586==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============4794528832237924586==--


From xen-devel-bounces@lists.xen.org Mon Sep 10 13:00:01 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Sep 2012 13:00: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 1TB3aP-0007AV-SD; Mon, 10 Sep 2012 12:59:33 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1TB3aO-0007AQ-Py
	for xen-devel@lists.xen.org; Mon, 10 Sep 2012 12:59:33 +0000
Received: from [85.158.138.51:56447] by server-5.bemta-3.messagelabs.com id
	B2/F3-13133-334ED405; Mon, 10 Sep 2012 12:59:31 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1347281971!20807664!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM5OTE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6617 invoked from network); 10 Sep 2012 12:59:31 -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;
	10 Sep 2012 12:59:31 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 10 Sep 2012 13:59:30 +0100
Message-Id: <504E004F020000780009A35F@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 10 Sep 2012 13:59:27 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Andrew Cooper" <andrew.cooper3@citrix.com>
References: <CC6FFE8E.3E156%keir.xen@gmail.com> <504A4619.90707@citrix.com>
In-Reply-To: <504A4619.90707@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Keir Fraser <keir.xen@gmail.com>, "Keir \(Xen.org\)" <keir@xen.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Hypervisor memory leak/corruption because of guest
	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 07.09.12 at 21:08, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
> Its not completely trivial to turn it into a discriminated union (in an
> acceptable way), as irq_desc and irqaction is common while
> irq_guest_action_t is x86 specific (and irq.c private, currently),
> meaning the introduction of an arch_irqaction.
> 
> Now that the two actions are different, you could perhaps convert
> __do_IRQ_guest() to be the 'handler' of the irqaction, which appears to
> cause large amounts of "if(desc->status & IRQ_GUEST) then do something"
> code to fall out.  Continuing along this line leads to large amounts of
> code change.
> 
> I will see about working on a bare minimum patch to make the teardown of
> guest IRQs safe, but I dont think it will be very small, and it will
> open the way for some cleanup.

Is there any reason why simply tying the removal of the timer
to the clearing of IRQ_GUEST isn't possible? This is basically
already the case for __pirq_guest_unbind() (where the caller
takes care of correctly dealing with the returned action pointer).

Hence if dynamic_irq_cleanup() indeed can be reached with the
flag still set, it would seem quite obvious that this simply needs
adding similar treatment. But I would have expected that the
unbind path should be taken in any case (and destroy_irq()
only be used for subsequent, final cleanup) - is there perhaps
a problem in when the forced unbind happens?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 10 13:00:01 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Sep 2012 13:00: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 1TB3aP-0007AV-SD; Mon, 10 Sep 2012 12:59:33 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1TB3aO-0007AQ-Py
	for xen-devel@lists.xen.org; Mon, 10 Sep 2012 12:59:33 +0000
Received: from [85.158.138.51:56447] by server-5.bemta-3.messagelabs.com id
	B2/F3-13133-334ED405; Mon, 10 Sep 2012 12:59:31 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1347281971!20807664!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM5OTE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6617 invoked from network); 10 Sep 2012 12:59:31 -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;
	10 Sep 2012 12:59:31 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 10 Sep 2012 13:59:30 +0100
Message-Id: <504E004F020000780009A35F@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 10 Sep 2012 13:59:27 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Andrew Cooper" <andrew.cooper3@citrix.com>
References: <CC6FFE8E.3E156%keir.xen@gmail.com> <504A4619.90707@citrix.com>
In-Reply-To: <504A4619.90707@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Keir Fraser <keir.xen@gmail.com>, "Keir \(Xen.org\)" <keir@xen.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Hypervisor memory leak/corruption because of guest
	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 07.09.12 at 21:08, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
> Its not completely trivial to turn it into a discriminated union (in an
> acceptable way), as irq_desc and irqaction is common while
> irq_guest_action_t is x86 specific (and irq.c private, currently),
> meaning the introduction of an arch_irqaction.
> 
> Now that the two actions are different, you could perhaps convert
> __do_IRQ_guest() to be the 'handler' of the irqaction, which appears to
> cause large amounts of "if(desc->status & IRQ_GUEST) then do something"
> code to fall out.  Continuing along this line leads to large amounts of
> code change.
> 
> I will see about working on a bare minimum patch to make the teardown of
> guest IRQs safe, but I dont think it will be very small, and it will
> open the way for some cleanup.

Is there any reason why simply tying the removal of the timer
to the clearing of IRQ_GUEST isn't possible? This is basically
already the case for __pirq_guest_unbind() (where the caller
takes care of correctly dealing with the returned action pointer).

Hence if dynamic_irq_cleanup() indeed can be reached with the
flag still set, it would seem quite obvious that this simply needs
adding similar treatment. But I would have expected that the
unbind path should be taken in any case (and destroy_irq()
only be used for subsequent, final cleanup) - is there perhaps
a problem in when the forced unbind happens?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 10 13:00:31 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Sep 2012 13:00: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 1TB3b4-0007EU-9U; Mon, 10 Sep 2012 13:00:14 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <julien.grall@citrix.com>) id 1TB3b3-0007EL-8n
	for xen-devel@lists.xen.org; Mon, 10 Sep 2012 13:00:13 +0000
Received: from [85.158.143.99:46254] by server-3.bemta-4.messagelabs.com id
	72/0E-08232-C54ED405; Mon, 10 Sep 2012 13:00:12 +0000
X-Env-Sender: julien.grall@citrix.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1347282009!29189206!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNzc5Njk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21132 invoked from network); 10 Sep 2012 13:00:11 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-5.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Sep 2012 13:00:11 -0000
X-IronPort-AV: E=Sophos;i="4.80,398,1344211200"; d="scan'208";a="207574001"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Sep 2012 13:00:09 +0000
Received: from [10.80.248.240] (10.80.248.240) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1; Mon, 10 Sep 2012
	09:00:08 -0400
Message-ID: <504DE4EF.5070004@citrix.com>
Date: Mon, 10 Sep 2012 14:02:39 +0100
From: Julien Grall <julien.grall@citrix.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US;
	rv:1.9.1.16) Gecko/20120726 Icedove/3.0.11
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <cover.1345552068.git.julien.grall@citrix.com>
	<c378b04ee29071c1d6d68bd3ef48fedadb493b10.1345552068.git.julien.grall@citrix.com>
	<5035E986020000780008A617@nat28.tlf.novell.com>
	<50360B81.2070402@citrix.com>
	<5037AE20020000780008A7A8@nat28.tlf.novell.com>
In-Reply-To: <5037AE20020000780008A7A8@nat28.tlf.novell.com>
Cc: "christian.limpach@gmail.com" <christian.limpach@gmail.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [XEN][RFC PATCH V2 05/17] hvm: Modify 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-Transfer-Encoding: 7bit
Content-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/24/2012 04:38 PM, Jan Beulich wrote:
>>>> On 23.08.12 at 12:52, Julien Grall<julien.grall@citrix.com>  wrote:
>>>>          
>> On 08/23/2012 08:27 AM, Jan Beulich wrote:
>>      
>>>> switch ( a.index )
>>>> {
>>>> -            case HVM_PARAM_IOREQ_PFN:
>>>>
>>>>          
>>> Removing sub-ops which a domain can issue for itself (which for this and
>>> another one below appears to be the case) is not allowed.
>>>
>>>        
>> I removed these 3 sub-ops because it will not work with
>> QEMU disaggregation. Shared pages and event channel
>> for IO request are private for each device model.
>>      
> Then they need to be made inaccessible for that specific setup, not
> removed altogether.
>
>    
What do you mean by specific feature ?
With this patch series, you are able to handle one or more
QEMU.
Keep a compatibility with the old IO emulation is hard.
It's still possible but IOreq handle will not send an IOreq
if no device  models registered it. There is no more default QEMU.

I have send a long patch series for QEMU, but it's for supporting
a "full disaggregation" (i.e. multiple QEMU for domain).
If you want to handle only one QEMU the patch decrease to
only 100 lines. So it can be backported easily.

>>>> +            case HVM_PARAM_IO_PFN_FIRST:
>>>>
>>>>          
>>> I don't see where in this patch this and the other new sub-op constants
>>> get defined.
>>>
>>>        
>> Both sub-op constants are added in patch 1:
>> http://lists.xen.org/archives/html/xen-devel/2012-08/msg01767.html
>>      
> Hmm, I can certainly see reasons for breaking up things that way,
> but I generally prefer patches to represent functional units.
>    
I will rework my patch series to represen function units.

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 10 13:00:31 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Sep 2012 13:00: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 1TB3b4-0007EU-9U; Mon, 10 Sep 2012 13:00:14 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <julien.grall@citrix.com>) id 1TB3b3-0007EL-8n
	for xen-devel@lists.xen.org; Mon, 10 Sep 2012 13:00:13 +0000
Received: from [85.158.143.99:46254] by server-3.bemta-4.messagelabs.com id
	72/0E-08232-C54ED405; Mon, 10 Sep 2012 13:00:12 +0000
X-Env-Sender: julien.grall@citrix.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1347282009!29189206!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNzc5Njk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21132 invoked from network); 10 Sep 2012 13:00:11 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-5.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Sep 2012 13:00:11 -0000
X-IronPort-AV: E=Sophos;i="4.80,398,1344211200"; d="scan'208";a="207574001"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Sep 2012 13:00:09 +0000
Received: from [10.80.248.240] (10.80.248.240) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1; Mon, 10 Sep 2012
	09:00:08 -0400
Message-ID: <504DE4EF.5070004@citrix.com>
Date: Mon, 10 Sep 2012 14:02:39 +0100
From: Julien Grall <julien.grall@citrix.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US;
	rv:1.9.1.16) Gecko/20120726 Icedove/3.0.11
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <cover.1345552068.git.julien.grall@citrix.com>
	<c378b04ee29071c1d6d68bd3ef48fedadb493b10.1345552068.git.julien.grall@citrix.com>
	<5035E986020000780008A617@nat28.tlf.novell.com>
	<50360B81.2070402@citrix.com>
	<5037AE20020000780008A7A8@nat28.tlf.novell.com>
In-Reply-To: <5037AE20020000780008A7A8@nat28.tlf.novell.com>
Cc: "christian.limpach@gmail.com" <christian.limpach@gmail.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [XEN][RFC PATCH V2 05/17] hvm: Modify 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-Transfer-Encoding: 7bit
Content-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/24/2012 04:38 PM, Jan Beulich wrote:
>>>> On 23.08.12 at 12:52, Julien Grall<julien.grall@citrix.com>  wrote:
>>>>          
>> On 08/23/2012 08:27 AM, Jan Beulich wrote:
>>      
>>>> switch ( a.index )
>>>> {
>>>> -            case HVM_PARAM_IOREQ_PFN:
>>>>
>>>>          
>>> Removing sub-ops which a domain can issue for itself (which for this and
>>> another one below appears to be the case) is not allowed.
>>>
>>>        
>> I removed these 3 sub-ops because it will not work with
>> QEMU disaggregation. Shared pages and event channel
>> for IO request are private for each device model.
>>      
> Then they need to be made inaccessible for that specific setup, not
> removed altogether.
>
>    
What do you mean by specific feature ?
With this patch series, you are able to handle one or more
QEMU.
Keep a compatibility with the old IO emulation is hard.
It's still possible but IOreq handle will not send an IOreq
if no device  models registered it. There is no more default QEMU.

I have send a long patch series for QEMU, but it's for supporting
a "full disaggregation" (i.e. multiple QEMU for domain).
If you want to handle only one QEMU the patch decrease to
only 100 lines. So it can be backported easily.

>>>> +            case HVM_PARAM_IO_PFN_FIRST:
>>>>
>>>>          
>>> I don't see where in this patch this and the other new sub-op constants
>>> get defined.
>>>
>>>        
>> Both sub-op constants are added in patch 1:
>> http://lists.xen.org/archives/html/xen-devel/2012-08/msg01767.html
>>      
> Hmm, I can certainly see reasons for breaking up things that way,
> but I generally prefer patches to represent functional units.
>    
I will rework my patch series to represen function units.

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 10 13:18:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Sep 2012 13:18:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TB3s4-0007Yn-Vn; Mon, 10 Sep 2012 13:17:48 +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 1TB3s3-0007Yi-Sp
	for xen-devel@lists.xen.org; Mon, 10 Sep 2012 13:17:47 +0000
Received: from [85.158.143.35:10131] by server-3.bemta-4.messagelabs.com id
	6E/18-08232-B78ED405; Mon, 10 Sep 2012 13:17:47 +0000
X-Env-Sender: anthony.perard@gmail.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1347283023!17588372!1
X-Originating-IP: [209.85.223.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31980 invoked from network); 10 Sep 2012 13:17:04 -0000
Received: from mail-ie0-f173.google.com (HELO mail-ie0-f173.google.com)
	(209.85.223.173)
	by server-14.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Sep 2012 13:17:04 -0000
Received: by iebc10 with SMTP id c10so3717780ieb.32
	for <xen-devel@lists.xen.org>; Mon, 10 Sep 2012 06:17: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:from:date
	:x-google-sender-auth:message-id:subject:to:cc:content-type;
	bh=FhKSm8SafMKm0szdWaFgtyTCinQQp7WC0Oy1qgNgqUU=;
	b=Eto1lG5ldqxDlllmVOsg8Ls0pIfqQY84E61Q6Wp3cAm2h7EsIsXsoRNzsiPv/4MKVv
	CazZToIbQgenDbjtef7ywM8SrLlOyoVTVA+Dkjc9QtwaM5ldCiDuV0oNy0Lsc4omcGXO
	0gwMaWMfnjQWP6xr2t/9kHSHd0ITolbI2vKbIfS6MM4E5IfmCJQ5KrbBj5Hrcxf1JoVD
	bqPG5mhBSyaNmv1kC5YaDFE0HoQ3P2Lt+rYGuV29igCf9I0NeofrY4TyS+Y9K+zqFabz
	W+9Ar6zJEHbwZRNTDrm3rPEMRmHZGCrMkxYTIZgC6I4hKBs25aLH0lMqnM9V9e39TNPj
	FJGw==
Received: by 10.50.184.163 with SMTP id ev3mr8742672igc.44.1347283023039; Mon,
	10 Sep 2012 06:17:03 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.64.59.41 with HTTP; Mon, 10 Sep 2012 06:16:32 -0700 (PDT)
In-Reply-To: <CAOvdn6WD31pQVbZNSMc8JTKfNQKOEWUkHpvpqPq=kcAUBC5QHQ@mail.gmail.com>
References: <502E212E.6070306@citrix.com>
	<CAOvdn6WD31pQVbZNSMc8JTKfNQKOEWUkHpvpqPq=kcAUBC5QHQ@mail.gmail.com>
From: Anthony PERARD <anthony.perard@citrix.com>
Date: Mon, 10 Sep 2012 14:16:32 +0100
X-Google-Sender-Auth: 8Uwqubx6cAra1qJvr_2iqNTeJaA
Message-ID: <CAJJyHjJe3fV8LzKNqJVW58Ngk3HGE+GA0rOGA7zU-tzTX0rNtQ@mail.gmail.com>
To: Ben Guthro <ben@guthro.net>
Cc: Xen Devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [ANNOUNCE] Git mirror of Xen repositories available
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Sat, Sep 8, 2012 at 1:23 PM, Ben Guthro <ben@guthro.net> wrote:
> Will this git mirror pick up a stable-4.2 branch, now that the
> xen-4.2-testing.hg branch has been forked off?

Yes, it will ! And it does now. There is two new branches,
"stable-4.2" and "staging-4.2".

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 Mon Sep 10 13:18:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Sep 2012 13:18:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TB3s4-0007Yn-Vn; Mon, 10 Sep 2012 13:17:48 +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 1TB3s3-0007Yi-Sp
	for xen-devel@lists.xen.org; Mon, 10 Sep 2012 13:17:47 +0000
Received: from [85.158.143.35:10131] by server-3.bemta-4.messagelabs.com id
	6E/18-08232-B78ED405; Mon, 10 Sep 2012 13:17:47 +0000
X-Env-Sender: anthony.perard@gmail.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1347283023!17588372!1
X-Originating-IP: [209.85.223.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31980 invoked from network); 10 Sep 2012 13:17:04 -0000
Received: from mail-ie0-f173.google.com (HELO mail-ie0-f173.google.com)
	(209.85.223.173)
	by server-14.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Sep 2012 13:17:04 -0000
Received: by iebc10 with SMTP id c10so3717780ieb.32
	for <xen-devel@lists.xen.org>; Mon, 10 Sep 2012 06:17: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:from:date
	:x-google-sender-auth:message-id:subject:to:cc:content-type;
	bh=FhKSm8SafMKm0szdWaFgtyTCinQQp7WC0Oy1qgNgqUU=;
	b=Eto1lG5ldqxDlllmVOsg8Ls0pIfqQY84E61Q6Wp3cAm2h7EsIsXsoRNzsiPv/4MKVv
	CazZToIbQgenDbjtef7ywM8SrLlOyoVTVA+Dkjc9QtwaM5ldCiDuV0oNy0Lsc4omcGXO
	0gwMaWMfnjQWP6xr2t/9kHSHd0ITolbI2vKbIfS6MM4E5IfmCJQ5KrbBj5Hrcxf1JoVD
	bqPG5mhBSyaNmv1kC5YaDFE0HoQ3P2Lt+rYGuV29igCf9I0NeofrY4TyS+Y9K+zqFabz
	W+9Ar6zJEHbwZRNTDrm3rPEMRmHZGCrMkxYTIZgC6I4hKBs25aLH0lMqnM9V9e39TNPj
	FJGw==
Received: by 10.50.184.163 with SMTP id ev3mr8742672igc.44.1347283023039; Mon,
	10 Sep 2012 06:17:03 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.64.59.41 with HTTP; Mon, 10 Sep 2012 06:16:32 -0700 (PDT)
In-Reply-To: <CAOvdn6WD31pQVbZNSMc8JTKfNQKOEWUkHpvpqPq=kcAUBC5QHQ@mail.gmail.com>
References: <502E212E.6070306@citrix.com>
	<CAOvdn6WD31pQVbZNSMc8JTKfNQKOEWUkHpvpqPq=kcAUBC5QHQ@mail.gmail.com>
From: Anthony PERARD <anthony.perard@citrix.com>
Date: Mon, 10 Sep 2012 14:16:32 +0100
X-Google-Sender-Auth: 8Uwqubx6cAra1qJvr_2iqNTeJaA
Message-ID: <CAJJyHjJe3fV8LzKNqJVW58Ngk3HGE+GA0rOGA7zU-tzTX0rNtQ@mail.gmail.com>
To: Ben Guthro <ben@guthro.net>
Cc: Xen Devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [ANNOUNCE] Git mirror of Xen repositories available
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Sat, Sep 8, 2012 at 1:23 PM, Ben Guthro <ben@guthro.net> wrote:
> Will this git mirror pick up a stable-4.2 branch, now that the
> xen-4.2-testing.hg branch has been forked off?

Yes, it will ! And it does now. There is two new branches,
"stable-4.2" and "staging-4.2".

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 Mon Sep 10 13:19:38 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Sep 2012 13: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 1TB3tX-0007fP-JH; Mon, 10 Sep 2012 13:19:19 +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 1TB3tV-0007ek-Gt
	for xen-devel@lists.xensource.com; Mon, 10 Sep 2012 13:19:17 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1347283150!4784711!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTIyODk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5488 invoked from network); 10 Sep 2012 13:19:11 -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;
	10 Sep 2012 13:19:11 -0000
X-IronPort-AV: E=Sophos;i="4.80,398,1344211200"; d="scan'208";a="14443822"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Sep 2012 13: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.279.1; Mon, 10 Sep 2012 14:18: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
	1TB3sq-00047v-7T; Mon, 10 Sep 2012 13:18:36 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1TB3sq-00066H-3U;
	Mon, 10 Sep 2012 14:18:36 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20557.59563.996992.453858@mariner.uk.xensource.com>
Date: Mon, 10 Sep 2012 14:18:35 +0100
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, Stefano
	Stabellini <Stefano.Stabellini@eu.citrix.com>
In-Reply-To: <osstest-13666-mainreport@xen.org>
References: <osstest-13666-mainreport@xen.org>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [xen-4.2-testing baseline test] 13666: 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

xen.org writes ("[xen-4.2-testing baseline test] 13666: tolerable FAIL"):
...
>  build-i386                    4 xen-build               fail   never pass

This was due to the fact that:

 * The test system thought that qemu-upstream-4.2-testing.git
   should exist because it was constructing the qemu branch name
   programmatically and overriding xen.hg's idea of which qemu version
   to use.

 * qemu-upstream-4.2-testing.git did not actually exist.
   This was because our release checklist didn't say to branch
   qemu-upstream.unstable.git.
   This was because we hadn't actually made a decision whether to
   branch qemu-xen-upstream for 4.2.

Also I discovered that:

 * xen-4.2-testing.hg's Config.mk referred to qemu-xen-unstable.git.
   This was because our release checklist didn't say to change this
   (and Keir didn't do so when making the various tags).

I have:

 * Checked with Ian C and Stefano and agreed that we want to branch
   xenbits's qemu-upstream-unstable.git.

 * Actually made the new trees and updated the checklist.

 * Pushed a change to xen-4.2-testing.hg to update Config.mk.
   (see below).

 * Poked the test system to start a retest of 4.2.

I'm afraid that we should still refrain from pushing substative
changes to xen-4.2-unstable.hg.

Sorry for the inconvenience.  The root causes are that (a) we have
accumulated 18 months' worth of bitrot in our process (b) we didn't
remember to update the releasing/branching checklist when inventing
new qemu trees.

Ian.

# HG changeset patch
# User Ian Jackson <Ian.Jackson@eu.citrix.com>
# Date 1347282491 -3600
# Node ID 317c8a48d81ff4848f6e8991c44a978efc06df30
# Parent  c7c84f9e2fd87530bae9c8a4701e49f08eddadb6
Config.mk: Change qemu references to 4.2-testing trees

QEMU_REMOTE and QEMU_UPSTREAM_URL need to refer to
git://xenbits.xen.org/qemu-{xen,upstream}-4.2-testing.git
(or the corresponding http versions), not -unstable.git.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

diff -r c7c84f9e2fd8 -r 317c8a48d81f Config.mk
--- a/Config.mk	Mon Sep 10 11:34:26 2012 +0100
+++ b/Config.mk	Mon Sep 10 14:08:11 2012 +0100
@@ -187,18 +187,18 @@ XEN_EXTFILES_URL=http://xenbits.xen.org/
 # near the place in the Xen Makefiles where the file is used.
 
 ifeq ($(GIT_HTTP),y)
-QEMU_REMOTE=http://xenbits.xen.org/git-http/qemu-xen-unstable.git
+QEMU_REMOTE=http://xenbits.xen.org/git-http/qemu-xen-4.2-testing.git
 else
-QEMU_REMOTE=git://xenbits.xen.org/qemu-xen-unstable.git
+QEMU_REMOTE=git://xenbits.xen.org/qemu-xen-4.2-testing.git
 endif
 
 ifeq ($(GIT_HTTP),y)
 OVMF_UPSTREAM_URL ?= http://xenbits.xen.org/git-http/ovmf.git
-QEMU_UPSTREAM_URL ?= http://xenbits.xen.org/git-http/qemu-upstream-unstable.git
+QEMU_UPSTREAM_URL ?= http://xenbits.xen.org/git-http/qemu-upstream-4.2-testing.git
 SEABIOS_UPSTREAM_URL ?= http://xenbits.xen.org/git-http/seabios.git
 else
 OVMF_UPSTREAM_URL ?= git://xenbits.xen.org/ovmf.git
-QEMU_UPSTREAM_URL ?= git://xenbits.xen.org/qemu-upstream-unstable.git
+QEMU_UPSTREAM_URL ?= git://xenbits.xen.org/qemu-upstream-4.2-testing.git
 SEABIOS_UPSTREAM_URL ?= git://xenbits.xen.org/seabios.git
 endif
 OVMF_UPSTREAM_REVISION ?= b0855f925c6e2e0b21fbb03fab4b5fb5b6876871

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 10 13:19:38 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Sep 2012 13: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 1TB3tX-0007fP-JH; Mon, 10 Sep 2012 13:19:19 +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 1TB3tV-0007ek-Gt
	for xen-devel@lists.xensource.com; Mon, 10 Sep 2012 13:19:17 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1347283150!4784711!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTIyODk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5488 invoked from network); 10 Sep 2012 13:19:11 -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;
	10 Sep 2012 13:19:11 -0000
X-IronPort-AV: E=Sophos;i="4.80,398,1344211200"; d="scan'208";a="14443822"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Sep 2012 13: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.279.1; Mon, 10 Sep 2012 14:18: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
	1TB3sq-00047v-7T; Mon, 10 Sep 2012 13:18:36 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1TB3sq-00066H-3U;
	Mon, 10 Sep 2012 14:18:36 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20557.59563.996992.453858@mariner.uk.xensource.com>
Date: Mon, 10 Sep 2012 14:18:35 +0100
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, Stefano
	Stabellini <Stefano.Stabellini@eu.citrix.com>
In-Reply-To: <osstest-13666-mainreport@xen.org>
References: <osstest-13666-mainreport@xen.org>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [xen-4.2-testing baseline test] 13666: 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

xen.org writes ("[xen-4.2-testing baseline test] 13666: tolerable FAIL"):
...
>  build-i386                    4 xen-build               fail   never pass

This was due to the fact that:

 * The test system thought that qemu-upstream-4.2-testing.git
   should exist because it was constructing the qemu branch name
   programmatically and overriding xen.hg's idea of which qemu version
   to use.

 * qemu-upstream-4.2-testing.git did not actually exist.
   This was because our release checklist didn't say to branch
   qemu-upstream.unstable.git.
   This was because we hadn't actually made a decision whether to
   branch qemu-xen-upstream for 4.2.

Also I discovered that:

 * xen-4.2-testing.hg's Config.mk referred to qemu-xen-unstable.git.
   This was because our release checklist didn't say to change this
   (and Keir didn't do so when making the various tags).

I have:

 * Checked with Ian C and Stefano and agreed that we want to branch
   xenbits's qemu-upstream-unstable.git.

 * Actually made the new trees and updated the checklist.

 * Pushed a change to xen-4.2-testing.hg to update Config.mk.
   (see below).

 * Poked the test system to start a retest of 4.2.

I'm afraid that we should still refrain from pushing substative
changes to xen-4.2-unstable.hg.

Sorry for the inconvenience.  The root causes are that (a) we have
accumulated 18 months' worth of bitrot in our process (b) we didn't
remember to update the releasing/branching checklist when inventing
new qemu trees.

Ian.

# HG changeset patch
# User Ian Jackson <Ian.Jackson@eu.citrix.com>
# Date 1347282491 -3600
# Node ID 317c8a48d81ff4848f6e8991c44a978efc06df30
# Parent  c7c84f9e2fd87530bae9c8a4701e49f08eddadb6
Config.mk: Change qemu references to 4.2-testing trees

QEMU_REMOTE and QEMU_UPSTREAM_URL need to refer to
git://xenbits.xen.org/qemu-{xen,upstream}-4.2-testing.git
(or the corresponding http versions), not -unstable.git.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

diff -r c7c84f9e2fd8 -r 317c8a48d81f Config.mk
--- a/Config.mk	Mon Sep 10 11:34:26 2012 +0100
+++ b/Config.mk	Mon Sep 10 14:08:11 2012 +0100
@@ -187,18 +187,18 @@ XEN_EXTFILES_URL=http://xenbits.xen.org/
 # near the place in the Xen Makefiles where the file is used.
 
 ifeq ($(GIT_HTTP),y)
-QEMU_REMOTE=http://xenbits.xen.org/git-http/qemu-xen-unstable.git
+QEMU_REMOTE=http://xenbits.xen.org/git-http/qemu-xen-4.2-testing.git
 else
-QEMU_REMOTE=git://xenbits.xen.org/qemu-xen-unstable.git
+QEMU_REMOTE=git://xenbits.xen.org/qemu-xen-4.2-testing.git
 endif
 
 ifeq ($(GIT_HTTP),y)
 OVMF_UPSTREAM_URL ?= http://xenbits.xen.org/git-http/ovmf.git
-QEMU_UPSTREAM_URL ?= http://xenbits.xen.org/git-http/qemu-upstream-unstable.git
+QEMU_UPSTREAM_URL ?= http://xenbits.xen.org/git-http/qemu-upstream-4.2-testing.git
 SEABIOS_UPSTREAM_URL ?= http://xenbits.xen.org/git-http/seabios.git
 else
 OVMF_UPSTREAM_URL ?= git://xenbits.xen.org/ovmf.git
-QEMU_UPSTREAM_URL ?= git://xenbits.xen.org/qemu-upstream-unstable.git
+QEMU_UPSTREAM_URL ?= git://xenbits.xen.org/qemu-upstream-4.2-testing.git
 SEABIOS_UPSTREAM_URL ?= git://xenbits.xen.org/seabios.git
 endif
 OVMF_UPSTREAM_REVISION ?= b0855f925c6e2e0b21fbb03fab4b5fb5b6876871

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 10 13:24:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Sep 2012 13:24:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TB3xz-0007sl-9Z; Mon, 10 Sep 2012 13:23:55 +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 1TB3xy-0007sT-GL
	for xen-devel@lists.xen.org; Mon, 10 Sep 2012 13:23:54 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1347283427!3405859!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM5OTE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10638 invoked from network); 10 Sep 2012 13:23:48 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-15.tower-27.messagelabs.com with SMTP;
	10 Sep 2012 13:23:48 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 10 Sep 2012 14:23:46 +0100
Message-Id: <504E0600020000780009A37F@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 10 Sep 2012 14:23:44 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Julien Grall" <julien.grall@citrix.com>
References: <cover.1345552068.git.julien.grall@citrix.com>
	<c378b04ee29071c1d6d68bd3ef48fedadb493b10.1345552068.git.julien.grall@citrix.com>
	<5035E986020000780008A617@nat28.tlf.novell.com>
	<50360B81.2070402@citrix.com>
	<5037AE20020000780008A7A8@nat28.tlf.novell.com>
	<504DE4EF.5070004@citrix.com>
In-Reply-To: <504DE4EF.5070004@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "christian.limpach@gmail.com" <christian.limpach@gmail.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [XEN][RFC PATCH V2 05/17] hvm: Modify 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

>>> On 10.09.12 at 15:02, Julien Grall <julien.grall@citrix.com> wrote:
> On 08/24/2012 04:38 PM, Jan Beulich wrote:
>>>>> On 23.08.12 at 12:52, Julien Grall<julien.grall@citrix.com>  wrote:
>>>>>          
>>> On 08/23/2012 08:27 AM, Jan Beulich wrote:
>>>      
>>>>> switch ( a.index )
>>>>> {
>>>>> -            case HVM_PARAM_IOREQ_PFN:
>>>>>
>>>>>          
>>>> Removing sub-ops which a domain can issue for itself (which for this and
>>>> another one below appears to be the case) is not allowed.
>>>>
>>>>        
>>> I removed these 3 sub-ops because it will not work with
>>> QEMU disaggregation. Shared pages and event channel
>>> for IO request are private for each device model.
>>>      
>> Then they need to be made inaccessible for that specific setup, not
>> removed altogether.
>>
>>    
> What do you mean by specific feature ?
> With this patch series, you are able to handle one or more
> QEMU.
> Keep a compatibility with the old IO emulation is hard.

Did you read my original reply? Code backing operations that a
guest can issue itself (i.e. without qemu or another host side
component involved) just can't be removed, as you/we have
no control over which guest(s) may be making use of that
functionality.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 10 13:24:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Sep 2012 13:24:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TB3xz-0007sl-9Z; Mon, 10 Sep 2012 13:23:55 +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 1TB3xy-0007sT-GL
	for xen-devel@lists.xen.org; Mon, 10 Sep 2012 13:23:54 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1347283427!3405859!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM5OTE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10638 invoked from network); 10 Sep 2012 13:23:48 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-15.tower-27.messagelabs.com with SMTP;
	10 Sep 2012 13:23:48 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 10 Sep 2012 14:23:46 +0100
Message-Id: <504E0600020000780009A37F@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 10 Sep 2012 14:23:44 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Julien Grall" <julien.grall@citrix.com>
References: <cover.1345552068.git.julien.grall@citrix.com>
	<c378b04ee29071c1d6d68bd3ef48fedadb493b10.1345552068.git.julien.grall@citrix.com>
	<5035E986020000780008A617@nat28.tlf.novell.com>
	<50360B81.2070402@citrix.com>
	<5037AE20020000780008A7A8@nat28.tlf.novell.com>
	<504DE4EF.5070004@citrix.com>
In-Reply-To: <504DE4EF.5070004@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "christian.limpach@gmail.com" <christian.limpach@gmail.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [XEN][RFC PATCH V2 05/17] hvm: Modify 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

>>> On 10.09.12 at 15:02, Julien Grall <julien.grall@citrix.com> wrote:
> On 08/24/2012 04:38 PM, Jan Beulich wrote:
>>>>> On 23.08.12 at 12:52, Julien Grall<julien.grall@citrix.com>  wrote:
>>>>>          
>>> On 08/23/2012 08:27 AM, Jan Beulich wrote:
>>>      
>>>>> switch ( a.index )
>>>>> {
>>>>> -            case HVM_PARAM_IOREQ_PFN:
>>>>>
>>>>>          
>>>> Removing sub-ops which a domain can issue for itself (which for this and
>>>> another one below appears to be the case) is not allowed.
>>>>
>>>>        
>>> I removed these 3 sub-ops because it will not work with
>>> QEMU disaggregation. Shared pages and event channel
>>> for IO request are private for each device model.
>>>      
>> Then they need to be made inaccessible for that specific setup, not
>> removed altogether.
>>
>>    
> What do you mean by specific feature ?
> With this patch series, you are able to handle one or more
> QEMU.
> Keep a compatibility with the old IO emulation is hard.

Did you read my original reply? Code backing operations that a
guest can issue itself (i.e. without qemu or another host side
component involved) just can't be removed, as you/we have
no control over which guest(s) may be making use of that
functionality.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 10 13:34:02 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Sep 2012 13:34:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TB47T-00084U-C5; Mon, 10 Sep 2012 13:33:43 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <julien.grall@citrix.com>) id 1TB47R-00084M-J1
	for xen-devel@lists.xen.org; Mon, 10 Sep 2012 13:33:41 +0000
Received: from [85.158.138.51:18430] by server-12.bemta-3.messagelabs.com id
	5D/47-10384-43CED405; Mon, 10 Sep 2012 13:33:40 +0000
X-Env-Sender: julien.grall@citrix.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1347284015!21671895!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzAwNzQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10551 invoked from network); 10 Sep 2012 13:33:37 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-6.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Sep 2012 13:33:37 -0000
X-IronPort-AV: E=Sophos;i="4.80,398,1344211200"; d="scan'208";a="37313905"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Sep 2012 13:33:35 +0000
Received: from [10.80.248.240] (10.80.248.240) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1; Mon, 10 Sep 2012
	09:33:27 -0400
Message-ID: <504DECBF.2000306@citrix.com>
Date: Mon, 10 Sep 2012 14:35:59 +0100
From: Julien Grall <julien.grall@citrix.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US;
	rv:1.9.1.16) Gecko/20120726 Icedove/3.0.11
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <cover.1345552068.git.julien.grall@citrix.com>
	<c378b04ee29071c1d6d68bd3ef48fedadb493b10.1345552068.git.julien.grall@citrix.com>
	<5035E986020000780008A617@nat28.tlf.novell.com>
	<50360B81.2070402@citrix.com>
	<5037AE20020000780008A7A8@nat28.tlf.novell.com>
	<504DE4EF.5070004@citrix.com>
	<504E0600020000780009A37F@nat28.tlf.novell.com>
In-Reply-To: <504E0600020000780009A37F@nat28.tlf.novell.com>
Cc: "christian.limpach@gmail.com" <christian.limpach@gmail.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [XEN][RFC PATCH V2 05/17] hvm: Modify 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-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 09/10/2012 02:23 PM, Jan Beulich wrote:
>>>> On 10.09.12 at 15:02, Julien Grall<julien.grall@citrix.com>  wrote:
>>>>          
>> On 08/24/2012 04:38 PM, Jan Beulich wrote:
>>      
>>>>>> On 23.08.12 at 12:52, Julien Grall<julien.grall@citrix.com>   wrote:
>>>>>>
>>>>>>              
>>>> On 08/23/2012 08:27 AM, Jan Beulich wrote:
>>>>
>>>>          
>>>>>> switch ( a.index )
>>>>>> {
>>>>>> -            case HVM_PARAM_IOREQ_PFN:
>>>>>>
>>>>>>
>>>>>>              
>>>>> Removing sub-ops which a domain can issue for itself (which for this and
>>>>> another one below appears to be the case) is not allowed.
>>>>>
>>>>>
>>>>>            
>>>> I removed these 3 sub-ops because it will not work with
>>>> QEMU disaggregation. Shared pages and event channel
>>>> for IO request are private for each device model.
>>>>
>>>>          
>>> Then they need to be made inaccessible for that specific setup, not
>>> removed altogether.
>>>
>>>
>>>        
>> What do you mean by specific feature ?
>> With this patch series, you are able to handle one or more
>> QEMU.
>> Keep a compatibility with the old IO emulation is hard.
>>      
> Did you read my original reply? Code backing operations that a
> guest can issue itself (i.e. without qemu or another host side
> component involved) just can't be removed, as you/we have
> no control over which guest(s) may be making use of that
> functionality.
>    

Ah ok misundertanding of my part. I don't really understand
in which case a domain needs to retrieve its ioreq page.
How can I made it inaccessible ? Just rc = -EINVAL ?

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 10 13:34:02 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Sep 2012 13:34:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TB47T-00084U-C5; Mon, 10 Sep 2012 13:33:43 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <julien.grall@citrix.com>) id 1TB47R-00084M-J1
	for xen-devel@lists.xen.org; Mon, 10 Sep 2012 13:33:41 +0000
Received: from [85.158.138.51:18430] by server-12.bemta-3.messagelabs.com id
	5D/47-10384-43CED405; Mon, 10 Sep 2012 13:33:40 +0000
X-Env-Sender: julien.grall@citrix.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1347284015!21671895!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzAwNzQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10551 invoked from network); 10 Sep 2012 13:33:37 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-6.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Sep 2012 13:33:37 -0000
X-IronPort-AV: E=Sophos;i="4.80,398,1344211200"; d="scan'208";a="37313905"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Sep 2012 13:33:35 +0000
Received: from [10.80.248.240] (10.80.248.240) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1; Mon, 10 Sep 2012
	09:33:27 -0400
Message-ID: <504DECBF.2000306@citrix.com>
Date: Mon, 10 Sep 2012 14:35:59 +0100
From: Julien Grall <julien.grall@citrix.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US;
	rv:1.9.1.16) Gecko/20120726 Icedove/3.0.11
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <cover.1345552068.git.julien.grall@citrix.com>
	<c378b04ee29071c1d6d68bd3ef48fedadb493b10.1345552068.git.julien.grall@citrix.com>
	<5035E986020000780008A617@nat28.tlf.novell.com>
	<50360B81.2070402@citrix.com>
	<5037AE20020000780008A7A8@nat28.tlf.novell.com>
	<504DE4EF.5070004@citrix.com>
	<504E0600020000780009A37F@nat28.tlf.novell.com>
In-Reply-To: <504E0600020000780009A37F@nat28.tlf.novell.com>
Cc: "christian.limpach@gmail.com" <christian.limpach@gmail.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [XEN][RFC PATCH V2 05/17] hvm: Modify 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-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 09/10/2012 02:23 PM, Jan Beulich wrote:
>>>> On 10.09.12 at 15:02, Julien Grall<julien.grall@citrix.com>  wrote:
>>>>          
>> On 08/24/2012 04:38 PM, Jan Beulich wrote:
>>      
>>>>>> On 23.08.12 at 12:52, Julien Grall<julien.grall@citrix.com>   wrote:
>>>>>>
>>>>>>              
>>>> On 08/23/2012 08:27 AM, Jan Beulich wrote:
>>>>
>>>>          
>>>>>> switch ( a.index )
>>>>>> {
>>>>>> -            case HVM_PARAM_IOREQ_PFN:
>>>>>>
>>>>>>
>>>>>>              
>>>>> Removing sub-ops which a domain can issue for itself (which for this and
>>>>> another one below appears to be the case) is not allowed.
>>>>>
>>>>>
>>>>>            
>>>> I removed these 3 sub-ops because it will not work with
>>>> QEMU disaggregation. Shared pages and event channel
>>>> for IO request are private for each device model.
>>>>
>>>>          
>>> Then they need to be made inaccessible for that specific setup, not
>>> removed altogether.
>>>
>>>
>>>        
>> What do you mean by specific feature ?
>> With this patch series, you are able to handle one or more
>> QEMU.
>> Keep a compatibility with the old IO emulation is hard.
>>      
> Did you read my original reply? Code backing operations that a
> guest can issue itself (i.e. without qemu or another host side
> component involved) just can't be removed, as you/we have
> no control over which guest(s) may be making use of that
> functionality.
>    

Ah ok misundertanding of my part. I don't really understand
in which case a domain needs to retrieve its ioreq page.
How can I made it inaccessible ? Just rc = -EINVAL ?

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 10 13:37:16 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Sep 2012 13: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 1TB4Ae-0008D9-0I; Mon, 10 Sep 2012 13:37:00 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1TB4Ac-0008Cs-D5
	for xen-devel@lists.xensource.com; Mon, 10 Sep 2012 13:36:58 +0000
X-Env-Sender: fantonifabio@tiscali.it
X-Msg-Ref: server-15.tower-27.messagelabs.com!1347284205!3408076!1
X-Originating-IP: [94.23.245.208]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG,
	ML_RADAR_SPEW_LINKS_14,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5151 invoked from network); 10 Sep 2012 13:36:46 -0000
Received: from lnx3.fantu.it (HELO lnx3.fantu.it) (94.23.245.208)
	by server-15.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 10 Sep 2012 13:36:46 -0000
Received: from localhost (localhost.localdomain [127.0.0.1])
	by lnx3.fantu.it (Postfix) with ESMTP id ECD9F4020A8;
	Mon, 10 Sep 2012 15:36:44 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at lnx3.fantu.it
Received: from lnx3.fantu.it ([127.0.0.1])
	by localhost (lnx3.fantu.it [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id wjo0bYP07q7i; Mon, 10 Sep 2012 15:36:43 +0200 (CEST)
Received: from [192.168.178.50]
	(host159-164-dynamic.56-82-r.retail.telecomitalia.it [82.56.164.159])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: prova@fantu.it)
	by lnx3.fantu.it (Postfix) with ESMTPSA id 457E64003AA;
	Mon, 10 Sep 2012 15:36:43 +0200 (CEST)
Message-ID: <504DECE7.1050404@tiscali.it>
Date: Mon, 10 Sep 2012 15:36:39 +0200
From: Fabio Fantoni <fantonifabio@tiscali.it>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:14.0) Gecko/20120713 Thunderbird/14.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <5049EC11.9080302@tiscali.it>
	<1347030955.30018.115.camel@zakaz.uk.xensource.com>
	<504DB165.6040500@tiscali.it>
	<1347269362.5305.39.camel@zakaz.uk.xensource.com>
In-Reply-To: <1347269362.5305.39.camel@zakaz.uk.xensource.com>
Cc: xen-devel <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Test report of xen 4.2.0-rc4
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="===============2718414259976601644=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Questo è un messaggio firmato digitalmente in formato MIME.

--===============2718414259976601644==
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms040405010208010703070903"

Questo è un messaggio firmato digitalmente in formato MIME.

--------------ms040405010208010703070903
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable

Il 10/09/2012 11:29, Ian Campbell ha scritto:
> On Mon, 2012-09-10 at 10:22 +0100, Fabio Fantoni wrote:
>> Il 07/09/2012 17:15, Ian Campbell ha scritto:
>>> Thanks for testing.
>>>
>>> On Fri, 2012-09-07 at 13:44 +0100, Fabio Fantoni wrote:
>>>> - IMPORTANT - On restore network is up but not working, tried with W=
7
>>>> pro 64 bit with gplpv last build (357) on qemu-xen-traditional
>>> Our automated tests aren't seeing this, might it be a GPLPV issue? Ca=
n
>>> you reproduce with e.g. PV Linux (or PVHVM Linux for that matter)?
>>>
>>>> - Cdrom hotswap is not working, tried with W7 pro 64 bit with gplpv =
last
>>>> build (357) on qemu-xen-traditional
>>>> xl -vvv cd-eject W7 hdb
>>>> libxl: debug: libxl.c:2143:libxl_cdrom_insert: ao 0x1461980: create:=

>>>> how=3D(nil) callback=3D(nil) poller=3D0x14619e0
>>>> Errore di segmentazione
>>> This doesn't happen for me. Please can you run this one under gdb and=

>>> when it fails type "bt" to get a backtrace.
>>>
>>>> - Vnc is working but only with parameters not supplied as value to t=
he
>>>> vfb key, but with vfb key is not working
>>> Whether or not that works is very much a function of exactly what the=

>>> rest of your guest config looks like (it depends on PV for HVM for on=
e
>>> thing).
>>>
>>> You've reported enough bugs now that I shouldn't need to remind you
>>> about providing guest config files or link to
>>> http://wiki.xen.org/wiki/Reporting_Bugs_against_Xen again.
>>>
>>> Ian.
>>>
>>>
>>>
>>>
>>> -----
>>> Nessun virus nel messaggio.
>>> Controllato da AVG - www.avg.com
>>> Versione: 2012.0.2197 / Database dei virus: 2437/5254 -  Data di rila=
scio: 07/09/2012
>>>
>>>
>> Thanks for reply, here the xl configuration file:
>>
>> -------------------------
>> W7.cfg
>> ------
>> name=3D'W7'
>> builder=3D"hvm"
>> memory=3D2048
>> vcpus=3D2
>> vif=3D['bridge=3Dxenbr0']
>> #vfb=3D['vnc=3D1,vncunused=3D1,vnclisten=3D"0.0.0.0",keymap=3Dit']
> I don't think it is expected that this line (even if uncommented) would=

> do anything for Windows unless you have a PV FB frontend driver, which
> I'm fairly certain doesn't exist. So I think:
>> Vnc is working but only with parameters not supplied as value to the
>> vfb key, but with vfb key is not working
> is entirely expected.
>
> The vfb line is for use with PV guests which have a PVFB driver.
>
> [...]
>> -------------------------
>>
>> I don't know exactly how to use gdbsx,
> You just need regular gdb not gdbsx.
>
> Run it as eg.g.
> 	gdb --args xl cd-eject <aprams>
>
> then when it crashes type "bt".
>
>> Can you post me details and versions  of your system installation (dom=
0
>> domU GPLPV) with which you have cd-eject and network on restore workin=
g,
>> please?
> I tested this with Linux HVM. I don't have any Windows domUs.
>
> Does this work without GPLPV drivers? The CDROM device should be
> emulated even if those are installed anyway.
>
> Ian.
>
>
>
> -----
> Nessun virus nel messaggio.
> Controllato da AVG - www.avg.com
> Versione: 2012.0.2197 / Database dei virus: 2437/5259 -  Data di rilasc=
io: 09/09/2012
>
>
Tried without GPLPV, same result with cd-eject
Tried also gdb but probably somethink is missing

gdb --args xl -vvv cd-eject W7 hdb
GNU gdb (GDB) 7.4.1-debian
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later=20
<http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying=
"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /usr/sbin/xl...done.
(gdb) bt
No stack.


--------------ms040405010208010703070903
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: Firma crittografica S/MIME

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINhjCC
BjQwggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT
DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp
Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3
MTAyNDIxMDI1NVoXDTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T
dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu
aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs
aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOM
KqANy9BV7V0igWdGxA8IU77L3aTxErQ+fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi
8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke/s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8M
DP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHksw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y
2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHHtOkzUreG//CsFnB9+uaYSlR65cdG
zTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB
Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd+q9rMfPIHeOsuzAfBgNV
HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH
MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3
dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu
c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v
c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0
dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93
d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqp
Jw3I07QWke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Mic
c/NXcs7kPBRdn6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9Jphw
UPTXwHovjavRnhUQHLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMc
p+reg9901zkyT3fDW/ivJVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT
+HBDYtbuvexNftwNQKD5193A7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1X
hwby6mLhkbaXslkVtwEWT3Van49rKjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvO
hNz/QplNa+VkIsrcp7+8ZhP1l1b2U6MaxIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC
0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqh
AChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H75dVCV33K6FuxZrf09yTz+Vx/PkdRUYk
XmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHSjCCBjKgAwIBAgICHmMwDQYJKoZIhvcNAQEF
BQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJT
ZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD
bGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0xMjAzMTgyMjE0MzBa
Fw0xNDAzMjAwODU3MDlaMIGMMRkwFwYDVQQNExBlQjZPRTM3UlJOUHlsNW0yMQswCQYDVQQG
EwJJVDEQMA4GA1UECBMHQmVyZ2FtbzEQMA4GA1UEBxMHUm92ZXR0YTEWMBQGA1UEAxMNRmFi
aW8gRmFudG9uaTEmMCQGCSqGSIb3DQEJARYXZmFudG9uaWZhYmlvQHRpc2NhbGkuaXQwggEi
MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC1XhckXsX23vgJq76s2f0KT8U8Msov5QgV
10eQBb2wL/TzcmqtZotI7ztKVhio3ehHg+mfu+3EqOkX9Umgut8rP0bPi7AGjkPXbOTT/cSU
Xz2Kw31VGOmiOVoUFGvpQitp3weCkhUJLBipI8EpNyBXpjtQ9yCpnIAqfuc77ybfSnCy7tTR
MBq1BUkfjH1+GL45riosuS4+F+MSUvlYzLiT4rAduAX1Y2IuORDsf9Bce8GBxa6syP9rCyzl
Vk7DIX5k8j2vlnyRATIypn5CQLQxGT6e0f6ac4gvWOHwO2QEBsmZKKs1ZidE4q/9OoNXYX6A
jnHtp1H1vcrek/vVcs19AgMBAAGjggOyMIIDrjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAd
BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFFan8cbEWWBmSTWFtLk2
YNdAcGUbMB8GA1UdIwQYMBaAFK5Vg2/sMcq59x36r2sx88gd46y7MCIGA1UdEQQbMBmBF2Zh
bnRvbmlmYWJpb0B0aXNjYWxpLml0MIICIQYDVR0gBIICGDCCAhQwggIQBgsrBgEEAYG1NwEC
AjCCAf8wLgYIKwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYw
NAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYw
gfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMC
AQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNjb3JkaW5nIHRvIHRoZSBDbGFz
cyAyIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3ks
IHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGluIGNvbXBsaWFuY2Ug
b2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMIGcBggrBgEFBQcCAjCBjzAnFiBT
dGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgECGmRMaWFiaWxpdHkgYW5kIHdh
cnJhbnRpZXMgYXJlIGxpbWl0ZWQhIFNlZSBzZWN0aW9uICJMZWdhbCBhbmQgTGltaXRhdGlv
bnMiIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3kuMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6
Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUyLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYI
KwYBBQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MyL2NsaWVudC9j
YTBCBggrBgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNz
Mi5jbGllbnQuY2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzAN
BgkqhkiG9w0BAQUFAAOCAQEAjzHNqifpDVMkH1TSPFZVIiQ4fh49/V5JMpstgqEZPDaDe5r8
h+fMBZtUa6LLMco03Z9BNEXlqlXKiFk8feVYB8obEjz7YYq1XhO9q7JUmkSs0WGIH4xU0XB1
kPC8T8H+5E//84poYSFHE4pA+Ff68UANP2/EuFJWMjegiefnOr8aM42OAcUkjEWSlautIIX8
oD2GizwQYjWdDDjEonbuMKFP6rY2xGI3PSLI3IVU2opb0/itNhQui3WRxafloJqTlriY8m8+
qSLr2HGftbBlbyzVWB8o//aW0H0LMabjkIvrm7Zmh2vcCxiSxGBwYASuSYXGuQiKAgGptUs1
XJLZuzGCA9owggPWAgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20g
THRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG
A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EC
Ah5jMAkGBSsOAwIaBQCgggIbMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcN
AQkFMQ8XDTEyMDkxMDEzMzYzOVowIwYJKoZIhvcNAQkEMRYEFBLzVPhgDQ/3UcCNvEHCkEk/
RU4mMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggqhkiG
9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcN
AwICASgwgaQGCSsGAQQBgjcQBDGBljCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0
YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25p
bmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp
ZW50IENBAgIeYzCBpgYLKoZIhvcNAQkQAgsxgZaggZMwgYwxCzAJBgNVBAYTAklMMRYwFAYD
VQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0
ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRp
YXRlIENsaWVudCBDQQICHmMwDQYJKoZIhvcNAQEBBQAEggEAJmfAcMt5YtsoCsFczrvna3m8
nLzTJSdt2C6454nu3NQY8hieMecOwUa0iW2kw8j6Yr5vBxSVgDE8t1aiPCYkAMjXvnQVRvWv
I3jefEfSnLwqO9bt6wB2dQRr3IT38x9PM5ad+9hzMoL36/ziZDiqmaT/Bd+DpaYNd/HQtNrB
ue/547+cGm+OSEg/kzLMqNE2bxFtHx7tO8j8xQ6Pkm45wwBQIh1CZHC1gOClr7r3El+FXyZp
x/oZBUFeVUuxXeQePAUiBHeQrlVQ3+VJd2NknS5Ll1X9+9TBV5Z9bU6LRoFUh3TcMgVLPenN
wI3uplj+YezPimEBY2OPsMep715kuAAAAAAAAA==
--------------ms040405010208010703070903--


--===============2718414259976601644==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============2718414259976601644==--


From xen-devel-bounces@lists.xen.org Mon Sep 10 13:37:16 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Sep 2012 13: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 1TB4Ae-0008D9-0I; Mon, 10 Sep 2012 13:37:00 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1TB4Ac-0008Cs-D5
	for xen-devel@lists.xensource.com; Mon, 10 Sep 2012 13:36:58 +0000
X-Env-Sender: fantonifabio@tiscali.it
X-Msg-Ref: server-15.tower-27.messagelabs.com!1347284205!3408076!1
X-Originating-IP: [94.23.245.208]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG,
	ML_RADAR_SPEW_LINKS_14,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5151 invoked from network); 10 Sep 2012 13:36:46 -0000
Received: from lnx3.fantu.it (HELO lnx3.fantu.it) (94.23.245.208)
	by server-15.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 10 Sep 2012 13:36:46 -0000
Received: from localhost (localhost.localdomain [127.0.0.1])
	by lnx3.fantu.it (Postfix) with ESMTP id ECD9F4020A8;
	Mon, 10 Sep 2012 15:36:44 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at lnx3.fantu.it
Received: from lnx3.fantu.it ([127.0.0.1])
	by localhost (lnx3.fantu.it [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id wjo0bYP07q7i; Mon, 10 Sep 2012 15:36:43 +0200 (CEST)
Received: from [192.168.178.50]
	(host159-164-dynamic.56-82-r.retail.telecomitalia.it [82.56.164.159])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: prova@fantu.it)
	by lnx3.fantu.it (Postfix) with ESMTPSA id 457E64003AA;
	Mon, 10 Sep 2012 15:36:43 +0200 (CEST)
Message-ID: <504DECE7.1050404@tiscali.it>
Date: Mon, 10 Sep 2012 15:36:39 +0200
From: Fabio Fantoni <fantonifabio@tiscali.it>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:14.0) Gecko/20120713 Thunderbird/14.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <5049EC11.9080302@tiscali.it>
	<1347030955.30018.115.camel@zakaz.uk.xensource.com>
	<504DB165.6040500@tiscali.it>
	<1347269362.5305.39.camel@zakaz.uk.xensource.com>
In-Reply-To: <1347269362.5305.39.camel@zakaz.uk.xensource.com>
Cc: xen-devel <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Test report of xen 4.2.0-rc4
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="===============2718414259976601644=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Questo è un messaggio firmato digitalmente in formato MIME.

--===============2718414259976601644==
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms040405010208010703070903"

Questo è un messaggio firmato digitalmente in formato MIME.

--------------ms040405010208010703070903
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable

Il 10/09/2012 11:29, Ian Campbell ha scritto:
> On Mon, 2012-09-10 at 10:22 +0100, Fabio Fantoni wrote:
>> Il 07/09/2012 17:15, Ian Campbell ha scritto:
>>> Thanks for testing.
>>>
>>> On Fri, 2012-09-07 at 13:44 +0100, Fabio Fantoni wrote:
>>>> - IMPORTANT - On restore network is up but not working, tried with W=
7
>>>> pro 64 bit with gplpv last build (357) on qemu-xen-traditional
>>> Our automated tests aren't seeing this, might it be a GPLPV issue? Ca=
n
>>> you reproduce with e.g. PV Linux (or PVHVM Linux for that matter)?
>>>
>>>> - Cdrom hotswap is not working, tried with W7 pro 64 bit with gplpv =
last
>>>> build (357) on qemu-xen-traditional
>>>> xl -vvv cd-eject W7 hdb
>>>> libxl: debug: libxl.c:2143:libxl_cdrom_insert: ao 0x1461980: create:=

>>>> how=3D(nil) callback=3D(nil) poller=3D0x14619e0
>>>> Errore di segmentazione
>>> This doesn't happen for me. Please can you run this one under gdb and=

>>> when it fails type "bt" to get a backtrace.
>>>
>>>> - Vnc is working but only with parameters not supplied as value to t=
he
>>>> vfb key, but with vfb key is not working
>>> Whether or not that works is very much a function of exactly what the=

>>> rest of your guest config looks like (it depends on PV for HVM for on=
e
>>> thing).
>>>
>>> You've reported enough bugs now that I shouldn't need to remind you
>>> about providing guest config files or link to
>>> http://wiki.xen.org/wiki/Reporting_Bugs_against_Xen again.
>>>
>>> Ian.
>>>
>>>
>>>
>>>
>>> -----
>>> Nessun virus nel messaggio.
>>> Controllato da AVG - www.avg.com
>>> Versione: 2012.0.2197 / Database dei virus: 2437/5254 -  Data di rila=
scio: 07/09/2012
>>>
>>>
>> Thanks for reply, here the xl configuration file:
>>
>> -------------------------
>> W7.cfg
>> ------
>> name=3D'W7'
>> builder=3D"hvm"
>> memory=3D2048
>> vcpus=3D2
>> vif=3D['bridge=3Dxenbr0']
>> #vfb=3D['vnc=3D1,vncunused=3D1,vnclisten=3D"0.0.0.0",keymap=3Dit']
> I don't think it is expected that this line (even if uncommented) would=

> do anything for Windows unless you have a PV FB frontend driver, which
> I'm fairly certain doesn't exist. So I think:
>> Vnc is working but only with parameters not supplied as value to the
>> vfb key, but with vfb key is not working
> is entirely expected.
>
> The vfb line is for use with PV guests which have a PVFB driver.
>
> [...]
>> -------------------------
>>
>> I don't know exactly how to use gdbsx,
> You just need regular gdb not gdbsx.
>
> Run it as eg.g.
> 	gdb --args xl cd-eject <aprams>
>
> then when it crashes type "bt".
>
>> Can you post me details and versions  of your system installation (dom=
0
>> domU GPLPV) with which you have cd-eject and network on restore workin=
g,
>> please?
> I tested this with Linux HVM. I don't have any Windows domUs.
>
> Does this work without GPLPV drivers? The CDROM device should be
> emulated even if those are installed anyway.
>
> Ian.
>
>
>
> -----
> Nessun virus nel messaggio.
> Controllato da AVG - www.avg.com
> Versione: 2012.0.2197 / Database dei virus: 2437/5259 -  Data di rilasc=
io: 09/09/2012
>
>
Tried without GPLPV, same result with cd-eject
Tried also gdb but probably somethink is missing

gdb --args xl -vvv cd-eject W7 hdb
GNU gdb (GDB) 7.4.1-debian
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later=20
<http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying=
"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /usr/sbin/xl...done.
(gdb) bt
No stack.


--------------ms040405010208010703070903
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: Firma crittografica S/MIME

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINhjCC
BjQwggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT
DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp
Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3
MTAyNDIxMDI1NVoXDTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T
dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu
aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs
aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOM
KqANy9BV7V0igWdGxA8IU77L3aTxErQ+fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi
8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke/s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8M
DP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHksw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y
2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHHtOkzUreG//CsFnB9+uaYSlR65cdG
zTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB
Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd+q9rMfPIHeOsuzAfBgNV
HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH
MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3
dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu
c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v
c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0
dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93
d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqp
Jw3I07QWke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Mic
c/NXcs7kPBRdn6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9Jphw
UPTXwHovjavRnhUQHLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMc
p+reg9901zkyT3fDW/ivJVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT
+HBDYtbuvexNftwNQKD5193A7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1X
hwby6mLhkbaXslkVtwEWT3Van49rKjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvO
hNz/QplNa+VkIsrcp7+8ZhP1l1b2U6MaxIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC
0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqh
AChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H75dVCV33K6FuxZrf09yTz+Vx/PkdRUYk
XmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHSjCCBjKgAwIBAgICHmMwDQYJKoZIhvcNAQEF
BQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJT
ZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD
bGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0xMjAzMTgyMjE0MzBa
Fw0xNDAzMjAwODU3MDlaMIGMMRkwFwYDVQQNExBlQjZPRTM3UlJOUHlsNW0yMQswCQYDVQQG
EwJJVDEQMA4GA1UECBMHQmVyZ2FtbzEQMA4GA1UEBxMHUm92ZXR0YTEWMBQGA1UEAxMNRmFi
aW8gRmFudG9uaTEmMCQGCSqGSIb3DQEJARYXZmFudG9uaWZhYmlvQHRpc2NhbGkuaXQwggEi
MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC1XhckXsX23vgJq76s2f0KT8U8Msov5QgV
10eQBb2wL/TzcmqtZotI7ztKVhio3ehHg+mfu+3EqOkX9Umgut8rP0bPi7AGjkPXbOTT/cSU
Xz2Kw31VGOmiOVoUFGvpQitp3weCkhUJLBipI8EpNyBXpjtQ9yCpnIAqfuc77ybfSnCy7tTR
MBq1BUkfjH1+GL45riosuS4+F+MSUvlYzLiT4rAduAX1Y2IuORDsf9Bce8GBxa6syP9rCyzl
Vk7DIX5k8j2vlnyRATIypn5CQLQxGT6e0f6ac4gvWOHwO2QEBsmZKKs1ZidE4q/9OoNXYX6A
jnHtp1H1vcrek/vVcs19AgMBAAGjggOyMIIDrjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAd
BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFFan8cbEWWBmSTWFtLk2
YNdAcGUbMB8GA1UdIwQYMBaAFK5Vg2/sMcq59x36r2sx88gd46y7MCIGA1UdEQQbMBmBF2Zh
bnRvbmlmYWJpb0B0aXNjYWxpLml0MIICIQYDVR0gBIICGDCCAhQwggIQBgsrBgEEAYG1NwEC
AjCCAf8wLgYIKwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYw
NAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYw
gfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMC
AQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNjb3JkaW5nIHRvIHRoZSBDbGFz
cyAyIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3ks
IHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGluIGNvbXBsaWFuY2Ug
b2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMIGcBggrBgEFBQcCAjCBjzAnFiBT
dGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgECGmRMaWFiaWxpdHkgYW5kIHdh
cnJhbnRpZXMgYXJlIGxpbWl0ZWQhIFNlZSBzZWN0aW9uICJMZWdhbCBhbmQgTGltaXRhdGlv
bnMiIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3kuMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6
Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUyLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYI
KwYBBQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MyL2NsaWVudC9j
YTBCBggrBgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNz
Mi5jbGllbnQuY2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzAN
BgkqhkiG9w0BAQUFAAOCAQEAjzHNqifpDVMkH1TSPFZVIiQ4fh49/V5JMpstgqEZPDaDe5r8
h+fMBZtUa6LLMco03Z9BNEXlqlXKiFk8feVYB8obEjz7YYq1XhO9q7JUmkSs0WGIH4xU0XB1
kPC8T8H+5E//84poYSFHE4pA+Ff68UANP2/EuFJWMjegiefnOr8aM42OAcUkjEWSlautIIX8
oD2GizwQYjWdDDjEonbuMKFP6rY2xGI3PSLI3IVU2opb0/itNhQui3WRxafloJqTlriY8m8+
qSLr2HGftbBlbyzVWB8o//aW0H0LMabjkIvrm7Zmh2vcCxiSxGBwYASuSYXGuQiKAgGptUs1
XJLZuzGCA9owggPWAgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20g
THRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG
A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EC
Ah5jMAkGBSsOAwIaBQCgggIbMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcN
AQkFMQ8XDTEyMDkxMDEzMzYzOVowIwYJKoZIhvcNAQkEMRYEFBLzVPhgDQ/3UcCNvEHCkEk/
RU4mMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggqhkiG
9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcN
AwICASgwgaQGCSsGAQQBgjcQBDGBljCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0
YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25p
bmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp
ZW50IENBAgIeYzCBpgYLKoZIhvcNAQkQAgsxgZaggZMwgYwxCzAJBgNVBAYTAklMMRYwFAYD
VQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0
ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRp
YXRlIENsaWVudCBDQQICHmMwDQYJKoZIhvcNAQEBBQAEggEAJmfAcMt5YtsoCsFczrvna3m8
nLzTJSdt2C6454nu3NQY8hieMecOwUa0iW2kw8j6Yr5vBxSVgDE8t1aiPCYkAMjXvnQVRvWv
I3jefEfSnLwqO9bt6wB2dQRr3IT38x9PM5ad+9hzMoL36/ziZDiqmaT/Bd+DpaYNd/HQtNrB
ue/547+cGm+OSEg/kzLMqNE2bxFtHx7tO8j8xQ6Pkm45wwBQIh1CZHC1gOClr7r3El+FXyZp
x/oZBUFeVUuxXeQePAUiBHeQrlVQ3+VJd2NknS5Ll1X9+9TBV5Z9bU6LRoFUh3TcMgVLPenN
wI3uplj+YezPimEBY2OPsMep715kuAAAAAAAAA==
--------------ms040405010208010703070903--


--===============2718414259976601644==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============2718414259976601644==--


From xen-devel-bounces@lists.xen.org Mon Sep 10 13:39:27 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Sep 2012 13: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 1TB4Cq-0008LC-Ic; Mon, 10 Sep 2012 13:39: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 1TB4Cp-0008L5-Hc
	for xen-devel@lists.xen.org; Mon, 10 Sep 2012 13:39:15 +0000
Received: from [85.158.143.35:45210] by server-1.bemta-4.messagelabs.com id
	DE/C5-12504-28DED405; Mon, 10 Sep 2012 13:39:14 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1347284299!12381840!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM5OTE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21972 invoked from network); 10 Sep 2012 13:38:20 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-11.tower-21.messagelabs.com with SMTP;
	10 Sep 2012 13:38:20 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 10 Sep 2012 14:38:18 +0100
Message-Id: <504E0968020000780009A397@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 10 Sep 2012 14:38:16 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Julien Grall" <julien.grall@citrix.com>
References: <cover.1345552068.git.julien.grall@citrix.com>
	<c378b04ee29071c1d6d68bd3ef48fedadb493b10.1345552068.git.julien.grall@citrix.com>
	<5035E986020000780008A617@nat28.tlf.novell.com>
	<50360B81.2070402@citrix.com>
	<5037AE20020000780008A7A8@nat28.tlf.novell.com>
	<504DE4EF.5070004@citrix.com>
	<504E0600020000780009A37F@nat28.tlf.novell.com>
	<504DECBF.2000306@citrix.com>
In-Reply-To: <504DECBF.2000306@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "christian.limpach@gmail.com" <christian.limpach@gmail.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [XEN][RFC PATCH V2 05/17] hvm: Modify 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

>>> On 10.09.12 at 15:35, Julien Grall <julien.grall@citrix.com> wrote:
> On 09/10/2012 02:23 PM, Jan Beulich wrote:
>>>>> On 10.09.12 at 15:02, Julien Grall<julien.grall@citrix.com>  wrote:
>>>>>          
>>> On 08/24/2012 04:38 PM, Jan Beulich wrote:
>>>      
>>>>>>> On 23.08.12 at 12:52, Julien Grall<julien.grall@citrix.com>   wrote:
>>>>>>>
>>>>>>>              
>>>>> On 08/23/2012 08:27 AM, Jan Beulich wrote:
>>>>>
>>>>>          
>>>>>>> switch ( a.index )
>>>>>>> {
>>>>>>> -            case HVM_PARAM_IOREQ_PFN:
>>>>>>>
>>>>>>>
>>>>>>>              
>>>>>> Removing sub-ops which a domain can issue for itself (which for this and
>>>>>> another one below appears to be the case) is not allowed.
>>>>>>
>>>>>>
>>>>>>            
>>>>> I removed these 3 sub-ops because it will not work with
>>>>> QEMU disaggregation. Shared pages and event channel
>>>>> for IO request are private for each device model.
>>>>>
>>>>>          
>>>> Then they need to be made inaccessible for that specific setup, not
>>>> removed altogether.
>>>>
>>>>
>>>>        
>>> What do you mean by specific feature ?
>>> With this patch series, you are able to handle one or more
>>> QEMU.
>>> Keep a compatibility with the old IO emulation is hard.
>>>      
>> Did you read my original reply? Code backing operations that a
>> guest can issue itself (i.e. without qemu or another host side
>> component involved) just can't be removed, as you/we have
>> no control over which guest(s) may be making use of that
>> functionality.
>>    
> 
> Ah ok misundertanding of my part. I don't really understand
> in which case a domain needs to retrieve its ioreq page.
> How can I made it inaccessible ? Just rc = -EINVAL ?

Probably, but you'd better talk to whoever added that code
(including to determine whether this by mistake was left guest
invokable).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 10 13:39:27 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Sep 2012 13: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 1TB4Cq-0008LC-Ic; Mon, 10 Sep 2012 13:39: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 1TB4Cp-0008L5-Hc
	for xen-devel@lists.xen.org; Mon, 10 Sep 2012 13:39:15 +0000
Received: from [85.158.143.35:45210] by server-1.bemta-4.messagelabs.com id
	DE/C5-12504-28DED405; Mon, 10 Sep 2012 13:39:14 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1347284299!12381840!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM5OTE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21972 invoked from network); 10 Sep 2012 13:38:20 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-11.tower-21.messagelabs.com with SMTP;
	10 Sep 2012 13:38:20 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 10 Sep 2012 14:38:18 +0100
Message-Id: <504E0968020000780009A397@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 10 Sep 2012 14:38:16 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Julien Grall" <julien.grall@citrix.com>
References: <cover.1345552068.git.julien.grall@citrix.com>
	<c378b04ee29071c1d6d68bd3ef48fedadb493b10.1345552068.git.julien.grall@citrix.com>
	<5035E986020000780008A617@nat28.tlf.novell.com>
	<50360B81.2070402@citrix.com>
	<5037AE20020000780008A7A8@nat28.tlf.novell.com>
	<504DE4EF.5070004@citrix.com>
	<504E0600020000780009A37F@nat28.tlf.novell.com>
	<504DECBF.2000306@citrix.com>
In-Reply-To: <504DECBF.2000306@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "christian.limpach@gmail.com" <christian.limpach@gmail.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [XEN][RFC PATCH V2 05/17] hvm: Modify 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

>>> On 10.09.12 at 15:35, Julien Grall <julien.grall@citrix.com> wrote:
> On 09/10/2012 02:23 PM, Jan Beulich wrote:
>>>>> On 10.09.12 at 15:02, Julien Grall<julien.grall@citrix.com>  wrote:
>>>>>          
>>> On 08/24/2012 04:38 PM, Jan Beulich wrote:
>>>      
>>>>>>> On 23.08.12 at 12:52, Julien Grall<julien.grall@citrix.com>   wrote:
>>>>>>>
>>>>>>>              
>>>>> On 08/23/2012 08:27 AM, Jan Beulich wrote:
>>>>>
>>>>>          
>>>>>>> switch ( a.index )
>>>>>>> {
>>>>>>> -            case HVM_PARAM_IOREQ_PFN:
>>>>>>>
>>>>>>>
>>>>>>>              
>>>>>> Removing sub-ops which a domain can issue for itself (which for this and
>>>>>> another one below appears to be the case) is not allowed.
>>>>>>
>>>>>>
>>>>>>            
>>>>> I removed these 3 sub-ops because it will not work with
>>>>> QEMU disaggregation. Shared pages and event channel
>>>>> for IO request are private for each device model.
>>>>>
>>>>>          
>>>> Then they need to be made inaccessible for that specific setup, not
>>>> removed altogether.
>>>>
>>>>
>>>>        
>>> What do you mean by specific feature ?
>>> With this patch series, you are able to handle one or more
>>> QEMU.
>>> Keep a compatibility with the old IO emulation is hard.
>>>      
>> Did you read my original reply? Code backing operations that a
>> guest can issue itself (i.e. without qemu or another host side
>> component involved) just can't be removed, as you/we have
>> no control over which guest(s) may be making use of that
>> functionality.
>>    
> 
> Ah ok misundertanding of my part. I don't really understand
> in which case a domain needs to retrieve its ioreq page.
> How can I made it inaccessible ? Just rc = -EINVAL ?

Probably, but you'd better talk to whoever added that code
(including to determine whether this by mistake was left guest
invokable).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 10 13:43:33 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Sep 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 1TB4Gp-00006y-D0; Mon, 10 Sep 2012 13:43: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 1TB4Gn-00006t-IO
	for xen-devel@lists.xensource.com; Mon, 10 Sep 2012 13:43:21 +0000
Received: from [85.158.143.99:39354] by server-3.bemta-4.messagelabs.com id
	9A/AD-08232-87EED405; Mon, 10 Sep 2012 13:43:20 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1347284517!26164841!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTIyODk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18217 invoked from network); 10 Sep 2012 13:41:57 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Sep 2012 13:41:57 -0000
X-IronPort-AV: E=Sophos;i="4.80,398,1344211200"; d="scan'208";a="14444836"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Sep 2012 13:41: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.279.1;
	Mon, 10 Sep 2012 14:41:57 +0100
Message-ID: <1347284515.5305.85.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "fantonifabio@tiscali.it" <fantonifabio@tiscali.it>
Date: Mon, 10 Sep 2012 14:41:55 +0100
In-Reply-To: <504DECE7.1050404@tiscali.it>
References: <5049EC11.9080302@tiscali.it>
	<1347030955.30018.115.camel@zakaz.uk.xensource.com>
	<504DB165.6040500@tiscali.it>
	<1347269362.5305.39.camel@zakaz.uk.xensource.com>
	<504DECE7.1050404@tiscali.it>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Test report of xen 4.2.0-rc4
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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-09-10 at 14:36 +0100, Fabio Fantoni wrote:
> gdb --args xl -vvv cd-eject W7 hdb
> GNU gdb (GDB) 7.4.1-debian
> Copyright (C) 2012 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later 
> <http://gnu.org/licenses/gpl.html>
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
> and "show warranty" for details.
> This GDB was configured as "x86_64-linux-gnu".
> For bug reporting instructions, please see:
> <http://www.gnu.org/software/gdb/bugs/>...
> Reading symbols from /usr/sbin/xl...done.

Oops, sorry I forget to say:

Enter "run" at this point to actually run the command.

> (gdb) bt
> No stack.
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 10 13:43:33 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Sep 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 1TB4Gp-00006y-D0; Mon, 10 Sep 2012 13:43: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 1TB4Gn-00006t-IO
	for xen-devel@lists.xensource.com; Mon, 10 Sep 2012 13:43:21 +0000
Received: from [85.158.143.99:39354] by server-3.bemta-4.messagelabs.com id
	9A/AD-08232-87EED405; Mon, 10 Sep 2012 13:43:20 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1347284517!26164841!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTIyODk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18217 invoked from network); 10 Sep 2012 13:41:57 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Sep 2012 13:41:57 -0000
X-IronPort-AV: E=Sophos;i="4.80,398,1344211200"; d="scan'208";a="14444836"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Sep 2012 13:41: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.279.1;
	Mon, 10 Sep 2012 14:41:57 +0100
Message-ID: <1347284515.5305.85.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "fantonifabio@tiscali.it" <fantonifabio@tiscali.it>
Date: Mon, 10 Sep 2012 14:41:55 +0100
In-Reply-To: <504DECE7.1050404@tiscali.it>
References: <5049EC11.9080302@tiscali.it>
	<1347030955.30018.115.camel@zakaz.uk.xensource.com>
	<504DB165.6040500@tiscali.it>
	<1347269362.5305.39.camel@zakaz.uk.xensource.com>
	<504DECE7.1050404@tiscali.it>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Test report of xen 4.2.0-rc4
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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-09-10 at 14:36 +0100, Fabio Fantoni wrote:
> gdb --args xl -vvv cd-eject W7 hdb
> GNU gdb (GDB) 7.4.1-debian
> Copyright (C) 2012 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later 
> <http://gnu.org/licenses/gpl.html>
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
> and "show warranty" for details.
> This GDB was configured as "x86_64-linux-gnu".
> For bug reporting instructions, please see:
> <http://www.gnu.org/software/gdb/bugs/>...
> Reading symbols from /usr/sbin/xl...done.

Oops, sorry I forget to say:

Enter "run" at this point to actually run the command.

> (gdb) bt
> No stack.
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 10 13:50:50 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Sep 2012 13: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 1TB4Nk-0000Hy-8d; Mon, 10 Sep 2012 13:50:32 +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 1TB4Ni-0000Ht-3D
	for xen-devel@lists.xen.org; Mon, 10 Sep 2012 13:50:30 +0000
Received: from [85.158.139.83:38242] by server-12.bemta-5.messagelabs.com id
	7A/88-18300-520FD405; Mon, 10 Sep 2012 13:50:29 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1347285026!29604574!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTIyODk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26710 invoked from network); 10 Sep 2012 13:50:27 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Sep 2012 13:50:27 -0000
X-IronPort-AV: E=Sophos;i="4.80,398,1344211200"; d="scan'208";a="14445118"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Sep 2012 13:50: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.279.1; Mon, 10 Sep 2012 14:50:25 +0100
Date: Mon, 10 Sep 2012 14:49:45 +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: <504A0BB50200007800099CD2@nat28.tlf.novell.com>
Message-ID: <alpine.DEB.2.02.1209101449390.15568@kaball.uk.xensource.com>
References: <504A0BB50200007800099CD2@nat28.tlf.novell.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] x86/hvm: don't give vector callback higher
 priority than NMI/MCE
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 7 Sep 2012, Jan Beulich wrote:
> Those two should always be delivered first imo.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

> --- a/xen/arch/x86/hvm/irq.c
> +++ b/xen/arch/x86/hvm/irq.c
> @@ -395,16 +395,16 @@ struct hvm_intack hvm_vcpu_has_pending_i
>      struct hvm_domain *plat = &v->domain->arch.hvm_domain;
>      int vector;
>  
> -    if ( (plat->irq.callback_via_type == HVMIRQ_callback_vector)
> -         && vcpu_info(v, evtchn_upcall_pending) )
> -        return hvm_intack_vector(plat->irq.callback_via.vector);
> -
>      if ( unlikely(v->nmi_pending) )
>          return hvm_intack_nmi;
>  
>      if ( unlikely(v->mce_pending) )
>          return hvm_intack_mce;
>  
> +    if ( (plat->irq.callback_via_type == HVMIRQ_callback_vector)
> +         && vcpu_info(v, evtchn_upcall_pending) )
> +        return hvm_intack_vector(plat->irq.callback_via.vector);
> +
>      if ( vlapic_accept_pic_intr(v) && plat->vpic[0].int_output )
>          return hvm_intack_pic(0);
>  
> 
> 
> 
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 10 13:50:50 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Sep 2012 13: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 1TB4Nk-0000Hy-8d; Mon, 10 Sep 2012 13:50:32 +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 1TB4Ni-0000Ht-3D
	for xen-devel@lists.xen.org; Mon, 10 Sep 2012 13:50:30 +0000
Received: from [85.158.139.83:38242] by server-12.bemta-5.messagelabs.com id
	7A/88-18300-520FD405; Mon, 10 Sep 2012 13:50:29 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1347285026!29604574!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTIyODk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26710 invoked from network); 10 Sep 2012 13:50:27 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Sep 2012 13:50:27 -0000
X-IronPort-AV: E=Sophos;i="4.80,398,1344211200"; d="scan'208";a="14445118"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Sep 2012 13:50: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.279.1; Mon, 10 Sep 2012 14:50:25 +0100
Date: Mon, 10 Sep 2012 14:49:45 +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: <504A0BB50200007800099CD2@nat28.tlf.novell.com>
Message-ID: <alpine.DEB.2.02.1209101449390.15568@kaball.uk.xensource.com>
References: <504A0BB50200007800099CD2@nat28.tlf.novell.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] x86/hvm: don't give vector callback higher
 priority than NMI/MCE
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 7 Sep 2012, Jan Beulich wrote:
> Those two should always be delivered first imo.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

> --- a/xen/arch/x86/hvm/irq.c
> +++ b/xen/arch/x86/hvm/irq.c
> @@ -395,16 +395,16 @@ struct hvm_intack hvm_vcpu_has_pending_i
>      struct hvm_domain *plat = &v->domain->arch.hvm_domain;
>      int vector;
>  
> -    if ( (plat->irq.callback_via_type == HVMIRQ_callback_vector)
> -         && vcpu_info(v, evtchn_upcall_pending) )
> -        return hvm_intack_vector(plat->irq.callback_via.vector);
> -
>      if ( unlikely(v->nmi_pending) )
>          return hvm_intack_nmi;
>  
>      if ( unlikely(v->mce_pending) )
>          return hvm_intack_mce;
>  
> +    if ( (plat->irq.callback_via_type == HVMIRQ_callback_vector)
> +         && vcpu_info(v, evtchn_upcall_pending) )
> +        return hvm_intack_vector(plat->irq.callback_via.vector);
> +
>      if ( vlapic_accept_pic_intr(v) && plat->vpic[0].int_output )
>          return hvm_intack_pic(0);
>  
> 
> 
> 
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 10 13:56:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Sep 2012 13:56: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 1TB4T0-0000Qz-1H; Mon, 10 Sep 2012 13:55: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 1TB4Sy-0000Qr-Io
	for Xen-devel@lists.xensource.com; Mon, 10 Sep 2012 13:55:56 +0000
Received: from [85.158.138.51:12017] by server-9.bemta-3.messagelabs.com id
	7E/2A-15390-B61FD405; Mon, 10 Sep 2012 13:55:55 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1347285354!27936634!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTIyODk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 976 invoked from network); 10 Sep 2012 13:55:55 -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;
	10 Sep 2012 13:55:55 -0000
X-IronPort-AV: E=Sophos;i="4.80,398,1344211200"; d="scan'208";a="14445276"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Sep 2012 13:55: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.279.1;
	Mon, 10 Sep 2012 14:55:54 +0100
Message-ID: <1347285352.5305.86.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Mukesh Rathor <mukesh.rathor@oracle.com>
Date: Mon, 10 Sep 2012 14:55:52 +0100
In-Reply-To: <20120815175724.3405043a@mantra.us.oracle.com>
References: <20120815175724.3405043a@mantra.us.oracle.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [RFC PATCH 1/8]: PVH: Basic and preparatory changes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-08-16 at 01:57 +0100, Mukesh Rathor wrote:
> diff --git a/include/xen/xen.h b/include/xen/xen.h
> index a164024..e823639 100644
> --- a/include/xen/xen.h
> +++ b/include/xen/xen.h
> @@ -18,6 +18,10 @@ extern enum xen_domain_type xen_domain_type;
>                                  xen_domain_type == XEN_PV_DOMAIN)
>  #define xen_hvm_domain()       (xen_domain() &&                        \
>                                  xen_domain_type == XEN_HVM_DOMAIN)
> +/* xen_pv_domain check is necessary as start_info ptr is null in HVM. Also,
> + * note, xen PVH domain shares lot of HVM code */
> +#define xen_pvh_domain()       (xen_pv_domain() &&                     \
> +                               (xen_start_info->flags & SIF_IS_PVINHVM))

Can I suggest that for the time being this be gated on a new
CONFIG_XEN_PVH option (I think it's new, I can't find one right now)
which "depends EXPERIMENTAL".

We don't want to get into the situation where whatever goes into Linux
now makes it into a distro (and is enabled) and is subsequently broken
on top of whatever the final hypervisor side stuff ends up looking like.
We've done the same for the ARM support for example.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 10 13:56:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Sep 2012 13:56: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 1TB4T0-0000Qz-1H; Mon, 10 Sep 2012 13:55: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 1TB4Sy-0000Qr-Io
	for Xen-devel@lists.xensource.com; Mon, 10 Sep 2012 13:55:56 +0000
Received: from [85.158.138.51:12017] by server-9.bemta-3.messagelabs.com id
	7E/2A-15390-B61FD405; Mon, 10 Sep 2012 13:55:55 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1347285354!27936634!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTIyODk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 976 invoked from network); 10 Sep 2012 13:55:55 -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;
	10 Sep 2012 13:55:55 -0000
X-IronPort-AV: E=Sophos;i="4.80,398,1344211200"; d="scan'208";a="14445276"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Sep 2012 13:55: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.279.1;
	Mon, 10 Sep 2012 14:55:54 +0100
Message-ID: <1347285352.5305.86.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Mukesh Rathor <mukesh.rathor@oracle.com>
Date: Mon, 10 Sep 2012 14:55:52 +0100
In-Reply-To: <20120815175724.3405043a@mantra.us.oracle.com>
References: <20120815175724.3405043a@mantra.us.oracle.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [RFC PATCH 1/8]: PVH: Basic and preparatory changes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-08-16 at 01:57 +0100, Mukesh Rathor wrote:
> diff --git a/include/xen/xen.h b/include/xen/xen.h
> index a164024..e823639 100644
> --- a/include/xen/xen.h
> +++ b/include/xen/xen.h
> @@ -18,6 +18,10 @@ extern enum xen_domain_type xen_domain_type;
>                                  xen_domain_type == XEN_PV_DOMAIN)
>  #define xen_hvm_domain()       (xen_domain() &&                        \
>                                  xen_domain_type == XEN_HVM_DOMAIN)
> +/* xen_pv_domain check is necessary as start_info ptr is null in HVM. Also,
> + * note, xen PVH domain shares lot of HVM code */
> +#define xen_pvh_domain()       (xen_pv_domain() &&                     \
> +                               (xen_start_info->flags & SIF_IS_PVINHVM))

Can I suggest that for the time being this be gated on a new
CONFIG_XEN_PVH option (I think it's new, I can't find one right now)
which "depends EXPERIMENTAL".

We don't want to get into the situation where whatever goes into Linux
now makes it into a distro (and is enabled) and is subsequently broken
on top of whatever the final hypervisor side stuff ends up looking like.
We've done the same for the ARM support for example.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 10 14:00:25 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Sep 2012 14: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 1TB4X4-0000df-OO; Mon, 10 Sep 2012 14:00:10 +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 1TB4X3-0000dZ-GB
	for xen-devel@lists.xen.org; Mon, 10 Sep 2012 14:00:09 +0000
Received: from [85.158.138.51:57608] by server-2.bemta-3.messagelabs.com id
	E6/7E-04862-862FD405; Mon, 10 Sep 2012 14:00:08 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1347285606!29618862!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-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30189 invoked from network); 10 Sep 2012 14:00:07 -0000
Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com)
	(74.125.83.45)
	by server-16.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Sep 2012 14:00:07 -0000
Received: by eeke53 with SMTP id e53so1217680eek.32
	for <xen-devel@lists.xen.org>; Mon, 10 Sep 2012 07:00:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=NGqia8fyLHZVyHbZfs1+LJ8dzB1VxWBg718PzF2WBRU=;
	b=OSjane2zxmitZ6JiBdwLZxzUm0jIKk/HWVFNf2m9uCCkG2emwXcQBtY7ODVoCFvktR
	86k+blSV52dULL/HaYfHZ7FuK/hpBP85znWZ9Sl5/NiJCMaelHqdc6CN0ESbgUBI5D3Q
	QII8o7bJZ0FreqmNQpnh1UCbIX+znMW2mNSMY6Nws63WfpwENbWbTDHT8gCVuvWf+R/I
	shuhmhwE8Xu9bxgfdj5clEBV9CSrhXy4A2JMof71Ae9PQG9Z3YjTKBD6SNe+ghthzZux
	5mKfzY+mbbl3V7/ELtdqr2NUF0NGNtaot8o3OE9SxD3rnfbrMQX7mHjLELZBSf/POcUj
	fUPw==
Received: by 10.14.202.71 with SMTP id c47mr20035656eeo.42.1347285606741;
	Mon, 10 Sep 2012 07:00:06 -0700 (PDT)
Received: from [192.168.1.69] (host86-184-74-117.range86-184.btcentralplus.com.
	[86.184.74.117])
	by mx.google.com with ESMTPS id r45sm38418819eem.6.2012.09.10.07.00.04
	(version=SSLv3 cipher=OTHER); Mon, 10 Sep 2012 07:00:05 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Mon, 10 Sep 2012 15:00:01 +0100
From: Keir Fraser <keir.xen@gmail.com>
To: <xen-devel@lists.xen.org>
Message-ID: <CC73B0F1.3E3CC%keir.xen@gmail.com>
Thread-Topic: [ANNOUNCE] Xen x86 32-bit hypervisor end of life after 4.2
Thread-Index: Ac2Oe91j9M1uXMmVDU+bWl7qtvqJWAA4LRwQ
In-Reply-To: <CC7237F3.3E2CD%keir.xen@gmail.com>
Mime-version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [ANNOUNCE] Xen x86 32-bit hypervisor end of life
	after 4.2
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 09/09/2012 12:11, "Keir Fraser" <keir.xen@gmail.com> wrote:

> Folks,
> 
> With 64-bit support well established in the x86 world these days, the number
> of x86 production environments that cannot run a 64-bit hypervisor is pretty
> much nil. Maintaining the 32-bit x86 port, and implementing new features for
> it, is an ongoing development burden which could be more usefully directed
> elsewhere. Therefore, 32-bit x86 will be considered obsolete in the 4.3
> development branch, and removed.

Ian,

Please can you remove x86_32 from the automated tests for xen-unstable?

 Thanks,
 Keir

> 32-bit x86 will continue to be maintained and supported (insofar as it has
> been recently) in the supported stable branches: 3.4, 4.1, and 4.2.
> 
> Furthermore, 32-bit guests (including 32-bit PV guests) will continue to be
> supported on the 64-bit hypervisor, as they always have been.
> 
>  Regards,
>  Keir & The Xen Team
> 
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 10 14:00:25 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Sep 2012 14: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 1TB4X4-0000df-OO; Mon, 10 Sep 2012 14:00:10 +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 1TB4X3-0000dZ-GB
	for xen-devel@lists.xen.org; Mon, 10 Sep 2012 14:00:09 +0000
Received: from [85.158.138.51:57608] by server-2.bemta-3.messagelabs.com id
	E6/7E-04862-862FD405; Mon, 10 Sep 2012 14:00:08 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1347285606!29618862!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-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30189 invoked from network); 10 Sep 2012 14:00:07 -0000
Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com)
	(74.125.83.45)
	by server-16.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Sep 2012 14:00:07 -0000
Received: by eeke53 with SMTP id e53so1217680eek.32
	for <xen-devel@lists.xen.org>; Mon, 10 Sep 2012 07:00:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=NGqia8fyLHZVyHbZfs1+LJ8dzB1VxWBg718PzF2WBRU=;
	b=OSjane2zxmitZ6JiBdwLZxzUm0jIKk/HWVFNf2m9uCCkG2emwXcQBtY7ODVoCFvktR
	86k+blSV52dULL/HaYfHZ7FuK/hpBP85znWZ9Sl5/NiJCMaelHqdc6CN0ESbgUBI5D3Q
	QII8o7bJZ0FreqmNQpnh1UCbIX+znMW2mNSMY6Nws63WfpwENbWbTDHT8gCVuvWf+R/I
	shuhmhwE8Xu9bxgfdj5clEBV9CSrhXy4A2JMof71Ae9PQG9Z3YjTKBD6SNe+ghthzZux
	5mKfzY+mbbl3V7/ELtdqr2NUF0NGNtaot8o3OE9SxD3rnfbrMQX7mHjLELZBSf/POcUj
	fUPw==
Received: by 10.14.202.71 with SMTP id c47mr20035656eeo.42.1347285606741;
	Mon, 10 Sep 2012 07:00:06 -0700 (PDT)
Received: from [192.168.1.69] (host86-184-74-117.range86-184.btcentralplus.com.
	[86.184.74.117])
	by mx.google.com with ESMTPS id r45sm38418819eem.6.2012.09.10.07.00.04
	(version=SSLv3 cipher=OTHER); Mon, 10 Sep 2012 07:00:05 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Mon, 10 Sep 2012 15:00:01 +0100
From: Keir Fraser <keir.xen@gmail.com>
To: <xen-devel@lists.xen.org>
Message-ID: <CC73B0F1.3E3CC%keir.xen@gmail.com>
Thread-Topic: [ANNOUNCE] Xen x86 32-bit hypervisor end of life after 4.2
Thread-Index: Ac2Oe91j9M1uXMmVDU+bWl7qtvqJWAA4LRwQ
In-Reply-To: <CC7237F3.3E2CD%keir.xen@gmail.com>
Mime-version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [ANNOUNCE] Xen x86 32-bit hypervisor end of life
	after 4.2
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 09/09/2012 12:11, "Keir Fraser" <keir.xen@gmail.com> wrote:

> Folks,
> 
> With 64-bit support well established in the x86 world these days, the number
> of x86 production environments that cannot run a 64-bit hypervisor is pretty
> much nil. Maintaining the 32-bit x86 port, and implementing new features for
> it, is an ongoing development burden which could be more usefully directed
> elsewhere. Therefore, 32-bit x86 will be considered obsolete in the 4.3
> development branch, and removed.

Ian,

Please can you remove x86_32 from the automated tests for xen-unstable?

 Thanks,
 Keir

> 32-bit x86 will continue to be maintained and supported (insofar as it has
> been recently) in the supported stable branches: 3.4, 4.1, and 4.2.
> 
> Furthermore, 32-bit guests (including 32-bit PV guests) will continue to be
> supported on the 64-bit hypervisor, as they always have been.
> 
>  Regards,
>  Keir & The Xen Team
> 
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 10 14:09:29 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Sep 2012 14:09:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TB4fq-0000r8-P7; Mon, 10 Sep 2012 14:09:14 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andreslc@gridcentric.ca>) id 1TB4fp-0000r3-4D
	for xen-devel@lists.xen.org; Mon, 10 Sep 2012 14:09:13 +0000
Received: from [85.158.143.35:62892] by server-2.bemta-4.messagelabs.com id
	0F/83-21239-884FD405; Mon, 10 Sep 2012 14:09:12 +0000
X-Env-Sender: andreslc@gridcentric.ca
X-Msg-Ref: server-13.tower-21.messagelabs.com!1347286101!16162974!1
X-Originating-IP: [209.85.223.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17307 invoked from network); 10 Sep 2012 14:08:22 -0000
Received: from mail-ie0-f173.google.com (HELO mail-ie0-f173.google.com)
	(209.85.223.173)
	by server-13.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Sep 2012 14:08:22 -0000
Received: by iebc10 with SMTP id c10so3863130ieb.32
	for <xen-devel@lists.xen.org>; Mon, 10 Sep 2012 07:08:20 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=from:content-type:content-transfer-encoding:subject:date:message-id
	:to:mime-version:x-mailer:x-gm-message-state;
	bh=GU3dYySxCDuu5MagMIRagDf/dizEzKbTSuj0S1paCmo=;
	b=BA9gBrMlyH5GiVCyUB9Z+ew/zLzAGxxAKJD4t0ciEnF1nKL4z5IPMRAixXyyG+S/x4
	xq0tvOdmttBgqErQLrvXD6EKXCkgpDdV8vBzbKICrt7hPNFFuXMWFXSqOxihpCsubECL
	mz52Yty9msWhzPp8PYCTiNn73kH/CA677AJOLTJiO0iPP36tIeB77E6D9XTpgztILxem
	cZypmH4k1Nu5lnHJlr98IXWk/oPwU2sazZFT79Irnc/nZs2gX1Hc/8lasgfqbC+aDZuK
	rXcYgkOyrT8PksZTa1q34Rc01S8iU8JJPnG5GYVrnJMGwA+cAdPkG+Xz6oSI7W6baoHy
	6ZVQ==
Received: by 10.50.140.74 with SMTP id re10mr2498664igb.52.1347286100670;
	Mon, 10 Sep 2012 07:08:20 -0700 (PDT)
Received: from [192.168.1.100] (69-196-182-10.dsl.teksavvy.com.
	[69.196.182.10]) by mx.google.com with ESMTPS id
	in10sm20937435igc.14.2012.09.10.07.08.19
	(version=TLSv1/SSLv3 cipher=OTHER);
	Mon, 10 Sep 2012 07:08:20 -0700 (PDT)
From: Andres Lagar-Cavilla <andreslc@gridcentric.ca>
Date: Mon, 10 Sep 2012 10:08:20 -0400
Message-Id: <08A8CD72-BB08-4178-945D-90C588A78F14@gridcentric.ca>
To: xen-devel <xen-devel@lists.xen.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Ian Campbell <ian.campbell@citrix.com>, Olaf Hering <olaf@aepfle.de>,
	Tim Deegan <tim@xen.org>
Mime-Version: 1.0 (Apple Message framework v1278)
X-Mailer: Apple Mail (2.1278)
X-Gm-Message-State: ALoCoQke+Afaaw5mrUebODEo3bqg8+kSVh0E0Yn1CyzFW/i0DDh2O4w/6qqgwNJ2VLb/mOCXQYat
Subject: [Xen-devel] Xen paging unit test
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi,
In the process of submitting the privcmd MMAP_BATCH_V2 patches for Linux 3.7, Konrad asked a very valid question:

"How do you test this thing?"

Turns out that you have two ways
1. You do the actual paging thing on a live domain
2. I had a unit test buried in my stash

Coincidentally, Ian C asked for demonstrable consumers of the xenpaging interface in the process of summarizing the 4.2 change log.

I've github'ed my paging unit test in the hopes it will be found useful, not only as a unit test, but also a demo/reference piece of code. 

The unit test exercises the privcmd/libxc interface for creating foreign mappings of paged out pages. As a precondition, it must create a domain, enable paging on it, and act as a pager to satisfy the page-in requests generated by the foreign maps.

https://github.com/andreslagarcavilla/xenpagingtest

This might be considered useful for tools/tests in xen-unstable, and I'll be happy to resubmit in a suitable form if you ask.

Cheers
Andres
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 10 14:09:29 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Sep 2012 14:09:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TB4fq-0000r8-P7; Mon, 10 Sep 2012 14:09:14 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andreslc@gridcentric.ca>) id 1TB4fp-0000r3-4D
	for xen-devel@lists.xen.org; Mon, 10 Sep 2012 14:09:13 +0000
Received: from [85.158.143.35:62892] by server-2.bemta-4.messagelabs.com id
	0F/83-21239-884FD405; Mon, 10 Sep 2012 14:09:12 +0000
X-Env-Sender: andreslc@gridcentric.ca
X-Msg-Ref: server-13.tower-21.messagelabs.com!1347286101!16162974!1
X-Originating-IP: [209.85.223.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17307 invoked from network); 10 Sep 2012 14:08:22 -0000
Received: from mail-ie0-f173.google.com (HELO mail-ie0-f173.google.com)
	(209.85.223.173)
	by server-13.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Sep 2012 14:08:22 -0000
Received: by iebc10 with SMTP id c10so3863130ieb.32
	for <xen-devel@lists.xen.org>; Mon, 10 Sep 2012 07:08:20 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=from:content-type:content-transfer-encoding:subject:date:message-id
	:to:mime-version:x-mailer:x-gm-message-state;
	bh=GU3dYySxCDuu5MagMIRagDf/dizEzKbTSuj0S1paCmo=;
	b=BA9gBrMlyH5GiVCyUB9Z+ew/zLzAGxxAKJD4t0ciEnF1nKL4z5IPMRAixXyyG+S/x4
	xq0tvOdmttBgqErQLrvXD6EKXCkgpDdV8vBzbKICrt7hPNFFuXMWFXSqOxihpCsubECL
	mz52Yty9msWhzPp8PYCTiNn73kH/CA677AJOLTJiO0iPP36tIeB77E6D9XTpgztILxem
	cZypmH4k1Nu5lnHJlr98IXWk/oPwU2sazZFT79Irnc/nZs2gX1Hc/8lasgfqbC+aDZuK
	rXcYgkOyrT8PksZTa1q34Rc01S8iU8JJPnG5GYVrnJMGwA+cAdPkG+Xz6oSI7W6baoHy
	6ZVQ==
Received: by 10.50.140.74 with SMTP id re10mr2498664igb.52.1347286100670;
	Mon, 10 Sep 2012 07:08:20 -0700 (PDT)
Received: from [192.168.1.100] (69-196-182-10.dsl.teksavvy.com.
	[69.196.182.10]) by mx.google.com with ESMTPS id
	in10sm20937435igc.14.2012.09.10.07.08.19
	(version=TLSv1/SSLv3 cipher=OTHER);
	Mon, 10 Sep 2012 07:08:20 -0700 (PDT)
From: Andres Lagar-Cavilla <andreslc@gridcentric.ca>
Date: Mon, 10 Sep 2012 10:08:20 -0400
Message-Id: <08A8CD72-BB08-4178-945D-90C588A78F14@gridcentric.ca>
To: xen-devel <xen-devel@lists.xen.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Ian Campbell <ian.campbell@citrix.com>, Olaf Hering <olaf@aepfle.de>,
	Tim Deegan <tim@xen.org>
Mime-Version: 1.0 (Apple Message framework v1278)
X-Mailer: Apple Mail (2.1278)
X-Gm-Message-State: ALoCoQke+Afaaw5mrUebODEo3bqg8+kSVh0E0Yn1CyzFW/i0DDh2O4w/6qqgwNJ2VLb/mOCXQYat
Subject: [Xen-devel] Xen paging unit test
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi,
In the process of submitting the privcmd MMAP_BATCH_V2 patches for Linux 3.7, Konrad asked a very valid question:

"How do you test this thing?"

Turns out that you have two ways
1. You do the actual paging thing on a live domain
2. I had a unit test buried in my stash

Coincidentally, Ian C asked for demonstrable consumers of the xenpaging interface in the process of summarizing the 4.2 change log.

I've github'ed my paging unit test in the hopes it will be found useful, not only as a unit test, but also a demo/reference piece of code. 

The unit test exercises the privcmd/libxc interface for creating foreign mappings of paged out pages. As a precondition, it must create a domain, enable paging on it, and act as a pager to satisfy the page-in requests generated by the foreign maps.

https://github.com/andreslagarcavilla/xenpagingtest

This might be considered useful for tools/tests in xen-unstable, and I'll be happy to resubmit in a suitable form if you ask.

Cheers
Andres
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 10 14:16:02 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Sep 2012 14:16: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 1TB4m7-00010z-Sw; Mon, 10 Sep 2012 14:15:43 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1TB4m6-00010u-71
	for xen-devel@lists.xen.org; Mon, 10 Sep 2012 14:15:42 +0000
Received: from [85.158.143.99:4391] by server-1.bemta-4.messagelabs.com id
	9D/4E-12504-D06FD405; Mon, 10 Sep 2012 14:15:41 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1347286530!29207409!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTIyODk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9262 invoked from network); 10 Sep 2012 14:15:31 -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;
	10 Sep 2012 14:15:31 -0000
X-IronPort-AV: E=Sophos;i="4.80,398,1344211200"; d="scan'208";a="14445835"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Sep 2012 14:15: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.279.1; Mon, 10 Sep 2012 15:15: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
	1TB4lR-0004eS-QF; Mon, 10 Sep 2012 14:15:01 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1TB4lR-0000I0-LE;
	Mon, 10 Sep 2012 15:15:01 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20557.62949.300788.804976@mariner.uk.xensource.com>
Date: Mon, 10 Sep 2012 15:15:01 +0100
To: <xen-devel@lists.xen.org>, <ian.campbell@eu.citrix.com>
In-Reply-To: <20544.39460.499127.781598@mariner.uk.xensource.com>
References: <20544.39460.499127.781598@mariner.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Subject: Re: [Xen-devel] Test report: Migration from 4.1 to 4.2 works
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 now managed to redo these tests with an HVM guest (Windows XP,
in this case).

Migration 4.1 xl -> 4.2 xl
  OK

Migration 4.1 xend -> 4.2 xend
  OK

Migration 4.1 xend -> 4.2 xl, plan A:
  Stop xend, use xl to do the migration.

  Fails:

  xc: Saving memory: iter 1 (last sent 134144 skipped 1553): 0/1048576
  0%xc: error: Failed to allocate memory for batch.!: Internal error

  (XEN) page_alloc.c:1284:d0 Over-allocation for domain 23: 131329 > 131328
  (XEN) memory.c:131:d0 Could not allocate order=0 extent: id=23 memflags=0 (288 of 472)

This was always something of a bodge.  It would be nice if we
understood why this doesn't work.

Migration 4.1 xend -> 4.2 xl, plan B:
  Migrate using xm to 4.2 (works).
  Stop xend, say  xenstore-write /local/domain/0/libxl/disable_udev 1
  Check that xl migrate localhost works.  It doesn't - same error
  as above.

Before we call 4.2 final we should think about this migration path.

Also I wrote:

> However, xl fails on config files which are missing the final
> newline.  This should be fixed for 4.2.

My patch for this didn't make it into 4.2 RC4.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 10 14:16:02 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Sep 2012 14:16: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 1TB4m7-00010z-Sw; Mon, 10 Sep 2012 14:15:43 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1TB4m6-00010u-71
	for xen-devel@lists.xen.org; Mon, 10 Sep 2012 14:15:42 +0000
Received: from [85.158.143.99:4391] by server-1.bemta-4.messagelabs.com id
	9D/4E-12504-D06FD405; Mon, 10 Sep 2012 14:15:41 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1347286530!29207409!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTIyODk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9262 invoked from network); 10 Sep 2012 14:15:31 -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;
	10 Sep 2012 14:15:31 -0000
X-IronPort-AV: E=Sophos;i="4.80,398,1344211200"; d="scan'208";a="14445835"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Sep 2012 14:15: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.279.1; Mon, 10 Sep 2012 15:15: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
	1TB4lR-0004eS-QF; Mon, 10 Sep 2012 14:15:01 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1TB4lR-0000I0-LE;
	Mon, 10 Sep 2012 15:15:01 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20557.62949.300788.804976@mariner.uk.xensource.com>
Date: Mon, 10 Sep 2012 15:15:01 +0100
To: <xen-devel@lists.xen.org>, <ian.campbell@eu.citrix.com>
In-Reply-To: <20544.39460.499127.781598@mariner.uk.xensource.com>
References: <20544.39460.499127.781598@mariner.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Subject: Re: [Xen-devel] Test report: Migration from 4.1 to 4.2 works
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 now managed to redo these tests with an HVM guest (Windows XP,
in this case).

Migration 4.1 xl -> 4.2 xl
  OK

Migration 4.1 xend -> 4.2 xend
  OK

Migration 4.1 xend -> 4.2 xl, plan A:
  Stop xend, use xl to do the migration.

  Fails:

  xc: Saving memory: iter 1 (last sent 134144 skipped 1553): 0/1048576
  0%xc: error: Failed to allocate memory for batch.!: Internal error

  (XEN) page_alloc.c:1284:d0 Over-allocation for domain 23: 131329 > 131328
  (XEN) memory.c:131:d0 Could not allocate order=0 extent: id=23 memflags=0 (288 of 472)

This was always something of a bodge.  It would be nice if we
understood why this doesn't work.

Migration 4.1 xend -> 4.2 xl, plan B:
  Migrate using xm to 4.2 (works).
  Stop xend, say  xenstore-write /local/domain/0/libxl/disable_udev 1
  Check that xl migrate localhost works.  It doesn't - same error
  as above.

Before we call 4.2 final we should think about this migration path.

Also I wrote:

> However, xl fails on config files which are missing the final
> newline.  This should be fixed for 4.2.

My patch for this didn't make it into 4.2 RC4.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 10 14:16:24 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Sep 2012 14:16:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TB4mZ-00012Y-9K; Mon, 10 Sep 2012 14:16:11 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1TB4mY-00012L-6P
	for xen-devel@lists.xen.org; Mon, 10 Sep 2012 14:16:10 +0000
Received: from [85.158.139.83:3135] by server-11.bemta-5.messagelabs.com id
	BE/5F-24658-926FD405; Mon, 10 Sep 2012 14:16:09 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1347286568!22281550!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTIyODk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19903 invoked from network); 10 Sep 2012 14:16:09 -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;
	10 Sep 2012 14:16:09 -0000
X-IronPort-AV: E=Sophos;i="4.80,398,1344211200"; d="scan'208";a="14445867"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Sep 2012 14:16: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.279.1; Mon, 10 Sep 2012 15:16: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
	1TB4mV-0004ep-Ot; Mon, 10 Sep 2012 14:16:07 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1TB4mV-0000MX-L7;
	Mon, 10 Sep 2012 15:16:07 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20557.63015.552841.739252@mariner.uk.xensource.com>
Date: Mon, 10 Sep 2012 15:16:07 +0100
To: Keir Fraser <keir.xen@gmail.com>
In-Reply-To: <CC73B0F1.3E3CC%keir.xen@gmail.com>
References: <CC7237F3.3E2CD%keir.xen@gmail.com>
	<CC73B0F1.3E3CC%keir.xen@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] [ANNOUNCE] Xen x86 32-bit hypervisor end of life
	after 4.2
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Keir Fraser writes ("Re: [ANNOUNCE] Xen x86 32-bit hypervisor end of life after 4.2"):
> Please can you remove x86_32 from the automated tests for xen-unstable?

I will do this but I have a number of other things which need to go
through the autotester's tests of itself, first.  I'll let you know
when it's done.

Thanks,
Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 10 14:16:24 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Sep 2012 14:16:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TB4mZ-00012Y-9K; Mon, 10 Sep 2012 14:16:11 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1TB4mY-00012L-6P
	for xen-devel@lists.xen.org; Mon, 10 Sep 2012 14:16:10 +0000
Received: from [85.158.139.83:3135] by server-11.bemta-5.messagelabs.com id
	BE/5F-24658-926FD405; Mon, 10 Sep 2012 14:16:09 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1347286568!22281550!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTIyODk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19903 invoked from network); 10 Sep 2012 14:16:09 -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;
	10 Sep 2012 14:16:09 -0000
X-IronPort-AV: E=Sophos;i="4.80,398,1344211200"; d="scan'208";a="14445867"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Sep 2012 14:16: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.279.1; Mon, 10 Sep 2012 15:16: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
	1TB4mV-0004ep-Ot; Mon, 10 Sep 2012 14:16:07 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1TB4mV-0000MX-L7;
	Mon, 10 Sep 2012 15:16:07 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20557.63015.552841.739252@mariner.uk.xensource.com>
Date: Mon, 10 Sep 2012 15:16:07 +0100
To: Keir Fraser <keir.xen@gmail.com>
In-Reply-To: <CC73B0F1.3E3CC%keir.xen@gmail.com>
References: <CC7237F3.3E2CD%keir.xen@gmail.com>
	<CC73B0F1.3E3CC%keir.xen@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] [ANNOUNCE] Xen x86 32-bit hypervisor end of life
	after 4.2
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Keir Fraser writes ("Re: [ANNOUNCE] Xen x86 32-bit hypervisor end of life after 4.2"):
> Please can you remove x86_32 from the automated tests for xen-unstable?

I will do this but I have a number of other things which need to go
through the autotester's tests of itself, first.  I'll let you know
when it's done.

Thanks,
Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 10 14:23:34 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Sep 2012 14:23:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TB4tT-0001JV-5Z; Mon, 10 Sep 2012 14:23:19 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1TB4tR-0001JQ-Bv
	for xen-devel@lists.xen.org; Mon, 10 Sep 2012 14:23:17 +0000
Received: from [85.158.139.83:53042] by server-1.bemta-5.messagelabs.com id
	21/40-32692-4D7FD405; Mon, 10 Sep 2012 14:23:16 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1347286996!29915836!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-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3145 invoked from network); 10 Sep 2012 14:23:16 -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;
	10 Sep 2012 14:23:16 -0000
Received: by eaac13 with SMTP id c13so960084eaa.32
	for <xen-devel@lists.xen.org>; Mon, 10 Sep 2012 07:23:15 -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=3qVcvF3GZuxbMBcD1zWxtRo6gi9Zlig8OOUviHBupns=;
	b=hHLouCdKsBpupCW1GMoCFOlZbDk4PNHSksEnbUZ8wwGMoOq3xoyIodXkTtU8VFn+Vg
	HlCjnpoF0HY2tsQhOv0LLilkGwgW9J9QD5r6gDvQA6AIsNjo7w6sUHjbdav+BycsllPx
	atR/HyC5ROo3DP1Wd4ylAqSEsv/KeRvL29LpDI1gbl/VE2ohQqvFp8Z+K/JmqInqaQ1h
	sLiEgMjsELHqpdFX+pPO5Z1NtWFefh8/srx35P1o3M3ld3lL7cUmsjEV7ByIvqOQJ6j2
	2+UtSI9yNtA5F3r3OSfQFFaWz5NJOks/IUuv3zxhOfn+shzKJkuGkeTQFMTt5IIVdmCh
	IZ4g==
Received: by 10.14.172.193 with SMTP id t41mr20061628eel.25.1347286995893;
	Mon, 10 Sep 2012 07:23:15 -0700 (PDT)
Received: from [192.168.1.69] (host86-184-74-117.range86-184.btcentralplus.com.
	[86.184.74.117])
	by mx.google.com with ESMTPS id h42sm38595331eem.5.2012.09.10.07.23.12
	(version=SSLv3 cipher=OTHER); Mon, 10 Sep 2012 07:23:14 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Mon, 10 Sep 2012 15:23:07 +0100
From: Keir Fraser <keir.xen@gmail.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Message-ID: <CC73B65B.3E3D4%keir.xen@gmail.com>
Thread-Topic: [ANNOUNCE] Xen x86 32-bit hypervisor end of life after 4.2
Thread-Index: Ac2PX8vzRlT5W3lWekafNYjDAZqhGw==
In-Reply-To: <20557.63015.552841.739252@mariner.uk.xensource.com>
Mime-version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [ANNOUNCE] Xen x86 32-bit hypervisor end of life
	after 4.2
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 10/09/2012 15:16, "Ian Jackson" <Ian.Jackson@eu.citrix.com> wrote:

> Keir Fraser writes ("Re: [ANNOUNCE] Xen x86 32-bit hypervisor end of life
> after 4.2"):
>> Please can you remove x86_32 from the automated tests for xen-unstable?
> 
> I will do this but I have a number of other things which need to go
> through the autotester's tests of itself, first.  I'll let you know
> when it's done.

A self-aware autotester. :)

Well that's fine. It doesn't have to be done in a huge hurry.

 Thanks,
 Keir

> 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 Sep 10 14:23:34 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Sep 2012 14:23:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TB4tT-0001JV-5Z; Mon, 10 Sep 2012 14:23:19 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1TB4tR-0001JQ-Bv
	for xen-devel@lists.xen.org; Mon, 10 Sep 2012 14:23:17 +0000
Received: from [85.158.139.83:53042] by server-1.bemta-5.messagelabs.com id
	21/40-32692-4D7FD405; Mon, 10 Sep 2012 14:23:16 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1347286996!29915836!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-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3145 invoked from network); 10 Sep 2012 14:23:16 -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;
	10 Sep 2012 14:23:16 -0000
Received: by eaac13 with SMTP id c13so960084eaa.32
	for <xen-devel@lists.xen.org>; Mon, 10 Sep 2012 07:23:15 -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=3qVcvF3GZuxbMBcD1zWxtRo6gi9Zlig8OOUviHBupns=;
	b=hHLouCdKsBpupCW1GMoCFOlZbDk4PNHSksEnbUZ8wwGMoOq3xoyIodXkTtU8VFn+Vg
	HlCjnpoF0HY2tsQhOv0LLilkGwgW9J9QD5r6gDvQA6AIsNjo7w6sUHjbdav+BycsllPx
	atR/HyC5ROo3DP1Wd4ylAqSEsv/KeRvL29LpDI1gbl/VE2ohQqvFp8Z+K/JmqInqaQ1h
	sLiEgMjsELHqpdFX+pPO5Z1NtWFefh8/srx35P1o3M3ld3lL7cUmsjEV7ByIvqOQJ6j2
	2+UtSI9yNtA5F3r3OSfQFFaWz5NJOks/IUuv3zxhOfn+shzKJkuGkeTQFMTt5IIVdmCh
	IZ4g==
Received: by 10.14.172.193 with SMTP id t41mr20061628eel.25.1347286995893;
	Mon, 10 Sep 2012 07:23:15 -0700 (PDT)
Received: from [192.168.1.69] (host86-184-74-117.range86-184.btcentralplus.com.
	[86.184.74.117])
	by mx.google.com with ESMTPS id h42sm38595331eem.5.2012.09.10.07.23.12
	(version=SSLv3 cipher=OTHER); Mon, 10 Sep 2012 07:23:14 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Mon, 10 Sep 2012 15:23:07 +0100
From: Keir Fraser <keir.xen@gmail.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Message-ID: <CC73B65B.3E3D4%keir.xen@gmail.com>
Thread-Topic: [ANNOUNCE] Xen x86 32-bit hypervisor end of life after 4.2
Thread-Index: Ac2PX8vzRlT5W3lWekafNYjDAZqhGw==
In-Reply-To: <20557.63015.552841.739252@mariner.uk.xensource.com>
Mime-version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [ANNOUNCE] Xen x86 32-bit hypervisor end of life
	after 4.2
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 10/09/2012 15:16, "Ian Jackson" <Ian.Jackson@eu.citrix.com> wrote:

> Keir Fraser writes ("Re: [ANNOUNCE] Xen x86 32-bit hypervisor end of life
> after 4.2"):
>> Please can you remove x86_32 from the automated tests for xen-unstable?
> 
> I will do this but I have a number of other things which need to go
> through the autotester's tests of itself, first.  I'll let you know
> when it's done.

A self-aware autotester. :)

Well that's fine. It doesn't have to be done in a huge hurry.

 Thanks,
 Keir

> 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 Sep 10 14:26:34 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Sep 2012 14: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 1TB4wL-0001PW-Oy; Mon, 10 Sep 2012 14:26:17 +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 1TB4wK-0001PQ-Kp
	for xen-devel@lists.xensource.com; Mon, 10 Sep 2012 14:26:17 +0000
Received: from [85.158.143.35:34492] by server-3.bemta-4.messagelabs.com id
	76/4A-08232-888FD405; Mon, 10 Sep 2012 14:26:16 +0000
X-Env-Sender: fantonifabio@tiscali.it
X-Msg-Ref: server-6.tower-21.messagelabs.com!1347287171!17527575!1
X-Originating-IP: [94.23.245.208]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26083 invoked from network); 10 Sep 2012 14:26:11 -0000
Received: from lnx3.fantu.it (HELO lnx3.fantu.it) (94.23.245.208)
	by server-6.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 10 Sep 2012 14:26:11 -0000
Received: from localhost (localhost.localdomain [127.0.0.1])
	by lnx3.fantu.it (Postfix) with ESMTP id 2462A4022C3;
	Mon, 10 Sep 2012 16:26:11 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at lnx3.fantu.it
Received: from lnx3.fantu.it ([127.0.0.1])
	by localhost (lnx3.fantu.it [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id fXHVESR3wxH7; Mon, 10 Sep 2012 16:26:10 +0200 (CEST)
Received: from [192.168.178.50]
	(host159-164-dynamic.56-82-r.retail.telecomitalia.it [82.56.164.159])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: prova@fantu.it)
	by lnx3.fantu.it (Postfix) with ESMTPSA id EB8A4402277;
	Mon, 10 Sep 2012 16:26:09 +0200 (CEST)
Message-ID: <504DF87E.6020901@tiscali.it>
Date: Mon, 10 Sep 2012 16:26:06 +0200
From: Fabio Fantoni <fantonifabio@tiscali.it>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:14.0) Gecko/20120713 Thunderbird/14.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <5049EC11.9080302@tiscali.it>
	<1347030955.30018.115.camel@zakaz.uk.xensource.com>
	<504DB165.6040500@tiscali.it>
	<1347269362.5305.39.camel@zakaz.uk.xensource.com>
	<504DECE7.1050404@tiscali.it>
	<1347284515.5305.85.camel@zakaz.uk.xensource.com>
In-Reply-To: <1347284515.5305.85.camel@zakaz.uk.xensource.com>
Cc: xen-devel <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Test report of xen 4.2.0-rc4
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="===============4824447651000339591=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Questo è un messaggio firmato digitalmente in formato MIME.

--===============4824447651000339591==
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms070501090901090902070405"

Questo è un messaggio firmato digitalmente in formato MIME.

--------------ms070501090901090902070405
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable

Il 10/09/2012 15:41, Ian Campbell ha scritto:
> On Mon, 2012-09-10 at 14:36 +0100, Fabio Fantoni wrote:
>> gdb --args xl -vvv cd-eject W7 hdb
>> GNU gdb (GDB) 7.4.1-debian
>> Copyright (C) 2012 Free Software Foundation, Inc.
>> License GPLv3+: GNU GPL version 3 or later
>> <http://gnu.org/licenses/gpl.html>
>> This is free software: you are free to change and redistribute it.
>> There is NO WARRANTY, to the extent permitted by law.  Type "show copy=
ing"
>> and "show warranty" for details.
>> This GDB was configured as "x86_64-linux-gnu".
>> For bug reporting instructions, please see:
>> <http://www.gnu.org/software/gdb/bugs/>...
>> Reading symbols from /usr/sbin/xl...done.
> Oops, sorry I forget to say:
>
> Enter "run" at this point to actually run the command.
>
>> (gdb) bt
>> No stack.
>>
>
>
>
> -----
> Nessun virus nel messaggio.
> Controllato da AVG - www.avg.com
> Versione: 2012.0.2197 / Database dei virus: 2437/5259 -  Data di rilasc=
io: 09/09/2012
>
>
gdb --args xl -vvv cd-eject W7 hdb
GNU gdb (GDB) 7.4.1-debian
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later=20
<http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying=
"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /usr/sbin/xl...done.
(gdb) run
Starting program: /usr/sbin/xl -vvv cd-eject W7 hdb
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1"=
=2E
libxl: debug: libxl.c:2143:libxl_cdrom_insert: ao 0x623980: create:=20
how=3D(nil) callback=3D(nil) poller=3D0x6239e0
libxl: debug: libxl_device.c:229:libxl__device_disk_set_backend: Disk=20
vdev=3Dhdb spec.backend=3Dunknown
libxl: debug: libxl_device.c:175:disk_try_backend: Disk vdev=3Dhdb,=20
backend phy unsuitable as phys path not a block device
libxl: debug: libxl_device.c:210:disk_try_backend: Disk vdev=3Dhdb,=20
backend tap unsuitable due to format empty
libxl: debug: libxl_device.c:265:libxl__device_disk_set_backend: Disk=20
vdev=3Dhdb, using backend qdisk
libxl: debug: libxl_event.c:1497:libxl__ao_complete: ao 0x623980:=20
complete, rc=3D0
libxl: debug: libxl.c:2236:libxl_cdrom_insert: ao 0x623980: inprogress:=20
poller=3D0x6239e0, flags=3Dic
libxl: debug: libxl_event.c:1469:libxl__ao__destroy: ao 0x623980: destroy=

xc: debug: hypercall buffer: total allocations:4 total releases:4
xc: debug: hypercall buffer: current allocations:0 maximum allocations:2
xc: debug: hypercall buffer: cache current size:2
xc: debug: hypercall buffer: cache hits:1 misses:2 toobig:1
[Inferior 1 (process 5581) exited normally]
(gdb) bt
No stack.

I also tried Precise hvm domU, on restore give update-manager crash,=20
tried firefox and work, on restore with Precise PV domU network not work =

but after yes, tried ping, first failed other ok.
Seem that also Linux domU have network not working on restore but=20
resolved itself after some seconds.

I also tried cd-eject on Precise hvm domU, same result:
gdb --args xl -vvv cd-eject PRECISEHVM hdb
GNU gdb (GDB) 7.4.1-debian
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later=20
<http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying=
"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /usr/sbin/xl...done.
(gdb) run
Starting program: /usr/sbin/xl -vvv cd-eject PRECISEHVM hdb
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1"=
=2E
libxl: debug: libxl.c:2143:libxl_cdrom_insert: ao 0x623980: create:=20
how=3D(nil) callback=3D(nil) poller=3D0x6239e0
libxl: debug: libxl_device.c:229:libxl__device_disk_set_backend: Disk=20
vdev=3Dhdb spec.backend=3Dunknown
libxl: debug: libxl_device.c:175:disk_try_backend: Disk vdev=3Dhdb,=20
backend phy unsuitable as phys path not a block device
libxl: debug: libxl_device.c:210:disk_try_backend: Disk vdev=3Dhdb,=20
backend tap unsuitable due to format empty
libxl: debug: libxl_device.c:265:libxl__device_disk_set_backend: Disk=20
vdev=3Dhdb, using backend qdisk
libxl: debug: libxl_event.c:1497:libxl__ao_complete: ao 0x623980:=20
complete, rc=3D0
libxl: debug: libxl.c:2236:libxl_cdrom_insert: ao 0x623980: inprogress:=20
poller=3D0x6239e0, flags=3Dic
libxl: debug: libxl_event.c:1469:libxl__ao__destroy: ao 0x623980: destroy=

xc: debug: hypercall buffer: total allocations:4 total releases:4
xc: debug: hypercall buffer: current allocations:0 maximum allocations:2
xc: debug: hypercall buffer: cache current size:2
xc: debug: hypercall buffer: cache hits:1 misses:2 toobig:1
[Inferior 1 (process 6522) exited normally]
(gdb) bt
No stack.

----------------------------------------------
PRECISEHVM.cfg
-----------------------
name=3D'PRECISEHVM'
builder=3D"hvm"
memory=3D1024
vcpus=3D2
hap=3D1
pae=3D1
acpi=3D1
apic=3D1
nx=3D1
vif=3D['bridge=3Dxenbr0']
#vfb=3D['vnc=3D1,vncunused=3D1,vnclisten=3D"0.0.0.0",keymap=3D"it"']
#disk=3D['/mnt/vm/disks/PRECISEHVM.disk1.xm,raw,hda,rw',=20
'/dev/sr0,raw,hdb,ro,cdrom']
disk=3D['/mnt/vm/disks/PRECISEHVM.disk1.xm,raw,hda,rw','/mnt/vm/iso/XPSP3=
PRO.iso,raw,hdb,ro,cdrom']
boot=3D'c'
xen_platform_pci=3D1
device_model_version=3D'qemu-xen-traditional'
vnc=3D1
vncunused=3D1
vnclisten=3D"0.0.0.0"
keymap=3D"it"
stdvga=3D0
#videoram=3D16
----------------------------------------------


--------------ms070501090901090902070405
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: Firma crittografica S/MIME

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINhjCC
BjQwggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT
DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp
Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3
MTAyNDIxMDI1NVoXDTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T
dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu
aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs
aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOM
KqANy9BV7V0igWdGxA8IU77L3aTxErQ+fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi
8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke/s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8M
DP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHksw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y
2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHHtOkzUreG//CsFnB9+uaYSlR65cdG
zTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB
Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd+q9rMfPIHeOsuzAfBgNV
HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH
MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3
dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu
c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v
c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0
dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93
d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqp
Jw3I07QWke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Mic
c/NXcs7kPBRdn6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9Jphw
UPTXwHovjavRnhUQHLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMc
p+reg9901zkyT3fDW/ivJVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT
+HBDYtbuvexNftwNQKD5193A7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1X
hwby6mLhkbaXslkVtwEWT3Van49rKjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvO
hNz/QplNa+VkIsrcp7+8ZhP1l1b2U6MaxIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC
0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqh
AChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H75dVCV33K6FuxZrf09yTz+Vx/PkdRUYk
XmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHSjCCBjKgAwIBAgICHmMwDQYJKoZIhvcNAQEF
BQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJT
ZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD
bGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0xMjAzMTgyMjE0MzBa
Fw0xNDAzMjAwODU3MDlaMIGMMRkwFwYDVQQNExBlQjZPRTM3UlJOUHlsNW0yMQswCQYDVQQG
EwJJVDEQMA4GA1UECBMHQmVyZ2FtbzEQMA4GA1UEBxMHUm92ZXR0YTEWMBQGA1UEAxMNRmFi
aW8gRmFudG9uaTEmMCQGCSqGSIb3DQEJARYXZmFudG9uaWZhYmlvQHRpc2NhbGkuaXQwggEi
MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC1XhckXsX23vgJq76s2f0KT8U8Msov5QgV
10eQBb2wL/TzcmqtZotI7ztKVhio3ehHg+mfu+3EqOkX9Umgut8rP0bPi7AGjkPXbOTT/cSU
Xz2Kw31VGOmiOVoUFGvpQitp3weCkhUJLBipI8EpNyBXpjtQ9yCpnIAqfuc77ybfSnCy7tTR
MBq1BUkfjH1+GL45riosuS4+F+MSUvlYzLiT4rAduAX1Y2IuORDsf9Bce8GBxa6syP9rCyzl
Vk7DIX5k8j2vlnyRATIypn5CQLQxGT6e0f6ac4gvWOHwO2QEBsmZKKs1ZidE4q/9OoNXYX6A
jnHtp1H1vcrek/vVcs19AgMBAAGjggOyMIIDrjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAd
BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFFan8cbEWWBmSTWFtLk2
YNdAcGUbMB8GA1UdIwQYMBaAFK5Vg2/sMcq59x36r2sx88gd46y7MCIGA1UdEQQbMBmBF2Zh
bnRvbmlmYWJpb0B0aXNjYWxpLml0MIICIQYDVR0gBIICGDCCAhQwggIQBgsrBgEEAYG1NwEC
AjCCAf8wLgYIKwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYw
NAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYw
gfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMC
AQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNjb3JkaW5nIHRvIHRoZSBDbGFz
cyAyIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3ks
IHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGluIGNvbXBsaWFuY2Ug
b2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMIGcBggrBgEFBQcCAjCBjzAnFiBT
dGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgECGmRMaWFiaWxpdHkgYW5kIHdh
cnJhbnRpZXMgYXJlIGxpbWl0ZWQhIFNlZSBzZWN0aW9uICJMZWdhbCBhbmQgTGltaXRhdGlv
bnMiIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3kuMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6
Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUyLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYI
KwYBBQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MyL2NsaWVudC9j
YTBCBggrBgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNz
Mi5jbGllbnQuY2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzAN
BgkqhkiG9w0BAQUFAAOCAQEAjzHNqifpDVMkH1TSPFZVIiQ4fh49/V5JMpstgqEZPDaDe5r8
h+fMBZtUa6LLMco03Z9BNEXlqlXKiFk8feVYB8obEjz7YYq1XhO9q7JUmkSs0WGIH4xU0XB1
kPC8T8H+5E//84poYSFHE4pA+Ff68UANP2/EuFJWMjegiefnOr8aM42OAcUkjEWSlautIIX8
oD2GizwQYjWdDDjEonbuMKFP6rY2xGI3PSLI3IVU2opb0/itNhQui3WRxafloJqTlriY8m8+
qSLr2HGftbBlbyzVWB8o//aW0H0LMabjkIvrm7Zmh2vcCxiSxGBwYASuSYXGuQiKAgGptUs1
XJLZuzGCA9owggPWAgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20g
THRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG
A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EC
Ah5jMAkGBSsOAwIaBQCgggIbMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcN
AQkFMQ8XDTEyMDkxMDE0MjYwNlowIwYJKoZIhvcNAQkEMRYEFAz4cir5fLqhS362RLD7JEv0
hBz4MGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggqhkiG
9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcN
AwICASgwgaQGCSsGAQQBgjcQBDGBljCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0
YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25p
bmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp
ZW50IENBAgIeYzCBpgYLKoZIhvcNAQkQAgsxgZaggZMwgYwxCzAJBgNVBAYTAklMMRYwFAYD
VQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0
ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRp
YXRlIENsaWVudCBDQQICHmMwDQYJKoZIhvcNAQEBBQAEggEAOHPhM71g9WFylLRMSrbfRbV3
/z0UdU7jU0JeJ+4MftZrOY8MJO+yC7M/LFhX0g6o+UVo5Kwt0tDns+tXG9VlSi8oO3FvQ/51
FQOWi+CGjqtTJtCMAK65gsXA6FwbOZyak9mvIqZhOWCglq8k5ONFG5z5WyBdu8SlWBeEzvJA
ASRUfi6QYYiezvZpubOGm56JXrZ8XKfHSnu7CkCXZYanAG/ZW5EHJAKoFbBt1hXjH5/DUAKU
oAqg9ECeqVqUZspXyH9q/G7W2s5WV7ZNFnQP6nOGlzasl5YIVogGlYL1JO4IXk666YqQDRqe
4Hek9CMgr1EOGPvJCL75aoVP6Qf3vAAAAAAAAA==
--------------ms070501090901090902070405--


--===============4824447651000339591==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============4824447651000339591==--


From xen-devel-bounces@lists.xen.org Mon Sep 10 14:26:34 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Sep 2012 14: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 1TB4wL-0001PW-Oy; Mon, 10 Sep 2012 14:26:17 +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 1TB4wK-0001PQ-Kp
	for xen-devel@lists.xensource.com; Mon, 10 Sep 2012 14:26:17 +0000
Received: from [85.158.143.35:34492] by server-3.bemta-4.messagelabs.com id
	76/4A-08232-888FD405; Mon, 10 Sep 2012 14:26:16 +0000
X-Env-Sender: fantonifabio@tiscali.it
X-Msg-Ref: server-6.tower-21.messagelabs.com!1347287171!17527575!1
X-Originating-IP: [94.23.245.208]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26083 invoked from network); 10 Sep 2012 14:26:11 -0000
Received: from lnx3.fantu.it (HELO lnx3.fantu.it) (94.23.245.208)
	by server-6.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 10 Sep 2012 14:26:11 -0000
Received: from localhost (localhost.localdomain [127.0.0.1])
	by lnx3.fantu.it (Postfix) with ESMTP id 2462A4022C3;
	Mon, 10 Sep 2012 16:26:11 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at lnx3.fantu.it
Received: from lnx3.fantu.it ([127.0.0.1])
	by localhost (lnx3.fantu.it [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id fXHVESR3wxH7; Mon, 10 Sep 2012 16:26:10 +0200 (CEST)
Received: from [192.168.178.50]
	(host159-164-dynamic.56-82-r.retail.telecomitalia.it [82.56.164.159])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: prova@fantu.it)
	by lnx3.fantu.it (Postfix) with ESMTPSA id EB8A4402277;
	Mon, 10 Sep 2012 16:26:09 +0200 (CEST)
Message-ID: <504DF87E.6020901@tiscali.it>
Date: Mon, 10 Sep 2012 16:26:06 +0200
From: Fabio Fantoni <fantonifabio@tiscali.it>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:14.0) Gecko/20120713 Thunderbird/14.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <5049EC11.9080302@tiscali.it>
	<1347030955.30018.115.camel@zakaz.uk.xensource.com>
	<504DB165.6040500@tiscali.it>
	<1347269362.5305.39.camel@zakaz.uk.xensource.com>
	<504DECE7.1050404@tiscali.it>
	<1347284515.5305.85.camel@zakaz.uk.xensource.com>
In-Reply-To: <1347284515.5305.85.camel@zakaz.uk.xensource.com>
Cc: xen-devel <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Test report of xen 4.2.0-rc4
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="===============4824447651000339591=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Questo è un messaggio firmato digitalmente in formato MIME.

--===============4824447651000339591==
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms070501090901090902070405"

Questo è un messaggio firmato digitalmente in formato MIME.

--------------ms070501090901090902070405
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable

Il 10/09/2012 15:41, Ian Campbell ha scritto:
> On Mon, 2012-09-10 at 14:36 +0100, Fabio Fantoni wrote:
>> gdb --args xl -vvv cd-eject W7 hdb
>> GNU gdb (GDB) 7.4.1-debian
>> Copyright (C) 2012 Free Software Foundation, Inc.
>> License GPLv3+: GNU GPL version 3 or later
>> <http://gnu.org/licenses/gpl.html>
>> This is free software: you are free to change and redistribute it.
>> There is NO WARRANTY, to the extent permitted by law.  Type "show copy=
ing"
>> and "show warranty" for details.
>> This GDB was configured as "x86_64-linux-gnu".
>> For bug reporting instructions, please see:
>> <http://www.gnu.org/software/gdb/bugs/>...
>> Reading symbols from /usr/sbin/xl...done.
> Oops, sorry I forget to say:
>
> Enter "run" at this point to actually run the command.
>
>> (gdb) bt
>> No stack.
>>
>
>
>
> -----
> Nessun virus nel messaggio.
> Controllato da AVG - www.avg.com
> Versione: 2012.0.2197 / Database dei virus: 2437/5259 -  Data di rilasc=
io: 09/09/2012
>
>
gdb --args xl -vvv cd-eject W7 hdb
GNU gdb (GDB) 7.4.1-debian
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later=20
<http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying=
"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /usr/sbin/xl...done.
(gdb) run
Starting program: /usr/sbin/xl -vvv cd-eject W7 hdb
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1"=
=2E
libxl: debug: libxl.c:2143:libxl_cdrom_insert: ao 0x623980: create:=20
how=3D(nil) callback=3D(nil) poller=3D0x6239e0
libxl: debug: libxl_device.c:229:libxl__device_disk_set_backend: Disk=20
vdev=3Dhdb spec.backend=3Dunknown
libxl: debug: libxl_device.c:175:disk_try_backend: Disk vdev=3Dhdb,=20
backend phy unsuitable as phys path not a block device
libxl: debug: libxl_device.c:210:disk_try_backend: Disk vdev=3Dhdb,=20
backend tap unsuitable due to format empty
libxl: debug: libxl_device.c:265:libxl__device_disk_set_backend: Disk=20
vdev=3Dhdb, using backend qdisk
libxl: debug: libxl_event.c:1497:libxl__ao_complete: ao 0x623980:=20
complete, rc=3D0
libxl: debug: libxl.c:2236:libxl_cdrom_insert: ao 0x623980: inprogress:=20
poller=3D0x6239e0, flags=3Dic
libxl: debug: libxl_event.c:1469:libxl__ao__destroy: ao 0x623980: destroy=

xc: debug: hypercall buffer: total allocations:4 total releases:4
xc: debug: hypercall buffer: current allocations:0 maximum allocations:2
xc: debug: hypercall buffer: cache current size:2
xc: debug: hypercall buffer: cache hits:1 misses:2 toobig:1
[Inferior 1 (process 5581) exited normally]
(gdb) bt
No stack.

I also tried Precise hvm domU, on restore give update-manager crash,=20
tried firefox and work, on restore with Precise PV domU network not work =

but after yes, tried ping, first failed other ok.
Seem that also Linux domU have network not working on restore but=20
resolved itself after some seconds.

I also tried cd-eject on Precise hvm domU, same result:
gdb --args xl -vvv cd-eject PRECISEHVM hdb
GNU gdb (GDB) 7.4.1-debian
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later=20
<http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying=
"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /usr/sbin/xl...done.
(gdb) run
Starting program: /usr/sbin/xl -vvv cd-eject PRECISEHVM hdb
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1"=
=2E
libxl: debug: libxl.c:2143:libxl_cdrom_insert: ao 0x623980: create:=20
how=3D(nil) callback=3D(nil) poller=3D0x6239e0
libxl: debug: libxl_device.c:229:libxl__device_disk_set_backend: Disk=20
vdev=3Dhdb spec.backend=3Dunknown
libxl: debug: libxl_device.c:175:disk_try_backend: Disk vdev=3Dhdb,=20
backend phy unsuitable as phys path not a block device
libxl: debug: libxl_device.c:210:disk_try_backend: Disk vdev=3Dhdb,=20
backend tap unsuitable due to format empty
libxl: debug: libxl_device.c:265:libxl__device_disk_set_backend: Disk=20
vdev=3Dhdb, using backend qdisk
libxl: debug: libxl_event.c:1497:libxl__ao_complete: ao 0x623980:=20
complete, rc=3D0
libxl: debug: libxl.c:2236:libxl_cdrom_insert: ao 0x623980: inprogress:=20
poller=3D0x6239e0, flags=3Dic
libxl: debug: libxl_event.c:1469:libxl__ao__destroy: ao 0x623980: destroy=

xc: debug: hypercall buffer: total allocations:4 total releases:4
xc: debug: hypercall buffer: current allocations:0 maximum allocations:2
xc: debug: hypercall buffer: cache current size:2
xc: debug: hypercall buffer: cache hits:1 misses:2 toobig:1
[Inferior 1 (process 6522) exited normally]
(gdb) bt
No stack.

----------------------------------------------
PRECISEHVM.cfg
-----------------------
name=3D'PRECISEHVM'
builder=3D"hvm"
memory=3D1024
vcpus=3D2
hap=3D1
pae=3D1
acpi=3D1
apic=3D1
nx=3D1
vif=3D['bridge=3Dxenbr0']
#vfb=3D['vnc=3D1,vncunused=3D1,vnclisten=3D"0.0.0.0",keymap=3D"it"']
#disk=3D['/mnt/vm/disks/PRECISEHVM.disk1.xm,raw,hda,rw',=20
'/dev/sr0,raw,hdb,ro,cdrom']
disk=3D['/mnt/vm/disks/PRECISEHVM.disk1.xm,raw,hda,rw','/mnt/vm/iso/XPSP3=
PRO.iso,raw,hdb,ro,cdrom']
boot=3D'c'
xen_platform_pci=3D1
device_model_version=3D'qemu-xen-traditional'
vnc=3D1
vncunused=3D1
vnclisten=3D"0.0.0.0"
keymap=3D"it"
stdvga=3D0
#videoram=3D16
----------------------------------------------


--------------ms070501090901090902070405
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: Firma crittografica S/MIME

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINhjCC
BjQwggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT
DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp
Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3
MTAyNDIxMDI1NVoXDTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T
dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu
aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs
aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOM
KqANy9BV7V0igWdGxA8IU77L3aTxErQ+fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi
8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke/s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8M
DP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHksw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y
2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHHtOkzUreG//CsFnB9+uaYSlR65cdG
zTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB
Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd+q9rMfPIHeOsuzAfBgNV
HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH
MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3
dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu
c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v
c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0
dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93
d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqp
Jw3I07QWke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Mic
c/NXcs7kPBRdn6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9Jphw
UPTXwHovjavRnhUQHLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMc
p+reg9901zkyT3fDW/ivJVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT
+HBDYtbuvexNftwNQKD5193A7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1X
hwby6mLhkbaXslkVtwEWT3Van49rKjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvO
hNz/QplNa+VkIsrcp7+8ZhP1l1b2U6MaxIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC
0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqh
AChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H75dVCV33K6FuxZrf09yTz+Vx/PkdRUYk
XmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHSjCCBjKgAwIBAgICHmMwDQYJKoZIhvcNAQEF
BQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJT
ZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD
bGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0xMjAzMTgyMjE0MzBa
Fw0xNDAzMjAwODU3MDlaMIGMMRkwFwYDVQQNExBlQjZPRTM3UlJOUHlsNW0yMQswCQYDVQQG
EwJJVDEQMA4GA1UECBMHQmVyZ2FtbzEQMA4GA1UEBxMHUm92ZXR0YTEWMBQGA1UEAxMNRmFi
aW8gRmFudG9uaTEmMCQGCSqGSIb3DQEJARYXZmFudG9uaWZhYmlvQHRpc2NhbGkuaXQwggEi
MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC1XhckXsX23vgJq76s2f0KT8U8Msov5QgV
10eQBb2wL/TzcmqtZotI7ztKVhio3ehHg+mfu+3EqOkX9Umgut8rP0bPi7AGjkPXbOTT/cSU
Xz2Kw31VGOmiOVoUFGvpQitp3weCkhUJLBipI8EpNyBXpjtQ9yCpnIAqfuc77ybfSnCy7tTR
MBq1BUkfjH1+GL45riosuS4+F+MSUvlYzLiT4rAduAX1Y2IuORDsf9Bce8GBxa6syP9rCyzl
Vk7DIX5k8j2vlnyRATIypn5CQLQxGT6e0f6ac4gvWOHwO2QEBsmZKKs1ZidE4q/9OoNXYX6A
jnHtp1H1vcrek/vVcs19AgMBAAGjggOyMIIDrjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAd
BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFFan8cbEWWBmSTWFtLk2
YNdAcGUbMB8GA1UdIwQYMBaAFK5Vg2/sMcq59x36r2sx88gd46y7MCIGA1UdEQQbMBmBF2Zh
bnRvbmlmYWJpb0B0aXNjYWxpLml0MIICIQYDVR0gBIICGDCCAhQwggIQBgsrBgEEAYG1NwEC
AjCCAf8wLgYIKwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYw
NAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYw
gfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMC
AQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNjb3JkaW5nIHRvIHRoZSBDbGFz
cyAyIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3ks
IHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGluIGNvbXBsaWFuY2Ug
b2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMIGcBggrBgEFBQcCAjCBjzAnFiBT
dGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgECGmRMaWFiaWxpdHkgYW5kIHdh
cnJhbnRpZXMgYXJlIGxpbWl0ZWQhIFNlZSBzZWN0aW9uICJMZWdhbCBhbmQgTGltaXRhdGlv
bnMiIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3kuMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6
Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUyLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYI
KwYBBQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MyL2NsaWVudC9j
YTBCBggrBgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNz
Mi5jbGllbnQuY2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzAN
BgkqhkiG9w0BAQUFAAOCAQEAjzHNqifpDVMkH1TSPFZVIiQ4fh49/V5JMpstgqEZPDaDe5r8
h+fMBZtUa6LLMco03Z9BNEXlqlXKiFk8feVYB8obEjz7YYq1XhO9q7JUmkSs0WGIH4xU0XB1
kPC8T8H+5E//84poYSFHE4pA+Ff68UANP2/EuFJWMjegiefnOr8aM42OAcUkjEWSlautIIX8
oD2GizwQYjWdDDjEonbuMKFP6rY2xGI3PSLI3IVU2opb0/itNhQui3WRxafloJqTlriY8m8+
qSLr2HGftbBlbyzVWB8o//aW0H0LMabjkIvrm7Zmh2vcCxiSxGBwYASuSYXGuQiKAgGptUs1
XJLZuzGCA9owggPWAgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20g
THRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG
A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EC
Ah5jMAkGBSsOAwIaBQCgggIbMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcN
AQkFMQ8XDTEyMDkxMDE0MjYwNlowIwYJKoZIhvcNAQkEMRYEFAz4cir5fLqhS362RLD7JEv0
hBz4MGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggqhkiG
9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcN
AwICASgwgaQGCSsGAQQBgjcQBDGBljCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0
YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25p
bmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp
ZW50IENBAgIeYzCBpgYLKoZIhvcNAQkQAgsxgZaggZMwgYwxCzAJBgNVBAYTAklMMRYwFAYD
VQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0
ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRp
YXRlIENsaWVudCBDQQICHmMwDQYJKoZIhvcNAQEBBQAEggEAOHPhM71g9WFylLRMSrbfRbV3
/z0UdU7jU0JeJ+4MftZrOY8MJO+yC7M/LFhX0g6o+UVo5Kwt0tDns+tXG9VlSi8oO3FvQ/51
FQOWi+CGjqtTJtCMAK65gsXA6FwbOZyak9mvIqZhOWCglq8k5ONFG5z5WyBdu8SlWBeEzvJA
ASRUfi6QYYiezvZpubOGm56JXrZ8XKfHSnu7CkCXZYanAG/ZW5EHJAKoFbBt1hXjH5/DUAKU
oAqg9ECeqVqUZspXyH9q/G7W2s5WV7ZNFnQP6nOGlzasl5YIVogGlYL1JO4IXk666YqQDRqe
4Hek9CMgr1EOGPvJCL75aoVP6Qf3vAAAAAAAAA==
--------------ms070501090901090902070405--


--===============4824447651000339591==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============4824447651000339591==--


From xen-devel-bounces@lists.xen.org Mon Sep 10 14:27:11 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Sep 2012 14: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 1TB4wy-0001T2-Bx; Mon, 10 Sep 2012 14:26:56 +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 1TB4ww-0001SK-Si
	for xen-devel@lists.xen.org; Mon, 10 Sep 2012 14:26:55 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1347287180!9296991!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTIyODk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14522 invoked from network); 10 Sep 2012 14:26: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;
	10 Sep 2012 14:26:24 -0000
X-IronPort-AV: E=Sophos;i="4.80,398,1344211200"; d="scan'208";a="14446159"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Sep 2012 14: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.279.1;
	Mon, 10 Sep 2012 15:26:17 +0100
Message-ID: <1347287175.5305.89.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Andres Lagar-Cavilla <andreslc@gridcentric.ca>
Date: Mon, 10 Sep 2012 15:26:15 +0100
In-Reply-To: <08A8CD72-BB08-4178-945D-90C588A78F14@gridcentric.ca>
References: <08A8CD72-BB08-4178-945D-90C588A78F14@gridcentric.ca>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Olaf Hering <olaf@aepfle.de>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"Tim \(Xen.org\)" <tim@xen.org>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen paging unit test
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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-09-10 at 15:08 +0100, Andres Lagar-Cavilla wrote:
> Hi,
> In the process of submitting the privcmd MMAP_BATCH_V2 patches for Linux 3.7, Konrad asked a very valid question:
> 
> "How do you test this thing?"
> 
> Turns out that you have two ways
> 1. You do the actual paging thing on a live domain
> 2. I had a unit test buried in my stash
> 
> Coincidentally, Ian C asked for demonstrable consumers of the
> xenpaging interface in the process of summarizing the 4.2 change log.
> 
> I've github'ed my paging unit test in the hopes it will be found
> useful, not only as a unit test, but also a demo/reference piece of
> code. 
> 
> The unit test exercises the privcmd/libxc interface for creating
> foreign mappings of paged out pages. As a precondition, it must create
> a domain, enable paging on it, and act as a pager to satisfy the
> page-in requests generated by the foreign maps.
> 
> https://github.com/andreslagarcavilla/xenpagingtest

I get a server error (cat holding a 500? so error code 500? nice way to
obfuscate the useful info!) from this.

I stripped off a level and tried https://github.com/andreslagarcavilla
but that gets me an angry unicorn saying "Page did not respond in a
timely fashion.".

:-)

Is this similar to/derived from tools/xenpaging?

> 
> This might be considered useful for tools/tests in xen-unstable, and I'll be happy to resubmit in a suitable form if you ask.
> 
> Cheers
> Andres



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 10 14:27:11 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Sep 2012 14: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 1TB4wy-0001T2-Bx; Mon, 10 Sep 2012 14:26:56 +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 1TB4ww-0001SK-Si
	for xen-devel@lists.xen.org; Mon, 10 Sep 2012 14:26:55 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1347287180!9296991!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTIyODk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14522 invoked from network); 10 Sep 2012 14:26: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;
	10 Sep 2012 14:26:24 -0000
X-IronPort-AV: E=Sophos;i="4.80,398,1344211200"; d="scan'208";a="14446159"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Sep 2012 14: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.279.1;
	Mon, 10 Sep 2012 15:26:17 +0100
Message-ID: <1347287175.5305.89.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Andres Lagar-Cavilla <andreslc@gridcentric.ca>
Date: Mon, 10 Sep 2012 15:26:15 +0100
In-Reply-To: <08A8CD72-BB08-4178-945D-90C588A78F14@gridcentric.ca>
References: <08A8CD72-BB08-4178-945D-90C588A78F14@gridcentric.ca>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Olaf Hering <olaf@aepfle.de>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"Tim \(Xen.org\)" <tim@xen.org>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen paging unit test
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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-09-10 at 15:08 +0100, Andres Lagar-Cavilla wrote:
> Hi,
> In the process of submitting the privcmd MMAP_BATCH_V2 patches for Linux 3.7, Konrad asked a very valid question:
> 
> "How do you test this thing?"
> 
> Turns out that you have two ways
> 1. You do the actual paging thing on a live domain
> 2. I had a unit test buried in my stash
> 
> Coincidentally, Ian C asked for demonstrable consumers of the
> xenpaging interface in the process of summarizing the 4.2 change log.
> 
> I've github'ed my paging unit test in the hopes it will be found
> useful, not only as a unit test, but also a demo/reference piece of
> code. 
> 
> The unit test exercises the privcmd/libxc interface for creating
> foreign mappings of paged out pages. As a precondition, it must create
> a domain, enable paging on it, and act as a pager to satisfy the
> page-in requests generated by the foreign maps.
> 
> https://github.com/andreslagarcavilla/xenpagingtest

I get a server error (cat holding a 500? so error code 500? nice way to
obfuscate the useful info!) from this.

I stripped off a level and tried https://github.com/andreslagarcavilla
but that gets me an angry unicorn saying "Page did not respond in a
timely fashion.".

:-)

Is this similar to/derived from tools/xenpaging?

> 
> This might be considered useful for tools/tests in xen-unstable, and I'll be happy to resubmit in a suitable form if you ask.
> 
> Cheers
> Andres



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 10 14:28:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Sep 2012 14: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 1TB4y1-0001b2-Ql; Mon, 10 Sep 2012 14:28: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 1TB4y0-0001an-Q5
	for xen-devel@lists.xensource.com; Mon, 10 Sep 2012 14:28:01 +0000
Received: from [85.158.138.51:41715] by server-11.bemta-3.messagelabs.com id
	F9/85-30250-FE8FD405; Mon, 10 Sep 2012 14:27:59 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1347287279!29674855!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTIyODk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7648 invoked from network); 10 Sep 2012 14:27: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;
	10 Sep 2012 14:27:59 -0000
X-IronPort-AV: E=Sophos;i="4.80,398,1344211200"; d="scan'208";a="14446203"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Sep 2012 14:27: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.279.1;
	Mon, 10 Sep 2012 15:27:59 +0100
Message-ID: <1347287277.5305.90.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "fantonifabio@tiscali.it" <fantonifabio@tiscali.it>
Date: Mon, 10 Sep 2012 15:27:57 +0100
In-Reply-To: <504DF87E.6020901@tiscali.it>
References: <5049EC11.9080302@tiscali.it>
	<1347030955.30018.115.camel@zakaz.uk.xensource.com>
	<504DB165.6040500@tiscali.it>
	<1347269362.5305.39.camel@zakaz.uk.xensource.com>
	<504DECE7.1050404@tiscali.it>
	<1347284515.5305.85.camel@zakaz.uk.xensource.com>
	<504DF87E.6020901@tiscali.it>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Test report of xen 4.2.0-rc4
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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-09-10 at 15:26 +0100, Fabio Fantoni wrote:
> gdb --args xl -vvv cd-eject W7 hdb
> GNU gdb (GDB) 7.4.1-debian
> Copyright (C) 2012 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later 
> <http://gnu.org/licenses/gpl.html>
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
> and "show warranty" for details.
> This GDB was configured as "x86_64-linux-gnu".
> For bug reporting instructions, please see:
> <http://www.gnu.org/software/gdb/bugs/>...
> Reading symbols from /usr/sbin/xl...done.
> (gdb) run
> Starting program: /usr/sbin/xl -vvv cd-eject W7 hdb
> [Thread debugging using libthread_db enabled]
> Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
> libxl: debug: libxl.c:2143:libxl_cdrom_insert: ao 0x623980: create: 
> how=(nil) callback=(nil) poller=0x6239e0
> libxl: debug: libxl_device.c:229:libxl__device_disk_set_backend: Disk 
> vdev=hdb spec.backend=unknown
> libxl: debug: libxl_device.c:175:disk_try_backend: Disk vdev=hdb, 
> backend phy unsuitable as phys path not a block device
> libxl: debug: libxl_device.c:210:disk_try_backend: Disk vdev=hdb, 
> backend tap unsuitable due to format empty
> libxl: debug: libxl_device.c:265:libxl__device_disk_set_backend: Disk 
> vdev=hdb, using backend qdisk
> libxl: debug: libxl_event.c:1497:libxl__ao_complete: ao 0x623980: 
> complete, rc=0
> libxl: debug: libxl.c:2236:libxl_cdrom_insert: ao 0x623980: inprogress: 
> poller=0x6239e0, flags=ic
> libxl: debug: libxl_event.c:1469:libxl__ao__destroy: ao 0x623980: destroy
> xc: debug: hypercall buffer: total allocations:4 total releases:4
> xc: debug: hypercall buffer: current allocations:0 maximum allocations:2
> xc: debug: hypercall buffer: cache current size:2
> xc: debug: hypercall buffer: cache hits:1 misses:2 toobig:1
> [Inferior 1 (process 5581) exited normally]
> (gdb) bt
> No stack.

That's because it seems to be working for you now... There is no crash
here.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 10 14:28:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Sep 2012 14: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 1TB4y1-0001b2-Ql; Mon, 10 Sep 2012 14:28: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 1TB4y0-0001an-Q5
	for xen-devel@lists.xensource.com; Mon, 10 Sep 2012 14:28:01 +0000
Received: from [85.158.138.51:41715] by server-11.bemta-3.messagelabs.com id
	F9/85-30250-FE8FD405; Mon, 10 Sep 2012 14:27:59 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1347287279!29674855!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTIyODk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7648 invoked from network); 10 Sep 2012 14:27: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;
	10 Sep 2012 14:27:59 -0000
X-IronPort-AV: E=Sophos;i="4.80,398,1344211200"; d="scan'208";a="14446203"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Sep 2012 14:27: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.279.1;
	Mon, 10 Sep 2012 15:27:59 +0100
Message-ID: <1347287277.5305.90.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "fantonifabio@tiscali.it" <fantonifabio@tiscali.it>
Date: Mon, 10 Sep 2012 15:27:57 +0100
In-Reply-To: <504DF87E.6020901@tiscali.it>
References: <5049EC11.9080302@tiscali.it>
	<1347030955.30018.115.camel@zakaz.uk.xensource.com>
	<504DB165.6040500@tiscali.it>
	<1347269362.5305.39.camel@zakaz.uk.xensource.com>
	<504DECE7.1050404@tiscali.it>
	<1347284515.5305.85.camel@zakaz.uk.xensource.com>
	<504DF87E.6020901@tiscali.it>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Test report of xen 4.2.0-rc4
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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-09-10 at 15:26 +0100, Fabio Fantoni wrote:
> gdb --args xl -vvv cd-eject W7 hdb
> GNU gdb (GDB) 7.4.1-debian
> Copyright (C) 2012 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later 
> <http://gnu.org/licenses/gpl.html>
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
> and "show warranty" for details.
> This GDB was configured as "x86_64-linux-gnu".
> For bug reporting instructions, please see:
> <http://www.gnu.org/software/gdb/bugs/>...
> Reading symbols from /usr/sbin/xl...done.
> (gdb) run
> Starting program: /usr/sbin/xl -vvv cd-eject W7 hdb
> [Thread debugging using libthread_db enabled]
> Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
> libxl: debug: libxl.c:2143:libxl_cdrom_insert: ao 0x623980: create: 
> how=(nil) callback=(nil) poller=0x6239e0
> libxl: debug: libxl_device.c:229:libxl__device_disk_set_backend: Disk 
> vdev=hdb spec.backend=unknown
> libxl: debug: libxl_device.c:175:disk_try_backend: Disk vdev=hdb, 
> backend phy unsuitable as phys path not a block device
> libxl: debug: libxl_device.c:210:disk_try_backend: Disk vdev=hdb, 
> backend tap unsuitable due to format empty
> libxl: debug: libxl_device.c:265:libxl__device_disk_set_backend: Disk 
> vdev=hdb, using backend qdisk
> libxl: debug: libxl_event.c:1497:libxl__ao_complete: ao 0x623980: 
> complete, rc=0
> libxl: debug: libxl.c:2236:libxl_cdrom_insert: ao 0x623980: inprogress: 
> poller=0x6239e0, flags=ic
> libxl: debug: libxl_event.c:1469:libxl__ao__destroy: ao 0x623980: destroy
> xc: debug: hypercall buffer: total allocations:4 total releases:4
> xc: debug: hypercall buffer: current allocations:0 maximum allocations:2
> xc: debug: hypercall buffer: cache current size:2
> xc: debug: hypercall buffer: cache hits:1 misses:2 toobig:1
> [Inferior 1 (process 5581) exited normally]
> (gdb) bt
> No stack.

That's because it seems to be working for you now... There is no crash
here.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 10 14:34:51 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Sep 2012 14:34: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 1TB54O-0001xA-Mm; Mon, 10 Sep 2012 14:34:36 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andreslc@gridcentric.ca>) id 1TB54N-0001x4-Bp
	for xen-devel@lists.xen.org; Mon, 10 Sep 2012 14:34:35 +0000
X-Env-Sender: andreslc@gridcentric.ca
X-Msg-Ref: server-9.tower-27.messagelabs.com!1347287663!9121206!1
X-Originating-IP: [209.85.223.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26447 invoked from network); 10 Sep 2012 14:34:27 -0000
Received: from mail-ie0-f173.google.com (HELO mail-ie0-f173.google.com)
	(209.85.223.173)
	by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Sep 2012 14:34:27 -0000
Received: by iebc10 with SMTP id c10so3937772ieb.32
	for <xen-devel@lists.xen.org>; Mon, 10 Sep 2012 07:34:23 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=subject:mime-version:content-type:from:in-reply-to:date:cc
	:content-transfer-encoding:message-id:references:to:x-mailer
	:x-gm-message-state;
	bh=RLfwb7cPeMV0R1tWjKYk8azixo6Br5Hf5Fmepu35rR8=;
	b=cWywCOBPMMhuk5tK9t4la+TpBJryu/CEzwAM0Z9VmPVQR8GFUpGQnDbzcaQ4XPvAQP
	uOd1cVyNG6FO9mb6B5PrtskySF+LyUqEaLB5bhC7F/iBLYtaoiSvBWACCQE/SDK2eUss
	oMku3J8uBV8o+PEtwIm6cXSSxHIAXIZ4TrkSitFk25rrcdx821T6Cssa0u3Cj6xzpO/t
	B1RsHG5UYTCHl9jtTfJFfXiGbdhJvW0MneTrKC5UQ53S1tGlf6Fu5/Rm6mr5YKSmeLuu
	0DqsE7GTsMaex9+S+rrmjD5M9cpLV8+Y0gsHa4kdfm15u8E25ILRG3MOh9Ol9orvG74D
	YQmQ==
Received: by 10.50.34.132 with SMTP id z4mr11431510igi.34.1347287663580;
	Mon, 10 Sep 2012 07:34:23 -0700 (PDT)
Received: from [192.168.1.100] (69-196-182-10.dsl.teksavvy.com.
	[69.196.182.10])
	by mx.google.com with ESMTPS id cu10sm21103729igc.9.2012.09.10.07.34.21
	(version=TLSv1/SSLv3 cipher=OTHER);
	Mon, 10 Sep 2012 07:34:22 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1278)
From: Andres Lagar-Cavilla <andreslc@gridcentric.ca>
In-Reply-To: <1347287175.5305.89.camel@zakaz.uk.xensource.com>
Date: Mon, 10 Sep 2012 10:34:23 -0400
Message-Id: <9AC332A1-A89A-4A89-8318-F918C22701A1@gridcentric.ca>
References: <08A8CD72-BB08-4178-945D-90C588A78F14@gridcentric.ca>
	<1347287175.5305.89.camel@zakaz.uk.xensource.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
X-Mailer: Apple Mail (2.1278)
X-Gm-Message-State: ALoCoQmxws8KM6g11I2vzYg6k/9qkC4XAqTo9hordMKnA0eq/EMcRDzHDH2mdtjjP6LABw/zNjCT
Cc: Andres Lagar-Cavilla <andreslc@gridcentric.ca>,
	Olaf Hering <olaf@aepfle.de>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"Tim \(Xen.org\)" <tim@xen.org>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen paging unit test
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Sep 10, 2012, at 10:26 AM, Ian Campbell wrote:

> On Mon, 2012-09-10 at 15:08 +0100, Andres Lagar-Cavilla wrote:
>> Hi,
>> In the process of submitting the privcmd MMAP_BATCH_V2 patches for Linux 3.7, Konrad asked a very valid question:
>> 
>> "How do you test this thing?"
>> 
>> Turns out that you have two ways
>> 1. You do the actual paging thing on a live domain
>> 2. I had a unit test buried in my stash
>> 
>> Coincidentally, Ian C asked for demonstrable consumers of the
>> xenpaging interface in the process of summarizing the 4.2 change log.
>> 
>> I've github'ed my paging unit test in the hopes it will be found
>> useful, not only as a unit test, but also a demo/reference piece of
>> code. 
>> 
>> The unit test exercises the privcmd/libxc interface for creating
>> foreign mappings of paged out pages. As a precondition, it must create
>> a domain, enable paging on it, and act as a pager to satisfy the
>> page-in requests generated by the foreign maps.
>> 
>> https://github.com/andreslagarcavilla/xenpagingtest
> 
> I get a server error (cat holding a 500? so error code 500? nice way to
> obfuscate the useful info!) from this.
> 
> I stripped off a level and tried https://github.com/andreslagarcavilla
> but that gets me an angry unicorn saying "Page did not respond in a
> timely fashion.".
> 
> :-)

I think github is just having a hard time right now. Many people are getting visits from angry unicorns.

> 
> Is this similar to/derived from tools/xenpaging?

Not really derived. The test will set up a dummy domain, page it out, and set up a pager. In a child process it will perform a number of different foreign mapping operations and patterns and check that everything works out well.

Similar to xenpaging in that they need to do similar things for setting up paging and watching paging events. But the unit test can afford the luxury of going straight to the point without bothering about user input, xenstore, what not.

Andres

> 
>> 
>> This might be considered useful for tools/tests in xen-unstable, and I'll be happy to resubmit in a suitable form if you ask.
>> 
>> Cheers
>> Andres
> 
> 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 10 14:34:51 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Sep 2012 14:34: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 1TB54O-0001xA-Mm; Mon, 10 Sep 2012 14:34:36 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andreslc@gridcentric.ca>) id 1TB54N-0001x4-Bp
	for xen-devel@lists.xen.org; Mon, 10 Sep 2012 14:34:35 +0000
X-Env-Sender: andreslc@gridcentric.ca
X-Msg-Ref: server-9.tower-27.messagelabs.com!1347287663!9121206!1
X-Originating-IP: [209.85.223.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26447 invoked from network); 10 Sep 2012 14:34:27 -0000
Received: from mail-ie0-f173.google.com (HELO mail-ie0-f173.google.com)
	(209.85.223.173)
	by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Sep 2012 14:34:27 -0000
Received: by iebc10 with SMTP id c10so3937772ieb.32
	for <xen-devel@lists.xen.org>; Mon, 10 Sep 2012 07:34:23 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=subject:mime-version:content-type:from:in-reply-to:date:cc
	:content-transfer-encoding:message-id:references:to:x-mailer
	:x-gm-message-state;
	bh=RLfwb7cPeMV0R1tWjKYk8azixo6Br5Hf5Fmepu35rR8=;
	b=cWywCOBPMMhuk5tK9t4la+TpBJryu/CEzwAM0Z9VmPVQR8GFUpGQnDbzcaQ4XPvAQP
	uOd1cVyNG6FO9mb6B5PrtskySF+LyUqEaLB5bhC7F/iBLYtaoiSvBWACCQE/SDK2eUss
	oMku3J8uBV8o+PEtwIm6cXSSxHIAXIZ4TrkSitFk25rrcdx821T6Cssa0u3Cj6xzpO/t
	B1RsHG5UYTCHl9jtTfJFfXiGbdhJvW0MneTrKC5UQ53S1tGlf6Fu5/Rm6mr5YKSmeLuu
	0DqsE7GTsMaex9+S+rrmjD5M9cpLV8+Y0gsHa4kdfm15u8E25ILRG3MOh9Ol9orvG74D
	YQmQ==
Received: by 10.50.34.132 with SMTP id z4mr11431510igi.34.1347287663580;
	Mon, 10 Sep 2012 07:34:23 -0700 (PDT)
Received: from [192.168.1.100] (69-196-182-10.dsl.teksavvy.com.
	[69.196.182.10])
	by mx.google.com with ESMTPS id cu10sm21103729igc.9.2012.09.10.07.34.21
	(version=TLSv1/SSLv3 cipher=OTHER);
	Mon, 10 Sep 2012 07:34:22 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1278)
From: Andres Lagar-Cavilla <andreslc@gridcentric.ca>
In-Reply-To: <1347287175.5305.89.camel@zakaz.uk.xensource.com>
Date: Mon, 10 Sep 2012 10:34:23 -0400
Message-Id: <9AC332A1-A89A-4A89-8318-F918C22701A1@gridcentric.ca>
References: <08A8CD72-BB08-4178-945D-90C588A78F14@gridcentric.ca>
	<1347287175.5305.89.camel@zakaz.uk.xensource.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
X-Mailer: Apple Mail (2.1278)
X-Gm-Message-State: ALoCoQmxws8KM6g11I2vzYg6k/9qkC4XAqTo9hordMKnA0eq/EMcRDzHDH2mdtjjP6LABw/zNjCT
Cc: Andres Lagar-Cavilla <andreslc@gridcentric.ca>,
	Olaf Hering <olaf@aepfle.de>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"Tim \(Xen.org\)" <tim@xen.org>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen paging unit test
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Sep 10, 2012, at 10:26 AM, Ian Campbell wrote:

> On Mon, 2012-09-10 at 15:08 +0100, Andres Lagar-Cavilla wrote:
>> Hi,
>> In the process of submitting the privcmd MMAP_BATCH_V2 patches for Linux 3.7, Konrad asked a very valid question:
>> 
>> "How do you test this thing?"
>> 
>> Turns out that you have two ways
>> 1. You do the actual paging thing on a live domain
>> 2. I had a unit test buried in my stash
>> 
>> Coincidentally, Ian C asked for demonstrable consumers of the
>> xenpaging interface in the process of summarizing the 4.2 change log.
>> 
>> I've github'ed my paging unit test in the hopes it will be found
>> useful, not only as a unit test, but also a demo/reference piece of
>> code. 
>> 
>> The unit test exercises the privcmd/libxc interface for creating
>> foreign mappings of paged out pages. As a precondition, it must create
>> a domain, enable paging on it, and act as a pager to satisfy the
>> page-in requests generated by the foreign maps.
>> 
>> https://github.com/andreslagarcavilla/xenpagingtest
> 
> I get a server error (cat holding a 500? so error code 500? nice way to
> obfuscate the useful info!) from this.
> 
> I stripped off a level and tried https://github.com/andreslagarcavilla
> but that gets me an angry unicorn saying "Page did not respond in a
> timely fashion.".
> 
> :-)

I think github is just having a hard time right now. Many people are getting visits from angry unicorns.

> 
> Is this similar to/derived from tools/xenpaging?

Not really derived. The test will set up a dummy domain, page it out, and set up a pager. In a child process it will perform a number of different foreign mapping operations and patterns and check that everything works out well.

Similar to xenpaging in that they need to do similar things for setting up paging and watching paging events. But the unit test can afford the luxury of going straight to the point without bothering about user input, xenstore, what not.

Andres

> 
>> 
>> This might be considered useful for tools/tests in xen-unstable, and I'll be happy to resubmit in a suitable form if you ask.
>> 
>> Cheers
>> Andres
> 
> 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 10 14:43:16 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Sep 2012 14: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 1TB5CZ-00028R-M7; Mon, 10 Sep 2012 14:43: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 1TB5CY-00028M-Dg
	for xen-devel@lists.xen.org; Mon, 10 Sep 2012 14:43:02 +0000
Received: from [85.158.138.51:63855] by server-7.bemta-3.messagelabs.com id
	D9/BC-32000-57CFD405; Mon, 10 Sep 2012 14:43:01 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1347288180!25678378!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTIyODk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31591 invoked from network); 10 Sep 2012 14:43:01 -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;
	10 Sep 2012 14:43:01 -0000
X-IronPort-AV: E=Sophos;i="4.80,398,1344211200"; d="scan'208";a="14446781"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Sep 2012 14:42: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.279.1; Mon, 10 Sep 2012 15:42: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
	1TB5CV-00052i-9y; Mon, 10 Sep 2012 14:42:59 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1TB5CV-0002Q9-5s;
	Mon, 10 Sep 2012 15:42:59 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20557.64627.33137.937086@mariner.uk.xensource.com>
Date: Mon, 10 Sep 2012 15:42:59 +0100
To: <xen-devel@lists.xen.org>, <ian.campbell@eu.citrix.com>
In-Reply-To: <20557.62949.300788.804976@mariner.uk.xensource.com>
References: <20544.39460.499127.781598@mariner.uk.xensource.com>
	<20557.62949.300788.804976@mariner.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Subject: Re: [Xen-devel] Test report: Migration from 4.1 to 4.2 works
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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: Test report: Migration from 4.1 to 4.2 works"):
>   xc: Saving memory: iter 1 (last sent 134144 skipped 1553): 0/1048576
>   0%xc: error: Failed to allocate memory for batch.!: Internal error

15:22 <ijc> It might be interesting to compare the actual memory usage
            of the same domain started with xend and xl on 4.1/4.2?

Started with xl create:

root@potato-beetle:~# xl list
Name                                        ID   Mem VCPUs      State   Time(s)
Domain-0                                     0   512     4     r-----     641.0
win.guest.osstest                           10   507     2     -b----     223.4
root@potato-beetle:~#

Then switched to xend:

root@potato-beetle:~# /etc/init.d/xend start
root@potato-beetle:~# xenstore-rm /local/domain/0/libxl/disable_udev

Started with xm create:

root@potato-beetle:~# xl list
Name                                        ID   Mem VCPUs      State   Time(s)
Domain-0                                     0   512     4     r-----     720.9
win.guest.osstest                           11   515     2     ------     238.0
root@potato-beetle:~#

I think what is happening is this: xend accounts memory differently to
xl, giving the guest actually slightly more than is specified in the
config file.  When xl during incoming migration reads the guest config
file, it assumes that the config file's memory maximum is an accurate
representation of the guest's actual memory use.

I can reproduce this problem by ballooning a PV guest before migrating
it.  Eg,
   xl create /etc/xen/debian.guest.osstest.cfg
with memory=512, maxmem=1024.  Then
   xl migrate debian.guest.osstest localhost
works but
   xl mem-set debian.guest.osstest 1024
   xl migrate debian.guest.osstest localhost

I think we need to fix this in 4.2.1 somehow.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 10 14:43:16 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Sep 2012 14: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 1TB5CZ-00028R-M7; Mon, 10 Sep 2012 14:43: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 1TB5CY-00028M-Dg
	for xen-devel@lists.xen.org; Mon, 10 Sep 2012 14:43:02 +0000
Received: from [85.158.138.51:63855] by server-7.bemta-3.messagelabs.com id
	D9/BC-32000-57CFD405; Mon, 10 Sep 2012 14:43:01 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1347288180!25678378!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTIyODk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31591 invoked from network); 10 Sep 2012 14:43:01 -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;
	10 Sep 2012 14:43:01 -0000
X-IronPort-AV: E=Sophos;i="4.80,398,1344211200"; d="scan'208";a="14446781"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Sep 2012 14:42: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.279.1; Mon, 10 Sep 2012 15:42: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
	1TB5CV-00052i-9y; Mon, 10 Sep 2012 14:42:59 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1TB5CV-0002Q9-5s;
	Mon, 10 Sep 2012 15:42:59 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20557.64627.33137.937086@mariner.uk.xensource.com>
Date: Mon, 10 Sep 2012 15:42:59 +0100
To: <xen-devel@lists.xen.org>, <ian.campbell@eu.citrix.com>
In-Reply-To: <20557.62949.300788.804976@mariner.uk.xensource.com>
References: <20544.39460.499127.781598@mariner.uk.xensource.com>
	<20557.62949.300788.804976@mariner.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Subject: Re: [Xen-devel] Test report: Migration from 4.1 to 4.2 works
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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: Test report: Migration from 4.1 to 4.2 works"):
>   xc: Saving memory: iter 1 (last sent 134144 skipped 1553): 0/1048576
>   0%xc: error: Failed to allocate memory for batch.!: Internal error

15:22 <ijc> It might be interesting to compare the actual memory usage
            of the same domain started with xend and xl on 4.1/4.2?

Started with xl create:

root@potato-beetle:~# xl list
Name                                        ID   Mem VCPUs      State   Time(s)
Domain-0                                     0   512     4     r-----     641.0
win.guest.osstest                           10   507     2     -b----     223.4
root@potato-beetle:~#

Then switched to xend:

root@potato-beetle:~# /etc/init.d/xend start
root@potato-beetle:~# xenstore-rm /local/domain/0/libxl/disable_udev

Started with xm create:

root@potato-beetle:~# xl list
Name                                        ID   Mem VCPUs      State   Time(s)
Domain-0                                     0   512     4     r-----     720.9
win.guest.osstest                           11   515     2     ------     238.0
root@potato-beetle:~#

I think what is happening is this: xend accounts memory differently to
xl, giving the guest actually slightly more than is specified in the
config file.  When xl during incoming migration reads the guest config
file, it assumes that the config file's memory maximum is an accurate
representation of the guest's actual memory use.

I can reproduce this problem by ballooning a PV guest before migrating
it.  Eg,
   xl create /etc/xen/debian.guest.osstest.cfg
with memory=512, maxmem=1024.  Then
   xl migrate debian.guest.osstest localhost
works but
   xl mem-set debian.guest.osstest 1024
   xl migrate debian.guest.osstest localhost

I think we need to fix this in 4.2.1 somehow.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 10 14:49:16 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Sep 2012 14: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 1TB5IN-0002Iq-Hg; Mon, 10 Sep 2012 14:49: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 1TB5IL-0002Ij-Ar
	for xen-devel@lists.xen.org; Mon, 10 Sep 2012 14:49:01 +0000
Received: from [85.158.143.99:16062] by server-2.bemta-4.messagelabs.com id
	F3/13-21239-CDDFD405; Mon, 10 Sep 2012 14:49:00 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1347288539!23155269!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTIyODk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31574 invoked from network); 10 Sep 2012 14:49: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;
	10 Sep 2012 14:49:00 -0000
X-IronPort-AV: E=Sophos;i="4.80,398,1344211200"; d="scan'208";a="14446980"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Sep 2012 14:48:59 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Mon, 10 Sep 2012 15:48:59 +0100
Message-ID: <1347288538.5305.96.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Mon, 10 Sep 2012 15:48:58 +0100
In-Reply-To: <20557.64627.33137.937086@mariner.uk.xensource.com>
References: <20544.39460.499127.781598@mariner.uk.xensource.com>
	<20557.62949.300788.804976@mariner.uk.xensource.com>
	<20557.64627.33137.937086@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Test report: Migration from 4.1 to 4.2 works
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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-09-10 at 15:42 +0100, Ian Jackson wrote:
> Ian Jackson writes ("Re: Test report: Migration from 4.1 to 4.2 works"):
> >   xc: Saving memory: iter 1 (last sent 134144 skipped 1553): 0/1048576
> >   0%xc: error: Failed to allocate memory for batch.!: Internal error
> 
> 15:22 <ijc> It might be interesting to compare the actual memory usage
>             of the same domain started with xend and xl on 4.1/4.2?
> 
> Started with xl create:
> 
> root@potato-beetle:~# xl list
> Name                                        ID   Mem VCPUs      State   Time(s)
> Domain-0                                     0   512     4     r-----     641.0
> win.guest.osstest                           10   507     2     -b----     223.4
> root@potato-beetle:~#
> 
> Then switched to xend:
> 
> root@potato-beetle:~# /etc/init.d/xend start
> root@potato-beetle:~# xenstore-rm /local/domain/0/libxl/disable_udev
> 
> Started with xm create:
> 
> root@potato-beetle:~# xl list
> Name                                        ID   Mem VCPUs      State   Time(s)
> Domain-0                                     0   512     4     r-----     720.9
> win.guest.osstest                           11   515     2     ------     238.0
> root@potato-beetle:~#
> 
> I think what is happening is this: xend accounts memory differently to
> xl, giving the guest actually slightly more than is specified in the
> config file.  When xl during incoming migration reads the guest config
> file, it assumes that the config file's memory maximum is an accurate
> representation of the guest's actual memory use.
> 
> I can reproduce this problem by ballooning a PV guest before migrating
> it.  Eg,
>    xl create /etc/xen/debian.guest.osstest.cfg
> with memory=512, maxmem=1024.  Then
>    xl migrate debian.guest.osstest localhost
> works but
>    xl mem-set debian.guest.osstest 1024
>    xl migrate debian.guest.osstest localhost
... "does not". I guess?

This is another facet of the problem with migrating based on the stored
config without taking into account dynamic changes made since the domain
was started.

> I think we need to fix this in 4.2.1 somehow.

The official workaround in 4.2.x is to use "xl config-update" to store a
new config file describing the new state of the domain when you change
its properties at runtime.

In 4.3 I'd like to add functionality to libxl to reconstitute a
libxl_domain_config from a running domain and use that instead of
reparsing the config for migrating/reboot etc. I think it's the only way
to handle these sorts of situations sanely.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 10 14:49:16 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Sep 2012 14: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 1TB5IN-0002Iq-Hg; Mon, 10 Sep 2012 14:49: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 1TB5IL-0002Ij-Ar
	for xen-devel@lists.xen.org; Mon, 10 Sep 2012 14:49:01 +0000
Received: from [85.158.143.99:16062] by server-2.bemta-4.messagelabs.com id
	F3/13-21239-CDDFD405; Mon, 10 Sep 2012 14:49:00 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1347288539!23155269!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTIyODk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31574 invoked from network); 10 Sep 2012 14:49: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;
	10 Sep 2012 14:49:00 -0000
X-IronPort-AV: E=Sophos;i="4.80,398,1344211200"; d="scan'208";a="14446980"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Sep 2012 14:48:59 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Mon, 10 Sep 2012 15:48:59 +0100
Message-ID: <1347288538.5305.96.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Mon, 10 Sep 2012 15:48:58 +0100
In-Reply-To: <20557.64627.33137.937086@mariner.uk.xensource.com>
References: <20544.39460.499127.781598@mariner.uk.xensource.com>
	<20557.62949.300788.804976@mariner.uk.xensource.com>
	<20557.64627.33137.937086@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Test report: Migration from 4.1 to 4.2 works
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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-09-10 at 15:42 +0100, Ian Jackson wrote:
> Ian Jackson writes ("Re: Test report: Migration from 4.1 to 4.2 works"):
> >   xc: Saving memory: iter 1 (last sent 134144 skipped 1553): 0/1048576
> >   0%xc: error: Failed to allocate memory for batch.!: Internal error
> 
> 15:22 <ijc> It might be interesting to compare the actual memory usage
>             of the same domain started with xend and xl on 4.1/4.2?
> 
> Started with xl create:
> 
> root@potato-beetle:~# xl list
> Name                                        ID   Mem VCPUs      State   Time(s)
> Domain-0                                     0   512     4     r-----     641.0
> win.guest.osstest                           10   507     2     -b----     223.4
> root@potato-beetle:~#
> 
> Then switched to xend:
> 
> root@potato-beetle:~# /etc/init.d/xend start
> root@potato-beetle:~# xenstore-rm /local/domain/0/libxl/disable_udev
> 
> Started with xm create:
> 
> root@potato-beetle:~# xl list
> Name                                        ID   Mem VCPUs      State   Time(s)
> Domain-0                                     0   512     4     r-----     720.9
> win.guest.osstest                           11   515     2     ------     238.0
> root@potato-beetle:~#
> 
> I think what is happening is this: xend accounts memory differently to
> xl, giving the guest actually slightly more than is specified in the
> config file.  When xl during incoming migration reads the guest config
> file, it assumes that the config file's memory maximum is an accurate
> representation of the guest's actual memory use.
> 
> I can reproduce this problem by ballooning a PV guest before migrating
> it.  Eg,
>    xl create /etc/xen/debian.guest.osstest.cfg
> with memory=512, maxmem=1024.  Then
>    xl migrate debian.guest.osstest localhost
> works but
>    xl mem-set debian.guest.osstest 1024
>    xl migrate debian.guest.osstest localhost
... "does not". I guess?

This is another facet of the problem with migrating based on the stored
config without taking into account dynamic changes made since the domain
was started.

> I think we need to fix this in 4.2.1 somehow.

The official workaround in 4.2.x is to use "xl config-update" to store a
new config file describing the new state of the domain when you change
its properties at runtime.

In 4.3 I'd like to add functionality to libxl to reconstitute a
libxl_domain_config from a running domain and use that instead of
reparsing the config for migrating/reboot etc. I think it's the only way
to handle these sorts of situations sanely.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 10 14:54:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Sep 2012 14:54: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 1TB5NB-0002Rn-AI; Mon, 10 Sep 2012 14:54:01 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Christoph.Egger@amd.com>) id 1TB5NA-0002Rh-5v
	for xen-devel@lists.xen.org; Mon, 10 Sep 2012 14:54:00 +0000
X-Env-Sender: Christoph.Egger@amd.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1347288825!9125163!1
X-Originating-IP: [216.32.181.185]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22080 invoked from network); 10 Sep 2012 14:53:46 -0000
Received: from ch1ehsobe005.messaging.microsoft.com (HELO
	ch1outboundpool.messaging.microsoft.com) (216.32.181.185)
	by server-9.tower-27.messagelabs.com with AES128-SHA encrypted SMTP;
	10 Sep 2012 14:53:46 -0000
Received: from mail118-ch1-R.bigfish.com (10.43.68.227) by
	CH1EHSOBE008.bigfish.com (10.43.70.58) with Microsoft SMTP Server id
	14.1.225.23; Mon, 10 Sep 2012 14:53:45 +0000
Received: from mail118-ch1 (localhost [127.0.0.1])	by
	mail118-ch1-R.bigfish.com (Postfix) with ESMTP id 58D104800F2	for
	<xen-devel@lists.xen.org>; Mon, 10 Sep 2012 14:53:45 +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(zzc85fhc85dhzz1202h1d1ahzz8275bhz2dh668h839hd25he5bhf0ah107ah1288h12a5h34h1155h)
Received: from mail118-ch1 (localhost.localdomain [127.0.0.1]) by mail118-ch1
	(MessageSwitch) id 1347288823231760_26284;
	Mon, 10 Sep 2012 14:53:43 +0000 (UTC)
Received: from CH1EHSMHS022.bigfish.com (snatpool2.int.messaging.microsoft.com
	[10.43.68.235])	by mail118-ch1.bigfish.com (Postfix) with ESMTP id
	35B2410005F	for <xen-devel@lists.xen.org>;
	Mon, 10 Sep 2012 14:53:43 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	CH1EHSMHS022.bigfish.com (10.43.70.22) with Microsoft SMTP Server id
	14.1.225.23; Mon, 10 Sep 2012 14:53:41 +0000
X-WSS-ID: 0MA52PF-02-2YW-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 27651C8125	for <xen-devel@lists.xen.org>; Mon, 10 Sep 2012
	09:53:39 -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;
	Mon, 10 Sep 2012 10:07:18 -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;
	Mon, 10 Sep 2012 09:53:33 -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, 10 Sep 2012
	10:53:30 -0400
Message-ID: <504DFEE9.7020900@amd.com>
Date: Mon, 10 Sep 2012 16:53:29 +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="------------000704010403080306070409"
X-OriginatorOrg: amd.com
Subject: [Xen-devel] [PATCH] refactor mce code
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--------------000704010403080306070409
Content-Type: text/plain; charset="ISO-8859-15"
Content-Transfer-Encoding: 7bit


Factor common mc code out of intel specific code and move it into common
files.
No functional changes.

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
Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen
Registergericht Muenchen, HRB Nr. 43632

--------------000704010403080306070409
Content-Type: text/plain; charset="us-ascii"; name="xen_mce_refactor.diff"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="xen_mce_refactor.diff"
Content-Description: xen_mce_refactor.diff

# User Christoph Egger
# Date 1347276743 -7200
Factor common mc code out of intel specific code and move it into common files.
No functional changes.

Signed-off-by: Christoph Egger <Christoph.Egger@amd.com>

diff -r 06f42b46c057 -r c45743df3686 xen/arch/x86/cpu/mcheck/Makefile
--- a/xen/arch/x86/cpu/mcheck/Makefile
+++ b/xen/arch/x86/cpu/mcheck/Makefile
@@ -2,10 +2,12 @@ obj-y += amd_nonfatal.o
 obj-y += k7.o
 obj-y += amd_k8.o
 obj-y += amd_f10.o
+obj-y += mcbarrier.o
 obj-y += mctelem.o
 obj-y += mce.o
 obj-y += mce-apei.o
 obj-y += mce_intel.o
 obj-y += mce_amd_quirks.o
+obj-y += mcutil.o
 obj-y += non-fatal.o
 obj-y += vmce.o
diff -r 06f42b46c057 -r c45743df3686 xen/arch/x86/cpu/mcheck/mcbarrier.c
--- /dev/null
+++ b/xen/arch/x86/cpu/mcheck/mcbarrier.c
@@ -0,0 +1,57 @@
+#include "mcbarrier.h"
+#include "mcutil.h"
+#include "mce.h"
+
+void mce_barrier_init(struct mce_softirq_barrier *bar)
+{
+    atomic_set(&bar->val, 0);
+    atomic_set(&bar->ingen, 0);
+    atomic_set(&bar->outgen, 0);
+}
+
+void mce_barrier_dec(struct mce_softirq_barrier *bar)
+{
+    atomic_inc(&bar->outgen);
+    wmb();
+    atomic_dec(&bar->val);
+}
+
+void mce_barrier_enter(struct mce_softirq_barrier *bar)
+{
+    int gen;
+
+    if (!mce_broadcast)
+        return;
+    atomic_inc(&bar->ingen);
+    gen = atomic_read(&bar->outgen);
+    mb();
+    atomic_inc(&bar->val);
+    while ( atomic_read(&bar->val) != num_online_cpus() &&
+        atomic_read(&bar->outgen) == gen) {
+            mb();
+            mce_panic_check();
+    }
+}
+
+void mce_barrier_exit(struct mce_softirq_barrier *bar)
+{
+    int gen;
+
+    if (!mce_broadcast)
+        return;
+    atomic_inc(&bar->outgen);
+    gen = atomic_read(&bar->ingen);
+    mb();
+    atomic_dec(&bar->val);
+    while ( atomic_read(&bar->val) != 0 &&
+        atomic_read(&bar->ingen) == gen ) {
+            mb();
+            mce_panic_check();
+    }
+}
+
+void mce_barrier(struct mce_softirq_barrier *bar)
+{
+    mce_barrier_enter(bar);
+    mce_barrier_exit(bar);
+}
diff -r 06f42b46c057 -r c45743df3686 xen/arch/x86/cpu/mcheck/mcbarrier.h
--- /dev/null
+++ b/xen/arch/x86/cpu/mcheck/mcbarrier.h
@@ -0,0 +1,44 @@
+#ifndef _MCHECK_BARRIER_H
+#define _MCHECK_BARRIER_H
+
+#include <asm/atomic.h>
+
+/* MCE handling */
+struct mce_softirq_barrier {
+    atomic_t val;
+    atomic_t ingen;
+    atomic_t outgen;
+};
+
+/*
+ * Initialize a barrier. Just set it to 0.
+ */
+void mce_barrier_init(struct mce_softirq_barrier *);
+
+/*
+ * This function will need to be used when offlining a CPU in the
+ * recovery actions.
+ *
+ * Decrement a barrier only. Needed for cases where the CPU
+ * in question can't do it itself (e.g. it is being offlined).
+ */
+void mce_barrier_dec(struct mce_softirq_barrier *);
+
+/*
+ * Increment the generation number and the value. The generation number
+ * is incremented when entering a barrier. This way, it can be checked
+ * on exit if a CPU is trying to re-enter the barrier. This can happen
+ * if the first CPU to make it out immediately exits or re-enters, while
+ * another CPU that is still in the loop becomes otherwise occupied
+ * (e.g. it needs to service an interrupt, etc), missing the value
+ * it's waiting for.
+ *
+ * These barrier functions should always be paired, so that the
+ * counter value will reach 0 again after all CPUs have exited.
+ */
+void mce_barrier_enter(struct mce_softirq_barrier *);
+void mce_barrier_exit(struct mce_softirq_barrier *);
+
+void mce_barrier(struct mce_softirq_barrier *);
+
+#endif /* _MCHECK_BARRIER_H */
diff -r 06f42b46c057 -r c45743df3686 xen/arch/x86/cpu/mcheck/mce_intel.c
--- a/xen/arch/x86/cpu/mcheck/mce_intel.c
+++ b/xen/arch/x86/cpu/mcheck/mce_intel.c
@@ -16,6 +16,8 @@
 #include <asm/apic.h>
 #include "mce.h"
 #include "x86_mca.h"
+#include "mcbarrier.h"
+#include "mcutil.h"
 
 DEFINE_PER_CPU(struct mca_banks *, mce_banks_owned);
 DEFINE_PER_CPU(struct mca_banks *, no_cmci_banks);
@@ -164,13 +166,6 @@ static void intel_init_thermal(struct cp
 }
 #endif /* CONFIG_X86_MCE_THERMAL */
 
-/* MCE handling */
-struct mce_softirq_barrier {
-	atomic_t val;
-	atomic_t ingen;
-	atomic_t outgen;
-};
-
 static struct mce_softirq_barrier mce_inside_bar, mce_severity_bar;
 static struct mce_softirq_barrier mce_trap_bar;
 
@@ -186,9 +181,6 @@ static atomic_t severity_cpu = ATOMIC_IN
 static atomic_t found_error = ATOMIC_INIT(0);
 static cpumask_t mce_fatal_cpus;
 
-static void mce_barrier_enter(struct mce_softirq_barrier *);
-static void mce_barrier_exit(struct mce_softirq_barrier *);
-
 static const struct mca_error_handler *__read_mostly mce_dhandlers;
 static const struct mca_error_handler *__read_mostly mce_uhandlers;
 static unsigned int __read_mostly mce_dhandler_num;
@@ -385,25 +377,6 @@ static int mce_urgent_action(struct cpu_
  * Round2: Do all MCE processing logic as normal.
  */
 
-static void mce_panic_check(void)
-{
-      if (is_mc_panic) {
-              local_irq_enable();
-              for ( ; ; )
-                      halt();
-      }
-}
-
-/*
- * Initialize a barrier. Just set it to 0.
- */
-static void mce_barrier_init(struct mce_softirq_barrier *bar)
-{
-      atomic_set(&bar->val, 0);
-      atomic_set(&bar->ingen, 0);
-      atomic_set(&bar->outgen, 0);
-}
-
 static void mce_handler_init(void)
 {
     if (smp_processor_id() != 0)
@@ -417,21 +390,6 @@ static void mce_handler_init(void)
     spin_lock_init(&mce_logout_lock);
     open_softirq(MACHINE_CHECK_SOFTIRQ, mce_softirq);
 }
-#if 0
-/*
- * This function will need to be used when offlining a CPU in the
- * recovery actions.
- *
- * Decrement a barrier only. Needed for cases where the CPU
- * in question can't do it itself (e.g. it is being offlined).
- */
-static void mce_barrier_dec(struct mce_softirq_barrier *bar)
-{
-      atomic_inc(&bar->outgen);
-      wmb();
-      atomic_dec(&bar->val);
-}
-#endif
 
 static void mce_spin_lock(spinlock_t *lk)
 {
@@ -446,60 +404,6 @@ static void mce_spin_unlock(spinlock_t *
       spin_unlock(lk);
 }
 
-/*
- * Increment the generation number and the value. The generation number
- * is incremented when entering a barrier. This way, it can be checked
- * on exit if a CPU is trying to re-enter the barrier. This can happen
- * if the first CPU to make it out immediately exits or re-enters, while
- * another CPU that is still in the loop becomes otherwise occupied
- * (e.g. it needs to service an interrupt, etc), missing the value
- * it's waiting for.
- *
- * These barrier functions should always be paired, so that the
- * counter value will reach 0 again after all CPUs have exited.
- */
-static void mce_barrier_enter(struct mce_softirq_barrier *bar)
-{
-      int gen;
-
-      if (!mce_broadcast)
-          return;
-      atomic_inc(&bar->ingen);
-      gen = atomic_read(&bar->outgen);
-      mb();
-      atomic_inc(&bar->val);
-      while ( atomic_read(&bar->val) != num_online_cpus() &&
-          atomic_read(&bar->outgen) == gen) {
-              mb();
-              mce_panic_check();
-      }
-}
-
-static void mce_barrier_exit(struct mce_softirq_barrier *bar)
-{
-      int gen;
-
-      if (!mce_broadcast)
-          return;
-      atomic_inc(&bar->outgen);
-      gen = atomic_read(&bar->ingen);
-      mb();
-      atomic_dec(&bar->val);
-      while ( atomic_read(&bar->val) != 0 &&
-          atomic_read(&bar->ingen) == gen ) {
-              mb();
-              mce_panic_check();
-      }
-}
-
-#if 0
-static void mce_barrier(struct mce_softirq_barrier *bar)
-{
-      mce_barrier_enter(bar);
-      mce_barrier_exit(bar);
-}
-#endif
-
 /* Intel MCE handler */
 static inline void intel_get_extended_msr(struct mcinfo_extended *ext, u32 msr)
 {
diff -r 06f42b46c057 -r c45743df3686 xen/arch/x86/cpu/mcheck/mcutil.c
--- /dev/null
+++ b/xen/arch/x86/cpu/mcheck/mcutil.c
@@ -0,0 +1,13 @@
+
+#include <asm/system.h>
+#include "mcutil.h"
+#include "mce.h"
+
+void mce_panic_check(void)
+{
+    if (is_mc_panic) {
+        local_irq_enable();
+        for ( ; ; )
+            halt();
+    }
+}
diff -r 06f42b46c057 -r c45743df3686 xen/arch/x86/cpu/mcheck/mcutil.h
--- /dev/null
+++ b/xen/arch/x86/cpu/mcheck/mcutil.h
@@ -0,0 +1,6 @@
+#ifndef _MCHECK_UTIL_H
+#define _MCHECK_UTIL_H
+
+void mce_panic_check(void);
+
+#endif

--------------000704010403080306070409
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--------------000704010403080306070409--


From xen-devel-bounces@lists.xen.org Mon Sep 10 14:54:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Sep 2012 14:54: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 1TB5NB-0002Rn-AI; Mon, 10 Sep 2012 14:54:01 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Christoph.Egger@amd.com>) id 1TB5NA-0002Rh-5v
	for xen-devel@lists.xen.org; Mon, 10 Sep 2012 14:54:00 +0000
X-Env-Sender: Christoph.Egger@amd.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1347288825!9125163!1
X-Originating-IP: [216.32.181.185]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22080 invoked from network); 10 Sep 2012 14:53:46 -0000
Received: from ch1ehsobe005.messaging.microsoft.com (HELO
	ch1outboundpool.messaging.microsoft.com) (216.32.181.185)
	by server-9.tower-27.messagelabs.com with AES128-SHA encrypted SMTP;
	10 Sep 2012 14:53:46 -0000
Received: from mail118-ch1-R.bigfish.com (10.43.68.227) by
	CH1EHSOBE008.bigfish.com (10.43.70.58) with Microsoft SMTP Server id
	14.1.225.23; Mon, 10 Sep 2012 14:53:45 +0000
Received: from mail118-ch1 (localhost [127.0.0.1])	by
	mail118-ch1-R.bigfish.com (Postfix) with ESMTP id 58D104800F2	for
	<xen-devel@lists.xen.org>; Mon, 10 Sep 2012 14:53:45 +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(zzc85fhc85dhzz1202h1d1ahzz8275bhz2dh668h839hd25he5bhf0ah107ah1288h12a5h34h1155h)
Received: from mail118-ch1 (localhost.localdomain [127.0.0.1]) by mail118-ch1
	(MessageSwitch) id 1347288823231760_26284;
	Mon, 10 Sep 2012 14:53:43 +0000 (UTC)
Received: from CH1EHSMHS022.bigfish.com (snatpool2.int.messaging.microsoft.com
	[10.43.68.235])	by mail118-ch1.bigfish.com (Postfix) with ESMTP id
	35B2410005F	for <xen-devel@lists.xen.org>;
	Mon, 10 Sep 2012 14:53:43 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	CH1EHSMHS022.bigfish.com (10.43.70.22) with Microsoft SMTP Server id
	14.1.225.23; Mon, 10 Sep 2012 14:53:41 +0000
X-WSS-ID: 0MA52PF-02-2YW-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 27651C8125	for <xen-devel@lists.xen.org>; Mon, 10 Sep 2012
	09:53:39 -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;
	Mon, 10 Sep 2012 10:07:18 -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;
	Mon, 10 Sep 2012 09:53:33 -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, 10 Sep 2012
	10:53:30 -0400
Message-ID: <504DFEE9.7020900@amd.com>
Date: Mon, 10 Sep 2012 16:53:29 +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="------------000704010403080306070409"
X-OriginatorOrg: amd.com
Subject: [Xen-devel] [PATCH] refactor mce code
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--------------000704010403080306070409
Content-Type: text/plain; charset="ISO-8859-15"
Content-Transfer-Encoding: 7bit


Factor common mc code out of intel specific code and move it into common
files.
No functional changes.

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
Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen
Registergericht Muenchen, HRB Nr. 43632

--------------000704010403080306070409
Content-Type: text/plain; charset="us-ascii"; name="xen_mce_refactor.diff"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="xen_mce_refactor.diff"
Content-Description: xen_mce_refactor.diff

# User Christoph Egger
# Date 1347276743 -7200
Factor common mc code out of intel specific code and move it into common files.
No functional changes.

Signed-off-by: Christoph Egger <Christoph.Egger@amd.com>

diff -r 06f42b46c057 -r c45743df3686 xen/arch/x86/cpu/mcheck/Makefile
--- a/xen/arch/x86/cpu/mcheck/Makefile
+++ b/xen/arch/x86/cpu/mcheck/Makefile
@@ -2,10 +2,12 @@ obj-y += amd_nonfatal.o
 obj-y += k7.o
 obj-y += amd_k8.o
 obj-y += amd_f10.o
+obj-y += mcbarrier.o
 obj-y += mctelem.o
 obj-y += mce.o
 obj-y += mce-apei.o
 obj-y += mce_intel.o
 obj-y += mce_amd_quirks.o
+obj-y += mcutil.o
 obj-y += non-fatal.o
 obj-y += vmce.o
diff -r 06f42b46c057 -r c45743df3686 xen/arch/x86/cpu/mcheck/mcbarrier.c
--- /dev/null
+++ b/xen/arch/x86/cpu/mcheck/mcbarrier.c
@@ -0,0 +1,57 @@
+#include "mcbarrier.h"
+#include "mcutil.h"
+#include "mce.h"
+
+void mce_barrier_init(struct mce_softirq_barrier *bar)
+{
+    atomic_set(&bar->val, 0);
+    atomic_set(&bar->ingen, 0);
+    atomic_set(&bar->outgen, 0);
+}
+
+void mce_barrier_dec(struct mce_softirq_barrier *bar)
+{
+    atomic_inc(&bar->outgen);
+    wmb();
+    atomic_dec(&bar->val);
+}
+
+void mce_barrier_enter(struct mce_softirq_barrier *bar)
+{
+    int gen;
+
+    if (!mce_broadcast)
+        return;
+    atomic_inc(&bar->ingen);
+    gen = atomic_read(&bar->outgen);
+    mb();
+    atomic_inc(&bar->val);
+    while ( atomic_read(&bar->val) != num_online_cpus() &&
+        atomic_read(&bar->outgen) == gen) {
+            mb();
+            mce_panic_check();
+    }
+}
+
+void mce_barrier_exit(struct mce_softirq_barrier *bar)
+{
+    int gen;
+
+    if (!mce_broadcast)
+        return;
+    atomic_inc(&bar->outgen);
+    gen = atomic_read(&bar->ingen);
+    mb();
+    atomic_dec(&bar->val);
+    while ( atomic_read(&bar->val) != 0 &&
+        atomic_read(&bar->ingen) == gen ) {
+            mb();
+            mce_panic_check();
+    }
+}
+
+void mce_barrier(struct mce_softirq_barrier *bar)
+{
+    mce_barrier_enter(bar);
+    mce_barrier_exit(bar);
+}
diff -r 06f42b46c057 -r c45743df3686 xen/arch/x86/cpu/mcheck/mcbarrier.h
--- /dev/null
+++ b/xen/arch/x86/cpu/mcheck/mcbarrier.h
@@ -0,0 +1,44 @@
+#ifndef _MCHECK_BARRIER_H
+#define _MCHECK_BARRIER_H
+
+#include <asm/atomic.h>
+
+/* MCE handling */
+struct mce_softirq_barrier {
+    atomic_t val;
+    atomic_t ingen;
+    atomic_t outgen;
+};
+
+/*
+ * Initialize a barrier. Just set it to 0.
+ */
+void mce_barrier_init(struct mce_softirq_barrier *);
+
+/*
+ * This function will need to be used when offlining a CPU in the
+ * recovery actions.
+ *
+ * Decrement a barrier only. Needed for cases where the CPU
+ * in question can't do it itself (e.g. it is being offlined).
+ */
+void mce_barrier_dec(struct mce_softirq_barrier *);
+
+/*
+ * Increment the generation number and the value. The generation number
+ * is incremented when entering a barrier. This way, it can be checked
+ * on exit if a CPU is trying to re-enter the barrier. This can happen
+ * if the first CPU to make it out immediately exits or re-enters, while
+ * another CPU that is still in the loop becomes otherwise occupied
+ * (e.g. it needs to service an interrupt, etc), missing the value
+ * it's waiting for.
+ *
+ * These barrier functions should always be paired, so that the
+ * counter value will reach 0 again after all CPUs have exited.
+ */
+void mce_barrier_enter(struct mce_softirq_barrier *);
+void mce_barrier_exit(struct mce_softirq_barrier *);
+
+void mce_barrier(struct mce_softirq_barrier *);
+
+#endif /* _MCHECK_BARRIER_H */
diff -r 06f42b46c057 -r c45743df3686 xen/arch/x86/cpu/mcheck/mce_intel.c
--- a/xen/arch/x86/cpu/mcheck/mce_intel.c
+++ b/xen/arch/x86/cpu/mcheck/mce_intel.c
@@ -16,6 +16,8 @@
 #include <asm/apic.h>
 #include "mce.h"
 #include "x86_mca.h"
+#include "mcbarrier.h"
+#include "mcutil.h"
 
 DEFINE_PER_CPU(struct mca_banks *, mce_banks_owned);
 DEFINE_PER_CPU(struct mca_banks *, no_cmci_banks);
@@ -164,13 +166,6 @@ static void intel_init_thermal(struct cp
 }
 #endif /* CONFIG_X86_MCE_THERMAL */
 
-/* MCE handling */
-struct mce_softirq_barrier {
-	atomic_t val;
-	atomic_t ingen;
-	atomic_t outgen;
-};
-
 static struct mce_softirq_barrier mce_inside_bar, mce_severity_bar;
 static struct mce_softirq_barrier mce_trap_bar;
 
@@ -186,9 +181,6 @@ static atomic_t severity_cpu = ATOMIC_IN
 static atomic_t found_error = ATOMIC_INIT(0);
 static cpumask_t mce_fatal_cpus;
 
-static void mce_barrier_enter(struct mce_softirq_barrier *);
-static void mce_barrier_exit(struct mce_softirq_barrier *);
-
 static const struct mca_error_handler *__read_mostly mce_dhandlers;
 static const struct mca_error_handler *__read_mostly mce_uhandlers;
 static unsigned int __read_mostly mce_dhandler_num;
@@ -385,25 +377,6 @@ static int mce_urgent_action(struct cpu_
  * Round2: Do all MCE processing logic as normal.
  */
 
-static void mce_panic_check(void)
-{
-      if (is_mc_panic) {
-              local_irq_enable();
-              for ( ; ; )
-                      halt();
-      }
-}
-
-/*
- * Initialize a barrier. Just set it to 0.
- */
-static void mce_barrier_init(struct mce_softirq_barrier *bar)
-{
-      atomic_set(&bar->val, 0);
-      atomic_set(&bar->ingen, 0);
-      atomic_set(&bar->outgen, 0);
-}
-
 static void mce_handler_init(void)
 {
     if (smp_processor_id() != 0)
@@ -417,21 +390,6 @@ static void mce_handler_init(void)
     spin_lock_init(&mce_logout_lock);
     open_softirq(MACHINE_CHECK_SOFTIRQ, mce_softirq);
 }
-#if 0
-/*
- * This function will need to be used when offlining a CPU in the
- * recovery actions.
- *
- * Decrement a barrier only. Needed for cases where the CPU
- * in question can't do it itself (e.g. it is being offlined).
- */
-static void mce_barrier_dec(struct mce_softirq_barrier *bar)
-{
-      atomic_inc(&bar->outgen);
-      wmb();
-      atomic_dec(&bar->val);
-}
-#endif
 
 static void mce_spin_lock(spinlock_t *lk)
 {
@@ -446,60 +404,6 @@ static void mce_spin_unlock(spinlock_t *
       spin_unlock(lk);
 }
 
-/*
- * Increment the generation number and the value. The generation number
- * is incremented when entering a barrier. This way, it can be checked
- * on exit if a CPU is trying to re-enter the barrier. This can happen
- * if the first CPU to make it out immediately exits or re-enters, while
- * another CPU that is still in the loop becomes otherwise occupied
- * (e.g. it needs to service an interrupt, etc), missing the value
- * it's waiting for.
- *
- * These barrier functions should always be paired, so that the
- * counter value will reach 0 again after all CPUs have exited.
- */
-static void mce_barrier_enter(struct mce_softirq_barrier *bar)
-{
-      int gen;
-
-      if (!mce_broadcast)
-          return;
-      atomic_inc(&bar->ingen);
-      gen = atomic_read(&bar->outgen);
-      mb();
-      atomic_inc(&bar->val);
-      while ( atomic_read(&bar->val) != num_online_cpus() &&
-          atomic_read(&bar->outgen) == gen) {
-              mb();
-              mce_panic_check();
-      }
-}
-
-static void mce_barrier_exit(struct mce_softirq_barrier *bar)
-{
-      int gen;
-
-      if (!mce_broadcast)
-          return;
-      atomic_inc(&bar->outgen);
-      gen = atomic_read(&bar->ingen);
-      mb();
-      atomic_dec(&bar->val);
-      while ( atomic_read(&bar->val) != 0 &&
-          atomic_read(&bar->ingen) == gen ) {
-              mb();
-              mce_panic_check();
-      }
-}
-
-#if 0
-static void mce_barrier(struct mce_softirq_barrier *bar)
-{
-      mce_barrier_enter(bar);
-      mce_barrier_exit(bar);
-}
-#endif
-
 /* Intel MCE handler */
 static inline void intel_get_extended_msr(struct mcinfo_extended *ext, u32 msr)
 {
diff -r 06f42b46c057 -r c45743df3686 xen/arch/x86/cpu/mcheck/mcutil.c
--- /dev/null
+++ b/xen/arch/x86/cpu/mcheck/mcutil.c
@@ -0,0 +1,13 @@
+
+#include <asm/system.h>
+#include "mcutil.h"
+#include "mce.h"
+
+void mce_panic_check(void)
+{
+    if (is_mc_panic) {
+        local_irq_enable();
+        for ( ; ; )
+            halt();
+    }
+}
diff -r 06f42b46c057 -r c45743df3686 xen/arch/x86/cpu/mcheck/mcutil.h
--- /dev/null
+++ b/xen/arch/x86/cpu/mcheck/mcutil.h
@@ -0,0 +1,6 @@
+#ifndef _MCHECK_UTIL_H
+#define _MCHECK_UTIL_H
+
+void mce_panic_check(void);
+
+#endif

--------------000704010403080306070409
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--------------000704010403080306070409--


From xen-devel-bounces@lists.xen.org Mon Sep 10 15:09:17 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Sep 2012 15:09:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TB5ba-0002xz-Q5; Mon, 10 Sep 2012 15:08:54 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mathias.gaunard@ens-lyon.org>) id 1TB5bZ-0002xr-Ft
	for xen-devel@lists.xen.org; Mon, 10 Sep 2012 15:08:53 +0000
Received: from [85.158.138.51:56129] by server-10.bemta-3.messagelabs.com id
	6D/7E-10411-4820E405; Mon, 10 Sep 2012 15:08:52 +0000
X-Env-Sender: mathias.gaunard@ens-lyon.org
X-Msg-Ref: server-13.tower-174.messagelabs.com!1347289732!11047322!1
X-Originating-IP: [46.105.75.36]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24743 invoked from network); 10 Sep 2012 15:08:52 -0000
Received: from 2.mo3.mail-out.ovh.net (HELO mo3.mail-out.ovh.net)
	(46.105.75.36) by server-13.tower-174.messagelabs.com with SMTP;
	10 Sep 2012 15:08:52 -0000
Received: from mail96.ha.ovh.net (b6.ovh.net [213.186.33.56])
	by mo3.mail-out.ovh.net (Postfix) with SMTP id F217AFF8BB7
	for <xen-devel@lists.xen.org>; Mon, 10 Sep 2012 17:16:40 +0200 (CEST)
Received: from b0.ovh.net (HELO queueout) (213.186.33.50)
	by b0.ovh.net with SMTP; 10 Sep 2012 17:08:51 +0200
Received: from unknown (HELO ?192.168.27.237?)
	(mathias@gaunard.com@193.55.24.4)
	by ns0.ovh.net with SMTP; 10 Sep 2012 17:08:50 +0200
Message-ID: <504E0282.5020701@ens-lyon.org>
Date: Mon, 10 Sep 2012 17:08:50 +0200
From: Mathias Gaunard <mathias.gaunard@ens-lyon.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120827 Thunderbird/15.0
MIME-Version: 1.0
To: xen-devel@lists.xen.org
X-Ovh-Mailout: 178.32.228.3 (mo3.mail-out.ovh.net)
X-Ovh-Tracer-Id: 180706936576475687
X-Ovh-Remote: 193.55.24.4 ()
X-Ovh-Local: 213.186.33.20 (ns0.ovh.net)
X-OVH-SPAMSTATE: OK
X-OVH-SPAMSCORE: 0
X-OVH-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrfeehtddrheegucetufdoteggodetrfcurfhrohhfihhlvgemucfqggfjnecuuegrihhlohhuthemuceftddtnecunecuhfhrohhmpeforghthhhirghsucfirghunhgrrhguuceomhgrthhhihgrshdrghgruhhnrghrugesvghnshdqlhihohhnrdhorhhgqeenucffohhmrghinhepgigvnhdrohhrghenucfjughrpefkfffhfgggvffutgfgsehtjegrtddtfedu
X-Spam-Check: DONE|U 0.5/N
X-VR-SPAMSTATE: OK
X-VR-SPAMSCORE: 0
X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrfeehtddrheegucetufdoteggodetrfcurfhrohhfihhlvgemucfqggfjnecuuegrihhlohhuthemuceftddtnecunecuhfhrohhmpeforghthhhirghsucfirghunhgrrhguuceomhgrthhhihgrshdrghgruhhnrghrugesvghnshdqlhihohhnrdhorhhgqeenucffohhmrghinhepgigvnhdrohhrghenucfjughrpefkfffhfgggvffutgfgsehtjegrtddtfedu
Subject: [Xen-devel] Xen 4.2 RC4 test on Debian
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
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, I tried to install Xen 4.2 RC4 on Debian Wheezy.

I followed the instructions here:
<http://wiki.xen.org/wiki/Xen_4.2_RC2_test_instructions>

./configure
make world
make deb

then sudo dpkg -i --force-overwrite dist/xen-upstream-4.2.0-rc4.deb

I used --force-overwrite so that I didn't have to uninstall my 
libxenstore package on which several other things depend.

then sudo update-grub

I rebooted and selected Xen 4.2

# xm
Traceback (most recent call last):
   File "/usr/sbin/xm", line 5, in <module>
     from xen.xm import main
ImportError: No module named xen.xm

# xl list
libxl: error: libxl.c:87:libxl_ctx_alloc: Is xenstore daemon running?
failed to stat /var/run/xenstored.pid: No such file or directory
cannot init xl context

# service xen start
Not running within Xen or no compatible utils ... (warning).

Doesn't seem to work terribly well, and I cannot find any instructions 
on how to fix those problems.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 10 15:09:17 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Sep 2012 15:09:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TB5ba-0002xz-Q5; Mon, 10 Sep 2012 15:08:54 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mathias.gaunard@ens-lyon.org>) id 1TB5bZ-0002xr-Ft
	for xen-devel@lists.xen.org; Mon, 10 Sep 2012 15:08:53 +0000
Received: from [85.158.138.51:56129] by server-10.bemta-3.messagelabs.com id
	6D/7E-10411-4820E405; Mon, 10 Sep 2012 15:08:52 +0000
X-Env-Sender: mathias.gaunard@ens-lyon.org
X-Msg-Ref: server-13.tower-174.messagelabs.com!1347289732!11047322!1
X-Originating-IP: [46.105.75.36]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24743 invoked from network); 10 Sep 2012 15:08:52 -0000
Received: from 2.mo3.mail-out.ovh.net (HELO mo3.mail-out.ovh.net)
	(46.105.75.36) by server-13.tower-174.messagelabs.com with SMTP;
	10 Sep 2012 15:08:52 -0000
Received: from mail96.ha.ovh.net (b6.ovh.net [213.186.33.56])
	by mo3.mail-out.ovh.net (Postfix) with SMTP id F217AFF8BB7
	for <xen-devel@lists.xen.org>; Mon, 10 Sep 2012 17:16:40 +0200 (CEST)
Received: from b0.ovh.net (HELO queueout) (213.186.33.50)
	by b0.ovh.net with SMTP; 10 Sep 2012 17:08:51 +0200
Received: from unknown (HELO ?192.168.27.237?)
	(mathias@gaunard.com@193.55.24.4)
	by ns0.ovh.net with SMTP; 10 Sep 2012 17:08:50 +0200
Message-ID: <504E0282.5020701@ens-lyon.org>
Date: Mon, 10 Sep 2012 17:08:50 +0200
From: Mathias Gaunard <mathias.gaunard@ens-lyon.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120827 Thunderbird/15.0
MIME-Version: 1.0
To: xen-devel@lists.xen.org
X-Ovh-Mailout: 178.32.228.3 (mo3.mail-out.ovh.net)
X-Ovh-Tracer-Id: 180706936576475687
X-Ovh-Remote: 193.55.24.4 ()
X-Ovh-Local: 213.186.33.20 (ns0.ovh.net)
X-OVH-SPAMSTATE: OK
X-OVH-SPAMSCORE: 0
X-OVH-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrfeehtddrheegucetufdoteggodetrfcurfhrohhfihhlvgemucfqggfjnecuuegrihhlohhuthemuceftddtnecunecuhfhrohhmpeforghthhhirghsucfirghunhgrrhguuceomhgrthhhihgrshdrghgruhhnrghrugesvghnshdqlhihohhnrdhorhhgqeenucffohhmrghinhepgigvnhdrohhrghenucfjughrpefkfffhfgggvffutgfgsehtjegrtddtfedu
X-Spam-Check: DONE|U 0.5/N
X-VR-SPAMSTATE: OK
X-VR-SPAMSCORE: 0
X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrfeehtddrheegucetufdoteggodetrfcurfhrohhfihhlvgemucfqggfjnecuuegrihhlohhuthemuceftddtnecunecuhfhrohhmpeforghthhhirghsucfirghunhgrrhguuceomhgrthhhihgrshdrghgruhhnrghrugesvghnshdqlhihohhnrdhorhhgqeenucffohhmrghinhepgigvnhdrohhrghenucfjughrpefkfffhfgggvffutgfgsehtjegrtddtfedu
Subject: [Xen-devel] Xen 4.2 RC4 test on Debian
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
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, I tried to install Xen 4.2 RC4 on Debian Wheezy.

I followed the instructions here:
<http://wiki.xen.org/wiki/Xen_4.2_RC2_test_instructions>

./configure
make world
make deb

then sudo dpkg -i --force-overwrite dist/xen-upstream-4.2.0-rc4.deb

I used --force-overwrite so that I didn't have to uninstall my 
libxenstore package on which several other things depend.

then sudo update-grub

I rebooted and selected Xen 4.2

# xm
Traceback (most recent call last):
   File "/usr/sbin/xm", line 5, in <module>
     from xen.xm import main
ImportError: No module named xen.xm

# xl list
libxl: error: libxl.c:87:libxl_ctx_alloc: Is xenstore daemon running?
failed to stat /var/run/xenstored.pid: No such file or directory
cannot init xl context

# service xen start
Not running within Xen or no compatible utils ... (warning).

Doesn't seem to work terribly well, and I cannot find any instructions 
on how to fix those problems.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 10 15:25:09 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Sep 2012 15:25:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TB5qx-0003XP-UR; Mon, 10 Sep 2012 15:24:47 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1TB5qx-0003XK-5m
	for xen-devel@lists.xen.org; Mon, 10 Sep 2012 15:24:47 +0000
Received: from [85.158.138.51:61268] by server-4.bemta-3.messagelabs.com id
	34/64-24831-E360E405; Mon, 10 Sep 2012 15:24:46 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1347290636!29638942!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTIyODk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18764 invoked from network); 10 Sep 2012 15:23:57 -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;
	10 Sep 2012 15:23:57 -0000
X-IronPort-AV: E=Sophos;i="4.80,398,1344211200"; d="scan'208";a="14447982"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Sep 2012 15:23: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.279.1;
	Mon, 10 Sep 2012 16:23:56 +0100
Message-ID: <1347290635.5305.108.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Mathias Gaunard <mathias.gaunard@ens-lyon.org>
Date: Mon, 10 Sep 2012 16:23:55 +0100
In-Reply-To: <504E0282.5020701@ens-lyon.org>
References: <504E0282.5020701@ens-lyon.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.2 RC4 test on Debian
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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-09-10 at 16:08 +0100, Mathias Gaunard wrote:
> Hi, I tried to install Xen 4.2 RC4 on Debian Wheezy.
> 
> I followed the instructions here:
> <http://wiki.xen.org/wiki/Xen_4.2_RC2_test_instructions>
> 
> ./configure
> make world
> make deb
> 
> then sudo dpkg -i --force-overwrite dist/xen-upstream-4.2.0-rc4.deb
> 
> I used --force-overwrite so that I didn't have to uninstall my 
> libxenstore package on which several other things depend.
> 
> then sudo update-grub
> 
> I rebooted and selected Xen 4.2
> 
> # xm
> Traceback (most recent call last):
>    File "/usr/sbin/xm", line 5, in <module>
>      from xen.xm import main
> ImportError: No module named xen.xm
> 
> # xl list
> libxl: error: libxl.c:87:libxl_ctx_alloc: Is xenstore daemon running?
> failed to stat /var/run/xenstored.pid: No such file or directory
> cannot init xl context
> 
> # service xen start
> Not running within Xen or no compatible utils ... (warning).

The xen initscript is part of the Debian packaging, which is leftover
due to your use of force above.

The xen supplied script is called "xencommons".

> Doesn't seem to work terribly well, and I cannot find any instructions 
> on how to fix those problems.

I suspect they mostly stem from you forcing the package manager to do
something it didn't want to.

I'm afraid that bug reports arising from a system which has had this
done to it are of rather low value.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 10 15:25:09 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Sep 2012 15:25:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TB5qx-0003XP-UR; Mon, 10 Sep 2012 15:24:47 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1TB5qx-0003XK-5m
	for xen-devel@lists.xen.org; Mon, 10 Sep 2012 15:24:47 +0000
Received: from [85.158.138.51:61268] by server-4.bemta-3.messagelabs.com id
	34/64-24831-E360E405; Mon, 10 Sep 2012 15:24:46 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1347290636!29638942!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTIyODk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18764 invoked from network); 10 Sep 2012 15:23:57 -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;
	10 Sep 2012 15:23:57 -0000
X-IronPort-AV: E=Sophos;i="4.80,398,1344211200"; d="scan'208";a="14447982"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Sep 2012 15:23: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.279.1;
	Mon, 10 Sep 2012 16:23:56 +0100
Message-ID: <1347290635.5305.108.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Mathias Gaunard <mathias.gaunard@ens-lyon.org>
Date: Mon, 10 Sep 2012 16:23:55 +0100
In-Reply-To: <504E0282.5020701@ens-lyon.org>
References: <504E0282.5020701@ens-lyon.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.2 RC4 test on Debian
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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-09-10 at 16:08 +0100, Mathias Gaunard wrote:
> Hi, I tried to install Xen 4.2 RC4 on Debian Wheezy.
> 
> I followed the instructions here:
> <http://wiki.xen.org/wiki/Xen_4.2_RC2_test_instructions>
> 
> ./configure
> make world
> make deb
> 
> then sudo dpkg -i --force-overwrite dist/xen-upstream-4.2.0-rc4.deb
> 
> I used --force-overwrite so that I didn't have to uninstall my 
> libxenstore package on which several other things depend.
> 
> then sudo update-grub
> 
> I rebooted and selected Xen 4.2
> 
> # xm
> Traceback (most recent call last):
>    File "/usr/sbin/xm", line 5, in <module>
>      from xen.xm import main
> ImportError: No module named xen.xm
> 
> # xl list
> libxl: error: libxl.c:87:libxl_ctx_alloc: Is xenstore daemon running?
> failed to stat /var/run/xenstored.pid: No such file or directory
> cannot init xl context
> 
> # service xen start
> Not running within Xen or no compatible utils ... (warning).

The xen initscript is part of the Debian packaging, which is leftover
due to your use of force above.

The xen supplied script is called "xencommons".

> Doesn't seem to work terribly well, and I cannot find any instructions 
> on how to fix those problems.

I suspect they mostly stem from you forcing the package manager to do
something it didn't want to.

I'm afraid that bug reports arising from a system which has had this
done to it are of rather low value.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 10 15:30:59 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Sep 2012 15: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 1TB5we-0003ha-S3; Mon, 10 Sep 2012 15:30: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 1TB5wd-0003hU-R3
	for xen-devel@lists.xen.org; Mon, 10 Sep 2012 15:30:40 +0000
Received: from [85.158.143.35:37910] by server-2.bemta-4.messagelabs.com id
	D3/80-21239-F970E405; Mon, 10 Sep 2012 15:30:39 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1347290965!17540519!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTIyODk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25864 invoked from network); 10 Sep 2012 15:29:41 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Sep 2012 15:29:41 -0000
X-IronPort-AV: E=Sophos;i="4.80,398,1344211200"; d="scan'208";a="14448087"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Sep 2012 15:29: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.279.1; Mon, 10 Sep 2012 16:29: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
	1TB5v8-0005ZL-SD; Mon, 10 Sep 2012 15:29:06 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1TB5v8-0005JL-OL;
	Mon, 10 Sep 2012 16:29:06 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20558.1858.645143.929250@mariner.uk.xensource.com>
Date: Mon, 10 Sep 2012 16:29:06 +0100
To: xen-devel@lists.xen.org,
    ian.campbell@eu.citrix.com
In-Reply-To: <20557.62949.300788.804976@mariner.uk.xensource.com>
References: <20544.39460.499127.781598@mariner.uk.xensource.com>
	<20557.62949.300788.804976@mariner.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Subject: Re: [Xen-devel] Test report: Migration from 4.1 to 4.2 works
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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: Test report: Migration from 4.1 to 4.2 works"):
> Migration 4.1 xend -> 4.2 xl, plan A:
>   Stop xend, use xl to do the migration.
> 
>   Fails:
> 
>   xc: Saving memory: iter 1 (last sent 134144 skipped 1553): 0/1048576
>   0%xc: error: Failed to allocate memory for batch.!: Internal error
> 
>   (XEN) page_alloc.c:1284:d0 Over-allocation for domain 23: 131329 > 131328
>   (XEN) memory.c:131:d0 Could not allocate order=0 extent: id=23 memflags=0 (288 of 472)

This works if I create a guest config file with a bigger "memory="
value, and pass that to xl migrate -C.

I can also do the migration successfully by migrating the domain to
the new host with xend, and then stopping xend on the target host.
After that an "xl migrate localhost" again works if the config file
I supply with -C (which is mandatory since xend didn't write one) has
an increased memory= value.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 10 15:30:59 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Sep 2012 15: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 1TB5we-0003ha-S3; Mon, 10 Sep 2012 15:30: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 1TB5wd-0003hU-R3
	for xen-devel@lists.xen.org; Mon, 10 Sep 2012 15:30:40 +0000
Received: from [85.158.143.35:37910] by server-2.bemta-4.messagelabs.com id
	D3/80-21239-F970E405; Mon, 10 Sep 2012 15:30:39 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1347290965!17540519!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTIyODk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25864 invoked from network); 10 Sep 2012 15:29:41 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Sep 2012 15:29:41 -0000
X-IronPort-AV: E=Sophos;i="4.80,398,1344211200"; d="scan'208";a="14448087"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Sep 2012 15:29: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.279.1; Mon, 10 Sep 2012 16:29: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
	1TB5v8-0005ZL-SD; Mon, 10 Sep 2012 15:29:06 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1TB5v8-0005JL-OL;
	Mon, 10 Sep 2012 16:29:06 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20558.1858.645143.929250@mariner.uk.xensource.com>
Date: Mon, 10 Sep 2012 16:29:06 +0100
To: xen-devel@lists.xen.org,
    ian.campbell@eu.citrix.com
In-Reply-To: <20557.62949.300788.804976@mariner.uk.xensource.com>
References: <20544.39460.499127.781598@mariner.uk.xensource.com>
	<20557.62949.300788.804976@mariner.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Subject: Re: [Xen-devel] Test report: Migration from 4.1 to 4.2 works
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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: Test report: Migration from 4.1 to 4.2 works"):
> Migration 4.1 xend -> 4.2 xl, plan A:
>   Stop xend, use xl to do the migration.
> 
>   Fails:
> 
>   xc: Saving memory: iter 1 (last sent 134144 skipped 1553): 0/1048576
>   0%xc: error: Failed to allocate memory for batch.!: Internal error
> 
>   (XEN) page_alloc.c:1284:d0 Over-allocation for domain 23: 131329 > 131328
>   (XEN) memory.c:131:d0 Could not allocate order=0 extent: id=23 memflags=0 (288 of 472)

This works if I create a guest config file with a bigger "memory="
value, and pass that to xl migrate -C.

I can also do the migration successfully by migrating the domain to
the new host with xend, and then stopping xend on the target host.
After that an "xl migrate localhost" again works if the config file
I supply with -C (which is mandatory since xend didn't write one) has
an increased memory= value.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 10 15:55:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Sep 2012 15:55:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TB6KZ-0003wt-0m; Mon, 10 Sep 2012 15:55:23 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <mathias.gaunard@ens-lyon.org>) id 1TB6KX-0003wo-UQ
	for xen-devel@lists.xen.org; Mon, 10 Sep 2012 15:55:22 +0000
X-Env-Sender: mathias.gaunard@ens-lyon.org
X-Msg-Ref: server-16.tower-27.messagelabs.com!1347292515!8985092!1
X-Originating-IP: [188.165.33.202]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22962 invoked from network); 10 Sep 2012 15:55:15 -0000
Received: from 13.mo3.mail-out.ovh.net (HELO mo3.mail-out.ovh.net)
	(188.165.33.202) by server-16.tower-27.messagelabs.com with SMTP;
	10 Sep 2012 15:55:15 -0000
Received: from mail96.ha.ovh.net (b6.ovh.net [213.186.33.56])
	by mo3.mail-out.ovh.net (Postfix) with SMTP id 15264FF8FF7
	for <xen-devel@lists.xen.org>; Mon, 10 Sep 2012 18:03:04 +0200 (CEST)
Received: from b0.ovh.net (HELO queueout) (213.186.33.50)
	by b0.ovh.net with SMTP; 10 Sep 2012 17:55:14 +0200
Received: from unknown (HELO ?192.168.27.237?)
	(mathias@gaunard.com@193.55.24.4)
	by ns0.ovh.net with SMTP; 10 Sep 2012 17:55:10 +0200
Message-ID: <504E0D5D.4030600@ens-lyon.org>
Date: Mon, 10 Sep 2012 17:55:09 +0200
From: Mathias Gaunard <mathias.gaunard@ens-lyon.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120827 Thunderbird/15.0
MIME-Version: 1.0
To: xen-devel@lists.xen.org
X-Ovh-Mailout: 178.32.228.3 (mo3.mail-out.ovh.net)
References: <504E0282.5020701@ens-lyon.org>
	<1347290635.5305.108.camel@zakaz.uk.xensource.com>
In-Reply-To: <1347290635.5305.108.camel@zakaz.uk.xensource.com>
X-Ovh-Tracer-Id: 963207370726638119
X-Ovh-Remote: 193.55.24.4 ()
X-Ovh-Local: 213.186.33.20 (ns0.ovh.net)
X-OVH-SPAMSTATE: OK
X-OVH-SPAMSCORE: 0
X-OVH-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrfeehtddrheegucetufdoteggodetrfcurfhrohhfihhlvgemucfqggfjnecuuegrihhlohhuthemuceftddtnecunecuhfhrohhmpeforghthhhirghsucfirghunhgrrhguuceomhgrthhhihgrshdrghgruhhnrghrugesvghnshdqlhihohhnrdhorhhgqeenucfjughrpefkfffhfgggvffufhgjtgfgsehtjegrtddtfedu
X-Spam-Check: DONE|U 0.5/N
X-VR-SPAMSTATE: OK
X-VR-SPAMSCORE: 0
X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrfeehtddrheegucetufdoteggodetrfcurfhrohhfihhlvgemucfqggfjnecuuegrihhlohhuthemuceftddtnecunecuhfhrohhmpeforghthhhirghsucfirghunhgrrhguuceomhgrthhhihgrshdrghgruhhnrghrugesvghnshdqlhihohhnrdhorhhgqeenucfjughrpefkfffhfgggvffufhgjtgfgsehtjegrtddtfedu
Subject: Re: [Xen-devel] Xen 4.2 RC4 test on Debian
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 09/10/2012 05:23 PM, Ian Campbell wrote:

>> # service xen start
>> Not running within Xen or no compatible utils ... (warning).
>
> The xen initscript is part of the Debian packaging, which is leftover
> due to your use of force above.

It's part of xen-utils-common, which is not installed on my system anymore.

I used to have xen from the debian repositories installed, which I 
uninstalled as the instructions said. It's possible it didn't remove all 
files.

In any case, I fixed the Python path problem and starting with 
xencommons works correctly.

One of my VMs has however disappeared. The others migrated successfully.

>
> The xen supplied script is called "xencommons".
>
>> Doesn't seem to work terribly well, and I cannot find any instructions
>> on how to fix those problems.
>
> I suspect they mostly stem from you forcing the package manager to do
> something it didn't want to.

I only forced it to erase /usr/lib/libxenstore.so.3.0.0


> I'm afraid that bug reports arising from a system which has had this
> done to it are of rather low value.

This is not a bug report. Just a user trying to use what will likely 
become a release.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 10 15:55:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Sep 2012 15:55:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TB6KZ-0003wt-0m; Mon, 10 Sep 2012 15:55:23 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <mathias.gaunard@ens-lyon.org>) id 1TB6KX-0003wo-UQ
	for xen-devel@lists.xen.org; Mon, 10 Sep 2012 15:55:22 +0000
X-Env-Sender: mathias.gaunard@ens-lyon.org
X-Msg-Ref: server-16.tower-27.messagelabs.com!1347292515!8985092!1
X-Originating-IP: [188.165.33.202]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22962 invoked from network); 10 Sep 2012 15:55:15 -0000
Received: from 13.mo3.mail-out.ovh.net (HELO mo3.mail-out.ovh.net)
	(188.165.33.202) by server-16.tower-27.messagelabs.com with SMTP;
	10 Sep 2012 15:55:15 -0000
Received: from mail96.ha.ovh.net (b6.ovh.net [213.186.33.56])
	by mo3.mail-out.ovh.net (Postfix) with SMTP id 15264FF8FF7
	for <xen-devel@lists.xen.org>; Mon, 10 Sep 2012 18:03:04 +0200 (CEST)
Received: from b0.ovh.net (HELO queueout) (213.186.33.50)
	by b0.ovh.net with SMTP; 10 Sep 2012 17:55:14 +0200
Received: from unknown (HELO ?192.168.27.237?)
	(mathias@gaunard.com@193.55.24.4)
	by ns0.ovh.net with SMTP; 10 Sep 2012 17:55:10 +0200
Message-ID: <504E0D5D.4030600@ens-lyon.org>
Date: Mon, 10 Sep 2012 17:55:09 +0200
From: Mathias Gaunard <mathias.gaunard@ens-lyon.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120827 Thunderbird/15.0
MIME-Version: 1.0
To: xen-devel@lists.xen.org
X-Ovh-Mailout: 178.32.228.3 (mo3.mail-out.ovh.net)
References: <504E0282.5020701@ens-lyon.org>
	<1347290635.5305.108.camel@zakaz.uk.xensource.com>
In-Reply-To: <1347290635.5305.108.camel@zakaz.uk.xensource.com>
X-Ovh-Tracer-Id: 963207370726638119
X-Ovh-Remote: 193.55.24.4 ()
X-Ovh-Local: 213.186.33.20 (ns0.ovh.net)
X-OVH-SPAMSTATE: OK
X-OVH-SPAMSCORE: 0
X-OVH-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrfeehtddrheegucetufdoteggodetrfcurfhrohhfihhlvgemucfqggfjnecuuegrihhlohhuthemuceftddtnecunecuhfhrohhmpeforghthhhirghsucfirghunhgrrhguuceomhgrthhhihgrshdrghgruhhnrghrugesvghnshdqlhihohhnrdhorhhgqeenucfjughrpefkfffhfgggvffufhgjtgfgsehtjegrtddtfedu
X-Spam-Check: DONE|U 0.5/N
X-VR-SPAMSTATE: OK
X-VR-SPAMSCORE: 0
X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrfeehtddrheegucetufdoteggodetrfcurfhrohhfihhlvgemucfqggfjnecuuegrihhlohhuthemuceftddtnecunecuhfhrohhmpeforghthhhirghsucfirghunhgrrhguuceomhgrthhhihgrshdrghgruhhnrghrugesvghnshdqlhihohhnrdhorhhgqeenucfjughrpefkfffhfgggvffufhgjtgfgsehtjegrtddtfedu
Subject: Re: [Xen-devel] Xen 4.2 RC4 test on Debian
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 09/10/2012 05:23 PM, Ian Campbell wrote:

>> # service xen start
>> Not running within Xen or no compatible utils ... (warning).
>
> The xen initscript is part of the Debian packaging, which is leftover
> due to your use of force above.

It's part of xen-utils-common, which is not installed on my system anymore.

I used to have xen from the debian repositories installed, which I 
uninstalled as the instructions said. It's possible it didn't remove all 
files.

In any case, I fixed the Python path problem and starting with 
xencommons works correctly.

One of my VMs has however disappeared. The others migrated successfully.

>
> The xen supplied script is called "xencommons".
>
>> Doesn't seem to work terribly well, and I cannot find any instructions
>> on how to fix those problems.
>
> I suspect they mostly stem from you forcing the package manager to do
> something it didn't want to.

I only forced it to erase /usr/lib/libxenstore.so.3.0.0


> I'm afraid that bug reports arising from a system which has had this
> done to it are of rather low value.

This is not a bug report. Just a user trying to use what will likely 
become a release.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 10 16:04:09 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Sep 2012 16:04: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 1TB6Sk-0004Z5-0s; Mon, 10 Sep 2012 16:03:50 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1TB6Sh-0004Z0-VH
	for xen-devel@lists.xen.org; Mon, 10 Sep 2012 16:03:48 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1347293021!10412469!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTIyODk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23082 invoked from network); 10 Sep 2012 16:03:41 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Sep 2012 16:03:41 -0000
X-IronPort-AV: E=Sophos;i="4.80,398,1344211200"; d="scan'208";a="14449081"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Sep 2012 16:03: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.279.1; Mon, 10 Sep 2012 17:03:24 +0100
Date: Mon, 10 Sep 2012 17:02:44 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: "Xu, Dongxiao" <dongxiao.xu@intel.com>
In-Reply-To: <40776A41FC278F40B59438AD47D147A90FE33BC3@SHSMSX102.ccr.corp.intel.com>
Message-ID: <alpine.DEB.2.02.1209101701290.15568@kaball.uk.xensource.com>
References: <40776A41FC278F40B59438AD47D147A90FE17D93@SHSMSX102.ccr.corp.intel.com>
	<alpine.DEB.2.02.1208201621330.15568@kaball.uk.xensource.com>
	<40776A41FC278F40B59438AD47D147A90FE1D78C@SHSMSX102.ccr.corp.intel.com>
	<alpine.DEB.2.02.1208241220400.15568@kaball.uk.xensource.com>
	<40776A41FC278F40B59438AD47D147A90FE1F771@SHSMSX102.ccr.corp.intel.com>
	<alpine.DEB.2.02.1208271812020.15568@kaball.uk.xensource.com>
	<40776A41FC278F40B59438AD47D147A90FE33BC3@SHSMSX102.ccr.corp.intel.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: "Keir \(Xen.org\)" <keir@xen.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, "Dugger,
	Donald D" <donald.d.dugger@intel.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH v2] QEMU/helper2.c: Fix multiply issue for
 int and uint types
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 10 Sep 2012, Xu, Dongxiao wrote:
> > -----Original Message-----
> > From: Xu, Dongxiao
> > Sent: Wednesday, September 05, 2012 11:01 AM
> > To: Stefano Stabellini
> > Cc: Keir (Xen.org); Jan Beulich; Ian Jackson; xen-devel@lists.xen.org
> > Subject: RE: [Xen-devel] [PATCH v2] QEMU/helper2.c: Fix multiply issue for int
> > and uint types
> > 
> > > On Mon, 27 Aug 2012, Xu, Dongxiao wrote:
> > > > > -----Original Message-----
> > > > > From: Stefano Stabellini [mailto:stefano.stabellini@eu.citrix.com]
> > > > > Sent: Friday, August 24, 2012 7:25 PM
> > > > > To: Xu, Dongxiao
> > > > > Cc: Stefano Stabellini; Keir (Xen.org); Jan Beulich; Ian Jackson;
> > > > > xen-devel@lists.xen.org
> > > > > Subject: RE: [Xen-devel] [PATCH v2] QEMU/helper2.c: Fix multiply
> > > > > issue for int and uint types
> > > > >
> > > > >
> > > > > I can only speak for qemu-upstream-unstable, but I'll certainly
> > > > > backport the int/uint fix as soon as it gets accepted in QEMU upstream.
> > > > >
> > > > > Regarding the other patches, if any of them are for
> > > > > qemu-upstream-unstable, I am going to backport them only if they
> > > > > are
> > > bugfixes.
> > > >
> > > > It seems that the int/uint patch is already merged by Anthony L, see
> > > > commit
> > > b100fcfe4966aa41d4d6908d0c4c510bcf8f82dd.
> > >
> > > Thanks for letting me know.
> > > I am current away on a conference but I'll try to get the backport
> > > done by the end of the week nonetheless.
> > 
> > Hi Stefano,
> > 
> > It seems that the patch is still not in qemu-xen repo, could you help to backport
> > it?
> 
> I saw both Xen and qemu-xen are tagged as RC4, however this fix is still not there. 
> 
> Without this fix, I think L1 Xen could not boot on L0 Xen successfully.

The patch is now in staging/qemu-upstream-unstable.git.
Sorry for the delay.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 10 16:04:09 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Sep 2012 16:04: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 1TB6Sk-0004Z5-0s; Mon, 10 Sep 2012 16:03:50 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1TB6Sh-0004Z0-VH
	for xen-devel@lists.xen.org; Mon, 10 Sep 2012 16:03:48 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1347293021!10412469!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTIyODk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23082 invoked from network); 10 Sep 2012 16:03:41 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Sep 2012 16:03:41 -0000
X-IronPort-AV: E=Sophos;i="4.80,398,1344211200"; d="scan'208";a="14449081"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Sep 2012 16:03: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.279.1; Mon, 10 Sep 2012 17:03:24 +0100
Date: Mon, 10 Sep 2012 17:02:44 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: "Xu, Dongxiao" <dongxiao.xu@intel.com>
In-Reply-To: <40776A41FC278F40B59438AD47D147A90FE33BC3@SHSMSX102.ccr.corp.intel.com>
Message-ID: <alpine.DEB.2.02.1209101701290.15568@kaball.uk.xensource.com>
References: <40776A41FC278F40B59438AD47D147A90FE17D93@SHSMSX102.ccr.corp.intel.com>
	<alpine.DEB.2.02.1208201621330.15568@kaball.uk.xensource.com>
	<40776A41FC278F40B59438AD47D147A90FE1D78C@SHSMSX102.ccr.corp.intel.com>
	<alpine.DEB.2.02.1208241220400.15568@kaball.uk.xensource.com>
	<40776A41FC278F40B59438AD47D147A90FE1F771@SHSMSX102.ccr.corp.intel.com>
	<alpine.DEB.2.02.1208271812020.15568@kaball.uk.xensource.com>
	<40776A41FC278F40B59438AD47D147A90FE33BC3@SHSMSX102.ccr.corp.intel.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: "Keir \(Xen.org\)" <keir@xen.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, "Dugger,
	Donald D" <donald.d.dugger@intel.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH v2] QEMU/helper2.c: Fix multiply issue for
 int and uint types
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 10 Sep 2012, Xu, Dongxiao wrote:
> > -----Original Message-----
> > From: Xu, Dongxiao
> > Sent: Wednesday, September 05, 2012 11:01 AM
> > To: Stefano Stabellini
> > Cc: Keir (Xen.org); Jan Beulich; Ian Jackson; xen-devel@lists.xen.org
> > Subject: RE: [Xen-devel] [PATCH v2] QEMU/helper2.c: Fix multiply issue for int
> > and uint types
> > 
> > > On Mon, 27 Aug 2012, Xu, Dongxiao wrote:
> > > > > -----Original Message-----
> > > > > From: Stefano Stabellini [mailto:stefano.stabellini@eu.citrix.com]
> > > > > Sent: Friday, August 24, 2012 7:25 PM
> > > > > To: Xu, Dongxiao
> > > > > Cc: Stefano Stabellini; Keir (Xen.org); Jan Beulich; Ian Jackson;
> > > > > xen-devel@lists.xen.org
> > > > > Subject: RE: [Xen-devel] [PATCH v2] QEMU/helper2.c: Fix multiply
> > > > > issue for int and uint types
> > > > >
> > > > >
> > > > > I can only speak for qemu-upstream-unstable, but I'll certainly
> > > > > backport the int/uint fix as soon as it gets accepted in QEMU upstream.
> > > > >
> > > > > Regarding the other patches, if any of them are for
> > > > > qemu-upstream-unstable, I am going to backport them only if they
> > > > > are
> > > bugfixes.
> > > >
> > > > It seems that the int/uint patch is already merged by Anthony L, see
> > > > commit
> > > b100fcfe4966aa41d4d6908d0c4c510bcf8f82dd.
> > >
> > > Thanks for letting me know.
> > > I am current away on a conference but I'll try to get the backport
> > > done by the end of the week nonetheless.
> > 
> > Hi Stefano,
> > 
> > It seems that the patch is still not in qemu-xen repo, could you help to backport
> > it?
> 
> I saw both Xen and qemu-xen are tagged as RC4, however this fix is still not there. 
> 
> Without this fix, I think L1 Xen could not boot on L0 Xen successfully.

The patch is now in staging/qemu-upstream-unstable.git.
Sorry for the delay.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 10 16:06:35 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Sep 2012 16: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 1TB6V9-0004eS-IZ; Mon, 10 Sep 2012 16:06:19 +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 1TB6V7-0004eD-Vp
	for xen-devel@lists.xen.org; Mon, 10 Sep 2012 16:06:18 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1347293164!10421223!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTIyODk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16053 invoked from network); 10 Sep 2012 16:06:04 -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;
	10 Sep 2012 16:06:04 -0000
X-IronPort-AV: E=Sophos;i="4.80,398,1344211200"; d="scan'208";a="14449123"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Sep 2012 16:06: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.279.1;
	Mon, 10 Sep 2012 17:06:04 +0100
Message-ID: <1347293162.5305.111.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Mathias Gaunard <mathias.gaunard@ens-lyon.org>
Date: Mon, 10 Sep 2012 17:06:02 +0100
In-Reply-To: <504E0D5D.4030600@ens-lyon.org>
References: <504E0282.5020701@ens-lyon.org>
	<1347290635.5305.108.camel@zakaz.uk.xensource.com>
	<504E0D5D.4030600@ens-lyon.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.2 RC4 test on Debian
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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-09-10 at 16:55 +0100, Mathias Gaunard wrote:
> On 09/10/2012 05:23 PM, Ian Campbell wrote:
> 
> >> # service xen start
> >> Not running within Xen or no compatible utils ... (warning).
> >
> > The xen initscript is part of the Debian packaging, which is leftover
> > due to your use of force above.
> 
> It's part of xen-utils-common, which is not installed on my system anymore.

Did you purge it? On Debian conffiles (which includes initscripts) are
not removed when you remove a package, you need to purge a package to
get rid of everything.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 10 16:06:35 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Sep 2012 16: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 1TB6V9-0004eS-IZ; Mon, 10 Sep 2012 16:06:19 +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 1TB6V7-0004eD-Vp
	for xen-devel@lists.xen.org; Mon, 10 Sep 2012 16:06:18 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1347293164!10421223!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTIyODk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16053 invoked from network); 10 Sep 2012 16:06:04 -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;
	10 Sep 2012 16:06:04 -0000
X-IronPort-AV: E=Sophos;i="4.80,398,1344211200"; d="scan'208";a="14449123"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Sep 2012 16:06: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.279.1;
	Mon, 10 Sep 2012 17:06:04 +0100
Message-ID: <1347293162.5305.111.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Mathias Gaunard <mathias.gaunard@ens-lyon.org>
Date: Mon, 10 Sep 2012 17:06:02 +0100
In-Reply-To: <504E0D5D.4030600@ens-lyon.org>
References: <504E0282.5020701@ens-lyon.org>
	<1347290635.5305.108.camel@zakaz.uk.xensource.com>
	<504E0D5D.4030600@ens-lyon.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.2 RC4 test on Debian
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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-09-10 at 16:55 +0100, Mathias Gaunard wrote:
> On 09/10/2012 05:23 PM, Ian Campbell wrote:
> 
> >> # service xen start
> >> Not running within Xen or no compatible utils ... (warning).
> >
> > The xen initscript is part of the Debian packaging, which is leftover
> > due to your use of force above.
> 
> It's part of xen-utils-common, which is not installed on my system anymore.

Did you purge it? On Debian conffiles (which includes initscripts) are
not removed when you remove a package, you need to purge a package to
get rid of everything.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 10 16:09:30 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Sep 2012 16:09:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TB6Xy-0004mg-58; Mon, 10 Sep 2012 16:09: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 1TB6Xx-0004mZ-7O
	for xen-devel@lists.xen.org; Mon, 10 Sep 2012 16:09:13 +0000
Received: from [85.158.143.99:3224] by server-2.bemta-4.messagelabs.com id
	5D/5F-21239-8A01E405; Mon, 10 Sep 2012 16:09:12 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1347293352!19799621!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTIyODk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1740 invoked from network); 10 Sep 2012 16:09:12 -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 Sep 2012 16:09:12 -0000
X-IronPort-AV: E=Sophos;i="4.80,398,1344211200"; d="scan'208";a="14449288"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Sep 2012 16:09: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.279.1;
	Mon, 10 Sep 2012 17:09:12 +0100
Message-ID: <1347293350.5305.113.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Matt Wilson <msw@amazon.com>
Date: Mon, 10 Sep 2012 17:09:10 +0100
In-Reply-To: <3b3582f4dc423daa8040.1346992558@u002268147cd4502c336d.ant.amazon.com>
References: <patchbomb.1346992557@u002268147cd4502c336d.ant.amazon.com>
	<3b3582f4dc423daa8040.1346992558@u002268147cd4502c336d.ant.amazon.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 1 of 2 v3] tools: check for documentation
 generation tools at configure 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


> diff -r d7e4efa17fb0 -r 3b3582f4dc42 tools/m4/docs_tool.m4
> --- /dev/null	Thu Jan 01 00:00:00 1970 +0000
> +++ b/tools/m4/docs_tool.m4	Thu Sep 06 21:31:51 2012 -0700
> @@ -0,0 +1,10 @@
> +# $1: autoconf variable name
> +# $2: list of programs to check for
> +AC_DEFUN([AX_DOCS_TOOL_PROGS], [
> +dnl
> +    AC_ARG_VAR([$1], [Path to ] m4_tolower($1) [ tool])
> +    AC_PATH_PROGS([$1], [$2])
> +    AS_IF([! test -x "$ac_cv_path_$1"], [
> +        AC_MSG_WARN([$2 is not available so some documentation won't be built])

Did you mean m4_tolower($1) for this last $2 as well? Since $2 is the
list of potential command names this will look a bit odd I think?



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 10 16:09:30 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Sep 2012 16:09:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TB6Xy-0004mg-58; Mon, 10 Sep 2012 16:09: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 1TB6Xx-0004mZ-7O
	for xen-devel@lists.xen.org; Mon, 10 Sep 2012 16:09:13 +0000
Received: from [85.158.143.99:3224] by server-2.bemta-4.messagelabs.com id
	5D/5F-21239-8A01E405; Mon, 10 Sep 2012 16:09:12 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1347293352!19799621!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTIyODk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1740 invoked from network); 10 Sep 2012 16:09:12 -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 Sep 2012 16:09:12 -0000
X-IronPort-AV: E=Sophos;i="4.80,398,1344211200"; d="scan'208";a="14449288"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Sep 2012 16:09: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.279.1;
	Mon, 10 Sep 2012 17:09:12 +0100
Message-ID: <1347293350.5305.113.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Matt Wilson <msw@amazon.com>
Date: Mon, 10 Sep 2012 17:09:10 +0100
In-Reply-To: <3b3582f4dc423daa8040.1346992558@u002268147cd4502c336d.ant.amazon.com>
References: <patchbomb.1346992557@u002268147cd4502c336d.ant.amazon.com>
	<3b3582f4dc423daa8040.1346992558@u002268147cd4502c336d.ant.amazon.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 1 of 2 v3] tools: check for documentation
 generation tools at configure 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


> diff -r d7e4efa17fb0 -r 3b3582f4dc42 tools/m4/docs_tool.m4
> --- /dev/null	Thu Jan 01 00:00:00 1970 +0000
> +++ b/tools/m4/docs_tool.m4	Thu Sep 06 21:31:51 2012 -0700
> @@ -0,0 +1,10 @@
> +# $1: autoconf variable name
> +# $2: list of programs to check for
> +AC_DEFUN([AX_DOCS_TOOL_PROGS], [
> +dnl
> +    AC_ARG_VAR([$1], [Path to ] m4_tolower($1) [ tool])
> +    AC_PATH_PROGS([$1], [$2])
> +    AS_IF([! test -x "$ac_cv_path_$1"], [
> +        AC_MSG_WARN([$2 is not available so some documentation won't be built])

Did you mean m4_tolower($1) for this last $2 as well? Since $2 is the
list of potential command names this will look a bit odd I think?



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 10 16:11:10 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Sep 2012 16:11:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TB6Zb-0004tx-LV; Mon, 10 Sep 2012 16:10:55 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <bunkertor@tiscali.it>) id 1TB6ZZ-0004te-CD
	for xen-devel@lists.xen.org; Mon, 10 Sep 2012 16:10:53 +0000
X-Env-Sender: bunkertor@tiscali.it
X-Msg-Ref: server-12.tower-27.messagelabs.com!1347293403!10421873!1
X-Originating-IP: [213.205.33.246]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjEzLjIwNS4zMy4yNDYgPT4gMjYwNTc=\n,
	ML_RADAR_SPEW_LINKS_14,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28218 invoked from network); 10 Sep 2012 16:10:04 -0000
Received: from michael.mail.tiscali.it (HELO michael.mail.tiscali.it)
	(213.205.33.246) by server-12.tower-27.messagelabs.com with SMTP;
	10 Sep 2012 16:10:04 -0000
Received: from [172.16.1.180] ([78.13.188.52]) by michael.mail.tiscali.it with 
	id xUA31j00K18G0wm01UA3fH; Mon, 10 Sep 2012 18:10:03 +0200
Message-ID: <504E10DA.6040603@tiscali.it>
Date: Mon, 10 Sep 2012 18:10:02 +0200
From: bunkertor <bunkertor@tiscali.it>
User-Agent: Mozilla/5.0 (Windows NT 5.1;
	rv:11.0) Gecko/20120327 Thunderbird/11.0.1
MIME-Version: 1.0
To: xen-devel@lists.xen.org
Subject: [Xen-devel] grub error 28
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
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

i compiled by myself xen-unstable from hg repo (changeset:   
25835:c70d70d85306)
but i'm facing a problem when i try to boot with xen kernel: Error 28 
Selected item can not fit into memory.
i'm newbie and i cannot understand where i fail...

here's the error (bad...)

================================================================

[root@xen-02 xen-unstable]# grub
Probing devices to guess BIOS drives. This may take a long time.


     GNU GRUB  version 0.97  (640K lower / 3072K upper memory)

  [ Minimal BASH-like line editing is supported.  For the first word, TAB
    lists possible command completions.  Anywhere else TAB lists the 
possible
    completions of a device/filename.]
grub> root (hd0,0)
root (hd0,0)
  Filesystem type is ext2fs, partition type 0x83
grub> kernel /xen.gz
kernel /xen.gz
    [Multiboot-elf, <0x964000:0x1a6db8:0x54248>(bad)

Error 28: Selected item cannot fit into memory

================================================================

and here are my specs:

================================================================

[root@xen-02 xen-unstable]# uname -r
2.6.32-279.5.2.el6.x86_64
[root@xen-02 xen-unstable]# cat /etc/redhat-release
CentOS release 6.3 (Final)
[root@xen-02 xen-unstable]#
[root@xen-02 xen-unstable]# cat /proc/meminfo
MemTotal:       16029352 kB
MemFree:        15720112 kB
Buffers:           11488 kB
Cached:            47264 kB
SwapCached:            0 kB
Active:            23736 kB
Inactive:          40804 kB
Active(anon):       5924 kB
Inactive(anon):     5628 kB
Active(file):      17812 kB
Inactive(file):    35176 kB
Unevictable:           0 kB
Mlocked:               0 kB
SwapTotal:      32767992 kB
SwapFree:       32767992 kB
Dirty:                 0 kB
Writeback:             0 kB
AnonPages:          5776 kB
Mapped:             5768 kB
Shmem:              5764 kB
Slab:              36836 kB
SReclaimable:      10224 kB
SUnreclaim:        26612 kB
KernelStack:        1224 kB
PageTables:         1128 kB
NFS_Unstable:          0 kB
Bounce:                0 kB
WritebackTmp:          0 kB
CommitLimit:    40782668 kB
Committed_AS:      59656 kB
VmallocTotal:   34359738367 kB
VmallocUsed:      392120 kB
VmallocChunk:   34359341780 kB
HardwareCorrupted:     0 kB
AnonHugePages:         0 kB
HugePages_Total:       0
HugePages_Free:        0
HugePages_Rsvd:        0
HugePages_Surp:        0
Hugepagesize:       2048 kB
DirectMap4k:        8192 kB
DirectMap2M:    16480256 kB
[root@xen-02 xen-unstable]# cat /proc/cpuinfo
processor       : 0
vendor_id       : GenuineIntel
cpu family      : 6
model           : 42
model name      : Intel(R) Core(TM) i5-2400 CPU @ 3.10GHz
stepping        : 7
cpu MHz         : 3092.749
cache size      : 6144 KB
physical id     : 0
siblings        : 4
core id         : 0
cpu cores       : 4
apicid          : 0
initial apicid  : 0
fpu             : yes
fpu_exception   : yes
cpuid level     : 13
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca 
cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall 
nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good xtopology 
nonstop_tsc aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx smx est 
tm2 ssse3 cx16 xtpr pdcm sse4_1 sse4_2 x2apic popcnt aes xsave avx 
lahf_lm ida arat epb xsaveopt pln pts dts tpr_shadow vnmi flexpriority 
ept vpid
bogomips        : 6185.49
clflush size    : 64
cache_alignment : 64
address sizes   : 36 bits physical, 48 bits virtual
power management:
.....
.....

=================================================================

[root@xen-02 xen-unstable]# ls -lh /boot/
totale 247M
-rw-r--r--. 1 root root 100K 24 ago 03:31 config-2.6.32-279.5.2.el6.x86_64
-rw-r--r--. 1 root root 100K 22 giu 14:44 config-2.6.32-279.el6.x86_64
-rw-r--r--. 1 root root 114K  9 set 02:09 config-3.1.0-rc9
drwxr-xr-x. 3 root root 4,0K  9 set 00:16 efi
drwxr-xr-x. 2 root root 4,0K  9 set 12:11 grub
-rw-r--r--. 1 root root  23M  9 set 01:16 
initramfs-2.6.32-279.5.2.el6.x86_64.img
-rw-r--r--. 1 root root  23M  9 set 00:17 
initramfs-2.6.32-279.el6.x86_64.img
-rw-r--r--. 1 root root 154M  9 set 02:31 initramfs-3.1.0-rc9.img
drwx------. 2 root root  16K  9 set 00:13 lost+found
-rw-r--r--. 1 root root 176K 24 ago 03:32 
symvers-2.6.32-279.5.2.el6.x86_64.gz
-rw-r--r--. 1 root root 175K 22 giu 14:45 symvers-2.6.32-279.el6.x86_64.gz
-rw-r--r--. 1 root root 2,3M 24 ago 03:31 
System.map-2.6.32-279.5.2.el6.x86_64
-rw-r--r--. 1 root root 2,3M 22 giu 14:44 System.map-2.6.32-279.el6.x86_64
-rw-r--r--. 1 root root 2,4M  9 set 02:12 System.map-3.1.0-rc9
-rwxr-xr-x. 1 root root 3,9M 24 ago 03:31 vmlinuz-2.6.32-279.5.2.el6.x86_64
-rwxr-xr-x. 1 root root 3,9M 22 giu 14:44 vmlinuz-2.6.32-279.el6.x86_64
-rwxr-xr-x. 1 root root 3,9M  9 set 02:12 vmlinuz-3.1.0-rc9
-rw-r--r--. 1 root root 776K  9 set 11:42 xen-4.2.0-rc2.gz
-rw-r--r--. 1 root root 779K  9 set 01:01 xen-4.2.0-rc4-pre.gz
lrwxrwxrwx. 1 root root   16  9 set 11:42 xen-4.2.gz -> xen-4.2.0-rc2.gz
lrwxrwxrwx. 1 root root   16  9 set 11:42 xen-4.gz -> xen-4.2.0-rc2.gz
lrwxrwxrwx. 1 root root   16  9 set 11:42 xen.gz -> xen-4.2.0-rc2.gz
-rw-r--r--. 1 root root  13M  9 set 11:42 xen-syms-4.2.0-rc2
-rw-r--r--. 1 root root  14M  9 set 01:01 xen-syms-4.2.0-rc4-pre

=================================================================

title Xen 4.2.0-rc4-pre with linux 3.1.0-rc9 pvops
         root (hd0,0)
         kernel /xen.gz dom0_mem=2048M loglvl=all guest_loglvl=all
         module /vmlinuz-3.1.0-rc9 ro root=/dev/mapper/vg_xen02-LogVol00 
LANG=it_IT.UTF-8 rd_NO_LUKS  KEYBOARDTYPE=pc KEYTABLE=it rd_NO_MD 
rd_LVM_LV=vg_xen02/LogVol00 SYSFONT=latarcyrheb-sun16 crashkernel=auto 
rd_LVM_LV=vg_xen02/LogVol01 rd_NO_DM rhgb quiet nomodeset
         module /initramfs-3.1.0-rc9.img

=================================================================

[root@xen-02 xen-unstable]# dmesg | grep BIOS
BIOS-provided physical RAM map:
  BIOS-e820: 0000000000000000 - 000000000009ec00 (usable)
  BIOS-e820: 000000000009ec00 - 00000000000a0000 (reserved)
  BIOS-e820: 00000000000e0000 - 0000000000100000 (reserved)
  BIOS-e820: 0000000000100000 - 0000000020000000 (usable)
  BIOS-e820: 0000000020000000 - 0000000020200000 (reserved)
  BIOS-e820: 0000000020200000 - 0000000040000000 (usable)
  BIOS-e820: 0000000040000000 - 0000000040200000 (reserved)
  BIOS-e820: 0000000040200000 - 00000000cd86f000 (usable)
  BIOS-e820: 00000000cd86f000 - 00000000ce01a000 (reserved)
  BIOS-e820: 00000000ce01a000 - 00000000ce29a000 (ACPI NVS)
  BIOS-e820: 00000000ce29a000 - 00000000ce29f000 (ACPI data)
  BIOS-e820: 00000000ce29f000 - 00000000ce2e2000 (ACPI NVS)
  BIOS-e820: 00000000ce2e2000 - 00000000cec3f000 (usable)
  BIOS-e820: 00000000cec3f000 - 00000000ceff2000 (reserved)
  BIOS-e820: 00000000ceff2000 - 00000000cf000000 (usable)
  BIOS-e820: 00000000cf800000 - 00000000dfa00000 (reserved)
  BIOS-e820: 00000000f8000000 - 00000000fc000000 (reserved)
  BIOS-e820: 00000000fec00000 - 00000000fec01000 (reserved)
  BIOS-e820: 00000000fed00000 - 00000000fed04000 (reserved)
  BIOS-e820: 00000000fed1c000 - 00000000fed20000 (reserved)
  BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved)
  BIOS-e820: 00000000ff000000 - 0000000100000000 (reserved)
  BIOS-e820: 0000000100000000 - 000000041f600000 (usable)
SMBIOS version 2.7 @ 0xF0480
DMI: To Be Filled By O.E.M. To Be Filled By O.E.M./Z68 Extreme4, BIOS 
P2.20 06/29/2012
AMI BIOS detected: BIOS may corrupt low RAM, working around it.
   #0 [0000000000 - 0000001000]   BIOS data page ==> [0000000000 - 
0000001000]
   #4 [000009ec00 - 0000100000]    BIOS reserved ==> [000009ec00 - 
0000100000]
=================================================================

any help will be appreciated.
thanks in advance.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 10 16:11:10 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Sep 2012 16:11:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TB6Zb-0004tx-LV; Mon, 10 Sep 2012 16:10:55 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <bunkertor@tiscali.it>) id 1TB6ZZ-0004te-CD
	for xen-devel@lists.xen.org; Mon, 10 Sep 2012 16:10:53 +0000
X-Env-Sender: bunkertor@tiscali.it
X-Msg-Ref: server-12.tower-27.messagelabs.com!1347293403!10421873!1
X-Originating-IP: [213.205.33.246]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjEzLjIwNS4zMy4yNDYgPT4gMjYwNTc=\n,
	ML_RADAR_SPEW_LINKS_14,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28218 invoked from network); 10 Sep 2012 16:10:04 -0000
Received: from michael.mail.tiscali.it (HELO michael.mail.tiscali.it)
	(213.205.33.246) by server-12.tower-27.messagelabs.com with SMTP;
	10 Sep 2012 16:10:04 -0000
Received: from [172.16.1.180] ([78.13.188.52]) by michael.mail.tiscali.it with 
	id xUA31j00K18G0wm01UA3fH; Mon, 10 Sep 2012 18:10:03 +0200
Message-ID: <504E10DA.6040603@tiscali.it>
Date: Mon, 10 Sep 2012 18:10:02 +0200
From: bunkertor <bunkertor@tiscali.it>
User-Agent: Mozilla/5.0 (Windows NT 5.1;
	rv:11.0) Gecko/20120327 Thunderbird/11.0.1
MIME-Version: 1.0
To: xen-devel@lists.xen.org
Subject: [Xen-devel] grub error 28
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
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

i compiled by myself xen-unstable from hg repo (changeset:   
25835:c70d70d85306)
but i'm facing a problem when i try to boot with xen kernel: Error 28 
Selected item can not fit into memory.
i'm newbie and i cannot understand where i fail...

here's the error (bad...)

================================================================

[root@xen-02 xen-unstable]# grub
Probing devices to guess BIOS drives. This may take a long time.


     GNU GRUB  version 0.97  (640K lower / 3072K upper memory)

  [ Minimal BASH-like line editing is supported.  For the first word, TAB
    lists possible command completions.  Anywhere else TAB lists the 
possible
    completions of a device/filename.]
grub> root (hd0,0)
root (hd0,0)
  Filesystem type is ext2fs, partition type 0x83
grub> kernel /xen.gz
kernel /xen.gz
    [Multiboot-elf, <0x964000:0x1a6db8:0x54248>(bad)

Error 28: Selected item cannot fit into memory

================================================================

and here are my specs:

================================================================

[root@xen-02 xen-unstable]# uname -r
2.6.32-279.5.2.el6.x86_64
[root@xen-02 xen-unstable]# cat /etc/redhat-release
CentOS release 6.3 (Final)
[root@xen-02 xen-unstable]#
[root@xen-02 xen-unstable]# cat /proc/meminfo
MemTotal:       16029352 kB
MemFree:        15720112 kB
Buffers:           11488 kB
Cached:            47264 kB
SwapCached:            0 kB
Active:            23736 kB
Inactive:          40804 kB
Active(anon):       5924 kB
Inactive(anon):     5628 kB
Active(file):      17812 kB
Inactive(file):    35176 kB
Unevictable:           0 kB
Mlocked:               0 kB
SwapTotal:      32767992 kB
SwapFree:       32767992 kB
Dirty:                 0 kB
Writeback:             0 kB
AnonPages:          5776 kB
Mapped:             5768 kB
Shmem:              5764 kB
Slab:              36836 kB
SReclaimable:      10224 kB
SUnreclaim:        26612 kB
KernelStack:        1224 kB
PageTables:         1128 kB
NFS_Unstable:          0 kB
Bounce:                0 kB
WritebackTmp:          0 kB
CommitLimit:    40782668 kB
Committed_AS:      59656 kB
VmallocTotal:   34359738367 kB
VmallocUsed:      392120 kB
VmallocChunk:   34359341780 kB
HardwareCorrupted:     0 kB
AnonHugePages:         0 kB
HugePages_Total:       0
HugePages_Free:        0
HugePages_Rsvd:        0
HugePages_Surp:        0
Hugepagesize:       2048 kB
DirectMap4k:        8192 kB
DirectMap2M:    16480256 kB
[root@xen-02 xen-unstable]# cat /proc/cpuinfo
processor       : 0
vendor_id       : GenuineIntel
cpu family      : 6
model           : 42
model name      : Intel(R) Core(TM) i5-2400 CPU @ 3.10GHz
stepping        : 7
cpu MHz         : 3092.749
cache size      : 6144 KB
physical id     : 0
siblings        : 4
core id         : 0
cpu cores       : 4
apicid          : 0
initial apicid  : 0
fpu             : yes
fpu_exception   : yes
cpuid level     : 13
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca 
cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall 
nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good xtopology 
nonstop_tsc aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx smx est 
tm2 ssse3 cx16 xtpr pdcm sse4_1 sse4_2 x2apic popcnt aes xsave avx 
lahf_lm ida arat epb xsaveopt pln pts dts tpr_shadow vnmi flexpriority 
ept vpid
bogomips        : 6185.49
clflush size    : 64
cache_alignment : 64
address sizes   : 36 bits physical, 48 bits virtual
power management:
.....
.....

=================================================================

[root@xen-02 xen-unstable]# ls -lh /boot/
totale 247M
-rw-r--r--. 1 root root 100K 24 ago 03:31 config-2.6.32-279.5.2.el6.x86_64
-rw-r--r--. 1 root root 100K 22 giu 14:44 config-2.6.32-279.el6.x86_64
-rw-r--r--. 1 root root 114K  9 set 02:09 config-3.1.0-rc9
drwxr-xr-x. 3 root root 4,0K  9 set 00:16 efi
drwxr-xr-x. 2 root root 4,0K  9 set 12:11 grub
-rw-r--r--. 1 root root  23M  9 set 01:16 
initramfs-2.6.32-279.5.2.el6.x86_64.img
-rw-r--r--. 1 root root  23M  9 set 00:17 
initramfs-2.6.32-279.el6.x86_64.img
-rw-r--r--. 1 root root 154M  9 set 02:31 initramfs-3.1.0-rc9.img
drwx------. 2 root root  16K  9 set 00:13 lost+found
-rw-r--r--. 1 root root 176K 24 ago 03:32 
symvers-2.6.32-279.5.2.el6.x86_64.gz
-rw-r--r--. 1 root root 175K 22 giu 14:45 symvers-2.6.32-279.el6.x86_64.gz
-rw-r--r--. 1 root root 2,3M 24 ago 03:31 
System.map-2.6.32-279.5.2.el6.x86_64
-rw-r--r--. 1 root root 2,3M 22 giu 14:44 System.map-2.6.32-279.el6.x86_64
-rw-r--r--. 1 root root 2,4M  9 set 02:12 System.map-3.1.0-rc9
-rwxr-xr-x. 1 root root 3,9M 24 ago 03:31 vmlinuz-2.6.32-279.5.2.el6.x86_64
-rwxr-xr-x. 1 root root 3,9M 22 giu 14:44 vmlinuz-2.6.32-279.el6.x86_64
-rwxr-xr-x. 1 root root 3,9M  9 set 02:12 vmlinuz-3.1.0-rc9
-rw-r--r--. 1 root root 776K  9 set 11:42 xen-4.2.0-rc2.gz
-rw-r--r--. 1 root root 779K  9 set 01:01 xen-4.2.0-rc4-pre.gz
lrwxrwxrwx. 1 root root   16  9 set 11:42 xen-4.2.gz -> xen-4.2.0-rc2.gz
lrwxrwxrwx. 1 root root   16  9 set 11:42 xen-4.gz -> xen-4.2.0-rc2.gz
lrwxrwxrwx. 1 root root   16  9 set 11:42 xen.gz -> xen-4.2.0-rc2.gz
-rw-r--r--. 1 root root  13M  9 set 11:42 xen-syms-4.2.0-rc2
-rw-r--r--. 1 root root  14M  9 set 01:01 xen-syms-4.2.0-rc4-pre

=================================================================

title Xen 4.2.0-rc4-pre with linux 3.1.0-rc9 pvops
         root (hd0,0)
         kernel /xen.gz dom0_mem=2048M loglvl=all guest_loglvl=all
         module /vmlinuz-3.1.0-rc9 ro root=/dev/mapper/vg_xen02-LogVol00 
LANG=it_IT.UTF-8 rd_NO_LUKS  KEYBOARDTYPE=pc KEYTABLE=it rd_NO_MD 
rd_LVM_LV=vg_xen02/LogVol00 SYSFONT=latarcyrheb-sun16 crashkernel=auto 
rd_LVM_LV=vg_xen02/LogVol01 rd_NO_DM rhgb quiet nomodeset
         module /initramfs-3.1.0-rc9.img

=================================================================

[root@xen-02 xen-unstable]# dmesg | grep BIOS
BIOS-provided physical RAM map:
  BIOS-e820: 0000000000000000 - 000000000009ec00 (usable)
  BIOS-e820: 000000000009ec00 - 00000000000a0000 (reserved)
  BIOS-e820: 00000000000e0000 - 0000000000100000 (reserved)
  BIOS-e820: 0000000000100000 - 0000000020000000 (usable)
  BIOS-e820: 0000000020000000 - 0000000020200000 (reserved)
  BIOS-e820: 0000000020200000 - 0000000040000000 (usable)
  BIOS-e820: 0000000040000000 - 0000000040200000 (reserved)
  BIOS-e820: 0000000040200000 - 00000000cd86f000 (usable)
  BIOS-e820: 00000000cd86f000 - 00000000ce01a000 (reserved)
  BIOS-e820: 00000000ce01a000 - 00000000ce29a000 (ACPI NVS)
  BIOS-e820: 00000000ce29a000 - 00000000ce29f000 (ACPI data)
  BIOS-e820: 00000000ce29f000 - 00000000ce2e2000 (ACPI NVS)
  BIOS-e820: 00000000ce2e2000 - 00000000cec3f000 (usable)
  BIOS-e820: 00000000cec3f000 - 00000000ceff2000 (reserved)
  BIOS-e820: 00000000ceff2000 - 00000000cf000000 (usable)
  BIOS-e820: 00000000cf800000 - 00000000dfa00000 (reserved)
  BIOS-e820: 00000000f8000000 - 00000000fc000000 (reserved)
  BIOS-e820: 00000000fec00000 - 00000000fec01000 (reserved)
  BIOS-e820: 00000000fed00000 - 00000000fed04000 (reserved)
  BIOS-e820: 00000000fed1c000 - 00000000fed20000 (reserved)
  BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved)
  BIOS-e820: 00000000ff000000 - 0000000100000000 (reserved)
  BIOS-e820: 0000000100000000 - 000000041f600000 (usable)
SMBIOS version 2.7 @ 0xF0480
DMI: To Be Filled By O.E.M. To Be Filled By O.E.M./Z68 Extreme4, BIOS 
P2.20 06/29/2012
AMI BIOS detected: BIOS may corrupt low RAM, working around it.
   #0 [0000000000 - 0000001000]   BIOS data page ==> [0000000000 - 
0000001000]
   #4 [000009ec00 - 0000100000]    BIOS reserved ==> [000009ec00 - 
0000100000]
=================================================================

any help will be appreciated.
thanks in advance.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 10 16:12:56 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Sep 2012 16:12:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TB6bN-00054L-D6; Mon, 10 Sep 2012 16:12: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 1TB6bL-000545-Oi
	for xen-devel@lists.xen.org; Mon, 10 Sep 2012 16:12:43 +0000
Received: from [85.158.143.99:6309] by server-3.bemta-4.messagelabs.com id
	24/30-08232-B711E405; Mon, 10 Sep 2012 16:12:43 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1347293562!24241080!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTIyODk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13090 invoked from network); 10 Sep 2012 16:12:42 -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;
	10 Sep 2012 16:12:42 -0000
X-IronPort-AV: E=Sophos;i="4.80,398,1344211200"; d="scan'208";a="14449362"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Sep 2012 16:12: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.279.1;
	Mon, 10 Sep 2012 17:12:42 +0100
Message-ID: <1347293560.5305.115.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: David Vrabel <david.vrabel@citrix.com>
Date: Mon, 10 Sep 2012 17:12:40 +0100
In-Reply-To: <5048B746.4070306@citrix.com>
References: <1346678886.32462.9.camel@zakaz.uk.xensource.com>
	<5048B746.4070306@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 0/16] arm: support for initial modules (e.g.
 dom0) and DTB supplied in RAM
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-09-06 at 15:46 +0100, David Vrabel wrote:
> On 03/09/12 14:28, Ian Campbell wrote:
> > The following series implements support for initial images and DTB in
> > RAM, as opposed to in flash (dom0 kernel) or compiled into the
> > hypervisor (DTB). It arranges to not clobber these with either the h/v
> > text on relocation or with the heaps and frees them as appropriate.
> > 
> > Most of this is independent of the specific bootloader protocol which is
> > used to tell Xen where these modules actually are, but I have included a
> > simple PoC bootloader protocol based around device tree which is similar
> > to the protocol used by Linux to find its initrd
> > (where /chosen/linux,initrd-{start,end} indicate the physical address).
> > 
> > In the PoC the modules are listed in the chosen node starting
> > with /chosen/nr-modules which contains the count and then /chosen/module
> > %d-{start,end} which gives the physical address of the module
> > and /chosen/module%d-args which give its command line.
> 
> Until there is an agreement on this protocol I would prepend a "xen,"
> prefix to the node names (xen,nr-modules etc.).

OK.

> bootargs instead of args would be more consistent perhaps. So,
> module1-args becomes xen,module1-bootargs.
> 
> The proposed protocol is functional and useful using nodes for each
> module seems to be more device-tree-ish. I think in the longer term,
> perhaps something like the following would be better?

I rather suspect I'm going to end up porting multiboot to ARM. But you
are right that this looks like a better DTish way than mine.

> 
> chosen {
>     module@1 {

Are these normally 1 based or 0 based in DT?

>         compatible = "multiboot-module";
>         regs = <0x12345678 0x01000>;

Is this start and length? This relates somehow to #address-cells or
something doesn't it?

>         bootargs = "frob";
>     };
>     module@2 {
>         compatible = "multiboot-module";
>         regs = <0x12345678 0x01000>;
>     }
> }
> 
> David



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 10 16:12:56 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Sep 2012 16:12:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TB6bN-00054L-D6; Mon, 10 Sep 2012 16:12: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 1TB6bL-000545-Oi
	for xen-devel@lists.xen.org; Mon, 10 Sep 2012 16:12:43 +0000
Received: from [85.158.143.99:6309] by server-3.bemta-4.messagelabs.com id
	24/30-08232-B711E405; Mon, 10 Sep 2012 16:12:43 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1347293562!24241080!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTIyODk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13090 invoked from network); 10 Sep 2012 16:12:42 -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;
	10 Sep 2012 16:12:42 -0000
X-IronPort-AV: E=Sophos;i="4.80,398,1344211200"; d="scan'208";a="14449362"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Sep 2012 16:12: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.279.1;
	Mon, 10 Sep 2012 17:12:42 +0100
Message-ID: <1347293560.5305.115.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: David Vrabel <david.vrabel@citrix.com>
Date: Mon, 10 Sep 2012 17:12:40 +0100
In-Reply-To: <5048B746.4070306@citrix.com>
References: <1346678886.32462.9.camel@zakaz.uk.xensource.com>
	<5048B746.4070306@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 0/16] arm: support for initial modules (e.g.
 dom0) and DTB supplied in RAM
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-09-06 at 15:46 +0100, David Vrabel wrote:
> On 03/09/12 14:28, Ian Campbell wrote:
> > The following series implements support for initial images and DTB in
> > RAM, as opposed to in flash (dom0 kernel) or compiled into the
> > hypervisor (DTB). It arranges to not clobber these with either the h/v
> > text on relocation or with the heaps and frees them as appropriate.
> > 
> > Most of this is independent of the specific bootloader protocol which is
> > used to tell Xen where these modules actually are, but I have included a
> > simple PoC bootloader protocol based around device tree which is similar
> > to the protocol used by Linux to find its initrd
> > (where /chosen/linux,initrd-{start,end} indicate the physical address).
> > 
> > In the PoC the modules are listed in the chosen node starting
> > with /chosen/nr-modules which contains the count and then /chosen/module
> > %d-{start,end} which gives the physical address of the module
> > and /chosen/module%d-args which give its command line.
> 
> Until there is an agreement on this protocol I would prepend a "xen,"
> prefix to the node names (xen,nr-modules etc.).

OK.

> bootargs instead of args would be more consistent perhaps. So,
> module1-args becomes xen,module1-bootargs.
> 
> The proposed protocol is functional and useful using nodes for each
> module seems to be more device-tree-ish. I think in the longer term,
> perhaps something like the following would be better?

I rather suspect I'm going to end up porting multiboot to ARM. But you
are right that this looks like a better DTish way than mine.

> 
> chosen {
>     module@1 {

Are these normally 1 based or 0 based in DT?

>         compatible = "multiboot-module";
>         regs = <0x12345678 0x01000>;

Is this start and length? This relates somehow to #address-cells or
something doesn't it?

>         bootargs = "frob";
>     };
>     module@2 {
>         compatible = "multiboot-module";
>         regs = <0x12345678 0x01000>;
>     }
> }
> 
> David



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 10 16:25:22 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Sep 2012 16:25:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TB6nK-0005Kk-MA; Mon, 10 Sep 2012 16:25:06 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1TB6nJ-0005Kd-Dp
	for xen-devel@lists.xen.org; Mon, 10 Sep 2012 16:25:05 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1347294298!3435152!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzAwNzQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29592 invoked from network); 10 Sep 2012 16:24:59 -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;
	10 Sep 2012 16:24:59 -0000
X-IronPort-AV: E=Sophos;i="4.80,398,1344211200"; d="scan'208";a="37343601"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Sep 2012 16:24:57 +0000
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.279.1; Mon, 10 Sep 2012
	12:24:57 -0400
Message-ID: <504E1458.70606@citrix.com>
Date: Mon, 10 Sep 2012 17:24:56 +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 Iceowl/1.0b1 Icedove/3.0.11
MIME-Version: 1.0
To: Keir Fraser <keir.xen@gmail.com>
References: <CC7237F3.3E2CD%keir.xen@gmail.com>
In-Reply-To: <CC7237F3.3E2CD%keir.xen@gmail.com>
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [ANNOUNCE] Xen x86 32-bit hypervisor end of life
 after	4.2
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 09/09/12 12:11, Keir Fraser wrote:
> Folks,
> 
> With 64-bit support well established in the x86 world these days, the number
> of x86 production environments that cannot run a 64-bit hypervisor is pretty
> much nil. Maintaining the 32-bit x86 port, and implementing new features for
> it, is an ongoing development burden which could be more usefully directed
> elsewhere. Therefore, 32-bit x86 will be considered obsolete in the 4.3
> development branch, and removed.

I have some tracing patches that have some 32-bit/64-bit #ifdef'ery.
Would you prefer them posted now, or deferred until 32-bit is gone?

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 10 16:25:22 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Sep 2012 16:25:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TB6nK-0005Kk-MA; Mon, 10 Sep 2012 16:25:06 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1TB6nJ-0005Kd-Dp
	for xen-devel@lists.xen.org; Mon, 10 Sep 2012 16:25:05 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1347294298!3435152!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzAwNzQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29592 invoked from network); 10 Sep 2012 16:24:59 -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;
	10 Sep 2012 16:24:59 -0000
X-IronPort-AV: E=Sophos;i="4.80,398,1344211200"; d="scan'208";a="37343601"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Sep 2012 16:24:57 +0000
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.279.1; Mon, 10 Sep 2012
	12:24:57 -0400
Message-ID: <504E1458.70606@citrix.com>
Date: Mon, 10 Sep 2012 17:24:56 +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 Iceowl/1.0b1 Icedove/3.0.11
MIME-Version: 1.0
To: Keir Fraser <keir.xen@gmail.com>
References: <CC7237F3.3E2CD%keir.xen@gmail.com>
In-Reply-To: <CC7237F3.3E2CD%keir.xen@gmail.com>
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [ANNOUNCE] Xen x86 32-bit hypervisor end of life
 after	4.2
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 09/09/12 12:11, Keir Fraser wrote:
> Folks,
> 
> With 64-bit support well established in the x86 world these days, the number
> of x86 production environments that cannot run a 64-bit hypervisor is pretty
> much nil. Maintaining the 32-bit x86 port, and implementing new features for
> it, is an ongoing development burden which could be more usefully directed
> elsewhere. Therefore, 32-bit x86 will be considered obsolete in the 4.3
> development branch, and removed.

I have some tracing patches that have some 32-bit/64-bit #ifdef'ery.
Would you prefer them posted now, or deferred until 32-bit is gone?

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 10 16:26:43 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Sep 2012 16:26: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 1TB6od-0005Pi-4m; Mon, 10 Sep 2012 16:26:27 +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 1TB6ob-0005PN-8I
	for xen-devel@lists.xen.org; Mon, 10 Sep 2012 16:26:25 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1347294377!2728798!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTIyODk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15049 invoked from network); 10 Sep 2012 16:26: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;
	10 Sep 2012 16:26:18 -0000
X-IronPort-AV: E=Sophos;i="4.80,398,1344211200"; d="scan'208";a="14449939"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Sep 2012 16:26: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.279.1;
	Mon, 10 Sep 2012 17:26:12 +0100
Message-ID: <1347294370.5305.116.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Mon, 10 Sep 2012 17:26:10 +0100
In-Reply-To: <1346856750.17325.110.camel@zakaz.uk.xensource.com>
References: <99b7a5af9b3059bac273.1346676538@cosworth.uk.xensource.com>
	<20551.26024.217179.594711@mariner.uk.xensource.com>
	<1346856750.17325.110.camel@zakaz.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Andres Lagar-Cavilla <andreslc@gridcentric.ca>,
	"Tim \(Xen.org\)" <tim@xen.org>,
	Stefano Panella <stefano.panella@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] libxl: handle errors from xc_sharing_* info
 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, 2012-09-05 at 15:52 +0100, Ian Campbell wrote:
> I'll respin with this approach, it's less mad.

8<-------------------------------------

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1347294326 -3600
# Node ID e2a8f423ed64c696a61dec88fe8e1976939a7193
# Parent  b02d3fdfab4295c4da3594444cabed898fcc90f7
libxl: handle errors from xc_sharing_* info functions

On a 32 bit hypervisor xl info currently reports:
sharing_freed_memory   : 72057594037927935
sharing_used_memory    : 72057594037927935

Eat the ENOSYS and turn it into 0. Log and propagate other errors.

I don't have a 32 bit system handy, so tested on x86_64 with a libxc
hacked to return -ENOSYS and -EINVAL.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r b02d3fdfab42 -r e2a8f423ed64 tools/libxl/libxl.c
--- a/tools/libxl/libxl.c	Mon Sep 10 17:22:01 2012 +0100
+++ b/tools/libxl/libxl.c	Mon Sep 10 17:25:26 2012 +0100
@@ -3622,6 +3622,7 @@ int libxl_get_physinfo(libxl_ctx *ctx, l
 {
     xc_physinfo_t xcphysinfo = { 0 };
     int rc;
+    long l;
 
     rc = xc_physinfo(ctx->xch, &xcphysinfo);
     if (rc != 0) {
@@ -3636,8 +3637,24 @@ int libxl_get_physinfo(libxl_ctx *ctx, l
     physinfo->total_pages = xcphysinfo.total_pages;
     physinfo->free_pages = xcphysinfo.free_pages;
     physinfo->scrub_pages = xcphysinfo.scrub_pages;
-    physinfo->sharing_freed_pages = xc_sharing_freed_pages(ctx->xch);
-    physinfo->sharing_used_frames = xc_sharing_used_frames(ctx->xch);
+    l = xc_sharing_freed_pages(ctx->xch);
+    if (l == -ENOSYS) {
+        l = 0;
+    } else if (l < 0) {
+        LIBXL__LOG_ERRNOVAL(ctx, LIBXL__LOG_ERROR, l,
+                            "getting sharing freed pages");
+        return ERROR_FAIL;
+    }
+    physinfo->sharing_freed_pages = l;
+    l = xc_sharing_used_frames(ctx->xch);
+    if (l == -ENOSYS) {
+        l = 0;
+    } else if (l < 0) {
+        LIBXL__LOG_ERRNOVAL(ctx, LIBXL__LOG_ERROR, l,
+                            "getting sharing used frames");
+        return ERROR_FAIL;
+    }
+    physinfo->sharing_used_frames = l;
     physinfo->nr_nodes = xcphysinfo.nr_nodes;
     memcpy(physinfo->hw_cap,xcphysinfo.hw_cap, sizeof(physinfo->hw_cap));
 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 10 16:26:43 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Sep 2012 16:26: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 1TB6od-0005Pi-4m; Mon, 10 Sep 2012 16:26:27 +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 1TB6ob-0005PN-8I
	for xen-devel@lists.xen.org; Mon, 10 Sep 2012 16:26:25 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1347294377!2728798!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTIyODk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15049 invoked from network); 10 Sep 2012 16:26: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;
	10 Sep 2012 16:26:18 -0000
X-IronPort-AV: E=Sophos;i="4.80,398,1344211200"; d="scan'208";a="14449939"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Sep 2012 16:26: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.279.1;
	Mon, 10 Sep 2012 17:26:12 +0100
Message-ID: <1347294370.5305.116.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Mon, 10 Sep 2012 17:26:10 +0100
In-Reply-To: <1346856750.17325.110.camel@zakaz.uk.xensource.com>
References: <99b7a5af9b3059bac273.1346676538@cosworth.uk.xensource.com>
	<20551.26024.217179.594711@mariner.uk.xensource.com>
	<1346856750.17325.110.camel@zakaz.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Andres Lagar-Cavilla <andreslc@gridcentric.ca>,
	"Tim \(Xen.org\)" <tim@xen.org>,
	Stefano Panella <stefano.panella@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] libxl: handle errors from xc_sharing_* info
 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, 2012-09-05 at 15:52 +0100, Ian Campbell wrote:
> I'll respin with this approach, it's less mad.

8<-------------------------------------

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1347294326 -3600
# Node ID e2a8f423ed64c696a61dec88fe8e1976939a7193
# Parent  b02d3fdfab4295c4da3594444cabed898fcc90f7
libxl: handle errors from xc_sharing_* info functions

On a 32 bit hypervisor xl info currently reports:
sharing_freed_memory   : 72057594037927935
sharing_used_memory    : 72057594037927935

Eat the ENOSYS and turn it into 0. Log and propagate other errors.

I don't have a 32 bit system handy, so tested on x86_64 with a libxc
hacked to return -ENOSYS and -EINVAL.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r b02d3fdfab42 -r e2a8f423ed64 tools/libxl/libxl.c
--- a/tools/libxl/libxl.c	Mon Sep 10 17:22:01 2012 +0100
+++ b/tools/libxl/libxl.c	Mon Sep 10 17:25:26 2012 +0100
@@ -3622,6 +3622,7 @@ int libxl_get_physinfo(libxl_ctx *ctx, l
 {
     xc_physinfo_t xcphysinfo = { 0 };
     int rc;
+    long l;
 
     rc = xc_physinfo(ctx->xch, &xcphysinfo);
     if (rc != 0) {
@@ -3636,8 +3637,24 @@ int libxl_get_physinfo(libxl_ctx *ctx, l
     physinfo->total_pages = xcphysinfo.total_pages;
     physinfo->free_pages = xcphysinfo.free_pages;
     physinfo->scrub_pages = xcphysinfo.scrub_pages;
-    physinfo->sharing_freed_pages = xc_sharing_freed_pages(ctx->xch);
-    physinfo->sharing_used_frames = xc_sharing_used_frames(ctx->xch);
+    l = xc_sharing_freed_pages(ctx->xch);
+    if (l == -ENOSYS) {
+        l = 0;
+    } else if (l < 0) {
+        LIBXL__LOG_ERRNOVAL(ctx, LIBXL__LOG_ERROR, l,
+                            "getting sharing freed pages");
+        return ERROR_FAIL;
+    }
+    physinfo->sharing_freed_pages = l;
+    l = xc_sharing_used_frames(ctx->xch);
+    if (l == -ENOSYS) {
+        l = 0;
+    } else if (l < 0) {
+        LIBXL__LOG_ERRNOVAL(ctx, LIBXL__LOG_ERROR, l,
+                            "getting sharing used frames");
+        return ERROR_FAIL;
+    }
+    physinfo->sharing_used_frames = l;
     physinfo->nr_nodes = xcphysinfo.nr_nodes;
     memcpy(physinfo->hw_cap,xcphysinfo.hw_cap, sizeof(physinfo->hw_cap));
 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 10 16:30:01 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Sep 2012 16:30: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 1TB6rp-0005aY-PW; Mon, 10 Sep 2012 16:29:45 +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 1TB6ro-0005aT-JG
	for xen-devel@lists.xen.org; Mon, 10 Sep 2012 16:29:44 +0000
Received: from [85.158.139.83:43518] by server-8.bemta-5.messagelabs.com id
	AE/A8-17085-6751E405; Mon, 10 Sep 2012 16:29:42 +0000
X-Env-Sender: msw@amazon.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1347294580!29639165!1
X-Originating-IP: [207.171.189.228]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA3LjE3MS4xODkuMjI4ID0+IDgyNTU3\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12537 invoked from network); 10 Sep 2012 16:29:41 -0000
Received: from smtp-fw-33001.amazon.com (HELO smtp-fw-33001.amazon.com)
	(207.171.189.228)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Sep 2012 16:29:41 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=amazon.com; i=msw@amazon.com; q=dns/txt; s=rte02;
	t=1347294581; x=1378830581;
	h=date:from:to:cc:subject:message-id:references:
	mime-version:in-reply-to;
	bh=1FEw7IjSR7HQSMh1SEEisNGCiiTlajUJ24pAmlUYejw=;
	b=BlYIxBWyyzVoqOdM/hvQCJ22WYnjByzNuWuPptAoWo6cUbEVV1HIeKC4
	KjBduURcUNUYgEh5NrcSKTeRiQPXxw==;
X-IronPort-AV: E=Sophos;i="4.80,399,1344211200"; d="scan'208";a="358955178"
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; 10 Sep 2012 16:29:39 +0000
Received: from ex10-hub-9003.ant.amazon.com (ex10-hub-9003.ant.amazon.com
	[10.185.137.132])
	by smtp-in-0102.sea3.amazon.com (8.13.8/8.13.8) with ESMTP id
	q8AGTcH6011972
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL);
	Mon, 10 Sep 2012 16:29:39 GMT
Received: from u002268147cd4502c336d.ant.amazon.com (10.224.80.42) by
	ex10-hub-9003.ant.amazon.com (10.185.137.132) with Microsoft SMTP
	Server id 14.2.247.3; Mon, 10 Sep 2012 09:29:34 -0700
Received: by u002268147cd4502c336d.ant.amazon.com (sSMTP sendmail emulation); 
	Mon, 10 Sep 2012 09:29:34 -0700
Date: Mon, 10 Sep 2012 09:29:34 -0700
From: Matt Wilson <msw@amazon.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120910162920.GA10746@u002268147cd4502c336d.ant.amazon.com>
References: <patchbomb.1347094753@u002268147cd4502c336d.ant.amazon.com>
	<9c9981ddbfd5c0ccaea7.1347094755@u002268147cd4502c336d.ant.amazon.com>
	<1347272099.5305.50.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1347272099.5305.50.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 2 of 2] docs: flesh out xl.cfg documentation,
 correct typos, reorganize
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Sep 10, 2012 at 11:14:59AM +0100, Ian Campbell wrote:
> On Sat, 2012-09-08 at 09:59 +0100, Matt Wilson wrote:
> >  * Add documentation for msitranslate, power_mgnt, acpi_s3, aspi_s4,
> >    gfx_passthru, nomigrate, etc.
> 
> >  * Reorganize items in "unclassified" sections like cpuid,
> >    gfx_passthru to where they belong
> 
> I tried to apply this but it conflicts with Pasi's "xl.cfg: gfx_passthru
> documentation improvements" patch which I've already applied.
> 
> I had intended to just drop that hunk and apply the rest but the .rej
> was pretty big due to the movement etc and I wasn't sure exactly what
> the right fix was, so I'm punting it back to you, sorry ;-).

Oops. I'll integrate, sorry about that.

> >  * Correct link L<> references so they can be resolved within the
> >    document
> >  * Remove placeholders for deprecated options device_model and vif2
> >  * Remove placeholder for "sched" and "node", as these are options for
> >    cpupool configuration. Perhaps cpupool configuration deserves
> >    a section in this document.
> 
> We have xlcpupool.cfg.pod.5 which you could refer too?

Done.

> [...]
> > +=item C<xauthority=XAUTHORITY>
> > +
> > +Specifies the path to the X authorty file that should be used to
> 
>                               authority
> 
> (probably copied from the original location?)

Yup. Fixed.
 
> Ian.

Matt

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 10 16:30:01 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Sep 2012 16:30: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 1TB6rp-0005aY-PW; Mon, 10 Sep 2012 16:29:45 +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 1TB6ro-0005aT-JG
	for xen-devel@lists.xen.org; Mon, 10 Sep 2012 16:29:44 +0000
Received: from [85.158.139.83:43518] by server-8.bemta-5.messagelabs.com id
	AE/A8-17085-6751E405; Mon, 10 Sep 2012 16:29:42 +0000
X-Env-Sender: msw@amazon.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1347294580!29639165!1
X-Originating-IP: [207.171.189.228]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA3LjE3MS4xODkuMjI4ID0+IDgyNTU3\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12537 invoked from network); 10 Sep 2012 16:29:41 -0000
Received: from smtp-fw-33001.amazon.com (HELO smtp-fw-33001.amazon.com)
	(207.171.189.228)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Sep 2012 16:29:41 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=amazon.com; i=msw@amazon.com; q=dns/txt; s=rte02;
	t=1347294581; x=1378830581;
	h=date:from:to:cc:subject:message-id:references:
	mime-version:in-reply-to;
	bh=1FEw7IjSR7HQSMh1SEEisNGCiiTlajUJ24pAmlUYejw=;
	b=BlYIxBWyyzVoqOdM/hvQCJ22WYnjByzNuWuPptAoWo6cUbEVV1HIeKC4
	KjBduURcUNUYgEh5NrcSKTeRiQPXxw==;
X-IronPort-AV: E=Sophos;i="4.80,399,1344211200"; d="scan'208";a="358955178"
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; 10 Sep 2012 16:29:39 +0000
Received: from ex10-hub-9003.ant.amazon.com (ex10-hub-9003.ant.amazon.com
	[10.185.137.132])
	by smtp-in-0102.sea3.amazon.com (8.13.8/8.13.8) with ESMTP id
	q8AGTcH6011972
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL);
	Mon, 10 Sep 2012 16:29:39 GMT
Received: from u002268147cd4502c336d.ant.amazon.com (10.224.80.42) by
	ex10-hub-9003.ant.amazon.com (10.185.137.132) with Microsoft SMTP
	Server id 14.2.247.3; Mon, 10 Sep 2012 09:29:34 -0700
Received: by u002268147cd4502c336d.ant.amazon.com (sSMTP sendmail emulation); 
	Mon, 10 Sep 2012 09:29:34 -0700
Date: Mon, 10 Sep 2012 09:29:34 -0700
From: Matt Wilson <msw@amazon.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120910162920.GA10746@u002268147cd4502c336d.ant.amazon.com>
References: <patchbomb.1347094753@u002268147cd4502c336d.ant.amazon.com>
	<9c9981ddbfd5c0ccaea7.1347094755@u002268147cd4502c336d.ant.amazon.com>
	<1347272099.5305.50.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1347272099.5305.50.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 2 of 2] docs: flesh out xl.cfg documentation,
 correct typos, reorganize
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Sep 10, 2012 at 11:14:59AM +0100, Ian Campbell wrote:
> On Sat, 2012-09-08 at 09:59 +0100, Matt Wilson wrote:
> >  * Add documentation for msitranslate, power_mgnt, acpi_s3, aspi_s4,
> >    gfx_passthru, nomigrate, etc.
> 
> >  * Reorganize items in "unclassified" sections like cpuid,
> >    gfx_passthru to where they belong
> 
> I tried to apply this but it conflicts with Pasi's "xl.cfg: gfx_passthru
> documentation improvements" patch which I've already applied.
> 
> I had intended to just drop that hunk and apply the rest but the .rej
> was pretty big due to the movement etc and I wasn't sure exactly what
> the right fix was, so I'm punting it back to you, sorry ;-).

Oops. I'll integrate, sorry about that.

> >  * Correct link L<> references so they can be resolved within the
> >    document
> >  * Remove placeholders for deprecated options device_model and vif2
> >  * Remove placeholder for "sched" and "node", as these are options for
> >    cpupool configuration. Perhaps cpupool configuration deserves
> >    a section in this document.
> 
> We have xlcpupool.cfg.pod.5 which you could refer too?

Done.

> [...]
> > +=item C<xauthority=XAUTHORITY>
> > +
> > +Specifies the path to the X authorty file that should be used to
> 
>                               authority
> 
> (probably copied from the original location?)

Yup. Fixed.
 
> Ian.

Matt

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 10 16:39:55 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Sep 2012 16:39: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 1TB71P-0005rN-T2; Mon, 10 Sep 2012 16:39:39 +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 1TB71O-0005rI-FI
	for xen-devel@lists.xen.org; Mon, 10 Sep 2012 16:39:38 +0000
Received: from [85.158.138.51:45644] by server-7.bemta-3.messagelabs.com id
	66/5B-32000-9C71E405; Mon, 10 Sep 2012 16:39:37 +0000
X-Env-Sender: msw@amazon.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1347295174!29745362!1
X-Originating-IP: [72.21.196.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNzIuMjEuMTk2LjI1ID0+IDEyNDU1OQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24470 invoked from network); 10 Sep 2012 16:39:35 -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;
	10 Sep 2012 16:39:35 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=amazon.com; i=msw@amazon.com; q=dns/txt; s=rte02;
	t=1347295176; x=1378831176;
	h=mime-version:content-transfer-encoding:subject:
	message-id:date:from:to:cc;
	bh=xNOEAGlkf2Rjy+bjQskB8v0KGLFBH7uCCWhUxJZdT5s=;
	b=m870DUBLrrQx27tVKO/ZU0gKNMl3czdfHfzCs8q54UXW1dMAHhFNrcC8
	84kr8LeDfeTvK4HQjLogBVDgUfDivA==;
X-IronPort-AV: E=Sophos;i="4.80,399,1344211200"; d="scan'208";a="437662921"
Received: from smtp-in-0191.sea3.amazon.com ([10.224.12.28])
	by smtp-border-fw-out-2101.iad2.amazon.com with
	ESMTP/TLS/DHE-RSA-AES256-SHA; 10 Sep 2012 16:39:32 +0000
Received: from ex10-hub-31005.ant.amazon.com (ex10-hub-31005.sea31.amazon.com
	[10.185.176.12])
	by smtp-in-0191.sea3.amazon.com (8.13.8/8.13.8) with ESMTP id
	q8AGdVTW014456
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL);
	Mon, 10 Sep 2012 16:39:31 GMT
Received: from u002268147cd4502c336d.ant.amazon.com (10.224.80.38) by
	ex10-hub-31005.ant.amazon.com (10.185.176.12) with Microsoft SMTP
	Server id 14.2.247.3; Mon, 10 Sep 2012 09:39:28 -0700
MIME-Version: 1.0
X-Mercurial-Node: 22452f41545c1786e88795682a64e224ff7c6d49
Message-ID: <22452f41545c1786e887.1347295130@u002268147cd4502c336d.ant.amazon.com>
User-Agent: Mercurial-patchbomb/2.3.1
Date: Mon, 10 Sep 2012 09:38:50 -0700
From: Matt Wilson <msw@amazon.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH v2] docs: flesh out xl.cfg documentation,
 correct typos, reorganize
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Some highlights:
 * Correct some markup errors:
       Around line 663:
           '=item' outside of any '=over'
       Around line 671:
           You forgot a '=back' before '=head3'
 * Add documentation for msitranslate, power_mgnt, acpi_s3, aspi_s4,
   gfx_passthru, nomigrate, etc.
 * Reorganize items in "unclassified" sections like cpuid,
   gfx_passthru to where they belong
 * Correct link L<> references so they can be resolved within the
   document
 * Remove placeholders for deprecated options device_model and vif2
 * Remove placeholder for "sched" and "node", as these are options for
   cpupool configuration. Perhaps cpupool configuration deserves
   a section in this document.
 * Rename "global" options to "general"
 * Add section headers to group general VM options.

Signed-off-by: Matt Wilson <msw@amazon.com>

---
Changes since v1:
  * integrate gfx_passthru documentation
  * correct typos
  * reference xlcpupool.cfg(5)

diff -r a1f73e989c24 -r 22452f41545c docs/man/xl.cfg.pod.5
--- a/docs/man/xl.cfg.pod.5	Mon Sep 10 16:47:31 2012 +0200
+++ b/docs/man/xl.cfg.pod.5	Mon Sep 10 09:33:02 2012 -0700
@@ -17,7 +17,7 @@
 
 A domain config file consists of a series of C<KEY=VALUE> pairs.
 
-Some C<KEY>s are mandatory, others are global options which apply to
+Some C<KEY>s are mandatory, others are general options which apply to
 any guest type while others relate only to specific guest types
 (e.g. PV or HVM guests).
 
@@ -80,21 +80,14 @@
 
 =back
 
-=head2 Global Options
+=head2 General Options
 
 The following options apply to guests of any type.
 
+=head3 CPU Allocation
+
 =over 4
 
-=item B<uuid="UUID">
-
-Specifies the UUID of the domain.  If not specified, a fresh unique
-UUID will be generated.
-
-=item B<vncviewer=BOOLEAN>
-
-Automatically spawn a vncviewer when creating/restoring a guest
-
 =item B<pool="CPUPOOLNAME">
 
 Put the guest's vcpus into the named cpu pool.
@@ -138,6 +131,12 @@
 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.
 
+=back
+
+=head3 CPU Scheduling
+
+=over 4
+
 =item B<cpu_weight=WEIGHT>
 
 A domain with a weight of 512 will get twice as much CPU as a domain
@@ -176,6 +175,12 @@
 Flag for allowing domain to run in extra time.
 Honoured by the sedf scheduler.
 
+=back
+
+=head3 Memory Allocation
+
+=over 4
+
 =item B<memory=MBYTES>
 
 Start the guest with MBYTES megabytes of RAM.
@@ -190,6 +195,12 @@
 A "pre-ballooned" HVM guest needs a balloon driver, without a balloon driver
 it will crash.
 
+=back
+
+=head3 Event Actions
+
+=over 4
+
 =item B<on_poweroff="ACTION">
 
 Specifies what should be done with the domain if it shuts itself down.
@@ -200,12 +211,12 @@
 =item B<destroy>
 
 destroy the domain
-     
+
 =item B<restart>
 
 destroy the domain and immediately create a new domain with the same
 configuration
-        
+
 =item B<rename-restart>
 
 rename the domain which terminated, and then immediately create a new
@@ -244,10 +255,28 @@
 
 Action to take if the domain crashes.  Default is C<destroy>.
 
+=back
+
+=head3 Other Options
+
+=over 4
+
+=item B<uuid="UUID">
+
+Specifies the UUID of the domain.  If not specified, a fresh unique
+UUID will be generated.
+
 =item B<seclabel="LABEL">
 
 Assign an XSM security label to this domain.
 
+=item B<nomigrate=BOOLEAN>
+
+Disable migration of this domain.  This enables certain other features
+which are incompatible with migration. Currently this is limited to
+enabling the invariant TSC feature flag in cpuid results when TSC is
+not emulated.
+
 =back
 
 =head2 Devices
@@ -309,7 +338,20 @@
 =item C<sdl=BOOLEAN>
 
 Specifies that the display should be presented via an X window (using
-Simple DirectMedia Layer). The default is to not enable this mode
+Simple DirectMedia Layer). The default is to not enable this mode.
+
+=item C<display=DISPLAY>
+
+Specifies the X Window display that should be used when the sdl option
+is used. Note: passing this value to the device-model is not currently
+implemented, so providing this option will have no effect.
+
+=item C<xauthority=XAUTHORITY>
+
+Specifies the path to the X authority file that should be used to
+connect to the X server when the sdl option is used. Note: passing
+this value to the device-model is not currently implemented, so
+providing this option will have no effect.
 
 =item C<opengl=BOOLEAN>
 
@@ -324,19 +366,9 @@
 (e.g. this is often the case when using VNC) then this allows us to
 correctly map the input keys into keycodes seen by the guest. The
 specific values which are accepted are defined by the version of the
-device-model which you are using. See L<Keymaps> below or consult the
+device-model which you are using. See L</"Keymaps"> below or consult the
 L<qemu(1)> manpage. The default is B<en-us>.
 
-=item C<display=XXX>
-
-XXX written to xenstore backend for vfb but does not appear to be used
-anywhere?
-
-=item C<authority=XXX>
-
-XXX written to xenstore backend for vfb but does not appear to be used
-anywhere?
-
 =back
 
 =item B<pci=[ "PCI_SPEC_STRING", "PCI_SPEC_STRING", ... ]>
@@ -348,7 +380,7 @@
 
 =item B<DDDD:BB:DD.F>
 
-identifies the PCI device from the host perspective in domain
+Identifies the PCI device from the host perspective in domain
 (B<DDDD>), Bus (B<BB>), Device (B<DD>) and Function (B<F>) syntax. This is
 the same scheme as used in the output of C<lspci> for the device in
 question. Note: By default C<lspci> will omit the domain (B<DDDD>) if it
@@ -357,9 +389,9 @@
 
 =item B<@VSLOT>
 
-specifies the virtual device where the guest will see this
+Specifies the virtual device where the guest will see this
 device. This is equivalent to the B<DD> which the guest sees. In a
-guest B<DDDD> and B<BB> are C<0000:00>. XXX how does this really work?
+guest B<DDDD> and B<BB> are C<0000:00>.
 
 =item B<KEY=VALUE>
 
@@ -367,14 +399,6 @@
 
 =over 4
 
-=item B<msitranslate=BOOLEAN>
-
-XXX
-
-=item B<power_mgmt=BOOLEAN>
-
-XXX
-
 =item B<permissive=BOOLEAN>
 
 (PV only) By default pciback only allows PV guests to write "known
@@ -386,6 +410,19 @@
 may have security or stability implications.  It is recommended to
 enable this option only for trusted VMs under administrator control.
 
+=item B<msitranslate=BOOLEAN>
+
+Specifies that MSI-INTx translation should be turned on for the PCI
+device. When enabled, MSI-INTx translation will always enable MSI on
+the PCI device regardless whether the guest uses INTx or MSI. Some
+device drivers, such as NVIDIA's, detect an inconsistency and do not
+function when this option is enabled. Therefore the default is 0.
+
+=item B<power_mgmt=BOOLEAN>
+
+(HVM only) Specifies that the VM should be able to program the
+D0-D3hot power management states for the PCI device. 0 by default.
+
 =back
 
 =back
@@ -393,19 +430,65 @@
 =item B<pci_permissive=BOOLEAN>
 
 (PV only) Changes the default value of 'permissive' for all PCI
-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
-for trusted VMs under administrator control.  See the "pci=" section
-for more information on the "permissive" flag.
+devices passed through to this VM. See L<permissive|/"permissive_boolean">
+above.
 
-=back
+=item B<pci_msitranslate=BOOLEAN>
+
+Changes the default value of 'msitranslate' for all PCI devices passed
+through to this VM. See L<msitranslate|/"msitranslate_boolean"> above.
+
+=item B<pci_power_mgmt=BOOLEAN>
+
+(HVM only) Changes the default value of 'power_mgmt' for all PCI
+devices passed through to this VM. See L<power_mgt|/"power_mgmt_boolean">
+above.
+
+=item B<gfx_passthru=BOOLEAN>
+
+Enable graphics device PCI passthrough. This option makes an assigned
+PCI graphics card become primary graphics card in the VM. The QEMU
+emulated graphics adapter is disabled and the VNC console for the VM
+will not have any graphics output. All graphics output, including boot
+time QEMU BIOS messages from the VM, will go to the physical outputs
+of the passedthrough physical graphics card.
+
+The graphics card PCI device to passthrough is chosen with B<pci>
+option, exactly in the same way as normal Xen PCI device
+passthrough/assignment is done.  Note that gfx_passthru does not do
+any kind of sharing of the GPU, so you can only assign the GPU to one
+single VM at a time.
+
+gfx_passthru also enables various legacy VGA memory ranges, BARs, MMIOs,
+and ioports to be passed thru to the VM, since those are required
+for correct operation of things like VGA BIOS, text mode, VBE, etc.
+
+Enabling gfx_passthru option also copies the physical graphics card
+video BIOS to the guest memory, and executes the VBIOS in the guest
+to initialize the graphics card.
+
+Most graphics adapters require vendor specific tweaks for properly
+working graphics passthrough. See the XenVGAPassthroughTestedAdapters
+L<http://wiki.xen.org/wiki/XenVGAPassthroughTestedAdapters> wiki page
+for currently supported graphics cards for gfx_passthru.
+
+gfx_passthru is currently only supported with the qemu-xen-traditional
+device-model. Upstream qemu-xen device-model currently does not have
+support for gfx_passthru.
+
+Note that some graphics adapters (AMD/ATI cards, for example) do not
+necessarily require gfx_passthru option, so you can use the normal Xen
+PCI passthrough to assign the graphics card as a secondary graphics
+card to the VM. The QEMU-emulated graphics card remains the primary
+graphics card, and VNC output is available from the QEMU-emulated
+primary adapter.
+
+More information about Xen gfx_passthru feature is available
+on the XenVGAPassthrough L<http://wiki.xen.org/wiki/XenVGAPassthrough>
+wiki page.
 
 =item B<ioports=[ "IOPORT_RANGE", "IOPORT_RANGE", ... ]>
 
-=over 4
-
 Allow guest to access specific legacy I/O ports. Each B<IOPORT_RANGE>
 is given in hexadecimal and may either a span e.g. C<2f8-2ff>
 (inclusive) or a single I/O port C<2f8>.
@@ -413,12 +496,8 @@
 It is recommended to use this option only for trusted VMs under
 administrator control.
 
-=back
-
 =item B<irqs=[ NUMBER, NUMBER, ... ]>
 
-=over 4
-
 Allow a guest to access specific physical IRQs.
 
 It is recommended to use this option only for trusted VMs under
@@ -471,12 +550,12 @@
 option is specified the virtual e820 instead reflects the host e820
 and contains the same PCI holes. The total amount of RAM represented
 by the memory map is always the same, this option configures only how
-it is layed out.
+it is laid 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 Operating System dependant whether this
+PCI devices. It is guest Operating System dependent 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 configured and false otherwise. If you do not
@@ -600,6 +679,16 @@
 default and usually you should omit it. However it may be necessary to
 disable ACPI for compatibility with some guest Operating Systems.
 
+=item B<acpi_s3=BOOLEAN>
+
+Include the S3 (suspend-to-ram) power state in the virtual firmware
+ACPI table. 1 by default.
+
+=item B<acpi_s4=BOOLEAN>
+
+Include S4 (suspend-to-disk) power state in the virtual firmware ACPI
+table. 1 by default.
+
 =item B<apic=BOOLEAN>
 
 Include information regarding APIC (Advanced Programmable Interrupt
@@ -637,414 +726,6 @@
 which uses hardware virtualisation extensions (e.g. Windows XP
 compatibility mode on more modern Windows OS).
 
-=back 
-
-=head3 Guest Virtual Time Controls
-
-=over 4
-
-=item B<tsc_mode="MODE">
-
-
-Specifies how the TSC (Time Stamp Counter) should be provided to the
-guest (X86 only). Specifying this option as a number is
-deprecated. Options are:
-
-=over 4
-
-=item B<"default">
-
-Guest rdtsc/p executed natively when monotonicity can be guaranteed
-and emulated otherwise (with frequency scaled if necessary).
-
-=item B<"always_emulate">
-
-Guest rdtsc/p always emulated at 1GHz (kernel and user). Guest rdtsc/p
-always emulated and the virtual TSC will appear to increment (kernel
-and user) at a fixed 1GHz rate, regardless of the PCPU HZ rate or
-power state; Although there is an overhead associated with emulation
-this will NOT affect underlying CPU performance.
-
-=item B<"native">
-
-Guest rdtsc always executed natively (no monotonicity/frequency
-guarantees); guest rdtscp emulated at native frequency if unsupported
-by h/w, else executed natively.
-
-=item B<"native_paravirt">
-
-Same as B<native>, except xen manages TSC_AUX register so guest can
-determine when a restore/migration has occurred and assumes guest
-obtains/uses pvclock-like mechanism to adjust for monotonicity and
-frequency changes.
-
-=back
-
-=back
-
-Please see F<docs/misc/tscmode.txt> for more information on this option.
-
-=item B<localtime=BOOLEAN>
-
-Set the real time clock to local time or to UTC. 0 by default, i.e. set to UTC.
-
-=item B<rtc_timeoffset=SECONDS>
-
-Set the real time clock offset in seconds. 0 by default.
-
-=head3 Support for Paravirtualisation of HVM Guests
-
-The following options allow Paravirtualised features (such as devices)
-to be exposed to the guest Operating System in an HVM guest.
-Utilising these features requires specific guest support but when
-available they will result in improved performance.
-
-=over 4
-
-=item B<xen_platform_pci=BOOLEAN>
-
-Enable or disable the Xen platform PCI device.  The presence of this
-virtual device enables a guest Operating System (subject to the
-availability of suitable drivers) to make use of paravirtualisation
-features such as disk and network devices etc. Enabling these drivers
-improves performance and is strongly recommended when available. PV
-drivers are available for various Operating Systems including HVM
-Linux L<http://wiki.xen.org/wiki/XenLinuxPVonHVMdrivers> and Microsoft
-Windows L<http://wiki.xen.org/wiki/XenWindowsGplPv>.
-
-=item B<viridian=BOOLEAN>
-
-Turns on or off the exposure of MicroSoft Hyper-V (AKA viridian)
-compatible enlightenments to the guest.  These can improve performance
-of Microsoft Windows guests from Windows Vista and Windows 2008
-onwards and setting this option for such guests is strongly
-recommended. This option should be harmless for other versions of
-Windows (although it won't give any benefit) and the majority of other
-non-Windows OSes. However it is known to be incompatible with some
-other Operating Systems and in some circumstance can prevent Xen's own
-paravirtualisation interfaces for HVM guests from being used.
-
-=back
-
-=head3 Emulated VGA Graphics Device
-
-The following options control the features of the emulated graphics
-device.  Many of these options behave similarly to the equivalent key
-in the B<VFB_SPEC_STRING> for configuring virtual frame buffer devices
-(see above).
-
-=over 4
-
-=item B<videoram=MBYTES>
-
-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 amount of video ram for stdvga is 8MB which is sufficient
-for e.g. 1600x1200 at 32bpp.
-
-When using the emulated Cirrus graphics card (B<stdvga=0>)
-the amount of video ram is fixed at 4MB which is sufficient
-for 1024x768 at 32 bpp.
-
-videoram option is currently only available when using the
-qemu-xen-traditional device-model. Upstream qemu-xen device-model
-currently doesn't support changing the amount of video memory
-for the emulated graphics device.
-
-=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.
-stdvga supports more video ram and bigger resolutions than Cirrus.
-
-=item B<vnc=BOOLEAN>
-
-Allow access to the display via the VNC protocol.  This enables the
-other VNC-related settings.  The default is to enable this.
-
-=item B<vnclisten="ADDRESS[:DISPLAYNUM]">
-
-Specifies the IP address, and optionally VNC display number, to use.
-
-=item B<vncdisplay=DISPLAYNUM>
-
-Specifies the VNC display number to use. The actual TCP port number
-will be DISPLAYNUM+5900.
-
-=item B<vncunused=BOOLEAN>
-
-Requests that the VNC display setup search for a free TCP port to use.
-The actual display used can be accessed with C<xl vncviewer>.
-
-=item B<vncpasswd="PASSWORD">
-
-Specifies the password for the VNC server.
-
-=item B<keymap="LANG">
-
-Configure the keymap to use for the keyboard associated with this
-display. If the input method does not easily support raw keycodes
-(e.g. this is often the case when using VNC) then this allows us to
-correctly map the input keys into keycodes seen by the guest. The
-specific values which are accepted are defined by the version of the
-device-model which you are using. See L<Keymaps> below of consult the
-L<qemu(1)> manpage. The default is B<en-us>.
-
-=item B<sdl=BOOLEAN>
-
-Specifies that the display should be presented via an X window (using
-Simple DirectMedia Layer). The default is not to enable this mode.
-
-=item B<opengl=BOOLEAN>
-
-Enable OpenGL acceleration of the SDL display. Only effects machines
-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>
-
-Enable or disable the virtual graphics device.  The default is to
-provide a VGA graphics device but this option can be used to disable
-it.
-
-=back
-
-=head3 Spice Graphics Support
-
-The following options control the features of SPICE.
-
-=over 4
-
-=item B<spice=BOOLEAN>
-
-Allow access to the display via the SPICE protocol.  This enables the
-other SPICE-related settings.
-
-=item B<spicehost="ADDRESS">
-
-Specify the interface address to listen on if given, otherwise any
-interface.
-
-=item B<spiceport=NUMBER>
-
-Specify the port to listen on by the SPICE server if the SPICE is
-enabled.
-
-=item B<spicetls_port=NUMBER>
-
-Specify the secure port to listen on by the SPICE server if the SPICE
-is enabled. At least one of the spiceport or spicetls_port must be
-given if SPICE is enabled.  NB. the options depending on spicetls_port
-have not been supported.
-
-=item B<spicedisable_ticketing=BOOLEAN>
-
-Enable client connection without password. The default is false. If
-it's false (set to 0), spicepasswd must be set.
-
-=item B<spicepasswd="PASSWORD">
-
-Specify the ticket password which is used by a client for connection.
-
-=item B<spiceagent_mouse=BOOLEAN>
-
-Whether SPICE agent is used for client mouse mode. The default is true
-(turn on)
-
-=back
-
-=head3 Miscellaneous Emulated Hardware
-
-=over 4
-
-=item B<serial=DEVICE>
-
-Redirect the virtual serial port to B<DEVICE>. Please see the
-B<-serial> option in the L<qemu(1)> manpage for details of the valid
-B<DEVICE> options. Default is B<vc> when in graphical mode and
-B<stdio> if B<nographics=1> is used.
-
-=item B<soundhw=DEVICE>
-
-Select the virtual sound card to expose to the guest. The valid
-devices are defined by the device model configuration, please see the
-L<qemu(1)> manpage for details. The default is not to export any sound
-device.
-
-=item B<usb=BOOLEAN>
-
-Enables or disables a USB bus in the guest.
-
-=item B<usbdevice=DEVICE>
-
-Adds B<DEVICE> to the USB bus. The USB bus must also be enabled using
-B<usb=1>. The most common use for this option is B<usbdevice=tablet>
-which adds pointer device using absolute coordinates. Such devices
-function better than relative coordinate devices (such as a standard
-mouse) since many methods of exporting guest graphics (such as VNC)
-work better in this mode. Note that this is independent of the actual
-pointer device you are using on the host/client side. XXX should/could
-be a list of devices.
-
-=back
-
-=head3 Unclassified HVM Specific Options
-
-These HVM specific options have not yet been documented or
-classified. They almost certainly belong in a more appropriate
-section.
-
-=over 4
-
-=item B<vpt_align=BOOLEAN>
-
-Align the Virtual Platform Timer ??? XXX Reduces interrupts?
-
-=item B<timer_mode=NUMBER>
-
-Set mode for Virtual Timers XXX ??? should be an enum of particular
-values. See C<HVM_PARAM_TIMER_MODE> in
-F<xen/include/public/hvm/params.h>.
-
-=back
-
-=head2 Device-Model Options
-
-The following options control the selection of the device-model.  This
-is the component which provides emulation of the virtual devices to an
-HVM guest.  For a PV guest a device-model is sometimes used to provide
-backends for certain PV devices (most usually a virtual framebuffer
-device).
-
-=over 4
-
-=item B<device_model_version="DEVICE-MODEL">
-
-Selects which variant of the device-model should be used for this
-guest. Valid values are:
-
-=over 4
-
-=item B<qemu-xen-traditional>
-
-Use the device-model based upon the historical Xen fork of Qemu.  This
-device-model is currently the default.
-
-=item B<qemu-xen>
-
-use the device-model merged into the upstream Qemu project.  This
-device-model will become the default in a future version of Xen.
-
-=back
-
-It is recommended to accept the default value for new guests.  If
-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.
-
-=item B<device_model_override="PATH">
-
-Override the path to the binary to be used as the device-model. The
-binary provided here MUST be consistent with the
-`device_model_version` which you have specified. You should not
-normally need to specify this option.
-
-=item B<device_model_stubdomain_override=BOOLEAN>
-
-Override the use of stubdomain based device-model.  Normally this will
-be automatically selected based upon the other features and options
-you have selected.
-
-=item B<device_model_stubdomain_seclabel="LABEL">
-
-Assign an XSM security label to the device-model stubdomain.
-
-=item B<device_model_args=[ "ARG", "ARG", ...]>
-
-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 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 device-model command line for
-an HVM device model only. Each element in the list is passed as an
-option to the device-model.
-
-=back
-
-=head2 Unclassified General Options
-
-These have not yet been fully documented or classified. They almost
-certainly belong in a more appropriate section.
-
-=over 4
-
-=item B<gfx_passthru=BOOLEAN>
-
-Enable graphics device PCI passthrough. This option makes the passthru
-graphics card become primary graphics card in the VM, so the Qemu emulated
-graphics adapter is disabled, and the VNC console for the VM won't have
-any graphics output. All graphics output, including boot time Qemu BIOS
-messages from the VM, will go to the physical outputs of the passed thru
-physical graphics card.
-
-Graphics card PCI device to passthru is chosen with B<pci> option,
-exactly in the same way as normal Xen PCI device passthru/assignment is done.
-Note that gfx_passthru doesn't do any kind of sharing
-of the GPU, so you can only assign the GPU to one single VM at a time.
-
-gfx_passthru also enables various legacy VGA memory ranges, BARs, MMIOs,
-and ioports to be passed thru to the VM, since those are required
-for correct operation of things like VGA BIOS, text mode, VBE, etc.
-
-Enabling gfx_passthru option also copies the physical graphics card
-video BIOS to the guest memory, and executes the VBIOS in the guest
-to get the graphics card initialized.
-
-Most graphics adapters require vendor specific tweaks for properly
-working graphics passthru. See the XenVGAPassthroughTestedAdapters
-L<http://wiki.xen.org/wiki/XenVGAPassthroughTestedAdapters>
-wiki page for currently supported graphics cards for gfx_passthru.
-
-gfx_passthru is currently only supported with the qemu-xen-traditional
-device-model. Upstream qemu-xen device-model currently doesn't have
-support for gfx_passthru.
-
-Note that some graphics adapters (AMD/ATI cards, for example) don't
-necessarily require gfx_passthru option, so you can use the normal
-Xen PCI passthru to assign the graphics card as a secondary graphics card
-to the VM. Qemu emulated graphics card stays as the primary graphics card,
-and you get VNC output from the Qemu-emulated primary adapter.
-
-More information about Xen gfx_passthru feature is available
-on the XenVGAPassthrough L<http://wiki.xen.org/wiki/XenVGAPassthrough>
-wiki page.
-
-=item B<nomigrate=BOOLEAN>
-
-Disable migration of this domain.  This enables certain other features
-which are incompatible with migration (currently certain TSC modes XXX
-?).
-
-=item B<pci_msitranslate=BOOLEAN>
-
-XXX
-
-=item B<pci_power_mgmt=BOOLEAN>
-
-XXX
-
 =item B<cpuid="LIBXL_STRING"> or B<cpuid=[ "XEND_STRING", "XEND_STRING" ]>
 
 Configure the value returned when a guest executes CPUID instruction.
@@ -1093,29 +774,375 @@
 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>
+=back 
 
-XXX
+=head3 Guest Virtual Time Controls
 
-=item B<acpi_s3=BOOLEAN>
+=over 4
 
-XXX
+=item B<tsc_mode="MODE">
 
-=item B<nodes=XXX>
 
-XXX
+Specifies how the TSC (Time Stamp Counter) should be provided to the
+guest (X86 only). Specifying this option as a number is
+deprecated. Options are:
 
-=item B<sched=XXX>
+=over 4
 
-XXX
+=item B<"default">
 
-=item B<device_model=XXX>
+Guest rdtsc/p executed natively when monotonicity can be guaranteed
+and emulated otherwise (with frequency scaled if necessary).
 
-XXX deprecated
+=item B<"always_emulate">
 
-=item B<vif2=XXX>
+Guest rdtsc/p always emulated at 1GHz (kernel and user). Guest rdtsc/p
+always emulated and the virtual TSC will appear to increment (kernel
+and user) at a fixed 1GHz rate, regardless of the PCPU HZ rate or
+power state; Although there is an overhead associated with emulation
+this will NOT affect underlying CPU performance.
 
-XXX deprecated
+=item B<"native">
+
+Guest rdtsc always executed natively (no monotonicity/frequency
+guarantees); guest rdtscp emulated at native frequency if unsupported
+by h/w, else executed natively.
+
+=item B<"native_paravirt">
+
+Same as B<native>, except xen manages TSC_AUX register so guest can
+determine when a restore/migration has occurred and assumes guest
+obtains/uses pvclock-like mechanism to adjust for monotonicity and
+frequency changes.
+
+=back
+
+Please see F<docs/misc/tscmode.txt> for more information on this option.
+
+=item B<localtime=BOOLEAN>
+
+Set the real time clock to local time or to UTC. 0 by default, i.e. set to UTC.
+
+=item B<rtc_timeoffset=SECONDS>
+
+Set the real time clock offset in seconds. 0 by default.
+
+
+=item B<vpt_align=BOOLEAN>
+
+Specifies that periodic Virtual Platform Timers should be aligned to
+reduce guest interrupts. Enabling this option can reduce power
+consumption, especially when a guest uses a high timer interrupt
+frequency (HZ) values. The default is 1.
+
+=item B<timer_mode=MODE>
+
+Specifies the mode for Virtual Timers. The valid values are as follows:
+
+=over 4
+
+=item B<"delay_for_missed_ticks">
+
+Delay for missed ticks. Do not advance a vcpu's time beyond the
+correct delivery time for interrupts that have been missed due to
+preemption. Deliver missed interrupts when the vcpu is rescheduled and
+advance the vcpu's virtual time stepwise for each one.
+
+=item B<"no_delay_for_missed_ticks">
+
+No delay for missed ticks. As above, missed interrupts are delivered,
+but guest time always tracks wallclock (i.e., real) time while doing
+so.
+
+=item B<"no_missed_ticks_pending">
+
+No missed interrupts are held pending. Instead, to ensure ticks are
+delivered at some non-zero rate, if we detect missed ticks then the
+internal tick alarm is not disabled if the VCPU is preempted during
+the next tick period.
+
+=item B<"one_missed_tick_pending">
+
+One missed tick pending. Missed interrupts are collapsed
+together and delivered as one 'late tick'.  Guest time always tracks
+wallclock (i.e., real) time.
+
+=back
+
+=back
+
+=head3 Support for Paravirtualisation of HVM Guests
+
+The following options allow Paravirtualised features (such as devices)
+to be exposed to the guest Operating System in an HVM guest.
+Utilising these features requires specific guest support but when
+available they will result in improved performance.
+
+=over 4
+
+=item B<xen_platform_pci=BOOLEAN>
+
+Enable or disable the Xen platform PCI device.  The presence of this
+virtual device enables a guest Operating System (subject to the
+availability of suitable drivers) to make use of paravirtualisation
+features such as disk and network devices etc. Enabling these drivers
+improves performance and is strongly recommended when available. PV
+drivers are available for various Operating Systems including HVM
+Linux L<http://wiki.xen.org/wiki/XenLinuxPVonHVMdrivers> and Microsoft
+Windows L<http://wiki.xen.org/wiki/XenWindowsGplPv>.
+
+=item B<viridian=BOOLEAN>
+
+Turns on or off the exposure of MicroSoft Hyper-V (AKA viridian)
+compatible enlightenments to the guest.  These can improve performance
+of Microsoft Windows guests from Windows Vista and Windows 2008
+onwards and setting this option for such guests is strongly
+recommended. This option should be harmless for other versions of
+Windows (although it will not give any benefit) and the majority of
+other non-Windows OSes. However it is known to be incompatible with
+some other Operating Systems and in some circumstance can prevent
+Xen's own paravirtualisation interfaces for HVM guests from being
+used.
+
+=back
+
+=head3 Emulated VGA Graphics Device
+
+The following options control the features of the emulated graphics
+device.  Many of these options behave similarly to the equivalent key
+in the B<VFB_SPEC_STRING> for configuring virtual frame buffer devices
+(see above).
+
+=over 4
+
+=item B<videoram=MBYTES>
+
+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 amount of video ram for stdvga is 8MB which is sufficient
+for e.g. 1600x1200 at 32bpp.
+
+When using the emulated Cirrus graphics card (B<stdvga=0>)
+the amount of video ram is fixed at 4MB which is sufficient
+for 1024x768 at 32 bpp.
+
+videoram option is currently only available when using the
+qemu-xen-traditional device-model. Upstream qemu-xen device-model
+currently does not support changing the amount of video memory for the
+emulated graphics device.
+
+=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.
+stdvga supports more video ram and bigger resolutions than Cirrus.
+
+=item B<vnc=BOOLEAN>
+
+Allow access to the display via the VNC protocol.  This enables the
+other VNC-related settings.  The default is to enable this.
+
+=item B<vncviewer=BOOLEAN>
+
+Automatically spawn a vncviewer when creating/restoring a guest.
+
+=item B<vnclisten="ADDRESS[:DISPLAYNUM]">
+
+Specifies the IP address, and optionally VNC display number, to use.
+
+=item B<vncdisplay=DISPLAYNUM>
+
+Specifies the VNC display number to use. The actual TCP port number
+will be DISPLAYNUM+5900.
+
+=item B<vncunused=BOOLEAN>
+
+Requests that the VNC display setup search for a free TCP port to use.
+The actual display used can be accessed with C<xl vncviewer>.
+
+=item B<vncpasswd="PASSWORD">
+
+Specifies the password for the VNC server.
+
+=item B<keymap="LANG">
+
+Configure the keymap to use for the keyboard associated with this
+display. If the input method does not easily support raw keycodes
+(e.g. this is often the case when using VNC) then this allows us to
+correctly map the input keys into keycodes seen by the guest. The
+specific values which are accepted are defined by the version of the
+device-model which you are using. See L</"Keymaps"> below or consult the
+L<qemu(1)> manpage. The default is B<en-us>.
+
+=item B<sdl=BOOLEAN>
+
+Specifies that the display should be presented via an X window (using
+Simple DirectMedia Layer). The default is not to enable this mode.
+
+=item B<opengl=BOOLEAN>
+
+Enable OpenGL acceleration of the SDL display. Only effects machines
+using B<device_model_version="qemu-xen-traditional"> and only if the
+device-model was compiled with OpenGL support. 0 by default.
+
+=item B<nographic=BOOLEAN>
+
+Enable or disable the virtual graphics device.  The default is to
+provide a VGA graphics device but this option can be used to disable
+it.
+
+=back
+
+=head3 Spice Graphics Support
+
+The following options control the features of SPICE.
+
+=over 4
+
+=item B<spice=BOOLEAN>
+
+Allow access to the display via the SPICE protocol.  This enables the
+other SPICE-related settings.
+
+=item B<spicehost="ADDRESS">
+
+Specify the interface address to listen on if given, otherwise any
+interface.
+
+=item B<spiceport=NUMBER>
+
+Specify the port to listen on by the SPICE server if the SPICE is
+enabled.
+
+=item B<spicetls_port=NUMBER>
+
+Specify the secure port to listen on by the SPICE server if the SPICE
+is enabled. At least one of the spiceport or spicetls_port must be
+given if SPICE is enabled.  NB. the options depending on spicetls_port
+have not been supported.
+
+=item B<spicedisable_ticketing=BOOLEAN>
+
+Enable client connection without password. When disabled, spicepasswd
+must be set. The default is 0.
+
+=item B<spicepasswd="PASSWORD">
+
+Specify the ticket password which is used by a client for connection.
+
+=item B<spiceagent_mouse=BOOLEAN>
+
+Whether SPICE agent is used for client mouse mode. The default is true
+(turn on)
+
+=back
+
+=head3 Miscellaneous Emulated Hardware
+
+=over 4
+
+=item B<serial=DEVICE>
+
+Redirect the virtual serial port to B<DEVICE>. Please see the
+B<-serial> option in the L<qemu(1)> manpage for details of the valid
+B<DEVICE> options. Default is B<vc> when in graphical mode and
+B<stdio> if B<nographics=1> is used.
+
+=item B<soundhw=DEVICE>
+
+Select the virtual sound card to expose to the guest. The valid
+devices are defined by the device model configuration, please see the
+L<qemu(1)> manpage for details. The default is not to export any sound
+device.
+
+=item B<usb=BOOLEAN>
+
+Enables or disables a USB bus in the guest.
+
+=item B<usbdevice=DEVICE>
+
+Adds B<DEVICE> to the USB bus. The USB bus must also be enabled using
+B<usb=1>. The most common use for this option is B<usbdevice=tablet>
+which adds pointer device using absolute coordinates. Such devices
+function better than relative coordinate devices (such as a standard
+mouse) since many methods of exporting guest graphics (such as VNC)
+work better in this mode. Note that this is independent of the actual
+pointer device you are using on the host/client side.
+
+=back
+
+=head2 Device-Model Options
+
+The following options control the selection of the device-model.  This
+is the component which provides emulation of the virtual devices to an
+HVM guest.  For a PV guest a device-model is sometimes used to provide
+backends for certain PV devices (most usually a virtual framebuffer
+device).
+
+=over 4
+
+=item B<device_model_version="DEVICE-MODEL">
+
+Selects which variant of the device-model should be used for this
+guest. Valid values are:
+
+=over 4
+
+=item B<qemu-xen-traditional>
+
+Use the device-model based upon the historical Xen fork of Qemu.  This
+device-model is currently the default.
+
+=item B<qemu-xen>
+
+use the device-model merged into the upstream QEMU project.  This
+device-model will become the default in a future version of Xen.
+
+=back
+
+It is recommended to accept the default value for new guests.  If
+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.
+
+=item B<device_model_override="PATH">
+
+Override the path to the binary to be used as the device-model. The
+binary provided here MUST be consistent with the
+`device_model_version` which you have specified. You should not
+normally need to specify this option.
+
+=item B<device_model_stubdomain_override=BOOLEAN>
+
+Override the use of stubdomain based device-model.  Normally this will
+be automatically selected based upon the other features and options
+you have selected.
+
+=item B<device_model_stubdomain_seclabel="LABEL">
+
+Assign an XSM security label to the device-model stubdomain.
+
+=item B<device_model_args=[ "ARG", "ARG", ...]>
+
+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 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 device-model command line for
+an HVM device model only. Each element in the list is passed as an
+option to the device-model.
 
 =back
 
@@ -1138,27 +1165,26 @@
 
 =item L<xl(1)>
 
+=item L<xlcpupool.cfg(5)>
+
 =item F<xl-disk-configuration>
 
 =item F<xl-network-configuration>
 
+=item F<docs/misc/tscmode.txt>
+
 =back
 
 =head1 FILES
 
 F</etc/xen/NAME.cfg>
 F</var/xen/dump/NAME>
-F<docs/misc/tscmode.txt>
 
 =head1 BUGS
 
-This document is a work in progress and contains items which require
-further documentation and which are generally incomplete (marked with
-XXX).  However all options are included here whether or not they are
-fully documented.
-
-Patches to improve incomplete items (or any other item) would be
-gratefully received on the xen-devel@lists.xen.org mailing
+This document may contain items which require further
+documentation. Patches to improve incomplete items (or any other item)
+are 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 Mon Sep 10 16:39:55 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Sep 2012 16:39: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 1TB71P-0005rN-T2; Mon, 10 Sep 2012 16:39:39 +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 1TB71O-0005rI-FI
	for xen-devel@lists.xen.org; Mon, 10 Sep 2012 16:39:38 +0000
Received: from [85.158.138.51:45644] by server-7.bemta-3.messagelabs.com id
	66/5B-32000-9C71E405; Mon, 10 Sep 2012 16:39:37 +0000
X-Env-Sender: msw@amazon.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1347295174!29745362!1
X-Originating-IP: [72.21.196.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNzIuMjEuMTk2LjI1ID0+IDEyNDU1OQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24470 invoked from network); 10 Sep 2012 16:39:35 -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;
	10 Sep 2012 16:39:35 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=amazon.com; i=msw@amazon.com; q=dns/txt; s=rte02;
	t=1347295176; x=1378831176;
	h=mime-version:content-transfer-encoding:subject:
	message-id:date:from:to:cc;
	bh=xNOEAGlkf2Rjy+bjQskB8v0KGLFBH7uCCWhUxJZdT5s=;
	b=m870DUBLrrQx27tVKO/ZU0gKNMl3czdfHfzCs8q54UXW1dMAHhFNrcC8
	84kr8LeDfeTvK4HQjLogBVDgUfDivA==;
X-IronPort-AV: E=Sophos;i="4.80,399,1344211200"; d="scan'208";a="437662921"
Received: from smtp-in-0191.sea3.amazon.com ([10.224.12.28])
	by smtp-border-fw-out-2101.iad2.amazon.com with
	ESMTP/TLS/DHE-RSA-AES256-SHA; 10 Sep 2012 16:39:32 +0000
Received: from ex10-hub-31005.ant.amazon.com (ex10-hub-31005.sea31.amazon.com
	[10.185.176.12])
	by smtp-in-0191.sea3.amazon.com (8.13.8/8.13.8) with ESMTP id
	q8AGdVTW014456
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL);
	Mon, 10 Sep 2012 16:39:31 GMT
Received: from u002268147cd4502c336d.ant.amazon.com (10.224.80.38) by
	ex10-hub-31005.ant.amazon.com (10.185.176.12) with Microsoft SMTP
	Server id 14.2.247.3; Mon, 10 Sep 2012 09:39:28 -0700
MIME-Version: 1.0
X-Mercurial-Node: 22452f41545c1786e88795682a64e224ff7c6d49
Message-ID: <22452f41545c1786e887.1347295130@u002268147cd4502c336d.ant.amazon.com>
User-Agent: Mercurial-patchbomb/2.3.1
Date: Mon, 10 Sep 2012 09:38:50 -0700
From: Matt Wilson <msw@amazon.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH v2] docs: flesh out xl.cfg documentation,
 correct typos, reorganize
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Some highlights:
 * Correct some markup errors:
       Around line 663:
           '=item' outside of any '=over'
       Around line 671:
           You forgot a '=back' before '=head3'
 * Add documentation for msitranslate, power_mgnt, acpi_s3, aspi_s4,
   gfx_passthru, nomigrate, etc.
 * Reorganize items in "unclassified" sections like cpuid,
   gfx_passthru to where they belong
 * Correct link L<> references so they can be resolved within the
   document
 * Remove placeholders for deprecated options device_model and vif2
 * Remove placeholder for "sched" and "node", as these are options for
   cpupool configuration. Perhaps cpupool configuration deserves
   a section in this document.
 * Rename "global" options to "general"
 * Add section headers to group general VM options.

Signed-off-by: Matt Wilson <msw@amazon.com>

---
Changes since v1:
  * integrate gfx_passthru documentation
  * correct typos
  * reference xlcpupool.cfg(5)

diff -r a1f73e989c24 -r 22452f41545c docs/man/xl.cfg.pod.5
--- a/docs/man/xl.cfg.pod.5	Mon Sep 10 16:47:31 2012 +0200
+++ b/docs/man/xl.cfg.pod.5	Mon Sep 10 09:33:02 2012 -0700
@@ -17,7 +17,7 @@
 
 A domain config file consists of a series of C<KEY=VALUE> pairs.
 
-Some C<KEY>s are mandatory, others are global options which apply to
+Some C<KEY>s are mandatory, others are general options which apply to
 any guest type while others relate only to specific guest types
 (e.g. PV or HVM guests).
 
@@ -80,21 +80,14 @@
 
 =back
 
-=head2 Global Options
+=head2 General Options
 
 The following options apply to guests of any type.
 
+=head3 CPU Allocation
+
 =over 4
 
-=item B<uuid="UUID">
-
-Specifies the UUID of the domain.  If not specified, a fresh unique
-UUID will be generated.
-
-=item B<vncviewer=BOOLEAN>
-
-Automatically spawn a vncviewer when creating/restoring a guest
-
 =item B<pool="CPUPOOLNAME">
 
 Put the guest's vcpus into the named cpu pool.
@@ -138,6 +131,12 @@
 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.
 
+=back
+
+=head3 CPU Scheduling
+
+=over 4
+
 =item B<cpu_weight=WEIGHT>
 
 A domain with a weight of 512 will get twice as much CPU as a domain
@@ -176,6 +175,12 @@
 Flag for allowing domain to run in extra time.
 Honoured by the sedf scheduler.
 
+=back
+
+=head3 Memory Allocation
+
+=over 4
+
 =item B<memory=MBYTES>
 
 Start the guest with MBYTES megabytes of RAM.
@@ -190,6 +195,12 @@
 A "pre-ballooned" HVM guest needs a balloon driver, without a balloon driver
 it will crash.
 
+=back
+
+=head3 Event Actions
+
+=over 4
+
 =item B<on_poweroff="ACTION">
 
 Specifies what should be done with the domain if it shuts itself down.
@@ -200,12 +211,12 @@
 =item B<destroy>
 
 destroy the domain
-     
+
 =item B<restart>
 
 destroy the domain and immediately create a new domain with the same
 configuration
-        
+
 =item B<rename-restart>
 
 rename the domain which terminated, and then immediately create a new
@@ -244,10 +255,28 @@
 
 Action to take if the domain crashes.  Default is C<destroy>.
 
+=back
+
+=head3 Other Options
+
+=over 4
+
+=item B<uuid="UUID">
+
+Specifies the UUID of the domain.  If not specified, a fresh unique
+UUID will be generated.
+
 =item B<seclabel="LABEL">
 
 Assign an XSM security label to this domain.
 
+=item B<nomigrate=BOOLEAN>
+
+Disable migration of this domain.  This enables certain other features
+which are incompatible with migration. Currently this is limited to
+enabling the invariant TSC feature flag in cpuid results when TSC is
+not emulated.
+
 =back
 
 =head2 Devices
@@ -309,7 +338,20 @@
 =item C<sdl=BOOLEAN>
 
 Specifies that the display should be presented via an X window (using
-Simple DirectMedia Layer). The default is to not enable this mode
+Simple DirectMedia Layer). The default is to not enable this mode.
+
+=item C<display=DISPLAY>
+
+Specifies the X Window display that should be used when the sdl option
+is used. Note: passing this value to the device-model is not currently
+implemented, so providing this option will have no effect.
+
+=item C<xauthority=XAUTHORITY>
+
+Specifies the path to the X authority file that should be used to
+connect to the X server when the sdl option is used. Note: passing
+this value to the device-model is not currently implemented, so
+providing this option will have no effect.
 
 =item C<opengl=BOOLEAN>
 
@@ -324,19 +366,9 @@
 (e.g. this is often the case when using VNC) then this allows us to
 correctly map the input keys into keycodes seen by the guest. The
 specific values which are accepted are defined by the version of the
-device-model which you are using. See L<Keymaps> below or consult the
+device-model which you are using. See L</"Keymaps"> below or consult the
 L<qemu(1)> manpage. The default is B<en-us>.
 
-=item C<display=XXX>
-
-XXX written to xenstore backend for vfb but does not appear to be used
-anywhere?
-
-=item C<authority=XXX>
-
-XXX written to xenstore backend for vfb but does not appear to be used
-anywhere?
-
 =back
 
 =item B<pci=[ "PCI_SPEC_STRING", "PCI_SPEC_STRING", ... ]>
@@ -348,7 +380,7 @@
 
 =item B<DDDD:BB:DD.F>
 
-identifies the PCI device from the host perspective in domain
+Identifies the PCI device from the host perspective in domain
 (B<DDDD>), Bus (B<BB>), Device (B<DD>) and Function (B<F>) syntax. This is
 the same scheme as used in the output of C<lspci> for the device in
 question. Note: By default C<lspci> will omit the domain (B<DDDD>) if it
@@ -357,9 +389,9 @@
 
 =item B<@VSLOT>
 
-specifies the virtual device where the guest will see this
+Specifies the virtual device where the guest will see this
 device. This is equivalent to the B<DD> which the guest sees. In a
-guest B<DDDD> and B<BB> are C<0000:00>. XXX how does this really work?
+guest B<DDDD> and B<BB> are C<0000:00>.
 
 =item B<KEY=VALUE>
 
@@ -367,14 +399,6 @@
 
 =over 4
 
-=item B<msitranslate=BOOLEAN>
-
-XXX
-
-=item B<power_mgmt=BOOLEAN>
-
-XXX
-
 =item B<permissive=BOOLEAN>
 
 (PV only) By default pciback only allows PV guests to write "known
@@ -386,6 +410,19 @@
 may have security or stability implications.  It is recommended to
 enable this option only for trusted VMs under administrator control.
 
+=item B<msitranslate=BOOLEAN>
+
+Specifies that MSI-INTx translation should be turned on for the PCI
+device. When enabled, MSI-INTx translation will always enable MSI on
+the PCI device regardless whether the guest uses INTx or MSI. Some
+device drivers, such as NVIDIA's, detect an inconsistency and do not
+function when this option is enabled. Therefore the default is 0.
+
+=item B<power_mgmt=BOOLEAN>
+
+(HVM only) Specifies that the VM should be able to program the
+D0-D3hot power management states for the PCI device. 0 by default.
+
 =back
 
 =back
@@ -393,19 +430,65 @@
 =item B<pci_permissive=BOOLEAN>
 
 (PV only) Changes the default value of 'permissive' for all PCI
-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
-for trusted VMs under administrator control.  See the "pci=" section
-for more information on the "permissive" flag.
+devices passed through to this VM. See L<permissive|/"permissive_boolean">
+above.
 
-=back
+=item B<pci_msitranslate=BOOLEAN>
+
+Changes the default value of 'msitranslate' for all PCI devices passed
+through to this VM. See L<msitranslate|/"msitranslate_boolean"> above.
+
+=item B<pci_power_mgmt=BOOLEAN>
+
+(HVM only) Changes the default value of 'power_mgmt' for all PCI
+devices passed through to this VM. See L<power_mgt|/"power_mgmt_boolean">
+above.
+
+=item B<gfx_passthru=BOOLEAN>
+
+Enable graphics device PCI passthrough. This option makes an assigned
+PCI graphics card become primary graphics card in the VM. The QEMU
+emulated graphics adapter is disabled and the VNC console for the VM
+will not have any graphics output. All graphics output, including boot
+time QEMU BIOS messages from the VM, will go to the physical outputs
+of the passedthrough physical graphics card.
+
+The graphics card PCI device to passthrough is chosen with B<pci>
+option, exactly in the same way as normal Xen PCI device
+passthrough/assignment is done.  Note that gfx_passthru does not do
+any kind of sharing of the GPU, so you can only assign the GPU to one
+single VM at a time.
+
+gfx_passthru also enables various legacy VGA memory ranges, BARs, MMIOs,
+and ioports to be passed thru to the VM, since those are required
+for correct operation of things like VGA BIOS, text mode, VBE, etc.
+
+Enabling gfx_passthru option also copies the physical graphics card
+video BIOS to the guest memory, and executes the VBIOS in the guest
+to initialize the graphics card.
+
+Most graphics adapters require vendor specific tweaks for properly
+working graphics passthrough. See the XenVGAPassthroughTestedAdapters
+L<http://wiki.xen.org/wiki/XenVGAPassthroughTestedAdapters> wiki page
+for currently supported graphics cards for gfx_passthru.
+
+gfx_passthru is currently only supported with the qemu-xen-traditional
+device-model. Upstream qemu-xen device-model currently does not have
+support for gfx_passthru.
+
+Note that some graphics adapters (AMD/ATI cards, for example) do not
+necessarily require gfx_passthru option, so you can use the normal Xen
+PCI passthrough to assign the graphics card as a secondary graphics
+card to the VM. The QEMU-emulated graphics card remains the primary
+graphics card, and VNC output is available from the QEMU-emulated
+primary adapter.
+
+More information about Xen gfx_passthru feature is available
+on the XenVGAPassthrough L<http://wiki.xen.org/wiki/XenVGAPassthrough>
+wiki page.
 
 =item B<ioports=[ "IOPORT_RANGE", "IOPORT_RANGE", ... ]>
 
-=over 4
-
 Allow guest to access specific legacy I/O ports. Each B<IOPORT_RANGE>
 is given in hexadecimal and may either a span e.g. C<2f8-2ff>
 (inclusive) or a single I/O port C<2f8>.
@@ -413,12 +496,8 @@
 It is recommended to use this option only for trusted VMs under
 administrator control.
 
-=back
-
 =item B<irqs=[ NUMBER, NUMBER, ... ]>
 
-=over 4
-
 Allow a guest to access specific physical IRQs.
 
 It is recommended to use this option only for trusted VMs under
@@ -471,12 +550,12 @@
 option is specified the virtual e820 instead reflects the host e820
 and contains the same PCI holes. The total amount of RAM represented
 by the memory map is always the same, this option configures only how
-it is layed out.
+it is laid 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 Operating System dependant whether this
+PCI devices. It is guest Operating System dependent 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 configured and false otherwise. If you do not
@@ -600,6 +679,16 @@
 default and usually you should omit it. However it may be necessary to
 disable ACPI for compatibility with some guest Operating Systems.
 
+=item B<acpi_s3=BOOLEAN>
+
+Include the S3 (suspend-to-ram) power state in the virtual firmware
+ACPI table. 1 by default.
+
+=item B<acpi_s4=BOOLEAN>
+
+Include S4 (suspend-to-disk) power state in the virtual firmware ACPI
+table. 1 by default.
+
 =item B<apic=BOOLEAN>
 
 Include information regarding APIC (Advanced Programmable Interrupt
@@ -637,414 +726,6 @@
 which uses hardware virtualisation extensions (e.g. Windows XP
 compatibility mode on more modern Windows OS).
 
-=back 
-
-=head3 Guest Virtual Time Controls
-
-=over 4
-
-=item B<tsc_mode="MODE">
-
-
-Specifies how the TSC (Time Stamp Counter) should be provided to the
-guest (X86 only). Specifying this option as a number is
-deprecated. Options are:
-
-=over 4
-
-=item B<"default">
-
-Guest rdtsc/p executed natively when monotonicity can be guaranteed
-and emulated otherwise (with frequency scaled if necessary).
-
-=item B<"always_emulate">
-
-Guest rdtsc/p always emulated at 1GHz (kernel and user). Guest rdtsc/p
-always emulated and the virtual TSC will appear to increment (kernel
-and user) at a fixed 1GHz rate, regardless of the PCPU HZ rate or
-power state; Although there is an overhead associated with emulation
-this will NOT affect underlying CPU performance.
-
-=item B<"native">
-
-Guest rdtsc always executed natively (no monotonicity/frequency
-guarantees); guest rdtscp emulated at native frequency if unsupported
-by h/w, else executed natively.
-
-=item B<"native_paravirt">
-
-Same as B<native>, except xen manages TSC_AUX register so guest can
-determine when a restore/migration has occurred and assumes guest
-obtains/uses pvclock-like mechanism to adjust for monotonicity and
-frequency changes.
-
-=back
-
-=back
-
-Please see F<docs/misc/tscmode.txt> for more information on this option.
-
-=item B<localtime=BOOLEAN>
-
-Set the real time clock to local time or to UTC. 0 by default, i.e. set to UTC.
-
-=item B<rtc_timeoffset=SECONDS>
-
-Set the real time clock offset in seconds. 0 by default.
-
-=head3 Support for Paravirtualisation of HVM Guests
-
-The following options allow Paravirtualised features (such as devices)
-to be exposed to the guest Operating System in an HVM guest.
-Utilising these features requires specific guest support but when
-available they will result in improved performance.
-
-=over 4
-
-=item B<xen_platform_pci=BOOLEAN>
-
-Enable or disable the Xen platform PCI device.  The presence of this
-virtual device enables a guest Operating System (subject to the
-availability of suitable drivers) to make use of paravirtualisation
-features such as disk and network devices etc. Enabling these drivers
-improves performance and is strongly recommended when available. PV
-drivers are available for various Operating Systems including HVM
-Linux L<http://wiki.xen.org/wiki/XenLinuxPVonHVMdrivers> and Microsoft
-Windows L<http://wiki.xen.org/wiki/XenWindowsGplPv>.
-
-=item B<viridian=BOOLEAN>
-
-Turns on or off the exposure of MicroSoft Hyper-V (AKA viridian)
-compatible enlightenments to the guest.  These can improve performance
-of Microsoft Windows guests from Windows Vista and Windows 2008
-onwards and setting this option for such guests is strongly
-recommended. This option should be harmless for other versions of
-Windows (although it won't give any benefit) and the majority of other
-non-Windows OSes. However it is known to be incompatible with some
-other Operating Systems and in some circumstance can prevent Xen's own
-paravirtualisation interfaces for HVM guests from being used.
-
-=back
-
-=head3 Emulated VGA Graphics Device
-
-The following options control the features of the emulated graphics
-device.  Many of these options behave similarly to the equivalent key
-in the B<VFB_SPEC_STRING> for configuring virtual frame buffer devices
-(see above).
-
-=over 4
-
-=item B<videoram=MBYTES>
-
-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 amount of video ram for stdvga is 8MB which is sufficient
-for e.g. 1600x1200 at 32bpp.
-
-When using the emulated Cirrus graphics card (B<stdvga=0>)
-the amount of video ram is fixed at 4MB which is sufficient
-for 1024x768 at 32 bpp.
-
-videoram option is currently only available when using the
-qemu-xen-traditional device-model. Upstream qemu-xen device-model
-currently doesn't support changing the amount of video memory
-for the emulated graphics device.
-
-=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.
-stdvga supports more video ram and bigger resolutions than Cirrus.
-
-=item B<vnc=BOOLEAN>
-
-Allow access to the display via the VNC protocol.  This enables the
-other VNC-related settings.  The default is to enable this.
-
-=item B<vnclisten="ADDRESS[:DISPLAYNUM]">
-
-Specifies the IP address, and optionally VNC display number, to use.
-
-=item B<vncdisplay=DISPLAYNUM>
-
-Specifies the VNC display number to use. The actual TCP port number
-will be DISPLAYNUM+5900.
-
-=item B<vncunused=BOOLEAN>
-
-Requests that the VNC display setup search for a free TCP port to use.
-The actual display used can be accessed with C<xl vncviewer>.
-
-=item B<vncpasswd="PASSWORD">
-
-Specifies the password for the VNC server.
-
-=item B<keymap="LANG">
-
-Configure the keymap to use for the keyboard associated with this
-display. If the input method does not easily support raw keycodes
-(e.g. this is often the case when using VNC) then this allows us to
-correctly map the input keys into keycodes seen by the guest. The
-specific values which are accepted are defined by the version of the
-device-model which you are using. See L<Keymaps> below of consult the
-L<qemu(1)> manpage. The default is B<en-us>.
-
-=item B<sdl=BOOLEAN>
-
-Specifies that the display should be presented via an X window (using
-Simple DirectMedia Layer). The default is not to enable this mode.
-
-=item B<opengl=BOOLEAN>
-
-Enable OpenGL acceleration of the SDL display. Only effects machines
-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>
-
-Enable or disable the virtual graphics device.  The default is to
-provide a VGA graphics device but this option can be used to disable
-it.
-
-=back
-
-=head3 Spice Graphics Support
-
-The following options control the features of SPICE.
-
-=over 4
-
-=item B<spice=BOOLEAN>
-
-Allow access to the display via the SPICE protocol.  This enables the
-other SPICE-related settings.
-
-=item B<spicehost="ADDRESS">
-
-Specify the interface address to listen on if given, otherwise any
-interface.
-
-=item B<spiceport=NUMBER>
-
-Specify the port to listen on by the SPICE server if the SPICE is
-enabled.
-
-=item B<spicetls_port=NUMBER>
-
-Specify the secure port to listen on by the SPICE server if the SPICE
-is enabled. At least one of the spiceport or spicetls_port must be
-given if SPICE is enabled.  NB. the options depending on spicetls_port
-have not been supported.
-
-=item B<spicedisable_ticketing=BOOLEAN>
-
-Enable client connection without password. The default is false. If
-it's false (set to 0), spicepasswd must be set.
-
-=item B<spicepasswd="PASSWORD">
-
-Specify the ticket password which is used by a client for connection.
-
-=item B<spiceagent_mouse=BOOLEAN>
-
-Whether SPICE agent is used for client mouse mode. The default is true
-(turn on)
-
-=back
-
-=head3 Miscellaneous Emulated Hardware
-
-=over 4
-
-=item B<serial=DEVICE>
-
-Redirect the virtual serial port to B<DEVICE>. Please see the
-B<-serial> option in the L<qemu(1)> manpage for details of the valid
-B<DEVICE> options. Default is B<vc> when in graphical mode and
-B<stdio> if B<nographics=1> is used.
-
-=item B<soundhw=DEVICE>
-
-Select the virtual sound card to expose to the guest. The valid
-devices are defined by the device model configuration, please see the
-L<qemu(1)> manpage for details. The default is not to export any sound
-device.
-
-=item B<usb=BOOLEAN>
-
-Enables or disables a USB bus in the guest.
-
-=item B<usbdevice=DEVICE>
-
-Adds B<DEVICE> to the USB bus. The USB bus must also be enabled using
-B<usb=1>. The most common use for this option is B<usbdevice=tablet>
-which adds pointer device using absolute coordinates. Such devices
-function better than relative coordinate devices (such as a standard
-mouse) since many methods of exporting guest graphics (such as VNC)
-work better in this mode. Note that this is independent of the actual
-pointer device you are using on the host/client side. XXX should/could
-be a list of devices.
-
-=back
-
-=head3 Unclassified HVM Specific Options
-
-These HVM specific options have not yet been documented or
-classified. They almost certainly belong in a more appropriate
-section.
-
-=over 4
-
-=item B<vpt_align=BOOLEAN>
-
-Align the Virtual Platform Timer ??? XXX Reduces interrupts?
-
-=item B<timer_mode=NUMBER>
-
-Set mode for Virtual Timers XXX ??? should be an enum of particular
-values. See C<HVM_PARAM_TIMER_MODE> in
-F<xen/include/public/hvm/params.h>.
-
-=back
-
-=head2 Device-Model Options
-
-The following options control the selection of the device-model.  This
-is the component which provides emulation of the virtual devices to an
-HVM guest.  For a PV guest a device-model is sometimes used to provide
-backends for certain PV devices (most usually a virtual framebuffer
-device).
-
-=over 4
-
-=item B<device_model_version="DEVICE-MODEL">
-
-Selects which variant of the device-model should be used for this
-guest. Valid values are:
-
-=over 4
-
-=item B<qemu-xen-traditional>
-
-Use the device-model based upon the historical Xen fork of Qemu.  This
-device-model is currently the default.
-
-=item B<qemu-xen>
-
-use the device-model merged into the upstream Qemu project.  This
-device-model will become the default in a future version of Xen.
-
-=back
-
-It is recommended to accept the default value for new guests.  If
-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.
-
-=item B<device_model_override="PATH">
-
-Override the path to the binary to be used as the device-model. The
-binary provided here MUST be consistent with the
-`device_model_version` which you have specified. You should not
-normally need to specify this option.
-
-=item B<device_model_stubdomain_override=BOOLEAN>
-
-Override the use of stubdomain based device-model.  Normally this will
-be automatically selected based upon the other features and options
-you have selected.
-
-=item B<device_model_stubdomain_seclabel="LABEL">
-
-Assign an XSM security label to the device-model stubdomain.
-
-=item B<device_model_args=[ "ARG", "ARG", ...]>
-
-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 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 device-model command line for
-an HVM device model only. Each element in the list is passed as an
-option to the device-model.
-
-=back
-
-=head2 Unclassified General Options
-
-These have not yet been fully documented or classified. They almost
-certainly belong in a more appropriate section.
-
-=over 4
-
-=item B<gfx_passthru=BOOLEAN>
-
-Enable graphics device PCI passthrough. This option makes the passthru
-graphics card become primary graphics card in the VM, so the Qemu emulated
-graphics adapter is disabled, and the VNC console for the VM won't have
-any graphics output. All graphics output, including boot time Qemu BIOS
-messages from the VM, will go to the physical outputs of the passed thru
-physical graphics card.
-
-Graphics card PCI device to passthru is chosen with B<pci> option,
-exactly in the same way as normal Xen PCI device passthru/assignment is done.
-Note that gfx_passthru doesn't do any kind of sharing
-of the GPU, so you can only assign the GPU to one single VM at a time.
-
-gfx_passthru also enables various legacy VGA memory ranges, BARs, MMIOs,
-and ioports to be passed thru to the VM, since those are required
-for correct operation of things like VGA BIOS, text mode, VBE, etc.
-
-Enabling gfx_passthru option also copies the physical graphics card
-video BIOS to the guest memory, and executes the VBIOS in the guest
-to get the graphics card initialized.
-
-Most graphics adapters require vendor specific tweaks for properly
-working graphics passthru. See the XenVGAPassthroughTestedAdapters
-L<http://wiki.xen.org/wiki/XenVGAPassthroughTestedAdapters>
-wiki page for currently supported graphics cards for gfx_passthru.
-
-gfx_passthru is currently only supported with the qemu-xen-traditional
-device-model. Upstream qemu-xen device-model currently doesn't have
-support for gfx_passthru.
-
-Note that some graphics adapters (AMD/ATI cards, for example) don't
-necessarily require gfx_passthru option, so you can use the normal
-Xen PCI passthru to assign the graphics card as a secondary graphics card
-to the VM. Qemu emulated graphics card stays as the primary graphics card,
-and you get VNC output from the Qemu-emulated primary adapter.
-
-More information about Xen gfx_passthru feature is available
-on the XenVGAPassthrough L<http://wiki.xen.org/wiki/XenVGAPassthrough>
-wiki page.
-
-=item B<nomigrate=BOOLEAN>
-
-Disable migration of this domain.  This enables certain other features
-which are incompatible with migration (currently certain TSC modes XXX
-?).
-
-=item B<pci_msitranslate=BOOLEAN>
-
-XXX
-
-=item B<pci_power_mgmt=BOOLEAN>
-
-XXX
-
 =item B<cpuid="LIBXL_STRING"> or B<cpuid=[ "XEND_STRING", "XEND_STRING" ]>
 
 Configure the value returned when a guest executes CPUID instruction.
@@ -1093,29 +774,375 @@
 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>
+=back 
 
-XXX
+=head3 Guest Virtual Time Controls
 
-=item B<acpi_s3=BOOLEAN>
+=over 4
 
-XXX
+=item B<tsc_mode="MODE">
 
-=item B<nodes=XXX>
 
-XXX
+Specifies how the TSC (Time Stamp Counter) should be provided to the
+guest (X86 only). Specifying this option as a number is
+deprecated. Options are:
 
-=item B<sched=XXX>
+=over 4
 
-XXX
+=item B<"default">
 
-=item B<device_model=XXX>
+Guest rdtsc/p executed natively when monotonicity can be guaranteed
+and emulated otherwise (with frequency scaled if necessary).
 
-XXX deprecated
+=item B<"always_emulate">
 
-=item B<vif2=XXX>
+Guest rdtsc/p always emulated at 1GHz (kernel and user). Guest rdtsc/p
+always emulated and the virtual TSC will appear to increment (kernel
+and user) at a fixed 1GHz rate, regardless of the PCPU HZ rate or
+power state; Although there is an overhead associated with emulation
+this will NOT affect underlying CPU performance.
 
-XXX deprecated
+=item B<"native">
+
+Guest rdtsc always executed natively (no monotonicity/frequency
+guarantees); guest rdtscp emulated at native frequency if unsupported
+by h/w, else executed natively.
+
+=item B<"native_paravirt">
+
+Same as B<native>, except xen manages TSC_AUX register so guest can
+determine when a restore/migration has occurred and assumes guest
+obtains/uses pvclock-like mechanism to adjust for monotonicity and
+frequency changes.
+
+=back
+
+Please see F<docs/misc/tscmode.txt> for more information on this option.
+
+=item B<localtime=BOOLEAN>
+
+Set the real time clock to local time or to UTC. 0 by default, i.e. set to UTC.
+
+=item B<rtc_timeoffset=SECONDS>
+
+Set the real time clock offset in seconds. 0 by default.
+
+
+=item B<vpt_align=BOOLEAN>
+
+Specifies that periodic Virtual Platform Timers should be aligned to
+reduce guest interrupts. Enabling this option can reduce power
+consumption, especially when a guest uses a high timer interrupt
+frequency (HZ) values. The default is 1.
+
+=item B<timer_mode=MODE>
+
+Specifies the mode for Virtual Timers. The valid values are as follows:
+
+=over 4
+
+=item B<"delay_for_missed_ticks">
+
+Delay for missed ticks. Do not advance a vcpu's time beyond the
+correct delivery time for interrupts that have been missed due to
+preemption. Deliver missed interrupts when the vcpu is rescheduled and
+advance the vcpu's virtual time stepwise for each one.
+
+=item B<"no_delay_for_missed_ticks">
+
+No delay for missed ticks. As above, missed interrupts are delivered,
+but guest time always tracks wallclock (i.e., real) time while doing
+so.
+
+=item B<"no_missed_ticks_pending">
+
+No missed interrupts are held pending. Instead, to ensure ticks are
+delivered at some non-zero rate, if we detect missed ticks then the
+internal tick alarm is not disabled if the VCPU is preempted during
+the next tick period.
+
+=item B<"one_missed_tick_pending">
+
+One missed tick pending. Missed interrupts are collapsed
+together and delivered as one 'late tick'.  Guest time always tracks
+wallclock (i.e., real) time.
+
+=back
+
+=back
+
+=head3 Support for Paravirtualisation of HVM Guests
+
+The following options allow Paravirtualised features (such as devices)
+to be exposed to the guest Operating System in an HVM guest.
+Utilising these features requires specific guest support but when
+available they will result in improved performance.
+
+=over 4
+
+=item B<xen_platform_pci=BOOLEAN>
+
+Enable or disable the Xen platform PCI device.  The presence of this
+virtual device enables a guest Operating System (subject to the
+availability of suitable drivers) to make use of paravirtualisation
+features such as disk and network devices etc. Enabling these drivers
+improves performance and is strongly recommended when available. PV
+drivers are available for various Operating Systems including HVM
+Linux L<http://wiki.xen.org/wiki/XenLinuxPVonHVMdrivers> and Microsoft
+Windows L<http://wiki.xen.org/wiki/XenWindowsGplPv>.
+
+=item B<viridian=BOOLEAN>
+
+Turns on or off the exposure of MicroSoft Hyper-V (AKA viridian)
+compatible enlightenments to the guest.  These can improve performance
+of Microsoft Windows guests from Windows Vista and Windows 2008
+onwards and setting this option for such guests is strongly
+recommended. This option should be harmless for other versions of
+Windows (although it will not give any benefit) and the majority of
+other non-Windows OSes. However it is known to be incompatible with
+some other Operating Systems and in some circumstance can prevent
+Xen's own paravirtualisation interfaces for HVM guests from being
+used.
+
+=back
+
+=head3 Emulated VGA Graphics Device
+
+The following options control the features of the emulated graphics
+device.  Many of these options behave similarly to the equivalent key
+in the B<VFB_SPEC_STRING> for configuring virtual frame buffer devices
+(see above).
+
+=over 4
+
+=item B<videoram=MBYTES>
+
+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 amount of video ram for stdvga is 8MB which is sufficient
+for e.g. 1600x1200 at 32bpp.
+
+When using the emulated Cirrus graphics card (B<stdvga=0>)
+the amount of video ram is fixed at 4MB which is sufficient
+for 1024x768 at 32 bpp.
+
+videoram option is currently only available when using the
+qemu-xen-traditional device-model. Upstream qemu-xen device-model
+currently does not support changing the amount of video memory for the
+emulated graphics device.
+
+=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.
+stdvga supports more video ram and bigger resolutions than Cirrus.
+
+=item B<vnc=BOOLEAN>
+
+Allow access to the display via the VNC protocol.  This enables the
+other VNC-related settings.  The default is to enable this.
+
+=item B<vncviewer=BOOLEAN>
+
+Automatically spawn a vncviewer when creating/restoring a guest.
+
+=item B<vnclisten="ADDRESS[:DISPLAYNUM]">
+
+Specifies the IP address, and optionally VNC display number, to use.
+
+=item B<vncdisplay=DISPLAYNUM>
+
+Specifies the VNC display number to use. The actual TCP port number
+will be DISPLAYNUM+5900.
+
+=item B<vncunused=BOOLEAN>
+
+Requests that the VNC display setup search for a free TCP port to use.
+The actual display used can be accessed with C<xl vncviewer>.
+
+=item B<vncpasswd="PASSWORD">
+
+Specifies the password for the VNC server.
+
+=item B<keymap="LANG">
+
+Configure the keymap to use for the keyboard associated with this
+display. If the input method does not easily support raw keycodes
+(e.g. this is often the case when using VNC) then this allows us to
+correctly map the input keys into keycodes seen by the guest. The
+specific values which are accepted are defined by the version of the
+device-model which you are using. See L</"Keymaps"> below or consult the
+L<qemu(1)> manpage. The default is B<en-us>.
+
+=item B<sdl=BOOLEAN>
+
+Specifies that the display should be presented via an X window (using
+Simple DirectMedia Layer). The default is not to enable this mode.
+
+=item B<opengl=BOOLEAN>
+
+Enable OpenGL acceleration of the SDL display. Only effects machines
+using B<device_model_version="qemu-xen-traditional"> and only if the
+device-model was compiled with OpenGL support. 0 by default.
+
+=item B<nographic=BOOLEAN>
+
+Enable or disable the virtual graphics device.  The default is to
+provide a VGA graphics device but this option can be used to disable
+it.
+
+=back
+
+=head3 Spice Graphics Support
+
+The following options control the features of SPICE.
+
+=over 4
+
+=item B<spice=BOOLEAN>
+
+Allow access to the display via the SPICE protocol.  This enables the
+other SPICE-related settings.
+
+=item B<spicehost="ADDRESS">
+
+Specify the interface address to listen on if given, otherwise any
+interface.
+
+=item B<spiceport=NUMBER>
+
+Specify the port to listen on by the SPICE server if the SPICE is
+enabled.
+
+=item B<spicetls_port=NUMBER>
+
+Specify the secure port to listen on by the SPICE server if the SPICE
+is enabled. At least one of the spiceport or spicetls_port must be
+given if SPICE is enabled.  NB. the options depending on spicetls_port
+have not been supported.
+
+=item B<spicedisable_ticketing=BOOLEAN>
+
+Enable client connection without password. When disabled, spicepasswd
+must be set. The default is 0.
+
+=item B<spicepasswd="PASSWORD">
+
+Specify the ticket password which is used by a client for connection.
+
+=item B<spiceagent_mouse=BOOLEAN>
+
+Whether SPICE agent is used for client mouse mode. The default is true
+(turn on)
+
+=back
+
+=head3 Miscellaneous Emulated Hardware
+
+=over 4
+
+=item B<serial=DEVICE>
+
+Redirect the virtual serial port to B<DEVICE>. Please see the
+B<-serial> option in the L<qemu(1)> manpage for details of the valid
+B<DEVICE> options. Default is B<vc> when in graphical mode and
+B<stdio> if B<nographics=1> is used.
+
+=item B<soundhw=DEVICE>
+
+Select the virtual sound card to expose to the guest. The valid
+devices are defined by the device model configuration, please see the
+L<qemu(1)> manpage for details. The default is not to export any sound
+device.
+
+=item B<usb=BOOLEAN>
+
+Enables or disables a USB bus in the guest.
+
+=item B<usbdevice=DEVICE>
+
+Adds B<DEVICE> to the USB bus. The USB bus must also be enabled using
+B<usb=1>. The most common use for this option is B<usbdevice=tablet>
+which adds pointer device using absolute coordinates. Such devices
+function better than relative coordinate devices (such as a standard
+mouse) since many methods of exporting guest graphics (such as VNC)
+work better in this mode. Note that this is independent of the actual
+pointer device you are using on the host/client side.
+
+=back
+
+=head2 Device-Model Options
+
+The following options control the selection of the device-model.  This
+is the component which provides emulation of the virtual devices to an
+HVM guest.  For a PV guest a device-model is sometimes used to provide
+backends for certain PV devices (most usually a virtual framebuffer
+device).
+
+=over 4
+
+=item B<device_model_version="DEVICE-MODEL">
+
+Selects which variant of the device-model should be used for this
+guest. Valid values are:
+
+=over 4
+
+=item B<qemu-xen-traditional>
+
+Use the device-model based upon the historical Xen fork of Qemu.  This
+device-model is currently the default.
+
+=item B<qemu-xen>
+
+use the device-model merged into the upstream QEMU project.  This
+device-model will become the default in a future version of Xen.
+
+=back
+
+It is recommended to accept the default value for new guests.  If
+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.
+
+=item B<device_model_override="PATH">
+
+Override the path to the binary to be used as the device-model. The
+binary provided here MUST be consistent with the
+`device_model_version` which you have specified. You should not
+normally need to specify this option.
+
+=item B<device_model_stubdomain_override=BOOLEAN>
+
+Override the use of stubdomain based device-model.  Normally this will
+be automatically selected based upon the other features and options
+you have selected.
+
+=item B<device_model_stubdomain_seclabel="LABEL">
+
+Assign an XSM security label to the device-model stubdomain.
+
+=item B<device_model_args=[ "ARG", "ARG", ...]>
+
+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 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 device-model command line for
+an HVM device model only. Each element in the list is passed as an
+option to the device-model.
 
 =back
 
@@ -1138,27 +1165,26 @@
 
 =item L<xl(1)>
 
+=item L<xlcpupool.cfg(5)>
+
 =item F<xl-disk-configuration>
 
 =item F<xl-network-configuration>
 
+=item F<docs/misc/tscmode.txt>
+
 =back
 
 =head1 FILES
 
 F</etc/xen/NAME.cfg>
 F</var/xen/dump/NAME>
-F<docs/misc/tscmode.txt>
 
 =head1 BUGS
 
-This document is a work in progress and contains items which require
-further documentation and which are generally incomplete (marked with
-XXX).  However all options are included here whether or not they are
-fully documented.
-
-Patches to improve incomplete items (or any other item) would be
-gratefully received on the xen-devel@lists.xen.org mailing
+This document may contain items which require further
+documentation. Patches to improve incomplete items (or any other item)
+are 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 Mon Sep 10 16:56:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Sep 2012 16:56:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TB7Gv-00063b-Nr; Mon, 10 Sep 2012 16:55:41 +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 1TB7Gt-00063W-Lu
	for xen-devel@lists.xen.org; Mon, 10 Sep 2012 16:55:39 +0000
Received: from [85.158.143.35:65060] by server-1.bemta-4.messagelabs.com id
	4A/66-12504-A8B1E405; Mon, 10 Sep 2012 16:55:38 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1347296136!5864466!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-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15908 invoked from network); 10 Sep 2012 16:55:36 -0000
Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com)
	(74.125.83.45)
	by server-4.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Sep 2012 16:55:36 -0000
Received: by eeke53 with SMTP id e53so1390208eek.32
	for <xen-devel@lists.xen.org>; Mon, 10 Sep 2012 09:55:36 -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=YMd/jKD3AH8ZBHt9kXAwCuL8HQHwxCDIAgZoVKAzslg=;
	b=aTJzYgkeRDjq/o6+q9s32J7Wfhn4Wzs79/isv6Tm8r4Eg6Svc+W0KtqNjwmOApCbJG
	MzFyveBltgapxHfif69bVyNTdhC6NfsX3HhGEIvi922DBcxsQ68T0YAGv79CXw73qI5/
	axvj7DjbLvQYOewdBkRR4ZYzNFow43psJxrywdjRmYoqBvZF2TZLdhmCpPnVAkFOa8X+
	tN97XdAV3Op9eymJxdk3H6mXZU0oMwd1S99OLT3oQJ87Q0cU7EGop/TxjBcYTF7dGYIZ
	2TPqEM1gM4RGBWg/s79mZ+CzIq8Ygt5QNmogmda2jgKZq7WBC+7Gb3j9jncHZJbGm2Vb
	vykA==
Received: by 10.14.209.129 with SMTP id s1mr20771746eeo.24.1347296136321;
	Mon, 10 Sep 2012 09:55:36 -0700 (PDT)
Received: from [192.168.1.69] (host86-184-74-117.range86-184.btcentralplus.com.
	[86.184.74.117])
	by mx.google.com with ESMTPS id h2sm39714857eeo.3.2012.09.10.09.55.31
	(version=SSLv3 cipher=OTHER); Mon, 10 Sep 2012 09:55:34 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Mon, 10 Sep 2012 17:55:27 +0100
From: Keir Fraser <keir.xen@gmail.com>
To: David Vrabel <david.vrabel@citrix.com>
Message-ID: <CC73DA0F.3E425%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [ANNOUNCE] Xen x86 32-bit hypervisor end of life
	after 4.2
Thread-Index: Ac2PdRPQuXl0ElU6BkWL9kt3SyS9/w==
In-Reply-To: <504E1458.70606@citrix.com>
Mime-version: 1.0
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [ANNOUNCE] Xen x86 32-bit hypervisor end of life
 after 4.2
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 10/09/2012 17:24, "David Vrabel" <david.vrabel@citrix.com> wrote:

> On 09/09/12 12:11, Keir Fraser wrote:
>> Folks,
>> 
>> With 64-bit support well established in the x86 world these days, the number
>> of x86 production environments that cannot run a 64-bit hypervisor is pretty
>> much nil. Maintaining the 32-bit x86 port, and implementing new features for
>> it, is an ongoing development burden which could be more usefully directed
>> elsewhere. Therefore, 32-bit x86 will be considered obsolete in the 4.3
>> development branch, and removed.
> 
> I have some tracing patches that have some 32-bit/64-bit #ifdef'ery.
> Would you prefer them posted now, or deferred until 32-bit is gone?

If it's not too intricate then post them now, and we'll strip out the 32-bit
parts later. I don't think we should hold up pending patches for this.
Although I'm holding back some further development in anticipation of it. :)

 -- Keir

> David



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 10 16:56:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Sep 2012 16:56:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TB7Gv-00063b-Nr; Mon, 10 Sep 2012 16:55:41 +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 1TB7Gt-00063W-Lu
	for xen-devel@lists.xen.org; Mon, 10 Sep 2012 16:55:39 +0000
Received: from [85.158.143.35:65060] by server-1.bemta-4.messagelabs.com id
	4A/66-12504-A8B1E405; Mon, 10 Sep 2012 16:55:38 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1347296136!5864466!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-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15908 invoked from network); 10 Sep 2012 16:55:36 -0000
Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com)
	(74.125.83.45)
	by server-4.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Sep 2012 16:55:36 -0000
Received: by eeke53 with SMTP id e53so1390208eek.32
	for <xen-devel@lists.xen.org>; Mon, 10 Sep 2012 09:55:36 -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=YMd/jKD3AH8ZBHt9kXAwCuL8HQHwxCDIAgZoVKAzslg=;
	b=aTJzYgkeRDjq/o6+q9s32J7Wfhn4Wzs79/isv6Tm8r4Eg6Svc+W0KtqNjwmOApCbJG
	MzFyveBltgapxHfif69bVyNTdhC6NfsX3HhGEIvi922DBcxsQ68T0YAGv79CXw73qI5/
	axvj7DjbLvQYOewdBkRR4ZYzNFow43psJxrywdjRmYoqBvZF2TZLdhmCpPnVAkFOa8X+
	tN97XdAV3Op9eymJxdk3H6mXZU0oMwd1S99OLT3oQJ87Q0cU7EGop/TxjBcYTF7dGYIZ
	2TPqEM1gM4RGBWg/s79mZ+CzIq8Ygt5QNmogmda2jgKZq7WBC+7Gb3j9jncHZJbGm2Vb
	vykA==
Received: by 10.14.209.129 with SMTP id s1mr20771746eeo.24.1347296136321;
	Mon, 10 Sep 2012 09:55:36 -0700 (PDT)
Received: from [192.168.1.69] (host86-184-74-117.range86-184.btcentralplus.com.
	[86.184.74.117])
	by mx.google.com with ESMTPS id h2sm39714857eeo.3.2012.09.10.09.55.31
	(version=SSLv3 cipher=OTHER); Mon, 10 Sep 2012 09:55:34 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Mon, 10 Sep 2012 17:55:27 +0100
From: Keir Fraser <keir.xen@gmail.com>
To: David Vrabel <david.vrabel@citrix.com>
Message-ID: <CC73DA0F.3E425%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [ANNOUNCE] Xen x86 32-bit hypervisor end of life
	after 4.2
Thread-Index: Ac2PdRPQuXl0ElU6BkWL9kt3SyS9/w==
In-Reply-To: <504E1458.70606@citrix.com>
Mime-version: 1.0
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [ANNOUNCE] Xen x86 32-bit hypervisor end of life
 after 4.2
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 10/09/2012 17:24, "David Vrabel" <david.vrabel@citrix.com> wrote:

> On 09/09/12 12:11, Keir Fraser wrote:
>> Folks,
>> 
>> With 64-bit support well established in the x86 world these days, the number
>> of x86 production environments that cannot run a 64-bit hypervisor is pretty
>> much nil. Maintaining the 32-bit x86 port, and implementing new features for
>> it, is an ongoing development burden which could be more usefully directed
>> elsewhere. Therefore, 32-bit x86 will be considered obsolete in the 4.3
>> development branch, and removed.
> 
> I have some tracing patches that have some 32-bit/64-bit #ifdef'ery.
> Would you prefer them posted now, or deferred until 32-bit is gone?

If it's not too intricate then post them now, and we'll strip out the 32-bit
parts later. I don't think we should hold up pending patches for this.
Although I'm holding back some further development in anticipation of it. :)

 -- Keir

> David



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 10 17:09:54 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Sep 2012 17: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 1TB7UP-0006Xk-1D; Mon, 10 Sep 2012 17:09:37 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1TB7UN-0006Xf-SY
	for xen-devel@lists.xen.org; Mon, 10 Sep 2012 17:09:36 +0000
Received: from [85.158.138.51:62540] by server-12.bemta-3.messagelabs.com id
	C2/B1-10384-FCE1E405; Mon, 10 Sep 2012 17:09:35 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1347296974!29749507!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTIyODk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29260 invoked from network); 10 Sep 2012 17:09:34 -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;
	10 Sep 2012 17:09:34 -0000
X-IronPort-AV: E=Sophos;i="4.80,398,1344211200"; d="scan'208";a="14451371"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Sep 2012 17:09: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.279.1; Mon, 10 Sep 2012 18:09: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
	1TB7Tu-0006jh-Bz; Mon, 10 Sep 2012 17:09:06 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1TB7Tu-0005TU-6d;
	Mon, 10 Sep 2012 18:09:06 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20558.7857.884864.696876@mariner.uk.xensource.com>
Date: Mon, 10 Sep 2012 18:09:05 +0100
To: Keir Fraser <keir.xen@gmail.com>
In-Reply-To: <CC73B65B.3E3D4%keir.xen@gmail.com>
References: <20557.63015.552841.739252@mariner.uk.xensource.com>
	<CC73B65B.3E3D4%keir.xen@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] [ANNOUNCE] Xen x86 32-bit hypervisor end of life
	after 4.2
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Keir Fraser writes ("Re: [ANNOUNCE] Xen x86 32-bit hypervisor end of life after 4.2"):
> On 10/09/2012 15:16, "Ian Jackson" <Ian.Jackson@eu.citrix.com> wrote:
> > I will do this but I have a number of other things which need to go
> > through the autotester's tests of itself, first.  I'll let you know
> > when it's done.
> 
> A self-aware autotester. :)

As you say.

> Well that's fine. It doesn't have to be done in a huge hurry.

I've been looking into this and have a draft of a suitable change.
But: can you confirm that typing "make" will still work on a 32-bit
system and generate a working tools build ?  I don't care what
hypervisor (if any) it builds, but it has to succeed because that's
how I build the tools for use in 32-bit dom0s.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 10 17:09:54 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Sep 2012 17: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 1TB7UP-0006Xk-1D; Mon, 10 Sep 2012 17:09:37 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1TB7UN-0006Xf-SY
	for xen-devel@lists.xen.org; Mon, 10 Sep 2012 17:09:36 +0000
Received: from [85.158.138.51:62540] by server-12.bemta-3.messagelabs.com id
	C2/B1-10384-FCE1E405; Mon, 10 Sep 2012 17:09:35 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1347296974!29749507!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTIyODk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29260 invoked from network); 10 Sep 2012 17:09:34 -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;
	10 Sep 2012 17:09:34 -0000
X-IronPort-AV: E=Sophos;i="4.80,398,1344211200"; d="scan'208";a="14451371"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Sep 2012 17:09: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.279.1; Mon, 10 Sep 2012 18:09: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
	1TB7Tu-0006jh-Bz; Mon, 10 Sep 2012 17:09:06 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1TB7Tu-0005TU-6d;
	Mon, 10 Sep 2012 18:09:06 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20558.7857.884864.696876@mariner.uk.xensource.com>
Date: Mon, 10 Sep 2012 18:09:05 +0100
To: Keir Fraser <keir.xen@gmail.com>
In-Reply-To: <CC73B65B.3E3D4%keir.xen@gmail.com>
References: <20557.63015.552841.739252@mariner.uk.xensource.com>
	<CC73B65B.3E3D4%keir.xen@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] [ANNOUNCE] Xen x86 32-bit hypervisor end of life
	after 4.2
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Keir Fraser writes ("Re: [ANNOUNCE] Xen x86 32-bit hypervisor end of life after 4.2"):
> On 10/09/2012 15:16, "Ian Jackson" <Ian.Jackson@eu.citrix.com> wrote:
> > I will do this but I have a number of other things which need to go
> > through the autotester's tests of itself, first.  I'll let you know
> > when it's done.
> 
> A self-aware autotester. :)

As you say.

> Well that's fine. It doesn't have to be done in a huge hurry.

I've been looking into this and have a draft of a suitable change.
But: can you confirm that typing "make" will still work on a 32-bit
system and generate a working tools build ?  I don't care what
hypervisor (if any) it builds, but it has to succeed because that's
how I build the tools for use in 32-bit dom0s.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 10 17:16:02 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Sep 2012 17:16: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 1TB7aK-0006lH-RK; Mon, 10 Sep 2012 17:15:44 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <john.stultz@linaro.org>) id 1TB7aJ-0006l8-GS
	for xen-devel@lists.xensource.com; Mon, 10 Sep 2012 17:15:43 +0000
Received: from [85.158.143.99:22501] by server-1.bemta-4.messagelabs.com id
	FA/99-12504-E302E405; Mon, 10 Sep 2012 17:15:42 +0000
X-Env-Sender: john.stultz@linaro.org
X-Msg-Ref: server-3.tower-216.messagelabs.com!1347297340!28988007!1
X-Originating-IP: [32.97.182.145]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMzIuOTcuMTgyLjE0NSA9PiA1MjQyNjI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19335 invoked from network); 10 Sep 2012 17:15:41 -0000
Received: from e5.ny.us.ibm.com (HELO e5.ny.us.ibm.com) (32.97.182.145)
	by server-3.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 10 Sep 2012 17:15:41 -0000
Received: from /spool/local
	by e5.ny.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only!
	Violators will be prosecuted
	for <xen-devel@lists.xensource.com> from <john.stultz@linaro.org>;
	Mon, 10 Sep 2012 13:15:39 -0400
Received: from d01dlp03.pok.ibm.com (9.56.250.168)
	by e5.ny.us.ibm.com (192.168.1.105) with IBM ESMTP SMTP Gateway:
	Authorized Use Only! Violators will be prosecuted; 
	Mon, 10 Sep 2012 13:15:34 -0400
Received: from d01relay03.pok.ibm.com (d01relay03.pok.ibm.com [9.56.227.235])
	by d01dlp03.pok.ibm.com (Postfix) with ESMTP id A1A40C90067
	for <xen-devel@lists.xensource.com>;
	Mon, 10 Sep 2012 13:15:32 -0400 (EDT)
Received: from d03av05.boulder.ibm.com (d03av05.boulder.ibm.com [9.17.195.85])
	by d01relay03.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id
	q8AHFWxW139294
	for <xen-devel@lists.xensource.com>; Mon, 10 Sep 2012 13:15:32 -0400
Received: from d03av05.boulder.ibm.com (loopback [127.0.0.1])
	by d03av05.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP
	id q8AHEH57026631
	for <xen-devel@lists.xensource.com>; Mon, 10 Sep 2012 11:14:19 -0600
Received: from [9.65.242.108] (sig-9-65-242-108.mts.ibm.com [9.65.242.108])
	by d03av05.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id
	q8AHEDLA026479; Mon, 10 Sep 2012 11:14:14 -0600
Message-ID: <504E1FE5.6090502@linaro.org>
Date: Mon, 10 Sep 2012 10:14:13 -0700
From: John Stultz <john.stultz@linaro.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120827 Thunderbird/15.0
MIME-Version: 1.0
To: Daniel Lezcano <daniel.lezcano@linaro.org>
References: <1343164349-28550-1-git-send-email-daniel.lezcano@linaro.org>
	<201209062204.11288.rjw@sisk.pl> <50490920.9070204@linaro.org>
	<201209062318.42874.rjw@sisk.pl> <504A02BD.4000805@linaro.org>
	<504A2D73.3010702@linaro.org> <504A68A0.7010907@linaro.org>
In-Reply-To: <504A68A0.7010907@linaro.org>
X-Content-Scanned: Fidelis XPS MAILER
x-cbid: 12091017-5930-0000-0000-00000BDFB471
Cc: prarit@redhat.com, xen-devel@lists.xensource.com,
	linaro-dev@lists.linaro.org, Peter Zijlstra <a.p.zijlstra@chello.nl>,
	linux-pm@vger.kernel.org, Frederic Weisbecker <fweisbec@gmail.com>,
	richardcochran@gmail.com, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	"Rafael J. Wysocki" <rjw@sisk.pl>, linux-acpi@vger.kernel.org,
	Thomas Gleixner <tglx@linutronix.de>, mingo@kernel.org, lenb@kernel.org
Subject: Re: [Xen-devel] CONFIG_NO_HZ + CONFIG_CPU_IDLE freeze the system
 (Was Re: [PATCH] acpi : remove power from acpi_processor_cx structure)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 09/07/2012 02:35 PM, Daniel Lezcano wrote:
> On 09/07/2012 07:22 PM, John Stultz wrote:
>> On 09/07/2012 07:20 AM, Daniel Lezcano wrote:
>>> On 09/06/2012 11:18 PM, Rafael J. Wysocki wrote:
>>>> On Thursday, September 06, 2012, Daniel Lezcano wrote:
>>>>> On 09/06/2012 10:04 PM, Rafael J. Wysocki wrote:
>>>>>> On Thursday, September 06, 2012, Daniel Lezcano wrote:
>>>>>>> On 09/06/2012 09:54 AM, Daniel Lezcano wrote:
>>>>>>> I fall into this issue because NETCONSOLE is set, disabling it
>>>>>>> allowed
>>>>>>> me to go further.
>>>>>>>
>>>>>>> Unfortunately I am facing to some random freeze on the system which
>>>>>>> seems to be related to CONFIG_NO_HZ=y and CONFIG_CPU_IDLE=y.
>>>>>>>
>>>>>>> Disabling one of them, make the freezes to disappear.
>>>>>>>
>>>>>>> Is it a known issue ?
>>>>>> Well, there are systems having problems with this configuration,
>>>>>> but they
>>>>>> should be exceptional.  What system is that?
>>>>> It is a laptop T61p with a Core 2 Duo T9500. Nothing exceptional I
>>>>> believe. Maybe someone got the same issue ?
>>>> Is it a regression for you?
>>> Yes, I think so. The issue appears between v3.5 and v3.6-rc1.
>>>
>>> It is not easy to reproduce but after taking some time to dig, it seems
>>> to appear with this commit:
>>>
>>> 1e75fa8be9fb61e1af46b5b3b176347a4c958ca1 is the first bad commit
>>> commit 1e75fa8be9fb61e1af46b5b3b176347a4c958ca1
>>> Author: John Stultz <john.stultz@linaro.org>
>>> Date:   Fri Jul 13 01:21:53 2012 -0400
>>>
>>>       time: Condense timekeeper.xtime into xtime_sec
>>>
>>>       The timekeeper struct has a xtime_nsec, which keeps the
>>>       sub-nanosecond remainder.  This ends up being somewhat
>>>       duplicative of the timekeeper.xtime.tv_nsec value, and we
>>>       have to do extra work to keep them apart, copying the full
>>>       nsec portion out and back in over and over.
>>>
>>>       This patch simplifies some of the logic by taking the timekeeper
>>>       xtime value and splitting it into timekeeper.xtime_sec and
>>>       reuses the timekeeper.xtime_nsec for the sub-second portion
>>>       (stored in higher res shifted nanoseconds).
>>>
>>>       This simplifies some of the accumulation logic. And will
>>>       allow for more accurate timekeeping once the vsyscall code
>>>       is updated to use the shifted nanosecond remainder.
>>>
>>>       Signed-off-by: John Stultz <john.stultz@linaro.org>
>>>       Reviewed-by: Ingo Molnar <mingo@kernel.org>
>>>       Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
>>>       Cc: Richard Cochran <richardcochran@gmail.com>
>>>       Cc: Prarit Bhargava <prarit@redhat.com>
>>>       Link:
>>> http://lkml.kernel.org/r/1342156917-25092-5-git-send-email-john.stultz@linaro.org
>>>
>>>       Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
>>>
>>> :040000 040000 4d6541ac1f6075d7adee1eef494b31a0cbda0934
>>> dc5708bc738af695f092bf822809b13a1da104b6 M    kernel
>>>
>>> How to reproduce: with a laptop T61p, with a Core 2 Duo. I boot the
>>> kernel in busybox and wait some minutes before writing something in the
>>> console. At this moment, nothing appears to the console but the
>>> characters are echo'ed several seconds later (could be 1, 5, or 10 secs
>>> or more).
>>>
>>> That happens when CONFIG_CPU_IDLE and CONFIG_NO_HZ are set. Disabling
>>> one of them, the issue does not appear.
>> Thanks for bisecting this down and the heads up!
>>
>> Right off I can't see what might be causing this.  Bunch of questions:
>>
>> Is this a 32 or 64 bit kernel?
> It is a 32 bit kernel.

Thanks for your answers! Has this has been seen on 3.6-rc4+ kernels? 
There were a few casting fixes that landed in 3.6-rc4 that would affect 
32bit systems.

In the meantime, I'll try to reproduce on my T61. If you could send me 
your .config, I'd appreciate it.

thanks!
-john


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 10 17:16:02 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Sep 2012 17:16: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 1TB7aK-0006lH-RK; Mon, 10 Sep 2012 17:15:44 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <john.stultz@linaro.org>) id 1TB7aJ-0006l8-GS
	for xen-devel@lists.xensource.com; Mon, 10 Sep 2012 17:15:43 +0000
Received: from [85.158.143.99:22501] by server-1.bemta-4.messagelabs.com id
	FA/99-12504-E302E405; Mon, 10 Sep 2012 17:15:42 +0000
X-Env-Sender: john.stultz@linaro.org
X-Msg-Ref: server-3.tower-216.messagelabs.com!1347297340!28988007!1
X-Originating-IP: [32.97.182.145]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMzIuOTcuMTgyLjE0NSA9PiA1MjQyNjI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19335 invoked from network); 10 Sep 2012 17:15:41 -0000
Received: from e5.ny.us.ibm.com (HELO e5.ny.us.ibm.com) (32.97.182.145)
	by server-3.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 10 Sep 2012 17:15:41 -0000
Received: from /spool/local
	by e5.ny.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only!
	Violators will be prosecuted
	for <xen-devel@lists.xensource.com> from <john.stultz@linaro.org>;
	Mon, 10 Sep 2012 13:15:39 -0400
Received: from d01dlp03.pok.ibm.com (9.56.250.168)
	by e5.ny.us.ibm.com (192.168.1.105) with IBM ESMTP SMTP Gateway:
	Authorized Use Only! Violators will be prosecuted; 
	Mon, 10 Sep 2012 13:15:34 -0400
Received: from d01relay03.pok.ibm.com (d01relay03.pok.ibm.com [9.56.227.235])
	by d01dlp03.pok.ibm.com (Postfix) with ESMTP id A1A40C90067
	for <xen-devel@lists.xensource.com>;
	Mon, 10 Sep 2012 13:15:32 -0400 (EDT)
Received: from d03av05.boulder.ibm.com (d03av05.boulder.ibm.com [9.17.195.85])
	by d01relay03.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id
	q8AHFWxW139294
	for <xen-devel@lists.xensource.com>; Mon, 10 Sep 2012 13:15:32 -0400
Received: from d03av05.boulder.ibm.com (loopback [127.0.0.1])
	by d03av05.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP
	id q8AHEH57026631
	for <xen-devel@lists.xensource.com>; Mon, 10 Sep 2012 11:14:19 -0600
Received: from [9.65.242.108] (sig-9-65-242-108.mts.ibm.com [9.65.242.108])
	by d03av05.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id
	q8AHEDLA026479; Mon, 10 Sep 2012 11:14:14 -0600
Message-ID: <504E1FE5.6090502@linaro.org>
Date: Mon, 10 Sep 2012 10:14:13 -0700
From: John Stultz <john.stultz@linaro.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120827 Thunderbird/15.0
MIME-Version: 1.0
To: Daniel Lezcano <daniel.lezcano@linaro.org>
References: <1343164349-28550-1-git-send-email-daniel.lezcano@linaro.org>
	<201209062204.11288.rjw@sisk.pl> <50490920.9070204@linaro.org>
	<201209062318.42874.rjw@sisk.pl> <504A02BD.4000805@linaro.org>
	<504A2D73.3010702@linaro.org> <504A68A0.7010907@linaro.org>
In-Reply-To: <504A68A0.7010907@linaro.org>
X-Content-Scanned: Fidelis XPS MAILER
x-cbid: 12091017-5930-0000-0000-00000BDFB471
Cc: prarit@redhat.com, xen-devel@lists.xensource.com,
	linaro-dev@lists.linaro.org, Peter Zijlstra <a.p.zijlstra@chello.nl>,
	linux-pm@vger.kernel.org, Frederic Weisbecker <fweisbec@gmail.com>,
	richardcochran@gmail.com, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	"Rafael J. Wysocki" <rjw@sisk.pl>, linux-acpi@vger.kernel.org,
	Thomas Gleixner <tglx@linutronix.de>, mingo@kernel.org, lenb@kernel.org
Subject: Re: [Xen-devel] CONFIG_NO_HZ + CONFIG_CPU_IDLE freeze the system
 (Was Re: [PATCH] acpi : remove power from acpi_processor_cx structure)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 09/07/2012 02:35 PM, Daniel Lezcano wrote:
> On 09/07/2012 07:22 PM, John Stultz wrote:
>> On 09/07/2012 07:20 AM, Daniel Lezcano wrote:
>>> On 09/06/2012 11:18 PM, Rafael J. Wysocki wrote:
>>>> On Thursday, September 06, 2012, Daniel Lezcano wrote:
>>>>> On 09/06/2012 10:04 PM, Rafael J. Wysocki wrote:
>>>>>> On Thursday, September 06, 2012, Daniel Lezcano wrote:
>>>>>>> On 09/06/2012 09:54 AM, Daniel Lezcano wrote:
>>>>>>> I fall into this issue because NETCONSOLE is set, disabling it
>>>>>>> allowed
>>>>>>> me to go further.
>>>>>>>
>>>>>>> Unfortunately I am facing to some random freeze on the system which
>>>>>>> seems to be related to CONFIG_NO_HZ=y and CONFIG_CPU_IDLE=y.
>>>>>>>
>>>>>>> Disabling one of them, make the freezes to disappear.
>>>>>>>
>>>>>>> Is it a known issue ?
>>>>>> Well, there are systems having problems with this configuration,
>>>>>> but they
>>>>>> should be exceptional.  What system is that?
>>>>> It is a laptop T61p with a Core 2 Duo T9500. Nothing exceptional I
>>>>> believe. Maybe someone got the same issue ?
>>>> Is it a regression for you?
>>> Yes, I think so. The issue appears between v3.5 and v3.6-rc1.
>>>
>>> It is not easy to reproduce but after taking some time to dig, it seems
>>> to appear with this commit:
>>>
>>> 1e75fa8be9fb61e1af46b5b3b176347a4c958ca1 is the first bad commit
>>> commit 1e75fa8be9fb61e1af46b5b3b176347a4c958ca1
>>> Author: John Stultz <john.stultz@linaro.org>
>>> Date:   Fri Jul 13 01:21:53 2012 -0400
>>>
>>>       time: Condense timekeeper.xtime into xtime_sec
>>>
>>>       The timekeeper struct has a xtime_nsec, which keeps the
>>>       sub-nanosecond remainder.  This ends up being somewhat
>>>       duplicative of the timekeeper.xtime.tv_nsec value, and we
>>>       have to do extra work to keep them apart, copying the full
>>>       nsec portion out and back in over and over.
>>>
>>>       This patch simplifies some of the logic by taking the timekeeper
>>>       xtime value and splitting it into timekeeper.xtime_sec and
>>>       reuses the timekeeper.xtime_nsec for the sub-second portion
>>>       (stored in higher res shifted nanoseconds).
>>>
>>>       This simplifies some of the accumulation logic. And will
>>>       allow for more accurate timekeeping once the vsyscall code
>>>       is updated to use the shifted nanosecond remainder.
>>>
>>>       Signed-off-by: John Stultz <john.stultz@linaro.org>
>>>       Reviewed-by: Ingo Molnar <mingo@kernel.org>
>>>       Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
>>>       Cc: Richard Cochran <richardcochran@gmail.com>
>>>       Cc: Prarit Bhargava <prarit@redhat.com>
>>>       Link:
>>> http://lkml.kernel.org/r/1342156917-25092-5-git-send-email-john.stultz@linaro.org
>>>
>>>       Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
>>>
>>> :040000 040000 4d6541ac1f6075d7adee1eef494b31a0cbda0934
>>> dc5708bc738af695f092bf822809b13a1da104b6 M    kernel
>>>
>>> How to reproduce: with a laptop T61p, with a Core 2 Duo. I boot the
>>> kernel in busybox and wait some minutes before writing something in the
>>> console. At this moment, nothing appears to the console but the
>>> characters are echo'ed several seconds later (could be 1, 5, or 10 secs
>>> or more).
>>>
>>> That happens when CONFIG_CPU_IDLE and CONFIG_NO_HZ are set. Disabling
>>> one of them, the issue does not appear.
>> Thanks for bisecting this down and the heads up!
>>
>> Right off I can't see what might be causing this.  Bunch of questions:
>>
>> Is this a 32 or 64 bit kernel?
> It is a 32 bit kernel.

Thanks for your answers! Has this has been seen on 3.6-rc4+ kernels? 
There were a few casting fixes that landed in 3.6-rc4 that would affect 
32bit systems.

In the meantime, I'll try to reproduce on my T61. If you could send me 
your .config, I'd appreciate it.

thanks!
-john


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 10 17:25:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Sep 2012 17:25:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TB7jE-0006wr-UE; Mon, 10 Sep 2012 17:24:56 +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 1TB7jC-0006wm-WA
	for xen-devel@lists.xen.org; Mon, 10 Sep 2012 17:24:55 +0000
Received: from [85.158.143.35:48704] by server-3.bemta-4.messagelabs.com id
	13/60-08232-6622E405; Mon, 10 Sep 2012 17:24:54 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1347297893!14217750!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-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23002 invoked from network); 10 Sep 2012 17:24:53 -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;
	10 Sep 2012 17:24:53 -0000
Received: by eeke53 with SMTP id e53so1413451eek.32
	for <xen-devel@lists.xen.org>; Mon, 10 Sep 2012 10:24:53 -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=Rgptnql7kdE8KW1UGUv7epeCilJf3JlBa68XnhW9xu0=;
	b=iuHS0MESDSxl2qoQ5gKlXbbQCF0ZWmQdaFAenULvpc6+2wiaL7o6Wm3fAIf7AKCQHw
	cFSH9krWvCh+dJCwozaW5Bu2XQcataYwErnWujsG4qxsLWz9E80yNORbFSF/iyfQpSJE
	yls77i6zMU4SveQ7guayyyBI/06UjqGT0wsVmk3R/VrTotHGi03ddu/cVEEreyAr7G+a
	pvGaZjA33aQLW3s7q1UM943909AgAorBuYxej3t8NcYnabTVASk27k+utMAilYK9ZckK
	FnNdUaF29TgXlz+d4WvVI0P5xVTfThQezeUWAsqpjloH+/v6K/2iaSnAu1VFra6y3n+H
	PlmA==
Received: by 10.14.182.134 with SMTP id o6mr20713266eem.26.1347297893504;
	Mon, 10 Sep 2012 10:24:53 -0700 (PDT)
Received: from [192.168.1.69] (host86-184-74-117.range86-184.btcentralplus.com.
	[86.184.74.117])
	by mx.google.com with ESMTPS id u47sm39891049eeo.9.2012.09.10.10.24.50
	(version=SSLv3 cipher=OTHER); Mon, 10 Sep 2012 10:24:52 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Mon, 10 Sep 2012 18:24:44 +0100
From: Keir Fraser <keir.xen@gmail.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Message-ID: <CC73E0EC.3E42A%keir.xen@gmail.com>
Thread-Topic: [ANNOUNCE] Xen x86 32-bit hypervisor end of life after 4.2
Thread-Index: Ac2PeSsR2ABhzc/ZYkCBcNaaEqEeVA==
In-Reply-To: <20558.7857.884864.696876@mariner.uk.xensource.com>
Mime-version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [ANNOUNCE] Xen x86 32-bit hypervisor end of life
	after 4.2
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 10/09/2012 18:09, "Ian Jackson" <Ian.Jackson@eu.citrix.com> wrote:

> Keir Fraser writes ("Re: [ANNOUNCE] Xen x86 32-bit hypervisor end of life
> after 4.2"):
>> On 10/09/2012 15:16, "Ian Jackson" <Ian.Jackson@eu.citrix.com> wrote:
>>> I will do this but I have a number of other things which need to go
>>> through the autotester's tests of itself, first.  I'll let you know
>>> when it's done.
>> 
>> A self-aware autotester. :)
> 
> As you say.
> 
>> Well that's fine. It doesn't have to be done in a huge hurry.
> 
> I've been looking into this and have a draft of a suitable change.
> But: can you confirm that typing "make" will still work on a 32-bit
> system and generate a working tools build ?  I don't care what
> hypervisor (if any) it builds, but it has to succeed because that's
> how I build the tools for use in 32-bit dom0s.

You want 'make' at the root Makefile to build successfully? If so we can
stub out 32-bit hypervisor only either in that Makefile, or xen/Makefile.

> Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 10 17:25:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Sep 2012 17:25:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TB7jE-0006wr-UE; Mon, 10 Sep 2012 17:24:56 +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 1TB7jC-0006wm-WA
	for xen-devel@lists.xen.org; Mon, 10 Sep 2012 17:24:55 +0000
Received: from [85.158.143.35:48704] by server-3.bemta-4.messagelabs.com id
	13/60-08232-6622E405; Mon, 10 Sep 2012 17:24:54 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1347297893!14217750!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-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23002 invoked from network); 10 Sep 2012 17:24:53 -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;
	10 Sep 2012 17:24:53 -0000
Received: by eeke53 with SMTP id e53so1413451eek.32
	for <xen-devel@lists.xen.org>; Mon, 10 Sep 2012 10:24:53 -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=Rgptnql7kdE8KW1UGUv7epeCilJf3JlBa68XnhW9xu0=;
	b=iuHS0MESDSxl2qoQ5gKlXbbQCF0ZWmQdaFAenULvpc6+2wiaL7o6Wm3fAIf7AKCQHw
	cFSH9krWvCh+dJCwozaW5Bu2XQcataYwErnWujsG4qxsLWz9E80yNORbFSF/iyfQpSJE
	yls77i6zMU4SveQ7guayyyBI/06UjqGT0wsVmk3R/VrTotHGi03ddu/cVEEreyAr7G+a
	pvGaZjA33aQLW3s7q1UM943909AgAorBuYxej3t8NcYnabTVASk27k+utMAilYK9ZckK
	FnNdUaF29TgXlz+d4WvVI0P5xVTfThQezeUWAsqpjloH+/v6K/2iaSnAu1VFra6y3n+H
	PlmA==
Received: by 10.14.182.134 with SMTP id o6mr20713266eem.26.1347297893504;
	Mon, 10 Sep 2012 10:24:53 -0700 (PDT)
Received: from [192.168.1.69] (host86-184-74-117.range86-184.btcentralplus.com.
	[86.184.74.117])
	by mx.google.com with ESMTPS id u47sm39891049eeo.9.2012.09.10.10.24.50
	(version=SSLv3 cipher=OTHER); Mon, 10 Sep 2012 10:24:52 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Mon, 10 Sep 2012 18:24:44 +0100
From: Keir Fraser <keir.xen@gmail.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Message-ID: <CC73E0EC.3E42A%keir.xen@gmail.com>
Thread-Topic: [ANNOUNCE] Xen x86 32-bit hypervisor end of life after 4.2
Thread-Index: Ac2PeSsR2ABhzc/ZYkCBcNaaEqEeVA==
In-Reply-To: <20558.7857.884864.696876@mariner.uk.xensource.com>
Mime-version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [ANNOUNCE] Xen x86 32-bit hypervisor end of life
	after 4.2
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 10/09/2012 18:09, "Ian Jackson" <Ian.Jackson@eu.citrix.com> wrote:

> Keir Fraser writes ("Re: [ANNOUNCE] Xen x86 32-bit hypervisor end of life
> after 4.2"):
>> On 10/09/2012 15:16, "Ian Jackson" <Ian.Jackson@eu.citrix.com> wrote:
>>> I will do this but I have a number of other things which need to go
>>> through the autotester's tests of itself, first.  I'll let you know
>>> when it's done.
>> 
>> A self-aware autotester. :)
> 
> As you say.
> 
>> Well that's fine. It doesn't have to be done in a huge hurry.
> 
> I've been looking into this and have a draft of a suitable change.
> But: can you confirm that typing "make" will still work on a 32-bit
> system and generate a working tools build ?  I don't care what
> hypervisor (if any) it builds, but it has to succeed because that's
> how I build the tools for use in 32-bit dom0s.

You want 'make' at the root Makefile to build successfully? If so we can
stub out 32-bit hypervisor only either in that Makefile, or xen/Makefile.

> Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 10 17:27:39 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Sep 2012 17:27:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TB7ld-000727-FO; Mon, 10 Sep 2012 17:27: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 1TB7lc-000721-Vg
	for xen-devel@lists.xensource.com; Mon, 10 Sep 2012 17:27:25 +0000
Received: from [85.158.143.35:39527] by server-2.bemta-4.messagelabs.com id
	E6/63-21239-CF22E405; Mon, 10 Sep 2012 17:27:24 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1347298025!17632787!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNzc5Njk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24766 invoked from network); 10 Sep 2012 17:27:06 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-14.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Sep 2012 17:27:06 -0000
X-IronPort-AV: E=Sophos;i="4.80,398,1344211200"; d="scan'208";a="207617902"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Sep 2012 17:27:04 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1;
	Mon, 10 Sep 2012 13:27:03 -0400
Received: from qabil.uk.xensource.com ([10.80.2.76])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<david.vrabel@citrix.com>)	id 1TB7lH-0004rA-I2;
	Mon, 10 Sep 2012 18:27:03 +0100
From: David Vrabel <david.vrabel@citrix.com>
To: xen-devel@lists.xensource.com
Date: Mon, 10 Sep 2012 18:26:55 +0100
Message-ID: <1347298015-6761-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>
Subject: [Xen-devel] [PATCH] x86: make the dom0_max_vcpus option more
	flexible
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: David Vrabel <david.vrabel@citrix.com>

The dom0_max_vcpus command line option only allows the exact number of
VCPUs for dom0 to be set.  It is not possible to say "up to N VCPUs
but no more than the number physically present."

Allow a range for the option to set a minimum number of VCPUs, and a
maximum which does not exceed the number of PCPUs.

For example, with "dom0_max_vcpus=4-8":

    PCPUs  Dom0 VCPUs
     2      4
     4      4
     6      6
     8      8
    10      8

Existing command lines with "dom0_max_vcpus=N" still work as before
(and are equivalent to dom0_max_vcpus=N-N).

Signed-off-by: David Vrabel <david.vrabel@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
---
Changes since v2:
  - none, repost for Xen 4.3
---
 docs/misc/xen-command-line.markdown |   29 +++++++++++++++++++++--
 xen/arch/x86/domain_build.c         |   43 +++++++++++++++++++++++++---------
 2 files changed, 57 insertions(+), 15 deletions(-)

diff --git a/docs/misc/xen-command-line.markdown b/docs/misc/xen-command-line.markdown
index 6599931..97a2bb2 100644
--- a/docs/misc/xen-command-line.markdown
+++ b/docs/misc/xen-command-line.markdown
@@ -383,10 +383,33 @@ Specify the bit width of the DMA heap.
 Specify a list of IO ports to be excluded from dom0 access.
 
 ### dom0\_max\_vcpus
-> `= <integer>`
 
-Specify the maximum number of vcpus to give to dom0.  This defaults
-to the number of pcpus on the host.
+Either:
+
+> `= <integer>`.
+
+The number of VCPUs to give to dom0.  This number of VCPUs can be more
+than the number of PCPUs on the host.  The default is the number of
+PCPUs.
+
+Or:
+
+> `= <min>-<max>` where `<min>` and `<max>` are integers.
+
+Gives dom0 a number of VCPUs equal to the number of PCPUs, but always
+at least `<min>` and no more than `<max>`.  Using `<min>` may give
+more VCPUs than PCPUs.  `<min>` or `<max>` may be omitted and the
+defaults of 1 and unlimited respectively are used instead.
+
+For example, with `dom0_max_vcpus=4-8`:
+
+     Number of
+  PCPUs | Dom0 VCPUs
+   2    |  4
+   4    |  4
+   6    |  6
+   8    |  8
+  10    |  8
 
 ### dom0\_mem
 > `= List of ( min:<size> | max:<size> | <size> )`
diff --git a/xen/arch/x86/domain_build.c b/xen/arch/x86/domain_build.c
index b3c5d4c..686b626 100644
--- a/xen/arch/x86/domain_build.c
+++ b/xen/arch/x86/domain_build.c
@@ -82,20 +82,39 @@ static void __init parse_dom0_mem(const char *s)
 }
 custom_param("dom0_mem", parse_dom0_mem);
 
-static unsigned int __initdata opt_dom0_max_vcpus;
-integer_param("dom0_max_vcpus", opt_dom0_max_vcpus);
+static unsigned int __initdata opt_dom0_max_vcpus_min = 1;
+static unsigned int __initdata opt_dom0_max_vcpus_max = UINT_MAX;
+
+static void __init parse_dom0_max_vcpus(const char *s)
+{
+    if (*s == '-')              /* -M */
+        opt_dom0_max_vcpus_max = simple_strtoul(s + 1, &s, 0);
+    else {                      /* N, N-, or N-M */
+        opt_dom0_max_vcpus_min = simple_strtoul(s, &s, 0);
+        if (*s++ == '\0')       /* N */
+            opt_dom0_max_vcpus_max = opt_dom0_max_vcpus_min;
+        else if (*s != '\0')    /* N-M */
+            opt_dom0_max_vcpus_max = simple_strtoul(s, &s, 0);
+    }
+}
+custom_param("dom0_max_vcpus", parse_dom0_max_vcpus);
 
 struct vcpu *__init alloc_dom0_vcpu0(void)
 {
-    if ( opt_dom0_max_vcpus == 0 )
-        opt_dom0_max_vcpus = num_cpupool_cpus(cpupool0);
-    if ( opt_dom0_max_vcpus > MAX_VIRT_CPUS )
-        opt_dom0_max_vcpus = MAX_VIRT_CPUS;
+    unsigned max_vcpus;
+
+    max_vcpus = num_cpupool_cpus(cpupool0);
+    if ( opt_dom0_max_vcpus_min > max_vcpus )
+        max_vcpus = opt_dom0_max_vcpus_min;
+    if ( opt_dom0_max_vcpus_max < max_vcpus )
+        max_vcpus = opt_dom0_max_vcpus_max;
+    if ( max_vcpus > MAX_VIRT_CPUS )
+        max_vcpus = MAX_VIRT_CPUS;
 
-    dom0->vcpu = xzalloc_array(struct vcpu *, opt_dom0_max_vcpus);
+    dom0->vcpu = xzalloc_array(struct vcpu *, max_vcpus);
     if ( !dom0->vcpu )
         return NULL;
-    dom0->max_vcpus = opt_dom0_max_vcpus;
+    dom0->max_vcpus = max_vcpus;
 
     return alloc_vcpu(dom0, 0, 0);
 }
@@ -185,11 +204,11 @@ static unsigned long __init compute_dom0_nr_pages(
     unsigned long max_pages = dom0_max_nrpages;
 
     /* Reserve memory for further dom0 vcpu-struct allocations... */
-    avail -= (opt_dom0_max_vcpus - 1UL)
+    avail -= (d->max_vcpus - 1UL)
              << get_order_from_bytes(sizeof(struct vcpu));
     /* ...and compat_l4's, if needed. */
     if ( is_pv_32on64_domain(d) )
-        avail -= opt_dom0_max_vcpus - 1;
+        avail -= d->max_vcpus - 1;
 
     /* Reserve memory for iommu_dom0_init() (rough estimate). */
     if ( iommu_enabled )
@@ -883,10 +902,10 @@ int __init construct_dom0(
     for ( i = 0; i < XEN_LEGACY_MAX_VCPUS; i++ )
         shared_info(d, vcpu_info[i].evtchn_upcall_mask) = 1;
 
-    printk("Dom0 has maximum %u VCPUs\n", opt_dom0_max_vcpus);
+    printk("Dom0 has maximum %u VCPUs\n", d->max_vcpus);
 
     cpu = cpumask_first(cpupool0->cpu_valid);
-    for ( i = 1; i < opt_dom0_max_vcpus; i++ )
+    for ( i = 1; i < d->max_vcpus; i++ )
     {
         cpu = cpumask_cycle(cpu, cpupool0->cpu_valid);
         (void)alloc_vcpu(d, i, cpu);
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 10 17:27:39 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Sep 2012 17:27:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TB7ld-000727-FO; Mon, 10 Sep 2012 17:27: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 1TB7lc-000721-Vg
	for xen-devel@lists.xensource.com; Mon, 10 Sep 2012 17:27:25 +0000
Received: from [85.158.143.35:39527] by server-2.bemta-4.messagelabs.com id
	E6/63-21239-CF22E405; Mon, 10 Sep 2012 17:27:24 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1347298025!17632787!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNzc5Njk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24766 invoked from network); 10 Sep 2012 17:27:06 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-14.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Sep 2012 17:27:06 -0000
X-IronPort-AV: E=Sophos;i="4.80,398,1344211200"; d="scan'208";a="207617902"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Sep 2012 17:27:04 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1;
	Mon, 10 Sep 2012 13:27:03 -0400
Received: from qabil.uk.xensource.com ([10.80.2.76])	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<david.vrabel@citrix.com>)	id 1TB7lH-0004rA-I2;
	Mon, 10 Sep 2012 18:27:03 +0100
From: David Vrabel <david.vrabel@citrix.com>
To: xen-devel@lists.xensource.com
Date: Mon, 10 Sep 2012 18:26:55 +0100
Message-ID: <1347298015-6761-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>
Subject: [Xen-devel] [PATCH] x86: make the dom0_max_vcpus option more
	flexible
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

From: David Vrabel <david.vrabel@citrix.com>

The dom0_max_vcpus command line option only allows the exact number of
VCPUs for dom0 to be set.  It is not possible to say "up to N VCPUs
but no more than the number physically present."

Allow a range for the option to set a minimum number of VCPUs, and a
maximum which does not exceed the number of PCPUs.

For example, with "dom0_max_vcpus=4-8":

    PCPUs  Dom0 VCPUs
     2      4
     4      4
     6      6
     8      8
    10      8

Existing command lines with "dom0_max_vcpus=N" still work as before
(and are equivalent to dom0_max_vcpus=N-N).

Signed-off-by: David Vrabel <david.vrabel@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
---
Changes since v2:
  - none, repost for Xen 4.3
---
 docs/misc/xen-command-line.markdown |   29 +++++++++++++++++++++--
 xen/arch/x86/domain_build.c         |   43 +++++++++++++++++++++++++---------
 2 files changed, 57 insertions(+), 15 deletions(-)

diff --git a/docs/misc/xen-command-line.markdown b/docs/misc/xen-command-line.markdown
index 6599931..97a2bb2 100644
--- a/docs/misc/xen-command-line.markdown
+++ b/docs/misc/xen-command-line.markdown
@@ -383,10 +383,33 @@ Specify the bit width of the DMA heap.
 Specify a list of IO ports to be excluded from dom0 access.
 
 ### dom0\_max\_vcpus
-> `= <integer>`
 
-Specify the maximum number of vcpus to give to dom0.  This defaults
-to the number of pcpus on the host.
+Either:
+
+> `= <integer>`.
+
+The number of VCPUs to give to dom0.  This number of VCPUs can be more
+than the number of PCPUs on the host.  The default is the number of
+PCPUs.
+
+Or:
+
+> `= <min>-<max>` where `<min>` and `<max>` are integers.
+
+Gives dom0 a number of VCPUs equal to the number of PCPUs, but always
+at least `<min>` and no more than `<max>`.  Using `<min>` may give
+more VCPUs than PCPUs.  `<min>` or `<max>` may be omitted and the
+defaults of 1 and unlimited respectively are used instead.
+
+For example, with `dom0_max_vcpus=4-8`:
+
+     Number of
+  PCPUs | Dom0 VCPUs
+   2    |  4
+   4    |  4
+   6    |  6
+   8    |  8
+  10    |  8
 
 ### dom0\_mem
 > `= List of ( min:<size> | max:<size> | <size> )`
diff --git a/xen/arch/x86/domain_build.c b/xen/arch/x86/domain_build.c
index b3c5d4c..686b626 100644
--- a/xen/arch/x86/domain_build.c
+++ b/xen/arch/x86/domain_build.c
@@ -82,20 +82,39 @@ static void __init parse_dom0_mem(const char *s)
 }
 custom_param("dom0_mem", parse_dom0_mem);
 
-static unsigned int __initdata opt_dom0_max_vcpus;
-integer_param("dom0_max_vcpus", opt_dom0_max_vcpus);
+static unsigned int __initdata opt_dom0_max_vcpus_min = 1;
+static unsigned int __initdata opt_dom0_max_vcpus_max = UINT_MAX;
+
+static void __init parse_dom0_max_vcpus(const char *s)
+{
+    if (*s == '-')              /* -M */
+        opt_dom0_max_vcpus_max = simple_strtoul(s + 1, &s, 0);
+    else {                      /* N, N-, or N-M */
+        opt_dom0_max_vcpus_min = simple_strtoul(s, &s, 0);
+        if (*s++ == '\0')       /* N */
+            opt_dom0_max_vcpus_max = opt_dom0_max_vcpus_min;
+        else if (*s != '\0')    /* N-M */
+            opt_dom0_max_vcpus_max = simple_strtoul(s, &s, 0);
+    }
+}
+custom_param("dom0_max_vcpus", parse_dom0_max_vcpus);
 
 struct vcpu *__init alloc_dom0_vcpu0(void)
 {
-    if ( opt_dom0_max_vcpus == 0 )
-        opt_dom0_max_vcpus = num_cpupool_cpus(cpupool0);
-    if ( opt_dom0_max_vcpus > MAX_VIRT_CPUS )
-        opt_dom0_max_vcpus = MAX_VIRT_CPUS;
+    unsigned max_vcpus;
+
+    max_vcpus = num_cpupool_cpus(cpupool0);
+    if ( opt_dom0_max_vcpus_min > max_vcpus )
+        max_vcpus = opt_dom0_max_vcpus_min;
+    if ( opt_dom0_max_vcpus_max < max_vcpus )
+        max_vcpus = opt_dom0_max_vcpus_max;
+    if ( max_vcpus > MAX_VIRT_CPUS )
+        max_vcpus = MAX_VIRT_CPUS;
 
-    dom0->vcpu = xzalloc_array(struct vcpu *, opt_dom0_max_vcpus);
+    dom0->vcpu = xzalloc_array(struct vcpu *, max_vcpus);
     if ( !dom0->vcpu )
         return NULL;
-    dom0->max_vcpus = opt_dom0_max_vcpus;
+    dom0->max_vcpus = max_vcpus;
 
     return alloc_vcpu(dom0, 0, 0);
 }
@@ -185,11 +204,11 @@ static unsigned long __init compute_dom0_nr_pages(
     unsigned long max_pages = dom0_max_nrpages;
 
     /* Reserve memory for further dom0 vcpu-struct allocations... */
-    avail -= (opt_dom0_max_vcpus - 1UL)
+    avail -= (d->max_vcpus - 1UL)
              << get_order_from_bytes(sizeof(struct vcpu));
     /* ...and compat_l4's, if needed. */
     if ( is_pv_32on64_domain(d) )
-        avail -= opt_dom0_max_vcpus - 1;
+        avail -= d->max_vcpus - 1;
 
     /* Reserve memory for iommu_dom0_init() (rough estimate). */
     if ( iommu_enabled )
@@ -883,10 +902,10 @@ int __init construct_dom0(
     for ( i = 0; i < XEN_LEGACY_MAX_VCPUS; i++ )
         shared_info(d, vcpu_info[i].evtchn_upcall_mask) = 1;
 
-    printk("Dom0 has maximum %u VCPUs\n", opt_dom0_max_vcpus);
+    printk("Dom0 has maximum %u VCPUs\n", d->max_vcpus);
 
     cpu = cpumask_first(cpupool0->cpu_valid);
-    for ( i = 1; i < opt_dom0_max_vcpus; i++ )
+    for ( i = 1; i < d->max_vcpus; i++ )
     {
         cpu = cpumask_cycle(cpu, cpupool0->cpu_valid);
         (void)alloc_vcpu(d, i, cpu);
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 10 18:05:40 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Sep 2012 18:05:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TB8ML-0007SI-Qf; Mon, 10 Sep 2012 18:05:21 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1TB8MJ-0007SD-W5
	for xen-devel@lists.xensource.com; Mon, 10 Sep 2012 18:05:20 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1347300312!9150948!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTIyODk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27264 invoked from network); 10 Sep 2012 18:05:12 -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;
	10 Sep 2012 18:05:12 -0000
X-IronPort-AV: E=Sophos;i="4.80,398,1344211200"; d="scan'208";a="14452371"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Sep 2012 18:05: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.279.1; Mon, 10 Sep 2012 19:05:11 +0100
Date: Mon, 10 Sep 2012 19:04:31 +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.1209101842150.15568@kaball.uk.xensource.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: dongxiao.xu@intel.com, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	qemu-devel@nongnu.org,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH 0/2] QEMU/xen: simplify cpu_ioreq_pio and
	cpu_ioreq_move
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi all,
after reviewing the patch "fix multiply issue for int and uint types"
with Ian Jackson, we realized that cpu_ioreq_pio and cpu_ioreq_move are
in much need for a simplification as well as removal of a possible
integer overflow.

This patch series tries to accomplish both switching to two new helper
functions and using a more obvious arithmetic. Doing so it should also
fix the original problem that Dongxiao was experiencing. The C language
can be a nasty backstabber when signed and unsigned integers are
involved.

The current patch series if for qemu-xen-traditional but if the patches
are deemed correct I'll submit an equivalent set for QEMU upstream (with
the appropriate code style changes).



Stefano Stabellini (2):
      i should be uint32_t rather than int
      introduce read_physical_offset and write_physical_offset

 i386-dm/helper2.c |   66 +++++++++++++++++++++++++++++++++-------------------
 1 files changed, 42 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 Mon Sep 10 18:05:40 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Sep 2012 18:05:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TB8ML-0007SI-Qf; Mon, 10 Sep 2012 18:05:21 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1TB8MJ-0007SD-W5
	for xen-devel@lists.xensource.com; Mon, 10 Sep 2012 18:05:20 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1347300312!9150948!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTIyODk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27264 invoked from network); 10 Sep 2012 18:05:12 -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;
	10 Sep 2012 18:05:12 -0000
X-IronPort-AV: E=Sophos;i="4.80,398,1344211200"; d="scan'208";a="14452371"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Sep 2012 18:05: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.279.1; Mon, 10 Sep 2012 19:05:11 +0100
Date: Mon, 10 Sep 2012 19:04:31 +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.1209101842150.15568@kaball.uk.xensource.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: dongxiao.xu@intel.com, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	qemu-devel@nongnu.org,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH 0/2] QEMU/xen: simplify cpu_ioreq_pio and
	cpu_ioreq_move
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi all,
after reviewing the patch "fix multiply issue for int and uint types"
with Ian Jackson, we realized that cpu_ioreq_pio and cpu_ioreq_move are
in much need for a simplification as well as removal of a possible
integer overflow.

This patch series tries to accomplish both switching to two new helper
functions and using a more obvious arithmetic. Doing so it should also
fix the original problem that Dongxiao was experiencing. The C language
can be a nasty backstabber when signed and unsigned integers are
involved.

The current patch series if for qemu-xen-traditional but if the patches
are deemed correct I'll submit an equivalent set for QEMU upstream (with
the appropriate code style changes).



Stefano Stabellini (2):
      i should be uint32_t rather than int
      introduce read_physical_offset and write_physical_offset

 i386-dm/helper2.c |   66 +++++++++++++++++++++++++++++++++-------------------
 1 files changed, 42 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 Mon Sep 10 18:07:17 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Sep 2012 18:07: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 1TB8Nv-0007Xv-Er; Mon, 10 Sep 2012 18:06:59 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1TB8Nu-0007Xg-3O
	for xen-devel@lists.xensource.com; Mon, 10 Sep 2012 18:06:58 +0000
Received: from [85.158.139.83:28078] by server-5.bemta-5.messagelabs.com id
	62/C9-30514-14C2E405; Mon, 10 Sep 2012 18:06:57 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1347300414!29412184!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNzc5Njk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11852 invoked from network); 10 Sep 2012 18:06:55 -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;
	10 Sep 2012 18:06:55 -0000
X-IronPort-AV: E=Sophos;i="4.80,398,1344211200"; d="scan'208";a="207623410"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Sep 2012 18:06:54 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1;
	Mon, 10 Sep 2012 14:06:53 -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 1TB8Nk-0005UC-44;
	Mon, 10 Sep 2012 19:06:48 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Mon, 10 Sep 2012 19:06:23 +0100
Message-ID: <1347300383-9089-2-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <alpine.DEB.2.02.1209101842150.15568@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1209101842150.15568@kaball.uk.xensource.com>
MIME-Version: 1.0
Cc: dongxiao.xu@intel.com, Ian.Jackson@eu.citrix.com, qemu-devel@nongnu.org,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH 2/2] introduce read_physical_offset and
	write_physical_offset
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Remove read_physical and write_physical.
Introduce two new helper functions, read_physical_offset and
write_physical_offset, that take care of adding or subtracting offset
depending on sign. This way we avoid the automatic casting of sign to
uint32_t that is clearly not a very good idea and can easily cause
overflows. It also makes the code easier to understand.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 i386-dm/helper2.c |   60 +++++++++++++++++++++++++++++++++-------------------
 1 files changed, 38 insertions(+), 22 deletions(-)

diff --git a/i386-dm/helper2.c b/i386-dm/helper2.c
index 8f2a893..5eb1901 100644
--- a/i386-dm/helper2.c
+++ b/i386-dm/helper2.c
@@ -339,14 +339,30 @@ static void do_outp(CPUState *env, unsigned long addr,
     }
 }
 
-static inline void read_physical(uint64_t addr, unsigned long size, void *val)
+static inline void read_physical_offset(target_phys_addr_t addr,
+                                        unsigned long offset,
+                                        int sign,
+                                        unsigned long size,
+                                        void *val)
 {
-    return cpu_physical_memory_rw((target_phys_addr_t)addr, val, size, 0);
+    if (sign >= 0)
+        addr += offset;
+    else
+        addr -= offset;
+    return cpu_physical_memory_rw(addr, val, size, 0);
 }
 
-static inline void write_physical(uint64_t addr, unsigned long size, void *val)
+static inline void write_physical_offset(target_phys_addr_t addr,
+                                         unsigned long offset,
+                                         int sign,
+                                         unsigned long size,
+                                         void *val)
 {
-    return cpu_physical_memory_rw((target_phys_addr_t)addr, val, size, 1);
+    if (sign >= 0)
+        addr += offset;
+    else
+        addr -= offset;
+    return cpu_physical_memory_rw(addr, val, size, 1);
 }
 
 static void cpu_ioreq_pio(CPUState *env, ioreq_t *req)
@@ -364,9 +380,9 @@ static void cpu_ioreq_pio(CPUState *env, ioreq_t *req)
 
             for (i = 0; i < req->count; i++) {
                 tmp = do_inp(env, req->addr, req->size);
-                write_physical((target_phys_addr_t) req->data
-                  + (sign * i * req->size),
-                  req->size, &tmp);
+                write_physical_offset((target_phys_addr_t) req->data,
+                                      i * req->size, sign,
+                                      req->size, &tmp);
             }
         }
     } else if (req->dir == IOREQ_WRITE) {
@@ -376,9 +392,9 @@ static void cpu_ioreq_pio(CPUState *env, ioreq_t *req)
             for (i = 0; i < req->count; i++) {
                 unsigned long tmp = 0;
 
-                read_physical((target_phys_addr_t) req->data
-                  + (sign * i * req->size),
-                  req->size, &tmp);
+                read_physical_offset((target_phys_addr_t) req->data,
+                              i * req->size, sign,
+                              req->size, &tmp);
                 do_outp(env, req->addr, req->size, tmp);
             }
         }
@@ -395,14 +411,14 @@ static void cpu_ioreq_move(CPUState *env, ioreq_t *req)
     if (!req->data_is_ptr) {
         if (req->dir == IOREQ_READ) {
             for (i = 0; i < req->count; i++) {
-                read_physical(req->addr
-                  + (sign * i * req->size),
+                read_physical_offset(req->addr,
+                  i * req->size, sign,
                   req->size, &req->data);
             }
         } else if (req->dir == IOREQ_WRITE) {
             for (i = 0; i < req->count; i++) {
-                write_physical(req->addr
-                  + (sign * i * req->size),
+                write_physical_offset(req->addr,
+                  i * req->size, sign,
                   req->size, &req->data);
             }
         }
@@ -411,20 +427,20 @@ static void cpu_ioreq_move(CPUState *env, ioreq_t *req)
 
         if (req->dir == IOREQ_READ) {
             for (i = 0; i < req->count; i++) {
-                read_physical(req->addr
-                  + (sign * i * req->size),
+                read_physical_offset(req->addr,
+                  i * req->size, sign,
                   req->size, &tmp);
-                write_physical((target_phys_addr_t )req->data
-                  + (sign * i * req->size),
+                write_physical_offset((target_phys_addr_t )req->data,
+                  i * req->size, sign,
                   req->size, &tmp);
             }
         } else if (req->dir == IOREQ_WRITE) {
             for (i = 0; i < req->count; i++) {
-                read_physical((target_phys_addr_t) req->data
-                  + (sign * i * req->size),
+                read_physical_offset((target_phys_addr_t) req->data,
+                  i * req->size, sign,
                   req->size, &tmp);
-                write_physical(req->addr
-                  + (sign * i * req->size),
+                write_physical_offset(req->addr,
+                  i * req->size, sign,
                   req->size, &tmp);
             }
         }
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 10 18:07:17 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Sep 2012 18:07: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 1TB8Nv-0007Xv-Er; Mon, 10 Sep 2012 18:06:59 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1TB8Nu-0007Xg-3O
	for xen-devel@lists.xensource.com; Mon, 10 Sep 2012 18:06:58 +0000
Received: from [85.158.139.83:28078] by server-5.bemta-5.messagelabs.com id
	62/C9-30514-14C2E405; Mon, 10 Sep 2012 18:06:57 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1347300414!29412184!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNzc5Njk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11852 invoked from network); 10 Sep 2012 18:06:55 -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;
	10 Sep 2012 18:06:55 -0000
X-IronPort-AV: E=Sophos;i="4.80,398,1344211200"; d="scan'208";a="207623410"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Sep 2012 18:06:54 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1;
	Mon, 10 Sep 2012 14:06:53 -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 1TB8Nk-0005UC-44;
	Mon, 10 Sep 2012 19:06:48 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Mon, 10 Sep 2012 19:06:23 +0100
Message-ID: <1347300383-9089-2-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <alpine.DEB.2.02.1209101842150.15568@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1209101842150.15568@kaball.uk.xensource.com>
MIME-Version: 1.0
Cc: dongxiao.xu@intel.com, Ian.Jackson@eu.citrix.com, qemu-devel@nongnu.org,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH 2/2] introduce read_physical_offset and
	write_physical_offset
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Remove read_physical and write_physical.
Introduce two new helper functions, read_physical_offset and
write_physical_offset, that take care of adding or subtracting offset
depending on sign. This way we avoid the automatic casting of sign to
uint32_t that is clearly not a very good idea and can easily cause
overflows. It also makes the code easier to understand.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 i386-dm/helper2.c |   60 +++++++++++++++++++++++++++++++++-------------------
 1 files changed, 38 insertions(+), 22 deletions(-)

diff --git a/i386-dm/helper2.c b/i386-dm/helper2.c
index 8f2a893..5eb1901 100644
--- a/i386-dm/helper2.c
+++ b/i386-dm/helper2.c
@@ -339,14 +339,30 @@ static void do_outp(CPUState *env, unsigned long addr,
     }
 }
 
-static inline void read_physical(uint64_t addr, unsigned long size, void *val)
+static inline void read_physical_offset(target_phys_addr_t addr,
+                                        unsigned long offset,
+                                        int sign,
+                                        unsigned long size,
+                                        void *val)
 {
-    return cpu_physical_memory_rw((target_phys_addr_t)addr, val, size, 0);
+    if (sign >= 0)
+        addr += offset;
+    else
+        addr -= offset;
+    return cpu_physical_memory_rw(addr, val, size, 0);
 }
 
-static inline void write_physical(uint64_t addr, unsigned long size, void *val)
+static inline void write_physical_offset(target_phys_addr_t addr,
+                                         unsigned long offset,
+                                         int sign,
+                                         unsigned long size,
+                                         void *val)
 {
-    return cpu_physical_memory_rw((target_phys_addr_t)addr, val, size, 1);
+    if (sign >= 0)
+        addr += offset;
+    else
+        addr -= offset;
+    return cpu_physical_memory_rw(addr, val, size, 1);
 }
 
 static void cpu_ioreq_pio(CPUState *env, ioreq_t *req)
@@ -364,9 +380,9 @@ static void cpu_ioreq_pio(CPUState *env, ioreq_t *req)
 
             for (i = 0; i < req->count; i++) {
                 tmp = do_inp(env, req->addr, req->size);
-                write_physical((target_phys_addr_t) req->data
-                  + (sign * i * req->size),
-                  req->size, &tmp);
+                write_physical_offset((target_phys_addr_t) req->data,
+                                      i * req->size, sign,
+                                      req->size, &tmp);
             }
         }
     } else if (req->dir == IOREQ_WRITE) {
@@ -376,9 +392,9 @@ static void cpu_ioreq_pio(CPUState *env, ioreq_t *req)
             for (i = 0; i < req->count; i++) {
                 unsigned long tmp = 0;
 
-                read_physical((target_phys_addr_t) req->data
-                  + (sign * i * req->size),
-                  req->size, &tmp);
+                read_physical_offset((target_phys_addr_t) req->data,
+                              i * req->size, sign,
+                              req->size, &tmp);
                 do_outp(env, req->addr, req->size, tmp);
             }
         }
@@ -395,14 +411,14 @@ static void cpu_ioreq_move(CPUState *env, ioreq_t *req)
     if (!req->data_is_ptr) {
         if (req->dir == IOREQ_READ) {
             for (i = 0; i < req->count; i++) {
-                read_physical(req->addr
-                  + (sign * i * req->size),
+                read_physical_offset(req->addr,
+                  i * req->size, sign,
                   req->size, &req->data);
             }
         } else if (req->dir == IOREQ_WRITE) {
             for (i = 0; i < req->count; i++) {
-                write_physical(req->addr
-                  + (sign * i * req->size),
+                write_physical_offset(req->addr,
+                  i * req->size, sign,
                   req->size, &req->data);
             }
         }
@@ -411,20 +427,20 @@ static void cpu_ioreq_move(CPUState *env, ioreq_t *req)
 
         if (req->dir == IOREQ_READ) {
             for (i = 0; i < req->count; i++) {
-                read_physical(req->addr
-                  + (sign * i * req->size),
+                read_physical_offset(req->addr,
+                  i * req->size, sign,
                   req->size, &tmp);
-                write_physical((target_phys_addr_t )req->data
-                  + (sign * i * req->size),
+                write_physical_offset((target_phys_addr_t )req->data,
+                  i * req->size, sign,
                   req->size, &tmp);
             }
         } else if (req->dir == IOREQ_WRITE) {
             for (i = 0; i < req->count; i++) {
-                read_physical((target_phys_addr_t) req->data
-                  + (sign * i * req->size),
+                read_physical_offset((target_phys_addr_t) req->data,
+                  i * req->size, sign,
                   req->size, &tmp);
-                write_physical(req->addr
-                  + (sign * i * req->size),
+                write_physical_offset(req->addr,
+                  i * req->size, sign,
                   req->size, &tmp);
             }
         }
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 10 18:07:20 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Sep 2012 18: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 1TB8Nz-0007Yr-Rd; Mon, 10 Sep 2012 18:07:03 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1TB8Ny-0007XX-BX
	for xen-devel@lists.xensource.com; Mon, 10 Sep 2012 18:07:02 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1347300414!10435621!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzAwNzQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13085 invoked from network); 10 Sep 2012 18:06:55 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Sep 2012 18:06:55 -0000
X-IronPort-AV: E=Sophos;i="4.80,398,1344211200"; d="scan'208";a="37360164"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Sep 2012 18:06:53 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1;
	Mon, 10 Sep 2012 14:06:53 -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 1TB8Nk-0005UC-3X;
	Mon, 10 Sep 2012 19:06:48 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Mon, 10 Sep 2012 19:06:22 +0100
Message-ID: <1347300383-9089-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.1209101842150.15568@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1209101842150.15568@kaball.uk.xensource.com>
MIME-Version: 1.0
Cc: dongxiao.xu@intel.com, Ian.Jackson@eu.citrix.com, qemu-devel@nongnu.org,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH 1/2] i should be uint32_t rather than int
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 code compare i (int) with req->count (uint32_t) in a for
loop, risking an infinite loop if req->count is equal to UINT_MAX.

Also i is only used in comparisons or multiplications with unsigned
integers.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 i386-dm/helper2.c |    6 ++++--
 1 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/i386-dm/helper2.c b/i386-dm/helper2.c
index c6d049c..8f2a893 100644
--- a/i386-dm/helper2.c
+++ b/i386-dm/helper2.c
@@ -351,7 +351,8 @@ static inline void write_physical(uint64_t addr, unsigned long size, void *val)
 
 static void cpu_ioreq_pio(CPUState *env, ioreq_t *req)
 {
-    int i, sign;
+    uint32_t i;
+    int sign;
 
     sign = req->df ? -1 : 1;
 
@@ -386,7 +387,8 @@ static void cpu_ioreq_pio(CPUState *env, ioreq_t *req)
 
 static void cpu_ioreq_move(CPUState *env, ioreq_t *req)
 {
-    int i, sign;
+    uint32_t i;
+    int sign;
 
     sign = req->df ? -1 : 1;
 
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 10 18:07:20 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Sep 2012 18: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 1TB8Nz-0007Yr-Rd; Mon, 10 Sep 2012 18:07:03 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1TB8Ny-0007XX-BX
	for xen-devel@lists.xensource.com; Mon, 10 Sep 2012 18:07:02 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1347300414!10435621!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzAwNzQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13085 invoked from network); 10 Sep 2012 18:06:55 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Sep 2012 18:06:55 -0000
X-IronPort-AV: E=Sophos;i="4.80,398,1344211200"; d="scan'208";a="37360164"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Sep 2012 18:06:53 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1;
	Mon, 10 Sep 2012 14:06:53 -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 1TB8Nk-0005UC-3X;
	Mon, 10 Sep 2012 19:06:48 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Mon, 10 Sep 2012 19:06:22 +0100
Message-ID: <1347300383-9089-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.1209101842150.15568@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1209101842150.15568@kaball.uk.xensource.com>
MIME-Version: 1.0
Cc: dongxiao.xu@intel.com, Ian.Jackson@eu.citrix.com, qemu-devel@nongnu.org,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH 1/2] i should be uint32_t rather than int
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 code compare i (int) with req->count (uint32_t) in a for
loop, risking an infinite loop if req->count is equal to UINT_MAX.

Also i is only used in comparisons or multiplications with unsigned
integers.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 i386-dm/helper2.c |    6 ++++--
 1 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/i386-dm/helper2.c b/i386-dm/helper2.c
index c6d049c..8f2a893 100644
--- a/i386-dm/helper2.c
+++ b/i386-dm/helper2.c
@@ -351,7 +351,8 @@ static inline void write_physical(uint64_t addr, unsigned long size, void *val)
 
 static void cpu_ioreq_pio(CPUState *env, ioreq_t *req)
 {
-    int i, sign;
+    uint32_t i;
+    int sign;
 
     sign = req->df ? -1 : 1;
 
@@ -386,7 +387,8 @@ static void cpu_ioreq_pio(CPUState *env, ioreq_t *req)
 
 static void cpu_ioreq_move(CPUState *env, ioreq_t *req)
 {
-    int i, sign;
+    uint32_t i;
+    int sign;
 
     sign = req->df ? -1 : 1;
 
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 10 18:33:11 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Sep 2012 18: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 1TB8mx-00082o-5J; Mon, 10 Sep 2012 18:32:51 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ashok.anand@gmail.com>) id 1TB8mw-00082b-3d
	for xen-devel@lists.xen.org; Mon, 10 Sep 2012 18:32:50 +0000
Received: from [85.158.139.83:28109] by server-4.bemta-5.messagelabs.com id
	D9/79-23042-1523E405; Mon, 10 Sep 2012 18:32:49 +0000
X-Env-Sender: ashok.anand@gmail.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1347301968!29140101!1
X-Originating-IP: [74.125.83.45]
X-SpamReason: No, hits=0.9 required=7.0 tests=BODY_RANDOM_LONG,
	HTML_50_60, HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14, RCVD_BY_IP,
	spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11999 invoked from network); 10 Sep 2012 18:32:48 -0000
Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com)
	(74.125.83.45)
	by server-13.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Sep 2012 18:32:48 -0000
Received: by eeke53 with SMTP id e53so1465351eek.32
	for <xen-devel@lists.xen.org>; Mon, 10 Sep 2012 11:32: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=Lx9UUSUWCM7DA8lmcy3FKUFRDjPk8N9+BOxpZ3iQPx0=;
	b=mANdwDzSpCcEVjxapqxIPw03oqyq9ewEq7Y0IMxbCDCxSo/bPuo9r6liHv+5ulPPkv
	SnY/4QRpyETp9vxe2wsuG16h7l2FxGWPUug6sHT8MLGefghg69IvXDok5gL+K0D9VVWs
	lihAzz0gMZgzsylGvxRo7yinndEHmCTtquNUJaE++Ue5C9ZwUwxUCL3VbXlM63/m/lI5
	m/qCoxZ5CDLEVruYR1g/e2H3EUzHbwLysfrkC/1H8/rIcYMinlzHN7TMJS+GKI6ARbva
	WKQ5wgUeL4UKR0g0OKvDbL7ReZBslyYpaoDAKm4hxXYFT4ERG49mKPb9NFtuUBqhynKc
	poMw==
MIME-Version: 1.0
Received: by 10.204.129.14 with SMTP id m14mr4118358bks.7.1347301967564; Mon,
	10 Sep 2012 11:32:47 -0700 (PDT)
Received: by 10.204.33.194 with HTTP; Mon, 10 Sep 2012 11:32:47 -0700 (PDT)
In-Reply-To: <CALQsBOXqT39-ZkOuTT-c58qUW6dihuXWfUi08YzjmgJzaW9YAA@mail.gmail.com>
References: <CALQsBOWDE_KqpntG8WJo86omLP3+rhQ0LDMW5vB752ubpF1FAA@mail.gmail.com>
	<CALQsBOXFVM+cdhmke5JDJmns2XUpHjyDOVN6R5qrrY9nTOR3SQ@mail.gmail.com>
	<504DC059.4070003@citrix.com>
	<CALQsBOV0EsUY+eYWqtL-FVuTOWOk_MLPnC2CYYPhNU9t=sxt9g@mail.gmail.com>
	<504DC334.6060201@citrix.com>
	<CALQsBOXqT39-ZkOuTT-c58qUW6dihuXWfUi08YzjmgJzaW9YAA@mail.gmail.com>
Date: Tue, 11 Sep 2012 00:02:47 +0530
Message-ID: <CALQsBOUAv_kPuAjbvyPZs90rGM7ZOBjEctC6iMuf6c+CL+VkDw@mail.gmail.com>
From: Ashok Anand <ashok.anand@gmail.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] issue using SRIOV "Unable to start - perhaps the PF
 driver is not up yet", while PF driver is actually up
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============8874624558075012550=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============8874624558075012550==
Content-Type: multipart/alternative; boundary=001517478a522e908004c95d2fd3

--001517478a522e908004c95d2fd3
Content-Type: text/plain; charset=ISO-8859-1

Any more thoughts on it? I will really appreciate it.

regards,
Ashok

On Mon, Sep 10, 2012 at 4:16 PM, Ashok Anand <ashok.anand@gmail.com> wrote:

>
> I am passing virtual functions. please see below ,based on the message
> from lspci.
>
>> What does lspci -vv for the physical function say?
>>
>> As for the physical function: it is unsafe to pass physical functions to
>> a non-trusted guest, as the physical function has complete control over the
>> all the virtual functions, even if they are passed through to other
>> guests.  For that reason, the physical function should remain in dom0 (or a
>> device driver domain if you are going for disaggregation).
>>
>
> here is the message lspci -vv | grep Eth gives me,
>
> 0f:00.0 Ethernet controller: Intel Corporation 82599EB 10-Gigabit SFI/SFP+
> Network Connection (rev 01)
>  Subsystem: Intel Corporation Ethernet Server Adapter X520-2
> 0f:00.1 Ethernet controller: Intel Corporation 82599EB 10-Gigabit SFI/SFP+
> Network Connection (rev 01)
>  Subsystem: Intel Corporation Ethernet Server Adapter X520-2
> 0f:10.0 Ethernet controller: Intel Corporation 82599 Ethernet Controller
> Virtual Function (rev 01)
> 0f:10.2 Ethernet controller: Intel Corporation 82599 Ethernet Controller
> Virtual Function (rev 01)
> 0f:10.4 Ethernet controller: Intel Corporation 82599 Ethernet Controller
> Virtual Function (rev 01)
> 0f:10.6 Ethernet controller: Intel Corporation 82599 Ethernet Controller
> Virtual Function (rev 01)
> 0f:11.0 Ethernet controller: Intel Corporation 82599 Ethernet Controller
> Virtual Function (rev 01)
> 0f:11.2 Ethernet controller: Intel Corporation 82599 Ethernet Controller
> Virtual Function (rev 01)
> 0f:11.4 Ethernet controller: Intel Corporation 82599 Ethernet Controller
> Virtual Function (rev 01)
> 0f:11.6 Ethernet controller: Intel Corporation 82599 Ethernet Controller
> Virtual Function (rev 01)
>
> Here, 0f:00.0 is the physical function, while 0f:10.0 and others are
> virtual functions -- so I am attaching virtual functions.
>
>
>
>
>>
>>
>>
>>
>>>
>>>
>>>  i attach 0f:10.0 to a domU ubuntu machine, xm pci-attach ubuntu 0f:10.0
>>>
>>>  on my dom0 machine, i can ping other machine using eth2, (implying PF
>>> on eth2 is active)
>>>
>>>  on my domU machine, when i attach the virtual function, i get the
>>> following messages
>>>
>>>  [ 2282.688356 <%5B%202282.688356>] ixgbevf 0000:00:00.0: Xen PCI
>>> mapped GSI0 to IRQ28
>>> [ 2282.688470 <%5B%202282.688470>] ixgbevf 0000:00:00.0: setting
>>> latency timer to 64
>>> [ 2282.690187 <%5B%202282.690187>] ixgbevf 0000:00:00.0: PF still in
>>> reset state, assigning new address
>>>
>>>  while PF on eth2 is  there and active, since i can ping other machine.
>>>
>>>  Now, when I try to bring up the VF interface on domU,
>>>  i get the following error
>>>
>>>   2476.295582] Unable to start - perhaps the PF Driver isn't up yet
>>> SIOCSIFFLAGS: Network is down
>>> [ 2476.296917] Unable to start - perhaps the PF Driver isn't up yet
>>>  SIOCSIFFLAGS: Network is down
>>>
>>>  and on dmesg on domU,
>>>  [ 2476.295582] Unable to start - perhaps the PF Driver isn't up yet
>>> [ 2476.296917] Unable to start - perhaps the PF Driver isn't up yet
>>>
>>>
>>>  Any thoughts on what could be wrong? I have been struggling with this
>>> for quite some time
>>> and would really appreciate your thoughts on it.
>>>
>>>  Thanks,
>>>  Ashok
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>  --
>>> 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
>>>
>>>
>>
>> --
>> Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
>> T: +44 (0)1223 225 900, http://www.citrix.com
>>
>>
>

--001517478a522e908004c95d2fd3
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Any more thoughts on it? I will really appreciate it.<div><br></div><div>re=
gards,</div><div>Ashok<br><br><div class=3D"gmail_quote">On Mon, Sep 10, 20=
12 at 4:16 PM, Ashok Anand <span dir=3D"ltr">&lt;<a href=3D"mailto:ashok.an=
and@gmail.com" target=3D"_blank">ashok.anand@gmail.com</a>&gt;</span> wrote=
:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div class=3D"gmail_quote"><div><br></div><d=
iv>I am passing virtual functions. please see below ,based on the message f=
rom lspci.=A0</div>
<div class=3D"im"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .=
8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor=3D"#FFFFFF" text=3D"#000000">What does lspci -vv for the physi=
cal function say?<br>
    <br>
    As for the physical function: it is unsafe to pass physical
    functions to a non-trusted guest, as the physical function has
    complete control over the all the virtual functions, even if they
    are passed through to other guests.=A0 For that reason, the physical
    function should remain in dom0 (or a device driver domain if you are
    going for disaggregation).</div></blockquote><div><br></div></div><div>=
here is the message lspci -vv | grep Eth gives me,=A0</div><div><br></div><=
div><div>0f:00.0 Ethernet controller: Intel Corporation 82599EB 10-Gigabit =
SFI/SFP+ Network Connection (rev 01)</div>

<div><span style=3D"white-space:pre-wrap">	</span>Subsystem: Intel Corporat=
ion Ethernet Server Adapter X520-2</div><div>0f:00.1 Ethernet controller: I=
ntel Corporation 82599EB 10-Gigabit SFI/SFP+ Network Connection (rev 01)</d=
iv>

<div><span style=3D"white-space:pre-wrap">	</span>Subsystem: Intel Corporat=
ion Ethernet Server Adapter X520-2</div><div>0f:10.0 Ethernet controller: I=
ntel Corporation 82599 Ethernet Controller Virtual Function (rev 01)</div>

<div>0f:10.2 Ethernet controller: Intel Corporation 82599 Ethernet Controll=
er Virtual Function (rev 01)</div><div>0f:10.4 Ethernet controller: Intel C=
orporation 82599 Ethernet Controller Virtual Function (rev 01)</div><div>

0f:10.6 Ethernet controller: Intel Corporation 82599 Ethernet Controller Vi=
rtual Function (rev 01)</div><div>0f:11.0 Ethernet controller: Intel Corpor=
ation 82599 Ethernet Controller Virtual Function (rev 01)</div><div>0f:11.2=
 Ethernet controller: Intel Corporation 82599 Ethernet Controller Virtual F=
unction (rev 01)</div>

<div>0f:11.4 Ethernet controller: Intel Corporation 82599 Ethernet Controll=
er Virtual Function (rev 01)</div><div>0f:11.6 Ethernet controller: Intel C=
orporation 82599 Ethernet Controller Virtual Function (rev 01)</div></div>

<div><br></div><div>Here, 0f:00.0 is the physical function, while 0f:10.0 a=
nd others are virtual functions -- so I am attaching virtual functions.=A0<=
/div><div><div class=3D"h5"><div><br></div><div><br></div><div>=A0</div><bl=
ockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #=
ccc solid;padding-left:1ex">

<div bgcolor=3D"#FFFFFF" text=3D"#000000"><div><div><br>
    <br>
    <blockquote type=3D"cite">
      <div class=3D"gmail_quote">
        <div><br>
        </div>
        <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border=
-left:1px #ccc solid;padding-left:1ex">
          <div bgcolor=3D"#FFFFFF" text=3D"#000000">
            <div><br>
              <br>
              <blockquote type=3D"cite">
                <div class=3D"gmail_quote">
                  <div><br>
                  </div>
                  <div>i attach 0f:10.0 to a domU ubuntu machine,=A0xm
                    pci-attach ubuntu 0f:10.0</div>
                  <div><br>
                  </div>
                  <div>on my dom0 machine, i can ping other machine
                    using eth2, (implying PF on eth2 is active)</div>
                  <div><br>
                  </div>
                  <div>on my domU machine, when i attach the virtual
                    function, i get the following messages</div>
                  <div><br>
                  </div>
                  <div>
                    <div><a href=3D"tel:%5B%202282.688356" value=3D"+122826=
88356" target=3D"_blank">[
                        2282.688356</a>] ixgbevf 0000:00:00.0: Xen PCI
                      mapped GSI0 to IRQ28</div>
                    <div><a href=3D"tel:%5B%202282.688470" value=3D"+122826=
88470" target=3D"_blank">[
                        2282.688470</a>] ixgbevf 0000:00:00.0: setting
                      latency timer to 64</div>
                    <div><a href=3D"tel:%5B%202282.690187" value=3D"+122826=
90187" target=3D"_blank">[
                        2282.690187</a>] ixgbevf 0000:00:00.0: PF still
                      in reset state, assigning new address</div>
                  </div>
                  <div><br>
                  </div>
                  <div>while PF on eth2 is =A0there and active, since i
                    can ping other machine.</div>
                  <div><br>
                  </div>
                  <div>Now, when I try to bring up the VF interface on
                    domU,=A0</div>
                  <div>=A0i get the following error</div>
                  <div> <br>
                  </div>
                  <div>
                    <div>=A02476.295582] Unable to start - perhaps the PF
                      Driver isn&#39;t up yet</div>
                    <div>SIOCSIFFLAGS: Network is down</div>
                    <div>[ 2476.296917] Unable to start - perhaps the PF
                      Driver isn&#39;t up yet</div>
                    <div> SIOCSIFFLAGS: Network is down</div>
                  </div>
                  <div><br>
                  </div>
                  <div>and on dmesg on domU,=A0</div>
                  <div>
                    <div>[ 2476.295582] Unable to start - perhaps the PF
                      Driver isn&#39;t up yet</div>
                    <div>[ 2476.296917] Unable to start - perhaps the PF
                      Driver isn&#39;t up yet</div>
                  </div>
                  <div><br>
                  </div>
                  <div><br>
                  </div>
                  <div>Any thoughts on what could be wrong? I have been
                    struggling with this for quite some time</div>
                  <div>and would really appreciate your thoughts on it.</di=
v>
                  <div><br>
                  </div>
                  <div>Thanks,=A0</div>
                  <span><font color=3D"#888888">
                      <div>Ashok</div>
                      <div><br>
                      </div>
                      <div><br>
                      </div>
                      <div><br>
                      </div>
                      <div><br>
                      </div>
                      <div><br>
                      </div>
                    </font></span></div>
                <br>
              </blockquote>
              <br>
            </div>
            <span><font color=3D"#888888">
                <pre cols=3D"72">--=20
Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
T: <a href=3D"tel:%2B44%20%280%291223%20225%20900" value=3D"+441223225900" =
target=3D"_blank">+44 (0)1223 225 900</a>, <a href=3D"http://www.citrix.com=
" target=3D"_blank">http://www.citrix.com</a></pre>
              </font></span></div>
          <br>
          _______________________________________________<br>
          Xen-devel mailing list<br>
          <a href=3D"mailto:Xen-devel@lists.xen.org" target=3D"_blank">Xen-=
devel@lists.xen.org</a><br>
          <a href=3D"http://lists.xen.org/xen-devel" target=3D"_blank">http=
://lists.xen.org/xen-devel</a><br>
          <br>
        </blockquote>
      </div>
      <br>
    </blockquote>
    <br>
    <pre cols=3D"72">--=20
Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
T: <a href=3D"tel:%2B44%20%280%291223%20225%20900" value=3D"+441223225900" =
target=3D"_blank">+44 (0)1223 225 900</a>, <a href=3D"http://www.citrix.com=
" target=3D"_blank">http://www.citrix.com</a></pre>
  </div></div></div>

</blockquote></div></div></div><br>
</blockquote></div><br></div>

--001517478a522e908004c95d2fd3--


--===============8874624558075012550==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============8874624558075012550==--


From xen-devel-bounces@lists.xen.org Mon Sep 10 18:33:11 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Sep 2012 18: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 1TB8mx-00082o-5J; Mon, 10 Sep 2012 18:32:51 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ashok.anand@gmail.com>) id 1TB8mw-00082b-3d
	for xen-devel@lists.xen.org; Mon, 10 Sep 2012 18:32:50 +0000
Received: from [85.158.139.83:28109] by server-4.bemta-5.messagelabs.com id
	D9/79-23042-1523E405; Mon, 10 Sep 2012 18:32:49 +0000
X-Env-Sender: ashok.anand@gmail.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1347301968!29140101!1
X-Originating-IP: [74.125.83.45]
X-SpamReason: No, hits=0.9 required=7.0 tests=BODY_RANDOM_LONG,
	HTML_50_60, HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14, RCVD_BY_IP,
	spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11999 invoked from network); 10 Sep 2012 18:32:48 -0000
Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com)
	(74.125.83.45)
	by server-13.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Sep 2012 18:32:48 -0000
Received: by eeke53 with SMTP id e53so1465351eek.32
	for <xen-devel@lists.xen.org>; Mon, 10 Sep 2012 11:32: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=Lx9UUSUWCM7DA8lmcy3FKUFRDjPk8N9+BOxpZ3iQPx0=;
	b=mANdwDzSpCcEVjxapqxIPw03oqyq9ewEq7Y0IMxbCDCxSo/bPuo9r6liHv+5ulPPkv
	SnY/4QRpyETp9vxe2wsuG16h7l2FxGWPUug6sHT8MLGefghg69IvXDok5gL+K0D9VVWs
	lihAzz0gMZgzsylGvxRo7yinndEHmCTtquNUJaE++Ue5C9ZwUwxUCL3VbXlM63/m/lI5
	m/qCoxZ5CDLEVruYR1g/e2H3EUzHbwLysfrkC/1H8/rIcYMinlzHN7TMJS+GKI6ARbva
	WKQ5wgUeL4UKR0g0OKvDbL7ReZBslyYpaoDAKm4hxXYFT4ERG49mKPb9NFtuUBqhynKc
	poMw==
MIME-Version: 1.0
Received: by 10.204.129.14 with SMTP id m14mr4118358bks.7.1347301967564; Mon,
	10 Sep 2012 11:32:47 -0700 (PDT)
Received: by 10.204.33.194 with HTTP; Mon, 10 Sep 2012 11:32:47 -0700 (PDT)
In-Reply-To: <CALQsBOXqT39-ZkOuTT-c58qUW6dihuXWfUi08YzjmgJzaW9YAA@mail.gmail.com>
References: <CALQsBOWDE_KqpntG8WJo86omLP3+rhQ0LDMW5vB752ubpF1FAA@mail.gmail.com>
	<CALQsBOXFVM+cdhmke5JDJmns2XUpHjyDOVN6R5qrrY9nTOR3SQ@mail.gmail.com>
	<504DC059.4070003@citrix.com>
	<CALQsBOV0EsUY+eYWqtL-FVuTOWOk_MLPnC2CYYPhNU9t=sxt9g@mail.gmail.com>
	<504DC334.6060201@citrix.com>
	<CALQsBOXqT39-ZkOuTT-c58qUW6dihuXWfUi08YzjmgJzaW9YAA@mail.gmail.com>
Date: Tue, 11 Sep 2012 00:02:47 +0530
Message-ID: <CALQsBOUAv_kPuAjbvyPZs90rGM7ZOBjEctC6iMuf6c+CL+VkDw@mail.gmail.com>
From: Ashok Anand <ashok.anand@gmail.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] issue using SRIOV "Unable to start - perhaps the PF
 driver is not up yet", while PF driver is actually up
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============8874624558075012550=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============8874624558075012550==
Content-Type: multipart/alternative; boundary=001517478a522e908004c95d2fd3

--001517478a522e908004c95d2fd3
Content-Type: text/plain; charset=ISO-8859-1

Any more thoughts on it? I will really appreciate it.

regards,
Ashok

On Mon, Sep 10, 2012 at 4:16 PM, Ashok Anand <ashok.anand@gmail.com> wrote:

>
> I am passing virtual functions. please see below ,based on the message
> from lspci.
>
>> What does lspci -vv for the physical function say?
>>
>> As for the physical function: it is unsafe to pass physical functions to
>> a non-trusted guest, as the physical function has complete control over the
>> all the virtual functions, even if they are passed through to other
>> guests.  For that reason, the physical function should remain in dom0 (or a
>> device driver domain if you are going for disaggregation).
>>
>
> here is the message lspci -vv | grep Eth gives me,
>
> 0f:00.0 Ethernet controller: Intel Corporation 82599EB 10-Gigabit SFI/SFP+
> Network Connection (rev 01)
>  Subsystem: Intel Corporation Ethernet Server Adapter X520-2
> 0f:00.1 Ethernet controller: Intel Corporation 82599EB 10-Gigabit SFI/SFP+
> Network Connection (rev 01)
>  Subsystem: Intel Corporation Ethernet Server Adapter X520-2
> 0f:10.0 Ethernet controller: Intel Corporation 82599 Ethernet Controller
> Virtual Function (rev 01)
> 0f:10.2 Ethernet controller: Intel Corporation 82599 Ethernet Controller
> Virtual Function (rev 01)
> 0f:10.4 Ethernet controller: Intel Corporation 82599 Ethernet Controller
> Virtual Function (rev 01)
> 0f:10.6 Ethernet controller: Intel Corporation 82599 Ethernet Controller
> Virtual Function (rev 01)
> 0f:11.0 Ethernet controller: Intel Corporation 82599 Ethernet Controller
> Virtual Function (rev 01)
> 0f:11.2 Ethernet controller: Intel Corporation 82599 Ethernet Controller
> Virtual Function (rev 01)
> 0f:11.4 Ethernet controller: Intel Corporation 82599 Ethernet Controller
> Virtual Function (rev 01)
> 0f:11.6 Ethernet controller: Intel Corporation 82599 Ethernet Controller
> Virtual Function (rev 01)
>
> Here, 0f:00.0 is the physical function, while 0f:10.0 and others are
> virtual functions -- so I am attaching virtual functions.
>
>
>
>
>>
>>
>>
>>
>>>
>>>
>>>  i attach 0f:10.0 to a domU ubuntu machine, xm pci-attach ubuntu 0f:10.0
>>>
>>>  on my dom0 machine, i can ping other machine using eth2, (implying PF
>>> on eth2 is active)
>>>
>>>  on my domU machine, when i attach the virtual function, i get the
>>> following messages
>>>
>>>  [ 2282.688356 <%5B%202282.688356>] ixgbevf 0000:00:00.0: Xen PCI
>>> mapped GSI0 to IRQ28
>>> [ 2282.688470 <%5B%202282.688470>] ixgbevf 0000:00:00.0: setting
>>> latency timer to 64
>>> [ 2282.690187 <%5B%202282.690187>] ixgbevf 0000:00:00.0: PF still in
>>> reset state, assigning new address
>>>
>>>  while PF on eth2 is  there and active, since i can ping other machine.
>>>
>>>  Now, when I try to bring up the VF interface on domU,
>>>  i get the following error
>>>
>>>   2476.295582] Unable to start - perhaps the PF Driver isn't up yet
>>> SIOCSIFFLAGS: Network is down
>>> [ 2476.296917] Unable to start - perhaps the PF Driver isn't up yet
>>>  SIOCSIFFLAGS: Network is down
>>>
>>>  and on dmesg on domU,
>>>  [ 2476.295582] Unable to start - perhaps the PF Driver isn't up yet
>>> [ 2476.296917] Unable to start - perhaps the PF Driver isn't up yet
>>>
>>>
>>>  Any thoughts on what could be wrong? I have been struggling with this
>>> for quite some time
>>> and would really appreciate your thoughts on it.
>>>
>>>  Thanks,
>>>  Ashok
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>  --
>>> 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
>>>
>>>
>>
>> --
>> Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
>> T: +44 (0)1223 225 900, http://www.citrix.com
>>
>>
>

--001517478a522e908004c95d2fd3
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Any more thoughts on it? I will really appreciate it.<div><br></div><div>re=
gards,</div><div>Ashok<br><br><div class=3D"gmail_quote">On Mon, Sep 10, 20=
12 at 4:16 PM, Ashok Anand <span dir=3D"ltr">&lt;<a href=3D"mailto:ashok.an=
and@gmail.com" target=3D"_blank">ashok.anand@gmail.com</a>&gt;</span> wrote=
:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div class=3D"gmail_quote"><div><br></div><d=
iv>I am passing virtual functions. please see below ,based on the message f=
rom lspci.=A0</div>
<div class=3D"im"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .=
8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor=3D"#FFFFFF" text=3D"#000000">What does lspci -vv for the physi=
cal function say?<br>
    <br>
    As for the physical function: it is unsafe to pass physical
    functions to a non-trusted guest, as the physical function has
    complete control over the all the virtual functions, even if they
    are passed through to other guests.=A0 For that reason, the physical
    function should remain in dom0 (or a device driver domain if you are
    going for disaggregation).</div></blockquote><div><br></div></div><div>=
here is the message lspci -vv | grep Eth gives me,=A0</div><div><br></div><=
div><div>0f:00.0 Ethernet controller: Intel Corporation 82599EB 10-Gigabit =
SFI/SFP+ Network Connection (rev 01)</div>

<div><span style=3D"white-space:pre-wrap">	</span>Subsystem: Intel Corporat=
ion Ethernet Server Adapter X520-2</div><div>0f:00.1 Ethernet controller: I=
ntel Corporation 82599EB 10-Gigabit SFI/SFP+ Network Connection (rev 01)</d=
iv>

<div><span style=3D"white-space:pre-wrap">	</span>Subsystem: Intel Corporat=
ion Ethernet Server Adapter X520-2</div><div>0f:10.0 Ethernet controller: I=
ntel Corporation 82599 Ethernet Controller Virtual Function (rev 01)</div>

<div>0f:10.2 Ethernet controller: Intel Corporation 82599 Ethernet Controll=
er Virtual Function (rev 01)</div><div>0f:10.4 Ethernet controller: Intel C=
orporation 82599 Ethernet Controller Virtual Function (rev 01)</div><div>

0f:10.6 Ethernet controller: Intel Corporation 82599 Ethernet Controller Vi=
rtual Function (rev 01)</div><div>0f:11.0 Ethernet controller: Intel Corpor=
ation 82599 Ethernet Controller Virtual Function (rev 01)</div><div>0f:11.2=
 Ethernet controller: Intel Corporation 82599 Ethernet Controller Virtual F=
unction (rev 01)</div>

<div>0f:11.4 Ethernet controller: Intel Corporation 82599 Ethernet Controll=
er Virtual Function (rev 01)</div><div>0f:11.6 Ethernet controller: Intel C=
orporation 82599 Ethernet Controller Virtual Function (rev 01)</div></div>

<div><br></div><div>Here, 0f:00.0 is the physical function, while 0f:10.0 a=
nd others are virtual functions -- so I am attaching virtual functions.=A0<=
/div><div><div class=3D"h5"><div><br></div><div><br></div><div>=A0</div><bl=
ockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #=
ccc solid;padding-left:1ex">

<div bgcolor=3D"#FFFFFF" text=3D"#000000"><div><div><br>
    <br>
    <blockquote type=3D"cite">
      <div class=3D"gmail_quote">
        <div><br>
        </div>
        <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border=
-left:1px #ccc solid;padding-left:1ex">
          <div bgcolor=3D"#FFFFFF" text=3D"#000000">
            <div><br>
              <br>
              <blockquote type=3D"cite">
                <div class=3D"gmail_quote">
                  <div><br>
                  </div>
                  <div>i attach 0f:10.0 to a domU ubuntu machine,=A0xm
                    pci-attach ubuntu 0f:10.0</div>
                  <div><br>
                  </div>
                  <div>on my dom0 machine, i can ping other machine
                    using eth2, (implying PF on eth2 is active)</div>
                  <div><br>
                  </div>
                  <div>on my domU machine, when i attach the virtual
                    function, i get the following messages</div>
                  <div><br>
                  </div>
                  <div>
                    <div><a href=3D"tel:%5B%202282.688356" value=3D"+122826=
88356" target=3D"_blank">[
                        2282.688356</a>] ixgbevf 0000:00:00.0: Xen PCI
                      mapped GSI0 to IRQ28</div>
                    <div><a href=3D"tel:%5B%202282.688470" value=3D"+122826=
88470" target=3D"_blank">[
                        2282.688470</a>] ixgbevf 0000:00:00.0: setting
                      latency timer to 64</div>
                    <div><a href=3D"tel:%5B%202282.690187" value=3D"+122826=
90187" target=3D"_blank">[
                        2282.690187</a>] ixgbevf 0000:00:00.0: PF still
                      in reset state, assigning new address</div>
                  </div>
                  <div><br>
                  </div>
                  <div>while PF on eth2 is =A0there and active, since i
                    can ping other machine.</div>
                  <div><br>
                  </div>
                  <div>Now, when I try to bring up the VF interface on
                    domU,=A0</div>
                  <div>=A0i get the following error</div>
                  <div> <br>
                  </div>
                  <div>
                    <div>=A02476.295582] Unable to start - perhaps the PF
                      Driver isn&#39;t up yet</div>
                    <div>SIOCSIFFLAGS: Network is down</div>
                    <div>[ 2476.296917] Unable to start - perhaps the PF
                      Driver isn&#39;t up yet</div>
                    <div> SIOCSIFFLAGS: Network is down</div>
                  </div>
                  <div><br>
                  </div>
                  <div>and on dmesg on domU,=A0</div>
                  <div>
                    <div>[ 2476.295582] Unable to start - perhaps the PF
                      Driver isn&#39;t up yet</div>
                    <div>[ 2476.296917] Unable to start - perhaps the PF
                      Driver isn&#39;t up yet</div>
                  </div>
                  <div><br>
                  </div>
                  <div><br>
                  </div>
                  <div>Any thoughts on what could be wrong? I have been
                    struggling with this for quite some time</div>
                  <div>and would really appreciate your thoughts on it.</di=
v>
                  <div><br>
                  </div>
                  <div>Thanks,=A0</div>
                  <span><font color=3D"#888888">
                      <div>Ashok</div>
                      <div><br>
                      </div>
                      <div><br>
                      </div>
                      <div><br>
                      </div>
                      <div><br>
                      </div>
                      <div><br>
                      </div>
                    </font></span></div>
                <br>
              </blockquote>
              <br>
            </div>
            <span><font color=3D"#888888">
                <pre cols=3D"72">--=20
Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
T: <a href=3D"tel:%2B44%20%280%291223%20225%20900" value=3D"+441223225900" =
target=3D"_blank">+44 (0)1223 225 900</a>, <a href=3D"http://www.citrix.com=
" target=3D"_blank">http://www.citrix.com</a></pre>
              </font></span></div>
          <br>
          _______________________________________________<br>
          Xen-devel mailing list<br>
          <a href=3D"mailto:Xen-devel@lists.xen.org" target=3D"_blank">Xen-=
devel@lists.xen.org</a><br>
          <a href=3D"http://lists.xen.org/xen-devel" target=3D"_blank">http=
://lists.xen.org/xen-devel</a><br>
          <br>
        </blockquote>
      </div>
      <br>
    </blockquote>
    <br>
    <pre cols=3D"72">--=20
Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
T: <a href=3D"tel:%2B44%20%280%291223%20225%20900" value=3D"+441223225900" =
target=3D"_blank">+44 (0)1223 225 900</a>, <a href=3D"http://www.citrix.com=
" target=3D"_blank">http://www.citrix.com</a></pre>
  </div></div></div>

</blockquote></div></div></div><br>
</blockquote></div><br></div>

--001517478a522e908004c95d2fd3--


--===============8874624558075012550==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============8874624558075012550==--


From xen-devel-bounces@lists.xen.org Mon Sep 10 19:36:09 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Sep 2012 19:36:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TB9lo-0000dy-7u; Mon, 10 Sep 2012 19:35:44 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ketuzsezr@gmail.com>) id 1TB9lm-0000dt-Mh
	for xen-devel@lists.xen.org; Mon, 10 Sep 2012 19:35:42 +0000
Received: from [85.158.143.35:42942] by server-1.bemta-4.messagelabs.com id
	51/BB-12504-D014E405; Mon, 10 Sep 2012 19:35:41 +0000
X-Env-Sender: ketuzsezr@gmail.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1347305739!6621288!1
X-Originating-IP: [209.85.212.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14317 invoked from network); 10 Sep 2012 19:35:40 -0000
Received: from mail-vb0-f45.google.com (HELO mail-vb0-f45.google.com)
	(209.85.212.45)
	by server-2.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Sep 2012 19:35:40 -0000
Received: by vbip1 with SMTP id p1so3893192vbi.32
	for <xen-devel@lists.xen.org>; Mon, 10 Sep 2012 12:35: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=W7nxEc0lyqg2xq8WL4Eh0CTdRkLQnCHKRyiWc1ZTI1M=;
	b=BoHJOLP8Du9J1jlAwQAaz5BrbCTvdHDpRF7JNtnacW/ux3JtmM/8pH9+XFn9e3GNBs
	5DOFEgcC3fG9zW36WlplUHfqGB7C9rRdg5j3gfxjBmm5L7Bt/iT0uzxN8hAo+Yl2jJCc
	HG71nwFCB2LJl1trkNKb1TDdfbJCzb/5Cb6fJkU8Ek/ffbNFt7ZHN3TLudGMf0mpyyoe
	FgJ1pjnuYuWmedplhJgSuxGsrNPB5NHEquEXYaFrY1JO+bTYe+rA7iAg2Dmf2SP+dnkr
	rYUJQ+T7eWRAXb3Gq5HBzAB9o8nPff/I8CgVXZoUGc0pSNSKRC6ZK5wYR5unjdZJsY80
	KtSg==
Received: by 10.220.155.3 with SMTP id q3mr21389774vcw.11.1347305738502;
	Mon, 10 Sep 2012 12:35:38 -0700 (PDT)
Received: from phenom.dumpdata.com
	(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 us1sm9217997vec.9.2012.09.10.12.35.37
	(version=TLSv1/SSLv3 cipher=OTHER);
	Mon, 10 Sep 2012 12:35:37 -0700 (PDT)
Date: Mon, 10 Sep 2012 15:24:57 -0400
From: Konrad Rzeszutek Wilk <konrad@kernel.org>
To: Bei Guan <gbtju85@gmail.com>
Message-ID: <20120910192456.GA28298@phenom.dumpdata.com>
References: <CAEQjb-TO9wy74up6pGfaRj+FQH8SPJtLXngM70ivWwWaQ53QPA@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAEQjb-TO9wy74up6pGfaRj+FQH8SPJtLXngM70ivWwWaQ53QPA@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Any news or plan about Xen support the APU
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Sep 10, 2012 at 08:48:41PM +0800, Bei Guan wrote:
> Hi,
> 
> Is there any news or plan about Xen support the latest AMD hardware APU
> (Accelerated Processing Unit)? Any clue is appreciated.

Not sure what you mean, but it works just fine on the AMD A5 CPU I've?
Are you hitting an issues?
> Thank you very much.
> 
> 
> 
> Best Regards,
> Bei Guan

> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Sep 10 19:36:09 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Sep 2012 19:36:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TB9lo-0000dy-7u; Mon, 10 Sep 2012 19:35:44 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ketuzsezr@gmail.com>) id 1TB9lm-0000dt-Mh
	for xen-devel@lists.xen.org; Mon, 10 Sep 2012 19:35:42 +0000
Received: from [85.158.143.35:42942] by server-1.bemta-4.messagelabs.com id
	51/BB-12504-D014E405; Mon, 10 Sep 2012 19:35:41 +0000
X-Env-Sender: ketuzsezr@gmail.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1347305739!6621288!1
X-Originating-IP: [209.85.212.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14317 invoked from network); 10 Sep 2012 19:35:40 -0000
Received: from mail-vb0-f45.google.com (HELO mail-vb0-f45.google.com)
	(209.85.212.45)
	by server-2.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Sep 2012 19:35:40 -0000
Received: by vbip1 with SMTP id p1so3893192vbi.32
	for <xen-devel@lists.xen.org>; Mon, 10 Sep 2012 12:35: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=W7nxEc0lyqg2xq8WL4Eh0CTdRkLQnCHKRyiWc1ZTI1M=;
	b=BoHJOLP8Du9J1jlAwQAaz5BrbCTvdHDpRF7JNtnacW/ux3JtmM/8pH9+XFn9e3GNBs
	5DOFEgcC3fG9zW36WlplUHfqGB7C9rRdg5j3gfxjBmm5L7Bt/iT0uzxN8hAo+Yl2jJCc
	HG71nwFCB2LJl1trkNKb1TDdfbJCzb/5Cb6fJkU8Ek/ffbNFt7ZHN3TLudGMf0mpyyoe
	FgJ1pjnuYuWmedplhJgSuxGsrNPB5NHEquEXYaFrY1JO+bTYe+rA7iAg2Dmf2SP+dnkr
	rYUJQ+T7eWRAXb3Gq5HBzAB9o8nPff/I8CgVXZoUGc0pSNSKRC6ZK5wYR5unjdZJsY80
	KtSg==
Received: by 10.220.155.3 with SMTP id q3mr21389774vcw.11.1347305738502;
	Mon, 10 Sep 2012 12:35:38 -0700 (PDT)
Received: from phenom.dumpdata.com
	(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 us1sm9217997vec.9.2012.09.10.12.35.37
	(version=TLSv1/SSLv3 cipher=OTHER);
	Mon, 10 Sep 2012 12:35:37 -0700 (PDT)
Date: Mon, 10 Sep 2012 15:24:57 -0400
From: Konrad Rzeszutek Wilk <konrad@kernel.org>
To: Bei Guan <gbtju85@gmail.com>
Message-ID: <20120910192456.GA28298@phenom.dumpdata.com>
References: <CAEQjb-TO9wy74up6pGfaRj+FQH8SPJtLXngM70ivWwWaQ53QPA@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAEQjb-TO9wy74up6pGfaRj+FQH8SPJtLXngM70ivWwWaQ53QPA@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Any news or plan about Xen support the APU
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Sep 10, 2012 at 08:48:41PM +0800, Bei Guan wrote:
> Hi,
> 
> Is there any news or plan about Xen support the latest AMD hardware APU
> (Accelerated Processing Unit)? Any clue is appreciated.

Not sure what you mean, but it works just fine on the AMD A5 CPU I've?
Are you hitting an issues?
> Thank you very much.
> 
> 
> 
> Best Regards,
> Bei Guan

> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Sep 10 19:38:42 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Sep 2012 19:38:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TB9oL-0000lH-VT; Mon, 10 Sep 2012 19:38:21 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ketuzsezr@gmail.com>) id 1TB9oK-0000lB-4z
	for xen-devel@lists.xen.org; Mon, 10 Sep 2012 19:38:20 +0000
Received: from [85.158.139.83:25219] by server-3.bemta-5.messagelabs.com id
	E9/C6-21836-9A14E405; Mon, 10 Sep 2012 19:38:17 +0000
X-Env-Sender: ketuzsezr@gmail.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1347305895!25799382!1
X-Originating-IP: [209.85.212.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16155 invoked from network); 10 Sep 2012 19:38:16 -0000
Received: from mail-vb0-f45.google.com (HELO mail-vb0-f45.google.com)
	(209.85.212.45)
	by server-6.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Sep 2012 19:38:16 -0000
Received: by vbip1 with SMTP id p1so3897660vbi.32
	for <xen-devel@lists.xen.org>; Mon, 10 Sep 2012 12:38:15 -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=VoLS42u0H66L/lvVh6UsbZcuIX7bUPetaxYSh0WyBh8=;
	b=PZUIlXTT3kEMc1bi3RgBrcl3VP3LjAADlHceF4QClPfFX+r9uA4Q2GS2NrX1hrWYcN
	b7OOZKFLl02o6rW7+3pIlKK1XbRJZ9pEs+Rcpwg+/Eb6TPg1fPhi0VI/0KOrlG+NF+cF
	EFAEyiQ8KHtDeQ8MqppmxtwHw1VyjaoNIdSM2LcqEHOHnuFPxkCs94ZHWsmcV1j8Xt5o
	dAgTDx/EDwAorheBfWXUsa2d/cBlnNNdA+jtYAaAtkW2hYYNE/im9SfGwNmRMqJWosXd
	1qzxI4/r5fI2lctM6Pae0iPNfxGfddn4Xu4JcA66bIwi7ip2aUQkZ0C8c7nyKEV2g4pS
	t1Jw==
Received: by 10.220.16.12 with SMTP id m12mr9892214vca.14.1347305894936;
	Mon, 10 Sep 2012 12:38:14 -0700 (PDT)
Received: from phenom.dumpdata.com
	(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 b6sm406550vea.2.2012.09.10.12.38.13
	(version=TLSv1/SSLv3 cipher=OTHER);
	Mon, 10 Sep 2012 12:38:14 -0700 (PDT)
Date: Mon, 10 Sep 2012 15:27:34 -0400
From: Konrad Rzeszutek Wilk <konrad@kernel.org>
To: bunkertor <bunkertor@tiscali.it>
Message-ID: <20120910192732.GB28298@phenom.dumpdata.com>
References: <504E10DA.6040603@tiscali.it>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <504E10DA.6040603@tiscali.it>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] grub error 28
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> 
>     GNU GRUB  version 0.97  (640K lower / 3072K upper memory)
> 
>  [ Minimal BASH-like line editing is supported.  For the first word, TAB
>    lists possible command completions.  Anywhere else TAB lists the
> possible
>    completions of a device/filename.]
> grub> root (hd0,0)
> root (hd0,0)
>  Filesystem type is ext2fs, partition type 0x83
> grub> kernel /xen.gz
> kernel /xen.gz
>    [Multiboot-elf, <0x964000:0x1a6db8:0x54248>(bad)
> 
> Error 28: Selected item cannot fit into memory
> 

Wish it said which one..

> [root@xen-02 xen-unstable]# ls -lh /boot/
> totale 247M
> -rw-r--r--. 1 root root 100K 24 ago 03:31 config-2.6.32-279.5.2.el6.x86_64
> -rw-r--r--. 1 root root 100K 22 giu 14:44 config-2.6.32-279.el6.x86_64
> -rw-r--r--. 1 root root 114K  9 set 02:09 config-3.1.0-rc9
> drwxr-xr-x. 3 root root 4,0K  9 set 00:16 efi
> drwxr-xr-x. 2 root root 4,0K  9 set 12:11 grub
> -rw-r--r--. 1 root root  23M  9 set 01:16
> initramfs-2.6.32-279.5.2.el6.x86_64.img
> -rw-r--r--. 1 root root  23M  9 set 00:17
> initramfs-2.6.32-279.el6.x86_64.img
> -rw-r--r--. 1 root root 154M  9 set 02:31 initramfs-3.1.0-rc9.img

This is pretty large? Any reason its so huge compared to the other ones?

And why not use v3.4 instead of v3.1?


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 10 19:38:42 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Sep 2012 19:38:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TB9oL-0000lH-VT; Mon, 10 Sep 2012 19:38:21 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ketuzsezr@gmail.com>) id 1TB9oK-0000lB-4z
	for xen-devel@lists.xen.org; Mon, 10 Sep 2012 19:38:20 +0000
Received: from [85.158.139.83:25219] by server-3.bemta-5.messagelabs.com id
	E9/C6-21836-9A14E405; Mon, 10 Sep 2012 19:38:17 +0000
X-Env-Sender: ketuzsezr@gmail.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1347305895!25799382!1
X-Originating-IP: [209.85.212.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16155 invoked from network); 10 Sep 2012 19:38:16 -0000
Received: from mail-vb0-f45.google.com (HELO mail-vb0-f45.google.com)
	(209.85.212.45)
	by server-6.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Sep 2012 19:38:16 -0000
Received: by vbip1 with SMTP id p1so3897660vbi.32
	for <xen-devel@lists.xen.org>; Mon, 10 Sep 2012 12:38:15 -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=VoLS42u0H66L/lvVh6UsbZcuIX7bUPetaxYSh0WyBh8=;
	b=PZUIlXTT3kEMc1bi3RgBrcl3VP3LjAADlHceF4QClPfFX+r9uA4Q2GS2NrX1hrWYcN
	b7OOZKFLl02o6rW7+3pIlKK1XbRJZ9pEs+Rcpwg+/Eb6TPg1fPhi0VI/0KOrlG+NF+cF
	EFAEyiQ8KHtDeQ8MqppmxtwHw1VyjaoNIdSM2LcqEHOHnuFPxkCs94ZHWsmcV1j8Xt5o
	dAgTDx/EDwAorheBfWXUsa2d/cBlnNNdA+jtYAaAtkW2hYYNE/im9SfGwNmRMqJWosXd
	1qzxI4/r5fI2lctM6Pae0iPNfxGfddn4Xu4JcA66bIwi7ip2aUQkZ0C8c7nyKEV2g4pS
	t1Jw==
Received: by 10.220.16.12 with SMTP id m12mr9892214vca.14.1347305894936;
	Mon, 10 Sep 2012 12:38:14 -0700 (PDT)
Received: from phenom.dumpdata.com
	(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 b6sm406550vea.2.2012.09.10.12.38.13
	(version=TLSv1/SSLv3 cipher=OTHER);
	Mon, 10 Sep 2012 12:38:14 -0700 (PDT)
Date: Mon, 10 Sep 2012 15:27:34 -0400
From: Konrad Rzeszutek Wilk <konrad@kernel.org>
To: bunkertor <bunkertor@tiscali.it>
Message-ID: <20120910192732.GB28298@phenom.dumpdata.com>
References: <504E10DA.6040603@tiscali.it>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <504E10DA.6040603@tiscali.it>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] grub error 28
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> 
>     GNU GRUB  version 0.97  (640K lower / 3072K upper memory)
> 
>  [ Minimal BASH-like line editing is supported.  For the first word, TAB
>    lists possible command completions.  Anywhere else TAB lists the
> possible
>    completions of a device/filename.]
> grub> root (hd0,0)
> root (hd0,0)
>  Filesystem type is ext2fs, partition type 0x83
> grub> kernel /xen.gz
> kernel /xen.gz
>    [Multiboot-elf, <0x964000:0x1a6db8:0x54248>(bad)
> 
> Error 28: Selected item cannot fit into memory
> 

Wish it said which one..

> [root@xen-02 xen-unstable]# ls -lh /boot/
> totale 247M
> -rw-r--r--. 1 root root 100K 24 ago 03:31 config-2.6.32-279.5.2.el6.x86_64
> -rw-r--r--. 1 root root 100K 22 giu 14:44 config-2.6.32-279.el6.x86_64
> -rw-r--r--. 1 root root 114K  9 set 02:09 config-3.1.0-rc9
> drwxr-xr-x. 3 root root 4,0K  9 set 00:16 efi
> drwxr-xr-x. 2 root root 4,0K  9 set 12:11 grub
> -rw-r--r--. 1 root root  23M  9 set 01:16
> initramfs-2.6.32-279.5.2.el6.x86_64.img
> -rw-r--r--. 1 root root  23M  9 set 00:17
> initramfs-2.6.32-279.el6.x86_64.img
> -rw-r--r--. 1 root root 154M  9 set 02:31 initramfs-3.1.0-rc9.img

This is pretty large? Any reason its so huge compared to the other ones?

And why not use v3.4 instead of v3.1?


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 10 19:45:43 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Sep 2012 19:45:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TB9v2-00010C-SI; Mon, 10 Sep 2012 19:45:16 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <daniel.lezcano@linaro.org>) id 1TB9v1-000107-BE
	for xen-devel@lists.xensource.com; Mon, 10 Sep 2012 19:45:15 +0000
Received: from [85.158.139.83:59656] by server-1.bemta-5.messagelabs.com id
	70/E1-32692-A434E405; Mon, 10 Sep 2012 19:45:14 +0000
X-Env-Sender: daniel.lezcano@linaro.org
X-Msg-Ref: server-10.tower-182.messagelabs.com!1347306311!29965963!1
X-Originating-IP: [74.125.83.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27273 invoked from network); 10 Sep 2012 19:45:12 -0000
Received: from mail-ee0-f43.google.com (HELO mail-ee0-f43.google.com)
	(74.125.83.43)
	by server-10.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Sep 2012 19:45:12 -0000
Received: by eekd4 with SMTP id d4so1488116eek.30
	for <xen-devel@lists.xensource.com>;
	Mon, 10 Sep 2012 12:45:11 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=message-id:date:from:user-agent:mime-version:to:cc:subject
	:references:in-reply-to:content-type:content-transfer-encoding
	:x-gm-message-state;
	bh=ON4EAVwJ6VpFu60O4W7hlkJWGUkhhupGh5RSySUuM1g=;
	b=TCOh+L5ioaVIS8IviZxru5t2zU4E2Ncro3bczLoDbsyKhSh3eqDYlMUe6s3vdwl00U
	nYUB1RuoQlLPICSE+q5ztpMDRlnx3mg8h6oAcOJ6Eft0kCDrj0FjJtc4eFPyYfIbgcn4
	dS0n8AABsKODWrrxLFCsV8xSMbyfu/0l4oGqSrDa8vHOZXPPZvlfvTs64quI9+3pwm3L
	XndH9x9JmrTLZOORjhIxcGEi8R71y5tTETT0fm21mFQ+3XdNsLleSp30WfTzW8gqNePa
	PXgNextMD3k8xtVZXUXDL+Xt4evf6niwx6phQdhXZJBc7V6Qtk1TVQWeKzq3+T/NCoxh
	+nAg==
Received: by 10.14.202.71 with SMTP id c47mr21590934eeo.42.1347306311038;
	Mon, 10 Sep 2012 12:45:11 -0700 (PDT)
Received: from [192.168.10.4] (AToulouse-651-1-192-218.w109-222.abo.wanadoo.fr.
	[109.222.127.218])
	by mx.google.com with ESMTPS id i8sm40837433eeo.16.2012.09.10.12.45.08
	(version=SSLv3 cipher=OTHER); Mon, 10 Sep 2012 12:45:10 -0700 (PDT)
Message-ID: <504E4343.5070004@linaro.org>
Date: Mon, 10 Sep 2012 21:45:07 +0200
From: Daniel Lezcano <daniel.lezcano@linaro.org>
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:12.0) Gecko/20120430 Thunderbird/12.0.1
MIME-Version: 1.0
To: John Stultz <john.stultz@linaro.org>
References: <1343164349-28550-1-git-send-email-daniel.lezcano@linaro.org>
	<201209062204.11288.rjw@sisk.pl> <50490920.9070204@linaro.org>
	<201209062318.42874.rjw@sisk.pl> <504A02BD.4000805@linaro.org>
	<504A2D73.3010702@linaro.org> <504A68A0.7010907@linaro.org>
	<504E1FE5.6090502@linaro.org>
In-Reply-To: <504E1FE5.6090502@linaro.org>
X-Gm-Message-State: ALoCoQljVlk56Gr0j2Ff1UhQAqaOywQNzRZnRVvjFP9wZHiQ5WqRvHXLItkYnch5Fu1cMRp9NVDx
Cc: prarit@redhat.com, xen-devel@lists.xensource.com,
	linaro-dev@lists.linaro.org, Peter Zijlstra <a.p.zijlstra@chello.nl>,
	linux-pm@vger.kernel.org, Frederic Weisbecker <fweisbec@gmail.com>,
	richardcochran@gmail.com, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	"Rafael J. Wysocki" <rjw@sisk.pl>, linux-acpi@vger.kernel.org,
	Thomas Gleixner <tglx@linutronix.de>, mingo@kernel.org, lenb@kernel.org
Subject: Re: [Xen-devel] CONFIG_NO_HZ + CONFIG_CPU_IDLE freeze the system
 (Was Re: [PATCH] acpi : remove power from acpi_processor_cx structure)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gMDkvMTAvMjAxMiAwNzoxNCBQTSwgSm9obiBTdHVsdHogd3JvdGU6Cj4gT24gMDkvMDcvMjAx
MiAwMjozNSBQTSwgRGFuaWVsIExlemNhbm8gd3JvdGU6Cj4+IE9uIDA5LzA3LzIwMTIgMDc6MjIg
UE0sIEpvaG4gU3R1bHR6IHdyb3RlOgo+Pj4gT24gMDkvMDcvMjAxMiAwNzoyMCBBTSwgRGFuaWVs
IExlemNhbm8gd3JvdGU6Cj4+Pj4gT24gMDkvMDYvMjAxMiAxMToxOCBQTSwgUmFmYWVsIEouIFd5
c29ja2kgd3JvdGU6Cj4+Pj4+IE9uIFRodXJzZGF5LCBTZXB0ZW1iZXIgMDYsIDIwMTIsIERhbmll
bCBMZXpjYW5vIHdyb3RlOgo+Pj4+Pj4gT24gMDkvMDYvMjAxMiAxMDowNCBQTSwgUmFmYWVsIEou
IFd5c29ja2kgd3JvdGU6Cj4+Pj4+Pj4gT24gVGh1cnNkYXksIFNlcHRlbWJlciAwNiwgMjAxMiwg
RGFuaWVsIExlemNhbm8gd3JvdGU6Cj4+Pj4+Pj4+IE9uIDA5LzA2LzIwMTIgMDk6NTQgQU0sIERh
bmllbCBMZXpjYW5vIHdyb3RlOgo+Pj4+Pj4+PiBJIGZhbGwgaW50byB0aGlzIGlzc3VlIGJlY2F1
c2UgTkVUQ09OU09MRSBpcyBzZXQsIGRpc2FibGluZyBpdAo+Pj4+Pj4+PiBhbGxvd2VkCj4+Pj4+
Pj4+IG1lIHRvIGdvIGZ1cnRoZXIuCj4+Pj4+Pj4+Cj4+Pj4+Pj4+IFVuZm9ydHVuYXRlbHkgSSBh
bSBmYWNpbmcgdG8gc29tZSByYW5kb20gZnJlZXplIG9uIHRoZSBzeXN0ZW0KPj4+Pj4+Pj4gd2hp
Y2gKPj4+Pj4+Pj4gc2VlbXMgdG8gYmUgcmVsYXRlZCB0byBDT05GSUdfTk9fSFo9eSBhbmQgQ09O
RklHX0NQVV9JRExFPXkuCj4+Pj4+Pj4+Cj4+Pj4+Pj4+IERpc2FibGluZyBvbmUgb2YgdGhlbSwg
bWFrZSB0aGUgZnJlZXplcyB0byBkaXNhcHBlYXIuCj4+Pj4+Pj4+Cj4+Pj4+Pj4+IElzIGl0IGEg
a25vd24gaXNzdWUgPwo+Pj4+Pj4+IFdlbGwsIHRoZXJlIGFyZSBzeXN0ZW1zIGhhdmluZyBwcm9i
bGVtcyB3aXRoIHRoaXMgY29uZmlndXJhdGlvbiwKPj4+Pj4+PiBidXQgdGhleQo+Pj4+Pj4+IHNo
b3VsZCBiZSBleGNlcHRpb25hbC4gV2hhdCBzeXN0ZW0gaXMgdGhhdD8KPj4+Pj4+IEl0IGlzIGEg
bGFwdG9wIFQ2MXAgd2l0aCBhIENvcmUgMiBEdW8gVDk1MDAuIE5vdGhpbmcgZXhjZXB0aW9uYWwg
SQo+Pj4+Pj4gYmVsaWV2ZS4gTWF5YmUgc29tZW9uZSBnb3QgdGhlIHNhbWUgaXNzdWUgPwo+Pj4+
PiBJcyBpdCBhIHJlZ3Jlc3Npb24gZm9yIHlvdT8KPj4+PiBZZXMsIEkgdGhpbmsgc28uIFRoZSBp
c3N1ZSBhcHBlYXJzIGJldHdlZW4gdjMuNSBhbmQgdjMuNi1yYzEuCj4+Pj4KPj4+PiBJdCBpcyBu
b3QgZWFzeSB0byByZXByb2R1Y2UgYnV0IGFmdGVyIHRha2luZyBzb21lIHRpbWUgdG8gZGlnLCBp
dAo+Pj4+IHNlZW1zCj4+Pj4gdG8gYXBwZWFyIHdpdGggdGhpcyBjb21taXQ6Cj4+Pj4KPj4+PiAx
ZTc1ZmE4YmU5ZmI2MWUxYWY0NmI1YjNiMTc2MzQ3YTRjOTU4Y2ExIGlzIHRoZSBmaXJzdCBiYWQg
Y29tbWl0Cj4+Pj4gY29tbWl0IDFlNzVmYThiZTlmYjYxZTFhZjQ2YjViM2IxNzYzNDdhNGM5NThj
YTEKPj4+PiBBdXRob3I6IEpvaG4gU3R1bHR6IDxqb2huLnN0dWx0ekBsaW5hcm8ub3JnPgo+Pj4+
IERhdGU6IEZyaSBKdWwgMTMgMDE6MjE6NTMgMjAxMiAtMDQwMAo+Pj4+Cj4+Pj4gdGltZTogQ29u
ZGVuc2UgdGltZWtlZXBlci54dGltZSBpbnRvIHh0aW1lX3NlYwo+Pj4+Cj4+Pj4gVGhlIHRpbWVr
ZWVwZXIgc3RydWN0IGhhcyBhIHh0aW1lX25zZWMsIHdoaWNoIGtlZXBzIHRoZQo+Pj4+IHN1Yi1u
YW5vc2Vjb25kIHJlbWFpbmRlci4gVGhpcyBlbmRzIHVwIGJlaW5nIHNvbWV3aGF0Cj4+Pj4gZHVw
bGljYXRpdmUgb2YgdGhlIHRpbWVrZWVwZXIueHRpbWUudHZfbnNlYyB2YWx1ZSwgYW5kIHdlCj4+
Pj4gaGF2ZSB0byBkbyBleHRyYSB3b3JrIHRvIGtlZXAgdGhlbSBhcGFydCwgY29weWluZyB0aGUg
ZnVsbAo+Pj4+IG5zZWMgcG9ydGlvbiBvdXQgYW5kIGJhY2sgaW4gb3ZlciBhbmQgb3Zlci4KPj4+
Pgo+Pj4+IFRoaXMgcGF0Y2ggc2ltcGxpZmllcyBzb21lIG9mIHRoZSBsb2dpYyBieSB0YWtpbmcg
dGhlIHRpbWVrZWVwZXIKPj4+PiB4dGltZSB2YWx1ZSBhbmQgc3BsaXR0aW5nIGl0IGludG8gdGlt
ZWtlZXBlci54dGltZV9zZWMgYW5kCj4+Pj4gcmV1c2VzIHRoZSB0aW1la2VlcGVyLnh0aW1lX25z
ZWMgZm9yIHRoZSBzdWItc2Vjb25kIHBvcnRpb24KPj4+PiAoc3RvcmVkIGluIGhpZ2hlciByZXMg
c2hpZnRlZCBuYW5vc2Vjb25kcykuCj4+Pj4KPj4+PiBUaGlzIHNpbXBsaWZpZXMgc29tZSBvZiB0
aGUgYWNjdW11bGF0aW9uIGxvZ2ljLiBBbmQgd2lsbAo+Pj4+IGFsbG93IGZvciBtb3JlIGFjY3Vy
YXRlIHRpbWVrZWVwaW5nIG9uY2UgdGhlIHZzeXNjYWxsIGNvZGUKPj4+PiBpcyB1cGRhdGVkIHRv
IHVzZSB0aGUgc2hpZnRlZCBuYW5vc2Vjb25kIHJlbWFpbmRlci4KPj4+Pgo+Pj4+IFNpZ25lZC1v
ZmYtYnk6IEpvaG4gU3R1bHR6IDxqb2huLnN0dWx0ekBsaW5hcm8ub3JnPgo+Pj4+IFJldmlld2Vk
LWJ5OiBJbmdvIE1vbG5hciA8bWluZ29Aa2VybmVsLm9yZz4KPj4+PiBDYzogUGV0ZXIgWmlqbHN0
cmEgPGEucC56aWpsc3RyYUBjaGVsbG8ubmw+Cj4+Pj4gQ2M6IFJpY2hhcmQgQ29jaHJhbiA8cmlj
aGFyZGNvY2hyYW5AZ21haWwuY29tPgo+Pj4+IENjOiBQcmFyaXQgQmhhcmdhdmEgPHByYXJpdEBy
ZWRoYXQuY29tPgo+Pj4+IExpbms6Cj4+Pj4gaHR0cDovL2xrbWwua2VybmVsLm9yZy9yLzEzNDIx
NTY5MTctMjUwOTItNS1naXQtc2VuZC1lbWFpbC1qb2huLnN0dWx0ekBsaW5hcm8ub3JnCj4+Pj4K
Pj4+Pgo+Pj4+IFNpZ25lZC1vZmYtYnk6IFRob21hcyBHbGVpeG5lciA8dGdseEBsaW51dHJvbml4
LmRlPgo+Pj4+Cj4+Pj4gOjA0MDAwMCAwNDAwMDAgNGQ2NTQxYWMxZjYwNzVkN2FkZWUxZWVmNDk0
YjMxYTBjYmRhMDkzNAo+Pj4+IGRjNTcwOGJjNzM4YWY2OTVmMDkyYmY4MjI4MDliMTNhMWRhMTA0
YjYgTSBrZXJuZWwKPj4+Pgo+Pj4+IEhvdyB0byByZXByb2R1Y2U6IHdpdGggYSBsYXB0b3AgVDYx
cCwgd2l0aCBhIENvcmUgMiBEdW8uIEkgYm9vdCB0aGUKPj4+PiBrZXJuZWwgaW4gYnVzeWJveCBh
bmQgd2FpdCBzb21lIG1pbnV0ZXMgYmVmb3JlIHdyaXRpbmcgc29tZXRoaW5nIGluCj4+Pj4gdGhl
Cj4+Pj4gY29uc29sZS4gQXQgdGhpcyBtb21lbnQsIG5vdGhpbmcgYXBwZWFycyB0byB0aGUgY29u
c29sZSBidXQgdGhlCj4+Pj4gY2hhcmFjdGVycyBhcmUgZWNobydlZCBzZXZlcmFsIHNlY29uZHMg
bGF0ZXIgKGNvdWxkIGJlIDEsIDUsIG9yIDEwCj4+Pj4gc2Vjcwo+Pj4+IG9yIG1vcmUpLgo+Pj4+
Cj4+Pj4gVGhhdCBoYXBwZW5zIHdoZW4gQ09ORklHX0NQVV9JRExFIGFuZCBDT05GSUdfTk9fSFog
YXJlIHNldC4gRGlzYWJsaW5nCj4+Pj4gb25lIG9mIHRoZW0sIHRoZSBpc3N1ZSBkb2VzIG5vdCBh
cHBlYXIuCj4+PiBUaGFua3MgZm9yIGJpc2VjdGluZyB0aGlzIGRvd24gYW5kIHRoZSBoZWFkcyB1
cCEKPj4+Cj4+PiBSaWdodCBvZmYgSSBjYW4ndCBzZWUgd2hhdCBtaWdodCBiZSBjYXVzaW5nIHRo
aXMuIEJ1bmNoIG9mIHF1ZXN0aW9uczoKPj4+Cj4+PiBJcyB0aGlzIGEgMzIgb3IgNjQgYml0IGtl
cm5lbD8KPj4gSXQgaXMgYSAzMiBiaXQga2VybmVsLgo+Cj4gVGhhbmtzIGZvciB5b3VyIGFuc3dl
cnMhIEhhcyB0aGlzIGhhcyBiZWVuIHNlZW4gb24gMy42LXJjNCsga2VybmVscz8KPiBUaGVyZSB3
ZXJlIGEgZmV3IGNhc3RpbmcgZml4ZXMgdGhhdCBsYW5kZWQgaW4gMy42LXJjNCB0aGF0IHdvdWxk
Cj4gYWZmZWN0IDMyYml0IHN5c3RlbXMuCgpPaywgSSBoYXZlIHRvIGNoZWNrIHRoYXQuIFVuZm9y
dHVuYXRlbHkgbm90IGJlZm9yZSBXZWRuZXNkYXkuCgo+Cj4gSW4gdGhlIG1lYW50aW1lLCBJJ2xs
IHRyeSB0byByZXByb2R1Y2Ugb24gbXkgVDYxLiBJZiB5b3UgY291bGQgc2VuZCBtZQo+IHlvdXIg
LmNvbmZpZywgSSdkIGFwcHJlY2lhdGUgaXQuCgpodHRwOi8vcGFzdGViaW4uY29tL3FTeHFmZERL
CgpUaGUgaGVhZGVyIG9mIHRoZSBjb25maWcgZmlsZSBzaG93cyBmb3IgYSB2My41LXJjNyBiZWNh
dXNlIGl0IGlzIHRoZQpyZXN1bHQgb2YgdGhlIGdpdC1iaXNlY3QuIElmIHlvdSBrZWVwIHRoaXMg
Y29uZmlnIGZpbGUgZm9yIHRoZSBsYXRlc3QKa2VybmVsIHRoYXQgc2hvdWxkIHJlcHJvZHVjZSB0
aGUgcHJvYmxlbS4KCkxldCBtZSBrbm93IGlmIHlvdSB3ZXJlIGFibGUgdG8gcmVwcm9kdWNlIHRo
ZSBwcm9ibGVtLgoKVGhhbmtzCi0tIERhbmllbAoKLS0gCiA8aHR0cDovL3d3dy5saW5hcm8ub3Jn
Lz4gTGluYXJvLm9yZyDilIIgT3BlbiBzb3VyY2Ugc29mdHdhcmUgZm9yIEFSTSBTb0NzCgpGb2xs
b3cgTGluYXJvOiAgPGh0dHA6Ly93d3cuZmFjZWJvb2suY29tL3BhZ2VzL0xpbmFybz4gRmFjZWJv
b2sgfAo8aHR0cDovL3R3aXR0ZXIuY29tLyMhL2xpbmFyb29yZz4gVHdpdHRlciB8CjxodHRwOi8v
d3d3LmxpbmFyby5vcmcvbGluYXJvLWJsb2cvPiBCbG9nCgoKCl9fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRl
dmVsQGxpc3RzLnhlbi5vcmcKaHR0cDovL2xpc3RzLnhlbi5vcmcveGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Mon Sep 10 19:45:43 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Sep 2012 19:45:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TB9v2-00010C-SI; Mon, 10 Sep 2012 19:45:16 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <daniel.lezcano@linaro.org>) id 1TB9v1-000107-BE
	for xen-devel@lists.xensource.com; Mon, 10 Sep 2012 19:45:15 +0000
Received: from [85.158.139.83:59656] by server-1.bemta-5.messagelabs.com id
	70/E1-32692-A434E405; Mon, 10 Sep 2012 19:45:14 +0000
X-Env-Sender: daniel.lezcano@linaro.org
X-Msg-Ref: server-10.tower-182.messagelabs.com!1347306311!29965963!1
X-Originating-IP: [74.125.83.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27273 invoked from network); 10 Sep 2012 19:45:12 -0000
Received: from mail-ee0-f43.google.com (HELO mail-ee0-f43.google.com)
	(74.125.83.43)
	by server-10.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Sep 2012 19:45:12 -0000
Received: by eekd4 with SMTP id d4so1488116eek.30
	for <xen-devel@lists.xensource.com>;
	Mon, 10 Sep 2012 12:45:11 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=message-id:date:from:user-agent:mime-version:to:cc:subject
	:references:in-reply-to:content-type:content-transfer-encoding
	:x-gm-message-state;
	bh=ON4EAVwJ6VpFu60O4W7hlkJWGUkhhupGh5RSySUuM1g=;
	b=TCOh+L5ioaVIS8IviZxru5t2zU4E2Ncro3bczLoDbsyKhSh3eqDYlMUe6s3vdwl00U
	nYUB1RuoQlLPICSE+q5ztpMDRlnx3mg8h6oAcOJ6Eft0kCDrj0FjJtc4eFPyYfIbgcn4
	dS0n8AABsKODWrrxLFCsV8xSMbyfu/0l4oGqSrDa8vHOZXPPZvlfvTs64quI9+3pwm3L
	XndH9x9JmrTLZOORjhIxcGEi8R71y5tTETT0fm21mFQ+3XdNsLleSp30WfTzW8gqNePa
	PXgNextMD3k8xtVZXUXDL+Xt4evf6niwx6phQdhXZJBc7V6Qtk1TVQWeKzq3+T/NCoxh
	+nAg==
Received: by 10.14.202.71 with SMTP id c47mr21590934eeo.42.1347306311038;
	Mon, 10 Sep 2012 12:45:11 -0700 (PDT)
Received: from [192.168.10.4] (AToulouse-651-1-192-218.w109-222.abo.wanadoo.fr.
	[109.222.127.218])
	by mx.google.com with ESMTPS id i8sm40837433eeo.16.2012.09.10.12.45.08
	(version=SSLv3 cipher=OTHER); Mon, 10 Sep 2012 12:45:10 -0700 (PDT)
Message-ID: <504E4343.5070004@linaro.org>
Date: Mon, 10 Sep 2012 21:45:07 +0200
From: Daniel Lezcano <daniel.lezcano@linaro.org>
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:12.0) Gecko/20120430 Thunderbird/12.0.1
MIME-Version: 1.0
To: John Stultz <john.stultz@linaro.org>
References: <1343164349-28550-1-git-send-email-daniel.lezcano@linaro.org>
	<201209062204.11288.rjw@sisk.pl> <50490920.9070204@linaro.org>
	<201209062318.42874.rjw@sisk.pl> <504A02BD.4000805@linaro.org>
	<504A2D73.3010702@linaro.org> <504A68A0.7010907@linaro.org>
	<504E1FE5.6090502@linaro.org>
In-Reply-To: <504E1FE5.6090502@linaro.org>
X-Gm-Message-State: ALoCoQljVlk56Gr0j2Ff1UhQAqaOywQNzRZnRVvjFP9wZHiQ5WqRvHXLItkYnch5Fu1cMRp9NVDx
Cc: prarit@redhat.com, xen-devel@lists.xensource.com,
	linaro-dev@lists.linaro.org, Peter Zijlstra <a.p.zijlstra@chello.nl>,
	linux-pm@vger.kernel.org, Frederic Weisbecker <fweisbec@gmail.com>,
	richardcochran@gmail.com, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	"Rafael J. Wysocki" <rjw@sisk.pl>, linux-acpi@vger.kernel.org,
	Thomas Gleixner <tglx@linutronix.de>, mingo@kernel.org, lenb@kernel.org
Subject: Re: [Xen-devel] CONFIG_NO_HZ + CONFIG_CPU_IDLE freeze the system
 (Was Re: [PATCH] acpi : remove power from acpi_processor_cx structure)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gMDkvMTAvMjAxMiAwNzoxNCBQTSwgSm9obiBTdHVsdHogd3JvdGU6Cj4gT24gMDkvMDcvMjAx
MiAwMjozNSBQTSwgRGFuaWVsIExlemNhbm8gd3JvdGU6Cj4+IE9uIDA5LzA3LzIwMTIgMDc6MjIg
UE0sIEpvaG4gU3R1bHR6IHdyb3RlOgo+Pj4gT24gMDkvMDcvMjAxMiAwNzoyMCBBTSwgRGFuaWVs
IExlemNhbm8gd3JvdGU6Cj4+Pj4gT24gMDkvMDYvMjAxMiAxMToxOCBQTSwgUmFmYWVsIEouIFd5
c29ja2kgd3JvdGU6Cj4+Pj4+IE9uIFRodXJzZGF5LCBTZXB0ZW1iZXIgMDYsIDIwMTIsIERhbmll
bCBMZXpjYW5vIHdyb3RlOgo+Pj4+Pj4gT24gMDkvMDYvMjAxMiAxMDowNCBQTSwgUmFmYWVsIEou
IFd5c29ja2kgd3JvdGU6Cj4+Pj4+Pj4gT24gVGh1cnNkYXksIFNlcHRlbWJlciAwNiwgMjAxMiwg
RGFuaWVsIExlemNhbm8gd3JvdGU6Cj4+Pj4+Pj4+IE9uIDA5LzA2LzIwMTIgMDk6NTQgQU0sIERh
bmllbCBMZXpjYW5vIHdyb3RlOgo+Pj4+Pj4+PiBJIGZhbGwgaW50byB0aGlzIGlzc3VlIGJlY2F1
c2UgTkVUQ09OU09MRSBpcyBzZXQsIGRpc2FibGluZyBpdAo+Pj4+Pj4+PiBhbGxvd2VkCj4+Pj4+
Pj4+IG1lIHRvIGdvIGZ1cnRoZXIuCj4+Pj4+Pj4+Cj4+Pj4+Pj4+IFVuZm9ydHVuYXRlbHkgSSBh
bSBmYWNpbmcgdG8gc29tZSByYW5kb20gZnJlZXplIG9uIHRoZSBzeXN0ZW0KPj4+Pj4+Pj4gd2hp
Y2gKPj4+Pj4+Pj4gc2VlbXMgdG8gYmUgcmVsYXRlZCB0byBDT05GSUdfTk9fSFo9eSBhbmQgQ09O
RklHX0NQVV9JRExFPXkuCj4+Pj4+Pj4+Cj4+Pj4+Pj4+IERpc2FibGluZyBvbmUgb2YgdGhlbSwg
bWFrZSB0aGUgZnJlZXplcyB0byBkaXNhcHBlYXIuCj4+Pj4+Pj4+Cj4+Pj4+Pj4+IElzIGl0IGEg
a25vd24gaXNzdWUgPwo+Pj4+Pj4+IFdlbGwsIHRoZXJlIGFyZSBzeXN0ZW1zIGhhdmluZyBwcm9i
bGVtcyB3aXRoIHRoaXMgY29uZmlndXJhdGlvbiwKPj4+Pj4+PiBidXQgdGhleQo+Pj4+Pj4+IHNo
b3VsZCBiZSBleGNlcHRpb25hbC4gV2hhdCBzeXN0ZW0gaXMgdGhhdD8KPj4+Pj4+IEl0IGlzIGEg
bGFwdG9wIFQ2MXAgd2l0aCBhIENvcmUgMiBEdW8gVDk1MDAuIE5vdGhpbmcgZXhjZXB0aW9uYWwg
SQo+Pj4+Pj4gYmVsaWV2ZS4gTWF5YmUgc29tZW9uZSBnb3QgdGhlIHNhbWUgaXNzdWUgPwo+Pj4+
PiBJcyBpdCBhIHJlZ3Jlc3Npb24gZm9yIHlvdT8KPj4+PiBZZXMsIEkgdGhpbmsgc28uIFRoZSBp
c3N1ZSBhcHBlYXJzIGJldHdlZW4gdjMuNSBhbmQgdjMuNi1yYzEuCj4+Pj4KPj4+PiBJdCBpcyBu
b3QgZWFzeSB0byByZXByb2R1Y2UgYnV0IGFmdGVyIHRha2luZyBzb21lIHRpbWUgdG8gZGlnLCBp
dAo+Pj4+IHNlZW1zCj4+Pj4gdG8gYXBwZWFyIHdpdGggdGhpcyBjb21taXQ6Cj4+Pj4KPj4+PiAx
ZTc1ZmE4YmU5ZmI2MWUxYWY0NmI1YjNiMTc2MzQ3YTRjOTU4Y2ExIGlzIHRoZSBmaXJzdCBiYWQg
Y29tbWl0Cj4+Pj4gY29tbWl0IDFlNzVmYThiZTlmYjYxZTFhZjQ2YjViM2IxNzYzNDdhNGM5NThj
YTEKPj4+PiBBdXRob3I6IEpvaG4gU3R1bHR6IDxqb2huLnN0dWx0ekBsaW5hcm8ub3JnPgo+Pj4+
IERhdGU6IEZyaSBKdWwgMTMgMDE6MjE6NTMgMjAxMiAtMDQwMAo+Pj4+Cj4+Pj4gdGltZTogQ29u
ZGVuc2UgdGltZWtlZXBlci54dGltZSBpbnRvIHh0aW1lX3NlYwo+Pj4+Cj4+Pj4gVGhlIHRpbWVr
ZWVwZXIgc3RydWN0IGhhcyBhIHh0aW1lX25zZWMsIHdoaWNoIGtlZXBzIHRoZQo+Pj4+IHN1Yi1u
YW5vc2Vjb25kIHJlbWFpbmRlci4gVGhpcyBlbmRzIHVwIGJlaW5nIHNvbWV3aGF0Cj4+Pj4gZHVw
bGljYXRpdmUgb2YgdGhlIHRpbWVrZWVwZXIueHRpbWUudHZfbnNlYyB2YWx1ZSwgYW5kIHdlCj4+
Pj4gaGF2ZSB0byBkbyBleHRyYSB3b3JrIHRvIGtlZXAgdGhlbSBhcGFydCwgY29weWluZyB0aGUg
ZnVsbAo+Pj4+IG5zZWMgcG9ydGlvbiBvdXQgYW5kIGJhY2sgaW4gb3ZlciBhbmQgb3Zlci4KPj4+
Pgo+Pj4+IFRoaXMgcGF0Y2ggc2ltcGxpZmllcyBzb21lIG9mIHRoZSBsb2dpYyBieSB0YWtpbmcg
dGhlIHRpbWVrZWVwZXIKPj4+PiB4dGltZSB2YWx1ZSBhbmQgc3BsaXR0aW5nIGl0IGludG8gdGlt
ZWtlZXBlci54dGltZV9zZWMgYW5kCj4+Pj4gcmV1c2VzIHRoZSB0aW1la2VlcGVyLnh0aW1lX25z
ZWMgZm9yIHRoZSBzdWItc2Vjb25kIHBvcnRpb24KPj4+PiAoc3RvcmVkIGluIGhpZ2hlciByZXMg
c2hpZnRlZCBuYW5vc2Vjb25kcykuCj4+Pj4KPj4+PiBUaGlzIHNpbXBsaWZpZXMgc29tZSBvZiB0
aGUgYWNjdW11bGF0aW9uIGxvZ2ljLiBBbmQgd2lsbAo+Pj4+IGFsbG93IGZvciBtb3JlIGFjY3Vy
YXRlIHRpbWVrZWVwaW5nIG9uY2UgdGhlIHZzeXNjYWxsIGNvZGUKPj4+PiBpcyB1cGRhdGVkIHRv
IHVzZSB0aGUgc2hpZnRlZCBuYW5vc2Vjb25kIHJlbWFpbmRlci4KPj4+Pgo+Pj4+IFNpZ25lZC1v
ZmYtYnk6IEpvaG4gU3R1bHR6IDxqb2huLnN0dWx0ekBsaW5hcm8ub3JnPgo+Pj4+IFJldmlld2Vk
LWJ5OiBJbmdvIE1vbG5hciA8bWluZ29Aa2VybmVsLm9yZz4KPj4+PiBDYzogUGV0ZXIgWmlqbHN0
cmEgPGEucC56aWpsc3RyYUBjaGVsbG8ubmw+Cj4+Pj4gQ2M6IFJpY2hhcmQgQ29jaHJhbiA8cmlj
aGFyZGNvY2hyYW5AZ21haWwuY29tPgo+Pj4+IENjOiBQcmFyaXQgQmhhcmdhdmEgPHByYXJpdEBy
ZWRoYXQuY29tPgo+Pj4+IExpbms6Cj4+Pj4gaHR0cDovL2xrbWwua2VybmVsLm9yZy9yLzEzNDIx
NTY5MTctMjUwOTItNS1naXQtc2VuZC1lbWFpbC1qb2huLnN0dWx0ekBsaW5hcm8ub3JnCj4+Pj4K
Pj4+Pgo+Pj4+IFNpZ25lZC1vZmYtYnk6IFRob21hcyBHbGVpeG5lciA8dGdseEBsaW51dHJvbml4
LmRlPgo+Pj4+Cj4+Pj4gOjA0MDAwMCAwNDAwMDAgNGQ2NTQxYWMxZjYwNzVkN2FkZWUxZWVmNDk0
YjMxYTBjYmRhMDkzNAo+Pj4+IGRjNTcwOGJjNzM4YWY2OTVmMDkyYmY4MjI4MDliMTNhMWRhMTA0
YjYgTSBrZXJuZWwKPj4+Pgo+Pj4+IEhvdyB0byByZXByb2R1Y2U6IHdpdGggYSBsYXB0b3AgVDYx
cCwgd2l0aCBhIENvcmUgMiBEdW8uIEkgYm9vdCB0aGUKPj4+PiBrZXJuZWwgaW4gYnVzeWJveCBh
bmQgd2FpdCBzb21lIG1pbnV0ZXMgYmVmb3JlIHdyaXRpbmcgc29tZXRoaW5nIGluCj4+Pj4gdGhl
Cj4+Pj4gY29uc29sZS4gQXQgdGhpcyBtb21lbnQsIG5vdGhpbmcgYXBwZWFycyB0byB0aGUgY29u
c29sZSBidXQgdGhlCj4+Pj4gY2hhcmFjdGVycyBhcmUgZWNobydlZCBzZXZlcmFsIHNlY29uZHMg
bGF0ZXIgKGNvdWxkIGJlIDEsIDUsIG9yIDEwCj4+Pj4gc2Vjcwo+Pj4+IG9yIG1vcmUpLgo+Pj4+
Cj4+Pj4gVGhhdCBoYXBwZW5zIHdoZW4gQ09ORklHX0NQVV9JRExFIGFuZCBDT05GSUdfTk9fSFog
YXJlIHNldC4gRGlzYWJsaW5nCj4+Pj4gb25lIG9mIHRoZW0sIHRoZSBpc3N1ZSBkb2VzIG5vdCBh
cHBlYXIuCj4+PiBUaGFua3MgZm9yIGJpc2VjdGluZyB0aGlzIGRvd24gYW5kIHRoZSBoZWFkcyB1
cCEKPj4+Cj4+PiBSaWdodCBvZmYgSSBjYW4ndCBzZWUgd2hhdCBtaWdodCBiZSBjYXVzaW5nIHRo
aXMuIEJ1bmNoIG9mIHF1ZXN0aW9uczoKPj4+Cj4+PiBJcyB0aGlzIGEgMzIgb3IgNjQgYml0IGtl
cm5lbD8KPj4gSXQgaXMgYSAzMiBiaXQga2VybmVsLgo+Cj4gVGhhbmtzIGZvciB5b3VyIGFuc3dl
cnMhIEhhcyB0aGlzIGhhcyBiZWVuIHNlZW4gb24gMy42LXJjNCsga2VybmVscz8KPiBUaGVyZSB3
ZXJlIGEgZmV3IGNhc3RpbmcgZml4ZXMgdGhhdCBsYW5kZWQgaW4gMy42LXJjNCB0aGF0IHdvdWxk
Cj4gYWZmZWN0IDMyYml0IHN5c3RlbXMuCgpPaywgSSBoYXZlIHRvIGNoZWNrIHRoYXQuIFVuZm9y
dHVuYXRlbHkgbm90IGJlZm9yZSBXZWRuZXNkYXkuCgo+Cj4gSW4gdGhlIG1lYW50aW1lLCBJJ2xs
IHRyeSB0byByZXByb2R1Y2Ugb24gbXkgVDYxLiBJZiB5b3UgY291bGQgc2VuZCBtZQo+IHlvdXIg
LmNvbmZpZywgSSdkIGFwcHJlY2lhdGUgaXQuCgpodHRwOi8vcGFzdGViaW4uY29tL3FTeHFmZERL
CgpUaGUgaGVhZGVyIG9mIHRoZSBjb25maWcgZmlsZSBzaG93cyBmb3IgYSB2My41LXJjNyBiZWNh
dXNlIGl0IGlzIHRoZQpyZXN1bHQgb2YgdGhlIGdpdC1iaXNlY3QuIElmIHlvdSBrZWVwIHRoaXMg
Y29uZmlnIGZpbGUgZm9yIHRoZSBsYXRlc3QKa2VybmVsIHRoYXQgc2hvdWxkIHJlcHJvZHVjZSB0
aGUgcHJvYmxlbS4KCkxldCBtZSBrbm93IGlmIHlvdSB3ZXJlIGFibGUgdG8gcmVwcm9kdWNlIHRo
ZSBwcm9ibGVtLgoKVGhhbmtzCi0tIERhbmllbAoKLS0gCiA8aHR0cDovL3d3dy5saW5hcm8ub3Jn
Lz4gTGluYXJvLm9yZyDilIIgT3BlbiBzb3VyY2Ugc29mdHdhcmUgZm9yIEFSTSBTb0NzCgpGb2xs
b3cgTGluYXJvOiAgPGh0dHA6Ly93d3cuZmFjZWJvb2suY29tL3BhZ2VzL0xpbmFybz4gRmFjZWJv
b2sgfAo8aHR0cDovL3R3aXR0ZXIuY29tLyMhL2xpbmFyb29yZz4gVHdpdHRlciB8CjxodHRwOi8v
d3d3LmxpbmFyby5vcmcvbGluYXJvLWJsb2cvPiBCbG9nCgoKCl9fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRl
dmVsQGxpc3RzLnhlbi5vcmcKaHR0cDovL2xpc3RzLnhlbi5vcmcveGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Mon Sep 10 19:49:56 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Sep 2012 19:49:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TB9zO-0001Db-G2; Mon, 10 Sep 2012 19:49:46 +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 1TB9zM-00019X-6h
	for xen-devel@lists.xen.org; Mon, 10 Sep 2012 19:49:44 +0000
Received: from [85.158.143.99:27987] by server-3.bemta-4.messagelabs.com id
	98/D7-08232-7544E405; Mon, 10 Sep 2012 19:49:43 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-16.tower-216.messagelabs.com!1347306581!18372732!1
X-Originating-IP: [63.239.67.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10118 invoked from network); 10 Sep 2012 19:49:42 -0000
Received: from emvm-gh1-uea09.nsa.gov (HELO nsa.gov) (63.239.67.10)
	by server-16.tower-216.messagelabs.com with SMTP;
	10 Sep 2012 19:49:42 -0000
X-TM-IMSS-Message-ID: <3066d337000f2263@nsa.gov>
Received: from tarius.tycho.ncsc.mil ([144.51.3.1]) by nsa.gov
	([63.239.67.10]) with ESMTP (TREND IMSS SMTP Service 7.1) id
	3066d337000f2263 ; Mon, 10 Sep 2012 15:51: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 q8AJna3o027796; 
	Mon, 10 Sep 2012 15:49:40 -0400
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xen.org
Date: Mon, 10 Sep 2012 15:49:05 -0400
Message-Id: <1347306553-20980-13-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.11.4
In-Reply-To: <1347306553-20980-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1347306553-20980-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>, Keir Fraser <keir@xen.org>,
	Jan Beulich <jbeulich@suse.com>
Subject: [Xen-devel] [PATCH 12/20] xen: avoid calling
	rcu_lock_*target_domain when an XSM hook 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>
MIME-Version: 1.0
Content-Type: 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 rcu_lock_{,remote_}target_domain_by_id functions are wrappers around
an IS_PRIV_FOR check for the current domain. This is now redundant with
XSM hooks, so replace these calls with rcu_lock_domain_by_any_id or
rcu_lock_remote_domain_by_id to remove the duplicate permission checks.

When XSM_ENABLE is not defined or when the dummy XSM module is used,
this patch should not change any functionality. Because the locations of
privilege checks have sometimes moved below argument validation, error
returns of some functions may change from EPERM to EINVAL when called
with invalid arguments and from a domain without permission to perform
the operation.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Cc: Keir Fraser <keir@xen.org>
Cc: Jan Beulich <jbeulich@suse.com>
---
 xen/arch/x86/hvm/hvm.c     | 38 +++++++++++++++----------------
 xen/arch/x86/mm.c          | 22 ++++++++----------
 xen/common/event_channel.c | 18 +++++++--------
 xen/common/grant_table.c   | 57 +++++++++++++++-------------------------------
 xen/common/memory.c        | 15 ++++++------
 5 files changed, 63 insertions(+), 87 deletions(-)

diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 0576a24..e737671 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -3375,7 +3375,7 @@ static int hvmop_set_pci_intx_level(
     if ( (op.domain > 0) || (op.bus > 0) || (op.device > 31) || (op.intx > 3) )
         return -EINVAL;
 
-    rc = rcu_lock_remote_target_domain_by_id(op.domid, &d);
+    rc = rcu_lock_remote_domain_by_id(op.domid, &d);
     if ( rc != 0 )
         return rc;
 
@@ -3540,7 +3540,7 @@ static int hvmop_set_isa_irq_level(
     if ( op.isa_irq > 15 )
         return -EINVAL;
 
-    rc = rcu_lock_remote_target_domain_by_id(op.domid, &d);
+    rc = rcu_lock_remote_domain_by_id(op.domid, &d);
     if ( rc != 0 )
         return rc;
 
@@ -3584,7 +3584,7 @@ static int hvmop_set_pci_link_route(
     if ( (op.link > 3) || (op.isa_irq > 15) )
         return -EINVAL;
 
-    rc = rcu_lock_remote_target_domain_by_id(op.domid, &d);
+    rc = rcu_lock_remote_domain_by_id(op.domid, &d);
     if ( rc != 0 )
         return rc;
 
@@ -3614,7 +3614,7 @@ static int hvmop_inject_msi(
     if ( copy_from_guest(&op, uop, 1) )
         return -EFAULT;
 
-    rc = rcu_lock_remote_target_domain_by_id(op.domid, &d);
+    rc = rcu_lock_remote_domain_by_id(op.domid, &d);
     if ( rc != 0 )
         return rc;
 
@@ -3711,9 +3711,9 @@ long do_hvm_op(unsigned long op, XEN_GUEST_HANDLE(void) arg)
         if ( a.index >= HVM_NR_PARAMS )
             return -EINVAL;
 
-        rc = rcu_lock_target_domain_by_id(a.domid, &d);
-        if ( rc != 0 )
-            return rc;
+        d = rcu_lock_domain_by_any_id(a.domid);
+        if ( d == NULL )
+            return -ESRCH;
 
         rc = -EINVAL;
         if ( !is_hvm_domain(d) )
@@ -3957,7 +3957,7 @@ long do_hvm_op(unsigned long op, XEN_GUEST_HANDLE(void) arg)
         if ( copy_from_guest(&a, arg, 1) )
             return -EFAULT;
 
-        rc = rcu_lock_remote_target_domain_by_id(a.domid, &d);
+        rc = rcu_lock_remote_domain_by_id(a.domid, &d);
         if ( rc != 0 )
             return rc;
 
@@ -3996,7 +3996,7 @@ long do_hvm_op(unsigned long op, XEN_GUEST_HANDLE(void) arg)
         if ( copy_from_guest(&a, arg, 1) )
             return -EFAULT;
 
-        rc = rcu_lock_remote_target_domain_by_id(a.domid, &d);
+        rc = rcu_lock_remote_domain_by_id(a.domid, &d);
         if ( rc != 0 )
             return rc;
 
@@ -4046,9 +4046,9 @@ long do_hvm_op(unsigned long op, XEN_GUEST_HANDLE(void) arg)
         if ( copy_from_guest(&a, arg, 1) )
             return -EFAULT;
 
-        rc = rcu_lock_target_domain_by_id(a.domid, &d);
-        if ( rc != 0 )
-            return rc;
+        d = rcu_lock_domain_by_any_id(a.domid);
+        if ( d == NULL )
+            return -ESRCH;
 
         rc = xsm_hvm_param(d, op);
         if ( rc )
@@ -4093,7 +4093,7 @@ long do_hvm_op(unsigned long op, XEN_GUEST_HANDLE(void) arg)
         if ( copy_from_guest(&a, arg, 1) )
             return -EFAULT;
 
-        rc = rcu_lock_remote_target_domain_by_id(a.domid, &d);
+        rc = rcu_lock_remote_domain_by_id(a.domid, &d);
         if ( rc != 0 )
             return rc;
 
@@ -4172,7 +4172,7 @@ long do_hvm_op(unsigned long op, XEN_GUEST_HANDLE(void) arg)
         if ( copy_from_guest(&a, arg, 1) )
             return -EFAULT;
 
-        rc = rcu_lock_remote_target_domain_by_id(a.domid, &d);
+        rc = rcu_lock_remote_domain_by_id(a.domid, &d);
         if ( rc != 0 )
             return rc;
 
@@ -4207,7 +4207,7 @@ long do_hvm_op(unsigned long op, XEN_GUEST_HANDLE(void) arg)
         if ( copy_from_guest(&a, arg, 1) )
             return -EFAULT;
 
-        rc = rcu_lock_remote_target_domain_by_id(a.domid, &d);
+        rc = rcu_lock_remote_domain_by_id(a.domid, &d);
         if ( rc != 0 )
             return rc;
 
@@ -4243,9 +4243,9 @@ long do_hvm_op(unsigned long op, XEN_GUEST_HANDLE(void) arg)
         if ( copy_from_guest(&a, arg, 1) )
             return -EFAULT;
 
-        rc = rcu_lock_target_domain_by_id(a.domid, &d);
-        if ( rc != 0 )
-            return rc;
+        d = rcu_lock_domain_by_any_id(a.domid);
+        if ( d == NULL )
+            return -ESRCH;
 
         rc = -EINVAL;
         if ( !is_hvm_domain(d) || !paging_mode_shadow(d) )
@@ -4297,7 +4297,7 @@ long do_hvm_op(unsigned long op, XEN_GUEST_HANDLE(void) arg)
         if ( copy_from_guest(&tr, arg, 1 ) )
             return -EFAULT;
 
-        rc = rcu_lock_remote_target_domain_by_id(tr.domid, &d);
+        rc = rcu_lock_remote_domain_by_id(tr.domid, &d);
         if ( rc != 0 )
             return rc;
 
diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
index 4732c81..f16b112 100644
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -4673,9 +4673,9 @@ long arch_memory_op(int op, XEN_GUEST_HANDLE(void) arg)
         if ( copy_from_guest(&xatp, arg, 1) )
             return -EFAULT;
 
-        rc = rcu_lock_target_domain_by_id(xatp.domid, &d);
-        if ( rc != 0 )
-            return rc;
+        d = rcu_lock_domain_by_any_id(xatp.domid);
+        if ( d == NULL )
+            return -ESRCH;
 
         if ( xsm_add_to_physmap(current->domain, d) )
         {
@@ -4712,9 +4712,9 @@ long arch_memory_op(int op, XEN_GUEST_HANDLE(void) arg)
         if ( fmap.map.nr_entries > E820MAX )
             return -EINVAL;
 
-        rc = rcu_lock_target_domain_by_id(fmap.domid, &d);
-        if ( rc != 0 )
-            return rc;
+        d = rcu_lock_domain_by_any_id(fmap.domid);
+        if ( d == NULL )
+            return -ESRCH;
 
         rc = xsm_domain_memory_map(d);
         if ( rc )
@@ -4865,16 +4865,12 @@ long arch_memory_op(int op, XEN_GUEST_HANDLE(void) arg)
         struct domain *d;
         struct p2m_domain *p2m;
 
-        /* Support DOMID_SELF? */
-        if ( !IS_PRIV(current->domain) )
-            return -EPERM;
-
         if ( copy_from_guest(&target, arg, 1) )
             return -EFAULT;
 
-        rc = rcu_lock_target_domain_by_id(target.domid, &d);
-        if ( rc != 0 )
-            return rc;
+        d = rcu_lock_domain_by_any_id(target.domid);
+        if ( d == NULL )
+            return -ESRCH;
 
         if ( op == XENMEM_set_pod_target )
             rc = xsm_set_pod_target(d);
diff --git a/xen/common/event_channel.c b/xen/common/event_channel.c
index 53777f8..70becdd 100644
--- a/xen/common/event_channel.c
+++ b/xen/common/event_channel.c
@@ -165,9 +165,9 @@ static long evtchn_alloc_unbound(evtchn_alloc_unbound_t *alloc)
     domid_t        dom = alloc->dom;
     long           rc;
 
-    rc = rcu_lock_target_domain_by_id(dom, &d);
-    if ( rc )
-        return rc;
+    d = rcu_lock_domain_by_any_id(dom);
+    if ( d == NULL )
+        return -ESRCH;
 
     spin_lock(&d->event_lock);
 
@@ -798,9 +798,9 @@ static long evtchn_status(evtchn_status_t *status)
     struct evtchn   *chn;
     long             rc = 0;
 
-    rc = rcu_lock_target_domain_by_id(dom, &d);
-    if ( rc )
-        return rc;
+    d = rcu_lock_domain_by_any_id(dom);
+    if ( d == NULL )
+        return -ESRCH;
 
     spin_lock(&d->event_lock);
 
@@ -950,9 +950,9 @@ static long evtchn_reset(evtchn_reset_t *r)
     struct domain *d;
     int i, rc;
 
-    rc = rcu_lock_target_domain_by_id(dom, &d);
-    if ( rc )
-        return rc;
+    d = rcu_lock_domain_by_any_id(dom);
+    if ( d == NULL )
+        return -ESRCH;
 
     rc = xsm_evtchn_reset(current->domain, d);
     if ( rc )
diff --git a/xen/common/grant_table.c b/xen/common/grant_table.c
index b81dcff..c29087a 100644
--- a/xen/common/grant_table.c
+++ b/xen/common/grant_table.c
@@ -195,30 +195,6 @@ double_gt_unlock(struct grant_table *lgt, struct grant_table *rgt)
         spin_unlock(&rgt->lock);
 }
 
-static struct domain *gt_lock_target_domain_by_id(domid_t dom)
-{
-    struct domain *d;
-    int rc = GNTST_general_error;
-
-    switch ( rcu_lock_target_domain_by_id(dom, &d) )
-    {
-    case 0:
-        return d;
-
-    case -ESRCH:
-        gdprintk(XENLOG_INFO, "Bad domid %d.\n", dom);
-        rc = GNTST_bad_domain;
-        break;
-
-    case -EPERM:
-        rc = GNTST_permission_denied;
-        break;
-    }
-
-    ASSERT(rc < 0 && -rc <= MAX_ERRNO);
-    return ERR_PTR(rc);
-}
-
 static inline int
 __get_maptrack_handle(
     struct grant_table *t)
@@ -1304,11 +1280,12 @@ gnttab_setup_table(
         goto out1;
     }
 
-    d = gt_lock_target_domain_by_id(op.dom);
-    if ( IS_ERR(d) )
+    d = rcu_lock_domain_by_any_id(op.dom);
+    if ( d == NULL )
     {
-        op.status = PTR_ERR(d);
-        goto out1;
+        gdprintk(XENLOG_INFO, "Bad domid %d.\n", op.dom);
+        op.status = GNTST_bad_domain;
+        goto out2;
     }
 
     if ( xsm_grant_setup(current->domain, d) )
@@ -1372,10 +1349,11 @@ gnttab_query_size(
         return -EFAULT;
     }
 
-    d = gt_lock_target_domain_by_id(op.dom);
-    if ( IS_ERR(d) )
+    d = rcu_lock_domain_by_any_id(op.dom);
+    if ( d == NULL )
     {
-        op.status = PTR_ERR(d);
+        gdprintk(XENLOG_INFO, "Bad domid %d.\n", op.dom);
+        op.status = GNTST_bad_domain;
         goto query_out;
     }
 
@@ -2245,10 +2223,10 @@ gnttab_get_status_frames(XEN_GUEST_HANDLE(gnttab_get_status_frames_t) uop,
         return -EFAULT;
     }
 
-    d = gt_lock_target_domain_by_id(op.dom);
-    if ( IS_ERR(d) )
+    d = rcu_lock_domain_by_any_id(op.dom);
+    if ( d == NULL )
     {
-        op.status = PTR_ERR(d);
+        op.status = GNTST_bad_domain;
         goto out1;
     }
     rc = xsm_grant_setup(current->domain, d);
@@ -2298,14 +2276,15 @@ gnttab_get_version(XEN_GUEST_HANDLE(gnttab_get_version_t uop))
     if ( copy_from_guest(&op, uop, 1) )
         return -EFAULT;
 
-    rc = rcu_lock_target_domain_by_id(op.dom, &d);
-    if ( rc < 0 )
-        return rc;
+    d = rcu_lock_domain_by_any_id(op.dom);
+    if ( d == NULL )
+        return -ESRCH;
 
-    if ( xsm_grant_query_size(current->domain, d) )
+    rc = xsm_grant_query_size(current->domain, d);
+    if ( rc )
     {
         rcu_unlock_domain(d);
-        return -EPERM;
+        return rc;
     }
 
     op.version = d->grant_table->gt_version;
diff --git a/xen/common/memory.c b/xen/common/memory.c
index 8779d6b..cfdd63f 100644
--- a/xen/common/memory.c
+++ b/xen/common/memory.c
@@ -570,7 +570,8 @@ long do_memory_op(unsigned long cmd, XEN_GUEST_HANDLE(void) arg)
              && (reservation.mem_flags & XENMEMF_populate_on_demand) )
             args.memflags |= MEMF_populate_on_demand;
 
-        if ( unlikely(rcu_lock_target_domain_by_id(reservation.domid, &d)) )
+        d = rcu_lock_domain_by_any_id(reservation.domid);
+        if ( d == NULL )
             return start_extent;
         args.domain = d;
 
@@ -619,9 +620,9 @@ long do_memory_op(unsigned long cmd, XEN_GUEST_HANDLE(void) arg)
         if ( copy_from_guest(&domid, arg, 1) )
             return -EFAULT;
 
-        rc = rcu_lock_target_domain_by_id(domid, &d);
-        if ( rc )
-            return rc;
+        d = rcu_lock_domain_by_any_id(domid);
+        if ( d == NULL )
+            return -ESRCH;
 
         rc = xsm_memory_stat_reservation(current->domain, d);
         if ( rc )
@@ -657,9 +658,9 @@ long do_memory_op(unsigned long cmd, XEN_GUEST_HANDLE(void) arg)
         if ( copy_from_guest(&xrfp, arg, 1) )
             return -EFAULT;
 
-        rc = rcu_lock_target_domain_by_id(xrfp.domid, &d);
-        if ( rc != 0 )
-            return rc;
+        d = rcu_lock_domain_by_any_id(xrfp.domid);
+        if ( d == NULL )
+            return -ESRCH;
 
         if ( xsm_remove_from_physmap(current->domain, d) )
         {
-- 
1.7.11.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 10 19:49:56 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Sep 2012 19:49:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TB9zO-0001Db-G2; Mon, 10 Sep 2012 19:49:46 +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 1TB9zM-00019X-6h
	for xen-devel@lists.xen.org; Mon, 10 Sep 2012 19:49:44 +0000
Received: from [85.158.143.99:27987] by server-3.bemta-4.messagelabs.com id
	98/D7-08232-7544E405; Mon, 10 Sep 2012 19:49:43 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-16.tower-216.messagelabs.com!1347306581!18372732!1
X-Originating-IP: [63.239.67.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10118 invoked from network); 10 Sep 2012 19:49:42 -0000
Received: from emvm-gh1-uea09.nsa.gov (HELO nsa.gov) (63.239.67.10)
	by server-16.tower-216.messagelabs.com with SMTP;
	10 Sep 2012 19:49:42 -0000
X-TM-IMSS-Message-ID: <3066d337000f2263@nsa.gov>
Received: from tarius.tycho.ncsc.mil ([144.51.3.1]) by nsa.gov
	([63.239.67.10]) with ESMTP (TREND IMSS SMTP Service 7.1) id
	3066d337000f2263 ; Mon, 10 Sep 2012 15:51: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 q8AJna3o027796; 
	Mon, 10 Sep 2012 15:49:40 -0400
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xen.org
Date: Mon, 10 Sep 2012 15:49:05 -0400
Message-Id: <1347306553-20980-13-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.11.4
In-Reply-To: <1347306553-20980-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1347306553-20980-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>, Keir Fraser <keir@xen.org>,
	Jan Beulich <jbeulich@suse.com>
Subject: [Xen-devel] [PATCH 12/20] xen: avoid calling
	rcu_lock_*target_domain when an XSM hook 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>
MIME-Version: 1.0
Content-Type: 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 rcu_lock_{,remote_}target_domain_by_id functions are wrappers around
an IS_PRIV_FOR check for the current domain. This is now redundant with
XSM hooks, so replace these calls with rcu_lock_domain_by_any_id or
rcu_lock_remote_domain_by_id to remove the duplicate permission checks.

When XSM_ENABLE is not defined or when the dummy XSM module is used,
this patch should not change any functionality. Because the locations of
privilege checks have sometimes moved below argument validation, error
returns of some functions may change from EPERM to EINVAL when called
with invalid arguments and from a domain without permission to perform
the operation.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Cc: Keir Fraser <keir@xen.org>
Cc: Jan Beulich <jbeulich@suse.com>
---
 xen/arch/x86/hvm/hvm.c     | 38 +++++++++++++++----------------
 xen/arch/x86/mm.c          | 22 ++++++++----------
 xen/common/event_channel.c | 18 +++++++--------
 xen/common/grant_table.c   | 57 +++++++++++++++-------------------------------
 xen/common/memory.c        | 15 ++++++------
 5 files changed, 63 insertions(+), 87 deletions(-)

diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 0576a24..e737671 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -3375,7 +3375,7 @@ static int hvmop_set_pci_intx_level(
     if ( (op.domain > 0) || (op.bus > 0) || (op.device > 31) || (op.intx > 3) )
         return -EINVAL;
 
-    rc = rcu_lock_remote_target_domain_by_id(op.domid, &d);
+    rc = rcu_lock_remote_domain_by_id(op.domid, &d);
     if ( rc != 0 )
         return rc;
 
@@ -3540,7 +3540,7 @@ static int hvmop_set_isa_irq_level(
     if ( op.isa_irq > 15 )
         return -EINVAL;
 
-    rc = rcu_lock_remote_target_domain_by_id(op.domid, &d);
+    rc = rcu_lock_remote_domain_by_id(op.domid, &d);
     if ( rc != 0 )
         return rc;
 
@@ -3584,7 +3584,7 @@ static int hvmop_set_pci_link_route(
     if ( (op.link > 3) || (op.isa_irq > 15) )
         return -EINVAL;
 
-    rc = rcu_lock_remote_target_domain_by_id(op.domid, &d);
+    rc = rcu_lock_remote_domain_by_id(op.domid, &d);
     if ( rc != 0 )
         return rc;
 
@@ -3614,7 +3614,7 @@ static int hvmop_inject_msi(
     if ( copy_from_guest(&op, uop, 1) )
         return -EFAULT;
 
-    rc = rcu_lock_remote_target_domain_by_id(op.domid, &d);
+    rc = rcu_lock_remote_domain_by_id(op.domid, &d);
     if ( rc != 0 )
         return rc;
 
@@ -3711,9 +3711,9 @@ long do_hvm_op(unsigned long op, XEN_GUEST_HANDLE(void) arg)
         if ( a.index >= HVM_NR_PARAMS )
             return -EINVAL;
 
-        rc = rcu_lock_target_domain_by_id(a.domid, &d);
-        if ( rc != 0 )
-            return rc;
+        d = rcu_lock_domain_by_any_id(a.domid);
+        if ( d == NULL )
+            return -ESRCH;
 
         rc = -EINVAL;
         if ( !is_hvm_domain(d) )
@@ -3957,7 +3957,7 @@ long do_hvm_op(unsigned long op, XEN_GUEST_HANDLE(void) arg)
         if ( copy_from_guest(&a, arg, 1) )
             return -EFAULT;
 
-        rc = rcu_lock_remote_target_domain_by_id(a.domid, &d);
+        rc = rcu_lock_remote_domain_by_id(a.domid, &d);
         if ( rc != 0 )
             return rc;
 
@@ -3996,7 +3996,7 @@ long do_hvm_op(unsigned long op, XEN_GUEST_HANDLE(void) arg)
         if ( copy_from_guest(&a, arg, 1) )
             return -EFAULT;
 
-        rc = rcu_lock_remote_target_domain_by_id(a.domid, &d);
+        rc = rcu_lock_remote_domain_by_id(a.domid, &d);
         if ( rc != 0 )
             return rc;
 
@@ -4046,9 +4046,9 @@ long do_hvm_op(unsigned long op, XEN_GUEST_HANDLE(void) arg)
         if ( copy_from_guest(&a, arg, 1) )
             return -EFAULT;
 
-        rc = rcu_lock_target_domain_by_id(a.domid, &d);
-        if ( rc != 0 )
-            return rc;
+        d = rcu_lock_domain_by_any_id(a.domid);
+        if ( d == NULL )
+            return -ESRCH;
 
         rc = xsm_hvm_param(d, op);
         if ( rc )
@@ -4093,7 +4093,7 @@ long do_hvm_op(unsigned long op, XEN_GUEST_HANDLE(void) arg)
         if ( copy_from_guest(&a, arg, 1) )
             return -EFAULT;
 
-        rc = rcu_lock_remote_target_domain_by_id(a.domid, &d);
+        rc = rcu_lock_remote_domain_by_id(a.domid, &d);
         if ( rc != 0 )
             return rc;
 
@@ -4172,7 +4172,7 @@ long do_hvm_op(unsigned long op, XEN_GUEST_HANDLE(void) arg)
         if ( copy_from_guest(&a, arg, 1) )
             return -EFAULT;
 
-        rc = rcu_lock_remote_target_domain_by_id(a.domid, &d);
+        rc = rcu_lock_remote_domain_by_id(a.domid, &d);
         if ( rc != 0 )
             return rc;
 
@@ -4207,7 +4207,7 @@ long do_hvm_op(unsigned long op, XEN_GUEST_HANDLE(void) arg)
         if ( copy_from_guest(&a, arg, 1) )
             return -EFAULT;
 
-        rc = rcu_lock_remote_target_domain_by_id(a.domid, &d);
+        rc = rcu_lock_remote_domain_by_id(a.domid, &d);
         if ( rc != 0 )
             return rc;
 
@@ -4243,9 +4243,9 @@ long do_hvm_op(unsigned long op, XEN_GUEST_HANDLE(void) arg)
         if ( copy_from_guest(&a, arg, 1) )
             return -EFAULT;
 
-        rc = rcu_lock_target_domain_by_id(a.domid, &d);
-        if ( rc != 0 )
-            return rc;
+        d = rcu_lock_domain_by_any_id(a.domid);
+        if ( d == NULL )
+            return -ESRCH;
 
         rc = -EINVAL;
         if ( !is_hvm_domain(d) || !paging_mode_shadow(d) )
@@ -4297,7 +4297,7 @@ long do_hvm_op(unsigned long op, XEN_GUEST_HANDLE(void) arg)
         if ( copy_from_guest(&tr, arg, 1 ) )
             return -EFAULT;
 
-        rc = rcu_lock_remote_target_domain_by_id(tr.domid, &d);
+        rc = rcu_lock_remote_domain_by_id(tr.domid, &d);
         if ( rc != 0 )
             return rc;
 
diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
index 4732c81..f16b112 100644
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -4673,9 +4673,9 @@ long arch_memory_op(int op, XEN_GUEST_HANDLE(void) arg)
         if ( copy_from_guest(&xatp, arg, 1) )
             return -EFAULT;
 
-        rc = rcu_lock_target_domain_by_id(xatp.domid, &d);
-        if ( rc != 0 )
-            return rc;
+        d = rcu_lock_domain_by_any_id(xatp.domid);
+        if ( d == NULL )
+            return -ESRCH;
 
         if ( xsm_add_to_physmap(current->domain, d) )
         {
@@ -4712,9 +4712,9 @@ long arch_memory_op(int op, XEN_GUEST_HANDLE(void) arg)
         if ( fmap.map.nr_entries > E820MAX )
             return -EINVAL;
 
-        rc = rcu_lock_target_domain_by_id(fmap.domid, &d);
-        if ( rc != 0 )
-            return rc;
+        d = rcu_lock_domain_by_any_id(fmap.domid);
+        if ( d == NULL )
+            return -ESRCH;
 
         rc = xsm_domain_memory_map(d);
         if ( rc )
@@ -4865,16 +4865,12 @@ long arch_memory_op(int op, XEN_GUEST_HANDLE(void) arg)
         struct domain *d;
         struct p2m_domain *p2m;
 
-        /* Support DOMID_SELF? */
-        if ( !IS_PRIV(current->domain) )
-            return -EPERM;
-
         if ( copy_from_guest(&target, arg, 1) )
             return -EFAULT;
 
-        rc = rcu_lock_target_domain_by_id(target.domid, &d);
-        if ( rc != 0 )
-            return rc;
+        d = rcu_lock_domain_by_any_id(target.domid);
+        if ( d == NULL )
+            return -ESRCH;
 
         if ( op == XENMEM_set_pod_target )
             rc = xsm_set_pod_target(d);
diff --git a/xen/common/event_channel.c b/xen/common/event_channel.c
index 53777f8..70becdd 100644
--- a/xen/common/event_channel.c
+++ b/xen/common/event_channel.c
@@ -165,9 +165,9 @@ static long evtchn_alloc_unbound(evtchn_alloc_unbound_t *alloc)
     domid_t        dom = alloc->dom;
     long           rc;
 
-    rc = rcu_lock_target_domain_by_id(dom, &d);
-    if ( rc )
-        return rc;
+    d = rcu_lock_domain_by_any_id(dom);
+    if ( d == NULL )
+        return -ESRCH;
 
     spin_lock(&d->event_lock);
 
@@ -798,9 +798,9 @@ static long evtchn_status(evtchn_status_t *status)
     struct evtchn   *chn;
     long             rc = 0;
 
-    rc = rcu_lock_target_domain_by_id(dom, &d);
-    if ( rc )
-        return rc;
+    d = rcu_lock_domain_by_any_id(dom);
+    if ( d == NULL )
+        return -ESRCH;
 
     spin_lock(&d->event_lock);
 
@@ -950,9 +950,9 @@ static long evtchn_reset(evtchn_reset_t *r)
     struct domain *d;
     int i, rc;
 
-    rc = rcu_lock_target_domain_by_id(dom, &d);
-    if ( rc )
-        return rc;
+    d = rcu_lock_domain_by_any_id(dom);
+    if ( d == NULL )
+        return -ESRCH;
 
     rc = xsm_evtchn_reset(current->domain, d);
     if ( rc )
diff --git a/xen/common/grant_table.c b/xen/common/grant_table.c
index b81dcff..c29087a 100644
--- a/xen/common/grant_table.c
+++ b/xen/common/grant_table.c
@@ -195,30 +195,6 @@ double_gt_unlock(struct grant_table *lgt, struct grant_table *rgt)
         spin_unlock(&rgt->lock);
 }
 
-static struct domain *gt_lock_target_domain_by_id(domid_t dom)
-{
-    struct domain *d;
-    int rc = GNTST_general_error;
-
-    switch ( rcu_lock_target_domain_by_id(dom, &d) )
-    {
-    case 0:
-        return d;
-
-    case -ESRCH:
-        gdprintk(XENLOG_INFO, "Bad domid %d.\n", dom);
-        rc = GNTST_bad_domain;
-        break;
-
-    case -EPERM:
-        rc = GNTST_permission_denied;
-        break;
-    }
-
-    ASSERT(rc < 0 && -rc <= MAX_ERRNO);
-    return ERR_PTR(rc);
-}
-
 static inline int
 __get_maptrack_handle(
     struct grant_table *t)
@@ -1304,11 +1280,12 @@ gnttab_setup_table(
         goto out1;
     }
 
-    d = gt_lock_target_domain_by_id(op.dom);
-    if ( IS_ERR(d) )
+    d = rcu_lock_domain_by_any_id(op.dom);
+    if ( d == NULL )
     {
-        op.status = PTR_ERR(d);
-        goto out1;
+        gdprintk(XENLOG_INFO, "Bad domid %d.\n", op.dom);
+        op.status = GNTST_bad_domain;
+        goto out2;
     }
 
     if ( xsm_grant_setup(current->domain, d) )
@@ -1372,10 +1349,11 @@ gnttab_query_size(
         return -EFAULT;
     }
 
-    d = gt_lock_target_domain_by_id(op.dom);
-    if ( IS_ERR(d) )
+    d = rcu_lock_domain_by_any_id(op.dom);
+    if ( d == NULL )
     {
-        op.status = PTR_ERR(d);
+        gdprintk(XENLOG_INFO, "Bad domid %d.\n", op.dom);
+        op.status = GNTST_bad_domain;
         goto query_out;
     }
 
@@ -2245,10 +2223,10 @@ gnttab_get_status_frames(XEN_GUEST_HANDLE(gnttab_get_status_frames_t) uop,
         return -EFAULT;
     }
 
-    d = gt_lock_target_domain_by_id(op.dom);
-    if ( IS_ERR(d) )
+    d = rcu_lock_domain_by_any_id(op.dom);
+    if ( d == NULL )
     {
-        op.status = PTR_ERR(d);
+        op.status = GNTST_bad_domain;
         goto out1;
     }
     rc = xsm_grant_setup(current->domain, d);
@@ -2298,14 +2276,15 @@ gnttab_get_version(XEN_GUEST_HANDLE(gnttab_get_version_t uop))
     if ( copy_from_guest(&op, uop, 1) )
         return -EFAULT;
 
-    rc = rcu_lock_target_domain_by_id(op.dom, &d);
-    if ( rc < 0 )
-        return rc;
+    d = rcu_lock_domain_by_any_id(op.dom);
+    if ( d == NULL )
+        return -ESRCH;
 
-    if ( xsm_grant_query_size(current->domain, d) )
+    rc = xsm_grant_query_size(current->domain, d);
+    if ( rc )
     {
         rcu_unlock_domain(d);
-        return -EPERM;
+        return rc;
     }
 
     op.version = d->grant_table->gt_version;
diff --git a/xen/common/memory.c b/xen/common/memory.c
index 8779d6b..cfdd63f 100644
--- a/xen/common/memory.c
+++ b/xen/common/memory.c
@@ -570,7 +570,8 @@ long do_memory_op(unsigned long cmd, XEN_GUEST_HANDLE(void) arg)
              && (reservation.mem_flags & XENMEMF_populate_on_demand) )
             args.memflags |= MEMF_populate_on_demand;
 
-        if ( unlikely(rcu_lock_target_domain_by_id(reservation.domid, &d)) )
+        d = rcu_lock_domain_by_any_id(reservation.domid);
+        if ( d == NULL )
             return start_extent;
         args.domain = d;
 
@@ -619,9 +620,9 @@ long do_memory_op(unsigned long cmd, XEN_GUEST_HANDLE(void) arg)
         if ( copy_from_guest(&domid, arg, 1) )
             return -EFAULT;
 
-        rc = rcu_lock_target_domain_by_id(domid, &d);
-        if ( rc )
-            return rc;
+        d = rcu_lock_domain_by_any_id(domid);
+        if ( d == NULL )
+            return -ESRCH;
 
         rc = xsm_memory_stat_reservation(current->domain, d);
         if ( rc )
@@ -657,9 +658,9 @@ long do_memory_op(unsigned long cmd, XEN_GUEST_HANDLE(void) arg)
         if ( copy_from_guest(&xrfp, arg, 1) )
             return -EFAULT;
 
-        rc = rcu_lock_target_domain_by_id(xrfp.domid, &d);
-        if ( rc != 0 )
-            return rc;
+        d = rcu_lock_domain_by_any_id(xrfp.domid);
+        if ( d == NULL )
+            return -ESRCH;
 
         if ( xsm_remove_from_physmap(current->domain, d) )
         {
-- 
1.7.11.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 10 19:49:56 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Sep 2012 19:49:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TB9zK-0001AB-Mn; Mon, 10 Sep 2012 19:49:42 +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 1TB9zJ-00019P-BC
	for xen-devel@lists.xen.org; Mon, 10 Sep 2012 19:49:41 +0000
Received: from [85.158.138.51:26901] by server-9.bemta-3.messagelabs.com id
	E4/3A-15390-4544E405; Mon, 10 Sep 2012 19:49:40 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-11.tower-174.messagelabs.com!1347306579!29749135!1
X-Originating-IP: [63.239.67.9]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4274 invoked from network); 10 Sep 2012 19:49:39 -0000
Received: from emvm-gh1-uea08.nsa.gov (HELO nsa.gov) (63.239.67.9)
	by server-11.tower-174.messagelabs.com with SMTP;
	10 Sep 2012 19:49:39 -0000
X-TM-IMSS-Message-ID: <30670aea000ed1bd@nsa.gov>
Received: from tarius.tycho.ncsc.mil ([144.51.3.1]) by nsa.gov ([63.239.67.9])
	with ESMTP (TREND IMSS SMTP Service 7.1) id 30670aea000ed1bd ;
	Mon, 10 Sep 2012 15:49:33 -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 q8AJna3f027796; 
	Mon, 10 Sep 2012 15:49:36 -0400
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xen.org
Date: Mon, 10 Sep 2012 15:48:56 -0400
Message-Id: <1347306553-20980-4-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.11.4
In-Reply-To: <1347306553-20980-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1347306553-20980-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: [Xen-devel] [PATCH 03/20] xen: Add versions of rcu_lock_*_domain
	without IS_PRIV checks
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

These functions will be used to avoid duplication of IS_PRIV calls
that will be introduced in XSM hooks.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 xen/common/domain.c     | 21 +++++++++++++++++++++
 xen/include/xen/sched.h | 11 +++++++++++
 2 files changed, 32 insertions(+)

diff --git a/xen/common/domain.c b/xen/common/domain.c
index a1aa05e..52489b3 100644
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -420,6 +420,13 @@ struct domain *rcu_lock_domain_by_id(domid_t dom)
     return d;
 }
 
+struct domain *rcu_lock_domain_by_any_id(domid_t dom)
+{
+    if ( dom == DOMID_SELF )
+        return rcu_lock_current_domain();
+    return rcu_lock_domain_by_id(dom);
+}
+
 int rcu_lock_target_domain_by_id(domid_t dom, struct domain **d)
 {
     if ( dom == DOMID_SELF )
@@ -454,6 +461,20 @@ int rcu_lock_remote_target_domain_by_id(domid_t dom, struct domain **d)
     return 0;
 }
 
+int rcu_lock_remote_domain_by_id(domid_t dom, struct domain **d)
+{
+    if ( (*d = rcu_lock_domain_by_id(dom)) == NULL )
+        return -ESRCH;
+
+    if ( *d == current->domain )
+    {
+        rcu_unlock_domain(*d);
+        return -EPERM;
+    }
+
+    return 0;
+}
+
 int domain_kill(struct domain *d)
 {
     int rc = 0;
diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
index 53804c8..b0def4a 100644
--- a/xen/include/xen/sched.h
+++ b/xen/include/xen/sched.h
@@ -447,6 +447,11 @@ struct domain *domain_create(
 struct domain *rcu_lock_domain_by_id(domid_t dom);
 
 /*
+ * As above function, but resolves DOMID_SELF to current domain
+ */
+struct domain *rcu_lock_domain_by_any_id(domid_t dom);
+
+/*
  * As above function, but accounts for current domain context:
  *  - Translates target DOMID_SELF into caller's domain id; and
  *  - Checks that caller has permission to act on the target domain.
@@ -460,6 +465,12 @@ int rcu_lock_target_domain_by_id(domid_t dom, struct domain **d);
  */
 int rcu_lock_remote_target_domain_by_id(domid_t dom, struct domain **d);
 
+/*
+ * As rcu_lock_domain_by_id(), but will fail EPERM or ESRCH rather than resolve
+ * to local domain.
+ */
+int rcu_lock_remote_domain_by_id(domid_t dom, struct domain **d);
+
 /* Finish a RCU critical region started by rcu_lock_domain_by_id(). */
 static inline void rcu_unlock_domain(struct domain *d)
 {
-- 
1.7.11.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 10 19:49:56 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Sep 2012 19:49:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TB9zK-0001AB-Mn; Mon, 10 Sep 2012 19:49:42 +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 1TB9zJ-00019P-BC
	for xen-devel@lists.xen.org; Mon, 10 Sep 2012 19:49:41 +0000
Received: from [85.158.138.51:26901] by server-9.bemta-3.messagelabs.com id
	E4/3A-15390-4544E405; Mon, 10 Sep 2012 19:49:40 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-11.tower-174.messagelabs.com!1347306579!29749135!1
X-Originating-IP: [63.239.67.9]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4274 invoked from network); 10 Sep 2012 19:49:39 -0000
Received: from emvm-gh1-uea08.nsa.gov (HELO nsa.gov) (63.239.67.9)
	by server-11.tower-174.messagelabs.com with SMTP;
	10 Sep 2012 19:49:39 -0000
X-TM-IMSS-Message-ID: <30670aea000ed1bd@nsa.gov>
Received: from tarius.tycho.ncsc.mil ([144.51.3.1]) by nsa.gov ([63.239.67.9])
	with ESMTP (TREND IMSS SMTP Service 7.1) id 30670aea000ed1bd ;
	Mon, 10 Sep 2012 15:49:33 -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 q8AJna3f027796; 
	Mon, 10 Sep 2012 15:49:36 -0400
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xen.org
Date: Mon, 10 Sep 2012 15:48:56 -0400
Message-Id: <1347306553-20980-4-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.11.4
In-Reply-To: <1347306553-20980-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1347306553-20980-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: [Xen-devel] [PATCH 03/20] xen: Add versions of rcu_lock_*_domain
	without IS_PRIV checks
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

These functions will be used to avoid duplication of IS_PRIV calls
that will be introduced in XSM hooks.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 xen/common/domain.c     | 21 +++++++++++++++++++++
 xen/include/xen/sched.h | 11 +++++++++++
 2 files changed, 32 insertions(+)

diff --git a/xen/common/domain.c b/xen/common/domain.c
index a1aa05e..52489b3 100644
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -420,6 +420,13 @@ struct domain *rcu_lock_domain_by_id(domid_t dom)
     return d;
 }
 
+struct domain *rcu_lock_domain_by_any_id(domid_t dom)
+{
+    if ( dom == DOMID_SELF )
+        return rcu_lock_current_domain();
+    return rcu_lock_domain_by_id(dom);
+}
+
 int rcu_lock_target_domain_by_id(domid_t dom, struct domain **d)
 {
     if ( dom == DOMID_SELF )
@@ -454,6 +461,20 @@ int rcu_lock_remote_target_domain_by_id(domid_t dom, struct domain **d)
     return 0;
 }
 
+int rcu_lock_remote_domain_by_id(domid_t dom, struct domain **d)
+{
+    if ( (*d = rcu_lock_domain_by_id(dom)) == NULL )
+        return -ESRCH;
+
+    if ( *d == current->domain )
+    {
+        rcu_unlock_domain(*d);
+        return -EPERM;
+    }
+
+    return 0;
+}
+
 int domain_kill(struct domain *d)
 {
     int rc = 0;
diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
index 53804c8..b0def4a 100644
--- a/xen/include/xen/sched.h
+++ b/xen/include/xen/sched.h
@@ -447,6 +447,11 @@ struct domain *domain_create(
 struct domain *rcu_lock_domain_by_id(domid_t dom);
 
 /*
+ * As above function, but resolves DOMID_SELF to current domain
+ */
+struct domain *rcu_lock_domain_by_any_id(domid_t dom);
+
+/*
  * As above function, but accounts for current domain context:
  *  - Translates target DOMID_SELF into caller's domain id; and
  *  - Checks that caller has permission to act on the target domain.
@@ -460,6 +465,12 @@ int rcu_lock_target_domain_by_id(domid_t dom, struct domain **d);
  */
 int rcu_lock_remote_target_domain_by_id(domid_t dom, struct domain **d);
 
+/*
+ * As rcu_lock_domain_by_id(), but will fail EPERM or ESRCH rather than resolve
+ * to local domain.
+ */
+int rcu_lock_remote_domain_by_id(domid_t dom, struct domain **d);
+
 /* Finish a RCU critical region started by rcu_lock_domain_by_id(). */
 static inline void rcu_unlock_domain(struct domain *d)
 {
-- 
1.7.11.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 10 19:49:56 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Sep 2012 19:49:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TB9zO-0001EA-Ta; Mon, 10 Sep 2012 19:49:46 +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 1TB9zM-0001A4-87
	for xen-devel@lists.xen.org; Mon, 10 Sep 2012 19:49:44 +0000
Received: from [85.158.143.99:27991] by server-2.bemta-4.messagelabs.com id
	A7/54-21239-7544E405; Mon, 10 Sep 2012 19:49:43 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-6.tower-216.messagelabs.com!1347306581!22574385!1
X-Originating-IP: [63.239.67.10]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16677 invoked from network); 10 Sep 2012 19:49:41 -0000
Received: from emvm-gh1-uea09.nsa.gov (HELO nsa.gov) (63.239.67.10)
	by server-6.tower-216.messagelabs.com with SMTP;
	10 Sep 2012 19:49:41 -0000
X-TM-IMSS-Message-ID: <3066d153000f2260@nsa.gov>
Received: from tarius.tycho.ncsc.mil ([144.51.3.1]) by nsa.gov
	([63.239.67.10]) with ESMTP (TREND IMSS SMTP Service 7.1) id
	3066d153000f2260 ; Mon, 10 Sep 2012 15:51: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 q8AJna3m027796; 
	Mon, 10 Sep 2012 15:49:39 -0400
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xen.org
Date: Mon, 10 Sep 2012 15:49:03 -0400
Message-Id: <1347306553-20980-11-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.11.4
In-Reply-To: <1347306553-20980-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1347306553-20980-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>, Keir Fraser <keir@xen.org>,
	Jan Beulich <jbeulich@suse.com>
Subject: [Xen-devel] [PATCH 10/20] xsm: Add IS_PRIV checks to dummy XSM
	module
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/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 copies IS_PRIV checks into the dummy XSM hooks and makes the
dummy hooks the default implementation instead of always returning zero.
This patch should not change any functionality regardless of the state
of XSM_ENABLE; these newly introduced duplicate checks will be resolved
in the next patch.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Cc: Keir Fraser <keir@xen.org>
Cc: Jan Beulich <jbeulich@suse.com>
---
 xen/include/xsm/dummy.h | 828 ++++++++++++++++++++++++++++++++++++++++++++++++
 xen/include/xsm/xsm.h   |  52 ++-
 xen/xsm/dummy.c         | 617 +-----------------------------------
 xen/xsm/xsm_core.c      |   2 +-
 4 files changed, 854 insertions(+), 645 deletions(-)
 create mode 100644 xen/include/xsm/dummy.h

diff --git a/xen/include/xsm/dummy.h b/xen/include/xsm/dummy.h
new file mode 100644
index 0000000..3f5d9b0
--- /dev/null
+++ b/xen/include/xsm/dummy.h
@@ -0,0 +1,828 @@
+/*
+ *  Default XSM hooks - IS_PRIV and IS_PRIV_FOR checks
+ *
+ *  Author: Daniel De Graaf <dgdegra@tyhco.nsa.gov>
+ *
+ *  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.
+ */
+
+#include <xen/sched.h>
+#include <xsm/xsm.h>
+
+static XSM_DEFAULT(void, security_domaininfo)(struct domain *d,
+                                    struct xen_domctl_getdomaininfo *info)
+{
+    return;
+}
+
+static XSM_DEFAULT(int, setvcpucontext)(struct domain *d)
+{
+    if ( !IS_PRIV(current->domain) )
+        return -EPERM;
+    return 0;
+}
+
+static XSM_DEFAULT(int, pausedomain) (struct domain *d)
+{
+    if ( !IS_PRIV(current->domain) )
+        return -EPERM;
+    return 0;
+}
+
+static XSM_DEFAULT(int, unpausedomain) (struct domain *d)
+{
+    if ( !IS_PRIV(current->domain) )
+        return -EPERM;
+    return 0;
+}
+
+static XSM_DEFAULT(int, resumedomain) (struct domain *d)
+{
+    if ( !IS_PRIV(current->domain) )
+        return -EPERM;
+    return 0;
+}
+
+static XSM_DEFAULT(int, domain_create)(struct domain *d, u32 ssidref)
+{
+    if ( !IS_PRIV(current->domain) )
+        return -EPERM;
+    return 0;
+}
+
+static XSM_DEFAULT(int, max_vcpus)(struct domain *d)
+{
+    if ( !IS_PRIV(current->domain) )
+        return -EPERM;
+    return 0;
+}
+
+static XSM_DEFAULT(int, destroydomain) (struct domain *d)
+{
+    if ( !IS_PRIV(current->domain) )
+        return -EPERM;
+    return 0;
+}
+
+static XSM_DEFAULT(int, vcpuaffinity) (int cmd, struct domain *d)
+{
+    if ( !IS_PRIV(current->domain) )
+        return -EPERM;
+    return 0;
+}
+
+static XSM_DEFAULT(int, scheduler) (struct domain *d)
+{
+    if ( !IS_PRIV(current->domain) )
+        return -EPERM;
+    return 0;
+}
+
+static XSM_DEFAULT(int, getdomaininfo) (struct domain *d)
+{
+    if ( !IS_PRIV(current->domain) )
+        return -EPERM;
+    return 0;
+}
+
+static XSM_DEFAULT(int, getvcpucontext) (struct domain *d)
+{
+    if ( !IS_PRIV(current->domain) )
+        return -EPERM;
+    return 0;
+}
+
+static XSM_DEFAULT(int, getvcpuinfo) (struct domain *d)
+{
+    if ( !IS_PRIV(current->domain) )
+        return -EPERM;
+    return 0;
+}
+
+static XSM_DEFAULT(int, domain_settime) (struct domain *d)
+{
+    if ( !IS_PRIV(current->domain) )
+        return -EPERM;
+    return 0;
+}
+
+static XSM_DEFAULT(int, set_target) (struct domain *d, struct domain *e)
+{
+    if ( !IS_PRIV(current->domain) )
+        return -EPERM;
+    return 0;
+}
+
+static XSM_DEFAULT(int, domctl)(struct domain *d, int cmd)
+{
+    if ( !IS_PRIV(current->domain) )
+        return -EPERM;
+    return 0;
+}
+
+static XSM_DEFAULT(int, set_virq_handler)(struct domain *d, uint32_t virq)
+{
+    if ( !IS_PRIV(current->domain) )
+        return -EPERM;
+    return 0;
+}
+
+static XSM_DEFAULT(int, tbufcontrol) (void)
+{
+    if ( !IS_PRIV(current->domain) )
+        return -EPERM;
+    return 0;
+}
+
+static XSM_DEFAULT(int, readconsole) (uint32_t clear)
+{
+    if ( !IS_PRIV(current->domain) )
+        return -EPERM;
+    return 0;
+}
+
+static XSM_DEFAULT(int, sched_id) (void)
+{
+    if ( !IS_PRIV(current->domain) )
+        return -EPERM;
+    return 0;
+}
+
+static XSM_DEFAULT(int, setdomainmaxmem) (struct domain *d)
+{
+    if ( !IS_PRIV(current->domain) )
+        return -EPERM;
+    return 0;
+}
+
+static XSM_DEFAULT(int, setdomainhandle) (struct domain *d)
+{
+    if ( !IS_PRIV(current->domain) )
+        return -EPERM;
+    return 0;
+}
+
+static XSM_DEFAULT(int, setdebugging) (struct domain *d)
+{
+    if ( !IS_PRIV(current->domain) )
+        return -EPERM;
+    return 0;
+}
+
+static XSM_DEFAULT(int, perfcontrol) (void)
+{
+    if ( !IS_PRIV(current->domain) )
+        return -EPERM;
+    return 0;
+}
+
+static XSM_DEFAULT(int, debug_keys) (void)
+{
+    if ( !IS_PRIV(current->domain) )
+        return -EPERM;
+    return 0;
+}
+
+static XSM_DEFAULT(int, getcpuinfo) (void)
+{
+    if ( !IS_PRIV(current->domain) )
+        return -EPERM;
+    return 0;
+}
+
+static XSM_DEFAULT(int, get_pmstat) (void)
+{
+    if ( !IS_PRIV(current->domain) )
+        return -EPERM;
+    return 0;
+}
+
+static XSM_DEFAULT(int, setpminfo) (void)
+{
+    if ( !IS_PRIV(current->domain) )
+        return -EPERM;
+    return 0;
+}
+
+static XSM_DEFAULT(int, pm_op) (void)
+{
+    if ( !IS_PRIV(current->domain) )
+        return -EPERM;
+    return 0;
+}
+
+static XSM_DEFAULT(int, do_mca) (void)
+{
+    if ( !IS_PRIV(current->domain) )
+        return -EPERM;
+    return 0;
+}
+
+static XSM_DEFAULT(int, availheap) (void)
+{
+    if ( !IS_PRIV(current->domain) )
+        return -EPERM;
+    return 0;
+}
+
+static XSM_DEFAULT(int, alloc_security_domain) (struct domain *d)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(void, free_security_domain) (struct domain *d)
+{
+    return;
+}
+
+static XSM_DEFAULT(int, grant_mapref) (struct domain *d1, struct domain *d2,
+                                                                uint32_t flags)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, grant_unmapref) (struct domain *d1, struct domain *d2)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, grant_setup) (struct domain *d1, struct domain *d2)
+{
+    if ( d1 != d2 && !IS_PRIV_FOR(d1, d2) )
+        return -EPERM;
+    return 0;
+}
+
+static XSM_DEFAULT(int, grant_transfer) (struct domain *d1, struct domain *d2)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, grant_copy) (struct domain *d1, struct domain *d2)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, grant_query_size) (struct domain *d1, struct domain *d2)
+{
+    if ( d1 != d2 && !IS_PRIV_FOR(d1, d2) )
+        return -EPERM;
+    return 0;
+}
+
+static XSM_DEFAULT(int, memory_adjust_reservation) (struct domain *d1,
+                                                            struct domain *d2)
+{
+    if ( d1 != d2 && !IS_PRIV_FOR(d1, d2) )
+        return -EPERM;
+    return 0;
+}
+
+static XSM_DEFAULT(int, memory_stat_reservation) (struct domain *d1, struct domain *d2)
+{
+    if ( !IS_PRIV_FOR(d1, d2) )
+        return -EPERM;
+    return 0;
+}
+
+static XSM_DEFAULT(int, console_io) (struct domain *d, int cmd)
+{
+#ifndef VERBOSE
+    if ( !IS_PRIV(current->domain) )
+        return -EPERM;
+#endif
+    return 0;
+}
+
+static XSM_DEFAULT(int, profile) (struct domain *d, int op)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, kexec) (void)
+{
+    if ( !IS_PRIV(current->domain) )
+        return -EPERM;
+    return 0;
+}
+
+static XSM_DEFAULT(int, schedop_shutdown) (struct domain *d1, struct domain *d2)
+{
+    if ( !IS_PRIV_FOR(d1, d2) )
+        return -EPERM;
+    return 0;
+}
+
+static XSM_DEFAULT(int, memory_pin_page) (struct domain *d1, struct domain *d2,
+                                          struct page_info *page)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, evtchn_unbound) (struct domain *d, struct evtchn *chn,
+                                         domid_t id2)
+{
+    if ( current->domain != d && !IS_PRIV_FOR(current->domain, d) )
+        return -EPERM;
+    return 0;
+}
+
+static XSM_DEFAULT(int, evtchn_interdomain) (struct domain *d1, struct evtchn
+                                *chan1, struct domain *d2, struct evtchn *chan2)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(void, evtchn_close_post) (struct evtchn *chn)
+{
+    return;
+}
+
+static XSM_DEFAULT(int, evtchn_send) (struct domain *d, struct evtchn *chn)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, evtchn_status) (struct domain *d, struct evtchn *chn)
+{
+    if ( current->domain != d && !IS_PRIV_FOR(current->domain, d) )
+        return -EPERM;
+    return 0;
+}
+
+static XSM_DEFAULT(int, evtchn_reset) (struct domain *d1, struct domain *d2)
+{
+    if ( d1 != d2 && !IS_PRIV_FOR(d1, d2) )
+        return -EPERM;
+    return 0;
+}
+
+static XSM_DEFAULT(int, alloc_security_evtchn) (struct evtchn *chn)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(void, free_security_evtchn) (struct evtchn *chn)
+{
+    return;
+}
+
+static XSM_DEFAULT(char *, show_security_evtchn) (struct domain *d, const struct evtchn *chn)
+{
+    return NULL;
+}
+
+static XSM_DEFAULT(int, get_pod_target)(struct domain *d)
+{
+    if ( !IS_PRIV(current->domain) )
+        return -EPERM;
+    return 0;
+}
+
+static XSM_DEFAULT(int, set_pod_target)(struct domain *d)
+{
+    if ( !IS_PRIV(current->domain) )
+        return -EPERM;
+    return 0;
+}
+
+static XSM_DEFAULT(int, get_device_group) (uint32_t machine_bdf)
+{
+    if ( !IS_PRIV(current->domain) )
+        return -EPERM;
+    return 0;
+}
+
+static XSM_DEFAULT(int, test_assign_device) (uint32_t machine_bdf)
+{
+    if ( !IS_PRIV(current->domain) )
+        return -EPERM;
+    return 0;
+}
+
+static XSM_DEFAULT(int, assign_device) (struct domain *d, uint32_t machine_bdf)
+{
+    if ( !IS_PRIV(current->domain) )
+        return -EPERM;
+    return 0;
+}
+
+static XSM_DEFAULT(int, deassign_device) (struct domain *d, uint32_t machine_bdf)
+{
+    if ( !IS_PRIV(current->domain) )
+        return -EPERM;
+    return 0;
+}
+
+static XSM_DEFAULT(int, resource_plug_core) (void)
+{
+    if ( !IS_PRIV(current->domain) )
+        return -EPERM;
+    return 0;
+}
+
+static XSM_DEFAULT(int, resource_unplug_core) (void)
+{
+    if ( !IS_PRIV(current->domain) )
+        return -EPERM;
+    return 0;
+}
+
+static XSM_DEFAULT(int, resource_plug_pci) (uint32_t machine_bdf)
+{
+    if ( !IS_PRIV(current->domain) )
+        return -EPERM;
+    return 0;
+}
+
+static XSM_DEFAULT(int, resource_unplug_pci) (uint32_t machine_bdf)
+{
+    if ( !IS_PRIV(current->domain) )
+        return -EPERM;
+    return 0;
+}
+
+static XSM_DEFAULT(int, resource_setup_pci) (uint32_t machine_bdf)
+{
+    if ( !IS_PRIV(current->domain) )
+        return -EPERM;
+    return 0;
+}
+
+static XSM_DEFAULT(int, resource_setup_gsi) (int gsi)
+{
+    if ( !IS_PRIV(current->domain) )
+        return -EPERM;
+    return 0;
+}
+
+static XSM_DEFAULT(int, resource_setup_misc) (void)
+{
+    if ( !IS_PRIV(current->domain) )
+        return -EPERM;
+    return 0;
+}
+
+static XSM_DEFAULT(int, page_offline) (uint32_t cmd)
+{
+    if ( !IS_PRIV(current->domain) )
+        return -EPERM;
+    return 0;
+}
+
+static XSM_DEFAULT(int, lockprof) (void)
+{
+    if ( !IS_PRIV(current->domain) )
+        return -EPERM;
+    return 0;
+}
+
+static XSM_DEFAULT(int, cpupool_op) (void)
+{
+    if ( !IS_PRIV(current->domain) )
+        return -EPERM;
+    return 0;
+}
+
+static XSM_DEFAULT(int, sched_op) (void)
+{
+    if ( !IS_PRIV(current->domain) )
+        return -EPERM;
+    return 0;
+}
+
+static XSM_DEFAULT(long, __do_xsm_op)(XEN_GUEST_HANDLE(xsm_op_t) op)
+{
+    return -ENOSYS;
+}
+
+static XSM_DEFAULT(char *, show_irq_sid) (int irq)
+{
+    return NULL;
+}
+
+static XSM_DEFAULT(int, map_domain_pirq) (struct domain *d, int irq, void *data)
+{
+    if ( !IS_PRIV_FOR(current->domain, d) )
+        return -EPERM;
+    return 0;
+}
+
+static XSM_DEFAULT(int, unmap_domain_pirq) (struct domain *d, int irq)
+{
+    if ( !IS_PRIV_FOR(current->domain, d) )
+        return -EPERM;
+    return 0;
+}
+
+static XSM_DEFAULT(int, irq_permission) (struct domain *d, int pirq, uint8_t allow)
+{
+    if ( !IS_PRIV(current->domain) )
+        return -EPERM;
+    return 0;
+}
+
+static XSM_DEFAULT(int, iomem_permission) (struct domain *d, uint64_t s, uint64_t e, uint8_t allow)
+{
+    if ( !IS_PRIV(current->domain) )
+        return -EPERM;
+    return 0;
+}
+
+static XSM_DEFAULT(int, iomem_mapping) (struct domain *d, uint64_t s, uint64_t e, uint8_t allow)
+{
+    if ( !IS_PRIV_FOR(current->domain, d) )
+        return -EPERM;
+    return 0;
+}
+
+static XSM_DEFAULT(int, pci_config_permission) (struct domain *d, uint32_t machine_bdf,
+                                        uint16_t start, uint16_t end,
+                                        uint8_t access)
+{
+    if ( !IS_PRIV(d) )
+        return -EPERM;
+    return 0;
+}
+
+#ifdef CONFIG_X86
+static XSM_DEFAULT(int, shadow_control) (struct domain *d, uint32_t op)
+{
+    if ( !IS_PRIV(current->domain) )
+        return -EPERM;
+    return 0;
+}
+
+static XSM_DEFAULT(int, getpageframeinfo) (struct domain *d)
+{
+    if ( !IS_PRIV(current->domain) )
+        return -EPERM;
+    return 0;
+}
+
+static XSM_DEFAULT(int, getmemlist) (struct domain *d)
+{
+    if ( !IS_PRIV(current->domain) )
+        return -EPERM;
+    return 0;
+}
+
+static XSM_DEFAULT(int, hypercall_init) (struct domain *d)
+{
+    if ( !IS_PRIV(current->domain) )
+        return -EPERM;
+    return 0;
+}
+
+static XSM_DEFAULT(int, hvmcontext) (struct domain *d, uint32_t cmd)
+{
+    if ( !IS_PRIV(current->domain) )
+        return -EPERM;
+    return 0;
+}
+
+static XSM_DEFAULT(int, address_size) (struct domain *d, uint32_t cmd)
+{
+    if ( !IS_PRIV(current->domain) )
+        return -EPERM;
+    return 0;
+}
+
+static XSM_DEFAULT(int, machine_address_size) (struct domain *d, uint32_t cmd)
+{
+    if ( !IS_PRIV(current->domain) )
+        return -EPERM;
+    return 0;
+}
+
+static XSM_DEFAULT(int, hvm_param) (struct domain *d, unsigned long op)
+{
+    if ( current->domain != d && !IS_PRIV_FOR(current->domain, d) )
+        return -EPERM;
+    return 0;
+}
+
+static XSM_DEFAULT(int, hvm_set_pci_intx_level) (struct domain *d)
+{
+    if ( !IS_PRIV_FOR(current->domain, d) )
+        return -EPERM;
+    return 0;
+}
+
+static XSM_DEFAULT(int, hvm_set_isa_irq_level) (struct domain *d)
+{
+    if ( !IS_PRIV_FOR(current->domain, d) )
+        return -EPERM;
+    return 0;
+}
+
+static XSM_DEFAULT(int, hvm_set_pci_link_route) (struct domain *d)
+{
+    if ( !IS_PRIV_FOR(current->domain, d) )
+        return -EPERM;
+    return 0;
+}
+
+static XSM_DEFAULT(int, hvm_inject_msi) (struct domain *d)
+{
+    if ( !IS_PRIV_FOR(current->domain, d) )
+        return -EPERM;
+    return 0;
+}
+
+static XSM_DEFAULT(int, mem_event) (struct domain *d)
+{
+    if ( !IS_PRIV(current->domain) )
+        return -EPERM;
+    return 0;
+}
+
+static XSM_DEFAULT(int, mem_sharing) (struct domain *d)
+{
+    if ( !IS_PRIV(current->domain) )
+        return -EPERM;
+    return 0;
+}
+
+static XSM_DEFAULT(int, apic) (struct domain *d, int cmd)
+{
+    if ( !IS_PRIV(current->domain) )
+        return -EPERM;
+    return 0;
+}
+
+static XSM_DEFAULT(int, xen_settime) (void)
+{
+    if ( !IS_PRIV(current->domain) )
+        return -EPERM;
+    return 0;
+}
+
+static XSM_DEFAULT(int, memtype) (uint32_t access)
+{
+    if ( !IS_PRIV(current->domain) )
+        return -EPERM;
+    return 0;
+}
+
+static XSM_DEFAULT(int, microcode) (void)
+{
+    if ( !IS_PRIV(current->domain) )
+        return -EPERM;
+    return 0;
+}
+
+static XSM_DEFAULT(int, physinfo) (void)
+{
+    if ( !IS_PRIV(current->domain) )
+        return -EPERM;
+    return 0;
+}
+
+static XSM_DEFAULT(int, platform_quirk) (uint32_t quirk)
+{
+    if ( !IS_PRIV(current->domain) )
+        return -EPERM;
+    return 0;
+}
+
+static XSM_DEFAULT(int, firmware_info) (void)
+{
+    if ( !IS_PRIV(current->domain) )
+        return -EPERM;
+    return 0;
+}
+
+static XSM_DEFAULT(int, efi_call) (void)
+{
+    if ( !IS_PRIV(current->domain) )
+        return -EPERM;
+    return 0;
+}
+
+static XSM_DEFAULT(int, acpi_sleep) (void)
+{
+    if ( !IS_PRIV(current->domain) )
+        return -EPERM;
+    return 0;
+}
+
+static XSM_DEFAULT(int, change_freq) (void)
+{
+    if ( !IS_PRIV(current->domain) )
+        return -EPERM;
+    return 0;
+}
+
+static XSM_DEFAULT(int, getidletime) (void)
+{
+    if ( !IS_PRIV(current->domain) )
+        return -EPERM;
+    return 0;
+}
+
+static XSM_DEFAULT(int, machine_memory_map) (void)
+{
+    if ( !IS_PRIV(current->domain) )
+        return -EPERM;
+    return 0;
+}
+
+static XSM_DEFAULT(int, domain_memory_map) (struct domain *d)
+{
+    if ( current->domain != d && !IS_PRIV_FOR(current->domain, d) )
+        return -EPERM;
+    return 0;
+}
+
+static XSM_DEFAULT(int, mmu_normal_update) (struct domain *d, struct domain *t,
+                                            struct domain *f, intpte_t fpte)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, mmu_machphys_update) (struct domain *d, struct domain *f,
+                                              unsigned long mfn)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, update_va_mapping) (struct domain *d, struct domain *f, 
+                                                            l1_pgentry_t pte)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, add_to_physmap) (struct domain *d1, struct domain *d2)
+{
+    if ( d1 != d2 && !IS_PRIV_FOR(d1, d2) )
+        return -EPERM;
+    return 0;
+}
+
+static XSM_DEFAULT(int, remove_from_physmap) (struct domain *d1, struct domain *d2)
+{
+    if ( d1 != d2 && !IS_PRIV_FOR(d1, d2) )
+        return -EPERM;
+    return 0;
+}
+
+static XSM_DEFAULT(int, sendtrigger) (struct domain *d)
+{
+    if ( !IS_PRIV(current->domain) )
+        return -EPERM;
+    return 0;
+}
+
+static XSM_DEFAULT(int, bind_pt_irq) (struct domain *d, struct xen_domctl_bind_pt_irq *bind)
+{
+    if ( !IS_PRIV_FOR(current->domain, d) )
+        return -EPERM;
+    return 0;
+}
+
+static XSM_DEFAULT(int, unbind_pt_irq) (struct domain *d, struct xen_domctl_bind_pt_irq *bind)
+{
+    if ( !IS_PRIV_FOR(current->domain, d) )
+        return -EPERM;
+    return 0;
+}
+
+static XSM_DEFAULT(int, pin_mem_cacheattr) (struct domain *d)
+{
+    if ( !IS_PRIV(current->domain) )
+        return -EPERM;
+    return 0;
+}
+
+static XSM_DEFAULT(int, ext_vcpucontext) (struct domain *d, uint32_t cmd)
+{
+    if ( !IS_PRIV(current->domain) )
+        return -EPERM;
+    return 0;
+}
+
+static XSM_DEFAULT(int, vcpuextstate) (struct domain *d, uint32_t cmd)
+{
+    if ( !IS_PRIV(current->domain) )
+        return -EPERM;
+    return 0;
+}
+
+static XSM_DEFAULT(int, ioport_permission) (struct domain *d, uint32_t s, uint32_t e, uint8_t allow)
+{
+    if ( !IS_PRIV(current->domain) )
+        return -EPERM;
+    return 0;
+}
+
+static XSM_DEFAULT(int, ioport_mapping) (struct domain *d, uint32_t s, uint32_t e, uint8_t allow)
+{
+    if ( !IS_PRIV_FOR(current->domain, d) )
+        return -EPERM;
+    return 0;
+}
+
+#endif
diff --git a/xen/include/xsm/xsm.h b/xen/include/xsm/xsm.h
index cbbe673..6095a86 100644
--- a/xen/include/xsm/xsm.h
+++ b/xen/include/xsm/xsm.h
@@ -21,11 +21,7 @@
 typedef void xsm_op_t;
 DEFINE_XEN_GUEST_HANDLE(xsm_op_t);
 
-#ifdef XSM_ENABLE
-    #define xsm_call(fn) xsm_ops->fn
-#else
-    #define xsm_call(fn) 0
-#endif
+#define xsm_call(fn) xsm_ops->fn
 
 /* policy magic number (defined by XSM_MAGIC) */
 typedef u32 xsm_magic_t;
@@ -187,8 +183,6 @@ struct xsm_operations {
 #endif
 };
 
-#endif
-
 extern struct xsm_operations *xsm_ops;
 
 static inline void xsm_security_domaininfo (struct domain *d,
@@ -598,32 +592,11 @@ static inline int xsm_sched_op(void)
     return xsm_call(sched_op());
 }
 
-static inline long __do_xsm_op (XEN_GUEST_HANDLE(xsm_op_t) op)
+static inline long xsm___do_xsm_op (XEN_GUEST_HANDLE(xsm_op_t) op)
 {
-#ifdef XSM_ENABLE
     return xsm_ops->__do_xsm_op(op);
-#else
-    return -ENOSYS;
-#endif
 }
 
-#ifdef XSM_ENABLE
-extern int xsm_init(unsigned long *module_map, const multiboot_info_t *mbi,
-                    void *(*bootstrap_map)(const module_t *));
-extern int xsm_policy_init(unsigned long *module_map,
-                           const multiboot_info_t *mbi,
-                           void *(*bootstrap_map)(const module_t *));
-extern int register_xsm(struct xsm_operations *ops);
-extern int unregister_xsm(struct xsm_operations *ops);
-#else
-static inline int xsm_init (unsigned long *module_map,
-                            const multiboot_info_t *mbi,
-                            void *(*bootstrap_map)(const module_t *))
-{
-    return 0;
-}
-#endif
-
 #ifdef CONFIG_X86
 static inline int xsm_shadow_control (struct domain *d, uint32_t op)
 {
@@ -825,7 +798,28 @@ static inline int xsm_ioport_mapping (struct domain *d, uint32_t s, uint32_t e,
 }
 #endif /* CONFIG_X86 */
 
+extern int xsm_init(unsigned long *module_map, const multiboot_info_t *mbi,
+                    void *(*bootstrap_map)(const module_t *));
+extern int xsm_policy_init(unsigned long *module_map,
+                           const multiboot_info_t *mbi,
+                           void *(*bootstrap_map)(const module_t *));
+extern int register_xsm(struct xsm_operations *ops);
+extern int unregister_xsm(struct xsm_operations *ops);
+
 extern struct xsm_operations dummy_xsm_ops;
 extern void xsm_fixup_ops(struct xsm_operations *ops);
 
+#else /* XSM_ENABLE */
+
+#define XSM_DEFAULT(type, name) inline type xsm_ ## name
+#include <xsm/dummy.h>
+
+static inline int xsm_init (unsigned long *module_map,
+                            const multiboot_info_t *mbi,
+                            void *(*bootstrap_map)(const module_t *))
+{
+    return 0;
+}
+#endif /* XSM_ENABLE */
+
 #endif /* __XSM_H */
diff --git a/xen/xsm/dummy.c b/xen/xsm/dummy.c
index a5dbfe7..af532b8 100644
--- a/xen/xsm/dummy.c
+++ b/xen/xsm/dummy.c
@@ -10,621 +10,8 @@
  *  as published by the Free Software Foundation.
  */
 
-#include <xen/sched.h>
-#include <xsm/xsm.h>
-
-static void dummy_security_domaininfo(struct domain *d,
-                                    struct xen_domctl_getdomaininfo *info)
-{
-    return;
-}
-
-static int dummy_setvcpucontext(struct domain *d)
-{
-    return 0;
-}
-
-static int dummy_pausedomain (struct domain *d)
-{
-    return 0;
-}
-
-static int dummy_unpausedomain (struct domain *d)
-{
-    return 0;
-}
-
-static int dummy_resumedomain (struct domain *d)
-{
-    return 0;
-}
-
-static int dummy_domain_create(struct domain *d, u32 ssidref)
-{
-    return 0;
-}
-
-static int dummy_max_vcpus(struct domain *d)
-{
-    return 0;
-}
-
-static int dummy_destroydomain (struct domain *d)
-{
-    return 0;
-}
-
-static int dummy_vcpuaffinity (int cmd, struct domain *d)
-{
-    return 0;
-}
-
-static int dummy_scheduler (struct domain *d)
-{
-    return 0;
-}
-
-static int dummy_getdomaininfo (struct domain *d)
-{
-    if ( !IS_PRIV(current->domain) )
-        return -EPERM;
-    return 0;
-}
-
-static int dummy_getvcpucontext (struct domain *d)
-{
-    return 0;
-}
-
-static int dummy_getvcpuinfo (struct domain *d)
-{
-    return 0;
-}
-
-static int dummy_domain_settime (struct domain *d)
-{
-    return 0;
-}
-
-static int dummy_set_target (struct domain *d, struct domain *e)
-{
-    return 0;
-}
-
-static int dummy_domctl(struct domain *d, int cmd)
-{
-    return 0;
-}
-
-static int dummy_set_virq_handler(struct domain *d, uint32_t virq)
-{
-    return 0;
-}
-
-static int dummy_tbufcontrol (void)
-{
-    return 0;
-}
-
-static int dummy_readconsole (uint32_t clear)
-{
-    return 0;
-}
-
-static int dummy_sched_id (void)
-{
-    return 0;
-}
-
-static int dummy_setdomainmaxmem (struct domain *d)
-{
-    return 0;
-}
-
-static int dummy_setdomainhandle (struct domain *d)
-{
-    return 0;
-}
-
-static int dummy_setdebugging (struct domain *d)
-{
-    return 0;
-}
-
-static int dummy_perfcontrol (void)
-{
-    return 0;
-}
-
-static int dummy_debug_keys (void)
-{
-    return 0;
-}
-
-static int dummy_getcpuinfo (void)
-{
-    return 0;
-}
-
-static int dummy_get_pmstat (void)
-{
-    return 0;
-}
-
-static int dummy_setpminfo (void)
-{
-    return 0;
-}
-
-static int dummy_pm_op (void)
-{
-    return 0;
-}
-
-static int dummy_do_mca (void)
-{
-    return 0;
-}
-
-static int dummy_availheap (void)
-{
-    return 0;
-}
-
-static int dummy_alloc_security_domain (struct domain *d)
-{
-    return 0;
-}
-
-static void dummy_free_security_domain (struct domain *d)
-{
-    return;
-}
-
-static int dummy_grant_mapref (struct domain *d1, struct domain *d2,
-                                                                uint32_t flags)
-{
-    return 0;
-}
-
-static int dummy_grant_unmapref (struct domain *d1, struct domain *d2)
-{
-    return 0;
-}
-
-static int dummy_grant_setup (struct domain *d1, struct domain *d2)
-{
-    return 0;
-}
-
-static int dummy_grant_transfer (struct domain *d1, struct domain *d2)
-{
-    return 0;
-}
-
-static int dummy_grant_copy (struct domain *d1, struct domain *d2)
-{
-    return 0;
-}
-
-static int dummy_grant_query_size (struct domain *d1, struct domain *d2)
-{
-    return 0;
-}
-
-static int dummy_memory_adjust_reservation (struct domain *d1,
-                                                            struct domain *d2)
-{
-    return 0;
-}
-
-static int dummy_memory_stat_reservation (struct domain *d1, struct domain *d2)
-{
-    return 0;
-}
-
-static int dummy_console_io (struct domain *d, int cmd)
-{
-    return 0;
-}
-
-static int dummy_profile (struct domain *d, int op)
-{
-    return 0;
-}
-
-static int dummy_kexec (void)
-{
-    return 0;
-}
-
-static int dummy_schedop_shutdown (struct domain *d1, struct domain *d2)
-{
-    return 0;
-}
-
-static int dummy_memory_pin_page(struct domain *d1, struct domain *d2, struct page_info *page)
-{
-    return 0;
-}
-
-static int dummy_evtchn_unbound (struct domain *d, struct evtchn *chn,
-                                                                    domid_t id2)
-{
-    return 0;
-}
-
-static int dummy_evtchn_interdomain (struct domain *d1, struct evtchn
-                                *chan1, struct domain *d2, struct evtchn *chan2)
-{
-    return 0;
-}
-
-static void dummy_evtchn_close_post (struct evtchn *chn)
-{
-    return;
-}
-
-static int dummy_evtchn_send (struct domain *d, struct evtchn *chn)
-{
-    return 0;
-}
-
-static int dummy_evtchn_status (struct domain *d, struct evtchn *chn)
-{
-    return 0;
-}
-
-static int dummy_evtchn_reset (struct domain *d1, struct domain *d2)
-{
-    return 0;
-}
-
-static int dummy_alloc_security_evtchn (struct evtchn *chn)
-{
-    return 0;
-}
-
-static void dummy_free_security_evtchn (struct evtchn *chn)
-{
-    return;
-}
-
-static char *dummy_show_security_evtchn (struct domain *d, const struct evtchn *chn)
-{
-    return NULL;
-}
-
-static int dummy_get_pod_target(struct domain *d)
-{
-    return 0;
-}
-
-static int dummy_set_pod_target(struct domain *d)
-{
-    return 0;
-}
-
-static int dummy_get_device_group (uint32_t machine_bdf)
-{
-    return 0;
-}
-
-static int dummy_test_assign_device (uint32_t machine_bdf)
-{
-    return 0;
-}
-
-static int dummy_assign_device (struct domain *d, uint32_t machine_bdf)
-{
-    return 0;
-}
-
-static int dummy_deassign_device (struct domain *d, uint32_t machine_bdf)
-{
-    return 0;
-}
-
-static int dummy_resource_plug_core (void)
-{
-    return 0;
-}
-
-static int dummy_resource_unplug_core (void)
-{
-    return 0;
-}
-
-static int dummy_resource_plug_pci (uint32_t machine_bdf)
-{
-    return 0;
-}
-
-static int dummy_resource_unplug_pci (uint32_t machine_bdf)
-{
-    return 0;
-}
-
-static int dummy_resource_setup_pci (uint32_t machine_bdf)
-{
-    return 0;
-}
-
-static int dummy_resource_setup_gsi (int gsi)
-{
-    return 0;
-}
-
-static int dummy_resource_setup_misc (void)
-{
-    return 0;
-}
-
-static int dummy_page_offline (uint32_t cmd)
-{
-    return 0;
-}
-
-static int dummy_lockprof (void)
-{
-    return 0;
-}
-
-static int dummy_cpupool_op (void)
-{
-    return 0;
-}
-
-static int dummy_sched_op (void)
-{
-    return 0;
-}
-
-static long dummy___do_xsm_op(XEN_GUEST_HANDLE(xsm_op_t) op)
-{
-    return -ENOSYS;
-}
-
-static char *dummy_show_irq_sid (int irq)
-{
-    return NULL;
-}
-
-static int dummy_map_domain_pirq (struct domain *d, int irq, void *data)
-{
-    return 0;
-}
-
-static int dummy_unmap_domain_pirq (struct domain *d, int irq)
-{
-    return 0;
-}
-
-static int dummy_irq_permission (struct domain *d, int pirq, uint8_t allow)
-{
-    return 0;
-}
-
-static int dummy_iomem_permission (struct domain *d, uint64_t s, uint64_t e, uint8_t allow)
-{
-    return 0;
-}
-
-static int dummy_iomem_mapping (struct domain *d, uint64_t s, uint64_t e, uint8_t allow)
-{
-    return 0;
-}
-
-static int dummy_pci_config_permission (struct domain *d, uint32_t machine_bdf,
-                                        uint16_t start, uint16_t end,
-                                        uint8_t access)
-{
-    return 0;
-}
-
-#ifdef CONFIG_X86
-static int dummy_shadow_control (struct domain *d, uint32_t op)
-{
-    return 0;
-}
-
-static int dummy_getpageframeinfo (struct domain *d)
-{
-    return 0;
-}
-
-static int dummy_getmemlist (struct domain *d)
-{
-    return 0;
-}
-
-static int dummy_hypercall_init (struct domain *d)
-{
-    return 0;
-}
-
-static int dummy_hvmcontext (struct domain *d, uint32_t cmd)
-{
-    return 0;
-}
-
-static int dummy_address_size (struct domain *d, uint32_t cmd)
-{
-    return 0;
-}
-
-static int dummy_machine_address_size (struct domain *d, uint32_t cmd)
-{
-    return 0;
-}
-
-static int dummy_hvm_param (struct domain *d, unsigned long op)
-{
-    return 0;
-}
-
-static int dummy_hvm_set_pci_intx_level (struct domain *d)
-{
-    return 0;
-}
-
-static int dummy_hvm_set_isa_irq_level (struct domain *d)
-{
-    return 0;
-}
-
-static int dummy_hvm_set_pci_link_route (struct domain *d)
-{
-    return 0;
-}
-
-static int dummy_hvm_inject_msi (struct domain *d)
-{
-    return 0;
-}
-
-static int dummy_mem_event (struct domain *d)
-{
-    return 0;
-}
-
-static int dummy_mem_sharing (struct domain *d)
-{
-    return 0;
-}
-
-static int dummy_apic (struct domain *d, int cmd)
-{
-    return 0;
-}
-
-static int dummy_xen_settime (void)
-{
-    return 0;
-}
-
-static int dummy_memtype (uint32_t access)
-{
-    return 0;
-}
-
-static int dummy_microcode (void)
-{
-    return 0;
-}
-
-static int dummy_physinfo (void)
-{
-    return 0;
-}
-
-static int dummy_platform_quirk (uint32_t quirk)
-{
-    return 0;
-}
-
-static int dummy_firmware_info (void)
-{
-    return 0;
-}
-
-static int dummy_efi_call(void)
-{
-    return 0;
-}
-
-static int dummy_acpi_sleep (void)
-{
-    return 0;
-}
-
-static int dummy_change_freq (void)
-{
-    return 0;
-}
-
-static int dummy_getidletime (void)
-{
-    return 0;
-}
-
-static int dummy_machine_memory_map (void)
-{
-    return 0;
-}
-
-static int dummy_domain_memory_map (struct domain *d)
-{
-    return 0;
-}
-
-static int dummy_mmu_normal_update (struct domain *d, struct domain *t,
-                                    struct domain *f, intpte_t fpte)
-{
-    return 0;
-}
-
-static int dummy_mmu_machphys_update (struct domain *d, struct domain *f, unsigned long mfn)
-{
-    return 0;
-}
-
-static int dummy_update_va_mapping (struct domain *d, struct domain *f, 
-                                                            l1_pgentry_t pte)
-{
-    return 0;
-}
-
-static int dummy_add_to_physmap (struct domain *d1, struct domain *d2)
-{
-    return 0;
-}
-
-static int dummy_remove_from_physmap (struct domain *d1, struct domain *d2)
-{
-    return 0;
-}
-
-static int dummy_sendtrigger (struct domain *d)
-{
-    return 0;
-}
-
-static int dummy_bind_pt_irq (struct domain *d, struct xen_domctl_bind_pt_irq *bind)
-{
-    return 0;
-}
-
-static int dummy_unbind_pt_irq (struct domain *d, struct xen_domctl_bind_pt_irq *bind)
-{
-    return 0;
-}
-
-static int dummy_pin_mem_cacheattr (struct domain *d)
-{
-    return 0;
-}
-
-static int dummy_ext_vcpucontext (struct domain *d, uint32_t cmd)
-{
-    return 0;
-}
-
-static int dummy_vcpuextstate (struct domain *d, uint32_t cmd)
-{
-    return 0;
-}
-
-static int dummy_ioport_permission (struct domain *d, uint32_t s, uint32_t e, uint8_t allow)
-{
-    return 0;
-}
-
-static int dummy_ioport_mapping (struct domain *d, uint32_t s, uint32_t e, uint8_t allow)
-{
-    return 0;
-}
-#endif
+#define XSM_DEFAULT(type, name) type dummy_ ## name
+#include <xsm/dummy.h>
 
 struct xsm_operations dummy_xsm_ops;
 
diff --git a/xen/xsm/xsm_core.c b/xen/xsm/xsm_core.c
index 96c8669..c4c85c0 100644
--- a/xen/xsm/xsm_core.c
+++ b/xen/xsm/xsm_core.c
@@ -113,7 +113,7 @@ int unregister_xsm(struct xsm_operations *ops)
 
 long do_xsm_op (XEN_GUEST_HANDLE(xsm_op_t) op)
 {
-    return __do_xsm_op(op);
+    return xsm___do_xsm_op(op);
 }
 
 
-- 
1.7.11.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 10 19:49:56 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Sep 2012 19:49:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TB9zO-0001EA-Ta; Mon, 10 Sep 2012 19:49:46 +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 1TB9zM-0001A4-87
	for xen-devel@lists.xen.org; Mon, 10 Sep 2012 19:49:44 +0000
Received: from [85.158.143.99:27991] by server-2.bemta-4.messagelabs.com id
	A7/54-21239-7544E405; Mon, 10 Sep 2012 19:49:43 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-6.tower-216.messagelabs.com!1347306581!22574385!1
X-Originating-IP: [63.239.67.10]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16677 invoked from network); 10 Sep 2012 19:49:41 -0000
Received: from emvm-gh1-uea09.nsa.gov (HELO nsa.gov) (63.239.67.10)
	by server-6.tower-216.messagelabs.com with SMTP;
	10 Sep 2012 19:49:41 -0000
X-TM-IMSS-Message-ID: <3066d153000f2260@nsa.gov>
Received: from tarius.tycho.ncsc.mil ([144.51.3.1]) by nsa.gov
	([63.239.67.10]) with ESMTP (TREND IMSS SMTP Service 7.1) id
	3066d153000f2260 ; Mon, 10 Sep 2012 15:51: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 q8AJna3m027796; 
	Mon, 10 Sep 2012 15:49:39 -0400
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xen.org
Date: Mon, 10 Sep 2012 15:49:03 -0400
Message-Id: <1347306553-20980-11-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.11.4
In-Reply-To: <1347306553-20980-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1347306553-20980-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>, Keir Fraser <keir@xen.org>,
	Jan Beulich <jbeulich@suse.com>
Subject: [Xen-devel] [PATCH 10/20] xsm: Add IS_PRIV checks to dummy XSM
	module
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/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 copies IS_PRIV checks into the dummy XSM hooks and makes the
dummy hooks the default implementation instead of always returning zero.
This patch should not change any functionality regardless of the state
of XSM_ENABLE; these newly introduced duplicate checks will be resolved
in the next patch.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Cc: Keir Fraser <keir@xen.org>
Cc: Jan Beulich <jbeulich@suse.com>
---
 xen/include/xsm/dummy.h | 828 ++++++++++++++++++++++++++++++++++++++++++++++++
 xen/include/xsm/xsm.h   |  52 ++-
 xen/xsm/dummy.c         | 617 +-----------------------------------
 xen/xsm/xsm_core.c      |   2 +-
 4 files changed, 854 insertions(+), 645 deletions(-)
 create mode 100644 xen/include/xsm/dummy.h

diff --git a/xen/include/xsm/dummy.h b/xen/include/xsm/dummy.h
new file mode 100644
index 0000000..3f5d9b0
--- /dev/null
+++ b/xen/include/xsm/dummy.h
@@ -0,0 +1,828 @@
+/*
+ *  Default XSM hooks - IS_PRIV and IS_PRIV_FOR checks
+ *
+ *  Author: Daniel De Graaf <dgdegra@tyhco.nsa.gov>
+ *
+ *  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.
+ */
+
+#include <xen/sched.h>
+#include <xsm/xsm.h>
+
+static XSM_DEFAULT(void, security_domaininfo)(struct domain *d,
+                                    struct xen_domctl_getdomaininfo *info)
+{
+    return;
+}
+
+static XSM_DEFAULT(int, setvcpucontext)(struct domain *d)
+{
+    if ( !IS_PRIV(current->domain) )
+        return -EPERM;
+    return 0;
+}
+
+static XSM_DEFAULT(int, pausedomain) (struct domain *d)
+{
+    if ( !IS_PRIV(current->domain) )
+        return -EPERM;
+    return 0;
+}
+
+static XSM_DEFAULT(int, unpausedomain) (struct domain *d)
+{
+    if ( !IS_PRIV(current->domain) )
+        return -EPERM;
+    return 0;
+}
+
+static XSM_DEFAULT(int, resumedomain) (struct domain *d)
+{
+    if ( !IS_PRIV(current->domain) )
+        return -EPERM;
+    return 0;
+}
+
+static XSM_DEFAULT(int, domain_create)(struct domain *d, u32 ssidref)
+{
+    if ( !IS_PRIV(current->domain) )
+        return -EPERM;
+    return 0;
+}
+
+static XSM_DEFAULT(int, max_vcpus)(struct domain *d)
+{
+    if ( !IS_PRIV(current->domain) )
+        return -EPERM;
+    return 0;
+}
+
+static XSM_DEFAULT(int, destroydomain) (struct domain *d)
+{
+    if ( !IS_PRIV(current->domain) )
+        return -EPERM;
+    return 0;
+}
+
+static XSM_DEFAULT(int, vcpuaffinity) (int cmd, struct domain *d)
+{
+    if ( !IS_PRIV(current->domain) )
+        return -EPERM;
+    return 0;
+}
+
+static XSM_DEFAULT(int, scheduler) (struct domain *d)
+{
+    if ( !IS_PRIV(current->domain) )
+        return -EPERM;
+    return 0;
+}
+
+static XSM_DEFAULT(int, getdomaininfo) (struct domain *d)
+{
+    if ( !IS_PRIV(current->domain) )
+        return -EPERM;
+    return 0;
+}
+
+static XSM_DEFAULT(int, getvcpucontext) (struct domain *d)
+{
+    if ( !IS_PRIV(current->domain) )
+        return -EPERM;
+    return 0;
+}
+
+static XSM_DEFAULT(int, getvcpuinfo) (struct domain *d)
+{
+    if ( !IS_PRIV(current->domain) )
+        return -EPERM;
+    return 0;
+}
+
+static XSM_DEFAULT(int, domain_settime) (struct domain *d)
+{
+    if ( !IS_PRIV(current->domain) )
+        return -EPERM;
+    return 0;
+}
+
+static XSM_DEFAULT(int, set_target) (struct domain *d, struct domain *e)
+{
+    if ( !IS_PRIV(current->domain) )
+        return -EPERM;
+    return 0;
+}
+
+static XSM_DEFAULT(int, domctl)(struct domain *d, int cmd)
+{
+    if ( !IS_PRIV(current->domain) )
+        return -EPERM;
+    return 0;
+}
+
+static XSM_DEFAULT(int, set_virq_handler)(struct domain *d, uint32_t virq)
+{
+    if ( !IS_PRIV(current->domain) )
+        return -EPERM;
+    return 0;
+}
+
+static XSM_DEFAULT(int, tbufcontrol) (void)
+{
+    if ( !IS_PRIV(current->domain) )
+        return -EPERM;
+    return 0;
+}
+
+static XSM_DEFAULT(int, readconsole) (uint32_t clear)
+{
+    if ( !IS_PRIV(current->domain) )
+        return -EPERM;
+    return 0;
+}
+
+static XSM_DEFAULT(int, sched_id) (void)
+{
+    if ( !IS_PRIV(current->domain) )
+        return -EPERM;
+    return 0;
+}
+
+static XSM_DEFAULT(int, setdomainmaxmem) (struct domain *d)
+{
+    if ( !IS_PRIV(current->domain) )
+        return -EPERM;
+    return 0;
+}
+
+static XSM_DEFAULT(int, setdomainhandle) (struct domain *d)
+{
+    if ( !IS_PRIV(current->domain) )
+        return -EPERM;
+    return 0;
+}
+
+static XSM_DEFAULT(int, setdebugging) (struct domain *d)
+{
+    if ( !IS_PRIV(current->domain) )
+        return -EPERM;
+    return 0;
+}
+
+static XSM_DEFAULT(int, perfcontrol) (void)
+{
+    if ( !IS_PRIV(current->domain) )
+        return -EPERM;
+    return 0;
+}
+
+static XSM_DEFAULT(int, debug_keys) (void)
+{
+    if ( !IS_PRIV(current->domain) )
+        return -EPERM;
+    return 0;
+}
+
+static XSM_DEFAULT(int, getcpuinfo) (void)
+{
+    if ( !IS_PRIV(current->domain) )
+        return -EPERM;
+    return 0;
+}
+
+static XSM_DEFAULT(int, get_pmstat) (void)
+{
+    if ( !IS_PRIV(current->domain) )
+        return -EPERM;
+    return 0;
+}
+
+static XSM_DEFAULT(int, setpminfo) (void)
+{
+    if ( !IS_PRIV(current->domain) )
+        return -EPERM;
+    return 0;
+}
+
+static XSM_DEFAULT(int, pm_op) (void)
+{
+    if ( !IS_PRIV(current->domain) )
+        return -EPERM;
+    return 0;
+}
+
+static XSM_DEFAULT(int, do_mca) (void)
+{
+    if ( !IS_PRIV(current->domain) )
+        return -EPERM;
+    return 0;
+}
+
+static XSM_DEFAULT(int, availheap) (void)
+{
+    if ( !IS_PRIV(current->domain) )
+        return -EPERM;
+    return 0;
+}
+
+static XSM_DEFAULT(int, alloc_security_domain) (struct domain *d)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(void, free_security_domain) (struct domain *d)
+{
+    return;
+}
+
+static XSM_DEFAULT(int, grant_mapref) (struct domain *d1, struct domain *d2,
+                                                                uint32_t flags)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, grant_unmapref) (struct domain *d1, struct domain *d2)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, grant_setup) (struct domain *d1, struct domain *d2)
+{
+    if ( d1 != d2 && !IS_PRIV_FOR(d1, d2) )
+        return -EPERM;
+    return 0;
+}
+
+static XSM_DEFAULT(int, grant_transfer) (struct domain *d1, struct domain *d2)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, grant_copy) (struct domain *d1, struct domain *d2)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, grant_query_size) (struct domain *d1, struct domain *d2)
+{
+    if ( d1 != d2 && !IS_PRIV_FOR(d1, d2) )
+        return -EPERM;
+    return 0;
+}
+
+static XSM_DEFAULT(int, memory_adjust_reservation) (struct domain *d1,
+                                                            struct domain *d2)
+{
+    if ( d1 != d2 && !IS_PRIV_FOR(d1, d2) )
+        return -EPERM;
+    return 0;
+}
+
+static XSM_DEFAULT(int, memory_stat_reservation) (struct domain *d1, struct domain *d2)
+{
+    if ( !IS_PRIV_FOR(d1, d2) )
+        return -EPERM;
+    return 0;
+}
+
+static XSM_DEFAULT(int, console_io) (struct domain *d, int cmd)
+{
+#ifndef VERBOSE
+    if ( !IS_PRIV(current->domain) )
+        return -EPERM;
+#endif
+    return 0;
+}
+
+static XSM_DEFAULT(int, profile) (struct domain *d, int op)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, kexec) (void)
+{
+    if ( !IS_PRIV(current->domain) )
+        return -EPERM;
+    return 0;
+}
+
+static XSM_DEFAULT(int, schedop_shutdown) (struct domain *d1, struct domain *d2)
+{
+    if ( !IS_PRIV_FOR(d1, d2) )
+        return -EPERM;
+    return 0;
+}
+
+static XSM_DEFAULT(int, memory_pin_page) (struct domain *d1, struct domain *d2,
+                                          struct page_info *page)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, evtchn_unbound) (struct domain *d, struct evtchn *chn,
+                                         domid_t id2)
+{
+    if ( current->domain != d && !IS_PRIV_FOR(current->domain, d) )
+        return -EPERM;
+    return 0;
+}
+
+static XSM_DEFAULT(int, evtchn_interdomain) (struct domain *d1, struct evtchn
+                                *chan1, struct domain *d2, struct evtchn *chan2)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(void, evtchn_close_post) (struct evtchn *chn)
+{
+    return;
+}
+
+static XSM_DEFAULT(int, evtchn_send) (struct domain *d, struct evtchn *chn)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, evtchn_status) (struct domain *d, struct evtchn *chn)
+{
+    if ( current->domain != d && !IS_PRIV_FOR(current->domain, d) )
+        return -EPERM;
+    return 0;
+}
+
+static XSM_DEFAULT(int, evtchn_reset) (struct domain *d1, struct domain *d2)
+{
+    if ( d1 != d2 && !IS_PRIV_FOR(d1, d2) )
+        return -EPERM;
+    return 0;
+}
+
+static XSM_DEFAULT(int, alloc_security_evtchn) (struct evtchn *chn)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(void, free_security_evtchn) (struct evtchn *chn)
+{
+    return;
+}
+
+static XSM_DEFAULT(char *, show_security_evtchn) (struct domain *d, const struct evtchn *chn)
+{
+    return NULL;
+}
+
+static XSM_DEFAULT(int, get_pod_target)(struct domain *d)
+{
+    if ( !IS_PRIV(current->domain) )
+        return -EPERM;
+    return 0;
+}
+
+static XSM_DEFAULT(int, set_pod_target)(struct domain *d)
+{
+    if ( !IS_PRIV(current->domain) )
+        return -EPERM;
+    return 0;
+}
+
+static XSM_DEFAULT(int, get_device_group) (uint32_t machine_bdf)
+{
+    if ( !IS_PRIV(current->domain) )
+        return -EPERM;
+    return 0;
+}
+
+static XSM_DEFAULT(int, test_assign_device) (uint32_t machine_bdf)
+{
+    if ( !IS_PRIV(current->domain) )
+        return -EPERM;
+    return 0;
+}
+
+static XSM_DEFAULT(int, assign_device) (struct domain *d, uint32_t machine_bdf)
+{
+    if ( !IS_PRIV(current->domain) )
+        return -EPERM;
+    return 0;
+}
+
+static XSM_DEFAULT(int, deassign_device) (struct domain *d, uint32_t machine_bdf)
+{
+    if ( !IS_PRIV(current->domain) )
+        return -EPERM;
+    return 0;
+}
+
+static XSM_DEFAULT(int, resource_plug_core) (void)
+{
+    if ( !IS_PRIV(current->domain) )
+        return -EPERM;
+    return 0;
+}
+
+static XSM_DEFAULT(int, resource_unplug_core) (void)
+{
+    if ( !IS_PRIV(current->domain) )
+        return -EPERM;
+    return 0;
+}
+
+static XSM_DEFAULT(int, resource_plug_pci) (uint32_t machine_bdf)
+{
+    if ( !IS_PRIV(current->domain) )
+        return -EPERM;
+    return 0;
+}
+
+static XSM_DEFAULT(int, resource_unplug_pci) (uint32_t machine_bdf)
+{
+    if ( !IS_PRIV(current->domain) )
+        return -EPERM;
+    return 0;
+}
+
+static XSM_DEFAULT(int, resource_setup_pci) (uint32_t machine_bdf)
+{
+    if ( !IS_PRIV(current->domain) )
+        return -EPERM;
+    return 0;
+}
+
+static XSM_DEFAULT(int, resource_setup_gsi) (int gsi)
+{
+    if ( !IS_PRIV(current->domain) )
+        return -EPERM;
+    return 0;
+}
+
+static XSM_DEFAULT(int, resource_setup_misc) (void)
+{
+    if ( !IS_PRIV(current->domain) )
+        return -EPERM;
+    return 0;
+}
+
+static XSM_DEFAULT(int, page_offline) (uint32_t cmd)
+{
+    if ( !IS_PRIV(current->domain) )
+        return -EPERM;
+    return 0;
+}
+
+static XSM_DEFAULT(int, lockprof) (void)
+{
+    if ( !IS_PRIV(current->domain) )
+        return -EPERM;
+    return 0;
+}
+
+static XSM_DEFAULT(int, cpupool_op) (void)
+{
+    if ( !IS_PRIV(current->domain) )
+        return -EPERM;
+    return 0;
+}
+
+static XSM_DEFAULT(int, sched_op) (void)
+{
+    if ( !IS_PRIV(current->domain) )
+        return -EPERM;
+    return 0;
+}
+
+static XSM_DEFAULT(long, __do_xsm_op)(XEN_GUEST_HANDLE(xsm_op_t) op)
+{
+    return -ENOSYS;
+}
+
+static XSM_DEFAULT(char *, show_irq_sid) (int irq)
+{
+    return NULL;
+}
+
+static XSM_DEFAULT(int, map_domain_pirq) (struct domain *d, int irq, void *data)
+{
+    if ( !IS_PRIV_FOR(current->domain, d) )
+        return -EPERM;
+    return 0;
+}
+
+static XSM_DEFAULT(int, unmap_domain_pirq) (struct domain *d, int irq)
+{
+    if ( !IS_PRIV_FOR(current->domain, d) )
+        return -EPERM;
+    return 0;
+}
+
+static XSM_DEFAULT(int, irq_permission) (struct domain *d, int pirq, uint8_t allow)
+{
+    if ( !IS_PRIV(current->domain) )
+        return -EPERM;
+    return 0;
+}
+
+static XSM_DEFAULT(int, iomem_permission) (struct domain *d, uint64_t s, uint64_t e, uint8_t allow)
+{
+    if ( !IS_PRIV(current->domain) )
+        return -EPERM;
+    return 0;
+}
+
+static XSM_DEFAULT(int, iomem_mapping) (struct domain *d, uint64_t s, uint64_t e, uint8_t allow)
+{
+    if ( !IS_PRIV_FOR(current->domain, d) )
+        return -EPERM;
+    return 0;
+}
+
+static XSM_DEFAULT(int, pci_config_permission) (struct domain *d, uint32_t machine_bdf,
+                                        uint16_t start, uint16_t end,
+                                        uint8_t access)
+{
+    if ( !IS_PRIV(d) )
+        return -EPERM;
+    return 0;
+}
+
+#ifdef CONFIG_X86
+static XSM_DEFAULT(int, shadow_control) (struct domain *d, uint32_t op)
+{
+    if ( !IS_PRIV(current->domain) )
+        return -EPERM;
+    return 0;
+}
+
+static XSM_DEFAULT(int, getpageframeinfo) (struct domain *d)
+{
+    if ( !IS_PRIV(current->domain) )
+        return -EPERM;
+    return 0;
+}
+
+static XSM_DEFAULT(int, getmemlist) (struct domain *d)
+{
+    if ( !IS_PRIV(current->domain) )
+        return -EPERM;
+    return 0;
+}
+
+static XSM_DEFAULT(int, hypercall_init) (struct domain *d)
+{
+    if ( !IS_PRIV(current->domain) )
+        return -EPERM;
+    return 0;
+}
+
+static XSM_DEFAULT(int, hvmcontext) (struct domain *d, uint32_t cmd)
+{
+    if ( !IS_PRIV(current->domain) )
+        return -EPERM;
+    return 0;
+}
+
+static XSM_DEFAULT(int, address_size) (struct domain *d, uint32_t cmd)
+{
+    if ( !IS_PRIV(current->domain) )
+        return -EPERM;
+    return 0;
+}
+
+static XSM_DEFAULT(int, machine_address_size) (struct domain *d, uint32_t cmd)
+{
+    if ( !IS_PRIV(current->domain) )
+        return -EPERM;
+    return 0;
+}
+
+static XSM_DEFAULT(int, hvm_param) (struct domain *d, unsigned long op)
+{
+    if ( current->domain != d && !IS_PRIV_FOR(current->domain, d) )
+        return -EPERM;
+    return 0;
+}
+
+static XSM_DEFAULT(int, hvm_set_pci_intx_level) (struct domain *d)
+{
+    if ( !IS_PRIV_FOR(current->domain, d) )
+        return -EPERM;
+    return 0;
+}
+
+static XSM_DEFAULT(int, hvm_set_isa_irq_level) (struct domain *d)
+{
+    if ( !IS_PRIV_FOR(current->domain, d) )
+        return -EPERM;
+    return 0;
+}
+
+static XSM_DEFAULT(int, hvm_set_pci_link_route) (struct domain *d)
+{
+    if ( !IS_PRIV_FOR(current->domain, d) )
+        return -EPERM;
+    return 0;
+}
+
+static XSM_DEFAULT(int, hvm_inject_msi) (struct domain *d)
+{
+    if ( !IS_PRIV_FOR(current->domain, d) )
+        return -EPERM;
+    return 0;
+}
+
+static XSM_DEFAULT(int, mem_event) (struct domain *d)
+{
+    if ( !IS_PRIV(current->domain) )
+        return -EPERM;
+    return 0;
+}
+
+static XSM_DEFAULT(int, mem_sharing) (struct domain *d)
+{
+    if ( !IS_PRIV(current->domain) )
+        return -EPERM;
+    return 0;
+}
+
+static XSM_DEFAULT(int, apic) (struct domain *d, int cmd)
+{
+    if ( !IS_PRIV(current->domain) )
+        return -EPERM;
+    return 0;
+}
+
+static XSM_DEFAULT(int, xen_settime) (void)
+{
+    if ( !IS_PRIV(current->domain) )
+        return -EPERM;
+    return 0;
+}
+
+static XSM_DEFAULT(int, memtype) (uint32_t access)
+{
+    if ( !IS_PRIV(current->domain) )
+        return -EPERM;
+    return 0;
+}
+
+static XSM_DEFAULT(int, microcode) (void)
+{
+    if ( !IS_PRIV(current->domain) )
+        return -EPERM;
+    return 0;
+}
+
+static XSM_DEFAULT(int, physinfo) (void)
+{
+    if ( !IS_PRIV(current->domain) )
+        return -EPERM;
+    return 0;
+}
+
+static XSM_DEFAULT(int, platform_quirk) (uint32_t quirk)
+{
+    if ( !IS_PRIV(current->domain) )
+        return -EPERM;
+    return 0;
+}
+
+static XSM_DEFAULT(int, firmware_info) (void)
+{
+    if ( !IS_PRIV(current->domain) )
+        return -EPERM;
+    return 0;
+}
+
+static XSM_DEFAULT(int, efi_call) (void)
+{
+    if ( !IS_PRIV(current->domain) )
+        return -EPERM;
+    return 0;
+}
+
+static XSM_DEFAULT(int, acpi_sleep) (void)
+{
+    if ( !IS_PRIV(current->domain) )
+        return -EPERM;
+    return 0;
+}
+
+static XSM_DEFAULT(int, change_freq) (void)
+{
+    if ( !IS_PRIV(current->domain) )
+        return -EPERM;
+    return 0;
+}
+
+static XSM_DEFAULT(int, getidletime) (void)
+{
+    if ( !IS_PRIV(current->domain) )
+        return -EPERM;
+    return 0;
+}
+
+static XSM_DEFAULT(int, machine_memory_map) (void)
+{
+    if ( !IS_PRIV(current->domain) )
+        return -EPERM;
+    return 0;
+}
+
+static XSM_DEFAULT(int, domain_memory_map) (struct domain *d)
+{
+    if ( current->domain != d && !IS_PRIV_FOR(current->domain, d) )
+        return -EPERM;
+    return 0;
+}
+
+static XSM_DEFAULT(int, mmu_normal_update) (struct domain *d, struct domain *t,
+                                            struct domain *f, intpte_t fpte)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, mmu_machphys_update) (struct domain *d, struct domain *f,
+                                              unsigned long mfn)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, update_va_mapping) (struct domain *d, struct domain *f, 
+                                                            l1_pgentry_t pte)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, add_to_physmap) (struct domain *d1, struct domain *d2)
+{
+    if ( d1 != d2 && !IS_PRIV_FOR(d1, d2) )
+        return -EPERM;
+    return 0;
+}
+
+static XSM_DEFAULT(int, remove_from_physmap) (struct domain *d1, struct domain *d2)
+{
+    if ( d1 != d2 && !IS_PRIV_FOR(d1, d2) )
+        return -EPERM;
+    return 0;
+}
+
+static XSM_DEFAULT(int, sendtrigger) (struct domain *d)
+{
+    if ( !IS_PRIV(current->domain) )
+        return -EPERM;
+    return 0;
+}
+
+static XSM_DEFAULT(int, bind_pt_irq) (struct domain *d, struct xen_domctl_bind_pt_irq *bind)
+{
+    if ( !IS_PRIV_FOR(current->domain, d) )
+        return -EPERM;
+    return 0;
+}
+
+static XSM_DEFAULT(int, unbind_pt_irq) (struct domain *d, struct xen_domctl_bind_pt_irq *bind)
+{
+    if ( !IS_PRIV_FOR(current->domain, d) )
+        return -EPERM;
+    return 0;
+}
+
+static XSM_DEFAULT(int, pin_mem_cacheattr) (struct domain *d)
+{
+    if ( !IS_PRIV(current->domain) )
+        return -EPERM;
+    return 0;
+}
+
+static XSM_DEFAULT(int, ext_vcpucontext) (struct domain *d, uint32_t cmd)
+{
+    if ( !IS_PRIV(current->domain) )
+        return -EPERM;
+    return 0;
+}
+
+static XSM_DEFAULT(int, vcpuextstate) (struct domain *d, uint32_t cmd)
+{
+    if ( !IS_PRIV(current->domain) )
+        return -EPERM;
+    return 0;
+}
+
+static XSM_DEFAULT(int, ioport_permission) (struct domain *d, uint32_t s, uint32_t e, uint8_t allow)
+{
+    if ( !IS_PRIV(current->domain) )
+        return -EPERM;
+    return 0;
+}
+
+static XSM_DEFAULT(int, ioport_mapping) (struct domain *d, uint32_t s, uint32_t e, uint8_t allow)
+{
+    if ( !IS_PRIV_FOR(current->domain, d) )
+        return -EPERM;
+    return 0;
+}
+
+#endif
diff --git a/xen/include/xsm/xsm.h b/xen/include/xsm/xsm.h
index cbbe673..6095a86 100644
--- a/xen/include/xsm/xsm.h
+++ b/xen/include/xsm/xsm.h
@@ -21,11 +21,7 @@
 typedef void xsm_op_t;
 DEFINE_XEN_GUEST_HANDLE(xsm_op_t);
 
-#ifdef XSM_ENABLE
-    #define xsm_call(fn) xsm_ops->fn
-#else
-    #define xsm_call(fn) 0
-#endif
+#define xsm_call(fn) xsm_ops->fn
 
 /* policy magic number (defined by XSM_MAGIC) */
 typedef u32 xsm_magic_t;
@@ -187,8 +183,6 @@ struct xsm_operations {
 #endif
 };
 
-#endif
-
 extern struct xsm_operations *xsm_ops;
 
 static inline void xsm_security_domaininfo (struct domain *d,
@@ -598,32 +592,11 @@ static inline int xsm_sched_op(void)
     return xsm_call(sched_op());
 }
 
-static inline long __do_xsm_op (XEN_GUEST_HANDLE(xsm_op_t) op)
+static inline long xsm___do_xsm_op (XEN_GUEST_HANDLE(xsm_op_t) op)
 {
-#ifdef XSM_ENABLE
     return xsm_ops->__do_xsm_op(op);
-#else
-    return -ENOSYS;
-#endif
 }
 
-#ifdef XSM_ENABLE
-extern int xsm_init(unsigned long *module_map, const multiboot_info_t *mbi,
-                    void *(*bootstrap_map)(const module_t *));
-extern int xsm_policy_init(unsigned long *module_map,
-                           const multiboot_info_t *mbi,
-                           void *(*bootstrap_map)(const module_t *));
-extern int register_xsm(struct xsm_operations *ops);
-extern int unregister_xsm(struct xsm_operations *ops);
-#else
-static inline int xsm_init (unsigned long *module_map,
-                            const multiboot_info_t *mbi,
-                            void *(*bootstrap_map)(const module_t *))
-{
-    return 0;
-}
-#endif
-
 #ifdef CONFIG_X86
 static inline int xsm_shadow_control (struct domain *d, uint32_t op)
 {
@@ -825,7 +798,28 @@ static inline int xsm_ioport_mapping (struct domain *d, uint32_t s, uint32_t e,
 }
 #endif /* CONFIG_X86 */
 
+extern int xsm_init(unsigned long *module_map, const multiboot_info_t *mbi,
+                    void *(*bootstrap_map)(const module_t *));
+extern int xsm_policy_init(unsigned long *module_map,
+                           const multiboot_info_t *mbi,
+                           void *(*bootstrap_map)(const module_t *));
+extern int register_xsm(struct xsm_operations *ops);
+extern int unregister_xsm(struct xsm_operations *ops);
+
 extern struct xsm_operations dummy_xsm_ops;
 extern void xsm_fixup_ops(struct xsm_operations *ops);
 
+#else /* XSM_ENABLE */
+
+#define XSM_DEFAULT(type, name) inline type xsm_ ## name
+#include <xsm/dummy.h>
+
+static inline int xsm_init (unsigned long *module_map,
+                            const multiboot_info_t *mbi,
+                            void *(*bootstrap_map)(const module_t *))
+{
+    return 0;
+}
+#endif /* XSM_ENABLE */
+
 #endif /* __XSM_H */
diff --git a/xen/xsm/dummy.c b/xen/xsm/dummy.c
index a5dbfe7..af532b8 100644
--- a/xen/xsm/dummy.c
+++ b/xen/xsm/dummy.c
@@ -10,621 +10,8 @@
  *  as published by the Free Software Foundation.
  */
 
-#include <xen/sched.h>
-#include <xsm/xsm.h>
-
-static void dummy_security_domaininfo(struct domain *d,
-                                    struct xen_domctl_getdomaininfo *info)
-{
-    return;
-}
-
-static int dummy_setvcpucontext(struct domain *d)
-{
-    return 0;
-}
-
-static int dummy_pausedomain (struct domain *d)
-{
-    return 0;
-}
-
-static int dummy_unpausedomain (struct domain *d)
-{
-    return 0;
-}
-
-static int dummy_resumedomain (struct domain *d)
-{
-    return 0;
-}
-
-static int dummy_domain_create(struct domain *d, u32 ssidref)
-{
-    return 0;
-}
-
-static int dummy_max_vcpus(struct domain *d)
-{
-    return 0;
-}
-
-static int dummy_destroydomain (struct domain *d)
-{
-    return 0;
-}
-
-static int dummy_vcpuaffinity (int cmd, struct domain *d)
-{
-    return 0;
-}
-
-static int dummy_scheduler (struct domain *d)
-{
-    return 0;
-}
-
-static int dummy_getdomaininfo (struct domain *d)
-{
-    if ( !IS_PRIV(current->domain) )
-        return -EPERM;
-    return 0;
-}
-
-static int dummy_getvcpucontext (struct domain *d)
-{
-    return 0;
-}
-
-static int dummy_getvcpuinfo (struct domain *d)
-{
-    return 0;
-}
-
-static int dummy_domain_settime (struct domain *d)
-{
-    return 0;
-}
-
-static int dummy_set_target (struct domain *d, struct domain *e)
-{
-    return 0;
-}
-
-static int dummy_domctl(struct domain *d, int cmd)
-{
-    return 0;
-}
-
-static int dummy_set_virq_handler(struct domain *d, uint32_t virq)
-{
-    return 0;
-}
-
-static int dummy_tbufcontrol (void)
-{
-    return 0;
-}
-
-static int dummy_readconsole (uint32_t clear)
-{
-    return 0;
-}
-
-static int dummy_sched_id (void)
-{
-    return 0;
-}
-
-static int dummy_setdomainmaxmem (struct domain *d)
-{
-    return 0;
-}
-
-static int dummy_setdomainhandle (struct domain *d)
-{
-    return 0;
-}
-
-static int dummy_setdebugging (struct domain *d)
-{
-    return 0;
-}
-
-static int dummy_perfcontrol (void)
-{
-    return 0;
-}
-
-static int dummy_debug_keys (void)
-{
-    return 0;
-}
-
-static int dummy_getcpuinfo (void)
-{
-    return 0;
-}
-
-static int dummy_get_pmstat (void)
-{
-    return 0;
-}
-
-static int dummy_setpminfo (void)
-{
-    return 0;
-}
-
-static int dummy_pm_op (void)
-{
-    return 0;
-}
-
-static int dummy_do_mca (void)
-{
-    return 0;
-}
-
-static int dummy_availheap (void)
-{
-    return 0;
-}
-
-static int dummy_alloc_security_domain (struct domain *d)
-{
-    return 0;
-}
-
-static void dummy_free_security_domain (struct domain *d)
-{
-    return;
-}
-
-static int dummy_grant_mapref (struct domain *d1, struct domain *d2,
-                                                                uint32_t flags)
-{
-    return 0;
-}
-
-static int dummy_grant_unmapref (struct domain *d1, struct domain *d2)
-{
-    return 0;
-}
-
-static int dummy_grant_setup (struct domain *d1, struct domain *d2)
-{
-    return 0;
-}
-
-static int dummy_grant_transfer (struct domain *d1, struct domain *d2)
-{
-    return 0;
-}
-
-static int dummy_grant_copy (struct domain *d1, struct domain *d2)
-{
-    return 0;
-}
-
-static int dummy_grant_query_size (struct domain *d1, struct domain *d2)
-{
-    return 0;
-}
-
-static int dummy_memory_adjust_reservation (struct domain *d1,
-                                                            struct domain *d2)
-{
-    return 0;
-}
-
-static int dummy_memory_stat_reservation (struct domain *d1, struct domain *d2)
-{
-    return 0;
-}
-
-static int dummy_console_io (struct domain *d, int cmd)
-{
-    return 0;
-}
-
-static int dummy_profile (struct domain *d, int op)
-{
-    return 0;
-}
-
-static int dummy_kexec (void)
-{
-    return 0;
-}
-
-static int dummy_schedop_shutdown (struct domain *d1, struct domain *d2)
-{
-    return 0;
-}
-
-static int dummy_memory_pin_page(struct domain *d1, struct domain *d2, struct page_info *page)
-{
-    return 0;
-}
-
-static int dummy_evtchn_unbound (struct domain *d, struct evtchn *chn,
-                                                                    domid_t id2)
-{
-    return 0;
-}
-
-static int dummy_evtchn_interdomain (struct domain *d1, struct evtchn
-                                *chan1, struct domain *d2, struct evtchn *chan2)
-{
-    return 0;
-}
-
-static void dummy_evtchn_close_post (struct evtchn *chn)
-{
-    return;
-}
-
-static int dummy_evtchn_send (struct domain *d, struct evtchn *chn)
-{
-    return 0;
-}
-
-static int dummy_evtchn_status (struct domain *d, struct evtchn *chn)
-{
-    return 0;
-}
-
-static int dummy_evtchn_reset (struct domain *d1, struct domain *d2)
-{
-    return 0;
-}
-
-static int dummy_alloc_security_evtchn (struct evtchn *chn)
-{
-    return 0;
-}
-
-static void dummy_free_security_evtchn (struct evtchn *chn)
-{
-    return;
-}
-
-static char *dummy_show_security_evtchn (struct domain *d, const struct evtchn *chn)
-{
-    return NULL;
-}
-
-static int dummy_get_pod_target(struct domain *d)
-{
-    return 0;
-}
-
-static int dummy_set_pod_target(struct domain *d)
-{
-    return 0;
-}
-
-static int dummy_get_device_group (uint32_t machine_bdf)
-{
-    return 0;
-}
-
-static int dummy_test_assign_device (uint32_t machine_bdf)
-{
-    return 0;
-}
-
-static int dummy_assign_device (struct domain *d, uint32_t machine_bdf)
-{
-    return 0;
-}
-
-static int dummy_deassign_device (struct domain *d, uint32_t machine_bdf)
-{
-    return 0;
-}
-
-static int dummy_resource_plug_core (void)
-{
-    return 0;
-}
-
-static int dummy_resource_unplug_core (void)
-{
-    return 0;
-}
-
-static int dummy_resource_plug_pci (uint32_t machine_bdf)
-{
-    return 0;
-}
-
-static int dummy_resource_unplug_pci (uint32_t machine_bdf)
-{
-    return 0;
-}
-
-static int dummy_resource_setup_pci (uint32_t machine_bdf)
-{
-    return 0;
-}
-
-static int dummy_resource_setup_gsi (int gsi)
-{
-    return 0;
-}
-
-static int dummy_resource_setup_misc (void)
-{
-    return 0;
-}
-
-static int dummy_page_offline (uint32_t cmd)
-{
-    return 0;
-}
-
-static int dummy_lockprof (void)
-{
-    return 0;
-}
-
-static int dummy_cpupool_op (void)
-{
-    return 0;
-}
-
-static int dummy_sched_op (void)
-{
-    return 0;
-}
-
-static long dummy___do_xsm_op(XEN_GUEST_HANDLE(xsm_op_t) op)
-{
-    return -ENOSYS;
-}
-
-static char *dummy_show_irq_sid (int irq)
-{
-    return NULL;
-}
-
-static int dummy_map_domain_pirq (struct domain *d, int irq, void *data)
-{
-    return 0;
-}
-
-static int dummy_unmap_domain_pirq (struct domain *d, int irq)
-{
-    return 0;
-}
-
-static int dummy_irq_permission (struct domain *d, int pirq, uint8_t allow)
-{
-    return 0;
-}
-
-static int dummy_iomem_permission (struct domain *d, uint64_t s, uint64_t e, uint8_t allow)
-{
-    return 0;
-}
-
-static int dummy_iomem_mapping (struct domain *d, uint64_t s, uint64_t e, uint8_t allow)
-{
-    return 0;
-}
-
-static int dummy_pci_config_permission (struct domain *d, uint32_t machine_bdf,
-                                        uint16_t start, uint16_t end,
-                                        uint8_t access)
-{
-    return 0;
-}
-
-#ifdef CONFIG_X86
-static int dummy_shadow_control (struct domain *d, uint32_t op)
-{
-    return 0;
-}
-
-static int dummy_getpageframeinfo (struct domain *d)
-{
-    return 0;
-}
-
-static int dummy_getmemlist (struct domain *d)
-{
-    return 0;
-}
-
-static int dummy_hypercall_init (struct domain *d)
-{
-    return 0;
-}
-
-static int dummy_hvmcontext (struct domain *d, uint32_t cmd)
-{
-    return 0;
-}
-
-static int dummy_address_size (struct domain *d, uint32_t cmd)
-{
-    return 0;
-}
-
-static int dummy_machine_address_size (struct domain *d, uint32_t cmd)
-{
-    return 0;
-}
-
-static int dummy_hvm_param (struct domain *d, unsigned long op)
-{
-    return 0;
-}
-
-static int dummy_hvm_set_pci_intx_level (struct domain *d)
-{
-    return 0;
-}
-
-static int dummy_hvm_set_isa_irq_level (struct domain *d)
-{
-    return 0;
-}
-
-static int dummy_hvm_set_pci_link_route (struct domain *d)
-{
-    return 0;
-}
-
-static int dummy_hvm_inject_msi (struct domain *d)
-{
-    return 0;
-}
-
-static int dummy_mem_event (struct domain *d)
-{
-    return 0;
-}
-
-static int dummy_mem_sharing (struct domain *d)
-{
-    return 0;
-}
-
-static int dummy_apic (struct domain *d, int cmd)
-{
-    return 0;
-}
-
-static int dummy_xen_settime (void)
-{
-    return 0;
-}
-
-static int dummy_memtype (uint32_t access)
-{
-    return 0;
-}
-
-static int dummy_microcode (void)
-{
-    return 0;
-}
-
-static int dummy_physinfo (void)
-{
-    return 0;
-}
-
-static int dummy_platform_quirk (uint32_t quirk)
-{
-    return 0;
-}
-
-static int dummy_firmware_info (void)
-{
-    return 0;
-}
-
-static int dummy_efi_call(void)
-{
-    return 0;
-}
-
-static int dummy_acpi_sleep (void)
-{
-    return 0;
-}
-
-static int dummy_change_freq (void)
-{
-    return 0;
-}
-
-static int dummy_getidletime (void)
-{
-    return 0;
-}
-
-static int dummy_machine_memory_map (void)
-{
-    return 0;
-}
-
-static int dummy_domain_memory_map (struct domain *d)
-{
-    return 0;
-}
-
-static int dummy_mmu_normal_update (struct domain *d, struct domain *t,
-                                    struct domain *f, intpte_t fpte)
-{
-    return 0;
-}
-
-static int dummy_mmu_machphys_update (struct domain *d, struct domain *f, unsigned long mfn)
-{
-    return 0;
-}
-
-static int dummy_update_va_mapping (struct domain *d, struct domain *f, 
-                                                            l1_pgentry_t pte)
-{
-    return 0;
-}
-
-static int dummy_add_to_physmap (struct domain *d1, struct domain *d2)
-{
-    return 0;
-}
-
-static int dummy_remove_from_physmap (struct domain *d1, struct domain *d2)
-{
-    return 0;
-}
-
-static int dummy_sendtrigger (struct domain *d)
-{
-    return 0;
-}
-
-static int dummy_bind_pt_irq (struct domain *d, struct xen_domctl_bind_pt_irq *bind)
-{
-    return 0;
-}
-
-static int dummy_unbind_pt_irq (struct domain *d, struct xen_domctl_bind_pt_irq *bind)
-{
-    return 0;
-}
-
-static int dummy_pin_mem_cacheattr (struct domain *d)
-{
-    return 0;
-}
-
-static int dummy_ext_vcpucontext (struct domain *d, uint32_t cmd)
-{
-    return 0;
-}
-
-static int dummy_vcpuextstate (struct domain *d, uint32_t cmd)
-{
-    return 0;
-}
-
-static int dummy_ioport_permission (struct domain *d, uint32_t s, uint32_t e, uint8_t allow)
-{
-    return 0;
-}
-
-static int dummy_ioport_mapping (struct domain *d, uint32_t s, uint32_t e, uint8_t allow)
-{
-    return 0;
-}
-#endif
+#define XSM_DEFAULT(type, name) type dummy_ ## name
+#include <xsm/dummy.h>
 
 struct xsm_operations dummy_xsm_ops;
 
diff --git a/xen/xsm/xsm_core.c b/xen/xsm/xsm_core.c
index 96c8669..c4c85c0 100644
--- a/xen/xsm/xsm_core.c
+++ b/xen/xsm/xsm_core.c
@@ -113,7 +113,7 @@ int unregister_xsm(struct xsm_operations *ops)
 
 long do_xsm_op (XEN_GUEST_HANDLE(xsm_op_t) op)
 {
-    return __do_xsm_op(op);
+    return xsm___do_xsm_op(op);
 }
 
 
-- 
1.7.11.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 10 19:49:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Sep 2012 19:49: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 1TB9zM-0001BC-3w; Mon, 10 Sep 2012 19:49:44 +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 1TB9zJ-00019P-SC
	for xen-devel@lists.xen.org; Mon, 10 Sep 2012 19:49:42 +0000
Received: from [85.158.138.51:12133] by server-9.bemta-3.messagelabs.com id
	A0/4A-15390-5544E405; Mon, 10 Sep 2012 19:49:41 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-4.tower-174.messagelabs.com!1347306579!29267702!1
X-Originating-IP: [63.239.67.9]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12823 invoked from network); 10 Sep 2012 19:49:40 -0000
Received: from emvm-gh1-uea08.nsa.gov (HELO nsa.gov) (63.239.67.9)
	by server-4.tower-174.messagelabs.com with SMTP;
	10 Sep 2012 19:49:40 -0000
X-TM-IMSS-Message-ID: <30670fca000ed1bf@nsa.gov>
Received: from tarius.tycho.ncsc.mil ([144.51.3.1]) by nsa.gov ([63.239.67.9])
	with ESMTP (TREND IMSS SMTP Service 7.1) id 30670fca000ed1bf ;
	Mon, 10 Sep 2012 15:49:34 -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 q8AJna3i027796; 
	Mon, 10 Sep 2012 15:49:38 -0400
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xen.org
Date: Mon, 10 Sep 2012 15:48:59 -0400
Message-Id: <1347306553-20980-7-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.11.4
In-Reply-To: <1347306553-20980-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1347306553-20980-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: [Xen-devel] [PATCH 06/20] flask/policy: Add domain relabel example
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This adds the nomigrate_t type to the example FLASK policy which allows
domains to be created that dom0 cannot access after building.

Example domain configuration snippet:
  seclabel='customer_1:vm_r:nomigrate_t'
  init_seclabel='customer_1:vm_r:nomigrate_t_building'

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 docs/misc/xsm-flask.txt                      |  2 +
 tools/flask/policy/policy/modules/xen/xen.if | 56 +++++++++++++++++++++-------
 tools/flask/policy/policy/modules/xen/xen.te | 10 +++++
 3 files changed, 55 insertions(+), 13 deletions(-)

diff --git a/docs/misc/xsm-flask.txt b/docs/misc/xsm-flask.txt
index 6b0d327..0778a28 100644
--- a/docs/misc/xsm-flask.txt
+++ b/docs/misc/xsm-flask.txt
@@ -60,6 +60,8 @@ that can be used without dom0 disaggregation. The main types for domUs are:
  - domU_t is a domain that can communicate with any other domU_t
  - isolated_domU_t can only communicate with dom0
  - prot_domU_t is a domain type whose creation can be disabled with a boolean
+ - nomigrate_t is a domain that must be created via the nomigrate_t_building
+   type, and whose memory cannot be read by dom0 once created
 
 HVM domains with stubdomain device models use two types (one per domain):
  - domHVM_t is an HVM domain that uses a stubdomain device model
diff --git a/tools/flask/policy/policy/modules/xen/xen.if b/tools/flask/policy/policy/modules/xen/xen.if
index 3f58909..2ad11b2 100644
--- a/tools/flask/policy/policy/modules/xen/xen.if
+++ b/tools/flask/policy/policy/modules/xen/xen.if
@@ -9,24 +9,47 @@
 #   Declare a type as a domain type, and allow basic domain setup
 define(`declare_domain', `
 	type $1, domain_type`'ifelse(`$#', `1', `', `,shift($@)');
+	type $1_channel, event_type;
+	type_transition $1 domain_type:event $1_channel;
 	allow $1 $1:grant { query setup };
 	allow $1 $1:mmu { adjust physmap map_read map_write stat pinpage };
 	allow $1 $1:hvm { getparam setparam };
 ')
 
-# create_domain(priv, target)
-#   Allow a domain to be created
-define(`create_domain', `
+# declare_build_label(type)
+#   Declare a paired _building type for the given domain type
+define(`declare_build_label', `
+	type $1_building, domain_type;
+	type_transition $1_building domain_type:event $1_channel;
+	allow $1_building $1 : domain transition;
+')
+
+define(`create_domain_common', `
 	allow $1 $2:domain { create max_vcpus setdomainmaxmem setaddrsize
-			getdomaininfo hypercall setvcpucontext scheduler
-			unpause getvcpuinfo getvcpuextstate getaddrsize
-			getvcpuaffinity };
+			getdomaininfo hypercall setvcpucontext setextvcpucontext
+			scheduler getvcpuinfo getvcpuextstate getaddrsize
+			getvcpuaffinity setvcpuaffinity };
 	allow $1 $2:security check_context;
 	allow $1 $2:shadow enable;
 	allow $1 $2:mmu {map_read map_write adjust memorymap physmap pinpage};
 	allow $1 $2:grant setup;
-	allow $1 $2:hvm { cacheattr getparam hvmctl irqlevel pciroute setparam pcilevel trackdirtyvram };
-	allow $1 $2_$1_channel:event create;
+	allow $1 $2:hvm { cacheattr getparam hvmctl irqlevel pciroute sethvmc setparam pcilevel trackdirtyvram };
+')
+
+# create_domain(priv, target)
+#   Allow a domain to be created directly
+define(`create_domain', `
+	create_domain_common($1, $2)
+	allow $1 $2_channel:event create;
+')
+
+# create_domain_build_label(priv, target)
+#   Allow a domain to be created via its domain build label
+define(`create_domain_build_label', `
+	create_domain_common($1, $2_building)
+	allow $1 $2_channel:event create;
+	allow $1 $2_building:domain2 relabelfrom;
+	allow $1 $2:domain2 relabelto;
 ')
 
 # manage_domain(priv, target)
@@ -37,6 +60,15 @@ define(`manage_domain', `
 			setvcpuaffinity setdomainmaxmem };
 ')
 
+# migrate_domain_out(priv, target)
+#   Allow creation of a snapshot or migration image from a domain
+#   (inbound migration is the same as domain creation)
+define(`migrate_domain_out', `
+	allow $1 $2:hvm { gethvmc getparam irqlevel };
+	allow $1 $2:mmu { stat pageinfo map_read };
+	allow $1 $2:domain { getaddrsize getvcpucontext getextvcpucontext getvcpuextstate pause destroy };
+')
+
 ################################################################################
 #
 # Inter-domain communication
@@ -47,8 +79,6 @@ define(`manage_domain', `
 #   This allows an event channel to be created from domains with labels
 #   <source> to <dest> and will label it <chan-label>
 define(`create_channel', `
-	type $3, event_type;
-	type_transition $1 $2:event $3;
 	allow $1 $3:event { create send status };
 	allow $3 $2:event { bind };
 ')
@@ -56,8 +86,8 @@ define(`create_channel', `
 # domain_event_comms(dom1, dom2)
 #   Allow two domain types to communicate using event channels
 define(`domain_event_comms', `
-	create_channel($1, $2, $1_$2_channel)
-	create_channel($2, $1, $2_$1_channel)
+	create_channel($1, $2, $1_channel)
+	create_channel($2, $1, $2_channel)
 ')
 
 # domain_comms(dom1, dom2)
@@ -72,7 +102,7 @@ define(`domain_comms', `
 #   Allow a domain types to communicate with others of its type using grants
 #   and event channels (this includes event channels to DOMID_SELF)
 define(`domain_self_comms', `
-	create_channel($1, $1, $1_self_channel)
+	create_channel($1, $1, $1_channel)
 	allow $1 $1:grant { map_read map_write copy unmap };
 ')
 
diff --git a/tools/flask/policy/policy/modules/xen/xen.te b/tools/flask/policy/policy/modules/xen/xen.te
index 9550397..1162153 100644
--- a/tools/flask/policy/policy/modules/xen/xen.te
+++ b/tools/flask/policy/policy/modules/xen/xen.te
@@ -90,6 +90,7 @@ create_domain(dom0_t, isolated_domU_t)
 manage_domain(dom0_t, isolated_domU_t)
 domain_comms(dom0_t, isolated_domU_t)
 
+# Declare a boolean that denies creation of prot_domU_t domains
 gen_bool(prot_doms_locked, false)
 declare_domain(prot_domU_t)
 if (!prot_doms_locked) {
@@ -111,6 +112,15 @@ manage_domain(dom0_t, dm_dom_t)
 domain_comms(dom0_t, dm_dom_t)
 device_model(dm_dom_t, domHVM_t)
 
+# nomigrate_t must be built via the nomigrate_t_building label; once built,
+# dom0 cannot read its memory.
+declare_domain(nomigrate_t)
+declare_build_label(nomigrate_t)
+create_domain_build_label(dom0_t, nomigrate_t)
+manage_domain(dom0_t, nomigrate_t)
+domain_comms(dom0_t, nomigrate_t)
+domain_self_comms(nomigrate_t)
+
 ###############################################################################
 #
 # Device delegation
-- 
1.7.11.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 10 19:49:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Sep 2012 19:49: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 1TB9zM-0001BC-3w; Mon, 10 Sep 2012 19:49:44 +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 1TB9zJ-00019P-SC
	for xen-devel@lists.xen.org; Mon, 10 Sep 2012 19:49:42 +0000
Received: from [85.158.138.51:12133] by server-9.bemta-3.messagelabs.com id
	A0/4A-15390-5544E405; Mon, 10 Sep 2012 19:49:41 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-4.tower-174.messagelabs.com!1347306579!29267702!1
X-Originating-IP: [63.239.67.9]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12823 invoked from network); 10 Sep 2012 19:49:40 -0000
Received: from emvm-gh1-uea08.nsa.gov (HELO nsa.gov) (63.239.67.9)
	by server-4.tower-174.messagelabs.com with SMTP;
	10 Sep 2012 19:49:40 -0000
X-TM-IMSS-Message-ID: <30670fca000ed1bf@nsa.gov>
Received: from tarius.tycho.ncsc.mil ([144.51.3.1]) by nsa.gov ([63.239.67.9])
	with ESMTP (TREND IMSS SMTP Service 7.1) id 30670fca000ed1bf ;
	Mon, 10 Sep 2012 15:49:34 -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 q8AJna3i027796; 
	Mon, 10 Sep 2012 15:49:38 -0400
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xen.org
Date: Mon, 10 Sep 2012 15:48:59 -0400
Message-Id: <1347306553-20980-7-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.11.4
In-Reply-To: <1347306553-20980-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1347306553-20980-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: [Xen-devel] [PATCH 06/20] flask/policy: Add domain relabel example
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This adds the nomigrate_t type to the example FLASK policy which allows
domains to be created that dom0 cannot access after building.

Example domain configuration snippet:
  seclabel='customer_1:vm_r:nomigrate_t'
  init_seclabel='customer_1:vm_r:nomigrate_t_building'

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 docs/misc/xsm-flask.txt                      |  2 +
 tools/flask/policy/policy/modules/xen/xen.if | 56 +++++++++++++++++++++-------
 tools/flask/policy/policy/modules/xen/xen.te | 10 +++++
 3 files changed, 55 insertions(+), 13 deletions(-)

diff --git a/docs/misc/xsm-flask.txt b/docs/misc/xsm-flask.txt
index 6b0d327..0778a28 100644
--- a/docs/misc/xsm-flask.txt
+++ b/docs/misc/xsm-flask.txt
@@ -60,6 +60,8 @@ that can be used without dom0 disaggregation. The main types for domUs are:
  - domU_t is a domain that can communicate with any other domU_t
  - isolated_domU_t can only communicate with dom0
  - prot_domU_t is a domain type whose creation can be disabled with a boolean
+ - nomigrate_t is a domain that must be created via the nomigrate_t_building
+   type, and whose memory cannot be read by dom0 once created
 
 HVM domains with stubdomain device models use two types (one per domain):
  - domHVM_t is an HVM domain that uses a stubdomain device model
diff --git a/tools/flask/policy/policy/modules/xen/xen.if b/tools/flask/policy/policy/modules/xen/xen.if
index 3f58909..2ad11b2 100644
--- a/tools/flask/policy/policy/modules/xen/xen.if
+++ b/tools/flask/policy/policy/modules/xen/xen.if
@@ -9,24 +9,47 @@
 #   Declare a type as a domain type, and allow basic domain setup
 define(`declare_domain', `
 	type $1, domain_type`'ifelse(`$#', `1', `', `,shift($@)');
+	type $1_channel, event_type;
+	type_transition $1 domain_type:event $1_channel;
 	allow $1 $1:grant { query setup };
 	allow $1 $1:mmu { adjust physmap map_read map_write stat pinpage };
 	allow $1 $1:hvm { getparam setparam };
 ')
 
-# create_domain(priv, target)
-#   Allow a domain to be created
-define(`create_domain', `
+# declare_build_label(type)
+#   Declare a paired _building type for the given domain type
+define(`declare_build_label', `
+	type $1_building, domain_type;
+	type_transition $1_building domain_type:event $1_channel;
+	allow $1_building $1 : domain transition;
+')
+
+define(`create_domain_common', `
 	allow $1 $2:domain { create max_vcpus setdomainmaxmem setaddrsize
-			getdomaininfo hypercall setvcpucontext scheduler
-			unpause getvcpuinfo getvcpuextstate getaddrsize
-			getvcpuaffinity };
+			getdomaininfo hypercall setvcpucontext setextvcpucontext
+			scheduler getvcpuinfo getvcpuextstate getaddrsize
+			getvcpuaffinity setvcpuaffinity };
 	allow $1 $2:security check_context;
 	allow $1 $2:shadow enable;
 	allow $1 $2:mmu {map_read map_write adjust memorymap physmap pinpage};
 	allow $1 $2:grant setup;
-	allow $1 $2:hvm { cacheattr getparam hvmctl irqlevel pciroute setparam pcilevel trackdirtyvram };
-	allow $1 $2_$1_channel:event create;
+	allow $1 $2:hvm { cacheattr getparam hvmctl irqlevel pciroute sethvmc setparam pcilevel trackdirtyvram };
+')
+
+# create_domain(priv, target)
+#   Allow a domain to be created directly
+define(`create_domain', `
+	create_domain_common($1, $2)
+	allow $1 $2_channel:event create;
+')
+
+# create_domain_build_label(priv, target)
+#   Allow a domain to be created via its domain build label
+define(`create_domain_build_label', `
+	create_domain_common($1, $2_building)
+	allow $1 $2_channel:event create;
+	allow $1 $2_building:domain2 relabelfrom;
+	allow $1 $2:domain2 relabelto;
 ')
 
 # manage_domain(priv, target)
@@ -37,6 +60,15 @@ define(`manage_domain', `
 			setvcpuaffinity setdomainmaxmem };
 ')
 
+# migrate_domain_out(priv, target)
+#   Allow creation of a snapshot or migration image from a domain
+#   (inbound migration is the same as domain creation)
+define(`migrate_domain_out', `
+	allow $1 $2:hvm { gethvmc getparam irqlevel };
+	allow $1 $2:mmu { stat pageinfo map_read };
+	allow $1 $2:domain { getaddrsize getvcpucontext getextvcpucontext getvcpuextstate pause destroy };
+')
+
 ################################################################################
 #
 # Inter-domain communication
@@ -47,8 +79,6 @@ define(`manage_domain', `
 #   This allows an event channel to be created from domains with labels
 #   <source> to <dest> and will label it <chan-label>
 define(`create_channel', `
-	type $3, event_type;
-	type_transition $1 $2:event $3;
 	allow $1 $3:event { create send status };
 	allow $3 $2:event { bind };
 ')
@@ -56,8 +86,8 @@ define(`create_channel', `
 # domain_event_comms(dom1, dom2)
 #   Allow two domain types to communicate using event channels
 define(`domain_event_comms', `
-	create_channel($1, $2, $1_$2_channel)
-	create_channel($2, $1, $2_$1_channel)
+	create_channel($1, $2, $1_channel)
+	create_channel($2, $1, $2_channel)
 ')
 
 # domain_comms(dom1, dom2)
@@ -72,7 +102,7 @@ define(`domain_comms', `
 #   Allow a domain types to communicate with others of its type using grants
 #   and event channels (this includes event channels to DOMID_SELF)
 define(`domain_self_comms', `
-	create_channel($1, $1, $1_self_channel)
+	create_channel($1, $1, $1_channel)
 	allow $1 $1:grant { map_read map_write copy unmap };
 ')
 
diff --git a/tools/flask/policy/policy/modules/xen/xen.te b/tools/flask/policy/policy/modules/xen/xen.te
index 9550397..1162153 100644
--- a/tools/flask/policy/policy/modules/xen/xen.te
+++ b/tools/flask/policy/policy/modules/xen/xen.te
@@ -90,6 +90,7 @@ create_domain(dom0_t, isolated_domU_t)
 manage_domain(dom0_t, isolated_domU_t)
 domain_comms(dom0_t, isolated_domU_t)
 
+# Declare a boolean that denies creation of prot_domU_t domains
 gen_bool(prot_doms_locked, false)
 declare_domain(prot_domU_t)
 if (!prot_doms_locked) {
@@ -111,6 +112,15 @@ manage_domain(dom0_t, dm_dom_t)
 domain_comms(dom0_t, dm_dom_t)
 device_model(dm_dom_t, domHVM_t)
 
+# nomigrate_t must be built via the nomigrate_t_building label; once built,
+# dom0 cannot read its memory.
+declare_domain(nomigrate_t)
+declare_build_label(nomigrate_t)
+create_domain_build_label(dom0_t, nomigrate_t)
+manage_domain(dom0_t, nomigrate_t)
+domain_comms(dom0_t, nomigrate_t)
+domain_self_comms(nomigrate_t)
+
 ###############################################################################
 #
 # Device delegation
-- 
1.7.11.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 10 19:49:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Sep 2012 19:49: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 1TB9zQ-0001GI-JO; Mon, 10 Sep 2012 19:49:48 +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 1TB9zO-00019X-IJ
	for xen-devel@lists.xen.org; Mon, 10 Sep 2012 19:49:46 +0000
Received: from [85.158.143.99:28064] by server-3.bemta-4.messagelabs.com id
	AB/D7-08232-A544E405; Mon, 10 Sep 2012 19:49:46 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-6.tower-216.messagelabs.com!1347306583!22574392!1
X-Originating-IP: [63.239.67.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16982 invoked from network); 10 Sep 2012 19:49:44 -0000
Received: from emvm-gh1-uea09.nsa.gov (HELO nsa.gov) (63.239.67.10)
	by server-6.tower-216.messagelabs.com with SMTP;
	10 Sep 2012 19:49:44 -0000
X-TM-IMSS-Message-ID: <3066de1f000f226a@nsa.gov>
Received: from tarius.tycho.ncsc.mil ([144.51.3.1]) by nsa.gov
	([63.239.67.10]) with ESMTP (TREND IMSS SMTP Service 7.1) id
	3066de1f000f226a ; Mon, 10 Sep 2012 15:51:54 -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 q8AJna3u027796; 
	Mon, 10 Sep 2012 15:49:42 -0400
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xen.org
Date: Mon, 10 Sep 2012 15:49:11 -0400
Message-Id: <1347306553-20980-19-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.11.4
In-Reply-To: <1347306553-20980-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1347306553-20980-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: [Xen-devel] [PATCH 18/20] xen: Add XSM hook for XENMEM_exchange
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 tools/flask/policy/policy/flask/access_vectors |  1 +
 tools/flask/policy/policy/modules/xen/xen.if   |  2 ++
 xen/common/memory.c                            | 12 +++++++++++-
 xen/include/xsm/dummy.h                        |  7 +++++++
 xen/include/xsm/xsm.h                          |  6 ++++++
 xen/xsm/dummy.c                                |  1 +
 xen/xsm/flask/hooks.c                          |  6 ++++++
 xen/xsm/flask/include/av_perm_to_string.h      |  1 +
 xen/xsm/flask/include/av_permissions.h         |  1 +
 9 files changed, 36 insertions(+), 1 deletion(-)

diff --git a/tools/flask/policy/policy/flask/access_vectors b/tools/flask/policy/policy/flask/access_vectors
index 5e897e2..2736075 100644
--- a/tools/flask/policy/policy/flask/access_vectors
+++ b/tools/flask/policy/policy/flask/access_vectors
@@ -142,6 +142,7 @@ class mmu
     memorymap
     remote_remap
 	mmuext_op
+	exchange
 }
 
 class shadow
diff --git a/tools/flask/policy/policy/modules/xen/xen.if b/tools/flask/policy/policy/modules/xen/xen.if
index e0c2d2d..8056f18 100644
--- a/tools/flask/policy/policy/modules/xen/xen.if
+++ b/tools/flask/policy/policy/modules/xen/xen.if
@@ -30,6 +30,7 @@ define(`declare_domain', `
 #   containing at most one domain. This is not enforced by policy.
 define(`declare_singleton_domain', `
 	type $1, domain_type`'ifelse(`$#', `1', `', `,shift($@)');
+	define(`$1_self', `$1')
 	type $1_channel, event_type;
 	type_transition $1 domain_type:event $1_channel;
 	declare_domain_common($1, $1)
@@ -161,6 +162,7 @@ define(`make_device_model', `
 # use_device(domain, device)
 #   Allow a device to be used by a domain
 define(`use_device', `
+    allow $1 $1_self:mmu exchange;
     allow $1 $2:resource use;
     allow $1 $2:mmu { map_read map_write };
 ')
diff --git a/xen/common/memory.c b/xen/common/memory.c
index cfdd63f..a5b548b 100644
--- a/xen/common/memory.c
+++ b/xen/common/memory.c
@@ -329,9 +329,19 @@ static long memory_exchange(XEN_GUEST_HANDLE(xen_memory_exchange_t) arg)
         out_chunk_order = exch.in.extent_order - exch.out.extent_order;
     }
 
-    rc = rcu_lock_target_domain_by_id(exch.in.domid, &d);
+    d = rcu_lock_domain_by_any_id(exch.in.domid);
+    if ( d == NULL )
+    {
+        rc = -ESRCH;
+        goto fail_early;
+    }
+
+    rc = xsm_memory_exchange(d);
     if ( rc )
+    {
+        rcu_unlock_domain(d);
         goto fail_early;
+    }
 
     memflags |= MEMF_bits(domain_clamp_alloc_bitsize(
         d,
diff --git a/xen/include/xsm/dummy.h b/xen/include/xsm/dummy.h
index a093734..16ad33a 100644
--- a/xen/include/xsm/dummy.h
+++ b/xen/include/xsm/dummy.h
@@ -279,6 +279,13 @@ static XSM_DEFAULT(int, grant_query_size) (struct domain *d1, struct domain *d2)
     return 0;
 }
 
+static XSM_DEFAULT(int, memory_exchange) (struct domain *d)
+{
+    if ( d != current->domain && !IS_PRIV_FOR(current->domain, d) )
+        return -EPERM;
+    return 0;
+}
+
 static XSM_DEFAULT(int, memory_adjust_reservation) (struct domain *d1,
                                                             struct domain *d2)
 {
diff --git a/xen/include/xsm/xsm.h b/xen/include/xsm/xsm.h
index cf2a7e5..8c11172 100644
--- a/xen/include/xsm/xsm.h
+++ b/xen/include/xsm/xsm.h
@@ -98,6 +98,7 @@ struct xsm_operations {
 
     int (*get_pod_target) (struct domain *d);
     int (*set_pod_target) (struct domain *d);
+    int (*memory_exchange) (struct domain *d);
     int (*memory_adjust_reservation) (struct domain *d1, struct domain *d2);
     int (*memory_stat_reservation) (struct domain *d1, struct domain *d2);
     int (*memory_pin_page) (struct domain *d1, struct domain *d2, struct page_info *page);
@@ -452,6 +453,11 @@ static inline int xsm_set_pod_target (struct domain *d)
     return xsm_ops->set_pod_target(d);
 }
 
+static inline int xsm_memory_exchange (struct domain *d)
+{
+    return xsm_ops->memory_exchange(d);
+}
+
 static inline int xsm_memory_adjust_reservation (struct domain *d1, struct
                                                                     domain *d2)
 {
diff --git a/xen/xsm/dummy.c b/xen/xsm/dummy.c
index 954f97c..8e13740 100644
--- a/xen/xsm/dummy.c
+++ b/xen/xsm/dummy.c
@@ -83,6 +83,7 @@ void xsm_fixup_ops (struct xsm_operations *ops)
     set_to_dummy_if_null(ops, get_pod_target);
     set_to_dummy_if_null(ops, set_pod_target);
 
+    set_to_dummy_if_null(ops, memory_exchange);
     set_to_dummy_if_null(ops, memory_adjust_reservation);
     set_to_dummy_if_null(ops, memory_stat_reservation);
     set_to_dummy_if_null(ops, memory_pin_page);
diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
index dc5f67e..316e8ef 100644
--- a/xen/xsm/flask/hooks.c
+++ b/xen/xsm/flask/hooks.c
@@ -396,6 +396,11 @@ static int flask_set_pod_target(struct domain *d)
     return current_has_perm(d, SECCLASS_DOMAIN, DOMAIN__SETPODTARGET);
 }
 
+static int flask_memory_exchange(struct domain *d)
+{
+    return current_has_perm(d, SECCLASS_MMU, MMU__EXCHANGE);
+}
+
 static int flask_memory_adjust_reservation(struct domain *d1, struct domain *d2)
 {
     return domain_has_perm(d1, d2, SECCLASS_MMU, MMU__ADJUST);
@@ -1555,6 +1560,7 @@ static struct xsm_operations flask_ops = {
 
     .get_pod_target = flask_get_pod_target,
     .set_pod_target = flask_set_pod_target,
+    .memory_exchange = flask_memory_exchange,
     .memory_adjust_reservation = flask_memory_adjust_reservation,
     .memory_stat_reservation = flask_memory_stat_reservation,
     .memory_pin_page = flask_memory_pin_page,
diff --git a/xen/xsm/flask/include/av_perm_to_string.h b/xen/xsm/flask/include/av_perm_to_string.h
index 5d4f316..b2c77b2 100644
--- a/xen/xsm/flask/include/av_perm_to_string.h
+++ b/xen/xsm/flask/include/av_perm_to_string.h
@@ -112,6 +112,7 @@
    S_(SECCLASS_MMU, MMU__MEMORYMAP, "memorymap")
    S_(SECCLASS_MMU, MMU__REMOTE_REMAP, "remote_remap")
    S_(SECCLASS_MMU, MMU__MMUEXT_OP, "mmuext_op")
+   S_(SECCLASS_MMU, MMU__EXCHANGE, "exchange")
    S_(SECCLASS_SHADOW, SHADOW__DISABLE, "disable")
    S_(SECCLASS_SHADOW, SHADOW__ENABLE, "enable")
    S_(SECCLASS_SHADOW, SHADOW__LOGDIRTY, "logdirty")
diff --git a/xen/xsm/flask/include/av_permissions.h b/xen/xsm/flask/include/av_permissions.h
index f970b50..acb0b1a 100644
--- a/xen/xsm/flask/include/av_permissions.h
+++ b/xen/xsm/flask/include/av_permissions.h
@@ -118,6 +118,7 @@
 #define MMU__MEMORYMAP                            0x00000800UL
 #define MMU__REMOTE_REMAP                         0x00001000UL
 #define MMU__MMUEXT_OP                            0x00002000UL
+#define MMU__EXCHANGE                             0x00004000UL
 
 #define SHADOW__DISABLE                           0x00000001UL
 #define SHADOW__ENABLE                            0x00000002UL
-- 
1.7.11.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 10 19:49:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Sep 2012 19:49: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 1TB9zL-0001AP-2h; Mon, 10 Sep 2012 19:49:43 +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 1TB9zJ-00019W-K5
	for xen-devel@lists.xen.org; Mon, 10 Sep 2012 19:49:41 +0000
Received: from [85.158.138.51:26913] by server-3.bemta-3.messagelabs.com id
	2C/E0-21322-4544E405; Mon, 10 Sep 2012 19:49:40 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-13.tower-174.messagelabs.com!1347306579!11083650!1
X-Originating-IP: [63.239.67.9]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22322 invoked from network); 10 Sep 2012 19:49:39 -0000
Received: from emvm-gh1-uea08.nsa.gov (HELO nsa.gov) (63.239.67.9)
	by server-13.tower-174.messagelabs.com with SMTP;
	10 Sep 2012 19:49:39 -0000
X-TM-IMSS-Message-ID: <30670b86000ed1be@nsa.gov>
Received: from tarius.tycho.ncsc.mil ([144.51.3.1]) by nsa.gov ([63.239.67.9])
	with ESMTP (TREND IMSS SMTP Service 7.1) id 30670b86000ed1be ;
	Mon, 10 Sep 2012 15:49:33 -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 q8AJna3g027796; 
	Mon, 10 Sep 2012 15:49:37 -0400
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xen.org
Date: Mon, 10 Sep 2012 15:48:57 -0400
Message-Id: <1347306553-20980-5-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.11.4
In-Reply-To: <1347306553-20980-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1347306553-20980-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: [Xen-devel] [PATCH 04/20] xsm/flask: add domain relabel 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

This adds the ability to change a domain's XSM label after creation.
The new label will be used for all future access checks; however,
existing event channels and memory mappings will remain valid even if
their creation would be denied by the new label.

With appropriate security policy and hooks in the domain builder, this
can be used to create domains that the domain builder does not have
access to after building. It can also be used to allow a domain to drop
privileges - for example, prior to launching a user-supplied kernel
loaded by a pv-grub stubdom.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 tools/flask/policy/policy/flask/access_vectors   |  7 ++++
 tools/flask/policy/policy/flask/security_classes |  1 +
 tools/flask/policy/policy/modules/xen/xen.te     |  2 +-
 xen/include/public/xsm/flask_op.h                |  8 ++++
 xen/xsm/flask/flask_op.c                         | 49 ++++++++++++++++++++++++
 xen/xsm/flask/include/av_perm_to_string.h        |  3 ++
 xen/xsm/flask/include/av_permissions.h           |  4 ++
 xen/xsm/flask/include/class_to_string.h          |  1 +
 xen/xsm/flask/include/flask.h                    | 15 ++++----
 9 files changed, 82 insertions(+), 8 deletions(-)

diff --git a/tools/flask/policy/policy/flask/access_vectors b/tools/flask/policy/policy/flask/access_vectors
index a884312..c7e29ab 100644
--- a/tools/flask/policy/policy/flask/access_vectors
+++ b/tools/flask/policy/policy/flask/access_vectors
@@ -73,6 +73,13 @@ class domain
 	set_virq_handler
 }
 
+class domain2
+{
+	relabelfrom
+	relabelto
+	relabelself
+}
+
 class hvm
 {
     sethvmc
diff --git a/tools/flask/policy/policy/flask/security_classes b/tools/flask/policy/policy/flask/security_classes
index 2ca35d2..ef134a7 100644
--- a/tools/flask/policy/policy/flask/security_classes
+++ b/tools/flask/policy/policy/flask/security_classes
@@ -9,6 +9,7 @@
 
 class xen
 class domain
+class domain2
 class hvm
 class mmu
 class resource
diff --git a/tools/flask/policy/policy/modules/xen/xen.te b/tools/flask/policy/policy/modules/xen/xen.te
index 9cc5240..9550397 100644
--- a/tools/flask/policy/policy/modules/xen/xen.te
+++ b/tools/flask/policy/policy/modules/xen/xen.te
@@ -169,7 +169,7 @@ delegate_devices(dom0_t, domU_t)
 ################################################################################
 
 # Domains must be declared using domain_type
-neverallow * ~domain_type:domain create;
+neverallow * ~domain_type:domain { create transition };
 
 # Resources must be declared using resource_type
 neverallow * ~resource_type:resource use;
diff --git a/xen/include/public/xsm/flask_op.h b/xen/include/public/xsm/flask_op.h
index 1a251c9..233de81 100644
--- a/xen/include/public/xsm/flask_op.h
+++ b/xen/include/public/xsm/flask_op.h
@@ -142,6 +142,12 @@ struct xen_flask_peersid {
     uint32_t sid;
 };
 
+struct xen_flask_relabel {
+    /* IN */
+    uint32_t domid;
+    uint32_t sid;
+};
+
 struct xen_flask_op {
     uint32_t cmd;
 #define FLASK_LOAD              1
@@ -167,6 +173,7 @@ struct xen_flask_op {
 #define FLASK_ADD_OCONTEXT      21
 #define FLASK_DEL_OCONTEXT      22
 #define FLASK_GET_PEER_SID      23
+#define FLASK_RELABEL_DOMAIN    24
     uint32_t interface_version; /* XEN_FLASK_INTERFACE_VERSION */
     union {
         struct xen_flask_load load;
@@ -185,6 +192,7 @@ struct xen_flask_op {
         /* FLASK_ADD_OCONTEXT, FLASK_DEL_OCONTEXT */
         struct xen_flask_ocontext ocontext;
         struct xen_flask_peersid peersid;
+        struct xen_flask_relabel relabel;
     } u;
 };
 typedef struct xen_flask_op xen_flask_op_t;
diff --git a/xen/xsm/flask/flask_op.c b/xen/xsm/flask/flask_op.c
index bd4db37..9c8dfe7 100644
--- a/xen/xsm/flask/flask_op.c
+++ b/xen/xsm/flask/flask_op.c
@@ -573,6 +573,51 @@ static int flask_get_peer_sid(struct xen_flask_peersid *arg)
     return rv;
 }
 
+static int flask_relabel_domain(struct xen_flask_relabel *arg)
+{
+    int rc;
+    struct domain *d;
+    struct domain_security_struct *csec = current->domain->ssid;
+    struct domain_security_struct *dsec;
+    struct avc_audit_data ad;
+    AVC_AUDIT_DATA_INIT(&ad, NONE);
+
+    d = rcu_lock_domain_by_any_id(arg->domid);
+    if ( d == NULL )
+        return -ESRCH;
+
+    ad.sdom = current->domain;
+    ad.tdom = d;
+    dsec = d->ssid;
+
+    if ( arg->domid == DOMID_SELF )
+    {
+        rc = avc_has_perm(dsec->sid, arg->sid, SECCLASS_DOMAIN2, DOMAIN2__RELABELSELF, &ad);
+        if ( rc )
+            goto out;
+    }
+    else
+    {
+        rc = avc_has_perm(csec->sid, dsec->sid, SECCLASS_DOMAIN2, DOMAIN2__RELABELFROM, &ad);
+        if ( rc )
+            goto out;
+
+        rc = avc_has_perm(csec->sid, arg->sid, SECCLASS_DOMAIN2, DOMAIN2__RELABELTO, &ad);
+        if ( rc )
+            goto out;
+    }
+
+    rc = avc_has_perm(dsec->sid, arg->sid, SECCLASS_DOMAIN, DOMAIN__TRANSITION, &ad);
+    if ( rc )
+        goto out;
+
+    dsec->sid = arg->sid;
+
+ out:
+    rcu_unlock_domain(d);
+    return rc;
+}
+
 long do_flask_op(XEN_GUEST_HANDLE(xsm_op_t) u_flask_op)
 {
     xen_flask_op_t op;
@@ -680,6 +725,10 @@ long do_flask_op(XEN_GUEST_HANDLE(xsm_op_t) u_flask_op)
         rv = flask_get_peer_sid(&op.u.peersid);
         break;
 
+    case FLASK_RELABEL_DOMAIN:
+        rv = flask_relabel_domain(&op.u.relabel);
+        break;
+
     default:
         rv = -ENOSYS;
     }
diff --git a/xen/xsm/flask/include/av_perm_to_string.h b/xen/xsm/flask/include/av_perm_to_string.h
index 17a1c36..e7e2058 100644
--- a/xen/xsm/flask/include/av_perm_to_string.h
+++ b/xen/xsm/flask/include/av_perm_to_string.h
@@ -61,6 +61,9 @@
    S_(SECCLASS_DOMAIN, DOMAIN__SETPODTARGET, "setpodtarget")
    S_(SECCLASS_DOMAIN, DOMAIN__SET_MISC_INFO, "set_misc_info")
    S_(SECCLASS_DOMAIN, DOMAIN__SET_VIRQ_HANDLER, "set_virq_handler")
+   S_(SECCLASS_DOMAIN2, DOMAIN2__RELABELFROM, "relabelfrom")
+   S_(SECCLASS_DOMAIN2, DOMAIN2__RELABELTO, "relabelto")
+   S_(SECCLASS_DOMAIN2, DOMAIN2__RELABELSELF, "relabelself")
    S_(SECCLASS_HVM, HVM__SETHVMC, "sethvmc")
    S_(SECCLASS_HVM, HVM__GETHVMC, "gethvmc")
    S_(SECCLASS_HVM, HVM__SETPARAM, "setparam")
diff --git a/xen/xsm/flask/include/av_permissions.h b/xen/xsm/flask/include/av_permissions.h
index 42eaf81..cb1c5dc 100644
--- a/xen/xsm/flask/include/av_permissions.h
+++ b/xen/xsm/flask/include/av_permissions.h
@@ -63,6 +63,10 @@
 #define DOMAIN__SET_MISC_INFO                     0x40000000UL
 #define DOMAIN__SET_VIRQ_HANDLER                  0x80000000UL
 
+#define DOMAIN2__RELABELFROM                      0x00000001UL
+#define DOMAIN2__RELABELTO                        0x00000002UL
+#define DOMAIN2__RELABELSELF                      0x00000004UL
+
 #define HVM__SETHVMC                              0x00000001UL
 #define HVM__GETHVMC                              0x00000002UL
 #define HVM__SETPARAM                             0x00000004UL
diff --git a/xen/xsm/flask/include/class_to_string.h b/xen/xsm/flask/include/class_to_string.h
index ab55700..7716645 100644
--- a/xen/xsm/flask/include/class_to_string.h
+++ b/xen/xsm/flask/include/class_to_string.h
@@ -5,6 +5,7 @@
     S_("null")
     S_("xen")
     S_("domain")
+    S_("domain2")
     S_("hvm")
     S_("mmu")
     S_("resource")
diff --git a/xen/xsm/flask/include/flask.h b/xen/xsm/flask/include/flask.h
index 6d29c5a..3bff998 100644
--- a/xen/xsm/flask/include/flask.h
+++ b/xen/xsm/flask/include/flask.h
@@ -7,13 +7,14 @@
  */
 #define SECCLASS_XEN                                     1
 #define SECCLASS_DOMAIN                                  2
-#define SECCLASS_HVM                                     3
-#define SECCLASS_MMU                                     4
-#define SECCLASS_RESOURCE                                5
-#define SECCLASS_SHADOW                                  6
-#define SECCLASS_EVENT                                   7
-#define SECCLASS_GRANT                                   8
-#define SECCLASS_SECURITY                                9
+#define SECCLASS_DOMAIN2                                 3
+#define SECCLASS_HVM                                     4
+#define SECCLASS_MMU                                     5
+#define SECCLASS_RESOURCE                                6
+#define SECCLASS_SHADOW                                  7
+#define SECCLASS_EVENT                                   8
+#define SECCLASS_GRANT                                   9
+#define SECCLASS_SECURITY                                10
 
 /*
  * Security identifier indices for initial entities
-- 
1.7.11.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 10 19:49:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Sep 2012 19:49: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 1TB9zQ-0001GI-JO; Mon, 10 Sep 2012 19:49:48 +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 1TB9zO-00019X-IJ
	for xen-devel@lists.xen.org; Mon, 10 Sep 2012 19:49:46 +0000
Received: from [85.158.143.99:28064] by server-3.bemta-4.messagelabs.com id
	AB/D7-08232-A544E405; Mon, 10 Sep 2012 19:49:46 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-6.tower-216.messagelabs.com!1347306583!22574392!1
X-Originating-IP: [63.239.67.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16982 invoked from network); 10 Sep 2012 19:49:44 -0000
Received: from emvm-gh1-uea09.nsa.gov (HELO nsa.gov) (63.239.67.10)
	by server-6.tower-216.messagelabs.com with SMTP;
	10 Sep 2012 19:49:44 -0000
X-TM-IMSS-Message-ID: <3066de1f000f226a@nsa.gov>
Received: from tarius.tycho.ncsc.mil ([144.51.3.1]) by nsa.gov
	([63.239.67.10]) with ESMTP (TREND IMSS SMTP Service 7.1) id
	3066de1f000f226a ; Mon, 10 Sep 2012 15:51:54 -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 q8AJna3u027796; 
	Mon, 10 Sep 2012 15:49:42 -0400
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xen.org
Date: Mon, 10 Sep 2012 15:49:11 -0400
Message-Id: <1347306553-20980-19-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.11.4
In-Reply-To: <1347306553-20980-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1347306553-20980-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: [Xen-devel] [PATCH 18/20] xen: Add XSM hook for XENMEM_exchange
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 tools/flask/policy/policy/flask/access_vectors |  1 +
 tools/flask/policy/policy/modules/xen/xen.if   |  2 ++
 xen/common/memory.c                            | 12 +++++++++++-
 xen/include/xsm/dummy.h                        |  7 +++++++
 xen/include/xsm/xsm.h                          |  6 ++++++
 xen/xsm/dummy.c                                |  1 +
 xen/xsm/flask/hooks.c                          |  6 ++++++
 xen/xsm/flask/include/av_perm_to_string.h      |  1 +
 xen/xsm/flask/include/av_permissions.h         |  1 +
 9 files changed, 36 insertions(+), 1 deletion(-)

diff --git a/tools/flask/policy/policy/flask/access_vectors b/tools/flask/policy/policy/flask/access_vectors
index 5e897e2..2736075 100644
--- a/tools/flask/policy/policy/flask/access_vectors
+++ b/tools/flask/policy/policy/flask/access_vectors
@@ -142,6 +142,7 @@ class mmu
     memorymap
     remote_remap
 	mmuext_op
+	exchange
 }
 
 class shadow
diff --git a/tools/flask/policy/policy/modules/xen/xen.if b/tools/flask/policy/policy/modules/xen/xen.if
index e0c2d2d..8056f18 100644
--- a/tools/flask/policy/policy/modules/xen/xen.if
+++ b/tools/flask/policy/policy/modules/xen/xen.if
@@ -30,6 +30,7 @@ define(`declare_domain', `
 #   containing at most one domain. This is not enforced by policy.
 define(`declare_singleton_domain', `
 	type $1, domain_type`'ifelse(`$#', `1', `', `,shift($@)');
+	define(`$1_self', `$1')
 	type $1_channel, event_type;
 	type_transition $1 domain_type:event $1_channel;
 	declare_domain_common($1, $1)
@@ -161,6 +162,7 @@ define(`make_device_model', `
 # use_device(domain, device)
 #   Allow a device to be used by a domain
 define(`use_device', `
+    allow $1 $1_self:mmu exchange;
     allow $1 $2:resource use;
     allow $1 $2:mmu { map_read map_write };
 ')
diff --git a/xen/common/memory.c b/xen/common/memory.c
index cfdd63f..a5b548b 100644
--- a/xen/common/memory.c
+++ b/xen/common/memory.c
@@ -329,9 +329,19 @@ static long memory_exchange(XEN_GUEST_HANDLE(xen_memory_exchange_t) arg)
         out_chunk_order = exch.in.extent_order - exch.out.extent_order;
     }
 
-    rc = rcu_lock_target_domain_by_id(exch.in.domid, &d);
+    d = rcu_lock_domain_by_any_id(exch.in.domid);
+    if ( d == NULL )
+    {
+        rc = -ESRCH;
+        goto fail_early;
+    }
+
+    rc = xsm_memory_exchange(d);
     if ( rc )
+    {
+        rcu_unlock_domain(d);
         goto fail_early;
+    }
 
     memflags |= MEMF_bits(domain_clamp_alloc_bitsize(
         d,
diff --git a/xen/include/xsm/dummy.h b/xen/include/xsm/dummy.h
index a093734..16ad33a 100644
--- a/xen/include/xsm/dummy.h
+++ b/xen/include/xsm/dummy.h
@@ -279,6 +279,13 @@ static XSM_DEFAULT(int, grant_query_size) (struct domain *d1, struct domain *d2)
     return 0;
 }
 
+static XSM_DEFAULT(int, memory_exchange) (struct domain *d)
+{
+    if ( d != current->domain && !IS_PRIV_FOR(current->domain, d) )
+        return -EPERM;
+    return 0;
+}
+
 static XSM_DEFAULT(int, memory_adjust_reservation) (struct domain *d1,
                                                             struct domain *d2)
 {
diff --git a/xen/include/xsm/xsm.h b/xen/include/xsm/xsm.h
index cf2a7e5..8c11172 100644
--- a/xen/include/xsm/xsm.h
+++ b/xen/include/xsm/xsm.h
@@ -98,6 +98,7 @@ struct xsm_operations {
 
     int (*get_pod_target) (struct domain *d);
     int (*set_pod_target) (struct domain *d);
+    int (*memory_exchange) (struct domain *d);
     int (*memory_adjust_reservation) (struct domain *d1, struct domain *d2);
     int (*memory_stat_reservation) (struct domain *d1, struct domain *d2);
     int (*memory_pin_page) (struct domain *d1, struct domain *d2, struct page_info *page);
@@ -452,6 +453,11 @@ static inline int xsm_set_pod_target (struct domain *d)
     return xsm_ops->set_pod_target(d);
 }
 
+static inline int xsm_memory_exchange (struct domain *d)
+{
+    return xsm_ops->memory_exchange(d);
+}
+
 static inline int xsm_memory_adjust_reservation (struct domain *d1, struct
                                                                     domain *d2)
 {
diff --git a/xen/xsm/dummy.c b/xen/xsm/dummy.c
index 954f97c..8e13740 100644
--- a/xen/xsm/dummy.c
+++ b/xen/xsm/dummy.c
@@ -83,6 +83,7 @@ void xsm_fixup_ops (struct xsm_operations *ops)
     set_to_dummy_if_null(ops, get_pod_target);
     set_to_dummy_if_null(ops, set_pod_target);
 
+    set_to_dummy_if_null(ops, memory_exchange);
     set_to_dummy_if_null(ops, memory_adjust_reservation);
     set_to_dummy_if_null(ops, memory_stat_reservation);
     set_to_dummy_if_null(ops, memory_pin_page);
diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
index dc5f67e..316e8ef 100644
--- a/xen/xsm/flask/hooks.c
+++ b/xen/xsm/flask/hooks.c
@@ -396,6 +396,11 @@ static int flask_set_pod_target(struct domain *d)
     return current_has_perm(d, SECCLASS_DOMAIN, DOMAIN__SETPODTARGET);
 }
 
+static int flask_memory_exchange(struct domain *d)
+{
+    return current_has_perm(d, SECCLASS_MMU, MMU__EXCHANGE);
+}
+
 static int flask_memory_adjust_reservation(struct domain *d1, struct domain *d2)
 {
     return domain_has_perm(d1, d2, SECCLASS_MMU, MMU__ADJUST);
@@ -1555,6 +1560,7 @@ static struct xsm_operations flask_ops = {
 
     .get_pod_target = flask_get_pod_target,
     .set_pod_target = flask_set_pod_target,
+    .memory_exchange = flask_memory_exchange,
     .memory_adjust_reservation = flask_memory_adjust_reservation,
     .memory_stat_reservation = flask_memory_stat_reservation,
     .memory_pin_page = flask_memory_pin_page,
diff --git a/xen/xsm/flask/include/av_perm_to_string.h b/xen/xsm/flask/include/av_perm_to_string.h
index 5d4f316..b2c77b2 100644
--- a/xen/xsm/flask/include/av_perm_to_string.h
+++ b/xen/xsm/flask/include/av_perm_to_string.h
@@ -112,6 +112,7 @@
    S_(SECCLASS_MMU, MMU__MEMORYMAP, "memorymap")
    S_(SECCLASS_MMU, MMU__REMOTE_REMAP, "remote_remap")
    S_(SECCLASS_MMU, MMU__MMUEXT_OP, "mmuext_op")
+   S_(SECCLASS_MMU, MMU__EXCHANGE, "exchange")
    S_(SECCLASS_SHADOW, SHADOW__DISABLE, "disable")
    S_(SECCLASS_SHADOW, SHADOW__ENABLE, "enable")
    S_(SECCLASS_SHADOW, SHADOW__LOGDIRTY, "logdirty")
diff --git a/xen/xsm/flask/include/av_permissions.h b/xen/xsm/flask/include/av_permissions.h
index f970b50..acb0b1a 100644
--- a/xen/xsm/flask/include/av_permissions.h
+++ b/xen/xsm/flask/include/av_permissions.h
@@ -118,6 +118,7 @@
 #define MMU__MEMORYMAP                            0x00000800UL
 #define MMU__REMOTE_REMAP                         0x00001000UL
 #define MMU__MMUEXT_OP                            0x00002000UL
+#define MMU__EXCHANGE                             0x00004000UL
 
 #define SHADOW__DISABLE                           0x00000001UL
 #define SHADOW__ENABLE                            0x00000002UL
-- 
1.7.11.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 10 19:49:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Sep 2012 19:49: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 1TB9zL-0001AP-2h; Mon, 10 Sep 2012 19:49:43 +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 1TB9zJ-00019W-K5
	for xen-devel@lists.xen.org; Mon, 10 Sep 2012 19:49:41 +0000
Received: from [85.158.138.51:26913] by server-3.bemta-3.messagelabs.com id
	2C/E0-21322-4544E405; Mon, 10 Sep 2012 19:49:40 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-13.tower-174.messagelabs.com!1347306579!11083650!1
X-Originating-IP: [63.239.67.9]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22322 invoked from network); 10 Sep 2012 19:49:39 -0000
Received: from emvm-gh1-uea08.nsa.gov (HELO nsa.gov) (63.239.67.9)
	by server-13.tower-174.messagelabs.com with SMTP;
	10 Sep 2012 19:49:39 -0000
X-TM-IMSS-Message-ID: <30670b86000ed1be@nsa.gov>
Received: from tarius.tycho.ncsc.mil ([144.51.3.1]) by nsa.gov ([63.239.67.9])
	with ESMTP (TREND IMSS SMTP Service 7.1) id 30670b86000ed1be ;
	Mon, 10 Sep 2012 15:49:33 -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 q8AJna3g027796; 
	Mon, 10 Sep 2012 15:49:37 -0400
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xen.org
Date: Mon, 10 Sep 2012 15:48:57 -0400
Message-Id: <1347306553-20980-5-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.11.4
In-Reply-To: <1347306553-20980-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1347306553-20980-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: [Xen-devel] [PATCH 04/20] xsm/flask: add domain relabel 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

This adds the ability to change a domain's XSM label after creation.
The new label will be used for all future access checks; however,
existing event channels and memory mappings will remain valid even if
their creation would be denied by the new label.

With appropriate security policy and hooks in the domain builder, this
can be used to create domains that the domain builder does not have
access to after building. It can also be used to allow a domain to drop
privileges - for example, prior to launching a user-supplied kernel
loaded by a pv-grub stubdom.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 tools/flask/policy/policy/flask/access_vectors   |  7 ++++
 tools/flask/policy/policy/flask/security_classes |  1 +
 tools/flask/policy/policy/modules/xen/xen.te     |  2 +-
 xen/include/public/xsm/flask_op.h                |  8 ++++
 xen/xsm/flask/flask_op.c                         | 49 ++++++++++++++++++++++++
 xen/xsm/flask/include/av_perm_to_string.h        |  3 ++
 xen/xsm/flask/include/av_permissions.h           |  4 ++
 xen/xsm/flask/include/class_to_string.h          |  1 +
 xen/xsm/flask/include/flask.h                    | 15 ++++----
 9 files changed, 82 insertions(+), 8 deletions(-)

diff --git a/tools/flask/policy/policy/flask/access_vectors b/tools/flask/policy/policy/flask/access_vectors
index a884312..c7e29ab 100644
--- a/tools/flask/policy/policy/flask/access_vectors
+++ b/tools/flask/policy/policy/flask/access_vectors
@@ -73,6 +73,13 @@ class domain
 	set_virq_handler
 }
 
+class domain2
+{
+	relabelfrom
+	relabelto
+	relabelself
+}
+
 class hvm
 {
     sethvmc
diff --git a/tools/flask/policy/policy/flask/security_classes b/tools/flask/policy/policy/flask/security_classes
index 2ca35d2..ef134a7 100644
--- a/tools/flask/policy/policy/flask/security_classes
+++ b/tools/flask/policy/policy/flask/security_classes
@@ -9,6 +9,7 @@
 
 class xen
 class domain
+class domain2
 class hvm
 class mmu
 class resource
diff --git a/tools/flask/policy/policy/modules/xen/xen.te b/tools/flask/policy/policy/modules/xen/xen.te
index 9cc5240..9550397 100644
--- a/tools/flask/policy/policy/modules/xen/xen.te
+++ b/tools/flask/policy/policy/modules/xen/xen.te
@@ -169,7 +169,7 @@ delegate_devices(dom0_t, domU_t)
 ################################################################################
 
 # Domains must be declared using domain_type
-neverallow * ~domain_type:domain create;
+neverallow * ~domain_type:domain { create transition };
 
 # Resources must be declared using resource_type
 neverallow * ~resource_type:resource use;
diff --git a/xen/include/public/xsm/flask_op.h b/xen/include/public/xsm/flask_op.h
index 1a251c9..233de81 100644
--- a/xen/include/public/xsm/flask_op.h
+++ b/xen/include/public/xsm/flask_op.h
@@ -142,6 +142,12 @@ struct xen_flask_peersid {
     uint32_t sid;
 };
 
+struct xen_flask_relabel {
+    /* IN */
+    uint32_t domid;
+    uint32_t sid;
+};
+
 struct xen_flask_op {
     uint32_t cmd;
 #define FLASK_LOAD              1
@@ -167,6 +173,7 @@ struct xen_flask_op {
 #define FLASK_ADD_OCONTEXT      21
 #define FLASK_DEL_OCONTEXT      22
 #define FLASK_GET_PEER_SID      23
+#define FLASK_RELABEL_DOMAIN    24
     uint32_t interface_version; /* XEN_FLASK_INTERFACE_VERSION */
     union {
         struct xen_flask_load load;
@@ -185,6 +192,7 @@ struct xen_flask_op {
         /* FLASK_ADD_OCONTEXT, FLASK_DEL_OCONTEXT */
         struct xen_flask_ocontext ocontext;
         struct xen_flask_peersid peersid;
+        struct xen_flask_relabel relabel;
     } u;
 };
 typedef struct xen_flask_op xen_flask_op_t;
diff --git a/xen/xsm/flask/flask_op.c b/xen/xsm/flask/flask_op.c
index bd4db37..9c8dfe7 100644
--- a/xen/xsm/flask/flask_op.c
+++ b/xen/xsm/flask/flask_op.c
@@ -573,6 +573,51 @@ static int flask_get_peer_sid(struct xen_flask_peersid *arg)
     return rv;
 }
 
+static int flask_relabel_domain(struct xen_flask_relabel *arg)
+{
+    int rc;
+    struct domain *d;
+    struct domain_security_struct *csec = current->domain->ssid;
+    struct domain_security_struct *dsec;
+    struct avc_audit_data ad;
+    AVC_AUDIT_DATA_INIT(&ad, NONE);
+
+    d = rcu_lock_domain_by_any_id(arg->domid);
+    if ( d == NULL )
+        return -ESRCH;
+
+    ad.sdom = current->domain;
+    ad.tdom = d;
+    dsec = d->ssid;
+
+    if ( arg->domid == DOMID_SELF )
+    {
+        rc = avc_has_perm(dsec->sid, arg->sid, SECCLASS_DOMAIN2, DOMAIN2__RELABELSELF, &ad);
+        if ( rc )
+            goto out;
+    }
+    else
+    {
+        rc = avc_has_perm(csec->sid, dsec->sid, SECCLASS_DOMAIN2, DOMAIN2__RELABELFROM, &ad);
+        if ( rc )
+            goto out;
+
+        rc = avc_has_perm(csec->sid, arg->sid, SECCLASS_DOMAIN2, DOMAIN2__RELABELTO, &ad);
+        if ( rc )
+            goto out;
+    }
+
+    rc = avc_has_perm(dsec->sid, arg->sid, SECCLASS_DOMAIN, DOMAIN__TRANSITION, &ad);
+    if ( rc )
+        goto out;
+
+    dsec->sid = arg->sid;
+
+ out:
+    rcu_unlock_domain(d);
+    return rc;
+}
+
 long do_flask_op(XEN_GUEST_HANDLE(xsm_op_t) u_flask_op)
 {
     xen_flask_op_t op;
@@ -680,6 +725,10 @@ long do_flask_op(XEN_GUEST_HANDLE(xsm_op_t) u_flask_op)
         rv = flask_get_peer_sid(&op.u.peersid);
         break;
 
+    case FLASK_RELABEL_DOMAIN:
+        rv = flask_relabel_domain(&op.u.relabel);
+        break;
+
     default:
         rv = -ENOSYS;
     }
diff --git a/xen/xsm/flask/include/av_perm_to_string.h b/xen/xsm/flask/include/av_perm_to_string.h
index 17a1c36..e7e2058 100644
--- a/xen/xsm/flask/include/av_perm_to_string.h
+++ b/xen/xsm/flask/include/av_perm_to_string.h
@@ -61,6 +61,9 @@
    S_(SECCLASS_DOMAIN, DOMAIN__SETPODTARGET, "setpodtarget")
    S_(SECCLASS_DOMAIN, DOMAIN__SET_MISC_INFO, "set_misc_info")
    S_(SECCLASS_DOMAIN, DOMAIN__SET_VIRQ_HANDLER, "set_virq_handler")
+   S_(SECCLASS_DOMAIN2, DOMAIN2__RELABELFROM, "relabelfrom")
+   S_(SECCLASS_DOMAIN2, DOMAIN2__RELABELTO, "relabelto")
+   S_(SECCLASS_DOMAIN2, DOMAIN2__RELABELSELF, "relabelself")
    S_(SECCLASS_HVM, HVM__SETHVMC, "sethvmc")
    S_(SECCLASS_HVM, HVM__GETHVMC, "gethvmc")
    S_(SECCLASS_HVM, HVM__SETPARAM, "setparam")
diff --git a/xen/xsm/flask/include/av_permissions.h b/xen/xsm/flask/include/av_permissions.h
index 42eaf81..cb1c5dc 100644
--- a/xen/xsm/flask/include/av_permissions.h
+++ b/xen/xsm/flask/include/av_permissions.h
@@ -63,6 +63,10 @@
 #define DOMAIN__SET_MISC_INFO                     0x40000000UL
 #define DOMAIN__SET_VIRQ_HANDLER                  0x80000000UL
 
+#define DOMAIN2__RELABELFROM                      0x00000001UL
+#define DOMAIN2__RELABELTO                        0x00000002UL
+#define DOMAIN2__RELABELSELF                      0x00000004UL
+
 #define HVM__SETHVMC                              0x00000001UL
 #define HVM__GETHVMC                              0x00000002UL
 #define HVM__SETPARAM                             0x00000004UL
diff --git a/xen/xsm/flask/include/class_to_string.h b/xen/xsm/flask/include/class_to_string.h
index ab55700..7716645 100644
--- a/xen/xsm/flask/include/class_to_string.h
+++ b/xen/xsm/flask/include/class_to_string.h
@@ -5,6 +5,7 @@
     S_("null")
     S_("xen")
     S_("domain")
+    S_("domain2")
     S_("hvm")
     S_("mmu")
     S_("resource")
diff --git a/xen/xsm/flask/include/flask.h b/xen/xsm/flask/include/flask.h
index 6d29c5a..3bff998 100644
--- a/xen/xsm/flask/include/flask.h
+++ b/xen/xsm/flask/include/flask.h
@@ -7,13 +7,14 @@
  */
 #define SECCLASS_XEN                                     1
 #define SECCLASS_DOMAIN                                  2
-#define SECCLASS_HVM                                     3
-#define SECCLASS_MMU                                     4
-#define SECCLASS_RESOURCE                                5
-#define SECCLASS_SHADOW                                  6
-#define SECCLASS_EVENT                                   7
-#define SECCLASS_GRANT                                   8
-#define SECCLASS_SECURITY                                9
+#define SECCLASS_DOMAIN2                                 3
+#define SECCLASS_HVM                                     4
+#define SECCLASS_MMU                                     5
+#define SECCLASS_RESOURCE                                6
+#define SECCLASS_SHADOW                                  7
+#define SECCLASS_EVENT                                   8
+#define SECCLASS_GRANT                                   9
+#define SECCLASS_SECURITY                                10
 
 /*
  * Security identifier indices for initial entities
-- 
1.7.11.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 10 19:49:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Sep 2012 19:49: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 1TB9zJ-00019g-Uz; Mon, 10 Sep 2012 19:49:41 +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 1TB9zH-00019A-Qg
	for xen-devel@lists.xen.org; Mon, 10 Sep 2012 19:49:40 +0000
Received: from [85.158.138.51:26815] by server-2.bemta-3.messagelabs.com id
	16/44-04862-3544E405; Mon, 10 Sep 2012 19:49:39 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-9.tower-174.messagelabs.com!1347306577!28078561!1
X-Originating-IP: [63.239.67.9]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21144 invoked from network); 10 Sep 2012 19:49:38 -0000
Received: from emvm-gh1-uea08.nsa.gov (HELO nsa.gov) (63.239.67.9)
	by server-9.tower-174.messagelabs.com with SMTP;
	10 Sep 2012 19:49:38 -0000
X-TM-IMSS-Message-ID: <306707de000ed1bc@nsa.gov>
Received: from tarius.tycho.ncsc.mil ([144.51.3.1]) by nsa.gov ([63.239.67.9])
	with ESMTP (TREND IMSS SMTP Service 7.1) id 306707de000ed1bc ;
	Mon, 10 Sep 2012 15:49:32 -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 q8AJna3e027796; 
	Mon, 10 Sep 2012 15:49:36 -0400
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xen.org
Date: Mon, 10 Sep 2012 15:48:55 -0400
Message-Id: <1347306553-20980-3-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.11.4
In-Reply-To: <1347306553-20980-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1347306553-20980-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: [Xen-devel] [PATCH 02/20] xsm/flask: remove unneeded create_sid
	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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This field was only used to populate the ssid of dom0, which can be
handled explicitly in the domain creation hook. This also removes the
unnecessary permission check on the creation of dom0.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 tools/flask/policy/policy/modules/xen/xen.te |  2 --
 xen/xsm/flask/hooks.c                        | 23 ++++++++++-------------
 xen/xsm/flask/include/objsec.h               |  1 -
 3 files changed, 10 insertions(+), 16 deletions(-)

diff --git a/tools/flask/policy/policy/modules/xen/xen.te b/tools/flask/policy/policy/modules/xen/xen.te
index e175d4b..9cc5240 100644
--- a/tools/flask/policy/policy/modules/xen/xen.te
+++ b/tools/flask/policy/policy/modules/xen/xen.te
@@ -52,8 +52,6 @@ type device_t, resource_type;
 # Rules required to boot the hypervisor and dom0
 #
 ################################################################################
-allow xen_t dom0_t:domain { create };
-
 allow dom0_t xen_t:xen { kexec readapic writeapic mtrr_read mtrr_add mtrr_del
 	scheduler physinfo heap quirk readconsole writeconsole settime getcpuinfo
 	microcode cpupool_op sched_op pm_op };
diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
index 8c853de..88fef9c 100644
--- a/xen/xsm/flask/hooks.c
+++ b/xen/xsm/flask/hooks.c
@@ -108,12 +108,10 @@ static int flask_domain_alloc_security(struct domain *d)
 
     memset(dsec, 0, sizeof(struct domain_security_struct));
 
-    dsec->create_sid = SECSID_NULL;
     switch ( d->domain_id )
     {
     case DOMID_IDLE:
         dsec->sid = SECINITSID_XEN;
-        dsec->create_sid = SECINITSID_DOM0;
         break;
     case DOMID_XEN:
         dsec->sid = SECINITSID_DOMXEN;
@@ -489,25 +487,24 @@ static int flask_domain_create(struct domain *d, u32 ssidref)
     int rc;
     struct domain_security_struct *dsec1;
     struct domain_security_struct *dsec2;
+    static int dom0_created = 0;
 
     dsec1 = current->domain->ssid;
+    dsec2 = d->ssid;
 
-    if ( dsec1->create_sid == SECSID_NULL ) 
-        dsec1->create_sid = ssidref;
+    if ( is_idle_domain(current->domain) && !dom0_created )
+    {
+        dsec2->sid = SECINITSID_DOM0;
+        dom0_created = 1;
+        return 0;
+    }
 
-    rc = avc_has_perm(dsec1->sid, dsec1->create_sid, SECCLASS_DOMAIN, 
+    rc = avc_has_perm(dsec1->sid, ssidref, SECCLASS_DOMAIN,
                       DOMAIN__CREATE, NULL);
     if ( rc )
-    {
-        dsec1->create_sid = SECSID_NULL;
         return rc;
-    }
-
-    dsec2 = d->ssid;
-    dsec2->sid = dsec1->create_sid;
 
-    dsec1->create_sid = SECSID_NULL;
-    dsec2->create_sid = SECSID_NULL;
+    dsec2->sid = ssidref;
 
     return rc;
 }
diff --git a/xen/xsm/flask/include/objsec.h b/xen/xsm/flask/include/objsec.h
index df5baee..4ff52be 100644
--- a/xen/xsm/flask/include/objsec.h
+++ b/xen/xsm/flask/include/objsec.h
@@ -19,7 +19,6 @@
 
 struct domain_security_struct {
     u32 sid;               /* current SID */
-    u32 create_sid;
 };
 
 struct evtchn_security_struct {
-- 
1.7.11.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 10 19:49:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Sep 2012 19:49: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 1TB9zI-00019K-Io; Mon, 10 Sep 2012 19:49:40 +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 1TB9zH-000199-6Q
	for xen-devel@lists.xen.org; Mon, 10 Sep 2012 19:49:39 +0000
Received: from [85.158.138.51:26773] by server-8.bemta-3.messagelabs.com id
	87/F5-24700-2544E405; Mon, 10 Sep 2012 19:49:38 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-6.tower-174.messagelabs.com!1347306577!21731044!1
X-Originating-IP: [63.239.67.9]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29934 invoked from network); 10 Sep 2012 19:49:37 -0000
Received: from emvm-gh1-uea08.nsa.gov (HELO nsa.gov) (63.239.67.9)
	by server-6.tower-174.messagelabs.com with SMTP;
	10 Sep 2012 19:49:37 -0000
X-TM-IMSS-Message-ID: <306704b2000ed1ba@nsa.gov>
Received: from tarius.tycho.ncsc.mil ([144.51.3.1]) by nsa.gov ([63.239.67.9])
	with ESMTP (TREND IMSS SMTP Service 7.1) id 306704b2000ed1ba ;
	Mon, 10 Sep 2012 15:49:31 -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 q8AJna3c027796
	for <xen-devel@lists.xen.org>; Mon, 10 Sep 2012 15:49:36 -0400
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xen.org
Date: Mon, 10 Sep 2012 15:48:53 -0400
Message-Id: <1347306553-20980-1-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.11.4
Subject: [Xen-devel] [PATCH v2] Merge IS_PRIV checks into XSM hooks
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Overall, this series should not change the behavior of Xen when XSM is
not enabled; however, in some cases, the exact errors that are returned
will be different because security checks have been moved below validity
checks. Also, once applied, newly introduced domctls and sysctls will
not automatically be guarded by IS_PRIV checks - they will need to add
their own permission checking code.

Background:

The Xen hypervisor has two basic access control function calls: IS_PRIV
and the xsm_* functions. Most privileged operations currently require
that both checks succeed, and many times the checks are at different
locations in the code.

When performing dom0 disaggregation, many of the functions normally
protected with IS_PRIV are handled by domains other than dom0. This
requires either making all such disaggregated domains privileged, or
allowing certain operations to be performed without an IS_PRIV check.
Because the privileged bit also short-circuits the IS_PRIV_FOR check,
and some IS_PRIV calls do not currently have an accompanying XSM call,
this series implements the second option.

Once applied, most IS_PRIV checks are isolated in the newly introduced
xen/include/xsm/dummy.h header. The remaining checks cover a few areas
that that have some reason to remain because they involve hardware
access or workarounds:

1. Overriding the IRQ and IO memory access checks (arch/x86/domctl.c).
   These overrides should not be needed, as dom0 should have access
   without needing the override.
2. Allow MAP_PIRQ_TYPE_GSI to ignore domain_pirq_to_irq negative return
3. The hack for device model framebuffers in get_page_from_l1e
4. Installing maps of non-owned pages in shadow_get_page_from_l1e
5. PCI configuration space (arch/x86/traps.c). Allowing a PV Linux domU
   to access the PCI configuration space is a good way to crash the
   system as it reconfigures PCI devices during boot, so this needs to
   remain to get a working system when FLASK is in permissive mode.
6. Various MSR accesses (arch/x86/traps.c)

The ARM architecture is not touched at all in these patches. The only
obvious breakage that I can see is due to rcu_lock_target_domain_by_id
being removed, but XSM hooks will be needed for domctls and sysctls.

The rcu_lock_target_domain_by_id and rcu_lock_remote_target_domain_by_id
functions are removed by this series because they act as wrappers around
IS_PRIV_FOR; their callers have been changed to use XSM checks instead.

Miscellaneous updates to FLASK:
    [PATCH 01/20] xsm/flask: remove inherited class attributes
    [PATCH 02/20] xsm/flask: remove unneeded create_sid field
    [PATCH 03/20] xen: Add versions of rcu_lock_*_domain without IS_PRIV
    [PATCH 04/20] xsm/flask: add domain relabel support
    [PATCH 05/20] libxl: introduce XSM relabel on build
    [PATCH 06/20] flask/policy: Add domain relabel example

Preparatory new hooks:
    [PATCH 07/20] arch/x86: add distinct XSM hooks for map/unmap
    [PATCH 08/20] arch/x86: add missing XSM checks to XENPF_ commands
    [PATCH 09/20] xsm/flask: Add checks on the domain performing the

Refactoring:
    [PATCH 10/20] xsm: Add IS_PRIV checks to dummy XSM module
    [PATCH 11/20] xen: use XSM instead of IS_PRIV where duplicated
    [PATCH 12/20] xen: avoid calling rcu_lock_*target_domain when an XSM

Remaining IS_PRIV calls:
    [PATCH 13/20] arch/x86: Add missing domctl and mem_sharing XSM hooks
    [PATCH 14/20] tmem: Add access control check
    [PATCH 17/20] arch/x86: use XSM hooks for get_pg_owner access checks
    [PATCH 18/20] xen: Add XSM hook for XENMEM_exchange

Cleanup, FLASK updates to support IS_PRIV emulation:
    [PATCH 15/20] xsm: remove unneeded xsm_call macro
    [PATCH 16/20] xsm/flask: add distinct SIDs for self/target access
    [PATCH 19/20] xen: remove rcu_lock_{remote_,}target_domain_by_id
    [PATCH 20/20] flask: add missing operations

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 10 19:49:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Sep 2012 19:49: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 1TB9zI-00019K-Io; Mon, 10 Sep 2012 19:49:40 +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 1TB9zH-000199-6Q
	for xen-devel@lists.xen.org; Mon, 10 Sep 2012 19:49:39 +0000
Received: from [85.158.138.51:26773] by server-8.bemta-3.messagelabs.com id
	87/F5-24700-2544E405; Mon, 10 Sep 2012 19:49:38 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-6.tower-174.messagelabs.com!1347306577!21731044!1
X-Originating-IP: [63.239.67.9]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29934 invoked from network); 10 Sep 2012 19:49:37 -0000
Received: from emvm-gh1-uea08.nsa.gov (HELO nsa.gov) (63.239.67.9)
	by server-6.tower-174.messagelabs.com with SMTP;
	10 Sep 2012 19:49:37 -0000
X-TM-IMSS-Message-ID: <306704b2000ed1ba@nsa.gov>
Received: from tarius.tycho.ncsc.mil ([144.51.3.1]) by nsa.gov ([63.239.67.9])
	with ESMTP (TREND IMSS SMTP Service 7.1) id 306704b2000ed1ba ;
	Mon, 10 Sep 2012 15:49:31 -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 q8AJna3c027796
	for <xen-devel@lists.xen.org>; Mon, 10 Sep 2012 15:49:36 -0400
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xen.org
Date: Mon, 10 Sep 2012 15:48:53 -0400
Message-Id: <1347306553-20980-1-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.11.4
Subject: [Xen-devel] [PATCH v2] Merge IS_PRIV checks into XSM hooks
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Overall, this series should not change the behavior of Xen when XSM is
not enabled; however, in some cases, the exact errors that are returned
will be different because security checks have been moved below validity
checks. Also, once applied, newly introduced domctls and sysctls will
not automatically be guarded by IS_PRIV checks - they will need to add
their own permission checking code.

Background:

The Xen hypervisor has two basic access control function calls: IS_PRIV
and the xsm_* functions. Most privileged operations currently require
that both checks succeed, and many times the checks are at different
locations in the code.

When performing dom0 disaggregation, many of the functions normally
protected with IS_PRIV are handled by domains other than dom0. This
requires either making all such disaggregated domains privileged, or
allowing certain operations to be performed without an IS_PRIV check.
Because the privileged bit also short-circuits the IS_PRIV_FOR check,
and some IS_PRIV calls do not currently have an accompanying XSM call,
this series implements the second option.

Once applied, most IS_PRIV checks are isolated in the newly introduced
xen/include/xsm/dummy.h header. The remaining checks cover a few areas
that that have some reason to remain because they involve hardware
access or workarounds:

1. Overriding the IRQ and IO memory access checks (arch/x86/domctl.c).
   These overrides should not be needed, as dom0 should have access
   without needing the override.
2. Allow MAP_PIRQ_TYPE_GSI to ignore domain_pirq_to_irq negative return
3. The hack for device model framebuffers in get_page_from_l1e
4. Installing maps of non-owned pages in shadow_get_page_from_l1e
5. PCI configuration space (arch/x86/traps.c). Allowing a PV Linux domU
   to access the PCI configuration space is a good way to crash the
   system as it reconfigures PCI devices during boot, so this needs to
   remain to get a working system when FLASK is in permissive mode.
6. Various MSR accesses (arch/x86/traps.c)

The ARM architecture is not touched at all in these patches. The only
obvious breakage that I can see is due to rcu_lock_target_domain_by_id
being removed, but XSM hooks will be needed for domctls and sysctls.

The rcu_lock_target_domain_by_id and rcu_lock_remote_target_domain_by_id
functions are removed by this series because they act as wrappers around
IS_PRIV_FOR; their callers have been changed to use XSM checks instead.

Miscellaneous updates to FLASK:
    [PATCH 01/20] xsm/flask: remove inherited class attributes
    [PATCH 02/20] xsm/flask: remove unneeded create_sid field
    [PATCH 03/20] xen: Add versions of rcu_lock_*_domain without IS_PRIV
    [PATCH 04/20] xsm/flask: add domain relabel support
    [PATCH 05/20] libxl: introduce XSM relabel on build
    [PATCH 06/20] flask/policy: Add domain relabel example

Preparatory new hooks:
    [PATCH 07/20] arch/x86: add distinct XSM hooks for map/unmap
    [PATCH 08/20] arch/x86: add missing XSM checks to XENPF_ commands
    [PATCH 09/20] xsm/flask: Add checks on the domain performing the

Refactoring:
    [PATCH 10/20] xsm: Add IS_PRIV checks to dummy XSM module
    [PATCH 11/20] xen: use XSM instead of IS_PRIV where duplicated
    [PATCH 12/20] xen: avoid calling rcu_lock_*target_domain when an XSM

Remaining IS_PRIV calls:
    [PATCH 13/20] arch/x86: Add missing domctl and mem_sharing XSM hooks
    [PATCH 14/20] tmem: Add access control check
    [PATCH 17/20] arch/x86: use XSM hooks for get_pg_owner access checks
    [PATCH 18/20] xen: Add XSM hook for XENMEM_exchange

Cleanup, FLASK updates to support IS_PRIV emulation:
    [PATCH 15/20] xsm: remove unneeded xsm_call macro
    [PATCH 16/20] xsm/flask: add distinct SIDs for self/target access
    [PATCH 19/20] xen: remove rcu_lock_{remote_,}target_domain_by_id
    [PATCH 20/20] flask: add missing operations

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 10 19:49:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Sep 2012 19:49: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 1TB9zJ-00019g-Uz; Mon, 10 Sep 2012 19:49:41 +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 1TB9zH-00019A-Qg
	for xen-devel@lists.xen.org; Mon, 10 Sep 2012 19:49:40 +0000
Received: from [85.158.138.51:26815] by server-2.bemta-3.messagelabs.com id
	16/44-04862-3544E405; Mon, 10 Sep 2012 19:49:39 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-9.tower-174.messagelabs.com!1347306577!28078561!1
X-Originating-IP: [63.239.67.9]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21144 invoked from network); 10 Sep 2012 19:49:38 -0000
Received: from emvm-gh1-uea08.nsa.gov (HELO nsa.gov) (63.239.67.9)
	by server-9.tower-174.messagelabs.com with SMTP;
	10 Sep 2012 19:49:38 -0000
X-TM-IMSS-Message-ID: <306707de000ed1bc@nsa.gov>
Received: from tarius.tycho.ncsc.mil ([144.51.3.1]) by nsa.gov ([63.239.67.9])
	with ESMTP (TREND IMSS SMTP Service 7.1) id 306707de000ed1bc ;
	Mon, 10 Sep 2012 15:49:32 -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 q8AJna3e027796; 
	Mon, 10 Sep 2012 15:49:36 -0400
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xen.org
Date: Mon, 10 Sep 2012 15:48:55 -0400
Message-Id: <1347306553-20980-3-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.11.4
In-Reply-To: <1347306553-20980-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1347306553-20980-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: [Xen-devel] [PATCH 02/20] xsm/flask: remove unneeded create_sid
	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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This field was only used to populate the ssid of dom0, which can be
handled explicitly in the domain creation hook. This also removes the
unnecessary permission check on the creation of dom0.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 tools/flask/policy/policy/modules/xen/xen.te |  2 --
 xen/xsm/flask/hooks.c                        | 23 ++++++++++-------------
 xen/xsm/flask/include/objsec.h               |  1 -
 3 files changed, 10 insertions(+), 16 deletions(-)

diff --git a/tools/flask/policy/policy/modules/xen/xen.te b/tools/flask/policy/policy/modules/xen/xen.te
index e175d4b..9cc5240 100644
--- a/tools/flask/policy/policy/modules/xen/xen.te
+++ b/tools/flask/policy/policy/modules/xen/xen.te
@@ -52,8 +52,6 @@ type device_t, resource_type;
 # Rules required to boot the hypervisor and dom0
 #
 ################################################################################
-allow xen_t dom0_t:domain { create };
-
 allow dom0_t xen_t:xen { kexec readapic writeapic mtrr_read mtrr_add mtrr_del
 	scheduler physinfo heap quirk readconsole writeconsole settime getcpuinfo
 	microcode cpupool_op sched_op pm_op };
diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
index 8c853de..88fef9c 100644
--- a/xen/xsm/flask/hooks.c
+++ b/xen/xsm/flask/hooks.c
@@ -108,12 +108,10 @@ static int flask_domain_alloc_security(struct domain *d)
 
     memset(dsec, 0, sizeof(struct domain_security_struct));
 
-    dsec->create_sid = SECSID_NULL;
     switch ( d->domain_id )
     {
     case DOMID_IDLE:
         dsec->sid = SECINITSID_XEN;
-        dsec->create_sid = SECINITSID_DOM0;
         break;
     case DOMID_XEN:
         dsec->sid = SECINITSID_DOMXEN;
@@ -489,25 +487,24 @@ static int flask_domain_create(struct domain *d, u32 ssidref)
     int rc;
     struct domain_security_struct *dsec1;
     struct domain_security_struct *dsec2;
+    static int dom0_created = 0;
 
     dsec1 = current->domain->ssid;
+    dsec2 = d->ssid;
 
-    if ( dsec1->create_sid == SECSID_NULL ) 
-        dsec1->create_sid = ssidref;
+    if ( is_idle_domain(current->domain) && !dom0_created )
+    {
+        dsec2->sid = SECINITSID_DOM0;
+        dom0_created = 1;
+        return 0;
+    }
 
-    rc = avc_has_perm(dsec1->sid, dsec1->create_sid, SECCLASS_DOMAIN, 
+    rc = avc_has_perm(dsec1->sid, ssidref, SECCLASS_DOMAIN,
                       DOMAIN__CREATE, NULL);
     if ( rc )
-    {
-        dsec1->create_sid = SECSID_NULL;
         return rc;
-    }
-
-    dsec2 = d->ssid;
-    dsec2->sid = dsec1->create_sid;
 
-    dsec1->create_sid = SECSID_NULL;
-    dsec2->create_sid = SECSID_NULL;
+    dsec2->sid = ssidref;
 
     return rc;
 }
diff --git a/xen/xsm/flask/include/objsec.h b/xen/xsm/flask/include/objsec.h
index df5baee..4ff52be 100644
--- a/xen/xsm/flask/include/objsec.h
+++ b/xen/xsm/flask/include/objsec.h
@@ -19,7 +19,6 @@
 
 struct domain_security_struct {
     u32 sid;               /* current SID */
-    u32 create_sid;
 };
 
 struct evtchn_security_struct {
-- 
1.7.11.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 10 19:49:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Sep 2012 19:49: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 1TB9zN-0001Cb-Fd; Mon, 10 Sep 2012 19:49:45 +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 1TB9zL-0001AA-Aa
	for xen-devel@lists.xen.org; Mon, 10 Sep 2012 19:49:43 +0000
Received: from [85.158.138.51:26998] by server-11.bemta-3.messagelabs.com id
	7A/D8-30250-6544E405; Mon, 10 Sep 2012 19:49:42 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-6.tower-174.messagelabs.com!1347306581!21731055!1
X-Originating-IP: [63.239.67.9]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30050 invoked from network); 10 Sep 2012 19:49:41 -0000
Received: from emvm-gh1-uea08.nsa.gov (HELO nsa.gov) (63.239.67.9)
	by server-6.tower-174.messagelabs.com with SMTP;
	10 Sep 2012 19:49:41 -0000
X-TM-IMSS-Message-ID: <30671352000ed1c1@nsa.gov>
Received: from tarius.tycho.ncsc.mil ([144.51.3.1]) by nsa.gov ([63.239.67.9])
	with ESMTP (TREND IMSS SMTP Service 7.1) id 30671352000ed1c1 ;
	Mon, 10 Sep 2012 15:49:35 -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 q8AJna3l027796; 
	Mon, 10 Sep 2012 15:49:39 -0400
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xen.org
Date: Mon, 10 Sep 2012 15:49:02 -0400
Message-Id: <1347306553-20980-10-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.11.4
In-Reply-To: <1347306553-20980-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1347306553-20980-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: [Xen-devel] [PATCH 09/20] xsm/flask: Add checks on the domain
	performing the set_target 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>
MIME-Version: 1.0
Content-Type: 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 existing domain__set_target check only verifies that the source and
target domains can be associated. We also need to check that the
privileged domain making this association is allowed to do so.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 tools/flask/policy/policy/flask/access_vectors | 2 ++
 xen/xsm/flask/hooks.c                          | 7 +++++++
 xen/xsm/flask/include/av_perm_to_string.h      | 2 ++
 xen/xsm/flask/include/av_permissions.h         | 2 ++
 4 files changed, 13 insertions(+)

diff --git a/tools/flask/policy/policy/flask/access_vectors b/tools/flask/policy/policy/flask/access_vectors
index c7e29ab..11d02da 100644
--- a/tools/flask/policy/policy/flask/access_vectors
+++ b/tools/flask/policy/policy/flask/access_vectors
@@ -78,6 +78,8 @@ class domain2
 	relabelfrom
 	relabelto
 	relabelself
+	make_priv_for
+	set_as_target
 }
 
 class hvm
diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
index 74c9271..6d4b4f0 100644
--- a/xen/xsm/flask/hooks.c
+++ b/xen/xsm/flask/hooks.c
@@ -577,6 +577,13 @@ static int flask_domain_settime(struct domain *d)
 
 static int flask_set_target(struct domain *d, struct domain *e)
 {
+    int rc;
+    rc = domain_has_perm(current->domain, d, SECCLASS_DOMAIN2, DOMAIN2__MAKE_PRIV_FOR);
+    if ( rc )
+        return rc;
+    rc = domain_has_perm(current->domain, e, SECCLASS_DOMAIN2, DOMAIN2__SET_AS_TARGET);
+    if ( rc )
+        return rc;
     return domain_has_perm(d, e, SECCLASS_DOMAIN, DOMAIN__SET_TARGET);
 }
 
diff --git a/xen/xsm/flask/include/av_perm_to_string.h b/xen/xsm/flask/include/av_perm_to_string.h
index e7e2058..10f8e80 100644
--- a/xen/xsm/flask/include/av_perm_to_string.h
+++ b/xen/xsm/flask/include/av_perm_to_string.h
@@ -64,6 +64,8 @@
    S_(SECCLASS_DOMAIN2, DOMAIN2__RELABELFROM, "relabelfrom")
    S_(SECCLASS_DOMAIN2, DOMAIN2__RELABELTO, "relabelto")
    S_(SECCLASS_DOMAIN2, DOMAIN2__RELABELSELF, "relabelself")
+   S_(SECCLASS_DOMAIN2, DOMAIN2__MAKE_PRIV_FOR, "make_priv_for")
+   S_(SECCLASS_DOMAIN2, DOMAIN2__SET_AS_TARGET, "set_as_target")
    S_(SECCLASS_HVM, HVM__SETHVMC, "sethvmc")
    S_(SECCLASS_HVM, HVM__GETHVMC, "gethvmc")
    S_(SECCLASS_HVM, HVM__SETPARAM, "setparam")
diff --git a/xen/xsm/flask/include/av_permissions.h b/xen/xsm/flask/include/av_permissions.h
index cb1c5dc..f7cfee1 100644
--- a/xen/xsm/flask/include/av_permissions.h
+++ b/xen/xsm/flask/include/av_permissions.h
@@ -66,6 +66,8 @@
 #define DOMAIN2__RELABELFROM                      0x00000001UL
 #define DOMAIN2__RELABELTO                        0x00000002UL
 #define DOMAIN2__RELABELSELF                      0x00000004UL
+#define DOMAIN2__MAKE_PRIV_FOR                    0x00000008UL
+#define DOMAIN2__SET_AS_TARGET                    0x00000010UL
 
 #define HVM__SETHVMC                              0x00000001UL
 #define HVM__GETHVMC                              0x00000002UL
-- 
1.7.11.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 10 19:49:58 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Sep 2012 19:49:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TB9zM-0001Bf-MV; Mon, 10 Sep 2012 19:49:44 +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 1TB9zK-0001A4-SK
	for xen-devel@lists.xen.org; Mon, 10 Sep 2012 19:49:42 +0000
Received: from [85.158.143.99:4154] by server-2.bemta-4.messagelabs.com id
	63/54-21239-6544E405; Mon, 10 Sep 2012 19:49:42 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-8.tower-216.messagelabs.com!1347306581!19823865!1
X-Originating-IP: [63.239.67.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9559 invoked from network); 10 Sep 2012 19:49:41 -0000
Received: from emvm-gh1-uea09.nsa.gov (HELO nsa.gov) (63.239.67.10)
	by server-8.tower-216.messagelabs.com with SMTP;
	10 Sep 2012 19:49:41 -0000
X-TM-IMSS-Message-ID: <3066cfcd000f225f@nsa.gov>
Received: from tarius.tycho.ncsc.mil ([144.51.3.1]) by nsa.gov
	([63.239.67.10]) with ESMTP (TREND IMSS SMTP Service 7.1) id
	3066cfcd000f225f ; Mon, 10 Sep 2012 15:51: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 q8AJna3k027796; 
	Mon, 10 Sep 2012 15:49:39 -0400
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xen.org
Date: Mon, 10 Sep 2012 15:49:01 -0400
Message-Id: <1347306553-20980-9-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.11.4
In-Reply-To: <1347306553-20980-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1347306553-20980-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>, Keir Fraser <keir@xen.org>,
	Jan Beulich <jbeulich@suse.com>
Subject: [Xen-devel] [PATCH 08/20] arch/x86: add missing XSM checks to
	XENPF_ commands
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Cc: Keir Fraser <keir@xen.org>
Cc: Jan Beulich <jbeulich@suse.com>
---
 xen/arch/x86/platform_hypercall.c | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/xen/arch/x86/platform_hypercall.c b/xen/arch/x86/platform_hypercall.c
index 88880b0..c049db7 100644
--- a/xen/arch/x86/platform_hypercall.c
+++ b/xen/arch/x86/platform_hypercall.c
@@ -501,6 +501,10 @@ ret_t do_platform_op(XEN_GUEST_HANDLE(xen_platform_op_t) u_xenpf_op)
     {
         struct xenpf_pcpu_version *ver = &op->u.pcpu_version;
 
+        ret = xsm_getcpuinfo();
+        if ( ret )
+            break;
+
         if ( !get_cpu_maps() )
         {
             ret = -EBUSY;
@@ -618,6 +622,10 @@ ret_t do_platform_op(XEN_GUEST_HANDLE(xen_platform_op_t) u_xenpf_op)
     {
         uint32_t idle_nums;
 
+        ret = xsm_pm_op();
+        if ( ret )
+            break;
+
         switch(op->u.core_parking.type)
         {
         case XEN_CORE_PARKING_SET:
-- 
1.7.11.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 10 19:49:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Sep 2012 19:49: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 1TB9zN-0001Cb-Fd; Mon, 10 Sep 2012 19:49:45 +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 1TB9zL-0001AA-Aa
	for xen-devel@lists.xen.org; Mon, 10 Sep 2012 19:49:43 +0000
Received: from [85.158.138.51:26998] by server-11.bemta-3.messagelabs.com id
	7A/D8-30250-6544E405; Mon, 10 Sep 2012 19:49:42 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-6.tower-174.messagelabs.com!1347306581!21731055!1
X-Originating-IP: [63.239.67.9]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30050 invoked from network); 10 Sep 2012 19:49:41 -0000
Received: from emvm-gh1-uea08.nsa.gov (HELO nsa.gov) (63.239.67.9)
	by server-6.tower-174.messagelabs.com with SMTP;
	10 Sep 2012 19:49:41 -0000
X-TM-IMSS-Message-ID: <30671352000ed1c1@nsa.gov>
Received: from tarius.tycho.ncsc.mil ([144.51.3.1]) by nsa.gov ([63.239.67.9])
	with ESMTP (TREND IMSS SMTP Service 7.1) id 30671352000ed1c1 ;
	Mon, 10 Sep 2012 15:49:35 -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 q8AJna3l027796; 
	Mon, 10 Sep 2012 15:49:39 -0400
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xen.org
Date: Mon, 10 Sep 2012 15:49:02 -0400
Message-Id: <1347306553-20980-10-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.11.4
In-Reply-To: <1347306553-20980-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1347306553-20980-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: [Xen-devel] [PATCH 09/20] xsm/flask: Add checks on the domain
	performing the set_target 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>
MIME-Version: 1.0
Content-Type: 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 existing domain__set_target check only verifies that the source and
target domains can be associated. We also need to check that the
privileged domain making this association is allowed to do so.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 tools/flask/policy/policy/flask/access_vectors | 2 ++
 xen/xsm/flask/hooks.c                          | 7 +++++++
 xen/xsm/flask/include/av_perm_to_string.h      | 2 ++
 xen/xsm/flask/include/av_permissions.h         | 2 ++
 4 files changed, 13 insertions(+)

diff --git a/tools/flask/policy/policy/flask/access_vectors b/tools/flask/policy/policy/flask/access_vectors
index c7e29ab..11d02da 100644
--- a/tools/flask/policy/policy/flask/access_vectors
+++ b/tools/flask/policy/policy/flask/access_vectors
@@ -78,6 +78,8 @@ class domain2
 	relabelfrom
 	relabelto
 	relabelself
+	make_priv_for
+	set_as_target
 }
 
 class hvm
diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
index 74c9271..6d4b4f0 100644
--- a/xen/xsm/flask/hooks.c
+++ b/xen/xsm/flask/hooks.c
@@ -577,6 +577,13 @@ static int flask_domain_settime(struct domain *d)
 
 static int flask_set_target(struct domain *d, struct domain *e)
 {
+    int rc;
+    rc = domain_has_perm(current->domain, d, SECCLASS_DOMAIN2, DOMAIN2__MAKE_PRIV_FOR);
+    if ( rc )
+        return rc;
+    rc = domain_has_perm(current->domain, e, SECCLASS_DOMAIN2, DOMAIN2__SET_AS_TARGET);
+    if ( rc )
+        return rc;
     return domain_has_perm(d, e, SECCLASS_DOMAIN, DOMAIN__SET_TARGET);
 }
 
diff --git a/xen/xsm/flask/include/av_perm_to_string.h b/xen/xsm/flask/include/av_perm_to_string.h
index e7e2058..10f8e80 100644
--- a/xen/xsm/flask/include/av_perm_to_string.h
+++ b/xen/xsm/flask/include/av_perm_to_string.h
@@ -64,6 +64,8 @@
    S_(SECCLASS_DOMAIN2, DOMAIN2__RELABELFROM, "relabelfrom")
    S_(SECCLASS_DOMAIN2, DOMAIN2__RELABELTO, "relabelto")
    S_(SECCLASS_DOMAIN2, DOMAIN2__RELABELSELF, "relabelself")
+   S_(SECCLASS_DOMAIN2, DOMAIN2__MAKE_PRIV_FOR, "make_priv_for")
+   S_(SECCLASS_DOMAIN2, DOMAIN2__SET_AS_TARGET, "set_as_target")
    S_(SECCLASS_HVM, HVM__SETHVMC, "sethvmc")
    S_(SECCLASS_HVM, HVM__GETHVMC, "gethvmc")
    S_(SECCLASS_HVM, HVM__SETPARAM, "setparam")
diff --git a/xen/xsm/flask/include/av_permissions.h b/xen/xsm/flask/include/av_permissions.h
index cb1c5dc..f7cfee1 100644
--- a/xen/xsm/flask/include/av_permissions.h
+++ b/xen/xsm/flask/include/av_permissions.h
@@ -66,6 +66,8 @@
 #define DOMAIN2__RELABELFROM                      0x00000001UL
 #define DOMAIN2__RELABELTO                        0x00000002UL
 #define DOMAIN2__RELABELSELF                      0x00000004UL
+#define DOMAIN2__MAKE_PRIV_FOR                    0x00000008UL
+#define DOMAIN2__SET_AS_TARGET                    0x00000010UL
 
 #define HVM__SETHVMC                              0x00000001UL
 #define HVM__GETHVMC                              0x00000002UL
-- 
1.7.11.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 10 19:49:58 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Sep 2012 19:49:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TB9zM-0001Bf-MV; Mon, 10 Sep 2012 19:49:44 +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 1TB9zK-0001A4-SK
	for xen-devel@lists.xen.org; Mon, 10 Sep 2012 19:49:42 +0000
Received: from [85.158.143.99:4154] by server-2.bemta-4.messagelabs.com id
	63/54-21239-6544E405; Mon, 10 Sep 2012 19:49:42 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-8.tower-216.messagelabs.com!1347306581!19823865!1
X-Originating-IP: [63.239.67.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9559 invoked from network); 10 Sep 2012 19:49:41 -0000
Received: from emvm-gh1-uea09.nsa.gov (HELO nsa.gov) (63.239.67.10)
	by server-8.tower-216.messagelabs.com with SMTP;
	10 Sep 2012 19:49:41 -0000
X-TM-IMSS-Message-ID: <3066cfcd000f225f@nsa.gov>
Received: from tarius.tycho.ncsc.mil ([144.51.3.1]) by nsa.gov
	([63.239.67.10]) with ESMTP (TREND IMSS SMTP Service 7.1) id
	3066cfcd000f225f ; Mon, 10 Sep 2012 15:51: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 q8AJna3k027796; 
	Mon, 10 Sep 2012 15:49:39 -0400
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xen.org
Date: Mon, 10 Sep 2012 15:49:01 -0400
Message-Id: <1347306553-20980-9-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.11.4
In-Reply-To: <1347306553-20980-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1347306553-20980-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>, Keir Fraser <keir@xen.org>,
	Jan Beulich <jbeulich@suse.com>
Subject: [Xen-devel] [PATCH 08/20] arch/x86: add missing XSM checks to
	XENPF_ commands
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Cc: Keir Fraser <keir@xen.org>
Cc: Jan Beulich <jbeulich@suse.com>
---
 xen/arch/x86/platform_hypercall.c | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/xen/arch/x86/platform_hypercall.c b/xen/arch/x86/platform_hypercall.c
index 88880b0..c049db7 100644
--- a/xen/arch/x86/platform_hypercall.c
+++ b/xen/arch/x86/platform_hypercall.c
@@ -501,6 +501,10 @@ ret_t do_platform_op(XEN_GUEST_HANDLE(xen_platform_op_t) u_xenpf_op)
     {
         struct xenpf_pcpu_version *ver = &op->u.pcpu_version;
 
+        ret = xsm_getcpuinfo();
+        if ( ret )
+            break;
+
         if ( !get_cpu_maps() )
         {
             ret = -EBUSY;
@@ -618,6 +622,10 @@ ret_t do_platform_op(XEN_GUEST_HANDLE(xen_platform_op_t) u_xenpf_op)
     {
         uint32_t idle_nums;
 
+        ret = xsm_pm_op();
+        if ( ret )
+            break;
+
         switch(op->u.core_parking.type)
         {
         case XEN_CORE_PARKING_SET:
-- 
1.7.11.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 10 19:49:58 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Sep 2012 19:49:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TB9zQ-0001Fu-6y; Mon, 10 Sep 2012 19:49:48 +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 1TB9zO-0001Ck-2d
	for xen-devel@lists.xen.org; Mon, 10 Sep 2012 19:49:46 +0000
Received: from [85.158.138.51:12369] by server-4.bemta-3.messagelabs.com id
	F9/27-24831-9544E405; Mon, 10 Sep 2012 19:49:45 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-6.tower-174.messagelabs.com!1347306583!21731058!1
X-Originating-IP: [63.239.67.9]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30096 invoked from network); 10 Sep 2012 19:49:44 -0000
Received: from emvm-gh1-uea08.nsa.gov (HELO nsa.gov) (63.239.67.9)
	by server-6.tower-174.messagelabs.com with SMTP;
	10 Sep 2012 19:49:44 -0000
X-TM-IMSS-Message-ID: <30672128000ed1c5@nsa.gov>
Received: from tarius.tycho.ncsc.mil ([144.51.3.1]) by nsa.gov ([63.239.67.9])
	with ESMTP (TREND IMSS SMTP Service 7.1) id 30672128000ed1c5 ;
	Mon, 10 Sep 2012 15:49:39 -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 q8AJna3v027796; 
	Mon, 10 Sep 2012 15:49:43 -0400
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xen.org
Date: Mon, 10 Sep 2012 15:49:12 -0400
Message-Id: <1347306553-20980-20-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.11.4
In-Reply-To: <1347306553-20980-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1347306553-20980-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: [Xen-devel] [PATCH 19/20] xen: remove rcu_lock_{remote_,
	}target_domain_by_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>
MIME-Version: 1.0
Content-Type: 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 functions are now (mostly) unused, replaced by versions without
an implicit access control check. Make the checks explicit in the
remaining callers.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 xen/arch/x86/physdev.c  | 18 +++++++++++-------
 xen/common/domain.c     | 34 ----------------------------------
 xen/include/xen/sched.h | 14 --------------
 3 files changed, 11 insertions(+), 55 deletions(-)

diff --git a/xen/arch/x86/physdev.c b/xen/arch/x86/physdev.c
index d6ea4f0..4dfb5a0 100644
--- a/xen/arch/x86/physdev.c
+++ b/xen/arch/x86/physdev.c
@@ -106,9 +106,11 @@ int physdev_map_pirq(domid_t domid, int type, int *index, int *pirq_p,
         return physdev_hvm_map_pirq(d, type, index, pirq_p);
     }
 
-    ret = rcu_lock_target_domain_by_id(domid, &d);
-    if ( ret )
-        return ret;
+    d = rcu_lock_domain_by_any_id(domid);
+    if ( d == NULL )
+        return -ESRCH;
+    if ( d != current->domain && !IS_PRIV_FOR(current->domain, d) )
+        return -EPERM;
 
     /* Verify or get irq. */
     switch ( type )
@@ -217,11 +219,13 @@ int physdev_map_pirq(domid_t domid, int type, int *index, int *pirq_p,
 int physdev_unmap_pirq(domid_t domid, int pirq)
 {
     struct domain *d;
-    int ret;
+    int ret = 0;
 
-    ret = rcu_lock_target_domain_by_id(domid, &d);
-    if ( ret )
-        return ret;
+    d = rcu_lock_domain_by_any_id(domid);
+    if ( d == NULL )
+        return -ESRCH;
+    if ( d != current->domain && !IS_PRIV_FOR(current->domain, d) )
+        return -EPERM;
 
     if ( is_hvm_domain(d) )
     {
diff --git a/xen/common/domain.c b/xen/common/domain.c
index 52489b3..ecfc6d6 100644
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -427,40 +427,6 @@ struct domain *rcu_lock_domain_by_any_id(domid_t dom)
     return rcu_lock_domain_by_id(dom);
 }
 
-int rcu_lock_target_domain_by_id(domid_t dom, struct domain **d)
-{
-    if ( dom == DOMID_SELF )
-    {
-        *d = rcu_lock_current_domain();
-        return 0;
-    }
-
-    if ( (*d = rcu_lock_domain_by_id(dom)) == NULL )
-        return -ESRCH;
-
-    if ( !IS_PRIV_FOR(current->domain, *d) )
-    {
-        rcu_unlock_domain(*d);
-        return -EPERM;
-    }
-
-    return 0;
-}
-
-int rcu_lock_remote_target_domain_by_id(domid_t dom, struct domain **d)
-{
-    if ( (*d = rcu_lock_domain_by_id(dom)) == NULL )
-        return -ESRCH;
-
-    if ( (*d == current->domain) || !IS_PRIV_FOR(current->domain, *d) )
-    {
-        rcu_unlock_domain(*d);
-        return -EPERM;
-    }
-
-    return 0;
-}
-
 int rcu_lock_remote_domain_by_id(domid_t dom, struct domain **d)
 {
     if ( (*d = rcu_lock_domain_by_id(dom)) == NULL )
diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
index b0def4a..9019c21 100644
--- a/xen/include/xen/sched.h
+++ b/xen/include/xen/sched.h
@@ -452,20 +452,6 @@ struct domain *rcu_lock_domain_by_id(domid_t dom);
 struct domain *rcu_lock_domain_by_any_id(domid_t dom);
 
 /*
- * As above function, but accounts for current domain context:
- *  - Translates target DOMID_SELF into caller's domain id; and
- *  - Checks that caller has permission to act on the target domain.
- */
-int rcu_lock_target_domain_by_id(domid_t dom, struct domain **d);
-
-/*
- * As rcu_lock_target_domain_by_id(), but will fail EPERM rather than resolve
- * to local domain. Successful return always resolves to a remote domain that
- * the local domain is privileged to control.
- */
-int rcu_lock_remote_target_domain_by_id(domid_t dom, struct domain **d);
-
-/*
  * As rcu_lock_domain_by_id(), but will fail EPERM or ESRCH rather than resolve
  * to local domain.
  */
-- 
1.7.11.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 10 19:49:58 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Sep 2012 19:49:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TB9zQ-0001Fu-6y; Mon, 10 Sep 2012 19:49:48 +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 1TB9zO-0001Ck-2d
	for xen-devel@lists.xen.org; Mon, 10 Sep 2012 19:49:46 +0000
Received: from [85.158.138.51:12369] by server-4.bemta-3.messagelabs.com id
	F9/27-24831-9544E405; Mon, 10 Sep 2012 19:49:45 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-6.tower-174.messagelabs.com!1347306583!21731058!1
X-Originating-IP: [63.239.67.9]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30096 invoked from network); 10 Sep 2012 19:49:44 -0000
Received: from emvm-gh1-uea08.nsa.gov (HELO nsa.gov) (63.239.67.9)
	by server-6.tower-174.messagelabs.com with SMTP;
	10 Sep 2012 19:49:44 -0000
X-TM-IMSS-Message-ID: <30672128000ed1c5@nsa.gov>
Received: from tarius.tycho.ncsc.mil ([144.51.3.1]) by nsa.gov ([63.239.67.9])
	with ESMTP (TREND IMSS SMTP Service 7.1) id 30672128000ed1c5 ;
	Mon, 10 Sep 2012 15:49:39 -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 q8AJna3v027796; 
	Mon, 10 Sep 2012 15:49:43 -0400
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xen.org
Date: Mon, 10 Sep 2012 15:49:12 -0400
Message-Id: <1347306553-20980-20-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.11.4
In-Reply-To: <1347306553-20980-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1347306553-20980-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: [Xen-devel] [PATCH 19/20] xen: remove rcu_lock_{remote_,
	}target_domain_by_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>
MIME-Version: 1.0
Content-Type: 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 functions are now (mostly) unused, replaced by versions without
an implicit access control check. Make the checks explicit in the
remaining callers.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 xen/arch/x86/physdev.c  | 18 +++++++++++-------
 xen/common/domain.c     | 34 ----------------------------------
 xen/include/xen/sched.h | 14 --------------
 3 files changed, 11 insertions(+), 55 deletions(-)

diff --git a/xen/arch/x86/physdev.c b/xen/arch/x86/physdev.c
index d6ea4f0..4dfb5a0 100644
--- a/xen/arch/x86/physdev.c
+++ b/xen/arch/x86/physdev.c
@@ -106,9 +106,11 @@ int physdev_map_pirq(domid_t domid, int type, int *index, int *pirq_p,
         return physdev_hvm_map_pirq(d, type, index, pirq_p);
     }
 
-    ret = rcu_lock_target_domain_by_id(domid, &d);
-    if ( ret )
-        return ret;
+    d = rcu_lock_domain_by_any_id(domid);
+    if ( d == NULL )
+        return -ESRCH;
+    if ( d != current->domain && !IS_PRIV_FOR(current->domain, d) )
+        return -EPERM;
 
     /* Verify or get irq. */
     switch ( type )
@@ -217,11 +219,13 @@ int physdev_map_pirq(domid_t domid, int type, int *index, int *pirq_p,
 int physdev_unmap_pirq(domid_t domid, int pirq)
 {
     struct domain *d;
-    int ret;
+    int ret = 0;
 
-    ret = rcu_lock_target_domain_by_id(domid, &d);
-    if ( ret )
-        return ret;
+    d = rcu_lock_domain_by_any_id(domid);
+    if ( d == NULL )
+        return -ESRCH;
+    if ( d != current->domain && !IS_PRIV_FOR(current->domain, d) )
+        return -EPERM;
 
     if ( is_hvm_domain(d) )
     {
diff --git a/xen/common/domain.c b/xen/common/domain.c
index 52489b3..ecfc6d6 100644
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -427,40 +427,6 @@ struct domain *rcu_lock_domain_by_any_id(domid_t dom)
     return rcu_lock_domain_by_id(dom);
 }
 
-int rcu_lock_target_domain_by_id(domid_t dom, struct domain **d)
-{
-    if ( dom == DOMID_SELF )
-    {
-        *d = rcu_lock_current_domain();
-        return 0;
-    }
-
-    if ( (*d = rcu_lock_domain_by_id(dom)) == NULL )
-        return -ESRCH;
-
-    if ( !IS_PRIV_FOR(current->domain, *d) )
-    {
-        rcu_unlock_domain(*d);
-        return -EPERM;
-    }
-
-    return 0;
-}
-
-int rcu_lock_remote_target_domain_by_id(domid_t dom, struct domain **d)
-{
-    if ( (*d = rcu_lock_domain_by_id(dom)) == NULL )
-        return -ESRCH;
-
-    if ( (*d == current->domain) || !IS_PRIV_FOR(current->domain, *d) )
-    {
-        rcu_unlock_domain(*d);
-        return -EPERM;
-    }
-
-    return 0;
-}
-
 int rcu_lock_remote_domain_by_id(domid_t dom, struct domain **d)
 {
     if ( (*d = rcu_lock_domain_by_id(dom)) == NULL )
diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
index b0def4a..9019c21 100644
--- a/xen/include/xen/sched.h
+++ b/xen/include/xen/sched.h
@@ -452,20 +452,6 @@ struct domain *rcu_lock_domain_by_id(domid_t dom);
 struct domain *rcu_lock_domain_by_any_id(domid_t dom);
 
 /*
- * As above function, but accounts for current domain context:
- *  - Translates target DOMID_SELF into caller's domain id; and
- *  - Checks that caller has permission to act on the target domain.
- */
-int rcu_lock_target_domain_by_id(domid_t dom, struct domain **d);
-
-/*
- * As rcu_lock_target_domain_by_id(), but will fail EPERM rather than resolve
- * to local domain. Successful return always resolves to a remote domain that
- * the local domain is privileged to control.
- */
-int rcu_lock_remote_target_domain_by_id(domid_t dom, struct domain **d);
-
-/*
  * As rcu_lock_domain_by_id(), but will fail EPERM or ESRCH rather than resolve
  * to local domain.
  */
-- 
1.7.11.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 10 19:49:59 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Sep 2012 19: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 1TB9zK-0001A0-AK; Mon, 10 Sep 2012 19:49:42 +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 1TB9zI-00019F-BB
	for xen-devel@lists.xen.org; Mon, 10 Sep 2012 19:49:40 +0000
Received: from [85.158.143.99:27848] by server-1.bemta-4.messagelabs.com id
	DD/F4-12504-3544E405; Mon, 10 Sep 2012 19:49:39 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-6.tower-216.messagelabs.com!1347306578!22574381!1
X-Originating-IP: [63.239.67.10]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16493 invoked from network); 10 Sep 2012 19:49:38 -0000
Received: from emvm-gh1-uea09.nsa.gov (HELO nsa.gov) (63.239.67.10)
	by server-6.tower-216.messagelabs.com with SMTP;
	10 Sep 2012 19:49:38 -0000
X-TM-IMSS-Message-ID: <3066c439000f225a@nsa.gov>
Received: from tarius.tycho.ncsc.mil ([144.51.3.1]) by nsa.gov
	([63.239.67.10]) with ESMTP (TREND IMSS SMTP Service 7.1) id
	3066c439000f225a ; Mon, 10 Sep 2012 15:51:48 -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 q8AJna3d027796; 
	Mon, 10 Sep 2012 15:49:36 -0400
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xen.org
Date: Mon, 10 Sep 2012 15:48:54 -0400
Message-Id: <1347306553-20980-2-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.11.4
In-Reply-To: <1347306553-20980-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1347306553-20980-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: [Xen-devel] [PATCH 01/20] xsm/flask: remove inherited class
	attributes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 ability to declare common permission blocks shared across multiple
classes is not currently used in Xen. Currently, support for this
feature is broken in the header generation scripts, and it is not
expected that this feature will be used in the future, so remove the
dead code.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 tools/flask/policy/policy/flask/Makefile           |  2 +-
 tools/flask/policy/policy/flask/access_vectors     | 17 +----
 tools/flask/policy/policy/flask/mkaccess_vector.sh | 89 ----------------------
 xen/xsm/flask/avc.c                                | 27 -------
 xen/xsm/flask/include/av_inherit.h                 |  1 -
 xen/xsm/flask/include/avc_ss.h                     |  8 --
 xen/xsm/flask/include/common_perm_to_string.h      |  1 -
 xen/xsm/flask/ss/services.c                        | 54 +------------
 8 files changed, 4 insertions(+), 195 deletions(-)
 delete mode 100644 xen/xsm/flask/include/av_inherit.h
 delete mode 100644 xen/xsm/flask/include/common_perm_to_string.h

diff --git a/tools/flask/policy/policy/flask/Makefile b/tools/flask/policy/policy/flask/Makefile
index 970b9fe..5f57e88 100644
--- a/tools/flask/policy/policy/flask/Makefile
+++ b/tools/flask/policy/policy/flask/Makefile
@@ -14,7 +14,7 @@ FLASK_H_DEPEND = security_classes initial_sids
 AV_H_DEPEND = access_vectors
 
 FLASK_H_FILES = class_to_string.h flask.h initial_sid_to_string.h
-AV_H_FILES = av_inherit.h common_perm_to_string.h av_perm_to_string.h av_permissions.h
+AV_H_FILES = av_perm_to_string.h av_permissions.h
 ALL_H_FILES = $(FLASK_H_FILES) $(AV_H_FILES)
 
 all:  $(ALL_H_FILES)
diff --git a/tools/flask/policy/policy/flask/access_vectors b/tools/flask/policy/policy/flask/access_vectors
index 5901911..a884312 100644
--- a/tools/flask/policy/policy/flask/access_vectors
+++ b/tools/flask/policy/policy/flask/access_vectors
@@ -1,22 +1,7 @@
 #
-# Define common prefixes for access vectors
-#
-# common common_name { permission_name ... }
-
-#
-# Define a common prefix for file access vectors.
-#
-
-
-#
 # Define the access vectors.
 #
-# class class_name [ inherits common_name ] { permission_name ... }
-
-
-#
-# Define the access vector interpretation for file-related objects.
-#
+# class class_name { permission_name ... }
 
 class xen
 {
diff --git a/tools/flask/policy/policy/flask/mkaccess_vector.sh b/tools/flask/policy/policy/flask/mkaccess_vector.sh
index b5da734..43a60a7 100644
--- a/tools/flask/policy/policy/flask/mkaccess_vector.sh
+++ b/tools/flask/policy/policy/flask/mkaccess_vector.sh
@@ -10,50 +10,21 @@ shift
 
 # output files
 av_permissions="av_permissions.h"
-av_inherit="av_inherit.h"
-common_perm_to_string="common_perm_to_string.h"
 av_perm_to_string="av_perm_to_string.h"
 
 cat $* | $awk "
 BEGIN	{
 		outfile = \"$av_permissions\"
-		inheritfile = \"$av_inherit\"
-		cpermfile = \"$common_perm_to_string\"
 		avpermfile = \"$av_perm_to_string\"
 		"'
 		nextstate = "COMMON_OR_AV";
 		printf("/* This file is automatically generated.  Do not edit. */\n") > outfile;
-		printf("/* This file is automatically generated.  Do not edit. */\n") > inheritfile;
-		printf("/* This file is automatically generated.  Do not edit. */\n") > cpermfile;
 		printf("/* This file is automatically generated.  Do not edit. */\n") > avpermfile;
 ;
 	}
 /^[ \t]*#/	{ 
 			next;
 		}
-$1 == "common"	{ 
-			if (nextstate != "COMMON_OR_AV")
-			{
-				printf("Parse error:  Unexpected COMMON definition on line %d\n", NR);
-				next;	
-			}
-
-			if ($2 in common_defined)
-			{
-				printf("Duplicate COMMON definition for %s on line %d.\n", $2, NR);
-				next;
-			}	
-			common_defined[$2] = 1;
-
-			tclass = $2;
-			common_name = $2; 
-			permission = 1;
-
-			printf("TB_(common_%s_perm_to_string)\n", $2) > cpermfile;
-
-			nextstate = "COMMON-OPENBRACKET";
-			next;
-		}
 $1 == "class"	{
 			if (nextstate != "COMMON_OR_AV" &&
 			    nextstate != "CLASS_OR_CLASS-OPENBRACKET")
@@ -71,62 +42,11 @@ $1 == "class"	{
 			} 
 			av_defined[tclass] = 1;
 
-			inherits = "";
 			permission = 1;
 
 			nextstate = "INHERITS_OR_CLASS-OPENBRACKET";
 			next;
 		}
-$1 == "inherits" {			
-			if (nextstate != "INHERITS_OR_CLASS-OPENBRACKET")
-			{
-				printf("Parse error:  Unexpected INHERITS definition on line %d\n", NR);
-				next;	
-			}
-
-			if (!($2 in common_defined))
-			{
-				printf("COMMON %s is not defined (line %d).\n", $2, NR);
-				next;
-			}
-
-			inherits = $2;
-			permission = common_base[$2];
-
-			for (combined in common_perms)
-			{
-				split(combined,separate, SUBSEP);
-				if (separate[1] == inherits)
-				{
-					inherited_perms[common_perms[combined]] = separate[2];
-				}
-			}
-
-                        j = 1;
-                        for (i in inherited_perms) {
-                            ind[j] = i + 0;
-                            j++;
-                        }
-                        n = asort(ind);
-			for (i = 1; i <= n; i++) {
-				perm = inherited_perms[ind[i]];
-				printf("#define %s__%s", toupper(tclass), toupper(perm)) > outfile; 
-				spaces = 40 - (length(perm) + length(tclass));
-				if (spaces < 1)
-				      spaces = 1;
-				for (j = 0; j < spaces; j++) 
-					printf(" ") > outfile; 
-				printf("0x%08xUL\n", ind[i]) > outfile; 
-			}
-			printf("\n") > outfile;
-                        for (i in ind) delete ind[i];
-                        for (i in inherited_perms) delete inherited_perms[i];
-
-			printf("   S_(SECCLASS_%s, %s, 0x%08xUL)\n", toupper(tclass), inherits, permission) > inheritfile; 
-
-			nextstate = "CLASS_OR_CLASS-OPENBRACKET";
-			next;
-		}
 $1 == "{"	{ 
 			if (nextstate != "INHERITS_OR_CLASS-OPENBRACKET" &&
 			    nextstate != "CLASS_OR_CLASS-OPENBRACKET" &&
@@ -177,15 +97,6 @@ $1 == "{"	{
 
 				av_perms[tclass,$1] = permission;
 		
-				if (inherits != "")
-				{
-					if ((inherits,$1) in common_perms)
-					{
-						printf("Permission %s in %s on line %d conflicts with common permission.\n", $1, tclass, inherits, NR);
-						next;
-					}
-				}
-
 				printf("#define %s__%s", toupper(tclass), toupper($1)) > outfile; 
 
 				printf("   S_(SECCLASS_%s, %s__%s, \"%s\")\n", toupper(tclass), toupper(tclass), toupper($1), $1) > avpermfile; 
diff --git a/xen/xsm/flask/avc.c b/xen/xsm/flask/avc.c
index 44240a9..1bfeef2 100644
--- a/xen/xsm/flask/avc.c
+++ b/xen/xsm/flask/avc.c
@@ -45,28 +45,11 @@ static const char *class_to_string[] = {
 #undef S_
 };
 
-#define TB_(s) static const char * s [] = {
-#define TE_(s) };
-#define S_(s) s,
-#include "common_perm_to_string.h"
-#undef TB_
-#undef TE_
-#undef S_
-
-static const struct av_inherit av_inherit[] = {
-#define S_(c, i, b) { .tclass = c, .common_pts = common_##i##_perm_to_string, \
-                      .common_base = b },
-#include "av_inherit.h"
-#undef S_
-};
-
 const struct selinux_class_perm selinux_class_perm = {
     .av_perm_to_string = av_perm_to_string,
     .av_pts_len = ARRAY_SIZE(av_perm_to_string),
     .class_to_string = class_to_string,
     .cts_len = ARRAY_SIZE(class_to_string),
-    .av_inherit = av_inherit,
-    .av_inherit_len = ARRAY_SIZE(av_inherit)
 };
 
 #define AVC_CACHE_SLOTS            512
@@ -191,16 +174,6 @@ static void avc_dump_av(struct avc_dump_buf *buf, u16 tclass, u32 av)
         return;
     }
 
-    for ( i = 0; i < ARRAY_SIZE(av_inherit); i++ )
-    {
-        if (av_inherit[i].tclass == tclass)
-        {
-            common_pts = av_inherit[i].common_pts;
-            common_base = av_inherit[i].common_base;
-            break;
-        }
-    }
-
     avc_printk(buf, " {");
     i = 0;
     perm = 1;
diff --git a/xen/xsm/flask/include/av_inherit.h b/xen/xsm/flask/include/av_inherit.h
deleted file mode 100644
index 321ffe7..0000000
--- a/xen/xsm/flask/include/av_inherit.h
+++ /dev/null
@@ -1 +0,0 @@
-/* This file is automatically generated.  Do not edit. */
diff --git a/xen/xsm/flask/include/avc_ss.h b/xen/xsm/flask/include/avc_ss.h
index ea4e98c..a3d7d1e 100644
--- a/xen/xsm/flask/include/avc_ss.h
+++ b/xen/xsm/flask/include/avc_ss.h
@@ -16,19 +16,11 @@ struct av_perm_to_string {
     const char *name;
 };
 
-struct av_inherit {
-    const char **common_pts;
-    u32 common_base;
-    u16 tclass;
-};
-
 struct selinux_class_perm {
     const struct av_perm_to_string *av_perm_to_string;
     u32 av_pts_len;
     u32 cts_len;
     const char **class_to_string;
-    const struct av_inherit *av_inherit;
-    u32 av_inherit_len;
 };
 
 extern const struct selinux_class_perm selinux_class_perm;
diff --git a/xen/xsm/flask/include/common_perm_to_string.h b/xen/xsm/flask/include/common_perm_to_string.h
deleted file mode 100644
index 321ffe7..0000000
--- a/xen/xsm/flask/include/common_perm_to_string.h
+++ /dev/null
@@ -1 +0,0 @@
-/* This file is automatically generated.  Do not edit. */
diff --git a/xen/xsm/flask/ss/services.c b/xen/xsm/flask/ss/services.c
index 363f586..1bf3b0c 100644
--- a/xen/xsm/flask/ss/services.c
+++ b/xen/xsm/flask/ss/services.c
@@ -1167,10 +1167,10 @@ int security_change_sid(u32 ssid, u32 tsid, u16 tclass, u32 *out_sid)
  */
 static int validate_classes(struct policydb *p)
 {
-    int i, j;
+    int i;
     struct class_datum *cladatum;
     struct perm_datum *perdatum;
-    u32 nprim, tmp, common_pts_len, perm_val, pol_val;
+    u32 nprim, perm_val, pol_val;
     u16 class_val;
     const struct selinux_class_perm *kdefs = &selinux_class_perm;
     const char *def_class, *def_perm, *pol_class;
@@ -1233,56 +1233,6 @@ static int validate_classes(struct policydb *p)
             return -EINVAL;
         }
     }
-    for ( i = 0; i < kdefs->av_inherit_len; i++ )
-    {
-        class_val = kdefs->av_inherit[i].tclass;
-        if ( class_val > p->p_classes.nprim )
-            continue;
-        pol_class = p->p_class_val_to_name[class_val-1];
-        cladatum = hashtab_search(p->p_classes.table, pol_class);
-        BUG_ON( !cladatum );
-        if ( !cladatum->comdatum )
-        {
-            printk(KERN_ERR
-            "Flask:  class %s should have an inherits clause but does not\n",
-                   pol_class);
-            return -EINVAL;
-        }
-        tmp = kdefs->av_inherit[i].common_base;
-        common_pts_len = 0;
-        while ( !(tmp & 0x01) )
-        {
-            common_pts_len++;
-            tmp >>= 1;
-        }
-        perms = &cladatum->comdatum->permissions;
-        for ( j = 0; j < common_pts_len; j++ )
-        {
-            def_perm = kdefs->av_inherit[i].common_pts[j];
-            if ( j >= perms->nprim )
-            {
-                printk(KERN_INFO
-                "Flask:  permission %s in class %s not defined in policy\n",
-                       def_perm, pol_class);
-                return -EINVAL;
-            }
-            perdatum = hashtab_search(perms->table, def_perm);
-            if ( perdatum == NULL )
-            {
-                printk(KERN_ERR
-                       "Flask:  permission %s in class %s not found in policy\n",
-                       def_perm, pol_class);
-                return -EINVAL;
-            }
-            if ( perdatum->value != j + 1 )
-            {
-                printk(KERN_ERR
-                      "Flask:  permission %s in class %s has incorrect value\n",
-                       def_perm, pol_class);
-                return -EINVAL;
-            }
-        }
-    }
     return 0;
 }
 
-- 
1.7.11.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 10 19:49:59 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Sep 2012 19: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 1TB9zK-0001A0-AK; Mon, 10 Sep 2012 19:49:42 +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 1TB9zI-00019F-BB
	for xen-devel@lists.xen.org; Mon, 10 Sep 2012 19:49:40 +0000
Received: from [85.158.143.99:27848] by server-1.bemta-4.messagelabs.com id
	DD/F4-12504-3544E405; Mon, 10 Sep 2012 19:49:39 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-6.tower-216.messagelabs.com!1347306578!22574381!1
X-Originating-IP: [63.239.67.10]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16493 invoked from network); 10 Sep 2012 19:49:38 -0000
Received: from emvm-gh1-uea09.nsa.gov (HELO nsa.gov) (63.239.67.10)
	by server-6.tower-216.messagelabs.com with SMTP;
	10 Sep 2012 19:49:38 -0000
X-TM-IMSS-Message-ID: <3066c439000f225a@nsa.gov>
Received: from tarius.tycho.ncsc.mil ([144.51.3.1]) by nsa.gov
	([63.239.67.10]) with ESMTP (TREND IMSS SMTP Service 7.1) id
	3066c439000f225a ; Mon, 10 Sep 2012 15:51:48 -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 q8AJna3d027796; 
	Mon, 10 Sep 2012 15:49:36 -0400
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xen.org
Date: Mon, 10 Sep 2012 15:48:54 -0400
Message-Id: <1347306553-20980-2-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.11.4
In-Reply-To: <1347306553-20980-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1347306553-20980-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: [Xen-devel] [PATCH 01/20] xsm/flask: remove inherited class
	attributes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 ability to declare common permission blocks shared across multiple
classes is not currently used in Xen. Currently, support for this
feature is broken in the header generation scripts, and it is not
expected that this feature will be used in the future, so remove the
dead code.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 tools/flask/policy/policy/flask/Makefile           |  2 +-
 tools/flask/policy/policy/flask/access_vectors     | 17 +----
 tools/flask/policy/policy/flask/mkaccess_vector.sh | 89 ----------------------
 xen/xsm/flask/avc.c                                | 27 -------
 xen/xsm/flask/include/av_inherit.h                 |  1 -
 xen/xsm/flask/include/avc_ss.h                     |  8 --
 xen/xsm/flask/include/common_perm_to_string.h      |  1 -
 xen/xsm/flask/ss/services.c                        | 54 +------------
 8 files changed, 4 insertions(+), 195 deletions(-)
 delete mode 100644 xen/xsm/flask/include/av_inherit.h
 delete mode 100644 xen/xsm/flask/include/common_perm_to_string.h

diff --git a/tools/flask/policy/policy/flask/Makefile b/tools/flask/policy/policy/flask/Makefile
index 970b9fe..5f57e88 100644
--- a/tools/flask/policy/policy/flask/Makefile
+++ b/tools/flask/policy/policy/flask/Makefile
@@ -14,7 +14,7 @@ FLASK_H_DEPEND = security_classes initial_sids
 AV_H_DEPEND = access_vectors
 
 FLASK_H_FILES = class_to_string.h flask.h initial_sid_to_string.h
-AV_H_FILES = av_inherit.h common_perm_to_string.h av_perm_to_string.h av_permissions.h
+AV_H_FILES = av_perm_to_string.h av_permissions.h
 ALL_H_FILES = $(FLASK_H_FILES) $(AV_H_FILES)
 
 all:  $(ALL_H_FILES)
diff --git a/tools/flask/policy/policy/flask/access_vectors b/tools/flask/policy/policy/flask/access_vectors
index 5901911..a884312 100644
--- a/tools/flask/policy/policy/flask/access_vectors
+++ b/tools/flask/policy/policy/flask/access_vectors
@@ -1,22 +1,7 @@
 #
-# Define common prefixes for access vectors
-#
-# common common_name { permission_name ... }
-
-#
-# Define a common prefix for file access vectors.
-#
-
-
-#
 # Define the access vectors.
 #
-# class class_name [ inherits common_name ] { permission_name ... }
-
-
-#
-# Define the access vector interpretation for file-related objects.
-#
+# class class_name { permission_name ... }
 
 class xen
 {
diff --git a/tools/flask/policy/policy/flask/mkaccess_vector.sh b/tools/flask/policy/policy/flask/mkaccess_vector.sh
index b5da734..43a60a7 100644
--- a/tools/flask/policy/policy/flask/mkaccess_vector.sh
+++ b/tools/flask/policy/policy/flask/mkaccess_vector.sh
@@ -10,50 +10,21 @@ shift
 
 # output files
 av_permissions="av_permissions.h"
-av_inherit="av_inherit.h"
-common_perm_to_string="common_perm_to_string.h"
 av_perm_to_string="av_perm_to_string.h"
 
 cat $* | $awk "
 BEGIN	{
 		outfile = \"$av_permissions\"
-		inheritfile = \"$av_inherit\"
-		cpermfile = \"$common_perm_to_string\"
 		avpermfile = \"$av_perm_to_string\"
 		"'
 		nextstate = "COMMON_OR_AV";
 		printf("/* This file is automatically generated.  Do not edit. */\n") > outfile;
-		printf("/* This file is automatically generated.  Do not edit. */\n") > inheritfile;
-		printf("/* This file is automatically generated.  Do not edit. */\n") > cpermfile;
 		printf("/* This file is automatically generated.  Do not edit. */\n") > avpermfile;
 ;
 	}
 /^[ \t]*#/	{ 
 			next;
 		}
-$1 == "common"	{ 
-			if (nextstate != "COMMON_OR_AV")
-			{
-				printf("Parse error:  Unexpected COMMON definition on line %d\n", NR);
-				next;	
-			}
-
-			if ($2 in common_defined)
-			{
-				printf("Duplicate COMMON definition for %s on line %d.\n", $2, NR);
-				next;
-			}	
-			common_defined[$2] = 1;
-
-			tclass = $2;
-			common_name = $2; 
-			permission = 1;
-
-			printf("TB_(common_%s_perm_to_string)\n", $2) > cpermfile;
-
-			nextstate = "COMMON-OPENBRACKET";
-			next;
-		}
 $1 == "class"	{
 			if (nextstate != "COMMON_OR_AV" &&
 			    nextstate != "CLASS_OR_CLASS-OPENBRACKET")
@@ -71,62 +42,11 @@ $1 == "class"	{
 			} 
 			av_defined[tclass] = 1;
 
-			inherits = "";
 			permission = 1;
 
 			nextstate = "INHERITS_OR_CLASS-OPENBRACKET";
 			next;
 		}
-$1 == "inherits" {			
-			if (nextstate != "INHERITS_OR_CLASS-OPENBRACKET")
-			{
-				printf("Parse error:  Unexpected INHERITS definition on line %d\n", NR);
-				next;	
-			}
-
-			if (!($2 in common_defined))
-			{
-				printf("COMMON %s is not defined (line %d).\n", $2, NR);
-				next;
-			}
-
-			inherits = $2;
-			permission = common_base[$2];
-
-			for (combined in common_perms)
-			{
-				split(combined,separate, SUBSEP);
-				if (separate[1] == inherits)
-				{
-					inherited_perms[common_perms[combined]] = separate[2];
-				}
-			}
-
-                        j = 1;
-                        for (i in inherited_perms) {
-                            ind[j] = i + 0;
-                            j++;
-                        }
-                        n = asort(ind);
-			for (i = 1; i <= n; i++) {
-				perm = inherited_perms[ind[i]];
-				printf("#define %s__%s", toupper(tclass), toupper(perm)) > outfile; 
-				spaces = 40 - (length(perm) + length(tclass));
-				if (spaces < 1)
-				      spaces = 1;
-				for (j = 0; j < spaces; j++) 
-					printf(" ") > outfile; 
-				printf("0x%08xUL\n", ind[i]) > outfile; 
-			}
-			printf("\n") > outfile;
-                        for (i in ind) delete ind[i];
-                        for (i in inherited_perms) delete inherited_perms[i];
-
-			printf("   S_(SECCLASS_%s, %s, 0x%08xUL)\n", toupper(tclass), inherits, permission) > inheritfile; 
-
-			nextstate = "CLASS_OR_CLASS-OPENBRACKET";
-			next;
-		}
 $1 == "{"	{ 
 			if (nextstate != "INHERITS_OR_CLASS-OPENBRACKET" &&
 			    nextstate != "CLASS_OR_CLASS-OPENBRACKET" &&
@@ -177,15 +97,6 @@ $1 == "{"	{
 
 				av_perms[tclass,$1] = permission;
 		
-				if (inherits != "")
-				{
-					if ((inherits,$1) in common_perms)
-					{
-						printf("Permission %s in %s on line %d conflicts with common permission.\n", $1, tclass, inherits, NR);
-						next;
-					}
-				}
-
 				printf("#define %s__%s", toupper(tclass), toupper($1)) > outfile; 
 
 				printf("   S_(SECCLASS_%s, %s__%s, \"%s\")\n", toupper(tclass), toupper(tclass), toupper($1), $1) > avpermfile; 
diff --git a/xen/xsm/flask/avc.c b/xen/xsm/flask/avc.c
index 44240a9..1bfeef2 100644
--- a/xen/xsm/flask/avc.c
+++ b/xen/xsm/flask/avc.c
@@ -45,28 +45,11 @@ static const char *class_to_string[] = {
 #undef S_
 };
 
-#define TB_(s) static const char * s [] = {
-#define TE_(s) };
-#define S_(s) s,
-#include "common_perm_to_string.h"
-#undef TB_
-#undef TE_
-#undef S_
-
-static const struct av_inherit av_inherit[] = {
-#define S_(c, i, b) { .tclass = c, .common_pts = common_##i##_perm_to_string, \
-                      .common_base = b },
-#include "av_inherit.h"
-#undef S_
-};
-
 const struct selinux_class_perm selinux_class_perm = {
     .av_perm_to_string = av_perm_to_string,
     .av_pts_len = ARRAY_SIZE(av_perm_to_string),
     .class_to_string = class_to_string,
     .cts_len = ARRAY_SIZE(class_to_string),
-    .av_inherit = av_inherit,
-    .av_inherit_len = ARRAY_SIZE(av_inherit)
 };
 
 #define AVC_CACHE_SLOTS            512
@@ -191,16 +174,6 @@ static void avc_dump_av(struct avc_dump_buf *buf, u16 tclass, u32 av)
         return;
     }
 
-    for ( i = 0; i < ARRAY_SIZE(av_inherit); i++ )
-    {
-        if (av_inherit[i].tclass == tclass)
-        {
-            common_pts = av_inherit[i].common_pts;
-            common_base = av_inherit[i].common_base;
-            break;
-        }
-    }
-
     avc_printk(buf, " {");
     i = 0;
     perm = 1;
diff --git a/xen/xsm/flask/include/av_inherit.h b/xen/xsm/flask/include/av_inherit.h
deleted file mode 100644
index 321ffe7..0000000
--- a/xen/xsm/flask/include/av_inherit.h
+++ /dev/null
@@ -1 +0,0 @@
-/* This file is automatically generated.  Do not edit. */
diff --git a/xen/xsm/flask/include/avc_ss.h b/xen/xsm/flask/include/avc_ss.h
index ea4e98c..a3d7d1e 100644
--- a/xen/xsm/flask/include/avc_ss.h
+++ b/xen/xsm/flask/include/avc_ss.h
@@ -16,19 +16,11 @@ struct av_perm_to_string {
     const char *name;
 };
 
-struct av_inherit {
-    const char **common_pts;
-    u32 common_base;
-    u16 tclass;
-};
-
 struct selinux_class_perm {
     const struct av_perm_to_string *av_perm_to_string;
     u32 av_pts_len;
     u32 cts_len;
     const char **class_to_string;
-    const struct av_inherit *av_inherit;
-    u32 av_inherit_len;
 };
 
 extern const struct selinux_class_perm selinux_class_perm;
diff --git a/xen/xsm/flask/include/common_perm_to_string.h b/xen/xsm/flask/include/common_perm_to_string.h
deleted file mode 100644
index 321ffe7..0000000
--- a/xen/xsm/flask/include/common_perm_to_string.h
+++ /dev/null
@@ -1 +0,0 @@
-/* This file is automatically generated.  Do not edit. */
diff --git a/xen/xsm/flask/ss/services.c b/xen/xsm/flask/ss/services.c
index 363f586..1bf3b0c 100644
--- a/xen/xsm/flask/ss/services.c
+++ b/xen/xsm/flask/ss/services.c
@@ -1167,10 +1167,10 @@ int security_change_sid(u32 ssid, u32 tsid, u16 tclass, u32 *out_sid)
  */
 static int validate_classes(struct policydb *p)
 {
-    int i, j;
+    int i;
     struct class_datum *cladatum;
     struct perm_datum *perdatum;
-    u32 nprim, tmp, common_pts_len, perm_val, pol_val;
+    u32 nprim, perm_val, pol_val;
     u16 class_val;
     const struct selinux_class_perm *kdefs = &selinux_class_perm;
     const char *def_class, *def_perm, *pol_class;
@@ -1233,56 +1233,6 @@ static int validate_classes(struct policydb *p)
             return -EINVAL;
         }
     }
-    for ( i = 0; i < kdefs->av_inherit_len; i++ )
-    {
-        class_val = kdefs->av_inherit[i].tclass;
-        if ( class_val > p->p_classes.nprim )
-            continue;
-        pol_class = p->p_class_val_to_name[class_val-1];
-        cladatum = hashtab_search(p->p_classes.table, pol_class);
-        BUG_ON( !cladatum );
-        if ( !cladatum->comdatum )
-        {
-            printk(KERN_ERR
-            "Flask:  class %s should have an inherits clause but does not\n",
-                   pol_class);
-            return -EINVAL;
-        }
-        tmp = kdefs->av_inherit[i].common_base;
-        common_pts_len = 0;
-        while ( !(tmp & 0x01) )
-        {
-            common_pts_len++;
-            tmp >>= 1;
-        }
-        perms = &cladatum->comdatum->permissions;
-        for ( j = 0; j < common_pts_len; j++ )
-        {
-            def_perm = kdefs->av_inherit[i].common_pts[j];
-            if ( j >= perms->nprim )
-            {
-                printk(KERN_INFO
-                "Flask:  permission %s in class %s not defined in policy\n",
-                       def_perm, pol_class);
-                return -EINVAL;
-            }
-            perdatum = hashtab_search(perms->table, def_perm);
-            if ( perdatum == NULL )
-            {
-                printk(KERN_ERR
-                       "Flask:  permission %s in class %s not found in policy\n",
-                       def_perm, pol_class);
-                return -EINVAL;
-            }
-            if ( perdatum->value != j + 1 )
-            {
-                printk(KERN_ERR
-                      "Flask:  permission %s in class %s has incorrect value\n",
-                       def_perm, pol_class);
-                return -EINVAL;
-            }
-        }
-    }
     return 0;
 }
 
-- 
1.7.11.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 10 19:49:59 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Sep 2012 19: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 1TB9zS-0001Io-Na; Mon, 10 Sep 2012 19:49:50 +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 1TB9zP-00019X-Fw
	for xen-devel@lists.xen.org; Mon, 10 Sep 2012 19:49:47 +0000
Received: from [85.158.143.99:28173] by server-3.bemta-4.messagelabs.com id
	2F/D7-08232-B544E405; Mon, 10 Sep 2012 19:49:47 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-5.tower-216.messagelabs.com!1347306583!29254242!1
X-Originating-IP: [63.239.67.10]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27368 invoked from network); 10 Sep 2012 19:49:44 -0000
Received: from emvm-gh1-uea09.nsa.gov (HELO nsa.gov) (63.239.67.10)
	by server-5.tower-216.messagelabs.com with SMTP;
	10 Sep 2012 19:49:44 -0000
X-TM-IMSS-Message-ID: <3066dc1d000f2269@nsa.gov>
Received: from tarius.tycho.ncsc.mil ([144.51.3.1]) by nsa.gov
	([63.239.67.10]) with ESMTP (TREND IMSS SMTP Service 7.1) id
	3066dc1d000f2269 ; Mon, 10 Sep 2012 15:51:54 -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 q8AJna3s027796; 
	Mon, 10 Sep 2012 15:49:41 -0400
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xen.org
Date: Mon, 10 Sep 2012 15:49:09 -0400
Message-Id: <1347306553-20980-17-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.11.4
In-Reply-To: <1347306553-20980-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1347306553-20980-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: [Xen-devel] [PATCH 16/20] xsm/flask: add distinct SIDs for
	self/target 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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Because the FLASK XSM module no longer checks IS_PRIV for remote domain
accesses covered by XSM permissions, domains now have the ability to
perform memory management and other functions on all domains that have
the same type. While it is possible to prevent this by only creating one
domain per type, this solution significantly limits the flexibility of
the type system.

This patch introduces a domain type transition to represent a domain
that is operating on itself. In the example policy, this is demonstrated
by creating a type with _self appended when declaring a domain type
which will be used for reflexive operations. AVCs for a domain of type
domU_t will look like the following:

scontext=system_u:system_r:domU_t tcontext=system_u:system_r:domU_t_self

This change also allows policy to distinguish between event channels a
domain creates to itself and event channels created between domains of
the same type.

The IS_PRIV_FOR check used for device model domains is also no longer
checked by FLASK; a similar transition is performed when the target is
set and used when the device model accesses its target domain.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 docs/misc/xsm-flask.txt                      |  43 ++-
 tools/flask/policy/policy/modules/xen/xen.if |  60 +++-
 tools/flask/policy/policy/modules/xen/xen.te |  13 +-
 xen/xsm/flask/flask_op.c                     |   9 +
 xen/xsm/flask/hooks.c                        | 425 +++++++++++++--------------
 xen/xsm/flask/include/objsec.h               |   2 +
 6 files changed, 309 insertions(+), 243 deletions(-)

diff --git a/docs/misc/xsm-flask.txt b/docs/misc/xsm-flask.txt
index 0778a28..ff81b01 100644
--- a/docs/misc/xsm-flask.txt
+++ b/docs/misc/xsm-flask.txt
@@ -68,9 +68,43 @@ HVM domains with stubdomain device models use two types (one per domain):
  - dm_dom_t is the device model for a domain with type domHVM_t
 
 One disadvantage of using type enforcement to enforce isolation is that a new
-type is needed for each group of domains. In addition, it is not possible to
-allow isolated_domU_t cannot to create loopback event channels without allowing
-two domains of type isolated_domU_t to communicate with one another.
+type is needed for each group of domains. The user field can be used to address
+this for the most common case of groups that can communicate internally but not
+externally; see "Users and roles" below.
+
+Type transitions
+----------------
+
+Xen defines a number of operations such as memory mapping that are necessary for
+a domain to perform on itself, but are also undesirable to allow a domain to
+perform on every other domain of the same label. While it is possible to address
+this by only creating one domain per type, this solution significantly limits
+the flexibility of the type system. Another method to address this issue is to
+duplicate the permission names for every operation that can be performed on the
+current domain or on other domains; however, this significantly increases the
+necessary number of permissions and complicates the XSM hooks. Instead, this is
+addressed by allowing a distinct type to be used for a domain's access to
+itself. The same applies for a device model domain's access to its designated
+target, allowing the IS_PRIV_FOR checks used in Xen's DAC model to be
+implemented in FLASK.
+
+Upon domain creation (or relabel), a type transition is computed using the
+domain's label as the source and target. The result of this computation is used
+as the target when the domain accesses itself. In the example policy, this
+computed type is the result of appending _self to a domain's type: domU_t_self
+for domU_t. If no type transition rule exists, the domain will continue to use
+its own label for both the source and target. An AVC message will look like:
+
+    scontext=system_u:system_r:domU_t tcontext=system_u:system_r:domU_t_self
+
+A similar type transition is done when a device model domain is associated with
+its target using the set_target operation. The transition is computed with the
+target domain as the source and the device model domain as the target: this
+ordering was chosen in order to preserve the original label for the target when
+no type transition rule exists. In the example policy, these computed types are
+the result of appending _target to the domain.
+
+Type transitions are also used to compute the labels of event channels.
 
 Users and roles
 ---------------
@@ -84,7 +118,8 @@ the customer_1 user.
 Access control rules involving users and roles are defined in the policy
 constraints file (tools/flask/policy/policy/constraints). The example policy
 provides constraints that prevent different users from communicating using
-grants or event channels, while still allowing communication with dom0.
+grants or event channels, while still allowing communication with the system_u
+user where dom0 resides.
 
 Resource Policy
 ---------------
diff --git a/tools/flask/policy/policy/modules/xen/xen.if b/tools/flask/policy/policy/modules/xen/xen.if
index 3527054..1847f23 100644
--- a/tools/flask/policy/policy/modules/xen/xen.if
+++ b/tools/flask/policy/policy/modules/xen/xen.if
@@ -5,15 +5,34 @@
 # Domain creation and setup
 #
 ################################################################################
+define(`declare_domain_common', `
+	allow $1 $2:grant { query setup };
+	allow $1 $2:mmu { adjust physmap map_read map_write stat pinpage updatemp };
+	allow $1 $2:hvm { getparam setparam };
+')
+
 # declare_domain(type, attrs...)
-#   Declare a type as a domain type, and allow basic domain setup
+#   Declare a domain type, along with associated _self and _channel types
+#   Allow the domain to perform basic operations on itself
 define(`declare_domain', `
 	type $1, domain_type`'ifelse(`$#', `1', `', `,shift($@)');
+	type $1_self, domain_type, domain_self_type;
+	type_transition $1 $1:domain $1_self;
+	type $1_channel, event_type;
+	type_transition $1 domain_type:event $1_channel;
+	declare_domain_common($1, $1_self)
+')
+
+# declare_singleton_domain(type, attrs...)
+#   Declare a domain type and associated _channel types.
+#   Note: Because the domain can perform basic operations on itself and any
+#   other domain of the same type, this constructor should be used for types
+#   containing at most one domain. This is not enforced by policy.
+define(`declare_singleton_domain', `
+	type $1, domain_type`'ifelse(`$#', `1', `', `,shift($@)');
 	type $1_channel, event_type;
 	type_transition $1 domain_type:event $1_channel;
-	allow $1 $1:grant { query setup };
-	allow $1 $1:mmu { adjust physmap map_read map_write stat pinpage };
-	allow $1 $1:hvm { getparam setparam };
+	declare_domain_common($1, $1)
 ')
 
 # declare_build_label(type)
@@ -51,6 +70,7 @@ define(`create_domain_build_label', `
 	allow $1 $2_channel:event create;
 	allow $1 $2_building:domain2 relabelfrom;
 	allow $1 $2:domain2 relabelto;
+	allow $2_building $2:domain transition;
 ')
 
 # manage_domain(priv, target)
@@ -101,20 +121,36 @@ define(`domain_comms', `
 ')
 
 # domain_self_comms(domain)
-#   Allow a domain types to communicate with others of its type using grants
-#   and event channels (this includes event channels to DOMID_SELF)
+#   Allow a non-singleton domain type to communicate with itself using grants
+#   and event channels
 define(`domain_self_comms', `
-	create_channel($1, $1, $1_channel)
-	allow $1 $1:grant { map_read map_write copy unmap };
+	create_channel($1, $1_self, $1_channel)
+	allow $1 $1_self:grant { map_read map_write copy unmap };
 ')
 
 # device_model(dm_dom, hvm_dom)
 #   Define how a device model domain interacts with its target
 define(`device_model', `
-	domain_comms($1, $2)
-	allow $1 $2:domain { set_target shutdown };
-	allow $1 $2:mmu { map_read map_write adjust physmap };
-	allow $1 $2:hvm { getparam setparam trackdirtyvram hvmctl irqlevel pciroute };
+	type $2_target, domain_type, domain_target_type;
+	type_transition $2 $1:domain $2_target;
+	allow $1 $2:domain set_target;
+
+	type_transition $2_target domain_type:event $2_channel;
+	create_channel($1, $2_target, $1_channel)
+	create_channel($2, $1, $2_channel)
+	allow $1 $2_channel:event create;
+
+	allow $1 $2_target:domain shutdown;
+	allow $1 $2_target:mmu { map_read map_write adjust physmap };
+	allow $1 $2_target:hvm { getparam setparam trackdirtyvram hvmctl irqlevel pciroute cacheattr };
+')
+
+# make_device_model(priv, dm_dom, hvm_dom)
+#   Allow creation of a device model and HVM domain pair
+define(`make_device_model', `
+	device_model($2, $3)
+	allow $1 $2:domain2 make_priv_for;
+	allow $1 $3:domain2 set_as_target;
 ')
 ################################################################################
 #
diff --git a/tools/flask/policy/policy/modules/xen/xen.te b/tools/flask/policy/policy/modules/xen/xen.te
index 1162153..8d33285 100644
--- a/tools/flask/policy/policy/modules/xen/xen.te
+++ b/tools/flask/policy/policy/modules/xen/xen.te
@@ -8,6 +8,8 @@
 ################################################################################
 attribute xen_type;
 attribute domain_type;
+attribute domain_self_type;
+attribute domain_target_type;
 attribute resource_type;
 attribute event_type;
 attribute mls_priv;
@@ -25,7 +27,7 @@ attribute mls_priv;
 type xen_t, xen_type, mls_priv;
 
 # Domain 0
-declare_domain(dom0_t, mls_priv);
+declare_singleton_domain(dom0_t, mls_priv);
 
 # Untracked I/O memory (pseudo-domain)
 type domio_t, xen_type;
@@ -69,7 +71,7 @@ admin_device(dom0_t, ioport_t)
 admin_device(dom0_t, iomem_t)
 allow dom0_t domio_t:mmu { map_read map_write };
 
-domain_self_comms(dom0_t)
+domain_comms(dom0_t, dom0_t)
 
 auditallow dom0_t security_t:security { load_policy setenforce setbool };
 
@@ -84,11 +86,14 @@ domain_self_comms(domU_t)
 create_domain(dom0_t, domU_t)
 manage_domain(dom0_t, domU_t)
 domain_comms(dom0_t, domU_t)
+domain_comms(domU_t, domU_t)
+domain_self_comms(domU_t)
 
 declare_domain(isolated_domU_t)
 create_domain(dom0_t, isolated_domU_t)
 manage_domain(dom0_t, isolated_domU_t)
 domain_comms(dom0_t, isolated_domU_t)
+domain_self_comms(isolated_domU_t)
 
 # Declare a boolean that denies creation of prot_domU_t domains
 gen_bool(prot_doms_locked, false)
@@ -98,6 +103,8 @@ if (!prot_doms_locked) {
 }
 domain_comms(dom0_t, prot_domU_t)
 domain_comms(domU_t, prot_domU_t)
+domain_comms(prot_domU_t, prot_domU_t)
+domain_self_comms(prot_domU_t)
 
 # domHVM_t is meant to be paired with a qemu-dm stub domain of type dm_dom_t
 declare_domain(domHVM_t)
@@ -110,7 +117,7 @@ declare_domain(dm_dom_t)
 create_domain(dom0_t, dm_dom_t)
 manage_domain(dom0_t, dm_dom_t)
 domain_comms(dom0_t, dm_dom_t)
-device_model(dm_dom_t, domHVM_t)
+make_device_model(dom0_t, dm_dom_t, domHVM_t)
 
 # nomigrate_t must be built via the nomigrate_t_building label; once built,
 # dom0 cannot read its memory.
diff --git a/xen/xsm/flask/flask_op.c b/xen/xsm/flask/flask_op.c
index 9c8dfe7..f8fc108 100644
--- a/xen/xsm/flask/flask_op.c
+++ b/xen/xsm/flask/flask_op.c
@@ -612,6 +612,15 @@ static int flask_relabel_domain(struct xen_flask_relabel *arg)
         goto out;
 
     dsec->sid = arg->sid;
+    dsec->self_sid = arg->sid;
+    security_transition_sid(dsec->sid, dsec->sid, SECCLASS_DOMAIN,
+                            &dsec->self_sid);
+    if ( d->target )
+    {
+        struct domain_security_struct *tsec = d->target->ssid;
+        security_transition_sid(tsec->sid, dsec->sid, SECCLASS_DOMAIN,
+                                &dsec->target_sid);
+    }
 
  out:
     rcu_unlock_domain(d);
diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
index f6ec7bd..7da1754 100644
--- a/xen/xsm/flask/hooks.c
+++ b/xen/xsm/flask/hooks.c
@@ -33,38 +33,69 @@
 
 struct xsm_operations *original_ops = NULL;
 
+static u32 domain_sid(struct domain *dom)
+{
+    struct domain_security_struct *dsec = dom->ssid;
+    return dsec->sid;
+}
+
+static u32 domain_target_sid(struct domain *src, struct domain *dst)
+{
+    struct domain_security_struct *ssec = src->ssid;
+    struct domain_security_struct *dsec = dst->ssid;
+    if (src == dst)
+        return ssec->self_sid;
+    if (src->target == dst)
+        return ssec->target_sid;
+    return dsec->sid;
+}
+
+static u32 evtchn_sid(const struct evtchn *chn)
+{
+    struct evtchn_security_struct *esec = chn->ssid;
+    return esec->sid;
+}
+
 static int domain_has_perm(struct domain *dom1, struct domain *dom2, 
                            u16 class, u32 perms)
 {
-    struct domain_security_struct *dsec1, *dsec2;
+    u32 ssid, tsid;
     struct avc_audit_data ad;
     AVC_AUDIT_DATA_INIT(&ad, NONE);
     ad.sdom = dom1;
     ad.tdom = dom2;
 
-    dsec1 = dom1->ssid;
-    dsec2 = dom2->ssid;
+    ssid = domain_sid(dom1);
+    tsid = domain_target_sid(dom1, dom2);
 
-    return avc_has_perm(dsec1->sid, dsec2->sid, class, perms, &ad);
+    return avc_has_perm(ssid, tsid, class, perms, &ad);
 }
 
-static int domain_has_evtchn(struct domain *d, struct evtchn *chn, u32 perms)
+static int avc_current_has_perm(u32 tsid, u16 class, u32 perm,
+                                struct avc_audit_data *ad)
 {
-    struct domain_security_struct *dsec;
-    struct evtchn_security_struct *esec;
+    u32 csid = domain_sid(current->domain);
+    return avc_has_perm(csid, tsid, class, perm, ad);
+}
 
-    dsec = d->ssid;
-    esec = chn->ssid;
+static int current_has_perm(struct domain *d, u16 class, u32 perms)
+{
+    return domain_has_perm(current->domain, d, class, perms);
+}
+
+static int domain_has_evtchn(struct domain *d, struct evtchn *chn, u32 perms)
+{
+    u32 dsid = domain_sid(d);
+    u32 esid = evtchn_sid(chn);
 
-    return avc_has_perm(dsec->sid, esec->sid, SECCLASS_EVENT, perms, NULL);
+    return avc_has_perm(dsid, esid, SECCLASS_EVENT, perms, NULL);
 }
 
 static int domain_has_xen(struct domain *d, u32 perms)
 {
-    struct domain_security_struct *dsec;
-    dsec = d->ssid;
+    u32 dsid = domain_sid(d);
 
-    return avc_has_perm(dsec->sid, SECINITSID_XEN, SECCLASS_XEN, perms, NULL);
+    return avc_has_perm(dsid, SECINITSID_XEN, SECCLASS_XEN, perms, NULL);
 }
 
 static int get_irq_sid(int irq, u32 *sid, struct avc_audit_data *ad)
@@ -123,6 +154,7 @@ static int flask_domain_alloc_security(struct domain *d)
         dsec->sid = SECINITSID_UNLABELED;
     }
 
+    dsec->self_sid = dsec->sid;
     d->ssid = dsec;
 
     return 0;
@@ -142,68 +174,55 @@ static void flask_domain_free_security(struct domain *d)
 static int flask_evtchn_unbound(struct domain *d1, struct evtchn *chn, 
                                 domid_t id2)
 {
-    u32 newsid;
+    u32 sid1, sid2, newsid;
     int rc;
-    domid_t id;
     struct domain *d2;
-    struct domain_security_struct *dsec, *dsec1, *dsec2;
     struct evtchn_security_struct *esec;
 
-    dsec = current->domain->ssid;
-    dsec1 = d1->ssid;
-    esec = chn->ssid;
-
-    if ( id2 == DOMID_SELF )
-        id = current->domain->domain_id;
-    else
-        id = id2;
-
-    d2 = get_domain_by_id(id);
+    d2 = rcu_lock_domain_by_any_id(id2);
     if ( d2 == NULL )
         return -EPERM;
 
-    dsec2 = d2->ssid;
-    rc = security_transition_sid(dsec1->sid, dsec2->sid, SECCLASS_EVENT, 
-                                 &newsid);
+    sid1 = domain_sid(d1);
+    sid2 = domain_target_sid(d1, d2);
+    esec = chn->ssid;
+
+    rc = security_transition_sid(sid1, sid2, SECCLASS_EVENT, &newsid);
     if ( rc )
         goto out;
 
-    rc = avc_has_perm(dsec->sid, newsid, SECCLASS_EVENT, EVENT__CREATE, NULL);
+    rc = avc_current_has_perm(newsid, SECCLASS_EVENT, EVENT__CREATE, NULL);
     if ( rc )
         goto out;
 
-    rc = avc_has_perm(newsid, dsec2->sid, SECCLASS_EVENT, EVENT__BIND, NULL);
+    rc = avc_has_perm(newsid, sid2, SECCLASS_EVENT, EVENT__BIND, NULL);
     if ( rc )
         goto out;
-    else
-        esec->sid = newsid;
+
+    esec->sid = newsid;
 
  out:
-    put_domain(d2);
+    rcu_unlock_domain(d2);
     return rc;
 }
 
 static int flask_evtchn_interdomain(struct domain *d1, struct evtchn *chn1, 
                                     struct domain *d2, struct evtchn *chn2)
 {
-    u32 newsid;
+    u32 sid1, sid2, newsid, reverse_sid;
     int rc;
-    struct domain_security_struct *dsec, *dsec1, *dsec2;
-    struct evtchn_security_struct *esec1, *esec2;
+    struct evtchn_security_struct *esec1;
     struct avc_audit_data ad;
     AVC_AUDIT_DATA_INIT(&ad, NONE);
     ad.sdom = d1;
     ad.tdom = d2;
 
-    dsec = current->domain->ssid;
-    dsec1 = d1->ssid;
-    dsec2 = d2->ssid;
+    sid1 = domain_sid(d1);
+    sid2 = domain_target_sid(d1, d2);
 
     esec1 = chn1->ssid;
-    esec2 = chn2->ssid;
 
-    rc = security_transition_sid(dsec1->sid, dsec2->sid, 
-                                 SECCLASS_EVENT, &newsid);
+    rc = security_transition_sid(sid1, sid2, SECCLASS_EVENT, &newsid);
     if ( rc )
     {
         printk("%s: security_transition_sid failed, rc=%d (domain=%d)\n",
@@ -211,15 +230,20 @@ static int flask_evtchn_interdomain(struct domain *d1, struct evtchn *chn1,
         return rc;
     }
 
-    rc = avc_has_perm(dsec->sid, newsid, SECCLASS_EVENT, EVENT__CREATE, &ad);
+    rc = avc_current_has_perm(newsid, SECCLASS_EVENT, EVENT__CREATE, &ad);
     if ( rc )
         return rc;
 
-    rc = avc_has_perm(newsid, dsec2->sid, SECCLASS_EVENT, EVENT__BIND, &ad);
+    rc = avc_has_perm(newsid, sid2, SECCLASS_EVENT, EVENT__BIND, &ad);
     if ( rc )
         return rc;
 
-    rc = avc_has_perm(esec2->sid, dsec1->sid, SECCLASS_EVENT, EVENT__BIND, &ad);
+    /* It's possible the target domain has changed (relabel or destroy/create)
+     * since the unbound part was created; re-validate this binding now.
+     */
+    reverse_sid = evtchn_sid(chn2);
+    sid1 = domain_target_sid(d2, d1);
+    rc = avc_has_perm(reverse_sid, sid1, SECCLASS_EVENT, EVENT__BIND, &ad);
     if ( rc )
         return rc;
 
@@ -302,7 +326,6 @@ static void flask_free_security_evtchn(struct evtchn *chn)
 
 static char *flask_show_security_evtchn(struct domain *d, const struct evtchn *chn)
 {
-    struct evtchn_security_struct *esec;
     int irq;
     u32 sid = 0;
     char *ctx;
@@ -312,9 +335,7 @@ static char *flask_show_security_evtchn(struct domain *d, const struct evtchn *c
     {
     case ECS_UNBOUND:
     case ECS_INTERDOMAIN:
-        esec = chn->ssid;
-        if ( esec )
-            sid = esec->sid;
+        sid = evtchn_sid(chn);
         break;
     case ECS_PIRQ:
         irq = domain_pirq_to_irq(d, chn->u.pirq.irq);
@@ -367,12 +388,12 @@ static int flask_grant_query_size(struct domain *d1, struct domain *d2)
 
 static int flask_get_pod_target(struct domain *d)
 {
-    return domain_has_perm(current->domain, d, SECCLASS_DOMAIN, DOMAIN__GETPODTARGET);
+    return current_has_perm(d, SECCLASS_DOMAIN, DOMAIN__GETPODTARGET);
 }
 
 static int flask_set_pod_target(struct domain *d)
 {
-    return domain_has_perm(current->domain, d, SECCLASS_DOMAIN, DOMAIN__SETPODTARGET);
+    return current_has_perm(d, SECCLASS_DOMAIN, DOMAIN__SETPODTARGET);
 }
 
 static int flask_memory_adjust_reservation(struct domain *d1, struct domain *d2)
@@ -455,70 +476,65 @@ static int flask_schedop_shutdown(struct domain *d1, struct domain *d2)
 static void flask_security_domaininfo(struct domain *d, 
                                       struct xen_domctl_getdomaininfo *info)
 {
-    struct domain_security_struct *dsec;
-
-    dsec = d->ssid;
-    info->ssidref = dsec->sid;
+    info->ssidref = domain_sid(d);
 }
 
 static int flask_setvcpucontext(struct domain *d)
 {
-    return domain_has_perm(current->domain, d, SECCLASS_DOMAIN, 
-                           DOMAIN__SETVCPUCONTEXT);
+    return current_has_perm(d, SECCLASS_DOMAIN, DOMAIN__SETVCPUCONTEXT);
 }
 
 static int flask_pausedomain(struct domain *d)
 {
-    return domain_has_perm(current->domain, d, SECCLASS_DOMAIN, DOMAIN__PAUSE);
+    return current_has_perm(d, SECCLASS_DOMAIN, DOMAIN__PAUSE);
 }
 
 static int flask_unpausedomain(struct domain *d)
 {
-    return domain_has_perm(current->domain, d, SECCLASS_DOMAIN, DOMAIN__UNPAUSE);
+    return current_has_perm(d, SECCLASS_DOMAIN, DOMAIN__UNPAUSE);
 }
 
 static int flask_resumedomain(struct domain *d)
 {
-    return domain_has_perm(current->domain, d, SECCLASS_DOMAIN, DOMAIN__RESUME);
+    return current_has_perm(d, SECCLASS_DOMAIN, DOMAIN__RESUME);
 }
 
 static int flask_domain_create(struct domain *d, u32 ssidref)
 {
     int rc;
-    struct domain_security_struct *dsec1;
-    struct domain_security_struct *dsec2;
+    struct domain_security_struct *dsec = d->ssid;
     static int dom0_created = 0;
 
-    dsec1 = current->domain->ssid;
-    dsec2 = d->ssid;
-
     if ( is_idle_domain(current->domain) && !dom0_created )
     {
-        dsec2->sid = SECINITSID_DOM0;
+        dsec->sid = SECINITSID_DOM0;
         dom0_created = 1;
-        return 0;
     }
+    else
+    {
+        rc = avc_current_has_perm(ssidref, SECCLASS_DOMAIN,
+                          DOMAIN__CREATE, NULL);
+        if ( rc )
+            return rc;
 
-    rc = avc_has_perm(dsec1->sid, ssidref, SECCLASS_DOMAIN,
-                      DOMAIN__CREATE, NULL);
-    if ( rc )
-        return rc;
+        dsec->sid = ssidref;
+    }
+    dsec->self_sid = dsec->sid;
 
-    dsec2->sid = ssidref;
+    rc = security_transition_sid(dsec->sid, dsec->sid, SECCLASS_DOMAIN,
+                                 &dsec->self_sid);
 
     return rc;
 }
 
 static int flask_max_vcpus(struct domain *d)
 {
-    return domain_has_perm(current->domain, d, SECCLASS_DOMAIN, 
-                           DOMAIN__MAX_VCPUS);
+    return current_has_perm(d, SECCLASS_DOMAIN, DOMAIN__MAX_VCPUS);
 }
 
 static int flask_destroydomain(struct domain *d)
 {
-    return domain_has_perm(current->domain, d, SECCLASS_DOMAIN, 
-                           DOMAIN__DESTROY);
+    return current_has_perm(d, SECCLASS_DOMAIN, DOMAIN__DESTROY);
 }
 
 static int flask_vcpuaffinity(int cmd, struct domain *d)
@@ -537,7 +553,7 @@ static int flask_vcpuaffinity(int cmd, struct domain *d)
         return -EPERM;
     }
 
-    return domain_has_perm(current->domain, d, SECCLASS_DOMAIN, perm );
+    return current_has_perm(d, SECCLASS_DOMAIN, perm );
 }
 
 static int flask_scheduler(struct domain *d)
@@ -548,53 +564,61 @@ static int flask_scheduler(struct domain *d)
     if ( rc )
         return rc;
 
-    return domain_has_perm(current->domain, d, SECCLASS_DOMAIN, 
-                           DOMAIN__SCHEDULER);
+    return current_has_perm(d, SECCLASS_DOMAIN, DOMAIN__SCHEDULER);
 }
 
 static int flask_getdomaininfo(struct domain *d)
 {
-    return domain_has_perm(current->domain, d, SECCLASS_DOMAIN,
-                           DOMAIN__GETDOMAININFO);
+    return current_has_perm(d, SECCLASS_DOMAIN, DOMAIN__GETDOMAININFO);
 }
 
 static int flask_getvcpucontext(struct domain *d)
 {
-    return domain_has_perm(current->domain, d, SECCLASS_DOMAIN, 
-                           DOMAIN__GETVCPUCONTEXT);
+    return current_has_perm(d, SECCLASS_DOMAIN, DOMAIN__GETVCPUCONTEXT);
 }
 
 static int flask_getvcpuinfo(struct domain *d)
 {
-    return domain_has_perm(current->domain, d, SECCLASS_DOMAIN,
-                           DOMAIN__GETVCPUINFO);
+    return current_has_perm(d, SECCLASS_DOMAIN, DOMAIN__GETVCPUINFO);
 }
 
 static int flask_domain_settime(struct domain *d)
 {
-    return domain_has_perm(current->domain, d, SECCLASS_DOMAIN, DOMAIN__SETTIME);
+    return current_has_perm(d, SECCLASS_DOMAIN, DOMAIN__SETTIME);
 }
 
-static int flask_set_target(struct domain *d, struct domain *e)
+static int flask_set_target(struct domain *d, struct domain *t)
 {
     int rc;
-    rc = domain_has_perm(current->domain, d, SECCLASS_DOMAIN2, DOMAIN2__MAKE_PRIV_FOR);
+    struct domain_security_struct *dsec, *tsec;
+    dsec = d->ssid;
+    tsec = t->ssid;
+
+    rc = current_has_perm(d, SECCLASS_DOMAIN2, DOMAIN2__MAKE_PRIV_FOR);
+    if ( rc )
+        return rc;
+    rc = current_has_perm(t, SECCLASS_DOMAIN2, DOMAIN2__SET_AS_TARGET);
     if ( rc )
         return rc;
-    rc = domain_has_perm(current->domain, e, SECCLASS_DOMAIN2, DOMAIN2__SET_AS_TARGET);
+    /* Use avc_has_perm to avoid resolving target/current SID */
+    rc = avc_has_perm(dsec->sid, tsec->sid, SECCLASS_DOMAIN, DOMAIN__SET_TARGET, NULL);
     if ( rc )
         return rc;
-    return domain_has_perm(d, e, SECCLASS_DOMAIN, DOMAIN__SET_TARGET);
+
+    /* (tsec, dsec) defaults the label to tsec, as it should here */
+    rc = security_transition_sid(tsec->sid, dsec->sid, SECCLASS_DOMAIN,
+                                 &dsec->target_sid);
+    return rc;
 }
 
 static int flask_domctl(struct domain *d, int cmd)
 {
-    return domain_has_perm(current->domain, d, SECCLASS_DOMAIN, DOMAIN__SET_MISC_INFO);
+    return current_has_perm(d, SECCLASS_DOMAIN, DOMAIN__SET_MISC_INFO);
 }
 
 static int flask_set_virq_handler(struct domain *d, uint32_t virq)
 {
-    return domain_has_perm(current->domain, d, SECCLASS_DOMAIN, DOMAIN__SET_VIRQ_HANDLER);
+    return current_has_perm(d, SECCLASS_DOMAIN, DOMAIN__SET_VIRQ_HANDLER);
 }
 
 static int flask_tbufcontrol(void)
@@ -619,26 +643,22 @@ static int flask_sched_id(void)
 
 static int flask_setdomainmaxmem(struct domain *d)
 {
-    return domain_has_perm(current->domain, d, SECCLASS_DOMAIN,
-                           DOMAIN__SETDOMAINMAXMEM);
+    return current_has_perm(d, SECCLASS_DOMAIN, DOMAIN__SETDOMAINMAXMEM);
 }
 
 static int flask_setdomainhandle(struct domain *d)
 {
-    return domain_has_perm(current->domain, d, SECCLASS_DOMAIN,
-                           DOMAIN__SETDOMAINHANDLE);
+    return current_has_perm(d, SECCLASS_DOMAIN, DOMAIN__SETDOMAINHANDLE);
 }
 
 static int flask_setdebugging(struct domain *d)
 {
-    return domain_has_perm(current->domain, d, SECCLASS_DOMAIN,
-                           DOMAIN__SETDEBUGGING);
+    return current_has_perm(d, SECCLASS_DOMAIN, DOMAIN__SETDEBUGGING);
 }
 
 static int flask_debug_op(struct domain *d)
 {
-    return domain_has_perm(current->domain, d, SECCLASS_DOMAIN,
-                           DOMAIN__SETDEBUGGING);
+    return current_has_perm(d, SECCLASS_DOMAIN, DOMAIN__SETDEBUGGING);
 }
 
 static int flask_debug_keys(void)
@@ -700,14 +720,12 @@ static char *flask_show_irq_sid (int irq)
 
 static int flask_map_domain_pirq (struct domain *d, int irq, void *data)
 {
-    u32 sid;
+    u32 sid, dsid;
     int rc = -EPERM;
     struct msi_info *msi = data;
-
-    struct domain_security_struct *ssec, *tsec;
     struct avc_audit_data ad;
 
-    rc = domain_has_perm(current->domain, d, SECCLASS_RESOURCE, RESOURCE__ADD);
+    rc = current_has_perm(d, SECCLASS_RESOURCE, RESOURCE__ADD);
 
     if ( rc )
         return rc;
@@ -723,14 +741,13 @@ static int flask_map_domain_pirq (struct domain *d, int irq, void *data)
     if ( rc )
         return rc;
 
-    ssec = current->domain->ssid;
-    tsec = d->ssid;
+    dsid = domain_sid(d);
 
-    rc = avc_has_perm(ssec->sid, sid, SECCLASS_RESOURCE, RESOURCE__ADD_IRQ, &ad);
+    rc = avc_current_has_perm(sid, SECCLASS_RESOURCE, RESOURCE__ADD_IRQ, &ad);
     if ( rc )
         return rc;
 
-    rc = avc_has_perm(tsec->sid, sid, SECCLASS_RESOURCE, RESOURCE__USE, &ad);
+    rc = avc_has_perm(dsid, sid, SECCLASS_RESOURCE, RESOURCE__USE, &ad);
     return rc;
 }
 
@@ -738,16 +755,12 @@ static int flask_unmap_domain_pirq (struct domain *d, int irq)
 {
     u32 sid;
     int rc = -EPERM;
-
-    struct domain_security_struct *ssec;
     struct avc_audit_data ad;
 
-    rc = domain_has_perm(current->domain, d, SECCLASS_RESOURCE, RESOURCE__REMOVE);
+    rc = current_has_perm(d, SECCLASS_RESOURCE, RESOURCE__REMOVE);
     if ( rc )
         return rc;
 
-    ssec = current->domain->ssid;
-
     if ( irq >= nr_irqs_gsi ) {
         /* TODO support for MSI here */
         return 0;
@@ -757,19 +770,19 @@ static int flask_unmap_domain_pirq (struct domain *d, int irq)
     if ( rc )
         return rc;
 
-    rc = avc_has_perm(ssec->sid, sid, SECCLASS_RESOURCE, RESOURCE__REMOVE_IRQ, &ad);
+    rc = avc_current_has_perm(sid, SECCLASS_RESOURCE, RESOURCE__REMOVE_IRQ, &ad);
     return rc;
 }
 
 static int flask_irq_permission (struct domain *d, int pirq, uint8_t access)
 {
     /* the PIRQ number is not useful; real IRQ is checked during mapping */
-    return domain_has_perm(current->domain, d, SECCLASS_RESOURCE,
-                           resource_to_perm(access));
+    return current_has_perm(d, SECCLASS_RESOURCE, resource_to_perm(access));
 }
 
 struct iomem_has_perm_data {
-    struct domain_security_struct *ssec, *tsec;
+    u32 ssid;
+    u32 dsid;
     u32 perm;
 };
 
@@ -783,12 +796,12 @@ static int _iomem_has_perm(void *v, u32 sid, unsigned long start, unsigned long
     ad.range.start = start;
     ad.range.end = end;
 
-    rc = avc_has_perm(data->ssec->sid, sid, SECCLASS_RESOURCE, data->perm, &ad);
+    rc = avc_has_perm(data->ssid, sid, SECCLASS_RESOURCE, data->perm, &ad);
 
     if ( rc )
         return rc;
 
-    return avc_has_perm(data->tsec->sid, sid, SECCLASS_RESOURCE, RESOURCE__USE, &ad);
+    return avc_has_perm(data->dsid, sid, SECCLASS_RESOURCE, RESOURCE__USE, &ad);
 }
 
 static int flask_iomem_permission(struct domain *d, uint64_t start, uint64_t end, uint8_t access)
@@ -796,7 +809,7 @@ static int flask_iomem_permission(struct domain *d, uint64_t start, uint64_t end
     struct iomem_has_perm_data data;
     int rc;
 
-    rc = domain_has_perm(current->domain, d, SECCLASS_RESOURCE,
+    rc = current_has_perm(d, SECCLASS_RESOURCE,
                          resource_to_perm(access));
     if ( rc )
         return rc;
@@ -806,18 +819,17 @@ static int flask_iomem_permission(struct domain *d, uint64_t start, uint64_t end
     else
         data.perm = RESOURCE__REMOVE_IOMEM;
 
-    data.ssec = current->domain->ssid;
-    data.tsec = d->ssid;
+    data.ssid = domain_sid(current->domain);
+    data.dsid = domain_sid(d);
 
     return security_iterate_iomem_sids(start, end, _iomem_has_perm, &data);
 }
 
 static int flask_pci_config_permission(struct domain *d, uint32_t machine_bdf, uint16_t start, uint16_t end, uint8_t access)
 {
-    u32 rsid;
+    u32 dsid, rsid;
     int rc = -EPERM;
     struct avc_audit_data ad;
-    struct domain_security_struct *ssec;
     u32 perm = RESOURCE__USE;
 
     rc = security_device_sid(machine_bdf, &rsid);
@@ -830,33 +842,24 @@ static int flask_pci_config_permission(struct domain *d, uint32_t machine_bdf, u
 
     AVC_AUDIT_DATA_INIT(&ad, DEV);
     ad.device = (unsigned long) machine_bdf;
-    ssec = d->ssid;
-    return avc_has_perm(ssec->sid, rsid, SECCLASS_RESOURCE, perm, &ad);
+    dsid = domain_sid(d);
+    return avc_has_perm(dsid, rsid, SECCLASS_RESOURCE, perm, &ad);
 
 }
 
 static int flask_resource_plug_core(void)
 {
-    struct domain_security_struct *ssec;
-
-    ssec = current->domain->ssid;
-    return avc_has_perm(ssec->sid, SECINITSID_DOMXEN, SECCLASS_RESOURCE, RESOURCE__PLUG, NULL);
+    return avc_current_has_perm(SECINITSID_DOMXEN, SECCLASS_RESOURCE, RESOURCE__PLUG, NULL);
 }
 
 static int flask_resource_unplug_core(void)
 {
-    struct domain_security_struct *ssec;
-
-    ssec = current->domain->ssid;
-    return avc_has_perm(ssec->sid, SECINITSID_DOMXEN, SECCLASS_RESOURCE, RESOURCE__UNPLUG, NULL);
+    return avc_current_has_perm(SECINITSID_DOMXEN, SECCLASS_RESOURCE, RESOURCE__UNPLUG, NULL);
 }
 
 static int flask_resource_use_core(void)
 {
-    struct domain_security_struct *ssec;
-
-    ssec = current->domain->ssid;
-    return avc_has_perm(ssec->sid, SECINITSID_DOMXEN, SECCLASS_RESOURCE, RESOURCE__USE, NULL);
+    return avc_current_has_perm(SECINITSID_DOMXEN, SECCLASS_RESOURCE, RESOURCE__USE, NULL);
 }
 
 static int flask_resource_plug_pci(uint32_t machine_bdf)
@@ -864,7 +867,6 @@ static int flask_resource_plug_pci(uint32_t machine_bdf)
     u32 rsid;
     int rc = -EPERM;
     struct avc_audit_data ad;
-    struct domain_security_struct *ssec;
 
     rc = security_device_sid(machine_bdf, &rsid);
     if ( rc )
@@ -872,8 +874,7 @@ static int flask_resource_plug_pci(uint32_t machine_bdf)
 
     AVC_AUDIT_DATA_INIT(&ad, DEV);
     ad.device = (unsigned long) machine_bdf;
-    ssec = current->domain->ssid;
-    return avc_has_perm(ssec->sid, rsid, SECCLASS_RESOURCE, RESOURCE__PLUG, &ad);
+    return avc_current_has_perm(rsid, SECCLASS_RESOURCE, RESOURCE__PLUG, &ad);
 }
 
 static int flask_resource_unplug_pci(uint32_t machine_bdf)
@@ -881,7 +882,6 @@ static int flask_resource_unplug_pci(uint32_t machine_bdf)
     u32 rsid;
     int rc = -EPERM;
     struct avc_audit_data ad;
-    struct domain_security_struct *ssec;
 
     rc = security_device_sid(machine_bdf, &rsid);
     if ( rc )
@@ -889,8 +889,7 @@ static int flask_resource_unplug_pci(uint32_t machine_bdf)
 
     AVC_AUDIT_DATA_INIT(&ad, DEV);
     ad.device = (unsigned long) machine_bdf;
-    ssec = current->domain->ssid;
-    return avc_has_perm(ssec->sid, rsid, SECCLASS_RESOURCE, RESOURCE__UNPLUG, &ad);
+    return avc_current_has_perm(rsid, SECCLASS_RESOURCE, RESOURCE__UNPLUG, &ad);
 }
 
 static int flask_resource_setup_pci(uint32_t machine_bdf)
@@ -898,7 +897,6 @@ static int flask_resource_setup_pci(uint32_t machine_bdf)
     u32 rsid;
     int rc = -EPERM;
     struct avc_audit_data ad;
-    struct domain_security_struct *ssec;
 
     rc = security_device_sid(machine_bdf, &rsid);
     if ( rc )
@@ -906,8 +904,7 @@ static int flask_resource_setup_pci(uint32_t machine_bdf)
 
     AVC_AUDIT_DATA_INIT(&ad, DEV);
     ad.device = (unsigned long) machine_bdf;
-    ssec = current->domain->ssid;
-    return avc_has_perm(ssec->sid, rsid, SECCLASS_RESOURCE, RESOURCE__SETUP, &ad);
+    return avc_current_has_perm(rsid, SECCLASS_RESOURCE, RESOURCE__SETUP, &ad);
 }
 
 static int flask_resource_setup_gsi(int gsi)
@@ -915,22 +912,17 @@ static int flask_resource_setup_gsi(int gsi)
     u32 rsid;
     int rc = -EPERM;
     struct avc_audit_data ad;
-    struct domain_security_struct *ssec;
 
     rc = get_irq_sid(gsi, &rsid, &ad);
     if ( rc )
         return rc;
 
-    ssec = current->domain->ssid;
-    return avc_has_perm(ssec->sid, rsid, SECCLASS_RESOURCE, RESOURCE__SETUP, &ad);
+    return avc_current_has_perm(rsid, SECCLASS_RESOURCE, RESOURCE__SETUP, &ad);
 }
 
 static int flask_resource_setup_misc(void)
 {
-    struct domain_security_struct *ssec;
-
-    ssec = current->domain->ssid;
-    return avc_has_perm(ssec->sid, SECINITSID_XEN, SECCLASS_RESOURCE, RESOURCE__SETUP, NULL);
+    return avc_current_has_perm(SECINITSID_XEN, SECCLASS_RESOURCE, RESOURCE__SETUP, NULL);
 }
 
 static inline int flask_page_offline(uint32_t cmd)
@@ -998,11 +990,12 @@ static int flask_shadow_control(struct domain *d, uint32_t op)
         return -EPERM;
     }
 
-    return domain_has_perm(current->domain, d, SECCLASS_SHADOW, perm);
+    return current_has_perm(d, SECCLASS_SHADOW, perm);
 }
 
 struct ioport_has_perm_data {
-    struct domain_security_struct *ssec, *tsec;
+    u32 ssid;
+    u32 dsid;
     u32 perm;
 };
 
@@ -1016,12 +1009,12 @@ static int _ioport_has_perm(void *v, u32 sid, unsigned long start, unsigned long
     ad.range.start = start;
     ad.range.end = end;
 
-    rc = avc_has_perm(data->ssec->sid, sid, SECCLASS_RESOURCE, data->perm, &ad);
+    rc = avc_has_perm(data->ssid, sid, SECCLASS_RESOURCE, data->perm, &ad);
 
     if ( rc )
         return rc;
 
-    return avc_has_perm(data->tsec->sid, sid, SECCLASS_RESOURCE, RESOURCE__USE, &ad);
+    return avc_has_perm(data->dsid, sid, SECCLASS_RESOURCE, RESOURCE__USE, &ad);
 }
 
 
@@ -1030,7 +1023,7 @@ static int flask_ioport_permission(struct domain *d, uint32_t start, uint32_t en
     int rc;
     struct ioport_has_perm_data data;
 
-    rc = domain_has_perm(current->domain, d, SECCLASS_RESOURCE,
+    rc = current_has_perm(d, SECCLASS_RESOURCE,
                          resource_to_perm(access));
 
     if ( rc )
@@ -1041,41 +1034,40 @@ static int flask_ioport_permission(struct domain *d, uint32_t start, uint32_t en
     else
         data.perm = RESOURCE__REMOVE_IOPORT;
 
-    data.ssec = current->domain->ssid;
-    data.tsec = d->ssid;
+    data.ssid = domain_sid(current->domain);
+    data.dsid = domain_sid(d);
 
     return security_iterate_ioport_sids(start, end, _ioport_has_perm, &data);
 }
 
 static int flask_getpageframeinfo(struct domain *d)
 {
-    return domain_has_perm(current->domain, d, SECCLASS_MMU, MMU__PAGEINFO);
+    return current_has_perm(d, SECCLASS_MMU, MMU__PAGEINFO);
 }
 
 static int flask_set_cpuid(struct domain *d)
 {
-    return domain_has_perm(current->domain, d, SECCLASS_DOMAIN2, DOMAIN2__SET_CPUID);
+    return current_has_perm(d, SECCLASS_DOMAIN2, DOMAIN2__SET_CPUID);
 }
 
 static int flask_gettscinfo(struct domain *d)
 {
-    return domain_has_perm(current->domain, d, SECCLASS_DOMAIN2, DOMAIN2__GETTSC);
+    return current_has_perm(d, SECCLASS_DOMAIN2, DOMAIN2__GETTSC);
 }
 
 static int flask_settscinfo(struct domain *d)
 {
-    return domain_has_perm(current->domain, d, SECCLASS_DOMAIN2, DOMAIN2__SETTSC);
+    return current_has_perm(d, SECCLASS_DOMAIN2, DOMAIN2__SETTSC);
 }
 
 static int flask_getmemlist(struct domain *d)
 {
-    return domain_has_perm(current->domain, d, SECCLASS_MMU, MMU__PAGELIST);
+    return current_has_perm(d, SECCLASS_MMU, MMU__PAGELIST);
 }
 
 static int flask_hypercall_init(struct domain *d)
 {
-    return domain_has_perm(current->domain, d, SECCLASS_DOMAIN,
-                           DOMAIN__HYPERCALL);
+    return current_has_perm(d, SECCLASS_DOMAIN, DOMAIN__HYPERCALL);
 }
 
 static int flask_hvmcontext(struct domain *d, uint32_t cmd)
@@ -1098,7 +1090,7 @@ static int flask_hvmcontext(struct domain *d, uint32_t cmd)
         return -EPERM;
     }
 
-    return domain_has_perm(current->domain, d, SECCLASS_HVM, perm);
+    return current_has_perm(d, SECCLASS_HVM, perm);
 }
 
 static int flask_address_size(struct domain *d, uint32_t cmd)
@@ -1117,7 +1109,7 @@ static int flask_address_size(struct domain *d, uint32_t cmd)
         return -EPERM;
     }
 
-    return domain_has_perm(current->domain, d, SECCLASS_DOMAIN, perm);
+    return current_has_perm(d, SECCLASS_DOMAIN, perm);
 }
 
 static int flask_hvm_param(struct domain *d, unsigned long op)
@@ -1139,47 +1131,47 @@ static int flask_hvm_param(struct domain *d, unsigned long op)
         perm = HVM__HVMCTL;
     }
 
-    return domain_has_perm(current->domain, d, SECCLASS_HVM, perm);
+    return current_has_perm(d, SECCLASS_HVM, perm);
 }
 
 static int flask_hvm_set_pci_intx_level(struct domain *d)
 {
-    return domain_has_perm(current->domain, d, SECCLASS_HVM, HVM__PCILEVEL);
+    return current_has_perm(d, SECCLASS_HVM, HVM__PCILEVEL);
 }
 
 static int flask_hvm_set_isa_irq_level(struct domain *d)
 {
-    return domain_has_perm(current->domain, d, SECCLASS_HVM, HVM__IRQLEVEL);
+    return current_has_perm(d, SECCLASS_HVM, HVM__IRQLEVEL);
 }
 
 static int flask_hvm_set_pci_link_route(struct domain *d)
 {
-    return domain_has_perm(current->domain, d, SECCLASS_HVM, HVM__PCIROUTE);
+    return current_has_perm(d, SECCLASS_HVM, HVM__PCIROUTE);
 }
 
 static int flask_mem_event_setup(struct domain *d)
 {
-    return domain_has_perm(current->domain, d, SECCLASS_HVM, HVM__MEM_EVENT);
+    return current_has_perm(d, SECCLASS_HVM, HVM__MEM_EVENT);
 }
 
 static int flask_mem_event_control(struct domain *d, int mode, int op)
 {
-    return domain_has_perm(current->domain, d, SECCLASS_HVM, HVM__MEM_EVENT);
+    return current_has_perm(d, SECCLASS_HVM, HVM__MEM_EVENT);
 }
 
 static int flask_mem_event_op(struct domain *d, int op)
 {
-    return domain_has_perm(current->domain, d, SECCLASS_HVM, HVM__MEM_EVENT);
+    return current_has_perm(d, SECCLASS_HVM, HVM__MEM_EVENT);
 }
 
 static int flask_mem_sharing(struct domain *d)
 {
-    return domain_has_perm(current->domain, d, SECCLASS_HVM, HVM__MEM_SHARING);
+    return current_has_perm(d, SECCLASS_HVM, HVM__MEM_SHARING);
 }
 
 static int flask_mem_sharing_op(struct domain *d, struct domain *cd, int op)
 {
-    int rc = domain_has_perm(current->domain, cd, SECCLASS_HVM, HVM__MEM_SHARING);
+    int rc = current_has_perm(cd, SECCLASS_HVM, HVM__MEM_SHARING);
     if ( rc )
         return rc;
     return domain_has_perm(d, cd, SECCLASS_HVM, HVM__SHARE_MEM);
@@ -1187,7 +1179,7 @@ static int flask_mem_sharing_op(struct domain *d, struct domain *cd, int op)
 
 static int flask_audit_p2m(struct domain *d)
 {
-    return domain_has_perm(current->domain, d, SECCLASS_HVM, HVM__AUDIT_P2M);
+    return current_has_perm(d, SECCLASS_HVM, HVM__AUDIT_P2M);
 }
 
 static int flask_apic(struct domain *d, int cmd)
@@ -1248,11 +1240,7 @@ static int flask_physinfo(void)
 
 static int flask_platform_quirk(uint32_t quirk)
 {
-    struct domain_security_struct *dsec;
-    dsec = current->domain->ssid;
-
-    return avc_has_perm(dsec->sid, SECINITSID_XEN, SECCLASS_XEN, 
-                        XEN__QUIRK, NULL);
+    return avc_current_has_perm(SECINITSID_XEN, SECCLASS_XEN, XEN__QUIRK, NULL);
 }
 
 static int flask_firmware_info(void)
@@ -1282,16 +1270,12 @@ static int flask_getidletime(void)
 
 static int flask_machine_memory_map(void)
 {
-    struct domain_security_struct *dsec;
-    dsec = current->domain->ssid;
-
-    return avc_has_perm(dsec->sid, SECINITSID_XEN, SECCLASS_MMU, 
-                        MMU__MEMORYMAP, NULL);
+    return avc_current_has_perm(SECINITSID_XEN, SECCLASS_MMU, MMU__MEMORYMAP, NULL);
 }
 
 static int flask_domain_memory_map(struct domain *d)
 {
-    return domain_has_perm(current->domain, d, SECCLASS_MMU, MMU__MEMORYMAP);
+    return current_has_perm(d, SECCLASS_MMU, MMU__MEMORYMAP);
 }
 
 static int domain_memory_perm(struct domain *d, struct domain *f, l1_pgentry_t pte)
@@ -1314,17 +1298,17 @@ static int domain_memory_perm(struct domain *d, struct domain *f, l1_pgentry_t p
     if ( f->domain_id == DOMID_IO || !mfn_valid(fmfn) )
     {
         struct avc_audit_data ad;
-        struct domain_security_struct *dsec = d->ssid;
-        u32 fsid;
+        u32 dsid, fsid;
+        rc = security_iomem_sid(fmfn, &fsid);
+        if ( rc )
+            return rc;
         AVC_AUDIT_DATA_INIT(&ad, MEMORY);
         ad.sdom = d;
         ad.tdom = f;
         ad.memory.pte = pte.l1;
         ad.memory.mfn = fmfn;
-        rc = security_iomem_sid(fmfn, &fsid);
-        if ( rc )
-            return rc;
-        return avc_has_perm(dsec->sid, fsid, SECCLASS_MMU, map_perms, &ad);
+        dsid = domain_sid(d);
+        return avc_has_perm(dsid, fsid, SECCLASS_MMU, map_perms, &ad);
     }
 
     return domain_has_perm(d, f, SECCLASS_MMU, map_perms);
@@ -1367,43 +1351,40 @@ static int flask_remove_from_physmap(struct domain *d1, struct domain *d2)
 
 static int flask_sendtrigger(struct domain *d)
 {
-    return domain_has_perm(current->domain, d, SECCLASS_DOMAIN, DOMAIN__TRIGGER);
+    return current_has_perm(d, SECCLASS_DOMAIN, DOMAIN__TRIGGER);
 }
 
 static int flask_get_device_group(uint32_t machine_bdf)
 {
     u32 rsid;
     int rc = -EPERM;
-    struct domain_security_struct *ssec = current->domain->ssid;
 
     rc = security_device_sid(machine_bdf, &rsid);
     if ( rc )
         return rc;
 
-    return avc_has_perm(ssec->sid, rsid, SECCLASS_RESOURCE, RESOURCE__STAT_DEVICE, NULL);
+    return avc_current_has_perm(rsid, SECCLASS_RESOURCE, RESOURCE__STAT_DEVICE, NULL);
 }
 
 static int flask_test_assign_device(uint32_t machine_bdf)
 {
     u32 rsid;
     int rc = -EPERM;
-    struct domain_security_struct *ssec = current->domain->ssid;
 
     rc = security_device_sid(machine_bdf, &rsid);
     if ( rc )
         return rc;
 
-    return rc = avc_has_perm(ssec->sid, rsid, SECCLASS_RESOURCE, RESOURCE__STAT_DEVICE, NULL);
+    return avc_current_has_perm(rsid, SECCLASS_RESOURCE, RESOURCE__STAT_DEVICE, NULL);
 }
 
 static int flask_assign_device(struct domain *d, uint32_t machine_bdf)
 {
-    u32 rsid;
+    u32 dsid, rsid;
     int rc = -EPERM;
-    struct domain_security_struct *ssec, *tsec;
     struct avc_audit_data ad;
 
-    rc = domain_has_perm(current->domain, d, SECCLASS_RESOURCE, RESOURCE__ADD);
+    rc = current_has_perm(d, SECCLASS_RESOURCE, RESOURCE__ADD);
     if ( rc )
         return rc;
 
@@ -1413,22 +1394,20 @@ static int flask_assign_device(struct domain *d, uint32_t machine_bdf)
 
     AVC_AUDIT_DATA_INIT(&ad, DEV);
     ad.device = (unsigned long) machine_bdf;
-    ssec = current->domain->ssid;
-    rc = avc_has_perm(ssec->sid, rsid, SECCLASS_RESOURCE, RESOURCE__ADD_DEVICE, &ad);
+    rc = avc_current_has_perm(rsid, SECCLASS_RESOURCE, RESOURCE__ADD_DEVICE, &ad);
     if ( rc )
         return rc;
 
-    tsec = d->ssid;
-    return avc_has_perm(tsec->sid, rsid, SECCLASS_RESOURCE, RESOURCE__USE, &ad);
+    dsid = domain_sid(d);
+    return avc_has_perm(dsid, rsid, SECCLASS_RESOURCE, RESOURCE__USE, &ad);
 }
 
 static int flask_deassign_device(struct domain *d, uint32_t machine_bdf)
 {
     u32 rsid;
     int rc = -EPERM;
-    struct domain_security_struct *ssec = current->domain->ssid;
 
-    rc = domain_has_perm(current->domain, d, SECCLASS_RESOURCE, RESOURCE__REMOVE);
+    rc = current_has_perm(d, SECCLASS_RESOURCE, RESOURCE__REMOVE);
     if ( rc )
         return rc;
 
@@ -1436,18 +1415,17 @@ static int flask_deassign_device(struct domain *d, uint32_t machine_bdf)
     if ( rc )
         return rc;
 
-    return rc = avc_has_perm(ssec->sid, rsid, SECCLASS_RESOURCE, RESOURCE__REMOVE_DEVICE, NULL);
+    return avc_current_has_perm(rsid, SECCLASS_RESOURCE, RESOURCE__REMOVE_DEVICE, NULL);
 }
 
 static int flask_bind_pt_irq (struct domain *d, struct xen_domctl_bind_pt_irq *bind)
 {
-    u32 rsid;
+    u32 dsid, rsid;
     int rc = -EPERM;
     int irq;
-    struct domain_security_struct *ssec, *tsec;
     struct avc_audit_data ad;
 
-    rc = domain_has_perm(current->domain, d, SECCLASS_RESOURCE, RESOURCE__ADD);
+    rc = current_has_perm(d, SECCLASS_RESOURCE, RESOURCE__ADD);
     if ( rc )
         return rc;
 
@@ -1457,23 +1435,22 @@ static int flask_bind_pt_irq (struct domain *d, struct xen_domctl_bind_pt_irq *b
     if ( rc )
         return rc;
 
-    ssec = current->domain->ssid;
-    rc = avc_has_perm(ssec->sid, rsid, SECCLASS_HVM, HVM__BIND_IRQ, &ad);
+    rc = avc_current_has_perm(rsid, SECCLASS_HVM, HVM__BIND_IRQ, &ad);
     if ( rc )
         return rc;
 
-    tsec = d->ssid;
-    return avc_has_perm(tsec->sid, rsid, SECCLASS_RESOURCE, RESOURCE__USE, &ad);
+    dsid = domain_sid(d);
+    return avc_has_perm(dsid, rsid, SECCLASS_RESOURCE, RESOURCE__USE, &ad);
 }
 
 static int flask_unbind_pt_irq (struct domain *d, struct xen_domctl_bind_pt_irq *bind)
 {
-    return domain_has_perm(current->domain, d, SECCLASS_RESOURCE, RESOURCE__REMOVE);
+    return current_has_perm(d, SECCLASS_RESOURCE, RESOURCE__REMOVE);
 }
 
 static int flask_pin_mem_cacheattr (struct domain *d)
 {
-    return domain_has_perm(current->domain, d, SECCLASS_HVM, HVM__CACHEATTR);
+    return current_has_perm(d, SECCLASS_HVM, HVM__CACHEATTR);
 }
 
 static int flask_ext_vcpucontext (struct domain *d, uint32_t cmd)
@@ -1492,7 +1469,7 @@ static int flask_ext_vcpucontext (struct domain *d, uint32_t cmd)
         return -EPERM;
     }
 
-    return domain_has_perm(current->domain, d, SECCLASS_DOMAIN, perm);
+    return current_has_perm(d, SECCLASS_DOMAIN, perm);
 }
 
 static int flask_vcpuextstate (struct domain *d, uint32_t cmd)
@@ -1511,7 +1488,7 @@ static int flask_vcpuextstate (struct domain *d, uint32_t cmd)
             return -EPERM;
     }
 
-    return domain_has_perm(current->domain, d, SECCLASS_DOMAIN, perm);
+    return current_has_perm(d, SECCLASS_DOMAIN, perm);
 }
 #endif
 
diff --git a/xen/xsm/flask/include/objsec.h b/xen/xsm/flask/include/objsec.h
index 4ff52be..6595dc3 100644
--- a/xen/xsm/flask/include/objsec.h
+++ b/xen/xsm/flask/include/objsec.h
@@ -19,6 +19,8 @@
 
 struct domain_security_struct {
     u32 sid;               /* current SID */
+    u32 self_sid;          /* SID for target when operating on DOMID_SELF */
+    u32 target_sid;        /* SID for device model target domain */
 };
 
 struct evtchn_security_struct {
-- 
1.7.11.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 10 19:49:59 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Sep 2012 19: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 1TB9zP-0001Ep-BY; Mon, 10 Sep 2012 19:49:47 +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 1TB9zM-0001A4-TA
	for xen-devel@lists.xen.org; Mon, 10 Sep 2012 19:49:45 +0000
Received: from [85.158.143.99:28040] by server-2.bemta-4.messagelabs.com id
	D8/54-21239-8544E405; Mon, 10 Sep 2012 19:49:44 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-2.tower-216.messagelabs.com!1347306581!24265303!1
X-Originating-IP: [63.239.67.10]
X-SpamReason: No, hits=2.5 required=7.0 tests=BODY_RANDOM_LONG,LONGWORDS
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4900 invoked from network); 10 Sep 2012 19:49:42 -0000
Received: from emvm-gh1-uea09.nsa.gov (HELO nsa.gov) (63.239.67.10)
	by server-2.tower-216.messagelabs.com with SMTP;
	10 Sep 2012 19:49:42 -0000
X-TM-IMSS-Message-ID: <3066d421000f2264@nsa.gov>
Received: from tarius.tycho.ncsc.mil ([144.51.3.1]) by nsa.gov
	([63.239.67.10]) with ESMTP (TREND IMSS SMTP Service 7.1) id
	3066d421000f2264 ; Mon, 10 Sep 2012 15:51: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 q8AJna3p027796; 
	Mon, 10 Sep 2012 15:49:40 -0400
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xen.org
Date: Mon, 10 Sep 2012 15:49:06 -0400
Message-Id: <1347306553-20980-14-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.11.4
In-Reply-To: <1347306553-20980-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1347306553-20980-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Tim Deegan <tim@xen.org>, Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	Keir Fraser <keir@xen.org>, Jan Beulich <jbeulich@suse.com>
Subject: [Xen-devel] [PATCH 13/20] arch/x86: Add missing domctl and
	mem_sharing XSM hooks
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This patch adds new XSM hooks to cover the 12 domctls that were not
previously covered by an XSM hook, and splits up the mem_sharing and
mem_event XSM hooks to better cover what the code is doing.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Cc: Keir Fraser <keir@xen.org>
Cc: Jan Beulich <jbeulich@suse.com>
Cc: Tim Deegan <tim@xen.org>
---
 tools/flask/policy/policy/flask/access_vectors |   5 ++
 tools/flask/policy/policy/modules/xen/xen.if   |   2 +
 xen/arch/x86/domctl.c                          | 111 +++++++++++++------------
 xen/arch/x86/mm/mem_event.c                    |  45 ++++------
 xen/arch/x86/mm/mem_sharing.c                  |  23 ++++-
 xen/include/asm-x86/mem_event.h                |   1 -
 xen/include/xsm/dummy.h                        |  58 ++++++++++++-
 xen/include/xsm/xsm.h                          |  56 ++++++++++++-
 xen/xsm/dummy.c                                |  10 ++-
 xen/xsm/flask/hooks.c                          |  56 ++++++++++++-
 xen/xsm/flask/include/av_perm_to_string.h      |   5 ++
 xen/xsm/flask/include/av_permissions.h         |   5 ++
 12 files changed, 284 insertions(+), 93 deletions(-)

diff --git a/tools/flask/policy/policy/flask/access_vectors b/tools/flask/policy/policy/flask/access_vectors
index 11d02da..28b8ada 100644
--- a/tools/flask/policy/policy/flask/access_vectors
+++ b/tools/flask/policy/policy/flask/access_vectors
@@ -80,6 +80,9 @@ class domain2
 	relabelself
 	make_priv_for
 	set_as_target
+	set_cpuid
+	gettsc
+	settsc
 }
 
 class hvm
@@ -97,6 +100,8 @@ class hvm
     hvmctl
     mem_event
     mem_sharing
+	share_mem
+	audit_p2m
 }
 
 class event
diff --git a/tools/flask/policy/policy/modules/xen/xen.if b/tools/flask/policy/policy/modules/xen/xen.if
index 2ad11b2..3527054 100644
--- a/tools/flask/policy/policy/modules/xen/xen.if
+++ b/tools/flask/policy/policy/modules/xen/xen.if
@@ -29,6 +29,7 @@ define(`create_domain_common', `
 			getdomaininfo hypercall setvcpucontext setextvcpucontext
 			scheduler getvcpuinfo getvcpuextstate getaddrsize
 			getvcpuaffinity setvcpuaffinity };
+	allow $1 $2:domain2 { set_cpuid settsc };
 	allow $1 $2:security check_context;
 	allow $1 $2:shadow enable;
 	allow $1 $2:mmu {map_read map_write adjust memorymap physmap pinpage};
@@ -67,6 +68,7 @@ define(`migrate_domain_out', `
 	allow $1 $2:hvm { gethvmc getparam irqlevel };
 	allow $1 $2:mmu { stat pageinfo map_read };
 	allow $1 $2:domain { getaddrsize getvcpucontext getextvcpucontext getvcpuextstate pause destroy };
+	allow $1 $2:domain2 gettsc;
 ')
 
 ################################################################################
diff --git a/xen/arch/x86/domctl.c b/xen/arch/x86/domctl.c
index 9bc2452..e92c323 100644
--- a/xen/arch/x86/domctl.c
+++ b/xen/arch/x86/domctl.c
@@ -54,26 +54,6 @@ long arch_do_domctl(
 
     switch ( domctl->cmd )
     {
-    /* TODO: the following do not have XSM hooks yet */
-    case XEN_DOMCTL_set_cpuid:
-    case XEN_DOMCTL_suppress_spurious_page_faults:
-    case XEN_DOMCTL_debug_op:
-    case XEN_DOMCTL_gettscinfo:
-    case XEN_DOMCTL_settscinfo:
-    case XEN_DOMCTL_audit_p2m:
-    case XEN_DOMCTL_gdbsx_guestmemio:
-    case XEN_DOMCTL_gdbsx_pausevcpu:
-    case XEN_DOMCTL_gdbsx_unpausevcpu:
-    case XEN_DOMCTL_gdbsx_domstatus:
-    /* getpageframeinfo[23] needs an extra check to avoid allowing queries of some remote GFNs */
-    case XEN_DOMCTL_getpageframeinfo2:
-    case XEN_DOMCTL_getpageframeinfo3:
-        if ( !IS_PRIV(current->domain) )
-            return -EPERM;
-    }
-
-    switch ( domctl->cmd )
-    {
 
     case XEN_DOMCTL_shadow_op:
     {
@@ -1113,6 +1093,10 @@ long arch_do_domctl(
         if ( d == NULL )
             break;
 
+        ret = xsm_set_cpuid(d);
+        if ( ret )
+            goto set_cpuid_out;
+
         for ( i = 0; i < MAX_CPUID_INPUT; i++ )
         {
             cpuid = &d->arch.cpuids[i];
@@ -1136,6 +1120,7 @@ long arch_do_domctl(
             ret = 0;
         }
 
+    set_cpuid_out:
         rcu_unlock_domain(d);
     }
     break;
@@ -1150,6 +1135,10 @@ long arch_do_domctl(
         if ( d == NULL )
             break;
 
+        ret = xsm_gettscinfo(d);
+        if ( ret )
+            goto gettscinfo_out;
+
         domain_pause(d);
         tsc_get_info(d, &info.tsc_mode,
                         &info.elapsed_nsec,
@@ -1161,6 +1150,7 @@ long arch_do_domctl(
             ret = 0;
         domain_unpause(d);
 
+    gettscinfo_out:
         rcu_unlock_domain(d);
     }
     break;
@@ -1174,15 +1164,20 @@ long arch_do_domctl(
         if ( d == NULL )
             break;
 
+        ret = xsm_settscinfo(d);
+        if ( ret )
+            goto settscinfo_out;
+
         domain_pause(d);
         tsc_set_info(d, domctl->u.tsc_info.info.tsc_mode,
                      domctl->u.tsc_info.info.elapsed_nsec,
                      domctl->u.tsc_info.info.gtsc_khz,
                      domctl->u.tsc_info.info.incarnation);
         domain_unpause(d);
+        ret = 0;
 
+    settscinfo_out:
         rcu_unlock_domain(d);
-        ret = 0;
     }
     break;
 
@@ -1194,9 +1189,10 @@ long arch_do_domctl(
         d = rcu_lock_domain_by_id(domctl->domain);
         if ( d != NULL )
         {
-            d->arch.suppress_spurious_page_faults = 1;
+            ret = xsm_domctl(d, domctl->cmd);
+            if ( !ret )
+                d->arch.suppress_spurious_page_faults = 1;
             rcu_unlock_domain(d);
-            ret = 0;
         }
     }
     break;
@@ -1211,6 +1207,10 @@ long arch_do_domctl(
         if ( d == NULL )
             break;
 
+        ret = xsm_debug_op(d);
+        if ( ret )
+            goto debug_op_out;
+
         ret = -EINVAL;
         if ( (domctl->u.debug_op.vcpu >= d->max_vcpus) ||
              ((v = d->vcpu[domctl->u.debug_op.vcpu]) == NULL) )
@@ -1235,6 +1235,10 @@ long arch_do_domctl(
         if ( (d = rcu_lock_domain_by_id(domctl->domain)) == NULL )
             break;
 
+        ret = xsm_debug_op(d);
+        if ( ret )
+            goto gdbsx_guestmemio_out;
+
         domctl->u.gdbsx_guest_memio.remain =
             domctl->u.gdbsx_guest_memio.len;
 
@@ -1242,6 +1246,7 @@ long arch_do_domctl(
         if ( !ret && copy_to_guest(u_domctl, domctl, 1) )
             ret = -EFAULT;
 
+    gdbsx_guestmemio_out:
         rcu_unlock_domain(d);
     }
     break;
@@ -1255,21 +1260,20 @@ long arch_do_domctl(
         if ( (d = rcu_lock_domain_by_id(domctl->domain)) == NULL )
             break;
 
+        ret = xsm_debug_op(d);
+        if ( ret )
+            goto gdbsx_pausevcpu_out;
+
         ret = -EBUSY;
         if ( !d->is_paused_by_controller )
-        {
-            rcu_unlock_domain(d);
-            break;
-        }
+            goto gdbsx_pausevcpu_out;
         ret = -EINVAL;
         if ( domctl->u.gdbsx_pauseunp_vcpu.vcpu >= MAX_VIRT_CPUS ||
              (v = d->vcpu[domctl->u.gdbsx_pauseunp_vcpu.vcpu]) == NULL )
-        {
-            rcu_unlock_domain(d);
-            break;
-        }
+            goto gdbsx_pausevcpu_out;
         vcpu_pause(v);
         ret = 0;
+    gdbsx_pausevcpu_out:
         rcu_unlock_domain(d);
     }
     break;
@@ -1283,23 +1287,22 @@ long arch_do_domctl(
         if ( (d = rcu_lock_domain_by_id(domctl->domain)) == NULL )
             break;
 
+        ret = xsm_debug_op(d);
+        if ( ret )
+            goto gdbsx_unpausevcpu_out;
+
         ret = -EBUSY;
         if ( !d->is_paused_by_controller )
-        {
-            rcu_unlock_domain(d);
-            break;
-        }
+            goto gdbsx_unpausevcpu_out;
         ret = -EINVAL;
         if ( domctl->u.gdbsx_pauseunp_vcpu.vcpu >= MAX_VIRT_CPUS ||
              (v = d->vcpu[domctl->u.gdbsx_pauseunp_vcpu.vcpu]) == NULL )
-        {
-            rcu_unlock_domain(d);
-            break;
-        }
+            goto gdbsx_unpausevcpu_out;
         if ( !atomic_read(&v->pause_count) )
             printk("WARN: Unpausing vcpu:%d which is not paused\n", v->vcpu_id);
         vcpu_unpause(v);
         ret = 0;
+    gdbsx_unpausevcpu_out:
         rcu_unlock_domain(d);
     }
     break;
@@ -1313,6 +1316,10 @@ long arch_do_domctl(
         if ( (d = rcu_lock_domain_by_id(domctl->domain)) == NULL )
             break;
 
+        ret = xsm_debug_op(d);
+        if ( ret )
+            goto gdbsx_domstatus_out;
+
         domctl->u.gdbsx_domstatus.vcpu_id = -1;
         domctl->u.gdbsx_domstatus.paused = d->is_paused_by_controller;
         if ( domctl->u.gdbsx_domstatus.paused )
@@ -1332,6 +1339,7 @@ long arch_do_domctl(
         ret = 0;
         if ( copy_to_guest(u_domctl, domctl, 1) )
             ret = -EFAULT;
+    gdbsx_domstatus_out:
         rcu_unlock_domain(d);
     }
     break;
@@ -1471,10 +1479,8 @@ long arch_do_domctl(
         d = rcu_lock_domain_by_id(domctl->domain);
         if ( d != NULL )
         {
-            ret = xsm_mem_event(d);
-            if ( !ret )
-                ret = mem_event_domctl(d, &domctl->u.mem_event_op,
-                                       guest_handle_cast(u_domctl, void));
+            ret = mem_event_domctl(d, &domctl->u.mem_event_op,
+                                   guest_handle_cast(u_domctl, void));
             rcu_unlock_domain(d);
             copy_to_guest(u_domctl, domctl, 1);
         } 
@@ -1503,16 +1509,19 @@ long arch_do_domctl(
     {
         struct domain *d;
 
-        ret = rcu_lock_remote_target_domain_by_id(domctl->domain, &d);
-        if ( ret != 0 )
+        d = rcu_lock_domain_by_any_id(domctl->domain);
+        if ( d == NULL )
             break;
 
-        audit_p2m(d,
-                  &domctl->u.audit_p2m.orphans,
-                  &domctl->u.audit_p2m.m2p_bad,
-                  &domctl->u.audit_p2m.p2m_bad);
+        ret = xsm_audit_p2m(d);
+        if ( !ret )
+            audit_p2m(d,
+                      &domctl->u.audit_p2m.orphans,
+                      &domctl->u.audit_p2m.m2p_bad,
+                      &domctl->u.audit_p2m.p2m_bad);
+
         rcu_unlock_domain(d);
-        if ( copy_to_guest(u_domctl, domctl, 1) ) 
+        if ( !ret && copy_to_guest(u_domctl, domctl, 1) ) 
             ret = -EFAULT;
     }
     break;
@@ -1531,7 +1540,7 @@ long arch_do_domctl(
         d = rcu_lock_domain_by_id(domctl->domain);
         if ( d != NULL )
         {
-            ret = xsm_mem_event(d);
+            ret = xsm_mem_event_setup(d);
             if ( !ret ) {
                 p2m = p2m_get_hostp2m(d);
                 p2m->access_required = domctl->u.access_required.access_required;
diff --git a/xen/arch/x86/mm/mem_event.c b/xen/arch/x86/mm/mem_event.c
index d728889..d574541 100644
--- a/xen/arch/x86/mm/mem_event.c
+++ b/xen/arch/x86/mm/mem_event.c
@@ -29,6 +29,7 @@
 #include <asm/mem_paging.h>
 #include <asm/mem_access.h>
 #include <asm/mem_sharing.h>
+#include <xsm/xsm.h>
 
 /* for public/io/ring.h macros */
 #define xen_mb()   mb()
@@ -439,34 +440,22 @@ static void mem_sharing_notification(struct vcpu *v, unsigned int port)
         mem_sharing_sharing_resume(v->domain);
 }
 
-struct domain *get_mem_event_op_target(uint32_t domain, int *rc)
-{
-    struct domain *d;
-
-    /* Get the target domain */
-    *rc = rcu_lock_remote_target_domain_by_id(domain, &d);
-    if ( *rc != 0 )
-        return NULL;
-
-    /* Not dying? */
-    if ( d->is_dying )
-    {
-        rcu_unlock_domain(d);
-        *rc = -EINVAL;
-        return NULL;
-    }
-    
-    return d;
-}
-
 int do_mem_event_op(int op, uint32_t domain, void *arg)
 {
     int ret;
     struct domain *d;
 
-    d = get_mem_event_op_target(domain, &ret);
+    d = rcu_lock_domain_by_any_id(domain);
     if ( !d )
-        return ret;
+        return -ESRCH;
+
+    ret = -EINVAL;
+    if ( d->is_dying || d == current->domain )
+        goto out;
+
+    ret = xsm_mem_event_op(d, op);
+    if ( ret )
+        goto out;
 
     switch (op)
     {
@@ -483,6 +472,7 @@ int do_mem_event_op(int op, uint32_t domain, void *arg)
             ret = -ENOSYS;
     }
 
+ out:
     rcu_unlock_domain(d);
     return ret;
 }
@@ -516,6 +506,10 @@ int mem_event_domctl(struct domain *d, xen_domctl_mem_event_op_t *mec,
 {
     int rc;
 
+    rc = xsm_mem_event_control(d, mec->mode, mec->op);
+    if ( rc )
+        return rc;
+
     if ( unlikely(d == current->domain) )
     {
         gdprintk(XENLOG_INFO, "Tried to do a memory event op on itself.\n");
@@ -537,13 +531,6 @@ int mem_event_domctl(struct domain *d, xen_domctl_mem_event_op_t *mec,
         return -EINVAL;
     }
 
-    /* TODO: XSM hook */
-#if 0
-    rc = xsm_mem_event_control(d, mec->op);
-    if ( rc )
-        return rc;
-#endif
-
     rc = -ENOSYS;
 
     switch ( mec->mode )
diff --git a/xen/arch/x86/mm/mem_sharing.c b/xen/arch/x86/mm/mem_sharing.c
index 5103285..395d302 100644
--- a/xen/arch/x86/mm/mem_sharing.c
+++ b/xen/arch/x86/mm/mem_sharing.c
@@ -34,6 +34,7 @@
 #include <asm/atomic.h>
 #include <xen/rcupdate.h>
 #include <asm/event.h>
+#include <xsm/xsm.h>
 
 #include "mm-locks.h"
 
@@ -1345,11 +1346,18 @@ int mem_sharing_memop(struct domain *d, xen_mem_sharing_op_t *mec)
             if ( !mem_sharing_enabled(d) )
                 return -EINVAL;
 
-            cd = get_mem_event_op_target(mec->u.share.client_domain, &rc);
+            cd = rcu_lock_domain_by_any_id(mec->u.share.client_domain);
             if ( !cd )
+                return -ESRCH;
+
+            rc = xsm_mem_sharing_op(d, cd, mec->op);
+            if ( rc )
+            {
+                rcu_unlock_domain(cd);
                 return rc;
+            }
 
-            if ( !mem_sharing_enabled(cd) )
+            if ( cd == current->domain || !mem_sharing_enabled(cd) )
             {
                 rcu_unlock_domain(cd);
                 return -EINVAL;
@@ -1401,11 +1409,18 @@ int mem_sharing_memop(struct domain *d, xen_mem_sharing_op_t *mec)
             if ( !mem_sharing_enabled(d) )
                 return -EINVAL;
 
-            cd = get_mem_event_op_target(mec->u.share.client_domain, &rc);
+            cd = rcu_lock_domain_by_any_id(mec->u.share.client_domain);
             if ( !cd )
+                return -ESRCH;
+
+            rc = xsm_mem_sharing_op(d, cd, mec->op);
+            if ( rc )
+            {
+                rcu_unlock_domain(cd);
                 return rc;
+            }
 
-            if ( !mem_sharing_enabled(cd) )
+            if ( cd == current->domain || !mem_sharing_enabled(cd) )
             {
                 rcu_unlock_domain(cd);
                 return -EINVAL;
diff --git a/xen/include/asm-x86/mem_event.h b/xen/include/asm-x86/mem_event.h
index 23d71c1..448be4f 100644
--- a/xen/include/asm-x86/mem_event.h
+++ b/xen/include/asm-x86/mem_event.h
@@ -62,7 +62,6 @@ void mem_event_put_request(struct domain *d, struct mem_event_domain *med,
 int mem_event_get_response(struct domain *d, struct mem_event_domain *med,
                            mem_event_response_t *rsp);
 
-struct domain *get_mem_event_op_target(uint32_t domain, int *rc);
 int do_mem_event_op(int op, uint32_t domain, void *arg);
 int mem_event_domctl(struct domain *d, xen_domctl_mem_event_op_t *mec,
                      XEN_GUEST_HANDLE(void) u_domctl);
diff --git a/xen/include/xsm/dummy.h b/xen/include/xsm/dummy.h
index 3f5d9b0..afbc504 100644
--- a/xen/include/xsm/dummy.h
+++ b/xen/include/xsm/dummy.h
@@ -171,6 +171,13 @@ static XSM_DEFAULT(int, setdebugging) (struct domain *d)
     return 0;
 }
 
+static XSM_DEFAULT(int, debug_op) (struct domain *d)
+{
+    if ( !IS_PRIV(current->domain) )
+        return -EPERM;
+    return 0;
+}
+
 static XSM_DEFAULT(int, perfcontrol) (void)
 {
     if ( !IS_PRIV(current->domain) )
@@ -562,6 +569,27 @@ static XSM_DEFAULT(int, getpageframeinfo) (struct domain *d)
     return 0;
 }
 
+static XSM_DEFAULT(int, set_cpuid) (struct domain *d)
+{
+    if ( !IS_PRIV(current->domain) )
+        return -EPERM;
+    return 0;
+}
+
+static XSM_DEFAULT(int, gettscinfo) (struct domain *d)
+{
+    if ( !IS_PRIV(current->domain) )
+        return -EPERM;
+    return 0;
+}
+
+static XSM_DEFAULT(int, settscinfo) (struct domain *d)
+{
+    if ( !IS_PRIV(current->domain) )
+        return -EPERM;
+    return 0;
+}
+
 static XSM_DEFAULT(int, getmemlist) (struct domain *d)
 {
     if ( !IS_PRIV(current->domain) )
@@ -632,13 +660,27 @@ static XSM_DEFAULT(int, hvm_inject_msi) (struct domain *d)
     return 0;
 }
 
-static XSM_DEFAULT(int, mem_event) (struct domain *d)
+static XSM_DEFAULT(int, mem_event_setup) (struct domain *d)
 {
     if ( !IS_PRIV(current->domain) )
         return -EPERM;
     return 0;
 }
 
+static XSM_DEFAULT(int, mem_event_control) (struct domain *d, int mode, int op)
+{
+    if ( !IS_PRIV(current->domain) )
+        return -EPERM;
+    return 0;
+}
+
+static XSM_DEFAULT(int, mem_event_op) (struct domain *d, int op)
+{
+    if ( !IS_PRIV_FOR(current->domain, d) )
+        return -EPERM;
+    return 0;
+}
+
 static XSM_DEFAULT(int, mem_sharing) (struct domain *d)
 {
     if ( !IS_PRIV(current->domain) )
@@ -646,6 +688,20 @@ static XSM_DEFAULT(int, mem_sharing) (struct domain *d)
     return 0;
 }
 
+static XSM_DEFAULT(int, mem_sharing_op) (struct domain *d, struct domain *cd, int op)
+{
+    if ( !IS_PRIV_FOR(current->domain, cd) )
+        return -EPERM;
+    return 0;
+}
+
+static XSM_DEFAULT(int, audit_p2m) (struct domain *d)
+{
+    if ( !IS_PRIV(current->domain) )
+        return -EPERM;
+    return 0;
+}
+
 static XSM_DEFAULT(int, apic) (struct domain *d, int cmd)
 {
     if ( !IS_PRIV(current->domain) )
diff --git a/xen/include/xsm/xsm.h b/xen/include/xsm/xsm.h
index 6095a86..6483ec6 100644
--- a/xen/include/xsm/xsm.h
+++ b/xen/include/xsm/xsm.h
@@ -67,6 +67,7 @@ struct xsm_operations {
     int (*setdomainmaxmem) (struct domain *d);
     int (*setdomainhandle) (struct domain *d);
     int (*setdebugging) (struct domain *d);
+    int (*debug_op) (struct domain *d);
     int (*perfcontrol) (void);
     int (*debug_keys) (void);
     int (*getcpuinfo) (void);
@@ -142,6 +143,9 @@ struct xsm_operations {
 #ifdef CONFIG_X86
     int (*shadow_control) (struct domain *d, uint32_t op);
     int (*getpageframeinfo) (struct domain *d);
+    int (*set_cpuid) (struct domain *d);
+    int (*gettscinfo) (struct domain *d);
+    int (*settscinfo) (struct domain *d);
     int (*getmemlist) (struct domain *d);
     int (*hypercall_init) (struct domain *d);
     int (*hvmcontext) (struct domain *d, uint32_t op);
@@ -152,8 +156,12 @@ struct xsm_operations {
     int (*hvm_set_isa_irq_level) (struct domain *d);
     int (*hvm_set_pci_link_route) (struct domain *d);
     int (*hvm_inject_msi) (struct domain *d);
-    int (*mem_event) (struct domain *d);
+    int (*mem_event_setup) (struct domain *d);
+    int (*mem_event_control) (struct domain *d, int mode, int op);
+    int (*mem_event_op) (struct domain *d, int op);
     int (*mem_sharing) (struct domain *d);
+    int (*mem_sharing_op) (struct domain *d, struct domain *cd, int op);
+    int (*audit_p2m) (struct domain *d);
     int (*apic) (struct domain *d, int cmd);
     int (*xen_settime) (void);
     int (*memtype) (uint32_t access);
@@ -301,6 +309,11 @@ static inline int xsm_setdebugging (struct domain *d)
     return xsm_call(setdebugging(d));
 }
 
+static inline int xsm_debug_op (struct domain *d)
+{
+    return xsm_call(debug_op(d));
+}
+
 static inline int xsm_perfcontrol (void)
 {
     return xsm_call(perfcontrol());
@@ -328,7 +341,7 @@ static inline int xsm_get_pmstat(void)
 
 static inline int xsm_setpminfo(void)
 {
-	return xsm_call(setpminfo());
+    return xsm_call(setpminfo());
 }
 
 static inline int xsm_pm_op(void)
@@ -608,6 +621,21 @@ static inline int xsm_getpageframeinfo (struct domain *d)
     return xsm_call(getpageframeinfo(d));
 }
 
+static inline int xsm_set_cpuid (struct domain *d)
+{
+    return xsm_call(set_cpuid(d));
+}
+
+static inline int xsm_gettscinfo (struct domain *d)
+{
+    return xsm_call(gettscinfo(d));
+}
+
+static inline int xsm_settscinfo (struct domain *d)
+{
+    return xsm_call(settscinfo(d));
+}
+
 static inline int xsm_getmemlist (struct domain *d)
 {
     return xsm_call(getmemlist(d));
@@ -658,9 +686,19 @@ static inline int xsm_hvm_inject_msi (struct domain *d)
     return xsm_call(hvm_inject_msi(d));
 }
 
-static inline int xsm_mem_event (struct domain *d)
+static inline int xsm_mem_event_setup (struct domain *d)
 {
-    return xsm_call(mem_event(d));
+    return xsm_call(mem_event_setup(d));
+}
+
+static inline int xsm_mem_event_control (struct domain *d, int mode, int op)
+{
+    return xsm_call(mem_event_control(d, mode, op));
+}
+
+static inline int xsm_mem_event_op (struct domain *d, int op)
+{
+    return xsm_call(mem_event_op(d, op));
 }
 
 static inline int xsm_mem_sharing (struct domain *d)
@@ -668,6 +706,16 @@ static inline int xsm_mem_sharing (struct domain *d)
     return xsm_call(mem_sharing(d));
 }
 
+static inline int xsm_mem_sharing_op (struct domain *d, struct domain *cd, int op)
+{
+    return xsm_call(mem_sharing_op(d, cd, op));
+}
+
+static inline int xsm_audit_p2m (struct domain *d)
+{
+    return xsm_call(audit_p2m(d));
+}
+
 static inline int xsm_apic (struct domain *d, int cmd)
 {
     return xsm_call(apic(d, cmd));
diff --git a/xen/xsm/dummy.c b/xen/xsm/dummy.c
index af532b8..055071a 100644
--- a/xen/xsm/dummy.c
+++ b/xen/xsm/dummy.c
@@ -51,6 +51,7 @@ void xsm_fixup_ops (struct xsm_operations *ops)
     set_to_dummy_if_null(ops, setdomainmaxmem);
     set_to_dummy_if_null(ops, setdomainhandle);
     set_to_dummy_if_null(ops, setdebugging);
+    set_to_dummy_if_null(ops, debug_op);
     set_to_dummy_if_null(ops, perfcontrol);
     set_to_dummy_if_null(ops, debug_keys);
     set_to_dummy_if_null(ops, getcpuinfo);
@@ -124,6 +125,9 @@ void xsm_fixup_ops (struct xsm_operations *ops)
 #ifdef CONFIG_X86
     set_to_dummy_if_null(ops, shadow_control);
     set_to_dummy_if_null(ops, getpageframeinfo);
+    set_to_dummy_if_null(ops, set_cpuid);
+    set_to_dummy_if_null(ops, gettscinfo);
+    set_to_dummy_if_null(ops, settscinfo);
     set_to_dummy_if_null(ops, getmemlist);
     set_to_dummy_if_null(ops, hypercall_init);
     set_to_dummy_if_null(ops, hvmcontext);
@@ -134,8 +138,12 @@ void xsm_fixup_ops (struct xsm_operations *ops)
     set_to_dummy_if_null(ops, hvm_set_isa_irq_level);
     set_to_dummy_if_null(ops, hvm_set_pci_link_route);
     set_to_dummy_if_null(ops, hvm_inject_msi);
-    set_to_dummy_if_null(ops, mem_event);
+    set_to_dummy_if_null(ops, mem_event_setup);
+    set_to_dummy_if_null(ops, mem_event_control);
+    set_to_dummy_if_null(ops, mem_event_op);
     set_to_dummy_if_null(ops, mem_sharing);
+    set_to_dummy_if_null(ops, mem_sharing_op);
+    set_to_dummy_if_null(ops, audit_p2m);
     set_to_dummy_if_null(ops, apic);
     set_to_dummy_if_null(ops, xen_settime);
     set_to_dummy_if_null(ops, memtype);
diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
index 6d4b4f0..fc89ebc 100644
--- a/xen/xsm/flask/hooks.c
+++ b/xen/xsm/flask/hooks.c
@@ -635,6 +635,12 @@ static int flask_setdebugging(struct domain *d)
                            DOMAIN__SETDEBUGGING);
 }
 
+static int flask_debug_op(struct domain *d)
+{
+    return domain_has_perm(current->domain, d, SECCLASS_DOMAIN,
+                           DOMAIN__SETDEBUGGING);
+}
+
 static int flask_debug_keys(void)
 {
     return domain_has_xen(current->domain, XEN__DEBUG);
@@ -1041,6 +1047,21 @@ static int flask_getpageframeinfo(struct domain *d)
     return domain_has_perm(current->domain, d, SECCLASS_MMU, MMU__PAGEINFO);
 }
 
+static int flask_set_cpuid(struct domain *d)
+{
+    return domain_has_perm(current->domain, d, SECCLASS_DOMAIN2, DOMAIN2__SET_CPUID);
+}
+
+static int flask_gettscinfo(struct domain *d)
+{
+    return domain_has_perm(current->domain, d, SECCLASS_DOMAIN2, DOMAIN2__GETTSC);
+}
+
+static int flask_settscinfo(struct domain *d)
+{
+    return domain_has_perm(current->domain, d, SECCLASS_DOMAIN2, DOMAIN2__SETTSC);
+}
+
 static int flask_getmemlist(struct domain *d)
 {
     return domain_has_perm(current->domain, d, SECCLASS_MMU, MMU__PAGELIST);
@@ -1131,7 +1152,17 @@ static int flask_hvm_set_pci_link_route(struct domain *d)
     return domain_has_perm(current->domain, d, SECCLASS_HVM, HVM__PCIROUTE);
 }
 
-static int flask_mem_event(struct domain *d)
+static int flask_mem_event_setup(struct domain *d)
+{
+    return domain_has_perm(current->domain, d, SECCLASS_HVM, HVM__MEM_EVENT);
+}
+
+static int flask_mem_event_control(struct domain *d, int mode, int op)
+{
+    return domain_has_perm(current->domain, d, SECCLASS_HVM, HVM__MEM_EVENT);
+}
+
+static int flask_mem_event_op(struct domain *d, int op)
 {
     return domain_has_perm(current->domain, d, SECCLASS_HVM, HVM__MEM_EVENT);
 }
@@ -1141,6 +1172,19 @@ static int flask_mem_sharing(struct domain *d)
     return domain_has_perm(current->domain, d, SECCLASS_HVM, HVM__MEM_SHARING);
 }
 
+static int flask_mem_sharing_op(struct domain *d, struct domain *cd, int op)
+{
+    int rc = domain_has_perm(current->domain, cd, SECCLASS_HVM, HVM__MEM_SHARING);
+    if ( rc )
+        return rc;
+    return domain_has_perm(d, cd, SECCLASS_HVM, HVM__SHARE_MEM);
+}
+
+static int flask_audit_p2m(struct domain *d)
+{
+    return domain_has_perm(current->domain, d, SECCLASS_HVM, HVM__AUDIT_P2M);
+}
+
 static int flask_apic(struct domain *d, int cmd)
 {
     u32 perm;
@@ -1492,6 +1536,7 @@ static struct xsm_operations flask_ops = {
     .setdomainmaxmem = flask_setdomainmaxmem,
     .setdomainhandle = flask_setdomainhandle,
     .setdebugging = flask_setdebugging,
+    .debug_op = flask_debug_op,
     .perfcontrol = flask_perfcontrol,
     .debug_keys = flask_debug_keys,
     .getcpuinfo = flask_getcpuinfo,
@@ -1560,6 +1605,9 @@ static struct xsm_operations flask_ops = {
 #ifdef CONFIG_X86
     .shadow_control = flask_shadow_control,
     .getpageframeinfo = flask_getpageframeinfo,
+    .set_cpuid = flask_set_cpuid,
+    .gettscinfo = flask_gettscinfo,
+    .settscinfo = flask_settscinfo,
     .getmemlist = flask_getmemlist,
     .hypercall_init = flask_hypercall_init,
     .hvmcontext = flask_hvmcontext,
@@ -1568,8 +1616,12 @@ static struct xsm_operations flask_ops = {
     .hvm_set_pci_intx_level = flask_hvm_set_pci_intx_level,
     .hvm_set_isa_irq_level = flask_hvm_set_isa_irq_level,
     .hvm_set_pci_link_route = flask_hvm_set_pci_link_route,
-    .mem_event = flask_mem_event,
+    .mem_event_setup = flask_mem_event_setup,
+    .mem_event_control = flask_mem_event_control,
+    .mem_event_op = flask_mem_event_op,
     .mem_sharing = flask_mem_sharing,
+    .mem_sharing_op = flask_mem_sharing_op,
+    .audit_p2m = flask_audit_p2m,
     .apic = flask_apic,
     .xen_settime = flask_xen_settime,
     .memtype = flask_memtype,
diff --git a/xen/xsm/flask/include/av_perm_to_string.h b/xen/xsm/flask/include/av_perm_to_string.h
index 10f8e80..997f098 100644
--- a/xen/xsm/flask/include/av_perm_to_string.h
+++ b/xen/xsm/flask/include/av_perm_to_string.h
@@ -66,6 +66,9 @@
    S_(SECCLASS_DOMAIN2, DOMAIN2__RELABELSELF, "relabelself")
    S_(SECCLASS_DOMAIN2, DOMAIN2__MAKE_PRIV_FOR, "make_priv_for")
    S_(SECCLASS_DOMAIN2, DOMAIN2__SET_AS_TARGET, "set_as_target")
+   S_(SECCLASS_DOMAIN2, DOMAIN2__SET_CPUID, "set_cpuid")
+   S_(SECCLASS_DOMAIN2, DOMAIN2__GETTSC, "gettsc")
+   S_(SECCLASS_DOMAIN2, DOMAIN2__SETTSC, "settsc")
    S_(SECCLASS_HVM, HVM__SETHVMC, "sethvmc")
    S_(SECCLASS_HVM, HVM__GETHVMC, "gethvmc")
    S_(SECCLASS_HVM, HVM__SETPARAM, "setparam")
@@ -79,6 +82,8 @@
    S_(SECCLASS_HVM, HVM__HVMCTL, "hvmctl")
    S_(SECCLASS_HVM, HVM__MEM_EVENT, "mem_event")
    S_(SECCLASS_HVM, HVM__MEM_SHARING, "mem_sharing")
+   S_(SECCLASS_HVM, HVM__SHARE_MEM, "share_mem")
+   S_(SECCLASS_HVM, HVM__AUDIT_P2M, "audit_p2m")
    S_(SECCLASS_EVENT, EVENT__BIND, "bind")
    S_(SECCLASS_EVENT, EVENT__SEND, "send")
    S_(SECCLASS_EVENT, EVENT__STATUS, "status")
diff --git a/xen/xsm/flask/include/av_permissions.h b/xen/xsm/flask/include/av_permissions.h
index f7cfee1..8596a55 100644
--- a/xen/xsm/flask/include/av_permissions.h
+++ b/xen/xsm/flask/include/av_permissions.h
@@ -68,6 +68,9 @@
 #define DOMAIN2__RELABELSELF                      0x00000004UL
 #define DOMAIN2__MAKE_PRIV_FOR                    0x00000008UL
 #define DOMAIN2__SET_AS_TARGET                    0x00000010UL
+#define DOMAIN2__SET_CPUID                        0x00000020UL
+#define DOMAIN2__GETTSC                           0x00000040UL
+#define DOMAIN2__SETTSC                           0x00000080UL
 
 #define HVM__SETHVMC                              0x00000001UL
 #define HVM__GETHVMC                              0x00000002UL
@@ -82,6 +85,8 @@
 #define HVM__HVMCTL                               0x00000400UL
 #define HVM__MEM_EVENT                            0x00000800UL
 #define HVM__MEM_SHARING                          0x00001000UL
+#define HVM__SHARE_MEM                            0x00002000UL
+#define HVM__AUDIT_P2M                            0x00004000UL
 
 #define EVENT__BIND                               0x00000001UL
 #define EVENT__SEND                               0x00000002UL
-- 
1.7.11.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 10 19:49:59 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Sep 2012 19: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 1TB9zS-0001Io-Na; Mon, 10 Sep 2012 19:49:50 +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 1TB9zP-00019X-Fw
	for xen-devel@lists.xen.org; Mon, 10 Sep 2012 19:49:47 +0000
Received: from [85.158.143.99:28173] by server-3.bemta-4.messagelabs.com id
	2F/D7-08232-B544E405; Mon, 10 Sep 2012 19:49:47 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-5.tower-216.messagelabs.com!1347306583!29254242!1
X-Originating-IP: [63.239.67.10]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27368 invoked from network); 10 Sep 2012 19:49:44 -0000
Received: from emvm-gh1-uea09.nsa.gov (HELO nsa.gov) (63.239.67.10)
	by server-5.tower-216.messagelabs.com with SMTP;
	10 Sep 2012 19:49:44 -0000
X-TM-IMSS-Message-ID: <3066dc1d000f2269@nsa.gov>
Received: from tarius.tycho.ncsc.mil ([144.51.3.1]) by nsa.gov
	([63.239.67.10]) with ESMTP (TREND IMSS SMTP Service 7.1) id
	3066dc1d000f2269 ; Mon, 10 Sep 2012 15:51:54 -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 q8AJna3s027796; 
	Mon, 10 Sep 2012 15:49:41 -0400
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xen.org
Date: Mon, 10 Sep 2012 15:49:09 -0400
Message-Id: <1347306553-20980-17-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.11.4
In-Reply-To: <1347306553-20980-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1347306553-20980-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: [Xen-devel] [PATCH 16/20] xsm/flask: add distinct SIDs for
	self/target 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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Because the FLASK XSM module no longer checks IS_PRIV for remote domain
accesses covered by XSM permissions, domains now have the ability to
perform memory management and other functions on all domains that have
the same type. While it is possible to prevent this by only creating one
domain per type, this solution significantly limits the flexibility of
the type system.

This patch introduces a domain type transition to represent a domain
that is operating on itself. In the example policy, this is demonstrated
by creating a type with _self appended when declaring a domain type
which will be used for reflexive operations. AVCs for a domain of type
domU_t will look like the following:

scontext=system_u:system_r:domU_t tcontext=system_u:system_r:domU_t_self

This change also allows policy to distinguish between event channels a
domain creates to itself and event channels created between domains of
the same type.

The IS_PRIV_FOR check used for device model domains is also no longer
checked by FLASK; a similar transition is performed when the target is
set and used when the device model accesses its target domain.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 docs/misc/xsm-flask.txt                      |  43 ++-
 tools/flask/policy/policy/modules/xen/xen.if |  60 +++-
 tools/flask/policy/policy/modules/xen/xen.te |  13 +-
 xen/xsm/flask/flask_op.c                     |   9 +
 xen/xsm/flask/hooks.c                        | 425 +++++++++++++--------------
 xen/xsm/flask/include/objsec.h               |   2 +
 6 files changed, 309 insertions(+), 243 deletions(-)

diff --git a/docs/misc/xsm-flask.txt b/docs/misc/xsm-flask.txt
index 0778a28..ff81b01 100644
--- a/docs/misc/xsm-flask.txt
+++ b/docs/misc/xsm-flask.txt
@@ -68,9 +68,43 @@ HVM domains with stubdomain device models use two types (one per domain):
  - dm_dom_t is the device model for a domain with type domHVM_t
 
 One disadvantage of using type enforcement to enforce isolation is that a new
-type is needed for each group of domains. In addition, it is not possible to
-allow isolated_domU_t cannot to create loopback event channels without allowing
-two domains of type isolated_domU_t to communicate with one another.
+type is needed for each group of domains. The user field can be used to address
+this for the most common case of groups that can communicate internally but not
+externally; see "Users and roles" below.
+
+Type transitions
+----------------
+
+Xen defines a number of operations such as memory mapping that are necessary for
+a domain to perform on itself, but are also undesirable to allow a domain to
+perform on every other domain of the same label. While it is possible to address
+this by only creating one domain per type, this solution significantly limits
+the flexibility of the type system. Another method to address this issue is to
+duplicate the permission names for every operation that can be performed on the
+current domain or on other domains; however, this significantly increases the
+necessary number of permissions and complicates the XSM hooks. Instead, this is
+addressed by allowing a distinct type to be used for a domain's access to
+itself. The same applies for a device model domain's access to its designated
+target, allowing the IS_PRIV_FOR checks used in Xen's DAC model to be
+implemented in FLASK.
+
+Upon domain creation (or relabel), a type transition is computed using the
+domain's label as the source and target. The result of this computation is used
+as the target when the domain accesses itself. In the example policy, this
+computed type is the result of appending _self to a domain's type: domU_t_self
+for domU_t. If no type transition rule exists, the domain will continue to use
+its own label for both the source and target. An AVC message will look like:
+
+    scontext=system_u:system_r:domU_t tcontext=system_u:system_r:domU_t_self
+
+A similar type transition is done when a device model domain is associated with
+its target using the set_target operation. The transition is computed with the
+target domain as the source and the device model domain as the target: this
+ordering was chosen in order to preserve the original label for the target when
+no type transition rule exists. In the example policy, these computed types are
+the result of appending _target to the domain.
+
+Type transitions are also used to compute the labels of event channels.
 
 Users and roles
 ---------------
@@ -84,7 +118,8 @@ the customer_1 user.
 Access control rules involving users and roles are defined in the policy
 constraints file (tools/flask/policy/policy/constraints). The example policy
 provides constraints that prevent different users from communicating using
-grants or event channels, while still allowing communication with dom0.
+grants or event channels, while still allowing communication with the system_u
+user where dom0 resides.
 
 Resource Policy
 ---------------
diff --git a/tools/flask/policy/policy/modules/xen/xen.if b/tools/flask/policy/policy/modules/xen/xen.if
index 3527054..1847f23 100644
--- a/tools/flask/policy/policy/modules/xen/xen.if
+++ b/tools/flask/policy/policy/modules/xen/xen.if
@@ -5,15 +5,34 @@
 # Domain creation and setup
 #
 ################################################################################
+define(`declare_domain_common', `
+	allow $1 $2:grant { query setup };
+	allow $1 $2:mmu { adjust physmap map_read map_write stat pinpage updatemp };
+	allow $1 $2:hvm { getparam setparam };
+')
+
 # declare_domain(type, attrs...)
-#   Declare a type as a domain type, and allow basic domain setup
+#   Declare a domain type, along with associated _self and _channel types
+#   Allow the domain to perform basic operations on itself
 define(`declare_domain', `
 	type $1, domain_type`'ifelse(`$#', `1', `', `,shift($@)');
+	type $1_self, domain_type, domain_self_type;
+	type_transition $1 $1:domain $1_self;
+	type $1_channel, event_type;
+	type_transition $1 domain_type:event $1_channel;
+	declare_domain_common($1, $1_self)
+')
+
+# declare_singleton_domain(type, attrs...)
+#   Declare a domain type and associated _channel types.
+#   Note: Because the domain can perform basic operations on itself and any
+#   other domain of the same type, this constructor should be used for types
+#   containing at most one domain. This is not enforced by policy.
+define(`declare_singleton_domain', `
+	type $1, domain_type`'ifelse(`$#', `1', `', `,shift($@)');
 	type $1_channel, event_type;
 	type_transition $1 domain_type:event $1_channel;
-	allow $1 $1:grant { query setup };
-	allow $1 $1:mmu { adjust physmap map_read map_write stat pinpage };
-	allow $1 $1:hvm { getparam setparam };
+	declare_domain_common($1, $1)
 ')
 
 # declare_build_label(type)
@@ -51,6 +70,7 @@ define(`create_domain_build_label', `
 	allow $1 $2_channel:event create;
 	allow $1 $2_building:domain2 relabelfrom;
 	allow $1 $2:domain2 relabelto;
+	allow $2_building $2:domain transition;
 ')
 
 # manage_domain(priv, target)
@@ -101,20 +121,36 @@ define(`domain_comms', `
 ')
 
 # domain_self_comms(domain)
-#   Allow a domain types to communicate with others of its type using grants
-#   and event channels (this includes event channels to DOMID_SELF)
+#   Allow a non-singleton domain type to communicate with itself using grants
+#   and event channels
 define(`domain_self_comms', `
-	create_channel($1, $1, $1_channel)
-	allow $1 $1:grant { map_read map_write copy unmap };
+	create_channel($1, $1_self, $1_channel)
+	allow $1 $1_self:grant { map_read map_write copy unmap };
 ')
 
 # device_model(dm_dom, hvm_dom)
 #   Define how a device model domain interacts with its target
 define(`device_model', `
-	domain_comms($1, $2)
-	allow $1 $2:domain { set_target shutdown };
-	allow $1 $2:mmu { map_read map_write adjust physmap };
-	allow $1 $2:hvm { getparam setparam trackdirtyvram hvmctl irqlevel pciroute };
+	type $2_target, domain_type, domain_target_type;
+	type_transition $2 $1:domain $2_target;
+	allow $1 $2:domain set_target;
+
+	type_transition $2_target domain_type:event $2_channel;
+	create_channel($1, $2_target, $1_channel)
+	create_channel($2, $1, $2_channel)
+	allow $1 $2_channel:event create;
+
+	allow $1 $2_target:domain shutdown;
+	allow $1 $2_target:mmu { map_read map_write adjust physmap };
+	allow $1 $2_target:hvm { getparam setparam trackdirtyvram hvmctl irqlevel pciroute cacheattr };
+')
+
+# make_device_model(priv, dm_dom, hvm_dom)
+#   Allow creation of a device model and HVM domain pair
+define(`make_device_model', `
+	device_model($2, $3)
+	allow $1 $2:domain2 make_priv_for;
+	allow $1 $3:domain2 set_as_target;
 ')
 ################################################################################
 #
diff --git a/tools/flask/policy/policy/modules/xen/xen.te b/tools/flask/policy/policy/modules/xen/xen.te
index 1162153..8d33285 100644
--- a/tools/flask/policy/policy/modules/xen/xen.te
+++ b/tools/flask/policy/policy/modules/xen/xen.te
@@ -8,6 +8,8 @@
 ################################################################################
 attribute xen_type;
 attribute domain_type;
+attribute domain_self_type;
+attribute domain_target_type;
 attribute resource_type;
 attribute event_type;
 attribute mls_priv;
@@ -25,7 +27,7 @@ attribute mls_priv;
 type xen_t, xen_type, mls_priv;
 
 # Domain 0
-declare_domain(dom0_t, mls_priv);
+declare_singleton_domain(dom0_t, mls_priv);
 
 # Untracked I/O memory (pseudo-domain)
 type domio_t, xen_type;
@@ -69,7 +71,7 @@ admin_device(dom0_t, ioport_t)
 admin_device(dom0_t, iomem_t)
 allow dom0_t domio_t:mmu { map_read map_write };
 
-domain_self_comms(dom0_t)
+domain_comms(dom0_t, dom0_t)
 
 auditallow dom0_t security_t:security { load_policy setenforce setbool };
 
@@ -84,11 +86,14 @@ domain_self_comms(domU_t)
 create_domain(dom0_t, domU_t)
 manage_domain(dom0_t, domU_t)
 domain_comms(dom0_t, domU_t)
+domain_comms(domU_t, domU_t)
+domain_self_comms(domU_t)
 
 declare_domain(isolated_domU_t)
 create_domain(dom0_t, isolated_domU_t)
 manage_domain(dom0_t, isolated_domU_t)
 domain_comms(dom0_t, isolated_domU_t)
+domain_self_comms(isolated_domU_t)
 
 # Declare a boolean that denies creation of prot_domU_t domains
 gen_bool(prot_doms_locked, false)
@@ -98,6 +103,8 @@ if (!prot_doms_locked) {
 }
 domain_comms(dom0_t, prot_domU_t)
 domain_comms(domU_t, prot_domU_t)
+domain_comms(prot_domU_t, prot_domU_t)
+domain_self_comms(prot_domU_t)
 
 # domHVM_t is meant to be paired with a qemu-dm stub domain of type dm_dom_t
 declare_domain(domHVM_t)
@@ -110,7 +117,7 @@ declare_domain(dm_dom_t)
 create_domain(dom0_t, dm_dom_t)
 manage_domain(dom0_t, dm_dom_t)
 domain_comms(dom0_t, dm_dom_t)
-device_model(dm_dom_t, domHVM_t)
+make_device_model(dom0_t, dm_dom_t, domHVM_t)
 
 # nomigrate_t must be built via the nomigrate_t_building label; once built,
 # dom0 cannot read its memory.
diff --git a/xen/xsm/flask/flask_op.c b/xen/xsm/flask/flask_op.c
index 9c8dfe7..f8fc108 100644
--- a/xen/xsm/flask/flask_op.c
+++ b/xen/xsm/flask/flask_op.c
@@ -612,6 +612,15 @@ static int flask_relabel_domain(struct xen_flask_relabel *arg)
         goto out;
 
     dsec->sid = arg->sid;
+    dsec->self_sid = arg->sid;
+    security_transition_sid(dsec->sid, dsec->sid, SECCLASS_DOMAIN,
+                            &dsec->self_sid);
+    if ( d->target )
+    {
+        struct domain_security_struct *tsec = d->target->ssid;
+        security_transition_sid(tsec->sid, dsec->sid, SECCLASS_DOMAIN,
+                                &dsec->target_sid);
+    }
 
  out:
     rcu_unlock_domain(d);
diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
index f6ec7bd..7da1754 100644
--- a/xen/xsm/flask/hooks.c
+++ b/xen/xsm/flask/hooks.c
@@ -33,38 +33,69 @@
 
 struct xsm_operations *original_ops = NULL;
 
+static u32 domain_sid(struct domain *dom)
+{
+    struct domain_security_struct *dsec = dom->ssid;
+    return dsec->sid;
+}
+
+static u32 domain_target_sid(struct domain *src, struct domain *dst)
+{
+    struct domain_security_struct *ssec = src->ssid;
+    struct domain_security_struct *dsec = dst->ssid;
+    if (src == dst)
+        return ssec->self_sid;
+    if (src->target == dst)
+        return ssec->target_sid;
+    return dsec->sid;
+}
+
+static u32 evtchn_sid(const struct evtchn *chn)
+{
+    struct evtchn_security_struct *esec = chn->ssid;
+    return esec->sid;
+}
+
 static int domain_has_perm(struct domain *dom1, struct domain *dom2, 
                            u16 class, u32 perms)
 {
-    struct domain_security_struct *dsec1, *dsec2;
+    u32 ssid, tsid;
     struct avc_audit_data ad;
     AVC_AUDIT_DATA_INIT(&ad, NONE);
     ad.sdom = dom1;
     ad.tdom = dom2;
 
-    dsec1 = dom1->ssid;
-    dsec2 = dom2->ssid;
+    ssid = domain_sid(dom1);
+    tsid = domain_target_sid(dom1, dom2);
 
-    return avc_has_perm(dsec1->sid, dsec2->sid, class, perms, &ad);
+    return avc_has_perm(ssid, tsid, class, perms, &ad);
 }
 
-static int domain_has_evtchn(struct domain *d, struct evtchn *chn, u32 perms)
+static int avc_current_has_perm(u32 tsid, u16 class, u32 perm,
+                                struct avc_audit_data *ad)
 {
-    struct domain_security_struct *dsec;
-    struct evtchn_security_struct *esec;
+    u32 csid = domain_sid(current->domain);
+    return avc_has_perm(csid, tsid, class, perm, ad);
+}
 
-    dsec = d->ssid;
-    esec = chn->ssid;
+static int current_has_perm(struct domain *d, u16 class, u32 perms)
+{
+    return domain_has_perm(current->domain, d, class, perms);
+}
+
+static int domain_has_evtchn(struct domain *d, struct evtchn *chn, u32 perms)
+{
+    u32 dsid = domain_sid(d);
+    u32 esid = evtchn_sid(chn);
 
-    return avc_has_perm(dsec->sid, esec->sid, SECCLASS_EVENT, perms, NULL);
+    return avc_has_perm(dsid, esid, SECCLASS_EVENT, perms, NULL);
 }
 
 static int domain_has_xen(struct domain *d, u32 perms)
 {
-    struct domain_security_struct *dsec;
-    dsec = d->ssid;
+    u32 dsid = domain_sid(d);
 
-    return avc_has_perm(dsec->sid, SECINITSID_XEN, SECCLASS_XEN, perms, NULL);
+    return avc_has_perm(dsid, SECINITSID_XEN, SECCLASS_XEN, perms, NULL);
 }
 
 static int get_irq_sid(int irq, u32 *sid, struct avc_audit_data *ad)
@@ -123,6 +154,7 @@ static int flask_domain_alloc_security(struct domain *d)
         dsec->sid = SECINITSID_UNLABELED;
     }
 
+    dsec->self_sid = dsec->sid;
     d->ssid = dsec;
 
     return 0;
@@ -142,68 +174,55 @@ static void flask_domain_free_security(struct domain *d)
 static int flask_evtchn_unbound(struct domain *d1, struct evtchn *chn, 
                                 domid_t id2)
 {
-    u32 newsid;
+    u32 sid1, sid2, newsid;
     int rc;
-    domid_t id;
     struct domain *d2;
-    struct domain_security_struct *dsec, *dsec1, *dsec2;
     struct evtchn_security_struct *esec;
 
-    dsec = current->domain->ssid;
-    dsec1 = d1->ssid;
-    esec = chn->ssid;
-
-    if ( id2 == DOMID_SELF )
-        id = current->domain->domain_id;
-    else
-        id = id2;
-
-    d2 = get_domain_by_id(id);
+    d2 = rcu_lock_domain_by_any_id(id2);
     if ( d2 == NULL )
         return -EPERM;
 
-    dsec2 = d2->ssid;
-    rc = security_transition_sid(dsec1->sid, dsec2->sid, SECCLASS_EVENT, 
-                                 &newsid);
+    sid1 = domain_sid(d1);
+    sid2 = domain_target_sid(d1, d2);
+    esec = chn->ssid;
+
+    rc = security_transition_sid(sid1, sid2, SECCLASS_EVENT, &newsid);
     if ( rc )
         goto out;
 
-    rc = avc_has_perm(dsec->sid, newsid, SECCLASS_EVENT, EVENT__CREATE, NULL);
+    rc = avc_current_has_perm(newsid, SECCLASS_EVENT, EVENT__CREATE, NULL);
     if ( rc )
         goto out;
 
-    rc = avc_has_perm(newsid, dsec2->sid, SECCLASS_EVENT, EVENT__BIND, NULL);
+    rc = avc_has_perm(newsid, sid2, SECCLASS_EVENT, EVENT__BIND, NULL);
     if ( rc )
         goto out;
-    else
-        esec->sid = newsid;
+
+    esec->sid = newsid;
 
  out:
-    put_domain(d2);
+    rcu_unlock_domain(d2);
     return rc;
 }
 
 static int flask_evtchn_interdomain(struct domain *d1, struct evtchn *chn1, 
                                     struct domain *d2, struct evtchn *chn2)
 {
-    u32 newsid;
+    u32 sid1, sid2, newsid, reverse_sid;
     int rc;
-    struct domain_security_struct *dsec, *dsec1, *dsec2;
-    struct evtchn_security_struct *esec1, *esec2;
+    struct evtchn_security_struct *esec1;
     struct avc_audit_data ad;
     AVC_AUDIT_DATA_INIT(&ad, NONE);
     ad.sdom = d1;
     ad.tdom = d2;
 
-    dsec = current->domain->ssid;
-    dsec1 = d1->ssid;
-    dsec2 = d2->ssid;
+    sid1 = domain_sid(d1);
+    sid2 = domain_target_sid(d1, d2);
 
     esec1 = chn1->ssid;
-    esec2 = chn2->ssid;
 
-    rc = security_transition_sid(dsec1->sid, dsec2->sid, 
-                                 SECCLASS_EVENT, &newsid);
+    rc = security_transition_sid(sid1, sid2, SECCLASS_EVENT, &newsid);
     if ( rc )
     {
         printk("%s: security_transition_sid failed, rc=%d (domain=%d)\n",
@@ -211,15 +230,20 @@ static int flask_evtchn_interdomain(struct domain *d1, struct evtchn *chn1,
         return rc;
     }
 
-    rc = avc_has_perm(dsec->sid, newsid, SECCLASS_EVENT, EVENT__CREATE, &ad);
+    rc = avc_current_has_perm(newsid, SECCLASS_EVENT, EVENT__CREATE, &ad);
     if ( rc )
         return rc;
 
-    rc = avc_has_perm(newsid, dsec2->sid, SECCLASS_EVENT, EVENT__BIND, &ad);
+    rc = avc_has_perm(newsid, sid2, SECCLASS_EVENT, EVENT__BIND, &ad);
     if ( rc )
         return rc;
 
-    rc = avc_has_perm(esec2->sid, dsec1->sid, SECCLASS_EVENT, EVENT__BIND, &ad);
+    /* It's possible the target domain has changed (relabel or destroy/create)
+     * since the unbound part was created; re-validate this binding now.
+     */
+    reverse_sid = evtchn_sid(chn2);
+    sid1 = domain_target_sid(d2, d1);
+    rc = avc_has_perm(reverse_sid, sid1, SECCLASS_EVENT, EVENT__BIND, &ad);
     if ( rc )
         return rc;
 
@@ -302,7 +326,6 @@ static void flask_free_security_evtchn(struct evtchn *chn)
 
 static char *flask_show_security_evtchn(struct domain *d, const struct evtchn *chn)
 {
-    struct evtchn_security_struct *esec;
     int irq;
     u32 sid = 0;
     char *ctx;
@@ -312,9 +335,7 @@ static char *flask_show_security_evtchn(struct domain *d, const struct evtchn *c
     {
     case ECS_UNBOUND:
     case ECS_INTERDOMAIN:
-        esec = chn->ssid;
-        if ( esec )
-            sid = esec->sid;
+        sid = evtchn_sid(chn);
         break;
     case ECS_PIRQ:
         irq = domain_pirq_to_irq(d, chn->u.pirq.irq);
@@ -367,12 +388,12 @@ static int flask_grant_query_size(struct domain *d1, struct domain *d2)
 
 static int flask_get_pod_target(struct domain *d)
 {
-    return domain_has_perm(current->domain, d, SECCLASS_DOMAIN, DOMAIN__GETPODTARGET);
+    return current_has_perm(d, SECCLASS_DOMAIN, DOMAIN__GETPODTARGET);
 }
 
 static int flask_set_pod_target(struct domain *d)
 {
-    return domain_has_perm(current->domain, d, SECCLASS_DOMAIN, DOMAIN__SETPODTARGET);
+    return current_has_perm(d, SECCLASS_DOMAIN, DOMAIN__SETPODTARGET);
 }
 
 static int flask_memory_adjust_reservation(struct domain *d1, struct domain *d2)
@@ -455,70 +476,65 @@ static int flask_schedop_shutdown(struct domain *d1, struct domain *d2)
 static void flask_security_domaininfo(struct domain *d, 
                                       struct xen_domctl_getdomaininfo *info)
 {
-    struct domain_security_struct *dsec;
-
-    dsec = d->ssid;
-    info->ssidref = dsec->sid;
+    info->ssidref = domain_sid(d);
 }
 
 static int flask_setvcpucontext(struct domain *d)
 {
-    return domain_has_perm(current->domain, d, SECCLASS_DOMAIN, 
-                           DOMAIN__SETVCPUCONTEXT);
+    return current_has_perm(d, SECCLASS_DOMAIN, DOMAIN__SETVCPUCONTEXT);
 }
 
 static int flask_pausedomain(struct domain *d)
 {
-    return domain_has_perm(current->domain, d, SECCLASS_DOMAIN, DOMAIN__PAUSE);
+    return current_has_perm(d, SECCLASS_DOMAIN, DOMAIN__PAUSE);
 }
 
 static int flask_unpausedomain(struct domain *d)
 {
-    return domain_has_perm(current->domain, d, SECCLASS_DOMAIN, DOMAIN__UNPAUSE);
+    return current_has_perm(d, SECCLASS_DOMAIN, DOMAIN__UNPAUSE);
 }
 
 static int flask_resumedomain(struct domain *d)
 {
-    return domain_has_perm(current->domain, d, SECCLASS_DOMAIN, DOMAIN__RESUME);
+    return current_has_perm(d, SECCLASS_DOMAIN, DOMAIN__RESUME);
 }
 
 static int flask_domain_create(struct domain *d, u32 ssidref)
 {
     int rc;
-    struct domain_security_struct *dsec1;
-    struct domain_security_struct *dsec2;
+    struct domain_security_struct *dsec = d->ssid;
     static int dom0_created = 0;
 
-    dsec1 = current->domain->ssid;
-    dsec2 = d->ssid;
-
     if ( is_idle_domain(current->domain) && !dom0_created )
     {
-        dsec2->sid = SECINITSID_DOM0;
+        dsec->sid = SECINITSID_DOM0;
         dom0_created = 1;
-        return 0;
     }
+    else
+    {
+        rc = avc_current_has_perm(ssidref, SECCLASS_DOMAIN,
+                          DOMAIN__CREATE, NULL);
+        if ( rc )
+            return rc;
 
-    rc = avc_has_perm(dsec1->sid, ssidref, SECCLASS_DOMAIN,
-                      DOMAIN__CREATE, NULL);
-    if ( rc )
-        return rc;
+        dsec->sid = ssidref;
+    }
+    dsec->self_sid = dsec->sid;
 
-    dsec2->sid = ssidref;
+    rc = security_transition_sid(dsec->sid, dsec->sid, SECCLASS_DOMAIN,
+                                 &dsec->self_sid);
 
     return rc;
 }
 
 static int flask_max_vcpus(struct domain *d)
 {
-    return domain_has_perm(current->domain, d, SECCLASS_DOMAIN, 
-                           DOMAIN__MAX_VCPUS);
+    return current_has_perm(d, SECCLASS_DOMAIN, DOMAIN__MAX_VCPUS);
 }
 
 static int flask_destroydomain(struct domain *d)
 {
-    return domain_has_perm(current->domain, d, SECCLASS_DOMAIN, 
-                           DOMAIN__DESTROY);
+    return current_has_perm(d, SECCLASS_DOMAIN, DOMAIN__DESTROY);
 }
 
 static int flask_vcpuaffinity(int cmd, struct domain *d)
@@ -537,7 +553,7 @@ static int flask_vcpuaffinity(int cmd, struct domain *d)
         return -EPERM;
     }
 
-    return domain_has_perm(current->domain, d, SECCLASS_DOMAIN, perm );
+    return current_has_perm(d, SECCLASS_DOMAIN, perm );
 }
 
 static int flask_scheduler(struct domain *d)
@@ -548,53 +564,61 @@ static int flask_scheduler(struct domain *d)
     if ( rc )
         return rc;
 
-    return domain_has_perm(current->domain, d, SECCLASS_DOMAIN, 
-                           DOMAIN__SCHEDULER);
+    return current_has_perm(d, SECCLASS_DOMAIN, DOMAIN__SCHEDULER);
 }
 
 static int flask_getdomaininfo(struct domain *d)
 {
-    return domain_has_perm(current->domain, d, SECCLASS_DOMAIN,
-                           DOMAIN__GETDOMAININFO);
+    return current_has_perm(d, SECCLASS_DOMAIN, DOMAIN__GETDOMAININFO);
 }
 
 static int flask_getvcpucontext(struct domain *d)
 {
-    return domain_has_perm(current->domain, d, SECCLASS_DOMAIN, 
-                           DOMAIN__GETVCPUCONTEXT);
+    return current_has_perm(d, SECCLASS_DOMAIN, DOMAIN__GETVCPUCONTEXT);
 }
 
 static int flask_getvcpuinfo(struct domain *d)
 {
-    return domain_has_perm(current->domain, d, SECCLASS_DOMAIN,
-                           DOMAIN__GETVCPUINFO);
+    return current_has_perm(d, SECCLASS_DOMAIN, DOMAIN__GETVCPUINFO);
 }
 
 static int flask_domain_settime(struct domain *d)
 {
-    return domain_has_perm(current->domain, d, SECCLASS_DOMAIN, DOMAIN__SETTIME);
+    return current_has_perm(d, SECCLASS_DOMAIN, DOMAIN__SETTIME);
 }
 
-static int flask_set_target(struct domain *d, struct domain *e)
+static int flask_set_target(struct domain *d, struct domain *t)
 {
     int rc;
-    rc = domain_has_perm(current->domain, d, SECCLASS_DOMAIN2, DOMAIN2__MAKE_PRIV_FOR);
+    struct domain_security_struct *dsec, *tsec;
+    dsec = d->ssid;
+    tsec = t->ssid;
+
+    rc = current_has_perm(d, SECCLASS_DOMAIN2, DOMAIN2__MAKE_PRIV_FOR);
+    if ( rc )
+        return rc;
+    rc = current_has_perm(t, SECCLASS_DOMAIN2, DOMAIN2__SET_AS_TARGET);
     if ( rc )
         return rc;
-    rc = domain_has_perm(current->domain, e, SECCLASS_DOMAIN2, DOMAIN2__SET_AS_TARGET);
+    /* Use avc_has_perm to avoid resolving target/current SID */
+    rc = avc_has_perm(dsec->sid, tsec->sid, SECCLASS_DOMAIN, DOMAIN__SET_TARGET, NULL);
     if ( rc )
         return rc;
-    return domain_has_perm(d, e, SECCLASS_DOMAIN, DOMAIN__SET_TARGET);
+
+    /* (tsec, dsec) defaults the label to tsec, as it should here */
+    rc = security_transition_sid(tsec->sid, dsec->sid, SECCLASS_DOMAIN,
+                                 &dsec->target_sid);
+    return rc;
 }
 
 static int flask_domctl(struct domain *d, int cmd)
 {
-    return domain_has_perm(current->domain, d, SECCLASS_DOMAIN, DOMAIN__SET_MISC_INFO);
+    return current_has_perm(d, SECCLASS_DOMAIN, DOMAIN__SET_MISC_INFO);
 }
 
 static int flask_set_virq_handler(struct domain *d, uint32_t virq)
 {
-    return domain_has_perm(current->domain, d, SECCLASS_DOMAIN, DOMAIN__SET_VIRQ_HANDLER);
+    return current_has_perm(d, SECCLASS_DOMAIN, DOMAIN__SET_VIRQ_HANDLER);
 }
 
 static int flask_tbufcontrol(void)
@@ -619,26 +643,22 @@ static int flask_sched_id(void)
 
 static int flask_setdomainmaxmem(struct domain *d)
 {
-    return domain_has_perm(current->domain, d, SECCLASS_DOMAIN,
-                           DOMAIN__SETDOMAINMAXMEM);
+    return current_has_perm(d, SECCLASS_DOMAIN, DOMAIN__SETDOMAINMAXMEM);
 }
 
 static int flask_setdomainhandle(struct domain *d)
 {
-    return domain_has_perm(current->domain, d, SECCLASS_DOMAIN,
-                           DOMAIN__SETDOMAINHANDLE);
+    return current_has_perm(d, SECCLASS_DOMAIN, DOMAIN__SETDOMAINHANDLE);
 }
 
 static int flask_setdebugging(struct domain *d)
 {
-    return domain_has_perm(current->domain, d, SECCLASS_DOMAIN,
-                           DOMAIN__SETDEBUGGING);
+    return current_has_perm(d, SECCLASS_DOMAIN, DOMAIN__SETDEBUGGING);
 }
 
 static int flask_debug_op(struct domain *d)
 {
-    return domain_has_perm(current->domain, d, SECCLASS_DOMAIN,
-                           DOMAIN__SETDEBUGGING);
+    return current_has_perm(d, SECCLASS_DOMAIN, DOMAIN__SETDEBUGGING);
 }
 
 static int flask_debug_keys(void)
@@ -700,14 +720,12 @@ static char *flask_show_irq_sid (int irq)
 
 static int flask_map_domain_pirq (struct domain *d, int irq, void *data)
 {
-    u32 sid;
+    u32 sid, dsid;
     int rc = -EPERM;
     struct msi_info *msi = data;
-
-    struct domain_security_struct *ssec, *tsec;
     struct avc_audit_data ad;
 
-    rc = domain_has_perm(current->domain, d, SECCLASS_RESOURCE, RESOURCE__ADD);
+    rc = current_has_perm(d, SECCLASS_RESOURCE, RESOURCE__ADD);
 
     if ( rc )
         return rc;
@@ -723,14 +741,13 @@ static int flask_map_domain_pirq (struct domain *d, int irq, void *data)
     if ( rc )
         return rc;
 
-    ssec = current->domain->ssid;
-    tsec = d->ssid;
+    dsid = domain_sid(d);
 
-    rc = avc_has_perm(ssec->sid, sid, SECCLASS_RESOURCE, RESOURCE__ADD_IRQ, &ad);
+    rc = avc_current_has_perm(sid, SECCLASS_RESOURCE, RESOURCE__ADD_IRQ, &ad);
     if ( rc )
         return rc;
 
-    rc = avc_has_perm(tsec->sid, sid, SECCLASS_RESOURCE, RESOURCE__USE, &ad);
+    rc = avc_has_perm(dsid, sid, SECCLASS_RESOURCE, RESOURCE__USE, &ad);
     return rc;
 }
 
@@ -738,16 +755,12 @@ static int flask_unmap_domain_pirq (struct domain *d, int irq)
 {
     u32 sid;
     int rc = -EPERM;
-
-    struct domain_security_struct *ssec;
     struct avc_audit_data ad;
 
-    rc = domain_has_perm(current->domain, d, SECCLASS_RESOURCE, RESOURCE__REMOVE);
+    rc = current_has_perm(d, SECCLASS_RESOURCE, RESOURCE__REMOVE);
     if ( rc )
         return rc;
 
-    ssec = current->domain->ssid;
-
     if ( irq >= nr_irqs_gsi ) {
         /* TODO support for MSI here */
         return 0;
@@ -757,19 +770,19 @@ static int flask_unmap_domain_pirq (struct domain *d, int irq)
     if ( rc )
         return rc;
 
-    rc = avc_has_perm(ssec->sid, sid, SECCLASS_RESOURCE, RESOURCE__REMOVE_IRQ, &ad);
+    rc = avc_current_has_perm(sid, SECCLASS_RESOURCE, RESOURCE__REMOVE_IRQ, &ad);
     return rc;
 }
 
 static int flask_irq_permission (struct domain *d, int pirq, uint8_t access)
 {
     /* the PIRQ number is not useful; real IRQ is checked during mapping */
-    return domain_has_perm(current->domain, d, SECCLASS_RESOURCE,
-                           resource_to_perm(access));
+    return current_has_perm(d, SECCLASS_RESOURCE, resource_to_perm(access));
 }
 
 struct iomem_has_perm_data {
-    struct domain_security_struct *ssec, *tsec;
+    u32 ssid;
+    u32 dsid;
     u32 perm;
 };
 
@@ -783,12 +796,12 @@ static int _iomem_has_perm(void *v, u32 sid, unsigned long start, unsigned long
     ad.range.start = start;
     ad.range.end = end;
 
-    rc = avc_has_perm(data->ssec->sid, sid, SECCLASS_RESOURCE, data->perm, &ad);
+    rc = avc_has_perm(data->ssid, sid, SECCLASS_RESOURCE, data->perm, &ad);
 
     if ( rc )
         return rc;
 
-    return avc_has_perm(data->tsec->sid, sid, SECCLASS_RESOURCE, RESOURCE__USE, &ad);
+    return avc_has_perm(data->dsid, sid, SECCLASS_RESOURCE, RESOURCE__USE, &ad);
 }
 
 static int flask_iomem_permission(struct domain *d, uint64_t start, uint64_t end, uint8_t access)
@@ -796,7 +809,7 @@ static int flask_iomem_permission(struct domain *d, uint64_t start, uint64_t end
     struct iomem_has_perm_data data;
     int rc;
 
-    rc = domain_has_perm(current->domain, d, SECCLASS_RESOURCE,
+    rc = current_has_perm(d, SECCLASS_RESOURCE,
                          resource_to_perm(access));
     if ( rc )
         return rc;
@@ -806,18 +819,17 @@ static int flask_iomem_permission(struct domain *d, uint64_t start, uint64_t end
     else
         data.perm = RESOURCE__REMOVE_IOMEM;
 
-    data.ssec = current->domain->ssid;
-    data.tsec = d->ssid;
+    data.ssid = domain_sid(current->domain);
+    data.dsid = domain_sid(d);
 
     return security_iterate_iomem_sids(start, end, _iomem_has_perm, &data);
 }
 
 static int flask_pci_config_permission(struct domain *d, uint32_t machine_bdf, uint16_t start, uint16_t end, uint8_t access)
 {
-    u32 rsid;
+    u32 dsid, rsid;
     int rc = -EPERM;
     struct avc_audit_data ad;
-    struct domain_security_struct *ssec;
     u32 perm = RESOURCE__USE;
 
     rc = security_device_sid(machine_bdf, &rsid);
@@ -830,33 +842,24 @@ static int flask_pci_config_permission(struct domain *d, uint32_t machine_bdf, u
 
     AVC_AUDIT_DATA_INIT(&ad, DEV);
     ad.device = (unsigned long) machine_bdf;
-    ssec = d->ssid;
-    return avc_has_perm(ssec->sid, rsid, SECCLASS_RESOURCE, perm, &ad);
+    dsid = domain_sid(d);
+    return avc_has_perm(dsid, rsid, SECCLASS_RESOURCE, perm, &ad);
 
 }
 
 static int flask_resource_plug_core(void)
 {
-    struct domain_security_struct *ssec;
-
-    ssec = current->domain->ssid;
-    return avc_has_perm(ssec->sid, SECINITSID_DOMXEN, SECCLASS_RESOURCE, RESOURCE__PLUG, NULL);
+    return avc_current_has_perm(SECINITSID_DOMXEN, SECCLASS_RESOURCE, RESOURCE__PLUG, NULL);
 }
 
 static int flask_resource_unplug_core(void)
 {
-    struct domain_security_struct *ssec;
-
-    ssec = current->domain->ssid;
-    return avc_has_perm(ssec->sid, SECINITSID_DOMXEN, SECCLASS_RESOURCE, RESOURCE__UNPLUG, NULL);
+    return avc_current_has_perm(SECINITSID_DOMXEN, SECCLASS_RESOURCE, RESOURCE__UNPLUG, NULL);
 }
 
 static int flask_resource_use_core(void)
 {
-    struct domain_security_struct *ssec;
-
-    ssec = current->domain->ssid;
-    return avc_has_perm(ssec->sid, SECINITSID_DOMXEN, SECCLASS_RESOURCE, RESOURCE__USE, NULL);
+    return avc_current_has_perm(SECINITSID_DOMXEN, SECCLASS_RESOURCE, RESOURCE__USE, NULL);
 }
 
 static int flask_resource_plug_pci(uint32_t machine_bdf)
@@ -864,7 +867,6 @@ static int flask_resource_plug_pci(uint32_t machine_bdf)
     u32 rsid;
     int rc = -EPERM;
     struct avc_audit_data ad;
-    struct domain_security_struct *ssec;
 
     rc = security_device_sid(machine_bdf, &rsid);
     if ( rc )
@@ -872,8 +874,7 @@ static int flask_resource_plug_pci(uint32_t machine_bdf)
 
     AVC_AUDIT_DATA_INIT(&ad, DEV);
     ad.device = (unsigned long) machine_bdf;
-    ssec = current->domain->ssid;
-    return avc_has_perm(ssec->sid, rsid, SECCLASS_RESOURCE, RESOURCE__PLUG, &ad);
+    return avc_current_has_perm(rsid, SECCLASS_RESOURCE, RESOURCE__PLUG, &ad);
 }
 
 static int flask_resource_unplug_pci(uint32_t machine_bdf)
@@ -881,7 +882,6 @@ static int flask_resource_unplug_pci(uint32_t machine_bdf)
     u32 rsid;
     int rc = -EPERM;
     struct avc_audit_data ad;
-    struct domain_security_struct *ssec;
 
     rc = security_device_sid(machine_bdf, &rsid);
     if ( rc )
@@ -889,8 +889,7 @@ static int flask_resource_unplug_pci(uint32_t machine_bdf)
 
     AVC_AUDIT_DATA_INIT(&ad, DEV);
     ad.device = (unsigned long) machine_bdf;
-    ssec = current->domain->ssid;
-    return avc_has_perm(ssec->sid, rsid, SECCLASS_RESOURCE, RESOURCE__UNPLUG, &ad);
+    return avc_current_has_perm(rsid, SECCLASS_RESOURCE, RESOURCE__UNPLUG, &ad);
 }
 
 static int flask_resource_setup_pci(uint32_t machine_bdf)
@@ -898,7 +897,6 @@ static int flask_resource_setup_pci(uint32_t machine_bdf)
     u32 rsid;
     int rc = -EPERM;
     struct avc_audit_data ad;
-    struct domain_security_struct *ssec;
 
     rc = security_device_sid(machine_bdf, &rsid);
     if ( rc )
@@ -906,8 +904,7 @@ static int flask_resource_setup_pci(uint32_t machine_bdf)
 
     AVC_AUDIT_DATA_INIT(&ad, DEV);
     ad.device = (unsigned long) machine_bdf;
-    ssec = current->domain->ssid;
-    return avc_has_perm(ssec->sid, rsid, SECCLASS_RESOURCE, RESOURCE__SETUP, &ad);
+    return avc_current_has_perm(rsid, SECCLASS_RESOURCE, RESOURCE__SETUP, &ad);
 }
 
 static int flask_resource_setup_gsi(int gsi)
@@ -915,22 +912,17 @@ static int flask_resource_setup_gsi(int gsi)
     u32 rsid;
     int rc = -EPERM;
     struct avc_audit_data ad;
-    struct domain_security_struct *ssec;
 
     rc = get_irq_sid(gsi, &rsid, &ad);
     if ( rc )
         return rc;
 
-    ssec = current->domain->ssid;
-    return avc_has_perm(ssec->sid, rsid, SECCLASS_RESOURCE, RESOURCE__SETUP, &ad);
+    return avc_current_has_perm(rsid, SECCLASS_RESOURCE, RESOURCE__SETUP, &ad);
 }
 
 static int flask_resource_setup_misc(void)
 {
-    struct domain_security_struct *ssec;
-
-    ssec = current->domain->ssid;
-    return avc_has_perm(ssec->sid, SECINITSID_XEN, SECCLASS_RESOURCE, RESOURCE__SETUP, NULL);
+    return avc_current_has_perm(SECINITSID_XEN, SECCLASS_RESOURCE, RESOURCE__SETUP, NULL);
 }
 
 static inline int flask_page_offline(uint32_t cmd)
@@ -998,11 +990,12 @@ static int flask_shadow_control(struct domain *d, uint32_t op)
         return -EPERM;
     }
 
-    return domain_has_perm(current->domain, d, SECCLASS_SHADOW, perm);
+    return current_has_perm(d, SECCLASS_SHADOW, perm);
 }
 
 struct ioport_has_perm_data {
-    struct domain_security_struct *ssec, *tsec;
+    u32 ssid;
+    u32 dsid;
     u32 perm;
 };
 
@@ -1016,12 +1009,12 @@ static int _ioport_has_perm(void *v, u32 sid, unsigned long start, unsigned long
     ad.range.start = start;
     ad.range.end = end;
 
-    rc = avc_has_perm(data->ssec->sid, sid, SECCLASS_RESOURCE, data->perm, &ad);
+    rc = avc_has_perm(data->ssid, sid, SECCLASS_RESOURCE, data->perm, &ad);
 
     if ( rc )
         return rc;
 
-    return avc_has_perm(data->tsec->sid, sid, SECCLASS_RESOURCE, RESOURCE__USE, &ad);
+    return avc_has_perm(data->dsid, sid, SECCLASS_RESOURCE, RESOURCE__USE, &ad);
 }
 
 
@@ -1030,7 +1023,7 @@ static int flask_ioport_permission(struct domain *d, uint32_t start, uint32_t en
     int rc;
     struct ioport_has_perm_data data;
 
-    rc = domain_has_perm(current->domain, d, SECCLASS_RESOURCE,
+    rc = current_has_perm(d, SECCLASS_RESOURCE,
                          resource_to_perm(access));
 
     if ( rc )
@@ -1041,41 +1034,40 @@ static int flask_ioport_permission(struct domain *d, uint32_t start, uint32_t en
     else
         data.perm = RESOURCE__REMOVE_IOPORT;
 
-    data.ssec = current->domain->ssid;
-    data.tsec = d->ssid;
+    data.ssid = domain_sid(current->domain);
+    data.dsid = domain_sid(d);
 
     return security_iterate_ioport_sids(start, end, _ioport_has_perm, &data);
 }
 
 static int flask_getpageframeinfo(struct domain *d)
 {
-    return domain_has_perm(current->domain, d, SECCLASS_MMU, MMU__PAGEINFO);
+    return current_has_perm(d, SECCLASS_MMU, MMU__PAGEINFO);
 }
 
 static int flask_set_cpuid(struct domain *d)
 {
-    return domain_has_perm(current->domain, d, SECCLASS_DOMAIN2, DOMAIN2__SET_CPUID);
+    return current_has_perm(d, SECCLASS_DOMAIN2, DOMAIN2__SET_CPUID);
 }
 
 static int flask_gettscinfo(struct domain *d)
 {
-    return domain_has_perm(current->domain, d, SECCLASS_DOMAIN2, DOMAIN2__GETTSC);
+    return current_has_perm(d, SECCLASS_DOMAIN2, DOMAIN2__GETTSC);
 }
 
 static int flask_settscinfo(struct domain *d)
 {
-    return domain_has_perm(current->domain, d, SECCLASS_DOMAIN2, DOMAIN2__SETTSC);
+    return current_has_perm(d, SECCLASS_DOMAIN2, DOMAIN2__SETTSC);
 }
 
 static int flask_getmemlist(struct domain *d)
 {
-    return domain_has_perm(current->domain, d, SECCLASS_MMU, MMU__PAGELIST);
+    return current_has_perm(d, SECCLASS_MMU, MMU__PAGELIST);
 }
 
 static int flask_hypercall_init(struct domain *d)
 {
-    return domain_has_perm(current->domain, d, SECCLASS_DOMAIN,
-                           DOMAIN__HYPERCALL);
+    return current_has_perm(d, SECCLASS_DOMAIN, DOMAIN__HYPERCALL);
 }
 
 static int flask_hvmcontext(struct domain *d, uint32_t cmd)
@@ -1098,7 +1090,7 @@ static int flask_hvmcontext(struct domain *d, uint32_t cmd)
         return -EPERM;
     }
 
-    return domain_has_perm(current->domain, d, SECCLASS_HVM, perm);
+    return current_has_perm(d, SECCLASS_HVM, perm);
 }
 
 static int flask_address_size(struct domain *d, uint32_t cmd)
@@ -1117,7 +1109,7 @@ static int flask_address_size(struct domain *d, uint32_t cmd)
         return -EPERM;
     }
 
-    return domain_has_perm(current->domain, d, SECCLASS_DOMAIN, perm);
+    return current_has_perm(d, SECCLASS_DOMAIN, perm);
 }
 
 static int flask_hvm_param(struct domain *d, unsigned long op)
@@ -1139,47 +1131,47 @@ static int flask_hvm_param(struct domain *d, unsigned long op)
         perm = HVM__HVMCTL;
     }
 
-    return domain_has_perm(current->domain, d, SECCLASS_HVM, perm);
+    return current_has_perm(d, SECCLASS_HVM, perm);
 }
 
 static int flask_hvm_set_pci_intx_level(struct domain *d)
 {
-    return domain_has_perm(current->domain, d, SECCLASS_HVM, HVM__PCILEVEL);
+    return current_has_perm(d, SECCLASS_HVM, HVM__PCILEVEL);
 }
 
 static int flask_hvm_set_isa_irq_level(struct domain *d)
 {
-    return domain_has_perm(current->domain, d, SECCLASS_HVM, HVM__IRQLEVEL);
+    return current_has_perm(d, SECCLASS_HVM, HVM__IRQLEVEL);
 }
 
 static int flask_hvm_set_pci_link_route(struct domain *d)
 {
-    return domain_has_perm(current->domain, d, SECCLASS_HVM, HVM__PCIROUTE);
+    return current_has_perm(d, SECCLASS_HVM, HVM__PCIROUTE);
 }
 
 static int flask_mem_event_setup(struct domain *d)
 {
-    return domain_has_perm(current->domain, d, SECCLASS_HVM, HVM__MEM_EVENT);
+    return current_has_perm(d, SECCLASS_HVM, HVM__MEM_EVENT);
 }
 
 static int flask_mem_event_control(struct domain *d, int mode, int op)
 {
-    return domain_has_perm(current->domain, d, SECCLASS_HVM, HVM__MEM_EVENT);
+    return current_has_perm(d, SECCLASS_HVM, HVM__MEM_EVENT);
 }
 
 static int flask_mem_event_op(struct domain *d, int op)
 {
-    return domain_has_perm(current->domain, d, SECCLASS_HVM, HVM__MEM_EVENT);
+    return current_has_perm(d, SECCLASS_HVM, HVM__MEM_EVENT);
 }
 
 static int flask_mem_sharing(struct domain *d)
 {
-    return domain_has_perm(current->domain, d, SECCLASS_HVM, HVM__MEM_SHARING);
+    return current_has_perm(d, SECCLASS_HVM, HVM__MEM_SHARING);
 }
 
 static int flask_mem_sharing_op(struct domain *d, struct domain *cd, int op)
 {
-    int rc = domain_has_perm(current->domain, cd, SECCLASS_HVM, HVM__MEM_SHARING);
+    int rc = current_has_perm(cd, SECCLASS_HVM, HVM__MEM_SHARING);
     if ( rc )
         return rc;
     return domain_has_perm(d, cd, SECCLASS_HVM, HVM__SHARE_MEM);
@@ -1187,7 +1179,7 @@ static int flask_mem_sharing_op(struct domain *d, struct domain *cd, int op)
 
 static int flask_audit_p2m(struct domain *d)
 {
-    return domain_has_perm(current->domain, d, SECCLASS_HVM, HVM__AUDIT_P2M);
+    return current_has_perm(d, SECCLASS_HVM, HVM__AUDIT_P2M);
 }
 
 static int flask_apic(struct domain *d, int cmd)
@@ -1248,11 +1240,7 @@ static int flask_physinfo(void)
 
 static int flask_platform_quirk(uint32_t quirk)
 {
-    struct domain_security_struct *dsec;
-    dsec = current->domain->ssid;
-
-    return avc_has_perm(dsec->sid, SECINITSID_XEN, SECCLASS_XEN, 
-                        XEN__QUIRK, NULL);
+    return avc_current_has_perm(SECINITSID_XEN, SECCLASS_XEN, XEN__QUIRK, NULL);
 }
 
 static int flask_firmware_info(void)
@@ -1282,16 +1270,12 @@ static int flask_getidletime(void)
 
 static int flask_machine_memory_map(void)
 {
-    struct domain_security_struct *dsec;
-    dsec = current->domain->ssid;
-
-    return avc_has_perm(dsec->sid, SECINITSID_XEN, SECCLASS_MMU, 
-                        MMU__MEMORYMAP, NULL);
+    return avc_current_has_perm(SECINITSID_XEN, SECCLASS_MMU, MMU__MEMORYMAP, NULL);
 }
 
 static int flask_domain_memory_map(struct domain *d)
 {
-    return domain_has_perm(current->domain, d, SECCLASS_MMU, MMU__MEMORYMAP);
+    return current_has_perm(d, SECCLASS_MMU, MMU__MEMORYMAP);
 }
 
 static int domain_memory_perm(struct domain *d, struct domain *f, l1_pgentry_t pte)
@@ -1314,17 +1298,17 @@ static int domain_memory_perm(struct domain *d, struct domain *f, l1_pgentry_t p
     if ( f->domain_id == DOMID_IO || !mfn_valid(fmfn) )
     {
         struct avc_audit_data ad;
-        struct domain_security_struct *dsec = d->ssid;
-        u32 fsid;
+        u32 dsid, fsid;
+        rc = security_iomem_sid(fmfn, &fsid);
+        if ( rc )
+            return rc;
         AVC_AUDIT_DATA_INIT(&ad, MEMORY);
         ad.sdom = d;
         ad.tdom = f;
         ad.memory.pte = pte.l1;
         ad.memory.mfn = fmfn;
-        rc = security_iomem_sid(fmfn, &fsid);
-        if ( rc )
-            return rc;
-        return avc_has_perm(dsec->sid, fsid, SECCLASS_MMU, map_perms, &ad);
+        dsid = domain_sid(d);
+        return avc_has_perm(dsid, fsid, SECCLASS_MMU, map_perms, &ad);
     }
 
     return domain_has_perm(d, f, SECCLASS_MMU, map_perms);
@@ -1367,43 +1351,40 @@ static int flask_remove_from_physmap(struct domain *d1, struct domain *d2)
 
 static int flask_sendtrigger(struct domain *d)
 {
-    return domain_has_perm(current->domain, d, SECCLASS_DOMAIN, DOMAIN__TRIGGER);
+    return current_has_perm(d, SECCLASS_DOMAIN, DOMAIN__TRIGGER);
 }
 
 static int flask_get_device_group(uint32_t machine_bdf)
 {
     u32 rsid;
     int rc = -EPERM;
-    struct domain_security_struct *ssec = current->domain->ssid;
 
     rc = security_device_sid(machine_bdf, &rsid);
     if ( rc )
         return rc;
 
-    return avc_has_perm(ssec->sid, rsid, SECCLASS_RESOURCE, RESOURCE__STAT_DEVICE, NULL);
+    return avc_current_has_perm(rsid, SECCLASS_RESOURCE, RESOURCE__STAT_DEVICE, NULL);
 }
 
 static int flask_test_assign_device(uint32_t machine_bdf)
 {
     u32 rsid;
     int rc = -EPERM;
-    struct domain_security_struct *ssec = current->domain->ssid;
 
     rc = security_device_sid(machine_bdf, &rsid);
     if ( rc )
         return rc;
 
-    return rc = avc_has_perm(ssec->sid, rsid, SECCLASS_RESOURCE, RESOURCE__STAT_DEVICE, NULL);
+    return avc_current_has_perm(rsid, SECCLASS_RESOURCE, RESOURCE__STAT_DEVICE, NULL);
 }
 
 static int flask_assign_device(struct domain *d, uint32_t machine_bdf)
 {
-    u32 rsid;
+    u32 dsid, rsid;
     int rc = -EPERM;
-    struct domain_security_struct *ssec, *tsec;
     struct avc_audit_data ad;
 
-    rc = domain_has_perm(current->domain, d, SECCLASS_RESOURCE, RESOURCE__ADD);
+    rc = current_has_perm(d, SECCLASS_RESOURCE, RESOURCE__ADD);
     if ( rc )
         return rc;
 
@@ -1413,22 +1394,20 @@ static int flask_assign_device(struct domain *d, uint32_t machine_bdf)
 
     AVC_AUDIT_DATA_INIT(&ad, DEV);
     ad.device = (unsigned long) machine_bdf;
-    ssec = current->domain->ssid;
-    rc = avc_has_perm(ssec->sid, rsid, SECCLASS_RESOURCE, RESOURCE__ADD_DEVICE, &ad);
+    rc = avc_current_has_perm(rsid, SECCLASS_RESOURCE, RESOURCE__ADD_DEVICE, &ad);
     if ( rc )
         return rc;
 
-    tsec = d->ssid;
-    return avc_has_perm(tsec->sid, rsid, SECCLASS_RESOURCE, RESOURCE__USE, &ad);
+    dsid = domain_sid(d);
+    return avc_has_perm(dsid, rsid, SECCLASS_RESOURCE, RESOURCE__USE, &ad);
 }
 
 static int flask_deassign_device(struct domain *d, uint32_t machine_bdf)
 {
     u32 rsid;
     int rc = -EPERM;
-    struct domain_security_struct *ssec = current->domain->ssid;
 
-    rc = domain_has_perm(current->domain, d, SECCLASS_RESOURCE, RESOURCE__REMOVE);
+    rc = current_has_perm(d, SECCLASS_RESOURCE, RESOURCE__REMOVE);
     if ( rc )
         return rc;
 
@@ -1436,18 +1415,17 @@ static int flask_deassign_device(struct domain *d, uint32_t machine_bdf)
     if ( rc )
         return rc;
 
-    return rc = avc_has_perm(ssec->sid, rsid, SECCLASS_RESOURCE, RESOURCE__REMOVE_DEVICE, NULL);
+    return avc_current_has_perm(rsid, SECCLASS_RESOURCE, RESOURCE__REMOVE_DEVICE, NULL);
 }
 
 static int flask_bind_pt_irq (struct domain *d, struct xen_domctl_bind_pt_irq *bind)
 {
-    u32 rsid;
+    u32 dsid, rsid;
     int rc = -EPERM;
     int irq;
-    struct domain_security_struct *ssec, *tsec;
     struct avc_audit_data ad;
 
-    rc = domain_has_perm(current->domain, d, SECCLASS_RESOURCE, RESOURCE__ADD);
+    rc = current_has_perm(d, SECCLASS_RESOURCE, RESOURCE__ADD);
     if ( rc )
         return rc;
 
@@ -1457,23 +1435,22 @@ static int flask_bind_pt_irq (struct domain *d, struct xen_domctl_bind_pt_irq *b
     if ( rc )
         return rc;
 
-    ssec = current->domain->ssid;
-    rc = avc_has_perm(ssec->sid, rsid, SECCLASS_HVM, HVM__BIND_IRQ, &ad);
+    rc = avc_current_has_perm(rsid, SECCLASS_HVM, HVM__BIND_IRQ, &ad);
     if ( rc )
         return rc;
 
-    tsec = d->ssid;
-    return avc_has_perm(tsec->sid, rsid, SECCLASS_RESOURCE, RESOURCE__USE, &ad);
+    dsid = domain_sid(d);
+    return avc_has_perm(dsid, rsid, SECCLASS_RESOURCE, RESOURCE__USE, &ad);
 }
 
 static int flask_unbind_pt_irq (struct domain *d, struct xen_domctl_bind_pt_irq *bind)
 {
-    return domain_has_perm(current->domain, d, SECCLASS_RESOURCE, RESOURCE__REMOVE);
+    return current_has_perm(d, SECCLASS_RESOURCE, RESOURCE__REMOVE);
 }
 
 static int flask_pin_mem_cacheattr (struct domain *d)
 {
-    return domain_has_perm(current->domain, d, SECCLASS_HVM, HVM__CACHEATTR);
+    return current_has_perm(d, SECCLASS_HVM, HVM__CACHEATTR);
 }
 
 static int flask_ext_vcpucontext (struct domain *d, uint32_t cmd)
@@ -1492,7 +1469,7 @@ static int flask_ext_vcpucontext (struct domain *d, uint32_t cmd)
         return -EPERM;
     }
 
-    return domain_has_perm(current->domain, d, SECCLASS_DOMAIN, perm);
+    return current_has_perm(d, SECCLASS_DOMAIN, perm);
 }
 
 static int flask_vcpuextstate (struct domain *d, uint32_t cmd)
@@ -1511,7 +1488,7 @@ static int flask_vcpuextstate (struct domain *d, uint32_t cmd)
             return -EPERM;
     }
 
-    return domain_has_perm(current->domain, d, SECCLASS_DOMAIN, perm);
+    return current_has_perm(d, SECCLASS_DOMAIN, perm);
 }
 #endif
 
diff --git a/xen/xsm/flask/include/objsec.h b/xen/xsm/flask/include/objsec.h
index 4ff52be..6595dc3 100644
--- a/xen/xsm/flask/include/objsec.h
+++ b/xen/xsm/flask/include/objsec.h
@@ -19,6 +19,8 @@
 
 struct domain_security_struct {
     u32 sid;               /* current SID */
+    u32 self_sid;          /* SID for target when operating on DOMID_SELF */
+    u32 target_sid;        /* SID for device model target domain */
 };
 
 struct evtchn_security_struct {
-- 
1.7.11.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 10 19:49:59 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Sep 2012 19: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 1TB9zP-0001Ep-BY; Mon, 10 Sep 2012 19:49:47 +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 1TB9zM-0001A4-TA
	for xen-devel@lists.xen.org; Mon, 10 Sep 2012 19:49:45 +0000
Received: from [85.158.143.99:28040] by server-2.bemta-4.messagelabs.com id
	D8/54-21239-8544E405; Mon, 10 Sep 2012 19:49:44 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-2.tower-216.messagelabs.com!1347306581!24265303!1
X-Originating-IP: [63.239.67.10]
X-SpamReason: No, hits=2.5 required=7.0 tests=BODY_RANDOM_LONG,LONGWORDS
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4900 invoked from network); 10 Sep 2012 19:49:42 -0000
Received: from emvm-gh1-uea09.nsa.gov (HELO nsa.gov) (63.239.67.10)
	by server-2.tower-216.messagelabs.com with SMTP;
	10 Sep 2012 19:49:42 -0000
X-TM-IMSS-Message-ID: <3066d421000f2264@nsa.gov>
Received: from tarius.tycho.ncsc.mil ([144.51.3.1]) by nsa.gov
	([63.239.67.10]) with ESMTP (TREND IMSS SMTP Service 7.1) id
	3066d421000f2264 ; Mon, 10 Sep 2012 15:51: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 q8AJna3p027796; 
	Mon, 10 Sep 2012 15:49:40 -0400
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xen.org
Date: Mon, 10 Sep 2012 15:49:06 -0400
Message-Id: <1347306553-20980-14-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.11.4
In-Reply-To: <1347306553-20980-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1347306553-20980-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Tim Deegan <tim@xen.org>, Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	Keir Fraser <keir@xen.org>, Jan Beulich <jbeulich@suse.com>
Subject: [Xen-devel] [PATCH 13/20] arch/x86: Add missing domctl and
	mem_sharing XSM hooks
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This patch adds new XSM hooks to cover the 12 domctls that were not
previously covered by an XSM hook, and splits up the mem_sharing and
mem_event XSM hooks to better cover what the code is doing.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Cc: Keir Fraser <keir@xen.org>
Cc: Jan Beulich <jbeulich@suse.com>
Cc: Tim Deegan <tim@xen.org>
---
 tools/flask/policy/policy/flask/access_vectors |   5 ++
 tools/flask/policy/policy/modules/xen/xen.if   |   2 +
 xen/arch/x86/domctl.c                          | 111 +++++++++++++------------
 xen/arch/x86/mm/mem_event.c                    |  45 ++++------
 xen/arch/x86/mm/mem_sharing.c                  |  23 ++++-
 xen/include/asm-x86/mem_event.h                |   1 -
 xen/include/xsm/dummy.h                        |  58 ++++++++++++-
 xen/include/xsm/xsm.h                          |  56 ++++++++++++-
 xen/xsm/dummy.c                                |  10 ++-
 xen/xsm/flask/hooks.c                          |  56 ++++++++++++-
 xen/xsm/flask/include/av_perm_to_string.h      |   5 ++
 xen/xsm/flask/include/av_permissions.h         |   5 ++
 12 files changed, 284 insertions(+), 93 deletions(-)

diff --git a/tools/flask/policy/policy/flask/access_vectors b/tools/flask/policy/policy/flask/access_vectors
index 11d02da..28b8ada 100644
--- a/tools/flask/policy/policy/flask/access_vectors
+++ b/tools/flask/policy/policy/flask/access_vectors
@@ -80,6 +80,9 @@ class domain2
 	relabelself
 	make_priv_for
 	set_as_target
+	set_cpuid
+	gettsc
+	settsc
 }
 
 class hvm
@@ -97,6 +100,8 @@ class hvm
     hvmctl
     mem_event
     mem_sharing
+	share_mem
+	audit_p2m
 }
 
 class event
diff --git a/tools/flask/policy/policy/modules/xen/xen.if b/tools/flask/policy/policy/modules/xen/xen.if
index 2ad11b2..3527054 100644
--- a/tools/flask/policy/policy/modules/xen/xen.if
+++ b/tools/flask/policy/policy/modules/xen/xen.if
@@ -29,6 +29,7 @@ define(`create_domain_common', `
 			getdomaininfo hypercall setvcpucontext setextvcpucontext
 			scheduler getvcpuinfo getvcpuextstate getaddrsize
 			getvcpuaffinity setvcpuaffinity };
+	allow $1 $2:domain2 { set_cpuid settsc };
 	allow $1 $2:security check_context;
 	allow $1 $2:shadow enable;
 	allow $1 $2:mmu {map_read map_write adjust memorymap physmap pinpage};
@@ -67,6 +68,7 @@ define(`migrate_domain_out', `
 	allow $1 $2:hvm { gethvmc getparam irqlevel };
 	allow $1 $2:mmu { stat pageinfo map_read };
 	allow $1 $2:domain { getaddrsize getvcpucontext getextvcpucontext getvcpuextstate pause destroy };
+	allow $1 $2:domain2 gettsc;
 ')
 
 ################################################################################
diff --git a/xen/arch/x86/domctl.c b/xen/arch/x86/domctl.c
index 9bc2452..e92c323 100644
--- a/xen/arch/x86/domctl.c
+++ b/xen/arch/x86/domctl.c
@@ -54,26 +54,6 @@ long arch_do_domctl(
 
     switch ( domctl->cmd )
     {
-    /* TODO: the following do not have XSM hooks yet */
-    case XEN_DOMCTL_set_cpuid:
-    case XEN_DOMCTL_suppress_spurious_page_faults:
-    case XEN_DOMCTL_debug_op:
-    case XEN_DOMCTL_gettscinfo:
-    case XEN_DOMCTL_settscinfo:
-    case XEN_DOMCTL_audit_p2m:
-    case XEN_DOMCTL_gdbsx_guestmemio:
-    case XEN_DOMCTL_gdbsx_pausevcpu:
-    case XEN_DOMCTL_gdbsx_unpausevcpu:
-    case XEN_DOMCTL_gdbsx_domstatus:
-    /* getpageframeinfo[23] needs an extra check to avoid allowing queries of some remote GFNs */
-    case XEN_DOMCTL_getpageframeinfo2:
-    case XEN_DOMCTL_getpageframeinfo3:
-        if ( !IS_PRIV(current->domain) )
-            return -EPERM;
-    }
-
-    switch ( domctl->cmd )
-    {
 
     case XEN_DOMCTL_shadow_op:
     {
@@ -1113,6 +1093,10 @@ long arch_do_domctl(
         if ( d == NULL )
             break;
 
+        ret = xsm_set_cpuid(d);
+        if ( ret )
+            goto set_cpuid_out;
+
         for ( i = 0; i < MAX_CPUID_INPUT; i++ )
         {
             cpuid = &d->arch.cpuids[i];
@@ -1136,6 +1120,7 @@ long arch_do_domctl(
             ret = 0;
         }
 
+    set_cpuid_out:
         rcu_unlock_domain(d);
     }
     break;
@@ -1150,6 +1135,10 @@ long arch_do_domctl(
         if ( d == NULL )
             break;
 
+        ret = xsm_gettscinfo(d);
+        if ( ret )
+            goto gettscinfo_out;
+
         domain_pause(d);
         tsc_get_info(d, &info.tsc_mode,
                         &info.elapsed_nsec,
@@ -1161,6 +1150,7 @@ long arch_do_domctl(
             ret = 0;
         domain_unpause(d);
 
+    gettscinfo_out:
         rcu_unlock_domain(d);
     }
     break;
@@ -1174,15 +1164,20 @@ long arch_do_domctl(
         if ( d == NULL )
             break;
 
+        ret = xsm_settscinfo(d);
+        if ( ret )
+            goto settscinfo_out;
+
         domain_pause(d);
         tsc_set_info(d, domctl->u.tsc_info.info.tsc_mode,
                      domctl->u.tsc_info.info.elapsed_nsec,
                      domctl->u.tsc_info.info.gtsc_khz,
                      domctl->u.tsc_info.info.incarnation);
         domain_unpause(d);
+        ret = 0;
 
+    settscinfo_out:
         rcu_unlock_domain(d);
-        ret = 0;
     }
     break;
 
@@ -1194,9 +1189,10 @@ long arch_do_domctl(
         d = rcu_lock_domain_by_id(domctl->domain);
         if ( d != NULL )
         {
-            d->arch.suppress_spurious_page_faults = 1;
+            ret = xsm_domctl(d, domctl->cmd);
+            if ( !ret )
+                d->arch.suppress_spurious_page_faults = 1;
             rcu_unlock_domain(d);
-            ret = 0;
         }
     }
     break;
@@ -1211,6 +1207,10 @@ long arch_do_domctl(
         if ( d == NULL )
             break;
 
+        ret = xsm_debug_op(d);
+        if ( ret )
+            goto debug_op_out;
+
         ret = -EINVAL;
         if ( (domctl->u.debug_op.vcpu >= d->max_vcpus) ||
              ((v = d->vcpu[domctl->u.debug_op.vcpu]) == NULL) )
@@ -1235,6 +1235,10 @@ long arch_do_domctl(
         if ( (d = rcu_lock_domain_by_id(domctl->domain)) == NULL )
             break;
 
+        ret = xsm_debug_op(d);
+        if ( ret )
+            goto gdbsx_guestmemio_out;
+
         domctl->u.gdbsx_guest_memio.remain =
             domctl->u.gdbsx_guest_memio.len;
 
@@ -1242,6 +1246,7 @@ long arch_do_domctl(
         if ( !ret && copy_to_guest(u_domctl, domctl, 1) )
             ret = -EFAULT;
 
+    gdbsx_guestmemio_out:
         rcu_unlock_domain(d);
     }
     break;
@@ -1255,21 +1260,20 @@ long arch_do_domctl(
         if ( (d = rcu_lock_domain_by_id(domctl->domain)) == NULL )
             break;
 
+        ret = xsm_debug_op(d);
+        if ( ret )
+            goto gdbsx_pausevcpu_out;
+
         ret = -EBUSY;
         if ( !d->is_paused_by_controller )
-        {
-            rcu_unlock_domain(d);
-            break;
-        }
+            goto gdbsx_pausevcpu_out;
         ret = -EINVAL;
         if ( domctl->u.gdbsx_pauseunp_vcpu.vcpu >= MAX_VIRT_CPUS ||
              (v = d->vcpu[domctl->u.gdbsx_pauseunp_vcpu.vcpu]) == NULL )
-        {
-            rcu_unlock_domain(d);
-            break;
-        }
+            goto gdbsx_pausevcpu_out;
         vcpu_pause(v);
         ret = 0;
+    gdbsx_pausevcpu_out:
         rcu_unlock_domain(d);
     }
     break;
@@ -1283,23 +1287,22 @@ long arch_do_domctl(
         if ( (d = rcu_lock_domain_by_id(domctl->domain)) == NULL )
             break;
 
+        ret = xsm_debug_op(d);
+        if ( ret )
+            goto gdbsx_unpausevcpu_out;
+
         ret = -EBUSY;
         if ( !d->is_paused_by_controller )
-        {
-            rcu_unlock_domain(d);
-            break;
-        }
+            goto gdbsx_unpausevcpu_out;
         ret = -EINVAL;
         if ( domctl->u.gdbsx_pauseunp_vcpu.vcpu >= MAX_VIRT_CPUS ||
              (v = d->vcpu[domctl->u.gdbsx_pauseunp_vcpu.vcpu]) == NULL )
-        {
-            rcu_unlock_domain(d);
-            break;
-        }
+            goto gdbsx_unpausevcpu_out;
         if ( !atomic_read(&v->pause_count) )
             printk("WARN: Unpausing vcpu:%d which is not paused\n", v->vcpu_id);
         vcpu_unpause(v);
         ret = 0;
+    gdbsx_unpausevcpu_out:
         rcu_unlock_domain(d);
     }
     break;
@@ -1313,6 +1316,10 @@ long arch_do_domctl(
         if ( (d = rcu_lock_domain_by_id(domctl->domain)) == NULL )
             break;
 
+        ret = xsm_debug_op(d);
+        if ( ret )
+            goto gdbsx_domstatus_out;
+
         domctl->u.gdbsx_domstatus.vcpu_id = -1;
         domctl->u.gdbsx_domstatus.paused = d->is_paused_by_controller;
         if ( domctl->u.gdbsx_domstatus.paused )
@@ -1332,6 +1339,7 @@ long arch_do_domctl(
         ret = 0;
         if ( copy_to_guest(u_domctl, domctl, 1) )
             ret = -EFAULT;
+    gdbsx_domstatus_out:
         rcu_unlock_domain(d);
     }
     break;
@@ -1471,10 +1479,8 @@ long arch_do_domctl(
         d = rcu_lock_domain_by_id(domctl->domain);
         if ( d != NULL )
         {
-            ret = xsm_mem_event(d);
-            if ( !ret )
-                ret = mem_event_domctl(d, &domctl->u.mem_event_op,
-                                       guest_handle_cast(u_domctl, void));
+            ret = mem_event_domctl(d, &domctl->u.mem_event_op,
+                                   guest_handle_cast(u_domctl, void));
             rcu_unlock_domain(d);
             copy_to_guest(u_domctl, domctl, 1);
         } 
@@ -1503,16 +1509,19 @@ long arch_do_domctl(
     {
         struct domain *d;
 
-        ret = rcu_lock_remote_target_domain_by_id(domctl->domain, &d);
-        if ( ret != 0 )
+        d = rcu_lock_domain_by_any_id(domctl->domain);
+        if ( d == NULL )
             break;
 
-        audit_p2m(d,
-                  &domctl->u.audit_p2m.orphans,
-                  &domctl->u.audit_p2m.m2p_bad,
-                  &domctl->u.audit_p2m.p2m_bad);
+        ret = xsm_audit_p2m(d);
+        if ( !ret )
+            audit_p2m(d,
+                      &domctl->u.audit_p2m.orphans,
+                      &domctl->u.audit_p2m.m2p_bad,
+                      &domctl->u.audit_p2m.p2m_bad);
+
         rcu_unlock_domain(d);
-        if ( copy_to_guest(u_domctl, domctl, 1) ) 
+        if ( !ret && copy_to_guest(u_domctl, domctl, 1) ) 
             ret = -EFAULT;
     }
     break;
@@ -1531,7 +1540,7 @@ long arch_do_domctl(
         d = rcu_lock_domain_by_id(domctl->domain);
         if ( d != NULL )
         {
-            ret = xsm_mem_event(d);
+            ret = xsm_mem_event_setup(d);
             if ( !ret ) {
                 p2m = p2m_get_hostp2m(d);
                 p2m->access_required = domctl->u.access_required.access_required;
diff --git a/xen/arch/x86/mm/mem_event.c b/xen/arch/x86/mm/mem_event.c
index d728889..d574541 100644
--- a/xen/arch/x86/mm/mem_event.c
+++ b/xen/arch/x86/mm/mem_event.c
@@ -29,6 +29,7 @@
 #include <asm/mem_paging.h>
 #include <asm/mem_access.h>
 #include <asm/mem_sharing.h>
+#include <xsm/xsm.h>
 
 /* for public/io/ring.h macros */
 #define xen_mb()   mb()
@@ -439,34 +440,22 @@ static void mem_sharing_notification(struct vcpu *v, unsigned int port)
         mem_sharing_sharing_resume(v->domain);
 }
 
-struct domain *get_mem_event_op_target(uint32_t domain, int *rc)
-{
-    struct domain *d;
-
-    /* Get the target domain */
-    *rc = rcu_lock_remote_target_domain_by_id(domain, &d);
-    if ( *rc != 0 )
-        return NULL;
-
-    /* Not dying? */
-    if ( d->is_dying )
-    {
-        rcu_unlock_domain(d);
-        *rc = -EINVAL;
-        return NULL;
-    }
-    
-    return d;
-}
-
 int do_mem_event_op(int op, uint32_t domain, void *arg)
 {
     int ret;
     struct domain *d;
 
-    d = get_mem_event_op_target(domain, &ret);
+    d = rcu_lock_domain_by_any_id(domain);
     if ( !d )
-        return ret;
+        return -ESRCH;
+
+    ret = -EINVAL;
+    if ( d->is_dying || d == current->domain )
+        goto out;
+
+    ret = xsm_mem_event_op(d, op);
+    if ( ret )
+        goto out;
 
     switch (op)
     {
@@ -483,6 +472,7 @@ int do_mem_event_op(int op, uint32_t domain, void *arg)
             ret = -ENOSYS;
     }
 
+ out:
     rcu_unlock_domain(d);
     return ret;
 }
@@ -516,6 +506,10 @@ int mem_event_domctl(struct domain *d, xen_domctl_mem_event_op_t *mec,
 {
     int rc;
 
+    rc = xsm_mem_event_control(d, mec->mode, mec->op);
+    if ( rc )
+        return rc;
+
     if ( unlikely(d == current->domain) )
     {
         gdprintk(XENLOG_INFO, "Tried to do a memory event op on itself.\n");
@@ -537,13 +531,6 @@ int mem_event_domctl(struct domain *d, xen_domctl_mem_event_op_t *mec,
         return -EINVAL;
     }
 
-    /* TODO: XSM hook */
-#if 0
-    rc = xsm_mem_event_control(d, mec->op);
-    if ( rc )
-        return rc;
-#endif
-
     rc = -ENOSYS;
 
     switch ( mec->mode )
diff --git a/xen/arch/x86/mm/mem_sharing.c b/xen/arch/x86/mm/mem_sharing.c
index 5103285..395d302 100644
--- a/xen/arch/x86/mm/mem_sharing.c
+++ b/xen/arch/x86/mm/mem_sharing.c
@@ -34,6 +34,7 @@
 #include <asm/atomic.h>
 #include <xen/rcupdate.h>
 #include <asm/event.h>
+#include <xsm/xsm.h>
 
 #include "mm-locks.h"
 
@@ -1345,11 +1346,18 @@ int mem_sharing_memop(struct domain *d, xen_mem_sharing_op_t *mec)
             if ( !mem_sharing_enabled(d) )
                 return -EINVAL;
 
-            cd = get_mem_event_op_target(mec->u.share.client_domain, &rc);
+            cd = rcu_lock_domain_by_any_id(mec->u.share.client_domain);
             if ( !cd )
+                return -ESRCH;
+
+            rc = xsm_mem_sharing_op(d, cd, mec->op);
+            if ( rc )
+            {
+                rcu_unlock_domain(cd);
                 return rc;
+            }
 
-            if ( !mem_sharing_enabled(cd) )
+            if ( cd == current->domain || !mem_sharing_enabled(cd) )
             {
                 rcu_unlock_domain(cd);
                 return -EINVAL;
@@ -1401,11 +1409,18 @@ int mem_sharing_memop(struct domain *d, xen_mem_sharing_op_t *mec)
             if ( !mem_sharing_enabled(d) )
                 return -EINVAL;
 
-            cd = get_mem_event_op_target(mec->u.share.client_domain, &rc);
+            cd = rcu_lock_domain_by_any_id(mec->u.share.client_domain);
             if ( !cd )
+                return -ESRCH;
+
+            rc = xsm_mem_sharing_op(d, cd, mec->op);
+            if ( rc )
+            {
+                rcu_unlock_domain(cd);
                 return rc;
+            }
 
-            if ( !mem_sharing_enabled(cd) )
+            if ( cd == current->domain || !mem_sharing_enabled(cd) )
             {
                 rcu_unlock_domain(cd);
                 return -EINVAL;
diff --git a/xen/include/asm-x86/mem_event.h b/xen/include/asm-x86/mem_event.h
index 23d71c1..448be4f 100644
--- a/xen/include/asm-x86/mem_event.h
+++ b/xen/include/asm-x86/mem_event.h
@@ -62,7 +62,6 @@ void mem_event_put_request(struct domain *d, struct mem_event_domain *med,
 int mem_event_get_response(struct domain *d, struct mem_event_domain *med,
                            mem_event_response_t *rsp);
 
-struct domain *get_mem_event_op_target(uint32_t domain, int *rc);
 int do_mem_event_op(int op, uint32_t domain, void *arg);
 int mem_event_domctl(struct domain *d, xen_domctl_mem_event_op_t *mec,
                      XEN_GUEST_HANDLE(void) u_domctl);
diff --git a/xen/include/xsm/dummy.h b/xen/include/xsm/dummy.h
index 3f5d9b0..afbc504 100644
--- a/xen/include/xsm/dummy.h
+++ b/xen/include/xsm/dummy.h
@@ -171,6 +171,13 @@ static XSM_DEFAULT(int, setdebugging) (struct domain *d)
     return 0;
 }
 
+static XSM_DEFAULT(int, debug_op) (struct domain *d)
+{
+    if ( !IS_PRIV(current->domain) )
+        return -EPERM;
+    return 0;
+}
+
 static XSM_DEFAULT(int, perfcontrol) (void)
 {
     if ( !IS_PRIV(current->domain) )
@@ -562,6 +569,27 @@ static XSM_DEFAULT(int, getpageframeinfo) (struct domain *d)
     return 0;
 }
 
+static XSM_DEFAULT(int, set_cpuid) (struct domain *d)
+{
+    if ( !IS_PRIV(current->domain) )
+        return -EPERM;
+    return 0;
+}
+
+static XSM_DEFAULT(int, gettscinfo) (struct domain *d)
+{
+    if ( !IS_PRIV(current->domain) )
+        return -EPERM;
+    return 0;
+}
+
+static XSM_DEFAULT(int, settscinfo) (struct domain *d)
+{
+    if ( !IS_PRIV(current->domain) )
+        return -EPERM;
+    return 0;
+}
+
 static XSM_DEFAULT(int, getmemlist) (struct domain *d)
 {
     if ( !IS_PRIV(current->domain) )
@@ -632,13 +660,27 @@ static XSM_DEFAULT(int, hvm_inject_msi) (struct domain *d)
     return 0;
 }
 
-static XSM_DEFAULT(int, mem_event) (struct domain *d)
+static XSM_DEFAULT(int, mem_event_setup) (struct domain *d)
 {
     if ( !IS_PRIV(current->domain) )
         return -EPERM;
     return 0;
 }
 
+static XSM_DEFAULT(int, mem_event_control) (struct domain *d, int mode, int op)
+{
+    if ( !IS_PRIV(current->domain) )
+        return -EPERM;
+    return 0;
+}
+
+static XSM_DEFAULT(int, mem_event_op) (struct domain *d, int op)
+{
+    if ( !IS_PRIV_FOR(current->domain, d) )
+        return -EPERM;
+    return 0;
+}
+
 static XSM_DEFAULT(int, mem_sharing) (struct domain *d)
 {
     if ( !IS_PRIV(current->domain) )
@@ -646,6 +688,20 @@ static XSM_DEFAULT(int, mem_sharing) (struct domain *d)
     return 0;
 }
 
+static XSM_DEFAULT(int, mem_sharing_op) (struct domain *d, struct domain *cd, int op)
+{
+    if ( !IS_PRIV_FOR(current->domain, cd) )
+        return -EPERM;
+    return 0;
+}
+
+static XSM_DEFAULT(int, audit_p2m) (struct domain *d)
+{
+    if ( !IS_PRIV(current->domain) )
+        return -EPERM;
+    return 0;
+}
+
 static XSM_DEFAULT(int, apic) (struct domain *d, int cmd)
 {
     if ( !IS_PRIV(current->domain) )
diff --git a/xen/include/xsm/xsm.h b/xen/include/xsm/xsm.h
index 6095a86..6483ec6 100644
--- a/xen/include/xsm/xsm.h
+++ b/xen/include/xsm/xsm.h
@@ -67,6 +67,7 @@ struct xsm_operations {
     int (*setdomainmaxmem) (struct domain *d);
     int (*setdomainhandle) (struct domain *d);
     int (*setdebugging) (struct domain *d);
+    int (*debug_op) (struct domain *d);
     int (*perfcontrol) (void);
     int (*debug_keys) (void);
     int (*getcpuinfo) (void);
@@ -142,6 +143,9 @@ struct xsm_operations {
 #ifdef CONFIG_X86
     int (*shadow_control) (struct domain *d, uint32_t op);
     int (*getpageframeinfo) (struct domain *d);
+    int (*set_cpuid) (struct domain *d);
+    int (*gettscinfo) (struct domain *d);
+    int (*settscinfo) (struct domain *d);
     int (*getmemlist) (struct domain *d);
     int (*hypercall_init) (struct domain *d);
     int (*hvmcontext) (struct domain *d, uint32_t op);
@@ -152,8 +156,12 @@ struct xsm_operations {
     int (*hvm_set_isa_irq_level) (struct domain *d);
     int (*hvm_set_pci_link_route) (struct domain *d);
     int (*hvm_inject_msi) (struct domain *d);
-    int (*mem_event) (struct domain *d);
+    int (*mem_event_setup) (struct domain *d);
+    int (*mem_event_control) (struct domain *d, int mode, int op);
+    int (*mem_event_op) (struct domain *d, int op);
     int (*mem_sharing) (struct domain *d);
+    int (*mem_sharing_op) (struct domain *d, struct domain *cd, int op);
+    int (*audit_p2m) (struct domain *d);
     int (*apic) (struct domain *d, int cmd);
     int (*xen_settime) (void);
     int (*memtype) (uint32_t access);
@@ -301,6 +309,11 @@ static inline int xsm_setdebugging (struct domain *d)
     return xsm_call(setdebugging(d));
 }
 
+static inline int xsm_debug_op (struct domain *d)
+{
+    return xsm_call(debug_op(d));
+}
+
 static inline int xsm_perfcontrol (void)
 {
     return xsm_call(perfcontrol());
@@ -328,7 +341,7 @@ static inline int xsm_get_pmstat(void)
 
 static inline int xsm_setpminfo(void)
 {
-	return xsm_call(setpminfo());
+    return xsm_call(setpminfo());
 }
 
 static inline int xsm_pm_op(void)
@@ -608,6 +621,21 @@ static inline int xsm_getpageframeinfo (struct domain *d)
     return xsm_call(getpageframeinfo(d));
 }
 
+static inline int xsm_set_cpuid (struct domain *d)
+{
+    return xsm_call(set_cpuid(d));
+}
+
+static inline int xsm_gettscinfo (struct domain *d)
+{
+    return xsm_call(gettscinfo(d));
+}
+
+static inline int xsm_settscinfo (struct domain *d)
+{
+    return xsm_call(settscinfo(d));
+}
+
 static inline int xsm_getmemlist (struct domain *d)
 {
     return xsm_call(getmemlist(d));
@@ -658,9 +686,19 @@ static inline int xsm_hvm_inject_msi (struct domain *d)
     return xsm_call(hvm_inject_msi(d));
 }
 
-static inline int xsm_mem_event (struct domain *d)
+static inline int xsm_mem_event_setup (struct domain *d)
 {
-    return xsm_call(mem_event(d));
+    return xsm_call(mem_event_setup(d));
+}
+
+static inline int xsm_mem_event_control (struct domain *d, int mode, int op)
+{
+    return xsm_call(mem_event_control(d, mode, op));
+}
+
+static inline int xsm_mem_event_op (struct domain *d, int op)
+{
+    return xsm_call(mem_event_op(d, op));
 }
 
 static inline int xsm_mem_sharing (struct domain *d)
@@ -668,6 +706,16 @@ static inline int xsm_mem_sharing (struct domain *d)
     return xsm_call(mem_sharing(d));
 }
 
+static inline int xsm_mem_sharing_op (struct domain *d, struct domain *cd, int op)
+{
+    return xsm_call(mem_sharing_op(d, cd, op));
+}
+
+static inline int xsm_audit_p2m (struct domain *d)
+{
+    return xsm_call(audit_p2m(d));
+}
+
 static inline int xsm_apic (struct domain *d, int cmd)
 {
     return xsm_call(apic(d, cmd));
diff --git a/xen/xsm/dummy.c b/xen/xsm/dummy.c
index af532b8..055071a 100644
--- a/xen/xsm/dummy.c
+++ b/xen/xsm/dummy.c
@@ -51,6 +51,7 @@ void xsm_fixup_ops (struct xsm_operations *ops)
     set_to_dummy_if_null(ops, setdomainmaxmem);
     set_to_dummy_if_null(ops, setdomainhandle);
     set_to_dummy_if_null(ops, setdebugging);
+    set_to_dummy_if_null(ops, debug_op);
     set_to_dummy_if_null(ops, perfcontrol);
     set_to_dummy_if_null(ops, debug_keys);
     set_to_dummy_if_null(ops, getcpuinfo);
@@ -124,6 +125,9 @@ void xsm_fixup_ops (struct xsm_operations *ops)
 #ifdef CONFIG_X86
     set_to_dummy_if_null(ops, shadow_control);
     set_to_dummy_if_null(ops, getpageframeinfo);
+    set_to_dummy_if_null(ops, set_cpuid);
+    set_to_dummy_if_null(ops, gettscinfo);
+    set_to_dummy_if_null(ops, settscinfo);
     set_to_dummy_if_null(ops, getmemlist);
     set_to_dummy_if_null(ops, hypercall_init);
     set_to_dummy_if_null(ops, hvmcontext);
@@ -134,8 +138,12 @@ void xsm_fixup_ops (struct xsm_operations *ops)
     set_to_dummy_if_null(ops, hvm_set_isa_irq_level);
     set_to_dummy_if_null(ops, hvm_set_pci_link_route);
     set_to_dummy_if_null(ops, hvm_inject_msi);
-    set_to_dummy_if_null(ops, mem_event);
+    set_to_dummy_if_null(ops, mem_event_setup);
+    set_to_dummy_if_null(ops, mem_event_control);
+    set_to_dummy_if_null(ops, mem_event_op);
     set_to_dummy_if_null(ops, mem_sharing);
+    set_to_dummy_if_null(ops, mem_sharing_op);
+    set_to_dummy_if_null(ops, audit_p2m);
     set_to_dummy_if_null(ops, apic);
     set_to_dummy_if_null(ops, xen_settime);
     set_to_dummy_if_null(ops, memtype);
diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
index 6d4b4f0..fc89ebc 100644
--- a/xen/xsm/flask/hooks.c
+++ b/xen/xsm/flask/hooks.c
@@ -635,6 +635,12 @@ static int flask_setdebugging(struct domain *d)
                            DOMAIN__SETDEBUGGING);
 }
 
+static int flask_debug_op(struct domain *d)
+{
+    return domain_has_perm(current->domain, d, SECCLASS_DOMAIN,
+                           DOMAIN__SETDEBUGGING);
+}
+
 static int flask_debug_keys(void)
 {
     return domain_has_xen(current->domain, XEN__DEBUG);
@@ -1041,6 +1047,21 @@ static int flask_getpageframeinfo(struct domain *d)
     return domain_has_perm(current->domain, d, SECCLASS_MMU, MMU__PAGEINFO);
 }
 
+static int flask_set_cpuid(struct domain *d)
+{
+    return domain_has_perm(current->domain, d, SECCLASS_DOMAIN2, DOMAIN2__SET_CPUID);
+}
+
+static int flask_gettscinfo(struct domain *d)
+{
+    return domain_has_perm(current->domain, d, SECCLASS_DOMAIN2, DOMAIN2__GETTSC);
+}
+
+static int flask_settscinfo(struct domain *d)
+{
+    return domain_has_perm(current->domain, d, SECCLASS_DOMAIN2, DOMAIN2__SETTSC);
+}
+
 static int flask_getmemlist(struct domain *d)
 {
     return domain_has_perm(current->domain, d, SECCLASS_MMU, MMU__PAGELIST);
@@ -1131,7 +1152,17 @@ static int flask_hvm_set_pci_link_route(struct domain *d)
     return domain_has_perm(current->domain, d, SECCLASS_HVM, HVM__PCIROUTE);
 }
 
-static int flask_mem_event(struct domain *d)
+static int flask_mem_event_setup(struct domain *d)
+{
+    return domain_has_perm(current->domain, d, SECCLASS_HVM, HVM__MEM_EVENT);
+}
+
+static int flask_mem_event_control(struct domain *d, int mode, int op)
+{
+    return domain_has_perm(current->domain, d, SECCLASS_HVM, HVM__MEM_EVENT);
+}
+
+static int flask_mem_event_op(struct domain *d, int op)
 {
     return domain_has_perm(current->domain, d, SECCLASS_HVM, HVM__MEM_EVENT);
 }
@@ -1141,6 +1172,19 @@ static int flask_mem_sharing(struct domain *d)
     return domain_has_perm(current->domain, d, SECCLASS_HVM, HVM__MEM_SHARING);
 }
 
+static int flask_mem_sharing_op(struct domain *d, struct domain *cd, int op)
+{
+    int rc = domain_has_perm(current->domain, cd, SECCLASS_HVM, HVM__MEM_SHARING);
+    if ( rc )
+        return rc;
+    return domain_has_perm(d, cd, SECCLASS_HVM, HVM__SHARE_MEM);
+}
+
+static int flask_audit_p2m(struct domain *d)
+{
+    return domain_has_perm(current->domain, d, SECCLASS_HVM, HVM__AUDIT_P2M);
+}
+
 static int flask_apic(struct domain *d, int cmd)
 {
     u32 perm;
@@ -1492,6 +1536,7 @@ static struct xsm_operations flask_ops = {
     .setdomainmaxmem = flask_setdomainmaxmem,
     .setdomainhandle = flask_setdomainhandle,
     .setdebugging = flask_setdebugging,
+    .debug_op = flask_debug_op,
     .perfcontrol = flask_perfcontrol,
     .debug_keys = flask_debug_keys,
     .getcpuinfo = flask_getcpuinfo,
@@ -1560,6 +1605,9 @@ static struct xsm_operations flask_ops = {
 #ifdef CONFIG_X86
     .shadow_control = flask_shadow_control,
     .getpageframeinfo = flask_getpageframeinfo,
+    .set_cpuid = flask_set_cpuid,
+    .gettscinfo = flask_gettscinfo,
+    .settscinfo = flask_settscinfo,
     .getmemlist = flask_getmemlist,
     .hypercall_init = flask_hypercall_init,
     .hvmcontext = flask_hvmcontext,
@@ -1568,8 +1616,12 @@ static struct xsm_operations flask_ops = {
     .hvm_set_pci_intx_level = flask_hvm_set_pci_intx_level,
     .hvm_set_isa_irq_level = flask_hvm_set_isa_irq_level,
     .hvm_set_pci_link_route = flask_hvm_set_pci_link_route,
-    .mem_event = flask_mem_event,
+    .mem_event_setup = flask_mem_event_setup,
+    .mem_event_control = flask_mem_event_control,
+    .mem_event_op = flask_mem_event_op,
     .mem_sharing = flask_mem_sharing,
+    .mem_sharing_op = flask_mem_sharing_op,
+    .audit_p2m = flask_audit_p2m,
     .apic = flask_apic,
     .xen_settime = flask_xen_settime,
     .memtype = flask_memtype,
diff --git a/xen/xsm/flask/include/av_perm_to_string.h b/xen/xsm/flask/include/av_perm_to_string.h
index 10f8e80..997f098 100644
--- a/xen/xsm/flask/include/av_perm_to_string.h
+++ b/xen/xsm/flask/include/av_perm_to_string.h
@@ -66,6 +66,9 @@
    S_(SECCLASS_DOMAIN2, DOMAIN2__RELABELSELF, "relabelself")
    S_(SECCLASS_DOMAIN2, DOMAIN2__MAKE_PRIV_FOR, "make_priv_for")
    S_(SECCLASS_DOMAIN2, DOMAIN2__SET_AS_TARGET, "set_as_target")
+   S_(SECCLASS_DOMAIN2, DOMAIN2__SET_CPUID, "set_cpuid")
+   S_(SECCLASS_DOMAIN2, DOMAIN2__GETTSC, "gettsc")
+   S_(SECCLASS_DOMAIN2, DOMAIN2__SETTSC, "settsc")
    S_(SECCLASS_HVM, HVM__SETHVMC, "sethvmc")
    S_(SECCLASS_HVM, HVM__GETHVMC, "gethvmc")
    S_(SECCLASS_HVM, HVM__SETPARAM, "setparam")
@@ -79,6 +82,8 @@
    S_(SECCLASS_HVM, HVM__HVMCTL, "hvmctl")
    S_(SECCLASS_HVM, HVM__MEM_EVENT, "mem_event")
    S_(SECCLASS_HVM, HVM__MEM_SHARING, "mem_sharing")
+   S_(SECCLASS_HVM, HVM__SHARE_MEM, "share_mem")
+   S_(SECCLASS_HVM, HVM__AUDIT_P2M, "audit_p2m")
    S_(SECCLASS_EVENT, EVENT__BIND, "bind")
    S_(SECCLASS_EVENT, EVENT__SEND, "send")
    S_(SECCLASS_EVENT, EVENT__STATUS, "status")
diff --git a/xen/xsm/flask/include/av_permissions.h b/xen/xsm/flask/include/av_permissions.h
index f7cfee1..8596a55 100644
--- a/xen/xsm/flask/include/av_permissions.h
+++ b/xen/xsm/flask/include/av_permissions.h
@@ -68,6 +68,9 @@
 #define DOMAIN2__RELABELSELF                      0x00000004UL
 #define DOMAIN2__MAKE_PRIV_FOR                    0x00000008UL
 #define DOMAIN2__SET_AS_TARGET                    0x00000010UL
+#define DOMAIN2__SET_CPUID                        0x00000020UL
+#define DOMAIN2__GETTSC                           0x00000040UL
+#define DOMAIN2__SETTSC                           0x00000080UL
 
 #define HVM__SETHVMC                              0x00000001UL
 #define HVM__GETHVMC                              0x00000002UL
@@ -82,6 +85,8 @@
 #define HVM__HVMCTL                               0x00000400UL
 #define HVM__MEM_EVENT                            0x00000800UL
 #define HVM__MEM_SHARING                          0x00001000UL
+#define HVM__SHARE_MEM                            0x00002000UL
+#define HVM__AUDIT_P2M                            0x00004000UL
 
 #define EVENT__BIND                               0x00000001UL
 #define EVENT__SEND                               0x00000002UL
-- 
1.7.11.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 10 19:49:59 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Sep 2012 19: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 1TB9zR-0001H3-Cz; Mon, 10 Sep 2012 19:49:49 +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 1TB9zO-0001Df-Tp
	for xen-devel@lists.xen.org; Mon, 10 Sep 2012 19:49:47 +0000
Received: from [85.158.143.99:4304] by server-1.bemta-4.messagelabs.com id
	72/15-12504-A544E405; Mon, 10 Sep 2012 19:49:46 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-8.tower-216.messagelabs.com!1347306584!19823871!1
X-Originating-IP: [63.239.67.10]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9643 invoked from network); 10 Sep 2012 19:49:45 -0000
Received: from emvm-gh1-uea09.nsa.gov (HELO nsa.gov) (63.239.67.10)
	by server-8.tower-216.messagelabs.com with SMTP;
	10 Sep 2012 19:49:45 -0000
X-TM-IMSS-Message-ID: <3066df38000f226b@nsa.gov>
Received: from tarius.tycho.ncsc.mil ([144.51.3.1]) by nsa.gov
	([63.239.67.10]) with ESMTP (TREND IMSS SMTP Service 7.1) id
	3066df38000f226b ; Mon, 10 Sep 2012 15:51:55 -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 q8AJna3w027796; 
	Mon, 10 Sep 2012 15:49:43 -0400
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xen.org
Date: Mon, 10 Sep 2012 15:49:13 -0400
Message-Id: <1347306553-20980-21-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.11.4
In-Reply-To: <1347306553-20980-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1347306553-20980-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: [Xen-devel] [PATCH 20/20] flask: add missing operations
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 hvm_inject_msi, machine_address_size, iomem_mapping, and
ioport_mapping security operations did not have FLASK operations
defined; define them now.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 tools/flask/policy/policy/flask/access_vectors |  1 +
 tools/flask/policy/policy/modules/xen/xen.if   |  2 +-
 xen/xsm/flask/hooks.c                          | 42 ++++++++++++++++++++++++--
 xen/xsm/flask/include/av_perm_to_string.h      |  1 +
 xen/xsm/flask/include/av_permissions.h         |  1 +
 5 files changed, 43 insertions(+), 4 deletions(-)

diff --git a/tools/flask/policy/policy/flask/access_vectors b/tools/flask/policy/policy/flask/access_vectors
index 2736075..b394fc1 100644
--- a/tools/flask/policy/policy/flask/access_vectors
+++ b/tools/flask/policy/policy/flask/access_vectors
@@ -103,6 +103,7 @@ class hvm
     mem_sharing
 	share_mem
 	audit_p2m
+	send_irq
 }
 
 class event
diff --git a/tools/flask/policy/policy/modules/xen/xen.if b/tools/flask/policy/policy/modules/xen/xen.if
index 8056f18..67f5daf 100644
--- a/tools/flask/policy/policy/modules/xen/xen.if
+++ b/tools/flask/policy/policy/modules/xen/xen.if
@@ -143,7 +143,7 @@ define(`device_model', `
 
 	allow $1 $2_target:domain shutdown;
 	allow $1 $2_target:mmu { map_read map_write adjust physmap };
-	allow $1 $2_target:hvm { getparam setparam trackdirtyvram hvmctl irqlevel pciroute cacheattr };
+	allow $1 $2_target:hvm { getparam setparam trackdirtyvram hvmctl irqlevel pciroute cacheattr send_irq };
 ')
 
 # make_device_model(priv, dm_dom, hvm_dom)
diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
index 316e8ef..12638c4 100644
--- a/xen/xsm/flask/hooks.c
+++ b/xen/xsm/flask/hooks.c
@@ -814,8 +814,7 @@ static int flask_iomem_permission(struct domain *d, uint64_t start, uint64_t end
     struct iomem_has_perm_data data;
     int rc;
 
-    rc = current_has_perm(d, SECCLASS_RESOURCE,
-                         resource_to_perm(access));
+    rc = current_has_perm(d, SECCLASS_RESOURCE, resource_to_perm(access));
     if ( rc )
         return rc;
 
@@ -830,6 +829,11 @@ static int flask_iomem_permission(struct domain *d, uint64_t start, uint64_t end
     return security_iterate_iomem_sids(start, end, _iomem_has_perm, &data);
 }
 
+static int flask_iomem_mapping(struct domain *d, uint64_t start, uint64_t end, uint8_t access)
+{
+    return flask_iomem_permission(d, start, end, access);
+}
+
 static int flask_pci_config_permission(struct domain *d, uint32_t machine_bdf, uint16_t start, uint16_t end, uint8_t access)
 {
     u32 dsid, rsid;
@@ -1022,7 +1026,6 @@ static int _ioport_has_perm(void *v, u32 sid, unsigned long start, unsigned long
     return avc_has_perm(data->dsid, sid, SECCLASS_RESOURCE, RESOURCE__USE, &ad);
 }
 
-
 static int flask_ioport_permission(struct domain *d, uint32_t start, uint32_t end, uint8_t access)
 {
     int rc;
@@ -1045,6 +1048,11 @@ static int flask_ioport_permission(struct domain *d, uint32_t start, uint32_t en
     return security_iterate_ioport_sids(start, end, _ioport_has_perm, &data);
 }
 
+static int flask_ioport_mapping(struct domain *d, uint32_t start, uint32_t end, uint8_t access)
+{
+    return flask_ioport_permission(d, start, end, access);
+}
+
 static int flask_getpageframeinfo(struct domain *d)
 {
     return current_has_perm(d, SECCLASS_MMU, MMU__PAGEINFO);
@@ -1117,6 +1125,25 @@ static int flask_address_size(struct domain *d, uint32_t cmd)
     return current_has_perm(d, SECCLASS_DOMAIN, perm);
 }
 
+static int flask_machine_address_size(struct domain *d, uint32_t cmd)
+{
+    u32 perm;
+
+    switch ( cmd )
+    {
+    case XEN_DOMCTL_set_machine_address_size:
+        perm = DOMAIN__SETADDRSIZE;
+        break;
+    case XEN_DOMCTL_get_machine_address_size:
+        perm = DOMAIN__GETADDRSIZE;
+        break;
+    default:
+        return -EPERM;
+    }
+
+    return current_has_perm(d, SECCLASS_DOMAIN, perm);
+}
+
 static int flask_hvm_param(struct domain *d, unsigned long op)
 {
     u32 perm;
@@ -1154,6 +1181,11 @@ static int flask_hvm_set_pci_link_route(struct domain *d)
     return current_has_perm(d, SECCLASS_HVM, HVM__PCIROUTE);
 }
 
+static int flask_hvm_inject_msi(struct domain *d)
+{
+    return current_has_perm(d, SECCLASS_HVM, HVM__SEND_IRQ);
+}
+
 static int flask_mem_event_setup(struct domain *d)
 {
     return current_has_perm(d, SECCLASS_HVM, HVM__MEM_EVENT);
@@ -1578,6 +1610,7 @@ static struct xsm_operations flask_ops = {
     .unmap_domain_pirq = flask_unmap_domain_pirq,
     .irq_permission = flask_irq_permission,
     .iomem_permission = flask_iomem_permission,
+    .iomem_mapping = flask_iomem_mapping,
     .pci_config_permission = flask_pci_config_permission,
 
     .resource_plug_core = flask_resource_plug_core,
@@ -1606,10 +1639,12 @@ static struct xsm_operations flask_ops = {
     .hypercall_init = flask_hypercall_init,
     .hvmcontext = flask_hvmcontext,
     .address_size = flask_address_size,
+    .machine_address_size = flask_machine_address_size,
     .hvm_param = flask_hvm_param,
     .hvm_set_pci_intx_level = flask_hvm_set_pci_intx_level,
     .hvm_set_isa_irq_level = flask_hvm_set_isa_irq_level,
     .hvm_set_pci_link_route = flask_hvm_set_pci_link_route,
+    .hvm_inject_msi = flask_hvm_inject_msi,
     .mem_event_setup = flask_mem_event_setup,
     .mem_event_control = flask_mem_event_control,
     .mem_event_op = flask_mem_event_op,
@@ -1646,6 +1681,7 @@ static struct xsm_operations flask_ops = {
     .ext_vcpucontext = flask_ext_vcpucontext,
     .vcpuextstate = flask_vcpuextstate,
     .ioport_permission = flask_ioport_permission,
+    .ioport_mapping = flask_ioport_mapping,
 #endif
 };
 
diff --git a/xen/xsm/flask/include/av_perm_to_string.h b/xen/xsm/flask/include/av_perm_to_string.h
index b2c77b2..1b958fd 100644
--- a/xen/xsm/flask/include/av_perm_to_string.h
+++ b/xen/xsm/flask/include/av_perm_to_string.h
@@ -85,6 +85,7 @@
    S_(SECCLASS_HVM, HVM__MEM_SHARING, "mem_sharing")
    S_(SECCLASS_HVM, HVM__SHARE_MEM, "share_mem")
    S_(SECCLASS_HVM, HVM__AUDIT_P2M, "audit_p2m")
+   S_(SECCLASS_HVM, HVM__SEND_IRQ, "send_irq")
    S_(SECCLASS_EVENT, EVENT__BIND, "bind")
    S_(SECCLASS_EVENT, EVENT__SEND, "send")
    S_(SECCLASS_EVENT, EVENT__STATUS, "status")
diff --git a/xen/xsm/flask/include/av_permissions.h b/xen/xsm/flask/include/av_permissions.h
index acb0b1a..15a7eee 100644
--- a/xen/xsm/flask/include/av_permissions.h
+++ b/xen/xsm/flask/include/av_permissions.h
@@ -88,6 +88,7 @@
 #define HVM__MEM_SHARING                          0x00001000UL
 #define HVM__SHARE_MEM                            0x00002000UL
 #define HVM__AUDIT_P2M                            0x00004000UL
+#define HVM__SEND_IRQ                             0x00008000UL
 
 #define EVENT__BIND                               0x00000001UL
 #define EVENT__SEND                               0x00000002UL
-- 
1.7.11.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 10 19:49:59 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Sep 2012 19: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 1TB9zR-0001H3-Cz; Mon, 10 Sep 2012 19:49:49 +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 1TB9zO-0001Df-Tp
	for xen-devel@lists.xen.org; Mon, 10 Sep 2012 19:49:47 +0000
Received: from [85.158.143.99:4304] by server-1.bemta-4.messagelabs.com id
	72/15-12504-A544E405; Mon, 10 Sep 2012 19:49:46 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-8.tower-216.messagelabs.com!1347306584!19823871!1
X-Originating-IP: [63.239.67.10]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9643 invoked from network); 10 Sep 2012 19:49:45 -0000
Received: from emvm-gh1-uea09.nsa.gov (HELO nsa.gov) (63.239.67.10)
	by server-8.tower-216.messagelabs.com with SMTP;
	10 Sep 2012 19:49:45 -0000
X-TM-IMSS-Message-ID: <3066df38000f226b@nsa.gov>
Received: from tarius.tycho.ncsc.mil ([144.51.3.1]) by nsa.gov
	([63.239.67.10]) with ESMTP (TREND IMSS SMTP Service 7.1) id
	3066df38000f226b ; Mon, 10 Sep 2012 15:51:55 -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 q8AJna3w027796; 
	Mon, 10 Sep 2012 15:49:43 -0400
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xen.org
Date: Mon, 10 Sep 2012 15:49:13 -0400
Message-Id: <1347306553-20980-21-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.11.4
In-Reply-To: <1347306553-20980-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1347306553-20980-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: [Xen-devel] [PATCH 20/20] flask: add missing operations
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 hvm_inject_msi, machine_address_size, iomem_mapping, and
ioport_mapping security operations did not have FLASK operations
defined; define them now.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 tools/flask/policy/policy/flask/access_vectors |  1 +
 tools/flask/policy/policy/modules/xen/xen.if   |  2 +-
 xen/xsm/flask/hooks.c                          | 42 ++++++++++++++++++++++++--
 xen/xsm/flask/include/av_perm_to_string.h      |  1 +
 xen/xsm/flask/include/av_permissions.h         |  1 +
 5 files changed, 43 insertions(+), 4 deletions(-)

diff --git a/tools/flask/policy/policy/flask/access_vectors b/tools/flask/policy/policy/flask/access_vectors
index 2736075..b394fc1 100644
--- a/tools/flask/policy/policy/flask/access_vectors
+++ b/tools/flask/policy/policy/flask/access_vectors
@@ -103,6 +103,7 @@ class hvm
     mem_sharing
 	share_mem
 	audit_p2m
+	send_irq
 }
 
 class event
diff --git a/tools/flask/policy/policy/modules/xen/xen.if b/tools/flask/policy/policy/modules/xen/xen.if
index 8056f18..67f5daf 100644
--- a/tools/flask/policy/policy/modules/xen/xen.if
+++ b/tools/flask/policy/policy/modules/xen/xen.if
@@ -143,7 +143,7 @@ define(`device_model', `
 
 	allow $1 $2_target:domain shutdown;
 	allow $1 $2_target:mmu { map_read map_write adjust physmap };
-	allow $1 $2_target:hvm { getparam setparam trackdirtyvram hvmctl irqlevel pciroute cacheattr };
+	allow $1 $2_target:hvm { getparam setparam trackdirtyvram hvmctl irqlevel pciroute cacheattr send_irq };
 ')
 
 # make_device_model(priv, dm_dom, hvm_dom)
diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
index 316e8ef..12638c4 100644
--- a/xen/xsm/flask/hooks.c
+++ b/xen/xsm/flask/hooks.c
@@ -814,8 +814,7 @@ static int flask_iomem_permission(struct domain *d, uint64_t start, uint64_t end
     struct iomem_has_perm_data data;
     int rc;
 
-    rc = current_has_perm(d, SECCLASS_RESOURCE,
-                         resource_to_perm(access));
+    rc = current_has_perm(d, SECCLASS_RESOURCE, resource_to_perm(access));
     if ( rc )
         return rc;
 
@@ -830,6 +829,11 @@ static int flask_iomem_permission(struct domain *d, uint64_t start, uint64_t end
     return security_iterate_iomem_sids(start, end, _iomem_has_perm, &data);
 }
 
+static int flask_iomem_mapping(struct domain *d, uint64_t start, uint64_t end, uint8_t access)
+{
+    return flask_iomem_permission(d, start, end, access);
+}
+
 static int flask_pci_config_permission(struct domain *d, uint32_t machine_bdf, uint16_t start, uint16_t end, uint8_t access)
 {
     u32 dsid, rsid;
@@ -1022,7 +1026,6 @@ static int _ioport_has_perm(void *v, u32 sid, unsigned long start, unsigned long
     return avc_has_perm(data->dsid, sid, SECCLASS_RESOURCE, RESOURCE__USE, &ad);
 }
 
-
 static int flask_ioport_permission(struct domain *d, uint32_t start, uint32_t end, uint8_t access)
 {
     int rc;
@@ -1045,6 +1048,11 @@ static int flask_ioport_permission(struct domain *d, uint32_t start, uint32_t en
     return security_iterate_ioport_sids(start, end, _ioport_has_perm, &data);
 }
 
+static int flask_ioport_mapping(struct domain *d, uint32_t start, uint32_t end, uint8_t access)
+{
+    return flask_ioport_permission(d, start, end, access);
+}
+
 static int flask_getpageframeinfo(struct domain *d)
 {
     return current_has_perm(d, SECCLASS_MMU, MMU__PAGEINFO);
@@ -1117,6 +1125,25 @@ static int flask_address_size(struct domain *d, uint32_t cmd)
     return current_has_perm(d, SECCLASS_DOMAIN, perm);
 }
 
+static int flask_machine_address_size(struct domain *d, uint32_t cmd)
+{
+    u32 perm;
+
+    switch ( cmd )
+    {
+    case XEN_DOMCTL_set_machine_address_size:
+        perm = DOMAIN__SETADDRSIZE;
+        break;
+    case XEN_DOMCTL_get_machine_address_size:
+        perm = DOMAIN__GETADDRSIZE;
+        break;
+    default:
+        return -EPERM;
+    }
+
+    return current_has_perm(d, SECCLASS_DOMAIN, perm);
+}
+
 static int flask_hvm_param(struct domain *d, unsigned long op)
 {
     u32 perm;
@@ -1154,6 +1181,11 @@ static int flask_hvm_set_pci_link_route(struct domain *d)
     return current_has_perm(d, SECCLASS_HVM, HVM__PCIROUTE);
 }
 
+static int flask_hvm_inject_msi(struct domain *d)
+{
+    return current_has_perm(d, SECCLASS_HVM, HVM__SEND_IRQ);
+}
+
 static int flask_mem_event_setup(struct domain *d)
 {
     return current_has_perm(d, SECCLASS_HVM, HVM__MEM_EVENT);
@@ -1578,6 +1610,7 @@ static struct xsm_operations flask_ops = {
     .unmap_domain_pirq = flask_unmap_domain_pirq,
     .irq_permission = flask_irq_permission,
     .iomem_permission = flask_iomem_permission,
+    .iomem_mapping = flask_iomem_mapping,
     .pci_config_permission = flask_pci_config_permission,
 
     .resource_plug_core = flask_resource_plug_core,
@@ -1606,10 +1639,12 @@ static struct xsm_operations flask_ops = {
     .hypercall_init = flask_hypercall_init,
     .hvmcontext = flask_hvmcontext,
     .address_size = flask_address_size,
+    .machine_address_size = flask_machine_address_size,
     .hvm_param = flask_hvm_param,
     .hvm_set_pci_intx_level = flask_hvm_set_pci_intx_level,
     .hvm_set_isa_irq_level = flask_hvm_set_isa_irq_level,
     .hvm_set_pci_link_route = flask_hvm_set_pci_link_route,
+    .hvm_inject_msi = flask_hvm_inject_msi,
     .mem_event_setup = flask_mem_event_setup,
     .mem_event_control = flask_mem_event_control,
     .mem_event_op = flask_mem_event_op,
@@ -1646,6 +1681,7 @@ static struct xsm_operations flask_ops = {
     .ext_vcpucontext = flask_ext_vcpucontext,
     .vcpuextstate = flask_vcpuextstate,
     .ioport_permission = flask_ioport_permission,
+    .ioport_mapping = flask_ioport_mapping,
 #endif
 };
 
diff --git a/xen/xsm/flask/include/av_perm_to_string.h b/xen/xsm/flask/include/av_perm_to_string.h
index b2c77b2..1b958fd 100644
--- a/xen/xsm/flask/include/av_perm_to_string.h
+++ b/xen/xsm/flask/include/av_perm_to_string.h
@@ -85,6 +85,7 @@
    S_(SECCLASS_HVM, HVM__MEM_SHARING, "mem_sharing")
    S_(SECCLASS_HVM, HVM__SHARE_MEM, "share_mem")
    S_(SECCLASS_HVM, HVM__AUDIT_P2M, "audit_p2m")
+   S_(SECCLASS_HVM, HVM__SEND_IRQ, "send_irq")
    S_(SECCLASS_EVENT, EVENT__BIND, "bind")
    S_(SECCLASS_EVENT, EVENT__SEND, "send")
    S_(SECCLASS_EVENT, EVENT__STATUS, "status")
diff --git a/xen/xsm/flask/include/av_permissions.h b/xen/xsm/flask/include/av_permissions.h
index acb0b1a..15a7eee 100644
--- a/xen/xsm/flask/include/av_permissions.h
+++ b/xen/xsm/flask/include/av_permissions.h
@@ -88,6 +88,7 @@
 #define HVM__MEM_SHARING                          0x00001000UL
 #define HVM__SHARE_MEM                            0x00002000UL
 #define HVM__AUDIT_P2M                            0x00004000UL
+#define HVM__SEND_IRQ                             0x00008000UL
 
 #define EVENT__BIND                               0x00000001UL
 #define EVENT__SEND                               0x00000002UL
-- 
1.7.11.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 10 19:50:00 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Sep 2012 19:50:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TB9zN-0001Cv-TO; Mon, 10 Sep 2012 19:49:45 +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 1TB9zL-0001A4-87
	for xen-devel@lists.xen.org; Mon, 10 Sep 2012 19:49:43 +0000
Received: from [85.158.143.99:27963] by server-2.bemta-4.messagelabs.com id
	C3/54-21239-6544E405; Mon, 10 Sep 2012 19:49:42 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-7.tower-216.messagelabs.com!1347306581!26220880!1
X-Originating-IP: [63.239.67.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26739 invoked from network); 10 Sep 2012 19:49:41 -0000
Received: from emvm-gh1-uea09.nsa.gov (HELO nsa.gov) (63.239.67.10)
	by server-7.tower-216.messagelabs.com with SMTP;
	10 Sep 2012 19:49:41 -0000
X-TM-IMSS-Message-ID: <3066cf51000f225e@nsa.gov>
Received: from tarius.tycho.ncsc.mil ([144.51.3.1]) by nsa.gov
	([63.239.67.10]) with ESMTP (TREND IMSS SMTP Service 7.1) id
	3066cf51000f225e ; Mon, 10 Sep 2012 15:51: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 q8AJna3j027796; 
	Mon, 10 Sep 2012 15:49:38 -0400
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xen.org
Date: Mon, 10 Sep 2012 15:49:00 -0400
Message-Id: <1347306553-20980-8-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.11.4
In-Reply-To: <1347306553-20980-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1347306553-20980-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>, Keir Fraser <keir@xen.org>,
	Jan Beulich <jbeulich@suse.com>
Subject: [Xen-devel] [PATCH 07/20] arch/x86: add distinct XSM hooks for
	map/unmap
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 xsm_iomem_permission and xsm_ioport_permission hooks are intended to
be called by the domain builder, while the calls in arch/x86/domctl.c
which control mapping are also performed by the device model. Because of
this, they should not use the same XSM hooks.

This also adds a missing XSM hook in the unbind IRQ domctl.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Cc: Keir Fraser <keir@xen.org>
Cc: Jan Beulich <jbeulich@suse.com>
---
 xen/arch/x86/domctl.c  |  8 ++++++--
 xen/arch/x86/physdev.c |  2 +-
 xen/include/xsm/xsm.h  | 25 ++++++++++++++++++++++---
 xen/xsm/dummy.c        | 20 +++++++++++++++++++-
 xen/xsm/flask/hooks.c  | 42 ++++++++++++++++++++----------------------
 5 files changed, 68 insertions(+), 29 deletions(-)

diff --git a/xen/arch/x86/domctl.c b/xen/arch/x86/domctl.c
index 97a13fb..3ccf712 100644
--- a/xen/arch/x86/domctl.c
+++ b/xen/arch/x86/domctl.c
@@ -807,6 +807,10 @@ long arch_do_domctl(
              !irq_access_permitted(current->domain, bind->machine_irq) )
             goto unbind_out;
 
+        ret = xsm_unbind_pt_irq(d, bind);
+        if ( ret )
+            goto unbind_out;
+
         if ( iommu_enabled )
         {
             spin_lock(&pcidevs_lock);
@@ -844,7 +848,7 @@ long arch_do_domctl(
         if ( unlikely((d = rcu_lock_domain_by_id(domctl->domain)) == NULL) )
             break;
 
-        ret = xsm_iomem_permission(d, mfn, mfn + nr_mfns - 1, add);
+        ret = xsm_iomem_mapping(d, mfn, mfn + nr_mfns - 1, add);
         if ( ret ) {
             rcu_unlock_domain(d);
             break;
@@ -906,7 +910,7 @@ long arch_do_domctl(
         if ( unlikely((d = rcu_lock_domain_by_id(domctl->domain)) == NULL) )
             break;
 
-        ret = xsm_ioport_permission(d, fmp, fmp + np - 1, add);
+        ret = xsm_ioport_mapping(d, fmp, fmp + np - 1, add);
         if ( ret ) {
             rcu_unlock_domain(d);
             break;
diff --git a/xen/arch/x86/physdev.c b/xen/arch/x86/physdev.c
index ce55ee1..bf133fa 100644
--- a/xen/arch/x86/physdev.c
+++ b/xen/arch/x86/physdev.c
@@ -243,7 +243,7 @@ int physdev_unmap_pirq(domid_t domid, int pirq)
     if ( !IS_PRIV_FOR(current->domain, d) )
         goto free_domain;
 
-    ret = xsm_irq_permission(d, domain_pirq_to_irq(d, pirq), 0);
+    ret = xsm_unmap_domain_pirq(d, domain_pirq_to_irq(d, pirq));
     if ( ret )
         goto free_domain;
 
diff --git a/xen/include/xsm/xsm.h b/xen/include/xsm/xsm.h
index 593cdbd..cbbe673 100644
--- a/xen/include/xsm/xsm.h
+++ b/xen/include/xsm/xsm.h
@@ -117,8 +117,10 @@ struct xsm_operations {
 
     char *(*show_irq_sid) (int irq);
     int (*map_domain_pirq) (struct domain *d, int irq, void *data);
+    int (*unmap_domain_pirq) (struct domain *d, int irq);
     int (*irq_permission) (struct domain *d, int pirq, uint8_t allow);
     int (*iomem_permission) (struct domain *d, uint64_t s, uint64_t e, uint8_t allow);
+    int (*iomem_mapping) (struct domain *d, uint64_t s, uint64_t e, uint8_t allow);
     int (*pci_config_permission) (struct domain *d, uint32_t machine_bdf, uint16_t start, uint16_t end, uint8_t access);
 
     int (*get_device_group) (uint32_t machine_bdf);
@@ -176,11 +178,12 @@ struct xsm_operations {
     int (*add_to_physmap) (struct domain *d1, struct domain *d2);
     int (*sendtrigger) (struct domain *d);
     int (*bind_pt_irq) (struct domain *d, struct xen_domctl_bind_pt_irq *bind);
-    int (*unbind_pt_irq) (struct domain *d);
+    int (*unbind_pt_irq) (struct domain *d, struct xen_domctl_bind_pt_irq *bind);
     int (*pin_mem_cacheattr) (struct domain *d);
     int (*ext_vcpucontext) (struct domain *d, uint32_t cmd);
     int (*vcpuextstate) (struct domain *d, uint32_t cmd);
     int (*ioport_permission) (struct domain *d, uint32_t s, uint32_t e, uint8_t allow);
+    int (*ioport_mapping) (struct domain *d, uint32_t s, uint32_t e, uint8_t allow);
 #endif
 };
 
@@ -495,6 +498,11 @@ static inline int xsm_map_domain_pirq (struct domain *d, int irq, void *data)
     return xsm_call(map_domain_pirq(d, irq, data));
 }
 
+static inline int xsm_unmap_domain_pirq (struct domain *d, int irq)
+{
+    return xsm_call(unmap_domain_pirq(d, irq));
+}
+
 static inline int xsm_irq_permission (struct domain *d, int pirq, uint8_t allow)
 {
     return xsm_call(irq_permission(d, pirq, allow));
@@ -505,6 +513,11 @@ static inline int xsm_iomem_permission (struct domain *d, uint64_t s, uint64_t e
     return xsm_call(iomem_permission(d, s, e, allow));
 }
 
+static inline int xsm_iomem_mapping (struct domain *d, uint64_t s, uint64_t e, uint8_t allow)
+{
+    return xsm_call(iomem_mapping(d, s, e, allow));
+}
+
 static inline int xsm_pci_config_permission (struct domain *d, uint32_t machine_bdf, uint16_t start, uint16_t end, uint8_t access)
 {
     return xsm_call(pci_config_permission(d, machine_bdf, start, end, access));
@@ -781,9 +794,10 @@ static inline int xsm_bind_pt_irq(struct domain *d,
     return xsm_call(bind_pt_irq(d, bind));
 }
 
-static inline int xsm_unbind_pt_irq(struct domain *d)
+static inline int xsm_unbind_pt_irq(struct domain *d,
+                                                struct xen_domctl_bind_pt_irq *bind)
 {
-    return xsm_call(unbind_pt_irq(d));
+    return xsm_call(unbind_pt_irq(d, bind));
 }
 
 static inline int xsm_pin_mem_cacheattr(struct domain *d)
@@ -804,6 +818,11 @@ static inline int xsm_ioport_permission (struct domain *d, uint32_t s, uint32_t
 {
     return xsm_call(ioport_permission(d, s, e, allow));
 }
+
+static inline int xsm_ioport_mapping (struct domain *d, uint32_t s, uint32_t e, uint8_t allow)
+{
+    return xsm_call(ioport_mapping(d, s, e, allow));
+}
 #endif /* CONFIG_X86 */
 
 extern struct xsm_operations dummy_xsm_ops;
diff --git a/xen/xsm/dummy.c b/xen/xsm/dummy.c
index 4836fc0..a5dbfe7 100644
--- a/xen/xsm/dummy.c
+++ b/xen/xsm/dummy.c
@@ -395,6 +395,11 @@ static int dummy_map_domain_pirq (struct domain *d, int irq, void *data)
     return 0;
 }
 
+static int dummy_unmap_domain_pirq (struct domain *d, int irq)
+{
+    return 0;
+}
+
 static int dummy_irq_permission (struct domain *d, int pirq, uint8_t allow)
 {
     return 0;
@@ -405,6 +410,11 @@ static int dummy_iomem_permission (struct domain *d, uint64_t s, uint64_t e, uin
     return 0;
 }
 
+static int dummy_iomem_mapping (struct domain *d, uint64_t s, uint64_t e, uint8_t allow)
+{
+    return 0;
+}
+
 static int dummy_pci_config_permission (struct domain *d, uint32_t machine_bdf,
                                         uint16_t start, uint16_t end,
                                         uint8_t access)
@@ -585,7 +595,7 @@ static int dummy_bind_pt_irq (struct domain *d, struct xen_domctl_bind_pt_irq *b
     return 0;
 }
 
-static int dummy_unbind_pt_irq (struct domain *d)
+static int dummy_unbind_pt_irq (struct domain *d, struct xen_domctl_bind_pt_irq *bind)
 {
     return 0;
 }
@@ -609,6 +619,11 @@ static int dummy_ioport_permission (struct domain *d, uint32_t s, uint32_t e, ui
 {
     return 0;
 }
+
+static int dummy_ioport_mapping (struct domain *d, uint32_t s, uint32_t e, uint8_t allow)
+{
+    return 0;
+}
 #endif
 
 struct xsm_operations dummy_xsm_ops;
@@ -693,8 +708,10 @@ void xsm_fixup_ops (struct xsm_operations *ops)
 
     set_to_dummy_if_null(ops, show_irq_sid);
     set_to_dummy_if_null(ops, map_domain_pirq);
+    set_to_dummy_if_null(ops, unmap_domain_pirq);
     set_to_dummy_if_null(ops, irq_permission);
     set_to_dummy_if_null(ops, iomem_permission);
+    set_to_dummy_if_null(ops, iomem_mapping);
     set_to_dummy_if_null(ops, pci_config_permission);
 
     set_to_dummy_if_null(ops, get_device_group);
@@ -757,5 +774,6 @@ void xsm_fixup_ops (struct xsm_operations *ops)
     set_to_dummy_if_null(ops, ext_vcpucontext);
     set_to_dummy_if_null(ops, vcpuextstate);
     set_to_dummy_if_null(ops, ioport_permission);
+    set_to_dummy_if_null(ops, ioport_mapping);
 #endif
 }
diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
index 88fef9c..74c9271 100644
--- a/xen/xsm/flask/hooks.c
+++ b/xen/xsm/flask/hooks.c
@@ -721,43 +721,40 @@ static int flask_map_domain_pirq (struct domain *d, int irq, void *data)
     return rc;
 }
 
-static int flask_irq_permission (struct domain *d, int irq, uint8_t access)
+static int flask_unmap_domain_pirq (struct domain *d, int irq)
 {
-    u32 perm;
-    u32 rsid;
+    u32 sid;
     int rc = -EPERM;
 
-    struct domain_security_struct *ssec, *tsec;
+    struct domain_security_struct *ssec;
     struct avc_audit_data ad;
 
-    rc = domain_has_perm(current->domain, d, SECCLASS_RESOURCE,
-                         resource_to_perm(access));
-
+    rc = domain_has_perm(current->domain, d, SECCLASS_RESOURCE, RESOURCE__REMOVE);
     if ( rc )
         return rc;
 
-    if ( access )
-        perm = RESOURCE__ADD_IRQ;
-    else
-        perm = RESOURCE__REMOVE_IRQ;
-
     ssec = current->domain->ssid;
-    tsec = d->ssid;
 
-    rc = get_irq_sid(irq, &rsid, &ad);
-    if ( rc )
-        return rc;
-
-    rc = avc_has_perm(ssec->sid, rsid, SECCLASS_RESOURCE, perm, &ad);
+    if ( irq >= nr_irqs_gsi ) {
+        /* TODO support for MSI here */
+        return 0;
+    } else {
+        rc = get_irq_sid(irq, &sid, &ad);
+    }
     if ( rc )
         return rc;
 
-    if ( access )
-        rc = avc_has_perm(tsec->sid, rsid, SECCLASS_RESOURCE, 
-                            RESOURCE__USE, &ad);
+    rc = avc_has_perm(ssec->sid, sid, SECCLASS_RESOURCE, RESOURCE__REMOVE_IRQ, &ad);
     return rc;
 }
 
+static int flask_irq_permission (struct domain *d, int pirq, uint8_t access)
+{
+    /* the PIRQ number is not useful; real IRQ is checked during mapping */
+    return domain_has_perm(current->domain, d, SECCLASS_RESOURCE,
+                           resource_to_perm(access));
+}
+
 struct iomem_has_perm_data {
     struct domain_security_struct *ssec, *tsec;
     u32 perm;
@@ -1413,7 +1410,7 @@ static int flask_bind_pt_irq (struct domain *d, struct xen_domctl_bind_pt_irq *b
     return avc_has_perm(tsec->sid, rsid, SECCLASS_RESOURCE, RESOURCE__USE, &ad);
 }
 
-static int flask_unbind_pt_irq (struct domain *d)
+static int flask_unbind_pt_irq (struct domain *d, struct xen_domctl_bind_pt_irq *bind)
 {
     return domain_has_perm(current->domain, d, SECCLASS_RESOURCE, RESOURCE__REMOVE);
 }
@@ -1533,6 +1530,7 @@ static struct xsm_operations flask_ops = {
     .show_irq_sid = flask_show_irq_sid,
 
     .map_domain_pirq = flask_map_domain_pirq,
+    .unmap_domain_pirq = flask_unmap_domain_pirq,
     .irq_permission = flask_irq_permission,
     .iomem_permission = flask_iomem_permission,
     .pci_config_permission = flask_pci_config_permission,
-- 
1.7.11.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 10 19:50:00 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Sep 2012 19:50:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TB9zN-0001Cv-TO; Mon, 10 Sep 2012 19:49:45 +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 1TB9zL-0001A4-87
	for xen-devel@lists.xen.org; Mon, 10 Sep 2012 19:49:43 +0000
Received: from [85.158.143.99:27963] by server-2.bemta-4.messagelabs.com id
	C3/54-21239-6544E405; Mon, 10 Sep 2012 19:49:42 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-7.tower-216.messagelabs.com!1347306581!26220880!1
X-Originating-IP: [63.239.67.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26739 invoked from network); 10 Sep 2012 19:49:41 -0000
Received: from emvm-gh1-uea09.nsa.gov (HELO nsa.gov) (63.239.67.10)
	by server-7.tower-216.messagelabs.com with SMTP;
	10 Sep 2012 19:49:41 -0000
X-TM-IMSS-Message-ID: <3066cf51000f225e@nsa.gov>
Received: from tarius.tycho.ncsc.mil ([144.51.3.1]) by nsa.gov
	([63.239.67.10]) with ESMTP (TREND IMSS SMTP Service 7.1) id
	3066cf51000f225e ; Mon, 10 Sep 2012 15:51: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 q8AJna3j027796; 
	Mon, 10 Sep 2012 15:49:38 -0400
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xen.org
Date: Mon, 10 Sep 2012 15:49:00 -0400
Message-Id: <1347306553-20980-8-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.11.4
In-Reply-To: <1347306553-20980-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1347306553-20980-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>, Keir Fraser <keir@xen.org>,
	Jan Beulich <jbeulich@suse.com>
Subject: [Xen-devel] [PATCH 07/20] arch/x86: add distinct XSM hooks for
	map/unmap
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 xsm_iomem_permission and xsm_ioport_permission hooks are intended to
be called by the domain builder, while the calls in arch/x86/domctl.c
which control mapping are also performed by the device model. Because of
this, they should not use the same XSM hooks.

This also adds a missing XSM hook in the unbind IRQ domctl.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Cc: Keir Fraser <keir@xen.org>
Cc: Jan Beulich <jbeulich@suse.com>
---
 xen/arch/x86/domctl.c  |  8 ++++++--
 xen/arch/x86/physdev.c |  2 +-
 xen/include/xsm/xsm.h  | 25 ++++++++++++++++++++++---
 xen/xsm/dummy.c        | 20 +++++++++++++++++++-
 xen/xsm/flask/hooks.c  | 42 ++++++++++++++++++++----------------------
 5 files changed, 68 insertions(+), 29 deletions(-)

diff --git a/xen/arch/x86/domctl.c b/xen/arch/x86/domctl.c
index 97a13fb..3ccf712 100644
--- a/xen/arch/x86/domctl.c
+++ b/xen/arch/x86/domctl.c
@@ -807,6 +807,10 @@ long arch_do_domctl(
              !irq_access_permitted(current->domain, bind->machine_irq) )
             goto unbind_out;
 
+        ret = xsm_unbind_pt_irq(d, bind);
+        if ( ret )
+            goto unbind_out;
+
         if ( iommu_enabled )
         {
             spin_lock(&pcidevs_lock);
@@ -844,7 +848,7 @@ long arch_do_domctl(
         if ( unlikely((d = rcu_lock_domain_by_id(domctl->domain)) == NULL) )
             break;
 
-        ret = xsm_iomem_permission(d, mfn, mfn + nr_mfns - 1, add);
+        ret = xsm_iomem_mapping(d, mfn, mfn + nr_mfns - 1, add);
         if ( ret ) {
             rcu_unlock_domain(d);
             break;
@@ -906,7 +910,7 @@ long arch_do_domctl(
         if ( unlikely((d = rcu_lock_domain_by_id(domctl->domain)) == NULL) )
             break;
 
-        ret = xsm_ioport_permission(d, fmp, fmp + np - 1, add);
+        ret = xsm_ioport_mapping(d, fmp, fmp + np - 1, add);
         if ( ret ) {
             rcu_unlock_domain(d);
             break;
diff --git a/xen/arch/x86/physdev.c b/xen/arch/x86/physdev.c
index ce55ee1..bf133fa 100644
--- a/xen/arch/x86/physdev.c
+++ b/xen/arch/x86/physdev.c
@@ -243,7 +243,7 @@ int physdev_unmap_pirq(domid_t domid, int pirq)
     if ( !IS_PRIV_FOR(current->domain, d) )
         goto free_domain;
 
-    ret = xsm_irq_permission(d, domain_pirq_to_irq(d, pirq), 0);
+    ret = xsm_unmap_domain_pirq(d, domain_pirq_to_irq(d, pirq));
     if ( ret )
         goto free_domain;
 
diff --git a/xen/include/xsm/xsm.h b/xen/include/xsm/xsm.h
index 593cdbd..cbbe673 100644
--- a/xen/include/xsm/xsm.h
+++ b/xen/include/xsm/xsm.h
@@ -117,8 +117,10 @@ struct xsm_operations {
 
     char *(*show_irq_sid) (int irq);
     int (*map_domain_pirq) (struct domain *d, int irq, void *data);
+    int (*unmap_domain_pirq) (struct domain *d, int irq);
     int (*irq_permission) (struct domain *d, int pirq, uint8_t allow);
     int (*iomem_permission) (struct domain *d, uint64_t s, uint64_t e, uint8_t allow);
+    int (*iomem_mapping) (struct domain *d, uint64_t s, uint64_t e, uint8_t allow);
     int (*pci_config_permission) (struct domain *d, uint32_t machine_bdf, uint16_t start, uint16_t end, uint8_t access);
 
     int (*get_device_group) (uint32_t machine_bdf);
@@ -176,11 +178,12 @@ struct xsm_operations {
     int (*add_to_physmap) (struct domain *d1, struct domain *d2);
     int (*sendtrigger) (struct domain *d);
     int (*bind_pt_irq) (struct domain *d, struct xen_domctl_bind_pt_irq *bind);
-    int (*unbind_pt_irq) (struct domain *d);
+    int (*unbind_pt_irq) (struct domain *d, struct xen_domctl_bind_pt_irq *bind);
     int (*pin_mem_cacheattr) (struct domain *d);
     int (*ext_vcpucontext) (struct domain *d, uint32_t cmd);
     int (*vcpuextstate) (struct domain *d, uint32_t cmd);
     int (*ioport_permission) (struct domain *d, uint32_t s, uint32_t e, uint8_t allow);
+    int (*ioport_mapping) (struct domain *d, uint32_t s, uint32_t e, uint8_t allow);
 #endif
 };
 
@@ -495,6 +498,11 @@ static inline int xsm_map_domain_pirq (struct domain *d, int irq, void *data)
     return xsm_call(map_domain_pirq(d, irq, data));
 }
 
+static inline int xsm_unmap_domain_pirq (struct domain *d, int irq)
+{
+    return xsm_call(unmap_domain_pirq(d, irq));
+}
+
 static inline int xsm_irq_permission (struct domain *d, int pirq, uint8_t allow)
 {
     return xsm_call(irq_permission(d, pirq, allow));
@@ -505,6 +513,11 @@ static inline int xsm_iomem_permission (struct domain *d, uint64_t s, uint64_t e
     return xsm_call(iomem_permission(d, s, e, allow));
 }
 
+static inline int xsm_iomem_mapping (struct domain *d, uint64_t s, uint64_t e, uint8_t allow)
+{
+    return xsm_call(iomem_mapping(d, s, e, allow));
+}
+
 static inline int xsm_pci_config_permission (struct domain *d, uint32_t machine_bdf, uint16_t start, uint16_t end, uint8_t access)
 {
     return xsm_call(pci_config_permission(d, machine_bdf, start, end, access));
@@ -781,9 +794,10 @@ static inline int xsm_bind_pt_irq(struct domain *d,
     return xsm_call(bind_pt_irq(d, bind));
 }
 
-static inline int xsm_unbind_pt_irq(struct domain *d)
+static inline int xsm_unbind_pt_irq(struct domain *d,
+                                                struct xen_domctl_bind_pt_irq *bind)
 {
-    return xsm_call(unbind_pt_irq(d));
+    return xsm_call(unbind_pt_irq(d, bind));
 }
 
 static inline int xsm_pin_mem_cacheattr(struct domain *d)
@@ -804,6 +818,11 @@ static inline int xsm_ioport_permission (struct domain *d, uint32_t s, uint32_t
 {
     return xsm_call(ioport_permission(d, s, e, allow));
 }
+
+static inline int xsm_ioport_mapping (struct domain *d, uint32_t s, uint32_t e, uint8_t allow)
+{
+    return xsm_call(ioport_mapping(d, s, e, allow));
+}
 #endif /* CONFIG_X86 */
 
 extern struct xsm_operations dummy_xsm_ops;
diff --git a/xen/xsm/dummy.c b/xen/xsm/dummy.c
index 4836fc0..a5dbfe7 100644
--- a/xen/xsm/dummy.c
+++ b/xen/xsm/dummy.c
@@ -395,6 +395,11 @@ static int dummy_map_domain_pirq (struct domain *d, int irq, void *data)
     return 0;
 }
 
+static int dummy_unmap_domain_pirq (struct domain *d, int irq)
+{
+    return 0;
+}
+
 static int dummy_irq_permission (struct domain *d, int pirq, uint8_t allow)
 {
     return 0;
@@ -405,6 +410,11 @@ static int dummy_iomem_permission (struct domain *d, uint64_t s, uint64_t e, uin
     return 0;
 }
 
+static int dummy_iomem_mapping (struct domain *d, uint64_t s, uint64_t e, uint8_t allow)
+{
+    return 0;
+}
+
 static int dummy_pci_config_permission (struct domain *d, uint32_t machine_bdf,
                                         uint16_t start, uint16_t end,
                                         uint8_t access)
@@ -585,7 +595,7 @@ static int dummy_bind_pt_irq (struct domain *d, struct xen_domctl_bind_pt_irq *b
     return 0;
 }
 
-static int dummy_unbind_pt_irq (struct domain *d)
+static int dummy_unbind_pt_irq (struct domain *d, struct xen_domctl_bind_pt_irq *bind)
 {
     return 0;
 }
@@ -609,6 +619,11 @@ static int dummy_ioport_permission (struct domain *d, uint32_t s, uint32_t e, ui
 {
     return 0;
 }
+
+static int dummy_ioport_mapping (struct domain *d, uint32_t s, uint32_t e, uint8_t allow)
+{
+    return 0;
+}
 #endif
 
 struct xsm_operations dummy_xsm_ops;
@@ -693,8 +708,10 @@ void xsm_fixup_ops (struct xsm_operations *ops)
 
     set_to_dummy_if_null(ops, show_irq_sid);
     set_to_dummy_if_null(ops, map_domain_pirq);
+    set_to_dummy_if_null(ops, unmap_domain_pirq);
     set_to_dummy_if_null(ops, irq_permission);
     set_to_dummy_if_null(ops, iomem_permission);
+    set_to_dummy_if_null(ops, iomem_mapping);
     set_to_dummy_if_null(ops, pci_config_permission);
 
     set_to_dummy_if_null(ops, get_device_group);
@@ -757,5 +774,6 @@ void xsm_fixup_ops (struct xsm_operations *ops)
     set_to_dummy_if_null(ops, ext_vcpucontext);
     set_to_dummy_if_null(ops, vcpuextstate);
     set_to_dummy_if_null(ops, ioport_permission);
+    set_to_dummy_if_null(ops, ioport_mapping);
 #endif
 }
diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
index 88fef9c..74c9271 100644
--- a/xen/xsm/flask/hooks.c
+++ b/xen/xsm/flask/hooks.c
@@ -721,43 +721,40 @@ static int flask_map_domain_pirq (struct domain *d, int irq, void *data)
     return rc;
 }
 
-static int flask_irq_permission (struct domain *d, int irq, uint8_t access)
+static int flask_unmap_domain_pirq (struct domain *d, int irq)
 {
-    u32 perm;
-    u32 rsid;
+    u32 sid;
     int rc = -EPERM;
 
-    struct domain_security_struct *ssec, *tsec;
+    struct domain_security_struct *ssec;
     struct avc_audit_data ad;
 
-    rc = domain_has_perm(current->domain, d, SECCLASS_RESOURCE,
-                         resource_to_perm(access));
-
+    rc = domain_has_perm(current->domain, d, SECCLASS_RESOURCE, RESOURCE__REMOVE);
     if ( rc )
         return rc;
 
-    if ( access )
-        perm = RESOURCE__ADD_IRQ;
-    else
-        perm = RESOURCE__REMOVE_IRQ;
-
     ssec = current->domain->ssid;
-    tsec = d->ssid;
 
-    rc = get_irq_sid(irq, &rsid, &ad);
-    if ( rc )
-        return rc;
-
-    rc = avc_has_perm(ssec->sid, rsid, SECCLASS_RESOURCE, perm, &ad);
+    if ( irq >= nr_irqs_gsi ) {
+        /* TODO support for MSI here */
+        return 0;
+    } else {
+        rc = get_irq_sid(irq, &sid, &ad);
+    }
     if ( rc )
         return rc;
 
-    if ( access )
-        rc = avc_has_perm(tsec->sid, rsid, SECCLASS_RESOURCE, 
-                            RESOURCE__USE, &ad);
+    rc = avc_has_perm(ssec->sid, sid, SECCLASS_RESOURCE, RESOURCE__REMOVE_IRQ, &ad);
     return rc;
 }
 
+static int flask_irq_permission (struct domain *d, int pirq, uint8_t access)
+{
+    /* the PIRQ number is not useful; real IRQ is checked during mapping */
+    return domain_has_perm(current->domain, d, SECCLASS_RESOURCE,
+                           resource_to_perm(access));
+}
+
 struct iomem_has_perm_data {
     struct domain_security_struct *ssec, *tsec;
     u32 perm;
@@ -1413,7 +1410,7 @@ static int flask_bind_pt_irq (struct domain *d, struct xen_domctl_bind_pt_irq *b
     return avc_has_perm(tsec->sid, rsid, SECCLASS_RESOURCE, RESOURCE__USE, &ad);
 }
 
-static int flask_unbind_pt_irq (struct domain *d)
+static int flask_unbind_pt_irq (struct domain *d, struct xen_domctl_bind_pt_irq *bind)
 {
     return domain_has_perm(current->domain, d, SECCLASS_RESOURCE, RESOURCE__REMOVE);
 }
@@ -1533,6 +1530,7 @@ static struct xsm_operations flask_ops = {
     .show_irq_sid = flask_show_irq_sid,
 
     .map_domain_pirq = flask_map_domain_pirq,
+    .unmap_domain_pirq = flask_unmap_domain_pirq,
     .irq_permission = flask_irq_permission,
     .iomem_permission = flask_iomem_permission,
     .pci_config_permission = flask_pci_config_permission,
-- 
1.7.11.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 10 19:50:00 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Sep 2012 19:50:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TB9zQ-0001Gf-WF; Mon, 10 Sep 2012 19:49:49 +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 1TB9zO-0001Cz-G7
	for xen-devel@lists.xen.org; Mon, 10 Sep 2012 19:49:46 +0000
Received: from [85.158.138.51:12384] by server-8.bemta-3.messagelabs.com id
	5B/16-24700-9544E405; Mon, 10 Sep 2012 19:49:45 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-6.tower-174.messagelabs.com!1347306583!21731059!1
X-Originating-IP: [63.239.67.9]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30097 invoked from network); 10 Sep 2012 19:49:44 -0000
Received: from emvm-gh1-uea08.nsa.gov (HELO nsa.gov) (63.239.67.9)
	by server-6.tower-174.messagelabs.com with SMTP;
	10 Sep 2012 19:49:44 -0000
X-TM-IMSS-Message-ID: <30671f54000ed1c4@nsa.gov>
Received: from tarius.tycho.ncsc.mil ([144.51.3.1]) by nsa.gov ([63.239.67.9])
	with ESMTP (TREND IMSS SMTP Service 7.1) id 30671f54000ed1c4 ;
	Mon, 10 Sep 2012 15:49:38 -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 q8AJna3t027796; 
	Mon, 10 Sep 2012 15:49:42 -0400
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xen.org
Date: Mon, 10 Sep 2012 15:49:10 -0400
Message-Id: <1347306553-20980-18-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.11.4
In-Reply-To: <1347306553-20980-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1347306553-20980-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Tim Deegan <tim@xen.org>, Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	Keir Fraser <keir@xen.org>, Jan Beulich <jbeulich@suse.com>
Subject: [Xen-devel] [PATCH 17/20] arch/x86: use XSM hooks for get_pg_owner
	access checks
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This requires introducing a new XSM hook for do_mmuext_op to validate
remote domain access there.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Cc: Keir Fraser <keir@xen.org>
Cc: Jan Beulich <jbeulich@suse.com>
Cc: Tim Deegan <tim@xen.org>
---
 tools/flask/policy/policy/flask/access_vectors |  1 +
 tools/flask/policy/policy/modules/xen/xen.if   |  4 ++--
 xen/arch/x86/mm.c                              | 23 +++++++----------------
 xen/include/xsm/dummy.h                        | 15 +++++++++++++++
 xen/include/xsm/xsm.h                          |  6 ++++++
 xen/xsm/dummy.c                                |  1 +
 xen/xsm/flask/hooks.c                          |  6 ++++++
 xen/xsm/flask/include/av_perm_to_string.h      |  1 +
 xen/xsm/flask/include/av_permissions.h         |  1 +
 9 files changed, 40 insertions(+), 18 deletions(-)

diff --git a/tools/flask/policy/policy/flask/access_vectors b/tools/flask/policy/policy/flask/access_vectors
index 2986b40..5e897e2 100644
--- a/tools/flask/policy/policy/flask/access_vectors
+++ b/tools/flask/policy/policy/flask/access_vectors
@@ -141,6 +141,7 @@ class mmu
     mfnlist
     memorymap
     remote_remap
+	mmuext_op
 }
 
 class shadow
diff --git a/tools/flask/policy/policy/modules/xen/xen.if b/tools/flask/policy/policy/modules/xen/xen.if
index 1847f23..e0c2d2d 100644
--- a/tools/flask/policy/policy/modules/xen/xen.if
+++ b/tools/flask/policy/policy/modules/xen/xen.if
@@ -7,7 +7,7 @@
 ################################################################################
 define(`declare_domain_common', `
 	allow $1 $2:grant { query setup };
-	allow $1 $2:mmu { adjust physmap map_read map_write stat pinpage updatemp };
+	allow $1 $2:mmu { adjust physmap map_read map_write stat pinpage updatemp mmuext_op };
 	allow $1 $2:hvm { getparam setparam };
 ')
 
@@ -51,7 +51,7 @@ define(`create_domain_common', `
 	allow $1 $2:domain2 { set_cpuid settsc };
 	allow $1 $2:security check_context;
 	allow $1 $2:shadow enable;
-	allow $1 $2:mmu {map_read map_write adjust memorymap physmap pinpage};
+	allow $1 $2:mmu { map_read map_write adjust memorymap physmap pinpage mmuext_op };
 	allow $1 $2:grant setup;
 	allow $1 $2:hvm { cacheattr getparam hvmctl irqlevel pciroute sethvmc setparam pcilevel trackdirtyvram };
 ')
diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
index f16b112..692d651 100644
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -2882,11 +2882,6 @@ static struct domain *get_pg_owner(domid_t domid)
         pg_owner = rcu_lock_domain(dom_io);
         break;
     case DOMID_XEN:
-        if ( !IS_PRIV(curr) )
-        {
-            MEM_LOG("Cannot set foreign dom");
-            break;
-        }
         pg_owner = rcu_lock_domain(dom_xen);
         break;
     default:
@@ -2895,12 +2890,6 @@ static struct domain *get_pg_owner(domid_t domid)
             MEM_LOG("Unknown domain '%u'", domid);
             break;
         }
-        if ( !IS_PRIV_FOR(curr, pg_owner) )
-        {
-            MEM_LOG("Cannot set foreign dom");
-            rcu_unlock_domain(pg_owner);
-            pg_owner = NULL;
-        }
         break;
     }
 
@@ -3008,6 +2997,13 @@ long do_mmuext_op(
         goto out;
     }
 
+    rc = xsm_mmuext_op(d, pg_owner);
+    if ( rc )
+    {
+        rcu_unlock_domain(pg_owner);
+        goto out;
+    }
+
     for ( i = 0; i < count; i++ )
     {
         if ( hypercall_preempt_check() )
@@ -3483,11 +3479,6 @@ long do_mmu_update(
             rc = -EINVAL;
             goto out;
         }
-        if ( !IS_PRIV_FOR(d, pt_owner) )
-        {
-            rc = -ESRCH;
-            goto out;
-        }
     }
 
     if ( (pg_owner = get_pg_owner((uint16_t)foreigndom)) == NULL )
diff --git a/xen/include/xsm/dummy.h b/xen/include/xsm/dummy.h
index b26de57..a093734 100644
--- a/xen/include/xsm/dummy.h
+++ b/xen/include/xsm/dummy.h
@@ -803,18 +803,33 @@ static XSM_DEFAULT(int, domain_memory_map) (struct domain *d)
 static XSM_DEFAULT(int, mmu_normal_update) (struct domain *d, struct domain *t,
                                             struct domain *f, intpte_t fpte)
 {
+    if ( d != t && !IS_PRIV_FOR(d, t) )
+        return -EPERM;
+    if ( d != f && !IS_PRIV_FOR(d, f) )
+        return -EPERM;
     return 0;
 }
 
 static XSM_DEFAULT(int, mmu_machphys_update) (struct domain *d, struct domain *f,
                                               unsigned long mfn)
 {
+    if ( d != f && !IS_PRIV_FOR(d, f) )
+        return -EPERM;
+    return 0;
+}
+
+static XSM_DEFAULT(int, mmuext_op) (struct domain *d, struct domain *f)
+{
+    if ( d != f && !IS_PRIV_FOR(d, f) )
+        return -EPERM;
     return 0;
 }
 
 static XSM_DEFAULT(int, update_va_mapping) (struct domain *d, struct domain *f, 
                                                             l1_pgentry_t pte)
 {
+    if ( d != f && !IS_PRIV_FOR(d, f) )
+        return -EPERM;
     return 0;
 }
 
diff --git a/xen/include/xsm/xsm.h b/xen/include/xsm/xsm.h
index 8226d93..cf2a7e5 100644
--- a/xen/include/xsm/xsm.h
+++ b/xen/include/xsm/xsm.h
@@ -177,6 +177,7 @@ struct xsm_operations {
     int (*mmu_normal_update) (struct domain *d, struct domain *t,
                               struct domain *f, intpte_t fpte);
     int (*mmu_machphys_update) (struct domain *d1, struct domain *d2, unsigned long mfn);
+    int (*mmuext_op) (struct domain *d, struct domain *f);
     int (*update_va_mapping) (struct domain *d, struct domain *f, l1_pgentry_t pte);
     int (*add_to_physmap) (struct domain *d1, struct domain *d2);
     int (*sendtrigger) (struct domain *d);
@@ -797,6 +798,11 @@ static inline int xsm_mmu_machphys_update (struct domain *d1, struct domain *d2,
     return xsm_ops->mmu_machphys_update(d1, d2, mfn);
 }
 
+static inline int xsm_mmuext_op (struct domain *d, struct domain *f)
+{
+	return xsm_ops->mmuext_op(d, f);
+}
+
 static inline int xsm_update_va_mapping(struct domain *d, struct domain *f, 
                                                             l1_pgentry_t pte)
 {
diff --git a/xen/xsm/dummy.c b/xen/xsm/dummy.c
index 0a18d50..954f97c 100644
--- a/xen/xsm/dummy.c
+++ b/xen/xsm/dummy.c
@@ -160,6 +160,7 @@ void xsm_fixup_ops (struct xsm_operations *ops)
     set_to_dummy_if_null(ops, domain_memory_map);
     set_to_dummy_if_null(ops, mmu_normal_update);
     set_to_dummy_if_null(ops, mmu_machphys_update);
+    set_to_dummy_if_null(ops, mmuext_op);
     set_to_dummy_if_null(ops, update_va_mapping);
     set_to_dummy_if_null(ops, add_to_physmap);
     set_to_dummy_if_null(ops, remove_from_physmap);
diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
index 7da1754..dc5f67e 100644
--- a/xen/xsm/flask/hooks.c
+++ b/xen/xsm/flask/hooks.c
@@ -1333,6 +1333,11 @@ static int flask_mmu_machphys_update(struct domain *d1, struct domain *d2,
     return domain_has_perm(d1, d2, SECCLASS_MMU, MMU__UPDATEMP);
 }
 
+static int flask_mmuext_op(struct domain *d, struct domain *f)
+{
+    return domain_has_perm(d, f, SECCLASS_MMU, MMU__MMUEXT_OP);
+}
+
 static int flask_update_va_mapping(struct domain *d, struct domain *f,
                                    l1_pgentry_t pte)
 {
@@ -1620,6 +1625,7 @@ static struct xsm_operations flask_ops = {
     .domain_memory_map = flask_domain_memory_map,
     .mmu_normal_update = flask_mmu_normal_update,
     .mmu_machphys_update = flask_mmu_machphys_update,
+    .mmuext_op = flask_mmuext_op,
     .update_va_mapping = flask_update_va_mapping,
     .add_to_physmap = flask_add_to_physmap,
     .remove_from_physmap = flask_remove_from_physmap,
diff --git a/xen/xsm/flask/include/av_perm_to_string.h b/xen/xsm/flask/include/av_perm_to_string.h
index 5d5a45a..5d4f316 100644
--- a/xen/xsm/flask/include/av_perm_to_string.h
+++ b/xen/xsm/flask/include/av_perm_to_string.h
@@ -111,6 +111,7 @@
    S_(SECCLASS_MMU, MMU__MFNLIST, "mfnlist")
    S_(SECCLASS_MMU, MMU__MEMORYMAP, "memorymap")
    S_(SECCLASS_MMU, MMU__REMOTE_REMAP, "remote_remap")
+   S_(SECCLASS_MMU, MMU__MMUEXT_OP, "mmuext_op")
    S_(SECCLASS_SHADOW, SHADOW__DISABLE, "disable")
    S_(SECCLASS_SHADOW, SHADOW__ENABLE, "enable")
    S_(SECCLASS_SHADOW, SHADOW__LOGDIRTY, "logdirty")
diff --git a/xen/xsm/flask/include/av_permissions.h b/xen/xsm/flask/include/av_permissions.h
index e6d6a6d..f970b50 100644
--- a/xen/xsm/flask/include/av_permissions.h
+++ b/xen/xsm/flask/include/av_permissions.h
@@ -117,6 +117,7 @@
 #define MMU__MFNLIST                              0x00000400UL
 #define MMU__MEMORYMAP                            0x00000800UL
 #define MMU__REMOTE_REMAP                         0x00001000UL
+#define MMU__MMUEXT_OP                            0x00002000UL
 
 #define SHADOW__DISABLE                           0x00000001UL
 #define SHADOW__ENABLE                            0x00000002UL
-- 
1.7.11.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 10 19:50:00 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Sep 2012 19:50:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TB9zQ-0001Gf-WF; Mon, 10 Sep 2012 19:49:49 +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 1TB9zO-0001Cz-G7
	for xen-devel@lists.xen.org; Mon, 10 Sep 2012 19:49:46 +0000
Received: from [85.158.138.51:12384] by server-8.bemta-3.messagelabs.com id
	5B/16-24700-9544E405; Mon, 10 Sep 2012 19:49:45 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-6.tower-174.messagelabs.com!1347306583!21731059!1
X-Originating-IP: [63.239.67.9]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30097 invoked from network); 10 Sep 2012 19:49:44 -0000
Received: from emvm-gh1-uea08.nsa.gov (HELO nsa.gov) (63.239.67.9)
	by server-6.tower-174.messagelabs.com with SMTP;
	10 Sep 2012 19:49:44 -0000
X-TM-IMSS-Message-ID: <30671f54000ed1c4@nsa.gov>
Received: from tarius.tycho.ncsc.mil ([144.51.3.1]) by nsa.gov ([63.239.67.9])
	with ESMTP (TREND IMSS SMTP Service 7.1) id 30671f54000ed1c4 ;
	Mon, 10 Sep 2012 15:49:38 -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 q8AJna3t027796; 
	Mon, 10 Sep 2012 15:49:42 -0400
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xen.org
Date: Mon, 10 Sep 2012 15:49:10 -0400
Message-Id: <1347306553-20980-18-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.11.4
In-Reply-To: <1347306553-20980-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1347306553-20980-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Tim Deegan <tim@xen.org>, Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	Keir Fraser <keir@xen.org>, Jan Beulich <jbeulich@suse.com>
Subject: [Xen-devel] [PATCH 17/20] arch/x86: use XSM hooks for get_pg_owner
	access checks
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This requires introducing a new XSM hook for do_mmuext_op to validate
remote domain access there.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Cc: Keir Fraser <keir@xen.org>
Cc: Jan Beulich <jbeulich@suse.com>
Cc: Tim Deegan <tim@xen.org>
---
 tools/flask/policy/policy/flask/access_vectors |  1 +
 tools/flask/policy/policy/modules/xen/xen.if   |  4 ++--
 xen/arch/x86/mm.c                              | 23 +++++++----------------
 xen/include/xsm/dummy.h                        | 15 +++++++++++++++
 xen/include/xsm/xsm.h                          |  6 ++++++
 xen/xsm/dummy.c                                |  1 +
 xen/xsm/flask/hooks.c                          |  6 ++++++
 xen/xsm/flask/include/av_perm_to_string.h      |  1 +
 xen/xsm/flask/include/av_permissions.h         |  1 +
 9 files changed, 40 insertions(+), 18 deletions(-)

diff --git a/tools/flask/policy/policy/flask/access_vectors b/tools/flask/policy/policy/flask/access_vectors
index 2986b40..5e897e2 100644
--- a/tools/flask/policy/policy/flask/access_vectors
+++ b/tools/flask/policy/policy/flask/access_vectors
@@ -141,6 +141,7 @@ class mmu
     mfnlist
     memorymap
     remote_remap
+	mmuext_op
 }
 
 class shadow
diff --git a/tools/flask/policy/policy/modules/xen/xen.if b/tools/flask/policy/policy/modules/xen/xen.if
index 1847f23..e0c2d2d 100644
--- a/tools/flask/policy/policy/modules/xen/xen.if
+++ b/tools/flask/policy/policy/modules/xen/xen.if
@@ -7,7 +7,7 @@
 ################################################################################
 define(`declare_domain_common', `
 	allow $1 $2:grant { query setup };
-	allow $1 $2:mmu { adjust physmap map_read map_write stat pinpage updatemp };
+	allow $1 $2:mmu { adjust physmap map_read map_write stat pinpage updatemp mmuext_op };
 	allow $1 $2:hvm { getparam setparam };
 ')
 
@@ -51,7 +51,7 @@ define(`create_domain_common', `
 	allow $1 $2:domain2 { set_cpuid settsc };
 	allow $1 $2:security check_context;
 	allow $1 $2:shadow enable;
-	allow $1 $2:mmu {map_read map_write adjust memorymap physmap pinpage};
+	allow $1 $2:mmu { map_read map_write adjust memorymap physmap pinpage mmuext_op };
 	allow $1 $2:grant setup;
 	allow $1 $2:hvm { cacheattr getparam hvmctl irqlevel pciroute sethvmc setparam pcilevel trackdirtyvram };
 ')
diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
index f16b112..692d651 100644
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -2882,11 +2882,6 @@ static struct domain *get_pg_owner(domid_t domid)
         pg_owner = rcu_lock_domain(dom_io);
         break;
     case DOMID_XEN:
-        if ( !IS_PRIV(curr) )
-        {
-            MEM_LOG("Cannot set foreign dom");
-            break;
-        }
         pg_owner = rcu_lock_domain(dom_xen);
         break;
     default:
@@ -2895,12 +2890,6 @@ static struct domain *get_pg_owner(domid_t domid)
             MEM_LOG("Unknown domain '%u'", domid);
             break;
         }
-        if ( !IS_PRIV_FOR(curr, pg_owner) )
-        {
-            MEM_LOG("Cannot set foreign dom");
-            rcu_unlock_domain(pg_owner);
-            pg_owner = NULL;
-        }
         break;
     }
 
@@ -3008,6 +2997,13 @@ long do_mmuext_op(
         goto out;
     }
 
+    rc = xsm_mmuext_op(d, pg_owner);
+    if ( rc )
+    {
+        rcu_unlock_domain(pg_owner);
+        goto out;
+    }
+
     for ( i = 0; i < count; i++ )
     {
         if ( hypercall_preempt_check() )
@@ -3483,11 +3479,6 @@ long do_mmu_update(
             rc = -EINVAL;
             goto out;
         }
-        if ( !IS_PRIV_FOR(d, pt_owner) )
-        {
-            rc = -ESRCH;
-            goto out;
-        }
     }
 
     if ( (pg_owner = get_pg_owner((uint16_t)foreigndom)) == NULL )
diff --git a/xen/include/xsm/dummy.h b/xen/include/xsm/dummy.h
index b26de57..a093734 100644
--- a/xen/include/xsm/dummy.h
+++ b/xen/include/xsm/dummy.h
@@ -803,18 +803,33 @@ static XSM_DEFAULT(int, domain_memory_map) (struct domain *d)
 static XSM_DEFAULT(int, mmu_normal_update) (struct domain *d, struct domain *t,
                                             struct domain *f, intpte_t fpte)
 {
+    if ( d != t && !IS_PRIV_FOR(d, t) )
+        return -EPERM;
+    if ( d != f && !IS_PRIV_FOR(d, f) )
+        return -EPERM;
     return 0;
 }
 
 static XSM_DEFAULT(int, mmu_machphys_update) (struct domain *d, struct domain *f,
                                               unsigned long mfn)
 {
+    if ( d != f && !IS_PRIV_FOR(d, f) )
+        return -EPERM;
+    return 0;
+}
+
+static XSM_DEFAULT(int, mmuext_op) (struct domain *d, struct domain *f)
+{
+    if ( d != f && !IS_PRIV_FOR(d, f) )
+        return -EPERM;
     return 0;
 }
 
 static XSM_DEFAULT(int, update_va_mapping) (struct domain *d, struct domain *f, 
                                                             l1_pgentry_t pte)
 {
+    if ( d != f && !IS_PRIV_FOR(d, f) )
+        return -EPERM;
     return 0;
 }
 
diff --git a/xen/include/xsm/xsm.h b/xen/include/xsm/xsm.h
index 8226d93..cf2a7e5 100644
--- a/xen/include/xsm/xsm.h
+++ b/xen/include/xsm/xsm.h
@@ -177,6 +177,7 @@ struct xsm_operations {
     int (*mmu_normal_update) (struct domain *d, struct domain *t,
                               struct domain *f, intpte_t fpte);
     int (*mmu_machphys_update) (struct domain *d1, struct domain *d2, unsigned long mfn);
+    int (*mmuext_op) (struct domain *d, struct domain *f);
     int (*update_va_mapping) (struct domain *d, struct domain *f, l1_pgentry_t pte);
     int (*add_to_physmap) (struct domain *d1, struct domain *d2);
     int (*sendtrigger) (struct domain *d);
@@ -797,6 +798,11 @@ static inline int xsm_mmu_machphys_update (struct domain *d1, struct domain *d2,
     return xsm_ops->mmu_machphys_update(d1, d2, mfn);
 }
 
+static inline int xsm_mmuext_op (struct domain *d, struct domain *f)
+{
+	return xsm_ops->mmuext_op(d, f);
+}
+
 static inline int xsm_update_va_mapping(struct domain *d, struct domain *f, 
                                                             l1_pgentry_t pte)
 {
diff --git a/xen/xsm/dummy.c b/xen/xsm/dummy.c
index 0a18d50..954f97c 100644
--- a/xen/xsm/dummy.c
+++ b/xen/xsm/dummy.c
@@ -160,6 +160,7 @@ void xsm_fixup_ops (struct xsm_operations *ops)
     set_to_dummy_if_null(ops, domain_memory_map);
     set_to_dummy_if_null(ops, mmu_normal_update);
     set_to_dummy_if_null(ops, mmu_machphys_update);
+    set_to_dummy_if_null(ops, mmuext_op);
     set_to_dummy_if_null(ops, update_va_mapping);
     set_to_dummy_if_null(ops, add_to_physmap);
     set_to_dummy_if_null(ops, remove_from_physmap);
diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
index 7da1754..dc5f67e 100644
--- a/xen/xsm/flask/hooks.c
+++ b/xen/xsm/flask/hooks.c
@@ -1333,6 +1333,11 @@ static int flask_mmu_machphys_update(struct domain *d1, struct domain *d2,
     return domain_has_perm(d1, d2, SECCLASS_MMU, MMU__UPDATEMP);
 }
 
+static int flask_mmuext_op(struct domain *d, struct domain *f)
+{
+    return domain_has_perm(d, f, SECCLASS_MMU, MMU__MMUEXT_OP);
+}
+
 static int flask_update_va_mapping(struct domain *d, struct domain *f,
                                    l1_pgentry_t pte)
 {
@@ -1620,6 +1625,7 @@ static struct xsm_operations flask_ops = {
     .domain_memory_map = flask_domain_memory_map,
     .mmu_normal_update = flask_mmu_normal_update,
     .mmu_machphys_update = flask_mmu_machphys_update,
+    .mmuext_op = flask_mmuext_op,
     .update_va_mapping = flask_update_va_mapping,
     .add_to_physmap = flask_add_to_physmap,
     .remove_from_physmap = flask_remove_from_physmap,
diff --git a/xen/xsm/flask/include/av_perm_to_string.h b/xen/xsm/flask/include/av_perm_to_string.h
index 5d5a45a..5d4f316 100644
--- a/xen/xsm/flask/include/av_perm_to_string.h
+++ b/xen/xsm/flask/include/av_perm_to_string.h
@@ -111,6 +111,7 @@
    S_(SECCLASS_MMU, MMU__MFNLIST, "mfnlist")
    S_(SECCLASS_MMU, MMU__MEMORYMAP, "memorymap")
    S_(SECCLASS_MMU, MMU__REMOTE_REMAP, "remote_remap")
+   S_(SECCLASS_MMU, MMU__MMUEXT_OP, "mmuext_op")
    S_(SECCLASS_SHADOW, SHADOW__DISABLE, "disable")
    S_(SECCLASS_SHADOW, SHADOW__ENABLE, "enable")
    S_(SECCLASS_SHADOW, SHADOW__LOGDIRTY, "logdirty")
diff --git a/xen/xsm/flask/include/av_permissions.h b/xen/xsm/flask/include/av_permissions.h
index e6d6a6d..f970b50 100644
--- a/xen/xsm/flask/include/av_permissions.h
+++ b/xen/xsm/flask/include/av_permissions.h
@@ -117,6 +117,7 @@
 #define MMU__MFNLIST                              0x00000400UL
 #define MMU__MEMORYMAP                            0x00000800UL
 #define MMU__REMOTE_REMAP                         0x00001000UL
+#define MMU__MMUEXT_OP                            0x00002000UL
 
 #define SHADOW__DISABLE                           0x00000001UL
 #define SHADOW__ENABLE                            0x00000002UL
-- 
1.7.11.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 10 19:50:00 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Sep 2012 19:50:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TB9zR-0001HX-PN; Mon, 10 Sep 2012 19:49:49 +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 1TB9zP-00019X-11
	for xen-devel@lists.xen.org; Mon, 10 Sep 2012 19:49:47 +0000
Received: from [85.158.143.99:28067] by server-3.bemta-4.messagelabs.com id
	9B/D7-08232-A544E405; Mon, 10 Sep 2012 19:49:46 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-10.tower-216.messagelabs.com!1347306583!23195048!1
X-Originating-IP: [63.239.67.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19027 invoked from network); 10 Sep 2012 19:49:44 -0000
Received: from emvm-gh1-uea09.nsa.gov (HELO nsa.gov) (63.239.67.10)
	by server-10.tower-216.messagelabs.com with SMTP;
	10 Sep 2012 19:49:44 -0000
X-TM-IMSS-Message-ID: <3066d836000f2267@nsa.gov>
Received: from tarius.tycho.ncsc.mil ([144.51.3.1]) by nsa.gov
	([63.239.67.10]) with ESMTP (TREND IMSS SMTP Service 7.1) id
	3066d836000f2267 ; Mon, 10 Sep 2012 15:51:53 -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 q8AJna3q027796; 
	Mon, 10 Sep 2012 15:49:40 -0400
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xen.org
Date: Mon, 10 Sep 2012 15:49:07 -0400
Message-Id: <1347306553-20980-15-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.11.4
In-Reply-To: <1347306553-20980-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1347306553-20980-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	Dan Magenheimer <dan.magenheimer@oracle.com>
Subject: [Xen-devel] [PATCH 14/20] tmem: Add access control 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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Cc: Dan Magenheimer <dan.magenheimer@oracle.com>
---
 tools/flask/policy/policy/flask/access_vectors |  1 +
 xen/common/tmem.c                              | 10 +++++-----
 xen/include/xen/tmem_xen.h                     |  5 -----
 xen/include/xsm/dummy.h                        |  7 +++++++
 xen/include/xsm/xsm.h                          |  6 ++++++
 xen/xsm/dummy.c                                |  1 +
 xen/xsm/flask/hooks.c                          |  6 ++++++
 xen/xsm/flask/include/av_perm_to_string.h      |  1 +
 xen/xsm/flask/include/av_permissions.h         |  1 +
 9 files changed, 28 insertions(+), 10 deletions(-)

diff --git a/tools/flask/policy/policy/flask/access_vectors b/tools/flask/policy/policy/flask/access_vectors
index 28b8ada..2986b40 100644
--- a/tools/flask/policy/policy/flask/access_vectors
+++ b/tools/flask/policy/policy/flask/access_vectors
@@ -35,6 +35,7 @@ class xen
 	lockprof
 	cpupool_op
 	sched_op
+	tmem_op
 }
 
 class domain
diff --git a/xen/common/tmem.c b/xen/common/tmem.c
index 1a8777c..fe2db45 100644
--- a/xen/common/tmem.c
+++ b/xen/common/tmem.c
@@ -23,6 +23,7 @@
 #include <xen/radix-tree.h>
 #include <xen/list.h>
 #include <xen/init.h>
+#include <xsm/xsm.h>
 
 #define EXPORT /* indicates code other modules are dependent upon */
 #define FORWARD
@@ -2540,11 +2541,10 @@ static NOINLINE int do_tmem_control(struct tmem_op *op)
     uint32_t subop = op->u.ctrl.subop;
     OID *oidp = (OID *)(&op->u.ctrl.oid[0]);
 
-    if (!tmh_current_is_privileged())
-    {
-        /* don't fail... mystery: sometimes dom0 fails here */
-        /* return -EPERM; */
-    }
+    ret = xsm_tmem_control(subop);
+    if ( ret )
+        return ret;
+
     switch(subop)
     {
     case TMEMC_THAW:
diff --git a/xen/include/xen/tmem_xen.h b/xen/include/xen/tmem_xen.h
index 4a35760..f248128 100644
--- a/xen/include/xen/tmem_xen.h
+++ b/xen/include/xen/tmem_xen.h
@@ -344,11 +344,6 @@ static inline bool_t tmh_set_client_from_id(
     return rc;
 }
 
-static inline bool_t tmh_current_is_privileged(void)
-{
-    return IS_PRIV(current->domain);
-}
-
 static inline uint8_t tmh_get_first_byte(pfp_t *pfp)
 {
     void *p = __map_domain_page(pfp);
diff --git a/xen/include/xsm/dummy.h b/xen/include/xsm/dummy.h
index afbc504..b26de57 100644
--- a/xen/include/xsm/dummy.h
+++ b/xen/include/xsm/dummy.h
@@ -500,6 +500,13 @@ static XSM_DEFAULT(int, sched_op) (void)
     return 0;
 }
 
+static XSM_DEFAULT(int, tmem_control) (uint32_t subcmd)
+{
+    if ( !IS_PRIV(current->domain) )
+        return -EPERM;
+    return 0;
+}
+
 static XSM_DEFAULT(long, __do_xsm_op)(XEN_GUEST_HANDLE(xsm_op_t) op)
 {
     return -ENOSYS;
diff --git a/xen/include/xsm/xsm.h b/xen/include/xsm/xsm.h
index 6483ec6..ff76cae 100644
--- a/xen/include/xsm/xsm.h
+++ b/xen/include/xsm/xsm.h
@@ -137,6 +137,7 @@ struct xsm_operations {
     int (*lockprof)(void);
     int (*cpupool_op)(void);
     int (*sched_op)(void);
+    int (*tmem_control)(uint32_t subop);
 
     long (*__do_xsm_op) (XEN_GUEST_HANDLE(xsm_op_t) op);
 
@@ -605,6 +606,11 @@ static inline int xsm_sched_op(void)
     return xsm_call(sched_op());
 }
 
+static inline int xsm_tmem_control(uint32_t subop)
+{
+    return xsm_call(tmem_control(subop));
+}
+
 static inline long xsm___do_xsm_op (XEN_GUEST_HANDLE(xsm_op_t) op)
 {
     return xsm_ops->__do_xsm_op(op);
diff --git a/xen/xsm/dummy.c b/xen/xsm/dummy.c
index 055071a..0a18d50 100644
--- a/xen/xsm/dummy.c
+++ b/xen/xsm/dummy.c
@@ -119,6 +119,7 @@ void xsm_fixup_ops (struct xsm_operations *ops)
     set_to_dummy_if_null(ops, lockprof);
     set_to_dummy_if_null(ops, cpupool_op);
     set_to_dummy_if_null(ops, sched_op);
+    set_to_dummy_if_null(ops, tmem_control);
 
     set_to_dummy_if_null(ops, __do_xsm_op);
 
diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
index fc89ebc..f6ec7bd 100644
--- a/xen/xsm/flask/hooks.c
+++ b/xen/xsm/flask/hooks.c
@@ -962,6 +962,11 @@ static inline int flask_sched_op(void)
     return domain_has_xen(current->domain, XEN__SCHED_OP);
 }
 
+static inline int flask_tmem_control(uint32_t subcmd)
+{
+    return domain_has_xen(current->domain, XEN__TMEM_OP);
+}
+
 static int flask_perfcontrol(void)
 {
     return domain_has_xen(current->domain, XEN__PERFCONTROL);
@@ -1599,6 +1604,7 @@ static struct xsm_operations flask_ops = {
     .lockprof = flask_lockprof,
     .cpupool_op = flask_cpupool_op,
     .sched_op = flask_sched_op,
+    .tmem_control = flask_tmem_control,
 
     .__do_xsm_op = do_flask_op,
 
diff --git a/xen/xsm/flask/include/av_perm_to_string.h b/xen/xsm/flask/include/av_perm_to_string.h
index 997f098..5d5a45a 100644
--- a/xen/xsm/flask/include/av_perm_to_string.h
+++ b/xen/xsm/flask/include/av_perm_to_string.h
@@ -29,6 +29,7 @@
    S_(SECCLASS_XEN, XEN__LOCKPROF, "lockprof")
    S_(SECCLASS_XEN, XEN__CPUPOOL_OP, "cpupool_op")
    S_(SECCLASS_XEN, XEN__SCHED_OP, "sched_op")
+   S_(SECCLASS_XEN, XEN__TMEM_OP, "tmem_op")
    S_(SECCLASS_DOMAIN, DOMAIN__SETVCPUCONTEXT, "setvcpucontext")
    S_(SECCLASS_DOMAIN, DOMAIN__PAUSE, "pause")
    S_(SECCLASS_DOMAIN, DOMAIN__UNPAUSE, "unpause")
diff --git a/xen/xsm/flask/include/av_permissions.h b/xen/xsm/flask/include/av_permissions.h
index 8596a55..e6d6a6d 100644
--- a/xen/xsm/flask/include/av_permissions.h
+++ b/xen/xsm/flask/include/av_permissions.h
@@ -29,6 +29,7 @@
 #define XEN__LOCKPROF                             0x08000000UL
 #define XEN__CPUPOOL_OP                           0x10000000UL
 #define XEN__SCHED_OP                             0x20000000UL
+#define XEN__TMEM_OP                              0x40000000UL
 
 #define DOMAIN__SETVCPUCONTEXT                    0x00000001UL
 #define DOMAIN__PAUSE                             0x00000002UL
-- 
1.7.11.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 10 19:50:00 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Sep 2012 19:50:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TB9zR-0001HX-PN; Mon, 10 Sep 2012 19:49:49 +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 1TB9zP-00019X-11
	for xen-devel@lists.xen.org; Mon, 10 Sep 2012 19:49:47 +0000
Received: from [85.158.143.99:28067] by server-3.bemta-4.messagelabs.com id
	9B/D7-08232-A544E405; Mon, 10 Sep 2012 19:49:46 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-10.tower-216.messagelabs.com!1347306583!23195048!1
X-Originating-IP: [63.239.67.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19027 invoked from network); 10 Sep 2012 19:49:44 -0000
Received: from emvm-gh1-uea09.nsa.gov (HELO nsa.gov) (63.239.67.10)
	by server-10.tower-216.messagelabs.com with SMTP;
	10 Sep 2012 19:49:44 -0000
X-TM-IMSS-Message-ID: <3066d836000f2267@nsa.gov>
Received: from tarius.tycho.ncsc.mil ([144.51.3.1]) by nsa.gov
	([63.239.67.10]) with ESMTP (TREND IMSS SMTP Service 7.1) id
	3066d836000f2267 ; Mon, 10 Sep 2012 15:51:53 -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 q8AJna3q027796; 
	Mon, 10 Sep 2012 15:49:40 -0400
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xen.org
Date: Mon, 10 Sep 2012 15:49:07 -0400
Message-Id: <1347306553-20980-15-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.11.4
In-Reply-To: <1347306553-20980-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1347306553-20980-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	Dan Magenheimer <dan.magenheimer@oracle.com>
Subject: [Xen-devel] [PATCH 14/20] tmem: Add access control 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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Cc: Dan Magenheimer <dan.magenheimer@oracle.com>
---
 tools/flask/policy/policy/flask/access_vectors |  1 +
 xen/common/tmem.c                              | 10 +++++-----
 xen/include/xen/tmem_xen.h                     |  5 -----
 xen/include/xsm/dummy.h                        |  7 +++++++
 xen/include/xsm/xsm.h                          |  6 ++++++
 xen/xsm/dummy.c                                |  1 +
 xen/xsm/flask/hooks.c                          |  6 ++++++
 xen/xsm/flask/include/av_perm_to_string.h      |  1 +
 xen/xsm/flask/include/av_permissions.h         |  1 +
 9 files changed, 28 insertions(+), 10 deletions(-)

diff --git a/tools/flask/policy/policy/flask/access_vectors b/tools/flask/policy/policy/flask/access_vectors
index 28b8ada..2986b40 100644
--- a/tools/flask/policy/policy/flask/access_vectors
+++ b/tools/flask/policy/policy/flask/access_vectors
@@ -35,6 +35,7 @@ class xen
 	lockprof
 	cpupool_op
 	sched_op
+	tmem_op
 }
 
 class domain
diff --git a/xen/common/tmem.c b/xen/common/tmem.c
index 1a8777c..fe2db45 100644
--- a/xen/common/tmem.c
+++ b/xen/common/tmem.c
@@ -23,6 +23,7 @@
 #include <xen/radix-tree.h>
 #include <xen/list.h>
 #include <xen/init.h>
+#include <xsm/xsm.h>
 
 #define EXPORT /* indicates code other modules are dependent upon */
 #define FORWARD
@@ -2540,11 +2541,10 @@ static NOINLINE int do_tmem_control(struct tmem_op *op)
     uint32_t subop = op->u.ctrl.subop;
     OID *oidp = (OID *)(&op->u.ctrl.oid[0]);
 
-    if (!tmh_current_is_privileged())
-    {
-        /* don't fail... mystery: sometimes dom0 fails here */
-        /* return -EPERM; */
-    }
+    ret = xsm_tmem_control(subop);
+    if ( ret )
+        return ret;
+
     switch(subop)
     {
     case TMEMC_THAW:
diff --git a/xen/include/xen/tmem_xen.h b/xen/include/xen/tmem_xen.h
index 4a35760..f248128 100644
--- a/xen/include/xen/tmem_xen.h
+++ b/xen/include/xen/tmem_xen.h
@@ -344,11 +344,6 @@ static inline bool_t tmh_set_client_from_id(
     return rc;
 }
 
-static inline bool_t tmh_current_is_privileged(void)
-{
-    return IS_PRIV(current->domain);
-}
-
 static inline uint8_t tmh_get_first_byte(pfp_t *pfp)
 {
     void *p = __map_domain_page(pfp);
diff --git a/xen/include/xsm/dummy.h b/xen/include/xsm/dummy.h
index afbc504..b26de57 100644
--- a/xen/include/xsm/dummy.h
+++ b/xen/include/xsm/dummy.h
@@ -500,6 +500,13 @@ static XSM_DEFAULT(int, sched_op) (void)
     return 0;
 }
 
+static XSM_DEFAULT(int, tmem_control) (uint32_t subcmd)
+{
+    if ( !IS_PRIV(current->domain) )
+        return -EPERM;
+    return 0;
+}
+
 static XSM_DEFAULT(long, __do_xsm_op)(XEN_GUEST_HANDLE(xsm_op_t) op)
 {
     return -ENOSYS;
diff --git a/xen/include/xsm/xsm.h b/xen/include/xsm/xsm.h
index 6483ec6..ff76cae 100644
--- a/xen/include/xsm/xsm.h
+++ b/xen/include/xsm/xsm.h
@@ -137,6 +137,7 @@ struct xsm_operations {
     int (*lockprof)(void);
     int (*cpupool_op)(void);
     int (*sched_op)(void);
+    int (*tmem_control)(uint32_t subop);
 
     long (*__do_xsm_op) (XEN_GUEST_HANDLE(xsm_op_t) op);
 
@@ -605,6 +606,11 @@ static inline int xsm_sched_op(void)
     return xsm_call(sched_op());
 }
 
+static inline int xsm_tmem_control(uint32_t subop)
+{
+    return xsm_call(tmem_control(subop));
+}
+
 static inline long xsm___do_xsm_op (XEN_GUEST_HANDLE(xsm_op_t) op)
 {
     return xsm_ops->__do_xsm_op(op);
diff --git a/xen/xsm/dummy.c b/xen/xsm/dummy.c
index 055071a..0a18d50 100644
--- a/xen/xsm/dummy.c
+++ b/xen/xsm/dummy.c
@@ -119,6 +119,7 @@ void xsm_fixup_ops (struct xsm_operations *ops)
     set_to_dummy_if_null(ops, lockprof);
     set_to_dummy_if_null(ops, cpupool_op);
     set_to_dummy_if_null(ops, sched_op);
+    set_to_dummy_if_null(ops, tmem_control);
 
     set_to_dummy_if_null(ops, __do_xsm_op);
 
diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
index fc89ebc..f6ec7bd 100644
--- a/xen/xsm/flask/hooks.c
+++ b/xen/xsm/flask/hooks.c
@@ -962,6 +962,11 @@ static inline int flask_sched_op(void)
     return domain_has_xen(current->domain, XEN__SCHED_OP);
 }
 
+static inline int flask_tmem_control(uint32_t subcmd)
+{
+    return domain_has_xen(current->domain, XEN__TMEM_OP);
+}
+
 static int flask_perfcontrol(void)
 {
     return domain_has_xen(current->domain, XEN__PERFCONTROL);
@@ -1599,6 +1604,7 @@ static struct xsm_operations flask_ops = {
     .lockprof = flask_lockprof,
     .cpupool_op = flask_cpupool_op,
     .sched_op = flask_sched_op,
+    .tmem_control = flask_tmem_control,
 
     .__do_xsm_op = do_flask_op,
 
diff --git a/xen/xsm/flask/include/av_perm_to_string.h b/xen/xsm/flask/include/av_perm_to_string.h
index 997f098..5d5a45a 100644
--- a/xen/xsm/flask/include/av_perm_to_string.h
+++ b/xen/xsm/flask/include/av_perm_to_string.h
@@ -29,6 +29,7 @@
    S_(SECCLASS_XEN, XEN__LOCKPROF, "lockprof")
    S_(SECCLASS_XEN, XEN__CPUPOOL_OP, "cpupool_op")
    S_(SECCLASS_XEN, XEN__SCHED_OP, "sched_op")
+   S_(SECCLASS_XEN, XEN__TMEM_OP, "tmem_op")
    S_(SECCLASS_DOMAIN, DOMAIN__SETVCPUCONTEXT, "setvcpucontext")
    S_(SECCLASS_DOMAIN, DOMAIN__PAUSE, "pause")
    S_(SECCLASS_DOMAIN, DOMAIN__UNPAUSE, "unpause")
diff --git a/xen/xsm/flask/include/av_permissions.h b/xen/xsm/flask/include/av_permissions.h
index 8596a55..e6d6a6d 100644
--- a/xen/xsm/flask/include/av_permissions.h
+++ b/xen/xsm/flask/include/av_permissions.h
@@ -29,6 +29,7 @@
 #define XEN__LOCKPROF                             0x08000000UL
 #define XEN__CPUPOOL_OP                           0x10000000UL
 #define XEN__SCHED_OP                             0x20000000UL
+#define XEN__TMEM_OP                              0x40000000UL
 
 #define DOMAIN__SETVCPUCONTEXT                    0x00000001UL
 #define DOMAIN__PAUSE                             0x00000002UL
-- 
1.7.11.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 10 19:50:01 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Sep 2012 19:50:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TB9zL-0001Af-G6; Mon, 10 Sep 2012 19:49:43 +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 1TB9zJ-00019X-PI
	for xen-devel@lists.xen.org; Mon, 10 Sep 2012 19:49:41 +0000
Received: from [85.158.143.99:27921] by server-3.bemta-4.messagelabs.com id
	EF/C7-08232-5544E405; Mon, 10 Sep 2012 19:49:41 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-3.tower-216.messagelabs.com!1347306579!29003656!1
X-Originating-IP: [63.239.67.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18551 invoked from network); 10 Sep 2012 19:49:40 -0000
Received: from emvm-gh1-uea09.nsa.gov (HELO nsa.gov) (63.239.67.10)
	by server-3.tower-216.messagelabs.com with SMTP;
	10 Sep 2012 19:49:40 -0000
X-TM-IMSS-Message-ID: <3066ccb2000f225d@nsa.gov>
Received: from tarius.tycho.ncsc.mil ([144.51.3.1]) by nsa.gov
	([63.239.67.10]) with ESMTP (TREND IMSS SMTP Service 7.1) id
	3066ccb2000f225d ; Mon, 10 Sep 2012 15:51:50 -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 q8AJna3h027796; 
	Mon, 10 Sep 2012 15:49:37 -0400
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xen.org
Date: Mon, 10 Sep 2012 15:48:58 -0400
Message-Id: <1347306553-20980-6-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.11.4
In-Reply-To: <1347306553-20980-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1347306553-20980-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	Ian Jackson <ian.jackson@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH 05/20] libxl: introduce XSM relabel on build
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Allow a domain to be built under one security label and run using a
different label. This can be used to prevent the domain builder or
control domain from having the ability to access a guest domain's memory
via map_foreign_range except during the build process where this is
required.

Note: this does not provide complete protection from a malicious dom0;
mappings created during the build process may persist after the relabel,
and could be used to indirectly access the guest's memory.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: Ian Campbell <ian.campbell@citrix.com>
---
 tools/libxc/xc_flask.c      | 10 ++++++++++
 tools/libxc/xenctrl.h       |  1 +
 tools/libxl/libxl_create.c  |  4 ++++
 tools/libxl/libxl_types.idl |  1 +
 tools/libxl/xl_cmdimpl.c    | 20 +++++++++++++++++++-
 5 files changed, 35 insertions(+), 1 deletion(-)

diff --git a/tools/libxc/xc_flask.c b/tools/libxc/xc_flask.c
index 80c5a2d..face1e0 100644
--- a/tools/libxc/xc_flask.c
+++ b/tools/libxc/xc_flask.c
@@ -422,6 +422,16 @@ int xc_flask_setavc_threshold(xc_interface *xch, int threshold)
     return xc_flask_op(xch, &op);
 }
 
+int xc_flask_relabel_domain(xc_interface *xch, int domid, uint32_t sid)
+{
+    DECLARE_FLASK_OP;
+    op.cmd = FLASK_RELABEL_DOMAIN;
+    op.u.relabel.domid = domid;
+    op.u.relabel.sid = sid;
+
+    return xc_flask_op(xch, &op);
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/tools/libxc/xenctrl.h b/tools/libxc/xenctrl.h
index b7741ca..0d595a0 100644
--- a/tools/libxc/xenctrl.h
+++ b/tools/libxc/xenctrl.h
@@ -2173,6 +2173,7 @@ int xc_flask_policyvers(xc_interface *xc_handle);
 int xc_flask_avc_hashstats(xc_interface *xc_handle, char *buf, int size);
 int xc_flask_getavc_threshold(xc_interface *xc_handle);
 int xc_flask_setavc_threshold(xc_interface *xc_handle, int threshold);
+int xc_flask_relabel_domain(xc_interface *xch, int domid, uint32_t sid);
 
 struct elf_binary;
 void xc_elf_set_logfile(xc_interface *xch, struct elf_binary *elf,
diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index ef17f05..6d7bf4e 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -1126,6 +1126,10 @@ static void domcreate_complete(libxl__egc *egc,
                                int rc)
 {
     STATE_AO_GC(dcs->ao);
+    libxl_domain_config *const d_config = dcs->guest_config;
+
+    if (!rc && d_config->b_info.exec_ssidref)
+        rc = xc_flask_relabel_domain(CTX->xch, dcs->guest_domid, d_config->b_info.exec_ssidref);
 
     if (rc) {
         if (dcs->guest_domid) {
diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
index 6d5c578..bc11591 100644
--- a/tools/libxl/libxl_types.idl
+++ b/tools/libxl/libxl_types.idl
@@ -262,6 +262,7 @@ libxl_domain_build_info = Struct("domain_build_info",[
     ("video_memkb",     MemKB),
     ("shadow_memkb",    MemKB),
     ("rtc_timeoffset",  uint32),
+    ("exec_ssidref",    uint32),
     ("localtime",       libxl_defbool),
     ("disable_migrate", libxl_defbool),
     ("cpuid",           libxl_cpuid_policy_list),
diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index 2d6ab97..9b5f291 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -595,16 +595,34 @@ static void parse_config_data(const char *config_source,
         exit(1);
     }
 
-    if (!xlu_cfg_get_string (config, "seclabel", &buf, 0)) {
+    if (!xlu_cfg_get_string (config, "init_seclabel", &buf, 0)) {
         e = libxl_flask_context_to_sid(ctx, (char *)buf, strlen(buf),
                                     &c_info->ssidref);
         if (e) {
             if (errno == ENOSYS) {
+                fprintf(stderr, "XSM Disabled: init_seclabel not supported\n");
+            } else {
+                fprintf(stderr, "Invalid init_seclabel: %s\n", buf);
+                exit(1);
+            }
+        }
+    }
+
+    if (!xlu_cfg_get_string (config, "seclabel", &buf, 0)) {
+        uint32_t ssidref;
+        e = libxl_flask_context_to_sid(ctx, (char *)buf, strlen(buf),
+                                    &ssidref);
+        if (e) {
+            if (errno == ENOSYS) {
                 fprintf(stderr, "XSM Disabled: seclabel not supported\n");
             } else {
                 fprintf(stderr, "Invalid seclabel: %s\n", buf);
                 exit(1);
             }
+        } else if (c_info->ssidref) {
+            b_info->exec_ssidref = ssidref;
+        } else {
+            c_info->ssidref = ssidref;
         }
     }
 
-- 
1.7.11.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 10 19:50:01 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Sep 2012 19:50:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TB9zL-0001Af-G6; Mon, 10 Sep 2012 19:49:43 +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 1TB9zJ-00019X-PI
	for xen-devel@lists.xen.org; Mon, 10 Sep 2012 19:49:41 +0000
Received: from [85.158.143.99:27921] by server-3.bemta-4.messagelabs.com id
	EF/C7-08232-5544E405; Mon, 10 Sep 2012 19:49:41 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-3.tower-216.messagelabs.com!1347306579!29003656!1
X-Originating-IP: [63.239.67.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18551 invoked from network); 10 Sep 2012 19:49:40 -0000
Received: from emvm-gh1-uea09.nsa.gov (HELO nsa.gov) (63.239.67.10)
	by server-3.tower-216.messagelabs.com with SMTP;
	10 Sep 2012 19:49:40 -0000
X-TM-IMSS-Message-ID: <3066ccb2000f225d@nsa.gov>
Received: from tarius.tycho.ncsc.mil ([144.51.3.1]) by nsa.gov
	([63.239.67.10]) with ESMTP (TREND IMSS SMTP Service 7.1) id
	3066ccb2000f225d ; Mon, 10 Sep 2012 15:51:50 -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 q8AJna3h027796; 
	Mon, 10 Sep 2012 15:49:37 -0400
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xen.org
Date: Mon, 10 Sep 2012 15:48:58 -0400
Message-Id: <1347306553-20980-6-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.11.4
In-Reply-To: <1347306553-20980-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1347306553-20980-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	Ian Jackson <ian.jackson@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH 05/20] libxl: introduce XSM relabel on build
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Allow a domain to be built under one security label and run using a
different label. This can be used to prevent the domain builder or
control domain from having the ability to access a guest domain's memory
via map_foreign_range except during the build process where this is
required.

Note: this does not provide complete protection from a malicious dom0;
mappings created during the build process may persist after the relabel,
and could be used to indirectly access the guest's memory.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: Ian Campbell <ian.campbell@citrix.com>
---
 tools/libxc/xc_flask.c      | 10 ++++++++++
 tools/libxc/xenctrl.h       |  1 +
 tools/libxl/libxl_create.c  |  4 ++++
 tools/libxl/libxl_types.idl |  1 +
 tools/libxl/xl_cmdimpl.c    | 20 +++++++++++++++++++-
 5 files changed, 35 insertions(+), 1 deletion(-)

diff --git a/tools/libxc/xc_flask.c b/tools/libxc/xc_flask.c
index 80c5a2d..face1e0 100644
--- a/tools/libxc/xc_flask.c
+++ b/tools/libxc/xc_flask.c
@@ -422,6 +422,16 @@ int xc_flask_setavc_threshold(xc_interface *xch, int threshold)
     return xc_flask_op(xch, &op);
 }
 
+int xc_flask_relabel_domain(xc_interface *xch, int domid, uint32_t sid)
+{
+    DECLARE_FLASK_OP;
+    op.cmd = FLASK_RELABEL_DOMAIN;
+    op.u.relabel.domid = domid;
+    op.u.relabel.sid = sid;
+
+    return xc_flask_op(xch, &op);
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/tools/libxc/xenctrl.h b/tools/libxc/xenctrl.h
index b7741ca..0d595a0 100644
--- a/tools/libxc/xenctrl.h
+++ b/tools/libxc/xenctrl.h
@@ -2173,6 +2173,7 @@ int xc_flask_policyvers(xc_interface *xc_handle);
 int xc_flask_avc_hashstats(xc_interface *xc_handle, char *buf, int size);
 int xc_flask_getavc_threshold(xc_interface *xc_handle);
 int xc_flask_setavc_threshold(xc_interface *xc_handle, int threshold);
+int xc_flask_relabel_domain(xc_interface *xch, int domid, uint32_t sid);
 
 struct elf_binary;
 void xc_elf_set_logfile(xc_interface *xch, struct elf_binary *elf,
diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index ef17f05..6d7bf4e 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -1126,6 +1126,10 @@ static void domcreate_complete(libxl__egc *egc,
                                int rc)
 {
     STATE_AO_GC(dcs->ao);
+    libxl_domain_config *const d_config = dcs->guest_config;
+
+    if (!rc && d_config->b_info.exec_ssidref)
+        rc = xc_flask_relabel_domain(CTX->xch, dcs->guest_domid, d_config->b_info.exec_ssidref);
 
     if (rc) {
         if (dcs->guest_domid) {
diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
index 6d5c578..bc11591 100644
--- a/tools/libxl/libxl_types.idl
+++ b/tools/libxl/libxl_types.idl
@@ -262,6 +262,7 @@ libxl_domain_build_info = Struct("domain_build_info",[
     ("video_memkb",     MemKB),
     ("shadow_memkb",    MemKB),
     ("rtc_timeoffset",  uint32),
+    ("exec_ssidref",    uint32),
     ("localtime",       libxl_defbool),
     ("disable_migrate", libxl_defbool),
     ("cpuid",           libxl_cpuid_policy_list),
diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index 2d6ab97..9b5f291 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -595,16 +595,34 @@ static void parse_config_data(const char *config_source,
         exit(1);
     }
 
-    if (!xlu_cfg_get_string (config, "seclabel", &buf, 0)) {
+    if (!xlu_cfg_get_string (config, "init_seclabel", &buf, 0)) {
         e = libxl_flask_context_to_sid(ctx, (char *)buf, strlen(buf),
                                     &c_info->ssidref);
         if (e) {
             if (errno == ENOSYS) {
+                fprintf(stderr, "XSM Disabled: init_seclabel not supported\n");
+            } else {
+                fprintf(stderr, "Invalid init_seclabel: %s\n", buf);
+                exit(1);
+            }
+        }
+    }
+
+    if (!xlu_cfg_get_string (config, "seclabel", &buf, 0)) {
+        uint32_t ssidref;
+        e = libxl_flask_context_to_sid(ctx, (char *)buf, strlen(buf),
+                                    &ssidref);
+        if (e) {
+            if (errno == ENOSYS) {
                 fprintf(stderr, "XSM Disabled: seclabel not supported\n");
             } else {
                 fprintf(stderr, "Invalid seclabel: %s\n", buf);
                 exit(1);
             }
+        } else if (c_info->ssidref) {
+            b_info->exec_ssidref = ssidref;
+        } else {
+            c_info->ssidref = ssidref;
         }
     }
 
-- 
1.7.11.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 10 19:50:02 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Sep 2012 19:50: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 1TB9zS-0001IH-Ap; Mon, 10 Sep 2012 19:49:50 +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 1TB9zP-0001Df-FY
	for xen-devel@lists.xen.org; Mon, 10 Sep 2012 19:49:47 +0000
Received: from [85.158.143.99:4314] by server-1.bemta-4.messagelabs.com id
	B3/15-12504-A544E405; Mon, 10 Sep 2012 19:49:46 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-6.tower-216.messagelabs.com!1347306583!22574390!1
X-Originating-IP: [63.239.67.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16981 invoked from network); 10 Sep 2012 19:49:44 -0000
Received: from emvm-gh1-uea09.nsa.gov (HELO nsa.gov) (63.239.67.10)
	by server-6.tower-216.messagelabs.com with SMTP;
	10 Sep 2012 19:49:44 -0000
X-TM-IMSS-Message-ID: <3066d8d2000f2268@nsa.gov>
Received: from tarius.tycho.ncsc.mil ([144.51.3.1]) by nsa.gov
	([63.239.67.10]) with ESMTP (TREND IMSS SMTP Service 7.1) id
	3066d8d2000f2268 ; Mon, 10 Sep 2012 15:51:53 -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 q8AJna3r027796; 
	Mon, 10 Sep 2012 15:49:41 -0400
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xen.org
Date: Mon, 10 Sep 2012 15:49:08 -0400
Message-Id: <1347306553-20980-16-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.11.4
In-Reply-To: <1347306553-20980-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1347306553-20980-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: [Xen-devel] [PATCH 15/20] xsm: remove unneeded xsm_call 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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 xen/include/xsm/xsm.h | 258 +++++++++++++++++++++++++-------------------------
 1 file changed, 128 insertions(+), 130 deletions(-)

diff --git a/xen/include/xsm/xsm.h b/xen/include/xsm/xsm.h
index ff76cae..8226d93 100644
--- a/xen/include/xsm/xsm.h
+++ b/xen/include/xsm/xsm.h
@@ -21,8 +21,6 @@
 typedef void xsm_op_t;
 DEFINE_XEN_GUEST_HANDLE(xsm_op_t);
 
-#define xsm_call(fn) xsm_ops->fn
-
 /* policy magic number (defined by XSM_MAGIC) */
 typedef u32 xsm_magic_t;
 #ifndef XSM_MAGIC
@@ -197,418 +195,418 @@ extern struct xsm_operations *xsm_ops;
 static inline void xsm_security_domaininfo (struct domain *d,
                                         struct xen_domctl_getdomaininfo *info)
 {
-    (void)xsm_call(security_domaininfo(d, info));
+    xsm_ops->security_domaininfo(d, info);
 }
 
 static inline int xsm_setvcpucontext(struct domain *d)
 {
-    return xsm_call(setvcpucontext(d));
+    return xsm_ops->setvcpucontext(d);
 }
 
 static inline int xsm_pausedomain (struct domain *d)
 {
-    return xsm_call(pausedomain(d));
+    return xsm_ops->pausedomain(d);
 }
 
 static inline int xsm_unpausedomain (struct domain *d)
 {
-    return xsm_call(unpausedomain(d));
+    return xsm_ops->unpausedomain(d);
 }
 
 static inline int xsm_resumedomain (struct domain *d)
 {
-    return xsm_call(resumedomain(d));
+    return xsm_ops->resumedomain(d);
 }
 
 static inline int xsm_domain_create (struct domain *d, u32 ssidref)
 {
-    return xsm_call(domain_create(d, ssidref));
+    return xsm_ops->domain_create(d, ssidref);
 }
 
 static inline int xsm_max_vcpus(struct domain *d)
 {
-    return xsm_call(max_vcpus(d));
+    return xsm_ops->max_vcpus(d);
 }
 
 static inline int xsm_destroydomain (struct domain *d)
 {
-    return xsm_call(destroydomain(d));
+    return xsm_ops->destroydomain(d);
 }
 
 static inline int xsm_vcpuaffinity (int cmd, struct domain *d)
 {
-    return xsm_call(vcpuaffinity(cmd, d));
+    return xsm_ops->vcpuaffinity(cmd, d);
 }
 
 static inline int xsm_scheduler (struct domain *d)
 {
-    return xsm_call(scheduler(d));
+    return xsm_ops->scheduler(d);
 }
 
 static inline int xsm_getdomaininfo (struct domain *d)
 {
-    return xsm_call(getdomaininfo(d));
+    return xsm_ops->getdomaininfo(d);
 }
 
 static inline int xsm_getvcpucontext (struct domain *d)
 {
-    return xsm_call(getvcpucontext(d));
+    return xsm_ops->getvcpucontext(d);
 }
 
 static inline int xsm_getvcpuinfo (struct domain *d)
 {
-    return xsm_call(getvcpuinfo(d));
+    return xsm_ops->getvcpuinfo(d);
 }
 
 static inline int xsm_domain_settime (struct domain *d)
 {
-    return xsm_call(domain_settime(d));
+    return xsm_ops->domain_settime(d);
 }
 
 static inline int xsm_set_target (struct domain *d, struct domain *e)
 {
-    return xsm_call(set_target(d, e));
+    return xsm_ops->set_target(d, e);
 }
 
 static inline int xsm_domctl (struct domain *d, int cmd)
 {
-    return xsm_call(domctl(d, cmd));
+    return xsm_ops->domctl(d, cmd);
 }
 
 static inline int xsm_set_virq_handler (struct domain *d, uint32_t virq)
 {
-    return xsm_call(set_virq_handler(d, virq));
+    return xsm_ops->set_virq_handler(d, virq);
 }
 
 static inline int xsm_tbufcontrol (void)
 {
-    return xsm_call(tbufcontrol());
+    return xsm_ops->tbufcontrol();
 }
 
 static inline int xsm_readconsole (uint32_t clear)
 {
-    return xsm_call(readconsole(clear));
+    return xsm_ops->readconsole(clear);
 }
 
 static inline int xsm_sched_id (void)
 {
-    return xsm_call(sched_id());
+    return xsm_ops->sched_id();
 }
 
 static inline int xsm_setdomainmaxmem (struct domain *d)
 {
-    return xsm_call(setdomainmaxmem(d));
+    return xsm_ops->setdomainmaxmem(d);
 }
 
 static inline int xsm_setdomainhandle (struct domain *d)
 {
-    return xsm_call(setdomainhandle(d));
+    return xsm_ops->setdomainhandle(d);
 }
 
 static inline int xsm_setdebugging (struct domain *d)
 {
-    return xsm_call(setdebugging(d));
+    return xsm_ops->setdebugging(d);
 }
 
 static inline int xsm_debug_op (struct domain *d)
 {
-    return xsm_call(debug_op(d));
+    return xsm_ops->debug_op(d);
 }
 
 static inline int xsm_perfcontrol (void)
 {
-    return xsm_call(perfcontrol());
+    return xsm_ops->perfcontrol();
 }
 
 static inline int xsm_debug_keys (void)
 {
-    return xsm_call(debug_keys());
+    return xsm_ops->debug_keys();
 }
 
 static inline int xsm_availheap (void)
 {
-    return xsm_call(availheap());
+    return xsm_ops->availheap();
 }
 
 static inline int xsm_getcpuinfo (void)
 {
-    return xsm_call(getcpuinfo());
+    return xsm_ops->getcpuinfo();
 }
 
 static inline int xsm_get_pmstat(void)
 {
-    return xsm_call(get_pmstat());
+    return xsm_ops->get_pmstat();
 }
 
 static inline int xsm_setpminfo(void)
 {
-    return xsm_call(setpminfo());
+    return xsm_ops->setpminfo();
 }
 
 static inline int xsm_pm_op(void)
 {
-    return xsm_call(pm_op());
+    return xsm_ops->pm_op();
 }
 
 static inline int xsm_do_mca(void)
 {
-    return xsm_call(do_mca());
+    return xsm_ops->do_mca();
 }
 
 static inline int xsm_evtchn_unbound (struct domain *d1, struct evtchn *chn,
                                                                     domid_t id2)
 {
-    return xsm_call(evtchn_unbound(d1, chn, id2));
+    return xsm_ops->evtchn_unbound(d1, chn, id2);
 }
 
 static inline int xsm_evtchn_interdomain (struct domain *d1, 
                 struct evtchn *chan1, struct domain *d2, struct evtchn *chan2)
 {
-    return xsm_call(evtchn_interdomain(d1, chan1, d2, chan2));
+    return xsm_ops->evtchn_interdomain(d1, chan1, d2, chan2);
 }
 
 static inline void xsm_evtchn_close_post (struct evtchn *chn)
 {
-    (void)xsm_call(evtchn_close_post(chn));
+    xsm_ops->evtchn_close_post(chn);
 }
 
 static inline int xsm_evtchn_send (struct domain *d, struct evtchn *chn)
 {
-    return xsm_call(evtchn_send(d, chn));
+    return xsm_ops->evtchn_send(d, chn);
 }
 
 static inline int xsm_evtchn_status (struct domain *d, struct evtchn *chn)
 {
-    return xsm_call(evtchn_status(d, chn));
+    return xsm_ops->evtchn_status(d, chn);
 }
 
 static inline int xsm_evtchn_reset (struct domain *d1, struct domain *d2)
 {
-    return xsm_call(evtchn_reset(d1, d2));
+    return xsm_ops->evtchn_reset(d1, d2);
 }
 
 static inline int xsm_grant_mapref (struct domain *d1, struct domain *d2,
                                                                 uint32_t flags)
 {
-    return xsm_call(grant_mapref(d1, d2, flags));
+    return xsm_ops->grant_mapref(d1, d2, flags);
 }
 
 static inline int xsm_grant_unmapref (struct domain *d1, struct domain *d2)
 {
-    return xsm_call(grant_unmapref(d1, d2));
+    return xsm_ops->grant_unmapref(d1, d2);
 }
 
 static inline int xsm_grant_setup (struct domain *d1, struct domain *d2)
 {
-    return xsm_call(grant_setup(d1, d2));
+    return xsm_ops->grant_setup(d1, d2);
 }
 
 static inline int xsm_grant_transfer (struct domain *d1, struct domain *d2)
 {
-    return xsm_call(grant_transfer(d1, d2));
+    return xsm_ops->grant_transfer(d1, d2);
 }
 
 static inline int xsm_grant_copy (struct domain *d1, struct domain *d2)
 {
-    return xsm_call(grant_copy(d1, d2));
+    return xsm_ops->grant_copy(d1, d2);
 }
 
 static inline int xsm_grant_query_size (struct domain *d1, struct domain *d2)
 {
-    return xsm_call(grant_query_size(d1, d2));
+    return xsm_ops->grant_query_size(d1, d2);
 }
 
 static inline int xsm_alloc_security_domain (struct domain *d)
 {
-    return xsm_call(alloc_security_domain(d));
+    return xsm_ops->alloc_security_domain(d);
 }
 
 static inline void xsm_free_security_domain (struct domain *d)
 {
-    (void)xsm_call(free_security_domain(d));
+    xsm_ops->free_security_domain(d);
 }
 
 static inline int xsm_alloc_security_evtchn (struct evtchn *chn)
 {
-    return xsm_call(alloc_security_evtchn(chn));
+    return xsm_ops->alloc_security_evtchn(chn);
 }
 
 static inline void xsm_free_security_evtchn (struct evtchn *chn)
 {
-    (void)xsm_call(free_security_evtchn(chn));
+    xsm_ops->free_security_evtchn(chn);
 }
 
 static inline char *xsm_show_security_evtchn (struct domain *d, const struct evtchn *chn)
 {
-    return xsm_call(show_security_evtchn(d, chn));
+    return xsm_ops->show_security_evtchn(d, chn);
 }
 
 static inline int xsm_get_pod_target (struct domain *d)
 {
-    return xsm_call(get_pod_target(d));
+    return xsm_ops->get_pod_target(d);
 }
 
 static inline int xsm_set_pod_target (struct domain *d)
 {
-    return xsm_call(set_pod_target(d));
+    return xsm_ops->set_pod_target(d);
 }
 
 static inline int xsm_memory_adjust_reservation (struct domain *d1, struct
                                                                     domain *d2)
 {
-    return xsm_call(memory_adjust_reservation(d1, d2));
+    return xsm_ops->memory_adjust_reservation(d1, d2);
 }
 
 static inline int xsm_memory_stat_reservation (struct domain *d1,
                                                             struct domain *d2)
 {
-    return xsm_call(memory_stat_reservation(d1, d2));
+    return xsm_ops->memory_stat_reservation(d1, d2);
 }
 
 static inline int xsm_memory_pin_page(struct domain *d1, struct domain *d2,
                                       struct page_info *page)
 {
-    return xsm_call(memory_pin_page(d1, d2, page));
+    return xsm_ops->memory_pin_page(d1, d2, page);
 }
 
 static inline int xsm_remove_from_physmap(struct domain *d1, struct domain *d2)
 {
-    return xsm_call(remove_from_physmap(d1, d2));
+    return xsm_ops->remove_from_physmap(d1, d2);
 }
 
 static inline int xsm_console_io (struct domain *d, int cmd)
 {
-    return xsm_call(console_io(d, cmd));
+    return xsm_ops->console_io(d, cmd);
 }
 
 static inline int xsm_profile (struct domain *d, int op)
 {
-    return xsm_call(profile(d, op));
+    return xsm_ops->profile(d, op);
 }
 
 static inline int xsm_kexec (void)
 {
-    return xsm_call(kexec());
+    return xsm_ops->kexec();
 }
 
 static inline int xsm_schedop_shutdown (struct domain *d1, struct domain *d2)
 {
-    return xsm_call(schedop_shutdown(d1, d2));
+    return xsm_ops->schedop_shutdown(d1, d2);
 }
 
 static inline char *xsm_show_irq_sid (int irq)
 {
-    return xsm_call(show_irq_sid(irq));
+    return xsm_ops->show_irq_sid(irq);
 }
 
 static inline int xsm_map_domain_pirq (struct domain *d, int irq, void *data)
 {
-    return xsm_call(map_domain_pirq(d, irq, data));
+    return xsm_ops->map_domain_pirq(d, irq, data);
 }
 
 static inline int xsm_unmap_domain_pirq (struct domain *d, int irq)
 {
-    return xsm_call(unmap_domain_pirq(d, irq));
+    return xsm_ops->unmap_domain_pirq(d, irq);
 }
 
 static inline int xsm_irq_permission (struct domain *d, int pirq, uint8_t allow)
 {
-    return xsm_call(irq_permission(d, pirq, allow));
+    return xsm_ops->irq_permission(d, pirq, allow);
 }
 
 static inline int xsm_iomem_permission (struct domain *d, uint64_t s, uint64_t e, uint8_t allow)
 {
-    return xsm_call(iomem_permission(d, s, e, allow));
+    return xsm_ops->iomem_permission(d, s, e, allow);
 }
 
 static inline int xsm_iomem_mapping (struct domain *d, uint64_t s, uint64_t e, uint8_t allow)
 {
-    return xsm_call(iomem_mapping(d, s, e, allow));
+    return xsm_ops->iomem_mapping(d, s, e, allow);
 }
 
 static inline int xsm_pci_config_permission (struct domain *d, uint32_t machine_bdf, uint16_t start, uint16_t end, uint8_t access)
 {
-    return xsm_call(pci_config_permission(d, machine_bdf, start, end, access));
+    return xsm_ops->pci_config_permission(d, machine_bdf, start, end, access);
 }
 
 static inline int xsm_get_device_group(uint32_t machine_bdf)
 {
-    return xsm_call(get_device_group(machine_bdf));
+    return xsm_ops->get_device_group(machine_bdf);
 }
 
 static inline int xsm_test_assign_device(uint32_t machine_bdf)
 {
-    return xsm_call(test_assign_device(machine_bdf));
+    return xsm_ops->test_assign_device(machine_bdf);
 }
 
 static inline int xsm_assign_device(struct domain *d, uint32_t machine_bdf)
 {
-    return xsm_call(assign_device(d, machine_bdf));
+    return xsm_ops->assign_device(d, machine_bdf);
 }
 
 static inline int xsm_deassign_device(struct domain *d, uint32_t machine_bdf)
 {
-    return xsm_call(deassign_device(d, machine_bdf));
+    return xsm_ops->deassign_device(d, machine_bdf);
 }
 
 static inline int xsm_resource_plug_pci (uint32_t machine_bdf)
 {
-    return xsm_call(resource_plug_pci(machine_bdf));
+    return xsm_ops->resource_plug_pci(machine_bdf);
 }
 
 static inline int xsm_resource_unplug_pci (uint32_t machine_bdf)
 {
-    return xsm_call(resource_unplug_pci(machine_bdf));
+    return xsm_ops->resource_unplug_pci(machine_bdf);
 }
 
 static inline int xsm_resource_plug_core (void)
 {
-    return xsm_call(resource_plug_core());
+    return xsm_ops->resource_plug_core();
 }
 
 static inline int xsm_resource_unplug_core (void)
 {
-    return xsm_call(resource_unplug_core());
+    return xsm_ops->resource_unplug_core();
 }
 
 static inline int xsm_resource_setup_pci (uint32_t machine_bdf)
 {
-    return xsm_call(resource_setup_pci(machine_bdf));
+    return xsm_ops->resource_setup_pci(machine_bdf);
 }
 
 static inline int xsm_resource_setup_gsi (int gsi)
 {
-    return xsm_call(resource_setup_gsi(gsi));
+    return xsm_ops->resource_setup_gsi(gsi);
 }
 
 static inline int xsm_resource_setup_misc (void)
 {
-    return xsm_call(resource_setup_misc());
+    return xsm_ops->resource_setup_misc();
 }
 
 static inline int xsm_page_offline(uint32_t cmd)
 {
-    return xsm_call(page_offline(cmd));
+    return xsm_ops->page_offline(cmd);
 }
 
 static inline int xsm_lockprof(void)
 {
-    return xsm_call(lockprof());
+    return xsm_ops->lockprof();
 }
 
 static inline int xsm_cpupool_op(void)
 {
-    return xsm_call(cpupool_op());
+    return xsm_ops->cpupool_op();
 }
 
 static inline int xsm_sched_op(void)
 {
-    return xsm_call(sched_op());
+    return xsm_ops->sched_op();
 }
 
 static inline int xsm_tmem_control(uint32_t subop)
 {
-    return xsm_call(tmem_control(subop));
+    return xsm_ops->tmem_control(subop);
 }
 
 static inline long xsm___do_xsm_op (XEN_GUEST_HANDLE(xsm_op_t) op)
@@ -619,236 +617,236 @@ static inline long xsm___do_xsm_op (XEN_GUEST_HANDLE(xsm_op_t) op)
 #ifdef CONFIG_X86
 static inline int xsm_shadow_control (struct domain *d, uint32_t op)
 {
-    return xsm_call(shadow_control(d, op));
+    return xsm_ops->shadow_control(d, op);
 }
 
 static inline int xsm_getpageframeinfo (struct domain *d)
 {
-    return xsm_call(getpageframeinfo(d));
+    return xsm_ops->getpageframeinfo(d);
 }
 
 static inline int xsm_set_cpuid (struct domain *d)
 {
-    return xsm_call(set_cpuid(d));
+    return xsm_ops->set_cpuid(d);
 }
 
 static inline int xsm_gettscinfo (struct domain *d)
 {
-    return xsm_call(gettscinfo(d));
+    return xsm_ops->gettscinfo(d);
 }
 
 static inline int xsm_settscinfo (struct domain *d)
 {
-    return xsm_call(settscinfo(d));
+    return xsm_ops->settscinfo(d);
 }
 
 static inline int xsm_getmemlist (struct domain *d)
 {
-    return xsm_call(getmemlist(d));
+    return xsm_ops->getmemlist(d);
 }
 
 static inline int xsm_hypercall_init (struct domain *d)
 {
-    return xsm_call(hypercall_init(d));
+    return xsm_ops->hypercall_init(d);
 }
 
 static inline int xsm_hvmcontext (struct domain *d, uint32_t cmd)
 {
-    return xsm_call(hvmcontext(d, cmd));
+    return xsm_ops->hvmcontext(d, cmd);
 }
 
 static inline int xsm_address_size (struct domain *d, uint32_t cmd)
 {
-    return xsm_call(address_size(d, cmd));
+    return xsm_ops->address_size(d, cmd);
 }
 
 static inline int xsm_machine_address_size (struct domain *d, uint32_t cmd)
 {
-    return xsm_call(machine_address_size(d, cmd));
+    return xsm_ops->machine_address_size(d, cmd);
 }
 
 static inline int xsm_hvm_param (struct domain *d, unsigned long op)
 {
-    return xsm_call(hvm_param(d, op));
+    return xsm_ops->hvm_param(d, op);
 }
 
 static inline int xsm_hvm_set_pci_intx_level (struct domain *d)
 {
-    return xsm_call(hvm_set_pci_intx_level(d));
+    return xsm_ops->hvm_set_pci_intx_level(d);
 }
 
 static inline int xsm_hvm_set_isa_irq_level (struct domain *d)
 {
-    return xsm_call(hvm_set_isa_irq_level(d));
+    return xsm_ops->hvm_set_isa_irq_level(d);
 }
 
 static inline int xsm_hvm_set_pci_link_route (struct domain *d)
 {
-    return xsm_call(hvm_set_pci_link_route(d));
+    return xsm_ops->hvm_set_pci_link_route(d);
 }
 
 static inline int xsm_hvm_inject_msi (struct domain *d)
 {
-    return xsm_call(hvm_inject_msi(d));
+    return xsm_ops->hvm_inject_msi(d);
 }
 
 static inline int xsm_mem_event_setup (struct domain *d)
 {
-    return xsm_call(mem_event_setup(d));
+    return xsm_ops->mem_event_setup(d);
 }
 
 static inline int xsm_mem_event_control (struct domain *d, int mode, int op)
 {
-    return xsm_call(mem_event_control(d, mode, op));
+    return xsm_ops->mem_event_control(d, mode, op);
 }
 
 static inline int xsm_mem_event_op (struct domain *d, int op)
 {
-    return xsm_call(mem_event_op(d, op));
+    return xsm_ops->mem_event_op(d, op);
 }
 
 static inline int xsm_mem_sharing (struct domain *d)
 {
-    return xsm_call(mem_sharing(d));
+    return xsm_ops->mem_sharing(d);
 }
 
 static inline int xsm_mem_sharing_op (struct domain *d, struct domain *cd, int op)
 {
-    return xsm_call(mem_sharing_op(d, cd, op));
+    return xsm_ops->mem_sharing_op(d, cd, op);
 }
 
 static inline int xsm_audit_p2m (struct domain *d)
 {
-    return xsm_call(audit_p2m(d));
+    return xsm_ops->audit_p2m(d);
 }
 
 static inline int xsm_apic (struct domain *d, int cmd)
 {
-    return xsm_call(apic(d, cmd));
+    return xsm_ops->apic(d, cmd);
 }
 
 static inline int xsm_xen_settime (void)
 {
-    return xsm_call(xen_settime());
+    return xsm_ops->xen_settime();
 }
 
 static inline int xsm_memtype (uint32_t access)
 {
-    return xsm_call(memtype(access));
+    return xsm_ops->memtype(access);
 }
 
 static inline int xsm_microcode (void)
 {
-    return xsm_call(microcode());
+    return xsm_ops->microcode();
 }
 
 static inline int xsm_physinfo (void)
 {
-    return xsm_call(physinfo());
+    return xsm_ops->physinfo();
 }
 
 static inline int xsm_platform_quirk (uint32_t quirk)
 {
-    return xsm_call(platform_quirk(quirk));
+    return xsm_ops->platform_quirk(quirk);
 }
 
 static inline int xsm_firmware_info (void)
 {
-    return xsm_call(firmware_info());
+    return xsm_ops->firmware_info();
 }
 
 static inline int xsm_efi_call (void)
 {
-    return xsm_call(efi_call());
+    return xsm_ops->efi_call();
 }
 
 static inline int xsm_acpi_sleep (void)
 {
-    return xsm_call(acpi_sleep());
+    return xsm_ops->acpi_sleep();
 }
 
 static inline int xsm_change_freq (void)
 {
-    return xsm_call(change_freq());
+    return xsm_ops->change_freq();
 }
 
 static inline int xsm_getidletime (void)
 {
-    return xsm_call(getidletime());
+    return xsm_ops->getidletime();
 }
 
 static inline int xsm_machine_memory_map(void)
 {
-    return xsm_call(machine_memory_map());
+    return xsm_ops->machine_memory_map();
 }
 
 static inline int xsm_domain_memory_map(struct domain *d)
 {
-    return xsm_call(domain_memory_map(d));
+    return xsm_ops->domain_memory_map(d);
 }
 
 static inline int xsm_mmu_normal_update (struct domain *d, struct domain *t,
                                          struct domain *f, intpte_t fpte)
 {
-    return xsm_call(mmu_normal_update(d, t, f, fpte));
+    return xsm_ops->mmu_normal_update(d, t, f, fpte);
 }
 
 static inline int xsm_mmu_machphys_update (struct domain *d1, struct domain *d2,
                                            unsigned long mfn)
 {
-    return xsm_call(mmu_machphys_update(d1, d2, mfn));
+    return xsm_ops->mmu_machphys_update(d1, d2, mfn);
 }
 
 static inline int xsm_update_va_mapping(struct domain *d, struct domain *f, 
                                                             l1_pgentry_t pte)
 {
-    return xsm_call(update_va_mapping(d, f, pte));
+    return xsm_ops->update_va_mapping(d, f, pte);
 }
 
 static inline int xsm_add_to_physmap(struct domain *d1, struct domain *d2)
 {
-    return xsm_call(add_to_physmap(d1, d2));
+    return xsm_ops->add_to_physmap(d1, d2);
 }
 
 static inline int xsm_sendtrigger(struct domain *d)
 {
-    return xsm_call(sendtrigger(d));
+    return xsm_ops->sendtrigger(d);
 }
 
 static inline int xsm_bind_pt_irq(struct domain *d, 
                                                 struct xen_domctl_bind_pt_irq *bind)
 {
-    return xsm_call(bind_pt_irq(d, bind));
+    return xsm_ops->bind_pt_irq(d, bind);
 }
 
 static inline int xsm_unbind_pt_irq(struct domain *d,
                                                 struct xen_domctl_bind_pt_irq *bind)
 {
-    return xsm_call(unbind_pt_irq(d, bind));
+    return xsm_ops->unbind_pt_irq(d, bind);
 }
 
 static inline int xsm_pin_mem_cacheattr(struct domain *d)
 {
-    return xsm_call(pin_mem_cacheattr(d));
+    return xsm_ops->pin_mem_cacheattr(d);
 }
 
 static inline int xsm_ext_vcpucontext(struct domain *d, uint32_t cmd)
 {
-    return xsm_call(ext_vcpucontext(d, cmd));
+    return xsm_ops->ext_vcpucontext(d, cmd);
 }
 static inline int xsm_vcpuextstate(struct domain *d, uint32_t cmd)
 {
-    return xsm_call(vcpuextstate(d, cmd));
+    return xsm_ops->vcpuextstate(d, cmd);
 }
 
 static inline int xsm_ioport_permission (struct domain *d, uint32_t s, uint32_t e, uint8_t allow)
 {
-    return xsm_call(ioport_permission(d, s, e, allow));
+    return xsm_ops->ioport_permission(d, s, e, allow);
 }
 
 static inline int xsm_ioport_mapping (struct domain *d, uint32_t s, uint32_t e, uint8_t allow)
 {
-    return xsm_call(ioport_mapping(d, s, e, allow));
+    return xsm_ops->ioport_mapping(d, s, e, allow);
 }
 #endif /* CONFIG_X86 */
 
-- 
1.7.11.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 10 19:50:02 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Sep 2012 19:50: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 1TB9zS-0001IH-Ap; Mon, 10 Sep 2012 19:49:50 +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 1TB9zP-0001Df-FY
	for xen-devel@lists.xen.org; Mon, 10 Sep 2012 19:49:47 +0000
Received: from [85.158.143.99:4314] by server-1.bemta-4.messagelabs.com id
	B3/15-12504-A544E405; Mon, 10 Sep 2012 19:49:46 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-6.tower-216.messagelabs.com!1347306583!22574390!1
X-Originating-IP: [63.239.67.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16981 invoked from network); 10 Sep 2012 19:49:44 -0000
Received: from emvm-gh1-uea09.nsa.gov (HELO nsa.gov) (63.239.67.10)
	by server-6.tower-216.messagelabs.com with SMTP;
	10 Sep 2012 19:49:44 -0000
X-TM-IMSS-Message-ID: <3066d8d2000f2268@nsa.gov>
Received: from tarius.tycho.ncsc.mil ([144.51.3.1]) by nsa.gov
	([63.239.67.10]) with ESMTP (TREND IMSS SMTP Service 7.1) id
	3066d8d2000f2268 ; Mon, 10 Sep 2012 15:51:53 -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 q8AJna3r027796; 
	Mon, 10 Sep 2012 15:49:41 -0400
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xen.org
Date: Mon, 10 Sep 2012 15:49:08 -0400
Message-Id: <1347306553-20980-16-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.11.4
In-Reply-To: <1347306553-20980-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1347306553-20980-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: [Xen-devel] [PATCH 15/20] xsm: remove unneeded xsm_call 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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 xen/include/xsm/xsm.h | 258 +++++++++++++++++++++++++-------------------------
 1 file changed, 128 insertions(+), 130 deletions(-)

diff --git a/xen/include/xsm/xsm.h b/xen/include/xsm/xsm.h
index ff76cae..8226d93 100644
--- a/xen/include/xsm/xsm.h
+++ b/xen/include/xsm/xsm.h
@@ -21,8 +21,6 @@
 typedef void xsm_op_t;
 DEFINE_XEN_GUEST_HANDLE(xsm_op_t);
 
-#define xsm_call(fn) xsm_ops->fn
-
 /* policy magic number (defined by XSM_MAGIC) */
 typedef u32 xsm_magic_t;
 #ifndef XSM_MAGIC
@@ -197,418 +195,418 @@ extern struct xsm_operations *xsm_ops;
 static inline void xsm_security_domaininfo (struct domain *d,
                                         struct xen_domctl_getdomaininfo *info)
 {
-    (void)xsm_call(security_domaininfo(d, info));
+    xsm_ops->security_domaininfo(d, info);
 }
 
 static inline int xsm_setvcpucontext(struct domain *d)
 {
-    return xsm_call(setvcpucontext(d));
+    return xsm_ops->setvcpucontext(d);
 }
 
 static inline int xsm_pausedomain (struct domain *d)
 {
-    return xsm_call(pausedomain(d));
+    return xsm_ops->pausedomain(d);
 }
 
 static inline int xsm_unpausedomain (struct domain *d)
 {
-    return xsm_call(unpausedomain(d));
+    return xsm_ops->unpausedomain(d);
 }
 
 static inline int xsm_resumedomain (struct domain *d)
 {
-    return xsm_call(resumedomain(d));
+    return xsm_ops->resumedomain(d);
 }
 
 static inline int xsm_domain_create (struct domain *d, u32 ssidref)
 {
-    return xsm_call(domain_create(d, ssidref));
+    return xsm_ops->domain_create(d, ssidref);
 }
 
 static inline int xsm_max_vcpus(struct domain *d)
 {
-    return xsm_call(max_vcpus(d));
+    return xsm_ops->max_vcpus(d);
 }
 
 static inline int xsm_destroydomain (struct domain *d)
 {
-    return xsm_call(destroydomain(d));
+    return xsm_ops->destroydomain(d);
 }
 
 static inline int xsm_vcpuaffinity (int cmd, struct domain *d)
 {
-    return xsm_call(vcpuaffinity(cmd, d));
+    return xsm_ops->vcpuaffinity(cmd, d);
 }
 
 static inline int xsm_scheduler (struct domain *d)
 {
-    return xsm_call(scheduler(d));
+    return xsm_ops->scheduler(d);
 }
 
 static inline int xsm_getdomaininfo (struct domain *d)
 {
-    return xsm_call(getdomaininfo(d));
+    return xsm_ops->getdomaininfo(d);
 }
 
 static inline int xsm_getvcpucontext (struct domain *d)
 {
-    return xsm_call(getvcpucontext(d));
+    return xsm_ops->getvcpucontext(d);
 }
 
 static inline int xsm_getvcpuinfo (struct domain *d)
 {
-    return xsm_call(getvcpuinfo(d));
+    return xsm_ops->getvcpuinfo(d);
 }
 
 static inline int xsm_domain_settime (struct domain *d)
 {
-    return xsm_call(domain_settime(d));
+    return xsm_ops->domain_settime(d);
 }
 
 static inline int xsm_set_target (struct domain *d, struct domain *e)
 {
-    return xsm_call(set_target(d, e));
+    return xsm_ops->set_target(d, e);
 }
 
 static inline int xsm_domctl (struct domain *d, int cmd)
 {
-    return xsm_call(domctl(d, cmd));
+    return xsm_ops->domctl(d, cmd);
 }
 
 static inline int xsm_set_virq_handler (struct domain *d, uint32_t virq)
 {
-    return xsm_call(set_virq_handler(d, virq));
+    return xsm_ops->set_virq_handler(d, virq);
 }
 
 static inline int xsm_tbufcontrol (void)
 {
-    return xsm_call(tbufcontrol());
+    return xsm_ops->tbufcontrol();
 }
 
 static inline int xsm_readconsole (uint32_t clear)
 {
-    return xsm_call(readconsole(clear));
+    return xsm_ops->readconsole(clear);
 }
 
 static inline int xsm_sched_id (void)
 {
-    return xsm_call(sched_id());
+    return xsm_ops->sched_id();
 }
 
 static inline int xsm_setdomainmaxmem (struct domain *d)
 {
-    return xsm_call(setdomainmaxmem(d));
+    return xsm_ops->setdomainmaxmem(d);
 }
 
 static inline int xsm_setdomainhandle (struct domain *d)
 {
-    return xsm_call(setdomainhandle(d));
+    return xsm_ops->setdomainhandle(d);
 }
 
 static inline int xsm_setdebugging (struct domain *d)
 {
-    return xsm_call(setdebugging(d));
+    return xsm_ops->setdebugging(d);
 }
 
 static inline int xsm_debug_op (struct domain *d)
 {
-    return xsm_call(debug_op(d));
+    return xsm_ops->debug_op(d);
 }
 
 static inline int xsm_perfcontrol (void)
 {
-    return xsm_call(perfcontrol());
+    return xsm_ops->perfcontrol();
 }
 
 static inline int xsm_debug_keys (void)
 {
-    return xsm_call(debug_keys());
+    return xsm_ops->debug_keys();
 }
 
 static inline int xsm_availheap (void)
 {
-    return xsm_call(availheap());
+    return xsm_ops->availheap();
 }
 
 static inline int xsm_getcpuinfo (void)
 {
-    return xsm_call(getcpuinfo());
+    return xsm_ops->getcpuinfo();
 }
 
 static inline int xsm_get_pmstat(void)
 {
-    return xsm_call(get_pmstat());
+    return xsm_ops->get_pmstat();
 }
 
 static inline int xsm_setpminfo(void)
 {
-    return xsm_call(setpminfo());
+    return xsm_ops->setpminfo();
 }
 
 static inline int xsm_pm_op(void)
 {
-    return xsm_call(pm_op());
+    return xsm_ops->pm_op();
 }
 
 static inline int xsm_do_mca(void)
 {
-    return xsm_call(do_mca());
+    return xsm_ops->do_mca();
 }
 
 static inline int xsm_evtchn_unbound (struct domain *d1, struct evtchn *chn,
                                                                     domid_t id2)
 {
-    return xsm_call(evtchn_unbound(d1, chn, id2));
+    return xsm_ops->evtchn_unbound(d1, chn, id2);
 }
 
 static inline int xsm_evtchn_interdomain (struct domain *d1, 
                 struct evtchn *chan1, struct domain *d2, struct evtchn *chan2)
 {
-    return xsm_call(evtchn_interdomain(d1, chan1, d2, chan2));
+    return xsm_ops->evtchn_interdomain(d1, chan1, d2, chan2);
 }
 
 static inline void xsm_evtchn_close_post (struct evtchn *chn)
 {
-    (void)xsm_call(evtchn_close_post(chn));
+    xsm_ops->evtchn_close_post(chn);
 }
 
 static inline int xsm_evtchn_send (struct domain *d, struct evtchn *chn)
 {
-    return xsm_call(evtchn_send(d, chn));
+    return xsm_ops->evtchn_send(d, chn);
 }
 
 static inline int xsm_evtchn_status (struct domain *d, struct evtchn *chn)
 {
-    return xsm_call(evtchn_status(d, chn));
+    return xsm_ops->evtchn_status(d, chn);
 }
 
 static inline int xsm_evtchn_reset (struct domain *d1, struct domain *d2)
 {
-    return xsm_call(evtchn_reset(d1, d2));
+    return xsm_ops->evtchn_reset(d1, d2);
 }
 
 static inline int xsm_grant_mapref (struct domain *d1, struct domain *d2,
                                                                 uint32_t flags)
 {
-    return xsm_call(grant_mapref(d1, d2, flags));
+    return xsm_ops->grant_mapref(d1, d2, flags);
 }
 
 static inline int xsm_grant_unmapref (struct domain *d1, struct domain *d2)
 {
-    return xsm_call(grant_unmapref(d1, d2));
+    return xsm_ops->grant_unmapref(d1, d2);
 }
 
 static inline int xsm_grant_setup (struct domain *d1, struct domain *d2)
 {
-    return xsm_call(grant_setup(d1, d2));
+    return xsm_ops->grant_setup(d1, d2);
 }
 
 static inline int xsm_grant_transfer (struct domain *d1, struct domain *d2)
 {
-    return xsm_call(grant_transfer(d1, d2));
+    return xsm_ops->grant_transfer(d1, d2);
 }
 
 static inline int xsm_grant_copy (struct domain *d1, struct domain *d2)
 {
-    return xsm_call(grant_copy(d1, d2));
+    return xsm_ops->grant_copy(d1, d2);
 }
 
 static inline int xsm_grant_query_size (struct domain *d1, struct domain *d2)
 {
-    return xsm_call(grant_query_size(d1, d2));
+    return xsm_ops->grant_query_size(d1, d2);
 }
 
 static inline int xsm_alloc_security_domain (struct domain *d)
 {
-    return xsm_call(alloc_security_domain(d));
+    return xsm_ops->alloc_security_domain(d);
 }
 
 static inline void xsm_free_security_domain (struct domain *d)
 {
-    (void)xsm_call(free_security_domain(d));
+    xsm_ops->free_security_domain(d);
 }
 
 static inline int xsm_alloc_security_evtchn (struct evtchn *chn)
 {
-    return xsm_call(alloc_security_evtchn(chn));
+    return xsm_ops->alloc_security_evtchn(chn);
 }
 
 static inline void xsm_free_security_evtchn (struct evtchn *chn)
 {
-    (void)xsm_call(free_security_evtchn(chn));
+    xsm_ops->free_security_evtchn(chn);
 }
 
 static inline char *xsm_show_security_evtchn (struct domain *d, const struct evtchn *chn)
 {
-    return xsm_call(show_security_evtchn(d, chn));
+    return xsm_ops->show_security_evtchn(d, chn);
 }
 
 static inline int xsm_get_pod_target (struct domain *d)
 {
-    return xsm_call(get_pod_target(d));
+    return xsm_ops->get_pod_target(d);
 }
 
 static inline int xsm_set_pod_target (struct domain *d)
 {
-    return xsm_call(set_pod_target(d));
+    return xsm_ops->set_pod_target(d);
 }
 
 static inline int xsm_memory_adjust_reservation (struct domain *d1, struct
                                                                     domain *d2)
 {
-    return xsm_call(memory_adjust_reservation(d1, d2));
+    return xsm_ops->memory_adjust_reservation(d1, d2);
 }
 
 static inline int xsm_memory_stat_reservation (struct domain *d1,
                                                             struct domain *d2)
 {
-    return xsm_call(memory_stat_reservation(d1, d2));
+    return xsm_ops->memory_stat_reservation(d1, d2);
 }
 
 static inline int xsm_memory_pin_page(struct domain *d1, struct domain *d2,
                                       struct page_info *page)
 {
-    return xsm_call(memory_pin_page(d1, d2, page));
+    return xsm_ops->memory_pin_page(d1, d2, page);
 }
 
 static inline int xsm_remove_from_physmap(struct domain *d1, struct domain *d2)
 {
-    return xsm_call(remove_from_physmap(d1, d2));
+    return xsm_ops->remove_from_physmap(d1, d2);
 }
 
 static inline int xsm_console_io (struct domain *d, int cmd)
 {
-    return xsm_call(console_io(d, cmd));
+    return xsm_ops->console_io(d, cmd);
 }
 
 static inline int xsm_profile (struct domain *d, int op)
 {
-    return xsm_call(profile(d, op));
+    return xsm_ops->profile(d, op);
 }
 
 static inline int xsm_kexec (void)
 {
-    return xsm_call(kexec());
+    return xsm_ops->kexec();
 }
 
 static inline int xsm_schedop_shutdown (struct domain *d1, struct domain *d2)
 {
-    return xsm_call(schedop_shutdown(d1, d2));
+    return xsm_ops->schedop_shutdown(d1, d2);
 }
 
 static inline char *xsm_show_irq_sid (int irq)
 {
-    return xsm_call(show_irq_sid(irq));
+    return xsm_ops->show_irq_sid(irq);
 }
 
 static inline int xsm_map_domain_pirq (struct domain *d, int irq, void *data)
 {
-    return xsm_call(map_domain_pirq(d, irq, data));
+    return xsm_ops->map_domain_pirq(d, irq, data);
 }
 
 static inline int xsm_unmap_domain_pirq (struct domain *d, int irq)
 {
-    return xsm_call(unmap_domain_pirq(d, irq));
+    return xsm_ops->unmap_domain_pirq(d, irq);
 }
 
 static inline int xsm_irq_permission (struct domain *d, int pirq, uint8_t allow)
 {
-    return xsm_call(irq_permission(d, pirq, allow));
+    return xsm_ops->irq_permission(d, pirq, allow);
 }
 
 static inline int xsm_iomem_permission (struct domain *d, uint64_t s, uint64_t e, uint8_t allow)
 {
-    return xsm_call(iomem_permission(d, s, e, allow));
+    return xsm_ops->iomem_permission(d, s, e, allow);
 }
 
 static inline int xsm_iomem_mapping (struct domain *d, uint64_t s, uint64_t e, uint8_t allow)
 {
-    return xsm_call(iomem_mapping(d, s, e, allow));
+    return xsm_ops->iomem_mapping(d, s, e, allow);
 }
 
 static inline int xsm_pci_config_permission (struct domain *d, uint32_t machine_bdf, uint16_t start, uint16_t end, uint8_t access)
 {
-    return xsm_call(pci_config_permission(d, machine_bdf, start, end, access));
+    return xsm_ops->pci_config_permission(d, machine_bdf, start, end, access);
 }
 
 static inline int xsm_get_device_group(uint32_t machine_bdf)
 {
-    return xsm_call(get_device_group(machine_bdf));
+    return xsm_ops->get_device_group(machine_bdf);
 }
 
 static inline int xsm_test_assign_device(uint32_t machine_bdf)
 {
-    return xsm_call(test_assign_device(machine_bdf));
+    return xsm_ops->test_assign_device(machine_bdf);
 }
 
 static inline int xsm_assign_device(struct domain *d, uint32_t machine_bdf)
 {
-    return xsm_call(assign_device(d, machine_bdf));
+    return xsm_ops->assign_device(d, machine_bdf);
 }
 
 static inline int xsm_deassign_device(struct domain *d, uint32_t machine_bdf)
 {
-    return xsm_call(deassign_device(d, machine_bdf));
+    return xsm_ops->deassign_device(d, machine_bdf);
 }
 
 static inline int xsm_resource_plug_pci (uint32_t machine_bdf)
 {
-    return xsm_call(resource_plug_pci(machine_bdf));
+    return xsm_ops->resource_plug_pci(machine_bdf);
 }
 
 static inline int xsm_resource_unplug_pci (uint32_t machine_bdf)
 {
-    return xsm_call(resource_unplug_pci(machine_bdf));
+    return xsm_ops->resource_unplug_pci(machine_bdf);
 }
 
 static inline int xsm_resource_plug_core (void)
 {
-    return xsm_call(resource_plug_core());
+    return xsm_ops->resource_plug_core();
 }
 
 static inline int xsm_resource_unplug_core (void)
 {
-    return xsm_call(resource_unplug_core());
+    return xsm_ops->resource_unplug_core();
 }
 
 static inline int xsm_resource_setup_pci (uint32_t machine_bdf)
 {
-    return xsm_call(resource_setup_pci(machine_bdf));
+    return xsm_ops->resource_setup_pci(machine_bdf);
 }
 
 static inline int xsm_resource_setup_gsi (int gsi)
 {
-    return xsm_call(resource_setup_gsi(gsi));
+    return xsm_ops->resource_setup_gsi(gsi);
 }
 
 static inline int xsm_resource_setup_misc (void)
 {
-    return xsm_call(resource_setup_misc());
+    return xsm_ops->resource_setup_misc();
 }
 
 static inline int xsm_page_offline(uint32_t cmd)
 {
-    return xsm_call(page_offline(cmd));
+    return xsm_ops->page_offline(cmd);
 }
 
 static inline int xsm_lockprof(void)
 {
-    return xsm_call(lockprof());
+    return xsm_ops->lockprof();
 }
 
 static inline int xsm_cpupool_op(void)
 {
-    return xsm_call(cpupool_op());
+    return xsm_ops->cpupool_op();
 }
 
 static inline int xsm_sched_op(void)
 {
-    return xsm_call(sched_op());
+    return xsm_ops->sched_op();
 }
 
 static inline int xsm_tmem_control(uint32_t subop)
 {
-    return xsm_call(tmem_control(subop));
+    return xsm_ops->tmem_control(subop);
 }
 
 static inline long xsm___do_xsm_op (XEN_GUEST_HANDLE(xsm_op_t) op)
@@ -619,236 +617,236 @@ static inline long xsm___do_xsm_op (XEN_GUEST_HANDLE(xsm_op_t) op)
 #ifdef CONFIG_X86
 static inline int xsm_shadow_control (struct domain *d, uint32_t op)
 {
-    return xsm_call(shadow_control(d, op));
+    return xsm_ops->shadow_control(d, op);
 }
 
 static inline int xsm_getpageframeinfo (struct domain *d)
 {
-    return xsm_call(getpageframeinfo(d));
+    return xsm_ops->getpageframeinfo(d);
 }
 
 static inline int xsm_set_cpuid (struct domain *d)
 {
-    return xsm_call(set_cpuid(d));
+    return xsm_ops->set_cpuid(d);
 }
 
 static inline int xsm_gettscinfo (struct domain *d)
 {
-    return xsm_call(gettscinfo(d));
+    return xsm_ops->gettscinfo(d);
 }
 
 static inline int xsm_settscinfo (struct domain *d)
 {
-    return xsm_call(settscinfo(d));
+    return xsm_ops->settscinfo(d);
 }
 
 static inline int xsm_getmemlist (struct domain *d)
 {
-    return xsm_call(getmemlist(d));
+    return xsm_ops->getmemlist(d);
 }
 
 static inline int xsm_hypercall_init (struct domain *d)
 {
-    return xsm_call(hypercall_init(d));
+    return xsm_ops->hypercall_init(d);
 }
 
 static inline int xsm_hvmcontext (struct domain *d, uint32_t cmd)
 {
-    return xsm_call(hvmcontext(d, cmd));
+    return xsm_ops->hvmcontext(d, cmd);
 }
 
 static inline int xsm_address_size (struct domain *d, uint32_t cmd)
 {
-    return xsm_call(address_size(d, cmd));
+    return xsm_ops->address_size(d, cmd);
 }
 
 static inline int xsm_machine_address_size (struct domain *d, uint32_t cmd)
 {
-    return xsm_call(machine_address_size(d, cmd));
+    return xsm_ops->machine_address_size(d, cmd);
 }
 
 static inline int xsm_hvm_param (struct domain *d, unsigned long op)
 {
-    return xsm_call(hvm_param(d, op));
+    return xsm_ops->hvm_param(d, op);
 }
 
 static inline int xsm_hvm_set_pci_intx_level (struct domain *d)
 {
-    return xsm_call(hvm_set_pci_intx_level(d));
+    return xsm_ops->hvm_set_pci_intx_level(d);
 }
 
 static inline int xsm_hvm_set_isa_irq_level (struct domain *d)
 {
-    return xsm_call(hvm_set_isa_irq_level(d));
+    return xsm_ops->hvm_set_isa_irq_level(d);
 }
 
 static inline int xsm_hvm_set_pci_link_route (struct domain *d)
 {
-    return xsm_call(hvm_set_pci_link_route(d));
+    return xsm_ops->hvm_set_pci_link_route(d);
 }
 
 static inline int xsm_hvm_inject_msi (struct domain *d)
 {
-    return xsm_call(hvm_inject_msi(d));
+    return xsm_ops->hvm_inject_msi(d);
 }
 
 static inline int xsm_mem_event_setup (struct domain *d)
 {
-    return xsm_call(mem_event_setup(d));
+    return xsm_ops->mem_event_setup(d);
 }
 
 static inline int xsm_mem_event_control (struct domain *d, int mode, int op)
 {
-    return xsm_call(mem_event_control(d, mode, op));
+    return xsm_ops->mem_event_control(d, mode, op);
 }
 
 static inline int xsm_mem_event_op (struct domain *d, int op)
 {
-    return xsm_call(mem_event_op(d, op));
+    return xsm_ops->mem_event_op(d, op);
 }
 
 static inline int xsm_mem_sharing (struct domain *d)
 {
-    return xsm_call(mem_sharing(d));
+    return xsm_ops->mem_sharing(d);
 }
 
 static inline int xsm_mem_sharing_op (struct domain *d, struct domain *cd, int op)
 {
-    return xsm_call(mem_sharing_op(d, cd, op));
+    return xsm_ops->mem_sharing_op(d, cd, op);
 }
 
 static inline int xsm_audit_p2m (struct domain *d)
 {
-    return xsm_call(audit_p2m(d));
+    return xsm_ops->audit_p2m(d);
 }
 
 static inline int xsm_apic (struct domain *d, int cmd)
 {
-    return xsm_call(apic(d, cmd));
+    return xsm_ops->apic(d, cmd);
 }
 
 static inline int xsm_xen_settime (void)
 {
-    return xsm_call(xen_settime());
+    return xsm_ops->xen_settime();
 }
 
 static inline int xsm_memtype (uint32_t access)
 {
-    return xsm_call(memtype(access));
+    return xsm_ops->memtype(access);
 }
 
 static inline int xsm_microcode (void)
 {
-    return xsm_call(microcode());
+    return xsm_ops->microcode();
 }
 
 static inline int xsm_physinfo (void)
 {
-    return xsm_call(physinfo());
+    return xsm_ops->physinfo();
 }
 
 static inline int xsm_platform_quirk (uint32_t quirk)
 {
-    return xsm_call(platform_quirk(quirk));
+    return xsm_ops->platform_quirk(quirk);
 }
 
 static inline int xsm_firmware_info (void)
 {
-    return xsm_call(firmware_info());
+    return xsm_ops->firmware_info();
 }
 
 static inline int xsm_efi_call (void)
 {
-    return xsm_call(efi_call());
+    return xsm_ops->efi_call();
 }
 
 static inline int xsm_acpi_sleep (void)
 {
-    return xsm_call(acpi_sleep());
+    return xsm_ops->acpi_sleep();
 }
 
 static inline int xsm_change_freq (void)
 {
-    return xsm_call(change_freq());
+    return xsm_ops->change_freq();
 }
 
 static inline int xsm_getidletime (void)
 {
-    return xsm_call(getidletime());
+    return xsm_ops->getidletime();
 }
 
 static inline int xsm_machine_memory_map(void)
 {
-    return xsm_call(machine_memory_map());
+    return xsm_ops->machine_memory_map();
 }
 
 static inline int xsm_domain_memory_map(struct domain *d)
 {
-    return xsm_call(domain_memory_map(d));
+    return xsm_ops->domain_memory_map(d);
 }
 
 static inline int xsm_mmu_normal_update (struct domain *d, struct domain *t,
                                          struct domain *f, intpte_t fpte)
 {
-    return xsm_call(mmu_normal_update(d, t, f, fpte));
+    return xsm_ops->mmu_normal_update(d, t, f, fpte);
 }
 
 static inline int xsm_mmu_machphys_update (struct domain *d1, struct domain *d2,
                                            unsigned long mfn)
 {
-    return xsm_call(mmu_machphys_update(d1, d2, mfn));
+    return xsm_ops->mmu_machphys_update(d1, d2, mfn);
 }
 
 static inline int xsm_update_va_mapping(struct domain *d, struct domain *f, 
                                                             l1_pgentry_t pte)
 {
-    return xsm_call(update_va_mapping(d, f, pte));
+    return xsm_ops->update_va_mapping(d, f, pte);
 }
 
 static inline int xsm_add_to_physmap(struct domain *d1, struct domain *d2)
 {
-    return xsm_call(add_to_physmap(d1, d2));
+    return xsm_ops->add_to_physmap(d1, d2);
 }
 
 static inline int xsm_sendtrigger(struct domain *d)
 {
-    return xsm_call(sendtrigger(d));
+    return xsm_ops->sendtrigger(d);
 }
 
 static inline int xsm_bind_pt_irq(struct domain *d, 
                                                 struct xen_domctl_bind_pt_irq *bind)
 {
-    return xsm_call(bind_pt_irq(d, bind));
+    return xsm_ops->bind_pt_irq(d, bind);
 }
 
 static inline int xsm_unbind_pt_irq(struct domain *d,
                                                 struct xen_domctl_bind_pt_irq *bind)
 {
-    return xsm_call(unbind_pt_irq(d, bind));
+    return xsm_ops->unbind_pt_irq(d, bind);
 }
 
 static inline int xsm_pin_mem_cacheattr(struct domain *d)
 {
-    return xsm_call(pin_mem_cacheattr(d));
+    return xsm_ops->pin_mem_cacheattr(d);
 }
 
 static inline int xsm_ext_vcpucontext(struct domain *d, uint32_t cmd)
 {
-    return xsm_call(ext_vcpucontext(d, cmd));
+    return xsm_ops->ext_vcpucontext(d, cmd);
 }
 static inline int xsm_vcpuextstate(struct domain *d, uint32_t cmd)
 {
-    return xsm_call(vcpuextstate(d, cmd));
+    return xsm_ops->vcpuextstate(d, cmd);
 }
 
 static inline int xsm_ioport_permission (struct domain *d, uint32_t s, uint32_t e, uint8_t allow)
 {
-    return xsm_call(ioport_permission(d, s, e, allow));
+    return xsm_ops->ioport_permission(d, s, e, allow);
 }
 
 static inline int xsm_ioport_mapping (struct domain *d, uint32_t s, uint32_t e, uint8_t allow)
 {
-    return xsm_call(ioport_mapping(d, s, e, allow));
+    return xsm_ops->ioport_mapping(d, s, e, allow);
 }
 #endif /* CONFIG_X86 */
 
-- 
1.7.11.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 10 19:50:02 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Sep 2012 19:50: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 1TB9zN-0001CA-2I; Mon, 10 Sep 2012 19:49:45 +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 1TB9zL-00019X-0K
	for xen-devel@lists.xen.org; Mon, 10 Sep 2012 19:49:43 +0000
Received: from [85.158.143.99:27973] by server-3.bemta-4.messagelabs.com id
	C4/D7-08232-6544E405; Mon, 10 Sep 2012 19:49:42 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-9.tower-216.messagelabs.com!1347306581!29620764!1
X-Originating-IP: [63.239.67.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13407 invoked from network); 10 Sep 2012 19:49:41 -0000
Received: from emvm-gh1-uea09.nsa.gov (HELO nsa.gov) (63.239.67.10)
	by server-9.tower-216.messagelabs.com with SMTP;
	10 Sep 2012 19:49:41 -0000
X-TM-IMSS-Message-ID: <3066d28b000f2262@nsa.gov>
Received: from tarius.tycho.ncsc.mil ([144.51.3.1]) by nsa.gov
	([63.239.67.10]) with ESMTP (TREND IMSS SMTP Service 7.1) id
	3066d28b000f2262 ; Mon, 10 Sep 2012 15:51: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 q8AJna3n027796; 
	Mon, 10 Sep 2012 15:49:39 -0400
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xen.org
Date: Mon, 10 Sep 2012 15:49:04 -0400
Message-Id: <1347306553-20980-12-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.11.4
In-Reply-To: <1347306553-20980-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1347306553-20980-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>, Keir Fraser <keir@xen.org>,
	Jan Beulich <jbeulich@suse.com>
Subject: [Xen-devel] [PATCH 11/20] xen: use XSM instead of IS_PRIV where
	duplicated
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

The Xen hypervisor has two basic access control function calls: IS_PRIV
and the xsm_* functions. Most privileged operations currently require
that both checks succeed, and many times the checks are at different
locations in the code. This patch eliminates the explicit and implicit
IS_PRIV checks that are duplicated in XSM hooks.

When XSM_ENABLE is not defined or when the dummy XSM module is used,
this patch should not change any functionality. Because the locations of
privilege checks have sometimes moved below argument validation, error
returns of some functions may change from EPERM to EINVAL or ESRCH if
called with invalid arguments and from a domain without permission to
perform the operation.

Some checks are removed due to non-obvious duplicates in their callers:

 * acpi_enter_sleep is checked by its only caller
 * map_domain_pirq has IS_PRIV_FOR checked in physdev_map_pirq
 * PHYSDEVOP_alloc_irq_vector is a noop, does not need IS_PRIV
 * Many PHYSDEVOP access checks are within the implementation functions
 * do_platform_op, do_domctl, and do_sysctl all have per-operation
   XSM hooks
 * do_console_io has changed to IS_PRIV from an explicit domid==0

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Cc: Keir Fraser <keir@xen.org>
Cc: Jan Beulich <jbeulich@suse.com>
---
 xen/arch/x86/acpi/power.c         |  2 +-
 xen/arch/x86/cpu/mcheck/mce.c     |  3 ---
 xen/arch/x86/domctl.c             | 25 ++++++++++++++----
 xen/arch/x86/irq.c                |  3 +--
 xen/arch/x86/mm.c                 |  3 ---
 xen/arch/x86/physdev.c            | 54 ---------------------------------------
 xen/arch/x86/platform_hypercall.c |  3 ---
 xen/common/domctl.c               | 33 +++---------------------
 xen/common/kexec.c                |  3 ---
 xen/common/schedule.c             |  6 -----
 xen/common/sysctl.c               |  3 ---
 xen/drivers/char/console.c        |  6 -----
 12 files changed, 25 insertions(+), 119 deletions(-)

diff --git a/xen/arch/x86/acpi/power.c b/xen/arch/x86/acpi/power.c
index 9e1f989..c7b37ef 100644
--- a/xen/arch/x86/acpi/power.c
+++ b/xen/arch/x86/acpi/power.c
@@ -238,7 +238,7 @@ static long enter_state_helper(void *data)
  */
 int acpi_enter_sleep(struct xenpf_enter_acpi_sleep *sleep)
 {
-    if ( !IS_PRIV(current->domain) || !acpi_sinfo.pm1a_cnt_blk.address )
+    if ( !acpi_sinfo.pm1a_cnt_blk.address )
         return -EPERM;
 
     /* Sanity check */
diff --git a/xen/arch/x86/cpu/mcheck/mce.c b/xen/arch/x86/cpu/mcheck/mce.c
index a89df6d..f399054 100644
--- a/xen/arch/x86/cpu/mcheck/mce.c
+++ b/xen/arch/x86/cpu/mcheck/mce.c
@@ -1379,9 +1379,6 @@ long do_mca(XEN_GUEST_HANDLE(xen_mc_t) u_xen_mc)
     struct xen_mc_msrinject *mc_msrinject;
     struct xen_mc_mceinject *mc_mceinject;
 
-    if (!IS_PRIV(v->domain) )
-        return x86_mcerr(NULL, -EPERM);
-
     ret = xsm_do_mca();
     if ( ret )
         return x86_mcerr(NULL, ret);
diff --git a/xen/arch/x86/domctl.c b/xen/arch/x86/domctl.c
index 3ccf712..9bc2452 100644
--- a/xen/arch/x86/domctl.c
+++ b/xen/arch/x86/domctl.c
@@ -54,6 +54,26 @@ long arch_do_domctl(
 
     switch ( domctl->cmd )
     {
+    /* TODO: the following do not have XSM hooks yet */
+    case XEN_DOMCTL_set_cpuid:
+    case XEN_DOMCTL_suppress_spurious_page_faults:
+    case XEN_DOMCTL_debug_op:
+    case XEN_DOMCTL_gettscinfo:
+    case XEN_DOMCTL_settscinfo:
+    case XEN_DOMCTL_audit_p2m:
+    case XEN_DOMCTL_gdbsx_guestmemio:
+    case XEN_DOMCTL_gdbsx_pausevcpu:
+    case XEN_DOMCTL_gdbsx_unpausevcpu:
+    case XEN_DOMCTL_gdbsx_domstatus:
+    /* getpageframeinfo[23] needs an extra check to avoid allowing queries of some remote GFNs */
+    case XEN_DOMCTL_getpageframeinfo2:
+    case XEN_DOMCTL_getpageframeinfo3:
+        if ( !IS_PRIV(current->domain) )
+            return -EPERM;
+    }
+
+    switch ( domctl->cmd )
+    {
 
     case XEN_DOMCTL_shadow_op:
     {
@@ -802,11 +822,6 @@ long arch_do_domctl(
             break;
         bind = &(domctl->u.bind_pt_irq);
 
-        ret = -EPERM;
-        if ( !IS_PRIV(current->domain) &&
-             !irq_access_permitted(current->domain, bind->machine_irq) )
-            goto unbind_out;
-
         ret = xsm_unbind_pt_irq(d, bind);
         if ( ret )
             goto unbind_out;
diff --git a/xen/arch/x86/irq.c b/xen/arch/x86/irq.c
index c87027b..70b0f03 100644
--- a/xen/arch/x86/irq.c
+++ b/xen/arch/x86/irq.c
@@ -1853,8 +1853,7 @@ int map_domain_pirq(
     ASSERT(spin_is_locked(&d->event_lock));
 
     if ( !IS_PRIV(current->domain) &&
-         !(IS_PRIV_FOR(current->domain, d) &&
-           irq_access_permitted(current->domain, pirq)))
+         !irq_access_permitted(current->domain, pirq))
         return -EPERM;
 
     if ( pirq < 0 || pirq >= d->nr_pirqs || irq < 0 || irq >= nr_irqs )
diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
index 4af4130..4732c81 100644
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -4790,9 +4790,6 @@ long arch_memory_op(int op, XEN_GUEST_HANDLE(void) arg)
         XEN_GUEST_HANDLE(e820entry_t) buffer;
         unsigned int i;
 
-        if ( !IS_PRIV(current->domain) )
-            return -EINVAL;
-
         rc = xsm_machine_memory_map();
         if ( rc )
             return rc;
diff --git a/xen/arch/x86/physdev.c b/xen/arch/x86/physdev.c
index bf133fa..d6ea4f0 100644
--- a/xen/arch/x86/physdev.c
+++ b/xen/arch/x86/physdev.c
@@ -110,12 +110,6 @@ int physdev_map_pirq(domid_t domid, int type, int *index, int *pirq_p,
     if ( ret )
         return ret;
 
-    if ( !IS_PRIV_FOR(current->domain, d) )
-    {
-        ret = -EPERM;
-        goto free_domain;
-    }
-
     /* Verify or get irq. */
     switch ( type )
     {
@@ -239,10 +233,6 @@ int physdev_unmap_pirq(domid_t domid, int pirq)
             goto free_domain;
     }
 
-    ret = -EPERM;
-    if ( !IS_PRIV_FOR(current->domain, d) )
-        goto free_domain;
-
     ret = xsm_unmap_domain_pirq(d, domain_pirq_to_irq(d, pirq));
     if ( ret )
         goto free_domain;
@@ -434,9 +424,6 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_HANDLE(void) arg)
         ret = -EFAULT;
         if ( copy_from_guest(&apic, arg, 1) != 0 )
             break;
-        ret = -EPERM;
-        if ( !IS_PRIV(v->domain) )
-            break;
         ret = xsm_apic(v->domain, cmd);
         if ( ret )
             break;
@@ -451,9 +438,6 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_HANDLE(void) arg)
         ret = -EFAULT;
         if ( copy_from_guest(&apic, arg, 1) != 0 )
             break;
-        ret = -EPERM;
-        if ( !IS_PRIV(v->domain) )
-            break;
         ret = xsm_apic(v->domain, cmd);
         if ( ret )
             break;
@@ -468,10 +452,6 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_HANDLE(void) arg)
         if ( copy_from_guest(&irq_op, arg, 1) != 0 )
             break;
 
-        ret = -EPERM;
-        if ( !IS_PRIV(v->domain) )
-            break;
-
         /* Vector is only used by hypervisor, and dom0 shouldn't
            touch it in its world, return irq_op.irq as the vecotr,
            and make this hypercall dummy, and also defer the vector 
@@ -518,9 +498,6 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_HANDLE(void) arg)
 
     case PHYSDEVOP_manage_pci_add: {
         struct physdev_manage_pci manage_pci;
-        ret = -EPERM;
-        if ( !IS_PRIV(v->domain) )
-            break;
         ret = -EFAULT;
         if ( copy_from_guest(&manage_pci, arg, 1) != 0 )
             break;
@@ -531,9 +508,6 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_HANDLE(void) arg)
 
     case PHYSDEVOP_manage_pci_remove: {
         struct physdev_manage_pci manage_pci;
-        ret = -EPERM;
-        if ( !IS_PRIV(v->domain) )
-            break;
         ret = -EFAULT;
         if ( copy_from_guest(&manage_pci, arg, 1) != 0 )
             break;
@@ -546,10 +520,6 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_HANDLE(void) arg)
         struct physdev_manage_pci_ext manage_pci_ext;
         struct pci_dev_info pdev_info;
 
-        ret = -EPERM;
-        if ( !IS_PRIV(current->domain) )
-            break;
-
         ret = -EFAULT;
         if ( copy_from_guest(&manage_pci_ext, arg, 1) != 0 )
             break;
@@ -572,10 +542,6 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_HANDLE(void) arg)
         struct physdev_pci_device_add add;
         struct pci_dev_info pdev_info;
 
-        ret = -EPERM;
-        if ( !IS_PRIV(current->domain) )
-            break;
-
         ret = -EFAULT;
         if ( copy_from_guest(&add, arg, 1) != 0 )
             break;
@@ -596,10 +562,6 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_HANDLE(void) arg)
     case PHYSDEVOP_pci_device_remove: {
         struct physdev_pci_device dev;
 
-        ret = -EPERM;
-        if ( !IS_PRIV(v->domain) )
-            break;
-
         ret = -EFAULT;
         if ( copy_from_guest(&dev, arg, 1) != 0 )
             break;
@@ -612,10 +574,6 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_HANDLE(void) arg)
     case PHYSDEVOP_pci_mmcfg_reserved: {
         struct physdev_pci_mmcfg_reserved info;
 
-        ret = -EPERM;
-        if ( !IS_PRIV(current->domain) )
-            break;
-
         ret = xsm_resource_setup_misc();
         if ( ret )
             break;
@@ -634,10 +592,6 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_HANDLE(void) arg)
         struct physdev_restore_msi restore_msi;
         struct pci_dev *pdev;
 
-        ret = -EPERM;
-        if ( !IS_PRIV(v->domain) )
-            break;
-
         ret = -EFAULT;
         if ( copy_from_guest(&restore_msi, arg, 1) != 0 )
             break;
@@ -653,10 +607,6 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_HANDLE(void) arg)
         struct physdev_pci_device dev;
         struct pci_dev *pdev;
 
-        ret = -EPERM;
-        if ( !IS_PRIV(v->domain) )
-            break;
-
         ret = -EFAULT;
         if ( copy_from_guest(&dev, arg, 1) != 0 )
             break;
@@ -671,10 +621,6 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_HANDLE(void) arg)
     case PHYSDEVOP_setup_gsi: {
         struct physdev_setup_gsi setup_gsi;
 
-        ret = -EPERM;
-        if ( !IS_PRIV(v->domain) )
-            break;
-
         ret = -EFAULT;
         if ( copy_from_guest(&setup_gsi, arg, 1) != 0 )
             break;
diff --git a/xen/arch/x86/platform_hypercall.c b/xen/arch/x86/platform_hypercall.c
index c049db7..f3304a2 100644
--- a/xen/arch/x86/platform_hypercall.c
+++ b/xen/arch/x86/platform_hypercall.c
@@ -65,9 +65,6 @@ ret_t do_platform_op(XEN_GUEST_HANDLE(xen_platform_op_t) u_xenpf_op)
     ret_t ret = 0;
     struct xen_platform_op curop, *op = &curop;
 
-    if ( !IS_PRIV(current->domain) )
-        return -EPERM;
-
     if ( copy_from_guest(op, u_xenpf_op, 1) )
         return -EFAULT;
 
diff --git a/xen/common/domctl.c b/xen/common/domctl.c
index 2b1f182..ec8fa58 100644
--- a/xen/common/domctl.c
+++ b/xen/common/domctl.c
@@ -250,33 +250,6 @@ long do_domctl(XEN_GUEST_HANDLE(xen_domctl_t) u_domctl)
     if ( op->interface_version != XEN_DOMCTL_INTERFACE_VERSION )
         return -EACCES;
 
-    switch ( op->cmd )
-    {
-    case XEN_DOMCTL_ioport_mapping:
-    case XEN_DOMCTL_memory_mapping:
-    case XEN_DOMCTL_bind_pt_irq:
-    case XEN_DOMCTL_unbind_pt_irq: {
-        struct domain *d;
-        bool_t is_priv = IS_PRIV(current->domain);
-        if ( !is_priv && ((d = rcu_lock_domain_by_id(op->domain)) != NULL) )
-        {
-            is_priv = IS_PRIV_FOR(current->domain, d);
-            rcu_unlock_domain(d);
-        }
-        if ( !is_priv )
-            return -EPERM;
-        break;
-    }
-#ifdef XSM_ENABLE
-    case XEN_DOMCTL_getdomaininfo:
-        break;
-#endif
-    default:
-        if ( !IS_PRIV(current->domain) )
-            return -EPERM;
-        break;
-    }
-
     if ( !domctl_lock_acquire() )
         return hypercall_create_continuation(
             __HYPERVISOR_domctl, "h", u_domctl);
@@ -892,10 +865,10 @@ long do_domctl(XEN_GUEST_HANDLE(xen_domctl_t) u_domctl)
         if ( d == NULL )
             break;
 
-        if ( pirq >= d->nr_pirqs )
-            ret = -EINVAL;
-        else if ( xsm_irq_permission(d, pirq, allow) )
+        if ( xsm_irq_permission(d, pirq, allow) )
             ret = -EPERM;
+        else if ( pirq >= d->nr_pirqs )
+            ret = -EINVAL;
         else if ( allow )
             ret = irq_permit_access(d, pirq);
         else
diff --git a/xen/common/kexec.c b/xen/common/kexec.c
index 2bc3e33..7dc6f24 100644
--- a/xen/common/kexec.c
+++ b/xen/common/kexec.c
@@ -851,9 +851,6 @@ static int do_kexec_op_internal(unsigned long op, XEN_GUEST_HANDLE(void) uarg,
     unsigned long flags;
     int ret = -EINVAL;
 
-    if ( !IS_PRIV(current->domain) )
-        return -EPERM;
-
     ret = xsm_kexec();
     if ( ret )
         return ret;
diff --git a/xen/common/schedule.c b/xen/common/schedule.c
index eee74be..95142c0 100644
--- a/xen/common/schedule.c
+++ b/xen/common/schedule.c
@@ -919,12 +919,6 @@ ret_t do_sched_op(int cmd, XEN_GUEST_HANDLE(void) arg)
         if ( d == NULL )
             break;
 
-        if ( !IS_PRIV_FOR(current->domain, d) )
-        {
-            rcu_unlock_domain(d);
-            return -EPERM;
-        }
-
         ret = xsm_schedop_shutdown(current->domain, d);
         if ( ret )
         {
diff --git a/xen/common/sysctl.c b/xen/common/sysctl.c
index ea68278..2cea0c3 100644
--- a/xen/common/sysctl.c
+++ b/xen/common/sysctl.c
@@ -33,9 +33,6 @@ long do_sysctl(XEN_GUEST_HANDLE(xen_sysctl_t) u_sysctl)
     struct xen_sysctl curop, *op = &curop;
     static DEFINE_SPINLOCK(sysctl_lock);
 
-    if ( !IS_PRIV(current->domain) )
-        return -EPERM;
-
     if ( copy_from_guest(op, u_sysctl, 1) )
         return -EFAULT;
 
diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c
index e10bed5..3ff36b9 100644
--- a/xen/drivers/char/console.c
+++ b/xen/drivers/char/console.c
@@ -363,12 +363,6 @@ long do_console_io(int cmd, int count, XEN_GUEST_HANDLE(char) buffer)
     long rc;
     unsigned int idx, len;
 
-#ifndef VERBOSE
-    /* Only domain 0 may access the emergency console. */
-    if ( current->domain->domain_id != 0 )
-        return -EPERM;
-#endif
-
     rc = xsm_console_io(current->domain, cmd);
     if ( rc )
         return rc;
-- 
1.7.11.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 10 19:50:02 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Sep 2012 19:50: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 1TB9zN-0001CA-2I; Mon, 10 Sep 2012 19:49:45 +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 1TB9zL-00019X-0K
	for xen-devel@lists.xen.org; Mon, 10 Sep 2012 19:49:43 +0000
Received: from [85.158.143.99:27973] by server-3.bemta-4.messagelabs.com id
	C4/D7-08232-6544E405; Mon, 10 Sep 2012 19:49:42 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-9.tower-216.messagelabs.com!1347306581!29620764!1
X-Originating-IP: [63.239.67.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13407 invoked from network); 10 Sep 2012 19:49:41 -0000
Received: from emvm-gh1-uea09.nsa.gov (HELO nsa.gov) (63.239.67.10)
	by server-9.tower-216.messagelabs.com with SMTP;
	10 Sep 2012 19:49:41 -0000
X-TM-IMSS-Message-ID: <3066d28b000f2262@nsa.gov>
Received: from tarius.tycho.ncsc.mil ([144.51.3.1]) by nsa.gov
	([63.239.67.10]) with ESMTP (TREND IMSS SMTP Service 7.1) id
	3066d28b000f2262 ; Mon, 10 Sep 2012 15:51: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 q8AJna3n027796; 
	Mon, 10 Sep 2012 15:49:39 -0400
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xen.org
Date: Mon, 10 Sep 2012 15:49:04 -0400
Message-Id: <1347306553-20980-12-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.11.4
In-Reply-To: <1347306553-20980-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1347306553-20980-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>, Keir Fraser <keir@xen.org>,
	Jan Beulich <jbeulich@suse.com>
Subject: [Xen-devel] [PATCH 11/20] xen: use XSM instead of IS_PRIV where
	duplicated
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

The Xen hypervisor has two basic access control function calls: IS_PRIV
and the xsm_* functions. Most privileged operations currently require
that both checks succeed, and many times the checks are at different
locations in the code. This patch eliminates the explicit and implicit
IS_PRIV checks that are duplicated in XSM hooks.

When XSM_ENABLE is not defined or when the dummy XSM module is used,
this patch should not change any functionality. Because the locations of
privilege checks have sometimes moved below argument validation, error
returns of some functions may change from EPERM to EINVAL or ESRCH if
called with invalid arguments and from a domain without permission to
perform the operation.

Some checks are removed due to non-obvious duplicates in their callers:

 * acpi_enter_sleep is checked by its only caller
 * map_domain_pirq has IS_PRIV_FOR checked in physdev_map_pirq
 * PHYSDEVOP_alloc_irq_vector is a noop, does not need IS_PRIV
 * Many PHYSDEVOP access checks are within the implementation functions
 * do_platform_op, do_domctl, and do_sysctl all have per-operation
   XSM hooks
 * do_console_io has changed to IS_PRIV from an explicit domid==0

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Cc: Keir Fraser <keir@xen.org>
Cc: Jan Beulich <jbeulich@suse.com>
---
 xen/arch/x86/acpi/power.c         |  2 +-
 xen/arch/x86/cpu/mcheck/mce.c     |  3 ---
 xen/arch/x86/domctl.c             | 25 ++++++++++++++----
 xen/arch/x86/irq.c                |  3 +--
 xen/arch/x86/mm.c                 |  3 ---
 xen/arch/x86/physdev.c            | 54 ---------------------------------------
 xen/arch/x86/platform_hypercall.c |  3 ---
 xen/common/domctl.c               | 33 +++---------------------
 xen/common/kexec.c                |  3 ---
 xen/common/schedule.c             |  6 -----
 xen/common/sysctl.c               |  3 ---
 xen/drivers/char/console.c        |  6 -----
 12 files changed, 25 insertions(+), 119 deletions(-)

diff --git a/xen/arch/x86/acpi/power.c b/xen/arch/x86/acpi/power.c
index 9e1f989..c7b37ef 100644
--- a/xen/arch/x86/acpi/power.c
+++ b/xen/arch/x86/acpi/power.c
@@ -238,7 +238,7 @@ static long enter_state_helper(void *data)
  */
 int acpi_enter_sleep(struct xenpf_enter_acpi_sleep *sleep)
 {
-    if ( !IS_PRIV(current->domain) || !acpi_sinfo.pm1a_cnt_blk.address )
+    if ( !acpi_sinfo.pm1a_cnt_blk.address )
         return -EPERM;
 
     /* Sanity check */
diff --git a/xen/arch/x86/cpu/mcheck/mce.c b/xen/arch/x86/cpu/mcheck/mce.c
index a89df6d..f399054 100644
--- a/xen/arch/x86/cpu/mcheck/mce.c
+++ b/xen/arch/x86/cpu/mcheck/mce.c
@@ -1379,9 +1379,6 @@ long do_mca(XEN_GUEST_HANDLE(xen_mc_t) u_xen_mc)
     struct xen_mc_msrinject *mc_msrinject;
     struct xen_mc_mceinject *mc_mceinject;
 
-    if (!IS_PRIV(v->domain) )
-        return x86_mcerr(NULL, -EPERM);
-
     ret = xsm_do_mca();
     if ( ret )
         return x86_mcerr(NULL, ret);
diff --git a/xen/arch/x86/domctl.c b/xen/arch/x86/domctl.c
index 3ccf712..9bc2452 100644
--- a/xen/arch/x86/domctl.c
+++ b/xen/arch/x86/domctl.c
@@ -54,6 +54,26 @@ long arch_do_domctl(
 
     switch ( domctl->cmd )
     {
+    /* TODO: the following do not have XSM hooks yet */
+    case XEN_DOMCTL_set_cpuid:
+    case XEN_DOMCTL_suppress_spurious_page_faults:
+    case XEN_DOMCTL_debug_op:
+    case XEN_DOMCTL_gettscinfo:
+    case XEN_DOMCTL_settscinfo:
+    case XEN_DOMCTL_audit_p2m:
+    case XEN_DOMCTL_gdbsx_guestmemio:
+    case XEN_DOMCTL_gdbsx_pausevcpu:
+    case XEN_DOMCTL_gdbsx_unpausevcpu:
+    case XEN_DOMCTL_gdbsx_domstatus:
+    /* getpageframeinfo[23] needs an extra check to avoid allowing queries of some remote GFNs */
+    case XEN_DOMCTL_getpageframeinfo2:
+    case XEN_DOMCTL_getpageframeinfo3:
+        if ( !IS_PRIV(current->domain) )
+            return -EPERM;
+    }
+
+    switch ( domctl->cmd )
+    {
 
     case XEN_DOMCTL_shadow_op:
     {
@@ -802,11 +822,6 @@ long arch_do_domctl(
             break;
         bind = &(domctl->u.bind_pt_irq);
 
-        ret = -EPERM;
-        if ( !IS_PRIV(current->domain) &&
-             !irq_access_permitted(current->domain, bind->machine_irq) )
-            goto unbind_out;
-
         ret = xsm_unbind_pt_irq(d, bind);
         if ( ret )
             goto unbind_out;
diff --git a/xen/arch/x86/irq.c b/xen/arch/x86/irq.c
index c87027b..70b0f03 100644
--- a/xen/arch/x86/irq.c
+++ b/xen/arch/x86/irq.c
@@ -1853,8 +1853,7 @@ int map_domain_pirq(
     ASSERT(spin_is_locked(&d->event_lock));
 
     if ( !IS_PRIV(current->domain) &&
-         !(IS_PRIV_FOR(current->domain, d) &&
-           irq_access_permitted(current->domain, pirq)))
+         !irq_access_permitted(current->domain, pirq))
         return -EPERM;
 
     if ( pirq < 0 || pirq >= d->nr_pirqs || irq < 0 || irq >= nr_irqs )
diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
index 4af4130..4732c81 100644
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -4790,9 +4790,6 @@ long arch_memory_op(int op, XEN_GUEST_HANDLE(void) arg)
         XEN_GUEST_HANDLE(e820entry_t) buffer;
         unsigned int i;
 
-        if ( !IS_PRIV(current->domain) )
-            return -EINVAL;
-
         rc = xsm_machine_memory_map();
         if ( rc )
             return rc;
diff --git a/xen/arch/x86/physdev.c b/xen/arch/x86/physdev.c
index bf133fa..d6ea4f0 100644
--- a/xen/arch/x86/physdev.c
+++ b/xen/arch/x86/physdev.c
@@ -110,12 +110,6 @@ int physdev_map_pirq(domid_t domid, int type, int *index, int *pirq_p,
     if ( ret )
         return ret;
 
-    if ( !IS_PRIV_FOR(current->domain, d) )
-    {
-        ret = -EPERM;
-        goto free_domain;
-    }
-
     /* Verify or get irq. */
     switch ( type )
     {
@@ -239,10 +233,6 @@ int physdev_unmap_pirq(domid_t domid, int pirq)
             goto free_domain;
     }
 
-    ret = -EPERM;
-    if ( !IS_PRIV_FOR(current->domain, d) )
-        goto free_domain;
-
     ret = xsm_unmap_domain_pirq(d, domain_pirq_to_irq(d, pirq));
     if ( ret )
         goto free_domain;
@@ -434,9 +424,6 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_HANDLE(void) arg)
         ret = -EFAULT;
         if ( copy_from_guest(&apic, arg, 1) != 0 )
             break;
-        ret = -EPERM;
-        if ( !IS_PRIV(v->domain) )
-            break;
         ret = xsm_apic(v->domain, cmd);
         if ( ret )
             break;
@@ -451,9 +438,6 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_HANDLE(void) arg)
         ret = -EFAULT;
         if ( copy_from_guest(&apic, arg, 1) != 0 )
             break;
-        ret = -EPERM;
-        if ( !IS_PRIV(v->domain) )
-            break;
         ret = xsm_apic(v->domain, cmd);
         if ( ret )
             break;
@@ -468,10 +452,6 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_HANDLE(void) arg)
         if ( copy_from_guest(&irq_op, arg, 1) != 0 )
             break;
 
-        ret = -EPERM;
-        if ( !IS_PRIV(v->domain) )
-            break;
-
         /* Vector is only used by hypervisor, and dom0 shouldn't
            touch it in its world, return irq_op.irq as the vecotr,
            and make this hypercall dummy, and also defer the vector 
@@ -518,9 +498,6 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_HANDLE(void) arg)
 
     case PHYSDEVOP_manage_pci_add: {
         struct physdev_manage_pci manage_pci;
-        ret = -EPERM;
-        if ( !IS_PRIV(v->domain) )
-            break;
         ret = -EFAULT;
         if ( copy_from_guest(&manage_pci, arg, 1) != 0 )
             break;
@@ -531,9 +508,6 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_HANDLE(void) arg)
 
     case PHYSDEVOP_manage_pci_remove: {
         struct physdev_manage_pci manage_pci;
-        ret = -EPERM;
-        if ( !IS_PRIV(v->domain) )
-            break;
         ret = -EFAULT;
         if ( copy_from_guest(&manage_pci, arg, 1) != 0 )
             break;
@@ -546,10 +520,6 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_HANDLE(void) arg)
         struct physdev_manage_pci_ext manage_pci_ext;
         struct pci_dev_info pdev_info;
 
-        ret = -EPERM;
-        if ( !IS_PRIV(current->domain) )
-            break;
-
         ret = -EFAULT;
         if ( copy_from_guest(&manage_pci_ext, arg, 1) != 0 )
             break;
@@ -572,10 +542,6 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_HANDLE(void) arg)
         struct physdev_pci_device_add add;
         struct pci_dev_info pdev_info;
 
-        ret = -EPERM;
-        if ( !IS_PRIV(current->domain) )
-            break;
-
         ret = -EFAULT;
         if ( copy_from_guest(&add, arg, 1) != 0 )
             break;
@@ -596,10 +562,6 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_HANDLE(void) arg)
     case PHYSDEVOP_pci_device_remove: {
         struct physdev_pci_device dev;
 
-        ret = -EPERM;
-        if ( !IS_PRIV(v->domain) )
-            break;
-
         ret = -EFAULT;
         if ( copy_from_guest(&dev, arg, 1) != 0 )
             break;
@@ -612,10 +574,6 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_HANDLE(void) arg)
     case PHYSDEVOP_pci_mmcfg_reserved: {
         struct physdev_pci_mmcfg_reserved info;
 
-        ret = -EPERM;
-        if ( !IS_PRIV(current->domain) )
-            break;
-
         ret = xsm_resource_setup_misc();
         if ( ret )
             break;
@@ -634,10 +592,6 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_HANDLE(void) arg)
         struct physdev_restore_msi restore_msi;
         struct pci_dev *pdev;
 
-        ret = -EPERM;
-        if ( !IS_PRIV(v->domain) )
-            break;
-
         ret = -EFAULT;
         if ( copy_from_guest(&restore_msi, arg, 1) != 0 )
             break;
@@ -653,10 +607,6 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_HANDLE(void) arg)
         struct physdev_pci_device dev;
         struct pci_dev *pdev;
 
-        ret = -EPERM;
-        if ( !IS_PRIV(v->domain) )
-            break;
-
         ret = -EFAULT;
         if ( copy_from_guest(&dev, arg, 1) != 0 )
             break;
@@ -671,10 +621,6 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_HANDLE(void) arg)
     case PHYSDEVOP_setup_gsi: {
         struct physdev_setup_gsi setup_gsi;
 
-        ret = -EPERM;
-        if ( !IS_PRIV(v->domain) )
-            break;
-
         ret = -EFAULT;
         if ( copy_from_guest(&setup_gsi, arg, 1) != 0 )
             break;
diff --git a/xen/arch/x86/platform_hypercall.c b/xen/arch/x86/platform_hypercall.c
index c049db7..f3304a2 100644
--- a/xen/arch/x86/platform_hypercall.c
+++ b/xen/arch/x86/platform_hypercall.c
@@ -65,9 +65,6 @@ ret_t do_platform_op(XEN_GUEST_HANDLE(xen_platform_op_t) u_xenpf_op)
     ret_t ret = 0;
     struct xen_platform_op curop, *op = &curop;
 
-    if ( !IS_PRIV(current->domain) )
-        return -EPERM;
-
     if ( copy_from_guest(op, u_xenpf_op, 1) )
         return -EFAULT;
 
diff --git a/xen/common/domctl.c b/xen/common/domctl.c
index 2b1f182..ec8fa58 100644
--- a/xen/common/domctl.c
+++ b/xen/common/domctl.c
@@ -250,33 +250,6 @@ long do_domctl(XEN_GUEST_HANDLE(xen_domctl_t) u_domctl)
     if ( op->interface_version != XEN_DOMCTL_INTERFACE_VERSION )
         return -EACCES;
 
-    switch ( op->cmd )
-    {
-    case XEN_DOMCTL_ioport_mapping:
-    case XEN_DOMCTL_memory_mapping:
-    case XEN_DOMCTL_bind_pt_irq:
-    case XEN_DOMCTL_unbind_pt_irq: {
-        struct domain *d;
-        bool_t is_priv = IS_PRIV(current->domain);
-        if ( !is_priv && ((d = rcu_lock_domain_by_id(op->domain)) != NULL) )
-        {
-            is_priv = IS_PRIV_FOR(current->domain, d);
-            rcu_unlock_domain(d);
-        }
-        if ( !is_priv )
-            return -EPERM;
-        break;
-    }
-#ifdef XSM_ENABLE
-    case XEN_DOMCTL_getdomaininfo:
-        break;
-#endif
-    default:
-        if ( !IS_PRIV(current->domain) )
-            return -EPERM;
-        break;
-    }
-
     if ( !domctl_lock_acquire() )
         return hypercall_create_continuation(
             __HYPERVISOR_domctl, "h", u_domctl);
@@ -892,10 +865,10 @@ long do_domctl(XEN_GUEST_HANDLE(xen_domctl_t) u_domctl)
         if ( d == NULL )
             break;
 
-        if ( pirq >= d->nr_pirqs )
-            ret = -EINVAL;
-        else if ( xsm_irq_permission(d, pirq, allow) )
+        if ( xsm_irq_permission(d, pirq, allow) )
             ret = -EPERM;
+        else if ( pirq >= d->nr_pirqs )
+            ret = -EINVAL;
         else if ( allow )
             ret = irq_permit_access(d, pirq);
         else
diff --git a/xen/common/kexec.c b/xen/common/kexec.c
index 2bc3e33..7dc6f24 100644
--- a/xen/common/kexec.c
+++ b/xen/common/kexec.c
@@ -851,9 +851,6 @@ static int do_kexec_op_internal(unsigned long op, XEN_GUEST_HANDLE(void) uarg,
     unsigned long flags;
     int ret = -EINVAL;
 
-    if ( !IS_PRIV(current->domain) )
-        return -EPERM;
-
     ret = xsm_kexec();
     if ( ret )
         return ret;
diff --git a/xen/common/schedule.c b/xen/common/schedule.c
index eee74be..95142c0 100644
--- a/xen/common/schedule.c
+++ b/xen/common/schedule.c
@@ -919,12 +919,6 @@ ret_t do_sched_op(int cmd, XEN_GUEST_HANDLE(void) arg)
         if ( d == NULL )
             break;
 
-        if ( !IS_PRIV_FOR(current->domain, d) )
-        {
-            rcu_unlock_domain(d);
-            return -EPERM;
-        }
-
         ret = xsm_schedop_shutdown(current->domain, d);
         if ( ret )
         {
diff --git a/xen/common/sysctl.c b/xen/common/sysctl.c
index ea68278..2cea0c3 100644
--- a/xen/common/sysctl.c
+++ b/xen/common/sysctl.c
@@ -33,9 +33,6 @@ long do_sysctl(XEN_GUEST_HANDLE(xen_sysctl_t) u_sysctl)
     struct xen_sysctl curop, *op = &curop;
     static DEFINE_SPINLOCK(sysctl_lock);
 
-    if ( !IS_PRIV(current->domain) )
-        return -EPERM;
-
     if ( copy_from_guest(op, u_sysctl, 1) )
         return -EFAULT;
 
diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c
index e10bed5..3ff36b9 100644
--- a/xen/drivers/char/console.c
+++ b/xen/drivers/char/console.c
@@ -363,12 +363,6 @@ long do_console_io(int cmd, int count, XEN_GUEST_HANDLE(char) buffer)
     long rc;
     unsigned int idx, len;
 
-#ifndef VERBOSE
-    /* Only domain 0 may access the emergency console. */
-    if ( current->domain->domain_id != 0 )
-        return -EPERM;
-#endif
-
     rc = xsm_console_io(current->domain, cmd);
     if ( rc )
         return rc;
-- 
1.7.11.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 10 19:57:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Sep 2012 19: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 1TBA6M-0004Si-TF; Mon, 10 Sep 2012 19:56:58 +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 1TBA6L-0004S6-Hr
	for xen-devel@lists.xensource.com; Mon, 10 Sep 2012 19:56:57 +0000
Received: from [85.158.139.83:45045] by server-6.bemta-5.messagelabs.com id
	83/91-21336-8064E405; Mon, 10 Sep 2012 19:56:56 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1347307014!22335825!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDc0NzYwMw==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22509 invoked from network); 10 Sep 2012 19:56:55 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-16.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 10 Sep 2012 19:56: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 q8AJunCd011004
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 10 Sep 2012 19:56: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
	q8AJummm021870
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 10 Sep 2012 19:56:49 GMT
Received: from abhmt103.oracle.com (abhmt103.oracle.com [141.146.116.55])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q8AJumPG018821; Mon, 10 Sep 2012 14:56:48 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 10 Sep 2012 12:56:48 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 22E7C4035A; Mon, 10 Sep 2012 15:46:09 -0400 (EDT)
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: linux-kernel@vger.kernel.org, xen-devel@lists.xensource.com,
	stefano.stabellini@eu.citrix.com
Date: Mon, 10 Sep 2012 15:46:05 -0400
Message-Id: <1347306367-28669-9-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.7.7.6
In-Reply-To: <1347306367-28669-1-git-send-email-konrad.wilk@oracle.com>
References: <1347306367-28669-1-git-send-email-konrad.wilk@oracle.com>
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: [Xen-devel] [PATCH 08/10] xen/swiotlb: Remove functions not needed
	anymore.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Sparse warns us off:
drivers/xen/swiotlb-xen.c:506:1: warning: symbol 'xen_swiotlb_map_sg' was not declared. Should it be static?
drivers/xen/swiotlb-xen.c:534:1: warning: symbol 'xen_swiotlb_unmap_sg' was not declared. Should it be static?

and it looks like we do not need this function at all.

Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 drivers/xen/swiotlb-xen.c |   16 ----------------
 include/xen/swiotlb-xen.h |    9 ---------
 2 files changed, 0 insertions(+), 25 deletions(-)

diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
index f0825cb..6f81994 100644
--- a/drivers/xen/swiotlb-xen.c
+++ b/drivers/xen/swiotlb-xen.c
@@ -514,14 +514,6 @@ xen_swiotlb_map_sg_attrs(struct device *hwdev, struct scatterlist *sgl,
 }
 EXPORT_SYMBOL_GPL(xen_swiotlb_map_sg_attrs);
 
-int
-xen_swiotlb_map_sg(struct device *hwdev, struct scatterlist *sgl, int nelems,
-		   enum dma_data_direction dir)
-{
-	return xen_swiotlb_map_sg_attrs(hwdev, sgl, nelems, dir, NULL);
-}
-EXPORT_SYMBOL_GPL(xen_swiotlb_map_sg);
-
 /*
  * Unmap a set of streaming mode DMA translations.  Again, cpu read rules
  * concerning calls here are the same as for swiotlb_unmap_page() above.
@@ -542,14 +534,6 @@ xen_swiotlb_unmap_sg_attrs(struct device *hwdev, struct scatterlist *sgl,
 }
 EXPORT_SYMBOL_GPL(xen_swiotlb_unmap_sg_attrs);
 
-void
-xen_swiotlb_unmap_sg(struct device *hwdev, struct scatterlist *sgl, int nelems,
-		     enum dma_data_direction dir)
-{
-	return xen_swiotlb_unmap_sg_attrs(hwdev, sgl, nelems, dir, NULL);
-}
-EXPORT_SYMBOL_GPL(xen_swiotlb_unmap_sg);
-
 /*
  * Make physical memory consistent for a set of streaming mode DMA translations
  * after a transfer.
diff --git a/include/xen/swiotlb-xen.h b/include/xen/swiotlb-xen.h
index f26f9f3..a0db2b7 100644
--- a/include/xen/swiotlb-xen.h
+++ b/include/xen/swiotlb-xen.h
@@ -23,15 +23,6 @@ extern dma_addr_t xen_swiotlb_map_page(struct device *dev, struct page *page,
 extern void xen_swiotlb_unmap_page(struct device *hwdev, dma_addr_t dev_addr,
 				   size_t size, enum dma_data_direction dir,
 				   struct dma_attrs *attrs);
-/*
-extern int
-xen_swiotlb_map_sg(struct device *hwdev, struct scatterlist *sg, int nents,
-		   enum dma_data_direction dir);
-
-extern void
-xen_swiotlb_unmap_sg(struct device *hwdev, struct scatterlist *sg, int nents,
-		     enum dma_data_direction dir);
-*/
 extern int
 xen_swiotlb_map_sg_attrs(struct device *hwdev, struct scatterlist *sgl,
 			 int nelems, enum dma_data_direction dir,
-- 
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 Sep 10 19:57:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Sep 2012 19: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 1TBA6M-0004Si-TF; Mon, 10 Sep 2012 19:56:58 +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 1TBA6L-0004S6-Hr
	for xen-devel@lists.xensource.com; Mon, 10 Sep 2012 19:56:57 +0000
Received: from [85.158.139.83:45045] by server-6.bemta-5.messagelabs.com id
	83/91-21336-8064E405; Mon, 10 Sep 2012 19:56:56 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1347307014!22335825!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDc0NzYwMw==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22509 invoked from network); 10 Sep 2012 19:56:55 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-16.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 10 Sep 2012 19:56: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 q8AJunCd011004
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 10 Sep 2012 19:56: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
	q8AJummm021870
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 10 Sep 2012 19:56:49 GMT
Received: from abhmt103.oracle.com (abhmt103.oracle.com [141.146.116.55])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q8AJumPG018821; Mon, 10 Sep 2012 14:56:48 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 10 Sep 2012 12:56:48 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 22E7C4035A; Mon, 10 Sep 2012 15:46:09 -0400 (EDT)
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: linux-kernel@vger.kernel.org, xen-devel@lists.xensource.com,
	stefano.stabellini@eu.citrix.com
Date: Mon, 10 Sep 2012 15:46:05 -0400
Message-Id: <1347306367-28669-9-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.7.7.6
In-Reply-To: <1347306367-28669-1-git-send-email-konrad.wilk@oracle.com>
References: <1347306367-28669-1-git-send-email-konrad.wilk@oracle.com>
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: [Xen-devel] [PATCH 08/10] xen/swiotlb: Remove functions not needed
	anymore.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Sparse warns us off:
drivers/xen/swiotlb-xen.c:506:1: warning: symbol 'xen_swiotlb_map_sg' was not declared. Should it be static?
drivers/xen/swiotlb-xen.c:534:1: warning: symbol 'xen_swiotlb_unmap_sg' was not declared. Should it be static?

and it looks like we do not need this function at all.

Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 drivers/xen/swiotlb-xen.c |   16 ----------------
 include/xen/swiotlb-xen.h |    9 ---------
 2 files changed, 0 insertions(+), 25 deletions(-)

diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
index f0825cb..6f81994 100644
--- a/drivers/xen/swiotlb-xen.c
+++ b/drivers/xen/swiotlb-xen.c
@@ -514,14 +514,6 @@ xen_swiotlb_map_sg_attrs(struct device *hwdev, struct scatterlist *sgl,
 }
 EXPORT_SYMBOL_GPL(xen_swiotlb_map_sg_attrs);
 
-int
-xen_swiotlb_map_sg(struct device *hwdev, struct scatterlist *sgl, int nelems,
-		   enum dma_data_direction dir)
-{
-	return xen_swiotlb_map_sg_attrs(hwdev, sgl, nelems, dir, NULL);
-}
-EXPORT_SYMBOL_GPL(xen_swiotlb_map_sg);
-
 /*
  * Unmap a set of streaming mode DMA translations.  Again, cpu read rules
  * concerning calls here are the same as for swiotlb_unmap_page() above.
@@ -542,14 +534,6 @@ xen_swiotlb_unmap_sg_attrs(struct device *hwdev, struct scatterlist *sgl,
 }
 EXPORT_SYMBOL_GPL(xen_swiotlb_unmap_sg_attrs);
 
-void
-xen_swiotlb_unmap_sg(struct device *hwdev, struct scatterlist *sgl, int nelems,
-		     enum dma_data_direction dir)
-{
-	return xen_swiotlb_unmap_sg_attrs(hwdev, sgl, nelems, dir, NULL);
-}
-EXPORT_SYMBOL_GPL(xen_swiotlb_unmap_sg);
-
 /*
  * Make physical memory consistent for a set of streaming mode DMA translations
  * after a transfer.
diff --git a/include/xen/swiotlb-xen.h b/include/xen/swiotlb-xen.h
index f26f9f3..a0db2b7 100644
--- a/include/xen/swiotlb-xen.h
+++ b/include/xen/swiotlb-xen.h
@@ -23,15 +23,6 @@ extern dma_addr_t xen_swiotlb_map_page(struct device *dev, struct page *page,
 extern void xen_swiotlb_unmap_page(struct device *hwdev, dma_addr_t dev_addr,
 				   size_t size, enum dma_data_direction dir,
 				   struct dma_attrs *attrs);
-/*
-extern int
-xen_swiotlb_map_sg(struct device *hwdev, struct scatterlist *sg, int nents,
-		   enum dma_data_direction dir);
-
-extern void
-xen_swiotlb_unmap_sg(struct device *hwdev, struct scatterlist *sg, int nents,
-		     enum dma_data_direction dir);
-*/
 extern int
 xen_swiotlb_map_sg_attrs(struct device *hwdev, struct scatterlist *sgl,
 			 int nelems, enum dma_data_direction dir,
-- 
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 Sep 10 19:57:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Sep 2012 19: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 1TBA6L-0004SA-Oy; Mon, 10 Sep 2012 19:56:57 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1TBA6K-0004Rn-0Y
	for xen-devel@lists.xensource.com; Mon, 10 Sep 2012 19:56:56 +0000
Received: from [85.158.143.35:54606] by server-2.bemta-4.messagelabs.com id
	40/09-21239-7064E405; Mon, 10 Sep 2012 19:56:55 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1347307013!6623896!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDc0NzYwMw==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11721 invoked from network); 10 Sep 2012 19:56:54 -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; 10 Sep 2012 19:56:54 -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 q8AJunYH010990
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 10 Sep 2012 19:56:49 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
	q8AJumBH013915
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 10 Sep 2012 19:56:48 GMT
Received: from abhmt110.oracle.com (abhmt110.oracle.com [141.146.116.62])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q8AJumJ5001274; Mon, 10 Sep 2012 14:56:48 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 10 Sep 2012 12:56:48 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id CA28D402E4; Mon, 10 Sep 2012 15:46:08 -0400 (EDT)
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: linux-kernel@vger.kernel.org, xen-devel@lists.xensource.com,
	stefano.stabellini@eu.citrix.com
Date: Mon, 10 Sep 2012 15:45:57 -0400
Message-Id: <1347306367-28669-1-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.7.7.6
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Subject: [Xen-devel] [PATCH] Xen-SWIOTLB fixes (v4) for v3.7
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

The original problem was:
<begin>
"if one boots a PV 64-bit guests with more than 4GB, the SWIOTLB [Xen]
gets turned on - and 64MB of precious low-memory gets used." was totally
bogus. The SWIOTLB that gets turned on is the *native* one - which does
not exhaust any low-memory of the host. But it does eat up perfectly
fine 64MB of the guest and never gets used.

So this patchset has some things I wanted to do for some time:
 [PATCH 01/10] xen/swiotlb: Simplify the logic.

Just so that next time I am not confused.

 [PATCH 02/10] xen/swiotlb: With more than 4GB on 64-bit, disable the

and don't turn the *native* SWIOTLB on PV guests and waste those 64MB.
<end>


The rest are  exciting new patches - basically I want to emulate what
IA64 does which is to turn on the SWIOTLB late in the bootup cycle.
This means not using the alloc_bootmem and having a "late" variant
to initialize SWIOTLB. There is some surgery in the SWIOTLB library:
 [PATCH 03/10] swiotlb: add the late swiotlb initialization function

to allow it to use an io_tlb passed in. Note: I hadn't tested this
on IA64 and that is something I need to do.

And then the implementation in the Xen-SWIOTLB to use it:
 [PATCH 06/10] xen/swiotlb: Use the swiotlb_late_init_with_tbl to
along with Xen PCI frontend to utilize it.
 [PATCH 07/10] xen/pcifront: Use Xen-SWIOTLB when initting if

The end result is that a PV guest can now dynamically(*) deal with
PCI passthrough cards. I say "dynamically" b/c if one boots a PV guest
with more than 3GB without using 'e820_hole' (or is it called 'e820_host'
now?) the PCI subsystem won't be able to squeeze the BARs as they
are RAM occupied. The workaround is to boot with 'e820_hole' or some
new work where we manipulate at boot time the E820 to leave a nice
big 1GB hole under 4G - and with all the work on the P2M tree that
should be fairly easy actually.

Note: If one uses 'iommu=soft' on the Linux command line, the Xen-SWIOTLB
still gets turned on.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 10 19:57:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Sep 2012 19: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 1TBA6M-0004SW-H2; Mon, 10 Sep 2012 19:56:58 +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 1TBA6K-0004Ro-8u
	for xen-devel@lists.xensource.com; Mon, 10 Sep 2012 19:56:56 +0000
Received: from [85.158.139.83:45023] by server-2.bemta-5.messagelabs.com id
	B6/BC-11456-7064E405; Mon, 10 Sep 2012 19:56:55 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1347307013!29512393!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDc0NzYwMw==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21527 invoked from network); 10 Sep 2012 19:56:54 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-12.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 10 Sep 2012 19:56:54 -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 q8AJum6C010980
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 10 Sep 2012 19:56:49 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
	q8AJulKC013904
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 10 Sep 2012 19:56:48 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
	q8AJulbt018813; Mon, 10 Sep 2012 14:56:47 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 10 Sep 2012 12:56:47 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id D0D8C402E8; Mon, 10 Sep 2012 15:46:08 -0400 (EDT)
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: linux-kernel@vger.kernel.org, xen-devel@lists.xensource.com,
	stefano.stabellini@eu.citrix.com
Date: Mon, 10 Sep 2012 15:45:58 -0400
Message-Id: <1347306367-28669-2-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.7.7.6
In-Reply-To: <1347306367-28669-1-git-send-email-konrad.wilk@oracle.com>
References: <1347306367-28669-1-git-send-email-konrad.wilk@oracle.com>
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: [Xen-devel] [PATCH 01/10] xen/swiotlb: Simplify the logic.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Its pretty easy:
 1). We only check to see if we need Xen SWIOTLB for PV guests.
 2). If swiotlb=force or iommu=soft is set, then Xen SWIOTLB will
     be enabled.
 3). If it is an initial domain, then Xen SWIOTLB will be enabled.
 4). Native SWIOTLB must be disabled for PV guests.

Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 arch/x86/xen/pci-swiotlb-xen.c |    9 +++++----
 1 files changed, 5 insertions(+), 4 deletions(-)

diff --git a/arch/x86/xen/pci-swiotlb-xen.c b/arch/x86/xen/pci-swiotlb-xen.c
index 967633a..b6a5340 100644
--- a/arch/x86/xen/pci-swiotlb-xen.c
+++ b/arch/x86/xen/pci-swiotlb-xen.c
@@ -34,19 +34,20 @@ static struct dma_map_ops xen_swiotlb_dma_ops = {
 int __init pci_xen_swiotlb_detect(void)
 {
 
+	if (!xen_pv_domain())
+		return 0;
+
 	/* If running as PV guest, either iommu=soft, or swiotlb=force will
 	 * activate this IOMMU. If running as PV privileged, activate it
 	 * irregardless.
 	 */
-	if ((xen_initial_domain() || swiotlb || swiotlb_force) &&
-	    (xen_pv_domain()))
+	if ((xen_initial_domain() || swiotlb || swiotlb_force))
 		xen_swiotlb = 1;
 
 	/* If we are running under Xen, we MUST disable the native SWIOTLB.
 	 * Don't worry about swiotlb_force flag activating the native, as
 	 * the 'swiotlb' flag is the only one turning it on. */
-	if (xen_pv_domain())
-		swiotlb = 0;
+	swiotlb = 0;
 
 	return xen_swiotlb;
 }
-- 
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 Sep 10 19:57:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Sep 2012 19: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 1TBA6L-0004SA-Oy; Mon, 10 Sep 2012 19:56:57 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1TBA6K-0004Rn-0Y
	for xen-devel@lists.xensource.com; Mon, 10 Sep 2012 19:56:56 +0000
Received: from [85.158.143.35:54606] by server-2.bemta-4.messagelabs.com id
	40/09-21239-7064E405; Mon, 10 Sep 2012 19:56:55 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1347307013!6623896!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDc0NzYwMw==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11721 invoked from network); 10 Sep 2012 19:56:54 -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; 10 Sep 2012 19:56:54 -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 q8AJunYH010990
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 10 Sep 2012 19:56:49 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
	q8AJumBH013915
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 10 Sep 2012 19:56:48 GMT
Received: from abhmt110.oracle.com (abhmt110.oracle.com [141.146.116.62])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q8AJumJ5001274; Mon, 10 Sep 2012 14:56:48 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 10 Sep 2012 12:56:48 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id CA28D402E4; Mon, 10 Sep 2012 15:46:08 -0400 (EDT)
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: linux-kernel@vger.kernel.org, xen-devel@lists.xensource.com,
	stefano.stabellini@eu.citrix.com
Date: Mon, 10 Sep 2012 15:45:57 -0400
Message-Id: <1347306367-28669-1-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.7.7.6
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Subject: [Xen-devel] [PATCH] Xen-SWIOTLB fixes (v4) for v3.7
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

The original problem was:
<begin>
"if one boots a PV 64-bit guests with more than 4GB, the SWIOTLB [Xen]
gets turned on - and 64MB of precious low-memory gets used." was totally
bogus. The SWIOTLB that gets turned on is the *native* one - which does
not exhaust any low-memory of the host. But it does eat up perfectly
fine 64MB of the guest and never gets used.

So this patchset has some things I wanted to do for some time:
 [PATCH 01/10] xen/swiotlb: Simplify the logic.

Just so that next time I am not confused.

 [PATCH 02/10] xen/swiotlb: With more than 4GB on 64-bit, disable the

and don't turn the *native* SWIOTLB on PV guests and waste those 64MB.
<end>


The rest are  exciting new patches - basically I want to emulate what
IA64 does which is to turn on the SWIOTLB late in the bootup cycle.
This means not using the alloc_bootmem and having a "late" variant
to initialize SWIOTLB. There is some surgery in the SWIOTLB library:
 [PATCH 03/10] swiotlb: add the late swiotlb initialization function

to allow it to use an io_tlb passed in. Note: I hadn't tested this
on IA64 and that is something I need to do.

And then the implementation in the Xen-SWIOTLB to use it:
 [PATCH 06/10] xen/swiotlb: Use the swiotlb_late_init_with_tbl to
along with Xen PCI frontend to utilize it.
 [PATCH 07/10] xen/pcifront: Use Xen-SWIOTLB when initting if

The end result is that a PV guest can now dynamically(*) deal with
PCI passthrough cards. I say "dynamically" b/c if one boots a PV guest
with more than 3GB without using 'e820_hole' (or is it called 'e820_host'
now?) the PCI subsystem won't be able to squeeze the BARs as they
are RAM occupied. The workaround is to boot with 'e820_hole' or some
new work where we manipulate at boot time the E820 to leave a nice
big 1GB hole under 4G - and with all the work on the P2M tree that
should be fairly easy actually.

Note: If one uses 'iommu=soft' on the Linux command line, the Xen-SWIOTLB
still gets turned on.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 10 19:57:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Sep 2012 19: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 1TBA6M-0004SW-H2; Mon, 10 Sep 2012 19:56:58 +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 1TBA6K-0004Ro-8u
	for xen-devel@lists.xensource.com; Mon, 10 Sep 2012 19:56:56 +0000
Received: from [85.158.139.83:45023] by server-2.bemta-5.messagelabs.com id
	B6/BC-11456-7064E405; Mon, 10 Sep 2012 19:56:55 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1347307013!29512393!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDc0NzYwMw==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21527 invoked from network); 10 Sep 2012 19:56:54 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-12.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 10 Sep 2012 19:56:54 -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 q8AJum6C010980
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 10 Sep 2012 19:56:49 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
	q8AJulKC013904
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 10 Sep 2012 19:56:48 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
	q8AJulbt018813; Mon, 10 Sep 2012 14:56:47 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 10 Sep 2012 12:56:47 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id D0D8C402E8; Mon, 10 Sep 2012 15:46:08 -0400 (EDT)
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: linux-kernel@vger.kernel.org, xen-devel@lists.xensource.com,
	stefano.stabellini@eu.citrix.com
Date: Mon, 10 Sep 2012 15:45:58 -0400
Message-Id: <1347306367-28669-2-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.7.7.6
In-Reply-To: <1347306367-28669-1-git-send-email-konrad.wilk@oracle.com>
References: <1347306367-28669-1-git-send-email-konrad.wilk@oracle.com>
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: [Xen-devel] [PATCH 01/10] xen/swiotlb: Simplify the logic.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Its pretty easy:
 1). We only check to see if we need Xen SWIOTLB for PV guests.
 2). If swiotlb=force or iommu=soft is set, then Xen SWIOTLB will
     be enabled.
 3). If it is an initial domain, then Xen SWIOTLB will be enabled.
 4). Native SWIOTLB must be disabled for PV guests.

Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 arch/x86/xen/pci-swiotlb-xen.c |    9 +++++----
 1 files changed, 5 insertions(+), 4 deletions(-)

diff --git a/arch/x86/xen/pci-swiotlb-xen.c b/arch/x86/xen/pci-swiotlb-xen.c
index 967633a..b6a5340 100644
--- a/arch/x86/xen/pci-swiotlb-xen.c
+++ b/arch/x86/xen/pci-swiotlb-xen.c
@@ -34,19 +34,20 @@ static struct dma_map_ops xen_swiotlb_dma_ops = {
 int __init pci_xen_swiotlb_detect(void)
 {
 
+	if (!xen_pv_domain())
+		return 0;
+
 	/* If running as PV guest, either iommu=soft, or swiotlb=force will
 	 * activate this IOMMU. If running as PV privileged, activate it
 	 * irregardless.
 	 */
-	if ((xen_initial_domain() || swiotlb || swiotlb_force) &&
-	    (xen_pv_domain()))
+	if ((xen_initial_domain() || swiotlb || swiotlb_force))
 		xen_swiotlb = 1;
 
 	/* If we are running under Xen, we MUST disable the native SWIOTLB.
 	 * Don't worry about swiotlb_force flag activating the native, as
 	 * the 'swiotlb' flag is the only one turning it on. */
-	if (xen_pv_domain())
-		swiotlb = 0;
+	swiotlb = 0;
 
 	return xen_swiotlb;
 }
-- 
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 Sep 10 19:57:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Sep 2012 19: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 1TBA6P-0004Tw-1c; Mon, 10 Sep 2012 19:57: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 1TBA6N-0004Rn-P9
	for xen-devel@lists.xensource.com; Mon, 10 Sep 2012 19:56:59 +0000
Received: from [85.158.143.35:54755] by server-2.bemta-4.messagelabs.com id
	EA/09-21239-B064E405; Mon, 10 Sep 2012 19:56:59 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1347307017!14323213!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDc0NzYwMw==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13914 invoked from network); 10 Sep 2012 19:56:58 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-8.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 10 Sep 2012 19:56:58 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q8AJuqiZ011050
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 10 Sep 2012 19:56:52 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q8AJupoU017586
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 10 Sep 2012 19:56:52 GMT
Received: from abhmt104.oracle.com (abhmt104.oracle.com [141.146.116.56])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q8AJumt0018820; Mon, 10 Sep 2012 14:56:48 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 10 Sep 2012 12:56:48 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id EF0B44031C; Mon, 10 Sep 2012 15:46:08 -0400 (EDT)
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: linux-kernel@vger.kernel.org, xen-devel@lists.xensource.com,
	stefano.stabellini@eu.citrix.com
Date: Mon, 10 Sep 2012 15:46:01 -0400
Message-Id: <1347306367-28669-5-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.7.7.6
In-Reply-To: <1347306367-28669-1-git-send-email-konrad.wilk@oracle.com>
References: <1347306367-28669-1-git-send-email-konrad.wilk@oracle.com>
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: [Xen-devel] [PATCH 04/10] xen/swiotlb: Move the nr_tbl
	determination in its own 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

Moving the function out of the way to prepare for the late
SWIOTLB init.

Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 drivers/xen/swiotlb-xen.c |   21 +++++++++++----------
 1 files changed, 11 insertions(+), 10 deletions(-)

diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
index 1afb4fb..a2aad6e 100644
--- a/drivers/xen/swiotlb-xen.c
+++ b/drivers/xen/swiotlb-xen.c
@@ -144,25 +144,26 @@ xen_swiotlb_fixup(void *buf, size_t size, unsigned long nslabs)
 	} while (i < nslabs);
 	return 0;
 }
+static unsigned long xen_set_nslabs(unsigned long nr_tbl)
+{
+	if (!nr_tbl) {
+		xen_io_tlb_nslabs = (64 * 1024 * 1024 >> IO_TLB_SHIFT);
+		xen_io_tlb_nslabs = ALIGN(xen_io_tlb_nslabs, IO_TLB_SEGSIZE);
+	} else
+		xen_io_tlb_nslabs = nr_tbl;
 
+	return xen_io_tlb_nslabs << IO_TLB_SHIFT;
+}
 void __init xen_swiotlb_init(int verbose)
 {
 	unsigned long bytes;
 	int rc = -ENOMEM;
-	unsigned long nr_tbl;
 	char *m = NULL;
 	unsigned int repeat = 3;
 
-	nr_tbl = swiotlb_nr_tbl();
-	if (nr_tbl)
-		xen_io_tlb_nslabs = nr_tbl;
-	else {
-		xen_io_tlb_nslabs = (64 * 1024 * 1024 >> IO_TLB_SHIFT);
-		xen_io_tlb_nslabs = ALIGN(xen_io_tlb_nslabs, IO_TLB_SEGSIZE);
-	}
+	xen_io_tlb_nslabs = swiotlb_nr_tbl();
 retry:
-	bytes = xen_io_tlb_nslabs << IO_TLB_SHIFT;
-
+	bytes = xen_set_nslabs(xen_io_tlb_nslabs);
 	/*
 	 * Get IO TLB memory from any location.
 	 */
-- 
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 Sep 10 19:57:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Sep 2012 19: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 1TBA6P-0004Tw-1c; Mon, 10 Sep 2012 19:57: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 1TBA6N-0004Rn-P9
	for xen-devel@lists.xensource.com; Mon, 10 Sep 2012 19:56:59 +0000
Received: from [85.158.143.35:54755] by server-2.bemta-4.messagelabs.com id
	EA/09-21239-B064E405; Mon, 10 Sep 2012 19:56:59 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1347307017!14323213!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDc0NzYwMw==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13914 invoked from network); 10 Sep 2012 19:56:58 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-8.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 10 Sep 2012 19:56:58 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q8AJuqiZ011050
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 10 Sep 2012 19:56:52 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q8AJupoU017586
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 10 Sep 2012 19:56:52 GMT
Received: from abhmt104.oracle.com (abhmt104.oracle.com [141.146.116.56])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q8AJumt0018820; Mon, 10 Sep 2012 14:56:48 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 10 Sep 2012 12:56:48 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id EF0B44031C; Mon, 10 Sep 2012 15:46:08 -0400 (EDT)
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: linux-kernel@vger.kernel.org, xen-devel@lists.xensource.com,
	stefano.stabellini@eu.citrix.com
Date: Mon, 10 Sep 2012 15:46:01 -0400
Message-Id: <1347306367-28669-5-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.7.7.6
In-Reply-To: <1347306367-28669-1-git-send-email-konrad.wilk@oracle.com>
References: <1347306367-28669-1-git-send-email-konrad.wilk@oracle.com>
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: [Xen-devel] [PATCH 04/10] xen/swiotlb: Move the nr_tbl
	determination in its own 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

Moving the function out of the way to prepare for the late
SWIOTLB init.

Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 drivers/xen/swiotlb-xen.c |   21 +++++++++++----------
 1 files changed, 11 insertions(+), 10 deletions(-)

diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
index 1afb4fb..a2aad6e 100644
--- a/drivers/xen/swiotlb-xen.c
+++ b/drivers/xen/swiotlb-xen.c
@@ -144,25 +144,26 @@ xen_swiotlb_fixup(void *buf, size_t size, unsigned long nslabs)
 	} while (i < nslabs);
 	return 0;
 }
+static unsigned long xen_set_nslabs(unsigned long nr_tbl)
+{
+	if (!nr_tbl) {
+		xen_io_tlb_nslabs = (64 * 1024 * 1024 >> IO_TLB_SHIFT);
+		xen_io_tlb_nslabs = ALIGN(xen_io_tlb_nslabs, IO_TLB_SEGSIZE);
+	} else
+		xen_io_tlb_nslabs = nr_tbl;
 
+	return xen_io_tlb_nslabs << IO_TLB_SHIFT;
+}
 void __init xen_swiotlb_init(int verbose)
 {
 	unsigned long bytes;
 	int rc = -ENOMEM;
-	unsigned long nr_tbl;
 	char *m = NULL;
 	unsigned int repeat = 3;
 
-	nr_tbl = swiotlb_nr_tbl();
-	if (nr_tbl)
-		xen_io_tlb_nslabs = nr_tbl;
-	else {
-		xen_io_tlb_nslabs = (64 * 1024 * 1024 >> IO_TLB_SHIFT);
-		xen_io_tlb_nslabs = ALIGN(xen_io_tlb_nslabs, IO_TLB_SEGSIZE);
-	}
+	xen_io_tlb_nslabs = swiotlb_nr_tbl();
 retry:
-	bytes = xen_io_tlb_nslabs << IO_TLB_SHIFT;
-
+	bytes = xen_set_nslabs(xen_io_tlb_nslabs);
 	/*
 	 * Get IO TLB memory from any location.
 	 */
-- 
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 Sep 10 19:57:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Sep 2012 19:57:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TBA6M-0004SL-4n; Mon, 10 Sep 2012 19:56:58 +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 1TBA6K-0004Rp-9E
	for xen-devel@lists.xensource.com; Mon, 10 Sep 2012 19:56:56 +0000
Received: from [85.158.143.99:44107] by server-3.bemta-4.messagelabs.com id
	75/7C-08232-7064E405; Mon, 10 Sep 2012 19:56:55 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1347307013!29254866!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDc0NzYwMw==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14303 invoked from network); 10 Sep 2012 19:56:54 -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; 10 Sep 2012 19:56:54 -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 q8AJunVn010989
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 10 Sep 2012 19:56:49 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
	q8AJumlu013916
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 10 Sep 2012 19:56:49 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
	q8AJum76001278; Mon, 10 Sep 2012 14:56:48 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 10 Sep 2012 12:56:48 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id D8112402F0; Mon, 10 Sep 2012 15:46:08 -0400 (EDT)
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: linux-kernel@vger.kernel.org, xen-devel@lists.xensource.com,
	stefano.stabellini@eu.citrix.com
Date: Mon, 10 Sep 2012 15:45:59 -0400
Message-Id: <1347306367-28669-3-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.7.7.6
In-Reply-To: <1347306367-28669-1-git-send-email-konrad.wilk@oracle.com>
References: <1347306367-28669-1-git-send-email-konrad.wilk@oracle.com>
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: [Xen-devel] [PATCH 02/10] xen/swiotlb: With more than 4GB on 64-bit,
	disable the native SWIOTLB.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 PV guest is booted the native SWIOTLB should not be
turned on. It does not help us (we don't have any PCI devices)
and it eats 64MB of good memory. In the case of PV guests
with PCI devices we need the Xen-SWIOTLB one.

[v1: Rewrite comment per Stefano's suggestion]
Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 arch/x86/xen/pci-swiotlb-xen.c |   14 ++++++++++++++
 1 files changed, 14 insertions(+), 0 deletions(-)

diff --git a/arch/x86/xen/pci-swiotlb-xen.c b/arch/x86/xen/pci-swiotlb-xen.c
index b6a5340..1c17227 100644
--- a/arch/x86/xen/pci-swiotlb-xen.c
+++ b/arch/x86/xen/pci-swiotlb-xen.c
@@ -8,6 +8,11 @@
 #include <xen/xen.h>
 #include <asm/iommu_table.h>
 
+#ifdef CONFIG_X86_64
+#include <asm/iommu.h>
+#include <asm/dma.h>
+#endif
+
 int xen_swiotlb __read_mostly;
 
 static struct dma_map_ops xen_swiotlb_dma_ops = {
@@ -49,6 +54,15 @@ int __init pci_xen_swiotlb_detect(void)
 	 * the 'swiotlb' flag is the only one turning it on. */
 	swiotlb = 0;
 
+#ifdef CONFIG_X86_64
+	/* pci_swiotlb_detect_4gb turns on native SWIOTLB if no_iommu == 0
+	 * (so no iommu=X command line over-writes).
+	 * Considering that PV guests do not want the *native SWIOTLB* but
+	 * only Xen SWIOTLB it is not useful to us so set no_iommu=1 here.
+	 */
+	if (max_pfn > MAX_DMA32_PFN)
+		no_iommu = 1;
+#endif
 	return xen_swiotlb;
 }
 
-- 
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 Sep 10 19:57:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Sep 2012 19:57:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TBA6M-0004SL-4n; Mon, 10 Sep 2012 19:56:58 +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 1TBA6K-0004Rp-9E
	for xen-devel@lists.xensource.com; Mon, 10 Sep 2012 19:56:56 +0000
Received: from [85.158.143.99:44107] by server-3.bemta-4.messagelabs.com id
	75/7C-08232-7064E405; Mon, 10 Sep 2012 19:56:55 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1347307013!29254866!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDc0NzYwMw==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14303 invoked from network); 10 Sep 2012 19:56:54 -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; 10 Sep 2012 19:56:54 -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 q8AJunVn010989
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 10 Sep 2012 19:56:49 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
	q8AJumlu013916
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 10 Sep 2012 19:56:49 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
	q8AJum76001278; Mon, 10 Sep 2012 14:56:48 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 10 Sep 2012 12:56:48 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id D8112402F0; Mon, 10 Sep 2012 15:46:08 -0400 (EDT)
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: linux-kernel@vger.kernel.org, xen-devel@lists.xensource.com,
	stefano.stabellini@eu.citrix.com
Date: Mon, 10 Sep 2012 15:45:59 -0400
Message-Id: <1347306367-28669-3-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.7.7.6
In-Reply-To: <1347306367-28669-1-git-send-email-konrad.wilk@oracle.com>
References: <1347306367-28669-1-git-send-email-konrad.wilk@oracle.com>
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: [Xen-devel] [PATCH 02/10] xen/swiotlb: With more than 4GB on 64-bit,
	disable the native SWIOTLB.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 PV guest is booted the native SWIOTLB should not be
turned on. It does not help us (we don't have any PCI devices)
and it eats 64MB of good memory. In the case of PV guests
with PCI devices we need the Xen-SWIOTLB one.

[v1: Rewrite comment per Stefano's suggestion]
Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 arch/x86/xen/pci-swiotlb-xen.c |   14 ++++++++++++++
 1 files changed, 14 insertions(+), 0 deletions(-)

diff --git a/arch/x86/xen/pci-swiotlb-xen.c b/arch/x86/xen/pci-swiotlb-xen.c
index b6a5340..1c17227 100644
--- a/arch/x86/xen/pci-swiotlb-xen.c
+++ b/arch/x86/xen/pci-swiotlb-xen.c
@@ -8,6 +8,11 @@
 #include <xen/xen.h>
 #include <asm/iommu_table.h>
 
+#ifdef CONFIG_X86_64
+#include <asm/iommu.h>
+#include <asm/dma.h>
+#endif
+
 int xen_swiotlb __read_mostly;
 
 static struct dma_map_ops xen_swiotlb_dma_ops = {
@@ -49,6 +54,15 @@ int __init pci_xen_swiotlb_detect(void)
 	 * the 'swiotlb' flag is the only one turning it on. */
 	swiotlb = 0;
 
+#ifdef CONFIG_X86_64
+	/* pci_swiotlb_detect_4gb turns on native SWIOTLB if no_iommu == 0
+	 * (so no iommu=X command line over-writes).
+	 * Considering that PV guests do not want the *native SWIOTLB* but
+	 * only Xen SWIOTLB it is not useful to us so set no_iommu=1 here.
+	 */
+	if (max_pfn > MAX_DMA32_PFN)
+		no_iommu = 1;
+#endif
 	return xen_swiotlb;
 }
 
-- 
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 Sep 10 19:57:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Sep 2012 19:57:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TBA6O-0004Th-Mo; Mon, 10 Sep 2012 19: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 1TBA6N-0004Sf-9K
	for xen-devel@lists.xensource.com; Mon, 10 Sep 2012 19:56:59 +0000
Received: from [85.158.138.51:41792] by server-10.bemta-3.messagelabs.com id
	2E/7B-10411-A064E405; Mon, 10 Sep 2012 19:56:58 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1347307016!29674424!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDc0NzYwMw==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29561 invoked from network); 10 Sep 2012 19:56:57 -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; 10 Sep 2012 19:56:57 -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 q8AJunv1011005
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 10 Sep 2012 19:56:50 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q8AJumGQ013918
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 10 Sep 2012 19:56:49 GMT
Received: from abhmt115.oracle.com (abhmt115.oracle.com [141.146.116.67])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q8AJumeq000543; Mon, 10 Sep 2012 14:56:48 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 10 Sep 2012 12:56:48 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 0DCA54032D; Mon, 10 Sep 2012 15:46:09 -0400 (EDT)
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: linux-kernel@vger.kernel.org, xen-devel@lists.xensource.com,
	stefano.stabellini@eu.citrix.com
Date: Mon, 10 Sep 2012 15:46:03 -0400
Message-Id: <1347306367-28669-7-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.7.7.6
In-Reply-To: <1347306367-28669-1-git-send-email-konrad.wilk@oracle.com>
References: <1347306367-28669-1-git-send-email-konrad.wilk@oracle.com>
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: [Xen-devel] [PATCH 06/10] xen/swiotlb: Use the
	swiotlb_late_init_with_tbl to init Xen-SWIOTLB late when PV
	PCI is 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>
MIME-Version: 1.0
Content-Type: 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 this patch we provide the functionality to initialize the
Xen-SWIOTLB late in the bootup cycle - specifically for
Xen PCI-frontend. We still will work if the user had
supplied 'iommu=soft' on the Linux command line.

CC: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
[v1: Fix smatch warnings]
[v2: Added check for xen_swiotlb]
[v3: Rebased with new xen-swiotlb changes]
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 arch/x86/include/asm/xen/swiotlb-xen.h |    2 +
 arch/x86/xen/pci-swiotlb-xen.c         |   22 ++++++++++++++-
 drivers/xen/swiotlb-xen.c              |   48 +++++++++++++++++++++++++------
 include/xen/swiotlb-xen.h              |    2 +-
 4 files changed, 62 insertions(+), 12 deletions(-)

diff --git a/arch/x86/include/asm/xen/swiotlb-xen.h b/arch/x86/include/asm/xen/swiotlb-xen.h
index 1be1ab7..ee52fca 100644
--- a/arch/x86/include/asm/xen/swiotlb-xen.h
+++ b/arch/x86/include/asm/xen/swiotlb-xen.h
@@ -5,10 +5,12 @@
 extern int xen_swiotlb;
 extern int __init pci_xen_swiotlb_detect(void);
 extern void __init pci_xen_swiotlb_init(void);
+extern int pci_xen_swiotlb_init_late(void);
 #else
 #define xen_swiotlb (0)
 static inline int __init pci_xen_swiotlb_detect(void) { return 0; }
 static inline void __init pci_xen_swiotlb_init(void) { }
+static inline int pci_xen_swiotlb_init_late(void) { return -ENXIO; }
 #endif
 
 #endif /* _ASM_X86_SWIOTLB_XEN_H */
diff --git a/arch/x86/xen/pci-swiotlb-xen.c b/arch/x86/xen/pci-swiotlb-xen.c
index 1c17227..406f9c4 100644
--- a/arch/x86/xen/pci-swiotlb-xen.c
+++ b/arch/x86/xen/pci-swiotlb-xen.c
@@ -12,7 +12,7 @@
 #include <asm/iommu.h>
 #include <asm/dma.h>
 #endif
-
+#include <linux/export.h>
 int xen_swiotlb __read_mostly;
 
 static struct dma_map_ops xen_swiotlb_dma_ops = {
@@ -76,6 +76,26 @@ void __init pci_xen_swiotlb_init(void)
 		pci_request_acs();
 	}
 }
+
+int pci_xen_swiotlb_init_late(void)
+{
+	int rc;
+
+	if (xen_swiotlb)
+		return 0;
+
+	rc = xen_swiotlb_init(1);
+	if (rc)
+		return rc;
+
+	dma_ops = &xen_swiotlb_dma_ops;
+	/* Make sure ACS will be enabled */
+	pci_request_acs();
+
+	return 0;
+}
+EXPORT_SYMBOL_GPL(pci_xen_swiotlb_init_late);
+
 IOMMU_INIT_FINISH(pci_xen_swiotlb_detect,
 		  0,
 		  pci_xen_swiotlb_init,
diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
index 701b103..f0825cb 100644
--- a/drivers/xen/swiotlb-xen.c
+++ b/drivers/xen/swiotlb-xen.c
@@ -176,9 +176,9 @@ static const char *xen_swiotlb_error(enum xen_swiotlb_err err)
 	}
 	return "";
 }
-void __init xen_swiotlb_init(int verbose)
+int __ref xen_swiotlb_init(int verbose)
 {
-	unsigned long bytes;
+	unsigned long bytes, order;
 	int rc = -ENOMEM;
 	enum xen_swiotlb_err m_ret = XEN_SWIOTLB_UNKNOWN;
 	unsigned int repeat = 3;
@@ -186,10 +186,28 @@ void __init xen_swiotlb_init(int verbose)
 	xen_io_tlb_nslabs = swiotlb_nr_tbl();
 retry:
 	bytes = xen_set_nslabs(xen_io_tlb_nslabs);
+	order = get_order(xen_io_tlb_nslabs << IO_TLB_SHIFT);
 	/*
 	 * Get IO TLB memory from any location.
 	 */
-	xen_io_tlb_start = alloc_bootmem_pages(PAGE_ALIGN(bytes));
+	if (!after_bootmem)
+		xen_io_tlb_start = alloc_bootmem_pages(PAGE_ALIGN(bytes));
+	else {
+#define SLABS_PER_PAGE (1 << (PAGE_SHIFT - IO_TLB_SHIFT))
+#define IO_TLB_MIN_SLABS ((1<<20) >> IO_TLB_SHIFT)
+		while ((SLABS_PER_PAGE << order) > IO_TLB_MIN_SLABS) {
+			xen_io_tlb_start = (void *)__get_free_pages(__GFP_NOWARN, order);
+			if (xen_io_tlb_start)
+				break;
+			order--;
+		}
+		if (order != get_order(bytes)) {
+			pr_warn("Warning: only able to allocate %ld MB "
+				"for software IO TLB\n", (PAGE_SIZE << order) >> 20);
+			xen_io_tlb_nslabs = SLABS_PER_PAGE << order;
+			bytes = xen_io_tlb_nslabs << IO_TLB_SHIFT;
+		}
+	}
 	if (!xen_io_tlb_start) {
 		m_ret = XEN_SWIOTLB_ENOMEM;
 		goto error;
@@ -202,14 +220,21 @@ retry:
 			       bytes,
 			       xen_io_tlb_nslabs);
 	if (rc) {
-		free_bootmem(__pa(xen_io_tlb_start), PAGE_ALIGN(bytes));
+		if (!after_bootmem)
+			free_bootmem(__pa(xen_io_tlb_start), PAGE_ALIGN(bytes));
+		else {
+			free_pages((unsigned long)xen_io_tlb_start, order);
+			xen_io_tlb_start = NULL;
+		}
 		m_ret = XEN_SWIOTLB_EFIXUP;
 		goto error;
 	}
 	start_dma_addr = xen_virt_to_bus(xen_io_tlb_start);
-	swiotlb_init_with_tbl(xen_io_tlb_start, xen_io_tlb_nslabs, verbose);
-
-	return;
+	if (!after_bootmem)
+		swiotlb_init_with_tbl(xen_io_tlb_start, xen_io_tlb_nslabs, verbose);
+	else
+		rc = swiotlb_late_init_with_tbl(xen_io_tlb_start, xen_io_tlb_nslabs);
+	return rc;
 error:
 	if (repeat--) {
 		xen_io_tlb_nslabs = max(1024UL, /* Min is 2MB */
@@ -218,10 +243,13 @@ error:
 		      (xen_io_tlb_nslabs << IO_TLB_SHIFT) >> 20);
 		goto retry;
 	}
-	xen_raw_printk("%s (rc:%d)", xen_swiotlb_error(m_ret), rc);
-	panic("%s (rc:%d)", xen_swiotlb_error(m_ret), rc);
+	pr_err("%s (rc:%d)", xen_swiotlb_error(m_ret), rc);
+	if (!after_bootmem)
+		panic("%s (rc:%d)", xen_swiotlb_error(m_ret), rc);
+	else
+		free_pages((unsigned long)xen_io_tlb_start, order);
+	return rc;
 }
-
 void *
 xen_swiotlb_alloc_coherent(struct device *hwdev, size_t size,
 			   dma_addr_t *dma_handle, gfp_t flags,
diff --git a/include/xen/swiotlb-xen.h b/include/xen/swiotlb-xen.h
index 4f4d449..f26f9f3 100644
--- a/include/xen/swiotlb-xen.h
+++ b/include/xen/swiotlb-xen.h
@@ -3,7 +3,7 @@
 
 #include <linux/swiotlb.h>
 
-extern void xen_swiotlb_init(int verbose);
+extern int xen_swiotlb_init(int verbose);
 
 extern void
 *xen_swiotlb_alloc_coherent(struct device *hwdev, size_t size,
-- 
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 Sep 10 19:57:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Sep 2012 19:57:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TBA6O-0004Th-Mo; Mon, 10 Sep 2012 19: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 1TBA6N-0004Sf-9K
	for xen-devel@lists.xensource.com; Mon, 10 Sep 2012 19:56:59 +0000
Received: from [85.158.138.51:41792] by server-10.bemta-3.messagelabs.com id
	2E/7B-10411-A064E405; Mon, 10 Sep 2012 19:56:58 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1347307016!29674424!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDc0NzYwMw==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29561 invoked from network); 10 Sep 2012 19:56:57 -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; 10 Sep 2012 19:56:57 -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 q8AJunv1011005
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 10 Sep 2012 19:56:50 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q8AJumGQ013918
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 10 Sep 2012 19:56:49 GMT
Received: from abhmt115.oracle.com (abhmt115.oracle.com [141.146.116.67])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q8AJumeq000543; Mon, 10 Sep 2012 14:56:48 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 10 Sep 2012 12:56:48 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 0DCA54032D; Mon, 10 Sep 2012 15:46:09 -0400 (EDT)
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: linux-kernel@vger.kernel.org, xen-devel@lists.xensource.com,
	stefano.stabellini@eu.citrix.com
Date: Mon, 10 Sep 2012 15:46:03 -0400
Message-Id: <1347306367-28669-7-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.7.7.6
In-Reply-To: <1347306367-28669-1-git-send-email-konrad.wilk@oracle.com>
References: <1347306367-28669-1-git-send-email-konrad.wilk@oracle.com>
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: [Xen-devel] [PATCH 06/10] xen/swiotlb: Use the
	swiotlb_late_init_with_tbl to init Xen-SWIOTLB late when PV
	PCI is 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>
MIME-Version: 1.0
Content-Type: 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 this patch we provide the functionality to initialize the
Xen-SWIOTLB late in the bootup cycle - specifically for
Xen PCI-frontend. We still will work if the user had
supplied 'iommu=soft' on the Linux command line.

CC: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
[v1: Fix smatch warnings]
[v2: Added check for xen_swiotlb]
[v3: Rebased with new xen-swiotlb changes]
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 arch/x86/include/asm/xen/swiotlb-xen.h |    2 +
 arch/x86/xen/pci-swiotlb-xen.c         |   22 ++++++++++++++-
 drivers/xen/swiotlb-xen.c              |   48 +++++++++++++++++++++++++------
 include/xen/swiotlb-xen.h              |    2 +-
 4 files changed, 62 insertions(+), 12 deletions(-)

diff --git a/arch/x86/include/asm/xen/swiotlb-xen.h b/arch/x86/include/asm/xen/swiotlb-xen.h
index 1be1ab7..ee52fca 100644
--- a/arch/x86/include/asm/xen/swiotlb-xen.h
+++ b/arch/x86/include/asm/xen/swiotlb-xen.h
@@ -5,10 +5,12 @@
 extern int xen_swiotlb;
 extern int __init pci_xen_swiotlb_detect(void);
 extern void __init pci_xen_swiotlb_init(void);
+extern int pci_xen_swiotlb_init_late(void);
 #else
 #define xen_swiotlb (0)
 static inline int __init pci_xen_swiotlb_detect(void) { return 0; }
 static inline void __init pci_xen_swiotlb_init(void) { }
+static inline int pci_xen_swiotlb_init_late(void) { return -ENXIO; }
 #endif
 
 #endif /* _ASM_X86_SWIOTLB_XEN_H */
diff --git a/arch/x86/xen/pci-swiotlb-xen.c b/arch/x86/xen/pci-swiotlb-xen.c
index 1c17227..406f9c4 100644
--- a/arch/x86/xen/pci-swiotlb-xen.c
+++ b/arch/x86/xen/pci-swiotlb-xen.c
@@ -12,7 +12,7 @@
 #include <asm/iommu.h>
 #include <asm/dma.h>
 #endif
-
+#include <linux/export.h>
 int xen_swiotlb __read_mostly;
 
 static struct dma_map_ops xen_swiotlb_dma_ops = {
@@ -76,6 +76,26 @@ void __init pci_xen_swiotlb_init(void)
 		pci_request_acs();
 	}
 }
+
+int pci_xen_swiotlb_init_late(void)
+{
+	int rc;
+
+	if (xen_swiotlb)
+		return 0;
+
+	rc = xen_swiotlb_init(1);
+	if (rc)
+		return rc;
+
+	dma_ops = &xen_swiotlb_dma_ops;
+	/* Make sure ACS will be enabled */
+	pci_request_acs();
+
+	return 0;
+}
+EXPORT_SYMBOL_GPL(pci_xen_swiotlb_init_late);
+
 IOMMU_INIT_FINISH(pci_xen_swiotlb_detect,
 		  0,
 		  pci_xen_swiotlb_init,
diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
index 701b103..f0825cb 100644
--- a/drivers/xen/swiotlb-xen.c
+++ b/drivers/xen/swiotlb-xen.c
@@ -176,9 +176,9 @@ static const char *xen_swiotlb_error(enum xen_swiotlb_err err)
 	}
 	return "";
 }
-void __init xen_swiotlb_init(int verbose)
+int __ref xen_swiotlb_init(int verbose)
 {
-	unsigned long bytes;
+	unsigned long bytes, order;
 	int rc = -ENOMEM;
 	enum xen_swiotlb_err m_ret = XEN_SWIOTLB_UNKNOWN;
 	unsigned int repeat = 3;
@@ -186,10 +186,28 @@ void __init xen_swiotlb_init(int verbose)
 	xen_io_tlb_nslabs = swiotlb_nr_tbl();
 retry:
 	bytes = xen_set_nslabs(xen_io_tlb_nslabs);
+	order = get_order(xen_io_tlb_nslabs << IO_TLB_SHIFT);
 	/*
 	 * Get IO TLB memory from any location.
 	 */
-	xen_io_tlb_start = alloc_bootmem_pages(PAGE_ALIGN(bytes));
+	if (!after_bootmem)
+		xen_io_tlb_start = alloc_bootmem_pages(PAGE_ALIGN(bytes));
+	else {
+#define SLABS_PER_PAGE (1 << (PAGE_SHIFT - IO_TLB_SHIFT))
+#define IO_TLB_MIN_SLABS ((1<<20) >> IO_TLB_SHIFT)
+		while ((SLABS_PER_PAGE << order) > IO_TLB_MIN_SLABS) {
+			xen_io_tlb_start = (void *)__get_free_pages(__GFP_NOWARN, order);
+			if (xen_io_tlb_start)
+				break;
+			order--;
+		}
+		if (order != get_order(bytes)) {
+			pr_warn("Warning: only able to allocate %ld MB "
+				"for software IO TLB\n", (PAGE_SIZE << order) >> 20);
+			xen_io_tlb_nslabs = SLABS_PER_PAGE << order;
+			bytes = xen_io_tlb_nslabs << IO_TLB_SHIFT;
+		}
+	}
 	if (!xen_io_tlb_start) {
 		m_ret = XEN_SWIOTLB_ENOMEM;
 		goto error;
@@ -202,14 +220,21 @@ retry:
 			       bytes,
 			       xen_io_tlb_nslabs);
 	if (rc) {
-		free_bootmem(__pa(xen_io_tlb_start), PAGE_ALIGN(bytes));
+		if (!after_bootmem)
+			free_bootmem(__pa(xen_io_tlb_start), PAGE_ALIGN(bytes));
+		else {
+			free_pages((unsigned long)xen_io_tlb_start, order);
+			xen_io_tlb_start = NULL;
+		}
 		m_ret = XEN_SWIOTLB_EFIXUP;
 		goto error;
 	}
 	start_dma_addr = xen_virt_to_bus(xen_io_tlb_start);
-	swiotlb_init_with_tbl(xen_io_tlb_start, xen_io_tlb_nslabs, verbose);
-
-	return;
+	if (!after_bootmem)
+		swiotlb_init_with_tbl(xen_io_tlb_start, xen_io_tlb_nslabs, verbose);
+	else
+		rc = swiotlb_late_init_with_tbl(xen_io_tlb_start, xen_io_tlb_nslabs);
+	return rc;
 error:
 	if (repeat--) {
 		xen_io_tlb_nslabs = max(1024UL, /* Min is 2MB */
@@ -218,10 +243,13 @@ error:
 		      (xen_io_tlb_nslabs << IO_TLB_SHIFT) >> 20);
 		goto retry;
 	}
-	xen_raw_printk("%s (rc:%d)", xen_swiotlb_error(m_ret), rc);
-	panic("%s (rc:%d)", xen_swiotlb_error(m_ret), rc);
+	pr_err("%s (rc:%d)", xen_swiotlb_error(m_ret), rc);
+	if (!after_bootmem)
+		panic("%s (rc:%d)", xen_swiotlb_error(m_ret), rc);
+	else
+		free_pages((unsigned long)xen_io_tlb_start, order);
+	return rc;
 }
-
 void *
 xen_swiotlb_alloc_coherent(struct device *hwdev, size_t size,
 			   dma_addr_t *dma_handle, gfp_t flags,
diff --git a/include/xen/swiotlb-xen.h b/include/xen/swiotlb-xen.h
index 4f4d449..f26f9f3 100644
--- a/include/xen/swiotlb-xen.h
+++ b/include/xen/swiotlb-xen.h
@@ -3,7 +3,7 @@
 
 #include <linux/swiotlb.h>
 
-extern void xen_swiotlb_init(int verbose);
+extern int xen_swiotlb_init(int verbose);
 
 extern void
 *xen_swiotlb_alloc_coherent(struct device *hwdev, size_t size,
-- 
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 Sep 10 19:57:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Sep 2012 19:57:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TBA6O-0004TQ-AB; Mon, 10 Sep 2012 19:57: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 1TBA6N-0004Rp-92
	for xen-devel@lists.xensource.com; Mon, 10 Sep 2012 19:56:59 +0000
Received: from [85.158.143.99:49015] by server-3.bemta-4.messagelabs.com id
	4C/7C-08232-B064E405; Mon, 10 Sep 2012 19:56:59 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1347307016!18373492!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDc0NzYwMw==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31312 invoked from network); 10 Sep 2012 19:56:58 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-16.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 10 Sep 2012 19:56:58 -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 q8AJupaG011039
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 10 Sep 2012 19:56:52 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
	q8AJunif021901
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 10 Sep 2012 19:56:50 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
	q8AJunWF000556; Mon, 10 Sep 2012 14:56:49 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 10 Sep 2012 12:56:49 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 37FDA4035E; Mon, 10 Sep 2012 15:46:09 -0400 (EDT)
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: linux-kernel@vger.kernel.org, xen-devel@lists.xensource.com,
	stefano.stabellini@eu.citrix.com
Date: Mon, 10 Sep 2012 15:46:07 -0400
Message-Id: <1347306367-28669-11-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.7.7.6
In-Reply-To: <1347306367-28669-1-git-send-email-konrad.wilk@oracle.com>
References: <1347306367-28669-1-git-send-email-konrad.wilk@oracle.com>
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: [Xen-devel] [PATCH 10/10] xen/swiotlb: Depending on after_bootmem
	is not 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>
MIME-Version: 1.0
Content-Type: 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 PCI IOMMUs are initialized it is after after_bootmem but
before a lot of "other" subsystems are initialized. As such
the check for after_bootmem is incorrect and we should
just use a parameter to define whether we are early or late.

This solves this bootup problem:

__ex_table already sorted, skipping sortM
Initializing CPU#0
Warning: only able to allocate 1 MB for software IO TLB
Xen-SWIOTLB: Lowering to 2MB
Warning: only able to allocate 1 MB for software IO TLB
Xen-SWIOTLB: Lowering to 2MB
Warning: only able to allocate 1 MB for software IO TLB
Xen-SWIOTLB: Lowering to 2MB
Warning: only able to allocate 1 MB for software IO TLB
Cannot allocate Xen-SWIOTLB buffer (rc:-12)

Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 arch/x86/xen/pci-swiotlb-xen.c |    4 ++--
 drivers/xen/swiotlb-xen.c      |   11 ++++++-----
 include/xen/swiotlb-xen.h      |    2 +-
 3 files changed, 9 insertions(+), 8 deletions(-)

diff --git a/arch/x86/xen/pci-swiotlb-xen.c b/arch/x86/xen/pci-swiotlb-xen.c
index fc0c78f..1608244 100644
--- a/arch/x86/xen/pci-swiotlb-xen.c
+++ b/arch/x86/xen/pci-swiotlb-xen.c
@@ -69,7 +69,7 @@ int __init pci_xen_swiotlb_detect(void)
 void __init pci_xen_swiotlb_init(void)
 {
 	if (xen_swiotlb) {
-		xen_swiotlb_init(1);
+		xen_swiotlb_init(1, true /* early */);
 		dma_ops = &xen_swiotlb_dma_ops;
 
 		/* Make sure ACS will be enabled */
@@ -84,7 +84,7 @@ int pci_xen_swiotlb_init_late(void)
 	if (xen_swiotlb)
 		return 0;
 
-	rc = xen_swiotlb_init(1);
+	rc = xen_swiotlb_init(1, false /* late */);
 	if (rc)
 		return rc;
 
diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
index 6f81994..7443e19 100644
--- a/drivers/xen/swiotlb-xen.c
+++ b/drivers/xen/swiotlb-xen.c
@@ -176,7 +176,7 @@ static const char *xen_swiotlb_error(enum xen_swiotlb_err err)
 	}
 	return "";
 }
-int __ref xen_swiotlb_init(int verbose)
+int __ref xen_swiotlb_init(int verbose, bool early)
 {
 	unsigned long bytes, order;
 	int rc = -ENOMEM;
@@ -190,7 +190,7 @@ retry:
 	/*
 	 * Get IO TLB memory from any location.
 	 */
-	if (!after_bootmem)
+	if (early)
 		xen_io_tlb_start = alloc_bootmem_pages(PAGE_ALIGN(bytes));
 	else {
 #define SLABS_PER_PAGE (1 << (PAGE_SHIFT - IO_TLB_SHIFT))
@@ -220,7 +220,7 @@ retry:
 			       bytes,
 			       xen_io_tlb_nslabs);
 	if (rc) {
-		if (!after_bootmem)
+		if (early)
 			free_bootmem(__pa(xen_io_tlb_start), PAGE_ALIGN(bytes));
 		else {
 			free_pages((unsigned long)xen_io_tlb_start, order);
@@ -230,7 +230,8 @@ retry:
 		goto error;
 	}
 	start_dma_addr = xen_virt_to_bus(xen_io_tlb_start);
-	if (!after_bootmem)
+	rc = 0;
+	if (early)
 		swiotlb_init_with_tbl(xen_io_tlb_start, xen_io_tlb_nslabs, verbose);
 	else
 		rc = swiotlb_late_init_with_tbl(xen_io_tlb_start, xen_io_tlb_nslabs);
@@ -244,7 +245,7 @@ error:
 		goto retry;
 	}
 	pr_err("%s (rc:%d)", xen_swiotlb_error(m_ret), rc);
-	if (!after_bootmem)
+	if (early)
 		panic("%s (rc:%d)", xen_swiotlb_error(m_ret), rc);
 	else
 		free_pages((unsigned long)xen_io_tlb_start, order);
diff --git a/include/xen/swiotlb-xen.h b/include/xen/swiotlb-xen.h
index a0db2b7..de8bcc6 100644
--- a/include/xen/swiotlb-xen.h
+++ b/include/xen/swiotlb-xen.h
@@ -3,7 +3,7 @@
 
 #include <linux/swiotlb.h>
 
-extern int xen_swiotlb_init(int verbose);
+extern int xen_swiotlb_init(int verbose, bool early);
 
 extern void
 *xen_swiotlb_alloc_coherent(struct device *hwdev, size_t size,
-- 
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 Sep 10 19:57:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Sep 2012 19:57:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TBA6O-0004TQ-AB; Mon, 10 Sep 2012 19:57: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 1TBA6N-0004Rp-92
	for xen-devel@lists.xensource.com; Mon, 10 Sep 2012 19:56:59 +0000
Received: from [85.158.143.99:49015] by server-3.bemta-4.messagelabs.com id
	4C/7C-08232-B064E405; Mon, 10 Sep 2012 19:56:59 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1347307016!18373492!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDc0NzYwMw==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31312 invoked from network); 10 Sep 2012 19:56:58 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-16.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 10 Sep 2012 19:56:58 -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 q8AJupaG011039
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 10 Sep 2012 19:56:52 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
	q8AJunif021901
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 10 Sep 2012 19:56:50 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
	q8AJunWF000556; Mon, 10 Sep 2012 14:56:49 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 10 Sep 2012 12:56:49 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 37FDA4035E; Mon, 10 Sep 2012 15:46:09 -0400 (EDT)
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: linux-kernel@vger.kernel.org, xen-devel@lists.xensource.com,
	stefano.stabellini@eu.citrix.com
Date: Mon, 10 Sep 2012 15:46:07 -0400
Message-Id: <1347306367-28669-11-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.7.7.6
In-Reply-To: <1347306367-28669-1-git-send-email-konrad.wilk@oracle.com>
References: <1347306367-28669-1-git-send-email-konrad.wilk@oracle.com>
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: [Xen-devel] [PATCH 10/10] xen/swiotlb: Depending on after_bootmem
	is not 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>
MIME-Version: 1.0
Content-Type: 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 PCI IOMMUs are initialized it is after after_bootmem but
before a lot of "other" subsystems are initialized. As such
the check for after_bootmem is incorrect and we should
just use a parameter to define whether we are early or late.

This solves this bootup problem:

__ex_table already sorted, skipping sortM
Initializing CPU#0
Warning: only able to allocate 1 MB for software IO TLB
Xen-SWIOTLB: Lowering to 2MB
Warning: only able to allocate 1 MB for software IO TLB
Xen-SWIOTLB: Lowering to 2MB
Warning: only able to allocate 1 MB for software IO TLB
Xen-SWIOTLB: Lowering to 2MB
Warning: only able to allocate 1 MB for software IO TLB
Cannot allocate Xen-SWIOTLB buffer (rc:-12)

Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 arch/x86/xen/pci-swiotlb-xen.c |    4 ++--
 drivers/xen/swiotlb-xen.c      |   11 ++++++-----
 include/xen/swiotlb-xen.h      |    2 +-
 3 files changed, 9 insertions(+), 8 deletions(-)

diff --git a/arch/x86/xen/pci-swiotlb-xen.c b/arch/x86/xen/pci-swiotlb-xen.c
index fc0c78f..1608244 100644
--- a/arch/x86/xen/pci-swiotlb-xen.c
+++ b/arch/x86/xen/pci-swiotlb-xen.c
@@ -69,7 +69,7 @@ int __init pci_xen_swiotlb_detect(void)
 void __init pci_xen_swiotlb_init(void)
 {
 	if (xen_swiotlb) {
-		xen_swiotlb_init(1);
+		xen_swiotlb_init(1, true /* early */);
 		dma_ops = &xen_swiotlb_dma_ops;
 
 		/* Make sure ACS will be enabled */
@@ -84,7 +84,7 @@ int pci_xen_swiotlb_init_late(void)
 	if (xen_swiotlb)
 		return 0;
 
-	rc = xen_swiotlb_init(1);
+	rc = xen_swiotlb_init(1, false /* late */);
 	if (rc)
 		return rc;
 
diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
index 6f81994..7443e19 100644
--- a/drivers/xen/swiotlb-xen.c
+++ b/drivers/xen/swiotlb-xen.c
@@ -176,7 +176,7 @@ static const char *xen_swiotlb_error(enum xen_swiotlb_err err)
 	}
 	return "";
 }
-int __ref xen_swiotlb_init(int verbose)
+int __ref xen_swiotlb_init(int verbose, bool early)
 {
 	unsigned long bytes, order;
 	int rc = -ENOMEM;
@@ -190,7 +190,7 @@ retry:
 	/*
 	 * Get IO TLB memory from any location.
 	 */
-	if (!after_bootmem)
+	if (early)
 		xen_io_tlb_start = alloc_bootmem_pages(PAGE_ALIGN(bytes));
 	else {
 #define SLABS_PER_PAGE (1 << (PAGE_SHIFT - IO_TLB_SHIFT))
@@ -220,7 +220,7 @@ retry:
 			       bytes,
 			       xen_io_tlb_nslabs);
 	if (rc) {
-		if (!after_bootmem)
+		if (early)
 			free_bootmem(__pa(xen_io_tlb_start), PAGE_ALIGN(bytes));
 		else {
 			free_pages((unsigned long)xen_io_tlb_start, order);
@@ -230,7 +230,8 @@ retry:
 		goto error;
 	}
 	start_dma_addr = xen_virt_to_bus(xen_io_tlb_start);
-	if (!after_bootmem)
+	rc = 0;
+	if (early)
 		swiotlb_init_with_tbl(xen_io_tlb_start, xen_io_tlb_nslabs, verbose);
 	else
 		rc = swiotlb_late_init_with_tbl(xen_io_tlb_start, xen_io_tlb_nslabs);
@@ -244,7 +245,7 @@ error:
 		goto retry;
 	}
 	pr_err("%s (rc:%d)", xen_swiotlb_error(m_ret), rc);
-	if (!after_bootmem)
+	if (early)
 		panic("%s (rc:%d)", xen_swiotlb_error(m_ret), rc);
 	else
 		free_pages((unsigned long)xen_io_tlb_start, order);
diff --git a/include/xen/swiotlb-xen.h b/include/xen/swiotlb-xen.h
index a0db2b7..de8bcc6 100644
--- a/include/xen/swiotlb-xen.h
+++ b/include/xen/swiotlb-xen.h
@@ -3,7 +3,7 @@
 
 #include <linux/swiotlb.h>
 
-extern int xen_swiotlb_init(int verbose);
+extern int xen_swiotlb_init(int verbose, bool early);
 
 extern void
 *xen_swiotlb_alloc_coherent(struct device *hwdev, size_t size,
-- 
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 Sep 10 19:57:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Sep 2012 19:57:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TBA6Q-0004Uf-2c; Mon, 10 Sep 2012 19:57:02 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1TBA6O-0004TD-4q
	for xen-devel@lists.xensource.com; Mon, 10 Sep 2012 19:57:00 +0000
Received: from [85.158.143.99:44225] by server-1.bemta-4.messagelabs.com id
	B0/99-12504-B064E405; Mon, 10 Sep 2012 19:56:59 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1347307017!19973322!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzM3MzI2\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20120 invoked from network); 10 Sep 2012 19:56:58 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-14.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 10 Sep 2012 19:56: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 q8AJuncM030549
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 10 Sep 2012 19:56:51 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
	q8AJumrQ013917
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 10 Sep 2012 19:56:49 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
	q8AJumhk001279; Mon, 10 Sep 2012 14:56:48 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 10 Sep 2012 12:56:48 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 17C2040357; Mon, 10 Sep 2012 15:46:09 -0400 (EDT)
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: linux-kernel@vger.kernel.org, xen-devel@lists.xensource.com,
	stefano.stabellini@eu.citrix.com
Date: Mon, 10 Sep 2012 15:46:04 -0400
Message-Id: <1347306367-28669-8-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.7.7.6
In-Reply-To: <1347306367-28669-1-git-send-email-konrad.wilk@oracle.com>
References: <1347306367-28669-1-git-send-email-konrad.wilk@oracle.com>
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: [Xen-devel] [PATCH 07/10] xen/pcifront: Use Xen-SWIOTLB when
	initting if required.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 piggyback on "xen/swiotlb: Use the swiotlb_late_init_with_tbl to init
Xen-SWIOTLB late when PV PCI is used." functionality to start up
the Xen-SWIOTLB if we are hot-plugged. This allows us to bypass
the need to supply 'iommu=soft' on the Linux command line (mostly).
With this patch, if a user forgot 'iommu=soft' on the command line,
and hotplug a PCI device they will get:

pcifront pci-0: Installing PCI frontend
Warning: only able to allocate 4 MB for software IO TLB
software IO TLB [mem 0x2a000000-0x2a3fffff] (4MB) mapped at [ffff88002a000000-ffff88002a3fffff]
pcifront pci-0: Creating PCI Frontend Bus 0000:00
pcifront pci-0: PCI host bridge to bus 0000:00
pci_bus 0000:00: root bus resource [io  0x0000-0xffff]
pci_bus 0000:00: root bus resource [mem 0x00000000-0xfffffffff]
pci 0000:00:00.0: [8086:10d3] type 00 class 0x020000
pci 0000:00:00.0: reg 10: [mem 0xfe5c0000-0xfe5dffff]
pci 0000:00:00.0: reg 14: [mem 0xfe500000-0xfe57ffff]
pci 0000:00:00.0: reg 18: [io  0xe000-0xe01f]
pci 0000:00:00.0: reg 1c: [mem 0xfe5e0000-0xfe5e3fff]
pcifront pci-0: claiming resource 0000:00:00.0/0
pcifront pci-0: claiming resource 0000:00:00.0/1
pcifront pci-0: claiming resource 0000:00:00.0/2
pcifront pci-0: claiming resource 0000:00:00.0/3
e1000e: Intel(R) PRO/1000 Network Driver - 2.0.0-k
e1000e: Copyright(c) 1999 - 2012 Intel Corporation.
e1000e 0000:00:00.0: Disabling ASPM L0s L1
e1000e 0000:00:00.0: enabling device (0000 -> 0002)
e1000e 0000:00:00.0: Xen PCI mapped GSI16 to IRQ34
e1000e 0000:00:00.0: (unregistered net_device): Interrupt Throttling Rate (ints/sec) set to dynamic conservative mode
e1000e 0000:00:00.0: eth0: (PCI Express:2.5GT/s:Width x1) 00:1b:21:ab:c6:13
e1000e 0000:00:00.0: eth0: Intel(R) PRO/1000 Network Connection
e1000e 0000:00:00.0: eth0: MAC: 3, PHY: 8, PBA No: E46981-005

The "Warning only" will go away if one supplies 'iommu=soft' instead
as we have a higher chance of being able to allocate large swaths of
memory.

Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 drivers/pci/xen-pcifront.c |   13 +++++++++----
 1 files changed, 9 insertions(+), 4 deletions(-)

diff --git a/drivers/pci/xen-pcifront.c b/drivers/pci/xen-pcifront.c
index d6cc62c..0ad8ca3 100644
--- a/drivers/pci/xen-pcifront.c
+++ b/drivers/pci/xen-pcifront.c
@@ -21,6 +21,7 @@
 #include <linux/bitops.h>
 #include <linux/time.h>
 
+#include <asm/xen/swiotlb-xen.h>
 #define INVALID_GRANT_REF (0)
 #define INVALID_EVTCHN    (-1)
 
@@ -668,7 +669,7 @@ static irqreturn_t pcifront_handler_aer(int irq, void *dev)
 	schedule_pcifront_aer_op(pdev);
 	return IRQ_HANDLED;
 }
-static int pcifront_connect(struct pcifront_device *pdev)
+static int pcifront_connect_and_init_dma(struct pcifront_device *pdev)
 {
 	int err = 0;
 
@@ -681,9 +682,13 @@ static int pcifront_connect(struct pcifront_device *pdev)
 		dev_err(&pdev->xdev->dev, "PCI frontend already installed!\n");
 		err = -EEXIST;
 	}
-
 	spin_unlock(&pcifront_dev_lock);
 
+	if (!err && !swiotlb_nr_tbl()) {
+		err = pci_xen_swiotlb_init_late();
+		if (err)
+			dev_err(&pdev->xdev->dev, "Could not setup SWIOTLB!\n");
+	}
 	return err;
 }
 
@@ -842,10 +847,10 @@ static int __devinit pcifront_try_connect(struct pcifront_device *pdev)
 	    XenbusStateInitialised)
 		goto out;
 
-	err = pcifront_connect(pdev);
+	err = pcifront_connect_and_init_dma(pdev);
 	if (err) {
 		xenbus_dev_fatal(pdev->xdev, err,
-				 "Error connecting PCI Frontend");
+				 "Error setting up PCI Frontend");
 		goto out;
 	}
 
-- 
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 Sep 10 19:57:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Sep 2012 19:57:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TBA6Q-0004Uf-2c; Mon, 10 Sep 2012 19:57:02 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1TBA6O-0004TD-4q
	for xen-devel@lists.xensource.com; Mon, 10 Sep 2012 19:57:00 +0000
Received: from [85.158.143.99:44225] by server-1.bemta-4.messagelabs.com id
	B0/99-12504-B064E405; Mon, 10 Sep 2012 19:56:59 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1347307017!19973322!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzM3MzI2\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20120 invoked from network); 10 Sep 2012 19:56:58 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-14.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 10 Sep 2012 19:56: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 q8AJuncM030549
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 10 Sep 2012 19:56:51 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
	q8AJumrQ013917
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 10 Sep 2012 19:56:49 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
	q8AJumhk001279; Mon, 10 Sep 2012 14:56:48 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 10 Sep 2012 12:56:48 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 17C2040357; Mon, 10 Sep 2012 15:46:09 -0400 (EDT)
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: linux-kernel@vger.kernel.org, xen-devel@lists.xensource.com,
	stefano.stabellini@eu.citrix.com
Date: Mon, 10 Sep 2012 15:46:04 -0400
Message-Id: <1347306367-28669-8-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.7.7.6
In-Reply-To: <1347306367-28669-1-git-send-email-konrad.wilk@oracle.com>
References: <1347306367-28669-1-git-send-email-konrad.wilk@oracle.com>
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: [Xen-devel] [PATCH 07/10] xen/pcifront: Use Xen-SWIOTLB when
	initting if required.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 piggyback on "xen/swiotlb: Use the swiotlb_late_init_with_tbl to init
Xen-SWIOTLB late when PV PCI is used." functionality to start up
the Xen-SWIOTLB if we are hot-plugged. This allows us to bypass
the need to supply 'iommu=soft' on the Linux command line (mostly).
With this patch, if a user forgot 'iommu=soft' on the command line,
and hotplug a PCI device they will get:

pcifront pci-0: Installing PCI frontend
Warning: only able to allocate 4 MB for software IO TLB
software IO TLB [mem 0x2a000000-0x2a3fffff] (4MB) mapped at [ffff88002a000000-ffff88002a3fffff]
pcifront pci-0: Creating PCI Frontend Bus 0000:00
pcifront pci-0: PCI host bridge to bus 0000:00
pci_bus 0000:00: root bus resource [io  0x0000-0xffff]
pci_bus 0000:00: root bus resource [mem 0x00000000-0xfffffffff]
pci 0000:00:00.0: [8086:10d3] type 00 class 0x020000
pci 0000:00:00.0: reg 10: [mem 0xfe5c0000-0xfe5dffff]
pci 0000:00:00.0: reg 14: [mem 0xfe500000-0xfe57ffff]
pci 0000:00:00.0: reg 18: [io  0xe000-0xe01f]
pci 0000:00:00.0: reg 1c: [mem 0xfe5e0000-0xfe5e3fff]
pcifront pci-0: claiming resource 0000:00:00.0/0
pcifront pci-0: claiming resource 0000:00:00.0/1
pcifront pci-0: claiming resource 0000:00:00.0/2
pcifront pci-0: claiming resource 0000:00:00.0/3
e1000e: Intel(R) PRO/1000 Network Driver - 2.0.0-k
e1000e: Copyright(c) 1999 - 2012 Intel Corporation.
e1000e 0000:00:00.0: Disabling ASPM L0s L1
e1000e 0000:00:00.0: enabling device (0000 -> 0002)
e1000e 0000:00:00.0: Xen PCI mapped GSI16 to IRQ34
e1000e 0000:00:00.0: (unregistered net_device): Interrupt Throttling Rate (ints/sec) set to dynamic conservative mode
e1000e 0000:00:00.0: eth0: (PCI Express:2.5GT/s:Width x1) 00:1b:21:ab:c6:13
e1000e 0000:00:00.0: eth0: Intel(R) PRO/1000 Network Connection
e1000e 0000:00:00.0: eth0: MAC: 3, PHY: 8, PBA No: E46981-005

The "Warning only" will go away if one supplies 'iommu=soft' instead
as we have a higher chance of being able to allocate large swaths of
memory.

Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 drivers/pci/xen-pcifront.c |   13 +++++++++----
 1 files changed, 9 insertions(+), 4 deletions(-)

diff --git a/drivers/pci/xen-pcifront.c b/drivers/pci/xen-pcifront.c
index d6cc62c..0ad8ca3 100644
--- a/drivers/pci/xen-pcifront.c
+++ b/drivers/pci/xen-pcifront.c
@@ -21,6 +21,7 @@
 #include <linux/bitops.h>
 #include <linux/time.h>
 
+#include <asm/xen/swiotlb-xen.h>
 #define INVALID_GRANT_REF (0)
 #define INVALID_EVTCHN    (-1)
 
@@ -668,7 +669,7 @@ static irqreturn_t pcifront_handler_aer(int irq, void *dev)
 	schedule_pcifront_aer_op(pdev);
 	return IRQ_HANDLED;
 }
-static int pcifront_connect(struct pcifront_device *pdev)
+static int pcifront_connect_and_init_dma(struct pcifront_device *pdev)
 {
 	int err = 0;
 
@@ -681,9 +682,13 @@ static int pcifront_connect(struct pcifront_device *pdev)
 		dev_err(&pdev->xdev->dev, "PCI frontend already installed!\n");
 		err = -EEXIST;
 	}
-
 	spin_unlock(&pcifront_dev_lock);
 
+	if (!err && !swiotlb_nr_tbl()) {
+		err = pci_xen_swiotlb_init_late();
+		if (err)
+			dev_err(&pdev->xdev->dev, "Could not setup SWIOTLB!\n");
+	}
 	return err;
 }
 
@@ -842,10 +847,10 @@ static int __devinit pcifront_try_connect(struct pcifront_device *pdev)
 	    XenbusStateInitialised)
 		goto out;
 
-	err = pcifront_connect(pdev);
+	err = pcifront_connect_and_init_dma(pdev);
 	if (err) {
 		xenbus_dev_fatal(pdev->xdev, err,
-				 "Error connecting PCI Frontend");
+				 "Error setting up PCI Frontend");
 		goto out;
 	}
 
-- 
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 Sep 10 19:57:07 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Sep 2012 19:57: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 1TBA6T-0004ZI-9f; Mon, 10 Sep 2012 19:57:05 +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 1TBA6P-0004Rq-DZ
	for xen-devel@lists.xensource.com; Mon, 10 Sep 2012 19:57:01 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1347307013!9161753!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDc0NzYwMw==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 415 invoked from network); 10 Sep 2012 19:56:54 -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; 10 Sep 2012 19:56:54 -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 q8AJunCJ010993
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 10 Sep 2012 19:56:49 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q8AJumPx017524
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 10 Sep 2012 19:56:49 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
	q8AJumaQ000541; Mon, 10 Sep 2012 14:56:48 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 10 Sep 2012 12:56:48 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 036324032B; Mon, 10 Sep 2012 15:46:09 -0400 (EDT)
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: linux-kernel@vger.kernel.org, xen-devel@lists.xensource.com,
	stefano.stabellini@eu.citrix.com
Date: Mon, 10 Sep 2012 15:46:02 -0400
Message-Id: <1347306367-28669-6-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.7.7.6
In-Reply-To: <1347306367-28669-1-git-send-email-konrad.wilk@oracle.com>
References: <1347306367-28669-1-git-send-email-konrad.wilk@oracle.com>
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: [Xen-devel] [PATCH 05/10] xen/swiotlb: Move the error strings to
	its own 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

That way we can more easily reuse those errors when using the
late SWIOTLB init.

Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 drivers/xen/swiotlb-xen.c |   35 +++++++++++++++++++++++++++--------
 1 files changed, 27 insertions(+), 8 deletions(-)

diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
index a2aad6e..701b103 100644
--- a/drivers/xen/swiotlb-xen.c
+++ b/drivers/xen/swiotlb-xen.c
@@ -154,11 +154,33 @@ static unsigned long xen_set_nslabs(unsigned long nr_tbl)
 
 	return xen_io_tlb_nslabs << IO_TLB_SHIFT;
 }
+
+enum xen_swiotlb_err {
+	XEN_SWIOTLB_UNKNOWN = 0,
+	XEN_SWIOTLB_ENOMEM,
+	XEN_SWIOTLB_EFIXUP
+};
+
+static const char *xen_swiotlb_error(enum xen_swiotlb_err err)
+{
+	switch (err) {
+	case XEN_SWIOTLB_ENOMEM:
+		return "Cannot allocate Xen-SWIOTLB buffer\n";
+	case XEN_SWIOTLB_EFIXUP:
+		return "Failed to get contiguous memory for DMA from Xen!\n"\
+		    "You either: don't have the permissions, do not have"\
+		    " enough free memory under 4GB, or the hypervisor memory"\
+		    " is too fragmented!";
+	default:
+		break;
+	}
+	return "";
+}
 void __init xen_swiotlb_init(int verbose)
 {
 	unsigned long bytes;
 	int rc = -ENOMEM;
-	char *m = NULL;
+	enum xen_swiotlb_err m_ret = XEN_SWIOTLB_UNKNOWN;
 	unsigned int repeat = 3;
 
 	xen_io_tlb_nslabs = swiotlb_nr_tbl();
@@ -169,7 +191,7 @@ retry:
 	 */
 	xen_io_tlb_start = alloc_bootmem_pages(PAGE_ALIGN(bytes));
 	if (!xen_io_tlb_start) {
-		m = "Cannot allocate Xen-SWIOTLB buffer!\n";
+		m_ret = XEN_SWIOTLB_ENOMEM;
 		goto error;
 	}
 	xen_io_tlb_end = xen_io_tlb_start + bytes;
@@ -181,10 +203,7 @@ retry:
 			       xen_io_tlb_nslabs);
 	if (rc) {
 		free_bootmem(__pa(xen_io_tlb_start), PAGE_ALIGN(bytes));
-		m = "Failed to get contiguous memory for DMA from Xen!\n"\
-		    "You either: don't have the permissions, do not have"\
-		    " enough free memory under 4GB, or the hypervisor memory"\
-		    "is too fragmented!";
+		m_ret = XEN_SWIOTLB_EFIXUP;
 		goto error;
 	}
 	start_dma_addr = xen_virt_to_bus(xen_io_tlb_start);
@@ -199,8 +218,8 @@ error:
 		      (xen_io_tlb_nslabs << IO_TLB_SHIFT) >> 20);
 		goto retry;
 	}
-	xen_raw_printk("%s (rc:%d)", m, rc);
-	panic("%s (rc:%d)", m, rc);
+	xen_raw_printk("%s (rc:%d)", xen_swiotlb_error(m_ret), rc);
+	panic("%s (rc:%d)", xen_swiotlb_error(m_ret), rc);
 }
 
 void *
-- 
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 Sep 10 19:57:07 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Sep 2012 19:57: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 1TBA6T-0004ZI-9f; Mon, 10 Sep 2012 19:57:05 +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 1TBA6P-0004Rq-DZ
	for xen-devel@lists.xensource.com; Mon, 10 Sep 2012 19:57:01 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1347307013!9161753!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDc0NzYwMw==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 415 invoked from network); 10 Sep 2012 19:56:54 -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; 10 Sep 2012 19:56:54 -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 q8AJunCJ010993
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 10 Sep 2012 19:56:49 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q8AJumPx017524
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 10 Sep 2012 19:56:49 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
	q8AJumaQ000541; Mon, 10 Sep 2012 14:56:48 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 10 Sep 2012 12:56:48 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 036324032B; Mon, 10 Sep 2012 15:46:09 -0400 (EDT)
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: linux-kernel@vger.kernel.org, xen-devel@lists.xensource.com,
	stefano.stabellini@eu.citrix.com
Date: Mon, 10 Sep 2012 15:46:02 -0400
Message-Id: <1347306367-28669-6-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.7.7.6
In-Reply-To: <1347306367-28669-1-git-send-email-konrad.wilk@oracle.com>
References: <1347306367-28669-1-git-send-email-konrad.wilk@oracle.com>
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: [Xen-devel] [PATCH 05/10] xen/swiotlb: Move the error strings to
	its own 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

That way we can more easily reuse those errors when using the
late SWIOTLB init.

Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 drivers/xen/swiotlb-xen.c |   35 +++++++++++++++++++++++++++--------
 1 files changed, 27 insertions(+), 8 deletions(-)

diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
index a2aad6e..701b103 100644
--- a/drivers/xen/swiotlb-xen.c
+++ b/drivers/xen/swiotlb-xen.c
@@ -154,11 +154,33 @@ static unsigned long xen_set_nslabs(unsigned long nr_tbl)
 
 	return xen_io_tlb_nslabs << IO_TLB_SHIFT;
 }
+
+enum xen_swiotlb_err {
+	XEN_SWIOTLB_UNKNOWN = 0,
+	XEN_SWIOTLB_ENOMEM,
+	XEN_SWIOTLB_EFIXUP
+};
+
+static const char *xen_swiotlb_error(enum xen_swiotlb_err err)
+{
+	switch (err) {
+	case XEN_SWIOTLB_ENOMEM:
+		return "Cannot allocate Xen-SWIOTLB buffer\n";
+	case XEN_SWIOTLB_EFIXUP:
+		return "Failed to get contiguous memory for DMA from Xen!\n"\
+		    "You either: don't have the permissions, do not have"\
+		    " enough free memory under 4GB, or the hypervisor memory"\
+		    " is too fragmented!";
+	default:
+		break;
+	}
+	return "";
+}
 void __init xen_swiotlb_init(int verbose)
 {
 	unsigned long bytes;
 	int rc = -ENOMEM;
-	char *m = NULL;
+	enum xen_swiotlb_err m_ret = XEN_SWIOTLB_UNKNOWN;
 	unsigned int repeat = 3;
 
 	xen_io_tlb_nslabs = swiotlb_nr_tbl();
@@ -169,7 +191,7 @@ retry:
 	 */
 	xen_io_tlb_start = alloc_bootmem_pages(PAGE_ALIGN(bytes));
 	if (!xen_io_tlb_start) {
-		m = "Cannot allocate Xen-SWIOTLB buffer!\n";
+		m_ret = XEN_SWIOTLB_ENOMEM;
 		goto error;
 	}
 	xen_io_tlb_end = xen_io_tlb_start + bytes;
@@ -181,10 +203,7 @@ retry:
 			       xen_io_tlb_nslabs);
 	if (rc) {
 		free_bootmem(__pa(xen_io_tlb_start), PAGE_ALIGN(bytes));
-		m = "Failed to get contiguous memory for DMA from Xen!\n"\
-		    "You either: don't have the permissions, do not have"\
-		    " enough free memory under 4GB, or the hypervisor memory"\
-		    "is too fragmented!";
+		m_ret = XEN_SWIOTLB_EFIXUP;
 		goto error;
 	}
 	start_dma_addr = xen_virt_to_bus(xen_io_tlb_start);
@@ -199,8 +218,8 @@ error:
 		      (xen_io_tlb_nslabs << IO_TLB_SHIFT) >> 20);
 		goto retry;
 	}
-	xen_raw_printk("%s (rc:%d)", m, rc);
-	panic("%s (rc:%d)", m, rc);
+	xen_raw_printk("%s (rc:%d)", xen_swiotlb_error(m_ret), rc);
+	panic("%s (rc:%d)", xen_swiotlb_error(m_ret), rc);
 }
 
 void *
-- 
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 Sep 10 19:57:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Sep 2012 19:57:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TBA6S-0004YO-Qb; Mon, 10 Sep 2012 19:57:04 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1TBA6P-0004Rn-J5
	for xen-devel@lists.xensource.com; Mon, 10 Sep 2012 19:57:01 +0000
Received: from [85.158.143.35:54848] by server-2.bemta-4.messagelabs.com id
	DE/09-21239-D064E405; Mon, 10 Sep 2012 19:57:01 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1347307019!6623909!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzM3MzI2\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11872 invoked from network); 10 Sep 2012 19:57:00 -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; 10 Sep 2012 19:57: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 q8AJun1L030550
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 10 Sep 2012 19:56: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
	q8AJum4Y021854
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 10 Sep 2012 19:56:48 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
	q8AJulAs018814; Mon, 10 Sep 2012 14:56:48 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 10 Sep 2012 12:56:47 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id E3D3A40305; Mon, 10 Sep 2012 15:46:08 -0400 (EDT)
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: linux-kernel@vger.kernel.org, xen-devel@lists.xensource.com,
	stefano.stabellini@eu.citrix.com
Date: Mon, 10 Sep 2012 15:46:00 -0400
Message-Id: <1347306367-28669-4-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.7.7.6
In-Reply-To: <1347306367-28669-1-git-send-email-konrad.wilk@oracle.com>
References: <1347306367-28669-1-git-send-email-konrad.wilk@oracle.com>
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: [Xen-devel] [PATCH 03/10] swiotlb: add the late swiotlb
	initialization function with iotlb memory
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This enables the caller to initialize swiotlb with its own iotlb
memory late in the bootup.

See git commit eb605a5754d050a25a9f00d718fb173f24c486ef
"swiotlb: add swiotlb_tbl_map_single library function" which will
explain the full details of what it can be used for.

CC: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
[v1: Fold in smatch warning]
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 include/linux/swiotlb.h |    1 +
 lib/swiotlb.c           |   33 ++++++++++++++++++++++++---------
 2 files changed, 25 insertions(+), 9 deletions(-)

diff --git a/include/linux/swiotlb.h b/include/linux/swiotlb.h
index e872526..8d08b3e 100644
--- a/include/linux/swiotlb.h
+++ b/include/linux/swiotlb.h
@@ -25,6 +25,7 @@ extern int swiotlb_force;
 extern void swiotlb_init(int verbose);
 extern void swiotlb_init_with_tbl(char *tlb, unsigned long nslabs, int verbose);
 extern unsigned long swiotlb_nr_tbl(void);
+extern int swiotlb_late_init_with_tbl(char *tlb, unsigned long nslabs);
 
 /*
  * Enumeration for sync targets
diff --git a/lib/swiotlb.c b/lib/swiotlb.c
index 45bc1f8..f114bf6 100644
--- a/lib/swiotlb.c
+++ b/lib/swiotlb.c
@@ -170,7 +170,7 @@ void __init swiotlb_init_with_tbl(char *tlb, unsigned long nslabs, int verbose)
  * Statically reserve bounce buffer space and initialize bounce buffer data
  * structures for the software IO TLB used to implement the DMA API.
  */
-void __init
+static void __init
 swiotlb_init_with_default_size(size_t default_size, int verbose)
 {
 	unsigned long bytes;
@@ -206,8 +206,9 @@ swiotlb_init(int verbose)
 int
 swiotlb_late_init_with_default_size(size_t default_size)
 {
-	unsigned long i, bytes, req_nslabs = io_tlb_nslabs;
+	unsigned long bytes, req_nslabs = io_tlb_nslabs;
 	unsigned int order;
+	int rc = 0;
 
 	if (!io_tlb_nslabs) {
 		io_tlb_nslabs = (default_size >> IO_TLB_SHIFT);
@@ -229,16 +230,32 @@ swiotlb_late_init_with_default_size(size_t default_size)
 		order--;
 	}
 
-	if (!io_tlb_start)
-		goto cleanup1;
-
+	if (!io_tlb_start) {
+		io_tlb_nslabs = req_nslabs;
+		return -ENOMEM;
+	}
 	if (order != get_order(bytes)) {
 		printk(KERN_WARNING "Warning: only able to allocate %ld MB "
 		       "for software IO TLB\n", (PAGE_SIZE << order) >> 20);
 		io_tlb_nslabs = SLABS_PER_PAGE << order;
-		bytes = io_tlb_nslabs << IO_TLB_SHIFT;
 	}
+	rc = swiotlb_late_init_with_tbl(io_tlb_start, io_tlb_nslabs);
+	if (rc)
+		free_pages((unsigned long)io_tlb_start, order);
+	return rc;
+}
+
+int
+swiotlb_late_init_with_tbl(char *tlb, unsigned long nslabs)
+{
+	unsigned long i, bytes;
+
+	bytes = nslabs << IO_TLB_SHIFT;
+
+	io_tlb_nslabs = nslabs;
+	io_tlb_start = tlb;
 	io_tlb_end = io_tlb_start + bytes;
+
 	memset(io_tlb_start, 0, bytes);
 
 	/*
@@ -288,10 +305,8 @@ cleanup3:
 	io_tlb_list = NULL;
 cleanup2:
 	io_tlb_end = NULL;
-	free_pages((unsigned long)io_tlb_start, order);
 	io_tlb_start = NULL;
-cleanup1:
-	io_tlb_nslabs = req_nslabs;
+	io_tlb_nslabs = 0;
 	return -ENOMEM;
 }
 
-- 
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 Sep 10 19:57:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Sep 2012 19:57:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TBA6S-0004YO-Qb; Mon, 10 Sep 2012 19:57:04 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1TBA6P-0004Rn-J5
	for xen-devel@lists.xensource.com; Mon, 10 Sep 2012 19:57:01 +0000
Received: from [85.158.143.35:54848] by server-2.bemta-4.messagelabs.com id
	DE/09-21239-D064E405; Mon, 10 Sep 2012 19:57:01 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1347307019!6623909!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzM3MzI2\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11872 invoked from network); 10 Sep 2012 19:57:00 -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; 10 Sep 2012 19:57: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 q8AJun1L030550
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 10 Sep 2012 19:56: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
	q8AJum4Y021854
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 10 Sep 2012 19:56:48 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
	q8AJulAs018814; Mon, 10 Sep 2012 14:56:48 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 10 Sep 2012 12:56:47 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id E3D3A40305; Mon, 10 Sep 2012 15:46:08 -0400 (EDT)
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: linux-kernel@vger.kernel.org, xen-devel@lists.xensource.com,
	stefano.stabellini@eu.citrix.com
Date: Mon, 10 Sep 2012 15:46:00 -0400
Message-Id: <1347306367-28669-4-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.7.7.6
In-Reply-To: <1347306367-28669-1-git-send-email-konrad.wilk@oracle.com>
References: <1347306367-28669-1-git-send-email-konrad.wilk@oracle.com>
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: [Xen-devel] [PATCH 03/10] swiotlb: add the late swiotlb
	initialization function with iotlb memory
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This enables the caller to initialize swiotlb with its own iotlb
memory late in the bootup.

See git commit eb605a5754d050a25a9f00d718fb173f24c486ef
"swiotlb: add swiotlb_tbl_map_single library function" which will
explain the full details of what it can be used for.

CC: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
[v1: Fold in smatch warning]
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 include/linux/swiotlb.h |    1 +
 lib/swiotlb.c           |   33 ++++++++++++++++++++++++---------
 2 files changed, 25 insertions(+), 9 deletions(-)

diff --git a/include/linux/swiotlb.h b/include/linux/swiotlb.h
index e872526..8d08b3e 100644
--- a/include/linux/swiotlb.h
+++ b/include/linux/swiotlb.h
@@ -25,6 +25,7 @@ extern int swiotlb_force;
 extern void swiotlb_init(int verbose);
 extern void swiotlb_init_with_tbl(char *tlb, unsigned long nslabs, int verbose);
 extern unsigned long swiotlb_nr_tbl(void);
+extern int swiotlb_late_init_with_tbl(char *tlb, unsigned long nslabs);
 
 /*
  * Enumeration for sync targets
diff --git a/lib/swiotlb.c b/lib/swiotlb.c
index 45bc1f8..f114bf6 100644
--- a/lib/swiotlb.c
+++ b/lib/swiotlb.c
@@ -170,7 +170,7 @@ void __init swiotlb_init_with_tbl(char *tlb, unsigned long nslabs, int verbose)
  * Statically reserve bounce buffer space and initialize bounce buffer data
  * structures for the software IO TLB used to implement the DMA API.
  */
-void __init
+static void __init
 swiotlb_init_with_default_size(size_t default_size, int verbose)
 {
 	unsigned long bytes;
@@ -206,8 +206,9 @@ swiotlb_init(int verbose)
 int
 swiotlb_late_init_with_default_size(size_t default_size)
 {
-	unsigned long i, bytes, req_nslabs = io_tlb_nslabs;
+	unsigned long bytes, req_nslabs = io_tlb_nslabs;
 	unsigned int order;
+	int rc = 0;
 
 	if (!io_tlb_nslabs) {
 		io_tlb_nslabs = (default_size >> IO_TLB_SHIFT);
@@ -229,16 +230,32 @@ swiotlb_late_init_with_default_size(size_t default_size)
 		order--;
 	}
 
-	if (!io_tlb_start)
-		goto cleanup1;
-
+	if (!io_tlb_start) {
+		io_tlb_nslabs = req_nslabs;
+		return -ENOMEM;
+	}
 	if (order != get_order(bytes)) {
 		printk(KERN_WARNING "Warning: only able to allocate %ld MB "
 		       "for software IO TLB\n", (PAGE_SIZE << order) >> 20);
 		io_tlb_nslabs = SLABS_PER_PAGE << order;
-		bytes = io_tlb_nslabs << IO_TLB_SHIFT;
 	}
+	rc = swiotlb_late_init_with_tbl(io_tlb_start, io_tlb_nslabs);
+	if (rc)
+		free_pages((unsigned long)io_tlb_start, order);
+	return rc;
+}
+
+int
+swiotlb_late_init_with_tbl(char *tlb, unsigned long nslabs)
+{
+	unsigned long i, bytes;
+
+	bytes = nslabs << IO_TLB_SHIFT;
+
+	io_tlb_nslabs = nslabs;
+	io_tlb_start = tlb;
 	io_tlb_end = io_tlb_start + bytes;
+
 	memset(io_tlb_start, 0, bytes);
 
 	/*
@@ -288,10 +305,8 @@ cleanup3:
 	io_tlb_list = NULL;
 cleanup2:
 	io_tlb_end = NULL;
-	free_pages((unsigned long)io_tlb_start, order);
 	io_tlb_start = NULL;
-cleanup1:
-	io_tlb_nslabs = req_nslabs;
+	io_tlb_nslabs = 0;
 	return -ENOMEM;
 }
 
-- 
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 Sep 10 19:57:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Sep 2012 19:57:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TBA6T-0004Zh-Mb; Mon, 10 Sep 2012 19:57:05 +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 1TBA6S-0004Sa-0V
	for xen-devel@lists.xensource.com; Mon, 10 Sep 2012 19:57:04 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1347307016!3426137!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDc0NzYwMw==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29844 invoked from network); 10 Sep 2012 19:56:57 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-14.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 10 Sep 2012 19:56: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 q8AJupLp011038
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 10 Sep 2012 19:56:52 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
	q8AJunu1021898
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 10 Sep 2012 19:56:50 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
	q8AJun8u000555; Mon, 10 Sep 2012 14:56:49 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 10 Sep 2012 12:56:49 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 2D0804035B; Mon, 10 Sep 2012 15:46:09 -0400 (EDT)
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: linux-kernel@vger.kernel.org, xen-devel@lists.xensource.com,
	stefano.stabellini@eu.citrix.com
Date: Mon, 10 Sep 2012 15:46:06 -0400
Message-Id: <1347306367-28669-10-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.7.7.6
In-Reply-To: <1347306367-28669-1-git-send-email-konrad.wilk@oracle.com>
References: <1347306367-28669-1-git-send-email-konrad.wilk@oracle.com>
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: [Xen-devel] [PATCH 09/10] xen/swiotlb: Fix compile warnings when
	using plain integer instead of NULL pointer.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

arch/x86/xen/pci-swiotlb-xen.c:96:1: warning: Using plain integer as NULL pointer
arch/x86/xen/pci-swiotlb-xen.c:96:1: warning: Using plain integer as NULL pointer

Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 arch/x86/xen/pci-swiotlb-xen.c |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/x86/xen/pci-swiotlb-xen.c b/arch/x86/xen/pci-swiotlb-xen.c
index 406f9c4..fc0c78f 100644
--- a/arch/x86/xen/pci-swiotlb-xen.c
+++ b/arch/x86/xen/pci-swiotlb-xen.c
@@ -97,6 +97,6 @@ int pci_xen_swiotlb_init_late(void)
 EXPORT_SYMBOL_GPL(pci_xen_swiotlb_init_late);
 
 IOMMU_INIT_FINISH(pci_xen_swiotlb_detect,
-		  0,
+		  NULL,
 		  pci_xen_swiotlb_init,
-		  0);
+		  NULL);
-- 
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 Sep 10 19:57:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Sep 2012 19:57:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TBA6T-0004Zh-Mb; Mon, 10 Sep 2012 19:57:05 +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 1TBA6S-0004Sa-0V
	for xen-devel@lists.xensource.com; Mon, 10 Sep 2012 19:57:04 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1347307016!3426137!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDc0NzYwMw==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29844 invoked from network); 10 Sep 2012 19:56:57 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-14.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 10 Sep 2012 19:56: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 q8AJupLp011038
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 10 Sep 2012 19:56:52 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
	q8AJunu1021898
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 10 Sep 2012 19:56:50 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
	q8AJun8u000555; Mon, 10 Sep 2012 14:56:49 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 10 Sep 2012 12:56:49 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 2D0804035B; Mon, 10 Sep 2012 15:46:09 -0400 (EDT)
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: linux-kernel@vger.kernel.org, xen-devel@lists.xensource.com,
	stefano.stabellini@eu.citrix.com
Date: Mon, 10 Sep 2012 15:46:06 -0400
Message-Id: <1347306367-28669-10-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.7.7.6
In-Reply-To: <1347306367-28669-1-git-send-email-konrad.wilk@oracle.com>
References: <1347306367-28669-1-git-send-email-konrad.wilk@oracle.com>
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: [Xen-devel] [PATCH 09/10] xen/swiotlb: Fix compile warnings when
	using plain integer instead of NULL pointer.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

arch/x86/xen/pci-swiotlb-xen.c:96:1: warning: Using plain integer as NULL pointer
arch/x86/xen/pci-swiotlb-xen.c:96:1: warning: Using plain integer as NULL pointer

Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 arch/x86/xen/pci-swiotlb-xen.c |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/x86/xen/pci-swiotlb-xen.c b/arch/x86/xen/pci-swiotlb-xen.c
index 406f9c4..fc0c78f 100644
--- a/arch/x86/xen/pci-swiotlb-xen.c
+++ b/arch/x86/xen/pci-swiotlb-xen.c
@@ -97,6 +97,6 @@ int pci_xen_swiotlb_init_late(void)
 EXPORT_SYMBOL_GPL(pci_xen_swiotlb_init_late);
 
 IOMMU_INIT_FINISH(pci_xen_swiotlb_detect,
-		  0,
+		  NULL,
 		  pci_xen_swiotlb_init,
-		  0);
+		  NULL);
-- 
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 Sep 10 20:21:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Sep 2012 20: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 1TBATe-0006ba-5k; Mon, 10 Sep 2012 20:21:02 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1TBATc-0006bV-NK
	for xen-devel@lists.xen.org; Mon, 10 Sep 2012 20:21:00 +0000
Received: from [85.158.143.35:10477] by server-3.bemta-4.messagelabs.com id
	B4/9B-08232-CAB4E405; Mon, 10 Sep 2012 20:21:00 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1347308459!14238559!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTIyODk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14266 invoked from network); 10 Sep 2012 20:20:59 -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;
	10 Sep 2012 20:20:59 -0000
X-IronPort-AV: E=Sophos;i="4.80,398,1344211200"; d="scan'208";a="14454082"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Sep 2012 20:20: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.279.1;
	Mon, 10 Sep 2012 21:20:22 +0100
Message-ID: <1347308422.10570.71.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Konrad Rzeszutek Wilk <konrad@kernel.org>
Date: Mon, 10 Sep 2012 21:20:22 +0100
In-Reply-To: <20120910192732.GB28298@phenom.dumpdata.com>
References: <504E10DA.6040603@tiscali.it>
	<20120910192732.GB28298@phenom.dumpdata.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: bunkertor <bunkertor@tiscali.it>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] grub error 28
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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-09-10 at 20:27 +0100, Konrad Rzeszutek Wilk wrote:
> > [root@xen-02 xen-unstable]# ls -lh /boot/
> > totale 247M
> > -rw-r--r--. 1 root root 100K 24 ago 03:31 config-2.6.32-279.5.2.el6.x86_64
> > -rw-r--r--. 1 root root 100K 22 giu 14:44 config-2.6.32-279.el6.x86_64
> > -rw-r--r--. 1 root root 114K  9 set 02:09 config-3.1.0-rc9
> > drwxr-xr-x. 3 root root 4,0K  9 set 00:16 efi
> > drwxr-xr-x. 2 root root 4,0K  9 set 12:11 grub
> > -rw-r--r--. 1 root root  23M  9 set 01:16
> > initramfs-2.6.32-279.5.2.el6.x86_64.img
> > -rw-r--r--. 1 root root  23M  9 set 00:17
> > initramfs-2.6.32-279.el6.x86_64.img
> > -rw-r--r--. 1 root root 154M  9 set 02:31 initramfs-3.1.0-rc9.img
> 
> This is pretty large? Any reason its so huge compared to the other ones?

Self built kernel with debug + unstripped modules perhaps? Not sure what
the behaviour of RH's mkinitrd (drakut?) is but if it includes a large
selection of modules, all of which have full debug then it could quickly
add up to those sorts of sizes.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 10 20:21:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Sep 2012 20: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 1TBATe-0006ba-5k; Mon, 10 Sep 2012 20:21:02 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1TBATc-0006bV-NK
	for xen-devel@lists.xen.org; Mon, 10 Sep 2012 20:21:00 +0000
Received: from [85.158.143.35:10477] by server-3.bemta-4.messagelabs.com id
	B4/9B-08232-CAB4E405; Mon, 10 Sep 2012 20:21:00 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1347308459!14238559!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTIyODk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14266 invoked from network); 10 Sep 2012 20:20:59 -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;
	10 Sep 2012 20:20:59 -0000
X-IronPort-AV: E=Sophos;i="4.80,398,1344211200"; d="scan'208";a="14454082"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Sep 2012 20:20: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.279.1;
	Mon, 10 Sep 2012 21:20:22 +0100
Message-ID: <1347308422.10570.71.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Konrad Rzeszutek Wilk <konrad@kernel.org>
Date: Mon, 10 Sep 2012 21:20:22 +0100
In-Reply-To: <20120910192732.GB28298@phenom.dumpdata.com>
References: <504E10DA.6040603@tiscali.it>
	<20120910192732.GB28298@phenom.dumpdata.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: bunkertor <bunkertor@tiscali.it>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] grub error 28
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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-09-10 at 20:27 +0100, Konrad Rzeszutek Wilk wrote:
> > [root@xen-02 xen-unstable]# ls -lh /boot/
> > totale 247M
> > -rw-r--r--. 1 root root 100K 24 ago 03:31 config-2.6.32-279.5.2.el6.x86_64
> > -rw-r--r--. 1 root root 100K 22 giu 14:44 config-2.6.32-279.el6.x86_64
> > -rw-r--r--. 1 root root 114K  9 set 02:09 config-3.1.0-rc9
> > drwxr-xr-x. 3 root root 4,0K  9 set 00:16 efi
> > drwxr-xr-x. 2 root root 4,0K  9 set 12:11 grub
> > -rw-r--r--. 1 root root  23M  9 set 01:16
> > initramfs-2.6.32-279.5.2.el6.x86_64.img
> > -rw-r--r--. 1 root root  23M  9 set 00:17
> > initramfs-2.6.32-279.el6.x86_64.img
> > -rw-r--r--. 1 root root 154M  9 set 02:31 initramfs-3.1.0-rc9.img
> 
> This is pretty large? Any reason its so huge compared to the other ones?

Self built kernel with debug + unstripped modules perhaps? Not sure what
the behaviour of RH's mkinitrd (drakut?) is but if it includes a large
selection of modules, all of which have full debug then it could quickly
add up to those sorts of sizes.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 10 20:47:01 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Sep 2012 20: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 1TBAsa-0007rH-Oo; Mon, 10 Sep 2012 20:46: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 1TBAsZ-0007qq-5l
	for xen-devel@lists.xen.org; Mon, 10 Sep 2012 20:46:47 +0000
Received: from [85.158.138.51:53485] by server-8.bemta-3.messagelabs.com id
	E2/0E-24700-6B15E405; Mon, 10 Sep 2012 20:46:46 +0000
X-Env-Sender: msw@amazon.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1347310004!21736349!1
X-Originating-IP: [207.171.189.228]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA3LjE3MS4xODkuMjI4ID0+IDgyNTU3\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29678 invoked from network); 10 Sep 2012 20:46:45 -0000
Received: from smtp-fw-33001.amazon.com (HELO smtp-fw-33001.amazon.com)
	(207.171.189.228)
	by server-6.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Sep 2012 20:46: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=1347310005; x=1378846005;
	h=date:from:to:cc:subject:message-id:references:
	mime-version:in-reply-to;
	bh=q7zwxUIhud9Bus8epz2+fMHiOzL/o2ft2qUsscPsX+o=;
	b=TK5M4h2VWe7WAtAWRVcRqNNwE9WPrlwe1oWRYqfovjb8QIDLixBgGkKq
	Fp19YxveZoOPMKqGiig3iZ8WEq+now==;
X-IronPort-AV: E=Sophos;i="4.80,400,1344211200"; d="scan'208";a="359057374"
Received: from smtp-in-31001.sea31.amazon.com ([10.184.168.27])
	by smtp-border-fw-out-33001.sea14.amazon.com with
	ESMTP/TLS/DHE-RSA-AES256-SHA; 10 Sep 2012 20:46:42 +0000
Received: from ex10-hub-31006.ant.amazon.com (ex10-hub-31006.sea31.amazon.com
	[10.185.176.13])
	by smtp-in-31001.sea31.amazon.com (8.13.8/8.13.8) with ESMTP id
	q8AKkfjm025253
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL);
	Mon, 10 Sep 2012 20:46:42 GMT
Received: from u002268147cd4502c336d.ant.amazon.com (10.224.80.42) by
	ex10-hub-31006.ant.amazon.com (10.185.176.13) with Microsoft SMTP
	Server id 14.2.247.3; Mon, 10 Sep 2012 13:46:37 -0700
Received: by u002268147cd4502c336d.ant.amazon.com (sSMTP sendmail emulation); 
	Mon, 10 Sep 2012 13:46:37 -0700
Date: Mon, 10 Sep 2012 13:46:37 -0700
From: Matt Wilson <msw@amazon.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120910204635.GA32584@u002268147cd4502c336d.ant.amazon.com>
References: <patchbomb.1346992557@u002268147cd4502c336d.ant.amazon.com>
	<3b3582f4dc423daa8040.1346992558@u002268147cd4502c336d.ant.amazon.com>
	<1347293350.5305.113.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1347293350.5305.113.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 1 of 2 v3] tools: check for documentation
 generation tools at configure 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 Mon, Sep 10, 2012 at 05:09:10PM +0100, Ian Campbell wrote:
> 
> > diff -r d7e4efa17fb0 -r 3b3582f4dc42 tools/m4/docs_tool.m4
> > --- /dev/null	Thu Jan 01 00:00:00 1970 +0000
> > +++ b/tools/m4/docs_tool.m4	Thu Sep 06 21:31:51 2012 -0700
> > @@ -0,0 +1,10 @@
> > +# $1: autoconf variable name
> > +# $2: list of programs to check for
> > +AC_DEFUN([AX_DOCS_TOOL_PROGS], [
> > +dnl
> > +    AC_ARG_VAR([$1], [Path to ] m4_tolower($1) [ tool])
> > +    AC_PATH_PROGS([$1], [$2])
> > +    AS_IF([! test -x "$ac_cv_path_$1"], [
> > +        AC_MSG_WARN([$2 is not available so some documentation won't be built])
> 
> Did you mean m4_tolower($1) for this last $2 as well? Since $2 is the
> list of potential command names this will look a bit odd I think?

Yea, that could be better. Though I kind of like that it shows the
programs that were checked. It'd look like:
 
 markdown markdown_py is not available so some documentation won't be built

Maybe just drop 'is' to avoid the verb mismatch.

Matt

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 10 20:47:01 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Sep 2012 20: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 1TBAsa-0007rH-Oo; Mon, 10 Sep 2012 20:46: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 1TBAsZ-0007qq-5l
	for xen-devel@lists.xen.org; Mon, 10 Sep 2012 20:46:47 +0000
Received: from [85.158.138.51:53485] by server-8.bemta-3.messagelabs.com id
	E2/0E-24700-6B15E405; Mon, 10 Sep 2012 20:46:46 +0000
X-Env-Sender: msw@amazon.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1347310004!21736349!1
X-Originating-IP: [207.171.189.228]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA3LjE3MS4xODkuMjI4ID0+IDgyNTU3\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29678 invoked from network); 10 Sep 2012 20:46:45 -0000
Received: from smtp-fw-33001.amazon.com (HELO smtp-fw-33001.amazon.com)
	(207.171.189.228)
	by server-6.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Sep 2012 20:46: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=1347310005; x=1378846005;
	h=date:from:to:cc:subject:message-id:references:
	mime-version:in-reply-to;
	bh=q7zwxUIhud9Bus8epz2+fMHiOzL/o2ft2qUsscPsX+o=;
	b=TK5M4h2VWe7WAtAWRVcRqNNwE9WPrlwe1oWRYqfovjb8QIDLixBgGkKq
	Fp19YxveZoOPMKqGiig3iZ8WEq+now==;
X-IronPort-AV: E=Sophos;i="4.80,400,1344211200"; d="scan'208";a="359057374"
Received: from smtp-in-31001.sea31.amazon.com ([10.184.168.27])
	by smtp-border-fw-out-33001.sea14.amazon.com with
	ESMTP/TLS/DHE-RSA-AES256-SHA; 10 Sep 2012 20:46:42 +0000
Received: from ex10-hub-31006.ant.amazon.com (ex10-hub-31006.sea31.amazon.com
	[10.185.176.13])
	by smtp-in-31001.sea31.amazon.com (8.13.8/8.13.8) with ESMTP id
	q8AKkfjm025253
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL);
	Mon, 10 Sep 2012 20:46:42 GMT
Received: from u002268147cd4502c336d.ant.amazon.com (10.224.80.42) by
	ex10-hub-31006.ant.amazon.com (10.185.176.13) with Microsoft SMTP
	Server id 14.2.247.3; Mon, 10 Sep 2012 13:46:37 -0700
Received: by u002268147cd4502c336d.ant.amazon.com (sSMTP sendmail emulation); 
	Mon, 10 Sep 2012 13:46:37 -0700
Date: Mon, 10 Sep 2012 13:46:37 -0700
From: Matt Wilson <msw@amazon.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120910204635.GA32584@u002268147cd4502c336d.ant.amazon.com>
References: <patchbomb.1346992557@u002268147cd4502c336d.ant.amazon.com>
	<3b3582f4dc423daa8040.1346992558@u002268147cd4502c336d.ant.amazon.com>
	<1347293350.5305.113.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1347293350.5305.113.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 1 of 2 v3] tools: check for documentation
 generation tools at configure 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 Mon, Sep 10, 2012 at 05:09:10PM +0100, Ian Campbell wrote:
> 
> > diff -r d7e4efa17fb0 -r 3b3582f4dc42 tools/m4/docs_tool.m4
> > --- /dev/null	Thu Jan 01 00:00:00 1970 +0000
> > +++ b/tools/m4/docs_tool.m4	Thu Sep 06 21:31:51 2012 -0700
> > @@ -0,0 +1,10 @@
> > +# $1: autoconf variable name
> > +# $2: list of programs to check for
> > +AC_DEFUN([AX_DOCS_TOOL_PROGS], [
> > +dnl
> > +    AC_ARG_VAR([$1], [Path to ] m4_tolower($1) [ tool])
> > +    AC_PATH_PROGS([$1], [$2])
> > +    AS_IF([! test -x "$ac_cv_path_$1"], [
> > +        AC_MSG_WARN([$2 is not available so some documentation won't be built])
> 
> Did you mean m4_tolower($1) for this last $2 as well? Since $2 is the
> list of potential command names this will look a bit odd I think?

Yea, that could be better. Though I kind of like that it shows the
programs that were checked. It'd look like:
 
 markdown markdown_py is not available so some documentation won't be built

Maybe just drop 'is' to avoid the verb mismatch.

Matt

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 10 20:51:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Sep 2012 20:51:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TBAwZ-0008G4-N9; Mon, 10 Sep 2012 20:50:55 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <bunkertor@tiscali.it>) id 1TBAwY-0008Fw-4m
	for xen-devel@lists.xen.org; Mon, 10 Sep 2012 20:50:54 +0000
Received: from [85.158.143.35:35456] by server-1.bemta-4.messagelabs.com id
	7F/99-12504-DA25E405; Mon, 10 Sep 2012 20:50:53 +0000
X-Env-Sender: bunkertor@tiscali.it
X-Msg-Ref: server-4.tower-21.messagelabs.com!1347310252!5891497!1
X-Originating-IP: [213.205.33.245]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjEzLjIwNS4zMy4yNDUgPT4gMjAzMjU=\n,
	ML_RADAR_SPEW_LINKS_14,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1455 invoked from network); 10 Sep 2012 20:50:52 -0000
Received: from santino.mail.tiscali.it (HELO santino.mail.tiscali.it)
	(213.205.33.245) by server-4.tower-21.messagelabs.com with SMTP;
	10 Sep 2012 20:50:52 -0000
Received: from [172.16.1.180] ([78.13.188.52]) by santino.mail.tiscali.it with 
	id xYqr1j00718G0wm01Yqr2R; Mon, 10 Sep 2012 22:50:52 +0200
Message-ID: <504E52AB.1000407@tiscali.it>
Date: Mon, 10 Sep 2012 22:50:51 +0200
From: bunkertor <bunkertor@tiscali.it>
User-Agent: Mozilla/5.0 (Windows NT 5.1;
	rv:11.0) Gecko/20120327 Thunderbird/11.0.1
MIME-Version: 1.0
To: xen-devel@lists.xen.org
References: <504E10DA.6040603@tiscali.it>
	<20120910192732.GB28298@phenom.dumpdata.com>
	<1347308422.10570.71.camel@dagon.hellion.org.uk>
In-Reply-To: <1347308422.10570.71.camel@dagon.hellion.org.uk>
Subject: Re: [Xen-devel] grub error 28
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Il 10/09/2012 22.20, Ian Campbell ha scritto:
> On Mon, 2012-09-10 at 20:27 +0100, Konrad Rzeszutek Wilk wrote:
>>> [root@xen-02 xen-unstable]# ls -lh /boot/
>>> totale 247M
>>> -rw-r--r--. 1 root root 100K 24 ago 03:31 config-2.6.32-279.5.2.el6.x86_64
>>> -rw-r--r--. 1 root root 100K 22 giu 14:44 config-2.6.32-279.el6.x86_64
>>> -rw-r--r--. 1 root root 114K  9 set 02:09 config-3.1.0-rc9
>>> drwxr-xr-x. 3 root root 4,0K  9 set 00:16 efi
>>> drwxr-xr-x. 2 root root 4,0K  9 set 12:11 grub
>>> -rw-r--r--. 1 root root  23M  9 set 01:16
>>> initramfs-2.6.32-279.5.2.el6.x86_64.img
>>> -rw-r--r--. 1 root root  23M  9 set 00:17
>>> initramfs-2.6.32-279.el6.x86_64.img
>>> -rw-r--r--. 1 root root 154M  9 set 02:31 initramfs-3.1.0-rc9.img
>> This is pretty large? Any reason its so huge compared to the other ones?
> Self built kernel with debug + unstripped modules perhaps? Not sure what
> the behaviour of RH's mkinitrd (drakut?) is but if it includes a large
> selection of modules, all of which have full debug then it could quickly
> add up to those sorts of sizes.
>
> Ian.
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
>
hi

i use dracut, --strip should be the default...

regards.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 10 20:51:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Sep 2012 20:51:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TBAwZ-0008G4-N9; Mon, 10 Sep 2012 20:50:55 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <bunkertor@tiscali.it>) id 1TBAwY-0008Fw-4m
	for xen-devel@lists.xen.org; Mon, 10 Sep 2012 20:50:54 +0000
Received: from [85.158.143.35:35456] by server-1.bemta-4.messagelabs.com id
	7F/99-12504-DA25E405; Mon, 10 Sep 2012 20:50:53 +0000
X-Env-Sender: bunkertor@tiscali.it
X-Msg-Ref: server-4.tower-21.messagelabs.com!1347310252!5891497!1
X-Originating-IP: [213.205.33.245]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjEzLjIwNS4zMy4yNDUgPT4gMjAzMjU=\n,
	ML_RADAR_SPEW_LINKS_14,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1455 invoked from network); 10 Sep 2012 20:50:52 -0000
Received: from santino.mail.tiscali.it (HELO santino.mail.tiscali.it)
	(213.205.33.245) by server-4.tower-21.messagelabs.com with SMTP;
	10 Sep 2012 20:50:52 -0000
Received: from [172.16.1.180] ([78.13.188.52]) by santino.mail.tiscali.it with 
	id xYqr1j00718G0wm01Yqr2R; Mon, 10 Sep 2012 22:50:52 +0200
Message-ID: <504E52AB.1000407@tiscali.it>
Date: Mon, 10 Sep 2012 22:50:51 +0200
From: bunkertor <bunkertor@tiscali.it>
User-Agent: Mozilla/5.0 (Windows NT 5.1;
	rv:11.0) Gecko/20120327 Thunderbird/11.0.1
MIME-Version: 1.0
To: xen-devel@lists.xen.org
References: <504E10DA.6040603@tiscali.it>
	<20120910192732.GB28298@phenom.dumpdata.com>
	<1347308422.10570.71.camel@dagon.hellion.org.uk>
In-Reply-To: <1347308422.10570.71.camel@dagon.hellion.org.uk>
Subject: Re: [Xen-devel] grub error 28
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Il 10/09/2012 22.20, Ian Campbell ha scritto:
> On Mon, 2012-09-10 at 20:27 +0100, Konrad Rzeszutek Wilk wrote:
>>> [root@xen-02 xen-unstable]# ls -lh /boot/
>>> totale 247M
>>> -rw-r--r--. 1 root root 100K 24 ago 03:31 config-2.6.32-279.5.2.el6.x86_64
>>> -rw-r--r--. 1 root root 100K 22 giu 14:44 config-2.6.32-279.el6.x86_64
>>> -rw-r--r--. 1 root root 114K  9 set 02:09 config-3.1.0-rc9
>>> drwxr-xr-x. 3 root root 4,0K  9 set 00:16 efi
>>> drwxr-xr-x. 2 root root 4,0K  9 set 12:11 grub
>>> -rw-r--r--. 1 root root  23M  9 set 01:16
>>> initramfs-2.6.32-279.5.2.el6.x86_64.img
>>> -rw-r--r--. 1 root root  23M  9 set 00:17
>>> initramfs-2.6.32-279.el6.x86_64.img
>>> -rw-r--r--. 1 root root 154M  9 set 02:31 initramfs-3.1.0-rc9.img
>> This is pretty large? Any reason its so huge compared to the other ones?
> Self built kernel with debug + unstripped modules perhaps? Not sure what
> the behaviour of RH's mkinitrd (drakut?) is but if it includes a large
> selection of modules, all of which have full debug then it could quickly
> add up to those sorts of sizes.
>
> Ian.
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
>
hi

i use dracut, --strip should be the default...

regards.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 10 20:52:21 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Sep 2012 20: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 1TBAxg-0008MO-6b; Mon, 10 Sep 2012 20:52:04 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1TBAxf-0008ME-Af
	for xen-devel@lists.xen.org; Mon, 10 Sep 2012 20:52:03 +0000
Received: from [85.158.138.51:11421] by server-11.bemta-3.messagelabs.com id
	9B/2C-30250-2F25E405; Mon, 10 Sep 2012 20:52:02 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1347310321!29754951!1
X-Originating-IP: [209.85.215.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13206 invoked from network); 10 Sep 2012 20:52:01 -0000
Received: from mail-ey0-f173.google.com (HELO mail-ey0-f173.google.com)
	(209.85.215.173)
	by server-11.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Sep 2012 20:52:01 -0000
Received: by eaac13 with SMTP id c13so1157017eaa.32
	for <xen-devel@lists.xen.org>; Mon, 10 Sep 2012 13:52: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:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=7fiuBrE+tG6sLjLcdIy6GLyzj4eF2tnRx5W4d7ViZGY=;
	b=kbVQIs5wupuBKjzp5emsohgZDNjFhv2cnJ9j4UKN16jzRBEyYEXOnm4/jwb/d3o/mN
	VufkktzdJ3K+29o79767GpwHCACVs+Nl1XBKfGth+Z2+ao+dYRX2UApsNbU1Si5noo9D
	lgMvNawY2v1a6+oLwHv3AInIer0Pw19m0sn9PIv6EdA8aYfnx1fEI1XNIth4r19XzpVT
	1d+OzELWxZZ6wr19V5rqoxtkcNe4Ck8afJuxvyaH9zs+emfwGivPJ1yml6jXgkLhCrZE
	vBmGipajo0odKRrpX9vhrh5LF5QJwJeV06+r0j/lvc4VdZW5Rqtjag2U16Ep731Juup5
	rEvQ==
Received: by 10.14.175.7 with SMTP id y7mr21513011eel.29.1347310321518;
	Mon, 10 Sep 2012 13:52:01 -0700 (PDT)
Received: from [192.168.1.3] (host86-184-74-117.range86-184.btcentralplus.com.
	[86.184.74.117])
	by mx.google.com with ESMTPS id l42sm41344583eep.1.2012.09.10.13.51.58
	(version=SSLv3 cipher=OTHER); Mon, 10 Sep 2012 13:52:00 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.33.0.120411
Date: Mon, 10 Sep 2012 21:51:51 +0100
From: Keir Fraser <keir@xen.org>
To: Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	<xen-devel@lists.xen.org>
Message-ID: <CC741177.4B381%keir@xen.org>
Thread-Topic: [Xen-devel] [PATCH v2] Merge IS_PRIV checks into XSM hooks
Thread-Index: Ac2PlhojYZSgAtjdVE+QLDMywoddpQ==
In-Reply-To: <1347306553-20980-1-git-send-email-dgdegra@tycho.nsa.gov>
Mime-version: 1.0
Subject: Re: [Xen-devel] [PATCH v2] Merge IS_PRIV checks into XSM hooks
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/09/2012 20:48, "Daniel De Graaf" <dgdegra@tycho.nsa.gov> wrote:

> Overall, this series should not change the behavior of Xen when XSM is
> not enabled; however, in some cases, the exact errors that are returned
> will be different because security checks have been moved below validity
> checks. Also, once applied, newly introduced domctls and sysctls will
> not automatically be guarded by IS_PRIV checks - they will need to add
> their own permission checking code.

How do we guard against accidentally forgetting to do this?

> The ARM architecture is not touched at all in these patches. The only
> obvious breakage that I can see is due to rcu_lock_target_domain_by_id
> being removed, but XSM hooks will be needed for domctls and sysctls.

So ARM build is broken? And/or ARM is made insecure because of unchecked
sysctls/domctls?

 -- Keir

> The rcu_lock_target_domain_by_id and rcu_lock_remote_target_domain_by_id
> functions are removed by this series because they act as wrappers around
> IS_PRIV_FOR; their callers have been changed to use XSM checks instead.
> 
> Miscellaneous updates to FLASK:
>     [PATCH 01/20] xsm/flask: remove inherited class attributes
>     [PATCH 02/20] xsm/flask: remove unneeded create_sid field
>     [PATCH 03/20] xen: Add versions of rcu_lock_*_domain without IS_PRIV
>     [PATCH 04/20] xsm/flask: add domain relabel support
>     [PATCH 05/20] libxl: introduce XSM relabel on build
>     [PATCH 06/20] flask/policy: Add domain relabel example
> 
> Preparatory new hooks:
>     [PATCH 07/20] arch/x86: add distinct XSM hooks for map/unmap
>     [PATCH 08/20] arch/x86: add missing XSM checks to XENPF_ commands
>     [PATCH 09/20] xsm/flask: Add checks on the domain performing the
> 
> Refactoring:
>     [PATCH 10/20] xsm: Add IS_PRIV checks to dummy XSM module
>     [PATCH 11/20] xen: use XSM instead of IS_PRIV where duplicated
>     [PATCH 12/20] xen: avoid calling rcu_lock_*target_domain when an XSM
> 
> Remaining IS_PRIV calls:
>     [PATCH 13/20] arch/x86: Add missing domctl and mem_sharing XSM hooks
>     [PATCH 14/20] tmem: Add access control check
>     [PATCH 17/20] arch/x86: use XSM hooks for get_pg_owner access checks
>     [PATCH 18/20] xen: Add XSM hook for XENMEM_exchange
> 
> Cleanup, FLASK updates to support IS_PRIV emulation:
>     [PATCH 15/20] xsm: remove unneeded xsm_call macro
>     [PATCH 16/20] xsm/flask: add distinct SIDs for self/target access
>     [PATCH 19/20] xen: remove rcu_lock_{remote_,}target_domain_by_id
>     [PATCH 20/20] flask: add missing operations
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Sep 10 20:52:21 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Sep 2012 20: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 1TBAxg-0008MO-6b; Mon, 10 Sep 2012 20:52:04 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1TBAxf-0008ME-Af
	for xen-devel@lists.xen.org; Mon, 10 Sep 2012 20:52:03 +0000
Received: from [85.158.138.51:11421] by server-11.bemta-3.messagelabs.com id
	9B/2C-30250-2F25E405; Mon, 10 Sep 2012 20:52:02 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1347310321!29754951!1
X-Originating-IP: [209.85.215.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13206 invoked from network); 10 Sep 2012 20:52:01 -0000
Received: from mail-ey0-f173.google.com (HELO mail-ey0-f173.google.com)
	(209.85.215.173)
	by server-11.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Sep 2012 20:52:01 -0000
Received: by eaac13 with SMTP id c13so1157017eaa.32
	for <xen-devel@lists.xen.org>; Mon, 10 Sep 2012 13:52: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:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=7fiuBrE+tG6sLjLcdIy6GLyzj4eF2tnRx5W4d7ViZGY=;
	b=kbVQIs5wupuBKjzp5emsohgZDNjFhv2cnJ9j4UKN16jzRBEyYEXOnm4/jwb/d3o/mN
	VufkktzdJ3K+29o79767GpwHCACVs+Nl1XBKfGth+Z2+ao+dYRX2UApsNbU1Si5noo9D
	lgMvNawY2v1a6+oLwHv3AInIer0Pw19m0sn9PIv6EdA8aYfnx1fEI1XNIth4r19XzpVT
	1d+OzELWxZZ6wr19V5rqoxtkcNe4Ck8afJuxvyaH9zs+emfwGivPJ1yml6jXgkLhCrZE
	vBmGipajo0odKRrpX9vhrh5LF5QJwJeV06+r0j/lvc4VdZW5Rqtjag2U16Ep731Juup5
	rEvQ==
Received: by 10.14.175.7 with SMTP id y7mr21513011eel.29.1347310321518;
	Mon, 10 Sep 2012 13:52:01 -0700 (PDT)
Received: from [192.168.1.3] (host86-184-74-117.range86-184.btcentralplus.com.
	[86.184.74.117])
	by mx.google.com with ESMTPS id l42sm41344583eep.1.2012.09.10.13.51.58
	(version=SSLv3 cipher=OTHER); Mon, 10 Sep 2012 13:52:00 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.33.0.120411
Date: Mon, 10 Sep 2012 21:51:51 +0100
From: Keir Fraser <keir@xen.org>
To: Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	<xen-devel@lists.xen.org>
Message-ID: <CC741177.4B381%keir@xen.org>
Thread-Topic: [Xen-devel] [PATCH v2] Merge IS_PRIV checks into XSM hooks
Thread-Index: Ac2PlhojYZSgAtjdVE+QLDMywoddpQ==
In-Reply-To: <1347306553-20980-1-git-send-email-dgdegra@tycho.nsa.gov>
Mime-version: 1.0
Subject: Re: [Xen-devel] [PATCH v2] Merge IS_PRIV checks into XSM hooks
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/09/2012 20:48, "Daniel De Graaf" <dgdegra@tycho.nsa.gov> wrote:

> Overall, this series should not change the behavior of Xen when XSM is
> not enabled; however, in some cases, the exact errors that are returned
> will be different because security checks have been moved below validity
> checks. Also, once applied, newly introduced domctls and sysctls will
> not automatically be guarded by IS_PRIV checks - they will need to add
> their own permission checking code.

How do we guard against accidentally forgetting to do this?

> The ARM architecture is not touched at all in these patches. The only
> obvious breakage that I can see is due to rcu_lock_target_domain_by_id
> being removed, but XSM hooks will be needed for domctls and sysctls.

So ARM build is broken? And/or ARM is made insecure because of unchecked
sysctls/domctls?

 -- Keir

> The rcu_lock_target_domain_by_id and rcu_lock_remote_target_domain_by_id
> functions are removed by this series because they act as wrappers around
> IS_PRIV_FOR; their callers have been changed to use XSM checks instead.
> 
> Miscellaneous updates to FLASK:
>     [PATCH 01/20] xsm/flask: remove inherited class attributes
>     [PATCH 02/20] xsm/flask: remove unneeded create_sid field
>     [PATCH 03/20] xen: Add versions of rcu_lock_*_domain without IS_PRIV
>     [PATCH 04/20] xsm/flask: add domain relabel support
>     [PATCH 05/20] libxl: introduce XSM relabel on build
>     [PATCH 06/20] flask/policy: Add domain relabel example
> 
> Preparatory new hooks:
>     [PATCH 07/20] arch/x86: add distinct XSM hooks for map/unmap
>     [PATCH 08/20] arch/x86: add missing XSM checks to XENPF_ commands
>     [PATCH 09/20] xsm/flask: Add checks on the domain performing the
> 
> Refactoring:
>     [PATCH 10/20] xsm: Add IS_PRIV checks to dummy XSM module
>     [PATCH 11/20] xen: use XSM instead of IS_PRIV where duplicated
>     [PATCH 12/20] xen: avoid calling rcu_lock_*target_domain when an XSM
> 
> Remaining IS_PRIV calls:
>     [PATCH 13/20] arch/x86: Add missing domctl and mem_sharing XSM hooks
>     [PATCH 14/20] tmem: Add access control check
>     [PATCH 17/20] arch/x86: use XSM hooks for get_pg_owner access checks
>     [PATCH 18/20] xen: Add XSM hook for XENMEM_exchange
> 
> Cleanup, FLASK updates to support IS_PRIV emulation:
>     [PATCH 15/20] xsm: remove unneeded xsm_call macro
>     [PATCH 16/20] xsm/flask: add distinct SIDs for self/target access
>     [PATCH 19/20] xen: remove rcu_lock_{remote_,}target_domain_by_id
>     [PATCH 20/20] flask: add missing operations
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Sep 10 21:03:45 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Sep 2012 21:03: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 1TBB8i-0000Rg-DP; Mon, 10 Sep 2012 21:03:28 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <steve@zentific.com>) id 1TBB8g-0000Rb-Qm
	for xen-devel@lists.xen.org; Mon, 10 Sep 2012 21:03:27 +0000
Received: from [85.158.143.35:27000] by server-2.bemta-4.messagelabs.com id
	A1/9F-21239-E955E405; Mon, 10 Sep 2012 21:03:26 +0000
X-Env-Sender: steve@zentific.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1347311004!13974303!1
X-Originating-IP: [209.85.220.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 922 invoked from network); 10 Sep 2012 21:03:25 -0000
Received: from mail-vc0-f173.google.com (HELO mail-vc0-f173.google.com)
	(209.85.220.173)
	by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Sep 2012 21:03:25 -0000
Received: by vcbfl15 with SMTP id fl15so932852vcb.32
	for <xen-devel@lists.xen.org>; Mon, 10 Sep 2012 14:03:24 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:user-agent:date:from:to:cc
	:x-gm-message-state;
	bh=erjCRNrR+9HWn/wYdaNYKq+balPKSEhiK2mLwM6vSjk=;
	b=WK5OtStcZNrx/w0AxBkMJXoyg+qXOXZkV0h39E1kcVYVPWYUpkFTo+M2hvEQOueSOr
	hnNXdh13BHAjn60kwkJRC+URqwKel5EvnASxT6cpjdxdDIIBq9tYmP5n1SmqMUFIIdeH
	H3eRzYhuYYtD0XkahVXMDpDNmOS9Zg60Egt557eAXcE0EfAgvASGktyD8XrrHkRoA3ki
	YfSOCDe1BtBtwpBGCkeB8DcQx9zrpk5V+sPSHpcKFj0ow5KNO5rq/C0RkewZ7pcXruRu
	36dXRrEak4wxJyCBm2kTqS9NdDhHMa33ffHmUMKJaMwwY++73Sx2OTPcloRMowB1ZhFq
	u6tg==
Received: by 10.52.35.104 with SMTP id g8mr17701349vdj.20.1347310997417;
	Mon, 10 Sep 2012 14:03:17 -0700 (PDT)
Received: from [127.0.1.1] ([50.28.129.85])
	by mx.google.com with ESMTPS id da9sm10201692vdc.11.2012.09.10.14.03.16
	(version=TLSv1/SSLv3 cipher=OTHER);
	Mon, 10 Sep 2012 14:03:16 -0700 (PDT)
MIME-Version: 1.0
X-Mercurial-Node: 4d31c1c8641846fa42faafe1f0643f06f40f05ba
Message-Id: <4d31c1c8641846fa42fa.1347310995@steve-xen>
User-Agent: Mercurial-patchbomb/2.0.2
Date: Mon, 10 Sep 2012 17:03:15 -0400
From: Steven Maresca <steve@zentific.com>
To: xen-devel@lists.xen.org
X-Gm-Message-State: ALoCoQnZe1+MkJBtoCg+vRCUzr7cM0PWWoIq8J2LDovoeN0hS9otA76+DXXxOKn+j3T4mNCEhSXr
Cc: aravindh@virtuata.com, andres@lagarcavilla.org
Subject: [Xen-devel] [PATCH] mem_event: fix regression affecting CR3,
	CR4 memory events
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a patch repairing a regression in code previously functional in 4.1.x. It appears that, during some refactoring work, calls to hvm_memory_event_cr3 and hvm_memory_event_cr4 were lost.

These functions were originally called in mov_to_cr() of vmx.c, but the commit  http://xenbits.xen.org/hg/xen-unstable.hg/rev/1276926e3795 abstracted the original code into generic functions up a level in hvm.c, dropping these calls in the process.

Signed-off-by: Steven Maresca <steve@zentific.com>

diff -r a64f4e107951 -r 4d31c1c86418 xen/arch/x86/hvm/hvm.c
--- a/xen/arch/x86/hvm/hvm.c	Fri Sep 07 11:09:46 2012 +0100
+++ b/xen/arch/x86/hvm/hvm.c	Mon Sep 10 16:48:15 2012 -0400
@@ -1758,6 +1758,7 @@ int hvm_set_cr3(unsigned long value)
 {
     struct vcpu *v = current;
     struct page_info *page;
+    unsigned long old;
 
     if ( hvm_paging_enabled(v) && !paging_mode_hap(v->domain) &&
          (value != v->arch.hvm_vcpu.guest_cr[3]) )
@@ -1775,8 +1776,10 @@ int hvm_set_cr3(unsigned long value)
         HVM_DBG_LOG(DBG_LEVEL_VMMU, "Update CR3 value = %lx", value);
     }
 
+    old=v->arch.hvm_vcpu.guest_cr[3];
     v->arch.hvm_vcpu.guest_cr[3] = value;
     paging_update_cr3(v);
+    hvm_memory_event_cr3(value, old);
     return X86EMUL_OKAY;
 
  bad_cr3:
@@ -1818,6 +1821,7 @@ int hvm_set_cr4(unsigned long value)
 
     v->arch.hvm_vcpu.guest_cr[4] = value;
     hvm_update_guest_cr(v, 4);
+    hvm_memory_event_cr4(value, old_cr);
 
     /*
      * Modifying CR4.{PSE,PAE,PGE,SMEP}, or clearing CR4.PCIDE

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 10 21:03:45 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Sep 2012 21:03: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 1TBB8i-0000Rg-DP; Mon, 10 Sep 2012 21:03:28 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <steve@zentific.com>) id 1TBB8g-0000Rb-Qm
	for xen-devel@lists.xen.org; Mon, 10 Sep 2012 21:03:27 +0000
Received: from [85.158.143.35:27000] by server-2.bemta-4.messagelabs.com id
	A1/9F-21239-E955E405; Mon, 10 Sep 2012 21:03:26 +0000
X-Env-Sender: steve@zentific.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1347311004!13974303!1
X-Originating-IP: [209.85.220.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 922 invoked from network); 10 Sep 2012 21:03:25 -0000
Received: from mail-vc0-f173.google.com (HELO mail-vc0-f173.google.com)
	(209.85.220.173)
	by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Sep 2012 21:03:25 -0000
Received: by vcbfl15 with SMTP id fl15so932852vcb.32
	for <xen-devel@lists.xen.org>; Mon, 10 Sep 2012 14:03:24 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:user-agent:date:from:to:cc
	:x-gm-message-state;
	bh=erjCRNrR+9HWn/wYdaNYKq+balPKSEhiK2mLwM6vSjk=;
	b=WK5OtStcZNrx/w0AxBkMJXoyg+qXOXZkV0h39E1kcVYVPWYUpkFTo+M2hvEQOueSOr
	hnNXdh13BHAjn60kwkJRC+URqwKel5EvnASxT6cpjdxdDIIBq9tYmP5n1SmqMUFIIdeH
	H3eRzYhuYYtD0XkahVXMDpDNmOS9Zg60Egt557eAXcE0EfAgvASGktyD8XrrHkRoA3ki
	YfSOCDe1BtBtwpBGCkeB8DcQx9zrpk5V+sPSHpcKFj0ow5KNO5rq/C0RkewZ7pcXruRu
	36dXRrEak4wxJyCBm2kTqS9NdDhHMa33ffHmUMKJaMwwY++73Sx2OTPcloRMowB1ZhFq
	u6tg==
Received: by 10.52.35.104 with SMTP id g8mr17701349vdj.20.1347310997417;
	Mon, 10 Sep 2012 14:03:17 -0700 (PDT)
Received: from [127.0.1.1] ([50.28.129.85])
	by mx.google.com with ESMTPS id da9sm10201692vdc.11.2012.09.10.14.03.16
	(version=TLSv1/SSLv3 cipher=OTHER);
	Mon, 10 Sep 2012 14:03:16 -0700 (PDT)
MIME-Version: 1.0
X-Mercurial-Node: 4d31c1c8641846fa42faafe1f0643f06f40f05ba
Message-Id: <4d31c1c8641846fa42fa.1347310995@steve-xen>
User-Agent: Mercurial-patchbomb/2.0.2
Date: Mon, 10 Sep 2012 17:03:15 -0400
From: Steven Maresca <steve@zentific.com>
To: xen-devel@lists.xen.org
X-Gm-Message-State: ALoCoQnZe1+MkJBtoCg+vRCUzr7cM0PWWoIq8J2LDovoeN0hS9otA76+DXXxOKn+j3T4mNCEhSXr
Cc: aravindh@virtuata.com, andres@lagarcavilla.org
Subject: [Xen-devel] [PATCH] mem_event: fix regression affecting CR3,
	CR4 memory events
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a patch repairing a regression in code previously functional in 4.1.x. It appears that, during some refactoring work, calls to hvm_memory_event_cr3 and hvm_memory_event_cr4 were lost.

These functions were originally called in mov_to_cr() of vmx.c, but the commit  http://xenbits.xen.org/hg/xen-unstable.hg/rev/1276926e3795 abstracted the original code into generic functions up a level in hvm.c, dropping these calls in the process.

Signed-off-by: Steven Maresca <steve@zentific.com>

diff -r a64f4e107951 -r 4d31c1c86418 xen/arch/x86/hvm/hvm.c
--- a/xen/arch/x86/hvm/hvm.c	Fri Sep 07 11:09:46 2012 +0100
+++ b/xen/arch/x86/hvm/hvm.c	Mon Sep 10 16:48:15 2012 -0400
@@ -1758,6 +1758,7 @@ int hvm_set_cr3(unsigned long value)
 {
     struct vcpu *v = current;
     struct page_info *page;
+    unsigned long old;
 
     if ( hvm_paging_enabled(v) && !paging_mode_hap(v->domain) &&
          (value != v->arch.hvm_vcpu.guest_cr[3]) )
@@ -1775,8 +1776,10 @@ int hvm_set_cr3(unsigned long value)
         HVM_DBG_LOG(DBG_LEVEL_VMMU, "Update CR3 value = %lx", value);
     }
 
+    old=v->arch.hvm_vcpu.guest_cr[3];
     v->arch.hvm_vcpu.guest_cr[3] = value;
     paging_update_cr3(v);
+    hvm_memory_event_cr3(value, old);
     return X86EMUL_OKAY;
 
  bad_cr3:
@@ -1818,6 +1821,7 @@ int hvm_set_cr4(unsigned long value)
 
     v->arch.hvm_vcpu.guest_cr[4] = value;
     hvm_update_guest_cr(v, 4);
+    hvm_memory_event_cr4(value, old_cr);
 
     /*
      * Modifying CR4.{PSE,PAE,PGE,SMEP}, or clearing CR4.PCIDE

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 10 21:07:58 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Sep 2012 21: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 1TBBCl-0000dN-45; Mon, 10 Sep 2012 21:07:39 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <bunkertor@tiscali.it>) id 1TBBCj-0000dE-7g
	for xen-devel@lists.xen.org; Mon, 10 Sep 2012 21:07:37 +0000
X-Env-Sender: bunkertor@tiscali.it
X-Msg-Ref: server-10.tower-27.messagelabs.com!1347311250!5263743!1
X-Originating-IP: [213.205.33.245]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjEzLjIwNS4zMy4yNDUgPT4gMjAzMjU=\n,
	ML_RADAR_SPEW_LINKS_14,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3446 invoked from network); 10 Sep 2012 21:07:30 -0000
Received: from santino.mail.tiscali.it (HELO santino.mail.tiscali.it)
	(213.205.33.245) by server-10.tower-27.messagelabs.com with SMTP;
	10 Sep 2012 21:07:30 -0000
Received: from [172.16.1.180] ([78.13.188.52]) by santino.mail.tiscali.it with 
	id xZ7V1j00718G0wm01Z7Wpw; Mon, 10 Sep 2012 23:07:30 +0200
Message-ID: <504E5691.7020706@tiscali.it>
Date: Mon, 10 Sep 2012 23:07:29 +0200
From: bunkertor <bunkertor@tiscali.it>
User-Agent: Mozilla/5.0 (Windows NT 5.1;
	rv:11.0) Gecko/20120327 Thunderbird/11.0.1
MIME-Version: 1.0
To: xen-devel@lists.xen.org
References: <504E4DD5.8010705@tiscali.it> <504E5167.20901@tiscali.it>
In-Reply-To: <504E5167.20901@tiscali.it>
Subject: Re: [Xen-devel] Fwd: Re:  grub error 28
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============8619837301402093327=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a multi-part message in MIME format.
--===============8619837301402093327==
Content-Type: multipart/alternative;
 boundary="------------020701050802030109000202"

This is a multi-part message in MIME format.
--------------020701050802030109000202
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Il 10/09/2012 22.45, bunkertor ha scritto:
>
>
> -------- Messaggio originale --------
> Oggetto: 	Re: [Xen-devel] grub error 28
> Data: 	Mon, 10 Sep 2012 22:30:13 +0200
> Mittente: 	bunkertor <bunkertor@tiscali.it>
> A: 	Konrad Rzeszutek Wilk <konrad@kernel.org>
>
>
>
> Il 10/09/2012 21.27, Konrad Rzeszutek Wilk ha scritto:
> >>       GNU GRUB  version 0.97  (640K lower / 3072K upper memory)
> >>
> >>    [ Minimal BASH-like line editing is supported.  For the first word, TAB
> >>      lists possible command completions.  Anywhere else TAB lists the
> >>  possible
> >>      completions of a device/filename.]
> >>  grub>   root (hd0,0)
> >>  root (hd0,0)
> >>    Filesystem type is ext2fs, partition type 0x83
> >>  grub>   kernel /xen.gz
> >>  kernel /xen.gz
> >>      [Multiboot-elf,<0x964000:0x1a6db8:0x54248>(bad)
> >>
> >>  Error 28: Selected item cannot fit into memory
> >>
> >  Wish it said which one..
> >
> >>  [root@xen-02 xen-unstable]# ls -lh /boot/
> >>  totale 247M
> >>  -rw-r--r--. 1 root root 100K 24 ago 03:31 config-2.6.32-279.5.2.el6.x86_64
> >>  -rw-r--r--. 1 root root 100K 22 giu 14:44 config-2.6.32-279.el6.x86_64
> >>  -rw-r--r--. 1 root root 114K  9 set 02:09 config-3.1.0-rc9
> >>  drwxr-xr-x. 3 root root 4,0K  9 set 00:16 efi
> >>  drwxr-xr-x. 2 root root 4,0K  9 set 12:11 grub
> >>  -rw-r--r--. 1 root root  23M  9 set 01:16
> >>  initramfs-2.6.32-279.5.2.el6.x86_64.img
> >>  -rw-r--r--. 1 root root  23M  9 set 00:17
> >>  initramfs-2.6.32-279.el6.x86_64.img
> >>  -rw-r--r--. 1 root root 154M  9 set 02:31 initramfs-3.1.0-rc9.img
> >  This is pretty large? Any reason its so huge compared to the other ones?
> >
> >  And why not use v3.4 instead of v3.1?
> >
> >
> >  _______________________________________________
> >  Xen-devel mailing list
> >  Xen-devel@lists.xen.org
> >  http://lists.xen.org/xen-devel
> >
> hi
>
> i tried 2 different kernel version 3.1.0-rc9+ (jeremy/xen.git) and
> 3.5.0+ (konrad/xen.git): same error in both versions
> (http://wiki.xensource.com/xenwiki/XenParavirtOps)
> i've noticed initramfs is huge, i dont know why, i've just followed the
> xen wiki to compile xenified kernel, no special options:
>
> fresh install
> clone git kernel-xen
> cp config-runningversion .config
> make oldconfig
> enabling all raccomanded xen options in .config (static should be ok)
> make bzImage
> make modules
> make install_modules
> cp bzImage, system.map, .config in /boot dir
> dracut initramfs...
>
> standard procedure end no error compiling kernels.
> same for xen-unstable or xen-4.2.0-rc2 tarball
> (http://wiki.xen.org/wiki/Xen_4.2_Build_From_Source_On_RHEL_CentOS_Fedora)
>
> git clone xe-unstable (or untar)
> .configure (no error, no warning)
> make xen&&  make tools&&  make stubdom
> make install-xen&&  make install-tools&&  make install-stubdom
>
> with different standard linux distributions (fedora 16-grub2, ubuntu
> 12.04-grub2, centos 6.3-grub itself) i can boot and run system.
>
> thanks for quick answer and for help!
>
> regards.


--------------020701050802030109000202
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">
    Il 10/09/2012 22.45, bunkertor ha scritto:
    <blockquote cite="mid:504E5167.20901@tiscali.it" type="cite">
      <meta http-equiv="content-type" content="text/html;
        charset=ISO-8859-1">
      <br>
      <br>
      -------- Messaggio originale --------
      <table class="moz-email-headers-table" border="0" cellpadding="0"
        cellspacing="0">
        <tbody>
          <tr>
            <th align="RIGHT" nowrap="nowrap" valign="BASELINE">Oggetto:
            </th>
            <td>Re: [Xen-devel] grub error 28</td>
          </tr>
          <tr>
            <th align="RIGHT" nowrap="nowrap" valign="BASELINE">Data: </th>
            <td>Mon, 10 Sep 2012 22:30:13 +0200</td>
          </tr>
          <tr>
            <th align="RIGHT" nowrap="nowrap" valign="BASELINE">Mittente:

            </th>
            <td>bunkertor <a moz-do-not-send="true"
                class="moz-txt-link-rfc2396E"
                href="mailto:bunkertor@tiscali.it">&lt;bunkertor@tiscali.it&gt;</a></td>
          </tr>
          <tr>
            <th align="RIGHT" nowrap="nowrap" valign="BASELINE">A: </th>
            <td>Konrad Rzeszutek Wilk <a moz-do-not-send="true"
                class="moz-txt-link-rfc2396E"
                href="mailto:konrad@kernel.org">&lt;konrad@kernel.org&gt;</a></td>
          </tr>
        </tbody>
      </table>
      <br>
      <br>
      <pre>Il 10/09/2012 21.27, Konrad Rzeszutek Wilk ha scritto:
&gt;&gt;      GNU GRUB  version 0.97  (640K lower / 3072K upper memory)
&gt;&gt;
&gt;&gt;   [ Minimal BASH-like line editing is supported.  For the first word, TAB
&gt;&gt;     lists possible command completions.  Anywhere else TAB lists the
&gt;&gt; possible
&gt;&gt;     completions of a device/filename.]
&gt;&gt; grub&gt;  root (hd0,0)
&gt;&gt; root (hd0,0)
&gt;&gt;   Filesystem type is ext2fs, partition type 0x83
&gt;&gt; grub&gt;  kernel /xen.gz
&gt;&gt; kernel /xen.gz
&gt;&gt;     [Multiboot-elf,&lt;0x964000:0x1a6db8:0x54248&gt;(bad)
&gt;&gt;
&gt;&gt; Error 28: Selected item cannot fit into memory
&gt;&gt;
&gt; Wish it said which one..
&gt;
&gt;&gt; [root@xen-02 xen-unstable]# ls -lh /boot/
&gt;&gt; totale 247M
&gt;&gt; -rw-r--r--. 1 root root 100K 24 ago 03:31 config-2.6.32-279.5.2.el6.x86_64
&gt;&gt; -rw-r--r--. 1 root root 100K 22 giu 14:44 config-2.6.32-279.el6.x86_64
&gt;&gt; -rw-r--r--. 1 root root 114K  9 set 02:09 config-3.1.0-rc9
&gt;&gt; drwxr-xr-x. 3 root root 4,0K  9 set 00:16 efi
&gt;&gt; drwxr-xr-x. 2 root root 4,0K  9 set 12:11 grub
&gt;&gt; -rw-r--r--. 1 root root  23M  9 set 01:16
&gt;&gt; initramfs-2.6.32-279.5.2.el6.x86_64.img
&gt;&gt; -rw-r--r--. 1 root root  23M  9 set 00:17
&gt;&gt; initramfs-2.6.32-279.el6.x86_64.img
&gt;&gt; -rw-r--r--. 1 root root 154M  9 set 02:31 initramfs-3.1.0-rc9.img
&gt; This is pretty large? Any reason its so huge compared to the other ones?
&gt;
&gt; And why not use v3.4 instead of v3.1?
&gt;
&gt;
&gt; _______________________________________________
&gt; Xen-devel mailing list
&gt; <a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:Xen-devel@lists.xen.org">Xen-devel@lists.xen.org</a>
&gt; <a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://lists.xen.org/xen-devel">http://lists.xen.org/xen-devel</a>
&gt;
hi

i tried 2 different kernel version 3.1.0-rc9+ (jeremy/xen.git) and 
3.5.0+ (konrad/xen.git): same error in both versions 
(<a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://wiki.xensource.com/xenwiki/XenParavirtOps">http://wiki.xensource.com/xenwiki/XenParavirtOps</a>)
i've noticed initramfs is huge, i dont know why, i've just followed the 
xen wiki to compile xenified kernel, no special options:

fresh install
clone git kernel-xen
cp config-runningversion .config
make oldconfig
enabling all raccomanded xen options in .config (static should be ok)
make bzImage
make modules
make install_modules
cp bzImage, system.map, .config in /boot dir
dracut initramfs...

standard procedure end no error compiling kernels.
same for xen-unstable or xen-4.2.0-rc2 tarball 
(<a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://wiki.xen.org/wiki/Xen_4.2_Build_From_Source_On_RHEL_CentOS_Fedora">http://wiki.xen.org/wiki/Xen_4.2_Build_From_Source_On_RHEL_CentOS_Fedora</a>)

git clone xe-unstable (or untar)
.configure (no error, no warning)
make xen &amp;&amp; make tools &amp;&amp; make stubdom
make install-xen &amp;&amp; make install-tools &amp;&amp; make install-stubdom

with different standard linux distributions (fedora 16-grub2, ubuntu 
12.04-grub2, centos 6.3-grub itself) i can boot and run system.

thanks for quick answer and for help!

regards.
</pre>
    </blockquote>
    <br>
  </body>
</html>

--------------020701050802030109000202--


--===============8619837301402093327==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============8619837301402093327==--


From xen-devel-bounces@lists.xen.org Mon Sep 10 21:07:58 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Sep 2012 21: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 1TBBCl-0000dN-45; Mon, 10 Sep 2012 21:07:39 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <bunkertor@tiscali.it>) id 1TBBCj-0000dE-7g
	for xen-devel@lists.xen.org; Mon, 10 Sep 2012 21:07:37 +0000
X-Env-Sender: bunkertor@tiscali.it
X-Msg-Ref: server-10.tower-27.messagelabs.com!1347311250!5263743!1
X-Originating-IP: [213.205.33.245]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjEzLjIwNS4zMy4yNDUgPT4gMjAzMjU=\n,
	ML_RADAR_SPEW_LINKS_14,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3446 invoked from network); 10 Sep 2012 21:07:30 -0000
Received: from santino.mail.tiscali.it (HELO santino.mail.tiscali.it)
	(213.205.33.245) by server-10.tower-27.messagelabs.com with SMTP;
	10 Sep 2012 21:07:30 -0000
Received: from [172.16.1.180] ([78.13.188.52]) by santino.mail.tiscali.it with 
	id xZ7V1j00718G0wm01Z7Wpw; Mon, 10 Sep 2012 23:07:30 +0200
Message-ID: <504E5691.7020706@tiscali.it>
Date: Mon, 10 Sep 2012 23:07:29 +0200
From: bunkertor <bunkertor@tiscali.it>
User-Agent: Mozilla/5.0 (Windows NT 5.1;
	rv:11.0) Gecko/20120327 Thunderbird/11.0.1
MIME-Version: 1.0
To: xen-devel@lists.xen.org
References: <504E4DD5.8010705@tiscali.it> <504E5167.20901@tiscali.it>
In-Reply-To: <504E5167.20901@tiscali.it>
Subject: Re: [Xen-devel] Fwd: Re:  grub error 28
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============8619837301402093327=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a multi-part message in MIME format.
--===============8619837301402093327==
Content-Type: multipart/alternative;
 boundary="------------020701050802030109000202"

This is a multi-part message in MIME format.
--------------020701050802030109000202
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Il 10/09/2012 22.45, bunkertor ha scritto:
>
>
> -------- Messaggio originale --------
> Oggetto: 	Re: [Xen-devel] grub error 28
> Data: 	Mon, 10 Sep 2012 22:30:13 +0200
> Mittente: 	bunkertor <bunkertor@tiscali.it>
> A: 	Konrad Rzeszutek Wilk <konrad@kernel.org>
>
>
>
> Il 10/09/2012 21.27, Konrad Rzeszutek Wilk ha scritto:
> >>       GNU GRUB  version 0.97  (640K lower / 3072K upper memory)
> >>
> >>    [ Minimal BASH-like line editing is supported.  For the first word, TAB
> >>      lists possible command completions.  Anywhere else TAB lists the
> >>  possible
> >>      completions of a device/filename.]
> >>  grub>   root (hd0,0)
> >>  root (hd0,0)
> >>    Filesystem type is ext2fs, partition type 0x83
> >>  grub>   kernel /xen.gz
> >>  kernel /xen.gz
> >>      [Multiboot-elf,<0x964000:0x1a6db8:0x54248>(bad)
> >>
> >>  Error 28: Selected item cannot fit into memory
> >>
> >  Wish it said which one..
> >
> >>  [root@xen-02 xen-unstable]# ls -lh /boot/
> >>  totale 247M
> >>  -rw-r--r--. 1 root root 100K 24 ago 03:31 config-2.6.32-279.5.2.el6.x86_64
> >>  -rw-r--r--. 1 root root 100K 22 giu 14:44 config-2.6.32-279.el6.x86_64
> >>  -rw-r--r--. 1 root root 114K  9 set 02:09 config-3.1.0-rc9
> >>  drwxr-xr-x. 3 root root 4,0K  9 set 00:16 efi
> >>  drwxr-xr-x. 2 root root 4,0K  9 set 12:11 grub
> >>  -rw-r--r--. 1 root root  23M  9 set 01:16
> >>  initramfs-2.6.32-279.5.2.el6.x86_64.img
> >>  -rw-r--r--. 1 root root  23M  9 set 00:17
> >>  initramfs-2.6.32-279.el6.x86_64.img
> >>  -rw-r--r--. 1 root root 154M  9 set 02:31 initramfs-3.1.0-rc9.img
> >  This is pretty large? Any reason its so huge compared to the other ones?
> >
> >  And why not use v3.4 instead of v3.1?
> >
> >
> >  _______________________________________________
> >  Xen-devel mailing list
> >  Xen-devel@lists.xen.org
> >  http://lists.xen.org/xen-devel
> >
> hi
>
> i tried 2 different kernel version 3.1.0-rc9+ (jeremy/xen.git) and
> 3.5.0+ (konrad/xen.git): same error in both versions
> (http://wiki.xensource.com/xenwiki/XenParavirtOps)
> i've noticed initramfs is huge, i dont know why, i've just followed the
> xen wiki to compile xenified kernel, no special options:
>
> fresh install
> clone git kernel-xen
> cp config-runningversion .config
> make oldconfig
> enabling all raccomanded xen options in .config (static should be ok)
> make bzImage
> make modules
> make install_modules
> cp bzImage, system.map, .config in /boot dir
> dracut initramfs...
>
> standard procedure end no error compiling kernels.
> same for xen-unstable or xen-4.2.0-rc2 tarball
> (http://wiki.xen.org/wiki/Xen_4.2_Build_From_Source_On_RHEL_CentOS_Fedora)
>
> git clone xe-unstable (or untar)
> .configure (no error, no warning)
> make xen&&  make tools&&  make stubdom
> make install-xen&&  make install-tools&&  make install-stubdom
>
> with different standard linux distributions (fedora 16-grub2, ubuntu
> 12.04-grub2, centos 6.3-grub itself) i can boot and run system.
>
> thanks for quick answer and for help!
>
> regards.


--------------020701050802030109000202
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">
    Il 10/09/2012 22.45, bunkertor ha scritto:
    <blockquote cite="mid:504E5167.20901@tiscali.it" type="cite">
      <meta http-equiv="content-type" content="text/html;
        charset=ISO-8859-1">
      <br>
      <br>
      -------- Messaggio originale --------
      <table class="moz-email-headers-table" border="0" cellpadding="0"
        cellspacing="0">
        <tbody>
          <tr>
            <th align="RIGHT" nowrap="nowrap" valign="BASELINE">Oggetto:
            </th>
            <td>Re: [Xen-devel] grub error 28</td>
          </tr>
          <tr>
            <th align="RIGHT" nowrap="nowrap" valign="BASELINE">Data: </th>
            <td>Mon, 10 Sep 2012 22:30:13 +0200</td>
          </tr>
          <tr>
            <th align="RIGHT" nowrap="nowrap" valign="BASELINE">Mittente:

            </th>
            <td>bunkertor <a moz-do-not-send="true"
                class="moz-txt-link-rfc2396E"
                href="mailto:bunkertor@tiscali.it">&lt;bunkertor@tiscali.it&gt;</a></td>
          </tr>
          <tr>
            <th align="RIGHT" nowrap="nowrap" valign="BASELINE">A: </th>
            <td>Konrad Rzeszutek Wilk <a moz-do-not-send="true"
                class="moz-txt-link-rfc2396E"
                href="mailto:konrad@kernel.org">&lt;konrad@kernel.org&gt;</a></td>
          </tr>
        </tbody>
      </table>
      <br>
      <br>
      <pre>Il 10/09/2012 21.27, Konrad Rzeszutek Wilk ha scritto:
&gt;&gt;      GNU GRUB  version 0.97  (640K lower / 3072K upper memory)
&gt;&gt;
&gt;&gt;   [ Minimal BASH-like line editing is supported.  For the first word, TAB
&gt;&gt;     lists possible command completions.  Anywhere else TAB lists the
&gt;&gt; possible
&gt;&gt;     completions of a device/filename.]
&gt;&gt; grub&gt;  root (hd0,0)
&gt;&gt; root (hd0,0)
&gt;&gt;   Filesystem type is ext2fs, partition type 0x83
&gt;&gt; grub&gt;  kernel /xen.gz
&gt;&gt; kernel /xen.gz
&gt;&gt;     [Multiboot-elf,&lt;0x964000:0x1a6db8:0x54248&gt;(bad)
&gt;&gt;
&gt;&gt; Error 28: Selected item cannot fit into memory
&gt;&gt;
&gt; Wish it said which one..
&gt;
&gt;&gt; [root@xen-02 xen-unstable]# ls -lh /boot/
&gt;&gt; totale 247M
&gt;&gt; -rw-r--r--. 1 root root 100K 24 ago 03:31 config-2.6.32-279.5.2.el6.x86_64
&gt;&gt; -rw-r--r--. 1 root root 100K 22 giu 14:44 config-2.6.32-279.el6.x86_64
&gt;&gt; -rw-r--r--. 1 root root 114K  9 set 02:09 config-3.1.0-rc9
&gt;&gt; drwxr-xr-x. 3 root root 4,0K  9 set 00:16 efi
&gt;&gt; drwxr-xr-x. 2 root root 4,0K  9 set 12:11 grub
&gt;&gt; -rw-r--r--. 1 root root  23M  9 set 01:16
&gt;&gt; initramfs-2.6.32-279.5.2.el6.x86_64.img
&gt;&gt; -rw-r--r--. 1 root root  23M  9 set 00:17
&gt;&gt; initramfs-2.6.32-279.el6.x86_64.img
&gt;&gt; -rw-r--r--. 1 root root 154M  9 set 02:31 initramfs-3.1.0-rc9.img
&gt; This is pretty large? Any reason its so huge compared to the other ones?
&gt;
&gt; And why not use v3.4 instead of v3.1?
&gt;
&gt;
&gt; _______________________________________________
&gt; Xen-devel mailing list
&gt; <a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:Xen-devel@lists.xen.org">Xen-devel@lists.xen.org</a>
&gt; <a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://lists.xen.org/xen-devel">http://lists.xen.org/xen-devel</a>
&gt;
hi

i tried 2 different kernel version 3.1.0-rc9+ (jeremy/xen.git) and 
3.5.0+ (konrad/xen.git): same error in both versions 
(<a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://wiki.xensource.com/xenwiki/XenParavirtOps">http://wiki.xensource.com/xenwiki/XenParavirtOps</a>)
i've noticed initramfs is huge, i dont know why, i've just followed the 
xen wiki to compile xenified kernel, no special options:

fresh install
clone git kernel-xen
cp config-runningversion .config
make oldconfig
enabling all raccomanded xen options in .config (static should be ok)
make bzImage
make modules
make install_modules
cp bzImage, system.map, .config in /boot dir
dracut initramfs...

standard procedure end no error compiling kernels.
same for xen-unstable or xen-4.2.0-rc2 tarball 
(<a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://wiki.xen.org/wiki/Xen_4.2_Build_From_Source_On_RHEL_CentOS_Fedora">http://wiki.xen.org/wiki/Xen_4.2_Build_From_Source_On_RHEL_CentOS_Fedora</a>)

git clone xe-unstable (or untar)
.configure (no error, no warning)
make xen &amp;&amp; make tools &amp;&amp; make stubdom
make install-xen &amp;&amp; make install-tools &amp;&amp; make install-stubdom

with different standard linux distributions (fedora 16-grub2, ubuntu 
12.04-grub2, centos 6.3-grub itself) i can boot and run system.

thanks for quick answer and for help!

regards.
</pre>
    </blockquote>
    <br>
  </body>
</html>

--------------020701050802030109000202--


--===============8619837301402093327==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============8619837301402093327==--


From xen-devel-bounces@lists.xen.org Mon Sep 10 21:09:48 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Sep 2012 21:09:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TBBEd-0000mA-MU; Mon, 10 Sep 2012 21:09: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 1TBBEb-0000m3-TT
	for xen-devel@lists.xensource.com; Mon, 10 Sep 2012 21:09:34 +0000
Received: from [85.158.139.83:51683] by server-9.bemta-5.messagelabs.com id
	A8/79-20529-D075E405; Mon, 10 Sep 2012 21:09:33 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1347311372!29520001!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTIyODk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29671 invoked from network); 10 Sep 2012 21:09:32 -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;
	10 Sep 2012 21:09:32 -0000
X-IronPort-AV: E=Sophos;i="4.80,398,1344211200"; d="scan'208";a="14454671"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Sep 2012 21:09: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.279.1; Mon, 10 Sep 2012 22:09:31 +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 1TBBEZ-0008Iz-4M;
	Mon, 10 Sep 2012 21:09:31 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1TBBEY-0001Pl-P3;
	Mon, 10 Sep 2012 22:09:30 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-13669-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Mon, 10 Sep 2012 22:09:30 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.2-testing test] 13669: 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 13669 xen-4.2-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13669/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore            fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-i386-i386-xl-qemuu-winxpsp3  9 guest-localmigrate         fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     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-win        13 guest-stop                   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-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass

version targeted for testing:
 xen                  317c8a48d81f
baseline version:
 xen                  ec23c2a11f6f

------------------------------------------------------------
People who touched revisions under test:
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <Ian.Jackson@eu.citrix.com>
  Keir Fraser <keir@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                                 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                                     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-4.2-testing
+ revision=317c8a48d81f
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push xen-4.2-testing 317c8a48d81f
+ branch=xen-4.2-testing
+ revision=317c8a48d81f
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-4.2-testing
+ '[' xxen = xlinux ']'
+ linuxbranch=linux
+ : master
+ : tested/2.6.39.x
+ . ap-common
++ : xen@xenbits.xensource.com
++ : http://xenbits.xen.org/hg/staging/xen-4.2-testing.hg
++ : git://xenbits.xen.org/staging/qemu-xen-4.2-testing.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : xen@xenbits.xensource.com:git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.xen-4.2-testing
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-4.2-testing.git
++ : daily-cron.xen-4.2-testing
+ TREE_LINUX=xen@xenbits.xensource.com:git/linux-pvops.git
+ TREE_QEMU_UPSTREAM=xen@xenbits.xensource.com:git/qemu-upstream-4.2-testing.git
+ info_linux_tree xen-4.2-testing
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/xen-4.2-testing.hg
+ hg push -r 317c8a48d81f ssh://xen@xenbits.xensource.com/HG/xen-4.2-testing.hg
pushing to ssh://xen@xenbits.xensource.com/HG/xen-4.2-testing.hg
searching for changes
remote: adding changesets
remote: adding manifests
remote: adding file changes
remote: added 10 changesets with 9 changes to 6 files

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 10 21:09:48 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Sep 2012 21:09:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TBBEd-0000mA-MU; Mon, 10 Sep 2012 21:09: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 1TBBEb-0000m3-TT
	for xen-devel@lists.xensource.com; Mon, 10 Sep 2012 21:09:34 +0000
Received: from [85.158.139.83:51683] by server-9.bemta-5.messagelabs.com id
	A8/79-20529-D075E405; Mon, 10 Sep 2012 21:09:33 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1347311372!29520001!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTIyODk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29671 invoked from network); 10 Sep 2012 21:09:32 -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;
	10 Sep 2012 21:09:32 -0000
X-IronPort-AV: E=Sophos;i="4.80,398,1344211200"; d="scan'208";a="14454671"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Sep 2012 21:09: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.279.1; Mon, 10 Sep 2012 22:09:31 +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 1TBBEZ-0008Iz-4M;
	Mon, 10 Sep 2012 21:09:31 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1TBBEY-0001Pl-P3;
	Mon, 10 Sep 2012 22:09:30 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-13669-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Mon, 10 Sep 2012 22:09:30 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.2-testing test] 13669: 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 13669 xen-4.2-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13669/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore            fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-i386-i386-xl-qemuu-winxpsp3  9 guest-localmigrate         fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     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-win        13 guest-stop                   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-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass

version targeted for testing:
 xen                  317c8a48d81f
baseline version:
 xen                  ec23c2a11f6f

------------------------------------------------------------
People who touched revisions under test:
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <Ian.Jackson@eu.citrix.com>
  Keir Fraser <keir@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                                 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                                     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-4.2-testing
+ revision=317c8a48d81f
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push xen-4.2-testing 317c8a48d81f
+ branch=xen-4.2-testing
+ revision=317c8a48d81f
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-4.2-testing
+ '[' xxen = xlinux ']'
+ linuxbranch=linux
+ : master
+ : tested/2.6.39.x
+ . ap-common
++ : xen@xenbits.xensource.com
++ : http://xenbits.xen.org/hg/staging/xen-4.2-testing.hg
++ : git://xenbits.xen.org/staging/qemu-xen-4.2-testing.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : xen@xenbits.xensource.com:git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.xen-4.2-testing
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-4.2-testing.git
++ : daily-cron.xen-4.2-testing
+ TREE_LINUX=xen@xenbits.xensource.com:git/linux-pvops.git
+ TREE_QEMU_UPSTREAM=xen@xenbits.xensource.com:git/qemu-upstream-4.2-testing.git
+ info_linux_tree xen-4.2-testing
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/xen-4.2-testing.hg
+ hg push -r 317c8a48d81f ssh://xen@xenbits.xensource.com/HG/xen-4.2-testing.hg
pushing to ssh://xen@xenbits.xensource.com/HG/xen-4.2-testing.hg
searching for changes
remote: adding changesets
remote: adding manifests
remote: adding file changes
remote: added 10 changesets with 9 changes to 6 files

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 10 21:11:17 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Sep 2012 21:11: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 1TBBG3-0000ua-Hd; Mon, 10 Sep 2012 21:11:03 +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 1TBBG1-0000uO-Px
	for xen-devel@lists.xen.org; Mon, 10 Sep 2012 21:11:02 +0000
Received: from [85.158.143.35:63029] by server-1.bemta-4.messagelabs.com id
	B1/D4-12504-5675E405; Mon, 10 Sep 2012 21:11:01 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-3.tower-21.messagelabs.com!1347311459!14243435!1
X-Originating-IP: [63.239.67.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27585 invoked from network); 10 Sep 2012 21:10:59 -0000
Received: from emvm-gh1-uea09.nsa.gov (HELO nsa.gov) (63.239.67.10)
	by server-3.tower-21.messagelabs.com with SMTP;
	10 Sep 2012 21:10:59 -0000
X-TM-IMSS-Message-ID: <30b13832000f3140@nsa.gov>
Received: from tarius.tycho.ncsc.mil ([144.51.3.1]) by nsa.gov
	([63.239.67.10]) with ESMTP (TREND IMSS SMTP Service 7.1) id
	30b13832000f3140 ; Mon, 10 Sep 2012 17:13:07 -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 q8ALAukq001163; 
	Mon, 10 Sep 2012 17:10:56 -0400
Message-ID: <504E5760.5070605@tycho.nsa.gov>
Date: Mon, 10 Sep 2012 17:10:56 -0400
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Organization: National Security Agency
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120828 Thunderbird/15.0
MIME-Version: 1.0
To: Keir Fraser <keir@xen.org>
References: <CC741177.4B381%keir@xen.org>
In-Reply-To: <CC741177.4B381%keir@xen.org>
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH v2] Merge IS_PRIV checks into XSM hooks
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 09/10/2012 04:51 PM, Keir Fraser wrote:
> On 10/09/2012 20:48, "Daniel De Graaf" <dgdegra@tycho.nsa.gov> wrote:
> 
>> Overall, this series should not change the behavior of Xen when XSM is
>> not enabled; however, in some cases, the exact errors that are returned
>> will be different because security checks have been moved below validity
>> checks. Also, once applied, newly introduced domctls and sysctls will
>> not automatically be guarded by IS_PRIV checks - they will need to add
>> their own permission checking code.
> 
> How do we guard against accidentally forgetting to do this?

The same way you guard against it when adding a new hypercall: when adding
new functionality that needs access checks, also add the access checks.

>> The ARM architecture is not touched at all in these patches. The only
>> obvious breakage that I can see is due to rcu_lock_target_domain_by_id
>> being removed, but XSM hooks will be needed for domctls and sysctls.
> 
> So ARM build is broken? And/or ARM is made insecure because of unchecked
> sysctls/domctls?
> 
>  -- Keir

The ARM build is broken by patch #19 in this series; fixing it is fairly
simple (I'll send a non-compile-tested version as 21/20), or you could
postpone that patch as it's just cleanup.

Since ARM doesn't have any arch-specific domctls or sysctls yet, they are
not insecure. You could also add an IS_PRIV check at the top of ARM's
arch_do_{dom,sys}ctl functions if you don't want to add XSM hooks for each
operation as in x86.

> 
>> The rcu_lock_target_domain_by_id and rcu_lock_remote_target_domain_by_id
>> functions are removed by this series because they act as wrappers around
>> IS_PRIV_FOR; their callers have been changed to use XSM checks instead.
>>
>> Miscellaneous updates to FLASK:
>>     [PATCH 01/20] xsm/flask: remove inherited class attributes
>>     [PATCH 02/20] xsm/flask: remove unneeded create_sid field
>>     [PATCH 03/20] xen: Add versions of rcu_lock_*_domain without IS_PRIV
>>     [PATCH 04/20] xsm/flask: add domain relabel support
>>     [PATCH 05/20] libxl: introduce XSM relabel on build
>>     [PATCH 06/20] flask/policy: Add domain relabel example
>>
>> Preparatory new hooks:
>>     [PATCH 07/20] arch/x86: add distinct XSM hooks for map/unmap
>>     [PATCH 08/20] arch/x86: add missing XSM checks to XENPF_ commands
>>     [PATCH 09/20] xsm/flask: Add checks on the domain performing the
>>
>> Refactoring:
>>     [PATCH 10/20] xsm: Add IS_PRIV checks to dummy XSM module
>>     [PATCH 11/20] xen: use XSM instead of IS_PRIV where duplicated
>>     [PATCH 12/20] xen: avoid calling rcu_lock_*target_domain when an XSM
>>
>> Remaining IS_PRIV calls:
>>     [PATCH 13/20] arch/x86: Add missing domctl and mem_sharing XSM hooks
>>     [PATCH 14/20] tmem: Add access control check
>>     [PATCH 17/20] arch/x86: use XSM hooks for get_pg_owner access checks
>>     [PATCH 18/20] xen: Add XSM hook for XENMEM_exchange
>>
>> Cleanup, FLASK updates to support IS_PRIV emulation:
>>     [PATCH 15/20] xsm: remove unneeded xsm_call macro
>>     [PATCH 16/20] xsm/flask: add distinct SIDs for self/target access
>>     [PATCH 19/20] xen: remove rcu_lock_{remote_,}target_domain_by_id
>>     [PATCH 20/20] flask: add missing operations
>>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 10 21:11:17 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Sep 2012 21:11: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 1TBBG3-0000ua-Hd; Mon, 10 Sep 2012 21:11:03 +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 1TBBG1-0000uO-Px
	for xen-devel@lists.xen.org; Mon, 10 Sep 2012 21:11:02 +0000
Received: from [85.158.143.35:63029] by server-1.bemta-4.messagelabs.com id
	B1/D4-12504-5675E405; Mon, 10 Sep 2012 21:11:01 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-3.tower-21.messagelabs.com!1347311459!14243435!1
X-Originating-IP: [63.239.67.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27585 invoked from network); 10 Sep 2012 21:10:59 -0000
Received: from emvm-gh1-uea09.nsa.gov (HELO nsa.gov) (63.239.67.10)
	by server-3.tower-21.messagelabs.com with SMTP;
	10 Sep 2012 21:10:59 -0000
X-TM-IMSS-Message-ID: <30b13832000f3140@nsa.gov>
Received: from tarius.tycho.ncsc.mil ([144.51.3.1]) by nsa.gov
	([63.239.67.10]) with ESMTP (TREND IMSS SMTP Service 7.1) id
	30b13832000f3140 ; Mon, 10 Sep 2012 17:13:07 -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 q8ALAukq001163; 
	Mon, 10 Sep 2012 17:10:56 -0400
Message-ID: <504E5760.5070605@tycho.nsa.gov>
Date: Mon, 10 Sep 2012 17:10:56 -0400
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Organization: National Security Agency
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120828 Thunderbird/15.0
MIME-Version: 1.0
To: Keir Fraser <keir@xen.org>
References: <CC741177.4B381%keir@xen.org>
In-Reply-To: <CC741177.4B381%keir@xen.org>
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH v2] Merge IS_PRIV checks into XSM hooks
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 09/10/2012 04:51 PM, Keir Fraser wrote:
> On 10/09/2012 20:48, "Daniel De Graaf" <dgdegra@tycho.nsa.gov> wrote:
> 
>> Overall, this series should not change the behavior of Xen when XSM is
>> not enabled; however, in some cases, the exact errors that are returned
>> will be different because security checks have been moved below validity
>> checks. Also, once applied, newly introduced domctls and sysctls will
>> not automatically be guarded by IS_PRIV checks - they will need to add
>> their own permission checking code.
> 
> How do we guard against accidentally forgetting to do this?

The same way you guard against it when adding a new hypercall: when adding
new functionality that needs access checks, also add the access checks.

>> The ARM architecture is not touched at all in these patches. The only
>> obvious breakage that I can see is due to rcu_lock_target_domain_by_id
>> being removed, but XSM hooks will be needed for domctls and sysctls.
> 
> So ARM build is broken? And/or ARM is made insecure because of unchecked
> sysctls/domctls?
> 
>  -- Keir

The ARM build is broken by patch #19 in this series; fixing it is fairly
simple (I'll send a non-compile-tested version as 21/20), or you could
postpone that patch as it's just cleanup.

Since ARM doesn't have any arch-specific domctls or sysctls yet, they are
not insecure. You could also add an IS_PRIV check at the top of ARM's
arch_do_{dom,sys}ctl functions if you don't want to add XSM hooks for each
operation as in x86.

> 
>> The rcu_lock_target_domain_by_id and rcu_lock_remote_target_domain_by_id
>> functions are removed by this series because they act as wrappers around
>> IS_PRIV_FOR; their callers have been changed to use XSM checks instead.
>>
>> Miscellaneous updates to FLASK:
>>     [PATCH 01/20] xsm/flask: remove inherited class attributes
>>     [PATCH 02/20] xsm/flask: remove unneeded create_sid field
>>     [PATCH 03/20] xen: Add versions of rcu_lock_*_domain without IS_PRIV
>>     [PATCH 04/20] xsm/flask: add domain relabel support
>>     [PATCH 05/20] libxl: introduce XSM relabel on build
>>     [PATCH 06/20] flask/policy: Add domain relabel example
>>
>> Preparatory new hooks:
>>     [PATCH 07/20] arch/x86: add distinct XSM hooks for map/unmap
>>     [PATCH 08/20] arch/x86: add missing XSM checks to XENPF_ commands
>>     [PATCH 09/20] xsm/flask: Add checks on the domain performing the
>>
>> Refactoring:
>>     [PATCH 10/20] xsm: Add IS_PRIV checks to dummy XSM module
>>     [PATCH 11/20] xen: use XSM instead of IS_PRIV where duplicated
>>     [PATCH 12/20] xen: avoid calling rcu_lock_*target_domain when an XSM
>>
>> Remaining IS_PRIV calls:
>>     [PATCH 13/20] arch/x86: Add missing domctl and mem_sharing XSM hooks
>>     [PATCH 14/20] tmem: Add access control check
>>     [PATCH 17/20] arch/x86: use XSM hooks for get_pg_owner access checks
>>     [PATCH 18/20] xen: Add XSM hook for XENMEM_exchange
>>
>> Cleanup, FLASK updates to support IS_PRIV emulation:
>>     [PATCH 15/20] xsm: remove unneeded xsm_call macro
>>     [PATCH 16/20] xsm/flask: add distinct SIDs for self/target access
>>     [PATCH 19/20] xen: remove rcu_lock_{remote_,}target_domain_by_id
>>     [PATCH 20/20] flask: add missing operations
>>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 10 21:13:32 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Sep 2012 21:13:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TBBII-0001O3-V4; Mon, 10 Sep 2012 21:13:22 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1TBBIH-0001Nw-9b
	for xen-devel@lists.xen.org; Mon, 10 Sep 2012 21:13:21 +0000
Received: from [85.158.139.83:56144] by server-2.bemta-5.messagelabs.com id
	6B/E5-11456-0F75E405; Mon, 10 Sep 2012 21:13:20 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-9.tower-182.messagelabs.com!1347311598!29016144!1
X-Originating-IP: [63.239.67.9]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21555 invoked from network); 10 Sep 2012 21:13:19 -0000
Received: from emvm-gh1-uea08.nsa.gov (HELO nsa.gov) (63.239.67.9)
	by server-9.tower-182.messagelabs.com with SMTP;
	10 Sep 2012 21:13:19 -0000
X-TM-IMSS-Message-ID: <30b39771000ee042@nsa.gov>
Received: from tarius.tycho.ncsc.mil ([144.51.3.1]) by nsa.gov ([63.239.67.9])
	with ESMTP (TREND IMSS SMTP Service 7.1) id 30b39771000ee042 ;
	Mon, 10 Sep 2012 17:13:10 -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 q8ALDEIr001267; 
	Mon, 10 Sep 2012 17:13:14 -0400
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: Keir Fraser <keir@xen.org>
Date: Mon, 10 Sep 2012 17:13:12 -0400
Message-Id: <1347311592-21734-1-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.11.4
In-Reply-To: <504E5760.5070605@tycho.nsa.gov>
References: <504E5760.5070605@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH 21/20] arch/arm: replace
	rcu_lock_target_domain_by_id with 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

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 xen/arch/arm/hvm.c      | 12 +++++++++---
 xen/arch/arm/mm.c       | 11 +++++++++--
 xen/include/xsm/dummy.h | 29 +++++++++++++++--------------
 xen/include/xsm/xsm.h   | 25 +++++++++++++------------
 4 files changed, 46 insertions(+), 31 deletions(-)

diff --git a/xen/arch/arm/hvm.c b/xen/arch/arm/hvm.c
index c11378d..3cb8eec 100644
--- a/xen/arch/arm/hvm.c
+++ b/xen/arch/arm/hvm.c
@@ -4,6 +4,7 @@
 #include <xen/errno.h>
 #include <xen/guest_access.h>
 #include <xen/sched.h>
+#include <xsm/xsm.h>
 
 #include <public/xen.h>
 #include <public/hvm/params.h>
@@ -30,9 +31,13 @@ long do_hvm_op(unsigned long op, XEN_GUEST_HANDLE(void) arg)
         if ( a.index >= HVM_NR_PARAMS )
             return -EINVAL;
 
-        rc = rcu_lock_target_domain_by_id(a.domid, &d);
-        if ( rc != 0 )
-            return rc;
+        d = rcu_lock_domain_by_any_id(a.domid);
+        if ( d == NULL )
+            return -ESRCH;
+
+        rc = xsm_hvm_param(d, op);
+        if ( rc )
+            goto param_fail;
 
         if ( op == HVMOP_set_param )
         {
@@ -44,6 +49,7 @@ long do_hvm_op(unsigned long op, XEN_GUEST_HANDLE(void) arg)
             rc = copy_to_guest(arg, &a, 1) ? -EFAULT : 0;
         }
 
+ param_fail:
         rcu_unlock_domain(d);
         break;
     }
diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
index 40ac176..ffef978 100644
--- a/xen/arch/arm/mm.c
+++ b/xen/arch/arm/mm.c
@@ -31,6 +31,7 @@
 #include <asm/current.h>
 #include <public/memory.h>
 #include <xen/sched.h>
+#include <xsm/xsm.h>
 
 struct domain *dom_xen, *dom_io;
 
@@ -508,9 +509,15 @@ long arch_memory_op(int op, XEN_GUEST_HANDLE(void) arg)
         if ( copy_from_guest(&xatp, arg, 1) )
             return -EFAULT;
 
-        rc = rcu_lock_target_domain_by_id(xatp.domid, &d);
-        if ( rc != 0 )
+        d = rcu_lock_domain_by_any_id(xatp.domid);
+        if ( d == NULL )
+            return -ESRCH;
+        rc = xsm_add_to_physmap(current->domain, d);
+        if ( rc )
+        {
+            rcu_unlock_domain(d);
             return rc;
+        }
 
         rc = xenmem_add_to_physmap(d, &xatp);
 
diff --git a/xen/include/xsm/dummy.h b/xen/include/xsm/dummy.h
index 16ad33a..d2a8879 100644
--- a/xen/include/xsm/dummy.h
+++ b/xen/include/xsm/dummy.h
@@ -568,6 +568,21 @@ static XSM_DEFAULT(int, pci_config_permission) (struct domain *d, uint32_t machi
     return 0;
 }
 
+static XSM_DEFAULT(int, hvm_param) (struct domain *d, unsigned long op)
+{
+    if ( current->domain != d && !IS_PRIV_FOR(current->domain, d) )
+        return -EPERM;
+    return 0;
+}
+
+static XSM_DEFAULT(int, add_to_physmap) (struct domain *d1, struct domain *d2)
+{
+    if ( d1 != d2 && !IS_PRIV_FOR(d1, d2) )
+        return -EPERM;
+    return 0;
+}
+
+
 #ifdef CONFIG_X86
 static XSM_DEFAULT(int, shadow_control) (struct domain *d, uint32_t op)
 {
@@ -639,13 +654,6 @@ static XSM_DEFAULT(int, machine_address_size) (struct domain *d, uint32_t cmd)
     return 0;
 }
 
-static XSM_DEFAULT(int, hvm_param) (struct domain *d, unsigned long op)
-{
-    if ( current->domain != d && !IS_PRIV_FOR(current->domain, d) )
-        return -EPERM;
-    return 0;
-}
-
 static XSM_DEFAULT(int, hvm_set_pci_intx_level) (struct domain *d)
 {
     if ( !IS_PRIV_FOR(current->domain, d) )
@@ -840,13 +848,6 @@ static XSM_DEFAULT(int, update_va_mapping) (struct domain *d, struct domain *f,
     return 0;
 }
 
-static XSM_DEFAULT(int, add_to_physmap) (struct domain *d1, struct domain *d2)
-{
-    if ( d1 != d2 && !IS_PRIV_FOR(d1, d2) )
-        return -EPERM;
-    return 0;
-}
-
 static XSM_DEFAULT(int, remove_from_physmap) (struct domain *d1, struct domain *d2)
 {
     if ( d1 != d2 && !IS_PRIV_FOR(d1, d2) )
diff --git a/xen/include/xsm/xsm.h b/xen/include/xsm/xsm.h
index 8c11172..d0538b4 100644
--- a/xen/include/xsm/xsm.h
+++ b/xen/include/xsm/xsm.h
@@ -140,6 +140,9 @@ struct xsm_operations {
 
     long (*__do_xsm_op) (XEN_GUEST_HANDLE(xsm_op_t) op);
 
+    int (*hvm_param) (struct domain *d, unsigned long op);
+    int (*add_to_physmap) (struct domain *d1, struct domain *d2);
+
 #ifdef CONFIG_X86
     int (*shadow_control) (struct domain *d, uint32_t op);
     int (*getpageframeinfo) (struct domain *d);
@@ -151,7 +154,6 @@ struct xsm_operations {
     int (*hvmcontext) (struct domain *d, uint32_t op);
     int (*address_size) (struct domain *d, uint32_t op);
     int (*machine_address_size) (struct domain *d, uint32_t op);
-    int (*hvm_param) (struct domain *d, unsigned long op);
     int (*hvm_set_pci_intx_level) (struct domain *d);
     int (*hvm_set_isa_irq_level) (struct domain *d);
     int (*hvm_set_pci_link_route) (struct domain *d);
@@ -180,7 +182,6 @@ struct xsm_operations {
     int (*mmu_machphys_update) (struct domain *d1, struct domain *d2, unsigned long mfn);
     int (*mmuext_op) (struct domain *d, struct domain *f);
     int (*update_va_mapping) (struct domain *d, struct domain *f, l1_pgentry_t pte);
-    int (*add_to_physmap) (struct domain *d1, struct domain *d2);
     int (*sendtrigger) (struct domain *d);
     int (*bind_pt_irq) (struct domain *d, struct xen_domctl_bind_pt_irq *bind);
     int (*unbind_pt_irq) (struct domain *d, struct xen_domctl_bind_pt_irq *bind);
@@ -621,6 +622,16 @@ static inline long xsm___do_xsm_op (XEN_GUEST_HANDLE(xsm_op_t) op)
     return xsm_ops->__do_xsm_op(op);
 }
 
+static inline int xsm_hvm_param (struct domain *d, unsigned long op)
+{
+    return xsm_ops->hvm_param(d, op);
+}
+
+static inline int xsm_add_to_physmap(struct domain *d1, struct domain *d2)
+{
+    return xsm_ops->add_to_physmap(d1, d2);
+}
+
 #ifdef CONFIG_X86
 static inline int xsm_shadow_control (struct domain *d, uint32_t op)
 {
@@ -672,11 +683,6 @@ static inline int xsm_machine_address_size (struct domain *d, uint32_t cmd)
     return xsm_ops->machine_address_size(d, cmd);
 }
 
-static inline int xsm_hvm_param (struct domain *d, unsigned long op)
-{
-    return xsm_ops->hvm_param(d, op);
-}
-
 static inline int xsm_hvm_set_pci_intx_level (struct domain *d)
 {
     return xsm_ops->hvm_set_pci_intx_level(d);
@@ -815,11 +821,6 @@ static inline int xsm_update_va_mapping(struct domain *d, struct domain *f,
     return xsm_ops->update_va_mapping(d, f, pte);
 }
 
-static inline int xsm_add_to_physmap(struct domain *d1, struct domain *d2)
-{
-    return xsm_ops->add_to_physmap(d1, d2);
-}
-
 static inline int xsm_sendtrigger(struct domain *d)
 {
     return xsm_ops->sendtrigger(d);
-- 
1.7.11.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 10 21:13:32 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Sep 2012 21:13:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TBBII-0001O3-V4; Mon, 10 Sep 2012 21:13:22 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1TBBIH-0001Nw-9b
	for xen-devel@lists.xen.org; Mon, 10 Sep 2012 21:13:21 +0000
Received: from [85.158.139.83:56144] by server-2.bemta-5.messagelabs.com id
	6B/E5-11456-0F75E405; Mon, 10 Sep 2012 21:13:20 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-9.tower-182.messagelabs.com!1347311598!29016144!1
X-Originating-IP: [63.239.67.9]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21555 invoked from network); 10 Sep 2012 21:13:19 -0000
Received: from emvm-gh1-uea08.nsa.gov (HELO nsa.gov) (63.239.67.9)
	by server-9.tower-182.messagelabs.com with SMTP;
	10 Sep 2012 21:13:19 -0000
X-TM-IMSS-Message-ID: <30b39771000ee042@nsa.gov>
Received: from tarius.tycho.ncsc.mil ([144.51.3.1]) by nsa.gov ([63.239.67.9])
	with ESMTP (TREND IMSS SMTP Service 7.1) id 30b39771000ee042 ;
	Mon, 10 Sep 2012 17:13:10 -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 q8ALDEIr001267; 
	Mon, 10 Sep 2012 17:13:14 -0400
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: Keir Fraser <keir@xen.org>
Date: Mon, 10 Sep 2012 17:13:12 -0400
Message-Id: <1347311592-21734-1-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.11.4
In-Reply-To: <504E5760.5070605@tycho.nsa.gov>
References: <504E5760.5070605@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH 21/20] arch/arm: replace
	rcu_lock_target_domain_by_id with 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

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 xen/arch/arm/hvm.c      | 12 +++++++++---
 xen/arch/arm/mm.c       | 11 +++++++++--
 xen/include/xsm/dummy.h | 29 +++++++++++++++--------------
 xen/include/xsm/xsm.h   | 25 +++++++++++++------------
 4 files changed, 46 insertions(+), 31 deletions(-)

diff --git a/xen/arch/arm/hvm.c b/xen/arch/arm/hvm.c
index c11378d..3cb8eec 100644
--- a/xen/arch/arm/hvm.c
+++ b/xen/arch/arm/hvm.c
@@ -4,6 +4,7 @@
 #include <xen/errno.h>
 #include <xen/guest_access.h>
 #include <xen/sched.h>
+#include <xsm/xsm.h>
 
 #include <public/xen.h>
 #include <public/hvm/params.h>
@@ -30,9 +31,13 @@ long do_hvm_op(unsigned long op, XEN_GUEST_HANDLE(void) arg)
         if ( a.index >= HVM_NR_PARAMS )
             return -EINVAL;
 
-        rc = rcu_lock_target_domain_by_id(a.domid, &d);
-        if ( rc != 0 )
-            return rc;
+        d = rcu_lock_domain_by_any_id(a.domid);
+        if ( d == NULL )
+            return -ESRCH;
+
+        rc = xsm_hvm_param(d, op);
+        if ( rc )
+            goto param_fail;
 
         if ( op == HVMOP_set_param )
         {
@@ -44,6 +49,7 @@ long do_hvm_op(unsigned long op, XEN_GUEST_HANDLE(void) arg)
             rc = copy_to_guest(arg, &a, 1) ? -EFAULT : 0;
         }
 
+ param_fail:
         rcu_unlock_domain(d);
         break;
     }
diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
index 40ac176..ffef978 100644
--- a/xen/arch/arm/mm.c
+++ b/xen/arch/arm/mm.c
@@ -31,6 +31,7 @@
 #include <asm/current.h>
 #include <public/memory.h>
 #include <xen/sched.h>
+#include <xsm/xsm.h>
 
 struct domain *dom_xen, *dom_io;
 
@@ -508,9 +509,15 @@ long arch_memory_op(int op, XEN_GUEST_HANDLE(void) arg)
         if ( copy_from_guest(&xatp, arg, 1) )
             return -EFAULT;
 
-        rc = rcu_lock_target_domain_by_id(xatp.domid, &d);
-        if ( rc != 0 )
+        d = rcu_lock_domain_by_any_id(xatp.domid);
+        if ( d == NULL )
+            return -ESRCH;
+        rc = xsm_add_to_physmap(current->domain, d);
+        if ( rc )
+        {
+            rcu_unlock_domain(d);
             return rc;
+        }
 
         rc = xenmem_add_to_physmap(d, &xatp);
 
diff --git a/xen/include/xsm/dummy.h b/xen/include/xsm/dummy.h
index 16ad33a..d2a8879 100644
--- a/xen/include/xsm/dummy.h
+++ b/xen/include/xsm/dummy.h
@@ -568,6 +568,21 @@ static XSM_DEFAULT(int, pci_config_permission) (struct domain *d, uint32_t machi
     return 0;
 }
 
+static XSM_DEFAULT(int, hvm_param) (struct domain *d, unsigned long op)
+{
+    if ( current->domain != d && !IS_PRIV_FOR(current->domain, d) )
+        return -EPERM;
+    return 0;
+}
+
+static XSM_DEFAULT(int, add_to_physmap) (struct domain *d1, struct domain *d2)
+{
+    if ( d1 != d2 && !IS_PRIV_FOR(d1, d2) )
+        return -EPERM;
+    return 0;
+}
+
+
 #ifdef CONFIG_X86
 static XSM_DEFAULT(int, shadow_control) (struct domain *d, uint32_t op)
 {
@@ -639,13 +654,6 @@ static XSM_DEFAULT(int, machine_address_size) (struct domain *d, uint32_t cmd)
     return 0;
 }
 
-static XSM_DEFAULT(int, hvm_param) (struct domain *d, unsigned long op)
-{
-    if ( current->domain != d && !IS_PRIV_FOR(current->domain, d) )
-        return -EPERM;
-    return 0;
-}
-
 static XSM_DEFAULT(int, hvm_set_pci_intx_level) (struct domain *d)
 {
     if ( !IS_PRIV_FOR(current->domain, d) )
@@ -840,13 +848,6 @@ static XSM_DEFAULT(int, update_va_mapping) (struct domain *d, struct domain *f,
     return 0;
 }
 
-static XSM_DEFAULT(int, add_to_physmap) (struct domain *d1, struct domain *d2)
-{
-    if ( d1 != d2 && !IS_PRIV_FOR(d1, d2) )
-        return -EPERM;
-    return 0;
-}
-
 static XSM_DEFAULT(int, remove_from_physmap) (struct domain *d1, struct domain *d2)
 {
     if ( d1 != d2 && !IS_PRIV_FOR(d1, d2) )
diff --git a/xen/include/xsm/xsm.h b/xen/include/xsm/xsm.h
index 8c11172..d0538b4 100644
--- a/xen/include/xsm/xsm.h
+++ b/xen/include/xsm/xsm.h
@@ -140,6 +140,9 @@ struct xsm_operations {
 
     long (*__do_xsm_op) (XEN_GUEST_HANDLE(xsm_op_t) op);
 
+    int (*hvm_param) (struct domain *d, unsigned long op);
+    int (*add_to_physmap) (struct domain *d1, struct domain *d2);
+
 #ifdef CONFIG_X86
     int (*shadow_control) (struct domain *d, uint32_t op);
     int (*getpageframeinfo) (struct domain *d);
@@ -151,7 +154,6 @@ struct xsm_operations {
     int (*hvmcontext) (struct domain *d, uint32_t op);
     int (*address_size) (struct domain *d, uint32_t op);
     int (*machine_address_size) (struct domain *d, uint32_t op);
-    int (*hvm_param) (struct domain *d, unsigned long op);
     int (*hvm_set_pci_intx_level) (struct domain *d);
     int (*hvm_set_isa_irq_level) (struct domain *d);
     int (*hvm_set_pci_link_route) (struct domain *d);
@@ -180,7 +182,6 @@ struct xsm_operations {
     int (*mmu_machphys_update) (struct domain *d1, struct domain *d2, unsigned long mfn);
     int (*mmuext_op) (struct domain *d, struct domain *f);
     int (*update_va_mapping) (struct domain *d, struct domain *f, l1_pgentry_t pte);
-    int (*add_to_physmap) (struct domain *d1, struct domain *d2);
     int (*sendtrigger) (struct domain *d);
     int (*bind_pt_irq) (struct domain *d, struct xen_domctl_bind_pt_irq *bind);
     int (*unbind_pt_irq) (struct domain *d, struct xen_domctl_bind_pt_irq *bind);
@@ -621,6 +622,16 @@ static inline long xsm___do_xsm_op (XEN_GUEST_HANDLE(xsm_op_t) op)
     return xsm_ops->__do_xsm_op(op);
 }
 
+static inline int xsm_hvm_param (struct domain *d, unsigned long op)
+{
+    return xsm_ops->hvm_param(d, op);
+}
+
+static inline int xsm_add_to_physmap(struct domain *d1, struct domain *d2)
+{
+    return xsm_ops->add_to_physmap(d1, d2);
+}
+
 #ifdef CONFIG_X86
 static inline int xsm_shadow_control (struct domain *d, uint32_t op)
 {
@@ -672,11 +683,6 @@ static inline int xsm_machine_address_size (struct domain *d, uint32_t cmd)
     return xsm_ops->machine_address_size(d, cmd);
 }
 
-static inline int xsm_hvm_param (struct domain *d, unsigned long op)
-{
-    return xsm_ops->hvm_param(d, op);
-}
-
 static inline int xsm_hvm_set_pci_intx_level (struct domain *d)
 {
     return xsm_ops->hvm_set_pci_intx_level(d);
@@ -815,11 +821,6 @@ static inline int xsm_update_va_mapping(struct domain *d, struct domain *f,
     return xsm_ops->update_va_mapping(d, f, pte);
 }
 
-static inline int xsm_add_to_physmap(struct domain *d1, struct domain *d2)
-{
-    return xsm_ops->add_to_physmap(d1, d2);
-}
-
 static inline int xsm_sendtrigger(struct domain *d)
 {
     return xsm_ops->sendtrigger(d);
-- 
1.7.11.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 10 21:21:41 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Sep 2012 21:21:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TBBQ8-0001cc-Tv; Mon, 10 Sep 2012 21:21:28 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <steve@zentific.com>) id 1TBBQ8-0001cX-A0
	for xen-devel@lists.xen.org; Mon, 10 Sep 2012 21:21:28 +0000
Received: from [85.158.143.35:54563] by server-1.bemta-4.messagelabs.com id
	E5/BA-12504-7D95E405; Mon, 10 Sep 2012 21:21:27 +0000
X-Env-Sender: steve@zentific.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1347312084!5894381!1
X-Originating-IP: [209.85.212.41]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7630 invoked from network); 10 Sep 2012 21:21:26 -0000
Received: from mail-vb0-f41.google.com (HELO mail-vb0-f41.google.com)
	(209.85.212.41)
	by server-4.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Sep 2012 21:21:26 -0000
Received: by vbkv13 with SMTP id v13so2608788vbk.28
	for <xen-devel@lists.xen.org>; Mon, 10 Sep 2012 14:21:24 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to
	:cc:content-type:x-gm-message-state;
	bh=bf+CV7F8zOec9pvvQdZFIVt9MN/fH2ScXh6VpWoagWE=;
	b=I7NVZ5BXKM7quC/adx59X8KSfgvDVdPZpmw6XtJePjPb4zfz07n7vw2qShrnEk528D
	pEZ8Z8/EX0wGSwaMpBOE19Gu0EDbyKBHLCxLbhZHNtWSxfjcIZq9hVV7q8ucshKW41rL
	CLQms7vX3Peu9zX+FboMrKFROCOF2PxO1BXfeJPOLUrUq17IqWY7KgCBUYTyUBJ53XCA
	5JkfJKatLRLhlXd/q+9IziurPLYRpUILiEWP+gQB70+Wr+Xy8vDVQLeGLdFOBHopV3yB
	EYlRRF5mkpaAvXVSDAsx4lK4h+/1bZiWgVQ3IYIhcIUWsu9zvHpw3U7LJWFyTKwaq2Pd
	0HWA==
Received: by 10.58.227.106 with SMTP id rz10mr24051048vec.19.1347312084220;
	Mon, 10 Sep 2012 14:21:24 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.220.25.76 with HTTP; Mon, 10 Sep 2012 14:20:43 -0700 (PDT)
In-Reply-To: <4d31c1c8641846fa42fa.1347310995@steve-xen>
References: <4d31c1c8641846fa42fa.1347310995@steve-xen>
From: Steven Maresca <steve@zentific.com>
Date: Mon, 10 Sep 2012 17:20:43 -0400
Message-ID: <CANSvah6PU5SOKd19qfbvTXvz4spcPYVUQHmiirmm5hPvmzR+pg@mail.gmail.com>
To: xen-devel@lists.xen.org
X-Gm-Message-State: ALoCoQkhTACpBu8M3WcFlzqFrs0XFItm3DY/8y5fE3r4JvCryi6U+mpJllgKhfCQvQ/S5xbcNHdL
Cc: aravindh@virtuata.com, andres@lagarcavilla.org
Subject: Re: [Xen-devel] [PATCH] mem_event: fix regression affecting CR3,
	CR4 memory events
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Sep 10, 2012 at 5:03 PM, Steven Maresca <steve@zentific.com> wrote:
> This is a patch repairing a regression in code previously functional in 4.1.x. It appears that, during some refactoring work, calls to hvm_memory_event_cr3 and hvm_memory_event_cr4 were lost.
>
> These functions were originally called in mov_to_cr() of vmx.c, but the commit  http://xenbits.xen.org/hg/xen-unstable.hg/rev/1276926e3795 abstracted the original code into generic functions up a level in hvm.c, dropping these calls in the process.
>
> Signed-off-by: Steven Maresca <steve@zentific.com>
>
> diff -r a64f4e107951 -r 4d31c1c86418 xen/arch/x86/hvm/hvm.c
> --- a/xen/arch/x86/hvm/hvm.c    Fri Sep 07 11:09:46 2012 +0100
> +++ b/xen/arch/x86/hvm/hvm.c    Mon Sep 10 16:48:15 2012 -0400
> @@ -1758,6 +1758,7 @@ int hvm_set_cr3(unsigned long value)
>  {
>      struct vcpu *v = current;
>      struct page_info *page;
> +    unsigned long old;
>
>      if ( hvm_paging_enabled(v) && !paging_mode_hap(v->domain) &&
>           (value != v->arch.hvm_vcpu.guest_cr[3]) )
> @@ -1775,8 +1776,10 @@ int hvm_set_cr3(unsigned long value)
>          HVM_DBG_LOG(DBG_LEVEL_VMMU, "Update CR3 value = %lx", value);
>      }
>
> +    old=v->arch.hvm_vcpu.guest_cr[3];
>      v->arch.hvm_vcpu.guest_cr[3] = value;
>      paging_update_cr3(v);
> +    hvm_memory_event_cr3(value, old);
>      return X86EMUL_OKAY;
>
>   bad_cr3:
> @@ -1818,6 +1821,7 @@ int hvm_set_cr4(unsigned long value)
>
>      v->arch.hvm_vcpu.guest_cr[4] = value;
>      hvm_update_guest_cr(v, 4);
> +    hvm_memory_event_cr4(value, old_cr);
>
>      /*
>       * Modifying CR4.{PSE,PAE,PGE,SMEP}, or clearing CR4.PCIDE

Given the refactoring in the commit related to the regression
http://xenbits.xen.org/hg/xen-unstable.hg/rev/1276926e3795, it seemed
(to me anyway) that inserting calls as shown in the patch would be
cleaner, but I can definitely come up with some drawbacks.  However, I
wanted to get this fixed for 4.2 if at all possible, so I wanted to
send regardless.

In terms of drawbacks, this will require some ifdefs for x86_64, for example.

Any suggestions for the cleanest means of achieving the same in vmx.c?

Steve

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 10 21:21:41 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Sep 2012 21:21:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TBBQ8-0001cc-Tv; Mon, 10 Sep 2012 21:21:28 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <steve@zentific.com>) id 1TBBQ8-0001cX-A0
	for xen-devel@lists.xen.org; Mon, 10 Sep 2012 21:21:28 +0000
Received: from [85.158.143.35:54563] by server-1.bemta-4.messagelabs.com id
	E5/BA-12504-7D95E405; Mon, 10 Sep 2012 21:21:27 +0000
X-Env-Sender: steve@zentific.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1347312084!5894381!1
X-Originating-IP: [209.85.212.41]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7630 invoked from network); 10 Sep 2012 21:21:26 -0000
Received: from mail-vb0-f41.google.com (HELO mail-vb0-f41.google.com)
	(209.85.212.41)
	by server-4.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Sep 2012 21:21:26 -0000
Received: by vbkv13 with SMTP id v13so2608788vbk.28
	for <xen-devel@lists.xen.org>; Mon, 10 Sep 2012 14:21:24 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to
	:cc:content-type:x-gm-message-state;
	bh=bf+CV7F8zOec9pvvQdZFIVt9MN/fH2ScXh6VpWoagWE=;
	b=I7NVZ5BXKM7quC/adx59X8KSfgvDVdPZpmw6XtJePjPb4zfz07n7vw2qShrnEk528D
	pEZ8Z8/EX0wGSwaMpBOE19Gu0EDbyKBHLCxLbhZHNtWSxfjcIZq9hVV7q8ucshKW41rL
	CLQms7vX3Peu9zX+FboMrKFROCOF2PxO1BXfeJPOLUrUq17IqWY7KgCBUYTyUBJ53XCA
	5JkfJKatLRLhlXd/q+9IziurPLYRpUILiEWP+gQB70+Wr+Xy8vDVQLeGLdFOBHopV3yB
	EYlRRF5mkpaAvXVSDAsx4lK4h+/1bZiWgVQ3IYIhcIUWsu9zvHpw3U7LJWFyTKwaq2Pd
	0HWA==
Received: by 10.58.227.106 with SMTP id rz10mr24051048vec.19.1347312084220;
	Mon, 10 Sep 2012 14:21:24 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.220.25.76 with HTTP; Mon, 10 Sep 2012 14:20:43 -0700 (PDT)
In-Reply-To: <4d31c1c8641846fa42fa.1347310995@steve-xen>
References: <4d31c1c8641846fa42fa.1347310995@steve-xen>
From: Steven Maresca <steve@zentific.com>
Date: Mon, 10 Sep 2012 17:20:43 -0400
Message-ID: <CANSvah6PU5SOKd19qfbvTXvz4spcPYVUQHmiirmm5hPvmzR+pg@mail.gmail.com>
To: xen-devel@lists.xen.org
X-Gm-Message-State: ALoCoQkhTACpBu8M3WcFlzqFrs0XFItm3DY/8y5fE3r4JvCryi6U+mpJllgKhfCQvQ/S5xbcNHdL
Cc: aravindh@virtuata.com, andres@lagarcavilla.org
Subject: Re: [Xen-devel] [PATCH] mem_event: fix regression affecting CR3,
	CR4 memory events
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Sep 10, 2012 at 5:03 PM, Steven Maresca <steve@zentific.com> wrote:
> This is a patch repairing a regression in code previously functional in 4.1.x. It appears that, during some refactoring work, calls to hvm_memory_event_cr3 and hvm_memory_event_cr4 were lost.
>
> These functions were originally called in mov_to_cr() of vmx.c, but the commit  http://xenbits.xen.org/hg/xen-unstable.hg/rev/1276926e3795 abstracted the original code into generic functions up a level in hvm.c, dropping these calls in the process.
>
> Signed-off-by: Steven Maresca <steve@zentific.com>
>
> diff -r a64f4e107951 -r 4d31c1c86418 xen/arch/x86/hvm/hvm.c
> --- a/xen/arch/x86/hvm/hvm.c    Fri Sep 07 11:09:46 2012 +0100
> +++ b/xen/arch/x86/hvm/hvm.c    Mon Sep 10 16:48:15 2012 -0400
> @@ -1758,6 +1758,7 @@ int hvm_set_cr3(unsigned long value)
>  {
>      struct vcpu *v = current;
>      struct page_info *page;
> +    unsigned long old;
>
>      if ( hvm_paging_enabled(v) && !paging_mode_hap(v->domain) &&
>           (value != v->arch.hvm_vcpu.guest_cr[3]) )
> @@ -1775,8 +1776,10 @@ int hvm_set_cr3(unsigned long value)
>          HVM_DBG_LOG(DBG_LEVEL_VMMU, "Update CR3 value = %lx", value);
>      }
>
> +    old=v->arch.hvm_vcpu.guest_cr[3];
>      v->arch.hvm_vcpu.guest_cr[3] = value;
>      paging_update_cr3(v);
> +    hvm_memory_event_cr3(value, old);
>      return X86EMUL_OKAY;
>
>   bad_cr3:
> @@ -1818,6 +1821,7 @@ int hvm_set_cr4(unsigned long value)
>
>      v->arch.hvm_vcpu.guest_cr[4] = value;
>      hvm_update_guest_cr(v, 4);
> +    hvm_memory_event_cr4(value, old_cr);
>
>      /*
>       * Modifying CR4.{PSE,PAE,PGE,SMEP}, or clearing CR4.PCIDE

Given the refactoring in the commit related to the regression
http://xenbits.xen.org/hg/xen-unstable.hg/rev/1276926e3795, it seemed
(to me anyway) that inserting calls as shown in the patch would be
cleaner, but I can definitely come up with some drawbacks.  However, I
wanted to get this fixed for 4.2 if at all possible, so I wanted to
send regardless.

In terms of drawbacks, this will require some ifdefs for x86_64, for example.

Any suggestions for the cleanest means of achieving the same in vmx.c?

Steve

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 10 21:35:55 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Sep 2012 21:35:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TBBds-0001sZ-UA; Mon, 10 Sep 2012 21:35:40 +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 1TBBdq-0001sD-Ok
	for xen-devel@lists.xen.org; Mon, 10 Sep 2012 21:35:38 +0000
Received: from [85.158.143.35:31767] by server-2.bemta-4.messagelabs.com id
	68/AF-21239-A2D5E405; Mon, 10 Sep 2012 21:35:38 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1347312937!6551505!1
X-Originating-IP: [74.125.82.51]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32248 invoked from network); 10 Sep 2012 21:35:37 -0000
Received: from mail-wg0-f51.google.com (HELO mail-wg0-f51.google.com)
	(74.125.82.51)
	by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Sep 2012 21:35:37 -0000
Received: by wgbed3 with SMTP id ed3so1637913wgb.32
	for <xen-devel@lists.xen.org>; Mon, 10 Sep 2012 14:35:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=GCiZ6pwxgM63glborf/Wx5oaVhXWCDMB+rHQWxWq+oY=;
	b=Z/j7et5Bb24LV6Te3g9qypbLAnwae79XtjwLVVGbPj06LuzUv6dzUStRoCJ51TZsEI
	fyKhD91aKlGscfdgWvJ/xOOOvcpFHqZNb5hL9gY/S86sG+sHGoGzn7z4dlyM7Jmnh5AG
	d1tkexW58xfRB6A/kKTy1IfcylDClk0CTiWAgzuNSA+hVqQagDWYpfZ1XwLtkjG7YXta
	r78a5t+EQFAbdPzC94s4+B8TxS0Kl09dcBgMLm+NFNebmLw5KLY7QdM+3txQtTPrwp1/
	yoWTLSL1bo5IBzVA+pQewWpYere0mQyiPT9pCZQPuK12lkA7VtU+Y0Rq7wcxJX2E5jgE
	XiAQ==
Received: by 10.216.236.163 with SMTP id w35mr8714237weq.13.1347312936694;
	Mon, 10 Sep 2012 14:35:36 -0700 (PDT)
Received: from [192.168.1.3] (host86-184-74-117.range86-184.btcentralplus.com.
	[86.184.74.117])
	by mx.google.com with ESMTPS id do5sm552816wib.10.2012.09.10.14.35.34
	(version=SSLv3 cipher=OTHER); Mon, 10 Sep 2012 14:35:35 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.33.0.120411
Date: Mon, 10 Sep 2012 22:35:25 +0100
From: Keir Fraser <keir@xen.org>
To: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Message-ID: <CC741BAD.4B395%keir@xen.org>
Thread-Topic: [Xen-devel] [PATCH v2] Merge IS_PRIV checks into XSM hooks
Thread-Index: Ac2PnDA0iAKmMQZhpESNG5GZYGa+LA==
In-Reply-To: <504E5760.5070605@tycho.nsa.gov>
Mime-version: 1.0
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH v2] Merge IS_PRIV checks into XSM hooks
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/09/2012 22:10, "Daniel De Graaf" <dgdegra@tycho.nsa.gov> wrote:

> On 09/10/2012 04:51 PM, Keir Fraser wrote:
>> On 10/09/2012 20:48, "Daniel De Graaf" <dgdegra@tycho.nsa.gov> wrote:
>> 
>>> Overall, this series should not change the behavior of Xen when XSM is
>>> not enabled; however, in some cases, the exact errors that are returned
>>> will be different because security checks have been moved below validity
>>> checks. Also, once applied, newly introduced domctls and sysctls will
>>> not automatically be guarded by IS_PRIV checks - they will need to add
>>> their own permission checking code.
>> 
>> How do we guard against accidentally forgetting to do this?
> 
> The same way you guard against it when adding a new hypercall: when adding
> new functionality that needs access checks, also add the access checks.

So... We just shouldn't accidentally forget. That will work well. ;)
Historically XSM has not been top of many committers' checklists.

 -- Keir

>>> The ARM architecture is not touched at all in these patches. The only
>>> obvious breakage that I can see is due to rcu_lock_target_domain_by_id
>>> being removed, but XSM hooks will be needed for domctls and sysctls.
>> 
>> So ARM build is broken? And/or ARM is made insecure because of unchecked
>> sysctls/domctls?
>> 
>>  -- Keir
> 
> The ARM build is broken by patch #19 in this series; fixing it is fairly
> simple (I'll send a non-compile-tested version as 21/20), or you could
> postpone that patch as it's just cleanup.
> 
> Since ARM doesn't have any arch-specific domctls or sysctls yet, they are
> not insecure. You could also add an IS_PRIV check at the top of ARM's
> arch_do_{dom,sys}ctl functions if you don't want to add XSM hooks for each
> operation as in x86.
> 
>> 
>>> The rcu_lock_target_domain_by_id and rcu_lock_remote_target_domain_by_id
>>> functions are removed by this series because they act as wrappers around
>>> IS_PRIV_FOR; their callers have been changed to use XSM checks instead.
>>> 
>>> Miscellaneous updates to FLASK:
>>>     [PATCH 01/20] xsm/flask: remove inherited class attributes
>>>     [PATCH 02/20] xsm/flask: remove unneeded create_sid field
>>>     [PATCH 03/20] xen: Add versions of rcu_lock_*_domain without IS_PRIV
>>>     [PATCH 04/20] xsm/flask: add domain relabel support
>>>     [PATCH 05/20] libxl: introduce XSM relabel on build
>>>     [PATCH 06/20] flask/policy: Add domain relabel example
>>> 
>>> Preparatory new hooks:
>>>     [PATCH 07/20] arch/x86: add distinct XSM hooks for map/unmap
>>>     [PATCH 08/20] arch/x86: add missing XSM checks to XENPF_ commands
>>>     [PATCH 09/20] xsm/flask: Add checks on the domain performing the
>>> 
>>> Refactoring:
>>>     [PATCH 10/20] xsm: Add IS_PRIV checks to dummy XSM module
>>>     [PATCH 11/20] xen: use XSM instead of IS_PRIV where duplicated
>>>     [PATCH 12/20] xen: avoid calling rcu_lock_*target_domain when an XSM
>>> 
>>> Remaining IS_PRIV calls:
>>>     [PATCH 13/20] arch/x86: Add missing domctl and mem_sharing XSM hooks
>>>     [PATCH 14/20] tmem: Add access control check
>>>     [PATCH 17/20] arch/x86: use XSM hooks for get_pg_owner access checks
>>>     [PATCH 18/20] xen: Add XSM hook for XENMEM_exchange
>>> 
>>> Cleanup, FLASK updates to support IS_PRIV emulation:
>>>     [PATCH 15/20] xsm: remove unneeded xsm_call macro
>>>     [PATCH 16/20] xsm/flask: add distinct SIDs for self/target access
>>>     [PATCH 19/20] xen: remove rcu_lock_{remote_,}target_domain_by_id
>>>     [PATCH 20/20] flask: add missing operations
>>> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 10 21:35:55 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Sep 2012 21:35:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TBBds-0001sZ-UA; Mon, 10 Sep 2012 21:35:40 +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 1TBBdq-0001sD-Ok
	for xen-devel@lists.xen.org; Mon, 10 Sep 2012 21:35:38 +0000
Received: from [85.158.143.35:31767] by server-2.bemta-4.messagelabs.com id
	68/AF-21239-A2D5E405; Mon, 10 Sep 2012 21:35:38 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1347312937!6551505!1
X-Originating-IP: [74.125.82.51]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32248 invoked from network); 10 Sep 2012 21:35:37 -0000
Received: from mail-wg0-f51.google.com (HELO mail-wg0-f51.google.com)
	(74.125.82.51)
	by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Sep 2012 21:35:37 -0000
Received: by wgbed3 with SMTP id ed3so1637913wgb.32
	for <xen-devel@lists.xen.org>; Mon, 10 Sep 2012 14:35:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=GCiZ6pwxgM63glborf/Wx5oaVhXWCDMB+rHQWxWq+oY=;
	b=Z/j7et5Bb24LV6Te3g9qypbLAnwae79XtjwLVVGbPj06LuzUv6dzUStRoCJ51TZsEI
	fyKhD91aKlGscfdgWvJ/xOOOvcpFHqZNb5hL9gY/S86sG+sHGoGzn7z4dlyM7Jmnh5AG
	d1tkexW58xfRB6A/kKTy1IfcylDClk0CTiWAgzuNSA+hVqQagDWYpfZ1XwLtkjG7YXta
	r78a5t+EQFAbdPzC94s4+B8TxS0Kl09dcBgMLm+NFNebmLw5KLY7QdM+3txQtTPrwp1/
	yoWTLSL1bo5IBzVA+pQewWpYere0mQyiPT9pCZQPuK12lkA7VtU+Y0Rq7wcxJX2E5jgE
	XiAQ==
Received: by 10.216.236.163 with SMTP id w35mr8714237weq.13.1347312936694;
	Mon, 10 Sep 2012 14:35:36 -0700 (PDT)
Received: from [192.168.1.3] (host86-184-74-117.range86-184.btcentralplus.com.
	[86.184.74.117])
	by mx.google.com with ESMTPS id do5sm552816wib.10.2012.09.10.14.35.34
	(version=SSLv3 cipher=OTHER); Mon, 10 Sep 2012 14:35:35 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.33.0.120411
Date: Mon, 10 Sep 2012 22:35:25 +0100
From: Keir Fraser <keir@xen.org>
To: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Message-ID: <CC741BAD.4B395%keir@xen.org>
Thread-Topic: [Xen-devel] [PATCH v2] Merge IS_PRIV checks into XSM hooks
Thread-Index: Ac2PnDA0iAKmMQZhpESNG5GZYGa+LA==
In-Reply-To: <504E5760.5070605@tycho.nsa.gov>
Mime-version: 1.0
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH v2] Merge IS_PRIV checks into XSM hooks
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/09/2012 22:10, "Daniel De Graaf" <dgdegra@tycho.nsa.gov> wrote:

> On 09/10/2012 04:51 PM, Keir Fraser wrote:
>> On 10/09/2012 20:48, "Daniel De Graaf" <dgdegra@tycho.nsa.gov> wrote:
>> 
>>> Overall, this series should not change the behavior of Xen when XSM is
>>> not enabled; however, in some cases, the exact errors that are returned
>>> will be different because security checks have been moved below validity
>>> checks. Also, once applied, newly introduced domctls and sysctls will
>>> not automatically be guarded by IS_PRIV checks - they will need to add
>>> their own permission checking code.
>> 
>> How do we guard against accidentally forgetting to do this?
> 
> The same way you guard against it when adding a new hypercall: when adding
> new functionality that needs access checks, also add the access checks.

So... We just shouldn't accidentally forget. That will work well. ;)
Historically XSM has not been top of many committers' checklists.

 -- Keir

>>> The ARM architecture is not touched at all in these patches. The only
>>> obvious breakage that I can see is due to rcu_lock_target_domain_by_id
>>> being removed, but XSM hooks will be needed for domctls and sysctls.
>> 
>> So ARM build is broken? And/or ARM is made insecure because of unchecked
>> sysctls/domctls?
>> 
>>  -- Keir
> 
> The ARM build is broken by patch #19 in this series; fixing it is fairly
> simple (I'll send a non-compile-tested version as 21/20), or you could
> postpone that patch as it's just cleanup.
> 
> Since ARM doesn't have any arch-specific domctls or sysctls yet, they are
> not insecure. You could also add an IS_PRIV check at the top of ARM's
> arch_do_{dom,sys}ctl functions if you don't want to add XSM hooks for each
> operation as in x86.
> 
>> 
>>> The rcu_lock_target_domain_by_id and rcu_lock_remote_target_domain_by_id
>>> functions are removed by this series because they act as wrappers around
>>> IS_PRIV_FOR; their callers have been changed to use XSM checks instead.
>>> 
>>> Miscellaneous updates to FLASK:
>>>     [PATCH 01/20] xsm/flask: remove inherited class attributes
>>>     [PATCH 02/20] xsm/flask: remove unneeded create_sid field
>>>     [PATCH 03/20] xen: Add versions of rcu_lock_*_domain without IS_PRIV
>>>     [PATCH 04/20] xsm/flask: add domain relabel support
>>>     [PATCH 05/20] libxl: introduce XSM relabel on build
>>>     [PATCH 06/20] flask/policy: Add domain relabel example
>>> 
>>> Preparatory new hooks:
>>>     [PATCH 07/20] arch/x86: add distinct XSM hooks for map/unmap
>>>     [PATCH 08/20] arch/x86: add missing XSM checks to XENPF_ commands
>>>     [PATCH 09/20] xsm/flask: Add checks on the domain performing the
>>> 
>>> Refactoring:
>>>     [PATCH 10/20] xsm: Add IS_PRIV checks to dummy XSM module
>>>     [PATCH 11/20] xen: use XSM instead of IS_PRIV where duplicated
>>>     [PATCH 12/20] xen: avoid calling rcu_lock_*target_domain when an XSM
>>> 
>>> Remaining IS_PRIV calls:
>>>     [PATCH 13/20] arch/x86: Add missing domctl and mem_sharing XSM hooks
>>>     [PATCH 14/20] tmem: Add access control check
>>>     [PATCH 17/20] arch/x86: use XSM hooks for get_pg_owner access checks
>>>     [PATCH 18/20] xen: Add XSM hook for XENMEM_exchange
>>> 
>>> Cleanup, FLASK updates to support IS_PRIV emulation:
>>>     [PATCH 15/20] xsm: remove unneeded xsm_call macro
>>>     [PATCH 16/20] xsm/flask: add distinct SIDs for self/target access
>>>     [PATCH 19/20] xen: remove rcu_lock_{remote_,}target_domain_by_id
>>>     [PATCH 20/20] flask: add missing operations
>>> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 10 21:39:38 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Sep 2012 21:39:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TBBhV-0002Ch-II; Mon, 10 Sep 2012 21:39:25 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1TBBhU-0002CL-7J
	for xen-devel@lists.xen.org; Mon, 10 Sep 2012 21:39:24 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1347313157!9631826!1
X-Originating-IP: [74.125.82.51]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23862 invoked from network); 10 Sep 2012 21:39:17 -0000
Received: from mail-wg0-f51.google.com (HELO mail-wg0-f51.google.com)
	(74.125.82.51)
	by server-3.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Sep 2012 21:39:17 -0000
Received: by wgbed3 with SMTP id ed3so1639953wgb.32
	for <xen-devel@lists.xen.org>; Mon, 10 Sep 2012 14:39: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=qpapETCcsHOCZi7wiTQK122imSJ2PaXHQWClSbAN+ks=;
	b=gs76qyC3MnuIxfKi8dQpAbh+dz459+OZ0pFNYv7nTog5wCFZlTNhWwtB8uYMjjIral
	ytOruBY03FvRenyXasNYLjehmpMpzGIw0Bw8cYAzWhGyf2GU0kIYDSH9jUiGR8xfYUvv
	KpDNPsCygFZSlzJ/q2M0AwWvvDDTnDj0C40v8TiiW/f16C0MjkBVRGoifRYElB4k6/3x
	yjGxgNFRmuS8oVk1M/E838lqmGGbXjQvtg81QHDbh4cJov885jAp2yl2JoYOf8j83xv2
	ZzuoRERBqRuAJjmwdAFrE0WOwfP0AkZXH1sFoqiGFKRzyYdSCewCzWWXeJkkCT9F9Z7P
	NaQA==
Received: by 10.180.74.133 with SMTP id t5mr19914655wiv.2.1347313157071;
	Mon, 10 Sep 2012 14:39:17 -0700 (PDT)
Received: from [192.168.1.3] (host86-184-74-117.range86-184.btcentralplus.com.
	[86.184.74.117])
	by mx.google.com with ESMTPS id b7sm582502wiz.9.2012.09.10.14.39.14
	(version=SSLv3 cipher=OTHER); Mon, 10 Sep 2012 14:39:16 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.33.0.120411
Date: Mon, 10 Sep 2012 22:39:09 +0100
From: Keir Fraser <keir@xen.org>
To: Steven Maresca <steve@zentific.com>,
	<xen-devel@lists.xen.org>
Message-ID: <CC741C8D.4B3AF%keir@xen.org>
Thread-Topic: [Xen-devel] [PATCH] mem_event: fix regression affecting CR3, CR4
	memory events
Thread-Index: Ac2PnLW3rPc3rU3L+kKMX5RSeWG2Bg==
In-Reply-To: <CANSvah6PU5SOKd19qfbvTXvz4spcPYVUQHmiirmm5hPvmzR+pg@mail.gmail.com>
Mime-version: 1.0
Cc: Aravindh Puthiyaparambil <aravindh@virtuata.com>, andres@lagarcavilla.org
Subject: Re: [Xen-devel] [PATCH] mem_event: fix regression affecting CR3,
 CR4 memory events
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 10/09/2012 22:20, "Steven Maresca" <steve@zentific.com> wrote:

> Given the refactoring in the commit related to the regression
> http://xenbits.xen.org/hg/xen-unstable.hg/rev/1276926e3795, it seemed
> (to me anyway) that inserting calls as shown in the patch would be
> cleaner, but I can definitely come up with some drawbacks.  However, I
> wanted to get this fixed for 4.2 if at all possible, so I wanted to
> send regardless.
> 
> In terms of drawbacks, this will require some ifdefs for x86_64, for example.
> 
> Any suggestions for the cleanest means of achieving the same in vmx.c?

I don't understand this at all. The original commit moved some CR handling
to common HVM code. Your patch adds some mem_event calls into that common
HVM code. What would need to be "achieved" in vmx.c? What ifdefs would be
required for x86_64?

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 10 21:39:38 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Sep 2012 21:39:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TBBhV-0002Ch-II; Mon, 10 Sep 2012 21:39:25 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1TBBhU-0002CL-7J
	for xen-devel@lists.xen.org; Mon, 10 Sep 2012 21:39:24 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1347313157!9631826!1
X-Originating-IP: [74.125.82.51]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23862 invoked from network); 10 Sep 2012 21:39:17 -0000
Received: from mail-wg0-f51.google.com (HELO mail-wg0-f51.google.com)
	(74.125.82.51)
	by server-3.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Sep 2012 21:39:17 -0000
Received: by wgbed3 with SMTP id ed3so1639953wgb.32
	for <xen-devel@lists.xen.org>; Mon, 10 Sep 2012 14:39: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=qpapETCcsHOCZi7wiTQK122imSJ2PaXHQWClSbAN+ks=;
	b=gs76qyC3MnuIxfKi8dQpAbh+dz459+OZ0pFNYv7nTog5wCFZlTNhWwtB8uYMjjIral
	ytOruBY03FvRenyXasNYLjehmpMpzGIw0Bw8cYAzWhGyf2GU0kIYDSH9jUiGR8xfYUvv
	KpDNPsCygFZSlzJ/q2M0AwWvvDDTnDj0C40v8TiiW/f16C0MjkBVRGoifRYElB4k6/3x
	yjGxgNFRmuS8oVk1M/E838lqmGGbXjQvtg81QHDbh4cJov885jAp2yl2JoYOf8j83xv2
	ZzuoRERBqRuAJjmwdAFrE0WOwfP0AkZXH1sFoqiGFKRzyYdSCewCzWWXeJkkCT9F9Z7P
	NaQA==
Received: by 10.180.74.133 with SMTP id t5mr19914655wiv.2.1347313157071;
	Mon, 10 Sep 2012 14:39:17 -0700 (PDT)
Received: from [192.168.1.3] (host86-184-74-117.range86-184.btcentralplus.com.
	[86.184.74.117])
	by mx.google.com with ESMTPS id b7sm582502wiz.9.2012.09.10.14.39.14
	(version=SSLv3 cipher=OTHER); Mon, 10 Sep 2012 14:39:16 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.33.0.120411
Date: Mon, 10 Sep 2012 22:39:09 +0100
From: Keir Fraser <keir@xen.org>
To: Steven Maresca <steve@zentific.com>,
	<xen-devel@lists.xen.org>
Message-ID: <CC741C8D.4B3AF%keir@xen.org>
Thread-Topic: [Xen-devel] [PATCH] mem_event: fix regression affecting CR3, CR4
	memory events
Thread-Index: Ac2PnLW3rPc3rU3L+kKMX5RSeWG2Bg==
In-Reply-To: <CANSvah6PU5SOKd19qfbvTXvz4spcPYVUQHmiirmm5hPvmzR+pg@mail.gmail.com>
Mime-version: 1.0
Cc: Aravindh Puthiyaparambil <aravindh@virtuata.com>, andres@lagarcavilla.org
Subject: Re: [Xen-devel] [PATCH] mem_event: fix regression affecting CR3,
 CR4 memory events
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 10/09/2012 22:20, "Steven Maresca" <steve@zentific.com> wrote:

> Given the refactoring in the commit related to the regression
> http://xenbits.xen.org/hg/xen-unstable.hg/rev/1276926e3795, it seemed
> (to me anyway) that inserting calls as shown in the patch would be
> cleaner, but I can definitely come up with some drawbacks.  However, I
> wanted to get this fixed for 4.2 if at all possible, so I wanted to
> send regardless.
> 
> In terms of drawbacks, this will require some ifdefs for x86_64, for example.
> 
> Any suggestions for the cleanest means of achieving the same in vmx.c?

I don't understand this at all. The original commit moved some CR handling
to common HVM code. Your patch adds some mem_event calls into that common
HVM code. What would need to be "achieved" in vmx.c? What ifdefs would be
required for x86_64?

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 10 22:07:19 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Sep 2012 22: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 1TBC8E-0002jD-Kc; Mon, 10 Sep 2012 22:07:02 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <steve@zentific.com>) id 1TBC8C-0002j8-Mb
	for xen-devel@lists.xen.org; Mon, 10 Sep 2012 22:07:00 +0000
X-Env-Sender: steve@zentific.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1347314806!2760190!1
X-Originating-IP: [209.85.220.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4688 invoked from network); 10 Sep 2012 22:06:51 -0000
Received: from mail-vc0-f173.google.com (HELO mail-vc0-f173.google.com)
	(209.85.220.173)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Sep 2012 22:06:51 -0000
Received: by vcbfl15 with SMTP id fl15so1032472vcb.32
	for <xen-devel@lists.xen.org>; Mon, 10 Sep 2012 15:06:45 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to
	:cc:content-type:x-gm-message-state;
	bh=E12/CLzLQlbeJd6K9eGd9xtgrsCkEzR5NTbvRgq9we0=;
	b=jtKkt9r1eTw3pBi3tgKq65y7xqn1zfpn40I7cW4gmz8TfHsR/U42FpS6UVmrMMiBjJ
	lK/3psD4P6Q93ypiGbqRC/mz0R5Hfsasut0aY1OIgP058RtoIWqp3bLfoLudKTO4jNal
	gDjqFS+5U01bW+r46HJPjiGy5awNPGk/Ivd967D+cuPvCh0c9R4odE5hAhG6am/05wI+
	eP54iXrczWZmL+AZZQv7EKoV5CGrTHVv66nWQW1GUKn6GPd955fiHCDX/nd+USY0YrbT
	D4Eb+LJpFSaBnW3ZuVxFu59vtn1TXbQLcibnAZ55r+LqMzguHikzUw8mBoZ8NTTFSOhu
	W9vw==
Received: by 10.58.227.106 with SMTP id rz10mr24256376vec.19.1347314805755;
	Mon, 10 Sep 2012 15:06:45 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.220.25.76 with HTTP; Mon, 10 Sep 2012 15:06:05 -0700 (PDT)
In-Reply-To: <CC741C8D.4B3AF%keir@xen.org>
References: <CANSvah6PU5SOKd19qfbvTXvz4spcPYVUQHmiirmm5hPvmzR+pg@mail.gmail.com>
	<CC741C8D.4B3AF%keir@xen.org>
From: Steven Maresca <steve@zentific.com>
Date: Mon, 10 Sep 2012 18:06:05 -0400
Message-ID: <CANSvah6nWfKP9-PLSkhbFcO2ONmfj5Hhs-+3r0MhjOUHU1qNfg@mail.gmail.com>
To: Keir Fraser <keir@xen.org>
X-Gm-Message-State: ALoCoQnWRbvyiksC/BobCjUD7TI0vO6sexp0oOfUi4GsFviSl0kn3KS5IiZ6wc+x/YPS3aMxNOr7
Cc: Aravindh Puthiyaparambil <aravindh@virtuata.com>, andres@lagarcavilla.org,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] mem_event: fix regression affecting CR3,
 CR4 memory events
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Sep 10, 2012 at 5:39 PM, Keir Fraser <keir@xen.org> wrote:
> On 10/09/2012 22:20, "Steven Maresca" <steve@zentific.com> wrote:
>
>> Given the refactoring in the commit related to the regression
>> http://xenbits.xen.org/hg/xen-unstable.hg/rev/1276926e3795, it seemed
>> (to me anyway) that inserting calls as shown in the patch would be
>> cleaner, but I can definitely come up with some drawbacks.  However, I
>> wanted to get this fixed for 4.2 if at all possible, so I wanted to
>> send regardless.
>>
>> In terms of drawbacks, this will require some ifdefs for x86_64, for example.
>>
>> Any suggestions for the cleanest means of achieving the same in vmx.c?
>
> I don't understand this at all. The original commit moved some CR handling
> to common HVM code. Your patch adds some mem_event calls into that common
> HVM code. What would need to be "achieved" in vmx.c? What ifdefs would be
> required for x86_64?
>
>  -- Keir
>
>

Keir,

In the process of moving CR handling to common code, that commit
removed calls to hvm_memory_event_cr3() and hvm_memory_event_cr4().
Without some patch restoring the calls to those two functions, current
xen-unstable and xen-4.2-testing only reference them as function
prototypes and function definitions -- there are no calls whatsoever.

I only mentioned an ifdef relative to x86_64 because of the #ifdef
__x86_64__  around the function definitions. ( I know in the hvm.h
itself they're just empty inline functions if not __x86_64__. )

Regarding vmx.c: hvm_memory_event_cr0 is called within vmx_cr_access.
The patch I sent restoring the calls to hvm_memory_event_cr4 and
hvm_memory_event_cr3 could be treated similarly, that's all.

Steve

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 10 22:07:19 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Sep 2012 22: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 1TBC8E-0002jD-Kc; Mon, 10 Sep 2012 22:07:02 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <steve@zentific.com>) id 1TBC8C-0002j8-Mb
	for xen-devel@lists.xen.org; Mon, 10 Sep 2012 22:07:00 +0000
X-Env-Sender: steve@zentific.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1347314806!2760190!1
X-Originating-IP: [209.85.220.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4688 invoked from network); 10 Sep 2012 22:06:51 -0000
Received: from mail-vc0-f173.google.com (HELO mail-vc0-f173.google.com)
	(209.85.220.173)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Sep 2012 22:06:51 -0000
Received: by vcbfl15 with SMTP id fl15so1032472vcb.32
	for <xen-devel@lists.xen.org>; Mon, 10 Sep 2012 15:06:45 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to
	:cc:content-type:x-gm-message-state;
	bh=E12/CLzLQlbeJd6K9eGd9xtgrsCkEzR5NTbvRgq9we0=;
	b=jtKkt9r1eTw3pBi3tgKq65y7xqn1zfpn40I7cW4gmz8TfHsR/U42FpS6UVmrMMiBjJ
	lK/3psD4P6Q93ypiGbqRC/mz0R5Hfsasut0aY1OIgP058RtoIWqp3bLfoLudKTO4jNal
	gDjqFS+5U01bW+r46HJPjiGy5awNPGk/Ivd967D+cuPvCh0c9R4odE5hAhG6am/05wI+
	eP54iXrczWZmL+AZZQv7EKoV5CGrTHVv66nWQW1GUKn6GPd955fiHCDX/nd+USY0YrbT
	D4Eb+LJpFSaBnW3ZuVxFu59vtn1TXbQLcibnAZ55r+LqMzguHikzUw8mBoZ8NTTFSOhu
	W9vw==
Received: by 10.58.227.106 with SMTP id rz10mr24256376vec.19.1347314805755;
	Mon, 10 Sep 2012 15:06:45 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.220.25.76 with HTTP; Mon, 10 Sep 2012 15:06:05 -0700 (PDT)
In-Reply-To: <CC741C8D.4B3AF%keir@xen.org>
References: <CANSvah6PU5SOKd19qfbvTXvz4spcPYVUQHmiirmm5hPvmzR+pg@mail.gmail.com>
	<CC741C8D.4B3AF%keir@xen.org>
From: Steven Maresca <steve@zentific.com>
Date: Mon, 10 Sep 2012 18:06:05 -0400
Message-ID: <CANSvah6nWfKP9-PLSkhbFcO2ONmfj5Hhs-+3r0MhjOUHU1qNfg@mail.gmail.com>
To: Keir Fraser <keir@xen.org>
X-Gm-Message-State: ALoCoQnWRbvyiksC/BobCjUD7TI0vO6sexp0oOfUi4GsFviSl0kn3KS5IiZ6wc+x/YPS3aMxNOr7
Cc: Aravindh Puthiyaparambil <aravindh@virtuata.com>, andres@lagarcavilla.org,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] mem_event: fix regression affecting CR3,
 CR4 memory events
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Sep 10, 2012 at 5:39 PM, Keir Fraser <keir@xen.org> wrote:
> On 10/09/2012 22:20, "Steven Maresca" <steve@zentific.com> wrote:
>
>> Given the refactoring in the commit related to the regression
>> http://xenbits.xen.org/hg/xen-unstable.hg/rev/1276926e3795, it seemed
>> (to me anyway) that inserting calls as shown in the patch would be
>> cleaner, but I can definitely come up with some drawbacks.  However, I
>> wanted to get this fixed for 4.2 if at all possible, so I wanted to
>> send regardless.
>>
>> In terms of drawbacks, this will require some ifdefs for x86_64, for example.
>>
>> Any suggestions for the cleanest means of achieving the same in vmx.c?
>
> I don't understand this at all. The original commit moved some CR handling
> to common HVM code. Your patch adds some mem_event calls into that common
> HVM code. What would need to be "achieved" in vmx.c? What ifdefs would be
> required for x86_64?
>
>  -- Keir
>
>

Keir,

In the process of moving CR handling to common code, that commit
removed calls to hvm_memory_event_cr3() and hvm_memory_event_cr4().
Without some patch restoring the calls to those two functions, current
xen-unstable and xen-4.2-testing only reference them as function
prototypes and function definitions -- there are no calls whatsoever.

I only mentioned an ifdef relative to x86_64 because of the #ifdef
__x86_64__  around the function definitions. ( I know in the hvm.h
itself they're just empty inline functions if not __x86_64__. )

Regarding vmx.c: hvm_memory_event_cr0 is called within vmx_cr_access.
The patch I sent restoring the calls to hvm_memory_event_cr4 and
hvm_memory_event_cr3 could be treated similarly, that's all.

Steve

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 10 22:37:24 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Sep 2012 22:37: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 1TBCbE-00033x-E2; Mon, 10 Sep 2012 22:37: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 1TBCbC-00033s-QA
	for xen-devel@lists.xen.org; Mon, 10 Sep 2012 22:36:59 +0000
Received: from [85.158.143.35:47933] by server-2.bemta-4.messagelabs.com id
	27/B9-21239-98B6E405; Mon, 10 Sep 2012 22:36:57 +0000
X-Env-Sender: msw@amazon.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1347316615!11783765!1
X-Originating-IP: [207.171.178.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA3LjE3MS4xNzguMjUgPT4gNjU0NTA=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17081 invoked from network); 10 Sep 2012 22:36:57 -0000
Received: from smtp-fw-31001.amazon.com (HELO smtp-fw-31001.amazon.com)
	(207.171.178.25)
	by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Sep 2012 22:36:57 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=amazon.com; i=msw@amazon.com; q=dns/txt; s=rte02;
	t=1347316617; x=1378852617;
	h=date:from:to:cc:subject:message-id:references:
	mime-version:in-reply-to;
	bh=aYre9vuP5hoh96FTEVPLh4XDa/0bYnhT3vqFO7m422Q=;
	b=Itp2D0K6Iv/ONHFahvQzLXPJKP/AHZcDWMwxKypS7APPCdbeyc/0+M4M
	hbPplKUl4Fckg7leNoAVPyL5XOD4hg==;
X-IronPort-AV: E=Sophos;i="4.80,400,1344211200"; d="scan'208";a="292639195"
Received: from smtp-in-1105.vdc.amazon.com ([10.140.9.24])
	by smtp-border-fw-out-31001.sea31.amazon.com with
	ESMTP/TLS/DHE-RSA-AES256-SHA; 10 Sep 2012 22:36:53 +0000
Received: from ex10-hub-9001.ant.amazon.com (ex10-hub-9001.ant.amazon.com
	[10.185.137.58])
	by smtp-in-1105.vdc.amazon.com (8.13.8/8.13.8) with ESMTP id
	q8AMaqpW018288
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL);
	Mon, 10 Sep 2012 22:36:52 GMT
Received: from u002268147cd4502c336d.ant.amazon.com (10.224.80.34) by
	ex10-hub-9001.ant.amazon.com (10.185.137.58) with Microsoft SMTP Server
	id 14.2.247.3; Mon, 10 Sep 2012 15:36:45 -0700
Received: by u002268147cd4502c336d.ant.amazon.com (sSMTP sendmail emulation); 
	Mon, 10 Sep 2012 15:36:45 -0700
Date: Mon, 10 Sep 2012 15:36:45 -0700
From: Matt Wilson <msw@amazon.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Message-ID: <20120910223644.GC22357@u002268147cd4502c336d.ant.amazon.com>
References: <1347018043-21252-1-git-send-email-stefan.bader@canonical.com>
	<504A05B00200007800099C7B@nat28.tlf.novell.com>
	<5049F4E9.9050306@canonical.com>
	<504A1A950200007800099D4C@nat28.tlf.novell.com>
	<20120907142251.GA20096@linuxtx.org>
	<20120907145433.GA5378@phenom.dumpdata.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120907145433.GA5378@phenom.dumpdata.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	"Justin M. Forbes" <jmforbes@linuxtx.org>,
	Stefan Bader <stefan.bader@canonical.com>,
	Jan Beulich <JBeulich@suse.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH/RFC] Fix xsave bug on older Xen hypervisors
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Sep 07, 2012 at 10:54:33AM -0400, Konrad Rzeszutek Wilk wrote:
> 
> Sure. Jan is asking though for actual confirmation that the upstream kernel
> does indeed go belly up without a workaround.
> And whether this patch (which I would did since Canonical is carrying it) does
> fix the issue.
> 
> I am still a newbie on the Amazon EC2 upload your kernel thing (hint, would
> appreciate somebody taking this patch and trying it out).

For what it's worth, that's super easy these days. All modern Linux
AMIs on EC2 should be using PV-GRUB. Just adjust the GRUB 0.97
configuration file in /boot/grub/menu.lst to point at your new kernel.

I have seen some OEL AMIs that, for some reason, have a partition
table and /boot on a separate partition. This means that the
configuration file is in /boot/boot/grub/menu.lst.

Matt

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 10 22:37:24 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 10 Sep 2012 22:37: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 1TBCbE-00033x-E2; Mon, 10 Sep 2012 22:37: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 1TBCbC-00033s-QA
	for xen-devel@lists.xen.org; Mon, 10 Sep 2012 22:36:59 +0000
Received: from [85.158.143.35:47933] by server-2.bemta-4.messagelabs.com id
	27/B9-21239-98B6E405; Mon, 10 Sep 2012 22:36:57 +0000
X-Env-Sender: msw@amazon.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1347316615!11783765!1
X-Originating-IP: [207.171.178.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA3LjE3MS4xNzguMjUgPT4gNjU0NTA=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17081 invoked from network); 10 Sep 2012 22:36:57 -0000
Received: from smtp-fw-31001.amazon.com (HELO smtp-fw-31001.amazon.com)
	(207.171.178.25)
	by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Sep 2012 22:36:57 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=amazon.com; i=msw@amazon.com; q=dns/txt; s=rte02;
	t=1347316617; x=1378852617;
	h=date:from:to:cc:subject:message-id:references:
	mime-version:in-reply-to;
	bh=aYre9vuP5hoh96FTEVPLh4XDa/0bYnhT3vqFO7m422Q=;
	b=Itp2D0K6Iv/ONHFahvQzLXPJKP/AHZcDWMwxKypS7APPCdbeyc/0+M4M
	hbPplKUl4Fckg7leNoAVPyL5XOD4hg==;
X-IronPort-AV: E=Sophos;i="4.80,400,1344211200"; d="scan'208";a="292639195"
Received: from smtp-in-1105.vdc.amazon.com ([10.140.9.24])
	by smtp-border-fw-out-31001.sea31.amazon.com with
	ESMTP/TLS/DHE-RSA-AES256-SHA; 10 Sep 2012 22:36:53 +0000
Received: from ex10-hub-9001.ant.amazon.com (ex10-hub-9001.ant.amazon.com
	[10.185.137.58])
	by smtp-in-1105.vdc.amazon.com (8.13.8/8.13.8) with ESMTP id
	q8AMaqpW018288
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL);
	Mon, 10 Sep 2012 22:36:52 GMT
Received: from u002268147cd4502c336d.ant.amazon.com (10.224.80.34) by
	ex10-hub-9001.ant.amazon.com (10.185.137.58) with Microsoft SMTP Server
	id 14.2.247.3; Mon, 10 Sep 2012 15:36:45 -0700
Received: by u002268147cd4502c336d.ant.amazon.com (sSMTP sendmail emulation); 
	Mon, 10 Sep 2012 15:36:45 -0700
Date: Mon, 10 Sep 2012 15:36:45 -0700
From: Matt Wilson <msw@amazon.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Message-ID: <20120910223644.GC22357@u002268147cd4502c336d.ant.amazon.com>
References: <1347018043-21252-1-git-send-email-stefan.bader@canonical.com>
	<504A05B00200007800099C7B@nat28.tlf.novell.com>
	<5049F4E9.9050306@canonical.com>
	<504A1A950200007800099D4C@nat28.tlf.novell.com>
	<20120907142251.GA20096@linuxtx.org>
	<20120907145433.GA5378@phenom.dumpdata.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120907145433.GA5378@phenom.dumpdata.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	"Justin M. Forbes" <jmforbes@linuxtx.org>,
	Stefan Bader <stefan.bader@canonical.com>,
	Jan Beulich <JBeulich@suse.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH/RFC] Fix xsave bug on older Xen hypervisors
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Sep 07, 2012 at 10:54:33AM -0400, Konrad Rzeszutek Wilk wrote:
> 
> Sure. Jan is asking though for actual confirmation that the upstream kernel
> does indeed go belly up without a workaround.
> And whether this patch (which I would did since Canonical is carrying it) does
> fix the issue.
> 
> I am still a newbie on the Amazon EC2 upload your kernel thing (hint, would
> appreciate somebody taking this patch and trying it out).

For what it's worth, that's super easy these days. All modern Linux
AMIs on EC2 should be using PV-GRUB. Just adjust the GRUB 0.97
configuration file in /boot/grub/menu.lst to point at your new kernel.

I have seen some OEL AMIs that, for some reason, have a partition
table and /boot on a separate partition. This means that the
configuration file is in /boot/boot/grub/menu.lst.

Matt

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 11 00:19:53 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 2012 00: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 1TBECC-00041m-4q; Tue, 11 Sep 2012 00:19:16 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <john.stultz@linaro.org>) id 1TBEC9-00041e-Qy
	for xen-devel@lists.xensource.com; Tue, 11 Sep 2012 00:19:14 +0000
X-Env-Sender: john.stultz@linaro.org
X-Msg-Ref: server-14.tower-27.messagelabs.com!1347322746!3447101!1
X-Originating-IP: [32.97.182.145]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMzIuOTcuMTgyLjE0NSA9PiA1MjE3OTI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14829 invoked from network); 11 Sep 2012 00:19:07 -0000
Received: from e5.ny.us.ibm.com (HELO e5.ny.us.ibm.com) (32.97.182.145)
	by server-14.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 11 Sep 2012 00:19:07 -0000
Received: from /spool/local
	by e5.ny.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only!
	Violators will be prosecuted
	for <xen-devel@lists.xensource.com> from <john.stultz@linaro.org>;
	Mon, 10 Sep 2012 20:19:06 -0400
Received: from d01dlp02.pok.ibm.com (9.56.250.167)
	by e5.ny.us.ibm.com (192.168.1.105) with IBM ESMTP SMTP Gateway:
	Authorized Use Only! Violators will be prosecuted; 
	Mon, 10 Sep 2012 20:19:04 -0400
Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236])
	by d01dlp02.pok.ibm.com (Postfix) with ESMTP id 5EA0E6E803F
	for <xen-devel@lists.xensource.com>;
	Mon, 10 Sep 2012 20:19:03 -0400 (EDT)
Received: from d01av03.pok.ibm.com (d01av03.pok.ibm.com [9.56.224.217])
	by d01relay04.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id
	q8B0J3NJ166600
	for <xen-devel@lists.xensource.com>; Mon, 10 Sep 2012 20:19:03 -0400
Received: from d01av03.pok.ibm.com (loopback [127.0.0.1])
	by d01av03.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id
	q8B0J2BP030754
	for <xen-devel@lists.xensource.com>; Mon, 10 Sep 2012 21:19:03 -0300
Received: from [9.65.242.108] (sig-9-65-242-108.mts.ibm.com [9.65.242.108])
	by d01av03.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id
	q8B0IwBX030699; Mon, 10 Sep 2012 21:18:59 -0300
Message-ID: <504E8372.20904@linaro.org>
Date: Mon, 10 Sep 2012 17:18:58 -0700
From: John Stultz <john.stultz@linaro.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120827 Thunderbird/15.0
MIME-Version: 1.0
To: Daniel Lezcano <daniel.lezcano@linaro.org>
References: <1343164349-28550-1-git-send-email-daniel.lezcano@linaro.org>
	<201209062204.11288.rjw@sisk.pl> <50490920.9070204@linaro.org>
	<201209062318.42874.rjw@sisk.pl> <504A02BD.4000805@linaro.org>
	<504A2D73.3010702@linaro.org> <504A68A0.7010907@linaro.org>
	<504E1FE5.6090502@linaro.org> <504E4343.5070004@linaro.org>
In-Reply-To: <504E4343.5070004@linaro.org>
X-Content-Scanned: Fidelis XPS MAILER
x-cbid: 12091100-5930-0000-0000-00000BE45A2C
Cc: prarit@redhat.com, xen-devel@lists.xensource.com,
	linaro-dev@lists.linaro.org, Peter Zijlstra <a.p.zijlstra@chello.nl>,
	linux-pm@vger.kernel.org, Frederic Weisbecker <fweisbec@gmail.com>,
	richardcochran@gmail.com, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	"Rafael J. Wysocki" <rjw@sisk.pl>, linux-acpi@vger.kernel.org,
	Thomas Gleixner <tglx@linutronix.de>, mingo@kernel.org, lenb@kernel.org
Subject: Re: [Xen-devel] CONFIG_NO_HZ + CONFIG_CPU_IDLE freeze the system
 (Was Re: [PATCH] acpi : remove power from acpi_processor_cx structure)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 09/10/2012 12:45 PM, Daniel Lezcano wrote:
> On 09/10/2012 07:14 PM, John Stultz wrote:
>> In the meantime, I'll try to reproduce on my T61. If you could send me
>> your .config, I'd appreciate it.
> http://pastebin.com/qSxqfdDK
>
> The header of the config file shows for a v3.5-rc7 because it is the
> result of the git-bisect. If you keep this config file for the latest
> kernel that should reproduce the problem.
>
> Let me know if you were able to reproduce the problem.
Great! With this I was able to quickly reproduce the problem and I think 
I have a fix.

Would you mind testing the following patch? It seems to resolve the 
issue, but I've not yet run it through my test suite to make sure it 
didn't break anything else.

If both your and my testing comes back ok, I'll submit it to Thomas.

thanks
-john

 From f10a285a5b532a14d3330f6e60e4d7bd5627932a Mon Sep 17 00:00:00 2001
From: John Stultz <john.stultz@linaro.org>
Date: Mon, 10 Sep 2012 20:00:15 -0400
Subject: [PATCH] time: Fix timeekeping_get_ns overflow on 32bit systems

Daniel Lezcano reported seeing multi-second stalls from
keyboard input on his T61 laptop when NOHZ and CPU_IDLE
were enabled on a 32bit kernel.

He bisected the problem down to
1e75fa8be9fb61e1af46b5b3b176347a4c958ca1 (time: Condense
timekeeper.xtime into xtime_sec).

After reproducing this issue, I narrowed the problem down
to the fact that timekeeping_get_ns() returns a 64bit
nsec value that hasn't been accumulated. In some cases
this value was being then stored in timespec.tv_nsec
(which is a long).

On 32bit systems, With idle times larger then 4 seconds
(or less, depending on the value of xtime_nsec), the
returned nsec value would overflow 32bits. This limited
kept time from increasing, causing timers to not expire.

The fix is to make sure we don't directly store the
result of timekeeping_get_ns() into a tv_nsec field,
instead using a 64bit nsec value which can then be
added into the timespec via timespec_add_ns().

With this patch I cannot reproduce the issue.

Cc: Ingo Molnar <mingo@kernel.org>
Cc: Richard Cochran <richardcochran@gmail.com>
Cc: Prarit Bhargava <prarit@redhat.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Daniel Lezcano <daniel.lezcano@linaro.org>
Reported-and-bisected-by: Daniel Lezcano <daniel.lezcano@linaro.org>
Signed-off-by: John Stultz <john.stultz@linaro.org>
---
  kernel/time/timekeeping.c |   19 ++++++++++++-------
  1 file changed, 12 insertions(+), 7 deletions(-)

diff --git a/kernel/time/timekeeping.c b/kernel/time/timekeeping.c
index 34e5eac..d3b91e7 100644
--- a/kernel/time/timekeeping.c
+++ b/kernel/time/timekeeping.c
@@ -303,10 +303,11 @@ void getnstimeofday(struct timespec *ts)
  		seq = read_seqbegin(&tk->lock);
  
  		ts->tv_sec = tk->xtime_sec;
-		ts->tv_nsec = timekeeping_get_ns(tk);
+		nsecs = timekeeping_get_ns(tk);
  
  	} while (read_seqretry(&tk->lock, seq));
  
+	ts->tv_nsec = 0;
  	timespec_add_ns(ts, nsecs);
  }
  EXPORT_SYMBOL(getnstimeofday);
@@ -345,6 +346,7 @@ void ktime_get_ts(struct timespec *ts)
  {
  	struct timekeeper *tk = &timekeeper;
  	struct timespec tomono;
+	s64 nsec;
  	unsigned int seq;
  
  	WARN_ON(timekeeping_suspended);
@@ -352,13 +354,14 @@ void ktime_get_ts(struct timespec *ts)
  	do {
  		seq = read_seqbegin(&tk->lock);
  		ts->tv_sec = tk->xtime_sec;
-		ts->tv_nsec = timekeeping_get_ns(tk);
+		nsec = timekeeping_get_ns(tk);
  		tomono = tk->wall_to_monotonic;
  
  	} while (read_seqretry(&tk->lock, seq));
  
-	set_normalized_timespec(ts, ts->tv_sec + tomono.tv_sec,
-				ts->tv_nsec + tomono.tv_nsec);
+	ts->tv_sec += tomono.tv_sec;
+	ts->tv_nsec = 0;
+	timespec_add_ns(ts, nsec + tomono.tv_nsec);
  }
  EXPORT_SYMBOL_GPL(ktime_get_ts);
  
@@ -1244,6 +1247,7 @@ void get_monotonic_boottime(struct timespec *ts)
  {
  	struct timekeeper *tk = &timekeeper;
  	struct timespec tomono, sleep;
+	s64 nsec;
  	unsigned int seq;
  
  	WARN_ON(timekeeping_suspended);
@@ -1251,14 +1255,15 @@ void get_monotonic_boottime(struct timespec *ts)
  	do {
  		seq = read_seqbegin(&tk->lock);
  		ts->tv_sec = tk->xtime_sec;
-		ts->tv_nsec = timekeeping_get_ns(tk);
+		nsec = timekeeping_get_ns(tk);
  		tomono = tk->wall_to_monotonic;
  		sleep = tk->total_sleep_time;
  
  	} while (read_seqretry(&tk->lock, seq));
  
-	set_normalized_timespec(ts, ts->tv_sec + tomono.tv_sec + sleep.tv_sec,
-			ts->tv_nsec + tomono.tv_nsec + sleep.tv_nsec);
+	ts->tv_sec += tomono.tv_sec + sleep.tv_sec;
+	ts->tv_nsec = 0;
+	timespec_add_ns(ts, nsec + tomono.tv_nsec + sleep.tv_nsec);
  }
  EXPORT_SYMBOL_GPL(get_monotonic_boottime);
  
-- 
1.7.9.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 11 00:19:53 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 2012 00: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 1TBECC-00041m-4q; Tue, 11 Sep 2012 00:19:16 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <john.stultz@linaro.org>) id 1TBEC9-00041e-Qy
	for xen-devel@lists.xensource.com; Tue, 11 Sep 2012 00:19:14 +0000
X-Env-Sender: john.stultz@linaro.org
X-Msg-Ref: server-14.tower-27.messagelabs.com!1347322746!3447101!1
X-Originating-IP: [32.97.182.145]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMzIuOTcuMTgyLjE0NSA9PiA1MjE3OTI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14829 invoked from network); 11 Sep 2012 00:19:07 -0000
Received: from e5.ny.us.ibm.com (HELO e5.ny.us.ibm.com) (32.97.182.145)
	by server-14.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 11 Sep 2012 00:19:07 -0000
Received: from /spool/local
	by e5.ny.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only!
	Violators will be prosecuted
	for <xen-devel@lists.xensource.com> from <john.stultz@linaro.org>;
	Mon, 10 Sep 2012 20:19:06 -0400
Received: from d01dlp02.pok.ibm.com (9.56.250.167)
	by e5.ny.us.ibm.com (192.168.1.105) with IBM ESMTP SMTP Gateway:
	Authorized Use Only! Violators will be prosecuted; 
	Mon, 10 Sep 2012 20:19:04 -0400
Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236])
	by d01dlp02.pok.ibm.com (Postfix) with ESMTP id 5EA0E6E803F
	for <xen-devel@lists.xensource.com>;
	Mon, 10 Sep 2012 20:19:03 -0400 (EDT)
Received: from d01av03.pok.ibm.com (d01av03.pok.ibm.com [9.56.224.217])
	by d01relay04.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id
	q8B0J3NJ166600
	for <xen-devel@lists.xensource.com>; Mon, 10 Sep 2012 20:19:03 -0400
Received: from d01av03.pok.ibm.com (loopback [127.0.0.1])
	by d01av03.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id
	q8B0J2BP030754
	for <xen-devel@lists.xensource.com>; Mon, 10 Sep 2012 21:19:03 -0300
Received: from [9.65.242.108] (sig-9-65-242-108.mts.ibm.com [9.65.242.108])
	by d01av03.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id
	q8B0IwBX030699; Mon, 10 Sep 2012 21:18:59 -0300
Message-ID: <504E8372.20904@linaro.org>
Date: Mon, 10 Sep 2012 17:18:58 -0700
From: John Stultz <john.stultz@linaro.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120827 Thunderbird/15.0
MIME-Version: 1.0
To: Daniel Lezcano <daniel.lezcano@linaro.org>
References: <1343164349-28550-1-git-send-email-daniel.lezcano@linaro.org>
	<201209062204.11288.rjw@sisk.pl> <50490920.9070204@linaro.org>
	<201209062318.42874.rjw@sisk.pl> <504A02BD.4000805@linaro.org>
	<504A2D73.3010702@linaro.org> <504A68A0.7010907@linaro.org>
	<504E1FE5.6090502@linaro.org> <504E4343.5070004@linaro.org>
In-Reply-To: <504E4343.5070004@linaro.org>
X-Content-Scanned: Fidelis XPS MAILER
x-cbid: 12091100-5930-0000-0000-00000BE45A2C
Cc: prarit@redhat.com, xen-devel@lists.xensource.com,
	linaro-dev@lists.linaro.org, Peter Zijlstra <a.p.zijlstra@chello.nl>,
	linux-pm@vger.kernel.org, Frederic Weisbecker <fweisbec@gmail.com>,
	richardcochran@gmail.com, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	"Rafael J. Wysocki" <rjw@sisk.pl>, linux-acpi@vger.kernel.org,
	Thomas Gleixner <tglx@linutronix.de>, mingo@kernel.org, lenb@kernel.org
Subject: Re: [Xen-devel] CONFIG_NO_HZ + CONFIG_CPU_IDLE freeze the system
 (Was Re: [PATCH] acpi : remove power from acpi_processor_cx structure)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 09/10/2012 12:45 PM, Daniel Lezcano wrote:
> On 09/10/2012 07:14 PM, John Stultz wrote:
>> In the meantime, I'll try to reproduce on my T61. If you could send me
>> your .config, I'd appreciate it.
> http://pastebin.com/qSxqfdDK
>
> The header of the config file shows for a v3.5-rc7 because it is the
> result of the git-bisect. If you keep this config file for the latest
> kernel that should reproduce the problem.
>
> Let me know if you were able to reproduce the problem.
Great! With this I was able to quickly reproduce the problem and I think 
I have a fix.

Would you mind testing the following patch? It seems to resolve the 
issue, but I've not yet run it through my test suite to make sure it 
didn't break anything else.

If both your and my testing comes back ok, I'll submit it to Thomas.

thanks
-john

 From f10a285a5b532a14d3330f6e60e4d7bd5627932a Mon Sep 17 00:00:00 2001
From: John Stultz <john.stultz@linaro.org>
Date: Mon, 10 Sep 2012 20:00:15 -0400
Subject: [PATCH] time: Fix timeekeping_get_ns overflow on 32bit systems

Daniel Lezcano reported seeing multi-second stalls from
keyboard input on his T61 laptop when NOHZ and CPU_IDLE
were enabled on a 32bit kernel.

He bisected the problem down to
1e75fa8be9fb61e1af46b5b3b176347a4c958ca1 (time: Condense
timekeeper.xtime into xtime_sec).

After reproducing this issue, I narrowed the problem down
to the fact that timekeeping_get_ns() returns a 64bit
nsec value that hasn't been accumulated. In some cases
this value was being then stored in timespec.tv_nsec
(which is a long).

On 32bit systems, With idle times larger then 4 seconds
(or less, depending on the value of xtime_nsec), the
returned nsec value would overflow 32bits. This limited
kept time from increasing, causing timers to not expire.

The fix is to make sure we don't directly store the
result of timekeeping_get_ns() into a tv_nsec field,
instead using a 64bit nsec value which can then be
added into the timespec via timespec_add_ns().

With this patch I cannot reproduce the issue.

Cc: Ingo Molnar <mingo@kernel.org>
Cc: Richard Cochran <richardcochran@gmail.com>
Cc: Prarit Bhargava <prarit@redhat.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Daniel Lezcano <daniel.lezcano@linaro.org>
Reported-and-bisected-by: Daniel Lezcano <daniel.lezcano@linaro.org>
Signed-off-by: John Stultz <john.stultz@linaro.org>
---
  kernel/time/timekeeping.c |   19 ++++++++++++-------
  1 file changed, 12 insertions(+), 7 deletions(-)

diff --git a/kernel/time/timekeeping.c b/kernel/time/timekeeping.c
index 34e5eac..d3b91e7 100644
--- a/kernel/time/timekeeping.c
+++ b/kernel/time/timekeeping.c
@@ -303,10 +303,11 @@ void getnstimeofday(struct timespec *ts)
  		seq = read_seqbegin(&tk->lock);
  
  		ts->tv_sec = tk->xtime_sec;
-		ts->tv_nsec = timekeeping_get_ns(tk);
+		nsecs = timekeeping_get_ns(tk);
  
  	} while (read_seqretry(&tk->lock, seq));
  
+	ts->tv_nsec = 0;
  	timespec_add_ns(ts, nsecs);
  }
  EXPORT_SYMBOL(getnstimeofday);
@@ -345,6 +346,7 @@ void ktime_get_ts(struct timespec *ts)
  {
  	struct timekeeper *tk = &timekeeper;
  	struct timespec tomono;
+	s64 nsec;
  	unsigned int seq;
  
  	WARN_ON(timekeeping_suspended);
@@ -352,13 +354,14 @@ void ktime_get_ts(struct timespec *ts)
  	do {
  		seq = read_seqbegin(&tk->lock);
  		ts->tv_sec = tk->xtime_sec;
-		ts->tv_nsec = timekeeping_get_ns(tk);
+		nsec = timekeeping_get_ns(tk);
  		tomono = tk->wall_to_monotonic;
  
  	} while (read_seqretry(&tk->lock, seq));
  
-	set_normalized_timespec(ts, ts->tv_sec + tomono.tv_sec,
-				ts->tv_nsec + tomono.tv_nsec);
+	ts->tv_sec += tomono.tv_sec;
+	ts->tv_nsec = 0;
+	timespec_add_ns(ts, nsec + tomono.tv_nsec);
  }
  EXPORT_SYMBOL_GPL(ktime_get_ts);
  
@@ -1244,6 +1247,7 @@ void get_monotonic_boottime(struct timespec *ts)
  {
  	struct timekeeper *tk = &timekeeper;
  	struct timespec tomono, sleep;
+	s64 nsec;
  	unsigned int seq;
  
  	WARN_ON(timekeeping_suspended);
@@ -1251,14 +1255,15 @@ void get_monotonic_boottime(struct timespec *ts)
  	do {
  		seq = read_seqbegin(&tk->lock);
  		ts->tv_sec = tk->xtime_sec;
-		ts->tv_nsec = timekeeping_get_ns(tk);
+		nsec = timekeeping_get_ns(tk);
  		tomono = tk->wall_to_monotonic;
  		sleep = tk->total_sleep_time;
  
  	} while (read_seqretry(&tk->lock, seq));
  
-	set_normalized_timespec(ts, ts->tv_sec + tomono.tv_sec + sleep.tv_sec,
-			ts->tv_nsec + tomono.tv_nsec + sleep.tv_nsec);
+	ts->tv_sec += tomono.tv_sec + sleep.tv_sec;
+	ts->tv_nsec = 0;
+	timespec_add_ns(ts, nsec + tomono.tv_nsec + sleep.tv_nsec);
  }
  EXPORT_SYMBOL_GPL(get_monotonic_boottime);
  
-- 
1.7.9.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 11 01:18:49 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 2012 01:18:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TBF7M-0008Aj-1U; Tue, 11 Sep 2012 01:18:20 +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 1TBF7K-0008Ae-3l
	for xen-devel@lists.xen.org; Tue, 11 Sep 2012 01:18:18 +0000
Received: from [85.158.139.83:49310] by server-9.bemta-5.messagelabs.com id
	1C/59-20529-9519E405; Tue, 11 Sep 2012 01:18:17 +0000
X-Env-Sender: msw@amazon.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1347326294!22486942!1
X-Originating-IP: [207.171.178.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA3LjE3MS4xNzguMjUgPT4gNjU0NTA=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20009 invoked from network); 11 Sep 2012 01:18:16 -0000
Received: from smtp-fw-31001.amazon.com (HELO smtp-fw-31001.amazon.com)
	(207.171.178.25)
	by server-11.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Sep 2012 01:18:16 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=amazon.com; i=msw@amazon.com; q=dns/txt; s=rte02;
	t=1347326296; x=1378862296;
	h=date:from:to:cc:subject:message-id:references:
	mime-version:in-reply-to;
	bh=VRjGmONTdFzAYiI6q8R4ljqM+MkZX0DRHGMx73HCx/k=;
	b=ZB+OSYt8QghWC+f50YU0q5HNV2rKoLAA2Y0Plw3BY11ypRdzEbuQQVgo
	ia/WmHsF7LUY6vTTU/JFNracWkQKxw==;
X-IronPort-AV: E=Sophos;i="4.80,401,1344211200"; d="scan'208";a="292710405"
Received: from smtp-in-0102.sea3.amazon.com ([10.224.19.46])
	by smtp-border-fw-out-31001.sea31.amazon.com with
	ESMTP/TLS/DHE-RSA-AES256-SHA; 11 Sep 2012 01:17:57 +0000
Received: from ex10-hub-31006.ant.amazon.com (ex10-hub-31006.sea31.amazon.com
	[10.185.176.13])
	by smtp-in-0102.sea3.amazon.com (8.13.8/8.13.8) with ESMTP id
	q8B1HuQp000314
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL);
	Tue, 11 Sep 2012 01:17:56 GMT
Received: from u002268147cd4502c336d.ant.amazon.com (10.224.80.42) by
	ex10-hub-31006.ant.amazon.com (10.185.176.13) with Microsoft SMTP
	Server id 14.2.247.3; Mon, 10 Sep 2012 18:17:51 -0700
Received: by u002268147cd4502c336d.ant.amazon.com (sSMTP sendmail emulation); 
	Mon, 10 Sep 2012 18:17:52 -0700
Date: Mon, 10 Sep 2012 18:17:52 -0700
From: Matt Wilson <msw@amazon.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Message-ID: <20120911011752.GD22357@u002268147cd4502c336d.ant.amazon.com>
References: <1347018043-21252-1-git-send-email-stefan.bader@canonical.com>
	<20120907134701.GF2870@phenom.dumpdata.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120907134701.GF2870@phenom.dumpdata.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Stefan Bader <stefan.bader@canonical.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH/RFC] Fix xsave bug on older Xen hypervisors
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Sep 07, 2012 at 09:47:01AM -0400, Konrad Rzeszutek Wilk wrote:
> On Fri, Sep 07, 2012 at 01:40:43PM +0200, Stefan Bader wrote:
> > When writing unsupported flags into CR4 (for some time the
> > xen_write_cr4 function would refuse to do anything at all)
> > older Xen hypervisors (and patch can potentially be improved
> > by finding out what older means in version numbers) would
> > crash the guest.
> > 
> > Since Amazon EC2 would at least in the past be affected by that,
> > Fedora and Ubuntu were carrying a hack that would filter out
> > X86_CR4_OSXSAVE before writing to CR4. This would affect any
> > PV guest, even those running on a newer HV.
> > 
> > And this recently caused trouble because some user-space was
> > only partially checking (or maybe only looking at the cpuid
> > bits) and then trying to use xsave even though the OS support
> > was not set.
> > 
> > So I came up with a patch that would
> > - limit the work-around to certain Xen versions
> > - prevent the write to CR4 by unsetting xsave and osxsave in
> >   the cpuid bits
> > 
> > Doing things that way may actually allow this to be acceptable
> > upstream, so I am sending it around, now.
> > It probably could be improved when knowing the exact version
> > to test for but otherwise should allow to work around the guest
> > crash while not preventing xsave on Xen 4.x and newer hosts.
> 
> Perhaps Matt can give us some hints here.. but otherwise this
> "quirk" should fix this. It should also allow one to run a virgin
> kernel on Amazon EC2 - and we can ask the distros to ditch their
> existing work-arounds for this..

Xen 3.4.0 rc1 contained changeset 19288:9ed53e602119, so checking for
major version < 4 is a bit restrictive. That being said, I don't think
that full PV support of xsave landed until 4.0.2.

Anyway, given that Xen advertises support for XSAVE via setting
OSXSAVE, I'm not happy with a version number check.

> > >From dff8885934d4e1274a69c4cedd28a4d18a1255e8 Mon Sep 17 00:00:00 2001
> > From: Stefan Bader <stefan.bader@canonical.com>
> > Date: Fri, 15 Jun 2012 11:54:59 +0200
> > Subject: [PATCH] xen: Mask xsave cpu capability on Xen host < 4
> >
> > Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
[...]
> > +/*
> > + * Older (with no clear statement about what old means) Xen hypervisors
> > + * will crash a PV guest that tries to store OSXSAVE into CR4.
> > + * To prevent this, we force the feature bits related to this off in the
> > + * xen cpuid call. This inline function serves as a centralized test
> > + * on whether the quirk should be done.
> > + */
> > +static inline needs_xsave_quirk(unsigned version)
> > +{
> > +	return (xen_pv_domain() && ((version >> 16) < 4)) ? 1 : 0;

What has me really a bit confused is this: it seems that Xen should be
setting OSXSAVE for the guest if XSAVE is supported. Going back to the
changeset that Konrad point out:

commit 947ccf9c3c30307b774af3666ee74fcd9f47f646
Author: Shan Haitao <haitao.shan@intel.com>
Date:   Tue Nov 9 11:43:36 2010 -0800

    xen: Allow PV-OPS kernel to detect whether XSAVE is supported
    
    Xen fails to mask XSAVE from the cpuid feature, despite not historically
    supporting guest use of XSAVE.  However, now that XSAVE support has been
    added to Xen, we need to reliably detect its presence.
    
    The most reliable way to do this is to look at the OSXSAVE feature in
    cpuid which is set iff the OS (Xen, in this case), has set
    CR4.OSXSAVE.
[...]
+       xsave_mask =
+               (1 << (X86_FEATURE_XSAVE % 32)) |
+               (1 << (X86_FEATURE_OSXSAVE % 32));
+
+       /* Xen will set CR4.OSXSAVE if supported and not disabled by force */
+       if ((cx & xsave_mask) != xsave_mask)
+               cpuid_leaf1_ecx_mask &= ~xsave_mask; /* disable XSAVE & OSXSAVE */

Since this proposed change is basically in the same codepath as the
existing check to see if OSXSAVE is set, I doubt that it will prevent
xsave_init() from writing the killer bits into cr4.

Let me do a bit of testing.

Matt

> > +}
> > +
> >  static void __init xen_banner(void)
> >  {
> >  	unsigned version = HYPERVISOR_xen_version(XENVER_version, NULL);
> > @@ -221,6 +233,8 @@ static void __init xen_banner(void)
> >  	printk(KERN_INFO "Xen version: %d.%d%s%s\n",
> >  	       version >> 16, version & 0xffff, extra.extraversion,
> >  	       xen_feature(XENFEAT_mmu_pt_update_preserve_ad) ? " (preserve-AD)" : "");
> > +	if (needs_xsave_quirk(version))
> > +		printk(KERN_INFO "Forcing xsave off due to Xen version.\n");
> >  }
> >  
> >  #define CPUID_THERM_POWER_LEAF 6
> > @@ -351,6 +365,7 @@ static bool __init xen_check_mwait(void)
> >  }
> >  static void __init xen_init_cpuid_mask(void)
> >  {
> > +	unsigned version = HYPERVISOR_xen_version(XENVER_version, NULL);
> >  	unsigned int ax, bx, cx, dx;
> >  	unsigned int xsave_mask;
> >  
> > @@ -371,7 +386,7 @@ static void __init xen_init_cpuid_mask(void)
> >  		(1 << (X86_FEATURE_OSXSAVE % 32));
> >  
> >  	/* Xen will set CR4.OSXSAVE if supported and not disabled by force */
> > -	if ((cx & xsave_mask) != xsave_mask)
> > +	if (((cx & xsave_mask) != xsave_mask) || needs_xsave_quirk(version))
> >  		cpuid_leaf1_ecx_mask &= ~xsave_mask; /* disable XSAVE & OSXSAVE */
> >  	if (xen_check_mwait())
> >  		cpuid_leaf1_ecx_set_mask = (1 << (X86_FEATURE_MWAIT % 32));

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 11 01:18:49 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 2012 01:18:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TBF7M-0008Aj-1U; Tue, 11 Sep 2012 01:18:20 +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 1TBF7K-0008Ae-3l
	for xen-devel@lists.xen.org; Tue, 11 Sep 2012 01:18:18 +0000
Received: from [85.158.139.83:49310] by server-9.bemta-5.messagelabs.com id
	1C/59-20529-9519E405; Tue, 11 Sep 2012 01:18:17 +0000
X-Env-Sender: msw@amazon.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1347326294!22486942!1
X-Originating-IP: [207.171.178.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA3LjE3MS4xNzguMjUgPT4gNjU0NTA=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20009 invoked from network); 11 Sep 2012 01:18:16 -0000
Received: from smtp-fw-31001.amazon.com (HELO smtp-fw-31001.amazon.com)
	(207.171.178.25)
	by server-11.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Sep 2012 01:18:16 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=amazon.com; i=msw@amazon.com; q=dns/txt; s=rte02;
	t=1347326296; x=1378862296;
	h=date:from:to:cc:subject:message-id:references:
	mime-version:in-reply-to;
	bh=VRjGmONTdFzAYiI6q8R4ljqM+MkZX0DRHGMx73HCx/k=;
	b=ZB+OSYt8QghWC+f50YU0q5HNV2rKoLAA2Y0Plw3BY11ypRdzEbuQQVgo
	ia/WmHsF7LUY6vTTU/JFNracWkQKxw==;
X-IronPort-AV: E=Sophos;i="4.80,401,1344211200"; d="scan'208";a="292710405"
Received: from smtp-in-0102.sea3.amazon.com ([10.224.19.46])
	by smtp-border-fw-out-31001.sea31.amazon.com with
	ESMTP/TLS/DHE-RSA-AES256-SHA; 11 Sep 2012 01:17:57 +0000
Received: from ex10-hub-31006.ant.amazon.com (ex10-hub-31006.sea31.amazon.com
	[10.185.176.13])
	by smtp-in-0102.sea3.amazon.com (8.13.8/8.13.8) with ESMTP id
	q8B1HuQp000314
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL);
	Tue, 11 Sep 2012 01:17:56 GMT
Received: from u002268147cd4502c336d.ant.amazon.com (10.224.80.42) by
	ex10-hub-31006.ant.amazon.com (10.185.176.13) with Microsoft SMTP
	Server id 14.2.247.3; Mon, 10 Sep 2012 18:17:51 -0700
Received: by u002268147cd4502c336d.ant.amazon.com (sSMTP sendmail emulation); 
	Mon, 10 Sep 2012 18:17:52 -0700
Date: Mon, 10 Sep 2012 18:17:52 -0700
From: Matt Wilson <msw@amazon.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Message-ID: <20120911011752.GD22357@u002268147cd4502c336d.ant.amazon.com>
References: <1347018043-21252-1-git-send-email-stefan.bader@canonical.com>
	<20120907134701.GF2870@phenom.dumpdata.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120907134701.GF2870@phenom.dumpdata.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Stefan Bader <stefan.bader@canonical.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH/RFC] Fix xsave bug on older Xen hypervisors
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Sep 07, 2012 at 09:47:01AM -0400, Konrad Rzeszutek Wilk wrote:
> On Fri, Sep 07, 2012 at 01:40:43PM +0200, Stefan Bader wrote:
> > When writing unsupported flags into CR4 (for some time the
> > xen_write_cr4 function would refuse to do anything at all)
> > older Xen hypervisors (and patch can potentially be improved
> > by finding out what older means in version numbers) would
> > crash the guest.
> > 
> > Since Amazon EC2 would at least in the past be affected by that,
> > Fedora and Ubuntu were carrying a hack that would filter out
> > X86_CR4_OSXSAVE before writing to CR4. This would affect any
> > PV guest, even those running on a newer HV.
> > 
> > And this recently caused trouble because some user-space was
> > only partially checking (or maybe only looking at the cpuid
> > bits) and then trying to use xsave even though the OS support
> > was not set.
> > 
> > So I came up with a patch that would
> > - limit the work-around to certain Xen versions
> > - prevent the write to CR4 by unsetting xsave and osxsave in
> >   the cpuid bits
> > 
> > Doing things that way may actually allow this to be acceptable
> > upstream, so I am sending it around, now.
> > It probably could be improved when knowing the exact version
> > to test for but otherwise should allow to work around the guest
> > crash while not preventing xsave on Xen 4.x and newer hosts.
> 
> Perhaps Matt can give us some hints here.. but otherwise this
> "quirk" should fix this. It should also allow one to run a virgin
> kernel on Amazon EC2 - and we can ask the distros to ditch their
> existing work-arounds for this..

Xen 3.4.0 rc1 contained changeset 19288:9ed53e602119, so checking for
major version < 4 is a bit restrictive. That being said, I don't think
that full PV support of xsave landed until 4.0.2.

Anyway, given that Xen advertises support for XSAVE via setting
OSXSAVE, I'm not happy with a version number check.

> > >From dff8885934d4e1274a69c4cedd28a4d18a1255e8 Mon Sep 17 00:00:00 2001
> > From: Stefan Bader <stefan.bader@canonical.com>
> > Date: Fri, 15 Jun 2012 11:54:59 +0200
> > Subject: [PATCH] xen: Mask xsave cpu capability on Xen host < 4
> >
> > Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
[...]
> > +/*
> > + * Older (with no clear statement about what old means) Xen hypervisors
> > + * will crash a PV guest that tries to store OSXSAVE into CR4.
> > + * To prevent this, we force the feature bits related to this off in the
> > + * xen cpuid call. This inline function serves as a centralized test
> > + * on whether the quirk should be done.
> > + */
> > +static inline needs_xsave_quirk(unsigned version)
> > +{
> > +	return (xen_pv_domain() && ((version >> 16) < 4)) ? 1 : 0;

What has me really a bit confused is this: it seems that Xen should be
setting OSXSAVE for the guest if XSAVE is supported. Going back to the
changeset that Konrad point out:

commit 947ccf9c3c30307b774af3666ee74fcd9f47f646
Author: Shan Haitao <haitao.shan@intel.com>
Date:   Tue Nov 9 11:43:36 2010 -0800

    xen: Allow PV-OPS kernel to detect whether XSAVE is supported
    
    Xen fails to mask XSAVE from the cpuid feature, despite not historically
    supporting guest use of XSAVE.  However, now that XSAVE support has been
    added to Xen, we need to reliably detect its presence.
    
    The most reliable way to do this is to look at the OSXSAVE feature in
    cpuid which is set iff the OS (Xen, in this case), has set
    CR4.OSXSAVE.
[...]
+       xsave_mask =
+               (1 << (X86_FEATURE_XSAVE % 32)) |
+               (1 << (X86_FEATURE_OSXSAVE % 32));
+
+       /* Xen will set CR4.OSXSAVE if supported and not disabled by force */
+       if ((cx & xsave_mask) != xsave_mask)
+               cpuid_leaf1_ecx_mask &= ~xsave_mask; /* disable XSAVE & OSXSAVE */

Since this proposed change is basically in the same codepath as the
existing check to see if OSXSAVE is set, I doubt that it will prevent
xsave_init() from writing the killer bits into cr4.

Let me do a bit of testing.

Matt

> > +}
> > +
> >  static void __init xen_banner(void)
> >  {
> >  	unsigned version = HYPERVISOR_xen_version(XENVER_version, NULL);
> > @@ -221,6 +233,8 @@ static void __init xen_banner(void)
> >  	printk(KERN_INFO "Xen version: %d.%d%s%s\n",
> >  	       version >> 16, version & 0xffff, extra.extraversion,
> >  	       xen_feature(XENFEAT_mmu_pt_update_preserve_ad) ? " (preserve-AD)" : "");
> > +	if (needs_xsave_quirk(version))
> > +		printk(KERN_INFO "Forcing xsave off due to Xen version.\n");
> >  }
> >  
> >  #define CPUID_THERM_POWER_LEAF 6
> > @@ -351,6 +365,7 @@ static bool __init xen_check_mwait(void)
> >  }
> >  static void __init xen_init_cpuid_mask(void)
> >  {
> > +	unsigned version = HYPERVISOR_xen_version(XENVER_version, NULL);
> >  	unsigned int ax, bx, cx, dx;
> >  	unsigned int xsave_mask;
> >  
> > @@ -371,7 +386,7 @@ static void __init xen_init_cpuid_mask(void)
> >  		(1 << (X86_FEATURE_OSXSAVE % 32));
> >  
> >  	/* Xen will set CR4.OSXSAVE if supported and not disabled by force */
> > -	if ((cx & xsave_mask) != xsave_mask)
> > +	if (((cx & xsave_mask) != xsave_mask) || needs_xsave_quirk(version))
> >  		cpuid_leaf1_ecx_mask &= ~xsave_mask; /* disable XSAVE & OSXSAVE */
> >  	if (xen_check_mwait())
> >  		cpuid_leaf1_ecx_set_mask = (1 << (X86_FEATURE_MWAIT % 32));

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 11 01:22:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 2012 01:22: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 1TBFAa-0008H2-Lb; Tue, 11 Sep 2012 01:21:40 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andres.lagarcavilla@gmail.com>) id 1TBFAZ-0008Gp-5S
	for xen-devel@lists.xen.org; Tue, 11 Sep 2012 01:21:39 +0000
X-Env-Sender: andres.lagarcavilla@gmail.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1347326490!2775211!1
X-Originating-IP: [209.85.210.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7045 invoked from network); 11 Sep 2012 01:21:32 -0000
Received: from mail-iy0-f173.google.com (HELO mail-iy0-f173.google.com)
	(209.85.210.173)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Sep 2012 01:21:32 -0000
Received: by iakx26 with SMTP id x26so2820253iak.32
	for <xen-devel@lists.xen.org>; Mon, 10 Sep 2012 18:21:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=subject:mime-version:content-type:from:in-reply-to:date:cc
	:content-transfer-encoding:message-id:references:to:x-mailer;
	bh=OiQpDZbKj/G3B6dtBkRWjaICm34+foBZU4qyDVXaKqo=;
	b=YwEH7P6Wvqb7CR9pAvEyxlwfuTDsEzkVZPo7yAQQEvmVhuprPVnaTlKHFDPmExK/FH
	Dkd8uq9s+taTJplNcJIS0LU7jMkXZw3jtSrXLqZ8YuXkKm2lvfwitlnVzPSG3s/nAyTD
	S0QxZaNWbuNKcUQO0+MHvJzmTTY0pLAM/waUpzdjwAyxiUyayPFsVNk0n8pQVoZI9oly
	ahLjGvbU+vv/O5rjanL1Bi+5iDvVT/XPl5A5laH48m5PG3SDqkwQk1n6ppG4TMSLgqMt
	A7Xq1Tv2hAYRvhPv1sVsvtyH6UpAWlteQXlGB+V9SW55674CWFYLDc1n4RTJICNlpDEp
	fsrg==
Received: by 10.50.160.195 with SMTP id xm3mr13920781igb.12.1347326490583;
	Mon, 10 Sep 2012 18:21:30 -0700 (PDT)
Received: from [192.168.1.100] (69-196-182-10.dsl.teksavvy.com.
	[69.196.182.10])
	by mx.google.com with ESMTPS id ua2sm1748962igb.7.2012.09.10.18.21.28
	(version=TLSv1/SSLv3 cipher=OTHER);
	Mon, 10 Sep 2012 18:21:29 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1278)
From: Andres Lagar-Cavilla <andres.lagarcavilla@gmail.com>
In-Reply-To: <CANSvah6nWfKP9-PLSkhbFcO2ONmfj5Hhs-+3r0MhjOUHU1qNfg@mail.gmail.com>
Date: Mon, 10 Sep 2012 21:21:27 -0400
Message-Id: <5E75DC93-571F-4B6A-BABF-24ECF4BC843F@gmail.com>
References: <CANSvah6PU5SOKd19qfbvTXvz4spcPYVUQHmiirmm5hPvmzR+pg@mail.gmail.com>
	<CC741C8D.4B3AF%keir@xen.org>
	<CANSvah6nWfKP9-PLSkhbFcO2ONmfj5Hhs-+3r0MhjOUHU1qNfg@mail.gmail.com>
To: Steven Maresca <steve@zentific.com>
X-Mailer: Apple Mail (2.1278)
Cc: Aravindh Puthiyaparambil <aravindh@virtuata.com>,
	Keir Fraser <keir@xen.org>, andres@lagarcavilla.org,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] mem_event: fix regression affecting CR3,
	CR4 memory events
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


On Sep 10, 2012, at 6:06 PM, Steven Maresca wrote:

> On Mon, Sep 10, 2012 at 5:39 PM, Keir Fraser <keir@xen.org> wrote:
>> On 10/09/2012 22:20, "Steven Maresca" <steve@zentific.com> wrote:
>> 
>>> Given the refactoring in the commit related to the regression
>>> http://xenbits.xen.org/hg/xen-unstable.hg/rev/1276926e3795, it seemed
>>> (to me anyway) that inserting calls as shown in the patch would be
>>> cleaner, but I can definitely come up with some drawbacks.  However, I
>>> wanted to get this fixed for 4.2 if at all possible, so I wanted to
>>> send regardless.
>>> 
>>> In terms of drawbacks, this will require some ifdefs for x86_64, for example.
>>> 
>>> Any suggestions for the cleanest means of achieving the same in vmx.c?
>> 
>> I don't understand this at all. The original commit moved some CR handling
>> to common HVM code. Your patch adds some mem_event calls into that common
>> HVM code. What would need to be "achieved" in vmx.c? What ifdefs would be
>> required for x86_64?
>> 
>> -- Keir
>> 
>> 
> 
> Keir,
> 
> In the process of moving CR handling to common code, that commit
> removed calls to hvm_memory_event_cr3() and hvm_memory_event_cr4().
> Without some patch restoring the calls to those two functions, current
> xen-unstable and xen-4.2-testing only reference them as function
> prototypes and function definitions -- there are no calls whatsoever.
> 
> I only mentioned an ifdef relative to x86_64 because of the #ifdef
> __x86_64__  around the function definitions. ( I know in the hvm.h
> itself they're just empty inline functions if not __x86_64__. )
> 
> Regarding vmx.c: hvm_memory_event_cr0 is called within vmx_cr_access.
> The patch I sent restoring the calls to hvm_memory_event_cr4 and
> hvm_memory_event_cr3 could be treated similarly, that's all.

The patch looks ok to me.
Acked-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

You don't need to worry about x86_32. Is on its way out. You don't need to push this down into vmx either. Once AMD gains support for mem-event, this will just work for svm as well.

Like Keir says, no need for us. Your patch is good as is. Best to cc Tim Deegan <tim@xen.org>, the mm maintainer.

Cheers
Andres

> 
> Steve


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 11 01:22:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 2012 01:22: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 1TBFAa-0008H2-Lb; Tue, 11 Sep 2012 01:21:40 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andres.lagarcavilla@gmail.com>) id 1TBFAZ-0008Gp-5S
	for xen-devel@lists.xen.org; Tue, 11 Sep 2012 01:21:39 +0000
X-Env-Sender: andres.lagarcavilla@gmail.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1347326490!2775211!1
X-Originating-IP: [209.85.210.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7045 invoked from network); 11 Sep 2012 01:21:32 -0000
Received: from mail-iy0-f173.google.com (HELO mail-iy0-f173.google.com)
	(209.85.210.173)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Sep 2012 01:21:32 -0000
Received: by iakx26 with SMTP id x26so2820253iak.32
	for <xen-devel@lists.xen.org>; Mon, 10 Sep 2012 18:21:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=subject:mime-version:content-type:from:in-reply-to:date:cc
	:content-transfer-encoding:message-id:references:to:x-mailer;
	bh=OiQpDZbKj/G3B6dtBkRWjaICm34+foBZU4qyDVXaKqo=;
	b=YwEH7P6Wvqb7CR9pAvEyxlwfuTDsEzkVZPo7yAQQEvmVhuprPVnaTlKHFDPmExK/FH
	Dkd8uq9s+taTJplNcJIS0LU7jMkXZw3jtSrXLqZ8YuXkKm2lvfwitlnVzPSG3s/nAyTD
	S0QxZaNWbuNKcUQO0+MHvJzmTTY0pLAM/waUpzdjwAyxiUyayPFsVNk0n8pQVoZI9oly
	ahLjGvbU+vv/O5rjanL1Bi+5iDvVT/XPl5A5laH48m5PG3SDqkwQk1n6ppG4TMSLgqMt
	A7Xq1Tv2hAYRvhPv1sVsvtyH6UpAWlteQXlGB+V9SW55674CWFYLDc1n4RTJICNlpDEp
	fsrg==
Received: by 10.50.160.195 with SMTP id xm3mr13920781igb.12.1347326490583;
	Mon, 10 Sep 2012 18:21:30 -0700 (PDT)
Received: from [192.168.1.100] (69-196-182-10.dsl.teksavvy.com.
	[69.196.182.10])
	by mx.google.com with ESMTPS id ua2sm1748962igb.7.2012.09.10.18.21.28
	(version=TLSv1/SSLv3 cipher=OTHER);
	Mon, 10 Sep 2012 18:21:29 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1278)
From: Andres Lagar-Cavilla <andres.lagarcavilla@gmail.com>
In-Reply-To: <CANSvah6nWfKP9-PLSkhbFcO2ONmfj5Hhs-+3r0MhjOUHU1qNfg@mail.gmail.com>
Date: Mon, 10 Sep 2012 21:21:27 -0400
Message-Id: <5E75DC93-571F-4B6A-BABF-24ECF4BC843F@gmail.com>
References: <CANSvah6PU5SOKd19qfbvTXvz4spcPYVUQHmiirmm5hPvmzR+pg@mail.gmail.com>
	<CC741C8D.4B3AF%keir@xen.org>
	<CANSvah6nWfKP9-PLSkhbFcO2ONmfj5Hhs-+3r0MhjOUHU1qNfg@mail.gmail.com>
To: Steven Maresca <steve@zentific.com>
X-Mailer: Apple Mail (2.1278)
Cc: Aravindh Puthiyaparambil <aravindh@virtuata.com>,
	Keir Fraser <keir@xen.org>, andres@lagarcavilla.org,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] mem_event: fix regression affecting CR3,
	CR4 memory events
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


On Sep 10, 2012, at 6:06 PM, Steven Maresca wrote:

> On Mon, Sep 10, 2012 at 5:39 PM, Keir Fraser <keir@xen.org> wrote:
>> On 10/09/2012 22:20, "Steven Maresca" <steve@zentific.com> wrote:
>> 
>>> Given the refactoring in the commit related to the regression
>>> http://xenbits.xen.org/hg/xen-unstable.hg/rev/1276926e3795, it seemed
>>> (to me anyway) that inserting calls as shown in the patch would be
>>> cleaner, but I can definitely come up with some drawbacks.  However, I
>>> wanted to get this fixed for 4.2 if at all possible, so I wanted to
>>> send regardless.
>>> 
>>> In terms of drawbacks, this will require some ifdefs for x86_64, for example.
>>> 
>>> Any suggestions for the cleanest means of achieving the same in vmx.c?
>> 
>> I don't understand this at all. The original commit moved some CR handling
>> to common HVM code. Your patch adds some mem_event calls into that common
>> HVM code. What would need to be "achieved" in vmx.c? What ifdefs would be
>> required for x86_64?
>> 
>> -- Keir
>> 
>> 
> 
> Keir,
> 
> In the process of moving CR handling to common code, that commit
> removed calls to hvm_memory_event_cr3() and hvm_memory_event_cr4().
> Without some patch restoring the calls to those two functions, current
> xen-unstable and xen-4.2-testing only reference them as function
> prototypes and function definitions -- there are no calls whatsoever.
> 
> I only mentioned an ifdef relative to x86_64 because of the #ifdef
> __x86_64__  around the function definitions. ( I know in the hvm.h
> itself they're just empty inline functions if not __x86_64__. )
> 
> Regarding vmx.c: hvm_memory_event_cr0 is called within vmx_cr_access.
> The patch I sent restoring the calls to hvm_memory_event_cr4 and
> hvm_memory_event_cr3 could be treated similarly, that's all.

The patch looks ok to me.
Acked-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

You don't need to worry about x86_32. Is on its way out. You don't need to push this down into vmx either. Once AMD gains support for mem-event, this will just work for svm as well.

Like Keir says, no need for us. Your patch is good as is. Best to cc Tim Deegan <tim@xen.org>, the mm maintainer.

Cheers
Andres

> 
> Steve


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 11 01:28:20 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 2012 01:28: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 1TBFGa-0008Sq-FN; Tue, 11 Sep 2012 01:27:52 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <gbtju85@gmail.com>) id 1TBFGZ-0008Sl-19
	for xen-devel@lists.xen.org; Tue, 11 Sep 2012 01:27:51 +0000
Received: from [85.158.138.51:27777] by server-11.bemta-3.messagelabs.com id
	EC/97-30250-6939E405; Tue, 11 Sep 2012 01:27:50 +0000
X-Env-Sender: gbtju85@gmail.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1347326868!20906445!1
X-Originating-IP: [209.85.217.173]
X-SpamReason: No, hits=0.9 required=7.0 tests=HTML_40_50,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20813 invoked from network); 11 Sep 2012 01:27:49 -0000
Received: from mail-lb0-f173.google.com (HELO mail-lb0-f173.google.com)
	(209.85.217.173)
	by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Sep 2012 01:27:49 -0000
Received: by lbbgm13 with SMTP id gm13so42547lbb.32
	for <xen-devel@lists.xen.org>; Mon, 10 Sep 2012 18:27:48 -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=OTXV16cKQucef0ofCFufuBXhe2OvvKD+hDRZMxm/NvA=;
	b=uqwRMvqD6GEm5HbOXvIIPFFiNTgdN6KRQCjEo1JBoM1Kg2a3OFG7S+XIGJICpcJY8V
	zkt73hreR89u0IdVrWzpox5/hJx6SRFN/AROy/zmlK5/R2Ie3iiYz3U+7XraO8fK7r2f
	EZ8JXsWFAIBuforBqIa7+pvbncfr6kixPfXlOQditm1Xf4wR723e7MoLYHgWL9GX6TGo
	I5hOpVXdAkuoXcMvmlb5aL0cUB3SDsrgJypcfgU/RfKDjB5Z2xFIbIDr/DV4RoitE2pl
	OkPq1kvBTUTXmCIiPffeee9TvrwfmlMyErvR6r9PQX6VLvRgAB956rf+0lRwX23hx5eX
	q67A==
MIME-Version: 1.0
Received: by 10.152.104.44 with SMTP id gb12mr10991951lab.29.1347326868472;
	Mon, 10 Sep 2012 18:27:48 -0700 (PDT)
Received: by 10.114.2.193 with HTTP; Mon, 10 Sep 2012 18:27:48 -0700 (PDT)
In-Reply-To: <20120910192456.GA28298@phenom.dumpdata.com>
References: <CAEQjb-TO9wy74up6pGfaRj+FQH8SPJtLXngM70ivWwWaQ53QPA@mail.gmail.com>
	<20120910192456.GA28298@phenom.dumpdata.com>
Date: Tue, 11 Sep 2012 09:27:48 +0800
Message-ID: <CAEQjb-QG71pnKQsWP1LLhpzXjkJUi+oRjFzLGZZZZSDJqo_BJA@mail.gmail.com>
From: Bei Guan <gbtju85@gmail.com>
To: Konrad Rzeszutek Wilk <konrad@kernel.org>
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Any news or plan about Xen support the APU
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============7974862439041158012=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============7974862439041158012==
Content-Type: multipart/alternative; boundary=f46d04088ef564436504c962fb43

--f46d04088ef564436504c962fb43
Content-Type: text/plain; charset=ISO-8859-1

Hi Konrad,

Thank you very much for your reply. I'm not hitting any issues.

AMD's APU is a new kind of processing device, which integrates a CPU and a
GPU on the same die. I want to know whether Xen has supported the
virtualization of the APU processors? If yes, I can run something
applications in the Xen PV VMs to use this kind of new CPU device.

Something information about the AMD' APU:
http://en.wikipedia.org/wiki/Accelerated_processing_unit
http://blog.netflowdevelopments.com/2012/05/03/what-is-an-apu/
http://www.amd.com/us/products/technologies/fusion/Pages/fusion.aspx


Best Regards,
Bei Guan


2012/9/11 Konrad Rzeszutek Wilk <konrad@kernel.org>

> On Mon, Sep 10, 2012 at 08:48:41PM +0800, Bei Guan wrote:
> > Hi,
> >
> > Is there any news or plan about Xen support the latest AMD hardware APU
> > (Accelerated Processing Unit)? Any clue is appreciated.
>
> Not sure what you mean, but it works just fine on the AMD A5 CPU I've?
> Are you hitting an issues?
> > Thank you very much.
> >
> >
> >
> > Best Regards,
> > Bei Guan
>
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xen.org
> > http://lists.xen.org/xen-devel
>
>


-- 
Best Regards,
Bei Guan

--f46d04088ef564436504c962fb43
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi Konrad,<div><br></div><div>Thank you very much for your reply. I&#39;m n=
ot hitting any issues.</div><div><br></div><div>AMD&#39;s APU is a new kind=
 of processing device, which integrates a CPU and a GPU on the same die. I =
want to know whether Xen has supported the virtualization of the APU proces=
sors? If yes, I can run something applications in the Xen PV VMs to use thi=
s kind of new CPU device.</div>
<div><br></div><div>Something information about the AMD&#39; APU:</div><div=
><div><a href=3D"http://en.wikipedia.org/wiki/Accelerated_processing_unit">=
http://en.wikipedia.org/wiki/Accelerated_processing_unit</a></div><div><a h=
ref=3D"http://blog.netflowdevelopments.com/2012/05/03/what-is-an-apu/">http=
://blog.netflowdevelopments.com/2012/05/03/what-is-an-apu/</a></div>
<div><a href=3D"http://www.amd.com/us/products/technologies/fusion/Pages/fu=
sion.aspx">http://www.amd.com/us/products/technologies/fusion/Pages/fusion.=
aspx</a></div></div><div><br></div><div><br>Best Regards,</div><div>Bei Gua=
n<br>
<br><br><div class=3D"gmail_quote">2012/9/11 Konrad Rzeszutek Wilk <span di=
r=3D"ltr">&lt;<a href=3D"mailto:konrad@kernel.org" target=3D"_blank">konrad=
@kernel.org</a>&gt;</span><br><blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class=3D"im">On Mon, Sep 10, 2012 at 08:48:41PM +0800, Bei Guan wrote:=
<br>
&gt; Hi,<br>
&gt;<br>
&gt; Is there any news or plan about Xen support the latest AMD hardware AP=
U<br>
&gt; (Accelerated Processing Unit)? Any clue is appreciated.<br>
<br>
</div>Not sure what you mean, but it works just fine on the AMD A5 CPU I&#3=
9;ve?<br>
Are you hitting an issues?<br>
<div class=3D"im">&gt; Thank you very much.<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; Best Regards,<br>
&gt; Bei Guan<br>
<br>
</div>&gt; _______________________________________________<br>
&gt; Xen-devel mailing list<br>
&gt; <a href=3D"mailto:Xen-devel@lists.xen.org">Xen-devel@lists.xen.org</a>=
<br>
&gt; <a href=3D"http://lists.xen.org/xen-devel" target=3D"_blank">http://li=
sts.xen.org/xen-devel</a><br>
<br>
</blockquote></div><br><br clear=3D"all"><div><br></div>-- <br>Best Regards=
,<div>Bei Guan</div><br>
</div>

--f46d04088ef564436504c962fb43--


--===============7974862439041158012==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============7974862439041158012==--


From xen-devel-bounces@lists.xen.org Tue Sep 11 01:28:20 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 2012 01:28: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 1TBFGa-0008Sq-FN; Tue, 11 Sep 2012 01:27:52 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <gbtju85@gmail.com>) id 1TBFGZ-0008Sl-19
	for xen-devel@lists.xen.org; Tue, 11 Sep 2012 01:27:51 +0000
Received: from [85.158.138.51:27777] by server-11.bemta-3.messagelabs.com id
	EC/97-30250-6939E405; Tue, 11 Sep 2012 01:27:50 +0000
X-Env-Sender: gbtju85@gmail.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1347326868!20906445!1
X-Originating-IP: [209.85.217.173]
X-SpamReason: No, hits=0.9 required=7.0 tests=HTML_40_50,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20813 invoked from network); 11 Sep 2012 01:27:49 -0000
Received: from mail-lb0-f173.google.com (HELO mail-lb0-f173.google.com)
	(209.85.217.173)
	by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Sep 2012 01:27:49 -0000
Received: by lbbgm13 with SMTP id gm13so42547lbb.32
	for <xen-devel@lists.xen.org>; Mon, 10 Sep 2012 18:27:48 -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=OTXV16cKQucef0ofCFufuBXhe2OvvKD+hDRZMxm/NvA=;
	b=uqwRMvqD6GEm5HbOXvIIPFFiNTgdN6KRQCjEo1JBoM1Kg2a3OFG7S+XIGJICpcJY8V
	zkt73hreR89u0IdVrWzpox5/hJx6SRFN/AROy/zmlK5/R2Ie3iiYz3U+7XraO8fK7r2f
	EZ8JXsWFAIBuforBqIa7+pvbncfr6kixPfXlOQditm1Xf4wR723e7MoLYHgWL9GX6TGo
	I5hOpVXdAkuoXcMvmlb5aL0cUB3SDsrgJypcfgU/RfKDjB5Z2xFIbIDr/DV4RoitE2pl
	OkPq1kvBTUTXmCIiPffeee9TvrwfmlMyErvR6r9PQX6VLvRgAB956rf+0lRwX23hx5eX
	q67A==
MIME-Version: 1.0
Received: by 10.152.104.44 with SMTP id gb12mr10991951lab.29.1347326868472;
	Mon, 10 Sep 2012 18:27:48 -0700 (PDT)
Received: by 10.114.2.193 with HTTP; Mon, 10 Sep 2012 18:27:48 -0700 (PDT)
In-Reply-To: <20120910192456.GA28298@phenom.dumpdata.com>
References: <CAEQjb-TO9wy74up6pGfaRj+FQH8SPJtLXngM70ivWwWaQ53QPA@mail.gmail.com>
	<20120910192456.GA28298@phenom.dumpdata.com>
Date: Tue, 11 Sep 2012 09:27:48 +0800
Message-ID: <CAEQjb-QG71pnKQsWP1LLhpzXjkJUi+oRjFzLGZZZZSDJqo_BJA@mail.gmail.com>
From: Bei Guan <gbtju85@gmail.com>
To: Konrad Rzeszutek Wilk <konrad@kernel.org>
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Any news or plan about Xen support the APU
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============7974862439041158012=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============7974862439041158012==
Content-Type: multipart/alternative; boundary=f46d04088ef564436504c962fb43

--f46d04088ef564436504c962fb43
Content-Type: text/plain; charset=ISO-8859-1

Hi Konrad,

Thank you very much for your reply. I'm not hitting any issues.

AMD's APU is a new kind of processing device, which integrates a CPU and a
GPU on the same die. I want to know whether Xen has supported the
virtualization of the APU processors? If yes, I can run something
applications in the Xen PV VMs to use this kind of new CPU device.

Something information about the AMD' APU:
http://en.wikipedia.org/wiki/Accelerated_processing_unit
http://blog.netflowdevelopments.com/2012/05/03/what-is-an-apu/
http://www.amd.com/us/products/technologies/fusion/Pages/fusion.aspx


Best Regards,
Bei Guan


2012/9/11 Konrad Rzeszutek Wilk <konrad@kernel.org>

> On Mon, Sep 10, 2012 at 08:48:41PM +0800, Bei Guan wrote:
> > Hi,
> >
> > Is there any news or plan about Xen support the latest AMD hardware APU
> > (Accelerated Processing Unit)? Any clue is appreciated.
>
> Not sure what you mean, but it works just fine on the AMD A5 CPU I've?
> Are you hitting an issues?
> > Thank you very much.
> >
> >
> >
> > Best Regards,
> > Bei Guan
>
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xen.org
> > http://lists.xen.org/xen-devel
>
>


-- 
Best Regards,
Bei Guan

--f46d04088ef564436504c962fb43
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi Konrad,<div><br></div><div>Thank you very much for your reply. I&#39;m n=
ot hitting any issues.</div><div><br></div><div>AMD&#39;s APU is a new kind=
 of processing device, which integrates a CPU and a GPU on the same die. I =
want to know whether Xen has supported the virtualization of the APU proces=
sors? If yes, I can run something applications in the Xen PV VMs to use thi=
s kind of new CPU device.</div>
<div><br></div><div>Something information about the AMD&#39; APU:</div><div=
><div><a href=3D"http://en.wikipedia.org/wiki/Accelerated_processing_unit">=
http://en.wikipedia.org/wiki/Accelerated_processing_unit</a></div><div><a h=
ref=3D"http://blog.netflowdevelopments.com/2012/05/03/what-is-an-apu/">http=
://blog.netflowdevelopments.com/2012/05/03/what-is-an-apu/</a></div>
<div><a href=3D"http://www.amd.com/us/products/technologies/fusion/Pages/fu=
sion.aspx">http://www.amd.com/us/products/technologies/fusion/Pages/fusion.=
aspx</a></div></div><div><br></div><div><br>Best Regards,</div><div>Bei Gua=
n<br>
<br><br><div class=3D"gmail_quote">2012/9/11 Konrad Rzeszutek Wilk <span di=
r=3D"ltr">&lt;<a href=3D"mailto:konrad@kernel.org" target=3D"_blank">konrad=
@kernel.org</a>&gt;</span><br><blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class=3D"im">On Mon, Sep 10, 2012 at 08:48:41PM +0800, Bei Guan wrote:=
<br>
&gt; Hi,<br>
&gt;<br>
&gt; Is there any news or plan about Xen support the latest AMD hardware AP=
U<br>
&gt; (Accelerated Processing Unit)? Any clue is appreciated.<br>
<br>
</div>Not sure what you mean, but it works just fine on the AMD A5 CPU I&#3=
9;ve?<br>
Are you hitting an issues?<br>
<div class=3D"im">&gt; Thank you very much.<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; Best Regards,<br>
&gt; Bei Guan<br>
<br>
</div>&gt; _______________________________________________<br>
&gt; Xen-devel mailing list<br>
&gt; <a href=3D"mailto:Xen-devel@lists.xen.org">Xen-devel@lists.xen.org</a>=
<br>
&gt; <a href=3D"http://lists.xen.org/xen-devel" target=3D"_blank">http://li=
sts.xen.org/xen-devel</a><br>
<br>
</blockquote></div><br><br clear=3D"all"><div><br></div>-- <br>Best Regards=
,<div>Bei Guan</div><br>
</div>

--f46d04088ef564436504c962fb43--


--===============7974862439041158012==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============7974862439041158012==--


From xen-devel-bounces@lists.xen.org Tue Sep 11 01:49:58 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 2012 01:49:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TBFba-0000HR-Ij; Tue, 11 Sep 2012 01:49:34 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <aravindh@virtuata.com>) id 1TBFbY-0000HM-Tj
	for xen-devel@lists.xen.org; Tue, 11 Sep 2012 01:49:33 +0000
Received: from [85.158.143.99:14453] by server-3.bemta-4.messagelabs.com id
	1B/59-08232-CA89E405; Tue, 11 Sep 2012 01:49:32 +0000
X-Env-Sender: aravindh@virtuata.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1347328171!29614448!1
X-Originating-IP: [74.125.82.51]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25563 invoked from network); 11 Sep 2012 01:49:31 -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;
	11 Sep 2012 01:49:31 -0000
Received: by wgbed3 with SMTP id ed3so1756543wgb.32
	for <xen-devel@lists.xen.org>; Mon, 10 Sep 2012 18:49:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=virtuata.com; s=google;
	h=mime-version:x-originating-ip:in-reply-to:references:date
	:message-id:subject:from:to:cc:content-type;
	bh=qa9HjoKoVLJosuVp0ECe9f6Scv7QBa8E/bGBX1CzOCY=;
	b=Vv6jhPSn867sVFdmOi+wnaw9kqX/UeJgL5FLoeFFX3RP7wkX3JZbTks974ABDgCmi0
	dWuOxkj0l15nexGxTpOwewGYp+YDB8Azejheg+Ehtu0I2NkHa7xpRIEXAMZwCUPK1hJb
	3ju31iNuFbe4ydP1pIjQyR3vf7iUBc5Q1g3HA=
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=qa9HjoKoVLJosuVp0ECe9f6Scv7QBa8E/bGBX1CzOCY=;
	b=Ji/uRtKt/eEXU2lkO2sHYqIGqV6W8Cd1WU8za1WM5pQswkkf8ulxPqPJB+cg9hZ6AJ
	d0CZbpTQFTEG+3LtZo+EBXehK0w4cT3kw1fDXTevsywJWF2+ZRYsSH1xvHG336SYNpPK
	yINA2Ghak/vpP8/YkceoGgnLhEMEbSNpxsP9xfuqwhBI1f70ymFbf0mkQCodig4qyjyP
	uStCyY6iye7LR8YR5rmQvxiDm0uy7IaQQz0CDFr6zIPzLJdUqTYbGZRtAx0uEVATK3Ej
	nCruWPp6CGJnMIDLOYeYo1XyILsqt1Ng98F3kD1rdfDlRYawN12/esFsRuOBcsiofsl9
	SqNQ==
MIME-Version: 1.0
Received: by 10.180.100.133 with SMTP id ey5mr21250894wib.4.1347328171184;
	Mon, 10 Sep 2012 18:49:31 -0700 (PDT)
Received: by 10.216.234.229 with HTTP; Mon, 10 Sep 2012 18:49:31 -0700 (PDT)
X-Originating-IP: [171.71.27.79]
In-Reply-To: <CANSvah6nWfKP9-PLSkhbFcO2ONmfj5Hhs-+3r0MhjOUHU1qNfg@mail.gmail.com>
References: <CANSvah6PU5SOKd19qfbvTXvz4spcPYVUQHmiirmm5hPvmzR+pg@mail.gmail.com>
	<CC741C8D.4B3AF%keir@xen.org>
	<CANSvah6nWfKP9-PLSkhbFcO2ONmfj5Hhs-+3r0MhjOUHU1qNfg@mail.gmail.com>
Date: Mon, 10 Sep 2012 18:49:31 -0700
Message-ID: <CAB10MZDy0zTQNO5APyWMgbhiKw+4uXZ2pYMKHqJ3MNKR5gLjjA@mail.gmail.com>
From: Aravindh Puthiyaparambil <aravindh@virtuata.com>
To: Steven Maresca <steve@zentific.com>
X-Gm-Message-State: ALoCoQlyehopyNtpWeepbQvrXfroU7v4MC4bXSCQ/cJDUU0TmeOnixcbjRRrrPfHRgaRYmMhYGP1
Cc: Keir Fraser <keir@xen.org>, andres@lagarcavilla.org,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] mem_event: fix regression affecting CR3,
 CR4 memory events
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Sep 10, 2012 at 3:06 PM, Steven Maresca <steve@zentific.com> wrote:
> On Mon, Sep 10, 2012 at 5:39 PM, Keir Fraser <keir@xen.org> wrote:
>> On 10/09/2012 22:20, "Steven Maresca" <steve@zentific.com> wrote:
>>
>>> Given the refactoring in the commit related to the regression
>>> http://xenbits.xen.org/hg/xen-unstable.hg/rev/1276926e3795, it seemed
>>> (to me anyway) that inserting calls as shown in the patch would be
>>> cleaner, but I can definitely come up with some drawbacks.  However, I
>>> wanted to get this fixed for 4.2 if at all possible, so I wanted to
>>> send regardless.
>>>
>>> In terms of drawbacks, this will require some ifdefs for x86_64, for example.
>>>
>>> Any suggestions for the cleanest means of achieving the same in vmx.c?
>>
>> I don't understand this at all. The original commit moved some CR handling
>> to common HVM code. Your patch adds some mem_event calls into that common
>> HVM code. What would need to be "achieved" in vmx.c? What ifdefs would be
>> required for x86_64?
>>
>>  -- Keir
>>
>>
>
> Keir,
>
> In the process of moving CR handling to common code, that commit
> removed calls to hvm_memory_event_cr3() and hvm_memory_event_cr4().
> Without some patch restoring the calls to those two functions, current
> xen-unstable and xen-4.2-testing only reference them as function
> prototypes and function definitions -- there are no calls whatsoever.
>
> I only mentioned an ifdef relative to x86_64 because of the #ifdef
> __x86_64__  around the function definitions. ( I know in the hvm.h
> itself they're just empty inline functions if not __x86_64__. )
>
> Regarding vmx.c: hvm_memory_event_cr0 is called within vmx_cr_access.
> The patch I sent restoring the calls to hvm_memory_event_cr4 and
> hvm_memory_event_cr3 could be treated similarly, that's all.

Looks good to me.
Acked-by: Aravindh Puthiyaparambil <aravindh@virtuata.com>

Cheers,
Aravindh

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 11 01:49:58 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 2012 01:49:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TBFba-0000HR-Ij; Tue, 11 Sep 2012 01:49:34 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <aravindh@virtuata.com>) id 1TBFbY-0000HM-Tj
	for xen-devel@lists.xen.org; Tue, 11 Sep 2012 01:49:33 +0000
Received: from [85.158.143.99:14453] by server-3.bemta-4.messagelabs.com id
	1B/59-08232-CA89E405; Tue, 11 Sep 2012 01:49:32 +0000
X-Env-Sender: aravindh@virtuata.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1347328171!29614448!1
X-Originating-IP: [74.125.82.51]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25563 invoked from network); 11 Sep 2012 01:49:31 -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;
	11 Sep 2012 01:49:31 -0000
Received: by wgbed3 with SMTP id ed3so1756543wgb.32
	for <xen-devel@lists.xen.org>; Mon, 10 Sep 2012 18:49:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=virtuata.com; s=google;
	h=mime-version:x-originating-ip:in-reply-to:references:date
	:message-id:subject:from:to:cc:content-type;
	bh=qa9HjoKoVLJosuVp0ECe9f6Scv7QBa8E/bGBX1CzOCY=;
	b=Vv6jhPSn867sVFdmOi+wnaw9kqX/UeJgL5FLoeFFX3RP7wkX3JZbTks974ABDgCmi0
	dWuOxkj0l15nexGxTpOwewGYp+YDB8Azejheg+Ehtu0I2NkHa7xpRIEXAMZwCUPK1hJb
	3ju31iNuFbe4ydP1pIjQyR3vf7iUBc5Q1g3HA=
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=qa9HjoKoVLJosuVp0ECe9f6Scv7QBa8E/bGBX1CzOCY=;
	b=Ji/uRtKt/eEXU2lkO2sHYqIGqV6W8Cd1WU8za1WM5pQswkkf8ulxPqPJB+cg9hZ6AJ
	d0CZbpTQFTEG+3LtZo+EBXehK0w4cT3kw1fDXTevsywJWF2+ZRYsSH1xvHG336SYNpPK
	yINA2Ghak/vpP8/YkceoGgnLhEMEbSNpxsP9xfuqwhBI1f70ymFbf0mkQCodig4qyjyP
	uStCyY6iye7LR8YR5rmQvxiDm0uy7IaQQz0CDFr6zIPzLJdUqTYbGZRtAx0uEVATK3Ej
	nCruWPp6CGJnMIDLOYeYo1XyILsqt1Ng98F3kD1rdfDlRYawN12/esFsRuOBcsiofsl9
	SqNQ==
MIME-Version: 1.0
Received: by 10.180.100.133 with SMTP id ey5mr21250894wib.4.1347328171184;
	Mon, 10 Sep 2012 18:49:31 -0700 (PDT)
Received: by 10.216.234.229 with HTTP; Mon, 10 Sep 2012 18:49:31 -0700 (PDT)
X-Originating-IP: [171.71.27.79]
In-Reply-To: <CANSvah6nWfKP9-PLSkhbFcO2ONmfj5Hhs-+3r0MhjOUHU1qNfg@mail.gmail.com>
References: <CANSvah6PU5SOKd19qfbvTXvz4spcPYVUQHmiirmm5hPvmzR+pg@mail.gmail.com>
	<CC741C8D.4B3AF%keir@xen.org>
	<CANSvah6nWfKP9-PLSkhbFcO2ONmfj5Hhs-+3r0MhjOUHU1qNfg@mail.gmail.com>
Date: Mon, 10 Sep 2012 18:49:31 -0700
Message-ID: <CAB10MZDy0zTQNO5APyWMgbhiKw+4uXZ2pYMKHqJ3MNKR5gLjjA@mail.gmail.com>
From: Aravindh Puthiyaparambil <aravindh@virtuata.com>
To: Steven Maresca <steve@zentific.com>
X-Gm-Message-State: ALoCoQlyehopyNtpWeepbQvrXfroU7v4MC4bXSCQ/cJDUU0TmeOnixcbjRRrrPfHRgaRYmMhYGP1
Cc: Keir Fraser <keir@xen.org>, andres@lagarcavilla.org,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] mem_event: fix regression affecting CR3,
 CR4 memory events
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Sep 10, 2012 at 3:06 PM, Steven Maresca <steve@zentific.com> wrote:
> On Mon, Sep 10, 2012 at 5:39 PM, Keir Fraser <keir@xen.org> wrote:
>> On 10/09/2012 22:20, "Steven Maresca" <steve@zentific.com> wrote:
>>
>>> Given the refactoring in the commit related to the regression
>>> http://xenbits.xen.org/hg/xen-unstable.hg/rev/1276926e3795, it seemed
>>> (to me anyway) that inserting calls as shown in the patch would be
>>> cleaner, but I can definitely come up with some drawbacks.  However, I
>>> wanted to get this fixed for 4.2 if at all possible, so I wanted to
>>> send regardless.
>>>
>>> In terms of drawbacks, this will require some ifdefs for x86_64, for example.
>>>
>>> Any suggestions for the cleanest means of achieving the same in vmx.c?
>>
>> I don't understand this at all. The original commit moved some CR handling
>> to common HVM code. Your patch adds some mem_event calls into that common
>> HVM code. What would need to be "achieved" in vmx.c? What ifdefs would be
>> required for x86_64?
>>
>>  -- Keir
>>
>>
>
> Keir,
>
> In the process of moving CR handling to common code, that commit
> removed calls to hvm_memory_event_cr3() and hvm_memory_event_cr4().
> Without some patch restoring the calls to those two functions, current
> xen-unstable and xen-4.2-testing only reference them as function
> prototypes and function definitions -- there are no calls whatsoever.
>
> I only mentioned an ifdef relative to x86_64 because of the #ifdef
> __x86_64__  around the function definitions. ( I know in the hvm.h
> itself they're just empty inline functions if not __x86_64__. )
>
> Regarding vmx.c: hvm_memory_event_cr0 is called within vmx_cr_access.
> The patch I sent restoring the calls to hvm_memory_event_cr4 and
> hvm_memory_event_cr3 could be treated similarly, that's all.

Looks good to me.
Acked-by: Aravindh Puthiyaparambil <aravindh@virtuata.com>

Cheers,
Aravindh

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 11 02:41:23 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 2012 02:41:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TBGPH-0000we-Oh; Tue, 11 Sep 2012 02:40:55 +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 1TBGPG-0000wZ-6R
	for xen-devel@lists.xen.org; Tue, 11 Sep 2012 02:40:54 +0000
Received: from [85.158.138.51:8984] by server-4.bemta-3.messagelabs.com id
	BD/7D-24831-5B4AE405; Tue, 11 Sep 2012 02:40:53 +0000
X-Env-Sender: msw@amazon.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1347331251!29707707!1
X-Originating-IP: [72.21.198.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNzIuMjEuMTk4LjI1ID0+IDE3NDI4MQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21217 invoked from network); 11 Sep 2012 02:40:52 -0000
Received: from smtp-fw-4101.amazon.com (HELO smtp-fw-4101.amazon.com)
	(72.21.198.25)
	by server-16.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Sep 2012 02:40: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=1347331252; x=1378867252;
	h=date:from:to:cc:subject:message-id:references:
	mime-version:in-reply-to;
	bh=SCTI3SP6q5xtJqlW7puBgupa5QIdLkF8ZY4yMNgfx2E=;
	b=ftz88Jn8p8eFxjD8cc5EvnN1cWI8hHcC2M9aNKfN/jq8Lkhz14HZFsmW
	rcqhmJ/CFI7Ei7B4yq5jn3TiwqIQKw==;
X-IronPort-AV: E=Sophos;i="4.80,401,1344211200"; d="scan'208";a="794515465"
Received: from smtp-in-9003.sea19.amazon.com ([10.186.104.20])
	by smtp-border-fw-out-4101.iad4.amazon.com with
	ESMTP/TLS/DHE-RSA-AES256-SHA; 11 Sep 2012 02:40:49 +0000
Received: from ex10-hub-9004.ant.amazon.com (ex10-hub-9004.ant.amazon.com
	[10.185.137.182])
	by smtp-in-9003.sea19.amazon.com (8.13.8/8.13.8) with ESMTP id
	q8B2emil005535
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL);
	Tue, 11 Sep 2012 02:40:48 GMT
Received: from u002268147cd4502c336d.ant.amazon.com (10.224.80.43) by
	ex10-hub-9004.ant.amazon.com (10.185.137.182) with Microsoft SMTP
	Server id 14.2.247.3; Mon, 10 Sep 2012 19:40:47 -0700
Received: by u002268147cd4502c336d.ant.amazon.com (sSMTP sendmail emulation); 
	Mon, 10 Sep 2012 19:40:47 -0700
Date: Mon, 10 Sep 2012 19:40:47 -0700
From: Matt Wilson <msw@amazon.com>
To: "Justin M. Forbes" <jmforbes@linuxtx.org>
Message-ID: <20120911024047.GA7620@u002268147cd4502c336d.ant.amazon.com>
References: <1347018043-21252-1-git-send-email-stefan.bader@canonical.com>
	<504A05B00200007800099C7B@nat28.tlf.novell.com>
	<5049F4E9.9050306@canonical.com>
	<504A1A950200007800099D4C@nat28.tlf.novell.com>
	<20120907142251.GA20096@linuxtx.org>
	<504A32800200007800099E40@nat28.tlf.novell.com>
	<1347033622.2980.12.camel@fedora64.linuxtx.org>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1347033622.2980.12.camel@fedora64.linuxtx.org>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Stefan Bader <stefan.bader@canonical.com>,
	Jan Beulich <JBeulich@suse.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH/RFC] Fix xsave bug on older Xen hypervisors
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Sep 07, 2012 at 11:00:22AM -0500, Justin M. Forbes wrote:
> On Fri, 2012-09-07 at 16:44 +0100, Jan Beulich wrote:
> > 
> > All of this still doesn't provide evidence that a plain upstream
> > kernel is actually having any problems in the first place. Further,
> > if you say EC2 has a crippled hypervisor patch - is that patch
> > available for looking at somewhere?
> 
> Yes, I can verify that a plain upstream kernel has problems in the first
> place, which is why we are carrying a patch to simply disable xsave all
> together in the pv guest.
> EC2 is not carrying a patch to cripple the hypervisor, there was an old
> xen bug that makes all this fail.  The correct fix for that bug is to
> patch the hypervisor, but they have not done so. Upstream xen has had
> the fix for quite some time, but that doesn't change the fact that a lot
> of xen guest usage these days is on EC2.  This is no different than
> putting in a quirk to work around a firmware bug in common use.

I've done some testing and have results that indicate otherwise. The
out-of-tree xen_write_cr4() patch is not needed as of 2.6.39. I tested
3.2.21 on a machine that has XSAVE capabilities:

[ec2-user@ip-10-160-18-80 ~]$ cpuid -1 -i | grep -i xsave/xstor
      XSAVE/XSTOR states                      = true
      OS-enabled XSAVE/XSTOR                  = false

on an older hypervisor build:

[ec2-user@ip-10-160-18-80 ~]$ cat /sys/hypervisor/version/major
3
[ec2-user@ip-10-160-18-80 ~]$ cat /sys/hypervisor/version/minor
0

and it boots without a problem. This patch correctly detects that the
hypervisor supports XSAVE by testing for OSXSAVE:

commit 947ccf9c3c30307b774af3666ee74fcd9f47f646
Author:     Shan Haitao <haitao.shan@intel.com>
AuthorDate: Tue Nov 9 11:43:36 2010 -0800
Commit:     Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
CommitDate: Wed Apr 6 08:31:13 2011 -0400

    xen: Allow PV-OPS kernel to detect whether XSAVE is supported
    
    Xen fails to mask XSAVE from the cpuid feature, despite not historically
    supporting guest use of XSAVE.  However, now that XSAVE support has been
    added to Xen, we need to reliably detect its presence.
    
    The most reliable way to do this is to look at the OSXSAVE feature in
    cpuid which is set iff the OS (Xen, in this case), has set
    CR4.OSXSAVE.

Matt

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 11 02:41:23 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 2012 02:41:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TBGPH-0000we-Oh; Tue, 11 Sep 2012 02:40:55 +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 1TBGPG-0000wZ-6R
	for xen-devel@lists.xen.org; Tue, 11 Sep 2012 02:40:54 +0000
Received: from [85.158.138.51:8984] by server-4.bemta-3.messagelabs.com id
	BD/7D-24831-5B4AE405; Tue, 11 Sep 2012 02:40:53 +0000
X-Env-Sender: msw@amazon.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1347331251!29707707!1
X-Originating-IP: [72.21.198.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNzIuMjEuMTk4LjI1ID0+IDE3NDI4MQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21217 invoked from network); 11 Sep 2012 02:40:52 -0000
Received: from smtp-fw-4101.amazon.com (HELO smtp-fw-4101.amazon.com)
	(72.21.198.25)
	by server-16.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Sep 2012 02:40: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=1347331252; x=1378867252;
	h=date:from:to:cc:subject:message-id:references:
	mime-version:in-reply-to;
	bh=SCTI3SP6q5xtJqlW7puBgupa5QIdLkF8ZY4yMNgfx2E=;
	b=ftz88Jn8p8eFxjD8cc5EvnN1cWI8hHcC2M9aNKfN/jq8Lkhz14HZFsmW
	rcqhmJ/CFI7Ei7B4yq5jn3TiwqIQKw==;
X-IronPort-AV: E=Sophos;i="4.80,401,1344211200"; d="scan'208";a="794515465"
Received: from smtp-in-9003.sea19.amazon.com ([10.186.104.20])
	by smtp-border-fw-out-4101.iad4.amazon.com with
	ESMTP/TLS/DHE-RSA-AES256-SHA; 11 Sep 2012 02:40:49 +0000
Received: from ex10-hub-9004.ant.amazon.com (ex10-hub-9004.ant.amazon.com
	[10.185.137.182])
	by smtp-in-9003.sea19.amazon.com (8.13.8/8.13.8) with ESMTP id
	q8B2emil005535
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL);
	Tue, 11 Sep 2012 02:40:48 GMT
Received: from u002268147cd4502c336d.ant.amazon.com (10.224.80.43) by
	ex10-hub-9004.ant.amazon.com (10.185.137.182) with Microsoft SMTP
	Server id 14.2.247.3; Mon, 10 Sep 2012 19:40:47 -0700
Received: by u002268147cd4502c336d.ant.amazon.com (sSMTP sendmail emulation); 
	Mon, 10 Sep 2012 19:40:47 -0700
Date: Mon, 10 Sep 2012 19:40:47 -0700
From: Matt Wilson <msw@amazon.com>
To: "Justin M. Forbes" <jmforbes@linuxtx.org>
Message-ID: <20120911024047.GA7620@u002268147cd4502c336d.ant.amazon.com>
References: <1347018043-21252-1-git-send-email-stefan.bader@canonical.com>
	<504A05B00200007800099C7B@nat28.tlf.novell.com>
	<5049F4E9.9050306@canonical.com>
	<504A1A950200007800099D4C@nat28.tlf.novell.com>
	<20120907142251.GA20096@linuxtx.org>
	<504A32800200007800099E40@nat28.tlf.novell.com>
	<1347033622.2980.12.camel@fedora64.linuxtx.org>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1347033622.2980.12.camel@fedora64.linuxtx.org>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Stefan Bader <stefan.bader@canonical.com>,
	Jan Beulich <JBeulich@suse.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH/RFC] Fix xsave bug on older Xen hypervisors
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Sep 07, 2012 at 11:00:22AM -0500, Justin M. Forbes wrote:
> On Fri, 2012-09-07 at 16:44 +0100, Jan Beulich wrote:
> > 
> > All of this still doesn't provide evidence that a plain upstream
> > kernel is actually having any problems in the first place. Further,
> > if you say EC2 has a crippled hypervisor patch - is that patch
> > available for looking at somewhere?
> 
> Yes, I can verify that a plain upstream kernel has problems in the first
> place, which is why we are carrying a patch to simply disable xsave all
> together in the pv guest.
> EC2 is not carrying a patch to cripple the hypervisor, there was an old
> xen bug that makes all this fail.  The correct fix for that bug is to
> patch the hypervisor, but they have not done so. Upstream xen has had
> the fix for quite some time, but that doesn't change the fact that a lot
> of xen guest usage these days is on EC2.  This is no different than
> putting in a quirk to work around a firmware bug in common use.

I've done some testing and have results that indicate otherwise. The
out-of-tree xen_write_cr4() patch is not needed as of 2.6.39. I tested
3.2.21 on a machine that has XSAVE capabilities:

[ec2-user@ip-10-160-18-80 ~]$ cpuid -1 -i | grep -i xsave/xstor
      XSAVE/XSTOR states                      = true
      OS-enabled XSAVE/XSTOR                  = false

on an older hypervisor build:

[ec2-user@ip-10-160-18-80 ~]$ cat /sys/hypervisor/version/major
3
[ec2-user@ip-10-160-18-80 ~]$ cat /sys/hypervisor/version/minor
0

and it boots without a problem. This patch correctly detects that the
hypervisor supports XSAVE by testing for OSXSAVE:

commit 947ccf9c3c30307b774af3666ee74fcd9f47f646
Author:     Shan Haitao <haitao.shan@intel.com>
AuthorDate: Tue Nov 9 11:43:36 2010 -0800
Commit:     Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
CommitDate: Wed Apr 6 08:31:13 2011 -0400

    xen: Allow PV-OPS kernel to detect whether XSAVE is supported
    
    Xen fails to mask XSAVE from the cpuid feature, despite not historically
    supporting guest use of XSAVE.  However, now that XSAVE support has been
    added to Xen, we need to reliably detect its presence.
    
    The most reliable way to do this is to look at the OSXSAVE feature in
    cpuid which is set iff the OS (Xen, in this case), has set
    CR4.OSXSAVE.

Matt

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 11 02:50:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 2012 02:50: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 1TBGXr-000166-PP; Tue, 11 Sep 2012 02:49:47 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <fajar@fajar.net>) id 1TBGXp-000161-Ko
	for xen-devel@lists.xen.org; Tue, 11 Sep 2012 02:49:45 +0000
X-Env-Sender: fajar@fajar.net
X-Msg-Ref: server-4.tower-27.messagelabs.com!1347331778!9903352!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-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5468 invoked from network); 11 Sep 2012 02:49:39 -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;
	11 Sep 2012 02:49:39 -0000
Received: by obbta14 with SMTP id ta14so50715obb.32
	for <xen-devel@lists.xen.org>; Mon, 10 Sep 2012 19:49:37 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type:x-gm-message-state;
	bh=3IMWZvS7T52ArBGhK6mLfrIwUMgqlLPl1xjrB4uALWs=;
	b=EPql/Trvv4S3rCbFd/G6HJ5bxG2hgazmSjK54+E8rbHWgFROhSbNvVOjCJrFK0z8vz
	Cv8revkGbodJ3lN8/GGq9Js2ySvSPa6gXuaW9q+TTv5EZs/asbzBt8WpHFvP4Ta5KiQ9
	sryJ07rBqb25pyu5+IlFI0SaVsBHOu+MJQF6aM7J4sTf2QOpJNTaiJ/JKojtdUbanWgX
	X7wWj+D1Cw6RxpvTg+DqzuYCoWeJWW2Kqcg3u9qJkXrB1wPWds6wQhwXZ91UdtqpR4LT
	m2M5by038PiEUMUhYD0pb6+IixamZiG+t7YzGCDu0bSN8NJ5vYOtm8pW262+lx74Ci7R
	QU2A==
MIME-Version: 1.0
Received: by 10.182.192.69 with SMTP id he5mr16170624obc.84.1347331777683;
	Mon, 10 Sep 2012 19:49:37 -0700 (PDT)
Received: by 10.60.6.230 with HTTP; Mon, 10 Sep 2012 19:49:37 -0700 (PDT)
In-Reply-To: <CAEQjb-QG71pnKQsWP1LLhpzXjkJUi+oRjFzLGZZZZSDJqo_BJA@mail.gmail.com>
References: <CAEQjb-TO9wy74up6pGfaRj+FQH8SPJtLXngM70ivWwWaQ53QPA@mail.gmail.com>
	<20120910192456.GA28298@phenom.dumpdata.com>
	<CAEQjb-QG71pnKQsWP1LLhpzXjkJUi+oRjFzLGZZZZSDJqo_BJA@mail.gmail.com>
Date: Tue, 11 Sep 2012 09:49:37 +0700
Message-ID: <CAG1y0scdfRzY97u7tty61Z2rFSqXzFxdVOw6WLk0MTKAZ+VJpA@mail.gmail.com>
From: "Fajar A. Nugraha" <list@fajar.net>
To: Bei Guan <gbtju85@gmail.com>
X-Gm-Message-State: ALoCoQlP0sSIdh7V+sTKSEzZdhj1c27Fgvvc4/vWEIErAj9rvQggiU3ROfn0PFuJAcAtGd0mP9jL
Cc: Konrad Rzeszutek Wilk <konrad@kernel.org>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Any news or plan about Xen support the APU
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Sep 11, 2012 at 8:27 AM, Bei Guan <gbtju85@gmail.com> wrote:
> Hi Konrad,
>
> Thank you very much for your reply. I'm not hitting any issues.
>
> AMD's APU is a new kind of processing device, which integrates a CPU and a
> GPU on the same die. I want to know whether Xen has supported the
> virtualization of the APU processors? If yes, I can run something
> applications in the Xen PV VMs to use this kind of new CPU device.

AFAIK at this point AMD APUs are simply CPU + GPU. Even though they're
in the same die, they're basically different devices. So for the GPU
part, treat it like any other GPU. Which means you could PROBABLY
passthru it to ONE domU, but that's it.

AMD's plan for the future is make a chip which can function as CPU or
GPU as needed, but that hasn't happened yet.

-- 
Fajar

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 11 02:50:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 2012 02:50: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 1TBGXr-000166-PP; Tue, 11 Sep 2012 02:49:47 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <fajar@fajar.net>) id 1TBGXp-000161-Ko
	for xen-devel@lists.xen.org; Tue, 11 Sep 2012 02:49:45 +0000
X-Env-Sender: fajar@fajar.net
X-Msg-Ref: server-4.tower-27.messagelabs.com!1347331778!9903352!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-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5468 invoked from network); 11 Sep 2012 02:49:39 -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;
	11 Sep 2012 02:49:39 -0000
Received: by obbta14 with SMTP id ta14so50715obb.32
	for <xen-devel@lists.xen.org>; Mon, 10 Sep 2012 19:49:37 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type:x-gm-message-state;
	bh=3IMWZvS7T52ArBGhK6mLfrIwUMgqlLPl1xjrB4uALWs=;
	b=EPql/Trvv4S3rCbFd/G6HJ5bxG2hgazmSjK54+E8rbHWgFROhSbNvVOjCJrFK0z8vz
	Cv8revkGbodJ3lN8/GGq9Js2ySvSPa6gXuaW9q+TTv5EZs/asbzBt8WpHFvP4Ta5KiQ9
	sryJ07rBqb25pyu5+IlFI0SaVsBHOu+MJQF6aM7J4sTf2QOpJNTaiJ/JKojtdUbanWgX
	X7wWj+D1Cw6RxpvTg+DqzuYCoWeJWW2Kqcg3u9qJkXrB1wPWds6wQhwXZ91UdtqpR4LT
	m2M5by038PiEUMUhYD0pb6+IixamZiG+t7YzGCDu0bSN8NJ5vYOtm8pW262+lx74Ci7R
	QU2A==
MIME-Version: 1.0
Received: by 10.182.192.69 with SMTP id he5mr16170624obc.84.1347331777683;
	Mon, 10 Sep 2012 19:49:37 -0700 (PDT)
Received: by 10.60.6.230 with HTTP; Mon, 10 Sep 2012 19:49:37 -0700 (PDT)
In-Reply-To: <CAEQjb-QG71pnKQsWP1LLhpzXjkJUi+oRjFzLGZZZZSDJqo_BJA@mail.gmail.com>
References: <CAEQjb-TO9wy74up6pGfaRj+FQH8SPJtLXngM70ivWwWaQ53QPA@mail.gmail.com>
	<20120910192456.GA28298@phenom.dumpdata.com>
	<CAEQjb-QG71pnKQsWP1LLhpzXjkJUi+oRjFzLGZZZZSDJqo_BJA@mail.gmail.com>
Date: Tue, 11 Sep 2012 09:49:37 +0700
Message-ID: <CAG1y0scdfRzY97u7tty61Z2rFSqXzFxdVOw6WLk0MTKAZ+VJpA@mail.gmail.com>
From: "Fajar A. Nugraha" <list@fajar.net>
To: Bei Guan <gbtju85@gmail.com>
X-Gm-Message-State: ALoCoQlP0sSIdh7V+sTKSEzZdhj1c27Fgvvc4/vWEIErAj9rvQggiU3ROfn0PFuJAcAtGd0mP9jL
Cc: Konrad Rzeszutek Wilk <konrad@kernel.org>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Any news or plan about Xen support the APU
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Sep 11, 2012 at 8:27 AM, Bei Guan <gbtju85@gmail.com> wrote:
> Hi Konrad,
>
> Thank you very much for your reply. I'm not hitting any issues.
>
> AMD's APU is a new kind of processing device, which integrates a CPU and a
> GPU on the same die. I want to know whether Xen has supported the
> virtualization of the APU processors? If yes, I can run something
> applications in the Xen PV VMs to use this kind of new CPU device.

AFAIK at this point AMD APUs are simply CPU + GPU. Even though they're
in the same die, they're basically different devices. So for the GPU
part, treat it like any other GPU. Which means you could PROBABLY
passthru it to ONE domU, but that's it.

AMD's plan for the future is make a chip which can function as CPU or
GPU as needed, but that hasn't happened yet.

-- 
Fajar

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 11 03:36:51 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 2012 03:36:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TBHGx-00021Q-FR; Tue, 11 Sep 2012 03:36:23 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1TBHGv-00021L-Bx
	for xen-devel@lists.xensource.com; Tue, 11 Sep 2012 03:36:21 +0000
Received: from [85.158.143.99:32908] by server-1.bemta-4.messagelabs.com id
	C7/72-12504-4B1BE405; Tue, 11 Sep 2012 03:36:20 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1347334579!24347135!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDg1MTY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15198 invoked from network); 11 Sep 2012 03:36: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;
	11 Sep 2012 03:36:19 -0000
X-IronPort-AV: E=Sophos;i="4.80,401,1344211200"; d="scan'208";a="14457632"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Sep 2012 03:36:18 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Tue, 11 Sep 2012 04:36: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 1TBHGr-00023P-N0;
	Tue, 11 Sep 2012 03:36:17 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1TBHGr-0003Px-8O;
	Tue, 11 Sep 2012 04:36:17 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-13668-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Tue, 11 Sep 2012 04:36:17 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13668: 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 13668 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13668/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore            fail   like 13661
 test-i386-i386-xl-qemuu-winxpsp3  9 guest-localmigrate         fail like 13661
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail like 13661
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail like 13661

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-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
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass

version targeted for testing:
 xen                  7d770de90b7f
baseline version:
 xen                  a64f4e107951

------------------------------------------------------------
People who touched revisions under test:
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <Ian.Jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Keir Fraser <keir@xen.org>
  Matt Wilson <msw@amazon.com>
  Olaf Hering <olaf@aepfle.de>
  Pasi K?rkk?inen <pasik@iki.fi>
  Roger Pau Monne <roger.pau@citrix.com>
  Wei Wang <wei.wang2@amd.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                                 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                                     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=7d770de90b7f
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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 7d770de90b7f
+ branch=xen-unstable
+ revision=7d770de90b7f
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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 7d770de90b7f ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg
pushing to ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg
searching for changes
remote: adding changesets
remote: adding manifests
remote: adding file changes
remote: added 18 changesets with 22 changes to 18 files

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 11 03:36:51 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 2012 03:36:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TBHGx-00021Q-FR; Tue, 11 Sep 2012 03:36:23 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1TBHGv-00021L-Bx
	for xen-devel@lists.xensource.com; Tue, 11 Sep 2012 03:36:21 +0000
Received: from [85.158.143.99:32908] by server-1.bemta-4.messagelabs.com id
	C7/72-12504-4B1BE405; Tue, 11 Sep 2012 03:36:20 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1347334579!24347135!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDg1MTY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15198 invoked from network); 11 Sep 2012 03:36: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;
	11 Sep 2012 03:36:19 -0000
X-IronPort-AV: E=Sophos;i="4.80,401,1344211200"; d="scan'208";a="14457632"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Sep 2012 03:36:18 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Tue, 11 Sep 2012 04:36: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 1TBHGr-00023P-N0;
	Tue, 11 Sep 2012 03:36:17 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1TBHGr-0003Px-8O;
	Tue, 11 Sep 2012 04:36:17 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-13668-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Tue, 11 Sep 2012 04:36:17 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13668: 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 13668 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13668/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore            fail   like 13661
 test-i386-i386-xl-qemuu-winxpsp3  9 guest-localmigrate         fail like 13661
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail like 13661
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail like 13661

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-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
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass

version targeted for testing:
 xen                  7d770de90b7f
baseline version:
 xen                  a64f4e107951

------------------------------------------------------------
People who touched revisions under test:
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <Ian.Jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Keir Fraser <keir@xen.org>
  Matt Wilson <msw@amazon.com>
  Olaf Hering <olaf@aepfle.de>
  Pasi K?rkk?inen <pasik@iki.fi>
  Roger Pau Monne <roger.pau@citrix.com>
  Wei Wang <wei.wang2@amd.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                                 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                                     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=7d770de90b7f
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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 7d770de90b7f
+ branch=xen-unstable
+ revision=7d770de90b7f
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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 7d770de90b7f ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg
pushing to ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg
searching for changes
remote: adding changesets
remote: adding manifests
remote: adding file changes
remote: added 18 changesets with 22 changes to 18 files

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 11 03:58:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 2012 03: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 1TBHbY-0002CZ-Em; Tue, 11 Sep 2012 03:57:40 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <steve@zentific.com>) id 1TBHbW-0002CU-0f
	for xen-devel@lists.xen.org; Tue, 11 Sep 2012 03:57:38 +0000
X-Env-Sender: steve@zentific.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1347335850!9048068!1
X-Originating-IP: [209.85.210.173]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
  RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9987 invoked from network); 11 Sep 2012 03:57:31 -0000
Received: from mail-iy0-f173.google.com (HELO mail-iy0-f173.google.com)
	(209.85.210.173)
	by server-16.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Sep 2012 03:57:31 -0000
Received: by iakx26 with SMTP id x26so68990iak.32
	for <xen-devel@lists.xen.org>; Mon, 10 Sep 2012 20:57:29 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to
	:cc:content-type:x-gm-message-state;
	bh=QvI+LTG9O7xG8usGpqLL7iadHVHoCpny1XmMby1m12o=;
	b=Tw4iP8fJvcNtNtvMS5C1a4T2G+BTBUC/SoDW9RdjVBJDDXWg1POV5u+MpPdgLFuhl/
	Dy2cl/3d+hWSpC5dkVlBB/nfapM/qnWrdTQVxGN2hlOkBuxMyAcoOMpiDoOUX94Tr7L+
	BO/4WF2ZvrigePsC2XVh9cW+It7PPNqXVXwdYIA1czdLHOAR6UQc9tdY7XtYGAOnG2Uz
	djwkJa1p68T8+DsygWPsPGTlTH5sSVJcFqCdbA5tuuYITMIQkZ/u9m0iM9wGF2lxYZK0
	t/1vAEKyqEoJiNubWXENnG3hgMmpTOzIXTlRG8IgdlkfFlkfR5aK134TZRld++72AUz/
	ZUfA==
Received: by 10.50.173.68 with SMTP id bi4mr5800842igc.69.1347335849787; Mon,
	10 Sep 2012 20:57:29 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.64.17.38 with HTTP; Mon, 10 Sep 2012 20:56:49 -0700 (PDT)
In-Reply-To: <CAB10MZDy0zTQNO5APyWMgbhiKw+4uXZ2pYMKHqJ3MNKR5gLjjA@mail.gmail.com>
References: <CANSvah6PU5SOKd19qfbvTXvz4spcPYVUQHmiirmm5hPvmzR+pg@mail.gmail.com>
	<CC741C8D.4B3AF%keir@xen.org>
	<CANSvah6nWfKP9-PLSkhbFcO2ONmfj5Hhs-+3r0MhjOUHU1qNfg@mail.gmail.com>
	<CAB10MZDy0zTQNO5APyWMgbhiKw+4uXZ2pYMKHqJ3MNKR5gLjjA@mail.gmail.com>
From: Steven Maresca <steve@zentific.com>
Date: Mon, 10 Sep 2012 23:56:49 -0400
Message-ID: <CANSvah4NN05Zimm2BmKO9ofC04G+D7Svrg+2xwp0yM16Cn3CRw@mail.gmail.com>
To: tim@xen.org
X-Gm-Message-State: ALoCoQmcToQFQTvMfm09UNE4+cfnlKjUheg3QfS1wx70lDpu/g167rS6kv38gC+DwkYsHHfHkD6g
Cc: Aravindh Puthiyaparambil <aravindh@virtuata.com>,
	Keir Fraser <keir@xen.org>, andres@lagarcavilla.org,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] mem_event: fix regression affecting CR3,
 CR4 memory events
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Sep 10, 2012 at 9:49 PM, Aravindh Puthiyaparambil
<aravindh@virtuata.com> wrote:
> On Mon, Sep 10, 2012 at 3:06 PM, Steven Maresca <steve@zentific.com> wrote:
>> On Mon, Sep 10, 2012 at 5:39 PM, Keir Fraser <keir@xen.org> wrote:
>>> On 10/09/2012 22:20, "Steven Maresca" <steve@zentific.com> wrote:
>>>
>>>> Given the refactoring in the commit related to the regression
>>>> http://xenbits.xen.org/hg/xen-unstable.hg/rev/1276926e3795, it seemed
>>>> (to me anyway) that inserting calls as shown in the patch would be
>>>> cleaner, but I can definitely come up with some drawbacks.  However, I
>>>> wanted to get this fixed for 4.2 if at all possible, so I wanted to
>>>> send regardless.
>>>>
>>>> In terms of drawbacks, this will require some ifdefs for x86_64, for example.
>>>>
>>>> Any suggestions for the cleanest means of achieving the same in vmx.c?
>>>
>>> I don't understand this at all. The original commit moved some CR handling
>>> to common HVM code. Your patch adds some mem_event calls into that common
>>> HVM code. What would need to be "achieved" in vmx.c? What ifdefs would be
>>> required for x86_64?
>>>
>>>  -- Keir
>>>
>>>
>>
>> Keir,
>>
>> In the process of moving CR handling to common code, that commit
>> removed calls to hvm_memory_event_cr3() and hvm_memory_event_cr4().
>> Without some patch restoring the calls to those two functions, current
>> xen-unstable and xen-4.2-testing only reference them as function
>> prototypes and function definitions -- there are no calls whatsoever.
>>
>> I only mentioned an ifdef relative to x86_64 because of the #ifdef
>> __x86_64__  around the function definitions. ( I know in the hvm.h
>> itself they're just empty inline functions if not __x86_64__. )
>>
>> Regarding vmx.c: hvm_memory_event_cr0 is called within vmx_cr_access.
>> The patch I sent restoring the calls to hvm_memory_event_cr4 and
>> hvm_memory_event_cr3 could be treated similarly, that's all.
>
> Looks good to me.
> Acked-by: Aravindh Puthiyaparambil <aravindh@virtuata.com>
>
> Cheers,
> Aravindh

Adding Tim Deegan as suggested.

Tim, this is a regression fix for CR3/CR4 memory events
unintentionally removed during some refactoring of HVM CR handling.
If at all possible, for 4.2 inclusion before we officially leave RC.
Acks received from Andres and Aravindh. Thanks to all for the quick
review.

Take care,
Steve

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 11 03:58:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 2012 03: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 1TBHbY-0002CZ-Em; Tue, 11 Sep 2012 03:57:40 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <steve@zentific.com>) id 1TBHbW-0002CU-0f
	for xen-devel@lists.xen.org; Tue, 11 Sep 2012 03:57:38 +0000
X-Env-Sender: steve@zentific.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1347335850!9048068!1
X-Originating-IP: [209.85.210.173]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
  RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9987 invoked from network); 11 Sep 2012 03:57:31 -0000
Received: from mail-iy0-f173.google.com (HELO mail-iy0-f173.google.com)
	(209.85.210.173)
	by server-16.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Sep 2012 03:57:31 -0000
Received: by iakx26 with SMTP id x26so68990iak.32
	for <xen-devel@lists.xen.org>; Mon, 10 Sep 2012 20:57:29 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to
	:cc:content-type:x-gm-message-state;
	bh=QvI+LTG9O7xG8usGpqLL7iadHVHoCpny1XmMby1m12o=;
	b=Tw4iP8fJvcNtNtvMS5C1a4T2G+BTBUC/SoDW9RdjVBJDDXWg1POV5u+MpPdgLFuhl/
	Dy2cl/3d+hWSpC5dkVlBB/nfapM/qnWrdTQVxGN2hlOkBuxMyAcoOMpiDoOUX94Tr7L+
	BO/4WF2ZvrigePsC2XVh9cW+It7PPNqXVXwdYIA1czdLHOAR6UQc9tdY7XtYGAOnG2Uz
	djwkJa1p68T8+DsygWPsPGTlTH5sSVJcFqCdbA5tuuYITMIQkZ/u9m0iM9wGF2lxYZK0
	t/1vAEKyqEoJiNubWXENnG3hgMmpTOzIXTlRG8IgdlkfFlkfR5aK134TZRld++72AUz/
	ZUfA==
Received: by 10.50.173.68 with SMTP id bi4mr5800842igc.69.1347335849787; Mon,
	10 Sep 2012 20:57:29 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.64.17.38 with HTTP; Mon, 10 Sep 2012 20:56:49 -0700 (PDT)
In-Reply-To: <CAB10MZDy0zTQNO5APyWMgbhiKw+4uXZ2pYMKHqJ3MNKR5gLjjA@mail.gmail.com>
References: <CANSvah6PU5SOKd19qfbvTXvz4spcPYVUQHmiirmm5hPvmzR+pg@mail.gmail.com>
	<CC741C8D.4B3AF%keir@xen.org>
	<CANSvah6nWfKP9-PLSkhbFcO2ONmfj5Hhs-+3r0MhjOUHU1qNfg@mail.gmail.com>
	<CAB10MZDy0zTQNO5APyWMgbhiKw+4uXZ2pYMKHqJ3MNKR5gLjjA@mail.gmail.com>
From: Steven Maresca <steve@zentific.com>
Date: Mon, 10 Sep 2012 23:56:49 -0400
Message-ID: <CANSvah4NN05Zimm2BmKO9ofC04G+D7Svrg+2xwp0yM16Cn3CRw@mail.gmail.com>
To: tim@xen.org
X-Gm-Message-State: ALoCoQmcToQFQTvMfm09UNE4+cfnlKjUheg3QfS1wx70lDpu/g167rS6kv38gC+DwkYsHHfHkD6g
Cc: Aravindh Puthiyaparambil <aravindh@virtuata.com>,
	Keir Fraser <keir@xen.org>, andres@lagarcavilla.org,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] mem_event: fix regression affecting CR3,
 CR4 memory events
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Sep 10, 2012 at 9:49 PM, Aravindh Puthiyaparambil
<aravindh@virtuata.com> wrote:
> On Mon, Sep 10, 2012 at 3:06 PM, Steven Maresca <steve@zentific.com> wrote:
>> On Mon, Sep 10, 2012 at 5:39 PM, Keir Fraser <keir@xen.org> wrote:
>>> On 10/09/2012 22:20, "Steven Maresca" <steve@zentific.com> wrote:
>>>
>>>> Given the refactoring in the commit related to the regression
>>>> http://xenbits.xen.org/hg/xen-unstable.hg/rev/1276926e3795, it seemed
>>>> (to me anyway) that inserting calls as shown in the patch would be
>>>> cleaner, but I can definitely come up with some drawbacks.  However, I
>>>> wanted to get this fixed for 4.2 if at all possible, so I wanted to
>>>> send regardless.
>>>>
>>>> In terms of drawbacks, this will require some ifdefs for x86_64, for example.
>>>>
>>>> Any suggestions for the cleanest means of achieving the same in vmx.c?
>>>
>>> I don't understand this at all. The original commit moved some CR handling
>>> to common HVM code. Your patch adds some mem_event calls into that common
>>> HVM code. What would need to be "achieved" in vmx.c? What ifdefs would be
>>> required for x86_64?
>>>
>>>  -- Keir
>>>
>>>
>>
>> Keir,
>>
>> In the process of moving CR handling to common code, that commit
>> removed calls to hvm_memory_event_cr3() and hvm_memory_event_cr4().
>> Without some patch restoring the calls to those two functions, current
>> xen-unstable and xen-4.2-testing only reference them as function
>> prototypes and function definitions -- there are no calls whatsoever.
>>
>> I only mentioned an ifdef relative to x86_64 because of the #ifdef
>> __x86_64__  around the function definitions. ( I know in the hvm.h
>> itself they're just empty inline functions if not __x86_64__. )
>>
>> Regarding vmx.c: hvm_memory_event_cr0 is called within vmx_cr_access.
>> The patch I sent restoring the calls to hvm_memory_event_cr4 and
>> hvm_memory_event_cr3 could be treated similarly, that's all.
>
> Looks good to me.
> Acked-by: Aravindh Puthiyaparambil <aravindh@virtuata.com>
>
> Cheers,
> Aravindh

Adding Tim Deegan as suggested.

Tim, this is a regression fix for CR3/CR4 memory events
unintentionally removed during some refactoring of HVM CR handling.
If at all possible, for 4.2 inclusion before we officially leave RC.
Acks received from Andres and Aravindh. Thanks to all for the quick
review.

Take care,
Steve

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 11 06:59:31 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 2012 06:59:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TBKQt-0003My-Mi; Tue, 11 Sep 2012 06:58:51 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <daniel.lezcano@linaro.org>) id 1TBKQs-0003Mt-Cn
	for xen-devel@lists.xensource.com; Tue, 11 Sep 2012 06:58:50 +0000
Received: from [85.158.138.51:23136] by server-5.bemta-3.messagelabs.com id
	8A/EB-13133-921EE405; Tue, 11 Sep 2012 06:58:49 +0000
X-Env-Sender: daniel.lezcano@linaro.org
X-Msg-Ref: server-2.tower-174.messagelabs.com!1347346728!29827116!1
X-Originating-IP: [74.125.83.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12874 invoked from network); 11 Sep 2012 06:58:48 -0000
Received: from mail-ee0-f43.google.com (HELO mail-ee0-f43.google.com)
	(74.125.83.43)
	by server-2.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Sep 2012 06:58:48 -0000
Received: by eekd4 with SMTP id d4so90833eek.30
	for <xen-devel@lists.xensource.com>;
	Mon, 10 Sep 2012 23:58:48 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=message-id:date:from:user-agent:mime-version:to:cc:subject
	:references:in-reply-to:content-type:content-transfer-encoding
	:x-gm-message-state;
	bh=05T4LAc/WeH6MsGqj2eSdF//CVuCGUfVJ2wfIstIDAQ=;
	b=VYRPQ5OuOkwWqXAdPC7UAGAhy1pPa2SgWeYM1F7Y65n/eCuu6ALMHXf60Rm/dEe6fw
	F7NJ6WQHFMtzU2Ea4Occ24q4ILEE3fAOEPrj9XbD2yKk+pKNyJV+qfmZVh2veUOSBQhj
	/Y5K+q2n2PLCRlaCFe6dqCEdzngUB9B+VE7fq2JMhASdcd3YIGO/mtQT54NXgjcf1/4a
	zSygwB83GAK+PS+GoPLZ2PaLkEvHbMrgCKY+XJic5OKo/oinVk4kX1oWUPY6f8Tj+8aA
	xKy91NCs4ggHzm4d1jwclsvw/TwgzmxugIpxpgdnrwtUtQsWC5eVgiemsHHegKKdRk5q
	vo1g==
Received: by 10.14.224.73 with SMTP id w49mr23887353eep.37.1347346728346;
	Mon, 10 Sep 2012 23:58:48 -0700 (PDT)
Received: from [192.168.10.4] (AToulouse-651-1-192-218.w109-222.abo.wanadoo.fr.
	[109.222.127.218])
	by mx.google.com with ESMTPS id r45sm44308612eem.6.2012.09.10.23.58.45
	(version=SSLv3 cipher=OTHER); Mon, 10 Sep 2012 23:58:47 -0700 (PDT)
Message-ID: <504EE124.3010401@linaro.org>
Date: Tue, 11 Sep 2012 08:58:44 +0200
From: Daniel Lezcano <daniel.lezcano@linaro.org>
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:12.0) Gecko/20120430 Thunderbird/12.0.1
MIME-Version: 1.0
To: John Stultz <john.stultz@linaro.org>
References: <1343164349-28550-1-git-send-email-daniel.lezcano@linaro.org>
	<201209062204.11288.rjw@sisk.pl> <50490920.9070204@linaro.org>
	<201209062318.42874.rjw@sisk.pl> <504A02BD.4000805@linaro.org>
	<504A2D73.3010702@linaro.org> <504A68A0.7010907@linaro.org>
	<504E1FE5.6090502@linaro.org> <504E4343.5070004@linaro.org>
	<504E8372.20904@linaro.org>
In-Reply-To: <504E8372.20904@linaro.org>
X-Gm-Message-State: ALoCoQkeuFP5LTiDcc6R+p496uGMXO9TttFQq/pWl5HfQO1HL3PxLZd2L05XDfuysOFbeDj98mww
Cc: prarit@redhat.com, xen-devel@lists.xensource.com,
	linaro-dev@lists.linaro.org, Peter Zijlstra <a.p.zijlstra@chello.nl>,
	linux-pm@vger.kernel.org, Frederic Weisbecker <fweisbec@gmail.com>,
	richardcochran@gmail.com, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	"Rafael J. Wysocki" <rjw@sisk.pl>, linux-acpi@vger.kernel.org,
	Thomas Gleixner <tglx@linutronix.de>, mingo@kernel.org, lenb@kernel.org
Subject: Re: [Xen-devel] CONFIG_NO_HZ + CONFIG_CPU_IDLE freeze the system
 (Was Re: [PATCH] acpi : remove power from acpi_processor_cx structure)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gMDkvMTEvMjAxMiAwMjoxOCBBTSwgSm9obiBTdHVsdHogd3JvdGU6Cj4gT24gMDkvMTAvMjAx
MiAxMjo0NSBQTSwgRGFuaWVsIExlemNhbm8gd3JvdGU6Cj4+IE9uIDA5LzEwLzIwMTIgMDc6MTQg
UE0sIEpvaG4gU3R1bHR6IHdyb3RlOgo+Pj4gSW4gdGhlIG1lYW50aW1lLCBJJ2xsIHRyeSB0byBy
ZXByb2R1Y2Ugb24gbXkgVDYxLiBJZiB5b3UgY291bGQgc2VuZCBtZQo+Pj4geW91ciAuY29uZmln
LCBJJ2QgYXBwcmVjaWF0ZSBpdC4KPj4gaHR0cDovL3Bhc3RlYmluLmNvbS9xU3hxZmRESwo+Pgo+
PiBUaGUgaGVhZGVyIG9mIHRoZSBjb25maWcgZmlsZSBzaG93cyBmb3IgYSB2My41LXJjNyBiZWNh
dXNlIGl0IGlzIHRoZQo+PiByZXN1bHQgb2YgdGhlIGdpdC1iaXNlY3QuIElmIHlvdSBrZWVwIHRo
aXMgY29uZmlnIGZpbGUgZm9yIHRoZSBsYXRlc3QKPj4ga2VybmVsIHRoYXQgc2hvdWxkIHJlcHJv
ZHVjZSB0aGUgcHJvYmxlbS4KPj4KPj4gTGV0IG1lIGtub3cgaWYgeW91IHdlcmUgYWJsZSB0byBy
ZXByb2R1Y2UgdGhlIHByb2JsZW0uCj4gR3JlYXQhIFdpdGggdGhpcyBJIHdhcyBhYmxlIHRvIHF1
aWNrbHkgcmVwcm9kdWNlIHRoZSBwcm9ibGVtIGFuZCBJIHRoaW5rCj4gSSBoYXZlIGEgZml4LgoK
Q29vbCAhCgo+IFdvdWxkIHlvdSBtaW5kIHRlc3RpbmcgdGhlIGZvbGxvd2luZyBwYXRjaD8gSXQg
c2VlbXMgdG8gcmVzb2x2ZSB0aGUKPiBpc3N1ZSwgYnV0IEkndmUgbm90IHlldCBydW4gaXQgdGhy
b3VnaCBteSB0ZXN0IHN1aXRlIHRvIG1ha2Ugc3VyZSBpdAo+IGRpZG4ndCBicmVhayBhbnl0aGlu
ZyBlbHNlLgoKTm8gcHJvYmxlbSwgSSB3aWxsIHRyeSBpdCB0aGlzIGV2ZW5pbmcuCgpJcyB0aGlz
IHByb2JsZW0gcmVsYXRlZCB0byBhbGwgMzJiaXRzIGFyY2ggPwoKVGhhbmtzICEKCiAgLS0gRGFu
aWVsCgo+IElmIGJvdGggeW91ciBhbmQgbXkgdGVzdGluZyBjb21lcyBiYWNrIG9rLCBJJ2xsIHN1
Ym1pdCBpdCB0byBUaG9tYXMuCj4gCj4gdGhhbmtzCj4gLWpvaG4KPiAKPiBGcm9tIGYxMGEyODVh
NWI1MzJhMTRkMzMzMGY2ZTYwZTRkN2JkNTYyNzkzMmEgTW9uIFNlcCAxNyAwMDowMDowMCAyMDAx
Cj4gRnJvbTogSm9obiBTdHVsdHogPGpvaG4uc3R1bHR6QGxpbmFyby5vcmc+Cj4gRGF0ZTogTW9u
LCAxMCBTZXAgMjAxMiAyMDowMDoxNSAtMDQwMAo+IFN1YmplY3Q6IFtQQVRDSF0gdGltZTogRml4
IHRpbWVla2VwaW5nX2dldF9ucyBvdmVyZmxvdyBvbiAzMmJpdCBzeXN0ZW1zCj4gCj4gRGFuaWVs
IExlemNhbm8gcmVwb3J0ZWQgc2VlaW5nIG11bHRpLXNlY29uZCBzdGFsbHMgZnJvbQo+IGtleWJv
YXJkIGlucHV0IG9uIGhpcyBUNjEgbGFwdG9wIHdoZW4gTk9IWiBhbmQgQ1BVX0lETEUKPiB3ZXJl
IGVuYWJsZWQgb24gYSAzMmJpdCBrZXJuZWwuCj4gCj4gSGUgYmlzZWN0ZWQgdGhlIHByb2JsZW0g
ZG93biB0bwo+IDFlNzVmYThiZTlmYjYxZTFhZjQ2YjViM2IxNzYzNDdhNGM5NThjYTEgKHRpbWU6
IENvbmRlbnNlCj4gdGltZWtlZXBlci54dGltZSBpbnRvIHh0aW1lX3NlYykuCj4gCj4gQWZ0ZXIg
cmVwcm9kdWNpbmcgdGhpcyBpc3N1ZSwgSSBuYXJyb3dlZCB0aGUgcHJvYmxlbSBkb3duCj4gdG8g
dGhlIGZhY3QgdGhhdCB0aW1la2VlcGluZ19nZXRfbnMoKSByZXR1cm5zIGEgNjRiaXQKPiBuc2Vj
IHZhbHVlIHRoYXQgaGFzbid0IGJlZW4gYWNjdW11bGF0ZWQuIEluIHNvbWUgY2FzZXMKPiB0aGlz
IHZhbHVlIHdhcyBiZWluZyB0aGVuIHN0b3JlZCBpbiB0aW1lc3BlYy50dl9uc2VjCj4gKHdoaWNo
IGlzIGEgbG9uZykuCj4gCj4gT24gMzJiaXQgc3lzdGVtcywgV2l0aCBpZGxlIHRpbWVzIGxhcmdl
ciB0aGVuIDQgc2Vjb25kcwo+IChvciBsZXNzLCBkZXBlbmRpbmcgb24gdGhlIHZhbHVlIG9mIHh0
aW1lX25zZWMpLCB0aGUKPiByZXR1cm5lZCBuc2VjIHZhbHVlIHdvdWxkIG92ZXJmbG93IDMyYml0
cy4gVGhpcyBsaW1pdGVkCj4ga2VwdCB0aW1lIGZyb20gaW5jcmVhc2luZywgY2F1c2luZyB0aW1l
cnMgdG8gbm90IGV4cGlyZS4KPiAKPiBUaGUgZml4IGlzIHRvIG1ha2Ugc3VyZSB3ZSBkb24ndCBk
aXJlY3RseSBzdG9yZSB0aGUKPiByZXN1bHQgb2YgdGltZWtlZXBpbmdfZ2V0X25zKCkgaW50byBh
IHR2X25zZWMgZmllbGQsCj4gaW5zdGVhZCB1c2luZyBhIDY0Yml0IG5zZWMgdmFsdWUgd2hpY2gg
Y2FuIHRoZW4gYmUKPiBhZGRlZCBpbnRvIHRoZSB0aW1lc3BlYyB2aWEgdGltZXNwZWNfYWRkX25z
KCkuCj4gCj4gV2l0aCB0aGlzIHBhdGNoIEkgY2Fubm90IHJlcHJvZHVjZSB0aGUgaXNzdWUuCj4g
Cj4gQ2M6IEluZ28gTW9sbmFyIDxtaW5nb0BrZXJuZWwub3JnPgo+IENjOiBSaWNoYXJkIENvY2hy
YW4gPHJpY2hhcmRjb2NocmFuQGdtYWlsLmNvbT4KPiBDYzogUHJhcml0IEJoYXJnYXZhIDxwcmFy
aXRAcmVkaGF0LmNvbT4KPiBDYzogVGhvbWFzIEdsZWl4bmVyIDx0Z2x4QGxpbnV0cm9uaXguZGU+
Cj4gQ2M6IERhbmllbCBMZXpjYW5vIDxkYW5pZWwubGV6Y2Fub0BsaW5hcm8ub3JnPgo+IFJlcG9y
dGVkLWFuZC1iaXNlY3RlZC1ieTogRGFuaWVsIExlemNhbm8gPGRhbmllbC5sZXpjYW5vQGxpbmFy
by5vcmc+Cj4gU2lnbmVkLW9mZi1ieTogSm9obiBTdHVsdHogPGpvaG4uc3R1bHR6QGxpbmFyby5v
cmc+Cj4gLS0tCj4gIGtlcm5lbC90aW1lL3RpbWVrZWVwaW5nLmMgfCAgIDE5ICsrKysrKysrKysr
Ky0tLS0tLS0KPiAgMSBmaWxlIGNoYW5nZWQsIDEyIGluc2VydGlvbnMoKyksIDcgZGVsZXRpb25z
KC0pCj4gCj4gZGlmZiAtLWdpdCBhL2tlcm5lbC90aW1lL3RpbWVrZWVwaW5nLmMgYi9rZXJuZWwv
dGltZS90aW1la2VlcGluZy5jCj4gaW5kZXggMzRlNWVhYy4uZDNiOTFlNyAxMDA2NDQKPiAtLS0g
YS9rZXJuZWwvdGltZS90aW1la2VlcGluZy5jCj4gKysrIGIva2VybmVsL3RpbWUvdGltZWtlZXBp
bmcuYwo+IEBAIC0zMDMsMTAgKzMwMywxMSBAQCB2b2lkIGdldG5zdGltZW9mZGF5KHN0cnVjdCB0
aW1lc3BlYyAqdHMpCj4gICAgICAgICAgc2VxID0gcmVhZF9zZXFiZWdpbigmdGstPmxvY2spOwo+
ICAKPiAgICAgICAgICB0cy0+dHZfc2VjID0gdGstPnh0aW1lX3NlYzsKPiAtICAgICAgICB0cy0+
dHZfbnNlYyA9IHRpbWVrZWVwaW5nX2dldF9ucyh0ayk7Cj4gKyAgICAgICAgbnNlY3MgPSB0aW1l
a2VlcGluZ19nZXRfbnModGspOwo+ICAKPiAgICAgIH0gd2hpbGUgKHJlYWRfc2VxcmV0cnkoJnRr
LT5sb2NrLCBzZXEpKTsKPiAgCj4gKyAgICB0cy0+dHZfbnNlYyA9IDA7Cj4gICAgICB0aW1lc3Bl
Y19hZGRfbnModHMsIG5zZWNzKTsKPiAgfQo+ICBFWFBPUlRfU1lNQk9MKGdldG5zdGltZW9mZGF5
KTsKPiBAQCAtMzQ1LDYgKzM0Niw3IEBAIHZvaWQga3RpbWVfZ2V0X3RzKHN0cnVjdCB0aW1lc3Bl
YyAqdHMpCj4gIHsKPiAgICAgIHN0cnVjdCB0aW1la2VlcGVyICp0ayA9ICZ0aW1la2VlcGVyOwo+
ICAgICAgc3RydWN0IHRpbWVzcGVjIHRvbW9ubzsKPiArICAgIHM2NCBuc2VjOwo+ICAgICAgdW5z
aWduZWQgaW50IHNlcTsKPiAgCj4gICAgICBXQVJOX09OKHRpbWVrZWVwaW5nX3N1c3BlbmRlZCk7
Cj4gQEAgLTM1MiwxMyArMzU0LDE0IEBAIHZvaWQga3RpbWVfZ2V0X3RzKHN0cnVjdCB0aW1lc3Bl
YyAqdHMpCj4gICAgICBkbyB7Cj4gICAgICAgICAgc2VxID0gcmVhZF9zZXFiZWdpbigmdGstPmxv
Y2spOwo+ICAgICAgICAgIHRzLT50dl9zZWMgPSB0ay0+eHRpbWVfc2VjOwo+IC0gICAgICAgIHRz
LT50dl9uc2VjID0gdGltZWtlZXBpbmdfZ2V0X25zKHRrKTsKPiArICAgICAgICBuc2VjID0gdGlt
ZWtlZXBpbmdfZ2V0X25zKHRrKTsKPiAgICAgICAgICB0b21vbm8gPSB0ay0+d2FsbF90b19tb25v
dG9uaWM7Cj4gIAo+ICAgICAgfSB3aGlsZSAocmVhZF9zZXFyZXRyeSgmdGstPmxvY2ssIHNlcSkp
Owo+ICAKPiAtICAgIHNldF9ub3JtYWxpemVkX3RpbWVzcGVjKHRzLCB0cy0+dHZfc2VjICsgdG9t
b25vLnR2X3NlYywKPiAtICAgICAgICAgICAgICAgIHRzLT50dl9uc2VjICsgdG9tb25vLnR2X25z
ZWMpOwo+ICsgICAgdHMtPnR2X3NlYyArPSB0b21vbm8udHZfc2VjOwo+ICsgICAgdHMtPnR2X25z
ZWMgPSAwOwo+ICsgICAgdGltZXNwZWNfYWRkX25zKHRzLCBuc2VjICsgdG9tb25vLnR2X25zZWMp
Owo+ICB9Cj4gIEVYUE9SVF9TWU1CT0xfR1BMKGt0aW1lX2dldF90cyk7Cj4gIAo+IEBAIC0xMjQ0
LDYgKzEyNDcsNyBAQCB2b2lkIGdldF9tb25vdG9uaWNfYm9vdHRpbWUoc3RydWN0IHRpbWVzcGVj
ICp0cykKPiAgewo+ICAgICAgc3RydWN0IHRpbWVrZWVwZXIgKnRrID0gJnRpbWVrZWVwZXI7Cj4g
ICAgICBzdHJ1Y3QgdGltZXNwZWMgdG9tb25vLCBzbGVlcDsKPiArICAgIHM2NCBuc2VjOwo+ICAg
ICAgdW5zaWduZWQgaW50IHNlcTsKPiAgCj4gICAgICBXQVJOX09OKHRpbWVrZWVwaW5nX3N1c3Bl
bmRlZCk7Cj4gQEAgLTEyNTEsMTQgKzEyNTUsMTUgQEAgdm9pZCBnZXRfbW9ub3RvbmljX2Jvb3R0
aW1lKHN0cnVjdCB0aW1lc3BlYyAqdHMpCj4gICAgICBkbyB7Cj4gICAgICAgICAgc2VxID0gcmVh
ZF9zZXFiZWdpbigmdGstPmxvY2spOwo+ICAgICAgICAgIHRzLT50dl9zZWMgPSB0ay0+eHRpbWVf
c2VjOwo+IC0gICAgICAgIHRzLT50dl9uc2VjID0gdGltZWtlZXBpbmdfZ2V0X25zKHRrKTsKPiAr
ICAgICAgICBuc2VjID0gdGltZWtlZXBpbmdfZ2V0X25zKHRrKTsKPiAgICAgICAgICB0b21vbm8g
PSB0ay0+d2FsbF90b19tb25vdG9uaWM7Cj4gICAgICAgICAgc2xlZXAgPSB0ay0+dG90YWxfc2xl
ZXBfdGltZTsKPiAgCj4gICAgICB9IHdoaWxlIChyZWFkX3NlcXJldHJ5KCZ0ay0+bG9jaywgc2Vx
KSk7Cj4gIAo+IC0gICAgc2V0X25vcm1hbGl6ZWRfdGltZXNwZWModHMsIHRzLT50dl9zZWMgKyB0
b21vbm8udHZfc2VjICsgc2xlZXAudHZfc2VjLAo+IC0gICAgICAgICAgICB0cy0+dHZfbnNlYyAr
IHRvbW9uby50dl9uc2VjICsgc2xlZXAudHZfbnNlYyk7Cj4gKyAgICB0cy0+dHZfc2VjICs9IHRv
bW9uby50dl9zZWMgKyBzbGVlcC50dl9zZWM7Cj4gKyAgICB0cy0+dHZfbnNlYyA9IDA7Cj4gKyAg
ICB0aW1lc3BlY19hZGRfbnModHMsIG5zZWMgKyB0b21vbm8udHZfbnNlYyArIHNsZWVwLnR2X25z
ZWMpOwo+ICB9Cj4gIEVYUE9SVF9TWU1CT0xfR1BMKGdldF9tb25vdG9uaWNfYm9vdHRpbWUpOwo+
ICAKCgotLSAKIDxodHRwOi8vd3d3LmxpbmFyby5vcmcvPiBMaW5hcm8ub3JnIOKUgiBPcGVuIHNv
dXJjZSBzb2Z0d2FyZSBmb3IgQVJNIFNvQ3MKCkZvbGxvdyBMaW5hcm86ICA8aHR0cDovL3d3dy5m
YWNlYm9vay5jb20vcGFnZXMvTGluYXJvPiBGYWNlYm9vayB8CjxodHRwOi8vdHdpdHRlci5jb20v
IyEvbGluYXJvb3JnPiBUd2l0dGVyIHwKPGh0dHA6Ly93d3cubGluYXJvLm9yZy9saW5hcm8tYmxv
Zy8+IEJsb2cKCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
XwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW4ub3JnCmh0dHA6Ly9s
aXN0cy54ZW4ub3JnL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xen.org Tue Sep 11 06:59:31 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 2012 06:59:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TBKQt-0003My-Mi; Tue, 11 Sep 2012 06:58:51 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <daniel.lezcano@linaro.org>) id 1TBKQs-0003Mt-Cn
	for xen-devel@lists.xensource.com; Tue, 11 Sep 2012 06:58:50 +0000
Received: from [85.158.138.51:23136] by server-5.bemta-3.messagelabs.com id
	8A/EB-13133-921EE405; Tue, 11 Sep 2012 06:58:49 +0000
X-Env-Sender: daniel.lezcano@linaro.org
X-Msg-Ref: server-2.tower-174.messagelabs.com!1347346728!29827116!1
X-Originating-IP: [74.125.83.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12874 invoked from network); 11 Sep 2012 06:58:48 -0000
Received: from mail-ee0-f43.google.com (HELO mail-ee0-f43.google.com)
	(74.125.83.43)
	by server-2.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Sep 2012 06:58:48 -0000
Received: by eekd4 with SMTP id d4so90833eek.30
	for <xen-devel@lists.xensource.com>;
	Mon, 10 Sep 2012 23:58:48 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=message-id:date:from:user-agent:mime-version:to:cc:subject
	:references:in-reply-to:content-type:content-transfer-encoding
	:x-gm-message-state;
	bh=05T4LAc/WeH6MsGqj2eSdF//CVuCGUfVJ2wfIstIDAQ=;
	b=VYRPQ5OuOkwWqXAdPC7UAGAhy1pPa2SgWeYM1F7Y65n/eCuu6ALMHXf60Rm/dEe6fw
	F7NJ6WQHFMtzU2Ea4Occ24q4ILEE3fAOEPrj9XbD2yKk+pKNyJV+qfmZVh2veUOSBQhj
	/Y5K+q2n2PLCRlaCFe6dqCEdzngUB9B+VE7fq2JMhASdcd3YIGO/mtQT54NXgjcf1/4a
	zSygwB83GAK+PS+GoPLZ2PaLkEvHbMrgCKY+XJic5OKo/oinVk4kX1oWUPY6f8Tj+8aA
	xKy91NCs4ggHzm4d1jwclsvw/TwgzmxugIpxpgdnrwtUtQsWC5eVgiemsHHegKKdRk5q
	vo1g==
Received: by 10.14.224.73 with SMTP id w49mr23887353eep.37.1347346728346;
	Mon, 10 Sep 2012 23:58:48 -0700 (PDT)
Received: from [192.168.10.4] (AToulouse-651-1-192-218.w109-222.abo.wanadoo.fr.
	[109.222.127.218])
	by mx.google.com with ESMTPS id r45sm44308612eem.6.2012.09.10.23.58.45
	(version=SSLv3 cipher=OTHER); Mon, 10 Sep 2012 23:58:47 -0700 (PDT)
Message-ID: <504EE124.3010401@linaro.org>
Date: Tue, 11 Sep 2012 08:58:44 +0200
From: Daniel Lezcano <daniel.lezcano@linaro.org>
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:12.0) Gecko/20120430 Thunderbird/12.0.1
MIME-Version: 1.0
To: John Stultz <john.stultz@linaro.org>
References: <1343164349-28550-1-git-send-email-daniel.lezcano@linaro.org>
	<201209062204.11288.rjw@sisk.pl> <50490920.9070204@linaro.org>
	<201209062318.42874.rjw@sisk.pl> <504A02BD.4000805@linaro.org>
	<504A2D73.3010702@linaro.org> <504A68A0.7010907@linaro.org>
	<504E1FE5.6090502@linaro.org> <504E4343.5070004@linaro.org>
	<504E8372.20904@linaro.org>
In-Reply-To: <504E8372.20904@linaro.org>
X-Gm-Message-State: ALoCoQkeuFP5LTiDcc6R+p496uGMXO9TttFQq/pWl5HfQO1HL3PxLZd2L05XDfuysOFbeDj98mww
Cc: prarit@redhat.com, xen-devel@lists.xensource.com,
	linaro-dev@lists.linaro.org, Peter Zijlstra <a.p.zijlstra@chello.nl>,
	linux-pm@vger.kernel.org, Frederic Weisbecker <fweisbec@gmail.com>,
	richardcochran@gmail.com, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	"Rafael J. Wysocki" <rjw@sisk.pl>, linux-acpi@vger.kernel.org,
	Thomas Gleixner <tglx@linutronix.de>, mingo@kernel.org, lenb@kernel.org
Subject: Re: [Xen-devel] CONFIG_NO_HZ + CONFIG_CPU_IDLE freeze the system
 (Was Re: [PATCH] acpi : remove power from acpi_processor_cx structure)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gMDkvMTEvMjAxMiAwMjoxOCBBTSwgSm9obiBTdHVsdHogd3JvdGU6Cj4gT24gMDkvMTAvMjAx
MiAxMjo0NSBQTSwgRGFuaWVsIExlemNhbm8gd3JvdGU6Cj4+IE9uIDA5LzEwLzIwMTIgMDc6MTQg
UE0sIEpvaG4gU3R1bHR6IHdyb3RlOgo+Pj4gSW4gdGhlIG1lYW50aW1lLCBJJ2xsIHRyeSB0byBy
ZXByb2R1Y2Ugb24gbXkgVDYxLiBJZiB5b3UgY291bGQgc2VuZCBtZQo+Pj4geW91ciAuY29uZmln
LCBJJ2QgYXBwcmVjaWF0ZSBpdC4KPj4gaHR0cDovL3Bhc3RlYmluLmNvbS9xU3hxZmRESwo+Pgo+
PiBUaGUgaGVhZGVyIG9mIHRoZSBjb25maWcgZmlsZSBzaG93cyBmb3IgYSB2My41LXJjNyBiZWNh
dXNlIGl0IGlzIHRoZQo+PiByZXN1bHQgb2YgdGhlIGdpdC1iaXNlY3QuIElmIHlvdSBrZWVwIHRo
aXMgY29uZmlnIGZpbGUgZm9yIHRoZSBsYXRlc3QKPj4ga2VybmVsIHRoYXQgc2hvdWxkIHJlcHJv
ZHVjZSB0aGUgcHJvYmxlbS4KPj4KPj4gTGV0IG1lIGtub3cgaWYgeW91IHdlcmUgYWJsZSB0byBy
ZXByb2R1Y2UgdGhlIHByb2JsZW0uCj4gR3JlYXQhIFdpdGggdGhpcyBJIHdhcyBhYmxlIHRvIHF1
aWNrbHkgcmVwcm9kdWNlIHRoZSBwcm9ibGVtIGFuZCBJIHRoaW5rCj4gSSBoYXZlIGEgZml4LgoK
Q29vbCAhCgo+IFdvdWxkIHlvdSBtaW5kIHRlc3RpbmcgdGhlIGZvbGxvd2luZyBwYXRjaD8gSXQg
c2VlbXMgdG8gcmVzb2x2ZSB0aGUKPiBpc3N1ZSwgYnV0IEkndmUgbm90IHlldCBydW4gaXQgdGhy
b3VnaCBteSB0ZXN0IHN1aXRlIHRvIG1ha2Ugc3VyZSBpdAo+IGRpZG4ndCBicmVhayBhbnl0aGlu
ZyBlbHNlLgoKTm8gcHJvYmxlbSwgSSB3aWxsIHRyeSBpdCB0aGlzIGV2ZW5pbmcuCgpJcyB0aGlz
IHByb2JsZW0gcmVsYXRlZCB0byBhbGwgMzJiaXRzIGFyY2ggPwoKVGhhbmtzICEKCiAgLS0gRGFu
aWVsCgo+IElmIGJvdGggeW91ciBhbmQgbXkgdGVzdGluZyBjb21lcyBiYWNrIG9rLCBJJ2xsIHN1
Ym1pdCBpdCB0byBUaG9tYXMuCj4gCj4gdGhhbmtzCj4gLWpvaG4KPiAKPiBGcm9tIGYxMGEyODVh
NWI1MzJhMTRkMzMzMGY2ZTYwZTRkN2JkNTYyNzkzMmEgTW9uIFNlcCAxNyAwMDowMDowMCAyMDAx
Cj4gRnJvbTogSm9obiBTdHVsdHogPGpvaG4uc3R1bHR6QGxpbmFyby5vcmc+Cj4gRGF0ZTogTW9u
LCAxMCBTZXAgMjAxMiAyMDowMDoxNSAtMDQwMAo+IFN1YmplY3Q6IFtQQVRDSF0gdGltZTogRml4
IHRpbWVla2VwaW5nX2dldF9ucyBvdmVyZmxvdyBvbiAzMmJpdCBzeXN0ZW1zCj4gCj4gRGFuaWVs
IExlemNhbm8gcmVwb3J0ZWQgc2VlaW5nIG11bHRpLXNlY29uZCBzdGFsbHMgZnJvbQo+IGtleWJv
YXJkIGlucHV0IG9uIGhpcyBUNjEgbGFwdG9wIHdoZW4gTk9IWiBhbmQgQ1BVX0lETEUKPiB3ZXJl
IGVuYWJsZWQgb24gYSAzMmJpdCBrZXJuZWwuCj4gCj4gSGUgYmlzZWN0ZWQgdGhlIHByb2JsZW0g
ZG93biB0bwo+IDFlNzVmYThiZTlmYjYxZTFhZjQ2YjViM2IxNzYzNDdhNGM5NThjYTEgKHRpbWU6
IENvbmRlbnNlCj4gdGltZWtlZXBlci54dGltZSBpbnRvIHh0aW1lX3NlYykuCj4gCj4gQWZ0ZXIg
cmVwcm9kdWNpbmcgdGhpcyBpc3N1ZSwgSSBuYXJyb3dlZCB0aGUgcHJvYmxlbSBkb3duCj4gdG8g
dGhlIGZhY3QgdGhhdCB0aW1la2VlcGluZ19nZXRfbnMoKSByZXR1cm5zIGEgNjRiaXQKPiBuc2Vj
IHZhbHVlIHRoYXQgaGFzbid0IGJlZW4gYWNjdW11bGF0ZWQuIEluIHNvbWUgY2FzZXMKPiB0aGlz
IHZhbHVlIHdhcyBiZWluZyB0aGVuIHN0b3JlZCBpbiB0aW1lc3BlYy50dl9uc2VjCj4gKHdoaWNo
IGlzIGEgbG9uZykuCj4gCj4gT24gMzJiaXQgc3lzdGVtcywgV2l0aCBpZGxlIHRpbWVzIGxhcmdl
ciB0aGVuIDQgc2Vjb25kcwo+IChvciBsZXNzLCBkZXBlbmRpbmcgb24gdGhlIHZhbHVlIG9mIHh0
aW1lX25zZWMpLCB0aGUKPiByZXR1cm5lZCBuc2VjIHZhbHVlIHdvdWxkIG92ZXJmbG93IDMyYml0
cy4gVGhpcyBsaW1pdGVkCj4ga2VwdCB0aW1lIGZyb20gaW5jcmVhc2luZywgY2F1c2luZyB0aW1l
cnMgdG8gbm90IGV4cGlyZS4KPiAKPiBUaGUgZml4IGlzIHRvIG1ha2Ugc3VyZSB3ZSBkb24ndCBk
aXJlY3RseSBzdG9yZSB0aGUKPiByZXN1bHQgb2YgdGltZWtlZXBpbmdfZ2V0X25zKCkgaW50byBh
IHR2X25zZWMgZmllbGQsCj4gaW5zdGVhZCB1c2luZyBhIDY0Yml0IG5zZWMgdmFsdWUgd2hpY2gg
Y2FuIHRoZW4gYmUKPiBhZGRlZCBpbnRvIHRoZSB0aW1lc3BlYyB2aWEgdGltZXNwZWNfYWRkX25z
KCkuCj4gCj4gV2l0aCB0aGlzIHBhdGNoIEkgY2Fubm90IHJlcHJvZHVjZSB0aGUgaXNzdWUuCj4g
Cj4gQ2M6IEluZ28gTW9sbmFyIDxtaW5nb0BrZXJuZWwub3JnPgo+IENjOiBSaWNoYXJkIENvY2hy
YW4gPHJpY2hhcmRjb2NocmFuQGdtYWlsLmNvbT4KPiBDYzogUHJhcml0IEJoYXJnYXZhIDxwcmFy
aXRAcmVkaGF0LmNvbT4KPiBDYzogVGhvbWFzIEdsZWl4bmVyIDx0Z2x4QGxpbnV0cm9uaXguZGU+
Cj4gQ2M6IERhbmllbCBMZXpjYW5vIDxkYW5pZWwubGV6Y2Fub0BsaW5hcm8ub3JnPgo+IFJlcG9y
dGVkLWFuZC1iaXNlY3RlZC1ieTogRGFuaWVsIExlemNhbm8gPGRhbmllbC5sZXpjYW5vQGxpbmFy
by5vcmc+Cj4gU2lnbmVkLW9mZi1ieTogSm9obiBTdHVsdHogPGpvaG4uc3R1bHR6QGxpbmFyby5v
cmc+Cj4gLS0tCj4gIGtlcm5lbC90aW1lL3RpbWVrZWVwaW5nLmMgfCAgIDE5ICsrKysrKysrKysr
Ky0tLS0tLS0KPiAgMSBmaWxlIGNoYW5nZWQsIDEyIGluc2VydGlvbnMoKyksIDcgZGVsZXRpb25z
KC0pCj4gCj4gZGlmZiAtLWdpdCBhL2tlcm5lbC90aW1lL3RpbWVrZWVwaW5nLmMgYi9rZXJuZWwv
dGltZS90aW1la2VlcGluZy5jCj4gaW5kZXggMzRlNWVhYy4uZDNiOTFlNyAxMDA2NDQKPiAtLS0g
YS9rZXJuZWwvdGltZS90aW1la2VlcGluZy5jCj4gKysrIGIva2VybmVsL3RpbWUvdGltZWtlZXBp
bmcuYwo+IEBAIC0zMDMsMTAgKzMwMywxMSBAQCB2b2lkIGdldG5zdGltZW9mZGF5KHN0cnVjdCB0
aW1lc3BlYyAqdHMpCj4gICAgICAgICAgc2VxID0gcmVhZF9zZXFiZWdpbigmdGstPmxvY2spOwo+
ICAKPiAgICAgICAgICB0cy0+dHZfc2VjID0gdGstPnh0aW1lX3NlYzsKPiAtICAgICAgICB0cy0+
dHZfbnNlYyA9IHRpbWVrZWVwaW5nX2dldF9ucyh0ayk7Cj4gKyAgICAgICAgbnNlY3MgPSB0aW1l
a2VlcGluZ19nZXRfbnModGspOwo+ICAKPiAgICAgIH0gd2hpbGUgKHJlYWRfc2VxcmV0cnkoJnRr
LT5sb2NrLCBzZXEpKTsKPiAgCj4gKyAgICB0cy0+dHZfbnNlYyA9IDA7Cj4gICAgICB0aW1lc3Bl
Y19hZGRfbnModHMsIG5zZWNzKTsKPiAgfQo+ICBFWFBPUlRfU1lNQk9MKGdldG5zdGltZW9mZGF5
KTsKPiBAQCAtMzQ1LDYgKzM0Niw3IEBAIHZvaWQga3RpbWVfZ2V0X3RzKHN0cnVjdCB0aW1lc3Bl
YyAqdHMpCj4gIHsKPiAgICAgIHN0cnVjdCB0aW1la2VlcGVyICp0ayA9ICZ0aW1la2VlcGVyOwo+
ICAgICAgc3RydWN0IHRpbWVzcGVjIHRvbW9ubzsKPiArICAgIHM2NCBuc2VjOwo+ICAgICAgdW5z
aWduZWQgaW50IHNlcTsKPiAgCj4gICAgICBXQVJOX09OKHRpbWVrZWVwaW5nX3N1c3BlbmRlZCk7
Cj4gQEAgLTM1MiwxMyArMzU0LDE0IEBAIHZvaWQga3RpbWVfZ2V0X3RzKHN0cnVjdCB0aW1lc3Bl
YyAqdHMpCj4gICAgICBkbyB7Cj4gICAgICAgICAgc2VxID0gcmVhZF9zZXFiZWdpbigmdGstPmxv
Y2spOwo+ICAgICAgICAgIHRzLT50dl9zZWMgPSB0ay0+eHRpbWVfc2VjOwo+IC0gICAgICAgIHRz
LT50dl9uc2VjID0gdGltZWtlZXBpbmdfZ2V0X25zKHRrKTsKPiArICAgICAgICBuc2VjID0gdGlt
ZWtlZXBpbmdfZ2V0X25zKHRrKTsKPiAgICAgICAgICB0b21vbm8gPSB0ay0+d2FsbF90b19tb25v
dG9uaWM7Cj4gIAo+ICAgICAgfSB3aGlsZSAocmVhZF9zZXFyZXRyeSgmdGstPmxvY2ssIHNlcSkp
Owo+ICAKPiAtICAgIHNldF9ub3JtYWxpemVkX3RpbWVzcGVjKHRzLCB0cy0+dHZfc2VjICsgdG9t
b25vLnR2X3NlYywKPiAtICAgICAgICAgICAgICAgIHRzLT50dl9uc2VjICsgdG9tb25vLnR2X25z
ZWMpOwo+ICsgICAgdHMtPnR2X3NlYyArPSB0b21vbm8udHZfc2VjOwo+ICsgICAgdHMtPnR2X25z
ZWMgPSAwOwo+ICsgICAgdGltZXNwZWNfYWRkX25zKHRzLCBuc2VjICsgdG9tb25vLnR2X25zZWMp
Owo+ICB9Cj4gIEVYUE9SVF9TWU1CT0xfR1BMKGt0aW1lX2dldF90cyk7Cj4gIAo+IEBAIC0xMjQ0
LDYgKzEyNDcsNyBAQCB2b2lkIGdldF9tb25vdG9uaWNfYm9vdHRpbWUoc3RydWN0IHRpbWVzcGVj
ICp0cykKPiAgewo+ICAgICAgc3RydWN0IHRpbWVrZWVwZXIgKnRrID0gJnRpbWVrZWVwZXI7Cj4g
ICAgICBzdHJ1Y3QgdGltZXNwZWMgdG9tb25vLCBzbGVlcDsKPiArICAgIHM2NCBuc2VjOwo+ICAg
ICAgdW5zaWduZWQgaW50IHNlcTsKPiAgCj4gICAgICBXQVJOX09OKHRpbWVrZWVwaW5nX3N1c3Bl
bmRlZCk7Cj4gQEAgLTEyNTEsMTQgKzEyNTUsMTUgQEAgdm9pZCBnZXRfbW9ub3RvbmljX2Jvb3R0
aW1lKHN0cnVjdCB0aW1lc3BlYyAqdHMpCj4gICAgICBkbyB7Cj4gICAgICAgICAgc2VxID0gcmVh
ZF9zZXFiZWdpbigmdGstPmxvY2spOwo+ICAgICAgICAgIHRzLT50dl9zZWMgPSB0ay0+eHRpbWVf
c2VjOwo+IC0gICAgICAgIHRzLT50dl9uc2VjID0gdGltZWtlZXBpbmdfZ2V0X25zKHRrKTsKPiAr
ICAgICAgICBuc2VjID0gdGltZWtlZXBpbmdfZ2V0X25zKHRrKTsKPiAgICAgICAgICB0b21vbm8g
PSB0ay0+d2FsbF90b19tb25vdG9uaWM7Cj4gICAgICAgICAgc2xlZXAgPSB0ay0+dG90YWxfc2xl
ZXBfdGltZTsKPiAgCj4gICAgICB9IHdoaWxlIChyZWFkX3NlcXJldHJ5KCZ0ay0+bG9jaywgc2Vx
KSk7Cj4gIAo+IC0gICAgc2V0X25vcm1hbGl6ZWRfdGltZXNwZWModHMsIHRzLT50dl9zZWMgKyB0
b21vbm8udHZfc2VjICsgc2xlZXAudHZfc2VjLAo+IC0gICAgICAgICAgICB0cy0+dHZfbnNlYyAr
IHRvbW9uby50dl9uc2VjICsgc2xlZXAudHZfbnNlYyk7Cj4gKyAgICB0cy0+dHZfc2VjICs9IHRv
bW9uby50dl9zZWMgKyBzbGVlcC50dl9zZWM7Cj4gKyAgICB0cy0+dHZfbnNlYyA9IDA7Cj4gKyAg
ICB0aW1lc3BlY19hZGRfbnModHMsIG5zZWMgKyB0b21vbm8udHZfbnNlYyArIHNsZWVwLnR2X25z
ZWMpOwo+ICB9Cj4gIEVYUE9SVF9TWU1CT0xfR1BMKGdldF9tb25vdG9uaWNfYm9vdHRpbWUpOwo+
ICAKCgotLSAKIDxodHRwOi8vd3d3LmxpbmFyby5vcmcvPiBMaW5hcm8ub3JnIOKUgiBPcGVuIHNv
dXJjZSBzb2Z0d2FyZSBmb3IgQVJNIFNvQ3MKCkZvbGxvdyBMaW5hcm86ICA8aHR0cDovL3d3dy5m
YWNlYm9vay5jb20vcGFnZXMvTGluYXJvPiBGYWNlYm9vayB8CjxodHRwOi8vdHdpdHRlci5jb20v
IyEvbGluYXJvb3JnPiBUd2l0dGVyIHwKPGh0dHA6Ly93d3cubGluYXJvLm9yZy9saW5hcm8tYmxv
Zy8+IEJsb2cKCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
XwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW4ub3JnCmh0dHA6Ly9s
aXN0cy54ZW4ub3JnL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xen.org Tue Sep 11 07:01:51 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 2012 07:01:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TBKTN-0003XH-B9; Tue, 11 Sep 2012 07:01:25 +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 1TBKTK-0003Ww-UY
	for xen-devel@lists.xensource.com; Tue, 11 Sep 2012 07:01:23 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1347346823!9393949!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDg1MTY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14942 invoked from network); 11 Sep 2012 07:00:23 -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;
	11 Sep 2012 07:00:23 -0000
X-IronPort-AV: E=Sophos;i="4.80,402,1344211200"; d="scan'208";a="14459536"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Sep 2012 07:00: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.279.1; Tue, 11 Sep 2012 08:00:23 +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 1TBKSM-0003pV-TK;
	Tue, 11 Sep 2012 07:00:22 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1TBKSM-00021d-LK;
	Tue, 11 Sep 2012 08:00:22 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-13670-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Tue, 11 Sep 2012 08:00:22 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [qemu-upstream-unstable test] 13670: 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 13670 qemu-upstream-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13670/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-xl-qemuu-win-vcpus1  9 guest-localmigrate      fail like 13653
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail like 13653
 test-amd64-i386-xl-qemuu-win7-amd64  9 guest-localmigrate      fail like 13653
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  9 guest-localmigrate fail like 13653
 test-i386-i386-xl-qemuu-winxpsp3  9 guest-localmigrate         fail like 13653
 test-amd64-amd64-xl-qemuu-win  9 guest-localmigrate           fail  like 13653
 test-i386-i386-xl-qemuu-win   9 guest-localmigrate           fail   like 13653
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail like 13653

Tests which did not succeed, but are not blocking:
 test-i386-i386-qemuu-win     16 leak-check/check             fail   never pass
 test-amd64-i386-qemuu-win    16 leak-check/check             fail   never pass
 test-amd64-amd64-qemuu-win   16 leak-check/check             fail   never pass
 test-amd64-i386-xend-qemuu-winxpsp3 16 leak-check/check        fail never pass
 test-amd64-i386-qemuu-win-vcpus1 16 leak-check/check           fail never pass

version targeted for testing:
 qemuu                9e63a82dd13cdfc80c1f401cc99a682ab4b81542
baseline version:
 qemuu                87650d262dea07c955a683dcac75db86477c7ee3

------------------------------------------------------------
People who touched revisions under test:
  Dongxiao Xu <dongxiao.xu@intel.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-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-win-vcpus1                             fail    
 test-amd64-i386-xl-qemuu-win-vcpus1                          fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-amd64-qemuu-win                                   fail    
 test-amd64-i386-qemuu-win                                    fail    
 test-i386-i386-qemuu-win                                     fail    
 test-amd64-amd64-xl-qemuu-win                                fail    
 test-i386-i386-xl-qemuu-win                                  fail    
 test-amd64-i386-xend-qemuu-winxpsp3                          fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=qemu-upstream-unstable
+ revision=9e63a82dd13cdfc80c1f401cc99a682ab4b81542
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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 9e63a82dd13cdfc80c1f401cc99a682ab4b81542
+ branch=qemu-upstream-unstable
+ revision=9e63a82dd13cdfc80c1f401cc99a682ab4b81542
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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 9e63a82dd13cdfc80c1f401cc99a682ab4b81542:master
Counting objects: 1   
Counting objects: 3   
Counting objects: 5, done.
Compressing objects: 100% (1/1)   
Compressing objects: 100% (1/1), done.
Writing objects:  33% (1/3)   
Writing objects:  66% (2/3)   
Writing objects: 100% (3/3)   
Writing objects: 100% (3/3), 642 bytes, done.
Total 3 (delta 2), reused 3 (delta 2)
To xen@xenbits.xensource.com:git/qemu-upstream-unstable.git
   87650d2..9e63a82  9e63a82dd13cdfc80c1f401cc99a682ab4b81542 -> master

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 11 07:01:51 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 2012 07:01:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TBKTN-0003XH-B9; Tue, 11 Sep 2012 07:01:25 +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 1TBKTK-0003Ww-UY
	for xen-devel@lists.xensource.com; Tue, 11 Sep 2012 07:01:23 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1347346823!9393949!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDg1MTY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14942 invoked from network); 11 Sep 2012 07:00:23 -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;
	11 Sep 2012 07:00:23 -0000
X-IronPort-AV: E=Sophos;i="4.80,402,1344211200"; d="scan'208";a="14459536"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Sep 2012 07:00: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.279.1; Tue, 11 Sep 2012 08:00:23 +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 1TBKSM-0003pV-TK;
	Tue, 11 Sep 2012 07:00:22 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1TBKSM-00021d-LK;
	Tue, 11 Sep 2012 08:00:22 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-13670-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Tue, 11 Sep 2012 08:00:22 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [qemu-upstream-unstable test] 13670: 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 13670 qemu-upstream-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13670/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-xl-qemuu-win-vcpus1  9 guest-localmigrate      fail like 13653
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail like 13653
 test-amd64-i386-xl-qemuu-win7-amd64  9 guest-localmigrate      fail like 13653
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  9 guest-localmigrate fail like 13653
 test-i386-i386-xl-qemuu-winxpsp3  9 guest-localmigrate         fail like 13653
 test-amd64-amd64-xl-qemuu-win  9 guest-localmigrate           fail  like 13653
 test-i386-i386-xl-qemuu-win   9 guest-localmigrate           fail   like 13653
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail like 13653

Tests which did not succeed, but are not blocking:
 test-i386-i386-qemuu-win     16 leak-check/check             fail   never pass
 test-amd64-i386-qemuu-win    16 leak-check/check             fail   never pass
 test-amd64-amd64-qemuu-win   16 leak-check/check             fail   never pass
 test-amd64-i386-xend-qemuu-winxpsp3 16 leak-check/check        fail never pass
 test-amd64-i386-qemuu-win-vcpus1 16 leak-check/check           fail never pass

version targeted for testing:
 qemuu                9e63a82dd13cdfc80c1f401cc99a682ab4b81542
baseline version:
 qemuu                87650d262dea07c955a683dcac75db86477c7ee3

------------------------------------------------------------
People who touched revisions under test:
  Dongxiao Xu <dongxiao.xu@intel.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-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-win-vcpus1                             fail    
 test-amd64-i386-xl-qemuu-win-vcpus1                          fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-amd64-qemuu-win                                   fail    
 test-amd64-i386-qemuu-win                                    fail    
 test-i386-i386-qemuu-win                                     fail    
 test-amd64-amd64-xl-qemuu-win                                fail    
 test-i386-i386-xl-qemuu-win                                  fail    
 test-amd64-i386-xend-qemuu-winxpsp3                          fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=qemu-upstream-unstable
+ revision=9e63a82dd13cdfc80c1f401cc99a682ab4b81542
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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 9e63a82dd13cdfc80c1f401cc99a682ab4b81542
+ branch=qemu-upstream-unstable
+ revision=9e63a82dd13cdfc80c1f401cc99a682ab4b81542
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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 9e63a82dd13cdfc80c1f401cc99a682ab4b81542:master
Counting objects: 1   
Counting objects: 3   
Counting objects: 5, done.
Compressing objects: 100% (1/1)   
Compressing objects: 100% (1/1), done.
Writing objects:  33% (1/3)   
Writing objects:  66% (2/3)   
Writing objects: 100% (3/3)   
Writing objects: 100% (3/3), 642 bytes, done.
Total 3 (delta 2), reused 3 (delta 2)
To xen@xenbits.xensource.com:git/qemu-upstream-unstable.git
   87650d2..9e63a82  9e63a82dd13cdfc80c1f401cc99a682ab4b81542 -> master

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 11 07:05:53 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 2012 07:05:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TBKXI-0003ss-Vh; Tue, 11 Sep 2012 07:05:28 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1TBKXI-0003sn-Jh
	for xen-devel@lists.xen.org; Tue, 11 Sep 2012 07:05:28 +0000
Received: from [85.158.143.35:59812] by server-2.bemta-4.messagelabs.com id
	39/B0-21239-7B2EE405; Tue, 11 Sep 2012 07:05:27 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1347347121!15158247!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM5NTk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24364 invoked from network); 11 Sep 2012 07:05:21 -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;
	11 Sep 2012 07:05:21 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 11 Sep 2012 08:05:20 +0100
Message-Id: <504EFECD020000780009A69C@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 11 Sep 2012 08:05:17 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "David Vrabel" <david.vrabel@citrix.com>
References: <1347298015-6761-1-git-send-email-david.vrabel@citrix.com>
In-Reply-To: <1347298015-6761-1-git-send-email-david.vrabel@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] x86: make the dom0_max_vcpus option more
 flexible
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.09.12 at 19:26, David Vrabel <david.vrabel@citrix.com> wrote:
> From: David Vrabel <david.vrabel@citrix.com>
> 
> The dom0_max_vcpus command line option only allows the exact number of
> VCPUs for dom0 to be set.  It is not possible to say "up to N VCPUs
> but no more than the number physically present."
> 
> Allow a range for the option to set a minimum number of VCPUs, and a
> maximum which does not exceed the number of PCPUs.
> 
> For example, with "dom0_max_vcpus=4-8":
> 
>     PCPUs  Dom0 VCPUs
>      2      4
>      4      4
>      6      6
>      8      8
>     10      8
> 
> Existing command lines with "dom0_max_vcpus=N" still work as before
> (and are equivalent to dom0_max_vcpus=N-N).
> 
> Signed-off-by: David Vrabel <david.vrabel@citrix.com>
> Acked-by: Jan Beulich <jbeulich@suse.com>
> ---
> Changes since v2:
>   - none, repost for Xen 4.3

Thanks for resending - it didn't get lost, just didn't get around
to apply it yet as I first wanted to have it in my local tree for
a short while.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 11 07:05:53 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 2012 07:05:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TBKXI-0003ss-Vh; Tue, 11 Sep 2012 07:05:28 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1TBKXI-0003sn-Jh
	for xen-devel@lists.xen.org; Tue, 11 Sep 2012 07:05:28 +0000
Received: from [85.158.143.35:59812] by server-2.bemta-4.messagelabs.com id
	39/B0-21239-7B2EE405; Tue, 11 Sep 2012 07:05:27 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1347347121!15158247!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM5NTk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24364 invoked from network); 11 Sep 2012 07:05:21 -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;
	11 Sep 2012 07:05:21 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 11 Sep 2012 08:05:20 +0100
Message-Id: <504EFECD020000780009A69C@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 11 Sep 2012 08:05:17 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "David Vrabel" <david.vrabel@citrix.com>
References: <1347298015-6761-1-git-send-email-david.vrabel@citrix.com>
In-Reply-To: <1347298015-6761-1-git-send-email-david.vrabel@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] x86: make the dom0_max_vcpus option more
 flexible
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.09.12 at 19:26, David Vrabel <david.vrabel@citrix.com> wrote:
> From: David Vrabel <david.vrabel@citrix.com>
> 
> The dom0_max_vcpus command line option only allows the exact number of
> VCPUs for dom0 to be set.  It is not possible to say "up to N VCPUs
> but no more than the number physically present."
> 
> Allow a range for the option to set a minimum number of VCPUs, and a
> maximum which does not exceed the number of PCPUs.
> 
> For example, with "dom0_max_vcpus=4-8":
> 
>     PCPUs  Dom0 VCPUs
>      2      4
>      4      4
>      6      6
>      8      8
>     10      8
> 
> Existing command lines with "dom0_max_vcpus=N" still work as before
> (and are equivalent to dom0_max_vcpus=N-N).
> 
> Signed-off-by: David Vrabel <david.vrabel@citrix.com>
> Acked-by: Jan Beulich <jbeulich@suse.com>
> ---
> Changes since v2:
>   - none, repost for Xen 4.3

Thanks for resending - it didn't get lost, just didn't get around
to apply it yet as I first wanted to have it in my local tree for
a short while.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 11 07:22:59 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 2012 07:22: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 1TBKnn-00045n-JS; Tue, 11 Sep 2012 07:22:31 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1TBKnm-00045i-HJ
	for xen-devel@lists.xen.org; Tue, 11 Sep 2012 07:22:30 +0000
Received: from [85.158.143.99:44199] by server-1.bemta-4.messagelabs.com id
	13/CD-12504-5B6EE405; Tue, 11 Sep 2012 07:22:29 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-16.tower-216.messagelabs.com!1347348148!18436584!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29942 invoked from network); 11 Sep 2012 07:22:29 -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; 11 Sep 2012 07:22:29 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1TBKnh-000KYS-PC; Tue, 11 Sep 2012 07:22:25 +0000
Date: Tue, 11 Sep 2012 08:22:25 +0100
From: Tim Deegan <tim@xen.org>
To: Steven Maresca <steve@zentific.com>
Message-ID: <20120911072225.GB78597@ocelot.phlegethon.org>
References: <CANSvah6PU5SOKd19qfbvTXvz4spcPYVUQHmiirmm5hPvmzR+pg@mail.gmail.com>
	<CC741C8D.4B3AF%keir@xen.org>
	<CANSvah6nWfKP9-PLSkhbFcO2ONmfj5Hhs-+3r0MhjOUHU1qNfg@mail.gmail.com>
	<CAB10MZDy0zTQNO5APyWMgbhiKw+4uXZ2pYMKHqJ3MNKR5gLjjA@mail.gmail.com>
	<CANSvah4NN05Zimm2BmKO9ofC04G+D7Svrg+2xwp0yM16Cn3CRw@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CANSvah4NN05Zimm2BmKO9ofC04G+D7Svrg+2xwp0yM16Cn3CRw@mail.gmail.com>
User-Agent: Mutt/1.4.2.1i
Cc: Aravindh Puthiyaparambil <aravindh@virtuata.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Keir Fraser <keir@xen.org>, andres@lagarcavilla.org,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] mem_event: fix regression affecting CR3,
	CR4 memory events
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At 23:56 -0400 on 10 Sep (1347321409), Steven Maresca wrote:
> On Mon, Sep 10, 2012 at 9:49 PM, Aravindh Puthiyaparambil
> <aravindh@virtuata.com> wrote:
> > On Mon, Sep 10, 2012 at 3:06 PM, Steven Maresca <steve@zentific.com> wrote:
> >> On Mon, Sep 10, 2012 at 5:39 PM, Keir Fraser <keir@xen.org> wrote:
> >>> On 10/09/2012 22:20, "Steven Maresca" <steve@zentific.com> wrote:
> >>>
> >>>> Given the refactoring in the commit related to the regression
> >>>> http://xenbits.xen.org/hg/xen-unstable.hg/rev/1276926e3795, it seemed
> >>>> (to me anyway) that inserting calls as shown in the patch would be
> >>>> cleaner, but I can definitely come up with some drawbacks.  However, I
> >>>> wanted to get this fixed for 4.2 if at all possible, so I wanted to
> >>>> send regardless.
> >>>>
> >>>> In terms of drawbacks, this will require some ifdefs for x86_64, for example.
> >>>>
> >>>> Any suggestions for the cleanest means of achieving the same in vmx.c?
> >>>
> >>> I don't understand this at all. The original commit moved some CR handling
> >>> to common HVM code. Your patch adds some mem_event calls into that common
> >>> HVM code. What would need to be "achieved" in vmx.c? What ifdefs would be
> >>> required for x86_64?
> >>>
> >>>  -- Keir
> >>>
> >>>
> >>
> >> Keir,
> >>
> >> In the process of moving CR handling to common code, that commit
> >> removed calls to hvm_memory_event_cr3() and hvm_memory_event_cr4().
> >> Without some patch restoring the calls to those two functions, current
> >> xen-unstable and xen-4.2-testing only reference them as function
> >> prototypes and function definitions -- there are no calls whatsoever.
> >>
> >> I only mentioned an ifdef relative to x86_64 because of the #ifdef
> >> __x86_64__  around the function definitions. ( I know in the hvm.h
> >> itself they're just empty inline functions if not __x86_64__. )
> >>
> >> Regarding vmx.c: hvm_memory_event_cr0 is called within vmx_cr_access.
> >> The patch I sent restoring the calls to hvm_memory_event_cr4 and
> >> hvm_memory_event_cr3 could be treated similarly, that's all.
> >
> > Looks good to me.
> > Acked-by: Aravindh Puthiyaparambil <aravindh@virtuata.com>
> >
> > Cheers,
> > Aravindh
> 
> Adding Tim Deegan as suggested.
> 
> Tim, this is a regression fix for CR3/CR4 memory events
> unintentionally removed during some refactoring of HVM CR handling.
> If at all possible, for 4.2 inclusion before we officially leave RC.

I think it's too late to get any more code changes in to 4.2.0, so this
will have to wait for 4.2.1.  Ian?

The patch looks OK, but why didn't you put the memory_event calls back
in mov_to_cr(), which is where they were before 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 Tue Sep 11 07:22:59 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 2012 07:22: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 1TBKnn-00045n-JS; Tue, 11 Sep 2012 07:22:31 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1TBKnm-00045i-HJ
	for xen-devel@lists.xen.org; Tue, 11 Sep 2012 07:22:30 +0000
Received: from [85.158.143.99:44199] by server-1.bemta-4.messagelabs.com id
	13/CD-12504-5B6EE405; Tue, 11 Sep 2012 07:22:29 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-16.tower-216.messagelabs.com!1347348148!18436584!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29942 invoked from network); 11 Sep 2012 07:22:29 -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; 11 Sep 2012 07:22:29 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1TBKnh-000KYS-PC; Tue, 11 Sep 2012 07:22:25 +0000
Date: Tue, 11 Sep 2012 08:22:25 +0100
From: Tim Deegan <tim@xen.org>
To: Steven Maresca <steve@zentific.com>
Message-ID: <20120911072225.GB78597@ocelot.phlegethon.org>
References: <CANSvah6PU5SOKd19qfbvTXvz4spcPYVUQHmiirmm5hPvmzR+pg@mail.gmail.com>
	<CC741C8D.4B3AF%keir@xen.org>
	<CANSvah6nWfKP9-PLSkhbFcO2ONmfj5Hhs-+3r0MhjOUHU1qNfg@mail.gmail.com>
	<CAB10MZDy0zTQNO5APyWMgbhiKw+4uXZ2pYMKHqJ3MNKR5gLjjA@mail.gmail.com>
	<CANSvah4NN05Zimm2BmKO9ofC04G+D7Svrg+2xwp0yM16Cn3CRw@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CANSvah4NN05Zimm2BmKO9ofC04G+D7Svrg+2xwp0yM16Cn3CRw@mail.gmail.com>
User-Agent: Mutt/1.4.2.1i
Cc: Aravindh Puthiyaparambil <aravindh@virtuata.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Keir Fraser <keir@xen.org>, andres@lagarcavilla.org,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] mem_event: fix regression affecting CR3,
	CR4 memory events
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At 23:56 -0400 on 10 Sep (1347321409), Steven Maresca wrote:
> On Mon, Sep 10, 2012 at 9:49 PM, Aravindh Puthiyaparambil
> <aravindh@virtuata.com> wrote:
> > On Mon, Sep 10, 2012 at 3:06 PM, Steven Maresca <steve@zentific.com> wrote:
> >> On Mon, Sep 10, 2012 at 5:39 PM, Keir Fraser <keir@xen.org> wrote:
> >>> On 10/09/2012 22:20, "Steven Maresca" <steve@zentific.com> wrote:
> >>>
> >>>> Given the refactoring in the commit related to the regression
> >>>> http://xenbits.xen.org/hg/xen-unstable.hg/rev/1276926e3795, it seemed
> >>>> (to me anyway) that inserting calls as shown in the patch would be
> >>>> cleaner, but I can definitely come up with some drawbacks.  However, I
> >>>> wanted to get this fixed for 4.2 if at all possible, so I wanted to
> >>>> send regardless.
> >>>>
> >>>> In terms of drawbacks, this will require some ifdefs for x86_64, for example.
> >>>>
> >>>> Any suggestions for the cleanest means of achieving the same in vmx.c?
> >>>
> >>> I don't understand this at all. The original commit moved some CR handling
> >>> to common HVM code. Your patch adds some mem_event calls into that common
> >>> HVM code. What would need to be "achieved" in vmx.c? What ifdefs would be
> >>> required for x86_64?
> >>>
> >>>  -- Keir
> >>>
> >>>
> >>
> >> Keir,
> >>
> >> In the process of moving CR handling to common code, that commit
> >> removed calls to hvm_memory_event_cr3() and hvm_memory_event_cr4().
> >> Without some patch restoring the calls to those two functions, current
> >> xen-unstable and xen-4.2-testing only reference them as function
> >> prototypes and function definitions -- there are no calls whatsoever.
> >>
> >> I only mentioned an ifdef relative to x86_64 because of the #ifdef
> >> __x86_64__  around the function definitions. ( I know in the hvm.h
> >> itself they're just empty inline functions if not __x86_64__. )
> >>
> >> Regarding vmx.c: hvm_memory_event_cr0 is called within vmx_cr_access.
> >> The patch I sent restoring the calls to hvm_memory_event_cr4 and
> >> hvm_memory_event_cr3 could be treated similarly, that's all.
> >
> > Looks good to me.
> > Acked-by: Aravindh Puthiyaparambil <aravindh@virtuata.com>
> >
> > Cheers,
> > Aravindh
> 
> Adding Tim Deegan as suggested.
> 
> Tim, this is a regression fix for CR3/CR4 memory events
> unintentionally removed during some refactoring of HVM CR handling.
> If at all possible, for 4.2 inclusion before we officially leave RC.

I think it's too late to get any more code changes in to 4.2.0, so this
will have to wait for 4.2.1.  Ian?

The patch looks OK, but why didn't you put the memory_event calls back
in mov_to_cr(), which is where they were before 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 Tue Sep 11 07:29:27 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 2012 07:29:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TBKuD-0004PF-4T; Tue, 11 Sep 2012 07:29: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 1TBKuB-0004P4-M5
	for xen-devel@lists.xen.org; Tue, 11 Sep 2012 07:29:07 +0000
Received: from [85.158.139.83:32272] by server-3.bemta-5.messagelabs.com id
	B9/F9-21836-248EE405; Tue, 11 Sep 2012 07:29:06 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1347348546!25490886!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM5NTk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1671 invoked from network); 11 Sep 2012 07:29:06 -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;
	11 Sep 2012 07:29:06 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 11 Sep 2012 08:29:05 +0100
Message-Id: <504F045E020000780009A6B2@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 11 Sep 2012 08:29:02 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Daniel De Graaf" <dgdegra@tycho.nsa.gov>
References: <1347306553-20980-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1347306553-20980-12-git-send-email-dgdegra@tycho.nsa.gov>
In-Reply-To: <1347306553-20980-12-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 11/20] xen: use XSM instead of IS_PRIV where
 duplicated
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.09.12 at 21:49, Daniel De Graaf <dgdegra@tycho.nsa.gov> wrote:
> Some checks are removed due to non-obvious duplicates in their callers:
> 
>  * acpi_enter_sleep is checked by its only caller
>  * map_domain_pirq has IS_PRIV_FOR checked in physdev_map_pirq

... and ioapic_guest_write(). Please have this list complete, as it
is going to be necessary to fully validate this (now and
retrospectively once applied) for the absence of security holes.

>  * PHYSDEVOP_alloc_irq_vector is a noop, does not need IS_PRIV

NAK. This nevertheless is a privileged operation (i.e. must not
succeed for unprivileged guests).

>  * Many PHYSDEVOP access checks are within the implementation functions

For the above named reason, please fully document this.

>  * do_platform_op, do_domctl, and do_sysctl all have per-operation
>    XSM hooks
>  * do_console_io has changed to IS_PRIV from an explicit domid==0

I see a point in actually limiting this to Dom0 - that's the only
domain that can't possibly have a virtual console. But I'm not
really opposed to changing this.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 11 07:29:27 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 2012 07:29:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TBKuD-0004PF-4T; Tue, 11 Sep 2012 07:29: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 1TBKuB-0004P4-M5
	for xen-devel@lists.xen.org; Tue, 11 Sep 2012 07:29:07 +0000
Received: from [85.158.139.83:32272] by server-3.bemta-5.messagelabs.com id
	B9/F9-21836-248EE405; Tue, 11 Sep 2012 07:29:06 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1347348546!25490886!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM5NTk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1671 invoked from network); 11 Sep 2012 07:29:06 -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;
	11 Sep 2012 07:29:06 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 11 Sep 2012 08:29:05 +0100
Message-Id: <504F045E020000780009A6B2@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 11 Sep 2012 08:29:02 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Daniel De Graaf" <dgdegra@tycho.nsa.gov>
References: <1347306553-20980-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1347306553-20980-12-git-send-email-dgdegra@tycho.nsa.gov>
In-Reply-To: <1347306553-20980-12-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 11/20] xen: use XSM instead of IS_PRIV where
 duplicated
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.09.12 at 21:49, Daniel De Graaf <dgdegra@tycho.nsa.gov> wrote:
> Some checks are removed due to non-obvious duplicates in their callers:
> 
>  * acpi_enter_sleep is checked by its only caller
>  * map_domain_pirq has IS_PRIV_FOR checked in physdev_map_pirq

... and ioapic_guest_write(). Please have this list complete, as it
is going to be necessary to fully validate this (now and
retrospectively once applied) for the absence of security holes.

>  * PHYSDEVOP_alloc_irq_vector is a noop, does not need IS_PRIV

NAK. This nevertheless is a privileged operation (i.e. must not
succeed for unprivileged guests).

>  * Many PHYSDEVOP access checks are within the implementation functions

For the above named reason, please fully document this.

>  * do_platform_op, do_domctl, and do_sysctl all have per-operation
>    XSM hooks
>  * do_console_io has changed to IS_PRIV from an explicit domid==0

I see a point in actually limiting this to Dom0 - that's the only
domain that can't possibly have a virtual console. But I'm not
really opposed to changing this.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 11 07:31:31 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 2012 07: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 1TBKwD-0004cx-E7; Tue, 11 Sep 2012 07:31:13 +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 1TBKwB-0004cg-LA
	for xen-devel@lists.xen.org; Tue, 11 Sep 2012 07:31:12 +0000
Received: from [85.158.143.35:12990] by server-1.bemta-4.messagelabs.com id
	CD/6B-12504-EB8EE405; Tue, 11 Sep 2012 07:31:10 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1347348189!17720346!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-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12363 invoked from network); 11 Sep 2012 07:23:10 -0000
Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com)
	(74.125.83.45)
	by server-14.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Sep 2012 07:23:10 -0000
Received: by eeke53 with SMTP id e53so110526eek.32
	for <xen-devel@lists.xen.org>; Tue, 11 Sep 2012 00:23:09 -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=B7zJJnIf2EuC9yiazAldl2hubr5RQowTPLBig3f0/pU=;
	b=wxr4HyymXqAEhlSQuwfHagU1HXHpiN8mha/aR0n1Z49sk/XD8/OpmQ1kP8tlfRzAtM
	1bOEh5iVBNGWz3rJv86iJL0MVB8B//LcVJlvkziY+UJkEM1A6OEdHcmsvrPxSuzoQcTD
	TtpgVsMg+s/voGSfEh0yuVs8O7DPQ+EwVNG5mIttVfhtRPByKlfxk0maSft+1e5UoxdZ
	qzw+KNSnBy34NNYNRnbvibbQhHkVUIlV3nLxiSEQ1KvZFMTOdeEYZ77YtobFqDv0NPp1
	bMnDYAS2Q5Iz7P/lT5K/GbTPPzzhiL4PWTrtklDyAmCXU4tO53V4jYBB5DlZYswoyjB3
	0ZOw==
Received: by 10.14.215.197 with SMTP id e45mr23782447eep.36.1347348189345;
	Tue, 11 Sep 2012 00:23:09 -0700 (PDT)
Received: from [192.168.1.69] (host86-184-74-117.range86-184.btcentralplus.com.
	[86.184.74.117])
	by mx.google.com with ESMTPS id l42sm44512324eep.1.2012.09.11.00.23.07
	(version=SSLv3 cipher=OTHER); Tue, 11 Sep 2012 00:23:08 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Tue, 11 Sep 2012 08:23:06 +0100
From: Keir Fraser <keir.xen@gmail.com>
To: Jan Beulich <JBeulich@suse.com>,
	xen-devel <xen-devel@lists.xen.org>
Message-ID: <CC74A56A.3E708%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [PATCH, v3] x86/HVM: assorted RTC emulation
	adjustments
Thread-Index: Ac2P7kllcHZmHO6mikCAj/1UfoF20g==
In-Reply-To: <504A0C420200007800099CD6@nat28.tlf.novell.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] [PATCH,
 v3] x86/HVM: assorted RTC emulation adjustments
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 07/09/2012 14:01, "Jan Beulich" <JBeulich@suse.com> wrote:

> - don't look at RTC_PIE in rtc_timer_update(), and hence don't call the
>   function on REG_B writes at all
> - only call alarm_timer_update() on REG_B writes when relevant bits
>   change
> - only call check_update_timer() on REG_B writes when SET changes
> - instead properly handle AF and PF when the guest is not also setting
>   AIE/PIE respectively (for UF this was already the case, only a
>   comment was slightly inaccurate)
> - raise the RTC IRQ not only when UIE gets set while UF was already
>   set, but generalize this to cover AIE and PIE as well
> - properly mask off bit 7 when retrieving the hour values in
>   alarm_timer_update(), and properly use RTC_HOURS_ALARM's bit 7 when
>   converting from 12- to 24-hour value
> - also handle the two other possible clock bases
> - use RTC_* names in a couple of places where literal numbers were used
>   so far
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Acked-by: Keir Fraser <keir@xen.org>

> --- a/xen/arch/x86/hvm/rtc.c
> +++ b/xen/arch/x86/hvm/rtc.c
> @@ -50,11 +50,24 @@ static void rtc_set_time(RTCState *s);
>  static inline int from_bcd(RTCState *s, int a);
>  static inline int convert_hour(RTCState *s, int hour);
>  
> -static void rtc_periodic_cb(struct vcpu *v, void *opaque)
> +static void rtc_toggle_irq(RTCState *s)
> +{
> +    struct domain *d = vrtc_domain(s);
> +
> +    ASSERT(spin_is_locked(&s->lock));
> +    s->hw.cmos_data[RTC_REG_C] |= RTC_IRQF;
> +    hvm_isa_irq_deassert(d, RTC_IRQ);
> +    hvm_isa_irq_assert(d, RTC_IRQ);
> +}
> +
> +void rtc_periodic_interrupt(void *opaque)
>  {
>      RTCState *s = opaque;
> +
>      spin_lock(&s->lock);
> -    s->hw.cmos_data[RTC_REG_C] |= 0xc0;
> +    s->hw.cmos_data[RTC_REG_C] |= RTC_PF;
> +    if ( s->hw.cmos_data[RTC_REG_B] & RTC_PIE )
> +        rtc_toggle_irq(s);
>      spin_unlock(&s->lock);
>  }
>  
> @@ -68,19 +81,25 @@ static void rtc_timer_update(RTCState *s
>      ASSERT(spin_is_locked(&s->lock));
>  
>      period_code = s->hw.cmos_data[RTC_REG_A] & RTC_RATE_SELECT;
> -    if ( (period_code != 0) && (s->hw.cmos_data[RTC_REG_B] & RTC_PIE) )
> +    switch ( s->hw.cmos_data[RTC_REG_A] & RTC_DIV_CTL )
>      {
> -        if ( period_code <= 2 )
> +    case RTC_REF_CLCK_32KHZ:
> +        if ( (period_code != 0) && (period_code <= 2) )
>              period_code += 7;
> -
> -        period = 1 << (period_code - 1); /* period in 32 Khz cycles */
> -        period = DIV_ROUND((period * 1000000000ULL), 32768); /* period in ns
> */
> -        create_periodic_time(v, &s->pt, period, period, RTC_IRQ,
> -                             rtc_periodic_cb, s);
> -    }
> -    else
> -    {
> +        /* fall through */
> +    case RTC_REF_CLCK_1MHZ:
> +    case RTC_REF_CLCK_4MHZ:
> +        if ( period_code != 0 )
> +        {
> +            period = 1 << (period_code - 1); /* period in 32 Khz cycles */
> +            period = DIV_ROUND(period * 1000000000ULL, 32768); /* in ns */
> +            create_periodic_time(v, &s->pt, period, period, RTC_IRQ, NULL,
> s);
> +            break;
> +        }
> +        /* fall through */
> +    default:
>          destroy_periodic_time(&s->pt);
> +        break;
>      }
>  }
>  
> @@ -102,7 +121,7 @@ static void check_update_timer(RTCState
>          guest_usec = get_localtime_us(d) % USEC_PER_SEC;
>          if (guest_usec >= (USEC_PER_SEC - 244))
>          {
> -            /* RTC is in update cycle when enabling UIE */
> +            /* RTC is in update cycle */
>              s->hw.cmos_data[RTC_REG_A] |= RTC_UIP;
>              next_update_time = (USEC_PER_SEC - guest_usec) * NS_PER_USEC;
>              expire_time = NOW() + next_update_time;
> @@ -144,7 +163,6 @@ static void rtc_update_timer(void *opaqu
>  static void rtc_update_timer2(void *opaque)
>  {
>      RTCState *s = opaque;
> -    struct domain *d = vrtc_domain(s);
>  
>      spin_lock(&s->lock);
>      if (!(s->hw.cmos_data[RTC_REG_B] & RTC_SET))
> @@ -152,11 +170,7 @@ static void rtc_update_timer2(void *opaq
>          s->hw.cmos_data[RTC_REG_C] |= RTC_UF;
>          s->hw.cmos_data[RTC_REG_A] &= ~RTC_UIP;
>          if ((s->hw.cmos_data[RTC_REG_B] & RTC_UIE))
> -        {
> -            s->hw.cmos_data[RTC_REG_C] |= RTC_IRQF;
> -            hvm_isa_irq_deassert(d, RTC_IRQ);
> -            hvm_isa_irq_assert(d, RTC_IRQ);
> -        }
> +            rtc_toggle_irq(s);
>          check_update_timer(s);
>      }
>      spin_unlock(&s->lock);
> @@ -175,21 +189,18 @@ static void alarm_timer_update(RTCState
>  
>      stop_timer(&s->alarm_timer);
>  
> -    if ((s->hw.cmos_data[RTC_REG_B] & RTC_AIE) &&
> -            !(s->hw.cmos_data[RTC_REG_B] & RTC_SET))
> +    if ( !(s->hw.cmos_data[RTC_REG_B] & RTC_SET) )
>      {
>          s->current_tm = gmtime(get_localtime(d));
>          rtc_copy_date(s);
>  
>          alarm_sec = from_bcd(s, s->hw.cmos_data[RTC_SECONDS_ALARM]);
>          alarm_min = from_bcd(s, s->hw.cmos_data[RTC_MINUTES_ALARM]);
> -        alarm_hour = from_bcd(s, s->hw.cmos_data[RTC_HOURS_ALARM]);
> -        alarm_hour = convert_hour(s, alarm_hour);
> +        alarm_hour = convert_hour(s, s->hw.cmos_data[RTC_HOURS_ALARM]);
>  
>          cur_sec = from_bcd(s, s->hw.cmos_data[RTC_SECONDS]);
>          cur_min = from_bcd(s, s->hw.cmos_data[RTC_MINUTES]);
> -        cur_hour = from_bcd(s, s->hw.cmos_data[RTC_HOURS]);
> -        cur_hour = convert_hour(s, cur_hour);
> +        cur_hour = convert_hour(s, s->hw.cmos_data[RTC_HOURS]);
>  
>          next_update_time = USEC_PER_SEC - (get_localtime_us(d) %
> USEC_PER_SEC);
>          next_update_time = next_update_time * NS_PER_USEC + NOW();
> @@ -343,7 +354,6 @@ static void alarm_timer_update(RTCState
>  static void rtc_alarm_cb(void *opaque)
>  {
>      RTCState *s = opaque;
> -    struct domain *d = vrtc_domain(s);
>  
>      spin_lock(&s->lock);
>      if (!(s->hw.cmos_data[RTC_REG_B] & RTC_SET))
> @@ -351,11 +361,7 @@ static void rtc_alarm_cb(void *opaque)
>          s->hw.cmos_data[RTC_REG_C] |= RTC_AF;
>          /* alarm interrupt */
>          if (s->hw.cmos_data[RTC_REG_B] & RTC_AIE)
> -        {
> -            s->hw.cmos_data[RTC_REG_C] |= RTC_IRQF;
> -            hvm_isa_irq_deassert(d, RTC_IRQ);
> -            hvm_isa_irq_assert(d, RTC_IRQ);
> -        }
> +            rtc_toggle_irq(s);
>          alarm_timer_update(s);
>      }
>      spin_unlock(&s->lock);
> @@ -365,7 +371,7 @@ static int rtc_ioport_write(void *opaque
>  {
>      RTCState *s = opaque;
>      struct domain *d = vrtc_domain(s);
> -    uint32_t orig;
> +    uint32_t orig, mask;
>  
>      spin_lock(&s->lock);
>  
> @@ -417,7 +423,7 @@ static int rtc_ioport_write(void *opaque
>              /* set mode: reset UIP mode */
>              s->hw.cmos_data[RTC_REG_A] &= ~RTC_UIP;
>              /* adjust cmos before stopping */
> -            if (!(s->hw.cmos_data[RTC_REG_B] & RTC_SET))
> +            if (!(orig & RTC_SET))
>              {
>                  s->current_tm = gmtime(get_localtime(d));
>                  rtc_copy_date(s);
> @@ -426,22 +432,26 @@ static int rtc_ioport_write(void *opaque
>          else
>          {
>              /* if disabling set mode, update the time */
> -            if ( s->hw.cmos_data[RTC_REG_B] & RTC_SET )
> +            if ( orig & RTC_SET )
>                  rtc_set_time(s);
>          }
> -        /* if the interrupt is already set when the interrupt become
> -         * enabled, raise an interrupt immediately*/
> -        if ((data & RTC_UIE) && !(s->hw.cmos_data[RTC_REG_B] & RTC_UIE))
> -            if (s->hw.cmos_data[RTC_REG_C] & RTC_UF)
> +        /*
> +         * If the interrupt is already set when the interrupt becomes
> +         * enabled, raise an interrupt immediately.
> +         * NB: RTC_{A,P,U}IE == RTC_{A,P,U}F respectively.
> +         */
> +        for ( mask = RTC_UIE; mask <= RTC_PIE; mask <<= 1 )
> +            if ( (data & mask) && !(orig & mask) &&
> +                 (s->hw.cmos_data[RTC_REG_C] & mask) )
>              {
> -                hvm_isa_irq_deassert(d, RTC_IRQ);
> -                hvm_isa_irq_assert(d, RTC_IRQ);
> +                rtc_toggle_irq(s);
> +                break;
>              }
>          s->hw.cmos_data[RTC_REG_B] = data;
> -        if ( (data ^ orig) & RTC_PIE )
> -            rtc_timer_update(s);
> -        check_update_timer(s);
> -        alarm_timer_update(s);
> +        if ( (data ^ orig) & RTC_SET )
> +            check_update_timer(s);
> +        if ( (data ^ orig) & (RTC_24H | RTC_DM_BINARY | RTC_SET) )
> +            alarm_timer_update(s);
>          break;
>      case RTC_REG_C:
>      case RTC_REG_D:
> @@ -456,7 +466,7 @@ static int rtc_ioport_write(void *opaque
>  
>  static inline int to_bcd(RTCState *s, int a)
>  {
> -    if ( s->hw.cmos_data[RTC_REG_B] & 0x04 )
> +    if ( s->hw.cmos_data[RTC_REG_B] & RTC_DM_BINARY )
>          return a;
>      else
>          return ((a / 10) << 4) | (a % 10);
> @@ -464,7 +474,7 @@ static inline int to_bcd(RTCState *s, in
>  
>  static inline int from_bcd(RTCState *s, int a)
>  {
> -    if ( s->hw.cmos_data[RTC_REG_B] & 0x04 )
> +    if ( s->hw.cmos_data[RTC_REG_B] & RTC_DM_BINARY )
>          return a;
>      else
>          return ((a >> 4) * 10) + (a & 0x0f);
> @@ -472,12 +482,14 @@ static inline int from_bcd(RTCState *s,
>  
>  /* Hours in 12 hour mode are in 1-12 range, not 0-11.
>   * So we need convert it before using it*/
> -static inline int convert_hour(RTCState *s, int hour)
> +static inline int convert_hour(RTCState *s, int raw)
>  {
> +    int hour = from_bcd(s, raw & 0x7f);
> +
>      if (!(s->hw.cmos_data[RTC_REG_B] & RTC_24H))
>      {
>          hour %= 12;
> -        if (s->hw.cmos_data[RTC_HOURS] & 0x80)
> +        if (raw & 0x80)
>              hour += 12;
>      }
>      return hour;
> @@ -496,8 +508,7 @@ static void rtc_set_time(RTCState *s)
>      
>      tm->tm_sec = from_bcd(s, s->hw.cmos_data[RTC_SECONDS]);
>      tm->tm_min = from_bcd(s, s->hw.cmos_data[RTC_MINUTES]);
> -    tm->tm_hour = from_bcd(s, s->hw.cmos_data[RTC_HOURS] & 0x7f);
> -    tm->tm_hour = convert_hour(s, tm->tm_hour);
> +    tm->tm_hour = convert_hour(s, s->hw.cmos_data[RTC_HOURS]);
>      tm->tm_wday = from_bcd(s, s->hw.cmos_data[RTC_DAY_OF_WEEK]);
>      tm->tm_mday = from_bcd(s, s->hw.cmos_data[RTC_DAY_OF_MONTH]);
>      tm->tm_mon = from_bcd(s, s->hw.cmos_data[RTC_MONTH]) - 1;
> --- a/xen/arch/x86/hvm/vpt.c
> +++ b/xen/arch/x86/hvm/vpt.c
> @@ -22,6 +22,7 @@
>  #include <asm/hvm/vpt.h>
>  #include <asm/event.h>
>  #include <asm/apic.h>
> +#include <asm/mc146818rtc.h>
>  
>  #define mode_is(d, name) \
>      ((d)->arch.hvm_domain.params[HVM_PARAM_TIMER_MODE] == HVMPTM_##name)
> @@ -218,6 +219,7 @@ void pt_update_irq(struct vcpu *v)
>      struct periodic_time *pt, *temp, *earliest_pt = NULL;
>      uint64_t max_lag = -1ULL;
>      int irq, is_lapic;
> +    void *pt_priv;
>  
>      spin_lock(&v->arch.hvm_vcpu.tm_lock);
>  
> @@ -251,13 +253,14 @@ void pt_update_irq(struct vcpu *v)
>      earliest_pt->irq_issued = 1;
>      irq = earliest_pt->irq;
>      is_lapic = (earliest_pt->source == PTSRC_lapic);
> +    pt_priv = earliest_pt->priv;
>  
>      spin_unlock(&v->arch.hvm_vcpu.tm_lock);
>  
>      if ( is_lapic )
> -    {
>          vlapic_set_irq(vcpu_vlapic(v), irq, 0);
> -    }
> +    else if ( irq == RTC_IRQ && pt_priv )
> +        rtc_periodic_interrupt(pt_priv);
>      else
>      {
>          hvm_isa_irq_deassert(v->domain, irq);
> --- a/xen/include/asm-x86/hvm/vpt.h
> +++ b/xen/include/asm-x86/hvm/vpt.h
> @@ -181,6 +181,7 @@ void rtc_migrate_timers(struct vcpu *v);
>  void rtc_deinit(struct domain *d);
>  void rtc_reset(struct domain *d);
>  void rtc_update_clock(struct domain *d);
> +void rtc_periodic_interrupt(void *);
>  
>  void pmtimer_init(struct vcpu *v);
>  void pmtimer_deinit(struct domain *d);
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 11 07:31:31 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 2012 07: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 1TBKwD-0004cx-E7; Tue, 11 Sep 2012 07:31:13 +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 1TBKwB-0004cg-LA
	for xen-devel@lists.xen.org; Tue, 11 Sep 2012 07:31:12 +0000
Received: from [85.158.143.35:12990] by server-1.bemta-4.messagelabs.com id
	CD/6B-12504-EB8EE405; Tue, 11 Sep 2012 07:31:10 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1347348189!17720346!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-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12363 invoked from network); 11 Sep 2012 07:23:10 -0000
Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com)
	(74.125.83.45)
	by server-14.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Sep 2012 07:23:10 -0000
Received: by eeke53 with SMTP id e53so110526eek.32
	for <xen-devel@lists.xen.org>; Tue, 11 Sep 2012 00:23:09 -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=B7zJJnIf2EuC9yiazAldl2hubr5RQowTPLBig3f0/pU=;
	b=wxr4HyymXqAEhlSQuwfHagU1HXHpiN8mha/aR0n1Z49sk/XD8/OpmQ1kP8tlfRzAtM
	1bOEh5iVBNGWz3rJv86iJL0MVB8B//LcVJlvkziY+UJkEM1A6OEdHcmsvrPxSuzoQcTD
	TtpgVsMg+s/voGSfEh0yuVs8O7DPQ+EwVNG5mIttVfhtRPByKlfxk0maSft+1e5UoxdZ
	qzw+KNSnBy34NNYNRnbvibbQhHkVUIlV3nLxiSEQ1KvZFMTOdeEYZ77YtobFqDv0NPp1
	bMnDYAS2Q5Iz7P/lT5K/GbTPPzzhiL4PWTrtklDyAmCXU4tO53V4jYBB5DlZYswoyjB3
	0ZOw==
Received: by 10.14.215.197 with SMTP id e45mr23782447eep.36.1347348189345;
	Tue, 11 Sep 2012 00:23:09 -0700 (PDT)
Received: from [192.168.1.69] (host86-184-74-117.range86-184.btcentralplus.com.
	[86.184.74.117])
	by mx.google.com with ESMTPS id l42sm44512324eep.1.2012.09.11.00.23.07
	(version=SSLv3 cipher=OTHER); Tue, 11 Sep 2012 00:23:08 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Tue, 11 Sep 2012 08:23:06 +0100
From: Keir Fraser <keir.xen@gmail.com>
To: Jan Beulich <JBeulich@suse.com>,
	xen-devel <xen-devel@lists.xen.org>
Message-ID: <CC74A56A.3E708%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [PATCH, v3] x86/HVM: assorted RTC emulation
	adjustments
Thread-Index: Ac2P7kllcHZmHO6mikCAj/1UfoF20g==
In-Reply-To: <504A0C420200007800099CD6@nat28.tlf.novell.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] [PATCH,
 v3] x86/HVM: assorted RTC emulation adjustments
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 07/09/2012 14:01, "Jan Beulich" <JBeulich@suse.com> wrote:

> - don't look at RTC_PIE in rtc_timer_update(), and hence don't call the
>   function on REG_B writes at all
> - only call alarm_timer_update() on REG_B writes when relevant bits
>   change
> - only call check_update_timer() on REG_B writes when SET changes
> - instead properly handle AF and PF when the guest is not also setting
>   AIE/PIE respectively (for UF this was already the case, only a
>   comment was slightly inaccurate)
> - raise the RTC IRQ not only when UIE gets set while UF was already
>   set, but generalize this to cover AIE and PIE as well
> - properly mask off bit 7 when retrieving the hour values in
>   alarm_timer_update(), and properly use RTC_HOURS_ALARM's bit 7 when
>   converting from 12- to 24-hour value
> - also handle the two other possible clock bases
> - use RTC_* names in a couple of places where literal numbers were used
>   so far
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Acked-by: Keir Fraser <keir@xen.org>

> --- a/xen/arch/x86/hvm/rtc.c
> +++ b/xen/arch/x86/hvm/rtc.c
> @@ -50,11 +50,24 @@ static void rtc_set_time(RTCState *s);
>  static inline int from_bcd(RTCState *s, int a);
>  static inline int convert_hour(RTCState *s, int hour);
>  
> -static void rtc_periodic_cb(struct vcpu *v, void *opaque)
> +static void rtc_toggle_irq(RTCState *s)
> +{
> +    struct domain *d = vrtc_domain(s);
> +
> +    ASSERT(spin_is_locked(&s->lock));
> +    s->hw.cmos_data[RTC_REG_C] |= RTC_IRQF;
> +    hvm_isa_irq_deassert(d, RTC_IRQ);
> +    hvm_isa_irq_assert(d, RTC_IRQ);
> +}
> +
> +void rtc_periodic_interrupt(void *opaque)
>  {
>      RTCState *s = opaque;
> +
>      spin_lock(&s->lock);
> -    s->hw.cmos_data[RTC_REG_C] |= 0xc0;
> +    s->hw.cmos_data[RTC_REG_C] |= RTC_PF;
> +    if ( s->hw.cmos_data[RTC_REG_B] & RTC_PIE )
> +        rtc_toggle_irq(s);
>      spin_unlock(&s->lock);
>  }
>  
> @@ -68,19 +81,25 @@ static void rtc_timer_update(RTCState *s
>      ASSERT(spin_is_locked(&s->lock));
>  
>      period_code = s->hw.cmos_data[RTC_REG_A] & RTC_RATE_SELECT;
> -    if ( (period_code != 0) && (s->hw.cmos_data[RTC_REG_B] & RTC_PIE) )
> +    switch ( s->hw.cmos_data[RTC_REG_A] & RTC_DIV_CTL )
>      {
> -        if ( period_code <= 2 )
> +    case RTC_REF_CLCK_32KHZ:
> +        if ( (period_code != 0) && (period_code <= 2) )
>              period_code += 7;
> -
> -        period = 1 << (period_code - 1); /* period in 32 Khz cycles */
> -        period = DIV_ROUND((period * 1000000000ULL), 32768); /* period in ns
> */
> -        create_periodic_time(v, &s->pt, period, period, RTC_IRQ,
> -                             rtc_periodic_cb, s);
> -    }
> -    else
> -    {
> +        /* fall through */
> +    case RTC_REF_CLCK_1MHZ:
> +    case RTC_REF_CLCK_4MHZ:
> +        if ( period_code != 0 )
> +        {
> +            period = 1 << (period_code - 1); /* period in 32 Khz cycles */
> +            period = DIV_ROUND(period * 1000000000ULL, 32768); /* in ns */
> +            create_periodic_time(v, &s->pt, period, period, RTC_IRQ, NULL,
> s);
> +            break;
> +        }
> +        /* fall through */
> +    default:
>          destroy_periodic_time(&s->pt);
> +        break;
>      }
>  }
>  
> @@ -102,7 +121,7 @@ static void check_update_timer(RTCState
>          guest_usec = get_localtime_us(d) % USEC_PER_SEC;
>          if (guest_usec >= (USEC_PER_SEC - 244))
>          {
> -            /* RTC is in update cycle when enabling UIE */
> +            /* RTC is in update cycle */
>              s->hw.cmos_data[RTC_REG_A] |= RTC_UIP;
>              next_update_time = (USEC_PER_SEC - guest_usec) * NS_PER_USEC;
>              expire_time = NOW() + next_update_time;
> @@ -144,7 +163,6 @@ static void rtc_update_timer(void *opaqu
>  static void rtc_update_timer2(void *opaque)
>  {
>      RTCState *s = opaque;
> -    struct domain *d = vrtc_domain(s);
>  
>      spin_lock(&s->lock);
>      if (!(s->hw.cmos_data[RTC_REG_B] & RTC_SET))
> @@ -152,11 +170,7 @@ static void rtc_update_timer2(void *opaq
>          s->hw.cmos_data[RTC_REG_C] |= RTC_UF;
>          s->hw.cmos_data[RTC_REG_A] &= ~RTC_UIP;
>          if ((s->hw.cmos_data[RTC_REG_B] & RTC_UIE))
> -        {
> -            s->hw.cmos_data[RTC_REG_C] |= RTC_IRQF;
> -            hvm_isa_irq_deassert(d, RTC_IRQ);
> -            hvm_isa_irq_assert(d, RTC_IRQ);
> -        }
> +            rtc_toggle_irq(s);
>          check_update_timer(s);
>      }
>      spin_unlock(&s->lock);
> @@ -175,21 +189,18 @@ static void alarm_timer_update(RTCState
>  
>      stop_timer(&s->alarm_timer);
>  
> -    if ((s->hw.cmos_data[RTC_REG_B] & RTC_AIE) &&
> -            !(s->hw.cmos_data[RTC_REG_B] & RTC_SET))
> +    if ( !(s->hw.cmos_data[RTC_REG_B] & RTC_SET) )
>      {
>          s->current_tm = gmtime(get_localtime(d));
>          rtc_copy_date(s);
>  
>          alarm_sec = from_bcd(s, s->hw.cmos_data[RTC_SECONDS_ALARM]);
>          alarm_min = from_bcd(s, s->hw.cmos_data[RTC_MINUTES_ALARM]);
> -        alarm_hour = from_bcd(s, s->hw.cmos_data[RTC_HOURS_ALARM]);
> -        alarm_hour = convert_hour(s, alarm_hour);
> +        alarm_hour = convert_hour(s, s->hw.cmos_data[RTC_HOURS_ALARM]);
>  
>          cur_sec = from_bcd(s, s->hw.cmos_data[RTC_SECONDS]);
>          cur_min = from_bcd(s, s->hw.cmos_data[RTC_MINUTES]);
> -        cur_hour = from_bcd(s, s->hw.cmos_data[RTC_HOURS]);
> -        cur_hour = convert_hour(s, cur_hour);
> +        cur_hour = convert_hour(s, s->hw.cmos_data[RTC_HOURS]);
>  
>          next_update_time = USEC_PER_SEC - (get_localtime_us(d) %
> USEC_PER_SEC);
>          next_update_time = next_update_time * NS_PER_USEC + NOW();
> @@ -343,7 +354,6 @@ static void alarm_timer_update(RTCState
>  static void rtc_alarm_cb(void *opaque)
>  {
>      RTCState *s = opaque;
> -    struct domain *d = vrtc_domain(s);
>  
>      spin_lock(&s->lock);
>      if (!(s->hw.cmos_data[RTC_REG_B] & RTC_SET))
> @@ -351,11 +361,7 @@ static void rtc_alarm_cb(void *opaque)
>          s->hw.cmos_data[RTC_REG_C] |= RTC_AF;
>          /* alarm interrupt */
>          if (s->hw.cmos_data[RTC_REG_B] & RTC_AIE)
> -        {
> -            s->hw.cmos_data[RTC_REG_C] |= RTC_IRQF;
> -            hvm_isa_irq_deassert(d, RTC_IRQ);
> -            hvm_isa_irq_assert(d, RTC_IRQ);
> -        }
> +            rtc_toggle_irq(s);
>          alarm_timer_update(s);
>      }
>      spin_unlock(&s->lock);
> @@ -365,7 +371,7 @@ static int rtc_ioport_write(void *opaque
>  {
>      RTCState *s = opaque;
>      struct domain *d = vrtc_domain(s);
> -    uint32_t orig;
> +    uint32_t orig, mask;
>  
>      spin_lock(&s->lock);
>  
> @@ -417,7 +423,7 @@ static int rtc_ioport_write(void *opaque
>              /* set mode: reset UIP mode */
>              s->hw.cmos_data[RTC_REG_A] &= ~RTC_UIP;
>              /* adjust cmos before stopping */
> -            if (!(s->hw.cmos_data[RTC_REG_B] & RTC_SET))
> +            if (!(orig & RTC_SET))
>              {
>                  s->current_tm = gmtime(get_localtime(d));
>                  rtc_copy_date(s);
> @@ -426,22 +432,26 @@ static int rtc_ioport_write(void *opaque
>          else
>          {
>              /* if disabling set mode, update the time */
> -            if ( s->hw.cmos_data[RTC_REG_B] & RTC_SET )
> +            if ( orig & RTC_SET )
>                  rtc_set_time(s);
>          }
> -        /* if the interrupt is already set when the interrupt become
> -         * enabled, raise an interrupt immediately*/
> -        if ((data & RTC_UIE) && !(s->hw.cmos_data[RTC_REG_B] & RTC_UIE))
> -            if (s->hw.cmos_data[RTC_REG_C] & RTC_UF)
> +        /*
> +         * If the interrupt is already set when the interrupt becomes
> +         * enabled, raise an interrupt immediately.
> +         * NB: RTC_{A,P,U}IE == RTC_{A,P,U}F respectively.
> +         */
> +        for ( mask = RTC_UIE; mask <= RTC_PIE; mask <<= 1 )
> +            if ( (data & mask) && !(orig & mask) &&
> +                 (s->hw.cmos_data[RTC_REG_C] & mask) )
>              {
> -                hvm_isa_irq_deassert(d, RTC_IRQ);
> -                hvm_isa_irq_assert(d, RTC_IRQ);
> +                rtc_toggle_irq(s);
> +                break;
>              }
>          s->hw.cmos_data[RTC_REG_B] = data;
> -        if ( (data ^ orig) & RTC_PIE )
> -            rtc_timer_update(s);
> -        check_update_timer(s);
> -        alarm_timer_update(s);
> +        if ( (data ^ orig) & RTC_SET )
> +            check_update_timer(s);
> +        if ( (data ^ orig) & (RTC_24H | RTC_DM_BINARY | RTC_SET) )
> +            alarm_timer_update(s);
>          break;
>      case RTC_REG_C:
>      case RTC_REG_D:
> @@ -456,7 +466,7 @@ static int rtc_ioport_write(void *opaque
>  
>  static inline int to_bcd(RTCState *s, int a)
>  {
> -    if ( s->hw.cmos_data[RTC_REG_B] & 0x04 )
> +    if ( s->hw.cmos_data[RTC_REG_B] & RTC_DM_BINARY )
>          return a;
>      else
>          return ((a / 10) << 4) | (a % 10);
> @@ -464,7 +474,7 @@ static inline int to_bcd(RTCState *s, in
>  
>  static inline int from_bcd(RTCState *s, int a)
>  {
> -    if ( s->hw.cmos_data[RTC_REG_B] & 0x04 )
> +    if ( s->hw.cmos_data[RTC_REG_B] & RTC_DM_BINARY )
>          return a;
>      else
>          return ((a >> 4) * 10) + (a & 0x0f);
> @@ -472,12 +482,14 @@ static inline int from_bcd(RTCState *s,
>  
>  /* Hours in 12 hour mode are in 1-12 range, not 0-11.
>   * So we need convert it before using it*/
> -static inline int convert_hour(RTCState *s, int hour)
> +static inline int convert_hour(RTCState *s, int raw)
>  {
> +    int hour = from_bcd(s, raw & 0x7f);
> +
>      if (!(s->hw.cmos_data[RTC_REG_B] & RTC_24H))
>      {
>          hour %= 12;
> -        if (s->hw.cmos_data[RTC_HOURS] & 0x80)
> +        if (raw & 0x80)
>              hour += 12;
>      }
>      return hour;
> @@ -496,8 +508,7 @@ static void rtc_set_time(RTCState *s)
>      
>      tm->tm_sec = from_bcd(s, s->hw.cmos_data[RTC_SECONDS]);
>      tm->tm_min = from_bcd(s, s->hw.cmos_data[RTC_MINUTES]);
> -    tm->tm_hour = from_bcd(s, s->hw.cmos_data[RTC_HOURS] & 0x7f);
> -    tm->tm_hour = convert_hour(s, tm->tm_hour);
> +    tm->tm_hour = convert_hour(s, s->hw.cmos_data[RTC_HOURS]);
>      tm->tm_wday = from_bcd(s, s->hw.cmos_data[RTC_DAY_OF_WEEK]);
>      tm->tm_mday = from_bcd(s, s->hw.cmos_data[RTC_DAY_OF_MONTH]);
>      tm->tm_mon = from_bcd(s, s->hw.cmos_data[RTC_MONTH]) - 1;
> --- a/xen/arch/x86/hvm/vpt.c
> +++ b/xen/arch/x86/hvm/vpt.c
> @@ -22,6 +22,7 @@
>  #include <asm/hvm/vpt.h>
>  #include <asm/event.h>
>  #include <asm/apic.h>
> +#include <asm/mc146818rtc.h>
>  
>  #define mode_is(d, name) \
>      ((d)->arch.hvm_domain.params[HVM_PARAM_TIMER_MODE] == HVMPTM_##name)
> @@ -218,6 +219,7 @@ void pt_update_irq(struct vcpu *v)
>      struct periodic_time *pt, *temp, *earliest_pt = NULL;
>      uint64_t max_lag = -1ULL;
>      int irq, is_lapic;
> +    void *pt_priv;
>  
>      spin_lock(&v->arch.hvm_vcpu.tm_lock);
>  
> @@ -251,13 +253,14 @@ void pt_update_irq(struct vcpu *v)
>      earliest_pt->irq_issued = 1;
>      irq = earliest_pt->irq;
>      is_lapic = (earliest_pt->source == PTSRC_lapic);
> +    pt_priv = earliest_pt->priv;
>  
>      spin_unlock(&v->arch.hvm_vcpu.tm_lock);
>  
>      if ( is_lapic )
> -    {
>          vlapic_set_irq(vcpu_vlapic(v), irq, 0);
> -    }
> +    else if ( irq == RTC_IRQ && pt_priv )
> +        rtc_periodic_interrupt(pt_priv);
>      else
>      {
>          hvm_isa_irq_deassert(v->domain, irq);
> --- a/xen/include/asm-x86/hvm/vpt.h
> +++ b/xen/include/asm-x86/hvm/vpt.h
> @@ -181,6 +181,7 @@ void rtc_migrate_timers(struct vcpu *v);
>  void rtc_deinit(struct domain *d);
>  void rtc_reset(struct domain *d);
>  void rtc_update_clock(struct domain *d);
> +void rtc_periodic_interrupt(void *);
>  
>  void pmtimer_init(struct vcpu *v);
>  void pmtimer_deinit(struct domain *d);
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 11 07:34:22 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 2012 07:34:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TBKyw-0004xX-5N; Tue, 11 Sep 2012 07:34:02 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <gbtju85@gmail.com>) id 1TBKyv-0004xN-0Y
	for xen-devel@lists.xen.org; Tue, 11 Sep 2012 07:34:01 +0000
Received: from [85.158.138.51:9090] by server-6.bemta-3.messagelabs.com id
	2E/31-29694-869EE405; Tue, 11 Sep 2012 07:34:00 +0000
X-Env-Sender: gbtju85@gmail.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1347348839!21893492!1
X-Originating-IP: [209.85.217.173]
X-SpamReason: No, hits=0.7 required=7.0 tests=HTML_30_40,HTML_MESSAGE,
	MAILTO_TO_SPAM_ADDR,ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12527 invoked from network); 11 Sep 2012 07:33:59 -0000
Received: from mail-lb0-f173.google.com (HELO mail-lb0-f173.google.com)
	(209.85.217.173)
	by server-12.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Sep 2012 07:33:59 -0000
Received: by lbbgm13 with SMTP id gm13so209355lbb.32
	for <xen-devel@lists.xen.org>; Tue, 11 Sep 2012 00:33: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:date:message-id:subject:from:to
	:cc:content-type;
	bh=LNFxMhm20yCT/gy0+K2RFYiwQRneaCkMilhb36LTCv4=;
	b=gBPlM6P1Lpkpn8amk+Y5FwL4ICLghmq7udAVUgOFJGTrlWFBkkXbdqj17P0iG0uFtt
	kR0PMIid2n7fiJSYZlBUb2cJeL5Qu/8mHHAVcXIazB+1wOyOK8nxMYuMFFnS4Y5t4JGb
	MFgGAKtqKB7FKqLPbYh6On99fe7esTM3EfzDZojwOoeAZB8oqCN+ffAmtKYT9ye0AsJz
	SE94jlN4na0x1+b0w03a3V4RS359QkUZpmtPG+z+A6aWhyc9RQ6DFqs7cedSAKy9fAR4
	7ewAjMPQsCkBmVdNrUeKifAzpWmTtXCNpGXWEIIRAdj13fHDyzRN0ukjACuuDCF/TAg+
	ImPg==
MIME-Version: 1.0
Received: by 10.112.43.98 with SMTP id v2mr5827083lbl.1.1347348838645; Tue, 11
	Sep 2012 00:33:58 -0700 (PDT)
Received: by 10.114.2.193 with HTTP; Tue, 11 Sep 2012 00:33:58 -0700 (PDT)
In-Reply-To: <CAG1y0scdfRzY97u7tty61Z2rFSqXzFxdVOw6WLk0MTKAZ+VJpA@mail.gmail.com>
References: <CAEQjb-TO9wy74up6pGfaRj+FQH8SPJtLXngM70ivWwWaQ53QPA@mail.gmail.com>
	<20120910192456.GA28298@phenom.dumpdata.com>
	<CAEQjb-QG71pnKQsWP1LLhpzXjkJUi+oRjFzLGZZZZSDJqo_BJA@mail.gmail.com>
	<CAG1y0scdfRzY97u7tty61Z2rFSqXzFxdVOw6WLk0MTKAZ+VJpA@mail.gmail.com>
Date: Tue, 11 Sep 2012 15:33:58 +0800
Message-ID: <CAEQjb-SBXK8x18Jg0e-K9snwSE1VdUjf4CPLprTqYG9xiTDm8w@mail.gmail.com>
From: Bei Guan <gbtju85@gmail.com>
To: "Fajar A. Nugraha" <list@fajar.net>
Cc: Konrad Rzeszutek Wilk <konrad@kernel.org>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Any news or plan about Xen support the APU
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============6801750793812101181=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============6801750793812101181==
Content-Type: multipart/alternative; boundary=e0cb4efa6e7eea814a04c9681810

--e0cb4efa6e7eea814a04c9681810
Content-Type: text/plain; charset=ISO-8859-1

2012/9/11 Fajar A. Nugraha <list@fajar.net>

> On Tue, Sep 11, 2012 at 8:27 AM, Bei Guan <gbtju85@gmail.com> wrote:
> > Hi Konrad,
> >
> > Thank you very much for your reply. I'm not hitting any issues.
> >
> > AMD's APU is a new kind of processing device, which integrates a CPU and
> a
> > GPU on the same die. I want to know whether Xen has supported the
> > virtualization of the APU processors? If yes, I can run something
> > applications in the Xen PV VMs to use this kind of new CPU device.
>
> AFAIK at this point AMD APUs are simply CPU + GPU. Even though they're
> in the same die, they're basically different devices. So for the GPU
> part, treat it like any other GPU. Which means you could PROBABLY
> passthru it to ONE domU, but that's it.
>
Hi Fajar,

Thank you for your information.
Passthrough is a good method for a VM to use the GPU device. However, the
GPU is exclusively used by a VM in this way. It cannot be shared among
several VMs. I noticed that there are several projects implementing the
virtualization of GPU devices on Xen, such as vCUDA (Hunan University, CN,
2009) and GViM (Georgia IT). But, is there any plan with Xen support the
GPU virtualization in the Xen official code?



Best Regards,
Bei Guan



>
> AMD's plan for the future is make a chip which can function as CPU or
> GPU as needed, but that hasn't happened yet.
>
> --
> Fajar
>



-- 
Best Regards,
Bei Guan

--e0cb4efa6e7eea814a04c9681810
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br><br><div class=3D"gmail_quote">2012/9/11 Fajar A. Nugraha <span dir=3D"=
ltr">&lt;<a href=3D"mailto:list@fajar.net" target=3D"_blank">list@fajar.net=
</a>&gt;</span><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 Tue, Sep 11, 2012 at 8:27 AM, Bei Guan &lt;<a href=3D"=
mailto:gbtju85@gmail.com">gbtju85@gmail.com</a>&gt; wrote:<br>
&gt; Hi Konrad,<br>
&gt;<br>
&gt; Thank you very much for your reply. I&#39;m not hitting any issues.<br=
>
&gt;<br>
&gt; AMD&#39;s APU is a new kind of processing device, which integrates a C=
PU and a<br>
&gt; GPU on the same die. I want to know whether Xen has supported the<br>
&gt; virtualization of the APU processors? If yes, I can run something<br>
&gt; applications in the Xen PV VMs to use this kind of new CPU device.<br>
<br>
</div>AFAIK at this point AMD APUs are simply CPU + GPU. Even though they&#=
39;re<br>
in the same die, they&#39;re basically different devices. So for the GPU<br=
>
part, treat it like any other GPU. Which means you could PROBABLY<br>
passthru it to ONE domU, but that&#39;s it.<br></blockquote><div>Hi Fajar,<=
/div><div><br></div><div>Thank you for your information.=A0</div><div>Passt=
hrough is a good method for a VM to use the GPU device. However, the GPU is=
 exclusively used by a VM in this way. It=A0cannot be shared among several =
VMs. I noticed that there are several projects implementing the virtualizat=
ion of GPU devices on Xen, such as=A0vCUDA (Hunan University, CN, 2009) and=
 GViM (Georgia IT). But, is there any plan with Xen support the GPU virtual=
ization in the Xen=A0official code?</div>
<div><br></div><div><br></div><div><br></div><div>Best Regards,</div><div>B=
ei Guan</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">
<br>
AMD&#39;s plan for the future is make a chip which can function as CPU or<b=
r>
GPU as needed, but that hasn&#39;t happened yet.<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
--<br>
Fajar<br>
</font></span></blockquote></div><br><br clear=3D"all"><div><br></div>-- <b=
r>Best Regards,<div>Bei Guan</div><br>

--e0cb4efa6e7eea814a04c9681810--


--===============6801750793812101181==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============6801750793812101181==--


From xen-devel-bounces@lists.xen.org Tue Sep 11 07:34:22 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 2012 07:34:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TBKyw-0004xX-5N; Tue, 11 Sep 2012 07:34:02 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <gbtju85@gmail.com>) id 1TBKyv-0004xN-0Y
	for xen-devel@lists.xen.org; Tue, 11 Sep 2012 07:34:01 +0000
Received: from [85.158.138.51:9090] by server-6.bemta-3.messagelabs.com id
	2E/31-29694-869EE405; Tue, 11 Sep 2012 07:34:00 +0000
X-Env-Sender: gbtju85@gmail.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1347348839!21893492!1
X-Originating-IP: [209.85.217.173]
X-SpamReason: No, hits=0.7 required=7.0 tests=HTML_30_40,HTML_MESSAGE,
	MAILTO_TO_SPAM_ADDR,ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12527 invoked from network); 11 Sep 2012 07:33:59 -0000
Received: from mail-lb0-f173.google.com (HELO mail-lb0-f173.google.com)
	(209.85.217.173)
	by server-12.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Sep 2012 07:33:59 -0000
Received: by lbbgm13 with SMTP id gm13so209355lbb.32
	for <xen-devel@lists.xen.org>; Tue, 11 Sep 2012 00:33: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:date:message-id:subject:from:to
	:cc:content-type;
	bh=LNFxMhm20yCT/gy0+K2RFYiwQRneaCkMilhb36LTCv4=;
	b=gBPlM6P1Lpkpn8amk+Y5FwL4ICLghmq7udAVUgOFJGTrlWFBkkXbdqj17P0iG0uFtt
	kR0PMIid2n7fiJSYZlBUb2cJeL5Qu/8mHHAVcXIazB+1wOyOK8nxMYuMFFnS4Y5t4JGb
	MFgGAKtqKB7FKqLPbYh6On99fe7esTM3EfzDZojwOoeAZB8oqCN+ffAmtKYT9ye0AsJz
	SE94jlN4na0x1+b0w03a3V4RS359QkUZpmtPG+z+A6aWhyc9RQ6DFqs7cedSAKy9fAR4
	7ewAjMPQsCkBmVdNrUeKifAzpWmTtXCNpGXWEIIRAdj13fHDyzRN0ukjACuuDCF/TAg+
	ImPg==
MIME-Version: 1.0
Received: by 10.112.43.98 with SMTP id v2mr5827083lbl.1.1347348838645; Tue, 11
	Sep 2012 00:33:58 -0700 (PDT)
Received: by 10.114.2.193 with HTTP; Tue, 11 Sep 2012 00:33:58 -0700 (PDT)
In-Reply-To: <CAG1y0scdfRzY97u7tty61Z2rFSqXzFxdVOw6WLk0MTKAZ+VJpA@mail.gmail.com>
References: <CAEQjb-TO9wy74up6pGfaRj+FQH8SPJtLXngM70ivWwWaQ53QPA@mail.gmail.com>
	<20120910192456.GA28298@phenom.dumpdata.com>
	<CAEQjb-QG71pnKQsWP1LLhpzXjkJUi+oRjFzLGZZZZSDJqo_BJA@mail.gmail.com>
	<CAG1y0scdfRzY97u7tty61Z2rFSqXzFxdVOw6WLk0MTKAZ+VJpA@mail.gmail.com>
Date: Tue, 11 Sep 2012 15:33:58 +0800
Message-ID: <CAEQjb-SBXK8x18Jg0e-K9snwSE1VdUjf4CPLprTqYG9xiTDm8w@mail.gmail.com>
From: Bei Guan <gbtju85@gmail.com>
To: "Fajar A. Nugraha" <list@fajar.net>
Cc: Konrad Rzeszutek Wilk <konrad@kernel.org>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Any news or plan about Xen support the APU
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============6801750793812101181=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============6801750793812101181==
Content-Type: multipart/alternative; boundary=e0cb4efa6e7eea814a04c9681810

--e0cb4efa6e7eea814a04c9681810
Content-Type: text/plain; charset=ISO-8859-1

2012/9/11 Fajar A. Nugraha <list@fajar.net>

> On Tue, Sep 11, 2012 at 8:27 AM, Bei Guan <gbtju85@gmail.com> wrote:
> > Hi Konrad,
> >
> > Thank you very much for your reply. I'm not hitting any issues.
> >
> > AMD's APU is a new kind of processing device, which integrates a CPU and
> a
> > GPU on the same die. I want to know whether Xen has supported the
> > virtualization of the APU processors? If yes, I can run something
> > applications in the Xen PV VMs to use this kind of new CPU device.
>
> AFAIK at this point AMD APUs are simply CPU + GPU. Even though they're
> in the same die, they're basically different devices. So for the GPU
> part, treat it like any other GPU. Which means you could PROBABLY
> passthru it to ONE domU, but that's it.
>
Hi Fajar,

Thank you for your information.
Passthrough is a good method for a VM to use the GPU device. However, the
GPU is exclusively used by a VM in this way. It cannot be shared among
several VMs. I noticed that there are several projects implementing the
virtualization of GPU devices on Xen, such as vCUDA (Hunan University, CN,
2009) and GViM (Georgia IT). But, is there any plan with Xen support the
GPU virtualization in the Xen official code?



Best Regards,
Bei Guan



>
> AMD's plan for the future is make a chip which can function as CPU or
> GPU as needed, but that hasn't happened yet.
>
> --
> Fajar
>



-- 
Best Regards,
Bei Guan

--e0cb4efa6e7eea814a04c9681810
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br><br><div class=3D"gmail_quote">2012/9/11 Fajar A. Nugraha <span dir=3D"=
ltr">&lt;<a href=3D"mailto:list@fajar.net" target=3D"_blank">list@fajar.net=
</a>&gt;</span><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 Tue, Sep 11, 2012 at 8:27 AM, Bei Guan &lt;<a href=3D"=
mailto:gbtju85@gmail.com">gbtju85@gmail.com</a>&gt; wrote:<br>
&gt; Hi Konrad,<br>
&gt;<br>
&gt; Thank you very much for your reply. I&#39;m not hitting any issues.<br=
>
&gt;<br>
&gt; AMD&#39;s APU is a new kind of processing device, which integrates a C=
PU and a<br>
&gt; GPU on the same die. I want to know whether Xen has supported the<br>
&gt; virtualization of the APU processors? If yes, I can run something<br>
&gt; applications in the Xen PV VMs to use this kind of new CPU device.<br>
<br>
</div>AFAIK at this point AMD APUs are simply CPU + GPU. Even though they&#=
39;re<br>
in the same die, they&#39;re basically different devices. So for the GPU<br=
>
part, treat it like any other GPU. Which means you could PROBABLY<br>
passthru it to ONE domU, but that&#39;s it.<br></blockquote><div>Hi Fajar,<=
/div><div><br></div><div>Thank you for your information.=A0</div><div>Passt=
hrough is a good method for a VM to use the GPU device. However, the GPU is=
 exclusively used by a VM in this way. It=A0cannot be shared among several =
VMs. I noticed that there are several projects implementing the virtualizat=
ion of GPU devices on Xen, such as=A0vCUDA (Hunan University, CN, 2009) and=
 GViM (Georgia IT). But, is there any plan with Xen support the GPU virtual=
ization in the Xen=A0official code?</div>
<div><br></div><div><br></div><div><br></div><div>Best Regards,</div><div>B=
ei Guan</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">
<br>
AMD&#39;s plan for the future is make a chip which can function as CPU or<b=
r>
GPU as needed, but that hasn&#39;t happened yet.<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
--<br>
Fajar<br>
</font></span></blockquote></div><br><br clear=3D"all"><div><br></div>-- <b=
r>Best Regards,<div>Bei Guan</div><br>

--e0cb4efa6e7eea814a04c9681810--


--===============6801750793812101181==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============6801750793812101181==--


From xen-devel-bounces@lists.xen.org Tue Sep 11 07:41:11 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 2012 07:41:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TBL5e-0005Ko-1S; Tue, 11 Sep 2012 07:40:58 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1TBL5c-0005Kf-Hi
	for xen-devel@lists.xen.org; Tue, 11 Sep 2012 07:40:56 +0000
Received: from [85.158.143.35:21351] by server-2.bemta-4.messagelabs.com id
	3F/1A-21239-70BEE405; Tue, 11 Sep 2012 07:40:55 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1347348966!5958982!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM5NTk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14127 invoked from network); 11 Sep 2012 07:36:06 -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;
	11 Sep 2012 07:36:06 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 11 Sep 2012 08:36:06 +0100
Message-Id: <504F0603020000780009A6CC@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 11 Sep 2012 08:36:02 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Daniel De Graaf" <dgdegra@tycho.nsa.gov>
References: <1347306553-20980-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1347306553-20980-13-git-send-email-dgdegra@tycho.nsa.gov>
In-Reply-To: <1347306553-20980-13-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 12/20] xen: avoid calling
 rcu_lock_*target_domain when an XSM hook 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 10.09.12 at 21:49, Daniel De Graaf <dgdegra@tycho.nsa.gov> wrote:
> --- a/xen/common/grant_table.c
> +++ b/xen/common/grant_table.c
> @@ -195,30 +195,6 @@ double_gt_unlock(struct grant_table *lgt, struct 
> grant_table *rgt)
>          spin_unlock(&rgt->lock);
>  }
>  
> -static struct domain *gt_lock_target_domain_by_id(domid_t dom)
> -{
> -    struct domain *d;
> -    int rc = GNTST_general_error;
> -
> -    switch ( rcu_lock_target_domain_by_id(dom, &d) )
> -    {
> -    case 0:
> -        return d;
> -
> -    case -ESRCH:
> -        gdprintk(XENLOG_INFO, "Bad domid %d.\n", dom);
> -        rc = GNTST_bad_domain;
> -        break;
> -
> -    case -EPERM:
> -        rc = GNTST_permission_denied;
> -        break;
> -    }
> -
> -    ASSERT(rc < 0 && -rc <= MAX_ERRNO);
> -    return ERR_PTR(rc);
> -}
> -

Removing that function again is fine as long as you retain the
distinguished error codes, which ...

>  static inline int
>  __get_maptrack_handle(
>      struct grant_table *t)
> @@ -1304,11 +1280,12 @@ gnttab_setup_table(
>          goto out1;
>      }
>  
> -    d = gt_lock_target_domain_by_id(op.dom);
> -    if ( IS_ERR(d) )
> +    d = rcu_lock_domain_by_any_id(op.dom);
> +    if ( d == NULL )
>      {
> -        op.status = PTR_ERR(d);
> -        goto out1;
> +        gdprintk(XENLOG_INFO, "Bad domid %d.\n", op.dom);
> +        op.status = GNTST_bad_domain;

... you don't.

> --- a/xen/common/memory.c
> +++ b/xen/common/memory.c
> @@ -570,7 +570,8 @@ long do_memory_op(unsigned long cmd, 
> XEN_GUEST_HANDLE(void) arg)
>               && (reservation.mem_flags & XENMEMF_populate_on_demand) )
>              args.memflags |= MEMF_populate_on_demand;
>  
> -        if ( unlikely(rcu_lock_target_domain_by_id(reservation.domid, &d)) )
> +        d = rcu_lock_domain_by_any_id(reservation.domid);
> +        if ( d == NULL )
>              return start_extent;
>          args.domain = d;
>  
> @@ -619,9 +620,9 @@ long do_memory_op(unsigned long cmd, 
> XEN_GUEST_HANDLE(void) arg)
>          if ( copy_from_guest(&domid, arg, 1) )
>              return -EFAULT;
>  
> -        rc = rcu_lock_target_domain_by_id(domid, &d);
> -        if ( rc )
> -            return rc;
> +        d = rcu_lock_domain_by_any_id(domid);
> +        if ( d == NULL )
> +            return -ESRCH;

And quite similarly here and further down you're losing -EPERM.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 11 07:41:11 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 2012 07:41:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TBL5e-0005Ko-1S; Tue, 11 Sep 2012 07:40:58 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1TBL5c-0005Kf-Hi
	for xen-devel@lists.xen.org; Tue, 11 Sep 2012 07:40:56 +0000
Received: from [85.158.143.35:21351] by server-2.bemta-4.messagelabs.com id
	3F/1A-21239-70BEE405; Tue, 11 Sep 2012 07:40:55 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1347348966!5958982!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM5NTk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14127 invoked from network); 11 Sep 2012 07:36:06 -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;
	11 Sep 2012 07:36:06 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 11 Sep 2012 08:36:06 +0100
Message-Id: <504F0603020000780009A6CC@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 11 Sep 2012 08:36:02 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Daniel De Graaf" <dgdegra@tycho.nsa.gov>
References: <1347306553-20980-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1347306553-20980-13-git-send-email-dgdegra@tycho.nsa.gov>
In-Reply-To: <1347306553-20980-13-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 12/20] xen: avoid calling
 rcu_lock_*target_domain when an XSM hook 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 10.09.12 at 21:49, Daniel De Graaf <dgdegra@tycho.nsa.gov> wrote:
> --- a/xen/common/grant_table.c
> +++ b/xen/common/grant_table.c
> @@ -195,30 +195,6 @@ double_gt_unlock(struct grant_table *lgt, struct 
> grant_table *rgt)
>          spin_unlock(&rgt->lock);
>  }
>  
> -static struct domain *gt_lock_target_domain_by_id(domid_t dom)
> -{
> -    struct domain *d;
> -    int rc = GNTST_general_error;
> -
> -    switch ( rcu_lock_target_domain_by_id(dom, &d) )
> -    {
> -    case 0:
> -        return d;
> -
> -    case -ESRCH:
> -        gdprintk(XENLOG_INFO, "Bad domid %d.\n", dom);
> -        rc = GNTST_bad_domain;
> -        break;
> -
> -    case -EPERM:
> -        rc = GNTST_permission_denied;
> -        break;
> -    }
> -
> -    ASSERT(rc < 0 && -rc <= MAX_ERRNO);
> -    return ERR_PTR(rc);
> -}
> -

Removing that function again is fine as long as you retain the
distinguished error codes, which ...

>  static inline int
>  __get_maptrack_handle(
>      struct grant_table *t)
> @@ -1304,11 +1280,12 @@ gnttab_setup_table(
>          goto out1;
>      }
>  
> -    d = gt_lock_target_domain_by_id(op.dom);
> -    if ( IS_ERR(d) )
> +    d = rcu_lock_domain_by_any_id(op.dom);
> +    if ( d == NULL )
>      {
> -        op.status = PTR_ERR(d);
> -        goto out1;
> +        gdprintk(XENLOG_INFO, "Bad domid %d.\n", op.dom);
> +        op.status = GNTST_bad_domain;

... you don't.

> --- a/xen/common/memory.c
> +++ b/xen/common/memory.c
> @@ -570,7 +570,8 @@ long do_memory_op(unsigned long cmd, 
> XEN_GUEST_HANDLE(void) arg)
>               && (reservation.mem_flags & XENMEMF_populate_on_demand) )
>              args.memflags |= MEMF_populate_on_demand;
>  
> -        if ( unlikely(rcu_lock_target_domain_by_id(reservation.domid, &d)) )
> +        d = rcu_lock_domain_by_any_id(reservation.domid);
> +        if ( d == NULL )
>              return start_extent;
>          args.domain = d;
>  
> @@ -619,9 +620,9 @@ long do_memory_op(unsigned long cmd, 
> XEN_GUEST_HANDLE(void) arg)
>          if ( copy_from_guest(&domid, arg, 1) )
>              return -EFAULT;
>  
> -        rc = rcu_lock_target_domain_by_id(domid, &d);
> -        if ( rc )
> -            return rc;
> +        d = rcu_lock_domain_by_any_id(domid);
> +        if ( d == NULL )
> +            return -ESRCH;

And quite similarly here and further down you're losing -EPERM.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 11 07:41:19 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 2012 07: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 1TBL5n-0005Le-Df; Tue, 11 Sep 2012 07:41:07 +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 1TBL5l-0005L3-Vb
	for xen-devel@lists.xen.org; Tue, 11 Sep 2012 07:41:06 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1347349256!9685515!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM5NTk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28022 invoked from network); 11 Sep 2012 07:40:56 -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;
	11 Sep 2012 07:40:56 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 11 Sep 2012 08:40:55 +0100
Message-Id: <504F0724020000780009A6D2@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 11 Sep 2012 08:40:52 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Daniel De Graaf" <dgdegra@tycho.nsa.gov>
References: <1347306553-20980-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1347306553-20980-15-git-send-email-dgdegra@tycho.nsa.gov>
In-Reply-To: <1347306553-20980-15-git-send-email-dgdegra@tycho.nsa.gov>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Dan Magenheimer <dan.magenheimer@oracle.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 14/20] tmem: Add access control check
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 10.09.12 at 21:49, Daniel De Graaf <dgdegra@tycho.nsa.gov> wrote:
> --- a/xen/common/tmem.c
> +++ b/xen/common/tmem.c
> @@ -23,6 +23,7 @@
>  #include <xen/radix-tree.h>
>  #include <xen/list.h>
>  #include <xen/init.h>
> +#include <xsm/xsm.h>
>  
>  #define EXPORT /* indicates code other modules are dependent upon */
>  #define FORWARD
> @@ -2540,11 +2541,10 @@ static NOINLINE int do_tmem_control(struct tmem_op *op)
>      uint32_t subop = op->u.ctrl.subop;
>      OID *oidp = (OID *)(&op->u.ctrl.oid[0]);
>  
> -    if (!tmh_current_is_privileged())
> -    {
> -        /* don't fail... mystery: sometimes dom0 fails here */
> -        /* return -EPERM; */
> -    }
> +    ret = xsm_tmem_control(subop);
> +    if ( ret )
> +        return ret;
> +

This shouldn't be placed here literally, but rather be moved into the
tmh_current_is_privileged() - the file here is, afaict, intended to not
have Xen-specific code (except for the inclusion of tmem_xen.h, so
the comment also applies to the inclusion of xsm/xsm.h above). Plus
it probably ought to go on top of the pending tmem patch series.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 11 07:41:19 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 2012 07: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 1TBL5n-0005Le-Df; Tue, 11 Sep 2012 07:41:07 +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 1TBL5l-0005L3-Vb
	for xen-devel@lists.xen.org; Tue, 11 Sep 2012 07:41:06 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1347349256!9685515!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM5NTk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28022 invoked from network); 11 Sep 2012 07:40:56 -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;
	11 Sep 2012 07:40:56 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 11 Sep 2012 08:40:55 +0100
Message-Id: <504F0724020000780009A6D2@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 11 Sep 2012 08:40:52 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Daniel De Graaf" <dgdegra@tycho.nsa.gov>
References: <1347306553-20980-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1347306553-20980-15-git-send-email-dgdegra@tycho.nsa.gov>
In-Reply-To: <1347306553-20980-15-git-send-email-dgdegra@tycho.nsa.gov>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Dan Magenheimer <dan.magenheimer@oracle.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 14/20] tmem: Add access control check
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 10.09.12 at 21:49, Daniel De Graaf <dgdegra@tycho.nsa.gov> wrote:
> --- a/xen/common/tmem.c
> +++ b/xen/common/tmem.c
> @@ -23,6 +23,7 @@
>  #include <xen/radix-tree.h>
>  #include <xen/list.h>
>  #include <xen/init.h>
> +#include <xsm/xsm.h>
>  
>  #define EXPORT /* indicates code other modules are dependent upon */
>  #define FORWARD
> @@ -2540,11 +2541,10 @@ static NOINLINE int do_tmem_control(struct tmem_op *op)
>      uint32_t subop = op->u.ctrl.subop;
>      OID *oidp = (OID *)(&op->u.ctrl.oid[0]);
>  
> -    if (!tmh_current_is_privileged())
> -    {
> -        /* don't fail... mystery: sometimes dom0 fails here */
> -        /* return -EPERM; */
> -    }
> +    ret = xsm_tmem_control(subop);
> +    if ( ret )
> +        return ret;
> +

This shouldn't be placed here literally, but rather be moved into the
tmh_current_is_privileged() - the file here is, afaict, intended to not
have Xen-specific code (except for the inclusion of tmem_xen.h, so
the comment also applies to the inclusion of xsm/xsm.h above). Plus
it probably ought to go on top of the pending tmem patch series.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 11 07:45:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 2012 07:45:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TBL9T-0005dv-2w; Tue, 11 Sep 2012 07:44: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 1TBL9R-0005dn-SZ
	for xen-devel@lists.xen.org; Tue, 11 Sep 2012 07:44:53 +0000
Received: from [85.158.139.83:28296] by server-4.bemta-5.messagelabs.com id
	A6/95-23042-4FBEE405; Tue, 11 Sep 2012 07:44:52 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1347349492!25494333!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM5NTk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9186 invoked from network); 11 Sep 2012 07:44:52 -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;
	11 Sep 2012 07:44:52 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 11 Sep 2012 08:44:51 +0100
Message-Id: <504F0811020000780009A6D5@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 11 Sep 2012 08:44:49 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Daniel De Graaf" <dgdegra@tycho.nsa.gov>
References: <1347306553-20980-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1347306553-20980-11-git-send-email-dgdegra@tycho.nsa.gov>
In-Reply-To: <1347306553-20980-11-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 10/20] xsm: Add IS_PRIV checks to dummy XSM
	module
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 10.09.12 at 21:49, Daniel De Graaf <dgdegra@tycho.nsa.gov> wrote:
> --- a/xen/include/xsm/xsm.h
> +++ b/xen/include/xsm/xsm.h
> @@ -21,11 +21,7 @@
>  typedef void xsm_op_t;
>  DEFINE_XEN_GUEST_HANDLE(xsm_op_t);
>  
> -#ifdef XSM_ENABLE
> -    #define xsm_call(fn) xsm_ops->fn
> -#else
> -    #define xsm_call(fn) 0
> -#endif
> +#define xsm_call(fn) xsm_ops->fn

So am I getting it right that with XSM disabled this now adds an
indirect call in almost every hypercall? I'm not really in favor of
that, particularly not if that affects hot path ones like the MMU
operations.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 11 07:45:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 2012 07:45:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TBL9T-0005dv-2w; Tue, 11 Sep 2012 07:44: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 1TBL9R-0005dn-SZ
	for xen-devel@lists.xen.org; Tue, 11 Sep 2012 07:44:53 +0000
Received: from [85.158.139.83:28296] by server-4.bemta-5.messagelabs.com id
	A6/95-23042-4FBEE405; Tue, 11 Sep 2012 07:44:52 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1347349492!25494333!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM5NTk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9186 invoked from network); 11 Sep 2012 07:44:52 -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;
	11 Sep 2012 07:44:52 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 11 Sep 2012 08:44:51 +0100
Message-Id: <504F0811020000780009A6D5@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 11 Sep 2012 08:44:49 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Daniel De Graaf" <dgdegra@tycho.nsa.gov>
References: <1347306553-20980-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1347306553-20980-11-git-send-email-dgdegra@tycho.nsa.gov>
In-Reply-To: <1347306553-20980-11-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 10/20] xsm: Add IS_PRIV checks to dummy XSM
	module
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 10.09.12 at 21:49, Daniel De Graaf <dgdegra@tycho.nsa.gov> wrote:
> --- a/xen/include/xsm/xsm.h
> +++ b/xen/include/xsm/xsm.h
> @@ -21,11 +21,7 @@
>  typedef void xsm_op_t;
>  DEFINE_XEN_GUEST_HANDLE(xsm_op_t);
>  
> -#ifdef XSM_ENABLE
> -    #define xsm_call(fn) xsm_ops->fn
> -#else
> -    #define xsm_call(fn) 0
> -#endif
> +#define xsm_call(fn) xsm_ops->fn

So am I getting it right that with XSM disabled this now adds an
indirect call in almost every hypercall? I'm not really in favor of
that, particularly not if that affects hot path ones like the MMU
operations.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 11 07:46:18 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 2012 07:46:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TBLAY-0005jq-Hg; Tue, 11 Sep 2012 07:46:02 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <belerajendra753@gmail.com>) id 1TBLAX-0005jf-2C
	for xen-devel@lists.xensource.com; Tue, 11 Sep 2012 07:46:01 +0000
Received: from [85.158.139.83:37723] by server-10.bemta-5.messagelabs.com id
	CE/EB-10969-83CEE405; Tue, 11 Sep 2012 07:46:00 +0000
X-Env-Sender: belerajendra753@gmail.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1347349558!29740414!1
X-Originating-IP: [209.85.212.43]
X-SpamReason: No, hits=2.8 required=7.0 tests=HTML_10_20,HTML_MESSAGE,
	HTML_SHORT_LENGTH,ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4820 invoked from network); 11 Sep 2012 07:45:59 -0000
Received: from mail-vb0-f43.google.com (HELO mail-vb0-f43.google.com)
	(209.85.212.43)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Sep 2012 07:45:59 -0000
Received: by vbbfq11 with SMTP id fq11so312338vbb.30
	for <xen-devel@lists.xensource.com>;
	Tue, 11 Sep 2012 00:45: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=pjX9y/iCjTGkLbb0na1LLkU8mqZl9PlOpTU3yExBefk=;
	b=GeSLnlOHIb8PLC4r4LRfuxyUueV/RpALR4XBzHctM8kDXhxls9WlmW5I+OK/TXxtxN
	XZ+VqztBLF36ogmAsVIBJ06+6po6KP4TZ2rKexmmAJJz+bi33VzGDlKXaMkgp3H12h6n
	5Alqntm5LBHWqOtEVEPPXQ/MUk6HqkuXAXyr9amZLHr29yb/8lqDgkF1IRSC1aJkO8e4
	1DH8+WtqLseaJ9V3heZ35MPC5DZeJDHMV0inQdWOuWheJwpaSdYqhN9Dhue96A6Kx5bi
	le/MZsg5aXJaA8PviGfBx3ZWGZfR/IVQ7ODfumJxMj99AWPjpx4huDLuPuXJ+0QuaKq8
	OEXw==
MIME-Version: 1.0
Received: by 10.52.26.1 with SMTP id h1mr19145763vdg.22.1347349557960; Tue, 11
	Sep 2012 00:45:57 -0700 (PDT)
Received: by 10.52.70.209 with HTTP; Tue, 11 Sep 2012 00:45:57 -0700 (PDT)
Date: Tue, 11 Sep 2012 13:15:57 +0530
Message-ID: <CAJRmKy-VaXJh7W0PArXSOwZT3K=V5+iSJQ2p-vF=wbqeu2d61Q@mail.gmail.com>
From: Rajendra Bele <belerajendra753@gmail.com>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] Xen Development
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============4764417822876848977=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============4764417822876848977==
Content-Type: multipart/alternative; boundary=20cf307d00c0ca603b04c96843a7

--20cf307d00c0ca603b04c96843a7
Content-Type: text/plain; charset=UTF-8

Dear Friends;

Can Any One Suggest me nice books to learn Xen Administration as well as
Xen Development from Scratch.

Thanks lot
Rajendra

--20cf307d00c0ca603b04c96843a7
Content-Type: text/html; charset=UTF-8

Dear Friends;<br><br>Can Any One Suggest me nice books to learn Xen Administration as well as Xen Development from Scratch.<br><br>Thanks lot<br>Rajendra<br>

--20cf307d00c0ca603b04c96843a7--


--===============4764417822876848977==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============4764417822876848977==--


From xen-devel-bounces@lists.xen.org Tue Sep 11 07:46:18 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 2012 07:46:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TBLAY-0005jq-Hg; Tue, 11 Sep 2012 07:46:02 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <belerajendra753@gmail.com>) id 1TBLAX-0005jf-2C
	for xen-devel@lists.xensource.com; Tue, 11 Sep 2012 07:46:01 +0000
Received: from [85.158.139.83:37723] by server-10.bemta-5.messagelabs.com id
	CE/EB-10969-83CEE405; Tue, 11 Sep 2012 07:46:00 +0000
X-Env-Sender: belerajendra753@gmail.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1347349558!29740414!1
X-Originating-IP: [209.85.212.43]
X-SpamReason: No, hits=2.8 required=7.0 tests=HTML_10_20,HTML_MESSAGE,
	HTML_SHORT_LENGTH,ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4820 invoked from network); 11 Sep 2012 07:45:59 -0000
Received: from mail-vb0-f43.google.com (HELO mail-vb0-f43.google.com)
	(209.85.212.43)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Sep 2012 07:45:59 -0000
Received: by vbbfq11 with SMTP id fq11so312338vbb.30
	for <xen-devel@lists.xensource.com>;
	Tue, 11 Sep 2012 00:45: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=pjX9y/iCjTGkLbb0na1LLkU8mqZl9PlOpTU3yExBefk=;
	b=GeSLnlOHIb8PLC4r4LRfuxyUueV/RpALR4XBzHctM8kDXhxls9WlmW5I+OK/TXxtxN
	XZ+VqztBLF36ogmAsVIBJ06+6po6KP4TZ2rKexmmAJJz+bi33VzGDlKXaMkgp3H12h6n
	5Alqntm5LBHWqOtEVEPPXQ/MUk6HqkuXAXyr9amZLHr29yb/8lqDgkF1IRSC1aJkO8e4
	1DH8+WtqLseaJ9V3heZ35MPC5DZeJDHMV0inQdWOuWheJwpaSdYqhN9Dhue96A6Kx5bi
	le/MZsg5aXJaA8PviGfBx3ZWGZfR/IVQ7ODfumJxMj99AWPjpx4huDLuPuXJ+0QuaKq8
	OEXw==
MIME-Version: 1.0
Received: by 10.52.26.1 with SMTP id h1mr19145763vdg.22.1347349557960; Tue, 11
	Sep 2012 00:45:57 -0700 (PDT)
Received: by 10.52.70.209 with HTTP; Tue, 11 Sep 2012 00:45:57 -0700 (PDT)
Date: Tue, 11 Sep 2012 13:15:57 +0530
Message-ID: <CAJRmKy-VaXJh7W0PArXSOwZT3K=V5+iSJQ2p-vF=wbqeu2d61Q@mail.gmail.com>
From: Rajendra Bele <belerajendra753@gmail.com>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] Xen Development
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============4764417822876848977=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============4764417822876848977==
Content-Type: multipart/alternative; boundary=20cf307d00c0ca603b04c96843a7

--20cf307d00c0ca603b04c96843a7
Content-Type: text/plain; charset=UTF-8

Dear Friends;

Can Any One Suggest me nice books to learn Xen Administration as well as
Xen Development from Scratch.

Thanks lot
Rajendra

--20cf307d00c0ca603b04c96843a7
Content-Type: text/html; charset=UTF-8

Dear Friends;<br><br>Can Any One Suggest me nice books to learn Xen Administration as well as Xen Development from Scratch.<br><br>Thanks lot<br>Rajendra<br>

--20cf307d00c0ca603b04c96843a7--


--===============4764417822876848977==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============4764417822876848977==--


From xen-devel-bounces@lists.xen.org Tue Sep 11 07:49:32 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 2012 07:49:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TBLDj-0005vz-5S; Tue, 11 Sep 2012 07:49:19 +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 1TBLDh-0005vq-Bs
	for xen-devel@lists.xen.org; Tue, 11 Sep 2012 07:49:17 +0000
Received: from [85.158.138.51:55219] by server-11.bemta-3.messagelabs.com id
	0C/5E-30250-CFCEE405; Tue, 11 Sep 2012 07:49:16 +0000
X-Env-Sender: yang.z.zhang@intel.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1347349755!25792150!1
X-Originating-IP: [143.182.124.21]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMjEgPT4gMTk5MjI5\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4583 invoked from network); 11 Sep 2012 07:49:15 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (143.182.124.21)
	by server-10.tower-174.messagelabs.com with SMTP;
	11 Sep 2012 07:49:15 -0000
Received: from azsmga002.ch.intel.com ([10.2.17.35])
	by azsmga101.ch.intel.com with ESMTP; 11 Sep 2012 00:49:14 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.80,402,1344236400"; d="scan'208";a="143682932"
Received: from fmsmsx105.amr.corp.intel.com ([10.19.9.36])
	by AZSMGA002.ch.intel.com with ESMTP; 11 Sep 2012 00:49:13 -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; Tue, 11 Sep 2012 00:49:13 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.239]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.175]) with mapi id
	14.01.0355.002; Tue, 11 Sep 2012 15:49:11 +0800
From: "Zhang, Yang Z" <yang.z.zhang@intel.com>
To: "Zhou, Chao" <chao.zhou@intel.com>, Ian Campbell
	<Ian.Campbell@citrix.com>, Stefano Stabellini
	<Stefano.Stabellini@eu.citrix.com>
Thread-Topic: [Xen-devel] error when pass through device to guest	with
	qemu-xen-dir-remote
Thread-Index: AQHNhACBIcVJkHzSNEKAhiEtlfNv7JeE2OOw
Date: Tue, 11 Sep 2012 07:49:11 +0000
Message-ID: <A9667DDFB95DB7438FA9D7D576C3D87E25184B@SHSMSX101.ccr.corp.intel.com>
References: <A9667DDFB95DB7438FA9D7D576C3D87E203D54@SHSMSX101.ccr.corp.intel.com>
	<alpine.DEB.2.02.1208031122170.4645@kaball.uk.xensource.com>
	<1343990187.21372.48.camel@zakaz.uk.xensource.com>
	<40352EBA8B4DF841A9907B883F22B59B0FDBCE1E@SHSMSX102.ccr.corp.intel.com>
	<40352EBA8B4DF841A9907B883F22B59B0FDD25C7@SHSMSX102.ccr.corp.intel.com>
In-Reply-To: <40352EBA8B4DF841A9907B883F22B59B0FDD25C7@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: Anthony Perard <anthony.perard@citrix.com>, "Shan,
	Haitao" <haitao.shan@intel.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] error when pass through device to
	guest	with	qemu-xen-dir-remote
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 Zhou, Chao Sent:
> Thursday, August 09, 2012 2:49 PM To: Ian Campbell; Stefano Stabellini
> Cc: Zhang, Yang Z; Anthony Perard; xen-devel Subject: Re: [Xen-devel]
> error when pass through device to guest with qemu-xen-dir-remote
> 
> I rebuild the upstream QEMU according to the wiki, but device static assignment
> doesn't work, no lspci output in guest. However hotplug & unplug works fine.
> 
> -----Original Message----- From: xen-devel-bounces@lists.xen.org
> [mailto:xen-devel-bounces@lists.xen.org] On Behalf Of Ian Campbell Sent:
> Friday, August 03, 2012 6:36 PM To: Stefano Stabellini Cc: Zhang, Yang
> Z; Anthony Perard; xen-devel Subject: Re: [Xen-devel] error when pass
> through device to guest with qemu-xen-dir-remote
> 
> On Fri, 2012-08-03 at 11:29 +0100, Stefano Stabellini wrote:
>> On Fri, 3 Aug 2012, Zhang, Yang Z wrote:
>>> When create guest with device assigned, it shows the error and the
>>> device wasn't able to work inside guest: libxl: error:
>>> libxl_qmp.c:288:qmp_handle_error_response: received an error message
>>> from QMP server: Parameter 'driver' expects a driver name
>>> 
>>> It only fails with qemu-xen-dir-remote(Is this tree more close to
>>> upstream qemu?). I don't see the error with the traditional Qemu. I
>>> also tried qemu-upstream, but it fails when I try to enable pci
>>> pass-through
> for xen. I think Anthony's patch to add pci pass-through support for Xen is
> accepted by qemu-upstream, am I right?
>> 
>> Yes, it was accepted, but it is present only in upstream QEMU (from
>> git://git.qemu.org/qemu.git), not the tree we are currently using in
>> xen-unstable for development
>> (git://xenbits.xensource.com/qemu-upstream-unstable.git).
>> Make sure you are using the right tree!
> 
> http://wiki.xen.org/wiki/QEMU_Upstream has some notes on how to use the
> upstream qemu tree instead of our stable branch of upstream.
> 
>> 
>> Anthony is currently on vacation and is going to be back in about a
>> week.
>> 
>>> Another question:
>>> Now I am trying to add some features (relevant to pass through device) to
> Qemu, which tree should I use? Since traditional qemu is great different from
> qemu-upstream, it is too old to develop patch base on it. But besides the old one,
> I cannot find a working qemu.
>> 
>> You should use upstream QEMU, I am going to rebase our tree on that
>> early on in the 4.3 release cycle.

Hi Anthony

I found the issue is caused by PV driver. Since RHEL6 integrated PV driver by default, when booting rhel6 as guest, it will load the PV driver and write the xen platform device to notify qemu to unplug all NICs including the pass through device. This definitely is wrong. We only need to unplug the emulator device, and leave pass through device.

Best regards,
Yang



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 11 07:49:32 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 2012 07:49:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TBLDj-0005vz-5S; Tue, 11 Sep 2012 07:49:19 +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 1TBLDh-0005vq-Bs
	for xen-devel@lists.xen.org; Tue, 11 Sep 2012 07:49:17 +0000
Received: from [85.158.138.51:55219] by server-11.bemta-3.messagelabs.com id
	0C/5E-30250-CFCEE405; Tue, 11 Sep 2012 07:49:16 +0000
X-Env-Sender: yang.z.zhang@intel.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1347349755!25792150!1
X-Originating-IP: [143.182.124.21]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMjEgPT4gMTk5MjI5\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4583 invoked from network); 11 Sep 2012 07:49:15 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (143.182.124.21)
	by server-10.tower-174.messagelabs.com with SMTP;
	11 Sep 2012 07:49:15 -0000
Received: from azsmga002.ch.intel.com ([10.2.17.35])
	by azsmga101.ch.intel.com with ESMTP; 11 Sep 2012 00:49:14 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.80,402,1344236400"; d="scan'208";a="143682932"
Received: from fmsmsx105.amr.corp.intel.com ([10.19.9.36])
	by AZSMGA002.ch.intel.com with ESMTP; 11 Sep 2012 00:49:13 -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; Tue, 11 Sep 2012 00:49:13 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.239]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.175]) with mapi id
	14.01.0355.002; Tue, 11 Sep 2012 15:49:11 +0800
From: "Zhang, Yang Z" <yang.z.zhang@intel.com>
To: "Zhou, Chao" <chao.zhou@intel.com>, Ian Campbell
	<Ian.Campbell@citrix.com>, Stefano Stabellini
	<Stefano.Stabellini@eu.citrix.com>
Thread-Topic: [Xen-devel] error when pass through device to guest	with
	qemu-xen-dir-remote
Thread-Index: AQHNhACBIcVJkHzSNEKAhiEtlfNv7JeE2OOw
Date: Tue, 11 Sep 2012 07:49:11 +0000
Message-ID: <A9667DDFB95DB7438FA9D7D576C3D87E25184B@SHSMSX101.ccr.corp.intel.com>
References: <A9667DDFB95DB7438FA9D7D576C3D87E203D54@SHSMSX101.ccr.corp.intel.com>
	<alpine.DEB.2.02.1208031122170.4645@kaball.uk.xensource.com>
	<1343990187.21372.48.camel@zakaz.uk.xensource.com>
	<40352EBA8B4DF841A9907B883F22B59B0FDBCE1E@SHSMSX102.ccr.corp.intel.com>
	<40352EBA8B4DF841A9907B883F22B59B0FDD25C7@SHSMSX102.ccr.corp.intel.com>
In-Reply-To: <40352EBA8B4DF841A9907B883F22B59B0FDD25C7@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: Anthony Perard <anthony.perard@citrix.com>, "Shan,
	Haitao" <haitao.shan@intel.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] error when pass through device to
	guest	with	qemu-xen-dir-remote
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 Zhou, Chao Sent:
> Thursday, August 09, 2012 2:49 PM To: Ian Campbell; Stefano Stabellini
> Cc: Zhang, Yang Z; Anthony Perard; xen-devel Subject: Re: [Xen-devel]
> error when pass through device to guest with qemu-xen-dir-remote
> 
> I rebuild the upstream QEMU according to the wiki, but device static assignment
> doesn't work, no lspci output in guest. However hotplug & unplug works fine.
> 
> -----Original Message----- From: xen-devel-bounces@lists.xen.org
> [mailto:xen-devel-bounces@lists.xen.org] On Behalf Of Ian Campbell Sent:
> Friday, August 03, 2012 6:36 PM To: Stefano Stabellini Cc: Zhang, Yang
> Z; Anthony Perard; xen-devel Subject: Re: [Xen-devel] error when pass
> through device to guest with qemu-xen-dir-remote
> 
> On Fri, 2012-08-03 at 11:29 +0100, Stefano Stabellini wrote:
>> On Fri, 3 Aug 2012, Zhang, Yang Z wrote:
>>> When create guest with device assigned, it shows the error and the
>>> device wasn't able to work inside guest: libxl: error:
>>> libxl_qmp.c:288:qmp_handle_error_response: received an error message
>>> from QMP server: Parameter 'driver' expects a driver name
>>> 
>>> It only fails with qemu-xen-dir-remote(Is this tree more close to
>>> upstream qemu?). I don't see the error with the traditional Qemu. I
>>> also tried qemu-upstream, but it fails when I try to enable pci
>>> pass-through
> for xen. I think Anthony's patch to add pci pass-through support for Xen is
> accepted by qemu-upstream, am I right?
>> 
>> Yes, it was accepted, but it is present only in upstream QEMU (from
>> git://git.qemu.org/qemu.git), not the tree we are currently using in
>> xen-unstable for development
>> (git://xenbits.xensource.com/qemu-upstream-unstable.git).
>> Make sure you are using the right tree!
> 
> http://wiki.xen.org/wiki/QEMU_Upstream has some notes on how to use the
> upstream qemu tree instead of our stable branch of upstream.
> 
>> 
>> Anthony is currently on vacation and is going to be back in about a
>> week.
>> 
>>> Another question:
>>> Now I am trying to add some features (relevant to pass through device) to
> Qemu, which tree should I use? Since traditional qemu is great different from
> qemu-upstream, it is too old to develop patch base on it. But besides the old one,
> I cannot find a working qemu.
>> 
>> You should use upstream QEMU, I am going to rebase our tree on that
>> early on in the 4.3 release cycle.

Hi Anthony

I found the issue is caused by PV driver. Since RHEL6 integrated PV driver by default, when booting rhel6 as guest, it will load the PV driver and write the xen platform device to notify qemu to unplug all NICs including the pass through device. This definitely is wrong. We only need to unplug the emulator device, and leave pass through device.

Best regards,
Yang



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 11 07:52:11 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 2012 07: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 1TBLGI-00063s-O5; Tue, 11 Sep 2012 07:51: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 1TBLGG-00063m-MK
	for xen-devel@lists.xen.org; Tue, 11 Sep 2012 07:51:56 +0000
Received: from [85.158.143.35:24411] by server-2.bemta-4.messagelabs.com id
	DF/7D-21239-C9DEE405; Tue, 11 Sep 2012 07:51:56 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1347349914!14401387!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDg1MTY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21632 invoked from network); 11 Sep 2012 07:51:54 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Sep 2012 07:51:54 -0000
X-IronPort-AV: E=Sophos;i="4.80,402,1344211200"; d="scan'208";a="14460688"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Sep 2012 07:51: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.279.1;
	Tue, 11 Sep 2012 08:51:54 +0100
Message-ID: <1347349913.10570.98.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Tim Deegan <tim@xen.org>
Date: Tue, 11 Sep 2012 08:51:53 +0100
In-Reply-To: <20120911072225.GB78597@ocelot.phlegethon.org>
References: <CANSvah6PU5SOKd19qfbvTXvz4spcPYVUQHmiirmm5hPvmzR+pg@mail.gmail.com>
	<CC741C8D.4B3AF%keir@xen.org>
	<CANSvah6nWfKP9-PLSkhbFcO2ONmfj5Hhs-+3r0MhjOUHU1qNfg@mail.gmail.com>
	<CAB10MZDy0zTQNO5APyWMgbhiKw+4uXZ2pYMKHqJ3MNKR5gLjjA@mail.gmail.com>
	<CANSvah4NN05Zimm2BmKO9ofC04G+D7Svrg+2xwp0yM16Cn3CRw@mail.gmail.com>
	<20120911072225.GB78597@ocelot.phlegethon.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Aravindh Puthiyaparambil <aravindh@virtuata.com>,
	"Keir \(Xen.org\)" <keir@xen.org>, Steven Maresca <steve@zentific.com>,
	"andres@lagarcavilla.org" <andres@lagarcavilla.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] mem_event: fix regression affecting CR3,
 CR4 memory events
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-09-11 at 08:22 +0100, Tim Deegan wrote:
> I think it's too late to get any more code changes in to 4.2.0, so this
> will have to wait for 4.2.1.  Ian?

I'd defer to you h/v guys but IMHO only fixes for super critical issues
should be going in for 4.2.0 now.

4.2.1 is not that far away and these fixes will be in 4.2-testing
between 4.2.0 and then.

> 
> The patch looks OK, but why didn't you put the memory_event calls back
> in mov_to_cr(), which is where they were before 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 Tue Sep 11 07:52:11 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 2012 07: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 1TBLGI-00063s-O5; Tue, 11 Sep 2012 07:51: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 1TBLGG-00063m-MK
	for xen-devel@lists.xen.org; Tue, 11 Sep 2012 07:51:56 +0000
Received: from [85.158.143.35:24411] by server-2.bemta-4.messagelabs.com id
	DF/7D-21239-C9DEE405; Tue, 11 Sep 2012 07:51:56 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1347349914!14401387!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDg1MTY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21632 invoked from network); 11 Sep 2012 07:51:54 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Sep 2012 07:51:54 -0000
X-IronPort-AV: E=Sophos;i="4.80,402,1344211200"; d="scan'208";a="14460688"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Sep 2012 07:51: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.279.1;
	Tue, 11 Sep 2012 08:51:54 +0100
Message-ID: <1347349913.10570.98.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Tim Deegan <tim@xen.org>
Date: Tue, 11 Sep 2012 08:51:53 +0100
In-Reply-To: <20120911072225.GB78597@ocelot.phlegethon.org>
References: <CANSvah6PU5SOKd19qfbvTXvz4spcPYVUQHmiirmm5hPvmzR+pg@mail.gmail.com>
	<CC741C8D.4B3AF%keir@xen.org>
	<CANSvah6nWfKP9-PLSkhbFcO2ONmfj5Hhs-+3r0MhjOUHU1qNfg@mail.gmail.com>
	<CAB10MZDy0zTQNO5APyWMgbhiKw+4uXZ2pYMKHqJ3MNKR5gLjjA@mail.gmail.com>
	<CANSvah4NN05Zimm2BmKO9ofC04G+D7Svrg+2xwp0yM16Cn3CRw@mail.gmail.com>
	<20120911072225.GB78597@ocelot.phlegethon.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Aravindh Puthiyaparambil <aravindh@virtuata.com>,
	"Keir \(Xen.org\)" <keir@xen.org>, Steven Maresca <steve@zentific.com>,
	"andres@lagarcavilla.org" <andres@lagarcavilla.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] mem_event: fix regression affecting CR3,
 CR4 memory events
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-09-11 at 08:22 +0100, Tim Deegan wrote:
> I think it's too late to get any more code changes in to 4.2.0, so this
> will have to wait for 4.2.1.  Ian?

I'd defer to you h/v guys but IMHO only fixes for super critical issues
should be going in for 4.2.0 now.

4.2.1 is not that far away and these fixes will be in 4.2-testing
between 4.2.0 and then.

> 
> The patch looks OK, but why didn't you put the memory_event calls back
> in mov_to_cr(), which is where they were before 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 Tue Sep 11 07:54:43 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 2012 07:54: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 1TBLIj-0006H9-4i; Tue, 11 Sep 2012 07:54: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 1TBLIh-0006Gv-85
	for xen-devel@lists.xen.org; Tue, 11 Sep 2012 07:54:27 +0000
Received: from [85.158.143.35:41393] by server-1.bemta-4.messagelabs.com id
	8E/75-12504-23EEE405; Tue, 11 Sep 2012 07:54:26 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1347350051!13079134!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDg1MTY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20367 invoked from network); 11 Sep 2012 07:54:12 -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;
	11 Sep 2012 07:54:12 -0000
X-IronPort-AV: E=Sophos;i="4.80,402,1344211200"; d="scan'208";a="14460765"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Sep 2012 07:54: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.279.1;
	Tue, 11 Sep 2012 08:54:11 +0100
Message-ID: <1347350050.10570.100.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Matt Wilson <msw@amazon.com>
Date: Tue, 11 Sep 2012 08:54:10 +0100
In-Reply-To: <20120910204635.GA32584@u002268147cd4502c336d.ant.amazon.com>
References: <patchbomb.1346992557@u002268147cd4502c336d.ant.amazon.com>
	<3b3582f4dc423daa8040.1346992558@u002268147cd4502c336d.ant.amazon.com>
	<1347293350.5305.113.camel@zakaz.uk.xensource.com>
	<20120910204635.GA32584@u002268147cd4502c336d.ant.amazon.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 1 of 2 v3] tools: check for documentation
 generation tools at configure 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 Mon, 2012-09-10 at 21:46 +0100, Matt Wilson wrote:
> On Mon, Sep 10, 2012 at 05:09:10PM +0100, Ian Campbell wrote:
> > 
> > > diff -r d7e4efa17fb0 -r 3b3582f4dc42 tools/m4/docs_tool.m4
> > > --- /dev/null	Thu Jan 01 00:00:00 1970 +0000
> > > +++ b/tools/m4/docs_tool.m4	Thu Sep 06 21:31:51 2012 -0700
> > > @@ -0,0 +1,10 @@
> > > +# $1: autoconf variable name
> > > +# $2: list of programs to check for
> > > +AC_DEFUN([AX_DOCS_TOOL_PROGS], [
> > > +dnl
> > > +    AC_ARG_VAR([$1], [Path to ] m4_tolower($1) [ tool])
> > > +    AC_PATH_PROGS([$1], [$2])
> > > +    AS_IF([! test -x "$ac_cv_path_$1"], [
> > > +        AC_MSG_WARN([$2 is not available so some documentation won't be built])
> > 
> > Did you mean m4_tolower($1) for this last $2 as well? Since $2 is the
> > list of potential command names this will look a bit odd I think?
> 
> Yea, that could be better. Though I kind of like that it shows the
> programs that were checked. It'd look like:
>  
>  markdown markdown_py is not available so some documentation won't be built
> 
> Maybe just drop 'is' to avoid the verb mismatch.

Or "m4_tolower($1) ($2) is not available ..."? (properly m4 quoted by
someone who knows what they are doing, of course ;-))

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 11 07:54:43 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 2012 07:54: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 1TBLIj-0006H9-4i; Tue, 11 Sep 2012 07:54: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 1TBLIh-0006Gv-85
	for xen-devel@lists.xen.org; Tue, 11 Sep 2012 07:54:27 +0000
Received: from [85.158.143.35:41393] by server-1.bemta-4.messagelabs.com id
	8E/75-12504-23EEE405; Tue, 11 Sep 2012 07:54:26 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1347350051!13079134!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDg1MTY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20367 invoked from network); 11 Sep 2012 07:54:12 -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;
	11 Sep 2012 07:54:12 -0000
X-IronPort-AV: E=Sophos;i="4.80,402,1344211200"; d="scan'208";a="14460765"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Sep 2012 07:54: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.279.1;
	Tue, 11 Sep 2012 08:54:11 +0100
Message-ID: <1347350050.10570.100.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Matt Wilson <msw@amazon.com>
Date: Tue, 11 Sep 2012 08:54:10 +0100
In-Reply-To: <20120910204635.GA32584@u002268147cd4502c336d.ant.amazon.com>
References: <patchbomb.1346992557@u002268147cd4502c336d.ant.amazon.com>
	<3b3582f4dc423daa8040.1346992558@u002268147cd4502c336d.ant.amazon.com>
	<1347293350.5305.113.camel@zakaz.uk.xensource.com>
	<20120910204635.GA32584@u002268147cd4502c336d.ant.amazon.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 1 of 2 v3] tools: check for documentation
 generation tools at configure 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 Mon, 2012-09-10 at 21:46 +0100, Matt Wilson wrote:
> On Mon, Sep 10, 2012 at 05:09:10PM +0100, Ian Campbell wrote:
> > 
> > > diff -r d7e4efa17fb0 -r 3b3582f4dc42 tools/m4/docs_tool.m4
> > > --- /dev/null	Thu Jan 01 00:00:00 1970 +0000
> > > +++ b/tools/m4/docs_tool.m4	Thu Sep 06 21:31:51 2012 -0700
> > > @@ -0,0 +1,10 @@
> > > +# $1: autoconf variable name
> > > +# $2: list of programs to check for
> > > +AC_DEFUN([AX_DOCS_TOOL_PROGS], [
> > > +dnl
> > > +    AC_ARG_VAR([$1], [Path to ] m4_tolower($1) [ tool])
> > > +    AC_PATH_PROGS([$1], [$2])
> > > +    AS_IF([! test -x "$ac_cv_path_$1"], [
> > > +        AC_MSG_WARN([$2 is not available so some documentation won't be built])
> > 
> > Did you mean m4_tolower($1) for this last $2 as well? Since $2 is the
> > list of potential command names this will look a bit odd I think?
> 
> Yea, that could be better. Though I kind of like that it shows the
> programs that were checked. It'd look like:
>  
>  markdown markdown_py is not available so some documentation won't be built
> 
> Maybe just drop 'is' to avoid the verb mismatch.

Or "m4_tolower($1) ($2) is not available ..."? (properly m4 quoted by
someone who knows what they are doing, of course ;-))

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 11 07:56:07 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 2012 07: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 1TBLKB-0006Sv-KD; Tue, 11 Sep 2012 07:55: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 1TBLKA-0006Sj-9w
	for xen-devel@lists.xen.org; Tue, 11 Sep 2012 07:55:58 +0000
Received: from [85.158.143.99:2997] by server-1.bemta-4.messagelabs.com id
	1E/38-12504-D8EEE405; Tue, 11 Sep 2012 07:55:57 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1347350156!26289345!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM5NTk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5901 invoked from network); 11 Sep 2012 07:55:57 -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;
	11 Sep 2012 07:55:57 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 11 Sep 2012 08:55:56 +0100
Message-Id: <504F0AA9020000780009A704@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 11 Sep 2012 08:55:53 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Daniel De Graaf" <dgdegra@tycho.nsa.gov>
References: <1347306553-20980-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1347306553-20980-18-git-send-email-dgdegra@tycho.nsa.gov>
In-Reply-To: <1347306553-20980-18-git-send-email-dgdegra@tycho.nsa.gov>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Tim Deegan <tim@xen.org>, Keir Fraser <keir@xen.org>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 17/20] arch/x86: use XSM hooks for
 get_pg_owner access checks
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 10.09.12 at 21:49, Daniel De Graaf <dgdegra@tycho.nsa.gov> wrote:
> --- a/xen/arch/x86/mm.c
> +++ b/xen/arch/x86/mm.c
> @@ -2882,11 +2882,6 @@ static struct domain *get_pg_owner(domid_t domid)
>          pg_owner = rcu_lock_domain(dom_io);
>          break;
>      case DOMID_XEN:
> -        if ( !IS_PRIV(curr) )
> -        {
> -            MEM_LOG("Cannot set foreign dom");
> -            break;
> -        }
>          pg_owner = rcu_lock_domain(dom_xen);
>          break;
>      default:
> @@ -2895,12 +2890,6 @@ static struct domain *get_pg_owner(domid_t domid)
>              MEM_LOG("Unknown domain '%u'", domid);
>              break;
>          }
> -        if ( !IS_PRIV_FOR(curr, pg_owner) )
> -        {
> -            MEM_LOG("Cannot set foreign dom");
> -            rcu_unlock_domain(pg_owner);
> -            pg_owner = NULL;
> -        }
>          break;
>      }
>  
> @@ -3008,6 +2997,13 @@ long do_mmuext_op(
>          goto out;
>      }
>  
> +    rc = xsm_mmuext_op(d, pg_owner);
> +    if ( rc )
> +    {
> +        rcu_unlock_domain(pg_owner);
> +        goto out;
> +    }
> +

While this part is fine, ...

>      for ( i = 0; i < count; i++ )
>      {
>          if ( hypercall_preempt_check() )
> @@ -3483,11 +3479,6 @@ long do_mmu_update(
>              rc = -EINVAL;
>              goto out;
>          }
> -        if ( !IS_PRIV_FOR(d, pt_owner) )
> -        {
> -            rc = -ESRCH;
> -            goto out;
> -        }

... this one isn't (at least in conjunction with them all becoming
indirect calls unconditionally) - you replace a single validation per
set of requests with one validation per request.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 11 07:56:07 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 2012 07: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 1TBLKB-0006Sv-KD; Tue, 11 Sep 2012 07:55: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 1TBLKA-0006Sj-9w
	for xen-devel@lists.xen.org; Tue, 11 Sep 2012 07:55:58 +0000
Received: from [85.158.143.99:2997] by server-1.bemta-4.messagelabs.com id
	1E/38-12504-D8EEE405; Tue, 11 Sep 2012 07:55:57 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1347350156!26289345!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM5NTk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5901 invoked from network); 11 Sep 2012 07:55:57 -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;
	11 Sep 2012 07:55:57 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 11 Sep 2012 08:55:56 +0100
Message-Id: <504F0AA9020000780009A704@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 11 Sep 2012 08:55:53 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Daniel De Graaf" <dgdegra@tycho.nsa.gov>
References: <1347306553-20980-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1347306553-20980-18-git-send-email-dgdegra@tycho.nsa.gov>
In-Reply-To: <1347306553-20980-18-git-send-email-dgdegra@tycho.nsa.gov>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Tim Deegan <tim@xen.org>, Keir Fraser <keir@xen.org>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 17/20] arch/x86: use XSM hooks for
 get_pg_owner access checks
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 10.09.12 at 21:49, Daniel De Graaf <dgdegra@tycho.nsa.gov> wrote:
> --- a/xen/arch/x86/mm.c
> +++ b/xen/arch/x86/mm.c
> @@ -2882,11 +2882,6 @@ static struct domain *get_pg_owner(domid_t domid)
>          pg_owner = rcu_lock_domain(dom_io);
>          break;
>      case DOMID_XEN:
> -        if ( !IS_PRIV(curr) )
> -        {
> -            MEM_LOG("Cannot set foreign dom");
> -            break;
> -        }
>          pg_owner = rcu_lock_domain(dom_xen);
>          break;
>      default:
> @@ -2895,12 +2890,6 @@ static struct domain *get_pg_owner(domid_t domid)
>              MEM_LOG("Unknown domain '%u'", domid);
>              break;
>          }
> -        if ( !IS_PRIV_FOR(curr, pg_owner) )
> -        {
> -            MEM_LOG("Cannot set foreign dom");
> -            rcu_unlock_domain(pg_owner);
> -            pg_owner = NULL;
> -        }
>          break;
>      }
>  
> @@ -3008,6 +2997,13 @@ long do_mmuext_op(
>          goto out;
>      }
>  
> +    rc = xsm_mmuext_op(d, pg_owner);
> +    if ( rc )
> +    {
> +        rcu_unlock_domain(pg_owner);
> +        goto out;
> +    }
> +

While this part is fine, ...

>      for ( i = 0; i < count; i++ )
>      {
>          if ( hypercall_preempt_check() )
> @@ -3483,11 +3479,6 @@ long do_mmu_update(
>              rc = -EINVAL;
>              goto out;
>          }
> -        if ( !IS_PRIV_FOR(d, pt_owner) )
> -        {
> -            rc = -ESRCH;
> -            goto out;
> -        }

... this one isn't (at least in conjunction with them all becoming
indirect calls unconditionally) - you replace a single validation per
set of requests with one validation per request.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 11 07:57:11 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 2012 07: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 1TBLLC-0006bT-2t; Tue, 11 Sep 2012 07:57:02 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1TBLLB-0006af-1d
	for xen-devel@lists.xensource.com; Tue, 11 Sep 2012 07:57:01 +0000
X-Env-Sender: fantonifabio@tiscali.it
X-Msg-Ref: server-12.tower-27.messagelabs.com!1347350212!10512113!1
X-Originating-IP: [94.23.245.208]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21121 invoked from network); 11 Sep 2012 07:56:52 -0000
Received: from lnx3.fantu.it (HELO lnx3.fantu.it) (94.23.245.208)
	by server-12.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 11 Sep 2012 07:56:52 -0000
Received: from localhost (localhost.localdomain [127.0.0.1])
	by lnx3.fantu.it (Postfix) with ESMTP id D19E140261C;
	Tue, 11 Sep 2012 09:56:49 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at lnx3.fantu.it
Received: from lnx3.fantu.it ([127.0.0.1])
	by localhost (lnx3.fantu.it [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id qrnh8Bo1uKcB; Tue, 11 Sep 2012 09:56:48 +0200 (CEST)
Received: from [192.168.178.50]
	(host159-164-dynamic.56-82-r.retail.telecomitalia.it [82.56.164.159])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: prova@fantu.it)
	by lnx3.fantu.it (Postfix) with ESMTPSA id 29F4C401989;
	Tue, 11 Sep 2012 09:56:48 +0200 (CEST)
Message-ID: <504EEEBA.9070708@tiscali.it>
Date: Tue, 11 Sep 2012 09:56:42 +0200
From: Fabio Fantoni <fantonifabio@tiscali.it>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:14.0) Gecko/20120713 Thunderbird/14.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <5049EC11.9080302@tiscali.it>
	<1347030955.30018.115.camel@zakaz.uk.xensource.com>
	<504DB165.6040500@tiscali.it>
	<1347269362.5305.39.camel@zakaz.uk.xensource.com>
	<504DECE7.1050404@tiscali.it>
	<1347284515.5305.85.camel@zakaz.uk.xensource.com>
	<504DF87E.6020901@tiscali.it>
	<1347287277.5305.90.camel@zakaz.uk.xensource.com>
In-Reply-To: <1347287277.5305.90.camel@zakaz.uk.xensource.com>
Cc: xen-devel <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Test report of xen 4.2.0-rc4
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="===============1364604165157897735=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Questo è un messaggio firmato digitalmente in formato MIME.

--===============1364604165157897735==
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms070209070801020208000300"

Questo è un messaggio firmato digitalmente in formato MIME.

--------------ms070209070801020208000300
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable

Il 10/09/2012 16:27, Ian Campbell ha scritto:
> On Mon, 2012-09-10 at 15:26 +0100, Fabio Fantoni wrote:
>> gdb --args xl -vvv cd-eject W7 hdb
>> GNU gdb (GDB) 7.4.1-debian
>> Copyright (C) 2012 Free Software Foundation, Inc.
>> License GPLv3+: GNU GPL version 3 or later
>> <http://gnu.org/licenses/gpl.html>
>> This is free software: you are free to change and redistribute it.
>> There is NO WARRANTY, to the extent permitted by law.  Type "show copy=
ing"
>> and "show warranty" for details.
>> This GDB was configured as "x86_64-linux-gnu".
>> For bug reporting instructions, please see:
>> <http://www.gnu.org/software/gdb/bugs/>...
>> Reading symbols from /usr/sbin/xl...done.
>> (gdb) run
>> Starting program: /usr/sbin/xl -vvv cd-eject W7 hdb
>> [Thread debugging using libthread_db enabled]
>> Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so=
=2E1".
>> libxl: debug: libxl.c:2143:libxl_cdrom_insert: ao 0x623980: create:
>> how=3D(nil) callback=3D(nil) poller=3D0x6239e0
>> libxl: debug: libxl_device.c:229:libxl__device_disk_set_backend: Disk
>> vdev=3Dhdb spec.backend=3Dunknown
>> libxl: debug: libxl_device.c:175:disk_try_backend: Disk vdev=3Dhdb,
>> backend phy unsuitable as phys path not a block device
>> libxl: debug: libxl_device.c:210:disk_try_backend: Disk vdev=3Dhdb,
>> backend tap unsuitable due to format empty
>> libxl: debug: libxl_device.c:265:libxl__device_disk_set_backend: Disk
>> vdev=3Dhdb, using backend qdisk
>> libxl: debug: libxl_event.c:1497:libxl__ao_complete: ao 0x623980:
>> complete, rc=3D0
>> libxl: debug: libxl.c:2236:libxl_cdrom_insert: ao 0x623980: inprogress=
:
>> poller=3D0x6239e0, flags=3Dic
>> libxl: debug: libxl_event.c:1469:libxl__ao__destroy: ao 0x623980: dest=
roy
>> xc: debug: hypercall buffer: total allocations:4 total releases:4
>> xc: debug: hypercall buffer: current allocations:0 maximum allocations=
:2
>> xc: debug: hypercall buffer: cache current size:2
>> xc: debug: hypercall buffer: cache hits:1 misses:2 toobig:1
>> [Inferior 1 (process 5581) exited normally]
>> (gdb) bt
>> No stack.
> That's because it seems to be working for you now... There is no crash
> here.
>
> Ian.
>
>
>
> -----
> Nessun virus nel messaggio.
> Controllato da AVG - www.avg.com
> Versione: 2012.0.2197 / Database dei virus: 2437/5259 -  Data di rilasc=
io: 09/09/2012
>
>
After issuing the command:
xl -vvv cd-eject PRECISEHVM hdb
libxl: debug: libxl.c:2143:libxl_cdrom_insert: ao 0x1812980: create:=20
how=3D(nil) callback=3D(nil) poller=3D0x18129e0
libxl: debug: libxl_device.c:229:libxl__device_disk_set_backend: Disk=20
vdev=3Dhdb spec.backend=3Dunknown
libxl: debug: libxl_device.c:175:disk_try_backend: Disk vdev=3Dhdb,=20
backend phy unsuitable as phys path not a block device
libxl: debug: libxl_device.c:210:disk_try_backend: Disk vdev=3Dhdb,=20
backend tap unsuitable due to format empty
libxl: debug: libxl_device.c:265:libxl__device_disk_set_backend: Disk=20
vdev=3Dhdb, using backend qdisk
libxl: debug: libxl_event.c:1497:libxl__ao_complete: ao 0x1812980:=20
complete, rc=3D0
libxl: debug: libxl.c:2236:libxl_cdrom_insert: ao 0x1812980: inprogress: =

poller=3D0x18129e0, flags=3Dic
libxl: debug: libxl_event.c:1469:libxl__ao__destroy: ao 0x1812980: destro=
y
xc: debug: hypercall buffer: total allocations:4 total releases:4
xc: debug: hypercall buffer: current allocations:0 maximum allocations:2
xc: debug: hypercall buffer: cache current size:2
xc: debug: hypercall buffer: cache hits:1 misses:2 toobig:1

The cdrom remain in domU and working

I also tried with insert:
root@vfarm:~# xl -vvv cd-insert PRECISEHVM hdb=20
raw:/mnt/vm/iso/Clonezilla.iso
libxl: debug: libxl.c:2143:libxl_cdrom_insert: ao 0xedd980: create:=20
how=3D(nil) callback=3D(nil) poller=3D0xedd9e0
Errore di segmentazione

But give segmentation error and nothing change on domU (remain the old=20
cdrom working)

Can you tell me datails about your dom0 configuration please?


--------------ms070209070801020208000300
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: Firma crittografica S/MIME

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINhjCC
BjQwggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT
DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp
Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3
MTAyNDIxMDI1NVoXDTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T
dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu
aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs
aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOM
KqANy9BV7V0igWdGxA8IU77L3aTxErQ+fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi
8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke/s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8M
DP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHksw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y
2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHHtOkzUreG//CsFnB9+uaYSlR65cdG
zTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB
Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd+q9rMfPIHeOsuzAfBgNV
HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH
MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3
dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu
c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v
c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0
dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93
d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqp
Jw3I07QWke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Mic
c/NXcs7kPBRdn6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9Jphw
UPTXwHovjavRnhUQHLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMc
p+reg9901zkyT3fDW/ivJVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT
+HBDYtbuvexNftwNQKD5193A7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1X
hwby6mLhkbaXslkVtwEWT3Van49rKjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvO
hNz/QplNa+VkIsrcp7+8ZhP1l1b2U6MaxIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC
0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqh
AChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H75dVCV33K6FuxZrf09yTz+Vx/PkdRUYk
XmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHSjCCBjKgAwIBAgICHmMwDQYJKoZIhvcNAQEF
BQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJT
ZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD
bGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0xMjAzMTgyMjE0MzBa
Fw0xNDAzMjAwODU3MDlaMIGMMRkwFwYDVQQNExBlQjZPRTM3UlJOUHlsNW0yMQswCQYDVQQG
EwJJVDEQMA4GA1UECBMHQmVyZ2FtbzEQMA4GA1UEBxMHUm92ZXR0YTEWMBQGA1UEAxMNRmFi
aW8gRmFudG9uaTEmMCQGCSqGSIb3DQEJARYXZmFudG9uaWZhYmlvQHRpc2NhbGkuaXQwggEi
MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC1XhckXsX23vgJq76s2f0KT8U8Msov5QgV
10eQBb2wL/TzcmqtZotI7ztKVhio3ehHg+mfu+3EqOkX9Umgut8rP0bPi7AGjkPXbOTT/cSU
Xz2Kw31VGOmiOVoUFGvpQitp3weCkhUJLBipI8EpNyBXpjtQ9yCpnIAqfuc77ybfSnCy7tTR
MBq1BUkfjH1+GL45riosuS4+F+MSUvlYzLiT4rAduAX1Y2IuORDsf9Bce8GBxa6syP9rCyzl
Vk7DIX5k8j2vlnyRATIypn5CQLQxGT6e0f6ac4gvWOHwO2QEBsmZKKs1ZidE4q/9OoNXYX6A
jnHtp1H1vcrek/vVcs19AgMBAAGjggOyMIIDrjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAd
BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFFan8cbEWWBmSTWFtLk2
YNdAcGUbMB8GA1UdIwQYMBaAFK5Vg2/sMcq59x36r2sx88gd46y7MCIGA1UdEQQbMBmBF2Zh
bnRvbmlmYWJpb0B0aXNjYWxpLml0MIICIQYDVR0gBIICGDCCAhQwggIQBgsrBgEEAYG1NwEC
AjCCAf8wLgYIKwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYw
NAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYw
gfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMC
AQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNjb3JkaW5nIHRvIHRoZSBDbGFz
cyAyIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3ks
IHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGluIGNvbXBsaWFuY2Ug
b2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMIGcBggrBgEFBQcCAjCBjzAnFiBT
dGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgECGmRMaWFiaWxpdHkgYW5kIHdh
cnJhbnRpZXMgYXJlIGxpbWl0ZWQhIFNlZSBzZWN0aW9uICJMZWdhbCBhbmQgTGltaXRhdGlv
bnMiIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3kuMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6
Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUyLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYI
KwYBBQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MyL2NsaWVudC9j
YTBCBggrBgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNz
Mi5jbGllbnQuY2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzAN
BgkqhkiG9w0BAQUFAAOCAQEAjzHNqifpDVMkH1TSPFZVIiQ4fh49/V5JMpstgqEZPDaDe5r8
h+fMBZtUa6LLMco03Z9BNEXlqlXKiFk8feVYB8obEjz7YYq1XhO9q7JUmkSs0WGIH4xU0XB1
kPC8T8H+5E//84poYSFHE4pA+Ff68UANP2/EuFJWMjegiefnOr8aM42OAcUkjEWSlautIIX8
oD2GizwQYjWdDDjEonbuMKFP6rY2xGI3PSLI3IVU2opb0/itNhQui3WRxafloJqTlriY8m8+
qSLr2HGftbBlbyzVWB8o//aW0H0LMabjkIvrm7Zmh2vcCxiSxGBwYASuSYXGuQiKAgGptUs1
XJLZuzGCA9owggPWAgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20g
THRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG
A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EC
Ah5jMAkGBSsOAwIaBQCgggIbMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcN
AQkFMQ8XDTEyMDkxMTA3NTY0MlowIwYJKoZIhvcNAQkEMRYEFKC3ku9Ulg0A6+eoI1L19HC2
ZDsgMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggqhkiG
9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcN
AwICASgwgaQGCSsGAQQBgjcQBDGBljCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0
YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25p
bmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp
ZW50IENBAgIeYzCBpgYLKoZIhvcNAQkQAgsxgZaggZMwgYwxCzAJBgNVBAYTAklMMRYwFAYD
VQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0
ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRp
YXRlIENsaWVudCBDQQICHmMwDQYJKoZIhvcNAQEBBQAEggEApek2z+w1eSmMJG2G7CTKiWBM
6Y6V2J8ElHcM/j3jLOiqmLZxkX4haQ2FuGk16iAxZi27AGRiFeGPiErNAu7SKAEXulg3fawF
NwW+Uhw0XEiS+K++zPOSssCoIWjmhxH1EBIcqDsll/hnYDtiVbjJKQJ7wpqAWlLOF45dH6n4
HQmb9e8mv7ZGY4kd5/JdhKUcgitx01qgoZTHvwrs1WQX0uAw1N0pXj82iLHQUPl20bDxvtMU
7aLfJMMzHlpCAgqgJN7C0rgs0TZ1u7bIRkLAzzFmlFG2oeRTAYZPeH5jhiZZNlg2Dd70Tr6c
fh6LvsDwCzOnff0gB+8bYjrKKJyU8QAAAAAAAA==
--------------ms070209070801020208000300--


--===============1364604165157897735==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============1364604165157897735==--


From xen-devel-bounces@lists.xen.org Tue Sep 11 07:57:11 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 2012 07: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 1TBLLC-0006bT-2t; Tue, 11 Sep 2012 07:57:02 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1TBLLB-0006af-1d
	for xen-devel@lists.xensource.com; Tue, 11 Sep 2012 07:57:01 +0000
X-Env-Sender: fantonifabio@tiscali.it
X-Msg-Ref: server-12.tower-27.messagelabs.com!1347350212!10512113!1
X-Originating-IP: [94.23.245.208]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21121 invoked from network); 11 Sep 2012 07:56:52 -0000
Received: from lnx3.fantu.it (HELO lnx3.fantu.it) (94.23.245.208)
	by server-12.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 11 Sep 2012 07:56:52 -0000
Received: from localhost (localhost.localdomain [127.0.0.1])
	by lnx3.fantu.it (Postfix) with ESMTP id D19E140261C;
	Tue, 11 Sep 2012 09:56:49 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at lnx3.fantu.it
Received: from lnx3.fantu.it ([127.0.0.1])
	by localhost (lnx3.fantu.it [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id qrnh8Bo1uKcB; Tue, 11 Sep 2012 09:56:48 +0200 (CEST)
Received: from [192.168.178.50]
	(host159-164-dynamic.56-82-r.retail.telecomitalia.it [82.56.164.159])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: prova@fantu.it)
	by lnx3.fantu.it (Postfix) with ESMTPSA id 29F4C401989;
	Tue, 11 Sep 2012 09:56:48 +0200 (CEST)
Message-ID: <504EEEBA.9070708@tiscali.it>
Date: Tue, 11 Sep 2012 09:56:42 +0200
From: Fabio Fantoni <fantonifabio@tiscali.it>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:14.0) Gecko/20120713 Thunderbird/14.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <5049EC11.9080302@tiscali.it>
	<1347030955.30018.115.camel@zakaz.uk.xensource.com>
	<504DB165.6040500@tiscali.it>
	<1347269362.5305.39.camel@zakaz.uk.xensource.com>
	<504DECE7.1050404@tiscali.it>
	<1347284515.5305.85.camel@zakaz.uk.xensource.com>
	<504DF87E.6020901@tiscali.it>
	<1347287277.5305.90.camel@zakaz.uk.xensource.com>
In-Reply-To: <1347287277.5305.90.camel@zakaz.uk.xensource.com>
Cc: xen-devel <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Test report of xen 4.2.0-rc4
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="===============1364604165157897735=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Questo è un messaggio firmato digitalmente in formato MIME.

--===============1364604165157897735==
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms070209070801020208000300"

Questo è un messaggio firmato digitalmente in formato MIME.

--------------ms070209070801020208000300
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable

Il 10/09/2012 16:27, Ian Campbell ha scritto:
> On Mon, 2012-09-10 at 15:26 +0100, Fabio Fantoni wrote:
>> gdb --args xl -vvv cd-eject W7 hdb
>> GNU gdb (GDB) 7.4.1-debian
>> Copyright (C) 2012 Free Software Foundation, Inc.
>> License GPLv3+: GNU GPL version 3 or later
>> <http://gnu.org/licenses/gpl.html>
>> This is free software: you are free to change and redistribute it.
>> There is NO WARRANTY, to the extent permitted by law.  Type "show copy=
ing"
>> and "show warranty" for details.
>> This GDB was configured as "x86_64-linux-gnu".
>> For bug reporting instructions, please see:
>> <http://www.gnu.org/software/gdb/bugs/>...
>> Reading symbols from /usr/sbin/xl...done.
>> (gdb) run
>> Starting program: /usr/sbin/xl -vvv cd-eject W7 hdb
>> [Thread debugging using libthread_db enabled]
>> Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so=
=2E1".
>> libxl: debug: libxl.c:2143:libxl_cdrom_insert: ao 0x623980: create:
>> how=3D(nil) callback=3D(nil) poller=3D0x6239e0
>> libxl: debug: libxl_device.c:229:libxl__device_disk_set_backend: Disk
>> vdev=3Dhdb spec.backend=3Dunknown
>> libxl: debug: libxl_device.c:175:disk_try_backend: Disk vdev=3Dhdb,
>> backend phy unsuitable as phys path not a block device
>> libxl: debug: libxl_device.c:210:disk_try_backend: Disk vdev=3Dhdb,
>> backend tap unsuitable due to format empty
>> libxl: debug: libxl_device.c:265:libxl__device_disk_set_backend: Disk
>> vdev=3Dhdb, using backend qdisk
>> libxl: debug: libxl_event.c:1497:libxl__ao_complete: ao 0x623980:
>> complete, rc=3D0
>> libxl: debug: libxl.c:2236:libxl_cdrom_insert: ao 0x623980: inprogress=
:
>> poller=3D0x6239e0, flags=3Dic
>> libxl: debug: libxl_event.c:1469:libxl__ao__destroy: ao 0x623980: dest=
roy
>> xc: debug: hypercall buffer: total allocations:4 total releases:4
>> xc: debug: hypercall buffer: current allocations:0 maximum allocations=
:2
>> xc: debug: hypercall buffer: cache current size:2
>> xc: debug: hypercall buffer: cache hits:1 misses:2 toobig:1
>> [Inferior 1 (process 5581) exited normally]
>> (gdb) bt
>> No stack.
> That's because it seems to be working for you now... There is no crash
> here.
>
> Ian.
>
>
>
> -----
> Nessun virus nel messaggio.
> Controllato da AVG - www.avg.com
> Versione: 2012.0.2197 / Database dei virus: 2437/5259 -  Data di rilasc=
io: 09/09/2012
>
>
After issuing the command:
xl -vvv cd-eject PRECISEHVM hdb
libxl: debug: libxl.c:2143:libxl_cdrom_insert: ao 0x1812980: create:=20
how=3D(nil) callback=3D(nil) poller=3D0x18129e0
libxl: debug: libxl_device.c:229:libxl__device_disk_set_backend: Disk=20
vdev=3Dhdb spec.backend=3Dunknown
libxl: debug: libxl_device.c:175:disk_try_backend: Disk vdev=3Dhdb,=20
backend phy unsuitable as phys path not a block device
libxl: debug: libxl_device.c:210:disk_try_backend: Disk vdev=3Dhdb,=20
backend tap unsuitable due to format empty
libxl: debug: libxl_device.c:265:libxl__device_disk_set_backend: Disk=20
vdev=3Dhdb, using backend qdisk
libxl: debug: libxl_event.c:1497:libxl__ao_complete: ao 0x1812980:=20
complete, rc=3D0
libxl: debug: libxl.c:2236:libxl_cdrom_insert: ao 0x1812980: inprogress: =

poller=3D0x18129e0, flags=3Dic
libxl: debug: libxl_event.c:1469:libxl__ao__destroy: ao 0x1812980: destro=
y
xc: debug: hypercall buffer: total allocations:4 total releases:4
xc: debug: hypercall buffer: current allocations:0 maximum allocations:2
xc: debug: hypercall buffer: cache current size:2
xc: debug: hypercall buffer: cache hits:1 misses:2 toobig:1

The cdrom remain in domU and working

I also tried with insert:
root@vfarm:~# xl -vvv cd-insert PRECISEHVM hdb=20
raw:/mnt/vm/iso/Clonezilla.iso
libxl: debug: libxl.c:2143:libxl_cdrom_insert: ao 0xedd980: create:=20
how=3D(nil) callback=3D(nil) poller=3D0xedd9e0
Errore di segmentazione

But give segmentation error and nothing change on domU (remain the old=20
cdrom working)

Can you tell me datails about your dom0 configuration please?


--------------ms070209070801020208000300
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: Firma crittografica S/MIME

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINhjCC
BjQwggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT
DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp
Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3
MTAyNDIxMDI1NVoXDTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T
dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu
aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs
aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOM
KqANy9BV7V0igWdGxA8IU77L3aTxErQ+fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi
8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke/s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8M
DP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHksw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y
2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHHtOkzUreG//CsFnB9+uaYSlR65cdG
zTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB
Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd+q9rMfPIHeOsuzAfBgNV
HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH
MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3
dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu
c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v
c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0
dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93
d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqp
Jw3I07QWke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Mic
c/NXcs7kPBRdn6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9Jphw
UPTXwHovjavRnhUQHLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMc
p+reg9901zkyT3fDW/ivJVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT
+HBDYtbuvexNftwNQKD5193A7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1X
hwby6mLhkbaXslkVtwEWT3Van49rKjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvO
hNz/QplNa+VkIsrcp7+8ZhP1l1b2U6MaxIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC
0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqh
AChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H75dVCV33K6FuxZrf09yTz+Vx/PkdRUYk
XmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHSjCCBjKgAwIBAgICHmMwDQYJKoZIhvcNAQEF
BQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJT
ZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD
bGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0xMjAzMTgyMjE0MzBa
Fw0xNDAzMjAwODU3MDlaMIGMMRkwFwYDVQQNExBlQjZPRTM3UlJOUHlsNW0yMQswCQYDVQQG
EwJJVDEQMA4GA1UECBMHQmVyZ2FtbzEQMA4GA1UEBxMHUm92ZXR0YTEWMBQGA1UEAxMNRmFi
aW8gRmFudG9uaTEmMCQGCSqGSIb3DQEJARYXZmFudG9uaWZhYmlvQHRpc2NhbGkuaXQwggEi
MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC1XhckXsX23vgJq76s2f0KT8U8Msov5QgV
10eQBb2wL/TzcmqtZotI7ztKVhio3ehHg+mfu+3EqOkX9Umgut8rP0bPi7AGjkPXbOTT/cSU
Xz2Kw31VGOmiOVoUFGvpQitp3weCkhUJLBipI8EpNyBXpjtQ9yCpnIAqfuc77ybfSnCy7tTR
MBq1BUkfjH1+GL45riosuS4+F+MSUvlYzLiT4rAduAX1Y2IuORDsf9Bce8GBxa6syP9rCyzl
Vk7DIX5k8j2vlnyRATIypn5CQLQxGT6e0f6ac4gvWOHwO2QEBsmZKKs1ZidE4q/9OoNXYX6A
jnHtp1H1vcrek/vVcs19AgMBAAGjggOyMIIDrjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAd
BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFFan8cbEWWBmSTWFtLk2
YNdAcGUbMB8GA1UdIwQYMBaAFK5Vg2/sMcq59x36r2sx88gd46y7MCIGA1UdEQQbMBmBF2Zh
bnRvbmlmYWJpb0B0aXNjYWxpLml0MIICIQYDVR0gBIICGDCCAhQwggIQBgsrBgEEAYG1NwEC
AjCCAf8wLgYIKwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYw
NAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYw
gfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMC
AQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNjb3JkaW5nIHRvIHRoZSBDbGFz
cyAyIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3ks
IHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGluIGNvbXBsaWFuY2Ug
b2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMIGcBggrBgEFBQcCAjCBjzAnFiBT
dGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgECGmRMaWFiaWxpdHkgYW5kIHdh
cnJhbnRpZXMgYXJlIGxpbWl0ZWQhIFNlZSBzZWN0aW9uICJMZWdhbCBhbmQgTGltaXRhdGlv
bnMiIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3kuMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6
Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUyLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYI
KwYBBQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MyL2NsaWVudC9j
YTBCBggrBgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNz
Mi5jbGllbnQuY2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzAN
BgkqhkiG9w0BAQUFAAOCAQEAjzHNqifpDVMkH1TSPFZVIiQ4fh49/V5JMpstgqEZPDaDe5r8
h+fMBZtUa6LLMco03Z9BNEXlqlXKiFk8feVYB8obEjz7YYq1XhO9q7JUmkSs0WGIH4xU0XB1
kPC8T8H+5E//84poYSFHE4pA+Ff68UANP2/EuFJWMjegiefnOr8aM42OAcUkjEWSlautIIX8
oD2GizwQYjWdDDjEonbuMKFP6rY2xGI3PSLI3IVU2opb0/itNhQui3WRxafloJqTlriY8m8+
qSLr2HGftbBlbyzVWB8o//aW0H0LMabjkIvrm7Zmh2vcCxiSxGBwYASuSYXGuQiKAgGptUs1
XJLZuzGCA9owggPWAgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20g
THRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG
A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EC
Ah5jMAkGBSsOAwIaBQCgggIbMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcN
AQkFMQ8XDTEyMDkxMTA3NTY0MlowIwYJKoZIhvcNAQkEMRYEFKC3ku9Ulg0A6+eoI1L19HC2
ZDsgMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggqhkiG
9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcN
AwICASgwgaQGCSsGAQQBgjcQBDGBljCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0
YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25p
bmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp
ZW50IENBAgIeYzCBpgYLKoZIhvcNAQkQAgsxgZaggZMwgYwxCzAJBgNVBAYTAklMMRYwFAYD
VQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0
ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRp
YXRlIENsaWVudCBDQQICHmMwDQYJKoZIhvcNAQEBBQAEggEApek2z+w1eSmMJG2G7CTKiWBM
6Y6V2J8ElHcM/j3jLOiqmLZxkX4haQ2FuGk16iAxZi27AGRiFeGPiErNAu7SKAEXulg3fawF
NwW+Uhw0XEiS+K++zPOSssCoIWjmhxH1EBIcqDsll/hnYDtiVbjJKQJ7wpqAWlLOF45dH6n4
HQmb9e8mv7ZGY4kd5/JdhKUcgitx01qgoZTHvwrs1WQX0uAw1N0pXj82iLHQUPl20bDxvtMU
7aLfJMMzHlpCAgqgJN7C0rgs0TZ1u7bIRkLAzzFmlFG2oeRTAYZPeH5jhiZZNlg2Dd70Tr6c
fh6LvsDwCzOnff0gB+8bYjrKKJyU8QAAAAAAAA==
--------------ms070209070801020208000300--


--===============1364604165157897735==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============1364604165157897735==--


From xen-devel-bounces@lists.xen.org Tue Sep 11 08:00:16 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 2012 08: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 1TBLO7-00073V-SL; Tue, 11 Sep 2012 08:00: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 1TBLO6-0006rI-0z
	for xen-devel@lists.xen.org; Tue, 11 Sep 2012 08:00:02 +0000
Received: from [85.158.143.99:60956] by server-3.bemta-4.messagelabs.com id
	94/AA-08232-08FEE405; Tue, 11 Sep 2012 08:00:00 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1347350362!29073679!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM5NTk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22334 invoked from network); 11 Sep 2012 07:59:23 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-3.tower-216.messagelabs.com with SMTP;
	11 Sep 2012 07:59:23 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 11 Sep 2012 08:59:22 +0100
Message-Id: <504F0B78020000780009A712@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 11 Sep 2012 08:59:20 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Daniel De Graaf" <dgdegra@tycho.nsa.gov>
References: <1347306553-20980-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1347306553-20980-20-git-send-email-dgdegra@tycho.nsa.gov>
In-Reply-To: <1347306553-20980-20-git-send-email-dgdegra@tycho.nsa.gov>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 19/20] xen: remove rcu_lock_{remote_,
 }target_domain_by_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 10.09.12 at 21:49, Daniel De Graaf <dgdegra@tycho.nsa.gov> wrote:
> --- a/xen/arch/x86/physdev.c
> +++ b/xen/arch/x86/physdev.c
> @@ -106,9 +106,11 @@ int physdev_map_pirq(domid_t domid, int type, int 
> *index, int *pirq_p,
>          return physdev_hvm_map_pirq(d, type, index, pirq_p);
>      }
>  
> -    ret = rcu_lock_target_domain_by_id(domid, &d);
> -    if ( ret )
> -        return ret;
> +    d = rcu_lock_domain_by_any_id(domid);
> +    if ( d == NULL )
> +        return -ESRCH;
> +    if ( d != current->domain && !IS_PRIV_FOR(current->domain, d) )
> +        return -EPERM;

Wasn't one of the goal of the series the _removal_ of the explicit
IS_PRIV()/IS_PRIV_FOR() checks?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 11 08:00:16 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 2012 08: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 1TBLO7-00073V-SL; Tue, 11 Sep 2012 08:00: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 1TBLO6-0006rI-0z
	for xen-devel@lists.xen.org; Tue, 11 Sep 2012 08:00:02 +0000
Received: from [85.158.143.99:60956] by server-3.bemta-4.messagelabs.com id
	94/AA-08232-08FEE405; Tue, 11 Sep 2012 08:00:00 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1347350362!29073679!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM5NTk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22334 invoked from network); 11 Sep 2012 07:59:23 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-3.tower-216.messagelabs.com with SMTP;
	11 Sep 2012 07:59:23 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 11 Sep 2012 08:59:22 +0100
Message-Id: <504F0B78020000780009A712@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 11 Sep 2012 08:59:20 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Daniel De Graaf" <dgdegra@tycho.nsa.gov>
References: <1347306553-20980-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1347306553-20980-20-git-send-email-dgdegra@tycho.nsa.gov>
In-Reply-To: <1347306553-20980-20-git-send-email-dgdegra@tycho.nsa.gov>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 19/20] xen: remove rcu_lock_{remote_,
 }target_domain_by_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 10.09.12 at 21:49, Daniel De Graaf <dgdegra@tycho.nsa.gov> wrote:
> --- a/xen/arch/x86/physdev.c
> +++ b/xen/arch/x86/physdev.c
> @@ -106,9 +106,11 @@ int physdev_map_pirq(domid_t domid, int type, int 
> *index, int *pirq_p,
>          return physdev_hvm_map_pirq(d, type, index, pirq_p);
>      }
>  
> -    ret = rcu_lock_target_domain_by_id(domid, &d);
> -    if ( ret )
> -        return ret;
> +    d = rcu_lock_domain_by_any_id(domid);
> +    if ( d == NULL )
> +        return -ESRCH;
> +    if ( d != current->domain && !IS_PRIV_FOR(current->domain, d) )
> +        return -EPERM;

Wasn't one of the goal of the series the _removal_ of the explicit
IS_PRIV()/IS_PRIV_FOR() checks?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 11 08:09:58 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 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 1TBLXU-0007ih-CW; Tue, 11 Sep 2012 08:09:44 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1TBLXT-0007ic-Nv
	for xen-devel@lists.xen.org; Tue, 11 Sep 2012 08:09:43 +0000
Received: from [85.158.138.51:29724] by server-9.bemta-3.messagelabs.com id
	7E/92-15390-6C1FE405; Tue, 11 Sep 2012 08:09:42 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1347350982!29749189!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM5NTk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11370 invoked from network); 11 Sep 2012 08:09:42 -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;
	11 Sep 2012 08:09:42 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 11 Sep 2012 09:09:41 +0100
Message-Id: <504F0DE3020000780009A727@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 11 Sep 2012 09:09:39 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Daniel De Graaf" <dgdegra@tycho.nsa.gov>
References: <CC741177.4B381%keir@xen.org> <504E5760.5070605@tycho.nsa.gov>
In-Reply-To: <504E5760.5070605@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 v2] Merge IS_PRIV checks into XSM hooks
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.09.12 at 23:10, Daniel De Graaf <dgdegra@tycho.nsa.gov> wrote:
> On 09/10/2012 04:51 PM, Keir Fraser wrote:
>> On 10/09/2012 20:48, "Daniel De Graaf" <dgdegra@tycho.nsa.gov> wrote:
>> 
>>> Overall, this series should not change the behavior of Xen when XSM is
>>> not enabled; however, in some cases, the exact errors that are returned
>>> will be different because security checks have been moved below validity
>>> checks. Also, once applied, newly introduced domctls and sysctls will
>>> not automatically be guarded by IS_PRIV checks - they will need to add
>>> their own permission checking code.
>> 
>> How do we guard against accidentally forgetting to do this?
> 
> The same way you guard against it when adding a new hypercall: when adding
> new functionality that needs access checks, also add the access checks.

Except that previously the access check was done centrally at the
top of do_domctl(), so newly added sub-functions didn't need to
worry.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 11 08:09:58 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 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 1TBLXU-0007ih-CW; Tue, 11 Sep 2012 08:09:44 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1TBLXT-0007ic-Nv
	for xen-devel@lists.xen.org; Tue, 11 Sep 2012 08:09:43 +0000
Received: from [85.158.138.51:29724] by server-9.bemta-3.messagelabs.com id
	7E/92-15390-6C1FE405; Tue, 11 Sep 2012 08:09:42 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1347350982!29749189!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM5NTk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11370 invoked from network); 11 Sep 2012 08:09:42 -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;
	11 Sep 2012 08:09:42 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 11 Sep 2012 09:09:41 +0100
Message-Id: <504F0DE3020000780009A727@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 11 Sep 2012 09:09:39 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Daniel De Graaf" <dgdegra@tycho.nsa.gov>
References: <CC741177.4B381%keir@xen.org> <504E5760.5070605@tycho.nsa.gov>
In-Reply-To: <504E5760.5070605@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 v2] Merge IS_PRIV checks into XSM hooks
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.09.12 at 23:10, Daniel De Graaf <dgdegra@tycho.nsa.gov> wrote:
> On 09/10/2012 04:51 PM, Keir Fraser wrote:
>> On 10/09/2012 20:48, "Daniel De Graaf" <dgdegra@tycho.nsa.gov> wrote:
>> 
>>> Overall, this series should not change the behavior of Xen when XSM is
>>> not enabled; however, in some cases, the exact errors that are returned
>>> will be different because security checks have been moved below validity
>>> checks. Also, once applied, newly introduced domctls and sysctls will
>>> not automatically be guarded by IS_PRIV checks - they will need to add
>>> their own permission checking code.
>> 
>> How do we guard against accidentally forgetting to do this?
> 
> The same way you guard against it when adding a new hypercall: when adding
> new functionality that needs access checks, also add the access checks.

Except that previously the access check was done centrally at the
top of do_domctl(), so newly added sub-functions didn't need to
worry.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 11 08:12:02 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 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 1TBLZU-0007oH-UH; Tue, 11 Sep 2012 08:11:48 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <asadrupucit2006@gmail.com>) id 1TBLZU-0007oA-05
	for xen-devel@lists.xen.org; Tue, 11 Sep 2012 08:11:48 +0000
Received: from [85.158.143.99:5639] by server-1.bemta-4.messagelabs.com id
	CE/4B-12504-342FE405; Tue, 11 Sep 2012 08:11:47 +0000
X-Env-Sender: asadrupucit2006@gmail.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1347351105!28762339!1
X-Originating-IP: [209.85.214.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17737 invoked from network); 11 Sep 2012 08:11:46 -0000
Received: from mail-ob0-f173.google.com (HELO mail-ob0-f173.google.com)
	(209.85.214.173)
	by server-13.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Sep 2012 08:11:46 -0000
Received: by obbta14 with SMTP id ta14so445593obb.32
	for <xen-devel@lists.xen.org>; Tue, 11 Sep 2012 01:11:45 -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=/PXl7ylSCkQQ53FDwjMuCEoT4C0ZMDbWJu0g2dVjeqs=;
	b=Il7Yx0hJkf/m/lueXwpJMPnZGoqUoPyPR+5hl7hnSchQ96rZArPRBgR3h/CY5BYF/4
	qUFMu9/gWfvZpkuZqGo3jN4NHAzuRxxVLwG7Xxr9aljtZ+VUyzHPIot6CqyexAOS8rkj
	AUBCsSlapg770TuBwHh3pAvmoRFgvuUMfDekk7mub3ynEsOuYYxWdJ9/rDTpck4gUmJX
	pWzAghWCRFMX8NjYmfCoZKGze34jbGFmz936c82kuN8NFFoK3raT37PdWVjYJdWf70NN
	LfnS72Qgz6iGl7uJkge6/XzZR/wYTqVDSHbxDfVqA0ivhn+OVM8mA9AbCwZiYIBy/z7e
	2duQ==
MIME-Version: 1.0
Received: by 10.182.78.228 with SMTP id e4mr16932251obx.77.1347351104966; Tue,
	11 Sep 2012 01:11:44 -0700 (PDT)
Received: by 10.60.125.194 with HTTP; Tue, 11 Sep 2012 01:11:44 -0700 (PDT)
Date: Tue, 11 Sep 2012 14:11:44 +0600
Message-ID: <CAJ2v2mjXZFMU0enKjkO7UedCazBte2HZLCs0gqc-TQ2nsJMcDg@mail.gmail.com>
From: asad raza <asadrupucit2006@gmail.com>
To: xen-devel@lists.xen.org
Subject: [Xen-devel] Error : regarding booting of xenified linux kernel
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

hi all,

I have a problem regarding booting of xenified linux kernel,the error
is some thing like this.

Bug:soft lockup CPU#1 stuck for 111's! [swapper:0]
Call Trace:
    [<xxxxxxx>] ? xen_safe_halt
    [<xxxxxxx>]   xen_idle
    [<xxxxxxx>]   cpu_idle

if you have faced this problem and have a solution then plz tell me
regarding this issue that how to solve it.

thanks

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 11 08:12:02 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 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 1TBLZU-0007oH-UH; Tue, 11 Sep 2012 08:11:48 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <asadrupucit2006@gmail.com>) id 1TBLZU-0007oA-05
	for xen-devel@lists.xen.org; Tue, 11 Sep 2012 08:11:48 +0000
Received: from [85.158.143.99:5639] by server-1.bemta-4.messagelabs.com id
	CE/4B-12504-342FE405; Tue, 11 Sep 2012 08:11:47 +0000
X-Env-Sender: asadrupucit2006@gmail.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1347351105!28762339!1
X-Originating-IP: [209.85.214.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17737 invoked from network); 11 Sep 2012 08:11:46 -0000
Received: from mail-ob0-f173.google.com (HELO mail-ob0-f173.google.com)
	(209.85.214.173)
	by server-13.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Sep 2012 08:11:46 -0000
Received: by obbta14 with SMTP id ta14so445593obb.32
	for <xen-devel@lists.xen.org>; Tue, 11 Sep 2012 01:11:45 -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=/PXl7ylSCkQQ53FDwjMuCEoT4C0ZMDbWJu0g2dVjeqs=;
	b=Il7Yx0hJkf/m/lueXwpJMPnZGoqUoPyPR+5hl7hnSchQ96rZArPRBgR3h/CY5BYF/4
	qUFMu9/gWfvZpkuZqGo3jN4NHAzuRxxVLwG7Xxr9aljtZ+VUyzHPIot6CqyexAOS8rkj
	AUBCsSlapg770TuBwHh3pAvmoRFgvuUMfDekk7mub3ynEsOuYYxWdJ9/rDTpck4gUmJX
	pWzAghWCRFMX8NjYmfCoZKGze34jbGFmz936c82kuN8NFFoK3raT37PdWVjYJdWf70NN
	LfnS72Qgz6iGl7uJkge6/XzZR/wYTqVDSHbxDfVqA0ivhn+OVM8mA9AbCwZiYIBy/z7e
	2duQ==
MIME-Version: 1.0
Received: by 10.182.78.228 with SMTP id e4mr16932251obx.77.1347351104966; Tue,
	11 Sep 2012 01:11:44 -0700 (PDT)
Received: by 10.60.125.194 with HTTP; Tue, 11 Sep 2012 01:11:44 -0700 (PDT)
Date: Tue, 11 Sep 2012 14:11:44 +0600
Message-ID: <CAJ2v2mjXZFMU0enKjkO7UedCazBte2HZLCs0gqc-TQ2nsJMcDg@mail.gmail.com>
From: asad raza <asadrupucit2006@gmail.com>
To: xen-devel@lists.xen.org
Subject: [Xen-devel] Error : regarding booting of xenified linux kernel
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

hi all,

I have a problem regarding booting of xenified linux kernel,the error
is some thing like this.

Bug:soft lockup CPU#1 stuck for 111's! [swapper:0]
Call Trace:
    [<xxxxxxx>] ? xen_safe_halt
    [<xxxxxxx>]   xen_idle
    [<xxxxxxx>]   cpu_idle

if you have faced this problem and have a solution then plz tell me
regarding this issue that how to solve it.

thanks

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 11 08:16:33 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 2012 08:16: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 1TBLdq-00081X-QN; Tue, 11 Sep 2012 08:16:18 +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 1TBLdo-00081R-Nq
	for xen-devel@lists.xen.org; Tue, 11 Sep 2012 08:16:16 +0000
Received: from [85.158.139.83:45392] by server-3.bemta-5.messagelabs.com id
	B4/93-21836-053FE405; Tue, 11 Sep 2012 08:16:16 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-13.tower-182.messagelabs.com!1347351374!29231584!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA0OTU1ODE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25002 invoked from network); 11 Sep 2012 08:16:15 -0000
Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25)
	by server-13.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 11 Sep 2012 08:16:15 -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 193871044;
	Tue, 11 Sep 2012 11:16:13 +0300 (EEST)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id A52DD2005D; Tue, 11 Sep 2012 11:16:13 +0300 (EEST)
Date: Tue, 11 Sep 2012 11:16:13 +0300
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: Bei Guan <gbtju85@gmail.com>
Message-ID: <20120911081613.GN8912@reaktio.net>
References: <CAEQjb-TO9wy74up6pGfaRj+FQH8SPJtLXngM70ivWwWaQ53QPA@mail.gmail.com>
	<20120910192456.GA28298@phenom.dumpdata.com>
	<CAEQjb-QG71pnKQsWP1LLhpzXjkJUi+oRjFzLGZZZZSDJqo_BJA@mail.gmail.com>
	<CAG1y0scdfRzY97u7tty61Z2rFSqXzFxdVOw6WLk0MTKAZ+VJpA@mail.gmail.com>
	<CAEQjb-SBXK8x18Jg0e-K9snwSE1VdUjf4CPLprTqYG9xiTDm8w@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAEQjb-SBXK8x18Jg0e-K9snwSE1VdUjf4CPLprTqYG9xiTDm8w@mail.gmail.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: Konrad Rzeszutek Wilk <konrad@kernel.org>,
	xen-devel <xen-devel@lists.xen.org>, "Fajar A. Nugraha" <list@fajar.net>
Subject: Re: [Xen-devel] Any news or plan about Xen support the APU
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Sep 11, 2012 at 03:33:58PM +0800, Bei Guan wrote:
>    2012/9/11 Fajar A. Nugraha <[1]list@fajar.net>
> 
>      On Tue, Sep 11, 2012 at 8:27 AM, Bei Guan <[2]gbtju85@gmail.com> wrote:
>      > Hi Konrad,
>      >
>      > Thank you very much for your reply. I'm not hitting any issues.
>      >
>      > AMD's APU is a new kind of processing device, which integrates a CPU
>      and a
>      > GPU on the same die. I want to know whether Xen has supported the
>      > virtualization of the APU processors? If yes, I can run something
>      > applications in the Xen PV VMs to use this kind of new CPU device.
> 
>      AFAIK at this point AMD APUs are simply CPU + GPU. Even though they're
>      in the same die, they're basically different devices. So for the GPU
>      part, treat it like any other GPU. Which means you could PROBABLY
>      passthru it to ONE domU, but that's it.
> 
>    Hi Fajar,
>    Thank you for your information.
>    Passthrough is a good method for a VM to use the GPU device. However, the
>    GPU is exclusively used by a VM in this way. It cannot be shared among
>    several VMs. I noticed that there are several projects implementing the
>    virtualization of GPU devices on Xen, such as vCUDA (Hunan University, CN,
>    2009) and GViM (Georgia IT). But, is there any plan with Xen support the
>    GPU virtualization in the Xen official code?
>

Take a look at the following projects:

vGallium / Xen3D:
http://www.cl.cam.ac.uk/~cs448/git/trunk/doc/Build-instructions
http://www.phoronix.com/scan.php?page=news_item&px=ODE2NQ

Chromium:
http://chromium.sourceforge.net/doc/index.html

VMGL:
http://sourceforge.net/projects/vmgl/

Spice OpenGL passthrough / Gallium3D:
http://lists.freedesktop.org/archives/spice-devel/2011-November/006018.html
http://www.phoronix.com/scan.php?page=news_item&px=MTA1NTQ

You might want to take a look at getting Spice/Gallium stuff working nicely with Xen. 

(Xen already has spice support in Xen 4.2, and making QXL working is possible when xen-unstable 
switches to using the most recent Qemu upstream branch during the Xen 4.3 development cycle)

Hopefully those links help..

-- Pasi


>    Best Regards,
>    Bei Guan
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 11 08:16:33 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 2012 08:16: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 1TBLdq-00081X-QN; Tue, 11 Sep 2012 08:16:18 +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 1TBLdo-00081R-Nq
	for xen-devel@lists.xen.org; Tue, 11 Sep 2012 08:16:16 +0000
Received: from [85.158.139.83:45392] by server-3.bemta-5.messagelabs.com id
	B4/93-21836-053FE405; Tue, 11 Sep 2012 08:16:16 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-13.tower-182.messagelabs.com!1347351374!29231584!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA0OTU1ODE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25002 invoked from network); 11 Sep 2012 08:16:15 -0000
Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25)
	by server-13.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 11 Sep 2012 08:16:15 -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 193871044;
	Tue, 11 Sep 2012 11:16:13 +0300 (EEST)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id A52DD2005D; Tue, 11 Sep 2012 11:16:13 +0300 (EEST)
Date: Tue, 11 Sep 2012 11:16:13 +0300
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: Bei Guan <gbtju85@gmail.com>
Message-ID: <20120911081613.GN8912@reaktio.net>
References: <CAEQjb-TO9wy74up6pGfaRj+FQH8SPJtLXngM70ivWwWaQ53QPA@mail.gmail.com>
	<20120910192456.GA28298@phenom.dumpdata.com>
	<CAEQjb-QG71pnKQsWP1LLhpzXjkJUi+oRjFzLGZZZZSDJqo_BJA@mail.gmail.com>
	<CAG1y0scdfRzY97u7tty61Z2rFSqXzFxdVOw6WLk0MTKAZ+VJpA@mail.gmail.com>
	<CAEQjb-SBXK8x18Jg0e-K9snwSE1VdUjf4CPLprTqYG9xiTDm8w@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAEQjb-SBXK8x18Jg0e-K9snwSE1VdUjf4CPLprTqYG9xiTDm8w@mail.gmail.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: Konrad Rzeszutek Wilk <konrad@kernel.org>,
	xen-devel <xen-devel@lists.xen.org>, "Fajar A. Nugraha" <list@fajar.net>
Subject: Re: [Xen-devel] Any news or plan about Xen support the APU
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Sep 11, 2012 at 03:33:58PM +0800, Bei Guan wrote:
>    2012/9/11 Fajar A. Nugraha <[1]list@fajar.net>
> 
>      On Tue, Sep 11, 2012 at 8:27 AM, Bei Guan <[2]gbtju85@gmail.com> wrote:
>      > Hi Konrad,
>      >
>      > Thank you very much for your reply. I'm not hitting any issues.
>      >
>      > AMD's APU is a new kind of processing device, which integrates a CPU
>      and a
>      > GPU on the same die. I want to know whether Xen has supported the
>      > virtualization of the APU processors? If yes, I can run something
>      > applications in the Xen PV VMs to use this kind of new CPU device.
> 
>      AFAIK at this point AMD APUs are simply CPU + GPU. Even though they're
>      in the same die, they're basically different devices. So for the GPU
>      part, treat it like any other GPU. Which means you could PROBABLY
>      passthru it to ONE domU, but that's it.
> 
>    Hi Fajar,
>    Thank you for your information.
>    Passthrough is a good method for a VM to use the GPU device. However, the
>    GPU is exclusively used by a VM in this way. It cannot be shared among
>    several VMs. I noticed that there are several projects implementing the
>    virtualization of GPU devices on Xen, such as vCUDA (Hunan University, CN,
>    2009) and GViM (Georgia IT). But, is there any plan with Xen support the
>    GPU virtualization in the Xen official code?
>

Take a look at the following projects:

vGallium / Xen3D:
http://www.cl.cam.ac.uk/~cs448/git/trunk/doc/Build-instructions
http://www.phoronix.com/scan.php?page=news_item&px=ODE2NQ

Chromium:
http://chromium.sourceforge.net/doc/index.html

VMGL:
http://sourceforge.net/projects/vmgl/

Spice OpenGL passthrough / Gallium3D:
http://lists.freedesktop.org/archives/spice-devel/2011-November/006018.html
http://www.phoronix.com/scan.php?page=news_item&px=MTA1NTQ

You might want to take a look at getting Spice/Gallium stuff working nicely with Xen. 

(Xen already has spice support in Xen 4.2, and making QXL working is possible when xen-unstable 
switches to using the most recent Qemu upstream branch during the Xen 4.3 development cycle)

Hopefully those links help..

-- Pasi


>    Best Regards,
>    Bei Guan
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 11 08:27:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 2012 08:27:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TBLoA-0008KH-Ke; Tue, 11 Sep 2012 08:26:58 +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 1TBLo9-0008Jc-1y
	for xen-devel@lists.xen.org; Tue, 11 Sep 2012 08:26:57 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1347352010!3499867!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM5NTk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8500 invoked from network); 11 Sep 2012 08:26:50 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-14.tower-27.messagelabs.com with SMTP;
	11 Sep 2012 08:26:50 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 11 Sep 2012 09:26:49 +0100
Message-Id: <504F11E6020000780009A73E@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 11 Sep 2012 09:26:46 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "bunkertor" <bunkertor@tiscali.it>
References: <504E10DA.6040603@tiscali.it>
In-Reply-To: <504E10DA.6040603@tiscali.it>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] grub error 28
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.09.12 at 18:10, bunkertor <bunkertor@tiscali.it> wrote:
> i compiled by myself xen-unstable from hg repo (changeset:   
> 25835:c70d70d85306)
> but i'm facing a problem when i try to boot with xen kernel: Error 28 
> Selected item can not fit into memory.
> i'm newbie and i cannot understand where i fail...

Did you ever successfully run Xen on that system?

>      GNU GRUB  version 0.97  (640K lower / 3072K upper memory)

Is the very small upper memory value perhaps causing your
problem (i.e. are you dealing with a GrUB issue rather than a
Xen one)? Admittedly I don't know what values GrUB would
display normally, but the E820 map you presented looks
quite unusual, so I wouldn't be surprised if that caused
problems.

>   [ Minimal BASH-like line editing is supported.  For the first word, TAB
>     lists possible command completions.  Anywhere else TAB lists the 
> possible
>     completions of a device/filename.]
> grub> root (hd0,0)
> root (hd0,0)
>   Filesystem type is ext2fs, partition type 0x83
> grub> kernel /xen.gz
> kernel /xen.gz
>     [Multiboot-elf, <0x964000:0x1a6db8:0x54248>(bad)
> 
> Error 28: Selected item cannot fit into memory

>From this, it pretty clearly is the (relatively small) hypervisor
image itself.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 11 08:27:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 2012 08:27:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TBLoA-0008KH-Ke; Tue, 11 Sep 2012 08:26:58 +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 1TBLo9-0008Jc-1y
	for xen-devel@lists.xen.org; Tue, 11 Sep 2012 08:26:57 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1347352010!3499867!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM5NTk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8500 invoked from network); 11 Sep 2012 08:26:50 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-14.tower-27.messagelabs.com with SMTP;
	11 Sep 2012 08:26:50 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 11 Sep 2012 09:26:49 +0100
Message-Id: <504F11E6020000780009A73E@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 11 Sep 2012 09:26:46 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "bunkertor" <bunkertor@tiscali.it>
References: <504E10DA.6040603@tiscali.it>
In-Reply-To: <504E10DA.6040603@tiscali.it>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] grub error 28
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.09.12 at 18:10, bunkertor <bunkertor@tiscali.it> wrote:
> i compiled by myself xen-unstable from hg repo (changeset:   
> 25835:c70d70d85306)
> but i'm facing a problem when i try to boot with xen kernel: Error 28 
> Selected item can not fit into memory.
> i'm newbie and i cannot understand where i fail...

Did you ever successfully run Xen on that system?

>      GNU GRUB  version 0.97  (640K lower / 3072K upper memory)

Is the very small upper memory value perhaps causing your
problem (i.e. are you dealing with a GrUB issue rather than a
Xen one)? Admittedly I don't know what values GrUB would
display normally, but the E820 map you presented looks
quite unusual, so I wouldn't be surprised if that caused
problems.

>   [ Minimal BASH-like line editing is supported.  For the first word, TAB
>     lists possible command completions.  Anywhere else TAB lists the 
> possible
>     completions of a device/filename.]
> grub> root (hd0,0)
> root (hd0,0)
>   Filesystem type is ext2fs, partition type 0x83
> grub> kernel /xen.gz
> kernel /xen.gz
>     [Multiboot-elf, <0x964000:0x1a6db8:0x54248>(bad)
> 
> Error 28: Selected item cannot fit into memory

>From this, it pretty clearly is the (relatively small) hypervisor
image itself.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 11 08:31:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 2012 08:31:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TBLs4-00007R-AH; Tue, 11 Sep 2012 08:31:00 +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 1TBLs3-00007M-D0
	for xen-devel@lists.xen.org; Tue, 11 Sep 2012 08:30:59 +0000
Received: from [85.158.138.51:3344] by server-12.bemta-3.messagelabs.com id
	23/6F-10384-2C6FE405; Tue, 11 Sep 2012 08:30:58 +0000
X-Env-Sender: ben.guthro@gmail.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1347352256!29753670!1
X-Originating-IP: [209.85.212.45]
X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_50_60,HTML_MESSAGE,
	RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12105 invoked from network); 11 Sep 2012 08:30:57 -0000
Received: from mail-vb0-f45.google.com (HELO mail-vb0-f45.google.com)
	(209.85.212.45)
	by server-16.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Sep 2012 08:30:57 -0000
Received: by vbip1 with SMTP id p1so366525vbi.32
	for <xen-devel@lists.xen.org>; Tue, 11 Sep 2012 01:30: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;
	bh=rjhUeu59PMPbw1AcxLaI+qlq813o4XR0oOLX+RPemCs=;
	b=YBoa/ig5/eWwzOs6jm4N7vV0b2v5WE0kyu/sfw4z+S0FgBylUyF4BpbNKXmr/HUHs3
	Pwt/Q20uCGBmHQuD3YeC1pq92hPTdLyb2Vabf5JmvCmZTqVbFYssKQiKvLjpYvmWAhY8
	KMzjDUoxz/gFD60dLLvfsJNIe+fx1RReG0MrczLW1MPX+djmeg8vCRkxvBU+KWb9uhiV
	ZyKE1gUPkXxK7U1mNLUrAIXjPAcgpe7Jdmhs1h7Z2dny58OOP742S5XxsPMe32Qylsib
	whpvkroohrweubfeXPZzKl9C938W5xECRYwYHxlsENF4moPPppMVSwZUbHsdQCTUud8D
	PvDA==
MIME-Version: 1.0
Received: by 10.52.24.201 with SMTP id w9mr19135872vdf.125.1347352256564; Tue,
	11 Sep 2012 01:30:56 -0700 (PDT)
Received: by 10.58.28.180 with HTTP; Tue, 11 Sep 2012 01:30:56 -0700 (PDT)
In-Reply-To: <CAJJyHjJe3fV8LzKNqJVW58Ngk3HGE+GA0rOGA7zU-tzTX0rNtQ@mail.gmail.com>
References: <502E212E.6070306@citrix.com>
	<CAOvdn6WD31pQVbZNSMc8JTKfNQKOEWUkHpvpqPq=kcAUBC5QHQ@mail.gmail.com>
	<CAJJyHjJe3fV8LzKNqJVW58Ngk3HGE+GA0rOGA7zU-tzTX0rNtQ@mail.gmail.com>
Date: Tue, 11 Sep 2012 04:30:56 -0400
X-Google-Sender-Auth: -wuJtD7LAmNDMHBrFRYZH4njM_c
Message-ID: <CAOvdn6XrvxvHr7GGsk02YZcN6EO5hpYuPuBVqv5VUtPGjB-82g@mail.gmail.com>
From: Ben Guthro <ben@guthro.net>
To: Anthony PERARD <anthony.perard@citrix.com>
Cc: Xen Devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [ANNOUNCE] Git mirror of Xen repositories available
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============6221567372740778770=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============6221567372740778770==
Content-Type: multipart/alternative; boundary=bcaec5016207a3ce0704c968e473

--bcaec5016207a3ce0704c968e473
Content-Type: text/plain; charset=ISO-8859-1

I don't see them after doing a "git fetch --all" - and they don't appear to
be visible via gitweb here:
http://xenbits.xen.org/gitweb/?p=xen.git;a=summary
nor here:
http://xenbits.xen.org/gitweb/?p=people/aperard/xen.git;a=summary

Is it possible you forgot to push something?

Thanks

Ben

On Mon, Sep 10, 2012 at 9:16 AM, Anthony PERARD
<anthony.perard@citrix.com>wrote:

> On Sat, Sep 8, 2012 at 1:23 PM, Ben Guthro <ben@guthro.net> wrote:
> > Will this git mirror pick up a stable-4.2 branch, now that the
> > xen-4.2-testing.hg branch has been forked off?
>
> Yes, it will ! And it does now. There is two new branches,
> "stable-4.2" and "staging-4.2".
>
> Regards,
>
> --
> Anthony PERARD
>

--bcaec5016207a3ce0704c968e473
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

I don&#39;t see them after doing a &quot;git fetch --all&quot; - and they d=
on&#39;t appear to be visible via gitweb here:<div><a href=3D"http://xenbit=
s.xen.org/gitweb/?p=3Dxen.git;a=3Dsummary">http://xenbits.xen.org/gitweb/?p=
=3Dxen.git;a=3Dsummary</a><div>
nor here:</div><div><a href=3D"http://xenbits.xen.org/gitweb/?p=3Dpeople/ap=
erard/xen.git;a=3Dsummary">http://xenbits.xen.org/gitweb/?p=3Dpeople/aperar=
d/xen.git;a=3Dsummary</a></div><div><br><div>Is it possible you forgot to p=
ush something?</div>
<div><br></div><div>Thanks</div><div><br></div><div>Ben</div><div><br><div =
class=3D"gmail_quote">On Mon, Sep 10, 2012 at 9:16 AM, Anthony PERARD <span=
 dir=3D"ltr">&lt;<a href=3D"mailto:anthony.perard@citrix.com" target=3D"_bl=
ank">anthony.perard@citrix.com</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div class=3D"im">On Sat, Sep 8, 2012 at 1:2=
3 PM, Ben Guthro &lt;<a href=3D"mailto:ben@guthro.net">ben@guthro.net</a>&g=
t; wrote:<br>

&gt; Will this git mirror pick up a stable-4.2 branch, now that the<br>
&gt; xen-4.2-testing.hg branch has been forked off?<br>
<br>
</div>Yes, it will ! And it does now. There is two new branches,<br>
&quot;stable-4.2&quot; and &quot;staging-4.2&quot;.<br>
<br>
Regards,<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
--<br>
Anthony PERARD<br>
</font></span></blockquote></div><br></div></div></div>

--bcaec5016207a3ce0704c968e473--


--===============6221567372740778770==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============6221567372740778770==--


From xen-devel-bounces@lists.xen.org Tue Sep 11 08:31:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 2012 08:31:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TBLs4-00007R-AH; Tue, 11 Sep 2012 08:31:00 +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 1TBLs3-00007M-D0
	for xen-devel@lists.xen.org; Tue, 11 Sep 2012 08:30:59 +0000
Received: from [85.158.138.51:3344] by server-12.bemta-3.messagelabs.com id
	23/6F-10384-2C6FE405; Tue, 11 Sep 2012 08:30:58 +0000
X-Env-Sender: ben.guthro@gmail.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1347352256!29753670!1
X-Originating-IP: [209.85.212.45]
X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_50_60,HTML_MESSAGE,
	RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12105 invoked from network); 11 Sep 2012 08:30:57 -0000
Received: from mail-vb0-f45.google.com (HELO mail-vb0-f45.google.com)
	(209.85.212.45)
	by server-16.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Sep 2012 08:30:57 -0000
Received: by vbip1 with SMTP id p1so366525vbi.32
	for <xen-devel@lists.xen.org>; Tue, 11 Sep 2012 01:30: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;
	bh=rjhUeu59PMPbw1AcxLaI+qlq813o4XR0oOLX+RPemCs=;
	b=YBoa/ig5/eWwzOs6jm4N7vV0b2v5WE0kyu/sfw4z+S0FgBylUyF4BpbNKXmr/HUHs3
	Pwt/Q20uCGBmHQuD3YeC1pq92hPTdLyb2Vabf5JmvCmZTqVbFYssKQiKvLjpYvmWAhY8
	KMzjDUoxz/gFD60dLLvfsJNIe+fx1RReG0MrczLW1MPX+djmeg8vCRkxvBU+KWb9uhiV
	ZyKE1gUPkXxK7U1mNLUrAIXjPAcgpe7Jdmhs1h7Z2dny58OOP742S5XxsPMe32Qylsib
	whpvkroohrweubfeXPZzKl9C938W5xECRYwYHxlsENF4moPPppMVSwZUbHsdQCTUud8D
	PvDA==
MIME-Version: 1.0
Received: by 10.52.24.201 with SMTP id w9mr19135872vdf.125.1347352256564; Tue,
	11 Sep 2012 01:30:56 -0700 (PDT)
Received: by 10.58.28.180 with HTTP; Tue, 11 Sep 2012 01:30:56 -0700 (PDT)
In-Reply-To: <CAJJyHjJe3fV8LzKNqJVW58Ngk3HGE+GA0rOGA7zU-tzTX0rNtQ@mail.gmail.com>
References: <502E212E.6070306@citrix.com>
	<CAOvdn6WD31pQVbZNSMc8JTKfNQKOEWUkHpvpqPq=kcAUBC5QHQ@mail.gmail.com>
	<CAJJyHjJe3fV8LzKNqJVW58Ngk3HGE+GA0rOGA7zU-tzTX0rNtQ@mail.gmail.com>
Date: Tue, 11 Sep 2012 04:30:56 -0400
X-Google-Sender-Auth: -wuJtD7LAmNDMHBrFRYZH4njM_c
Message-ID: <CAOvdn6XrvxvHr7GGsk02YZcN6EO5hpYuPuBVqv5VUtPGjB-82g@mail.gmail.com>
From: Ben Guthro <ben@guthro.net>
To: Anthony PERARD <anthony.perard@citrix.com>
Cc: Xen Devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [ANNOUNCE] Git mirror of Xen repositories available
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============6221567372740778770=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============6221567372740778770==
Content-Type: multipart/alternative; boundary=bcaec5016207a3ce0704c968e473

--bcaec5016207a3ce0704c968e473
Content-Type: text/plain; charset=ISO-8859-1

I don't see them after doing a "git fetch --all" - and they don't appear to
be visible via gitweb here:
http://xenbits.xen.org/gitweb/?p=xen.git;a=summary
nor here:
http://xenbits.xen.org/gitweb/?p=people/aperard/xen.git;a=summary

Is it possible you forgot to push something?

Thanks

Ben

On Mon, Sep 10, 2012 at 9:16 AM, Anthony PERARD
<anthony.perard@citrix.com>wrote:

> On Sat, Sep 8, 2012 at 1:23 PM, Ben Guthro <ben@guthro.net> wrote:
> > Will this git mirror pick up a stable-4.2 branch, now that the
> > xen-4.2-testing.hg branch has been forked off?
>
> Yes, it will ! And it does now. There is two new branches,
> "stable-4.2" and "staging-4.2".
>
> Regards,
>
> --
> Anthony PERARD
>

--bcaec5016207a3ce0704c968e473
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

I don&#39;t see them after doing a &quot;git fetch --all&quot; - and they d=
on&#39;t appear to be visible via gitweb here:<div><a href=3D"http://xenbit=
s.xen.org/gitweb/?p=3Dxen.git;a=3Dsummary">http://xenbits.xen.org/gitweb/?p=
=3Dxen.git;a=3Dsummary</a><div>
nor here:</div><div><a href=3D"http://xenbits.xen.org/gitweb/?p=3Dpeople/ap=
erard/xen.git;a=3Dsummary">http://xenbits.xen.org/gitweb/?p=3Dpeople/aperar=
d/xen.git;a=3Dsummary</a></div><div><br><div>Is it possible you forgot to p=
ush something?</div>
<div><br></div><div>Thanks</div><div><br></div><div>Ben</div><div><br><div =
class=3D"gmail_quote">On Mon, Sep 10, 2012 at 9:16 AM, Anthony PERARD <span=
 dir=3D"ltr">&lt;<a href=3D"mailto:anthony.perard@citrix.com" target=3D"_bl=
ank">anthony.perard@citrix.com</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div class=3D"im">On Sat, Sep 8, 2012 at 1:2=
3 PM, Ben Guthro &lt;<a href=3D"mailto:ben@guthro.net">ben@guthro.net</a>&g=
t; wrote:<br>

&gt; Will this git mirror pick up a stable-4.2 branch, now that the<br>
&gt; xen-4.2-testing.hg branch has been forked off?<br>
<br>
</div>Yes, it will ! And it does now. There is two new branches,<br>
&quot;stable-4.2&quot; and &quot;staging-4.2&quot;.<br>
<br>
Regards,<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
--<br>
Anthony PERARD<br>
</font></span></blockquote></div><br></div></div></div>

--bcaec5016207a3ce0704c968e473--


--===============6221567372740778770==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============6221567372740778770==--


From xen-devel-bounces@lists.xen.org Tue Sep 11 08:38:16 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 2012 08:38:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TBLyr-0000Sw-5x; Tue, 11 Sep 2012 08:38:01 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1TBLyp-0000Sr-V0
	for xen-devel@lists.xen.org; Tue, 11 Sep 2012 08:38:00 +0000
Received: from [85.158.143.35:58971] by server-3.bemta-4.messagelabs.com id
	41/46-08232-768FE405; Tue, 11 Sep 2012 08:37:59 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1347352566!15185031!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQwNzc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17425 invoked from network); 11 Sep 2012 08:36:15 -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;
	11 Sep 2012 08:36:15 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 11 Sep 2012 09:36:05 +0100
Message-Id: <504F1412020000780009A750@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 11 Sep 2012 09:36:02 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: <dan.magenheimer@oracle.com>, "Zhenzhong Duan" <zhenzhong.duan@oracle.com>
References: <504764270200007800098DE1@nat28.tlf.novell.com>
	<504A01790200007800099C52@nat28.tlf.novell.com>
In-Reply-To: <504A01790200007800099C52@nat28.tlf.novell.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Ian Campbell <ian.campbell@citrix.com>, xen-devel <xen-devel@lists.xen.org>
Subject: [Xen-devel] Ping: [PATCH 09/11,
	v2] tmem: reduce severity of log messages
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

I was hoping to get this series (and the supposedly trivial tools
side fix for save/restore) into the tree, but this patch is lacking
an ack...

Jan

>>> On 07.09.12 at 14:15, "Jan Beulich" <JBeulich@suse.com> wrote:
> Otherwise they can be used by a guest to spam the hypervisor log when
> all settings are at their defaults.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> ---
> v2: As suggested by Ian, use separate abstraction for messages printed
>     in result of client side operations (so that e.g. the init time
>     system messages don't also get converted to guest level ones).
> 
> --- a/xen/common/tmem.c
> +++ b/xen/common/tmem.c
> @@ -1107,7 +1107,7 @@ static int shared_pool_join(pool_t *pool
>      sl->client = new_client;
>      list_add_tail(&sl->share_list, &pool->share_list);
>      if ( new_client->cli_id != pool->client->cli_id )
> -        printk("adding new %s %d to shared pool owned by %s %d\n",
> +        tmh_client_info("adding new %s %d to shared pool owned by %s %d\n",
>              client_str, new_client->cli_id, client_str, pool->client->cli_id);
>      return ++pool->shared_count;
>  }
> @@ -1137,7 +1137,7 @@ static NOINLINE void shared_pool_reassig
>      old_client->eph_count -= _atomic_read(pool->pgp_count);
>      list_splice_init(&old_client->ephemeral_page_list,
>                       &new_client->ephemeral_page_list);
> -    printk("reassigned shared pool from %s=%d to %s=%d pool_id=%d\n",
> +    tmh_client_info("reassigned shared pool from %s=%d to %s=%d 
> pool_id=%d\n",
>          cli_id_str, old_client->cli_id, cli_id_str, new_client->cli_id, 
> poolid);
>      pool->pool_id = poolid;
>  }
> @@ -1173,7 +1173,7 @@ static NOINLINE int shared_pool_quit(poo
>              }
>          return 0;
>      }
> -    printk("tmem: no match unsharing pool, %s=%d\n",
> +    tmh_client_warn("tmem: no match unsharing pool, %s=%d\n",
>          cli_id_str,pool->client->cli_id);
>      return -1;
>  }
> @@ -1184,17 +1184,18 @@ static void pool_flush(pool_t *pool, cli
>      ASSERT(pool != NULL);
>      if ( (is_shared(pool)) && (shared_pool_quit(pool,cli_id) > 0) )
>      {
> -        printk("tmem: %s=%d no longer using shared pool %d owned by 
> %s=%d\n",
> +        tmh_client_warn("tmem: %s=%d no longer using shared pool %d owned 
> by %s=%d\n",
>             cli_id_str, cli_id, pool->pool_id, cli_id_str,pool->client->cli_id);
>          return;
>      }
> -    printk("%s %s-%s tmem pool ",destroy?"destroying":"flushing",
> -        is_persistent(pool) ? "persistent" : "ephemeral" ,
> -        is_shared(pool) ? "shared" : "private");
> -    printk("%s=%d pool_id=%d\n", cli_id_str,pool->client->cli_id,pool->pool_id);
> +    tmh_client_info("%s %s-%s tmem pool %s=%d pool_id=%d\n",
> +                    destroy ? "destroying" : "flushing",
> +                    is_persistent(pool) ? "persistent" : "ephemeral" ,
> +                    is_shared(pool) ? "shared" : "private",
> +                    cli_id_str, pool->client->cli_id, pool->pool_id);
>      if ( pool->client->live_migrating )
>      {
> -        printk("can't %s pool while %s is live-migrating\n",
> +        tmh_client_warn("can't %s pool while %s is live-migrating\n",
>                 destroy?"destroy":"flush", client_str);
>          return;
>      }
> @@ -1213,21 +1214,22 @@ static client_t *client_create(cli_id_t 
>      client_t *client = 
> tmh_alloc_infra(sizeof(client_t),__alignof__(client_t));
>      int i;
>  
> -    printk("tmem: initializing tmem capability for 
> %s=%d...",cli_id_str,cli_id);
> +    tmh_client_info("tmem: initializing tmem capability for %s=%d...",
> +                    cli_id_str, cli_id);
>      if ( client == NULL )
>      {
> -        printk("failed... out of memory\n");
> +        tmh_client_err("failed... out of memory\n");
>          goto fail;
>      }
>      memset(client,0,sizeof(client_t));
>      if ( (client->tmh = tmh_client_init(cli_id)) == NULL )
>      {
> -        printk("failed... can't allocate host-dependent part of client\n");
> +        tmh_client_err("failed... can't allocate host-dependent part of 
> client\n");
>          goto fail;
>      }
>      if ( !tmh_set_client_from_id(client, client->tmh, cli_id) )
>      {
> -        printk("failed... can't set client\n");
> +        tmh_client_err("failed... can't set client\n");
>          goto fail;
>      }
>      client->cli_id = cli_id;
> @@ -1249,7 +1251,7 @@ static client_t *client_create(cli_id_t 
>      client->eph_count = client->eph_count_max = 0;
>      client->total_cycles = 0; client->succ_pers_puts = 0;
>      client->succ_eph_gets = 0; client->succ_pers_gets = 0;
> -    printk("ok\n");
> +    tmh_client_info("ok\n");
>      return client;
>  
>   fail:
> @@ -1903,32 +1905,33 @@ static NOINLINE int do_tmem_new_pool(cli
>          cli_id = tmh_get_cli_id_from_current();
>      else
>          cli_id = this_cli_id;
> -    printk("tmem: allocating %s-%s tmem pool for %s=%d...",
> +    tmh_client_info("tmem: allocating %s-%s tmem pool for %s=%d...",
>          persistent ? "persistent" : "ephemeral" ,
>          shared ? "shared" : "private", cli_id_str, cli_id);
>      if ( specversion != TMEM_SPEC_VERSION )
>      {
> -        printk("failed... unsupported spec version\n");
> +        tmh_client_err("failed... unsupported spec version\n");
>          return -EPERM;
>      }
>      if ( pagebits != (PAGE_SHIFT - 12) )
>      {
> -        printk("failed... unsupported pagesize %d\n",1<<(pagebits+12));
> +        tmh_client_err("failed... unsupported pagesize %d\n",
> +                       1 << (pagebits + 12));
>          return -EPERM;
>      }
>      if ( flags & TMEM_POOL_PRECOMPRESSED )
>      {
> -        printk("failed... precompression flag set but unsupported\n");
> +        tmh_client_err("failed... precompression flag set but 
> unsupported\n");
>          return -EPERM;
>      }
>      if ( flags & TMEM_POOL_RESERVED_BITS )
>      {
> -        printk("failed... reserved bits must be zero\n");
> +        tmh_client_err("failed... reserved bits must be zero\n");
>          return -EPERM;
>      }
>      if ( (pool = pool_alloc()) == NULL )
>      {
> -        printk("failed... out of memory\n");
> +        tmh_client_err("failed... out of memory\n");
>          return -ENOMEM;
>      }
>      if ( this_cli_id != CLI_ID_NULL )
> @@ -1947,7 +1950,7 @@ static NOINLINE int do_tmem_new_pool(cli
>                  break;
>          if ( d_poolid >= MAX_POOLS_PER_DOMAIN )
>          {
> -            printk("failed... no more pool slots available for this %s\n",
> +            tmh_client_err("failed... no more pool slots available for this 
> %s\n",
>                     client_str);
>              goto fail;
>          }
> @@ -1977,9 +1980,8 @@ static NOINLINE int do_tmem_new_pool(cli
>              {
>                  if ( shpool->uuid[0] == uuid_lo && shpool->uuid[1] == uuid_hi )
>                  {
> -                    printk("(matches shared pool uuid=%"PRIx64".%"PRIx64") 
> ",
> -                        uuid_hi, uuid_lo);
> -                    printk("pool_id=%d\n",d_poolid);
> +                    tmh_client_info("(matches shared pool 
> uuid=%"PRIx64".%"PRIx64") pool_id=%d\n",
> +                        uuid_hi, uuid_lo, d_poolid);
>                      client->pools[d_poolid] = global_shared_pools[s_poolid];
>                      shared_pool_join(global_shared_pools[s_poolid], 
> client);
>                      pool_free(pool);
> @@ -1991,7 +1993,7 @@ static NOINLINE int do_tmem_new_pool(cli
>          }
>          if ( first_unused_s_poolid == MAX_GLOBAL_SHARED_POOLS )
>          {
> -            printk("tmem: failed... no global shared pool slots 
> available\n");
> +            tmh_client_warn("tmem: failed... no global shared pool slots 
> available\n");
>              goto fail;
>          }
>          else
> @@ -2007,7 +2009,7 @@ static NOINLINE int do_tmem_new_pool(cli
>      pool->pool_id = d_poolid;
>      pool->persistent = persistent;
>      pool->uuid[0] = uuid_lo; pool->uuid[1] = uuid_hi;
> -    printk("pool_id=%d\n",d_poolid);
> +    tmh_client_info("pool_id=%d\n", d_poolid);
>      return d_poolid;
>  
>  fail:
> @@ -2030,14 +2032,15 @@ static int tmemc_freeze_pools(cli_id_t c
>      {
>          list_for_each_entry(client,&global_client_list,client_list)
>              client_freeze(client,freeze);
> -        printk("tmem: all pools %s for all %ss\n",s,client_str);
> +        tmh_client_info("tmem: all pools %s for all %ss\n", s, client_str);
>      }
>      else
>      {
>          if ( (client = tmh_client_from_cli_id(cli_id)) == NULL)
>              return -1;
>          client_freeze(client,freeze);
> -        printk("tmem: all pools %s for %s=%d\n",s,cli_id_str,cli_id);
> +        tmh_client_info("tmem: all pools %s for %s=%d\n",
> +                         s, cli_id_str, cli_id);
>      }
>      return 0;
>  }
> @@ -2048,7 +2051,7 @@ static int tmemc_flush_mem(cli_id_t cli_
>  
>      if ( cli_id != CLI_ID_NULL )
>      {
> -        printk("tmem: %s-specific flush not supported yet, use --all\n",
> +        tmh_client_warn("tmem: %s-specific flush not supported yet, use 
> --all\n",
>             client_str);
>          return -1;
>      }
> @@ -2261,13 +2264,15 @@ static int tmemc_set_var_one(client_t *c
>      case TMEMC_SET_WEIGHT:
>          old_weight = client->weight;
>          client->weight = arg1;
> -        printk("tmem: weight set to %d for %s=%d\n",arg1,cli_id_str,cli_id);
> +        tmh_client_info("tmem: weight set to %d for %s=%d\n",
> +                        arg1, cli_id_str, cli_id);
>          atomic_sub(old_weight,&client_weight_total);
>          atomic_add(client->weight,&client_weight_total);
>          break;
>      case TMEMC_SET_CAP:
>          client->cap = arg1;
> -        printk("tmem: cap set to %d for %s=%d\n",arg1,cli_id_str,cli_id);
> +        tmh_client_info("tmem: cap set to %d for %s=%d\n",
> +                        arg1, cli_id_str, cli_id);
>          break;
>      case TMEMC_SET_COMPRESS:
>  #ifdef __i386__
> @@ -2275,17 +2280,17 @@ static int tmemc_set_var_one(client_t *c
>  #endif
>          if ( tmh_dedup_enabled() )
>          {
> -            printk("tmem: compression %s for all %ss, cannot be changed "
> -                   "when tmem_dedup is enabled\n",
> -            tmh_compression_enabled() ? "enabled" : "disabled",client_str);
> +            tmh_client_warn("tmem: compression %s for all %ss, cannot be 
> changed when tmem_dedup is enabled\n",
> +                            tmh_compression_enabled() ? "enabled" : 
> "disabled",
> +                            client_str);
>              return -1;
>          }
>          client->compress = arg1 ? 1 : 0;
> -        printk("tmem: compression %s for %s=%d\n",
> +        tmh_client_info("tmem: compression %s for %s=%d\n",
>              arg1 ? "enabled" : "disabled",cli_id_str,cli_id);
>          break;
>      default:
> -        printk("tmem: unknown subop %d for tmemc_set_var\n",subop);
> +        tmh_client_warn("tmem: unknown subop %d for tmemc_set_var\n", 
> subop);
>          return -1;
>      }
>      return 0;
> @@ -2668,7 +2673,7 @@ EXPORT long do_tmem_op(tmem_cli_op_t uop
>  
>      if ( unlikely(tmh_get_tmemop_from_client(&op, uops) != 0) )
>      {
> -        printk("tmem: can't get tmem struct from %s\n",client_str);
> +        tmh_client_err("tmem: can't get tmem struct from %s\n", 
> client_str);
>          rc = -EFAULT;
>          if ( !tmh_lock_all )
>              goto simple_error;
> @@ -2702,7 +2707,8 @@ EXPORT long do_tmem_op(tmem_cli_op_t uop
>          tmem_write_lock_set = 1;
>          if ( (client = client_create(tmh_get_cli_id_from_current())) == 
> NULL )
>          {
> -            printk("tmem: can't create tmem structure for %s\n",client_str);
> +            tmh_client_err("tmem: can't create tmem structure for %s\n",
> +                           client_str);
>              rc = -ENOMEM;
>              goto out;
>          }
> @@ -2726,8 +2732,8 @@ EXPORT long do_tmem_op(tmem_cli_op_t uop
>          if ( ((uint32_t)op.pool_id >= MAX_POOLS_PER_DOMAIN) ||
>               ((pool = client->pools[op.pool_id]) == NULL) )
>          {
> +            tmh_client_err("tmem: operation requested on uncreated 
> pool\n");
>              rc = -ENODEV;
> -            printk("tmem: operation requested on uncreated pool\n");
>              goto out;
>          }
>          ASSERT_SENTINEL(pool,POOL);
> @@ -2783,11 +2789,11 @@ EXPORT long do_tmem_op(tmem_cli_op_t uop
>          break;
>      case TMEM_XCHG:
>          /* need to hold global lock to ensure xchg is atomic */
> -        printk("tmem_xchg op not implemented yet\n");
> +        tmh_client_warn("tmem_xchg op not implemented yet\n");
>          rc = 0;
>          break;
>      default:
> -        printk("tmem: op %d not implemented\n", op.cmd);
> +        tmh_client_warn("tmem: op %d not implemented\n", op.cmd);
>          rc = 0;
>          break;
>      }
> --- a/xen/include/xen/tmem_xen.h
> +++ b/xen/include/xen/tmem_xen.h
> @@ -512,6 +512,9 @@ int tmh_copy_to_client(tmem_cli_mfn_t, p
>  
>  extern int tmh_copy_tze_to_client(tmem_cli_mfn_t cmfn, void *tmem_va, 
> pagesize_t len);
>  
> +#define tmh_client_err(fmt, args...)  printk(XENLOG_G_ERR fmt, ##args)
> +#define tmh_client_warn(fmt, args...) printk(XENLOG_G_WARNING fmt, ##args)
> +#define tmh_client_info(fmt, args...) printk(XENLOG_G_INFO fmt, ##args)
>  
>  #define TMEM_PERF
>  #ifdef TMEM_PERF



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 11 08:38:16 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 2012 08:38:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TBLyr-0000Sw-5x; Tue, 11 Sep 2012 08:38:01 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1TBLyp-0000Sr-V0
	for xen-devel@lists.xen.org; Tue, 11 Sep 2012 08:38:00 +0000
Received: from [85.158.143.35:58971] by server-3.bemta-4.messagelabs.com id
	41/46-08232-768FE405; Tue, 11 Sep 2012 08:37:59 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1347352566!15185031!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQwNzc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17425 invoked from network); 11 Sep 2012 08:36:15 -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;
	11 Sep 2012 08:36:15 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 11 Sep 2012 09:36:05 +0100
Message-Id: <504F1412020000780009A750@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 11 Sep 2012 09:36:02 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: <dan.magenheimer@oracle.com>, "Zhenzhong Duan" <zhenzhong.duan@oracle.com>
References: <504764270200007800098DE1@nat28.tlf.novell.com>
	<504A01790200007800099C52@nat28.tlf.novell.com>
In-Reply-To: <504A01790200007800099C52@nat28.tlf.novell.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Ian Campbell <ian.campbell@citrix.com>, xen-devel <xen-devel@lists.xen.org>
Subject: [Xen-devel] Ping: [PATCH 09/11,
	v2] tmem: reduce severity of log messages
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

I was hoping to get this series (and the supposedly trivial tools
side fix for save/restore) into the tree, but this patch is lacking
an ack...

Jan

>>> On 07.09.12 at 14:15, "Jan Beulich" <JBeulich@suse.com> wrote:
> Otherwise they can be used by a guest to spam the hypervisor log when
> all settings are at their defaults.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> ---
> v2: As suggested by Ian, use separate abstraction for messages printed
>     in result of client side operations (so that e.g. the init time
>     system messages don't also get converted to guest level ones).
> 
> --- a/xen/common/tmem.c
> +++ b/xen/common/tmem.c
> @@ -1107,7 +1107,7 @@ static int shared_pool_join(pool_t *pool
>      sl->client = new_client;
>      list_add_tail(&sl->share_list, &pool->share_list);
>      if ( new_client->cli_id != pool->client->cli_id )
> -        printk("adding new %s %d to shared pool owned by %s %d\n",
> +        tmh_client_info("adding new %s %d to shared pool owned by %s %d\n",
>              client_str, new_client->cli_id, client_str, pool->client->cli_id);
>      return ++pool->shared_count;
>  }
> @@ -1137,7 +1137,7 @@ static NOINLINE void shared_pool_reassig
>      old_client->eph_count -= _atomic_read(pool->pgp_count);
>      list_splice_init(&old_client->ephemeral_page_list,
>                       &new_client->ephemeral_page_list);
> -    printk("reassigned shared pool from %s=%d to %s=%d pool_id=%d\n",
> +    tmh_client_info("reassigned shared pool from %s=%d to %s=%d 
> pool_id=%d\n",
>          cli_id_str, old_client->cli_id, cli_id_str, new_client->cli_id, 
> poolid);
>      pool->pool_id = poolid;
>  }
> @@ -1173,7 +1173,7 @@ static NOINLINE int shared_pool_quit(poo
>              }
>          return 0;
>      }
> -    printk("tmem: no match unsharing pool, %s=%d\n",
> +    tmh_client_warn("tmem: no match unsharing pool, %s=%d\n",
>          cli_id_str,pool->client->cli_id);
>      return -1;
>  }
> @@ -1184,17 +1184,18 @@ static void pool_flush(pool_t *pool, cli
>      ASSERT(pool != NULL);
>      if ( (is_shared(pool)) && (shared_pool_quit(pool,cli_id) > 0) )
>      {
> -        printk("tmem: %s=%d no longer using shared pool %d owned by 
> %s=%d\n",
> +        tmh_client_warn("tmem: %s=%d no longer using shared pool %d owned 
> by %s=%d\n",
>             cli_id_str, cli_id, pool->pool_id, cli_id_str,pool->client->cli_id);
>          return;
>      }
> -    printk("%s %s-%s tmem pool ",destroy?"destroying":"flushing",
> -        is_persistent(pool) ? "persistent" : "ephemeral" ,
> -        is_shared(pool) ? "shared" : "private");
> -    printk("%s=%d pool_id=%d\n", cli_id_str,pool->client->cli_id,pool->pool_id);
> +    tmh_client_info("%s %s-%s tmem pool %s=%d pool_id=%d\n",
> +                    destroy ? "destroying" : "flushing",
> +                    is_persistent(pool) ? "persistent" : "ephemeral" ,
> +                    is_shared(pool) ? "shared" : "private",
> +                    cli_id_str, pool->client->cli_id, pool->pool_id);
>      if ( pool->client->live_migrating )
>      {
> -        printk("can't %s pool while %s is live-migrating\n",
> +        tmh_client_warn("can't %s pool while %s is live-migrating\n",
>                 destroy?"destroy":"flush", client_str);
>          return;
>      }
> @@ -1213,21 +1214,22 @@ static client_t *client_create(cli_id_t 
>      client_t *client = 
> tmh_alloc_infra(sizeof(client_t),__alignof__(client_t));
>      int i;
>  
> -    printk("tmem: initializing tmem capability for 
> %s=%d...",cli_id_str,cli_id);
> +    tmh_client_info("tmem: initializing tmem capability for %s=%d...",
> +                    cli_id_str, cli_id);
>      if ( client == NULL )
>      {
> -        printk("failed... out of memory\n");
> +        tmh_client_err("failed... out of memory\n");
>          goto fail;
>      }
>      memset(client,0,sizeof(client_t));
>      if ( (client->tmh = tmh_client_init(cli_id)) == NULL )
>      {
> -        printk("failed... can't allocate host-dependent part of client\n");
> +        tmh_client_err("failed... can't allocate host-dependent part of 
> client\n");
>          goto fail;
>      }
>      if ( !tmh_set_client_from_id(client, client->tmh, cli_id) )
>      {
> -        printk("failed... can't set client\n");
> +        tmh_client_err("failed... can't set client\n");
>          goto fail;
>      }
>      client->cli_id = cli_id;
> @@ -1249,7 +1251,7 @@ static client_t *client_create(cli_id_t 
>      client->eph_count = client->eph_count_max = 0;
>      client->total_cycles = 0; client->succ_pers_puts = 0;
>      client->succ_eph_gets = 0; client->succ_pers_gets = 0;
> -    printk("ok\n");
> +    tmh_client_info("ok\n");
>      return client;
>  
>   fail:
> @@ -1903,32 +1905,33 @@ static NOINLINE int do_tmem_new_pool(cli
>          cli_id = tmh_get_cli_id_from_current();
>      else
>          cli_id = this_cli_id;
> -    printk("tmem: allocating %s-%s tmem pool for %s=%d...",
> +    tmh_client_info("tmem: allocating %s-%s tmem pool for %s=%d...",
>          persistent ? "persistent" : "ephemeral" ,
>          shared ? "shared" : "private", cli_id_str, cli_id);
>      if ( specversion != TMEM_SPEC_VERSION )
>      {
> -        printk("failed... unsupported spec version\n");
> +        tmh_client_err("failed... unsupported spec version\n");
>          return -EPERM;
>      }
>      if ( pagebits != (PAGE_SHIFT - 12) )
>      {
> -        printk("failed... unsupported pagesize %d\n",1<<(pagebits+12));
> +        tmh_client_err("failed... unsupported pagesize %d\n",
> +                       1 << (pagebits + 12));
>          return -EPERM;
>      }
>      if ( flags & TMEM_POOL_PRECOMPRESSED )
>      {
> -        printk("failed... precompression flag set but unsupported\n");
> +        tmh_client_err("failed... precompression flag set but 
> unsupported\n");
>          return -EPERM;
>      }
>      if ( flags & TMEM_POOL_RESERVED_BITS )
>      {
> -        printk("failed... reserved bits must be zero\n");
> +        tmh_client_err("failed... reserved bits must be zero\n");
>          return -EPERM;
>      }
>      if ( (pool = pool_alloc()) == NULL )
>      {
> -        printk("failed... out of memory\n");
> +        tmh_client_err("failed... out of memory\n");
>          return -ENOMEM;
>      }
>      if ( this_cli_id != CLI_ID_NULL )
> @@ -1947,7 +1950,7 @@ static NOINLINE int do_tmem_new_pool(cli
>                  break;
>          if ( d_poolid >= MAX_POOLS_PER_DOMAIN )
>          {
> -            printk("failed... no more pool slots available for this %s\n",
> +            tmh_client_err("failed... no more pool slots available for this 
> %s\n",
>                     client_str);
>              goto fail;
>          }
> @@ -1977,9 +1980,8 @@ static NOINLINE int do_tmem_new_pool(cli
>              {
>                  if ( shpool->uuid[0] == uuid_lo && shpool->uuid[1] == uuid_hi )
>                  {
> -                    printk("(matches shared pool uuid=%"PRIx64".%"PRIx64") 
> ",
> -                        uuid_hi, uuid_lo);
> -                    printk("pool_id=%d\n",d_poolid);
> +                    tmh_client_info("(matches shared pool 
> uuid=%"PRIx64".%"PRIx64") pool_id=%d\n",
> +                        uuid_hi, uuid_lo, d_poolid);
>                      client->pools[d_poolid] = global_shared_pools[s_poolid];
>                      shared_pool_join(global_shared_pools[s_poolid], 
> client);
>                      pool_free(pool);
> @@ -1991,7 +1993,7 @@ static NOINLINE int do_tmem_new_pool(cli
>          }
>          if ( first_unused_s_poolid == MAX_GLOBAL_SHARED_POOLS )
>          {
> -            printk("tmem: failed... no global shared pool slots 
> available\n");
> +            tmh_client_warn("tmem: failed... no global shared pool slots 
> available\n");
>              goto fail;
>          }
>          else
> @@ -2007,7 +2009,7 @@ static NOINLINE int do_tmem_new_pool(cli
>      pool->pool_id = d_poolid;
>      pool->persistent = persistent;
>      pool->uuid[0] = uuid_lo; pool->uuid[1] = uuid_hi;
> -    printk("pool_id=%d\n",d_poolid);
> +    tmh_client_info("pool_id=%d\n", d_poolid);
>      return d_poolid;
>  
>  fail:
> @@ -2030,14 +2032,15 @@ static int tmemc_freeze_pools(cli_id_t c
>      {
>          list_for_each_entry(client,&global_client_list,client_list)
>              client_freeze(client,freeze);
> -        printk("tmem: all pools %s for all %ss\n",s,client_str);
> +        tmh_client_info("tmem: all pools %s for all %ss\n", s, client_str);
>      }
>      else
>      {
>          if ( (client = tmh_client_from_cli_id(cli_id)) == NULL)
>              return -1;
>          client_freeze(client,freeze);
> -        printk("tmem: all pools %s for %s=%d\n",s,cli_id_str,cli_id);
> +        tmh_client_info("tmem: all pools %s for %s=%d\n",
> +                         s, cli_id_str, cli_id);
>      }
>      return 0;
>  }
> @@ -2048,7 +2051,7 @@ static int tmemc_flush_mem(cli_id_t cli_
>  
>      if ( cli_id != CLI_ID_NULL )
>      {
> -        printk("tmem: %s-specific flush not supported yet, use --all\n",
> +        tmh_client_warn("tmem: %s-specific flush not supported yet, use 
> --all\n",
>             client_str);
>          return -1;
>      }
> @@ -2261,13 +2264,15 @@ static int tmemc_set_var_one(client_t *c
>      case TMEMC_SET_WEIGHT:
>          old_weight = client->weight;
>          client->weight = arg1;
> -        printk("tmem: weight set to %d for %s=%d\n",arg1,cli_id_str,cli_id);
> +        tmh_client_info("tmem: weight set to %d for %s=%d\n",
> +                        arg1, cli_id_str, cli_id);
>          atomic_sub(old_weight,&client_weight_total);
>          atomic_add(client->weight,&client_weight_total);
>          break;
>      case TMEMC_SET_CAP:
>          client->cap = arg1;
> -        printk("tmem: cap set to %d for %s=%d\n",arg1,cli_id_str,cli_id);
> +        tmh_client_info("tmem: cap set to %d for %s=%d\n",
> +                        arg1, cli_id_str, cli_id);
>          break;
>      case TMEMC_SET_COMPRESS:
>  #ifdef __i386__
> @@ -2275,17 +2280,17 @@ static int tmemc_set_var_one(client_t *c
>  #endif
>          if ( tmh_dedup_enabled() )
>          {
> -            printk("tmem: compression %s for all %ss, cannot be changed "
> -                   "when tmem_dedup is enabled\n",
> -            tmh_compression_enabled() ? "enabled" : "disabled",client_str);
> +            tmh_client_warn("tmem: compression %s for all %ss, cannot be 
> changed when tmem_dedup is enabled\n",
> +                            tmh_compression_enabled() ? "enabled" : 
> "disabled",
> +                            client_str);
>              return -1;
>          }
>          client->compress = arg1 ? 1 : 0;
> -        printk("tmem: compression %s for %s=%d\n",
> +        tmh_client_info("tmem: compression %s for %s=%d\n",
>              arg1 ? "enabled" : "disabled",cli_id_str,cli_id);
>          break;
>      default:
> -        printk("tmem: unknown subop %d for tmemc_set_var\n",subop);
> +        tmh_client_warn("tmem: unknown subop %d for tmemc_set_var\n", 
> subop);
>          return -1;
>      }
>      return 0;
> @@ -2668,7 +2673,7 @@ EXPORT long do_tmem_op(tmem_cli_op_t uop
>  
>      if ( unlikely(tmh_get_tmemop_from_client(&op, uops) != 0) )
>      {
> -        printk("tmem: can't get tmem struct from %s\n",client_str);
> +        tmh_client_err("tmem: can't get tmem struct from %s\n", 
> client_str);
>          rc = -EFAULT;
>          if ( !tmh_lock_all )
>              goto simple_error;
> @@ -2702,7 +2707,8 @@ EXPORT long do_tmem_op(tmem_cli_op_t uop
>          tmem_write_lock_set = 1;
>          if ( (client = client_create(tmh_get_cli_id_from_current())) == 
> NULL )
>          {
> -            printk("tmem: can't create tmem structure for %s\n",client_str);
> +            tmh_client_err("tmem: can't create tmem structure for %s\n",
> +                           client_str);
>              rc = -ENOMEM;
>              goto out;
>          }
> @@ -2726,8 +2732,8 @@ EXPORT long do_tmem_op(tmem_cli_op_t uop
>          if ( ((uint32_t)op.pool_id >= MAX_POOLS_PER_DOMAIN) ||
>               ((pool = client->pools[op.pool_id]) == NULL) )
>          {
> +            tmh_client_err("tmem: operation requested on uncreated 
> pool\n");
>              rc = -ENODEV;
> -            printk("tmem: operation requested on uncreated pool\n");
>              goto out;
>          }
>          ASSERT_SENTINEL(pool,POOL);
> @@ -2783,11 +2789,11 @@ EXPORT long do_tmem_op(tmem_cli_op_t uop
>          break;
>      case TMEM_XCHG:
>          /* need to hold global lock to ensure xchg is atomic */
> -        printk("tmem_xchg op not implemented yet\n");
> +        tmh_client_warn("tmem_xchg op not implemented yet\n");
>          rc = 0;
>          break;
>      default:
> -        printk("tmem: op %d not implemented\n", op.cmd);
> +        tmh_client_warn("tmem: op %d not implemented\n", op.cmd);
>          rc = 0;
>          break;
>      }
> --- a/xen/include/xen/tmem_xen.h
> +++ b/xen/include/xen/tmem_xen.h
> @@ -512,6 +512,9 @@ int tmh_copy_to_client(tmem_cli_mfn_t, p
>  
>  extern int tmh_copy_tze_to_client(tmem_cli_mfn_t cmfn, void *tmem_va, 
> pagesize_t len);
>  
> +#define tmh_client_err(fmt, args...)  printk(XENLOG_G_ERR fmt, ##args)
> +#define tmh_client_warn(fmt, args...) printk(XENLOG_G_WARNING fmt, ##args)
> +#define tmh_client_info(fmt, args...) printk(XENLOG_G_INFO fmt, ##args)
>  
>  #define TMEM_PERF
>  #ifdef TMEM_PERF



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 11 08:56:02 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 2012 08:56: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 1TBMG2-0000ex-0Q; Tue, 11 Sep 2012 08:55: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 1TBMG0-0000es-Fo
	for xen-devel@lists.xen.org; Tue, 11 Sep 2012 08:55:44 +0000
Received: from [85.158.143.99:33483] by server-3.bemta-4.messagelabs.com id
	E6/8C-08232-F8CFE405; Tue, 11 Sep 2012 08:55:43 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1347353739!24433232!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDg1NjI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7672 invoked from network); 11 Sep 2012 08:55:42 -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;
	11 Sep 2012 08:55:42 -0000
X-IronPort-AV: E=Sophos;i="4.80,402,1344211200"; d="scan'208";a="14462572"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Sep 2012 08:54: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.279.1;
	Tue, 11 Sep 2012 09:54:39 +0100
Message-ID: <1347353677.5305.130.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Keir Fraser <keir@xen.org>
Date: Tue, 11 Sep 2012 09:54:37 +0100
In-Reply-To: <CC741BAD.4B395%keir@xen.org>
References: <CC741BAD.4B395%keir@xen.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v2] Merge IS_PRIV checks into XSM hooks
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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-09-10 at 22:35 +0100, Keir Fraser wrote:
> On 10/09/2012 22:10, "Daniel De Graaf" <dgdegra@tycho.nsa.gov> wrote:
> 
> > On 09/10/2012 04:51 PM, Keir Fraser wrote:
> >> On 10/09/2012 20:48, "Daniel De Graaf" <dgdegra@tycho.nsa.gov> wrote:
> >> 
> >>> Overall, this series should not change the behavior of Xen when XSM is
> >>> not enabled; however, in some cases, the exact errors that are returned
> >>> will be different because security checks have been moved below validity
> >>> checks. Also, once applied, newly introduced domctls and sysctls will
> >>> not automatically be guarded by IS_PRIV checks - they will need to add
> >>> their own permission checking code.
> >> 
> >> How do we guard against accidentally forgetting to do this?
> > 
> > The same way you guard against it when adding a new hypercall: when adding
> > new functionality that needs access checks, also add the access checks.
> 
> So... We just shouldn't accidentally forget. That will work well. ;)
> Historically XSM has not been top of many committers' checklists.

Can we play tricks like

	int did_priv_check;

	switch(op)
	case FOO:
		if (xsm_check_foo(&did_priv_check))
		....
		break;
	}
	ASSERT(did_priv_check)

I'd expect the compiler to catch missing checks due to the use of the
uninitialised var, although that relies somewhat on the switch not being
too big and confusing it.

The other option might be to define domctl_do_perm_check, which has a
similar switch over op but an explicit default: return -EPERM. Then call
that from the top of do_domctl instead of scattering the priv checks
throughout the main switch statement? That way if you forget to add the
perm check it simply won't work and you'll see that the first time you
try and test it...

Or an array of do_perm_check function pointers of NR_DOMCTL in size and
a NULL check? The differing prototypes probably make this one a
non-starter without loads of per op helper functions.

Ian.

>  -- Keir
> 
> >>> The ARM architecture is not touched at all in these patches. The only
> >>> obvious breakage that I can see is due to rcu_lock_target_domain_by_id
> >>> being removed, but XSM hooks will be needed for domctls and sysctls.
> >> 
> >> So ARM build is broken? And/or ARM is made insecure because of unchecked
> >> sysctls/domctls?
> >> 
> >>  -- Keir
> > 
> > The ARM build is broken by patch #19 in this series; fixing it is fairly
> > simple (I'll send a non-compile-tested version as 21/20), or you could
> > postpone that patch as it's just cleanup.
> > 
> > Since ARM doesn't have any arch-specific domctls or sysctls yet, they are
> > not insecure. You could also add an IS_PRIV check at the top of ARM's
> > arch_do_{dom,sys}ctl functions if you don't want to add XSM hooks for each
> > operation as in x86.
> > 
> >> 
> >>> The rcu_lock_target_domain_by_id and rcu_lock_remote_target_domain_by_id
> >>> functions are removed by this series because they act as wrappers around
> >>> IS_PRIV_FOR; their callers have been changed to use XSM checks instead.
> >>> 
> >>> Miscellaneous updates to FLASK:
> >>>     [PATCH 01/20] xsm/flask: remove inherited class attributes
> >>>     [PATCH 02/20] xsm/flask: remove unneeded create_sid field
> >>>     [PATCH 03/20] xen: Add versions of rcu_lock_*_domain without IS_PRIV
> >>>     [PATCH 04/20] xsm/flask: add domain relabel support
> >>>     [PATCH 05/20] libxl: introduce XSM relabel on build
> >>>     [PATCH 06/20] flask/policy: Add domain relabel example
> >>> 
> >>> Preparatory new hooks:
> >>>     [PATCH 07/20] arch/x86: add distinct XSM hooks for map/unmap
> >>>     [PATCH 08/20] arch/x86: add missing XSM checks to XENPF_ commands
> >>>     [PATCH 09/20] xsm/flask: Add checks on the domain performing the
> >>> 
> >>> Refactoring:
> >>>     [PATCH 10/20] xsm: Add IS_PRIV checks to dummy XSM module
> >>>     [PATCH 11/20] xen: use XSM instead of IS_PRIV where duplicated
> >>>     [PATCH 12/20] xen: avoid calling rcu_lock_*target_domain when an XSM
> >>> 
> >>> Remaining IS_PRIV calls:
> >>>     [PATCH 13/20] arch/x86: Add missing domctl and mem_sharing XSM hooks
> >>>     [PATCH 14/20] tmem: Add access control check
> >>>     [PATCH 17/20] arch/x86: use XSM hooks for get_pg_owner access checks
> >>>     [PATCH 18/20] xen: Add XSM hook for XENMEM_exchange
> >>> 
> >>> Cleanup, FLASK updates to support IS_PRIV emulation:
> >>>     [PATCH 15/20] xsm: remove unneeded xsm_call macro
> >>>     [PATCH 16/20] xsm/flask: add distinct SIDs for self/target access
> >>>     [PATCH 19/20] xen: remove rcu_lock_{remote_,}target_domain_by_id
> >>>     [PATCH 20/20] flask: add missing operations
> >>> 
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Sep 11 08:56:02 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 2012 08:56: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 1TBMG2-0000ex-0Q; Tue, 11 Sep 2012 08:55: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 1TBMG0-0000es-Fo
	for xen-devel@lists.xen.org; Tue, 11 Sep 2012 08:55:44 +0000
Received: from [85.158.143.99:33483] by server-3.bemta-4.messagelabs.com id
	E6/8C-08232-F8CFE405; Tue, 11 Sep 2012 08:55:43 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1347353739!24433232!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDg1NjI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7672 invoked from network); 11 Sep 2012 08:55:42 -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;
	11 Sep 2012 08:55:42 -0000
X-IronPort-AV: E=Sophos;i="4.80,402,1344211200"; d="scan'208";a="14462572"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Sep 2012 08:54: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.279.1;
	Tue, 11 Sep 2012 09:54:39 +0100
Message-ID: <1347353677.5305.130.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Keir Fraser <keir@xen.org>
Date: Tue, 11 Sep 2012 09:54:37 +0100
In-Reply-To: <CC741BAD.4B395%keir@xen.org>
References: <CC741BAD.4B395%keir@xen.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v2] Merge IS_PRIV checks into XSM hooks
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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-09-10 at 22:35 +0100, Keir Fraser wrote:
> On 10/09/2012 22:10, "Daniel De Graaf" <dgdegra@tycho.nsa.gov> wrote:
> 
> > On 09/10/2012 04:51 PM, Keir Fraser wrote:
> >> On 10/09/2012 20:48, "Daniel De Graaf" <dgdegra@tycho.nsa.gov> wrote:
> >> 
> >>> Overall, this series should not change the behavior of Xen when XSM is
> >>> not enabled; however, in some cases, the exact errors that are returned
> >>> will be different because security checks have been moved below validity
> >>> checks. Also, once applied, newly introduced domctls and sysctls will
> >>> not automatically be guarded by IS_PRIV checks - they will need to add
> >>> their own permission checking code.
> >> 
> >> How do we guard against accidentally forgetting to do this?
> > 
> > The same way you guard against it when adding a new hypercall: when adding
> > new functionality that needs access checks, also add the access checks.
> 
> So... We just shouldn't accidentally forget. That will work well. ;)
> Historically XSM has not been top of many committers' checklists.

Can we play tricks like

	int did_priv_check;

	switch(op)
	case FOO:
		if (xsm_check_foo(&did_priv_check))
		....
		break;
	}
	ASSERT(did_priv_check)

I'd expect the compiler to catch missing checks due to the use of the
uninitialised var, although that relies somewhat on the switch not being
too big and confusing it.

The other option might be to define domctl_do_perm_check, which has a
similar switch over op but an explicit default: return -EPERM. Then call
that from the top of do_domctl instead of scattering the priv checks
throughout the main switch statement? That way if you forget to add the
perm check it simply won't work and you'll see that the first time you
try and test it...

Or an array of do_perm_check function pointers of NR_DOMCTL in size and
a NULL check? The differing prototypes probably make this one a
non-starter without loads of per op helper functions.

Ian.

>  -- Keir
> 
> >>> The ARM architecture is not touched at all in these patches. The only
> >>> obvious breakage that I can see is due to rcu_lock_target_domain_by_id
> >>> being removed, but XSM hooks will be needed for domctls and sysctls.
> >> 
> >> So ARM build is broken? And/or ARM is made insecure because of unchecked
> >> sysctls/domctls?
> >> 
> >>  -- Keir
> > 
> > The ARM build is broken by patch #19 in this series; fixing it is fairly
> > simple (I'll send a non-compile-tested version as 21/20), or you could
> > postpone that patch as it's just cleanup.
> > 
> > Since ARM doesn't have any arch-specific domctls or sysctls yet, they are
> > not insecure. You could also add an IS_PRIV check at the top of ARM's
> > arch_do_{dom,sys}ctl functions if you don't want to add XSM hooks for each
> > operation as in x86.
> > 
> >> 
> >>> The rcu_lock_target_domain_by_id and rcu_lock_remote_target_domain_by_id
> >>> functions are removed by this series because they act as wrappers around
> >>> IS_PRIV_FOR; their callers have been changed to use XSM checks instead.
> >>> 
> >>> Miscellaneous updates to FLASK:
> >>>     [PATCH 01/20] xsm/flask: remove inherited class attributes
> >>>     [PATCH 02/20] xsm/flask: remove unneeded create_sid field
> >>>     [PATCH 03/20] xen: Add versions of rcu_lock_*_domain without IS_PRIV
> >>>     [PATCH 04/20] xsm/flask: add domain relabel support
> >>>     [PATCH 05/20] libxl: introduce XSM relabel on build
> >>>     [PATCH 06/20] flask/policy: Add domain relabel example
> >>> 
> >>> Preparatory new hooks:
> >>>     [PATCH 07/20] arch/x86: add distinct XSM hooks for map/unmap
> >>>     [PATCH 08/20] arch/x86: add missing XSM checks to XENPF_ commands
> >>>     [PATCH 09/20] xsm/flask: Add checks on the domain performing the
> >>> 
> >>> Refactoring:
> >>>     [PATCH 10/20] xsm: Add IS_PRIV checks to dummy XSM module
> >>>     [PATCH 11/20] xen: use XSM instead of IS_PRIV where duplicated
> >>>     [PATCH 12/20] xen: avoid calling rcu_lock_*target_domain when an XSM
> >>> 
> >>> Remaining IS_PRIV calls:
> >>>     [PATCH 13/20] arch/x86: Add missing domctl and mem_sharing XSM hooks
> >>>     [PATCH 14/20] tmem: Add access control check
> >>>     [PATCH 17/20] arch/x86: use XSM hooks for get_pg_owner access checks
> >>>     [PATCH 18/20] xen: Add XSM hook for XENMEM_exchange
> >>> 
> >>> Cleanup, FLASK updates to support IS_PRIV emulation:
> >>>     [PATCH 15/20] xsm: remove unneeded xsm_call macro
> >>>     [PATCH 16/20] xsm/flask: add distinct SIDs for self/target access
> >>>     [PATCH 19/20] xen: remove rcu_lock_{remote_,}target_domain_by_id
> >>>     [PATCH 20/20] flask: add missing operations
> >>> 
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Sep 11 09:11:07 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 2012 09: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 1TBMUR-0000zR-NL; Tue, 11 Sep 2012 09:10:39 +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 1TBMUR-0000zM-0F
	for xen-devel@lists.xen.org; Tue, 11 Sep 2012 09:10:39 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1347354407!3538892!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDg1NjI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1959 invoked from network); 11 Sep 2012 09:06:48 -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;
	11 Sep 2012 09:06:48 -0000
X-IronPort-AV: E=Sophos;i="4.80,402,1344211200"; d="scan'208";a="14463066"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Sep 2012 09:05: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.279.1;
	Tue, 11 Sep 2012 10:05:25 +0100
Message-ID: <1347354323.5305.136.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Tue, 11 Sep 2012 10:05:23 +0100
In-Reply-To: <504F045E020000780009A6B2@nat28.tlf.novell.com>
References: <1347306553-20980-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1347306553-20980-12-git-send-email-dgdegra@tycho.nsa.gov>
	<504F045E020000780009A6B2@nat28.tlf.novell.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>, "Keir \(Xen.org\)" <keir@xen.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 11/20] xen: use XSM instead of IS_PRIV where
 duplicated
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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-09-11 at 08:29 +0100, Jan Beulich wrote:
> >  * do_console_io has changed to IS_PRIV from an explicit domid==0
> 
> I see a point in actually limiting this to Dom0 - that's the only
> domain that can't possibly have a virtual console. But I'm not
> really opposed to changing this.

On a debug and/or verbose build of the hypervisor any domain can log
here, and pvops Linux with earlyprintk=xen and/or xen_raw_printk will do
so - it's quite useful for debugging early start of day issues in guest
kernels. Although I suppose we can always comment out the check locally
when doing such debugging.

It occurs to me now that perhaps this should be handled more like the
HVM port e9 stuff (i.e. with rate limiting etc) anyway.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 11 09:11:07 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 2012 09: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 1TBMUR-0000zR-NL; Tue, 11 Sep 2012 09:10:39 +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 1TBMUR-0000zM-0F
	for xen-devel@lists.xen.org; Tue, 11 Sep 2012 09:10:39 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1347354407!3538892!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDg1NjI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1959 invoked from network); 11 Sep 2012 09:06:48 -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;
	11 Sep 2012 09:06:48 -0000
X-IronPort-AV: E=Sophos;i="4.80,402,1344211200"; d="scan'208";a="14463066"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Sep 2012 09:05: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.279.1;
	Tue, 11 Sep 2012 10:05:25 +0100
Message-ID: <1347354323.5305.136.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Tue, 11 Sep 2012 10:05:23 +0100
In-Reply-To: <504F045E020000780009A6B2@nat28.tlf.novell.com>
References: <1347306553-20980-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1347306553-20980-12-git-send-email-dgdegra@tycho.nsa.gov>
	<504F045E020000780009A6B2@nat28.tlf.novell.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>, "Keir \(Xen.org\)" <keir@xen.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 11/20] xen: use XSM instead of IS_PRIV where
 duplicated
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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-09-11 at 08:29 +0100, Jan Beulich wrote:
> >  * do_console_io has changed to IS_PRIV from an explicit domid==0
> 
> I see a point in actually limiting this to Dom0 - that's the only
> domain that can't possibly have a virtual console. But I'm not
> really opposed to changing this.

On a debug and/or verbose build of the hypervisor any domain can log
here, and pvops Linux with earlyprintk=xen and/or xen_raw_printk will do
so - it's quite useful for debugging early start of day issues in guest
kernels. Although I suppose we can always comment out the check locally
when doing such debugging.

It occurs to me now that perhaps this should be handled more like the
HVM port e9 stuff (i.e. with rate limiting etc) anyway.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 11 09:18:02 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 2012 09: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 1TBMbG-00018h-JX; Tue, 11 Sep 2012 09:17:42 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <zhenzhong.duan@oracle.com>) id 1TBMbF-00018c-7X
	for xen-devel@lists.xen.org; Tue, 11 Sep 2012 09:17:41 +0000
Received: from [85.158.143.35:64451] by server-2.bemta-4.messagelabs.com id
	DA/3C-21239-3B10F405; Tue, 11 Sep 2012 09:17:39 +0000
X-Env-Sender: zhenzhong.duan@oracle.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1347355001!13099785!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDc0Mjk0Nw==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15597 invoked from network); 11 Sep 2012 09:16:43 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-3.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 11 Sep 2012 09:16: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 q8B9Gc7Y006469
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 11 Sep 2012 09:16:39 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q8B9Gbqe026794
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 11 Sep 2012 09:16:38 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
	q8B9GbKN013041; Tue, 11 Sep 2012 04:16:37 -0500
Received: from zhenzhong2.localdomain (/10.182.39.88)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 11 Sep 2012 02:16:37 -0700
Message-ID: <504F01D6.3050903@oracle.com>
Date: Tue, 11 Sep 2012 17:18:14 +0800
From: DuanZhenzhong <zhenzhong.duan@oracle.com>
Organization: Oracle Corporation
User-Agent: Thunderbird 2.0.0.24 (X11/20101209)
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <504764270200007800098DE1@nat28.tlf.novell.com>
	<504A01790200007800099C52@nat28.tlf.novell.com>
	<504F1412020000780009A750@nat28.tlf.novell.com>
In-Reply-To: <504F1412020000780009A750@nat28.tlf.novell.com>
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: dan.magenheimer@oracle.com, Ian Campbell <ian.campbell@citrix.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Ping: [PATCH 09/11,
	v2] tmem: reduce severity of log messages
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Dan is offline recently.
What about 'printk("tmem_relinquish_page: failing order=%d\n", order)', 
more like a  guest level msg.
zduan

Jan Beulich wrote:
> I was hoping to get this series (and the supposedly trivial tools
> side fix for save/restore) into the tree, but this patch is lacking
> an ack...
>
> Jan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 11 09:18:02 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 2012 09: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 1TBMbG-00018h-JX; Tue, 11 Sep 2012 09:17:42 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <zhenzhong.duan@oracle.com>) id 1TBMbF-00018c-7X
	for xen-devel@lists.xen.org; Tue, 11 Sep 2012 09:17:41 +0000
Received: from [85.158.143.35:64451] by server-2.bemta-4.messagelabs.com id
	DA/3C-21239-3B10F405; Tue, 11 Sep 2012 09:17:39 +0000
X-Env-Sender: zhenzhong.duan@oracle.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1347355001!13099785!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDc0Mjk0Nw==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15597 invoked from network); 11 Sep 2012 09:16:43 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-3.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 11 Sep 2012 09:16: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 q8B9Gc7Y006469
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 11 Sep 2012 09:16:39 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q8B9Gbqe026794
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 11 Sep 2012 09:16:38 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
	q8B9GbKN013041; Tue, 11 Sep 2012 04:16:37 -0500
Received: from zhenzhong2.localdomain (/10.182.39.88)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 11 Sep 2012 02:16:37 -0700
Message-ID: <504F01D6.3050903@oracle.com>
Date: Tue, 11 Sep 2012 17:18:14 +0800
From: DuanZhenzhong <zhenzhong.duan@oracle.com>
Organization: Oracle Corporation
User-Agent: Thunderbird 2.0.0.24 (X11/20101209)
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <504764270200007800098DE1@nat28.tlf.novell.com>
	<504A01790200007800099C52@nat28.tlf.novell.com>
	<504F1412020000780009A750@nat28.tlf.novell.com>
In-Reply-To: <504F1412020000780009A750@nat28.tlf.novell.com>
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: dan.magenheimer@oracle.com, Ian Campbell <ian.campbell@citrix.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Ping: [PATCH 09/11,
	v2] tmem: reduce severity of log messages
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Dan is offline recently.
What about 'printk("tmem_relinquish_page: failing order=%d\n", order)', 
more like a  guest level msg.
zduan

Jan Beulich wrote:
> I was hoping to get this series (and the supposedly trivial tools
> side fix for save/restore) into the tree, but this patch is lacking
> an ack...
>
> Jan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 11 09:19:59 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 2012 09:19: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 1TBMdB-0001Dg-4I; Tue, 11 Sep 2012 09:19:41 +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 1TBMd9-0001DM-6s
	for xen-devel@lists.xensource.com; Tue, 11 Sep 2012 09:19:39 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1347355172!7105722!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDg1NjI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13847 invoked from network); 11 Sep 2012 09:19:33 -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 Sep 2012 09:19:33 -0000
X-IronPort-AV: E=Sophos;i="4.80,402,1344211200"; d="scan'208";a="14463476"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Sep 2012 09:18: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.279.1; Tue, 11 Sep 2012 10:18: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 1TBMbz-00053b-Fo;
	Tue, 11 Sep 2012 09:18:27 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1TBMby-0000U8-TN;
	Tue, 11 Sep 2012 10:18:27 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-13675-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Tue, 11 Sep 2012 10:18:27 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13675: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 13675 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13675/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-win-vcpus1 12 guest-localmigrate/x10   fail REGR. vs. 13668

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore            fail   like 13668
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail like 13668
 test-i386-i386-xl-qemuu-winxpsp3  9 guest-localmigrate         fail like 13668
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail like 13668

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-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
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass

version targeted for testing:
 xen                  a1f73e989c24
baseline version:
 xen                  7d770de90b7f

------------------------------------------------------------
People who touched revisions under test:
  Ian Campbell <ian.campbell@citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Keir Fraser <keir@xen.org>
  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                                 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                                     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:   25842:a1f73e989c24
tag:         tip
user:        Jan Beulich <jbeulich@suse.com>
date:        Mon Sep 10 16:47:31 2012 +0200
    
    x86/hvm: don't give vector callback higher priority than NMI/MCE
    
    Those two should always be delivered first imo.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
    
    
changeset:   25841:7d770de90b7f
user:        Jan Beulich <JBeulich@suse.com>
date:        Mon Sep 10 11:13:56 2012 +0100
    
    docs: document "ucode=" hypervisor command line option
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Ian Campbell <ian.campbell@citrix.com>
    Committed-by: Ian Campbell <ian.campbell@citrix.com>
    
    
(qemu changes not included)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 11 09:19:59 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 2012 09:19: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 1TBMdB-0001Dg-4I; Tue, 11 Sep 2012 09:19:41 +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 1TBMd9-0001DM-6s
	for xen-devel@lists.xensource.com; Tue, 11 Sep 2012 09:19:39 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1347355172!7105722!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDg1NjI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13847 invoked from network); 11 Sep 2012 09:19:33 -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 Sep 2012 09:19:33 -0000
X-IronPort-AV: E=Sophos;i="4.80,402,1344211200"; d="scan'208";a="14463476"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Sep 2012 09:18: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.279.1; Tue, 11 Sep 2012 10:18: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 1TBMbz-00053b-Fo;
	Tue, 11 Sep 2012 09:18:27 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1TBMby-0000U8-TN;
	Tue, 11 Sep 2012 10:18:27 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-13675-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Tue, 11 Sep 2012 10:18:27 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13675: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 13675 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13675/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-win-vcpus1 12 guest-localmigrate/x10   fail REGR. vs. 13668

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore            fail   like 13668
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail like 13668
 test-i386-i386-xl-qemuu-winxpsp3  9 guest-localmigrate         fail like 13668
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail like 13668

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-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
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass

version targeted for testing:
 xen                  a1f73e989c24
baseline version:
 xen                  7d770de90b7f

------------------------------------------------------------
People who touched revisions under test:
  Ian Campbell <ian.campbell@citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Keir Fraser <keir@xen.org>
  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                                 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                                     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:   25842:a1f73e989c24
tag:         tip
user:        Jan Beulich <jbeulich@suse.com>
date:        Mon Sep 10 16:47:31 2012 +0200
    
    x86/hvm: don't give vector callback higher priority than NMI/MCE
    
    Those two should always be delivered first imo.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
    
    
changeset:   25841:7d770de90b7f
user:        Jan Beulich <JBeulich@suse.com>
date:        Mon Sep 10 11:13:56 2012 +0100
    
    docs: document "ucode=" hypervisor command line option
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Ian Campbell <ian.campbell@citrix.com>
    Committed-by: Ian Campbell <ian.campbell@citrix.com>
    
    
(qemu changes not included)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 11 09:34:00 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 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 1TBMqk-0001UI-I5; Tue, 11 Sep 2012 09:33:42 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1TBMqi-0001Ty-Tw
	for xen-devel@lists.xen.org; Tue, 11 Sep 2012 09:33:41 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1347355946!2831539!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNzM2MjU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 650 invoked from network); 11 Sep 2012 09:32:28 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Sep 2012 09:32:28 -0000
X-IronPort-AV: E=Sophos;i="4.80,402,1344211200"; 
	d="scan'208,217";a="207690844"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Sep 2012 09:32:26 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Tue, 11 Sep 2012 05:32: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 1TBMpV-00031l-8Y	for
	xen-devel@lists.xen.org; Tue, 11 Sep 2012 10:32:25 +0100
Message-ID: <504F0529.7010204@citrix.com>
Date: Tue, 11 Sep 2012 10:32:25 +0100
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:14.0) Gecko/20120714 Thunderbird/14.0
MIME-Version: 1.0
To: xen-devel@lists.xen.org
References: <CALQsBOWDE_KqpntG8WJo86omLP3+rhQ0LDMW5vB752ubpF1FAA@mail.gmail.com>
	<CALQsBOXFVM+cdhmke5JDJmns2XUpHjyDOVN6R5qrrY9nTOR3SQ@mail.gmail.com>
	<504DC059.4070003@citrix.com>
	<CALQsBOV0EsUY+eYWqtL-FVuTOWOk_MLPnC2CYYPhNU9t=sxt9g@mail.gmail.com>
	<504DC334.6060201@citrix.com>
	<CALQsBOXqT39-ZkOuTT-c58qUW6dihuXWfUi08YzjmgJzaW9YAA@mail.gmail.com>
	<CALQsBOUAv_kPuAjbvyPZs90rGM7ZOBjEctC6iMuf6c+CL+VkDw@mail.gmail.com>
In-Reply-To: <CALQsBOUAv_kPuAjbvyPZs90rGM7ZOBjEctC6iMuf6c+CL+VkDw@mail.gmail.com>
X-Enigmail-Version: 1.4.4
Subject: Re: [Xen-devel] issue using SRIOV "Unable to start - perhaps the PF
 driver is not up yet", while PF driver is actually up
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0887041430581390211=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============0887041430581390211==
Content-Type: multipart/alternative;
	boundary="------------030307030407000205090902"

--------------030307030407000205090902
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit


On 10/09/12 19:32, Ashok Anand wrote:
> Any more thoughts on it? I will really appreciate it.

Sorry - I am debugging a memory corruption issue, so not paying too
close attention to emails.

Have you ensured that the pif is up in dom0 before trying to use a vif?

~Andrew

>
> regards,
> Ashok
>
> On Mon, Sep 10, 2012 at 4:16 PM, Ashok Anand <ashok.anand@gmail.com
> <mailto:ashok.anand@gmail.com>> wrote:
>
>
>     I am passing virtual functions. please see below ,based on the
>     message from lspci. 
>
>         What does lspci -vv for the physical function say?
>
>         As for the physical function: it is unsafe to pass physical
>         functions to a non-trusted guest, as the physical function has
>         complete control over the all the virtual functions, even if
>         they are passed through to other guests.  For that reason, the
>         physical function should remain in dom0 (or a device driver
>         domain if you are going for disaggregation).
>
>
>     here is the message lspci -vv | grep Eth gives me, 
>
>     0f:00.0 Ethernet controller: Intel Corporation 82599EB 10-Gigabit
>     SFI/SFP+ Network Connection (rev 01)
>     Subsystem: Intel Corporation Ethernet Server Adapter X520-2
>     0f:00.1 Ethernet controller: Intel Corporation 82599EB 10-Gigabit
>     SFI/SFP+ Network Connection (rev 01)
>     Subsystem: Intel Corporation Ethernet Server Adapter X520-2
>     0f:10.0 Ethernet controller: Intel Corporation 82599 Ethernet
>     Controller Virtual Function (rev 01)
>     0f:10.2 Ethernet controller: Intel Corporation 82599 Ethernet
>     Controller Virtual Function (rev 01)
>     0f:10.4 Ethernet controller: Intel Corporation 82599 Ethernet
>     Controller Virtual Function (rev 01)
>     0f:10.6 Ethernet controller: Intel Corporation 82599 Ethernet
>     Controller Virtual Function (rev 01)
>     0f:11.0 Ethernet controller: Intel Corporation 82599 Ethernet
>     Controller Virtual Function (rev 01)
>     0f:11.2 Ethernet controller: Intel Corporation 82599 Ethernet
>     Controller Virtual Function (rev 01)
>     0f:11.4 Ethernet controller: Intel Corporation 82599 Ethernet
>     Controller Virtual Function (rev 01)
>     0f:11.6 Ethernet controller: Intel Corporation 82599 Ethernet
>     Controller Virtual Function (rev 01)
>
>     Here, 0f:00.0 is the physical function, while 0f:10.0 and others
>     are virtual functions -- so I am attaching virtual functions. 
>
>
>      
>
>
>
>>
>>
>>
>>>
>>>             i attach 0f:10.0 to a domU ubuntu machine, xm pci-attach
>>>             ubuntu 0f:10.0
>>>
>>>             on my dom0 machine, i can ping other machine using eth2,
>>>             (implying PF on eth2 is active)
>>>
>>>             on my domU machine, when i attach the virtual function,
>>>             i get the following messages
>>>
>>>             [ 2282.688356 <tel:%5B%202282.688356>] ixgbevf
>>>             0000:00:00.0: Xen PCI mapped GSI0 to IRQ28
>>>             [ 2282.688470 <tel:%5B%202282.688470>] ixgbevf
>>>             0000:00:00.0: setting latency timer to 64
>>>             [ 2282.690187 <tel:%5B%202282.690187>] ixgbevf
>>>             0000:00:00.0: PF still in reset state, assigning new address
>>>
>>>             while PF on eth2 is  there and active, since i can ping
>>>             other machine.
>>>
>>>             Now, when I try to bring up the VF interface on domU, 
>>>              i get the following error
>>>
>>>              2476.295582] Unable to start - perhaps the PF Driver
>>>             isn't up yet
>>>             SIOCSIFFLAGS: Network is down
>>>             [ 2476.296917] Unable to start - perhaps the PF Driver
>>>             isn't up yet
>>>             SIOCSIFFLAGS: Network is down
>>>
>>>             and on dmesg on domU, 
>>>             [ 2476.295582] Unable to start - perhaps the PF Driver
>>>             isn't up yet
>>>             [ 2476.296917] Unable to start - perhaps the PF Driver
>>>             isn't up yet
>>>
>>>
>>>             Any thoughts on what could be wrong? I have been
>>>             struggling with this for quite some time
>>>             and would really appreciate your thoughts on it.
>>>
>>>             Thanks, 
>>>             Ashok
>>>
>>>
>>>
>>>
>>>
>>>
>>
>>             -- 
>>             Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
>>             T: +44 (0)1223 225 900 <tel:%2B44%20%280%291223%20225%20900>, http://www.citrix.com
>>
>>
>>             _______________________________________________
>>             Xen-devel mailing list
>>             Xen-devel@lists.xen.org <mailto:Xen-devel@lists.xen.org>
>>             http://lists.xen.org/xen-devel
>>
>>
>
>         -- 
>         Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
>         T: +44 (0)1223 225 900 <tel:%2B44%20%280%291223%20225%20900>, http://www.citrix.com
>
>
>

-- 
Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
T: +44 (0)1223 225 900, http://www.citrix.com


--------------030307030407000205090902
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">
    <br>
    <div class="moz-cite-prefix">On 10/09/12 19:32, Ashok Anand wrote:<br>
    </div>
    <blockquote
cite="mid:CALQsBOUAv_kPuAjbvyPZs90rGM7ZOBjEctC6iMuf6c+CL+VkDw@mail.gmail.com"
      type="cite">Any more thoughts on it? I will really appreciate it.</blockquote>
    <br>
    Sorry - I am debugging a memory corruption issue, so not paying too
    close attention to emails.<br>
    <br>
    Have you ensured that the pif is up in dom0 before trying to use a
    vif?<br>
    <br>
    ~Andrew<br>
    <br>
    <blockquote
cite="mid:CALQsBOUAv_kPuAjbvyPZs90rGM7ZOBjEctC6iMuf6c+CL+VkDw@mail.gmail.com"
      type="cite">
      <div><br>
      </div>
      <div>regards,</div>
      <div>Ashok<br>
        <br>
        <div class="gmail_quote">On Mon, Sep 10, 2012 at 4:16 PM, Ashok
          Anand <span dir="ltr">&lt;<a moz-do-not-send="true"
              href="mailto:ashok.anand@gmail.com" target="_blank">ashok.anand@gmail.com</a>&gt;</span>
          wrote:<br>
          <blockquote class="gmail_quote" style="margin:0 0 0
            .8ex;border-left:1px #ccc solid;padding-left:1ex">
            <div class="gmail_quote">
              <div><br>
              </div>
              <div>I am passing virtual functions. please see below
                ,based on the message from lspci.&nbsp;</div>
              <div class="im">
                <blockquote class="gmail_quote" style="margin:0 0 0
                  .8ex;border-left:1px #ccc solid;padding-left:1ex">
                  <div bgcolor="#FFFFFF" text="#000000">What does lspci
                    -vv for the physical function say?<br>
                    <br>
                    As for the physical function: it is unsafe to pass
                    physical functions to a non-trusted guest, as the
                    physical function has complete control over the all
                    the virtual functions, even if they are passed
                    through to other guests.&nbsp; For that reason, the
                    physical function should remain in dom0 (or a device
                    driver domain if you are going for disaggregation).</div>
                </blockquote>
                <div><br>
                </div>
              </div>
              <div>here is the message lspci -vv | grep Eth gives me,&nbsp;</div>
              <div><br>
              </div>
              <div>
                <div>0f:00.0 Ethernet controller: Intel Corporation
                  82599EB 10-Gigabit SFI/SFP+ Network Connection (rev
                  01)</div>
                <div><span style="white-space:pre-wrap"> </span>Subsystem:
                  Intel Corporation Ethernet Server Adapter X520-2</div>
                <div>0f:00.1 Ethernet controller: Intel Corporation
                  82599EB 10-Gigabit SFI/SFP+ Network Connection (rev
                  01)</div>
                <div><span style="white-space:pre-wrap"> </span>Subsystem:
                  Intel Corporation Ethernet Server Adapter X520-2</div>
                <div>0f:10.0 Ethernet controller: Intel Corporation
                  82599 Ethernet Controller Virtual Function (rev 01)</div>
                <div>0f:10.2 Ethernet controller: Intel Corporation
                  82599 Ethernet Controller Virtual Function (rev 01)</div>
                <div>0f:10.4 Ethernet controller: Intel Corporation
                  82599 Ethernet Controller Virtual Function (rev 01)</div>
                <div>
                  0f:10.6 Ethernet controller: Intel Corporation 82599
                  Ethernet Controller Virtual Function (rev 01)</div>
                <div>0f:11.0 Ethernet controller: Intel Corporation
                  82599 Ethernet Controller Virtual Function (rev 01)</div>
                <div>0f:11.2 Ethernet controller: Intel Corporation
                  82599 Ethernet Controller Virtual Function (rev 01)</div>
                <div>0f:11.4 Ethernet controller: Intel Corporation
                  82599 Ethernet Controller Virtual Function (rev 01)</div>
                <div>0f:11.6 Ethernet controller: Intel Corporation
                  82599 Ethernet Controller Virtual Function (rev 01)</div>
              </div>
              <div><br>
              </div>
              <div>Here, 0f:00.0 is the physical function, while 0f:10.0
                and others are virtual functions -- so I am attaching
                virtual functions.&nbsp;</div>
              <div>
                <div class="h5">
                  <div><br>
                  </div>
                  <div><br>
                  </div>
                  <div>&nbsp;</div>
                  <blockquote class="gmail_quote" style="margin:0 0 0
                    .8ex;border-left:1px #ccc solid;padding-left:1ex">
                    <div bgcolor="#FFFFFF" text="#000000">
                      <div>
                        <div><br>
                          <br>
                          <blockquote type="cite">
                            <div class="gmail_quote">
                              <div><br>
                              </div>
                              <blockquote class="gmail_quote"
                                style="margin:0 0 0 .8ex;border-left:1px
                                #ccc solid;padding-left:1ex">
                                <div bgcolor="#FFFFFF" text="#000000">
                                  <div><br>
                                    <br>
                                    <blockquote type="cite">
                                      <div class="gmail_quote">
                                        <div><br>
                                        </div>
                                        <div>i attach 0f:10.0 to a domU
                                          ubuntu machine,&nbsp;xm pci-attach
                                          ubuntu 0f:10.0</div>
                                        <div><br>
                                        </div>
                                        <div>on my dom0 machine, i can
                                          ping other machine using eth2,
                                          (implying PF on eth2 is
                                          active)</div>
                                        <div><br>
                                        </div>
                                        <div>on my domU machine, when i
                                          attach the virtual function, i
                                          get the following messages</div>
                                        <div><br>
                                        </div>
                                        <div>
                                          <div><a moz-do-not-send="true"
href="tel:%5B%202282.688356" value="+12282688356" target="_blank">[
                                              2282.688356</a>] ixgbevf
                                            0000:00:00.0: Xen PCI mapped
                                            GSI0 to IRQ28</div>
                                          <div><a moz-do-not-send="true"
href="tel:%5B%202282.688470" value="+12282688470" target="_blank">[
                                              2282.688470</a>] ixgbevf
                                            0000:00:00.0: setting
                                            latency timer to 64</div>
                                          <div><a moz-do-not-send="true"
href="tel:%5B%202282.690187" value="+12282690187" target="_blank">[
                                              2282.690187</a>] ixgbevf
                                            0000:00:00.0: PF still in
                                            reset state, assigning new
                                            address</div>
                                        </div>
                                        <div><br>
                                        </div>
                                        <div>while PF on eth2 is &nbsp;there
                                          and active, since i can ping
                                          other machine.</div>
                                        <div><br>
                                        </div>
                                        <div>Now, when I try to bring up
                                          the VF interface on domU,&nbsp;</div>
                                        <div>&nbsp;i get the following error</div>
                                        <div> <br>
                                        </div>
                                        <div>
                                          <div>&nbsp;2476.295582] Unable to
                                            start - perhaps the PF
                                            Driver isn't up yet</div>
                                          <div>SIOCSIFFLAGS: Network is
                                            down</div>
                                          <div>[ 2476.296917] Unable to
                                            start - perhaps the PF
                                            Driver isn't up yet</div>
                                          <div> SIOCSIFFLAGS: Network is
                                            down</div>
                                        </div>
                                        <div><br>
                                        </div>
                                        <div>and on dmesg on domU,&nbsp;</div>
                                        <div>
                                          <div>[ 2476.295582] Unable to
                                            start - perhaps the PF
                                            Driver isn't up yet</div>
                                          <div>[ 2476.296917] Unable to
                                            start - perhaps the PF
                                            Driver isn't up yet</div>
                                        </div>
                                        <div><br>
                                        </div>
                                        <div><br>
                                        </div>
                                        <div>Any thoughts on what could
                                          be wrong? I have been
                                          struggling with this for quite
                                          some time</div>
                                        <div>and would really appreciate
                                          your thoughts on it.</div>
                                        <div><br>
                                        </div>
                                        <div>Thanks,&nbsp;</div>
                                        <span><font color="#888888">
                                            <div>Ashok</div>
                                            <div><br>
                                            </div>
                                            <div><br>
                                            </div>
                                            <div><br>
                                            </div>
                                            <div><br>
                                            </div>
                                            <div><br>
                                            </div>
                                          </font></span></div>
                                      <br>
                                    </blockquote>
                                    <br>
                                  </div>
                                  <span><font color="#888888">
                                      <pre cols="72">-- 
Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
T: <a moz-do-not-send="true" href="tel:%2B44%20%280%291223%20225%20900" value="+441223225900" target="_blank">+44 (0)1223 225 900</a>, <a moz-do-not-send="true" href="http://www.citrix.com" target="_blank">http://www.citrix.com</a></pre>
                                    </font></span></div>
                                <br>
_______________________________________________<br>
                                Xen-devel mailing list<br>
                                <a moz-do-not-send="true"
                                  href="mailto:Xen-devel@lists.xen.org"
                                  target="_blank">Xen-devel@lists.xen.org</a><br>
                                <a moz-do-not-send="true"
                                  href="http://lists.xen.org/xen-devel"
                                  target="_blank">http://lists.xen.org/xen-devel</a><br>
                                <br>
                              </blockquote>
                            </div>
                            <br>
                          </blockquote>
                          <br>
                          <pre cols="72">-- 
Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
T: <a moz-do-not-send="true" href="tel:%2B44%20%280%291223%20225%20900" value="+441223225900" target="_blank">+44 (0)1223 225 900</a>, <a moz-do-not-send="true" href="http://www.citrix.com" target="_blank">http://www.citrix.com</a></pre>
                        </div>
                      </div>
                    </div>
                  </blockquote>
                </div>
              </div>
            </div>
            <br>
          </blockquote>
        </div>
        <br>
      </div>
    </blockquote>
    <br>
    <pre class="moz-signature" cols="72">-- 
Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
T: +44 (0)1223 225 900, <a class="moz-txt-link-freetext" href="http://www.citrix.com">http://www.citrix.com</a></pre>
  </body>
</html>

--------------030307030407000205090902--


--===============0887041430581390211==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============0887041430581390211==--


From xen-devel-bounces@lists.xen.org Tue Sep 11 09:34:00 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 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 1TBMqk-0001UI-I5; Tue, 11 Sep 2012 09:33:42 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1TBMqi-0001Ty-Tw
	for xen-devel@lists.xen.org; Tue, 11 Sep 2012 09:33:41 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1347355946!2831539!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNzM2MjU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 650 invoked from network); 11 Sep 2012 09:32:28 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Sep 2012 09:32:28 -0000
X-IronPort-AV: E=Sophos;i="4.80,402,1344211200"; 
	d="scan'208,217";a="207690844"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Sep 2012 09:32:26 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Tue, 11 Sep 2012 05:32: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 1TBMpV-00031l-8Y	for
	xen-devel@lists.xen.org; Tue, 11 Sep 2012 10:32:25 +0100
Message-ID: <504F0529.7010204@citrix.com>
Date: Tue, 11 Sep 2012 10:32:25 +0100
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:14.0) Gecko/20120714 Thunderbird/14.0
MIME-Version: 1.0
To: xen-devel@lists.xen.org
References: <CALQsBOWDE_KqpntG8WJo86omLP3+rhQ0LDMW5vB752ubpF1FAA@mail.gmail.com>
	<CALQsBOXFVM+cdhmke5JDJmns2XUpHjyDOVN6R5qrrY9nTOR3SQ@mail.gmail.com>
	<504DC059.4070003@citrix.com>
	<CALQsBOV0EsUY+eYWqtL-FVuTOWOk_MLPnC2CYYPhNU9t=sxt9g@mail.gmail.com>
	<504DC334.6060201@citrix.com>
	<CALQsBOXqT39-ZkOuTT-c58qUW6dihuXWfUi08YzjmgJzaW9YAA@mail.gmail.com>
	<CALQsBOUAv_kPuAjbvyPZs90rGM7ZOBjEctC6iMuf6c+CL+VkDw@mail.gmail.com>
In-Reply-To: <CALQsBOUAv_kPuAjbvyPZs90rGM7ZOBjEctC6iMuf6c+CL+VkDw@mail.gmail.com>
X-Enigmail-Version: 1.4.4
Subject: Re: [Xen-devel] issue using SRIOV "Unable to start - perhaps the PF
 driver is not up yet", while PF driver is actually up
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0887041430581390211=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============0887041430581390211==
Content-Type: multipart/alternative;
	boundary="------------030307030407000205090902"

--------------030307030407000205090902
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit


On 10/09/12 19:32, Ashok Anand wrote:
> Any more thoughts on it? I will really appreciate it.

Sorry - I am debugging a memory corruption issue, so not paying too
close attention to emails.

Have you ensured that the pif is up in dom0 before trying to use a vif?

~Andrew

>
> regards,
> Ashok
>
> On Mon, Sep 10, 2012 at 4:16 PM, Ashok Anand <ashok.anand@gmail.com
> <mailto:ashok.anand@gmail.com>> wrote:
>
>
>     I am passing virtual functions. please see below ,based on the
>     message from lspci. 
>
>         What does lspci -vv for the physical function say?
>
>         As for the physical function: it is unsafe to pass physical
>         functions to a non-trusted guest, as the physical function has
>         complete control over the all the virtual functions, even if
>         they are passed through to other guests.  For that reason, the
>         physical function should remain in dom0 (or a device driver
>         domain if you are going for disaggregation).
>
>
>     here is the message lspci -vv | grep Eth gives me, 
>
>     0f:00.0 Ethernet controller: Intel Corporation 82599EB 10-Gigabit
>     SFI/SFP+ Network Connection (rev 01)
>     Subsystem: Intel Corporation Ethernet Server Adapter X520-2
>     0f:00.1 Ethernet controller: Intel Corporation 82599EB 10-Gigabit
>     SFI/SFP+ Network Connection (rev 01)
>     Subsystem: Intel Corporation Ethernet Server Adapter X520-2
>     0f:10.0 Ethernet controller: Intel Corporation 82599 Ethernet
>     Controller Virtual Function (rev 01)
>     0f:10.2 Ethernet controller: Intel Corporation 82599 Ethernet
>     Controller Virtual Function (rev 01)
>     0f:10.4 Ethernet controller: Intel Corporation 82599 Ethernet
>     Controller Virtual Function (rev 01)
>     0f:10.6 Ethernet controller: Intel Corporation 82599 Ethernet
>     Controller Virtual Function (rev 01)
>     0f:11.0 Ethernet controller: Intel Corporation 82599 Ethernet
>     Controller Virtual Function (rev 01)
>     0f:11.2 Ethernet controller: Intel Corporation 82599 Ethernet
>     Controller Virtual Function (rev 01)
>     0f:11.4 Ethernet controller: Intel Corporation 82599 Ethernet
>     Controller Virtual Function (rev 01)
>     0f:11.6 Ethernet controller: Intel Corporation 82599 Ethernet
>     Controller Virtual Function (rev 01)
>
>     Here, 0f:00.0 is the physical function, while 0f:10.0 and others
>     are virtual functions -- so I am attaching virtual functions. 
>
>
>      
>
>
>
>>
>>
>>
>>>
>>>             i attach 0f:10.0 to a domU ubuntu machine, xm pci-attach
>>>             ubuntu 0f:10.0
>>>
>>>             on my dom0 machine, i can ping other machine using eth2,
>>>             (implying PF on eth2 is active)
>>>
>>>             on my domU machine, when i attach the virtual function,
>>>             i get the following messages
>>>
>>>             [ 2282.688356 <tel:%5B%202282.688356>] ixgbevf
>>>             0000:00:00.0: Xen PCI mapped GSI0 to IRQ28
>>>             [ 2282.688470 <tel:%5B%202282.688470>] ixgbevf
>>>             0000:00:00.0: setting latency timer to 64
>>>             [ 2282.690187 <tel:%5B%202282.690187>] ixgbevf
>>>             0000:00:00.0: PF still in reset state, assigning new address
>>>
>>>             while PF on eth2 is  there and active, since i can ping
>>>             other machine.
>>>
>>>             Now, when I try to bring up the VF interface on domU, 
>>>              i get the following error
>>>
>>>              2476.295582] Unable to start - perhaps the PF Driver
>>>             isn't up yet
>>>             SIOCSIFFLAGS: Network is down
>>>             [ 2476.296917] Unable to start - perhaps the PF Driver
>>>             isn't up yet
>>>             SIOCSIFFLAGS: Network is down
>>>
>>>             and on dmesg on domU, 
>>>             [ 2476.295582] Unable to start - perhaps the PF Driver
>>>             isn't up yet
>>>             [ 2476.296917] Unable to start - perhaps the PF Driver
>>>             isn't up yet
>>>
>>>
>>>             Any thoughts on what could be wrong? I have been
>>>             struggling with this for quite some time
>>>             and would really appreciate your thoughts on it.
>>>
>>>             Thanks, 
>>>             Ashok
>>>
>>>
>>>
>>>
>>>
>>>
>>
>>             -- 
>>             Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
>>             T: +44 (0)1223 225 900 <tel:%2B44%20%280%291223%20225%20900>, http://www.citrix.com
>>
>>
>>             _______________________________________________
>>             Xen-devel mailing list
>>             Xen-devel@lists.xen.org <mailto:Xen-devel@lists.xen.org>
>>             http://lists.xen.org/xen-devel
>>
>>
>
>         -- 
>         Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
>         T: +44 (0)1223 225 900 <tel:%2B44%20%280%291223%20225%20900>, http://www.citrix.com
>
>
>

-- 
Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
T: +44 (0)1223 225 900, http://www.citrix.com


--------------030307030407000205090902
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">
    <br>
    <div class="moz-cite-prefix">On 10/09/12 19:32, Ashok Anand wrote:<br>
    </div>
    <blockquote
cite="mid:CALQsBOUAv_kPuAjbvyPZs90rGM7ZOBjEctC6iMuf6c+CL+VkDw@mail.gmail.com"
      type="cite">Any more thoughts on it? I will really appreciate it.</blockquote>
    <br>
    Sorry - I am debugging a memory corruption issue, so not paying too
    close attention to emails.<br>
    <br>
    Have you ensured that the pif is up in dom0 before trying to use a
    vif?<br>
    <br>
    ~Andrew<br>
    <br>
    <blockquote
cite="mid:CALQsBOUAv_kPuAjbvyPZs90rGM7ZOBjEctC6iMuf6c+CL+VkDw@mail.gmail.com"
      type="cite">
      <div><br>
      </div>
      <div>regards,</div>
      <div>Ashok<br>
        <br>
        <div class="gmail_quote">On Mon, Sep 10, 2012 at 4:16 PM, Ashok
          Anand <span dir="ltr">&lt;<a moz-do-not-send="true"
              href="mailto:ashok.anand@gmail.com" target="_blank">ashok.anand@gmail.com</a>&gt;</span>
          wrote:<br>
          <blockquote class="gmail_quote" style="margin:0 0 0
            .8ex;border-left:1px #ccc solid;padding-left:1ex">
            <div class="gmail_quote">
              <div><br>
              </div>
              <div>I am passing virtual functions. please see below
                ,based on the message from lspci.&nbsp;</div>
              <div class="im">
                <blockquote class="gmail_quote" style="margin:0 0 0
                  .8ex;border-left:1px #ccc solid;padding-left:1ex">
                  <div bgcolor="#FFFFFF" text="#000000">What does lspci
                    -vv for the physical function say?<br>
                    <br>
                    As for the physical function: it is unsafe to pass
                    physical functions to a non-trusted guest, as the
                    physical function has complete control over the all
                    the virtual functions, even if they are passed
                    through to other guests.&nbsp; For that reason, the
                    physical function should remain in dom0 (or a device
                    driver domain if you are going for disaggregation).</div>
                </blockquote>
                <div><br>
                </div>
              </div>
              <div>here is the message lspci -vv | grep Eth gives me,&nbsp;</div>
              <div><br>
              </div>
              <div>
                <div>0f:00.0 Ethernet controller: Intel Corporation
                  82599EB 10-Gigabit SFI/SFP+ Network Connection (rev
                  01)</div>
                <div><span style="white-space:pre-wrap"> </span>Subsystem:
                  Intel Corporation Ethernet Server Adapter X520-2</div>
                <div>0f:00.1 Ethernet controller: Intel Corporation
                  82599EB 10-Gigabit SFI/SFP+ Network Connection (rev
                  01)</div>
                <div><span style="white-space:pre-wrap"> </span>Subsystem:
                  Intel Corporation Ethernet Server Adapter X520-2</div>
                <div>0f:10.0 Ethernet controller: Intel Corporation
                  82599 Ethernet Controller Virtual Function (rev 01)</div>
                <div>0f:10.2 Ethernet controller: Intel Corporation
                  82599 Ethernet Controller Virtual Function (rev 01)</div>
                <div>0f:10.4 Ethernet controller: Intel Corporation
                  82599 Ethernet Controller Virtual Function (rev 01)</div>
                <div>
                  0f:10.6 Ethernet controller: Intel Corporation 82599
                  Ethernet Controller Virtual Function (rev 01)</div>
                <div>0f:11.0 Ethernet controller: Intel Corporation
                  82599 Ethernet Controller Virtual Function (rev 01)</div>
                <div>0f:11.2 Ethernet controller: Intel Corporation
                  82599 Ethernet Controller Virtual Function (rev 01)</div>
                <div>0f:11.4 Ethernet controller: Intel Corporation
                  82599 Ethernet Controller Virtual Function (rev 01)</div>
                <div>0f:11.6 Ethernet controller: Intel Corporation
                  82599 Ethernet Controller Virtual Function (rev 01)</div>
              </div>
              <div><br>
              </div>
              <div>Here, 0f:00.0 is the physical function, while 0f:10.0
                and others are virtual functions -- so I am attaching
                virtual functions.&nbsp;</div>
              <div>
                <div class="h5">
                  <div><br>
                  </div>
                  <div><br>
                  </div>
                  <div>&nbsp;</div>
                  <blockquote class="gmail_quote" style="margin:0 0 0
                    .8ex;border-left:1px #ccc solid;padding-left:1ex">
                    <div bgcolor="#FFFFFF" text="#000000">
                      <div>
                        <div><br>
                          <br>
                          <blockquote type="cite">
                            <div class="gmail_quote">
                              <div><br>
                              </div>
                              <blockquote class="gmail_quote"
                                style="margin:0 0 0 .8ex;border-left:1px
                                #ccc solid;padding-left:1ex">
                                <div bgcolor="#FFFFFF" text="#000000">
                                  <div><br>
                                    <br>
                                    <blockquote type="cite">
                                      <div class="gmail_quote">
                                        <div><br>
                                        </div>
                                        <div>i attach 0f:10.0 to a domU
                                          ubuntu machine,&nbsp;xm pci-attach
                                          ubuntu 0f:10.0</div>
                                        <div><br>
                                        </div>
                                        <div>on my dom0 machine, i can
                                          ping other machine using eth2,
                                          (implying PF on eth2 is
                                          active)</div>
                                        <div><br>
                                        </div>
                                        <div>on my domU machine, when i
                                          attach the virtual function, i
                                          get the following messages</div>
                                        <div><br>
                                        </div>
                                        <div>
                                          <div><a moz-do-not-send="true"
href="tel:%5B%202282.688356" value="+12282688356" target="_blank">[
                                              2282.688356</a>] ixgbevf
                                            0000:00:00.0: Xen PCI mapped
                                            GSI0 to IRQ28</div>
                                          <div><a moz-do-not-send="true"
href="tel:%5B%202282.688470" value="+12282688470" target="_blank">[
                                              2282.688470</a>] ixgbevf
                                            0000:00:00.0: setting
                                            latency timer to 64</div>
                                          <div><a moz-do-not-send="true"
href="tel:%5B%202282.690187" value="+12282690187" target="_blank">[
                                              2282.690187</a>] ixgbevf
                                            0000:00:00.0: PF still in
                                            reset state, assigning new
                                            address</div>
                                        </div>
                                        <div><br>
                                        </div>
                                        <div>while PF on eth2 is &nbsp;there
                                          and active, since i can ping
                                          other machine.</div>
                                        <div><br>
                                        </div>
                                        <div>Now, when I try to bring up
                                          the VF interface on domU,&nbsp;</div>
                                        <div>&nbsp;i get the following error</div>
                                        <div> <br>
                                        </div>
                                        <div>
                                          <div>&nbsp;2476.295582] Unable to
                                            start - perhaps the PF
                                            Driver isn't up yet</div>
                                          <div>SIOCSIFFLAGS: Network is
                                            down</div>
                                          <div>[ 2476.296917] Unable to
                                            start - perhaps the PF
                                            Driver isn't up yet</div>
                                          <div> SIOCSIFFLAGS: Network is
                                            down</div>
                                        </div>
                                        <div><br>
                                        </div>
                                        <div>and on dmesg on domU,&nbsp;</div>
                                        <div>
                                          <div>[ 2476.295582] Unable to
                                            start - perhaps the PF
                                            Driver isn't up yet</div>
                                          <div>[ 2476.296917] Unable to
                                            start - perhaps the PF
                                            Driver isn't up yet</div>
                                        </div>
                                        <div><br>
                                        </div>
                                        <div><br>
                                        </div>
                                        <div>Any thoughts on what could
                                          be wrong? I have been
                                          struggling with this for quite
                                          some time</div>
                                        <div>and would really appreciate
                                          your thoughts on it.</div>
                                        <div><br>
                                        </div>
                                        <div>Thanks,&nbsp;</div>
                                        <span><font color="#888888">
                                            <div>Ashok</div>
                                            <div><br>
                                            </div>
                                            <div><br>
                                            </div>
                                            <div><br>
                                            </div>
                                            <div><br>
                                            </div>
                                            <div><br>
                                            </div>
                                          </font></span></div>
                                      <br>
                                    </blockquote>
                                    <br>
                                  </div>
                                  <span><font color="#888888">
                                      <pre cols="72">-- 
Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
T: <a moz-do-not-send="true" href="tel:%2B44%20%280%291223%20225%20900" value="+441223225900" target="_blank">+44 (0)1223 225 900</a>, <a moz-do-not-send="true" href="http://www.citrix.com" target="_blank">http://www.citrix.com</a></pre>
                                    </font></span></div>
                                <br>
_______________________________________________<br>
                                Xen-devel mailing list<br>
                                <a moz-do-not-send="true"
                                  href="mailto:Xen-devel@lists.xen.org"
                                  target="_blank">Xen-devel@lists.xen.org</a><br>
                                <a moz-do-not-send="true"
                                  href="http://lists.xen.org/xen-devel"
                                  target="_blank">http://lists.xen.org/xen-devel</a><br>
                                <br>
                              </blockquote>
                            </div>
                            <br>
                          </blockquote>
                          <br>
                          <pre cols="72">-- 
Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
T: <a moz-do-not-send="true" href="tel:%2B44%20%280%291223%20225%20900" value="+441223225900" target="_blank">+44 (0)1223 225 900</a>, <a moz-do-not-send="true" href="http://www.citrix.com" target="_blank">http://www.citrix.com</a></pre>
                        </div>
                      </div>
                    </div>
                  </blockquote>
                </div>
              </div>
            </div>
            <br>
          </blockquote>
        </div>
        <br>
      </div>
    </blockquote>
    <br>
    <pre class="moz-signature" cols="72">-- 
Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
T: +44 (0)1223 225 900, <a class="moz-txt-link-freetext" href="http://www.citrix.com">http://www.citrix.com</a></pre>
  </body>
</html>

--------------030307030407000205090902--


--===============0887041430581390211==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============0887041430581390211==--


From xen-devel-bounces@lists.xen.org Tue Sep 11 09:37:39 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 2012 09: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 1TBMuJ-0001hC-CB; Tue, 11 Sep 2012 09:37:23 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony.perard@gmail.com>) id 1TBMuI-0001h1-Bz
	for xen-devel@lists.xen.org; Tue, 11 Sep 2012 09:37:22 +0000
Received: from [85.158.139.83:57525] by server-7.bemta-5.messagelabs.com id
	79/3E-19703-1560F405; Tue, 11 Sep 2012 09:37:21 +0000
X-Env-Sender: anthony.perard@gmail.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1347356239!18501911!1
X-Originating-IP: [209.85.214.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18861 invoked from network); 11 Sep 2012 09:37:21 -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;
	11 Sep 2012 09:37:21 -0000
Received: by obbta14 with SMTP id ta14so571749obb.32
	for <xen-devel@lists.xen.org>; Tue, 11 Sep 2012 02:37:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:from:date
	:x-google-sender-auth:message-id:subject:to:cc:content-type;
	bh=srFw/mjKhwEd52EXKGQaYvRZMLIT0ANFAsTszmovKRw=;
	b=sF5B5wBWV57hXFw6zMJsAbrq63MVvPNairCtjAkMO4B1J2Iff/0/6gnWQ7x8OYW0Ze
	HLSDXrqhl0/kist4gs4GhV2IBJyW104kfpSp/hCXCjFXoMV1kDjWq9Tz6+oCy7/rSZ4d
	hsrcdx3bpnYuAO7MmAHauNkNIxYficqyez8Dtohd+ch3/jzx0TriAlW++ATzr50alPMt
	S1t8CG5ePoJXivSpf85K6HPr9rFCzkdgw7NgaPYDm0tQNnJtmkZnvYbLK7a7QkQDLOdM
	M2wHCETeMv+ett5g6vGcdfhdrWx+sRXtaf7DTip47z5t0W3pqQW0GbVHyhuRgZqm3tMn
	PW5g==
Received: by 10.60.2.134 with SMTP id 6mr17071374oeu.62.1347356239575; Tue, 11
	Sep 2012 02:37:19 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.60.97.36 with HTTP; Tue, 11 Sep 2012 02:36:49 -0700 (PDT)
In-Reply-To: <CAOvdn6XrvxvHr7GGsk02YZcN6EO5hpYuPuBVqv5VUtPGjB-82g@mail.gmail.com>
References: <502E212E.6070306@citrix.com>
	<CAOvdn6WD31pQVbZNSMc8JTKfNQKOEWUkHpvpqPq=kcAUBC5QHQ@mail.gmail.com>
	<CAJJyHjJe3fV8LzKNqJVW58Ngk3HGE+GA0rOGA7zU-tzTX0rNtQ@mail.gmail.com>
	<CAOvdn6XrvxvHr7GGsk02YZcN6EO5hpYuPuBVqv5VUtPGjB-82g@mail.gmail.com>
From: Anthony PERARD <anthony.perard@citrix.com>
Date: Tue, 11 Sep 2012 10:36:49 +0100
X-Google-Sender-Auth: Vd5Lnr1gaxT8f1JVOvg5WitEdf0
Message-ID: <CAJJyHj+Q4LQjXUne1mXyHn=WKrU9copL7CnCoyH9vcT__V8U7Q@mail.gmail.com>
To: Ben Guthro <ben@guthro.net>
Cc: Xen Devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [ANNOUNCE] Git mirror of Xen repositories available
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Sep 11, 2012 at 9:30 AM, Ben Guthro <ben@guthro.net> wrote:
> I don't see them after doing a "git fetch --all" - and they don't appear to
> be visible via gitweb here:
> http://xenbits.xen.org/gitweb/?p=xen.git;a=summary
> nor here:
> http://xenbits.xen.org/gitweb/?p=people/aperard/xen.git;a=summary
>
> Is it possible you forgot to push something?

Yes, I forgot to do one thing ... But now it's fixed and both new
branches are here.

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 Tue Sep 11 09:37:39 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 2012 09: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 1TBMuJ-0001hC-CB; Tue, 11 Sep 2012 09:37:23 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony.perard@gmail.com>) id 1TBMuI-0001h1-Bz
	for xen-devel@lists.xen.org; Tue, 11 Sep 2012 09:37:22 +0000
Received: from [85.158.139.83:57525] by server-7.bemta-5.messagelabs.com id
	79/3E-19703-1560F405; Tue, 11 Sep 2012 09:37:21 +0000
X-Env-Sender: anthony.perard@gmail.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1347356239!18501911!1
X-Originating-IP: [209.85.214.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18861 invoked from network); 11 Sep 2012 09:37:21 -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;
	11 Sep 2012 09:37:21 -0000
Received: by obbta14 with SMTP id ta14so571749obb.32
	for <xen-devel@lists.xen.org>; Tue, 11 Sep 2012 02:37:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:from:date
	:x-google-sender-auth:message-id:subject:to:cc:content-type;
	bh=srFw/mjKhwEd52EXKGQaYvRZMLIT0ANFAsTszmovKRw=;
	b=sF5B5wBWV57hXFw6zMJsAbrq63MVvPNairCtjAkMO4B1J2Iff/0/6gnWQ7x8OYW0Ze
	HLSDXrqhl0/kist4gs4GhV2IBJyW104kfpSp/hCXCjFXoMV1kDjWq9Tz6+oCy7/rSZ4d
	hsrcdx3bpnYuAO7MmAHauNkNIxYficqyez8Dtohd+ch3/jzx0TriAlW++ATzr50alPMt
	S1t8CG5ePoJXivSpf85K6HPr9rFCzkdgw7NgaPYDm0tQNnJtmkZnvYbLK7a7QkQDLOdM
	M2wHCETeMv+ett5g6vGcdfhdrWx+sRXtaf7DTip47z5t0W3pqQW0GbVHyhuRgZqm3tMn
	PW5g==
Received: by 10.60.2.134 with SMTP id 6mr17071374oeu.62.1347356239575; Tue, 11
	Sep 2012 02:37:19 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.60.97.36 with HTTP; Tue, 11 Sep 2012 02:36:49 -0700 (PDT)
In-Reply-To: <CAOvdn6XrvxvHr7GGsk02YZcN6EO5hpYuPuBVqv5VUtPGjB-82g@mail.gmail.com>
References: <502E212E.6070306@citrix.com>
	<CAOvdn6WD31pQVbZNSMc8JTKfNQKOEWUkHpvpqPq=kcAUBC5QHQ@mail.gmail.com>
	<CAJJyHjJe3fV8LzKNqJVW58Ngk3HGE+GA0rOGA7zU-tzTX0rNtQ@mail.gmail.com>
	<CAOvdn6XrvxvHr7GGsk02YZcN6EO5hpYuPuBVqv5VUtPGjB-82g@mail.gmail.com>
From: Anthony PERARD <anthony.perard@citrix.com>
Date: Tue, 11 Sep 2012 10:36:49 +0100
X-Google-Sender-Auth: Vd5Lnr1gaxT8f1JVOvg5WitEdf0
Message-ID: <CAJJyHj+Q4LQjXUne1mXyHn=WKrU9copL7CnCoyH9vcT__V8U7Q@mail.gmail.com>
To: Ben Guthro <ben@guthro.net>
Cc: Xen Devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [ANNOUNCE] Git mirror of Xen repositories available
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Sep 11, 2012 at 9:30 AM, Ben Guthro <ben@guthro.net> wrote:
> I don't see them after doing a "git fetch --all" - and they don't appear to
> be visible via gitweb here:
> http://xenbits.xen.org/gitweb/?p=xen.git;a=summary
> nor here:
> http://xenbits.xen.org/gitweb/?p=people/aperard/xen.git;a=summary
>
> Is it possible you forgot to push something?

Yes, I forgot to do one thing ... But now it's fixed and both new
branches are here.

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 Tue Sep 11 09:43:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 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 1TBMzX-0001s7-4P; Tue, 11 Sep 2012 09:42:47 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1TBMzV-0001s2-Ml
	for xen-devel@lists.xen.org; Tue, 11 Sep 2012 09:42:45 +0000
Received: from [85.158.139.83:16147] by server-2.bemta-5.messagelabs.com id
	AF/0C-11456-4970F405; Tue, 11 Sep 2012 09:42:44 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1347356564!22567299!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQwNzc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9126 invoked from network); 11 Sep 2012 09:42:44 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-11.tower-182.messagelabs.com with SMTP;
	11 Sep 2012 09:42:44 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 11 Sep 2012 10:42:43 +0100
Message-Id: <504F23B2020000780009A79B@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 11 Sep 2012 10:42:42 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "DuanZhenzhong" <zhenzhong.duan@oracle.com>
References: <504764270200007800098DE1@nat28.tlf.novell.com>
	<504A01790200007800099C52@nat28.tlf.novell.com>
	<504F1412020000780009A750@nat28.tlf.novell.com>
	<504F01D6.3050903@oracle.com>
In-Reply-To: <504F01D6.3050903@oracle.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: dan.magenheimer@oracle.com, Ian Campbell <ian.campbell@citrix.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Ping: [PATCH 09/11,
 v2] tmem: reduce severity of log messages
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 11.09.12 at 11:18, DuanZhenzhong <zhenzhong.duan@oracle.com> wrote:
> Dan is offline recently.
> What about 'printk("tmem_relinquish_page: failing order=%d\n", order)', 
> more like a  guest level msg.

That's debatable, but the message is enabled for debug builds
only anyway. Could be make XENLOG_DEBUG, but that would
require yet another helper in tmem_xen.h. I'd want to leave
this alone for the moment.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 11 09:43:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 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 1TBMzX-0001s7-4P; Tue, 11 Sep 2012 09:42:47 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1TBMzV-0001s2-Ml
	for xen-devel@lists.xen.org; Tue, 11 Sep 2012 09:42:45 +0000
Received: from [85.158.139.83:16147] by server-2.bemta-5.messagelabs.com id
	AF/0C-11456-4970F405; Tue, 11 Sep 2012 09:42:44 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1347356564!22567299!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQwNzc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9126 invoked from network); 11 Sep 2012 09:42:44 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-11.tower-182.messagelabs.com with SMTP;
	11 Sep 2012 09:42:44 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 11 Sep 2012 10:42:43 +0100
Message-Id: <504F23B2020000780009A79B@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 11 Sep 2012 10:42:42 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "DuanZhenzhong" <zhenzhong.duan@oracle.com>
References: <504764270200007800098DE1@nat28.tlf.novell.com>
	<504A01790200007800099C52@nat28.tlf.novell.com>
	<504F1412020000780009A750@nat28.tlf.novell.com>
	<504F01D6.3050903@oracle.com>
In-Reply-To: <504F01D6.3050903@oracle.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: dan.magenheimer@oracle.com, Ian Campbell <ian.campbell@citrix.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Ping: [PATCH 09/11,
 v2] tmem: reduce severity of log messages
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 11.09.12 at 11:18, DuanZhenzhong <zhenzhong.duan@oracle.com> wrote:
> Dan is offline recently.
> What about 'printk("tmem_relinquish_page: failing order=%d\n", order)', 
> more like a  guest level msg.

That's debatable, but the message is enabled for debug builds
only anyway. Could be make XENLOG_DEBUG, but that would
require yet another helper in tmem_xen.h. I'd want to leave
this alone for the moment.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 11 10:00:43 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 2012 10:00:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TBNGW-00026F-OV; Tue, 11 Sep 2012 10:00:20 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <zhenzhong.duan@oracle.com>) id 1TBNGV-00026A-T3
	for xen-devel@lists.xen.org; Tue, 11 Sep 2012 10:00:20 +0000
Received: from [85.158.139.83:42048] by server-12.bemta-5.messagelabs.com id
	81/5A-18300-3BB0F405; Tue, 11 Sep 2012 10:00:19 +0000
X-Env-Sender: zhenzhong.duan@oracle.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1347357615!18508546!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzMyNjc3\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20271 invoked from network); 11 Sep 2012 10:00:16 -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; 11 Sep 2012 10:00:16 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q8BA0Bic003513
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 11 Sep 2012 10:00:12 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q8BA0BkH008587
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 11 Sep 2012 10:00:11 GMT
Received: from abhmt104.oracle.com (abhmt104.oracle.com [141.146.116.56])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q8BA0Baq003397; Tue, 11 Sep 2012 05:00:11 -0500
Received: from zhenzhong2.localdomain (/10.182.39.88)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 11 Sep 2012 03:00:10 -0700
Message-ID: <504F0C0C.6020804@oracle.com>
Date: Tue, 11 Sep 2012 18:01:48 +0800
From: DuanZhenzhong <zhenzhong.duan@oracle.com>
Organization: Oracle Corporation
User-Agent: Thunderbird 2.0.0.24 (X11/20101209)
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <504764270200007800098DE1@nat28.tlf.novell.com>
	<504A01790200007800099C52@nat28.tlf.novell.com>
	<504F1412020000780009A750@nat28.tlf.novell.com>
	<504F01D6.3050903@oracle.com>
	<504F23B2020000780009A79B@nat28.tlf.novell.com>
In-Reply-To: <504F23B2020000780009A79B@nat28.tlf.novell.com>
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: dan.magenheimer@oracle.com, Ian Campbell <ian.campbell@citrix.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Ping: [PATCH 09/11,
	v2] tmem: reduce severity of log messages
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Jan Beulich wrote:
>>>> On 11.09.12 at 11:18, DuanZhenzhong <zhenzhong.duan@oracle.com> wrote:
>>>>         
>> Dan is offline recently.
>> What about 'printk("tmem_relinquish_page: failing order=%d\n", order)', 
>> more like a  guest level msg.
>>     
>
> That's debatable, but the message is enabled for debug builds
> only anyway. Could be make XENLOG_DEBUG, but that would
> require yet another helper in tmem_xen.h. I'd want to leave
> this alone for the moment.
Ok.
zduan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 11 10:00:43 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 2012 10:00:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TBNGW-00026F-OV; Tue, 11 Sep 2012 10:00:20 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <zhenzhong.duan@oracle.com>) id 1TBNGV-00026A-T3
	for xen-devel@lists.xen.org; Tue, 11 Sep 2012 10:00:20 +0000
Received: from [85.158.139.83:42048] by server-12.bemta-5.messagelabs.com id
	81/5A-18300-3BB0F405; Tue, 11 Sep 2012 10:00:19 +0000
X-Env-Sender: zhenzhong.duan@oracle.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1347357615!18508546!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzMyNjc3\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20271 invoked from network); 11 Sep 2012 10:00:16 -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; 11 Sep 2012 10:00:16 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q8BA0Bic003513
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 11 Sep 2012 10:00:12 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q8BA0BkH008587
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 11 Sep 2012 10:00:11 GMT
Received: from abhmt104.oracle.com (abhmt104.oracle.com [141.146.116.56])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q8BA0Baq003397; Tue, 11 Sep 2012 05:00:11 -0500
Received: from zhenzhong2.localdomain (/10.182.39.88)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 11 Sep 2012 03:00:10 -0700
Message-ID: <504F0C0C.6020804@oracle.com>
Date: Tue, 11 Sep 2012 18:01:48 +0800
From: DuanZhenzhong <zhenzhong.duan@oracle.com>
Organization: Oracle Corporation
User-Agent: Thunderbird 2.0.0.24 (X11/20101209)
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <504764270200007800098DE1@nat28.tlf.novell.com>
	<504A01790200007800099C52@nat28.tlf.novell.com>
	<504F1412020000780009A750@nat28.tlf.novell.com>
	<504F01D6.3050903@oracle.com>
	<504F23B2020000780009A79B@nat28.tlf.novell.com>
In-Reply-To: <504F23B2020000780009A79B@nat28.tlf.novell.com>
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: dan.magenheimer@oracle.com, Ian Campbell <ian.campbell@citrix.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Ping: [PATCH 09/11,
	v2] tmem: reduce severity of log messages
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Jan Beulich wrote:
>>>> On 11.09.12 at 11:18, DuanZhenzhong <zhenzhong.duan@oracle.com> wrote:
>>>>         
>> Dan is offline recently.
>> What about 'printk("tmem_relinquish_page: failing order=%d\n", order)', 
>> more like a  guest level msg.
>>     
>
> That's debatable, but the message is enabled for debug builds
> only anyway. Could be make XENLOG_DEBUG, but that would
> require yet another helper in tmem_xen.h. I'd want to leave
> this alone for the moment.
Ok.
zduan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 11 10:05:35 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 2012 10:05:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TBNLI-0002K0-Fu; Tue, 11 Sep 2012 10:05:16 +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 1TBNLG-0002Jv-Mv
	for xen-devel@lists.xen.org; Tue, 11 Sep 2012 10:05:15 +0000
Received: from [85.158.138.51:30255] by server-12.bemta-3.messagelabs.com id
	20/D3-10384-9DC0F405; Tue, 11 Sep 2012 10:05:13 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-11.tower-174.messagelabs.com!1347357911!29855650!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA0OTYyMDY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27903 invoked from network); 11 Sep 2012 10:05:12 -0000
Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25)
	by server-11.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 11 Sep 2012 10:05: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 68D8D2314;
	Tue, 11 Sep 2012 13:05:11 +0300 (EEST)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id CEE362005D; Tue, 11 Sep 2012 13:05:10 +0300 (EEST)
Date: Tue, 11 Sep 2012 13:05:10 +0300
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Message-ID: <20120911100510.GP8912@reaktio.net>
References: <CALQsBOWDE_KqpntG8WJo86omLP3+rhQ0LDMW5vB752ubpF1FAA@mail.gmail.com>
	<CALQsBOXFVM+cdhmke5JDJmns2XUpHjyDOVN6R5qrrY9nTOR3SQ@mail.gmail.com>
	<504DC059.4070003@citrix.com>
	<CALQsBOV0EsUY+eYWqtL-FVuTOWOk_MLPnC2CYYPhNU9t=sxt9g@mail.gmail.com>
	<504DC334.6060201@citrix.com>
	<CALQsBOXqT39-ZkOuTT-c58qUW6dihuXWfUi08YzjmgJzaW9YAA@mail.gmail.com>
	<CALQsBOUAv_kPuAjbvyPZs90rGM7ZOBjEctC6iMuf6c+CL+VkDw@mail.gmail.com>
	<504F0529.7010204@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <504F0529.7010204@citrix.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] issue using SRIOV "Unable to start - perhaps the PF
 driver is not up yet", while PF driver is actually up
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Sep 11, 2012 at 10:32:25AM +0100, Andrew Cooper wrote:
>    On 10/09/12 19:32, Ashok Anand wrote:
> 
>      Any more thoughts on it? I will really appreciate it.
> 
>    Sorry - I am debugging a memory corruption issue, so not paying too close
>    attention to emails.
> 
>    Have you ensured that the pif is up in dom0 before trying to use a vif?
> 

Yes, "ifconfig ethX up" for the PF is required in dom0 before the VF works in the VM.

-- Pasi

>    ~Andrew
> 
>      regards,
>      Ashok
> 
>      On Mon, Sep 10, 2012 at 4:16 PM, Ashok Anand <[1]ashok.anand@gmail.com>
>      wrote:
> 
>        I am passing virtual functions. please see below ,based on the message
>        from lspci.
> 
>          What does lspci -vv for the physical function say?
> 
>          As for the physical function: it is unsafe to pass physical
>          functions to a non-trusted guest, as the physical function has
>          complete control over the all the virtual functions, even if they
>          are passed through to other guests.  For that reason, the physical
>          function should remain in dom0 (or a device driver domain if you are
>          going for disaggregation).
> 
>        here is the message lspci -vv | grep Eth gives me,
>        0f:00.0 Ethernet controller: Intel Corporation 82599EB 10-Gigabit
>        SFI/SFP+ Network Connection (rev 01)
>        Subsystem: Intel Corporation Ethernet Server Adapter X520-2
>        0f:00.1 Ethernet controller: Intel Corporation 82599EB 10-Gigabit
>        SFI/SFP+ Network Connection (rev 01)
>        Subsystem: Intel Corporation Ethernet Server Adapter X520-2
>        0f:10.0 Ethernet controller: Intel Corporation 82599 Ethernet
>        Controller Virtual Function (rev 01)
>        0f:10.2 Ethernet controller: Intel Corporation 82599 Ethernet
>        Controller Virtual Function (rev 01)
>        0f:10.4 Ethernet controller: Intel Corporation 82599 Ethernet
>        Controller Virtual Function (rev 01)
>        0f:10.6 Ethernet controller: Intel Corporation 82599 Ethernet
>        Controller Virtual Function (rev 01)
>        0f:11.0 Ethernet controller: Intel Corporation 82599 Ethernet
>        Controller Virtual Function (rev 01)
>        0f:11.2 Ethernet controller: Intel Corporation 82599 Ethernet
>        Controller Virtual Function (rev 01)
>        0f:11.4 Ethernet controller: Intel Corporation 82599 Ethernet
>        Controller Virtual Function (rev 01)
>        0f:11.6 Ethernet controller: Intel Corporation 82599 Ethernet
>        Controller Virtual Function (rev 01)
>        Here, 0f:00.0 is the physical function, while 0f:10.0 and others are
>        virtual functions -- so I am attaching virtual functions.
> 
> 
>                i attach 0f:10.0 to a domU ubuntu machine, xm pci-attach
>                ubuntu 0f:10.0
>                on my dom0 machine, i can ping other machine using eth2,
>                (implying PF on eth2 is active)
>                on my domU machine, when i attach the virtual function, i get
>                the following messages
>                [2][ 2282.688356] ixgbevf 0000:00:00.0: Xen PCI mapped GSI0 to
>                IRQ28
>                [3][ 2282.688470] ixgbevf 0000:00:00.0: setting latency timer
>                to 64
>                [4][ 2282.690187] ixgbevf 0000:00:00.0: PF still in reset
>                state, assigning new address
>                while PF on eth2 is  there and active, since i can ping other
>                machine.
>                Now, when I try to bring up the VF interface on domU,
>                 i get the following error
>                 2476.295582] Unable to start - perhaps the PF Driver isn't up
>                yet
>                SIOCSIFFLAGS: Network is down
>                [ 2476.296917] Unable to start - perhaps the PF Driver isn't
>                up yet
>                SIOCSIFFLAGS: Network is down
>                and on dmesg on domU,
>                [ 2476.295582] Unable to start - perhaps the PF Driver isn't
>                up yet
>                [ 2476.296917] Unable to start - perhaps the PF Driver isn't
>                up yet
>                Any thoughts on what could be wrong? I have been struggling
>                with this for quite some time
>                and would really appreciate your thoughts on it.
>                Thanks,
>                Ashok
> 
>  --
>  Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
>  T: [5]+44 (0)1223 225 900, [6]http://www.citrix.com
> 
>              _______________________________________________
>              Xen-devel mailing list
>              [7]Xen-devel@lists.xen.org
>              [8]http://lists.xen.org/xen-devel
> 
>  --
>  Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
>  T: [9]+44 (0)1223 225 900, [10]http://www.citrix.com
> 
>  --
>  Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
>  T: +44 (0)1223 225 900, [11]http://www.citrix.com
> 
> References
> 
>    Visible links
>    1. mailto:ashok.anand@gmail.com
>    2. file:///tmp/tel:%5B%202282.688356
>    3. file:///tmp/tel:%5B%202282.688470
>    4. file:///tmp/tel:%5B%202282.690187
>    5. file:///tmp/tel:%2B44%20%280%291223%20225%20900
>    6. http://www.citrix.com/
>    7. mailto:Xen-devel@lists.xen.org
>    8. http://lists.xen.org/xen-devel
>    9. file:///tmp/tel:%2B44%20%280%291223%20225%20900
>   10. http://www.citrix.com/
>   11. http://www.citrix.com/

> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 11 10:05:35 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 2012 10:05:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TBNLI-0002K0-Fu; Tue, 11 Sep 2012 10:05:16 +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 1TBNLG-0002Jv-Mv
	for xen-devel@lists.xen.org; Tue, 11 Sep 2012 10:05:15 +0000
Received: from [85.158.138.51:30255] by server-12.bemta-3.messagelabs.com id
	20/D3-10384-9DC0F405; Tue, 11 Sep 2012 10:05:13 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-11.tower-174.messagelabs.com!1347357911!29855650!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA0OTYyMDY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27903 invoked from network); 11 Sep 2012 10:05:12 -0000
Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25)
	by server-11.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 11 Sep 2012 10:05: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 68D8D2314;
	Tue, 11 Sep 2012 13:05:11 +0300 (EEST)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id CEE362005D; Tue, 11 Sep 2012 13:05:10 +0300 (EEST)
Date: Tue, 11 Sep 2012 13:05:10 +0300
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Message-ID: <20120911100510.GP8912@reaktio.net>
References: <CALQsBOWDE_KqpntG8WJo86omLP3+rhQ0LDMW5vB752ubpF1FAA@mail.gmail.com>
	<CALQsBOXFVM+cdhmke5JDJmns2XUpHjyDOVN6R5qrrY9nTOR3SQ@mail.gmail.com>
	<504DC059.4070003@citrix.com>
	<CALQsBOV0EsUY+eYWqtL-FVuTOWOk_MLPnC2CYYPhNU9t=sxt9g@mail.gmail.com>
	<504DC334.6060201@citrix.com>
	<CALQsBOXqT39-ZkOuTT-c58qUW6dihuXWfUi08YzjmgJzaW9YAA@mail.gmail.com>
	<CALQsBOUAv_kPuAjbvyPZs90rGM7ZOBjEctC6iMuf6c+CL+VkDw@mail.gmail.com>
	<504F0529.7010204@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <504F0529.7010204@citrix.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] issue using SRIOV "Unable to start - perhaps the PF
 driver is not up yet", while PF driver is actually up
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Sep 11, 2012 at 10:32:25AM +0100, Andrew Cooper wrote:
>    On 10/09/12 19:32, Ashok Anand wrote:
> 
>      Any more thoughts on it? I will really appreciate it.
> 
>    Sorry - I am debugging a memory corruption issue, so not paying too close
>    attention to emails.
> 
>    Have you ensured that the pif is up in dom0 before trying to use a vif?
> 

Yes, "ifconfig ethX up" for the PF is required in dom0 before the VF works in the VM.

-- Pasi

>    ~Andrew
> 
>      regards,
>      Ashok
> 
>      On Mon, Sep 10, 2012 at 4:16 PM, Ashok Anand <[1]ashok.anand@gmail.com>
>      wrote:
> 
>        I am passing virtual functions. please see below ,based on the message
>        from lspci.
> 
>          What does lspci -vv for the physical function say?
> 
>          As for the physical function: it is unsafe to pass physical
>          functions to a non-trusted guest, as the physical function has
>          complete control over the all the virtual functions, even if they
>          are passed through to other guests.  For that reason, the physical
>          function should remain in dom0 (or a device driver domain if you are
>          going for disaggregation).
> 
>        here is the message lspci -vv | grep Eth gives me,
>        0f:00.0 Ethernet controller: Intel Corporation 82599EB 10-Gigabit
>        SFI/SFP+ Network Connection (rev 01)
>        Subsystem: Intel Corporation Ethernet Server Adapter X520-2
>        0f:00.1 Ethernet controller: Intel Corporation 82599EB 10-Gigabit
>        SFI/SFP+ Network Connection (rev 01)
>        Subsystem: Intel Corporation Ethernet Server Adapter X520-2
>        0f:10.0 Ethernet controller: Intel Corporation 82599 Ethernet
>        Controller Virtual Function (rev 01)
>        0f:10.2 Ethernet controller: Intel Corporation 82599 Ethernet
>        Controller Virtual Function (rev 01)
>        0f:10.4 Ethernet controller: Intel Corporation 82599 Ethernet
>        Controller Virtual Function (rev 01)
>        0f:10.6 Ethernet controller: Intel Corporation 82599 Ethernet
>        Controller Virtual Function (rev 01)
>        0f:11.0 Ethernet controller: Intel Corporation 82599 Ethernet
>        Controller Virtual Function (rev 01)
>        0f:11.2 Ethernet controller: Intel Corporation 82599 Ethernet
>        Controller Virtual Function (rev 01)
>        0f:11.4 Ethernet controller: Intel Corporation 82599 Ethernet
>        Controller Virtual Function (rev 01)
>        0f:11.6 Ethernet controller: Intel Corporation 82599 Ethernet
>        Controller Virtual Function (rev 01)
>        Here, 0f:00.0 is the physical function, while 0f:10.0 and others are
>        virtual functions -- so I am attaching virtual functions.
> 
> 
>                i attach 0f:10.0 to a domU ubuntu machine, xm pci-attach
>                ubuntu 0f:10.0
>                on my dom0 machine, i can ping other machine using eth2,
>                (implying PF on eth2 is active)
>                on my domU machine, when i attach the virtual function, i get
>                the following messages
>                [2][ 2282.688356] ixgbevf 0000:00:00.0: Xen PCI mapped GSI0 to
>                IRQ28
>                [3][ 2282.688470] ixgbevf 0000:00:00.0: setting latency timer
>                to 64
>                [4][ 2282.690187] ixgbevf 0000:00:00.0: PF still in reset
>                state, assigning new address
>                while PF on eth2 is  there and active, since i can ping other
>                machine.
>                Now, when I try to bring up the VF interface on domU,
>                 i get the following error
>                 2476.295582] Unable to start - perhaps the PF Driver isn't up
>                yet
>                SIOCSIFFLAGS: Network is down
>                [ 2476.296917] Unable to start - perhaps the PF Driver isn't
>                up yet
>                SIOCSIFFLAGS: Network is down
>                and on dmesg on domU,
>                [ 2476.295582] Unable to start - perhaps the PF Driver isn't
>                up yet
>                [ 2476.296917] Unable to start - perhaps the PF Driver isn't
>                up yet
>                Any thoughts on what could be wrong? I have been struggling
>                with this for quite some time
>                and would really appreciate your thoughts on it.
>                Thanks,
>                Ashok
> 
>  --
>  Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
>  T: [5]+44 (0)1223 225 900, [6]http://www.citrix.com
> 
>              _______________________________________________
>              Xen-devel mailing list
>              [7]Xen-devel@lists.xen.org
>              [8]http://lists.xen.org/xen-devel
> 
>  --
>  Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
>  T: [9]+44 (0)1223 225 900, [10]http://www.citrix.com
> 
>  --
>  Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
>  T: +44 (0)1223 225 900, [11]http://www.citrix.com
> 
> References
> 
>    Visible links
>    1. mailto:ashok.anand@gmail.com
>    2. file:///tmp/tel:%5B%202282.688356
>    3. file:///tmp/tel:%5B%202282.688470
>    4. file:///tmp/tel:%5B%202282.690187
>    5. file:///tmp/tel:%2B44%20%280%291223%20225%20900
>    6. http://www.citrix.com/
>    7. mailto:Xen-devel@lists.xen.org
>    8. http://lists.xen.org/xen-devel
>    9. file:///tmp/tel:%2B44%20%280%291223%20225%20900
>   10. http://www.citrix.com/
>   11. http://www.citrix.com/

> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 11 10:11:59 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 2012 10:11:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TBNRR-0002UJ-AS; Tue, 11 Sep 2012 10:11:37 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1TBNRP-0002UE-1h
	for xen-devel@lists.xen.org; Tue, 11 Sep 2012 10:11:35 +0000
Received: from [85.158.139.83:39327] by server-3.bemta-5.messagelabs.com id
	43/40-21836-65E0F405; Tue, 11 Sep 2012 10:11:34 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1347358292!25847144!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQwNzc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30860 invoked from network); 11 Sep 2012 10:11:33 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-7.tower-182.messagelabs.com with SMTP;
	11 Sep 2012 10:11:33 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 11 Sep 2012 11:11:31 +0100
Message-Id: <504F2A71020000780009A7ED@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 11 Sep 2012 11:11:29 +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 RFC 0/8] console improvements
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This series adds support for an EHCI debug port based console, and
does some other improvements and cleanup noticed to be desirable
during the implementation of the former as follow-up.

1: x86: allow early use of fixmaps
2: console: prepare for non-COMn port support
3: console: add EHCI debug port based serial console
4: serial: avoid fully initializing unused consoles
5: ns16550: MMIO adjustments
6: ns16550: PCI initialization adjustments
7: ns16550: command line parsing adjustments
8: drop tx_fifo_size

Note that this also requires a Dom0 kernel side enhancement,
which I'm reproducing below for reference (intending to submit
this only when the public interface change on the hypervisor
side is approved, which in turn will take its time due to the
current feature freeze).

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/drivers/usb/early/ehci-dbgp.c
+++ b/drivers/usb/early/ehci-dbgp.c
@@ -491,7 +491,7 @@ static int ehci_wait_for_port(int port);
  * Return -ENODEV for any general failure
  * Return -EIO if wait for port fails
  */
-int dbgp_external_startup(void)
+static int _dbgp_external_startup(void)
 {
 	int devnum;
 	struct usb_debug_descriptor dbgp_desc;
@@ -613,6 +613,11 @@ err:
 		goto try_again;
 	return -ENODEV;
 }
+
+int dbgp_external_startup(struct usb_hcd *hcd)
+{
+	return xen_dbgp_external_startup(hcd) ?: _dbgp_external_startup();
+}
 EXPORT_SYMBOL_GPL(dbgp_external_startup);
 
 static int ehci_reset_port(int port)
@@ -804,7 +809,7 @@ try_next_port:
 		dbgp_ehci_status("ehci skip - already configured");
 	}
 
-	ret = dbgp_external_startup();
+	ret = _dbgp_external_startup();
 	if (ret == -EIO)
 		goto next_debug_port;
 
@@ -934,7 +939,7 @@ static void early_dbgp_write(struct cons
 		ctrl = readl(&ehci_debug->control);
 		if (!(ctrl & DBGP_ENABLED)) {
 			dbgp_not_safe = 1;
-			dbgp_external_startup();
+			_dbgp_external_startup();
 		} else {
 			cmd |= CMD_RUN;
 			writel(cmd, &ehci_regs->command);
@@ -974,10 +979,14 @@ struct console early_dbgp_console = {
 	.index =	-1,
 };
 
-int dbgp_reset_prep(void)
+int dbgp_reset_prep(struct usb_hcd *hcd)
 {
+	int ret = xen_dbgp_reset_prep(hcd);
 	u32 ctrl;
 
+	if (ret)
+		return ret;
+
 	dbgp_not_safe = 1;
 	if (!ehci_debug)
 		return 0;
--- a/drivers/usb/host/ehci-hcd.c
+++ b/drivers/usb/host/ehci-hcd.c
@@ -321,7 +321,7 @@ static int ehci_reset (struct ehci_hcd *
 
 	/* If the EHCI debug controller is active, special care must be
 	 * taken before and after a host controller reset */
-	if (ehci->debug && !dbgp_reset_prep())
+	if (ehci->debug && !dbgp_reset_prep(ehci_to_hcd(ehci)))
 		ehci->debug = NULL;
 
 	command |= CMD_RESET;
@@ -345,7 +345,7 @@ static int ehci_reset (struct ehci_hcd *
 		tdi_reset (ehci);
 
 	if (ehci->debug)
-		dbgp_external_startup();
+		dbgp_external_startup(ehci_to_hcd(ehci));
 
 	ehci->port_c_suspend = ehci->suspended_ports =
 			ehci->resuming_ports = 0;
--- a/drivers/usb/host/ehci-hub.c
+++ b/drivers/usb/host/ehci-hub.c
@@ -347,10 +347,10 @@ static int ehci_bus_resume (struct usb_h
 	}
 
 	if (unlikely(ehci->debug)) {
-		if (!dbgp_reset_prep())
+		if (!dbgp_reset_prep(hcd))
 			ehci->debug = NULL;
 		else
-			dbgp_external_startup();
+			dbgp_external_startup(hcd);
 	}
 
 	/* Ideally and we've got a real resume here, and no port's power
--- a/drivers/xen/Makefile
+++ b/drivers/xen/Makefile
@@ -21,6 +21,7 @@ CFLAGS_features.o			:= $(nostackp)
 endif
 
 priv-$(CONFIG_PCI)			:= pci.o
+priv-$(CONFIG_USB_SUPPORT)		+= dbgp.o
 
 obj-$(CONFIG_XEN)			+= features.o $(xen-backend-y) $(xen-backend-m)
 obj-$(CONFIG_XEN_PRIVILEGED_GUEST)	+= $(priv-y)
@@ -37,7 +38,7 @@ obj-$(CONFIG_XEN_SYS_HYPERVISOR)	+= sys-
 obj-$(CONFIG_XEN_PVHVM)			+= platform-pci.o
 obj-$(CONFIG_XEN_TMEM)			+= tmem.o
 obj-$(CONFIG_SWIOTLB_XEN)		+= swiotlb-xen.o
-obj-$(CONFIG_XEN_DOM0)			+= pci.o
+obj-$(CONFIG_XEN_DOM0)			+= pci.o dbgp.o
 obj-$(CONFIG_XEN_PCIDEV_BACKEND)	+= xen-pciback/
 obj-$(CONFIG_XEN_PRIVCMD)		+= $(xen-privcmd_y)
 obj-$(CONFIG_XEN_ACPI_PROCESSOR)	+= xen-acpi-processor.o
--- /dev/null
+++ b/drivers/xen/dbgp.c
@@ -0,0 +1,48 @@
+#include <linux/pci.h>
+#include <linux/usb.h>
+#include <linux/usb/ehci_def.h>
+#include <linux/usb/hcd.h>
+#include <asm/xen/hypercall.h>
+#include <xen/interface/physdev.h>
+#include <xen/xen.h>
+
+static int xen_dbgp_op(struct usb_hcd *hcd, int op)
+{
+	const struct device *ctrlr = hcd_to_bus(hcd)->controller;
+	struct physdev_dbgp_op dbgp;
+
+	if (!xen_initial_domain())
+		return 0;
+
+	dbgp.op = op;
+
+#ifdef CONFIG_PCI
+	if (ctrlr->bus == &pci_bus_type) {
+		const struct pci_dev *pdev = to_pci_dev(ctrlr);
+
+		dbgp.u.pci.seg = pci_domain_nr(pdev->bus);
+		dbgp.u.pci.bus = pdev->bus->number;
+		dbgp.u.pci.devfn = pdev->devfn;
+		dbgp.bus = PHYSDEVOP_DBGP_BUS_PCI;
+	} else
+#endif
+		dbgp.bus = PHYSDEVOP_DBGP_BUS_UNKNOWN;
+
+	return HYPERVISOR_physdev_op(PHYSDEVOP_dbgp_op, &dbgp);
+}
+
+int xen_dbgp_reset_prep(struct usb_hcd *hcd)
+{
+	return xen_dbgp_op(hcd, PHYSDEVOP_DBGP_RESET_PREPARE);
+}
+
+int xen_dbgp_external_startup(struct usb_hcd *hcd)
+{
+	return xen_dbgp_op(hcd, PHYSDEVOP_DBGP_RESET_DONE);
+}
+
+#ifndef CONFIG_EARLY_PRINTK_DBGP
+#include <linux/export.h>
+EXPORT_SYMBOL_GPL(xen_dbgp_reset_prep);
+EXPORT_SYMBOL_GPL(xen_dbgp_external_startup);
+#endif
--- a/include/linux/usb/ehci_def.h
+++ b/include/linux/usb/ehci_def.h
@@ -207,18 +207,35 @@ extern int __init early_dbgp_init(char *
 extern struct console early_dbgp_console;
 #endif /* CONFIG_EARLY_PRINTK_DBGP */
 
+struct usb_hcd;
+
+#if defined(CONFIG_XEN_PRIVILEGED_GUEST) || defined(CONFIG_XEN_DOM0)
+extern int xen_dbgp_reset_prep(struct usb_hcd *);
+extern int xen_dbgp_external_startup(struct usb_hcd *);
+#else
+static inline int xen_dbgp_reset_prep(struct usb_hcd *hcd)
+{
+	return 1; /* Shouldn't this be 0? */
+}
+
+static inline int xen_dbgp_external_startup(struct usb_hcd *hcd)
+{
+	return -1;
+}
+#endif
+
 #ifdef CONFIG_EARLY_PRINTK_DBGP
 /* Call backs from ehci host driver to ehci debug driver */
-extern int dbgp_external_startup(void);
-extern int dbgp_reset_prep(void);
+extern int dbgp_external_startup(struct usb_hcd *);
+extern int dbgp_reset_prep(struct usb_hcd *hcd);
 #else
-static inline int dbgp_reset_prep(void)
+static inline int dbgp_reset_prep(struct usb_hcd *hcd)
 {
-	return 1;
+	return xen_dbgp_reset_prep(hcd);
 }
-static inline int dbgp_external_startup(void)
+static inline int dbgp_external_startup(struct usb_hcd *hcd)
 {
-	return -1;
+	return xen_dbgp_external_startup(hcd);
 }
 #endif
 
--- a/include/xen/interface/physdev.h
+++ b/include/xen/interface/physdev.h
@@ -307,6 +307,24 @@ struct physdev_pci_device {
 typedef struct physdev_pci_device physdev_pci_device_t;
 DEFINE_XEN_GUEST_HANDLE(physdev_pci_device_t);
 
+#define PHYSDEVOP_DBGP_RESET_PREPARE    1
+#define PHYSDEVOP_DBGP_RESET_DONE       2
+
+#define PHYSDEVOP_DBGP_BUS_UNKNOWN      0
+#define PHYSDEVOP_DBGP_BUS_PCI          1
+
+#define PHYSDEVOP_dbgp_op               29
+struct physdev_dbgp_op {
+    /* IN */
+    uint8_t op;
+    uint8_t bus;
+    union {
+        struct physdev_pci_device pci;
+    } u;
+};
+typedef struct physdev_dbgp_op physdev_dbgp_op_t;
+DEFINE_XEN_GUEST_HANDLE(physdev_dbgp_op_t);
+
 /*
  * Notify that some PIRQ-bound event channels have been unmasked.
  * ** This command is obsolete since interface version 0x00030202 and is **


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 11 10:11:59 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 2012 10:11:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TBNRR-0002UJ-AS; Tue, 11 Sep 2012 10:11:37 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1TBNRP-0002UE-1h
	for xen-devel@lists.xen.org; Tue, 11 Sep 2012 10:11:35 +0000
Received: from [85.158.139.83:39327] by server-3.bemta-5.messagelabs.com id
	43/40-21836-65E0F405; Tue, 11 Sep 2012 10:11:34 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1347358292!25847144!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQwNzc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30860 invoked from network); 11 Sep 2012 10:11:33 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-7.tower-182.messagelabs.com with SMTP;
	11 Sep 2012 10:11:33 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 11 Sep 2012 11:11:31 +0100
Message-Id: <504F2A71020000780009A7ED@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 11 Sep 2012 11:11:29 +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 RFC 0/8] console improvements
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This series adds support for an EHCI debug port based console, and
does some other improvements and cleanup noticed to be desirable
during the implementation of the former as follow-up.

1: x86: allow early use of fixmaps
2: console: prepare for non-COMn port support
3: console: add EHCI debug port based serial console
4: serial: avoid fully initializing unused consoles
5: ns16550: MMIO adjustments
6: ns16550: PCI initialization adjustments
7: ns16550: command line parsing adjustments
8: drop tx_fifo_size

Note that this also requires a Dom0 kernel side enhancement,
which I'm reproducing below for reference (intending to submit
this only when the public interface change on the hypervisor
side is approved, which in turn will take its time due to the
current feature freeze).

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/drivers/usb/early/ehci-dbgp.c
+++ b/drivers/usb/early/ehci-dbgp.c
@@ -491,7 +491,7 @@ static int ehci_wait_for_port(int port);
  * Return -ENODEV for any general failure
  * Return -EIO if wait for port fails
  */
-int dbgp_external_startup(void)
+static int _dbgp_external_startup(void)
 {
 	int devnum;
 	struct usb_debug_descriptor dbgp_desc;
@@ -613,6 +613,11 @@ err:
 		goto try_again;
 	return -ENODEV;
 }
+
+int dbgp_external_startup(struct usb_hcd *hcd)
+{
+	return xen_dbgp_external_startup(hcd) ?: _dbgp_external_startup();
+}
 EXPORT_SYMBOL_GPL(dbgp_external_startup);
 
 static int ehci_reset_port(int port)
@@ -804,7 +809,7 @@ try_next_port:
 		dbgp_ehci_status("ehci skip - already configured");
 	}
 
-	ret = dbgp_external_startup();
+	ret = _dbgp_external_startup();
 	if (ret == -EIO)
 		goto next_debug_port;
 
@@ -934,7 +939,7 @@ static void early_dbgp_write(struct cons
 		ctrl = readl(&ehci_debug->control);
 		if (!(ctrl & DBGP_ENABLED)) {
 			dbgp_not_safe = 1;
-			dbgp_external_startup();
+			_dbgp_external_startup();
 		} else {
 			cmd |= CMD_RUN;
 			writel(cmd, &ehci_regs->command);
@@ -974,10 +979,14 @@ struct console early_dbgp_console = {
 	.index =	-1,
 };
 
-int dbgp_reset_prep(void)
+int dbgp_reset_prep(struct usb_hcd *hcd)
 {
+	int ret = xen_dbgp_reset_prep(hcd);
 	u32 ctrl;
 
+	if (ret)
+		return ret;
+
 	dbgp_not_safe = 1;
 	if (!ehci_debug)
 		return 0;
--- a/drivers/usb/host/ehci-hcd.c
+++ b/drivers/usb/host/ehci-hcd.c
@@ -321,7 +321,7 @@ static int ehci_reset (struct ehci_hcd *
 
 	/* If the EHCI debug controller is active, special care must be
 	 * taken before and after a host controller reset */
-	if (ehci->debug && !dbgp_reset_prep())
+	if (ehci->debug && !dbgp_reset_prep(ehci_to_hcd(ehci)))
 		ehci->debug = NULL;
 
 	command |= CMD_RESET;
@@ -345,7 +345,7 @@ static int ehci_reset (struct ehci_hcd *
 		tdi_reset (ehci);
 
 	if (ehci->debug)
-		dbgp_external_startup();
+		dbgp_external_startup(ehci_to_hcd(ehci));
 
 	ehci->port_c_suspend = ehci->suspended_ports =
 			ehci->resuming_ports = 0;
--- a/drivers/usb/host/ehci-hub.c
+++ b/drivers/usb/host/ehci-hub.c
@@ -347,10 +347,10 @@ static int ehci_bus_resume (struct usb_h
 	}
 
 	if (unlikely(ehci->debug)) {
-		if (!dbgp_reset_prep())
+		if (!dbgp_reset_prep(hcd))
 			ehci->debug = NULL;
 		else
-			dbgp_external_startup();
+			dbgp_external_startup(hcd);
 	}
 
 	/* Ideally and we've got a real resume here, and no port's power
--- a/drivers/xen/Makefile
+++ b/drivers/xen/Makefile
@@ -21,6 +21,7 @@ CFLAGS_features.o			:= $(nostackp)
 endif
 
 priv-$(CONFIG_PCI)			:= pci.o
+priv-$(CONFIG_USB_SUPPORT)		+= dbgp.o
 
 obj-$(CONFIG_XEN)			+= features.o $(xen-backend-y) $(xen-backend-m)
 obj-$(CONFIG_XEN_PRIVILEGED_GUEST)	+= $(priv-y)
@@ -37,7 +38,7 @@ obj-$(CONFIG_XEN_SYS_HYPERVISOR)	+= sys-
 obj-$(CONFIG_XEN_PVHVM)			+= platform-pci.o
 obj-$(CONFIG_XEN_TMEM)			+= tmem.o
 obj-$(CONFIG_SWIOTLB_XEN)		+= swiotlb-xen.o
-obj-$(CONFIG_XEN_DOM0)			+= pci.o
+obj-$(CONFIG_XEN_DOM0)			+= pci.o dbgp.o
 obj-$(CONFIG_XEN_PCIDEV_BACKEND)	+= xen-pciback/
 obj-$(CONFIG_XEN_PRIVCMD)		+= $(xen-privcmd_y)
 obj-$(CONFIG_XEN_ACPI_PROCESSOR)	+= xen-acpi-processor.o
--- /dev/null
+++ b/drivers/xen/dbgp.c
@@ -0,0 +1,48 @@
+#include <linux/pci.h>
+#include <linux/usb.h>
+#include <linux/usb/ehci_def.h>
+#include <linux/usb/hcd.h>
+#include <asm/xen/hypercall.h>
+#include <xen/interface/physdev.h>
+#include <xen/xen.h>
+
+static int xen_dbgp_op(struct usb_hcd *hcd, int op)
+{
+	const struct device *ctrlr = hcd_to_bus(hcd)->controller;
+	struct physdev_dbgp_op dbgp;
+
+	if (!xen_initial_domain())
+		return 0;
+
+	dbgp.op = op;
+
+#ifdef CONFIG_PCI
+	if (ctrlr->bus == &pci_bus_type) {
+		const struct pci_dev *pdev = to_pci_dev(ctrlr);
+
+		dbgp.u.pci.seg = pci_domain_nr(pdev->bus);
+		dbgp.u.pci.bus = pdev->bus->number;
+		dbgp.u.pci.devfn = pdev->devfn;
+		dbgp.bus = PHYSDEVOP_DBGP_BUS_PCI;
+	} else
+#endif
+		dbgp.bus = PHYSDEVOP_DBGP_BUS_UNKNOWN;
+
+	return HYPERVISOR_physdev_op(PHYSDEVOP_dbgp_op, &dbgp);
+}
+
+int xen_dbgp_reset_prep(struct usb_hcd *hcd)
+{
+	return xen_dbgp_op(hcd, PHYSDEVOP_DBGP_RESET_PREPARE);
+}
+
+int xen_dbgp_external_startup(struct usb_hcd *hcd)
+{
+	return xen_dbgp_op(hcd, PHYSDEVOP_DBGP_RESET_DONE);
+}
+
+#ifndef CONFIG_EARLY_PRINTK_DBGP
+#include <linux/export.h>
+EXPORT_SYMBOL_GPL(xen_dbgp_reset_prep);
+EXPORT_SYMBOL_GPL(xen_dbgp_external_startup);
+#endif
--- a/include/linux/usb/ehci_def.h
+++ b/include/linux/usb/ehci_def.h
@@ -207,18 +207,35 @@ extern int __init early_dbgp_init(char *
 extern struct console early_dbgp_console;
 #endif /* CONFIG_EARLY_PRINTK_DBGP */
 
+struct usb_hcd;
+
+#if defined(CONFIG_XEN_PRIVILEGED_GUEST) || defined(CONFIG_XEN_DOM0)
+extern int xen_dbgp_reset_prep(struct usb_hcd *);
+extern int xen_dbgp_external_startup(struct usb_hcd *);
+#else
+static inline int xen_dbgp_reset_prep(struct usb_hcd *hcd)
+{
+	return 1; /* Shouldn't this be 0? */
+}
+
+static inline int xen_dbgp_external_startup(struct usb_hcd *hcd)
+{
+	return -1;
+}
+#endif
+
 #ifdef CONFIG_EARLY_PRINTK_DBGP
 /* Call backs from ehci host driver to ehci debug driver */
-extern int dbgp_external_startup(void);
-extern int dbgp_reset_prep(void);
+extern int dbgp_external_startup(struct usb_hcd *);
+extern int dbgp_reset_prep(struct usb_hcd *hcd);
 #else
-static inline int dbgp_reset_prep(void)
+static inline int dbgp_reset_prep(struct usb_hcd *hcd)
 {
-	return 1;
+	return xen_dbgp_reset_prep(hcd);
 }
-static inline int dbgp_external_startup(void)
+static inline int dbgp_external_startup(struct usb_hcd *hcd)
 {
-	return -1;
+	return xen_dbgp_external_startup(hcd);
 }
 #endif
 
--- a/include/xen/interface/physdev.h
+++ b/include/xen/interface/physdev.h
@@ -307,6 +307,24 @@ struct physdev_pci_device {
 typedef struct physdev_pci_device physdev_pci_device_t;
 DEFINE_XEN_GUEST_HANDLE(physdev_pci_device_t);
 
+#define PHYSDEVOP_DBGP_RESET_PREPARE    1
+#define PHYSDEVOP_DBGP_RESET_DONE       2
+
+#define PHYSDEVOP_DBGP_BUS_UNKNOWN      0
+#define PHYSDEVOP_DBGP_BUS_PCI          1
+
+#define PHYSDEVOP_dbgp_op               29
+struct physdev_dbgp_op {
+    /* IN */
+    uint8_t op;
+    uint8_t bus;
+    union {
+        struct physdev_pci_device pci;
+    } u;
+};
+typedef struct physdev_dbgp_op physdev_dbgp_op_t;
+DEFINE_XEN_GUEST_HANDLE(physdev_dbgp_op_t);
+
 /*
  * Notify that some PIRQ-bound event channels have been unmasked.
  * ** This command is obsolete since interface version 0x00030202 and is **


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 11 10:13:36 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 2012 10:13: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 1TBNT1-0002Yj-Q4; Tue, 11 Sep 2012 10:13: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 1TBNT0-0002Yd-Do
	for xen-devel@lists.xen.org; Tue, 11 Sep 2012 10:13:14 +0000
Received: from [85.158.139.83:19235] by server-5.bemta-5.messagelabs.com id
	9D/49-30514-9BE0F405; Tue, 11 Sep 2012 10:13:13 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1347358392!29630088!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQwNzc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6837 invoked from network); 11 Sep 2012 10:13:12 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-12.tower-182.messagelabs.com with SMTP;
	11 Sep 2012 10:13:12 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 11 Sep 2012 11:13:12 +0100
Message-Id: <504F2AD5020000780009A7F1@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 11 Sep 2012 11:13:09 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__PartDCEDCEA5.0__="
Subject: [Xen-devel] [PATCH RFC 1/8] x86: allow early use of fixmaps
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<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.

--=__PartDCEDCEA5.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

As a prerequisite for adding an EHCI debug port based console
implementation, set up the page tables needed for (a sub-portion of)
the fixmaps together with other boot time page table construction.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/arch/x86/boot/head.S
+++ b/xen/arch/x86/boot/head.S
@@ -3,6 +3,7 @@
 #include <public/xen.h>
 #include <asm/asm_defns.h>
 #include <asm/desc.h>
+#include <asm/fixmap.h>
 #include <asm/page.h>
 #include <asm/msr.h>
=20
@@ -136,6 +137,9 @@ __start:
         add     $8,%edx
         add     $(1<<L2_PAGETABLE_SHIFT),%eax
         loop    1b
+        /* Initialise L2 fixmap page directory entry. */
+        mov     $(sym_phys(l1_fixmap)+7),%eax
+        mov     %eax,sym_phys(l2_fixmap) + l2_table_offset(FIXADDR_TOP-1)*=
8
         /* Initialise L3 identity-map page directory entries. */
         mov     $sym_phys(l3_identmap),%edi
         mov     $(sym_phys(l2_identmap)+7),%eax
@@ -144,9 +148,11 @@ __start:
         add     $8,%edi
         add     $PAGE_SIZE,%eax
         loop    1b
-        /* Initialise L3 xen-map page directory entry. */
+        /* Initialise L3 xen-map and fixmap page directory entries. */
         mov     $(sym_phys(l2_xenmap)+7),%eax
         mov     %eax,sym_phys(l3_xenmap) + l3_table_offset(XEN_VIRT_START)=
*8
+        mov     $(sym_phys(l2_fixmap)+7),%eax
+        mov     %eax,sym_phys(l3_xenmap) + l3_table_offset(FIXADDR_TOP-1)*=
8
         /* Initialise L3 boot-map page directory entry. */
         mov     $(sym_phys(l2_bootmap)+7),%eax
         mov     %eax,sym_phys(l3_bootmap) + 0*8
@@ -172,6 +178,9 @@ __start:
         add     $(1<<L2_PAGETABLE_SHIFT),%eax
         cmp     $(16<<20)+0xe3,%eax
         jne     1b
+        /* Initialise L2 fixmap page directory entry. */
+        mov     $(sym_phys(l1_fixmap)+7),%eax
+        mov     %eax,sym_phys(idle_pg_table_l2) + l2_table_offset(FIXADDR_=
TOP-1)*8
 #endif
=20
         /* Initialize 4kB mappings of first 2MB or 4MB of memory. */
--- a/xen/arch/x86/efi/boot.c
+++ b/xen/arch/x86/efi/boot.c
@@ -17,6 +17,9 @@
 #include <xen/vga.h>
 #include <asm/e820.h>
 #include <asm/edd.h>
+#define __ASSEMBLY__ /* avoid pulling in ACPI stuff (conflicts with EFI) =
*/
+#include <asm/fixmap.h>
+#undef __ASSEMBLY__
 #include <asm/mm.h>
 #include <asm/msr.h>
 #include <asm/processor.h>
@@ -1123,14 +1126,19 @@ efi_start(EFI_HANDLE ImageHandle, EFI_SY
         slot &=3D L2_PAGETABLE_ENTRIES - 1;
         l2_bootmap[slot] =3D l2e_from_paddr(addr, __PAGE_HYPERVISOR|_PAGE_=
PSE);
     }
+    /* Initialise L2 fixmap page directory entry. */
+    l2_fixmap[l2_table_offset(FIXADDR_TOP - 1)] =3D
+        l2e_from_paddr((UINTN)l1_fixmap, __PAGE_HYPERVISOR);
     /* Initialise L3 identity-map page directory entries. */
     for ( i =3D 0; i < ARRAY_SIZE(l2_identmap) / L2_PAGETABLE_ENTRIES; =
++i )
         l3_identmap[i] =3D l3e_from_paddr((UINTN)(l2_identmap +
                                                 i * L2_PAGETABLE_ENTRIES),=

                                         __PAGE_HYPERVISOR);
-    /* Initialise L3 xen-map page directory entry. */
+    /* Initialise L3 xen-map and fixmap page directory entries. */
     l3_xenmap[l3_table_offset(XEN_VIRT_START)] =3D
         l3e_from_paddr((UINTN)l2_xenmap, __PAGE_HYPERVISOR);
+    l3_xenmap[l3_table_offset(FIXADDR_TOP - 1)] =3D
+        l3e_from_paddr((UINTN)l2_fixmap, __PAGE_HYPERVISOR);
     /* Initialise L3 boot-map page directory entries. */
     l3_bootmap[l3_table_offset(xen_phys_start)] =3D
         l3e_from_paddr((UINTN)l2_bootmap, __PAGE_HYPERVISOR);
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -130,6 +130,10 @@
 l1_pgentry_t __attribute__ ((__section__ (".bss.page_aligned")))
     l1_identmap[L1_PAGETABLE_ENTRIES];
=20
+/* Mapping of the fixmap space needed early. */
+l1_pgentry_t __attribute__ ((__section__ (".bss.page_aligned")))
+    l1_fixmap[L1_PAGETABLE_ENTRIES];
+
 #define MEM_LOG(_f, _a...) gdprintk(XENLOG_WARNING , _f "\n" , ## _a)
=20
 /*
--- a/xen/arch/x86/x86_64/mm.c
+++ b/xen/arch/x86/x86_64/mm.c
@@ -65,6 +65,10 @@ l3_pgentry_t __attribute__ ((__section__
 l2_pgentry_t __attribute__ ((__section__ (".bss.page_aligned")))
     l2_xenmap[L2_PAGETABLE_ENTRIES];
=20
+/* Enough page directories to map the early fixmap space. */
+l2_pgentry_t __attribute__ ((__section__ (".bss.page_aligned")))
+    l2_fixmap[L2_PAGETABLE_ENTRIES];
+
 /* Enough page directories to map into the bottom 1GB. */
 l3_pgentry_t __attribute__ ((__section__ (".bss.page_aligned")))
     l3_bootmap[L3_PAGETABLE_ENTRIES];
--- a/xen/include/asm-x86/config.h
+++ b/xen/include/asm-x86/config.h
@@ -315,7 +315,7 @@ extern unsigned char boot_edid_info[128]
 #define MACHPHYS_MBYTES         16 /* 1 MB needed per 1 GB memory */
 #define FRAMETABLE_MBYTES       (MACHPHYS_MBYTES * 6)
=20
-#define IOREMAP_VIRT_END	0UL
+#define IOREMAP_VIRT_END	_AC(0,UL)
 #define IOREMAP_VIRT_START	(IOREMAP_VIRT_END - (IOREMAP_MBYTES<<20))
 #define DIRECTMAP_VIRT_END	IOREMAP_VIRT_START
 #define DIRECTMAP_VIRT_START	(DIRECTMAP_VIRT_END - (DIRECTMAP_MBYTES<<20=
))
--- a/xen/include/asm-x86/fixmap.h
+++ b/xen/include/asm-x86/fixmap.h
@@ -13,12 +13,17 @@
 #define _ASM_FIXMAP_H
=20
 #include <xen/config.h>
+#include <asm/page.h>
+
+#define FIXADDR_TOP (IOREMAP_VIRT_END - PAGE_SIZE)
+
+#ifndef __ASSEMBLY__
+
 #include <xen/pfn.h>
 #include <xen/kexec.h>
 #include <xen/iommu.h>
 #include <asm/apicdef.h>
 #include <asm/acpi.h>
-#include <asm/page.h>
 #include <asm/amd-iommu.h>
 #include <asm/msi.h>
 #include <acpi/apei.h>
@@ -66,7 +71,6 @@ enum fixed_addresses {
     __end_of_fixed_addresses
 };
=20
-#define FIXADDR_TOP   (IOREMAP_VIRT_END - PAGE_SIZE)
 #define FIXADDR_SIZE  (__end_of_fixed_addresses << PAGE_SHIFT)
 #define FIXADDR_START (FIXADDR_TOP - FIXADDR_SIZE)
=20
@@ -90,4 +94,6 @@ static inline unsigned long virt_to_fix(
     return __virt_to_fix(vaddr);
 }
=20
+#endif /* __ASSEMBLY__ */
+
 #endif
--- a/xen/include/asm-x86/page.h
+++ b/xen/include/asm-x86/page.h
@@ -306,13 +306,15 @@ extern l2_pgentry_t   idle_pg_table_l2[
 extern l2_pgentry_t  *compat_idle_pg_table_l2;
 extern unsigned int   m2p_compat_vstart;
 extern l2_pgentry_t l2_xenmap[L2_PAGETABLE_ENTRIES],
+    l2_fixmap[L2_PAGETABLE_ENTRIES],
     l2_bootmap[L2_PAGETABLE_ENTRIES];
 extern l3_pgentry_t l3_xenmap[L3_PAGETABLE_ENTRIES],
     l3_identmap[L3_PAGETABLE_ENTRIES],
     l3_bootmap[L3_PAGETABLE_ENTRIES];
 #endif
 extern l2_pgentry_t l2_identmap[4*L2_PAGETABLE_ENTRIES];
-extern l1_pgentry_t l1_identmap[L1_PAGETABLE_ENTRIES];
+extern l1_pgentry_t l1_identmap[L1_PAGETABLE_ENTRIES],
+    l1_fixmap[L1_PAGETABLE_ENTRIES];
 void paging_init(void);
 void setup_idle_pagetable(void);
 #endif /* !defined(__ASSEMBLY__) */
--- /dev/null
+++ a/xen/include/xen/const.h
@@ -0,0 +1,24 @@
+/* const.h: Macros for dealing with constants.  */
+
+#ifndef __XEN_CONST_H__
+#define __XEN_CONST_H__
+
+/* Some constant macros are used in both assembler and
+ * C code.  Therefore we cannot annotate them always with
+ * 'UL' and other type specifiers unilaterally.  We
+ * use the following macros to deal with this.
+ *
+ * Similarly, _AT() will cast an expression with a type in C, but
+ * leave it unchanged in asm.
+ */
+
+#ifdef __ASSEMBLY__
+#define _AC(X,Y)	X
+#define _AT(T,X)	X
+#else
+#define __AC(X,Y)	(X##Y)
+#define _AC(X,Y)	__AC(X,Y)
+#define _AT(T,X)	((T)(X))
+#endif
+
+#endif /* __XEN_CONST_H__ */



--=__PartDCEDCEA5.0__=
Content-Type: text/plain; name="x86-early-fixmap.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="x86-early-fixmap.patch"

x86: allow early use of fixmaps=0A=0AAs a prerequisite for adding an EHCI =
debug port based console=0Aimplementation, set up the page tables needed =
for (a sub-portion of)=0Athe fixmaps together with other boot time page =
table construction.=0A=0ASigned-off-by: Jan Beulich <jbeulich@suse.com>=0A=
=0A--- a/xen/arch/x86/boot/head.S=0A+++ b/xen/arch/x86/boot/head.S=0A@@ =
-3,6 +3,7 @@=0A #include <public/xen.h>=0A #include <asm/asm_defns.h>=0A =
#include <asm/desc.h>=0A+#include <asm/fixmap.h>=0A #include <asm/page.h>=
=0A #include <asm/msr.h>=0A =0A@@ -136,6 +137,9 @@ __start:=0A         add =
    $8,%edx=0A         add     $(1<<L2_PAGETABLE_SHIFT),%eax=0A         =
loop    1b=0A+        /* Initialise L2 fixmap page directory entry. */=0A+ =
       mov     $(sym_phys(l1_fixmap)+7),%eax=0A+        mov     %eax,sym_ph=
ys(l2_fixmap) + l2_table_offset(FIXADDR_TOP-1)*8=0A         /* Initialise =
L3 identity-map page directory entries. */=0A         mov     $sym_phys(l3_=
identmap),%edi=0A         mov     $(sym_phys(l2_identmap)+7),%eax=0A@@ =
-144,9 +148,11 @@ __start:=0A         add     $8,%edi=0A         add     =
$PAGE_SIZE,%eax=0A         loop    1b=0A-        /* Initialise L3 xen-map =
page directory entry. */=0A+        /* Initialise L3 xen-map and fixmap =
page directory entries. */=0A         mov     $(sym_phys(l2_xenmap)+7),%eax=
=0A         mov     %eax,sym_phys(l3_xenmap) + l3_table_offset(XEN_VIRT_STA=
RT)*8=0A+        mov     $(sym_phys(l2_fixmap)+7),%eax=0A+        mov     =
%eax,sym_phys(l3_xenmap) + l3_table_offset(FIXADDR_TOP-1)*8=0A         /* =
Initialise L3 boot-map page directory entry. */=0A         mov     =
$(sym_phys(l2_bootmap)+7),%eax=0A         mov     %eax,sym_phys(l3_bootmap)=
 + 0*8=0A@@ -172,6 +178,9 @@ __start:=0A         add     $(1<<L2_PAGETABLE_=
SHIFT),%eax=0A         cmp     $(16<<20)+0xe3,%eax=0A         jne     =
1b=0A+        /* Initialise L2 fixmap page directory entry. */=0A+        =
mov     $(sym_phys(l1_fixmap)+7),%eax=0A+        mov     %eax,sym_phys(idle=
_pg_table_l2) + l2_table_offset(FIXADDR_TOP-1)*8=0A #endif=0A =0A         =
/* Initialize 4kB mappings of first 2MB or 4MB of memory. */=0A--- =
a/xen/arch/x86/efi/boot.c=0A+++ b/xen/arch/x86/efi/boot.c=0A@@ -17,6 +17,9 =
@@=0A #include <xen/vga.h>=0A #include <asm/e820.h>=0A #include <asm/edd.h>=
=0A+#define __ASSEMBLY__ /* avoid pulling in ACPI stuff (conflicts with =
EFI) */=0A+#include <asm/fixmap.h>=0A+#undef __ASSEMBLY__=0A #include =
<asm/mm.h>=0A #include <asm/msr.h>=0A #include <asm/processor.h>=0A@@ =
-1123,14 +1126,19 @@ efi_start(EFI_HANDLE ImageHandle, EFI_SY=0A         =
slot &=3D L2_PAGETABLE_ENTRIES - 1;=0A         l2_bootmap[slot] =3D =
l2e_from_paddr(addr, __PAGE_HYPERVISOR|_PAGE_PSE);=0A     }=0A+    /* =
Initialise L2 fixmap page directory entry. */=0A+    l2_fixmap[l2_table_off=
set(FIXADDR_TOP - 1)] =3D=0A+        l2e_from_paddr((UINTN)l1_fixmap, =
__PAGE_HYPERVISOR);=0A     /* Initialise L3 identity-map page directory =
entries. */=0A     for ( i =3D 0; i < ARRAY_SIZE(l2_identmap) / L2_PAGETABL=
E_ENTRIES; ++i )=0A         l3_identmap[i] =3D l3e_from_paddr((UINTN)(l2_id=
entmap +=0A                                                 i * L2_PAGETABL=
E_ENTRIES),=0A                                         __PAGE_HYPERVISOR);=
=0A-    /* Initialise L3 xen-map page directory entry. */=0A+    /* =
Initialise L3 xen-map and fixmap page directory entries. */=0A     =
l3_xenmap[l3_table_offset(XEN_VIRT_START)] =3D=0A         l3e_from_paddr((U=
INTN)l2_xenmap, __PAGE_HYPERVISOR);=0A+    l3_xenmap[l3_table_offset(FIXADD=
R_TOP - 1)] =3D=0A+        l3e_from_paddr((UINTN)l2_fixmap, __PAGE_HYPERVIS=
OR);=0A     /* Initialise L3 boot-map page directory entries. */=0A     =
l3_bootmap[l3_table_offset(xen_phys_start)] =3D=0A         l3e_from_paddr((=
UINTN)l2_bootmap, __PAGE_HYPERVISOR);=0A--- a/xen/arch/x86/mm.c=0A+++ =
b/xen/arch/x86/mm.c=0A@@ -130,6 +130,10 @@=0A l1_pgentry_t __attribute__ =
((__section__ (".bss.page_aligned")))=0A     l1_identmap[L1_PAGETABLE_ENTRI=
ES];=0A =0A+/* Mapping of the fixmap space needed early. */=0A+l1_pgentry_t=
 __attribute__ ((__section__ (".bss.page_aligned")))=0A+    l1_fixmap[L1_PA=
GETABLE_ENTRIES];=0A+=0A #define MEM_LOG(_f, _a...) gdprintk(XENLOG_WARNING=
 , _f "\n" , ## _a)=0A =0A /*=0A--- a/xen/arch/x86/x86_64/mm.c=0A+++ =
b/xen/arch/x86/x86_64/mm.c=0A@@ -65,6 +65,10 @@ l3_pgentry_t __attribute__ =
((__section__=0A l2_pgentry_t __attribute__ ((__section__ (".bss.page_align=
ed")))=0A     l2_xenmap[L2_PAGETABLE_ENTRIES];=0A =0A+/* Enough page =
directories to map the early fixmap space. */=0A+l2_pgentry_t __attribute__=
 ((__section__ (".bss.page_aligned")))=0A+    l2_fixmap[L2_PAGETABLE_ENTRIE=
S];=0A+=0A /* Enough page directories to map into the bottom 1GB. */=0A =
l3_pgentry_t __attribute__ ((__section__ (".bss.page_aligned")))=0A     =
l3_bootmap[L3_PAGETABLE_ENTRIES];=0A--- a/xen/include/asm-x86/config.h=0A++=
+ b/xen/include/asm-x86/config.h=0A@@ -315,7 +315,7 @@ extern unsigned =
char boot_edid_info[128]=0A #define MACHPHYS_MBYTES         16 /* 1 MB =
needed per 1 GB memory */=0A #define FRAMETABLE_MBYTES       (MACHPHYS_MBYT=
ES * 6)=0A =0A-#define IOREMAP_VIRT_END	0UL=0A+#define IOREMAP_VIRT_END	=
_AC(0,UL)=0A #define IOREMAP_VIRT_START	(IOREMAP_VIRT_END - (IOREMAP_MBYTES=
<<20))=0A #define DIRECTMAP_VIRT_END	IOREMAP_VIRT_START=0A #define =
DIRECTMAP_VIRT_START	(DIRECTMAP_VIRT_END - (DIRECTMAP_MBYTES<<20))=0A---=
 a/xen/include/asm-x86/fixmap.h=0A+++ b/xen/include/asm-x86/fixmap.h=0A@@ =
-13,12 +13,17 @@=0A #define _ASM_FIXMAP_H=0A =0A #include <xen/config.h>=0A=
+#include <asm/page.h>=0A+=0A+#define FIXADDR_TOP (IOREMAP_VIRT_END - =
PAGE_SIZE)=0A+=0A+#ifndef __ASSEMBLY__=0A+=0A #include <xen/pfn.h>=0A =
#include <xen/kexec.h>=0A #include <xen/iommu.h>=0A #include <asm/apicdef.h=
>=0A #include <asm/acpi.h>=0A-#include <asm/page.h>=0A #include <asm/amd-io=
mmu.h>=0A #include <asm/msi.h>=0A #include <acpi/apei.h>=0A@@ -66,7 +71,6 =
@@ enum fixed_addresses {=0A     __end_of_fixed_addresses=0A };=0A =
=0A-#define FIXADDR_TOP   (IOREMAP_VIRT_END - PAGE_SIZE)=0A #define =
FIXADDR_SIZE  (__end_of_fixed_addresses << PAGE_SHIFT)=0A #define =
FIXADDR_START (FIXADDR_TOP - FIXADDR_SIZE)=0A =0A@@ -90,4 +94,6 @@ static =
inline unsigned long virt_to_fix(=0A     return __virt_to_fix(vaddr);=0A =
}=0A =0A+#endif /* __ASSEMBLY__ */=0A+=0A #endif=0A--- a/xen/include/asm-x8=
6/page.h=0A+++ b/xen/include/asm-x86/page.h=0A@@ -306,13 +306,15 @@ extern =
l2_pgentry_t   idle_pg_table_l2[=0A extern l2_pgentry_t  *compat_idle_pg_ta=
ble_l2;=0A extern unsigned int   m2p_compat_vstart;=0A extern l2_pgentry_t =
l2_xenmap[L2_PAGETABLE_ENTRIES],=0A+    l2_fixmap[L2_PAGETABLE_ENTRIES],=0A=
     l2_bootmap[L2_PAGETABLE_ENTRIES];=0A extern l3_pgentry_t l3_xenmap[L3_=
PAGETABLE_ENTRIES],=0A     l3_identmap[L3_PAGETABLE_ENTRIES],=0A     =
l3_bootmap[L3_PAGETABLE_ENTRIES];=0A #endif=0A extern l2_pgentry_t =
l2_identmap[4*L2_PAGETABLE_ENTRIES];=0A-extern l1_pgentry_t l1_identmap[L1_=
PAGETABLE_ENTRIES];=0A+extern l1_pgentry_t l1_identmap[L1_PAGETABLE_ENTRIES=
],=0A+    l1_fixmap[L1_PAGETABLE_ENTRIES];=0A void paging_init(void);=0A =
void setup_idle_pagetable(void);=0A #endif /* !defined(__ASSEMBLY__) =
*/=0A--- /dev/null=0A+++ a/xen/include/xen/const.h=0A@@ -0,0 +1,24 =
@@=0A+/* const.h: Macros for dealing with constants.  */=0A+=0A+#ifndef =
__XEN_CONST_H__=0A+#define __XEN_CONST_H__=0A+=0A+/* Some constant macros =
are used in both assembler and=0A+ * C code.  Therefore we cannot annotate =
them always with=0A+ * 'UL' and other type specifiers unilaterally.  =
We=0A+ * use the following macros to deal with this.=0A+ *=0A+ * Similarly,=
 _AT() will cast an expression with a type in C, but=0A+ * leave it =
unchanged in asm.=0A+ */=0A+=0A+#ifdef __ASSEMBLY__=0A+#define _AC(X,Y)	=
X=0A+#define _AT(T,X)	X=0A+#else=0A+#define __AC(X,Y)	(X##Y)=0A+#define =
_AC(X,Y)	__AC(X,Y)=0A+#define _AT(T,X)	((T)(X))=0A+#endif=0A+=0A+#=
endif /* __XEN_CONST_H__ */=0A
--=__PartDCEDCEA5.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

--=__PartDCEDCEA5.0__=--


From xen-devel-bounces@lists.xen.org Tue Sep 11 10:13:36 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 2012 10:13: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 1TBNT1-0002Yj-Q4; Tue, 11 Sep 2012 10:13: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 1TBNT0-0002Yd-Do
	for xen-devel@lists.xen.org; Tue, 11 Sep 2012 10:13:14 +0000
Received: from [85.158.139.83:19235] by server-5.bemta-5.messagelabs.com id
	9D/49-30514-9BE0F405; Tue, 11 Sep 2012 10:13:13 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1347358392!29630088!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQwNzc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6837 invoked from network); 11 Sep 2012 10:13:12 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-12.tower-182.messagelabs.com with SMTP;
	11 Sep 2012 10:13:12 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 11 Sep 2012 11:13:12 +0100
Message-Id: <504F2AD5020000780009A7F1@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 11 Sep 2012 11:13:09 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__PartDCEDCEA5.0__="
Subject: [Xen-devel] [PATCH RFC 1/8] x86: allow early use of fixmaps
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<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.

--=__PartDCEDCEA5.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

As a prerequisite for adding an EHCI debug port based console
implementation, set up the page tables needed for (a sub-portion of)
the fixmaps together with other boot time page table construction.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/arch/x86/boot/head.S
+++ b/xen/arch/x86/boot/head.S
@@ -3,6 +3,7 @@
 #include <public/xen.h>
 #include <asm/asm_defns.h>
 #include <asm/desc.h>
+#include <asm/fixmap.h>
 #include <asm/page.h>
 #include <asm/msr.h>
=20
@@ -136,6 +137,9 @@ __start:
         add     $8,%edx
         add     $(1<<L2_PAGETABLE_SHIFT),%eax
         loop    1b
+        /* Initialise L2 fixmap page directory entry. */
+        mov     $(sym_phys(l1_fixmap)+7),%eax
+        mov     %eax,sym_phys(l2_fixmap) + l2_table_offset(FIXADDR_TOP-1)*=
8
         /* Initialise L3 identity-map page directory entries. */
         mov     $sym_phys(l3_identmap),%edi
         mov     $(sym_phys(l2_identmap)+7),%eax
@@ -144,9 +148,11 @@ __start:
         add     $8,%edi
         add     $PAGE_SIZE,%eax
         loop    1b
-        /* Initialise L3 xen-map page directory entry. */
+        /* Initialise L3 xen-map and fixmap page directory entries. */
         mov     $(sym_phys(l2_xenmap)+7),%eax
         mov     %eax,sym_phys(l3_xenmap) + l3_table_offset(XEN_VIRT_START)=
*8
+        mov     $(sym_phys(l2_fixmap)+7),%eax
+        mov     %eax,sym_phys(l3_xenmap) + l3_table_offset(FIXADDR_TOP-1)*=
8
         /* Initialise L3 boot-map page directory entry. */
         mov     $(sym_phys(l2_bootmap)+7),%eax
         mov     %eax,sym_phys(l3_bootmap) + 0*8
@@ -172,6 +178,9 @@ __start:
         add     $(1<<L2_PAGETABLE_SHIFT),%eax
         cmp     $(16<<20)+0xe3,%eax
         jne     1b
+        /* Initialise L2 fixmap page directory entry. */
+        mov     $(sym_phys(l1_fixmap)+7),%eax
+        mov     %eax,sym_phys(idle_pg_table_l2) + l2_table_offset(FIXADDR_=
TOP-1)*8
 #endif
=20
         /* Initialize 4kB mappings of first 2MB or 4MB of memory. */
--- a/xen/arch/x86/efi/boot.c
+++ b/xen/arch/x86/efi/boot.c
@@ -17,6 +17,9 @@
 #include <xen/vga.h>
 #include <asm/e820.h>
 #include <asm/edd.h>
+#define __ASSEMBLY__ /* avoid pulling in ACPI stuff (conflicts with EFI) =
*/
+#include <asm/fixmap.h>
+#undef __ASSEMBLY__
 #include <asm/mm.h>
 #include <asm/msr.h>
 #include <asm/processor.h>
@@ -1123,14 +1126,19 @@ efi_start(EFI_HANDLE ImageHandle, EFI_SY
         slot &=3D L2_PAGETABLE_ENTRIES - 1;
         l2_bootmap[slot] =3D l2e_from_paddr(addr, __PAGE_HYPERVISOR|_PAGE_=
PSE);
     }
+    /* Initialise L2 fixmap page directory entry. */
+    l2_fixmap[l2_table_offset(FIXADDR_TOP - 1)] =3D
+        l2e_from_paddr((UINTN)l1_fixmap, __PAGE_HYPERVISOR);
     /* Initialise L3 identity-map page directory entries. */
     for ( i =3D 0; i < ARRAY_SIZE(l2_identmap) / L2_PAGETABLE_ENTRIES; =
++i )
         l3_identmap[i] =3D l3e_from_paddr((UINTN)(l2_identmap +
                                                 i * L2_PAGETABLE_ENTRIES),=

                                         __PAGE_HYPERVISOR);
-    /* Initialise L3 xen-map page directory entry. */
+    /* Initialise L3 xen-map and fixmap page directory entries. */
     l3_xenmap[l3_table_offset(XEN_VIRT_START)] =3D
         l3e_from_paddr((UINTN)l2_xenmap, __PAGE_HYPERVISOR);
+    l3_xenmap[l3_table_offset(FIXADDR_TOP - 1)] =3D
+        l3e_from_paddr((UINTN)l2_fixmap, __PAGE_HYPERVISOR);
     /* Initialise L3 boot-map page directory entries. */
     l3_bootmap[l3_table_offset(xen_phys_start)] =3D
         l3e_from_paddr((UINTN)l2_bootmap, __PAGE_HYPERVISOR);
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -130,6 +130,10 @@
 l1_pgentry_t __attribute__ ((__section__ (".bss.page_aligned")))
     l1_identmap[L1_PAGETABLE_ENTRIES];
=20
+/* Mapping of the fixmap space needed early. */
+l1_pgentry_t __attribute__ ((__section__ (".bss.page_aligned")))
+    l1_fixmap[L1_PAGETABLE_ENTRIES];
+
 #define MEM_LOG(_f, _a...) gdprintk(XENLOG_WARNING , _f "\n" , ## _a)
=20
 /*
--- a/xen/arch/x86/x86_64/mm.c
+++ b/xen/arch/x86/x86_64/mm.c
@@ -65,6 +65,10 @@ l3_pgentry_t __attribute__ ((__section__
 l2_pgentry_t __attribute__ ((__section__ (".bss.page_aligned")))
     l2_xenmap[L2_PAGETABLE_ENTRIES];
=20
+/* Enough page directories to map the early fixmap space. */
+l2_pgentry_t __attribute__ ((__section__ (".bss.page_aligned")))
+    l2_fixmap[L2_PAGETABLE_ENTRIES];
+
 /* Enough page directories to map into the bottom 1GB. */
 l3_pgentry_t __attribute__ ((__section__ (".bss.page_aligned")))
     l3_bootmap[L3_PAGETABLE_ENTRIES];
--- a/xen/include/asm-x86/config.h
+++ b/xen/include/asm-x86/config.h
@@ -315,7 +315,7 @@ extern unsigned char boot_edid_info[128]
 #define MACHPHYS_MBYTES         16 /* 1 MB needed per 1 GB memory */
 #define FRAMETABLE_MBYTES       (MACHPHYS_MBYTES * 6)
=20
-#define IOREMAP_VIRT_END	0UL
+#define IOREMAP_VIRT_END	_AC(0,UL)
 #define IOREMAP_VIRT_START	(IOREMAP_VIRT_END - (IOREMAP_MBYTES<<20))
 #define DIRECTMAP_VIRT_END	IOREMAP_VIRT_START
 #define DIRECTMAP_VIRT_START	(DIRECTMAP_VIRT_END - (DIRECTMAP_MBYTES<<20=
))
--- a/xen/include/asm-x86/fixmap.h
+++ b/xen/include/asm-x86/fixmap.h
@@ -13,12 +13,17 @@
 #define _ASM_FIXMAP_H
=20
 #include <xen/config.h>
+#include <asm/page.h>
+
+#define FIXADDR_TOP (IOREMAP_VIRT_END - PAGE_SIZE)
+
+#ifndef __ASSEMBLY__
+
 #include <xen/pfn.h>
 #include <xen/kexec.h>
 #include <xen/iommu.h>
 #include <asm/apicdef.h>
 #include <asm/acpi.h>
-#include <asm/page.h>
 #include <asm/amd-iommu.h>
 #include <asm/msi.h>
 #include <acpi/apei.h>
@@ -66,7 +71,6 @@ enum fixed_addresses {
     __end_of_fixed_addresses
 };
=20
-#define FIXADDR_TOP   (IOREMAP_VIRT_END - PAGE_SIZE)
 #define FIXADDR_SIZE  (__end_of_fixed_addresses << PAGE_SHIFT)
 #define FIXADDR_START (FIXADDR_TOP - FIXADDR_SIZE)
=20
@@ -90,4 +94,6 @@ static inline unsigned long virt_to_fix(
     return __virt_to_fix(vaddr);
 }
=20
+#endif /* __ASSEMBLY__ */
+
 #endif
--- a/xen/include/asm-x86/page.h
+++ b/xen/include/asm-x86/page.h
@@ -306,13 +306,15 @@ extern l2_pgentry_t   idle_pg_table_l2[
 extern l2_pgentry_t  *compat_idle_pg_table_l2;
 extern unsigned int   m2p_compat_vstart;
 extern l2_pgentry_t l2_xenmap[L2_PAGETABLE_ENTRIES],
+    l2_fixmap[L2_PAGETABLE_ENTRIES],
     l2_bootmap[L2_PAGETABLE_ENTRIES];
 extern l3_pgentry_t l3_xenmap[L3_PAGETABLE_ENTRIES],
     l3_identmap[L3_PAGETABLE_ENTRIES],
     l3_bootmap[L3_PAGETABLE_ENTRIES];
 #endif
 extern l2_pgentry_t l2_identmap[4*L2_PAGETABLE_ENTRIES];
-extern l1_pgentry_t l1_identmap[L1_PAGETABLE_ENTRIES];
+extern l1_pgentry_t l1_identmap[L1_PAGETABLE_ENTRIES],
+    l1_fixmap[L1_PAGETABLE_ENTRIES];
 void paging_init(void);
 void setup_idle_pagetable(void);
 #endif /* !defined(__ASSEMBLY__) */
--- /dev/null
+++ a/xen/include/xen/const.h
@@ -0,0 +1,24 @@
+/* const.h: Macros for dealing with constants.  */
+
+#ifndef __XEN_CONST_H__
+#define __XEN_CONST_H__
+
+/* Some constant macros are used in both assembler and
+ * C code.  Therefore we cannot annotate them always with
+ * 'UL' and other type specifiers unilaterally.  We
+ * use the following macros to deal with this.
+ *
+ * Similarly, _AT() will cast an expression with a type in C, but
+ * leave it unchanged in asm.
+ */
+
+#ifdef __ASSEMBLY__
+#define _AC(X,Y)	X
+#define _AT(T,X)	X
+#else
+#define __AC(X,Y)	(X##Y)
+#define _AC(X,Y)	__AC(X,Y)
+#define _AT(T,X)	((T)(X))
+#endif
+
+#endif /* __XEN_CONST_H__ */



--=__PartDCEDCEA5.0__=
Content-Type: text/plain; name="x86-early-fixmap.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="x86-early-fixmap.patch"

x86: allow early use of fixmaps=0A=0AAs a prerequisite for adding an EHCI =
debug port based console=0Aimplementation, set up the page tables needed =
for (a sub-portion of)=0Athe fixmaps together with other boot time page =
table construction.=0A=0ASigned-off-by: Jan Beulich <jbeulich@suse.com>=0A=
=0A--- a/xen/arch/x86/boot/head.S=0A+++ b/xen/arch/x86/boot/head.S=0A@@ =
-3,6 +3,7 @@=0A #include <public/xen.h>=0A #include <asm/asm_defns.h>=0A =
#include <asm/desc.h>=0A+#include <asm/fixmap.h>=0A #include <asm/page.h>=
=0A #include <asm/msr.h>=0A =0A@@ -136,6 +137,9 @@ __start:=0A         add =
    $8,%edx=0A         add     $(1<<L2_PAGETABLE_SHIFT),%eax=0A         =
loop    1b=0A+        /* Initialise L2 fixmap page directory entry. */=0A+ =
       mov     $(sym_phys(l1_fixmap)+7),%eax=0A+        mov     %eax,sym_ph=
ys(l2_fixmap) + l2_table_offset(FIXADDR_TOP-1)*8=0A         /* Initialise =
L3 identity-map page directory entries. */=0A         mov     $sym_phys(l3_=
identmap),%edi=0A         mov     $(sym_phys(l2_identmap)+7),%eax=0A@@ =
-144,9 +148,11 @@ __start:=0A         add     $8,%edi=0A         add     =
$PAGE_SIZE,%eax=0A         loop    1b=0A-        /* Initialise L3 xen-map =
page directory entry. */=0A+        /* Initialise L3 xen-map and fixmap =
page directory entries. */=0A         mov     $(sym_phys(l2_xenmap)+7),%eax=
=0A         mov     %eax,sym_phys(l3_xenmap) + l3_table_offset(XEN_VIRT_STA=
RT)*8=0A+        mov     $(sym_phys(l2_fixmap)+7),%eax=0A+        mov     =
%eax,sym_phys(l3_xenmap) + l3_table_offset(FIXADDR_TOP-1)*8=0A         /* =
Initialise L3 boot-map page directory entry. */=0A         mov     =
$(sym_phys(l2_bootmap)+7),%eax=0A         mov     %eax,sym_phys(l3_bootmap)=
 + 0*8=0A@@ -172,6 +178,9 @@ __start:=0A         add     $(1<<L2_PAGETABLE_=
SHIFT),%eax=0A         cmp     $(16<<20)+0xe3,%eax=0A         jne     =
1b=0A+        /* Initialise L2 fixmap page directory entry. */=0A+        =
mov     $(sym_phys(l1_fixmap)+7),%eax=0A+        mov     %eax,sym_phys(idle=
_pg_table_l2) + l2_table_offset(FIXADDR_TOP-1)*8=0A #endif=0A =0A         =
/* Initialize 4kB mappings of first 2MB or 4MB of memory. */=0A--- =
a/xen/arch/x86/efi/boot.c=0A+++ b/xen/arch/x86/efi/boot.c=0A@@ -17,6 +17,9 =
@@=0A #include <xen/vga.h>=0A #include <asm/e820.h>=0A #include <asm/edd.h>=
=0A+#define __ASSEMBLY__ /* avoid pulling in ACPI stuff (conflicts with =
EFI) */=0A+#include <asm/fixmap.h>=0A+#undef __ASSEMBLY__=0A #include =
<asm/mm.h>=0A #include <asm/msr.h>=0A #include <asm/processor.h>=0A@@ =
-1123,14 +1126,19 @@ efi_start(EFI_HANDLE ImageHandle, EFI_SY=0A         =
slot &=3D L2_PAGETABLE_ENTRIES - 1;=0A         l2_bootmap[slot] =3D =
l2e_from_paddr(addr, __PAGE_HYPERVISOR|_PAGE_PSE);=0A     }=0A+    /* =
Initialise L2 fixmap page directory entry. */=0A+    l2_fixmap[l2_table_off=
set(FIXADDR_TOP - 1)] =3D=0A+        l2e_from_paddr((UINTN)l1_fixmap, =
__PAGE_HYPERVISOR);=0A     /* Initialise L3 identity-map page directory =
entries. */=0A     for ( i =3D 0; i < ARRAY_SIZE(l2_identmap) / L2_PAGETABL=
E_ENTRIES; ++i )=0A         l3_identmap[i] =3D l3e_from_paddr((UINTN)(l2_id=
entmap +=0A                                                 i * L2_PAGETABL=
E_ENTRIES),=0A                                         __PAGE_HYPERVISOR);=
=0A-    /* Initialise L3 xen-map page directory entry. */=0A+    /* =
Initialise L3 xen-map and fixmap page directory entries. */=0A     =
l3_xenmap[l3_table_offset(XEN_VIRT_START)] =3D=0A         l3e_from_paddr((U=
INTN)l2_xenmap, __PAGE_HYPERVISOR);=0A+    l3_xenmap[l3_table_offset(FIXADD=
R_TOP - 1)] =3D=0A+        l3e_from_paddr((UINTN)l2_fixmap, __PAGE_HYPERVIS=
OR);=0A     /* Initialise L3 boot-map page directory entries. */=0A     =
l3_bootmap[l3_table_offset(xen_phys_start)] =3D=0A         l3e_from_paddr((=
UINTN)l2_bootmap, __PAGE_HYPERVISOR);=0A--- a/xen/arch/x86/mm.c=0A+++ =
b/xen/arch/x86/mm.c=0A@@ -130,6 +130,10 @@=0A l1_pgentry_t __attribute__ =
((__section__ (".bss.page_aligned")))=0A     l1_identmap[L1_PAGETABLE_ENTRI=
ES];=0A =0A+/* Mapping of the fixmap space needed early. */=0A+l1_pgentry_t=
 __attribute__ ((__section__ (".bss.page_aligned")))=0A+    l1_fixmap[L1_PA=
GETABLE_ENTRIES];=0A+=0A #define MEM_LOG(_f, _a...) gdprintk(XENLOG_WARNING=
 , _f "\n" , ## _a)=0A =0A /*=0A--- a/xen/arch/x86/x86_64/mm.c=0A+++ =
b/xen/arch/x86/x86_64/mm.c=0A@@ -65,6 +65,10 @@ l3_pgentry_t __attribute__ =
((__section__=0A l2_pgentry_t __attribute__ ((__section__ (".bss.page_align=
ed")))=0A     l2_xenmap[L2_PAGETABLE_ENTRIES];=0A =0A+/* Enough page =
directories to map the early fixmap space. */=0A+l2_pgentry_t __attribute__=
 ((__section__ (".bss.page_aligned")))=0A+    l2_fixmap[L2_PAGETABLE_ENTRIE=
S];=0A+=0A /* Enough page directories to map into the bottom 1GB. */=0A =
l3_pgentry_t __attribute__ ((__section__ (".bss.page_aligned")))=0A     =
l3_bootmap[L3_PAGETABLE_ENTRIES];=0A--- a/xen/include/asm-x86/config.h=0A++=
+ b/xen/include/asm-x86/config.h=0A@@ -315,7 +315,7 @@ extern unsigned =
char boot_edid_info[128]=0A #define MACHPHYS_MBYTES         16 /* 1 MB =
needed per 1 GB memory */=0A #define FRAMETABLE_MBYTES       (MACHPHYS_MBYT=
ES * 6)=0A =0A-#define IOREMAP_VIRT_END	0UL=0A+#define IOREMAP_VIRT_END	=
_AC(0,UL)=0A #define IOREMAP_VIRT_START	(IOREMAP_VIRT_END - (IOREMAP_MBYTES=
<<20))=0A #define DIRECTMAP_VIRT_END	IOREMAP_VIRT_START=0A #define =
DIRECTMAP_VIRT_START	(DIRECTMAP_VIRT_END - (DIRECTMAP_MBYTES<<20))=0A---=
 a/xen/include/asm-x86/fixmap.h=0A+++ b/xen/include/asm-x86/fixmap.h=0A@@ =
-13,12 +13,17 @@=0A #define _ASM_FIXMAP_H=0A =0A #include <xen/config.h>=0A=
+#include <asm/page.h>=0A+=0A+#define FIXADDR_TOP (IOREMAP_VIRT_END - =
PAGE_SIZE)=0A+=0A+#ifndef __ASSEMBLY__=0A+=0A #include <xen/pfn.h>=0A =
#include <xen/kexec.h>=0A #include <xen/iommu.h>=0A #include <asm/apicdef.h=
>=0A #include <asm/acpi.h>=0A-#include <asm/page.h>=0A #include <asm/amd-io=
mmu.h>=0A #include <asm/msi.h>=0A #include <acpi/apei.h>=0A@@ -66,7 +71,6 =
@@ enum fixed_addresses {=0A     __end_of_fixed_addresses=0A };=0A =
=0A-#define FIXADDR_TOP   (IOREMAP_VIRT_END - PAGE_SIZE)=0A #define =
FIXADDR_SIZE  (__end_of_fixed_addresses << PAGE_SHIFT)=0A #define =
FIXADDR_START (FIXADDR_TOP - FIXADDR_SIZE)=0A =0A@@ -90,4 +94,6 @@ static =
inline unsigned long virt_to_fix(=0A     return __virt_to_fix(vaddr);=0A =
}=0A =0A+#endif /* __ASSEMBLY__ */=0A+=0A #endif=0A--- a/xen/include/asm-x8=
6/page.h=0A+++ b/xen/include/asm-x86/page.h=0A@@ -306,13 +306,15 @@ extern =
l2_pgentry_t   idle_pg_table_l2[=0A extern l2_pgentry_t  *compat_idle_pg_ta=
ble_l2;=0A extern unsigned int   m2p_compat_vstart;=0A extern l2_pgentry_t =
l2_xenmap[L2_PAGETABLE_ENTRIES],=0A+    l2_fixmap[L2_PAGETABLE_ENTRIES],=0A=
     l2_bootmap[L2_PAGETABLE_ENTRIES];=0A extern l3_pgentry_t l3_xenmap[L3_=
PAGETABLE_ENTRIES],=0A     l3_identmap[L3_PAGETABLE_ENTRIES],=0A     =
l3_bootmap[L3_PAGETABLE_ENTRIES];=0A #endif=0A extern l2_pgentry_t =
l2_identmap[4*L2_PAGETABLE_ENTRIES];=0A-extern l1_pgentry_t l1_identmap[L1_=
PAGETABLE_ENTRIES];=0A+extern l1_pgentry_t l1_identmap[L1_PAGETABLE_ENTRIES=
],=0A+    l1_fixmap[L1_PAGETABLE_ENTRIES];=0A void paging_init(void);=0A =
void setup_idle_pagetable(void);=0A #endif /* !defined(__ASSEMBLY__) =
*/=0A--- /dev/null=0A+++ a/xen/include/xen/const.h=0A@@ -0,0 +1,24 =
@@=0A+/* const.h: Macros for dealing with constants.  */=0A+=0A+#ifndef =
__XEN_CONST_H__=0A+#define __XEN_CONST_H__=0A+=0A+/* Some constant macros =
are used in both assembler and=0A+ * C code.  Therefore we cannot annotate =
them always with=0A+ * 'UL' and other type specifiers unilaterally.  =
We=0A+ * use the following macros to deal with this.=0A+ *=0A+ * Similarly,=
 _AT() will cast an expression with a type in C, but=0A+ * leave it =
unchanged in asm.=0A+ */=0A+=0A+#ifdef __ASSEMBLY__=0A+#define _AC(X,Y)	=
X=0A+#define _AT(T,X)	X=0A+#else=0A+#define __AC(X,Y)	(X##Y)=0A+#define =
_AC(X,Y)	__AC(X,Y)=0A+#define _AT(T,X)	((T)(X))=0A+#endif=0A+=0A+#=
endif /* __XEN_CONST_H__ */=0A
--=__PartDCEDCEA5.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

--=__PartDCEDCEA5.0__=--


From xen-devel-bounces@lists.xen.org Tue Sep 11 10:15:00 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 2012 10:15: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 1TBNUS-0002gF-FO; Tue, 11 Sep 2012 10:14: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 1TBNUR-0002g5-6j
	for xen-devel@lists.xen.org; Tue, 11 Sep 2012 10:14:43 +0000
Received: from [85.158.139.83:32831] by server-8.bemta-5.messagelabs.com id
	DF/C7-17085-21F0F405; Tue, 11 Sep 2012 10:14:42 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1347358481!27615446!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQwNzc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1634 invoked from network); 11 Sep 2012 10:14:41 -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;
	11 Sep 2012 10:14:41 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 11 Sep 2012 11:14:41 +0100
Message-Id: <504F2B2D020000780009A7FC@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 11 Sep 2012 11:14:37 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part6554771D.0__="
Subject: [Xen-devel] [PATCH RFC 2/8] console: prepare for non-COMn port
	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

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.

--=__Part6554771D.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Widen SERHND_IDX (and use it where needed), introduce a flush low level
driver method, and remove unnecessary peeking of the common code at the
(driver specific) serial port identification string in the "console=3D"
command line option value.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/arch/x86/smpboot.c
+++ b/xen/arch/x86/smpboot.c
@@ -1017,7 +1017,7 @@ void __init smp_intr_init(void)
      * Also ensure serial interrupts are high priority. We do not
      * want them to be blocked by unacknowledged guest-bound interrupts.
      */
-    for ( seridx =3D 0; seridx < 2; seridx++ )
+    for ( seridx =3D 0; seridx <=3D SERHND_IDX; seridx++ )
     {
         if ( (irq =3D serial_irq(seridx)) < 0 )
             continue;
--- a/xen/drivers/char/console.c
+++ b/xen/drivers/char/console.c
@@ -539,6 +539,7 @@ void printk(const char *fmt, ...)
 void __init console_init_preirq(void)
 {
     char *p;
+    int sh;
=20
     serial_init_preirq();
=20
@@ -551,8 +552,9 @@ void __init console_init_preirq(void)
             vga_init();
         else if ( !strncmp(p, "none", 4) )
             continue;
-        else if ( strncmp(p, "com", 3) ||
-                  (sercon_handle =3D serial_parse_handle(p)) =3D=3D -1 )
+        else if ( (sh =3D serial_parse_handle(p)) >=3D 0 )
+            sercon_handle =3D sh;
+        else
         {
             char *q =3D strchr(p, ',');
             if ( q !=3D NULL )
--- a/xen/drivers/char/serial.c
+++ b/xen/drivers/char/serial.c
@@ -22,9 +22,11 @@ size_param("serial_tx_buffer", serial_tx
 #define mask_serial_rxbuf_idx(_i) ((_i)&(serial_rxbufsz-1))
 #define mask_serial_txbuf_idx(_i) ((_i)&(serial_txbufsz-1))
=20
-static struct serial_port com[2] =3D {
-    { .rx_lock =3D SPIN_LOCK_UNLOCKED, .tx_lock =3D SPIN_LOCK_UNLOCKED =
},=20
-    { .rx_lock =3D SPIN_LOCK_UNLOCKED, .tx_lock =3D SPIN_LOCK_UNLOCKED }
+static struct serial_port com[SERHND_IDX + 1] =3D {
+    [0 ... SERHND_IDX] =3D {
+        .rx_lock =3D SPIN_LOCK_UNLOCKED,
+        .tx_lock =3D SPIN_LOCK_UNLOCKED
+    }
 };
=20
 void serial_rx_interrupt(struct serial_port *port, struct cpu_user_regs =
*regs)
@@ -81,6 +83,8 @@ void serial_tx_interrupt(struct serial_p
             port->driver->putc(
                 port, port->txbuf[mask_serial_txbuf_idx(port->txbufc++)]);=

         }
+        if ( i && port->driver->flush )
+            port->driver->flush(port);
     }
=20
     spin_unlock(&port->tx_lock);
@@ -175,6 +179,9 @@ void serial_putc(int handle, char c)
=20
     __serial_putc(port, c);
=20
+    if ( port->driver->flush )
+        port->driver->flush(port);
+
     spin_unlock_irqrestore(&port->tx_lock, flags);
 }
=20
@@ -206,6 +213,9 @@ void serial_puts(int handle, const char=20
         __serial_putc(port, c);
     }
=20
+    if ( port->driver->flush )
+        port->driver->flush(port);
+
     spin_unlock_irqrestore(&port->tx_lock, flags);
 }
=20
@@ -261,10 +271,10 @@ int __init serial_parse_handle(char *con
     switch ( conf[3] )
     {
     case '1':
-        handle =3D 0;
+        handle =3D SERHND_COM1;
         break;
     case '2':
-        handle =3D 1;
+        handle =3D SERHND_COM2;
         break;
     default:
         goto fail;
@@ -365,6 +375,8 @@ void serial_start_sync(int handle)
             port->driver->putc(
                 port, port->txbuf[mask_serial_txbuf_idx(port->txbufc++)]);=

         }
+        if ( port->driver->flush )
+            port->driver->flush(port);
     }
=20
     spin_unlock_irqrestore(&port->tx_lock, flags);
--- a/xen/include/xen/serial.h
+++ b/xen/include/xen/serial.h
@@ -60,6 +60,8 @@ struct uart_driver {
     int  (*tx_empty)(struct serial_port *);
     /* Put a character onto the serial line. */
     void (*putc)(struct serial_port *, char);
+    /* Flush accumulated characters. */
+    void (*flush)(struct serial_port *);
     /* Get a character from the serial line: returns 0 if none available. =
*/
     int  (*getc)(struct serial_port *, char *);
     /* Get IRQ number for this port's serial line: returns -1 if none. */
@@ -67,10 +69,12 @@ struct uart_driver {
 };
=20
 /* 'Serial handles' are composed from the following fields. */
-#define SERHND_IDX      (1<<0) /* COM1 or COM2?                           =
*/
-#define SERHND_HI       (1<<1) /* Mux/demux each transferred char by MSB. =
*/
-#define SERHND_LO       (1<<2) /* Ditto, except that the MSB is cleared.  =
*/
-#define SERHND_COOKED   (1<<3) /* Newline/carriage-return translation?    =
*/
+#define SERHND_IDX      (3<<0) /* COM1 or COM2?                           =
*/
+# define SERHND_COM1    (0<<0)
+# define SERHND_COM2    (1<<0)
+#define SERHND_HI       (1<<2) /* Mux/demux each transferred char by MSB. =
*/
+#define SERHND_LO       (1<<3) /* Ditto, except that the MSB is cleared.  =
*/
+#define SERHND_COOKED   (1<<4) /* Newline/carriage-return translation?    =
*/
=20
 /* Two-stage initialisation (before/after IRQ-subsystem initialisation). =
*/
 void serial_init_preirq(void);



--=__Part6554771D.0__=
Content-Type: text/plain; name="sercon-non-com.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="sercon-non-com.patch"

console: prepare for non-COMn port support=0A=0AWiden SERHND_IDX (and use =
it where needed), introduce a flush low level=0Adriver method, and remove =
unnecessary peeking of the common code at the=0A(driver specific) serial =
port identification string in the "console=3D"=0Acommand line option =
value.=0A=0ASigned-off-by: Jan Beulich <jbeulich@suse.com>=0A=0A--- =
a/xen/arch/x86/smpboot.c=0A+++ b/xen/arch/x86/smpboot.c=0A@@ -1017,7 =
+1017,7 @@ void __init smp_intr_init(void)=0A      * Also ensure serial =
interrupts are high priority. We do not=0A      * want them to be blocked =
by unacknowledged guest-bound interrupts.=0A      */=0A-    for ( seridx =
=3D 0; seridx < 2; seridx++ )=0A+    for ( seridx =3D 0; seridx <=3D =
SERHND_IDX; seridx++ )=0A     {=0A         if ( (irq =3D serial_irq(seridx)=
) < 0 )=0A             continue;=0A--- a/xen/drivers/char/console.c=0A+++ =
b/xen/drivers/char/console.c=0A@@ -539,6 +539,7 @@ void printk(const char =
*fmt, ...)=0A void __init console_init_preirq(void)=0A {=0A     char =
*p;=0A+    int sh;=0A =0A     serial_init_preirq();=0A =0A@@ -551,8 +552,9 =
@@ void __init console_init_preirq(void)=0A             vga_init();=0A     =
    else if ( !strncmp(p, "none", 4) )=0A             continue;=0A-        =
else if ( strncmp(p, "com", 3) ||=0A-                  (sercon_handle =3D =
serial_parse_handle(p)) =3D=3D -1 )=0A+        else if ( (sh =3D serial_par=
se_handle(p)) >=3D 0 )=0A+            sercon_handle =3D sh;=0A+        =
else=0A         {=0A             char *q =3D strchr(p, ',');=0A            =
 if ( q !=3D NULL )=0A--- a/xen/drivers/char/serial.c=0A+++ b/xen/drivers/c=
har/serial.c=0A@@ -22,9 +22,11 @@ size_param("serial_tx_buffer", =
serial_tx=0A #define mask_serial_rxbuf_idx(_i) ((_i)&(serial_rxbufsz-1))=0A=
 #define mask_serial_txbuf_idx(_i) ((_i)&(serial_txbufsz-1))=0A =0A-static =
struct serial_port com[2] =3D {=0A-    { .rx_lock =3D SPIN_LOCK_UNLOCKED, =
.tx_lock =3D SPIN_LOCK_UNLOCKED }, =0A-    { .rx_lock =3D SPIN_LOCK_UNLOCKE=
D, .tx_lock =3D SPIN_LOCK_UNLOCKED }=0A+static struct serial_port =
com[SERHND_IDX + 1] =3D {=0A+    [0 ... SERHND_IDX] =3D {=0A+        =
.rx_lock =3D SPIN_LOCK_UNLOCKED,=0A+        .tx_lock =3D SPIN_LOCK_UNLOCKED=
=0A+    }=0A };=0A =0A void serial_rx_interrupt(struct serial_port *port, =
struct cpu_user_regs *regs)=0A@@ -81,6 +83,8 @@ void serial_tx_interrupt(st=
ruct serial_p=0A             port->driver->putc(=0A                 port, =
port->txbuf[mask_serial_txbuf_idx(port->txbufc++)]);=0A         }=0A+      =
  if ( i && port->driver->flush )=0A+            port->driver->flush(port);=
=0A     }=0A =0A     spin_unlock(&port->tx_lock);=0A@@ -175,6 +179,9 @@ =
void serial_putc(int handle, char c)=0A =0A     __serial_putc(port, c);=0A =
=0A+    if ( port->driver->flush )=0A+        port->driver->flush(port);=0A=
+=0A     spin_unlock_irqrestore(&port->tx_lock, flags);=0A }=0A =0A@@ =
-206,6 +213,9 @@ void serial_puts(int handle, const char =0A         =
__serial_putc(port, c);=0A     }=0A =0A+    if ( port->driver->flush )=0A+ =
       port->driver->flush(port);=0A+=0A     spin_unlock_irqrestore(&port->=
tx_lock, flags);=0A }=0A =0A@@ -261,10 +271,10 @@ int __init serial_parse_h=
andle(char *con=0A     switch ( conf[3] )=0A     {=0A     case '1':=0A-    =
    handle =3D 0;=0A+        handle =3D SERHND_COM1;=0A         break;=0A  =
   case '2':=0A-        handle =3D 1;=0A+        handle =3D SERHND_COM2;=0A=
         break;=0A     default:=0A         goto fail;=0A@@ -365,6 +375,8 =
@@ void serial_start_sync(int handle)=0A             port->driver->putc(=0A=
                 port, port->txbuf[mask_serial_txbuf_idx(port->txbufc++)]);=
=0A         }=0A+        if ( port->driver->flush )=0A+            =
port->driver->flush(port);=0A     }=0A =0A     spin_unlock_irqrestore(&port=
->tx_lock, flags);=0A--- a/xen/include/xen/serial.h=0A+++ b/xen/include/xen=
/serial.h=0A@@ -60,6 +60,8 @@ struct uart_driver {=0A     int  (*tx_empty)(=
struct serial_port *);=0A     /* Put a character onto the serial line. =
*/=0A     void (*putc)(struct serial_port *, char);=0A+    /* Flush =
accumulated characters. */=0A+    void (*flush)(struct serial_port *);=0A  =
   /* Get a character from the serial line: returns 0 if none available. =
*/=0A     int  (*getc)(struct serial_port *, char *);=0A     /* Get IRQ =
number for this port's serial line: returns -1 if none. */=0A@@ -67,10 =
+69,12 @@ struct uart_driver {=0A };=0A =0A /* 'Serial handles' are =
composed from the following fields. */=0A-#define SERHND_IDX      (1<<0) =
/* COM1 or COM2?                           */=0A-#define SERHND_HI       =
(1<<1) /* Mux/demux each transferred char by MSB. */=0A-#define SERHND_LO  =
     (1<<2) /* Ditto, except that the MSB is cleared.  */=0A-#define =
SERHND_COOKED   (1<<3) /* Newline/carriage-return translation?    =
*/=0A+#define SERHND_IDX      (3<<0) /* COM1 or COM2?                      =
     */=0A+# define SERHND_COM1    (0<<0)=0A+# define SERHND_COM2    =
(1<<0)=0A+#define SERHND_HI       (1<<2) /* Mux/demux each transferred =
char by MSB. */=0A+#define SERHND_LO       (1<<3) /* Ditto, except that =
the MSB is cleared.  */=0A+#define SERHND_COOKED   (1<<4) /* Newline/carria=
ge-return translation?    */=0A =0A /* Two-stage initialisation (before/aft=
er IRQ-subsystem initialisation). */=0A void serial_init_preirq(void);=0A
--=__Part6554771D.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

--=__Part6554771D.0__=--


From xen-devel-bounces@lists.xen.org Tue Sep 11 10:15:00 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 2012 10:15: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 1TBNUS-0002gF-FO; Tue, 11 Sep 2012 10:14: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 1TBNUR-0002g5-6j
	for xen-devel@lists.xen.org; Tue, 11 Sep 2012 10:14:43 +0000
Received: from [85.158.139.83:32831] by server-8.bemta-5.messagelabs.com id
	DF/C7-17085-21F0F405; Tue, 11 Sep 2012 10:14:42 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1347358481!27615446!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQwNzc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1634 invoked from network); 11 Sep 2012 10:14:41 -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;
	11 Sep 2012 10:14:41 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 11 Sep 2012 11:14:41 +0100
Message-Id: <504F2B2D020000780009A7FC@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 11 Sep 2012 11:14:37 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part6554771D.0__="
Subject: [Xen-devel] [PATCH RFC 2/8] console: prepare for non-COMn port
	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

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.

--=__Part6554771D.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Widen SERHND_IDX (and use it where needed), introduce a flush low level
driver method, and remove unnecessary peeking of the common code at the
(driver specific) serial port identification string in the "console=3D"
command line option value.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/arch/x86/smpboot.c
+++ b/xen/arch/x86/smpboot.c
@@ -1017,7 +1017,7 @@ void __init smp_intr_init(void)
      * Also ensure serial interrupts are high priority. We do not
      * want them to be blocked by unacknowledged guest-bound interrupts.
      */
-    for ( seridx =3D 0; seridx < 2; seridx++ )
+    for ( seridx =3D 0; seridx <=3D SERHND_IDX; seridx++ )
     {
         if ( (irq =3D serial_irq(seridx)) < 0 )
             continue;
--- a/xen/drivers/char/console.c
+++ b/xen/drivers/char/console.c
@@ -539,6 +539,7 @@ void printk(const char *fmt, ...)
 void __init console_init_preirq(void)
 {
     char *p;
+    int sh;
=20
     serial_init_preirq();
=20
@@ -551,8 +552,9 @@ void __init console_init_preirq(void)
             vga_init();
         else if ( !strncmp(p, "none", 4) )
             continue;
-        else if ( strncmp(p, "com", 3) ||
-                  (sercon_handle =3D serial_parse_handle(p)) =3D=3D -1 )
+        else if ( (sh =3D serial_parse_handle(p)) >=3D 0 )
+            sercon_handle =3D sh;
+        else
         {
             char *q =3D strchr(p, ',');
             if ( q !=3D NULL )
--- a/xen/drivers/char/serial.c
+++ b/xen/drivers/char/serial.c
@@ -22,9 +22,11 @@ size_param("serial_tx_buffer", serial_tx
 #define mask_serial_rxbuf_idx(_i) ((_i)&(serial_rxbufsz-1))
 #define mask_serial_txbuf_idx(_i) ((_i)&(serial_txbufsz-1))
=20
-static struct serial_port com[2] =3D {
-    { .rx_lock =3D SPIN_LOCK_UNLOCKED, .tx_lock =3D SPIN_LOCK_UNLOCKED =
},=20
-    { .rx_lock =3D SPIN_LOCK_UNLOCKED, .tx_lock =3D SPIN_LOCK_UNLOCKED }
+static struct serial_port com[SERHND_IDX + 1] =3D {
+    [0 ... SERHND_IDX] =3D {
+        .rx_lock =3D SPIN_LOCK_UNLOCKED,
+        .tx_lock =3D SPIN_LOCK_UNLOCKED
+    }
 };
=20
 void serial_rx_interrupt(struct serial_port *port, struct cpu_user_regs =
*regs)
@@ -81,6 +83,8 @@ void serial_tx_interrupt(struct serial_p
             port->driver->putc(
                 port, port->txbuf[mask_serial_txbuf_idx(port->txbufc++)]);=

         }
+        if ( i && port->driver->flush )
+            port->driver->flush(port);
     }
=20
     spin_unlock(&port->tx_lock);
@@ -175,6 +179,9 @@ void serial_putc(int handle, char c)
=20
     __serial_putc(port, c);
=20
+    if ( port->driver->flush )
+        port->driver->flush(port);
+
     spin_unlock_irqrestore(&port->tx_lock, flags);
 }
=20
@@ -206,6 +213,9 @@ void serial_puts(int handle, const char=20
         __serial_putc(port, c);
     }
=20
+    if ( port->driver->flush )
+        port->driver->flush(port);
+
     spin_unlock_irqrestore(&port->tx_lock, flags);
 }
=20
@@ -261,10 +271,10 @@ int __init serial_parse_handle(char *con
     switch ( conf[3] )
     {
     case '1':
-        handle =3D 0;
+        handle =3D SERHND_COM1;
         break;
     case '2':
-        handle =3D 1;
+        handle =3D SERHND_COM2;
         break;
     default:
         goto fail;
@@ -365,6 +375,8 @@ void serial_start_sync(int handle)
             port->driver->putc(
                 port, port->txbuf[mask_serial_txbuf_idx(port->txbufc++)]);=

         }
+        if ( port->driver->flush )
+            port->driver->flush(port);
     }
=20
     spin_unlock_irqrestore(&port->tx_lock, flags);
--- a/xen/include/xen/serial.h
+++ b/xen/include/xen/serial.h
@@ -60,6 +60,8 @@ struct uart_driver {
     int  (*tx_empty)(struct serial_port *);
     /* Put a character onto the serial line. */
     void (*putc)(struct serial_port *, char);
+    /* Flush accumulated characters. */
+    void (*flush)(struct serial_port *);
     /* Get a character from the serial line: returns 0 if none available. =
*/
     int  (*getc)(struct serial_port *, char *);
     /* Get IRQ number for this port's serial line: returns -1 if none. */
@@ -67,10 +69,12 @@ struct uart_driver {
 };
=20
 /* 'Serial handles' are composed from the following fields. */
-#define SERHND_IDX      (1<<0) /* COM1 or COM2?                           =
*/
-#define SERHND_HI       (1<<1) /* Mux/demux each transferred char by MSB. =
*/
-#define SERHND_LO       (1<<2) /* Ditto, except that the MSB is cleared.  =
*/
-#define SERHND_COOKED   (1<<3) /* Newline/carriage-return translation?    =
*/
+#define SERHND_IDX      (3<<0) /* COM1 or COM2?                           =
*/
+# define SERHND_COM1    (0<<0)
+# define SERHND_COM2    (1<<0)
+#define SERHND_HI       (1<<2) /* Mux/demux each transferred char by MSB. =
*/
+#define SERHND_LO       (1<<3) /* Ditto, except that the MSB is cleared.  =
*/
+#define SERHND_COOKED   (1<<4) /* Newline/carriage-return translation?    =
*/
=20
 /* Two-stage initialisation (before/after IRQ-subsystem initialisation). =
*/
 void serial_init_preirq(void);



--=__Part6554771D.0__=
Content-Type: text/plain; name="sercon-non-com.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="sercon-non-com.patch"

console: prepare for non-COMn port support=0A=0AWiden SERHND_IDX (and use =
it where needed), introduce a flush low level=0Adriver method, and remove =
unnecessary peeking of the common code at the=0A(driver specific) serial =
port identification string in the "console=3D"=0Acommand line option =
value.=0A=0ASigned-off-by: Jan Beulich <jbeulich@suse.com>=0A=0A--- =
a/xen/arch/x86/smpboot.c=0A+++ b/xen/arch/x86/smpboot.c=0A@@ -1017,7 =
+1017,7 @@ void __init smp_intr_init(void)=0A      * Also ensure serial =
interrupts are high priority. We do not=0A      * want them to be blocked =
by unacknowledged guest-bound interrupts.=0A      */=0A-    for ( seridx =
=3D 0; seridx < 2; seridx++ )=0A+    for ( seridx =3D 0; seridx <=3D =
SERHND_IDX; seridx++ )=0A     {=0A         if ( (irq =3D serial_irq(seridx)=
) < 0 )=0A             continue;=0A--- a/xen/drivers/char/console.c=0A+++ =
b/xen/drivers/char/console.c=0A@@ -539,6 +539,7 @@ void printk(const char =
*fmt, ...)=0A void __init console_init_preirq(void)=0A {=0A     char =
*p;=0A+    int sh;=0A =0A     serial_init_preirq();=0A =0A@@ -551,8 +552,9 =
@@ void __init console_init_preirq(void)=0A             vga_init();=0A     =
    else if ( !strncmp(p, "none", 4) )=0A             continue;=0A-        =
else if ( strncmp(p, "com", 3) ||=0A-                  (sercon_handle =3D =
serial_parse_handle(p)) =3D=3D -1 )=0A+        else if ( (sh =3D serial_par=
se_handle(p)) >=3D 0 )=0A+            sercon_handle =3D sh;=0A+        =
else=0A         {=0A             char *q =3D strchr(p, ',');=0A            =
 if ( q !=3D NULL )=0A--- a/xen/drivers/char/serial.c=0A+++ b/xen/drivers/c=
har/serial.c=0A@@ -22,9 +22,11 @@ size_param("serial_tx_buffer", =
serial_tx=0A #define mask_serial_rxbuf_idx(_i) ((_i)&(serial_rxbufsz-1))=0A=
 #define mask_serial_txbuf_idx(_i) ((_i)&(serial_txbufsz-1))=0A =0A-static =
struct serial_port com[2] =3D {=0A-    { .rx_lock =3D SPIN_LOCK_UNLOCKED, =
.tx_lock =3D SPIN_LOCK_UNLOCKED }, =0A-    { .rx_lock =3D SPIN_LOCK_UNLOCKE=
D, .tx_lock =3D SPIN_LOCK_UNLOCKED }=0A+static struct serial_port =
com[SERHND_IDX + 1] =3D {=0A+    [0 ... SERHND_IDX] =3D {=0A+        =
.rx_lock =3D SPIN_LOCK_UNLOCKED,=0A+        .tx_lock =3D SPIN_LOCK_UNLOCKED=
=0A+    }=0A };=0A =0A void serial_rx_interrupt(struct serial_port *port, =
struct cpu_user_regs *regs)=0A@@ -81,6 +83,8 @@ void serial_tx_interrupt(st=
ruct serial_p=0A             port->driver->putc(=0A                 port, =
port->txbuf[mask_serial_txbuf_idx(port->txbufc++)]);=0A         }=0A+      =
  if ( i && port->driver->flush )=0A+            port->driver->flush(port);=
=0A     }=0A =0A     spin_unlock(&port->tx_lock);=0A@@ -175,6 +179,9 @@ =
void serial_putc(int handle, char c)=0A =0A     __serial_putc(port, c);=0A =
=0A+    if ( port->driver->flush )=0A+        port->driver->flush(port);=0A=
+=0A     spin_unlock_irqrestore(&port->tx_lock, flags);=0A }=0A =0A@@ =
-206,6 +213,9 @@ void serial_puts(int handle, const char =0A         =
__serial_putc(port, c);=0A     }=0A =0A+    if ( port->driver->flush )=0A+ =
       port->driver->flush(port);=0A+=0A     spin_unlock_irqrestore(&port->=
tx_lock, flags);=0A }=0A =0A@@ -261,10 +271,10 @@ int __init serial_parse_h=
andle(char *con=0A     switch ( conf[3] )=0A     {=0A     case '1':=0A-    =
    handle =3D 0;=0A+        handle =3D SERHND_COM1;=0A         break;=0A  =
   case '2':=0A-        handle =3D 1;=0A+        handle =3D SERHND_COM2;=0A=
         break;=0A     default:=0A         goto fail;=0A@@ -365,6 +375,8 =
@@ void serial_start_sync(int handle)=0A             port->driver->putc(=0A=
                 port, port->txbuf[mask_serial_txbuf_idx(port->txbufc++)]);=
=0A         }=0A+        if ( port->driver->flush )=0A+            =
port->driver->flush(port);=0A     }=0A =0A     spin_unlock_irqrestore(&port=
->tx_lock, flags);=0A--- a/xen/include/xen/serial.h=0A+++ b/xen/include/xen=
/serial.h=0A@@ -60,6 +60,8 @@ struct uart_driver {=0A     int  (*tx_empty)(=
struct serial_port *);=0A     /* Put a character onto the serial line. =
*/=0A     void (*putc)(struct serial_port *, char);=0A+    /* Flush =
accumulated characters. */=0A+    void (*flush)(struct serial_port *);=0A  =
   /* Get a character from the serial line: returns 0 if none available. =
*/=0A     int  (*getc)(struct serial_port *, char *);=0A     /* Get IRQ =
number for this port's serial line: returns -1 if none. */=0A@@ -67,10 =
+69,12 @@ struct uart_driver {=0A };=0A =0A /* 'Serial handles' are =
composed from the following fields. */=0A-#define SERHND_IDX      (1<<0) =
/* COM1 or COM2?                           */=0A-#define SERHND_HI       =
(1<<1) /* Mux/demux each transferred char by MSB. */=0A-#define SERHND_LO  =
     (1<<2) /* Ditto, except that the MSB is cleared.  */=0A-#define =
SERHND_COOKED   (1<<3) /* Newline/carriage-return translation?    =
*/=0A+#define SERHND_IDX      (3<<0) /* COM1 or COM2?                      =
     */=0A+# define SERHND_COM1    (0<<0)=0A+# define SERHND_COM2    =
(1<<0)=0A+#define SERHND_HI       (1<<2) /* Mux/demux each transferred =
char by MSB. */=0A+#define SERHND_LO       (1<<3) /* Ditto, except that =
the MSB is cleared.  */=0A+#define SERHND_COOKED   (1<<4) /* Newline/carria=
ge-return translation?    */=0A =0A /* Two-stage initialisation (before/aft=
er IRQ-subsystem initialisation). */=0A void serial_init_preirq(void);=0A
--=__Part6554771D.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

--=__Part6554771D.0__=--


From xen-devel-bounces@lists.xen.org Tue Sep 11 10:16:37 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 2012 10: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 1TBNW1-0002oe-Vk; Tue, 11 Sep 2012 10:16:21 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1TBNVz-0002oU-V8
	for xen-devel@lists.xen.org; Tue, 11 Sep 2012 10:16:20 +0000
Received: from [85.158.139.83:53981] by server-6.bemta-5.messagelabs.com id
	20/D3-21336-37F0F405; Tue, 11 Sep 2012 10:16:19 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1347358578!25918303!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQwNzc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2013 invoked from network); 11 Sep 2012 10:16:18 -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;
	11 Sep 2012 10:16:18 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 11 Sep 2012 11:16:17 +0100
Message-Id: <504F2B8F020000780009A800@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 11 Sep 2012 11:16: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="=__Part0736157F.0__="
Subject: [Xen-devel] [PATCH RFC 3/8] console: add EHCI debug port based
 serial console
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<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.

--=__Part0736157F.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Low level hardware interface pieces adapted from Linux.

For setup information, see Linux'es Documentation/x86/earlyprintk.txt
and/or http://www.coreboot.org/EHCI_Debug_Port.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

--- a/docs/misc/xen-command-line.markdown
+++ b/docs/misc/xen-command-line.markdown
@@ -244,7 +244,7 @@ A typical setup for most situations migh
 Specify the size of the console ring buffer.
=20
 ### console
-> `=3D List of [ vga | com1[H,L] | com2[H,L] | none ]`
+> `=3D List of [ vga | com1[H,L] | com2[H,L] | dbgp | none ]`
=20
 > Default: `console=3Dcom1,vga`
=20
@@ -260,6 +260,8 @@ the converse; transmitted and received c
 cleared.  This allows a single port to be shared by two subsystems
 (e.g. console and debugger).
=20
+`dbgp` indicates that Xen should use a USB debug port.
+
 `none` indicates that Xen should not use a console.  This option only
 makes sense on its own.
=20
@@ -352,6 +354,12 @@ combination with the `low_crashinfo` com
 ### credit2\_load\_window\_shift
 > `=3D <integer>`
=20
+### dbgp
+> `=3D ehci[ <integer> | @pci<bus>:<slot>.<func> ]`
+
+Specify the USB controller to use, either by instance number (when going
+over the PCI busses sequentially) or by PCI device (must be on segment =
0).
+
 ### debug\_stack\_lines
 > `=3D <integer>`
=20
--- a/xen/arch/x86/Rules.mk
+++ b/xen/arch/x86/Rules.mk
@@ -7,6 +7,7 @@ HAS_CPUFREQ :=3D y
 HAS_PCI :=3D y
 HAS_PASSTHROUGH :=3D y
 HAS_NS16550 :=3D y
+HAS_EHCI :=3D y
 HAS_KEXEC :=3D y
 HAS_GDBSX :=3D y
 xenoprof :=3D y
--- a/xen/arch/x86/physdev.c
+++ b/xen/arch/x86/physdev.c
@@ -8,6 +8,7 @@
 #include <xen/event.h>
 #include <xen/guest_access.h>
 #include <xen/iocap.h>
+#include <xen/serial.h>
 #include <asm/current.h>
 #include <asm/io_apic.h>
 #include <asm/msi.h>
@@ -722,6 +723,19 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_H
=20
         break;
     }
+
+    case PHYSDEVOP_dbgp_op: {
+        struct physdev_dbgp_op op;
+
+        if ( !IS_PRIV(v->domain) )
+            ret =3D -EPERM;
+        else if ( copy_from_guest(&op, arg, 1) )
+            ret =3D -EFAULT;
+        else
+            ret =3D dbgp_op(&op);
+        break;
+    }
+
     default:
         ret =3D -ENOSYS;
         break;
--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@ -606,6 +606,7 @@ void __init __start_xen(unsigned long mb
     ns16550.io_base =3D 0x2f8;
     ns16550.irq     =3D 3;
     ns16550_init(1, &ns16550);
+    ehci_dbgp_init();
     console_init_preirq();
=20
     printk("Bootloader: %s\n", loader);
--- a/xen/drivers/char/Makefile
+++ b/xen/drivers/char/Makefile
@@ -1,4 +1,5 @@
 obj-y +=3D console.o
 obj-$(HAS_NS16550) +=3D ns16550.o
 obj-$(HAS_PL011) +=3D pl011.o
+obj-$(HAS_EHCI) +=3D ehci-dbgp.o
 obj-y +=3D serial.o
--- /dev/null
+++ b/xen/drivers/char/ehci-dbgp.c
@@ -0,0 +1,1577 @@
+/*
+ * Standalone EHCI USB debug driver
+ *
+ * Hardware interface code based on the respective early console driver =
in
+ * Linux; see the Linux source for authorship and copyrights.
+ */
+
+#include <xen/config.h>
+#include <xen/console.h>
+#include <xen/delay.h>
+#include <xen/errno.h>
+#include <xen/pci.h>
+#include <xen/serial.h>
+#include <asm/byteorder.h>
+#include <asm/io.h>
+#include <asm/fixmap.h>
+#include <public/physdev.h>
+
+/* #define DBGP_DEBUG */
+
+/* EHCI register interface, corresponds to EHCI Revision 0.95 specificatio=
n */
+
+/* Section 2.2 Host Controller Capability Registers */
+struct ehci_caps {
+    /*
+     * These fields are specified as 8 and 16 bit registers,
+     * but some hosts can't perform 8 or 16 bit PCI accesses.
+     * some hosts treat caplength and hciversion as parts of a 32-bit
+     * register, others treat them as two separate registers, this
+     * affects the memory map for big endian controllers.
+     */
+    u32 hc_capbase;
+#define HC_LENGTH(p)      (0x00ff & (p)) /* bits 7:0 / offset 0x00 */
+#define HC_VERSION(p)     (0xffff & ((p) >> 16)) /* bits 31:16 / offset =
0x02 */
+
+    u32 hcs_params;       /* HCSPARAMS - offset 0x04 */
+#define HCS_DEBUG_PORT(p) (((p) >> 20) & 0xf) /* bits 23:20, debug port? =
*/
+#define HCS_INDICATOR(p)  ((p) & (1 << 16))   /* true: has port indicators=
 */
+#define HCS_N_CC(p)       (((p) >> 12) & 0xf) /* bits 15:12, #companion =
HCs */
+#define HCS_N_PCC(p)      (((p) >> 8) & 0xf)  /* bits 11:8, ports per CC =
*/
+#define HCS_PORTROUTED(p) ((p) & (1 << 7))    /* true: port routing */
+#define HCS_PPC(p)        ((p) & (1 << 4))    /* true: port power control =
*/
+#define HCS_N_PORTS(p)    (((p) >> 0) & 0xf)  /* bits 3:0, ports on HC */
+
+    u32 hcc_params;       /* HCCPARAMS - offset 0x08 */
+/* EHCI 1.1 addendum */
+#define HCC_32FRAME_PERIODIC_LIST(p) ((p) & (1 << 19))
+#define HCC_PER_PORT_CHANGE_EVENT(p) ((p) & (1 << 18))
+#define HCC_LPM(p)        ((p) & (1 << 17))
+#define HCC_HW_PREFETCH(p) ((p) & (1 << 16))
+#define HCC_EXT_CAPS(p)   (((p) >> 8) & 0xff) /* for pci extended caps */
+#define HCC_ISOC_CACHE(p) ((p) & (1 << 7))    /* true: can cache isoc =
frame */
+#define HCC_ISOC_THRES(p) (((p) >> 4) & 0x7)  /* bits 6:4, uframes cached =
*/
+#define HCC_CANPARK(p)    ((p) & (1 << 2))    /* true: can park on async =
qh */
+#define HCC_PGM_FRAMELISTLEN(p) ((p) & (1 << 1)) /* true: periodic_size =
changes */
+#define HCC_64BIT_ADDR(p) ((p) & 1)           /* true: can use 64-bit =
addr */
+
+    u8  portroute[8];     /* nibbles for routing - offset 0x0C */
+};
+
+/* Section 2.3 Host Controller Operational Registers */
+struct ehci_regs {
+    /* USBCMD: offset 0x00 */
+    u32 command;
+
+/* EHCI 1.1 addendum */
+#define CMD_HIRD        (0xf << 24) /* host initiated resume duration */
+#define CMD_PPCEE       (1 << 15)   /* per port change event enable */
+#define CMD_FSP         (1 << 14)   /* fully synchronized prefetch */
+#define CMD_ASPE        (1 << 13)   /* async schedule prefetch enable */
+#define CMD_PSPE        (1 << 12)   /* periodic schedule prefetch enable =
*/
+/* 23:16 is r/w intr rate, in microframes; default "8" =3D=3D 1/msec */
+#define CMD_PARK        (1 << 11)   /* enable "park" on async qh */
+#define CMD_PARK_CNT(c) (((c) >> 8) & 3) /* how many transfers to park =
for */
+#define CMD_LRESET      (1 << 7)    /* partial reset (no ports, etc) */
+#define CMD_IAAD        (1 << 6)    /* "doorbell" interrupt async advance =
*/
+#define CMD_ASE         (1 << 5)    /* async schedule enable */
+#define CMD_PSE         (1 << 4)    /* periodic schedule enable */
+/* 3:2 is periodic frame list size */
+#define CMD_RESET       (1 << 1)    /* reset HC not bus */
+#define CMD_RUN         (1 << 0)    /* start/stop HC */
+
+    /* USBSTS: offset 0x04 */
+    u32 status;
+#define STS_PPCE_MASK   (0xff << 16) /* Per-Port change event 1-16 */
+#define STS_ASS         (1 << 15)   /* Async Schedule Status */
+#define STS_PSS         (1 << 14)   /* Periodic Schedule Status */
+#define STS_RECL        (1 << 13)   /* Reclamation */
+#define STS_HALT        (1 << 12)   /* Not running (any reason) */
+/* some bits reserved */
+    /* these STS_* flags are also intr_enable bits (USBINTR) */
+#define STS_IAA         (1 << 5)    /* Interrupted on async advance */
+#define STS_FATAL       (1 << 4)    /* such as some PCI access errors */
+#define STS_FLR         (1 << 3)    /* frame list rolled over */
+#define STS_PCD         (1 << 2)    /* port change detect */
+#define STS_ERR         (1 << 1)    /* "error" completion (overflow, ...) =
*/
+#define STS_INT         (1 << 0)    /* "normal" completion (short, ...) =
*/
+
+    /* USBINTR: offset 0x08 */
+    u32 intr_enable;
+
+    /* FRINDEX: offset 0x0C */
+    u32 frame_index;    /* current microframe number */
+    /* CTRLDSSEGMENT: offset 0x10 */
+    u32 segment;    /* address bits 63:32 if needed */
+    /* PERIODICLISTBASE: offset 0x14 */
+    u32 frame_list;    /* points to periodic list */
+    /* ASYNCLISTADDR: offset 0x18 */
+    u32 async_next;    /* address of next async queue head */
+
+    u32 reserved[9];
+
+    /* CONFIGFLAG: offset 0x40 */
+    u32 configured_flag;
+#define FLAG_CF         (1 << 0)    /* true: we'll support "high speed" =
*/
+
+    /* PORTSC: offset 0x44 */
+    u32 port_status[0];    /* up to N_PORTS */
+/* EHCI 1.1 addendum */
+#define PORTSC_SUSPEND_STS_ACK   0
+#define PORTSC_SUSPEND_STS_NYET  1
+#define PORTSC_SUSPEND_STS_STALL 2
+#define PORTSC_SUSPEND_STS_ERR   3
+
+#define PORT_DEV_ADDR   (0x7f << 25) /* device address */
+#define PORT_SSTS       (0x3 << 23)  /* suspend status */
+/* 31:23 reserved */
+#define PORT_WKOC_E     (1 << 22)    /* wake on overcurrent (enable) */
+#define PORT_WKDISC_E   (1 << 21)    /* wake on disconnect (enable) */
+#define PORT_WKCONN_E   (1 << 20)    /* wake on connect (enable) */
+/* 19:16 for port testing */
+#define PORT_TEST(x)    (((x) & 0xf) << 16) /* Port Test Control */
+#define PORT_TEST_PKT   PORT_TEST(0x4) /* Port Test Control - packet test =
*/
+#define PORT_TEST_FORCE PORT_TEST(0x5) /* Port Test Control - force =
enable */
+#define PORT_LED_OFF    (0 << 14)
+#define PORT_LED_AMBER  (1 << 14)
+#define PORT_LED_GREEN  (2 << 14)
+#define PORT_LED_MASK   (3 << 14)
+#define PORT_OWNER      (1 << 13)    /* true: companion hc owns this port =
*/
+#define PORT_POWER      (1 << 12)    /* true: has power (see PPC) */
+#define PORT_USB11(x)   (((x) & (3 << 10)) =3D=3D (1 << 10)) /* USB 1.1 =
device */
+/* 11:10 for detecting lowspeed devices (reset vs release ownership) */
+/* 9 reserved */
+#define PORT_LPM        (1 << 9)     /* LPM transaction */
+#define PORT_RESET      (1 << 8)     /* reset port */
+#define PORT_SUSPEND    (1 << 7)     /* suspend port */
+#define PORT_RESUME     (1 << 6)     /* resume it */
+#define PORT_OCC        (1 << 5)     /* over current change */
+#define PORT_OC         (1 << 4)     /* over current active */
+#define PORT_PEC        (1 << 3)     /* port enable change */
+#define PORT_PE         (1 << 2)     /* port enable */
+#define PORT_CSC        (1 << 1)     /* connect status change */
+#define PORT_CONNECT    (1 << 0)     /* device connected */
+#define PORT_RWC_BITS   (PORT_CSC | PORT_PEC | PORT_OCC)
+};
+
+/*
+ * Appendix C, Debug port ... intended for use with special "debug =
devices"
+ * that can help if there's no serial console.  (nonstandard enumeration.)=

+ */
+struct ehci_dbg_port {
+    u32 control;
+#define DBGP_OWNER      (1 << 30)
+#define DBGP_ENABLED    (1 << 28)
+#define DBGP_DONE       (1 << 16)
+#define DBGP_INUSE      (1 << 10)
+#define DBGP_ERRCODE(x) (((x) >> 7) & 0x07)
+# define DBGP_ERR_BAD    1
+# define DBGP_ERR_SIGNAL 2
+#define DBGP_ERROR      (1 << 6)
+#define DBGP_GO         (1 << 5)
+#define DBGP_OUT        (1 << 4)
+#define DBGP_LEN        (0xf << 0)
+#define DBGP_CLAIM      (DBGP_OWNER | DBGP_ENABLED | DBGP_INUSE)
+    u32 pids;
+#define DBGP_PID_GET(x)         (((x) >> 16) & 0xff)
+#define DBGP_PID_SET(data, tok) (((data) << 8) | (tok))
+    u32 data03;
+    u32 data47;
+    u32 address;
+#define DBGP_EPADDR(dev, ep) (((dev) << 8) | (ep))
+};
+
+/* CONTROL REQUEST SUPPORT */
+
+/*
+ * USB directions
+ *
+ * This bit flag is used in endpoint descriptors' bEndpointAddress field.
+ * It's also one of three fields in control requests bRequestType.
+ */
+#define USB_DIR_OUT 0           /* to device */
+#define USB_DIR_IN  0x80        /* to host */
+
+/*
+ * USB types, the second of three bRequestType fields
+ */
+#define USB_TYPE_MASK     (0x03 << 5)
+#define USB_TYPE_STANDARD (0x00 << 5)
+#define USB_TYPE_CLASS    (0x01 << 5)
+#define USB_TYPE_VENDOR   (0x02 << 5)
+#define USB_TYPE_RESERVED (0x03 << 5)
+
+/*
+ * USB recipients, the third of three bRequestType fields
+ */
+#define USB_RECIP_MASK      0x1f
+#define USB_RECIP_DEVICE    0x00
+#define USB_RECIP_INTERFACE 0x01
+#define USB_RECIP_ENDPOINT  0x02
+#define USB_RECIP_OTHER     0x03
+/* From Wireless USB 1.0 */
+#define USB_RECIP_PORT      0x04
+#define USB_RECIP_RPIPE     0x05
+
+/*
+ * Standard requests, for the bRequest field of a SETUP packet.
+ *
+ * These are qualified by the bRequestType field, so that for example
+ * TYPE_CLASS or TYPE_VENDOR specific feature flags could be retrieved
+ * by a GET_STATUS request.
+ */
+#define USB_REQ_GET_STATUS        0x00
+#define USB_REQ_CLEAR_FEATURE     0x01
+#define USB_REQ_SET_FEATURE       0x03
+#define USB_REQ_SET_ADDRESS       0x05
+#define USB_REQ_GET_DESCRIPTOR    0x06
+#define USB_REQ_SET_DESCRIPTOR    0x07
+#define USB_REQ_GET_CONFIGURATION 0x08
+#define USB_REQ_SET_CONFIGURATION 0x09
+#define USB_REQ_GET_INTERFACE     0x0A
+#define USB_REQ_SET_INTERFACE     0x0B
+#define USB_REQ_SYNCH_FRAME       0x0C
+
+#define USB_DEVICE_DEBUG_MODE        6    /* (special devices only) */
+
+/**
+ * struct usb_ctrlrequest - SETUP data for a USB device control request
+ * @bRequestType: matches the USB bmRequestType field
+ * @bRequest: matches the USB bRequest field
+ * @wValue: matches the USB wValue field (le16 byte order)
+ * @wIndex: matches the USB wIndex field (le16 byte order)
+ * @wLength: matches the USB wLength field (le16 byte order)
+ *
+ * This structure is used to send control requests to a USB device.  It =
matches
+ * the different fields of the USB 2.0 Spec section 9.3, table 9-2.  See =
the
+ * USB spec for a fuller description of the different fields, and what =
they are
+ * used for.
+ *
+ * Note that the driver for any interface can issue control requests.
+ * For most devices, interfaces don't coordinate with each other, so
+ * such requests may be made at any time.
+ */
+struct usb_ctrlrequest {
+    u8 bRequestType;
+    u8 bRequest;
+    __le16 wValue;
+    __le16 wIndex;
+    __le16 wLength;
+} __attribute__ ((packed));
+
+/* USB_DT_DEBUG: for special highspeed devices, replacing serial console =
*/
+
+#define USB_DT_DEBUG    0x0a
+
+struct usb_debug_descriptor {
+    u8 bLength;
+    u8 bDescriptorType;
+    /* bulk endpoints with 8 byte maxpacket */
+    u8 bDebugInEndpoint;
+    u8 bDebugOutEndpoint;
+} __attribute__((packed));
+
+#define USB_DEBUG_DEVNUM 127
+
+/*
+ * USB Packet IDs (PIDs)
+ */
+
+/* token */
+#define USB_PID_OUT           0xe1
+#define USB_PID_IN            0x69
+#define USB_PID_SOF           0xa5
+#define USB_PID_SETUP         0x2d
+/* handshake */
+#define USB_PID_ACK           0xd2
+#define USB_PID_NAK           0x5a
+#define USB_PID_STALL         0x1e
+#define USB_PID_NYET          0x96
+/* data */
+#define USB_PID_DATA0         0xc3
+#define USB_PID_DATA1         0x4b
+#define USB_PID_DATA2         0x87
+#define USB_PID_MDATA         0x0f
+/* Special */
+#define USB_PID_PREAMBLE      0x3c
+#define USB_PID_ERR           0x3c
+#define USB_PID_SPLIT         0x78
+#define USB_PID_PING          0xb4
+#define USB_PID_UNDEF_0       0xf0
+
+#define PCI_CLASS_SERIAL_USB_EHCI 0x0c0320
+#define PCI_CAP_ID_EHCI_DEBUG     0x0a
+
+#define HUB_ROOT_RESET_TIME   50    /* times are in msec */
+#define HUB_SHORT_RESET_TIME  10
+#define HUB_LONG_RESET_TIME   200
+#define HUB_RESET_TIMEOUT     500
+
+#define DBGP_MAX_PACKET       8
+#define DBGP_LOOPS            1000
+#define DBGP_TIMEOUT          (250 * 1000) /* us */
+#define DBGP_CHECK_INTERVAL   100 /* us */
+/* This one can be set arbitrarily - only affects input responsiveness: =
*/
+#define DBGP_IDLE_INTERVAL    100 /* ms */
+
+struct ehci_dbgp {
+    struct ehci_dbg_port __iomem *ehci_debug;
+    enum dbgp_state {
+        dbgp_idle,
+        dbgp_out,
+        dbgp_in,
+        dbgp_ctrl,
+        dbgp_unsafe /* cannot use debug device during EHCI reset */
+    } state;
+    unsigned int phys_port;
+    struct {
+        unsigned int endpoint;
+        unsigned int chunk;
+        char buf[DBGP_MAX_PACKET];
+    } out, in;
+    unsigned long timeout;
+    struct timer timer;
+    spinlock_t *lock;
+    bool_t reset_run;
+    u8 bus, slot, func, bar;
+    u16 pci_cr;
+    u32 bar_val;
+    unsigned int cap;
+    struct ehci_regs __iomem *ehci_regs;
+    struct ehci_caps __iomem *ehci_caps;
+};
+
+static int ehci_dbgp_external_startup(struct ehci_dbgp *);
+
+static void ehci_dbgp_status(struct ehci_dbgp *dbgp, const char *str)
+{
+#ifdef DBGP_DEBUG
+#define dbgp_printk printk
+    if ( !dbgp->ehci_debug )
+        return;
+    dbgp_printk("dbgp: %s\n", str);
+    dbgp_printk("  debug control: %08x\n", readl(&dbgp->ehci_debug->contro=
l));
+    dbgp_printk("  EHCI cmd     : %08x\n", readl(&dbgp->ehci_regs->command=
));
+    dbgp_printk("  EHCI conf flg: %08x\n",
+                readl(&dbgp->ehci_regs->configured_flag));
+    dbgp_printk("  EHCI status  : %08x\n", readl(&dbgp->ehci_regs->status)=
);
+    dbgp_printk("  EHCI portsc  : %08x\n",
+                readl(&dbgp->ehci_regs->port_status[dbgp->phys_port - =
1]));
+#endif
+}
+
+#ifndef DBGP_DEBUG
+static inline __attribute__ ((format (printf, 1, 2))) void
+dbgp_printk(const char *fmt, ...) { }
+#endif
+
+static inline u32 dbgp_len_update(u32 x, u32 len)
+{
+    return (x & ~DBGP_LEN) | (len & DBGP_LEN) | DBGP_OUT;
+}
+
+static inline u32 dbgp_pid_write_update(u32 x, u32 tok)
+{
+    static u8 data0 =3D USB_PID_DATA1;
+
+    data0 ^=3D USB_PID_DATA0 ^ USB_PID_DATA1;
+    return (x & 0xffff0000) | (data0 << 8) | (tok & 0xff);
+}
+
+static inline u32 dbgp_pid_read_update(u32 x, u32 tok)
+{
+    return (x & 0xffffff00) | (tok & 0xff);
+}
+
+static inline void dbgp_set_data(struct ehci_dbg_port __iomem *ehci_debug,=

+                                 const void *buf, unsigned int size)
+{
+    const unsigned char *bytes =3D buf;
+    u32 lo =3D 0, hi =3D 0;
+    unsigned int i;
+
+    for ( i =3D 0; i < 4 && i < size; i++ )
+        lo |=3D bytes[i] << (8 * i);
+    for ( ; i < 8 && i < size; i++ )
+        hi |=3D bytes[i] << (8 * (i - 4));
+    writel(lo, &ehci_debug->data03);
+    writel(hi, &ehci_debug->data47);
+}
+
+static inline void dbgp_get_data(struct ehci_dbg_port __iomem *ehci_debug,=

+                                 void *buf, int size)
+{
+    unsigned char *bytes =3D buf;
+    u32 lo =3D readl(&ehci_debug->data03);
+    u32 hi =3D readl(&ehci_debug->data47);
+    unsigned int i;
+
+    for ( i =3D 0; i < 4 && i < size; i++ )
+        bytes[i] =3D (lo >> (8 * i)) & 0xff;
+    for ( ; i < 8 && i < size; i++ )
+        bytes[i] =3D (hi >> (8 * (i - 4))) & 0xff;
+}
+
+static void dbgp_issue_command(struct ehci_dbgp *dbgp, u32 ctrl,
+                               enum dbgp_state state)
+{
+    u32 cmd =3D readl(&dbgp->ehci_regs->command);
+
+    if ( unlikely(!(cmd & CMD_RUN)) )
+    {
+        /*
+         * If the EHCI controller is not in the run state do extended
+         * checks to see if ACPI or some other initialization also
+         * reset the EHCI debug port.
+         */
+        u32 ctrl =3D readl(&dbgp->ehci_debug->control);
+
+        if ( ctrl & DBGP_ENABLED )
+        {
+            cmd |=3D CMD_RUN;
+            writel(cmd, &dbgp->ehci_regs->command);
+            dbgp->reset_run =3D 1;
+        }
+        else if ( dbgp->state !=3D dbgp_unsafe )
+        {
+            dbgp->state =3D dbgp_unsafe;
+            ehci_dbgp_external_startup(dbgp);
+        }
+    }
+
+    writel(ctrl | DBGP_GO, &dbgp->ehci_debug->control);
+    dbgp->timeout =3D DBGP_TIMEOUT;
+    if ( dbgp->state !=3D dbgp_unsafe )
+        dbgp->state =3D state;
+}
+
+static int dbgp_check_for_completion(struct ehci_dbgp *dbgp,
+                                     unsigned int interval, u8 *ppid)
+{
+    u32 ctrl;
+    int ret;
+
+    if ( dbgp->state =3D=3D dbgp_idle )
+        return 0;
+
+    ctrl =3D readl(&dbgp->ehci_debug->control) & ~DBGP_GO;
+    if ( !(ctrl & DBGP_DONE) )
+    {
+        if ( dbgp->timeout > interval )
+            dbgp->timeout -=3D interval;
+        else if ( interval )
+        {
+            /* See the timeout related comment in dbgp_wait_until_done(). =
*/
+            dbgp->state =3D dbgp_unsafe;
+            dbgp->timeout =3D 0;
+        }
+        return -DBGP_TIMEOUT;
+    }
+
+    if ( ctrl & DBGP_ERROR )
+    {
+        ret =3D -DBGP_ERRCODE(ctrl);
+        if ( ret =3D=3D -DBGP_ERR_BAD && dbgp->timeout > interval )
+            ctrl |=3D DBGP_GO;
+    }
+    else
+    {
+        u8 pid =3D DBGP_PID_GET(readl(&dbgp->ehci_debug->pids));
+
+        ret =3D ctrl & DBGP_LEN;
+        if ( ppid )
+            *ppid =3D pid;
+        else if ( dbgp->state =3D=3D dbgp_in )
+        {
+            dbgp_get_data(dbgp->ehci_debug, dbgp->in.buf, ret);
+            dbgp->in.chunk =3D ret;
+        }
+        else if ( pid =3D=3D USB_PID_NAK && dbgp->timeout > interval )
+            ctrl |=3D DBGP_GO;
+    }
+
+    writel(ctrl, &dbgp->ehci_debug->control);
+    if ( ctrl & DBGP_GO )
+    {
+        dbgp->timeout -=3D interval;
+        return -DBGP_TIMEOUT;
+    }
+
+    if ( unlikely(dbgp->reset_run) )
+    {
+        writel(readl(&dbgp->ehci_regs->command) & ~CMD_RUN,
+               &dbgp->ehci_regs->command);
+        dbgp->reset_run =3D 0;
+    }
+
+    if ( dbgp->state !=3D dbgp_unsafe )
+        dbgp->state =3D dbgp_idle;
+
+    return ret;
+}
+
+static int dbgp_wait_until_complete(struct ehci_dbgp *dbgp, u8 *ppid)
+{
+    unsigned int loop =3D DBGP_TIMEOUT;
+    int ret;
+
+    do {
+        ret =3D dbgp_check_for_completion(dbgp, 0, ppid);
+        if ( ret !=3D -DBGP_TIMEOUT )
+            break;
+        udelay(1);
+    } while ( --loop );
+
+    if ( !ppid && !loop )
+        dbgp->state =3D dbgp_unsafe;
+
+    return ret;
+}
+
+static inline void dbgp_mdelay(unsigned int ms)
+{
+    while ( ms-- )
+    {
+        unsigned int i;
+
+        for ( i =3D 0; i < 1000; i++ )
+            outb(0x1, 0x80);
+    }
+}
+
+static void dbgp_breathe(void)
+{
+    /* Sleep to give the debug port a chance to breathe. */
+    dbgp_mdelay(1);
+}
+
+static int dbgp_wait_until_done(struct ehci_dbgp *dbgp, u32 ctrl,
+                                unsigned int loop)
+{
+    int ret;
+
+    dbgp->timeout =3D 0;
+
+    for ( ; ; writel(ctrl | DBGP_GO, &dbgp->ehci_debug->control) )
+    {
+        u8 pid;
+
+        ret =3D dbgp_wait_until_complete(dbgp, &pid);
+        if ( ret < 0 )
+        {
+            /*
+             * A -DBGP_TIMEOUT failure here means the device has failed,
+             * perhaps because it was unplugged, in which case we do not
+             * want to hang the system so the dbgp will be marked as =
unsafe
+             * to use. EHCI reset is the only way to recover if you =
unplug
+             * the dbgp device.
+             */
+            if ( ret =3D=3D -DBGP_TIMEOUT )
+                dbgp->state =3D dbgp_unsafe;
+            if ( ret !=3D -DBGP_ERR_BAD || !--loop )
+                break;
+        }
+        else
+        {
+            /*
+             * If the port is getting full or it has dropped data
+             * start pacing ourselves, not necessary but it's friendly.
+             */
+            if ( pid =3D=3D USB_PID_NAK || pid =3D=3D USB_PID_NYET )
+                dbgp_breathe();
+
+            /* If we got a NACK, reissue the transmission. */
+            if ( pid !=3D USB_PID_NAK || !--loop )
+                break;
+        }
+    }
+
+    return ret;
+}
+
+static int dbgp_bulk_write(struct ehci_dbgp *dbgp,
+                           unsigned int devnum, unsigned int endpoint,
+                           const void *bytes, unsigned int size, u32 =
*pctrl)
+{
+    u32 addr, pids, ctrl;
+
+    if ( size > DBGP_MAX_PACKET )
+        return -EINVAL;
+
+    addr =3D DBGP_EPADDR(devnum, endpoint);
+    pids =3D dbgp_pid_write_update(readl(&dbgp->ehci_debug->pids), =
USB_PID_OUT);
+    ctrl =3D dbgp_len_update(readl(&dbgp->ehci_debug->control), size);
+    if ( pctrl )
+        *pctrl =3D ctrl;
+
+    dbgp_set_data(dbgp->ehci_debug, bytes, size);
+    writel(addr, &dbgp->ehci_debug->address);
+    writel(pids, &dbgp->ehci_debug->pids);
+    dbgp_issue_command(dbgp, ctrl, dbgp_out);
+
+    return 0;
+}
+
+static int dbgp_bulk_read(struct ehci_dbgp *dbgp,
+                          unsigned int devnum, unsigned int endpoint,
+                          unsigned int size, u32 *pctrl)
+{
+    u32 addr, pids, ctrl;
+
+    if ( size > DBGP_MAX_PACKET )
+        return -EINVAL;
+
+    addr =3D DBGP_EPADDR(devnum, endpoint);
+    pids =3D dbgp_pid_read_update(readl(&dbgp->ehci_debug->pids), =
USB_PID_IN);
+    ctrl =3D readl(&dbgp->ehci_debug->control) & ~DBGP_OUT;
+
+    writel(addr, &dbgp->ehci_debug->address);
+    writel(pids, &dbgp->ehci_debug->pids);
+    if ( likely(!pctrl) )
+        dbgp_issue_command(dbgp, ctrl, dbgp_in);
+    else
+        dbgp_issue_command(dbgp, *pctrl =3D ctrl, dbgp_ctrl);
+
+    return 0;
+}
+
+static int dbgp_control_msg(struct ehci_dbgp *dbgp, unsigned int devnum,
+                            int requesttype, int request, int value,
+                            int index, void *data, unsigned int size)
+{
+    u32 addr, pids, ctrl;
+    struct usb_ctrlrequest req;
+    bool_t read =3D (requesttype & USB_DIR_IN) !=3D 0;
+    int ret;
+
+    if ( size > (read ? DBGP_MAX_PACKET : 0) )
+        return -EINVAL;
+
+    /* Compute the control message */
+    req.bRequestType =3D requesttype;
+    req.bRequest =3D request;
+    req.wValue =3D cpu_to_le16(value);
+    req.wIndex =3D cpu_to_le16(index);
+    req.wLength =3D cpu_to_le16(size);
+
+    pids =3D DBGP_PID_SET(USB_PID_DATA0, USB_PID_SETUP);
+    addr =3D DBGP_EPADDR(devnum, 0);
+    ctrl =3D dbgp_len_update(readl(&dbgp->ehci_debug->control), sizeof(req=
));
+
+    /* Send the setup message */
+    dbgp_set_data(dbgp->ehci_debug, &req, sizeof(req));
+    writel(addr, &dbgp->ehci_debug->address);
+    writel(pids, &dbgp->ehci_debug->pids);
+    dbgp_issue_command(dbgp, ctrl, dbgp_ctrl);
+    ret =3D dbgp_wait_until_done(dbgp, ctrl, DBGP_LOOPS);
+    if ( ret < 0 )
+        return ret;
+
+    /* Read the result */
+    ret =3D dbgp_bulk_read(dbgp, devnum, 0, size, &ctrl);
+    if ( !ret )
+        ret =3D dbgp_wait_until_done(dbgp, ctrl, DBGP_LOOPS);
+    if ( ret > 0 )
+    {
+        if ( size > ret )
+            size =3D ret;
+        dbgp_get_data(dbgp->ehci_debug, data, size);
+    }
+
+    return ret;
+}
+
+static unsigned int __init __find_dbgp(u8 bus, u8 slot, u8 func)
+{
+    u32 class =3D pci_conf_read32(0, bus, slot, func, PCI_CLASS_REVISION);=

+
+    if ( (class >> 8) !=3D PCI_CLASS_SERIAL_USB_EHCI )
+        return 0;
+
+    return pci_find_cap_offset(0, bus, slot, func, PCI_CAP_ID_EHCI_DEBUG);=

+}
+
+static unsigned int __init find_dbgp(struct ehci_dbgp *dbgp,
+                                     unsigned int ehci_num)
+{
+    unsigned int bus, slot, func;
+
+    for ( bus =3D 0; bus < 256; bus++ )
+    {
+        for ( slot =3D 0; slot < 32; slot++ )
+        {
+            for ( func =3D 0; func < 8; func++ )
+            {
+                unsigned int cap;
+
+                if ( !pci_device_detect(0, bus, slot, func) )
+                {
+                    if ( !func )
+                        break;
+                    continue;
+                }
+
+                cap =3D __find_dbgp(bus, slot, func);
+                if ( !cap || ehci_num-- )
+                {
+                    if ( !func && !(pci_conf_read8(0, bus, slot, func,
+                                                   PCI_HEADER_TYPE) & =
0x80) )
+                        break;
+                    continue;
+                }
+
+                dbgp->bus =3D bus;
+                dbgp->slot =3D slot;
+                dbgp->func =3D func;
+                return cap;
+            }
+        }
+    }
+
+    return 0;
+}
+
+static int ehci_dbgp_startup(struct ehci_dbgp *dbgp)
+{
+    u32 ctrl, cmd, status;
+    unsigned int loop;
+
+    /* Claim ownership, but do not enable yet */
+    ctrl =3D readl(&dbgp->ehci_debug->control);
+    ctrl |=3D DBGP_OWNER;
+    ctrl &=3D ~(DBGP_ENABLED | DBGP_INUSE);
+    writel(ctrl, &dbgp->ehci_debug->control);
+    udelay(1);
+
+    ehci_dbgp_status(dbgp, "EHCI startup");
+    /* Start the EHCI. */
+    cmd =3D readl(&dbgp->ehci_regs->command);
+    cmd &=3D ~(CMD_LRESET | CMD_IAAD | CMD_PSE | CMD_ASE | CMD_RESET);
+    cmd |=3D CMD_RUN;
+    writel(cmd, &dbgp->ehci_regs->command);
+
+    /* Ensure everything is routed to the EHCI */
+    writel(FLAG_CF, &dbgp->ehci_regs->configured_flag);
+
+    /* Wait until the controller is no longer halted. */
+    loop =3D 1000;
+    do {
+        status =3D readl(&dbgp->ehci_regs->status);
+        if ( !(status & STS_HALT) )
+            break;
+        udelay(1);
+    } while ( --loop );
+
+    if ( !loop )
+    {
+        dbgp_printk("EHCI cannot be started\n");
+        return -ENODEV;
+    }
+    dbgp_printk("EHCI started\n");
+
+    return 0;
+}
+
+static int ehci_dbgp_controller_reset(struct ehci_dbgp *dbgp)
+{
+    unsigned int loop =3D 250 * 1000;
+    u32 cmd;
+
+    /* Reset the EHCI controller */
+    cmd =3D readl(&dbgp->ehci_regs->command);
+    cmd |=3D CMD_RESET;
+    writel(cmd, &dbgp->ehci_regs->command);
+    do {
+        cmd =3D readl(&dbgp->ehci_regs->command);
+    } while ( (cmd & CMD_RESET) && --loop );
+
+    if ( !loop )
+    {
+        dbgp_printk("cannot reset EHCI\n");
+        return -1;
+    }
+    ehci_dbgp_status(dbgp, "ehci reset done");
+
+    return 0;
+}
+
+static int ehci_reset_port(struct ehci_dbgp *dbgp, unsigned int port)
+{
+    u32 portsc, delay_time, delay;
+
+    ehci_dbgp_status(dbgp, "reset port");
+    /* Reset the USB debug port. */
+    portsc =3D readl(&dbgp->ehci_regs->port_status[port - 1]);
+    portsc &=3D ~PORT_PE;
+    portsc |=3D PORT_RESET;
+    writel(portsc, &dbgp->ehci_regs->port_status[port - 1]);
+
+    delay =3D HUB_ROOT_RESET_TIME;
+    for ( delay_time =3D 0; delay_time < HUB_RESET_TIMEOUT;
+          delay_time +=3D delay )
+    {
+        dbgp_mdelay(delay);
+        portsc =3D readl(&dbgp->ehci_regs->port_status[port - 1]);
+        if (!(portsc & PORT_RESET))
+            break;
+    }
+
+    if ( portsc & PORT_RESET )
+    {
+        /* force reset to complete */
+        unsigned int loop =3D 100 * 1000;
+
+        writel(portsc & ~(PORT_RWC_BITS | PORT_RESET),
+               &dbgp->ehci_regs->port_status[port - 1]);
+        do {
+            udelay(1);
+            portsc =3D readl(&dbgp->ehci_regs->port_status[port-1]);
+        } while ( (portsc & PORT_RESET) && --loop );
+    }
+
+    /* Device went away? */
+    if ( !(portsc & PORT_CONNECT) )
+        return -ENOTCONN;
+
+    /* bomb out completely if something weird happened */
+    if ( portsc & PORT_CSC )
+        return -EINVAL;
+
+    /* If we've finished resetting, then break out of the loop */
+    if ( !(portsc & PORT_RESET) && (portsc & PORT_PE) )
+        return 0;
+
+    return -EBUSY;
+}
+
+static int ehci_wait_for_port(struct ehci_dbgp *dbgp, unsigned int port)
+{
+    u32 status;
+    unsigned int reps;
+
+    for ( reps =3D 0; reps < 300; reps++ )
+    {
+        status =3D readl(&dbgp->ehci_regs->status);
+        if ( status & STS_PCD )
+            break;
+        dbgp_mdelay(1);
+    }
+
+    return ehci_reset_port(dbgp, port) =3D=3D 0 ? 0 : -ENOTCONN;
+}
+
+/* Return 0 on success
+ * Return -ENODEV for any general failure
+ * Return -EIO if wait for port fails
+ */
+static int ehci_dbgp_external_startup(struct ehci_dbgp *dbgp)
+{
+    unsigned int devnum;
+    struct usb_debug_descriptor dbgp_desc;
+    int ret;
+    u32 ctrl, portsc, cmd;
+    unsigned int dbg_port =3D dbgp->phys_port;
+    unsigned int tries =3D 3;
+    unsigned int reset_port_tries =3D 1;
+    bool_t try_hard_once =3D 1;
+
+try_port_reset_again:
+    ret =3D ehci_dbgp_startup(dbgp);
+    if ( ret )
+        return ret;
+
+    /* Wait for a device to show up in the debug port */
+    ret =3D ehci_wait_for_port(dbgp, dbg_port);
+    if ( ret < 0 )
+    {
+        portsc =3D readl(&dbgp->ehci_regs->port_status[dbg_port - 1]);
+        if ( !(portsc & PORT_CONNECT) && try_hard_once )
+        {
+            /*
+             * Last ditch effort to try to force enable the debug device =
by
+             * using the packet test EHCI command to try and wake it up.
+             */
+            try_hard_once =3D 0;
+            cmd =3D readl(&dbgp->ehci_regs->command);
+            cmd &=3D ~CMD_RUN;
+            writel(cmd, &dbgp->ehci_regs->command);
+            portsc =3D readl(&dbgp->ehci_regs->port_status[dbg_port - =
1]);
+            portsc |=3D PORT_TEST_PKT;
+            writel(portsc, &dbgp->ehci_regs->port_status[dbg_port - 1]);
+            ehci_dbgp_status(dbgp, "Trying to force debug port online");
+            mdelay(50);
+            ehci_dbgp_controller_reset(dbgp);
+            goto try_port_reset_again;
+        }
+        else if ( reset_port_tries-- )
+            goto try_port_reset_again;
+        dbgp_printk("no device found in debug port\n");
+        return -EIO;
+    }
+    ehci_dbgp_status(dbgp, "wait for port done");
+
+    /* Enable the debug port */
+    ctrl =3D readl(&dbgp->ehci_debug->control);
+    ctrl |=3D DBGP_CLAIM;
+    writel(ctrl, &dbgp->ehci_debug->control);
+    ctrl =3D readl(&dbgp->ehci_debug->control);
+    if ( (ctrl & DBGP_CLAIM) !=3D DBGP_CLAIM )
+    {
+        dbgp_printk("no device in debug port\n");
+        writel(ctrl & ~DBGP_CLAIM, &dbgp->ehci_debug->control);
+        return -ENODEV;
+    }
+    ehci_dbgp_status(dbgp, "debug port enabled");
+
+    /* Completely transfer the debug device to the debug controller */
+    portsc =3D readl(&dbgp->ehci_regs->port_status[dbg_port - 1]);
+    portsc &=3D ~PORT_PE;
+    writel(portsc, &dbgp->ehci_regs->port_status[dbg_port - 1]);
+
+    dbgp_mdelay(100);
+
+try_again:
+    /* Find the debug device and make it device number 127 */
+    for ( devnum =3D 0; devnum <=3D 127; devnum++ )
+    {
+        ret =3D dbgp_control_msg(dbgp, devnum,
+                               USB_DIR_IN | USB_TYPE_STANDARD | USB_RECIP_=
DEVICE,
+                               USB_REQ_GET_DESCRIPTOR, (USB_DT_DEBUG << =
8), 0,
+                               &dbgp_desc, sizeof(dbgp_desc));
+        if ( ret > 0 )
+            break;
+    }
+    if ( devnum > 127 )
+    {
+        dbgp_printk("could not find attached debug device\n");
+        goto err;
+    }
+    if ( ret < 0 )
+    {
+        dbgp_printk("attached device is not a debug device\n");
+        goto err;
+    }
+    dbgp->out.endpoint =3D dbgp_desc.bDebugOutEndpoint;
+    dbgp->in.endpoint =3D dbgp_desc.bDebugInEndpoint;
+
+    /* Move the device to 127 if it isn't already there. */
+    if ( devnum !=3D USB_DEBUG_DEVNUM )
+    {
+        ret =3D dbgp_control_msg(dbgp, devnum,
+                               USB_DIR_OUT | USB_TYPE_STANDARD | =
USB_RECIP_DEVICE,
+                               USB_REQ_SET_ADDRESS, USB_DEBUG_DEVNUM, 0, =
NULL, 0);
+        if ( ret < 0 )
+        {
+            dbgp_printk("could not move attached device to %d\n",
+                        USB_DEBUG_DEVNUM);
+            goto err;
+        }
+        devnum =3D USB_DEBUG_DEVNUM;
+        dbgp_printk("debug device renamed to 127\n");
+    }
+
+    /* Enable the debug interface */
+    ret =3D dbgp_control_msg(dbgp, USB_DEBUG_DEVNUM,
+                           USB_DIR_OUT | USB_TYPE_STANDARD | USB_RECIP_DEV=
ICE,
+                           USB_REQ_SET_FEATURE, USB_DEVICE_DEBUG_MODE,
+                           0, NULL, 0);
+    if ( ret < 0 )
+    {
+        dbgp_printk("could not enable the debug device\n");
+        goto err;
+    }
+    dbgp_printk("debug interface enabled\n");
+
+    /* Perform a small write to get the even/odd data state in sync. */
+    ret =3D dbgp_bulk_write(dbgp, USB_DEBUG_DEVNUM, dbgp->out.endpoint,
+                          "\n", 1, &ctrl);
+    if ( !ret )
+        ret =3D dbgp_wait_until_done(dbgp, ctrl, DBGP_LOOPS);
+    if ( ret < 0 )
+    {
+        dbgp_printk("dbgp_bulk_write failed: %d\n", ret);
+        goto err;
+    }
+    dbgp_printk("small write done\n");
+    dbgp->state =3D dbgp_idle;
+
+    return 0;
+err:
+    if ( tries-- )
+        goto try_again;
+    return -ENODEV;
+}
+
+typedef void (*set_debug_port_t)(struct ehci_dbgp *, unsigned int);
+
+static void default_set_debug_port(struct ehci_dbgp *dbgp, unsigned int =
port)
+{
+}
+
+static set_debug_port_t __read_mostly set_debug_port =3D default_set_debug=
_port;
+
+static void nvidia_set_debug_port(struct ehci_dbgp *dbgp, unsigned int =
port)
+{
+    u32 dword =3D pci_conf_read32(0, dbgp->bus, dbgp->slot, dbgp->func, =
0x74);
+
+    dword &=3D ~(0x0f << 12);
+    dword |=3D (port & 0x0f) << 12;
+    pci_conf_write32(0, dbgp->bus, dbgp->slot, dbgp->func, 0x74, dword);
+    dbgp_printk("set debug port to %u\n", port);
+}
+
+static void __init detect_set_debug_port(struct ehci_dbgp *dbgp)
+{
+    if ( pci_conf_read16(0, dbgp->bus, dbgp->slot, dbgp->func,
+                         PCI_VENDOR_ID) =3D=3D 0x10de )
+    {
+        dbgp_printk("using nvidia set_debug_port\n");
+        set_debug_port =3D nvidia_set_debug_port;
+    }
+}
+
+/*
+ * The code in ehci_dbgp_bios_handoff() is derived from the USB PCI
+ * quirk initialization in Linux.
+ */
+#define EHCI_USBLEGSUP_BIOS    (1 << 16) /* BIOS semaphore */
+#define EHCI_USBLEGCTLSTS      4        /* legacy control/status */
+static void ehci_dbgp_bios_handoff(struct ehci_dbgp *dbgp, u32 hcc_params)=

+{
+    u32 cap;
+    unsigned int offset =3D HCC_EXT_CAPS(hcc_params);
+    int msec;
+
+    if ( !offset )
+        return;
+
+    cap =3D pci_conf_read32(0, dbgp->bus, dbgp->slot, dbgp->func, =
offset);
+    dbgp_printk("dbgp: EHCI BIOS state %08x\n", cap);
+
+    if ( (cap & 0xff) =3D=3D 1 && (cap & EHCI_USBLEGSUP_BIOS) )
+    {
+        dbgp_printk("dbgp: BIOS handoff\n");
+        pci_conf_write8(0, dbgp->bus, dbgp->slot, dbgp->func, offset + 3, =
1);
+    }
+
+    /* if boot firmware now owns EHCI, spin till it hands it over. */
+    msec =3D 1000;
+    while ( (cap & EHCI_USBLEGSUP_BIOS) && (msec > 0) )
+    {
+        mdelay(10);
+        msec -=3D 10;
+        cap =3D pci_conf_read32(0, dbgp->bus, dbgp->slot, dbgp->func, =
offset);
+    }
+
+    if ( cap & EHCI_USBLEGSUP_BIOS )
+    {
+        /* well, possibly buggy BIOS... try to shut it down,
+         * and hope nothing goes too wrong */
+        dbgp_printk("dbgp: BIOS handoff failed: %08x\n", cap);
+        pci_conf_write8(0, dbgp->bus, dbgp->slot, dbgp->func, offset + 2, =
0);
+    }
+
+    /* just in case, always disable EHCI SMIs */
+    pci_conf_write8(0, dbgp->bus, dbgp->slot, dbgp->func,
+                    offset + EHCI_USBLEGCTLSTS, 0);
+}
+
+static int ehci_dbgp_setup(struct ehci_dbgp *dbgp)
+{
+    u32 ctrl, portsc, hcs_params;
+    unsigned int i, debug_port, new_debug_port =3D 0, n_ports;
+    unsigned int port_map_tried, playtimes =3D 3;
+    int ret;
+
+    ehci_dbgp_bios_handoff(dbgp, readl(&dbgp->ehci_caps->hcc_params));
+
+try_next_time:
+    port_map_tried =3D 0;
+
+try_next_port:
+
+    hcs_params =3D readl(&dbgp->ehci_caps->hcs_params);
+    debug_port =3D HCS_DEBUG_PORT(hcs_params);
+    dbgp->phys_port =3D debug_port;
+    n_ports =3D HCS_N_PORTS(hcs_params);
+
+    dbgp_printk("debug_port: %u\n", debug_port);
+    dbgp_printk("n_ports:    %u\n", n_ports);
+    ehci_dbgp_status(dbgp, "");
+
+    for ( i =3D 1; i <=3D n_ports; i++ )
+    {
+        portsc =3D readl(&dbgp->ehci_regs->port_status[i-1]);
+        dbgp_printk("portstatus%d: %08x\n", i, portsc);
+    }
+
+    if ( port_map_tried && (new_debug_port !=3D debug_port) )
+    {
+        if ( --playtimes )
+        {
+            set_debug_port(dbgp, new_debug_port);
+            goto try_next_time;
+        }
+        return -1;
+    }
+
+    /* Only reset the controller if it is not already in the
+     * configured state */
+    if ( readl(&dbgp->ehci_regs->configured_flag) & FLAG_CF )
+        ehci_dbgp_status(dbgp, "ehci skip - already configured");
+    else if ( ehci_dbgp_controller_reset(dbgp) !=3D 0 )
+        return -1;
+
+    ret =3D ehci_dbgp_external_startup(dbgp);
+    if (ret =3D=3D -EIO)
+        goto next_debug_port;
+
+    if ( ret < 0 )
+    {
+        /* Things didn't work so remove my claim */
+        ctrl =3D readl(&dbgp->ehci_debug->control);
+        ctrl &=3D ~(DBGP_CLAIM | DBGP_OUT);
+        writel(ctrl, &dbgp->ehci_debug->control);
+        return -1;
+    }
+
+    return 0;
+
+next_debug_port:
+    port_map_tried |=3D 1 << (debug_port - 1);
+    new_debug_port =3D (debug_port % n_ports) + 1;
+    if ( port_map_tried !=3D ((1 << n_ports) - 1) )
+    {
+        set_debug_port(dbgp, new_debug_port);
+        goto try_next_port;
+    }
+    if ( --playtimes )
+    {
+        set_debug_port(dbgp, new_debug_port);
+        goto try_next_time;
+    }
+
+    return -1;
+}
+
+static inline void _ehci_dbgp_flush(struct ehci_dbgp *dbgp)
+{
+    if ( dbgp_bulk_write(dbgp, USB_DEBUG_DEVNUM, dbgp->out.endpoint,
+                         dbgp->out.buf, dbgp->out.chunk, NULL) )
+        BUG();
+    dbgp->out.chunk =3D 0;
+}
+
+static void ehci_dbgp_flush(struct serial_port *port)
+{
+    struct ehci_dbgp *dbgp =3D port->uart;
+    s_time_t goal;
+
+    if ( !dbgp->out.chunk || !dbgp->ehci_debug || dbgp->state =3D=3D =
dbgp_unsafe )
+        return;
+
+    if ( dbgp->state =3D=3D dbgp_idle || !port->sync )
+        dbgp_check_for_completion(dbgp, 1, NULL);
+    else
+        dbgp_wait_until_complete(dbgp, NULL);
+
+    if ( dbgp->state =3D=3D dbgp_idle )
+    {
+        _ehci_dbgp_flush(dbgp);
+
+        if ( port->sync )
+        {
+            dbgp_wait_until_complete(dbgp, NULL);
+            return;
+        }
+    }
+
+    goal =3D NOW() + MICROSECS(DBGP_CHECK_INTERVAL);
+    if ( dbgp->timer.expires > goal )
+       set_timer(&dbgp->timer, goal);
+}
+
+static void ehci_dbgp_putc(struct serial_port *port, char c)
+{
+    struct ehci_dbgp *dbgp =3D port->uart;
+
+    if ( unlikely(dbgp->out.chunk >=3D DBGP_MAX_PACKET) )
+        return;
+
+    dbgp->out.buf[dbgp->out.chunk++] =3D c;
+
+    if ( dbgp->out.chunk =3D=3D DBGP_MAX_PACKET )
+        ehci_dbgp_flush(port);
+}
+
+static int ehci_dbgp_tx_empty(struct serial_port *port)
+{
+    struct ehci_dbgp *dbgp =3D port->uart;
+
+    if ( unlikely(!dbgp->ehci_debug) || unlikely(dbgp->state =3D=3D =
dbgp_unsafe) )
+        return port->sync || port->tx_log_everything || !port->txbuf;
+
+    if ( dbgp->out.chunk =3D=3D DBGP_MAX_PACKET )
+        ehci_dbgp_flush(port);
+    else
+        dbgp_check_for_completion(dbgp, 1, NULL);
+
+    if ( dbgp->state !=3D dbgp_idle && dbgp->out.chunk >=3D DBGP_MAX_PACKE=
T )
+        return 0;
+
+    port->tx_fifo_size =3D DBGP_MAX_PACKET - dbgp->out.chunk;
+    if ( dbgp->state =3D=3D dbgp_idle )
+        port->tx_fifo_size +=3D DBGP_MAX_PACKET;
+
+    return 1;
+}
+
+static int ehci_dbgp_getc(struct serial_port *port, char *pc)
+{
+    struct ehci_dbgp *dbgp =3D port->uart;
+
+    if ( !dbgp->in.chunk )
+        return 0;
+
+    *pc =3D *dbgp->in.buf;
+    if ( --dbgp->in.chunk )
+        memmove(dbgp->in.buf, dbgp->in.buf + 1, dbgp->in.chunk);
+
+    return 1;
+}
+
+/* Safe: ehci_dbgp_poll() runs as timer handler, so not reentrant. */
+static struct serial_port *poll_port;
+
+static void _ehci_dbgp_poll(struct cpu_user_regs *regs)
+{
+    struct serial_port *port =3D poll_port;
+    struct ehci_dbgp *dbgp =3D port->uart;
+    unsigned long flags;
+    unsigned int timeout =3D MICROSECS(DBGP_CHECK_INTERVAL);
+    bool_t empty =3D 0;
+
+    if ( !dbgp->ehci_debug )
+        return;
+
+    if ( spin_trylock_irqsave(&port->tx_lock, flags) )
+    {
+        if ( dbgp->state !=3D dbgp_unsafe )
+            dbgp_check_for_completion(dbgp, DBGP_CHECK_INTERVAL, NULL);
+        if ( dbgp->state =3D=3D dbgp_idle && dbgp->out.chunk )
+            _ehci_dbgp_flush(dbgp);
+        if ( dbgp->state =3D=3D dbgp_idle || dbgp->out.chunk < DBGP_MAX_PA=
CKET )
+            empty =3D 1;
+        spin_unlock_irqrestore(&port->tx_lock, flags);
+    }
+
+    if ( dbgp->in.chunk )
+        serial_rx_interrupt(port, regs);
+
+    if ( empty )
+        serial_tx_interrupt(port, regs);
+
+    if ( spin_trylock_irqsave(&port->tx_lock, flags) )
+    {
+        if ( dbgp->state =3D=3D dbgp_idle && !dbgp->in.chunk &&
+             !dbgp->out.chunk && port->txbufp =3D=3D port->txbufc )
+        {
+            if ( dbgp_bulk_read(dbgp, USB_DEBUG_DEVNUM, dbgp->in.endpoint,=

+                                DBGP_MAX_PACKET, NULL) )
+                BUG();
+            timeout =3D MILLISECS(DBGP_IDLE_INTERVAL);
+        }
+        spin_unlock_irqrestore(&port->tx_lock, flags);
+    }
+
+    set_timer(&dbgp->timer, NOW() + timeout);
+}
+
+static void ehci_dbgp_poll(void *data)
+{
+    poll_port =3D data;
+#ifdef run_in_exception_handler
+    run_in_exception_handler(_ehci_dbgp_poll);
+#else
+    _ehci_dbgp_poll(guest_cpu_user_regs());
+#endif
+}
+
+static bool_t ehci_dbgp_setup_preirq(struct ehci_dbgp *dbgp)
+{
+    if ( !ehci_dbgp_setup(dbgp) )
+        return 1;
+
+    dbgp_printk("ehci_dbgp_setup failed\n");
+    dbgp->ehci_debug =3D NULL;
+    return 0;
+}
+
+static void __init ehci_dbgp_init_preirq(struct serial_port *port)
+{
+    struct ehci_dbgp *dbgp =3D port->uart;
+    u32 debug_port, offset;
+    void __iomem *ehci_bar;
+
+    debug_port =3D pci_conf_read32(0, dbgp->bus, dbgp->slot, dbgp->func,
+                                 dbgp->cap);
+    offset =3D (debug_port >> 16) & 0xfff;
+
+    /* double check if the mem space is enabled */
+    dbgp->pci_cr =3D pci_conf_read8(0, dbgp->bus, dbgp->slot, dbgp->func,
+                                  PCI_COMMAND);
+    if ( !(dbgp->pci_cr & PCI_COMMAND_MEMORY) )
+    {
+        dbgp->pci_cr |=3D PCI_COMMAND_MEMORY;
+        pci_conf_write16(0, dbgp->bus, dbgp->slot, dbgp->func, PCI_COMMAND=
,
+                         dbgp->pci_cr);
+        dbgp_printk("MMIO for EHCI enabled\n");
+    }
+
+    /*
+     * FIXME I don't have the bar size so just guess PAGE_SIZE is more
+     * than enough.  1k is the biggest that was seen.
+     */
+    set_fixmap_nocache(FIX_EHCI_DBGP, dbgp->bar_val);
+    ehci_bar =3D (void __iomem *)fix_to_virt(FIX_EHCI_DBGP);
+    ehci_bar +=3D dbgp->bar_val & ~PAGE_MASK;
+    dbgp_printk("ehci_bar: %p\n", ehci_bar);
+
+    dbgp->ehci_caps =3D ehci_bar;
+    dbgp->ehci_regs =3D ehci_bar +
+                      HC_LENGTH(readl(&dbgp->ehci_caps->hc_capbase));
+    dbgp->ehci_debug =3D ehci_bar + offset;
+
+    detect_set_debug_port(dbgp);
+
+    if ( ehci_dbgp_setup_preirq(dbgp) )
+        ehci_dbgp_status(dbgp, "ehci_dbgp_init_preirq complete");
+
+    port->tx_fifo_size =3D DBGP_MAX_PACKET;
+    dbgp->lock =3D &port->tx_lock;
+}
+
+static void ehci_dbgp_setup_postirq(struct ehci_dbgp *dbgp)
+{
+    set_timer(&dbgp->timer, NOW() + MILLISECS(1));
+}
+
+static void __init ehci_dbgp_init_postirq(struct serial_port *port)
+{
+    struct ehci_dbgp *dbgp =3D port->uart;
+
+    if ( !dbgp->ehci_debug )
+        return;
+
+    serial_async_transmit(port);
+
+    init_timer(&dbgp->timer, ehci_dbgp_poll, port, 0);
+
+    ehci_dbgp_setup_postirq(dbgp);
+}
+
+static int ehci_dbgp_check_release(struct ehci_dbgp *dbgp)
+{
+    struct ehci_dbg_port __iomem *ehci_debug =3D dbgp->ehci_debug;
+    u32 ctrl;
+    unsigned int i;
+
+    if ( !ehci_debug )
+        return 0;
+
+    for ( i =3D 0; i < DBGP_MAX_PACKET; ++i )
+        if ( dbgp->out.buf[i] )
+            return 1;
+
+    /*
+     * This means the console is not initialized, or should get shutdown
+     * so as to allow for reuse of the USB device, which means it is time
+     * to shutdown the USB debug port.
+     */
+    printk(XENLOG_INFO "Releasing EHCI debug port at %02x:%02x.%u\n",
+           dbgp->bus, dbgp->slot, dbgp->func);
+
+    kill_timer(&dbgp->timer);
+    dbgp->ehci_debug =3D NULL;
+
+    ctrl =3D readl(&ehci_debug->control);
+    if ( ctrl & DBGP_ENABLED )
+    {
+        ctrl &=3D ~DBGP_CLAIM;
+        writel(ctrl, &ehci_debug->control);
+    }
+
+    return 0;
+}
+
+static void __init ehci_dbgp_endboot(struct serial_port *port)
+{
+    ehci_dbgp_check_release(port->uart);
+}
+
+static void ehci_dbgp_suspend(struct serial_port *port)
+{
+    struct ehci_dbgp *dbgp =3D port->uart;
+
+    if ( !dbgp->ehci_debug )
+        return;
+
+    stop_timer(&dbgp->timer);
+    dbgp->timer.expires =3D 0;
+
+    dbgp->pci_cr =3D pci_conf_read16(0, dbgp->bus, dbgp->slot, dbgp->func,=

+                                   PCI_COMMAND);
+
+    dbgp->state =3D dbgp_unsafe;
+}
+
+static void ehci_dbgp_resume(struct serial_port *port)
+{
+    struct ehci_dbgp *dbgp =3D port->uart;
+
+    if ( !dbgp->ehci_debug )
+        return;
+
+    pci_conf_write32(0, dbgp->bus, dbgp->slot, dbgp->func, dbgp->bar,
+                     dbgp->bar_val);
+    pci_conf_write16(0, dbgp->bus, dbgp->slot, dbgp->func,
+                     PCI_COMMAND, dbgp->pci_cr);
+
+    ehci_dbgp_setup_preirq(dbgp);
+    ehci_dbgp_setup_postirq(dbgp);
+}
+
+static struct uart_driver __read_mostly ehci_dbgp_driver =3D {
+    .init_preirq  =3D ehci_dbgp_init_preirq,
+    .init_postirq =3D ehci_dbgp_init_postirq,
+    .endboot      =3D ehci_dbgp_endboot,
+    .suspend      =3D ehci_dbgp_suspend,
+    .resume       =3D ehci_dbgp_resume,
+    .tx_empty     =3D ehci_dbgp_tx_empty,
+    .putc         =3D ehci_dbgp_putc,
+    .flush        =3D ehci_dbgp_flush,
+    .getc         =3D ehci_dbgp_getc
+};
+
+static struct ehci_dbgp ehci_dbgp =3D { .state =3D dbgp_unsafe, .phys_port=
 =3D 1 };
+
+static char __initdata opt_dbgp[30];
+string_param("dbgp", opt_dbgp);
+
+void __init ehci_dbgp_init(void)
+{
+    struct ehci_dbgp *dbgp =3D &ehci_dbgp;
+    u32 debug_port, offset, bar_val;
+    const char *e;
+
+    if ( strncmp(opt_dbgp, "ehci", 4) )
+        return;
+
+    if ( isdigit(opt_dbgp[4]) || !opt_dbgp[4] )
+    {
+        unsigned int num =3D 0;
+
+        if ( opt_dbgp[4] )
+            simple_strtoul(opt_dbgp + 4, &e, 10);
+
+        dbgp->cap =3D find_dbgp(dbgp, num);
+        if ( !dbgp->cap )
+            return;
+
+        dbgp_printk("Found EHCI debug port on %02x:%02x.%u\n",
+                    dbgp->bus, dbgp->slot, dbgp->func);
+    }
+    else if ( strncmp(opt_dbgp + 4, "@pci", 4) =3D=3D 0 )
+    {
+        unsigned long val =3D simple_strtoul(opt_dbgp + 8, &e, 16);
+
+        dbgp->bus =3D val;
+        if ( dbgp->bus !=3D val || *e !=3D ':' )
+            return;
+
+        val =3D simple_strtoul(e + 1, &e, 16);
+        if ( PCI_SLOT(PCI_DEVFN(val, 0)) !=3D val || *e !=3D '.' )
+            return;
+        dbgp->slot =3D val;
+
+        val =3D simple_strtoul(e + 1, &e, 16);
+        if ( PCI_FUNC(PCI_DEVFN(0, val)) !=3D val || *e )
+            return;
+        dbgp->func =3D val;
+
+        if ( !pci_device_detect(0, dbgp->bus, dbgp->slot, dbgp->func) )
+            return;
+
+        dbgp->cap =3D __find_dbgp(dbgp->bus, dbgp->slot, dbgp->func);
+        if ( !dbgp->cap )
+            return;
+
+        dbgp_printk("Using EHCI debug port on %02x:%02x.%u\n",
+                    dbgp->bus, dbgp->slot, dbgp->func);
+    }
+    else
+        return;
+
+    debug_port =3D pci_conf_read32(0, dbgp->bus, dbgp->slot, dbgp->func,
+                                 dbgp->cap);
+    dbgp->bar =3D (debug_port >> 29) & 0x7;
+    dbgp->bar =3D ((dbgp->bar - 1) * 4) + PCI_BASE_ADDRESS_0;
+    offset =3D (debug_port >> 16) & 0xfff;
+    dbgp_printk("bar: %02x offset: %03x\n", dbgp->bar, offset);
+    if ( dbgp->bar < PCI_BASE_ADDRESS_0 || dbgp->bar > PCI_BASE_ADDRESS_5 =
)
+    {
+        dbgp_printk("unsupported/invalid bar\n");
+        return;
+    }
+
+    dbgp->bar_val =3D bar_val =3D pci_conf_read32(0, dbgp->bus, dbgp->slot=
,
+                                              dbgp->func, dbgp->bar);
+    dbgp_printk("bar_val: %08x\n", bar_val);
+    if ( bar_val & ~PCI_BASE_ADDRESS_MEM_MASK )
+    {
+        dbgp_printk("only simple 32-bit MMIO BARs supported\n");
+        return;
+    }
+    bar_val &=3D PCI_BASE_ADDRESS_MEM_MASK;
+    if ( !bar_val || !(bar_val + (bar_val & -bar_val)) )
+    {
+        dbgp_printk("firmware initialization of MMIO BAR required\n");
+        return;
+    }
+
+    serial_register_uart(SERHND_DBGP, &ehci_dbgp_driver, dbgp);
+}
+
+int dbgp_op(const struct physdev_dbgp_op *op)
+{
+    if ( !ehci_dbgp.ehci_debug )
+        return 0;
+
+    switch ( op->bus )
+    {
+    case PHYSDEVOP_DBGP_BUS_UNKNOWN:
+        break;
+    case PHYSDEVOP_DBGP_BUS_PCI:
+        if ( op->u.pci.seg || ehci_dbgp.bus !=3D op->u.pci.bus ||
+            PCI_DEVFN(ehci_dbgp.slot, ehci_dbgp.func) !=3D op->u.pci.devfn=
 )
+    default:
+            return 0;
+        break;
+    }
+
+    switch ( op->op )
+    {
+    case PHYSDEVOP_DBGP_RESET_PREPARE:
+        spin_lock_irq(ehci_dbgp.lock);
+        ehci_dbgp.state =3D dbgp_unsafe;
+        dbgp_wait_until_complete(&ehci_dbgp, NULL);
+        spin_unlock_irq(ehci_dbgp.lock);
+
+        return ehci_dbgp_check_release(&ehci_dbgp);
+
+    case PHYSDEVOP_DBGP_RESET_DONE:
+        return ehci_dbgp_external_startup(&ehci_dbgp) ?: 1;
+    }
+
+    return -ENOSYS;
+}
--- a/xen/drivers/char/serial.c
+++ b/xen/drivers/char/serial.c
@@ -265,6 +265,14 @@ int __init serial_parse_handle(char *con
 {
     int handle;
=20
+    if ( !strncmp(conf, "dbgp", 4) && (!conf[4] || conf[4] =3D=3D ',') )
+    {
+        if ( !com[SERHND_DBGP].driver )
+            goto fail;
+
+        return SERHND_DBGP | SERHND_COOKED;
+    }
+
     if ( strncmp(conf, "com", 3) )
         goto fail;
=20
--- a/xen/include/asm-x86/fixmap.h
+++ b/xen/include/asm-x86/fixmap.h
@@ -36,7 +36,15 @@
  * from the end of virtual memory backwards.
  */
 enum fixed_addresses {
-    FIX_RESERVED, /* Index 0 is reserved since fix_to_virt(0) > FIXADDR_TO=
P. */
+    /* Index 0 is reserved since fix_to_virt(0) =3D=3D FIXADDR_TOP. */
+    FIX_RESERVED,
+    /*
+     * Indexes using the page tables set up before entering __start_xen()
+     * must be among the first (L1_PAGETABLE_ENTRIES - 1) entries.
+     * These are generally those needed by the various console drivers.
+     */
+    FIX_EHCI_DBGP,
+    /* Everything else should go further down. */
 #ifdef __i386__
     FIX_PAE_HIGHMEM_0,
     FIX_PAE_HIGHMEM_END =3D FIX_PAE_HIGHMEM_0 + NR_CPUS-1,
--- a/xen/include/public/physdev.h
+++ b/xen/include/public/physdev.h
@@ -312,6 +312,24 @@ struct physdev_pci_device {
 typedef struct physdev_pci_device physdev_pci_device_t;
 DEFINE_XEN_GUEST_HANDLE(physdev_pci_device_t);
=20
+#define PHYSDEVOP_DBGP_RESET_PREPARE    1
+#define PHYSDEVOP_DBGP_RESET_DONE       2
+
+#define PHYSDEVOP_DBGP_BUS_UNKNOWN      0
+#define PHYSDEVOP_DBGP_BUS_PCI          1
+
+#define PHYSDEVOP_dbgp_op               29
+struct physdev_dbgp_op {
+    /* IN */
+    uint8_t op;
+    uint8_t bus;
+    union {
+        struct physdev_pci_device pci;
+    } u;
+};
+typedef struct physdev_dbgp_op physdev_dbgp_op_t;
+DEFINE_XEN_GUEST_HANDLE(physdev_dbgp_op_t);
+
 /*
  * Notify that some PIRQ-bound event channels have been unmasked.
  * ** This command is obsolete since interface version 0x00030202 and is =
**
--- a/xen/include/xen/serial.h
+++ b/xen/include/xen/serial.h
@@ -69,9 +69,10 @@ struct uart_driver {
 };
=20
 /* 'Serial handles' are composed from the following fields. */
-#define SERHND_IDX      (3<<0) /* COM1 or COM2?                           =
*/
+#define SERHND_IDX      (3<<0) /* COM1, COM2, or DBGP?                    =
*/
 # define SERHND_COM1    (0<<0)
 # define SERHND_COM2    (1<<0)
+# define SERHND_DBGP    (2<<0)
 #define SERHND_HI       (1<<2) /* Mux/demux each transferred char by MSB. =
*/
 #define SERHND_LO       (1<<3) /* Ditto, except that the MSB is cleared.  =
*/
 #define SERHND_COOKED   (1<<4) /* Newline/carriage-return translation?    =
*/
@@ -142,9 +143,13 @@ struct ns16550_defaults {
     unsigned long io_base; /* default io_base address */
 };
 void ns16550_init(int index, struct ns16550_defaults *defaults);
+void ehci_dbgp_init(void);
=20
 void pl011_init(int index, unsigned long register_base_address);
=20
+struct physdev_dbgp_op;
+int dbgp_op(const struct physdev_dbgp_op *);
+
 /* Baud rate was pre-configured before invoking the UART driver. */
 #define BAUD_AUTO (-1)
=20



--=__Part0736157F.0__=
Content-Type: text/plain; name="sercon-ehci-dbgp.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="sercon-ehci-dbgp.patch"

console: add EHCI debug port based serial console=0A=0ALow level hardware =
interface pieces adapted from Linux.=0A=0AFor setup information, see =
Linux'es Documentation/x86/earlyprintk.txt=0Aand/or http://www.coreboot.org=
/EHCI_Debug_Port.=0A=0ASigned-off-by: Jan Beulich <jbeulich@suse.com>=0ARev=
iewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>=0A=0A--- =
a/docs/misc/xen-command-line.markdown=0A+++ b/docs/misc/xen-command-line.ma=
rkdown=0A@@ -244,7 +244,7 @@ A typical setup for most situations migh=0A =
Specify the size of the console ring buffer.=0A =0A ### console=0A-> `=3D =
List of [ vga | com1[H,L] | com2[H,L] | none ]`=0A+> `=3D List of [ vga | =
com1[H,L] | com2[H,L] | dbgp | none ]`=0A =0A > Default: `console=3Dcom1,vg=
a`=0A =0A@@ -260,6 +260,8 @@ the converse; transmitted and received c=0A =
cleared.  This allows a single port to be shared by two subsystems=0A =
(e.g. console and debugger).=0A =0A+`dbgp` indicates that Xen should use a =
USB debug port.=0A+=0A `none` indicates that Xen should not use a console. =
 This option only=0A makes sense on its own.=0A =0A@@ -352,6 +354,12 @@ =
combination with the `low_crashinfo` com=0A ### credit2\_load\_window\_shif=
t=0A > `=3D <integer>`=0A =0A+### dbgp=0A+> `=3D ehci[ <integer> | =
@pci<bus>:<slot>.<func> ]`=0A+=0A+Specify the USB controller to use, =
either by instance number (when going=0A+over the PCI busses sequentially) =
or by PCI device (must be on segment 0).=0A+=0A ### debug\_stack\_lines=0A =
> `=3D <integer>`=0A =0A--- a/xen/arch/x86/Rules.mk=0A+++ b/xen/arch/x86/Ru=
les.mk=0A@@ -7,6 +7,7 @@ HAS_CPUFREQ :=3D y=0A HAS_PCI :=3D y=0A HAS_PASSTH=
ROUGH :=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--- a/xen/arch/x86/physdev.c=0A+=
++ b/xen/arch/x86/physdev.c=0A@@ -8,6 +8,7 @@=0A #include <xen/event.h>=0A =
#include <xen/guest_access.h>=0A #include <xen/iocap.h>=0A+#include =
<xen/serial.h>=0A #include <asm/current.h>=0A #include <asm/io_apic.h>=0A =
#include <asm/msi.h>=0A@@ -722,6 +723,19 @@ ret_t do_physdev_op(int cmd, =
XEN_GUEST_H=0A =0A         break;=0A     }=0A+=0A+    case PHYSDEVOP_dbgp_o=
p: {=0A+        struct physdev_dbgp_op op;=0A+=0A+        if ( !IS_PRIV(v->=
domain) )=0A+            ret =3D -EPERM;=0A+        else if ( copy_from_gue=
st(&op, arg, 1) )=0A+            ret =3D -EFAULT;=0A+        else=0A+      =
      ret =3D dbgp_op(&op);=0A+        break;=0A+    }=0A+=0A     =
default:=0A         ret =3D -ENOSYS;=0A         break;=0A--- a/xen/arch/x86=
/setup.c=0A+++ b/xen/arch/x86/setup.c=0A@@ -606,6 +606,7 @@ void __init =
__start_xen(unsigned long mb=0A     ns16550.io_base =3D 0x2f8;=0A     =
ns16550.irq     =3D 3;=0A     ns16550_init(1, &ns16550);=0A+    ehci_dbgp_i=
nit();=0A     console_init_preirq();=0A =0A     printk("Bootloader: %s\n", =
loader);=0A--- a/xen/drivers/char/Makefile=0A+++ b/xen/drivers/char/Makefil=
e=0A@@ -1,4 +1,5 @@=0A obj-y +=3D console.o=0A obj-$(HAS_NS16550) +=3D =
ns16550.o=0A obj-$(HAS_PL011) +=3D pl011.o=0A+obj-$(HAS_EHCI) +=3D =
ehci-dbgp.o=0A obj-y +=3D serial.o=0A--- /dev/null=0A+++ b/xen/drivers/char=
/ehci-dbgp.c=0A@@ -0,0 +1,1577 @@=0A+/*=0A+ * Standalone EHCI USB debug =
driver=0A+ *=0A+ * Hardware interface code based on the respective early =
console driver in=0A+ * Linux; see the Linux source for authorship and =
copyrights.=0A+ */=0A+=0A+#include <xen/config.h>=0A+#include <xen/console.=
h>=0A+#include <xen/delay.h>=0A+#include <xen/errno.h>=0A+#include =
<xen/pci.h>=0A+#include <xen/serial.h>=0A+#include <asm/byteorder.h>=0A+#in=
clude <asm/io.h>=0A+#include <asm/fixmap.h>=0A+#include <public/physdev.h>=
=0A+=0A+/* #define DBGP_DEBUG */=0A+=0A+/* EHCI register interface, =
corresponds to EHCI Revision 0.95 specification */=0A+=0A+/* Section 2.2 =
Host Controller Capability Registers */=0A+struct ehci_caps {=0A+    =
/*=0A+     * These fields are specified as 8 and 16 bit registers,=0A+     =
* but some hosts can't perform 8 or 16 bit PCI accesses.=0A+     * some =
hosts treat caplength and hciversion as parts of a 32-bit=0A+     * =
register, others treat them as two separate registers, this=0A+     * =
affects the memory map for big endian controllers.=0A+     */=0A+    u32 =
hc_capbase;=0A+#define HC_LENGTH(p)      (0x00ff & (p)) /* bits 7:0 / =
offset 0x00 */=0A+#define HC_VERSION(p)     (0xffff & ((p) >> 16)) /* bits =
31:16 / offset 0x02 */=0A+=0A+    u32 hcs_params;       /* HCSPARAMS - =
offset 0x04 */=0A+#define HCS_DEBUG_PORT(p) (((p) >> 20) & 0xf) /* bits =
23:20, debug port? */=0A+#define HCS_INDICATOR(p)  ((p) & (1 << 16))   /* =
true: has port indicators */=0A+#define HCS_N_CC(p)       (((p) >> 12) & =
0xf) /* bits 15:12, #companion HCs */=0A+#define HCS_N_PCC(p)      (((p) =
>> 8) & 0xf)  /* bits 11:8, ports per CC */=0A+#define HCS_PORTROUTED(p) =
((p) & (1 << 7))    /* true: port routing */=0A+#define HCS_PPC(p)        =
((p) & (1 << 4))    /* true: port power control */=0A+#define HCS_N_PORTS(p=
)    (((p) >> 0) & 0xf)  /* bits 3:0, ports on HC */=0A+=0A+    u32 =
hcc_params;       /* HCCPARAMS - offset 0x08 */=0A+/* EHCI 1.1 addendum =
*/=0A+#define HCC_32FRAME_PERIODIC_LIST(p) ((p) & (1 << 19))=0A+#define =
HCC_PER_PORT_CHANGE_EVENT(p) ((p) & (1 << 18))=0A+#define HCC_LPM(p)       =
 ((p) & (1 << 17))=0A+#define HCC_HW_PREFETCH(p) ((p) & (1 << 16))=0A+#defi=
ne HCC_EXT_CAPS(p)   (((p) >> 8) & 0xff) /* for pci extended caps =
*/=0A+#define HCC_ISOC_CACHE(p) ((p) & (1 << 7))    /* true: can cache =
isoc frame */=0A+#define HCC_ISOC_THRES(p) (((p) >> 4) & 0x7)  /* bits =
6:4, uframes cached */=0A+#define HCC_CANPARK(p)    ((p) & (1 << 2))    /* =
true: can park on async qh */=0A+#define HCC_PGM_FRAMELISTLEN(p) ((p) & (1 =
<< 1)) /* true: periodic_size changes */=0A+#define HCC_64BIT_ADDR(p) ((p) =
& 1)           /* true: can use 64-bit addr */=0A+=0A+    u8  portroute[8];=
     /* nibbles for routing - offset 0x0C */=0A+};=0A+=0A+/* Section 2.3 =
Host Controller Operational Registers */=0A+struct ehci_regs {=0A+    /* =
USBCMD: offset 0x00 */=0A+    u32 command;=0A+=0A+/* EHCI 1.1 addendum =
*/=0A+#define CMD_HIRD        (0xf << 24) /* host initiated resume =
duration */=0A+#define CMD_PPCEE       (1 << 15)   /* per port change =
event enable */=0A+#define CMD_FSP         (1 << 14)   /* fully synchronize=
d prefetch */=0A+#define CMD_ASPE        (1 << 13)   /* async schedule =
prefetch enable */=0A+#define CMD_PSPE        (1 << 12)   /* periodic =
schedule prefetch enable */=0A+/* 23:16 is r/w intr rate, in microframes; =
default "8" =3D=3D 1/msec */=0A+#define CMD_PARK        (1 << 11)   /* =
enable "park" on async qh */=0A+#define CMD_PARK_CNT(c) (((c) >> 8) & 3) =
/* how many transfers to park for */=0A+#define CMD_LRESET      (1 << 7)   =
 /* partial reset (no ports, etc) */=0A+#define CMD_IAAD        (1 << 6)   =
 /* "doorbell" interrupt async advance */=0A+#define CMD_ASE         (1 << =
5)    /* async schedule enable */=0A+#define CMD_PSE         (1 << 4)    =
/* periodic schedule enable */=0A+/* 3:2 is periodic frame list size =
*/=0A+#define CMD_RESET       (1 << 1)    /* reset HC not bus */=0A+#define=
 CMD_RUN         (1 << 0)    /* start/stop HC */=0A+=0A+    /* USBSTS: =
offset 0x04 */=0A+    u32 status;=0A+#define STS_PPCE_MASK   (0xff << 16) =
/* Per-Port change event 1-16 */=0A+#define STS_ASS         (1 << 15)   /* =
Async Schedule Status */=0A+#define STS_PSS         (1 << 14)   /* =
Periodic Schedule Status */=0A+#define STS_RECL        (1 << 13)   /* =
Reclamation */=0A+#define STS_HALT        (1 << 12)   /* Not running (any =
reason) */=0A+/* some bits reserved */=0A+    /* these STS_* flags are =
also intr_enable bits (USBINTR) */=0A+#define STS_IAA         (1 << 5)    =
/* Interrupted on async advance */=0A+#define STS_FATAL       (1 << 4)    =
/* such as some PCI access errors */=0A+#define STS_FLR         (1 << 3)   =
 /* frame list rolled over */=0A+#define STS_PCD         (1 << 2)    /* =
port change detect */=0A+#define STS_ERR         (1 << 1)    /* "error" =
completion (overflow, ...) */=0A+#define STS_INT         (1 << 0)    /* =
"normal" completion (short, ...) */=0A+=0A+    /* USBINTR: offset 0x08 =
*/=0A+    u32 intr_enable;=0A+=0A+    /* FRINDEX: offset 0x0C */=0A+    =
u32 frame_index;    /* current microframe number */=0A+    /* CTRLDSSEGMENT=
: offset 0x10 */=0A+    u32 segment;    /* address bits 63:32 if needed =
*/=0A+    /* PERIODICLISTBASE: offset 0x14 */=0A+    u32 frame_list;    /* =
points to periodic list */=0A+    /* ASYNCLISTADDR: offset 0x18 */=0A+    =
u32 async_next;    /* address of next async queue head */=0A+=0A+    u32 =
reserved[9];=0A+=0A+    /* CONFIGFLAG: offset 0x40 */=0A+    u32 configured=
_flag;=0A+#define FLAG_CF         (1 << 0)    /* true: we'll support "high =
speed" */=0A+=0A+    /* PORTSC: offset 0x44 */=0A+    u32 port_status[0];  =
  /* up to N_PORTS */=0A+/* EHCI 1.1 addendum */=0A+#define PORTSC_SUSPEND_=
STS_ACK   0=0A+#define PORTSC_SUSPEND_STS_NYET  1=0A+#define PORTSC_SUSPEND=
_STS_STALL 2=0A+#define PORTSC_SUSPEND_STS_ERR   3=0A+=0A+#define =
PORT_DEV_ADDR   (0x7f << 25) /* device address */=0A+#define PORT_SSTS     =
  (0x3 << 23)  /* suspend status */=0A+/* 31:23 reserved */=0A+#define =
PORT_WKOC_E     (1 << 22)    /* wake on overcurrent (enable) */=0A+#define =
PORT_WKDISC_E   (1 << 21)    /* wake on disconnect (enable) */=0A+#define =
PORT_WKCONN_E   (1 << 20)    /* wake on connect (enable) */=0A+/* 19:16 =
for port testing */=0A+#define PORT_TEST(x)    (((x) & 0xf) << 16) /* Port =
Test Control */=0A+#define PORT_TEST_PKT   PORT_TEST(0x4) /* Port Test =
Control - packet test */=0A+#define PORT_TEST_FORCE PORT_TEST(0x5) /* Port =
Test Control - force enable */=0A+#define PORT_LED_OFF    (0 << 14)=0A+#def=
ine PORT_LED_AMBER  (1 << 14)=0A+#define PORT_LED_GREEN  (2 << 14)=0A+#defi=
ne PORT_LED_MASK   (3 << 14)=0A+#define PORT_OWNER      (1 << 13)    /* =
true: companion hc owns this port */=0A+#define PORT_POWER      (1 << 12)  =
  /* true: has power (see PPC) */=0A+#define PORT_USB11(x)   (((x) & (3 << =
10)) =3D=3D (1 << 10)) /* USB 1.1 device */=0A+/* 11:10 for detecting =
lowspeed devices (reset vs release ownership) */=0A+/* 9 reserved =
*/=0A+#define PORT_LPM        (1 << 9)     /* LPM transaction */=0A+#define=
 PORT_RESET      (1 << 8)     /* reset port */=0A+#define PORT_SUSPEND    =
(1 << 7)     /* suspend port */=0A+#define PORT_RESUME     (1 << 6)     /* =
resume it */=0A+#define PORT_OCC        (1 << 5)     /* over current =
change */=0A+#define PORT_OC         (1 << 4)     /* over current active =
*/=0A+#define PORT_PEC        (1 << 3)     /* port enable change */=0A+#def=
ine PORT_PE         (1 << 2)     /* port enable */=0A+#define PORT_CSC     =
   (1 << 1)     /* connect status change */=0A+#define PORT_CONNECT    (1 =
<< 0)     /* device connected */=0A+#define PORT_RWC_BITS   (PORT_CSC | =
PORT_PEC | PORT_OCC)=0A+};=0A+=0A+/*=0A+ * Appendix C, Debug port ... =
intended for use with special "debug devices"=0A+ * that can help if =
there's no serial console.  (nonstandard enumeration.)=0A+ */=0A+struct =
ehci_dbg_port {=0A+    u32 control;=0A+#define DBGP_OWNER      (1 << =
30)=0A+#define DBGP_ENABLED    (1 << 28)=0A+#define DBGP_DONE       (1 << =
16)=0A+#define DBGP_INUSE      (1 << 10)=0A+#define DBGP_ERRCODE(x) (((x) =
>> 7) & 0x07)=0A+# define DBGP_ERR_BAD    1=0A+# define DBGP_ERR_SIGNAL =
2=0A+#define DBGP_ERROR      (1 << 6)=0A+#define DBGP_GO         (1 << =
5)=0A+#define DBGP_OUT        (1 << 4)=0A+#define DBGP_LEN        (0xf << =
0)=0A+#define DBGP_CLAIM      (DBGP_OWNER | DBGP_ENABLED | DBGP_INUSE)=0A+ =
   u32 pids;=0A+#define DBGP_PID_GET(x)         (((x) >> 16) & 0xff)=0A+#de=
fine DBGP_PID_SET(data, tok) (((data) << 8) | (tok))=0A+    u32 data03;=0A+=
    u32 data47;=0A+    u32 address;=0A+#define DBGP_EPADDR(dev, ep) =
(((dev) << 8) | (ep))=0A+};=0A+=0A+/* CONTROL REQUEST SUPPORT */=0A+=0A+/*=
=0A+ * USB directions=0A+ *=0A+ * This bit flag is used in endpoint =
descriptors' bEndpointAddress field.=0A+ * It's also one of three fields =
in control requests bRequestType.=0A+ */=0A+#define USB_DIR_OUT 0          =
 /* to device */=0A+#define USB_DIR_IN  0x80        /* to host */=0A+=0A+/*=
=0A+ * USB types, the second of three bRequestType fields=0A+ */=0A+#define=
 USB_TYPE_MASK     (0x03 << 5)=0A+#define USB_TYPE_STANDARD (0x00 << =
5)=0A+#define USB_TYPE_CLASS    (0x01 << 5)=0A+#define USB_TYPE_VENDOR   =
(0x02 << 5)=0A+#define USB_TYPE_RESERVED (0x03 << 5)=0A+=0A+/*=0A+ * USB =
recipients, the third of three bRequestType fields=0A+ */=0A+#define =
USB_RECIP_MASK      0x1f=0A+#define USB_RECIP_DEVICE    0x00=0A+#define =
USB_RECIP_INTERFACE 0x01=0A+#define USB_RECIP_ENDPOINT  0x02=0A+#define =
USB_RECIP_OTHER     0x03=0A+/* From Wireless USB 1.0 */=0A+#define =
USB_RECIP_PORT      0x04=0A+#define USB_RECIP_RPIPE     0x05=0A+=0A+/*=0A+ =
* Standard requests, for the bRequest field of a SETUP packet.=0A+ *=0A+ * =
These are qualified by the bRequestType field, so that for example=0A+ * =
TYPE_CLASS or TYPE_VENDOR specific feature flags could be retrieved=0A+ * =
by a GET_STATUS request.=0A+ */=0A+#define USB_REQ_GET_STATUS        =
0x00=0A+#define USB_REQ_CLEAR_FEATURE     0x01=0A+#define USB_REQ_SET_FEATU=
RE       0x03=0A+#define USB_REQ_SET_ADDRESS       0x05=0A+#define =
USB_REQ_GET_DESCRIPTOR    0x06=0A+#define USB_REQ_SET_DESCRIPTOR    =
0x07=0A+#define USB_REQ_GET_CONFIGURATION 0x08=0A+#define USB_REQ_SET_CONFI=
GURATION 0x09=0A+#define USB_REQ_GET_INTERFACE     0x0A=0A+#define =
USB_REQ_SET_INTERFACE     0x0B=0A+#define USB_REQ_SYNCH_FRAME       =
0x0C=0A+=0A+#define USB_DEVICE_DEBUG_MODE        6    /* (special devices =
only) */=0A+=0A+/**=0A+ * struct usb_ctrlrequest - SETUP data for a USB =
device control request=0A+ * @bRequestType: matches the USB bmRequestType =
field=0A+ * @bRequest: matches the USB bRequest field=0A+ * @wValue: =
matches the USB wValue field (le16 byte order)=0A+ * @wIndex: matches the =
USB wIndex field (le16 byte order)=0A+ * @wLength: matches the USB wLength =
field (le16 byte order)=0A+ *=0A+ * This structure is used to send control =
requests to a USB device.  It matches=0A+ * the different fields of the =
USB 2.0 Spec section 9.3, table 9-2.  See the=0A+ * USB spec for a fuller =
description of the different fields, and what they are=0A+ * used for.=0A+ =
*=0A+ * Note that the driver for any interface can issue control =
requests.=0A+ * For most devices, interfaces don't coordinate with each =
other, so=0A+ * such requests may be made at any time.=0A+ */=0A+struct =
usb_ctrlrequest {=0A+    u8 bRequestType;=0A+    u8 bRequest;=0A+    =
__le16 wValue;=0A+    __le16 wIndex;=0A+    __le16 wLength;=0A+} __attribut=
e__ ((packed));=0A+=0A+/* USB_DT_DEBUG: for special highspeed devices, =
replacing serial console */=0A+=0A+#define USB_DT_DEBUG    0x0a=0A+=0A+stru=
ct usb_debug_descriptor {=0A+    u8 bLength;=0A+    u8 bDescriptorType;=0A+=
    /* bulk endpoints with 8 byte maxpacket */=0A+    u8 bDebugInEndpoint;=
=0A+    u8 bDebugOutEndpoint;=0A+} __attribute__((packed));=0A+=0A+#define =
USB_DEBUG_DEVNUM 127=0A+=0A+/*=0A+ * USB Packet IDs (PIDs)=0A+ */=0A+=0A+/*=
 token */=0A+#define USB_PID_OUT           0xe1=0A+#define USB_PID_IN      =
      0x69=0A+#define USB_PID_SOF           0xa5=0A+#define USB_PID_SETUP  =
       0x2d=0A+/* handshake */=0A+#define USB_PID_ACK           0xd2=0A+#de=
fine USB_PID_NAK           0x5a=0A+#define USB_PID_STALL         0x1e=0A+#d=
efine USB_PID_NYET          0x96=0A+/* data */=0A+#define USB_PID_DATA0    =
     0xc3=0A+#define USB_PID_DATA1         0x4b=0A+#define USB_PID_DATA2   =
      0x87=0A+#define USB_PID_MDATA         0x0f=0A+/* Special */=0A+#defin=
e USB_PID_PREAMBLE      0x3c=0A+#define USB_PID_ERR           0x3c=0A+#defi=
ne USB_PID_SPLIT         0x78=0A+#define USB_PID_PING          0xb4=0A+#def=
ine USB_PID_UNDEF_0       0xf0=0A+=0A+#define PCI_CLASS_SERIAL_USB_EHCI =
0x0c0320=0A+#define PCI_CAP_ID_EHCI_DEBUG     0x0a=0A+=0A+#define =
HUB_ROOT_RESET_TIME   50    /* times are in msec */=0A+#define HUB_SHORT_RE=
SET_TIME  10=0A+#define HUB_LONG_RESET_TIME   200=0A+#define HUB_RESET_TIME=
OUT     500=0A+=0A+#define DBGP_MAX_PACKET       8=0A+#define DBGP_LOOPS   =
         1000=0A+#define DBGP_TIMEOUT          (250 * 1000) /* us =
*/=0A+#define DBGP_CHECK_INTERVAL   100 /* us */=0A+/* This one can be set =
arbitrarily - only affects input responsiveness: */=0A+#define DBGP_IDLE_IN=
TERVAL    100 /* ms */=0A+=0A+struct ehci_dbgp {=0A+    struct ehci_dbg_por=
t __iomem *ehci_debug;=0A+    enum dbgp_state {=0A+        dbgp_idle,=0A+  =
      dbgp_out,=0A+        dbgp_in,=0A+        dbgp_ctrl,=0A+        =
dbgp_unsafe /* cannot use debug device during EHCI reset */=0A+    } =
state;=0A+    unsigned int phys_port;=0A+    struct {=0A+        unsigned =
int endpoint;=0A+        unsigned int chunk;=0A+        char buf[DBGP_MAX_P=
ACKET];=0A+    } out, in;=0A+    unsigned long timeout;=0A+    struct =
timer timer;=0A+    spinlock_t *lock;=0A+    bool_t reset_run;=0A+    u8 =
bus, slot, func, bar;=0A+    u16 pci_cr;=0A+    u32 bar_val;=0A+    =
unsigned int cap;=0A+    struct ehci_regs __iomem *ehci_regs;=0A+    =
struct ehci_caps __iomem *ehci_caps;=0A+};=0A+=0A+static int ehci_dbgp_exte=
rnal_startup(struct ehci_dbgp *);=0A+=0A+static void ehci_dbgp_status(struc=
t ehci_dbgp *dbgp, const char *str)=0A+{=0A+#ifdef DBGP_DEBUG=0A+#define =
dbgp_printk printk=0A+    if ( !dbgp->ehci_debug )=0A+        return;=0A+  =
  dbgp_printk("dbgp: %s\n", str);=0A+    dbgp_printk("  debug control: =
%08x\n", readl(&dbgp->ehci_debug->control));=0A+    dbgp_printk("  EHCI =
cmd     : %08x\n", readl(&dbgp->ehci_regs->command));=0A+    dbgp_printk(" =
 EHCI conf flg: %08x\n",=0A+                readl(&dbgp->ehci_regs->configu=
red_flag));=0A+    dbgp_printk("  EHCI status  : %08x\n", readl(&dbgp->ehci=
_regs->status));=0A+    dbgp_printk("  EHCI portsc  : %08x\n",=0A+         =
       readl(&dbgp->ehci_regs->port_status[dbgp->phys_port - 1]));=0A+#endi=
f=0A+}=0A+=0A+#ifndef DBGP_DEBUG=0A+static inline __attribute__ ((format =
(printf, 1, 2))) void=0A+dbgp_printk(const char *fmt, ...) { }=0A+#endif=0A=
+=0A+static inline u32 dbgp_len_update(u32 x, u32 len)=0A+{=0A+    return =
(x & ~DBGP_LEN) | (len & DBGP_LEN) | DBGP_OUT;=0A+}=0A+=0A+static inline =
u32 dbgp_pid_write_update(u32 x, u32 tok)=0A+{=0A+    static u8 data0 =3D =
USB_PID_DATA1;=0A+=0A+    data0 ^=3D USB_PID_DATA0 ^ USB_PID_DATA1;=0A+    =
return (x & 0xffff0000) | (data0 << 8) | (tok & 0xff);=0A+}=0A+=0A+static =
inline u32 dbgp_pid_read_update(u32 x, u32 tok)=0A+{=0A+    return (x & =
0xffffff00) | (tok & 0xff);=0A+}=0A+=0A+static inline void dbgp_set_data(st=
ruct ehci_dbg_port __iomem *ehci_debug,=0A+                                =
 const void *buf, unsigned int size)=0A+{=0A+    const unsigned char =
*bytes =3D buf;=0A+    u32 lo =3D 0, hi =3D 0;=0A+    unsigned int =
i;=0A+=0A+    for ( i =3D 0; i < 4 && i < size; i++ )=0A+        lo |=3D =
bytes[i] << (8 * i);=0A+    for ( ; i < 8 && i < size; i++ )=0A+        hi =
|=3D bytes[i] << (8 * (i - 4));=0A+    writel(lo, &ehci_debug->data03);=0A+=
    writel(hi, &ehci_debug->data47);=0A+}=0A+=0A+static inline void =
dbgp_get_data(struct ehci_dbg_port __iomem *ehci_debug,=0A+                =
                 void *buf, int size)=0A+{=0A+    unsigned char *bytes =3D =
buf;=0A+    u32 lo =3D readl(&ehci_debug->data03);=0A+    u32 hi =3D =
readl(&ehci_debug->data47);=0A+    unsigned int i;=0A+=0A+    for ( i =3D =
0; i < 4 && i < size; i++ )=0A+        bytes[i] =3D (lo >> (8 * i)) & =
0xff;=0A+    for ( ; i < 8 && i < size; i++ )=0A+        bytes[i] =3D (hi =
>> (8 * (i - 4))) & 0xff;=0A+}=0A+=0A+static void dbgp_issue_command(struct=
 ehci_dbgp *dbgp, u32 ctrl,=0A+                               enum =
dbgp_state state)=0A+{=0A+    u32 cmd =3D readl(&dbgp->ehci_regs->command);=
=0A+=0A+    if ( unlikely(!(cmd & CMD_RUN)) )=0A+    {=0A+        /*=0A+   =
      * If the EHCI controller is not in the run state do extended=0A+     =
    * checks to see if ACPI or some other initialization also=0A+         =
* reset the EHCI debug port.=0A+         */=0A+        u32 ctrl =3D =
readl(&dbgp->ehci_debug->control);=0A+=0A+        if ( ctrl & DBGP_ENABLED =
)=0A+        {=0A+            cmd |=3D CMD_RUN;=0A+            writel(cmd, =
&dbgp->ehci_regs->command);=0A+            dbgp->reset_run =3D 1;=0A+      =
  }=0A+        else if ( dbgp->state !=3D dbgp_unsafe )=0A+        {=0A+   =
         dbgp->state =3D dbgp_unsafe;=0A+            ehci_dbgp_external_sta=
rtup(dbgp);=0A+        }=0A+    }=0A+=0A+    writel(ctrl | DBGP_GO, =
&dbgp->ehci_debug->control);=0A+    dbgp->timeout =3D DBGP_TIMEOUT;=0A+    =
if ( dbgp->state !=3D dbgp_unsafe )=0A+        dbgp->state =3D state;=0A+}=
=0A+=0A+static int dbgp_check_for_completion(struct ehci_dbgp *dbgp,=0A+   =
                                  unsigned int interval, u8 *ppid)=0A+{=0A+=
    u32 ctrl;=0A+    int ret;=0A+=0A+    if ( dbgp->state =3D=3D dbgp_idle =
)=0A+        return 0;=0A+=0A+    ctrl =3D readl(&dbgp->ehci_debug->control=
) & ~DBGP_GO;=0A+    if ( !(ctrl & DBGP_DONE) )=0A+    {=0A+        if ( =
dbgp->timeout > interval )=0A+            dbgp->timeout -=3D interval;=0A+ =
       else if ( interval )=0A+        {=0A+            /* See the timeout =
related comment in dbgp_wait_until_done(). */=0A+            dbgp->state =
=3D dbgp_unsafe;=0A+            dbgp->timeout =3D 0;=0A+        }=0A+      =
  return -DBGP_TIMEOUT;=0A+    }=0A+=0A+    if ( ctrl & DBGP_ERROR )=0A+   =
 {=0A+        ret =3D -DBGP_ERRCODE(ctrl);=0A+        if ( ret =3D=3D =
-DBGP_ERR_BAD && dbgp->timeout > interval )=0A+            ctrl |=3D =
DBGP_GO;=0A+    }=0A+    else=0A+    {=0A+        u8 pid =3D DBGP_PID_GET(r=
eadl(&dbgp->ehci_debug->pids));=0A+=0A+        ret =3D ctrl & DBGP_LEN;=0A+=
        if ( ppid )=0A+            *ppid =3D pid;=0A+        else if ( =
dbgp->state =3D=3D dbgp_in )=0A+        {=0A+            dbgp_get_data(dbgp=
->ehci_debug, dbgp->in.buf, ret);=0A+            dbgp->in.chunk =3D =
ret;=0A+        }=0A+        else if ( pid =3D=3D USB_PID_NAK && dbgp->time=
out > interval )=0A+            ctrl |=3D DBGP_GO;=0A+    }=0A+=0A+    =
writel(ctrl, &dbgp->ehci_debug->control);=0A+    if ( ctrl & DBGP_GO )=0A+ =
   {=0A+        dbgp->timeout -=3D interval;=0A+        return -DBGP_TIMEOU=
T;=0A+    }=0A+=0A+    if ( unlikely(dbgp->reset_run) )=0A+    {=0A+       =
 writel(readl(&dbgp->ehci_regs->command) & ~CMD_RUN,=0A+               =
&dbgp->ehci_regs->command);=0A+        dbgp->reset_run =3D 0;=0A+    =
}=0A+=0A+    if ( dbgp->state !=3D dbgp_unsafe )=0A+        dbgp->state =
=3D dbgp_idle;=0A+=0A+    return ret;=0A+}=0A+=0A+static int dbgp_wait_unti=
l_complete(struct ehci_dbgp *dbgp, u8 *ppid)=0A+{=0A+    unsigned int loop =
=3D DBGP_TIMEOUT;=0A+    int ret;=0A+=0A+    do {=0A+        ret =3D =
dbgp_check_for_completion(dbgp, 0, ppid);=0A+        if ( ret !=3D =
-DBGP_TIMEOUT )=0A+            break;=0A+        udelay(1);=0A+    } while =
( --loop );=0A+=0A+    if ( !ppid && !loop )=0A+        dbgp->state =3D =
dbgp_unsafe;=0A+=0A+    return ret;=0A+}=0A+=0A+static inline void =
dbgp_mdelay(unsigned int ms)=0A+{=0A+    while ( ms-- )=0A+    {=0A+       =
 unsigned int i;=0A+=0A+        for ( i =3D 0; i < 1000; i++ )=0A+         =
   outb(0x1, 0x80);=0A+    }=0A+}=0A+=0A+static void dbgp_breathe(void)=0A+=
{=0A+    /* Sleep to give the debug port a chance to breathe. */=0A+    =
dbgp_mdelay(1);=0A+}=0A+=0A+static int dbgp_wait_until_done(struct =
ehci_dbgp *dbgp, u32 ctrl,=0A+                                unsigned int =
loop)=0A+{=0A+    int ret;=0A+=0A+    dbgp->timeout =3D 0;=0A+=0A+    for =
( ; ; writel(ctrl | DBGP_GO, &dbgp->ehci_debug->control) )=0A+    {=0A+    =
    u8 pid;=0A+=0A+        ret =3D dbgp_wait_until_complete(dbgp, =
&pid);=0A+        if ( ret < 0 )=0A+        {=0A+            /*=0A+        =
     * A -DBGP_TIMEOUT failure here means the device has failed,=0A+       =
      * perhaps because it was unplugged, in which case we do not=0A+      =
       * want to hang the system so the dbgp will be marked as unsafe=0A+  =
           * to use. EHCI reset is the only way to recover if you =
unplug=0A+             * the dbgp device.=0A+             */=0A+           =
 if ( ret =3D=3D -DBGP_TIMEOUT )=0A+                dbgp->state =3D =
dbgp_unsafe;=0A+            if ( ret !=3D -DBGP_ERR_BAD || !--loop )=0A+   =
             break;=0A+        }=0A+        else=0A+        {=0A+          =
  /*=0A+             * If the port is getting full or it has dropped =
data=0A+             * start pacing ourselves, not necessary but it's =
friendly.=0A+             */=0A+            if ( pid =3D=3D USB_PID_NAK || =
pid =3D=3D USB_PID_NYET )=0A+                dbgp_breathe();=0A+=0A+       =
     /* If we got a NACK, reissue the transmission. */=0A+            if ( =
pid !=3D USB_PID_NAK || !--loop )=0A+                break;=0A+        =
}=0A+    }=0A+=0A+    return ret;=0A+}=0A+=0A+static int dbgp_bulk_write(st=
ruct ehci_dbgp *dbgp,=0A+                           unsigned int devnum, =
unsigned int endpoint,=0A+                           const void *bytes, =
unsigned int size, u32 *pctrl)=0A+{=0A+    u32 addr, pids, ctrl;=0A+=0A+   =
 if ( size > DBGP_MAX_PACKET )=0A+        return -EINVAL;=0A+=0A+    addr =
=3D DBGP_EPADDR(devnum, endpoint);=0A+    pids =3D dbgp_pid_write_update(re=
adl(&dbgp->ehci_debug->pids), USB_PID_OUT);=0A+    ctrl =3D dbgp_len_update=
(readl(&dbgp->ehci_debug->control), size);=0A+    if ( pctrl )=0A+        =
*pctrl =3D ctrl;=0A+=0A+    dbgp_set_data(dbgp->ehci_debug, bytes, =
size);=0A+    writel(addr, &dbgp->ehci_debug->address);=0A+    writel(pids,=
 &dbgp->ehci_debug->pids);=0A+    dbgp_issue_command(dbgp, ctrl, dbgp_out);=
=0A+=0A+    return 0;=0A+}=0A+=0A+static int dbgp_bulk_read(struct =
ehci_dbgp *dbgp,=0A+                          unsigned int devnum, =
unsigned int endpoint,=0A+                          unsigned int size, u32 =
*pctrl)=0A+{=0A+    u32 addr, pids, ctrl;=0A+=0A+    if ( size > DBGP_MAX_P=
ACKET )=0A+        return -EINVAL;=0A+=0A+    addr =3D DBGP_EPADDR(devnum, =
endpoint);=0A+    pids =3D dbgp_pid_read_update(readl(&dbgp->ehci_debug->pi=
ds), USB_PID_IN);=0A+    ctrl =3D readl(&dbgp->ehci_debug->control) & =
~DBGP_OUT;=0A+=0A+    writel(addr, &dbgp->ehci_debug->address);=0A+    =
writel(pids, &dbgp->ehci_debug->pids);=0A+    if ( likely(!pctrl) )=0A+    =
    dbgp_issue_command(dbgp, ctrl, dbgp_in);=0A+    else=0A+        =
dbgp_issue_command(dbgp, *pctrl =3D ctrl, dbgp_ctrl);=0A+=0A+    return =
0;=0A+}=0A+=0A+static int dbgp_control_msg(struct ehci_dbgp *dbgp, =
unsigned int devnum,=0A+                            int requesttype, int =
request, int value,=0A+                            int index, void *data, =
unsigned int size)=0A+{=0A+    u32 addr, pids, ctrl;=0A+    struct =
usb_ctrlrequest req;=0A+    bool_t read =3D (requesttype & USB_DIR_IN) =
!=3D 0;=0A+    int ret;=0A+=0A+    if ( size > (read ? DBGP_MAX_PACKET : =
0) )=0A+        return -EINVAL;=0A+=0A+    /* Compute the control message =
*/=0A+    req.bRequestType =3D requesttype;=0A+    req.bRequest =3D =
request;=0A+    req.wValue =3D cpu_to_le16(value);=0A+    req.wIndex =3D =
cpu_to_le16(index);=0A+    req.wLength =3D cpu_to_le16(size);=0A+=0A+    =
pids =3D DBGP_PID_SET(USB_PID_DATA0, USB_PID_SETUP);=0A+    addr =3D =
DBGP_EPADDR(devnum, 0);=0A+    ctrl =3D dbgp_len_update(readl(&dbgp->ehci_d=
ebug->control), sizeof(req));=0A+=0A+    /* Send the setup message */=0A+  =
  dbgp_set_data(dbgp->ehci_debug, &req, sizeof(req));=0A+    writel(addr, =
&dbgp->ehci_debug->address);=0A+    writel(pids, &dbgp->ehci_debug->pids);=
=0A+    dbgp_issue_command(dbgp, ctrl, dbgp_ctrl);=0A+    ret =3D =
dbgp_wait_until_done(dbgp, ctrl, DBGP_LOOPS);=0A+    if ( ret < 0 )=0A+    =
    return ret;=0A+=0A+    /* Read the result */=0A+    ret =3D dbgp_bulk_r=
ead(dbgp, devnum, 0, size, &ctrl);=0A+    if ( !ret )=0A+        ret =3D =
dbgp_wait_until_done(dbgp, ctrl, DBGP_LOOPS);=0A+    if ( ret > 0 )=0A+    =
{=0A+        if ( size > ret )=0A+            size =3D ret;=0A+        =
dbgp_get_data(dbgp->ehci_debug, data, size);=0A+    }=0A+=0A+    return =
ret;=0A+}=0A+=0A+static unsigned int __init __find_dbgp(u8 bus, u8 slot, =
u8 func)=0A+{=0A+    u32 class =3D pci_conf_read32(0, bus, slot, func, =
PCI_CLASS_REVISION);=0A+=0A+    if ( (class >> 8) !=3D PCI_CLASS_SERIAL_USB=
_EHCI )=0A+        return 0;=0A+=0A+    return pci_find_cap_offset(0, bus, =
slot, func, PCI_CAP_ID_EHCI_DEBUG);=0A+}=0A+=0A+static unsigned int __init =
find_dbgp(struct ehci_dbgp *dbgp,=0A+                                     =
unsigned int ehci_num)=0A+{=0A+    unsigned int bus, slot, func;=0A+=0A+   =
 for ( bus =3D 0; bus < 256; bus++ )=0A+    {=0A+        for ( slot =3D 0; =
slot < 32; slot++ )=0A+        {=0A+            for ( func =3D 0; func < =
8; func++ )=0A+            {=0A+                unsigned int cap;=0A+=0A+  =
              if ( !pci_device_detect(0, bus, slot, func) )=0A+            =
    {=0A+                    if ( !func )=0A+                        =
break;=0A+                    continue;=0A+                }=0A+=0A+       =
         cap =3D __find_dbgp(bus, slot, func);=0A+                if ( =
!cap || ehci_num-- )=0A+                {=0A+                    if ( =
!func && !(pci_conf_read8(0, bus, slot, func,=0A+                          =
                         PCI_HEADER_TYPE) & 0x80) )=0A+                    =
    break;=0A+                    continue;=0A+                }=0A+=0A+   =
             dbgp->bus =3D bus;=0A+                dbgp->slot =3D =
slot;=0A+                dbgp->func =3D func;=0A+                return =
cap;=0A+            }=0A+        }=0A+    }=0A+=0A+    return 0;=0A+}=0A+=
=0A+static int ehci_dbgp_startup(struct ehci_dbgp *dbgp)=0A+{=0A+    u32 =
ctrl, cmd, status;=0A+    unsigned int loop;=0A+=0A+    /* Claim ownership,=
 but do not enable yet */=0A+    ctrl =3D readl(&dbgp->ehci_debug->control)=
;=0A+    ctrl |=3D DBGP_OWNER;=0A+    ctrl &=3D ~(DBGP_ENABLED | DBGP_INUSE=
);=0A+    writel(ctrl, &dbgp->ehci_debug->control);=0A+    udelay(1);=0A+=
=0A+    ehci_dbgp_status(dbgp, "EHCI startup");=0A+    /* Start the EHCI. =
*/=0A+    cmd =3D readl(&dbgp->ehci_regs->command);=0A+    cmd &=3D =
~(CMD_LRESET | CMD_IAAD | CMD_PSE | CMD_ASE | CMD_RESET);=0A+    cmd |=3D =
CMD_RUN;=0A+    writel(cmd, &dbgp->ehci_regs->command);=0A+=0A+    /* =
Ensure everything is routed to the EHCI */=0A+    writel(FLAG_CF, =
&dbgp->ehci_regs->configured_flag);=0A+=0A+    /* Wait until the controller=
 is no longer halted. */=0A+    loop =3D 1000;=0A+    do {=0A+        =
status =3D readl(&dbgp->ehci_regs->status);=0A+        if ( !(status & =
STS_HALT) )=0A+            break;=0A+        udelay(1);=0A+    } while ( =
--loop );=0A+=0A+    if ( !loop )=0A+    {=0A+        dbgp_printk("EHCI =
cannot be started\n");=0A+        return -ENODEV;=0A+    }=0A+    =
dbgp_printk("EHCI started\n");=0A+=0A+    return 0;=0A+}=0A+=0A+static int =
ehci_dbgp_controller_reset(struct ehci_dbgp *dbgp)=0A+{=0A+    unsigned =
int loop =3D 250 * 1000;=0A+    u32 cmd;=0A+=0A+    /* Reset the EHCI =
controller */=0A+    cmd =3D readl(&dbgp->ehci_regs->command);=0A+    cmd =
|=3D CMD_RESET;=0A+    writel(cmd, &dbgp->ehci_regs->command);=0A+    do =
{=0A+        cmd =3D readl(&dbgp->ehci_regs->command);=0A+    } while ( =
(cmd & CMD_RESET) && --loop );=0A+=0A+    if ( !loop )=0A+    {=0A+        =
dbgp_printk("cannot reset EHCI\n");=0A+        return -1;=0A+    }=0A+    =
ehci_dbgp_status(dbgp, "ehci reset done");=0A+=0A+    return 0;=0A+}=0A+=0A=
+static int ehci_reset_port(struct ehci_dbgp *dbgp, unsigned int port)=0A+{=
=0A+    u32 portsc, delay_time, delay;=0A+=0A+    ehci_dbgp_status(dbgp, =
"reset port");=0A+    /* Reset the USB debug port. */=0A+    portsc =3D =
readl(&dbgp->ehci_regs->port_status[port - 1]);=0A+    portsc &=3D =
~PORT_PE;=0A+    portsc |=3D PORT_RESET;=0A+    writel(portsc, &dbgp->ehci_=
regs->port_status[port - 1]);=0A+=0A+    delay =3D HUB_ROOT_RESET_TIME;=0A+=
    for ( delay_time =3D 0; delay_time < HUB_RESET_TIMEOUT;=0A+          =
delay_time +=3D delay )=0A+    {=0A+        dbgp_mdelay(delay);=0A+        =
portsc =3D readl(&dbgp->ehci_regs->port_status[port - 1]);=0A+        if =
(!(portsc & PORT_RESET))=0A+            break;=0A+    }=0A+=0A+    if ( =
portsc & PORT_RESET )=0A+    {=0A+        /* force reset to complete =
*/=0A+        unsigned int loop =3D 100 * 1000;=0A+=0A+        writel(ports=
c & ~(PORT_RWC_BITS | PORT_RESET),=0A+               &dbgp->ehci_regs->port=
_status[port - 1]);=0A+        do {=0A+            udelay(1);=0A+          =
  portsc =3D readl(&dbgp->ehci_regs->port_status[port-1]);=0A+        } =
while ( (portsc & PORT_RESET) && --loop );=0A+    }=0A+=0A+    /* Device =
went away? */=0A+    if ( !(portsc & PORT_CONNECT) )=0A+        return =
-ENOTCONN;=0A+=0A+    /* bomb out completely if something weird happened =
*/=0A+    if ( portsc & PORT_CSC )=0A+        return -EINVAL;=0A+=0A+    =
/* If we've finished resetting, then break out of the loop */=0A+    if ( =
!(portsc & PORT_RESET) && (portsc & PORT_PE) )=0A+        return 0;=0A+=0A+=
    return -EBUSY;=0A+}=0A+=0A+static int ehci_wait_for_port(struct =
ehci_dbgp *dbgp, unsigned int port)=0A+{=0A+    u32 status;=0A+    =
unsigned int reps;=0A+=0A+    for ( reps =3D 0; reps < 300; reps++ )=0A+   =
 {=0A+        status =3D readl(&dbgp->ehci_regs->status);=0A+        if ( =
status & STS_PCD )=0A+            break;=0A+        dbgp_mdelay(1);=0A+    =
}=0A+=0A+    return ehci_reset_port(dbgp, port) =3D=3D 0 ? 0 : -ENOTCONN;=
=0A+}=0A+=0A+/* Return 0 on success=0A+ * Return -ENODEV for any general =
failure=0A+ * Return -EIO if wait for port fails=0A+ */=0A+static int =
ehci_dbgp_external_startup(struct ehci_dbgp *dbgp)=0A+{=0A+    unsigned =
int devnum;=0A+    struct usb_debug_descriptor dbgp_desc;=0A+    int =
ret;=0A+    u32 ctrl, portsc, cmd;=0A+    unsigned int dbg_port =3D =
dbgp->phys_port;=0A+    unsigned int tries =3D 3;=0A+    unsigned int =
reset_port_tries =3D 1;=0A+    bool_t try_hard_once =3D 1;=0A+=0A+try_port_=
reset_again:=0A+    ret =3D ehci_dbgp_startup(dbgp);=0A+    if ( ret )=0A+ =
       return ret;=0A+=0A+    /* Wait for a device to show up in the debug =
port */=0A+    ret =3D ehci_wait_for_port(dbgp, dbg_port);=0A+    if ( ret =
< 0 )=0A+    {=0A+        portsc =3D readl(&dbgp->ehci_regs->port_status[db=
g_port - 1]);=0A+        if ( !(portsc & PORT_CONNECT) && try_hard_once =
)=0A+        {=0A+            /*=0A+             * Last ditch effort to =
try to force enable the debug device by=0A+             * using the packet =
test EHCI command to try and wake it up.=0A+             */=0A+            =
try_hard_once =3D 0;=0A+            cmd =3D readl(&dbgp->ehci_regs->command=
);=0A+            cmd &=3D ~CMD_RUN;=0A+            writel(cmd, &dbgp->ehci=
_regs->command);=0A+            portsc =3D readl(&dbgp->ehci_regs->port_sta=
tus[dbg_port - 1]);=0A+            portsc |=3D PORT_TEST_PKT;=0A+          =
  writel(portsc, &dbgp->ehci_regs->port_status[dbg_port - 1]);=0A+         =
   ehci_dbgp_status(dbgp, "Trying to force debug port online");=0A+        =
    mdelay(50);=0A+            ehci_dbgp_controller_reset(dbgp);=0A+       =
     goto try_port_reset_again;=0A+        }=0A+        else if ( =
reset_port_tries-- )=0A+            goto try_port_reset_again;=0A+        =
dbgp_printk("no device found in debug port\n");=0A+        return =
-EIO;=0A+    }=0A+    ehci_dbgp_status(dbgp, "wait for port done");=0A+=0A+=
    /* Enable the debug port */=0A+    ctrl =3D readl(&dbgp->ehci_debug->co=
ntrol);=0A+    ctrl |=3D DBGP_CLAIM;=0A+    writel(ctrl, &dbgp->ehci_debug-=
>control);=0A+    ctrl =3D readl(&dbgp->ehci_debug->control);=0A+    if ( =
(ctrl & DBGP_CLAIM) !=3D DBGP_CLAIM )=0A+    {=0A+        dbgp_printk("no =
device in debug port\n");=0A+        writel(ctrl & ~DBGP_CLAIM, &dbgp->ehci=
_debug->control);=0A+        return -ENODEV;=0A+    }=0A+    ehci_dbgp_stat=
us(dbgp, "debug port enabled");=0A+=0A+    /* Completely transfer the =
debug device to the debug controller */=0A+    portsc =3D readl(&dbgp->ehci=
_regs->port_status[dbg_port - 1]);=0A+    portsc &=3D ~PORT_PE;=0A+    =
writel(portsc, &dbgp->ehci_regs->port_status[dbg_port - 1]);=0A+=0A+    =
dbgp_mdelay(100);=0A+=0A+try_again:=0A+    /* Find the debug device and =
make it device number 127 */=0A+    for ( devnum =3D 0; devnum <=3D 127; =
devnum++ )=0A+    {=0A+        ret =3D dbgp_control_msg(dbgp, devnum,=0A+  =
                             USB_DIR_IN | USB_TYPE_STANDARD | USB_RECIP_DEV=
ICE,=0A+                               USB_REQ_GET_DESCRIPTOR, (USB_DT_DEBU=
G << 8), 0,=0A+                               &dbgp_desc, sizeof(dbgp_desc)=
);=0A+        if ( ret > 0 )=0A+            break;=0A+    }=0A+    if ( =
devnum > 127 )=0A+    {=0A+        dbgp_printk("could not find attached =
debug device\n");=0A+        goto err;=0A+    }=0A+    if ( ret < 0 )=0A+  =
  {=0A+        dbgp_printk("attached device is not a debug device\n");=0A+ =
       goto err;=0A+    }=0A+    dbgp->out.endpoint =3D dbgp_desc.bDebugOut=
Endpoint;=0A+    dbgp->in.endpoint =3D dbgp_desc.bDebugInEndpoint;=0A+=0A+ =
   /* Move the device to 127 if it isn't already there. */=0A+    if ( =
devnum !=3D USB_DEBUG_DEVNUM )=0A+    {=0A+        ret =3D dbgp_control_msg=
(dbgp, devnum,=0A+                               USB_DIR_OUT | USB_TYPE_STA=
NDARD | USB_RECIP_DEVICE,=0A+                               USB_REQ_SET_ADD=
RESS, USB_DEBUG_DEVNUM, 0, NULL, 0);=0A+        if ( ret < 0 )=0A+        =
{=0A+            dbgp_printk("could not move attached device to %d\n",=0A+ =
                       USB_DEBUG_DEVNUM);=0A+            goto err;=0A+     =
   }=0A+        devnum =3D USB_DEBUG_DEVNUM;=0A+        dbgp_printk("debug =
device renamed to 127\n");=0A+    }=0A+=0A+    /* Enable the debug =
interface */=0A+    ret =3D dbgp_control_msg(dbgp, USB_DEBUG_DEVNUM,=0A+   =
                        USB_DIR_OUT | USB_TYPE_STANDARD | USB_RECIP_DEVICE,=
=0A+                           USB_REQ_SET_FEATURE, USB_DEVICE_DEBUG_MODE,=
=0A+                           0, NULL, 0);=0A+    if ( ret < 0 )=0A+    =
{=0A+        dbgp_printk("could not enable the debug device\n");=0A+       =
 goto err;=0A+    }=0A+    dbgp_printk("debug interface enabled\n");=0A+=0A=
+    /* Perform a small write to get the even/odd data state in sync. =
*/=0A+    ret =3D dbgp_bulk_write(dbgp, USB_DEBUG_DEVNUM, dbgp->out.endpoin=
t,=0A+                          "\n", 1, &ctrl);=0A+    if ( !ret )=0A+    =
    ret =3D dbgp_wait_until_done(dbgp, ctrl, DBGP_LOOPS);=0A+    if ( ret =
< 0 )=0A+    {=0A+        dbgp_printk("dbgp_bulk_write failed: %d\n", =
ret);=0A+        goto err;=0A+    }=0A+    dbgp_printk("small write =
done\n");=0A+    dbgp->state =3D dbgp_idle;=0A+=0A+    return 0;=0A+err:=0A=
+    if ( tries-- )=0A+        goto try_again;=0A+    return -ENODEV;=0A+}=
=0A+=0A+typedef void (*set_debug_port_t)(struct ehci_dbgp *, unsigned =
int);=0A+=0A+static void default_set_debug_port(struct ehci_dbgp *dbgp, =
unsigned int port)=0A+{=0A+}=0A+=0A+static set_debug_port_t __read_mostly =
set_debug_port =3D default_set_debug_port;=0A+=0A+static void nvidia_set_de=
bug_port(struct ehci_dbgp *dbgp, unsigned int port)=0A+{=0A+    u32 dword =
=3D pci_conf_read32(0, dbgp->bus, dbgp->slot, dbgp->func, 0x74);=0A+=0A+   =
 dword &=3D ~(0x0f << 12);=0A+    dword |=3D (port & 0x0f) << 12;=0A+    =
pci_conf_write32(0, dbgp->bus, dbgp->slot, dbgp->func, 0x74, dword);=0A+   =
 dbgp_printk("set debug port to %u\n", port);=0A+}=0A+=0A+static void =
__init detect_set_debug_port(struct ehci_dbgp *dbgp)=0A+{=0A+    if ( =
pci_conf_read16(0, dbgp->bus, dbgp->slot, dbgp->func,=0A+                  =
       PCI_VENDOR_ID) =3D=3D 0x10de )=0A+    {=0A+        dbgp_printk("usin=
g nvidia set_debug_port\n");=0A+        set_debug_port =3D nvidia_set_debug=
_port;=0A+    }=0A+}=0A+=0A+/*=0A+ * The code in ehci_dbgp_bios_handoff() =
is derived from the USB PCI=0A+ * quirk initialization in Linux.=0A+ =
*/=0A+#define EHCI_USBLEGSUP_BIOS    (1 << 16) /* BIOS semaphore */=0A+#def=
ine EHCI_USBLEGCTLSTS      4        /* legacy control/status */=0A+static =
void ehci_dbgp_bios_handoff(struct ehci_dbgp *dbgp, u32 hcc_params)=0A+{=0A=
+    u32 cap;=0A+    unsigned int offset =3D HCC_EXT_CAPS(hcc_params);=0A+ =
   int msec;=0A+=0A+    if ( !offset )=0A+        return;=0A+=0A+    cap =
=3D pci_conf_read32(0, dbgp->bus, dbgp->slot, dbgp->func, offset);=0A+    =
dbgp_printk("dbgp: EHCI BIOS state %08x\n", cap);=0A+=0A+    if ( (cap & =
0xff) =3D=3D 1 && (cap & EHCI_USBLEGSUP_BIOS) )=0A+    {=0A+        =
dbgp_printk("dbgp: BIOS handoff\n");=0A+        pci_conf_write8(0, =
dbgp->bus, dbgp->slot, dbgp->func, offset + 3, 1);=0A+    }=0A+=0A+    /* =
if boot firmware now owns EHCI, spin till it hands it over. */=0A+    msec =
=3D 1000;=0A+    while ( (cap & EHCI_USBLEGSUP_BIOS) && (msec > 0) )=0A+   =
 {=0A+        mdelay(10);=0A+        msec -=3D 10;=0A+        cap =3D =
pci_conf_read32(0, dbgp->bus, dbgp->slot, dbgp->func, offset);=0A+    =
}=0A+=0A+    if ( cap & EHCI_USBLEGSUP_BIOS )=0A+    {=0A+        /* well, =
possibly buggy BIOS... try to shut it down,=0A+         * and hope nothing =
goes too wrong */=0A+        dbgp_printk("dbgp: BIOS handoff failed: =
%08x\n", cap);=0A+        pci_conf_write8(0, dbgp->bus, dbgp->slot, =
dbgp->func, offset + 2, 0);=0A+    }=0A+=0A+    /* just in case, always =
disable EHCI SMIs */=0A+    pci_conf_write8(0, dbgp->bus, dbgp->slot, =
dbgp->func,=0A+                    offset + EHCI_USBLEGCTLSTS, 0);=0A+}=0A+=
=0A+static int ehci_dbgp_setup(struct ehci_dbgp *dbgp)=0A+{=0A+    u32 =
ctrl, portsc, hcs_params;=0A+    unsigned int i, debug_port, new_debug_port=
 =3D 0, n_ports;=0A+    unsigned int port_map_tried, playtimes =3D 3;=0A+  =
  int ret;=0A+=0A+    ehci_dbgp_bios_handoff(dbgp, readl(&dbgp->ehci_caps->=
hcc_params));=0A+=0A+try_next_time:=0A+    port_map_tried =3D 0;=0A+=0A+try=
_next_port:=0A+=0A+    hcs_params =3D readl(&dbgp->ehci_caps->hcs_params);=
=0A+    debug_port =3D HCS_DEBUG_PORT(hcs_params);=0A+    dbgp->phys_port =
=3D debug_port;=0A+    n_ports =3D HCS_N_PORTS(hcs_params);=0A+=0A+    =
dbgp_printk("debug_port: %u\n", debug_port);=0A+    dbgp_printk("n_ports:  =
  %u\n", n_ports);=0A+    ehci_dbgp_status(dbgp, "");=0A+=0A+    for ( i =
=3D 1; i <=3D n_ports; i++ )=0A+    {=0A+        portsc =3D readl(&dbgp->eh=
ci_regs->port_status[i-1]);=0A+        dbgp_printk("portstatus%d: %08x\n", =
i, portsc);=0A+    }=0A+=0A+    if ( port_map_tried && (new_debug_port =
!=3D debug_port) )=0A+    {=0A+        if ( --playtimes )=0A+        {=0A+ =
           set_debug_port(dbgp, new_debug_port);=0A+            goto =
try_next_time;=0A+        }=0A+        return -1;=0A+    }=0A+=0A+    /* =
Only reset the controller if it is not already in the=0A+     * configured =
state */=0A+    if ( readl(&dbgp->ehci_regs->configured_flag) & FLAG_CF =
)=0A+        ehci_dbgp_status(dbgp, "ehci skip - already configured");=0A+ =
   else if ( ehci_dbgp_controller_reset(dbgp) !=3D 0 )=0A+        return =
-1;=0A+=0A+    ret =3D ehci_dbgp_external_startup(dbgp);=0A+    if (ret =
=3D=3D -EIO)=0A+        goto next_debug_port;=0A+=0A+    if ( ret < 0 =
)=0A+    {=0A+        /* Things didn't work so remove my claim */=0A+      =
  ctrl =3D readl(&dbgp->ehci_debug->control);=0A+        ctrl &=3D =
~(DBGP_CLAIM | DBGP_OUT);=0A+        writel(ctrl, &dbgp->ehci_debug->contro=
l);=0A+        return -1;=0A+    }=0A+=0A+    return 0;=0A+=0A+next_debug_p=
ort:=0A+    port_map_tried |=3D 1 << (debug_port - 1);=0A+    new_debug_por=
t =3D (debug_port % n_ports) + 1;=0A+    if ( port_map_tried !=3D ((1 << =
n_ports) - 1) )=0A+    {=0A+        set_debug_port(dbgp, new_debug_port);=
=0A+        goto try_next_port;=0A+    }=0A+    if ( --playtimes )=0A+    =
{=0A+        set_debug_port(dbgp, new_debug_port);=0A+        goto =
try_next_time;=0A+    }=0A+=0A+    return -1;=0A+}=0A+=0A+static inline =
void _ehci_dbgp_flush(struct ehci_dbgp *dbgp)=0A+{=0A+    if ( dbgp_bulk_wr=
ite(dbgp, USB_DEBUG_DEVNUM, dbgp->out.endpoint,=0A+                        =
 dbgp->out.buf, dbgp->out.chunk, NULL) )=0A+        BUG();=0A+    =
dbgp->out.chunk =3D 0;=0A+}=0A+=0A+static void ehci_dbgp_flush(struct =
serial_port *port)=0A+{=0A+    struct ehci_dbgp *dbgp =3D port->uart;=0A+  =
  s_time_t goal;=0A+=0A+    if ( !dbgp->out.chunk || !dbgp->ehci_debug || =
dbgp->state =3D=3D dbgp_unsafe )=0A+        return;=0A+=0A+    if ( =
dbgp->state =3D=3D dbgp_idle || !port->sync )=0A+        dbgp_check_for_com=
pletion(dbgp, 1, NULL);=0A+    else=0A+        dbgp_wait_until_complete(dbg=
p, NULL);=0A+=0A+    if ( dbgp->state =3D=3D dbgp_idle )=0A+    {=0A+      =
  _ehci_dbgp_flush(dbgp);=0A+=0A+        if ( port->sync )=0A+        =
{=0A+            dbgp_wait_until_complete(dbgp, NULL);=0A+            =
return;=0A+        }=0A+    }=0A+=0A+    goal =3D NOW() + MICROSECS(DBGP_CH=
ECK_INTERVAL);=0A+    if ( dbgp->timer.expires > goal )=0A+       =
set_timer(&dbgp->timer, goal);=0A+}=0A+=0A+static void ehci_dbgp_putc(struc=
t serial_port *port, char c)=0A+{=0A+    struct ehci_dbgp *dbgp =3D =
port->uart;=0A+=0A+    if ( unlikely(dbgp->out.chunk >=3D DBGP_MAX_PACKET) =
)=0A+        return;=0A+=0A+    dbgp->out.buf[dbgp->out.chunk++] =3D =
c;=0A+=0A+    if ( dbgp->out.chunk =3D=3D DBGP_MAX_PACKET )=0A+        =
ehci_dbgp_flush(port);=0A+}=0A+=0A+static int ehci_dbgp_tx_empty(struct =
serial_port *port)=0A+{=0A+    struct ehci_dbgp *dbgp =3D port->uart;=0A+=
=0A+    if ( unlikely(!dbgp->ehci_debug) || unlikely(dbgp->state =3D=3D =
dbgp_unsafe) )=0A+        return port->sync || port->tx_log_everything || =
!port->txbuf;=0A+=0A+    if ( dbgp->out.chunk =3D=3D DBGP_MAX_PACKET )=0A+ =
       ehci_dbgp_flush(port);=0A+    else=0A+        dbgp_check_for_complet=
ion(dbgp, 1, NULL);=0A+=0A+    if ( dbgp->state !=3D dbgp_idle && =
dbgp->out.chunk >=3D DBGP_MAX_PACKET )=0A+        return 0;=0A+=0A+    =
port->tx_fifo_size =3D DBGP_MAX_PACKET - dbgp->out.chunk;=0A+    if ( =
dbgp->state =3D=3D dbgp_idle )=0A+        port->tx_fifo_size +=3D =
DBGP_MAX_PACKET;=0A+=0A+    return 1;=0A+}=0A+=0A+static int ehci_dbgp_getc=
(struct serial_port *port, char *pc)=0A+{=0A+    struct ehci_dbgp *dbgp =
=3D port->uart;=0A+=0A+    if ( !dbgp->in.chunk )=0A+        return =
0;=0A+=0A+    *pc =3D *dbgp->in.buf;=0A+    if ( --dbgp->in.chunk )=0A+    =
    memmove(dbgp->in.buf, dbgp->in.buf + 1, dbgp->in.chunk);=0A+=0A+    =
return 1;=0A+}=0A+=0A+/* Safe: ehci_dbgp_poll() runs as timer handler, so =
not reentrant. */=0A+static struct serial_port *poll_port;=0A+=0A+static =
void _ehci_dbgp_poll(struct cpu_user_regs *regs)=0A+{=0A+    struct =
serial_port *port =3D poll_port;=0A+    struct ehci_dbgp *dbgp =3D =
port->uart;=0A+    unsigned long flags;=0A+    unsigned int timeout =3D =
MICROSECS(DBGP_CHECK_INTERVAL);=0A+    bool_t empty =3D 0;=0A+=0A+    if ( =
!dbgp->ehci_debug )=0A+        return;=0A+=0A+    if ( spin_trylock_irqsave=
(&port->tx_lock, flags) )=0A+    {=0A+        if ( dbgp->state !=3D =
dbgp_unsafe )=0A+            dbgp_check_for_completion(dbgp, DBGP_CHECK_INT=
ERVAL, NULL);=0A+        if ( dbgp->state =3D=3D dbgp_idle && dbgp->out.chu=
nk )=0A+            _ehci_dbgp_flush(dbgp);=0A+        if ( dbgp->state =
=3D=3D dbgp_idle || dbgp->out.chunk < DBGP_MAX_PACKET )=0A+            =
empty =3D 1;=0A+        spin_unlock_irqrestore(&port->tx_lock, flags);=0A+ =
   }=0A+=0A+    if ( dbgp->in.chunk )=0A+        serial_rx_interrupt(port, =
regs);=0A+=0A+    if ( empty )=0A+        serial_tx_interrupt(port, =
regs);=0A+=0A+    if ( spin_trylock_irqsave(&port->tx_lock, flags) )=0A+   =
 {=0A+        if ( dbgp->state =3D=3D dbgp_idle && !dbgp->in.chunk &&=0A+  =
           !dbgp->out.chunk && port->txbufp =3D=3D port->txbufc )=0A+      =
  {=0A+            if ( dbgp_bulk_read(dbgp, USB_DEBUG_DEVNUM, dbgp->in.end=
point,=0A+                                DBGP_MAX_PACKET, NULL) )=0A+     =
           BUG();=0A+            timeout =3D MILLISECS(DBGP_IDLE_INTERVAL);=
=0A+        }=0A+        spin_unlock_irqrestore(&port->tx_lock, flags);=0A+=
    }=0A+=0A+    set_timer(&dbgp->timer, NOW() + timeout);=0A+}=0A+=0A+stat=
ic void ehci_dbgp_poll(void *data)=0A+{=0A+    poll_port =3D data;=0A+#ifde=
f run_in_exception_handler=0A+    run_in_exception_handler(_ehci_dbgp_poll)=
;=0A+#else=0A+    _ehci_dbgp_poll(guest_cpu_user_regs());=0A+#endif=0A+}=0A=
+=0A+static bool_t ehci_dbgp_setup_preirq(struct ehci_dbgp *dbgp)=0A+{=0A+ =
   if ( !ehci_dbgp_setup(dbgp) )=0A+        return 1;=0A+=0A+    dbgp_print=
k("ehci_dbgp_setup failed\n");=0A+    dbgp->ehci_debug =3D NULL;=0A+    =
return 0;=0A+}=0A+=0A+static void __init ehci_dbgp_init_preirq(struct =
serial_port *port)=0A+{=0A+    struct ehci_dbgp *dbgp =3D port->uart;=0A+  =
  u32 debug_port, offset;=0A+    void __iomem *ehci_bar;=0A+=0A+    =
debug_port =3D pci_conf_read32(0, dbgp->bus, dbgp->slot, dbgp->func,=0A+   =
                              dbgp->cap);=0A+    offset =3D (debug_port >> =
16) & 0xfff;=0A+=0A+    /* double check if the mem space is enabled */=0A+ =
   dbgp->pci_cr =3D pci_conf_read8(0, dbgp->bus, dbgp->slot, dbgp->func,=0A=
+                                  PCI_COMMAND);=0A+    if ( !(dbgp->pci_cr=
 & PCI_COMMAND_MEMORY) )=0A+    {=0A+        dbgp->pci_cr |=3D PCI_COMMAND_=
MEMORY;=0A+        pci_conf_write16(0, dbgp->bus, dbgp->slot, dbgp->func, =
PCI_COMMAND,=0A+                         dbgp->pci_cr);=0A+        =
dbgp_printk("MMIO for EHCI enabled\n");=0A+    }=0A+=0A+    /*=0A+     * =
FIXME I don't have the bar size so just guess PAGE_SIZE is more=0A+     * =
than enough.  1k is the biggest that was seen.=0A+     */=0A+    set_fixmap=
_nocache(FIX_EHCI_DBGP, dbgp->bar_val);=0A+    ehci_bar =3D (void __iomem =
*)fix_to_virt(FIX_EHCI_DBGP);=0A+    ehci_bar +=3D dbgp->bar_val & =
~PAGE_MASK;=0A+    dbgp_printk("ehci_bar: %p\n", ehci_bar);=0A+=0A+    =
dbgp->ehci_caps =3D ehci_bar;=0A+    dbgp->ehci_regs =3D ehci_bar +=0A+    =
                  HC_LENGTH(readl(&dbgp->ehci_caps->hc_capbase));=0A+    =
dbgp->ehci_debug =3D ehci_bar + offset;=0A+=0A+    detect_set_debug_port(db=
gp);=0A+=0A+    if ( ehci_dbgp_setup_preirq(dbgp) )=0A+        ehci_dbgp_st=
atus(dbgp, "ehci_dbgp_init_preirq complete");=0A+=0A+    port->tx_fifo_size=
 =3D DBGP_MAX_PACKET;=0A+    dbgp->lock =3D &port->tx_lock;=0A+}=0A+=0A+sta=
tic void ehci_dbgp_setup_postirq(struct ehci_dbgp *dbgp)=0A+{=0A+    =
set_timer(&dbgp->timer, NOW() + MILLISECS(1));=0A+}=0A+=0A+static void =
__init ehci_dbgp_init_postirq(struct serial_port *port)=0A+{=0A+    struct =
ehci_dbgp *dbgp =3D port->uart;=0A+=0A+    if ( !dbgp->ehci_debug )=0A+    =
    return;=0A+=0A+    serial_async_transmit(port);=0A+=0A+    init_timer(&=
dbgp->timer, ehci_dbgp_poll, port, 0);=0A+=0A+    ehci_dbgp_setup_postirq(d=
bgp);=0A+}=0A+=0A+static int ehci_dbgp_check_release(struct ehci_dbgp =
*dbgp)=0A+{=0A+    struct ehci_dbg_port __iomem *ehci_debug =3D dbgp->ehci_=
debug;=0A+    u32 ctrl;=0A+    unsigned int i;=0A+=0A+    if ( !ehci_debug =
)=0A+        return 0;=0A+=0A+    for ( i =3D 0; i < DBGP_MAX_PACKET; ++i =
)=0A+        if ( dbgp->out.buf[i] )=0A+            return 1;=0A+=0A+    =
/*=0A+     * This means the console is not initialized, or should get =
shutdown=0A+     * so as to allow for reuse of the USB device, which means =
it is time=0A+     * to shutdown the USB debug port.=0A+     */=0A+    =
printk(XENLOG_INFO "Releasing EHCI debug port at %02x:%02x.%u\n",=0A+      =
     dbgp->bus, dbgp->slot, dbgp->func);=0A+=0A+    kill_timer(&dbgp->timer=
);=0A+    dbgp->ehci_debug =3D NULL;=0A+=0A+    ctrl =3D readl(&ehci_debug-=
>control);=0A+    if ( ctrl & DBGP_ENABLED )=0A+    {=0A+        ctrl &=3D =
~DBGP_CLAIM;=0A+        writel(ctrl, &ehci_debug->control);=0A+    =
}=0A+=0A+    return 0;=0A+}=0A+=0A+static void __init ehci_dbgp_endboot(str=
uct serial_port *port)=0A+{=0A+    ehci_dbgp_check_release(port->uart);=0A+=
}=0A+=0A+static void ehci_dbgp_suspend(struct serial_port *port)=0A+{=0A+  =
  struct ehci_dbgp *dbgp =3D port->uart;=0A+=0A+    if ( !dbgp->ehci_debug =
)=0A+        return;=0A+=0A+    stop_timer(&dbgp->timer);=0A+    dbgp->time=
r.expires =3D 0;=0A+=0A+    dbgp->pci_cr =3D pci_conf_read16(0, dbgp->bus, =
dbgp->slot, dbgp->func,=0A+                                   PCI_COMMAND);=
=0A+=0A+    dbgp->state =3D dbgp_unsafe;=0A+}=0A+=0A+static void ehci_dbgp_=
resume(struct serial_port *port)=0A+{=0A+    struct ehci_dbgp *dbgp =3D =
port->uart;=0A+=0A+    if ( !dbgp->ehci_debug )=0A+        return;=0A+=0A+ =
   pci_conf_write32(0, dbgp->bus, dbgp->slot, dbgp->func, dbgp->bar,=0A+   =
                  dbgp->bar_val);=0A+    pci_conf_write16(0, dbgp->bus, =
dbgp->slot, dbgp->func,=0A+                     PCI_COMMAND, dbgp->pci_cr);=
=0A+=0A+    ehci_dbgp_setup_preirq(dbgp);=0A+    ehci_dbgp_setup_postirq(db=
gp);=0A+}=0A+=0A+static struct uart_driver __read_mostly ehci_dbgp_driver =
=3D {=0A+    .init_preirq  =3D ehci_dbgp_init_preirq,=0A+    .init_postirq =
=3D ehci_dbgp_init_postirq,=0A+    .endboot      =3D ehci_dbgp_endboot,=0A+=
    .suspend      =3D ehci_dbgp_suspend,=0A+    .resume       =3D =
ehci_dbgp_resume,=0A+    .tx_empty     =3D ehci_dbgp_tx_empty,=0A+    =
.putc         =3D ehci_dbgp_putc,=0A+    .flush        =3D ehci_dbgp_flush,=
=0A+    .getc         =3D ehci_dbgp_getc=0A+};=0A+=0A+static struct =
ehci_dbgp ehci_dbgp =3D { .state =3D dbgp_unsafe, .phys_port =3D 1 =
};=0A+=0A+static char __initdata opt_dbgp[30];=0A+string_param("dbgp", =
opt_dbgp);=0A+=0A+void __init ehci_dbgp_init(void)=0A+{=0A+    struct =
ehci_dbgp *dbgp =3D &ehci_dbgp;=0A+    u32 debug_port, offset, bar_val;=0A+=
    const char *e;=0A+=0A+    if ( strncmp(opt_dbgp, "ehci", 4) )=0A+      =
  return;=0A+=0A+    if ( isdigit(opt_dbgp[4]) || !opt_dbgp[4] )=0A+    =
{=0A+        unsigned int num =3D 0;=0A+=0A+        if ( opt_dbgp[4] )=0A+ =
           simple_strtoul(opt_dbgp + 4, &e, 10);=0A+=0A+        dbgp->cap =
=3D find_dbgp(dbgp, num);=0A+        if ( !dbgp->cap )=0A+            =
return;=0A+=0A+        dbgp_printk("Found EHCI debug port on %02x:%02x.%u\n=
",=0A+                    dbgp->bus, dbgp->slot, dbgp->func);=0A+    }=0A+ =
   else if ( strncmp(opt_dbgp + 4, "@pci", 4) =3D=3D 0 )=0A+    {=0A+      =
  unsigned long val =3D simple_strtoul(opt_dbgp + 8, &e, 16);=0A+=0A+      =
  dbgp->bus =3D val;=0A+        if ( dbgp->bus !=3D val || *e !=3D ':' =
)=0A+            return;=0A+=0A+        val =3D simple_strtoul(e + 1, &e, =
16);=0A+        if ( PCI_SLOT(PCI_DEVFN(val, 0)) !=3D val || *e !=3D '.' =
)=0A+            return;=0A+        dbgp->slot =3D val;=0A+=0A+        val =
=3D simple_strtoul(e + 1, &e, 16);=0A+        if ( PCI_FUNC(PCI_DEVFN(0, =
val)) !=3D val || *e )=0A+            return;=0A+        dbgp->func =3D =
val;=0A+=0A+        if ( !pci_device_detect(0, dbgp->bus, dbgp->slot, =
dbgp->func) )=0A+            return;=0A+=0A+        dbgp->cap =3D =
__find_dbgp(dbgp->bus, dbgp->slot, dbgp->func);=0A+        if ( !dbgp->cap =
)=0A+            return;=0A+=0A+        dbgp_printk("Using EHCI debug port =
on %02x:%02x.%u\n",=0A+                    dbgp->bus, dbgp->slot, =
dbgp->func);=0A+    }=0A+    else=0A+        return;=0A+=0A+    debug_port =
=3D pci_conf_read32(0, dbgp->bus, dbgp->slot, dbgp->func,=0A+              =
                   dbgp->cap);=0A+    dbgp->bar =3D (debug_port >> 29) & =
0x7;=0A+    dbgp->bar =3D ((dbgp->bar - 1) * 4) + PCI_BASE_ADDRESS_0;=0A+  =
  offset =3D (debug_port >> 16) & 0xfff;=0A+    dbgp_printk("bar: %02x =
offset: %03x\n", dbgp->bar, offset);=0A+    if ( dbgp->bar < PCI_BASE_ADDRE=
SS_0 || dbgp->bar > PCI_BASE_ADDRESS_5 )=0A+    {=0A+        dbgp_printk("u=
nsupported/invalid bar\n");=0A+        return;=0A+    }=0A+=0A+    =
dbgp->bar_val =3D bar_val =3D pci_conf_read32(0, dbgp->bus, dbgp->slot,=0A+=
                                              dbgp->func, dbgp->bar);=0A+  =
  dbgp_printk("bar_val: %08x\n", bar_val);=0A+    if ( bar_val & ~PCI_BASE_=
ADDRESS_MEM_MASK )=0A+    {=0A+        dbgp_printk("only simple 32-bit =
MMIO BARs supported\n");=0A+        return;=0A+    }=0A+    bar_val &=3D =
PCI_BASE_ADDRESS_MEM_MASK;=0A+    if ( !bar_val || !(bar_val + (bar_val & =
-bar_val)) )=0A+    {=0A+        dbgp_printk("firmware initialization of =
MMIO BAR required\n");=0A+        return;=0A+    }=0A+=0A+    serial_regist=
er_uart(SERHND_DBGP, &ehci_dbgp_driver, dbgp);=0A+}=0A+=0A+int dbgp_op(cons=
t struct physdev_dbgp_op *op)=0A+{=0A+    if ( !ehci_dbgp.ehci_debug )=0A+ =
       return 0;=0A+=0A+    switch ( op->bus )=0A+    {=0A+    case =
PHYSDEVOP_DBGP_BUS_UNKNOWN:=0A+        break;=0A+    case PHYSDEVOP_DBGP_BU=
S_PCI:=0A+        if ( op->u.pci.seg || ehci_dbgp.bus !=3D op->u.pci.bus =
||=0A+            PCI_DEVFN(ehci_dbgp.slot, ehci_dbgp.func) !=3D op->u.pci.=
devfn )=0A+    default:=0A+            return 0;=0A+        break;=0A+    =
}=0A+=0A+    switch ( op->op )=0A+    {=0A+    case PHYSDEVOP_DBGP_RESET_PR=
EPARE:=0A+        spin_lock_irq(ehci_dbgp.lock);=0A+        ehci_dbgp.state=
 =3D dbgp_unsafe;=0A+        dbgp_wait_until_complete(&ehci_dbgp, =
NULL);=0A+        spin_unlock_irq(ehci_dbgp.lock);=0A+=0A+        return =
ehci_dbgp_check_release(&ehci_dbgp);=0A+=0A+    case PHYSDEVOP_DBGP_RESET_D=
ONE:=0A+        return ehci_dbgp_external_startup(&ehci_dbgp) ?: 1;=0A+    =
}=0A+=0A+    return -ENOSYS;=0A+}=0A--- a/xen/drivers/char/serial.c=0A+++ =
b/xen/drivers/char/serial.c=0A@@ -265,6 +265,14 @@ int __init serial_parse_=
handle(char *con=0A {=0A     int handle;=0A =0A+    if ( !strncmp(conf, =
"dbgp", 4) && (!conf[4] || conf[4] =3D=3D ',') )=0A+    {=0A+        if ( =
!com[SERHND_DBGP].driver )=0A+            goto fail;=0A+=0A+        return =
SERHND_DBGP | SERHND_COOKED;=0A+    }=0A+=0A     if ( strncmp(conf, "com", =
3) )=0A         goto fail;=0A =0A--- a/xen/include/asm-x86/fixmap.h=0A+++ =
b/xen/include/asm-x86/fixmap.h=0A@@ -36,7 +36,15 @@=0A  * from the end of =
virtual memory backwards.=0A  */=0A enum fixed_addresses {=0A-    =
FIX_RESERVED, /* Index 0 is reserved since fix_to_virt(0) > FIXADDR_TOP. =
*/=0A+    /* Index 0 is reserved since fix_to_virt(0) =3D=3D FIXADDR_TOP. =
*/=0A+    FIX_RESERVED,=0A+    /*=0A+     * Indexes using the page tables =
set up before entering __start_xen()=0A+     * must be among the first =
(L1_PAGETABLE_ENTRIES - 1) entries.=0A+     * These are generally those =
needed by the various console drivers.=0A+     */=0A+    FIX_EHCI_DBGP,=0A+=
    /* Everything else should go further down. */=0A #ifdef __i386__=0A    =
 FIX_PAE_HIGHMEM_0,=0A     FIX_PAE_HIGHMEM_END =3D FIX_PAE_HIGHMEM_0 + =
NR_CPUS-1,=0A--- a/xen/include/public/physdev.h=0A+++ b/xen/include/public/=
physdev.h=0A@@ -312,6 +312,24 @@ struct physdev_pci_device {=0A typedef =
struct physdev_pci_device physdev_pci_device_t;=0A DEFINE_XEN_GUEST_HANDLE(=
physdev_pci_device_t);=0A =0A+#define PHYSDEVOP_DBGP_RESET_PREPARE    =
1=0A+#define PHYSDEVOP_DBGP_RESET_DONE       2=0A+=0A+#define PHYSDEVOP_DBG=
P_BUS_UNKNOWN      0=0A+#define PHYSDEVOP_DBGP_BUS_PCI          1=0A+=0A+#d=
efine PHYSDEVOP_dbgp_op               29=0A+struct physdev_dbgp_op {=0A+   =
 /* IN */=0A+    uint8_t op;=0A+    uint8_t bus;=0A+    union {=0A+        =
struct physdev_pci_device pci;=0A+    } u;=0A+};=0A+typedef struct =
physdev_dbgp_op physdev_dbgp_op_t;=0A+DEFINE_XEN_GUEST_HANDLE(physdev_dbgp_=
op_t);=0A+=0A /*=0A  * Notify that some PIRQ-bound event channels have =
been unmasked.=0A  * ** This command is obsolete since interface version =
0x00030202 and is **=0A--- a/xen/include/xen/serial.h=0A+++ b/xen/include/x=
en/serial.h=0A@@ -69,9 +69,10 @@ struct uart_driver {=0A };=0A =0A /* =
'Serial handles' are composed from the following fields. */=0A-#define =
SERHND_IDX      (3<<0) /* COM1 or COM2?                           =
*/=0A+#define SERHND_IDX      (3<<0) /* COM1, COM2, or DBGP?               =
     */=0A # define SERHND_COM1    (0<<0)=0A # define SERHND_COM2    =
(1<<0)=0A+# define SERHND_DBGP    (2<<0)=0A #define SERHND_HI       (1<<2) =
/* Mux/demux each transferred char by MSB. */=0A #define SERHND_LO       =
(1<<3) /* Ditto, except that the MSB is cleared.  */=0A #define SERHND_COOK=
ED   (1<<4) /* Newline/carriage-return translation?    */=0A@@ -142,9 =
+143,13 @@ struct ns16550_defaults {=0A     unsigned long io_base; /* =
default io_base address */=0A };=0A void ns16550_init(int index, struct =
ns16550_defaults *defaults);=0A+void ehci_dbgp_init(void);=0A =0A void =
pl011_init(int index, unsigned long register_base_address);=0A =0A+struct =
physdev_dbgp_op;=0A+int dbgp_op(const struct physdev_dbgp_op *);=0A+=0A /* =
Baud rate was pre-configured before invoking the UART driver. */=0A =
#define BAUD_AUTO (-1)=0A =0A
--=__Part0736157F.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

--=__Part0736157F.0__=--


From xen-devel-bounces@lists.xen.org Tue Sep 11 10:16:37 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 2012 10: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 1TBNW1-0002oe-Vk; Tue, 11 Sep 2012 10:16:21 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1TBNVz-0002oU-V8
	for xen-devel@lists.xen.org; Tue, 11 Sep 2012 10:16:20 +0000
Received: from [85.158.139.83:53981] by server-6.bemta-5.messagelabs.com id
	20/D3-21336-37F0F405; Tue, 11 Sep 2012 10:16:19 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1347358578!25918303!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQwNzc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2013 invoked from network); 11 Sep 2012 10:16:18 -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;
	11 Sep 2012 10:16:18 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 11 Sep 2012 11:16:17 +0100
Message-Id: <504F2B8F020000780009A800@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 11 Sep 2012 11:16: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="=__Part0736157F.0__="
Subject: [Xen-devel] [PATCH RFC 3/8] console: add EHCI debug port based
 serial console
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<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.

--=__Part0736157F.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Low level hardware interface pieces adapted from Linux.

For setup information, see Linux'es Documentation/x86/earlyprintk.txt
and/or http://www.coreboot.org/EHCI_Debug_Port.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

--- a/docs/misc/xen-command-line.markdown
+++ b/docs/misc/xen-command-line.markdown
@@ -244,7 +244,7 @@ A typical setup for most situations migh
 Specify the size of the console ring buffer.
=20
 ### console
-> `=3D List of [ vga | com1[H,L] | com2[H,L] | none ]`
+> `=3D List of [ vga | com1[H,L] | com2[H,L] | dbgp | none ]`
=20
 > Default: `console=3Dcom1,vga`
=20
@@ -260,6 +260,8 @@ the converse; transmitted and received c
 cleared.  This allows a single port to be shared by two subsystems
 (e.g. console and debugger).
=20
+`dbgp` indicates that Xen should use a USB debug port.
+
 `none` indicates that Xen should not use a console.  This option only
 makes sense on its own.
=20
@@ -352,6 +354,12 @@ combination with the `low_crashinfo` com
 ### credit2\_load\_window\_shift
 > `=3D <integer>`
=20
+### dbgp
+> `=3D ehci[ <integer> | @pci<bus>:<slot>.<func> ]`
+
+Specify the USB controller to use, either by instance number (when going
+over the PCI busses sequentially) or by PCI device (must be on segment =
0).
+
 ### debug\_stack\_lines
 > `=3D <integer>`
=20
--- a/xen/arch/x86/Rules.mk
+++ b/xen/arch/x86/Rules.mk
@@ -7,6 +7,7 @@ HAS_CPUFREQ :=3D y
 HAS_PCI :=3D y
 HAS_PASSTHROUGH :=3D y
 HAS_NS16550 :=3D y
+HAS_EHCI :=3D y
 HAS_KEXEC :=3D y
 HAS_GDBSX :=3D y
 xenoprof :=3D y
--- a/xen/arch/x86/physdev.c
+++ b/xen/arch/x86/physdev.c
@@ -8,6 +8,7 @@
 #include <xen/event.h>
 #include <xen/guest_access.h>
 #include <xen/iocap.h>
+#include <xen/serial.h>
 #include <asm/current.h>
 #include <asm/io_apic.h>
 #include <asm/msi.h>
@@ -722,6 +723,19 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_H
=20
         break;
     }
+
+    case PHYSDEVOP_dbgp_op: {
+        struct physdev_dbgp_op op;
+
+        if ( !IS_PRIV(v->domain) )
+            ret =3D -EPERM;
+        else if ( copy_from_guest(&op, arg, 1) )
+            ret =3D -EFAULT;
+        else
+            ret =3D dbgp_op(&op);
+        break;
+    }
+
     default:
         ret =3D -ENOSYS;
         break;
--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@ -606,6 +606,7 @@ void __init __start_xen(unsigned long mb
     ns16550.io_base =3D 0x2f8;
     ns16550.irq     =3D 3;
     ns16550_init(1, &ns16550);
+    ehci_dbgp_init();
     console_init_preirq();
=20
     printk("Bootloader: %s\n", loader);
--- a/xen/drivers/char/Makefile
+++ b/xen/drivers/char/Makefile
@@ -1,4 +1,5 @@
 obj-y +=3D console.o
 obj-$(HAS_NS16550) +=3D ns16550.o
 obj-$(HAS_PL011) +=3D pl011.o
+obj-$(HAS_EHCI) +=3D ehci-dbgp.o
 obj-y +=3D serial.o
--- /dev/null
+++ b/xen/drivers/char/ehci-dbgp.c
@@ -0,0 +1,1577 @@
+/*
+ * Standalone EHCI USB debug driver
+ *
+ * Hardware interface code based on the respective early console driver =
in
+ * Linux; see the Linux source for authorship and copyrights.
+ */
+
+#include <xen/config.h>
+#include <xen/console.h>
+#include <xen/delay.h>
+#include <xen/errno.h>
+#include <xen/pci.h>
+#include <xen/serial.h>
+#include <asm/byteorder.h>
+#include <asm/io.h>
+#include <asm/fixmap.h>
+#include <public/physdev.h>
+
+/* #define DBGP_DEBUG */
+
+/* EHCI register interface, corresponds to EHCI Revision 0.95 specificatio=
n */
+
+/* Section 2.2 Host Controller Capability Registers */
+struct ehci_caps {
+    /*
+     * These fields are specified as 8 and 16 bit registers,
+     * but some hosts can't perform 8 or 16 bit PCI accesses.
+     * some hosts treat caplength and hciversion as parts of a 32-bit
+     * register, others treat them as two separate registers, this
+     * affects the memory map for big endian controllers.
+     */
+    u32 hc_capbase;
+#define HC_LENGTH(p)      (0x00ff & (p)) /* bits 7:0 / offset 0x00 */
+#define HC_VERSION(p)     (0xffff & ((p) >> 16)) /* bits 31:16 / offset =
0x02 */
+
+    u32 hcs_params;       /* HCSPARAMS - offset 0x04 */
+#define HCS_DEBUG_PORT(p) (((p) >> 20) & 0xf) /* bits 23:20, debug port? =
*/
+#define HCS_INDICATOR(p)  ((p) & (1 << 16))   /* true: has port indicators=
 */
+#define HCS_N_CC(p)       (((p) >> 12) & 0xf) /* bits 15:12, #companion =
HCs */
+#define HCS_N_PCC(p)      (((p) >> 8) & 0xf)  /* bits 11:8, ports per CC =
*/
+#define HCS_PORTROUTED(p) ((p) & (1 << 7))    /* true: port routing */
+#define HCS_PPC(p)        ((p) & (1 << 4))    /* true: port power control =
*/
+#define HCS_N_PORTS(p)    (((p) >> 0) & 0xf)  /* bits 3:0, ports on HC */
+
+    u32 hcc_params;       /* HCCPARAMS - offset 0x08 */
+/* EHCI 1.1 addendum */
+#define HCC_32FRAME_PERIODIC_LIST(p) ((p) & (1 << 19))
+#define HCC_PER_PORT_CHANGE_EVENT(p) ((p) & (1 << 18))
+#define HCC_LPM(p)        ((p) & (1 << 17))
+#define HCC_HW_PREFETCH(p) ((p) & (1 << 16))
+#define HCC_EXT_CAPS(p)   (((p) >> 8) & 0xff) /* for pci extended caps */
+#define HCC_ISOC_CACHE(p) ((p) & (1 << 7))    /* true: can cache isoc =
frame */
+#define HCC_ISOC_THRES(p) (((p) >> 4) & 0x7)  /* bits 6:4, uframes cached =
*/
+#define HCC_CANPARK(p)    ((p) & (1 << 2))    /* true: can park on async =
qh */
+#define HCC_PGM_FRAMELISTLEN(p) ((p) & (1 << 1)) /* true: periodic_size =
changes */
+#define HCC_64BIT_ADDR(p) ((p) & 1)           /* true: can use 64-bit =
addr */
+
+    u8  portroute[8];     /* nibbles for routing - offset 0x0C */
+};
+
+/* Section 2.3 Host Controller Operational Registers */
+struct ehci_regs {
+    /* USBCMD: offset 0x00 */
+    u32 command;
+
+/* EHCI 1.1 addendum */
+#define CMD_HIRD        (0xf << 24) /* host initiated resume duration */
+#define CMD_PPCEE       (1 << 15)   /* per port change event enable */
+#define CMD_FSP         (1 << 14)   /* fully synchronized prefetch */
+#define CMD_ASPE        (1 << 13)   /* async schedule prefetch enable */
+#define CMD_PSPE        (1 << 12)   /* periodic schedule prefetch enable =
*/
+/* 23:16 is r/w intr rate, in microframes; default "8" =3D=3D 1/msec */
+#define CMD_PARK        (1 << 11)   /* enable "park" on async qh */
+#define CMD_PARK_CNT(c) (((c) >> 8) & 3) /* how many transfers to park =
for */
+#define CMD_LRESET      (1 << 7)    /* partial reset (no ports, etc) */
+#define CMD_IAAD        (1 << 6)    /* "doorbell" interrupt async advance =
*/
+#define CMD_ASE         (1 << 5)    /* async schedule enable */
+#define CMD_PSE         (1 << 4)    /* periodic schedule enable */
+/* 3:2 is periodic frame list size */
+#define CMD_RESET       (1 << 1)    /* reset HC not bus */
+#define CMD_RUN         (1 << 0)    /* start/stop HC */
+
+    /* USBSTS: offset 0x04 */
+    u32 status;
+#define STS_PPCE_MASK   (0xff << 16) /* Per-Port change event 1-16 */
+#define STS_ASS         (1 << 15)   /* Async Schedule Status */
+#define STS_PSS         (1 << 14)   /* Periodic Schedule Status */
+#define STS_RECL        (1 << 13)   /* Reclamation */
+#define STS_HALT        (1 << 12)   /* Not running (any reason) */
+/* some bits reserved */
+    /* these STS_* flags are also intr_enable bits (USBINTR) */
+#define STS_IAA         (1 << 5)    /* Interrupted on async advance */
+#define STS_FATAL       (1 << 4)    /* such as some PCI access errors */
+#define STS_FLR         (1 << 3)    /* frame list rolled over */
+#define STS_PCD         (1 << 2)    /* port change detect */
+#define STS_ERR         (1 << 1)    /* "error" completion (overflow, ...) =
*/
+#define STS_INT         (1 << 0)    /* "normal" completion (short, ...) =
*/
+
+    /* USBINTR: offset 0x08 */
+    u32 intr_enable;
+
+    /* FRINDEX: offset 0x0C */
+    u32 frame_index;    /* current microframe number */
+    /* CTRLDSSEGMENT: offset 0x10 */
+    u32 segment;    /* address bits 63:32 if needed */
+    /* PERIODICLISTBASE: offset 0x14 */
+    u32 frame_list;    /* points to periodic list */
+    /* ASYNCLISTADDR: offset 0x18 */
+    u32 async_next;    /* address of next async queue head */
+
+    u32 reserved[9];
+
+    /* CONFIGFLAG: offset 0x40 */
+    u32 configured_flag;
+#define FLAG_CF         (1 << 0)    /* true: we'll support "high speed" =
*/
+
+    /* PORTSC: offset 0x44 */
+    u32 port_status[0];    /* up to N_PORTS */
+/* EHCI 1.1 addendum */
+#define PORTSC_SUSPEND_STS_ACK   0
+#define PORTSC_SUSPEND_STS_NYET  1
+#define PORTSC_SUSPEND_STS_STALL 2
+#define PORTSC_SUSPEND_STS_ERR   3
+
+#define PORT_DEV_ADDR   (0x7f << 25) /* device address */
+#define PORT_SSTS       (0x3 << 23)  /* suspend status */
+/* 31:23 reserved */
+#define PORT_WKOC_E     (1 << 22)    /* wake on overcurrent (enable) */
+#define PORT_WKDISC_E   (1 << 21)    /* wake on disconnect (enable) */
+#define PORT_WKCONN_E   (1 << 20)    /* wake on connect (enable) */
+/* 19:16 for port testing */
+#define PORT_TEST(x)    (((x) & 0xf) << 16) /* Port Test Control */
+#define PORT_TEST_PKT   PORT_TEST(0x4) /* Port Test Control - packet test =
*/
+#define PORT_TEST_FORCE PORT_TEST(0x5) /* Port Test Control - force =
enable */
+#define PORT_LED_OFF    (0 << 14)
+#define PORT_LED_AMBER  (1 << 14)
+#define PORT_LED_GREEN  (2 << 14)
+#define PORT_LED_MASK   (3 << 14)
+#define PORT_OWNER      (1 << 13)    /* true: companion hc owns this port =
*/
+#define PORT_POWER      (1 << 12)    /* true: has power (see PPC) */
+#define PORT_USB11(x)   (((x) & (3 << 10)) =3D=3D (1 << 10)) /* USB 1.1 =
device */
+/* 11:10 for detecting lowspeed devices (reset vs release ownership) */
+/* 9 reserved */
+#define PORT_LPM        (1 << 9)     /* LPM transaction */
+#define PORT_RESET      (1 << 8)     /* reset port */
+#define PORT_SUSPEND    (1 << 7)     /* suspend port */
+#define PORT_RESUME     (1 << 6)     /* resume it */
+#define PORT_OCC        (1 << 5)     /* over current change */
+#define PORT_OC         (1 << 4)     /* over current active */
+#define PORT_PEC        (1 << 3)     /* port enable change */
+#define PORT_PE         (1 << 2)     /* port enable */
+#define PORT_CSC        (1 << 1)     /* connect status change */
+#define PORT_CONNECT    (1 << 0)     /* device connected */
+#define PORT_RWC_BITS   (PORT_CSC | PORT_PEC | PORT_OCC)
+};
+
+/*
+ * Appendix C, Debug port ... intended for use with special "debug =
devices"
+ * that can help if there's no serial console.  (nonstandard enumeration.)=

+ */
+struct ehci_dbg_port {
+    u32 control;
+#define DBGP_OWNER      (1 << 30)
+#define DBGP_ENABLED    (1 << 28)
+#define DBGP_DONE       (1 << 16)
+#define DBGP_INUSE      (1 << 10)
+#define DBGP_ERRCODE(x) (((x) >> 7) & 0x07)
+# define DBGP_ERR_BAD    1
+# define DBGP_ERR_SIGNAL 2
+#define DBGP_ERROR      (1 << 6)
+#define DBGP_GO         (1 << 5)
+#define DBGP_OUT        (1 << 4)
+#define DBGP_LEN        (0xf << 0)
+#define DBGP_CLAIM      (DBGP_OWNER | DBGP_ENABLED | DBGP_INUSE)
+    u32 pids;
+#define DBGP_PID_GET(x)         (((x) >> 16) & 0xff)
+#define DBGP_PID_SET(data, tok) (((data) << 8) | (tok))
+    u32 data03;
+    u32 data47;
+    u32 address;
+#define DBGP_EPADDR(dev, ep) (((dev) << 8) | (ep))
+};
+
+/* CONTROL REQUEST SUPPORT */
+
+/*
+ * USB directions
+ *
+ * This bit flag is used in endpoint descriptors' bEndpointAddress field.
+ * It's also one of three fields in control requests bRequestType.
+ */
+#define USB_DIR_OUT 0           /* to device */
+#define USB_DIR_IN  0x80        /* to host */
+
+/*
+ * USB types, the second of three bRequestType fields
+ */
+#define USB_TYPE_MASK     (0x03 << 5)
+#define USB_TYPE_STANDARD (0x00 << 5)
+#define USB_TYPE_CLASS    (0x01 << 5)
+#define USB_TYPE_VENDOR   (0x02 << 5)
+#define USB_TYPE_RESERVED (0x03 << 5)
+
+/*
+ * USB recipients, the third of three bRequestType fields
+ */
+#define USB_RECIP_MASK      0x1f
+#define USB_RECIP_DEVICE    0x00
+#define USB_RECIP_INTERFACE 0x01
+#define USB_RECIP_ENDPOINT  0x02
+#define USB_RECIP_OTHER     0x03
+/* From Wireless USB 1.0 */
+#define USB_RECIP_PORT      0x04
+#define USB_RECIP_RPIPE     0x05
+
+/*
+ * Standard requests, for the bRequest field of a SETUP packet.
+ *
+ * These are qualified by the bRequestType field, so that for example
+ * TYPE_CLASS or TYPE_VENDOR specific feature flags could be retrieved
+ * by a GET_STATUS request.
+ */
+#define USB_REQ_GET_STATUS        0x00
+#define USB_REQ_CLEAR_FEATURE     0x01
+#define USB_REQ_SET_FEATURE       0x03
+#define USB_REQ_SET_ADDRESS       0x05
+#define USB_REQ_GET_DESCRIPTOR    0x06
+#define USB_REQ_SET_DESCRIPTOR    0x07
+#define USB_REQ_GET_CONFIGURATION 0x08
+#define USB_REQ_SET_CONFIGURATION 0x09
+#define USB_REQ_GET_INTERFACE     0x0A
+#define USB_REQ_SET_INTERFACE     0x0B
+#define USB_REQ_SYNCH_FRAME       0x0C
+
+#define USB_DEVICE_DEBUG_MODE        6    /* (special devices only) */
+
+/**
+ * struct usb_ctrlrequest - SETUP data for a USB device control request
+ * @bRequestType: matches the USB bmRequestType field
+ * @bRequest: matches the USB bRequest field
+ * @wValue: matches the USB wValue field (le16 byte order)
+ * @wIndex: matches the USB wIndex field (le16 byte order)
+ * @wLength: matches the USB wLength field (le16 byte order)
+ *
+ * This structure is used to send control requests to a USB device.  It =
matches
+ * the different fields of the USB 2.0 Spec section 9.3, table 9-2.  See =
the
+ * USB spec for a fuller description of the different fields, and what =
they are
+ * used for.
+ *
+ * Note that the driver for any interface can issue control requests.
+ * For most devices, interfaces don't coordinate with each other, so
+ * such requests may be made at any time.
+ */
+struct usb_ctrlrequest {
+    u8 bRequestType;
+    u8 bRequest;
+    __le16 wValue;
+    __le16 wIndex;
+    __le16 wLength;
+} __attribute__ ((packed));
+
+/* USB_DT_DEBUG: for special highspeed devices, replacing serial console =
*/
+
+#define USB_DT_DEBUG    0x0a
+
+struct usb_debug_descriptor {
+    u8 bLength;
+    u8 bDescriptorType;
+    /* bulk endpoints with 8 byte maxpacket */
+    u8 bDebugInEndpoint;
+    u8 bDebugOutEndpoint;
+} __attribute__((packed));
+
+#define USB_DEBUG_DEVNUM 127
+
+/*
+ * USB Packet IDs (PIDs)
+ */
+
+/* token */
+#define USB_PID_OUT           0xe1
+#define USB_PID_IN            0x69
+#define USB_PID_SOF           0xa5
+#define USB_PID_SETUP         0x2d
+/* handshake */
+#define USB_PID_ACK           0xd2
+#define USB_PID_NAK           0x5a
+#define USB_PID_STALL         0x1e
+#define USB_PID_NYET          0x96
+/* data */
+#define USB_PID_DATA0         0xc3
+#define USB_PID_DATA1         0x4b
+#define USB_PID_DATA2         0x87
+#define USB_PID_MDATA         0x0f
+/* Special */
+#define USB_PID_PREAMBLE      0x3c
+#define USB_PID_ERR           0x3c
+#define USB_PID_SPLIT         0x78
+#define USB_PID_PING          0xb4
+#define USB_PID_UNDEF_0       0xf0
+
+#define PCI_CLASS_SERIAL_USB_EHCI 0x0c0320
+#define PCI_CAP_ID_EHCI_DEBUG     0x0a
+
+#define HUB_ROOT_RESET_TIME   50    /* times are in msec */
+#define HUB_SHORT_RESET_TIME  10
+#define HUB_LONG_RESET_TIME   200
+#define HUB_RESET_TIMEOUT     500
+
+#define DBGP_MAX_PACKET       8
+#define DBGP_LOOPS            1000
+#define DBGP_TIMEOUT          (250 * 1000) /* us */
+#define DBGP_CHECK_INTERVAL   100 /* us */
+/* This one can be set arbitrarily - only affects input responsiveness: =
*/
+#define DBGP_IDLE_INTERVAL    100 /* ms */
+
+struct ehci_dbgp {
+    struct ehci_dbg_port __iomem *ehci_debug;
+    enum dbgp_state {
+        dbgp_idle,
+        dbgp_out,
+        dbgp_in,
+        dbgp_ctrl,
+        dbgp_unsafe /* cannot use debug device during EHCI reset */
+    } state;
+    unsigned int phys_port;
+    struct {
+        unsigned int endpoint;
+        unsigned int chunk;
+        char buf[DBGP_MAX_PACKET];
+    } out, in;
+    unsigned long timeout;
+    struct timer timer;
+    spinlock_t *lock;
+    bool_t reset_run;
+    u8 bus, slot, func, bar;
+    u16 pci_cr;
+    u32 bar_val;
+    unsigned int cap;
+    struct ehci_regs __iomem *ehci_regs;
+    struct ehci_caps __iomem *ehci_caps;
+};
+
+static int ehci_dbgp_external_startup(struct ehci_dbgp *);
+
+static void ehci_dbgp_status(struct ehci_dbgp *dbgp, const char *str)
+{
+#ifdef DBGP_DEBUG
+#define dbgp_printk printk
+    if ( !dbgp->ehci_debug )
+        return;
+    dbgp_printk("dbgp: %s\n", str);
+    dbgp_printk("  debug control: %08x\n", readl(&dbgp->ehci_debug->contro=
l));
+    dbgp_printk("  EHCI cmd     : %08x\n", readl(&dbgp->ehci_regs->command=
));
+    dbgp_printk("  EHCI conf flg: %08x\n",
+                readl(&dbgp->ehci_regs->configured_flag));
+    dbgp_printk("  EHCI status  : %08x\n", readl(&dbgp->ehci_regs->status)=
);
+    dbgp_printk("  EHCI portsc  : %08x\n",
+                readl(&dbgp->ehci_regs->port_status[dbgp->phys_port - =
1]));
+#endif
+}
+
+#ifndef DBGP_DEBUG
+static inline __attribute__ ((format (printf, 1, 2))) void
+dbgp_printk(const char *fmt, ...) { }
+#endif
+
+static inline u32 dbgp_len_update(u32 x, u32 len)
+{
+    return (x & ~DBGP_LEN) | (len & DBGP_LEN) | DBGP_OUT;
+}
+
+static inline u32 dbgp_pid_write_update(u32 x, u32 tok)
+{
+    static u8 data0 =3D USB_PID_DATA1;
+
+    data0 ^=3D USB_PID_DATA0 ^ USB_PID_DATA1;
+    return (x & 0xffff0000) | (data0 << 8) | (tok & 0xff);
+}
+
+static inline u32 dbgp_pid_read_update(u32 x, u32 tok)
+{
+    return (x & 0xffffff00) | (tok & 0xff);
+}
+
+static inline void dbgp_set_data(struct ehci_dbg_port __iomem *ehci_debug,=

+                                 const void *buf, unsigned int size)
+{
+    const unsigned char *bytes =3D buf;
+    u32 lo =3D 0, hi =3D 0;
+    unsigned int i;
+
+    for ( i =3D 0; i < 4 && i < size; i++ )
+        lo |=3D bytes[i] << (8 * i);
+    for ( ; i < 8 && i < size; i++ )
+        hi |=3D bytes[i] << (8 * (i - 4));
+    writel(lo, &ehci_debug->data03);
+    writel(hi, &ehci_debug->data47);
+}
+
+static inline void dbgp_get_data(struct ehci_dbg_port __iomem *ehci_debug,=

+                                 void *buf, int size)
+{
+    unsigned char *bytes =3D buf;
+    u32 lo =3D readl(&ehci_debug->data03);
+    u32 hi =3D readl(&ehci_debug->data47);
+    unsigned int i;
+
+    for ( i =3D 0; i < 4 && i < size; i++ )
+        bytes[i] =3D (lo >> (8 * i)) & 0xff;
+    for ( ; i < 8 && i < size; i++ )
+        bytes[i] =3D (hi >> (8 * (i - 4))) & 0xff;
+}
+
+static void dbgp_issue_command(struct ehci_dbgp *dbgp, u32 ctrl,
+                               enum dbgp_state state)
+{
+    u32 cmd =3D readl(&dbgp->ehci_regs->command);
+
+    if ( unlikely(!(cmd & CMD_RUN)) )
+    {
+        /*
+         * If the EHCI controller is not in the run state do extended
+         * checks to see if ACPI or some other initialization also
+         * reset the EHCI debug port.
+         */
+        u32 ctrl =3D readl(&dbgp->ehci_debug->control);
+
+        if ( ctrl & DBGP_ENABLED )
+        {
+            cmd |=3D CMD_RUN;
+            writel(cmd, &dbgp->ehci_regs->command);
+            dbgp->reset_run =3D 1;
+        }
+        else if ( dbgp->state !=3D dbgp_unsafe )
+        {
+            dbgp->state =3D dbgp_unsafe;
+            ehci_dbgp_external_startup(dbgp);
+        }
+    }
+
+    writel(ctrl | DBGP_GO, &dbgp->ehci_debug->control);
+    dbgp->timeout =3D DBGP_TIMEOUT;
+    if ( dbgp->state !=3D dbgp_unsafe )
+        dbgp->state =3D state;
+}
+
+static int dbgp_check_for_completion(struct ehci_dbgp *dbgp,
+                                     unsigned int interval, u8 *ppid)
+{
+    u32 ctrl;
+    int ret;
+
+    if ( dbgp->state =3D=3D dbgp_idle )
+        return 0;
+
+    ctrl =3D readl(&dbgp->ehci_debug->control) & ~DBGP_GO;
+    if ( !(ctrl & DBGP_DONE) )
+    {
+        if ( dbgp->timeout > interval )
+            dbgp->timeout -=3D interval;
+        else if ( interval )
+        {
+            /* See the timeout related comment in dbgp_wait_until_done(). =
*/
+            dbgp->state =3D dbgp_unsafe;
+            dbgp->timeout =3D 0;
+        }
+        return -DBGP_TIMEOUT;
+    }
+
+    if ( ctrl & DBGP_ERROR )
+    {
+        ret =3D -DBGP_ERRCODE(ctrl);
+        if ( ret =3D=3D -DBGP_ERR_BAD && dbgp->timeout > interval )
+            ctrl |=3D DBGP_GO;
+    }
+    else
+    {
+        u8 pid =3D DBGP_PID_GET(readl(&dbgp->ehci_debug->pids));
+
+        ret =3D ctrl & DBGP_LEN;
+        if ( ppid )
+            *ppid =3D pid;
+        else if ( dbgp->state =3D=3D dbgp_in )
+        {
+            dbgp_get_data(dbgp->ehci_debug, dbgp->in.buf, ret);
+            dbgp->in.chunk =3D ret;
+        }
+        else if ( pid =3D=3D USB_PID_NAK && dbgp->timeout > interval )
+            ctrl |=3D DBGP_GO;
+    }
+
+    writel(ctrl, &dbgp->ehci_debug->control);
+    if ( ctrl & DBGP_GO )
+    {
+        dbgp->timeout -=3D interval;
+        return -DBGP_TIMEOUT;
+    }
+
+    if ( unlikely(dbgp->reset_run) )
+    {
+        writel(readl(&dbgp->ehci_regs->command) & ~CMD_RUN,
+               &dbgp->ehci_regs->command);
+        dbgp->reset_run =3D 0;
+    }
+
+    if ( dbgp->state !=3D dbgp_unsafe )
+        dbgp->state =3D dbgp_idle;
+
+    return ret;
+}
+
+static int dbgp_wait_until_complete(struct ehci_dbgp *dbgp, u8 *ppid)
+{
+    unsigned int loop =3D DBGP_TIMEOUT;
+    int ret;
+
+    do {
+        ret =3D dbgp_check_for_completion(dbgp, 0, ppid);
+        if ( ret !=3D -DBGP_TIMEOUT )
+            break;
+        udelay(1);
+    } while ( --loop );
+
+    if ( !ppid && !loop )
+        dbgp->state =3D dbgp_unsafe;
+
+    return ret;
+}
+
+static inline void dbgp_mdelay(unsigned int ms)
+{
+    while ( ms-- )
+    {
+        unsigned int i;
+
+        for ( i =3D 0; i < 1000; i++ )
+            outb(0x1, 0x80);
+    }
+}
+
+static void dbgp_breathe(void)
+{
+    /* Sleep to give the debug port a chance to breathe. */
+    dbgp_mdelay(1);
+}
+
+static int dbgp_wait_until_done(struct ehci_dbgp *dbgp, u32 ctrl,
+                                unsigned int loop)
+{
+    int ret;
+
+    dbgp->timeout =3D 0;
+
+    for ( ; ; writel(ctrl | DBGP_GO, &dbgp->ehci_debug->control) )
+    {
+        u8 pid;
+
+        ret =3D dbgp_wait_until_complete(dbgp, &pid);
+        if ( ret < 0 )
+        {
+            /*
+             * A -DBGP_TIMEOUT failure here means the device has failed,
+             * perhaps because it was unplugged, in which case we do not
+             * want to hang the system so the dbgp will be marked as =
unsafe
+             * to use. EHCI reset is the only way to recover if you =
unplug
+             * the dbgp device.
+             */
+            if ( ret =3D=3D -DBGP_TIMEOUT )
+                dbgp->state =3D dbgp_unsafe;
+            if ( ret !=3D -DBGP_ERR_BAD || !--loop )
+                break;
+        }
+        else
+        {
+            /*
+             * If the port is getting full or it has dropped data
+             * start pacing ourselves, not necessary but it's friendly.
+             */
+            if ( pid =3D=3D USB_PID_NAK || pid =3D=3D USB_PID_NYET )
+                dbgp_breathe();
+
+            /* If we got a NACK, reissue the transmission. */
+            if ( pid !=3D USB_PID_NAK || !--loop )
+                break;
+        }
+    }
+
+    return ret;
+}
+
+static int dbgp_bulk_write(struct ehci_dbgp *dbgp,
+                           unsigned int devnum, unsigned int endpoint,
+                           const void *bytes, unsigned int size, u32 =
*pctrl)
+{
+    u32 addr, pids, ctrl;
+
+    if ( size > DBGP_MAX_PACKET )
+        return -EINVAL;
+
+    addr =3D DBGP_EPADDR(devnum, endpoint);
+    pids =3D dbgp_pid_write_update(readl(&dbgp->ehci_debug->pids), =
USB_PID_OUT);
+    ctrl =3D dbgp_len_update(readl(&dbgp->ehci_debug->control), size);
+    if ( pctrl )
+        *pctrl =3D ctrl;
+
+    dbgp_set_data(dbgp->ehci_debug, bytes, size);
+    writel(addr, &dbgp->ehci_debug->address);
+    writel(pids, &dbgp->ehci_debug->pids);
+    dbgp_issue_command(dbgp, ctrl, dbgp_out);
+
+    return 0;
+}
+
+static int dbgp_bulk_read(struct ehci_dbgp *dbgp,
+                          unsigned int devnum, unsigned int endpoint,
+                          unsigned int size, u32 *pctrl)
+{
+    u32 addr, pids, ctrl;
+
+    if ( size > DBGP_MAX_PACKET )
+        return -EINVAL;
+
+    addr =3D DBGP_EPADDR(devnum, endpoint);
+    pids =3D dbgp_pid_read_update(readl(&dbgp->ehci_debug->pids), =
USB_PID_IN);
+    ctrl =3D readl(&dbgp->ehci_debug->control) & ~DBGP_OUT;
+
+    writel(addr, &dbgp->ehci_debug->address);
+    writel(pids, &dbgp->ehci_debug->pids);
+    if ( likely(!pctrl) )
+        dbgp_issue_command(dbgp, ctrl, dbgp_in);
+    else
+        dbgp_issue_command(dbgp, *pctrl =3D ctrl, dbgp_ctrl);
+
+    return 0;
+}
+
+static int dbgp_control_msg(struct ehci_dbgp *dbgp, unsigned int devnum,
+                            int requesttype, int request, int value,
+                            int index, void *data, unsigned int size)
+{
+    u32 addr, pids, ctrl;
+    struct usb_ctrlrequest req;
+    bool_t read =3D (requesttype & USB_DIR_IN) !=3D 0;
+    int ret;
+
+    if ( size > (read ? DBGP_MAX_PACKET : 0) )
+        return -EINVAL;
+
+    /* Compute the control message */
+    req.bRequestType =3D requesttype;
+    req.bRequest =3D request;
+    req.wValue =3D cpu_to_le16(value);
+    req.wIndex =3D cpu_to_le16(index);
+    req.wLength =3D cpu_to_le16(size);
+
+    pids =3D DBGP_PID_SET(USB_PID_DATA0, USB_PID_SETUP);
+    addr =3D DBGP_EPADDR(devnum, 0);
+    ctrl =3D dbgp_len_update(readl(&dbgp->ehci_debug->control), sizeof(req=
));
+
+    /* Send the setup message */
+    dbgp_set_data(dbgp->ehci_debug, &req, sizeof(req));
+    writel(addr, &dbgp->ehci_debug->address);
+    writel(pids, &dbgp->ehci_debug->pids);
+    dbgp_issue_command(dbgp, ctrl, dbgp_ctrl);
+    ret =3D dbgp_wait_until_done(dbgp, ctrl, DBGP_LOOPS);
+    if ( ret < 0 )
+        return ret;
+
+    /* Read the result */
+    ret =3D dbgp_bulk_read(dbgp, devnum, 0, size, &ctrl);
+    if ( !ret )
+        ret =3D dbgp_wait_until_done(dbgp, ctrl, DBGP_LOOPS);
+    if ( ret > 0 )
+    {
+        if ( size > ret )
+            size =3D ret;
+        dbgp_get_data(dbgp->ehci_debug, data, size);
+    }
+
+    return ret;
+}
+
+static unsigned int __init __find_dbgp(u8 bus, u8 slot, u8 func)
+{
+    u32 class =3D pci_conf_read32(0, bus, slot, func, PCI_CLASS_REVISION);=

+
+    if ( (class >> 8) !=3D PCI_CLASS_SERIAL_USB_EHCI )
+        return 0;
+
+    return pci_find_cap_offset(0, bus, slot, func, PCI_CAP_ID_EHCI_DEBUG);=

+}
+
+static unsigned int __init find_dbgp(struct ehci_dbgp *dbgp,
+                                     unsigned int ehci_num)
+{
+    unsigned int bus, slot, func;
+
+    for ( bus =3D 0; bus < 256; bus++ )
+    {
+        for ( slot =3D 0; slot < 32; slot++ )
+        {
+            for ( func =3D 0; func < 8; func++ )
+            {
+                unsigned int cap;
+
+                if ( !pci_device_detect(0, bus, slot, func) )
+                {
+                    if ( !func )
+                        break;
+                    continue;
+                }
+
+                cap =3D __find_dbgp(bus, slot, func);
+                if ( !cap || ehci_num-- )
+                {
+                    if ( !func && !(pci_conf_read8(0, bus, slot, func,
+                                                   PCI_HEADER_TYPE) & =
0x80) )
+                        break;
+                    continue;
+                }
+
+                dbgp->bus =3D bus;
+                dbgp->slot =3D slot;
+                dbgp->func =3D func;
+                return cap;
+            }
+        }
+    }
+
+    return 0;
+}
+
+static int ehci_dbgp_startup(struct ehci_dbgp *dbgp)
+{
+    u32 ctrl, cmd, status;
+    unsigned int loop;
+
+    /* Claim ownership, but do not enable yet */
+    ctrl =3D readl(&dbgp->ehci_debug->control);
+    ctrl |=3D DBGP_OWNER;
+    ctrl &=3D ~(DBGP_ENABLED | DBGP_INUSE);
+    writel(ctrl, &dbgp->ehci_debug->control);
+    udelay(1);
+
+    ehci_dbgp_status(dbgp, "EHCI startup");
+    /* Start the EHCI. */
+    cmd =3D readl(&dbgp->ehci_regs->command);
+    cmd &=3D ~(CMD_LRESET | CMD_IAAD | CMD_PSE | CMD_ASE | CMD_RESET);
+    cmd |=3D CMD_RUN;
+    writel(cmd, &dbgp->ehci_regs->command);
+
+    /* Ensure everything is routed to the EHCI */
+    writel(FLAG_CF, &dbgp->ehci_regs->configured_flag);
+
+    /* Wait until the controller is no longer halted. */
+    loop =3D 1000;
+    do {
+        status =3D readl(&dbgp->ehci_regs->status);
+        if ( !(status & STS_HALT) )
+            break;
+        udelay(1);
+    } while ( --loop );
+
+    if ( !loop )
+    {
+        dbgp_printk("EHCI cannot be started\n");
+        return -ENODEV;
+    }
+    dbgp_printk("EHCI started\n");
+
+    return 0;
+}
+
+static int ehci_dbgp_controller_reset(struct ehci_dbgp *dbgp)
+{
+    unsigned int loop =3D 250 * 1000;
+    u32 cmd;
+
+    /* Reset the EHCI controller */
+    cmd =3D readl(&dbgp->ehci_regs->command);
+    cmd |=3D CMD_RESET;
+    writel(cmd, &dbgp->ehci_regs->command);
+    do {
+        cmd =3D readl(&dbgp->ehci_regs->command);
+    } while ( (cmd & CMD_RESET) && --loop );
+
+    if ( !loop )
+    {
+        dbgp_printk("cannot reset EHCI\n");
+        return -1;
+    }
+    ehci_dbgp_status(dbgp, "ehci reset done");
+
+    return 0;
+}
+
+static int ehci_reset_port(struct ehci_dbgp *dbgp, unsigned int port)
+{
+    u32 portsc, delay_time, delay;
+
+    ehci_dbgp_status(dbgp, "reset port");
+    /* Reset the USB debug port. */
+    portsc =3D readl(&dbgp->ehci_regs->port_status[port - 1]);
+    portsc &=3D ~PORT_PE;
+    portsc |=3D PORT_RESET;
+    writel(portsc, &dbgp->ehci_regs->port_status[port - 1]);
+
+    delay =3D HUB_ROOT_RESET_TIME;
+    for ( delay_time =3D 0; delay_time < HUB_RESET_TIMEOUT;
+          delay_time +=3D delay )
+    {
+        dbgp_mdelay(delay);
+        portsc =3D readl(&dbgp->ehci_regs->port_status[port - 1]);
+        if (!(portsc & PORT_RESET))
+            break;
+    }
+
+    if ( portsc & PORT_RESET )
+    {
+        /* force reset to complete */
+        unsigned int loop =3D 100 * 1000;
+
+        writel(portsc & ~(PORT_RWC_BITS | PORT_RESET),
+               &dbgp->ehci_regs->port_status[port - 1]);
+        do {
+            udelay(1);
+            portsc =3D readl(&dbgp->ehci_regs->port_status[port-1]);
+        } while ( (portsc & PORT_RESET) && --loop );
+    }
+
+    /* Device went away? */
+    if ( !(portsc & PORT_CONNECT) )
+        return -ENOTCONN;
+
+    /* bomb out completely if something weird happened */
+    if ( portsc & PORT_CSC )
+        return -EINVAL;
+
+    /* If we've finished resetting, then break out of the loop */
+    if ( !(portsc & PORT_RESET) && (portsc & PORT_PE) )
+        return 0;
+
+    return -EBUSY;
+}
+
+static int ehci_wait_for_port(struct ehci_dbgp *dbgp, unsigned int port)
+{
+    u32 status;
+    unsigned int reps;
+
+    for ( reps =3D 0; reps < 300; reps++ )
+    {
+        status =3D readl(&dbgp->ehci_regs->status);
+        if ( status & STS_PCD )
+            break;
+        dbgp_mdelay(1);
+    }
+
+    return ehci_reset_port(dbgp, port) =3D=3D 0 ? 0 : -ENOTCONN;
+}
+
+/* Return 0 on success
+ * Return -ENODEV for any general failure
+ * Return -EIO if wait for port fails
+ */
+static int ehci_dbgp_external_startup(struct ehci_dbgp *dbgp)
+{
+    unsigned int devnum;
+    struct usb_debug_descriptor dbgp_desc;
+    int ret;
+    u32 ctrl, portsc, cmd;
+    unsigned int dbg_port =3D dbgp->phys_port;
+    unsigned int tries =3D 3;
+    unsigned int reset_port_tries =3D 1;
+    bool_t try_hard_once =3D 1;
+
+try_port_reset_again:
+    ret =3D ehci_dbgp_startup(dbgp);
+    if ( ret )
+        return ret;
+
+    /* Wait for a device to show up in the debug port */
+    ret =3D ehci_wait_for_port(dbgp, dbg_port);
+    if ( ret < 0 )
+    {
+        portsc =3D readl(&dbgp->ehci_regs->port_status[dbg_port - 1]);
+        if ( !(portsc & PORT_CONNECT) && try_hard_once )
+        {
+            /*
+             * Last ditch effort to try to force enable the debug device =
by
+             * using the packet test EHCI command to try and wake it up.
+             */
+            try_hard_once =3D 0;
+            cmd =3D readl(&dbgp->ehci_regs->command);
+            cmd &=3D ~CMD_RUN;
+            writel(cmd, &dbgp->ehci_regs->command);
+            portsc =3D readl(&dbgp->ehci_regs->port_status[dbg_port - =
1]);
+            portsc |=3D PORT_TEST_PKT;
+            writel(portsc, &dbgp->ehci_regs->port_status[dbg_port - 1]);
+            ehci_dbgp_status(dbgp, "Trying to force debug port online");
+            mdelay(50);
+            ehci_dbgp_controller_reset(dbgp);
+            goto try_port_reset_again;
+        }
+        else if ( reset_port_tries-- )
+            goto try_port_reset_again;
+        dbgp_printk("no device found in debug port\n");
+        return -EIO;
+    }
+    ehci_dbgp_status(dbgp, "wait for port done");
+
+    /* Enable the debug port */
+    ctrl =3D readl(&dbgp->ehci_debug->control);
+    ctrl |=3D DBGP_CLAIM;
+    writel(ctrl, &dbgp->ehci_debug->control);
+    ctrl =3D readl(&dbgp->ehci_debug->control);
+    if ( (ctrl & DBGP_CLAIM) !=3D DBGP_CLAIM )
+    {
+        dbgp_printk("no device in debug port\n");
+        writel(ctrl & ~DBGP_CLAIM, &dbgp->ehci_debug->control);
+        return -ENODEV;
+    }
+    ehci_dbgp_status(dbgp, "debug port enabled");
+
+    /* Completely transfer the debug device to the debug controller */
+    portsc =3D readl(&dbgp->ehci_regs->port_status[dbg_port - 1]);
+    portsc &=3D ~PORT_PE;
+    writel(portsc, &dbgp->ehci_regs->port_status[dbg_port - 1]);
+
+    dbgp_mdelay(100);
+
+try_again:
+    /* Find the debug device and make it device number 127 */
+    for ( devnum =3D 0; devnum <=3D 127; devnum++ )
+    {
+        ret =3D dbgp_control_msg(dbgp, devnum,
+                               USB_DIR_IN | USB_TYPE_STANDARD | USB_RECIP_=
DEVICE,
+                               USB_REQ_GET_DESCRIPTOR, (USB_DT_DEBUG << =
8), 0,
+                               &dbgp_desc, sizeof(dbgp_desc));
+        if ( ret > 0 )
+            break;
+    }
+    if ( devnum > 127 )
+    {
+        dbgp_printk("could not find attached debug device\n");
+        goto err;
+    }
+    if ( ret < 0 )
+    {
+        dbgp_printk("attached device is not a debug device\n");
+        goto err;
+    }
+    dbgp->out.endpoint =3D dbgp_desc.bDebugOutEndpoint;
+    dbgp->in.endpoint =3D dbgp_desc.bDebugInEndpoint;
+
+    /* Move the device to 127 if it isn't already there. */
+    if ( devnum !=3D USB_DEBUG_DEVNUM )
+    {
+        ret =3D dbgp_control_msg(dbgp, devnum,
+                               USB_DIR_OUT | USB_TYPE_STANDARD | =
USB_RECIP_DEVICE,
+                               USB_REQ_SET_ADDRESS, USB_DEBUG_DEVNUM, 0, =
NULL, 0);
+        if ( ret < 0 )
+        {
+            dbgp_printk("could not move attached device to %d\n",
+                        USB_DEBUG_DEVNUM);
+            goto err;
+        }
+        devnum =3D USB_DEBUG_DEVNUM;
+        dbgp_printk("debug device renamed to 127\n");
+    }
+
+    /* Enable the debug interface */
+    ret =3D dbgp_control_msg(dbgp, USB_DEBUG_DEVNUM,
+                           USB_DIR_OUT | USB_TYPE_STANDARD | USB_RECIP_DEV=
ICE,
+                           USB_REQ_SET_FEATURE, USB_DEVICE_DEBUG_MODE,
+                           0, NULL, 0);
+    if ( ret < 0 )
+    {
+        dbgp_printk("could not enable the debug device\n");
+        goto err;
+    }
+    dbgp_printk("debug interface enabled\n");
+
+    /* Perform a small write to get the even/odd data state in sync. */
+    ret =3D dbgp_bulk_write(dbgp, USB_DEBUG_DEVNUM, dbgp->out.endpoint,
+                          "\n", 1, &ctrl);
+    if ( !ret )
+        ret =3D dbgp_wait_until_done(dbgp, ctrl, DBGP_LOOPS);
+    if ( ret < 0 )
+    {
+        dbgp_printk("dbgp_bulk_write failed: %d\n", ret);
+        goto err;
+    }
+    dbgp_printk("small write done\n");
+    dbgp->state =3D dbgp_idle;
+
+    return 0;
+err:
+    if ( tries-- )
+        goto try_again;
+    return -ENODEV;
+}
+
+typedef void (*set_debug_port_t)(struct ehci_dbgp *, unsigned int);
+
+static void default_set_debug_port(struct ehci_dbgp *dbgp, unsigned int =
port)
+{
+}
+
+static set_debug_port_t __read_mostly set_debug_port =3D default_set_debug=
_port;
+
+static void nvidia_set_debug_port(struct ehci_dbgp *dbgp, unsigned int =
port)
+{
+    u32 dword =3D pci_conf_read32(0, dbgp->bus, dbgp->slot, dbgp->func, =
0x74);
+
+    dword &=3D ~(0x0f << 12);
+    dword |=3D (port & 0x0f) << 12;
+    pci_conf_write32(0, dbgp->bus, dbgp->slot, dbgp->func, 0x74, dword);
+    dbgp_printk("set debug port to %u\n", port);
+}
+
+static void __init detect_set_debug_port(struct ehci_dbgp *dbgp)
+{
+    if ( pci_conf_read16(0, dbgp->bus, dbgp->slot, dbgp->func,
+                         PCI_VENDOR_ID) =3D=3D 0x10de )
+    {
+        dbgp_printk("using nvidia set_debug_port\n");
+        set_debug_port =3D nvidia_set_debug_port;
+    }
+}
+
+/*
+ * The code in ehci_dbgp_bios_handoff() is derived from the USB PCI
+ * quirk initialization in Linux.
+ */
+#define EHCI_USBLEGSUP_BIOS    (1 << 16) /* BIOS semaphore */
+#define EHCI_USBLEGCTLSTS      4        /* legacy control/status */
+static void ehci_dbgp_bios_handoff(struct ehci_dbgp *dbgp, u32 hcc_params)=

+{
+    u32 cap;
+    unsigned int offset =3D HCC_EXT_CAPS(hcc_params);
+    int msec;
+
+    if ( !offset )
+        return;
+
+    cap =3D pci_conf_read32(0, dbgp->bus, dbgp->slot, dbgp->func, =
offset);
+    dbgp_printk("dbgp: EHCI BIOS state %08x\n", cap);
+
+    if ( (cap & 0xff) =3D=3D 1 && (cap & EHCI_USBLEGSUP_BIOS) )
+    {
+        dbgp_printk("dbgp: BIOS handoff\n");
+        pci_conf_write8(0, dbgp->bus, dbgp->slot, dbgp->func, offset + 3, =
1);
+    }
+
+    /* if boot firmware now owns EHCI, spin till it hands it over. */
+    msec =3D 1000;
+    while ( (cap & EHCI_USBLEGSUP_BIOS) && (msec > 0) )
+    {
+        mdelay(10);
+        msec -=3D 10;
+        cap =3D pci_conf_read32(0, dbgp->bus, dbgp->slot, dbgp->func, =
offset);
+    }
+
+    if ( cap & EHCI_USBLEGSUP_BIOS )
+    {
+        /* well, possibly buggy BIOS... try to shut it down,
+         * and hope nothing goes too wrong */
+        dbgp_printk("dbgp: BIOS handoff failed: %08x\n", cap);
+        pci_conf_write8(0, dbgp->bus, dbgp->slot, dbgp->func, offset + 2, =
0);
+    }
+
+    /* just in case, always disable EHCI SMIs */
+    pci_conf_write8(0, dbgp->bus, dbgp->slot, dbgp->func,
+                    offset + EHCI_USBLEGCTLSTS, 0);
+}
+
+static int ehci_dbgp_setup(struct ehci_dbgp *dbgp)
+{
+    u32 ctrl, portsc, hcs_params;
+    unsigned int i, debug_port, new_debug_port =3D 0, n_ports;
+    unsigned int port_map_tried, playtimes =3D 3;
+    int ret;
+
+    ehci_dbgp_bios_handoff(dbgp, readl(&dbgp->ehci_caps->hcc_params));
+
+try_next_time:
+    port_map_tried =3D 0;
+
+try_next_port:
+
+    hcs_params =3D readl(&dbgp->ehci_caps->hcs_params);
+    debug_port =3D HCS_DEBUG_PORT(hcs_params);
+    dbgp->phys_port =3D debug_port;
+    n_ports =3D HCS_N_PORTS(hcs_params);
+
+    dbgp_printk("debug_port: %u\n", debug_port);
+    dbgp_printk("n_ports:    %u\n", n_ports);
+    ehci_dbgp_status(dbgp, "");
+
+    for ( i =3D 1; i <=3D n_ports; i++ )
+    {
+        portsc =3D readl(&dbgp->ehci_regs->port_status[i-1]);
+        dbgp_printk("portstatus%d: %08x\n", i, portsc);
+    }
+
+    if ( port_map_tried && (new_debug_port !=3D debug_port) )
+    {
+        if ( --playtimes )
+        {
+            set_debug_port(dbgp, new_debug_port);
+            goto try_next_time;
+        }
+        return -1;
+    }
+
+    /* Only reset the controller if it is not already in the
+     * configured state */
+    if ( readl(&dbgp->ehci_regs->configured_flag) & FLAG_CF )
+        ehci_dbgp_status(dbgp, "ehci skip - already configured");
+    else if ( ehci_dbgp_controller_reset(dbgp) !=3D 0 )
+        return -1;
+
+    ret =3D ehci_dbgp_external_startup(dbgp);
+    if (ret =3D=3D -EIO)
+        goto next_debug_port;
+
+    if ( ret < 0 )
+    {
+        /* Things didn't work so remove my claim */
+        ctrl =3D readl(&dbgp->ehci_debug->control);
+        ctrl &=3D ~(DBGP_CLAIM | DBGP_OUT);
+        writel(ctrl, &dbgp->ehci_debug->control);
+        return -1;
+    }
+
+    return 0;
+
+next_debug_port:
+    port_map_tried |=3D 1 << (debug_port - 1);
+    new_debug_port =3D (debug_port % n_ports) + 1;
+    if ( port_map_tried !=3D ((1 << n_ports) - 1) )
+    {
+        set_debug_port(dbgp, new_debug_port);
+        goto try_next_port;
+    }
+    if ( --playtimes )
+    {
+        set_debug_port(dbgp, new_debug_port);
+        goto try_next_time;
+    }
+
+    return -1;
+}
+
+static inline void _ehci_dbgp_flush(struct ehci_dbgp *dbgp)
+{
+    if ( dbgp_bulk_write(dbgp, USB_DEBUG_DEVNUM, dbgp->out.endpoint,
+                         dbgp->out.buf, dbgp->out.chunk, NULL) )
+        BUG();
+    dbgp->out.chunk =3D 0;
+}
+
+static void ehci_dbgp_flush(struct serial_port *port)
+{
+    struct ehci_dbgp *dbgp =3D port->uart;
+    s_time_t goal;
+
+    if ( !dbgp->out.chunk || !dbgp->ehci_debug || dbgp->state =3D=3D =
dbgp_unsafe )
+        return;
+
+    if ( dbgp->state =3D=3D dbgp_idle || !port->sync )
+        dbgp_check_for_completion(dbgp, 1, NULL);
+    else
+        dbgp_wait_until_complete(dbgp, NULL);
+
+    if ( dbgp->state =3D=3D dbgp_idle )
+    {
+        _ehci_dbgp_flush(dbgp);
+
+        if ( port->sync )
+        {
+            dbgp_wait_until_complete(dbgp, NULL);
+            return;
+        }
+    }
+
+    goal =3D NOW() + MICROSECS(DBGP_CHECK_INTERVAL);
+    if ( dbgp->timer.expires > goal )
+       set_timer(&dbgp->timer, goal);
+}
+
+static void ehci_dbgp_putc(struct serial_port *port, char c)
+{
+    struct ehci_dbgp *dbgp =3D port->uart;
+
+    if ( unlikely(dbgp->out.chunk >=3D DBGP_MAX_PACKET) )
+        return;
+
+    dbgp->out.buf[dbgp->out.chunk++] =3D c;
+
+    if ( dbgp->out.chunk =3D=3D DBGP_MAX_PACKET )
+        ehci_dbgp_flush(port);
+}
+
+static int ehci_dbgp_tx_empty(struct serial_port *port)
+{
+    struct ehci_dbgp *dbgp =3D port->uart;
+
+    if ( unlikely(!dbgp->ehci_debug) || unlikely(dbgp->state =3D=3D =
dbgp_unsafe) )
+        return port->sync || port->tx_log_everything || !port->txbuf;
+
+    if ( dbgp->out.chunk =3D=3D DBGP_MAX_PACKET )
+        ehci_dbgp_flush(port);
+    else
+        dbgp_check_for_completion(dbgp, 1, NULL);
+
+    if ( dbgp->state !=3D dbgp_idle && dbgp->out.chunk >=3D DBGP_MAX_PACKE=
T )
+        return 0;
+
+    port->tx_fifo_size =3D DBGP_MAX_PACKET - dbgp->out.chunk;
+    if ( dbgp->state =3D=3D dbgp_idle )
+        port->tx_fifo_size +=3D DBGP_MAX_PACKET;
+
+    return 1;
+}
+
+static int ehci_dbgp_getc(struct serial_port *port, char *pc)
+{
+    struct ehci_dbgp *dbgp =3D port->uart;
+
+    if ( !dbgp->in.chunk )
+        return 0;
+
+    *pc =3D *dbgp->in.buf;
+    if ( --dbgp->in.chunk )
+        memmove(dbgp->in.buf, dbgp->in.buf + 1, dbgp->in.chunk);
+
+    return 1;
+}
+
+/* Safe: ehci_dbgp_poll() runs as timer handler, so not reentrant. */
+static struct serial_port *poll_port;
+
+static void _ehci_dbgp_poll(struct cpu_user_regs *regs)
+{
+    struct serial_port *port =3D poll_port;
+    struct ehci_dbgp *dbgp =3D port->uart;
+    unsigned long flags;
+    unsigned int timeout =3D MICROSECS(DBGP_CHECK_INTERVAL);
+    bool_t empty =3D 0;
+
+    if ( !dbgp->ehci_debug )
+        return;
+
+    if ( spin_trylock_irqsave(&port->tx_lock, flags) )
+    {
+        if ( dbgp->state !=3D dbgp_unsafe )
+            dbgp_check_for_completion(dbgp, DBGP_CHECK_INTERVAL, NULL);
+        if ( dbgp->state =3D=3D dbgp_idle && dbgp->out.chunk )
+            _ehci_dbgp_flush(dbgp);
+        if ( dbgp->state =3D=3D dbgp_idle || dbgp->out.chunk < DBGP_MAX_PA=
CKET )
+            empty =3D 1;
+        spin_unlock_irqrestore(&port->tx_lock, flags);
+    }
+
+    if ( dbgp->in.chunk )
+        serial_rx_interrupt(port, regs);
+
+    if ( empty )
+        serial_tx_interrupt(port, regs);
+
+    if ( spin_trylock_irqsave(&port->tx_lock, flags) )
+    {
+        if ( dbgp->state =3D=3D dbgp_idle && !dbgp->in.chunk &&
+             !dbgp->out.chunk && port->txbufp =3D=3D port->txbufc )
+        {
+            if ( dbgp_bulk_read(dbgp, USB_DEBUG_DEVNUM, dbgp->in.endpoint,=

+                                DBGP_MAX_PACKET, NULL) )
+                BUG();
+            timeout =3D MILLISECS(DBGP_IDLE_INTERVAL);
+        }
+        spin_unlock_irqrestore(&port->tx_lock, flags);
+    }
+
+    set_timer(&dbgp->timer, NOW() + timeout);
+}
+
+static void ehci_dbgp_poll(void *data)
+{
+    poll_port =3D data;
+#ifdef run_in_exception_handler
+    run_in_exception_handler(_ehci_dbgp_poll);
+#else
+    _ehci_dbgp_poll(guest_cpu_user_regs());
+#endif
+}
+
+static bool_t ehci_dbgp_setup_preirq(struct ehci_dbgp *dbgp)
+{
+    if ( !ehci_dbgp_setup(dbgp) )
+        return 1;
+
+    dbgp_printk("ehci_dbgp_setup failed\n");
+    dbgp->ehci_debug =3D NULL;
+    return 0;
+}
+
+static void __init ehci_dbgp_init_preirq(struct serial_port *port)
+{
+    struct ehci_dbgp *dbgp =3D port->uart;
+    u32 debug_port, offset;
+    void __iomem *ehci_bar;
+
+    debug_port =3D pci_conf_read32(0, dbgp->bus, dbgp->slot, dbgp->func,
+                                 dbgp->cap);
+    offset =3D (debug_port >> 16) & 0xfff;
+
+    /* double check if the mem space is enabled */
+    dbgp->pci_cr =3D pci_conf_read8(0, dbgp->bus, dbgp->slot, dbgp->func,
+                                  PCI_COMMAND);
+    if ( !(dbgp->pci_cr & PCI_COMMAND_MEMORY) )
+    {
+        dbgp->pci_cr |=3D PCI_COMMAND_MEMORY;
+        pci_conf_write16(0, dbgp->bus, dbgp->slot, dbgp->func, PCI_COMMAND=
,
+                         dbgp->pci_cr);
+        dbgp_printk("MMIO for EHCI enabled\n");
+    }
+
+    /*
+     * FIXME I don't have the bar size so just guess PAGE_SIZE is more
+     * than enough.  1k is the biggest that was seen.
+     */
+    set_fixmap_nocache(FIX_EHCI_DBGP, dbgp->bar_val);
+    ehci_bar =3D (void __iomem *)fix_to_virt(FIX_EHCI_DBGP);
+    ehci_bar +=3D dbgp->bar_val & ~PAGE_MASK;
+    dbgp_printk("ehci_bar: %p\n", ehci_bar);
+
+    dbgp->ehci_caps =3D ehci_bar;
+    dbgp->ehci_regs =3D ehci_bar +
+                      HC_LENGTH(readl(&dbgp->ehci_caps->hc_capbase));
+    dbgp->ehci_debug =3D ehci_bar + offset;
+
+    detect_set_debug_port(dbgp);
+
+    if ( ehci_dbgp_setup_preirq(dbgp) )
+        ehci_dbgp_status(dbgp, "ehci_dbgp_init_preirq complete");
+
+    port->tx_fifo_size =3D DBGP_MAX_PACKET;
+    dbgp->lock =3D &port->tx_lock;
+}
+
+static void ehci_dbgp_setup_postirq(struct ehci_dbgp *dbgp)
+{
+    set_timer(&dbgp->timer, NOW() + MILLISECS(1));
+}
+
+static void __init ehci_dbgp_init_postirq(struct serial_port *port)
+{
+    struct ehci_dbgp *dbgp =3D port->uart;
+
+    if ( !dbgp->ehci_debug )
+        return;
+
+    serial_async_transmit(port);
+
+    init_timer(&dbgp->timer, ehci_dbgp_poll, port, 0);
+
+    ehci_dbgp_setup_postirq(dbgp);
+}
+
+static int ehci_dbgp_check_release(struct ehci_dbgp *dbgp)
+{
+    struct ehci_dbg_port __iomem *ehci_debug =3D dbgp->ehci_debug;
+    u32 ctrl;
+    unsigned int i;
+
+    if ( !ehci_debug )
+        return 0;
+
+    for ( i =3D 0; i < DBGP_MAX_PACKET; ++i )
+        if ( dbgp->out.buf[i] )
+            return 1;
+
+    /*
+     * This means the console is not initialized, or should get shutdown
+     * so as to allow for reuse of the USB device, which means it is time
+     * to shutdown the USB debug port.
+     */
+    printk(XENLOG_INFO "Releasing EHCI debug port at %02x:%02x.%u\n",
+           dbgp->bus, dbgp->slot, dbgp->func);
+
+    kill_timer(&dbgp->timer);
+    dbgp->ehci_debug =3D NULL;
+
+    ctrl =3D readl(&ehci_debug->control);
+    if ( ctrl & DBGP_ENABLED )
+    {
+        ctrl &=3D ~DBGP_CLAIM;
+        writel(ctrl, &ehci_debug->control);
+    }
+
+    return 0;
+}
+
+static void __init ehci_dbgp_endboot(struct serial_port *port)
+{
+    ehci_dbgp_check_release(port->uart);
+}
+
+static void ehci_dbgp_suspend(struct serial_port *port)
+{
+    struct ehci_dbgp *dbgp =3D port->uart;
+
+    if ( !dbgp->ehci_debug )
+        return;
+
+    stop_timer(&dbgp->timer);
+    dbgp->timer.expires =3D 0;
+
+    dbgp->pci_cr =3D pci_conf_read16(0, dbgp->bus, dbgp->slot, dbgp->func,=

+                                   PCI_COMMAND);
+
+    dbgp->state =3D dbgp_unsafe;
+}
+
+static void ehci_dbgp_resume(struct serial_port *port)
+{
+    struct ehci_dbgp *dbgp =3D port->uart;
+
+    if ( !dbgp->ehci_debug )
+        return;
+
+    pci_conf_write32(0, dbgp->bus, dbgp->slot, dbgp->func, dbgp->bar,
+                     dbgp->bar_val);
+    pci_conf_write16(0, dbgp->bus, dbgp->slot, dbgp->func,
+                     PCI_COMMAND, dbgp->pci_cr);
+
+    ehci_dbgp_setup_preirq(dbgp);
+    ehci_dbgp_setup_postirq(dbgp);
+}
+
+static struct uart_driver __read_mostly ehci_dbgp_driver =3D {
+    .init_preirq  =3D ehci_dbgp_init_preirq,
+    .init_postirq =3D ehci_dbgp_init_postirq,
+    .endboot      =3D ehci_dbgp_endboot,
+    .suspend      =3D ehci_dbgp_suspend,
+    .resume       =3D ehci_dbgp_resume,
+    .tx_empty     =3D ehci_dbgp_tx_empty,
+    .putc         =3D ehci_dbgp_putc,
+    .flush        =3D ehci_dbgp_flush,
+    .getc         =3D ehci_dbgp_getc
+};
+
+static struct ehci_dbgp ehci_dbgp =3D { .state =3D dbgp_unsafe, .phys_port=
 =3D 1 };
+
+static char __initdata opt_dbgp[30];
+string_param("dbgp", opt_dbgp);
+
+void __init ehci_dbgp_init(void)
+{
+    struct ehci_dbgp *dbgp =3D &ehci_dbgp;
+    u32 debug_port, offset, bar_val;
+    const char *e;
+
+    if ( strncmp(opt_dbgp, "ehci", 4) )
+        return;
+
+    if ( isdigit(opt_dbgp[4]) || !opt_dbgp[4] )
+    {
+        unsigned int num =3D 0;
+
+        if ( opt_dbgp[4] )
+            simple_strtoul(opt_dbgp + 4, &e, 10);
+
+        dbgp->cap =3D find_dbgp(dbgp, num);
+        if ( !dbgp->cap )
+            return;
+
+        dbgp_printk("Found EHCI debug port on %02x:%02x.%u\n",
+                    dbgp->bus, dbgp->slot, dbgp->func);
+    }
+    else if ( strncmp(opt_dbgp + 4, "@pci", 4) =3D=3D 0 )
+    {
+        unsigned long val =3D simple_strtoul(opt_dbgp + 8, &e, 16);
+
+        dbgp->bus =3D val;
+        if ( dbgp->bus !=3D val || *e !=3D ':' )
+            return;
+
+        val =3D simple_strtoul(e + 1, &e, 16);
+        if ( PCI_SLOT(PCI_DEVFN(val, 0)) !=3D val || *e !=3D '.' )
+            return;
+        dbgp->slot =3D val;
+
+        val =3D simple_strtoul(e + 1, &e, 16);
+        if ( PCI_FUNC(PCI_DEVFN(0, val)) !=3D val || *e )
+            return;
+        dbgp->func =3D val;
+
+        if ( !pci_device_detect(0, dbgp->bus, dbgp->slot, dbgp->func) )
+            return;
+
+        dbgp->cap =3D __find_dbgp(dbgp->bus, dbgp->slot, dbgp->func);
+        if ( !dbgp->cap )
+            return;
+
+        dbgp_printk("Using EHCI debug port on %02x:%02x.%u\n",
+                    dbgp->bus, dbgp->slot, dbgp->func);
+    }
+    else
+        return;
+
+    debug_port =3D pci_conf_read32(0, dbgp->bus, dbgp->slot, dbgp->func,
+                                 dbgp->cap);
+    dbgp->bar =3D (debug_port >> 29) & 0x7;
+    dbgp->bar =3D ((dbgp->bar - 1) * 4) + PCI_BASE_ADDRESS_0;
+    offset =3D (debug_port >> 16) & 0xfff;
+    dbgp_printk("bar: %02x offset: %03x\n", dbgp->bar, offset);
+    if ( dbgp->bar < PCI_BASE_ADDRESS_0 || dbgp->bar > PCI_BASE_ADDRESS_5 =
)
+    {
+        dbgp_printk("unsupported/invalid bar\n");
+        return;
+    }
+
+    dbgp->bar_val =3D bar_val =3D pci_conf_read32(0, dbgp->bus, dbgp->slot=
,
+                                              dbgp->func, dbgp->bar);
+    dbgp_printk("bar_val: %08x\n", bar_val);
+    if ( bar_val & ~PCI_BASE_ADDRESS_MEM_MASK )
+    {
+        dbgp_printk("only simple 32-bit MMIO BARs supported\n");
+        return;
+    }
+    bar_val &=3D PCI_BASE_ADDRESS_MEM_MASK;
+    if ( !bar_val || !(bar_val + (bar_val & -bar_val)) )
+    {
+        dbgp_printk("firmware initialization of MMIO BAR required\n");
+        return;
+    }
+
+    serial_register_uart(SERHND_DBGP, &ehci_dbgp_driver, dbgp);
+}
+
+int dbgp_op(const struct physdev_dbgp_op *op)
+{
+    if ( !ehci_dbgp.ehci_debug )
+        return 0;
+
+    switch ( op->bus )
+    {
+    case PHYSDEVOP_DBGP_BUS_UNKNOWN:
+        break;
+    case PHYSDEVOP_DBGP_BUS_PCI:
+        if ( op->u.pci.seg || ehci_dbgp.bus !=3D op->u.pci.bus ||
+            PCI_DEVFN(ehci_dbgp.slot, ehci_dbgp.func) !=3D op->u.pci.devfn=
 )
+    default:
+            return 0;
+        break;
+    }
+
+    switch ( op->op )
+    {
+    case PHYSDEVOP_DBGP_RESET_PREPARE:
+        spin_lock_irq(ehci_dbgp.lock);
+        ehci_dbgp.state =3D dbgp_unsafe;
+        dbgp_wait_until_complete(&ehci_dbgp, NULL);
+        spin_unlock_irq(ehci_dbgp.lock);
+
+        return ehci_dbgp_check_release(&ehci_dbgp);
+
+    case PHYSDEVOP_DBGP_RESET_DONE:
+        return ehci_dbgp_external_startup(&ehci_dbgp) ?: 1;
+    }
+
+    return -ENOSYS;
+}
--- a/xen/drivers/char/serial.c
+++ b/xen/drivers/char/serial.c
@@ -265,6 +265,14 @@ int __init serial_parse_handle(char *con
 {
     int handle;
=20
+    if ( !strncmp(conf, "dbgp", 4) && (!conf[4] || conf[4] =3D=3D ',') )
+    {
+        if ( !com[SERHND_DBGP].driver )
+            goto fail;
+
+        return SERHND_DBGP | SERHND_COOKED;
+    }
+
     if ( strncmp(conf, "com", 3) )
         goto fail;
=20
--- a/xen/include/asm-x86/fixmap.h
+++ b/xen/include/asm-x86/fixmap.h
@@ -36,7 +36,15 @@
  * from the end of virtual memory backwards.
  */
 enum fixed_addresses {
-    FIX_RESERVED, /* Index 0 is reserved since fix_to_virt(0) > FIXADDR_TO=
P. */
+    /* Index 0 is reserved since fix_to_virt(0) =3D=3D FIXADDR_TOP. */
+    FIX_RESERVED,
+    /*
+     * Indexes using the page tables set up before entering __start_xen()
+     * must be among the first (L1_PAGETABLE_ENTRIES - 1) entries.
+     * These are generally those needed by the various console drivers.
+     */
+    FIX_EHCI_DBGP,
+    /* Everything else should go further down. */
 #ifdef __i386__
     FIX_PAE_HIGHMEM_0,
     FIX_PAE_HIGHMEM_END =3D FIX_PAE_HIGHMEM_0 + NR_CPUS-1,
--- a/xen/include/public/physdev.h
+++ b/xen/include/public/physdev.h
@@ -312,6 +312,24 @@ struct physdev_pci_device {
 typedef struct physdev_pci_device physdev_pci_device_t;
 DEFINE_XEN_GUEST_HANDLE(physdev_pci_device_t);
=20
+#define PHYSDEVOP_DBGP_RESET_PREPARE    1
+#define PHYSDEVOP_DBGP_RESET_DONE       2
+
+#define PHYSDEVOP_DBGP_BUS_UNKNOWN      0
+#define PHYSDEVOP_DBGP_BUS_PCI          1
+
+#define PHYSDEVOP_dbgp_op               29
+struct physdev_dbgp_op {
+    /* IN */
+    uint8_t op;
+    uint8_t bus;
+    union {
+        struct physdev_pci_device pci;
+    } u;
+};
+typedef struct physdev_dbgp_op physdev_dbgp_op_t;
+DEFINE_XEN_GUEST_HANDLE(physdev_dbgp_op_t);
+
 /*
  * Notify that some PIRQ-bound event channels have been unmasked.
  * ** This command is obsolete since interface version 0x00030202 and is =
**
--- a/xen/include/xen/serial.h
+++ b/xen/include/xen/serial.h
@@ -69,9 +69,10 @@ struct uart_driver {
 };
=20
 /* 'Serial handles' are composed from the following fields. */
-#define SERHND_IDX      (3<<0) /* COM1 or COM2?                           =
*/
+#define SERHND_IDX      (3<<0) /* COM1, COM2, or DBGP?                    =
*/
 # define SERHND_COM1    (0<<0)
 # define SERHND_COM2    (1<<0)
+# define SERHND_DBGP    (2<<0)
 #define SERHND_HI       (1<<2) /* Mux/demux each transferred char by MSB. =
*/
 #define SERHND_LO       (1<<3) /* Ditto, except that the MSB is cleared.  =
*/
 #define SERHND_COOKED   (1<<4) /* Newline/carriage-return translation?    =
*/
@@ -142,9 +143,13 @@ struct ns16550_defaults {
     unsigned long io_base; /* default io_base address */
 };
 void ns16550_init(int index, struct ns16550_defaults *defaults);
+void ehci_dbgp_init(void);
=20
 void pl011_init(int index, unsigned long register_base_address);
=20
+struct physdev_dbgp_op;
+int dbgp_op(const struct physdev_dbgp_op *);
+
 /* Baud rate was pre-configured before invoking the UART driver. */
 #define BAUD_AUTO (-1)
=20



--=__Part0736157F.0__=
Content-Type: text/plain; name="sercon-ehci-dbgp.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="sercon-ehci-dbgp.patch"

console: add EHCI debug port based serial console=0A=0ALow level hardware =
interface pieces adapted from Linux.=0A=0AFor setup information, see =
Linux'es Documentation/x86/earlyprintk.txt=0Aand/or http://www.coreboot.org=
/EHCI_Debug_Port.=0A=0ASigned-off-by: Jan Beulich <jbeulich@suse.com>=0ARev=
iewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>=0A=0A--- =
a/docs/misc/xen-command-line.markdown=0A+++ b/docs/misc/xen-command-line.ma=
rkdown=0A@@ -244,7 +244,7 @@ A typical setup for most situations migh=0A =
Specify the size of the console ring buffer.=0A =0A ### console=0A-> `=3D =
List of [ vga | com1[H,L] | com2[H,L] | none ]`=0A+> `=3D List of [ vga | =
com1[H,L] | com2[H,L] | dbgp | none ]`=0A =0A > Default: `console=3Dcom1,vg=
a`=0A =0A@@ -260,6 +260,8 @@ the converse; transmitted and received c=0A =
cleared.  This allows a single port to be shared by two subsystems=0A =
(e.g. console and debugger).=0A =0A+`dbgp` indicates that Xen should use a =
USB debug port.=0A+=0A `none` indicates that Xen should not use a console. =
 This option only=0A makes sense on its own.=0A =0A@@ -352,6 +354,12 @@ =
combination with the `low_crashinfo` com=0A ### credit2\_load\_window\_shif=
t=0A > `=3D <integer>`=0A =0A+### dbgp=0A+> `=3D ehci[ <integer> | =
@pci<bus>:<slot>.<func> ]`=0A+=0A+Specify the USB controller to use, =
either by instance number (when going=0A+over the PCI busses sequentially) =
or by PCI device (must be on segment 0).=0A+=0A ### debug\_stack\_lines=0A =
> `=3D <integer>`=0A =0A--- a/xen/arch/x86/Rules.mk=0A+++ b/xen/arch/x86/Ru=
les.mk=0A@@ -7,6 +7,7 @@ HAS_CPUFREQ :=3D y=0A HAS_PCI :=3D y=0A HAS_PASSTH=
ROUGH :=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--- a/xen/arch/x86/physdev.c=0A+=
++ b/xen/arch/x86/physdev.c=0A@@ -8,6 +8,7 @@=0A #include <xen/event.h>=0A =
#include <xen/guest_access.h>=0A #include <xen/iocap.h>=0A+#include =
<xen/serial.h>=0A #include <asm/current.h>=0A #include <asm/io_apic.h>=0A =
#include <asm/msi.h>=0A@@ -722,6 +723,19 @@ ret_t do_physdev_op(int cmd, =
XEN_GUEST_H=0A =0A         break;=0A     }=0A+=0A+    case PHYSDEVOP_dbgp_o=
p: {=0A+        struct physdev_dbgp_op op;=0A+=0A+        if ( !IS_PRIV(v->=
domain) )=0A+            ret =3D -EPERM;=0A+        else if ( copy_from_gue=
st(&op, arg, 1) )=0A+            ret =3D -EFAULT;=0A+        else=0A+      =
      ret =3D dbgp_op(&op);=0A+        break;=0A+    }=0A+=0A     =
default:=0A         ret =3D -ENOSYS;=0A         break;=0A--- a/xen/arch/x86=
/setup.c=0A+++ b/xen/arch/x86/setup.c=0A@@ -606,6 +606,7 @@ void __init =
__start_xen(unsigned long mb=0A     ns16550.io_base =3D 0x2f8;=0A     =
ns16550.irq     =3D 3;=0A     ns16550_init(1, &ns16550);=0A+    ehci_dbgp_i=
nit();=0A     console_init_preirq();=0A =0A     printk("Bootloader: %s\n", =
loader);=0A--- a/xen/drivers/char/Makefile=0A+++ b/xen/drivers/char/Makefil=
e=0A@@ -1,4 +1,5 @@=0A obj-y +=3D console.o=0A obj-$(HAS_NS16550) +=3D =
ns16550.o=0A obj-$(HAS_PL011) +=3D pl011.o=0A+obj-$(HAS_EHCI) +=3D =
ehci-dbgp.o=0A obj-y +=3D serial.o=0A--- /dev/null=0A+++ b/xen/drivers/char=
/ehci-dbgp.c=0A@@ -0,0 +1,1577 @@=0A+/*=0A+ * Standalone EHCI USB debug =
driver=0A+ *=0A+ * Hardware interface code based on the respective early =
console driver in=0A+ * Linux; see the Linux source for authorship and =
copyrights.=0A+ */=0A+=0A+#include <xen/config.h>=0A+#include <xen/console.=
h>=0A+#include <xen/delay.h>=0A+#include <xen/errno.h>=0A+#include =
<xen/pci.h>=0A+#include <xen/serial.h>=0A+#include <asm/byteorder.h>=0A+#in=
clude <asm/io.h>=0A+#include <asm/fixmap.h>=0A+#include <public/physdev.h>=
=0A+=0A+/* #define DBGP_DEBUG */=0A+=0A+/* EHCI register interface, =
corresponds to EHCI Revision 0.95 specification */=0A+=0A+/* Section 2.2 =
Host Controller Capability Registers */=0A+struct ehci_caps {=0A+    =
/*=0A+     * These fields are specified as 8 and 16 bit registers,=0A+     =
* but some hosts can't perform 8 or 16 bit PCI accesses.=0A+     * some =
hosts treat caplength and hciversion as parts of a 32-bit=0A+     * =
register, others treat them as two separate registers, this=0A+     * =
affects the memory map for big endian controllers.=0A+     */=0A+    u32 =
hc_capbase;=0A+#define HC_LENGTH(p)      (0x00ff & (p)) /* bits 7:0 / =
offset 0x00 */=0A+#define HC_VERSION(p)     (0xffff & ((p) >> 16)) /* bits =
31:16 / offset 0x02 */=0A+=0A+    u32 hcs_params;       /* HCSPARAMS - =
offset 0x04 */=0A+#define HCS_DEBUG_PORT(p) (((p) >> 20) & 0xf) /* bits =
23:20, debug port? */=0A+#define HCS_INDICATOR(p)  ((p) & (1 << 16))   /* =
true: has port indicators */=0A+#define HCS_N_CC(p)       (((p) >> 12) & =
0xf) /* bits 15:12, #companion HCs */=0A+#define HCS_N_PCC(p)      (((p) =
>> 8) & 0xf)  /* bits 11:8, ports per CC */=0A+#define HCS_PORTROUTED(p) =
((p) & (1 << 7))    /* true: port routing */=0A+#define HCS_PPC(p)        =
((p) & (1 << 4))    /* true: port power control */=0A+#define HCS_N_PORTS(p=
)    (((p) >> 0) & 0xf)  /* bits 3:0, ports on HC */=0A+=0A+    u32 =
hcc_params;       /* HCCPARAMS - offset 0x08 */=0A+/* EHCI 1.1 addendum =
*/=0A+#define HCC_32FRAME_PERIODIC_LIST(p) ((p) & (1 << 19))=0A+#define =
HCC_PER_PORT_CHANGE_EVENT(p) ((p) & (1 << 18))=0A+#define HCC_LPM(p)       =
 ((p) & (1 << 17))=0A+#define HCC_HW_PREFETCH(p) ((p) & (1 << 16))=0A+#defi=
ne HCC_EXT_CAPS(p)   (((p) >> 8) & 0xff) /* for pci extended caps =
*/=0A+#define HCC_ISOC_CACHE(p) ((p) & (1 << 7))    /* true: can cache =
isoc frame */=0A+#define HCC_ISOC_THRES(p) (((p) >> 4) & 0x7)  /* bits =
6:4, uframes cached */=0A+#define HCC_CANPARK(p)    ((p) & (1 << 2))    /* =
true: can park on async qh */=0A+#define HCC_PGM_FRAMELISTLEN(p) ((p) & (1 =
<< 1)) /* true: periodic_size changes */=0A+#define HCC_64BIT_ADDR(p) ((p) =
& 1)           /* true: can use 64-bit addr */=0A+=0A+    u8  portroute[8];=
     /* nibbles for routing - offset 0x0C */=0A+};=0A+=0A+/* Section 2.3 =
Host Controller Operational Registers */=0A+struct ehci_regs {=0A+    /* =
USBCMD: offset 0x00 */=0A+    u32 command;=0A+=0A+/* EHCI 1.1 addendum =
*/=0A+#define CMD_HIRD        (0xf << 24) /* host initiated resume =
duration */=0A+#define CMD_PPCEE       (1 << 15)   /* per port change =
event enable */=0A+#define CMD_FSP         (1 << 14)   /* fully synchronize=
d prefetch */=0A+#define CMD_ASPE        (1 << 13)   /* async schedule =
prefetch enable */=0A+#define CMD_PSPE        (1 << 12)   /* periodic =
schedule prefetch enable */=0A+/* 23:16 is r/w intr rate, in microframes; =
default "8" =3D=3D 1/msec */=0A+#define CMD_PARK        (1 << 11)   /* =
enable "park" on async qh */=0A+#define CMD_PARK_CNT(c) (((c) >> 8) & 3) =
/* how many transfers to park for */=0A+#define CMD_LRESET      (1 << 7)   =
 /* partial reset (no ports, etc) */=0A+#define CMD_IAAD        (1 << 6)   =
 /* "doorbell" interrupt async advance */=0A+#define CMD_ASE         (1 << =
5)    /* async schedule enable */=0A+#define CMD_PSE         (1 << 4)    =
/* periodic schedule enable */=0A+/* 3:2 is periodic frame list size =
*/=0A+#define CMD_RESET       (1 << 1)    /* reset HC not bus */=0A+#define=
 CMD_RUN         (1 << 0)    /* start/stop HC */=0A+=0A+    /* USBSTS: =
offset 0x04 */=0A+    u32 status;=0A+#define STS_PPCE_MASK   (0xff << 16) =
/* Per-Port change event 1-16 */=0A+#define STS_ASS         (1 << 15)   /* =
Async Schedule Status */=0A+#define STS_PSS         (1 << 14)   /* =
Periodic Schedule Status */=0A+#define STS_RECL        (1 << 13)   /* =
Reclamation */=0A+#define STS_HALT        (1 << 12)   /* Not running (any =
reason) */=0A+/* some bits reserved */=0A+    /* these STS_* flags are =
also intr_enable bits (USBINTR) */=0A+#define STS_IAA         (1 << 5)    =
/* Interrupted on async advance */=0A+#define STS_FATAL       (1 << 4)    =
/* such as some PCI access errors */=0A+#define STS_FLR         (1 << 3)   =
 /* frame list rolled over */=0A+#define STS_PCD         (1 << 2)    /* =
port change detect */=0A+#define STS_ERR         (1 << 1)    /* "error" =
completion (overflow, ...) */=0A+#define STS_INT         (1 << 0)    /* =
"normal" completion (short, ...) */=0A+=0A+    /* USBINTR: offset 0x08 =
*/=0A+    u32 intr_enable;=0A+=0A+    /* FRINDEX: offset 0x0C */=0A+    =
u32 frame_index;    /* current microframe number */=0A+    /* CTRLDSSEGMENT=
: offset 0x10 */=0A+    u32 segment;    /* address bits 63:32 if needed =
*/=0A+    /* PERIODICLISTBASE: offset 0x14 */=0A+    u32 frame_list;    /* =
points to periodic list */=0A+    /* ASYNCLISTADDR: offset 0x18 */=0A+    =
u32 async_next;    /* address of next async queue head */=0A+=0A+    u32 =
reserved[9];=0A+=0A+    /* CONFIGFLAG: offset 0x40 */=0A+    u32 configured=
_flag;=0A+#define FLAG_CF         (1 << 0)    /* true: we'll support "high =
speed" */=0A+=0A+    /* PORTSC: offset 0x44 */=0A+    u32 port_status[0];  =
  /* up to N_PORTS */=0A+/* EHCI 1.1 addendum */=0A+#define PORTSC_SUSPEND_=
STS_ACK   0=0A+#define PORTSC_SUSPEND_STS_NYET  1=0A+#define PORTSC_SUSPEND=
_STS_STALL 2=0A+#define PORTSC_SUSPEND_STS_ERR   3=0A+=0A+#define =
PORT_DEV_ADDR   (0x7f << 25) /* device address */=0A+#define PORT_SSTS     =
  (0x3 << 23)  /* suspend status */=0A+/* 31:23 reserved */=0A+#define =
PORT_WKOC_E     (1 << 22)    /* wake on overcurrent (enable) */=0A+#define =
PORT_WKDISC_E   (1 << 21)    /* wake on disconnect (enable) */=0A+#define =
PORT_WKCONN_E   (1 << 20)    /* wake on connect (enable) */=0A+/* 19:16 =
for port testing */=0A+#define PORT_TEST(x)    (((x) & 0xf) << 16) /* Port =
Test Control */=0A+#define PORT_TEST_PKT   PORT_TEST(0x4) /* Port Test =
Control - packet test */=0A+#define PORT_TEST_FORCE PORT_TEST(0x5) /* Port =
Test Control - force enable */=0A+#define PORT_LED_OFF    (0 << 14)=0A+#def=
ine PORT_LED_AMBER  (1 << 14)=0A+#define PORT_LED_GREEN  (2 << 14)=0A+#defi=
ne PORT_LED_MASK   (3 << 14)=0A+#define PORT_OWNER      (1 << 13)    /* =
true: companion hc owns this port */=0A+#define PORT_POWER      (1 << 12)  =
  /* true: has power (see PPC) */=0A+#define PORT_USB11(x)   (((x) & (3 << =
10)) =3D=3D (1 << 10)) /* USB 1.1 device */=0A+/* 11:10 for detecting =
lowspeed devices (reset vs release ownership) */=0A+/* 9 reserved =
*/=0A+#define PORT_LPM        (1 << 9)     /* LPM transaction */=0A+#define=
 PORT_RESET      (1 << 8)     /* reset port */=0A+#define PORT_SUSPEND    =
(1 << 7)     /* suspend port */=0A+#define PORT_RESUME     (1 << 6)     /* =
resume it */=0A+#define PORT_OCC        (1 << 5)     /* over current =
change */=0A+#define PORT_OC         (1 << 4)     /* over current active =
*/=0A+#define PORT_PEC        (1 << 3)     /* port enable change */=0A+#def=
ine PORT_PE         (1 << 2)     /* port enable */=0A+#define PORT_CSC     =
   (1 << 1)     /* connect status change */=0A+#define PORT_CONNECT    (1 =
<< 0)     /* device connected */=0A+#define PORT_RWC_BITS   (PORT_CSC | =
PORT_PEC | PORT_OCC)=0A+};=0A+=0A+/*=0A+ * Appendix C, Debug port ... =
intended for use with special "debug devices"=0A+ * that can help if =
there's no serial console.  (nonstandard enumeration.)=0A+ */=0A+struct =
ehci_dbg_port {=0A+    u32 control;=0A+#define DBGP_OWNER      (1 << =
30)=0A+#define DBGP_ENABLED    (1 << 28)=0A+#define DBGP_DONE       (1 << =
16)=0A+#define DBGP_INUSE      (1 << 10)=0A+#define DBGP_ERRCODE(x) (((x) =
>> 7) & 0x07)=0A+# define DBGP_ERR_BAD    1=0A+# define DBGP_ERR_SIGNAL =
2=0A+#define DBGP_ERROR      (1 << 6)=0A+#define DBGP_GO         (1 << =
5)=0A+#define DBGP_OUT        (1 << 4)=0A+#define DBGP_LEN        (0xf << =
0)=0A+#define DBGP_CLAIM      (DBGP_OWNER | DBGP_ENABLED | DBGP_INUSE)=0A+ =
   u32 pids;=0A+#define DBGP_PID_GET(x)         (((x) >> 16) & 0xff)=0A+#de=
fine DBGP_PID_SET(data, tok) (((data) << 8) | (tok))=0A+    u32 data03;=0A+=
    u32 data47;=0A+    u32 address;=0A+#define DBGP_EPADDR(dev, ep) =
(((dev) << 8) | (ep))=0A+};=0A+=0A+/* CONTROL REQUEST SUPPORT */=0A+=0A+/*=
=0A+ * USB directions=0A+ *=0A+ * This bit flag is used in endpoint =
descriptors' bEndpointAddress field.=0A+ * It's also one of three fields =
in control requests bRequestType.=0A+ */=0A+#define USB_DIR_OUT 0          =
 /* to device */=0A+#define USB_DIR_IN  0x80        /* to host */=0A+=0A+/*=
=0A+ * USB types, the second of three bRequestType fields=0A+ */=0A+#define=
 USB_TYPE_MASK     (0x03 << 5)=0A+#define USB_TYPE_STANDARD (0x00 << =
5)=0A+#define USB_TYPE_CLASS    (0x01 << 5)=0A+#define USB_TYPE_VENDOR   =
(0x02 << 5)=0A+#define USB_TYPE_RESERVED (0x03 << 5)=0A+=0A+/*=0A+ * USB =
recipients, the third of three bRequestType fields=0A+ */=0A+#define =
USB_RECIP_MASK      0x1f=0A+#define USB_RECIP_DEVICE    0x00=0A+#define =
USB_RECIP_INTERFACE 0x01=0A+#define USB_RECIP_ENDPOINT  0x02=0A+#define =
USB_RECIP_OTHER     0x03=0A+/* From Wireless USB 1.0 */=0A+#define =
USB_RECIP_PORT      0x04=0A+#define USB_RECIP_RPIPE     0x05=0A+=0A+/*=0A+ =
* Standard requests, for the bRequest field of a SETUP packet.=0A+ *=0A+ * =
These are qualified by the bRequestType field, so that for example=0A+ * =
TYPE_CLASS or TYPE_VENDOR specific feature flags could be retrieved=0A+ * =
by a GET_STATUS request.=0A+ */=0A+#define USB_REQ_GET_STATUS        =
0x00=0A+#define USB_REQ_CLEAR_FEATURE     0x01=0A+#define USB_REQ_SET_FEATU=
RE       0x03=0A+#define USB_REQ_SET_ADDRESS       0x05=0A+#define =
USB_REQ_GET_DESCRIPTOR    0x06=0A+#define USB_REQ_SET_DESCRIPTOR    =
0x07=0A+#define USB_REQ_GET_CONFIGURATION 0x08=0A+#define USB_REQ_SET_CONFI=
GURATION 0x09=0A+#define USB_REQ_GET_INTERFACE     0x0A=0A+#define =
USB_REQ_SET_INTERFACE     0x0B=0A+#define USB_REQ_SYNCH_FRAME       =
0x0C=0A+=0A+#define USB_DEVICE_DEBUG_MODE        6    /* (special devices =
only) */=0A+=0A+/**=0A+ * struct usb_ctrlrequest - SETUP data for a USB =
device control request=0A+ * @bRequestType: matches the USB bmRequestType =
field=0A+ * @bRequest: matches the USB bRequest field=0A+ * @wValue: =
matches the USB wValue field (le16 byte order)=0A+ * @wIndex: matches the =
USB wIndex field (le16 byte order)=0A+ * @wLength: matches the USB wLength =
field (le16 byte order)=0A+ *=0A+ * This structure is used to send control =
requests to a USB device.  It matches=0A+ * the different fields of the =
USB 2.0 Spec section 9.3, table 9-2.  See the=0A+ * USB spec for a fuller =
description of the different fields, and what they are=0A+ * used for.=0A+ =
*=0A+ * Note that the driver for any interface can issue control =
requests.=0A+ * For most devices, interfaces don't coordinate with each =
other, so=0A+ * such requests may be made at any time.=0A+ */=0A+struct =
usb_ctrlrequest {=0A+    u8 bRequestType;=0A+    u8 bRequest;=0A+    =
__le16 wValue;=0A+    __le16 wIndex;=0A+    __le16 wLength;=0A+} __attribut=
e__ ((packed));=0A+=0A+/* USB_DT_DEBUG: for special highspeed devices, =
replacing serial console */=0A+=0A+#define USB_DT_DEBUG    0x0a=0A+=0A+stru=
ct usb_debug_descriptor {=0A+    u8 bLength;=0A+    u8 bDescriptorType;=0A+=
    /* bulk endpoints with 8 byte maxpacket */=0A+    u8 bDebugInEndpoint;=
=0A+    u8 bDebugOutEndpoint;=0A+} __attribute__((packed));=0A+=0A+#define =
USB_DEBUG_DEVNUM 127=0A+=0A+/*=0A+ * USB Packet IDs (PIDs)=0A+ */=0A+=0A+/*=
 token */=0A+#define USB_PID_OUT           0xe1=0A+#define USB_PID_IN      =
      0x69=0A+#define USB_PID_SOF           0xa5=0A+#define USB_PID_SETUP  =
       0x2d=0A+/* handshake */=0A+#define USB_PID_ACK           0xd2=0A+#de=
fine USB_PID_NAK           0x5a=0A+#define USB_PID_STALL         0x1e=0A+#d=
efine USB_PID_NYET          0x96=0A+/* data */=0A+#define USB_PID_DATA0    =
     0xc3=0A+#define USB_PID_DATA1         0x4b=0A+#define USB_PID_DATA2   =
      0x87=0A+#define USB_PID_MDATA         0x0f=0A+/* Special */=0A+#defin=
e USB_PID_PREAMBLE      0x3c=0A+#define USB_PID_ERR           0x3c=0A+#defi=
ne USB_PID_SPLIT         0x78=0A+#define USB_PID_PING          0xb4=0A+#def=
ine USB_PID_UNDEF_0       0xf0=0A+=0A+#define PCI_CLASS_SERIAL_USB_EHCI =
0x0c0320=0A+#define PCI_CAP_ID_EHCI_DEBUG     0x0a=0A+=0A+#define =
HUB_ROOT_RESET_TIME   50    /* times are in msec */=0A+#define HUB_SHORT_RE=
SET_TIME  10=0A+#define HUB_LONG_RESET_TIME   200=0A+#define HUB_RESET_TIME=
OUT     500=0A+=0A+#define DBGP_MAX_PACKET       8=0A+#define DBGP_LOOPS   =
         1000=0A+#define DBGP_TIMEOUT          (250 * 1000) /* us =
*/=0A+#define DBGP_CHECK_INTERVAL   100 /* us */=0A+/* This one can be set =
arbitrarily - only affects input responsiveness: */=0A+#define DBGP_IDLE_IN=
TERVAL    100 /* ms */=0A+=0A+struct ehci_dbgp {=0A+    struct ehci_dbg_por=
t __iomem *ehci_debug;=0A+    enum dbgp_state {=0A+        dbgp_idle,=0A+  =
      dbgp_out,=0A+        dbgp_in,=0A+        dbgp_ctrl,=0A+        =
dbgp_unsafe /* cannot use debug device during EHCI reset */=0A+    } =
state;=0A+    unsigned int phys_port;=0A+    struct {=0A+        unsigned =
int endpoint;=0A+        unsigned int chunk;=0A+        char buf[DBGP_MAX_P=
ACKET];=0A+    } out, in;=0A+    unsigned long timeout;=0A+    struct =
timer timer;=0A+    spinlock_t *lock;=0A+    bool_t reset_run;=0A+    u8 =
bus, slot, func, bar;=0A+    u16 pci_cr;=0A+    u32 bar_val;=0A+    =
unsigned int cap;=0A+    struct ehci_regs __iomem *ehci_regs;=0A+    =
struct ehci_caps __iomem *ehci_caps;=0A+};=0A+=0A+static int ehci_dbgp_exte=
rnal_startup(struct ehci_dbgp *);=0A+=0A+static void ehci_dbgp_status(struc=
t ehci_dbgp *dbgp, const char *str)=0A+{=0A+#ifdef DBGP_DEBUG=0A+#define =
dbgp_printk printk=0A+    if ( !dbgp->ehci_debug )=0A+        return;=0A+  =
  dbgp_printk("dbgp: %s\n", str);=0A+    dbgp_printk("  debug control: =
%08x\n", readl(&dbgp->ehci_debug->control));=0A+    dbgp_printk("  EHCI =
cmd     : %08x\n", readl(&dbgp->ehci_regs->command));=0A+    dbgp_printk(" =
 EHCI conf flg: %08x\n",=0A+                readl(&dbgp->ehci_regs->configu=
red_flag));=0A+    dbgp_printk("  EHCI status  : %08x\n", readl(&dbgp->ehci=
_regs->status));=0A+    dbgp_printk("  EHCI portsc  : %08x\n",=0A+         =
       readl(&dbgp->ehci_regs->port_status[dbgp->phys_port - 1]));=0A+#endi=
f=0A+}=0A+=0A+#ifndef DBGP_DEBUG=0A+static inline __attribute__ ((format =
(printf, 1, 2))) void=0A+dbgp_printk(const char *fmt, ...) { }=0A+#endif=0A=
+=0A+static inline u32 dbgp_len_update(u32 x, u32 len)=0A+{=0A+    return =
(x & ~DBGP_LEN) | (len & DBGP_LEN) | DBGP_OUT;=0A+}=0A+=0A+static inline =
u32 dbgp_pid_write_update(u32 x, u32 tok)=0A+{=0A+    static u8 data0 =3D =
USB_PID_DATA1;=0A+=0A+    data0 ^=3D USB_PID_DATA0 ^ USB_PID_DATA1;=0A+    =
return (x & 0xffff0000) | (data0 << 8) | (tok & 0xff);=0A+}=0A+=0A+static =
inline u32 dbgp_pid_read_update(u32 x, u32 tok)=0A+{=0A+    return (x & =
0xffffff00) | (tok & 0xff);=0A+}=0A+=0A+static inline void dbgp_set_data(st=
ruct ehci_dbg_port __iomem *ehci_debug,=0A+                                =
 const void *buf, unsigned int size)=0A+{=0A+    const unsigned char =
*bytes =3D buf;=0A+    u32 lo =3D 0, hi =3D 0;=0A+    unsigned int =
i;=0A+=0A+    for ( i =3D 0; i < 4 && i < size; i++ )=0A+        lo |=3D =
bytes[i] << (8 * i);=0A+    for ( ; i < 8 && i < size; i++ )=0A+        hi =
|=3D bytes[i] << (8 * (i - 4));=0A+    writel(lo, &ehci_debug->data03);=0A+=
    writel(hi, &ehci_debug->data47);=0A+}=0A+=0A+static inline void =
dbgp_get_data(struct ehci_dbg_port __iomem *ehci_debug,=0A+                =
                 void *buf, int size)=0A+{=0A+    unsigned char *bytes =3D =
buf;=0A+    u32 lo =3D readl(&ehci_debug->data03);=0A+    u32 hi =3D =
readl(&ehci_debug->data47);=0A+    unsigned int i;=0A+=0A+    for ( i =3D =
0; i < 4 && i < size; i++ )=0A+        bytes[i] =3D (lo >> (8 * i)) & =
0xff;=0A+    for ( ; i < 8 && i < size; i++ )=0A+        bytes[i] =3D (hi =
>> (8 * (i - 4))) & 0xff;=0A+}=0A+=0A+static void dbgp_issue_command(struct=
 ehci_dbgp *dbgp, u32 ctrl,=0A+                               enum =
dbgp_state state)=0A+{=0A+    u32 cmd =3D readl(&dbgp->ehci_regs->command);=
=0A+=0A+    if ( unlikely(!(cmd & CMD_RUN)) )=0A+    {=0A+        /*=0A+   =
      * If the EHCI controller is not in the run state do extended=0A+     =
    * checks to see if ACPI or some other initialization also=0A+         =
* reset the EHCI debug port.=0A+         */=0A+        u32 ctrl =3D =
readl(&dbgp->ehci_debug->control);=0A+=0A+        if ( ctrl & DBGP_ENABLED =
)=0A+        {=0A+            cmd |=3D CMD_RUN;=0A+            writel(cmd, =
&dbgp->ehci_regs->command);=0A+            dbgp->reset_run =3D 1;=0A+      =
  }=0A+        else if ( dbgp->state !=3D dbgp_unsafe )=0A+        {=0A+   =
         dbgp->state =3D dbgp_unsafe;=0A+            ehci_dbgp_external_sta=
rtup(dbgp);=0A+        }=0A+    }=0A+=0A+    writel(ctrl | DBGP_GO, =
&dbgp->ehci_debug->control);=0A+    dbgp->timeout =3D DBGP_TIMEOUT;=0A+    =
if ( dbgp->state !=3D dbgp_unsafe )=0A+        dbgp->state =3D state;=0A+}=
=0A+=0A+static int dbgp_check_for_completion(struct ehci_dbgp *dbgp,=0A+   =
                                  unsigned int interval, u8 *ppid)=0A+{=0A+=
    u32 ctrl;=0A+    int ret;=0A+=0A+    if ( dbgp->state =3D=3D dbgp_idle =
)=0A+        return 0;=0A+=0A+    ctrl =3D readl(&dbgp->ehci_debug->control=
) & ~DBGP_GO;=0A+    if ( !(ctrl & DBGP_DONE) )=0A+    {=0A+        if ( =
dbgp->timeout > interval )=0A+            dbgp->timeout -=3D interval;=0A+ =
       else if ( interval )=0A+        {=0A+            /* See the timeout =
related comment in dbgp_wait_until_done(). */=0A+            dbgp->state =
=3D dbgp_unsafe;=0A+            dbgp->timeout =3D 0;=0A+        }=0A+      =
  return -DBGP_TIMEOUT;=0A+    }=0A+=0A+    if ( ctrl & DBGP_ERROR )=0A+   =
 {=0A+        ret =3D -DBGP_ERRCODE(ctrl);=0A+        if ( ret =3D=3D =
-DBGP_ERR_BAD && dbgp->timeout > interval )=0A+            ctrl |=3D =
DBGP_GO;=0A+    }=0A+    else=0A+    {=0A+        u8 pid =3D DBGP_PID_GET(r=
eadl(&dbgp->ehci_debug->pids));=0A+=0A+        ret =3D ctrl & DBGP_LEN;=0A+=
        if ( ppid )=0A+            *ppid =3D pid;=0A+        else if ( =
dbgp->state =3D=3D dbgp_in )=0A+        {=0A+            dbgp_get_data(dbgp=
->ehci_debug, dbgp->in.buf, ret);=0A+            dbgp->in.chunk =3D =
ret;=0A+        }=0A+        else if ( pid =3D=3D USB_PID_NAK && dbgp->time=
out > interval )=0A+            ctrl |=3D DBGP_GO;=0A+    }=0A+=0A+    =
writel(ctrl, &dbgp->ehci_debug->control);=0A+    if ( ctrl & DBGP_GO )=0A+ =
   {=0A+        dbgp->timeout -=3D interval;=0A+        return -DBGP_TIMEOU=
T;=0A+    }=0A+=0A+    if ( unlikely(dbgp->reset_run) )=0A+    {=0A+       =
 writel(readl(&dbgp->ehci_regs->command) & ~CMD_RUN,=0A+               =
&dbgp->ehci_regs->command);=0A+        dbgp->reset_run =3D 0;=0A+    =
}=0A+=0A+    if ( dbgp->state !=3D dbgp_unsafe )=0A+        dbgp->state =
=3D dbgp_idle;=0A+=0A+    return ret;=0A+}=0A+=0A+static int dbgp_wait_unti=
l_complete(struct ehci_dbgp *dbgp, u8 *ppid)=0A+{=0A+    unsigned int loop =
=3D DBGP_TIMEOUT;=0A+    int ret;=0A+=0A+    do {=0A+        ret =3D =
dbgp_check_for_completion(dbgp, 0, ppid);=0A+        if ( ret !=3D =
-DBGP_TIMEOUT )=0A+            break;=0A+        udelay(1);=0A+    } while =
( --loop );=0A+=0A+    if ( !ppid && !loop )=0A+        dbgp->state =3D =
dbgp_unsafe;=0A+=0A+    return ret;=0A+}=0A+=0A+static inline void =
dbgp_mdelay(unsigned int ms)=0A+{=0A+    while ( ms-- )=0A+    {=0A+       =
 unsigned int i;=0A+=0A+        for ( i =3D 0; i < 1000; i++ )=0A+         =
   outb(0x1, 0x80);=0A+    }=0A+}=0A+=0A+static void dbgp_breathe(void)=0A+=
{=0A+    /* Sleep to give the debug port a chance to breathe. */=0A+    =
dbgp_mdelay(1);=0A+}=0A+=0A+static int dbgp_wait_until_done(struct =
ehci_dbgp *dbgp, u32 ctrl,=0A+                                unsigned int =
loop)=0A+{=0A+    int ret;=0A+=0A+    dbgp->timeout =3D 0;=0A+=0A+    for =
( ; ; writel(ctrl | DBGP_GO, &dbgp->ehci_debug->control) )=0A+    {=0A+    =
    u8 pid;=0A+=0A+        ret =3D dbgp_wait_until_complete(dbgp, =
&pid);=0A+        if ( ret < 0 )=0A+        {=0A+            /*=0A+        =
     * A -DBGP_TIMEOUT failure here means the device has failed,=0A+       =
      * perhaps because it was unplugged, in which case we do not=0A+      =
       * want to hang the system so the dbgp will be marked as unsafe=0A+  =
           * to use. EHCI reset is the only way to recover if you =
unplug=0A+             * the dbgp device.=0A+             */=0A+           =
 if ( ret =3D=3D -DBGP_TIMEOUT )=0A+                dbgp->state =3D =
dbgp_unsafe;=0A+            if ( ret !=3D -DBGP_ERR_BAD || !--loop )=0A+   =
             break;=0A+        }=0A+        else=0A+        {=0A+          =
  /*=0A+             * If the port is getting full or it has dropped =
data=0A+             * start pacing ourselves, not necessary but it's =
friendly.=0A+             */=0A+            if ( pid =3D=3D USB_PID_NAK || =
pid =3D=3D USB_PID_NYET )=0A+                dbgp_breathe();=0A+=0A+       =
     /* If we got a NACK, reissue the transmission. */=0A+            if ( =
pid !=3D USB_PID_NAK || !--loop )=0A+                break;=0A+        =
}=0A+    }=0A+=0A+    return ret;=0A+}=0A+=0A+static int dbgp_bulk_write(st=
ruct ehci_dbgp *dbgp,=0A+                           unsigned int devnum, =
unsigned int endpoint,=0A+                           const void *bytes, =
unsigned int size, u32 *pctrl)=0A+{=0A+    u32 addr, pids, ctrl;=0A+=0A+   =
 if ( size > DBGP_MAX_PACKET )=0A+        return -EINVAL;=0A+=0A+    addr =
=3D DBGP_EPADDR(devnum, endpoint);=0A+    pids =3D dbgp_pid_write_update(re=
adl(&dbgp->ehci_debug->pids), USB_PID_OUT);=0A+    ctrl =3D dbgp_len_update=
(readl(&dbgp->ehci_debug->control), size);=0A+    if ( pctrl )=0A+        =
*pctrl =3D ctrl;=0A+=0A+    dbgp_set_data(dbgp->ehci_debug, bytes, =
size);=0A+    writel(addr, &dbgp->ehci_debug->address);=0A+    writel(pids,=
 &dbgp->ehci_debug->pids);=0A+    dbgp_issue_command(dbgp, ctrl, dbgp_out);=
=0A+=0A+    return 0;=0A+}=0A+=0A+static int dbgp_bulk_read(struct =
ehci_dbgp *dbgp,=0A+                          unsigned int devnum, =
unsigned int endpoint,=0A+                          unsigned int size, u32 =
*pctrl)=0A+{=0A+    u32 addr, pids, ctrl;=0A+=0A+    if ( size > DBGP_MAX_P=
ACKET )=0A+        return -EINVAL;=0A+=0A+    addr =3D DBGP_EPADDR(devnum, =
endpoint);=0A+    pids =3D dbgp_pid_read_update(readl(&dbgp->ehci_debug->pi=
ds), USB_PID_IN);=0A+    ctrl =3D readl(&dbgp->ehci_debug->control) & =
~DBGP_OUT;=0A+=0A+    writel(addr, &dbgp->ehci_debug->address);=0A+    =
writel(pids, &dbgp->ehci_debug->pids);=0A+    if ( likely(!pctrl) )=0A+    =
    dbgp_issue_command(dbgp, ctrl, dbgp_in);=0A+    else=0A+        =
dbgp_issue_command(dbgp, *pctrl =3D ctrl, dbgp_ctrl);=0A+=0A+    return =
0;=0A+}=0A+=0A+static int dbgp_control_msg(struct ehci_dbgp *dbgp, =
unsigned int devnum,=0A+                            int requesttype, int =
request, int value,=0A+                            int index, void *data, =
unsigned int size)=0A+{=0A+    u32 addr, pids, ctrl;=0A+    struct =
usb_ctrlrequest req;=0A+    bool_t read =3D (requesttype & USB_DIR_IN) =
!=3D 0;=0A+    int ret;=0A+=0A+    if ( size > (read ? DBGP_MAX_PACKET : =
0) )=0A+        return -EINVAL;=0A+=0A+    /* Compute the control message =
*/=0A+    req.bRequestType =3D requesttype;=0A+    req.bRequest =3D =
request;=0A+    req.wValue =3D cpu_to_le16(value);=0A+    req.wIndex =3D =
cpu_to_le16(index);=0A+    req.wLength =3D cpu_to_le16(size);=0A+=0A+    =
pids =3D DBGP_PID_SET(USB_PID_DATA0, USB_PID_SETUP);=0A+    addr =3D =
DBGP_EPADDR(devnum, 0);=0A+    ctrl =3D dbgp_len_update(readl(&dbgp->ehci_d=
ebug->control), sizeof(req));=0A+=0A+    /* Send the setup message */=0A+  =
  dbgp_set_data(dbgp->ehci_debug, &req, sizeof(req));=0A+    writel(addr, =
&dbgp->ehci_debug->address);=0A+    writel(pids, &dbgp->ehci_debug->pids);=
=0A+    dbgp_issue_command(dbgp, ctrl, dbgp_ctrl);=0A+    ret =3D =
dbgp_wait_until_done(dbgp, ctrl, DBGP_LOOPS);=0A+    if ( ret < 0 )=0A+    =
    return ret;=0A+=0A+    /* Read the result */=0A+    ret =3D dbgp_bulk_r=
ead(dbgp, devnum, 0, size, &ctrl);=0A+    if ( !ret )=0A+        ret =3D =
dbgp_wait_until_done(dbgp, ctrl, DBGP_LOOPS);=0A+    if ( ret > 0 )=0A+    =
{=0A+        if ( size > ret )=0A+            size =3D ret;=0A+        =
dbgp_get_data(dbgp->ehci_debug, data, size);=0A+    }=0A+=0A+    return =
ret;=0A+}=0A+=0A+static unsigned int __init __find_dbgp(u8 bus, u8 slot, =
u8 func)=0A+{=0A+    u32 class =3D pci_conf_read32(0, bus, slot, func, =
PCI_CLASS_REVISION);=0A+=0A+    if ( (class >> 8) !=3D PCI_CLASS_SERIAL_USB=
_EHCI )=0A+        return 0;=0A+=0A+    return pci_find_cap_offset(0, bus, =
slot, func, PCI_CAP_ID_EHCI_DEBUG);=0A+}=0A+=0A+static unsigned int __init =
find_dbgp(struct ehci_dbgp *dbgp,=0A+                                     =
unsigned int ehci_num)=0A+{=0A+    unsigned int bus, slot, func;=0A+=0A+   =
 for ( bus =3D 0; bus < 256; bus++ )=0A+    {=0A+        for ( slot =3D 0; =
slot < 32; slot++ )=0A+        {=0A+            for ( func =3D 0; func < =
8; func++ )=0A+            {=0A+                unsigned int cap;=0A+=0A+  =
              if ( !pci_device_detect(0, bus, slot, func) )=0A+            =
    {=0A+                    if ( !func )=0A+                        =
break;=0A+                    continue;=0A+                }=0A+=0A+       =
         cap =3D __find_dbgp(bus, slot, func);=0A+                if ( =
!cap || ehci_num-- )=0A+                {=0A+                    if ( =
!func && !(pci_conf_read8(0, bus, slot, func,=0A+                          =
                         PCI_HEADER_TYPE) & 0x80) )=0A+                    =
    break;=0A+                    continue;=0A+                }=0A+=0A+   =
             dbgp->bus =3D bus;=0A+                dbgp->slot =3D =
slot;=0A+                dbgp->func =3D func;=0A+                return =
cap;=0A+            }=0A+        }=0A+    }=0A+=0A+    return 0;=0A+}=0A+=
=0A+static int ehci_dbgp_startup(struct ehci_dbgp *dbgp)=0A+{=0A+    u32 =
ctrl, cmd, status;=0A+    unsigned int loop;=0A+=0A+    /* Claim ownership,=
 but do not enable yet */=0A+    ctrl =3D readl(&dbgp->ehci_debug->control)=
;=0A+    ctrl |=3D DBGP_OWNER;=0A+    ctrl &=3D ~(DBGP_ENABLED | DBGP_INUSE=
);=0A+    writel(ctrl, &dbgp->ehci_debug->control);=0A+    udelay(1);=0A+=
=0A+    ehci_dbgp_status(dbgp, "EHCI startup");=0A+    /* Start the EHCI. =
*/=0A+    cmd =3D readl(&dbgp->ehci_regs->command);=0A+    cmd &=3D =
~(CMD_LRESET | CMD_IAAD | CMD_PSE | CMD_ASE | CMD_RESET);=0A+    cmd |=3D =
CMD_RUN;=0A+    writel(cmd, &dbgp->ehci_regs->command);=0A+=0A+    /* =
Ensure everything is routed to the EHCI */=0A+    writel(FLAG_CF, =
&dbgp->ehci_regs->configured_flag);=0A+=0A+    /* Wait until the controller=
 is no longer halted. */=0A+    loop =3D 1000;=0A+    do {=0A+        =
status =3D readl(&dbgp->ehci_regs->status);=0A+        if ( !(status & =
STS_HALT) )=0A+            break;=0A+        udelay(1);=0A+    } while ( =
--loop );=0A+=0A+    if ( !loop )=0A+    {=0A+        dbgp_printk("EHCI =
cannot be started\n");=0A+        return -ENODEV;=0A+    }=0A+    =
dbgp_printk("EHCI started\n");=0A+=0A+    return 0;=0A+}=0A+=0A+static int =
ehci_dbgp_controller_reset(struct ehci_dbgp *dbgp)=0A+{=0A+    unsigned =
int loop =3D 250 * 1000;=0A+    u32 cmd;=0A+=0A+    /* Reset the EHCI =
controller */=0A+    cmd =3D readl(&dbgp->ehci_regs->command);=0A+    cmd =
|=3D CMD_RESET;=0A+    writel(cmd, &dbgp->ehci_regs->command);=0A+    do =
{=0A+        cmd =3D readl(&dbgp->ehci_regs->command);=0A+    } while ( =
(cmd & CMD_RESET) && --loop );=0A+=0A+    if ( !loop )=0A+    {=0A+        =
dbgp_printk("cannot reset EHCI\n");=0A+        return -1;=0A+    }=0A+    =
ehci_dbgp_status(dbgp, "ehci reset done");=0A+=0A+    return 0;=0A+}=0A+=0A=
+static int ehci_reset_port(struct ehci_dbgp *dbgp, unsigned int port)=0A+{=
=0A+    u32 portsc, delay_time, delay;=0A+=0A+    ehci_dbgp_status(dbgp, =
"reset port");=0A+    /* Reset the USB debug port. */=0A+    portsc =3D =
readl(&dbgp->ehci_regs->port_status[port - 1]);=0A+    portsc &=3D =
~PORT_PE;=0A+    portsc |=3D PORT_RESET;=0A+    writel(portsc, &dbgp->ehci_=
regs->port_status[port - 1]);=0A+=0A+    delay =3D HUB_ROOT_RESET_TIME;=0A+=
    for ( delay_time =3D 0; delay_time < HUB_RESET_TIMEOUT;=0A+          =
delay_time +=3D delay )=0A+    {=0A+        dbgp_mdelay(delay);=0A+        =
portsc =3D readl(&dbgp->ehci_regs->port_status[port - 1]);=0A+        if =
(!(portsc & PORT_RESET))=0A+            break;=0A+    }=0A+=0A+    if ( =
portsc & PORT_RESET )=0A+    {=0A+        /* force reset to complete =
*/=0A+        unsigned int loop =3D 100 * 1000;=0A+=0A+        writel(ports=
c & ~(PORT_RWC_BITS | PORT_RESET),=0A+               &dbgp->ehci_regs->port=
_status[port - 1]);=0A+        do {=0A+            udelay(1);=0A+          =
  portsc =3D readl(&dbgp->ehci_regs->port_status[port-1]);=0A+        } =
while ( (portsc & PORT_RESET) && --loop );=0A+    }=0A+=0A+    /* Device =
went away? */=0A+    if ( !(portsc & PORT_CONNECT) )=0A+        return =
-ENOTCONN;=0A+=0A+    /* bomb out completely if something weird happened =
*/=0A+    if ( portsc & PORT_CSC )=0A+        return -EINVAL;=0A+=0A+    =
/* If we've finished resetting, then break out of the loop */=0A+    if ( =
!(portsc & PORT_RESET) && (portsc & PORT_PE) )=0A+        return 0;=0A+=0A+=
    return -EBUSY;=0A+}=0A+=0A+static int ehci_wait_for_port(struct =
ehci_dbgp *dbgp, unsigned int port)=0A+{=0A+    u32 status;=0A+    =
unsigned int reps;=0A+=0A+    for ( reps =3D 0; reps < 300; reps++ )=0A+   =
 {=0A+        status =3D readl(&dbgp->ehci_regs->status);=0A+        if ( =
status & STS_PCD )=0A+            break;=0A+        dbgp_mdelay(1);=0A+    =
}=0A+=0A+    return ehci_reset_port(dbgp, port) =3D=3D 0 ? 0 : -ENOTCONN;=
=0A+}=0A+=0A+/* Return 0 on success=0A+ * Return -ENODEV for any general =
failure=0A+ * Return -EIO if wait for port fails=0A+ */=0A+static int =
ehci_dbgp_external_startup(struct ehci_dbgp *dbgp)=0A+{=0A+    unsigned =
int devnum;=0A+    struct usb_debug_descriptor dbgp_desc;=0A+    int =
ret;=0A+    u32 ctrl, portsc, cmd;=0A+    unsigned int dbg_port =3D =
dbgp->phys_port;=0A+    unsigned int tries =3D 3;=0A+    unsigned int =
reset_port_tries =3D 1;=0A+    bool_t try_hard_once =3D 1;=0A+=0A+try_port_=
reset_again:=0A+    ret =3D ehci_dbgp_startup(dbgp);=0A+    if ( ret )=0A+ =
       return ret;=0A+=0A+    /* Wait for a device to show up in the debug =
port */=0A+    ret =3D ehci_wait_for_port(dbgp, dbg_port);=0A+    if ( ret =
< 0 )=0A+    {=0A+        portsc =3D readl(&dbgp->ehci_regs->port_status[db=
g_port - 1]);=0A+        if ( !(portsc & PORT_CONNECT) && try_hard_once =
)=0A+        {=0A+            /*=0A+             * Last ditch effort to =
try to force enable the debug device by=0A+             * using the packet =
test EHCI command to try and wake it up.=0A+             */=0A+            =
try_hard_once =3D 0;=0A+            cmd =3D readl(&dbgp->ehci_regs->command=
);=0A+            cmd &=3D ~CMD_RUN;=0A+            writel(cmd, &dbgp->ehci=
_regs->command);=0A+            portsc =3D readl(&dbgp->ehci_regs->port_sta=
tus[dbg_port - 1]);=0A+            portsc |=3D PORT_TEST_PKT;=0A+          =
  writel(portsc, &dbgp->ehci_regs->port_status[dbg_port - 1]);=0A+         =
   ehci_dbgp_status(dbgp, "Trying to force debug port online");=0A+        =
    mdelay(50);=0A+            ehci_dbgp_controller_reset(dbgp);=0A+       =
     goto try_port_reset_again;=0A+        }=0A+        else if ( =
reset_port_tries-- )=0A+            goto try_port_reset_again;=0A+        =
dbgp_printk("no device found in debug port\n");=0A+        return =
-EIO;=0A+    }=0A+    ehci_dbgp_status(dbgp, "wait for port done");=0A+=0A+=
    /* Enable the debug port */=0A+    ctrl =3D readl(&dbgp->ehci_debug->co=
ntrol);=0A+    ctrl |=3D DBGP_CLAIM;=0A+    writel(ctrl, &dbgp->ehci_debug-=
>control);=0A+    ctrl =3D readl(&dbgp->ehci_debug->control);=0A+    if ( =
(ctrl & DBGP_CLAIM) !=3D DBGP_CLAIM )=0A+    {=0A+        dbgp_printk("no =
device in debug port\n");=0A+        writel(ctrl & ~DBGP_CLAIM, &dbgp->ehci=
_debug->control);=0A+        return -ENODEV;=0A+    }=0A+    ehci_dbgp_stat=
us(dbgp, "debug port enabled");=0A+=0A+    /* Completely transfer the =
debug device to the debug controller */=0A+    portsc =3D readl(&dbgp->ehci=
_regs->port_status[dbg_port - 1]);=0A+    portsc &=3D ~PORT_PE;=0A+    =
writel(portsc, &dbgp->ehci_regs->port_status[dbg_port - 1]);=0A+=0A+    =
dbgp_mdelay(100);=0A+=0A+try_again:=0A+    /* Find the debug device and =
make it device number 127 */=0A+    for ( devnum =3D 0; devnum <=3D 127; =
devnum++ )=0A+    {=0A+        ret =3D dbgp_control_msg(dbgp, devnum,=0A+  =
                             USB_DIR_IN | USB_TYPE_STANDARD | USB_RECIP_DEV=
ICE,=0A+                               USB_REQ_GET_DESCRIPTOR, (USB_DT_DEBU=
G << 8), 0,=0A+                               &dbgp_desc, sizeof(dbgp_desc)=
);=0A+        if ( ret > 0 )=0A+            break;=0A+    }=0A+    if ( =
devnum > 127 )=0A+    {=0A+        dbgp_printk("could not find attached =
debug device\n");=0A+        goto err;=0A+    }=0A+    if ( ret < 0 )=0A+  =
  {=0A+        dbgp_printk("attached device is not a debug device\n");=0A+ =
       goto err;=0A+    }=0A+    dbgp->out.endpoint =3D dbgp_desc.bDebugOut=
Endpoint;=0A+    dbgp->in.endpoint =3D dbgp_desc.bDebugInEndpoint;=0A+=0A+ =
   /* Move the device to 127 if it isn't already there. */=0A+    if ( =
devnum !=3D USB_DEBUG_DEVNUM )=0A+    {=0A+        ret =3D dbgp_control_msg=
(dbgp, devnum,=0A+                               USB_DIR_OUT | USB_TYPE_STA=
NDARD | USB_RECIP_DEVICE,=0A+                               USB_REQ_SET_ADD=
RESS, USB_DEBUG_DEVNUM, 0, NULL, 0);=0A+        if ( ret < 0 )=0A+        =
{=0A+            dbgp_printk("could not move attached device to %d\n",=0A+ =
                       USB_DEBUG_DEVNUM);=0A+            goto err;=0A+     =
   }=0A+        devnum =3D USB_DEBUG_DEVNUM;=0A+        dbgp_printk("debug =
device renamed to 127\n");=0A+    }=0A+=0A+    /* Enable the debug =
interface */=0A+    ret =3D dbgp_control_msg(dbgp, USB_DEBUG_DEVNUM,=0A+   =
                        USB_DIR_OUT | USB_TYPE_STANDARD | USB_RECIP_DEVICE,=
=0A+                           USB_REQ_SET_FEATURE, USB_DEVICE_DEBUG_MODE,=
=0A+                           0, NULL, 0);=0A+    if ( ret < 0 )=0A+    =
{=0A+        dbgp_printk("could not enable the debug device\n");=0A+       =
 goto err;=0A+    }=0A+    dbgp_printk("debug interface enabled\n");=0A+=0A=
+    /* Perform a small write to get the even/odd data state in sync. =
*/=0A+    ret =3D dbgp_bulk_write(dbgp, USB_DEBUG_DEVNUM, dbgp->out.endpoin=
t,=0A+                          "\n", 1, &ctrl);=0A+    if ( !ret )=0A+    =
    ret =3D dbgp_wait_until_done(dbgp, ctrl, DBGP_LOOPS);=0A+    if ( ret =
< 0 )=0A+    {=0A+        dbgp_printk("dbgp_bulk_write failed: %d\n", =
ret);=0A+        goto err;=0A+    }=0A+    dbgp_printk("small write =
done\n");=0A+    dbgp->state =3D dbgp_idle;=0A+=0A+    return 0;=0A+err:=0A=
+    if ( tries-- )=0A+        goto try_again;=0A+    return -ENODEV;=0A+}=
=0A+=0A+typedef void (*set_debug_port_t)(struct ehci_dbgp *, unsigned =
int);=0A+=0A+static void default_set_debug_port(struct ehci_dbgp *dbgp, =
unsigned int port)=0A+{=0A+}=0A+=0A+static set_debug_port_t __read_mostly =
set_debug_port =3D default_set_debug_port;=0A+=0A+static void nvidia_set_de=
bug_port(struct ehci_dbgp *dbgp, unsigned int port)=0A+{=0A+    u32 dword =
=3D pci_conf_read32(0, dbgp->bus, dbgp->slot, dbgp->func, 0x74);=0A+=0A+   =
 dword &=3D ~(0x0f << 12);=0A+    dword |=3D (port & 0x0f) << 12;=0A+    =
pci_conf_write32(0, dbgp->bus, dbgp->slot, dbgp->func, 0x74, dword);=0A+   =
 dbgp_printk("set debug port to %u\n", port);=0A+}=0A+=0A+static void =
__init detect_set_debug_port(struct ehci_dbgp *dbgp)=0A+{=0A+    if ( =
pci_conf_read16(0, dbgp->bus, dbgp->slot, dbgp->func,=0A+                  =
       PCI_VENDOR_ID) =3D=3D 0x10de )=0A+    {=0A+        dbgp_printk("usin=
g nvidia set_debug_port\n");=0A+        set_debug_port =3D nvidia_set_debug=
_port;=0A+    }=0A+}=0A+=0A+/*=0A+ * The code in ehci_dbgp_bios_handoff() =
is derived from the USB PCI=0A+ * quirk initialization in Linux.=0A+ =
*/=0A+#define EHCI_USBLEGSUP_BIOS    (1 << 16) /* BIOS semaphore */=0A+#def=
ine EHCI_USBLEGCTLSTS      4        /* legacy control/status */=0A+static =
void ehci_dbgp_bios_handoff(struct ehci_dbgp *dbgp, u32 hcc_params)=0A+{=0A=
+    u32 cap;=0A+    unsigned int offset =3D HCC_EXT_CAPS(hcc_params);=0A+ =
   int msec;=0A+=0A+    if ( !offset )=0A+        return;=0A+=0A+    cap =
=3D pci_conf_read32(0, dbgp->bus, dbgp->slot, dbgp->func, offset);=0A+    =
dbgp_printk("dbgp: EHCI BIOS state %08x\n", cap);=0A+=0A+    if ( (cap & =
0xff) =3D=3D 1 && (cap & EHCI_USBLEGSUP_BIOS) )=0A+    {=0A+        =
dbgp_printk("dbgp: BIOS handoff\n");=0A+        pci_conf_write8(0, =
dbgp->bus, dbgp->slot, dbgp->func, offset + 3, 1);=0A+    }=0A+=0A+    /* =
if boot firmware now owns EHCI, spin till it hands it over. */=0A+    msec =
=3D 1000;=0A+    while ( (cap & EHCI_USBLEGSUP_BIOS) && (msec > 0) )=0A+   =
 {=0A+        mdelay(10);=0A+        msec -=3D 10;=0A+        cap =3D =
pci_conf_read32(0, dbgp->bus, dbgp->slot, dbgp->func, offset);=0A+    =
}=0A+=0A+    if ( cap & EHCI_USBLEGSUP_BIOS )=0A+    {=0A+        /* well, =
possibly buggy BIOS... try to shut it down,=0A+         * and hope nothing =
goes too wrong */=0A+        dbgp_printk("dbgp: BIOS handoff failed: =
%08x\n", cap);=0A+        pci_conf_write8(0, dbgp->bus, dbgp->slot, =
dbgp->func, offset + 2, 0);=0A+    }=0A+=0A+    /* just in case, always =
disable EHCI SMIs */=0A+    pci_conf_write8(0, dbgp->bus, dbgp->slot, =
dbgp->func,=0A+                    offset + EHCI_USBLEGCTLSTS, 0);=0A+}=0A+=
=0A+static int ehci_dbgp_setup(struct ehci_dbgp *dbgp)=0A+{=0A+    u32 =
ctrl, portsc, hcs_params;=0A+    unsigned int i, debug_port, new_debug_port=
 =3D 0, n_ports;=0A+    unsigned int port_map_tried, playtimes =3D 3;=0A+  =
  int ret;=0A+=0A+    ehci_dbgp_bios_handoff(dbgp, readl(&dbgp->ehci_caps->=
hcc_params));=0A+=0A+try_next_time:=0A+    port_map_tried =3D 0;=0A+=0A+try=
_next_port:=0A+=0A+    hcs_params =3D readl(&dbgp->ehci_caps->hcs_params);=
=0A+    debug_port =3D HCS_DEBUG_PORT(hcs_params);=0A+    dbgp->phys_port =
=3D debug_port;=0A+    n_ports =3D HCS_N_PORTS(hcs_params);=0A+=0A+    =
dbgp_printk("debug_port: %u\n", debug_port);=0A+    dbgp_printk("n_ports:  =
  %u\n", n_ports);=0A+    ehci_dbgp_status(dbgp, "");=0A+=0A+    for ( i =
=3D 1; i <=3D n_ports; i++ )=0A+    {=0A+        portsc =3D readl(&dbgp->eh=
ci_regs->port_status[i-1]);=0A+        dbgp_printk("portstatus%d: %08x\n", =
i, portsc);=0A+    }=0A+=0A+    if ( port_map_tried && (new_debug_port =
!=3D debug_port) )=0A+    {=0A+        if ( --playtimes )=0A+        {=0A+ =
           set_debug_port(dbgp, new_debug_port);=0A+            goto =
try_next_time;=0A+        }=0A+        return -1;=0A+    }=0A+=0A+    /* =
Only reset the controller if it is not already in the=0A+     * configured =
state */=0A+    if ( readl(&dbgp->ehci_regs->configured_flag) & FLAG_CF =
)=0A+        ehci_dbgp_status(dbgp, "ehci skip - already configured");=0A+ =
   else if ( ehci_dbgp_controller_reset(dbgp) !=3D 0 )=0A+        return =
-1;=0A+=0A+    ret =3D ehci_dbgp_external_startup(dbgp);=0A+    if (ret =
=3D=3D -EIO)=0A+        goto next_debug_port;=0A+=0A+    if ( ret < 0 =
)=0A+    {=0A+        /* Things didn't work so remove my claim */=0A+      =
  ctrl =3D readl(&dbgp->ehci_debug->control);=0A+        ctrl &=3D =
~(DBGP_CLAIM | DBGP_OUT);=0A+        writel(ctrl, &dbgp->ehci_debug->contro=
l);=0A+        return -1;=0A+    }=0A+=0A+    return 0;=0A+=0A+next_debug_p=
ort:=0A+    port_map_tried |=3D 1 << (debug_port - 1);=0A+    new_debug_por=
t =3D (debug_port % n_ports) + 1;=0A+    if ( port_map_tried !=3D ((1 << =
n_ports) - 1) )=0A+    {=0A+        set_debug_port(dbgp, new_debug_port);=
=0A+        goto try_next_port;=0A+    }=0A+    if ( --playtimes )=0A+    =
{=0A+        set_debug_port(dbgp, new_debug_port);=0A+        goto =
try_next_time;=0A+    }=0A+=0A+    return -1;=0A+}=0A+=0A+static inline =
void _ehci_dbgp_flush(struct ehci_dbgp *dbgp)=0A+{=0A+    if ( dbgp_bulk_wr=
ite(dbgp, USB_DEBUG_DEVNUM, dbgp->out.endpoint,=0A+                        =
 dbgp->out.buf, dbgp->out.chunk, NULL) )=0A+        BUG();=0A+    =
dbgp->out.chunk =3D 0;=0A+}=0A+=0A+static void ehci_dbgp_flush(struct =
serial_port *port)=0A+{=0A+    struct ehci_dbgp *dbgp =3D port->uart;=0A+  =
  s_time_t goal;=0A+=0A+    if ( !dbgp->out.chunk || !dbgp->ehci_debug || =
dbgp->state =3D=3D dbgp_unsafe )=0A+        return;=0A+=0A+    if ( =
dbgp->state =3D=3D dbgp_idle || !port->sync )=0A+        dbgp_check_for_com=
pletion(dbgp, 1, NULL);=0A+    else=0A+        dbgp_wait_until_complete(dbg=
p, NULL);=0A+=0A+    if ( dbgp->state =3D=3D dbgp_idle )=0A+    {=0A+      =
  _ehci_dbgp_flush(dbgp);=0A+=0A+        if ( port->sync )=0A+        =
{=0A+            dbgp_wait_until_complete(dbgp, NULL);=0A+            =
return;=0A+        }=0A+    }=0A+=0A+    goal =3D NOW() + MICROSECS(DBGP_CH=
ECK_INTERVAL);=0A+    if ( dbgp->timer.expires > goal )=0A+       =
set_timer(&dbgp->timer, goal);=0A+}=0A+=0A+static void ehci_dbgp_putc(struc=
t serial_port *port, char c)=0A+{=0A+    struct ehci_dbgp *dbgp =3D =
port->uart;=0A+=0A+    if ( unlikely(dbgp->out.chunk >=3D DBGP_MAX_PACKET) =
)=0A+        return;=0A+=0A+    dbgp->out.buf[dbgp->out.chunk++] =3D =
c;=0A+=0A+    if ( dbgp->out.chunk =3D=3D DBGP_MAX_PACKET )=0A+        =
ehci_dbgp_flush(port);=0A+}=0A+=0A+static int ehci_dbgp_tx_empty(struct =
serial_port *port)=0A+{=0A+    struct ehci_dbgp *dbgp =3D port->uart;=0A+=
=0A+    if ( unlikely(!dbgp->ehci_debug) || unlikely(dbgp->state =3D=3D =
dbgp_unsafe) )=0A+        return port->sync || port->tx_log_everything || =
!port->txbuf;=0A+=0A+    if ( dbgp->out.chunk =3D=3D DBGP_MAX_PACKET )=0A+ =
       ehci_dbgp_flush(port);=0A+    else=0A+        dbgp_check_for_complet=
ion(dbgp, 1, NULL);=0A+=0A+    if ( dbgp->state !=3D dbgp_idle && =
dbgp->out.chunk >=3D DBGP_MAX_PACKET )=0A+        return 0;=0A+=0A+    =
port->tx_fifo_size =3D DBGP_MAX_PACKET - dbgp->out.chunk;=0A+    if ( =
dbgp->state =3D=3D dbgp_idle )=0A+        port->tx_fifo_size +=3D =
DBGP_MAX_PACKET;=0A+=0A+    return 1;=0A+}=0A+=0A+static int ehci_dbgp_getc=
(struct serial_port *port, char *pc)=0A+{=0A+    struct ehci_dbgp *dbgp =
=3D port->uart;=0A+=0A+    if ( !dbgp->in.chunk )=0A+        return =
0;=0A+=0A+    *pc =3D *dbgp->in.buf;=0A+    if ( --dbgp->in.chunk )=0A+    =
    memmove(dbgp->in.buf, dbgp->in.buf + 1, dbgp->in.chunk);=0A+=0A+    =
return 1;=0A+}=0A+=0A+/* Safe: ehci_dbgp_poll() runs as timer handler, so =
not reentrant. */=0A+static struct serial_port *poll_port;=0A+=0A+static =
void _ehci_dbgp_poll(struct cpu_user_regs *regs)=0A+{=0A+    struct =
serial_port *port =3D poll_port;=0A+    struct ehci_dbgp *dbgp =3D =
port->uart;=0A+    unsigned long flags;=0A+    unsigned int timeout =3D =
MICROSECS(DBGP_CHECK_INTERVAL);=0A+    bool_t empty =3D 0;=0A+=0A+    if ( =
!dbgp->ehci_debug )=0A+        return;=0A+=0A+    if ( spin_trylock_irqsave=
(&port->tx_lock, flags) )=0A+    {=0A+        if ( dbgp->state !=3D =
dbgp_unsafe )=0A+            dbgp_check_for_completion(dbgp, DBGP_CHECK_INT=
ERVAL, NULL);=0A+        if ( dbgp->state =3D=3D dbgp_idle && dbgp->out.chu=
nk )=0A+            _ehci_dbgp_flush(dbgp);=0A+        if ( dbgp->state =
=3D=3D dbgp_idle || dbgp->out.chunk < DBGP_MAX_PACKET )=0A+            =
empty =3D 1;=0A+        spin_unlock_irqrestore(&port->tx_lock, flags);=0A+ =
   }=0A+=0A+    if ( dbgp->in.chunk )=0A+        serial_rx_interrupt(port, =
regs);=0A+=0A+    if ( empty )=0A+        serial_tx_interrupt(port, =
regs);=0A+=0A+    if ( spin_trylock_irqsave(&port->tx_lock, flags) )=0A+   =
 {=0A+        if ( dbgp->state =3D=3D dbgp_idle && !dbgp->in.chunk &&=0A+  =
           !dbgp->out.chunk && port->txbufp =3D=3D port->txbufc )=0A+      =
  {=0A+            if ( dbgp_bulk_read(dbgp, USB_DEBUG_DEVNUM, dbgp->in.end=
point,=0A+                                DBGP_MAX_PACKET, NULL) )=0A+     =
           BUG();=0A+            timeout =3D MILLISECS(DBGP_IDLE_INTERVAL);=
=0A+        }=0A+        spin_unlock_irqrestore(&port->tx_lock, flags);=0A+=
    }=0A+=0A+    set_timer(&dbgp->timer, NOW() + timeout);=0A+}=0A+=0A+stat=
ic void ehci_dbgp_poll(void *data)=0A+{=0A+    poll_port =3D data;=0A+#ifde=
f run_in_exception_handler=0A+    run_in_exception_handler(_ehci_dbgp_poll)=
;=0A+#else=0A+    _ehci_dbgp_poll(guest_cpu_user_regs());=0A+#endif=0A+}=0A=
+=0A+static bool_t ehci_dbgp_setup_preirq(struct ehci_dbgp *dbgp)=0A+{=0A+ =
   if ( !ehci_dbgp_setup(dbgp) )=0A+        return 1;=0A+=0A+    dbgp_print=
k("ehci_dbgp_setup failed\n");=0A+    dbgp->ehci_debug =3D NULL;=0A+    =
return 0;=0A+}=0A+=0A+static void __init ehci_dbgp_init_preirq(struct =
serial_port *port)=0A+{=0A+    struct ehci_dbgp *dbgp =3D port->uart;=0A+  =
  u32 debug_port, offset;=0A+    void __iomem *ehci_bar;=0A+=0A+    =
debug_port =3D pci_conf_read32(0, dbgp->bus, dbgp->slot, dbgp->func,=0A+   =
                              dbgp->cap);=0A+    offset =3D (debug_port >> =
16) & 0xfff;=0A+=0A+    /* double check if the mem space is enabled */=0A+ =
   dbgp->pci_cr =3D pci_conf_read8(0, dbgp->bus, dbgp->slot, dbgp->func,=0A=
+                                  PCI_COMMAND);=0A+    if ( !(dbgp->pci_cr=
 & PCI_COMMAND_MEMORY) )=0A+    {=0A+        dbgp->pci_cr |=3D PCI_COMMAND_=
MEMORY;=0A+        pci_conf_write16(0, dbgp->bus, dbgp->slot, dbgp->func, =
PCI_COMMAND,=0A+                         dbgp->pci_cr);=0A+        =
dbgp_printk("MMIO for EHCI enabled\n");=0A+    }=0A+=0A+    /*=0A+     * =
FIXME I don't have the bar size so just guess PAGE_SIZE is more=0A+     * =
than enough.  1k is the biggest that was seen.=0A+     */=0A+    set_fixmap=
_nocache(FIX_EHCI_DBGP, dbgp->bar_val);=0A+    ehci_bar =3D (void __iomem =
*)fix_to_virt(FIX_EHCI_DBGP);=0A+    ehci_bar +=3D dbgp->bar_val & =
~PAGE_MASK;=0A+    dbgp_printk("ehci_bar: %p\n", ehci_bar);=0A+=0A+    =
dbgp->ehci_caps =3D ehci_bar;=0A+    dbgp->ehci_regs =3D ehci_bar +=0A+    =
                  HC_LENGTH(readl(&dbgp->ehci_caps->hc_capbase));=0A+    =
dbgp->ehci_debug =3D ehci_bar + offset;=0A+=0A+    detect_set_debug_port(db=
gp);=0A+=0A+    if ( ehci_dbgp_setup_preirq(dbgp) )=0A+        ehci_dbgp_st=
atus(dbgp, "ehci_dbgp_init_preirq complete");=0A+=0A+    port->tx_fifo_size=
 =3D DBGP_MAX_PACKET;=0A+    dbgp->lock =3D &port->tx_lock;=0A+}=0A+=0A+sta=
tic void ehci_dbgp_setup_postirq(struct ehci_dbgp *dbgp)=0A+{=0A+    =
set_timer(&dbgp->timer, NOW() + MILLISECS(1));=0A+}=0A+=0A+static void =
__init ehci_dbgp_init_postirq(struct serial_port *port)=0A+{=0A+    struct =
ehci_dbgp *dbgp =3D port->uart;=0A+=0A+    if ( !dbgp->ehci_debug )=0A+    =
    return;=0A+=0A+    serial_async_transmit(port);=0A+=0A+    init_timer(&=
dbgp->timer, ehci_dbgp_poll, port, 0);=0A+=0A+    ehci_dbgp_setup_postirq(d=
bgp);=0A+}=0A+=0A+static int ehci_dbgp_check_release(struct ehci_dbgp =
*dbgp)=0A+{=0A+    struct ehci_dbg_port __iomem *ehci_debug =3D dbgp->ehci_=
debug;=0A+    u32 ctrl;=0A+    unsigned int i;=0A+=0A+    if ( !ehci_debug =
)=0A+        return 0;=0A+=0A+    for ( i =3D 0; i < DBGP_MAX_PACKET; ++i =
)=0A+        if ( dbgp->out.buf[i] )=0A+            return 1;=0A+=0A+    =
/*=0A+     * This means the console is not initialized, or should get =
shutdown=0A+     * so as to allow for reuse of the USB device, which means =
it is time=0A+     * to shutdown the USB debug port.=0A+     */=0A+    =
printk(XENLOG_INFO "Releasing EHCI debug port at %02x:%02x.%u\n",=0A+      =
     dbgp->bus, dbgp->slot, dbgp->func);=0A+=0A+    kill_timer(&dbgp->timer=
);=0A+    dbgp->ehci_debug =3D NULL;=0A+=0A+    ctrl =3D readl(&ehci_debug-=
>control);=0A+    if ( ctrl & DBGP_ENABLED )=0A+    {=0A+        ctrl &=3D =
~DBGP_CLAIM;=0A+        writel(ctrl, &ehci_debug->control);=0A+    =
}=0A+=0A+    return 0;=0A+}=0A+=0A+static void __init ehci_dbgp_endboot(str=
uct serial_port *port)=0A+{=0A+    ehci_dbgp_check_release(port->uart);=0A+=
}=0A+=0A+static void ehci_dbgp_suspend(struct serial_port *port)=0A+{=0A+  =
  struct ehci_dbgp *dbgp =3D port->uart;=0A+=0A+    if ( !dbgp->ehci_debug =
)=0A+        return;=0A+=0A+    stop_timer(&dbgp->timer);=0A+    dbgp->time=
r.expires =3D 0;=0A+=0A+    dbgp->pci_cr =3D pci_conf_read16(0, dbgp->bus, =
dbgp->slot, dbgp->func,=0A+                                   PCI_COMMAND);=
=0A+=0A+    dbgp->state =3D dbgp_unsafe;=0A+}=0A+=0A+static void ehci_dbgp_=
resume(struct serial_port *port)=0A+{=0A+    struct ehci_dbgp *dbgp =3D =
port->uart;=0A+=0A+    if ( !dbgp->ehci_debug )=0A+        return;=0A+=0A+ =
   pci_conf_write32(0, dbgp->bus, dbgp->slot, dbgp->func, dbgp->bar,=0A+   =
                  dbgp->bar_val);=0A+    pci_conf_write16(0, dbgp->bus, =
dbgp->slot, dbgp->func,=0A+                     PCI_COMMAND, dbgp->pci_cr);=
=0A+=0A+    ehci_dbgp_setup_preirq(dbgp);=0A+    ehci_dbgp_setup_postirq(db=
gp);=0A+}=0A+=0A+static struct uart_driver __read_mostly ehci_dbgp_driver =
=3D {=0A+    .init_preirq  =3D ehci_dbgp_init_preirq,=0A+    .init_postirq =
=3D ehci_dbgp_init_postirq,=0A+    .endboot      =3D ehci_dbgp_endboot,=0A+=
    .suspend      =3D ehci_dbgp_suspend,=0A+    .resume       =3D =
ehci_dbgp_resume,=0A+    .tx_empty     =3D ehci_dbgp_tx_empty,=0A+    =
.putc         =3D ehci_dbgp_putc,=0A+    .flush        =3D ehci_dbgp_flush,=
=0A+    .getc         =3D ehci_dbgp_getc=0A+};=0A+=0A+static struct =
ehci_dbgp ehci_dbgp =3D { .state =3D dbgp_unsafe, .phys_port =3D 1 =
};=0A+=0A+static char __initdata opt_dbgp[30];=0A+string_param("dbgp", =
opt_dbgp);=0A+=0A+void __init ehci_dbgp_init(void)=0A+{=0A+    struct =
ehci_dbgp *dbgp =3D &ehci_dbgp;=0A+    u32 debug_port, offset, bar_val;=0A+=
    const char *e;=0A+=0A+    if ( strncmp(opt_dbgp, "ehci", 4) )=0A+      =
  return;=0A+=0A+    if ( isdigit(opt_dbgp[4]) || !opt_dbgp[4] )=0A+    =
{=0A+        unsigned int num =3D 0;=0A+=0A+        if ( opt_dbgp[4] )=0A+ =
           simple_strtoul(opt_dbgp + 4, &e, 10);=0A+=0A+        dbgp->cap =
=3D find_dbgp(dbgp, num);=0A+        if ( !dbgp->cap )=0A+            =
return;=0A+=0A+        dbgp_printk("Found EHCI debug port on %02x:%02x.%u\n=
",=0A+                    dbgp->bus, dbgp->slot, dbgp->func);=0A+    }=0A+ =
   else if ( strncmp(opt_dbgp + 4, "@pci", 4) =3D=3D 0 )=0A+    {=0A+      =
  unsigned long val =3D simple_strtoul(opt_dbgp + 8, &e, 16);=0A+=0A+      =
  dbgp->bus =3D val;=0A+        if ( dbgp->bus !=3D val || *e !=3D ':' =
)=0A+            return;=0A+=0A+        val =3D simple_strtoul(e + 1, &e, =
16);=0A+        if ( PCI_SLOT(PCI_DEVFN(val, 0)) !=3D val || *e !=3D '.' =
)=0A+            return;=0A+        dbgp->slot =3D val;=0A+=0A+        val =
=3D simple_strtoul(e + 1, &e, 16);=0A+        if ( PCI_FUNC(PCI_DEVFN(0, =
val)) !=3D val || *e )=0A+            return;=0A+        dbgp->func =3D =
val;=0A+=0A+        if ( !pci_device_detect(0, dbgp->bus, dbgp->slot, =
dbgp->func) )=0A+            return;=0A+=0A+        dbgp->cap =3D =
__find_dbgp(dbgp->bus, dbgp->slot, dbgp->func);=0A+        if ( !dbgp->cap =
)=0A+            return;=0A+=0A+        dbgp_printk("Using EHCI debug port =
on %02x:%02x.%u\n",=0A+                    dbgp->bus, dbgp->slot, =
dbgp->func);=0A+    }=0A+    else=0A+        return;=0A+=0A+    debug_port =
=3D pci_conf_read32(0, dbgp->bus, dbgp->slot, dbgp->func,=0A+              =
                   dbgp->cap);=0A+    dbgp->bar =3D (debug_port >> 29) & =
0x7;=0A+    dbgp->bar =3D ((dbgp->bar - 1) * 4) + PCI_BASE_ADDRESS_0;=0A+  =
  offset =3D (debug_port >> 16) & 0xfff;=0A+    dbgp_printk("bar: %02x =
offset: %03x\n", dbgp->bar, offset);=0A+    if ( dbgp->bar < PCI_BASE_ADDRE=
SS_0 || dbgp->bar > PCI_BASE_ADDRESS_5 )=0A+    {=0A+        dbgp_printk("u=
nsupported/invalid bar\n");=0A+        return;=0A+    }=0A+=0A+    =
dbgp->bar_val =3D bar_val =3D pci_conf_read32(0, dbgp->bus, dbgp->slot,=0A+=
                                              dbgp->func, dbgp->bar);=0A+  =
  dbgp_printk("bar_val: %08x\n", bar_val);=0A+    if ( bar_val & ~PCI_BASE_=
ADDRESS_MEM_MASK )=0A+    {=0A+        dbgp_printk("only simple 32-bit =
MMIO BARs supported\n");=0A+        return;=0A+    }=0A+    bar_val &=3D =
PCI_BASE_ADDRESS_MEM_MASK;=0A+    if ( !bar_val || !(bar_val + (bar_val & =
-bar_val)) )=0A+    {=0A+        dbgp_printk("firmware initialization of =
MMIO BAR required\n");=0A+        return;=0A+    }=0A+=0A+    serial_regist=
er_uart(SERHND_DBGP, &ehci_dbgp_driver, dbgp);=0A+}=0A+=0A+int dbgp_op(cons=
t struct physdev_dbgp_op *op)=0A+{=0A+    if ( !ehci_dbgp.ehci_debug )=0A+ =
       return 0;=0A+=0A+    switch ( op->bus )=0A+    {=0A+    case =
PHYSDEVOP_DBGP_BUS_UNKNOWN:=0A+        break;=0A+    case PHYSDEVOP_DBGP_BU=
S_PCI:=0A+        if ( op->u.pci.seg || ehci_dbgp.bus !=3D op->u.pci.bus =
||=0A+            PCI_DEVFN(ehci_dbgp.slot, ehci_dbgp.func) !=3D op->u.pci.=
devfn )=0A+    default:=0A+            return 0;=0A+        break;=0A+    =
}=0A+=0A+    switch ( op->op )=0A+    {=0A+    case PHYSDEVOP_DBGP_RESET_PR=
EPARE:=0A+        spin_lock_irq(ehci_dbgp.lock);=0A+        ehci_dbgp.state=
 =3D dbgp_unsafe;=0A+        dbgp_wait_until_complete(&ehci_dbgp, =
NULL);=0A+        spin_unlock_irq(ehci_dbgp.lock);=0A+=0A+        return =
ehci_dbgp_check_release(&ehci_dbgp);=0A+=0A+    case PHYSDEVOP_DBGP_RESET_D=
ONE:=0A+        return ehci_dbgp_external_startup(&ehci_dbgp) ?: 1;=0A+    =
}=0A+=0A+    return -ENOSYS;=0A+}=0A--- a/xen/drivers/char/serial.c=0A+++ =
b/xen/drivers/char/serial.c=0A@@ -265,6 +265,14 @@ int __init serial_parse_=
handle(char *con=0A {=0A     int handle;=0A =0A+    if ( !strncmp(conf, =
"dbgp", 4) && (!conf[4] || conf[4] =3D=3D ',') )=0A+    {=0A+        if ( =
!com[SERHND_DBGP].driver )=0A+            goto fail;=0A+=0A+        return =
SERHND_DBGP | SERHND_COOKED;=0A+    }=0A+=0A     if ( strncmp(conf, "com", =
3) )=0A         goto fail;=0A =0A--- a/xen/include/asm-x86/fixmap.h=0A+++ =
b/xen/include/asm-x86/fixmap.h=0A@@ -36,7 +36,15 @@=0A  * from the end of =
virtual memory backwards.=0A  */=0A enum fixed_addresses {=0A-    =
FIX_RESERVED, /* Index 0 is reserved since fix_to_virt(0) > FIXADDR_TOP. =
*/=0A+    /* Index 0 is reserved since fix_to_virt(0) =3D=3D FIXADDR_TOP. =
*/=0A+    FIX_RESERVED,=0A+    /*=0A+     * Indexes using the page tables =
set up before entering __start_xen()=0A+     * must be among the first =
(L1_PAGETABLE_ENTRIES - 1) entries.=0A+     * These are generally those =
needed by the various console drivers.=0A+     */=0A+    FIX_EHCI_DBGP,=0A+=
    /* Everything else should go further down. */=0A #ifdef __i386__=0A    =
 FIX_PAE_HIGHMEM_0,=0A     FIX_PAE_HIGHMEM_END =3D FIX_PAE_HIGHMEM_0 + =
NR_CPUS-1,=0A--- a/xen/include/public/physdev.h=0A+++ b/xen/include/public/=
physdev.h=0A@@ -312,6 +312,24 @@ struct physdev_pci_device {=0A typedef =
struct physdev_pci_device physdev_pci_device_t;=0A DEFINE_XEN_GUEST_HANDLE(=
physdev_pci_device_t);=0A =0A+#define PHYSDEVOP_DBGP_RESET_PREPARE    =
1=0A+#define PHYSDEVOP_DBGP_RESET_DONE       2=0A+=0A+#define PHYSDEVOP_DBG=
P_BUS_UNKNOWN      0=0A+#define PHYSDEVOP_DBGP_BUS_PCI          1=0A+=0A+#d=
efine PHYSDEVOP_dbgp_op               29=0A+struct physdev_dbgp_op {=0A+   =
 /* IN */=0A+    uint8_t op;=0A+    uint8_t bus;=0A+    union {=0A+        =
struct physdev_pci_device pci;=0A+    } u;=0A+};=0A+typedef struct =
physdev_dbgp_op physdev_dbgp_op_t;=0A+DEFINE_XEN_GUEST_HANDLE(physdev_dbgp_=
op_t);=0A+=0A /*=0A  * Notify that some PIRQ-bound event channels have =
been unmasked.=0A  * ** This command is obsolete since interface version =
0x00030202 and is **=0A--- a/xen/include/xen/serial.h=0A+++ b/xen/include/x=
en/serial.h=0A@@ -69,9 +69,10 @@ struct uart_driver {=0A };=0A =0A /* =
'Serial handles' are composed from the following fields. */=0A-#define =
SERHND_IDX      (3<<0) /* COM1 or COM2?                           =
*/=0A+#define SERHND_IDX      (3<<0) /* COM1, COM2, or DBGP?               =
     */=0A # define SERHND_COM1    (0<<0)=0A # define SERHND_COM2    =
(1<<0)=0A+# define SERHND_DBGP    (2<<0)=0A #define SERHND_HI       (1<<2) =
/* Mux/demux each transferred char by MSB. */=0A #define SERHND_LO       =
(1<<3) /* Ditto, except that the MSB is cleared.  */=0A #define SERHND_COOK=
ED   (1<<4) /* Newline/carriage-return translation?    */=0A@@ -142,9 =
+143,13 @@ struct ns16550_defaults {=0A     unsigned long io_base; /* =
default io_base address */=0A };=0A void ns16550_init(int index, struct =
ns16550_defaults *defaults);=0A+void ehci_dbgp_init(void);=0A =0A void =
pl011_init(int index, unsigned long register_base_address);=0A =0A+struct =
physdev_dbgp_op;=0A+int dbgp_op(const struct physdev_dbgp_op *);=0A+=0A /* =
Baud rate was pre-configured before invoking the UART driver. */=0A =
#define BAUD_AUTO (-1)=0A =0A
--=__Part0736157F.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

--=__Part0736157F.0__=--


From xen-devel-bounces@lists.xen.org Tue Sep 11 10:17:30 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 2012 10:17:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TBNWv-0002vB-NE; Tue, 11 Sep 2012 10:17:17 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1TBNWu-0002uv-3y
	for xen-devel@lists.xen.org; Tue, 11 Sep 2012 10:17:16 +0000
Received: from [85.158.139.83:64581] by server-5.bemta-5.messagelabs.com id
	41/33-30514-BAF0F405; Tue, 11 Sep 2012 10:17:15 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1347358634!22577555!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQwNzc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18034 invoked from network); 11 Sep 2012 10:17:14 -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;
	11 Sep 2012 10:17:14 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 11 Sep 2012 11:17:13 +0100
Message-Id: <504F2BC7020000780009A804@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 11 Sep 2012 11:17:11 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__PartCFFEDDB7.0__="
Subject: [Xen-devel] [PATCH RFC 4/8] serial: avoid fully initializing unused
 consoles
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<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.

--=__PartCFFEDDB7.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Defer calling the drivers' post-IRQ initialization functions (generally
doing allocation of transmit buffers) until it is known that the
respective console is actually going to be used.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/drivers/char/ehci-dbgp.c
+++ b/xen/drivers/char/ehci-dbgp.c
@@ -1391,7 +1391,8 @@ static int ehci_dbgp_check_release(struc
     printk(XENLOG_INFO "Releasing EHCI debug port at %02x:%02x.%u\n",
            dbgp->bus, dbgp->slot, dbgp->func);
=20
-    kill_timer(&dbgp->timer);
+    if ( dbgp->timer.function )
+        kill_timer(&dbgp->timer);
     dbgp->ehci_debug =3D NULL;
=20
     ctrl =3D readl(&ehci_debug->control);
--- a/xen/drivers/char/serial.c
+++ b/xen/drivers/char/serial.c
@@ -29,6 +29,8 @@ static struct serial_port com[SERHND_IDX
     }
 };
=20
+static bool_t __read_mostly post_irq;
+
 void serial_rx_interrupt(struct serial_port *port, struct cpu_user_regs =
*regs)
 {
     char c;
@@ -263,14 +265,12 @@ char serial_getc(int handle)
=20
 int __init serial_parse_handle(char *conf)
 {
-    int handle;
+    int handle, flags =3D 0;
=20
     if ( !strncmp(conf, "dbgp", 4) && (!conf[4] || conf[4] =3D=3D ',') )
     {
-        if ( !com[SERHND_DBGP].driver )
-            goto fail;
-
-        return SERHND_DBGP | SERHND_COOKED;
+        handle =3D SERHND_DBGP;
+        goto common;
     }
=20
     if ( strncmp(conf, "com", 3) )
@@ -288,17 +288,25 @@ int __init serial_parse_handle(char *con
         goto fail;
     }
=20
-    if ( !com[handle].driver )
-        goto fail;
-
     if ( conf[4] =3D=3D 'H' )
-        handle |=3D SERHND_HI;
+        flags |=3D SERHND_HI;
     else if ( conf[4] =3D=3D 'L' )
-        handle |=3D SERHND_LO;
+        flags |=3D SERHND_LO;
=20
-    handle |=3D SERHND_COOKED;
+ common:
+    if ( !com[handle].driver )
+        goto fail;
+
+    if ( !post_irq )
+        com[handle].state =3D serial_parsed;
+    else if ( com[handle].state !=3D serial_initialized )
+    {
+        if ( com[handle].driver->init_postirq )
+            com[handle].driver->init_postirq(&com[handle]);
+        com[handle].state =3D serial_initialized;
+    }
=20
-    return handle;
+    return handle | flags | SERHND_COOKED;
=20
  fail:
     return -1;
@@ -450,8 +458,13 @@ void __init serial_init_postirq(void)
 {
     int i;
     for ( i =3D 0; i < ARRAY_SIZE(com); i++ )
-        if ( com[i].driver && com[i].driver->init_postirq )
-            com[i].driver->init_postirq(&com[i]);
+        if ( com[i].state =3D=3D serial_parsed )
+        {
+            if ( com[i].driver->init_postirq )
+                com[i].driver->init_postirq(&com[i]);
+            com[i].state =3D serial_initialized;
+        }
+    post_irq =3D 1;
 }
=20
 void __init serial_endboot(void)
@@ -475,7 +488,7 @@ void serial_suspend(void)
 {
     int i;
     for ( i =3D 0; i < ARRAY_SIZE(com); i++ )
-        if ( com[i].driver && com[i].driver->suspend )
+        if ( com[i].state =3D=3D serial_initialized && com[i].driver->susp=
end )
             com[i].driver->suspend(&com[i]);
 }
=20
@@ -483,7 +496,7 @@ void serial_resume(void)
 {
     int i;
     for ( i =3D 0; i < ARRAY_SIZE(com); i++ )
-        if ( com[i].driver && com[i].driver->resume )
+        if ( com[i].state =3D=3D serial_initialized && com[i].driver->resu=
me )
             com[i].driver->resume(&com[i]);
 }
=20
--- a/xen/include/xen/serial.h
+++ b/xen/include/xen/serial.h
@@ -25,10 +25,17 @@ extern unsigned int serial_txbufsz;
=20
 struct uart_driver;
=20
+enum serial_port_state {
+    serial_unused,
+    serial_parsed,
+    serial_initialized
+};
+
 struct serial_port {
     /* Uart-driver parameters. */
     struct uart_driver *driver;
     void               *uart;
+    enum serial_port_state state;
     /* Number of characters the port can hold for transmit. */
     int                 tx_fifo_size;
     /* Transmit data buffer (interrupt-driven uart). */




--=__PartCFFEDDB7.0__=
Content-Type: text/plain; name="sercon-unused.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="sercon-unused.patch"

serial: avoid fully initializing unused consoles=0A=0ADefer calling the =
drivers' post-IRQ initialization functions (generally=0Adoing allocation =
of transmit buffers) until it is known that the=0Arespective console is =
actually going to be used.=0A=0ASigned-off-by: Jan Beulich <jbeulich@suse.c=
om>=0A=0A--- a/xen/drivers/char/ehci-dbgp.c=0A+++ b/xen/drivers/char/ehci-d=
bgp.c=0A@@ -1391,7 +1391,8 @@ static int ehci_dbgp_check_release(struc=0A  =
   printk(XENLOG_INFO "Releasing EHCI debug port at %02x:%02x.%u\n",=0A    =
        dbgp->bus, dbgp->slot, dbgp->func);=0A =0A-    kill_timer(&dbgp->ti=
mer);=0A+    if ( dbgp->timer.function )=0A+        kill_timer(&dbgp->timer=
);=0A     dbgp->ehci_debug =3D NULL;=0A =0A     ctrl =3D readl(&ehci_debug-=
>control);=0A--- a/xen/drivers/char/serial.c=0A+++ b/xen/drivers/char/seria=
l.c=0A@@ -29,6 +29,8 @@ static struct serial_port com[SERHND_IDX=0A     =
}=0A };=0A =0A+static bool_t __read_mostly post_irq;=0A+=0A void serial_rx_=
interrupt(struct serial_port *port, struct cpu_user_regs *regs)=0A {=0A    =
 char c;=0A@@ -263,14 +265,12 @@ char serial_getc(int handle)=0A =0A int =
__init serial_parse_handle(char *conf)=0A {=0A-    int handle;=0A+    int =
handle, flags =3D 0;=0A =0A     if ( !strncmp(conf, "dbgp", 4) && =
(!conf[4] || conf[4] =3D=3D ',') )=0A     {=0A-        if ( !com[SERHND_DBG=
P].driver )=0A-            goto fail;=0A-=0A-        return SERHND_DBGP | =
SERHND_COOKED;=0A+        handle =3D SERHND_DBGP;=0A+        goto =
common;=0A     }=0A =0A     if ( strncmp(conf, "com", 3) )=0A@@ -288,17 =
+288,25 @@ int __init serial_parse_handle(char *con=0A         goto =
fail;=0A     }=0A =0A-    if ( !com[handle].driver )=0A-        goto =
fail;=0A-=0A     if ( conf[4] =3D=3D 'H' )=0A-        handle |=3D =
SERHND_HI;=0A+        flags |=3D SERHND_HI;=0A     else if ( conf[4] =
=3D=3D 'L' )=0A-        handle |=3D SERHND_LO;=0A+        flags |=3D =
SERHND_LO;=0A =0A-    handle |=3D SERHND_COOKED;=0A+ common:=0A+    if ( =
!com[handle].driver )=0A+        goto fail;=0A+=0A+    if ( !post_irq =
)=0A+        com[handle].state =3D serial_parsed;=0A+    else if ( =
com[handle].state !=3D serial_initialized )=0A+    {=0A+        if ( =
com[handle].driver->init_postirq )=0A+            com[handle].driver->init_=
postirq(&com[handle]);=0A+        com[handle].state =3D serial_initialized;=
=0A+    }=0A =0A-    return handle;=0A+    return handle | flags | =
SERHND_COOKED;=0A =0A  fail:=0A     return -1;=0A@@ -450,8 +458,13 @@ void =
__init serial_init_postirq(void)=0A {=0A     int i;=0A     for ( i =3D 0; =
i < ARRAY_SIZE(com); i++ )=0A-        if ( com[i].driver && com[i].driver->=
init_postirq )=0A-            com[i].driver->init_postirq(&com[i]);=0A+    =
    if ( com[i].state =3D=3D serial_parsed )=0A+        {=0A+            =
if ( com[i].driver->init_postirq )=0A+                com[i].driver->init_p=
ostirq(&com[i]);=0A+            com[i].state =3D serial_initialized;=0A+   =
     }=0A+    post_irq =3D 1;=0A }=0A =0A void __init serial_endboot(void)=
=0A@@ -475,7 +488,7 @@ void serial_suspend(void)=0A {=0A     int i;=0A     =
for ( i =3D 0; i < ARRAY_SIZE(com); i++ )=0A-        if ( com[i].driver && =
com[i].driver->suspend )=0A+        if ( com[i].state =3D=3D serial_initial=
ized && com[i].driver->suspend )=0A             com[i].driver->suspend(&com=
[i]);=0A }=0A =0A@@ -483,7 +496,7 @@ void serial_resume(void)=0A {=0A     =
int i;=0A     for ( i =3D 0; i < ARRAY_SIZE(com); i++ )=0A-        if ( =
com[i].driver && com[i].driver->resume )=0A+        if ( com[i].state =
=3D=3D serial_initialized && com[i].driver->resume )=0A             =
com[i].driver->resume(&com[i]);=0A }=0A =0A--- a/xen/include/xen/serial.h=
=0A+++ b/xen/include/xen/serial.h=0A@@ -25,10 +25,17 @@ extern unsigned =
int serial_txbufsz;=0A =0A struct uart_driver;=0A =0A+enum serial_port_stat=
e {=0A+    serial_unused,=0A+    serial_parsed,=0A+    serial_initialized=
=0A+};=0A+=0A struct serial_port {=0A     /* Uart-driver parameters. */=0A =
    struct uart_driver *driver;=0A     void               *uart;=0A+    =
enum serial_port_state state;=0A     /* Number of characters the port can =
hold for transmit. */=0A     int                 tx_fifo_size;=0A     /* =
Transmit data buffer (interrupt-driven uart). */=0A
--=__PartCFFEDDB7.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

--=__PartCFFEDDB7.0__=--


From xen-devel-bounces@lists.xen.org Tue Sep 11 10:17:30 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 2012 10:17:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TBNWv-0002vB-NE; Tue, 11 Sep 2012 10:17:17 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1TBNWu-0002uv-3y
	for xen-devel@lists.xen.org; Tue, 11 Sep 2012 10:17:16 +0000
Received: from [85.158.139.83:64581] by server-5.bemta-5.messagelabs.com id
	41/33-30514-BAF0F405; Tue, 11 Sep 2012 10:17:15 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1347358634!22577555!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQwNzc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18034 invoked from network); 11 Sep 2012 10:17:14 -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;
	11 Sep 2012 10:17:14 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 11 Sep 2012 11:17:13 +0100
Message-Id: <504F2BC7020000780009A804@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 11 Sep 2012 11:17:11 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__PartCFFEDDB7.0__="
Subject: [Xen-devel] [PATCH RFC 4/8] serial: avoid fully initializing unused
 consoles
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<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.

--=__PartCFFEDDB7.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Defer calling the drivers' post-IRQ initialization functions (generally
doing allocation of transmit buffers) until it is known that the
respective console is actually going to be used.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/drivers/char/ehci-dbgp.c
+++ b/xen/drivers/char/ehci-dbgp.c
@@ -1391,7 +1391,8 @@ static int ehci_dbgp_check_release(struc
     printk(XENLOG_INFO "Releasing EHCI debug port at %02x:%02x.%u\n",
            dbgp->bus, dbgp->slot, dbgp->func);
=20
-    kill_timer(&dbgp->timer);
+    if ( dbgp->timer.function )
+        kill_timer(&dbgp->timer);
     dbgp->ehci_debug =3D NULL;
=20
     ctrl =3D readl(&ehci_debug->control);
--- a/xen/drivers/char/serial.c
+++ b/xen/drivers/char/serial.c
@@ -29,6 +29,8 @@ static struct serial_port com[SERHND_IDX
     }
 };
=20
+static bool_t __read_mostly post_irq;
+
 void serial_rx_interrupt(struct serial_port *port, struct cpu_user_regs =
*regs)
 {
     char c;
@@ -263,14 +265,12 @@ char serial_getc(int handle)
=20
 int __init serial_parse_handle(char *conf)
 {
-    int handle;
+    int handle, flags =3D 0;
=20
     if ( !strncmp(conf, "dbgp", 4) && (!conf[4] || conf[4] =3D=3D ',') )
     {
-        if ( !com[SERHND_DBGP].driver )
-            goto fail;
-
-        return SERHND_DBGP | SERHND_COOKED;
+        handle =3D SERHND_DBGP;
+        goto common;
     }
=20
     if ( strncmp(conf, "com", 3) )
@@ -288,17 +288,25 @@ int __init serial_parse_handle(char *con
         goto fail;
     }
=20
-    if ( !com[handle].driver )
-        goto fail;
-
     if ( conf[4] =3D=3D 'H' )
-        handle |=3D SERHND_HI;
+        flags |=3D SERHND_HI;
     else if ( conf[4] =3D=3D 'L' )
-        handle |=3D SERHND_LO;
+        flags |=3D SERHND_LO;
=20
-    handle |=3D SERHND_COOKED;
+ common:
+    if ( !com[handle].driver )
+        goto fail;
+
+    if ( !post_irq )
+        com[handle].state =3D serial_parsed;
+    else if ( com[handle].state !=3D serial_initialized )
+    {
+        if ( com[handle].driver->init_postirq )
+            com[handle].driver->init_postirq(&com[handle]);
+        com[handle].state =3D serial_initialized;
+    }
=20
-    return handle;
+    return handle | flags | SERHND_COOKED;
=20
  fail:
     return -1;
@@ -450,8 +458,13 @@ void __init serial_init_postirq(void)
 {
     int i;
     for ( i =3D 0; i < ARRAY_SIZE(com); i++ )
-        if ( com[i].driver && com[i].driver->init_postirq )
-            com[i].driver->init_postirq(&com[i]);
+        if ( com[i].state =3D=3D serial_parsed )
+        {
+            if ( com[i].driver->init_postirq )
+                com[i].driver->init_postirq(&com[i]);
+            com[i].state =3D serial_initialized;
+        }
+    post_irq =3D 1;
 }
=20
 void __init serial_endboot(void)
@@ -475,7 +488,7 @@ void serial_suspend(void)
 {
     int i;
     for ( i =3D 0; i < ARRAY_SIZE(com); i++ )
-        if ( com[i].driver && com[i].driver->suspend )
+        if ( com[i].state =3D=3D serial_initialized && com[i].driver->susp=
end )
             com[i].driver->suspend(&com[i]);
 }
=20
@@ -483,7 +496,7 @@ void serial_resume(void)
 {
     int i;
     for ( i =3D 0; i < ARRAY_SIZE(com); i++ )
-        if ( com[i].driver && com[i].driver->resume )
+        if ( com[i].state =3D=3D serial_initialized && com[i].driver->resu=
me )
             com[i].driver->resume(&com[i]);
 }
=20
--- a/xen/include/xen/serial.h
+++ b/xen/include/xen/serial.h
@@ -25,10 +25,17 @@ extern unsigned int serial_txbufsz;
=20
 struct uart_driver;
=20
+enum serial_port_state {
+    serial_unused,
+    serial_parsed,
+    serial_initialized
+};
+
 struct serial_port {
     /* Uart-driver parameters. */
     struct uart_driver *driver;
     void               *uart;
+    enum serial_port_state state;
     /* Number of characters the port can hold for transmit. */
     int                 tx_fifo_size;
     /* Transmit data buffer (interrupt-driven uart). */




--=__PartCFFEDDB7.0__=
Content-Type: text/plain; name="sercon-unused.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="sercon-unused.patch"

serial: avoid fully initializing unused consoles=0A=0ADefer calling the =
drivers' post-IRQ initialization functions (generally=0Adoing allocation =
of transmit buffers) until it is known that the=0Arespective console is =
actually going to be used.=0A=0ASigned-off-by: Jan Beulich <jbeulich@suse.c=
om>=0A=0A--- a/xen/drivers/char/ehci-dbgp.c=0A+++ b/xen/drivers/char/ehci-d=
bgp.c=0A@@ -1391,7 +1391,8 @@ static int ehci_dbgp_check_release(struc=0A  =
   printk(XENLOG_INFO "Releasing EHCI debug port at %02x:%02x.%u\n",=0A    =
        dbgp->bus, dbgp->slot, dbgp->func);=0A =0A-    kill_timer(&dbgp->ti=
mer);=0A+    if ( dbgp->timer.function )=0A+        kill_timer(&dbgp->timer=
);=0A     dbgp->ehci_debug =3D NULL;=0A =0A     ctrl =3D readl(&ehci_debug-=
>control);=0A--- a/xen/drivers/char/serial.c=0A+++ b/xen/drivers/char/seria=
l.c=0A@@ -29,6 +29,8 @@ static struct serial_port com[SERHND_IDX=0A     =
}=0A };=0A =0A+static bool_t __read_mostly post_irq;=0A+=0A void serial_rx_=
interrupt(struct serial_port *port, struct cpu_user_regs *regs)=0A {=0A    =
 char c;=0A@@ -263,14 +265,12 @@ char serial_getc(int handle)=0A =0A int =
__init serial_parse_handle(char *conf)=0A {=0A-    int handle;=0A+    int =
handle, flags =3D 0;=0A =0A     if ( !strncmp(conf, "dbgp", 4) && =
(!conf[4] || conf[4] =3D=3D ',') )=0A     {=0A-        if ( !com[SERHND_DBG=
P].driver )=0A-            goto fail;=0A-=0A-        return SERHND_DBGP | =
SERHND_COOKED;=0A+        handle =3D SERHND_DBGP;=0A+        goto =
common;=0A     }=0A =0A     if ( strncmp(conf, "com", 3) )=0A@@ -288,17 =
+288,25 @@ int __init serial_parse_handle(char *con=0A         goto =
fail;=0A     }=0A =0A-    if ( !com[handle].driver )=0A-        goto =
fail;=0A-=0A     if ( conf[4] =3D=3D 'H' )=0A-        handle |=3D =
SERHND_HI;=0A+        flags |=3D SERHND_HI;=0A     else if ( conf[4] =
=3D=3D 'L' )=0A-        handle |=3D SERHND_LO;=0A+        flags |=3D =
SERHND_LO;=0A =0A-    handle |=3D SERHND_COOKED;=0A+ common:=0A+    if ( =
!com[handle].driver )=0A+        goto fail;=0A+=0A+    if ( !post_irq =
)=0A+        com[handle].state =3D serial_parsed;=0A+    else if ( =
com[handle].state !=3D serial_initialized )=0A+    {=0A+        if ( =
com[handle].driver->init_postirq )=0A+            com[handle].driver->init_=
postirq(&com[handle]);=0A+        com[handle].state =3D serial_initialized;=
=0A+    }=0A =0A-    return handle;=0A+    return handle | flags | =
SERHND_COOKED;=0A =0A  fail:=0A     return -1;=0A@@ -450,8 +458,13 @@ void =
__init serial_init_postirq(void)=0A {=0A     int i;=0A     for ( i =3D 0; =
i < ARRAY_SIZE(com); i++ )=0A-        if ( com[i].driver && com[i].driver->=
init_postirq )=0A-            com[i].driver->init_postirq(&com[i]);=0A+    =
    if ( com[i].state =3D=3D serial_parsed )=0A+        {=0A+            =
if ( com[i].driver->init_postirq )=0A+                com[i].driver->init_p=
ostirq(&com[i]);=0A+            com[i].state =3D serial_initialized;=0A+   =
     }=0A+    post_irq =3D 1;=0A }=0A =0A void __init serial_endboot(void)=
=0A@@ -475,7 +488,7 @@ void serial_suspend(void)=0A {=0A     int i;=0A     =
for ( i =3D 0; i < ARRAY_SIZE(com); i++ )=0A-        if ( com[i].driver && =
com[i].driver->suspend )=0A+        if ( com[i].state =3D=3D serial_initial=
ized && com[i].driver->suspend )=0A             com[i].driver->suspend(&com=
[i]);=0A }=0A =0A@@ -483,7 +496,7 @@ void serial_resume(void)=0A {=0A     =
int i;=0A     for ( i =3D 0; i < ARRAY_SIZE(com); i++ )=0A-        if ( =
com[i].driver && com[i].driver->resume )=0A+        if ( com[i].state =
=3D=3D serial_initialized && com[i].driver->resume )=0A             =
com[i].driver->resume(&com[i]);=0A }=0A =0A--- a/xen/include/xen/serial.h=
=0A+++ b/xen/include/xen/serial.h=0A@@ -25,10 +25,17 @@ extern unsigned =
int serial_txbufsz;=0A =0A struct uart_driver;=0A =0A+enum serial_port_stat=
e {=0A+    serial_unused,=0A+    serial_parsed,=0A+    serial_initialized=
=0A+};=0A+=0A struct serial_port {=0A     /* Uart-driver parameters. */=0A =
    struct uart_driver *driver;=0A     void               *uart;=0A+    =
enum serial_port_state state;=0A     /* Number of characters the port can =
hold for transmit. */=0A     int                 tx_fifo_size;=0A     /* =
Transmit data buffer (interrupt-driven uart). */=0A
--=__PartCFFEDDB7.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

--=__PartCFFEDDB7.0__=--


From xen-devel-bounces@lists.xen.org Tue Sep 11 10:18:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 2012 10:18: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 1TBNXs-00033g-5q; Tue, 11 Sep 2012 10:18: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 1TBNXq-00033T-Jf
	for xen-devel@lists.xen.org; Tue, 11 Sep 2012 10:18:14 +0000
Received: from [85.158.139.83:16324] by server-12.bemta-5.messagelabs.com id
	A9/34-18300-5EF0F405; Tue, 11 Sep 2012 10:18:13 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1347358692!27616449!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQwNzc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21668 invoked from network); 11 Sep 2012 10:18:12 -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;
	11 Sep 2012 10:18:12 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 11 Sep 2012 11:18:12 +0100
Message-Id: <504F2C00020000780009A808@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 11 Sep 2012 11:18:08 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part88B99AF0.0__="
Subject: [Xen-devel] [PATCH RFC 5/8] ns16550: MMIO adjustments
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=__Part88B99AF0.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

On x86 ioremap() is not suitable here, set_fixmap() must be used
instead.

Also replace some literal numbers by their proper symbolic constants,
making the code easier to understand.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/drivers/char/ns16550.c
+++ b/xen/drivers/char/ns16550.c
@@ -20,6 +20,9 @@
 #include <xen/pci.h>
 #include <xen/pci_regs.h>
 #include <asm/io.h>
+#ifdef CONFIG_X86
+#include <asm/fixmap.h>
+#endif
=20
 /*
  * Configure serial port with a string:
@@ -37,7 +40,7 @@ string_param("com2", opt_com2);
 static struct ns16550 {
     int baud, clock_hz, data_bits, parity, stop_bits, irq;
     unsigned long io_base;   /* I/O port or memory-mapped I/O address. */
-    char *remapped_io_base;  /* Remapped virtual address of mmap I/O.  =
*/=20
+    char __iomem *remapped_io_base;  /* Remapped virtual address of MMIO. =
*/
     /* UART with IRQ line: interrupt-driven I/O. */
     struct irqaction irqaction;
     /* UART with no IRQ line: periodically-polled I/O. */
@@ -207,17 +210,20 @@ static int ns16550_getc(struct serial_po
=20
 static void pci_serial_early_init(struct ns16550 *uart)
 {
-    if ( !uart->ps_bdf_enable )
+    if ( !uart->ps_bdf_enable || uart->io_base >=3D 0x10000 )
         return;
    =20
     if ( uart->pb_bdf_enable )
         pci_conf_write16(0, uart->pb_bdf[0], uart->pb_bdf[1], uart->pb_bdf=
[2],
-            0x1c, (uart->io_base & 0xF000) | ((uart->io_base & 0xF000) >> =
8));
+                         PCI_IO_BASE,
+                         (uart->io_base & 0xF000) |
+                         ((uart->io_base & 0xF000) >> 8));
=20
     pci_conf_write32(0, uart->ps_bdf[0], uart->ps_bdf[1], uart->ps_bdf[2],=

-        0x10, uart->io_base | 0x1);
+                     PCI_BASE_ADDRESS_0,
+                     uart->io_base | PCI_BASE_ADDRESS_SPACE_IO);
     pci_conf_write16(0, uart->ps_bdf[0], uart->ps_bdf[1], uart->ps_bdf[2],=

-        0x4, 0x1);
+                     PCI_COMMAND, PCI_COMMAND_IO);
 }
=20
 static void ns16550_setup_preirq(struct ns16550 *uart)
@@ -265,7 +271,17 @@ static void __init ns16550_init_preirq(s
=20
     /* I/O ports are distinguished by their size (16 bits). */
     if ( uart->io_base >=3D 0x10000 )
+    {
+#ifdef CONFIG_X86
+        enum fixed_addresses idx =3D FIX_COM_BEGIN + (uart - ns16550_com);=

+
+        set_fixmap_nocache(idx, uart->io_base);
+        uart->remapped_io_base =3D (void __iomem *)fix_to_virt(idx);
+        uart->remapped_io_base +=3D uart->io_base & ~PAGE_MASK;
+#else
         uart->remapped_io_base =3D (char *)ioremap(uart->io_base, 8);
+#endif
+    }
=20
     ns16550_setup_preirq(uart);
=20
@@ -350,6 +366,9 @@ static void ns16550_resume(struct serial
 static void __init ns16550_endboot(struct serial_port *port)
 {
     struct ns16550 *uart =3D port->uart;
+
+    if ( uart->remapped_io_base )
+        return;
     if ( ioports_deny_access(dom0, uart->io_base, uart->io_base + 7) !=3D =
0 )
         BUG();
 }
@@ -453,7 +472,7 @@ pci_uart_config (struct ns16550 *uart, i
     uint32_t bar, len;
     int b, d, f;
=20
-    /* NB. Start at bus 1 to avoid AMT: a plug-in card cannot be on bus =
1. */
+    /* NB. Start at bus 1 to avoid AMT: a plug-in card cannot be on bus =
0. */
     for ( b =3D skip_amt ? 1 : 0; b < 0x100; b++ )
     {
         for ( d =3D 0; d < 0x20; d++ )
@@ -468,7 +487,7 @@ pci_uart_config (struct ns16550 *uart, i
                                       PCI_BASE_ADDRESS_0 + bar_idx*4);
=20
                 /* Not IO */
-                if ( !(bar & 1) )
+                if ( !(bar & PCI_BASE_ADDRESS_SPACE_IO) )
                     continue;
=20
                 pci_conf_write32(0, b, d, f, PCI_BASE_ADDRESS_0, ~0u);
@@ -484,7 +503,7 @@ pci_uart_config (struct ns16550 *uart, i
                 uart->ps_bdf[2] =3D f;
                 uart->bar =3D bar;
                 uart->bar_idx =3D bar_idx;
-                uart->io_base =3D bar & 0xfffe;
+                uart->io_base =3D bar & ~PCI_BASE_ADDRESS_SPACE_IO;
                 uart->irq =3D 0;
=20
                 return 0;
--- a/xen/include/asm-x86/fixmap.h
+++ b/xen/include/asm-x86/fixmap.h
@@ -43,6 +43,8 @@ enum fixed_addresses {
      * must be among the first (L1_PAGETABLE_ENTRIES - 1) entries.
      * These are generally those needed by the various console drivers.
      */
+    FIX_COM_BEGIN,
+    FIX_COM_END,
     FIX_EHCI_DBGP,
     /* Everything else should go further down. */
 #ifdef __i386__



--=__Part88B99AF0.0__=
Content-Type: text/plain; name="sercon-ns16550-mmio.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="sercon-ns16550-mmio.patch"

ns16550: MMIO adjustments=0A=0AOn x86 ioremap() is not suitable here, =
set_fixmap() must be used=0Ainstead.=0A=0AAlso replace some literal =
numbers by their proper symbolic constants,=0Amaking the code easier to =
understand.=0A=0ASigned-off-by: Jan Beulich <jbeulich@suse.com>=0A=0A--- =
a/xen/drivers/char/ns16550.c=0A+++ b/xen/drivers/char/ns16550.c=0A@@ -20,6 =
+20,9 @@=0A #include <xen/pci.h>=0A #include <xen/pci_regs.h>=0A #include =
<asm/io.h>=0A+#ifdef CONFIG_X86=0A+#include <asm/fixmap.h>=0A+#endif=0A =
=0A /*=0A  * Configure serial port with a string:=0A@@ -37,7 +40,7 @@ =
string_param("com2", opt_com2);=0A static struct ns16550 {=0A     int =
baud, clock_hz, data_bits, parity, stop_bits, irq;=0A     unsigned long =
io_base;   /* I/O port or memory-mapped I/O address. */=0A-    char =
*remapped_io_base;  /* Remapped virtual address of mmap I/O.  */ =0A+    =
char __iomem *remapped_io_base;  /* Remapped virtual address of MMIO. =
*/=0A     /* UART with IRQ line: interrupt-driven I/O. */=0A     struct =
irqaction irqaction;=0A     /* UART with no IRQ line: periodically-polled =
I/O. */=0A@@ -207,17 +210,20 @@ static int ns16550_getc(struct serial_po=0A=
 =0A static void pci_serial_early_init(struct ns16550 *uart)=0A {=0A-    =
if ( !uart->ps_bdf_enable )=0A+    if ( !uart->ps_bdf_enable || uart->io_ba=
se >=3D 0x10000 )=0A         return;=0A     =0A     if ( uart->pb_bdf_enabl=
e )=0A         pci_conf_write16(0, uart->pb_bdf[0], uart->pb_bdf[1], =
uart->pb_bdf[2],=0A-            0x1c, (uart->io_base & 0xF000) | ((uart->io=
_base & 0xF000) >> 8));=0A+                         PCI_IO_BASE,=0A+       =
                  (uart->io_base & 0xF000) |=0A+                         =
((uart->io_base & 0xF000) >> 8));=0A =0A     pci_conf_write32(0, uart->ps_b=
df[0], uart->ps_bdf[1], uart->ps_bdf[2],=0A-        0x10, uart->io_base | =
0x1);=0A+                     PCI_BASE_ADDRESS_0,=0A+                     =
uart->io_base | PCI_BASE_ADDRESS_SPACE_IO);=0A     pci_conf_write16(0, =
uart->ps_bdf[0], uart->ps_bdf[1], uart->ps_bdf[2],=0A-        0x4, =
0x1);=0A+                     PCI_COMMAND, PCI_COMMAND_IO);=0A }=0A =0A =
static void ns16550_setup_preirq(struct ns16550 *uart)=0A@@ -265,7 +271,17 =
@@ static void __init ns16550_init_preirq(s=0A =0A     /* I/O ports are =
distinguished by their size (16 bits). */=0A     if ( uart->io_base >=3D =
0x10000 )=0A+    {=0A+#ifdef CONFIG_X86=0A+        enum fixed_addresses =
idx =3D FIX_COM_BEGIN + (uart - ns16550_com);=0A+=0A+        set_fixmap_noc=
ache(idx, uart->io_base);=0A+        uart->remapped_io_base =3D (void =
__iomem *)fix_to_virt(idx);=0A+        uart->remapped_io_base +=3D =
uart->io_base & ~PAGE_MASK;=0A+#else=0A         uart->remapped_io_base =3D =
(char *)ioremap(uart->io_base, 8);=0A+#endif=0A+    }=0A =0A     ns16550_se=
tup_preirq(uart);=0A =0A@@ -350,6 +366,9 @@ static void ns16550_resume(stru=
ct serial=0A static void __init ns16550_endboot(struct serial_port =
*port)=0A {=0A     struct ns16550 *uart =3D port->uart;=0A+=0A+    if ( =
uart->remapped_io_base )=0A+        return;=0A     if ( ioports_deny_access=
(dom0, uart->io_base, uart->io_base + 7) !=3D 0 )=0A         BUG();=0A =
}=0A@@ -453,7 +472,7 @@ pci_uart_config (struct ns16550 *uart, i=0A     =
uint32_t bar, len;=0A     int b, d, f;=0A =0A-    /* NB. Start at bus 1 to =
avoid AMT: a plug-in card cannot be on bus 1. */=0A+    /* NB. Start at =
bus 1 to avoid AMT: a plug-in card cannot be on bus 0. */=0A     for ( b =
=3D skip_amt ? 1 : 0; b < 0x100; b++ )=0A     {=0A         for ( d =3D 0; =
d < 0x20; d++ )=0A@@ -468,7 +487,7 @@ pci_uart_config (struct ns16550 =
*uart, i=0A                                       PCI_BASE_ADDRESS_0 + =
bar_idx*4);=0A =0A                 /* Not IO */=0A-                if ( =
!(bar & 1) )=0A+                if ( !(bar & PCI_BASE_ADDRESS_SPACE_IO) =
)=0A                     continue;=0A =0A                 pci_conf_write32(=
0, b, d, f, PCI_BASE_ADDRESS_0, ~0u);=0A@@ -484,7 +503,7 @@ pci_uart_config=
 (struct ns16550 *uart, i=0A                 uart->ps_bdf[2] =3D f;=0A     =
            uart->bar =3D bar;=0A                 uart->bar_idx =3D =
bar_idx;=0A-                uart->io_base =3D bar & 0xfffe;=0A+            =
    uart->io_base =3D bar & ~PCI_BASE_ADDRESS_SPACE_IO;=0A                 =
uart->irq =3D 0;=0A =0A                 return 0;=0A--- a/xen/include/asm-x=
86/fixmap.h=0A+++ b/xen/include/asm-x86/fixmap.h=0A@@ -43,6 +43,8 @@ enum =
fixed_addresses {=0A      * must be among the first (L1_PAGETABLE_ENTRIES =
- 1) entries.=0A      * These are generally those needed by the various =
console drivers.=0A      */=0A+    FIX_COM_BEGIN,=0A+    FIX_COM_END,=0A   =
  FIX_EHCI_DBGP,=0A     /* Everything else should go further down. */=0A =
#ifdef __i386__=0A
--=__Part88B99AF0.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

--=__Part88B99AF0.0__=--


From xen-devel-bounces@lists.xen.org Tue Sep 11 10:18:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 2012 10:18: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 1TBNXs-00033g-5q; Tue, 11 Sep 2012 10:18: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 1TBNXq-00033T-Jf
	for xen-devel@lists.xen.org; Tue, 11 Sep 2012 10:18:14 +0000
Received: from [85.158.139.83:16324] by server-12.bemta-5.messagelabs.com id
	A9/34-18300-5EF0F405; Tue, 11 Sep 2012 10:18:13 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1347358692!27616449!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQwNzc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21668 invoked from network); 11 Sep 2012 10:18:12 -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;
	11 Sep 2012 10:18:12 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 11 Sep 2012 11:18:12 +0100
Message-Id: <504F2C00020000780009A808@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 11 Sep 2012 11:18:08 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part88B99AF0.0__="
Subject: [Xen-devel] [PATCH RFC 5/8] ns16550: MMIO adjustments
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=__Part88B99AF0.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

On x86 ioremap() is not suitable here, set_fixmap() must be used
instead.

Also replace some literal numbers by their proper symbolic constants,
making the code easier to understand.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/drivers/char/ns16550.c
+++ b/xen/drivers/char/ns16550.c
@@ -20,6 +20,9 @@
 #include <xen/pci.h>
 #include <xen/pci_regs.h>
 #include <asm/io.h>
+#ifdef CONFIG_X86
+#include <asm/fixmap.h>
+#endif
=20
 /*
  * Configure serial port with a string:
@@ -37,7 +40,7 @@ string_param("com2", opt_com2);
 static struct ns16550 {
     int baud, clock_hz, data_bits, parity, stop_bits, irq;
     unsigned long io_base;   /* I/O port or memory-mapped I/O address. */
-    char *remapped_io_base;  /* Remapped virtual address of mmap I/O.  =
*/=20
+    char __iomem *remapped_io_base;  /* Remapped virtual address of MMIO. =
*/
     /* UART with IRQ line: interrupt-driven I/O. */
     struct irqaction irqaction;
     /* UART with no IRQ line: periodically-polled I/O. */
@@ -207,17 +210,20 @@ static int ns16550_getc(struct serial_po
=20
 static void pci_serial_early_init(struct ns16550 *uart)
 {
-    if ( !uart->ps_bdf_enable )
+    if ( !uart->ps_bdf_enable || uart->io_base >=3D 0x10000 )
         return;
    =20
     if ( uart->pb_bdf_enable )
         pci_conf_write16(0, uart->pb_bdf[0], uart->pb_bdf[1], uart->pb_bdf=
[2],
-            0x1c, (uart->io_base & 0xF000) | ((uart->io_base & 0xF000) >> =
8));
+                         PCI_IO_BASE,
+                         (uart->io_base & 0xF000) |
+                         ((uart->io_base & 0xF000) >> 8));
=20
     pci_conf_write32(0, uart->ps_bdf[0], uart->ps_bdf[1], uart->ps_bdf[2],=

-        0x10, uart->io_base | 0x1);
+                     PCI_BASE_ADDRESS_0,
+                     uart->io_base | PCI_BASE_ADDRESS_SPACE_IO);
     pci_conf_write16(0, uart->ps_bdf[0], uart->ps_bdf[1], uart->ps_bdf[2],=

-        0x4, 0x1);
+                     PCI_COMMAND, PCI_COMMAND_IO);
 }
=20
 static void ns16550_setup_preirq(struct ns16550 *uart)
@@ -265,7 +271,17 @@ static void __init ns16550_init_preirq(s
=20
     /* I/O ports are distinguished by their size (16 bits). */
     if ( uart->io_base >=3D 0x10000 )
+    {
+#ifdef CONFIG_X86
+        enum fixed_addresses idx =3D FIX_COM_BEGIN + (uart - ns16550_com);=

+
+        set_fixmap_nocache(idx, uart->io_base);
+        uart->remapped_io_base =3D (void __iomem *)fix_to_virt(idx);
+        uart->remapped_io_base +=3D uart->io_base & ~PAGE_MASK;
+#else
         uart->remapped_io_base =3D (char *)ioremap(uart->io_base, 8);
+#endif
+    }
=20
     ns16550_setup_preirq(uart);
=20
@@ -350,6 +366,9 @@ static void ns16550_resume(struct serial
 static void __init ns16550_endboot(struct serial_port *port)
 {
     struct ns16550 *uart =3D port->uart;
+
+    if ( uart->remapped_io_base )
+        return;
     if ( ioports_deny_access(dom0, uart->io_base, uart->io_base + 7) !=3D =
0 )
         BUG();
 }
@@ -453,7 +472,7 @@ pci_uart_config (struct ns16550 *uart, i
     uint32_t bar, len;
     int b, d, f;
=20
-    /* NB. Start at bus 1 to avoid AMT: a plug-in card cannot be on bus =
1. */
+    /* NB. Start at bus 1 to avoid AMT: a plug-in card cannot be on bus =
0. */
     for ( b =3D skip_amt ? 1 : 0; b < 0x100; b++ )
     {
         for ( d =3D 0; d < 0x20; d++ )
@@ -468,7 +487,7 @@ pci_uart_config (struct ns16550 *uart, i
                                       PCI_BASE_ADDRESS_0 + bar_idx*4);
=20
                 /* Not IO */
-                if ( !(bar & 1) )
+                if ( !(bar & PCI_BASE_ADDRESS_SPACE_IO) )
                     continue;
=20
                 pci_conf_write32(0, b, d, f, PCI_BASE_ADDRESS_0, ~0u);
@@ -484,7 +503,7 @@ pci_uart_config (struct ns16550 *uart, i
                 uart->ps_bdf[2] =3D f;
                 uart->bar =3D bar;
                 uart->bar_idx =3D bar_idx;
-                uart->io_base =3D bar & 0xfffe;
+                uart->io_base =3D bar & ~PCI_BASE_ADDRESS_SPACE_IO;
                 uart->irq =3D 0;
=20
                 return 0;
--- a/xen/include/asm-x86/fixmap.h
+++ b/xen/include/asm-x86/fixmap.h
@@ -43,6 +43,8 @@ enum fixed_addresses {
      * must be among the first (L1_PAGETABLE_ENTRIES - 1) entries.
      * These are generally those needed by the various console drivers.
      */
+    FIX_COM_BEGIN,
+    FIX_COM_END,
     FIX_EHCI_DBGP,
     /* Everything else should go further down. */
 #ifdef __i386__



--=__Part88B99AF0.0__=
Content-Type: text/plain; name="sercon-ns16550-mmio.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="sercon-ns16550-mmio.patch"

ns16550: MMIO adjustments=0A=0AOn x86 ioremap() is not suitable here, =
set_fixmap() must be used=0Ainstead.=0A=0AAlso replace some literal =
numbers by their proper symbolic constants,=0Amaking the code easier to =
understand.=0A=0ASigned-off-by: Jan Beulich <jbeulich@suse.com>=0A=0A--- =
a/xen/drivers/char/ns16550.c=0A+++ b/xen/drivers/char/ns16550.c=0A@@ -20,6 =
+20,9 @@=0A #include <xen/pci.h>=0A #include <xen/pci_regs.h>=0A #include =
<asm/io.h>=0A+#ifdef CONFIG_X86=0A+#include <asm/fixmap.h>=0A+#endif=0A =
=0A /*=0A  * Configure serial port with a string:=0A@@ -37,7 +40,7 @@ =
string_param("com2", opt_com2);=0A static struct ns16550 {=0A     int =
baud, clock_hz, data_bits, parity, stop_bits, irq;=0A     unsigned long =
io_base;   /* I/O port or memory-mapped I/O address. */=0A-    char =
*remapped_io_base;  /* Remapped virtual address of mmap I/O.  */ =0A+    =
char __iomem *remapped_io_base;  /* Remapped virtual address of MMIO. =
*/=0A     /* UART with IRQ line: interrupt-driven I/O. */=0A     struct =
irqaction irqaction;=0A     /* UART with no IRQ line: periodically-polled =
I/O. */=0A@@ -207,17 +210,20 @@ static int ns16550_getc(struct serial_po=0A=
 =0A static void pci_serial_early_init(struct ns16550 *uart)=0A {=0A-    =
if ( !uart->ps_bdf_enable )=0A+    if ( !uart->ps_bdf_enable || uart->io_ba=
se >=3D 0x10000 )=0A         return;=0A     =0A     if ( uart->pb_bdf_enabl=
e )=0A         pci_conf_write16(0, uart->pb_bdf[0], uart->pb_bdf[1], =
uart->pb_bdf[2],=0A-            0x1c, (uart->io_base & 0xF000) | ((uart->io=
_base & 0xF000) >> 8));=0A+                         PCI_IO_BASE,=0A+       =
                  (uart->io_base & 0xF000) |=0A+                         =
((uart->io_base & 0xF000) >> 8));=0A =0A     pci_conf_write32(0, uart->ps_b=
df[0], uart->ps_bdf[1], uart->ps_bdf[2],=0A-        0x10, uart->io_base | =
0x1);=0A+                     PCI_BASE_ADDRESS_0,=0A+                     =
uart->io_base | PCI_BASE_ADDRESS_SPACE_IO);=0A     pci_conf_write16(0, =
uart->ps_bdf[0], uart->ps_bdf[1], uart->ps_bdf[2],=0A-        0x4, =
0x1);=0A+                     PCI_COMMAND, PCI_COMMAND_IO);=0A }=0A =0A =
static void ns16550_setup_preirq(struct ns16550 *uart)=0A@@ -265,7 +271,17 =
@@ static void __init ns16550_init_preirq(s=0A =0A     /* I/O ports are =
distinguished by their size (16 bits). */=0A     if ( uart->io_base >=3D =
0x10000 )=0A+    {=0A+#ifdef CONFIG_X86=0A+        enum fixed_addresses =
idx =3D FIX_COM_BEGIN + (uart - ns16550_com);=0A+=0A+        set_fixmap_noc=
ache(idx, uart->io_base);=0A+        uart->remapped_io_base =3D (void =
__iomem *)fix_to_virt(idx);=0A+        uart->remapped_io_base +=3D =
uart->io_base & ~PAGE_MASK;=0A+#else=0A         uart->remapped_io_base =3D =
(char *)ioremap(uart->io_base, 8);=0A+#endif=0A+    }=0A =0A     ns16550_se=
tup_preirq(uart);=0A =0A@@ -350,6 +366,9 @@ static void ns16550_resume(stru=
ct serial=0A static void __init ns16550_endboot(struct serial_port =
*port)=0A {=0A     struct ns16550 *uart =3D port->uart;=0A+=0A+    if ( =
uart->remapped_io_base )=0A+        return;=0A     if ( ioports_deny_access=
(dom0, uart->io_base, uart->io_base + 7) !=3D 0 )=0A         BUG();=0A =
}=0A@@ -453,7 +472,7 @@ pci_uart_config (struct ns16550 *uart, i=0A     =
uint32_t bar, len;=0A     int b, d, f;=0A =0A-    /* NB. Start at bus 1 to =
avoid AMT: a plug-in card cannot be on bus 1. */=0A+    /* NB. Start at =
bus 1 to avoid AMT: a plug-in card cannot be on bus 0. */=0A     for ( b =
=3D skip_amt ? 1 : 0; b < 0x100; b++ )=0A     {=0A         for ( d =3D 0; =
d < 0x20; d++ )=0A@@ -468,7 +487,7 @@ pci_uart_config (struct ns16550 =
*uart, i=0A                                       PCI_BASE_ADDRESS_0 + =
bar_idx*4);=0A =0A                 /* Not IO */=0A-                if ( =
!(bar & 1) )=0A+                if ( !(bar & PCI_BASE_ADDRESS_SPACE_IO) =
)=0A                     continue;=0A =0A                 pci_conf_write32(=
0, b, d, f, PCI_BASE_ADDRESS_0, ~0u);=0A@@ -484,7 +503,7 @@ pci_uart_config=
 (struct ns16550 *uart, i=0A                 uart->ps_bdf[2] =3D f;=0A     =
            uart->bar =3D bar;=0A                 uart->bar_idx =3D =
bar_idx;=0A-                uart->io_base =3D bar & 0xfffe;=0A+            =
    uart->io_base =3D bar & ~PCI_BASE_ADDRESS_SPACE_IO;=0A                 =
uart->irq =3D 0;=0A =0A                 return 0;=0A--- a/xen/include/asm-x=
86/fixmap.h=0A+++ b/xen/include/asm-x86/fixmap.h=0A@@ -43,6 +43,8 @@ enum =
fixed_addresses {=0A      * must be among the first (L1_PAGETABLE_ENTRIES =
- 1) entries.=0A      * These are generally those needed by the various =
console drivers.=0A      */=0A+    FIX_COM_BEGIN,=0A+    FIX_COM_END,=0A   =
  FIX_EHCI_DBGP,=0A     /* Everything else should go further down. */=0A =
#ifdef __i386__=0A
--=__Part88B99AF0.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

--=__Part88B99AF0.0__=--


From xen-devel-bounces@lists.xen.org Tue Sep 11 10:19:55 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 2012 10:19:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TBNZG-0003D6-Lf; Tue, 11 Sep 2012 10:19:42 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1TBNZE-0003Cx-Q2
	for xen-devel@lists.xen.org; Tue, 11 Sep 2012 10:19:41 +0000
Received: from [85.158.139.83:30363] by server-11.bemta-5.messagelabs.com id
	11/72-24658-C301F405; Tue, 11 Sep 2012 10:19:40 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1347358776!18514379!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQwNzc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6293 invoked from network); 11 Sep 2012 10:19:36 -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;
	11 Sep 2012 10:19:36 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 11 Sep 2012 11:19:35 +0100
Message-Id: <504F2C54020000780009A830@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 11 Sep 2012 11:19:32 +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 6/8] ns16550: PCI initialization adjustments
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Besides single-port serial cards, also accept multi-port ones and such
providing mixed functionality (e.g. also having a parallel port).

Reading PCI_INTERRUPT_PIN before ACPI gets enabled generally produces
an incorrect IRQ (below 16, whereas after enabling ACPI it frequently
would end up at a higher one), so this is useful (almost) only when a
system already boots in ACPI mode.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/drivers/char/ns16550.c
+++ b/xen/drivers/char/ns16550.c
@@ -468,7 +468,6 @@ static int __init check_existence(struct
 static int
 pci_uart_config (struct ns16550 *uart, int skip_amt, int bar_idx)
 {
-    uint16_t class;
     uint32_t bar, len;
     int b, d, f;
 
@@ -479,9 +478,15 @@ pci_uart_config (struct ns16550 *uart, i
         {
             for ( f = 0; f < 0x8; f++ )
             {
-                class = pci_conf_read16(0, b, d, f, PCI_CLASS_DEVICE);
-                if ( class != 0x700 )
+                switch ( pci_conf_read16(0, b, d, f, PCI_CLASS_DEVICE) )
+                {
+                case 0x0700: /* single port serial */
+                case 0x0702: /* multi port serial */
+                case 0x0780: /* other (e.g serial+parallel) */
+                    break;
+                default:
                     continue;
+                }
 
                 bar = pci_conf_read32(0, b, d, f,
                                       PCI_BASE_ADDRESS_0 + bar_idx*4);
@@ -504,7 +509,9 @@ pci_uart_config (struct ns16550 *uart, i
                 uart->bar = bar;
                 uart->bar_idx = bar_idx;
                 uart->io_base = bar & ~PCI_BASE_ADDRESS_SPACE_IO;
-                uart->irq = 0;
+                uart->irq = pci_conf_read8(0, b, d, f, PCI_INTERRUPT_PIN) ?
+                    pci_conf_read8(0, b, d, f, PCI_INTERRUPT_LINE) : 0;
+printk("COM%d: BAR=%04x IRQ=%d\n", bar_idx + 1, bar, uart->irq);//temp
 
                 return 0;
             }




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 11 10:19:55 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 2012 10:19:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TBNZG-0003D6-Lf; Tue, 11 Sep 2012 10:19:42 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1TBNZE-0003Cx-Q2
	for xen-devel@lists.xen.org; Tue, 11 Sep 2012 10:19:41 +0000
Received: from [85.158.139.83:30363] by server-11.bemta-5.messagelabs.com id
	11/72-24658-C301F405; Tue, 11 Sep 2012 10:19:40 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1347358776!18514379!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQwNzc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6293 invoked from network); 11 Sep 2012 10:19:36 -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;
	11 Sep 2012 10:19:36 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 11 Sep 2012 11:19:35 +0100
Message-Id: <504F2C54020000780009A830@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 11 Sep 2012 11:19:32 +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 6/8] ns16550: PCI initialization adjustments
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Besides single-port serial cards, also accept multi-port ones and such
providing mixed functionality (e.g. also having a parallel port).

Reading PCI_INTERRUPT_PIN before ACPI gets enabled generally produces
an incorrect IRQ (below 16, whereas after enabling ACPI it frequently
would end up at a higher one), so this is useful (almost) only when a
system already boots in ACPI mode.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/drivers/char/ns16550.c
+++ b/xen/drivers/char/ns16550.c
@@ -468,7 +468,6 @@ static int __init check_existence(struct
 static int
 pci_uart_config (struct ns16550 *uart, int skip_amt, int bar_idx)
 {
-    uint16_t class;
     uint32_t bar, len;
     int b, d, f;
 
@@ -479,9 +478,15 @@ pci_uart_config (struct ns16550 *uart, i
         {
             for ( f = 0; f < 0x8; f++ )
             {
-                class = pci_conf_read16(0, b, d, f, PCI_CLASS_DEVICE);
-                if ( class != 0x700 )
+                switch ( pci_conf_read16(0, b, d, f, PCI_CLASS_DEVICE) )
+                {
+                case 0x0700: /* single port serial */
+                case 0x0702: /* multi port serial */
+                case 0x0780: /* other (e.g serial+parallel) */
+                    break;
+                default:
                     continue;
+                }
 
                 bar = pci_conf_read32(0, b, d, f,
                                       PCI_BASE_ADDRESS_0 + bar_idx*4);
@@ -504,7 +509,9 @@ pci_uart_config (struct ns16550 *uart, i
                 uart->bar = bar;
                 uart->bar_idx = bar_idx;
                 uart->io_base = bar & ~PCI_BASE_ADDRESS_SPACE_IO;
-                uart->irq = 0;
+                uart->irq = pci_conf_read8(0, b, d, f, PCI_INTERRUPT_PIN) ?
+                    pci_conf_read8(0, b, d, f, PCI_INTERRUPT_LINE) : 0;
+printk("COM%d: BAR=%04x IRQ=%d\n", bar_idx + 1, bar, uart->irq);//temp
 
                 return 0;
             }




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 11 10:20:50 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 2012 10:20:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TBNaB-0003KG-4X; Tue, 11 Sep 2012 10:20: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 1TBNa9-0003Jw-VR
	for xen-devel@lists.xen.org; Tue, 11 Sep 2012 10:20:38 +0000
Received: from [85.158.139.83:41271] by server-10.bemta-5.messagelabs.com id
	17/E2-10969-5701F405; Tue, 11 Sep 2012 10:20:37 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1347358835!22578385!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQwNzc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1869 invoked from network); 11 Sep 2012 10:20:36 -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;
	11 Sep 2012 10:20:36 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 11 Sep 2012 11:20:35 +0100
Message-Id: <504F2C90020000780009A834@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 11 Sep 2012 11:20:32 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part07361560.0__="
Subject: [Xen-devel] [PATCH 7/8] ns16550: command line parsing adjustments
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=__Part07361560.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Allow intermediate parts of the command line options to be absent
(expressed by two immediately succeeding commas).

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/drivers/char/ns16550.c
+++ b/xen/drivers/char/ns16550.c
@@ -556,26 +556,23 @@ static void __init ns16550_parse_port_co
     else if ( (baud =3D simple_strtoul(conf, &conf, 10)) !=3D 0 )
         uart->baud =3D baud;
=20
-    if ( *conf =3D=3D '/')
+    if ( *conf =3D=3D '/' )
     {
         conf++;
         uart->clock_hz =3D simple_strtoul(conf, &conf, 0) << 4;
     }
=20
-    if ( *conf !=3D ',' )
-        goto config_parsed;
-    conf++;
-
-    uart->data_bits =3D simple_strtoul(conf, &conf, 10);
+    if ( *conf =3D=3D ',' && *++conf !=3D ',' )
+    {
+        uart->data_bits =3D simple_strtoul(conf, &conf, 10);
=20
-    uart->parity =3D parse_parity_char(*conf);
-    conf++;
+        uart->parity =3D parse_parity_char(*conf);
=20
-    uart->stop_bits =3D simple_strtoul(conf, &conf, 10);
+        uart->stop_bits =3D simple_strtoul(conf + 1, &conf, 10);
+    }
=20
-    if ( *conf =3D=3D ',' )
+    if ( *conf =3D=3D ',' && *++conf !=3D ',' )
     {
-        conf++;
         if ( strncmp(conf, "pci", 3) =3D=3D 0 )
         {
             if ( pci_uart_config(uart, 1/* skip AMT */, uart - ns16550_com=
) )
@@ -592,24 +589,21 @@ static void __init ns16550_parse_port_co
         {
             uart->io_base =3D simple_strtoul(conf, &conf, 0);
         }
+    }
=20
-        if ( *conf =3D=3D ',' )
-        {
-            conf++;
-            uart->irq =3D simple_strtoul(conf, &conf, 10);
-            if ( *conf =3D=3D ',' )
-            {
-                conf++;
-                uart->ps_bdf_enable =3D 1;
-                parse_pci_bdf(&conf, &uart->ps_bdf[0]);
-                if ( *conf =3D=3D ',' )
-                {
-                    conf++;
-                    uart->pb_bdf_enable =3D 1;
-                    parse_pci_bdf(&conf, &uart->pb_bdf[0]);
-                }
-            }
-        }
+    if ( *conf =3D=3D ',' && *++conf !=3D ',' )
+        uart->irq =3D simple_strtol(conf, &conf, 10);
+
+    if ( *conf =3D=3D ',' && *++conf !=3D ',' )
+    {
+        uart->ps_bdf_enable =3D 1;
+        parse_pci_bdf(&conf, &uart->ps_bdf[0]);
+    }
+
+    if ( *conf =3D=3D ',' && *++conf !=3D ',' )
+    {
+        uart->pb_bdf_enable =3D 1;
+        parse_pci_bdf(&conf, &uart->pb_bdf[0]);
     }
=20
  config_parsed:




--=__Part07361560.0__=
Content-Type: text/plain; name="sercon-ns16550-parse.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="sercon-ns16550-parse.patch"

ns16550: command line parsing adjustments=0A=0AAllow intermediate parts of =
the command line options to be absent=0A(expressed by two immediately =
succeeding commas).=0A=0ASigned-off-by: Jan Beulich <jbeulich@suse.com>=0A=
=0A--- a/xen/drivers/char/ns16550.c=0A+++ b/xen/drivers/char/ns16550.c=0A@@=
 -556,26 +556,23 @@ static void __init ns16550_parse_port_co=0A     else =
if ( (baud =3D simple_strtoul(conf, &conf, 10)) !=3D 0 )=0A         =
uart->baud =3D baud;=0A =0A-    if ( *conf =3D=3D '/')=0A+    if ( *conf =
=3D=3D '/' )=0A     {=0A         conf++;=0A         uart->clock_hz =3D =
simple_strtoul(conf, &conf, 0) << 4;=0A     }=0A =0A-    if ( *conf !=3D =
',' )=0A-        goto config_parsed;=0A-    conf++;=0A-=0A-    uart->data_b=
its =3D simple_strtoul(conf, &conf, 10);=0A+    if ( *conf =3D=3D ',' && =
*++conf !=3D ',' )=0A+    {=0A+        uart->data_bits =3D simple_strtoul(c=
onf, &conf, 10);=0A =0A-    uart->parity =3D parse_parity_char(*conf);=0A- =
   conf++;=0A+        uart->parity =3D parse_parity_char(*conf);=0A =0A-   =
 uart->stop_bits =3D simple_strtoul(conf, &conf, 10);=0A+        uart->stop=
_bits =3D simple_strtoul(conf + 1, &conf, 10);=0A+    }=0A =0A-    if ( =
*conf =3D=3D ',' )=0A+    if ( *conf =3D=3D ',' && *++conf !=3D ',' )=0A   =
  {=0A-        conf++;=0A         if ( strncmp(conf, "pci", 3) =3D=3D 0 =
)=0A         {=0A             if ( pci_uart_config(uart, 1/* skip AMT */, =
uart - ns16550_com) )=0A@@ -592,24 +589,21 @@ static void __init ns16550_pa=
rse_port_co=0A         {=0A             uart->io_base =3D simple_strtoul(co=
nf, &conf, 0);=0A         }=0A+    }=0A =0A-        if ( *conf =3D=3D ',' =
)=0A-        {=0A-            conf++;=0A-            uart->irq =3D =
simple_strtoul(conf, &conf, 10);=0A-            if ( *conf =3D=3D ',' =
)=0A-            {=0A-                conf++;=0A-                uart->ps_b=
df_enable =3D 1;=0A-                parse_pci_bdf(&conf, &uart->ps_bdf[0]);=
=0A-                if ( *conf =3D=3D ',' )=0A-                {=0A-       =
             conf++;=0A-                    uart->pb_bdf_enable =3D 1;=0A- =
                   parse_pci_bdf(&conf, &uart->pb_bdf[0]);=0A-             =
   }=0A-            }=0A-        }=0A+    if ( *conf =3D=3D ',' && *++conf =
!=3D ',' )=0A+        uart->irq =3D simple_strtol(conf, &conf, 10);=0A+=0A+=
    if ( *conf =3D=3D ',' && *++conf !=3D ',' )=0A+    {=0A+        =
uart->ps_bdf_enable =3D 1;=0A+        parse_pci_bdf(&conf, &uart->ps_bdf[0]=
);=0A+    }=0A+=0A+    if ( *conf =3D=3D ',' && *++conf !=3D ',' )=0A+    =
{=0A+        uart->pb_bdf_enable =3D 1;=0A+        parse_pci_bdf(&conf, =
&uart->pb_bdf[0]);=0A     }=0A =0A  config_parsed:=0A
--=__Part07361560.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

--=__Part07361560.0__=--


From xen-devel-bounces@lists.xen.org Tue Sep 11 10:20:50 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 2012 10:20:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TBNaB-0003KG-4X; Tue, 11 Sep 2012 10:20: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 1TBNa9-0003Jw-VR
	for xen-devel@lists.xen.org; Tue, 11 Sep 2012 10:20:38 +0000
Received: from [85.158.139.83:41271] by server-10.bemta-5.messagelabs.com id
	17/E2-10969-5701F405; Tue, 11 Sep 2012 10:20:37 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1347358835!22578385!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQwNzc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1869 invoked from network); 11 Sep 2012 10:20:36 -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;
	11 Sep 2012 10:20:36 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 11 Sep 2012 11:20:35 +0100
Message-Id: <504F2C90020000780009A834@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 11 Sep 2012 11:20:32 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part07361560.0__="
Subject: [Xen-devel] [PATCH 7/8] ns16550: command line parsing adjustments
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=__Part07361560.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Allow intermediate parts of the command line options to be absent
(expressed by two immediately succeeding commas).

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/drivers/char/ns16550.c
+++ b/xen/drivers/char/ns16550.c
@@ -556,26 +556,23 @@ static void __init ns16550_parse_port_co
     else if ( (baud =3D simple_strtoul(conf, &conf, 10)) !=3D 0 )
         uart->baud =3D baud;
=20
-    if ( *conf =3D=3D '/')
+    if ( *conf =3D=3D '/' )
     {
         conf++;
         uart->clock_hz =3D simple_strtoul(conf, &conf, 0) << 4;
     }
=20
-    if ( *conf !=3D ',' )
-        goto config_parsed;
-    conf++;
-
-    uart->data_bits =3D simple_strtoul(conf, &conf, 10);
+    if ( *conf =3D=3D ',' && *++conf !=3D ',' )
+    {
+        uart->data_bits =3D simple_strtoul(conf, &conf, 10);
=20
-    uart->parity =3D parse_parity_char(*conf);
-    conf++;
+        uart->parity =3D parse_parity_char(*conf);
=20
-    uart->stop_bits =3D simple_strtoul(conf, &conf, 10);
+        uart->stop_bits =3D simple_strtoul(conf + 1, &conf, 10);
+    }
=20
-    if ( *conf =3D=3D ',' )
+    if ( *conf =3D=3D ',' && *++conf !=3D ',' )
     {
-        conf++;
         if ( strncmp(conf, "pci", 3) =3D=3D 0 )
         {
             if ( pci_uart_config(uart, 1/* skip AMT */, uart - ns16550_com=
) )
@@ -592,24 +589,21 @@ static void __init ns16550_parse_port_co
         {
             uart->io_base =3D simple_strtoul(conf, &conf, 0);
         }
+    }
=20
-        if ( *conf =3D=3D ',' )
-        {
-            conf++;
-            uart->irq =3D simple_strtoul(conf, &conf, 10);
-            if ( *conf =3D=3D ',' )
-            {
-                conf++;
-                uart->ps_bdf_enable =3D 1;
-                parse_pci_bdf(&conf, &uart->ps_bdf[0]);
-                if ( *conf =3D=3D ',' )
-                {
-                    conf++;
-                    uart->pb_bdf_enable =3D 1;
-                    parse_pci_bdf(&conf, &uart->pb_bdf[0]);
-                }
-            }
-        }
+    if ( *conf =3D=3D ',' && *++conf !=3D ',' )
+        uart->irq =3D simple_strtol(conf, &conf, 10);
+
+    if ( *conf =3D=3D ',' && *++conf !=3D ',' )
+    {
+        uart->ps_bdf_enable =3D 1;
+        parse_pci_bdf(&conf, &uart->ps_bdf[0]);
+    }
+
+    if ( *conf =3D=3D ',' && *++conf !=3D ',' )
+    {
+        uart->pb_bdf_enable =3D 1;
+        parse_pci_bdf(&conf, &uart->pb_bdf[0]);
     }
=20
  config_parsed:




--=__Part07361560.0__=
Content-Type: text/plain; name="sercon-ns16550-parse.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="sercon-ns16550-parse.patch"

ns16550: command line parsing adjustments=0A=0AAllow intermediate parts of =
the command line options to be absent=0A(expressed by two immediately =
succeeding commas).=0A=0ASigned-off-by: Jan Beulich <jbeulich@suse.com>=0A=
=0A--- a/xen/drivers/char/ns16550.c=0A+++ b/xen/drivers/char/ns16550.c=0A@@=
 -556,26 +556,23 @@ static void __init ns16550_parse_port_co=0A     else =
if ( (baud =3D simple_strtoul(conf, &conf, 10)) !=3D 0 )=0A         =
uart->baud =3D baud;=0A =0A-    if ( *conf =3D=3D '/')=0A+    if ( *conf =
=3D=3D '/' )=0A     {=0A         conf++;=0A         uart->clock_hz =3D =
simple_strtoul(conf, &conf, 0) << 4;=0A     }=0A =0A-    if ( *conf !=3D =
',' )=0A-        goto config_parsed;=0A-    conf++;=0A-=0A-    uart->data_b=
its =3D simple_strtoul(conf, &conf, 10);=0A+    if ( *conf =3D=3D ',' && =
*++conf !=3D ',' )=0A+    {=0A+        uart->data_bits =3D simple_strtoul(c=
onf, &conf, 10);=0A =0A-    uart->parity =3D parse_parity_char(*conf);=0A- =
   conf++;=0A+        uart->parity =3D parse_parity_char(*conf);=0A =0A-   =
 uart->stop_bits =3D simple_strtoul(conf, &conf, 10);=0A+        uart->stop=
_bits =3D simple_strtoul(conf + 1, &conf, 10);=0A+    }=0A =0A-    if ( =
*conf =3D=3D ',' )=0A+    if ( *conf =3D=3D ',' && *++conf !=3D ',' )=0A   =
  {=0A-        conf++;=0A         if ( strncmp(conf, "pci", 3) =3D=3D 0 =
)=0A         {=0A             if ( pci_uart_config(uart, 1/* skip AMT */, =
uart - ns16550_com) )=0A@@ -592,24 +589,21 @@ static void __init ns16550_pa=
rse_port_co=0A         {=0A             uart->io_base =3D simple_strtoul(co=
nf, &conf, 0);=0A         }=0A+    }=0A =0A-        if ( *conf =3D=3D ',' =
)=0A-        {=0A-            conf++;=0A-            uart->irq =3D =
simple_strtoul(conf, &conf, 10);=0A-            if ( *conf =3D=3D ',' =
)=0A-            {=0A-                conf++;=0A-                uart->ps_b=
df_enable =3D 1;=0A-                parse_pci_bdf(&conf, &uart->ps_bdf[0]);=
=0A-                if ( *conf =3D=3D ',' )=0A-                {=0A-       =
             conf++;=0A-                    uart->pb_bdf_enable =3D 1;=0A- =
                   parse_pci_bdf(&conf, &uart->pb_bdf[0]);=0A-             =
   }=0A-            }=0A-        }=0A+    if ( *conf =3D=3D ',' && *++conf =
!=3D ',' )=0A+        uart->irq =3D simple_strtol(conf, &conf, 10);=0A+=0A+=
    if ( *conf =3D=3D ',' && *++conf !=3D ',' )=0A+    {=0A+        =
uart->ps_bdf_enable =3D 1;=0A+        parse_pci_bdf(&conf, &uart->ps_bdf[0]=
);=0A+    }=0A+=0A+    if ( *conf =3D=3D ',' && *++conf !=3D ',' )=0A+    =
{=0A+        uart->pb_bdf_enable =3D 1;=0A+        parse_pci_bdf(&conf, =
&uart->pb_bdf[0]);=0A     }=0A =0A  config_parsed:=0A
--=__Part07361560.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

--=__Part07361560.0__=--


From xen-devel-bounces@lists.xen.org Tue Sep 11 10:22:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 2012 10:22:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TBNbK-0003VB-Pu; Tue, 11 Sep 2012 10:21: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 1TBNbJ-0003Uw-9c
	for xen-devel@lists.xen.org; Tue, 11 Sep 2012 10:21:49 +0000
Received: from [85.158.138.51:51007] by server-11.bemta-3.messagelabs.com id
	AB/C2-30250-CB01F405; Tue, 11 Sep 2012 10:21:48 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1347358907!28096687!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQwNzc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30178 invoked from network); 11 Sep 2012 10:21:47 -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;
	11 Sep 2012 10:21:47 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 11 Sep 2012 11:21:46 +0100
Message-Id: <504F2CD9020000780009A838@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 11 Sep 2012 11:21:45 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__PartCEFFDCA9.0__="
Subject: [Xen-devel] [PATCH 8/8] drop tx_fifo_size
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=__PartCEFFDCA9.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

... in favor of having what so far was called tx_empty() return the
amount of space available.

Note that in the pl011.c case, original code and comment disagreed, and
I picked the conservative value for it's ->tx_ready() handler's return
value.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/drivers/char/ehci-dbgp.c
+++ b/xen/drivers/char/ehci-dbgp.c
@@ -1204,7 +1204,7 @@ static void ehci_dbgp_putc(struct serial
         ehci_dbgp_flush(port);
 }
=20
-static int ehci_dbgp_tx_empty(struct serial_port *port)
+static unsigned int ehci_dbgp_tx_ready(struct serial_port *port)
 {
     struct ehci_dbgp *dbgp =3D port->uart;
=20
@@ -1219,11 +1219,8 @@ static int ehci_dbgp_tx_empty(struct ser
     if ( dbgp->state !=3D dbgp_idle && dbgp->out.chunk >=3D DBGP_MAX_PACKE=
T )
         return 0;
=20
-    port->tx_fifo_size =3D DBGP_MAX_PACKET - dbgp->out.chunk;
-    if ( dbgp->state =3D=3D dbgp_idle )
-        port->tx_fifo_size +=3D DBGP_MAX_PACKET;
-
-    return 1;
+    return DBGP_MAX_PACKET - dbgp->out.chunk +
+           (dbgp->state =3D=3D dbgp_idle) * DBGP_MAX_PACKET;
 }
=20
 static int ehci_dbgp_getc(struct serial_port *port, char *pc)
@@ -1347,7 +1344,6 @@ static void __init ehci_dbgp_init_preirq
     if ( ehci_dbgp_setup_preirq(dbgp) )
         ehci_dbgp_status(dbgp, "ehci_dbgp_init_preirq complete");
=20
-    port->tx_fifo_size =3D DBGP_MAX_PACKET;
     dbgp->lock =3D &port->tx_lock;
 }
=20
@@ -1448,7 +1444,7 @@ static struct uart_driver __read_mostly=20
     .endboot      =3D ehci_dbgp_endboot,
     .suspend      =3D ehci_dbgp_suspend,
     .resume       =3D ehci_dbgp_resume,
-    .tx_empty     =3D ehci_dbgp_tx_empty,
+    .tx_ready     =3D ehci_dbgp_tx_ready,
     .putc         =3D ehci_dbgp_putc,
     .flush        =3D ehci_dbgp_flush,
     .getc         =3D ehci_dbgp_getc
--- a/xen/drivers/char/ns16550.c
+++ b/xen/drivers/char/ns16550.c
@@ -38,7 +38,7 @@ string_param("com1", opt_com1);
 string_param("com2", opt_com2);
=20
 static struct ns16550 {
-    int baud, clock_hz, data_bits, parity, stop_bits, irq;
+    int baud, clock_hz, data_bits, parity, stop_bits, fifo_size, irq;
     unsigned long io_base;   /* I/O port or memory-mapped I/O address. */
     char __iomem *remapped_io_base;  /* Remapped virtual address of MMIO. =
*/
     /* UART with IRQ line: interrupt-driven I/O. */
@@ -185,10 +185,11 @@ static void ns16550_poll(void *data)
 #endif
 }
=20
-static int ns16550_tx_empty(struct serial_port *port)
+static unsigned int ns16550_tx_ready(struct serial_port *port)
 {
     struct ns16550 *uart =3D port->uart;
-    return !!(ns_read_reg(uart, LSR) & LSR_THRE);
+
+    return ns_read_reg(uart, LSR) & LSR_THRE ? uart->fifo_size : 0;
 }
=20
 static void ns16550_putc(struct serial_port *port, char c)
@@ -288,7 +289,7 @@ static void __init ns16550_init_preirq(s
     /* Check this really is a 16550+. Otherwise we have no FIFOs. */
     if ( ((ns_read_reg(uart, IIR) & 0xc0) =3D=3D 0xc0) &&
          ((ns_read_reg(uart, FCR) & FCR_TRG14) =3D=3D FCR_TRG14) )
-        port->tx_fifo_size =3D 16;
+        uart->fifo_size =3D 16;
 }
=20
 static void ns16550_setup_postirq(struct ns16550 *uart)
@@ -321,7 +322,7 @@ static void __init ns16550_init_postirq(
     /* Calculate time to fill RX FIFO and/or empty TX FIFO for polling. =
*/
     bits =3D uart->data_bits + uart->stop_bits + !!uart->parity;
     uart->timeout_ms =3D max_t(
-        unsigned int, 1, (bits * port->tx_fifo_size * 1000) / uart->baud);=

+        unsigned int, 1, (bits * uart->fifo_size * 1000) / uart->baud);
=20
     if ( uart->irq > 0 )
     {
@@ -388,7 +389,7 @@ static struct uart_driver __read_mostly=20
     .endboot      =3D ns16550_endboot,
     .suspend      =3D ns16550_suspend,
     .resume       =3D ns16550_resume,
-    .tx_empty     =3D ns16550_tx_empty,
+    .tx_ready     =3D ns16550_tx_ready,
     .putc         =3D ns16550_putc,
     .getc         =3D ns16550_getc,
     .irq          =3D ns16550_irq
@@ -642,6 +643,8 @@ void __init ns16550_init(int index, stru
     uart->stop_bits =3D defaults->stop_bits;
     uart->irq       =3D defaults->irq;
     uart->io_base   =3D defaults->io_base;
+    /* Default is no transmit FIFO. */
+    uart->fifo_size =3D 1;
=20
     ns16550_parse_port_config(uart, (index =3D=3D 0) ? opt_com1 : =
opt_com2);
 }
--- a/xen/drivers/char/pl011.c
+++ b/xen/drivers/char/pl011.c
@@ -156,9 +156,6 @@ static void __init pl011_init_preirq(str
=20
     /* Enable the UART for RX and TX; no flow ctrl */
     uart->regs[CR] =3D RXE | TXE | UARTEN;
-
-    /* Tell the serial framework about our fine 156-character FIFO */
-    port->tx_fifo_size =3D 16;
 }
=20
 static void __init pl011_init_postirq(struct serial_port *port)
@@ -192,10 +189,10 @@ static void pl011_resume(struct serial_p
     BUG(); // XXX
 }
=20
-static int pl011_tx_empty(struct serial_port *port)
+static unsigned int pl011_tx_ready(struct serial_port *port)
 {
     struct pl011 *uart =3D port->uart;
-    return !!(uart->regs[FR] & TXFE);
+    return uart->regs[FR] & TXFE ? 16 : 0;
 }
=20
 static void pl011_putc(struct serial_port *port, char c)
@@ -227,7 +224,7 @@ static struct uart_driver __read_mostly=20
     .endboot      =3D NULL,
     .suspend      =3D pl011_suspend,
     .resume       =3D pl011_resume,
-    .tx_empty     =3D pl011_tx_empty,
+    .tx_ready     =3D pl011_tx_ready,
     .putc         =3D pl011_putc,
     .getc         =3D pl011_getc,
     .irq          =3D pl011_irq
--- a/xen/drivers/char/serial.c
+++ b/xen/drivers/char/serial.c
@@ -59,7 +59,7 @@ void serial_rx_interrupt(struct serial_p
=20
 void serial_tx_interrupt(struct serial_port *port, struct cpu_user_regs =
*regs)
 {
-    int i;
+    unsigned int i, n;
     unsigned long flags;
=20
     local_irq_save(flags);
@@ -71,23 +71,20 @@ void serial_tx_interrupt(struct serial_p
      */
     while ( !spin_trylock(&port->tx_lock) )
     {
-        if ( !port->driver->tx_empty(port) )
+        if ( !port->driver->tx_ready(port) )
             goto out;
         cpu_relax();
     }
=20
-    if ( port->driver->tx_empty(port) )
+    for ( i =3D 0, n =3D port->driver->tx_ready(port); i < n; i++ )
     {
-        for ( i =3D 0; i < port->tx_fifo_size; i++ )
-        {
-            if ( port->txbufc =3D=3D port->txbufp )
-                break;
-            port->driver->putc(
-                port, port->txbuf[mask_serial_txbuf_idx(port->txbufc++)]);=

-        }
-        if ( i && port->driver->flush )
-            port->driver->flush(port);
+        if ( port->txbufc =3D=3D port->txbufp )
+            break;
+        port->driver->putc(
+            port, port->txbuf[mask_serial_txbuf_idx(port->txbufc++)]);
     }
+    if ( i && port->driver->flush )
+        port->driver->flush(port);
=20
     spin_unlock(&port->tx_lock);
=20
@@ -114,10 +111,11 @@ static void __serial_putc(struct serial_
             if ( port->tx_log_everything )
             {
                 /* Buffer is full: we spin waiting for space to appear. =
*/
-                int i;
-                while ( !port->driver->tx_empty(port) )
+                unsigned int n;
+
+                while ( (n =3D port->driver->tx_ready(port)) =3D=3D 0 )
                     cpu_relax();
-                for ( i =3D 0; i < port->tx_fifo_size; i++ )
+                while ( n-- )
                     port->driver->putc(
                         port,
                         port->txbuf[mask_serial_txbuf_idx(port->txbufc++)]=
);
@@ -132,7 +130,7 @@ static void __serial_putc(struct serial_
         }
=20
         if ( ((port->txbufp - port->txbufc) =3D=3D 0) &&
-                  port->driver->tx_empty(port) )
+             port->driver->tx_ready(port) )
         {
             /* Buffer and UART FIFO are both empty. */
             port->driver->putc(port, c);
@@ -143,10 +141,10 @@ static void __serial_putc(struct serial_
             port->txbuf[mask_serial_txbuf_idx(port->txbufp++)] =3D c;
         }
     }
-    else if ( port->driver->tx_empty )
+    else if ( port->driver->tx_ready )
     {
         /* Synchronous finite-capacity transmitter. */
-        while ( !port->driver->tx_empty(port) )
+        while ( !port->driver->tx_ready(port) )
             cpu_relax();
         port->driver->putc(port, c);
     }
@@ -386,7 +384,7 @@ void serial_start_sync(int handle)
     {
         while ( (port->txbufp - port->txbufc) !=3D 0 )
         {
-            while ( !port->driver->tx_empty(port) )
+            while ( !port->driver->tx_ready(port) )
                 cpu_relax();
             port->driver->putc(
                 port, port->txbuf[mask_serial_txbuf_idx(port->txbufc++)]);=

@@ -506,14 +504,11 @@ void __init serial_register_uart(int idx
     /* Store UART-specific info. */
     com[idx].driver =3D driver;
     com[idx].uart   =3D uart;
-
-    /* Default is no transmit FIFO. */
-    com[idx].tx_fifo_size =3D 1;
 }
=20
 void __init serial_async_transmit(struct serial_port *port)
 {
-    BUG_ON(!port->driver->tx_empty);
+    BUG_ON(!port->driver->tx_ready);
     if ( port->txbuf !=3D NULL )
         return;
     if ( serial_txbufsz < PAGE_SIZE )
--- a/xen/include/xen/serial.h
+++ b/xen/include/xen/serial.h
@@ -36,8 +36,6 @@ struct serial_port {
     struct uart_driver *driver;
     void               *uart;
     enum serial_port_state state;
-    /* Number of characters the port can hold for transmit. */
-    int                 tx_fifo_size;
     /* Transmit data buffer (interrupt-driven uart). */
     char               *txbuf;
     unsigned int        txbufp, txbufc;
@@ -63,8 +61,8 @@ struct uart_driver {
     /* Driver suspend/resume. */
     void (*suspend)(struct serial_port *);
     void (*resume)(struct serial_port *);
-    /* Transmit FIFO ready to receive up to @tx_fifo_size characters? */
-    int  (*tx_empty)(struct serial_port *);
+    /* Return number of characters the port can hold for transmit. */
+    unsigned int (*tx_ready)(struct serial_port *);
     /* Put a character onto the serial line. */
     void (*putc)(struct serial_port *, char);
     /* Flush accumulated characters. */



--=__PartCEFFDCA9.0__=
Content-Type: text/plain; name="sercon-drop-tx_fifo_size.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="sercon-drop-tx_fifo_size.patch"

drop tx_fifo_size=0A=0A... in favor of having what so far was called =
tx_empty() return the=0Aamount of space available.=0A=0ANote that in the =
pl011.c case, original code and comment disagreed, and=0AI picked the =
conservative value for it's ->tx_ready() handler's return=0Avalue.=0A=0ASig=
ned-off-by: Jan Beulich <jbeulich@suse.com>=0A=0A--- a/xen/drivers/char/ehc=
i-dbgp.c=0A+++ b/xen/drivers/char/ehci-dbgp.c=0A@@ -1204,7 +1204,7 @@ =
static void ehci_dbgp_putc(struct serial=0A         ehci_dbgp_flush(port);=
=0A }=0A =0A-static int ehci_dbgp_tx_empty(struct serial_port *port)=0A+sta=
tic unsigned int ehci_dbgp_tx_ready(struct serial_port *port)=0A {=0A     =
struct ehci_dbgp *dbgp =3D port->uart;=0A =0A@@ -1219,11 +1219,8 @@ static =
int ehci_dbgp_tx_empty(struct ser=0A     if ( dbgp->state !=3D dbgp_idle =
&& dbgp->out.chunk >=3D DBGP_MAX_PACKET )=0A         return 0;=0A =0A-    =
port->tx_fifo_size =3D DBGP_MAX_PACKET - dbgp->out.chunk;=0A-    if ( =
dbgp->state =3D=3D dbgp_idle )=0A-        port->tx_fifo_size +=3D =
DBGP_MAX_PACKET;=0A-=0A-    return 1;=0A+    return DBGP_MAX_PACKET - =
dbgp->out.chunk +=0A+           (dbgp->state =3D=3D dbgp_idle) * DBGP_MAX_P=
ACKET;=0A }=0A =0A static int ehci_dbgp_getc(struct serial_port *port, =
char *pc)=0A@@ -1347,7 +1344,6 @@ static void __init ehci_dbgp_init_preirq=
=0A     if ( ehci_dbgp_setup_preirq(dbgp) )=0A         ehci_dbgp_status(dbg=
p, "ehci_dbgp_init_preirq complete");=0A =0A-    port->tx_fifo_size =3D =
DBGP_MAX_PACKET;=0A     dbgp->lock =3D &port->tx_lock;=0A }=0A =0A@@ =
-1448,7 +1444,7 @@ static struct uart_driver __read_mostly =0A     =
.endboot      =3D ehci_dbgp_endboot,=0A     .suspend      =3D ehci_dbgp_sus=
pend,=0A     .resume       =3D ehci_dbgp_resume,=0A-    .tx_empty     =3D =
ehci_dbgp_tx_empty,=0A+    .tx_ready     =3D ehci_dbgp_tx_ready,=0A     =
.putc         =3D ehci_dbgp_putc,=0A     .flush        =3D ehci_dbgp_flush,=
=0A     .getc         =3D ehci_dbgp_getc=0A--- a/xen/drivers/char/ns16550.c=
=0A+++ b/xen/drivers/char/ns16550.c=0A@@ -38,7 +38,7 @@ string_param("com1"=
, opt_com1);=0A string_param("com2", opt_com2);=0A =0A static struct =
ns16550 {=0A-    int baud, clock_hz, data_bits, parity, stop_bits, =
irq;=0A+    int baud, clock_hz, data_bits, parity, stop_bits, fifo_size, =
irq;=0A     unsigned long io_base;   /* I/O port or memory-mapped I/O =
address. */=0A     char __iomem *remapped_io_base;  /* Remapped virtual =
address of MMIO. */=0A     /* UART with IRQ line: interrupt-driven I/O. =
*/=0A@@ -185,10 +185,11 @@ static void ns16550_poll(void *data)=0A =
#endif=0A }=0A =0A-static int ns16550_tx_empty(struct serial_port =
*port)=0A+static unsigned int ns16550_tx_ready(struct serial_port =
*port)=0A {=0A     struct ns16550 *uart =3D port->uart;=0A-    return =
!!(ns_read_reg(uart, LSR) & LSR_THRE);=0A+=0A+    return ns_read_reg(uart, =
LSR) & LSR_THRE ? uart->fifo_size : 0;=0A }=0A =0A static void ns16550_putc=
(struct serial_port *port, char c)=0A@@ -288,7 +289,7 @@ static void =
__init ns16550_init_preirq(s=0A     /* Check this really is a 16550+. =
Otherwise we have no FIFOs. */=0A     if ( ((ns_read_reg(uart, IIR) & =
0xc0) =3D=3D 0xc0) &&=0A          ((ns_read_reg(uart, FCR) & FCR_TRG14) =
=3D=3D FCR_TRG14) )=0A-        port->tx_fifo_size =3D 16;=0A+        =
uart->fifo_size =3D 16;=0A }=0A =0A static void ns16550_setup_postirq(struc=
t ns16550 *uart)=0A@@ -321,7 +322,7 @@ static void __init ns16550_init_post=
irq(=0A     /* Calculate time to fill RX FIFO and/or empty TX FIFO for =
polling. */=0A     bits =3D uart->data_bits + uart->stop_bits + !!uart->par=
ity;=0A     uart->timeout_ms =3D max_t(=0A-        unsigned int, 1, (bits =
* port->tx_fifo_size * 1000) / uart->baud);=0A+        unsigned int, 1, =
(bits * uart->fifo_size * 1000) / uart->baud);=0A =0A     if ( uart->irq > =
0 )=0A     {=0A@@ -388,7 +389,7 @@ static struct uart_driver __read_mostly =
=0A     .endboot      =3D ns16550_endboot,=0A     .suspend      =3D =
ns16550_suspend,=0A     .resume       =3D ns16550_resume,=0A-    .tx_empty =
    =3D ns16550_tx_empty,=0A+    .tx_ready     =3D ns16550_tx_ready,=0A    =
 .putc         =3D ns16550_putc,=0A     .getc         =3D ns16550_getc,=0A =
    .irq          =3D ns16550_irq=0A@@ -642,6 +643,8 @@ void __init =
ns16550_init(int index, stru=0A     uart->stop_bits =3D defaults->stop_bits=
;=0A     uart->irq       =3D defaults->irq;=0A     uart->io_base   =3D =
defaults->io_base;=0A+    /* Default is no transmit FIFO. */=0A+    =
uart->fifo_size =3D 1;=0A =0A     ns16550_parse_port_config(uart, (index =
=3D=3D 0) ? opt_com1 : opt_com2);=0A }=0A--- a/xen/drivers/char/pl011.c=0A+=
++ b/xen/drivers/char/pl011.c=0A@@ -156,9 +156,6 @@ static void __init =
pl011_init_preirq(str=0A =0A     /* Enable the UART for RX and TX; no flow =
ctrl */=0A     uart->regs[CR] =3D RXE | TXE | UARTEN;=0A-=0A-    /* Tell =
the serial framework about our fine 156-character FIFO */=0A-    port->tx_f=
ifo_size =3D 16;=0A }=0A =0A static void __init pl011_init_postirq(struct =
serial_port *port)=0A@@ -192,10 +189,10 @@ static void pl011_resume(struct =
serial_p=0A     BUG(); // XXX=0A }=0A =0A-static int pl011_tx_empty(struct =
serial_port *port)=0A+static unsigned int pl011_tx_ready(struct serial_port=
 *port)=0A {=0A     struct pl011 *uart =3D port->uart;=0A-    return =
!!(uart->regs[FR] & TXFE);=0A+    return uart->regs[FR] & TXFE ? 16 : =
0;=0A }=0A =0A static void pl011_putc(struct serial_port *port, char =
c)=0A@@ -227,7 +224,7 @@ static struct uart_driver __read_mostly =0A     =
.endboot      =3D NULL,=0A     .suspend      =3D pl011_suspend,=0A     =
.resume       =3D pl011_resume,=0A-    .tx_empty     =3D pl011_tx_empty,=0A=
+    .tx_ready     =3D pl011_tx_ready,=0A     .putc         =3D pl011_putc,=
=0A     .getc         =3D pl011_getc,=0A     .irq          =3D pl011_irq=0A=
--- a/xen/drivers/char/serial.c=0A+++ b/xen/drivers/char/serial.c=0A@@ =
-59,7 +59,7 @@ void serial_rx_interrupt(struct serial_p=0A =0A void =
serial_tx_interrupt(struct serial_port *port, struct cpu_user_regs =
*regs)=0A {=0A-    int i;=0A+    unsigned int i, n;=0A     unsigned long =
flags;=0A =0A     local_irq_save(flags);=0A@@ -71,23 +71,20 @@ void =
serial_tx_interrupt(struct serial_p=0A      */=0A     while ( !spin_trylock=
(&port->tx_lock) )=0A     {=0A-        if ( !port->driver->tx_empty(port) =
)=0A+        if ( !port->driver->tx_ready(port) )=0A             goto =
out;=0A         cpu_relax();=0A     }=0A =0A-    if ( port->driver->tx_empt=
y(port) )=0A+    for ( i =3D 0, n =3D port->driver->tx_ready(port); i < n; =
i++ )=0A     {=0A-        for ( i =3D 0; i < port->tx_fifo_size; i++ )=0A- =
       {=0A-            if ( port->txbufc =3D=3D port->txbufp )=0A-        =
        break;=0A-            port->driver->putc(=0A-                port, =
port->txbuf[mask_serial_txbuf_idx(port->txbufc++)]);=0A-        }=0A-      =
  if ( i && port->driver->flush )=0A-            port->driver->flush(port);=
=0A+        if ( port->txbufc =3D=3D port->txbufp )=0A+            =
break;=0A+        port->driver->putc(=0A+            port, port->txbuf[mask=
_serial_txbuf_idx(port->txbufc++)]);=0A     }=0A+    if ( i && port->driver=
->flush )=0A+        port->driver->flush(port);=0A =0A     spin_unlock(&por=
t->tx_lock);=0A =0A@@ -114,10 +111,11 @@ static void __serial_putc(struct =
serial_=0A             if ( port->tx_log_everything )=0A             {=0A  =
               /* Buffer is full: we spin waiting for space to appear. =
*/=0A-                int i;=0A-                while ( !port->driver->tx_e=
mpty(port) )=0A+                unsigned int n;=0A+=0A+                =
while ( (n =3D port->driver->tx_ready(port)) =3D=3D 0 )=0A                 =
    cpu_relax();=0A-                for ( i =3D 0; i < port->tx_fifo_size; =
i++ )=0A+                while ( n-- )=0A                     port->driver-=
>putc(=0A                         port,=0A                         =
port->txbuf[mask_serial_txbuf_idx(port->txbufc++)]);=0A@@ -132,7 +130,7 @@ =
static void __serial_putc(struct serial_=0A         }=0A =0A         if ( =
((port->txbufp - port->txbufc) =3D=3D 0) &&=0A-                  port->driv=
er->tx_empty(port) )=0A+             port->driver->tx_ready(port) )=0A     =
    {=0A             /* Buffer and UART FIFO are both empty. */=0A         =
    port->driver->putc(port, c);=0A@@ -143,10 +141,10 @@ static void =
__serial_putc(struct serial_=0A             port->txbuf[mask_serial_txbuf_i=
dx(port->txbufp++)] =3D c;=0A         }=0A     }=0A-    else if ( =
port->driver->tx_empty )=0A+    else if ( port->driver->tx_ready )=0A     =
{=0A         /* Synchronous finite-capacity transmitter. */=0A-        =
while ( !port->driver->tx_empty(port) )=0A+        while ( !port->driver->t=
x_ready(port) )=0A             cpu_relax();=0A         port->driver->putc(p=
ort, c);=0A     }=0A@@ -386,7 +384,7 @@ void serial_start_sync(int =
handle)=0A     {=0A         while ( (port->txbufp - port->txbufc) !=3D 0 =
)=0A         {=0A-            while ( !port->driver->tx_empty(port) )=0A+  =
          while ( !port->driver->tx_ready(port) )=0A                 =
cpu_relax();=0A             port->driver->putc(=0A                 port, =
port->txbuf[mask_serial_txbuf_idx(port->txbufc++)]);=0A@@ -506,14 +504,11 =
@@ void __init serial_register_uart(int idx=0A     /* Store UART-specific =
info. */=0A     com[idx].driver =3D driver;=0A     com[idx].uart   =3D =
uart;=0A-=0A-    /* Default is no transmit FIFO. */=0A-    com[idx].tx_fifo=
_size =3D 1;=0A }=0A =0A void __init serial_async_transmit(struct =
serial_port *port)=0A {=0A-    BUG_ON(!port->driver->tx_empty);=0A+    =
BUG_ON(!port->driver->tx_ready);=0A     if ( port->txbuf !=3D NULL )=0A    =
     return;=0A     if ( serial_txbufsz < PAGE_SIZE )=0A--- a/xen/include/x=
en/serial.h=0A+++ b/xen/include/xen/serial.h=0A@@ -36,8 +36,6 @@ struct =
serial_port {=0A     struct uart_driver *driver;=0A     void               =
*uart;=0A     enum serial_port_state state;=0A-    /* Number of characters =
the port can hold for transmit. */=0A-    int                 tx_fifo_size;=
=0A     /* Transmit data buffer (interrupt-driven uart). */=0A     char    =
           *txbuf;=0A     unsigned int        txbufp, txbufc;=0A@@ -63,8 =
+61,8 @@ struct uart_driver {=0A     /* Driver suspend/resume. */=0A     =
void (*suspend)(struct serial_port *);=0A     void (*resume)(struct =
serial_port *);=0A-    /* Transmit FIFO ready to receive up to @tx_fifo_siz=
e characters? */=0A-    int  (*tx_empty)(struct serial_port *);=0A+    /* =
Return number of characters the port can hold for transmit. */=0A+    =
unsigned int (*tx_ready)(struct serial_port *);=0A     /* Put a character =
onto the serial line. */=0A     void (*putc)(struct serial_port *, =
char);=0A     /* Flush accumulated characters. */=0A
--=__PartCEFFDCA9.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

--=__PartCEFFDCA9.0__=--


From xen-devel-bounces@lists.xen.org Tue Sep 11 10:22:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 2012 10:22:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TBNbK-0003VB-Pu; Tue, 11 Sep 2012 10:21: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 1TBNbJ-0003Uw-9c
	for xen-devel@lists.xen.org; Tue, 11 Sep 2012 10:21:49 +0000
Received: from [85.158.138.51:51007] by server-11.bemta-3.messagelabs.com id
	AB/C2-30250-CB01F405; Tue, 11 Sep 2012 10:21:48 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1347358907!28096687!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQwNzc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30178 invoked from network); 11 Sep 2012 10:21:47 -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;
	11 Sep 2012 10:21:47 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 11 Sep 2012 11:21:46 +0100
Message-Id: <504F2CD9020000780009A838@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 11 Sep 2012 11:21:45 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__PartCEFFDCA9.0__="
Subject: [Xen-devel] [PATCH 8/8] drop tx_fifo_size
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=__PartCEFFDCA9.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

... in favor of having what so far was called tx_empty() return the
amount of space available.

Note that in the pl011.c case, original code and comment disagreed, and
I picked the conservative value for it's ->tx_ready() handler's return
value.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/drivers/char/ehci-dbgp.c
+++ b/xen/drivers/char/ehci-dbgp.c
@@ -1204,7 +1204,7 @@ static void ehci_dbgp_putc(struct serial
         ehci_dbgp_flush(port);
 }
=20
-static int ehci_dbgp_tx_empty(struct serial_port *port)
+static unsigned int ehci_dbgp_tx_ready(struct serial_port *port)
 {
     struct ehci_dbgp *dbgp =3D port->uart;
=20
@@ -1219,11 +1219,8 @@ static int ehci_dbgp_tx_empty(struct ser
     if ( dbgp->state !=3D dbgp_idle && dbgp->out.chunk >=3D DBGP_MAX_PACKE=
T )
         return 0;
=20
-    port->tx_fifo_size =3D DBGP_MAX_PACKET - dbgp->out.chunk;
-    if ( dbgp->state =3D=3D dbgp_idle )
-        port->tx_fifo_size +=3D DBGP_MAX_PACKET;
-
-    return 1;
+    return DBGP_MAX_PACKET - dbgp->out.chunk +
+           (dbgp->state =3D=3D dbgp_idle) * DBGP_MAX_PACKET;
 }
=20
 static int ehci_dbgp_getc(struct serial_port *port, char *pc)
@@ -1347,7 +1344,6 @@ static void __init ehci_dbgp_init_preirq
     if ( ehci_dbgp_setup_preirq(dbgp) )
         ehci_dbgp_status(dbgp, "ehci_dbgp_init_preirq complete");
=20
-    port->tx_fifo_size =3D DBGP_MAX_PACKET;
     dbgp->lock =3D &port->tx_lock;
 }
=20
@@ -1448,7 +1444,7 @@ static struct uart_driver __read_mostly=20
     .endboot      =3D ehci_dbgp_endboot,
     .suspend      =3D ehci_dbgp_suspend,
     .resume       =3D ehci_dbgp_resume,
-    .tx_empty     =3D ehci_dbgp_tx_empty,
+    .tx_ready     =3D ehci_dbgp_tx_ready,
     .putc         =3D ehci_dbgp_putc,
     .flush        =3D ehci_dbgp_flush,
     .getc         =3D ehci_dbgp_getc
--- a/xen/drivers/char/ns16550.c
+++ b/xen/drivers/char/ns16550.c
@@ -38,7 +38,7 @@ string_param("com1", opt_com1);
 string_param("com2", opt_com2);
=20
 static struct ns16550 {
-    int baud, clock_hz, data_bits, parity, stop_bits, irq;
+    int baud, clock_hz, data_bits, parity, stop_bits, fifo_size, irq;
     unsigned long io_base;   /* I/O port or memory-mapped I/O address. */
     char __iomem *remapped_io_base;  /* Remapped virtual address of MMIO. =
*/
     /* UART with IRQ line: interrupt-driven I/O. */
@@ -185,10 +185,11 @@ static void ns16550_poll(void *data)
 #endif
 }
=20
-static int ns16550_tx_empty(struct serial_port *port)
+static unsigned int ns16550_tx_ready(struct serial_port *port)
 {
     struct ns16550 *uart =3D port->uart;
-    return !!(ns_read_reg(uart, LSR) & LSR_THRE);
+
+    return ns_read_reg(uart, LSR) & LSR_THRE ? uart->fifo_size : 0;
 }
=20
 static void ns16550_putc(struct serial_port *port, char c)
@@ -288,7 +289,7 @@ static void __init ns16550_init_preirq(s
     /* Check this really is a 16550+. Otherwise we have no FIFOs. */
     if ( ((ns_read_reg(uart, IIR) & 0xc0) =3D=3D 0xc0) &&
          ((ns_read_reg(uart, FCR) & FCR_TRG14) =3D=3D FCR_TRG14) )
-        port->tx_fifo_size =3D 16;
+        uart->fifo_size =3D 16;
 }
=20
 static void ns16550_setup_postirq(struct ns16550 *uart)
@@ -321,7 +322,7 @@ static void __init ns16550_init_postirq(
     /* Calculate time to fill RX FIFO and/or empty TX FIFO for polling. =
*/
     bits =3D uart->data_bits + uart->stop_bits + !!uart->parity;
     uart->timeout_ms =3D max_t(
-        unsigned int, 1, (bits * port->tx_fifo_size * 1000) / uart->baud);=

+        unsigned int, 1, (bits * uart->fifo_size * 1000) / uart->baud);
=20
     if ( uart->irq > 0 )
     {
@@ -388,7 +389,7 @@ static struct uart_driver __read_mostly=20
     .endboot      =3D ns16550_endboot,
     .suspend      =3D ns16550_suspend,
     .resume       =3D ns16550_resume,
-    .tx_empty     =3D ns16550_tx_empty,
+    .tx_ready     =3D ns16550_tx_ready,
     .putc         =3D ns16550_putc,
     .getc         =3D ns16550_getc,
     .irq          =3D ns16550_irq
@@ -642,6 +643,8 @@ void __init ns16550_init(int index, stru
     uart->stop_bits =3D defaults->stop_bits;
     uart->irq       =3D defaults->irq;
     uart->io_base   =3D defaults->io_base;
+    /* Default is no transmit FIFO. */
+    uart->fifo_size =3D 1;
=20
     ns16550_parse_port_config(uart, (index =3D=3D 0) ? opt_com1 : =
opt_com2);
 }
--- a/xen/drivers/char/pl011.c
+++ b/xen/drivers/char/pl011.c
@@ -156,9 +156,6 @@ static void __init pl011_init_preirq(str
=20
     /* Enable the UART for RX and TX; no flow ctrl */
     uart->regs[CR] =3D RXE | TXE | UARTEN;
-
-    /* Tell the serial framework about our fine 156-character FIFO */
-    port->tx_fifo_size =3D 16;
 }
=20
 static void __init pl011_init_postirq(struct serial_port *port)
@@ -192,10 +189,10 @@ static void pl011_resume(struct serial_p
     BUG(); // XXX
 }
=20
-static int pl011_tx_empty(struct serial_port *port)
+static unsigned int pl011_tx_ready(struct serial_port *port)
 {
     struct pl011 *uart =3D port->uart;
-    return !!(uart->regs[FR] & TXFE);
+    return uart->regs[FR] & TXFE ? 16 : 0;
 }
=20
 static void pl011_putc(struct serial_port *port, char c)
@@ -227,7 +224,7 @@ static struct uart_driver __read_mostly=20
     .endboot      =3D NULL,
     .suspend      =3D pl011_suspend,
     .resume       =3D pl011_resume,
-    .tx_empty     =3D pl011_tx_empty,
+    .tx_ready     =3D pl011_tx_ready,
     .putc         =3D pl011_putc,
     .getc         =3D pl011_getc,
     .irq          =3D pl011_irq
--- a/xen/drivers/char/serial.c
+++ b/xen/drivers/char/serial.c
@@ -59,7 +59,7 @@ void serial_rx_interrupt(struct serial_p
=20
 void serial_tx_interrupt(struct serial_port *port, struct cpu_user_regs =
*regs)
 {
-    int i;
+    unsigned int i, n;
     unsigned long flags;
=20
     local_irq_save(flags);
@@ -71,23 +71,20 @@ void serial_tx_interrupt(struct serial_p
      */
     while ( !spin_trylock(&port->tx_lock) )
     {
-        if ( !port->driver->tx_empty(port) )
+        if ( !port->driver->tx_ready(port) )
             goto out;
         cpu_relax();
     }
=20
-    if ( port->driver->tx_empty(port) )
+    for ( i =3D 0, n =3D port->driver->tx_ready(port); i < n; i++ )
     {
-        for ( i =3D 0; i < port->tx_fifo_size; i++ )
-        {
-            if ( port->txbufc =3D=3D port->txbufp )
-                break;
-            port->driver->putc(
-                port, port->txbuf[mask_serial_txbuf_idx(port->txbufc++)]);=

-        }
-        if ( i && port->driver->flush )
-            port->driver->flush(port);
+        if ( port->txbufc =3D=3D port->txbufp )
+            break;
+        port->driver->putc(
+            port, port->txbuf[mask_serial_txbuf_idx(port->txbufc++)]);
     }
+    if ( i && port->driver->flush )
+        port->driver->flush(port);
=20
     spin_unlock(&port->tx_lock);
=20
@@ -114,10 +111,11 @@ static void __serial_putc(struct serial_
             if ( port->tx_log_everything )
             {
                 /* Buffer is full: we spin waiting for space to appear. =
*/
-                int i;
-                while ( !port->driver->tx_empty(port) )
+                unsigned int n;
+
+                while ( (n =3D port->driver->tx_ready(port)) =3D=3D 0 )
                     cpu_relax();
-                for ( i =3D 0; i < port->tx_fifo_size; i++ )
+                while ( n-- )
                     port->driver->putc(
                         port,
                         port->txbuf[mask_serial_txbuf_idx(port->txbufc++)]=
);
@@ -132,7 +130,7 @@ static void __serial_putc(struct serial_
         }
=20
         if ( ((port->txbufp - port->txbufc) =3D=3D 0) &&
-                  port->driver->tx_empty(port) )
+             port->driver->tx_ready(port) )
         {
             /* Buffer and UART FIFO are both empty. */
             port->driver->putc(port, c);
@@ -143,10 +141,10 @@ static void __serial_putc(struct serial_
             port->txbuf[mask_serial_txbuf_idx(port->txbufp++)] =3D c;
         }
     }
-    else if ( port->driver->tx_empty )
+    else if ( port->driver->tx_ready )
     {
         /* Synchronous finite-capacity transmitter. */
-        while ( !port->driver->tx_empty(port) )
+        while ( !port->driver->tx_ready(port) )
             cpu_relax();
         port->driver->putc(port, c);
     }
@@ -386,7 +384,7 @@ void serial_start_sync(int handle)
     {
         while ( (port->txbufp - port->txbufc) !=3D 0 )
         {
-            while ( !port->driver->tx_empty(port) )
+            while ( !port->driver->tx_ready(port) )
                 cpu_relax();
             port->driver->putc(
                 port, port->txbuf[mask_serial_txbuf_idx(port->txbufc++)]);=

@@ -506,14 +504,11 @@ void __init serial_register_uart(int idx
     /* Store UART-specific info. */
     com[idx].driver =3D driver;
     com[idx].uart   =3D uart;
-
-    /* Default is no transmit FIFO. */
-    com[idx].tx_fifo_size =3D 1;
 }
=20
 void __init serial_async_transmit(struct serial_port *port)
 {
-    BUG_ON(!port->driver->tx_empty);
+    BUG_ON(!port->driver->tx_ready);
     if ( port->txbuf !=3D NULL )
         return;
     if ( serial_txbufsz < PAGE_SIZE )
--- a/xen/include/xen/serial.h
+++ b/xen/include/xen/serial.h
@@ -36,8 +36,6 @@ struct serial_port {
     struct uart_driver *driver;
     void               *uart;
     enum serial_port_state state;
-    /* Number of characters the port can hold for transmit. */
-    int                 tx_fifo_size;
     /* Transmit data buffer (interrupt-driven uart). */
     char               *txbuf;
     unsigned int        txbufp, txbufc;
@@ -63,8 +61,8 @@ struct uart_driver {
     /* Driver suspend/resume. */
     void (*suspend)(struct serial_port *);
     void (*resume)(struct serial_port *);
-    /* Transmit FIFO ready to receive up to @tx_fifo_size characters? */
-    int  (*tx_empty)(struct serial_port *);
+    /* Return number of characters the port can hold for transmit. */
+    unsigned int (*tx_ready)(struct serial_port *);
     /* Put a character onto the serial line. */
     void (*putc)(struct serial_port *, char);
     /* Flush accumulated characters. */



--=__PartCEFFDCA9.0__=
Content-Type: text/plain; name="sercon-drop-tx_fifo_size.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="sercon-drop-tx_fifo_size.patch"

drop tx_fifo_size=0A=0A... in favor of having what so far was called =
tx_empty() return the=0Aamount of space available.=0A=0ANote that in the =
pl011.c case, original code and comment disagreed, and=0AI picked the =
conservative value for it's ->tx_ready() handler's return=0Avalue.=0A=0ASig=
ned-off-by: Jan Beulich <jbeulich@suse.com>=0A=0A--- a/xen/drivers/char/ehc=
i-dbgp.c=0A+++ b/xen/drivers/char/ehci-dbgp.c=0A@@ -1204,7 +1204,7 @@ =
static void ehci_dbgp_putc(struct serial=0A         ehci_dbgp_flush(port);=
=0A }=0A =0A-static int ehci_dbgp_tx_empty(struct serial_port *port)=0A+sta=
tic unsigned int ehci_dbgp_tx_ready(struct serial_port *port)=0A {=0A     =
struct ehci_dbgp *dbgp =3D port->uart;=0A =0A@@ -1219,11 +1219,8 @@ static =
int ehci_dbgp_tx_empty(struct ser=0A     if ( dbgp->state !=3D dbgp_idle =
&& dbgp->out.chunk >=3D DBGP_MAX_PACKET )=0A         return 0;=0A =0A-    =
port->tx_fifo_size =3D DBGP_MAX_PACKET - dbgp->out.chunk;=0A-    if ( =
dbgp->state =3D=3D dbgp_idle )=0A-        port->tx_fifo_size +=3D =
DBGP_MAX_PACKET;=0A-=0A-    return 1;=0A+    return DBGP_MAX_PACKET - =
dbgp->out.chunk +=0A+           (dbgp->state =3D=3D dbgp_idle) * DBGP_MAX_P=
ACKET;=0A }=0A =0A static int ehci_dbgp_getc(struct serial_port *port, =
char *pc)=0A@@ -1347,7 +1344,6 @@ static void __init ehci_dbgp_init_preirq=
=0A     if ( ehci_dbgp_setup_preirq(dbgp) )=0A         ehci_dbgp_status(dbg=
p, "ehci_dbgp_init_preirq complete");=0A =0A-    port->tx_fifo_size =3D =
DBGP_MAX_PACKET;=0A     dbgp->lock =3D &port->tx_lock;=0A }=0A =0A@@ =
-1448,7 +1444,7 @@ static struct uart_driver __read_mostly =0A     =
.endboot      =3D ehci_dbgp_endboot,=0A     .suspend      =3D ehci_dbgp_sus=
pend,=0A     .resume       =3D ehci_dbgp_resume,=0A-    .tx_empty     =3D =
ehci_dbgp_tx_empty,=0A+    .tx_ready     =3D ehci_dbgp_tx_ready,=0A     =
.putc         =3D ehci_dbgp_putc,=0A     .flush        =3D ehci_dbgp_flush,=
=0A     .getc         =3D ehci_dbgp_getc=0A--- a/xen/drivers/char/ns16550.c=
=0A+++ b/xen/drivers/char/ns16550.c=0A@@ -38,7 +38,7 @@ string_param("com1"=
, opt_com1);=0A string_param("com2", opt_com2);=0A =0A static struct =
ns16550 {=0A-    int baud, clock_hz, data_bits, parity, stop_bits, =
irq;=0A+    int baud, clock_hz, data_bits, parity, stop_bits, fifo_size, =
irq;=0A     unsigned long io_base;   /* I/O port or memory-mapped I/O =
address. */=0A     char __iomem *remapped_io_base;  /* Remapped virtual =
address of MMIO. */=0A     /* UART with IRQ line: interrupt-driven I/O. =
*/=0A@@ -185,10 +185,11 @@ static void ns16550_poll(void *data)=0A =
#endif=0A }=0A =0A-static int ns16550_tx_empty(struct serial_port =
*port)=0A+static unsigned int ns16550_tx_ready(struct serial_port =
*port)=0A {=0A     struct ns16550 *uart =3D port->uart;=0A-    return =
!!(ns_read_reg(uart, LSR) & LSR_THRE);=0A+=0A+    return ns_read_reg(uart, =
LSR) & LSR_THRE ? uart->fifo_size : 0;=0A }=0A =0A static void ns16550_putc=
(struct serial_port *port, char c)=0A@@ -288,7 +289,7 @@ static void =
__init ns16550_init_preirq(s=0A     /* Check this really is a 16550+. =
Otherwise we have no FIFOs. */=0A     if ( ((ns_read_reg(uart, IIR) & =
0xc0) =3D=3D 0xc0) &&=0A          ((ns_read_reg(uart, FCR) & FCR_TRG14) =
=3D=3D FCR_TRG14) )=0A-        port->tx_fifo_size =3D 16;=0A+        =
uart->fifo_size =3D 16;=0A }=0A =0A static void ns16550_setup_postirq(struc=
t ns16550 *uart)=0A@@ -321,7 +322,7 @@ static void __init ns16550_init_post=
irq(=0A     /* Calculate time to fill RX FIFO and/or empty TX FIFO for =
polling. */=0A     bits =3D uart->data_bits + uart->stop_bits + !!uart->par=
ity;=0A     uart->timeout_ms =3D max_t(=0A-        unsigned int, 1, (bits =
* port->tx_fifo_size * 1000) / uart->baud);=0A+        unsigned int, 1, =
(bits * uart->fifo_size * 1000) / uart->baud);=0A =0A     if ( uart->irq > =
0 )=0A     {=0A@@ -388,7 +389,7 @@ static struct uart_driver __read_mostly =
=0A     .endboot      =3D ns16550_endboot,=0A     .suspend      =3D =
ns16550_suspend,=0A     .resume       =3D ns16550_resume,=0A-    .tx_empty =
    =3D ns16550_tx_empty,=0A+    .tx_ready     =3D ns16550_tx_ready,=0A    =
 .putc         =3D ns16550_putc,=0A     .getc         =3D ns16550_getc,=0A =
    .irq          =3D ns16550_irq=0A@@ -642,6 +643,8 @@ void __init =
ns16550_init(int index, stru=0A     uart->stop_bits =3D defaults->stop_bits=
;=0A     uart->irq       =3D defaults->irq;=0A     uart->io_base   =3D =
defaults->io_base;=0A+    /* Default is no transmit FIFO. */=0A+    =
uart->fifo_size =3D 1;=0A =0A     ns16550_parse_port_config(uart, (index =
=3D=3D 0) ? opt_com1 : opt_com2);=0A }=0A--- a/xen/drivers/char/pl011.c=0A+=
++ b/xen/drivers/char/pl011.c=0A@@ -156,9 +156,6 @@ static void __init =
pl011_init_preirq(str=0A =0A     /* Enable the UART for RX and TX; no flow =
ctrl */=0A     uart->regs[CR] =3D RXE | TXE | UARTEN;=0A-=0A-    /* Tell =
the serial framework about our fine 156-character FIFO */=0A-    port->tx_f=
ifo_size =3D 16;=0A }=0A =0A static void __init pl011_init_postirq(struct =
serial_port *port)=0A@@ -192,10 +189,10 @@ static void pl011_resume(struct =
serial_p=0A     BUG(); // XXX=0A }=0A =0A-static int pl011_tx_empty(struct =
serial_port *port)=0A+static unsigned int pl011_tx_ready(struct serial_port=
 *port)=0A {=0A     struct pl011 *uart =3D port->uart;=0A-    return =
!!(uart->regs[FR] & TXFE);=0A+    return uart->regs[FR] & TXFE ? 16 : =
0;=0A }=0A =0A static void pl011_putc(struct serial_port *port, char =
c)=0A@@ -227,7 +224,7 @@ static struct uart_driver __read_mostly =0A     =
.endboot      =3D NULL,=0A     .suspend      =3D pl011_suspend,=0A     =
.resume       =3D pl011_resume,=0A-    .tx_empty     =3D pl011_tx_empty,=0A=
+    .tx_ready     =3D pl011_tx_ready,=0A     .putc         =3D pl011_putc,=
=0A     .getc         =3D pl011_getc,=0A     .irq          =3D pl011_irq=0A=
--- a/xen/drivers/char/serial.c=0A+++ b/xen/drivers/char/serial.c=0A@@ =
-59,7 +59,7 @@ void serial_rx_interrupt(struct serial_p=0A =0A void =
serial_tx_interrupt(struct serial_port *port, struct cpu_user_regs =
*regs)=0A {=0A-    int i;=0A+    unsigned int i, n;=0A     unsigned long =
flags;=0A =0A     local_irq_save(flags);=0A@@ -71,23 +71,20 @@ void =
serial_tx_interrupt(struct serial_p=0A      */=0A     while ( !spin_trylock=
(&port->tx_lock) )=0A     {=0A-        if ( !port->driver->tx_empty(port) =
)=0A+        if ( !port->driver->tx_ready(port) )=0A             goto =
out;=0A         cpu_relax();=0A     }=0A =0A-    if ( port->driver->tx_empt=
y(port) )=0A+    for ( i =3D 0, n =3D port->driver->tx_ready(port); i < n; =
i++ )=0A     {=0A-        for ( i =3D 0; i < port->tx_fifo_size; i++ )=0A- =
       {=0A-            if ( port->txbufc =3D=3D port->txbufp )=0A-        =
        break;=0A-            port->driver->putc(=0A-                port, =
port->txbuf[mask_serial_txbuf_idx(port->txbufc++)]);=0A-        }=0A-      =
  if ( i && port->driver->flush )=0A-            port->driver->flush(port);=
=0A+        if ( port->txbufc =3D=3D port->txbufp )=0A+            =
break;=0A+        port->driver->putc(=0A+            port, port->txbuf[mask=
_serial_txbuf_idx(port->txbufc++)]);=0A     }=0A+    if ( i && port->driver=
->flush )=0A+        port->driver->flush(port);=0A =0A     spin_unlock(&por=
t->tx_lock);=0A =0A@@ -114,10 +111,11 @@ static void __serial_putc(struct =
serial_=0A             if ( port->tx_log_everything )=0A             {=0A  =
               /* Buffer is full: we spin waiting for space to appear. =
*/=0A-                int i;=0A-                while ( !port->driver->tx_e=
mpty(port) )=0A+                unsigned int n;=0A+=0A+                =
while ( (n =3D port->driver->tx_ready(port)) =3D=3D 0 )=0A                 =
    cpu_relax();=0A-                for ( i =3D 0; i < port->tx_fifo_size; =
i++ )=0A+                while ( n-- )=0A                     port->driver-=
>putc(=0A                         port,=0A                         =
port->txbuf[mask_serial_txbuf_idx(port->txbufc++)]);=0A@@ -132,7 +130,7 @@ =
static void __serial_putc(struct serial_=0A         }=0A =0A         if ( =
((port->txbufp - port->txbufc) =3D=3D 0) &&=0A-                  port->driv=
er->tx_empty(port) )=0A+             port->driver->tx_ready(port) )=0A     =
    {=0A             /* Buffer and UART FIFO are both empty. */=0A         =
    port->driver->putc(port, c);=0A@@ -143,10 +141,10 @@ static void =
__serial_putc(struct serial_=0A             port->txbuf[mask_serial_txbuf_i=
dx(port->txbufp++)] =3D c;=0A         }=0A     }=0A-    else if ( =
port->driver->tx_empty )=0A+    else if ( port->driver->tx_ready )=0A     =
{=0A         /* Synchronous finite-capacity transmitter. */=0A-        =
while ( !port->driver->tx_empty(port) )=0A+        while ( !port->driver->t=
x_ready(port) )=0A             cpu_relax();=0A         port->driver->putc(p=
ort, c);=0A     }=0A@@ -386,7 +384,7 @@ void serial_start_sync(int =
handle)=0A     {=0A         while ( (port->txbufp - port->txbufc) !=3D 0 =
)=0A         {=0A-            while ( !port->driver->tx_empty(port) )=0A+  =
          while ( !port->driver->tx_ready(port) )=0A                 =
cpu_relax();=0A             port->driver->putc(=0A                 port, =
port->txbuf[mask_serial_txbuf_idx(port->txbufc++)]);=0A@@ -506,14 +504,11 =
@@ void __init serial_register_uart(int idx=0A     /* Store UART-specific =
info. */=0A     com[idx].driver =3D driver;=0A     com[idx].uart   =3D =
uart;=0A-=0A-    /* Default is no transmit FIFO. */=0A-    com[idx].tx_fifo=
_size =3D 1;=0A }=0A =0A void __init serial_async_transmit(struct =
serial_port *port)=0A {=0A-    BUG_ON(!port->driver->tx_empty);=0A+    =
BUG_ON(!port->driver->tx_ready);=0A     if ( port->txbuf !=3D NULL )=0A    =
     return;=0A     if ( serial_txbufsz < PAGE_SIZE )=0A--- a/xen/include/x=
en/serial.h=0A+++ b/xen/include/xen/serial.h=0A@@ -36,8 +36,6 @@ struct =
serial_port {=0A     struct uart_driver *driver;=0A     void               =
*uart;=0A     enum serial_port_state state;=0A-    /* Number of characters =
the port can hold for transmit. */=0A-    int                 tx_fifo_size;=
=0A     /* Transmit data buffer (interrupt-driven uart). */=0A     char    =
           *txbuf;=0A     unsigned int        txbufp, txbufc;=0A@@ -63,8 =
+61,8 @@ struct uart_driver {=0A     /* Driver suspend/resume. */=0A     =
void (*suspend)(struct serial_port *);=0A     void (*resume)(struct =
serial_port *);=0A-    /* Transmit FIFO ready to receive up to @tx_fifo_siz=
e characters? */=0A-    int  (*tx_empty)(struct serial_port *);=0A+    /* =
Return number of characters the port can hold for transmit. */=0A+    =
unsigned int (*tx_ready)(struct serial_port *);=0A     /* Put a character =
onto the serial line. */=0A     void (*putc)(struct serial_port *, =
char);=0A     /* Flush accumulated characters. */=0A
--=__PartCEFFDCA9.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

--=__PartCEFFDCA9.0__=--


From xen-devel-bounces@lists.xen.org Tue Sep 11 10:22:44 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 2012 10:22: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 1TBNc5-0003bu-7o; Tue, 11 Sep 2012 10:22:37 +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 1TBNc3-0003bf-P7
	for xen-devel@lists.xen.org; Tue, 11 Sep 2012 10:22:35 +0000
Received: from [85.158.139.83:50352] by server-5.bemta-5.messagelabs.com id
	BB/40-30514-AE01F405; Tue, 11 Sep 2012 10:22:34 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1347358952!29783027!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNzM2MjU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20262 invoked from network); 11 Sep 2012 10:22:34 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-3.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Sep 2012 10:22:34 -0000
X-IronPort-AV: E=Sophos;i="4.80,402,1344211200"; d="scan'208";a="207694572"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Sep 2012 10:22:32 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Tue, 11 Sep 2012 06:22: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 1TBNc0-0003s2-1i	for
	xen-devel@lists.xen.org; Tue, 11 Sep 2012 11:22:32 +0100
Message-ID: <504F10E8.9020007@citrix.com>
Date: Tue, 11 Sep 2012 11:22:32 +0100
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:14.0) Gecko/20120714 Thunderbird/14.0
MIME-Version: 1.0
To: xen-devel@lists.xen.org
References: <504F2C90020000780009A834@nat28.tlf.novell.com>
In-Reply-To: <504F2C90020000780009A834@nat28.tlf.novell.com>
X-Enigmail-Version: 1.4.4
Subject: Re: [Xen-devel] [PATCH 7/8] ns16550: command line parsing
	adjustments
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


On 11/09/12 11:20, Jan Beulich wrote:
> Allow intermediate parts of the command line options to be absent
> (expressed by two immediately succeeding commas).
>
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Can you also update com{1,2} in the docs to reflect this?

>
> --- a/xen/drivers/char/ns16550.c
> +++ b/xen/drivers/char/ns16550.c
> @@ -556,26 +556,23 @@ static void __init ns16550_parse_port_co
>      else if ( (baud = simple_strtoul(conf, &conf, 10)) != 0 )
>          uart->baud = baud;
>  
> -    if ( *conf == '/')
> +    if ( *conf == '/' )
>      {
>          conf++;
>          uart->clock_hz = simple_strtoul(conf, &conf, 0) << 4;
>      }
>  
> -    if ( *conf != ',' )
> -        goto config_parsed;
> -    conf++;
> -
> -    uart->data_bits = simple_strtoul(conf, &conf, 10);
> +    if ( *conf == ',' && *++conf != ',' )
> +    {
> +        uart->data_bits = simple_strtoul(conf, &conf, 10);
>  
> -    uart->parity = parse_parity_char(*conf);
> -    conf++;
> +        uart->parity = parse_parity_char(*conf);
>  
> -    uart->stop_bits = simple_strtoul(conf, &conf, 10);
> +        uart->stop_bits = simple_strtoul(conf + 1, &conf, 10);
> +    }
>  
> -    if ( *conf == ',' )
> +    if ( *conf == ',' && *++conf != ',' )
>      {
> -        conf++;
>          if ( strncmp(conf, "pci", 3) == 0 )
>          {
>              if ( pci_uart_config(uart, 1/* skip AMT */, uart - ns16550_com) )
> @@ -592,24 +589,21 @@ static void __init ns16550_parse_port_co
>          {
>              uart->io_base = simple_strtoul(conf, &conf, 0);
>          }
> +    }
>  
> -        if ( *conf == ',' )
> -        {
> -            conf++;
> -            uart->irq = simple_strtoul(conf, &conf, 10);
> -            if ( *conf == ',' )
> -            {
> -                conf++;
> -                uart->ps_bdf_enable = 1;
> -                parse_pci_bdf(&conf, &uart->ps_bdf[0]);
> -                if ( *conf == ',' )
> -                {
> -                    conf++;
> -                    uart->pb_bdf_enable = 1;
> -                    parse_pci_bdf(&conf, &uart->pb_bdf[0]);
> -                }
> -            }
> -        }
> +    if ( *conf == ',' && *++conf != ',' )
> +        uart->irq = simple_strtol(conf, &conf, 10);
> +
> +    if ( *conf == ',' && *++conf != ',' )
> +    {
> +        uart->ps_bdf_enable = 1;
> +        parse_pci_bdf(&conf, &uart->ps_bdf[0]);
> +    }
> +
> +    if ( *conf == ',' && *++conf != ',' )
> +    {
> +        uart->pb_bdf_enable = 1;
> +        parse_pci_bdf(&conf, &uart->pb_bdf[0]);
>      }
>  
>   config_parsed:
>
>
>

-- 
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 Sep 11 10:22:44 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 2012 10:22: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 1TBNc5-0003bu-7o; Tue, 11 Sep 2012 10:22:37 +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 1TBNc3-0003bf-P7
	for xen-devel@lists.xen.org; Tue, 11 Sep 2012 10:22:35 +0000
Received: from [85.158.139.83:50352] by server-5.bemta-5.messagelabs.com id
	BB/40-30514-AE01F405; Tue, 11 Sep 2012 10:22:34 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1347358952!29783027!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNzM2MjU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20262 invoked from network); 11 Sep 2012 10:22:34 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-3.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Sep 2012 10:22:34 -0000
X-IronPort-AV: E=Sophos;i="4.80,402,1344211200"; d="scan'208";a="207694572"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Sep 2012 10:22:32 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Tue, 11 Sep 2012 06:22: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 1TBNc0-0003s2-1i	for
	xen-devel@lists.xen.org; Tue, 11 Sep 2012 11:22:32 +0100
Message-ID: <504F10E8.9020007@citrix.com>
Date: Tue, 11 Sep 2012 11:22:32 +0100
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:14.0) Gecko/20120714 Thunderbird/14.0
MIME-Version: 1.0
To: xen-devel@lists.xen.org
References: <504F2C90020000780009A834@nat28.tlf.novell.com>
In-Reply-To: <504F2C90020000780009A834@nat28.tlf.novell.com>
X-Enigmail-Version: 1.4.4
Subject: Re: [Xen-devel] [PATCH 7/8] ns16550: command line parsing
	adjustments
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


On 11/09/12 11:20, Jan Beulich wrote:
> Allow intermediate parts of the command line options to be absent
> (expressed by two immediately succeeding commas).
>
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Can you also update com{1,2} in the docs to reflect this?

>
> --- a/xen/drivers/char/ns16550.c
> +++ b/xen/drivers/char/ns16550.c
> @@ -556,26 +556,23 @@ static void __init ns16550_parse_port_co
>      else if ( (baud = simple_strtoul(conf, &conf, 10)) != 0 )
>          uart->baud = baud;
>  
> -    if ( *conf == '/')
> +    if ( *conf == '/' )
>      {
>          conf++;
>          uart->clock_hz = simple_strtoul(conf, &conf, 0) << 4;
>      }
>  
> -    if ( *conf != ',' )
> -        goto config_parsed;
> -    conf++;
> -
> -    uart->data_bits = simple_strtoul(conf, &conf, 10);
> +    if ( *conf == ',' && *++conf != ',' )
> +    {
> +        uart->data_bits = simple_strtoul(conf, &conf, 10);
>  
> -    uart->parity = parse_parity_char(*conf);
> -    conf++;
> +        uart->parity = parse_parity_char(*conf);
>  
> -    uart->stop_bits = simple_strtoul(conf, &conf, 10);
> +        uart->stop_bits = simple_strtoul(conf + 1, &conf, 10);
> +    }
>  
> -    if ( *conf == ',' )
> +    if ( *conf == ',' && *++conf != ',' )
>      {
> -        conf++;
>          if ( strncmp(conf, "pci", 3) == 0 )
>          {
>              if ( pci_uart_config(uart, 1/* skip AMT */, uart - ns16550_com) )
> @@ -592,24 +589,21 @@ static void __init ns16550_parse_port_co
>          {
>              uart->io_base = simple_strtoul(conf, &conf, 0);
>          }
> +    }
>  
> -        if ( *conf == ',' )
> -        {
> -            conf++;
> -            uart->irq = simple_strtoul(conf, &conf, 10);
> -            if ( *conf == ',' )
> -            {
> -                conf++;
> -                uart->ps_bdf_enable = 1;
> -                parse_pci_bdf(&conf, &uart->ps_bdf[0]);
> -                if ( *conf == ',' )
> -                {
> -                    conf++;
> -                    uart->pb_bdf_enable = 1;
> -                    parse_pci_bdf(&conf, &uart->pb_bdf[0]);
> -                }
> -            }
> -        }
> +    if ( *conf == ',' && *++conf != ',' )
> +        uart->irq = simple_strtol(conf, &conf, 10);
> +
> +    if ( *conf == ',' && *++conf != ',' )
> +    {
> +        uart->ps_bdf_enable = 1;
> +        parse_pci_bdf(&conf, &uart->ps_bdf[0]);
> +    }
> +
> +    if ( *conf == ',' && *++conf != ',' )
> +    {
> +        uart->pb_bdf_enable = 1;
> +        parse_pci_bdf(&conf, &uart->pb_bdf[0]);
>      }
>  
>   config_parsed:
>
>
>

-- 
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 Sep 11 10:23:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 2012 10:23: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 1TBNdD-0003mZ-Nm; Tue, 11 Sep 2012 10:23:47 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1TBNdC-0003mE-7y
	for xen-devel@lists.xen.org; Tue, 11 Sep 2012 10:23:46 +0000
Received: from [85.158.138.51:46853] by server-7.bemta-3.messagelabs.com id
	C0/D1-32000-1311F405; Tue, 11 Sep 2012 10:23:45 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1347359024!29860599!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQwNzc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18167 invoked from network); 11 Sep 2012 10:23:44 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-11.tower-174.messagelabs.com with SMTP;
	11 Sep 2012 10:23:44 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 11 Sep 2012 11:23:44 +0100
Message-Id: <504F2D4E020000780009A858@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 11 Sep 2012 11:23:42 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
References: <504F2A71020000780009A7ED@nat28.tlf.novell.com>
In-Reply-To: <504F2A71020000780009A7ED@nat28.tlf.novell.com>
Mime-Version: 1.0
Content-Disposition: inline
Subject: [Xen-devel] patch series not just RFC (was: Re: [PATCH RFC 0/8]
 console improvements)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 11.09.12 at 12:11, "Jan Beulich" <JBeulich@suse.com> wrote:
> This series adds support for an EHCI debug port based console, and
> does some other improvements and cleanup noticed to be desirable
> during the implementation of the former as follow-up.
> 
> 1: x86: allow early use of fixmaps
> 2: console: prepare for non-COMn port support
> 3: console: add EHCI debug port based serial console
> 4: serial: avoid fully initializing unused consoles
> 5: ns16550: MMIO adjustments
> 6: ns16550: PCI initialization adjustments
> 7: ns16550: command line parsing adjustments
> 8: drop tx_fifo_size

I only noticed that I accidentally left the RFC tag in the subject
line in the middle of (re)sending this series, so please ignore
that tag and take it as a series ready to go in.

Sorry and thanks, Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 11 10:23:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 2012 10:23: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 1TBNdD-0003mZ-Nm; Tue, 11 Sep 2012 10:23:47 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1TBNdC-0003mE-7y
	for xen-devel@lists.xen.org; Tue, 11 Sep 2012 10:23:46 +0000
Received: from [85.158.138.51:46853] by server-7.bemta-3.messagelabs.com id
	C0/D1-32000-1311F405; Tue, 11 Sep 2012 10:23:45 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1347359024!29860599!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQwNzc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18167 invoked from network); 11 Sep 2012 10:23:44 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-11.tower-174.messagelabs.com with SMTP;
	11 Sep 2012 10:23:44 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 11 Sep 2012 11:23:44 +0100
Message-Id: <504F2D4E020000780009A858@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 11 Sep 2012 11:23:42 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
References: <504F2A71020000780009A7ED@nat28.tlf.novell.com>
In-Reply-To: <504F2A71020000780009A7ED@nat28.tlf.novell.com>
Mime-Version: 1.0
Content-Disposition: inline
Subject: [Xen-devel] patch series not just RFC (was: Re: [PATCH RFC 0/8]
 console improvements)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 11.09.12 at 12:11, "Jan Beulich" <JBeulich@suse.com> wrote:
> This series adds support for an EHCI debug port based console, and
> does some other improvements and cleanup noticed to be desirable
> during the implementation of the former as follow-up.
> 
> 1: x86: allow early use of fixmaps
> 2: console: prepare for non-COMn port support
> 3: console: add EHCI debug port based serial console
> 4: serial: avoid fully initializing unused consoles
> 5: ns16550: MMIO adjustments
> 6: ns16550: PCI initialization adjustments
> 7: ns16550: command line parsing adjustments
> 8: drop tx_fifo_size

I only noticed that I accidentally left the RFC tag in the subject
line in the middle of (re)sending this series, so please ignore
that tag and take it as a series ready to go in.

Sorry and thanks, Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 11 10:26:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 2012 10: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 1TBNfS-00042Z-EM; Tue, 11 Sep 2012 10:26: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 1TBNfR-00042P-2A
	for xen-devel@lists.xen.org; Tue, 11 Sep 2012 10:26:05 +0000
Received: from [85.158.138.51:10592] by server-6.bemta-3.messagelabs.com id
	33/D7-29694-CB11F405; Tue, 11 Sep 2012 10:26:04 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1347359163!23530831!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQwNzc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22020 invoked from network); 11 Sep 2012 10:26:03 -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;
	11 Sep 2012 10:26:03 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 11 Sep 2012 11:26:03 +0100
Message-Id: <504F2DD8020000780009A85B@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 11 Sep 2012 11:26:00 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "DuanZhenzhong" <zhenzhong.duan@oracle.com>
References: <504764270200007800098DE1@nat28.tlf.novell.com>
	<504A01790200007800099C52@nat28.tlf.novell.com>
	<504F1412020000780009A750@nat28.tlf.novell.com>
	<504F01D6.3050903@oracle.com>
	<504F23B2020000780009A79B@nat28.tlf.novell.com>
	<504F0C0C.6020804@oracle.com>
In-Reply-To: <504F0C0C.6020804@oracle.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: dan.magenheimer@oracle.com, Ian Campbell <ian.campbell@citrix.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Ping: [PATCH 09/11,
 v2] tmem: reduce severity of log messages
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 11.09.12 at 12:01, DuanZhenzhong <zhenzhong.duan@oracle.com> wrote:
> Jan Beulich wrote:
>>>>> On 11.09.12 at 11:18, DuanZhenzhong <zhenzhong.duan@oracle.com> wrote:
>>>>>         
>>> Dan is offline recently.
>>> What about 'printk("tmem_relinquish_page: failing order=%d\n", order)', 
>>> more like a  guest level msg.
>>>     
>>
>> That's debatable, but the message is enabled for debug builds
>> only anyway. Could be make XENLOG_DEBUG, but that would
>> require yet another helper in tmem_xen.h. I'd want to leave
>> this alone for the moment.
> Ok.
> zduan

Is that an ack on the patch then?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 11 10:26:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 2012 10: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 1TBNfS-00042Z-EM; Tue, 11 Sep 2012 10:26: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 1TBNfR-00042P-2A
	for xen-devel@lists.xen.org; Tue, 11 Sep 2012 10:26:05 +0000
Received: from [85.158.138.51:10592] by server-6.bemta-3.messagelabs.com id
	33/D7-29694-CB11F405; Tue, 11 Sep 2012 10:26:04 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1347359163!23530831!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQwNzc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22020 invoked from network); 11 Sep 2012 10:26:03 -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;
	11 Sep 2012 10:26:03 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 11 Sep 2012 11:26:03 +0100
Message-Id: <504F2DD8020000780009A85B@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 11 Sep 2012 11:26:00 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "DuanZhenzhong" <zhenzhong.duan@oracle.com>
References: <504764270200007800098DE1@nat28.tlf.novell.com>
	<504A01790200007800099C52@nat28.tlf.novell.com>
	<504F1412020000780009A750@nat28.tlf.novell.com>
	<504F01D6.3050903@oracle.com>
	<504F23B2020000780009A79B@nat28.tlf.novell.com>
	<504F0C0C.6020804@oracle.com>
In-Reply-To: <504F0C0C.6020804@oracle.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: dan.magenheimer@oracle.com, Ian Campbell <ian.campbell@citrix.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Ping: [PATCH 09/11,
 v2] tmem: reduce severity of log messages
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 11.09.12 at 12:01, DuanZhenzhong <zhenzhong.duan@oracle.com> wrote:
> Jan Beulich wrote:
>>>>> On 11.09.12 at 11:18, DuanZhenzhong <zhenzhong.duan@oracle.com> wrote:
>>>>>         
>>> Dan is offline recently.
>>> What about 'printk("tmem_relinquish_page: failing order=%d\n", order)', 
>>> more like a  guest level msg.
>>>     
>>
>> That's debatable, but the message is enabled for debug builds
>> only anyway. Could be make XENLOG_DEBUG, but that would
>> require yet another helper in tmem_xen.h. I'd want to leave
>> this alone for the moment.
> Ok.
> zduan

Is that an ack on the patch then?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 11 10:27:38 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 2012 10:27:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TBNgl-0004Az-U2; Tue, 11 Sep 2012 10:27: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 1TBNgk-0004Ar-0r
	for xen-devel@lists.xen.org; Tue, 11 Sep 2012 10:27:26 +0000
Received: from [85.158.143.99:30056] by server-1.bemta-4.messagelabs.com id
	20/19-12504-D021F405; Tue, 11 Sep 2012 10:27:25 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1347359244!24456616!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDg1NjI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21074 invoked from network); 11 Sep 2012 10:27:24 -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;
	11 Sep 2012 10:27:24 -0000
X-IronPort-AV: E=Sophos;i="4.80,404,1344211200"; d="scan'208";a="14465979"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Sep 2012 10:27:24 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Tue, 11 Sep 2012 11:27: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
	1TBNgi-0005lY-IV; Tue, 11 Sep 2012 10:27:24 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1TBNgi-00068A-E6;
	Tue, 11 Sep 2012 11:27:24 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20559.4620.289290.810165@mariner.uk.xensource.com>
Date: Tue, 11 Sep 2012 11:27:24 +0100
To: Keir Fraser <keir.xen@gmail.com>
In-Reply-To: <CC73E0EC.3E42A%keir.xen@gmail.com>
References: <20558.7857.884864.696876@mariner.uk.xensource.com>
	<CC73E0EC.3E42A%keir.xen@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] [ANNOUNCE] Xen x86 32-bit hypervisor end of life
	after 4.2
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Keir Fraser writes ("Re: [ANNOUNCE] Xen x86 32-bit hypervisor end of life after 4.2"):
> On 10/09/2012 18:09, "Ian Jackson" <Ian.Jackson@eu.citrix.com> wrote:
> > I've been looking into this and have a draft of a suitable change.
> > But: can you confirm that typing "make" will still work on a 32-bit
> > system and generate a working tools build ?  I don't care what
> > hypervisor (if any) it builds, but it has to succeed because that's
> > how I build the tools for use in 32-bit dom0s.
> 
> You want 'make' at the root Makefile to build successfully? If so we can
> stub out 32-bit hypervisor only either in that Makefile, or xen/Makefile.

That would be best for me.  I think it would be best for users too.
Maybe you would like to leave a xen-blah.README in dist/install/boot.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 11 10:27:38 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 2012 10:27:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TBNgl-0004Az-U2; Tue, 11 Sep 2012 10:27: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 1TBNgk-0004Ar-0r
	for xen-devel@lists.xen.org; Tue, 11 Sep 2012 10:27:26 +0000
Received: from [85.158.143.99:30056] by server-1.bemta-4.messagelabs.com id
	20/19-12504-D021F405; Tue, 11 Sep 2012 10:27:25 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1347359244!24456616!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDg1NjI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21074 invoked from network); 11 Sep 2012 10:27:24 -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;
	11 Sep 2012 10:27:24 -0000
X-IronPort-AV: E=Sophos;i="4.80,404,1344211200"; d="scan'208";a="14465979"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Sep 2012 10:27:24 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Tue, 11 Sep 2012 11:27: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
	1TBNgi-0005lY-IV; Tue, 11 Sep 2012 10:27:24 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1TBNgi-00068A-E6;
	Tue, 11 Sep 2012 11:27:24 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20559.4620.289290.810165@mariner.uk.xensource.com>
Date: Tue, 11 Sep 2012 11:27:24 +0100
To: Keir Fraser <keir.xen@gmail.com>
In-Reply-To: <CC73E0EC.3E42A%keir.xen@gmail.com>
References: <20558.7857.884864.696876@mariner.uk.xensource.com>
	<CC73E0EC.3E42A%keir.xen@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] [ANNOUNCE] Xen x86 32-bit hypervisor end of life
	after 4.2
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Keir Fraser writes ("Re: [ANNOUNCE] Xen x86 32-bit hypervisor end of life after 4.2"):
> On 10/09/2012 18:09, "Ian Jackson" <Ian.Jackson@eu.citrix.com> wrote:
> > I've been looking into this and have a draft of a suitable change.
> > But: can you confirm that typing "make" will still work on a 32-bit
> > system and generate a working tools build ?  I don't care what
> > hypervisor (if any) it builds, but it has to succeed because that's
> > how I build the tools for use in 32-bit dom0s.
> 
> You want 'make' at the root Makefile to build successfully? If so we can
> stub out 32-bit hypervisor only either in that Makefile, or xen/Makefile.

That would be best for me.  I think it would be best for users too.
Maybe you would like to leave a xen-blah.README in dist/install/boot.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 11 10:32:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 2012 10:32:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TBNl0-0004Pc-1r; Tue, 11 Sep 2012 10:31:50 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1TBNky-0004PV-Lm
	for xen-devel@lists.xensource.com; Tue, 11 Sep 2012 10:31:48 +0000
Received: from [85.158.143.35:20213] by server-1.bemta-4.messagelabs.com id
	F5/82-12504-3131F405; Tue, 11 Sep 2012 10:31:47 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1347359148!6728058!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDg1NjI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32138 invoked from network); 11 Sep 2012 10:25:56 -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;
	11 Sep 2012 10:25:56 -0000
X-IronPort-AV: E=Sophos;i="4.80,404,1344211200"; d="scan'208";a="14465903"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Sep 2012 10:24: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.279.1; Tue, 11 Sep 2012 11:24: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
	1TBNe4-0005k9-1P; Tue, 11 Sep 2012 10:24:40 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1TBNe3-00067w-SV;
	Tue, 11 Sep 2012 11:24:39 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20559.4455.788888.924416@mariner.uk.xensource.com>
Date: Tue, 11 Sep 2012 11:24:39 +0100
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
In-Reply-To: <osstest-13669-mainreport@xen.org>
References: <osstest-13669-mainreport@xen.org>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [xen-4.2-testing test] 13669: 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

xen.org writes ("[xen-4.2-testing test] 13669: tolerable FAIL - PUSHED"):
> flight 13669 xen-4.2-testing real [real]
> http://www.chiark.greenend.org.uk/~xensrcts/logs/13669/
> 
> Failures :-/ but no regressions.
> 
> Tests which did not succeed, but are not blocking:
>  [stuff]

These are all things which are broken in -unstable too.  So I can
declare 4.2 open for business.

FYI below is the output of "./sg-report-flight --that-xen=7d770de90b7f 13669"

Ian.

13669: tolerable FAIL

flight 13669 xen-4.2-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13669/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore            fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-i386-i386-xl-qemuu-winxpsp3  9 guest-localmigrate         fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     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-win        13 guest-stop                   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-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass

baseline version:
 xen                  7d770de90b7f

jobs:
 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                                 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                                     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


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 11 10:32:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 2012 10:32:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TBNl0-0004Pc-1r; Tue, 11 Sep 2012 10:31:50 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1TBNky-0004PV-Lm
	for xen-devel@lists.xensource.com; Tue, 11 Sep 2012 10:31:48 +0000
Received: from [85.158.143.35:20213] by server-1.bemta-4.messagelabs.com id
	F5/82-12504-3131F405; Tue, 11 Sep 2012 10:31:47 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1347359148!6728058!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDg1NjI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32138 invoked from network); 11 Sep 2012 10:25:56 -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;
	11 Sep 2012 10:25:56 -0000
X-IronPort-AV: E=Sophos;i="4.80,404,1344211200"; d="scan'208";a="14465903"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Sep 2012 10:24: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.279.1; Tue, 11 Sep 2012 11:24: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
	1TBNe4-0005k9-1P; Tue, 11 Sep 2012 10:24:40 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1TBNe3-00067w-SV;
	Tue, 11 Sep 2012 11:24:39 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20559.4455.788888.924416@mariner.uk.xensource.com>
Date: Tue, 11 Sep 2012 11:24:39 +0100
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
In-Reply-To: <osstest-13669-mainreport@xen.org>
References: <osstest-13669-mainreport@xen.org>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [xen-4.2-testing test] 13669: 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

xen.org writes ("[xen-4.2-testing test] 13669: tolerable FAIL - PUSHED"):
> flight 13669 xen-4.2-testing real [real]
> http://www.chiark.greenend.org.uk/~xensrcts/logs/13669/
> 
> Failures :-/ but no regressions.
> 
> Tests which did not succeed, but are not blocking:
>  [stuff]

These are all things which are broken in -unstable too.  So I can
declare 4.2 open for business.

FYI below is the output of "./sg-report-flight --that-xen=7d770de90b7f 13669"

Ian.

13669: tolerable FAIL

flight 13669 xen-4.2-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13669/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore            fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-i386-i386-xl-qemuu-winxpsp3  9 guest-localmigrate         fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     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-win        13 guest-stop                   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-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass

baseline version:
 xen                  7d770de90b7f

jobs:
 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                                 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                                     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


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 11 10:42:39 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 2012 10:42:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TBNvG-0004gd-Bl; Tue, 11 Sep 2012 10:42:26 +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 1TBNvF-0004gY-CL
	for xen-devel@lists.xen.org; Tue, 11 Sep 2012 10:42:25 +0000
Received: from [85.158.138.51:53852] by server-11.bemta-3.messagelabs.com id
	EF/B1-30250-0951F405; Tue, 11 Sep 2012 10:42:24 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1347360143!29956102!1
X-Originating-IP: [74.125.83.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2309 invoked from network); 11 Sep 2012 10:42:24 -0000
Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com)
	(74.125.83.45)
	by server-5.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Sep 2012 10:42:24 -0000
Received: by eeke53 with SMTP id e53so287840eek.32
	for <xen-devel@lists.xen.org>; Tue, 11 Sep 2012 03:42: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:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=3ZxWl4vk08NfI8P7VRR7gJ7H6q01axoO4nNsPvQ89Xg=;
	b=zS2lGiofBFzru0+lBtzB0sZp9i9v7DClZx0oNmObT9QBHqq1lm/le2iHKy93e4UGiG
	kRUVpCITrp6xYJA2mvRUTsg8wiRCb1JhDop0xqS9vcoKQkjhJxE9SNUjqscvWcibeavR
	GCM222utvu5D0fbLWs5h47Ni1+epbBQc2HUwev2z8AHITIz2ej8HOYVQsiXXLO0DiWrc
	AB9Uy+gKfv2w3fDDisHs/oQReCKA3+2qwkryn62+TYKmgn5UgDoJ+5jILdWT4DWpMB8y
	T8uF6BS/pknpJgupkdiTu05xHrOI6MUMUs3PRZJ2O3rOjkXIF0G43qFI2j3fsNHGZujo
	Z/zw==
Received: by 10.14.175.7 with SMTP id y7mr24590098eel.29.1347360143806;
	Tue, 11 Sep 2012 03:42:23 -0700 (PDT)
Received: from [192.168.1.3] (host86-184-74-117.range86-184.btcentralplus.com.
	[86.184.74.117])
	by mx.google.com with ESMTPS id r45sm45942523eem.6.2012.09.11.03.42.21
	(version=SSLv3 cipher=OTHER); Tue, 11 Sep 2012 03:42:23 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.33.0.120411
Date: Tue, 11 Sep 2012 11:42:13 +0100
From: Keir Fraser <keir@xen.org>
To: Jan Beulich <JBeulich@suse.com>,
	xen-devel <xen-devel@lists.xen.org>
Message-ID: <CC74D415.4B6AA%keir@xen.org>
Thread-Topic: [Xen-devel] [PATCH RFC 5/8] ns16550: MMIO adjustments
Thread-Index: Ac2QChpdHZzdnEmhQEm8zPTooW3nKw==
In-Reply-To: <504F2C00020000780009A808@nat28.tlf.novell.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] [PATCH RFC 5/8] ns16550: MMIO adjustments
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/09/2012 11:18, "Jan Beulich" <JBeulich@suse.com> wrote:

> On x86 ioremap() is not suitable here, set_fixmap() must be used
> instead.

Is that just because we don't have ioremap()?

 -- Keir

> Also replace some literal numbers by their proper symbolic constants,
> making the code easier to understand.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 11 10:42:39 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 2012 10:42:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TBNvG-0004gd-Bl; Tue, 11 Sep 2012 10:42:26 +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 1TBNvF-0004gY-CL
	for xen-devel@lists.xen.org; Tue, 11 Sep 2012 10:42:25 +0000
Received: from [85.158.138.51:53852] by server-11.bemta-3.messagelabs.com id
	EF/B1-30250-0951F405; Tue, 11 Sep 2012 10:42:24 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1347360143!29956102!1
X-Originating-IP: [74.125.83.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2309 invoked from network); 11 Sep 2012 10:42:24 -0000
Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com)
	(74.125.83.45)
	by server-5.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Sep 2012 10:42:24 -0000
Received: by eeke53 with SMTP id e53so287840eek.32
	for <xen-devel@lists.xen.org>; Tue, 11 Sep 2012 03:42: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:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=3ZxWl4vk08NfI8P7VRR7gJ7H6q01axoO4nNsPvQ89Xg=;
	b=zS2lGiofBFzru0+lBtzB0sZp9i9v7DClZx0oNmObT9QBHqq1lm/le2iHKy93e4UGiG
	kRUVpCITrp6xYJA2mvRUTsg8wiRCb1JhDop0xqS9vcoKQkjhJxE9SNUjqscvWcibeavR
	GCM222utvu5D0fbLWs5h47Ni1+epbBQc2HUwev2z8AHITIz2ej8HOYVQsiXXLO0DiWrc
	AB9Uy+gKfv2w3fDDisHs/oQReCKA3+2qwkryn62+TYKmgn5UgDoJ+5jILdWT4DWpMB8y
	T8uF6BS/pknpJgupkdiTu05xHrOI6MUMUs3PRZJ2O3rOjkXIF0G43qFI2j3fsNHGZujo
	Z/zw==
Received: by 10.14.175.7 with SMTP id y7mr24590098eel.29.1347360143806;
	Tue, 11 Sep 2012 03:42:23 -0700 (PDT)
Received: from [192.168.1.3] (host86-184-74-117.range86-184.btcentralplus.com.
	[86.184.74.117])
	by mx.google.com with ESMTPS id r45sm45942523eem.6.2012.09.11.03.42.21
	(version=SSLv3 cipher=OTHER); Tue, 11 Sep 2012 03:42:23 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.33.0.120411
Date: Tue, 11 Sep 2012 11:42:13 +0100
From: Keir Fraser <keir@xen.org>
To: Jan Beulich <JBeulich@suse.com>,
	xen-devel <xen-devel@lists.xen.org>
Message-ID: <CC74D415.4B6AA%keir@xen.org>
Thread-Topic: [Xen-devel] [PATCH RFC 5/8] ns16550: MMIO adjustments
Thread-Index: Ac2QChpdHZzdnEmhQEm8zPTooW3nKw==
In-Reply-To: <504F2C00020000780009A808@nat28.tlf.novell.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] [PATCH RFC 5/8] ns16550: MMIO adjustments
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/09/2012 11:18, "Jan Beulich" <JBeulich@suse.com> wrote:

> On x86 ioremap() is not suitable here, set_fixmap() must be used
> instead.

Is that just because we don't have ioremap()?

 -- Keir

> Also replace some literal numbers by their proper symbolic constants,
> making the code easier to understand.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 11 10:44:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 2012 10:44:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TBNxE-0004mQ-UI; Tue, 11 Sep 2012 10:44:28 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1TBNxD-0004mK-I6
	for xen-devel@lists.xen.org; Tue, 11 Sep 2012 10:44:27 +0000
Received: from [85.158.143.35:44633] by server-2.bemta-4.messagelabs.com id
	DC/BC-21239-A061F405; Tue, 11 Sep 2012 10:44:26 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1347360265!15219939!1
X-Originating-IP: [74.125.83.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2659 invoked from network); 11 Sep 2012 10:44:25 -0000
Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com)
	(74.125.83.45)
	by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Sep 2012 10:44:25 -0000
Received: by eeke53 with SMTP id e53so289551eek.32
	for <xen-devel@lists.xen.org>; Tue, 11 Sep 2012 03:44:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=O4KyEVTB0bjCvkEz9rYYhu8HKJUgcVmW2LcZwmQ+UNQ=;
	b=wllzsIOYmLq/y/64o9nWba+s/HFoL6sGORZcGQ2ztkN2fckcW45zR7AJNWFETlyZSY
	XIfk+7R8borNidAca5y6MtR1/kUD8zk6m52kYJAJ8WTt3P9Vlc+mcfErM44olzYnRcpD
	4vddbjw9UWmV2KRiknAka/wmwwYz3xWCnnp75IXiD0e6dtcGWNfwaz0LzFjNqoarqyPG
	NgB1LSg/Tqp4+oWQi6zevmreMQanSaSk9zXs4QJnvTXPxME4QtWFCvzPHa9MOgNVVQyz
	KX2rQMFR9Rt2GSUmrqEe59kDo6A5X47GTcnqBg6I6+VT7DBEOXyYWzI1hMbvI98bMLG7
	Ly6A==
Received: by 10.14.203.73 with SMTP id e49mr24841796eeo.27.1347360265544;
	Tue, 11 Sep 2012 03:44:25 -0700 (PDT)
Received: from [192.168.1.3] (host86-184-74-117.range86-184.btcentralplus.com.
	[86.184.74.117])
	by mx.google.com with ESMTPS id u8sm45937256eel.11.2012.09.11.03.44.24
	(version=SSLv3 cipher=OTHER); Tue, 11 Sep 2012 03:44:24 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.33.0.120411
Date: Tue, 11 Sep 2012 11:44:19 +0100
From: Keir Fraser <keir@xen.org>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Message-ID: <CC74D493.4B6AB%keir@xen.org>
Thread-Topic: [ANNOUNCE] Xen x86 32-bit hypervisor end of life after 4.2
Thread-Index: Ac2QCmV3Nx+af2o2S0SKo+SYGRShDA==
In-Reply-To: <20559.4620.289290.810165@mariner.uk.xensource.com>
Mime-version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [ANNOUNCE] Xen x86 32-bit hypervisor end of life
	after 4.2
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/09/2012 11:27, "Ian Jackson" <Ian.Jackson@eu.citrix.com> wrote:

> Keir Fraser writes ("Re: [ANNOUNCE] Xen x86 32-bit hypervisor end of life
> after 4.2"):
>> On 10/09/2012 18:09, "Ian Jackson" <Ian.Jackson@eu.citrix.com> wrote:
>>> I've been looking into this and have a draft of a suitable change.
>>> But: can you confirm that typing "make" will still work on a 32-bit
>>> system and generate a working tools build ?  I don't care what
>>> hypervisor (if any) it builds, but it has to succeed because that's
>>> how I build the tools for use in 32-bit dom0s.
>> 
>> You want 'make' at the root Makefile to build successfully? If so we can
>> stub out 32-bit hypervisor only either in that Makefile, or xen/Makefile.
> 
> That would be best for me.  I think it would be best for users too.
> Maybe you would like to leave a xen-blah.README in dist/install/boot.

Okay, I'll stub out in xen/Makefile and install something into
dist/install/boot.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 11 10:44:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 2012 10:44:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TBNxE-0004mQ-UI; Tue, 11 Sep 2012 10:44:28 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1TBNxD-0004mK-I6
	for xen-devel@lists.xen.org; Tue, 11 Sep 2012 10:44:27 +0000
Received: from [85.158.143.35:44633] by server-2.bemta-4.messagelabs.com id
	DC/BC-21239-A061F405; Tue, 11 Sep 2012 10:44:26 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1347360265!15219939!1
X-Originating-IP: [74.125.83.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2659 invoked from network); 11 Sep 2012 10:44:25 -0000
Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com)
	(74.125.83.45)
	by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Sep 2012 10:44:25 -0000
Received: by eeke53 with SMTP id e53so289551eek.32
	for <xen-devel@lists.xen.org>; Tue, 11 Sep 2012 03:44:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=O4KyEVTB0bjCvkEz9rYYhu8HKJUgcVmW2LcZwmQ+UNQ=;
	b=wllzsIOYmLq/y/64o9nWba+s/HFoL6sGORZcGQ2ztkN2fckcW45zR7AJNWFETlyZSY
	XIfk+7R8borNidAca5y6MtR1/kUD8zk6m52kYJAJ8WTt3P9Vlc+mcfErM44olzYnRcpD
	4vddbjw9UWmV2KRiknAka/wmwwYz3xWCnnp75IXiD0e6dtcGWNfwaz0LzFjNqoarqyPG
	NgB1LSg/Tqp4+oWQi6zevmreMQanSaSk9zXs4QJnvTXPxME4QtWFCvzPHa9MOgNVVQyz
	KX2rQMFR9Rt2GSUmrqEe59kDo6A5X47GTcnqBg6I6+VT7DBEOXyYWzI1hMbvI98bMLG7
	Ly6A==
Received: by 10.14.203.73 with SMTP id e49mr24841796eeo.27.1347360265544;
	Tue, 11 Sep 2012 03:44:25 -0700 (PDT)
Received: from [192.168.1.3] (host86-184-74-117.range86-184.btcentralplus.com.
	[86.184.74.117])
	by mx.google.com with ESMTPS id u8sm45937256eel.11.2012.09.11.03.44.24
	(version=SSLv3 cipher=OTHER); Tue, 11 Sep 2012 03:44:24 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.33.0.120411
Date: Tue, 11 Sep 2012 11:44:19 +0100
From: Keir Fraser <keir@xen.org>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Message-ID: <CC74D493.4B6AB%keir@xen.org>
Thread-Topic: [ANNOUNCE] Xen x86 32-bit hypervisor end of life after 4.2
Thread-Index: Ac2QCmV3Nx+af2o2S0SKo+SYGRShDA==
In-Reply-To: <20559.4620.289290.810165@mariner.uk.xensource.com>
Mime-version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [ANNOUNCE] Xen x86 32-bit hypervisor end of life
	after 4.2
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/09/2012 11:27, "Ian Jackson" <Ian.Jackson@eu.citrix.com> wrote:

> Keir Fraser writes ("Re: [ANNOUNCE] Xen x86 32-bit hypervisor end of life
> after 4.2"):
>> On 10/09/2012 18:09, "Ian Jackson" <Ian.Jackson@eu.citrix.com> wrote:
>>> I've been looking into this and have a draft of a suitable change.
>>> But: can you confirm that typing "make" will still work on a 32-bit
>>> system and generate a working tools build ?  I don't care what
>>> hypervisor (if any) it builds, but it has to succeed because that's
>>> how I build the tools for use in 32-bit dom0s.
>> 
>> You want 'make' at the root Makefile to build successfully? If so we can
>> stub out 32-bit hypervisor only either in that Makefile, or xen/Makefile.
> 
> That would be best for me.  I think it would be best for users too.
> Maybe you would like to leave a xen-blah.README in dist/install/boot.

Okay, I'll stub out in xen/Makefile and install something into
dist/install/boot.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 11 10:48:24 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 2012 10:48:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TBO0o-0004xh-IK; Tue, 11 Sep 2012 10:48:10 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1TBO0n-0004xa-B2
	for xen-devel@lists.xen.org; Tue, 11 Sep 2012 10:48:09 +0000
Received: from [85.158.139.83:27706] by server-7.bemta-5.messagelabs.com id
	13/24-19703-8E61F405; Tue, 11 Sep 2012 10:48:08 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1347360487!25857372!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQwNzc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9661 invoked from network); 11 Sep 2012 10:48:07 -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;
	11 Sep 2012 10:48:07 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 11 Sep 2012 11:48:07 +0100
Message-Id: <504F3304020000780009A896@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 11 Sep 2012 11:48:04 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Andrew Cooper" <andrew.cooper3@citrix.com>
References: <504F2C90020000780009A834@nat28.tlf.novell.com>
	<504F10E8.9020007@citrix.com>
In-Reply-To: <504F10E8.9020007@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 7/8] ns16550: command line parsing
 adjustments
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 11.09.12 at 12:22, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
> On 11/09/12 11:20, Jan Beulich wrote:
>> Allow intermediate parts of the command line options to be absent
>> (expressed by two immediately succeeding commas).
>>
>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> 
> Can you also update com{1,2} in the docs to reflect this?

Sure - here's the incremental diff.

Jan

--- a/docs/misc/xen-command-line.markdown
+++ b/docs/misc/xen-command-line.markdown
@@ -199,7 +199,7 @@ If set, override Xen's calculation of th
 If set, override Xen's default choice for the platform timer.
 
 ### com1,com2
-> `= <baud>[/<clock_hz>][,DPS[,<io-base>[,<irq>[,<port-bdf>[,<bridge-bdf>]]]] | pci | amt ] `
+> `= <baud>[/<clock_hz>][,[DPS][,[<io-base>|pci|amt][,[<irq>][,[<port-bdf>][,[<bridge-bdf>]]]]]]`
 
 Both option `com1` and `com2` follow the same format.
 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 11 10:48:24 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 2012 10:48:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TBO0o-0004xh-IK; Tue, 11 Sep 2012 10:48:10 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1TBO0n-0004xa-B2
	for xen-devel@lists.xen.org; Tue, 11 Sep 2012 10:48:09 +0000
Received: from [85.158.139.83:27706] by server-7.bemta-5.messagelabs.com id
	13/24-19703-8E61F405; Tue, 11 Sep 2012 10:48:08 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1347360487!25857372!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQwNzc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9661 invoked from network); 11 Sep 2012 10:48:07 -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;
	11 Sep 2012 10:48:07 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 11 Sep 2012 11:48:07 +0100
Message-Id: <504F3304020000780009A896@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 11 Sep 2012 11:48:04 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Andrew Cooper" <andrew.cooper3@citrix.com>
References: <504F2C90020000780009A834@nat28.tlf.novell.com>
	<504F10E8.9020007@citrix.com>
In-Reply-To: <504F10E8.9020007@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 7/8] ns16550: command line parsing
 adjustments
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 11.09.12 at 12:22, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
> On 11/09/12 11:20, Jan Beulich wrote:
>> Allow intermediate parts of the command line options to be absent
>> (expressed by two immediately succeeding commas).
>>
>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> 
> Can you also update com{1,2} in the docs to reflect this?

Sure - here's the incremental diff.

Jan

--- a/docs/misc/xen-command-line.markdown
+++ b/docs/misc/xen-command-line.markdown
@@ -199,7 +199,7 @@ If set, override Xen's calculation of th
 If set, override Xen's default choice for the platform timer.
 
 ### com1,com2
-> `= <baud>[/<clock_hz>][,DPS[,<io-base>[,<irq>[,<port-bdf>[,<bridge-bdf>]]]] | pci | amt ] `
+> `= <baud>[/<clock_hz>][,[DPS][,[<io-base>|pci|amt][,[<irq>][,[<port-bdf>][,[<bridge-bdf>]]]]]]`
 
 Both option `com1` and `com2` follow the same format.
 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 11 10:49:10 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 2012 10:49:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TBO1a-00051p-18; Tue, 11 Sep 2012 10:48: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 1TBO1Y-00051d-8j
	for xen-devel@lists.xen.org; Tue, 11 Sep 2012 10:48:57 +0000
Received: from [85.158.143.35:38284] by server-2.bemta-4.messagelabs.com id
	B4/A6-21239-7171F405; Tue, 11 Sep 2012 10:48:55 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1347360489!12549349!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDg1NjI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30450 invoked from network); 11 Sep 2012 10:48:10 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Sep 2012 10:48:10 -0000
X-IronPort-AV: E=Sophos;i="4.80,404,1344211200"; 
	d="gz'50?scan'50,208,50";a="14466528"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Sep 2012 10: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.279.1;
	Tue, 11 Sep 2012 11:48:04 +0100
Message-ID: <1347360482.5305.143.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: xen-devel <xen-devel@lists.xen.org>
Date: Tue, 11 Sep 2012 11:48:02 +0100
Organization: Citrix Systems, Inc.
Content-Type: multipart/mixed; boundary="=-Sfh9NpehBPpgCCvRbkpp"
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Subject: [Xen-devel] [PATCH] tools: drop ia64 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

--=-Sfh9NpehBPpgCCvRbkpp
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit

Removed support from libxc and mini-os.

This also took me under xen/include/public via various symlinks.

Dropped tools/debugger/xenitp entirely, it was described upon commit as:
"Xenitp is a low-level debugger for ia64" and doesn't appear to be
linked into the build anywhere.

 99 files changed, 14 insertions(+), 32361 deletions(-)

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

Patch is compressed and attached because it is 1.2M in size
uncompressed.

--=-Sfh9NpehBPpgCCvRbkpp
Content-Type: application/x-gzip; name="tools-drop-ia64.patch.gz"
Content-Disposition: attachment; filename="tools-drop-ia64.patch.gz"
Content-Transfer-Encoding: base64

H4sICEkHT1AAA3Rvb2xzLWRyb3AtaWE2NC5wYXRjaADsXHlX40iS/xs+RQxV3W0XsmzZYLAp6rUx
BtQNmLVMV9fOm9HIUgpr0VU6OLq3v/tGpCRLtmUDdczbfUsdWMqMOyMz45fCegNnp6BPNfeGhSwC
X4v06eYbuA5ZALLmQl9z/AmzbXhvaa6op3c/61YUWA+i7jkfkPpYixhIrZ291m672exArdVuNLD9
0jMYyMfQ2dP1Xa2zo0uTlrG3M9nd7ezu652GttvYaTb2Ozu7erPFzH1kudIC5kYArKntmzvYarR3
9HanrbUlg+n7+ybbZ1Jnr91pdbQ9qdPajDzPDrtgBJ4PltbegTD2fS+IxM3NEXO8O2ZkLWAGngO2
NXnQQXMNcCzXqnkhEo6nVgiaHXqA0m7BYRC7Bgbggbl1y9Xt2GB1P57Ylg53lgZ3WmB5cQjho2Nb
7i1JOEb1Pqri1tQNNolvblhQRwFW5AN6ZAXMfhTAiuBeC8FgoR5YE2SIfc8FDKODPVrY3dz6PWEh
g8D27ms2u2M2ZBLB9ALu5hZ3wfBY6P6EnKhcC1A7TNgm2YSSLRdvoymDSWzZBpI/3k9ZwNBY6HTA
tGwWpgNvCCDtID2OeWR5bljZrgrQarbaEuq1WdJWq25uKtaNy4yaZ5q1yWP3ufmxaVimCbVgbkzp
vpgWwB6iQAvr6aDU+55rWjeic7tZq9VAq6/q3rjA+CnMB6kB0l63udtttqHZkJqw3ZAwCbe3t2Gy
mnscs4RbQgHd1l630Sly//wz1DrCHmzTD7xhDzyRfh9cqvLleDA66fUH6m+DkSIPLzdhE97AOHik
YTAtHB0vjvgAaIE+tSKmR3HAwNQcy36EcW90OhirvVH/TD3pXYjEe2IFYYRjwvRbwLFCVkzB/bYq
iiLlg+65kWbhAECFsoB6Wk0h/XxMLto7VXGz9gZkE1wvoiaywIU4ZPC2QnYXFFeh9mGWUAKgms3t
57JugmWyz1B5WyFXQxxt94ZbICzTVgXqQJYFp+GQODaB2SH7oiShwNbJ+PqFdssopcuzZZnuOWmD
0/iu7sa2vTGexvALJntDgkajy/8BLkINJG6kWSIJ7RbeCg1MExwAGgPFZ7ql2eCkOmehFjnBZo3i
NBoOxxiHt5X+9ehYHlXrojj7t1lLF580/kRbLc6MnCBhKe0i53nTPC3FBhe/hJaPiDLqK9A9hFCz
Rb3Ytn0I6MBSW2Q5bKnRuotEZaHNvF9qohXPc58n0nGWmvhyuNQa4tQxllpxDSZtS+2qGjueYVit
JeOwx7DuynvyjrRrePTLLGpesS2N2mIbd3GxkaK22IZRW2xKo/YskejxYlMStcXWJGqLrVnUFtvz
qJX0pMEp7wlLe8pYujQfNMPwAwzgA15jq8onBy4uM7JqlcbgFOfF8OSERoj4bpir4vZEg5319JSL
Yk+Y95wBJLou5Eu5NlTSCZbt+Kku+bJfrSMnlkehOCWdmm13i1alhOfyETfpbaWgukqUBSORYgMn
ex/XXgVqHrz9meb+1dXJee9UqcLb9/MSzub4SR7yh7gF1FwGW/V/1j7U4c+wjh9vDAwWNtYPwP9r
C96jKPiA4hN5ZbYWJeNeUAztvHdng96xmnUmDvRGVQjuoCBtjp+U6jbT3C5SBw7UzBXxeonWTM5C
NBabcW/6ur2kOMnX7yY55XfYT6QdKd9QRL6BbM0UhlsU4nod3p4EjB0px10IA70ePoZ1LHBvWeAu
WijcgSRKaFOjUZca9cYO2bnb6jZaYJgBDB58eMslAv/Z9/zHwLqZRlDRq5xLANmNsBTtewEWQRpV
hZyyh8UfpwwhQAwRYMUtUkcqxsXSYBJHmLLNurRbJ0kweYQLrKGxhEZhLtME+MWbunCmBYEVeq4A
ffyMLFcD2QsMDRcoIbFqjGJ+jSdaeIs8R94EEQYWHgKvhRWsZbGYizyswDyTF159z/HjiJuK+7Di
mdE9wgs41yapvCWPcss/9kaj3uX4ExzLSv+8J18MRrO+8ZmsgDI8GSPRAPD6ajT8TT4eHMPRJ+wc
QH949Wkkn56N4Wx4foz1IfQuj7H1cjySj67Hw5HC5Wz1FOTe4p29y08w+P1qNFAUGI5Avrg6l1Fg
aoY8UDD+l/3z62P58hR9vx7DJVYOXMy5fCGPkXY8FLj2ZV4YngA60D/D296RfC6jX6T0RB5fksKT
4SgZS7jqjcZy//q8N4Kr69HVUBkA+TgLwrGIZqBqGPw2uByDctY7Pweqhc+51WMlTZ+Cq3A0QBN7
R+cD0sMdxSk+6I/Jo/yqjwFE684FUK4GfRkvuKTB7wN0pzf6JJAClKsM/uMaCZEAjnsXvVP0rlIS
mUJQuBwcIiyxBhdkNUZDuT5SxvL4ejyA0+HwmMdcGYx+k/sD5QDOhwqP2bUyEFDLuMeVZ3IwakiD
DUfXiszjx8HA6PpqjDigimP+EaODxvaQ/5gHenjJ/cbRGY4+cTkonYLCx0KAj2cD7BtRbHnoehQT
BUPYH+dkpBIDOi74y0VdDk7PZVz++gOiGJKgj7IyqOLIyWjgKUkl7R97KOKau09pgsYll3KSjVlC
C3xsQT6B3vFvMnmQMmA2KHJmCoWwf5YOQT5tlmYUIRcOguJoivUvn5kczBgsmbcB+xyzMCIqDZGs
bXM5fuBNbOZgLyGuEJA1Aas5/YQhsp8gcI448CZsbSDM1iOEV1rEpUyjyO/WaeFltuezQLTIPIKl
dbx1Qy8OdJYaj4tsiMxkshjhko/3aIQ+q1GwZBc1GxEwQmO8vLG9CS4q5b1ceXunNkGbQg6aCY4z
AvBIbhmMSDLWLt38CaJjWZs1oAig1qAlHWqB6Juh0BQa9Jf6XM8XLSheHhxs1v4C4nYskgOQaD6S
cXLKp5c4epScp5hbxzKtUTgbT+VLBTBJBgkDFjZYFlk3YO4fBmR9samDTa1SfeYka3YSi0wdq9gH
E8z2obmf9U2o7ymGvUOzU2Ao6LAWWChNI9xmK1I1vX1sIHySoA4TDDEkis1A9zUxlPBW8NGatmDu
lfuwUn4zk88S+TWU/46UkRJubMVvV8F0nURR59DcE1CdKc2N01NqWpmaz6RGy1VIjVxHqkJqcE9Q
R3kCrNayM3NGQi3o0Tv6wdVIy2okHA2B/jVe5MruzBVSgv5sJ5o+r3UI1UgNIe19gUvt2fiTtseZ
tjR8+0vK9rkuDN7+CzXtzfxqkl8SaZLIL2kxF/JUkKQvdGt/5hYpe5wpe5RWu0XKvsCvTqYqaPLU
SzIcnVwcLbcwXHs8MdovVCU1ZjFsUQyxKiat78jL1W41uFudcl2La0mua7YyfEZVURC7OlQ+J/OM
Lzjmg8hbMz3FpWp+NU2kxF5k0ZH0vYWFLu45aHCwDxXLxHj97RAS126yBTMoSnSWl+rnrdGDy+N8
hebmLPpbuJwEYsAiMfSjW5jkWkTmGv5sf/pqTBQ/HxTF3xUVNUtQUfxiWBS/4qJXXPSKi15x0Ssu
+mJcFK8HRqXdRWQUu2uwUfytwNFsC13CR9eX/26ElFY3BJCwOCxU2GthUsq1l1TL81yvWOkVK71i
pVes9EKsRDApB0gL+Cj+3wSQVi3S3xIixd8QI4XPx0jh98JIzZ0VGCl8MUYKc4wk7ic4abfekOot
vGyhqd0mzjbHz3ASCa69AqVXoPQKlF6B0v97oMRFtJpPgZ0ingrX46ml7gwqhd/sOZI1X5qkuzF6
8SLIhCw3zGUBWh6wG1yM0eM4ZEY37cQ/iKSwkFofHtco0reeoA+9oEC+v4YaN5rYjgrEZEqoB/Tr
zzOD027T9jAR3Zua7yH7rDdM/EE0JyA2Ewg/pRUuzz5mWDr9WvQiud9OAvTHQ7RDIcgAZXrfIjRZ
qLIm82CzvYw/94r4cz0iLD6ha8/lwVMMiD05KnS8u6QGbjw0TNMwFpVxsxjWAmYHiYLmrNysItr4
ariJSLMI/pYq4XYZ6FsrsFVdBK3LtfxeGVx9wtCd6jK0KzMXBbeF540Fid2tzsPSbWj+s9baWZKc
mLy3EhGUyUb2JdRWhjWWTX5C8N4c0mg+B2ksPdheiTRoZ7CZFibP2S0TJx0S4MqC0z6kzeJbQJEn
Fr9vDUXCbwFF8t9tfRKKZKTfA4rslkKRVOMLoEhmI4ciLcITrXoDAQEhkq6028WLUJ/eM+t2+vrM
5hWKvEKRVyjyCkXmoEh2qLaiHnY0i77zNodHkkV3JR4p6+Z4JOl4Co+01uGRYgH8xIEgToQeTj68
+nIUsv6JlGsIoKP92KHhUNne/SIqWcePqGTGPlli31/DPYdSXgRDBDqCph8S/cjK8KdRSQ4rJI5M
ONvUsw36OiKWW5llphc4L4MhfCgiaNJ0cXycDlTI4QxKAE48SbBPQ0ilJMgjNrNCOfHheXgl5cow
y0sO3/9dT8q++BHWCx6Tfc3TuBc9Kfvqh1gveGD25U/lXp+U/R9+Ukbr395hbeE0ZLbmfM+nZ2WQ
9kuens2krhHbrELAw7YNldqkSpGjvge01U6kcVQ/txgWhFqT1fi2sL0mv2zwgn11CeBaZQDXeh7A
TYqDrwS4sy+1rge3Kdl3ALadHNamX13s86/w0RcKazi6D8yoBVTjHZrNmrlLY1YzJfxs0WdzD4l0
zw0jzY1qN/68iG0UMWymbT0ll/sAWhgyB4vJoHZvRdOa7vsLZNvPVW96WG3WzEBzWFJRUO23JMp0
vRq9PwALj+Qm+Qpqck3f+tajGhZ/Wkhf/15wKRV3fpyIQ2mIWN1UAnZ/XQbk3yBenwIZ3XfIgWa7
nWdB/R0m/zs49hC4Tx7h2GKRowVwpk1deG8kd+IU73424/+yojCuhRYVQWHykgTkpf/f8E8mEkZY
9IXJyQUBAsIp9J1+HNEEM/CWieVqwSOv60IBKLkIptCnF0dcDM5bfrxGQhDtBAwQhKSIBQED1clG
gnsIIpkelvv3lBWYE4bF3yHBxRCjw6Iuv5HEBev4kV1qFsEqcOKQal168UECvSbeHXWlJzpcCtD6
E1k6gjCOx2wUSHJyzdzFebNQq25rloNAigtpLpuCKgthyUxBX40YzftO1qSHmpkow9NjKpW1bOzq
BDz5qyEcLOQDS7PDPPx83Ehy0RFxlglPnvX0rsdn/Fhj/oAH/vUvfrrz00/UxUV92RHPwukOl/RF
JzylpzuJYQsnPCVHPAVPk2OYkuMdLutlRzzrjneSteF5RzxPHe9wWc844nn6dIdLeuqE5/mnO1xc
gXT5iOclxzuJm6VHPC893uGi5o94vt9ye6XRGQ8tc5F2y9zkrUPp+fZMMT+j2ay9yd7J8T7buLxQ
nH4o64gefbaqz7YmK3p87YYtdNFLjfD/KobAusNabpmFDjAmmn67go/2WlX34xXdU7Q+4EchKwjY
HS5yq/yjssKzFx2ZRYZef1HehYUznTrxXv6oAec0rp+OF9CqzYXCxPMi3JHCEEMVinxo6HyFmu9Y
MPFCdpCwJksoLem4tsbJ23zSd/JQEw57zTNrhvaIS7jpCRDG+hQLNqAxiLQJqdJw302LLSHZDQ0j
QNXZIX84xbwxVOLPlQjpfoH7BO0mt4zvsmKaRrFLGwNXz/nU8gbuQ0G8GsG7s09XtIQow5FaVHwI
lQXC6u+KrB71lEEihRuG24+OJjHVvM8uT+5P01AlYUo9pVNTHI8ItyrrD366lbwFR8m3q4Uw8CHx
NaxNs5JBw9uQ3nuBpVVGYXuagbs3j0JqEyaqyjOR+lUu4R0sNFwVnShh4PRHeHtFd+SRjtHgGlXd
MVQbPf17f3hxgSuleo6rqqrI/znYlv5xkOTYnWcZmEIk9D6wIqZaUaBaFd7g4230DvDjSoAYo9Nq
qvwoL7lDigjuehgMzI6NDcgb/bBA4d/iyv0nUvBAM7izgijW7CyKSUQ2VFULHQRcd56NxYPNKluO
d7ehB6Jlaoc/NLag24WtYKvC9VWrB7k8SlgIcayeEhRZAUo6OJjJqvghvH8Pcg/tlMfySL1Sqv9d
8W/nG38dfKrOFF7FEcUjeV0ZziQ+LpTBWM+7oZ3UPdlxJbkGpSZhkEVrA3/+/YfGPw5/kGYmIWtV
4FfvKlkE31VpBGYmKLyMsv5IdK3wOQzsP0Rrq5rh2WSYHc3HrLFVqlUr1JSOTD7a5BzPjA3KtZBF
ajpcqh9iXuiVBjfDYQ72VX5EagEaAg+/Z1bwFs3c4IHC0pPvKjRCUTo2eCGSGp+O+pCOU/r07JKW
MCuap3I0JLsaD9SLnvrx6CChRs30mFGL0oeb8yxaUbCm6yyZhYuSjSKZgQ4+LtP4dqr96hxTYHR5
kBpr3WGAb+gxPr3pbl57kLL0Ruro4+8HBSuy57TzKnyXlq/ZQFdxCH2tkq9PYjIwGH1ai6tV+PAB
pJ2DgghGrjQyV9iDznyeFgYzWUAPEpK9e4P2gw1cnC4IFfhxgA7Q6/VgwnSN4JUGVqTXjUjPV7kQ
sXY2SRNmBzeL/PcYInvyN95ezzNIV+2V5gtJNBVVav/Kk2hp0UnSic+8MU5G/hwSHYM8QCtlJ4S5
glQMzl11NDjd4/pWZLQ0myQYQdlN3gnGvUKUzgIX+IKalwRqVlukKzPOOB2S+ZVN/H5KUZxj6RKe
MauzJzy8loBDJCGyDZFKJxzUPtb+R73+r2Pc9lROw50Us80HE2f2BMb23JvqjyUmEstf5Hth85xZ
4PmVTMnwamaPAD9ybbOozHlIO6Oa79aVwsaNOwWP8KwlX/bpPXaYYoQ8Z7XDjKxQn/BUyntEN1Bp
dSdn50XXPmRdB/Mc85XBIlOhd4HPtLWbMjW8fVFHhAWZ6phumYasr5SH3UX61N1YxZZ0L3Bm1aTh
OddiudJFknUSEh083fDPWkml5vgRn3AlVqQ9B8tDGKn84C4scbzYvcCJjqj8NGKZK+ta5PCMhKyM
Jesr4bFZWVTTntXTIC/CwsXNNC/I6LzMwYqYF2KoZbG8o5jnBAfL/My01PARtU9KufPuFby4YeK2
v5I36V7Lq/Liar0ATrNaCr1BlpNsrBEzI3pCDuKckPa4NIfXy0uJS0SmuZ6maexgVWSHq4WWkj9H
bODdv0QskT8l1sNqQn14ptCE+FkiH18i8rFEpOmH91ppqvCeEg6aSUE+bZcZiwRr+FelaKG/hBvX
uf9h78/727iRxHH4b/rzvAhE2WRImZJ5ibqi7FCXzY2uJSknmYy//WuSTYljXtNN6shM9rU/dQBo
oBtNUbI9u/tZK7FEAoVCoVAACkChCvbDS2o3AZaUz6rdyN+39DA08qONMkBGQbyNlJOBwMlgU4Iu
QnQyPYKlc4L2NdLlLhojxJt+3LX2p6rMm1hFtzaCpq5uZfDmAhbiSW/2mCiDEpFHHWi9ADsMP79k
foOtS2qrSZif2I6KDVH+AAz8019Lf1J8Emfo3Bqd0BrNlJvF4QA2/fMQ/k+2b80AXkOfm7mcySVU
+13zOaqFU1yIAh8VEYfeprfeBpiAzwOmFz9tAhlQA7lbRuXz8qpz6tG5K+xgrkgP3VegOH0lIC8v
dO7sZhZO57Q3KONmFPVadBZ5VRD/FHZSI510DEm8IaefvN5CmUDnDQeU3OpYVZ454Gh/Y1HRYgki
6j8GMI/Y+ndCBTVZ/T2WSexT8T7Mw5Fr6ZdiPRrKTsEZHg/SIHE+lis69iYehRmHN9w3KC1GIglF
GEDlE5mf1GmHBSPDXOXNdCBBfbe21QoGZSWCRGpGct+CGXTIdlWIacRG3YAgYsPy38/HsN+jHQHs
OSfzj/m1k9PmRhuW+mDcAYg98V1/k/6HXvmuv0f/rxWNrpqPN4/9xyL+PZ9O5rf06dfADxNA76aL
kKGGkwXuwOBjO8ALIEkcUQeJWO1f8Mbw4EAAMd71BV0mnDZPjr1O8/zkL5cXJ8RdTTJUgIV+x0Lo
pjtCJ9ODYdD/5q8TOpzI5cidtqMMVoRtFNCGEW6e90Tp4bsHKCc3e5p+BV2ULSZoQv4HOesWJhMt
JhfEwIfdfF8Sg+5Zkzs4mZ6cIAxJUAeFxtxiSPEAQMzpBA+tLo8vaR5LwhKNLIOmPjnB08u/oVne
eDiZhlLm8CPUaYwqnKKkuoMOuN+ftNRXmPf52AbRQCEujIcJ9X2N6/sD8V+lh4H8oUMGybPWYjLB
az+YtH4BVVkilQKIHWLRhzV9CxJTMjBI+afjBLoztU5sBXXtSPWt7Fn3rq6w70BLR4CgPHUDAzul
PolZ7dcsvHKThIsPAdCyvJjI62SBLX8CI2OwkJ43jt7BgmeeHqtD/VUoTW7ysghWONUdAaJZSrBj
z0ddGEz6wwFNTbjWwk4ooTKIH+mFSjy0UP5u0EAYYWi7Y/0AEREJi41GjplPM6/QHtaXW1dIsC/x
cqS+YxpXiC9wXfdCYw1903dMUTzoeHAvx7FHeDbuoRI6VwczkmtUJJe7wr6N2Bc7XRSFYx4DeL0v
esDmWyxoFFr9VvFz8+cKDTyiSFq+4/EmMOsm9CdzjBkygNppzMHkcINrxRSDjKBVSITN6eLFGE5y
fExFCJXFfKSer6Bm7kfRtDf00Y7EtnbgGCV55OGaevCyVsCKCFk/8Efq6FS/h5EWK2g6TdZJNFfz
vSDSorJHw/FQ1qKMLeR5MrRigUerSHORjV7wb0BNpCAwEaz72r4iwHs+jAwDwsE3dW/oEeq6iDAq
CmAZBvpeS1Epb/Sm0oJGsozqvr+FfrVaNGTJGYB2BVXz84D+FFhINf8tAFVaBnpx2dywnY28ukwZ
rEhLFXXBGDFB3OMyC6Z+9diOLlfx/o5v5YzmhUgKWX5hwAt85aBsecymbBq0vDtxG6LIZ0RF8XOz
8w5v//XbpctTsgz4qXlxXDRNT0wjEsPoxGFZQbUuNTMpMranDE3ISOLi8qJ5cdqCqshSw/WWCOtj
oxSyNmmzWUjyOVX6SREZrxS1vYiylBBJAwvDFqMB/x+hUQe2KjbMIPsL09KiqC0tuKWtS6hIWllc
KquOixNGhX1gdxWadChbDIuq45MGbD7fooGJVWJTWztk2jronSNZD/LlwDop9Xcg3NPQm+BZ5m+4
nUXtbe39u6uO6MS3g2tFvqsp8VZ2rWlcInbODlV2WWYf+3Nfp2NGRWY0Rng5ga8jHBgArpqCs1AB
RM2s4gJmIBgtRvaWg8CfYGt3DiNOwdRNFMnMbZWJF2wbh8O5bsOOA3WD7skUGADtmrjtXGKQYuBh
GPgfTSZoCMXDE7rHgaGOT6TCcDGLkShutuT7SVGuairL1VRmLc6spTK34sytVGY9zqynMrfjzO1U
5k6cuZPK3I0zFb+uUBm+gM3WFV+sqrZWFMOwn+K1UmeXMztFtGixkf1SqaQ7xoAgEMW5t/I504m6
mNQQWviGEe6D++L0aqMlN18aSLHxwu/ge9ZoMbaRKE5i7KKFMbwoM8XJSszJiuLkMSo2cbLi4fWE
3ohBoRZepAaTXqAqrZY0jIzUFvR5aFmgCKk4emq/hTr1FyPdK9WKGwhmjJmGUew8m94H4caVvoOm
aQUqVdAIqxjbIcXrECB6tzY2xdU21DYK+CmCBZAS0GosoNUUW6sxW6spAa3GAlrdTWbWSjqzVkpl
luPMciqzEmemhnAtHsK11BCuxUO4pljVbGxAN6RktLZl5dPkgSA6v57ONyeXWopVtZhVtRSrajGr
ailWbcWs2kqxaitm1VaKVVsxq7ZSrNqKWbWVYtVWzKqt1Gy3Fc92W6nZbiue7bZSwrQVC9NWikNb
MYe2Uhzaijm0leJQPeZQPcWhesyheopD9ZhD9RSH6jGH6ikO1WMO1VMcqsccqqc4VI85VE9xqB5z
qM4c+oMOfdAyoB8M5IU5nw5pMyvYpOT2tvdJtdios0EUaLR0tcoVGKAjBbq9Aaucgh1Ne2ifnYdd
ymv8UkiVC3N7ZH6ik8Kw692EiC2ZOnCmziC1bqcGUQ624ESN8mKQqPcut1fe1+Zj2lTnDzEcRN58
Pz5F60892PnPPBiH0zBPH6n9aJswH6jzNCwkeouwOYj4LE0dYIAWeoVbNKnx7akzyvhkElHSoWT+
u6hAhxnzwcaPVNFkMTbOV9IKoQn4IYF2OJzxGdhmuT56gO8DP/6qqwEo+WHgJxHMotBGELkQAJTC
ECUxRKFwFYnCBODNTFi0RjNXuRtJajRLFA8TxefO4t2S5GyyeLduF+9uO4vX5d/tZO07wgUf7iSr
iewOCaOeq5pIthKykxWBfmghKG+56i3X1IetFIJ6AsG2E0FdfUg1FbRFG8GuE8GO+rCbRAAKo4Wg
UnYhqJTUh3IKQSWBoOpEUFEfqikECSZWnEysKCZWUkysJJhYcTKxophYSTGxkmBixcnEimJiJcXE
aoKJVScTq4qJ1bK8WUibdA5Gi+g2jPb3eVLiCQx2mev5PE1p64U8XRvA3+/VGOdbOby++YbhN++s
I1ucKDbv0ISQkdJ1CV06aeNTtGa92ldJZAEshvJeKG5nbzDehBWI5kb5ZaROneVci/nG5xFf/yB2
smVTkz2QL8cWLEL4aUIGmgyNB9z5IcDHKPfFkJwl7Qt5Xcb3feIHvD2NLQepnu/RERj+lAc7ZExZ
VXdskpCNA2obmUCQYSV/7uIWkz//wVUg5NPYuYiriami/6XLDgp4HU5F/7DaXMKm/mA3/fVrs9XL
KTo4ML/GrX79muk0pPa7vnEdAf39GkP3riNwIW6TLIdE4j/LPn8x70/vJ/n2u+vO8eXPF94Mdy7T
gbzo/bTDfhnddflRPwF9iVeU5Z3P+YqSVBp6OojHmX6IZh7/kiPzr+8tv763/Pre8ut7y6/vLbPf
Wz7/2SOuOis/bXz6PaT5klA/VQvQgzl7JNJuvtBZyP1me9N8tqBUAfm6C83+0WjJG6ATEK2L4Ler
ov7qxx+78cde/FHaBMFXqMi0pYlNsmCvPb6Sm21phQgJpu1hDBsrqA4ine8+kMVQKRr9nFqWQDE0
1ubOubg+OyNCSgVUGtGICToeRkk7YWtl1JK0ElLGY6wdouYjv2vzH/34MiD2UiehGylY3CIxv58K
Ytxi2EeGkx82LB+JEt6qB39f+KPh/LHI8/j9EBbjsrqXis3cJPcRSW88y8cYYQ31RrC6mCld2RuS
UOgULMNwXatXuEQhYY+nDd4MsyRleB6M2ZIN64G09mPUIcM26lc0Xer3JvOiGBbRQOdoOrk7D8hi
TxppT8NHry8tE6YhKsdouQ3Ssg6/FRw2e4GnNvyBtj947za4fx9M+tPwN1Dm8MJtbTH5OAG9c00V
RKhyHUkb3Gts4WJCwodnTbAQR7TJifihJZeaTgbDmwV70Ytbh8mkyGfDFEqqEtm9kY/PyNqNM6/9
a7tzcu51cPnw3l43jxOQfm+GSn7j6Kq5HKhSUmCVUgIyHnDfxyPGHHhxqn5O2Ap8VjeSHQqLIx3D
mZ2qWp/oeKdhcPwyQdqeWUM4gTUpOVctWIq8w/f5tRPKQaNHepTsz2FbOaNtiVmGqoA+Vvss6nR8
Twd0mXAbP54OwzFe77Pk6OkHysopILnfygO6guSfEjjaoonvvxfrKFfi9esh76e0QA5RHDFTbpLs
DGnnTJNH3FKB89GGTV/KeEpTsL+kbCu4G5JVhCqrrL9yws0MVcCJ1WD/RozZMP9zIH7XDzc1LBka
PgmFm1W0PCQaYDwqWXMMV2K2o29bDNqWkCx3OP9I4/wlz1tQ0p96vLLP46uvSXPMX0roMquT5zuG
gAOLzwlRjCfSZydEviyjJTOeSVFMEQhJItJYZqkUHQ/oM2mGuQDlgCs71pXlab59ou3qoIRmDLwo
QLeMzG71JjcKblApicgMcSAlS1rsW0IFgiM6jzM0730QoqGe8ka2CSRIy5CatvEjAsuPGpqXYhMt
/FzdPkZtNG2UqIS4WIzxQjyNm7AhPGxaR1RG1nBBdqSXAyrGtUSwc+rdirwmRh269PApHMxQCcHD
6+A9PmBJELjxYwa4Vi6s0yaFH6f7VkB7QO69ZdhTwE/jZriL9+2n8GrA5ThROkEUyPvz0wSnoQ3s
iRLKdlV1MEyGya7N5Rx9m5kjXptZVueDDoca4hXsCeKnLPKoLR6C+gTRtGAXyWc7eEQEY0qsSdjc
mhw1vVtQWkRsSvDNN98YrTeZK88ezZUUP+Iw1S+Y0u3bX1KIni2t3HyJKW65Ojh0SQD347k/mwX9
5uUVtK0983vBMjGAIin45WJ25Y+Opv2A/OM6f6x2Wy/Gdbtptk6zLUP8mFJZLxAnkQhbOIXSUVR2
5pP+VNv+kJNsU9z6dwHaSoI6t5iRhvaeH66z2Bpm5MFdED7S8gqT8/UFPsXYIC8ksC2ckR8GPESi
2AN4KERv0KGcLNEO5hJxg1FCJ8CeBzcfwf2wL4+MUHaj+WIwwNPBSBZNuPIg89mJ1ib1+qA2QaqY
9CMgnQwrz9GbnMsL8UBOtnq6B/UAhfH85Pyy9asnW2mefS8D//lQHncTkMXGA7FcAOIbkaeruT4q
JGYCXEVx87Qn5JTPw4JP4uKp4PrIcGjxDf2YcwA9GswgX+bQa6urd7+2vc6l12rVl0h0jlnMkqYO
70HiLqb3Qi50Zudxp4Mcpjt7Uz/Yh02Zev+ot/AzWXmeapNXU8Rs45YiAipdAljgobNcaVsGoxWX
J4HUG5nlFcoHkrKlxsGB2kDIvKWnCuhREvi2JxYT2szg6GaOQxn2KaO4TMIh55Q1ifzgu9GCrQ74
u3kasR935NtgjoZk1Iv6/EF5N0Ld7CaYwySGZxuyBzOOV1i6rHdp0GeuLnzLJdSe8kkK0NBjzvsK
NwkGgEkGJevdp5OUVlxSqs3oM6fn8xMmjk1hbN0F+7qStt/2ZlOSFi8BanlkDARzglE2UL38bpS1
F1KlTHhJ2ipHCiSXjs2O1QxK5E1wYvv6NC3mNSJdFVsnS98TjbBv3eSN51vIKIrvI3+k706zXzeS
dy74ljwv4Jko0X0iUVPcJnsZPp0uMOgITGuJc4GEGmic+6UWYPsBJqoUU5juJosgXoRXZgUeymTy
AhEgANem5utPankD0MWNpp9ntNwm6PO0vlJ6sv2V0mfmQKVk8eAFHFAkZfHgj0+/qsZD+aduqhHm
C1xU13Z3P+tFNT/p+no3/fVu+uvd9Ne76a930/9T76b9aPz8K+gn/OFS9iAzezoYgM6ddSduevA1
bke5Sgos5Y3xECcno0zhF9gZvaFFRm0iKVXPBo3whqYWfi+aC8u13CzinQVs6Yb4+N+CP6cFINDg
WxthpZSTAVQpDZa/bjTLKS+e/G51EtxrPLnlucPhsmzoLBgRrV/zyUYX6KpjjNRvDsU/Bf3t4XZo
egd07mLwqTDq5XJv3ogIz4Pgi7i/xcCE94EwGAZF5t3hfHPye262U5ztHqBpcXmbCl5HQUSY+/MN
zU9gldpq/jupPxhwaQdtBOfhIthT+9J4R6qBdl1ACi9A7e9L+pn2AzqaaLVPvLPGX35FDHQHDTIj
WjjxyabWD8KZKiwtXXNcYW8U+LyChuQphF2bStjyniy/dTCcaWTbB9yfOmGHGDnB2GRchd/vU6HK
YKPcLcInqkqdqUGDQti64sttOoz75ptveA3tBrFrTPJtDEsePReYRmRlsYmhp7C787OdAtY9yoGk
HeTRq87JmdfuwMwvNkS+/MMPMonObCjda79rnnbIZ9H+vuI24lnSGfnZbsHdDUT5G9bUVEdbAFg0
N5/5xAZiAMIjE40c6JVynXNCO2cbcrY5R/Fa50azAxgtLLTcqcTFiyDAlZ6Ow3Go6uggQCBaOQdi
c3NTyDMS5RdYN0JLrskFYrPqSzRFVz3J7dCZdZlZN5qiM7dl5naiNRIAWoP52KK4QbGIAzC5/EB+
KHmbIduSQwGkD5J3ZAo6JB4i3JaRAIMUBy6PMzmhxfOIBhtEB2FJoQ8HaixU9sxhB7MHNzZgFyac
rEoZYW82B1BDyK2bTO9RpOM6Ty6OXZOWPYurruF5XAh7Is+Yw1t0bMXKNKrJJUFNxqHHFLtnb3pK
sYGPG4zpW8heowc6Ez0FpyoWPMHSlAKLRHpqtlpS0NNH7QDK8bcRiVqez1vbLa/5z/hjJ/583Pln
7q80SnVSy8w+PTO/vCuYwoLMQDGIK6wfaODDCz2FTfq9MRGHcz0KvpwsYTz54XC6iMRDhwILqxLT
0ACvI/gYHbNG6Mrs8OKgLEGoeviVCaQkCPcFLEJjdKWRlBNDepJ8TWgBySNj0AXwigKmfTwXxfiO
QR/rx/uMVRSC4aSUyzXiCxIbS3zNLoHLG8MJTBsaCcqOVcQltMSnDfhVVWZVd/5oASstzVZQ3NDU
zMU/2VbsegxhOZreLHCQw7i8ieYfc/VirbiF8SZzm7jy52QYytG0h2kUKCCHX1R8yhieuocLhTMs
UJaChR+NZXazO+0/yp4EfEZPwgSW7jZZLMZVOQh3cnquigeuOV0BWPXgRi0GqMFgnORgJDDkUm7U
3yGJ/A067ENxhyd7dV4cu54mahH2ZsagNuDNjFkvq4Rdf+kAOjX+WoavlfhrBb5W469V+FqLv9bg
q5qTu3U5DrXEp/jU5SWF5DUhM4QCSEYe5Ky52OSBmmGQoUuYmU1BetgZUwnVrljBknIgRSi1DkiE
5qTvElZj9ErfiPpKkyOAGoMaE9lmMbY4RQ5ROIn4gacf3pSNiAHwtWJ/pZB1rpEUV8Ck6eFDgwGH
A0BAC3MHOW42jO/wkb8BW8IZDRP6ChIC3CEZpe8gItAVcX6NZJ8HngRUY09XBkwVmvUEEc7UkBnl
qO6DP9/MwmCU10yj1IJWZZle0GZZyOmyhKaXxHhA1YQR0u+iFiZJdLxkgQq6c0BTYo7D+8p5kB2m
meOL8f1Gfz5IifX7gr7z/Y3GuItDTCro5MtUTZ4KoloyRh3G0eVBp0UTxhbhlU2RzWZ9XPYZjyvy
7BBkcIEwlQ64gLmZYtL67F2CAsHS2/zolWP5El2p49Iopms4Zb6kwCMbbzBxo5UqGEKODmRHGErh
zPguB6OUJF0Pbm769sAULEP2qLQEXw/II1o2rXs3PiOE7t+jpMTqBxnlPQ5eUqbvoILL9C2ZvrVk
EUOMhYzlqMrLkbn2aBnl1UMPjc80Z2esKBjI95NWFVNmeT149lLgnIHj9aH8ypyvKyv0v8F9+TKg
JReM+S0H+gke5qyLULCGWxrJMn3T6lK50ngyE+27c5vjMW4rhhPggb9kP6+20jAftH/22ldFYCSZ
jnMyTAKQ3JLJMq2MaVctmaa7ISxXDn4DRB+KkH12tEH4iKMYOoc3XgxXB7hqieAO21cbVEMMGCs4
DL2N0GWCbl00OhtUeQw+CzXkToz36rS9wehjSONAwdrgGUTJamobsjKDKj58oNkBN3nbxQ05fUbB
nIlIbyh37CoM+q4BeWODCY2bMoisVkteIuzhBjFVg456RqfyztTVHq6stbWhqtQIFlDI822xjne3
kDDqyR2xwrk5GMLACGsGn+rEp5rBpVqMYJEmS6LYMkjbJhRbBootqwmSB4dV1YRDuwndDOE+abw9
aaWrNnr5sExV142q6xbstiGmFYLdNmC3M6X0kMTnsGxIXtklA4fULYcVA66SZh8LmW5roocle06J
vsOqgUrNtt2ycbLRraSl0qD8lLh8aHRot+ai/JRbaPRaV6vcVbvPB8zMgZwbcnGRgWpst2ZSuGVT
qMpXDSqJb6dGYwdVC7aWpPTU4PGglka+tRT5lgVrDiwHdlfbLRan8VPbDegUo+0KHMwp7y6vYNfu
itLSCiolR++Vl1ZQKdvQleUVVBwVLO/fit3BleU9XHF0cWV5H1fsTq4s7+SKS8CXd3LF7uTK8k6u
ODq5sryTK3YnV5d3ctXRydXy8iJlqQHkwp2DcpFOMA0tJ6fXbVR00jqJ1nHRkFAeeavsvNyIspaz
LqajflEk0ibBvb2JtFEUtC6aoeaoawo5tdraDC0slpJTMvUhapZWquT1Bmr7850csewgmtFqdmVo
Pcb1xXZ8avNHXKz8AadK0lZa1uqG9Il8N4DNIx1ixtWg3pHSmsKZ0byZ3hCma2GdSCpPWmVxXLfU
5S4gE5VWxFh7oU03w6doZWVKKWIEmarKvNlJ17VlaWN8jRZrY8sWft1lm+NgvMnXnLkd2uhDNSC2
IPeK2pql0SBba4mCQE6qJJK5ZSkyWFIthtS+bjnu+mcTpJUURFt/DkFaZcGS2zFB2wfdSloWS5rd
WjMFBQaKEvVmn2zH6phUXbTWIu/pFnHn4BWo1kTwJq1b01/KB6Q0mJ1OVOzEOpRWWXlE+APYrhcS
9OwaqhTPh92qA22lFG9LpIJDtBioKmVDlWLdRqs1cpCMeiZqW9BZeWIdXYFG84HVNYOKObnGuAZW
1w+q5hzvQlNbCc3WU2i4x5/EI9u3DNHOaoh2n0LE3fQkItlVyxCtxunKk6yurMbrypPMrqzG7MqT
zK6sxuzKbgIshShWAtISaC72JV7sxwNYw9+k1nye1QZqIwZrJ2wyqkj5ZDrL5aSaQOC5hFoQz0Os
NTiWdNdb/GGEZoR0RcjPdXy68WRNwT4b4TR+XkVzx6vEbc1KdzOlYhn+i+9m5MVLfK4EC3yNtzZz
k1BpMv/KOCQL6zGcOnNVqNynUrzppJNB4yRI1bG0bPAwnHtcQJ9sGWmGvubgEzPQ8ygsJRaV96ki
xP7dpjrRc3PpoYxWq467iG7JqMFGpDu2PV90OVDHIpoFE+4+8R9orAGp0tgRyOp9DPo6MC/d8HUD
gcFH58GEfD7Swxy78x+CCQb+8Cg4i67dkzXpO1vub1yddHeXiry08kp14Hmmc6zebdD3pvqU6s26
+DnA4F1/mot7f0L+8SlYAJlEgkqiHuLHeiMfqcNOuRofsFcOeDVtH707Ob680j644g4GZuc0s923
P8hxZPaTLf9Eu+ibYOKBEvK0Gy8N+CVidtTKKQvpIx1rIN8rAP7S9kuMpT+vOfRXi+ivFtFfLaK/
WkR/tYh+yiI6bXyMLrOzDJNpIU7kmcbKdiquSWzjyYbM3/aDAca4Oj45hd7IR4/jIl4YFuiJ7V/x
RTo6cI3dt/51svHjmgAwsSa+KwlY9dfEt3f40hNIX9sTe2JtuCbyiKKQxO5Bn1S4itngIa7niWrW
EFqsfVdaExI/o9836W//JR/Ni0FBuQjKw1exXigVNn4MDEIuT08JrtgvTuO6ZeO/7RcFnylMMVhY
UQC612Ja2E+CiTUv+n2tqCoVBQQxYbilBDjqA+Aa/WZwgWFKM4CjOQLTbxM4lzOb2jnFVkATCtQc
0z84wBdFv0gRzTRnmn85QVQAbrRTsimaFwoWG3+2cFuHjyZyuqq1w9/RJa0WPBZkTYLHaIXCa5aU
eBHtG3xVj74TMI57ZCI15NZCfd5KoLbKK5J/OW9cXZ0ct07etgG8XdC+3zCuLXpGwk1IryjD4KBG
cHMnHYQxt3sDENrOqXd0ek7v7DgVtWRMvQKUcSr504bUw/aVkYpndZSMR3hGei/qM+b2sZnau+PU
o/dG6kLhuLZxDMgjOqSfXrVbJn2cegVpJEEyWdJnkXfDaW/NtDmndVR0T9mQCkMCMytm+6o6uWom
o2tvmV6uWxnbcca2VQO6TUf+QU7J5GtdJ5uIuts62UYzYPjTBPxgWyfb8GHU4w5qHxng7LeZMnCp
7fxq5EWy79pW35GDe4yZ2zSZOVR91LT7aChlqGnJkPbFTx3Qalx5F9fnFrXDgS/LNUxsqhK7juFY
UqRw0KRgzxzYDukdRgEkhj8e6iv/MTxR4Cjb5EtZyqaz+2Q+ihvdByQzQs5opTJQbumIPpWBzOID
92RWV1Zz6KiHho08PU9mjnqUdcZ9/uaNkcXDCs+NVJdZ2SrXmXnD1LxNEcMWB5pb1HnK64pJc40p
rmXlb3H+VlZ+nfPrWfnbnL+dkd8tMzfLWfkVzq9k5Vc5v5qVz+07zGpfl9t3mNW+Add/mlX/gOs/
zap/wPWfZtU/4PpPt/R4oHUGl6FNI5rzbDBBVRPfvTQvTi9BMC+ow+WypC3rvLEfffTQagsWI8BF
hvZe4/i4ReuRs0gPtmIBnW55bKjXN8oepcqROGI+TjCpXJyTKLN5lcrDQUV5p+10nq/yGmmcY4Xz
/Hl5M18Tk8aqm5FuRdeffKRJEfMPGxc/waToginT8v9b6UMMWfZa5XoSdhYGPdgth55mAewejy4x
5LDBi1cbpqvUT31LTzrMk6/pGepLOH6vVv+XnBbxc/2vwVC/BkP9Ggz1azDUzxEM9X/MS/NZOLyb
zlZ4hs7/sec07MSRdFkqX97QhRAeX/ubDNDBEaTuBTnuO0Ion1X5mymMFbxO4Y31R8p+HXuGxGHI
mFrAXwZfzEzgAtf0hi4NWTsRm31/7rNWVFzz79Hn1+bNaNr1RzkuhAkUiTKnq3q1wVl7gAY9JIqf
QIs6+oncNLZx4o8BsTRfkxqsYL9xOLaZF5IBGOmIWhupKclwMIhfMWo7PwgIkCPIu6K4Gd4FE0ag
Tc0REC2+6DAec04egh5fV0CZ3m3Ay1HqMZ/mj7w4JLakXsex+Q7oZGGJ70Fx1qPwtosJzJ99XNIA
Mx2e+wL9vbN9k7xzXX49+4oekIjUa/z4aYZ6a2swtDkZ4tSJvjSlJNI9IzVXXjfuMWTCJWgSSmzR
ZL5N1ypaEA13e7Knwt+2Pog9/apbirTqLhIKDbmNkMrDojwi0myHFFkqiGLplK/WD0o//MBGUaDT
Hf/iweSpM6sHZVdm/Ows/C2sfOBHyup79YPxaFnVUVlWR/Xz1FFbVkf90+oAAfyZ3U2wX0fsMNkf
OLR5ceYHF5oeVd/7xpnyC9BpxV5W6ThP07eVok8+yyLR2UoSi8Rpiw4loC0G3o47myRMv8PPFg8u
v0RGzLZcdU5gh+WV6z/ZTdhe2oTtlZrQJh+oMA/M5cz5MXiM5OM45gQPHYtCJJAfav908qvXOnm7
JX74QfBL6p9amFiAQa6/Qxuax6pk1S65vXrJcu2g9FA2WzX7CM0iGzL2ni0J1mRSfrkGAFUDQIZG
tdiALjpnaKwAHYU+EvitGk66nbNDU/jo8Q9yBKXQ5kl558AldrKTmp0mJLYL/xT8et3mnwmETNC9
XN4+MF1cmK1HhwXzYZhwfTDwTX8J6oF7B9EimrgblFePEVGOMiYranQ6+n1GP5jRjFUMqzCZO1qn
AOkF/A70RNF4JGBN7LnhHF/5wW/ok/oH8zEB5vRzfUeOwkBdJUSb/XFY/jzJGYIxdqDJxKrrKzyW
SDKMHUHUTf6WB0kgch+xbTLV7ReivIdUoWuH+4BGPkhQiixjwJIORkec5B4vWe0ddJ2ykExOBafk
z+DktHF91jEwUt7xkZllc54Ab2YHnncTPwqE1XlAjKjEtfd7YVy7rlsrS5ywdZClE2HYhnqMHg1/
S2TMPEJNClU34E0wIcuhvhj5vz9a769RrSG/NNrTAt/Ph/NHCt42NC2qUs+5KvRyFANi4EaUiqLZ
Gdaq6Nf+RorhVgJP2kg5TTio3aEkOMki6lRUzTzS4a7iEcb2YeTkQekQSjrUHL1pDzQYQNUiBr2s
l4u6L4wn/ku1R9IcNfwMncD00SehrTq+Upa1uPzq1ww8vmAxEA/RUKADbdi6kQEMaZR8ZIUGU+ZF
1+nPbH11BNs6r32CfnZgc3PMx47vGymf4aWHekku+Giq9kRxyWLUnw9U/YolCfs2aypv0rs/WNSI
cmy82mvIGZ33ASI+MpUPGhZhYO5ZdCKovGqzr/RR3O8LMuHCtHwhsX6TPaFxJLuYsPRiv1yR23BQ
EgAGBk2CPqOQodrAypfkgHLNYx/0FtHHDbtbktfGiDRZ1i7jjfr8sBfQfdCPSqRxn3GorCutH2zj
JkFPNbcj6emoVuTpAL0teb+cXKDGQqI4mOAqn87UpckbUtGlzOTTSo42D4Q1hy038UJPO1ri8aZH
WPJdcuRyCuZYrZxmm8wRVgWsnqgcVIsxS+hZHr6bqnzQ4ysKRoO93C1e7P555i/I4Za0vmX0CCCf
wPdHOMBH06l0GaF3bLH1Z3/qTaYzZAXa8pYeSmVDKMpF9n6U6YNClf7Ec+O7+QrHxgj0BU6Nt7dr
X+jUWKgALiA/e+RyA7Z+QQ/N+ihMubgF/W/E28bPfsb89Yj56xHz1yPmr0fMn+WI2Thm/tccMj/r
FJnCGUyCUKrDeFIHUwDUjZOLvnPWs61yMUprPWgg6NLQOs8bTmYL4yCVjaQX3Y0QJh5QVyMuX9nd
y6k3Kn6vhwutPGK6vx3C3hJDqIQ+xoaEIjg30gGAvxjNuXy1tJfrluRjR0m2zIHt4CwM+mj9DYMz
DTGrloozhNIkI24KA7In8qViuXCApwpFkS8XS4WD4YRVUNId445UyncTtOZT2OM2mq38oAzLQqUo
0ESiWymQgzz1fDg3KB/81i1/KFYruX07owIZlThj3zZfvHqqBuNtUpfemmlMZk6FHte566BGtE7e
ch0h4A5TrWCnD9Dx3IpyXbVCZchWqAxXK5ZWYTzcFKBQgBYp27Bjtg5KqhrMAjvuArS5SpCEEk9D
Mme9merjjYYv2MWMnLl7fJ7Njm5gmQ6FfpcFxdU+Bq8IQDvrBTNetlHwlbq7qSqK+GQimmLEGVRj
MNCMtKyXjh6Ng3IUSlR7YbwRgqMNHWKIQxxpvEJtv/X2SPlv3YS5m13L0u4ZxhfsO7XRPZUnEwdh
CDij1bilccMQb4Ym9LJqurjBa4e/LcYztexO8Ciuu0BtWdADVDGcCbTuK+jJL3cdGY+T9oScPXbw
1y5KQgl/kUxUkPdoqSFK+iVA7s80m1A5RK623FynfkaARHEDYvid5K6TNEfqogRopcp57DTsDcx6
aIVsTd/yWT1MKN584IVR4PF7vPiYsFI+UHY2tIeADZb45ps4u3IgjVvs3Hi3Qn4kKuUPKp9OynQm
+QipfCB3szKbjg95w7F7IG0I5dkf74hKB2xwaB0I0slDeZfe9PKxBomQPJmLzyboULeSgBjGL7ve
4Dk3dIoUFBILyXDqYNxZa4bTeQaqGCa9aOlWjI9O5SOzReq9OxNbMkhRo8aAtVG/vUozop3Bh5tZ
kexZN6hcXAk59IqZERHYVWuDUBm06Pf60IFJDwNEerlqkD6fJVhsdkJc3GwL2tQi6QiHp+SDYRjN
xU28cNPlhdFSMrc1G5uYgmn+xWMuGIFQpOCCwAG6uwQiLKMP1fJSCPLcakLElyHkqpVdmI1RL0+I
Cs2C3eheg28dKAfHclF3Ocx78waKbEqGar/RNKOU+eLbv5OBkqJYMYjUKY9AzxaGERk/OUzg2VSn
Z9XyQVn2dE3Ix+5VfTeijsIuJzTUcfqhp4Z3Q1xKbv2Ie5wXAUmhJoiLQoM3ACOeAsoXXepYyCRe
nrFN0RMcl2OVyj4Ps5pGVm/7cU7Zznm9w44eYd4RsassKCE4RflygZR9DbaTAtt1gGnvOhpMO8+x
wCopsKoLrJYC23KBpZpQcTWhkmpCxdUE5TtGwlQl/eY5lDZsL7JDPXaaopO3i4bf1dSYwUIAAQO+
6hxTO3I8ZeSjs29YTbPzIaNSXZIPY7aytSQf6Kssoa8C9FWW0FfFeyyDPmPcluSxeReNU0Cg4/2H
0gnUabQ5SI0hWEnckPN1WLlm+6dV7gPt9+d8ALplg2bNMp+88h0dvU+vT0ftY2s1LONq2Ovd6YQK
JUTqabpjKdcF0mu4XdSgpe2qNnqilsiJih5VpBtGjyrSy5He14BCiM8vlD5YSEPAYjTYXQoBq5EY
lMsWjE0cPRxRyyg+JsGXI91tm9RDowXaE0vJ6IFu3cmXonprsqFqihf1binZIUW1lHG+5U2fatzO
Zr4ss80XRi8TxVd8D9JCXwm4EaEltdU+Koqr07bNNUhIdyiCpkSGXRwZkhp75CfPPt0lzdHFs3RP
jQ6TmlG0wHGc2MC82uBNDSsVRkSLkQ+fDUB6L00bCGIh3oTQLZhHRt6vYv8/aSY1k/xpuvhzdHou
E/FK7wG2iGrbp05SSBuZTaNo2B098l0st8e4Rec7N9P2fD+9X9j58JSo8OX5K7rf3PydOgcFtlSs
7sQejoeDMV3ysqUbwEOZsY3ZsSEgEGLSksvlJW7H+G41xeTD9lW7c9k6oRR8nZMYyG2Hct9K7iXK
B8b9dEIwM3YY5VzyutSUPwNXgiG2mBrIyYQqHM75Llw1i4TOJpKSjCmgwn2I5bGk3ucHf5ehTqYj
Pf+mr+Ir2omKWTib3woSCFSnD+SXGuWUt8S47WZLALXbSNHP3Fx0KZVVEKYDPmNkaX4xx51GvJW9
yc/nNnS/7hq819k4VFDAQvLWuFTcdT1P2xeg1KKvght/qA0bzNUs3k5bs7M03Vi6PpoAL9UXENWZ
ugi+mUlfFwsygliMAsH2JAnzErMV9QPSJsk/GvarOrkxTm3MtqGjHu2h03BcpN120zXnq9hjkV6m
Yh9FrvORzGM33tBEfAGfPGZT+yO+csmlMecLxokVbLPkmZntZEjvrkp6RfAh527z6XOucDDcdB1g
dUlVec4h1rIzqcTZoXHmZPuvtpmaUCdXOviJ14zy7ofYdWV87mOcM5USAKahWj3jmMscDHVWioyn
ZRvmG7TEAZc0Z9RTHk1KKLCDmYzQ3QVJuXfVUUmchpkDzjGu1LDSJvO++D0Ip/Tuva96QPk8qlo+
j/BY+g053e/5YV8fD6syemrFydM5a9J8i9cjdNtI9nMwLW0Cj8M+bfmNDuVZL917FaP37ImOjDho
5tXaJXl4ZzNrKzySMSfqqZNMUBGUrcDMBrG25cscW+HSLhuV8VhC8+KTKltHI8QwlYjSQ8n8FCtc
PJFrLYBVErUZDPrxQfxztIJ9fOyeNQjs5T1jICQW9/S6q3mZwGcsu9w0qdNYLsqVZsWlk1qEKgnq
OMlRSg916umxcmqP3dP20jPoJGsM1+vu6SF2hmpQZG8SlBf1SuwyMzWCB5GTWe2jpdQ9KdkxUPbE
8OqZp8cqtAJSkzw9JsJ0CKBoxhxLHh7Hfv9j7peryfbNZ1bbLc7Hh8Vj6XgfptyNuNnOw2S9C36V
ue9NS4N7d8u+zUtJ0VDTD2dbe9tuSQrAWMabML1dO/u3u70cvR11ZVuiX9rP1vEznfAqHTh9MqTe
QdCx8qvPf0r8ggPD5H1t4rwwmZ04LjxdflqYzE4cFiazE2eFyezEUWEyO3FSeLr0oPBV6ki9CZvp
u4AtNlVokMRBun5CwAWl1Sn2nbRc8ONT8hwr6XjiTvY9aFJ+C9sswlmW8c+0CFTsI/NYNJJH6arb
Ejfc+0JfVcuDS+jIcsKHMd5s24BVdqgb+9F/Gu3Oqmh3n4MWBGc1tJXys9BWVkVbfRba2qpot56F
dtUuqzyryyqrdlnlWV1WXbXLqmaXyclvxcN3/WrCPno/xxs+PtbPnmZdN572IpW61jx96lYzCZC6
1ExOl6k7zSRA8kpz6Wojz1pXP/jPWAr1sX5aB7OP9aUCBMDGQssgcrF1HvxnVxulcEeEqmyjWvXg
//Spc//Tp479T5889V92hONso3lWYz/NSbTy2txNJLElMHCEmope6W3L9jdv+AVTfPTcOm2q010z
RITrLMUwRZHHyuTYxB2qrFzcltH7aAtAkcqk5xaHlQqFLpNuVjK2CBT08jfE86FouHLZMNzBaPWM
tXo/LlmjkhVVkv28bBh+Xeyi1C/YAVBoizc0DSMQBaTWD9itlRlvi3YXWOIDRacssourDS6eOBf3
Dfg6wdfM81yEiYUj0XwjXA8fQIwzKEhijAGNnVFW4EoOYGwcryX6PJaI2L6AoqjhfFsw1KbrKDB9
ZLMPADIeYJcA01Cdnll2UvSeZ/6nCI2ixT2/B6antEURTZWBJr0Hno+6bKUZkQXntNdbhN9o/YrH
0c7BhvQoVtR7HzxEGOJBo3xGEUdMqJuRIun0khYROhBIHwi+ik8mnZnqVke+Q9sg1XnHOivXT9X4
BKi8ZZ4AlfkEqIzvhvht8dRz8NzsW/k2Jq4kZq0acsowjP03qaZXqnrbQFcNpBdIMyL1iN+Mdx2/
k2F5EQeZ1GVWrBZzVR8bXIVmdaoTgXUyZDiJ/8nphjrWtA7T4/MgUtWh5EYwmBXpqDaiKPTSCTP7
Ntfd55z9jNnRLemvTLcFe7hNUyuyDgZqOr/HN6BBGE4paAYSeqTDcWq36vqlnzFENpcKs7n8KQ99
ttlZRV0dVUv6sNOmMj5/X3FY4MB9YmQg+AstMVcaVc8ZNDHrVx8rjkF7tMGBtLtDA417e27s37O2
5NKGkN5gYpfQayrDBsVyr5+YJXmGcw/D1JytOzh7/I9oArA9wtlKB71sq37Q08VWHLvcGMGVrfSM
Ec3LOSqrBrjOjQnLnFDSPYcYNjZ+VOfho0daJ9gXSv8brVkIZ4Nkjmseiq2+dDNFopllIdtB8cnk
LoQmrsQVLlAU7PGb5kh0p/NbccfPD/EklT/2tI6jdjvGnmTl+Q77Al8489X/F5r8rIkrEQUkfhsX
hHx1Evs50o6CcVY6abXyMN8U2EGxfC1dgk6GRHZsjAfmOflRkRZXrUAMxLnm+47Hc+sEBoVymqyq
2JyGN7nE63v0o0xA+wwi3QPdDu/m3rffIpZ9VRrvB7MyyH/Ofk6loDOcfeWp2iiylyb2mEgt6KLQ
FTNnLeyniF47m7wkLMhKajA5IdStxnIZLJFstXpC029RZvUu3mDD0qZmpPdBb44PWIiTeShWoK01
yGMkKiURjaagidGlcb1GOPjKl166iTsujCOgtmPClusOuFiKDP9O5PsFmVVc8x/WYi5VK9v1nbg7
RdrlwibetyWFoShkwUQ6dZti9Pt3Vx2vE/qTaCTjO8CiBYtjIQZpxrdNXufssCjKBFErmUDHoLBy
boVyd6zcxgh4jH6XvBSyKoH3SiU5+OIejgvFyPl5fCEeYQcqEo654Pt9dOs5Hk8ne8Yaz/sTgr4n
Nb0/7IshziagfU80SrQ5N65N49dPalLChWxzwYH20i+8i1UsilGk5WttO3B6bzzbDP6em5VrxRks
7LiZV5f+b97kIbmgJgeBrQAcA/Jnygv0bYA6SezIZhsUMnTAE3vdoaBJjM0xy1Byjqze5T09puA/
q7I9gku0s14qciQzR9viOhPtKz0MuIUSwtnC7We2UCvpqdZx12uUe4YGm3w7b/o1Wt2nkeGVqymj
8PSn+CoZ6U55PCod/Fc+H3sDMp77i3+CKA8GA8Mpzs5B3vCKlPSwYzsYSrrWMZ8CjOh0JZfPl3/4
AfFdnp56V1ghYT9veD8fxhnnDcxh7z3CLEHpZsKxCUh0npFzHaOSM11Lo+W1fjaQtYjChCcU2SPd
4Zyv8ksb5bKCImWxx8s5ulrQ/uL4hCHtKggQEMNZ6Y6PW9GHj0wGtrAXEXxROZjwXcZsbpns4KVf
VV/6KbNlaw4A7WGT6lLlnGdOaiI7dkxjZkSqd8p+EfYHyb3/MIKkoI8nA92g58vQPY69Wp7jecS7
LCtmmbrL0Zc4pqIt3YLIQr404+jzo/hHWDKl67e8H4lhHyR/ONfDRA6Lgnp7Fwb3wz6seBPQ50M9
lvyb4Bu52sVzO7HigtqrJ/aaXAP01L7lmNrldtDaKUqruB1m2B09uWV3JpZrA7OflVepOPStmk7i
tSPuwgS1BeUx0rVC/hQ8eufDKCqKOrVqJ71MxiDbBNKzQdAKxTsczotiB7MrpVLWatyghykMu0uw
jkXZBCrT4l6xaTpExzPmwgxwtMRXbMJOHkiQR57WmACQVvuqTWIriEBCgVdVIAdgaImv1jJgdgim
RjA7GTA9gtkimJ4bBtAjDDG9lkFPjekhrtcy6KkxPcT6WgY9NaaHWF6z6bkCcfcupnPvCoYGDBfQ
h4jnWzZJKAKxRwwAIoZvlZ/q6hY5lgB44vtWJbO7NSAxf6tqAcon6t6JspUDOOqArYT8DCNyiI73
Ay05ewAo9cPWlgV64Xe8o+kkWowVQuqJrboF1YZt+0IpmhXqh61tN4+3qB8q1A9biUEUdBc3kEf8
39q18q4npDMDglYwgBlpgtG4qtwFfgIyWszQvQTAEufMAtwdXavAKWxV0YTXu8KtqneKJ7OoYxNo
bxko6NewT61yV/QtyLPpfRCCsAzvhqMARIdUcaBDleFuCawyHf9jMPEOAbJ3q+C4TwY2t4GCUeC1
58FMgVGn1DOGR72MLK9St9TLGTAVgqFuqVcyYKoEQ91Tr2bA0FCsUcfUM4ZifYtgqC/qWxkwdYKh
TqjXM2C2CYbYX88QtzqJW43YXbfFrdnwqhVzrNSI2fVdBxRNjQgIUMxrPwuKJ9Aac7ubQRVNNDXm
dsbEV+8TDHO7nwETIMwWczvIgBkQDHN74IbZpkl2i7i9nSFF2yRFW8Tt7Qwp2iYp2iJub2dI0TZJ
0RbxejtDirZJiraI09sZUrRNUrRFfN7OkKJtkqIt4vN2hhRtkxRtEZ+3M6Rom6SoTnzezlg8tncJ
hvi8vZsB4xMM89nPgOkSDPM5Q362SX7qzOcM+dkm+akznzPkZ5vkp858zpCfbZKfOvOZ5OfTPHFh
yjTiYFSjfvSUT64E+BfwzrVTj51zXV53rq473ull67zRya8Fo0G9RnVvjIbz+ShYK2iYRuvoXR6z
CvHNIm4wDQdoV++OW22KgyU49uVVxzu7bBzvYwJtB+IEuhpos1MdLoNAMUJxIOSHDZHP57d++CFf
LxcKr/nkhH4KmFXGbWmlJOO7yXr3xD/EH2KvRw+NhNgEZBkoZCmPDE8OxKb8TmdYgAaYgkfSefpe
WJUU3MaIf3CgmHVZFr/9ISsLErURayTN7LtWsJd0kwL8/kwKsHIuZtS+GSUxR89HzT9UgSytPpX5
Y8ipqs5wmqyUU17QIFXQRr0JKmZ5cyddg8x4cUW6vKwPncoG96NhN3Y5KT2zaWcsuEVkoWucNd9e
5GG2eCN2OHKQdOol8p4Hu3FE4flh6D9qod9kuE0rl7i9x2RZGUTWEqwB7Gg1TgNqScXuWpdVuUJ9
A4DJqC/OMuuLU9P1GciM+ggZnklHphBQwnM6P/ePWL4976hz2fLOmu2O58nxqvLWFW4ogoFSO61r
BG7HEP953TjOlwopdLATT2FTwtxP0t9/Lv16bJr1Hi9rRl82Ywndx0/RDfogrFccjID9thptSGW+
YDA6cLjqzqr2E2uMK+tGVvd0o2d2TrwqYFH9xZ/NdIJeJVi2SbQ/NYzUePx01HGE+RIBxx3OQI/x
RV338aVxo2wvoG35hJq8gUp/cWN/4t9gwTk7WLyCOYcPyue46eRz2NMwCA7bx1/KVehXd6Ff3YV+
dRf61V3o54xI5fDcmRXoezzW3jx19OPGL975yTls5U4aua1XGzO8+fDmvOvy7/zh6DcTBGiqfNin
0Me5GMTrTeaQuIBUvI6nwjDr7tsWJ1Eg7vxwiMeuPO8yCX0124yGk49oikLTuOBNrxfvkfEWiDxX
8WUQhhmSI0HHbyKeBHSWLzQxtI/77UNR7rH406SPfzlcAn6KN5m/fSCydXFEzoGpuJ5Jnz8gAfxp
ZmTPIJ8NXYYDaJ5413h/AlrW4RFj3EF6bgN/9tsWrJ/rsKRWaljfAtDhya4YTWGeQQDcnlqpBSpX
jPUs/umGH1cFxURPXl25i4jXKqo3fS24UbASskp5aNm3AD0cSP+xVyH6U6eoCCg2ZIwiV+fe7WLy
MWLruAjXkJ64mw77IJBYxotlLY/JBY6sjdiGbIZGYB/za1c6kpaBNx8V9v46WaPAnXgBnx9CA0r7
ppAPgfbyB/ENpcOXA1EpoGaWo0pI2g4c8BtW2geyclOklB6+K+2MHgBGfiqK7zDCA3qbzX/H14dR
Aegq0tWwhajorKvMkCx6RNObOKQHte4PeYrCvNMhD7zx2O6vdRktYDaYeLOiSOSN/QfOkXzWg2Ec
4aK9r1hfFH/bt7KLYsLdoUcNcG0ewjbYw9bmaSwSoXIsCcgPp4tJfzGTEJBYiHHMHEjY5mfm53Ul
BY1yxsJpoTTwvBZ5VfGGcBSX/awxbRgDXNphRkn0Y793C9PY6f3bTfzogeDJ8y+6kQ1s4jOhXztz
gB6JZhwF8zwJ/3ohlg2yaZJjLk7lBsGAK29Ks5N7HV1DBkYaoYZhRZ6j8SLNU+UEDqQD/RvQ7dTl
A9jUQPt/iBlUEN9/L0wG/4AlCmrkQAGEN5gIOUhXhwPfoSNd8iTUDQZTiz5JRy53BapAxzt8n18T
4hTZziNalWDoPRxhaqSNHvSQypHAGrXvJ0eavYZ9wAZHTwC9Ln9QIqLkwgJHGJo/KOMPxQgtUz8g
h7LYcDuUvn5XZgOVeIoNqnIcvaswwVjKnmYFTwjLWfCHCEaw/lOrL3GjN7yRLeAGptunIRytkvMQ
t2SV3syE4ZlVtyGjCX/IIZFZTclYhMy1So7DV/KhAe8G2NHFHexOcEPQZDut0XTKxmH0NHl4A0vD
HMdk4uWxXr3+hkSjDa6QK9YPIqGP2asYwuEE5M0pOkw+tbzgwUQWwAfmNIrxRPwoxhJnjgjgzkd6
hnF3w791Y4XJrvxvjHtdLzlCLAEWr8uCCvwhNYpEJElf9Bfj8aM+eOXxk1wM+8EYtmaeDB7nIYft
1VEtgHL5k9+Q4/xJEWAXUhZGHmwTqYYE0klinRV0nY8b84K8IOEfK1Q4N/NdMEIDW+2qSBkB3Uzm
c7+72YvbiZb30DCPbKCiBAUUPZ4rgr0sCJidvT5IUpgiGffn/QCnFTsdthohna3AJn46HvZBGRj2
8YhgLtaDMEyiwQCGkrk4DV4eX7J4N9rtk1YnX9JdTOvdq424RV7wkHfQvs5GX9HnaEBGJ1ktkxrQ
8rapDpVN3MNKpuPZCPYh38gbAf6RzQYJOxBl8c9/ijyTid9LuMRq6giiUNhPlYWeh6zjy/Pmsdc+
OTt1gCBhhJFGnJQyqVEIz7vz88zD30of7PhPujewyYtJpnhhtDQyTk31wmIsSyBjhGDSzJ43yIw7
3zG8PLRaH96QLhXlkZ5p2A/MCjGN9rBofBn3w5OV0eCJ54hZZbxsTkAUSs//2Q8newIKoF0gPWkZ
YidjdwX9Tbnv+NTT2sgfPX1cS0Bf4ry2VP2c57XifBrhlP0vPndtBfp8EedQPJ2TdqfRdBHK87ru
cOJz/FrUMdiNXqgOOAkNHV6iySwdguI5Bp834kkrDLG7YZ88dcsHO67TQz7oC3HvO+eTRNDTbeo4
GgqTRdfX0qs3nv7yBto+ciQs8MPHi0VWNEaAkI6Sdc06lERMFjopG/nDsYwVISppUtAFaswWRQq0
tb/oBV+KGnkqpFDZZ9h8ICymaJkLo24ehEN/FMXs17EezIZo4RKdd822+6D08Fc6Z+OTRTqQpFO/
5uE1XuSJ/+//o4PUP/0Js/gM8uJX89hUnpga56HG4WnRcXpaxPrMw9blR6lE0lMHqUwYtOy42aZD
z5PjTZFxkCpbSkeoRkP16SmfZ8oT1ONm6wTPP5sX8acj4BuQd1YU7auToyZ+OPnlBNrSaP1alHjb
J/95DUCQyVOHPIHNP8EZ6JWj6xadAyMr2teH7U6zc905EW8vL4/bhAsqgIn8ffPopL0vzi7bxLRr
PJE9bnQaRACgAY5BNnw+vG43iXew3Thpta6v8ESWTczfXf4MzAF6G1D8mBh9eUHNBj5dtuio3H1K
HB8Mt4GDR53kgTIe7+KJcdxecXHy9qz59uTi6MQ6Ry7oc+QmV/1z41duJp8l61PiU1uGi9Svonkq
Gsfvm0i+BAZxaDel6FyeEqr29dE72QV21KlnHCSPht2MHNTNpqOseFQ6VBWFWORjPjYE5pdfg34Q
QYo/4k/mmTLlzyAHJoHwcR/1xqvGmYcyIiiJXlnqU3ETa0SvaSOKCaUT0PY/r7H75WJ8YuxXzC9V
80sNNT/WquLELROibn7ZNr/sSI1XeRFVlBD1eaQAK8b6oBrCisgQh7+j1RQH08zmDWBJxYSXtuzF
jXIThBeGrGxGm5iK1C/wBG2jaiYzMOqdvJVOZpSzMipGBjGV6/vDuHhI7BDp5gzk5vikfcQPNq4u
YS7AQxh66MQ3gRQfQz47oe5hB0TS/awMyQR0xBY+6vaB95qaDRRvVvKGGPAYzYOxfNG6DinwSXOQ
elYdN0e/1bFx/yATWbTERvt/9bdcF3+ok1e8U1if6TNZPomIz1PQfTOurNBofiKpDsJt+YOqlOww
Bjq8C8a98UydOmqZKuSZ8I0fqUmgI/sYeLdQJM62m28vGp1rnJRqynomPhQ/RHciqgQdeEAZ0Sa2
8PNURZ/sUn3+QncOqr0FIWnAs4vUuT6ehpgkUgth67CgY5HXr+X5hQz7kl+fyYQeun11SMcePcPB
V1HcmJzRo/Hc4/WlCQJQst6fMRtzuT5R/lSJ9cKMD1LseU4c8AkevYm7evdr2+tceq3Wdr4/o6YF
BIoPnuWxnnmQBvOjuIIsfDwen53ZFchiesrdRIl+utbIrjUufoOtXV7uZuagtZ2ktSjeXlmEy6NM
m9KiMKsuGCw0JTsfCwHJzvfmCgMFKD51fFzbD8g1zZ4rb4aHajw+12cfjCuXT9zeoQuEFTZ4DPYl
4vPumjs88QlbPLdFjh2Xl0675e0ttWmBTghwCMs2f7W/+Wp/89X+5qv9zf9K+5v54yzI2jnxDP7c
XdXDmE4/nzLr4SvF+JoAfcfHR5E4qwzuN9umlQyderKXN76GDkI2sNjXZ6JkI+Pd+6OPhulF8kj1
D2PPxejW5Y1LD77MA48T8zirinV2cELY8+uK2gKhh+VZ5qyTTb+1u5CYhcTGGpb8YihZEqzgSbbl
5QW5lV1ALVrdk2sf/3SuLD14QbOL8v24ipkqH2DyZYWsGDQbgoH6uXUFPqnmI+p2p3H0E9lneHSg
ftmC0UHV6uLIDbxI8/kS0r7q/z6v4ciJn3nhb+fYSCn2SkSqZ6y32xQXQHeOyUPzknoaRfdpHGjd
nC5IbqBOSZE+vb44yttC5iB2NsCNYelhp+JAVrORaZlxgNbVRoHIRSEy9oex5JDEmqNA+VKSLmeT
wrSvoWmHRluHDNiiSJe1biFlac6OEqXRJcNdEgXFYVFWT6TeBnMvLFeNjpko05oEbYxO5aobxZO7
IHyExZGuvvjRSkR+GsmMY4gBc+W4ine14WLiYY4azIYl1ps3/anXXUSP3mg6neWNDWaKTgODvIiy
+Z7MVzvH76K9VB8V5GVpgKY6Xb//De1wPA/lw/M+x73LfDgOntbLGeoLqOWVnc+ml/+YVsojWh0S
ujm2xXAs8d9pKf/1xubrjc3XG5uvNzZfb2ysG5vn3tYsv5OhtcudFQyGWTl3MLIjue1QqgogwlVE
TCMPP+/r24r4Emfe8/zRfJ9cp8IXDKlHETcXM1DUAsv82y4097rTqV0QEzILDMLg74tg0nt0UKHj
xy2FGs7H3p08DTfO5oeRN0Ir+MfAD8kABT8ozWyQp6/iO1Fj2x19/m1kgSoQZ8oDZbOkzlaWYGU+
pSQLSsM4TJ5ImkB/xJquNh8zaKcT8Jh8NqAJZtPeLZtqmU1h+255jSMvWWAxyQs8Y6cygg/aiWw6
VgeKsR02hwrUDsTy+rV9UQNJDhpvQGHs+4+atUzZmA+85qKPr38VgRqJ1HnzAKY5Tof5pT2zCSI+
zKXcspFbLats3NhCTrUsbVMJtGKAbu2aoBUEfV3ZMaGrBvRuyYSGnK3d1zbumgFdrpT2Y2jI2S29
rpZM6C0TeqtsQEMOFE8gr5vgOyY45ED5BPZtA7xSrhjgkAPlE9h3TPBa1QCHHCifAN81wbdNcMiB
8gliyqW9uH9KNQMccqB8Anu5bIBXLfDyHpSPsasT/lgg/pDD1xJeGg9ofwdyJX4UlZQoU2WvD1Aq
cf+cKd/qLnI6gW0X6NJvYas6BQ1ogn4eOC5RgFpWBCr5BDQ03AdslMobxt6Adb1GFIFShQoeuvob
4nlmOPZHjAZ1PX8O42QTZtLy7k5po1zZABZVqntbu/A/YTj4kYbVAebjSfDkAB2dQQMO0DMU6Mzh
ATrWgon+AB3CAF3wN1bEYO26gNVuT5oyq5MmOiDBoMQDUAtxcq6US/WNUmWjtC1K9b3Kzl65LqZ8
xCofOkTiHq3f2foyEtXKRnc4/0bk303v0dEdKOoRLSk4FUeCLfFAv2f9kurzR7hJfKQ3YTCnd0fB
OMIrI1YyZyO/h6e4QEupuoPcLO+KUnWvXNsr7RTkOqomfcvSzxt/xIqTdqbxjOTIwAmKZmmHca2c
t5zlkOFU0Hxm5cI/nDjLQ/+oRzpWG6yJO5bVAyxgyy5gBobWS3Yq0gXJ1XopkaHmZ+YEDgx8l8Tz
Mox6dHhlFyBIBAKZRpBqeQuxJqBSSxOCF3lFMvA+uYCM8FGjWsNfbUwiD3erXu+xN0J7VbW483fb
ICPPiVBbXj/XL4k3tjpRSFpiuKqcT1MVTpKVTagiCzfUFVdcKCQmj8PRVAZF6k/HuKkEhg1H/Ds/
8SdTOYUUcLjgUOQZozkQXSqJFg7+aAQCgk4sccOmHdar55ijIRSj4KawwX8IJsq5JR//EBqPK8+z
iufNuX6HEcgsNgKRH5XBAncAHkndc4/28PTT4hrhRHgMtHHACFHwgF15PHLsgTxdXP6cOGcCjS0P
BQqsJbYCHXNyPuZ5X73EQMMh2E91vDO6suAuoakCZ55HEUh3kLFL/yIXjK/c5nLHqzgYP9GQrVVk
I8+JGSwvebtu9kldlDbZaHMhi2/OYnMZfJRYMI0o8Cgsow2wpJDDYGVFETOC4pbwapEgHvfjvVv5
1iiD47E27OC3PSJYWlRg8IAExTwrtPR0KG9IgkxJEaCYo/J/UDsJYguX+C8M4SGTiWACxZKoOMdw
CocG3pcV+zQ/GuUYPjGFyAbn5CZnc37nTWDk4RwmiyGhydwfzZGtnkHpBVM98zJKQSFWMlIVbRwY
uAwDBDlKqW893bf54A76duLh7SVufab4UlmO0xn5k47IgXR05bh2iWcvPVTtXl02RleRGDm1wSoy
nU8nw57XwzkmX9jT8vwteQ+OZzeYTCJ8/MJ6Es1BZGOlFvR4Hk4idUkgTHl0PQBp9DHdjg1r+2nA
JcSCks2HFQq1ejjxagOQIr3TAS6fxp4ZmCTW53eK//PfJZUuXs/vNn5k6QASbHHBoABv1rUiSRIl
wRcMf9E+OUKLnGv4m5TQAllUjoe9cGpicL1J2jd6Dq3LOFAfrTFqKcPrc1pELFs5DNgu26SOluOi
WmI3bdUsOZsYVZhdmmF/GMVLz5OL02pz92nr5D+9VqPTvGzbk3dkl40tO9uq1GEDT7lK6f8Lscmd
xGJZS8pHQI6VgV7zCGlglzrUkGZcJsrY0nLdXmrijB9/BF2cfZrn3mQBfS/y+fIZPhMCWFTuCvKJ
oKXPPL/+yir1V7LrT9s9pgRTG0DatnIgXHRWbsM/iu9GffHud22AJseDs00OrKpTRIjH4IjsDfwr
ikPovETSmokfyjY7RzZIkoYl3bcCXJqDTxUqr4i8/BLklRWRZ/a9qR8x86w+ZNNHS5OntVO+S3bI
bmKVdQ8wofK44kyhEwN/OKIgR+Ialq6bPWF0qGytgzq5fGCMCeWw5d1fRDl234LfgECyT8UPsmaY
rD5yTBaYzI0QNGiX2Wmen7S89yfoeE6UHoJBrDvQy7dMdU1pU4Oh0v3nY0pIaRiJF9HAmKa6Y1a6
sxqE7oldTYisQuCFvt05r6Hhb6Dz38Bf845YKK1jz+hzSpAY7SVT9V9SxdLk44yM7UV9gPjy/Xxc
0BOuqvPktLnRgVyotL9J/0Nvftffo/+JiPl489h/NDsbUs6nk/kt5f1Ke2n48A5PAyhvOCErPPjY
puW4kNQFmU51VGEiYbw8geZkzc9ELrkAABda9YqHi9l6izsFKeayc7FjWBq66KLvbhj+Pf++2fpP
D0ZnUSQU1aK4uD47i7dBVPBAbJQT7MYoo7x/IWmIYCt5S7edfVm5+G5IPEcMDkNypdHgO9boo8fC
m9fAxkYgvQOJNUG5UZC7h2dpwHf51DDM2MbqxHD0u9fPW09VX22Qy8vkYLVtsj7N9OEhwOfKK3gJ
1IBfwACiupt2FXikDT3zRwXAX6qLd9MRTC7icISO4/2wL364pZTunxfR5rA7JgOIomgenkPpEHqb
bqX5ajkcoo2neAtTE8Zw/2HOCZs3nPDnLhC7OQnmsa9BiiwC68FN6I/xXIVshpX17754nC5A0cUj
qtigFqMxyTtwtr4lREM8P+kH7PUBBsJYW5e+vbgWMpaBuCJTXHHG5rh4LiotdgN0J6T1aLTIiA1s
yYsGtXJfBEM6EVUuJyqqkjNl4CuNe/P+HIkPxZQMRApk+YyTsy5rGrsmmBC3VXv0up3OAjasGM61
DR1sRgaLUZFwALQ2ieXLUzaL3dcmzXjRyNFxxrPREA0F0MvrZP4IbeC3xInrdmDwU7ftmwKENNC2
CktYTRbpUzobm8PkEhnN/xU6OQISQWI4Zl/QC4Z3GDqGrCqe7kdpbjyV9tvSUpn5uS9gDoTta1Hc
h0O+IEj1MN/z614G4Z70NtGLu+gEZNZzhQfgRdFeIIYqBoo4nEZzhDxvCFGqlMvljXK1tC2u2w19
rfzGkHAyY4G/49RzbXIH/hAoY/YHGF0ezgubPdrt6QmB+XV0609uQPF+wUOC5/u4g9VkMn22gW0c
eSgBAE3R81s6h14N8GuulGc9WKiOLs/PvfPmBQexbIuqviuXKIlp1gZWZdBDSE89UYnf23Fcot/S
yD/orbkiAFB5N7hCehzlMX+LDptAeca/m7OCcXWvamXAfWVLLGPnBeTZYYFbeRniFo38leMomQaD
yj5/UTjv2KPg1CPXgvGJOKXri3ORV3HETn7ptPKciQrAViFewgVG5fJAheh4FXpfJOFiZS0DybaJ
xANKrIIOhytNPtVXs54Qnamcu/r8jhANFwAChDmawTCTfsVG/K0gmWE/1rSZjEuJSpE20nyVIM2g
u4vBIAiddzvESHVgAR9B98hgdsJJn8RpnFLlM2gr5BnzP7UYNy/Omhcn3ulZ461WRJSkgRTn/WK3
gE6P/YL4QeS7oCX/u8Ave/TFvOKP2y298US9JBkk/ev4W52KMelJxyLkTC/j/quHnkH6SsUnewZb
sc8zTpQPUj3Jlxm75/tRlDis2+H1W7UZebMukfIjUCX+bDFOgkFHbog5gfgV3ThHvY0fJyH5R4li
Qu5vhxiRM6/p/UE2iqhB+wq7pNp9JDyvSDFw9jdoogr7frqoEiZ2dChDrKqv7JXxd7m95kyohqv7
LvY9SJfsUnbwbddQM0ZezzMeQbeNeV0MNu+MsyjdIm5oSvWWfrmA62Gck5cnBI2XAddnykuVeWvS
wwUbQxvO47mNG2M8MpQ7BGVGXBRGLWrgbJw0L943ziiNQ1rLLlYz9PD16w/kyUqxV/cw3nZqvkrD
A+EQAGvbo4mXz5g1+Xg+BboG/qFyiUOFuBGqAslrc2sErbm4bF8dSXpY2GFp/giFxuq9m44tOZzA
pgafbvwNzUrprYQ/COZ4//smlmiH6GYyKZ5jgKXNYz5mR7ixfzPsGQDnjbfNI2P6Sho58VwRTzD8
EgMX2eQMg2liHV1/SS9Vk25InsCcs0nXj+hthnX1jgKux0vccI1J/BifzppvTGBnQE7dhBwccYnC
xoYUe6wwPZ7zhPa1QSyfPmlCcKuNJa2hyRjf0FUwmf4ikv4UehJ9FeGBPzsgxKeAZF4916TRNGkO
17iqAjbPflhj8lZGxZT99D3W+ZsmW72bRaIupqxhmyyRpXDytG5QEuvls/o15cuWf55cXTLKZayb
60B6IVuhW1cKHVmv9fZTgqZvIgg8nvYMQea2WRKA3fQNligkxvT5yXk8mIzFJ60+Sk3IrDNenXkh
VkyKpw+at6xKqU3Ug9HKWgkRrtEFkZ6/rcao6RYSkcnGcy+7D9YL2udElh2kFiSQXuKpZ+jx3nTm
lqmHnre6WBk/1pzRG/eVRjOdJbyWkQnM0/iyJE/2v0P0FAhClFPTmB/e4DA+KFly+WpDu0cAmnkW
IyO7txcd2GtfXpGXQeZbGAzorbzEJJLzAnsptAvwzKXN72zU7GPuWcgTRZaih9lrEQcMZ2tRG5sB
IdbpC163KpcOKVIYRKksKMbUl2i4UbbmQVNrsMaaMaMZi7fIa6Ez5M2wFUt55khv+oi0jR/J/Z6H
LzoKNgqZPwmlhz4rc123cAW8CcTfk7jFupmcKKyZAvgezL2ncSvnD7rNwmy0UZFlz2n3en8xNjr9
KXmKoZeK0lzGtFwFpYJdihDPjlZBhnAJRKbbClNtBFVzMr2fkGsF9nMgWLKnMyHvJ2ItEQf7vrnz
kQphlrQ6JFTgzMYDYF3NLkWhZvl4ZiYJcJjSWUs9vZek0xm6jE9M1Km59cnZc/kkupim3eZn/aTn
btvCL6a6isbsRWHTXuS1YKGZZXrZjNtPy9Pq7Y/Xlk9uRqyiLFlO1JqhdV7pMdm1gkpJ+a3yIa1s
ZK3EWrq+tyZAZWeLLdYMLPKUs0wzUV9Wky5Cz7qP3UOWaYprdcOQa8tWP5I04361WvFgJzXyb6T2
Rx+BOwAF02Ccjs3ivO9xyjhvXHm3U5g3Abnhcz0B4c9mI/n60QDUU4QbigKOw/ZABxIWj8F8L2Gk
wBWVHr5jz0L0VW6T9fQRe0BPkIVveGFvGXmzeZBBkwniJIirTFC1Aj3y2t9BVT+4G/YCg08JkuJ8
N0GuyrnuN29++eUXKgFwm8Lv4YkqeSTDGySAVgjxLGnzlW2bYM7G8STx7tcrfEnXvmytOjEs3Fqn
cQwLwKiAu9W85OGT8jiWS7nfSjnbymWOE7PzxLJRs14A8vFe1ejI9JhePmNmTbq0P077x8AGZkwW
0SJCF/lZJ6iw8CHyZD+pUgmv1KEy408sUOQuxItuF/M+LuGAdJ9DwfEPfN+EORE9E0mnBziTFNrv
rjvHlz9fqNqsMsunQEWf+2j6e2yVvVAZbaNHgV4PODAJRsjshPBh4RXXlklw35BtzfHntPohaZKM
5uUkbkmFF90kTXLZZZx6qVgAqo/B6DGPSA74OOzXtjprlTRKOxcQQb0TmM42abwgUpJJ9Jg3e8x/
DxkLfGp+o511YIo0UktQWnZT6qGvcHzOA8jU0F+iOiV1JlSq5fVF3A9LZDVDd5FsNLBJDkq2P03E
ICBff88g4jPKxMrNiQXCKdpObialWj5C1PtlVu1/Obl4f9JSpffMPVBmhxF6Niu1kKB1ieRntByT
4rrZVwnPdmpPql6OOhsu3w57w2nc7viwQrDHG+iwJ7uuPQ9118HnzK5DXM6uk1p0TJDsOUkJo83s
QJ5I9aiKG5NwMv/kSEggcoyGrKqXCM4XF3hFw2rSjgW76PXpv5dog4zV6J7O9PDIr06u5xv04pen
CHaRLCdxgwKi1lsqGHJZt7U1Xs9tqhNqQOLrAc82sSbAH3BUy20DLbeQ4ZLK9tG7k2M8FZPoYMGx
8RvX6/byqNeyJeMsjV22z30U8BKLNRUExW2mpnJXsU3rZhbuLAIuXManx9XtvdKuWRht1SrVIuS+
hj/baKwm1OX4RctrnaDHi5NjcimLbkJ2XolXeGUKeW/R4Mk7bTXOIZ0ctXQDMSIjC5BRNGcK/o6m
F2QC5OPEOxkMbxYhW1n9EkxIXZXhBj2Kl+h58dV8sga0HSYbTpEFUdNB+9Igiv58stB6fOEk3iiV
h1Vv6Xe1UMA2S03ByhHr6oAMlfT9F8mAtMqx7Hjc8uCCfJFsOBGtICfbIB+vt4t1EhLbmrFH1oyV
ovhJNMQpVBaEbpCtongb/o5vyH8X58PRNCKwa3KiEe2JRujfDSf9W3G1gN3loz/zQ3/cHY7ED77M
2ZzZOX9eTIbRo+EnSuN6ppMpug9GIXxFd3nQ5SCaE5JNY5Z457F5525xR7wu70hmxLZVelrdeNip
e9UKGlcJkFuYg2TQ0LznYRYKeyG7ZL3GRluJkjxICqY1V1yOIo7K+mic0HtKsXY9iXf6qGYN50EP
5/k1BKHx8imCS4a0pL2RE9foKfFNw3+JuC+V2PaW5hjuSK/ROnrnkd+fNnSlMds4sjhMF6ylZLdQ
rv8kDUPQRpVOOnj+0gjisEO5co1iGOoiLkCYcHL58g8/5M2ShYJpneR5TieMsBWuuIHsA9K8URW9
DceXJxk4CwXz2FVNpDjTpziDrfk8AoOWiasKC8J+AUGppeMDpYy0t8XGS4O7f2bfcl89QH/1AP3V
A/RXD9CfxwN0Ylk8P3cuiSrZ0DnWOBrOmpnEz45nC0qOkVydXrC980Mhl8cwmWRLcxPA94IBhREX
AJShjBCaFhSkoTk3AlHQvwc7Dw1bOW/GeXEuxfcDkDGhzKmvXIMNBjuWGFKuozpusxFIBCjDd5/G
0m3ZFceRBgewnS4IOw4kphXR+UyJfsfBD/ktWZG8Zpgvoky8vwfhNI/uQJNYuehEPc72sxArZDLg
JuGTkeCBUjOkY4kbldQFWCQ+nx4gXYuvqgpI8C+gDeyWlmkDPflk6yXeaxswN8v1DBZC2HbRTZl+
lRXQ0irUtWHCsW0caKIf9EY+PwGLvpQD269Kxlcl46uS8VXJ+CJKBp2qOvUMI8fUK/C53FoqRsN+
jn3GXOLW3JgUZaUWLLkKctjGwzd8E80+ty78Dkj7AO25o9lwhB7E2aLbLhLNUpbPudCRNgvTaV1X
4dkgcmAEwtKpI2nd6miEHzfCH+CjV9WGTVcjwpqjyi1HWt2Rtu0iolt2NLfiSKs60hzUdLfkyT2F
VpxBB3rz3IAQ2knVdFItnbSVTuKIEYm0bUfajiNtN51WKTnSyo40RyMqjlZUHM2oONpRcbSj4mhH
xdGOiqMdVUc7qtgOvpDBADE4mtMDzPzs8buSODD1S8NG7KdtLBNgeK/c40CJpjcBoAKWahwIJrhY
l6CgfIzza2G5umZe48nMfe27JKX46jnqM+q+M2jYtPfxGeqvLvEFNOB6+TPFy35SsfXxySm3BHpp
MRh81We/6rNf9dmv+uz/En2WF4Sr5sXZ5dFPeC8YK7TpLFOj9efT8bCXOCfTRTwqc01Fobv/IUrC
erFuwmDwiFzJmYc5uTIvY/YCyrbfXujf00rikYtJNRN783Ux6n1MGniH/LIaxus/pGG6djQ4nj30
bm88v/d3r1rJf5+H0hs/RoirEBu8J4kuJkiVHs3kO1RCf+AAcTy5SLZmMUm0R6zH7YFVHwqgE0es
Zi2a1zbDYLQJE7X47TuK4RyW/jr563xN7O2JtXDNbo707Ac/kDkOxtPwcU0scaqMnDNJm4ePz+D1
qjxOsMnJWeUyYTljDW0nKcCfR92JVrzui77MVV955zOqNmouEN/oy/lGG49FC+Y8QCnG6M1RZOa8
hxHzvAKK0l+hezZvRtOuP8px8r5Opph9Odip6BT05JcA42979BW/27Udm3VJJNDNM4nE7vZUUz5P
t8vpbpWel6BfoPO3SmlvXE+4CpJxwpTXf6MhL/cM9MUuhu1j6vLu7g4I9+JGtPxuJN2FLT2C/hqw
7GvAsq8By74GLPsasMwVsEyq/OeNo3foSqrRuTxvHtk6vyNPLzTv/XA4XUQqaiV8m9/C9DakYGCs
SaLu27vFhYiXGXUiMMOpetIL1LmDGfkCJoj2+RX5sNnM0Ek8vM09Pzz7lYwGl4d8Ngg2Y6xGorsY
jmB2WvAMxcqoqtBy0Ht0fvXL0bu3+eh3DL8zLgqyfp/d+SMyKae/6GaEFRHPQ33c82KNXOsoubXx
9A74tNnr3R18V9nfJ608zpVErIlvo9/F2ib+DcZiTXxXOviuVvyuWuSiXIqKgMp+EK6RCgw689rB
GD6vz7QKliN9H98QIrUIgd+YZvymwRWw1P8LFtva0zFO9GgxyItkzLC4g+RGwfOMrcIO7hRSuv5O
XrNGAq0jR+VnzVn1XVIbbyd29G4CEqwOKsPa3Pt7Zv8k9gzJPY5FernupL1ct4lHME09frHIp4QU
/ZTqbkDl8zWAt2mujZbVAATTDaCNmtkASkg1wNjPJRtQ+6INgF3tv6ABUMtnaQB7XUz1QL1mNwDB
dAM4FI/RAOXo224ApbobsPP5esDRAOyBL9+Al/SAPnHihaoNq++Jd3bZOM7jUoBqfR+de+NLiALP
jq4mf/stwX37rTeXcyg1f9SnrpO5dvONIsAFnkv/IU9UaF5NAIm7/XhBiKHSy8baqL9G9MJSALXT
KlBeUwWFUHP/XTzdc2pyEZCpcmrX227FxTtOosQ/TJLij6uxipd4D4MbfWXXS9iFkvp/i1vSMN/F
NDwC1eDsdn1O888KYlVMpom7QpJzDp5Ec80TqMjJE3fz3ZxK8OQTmi9FJZpPw+ArDzQPnhov/zNZ
gKtVepXCe9qigMVvrYzqdxoguqVQYeU6gFTcIPTitQpK5FrNDYBWKEVRByVnbYeV/G8XtAdMgZpL
Ki3PDEF7IF5Q8aRVL6tT4oUx67i6E8vlkv357beICDrHuWJgEbE+4zoF8tbsP6qQcqYYsAf1CSMD
r3UsccNgAgeAbd9IS23wlPJEGLHEdCbupOpBRaz7nG8OEMaY4+TEx6pJXPkfFskv5pFz6P/reaT0
s8/MI5Q5U9bKehNYJLd4xdxOMffPgg1UibdaRQaCEZKCqsXbAQkFwyQFtROrrBIKhgpBLSGsN8I4
L0ja9/+1jDYJh9SlAC3yJCASmAK0KJSASCMBLiHS7/eJxNfLKCQgpC8JZZFHUEhcEsqijaCQstfL
CYsW3Xno97hvN5b2rYZEEpOgdgdrUKQzCWr3sgZFYjfMOdEoY6fJoWBOkWpxCubeDkiz8ZVOPOK7
K5lDXWeCcoINrLACL01Q/OrGqhqD0MkkWcJJcrmeprlczyDaBI6pNsBNsk1gRbcDs6YS4V2UYxkn
6dVKmvRqJYN0Ezgm3QA3STeBFekOzJpMhHeRjmWcpNdradLrtQzSTeCYdAPcJN0EVqQ7MGsyEd5F
OpZxko7Kik18WmqZSoa0pd5Js42SRD5dtSLOwhpLvZNWbIgNnxqVIsVYB9nZYzNVID1CUy3QZTLG
qaMhuPinGoKJWQ1JFYiT3Q1JFVCJSxqiy7gysiYc0mWtdjjmD6bWBlVTkJN8G5Snn2zCEzTEM1Cm
FKWpzpj5YoFxUb9kukwXcUyaTlniUllTZ4Y0pRuEqZkNSheJ0zMalC6iUpc1KC7lyslcC2BRtycl
x8zOFBNkYmlw0m+h5FUhm2wTq7EsZMqTBZ9eu9LSlCZ7yfqVLOBYw5yS5GxFVkEpMsmW8EH9EjFK
tySjiBKXZEsywC1BcbZEFXS2hV5pWC1xrLBML4Mm1mgn+TZSXp+zCbfwGit0phTZBdJ6RFqMHKQv
USZSJRwahVOQqFCWWpEhSKnG8IXDEklyNCajjBKbVGMy4C2RcTZGFdQ3pQ0CIC+y5G4rZFOZO3+0
wCceU3QS5c9he83WKny/QTfew4G2fJnfT7kE+2Qhb1OwZSH/Pwa66UDj4fsRNOKhGO2EBZ8/S6ya
Fo7HWRST6YSyyZbmfhjpe/bkaQQ5SFO8Hc/iSerT7uDk4bDrcjJ160Phwjgp667KQeXnuCl0USnx
rkLl/y2R+NRLwSyRALyfUSS+BJUS7ypUJicxJszYOFpjLAve2K1ZHZDeOXKutdaqKrOA7elUVZhF
SkopWYX+1PpvDtllNbloy1rsYpyuUvHEvaJ4z+ZhLDnsybIfzZUPzuBhpj5GYcJvtBQZd2vyhjhS
glgv9O3oGiLPOQWqRH3Bap4p+5+5CYq1n6UJblkEih29DamuVqtIY7KAvlV1NHtmj2YVvyRZMqt1
s0zO86sNpSXoiyoXCYrZd+oNR7JQZu0xB+9Sxg/GkaV31WnlLxrnJ+o+KvNyzbxnwALffptBMc6J
kEPXaOYdw19j+jWGJeTf8SXBH0bpzOuQZURm9e7zCF3a00Ts56A1WwyeQ+sTciFpTZy3kyBEFAUt
mUrqsiMdlGJHqlJ7M87IEWa5LZdsDj5ZBv1G7budSlrSWEtGbVcvtVBFolsq867pm+Qah2syLcil
gmk2tERtiK2eXLRmaA9Js6YX0Mr6w3JaEyucRRkup27uLi9n7moSTVUWoGz92R3OxXQWSBc9tsmn
NflhawCYvFRPFuOiSEi8EWNYdy7Ay7tE0Jyw8SmJkOzDoF9pcQHhp2CY4rXIQ5XovmqLeIhEHwhy
D0kZ34sqR6XqT1/JKGP6uhO/QO2C7irFP5Emo8PyGVsVRXRBX3K6BcvzJHuYu89l0NiPPn4RDiFi
KPFf+QSTCqYAZ/DoeyLLkupP5xLpLnOMPGbxCH3Mz1fhFA82dOyQUF4w43sMh5xAlWRR4TfFoA/4
22aJua8jImG8eFLixYZoB3Ph01DB7ZvaK8wjYhft0KgkoNwTh0N6GA6F+WUQVL0nGnE0bw7XhQ+2
7H2YqeOlSFhBqHSUqazBpwAcHBrvm2FLxs8SNVUqa0yqfBY6kfiRIjjeT2elB63KWSqWY7dYJqQm
z4IOeAmolCUDeliDFBzh5y8tB+i7XgmCgwyHINhhFbimTxUJwGKJhP8JIuGcg1aSCn+pVHz/HKnw
nyMV/5USC/erU/OxinrNEoM5nth8lvepUPtKj1MJ7gu8TK3u1t0vU/EtkKDbHREtxmN8YjgdWB4A
adgQ++SbQXq3ihwJ0JENoYJccQsaSxBKRySAozmZB6PoT+LktOl1ptPRx+HcK2+WS5vl2ma9wp4Q
KC48ukTHQzBkyBjdlOD7pfil4ZBDMwKrNv+nP4plT87lDfhVKzIDIDucTZmVm8bTR3ypd9o8apDv
CIdTD/YncXFpPkb8+V2j077EJ3JFfq+oH7PxQ7XY+UfKVUfCAUfRfMGoX1Gm3zHSyzkbuXoop9/J
yYdxAMV+cFqXUFK/RtRtxGeCjfOrs5NNcfLQC2YcGt1n7zIgBbGfFekghuf0KWVITzjSVaX0eIOe
9PGh2gRkBp8Rowd1PDoV2sNM8DCjmVt6mUHBGnKEdwGT9HQ2g/5Rj1jxlFX75UG8o1FAMejwTSvo
2vNH9a5ZOpmRvn3I1c9wgs87qb/V+9mInL6Mhn53OBrOH03HOjoR28CUTQYh5JDU49gh30BQbQhC
jUOSayZTP2g8oAA6E8NkOlCYpuFYj5w03zYVnSrC+b0fUtBTYAQ+KcaXgDyo6QV1tMAHg1ZV+agg
7ofQOCytKGdAphN4cRzQ+hZG9FaZF9gpvjEZPYqpej9Nbw6xXrRYgK1sEA4jWE0jxQEVyklQT7OT
Lf16G8b6R+D+mnplvoZQa7QPxol+c022U+aj6zD4RFIzWCBa6RdJzWs0zbEDn1v/LkA5gqIzqG4o
O+se+BFNgzuc5JDo6WQAkjaPxWvCQV0Yfki3A8MIe4tmTK4V24rTl/RDNN6Mp2L1wJrm5AnL9jjo
o7cn0Q/9wVxWO2YpQaeEdDERGb6NCBtXof038RtwvHzACTrC2X4BSyb2R5+6SfBDcmhJ18cJecpy
wwySRDGdxNIidR9zdzS9mbKHpubcnwxBW6ArlRBqwg6KWKrYTRo+ytcZ6qlpapKkzp5Tm6IhND5E
Rsp3qtcTmirac4y9QbXS0OVGo2qGwEzpJT1MR0NdBuyCjPdBGv1H9M/EL9zRnZZ8/ypHOBBEGCPH
u1xcx6zHuCrh6QevqgiUgIn0Iu8XkhoS/0CGBeydtFqXrQxw2D0NVVhrgPhB+lG2EbSvj45wmnf9
lGxQtDPnCtOgkA85+XKCPIrW3Tz2YOFonJ90TlrpIpVEkeuL9vXV1WULX5hn1FJNFDkEug6vT09P
WunwE7JILVmEwTuXl177HB/ap4tsJYpcXHa81knj+FcHp2SReqLI8Qm+enfzTBbZThT5udXsnHiw
RnZOjpIskEV2EkVgffUuTzFI0uV1CzrTUWQ3UeT95dn1+Yl3dEnv6+1qVFeW3GVOr21uWWWS/X9x
6Z2fHDcbDpbpMkkBoAIeaidvUyKgyiQlAPvm9PL6Ii0ycZmkCDRI8KGPLpqZ9aRlANl8he4SMutJ
CgHyoHF1hZpQZpmkFHSa5yeoNi3jW1IMkAftTmPZwCkn5aBxRhLtLKfGZ1IOGofuwWmWSc0DR+dX
T0wdlaQcdE47T5ZJygGOm8ujyzNXOVWmVkjOgTjlwrzzE0Z8fXv269U7uxTNyMkWUZnjkzOY1LzT
RvPsunWSKpNsEZXhAZ4sosskW0RlMmYrVaYm53XlFlUdbecAjYcHEAv2hary8ZBpPUe5HMYvK5dD
qpqZyr6fslErwy/7tvsBWOf7fthH8gSFJJM7P8P3AMeDBRQcV1jlm+fyuTYoHqTe4ZnlmzegndwN
I1ZkDdSW6lpkyAXo7aEo1wWf8Iz9v5GSIYtPFuMuVoaQo+m9BTmcOCHV0UhO0bBvJr4j6tvD3wMr
+ah1VK3s26VZE5V+bBNebJPsSCVIRivnGMCCDugokqs2MmBlLFqGH4Pcr4Ef7st0jA2FHpo2YE/6
yy/SRTO/9MjhCcP8dj8GBKhyJQFz7D8qXAqmWk7AvJsuzApLWFs1WddwspgH+ybM1m4Cph2gU6Ll
MFd+v2wx/MKfTCNZUBba3d0tyn9cWnEmh8z8y3RCdADwRrlWK6ESTn9BLCql2naaASPc0OwnqMBu
/4P7D5DqfqPTQ+ugZBoaUJsKneXSRC0HXuP4P67bHe+48esZebyEn9JDqeyAbF5YUBKyIol4T7ZH
xr4mQYXiQ4oK0Mx4w35yTPX85fLiROLePj3lOcAhiIkRMB2Rpyfdk+Vgoy5mfjgnf6kwBEcj5UE9
Ltfo9RawAXw0JAmU8PnvKSGZR53pX4JwqtHjIT+ds9KGYYOlQWBTqazRSz1/5quNmZ7TVGvMmVTk
1/Er+nxmlhVEPubfejEL5XphfynCKAPhE8WQjnv/Y7CYxaWVoxb9dMukaiVCMjCm0Oj56JzezfIJ
D26p76Tbsfk8FLR5fhShz+cAMzplkYd10wkuMkN/xAjYdRltsH8+LLZbxfbPsK8OJoliP2MSbMWn
PT7uoA10Cpc/uvcfcU/3MYAto0YYY+ATYnle8vziwHo+bMHDSUm+jzdo1ORWh4ZWCNtOFDfa8ek1
ULMfD9BxjJwMhmp94Oo7+GyXHOqXWMwB4myKC8HRtB8UzYRjf+7LhMPpdN7GeJq9IDLgzGQDusW0
OQokcqgMEVPXxCh+TSeKYwyxrSGuJ4sIFzCZy4mNo6tmK6ANtllqV5dCAM65eN/mzDIGEtIAnHnu
wzLfb14WXYlX03Denvk94CAWrxRFTxe/8kfU0ByjrhZFP0btP8Tc5/wayLwxV3A/e9h/8cQ+m0bR
ENWRHnlpvOHOjg+uWTZY/pPT6vnJ+WXrV+/6KJeDmdT+KTtBf3aBVtygHQdozQ166ADdyaD1JA1b
LqGqgcy4fYzQhFY1exZOMdQnqW6T5Uz4+SqJt4xXFC7QVgq0kgX6Swq0RqBAK1MTBn9fDPEc0dej
FcbxTEXfcNV+fYFLIKDdSXAsubmQBY5P2ket5lXnsuW9P2m18cBblF1KOwkZshBt3cOU8q1BKHqY
Bnli3UVp1qoaL4zVCim9M0Cho4wkqs5dyZ5sY1iufQlgVJx7z6HKdL5W3i9Idb4cXGHgUSunMZe+
3vcTI6ofRL1wOJtPVYsUFy+ChzkPymMNkr+ah0VUuQt4zpWBZb2AZ2BqBSwIKFMQrwUVKzy5vuMq
qEKx+XzDS4HK0KAql0fjCt0feu5B1EUrKybZyqOL1jjvfRBGcv+Sy2qMkMyGagCssP8E+T2cnaGn
ZlM6J3aRfRx0FzfHwwhmr6HaPuVo+7eu7rR1Tco8Xry9bh6nVrHsXQeJH64eWjMnbRtTKqmUqqVI
Y0rtt50P+0JJys1i2E/vgo5kRG8+He7QthBPdJFSU92OT2ylYJ1ftb0OetD0EFQa8f0D9Nmgu9uv
9CuDInyu9Hd28G+53K8W2aIQQXZ9Sqzjbwx097BLvyvb+LtKJXsYWe+h1hd/2L7TcX1bVm+19AXr
rZSMqoVQNe/s1HeCnW0qGdQGZUfN3R5VVNE179DvHtdMmUzxTjlZc/v8sHnZtiqOq5aNLn+ZRrcb
Z17713bn5Hx59ZXPWz1MsMfNt/WawMMBikYPUgp7n0B8z8NOoIbCwmpFcM69Ozq+sqSDCC09DHa3
yrvVnT7WU6+UulRfJRgoOoHv1IbtXfztUztq3TilThRuUzps+iWdzlOInjmg+AiC15N4DObeB5P+
NHwLX9i+jc6MOLHDYejlmHUgS54Y4SCejfw5uS6+88MhAqWHK66mb88uD6FH3zdaHORB9iT++Qcu
xocnteNTbupu9aghO5MY06BvpWP6XWK2lR5OuEOJLaUqdeshCfGR7sj3kiLay9DSFaXUAkWQd3F5
gSfljU7zzDwi1upHOaPc4eVlR3rJlSfTdrlKRjmpiJhlrHK1ZCPIU5IRsSWl4DR+aZ5fn8c1JK5U
yqVKbYWdsepGY90xjwzXc4qgC/RLpLKlcK3H0mWtmOux9hBZy+w6LRZ6hZXiiGnJpfLVRgbBGOkp
ppr80qeXTJtsXd/KLVs3xs0qi3j0iZw067M4mcXIp/motvvDqOfczPJMIXez8yO0zzK+/+yHY/N7
+3Yx70/vJ2q2wJODubm5Wsoeho4eo3kwTrDHREQHr3PaT6tshSjHeW36anPCZoXNci7lkq+s8UDi
dTu8ufXG08nUo8tofbDCxnnvIPcI0wvp6VFuxwXsx4d3sB/nlcM5RaoZQfnchgH89qLRoduG0sNW
fatS26pu1WrB1tZW5frs7InSrZP3Tdqu5PN0X2za7MBk8R+woVEgP/xQrheEenTxT+Eq0LwwCrAW
7tq5pM++c7l3fQpniAGJkRWRPJqIty7xiRxU/xZ6HD6rXUtk5rXtvNQJGpX+mVKSOBJw7STcG62n
q+1vms7MnQWik6Wl/g3Kvqo9pdDnckecdMUpqno902PFaM9hMSieTqiVCtrkhWsqRFjciJmTjckX
E23bRvuGZwubDPd4ULXgUDiH9Pl0MuzRmFB12UNeDV/6SqNGTiM8XDzFez2ZWKYPS0RZJNZpS4U0
BhSvtVs4ona3qpVSbbdWqe0uKasr+HLjydDkFJ9sFS4xsHhcmXv002E4xhhjvHhgVM83dKrDdsHT
gTh612ihX494PVFF9A0ZllGJ4o4Q6cs6qs28fsxJ7bg5eUcp1okB5DUn+5llLhdzdyHIcJRS15Mn
YTgNHQXbc8xKMCRxGrpvMcQENM9ZE3yzMaoDEprHT9gwidByBjI54FS0beItbqJ9sVrNGne6lwhG
rhTOyJlJGUklOAcOR5tntbBW2q07cs8b7Z9oaJzizVC6MIaqB12ykhqTgNXrXBJUm+yapHafh/Hi
U6x7Gwke6FDO94nK/12UxZ4oFYQ86aGXFXgU4EFtHKRzH83ymQlq6TDvXcR8fIUw1orOZuj+aOSp
wzI8IJNvUotic3NTrd5GICs2BPssduK30IEh1k8+dlcyGU8W+RJBrapbpvX4Z/0hHUi3QQY+kjoo
tPayvaEj1BMUzD8w1dB4p5shNBfEdsfl7ChFFdhcSYPsn0RDnAIfpcXgyobkw5QduQoSOaSINzeh
P0YzTAryqcJ17ovH6UL0fLyFiiNgCn6GouJecshMTETDVb5NQKtPHQ7y7cW1eBtMghAUjiuKnSnO
2LoZJl06VBQVfqoSqYCbQR/tm7EwxpaKY2Oewjrb9/lydhoW+dotpqz/igNxztDuH8106c4N0ZwN
J4sH8TEIJ2wujXaubK5JAS7nU8MKUwcrnfm9j3g4vCTwpjTTNqJufsEYqhTHiaLEumKkLo2PSpie
FSN1aXxU7vhnxUhdGh+Vu/85MVKfiI8qjb//j8ZIfWVEgvrkEKmE7DNGSOVD+s8SIPVVIkTSp8RH
5WZ+hvCoKjKqfN7yVHRU792vV8BxYA6GyzZMs5MZpon2QzB5w5ZvaCcPcxqZadv5UQ8GhyNdzrnS
sFvTQbWBjg66OlmIiwC1T7E2GwWw2sAIm/xpruSdxwXNRP1hCCNu9LimtAk6FXgDizce4cGk+wYf
FABkiMuiatxo+BGm5/yDMgr3PAqdNJx4wQOslPP8N99AZlGYJo2LiV0qqwybkIO2AZN94o2i5+lF
Om/n+OhC2E6pFNOPAFM/iTLVFJbaC7BsJbH0xqQJqguuKArGoPhizHaYYUh9oHZtYMNMs38lSrrV
pXzsab2gnELkLX/dklEhbQ5UIn0XBxYD8VQ6/l+7suCuMaSJXY2jW24EIAIKCfx/FNzklg1yYR0p
Fz6NYrvPC9DnFtVmg9wteHYDKokGwL/Kl21EMruS0cbP1MCqo4Hwr1r4b2xjMrvqYsHnEtFaBgPg
X+1/MBOS2bUUjz4Xg7aWMAj+bRX+t/Iomb31OeZA3u4bJa1V3pvO6B0+rAfK2xNsI3g3nygHK70n
V/pVi/T4sMobTuMS9AEPN4u0ZRHroOI7C5O2AfR5/H4wxpBY2zLqVsVXphV6vwvbs2cUoT2YPDKC
UpquRPHFdGYQrdvvRDmdzT35wDO/vPJoEc1APUpoHRHoTm5weedkUxmCJjadcAHj6MZWFD/LEQ4f
Ic0WKx3exMBf4Nhmu/q5gpH/GJ93PBnKWgf5/cKP7flsp/Q1AvXXCNRfI1B/jUD9NQL1J0SgTh+t
cGidq2v7ybuVahyOrNE6NsB1bM0wbTjW1pk46FvBDX5qSXcAaJ8ciXyrVYhn5xYZLQ+GwagvlNmq
shSzvGq20M46lyulk88P/1LK5crpjKt2LldxJXtnJxe5XD2d1UL7vB1nOpep1Jz1l3M526e9ymse
/+JBb0BlZVf2+8ZZHu23iuGwT7bNFB4V/TDFxBbEPyGHAIx0oIgvh03GB+IqNs3/KXiMOZ+/+sng
OnxZle0A6r1Psx2Tfz5Ocx3TW8dptmP6L5BedaRz/yUZizk/nfya7g6ZQf2R6g6Jz90f1BZ0X5DL
sbOrONUOuN3sNJcxKLbtJAQILRtRcmXZYmhlUCPqrrxE0+2cZNttOmTj3XlUtOys8uoKBLzmrBOy
uOBWBt4KSHg1cx64arfYYwh+wEnAGeYdMr1DxzuUUkqYAPA69QTEfgejARuutzUpmQLA89Mz1xsY
J+Q777DZyW2582zpiuELrmbg1TYUMBgAw91opfincnprtMgEAbIdMFClq7rmERGeK6fGIWUi5T/8
kIAuwLYp/S7H2XtNid3VD80kcjfuWhbuq5+SvbNjPQ/SgMfJF1KVUgZgqsNrmZDvEpA7GZDthFiW
SxmAVwnAShbgcdMGrGUBthOAO5kY7XdhTKIL8MymsZIJ2LEx1jIBW3bf7GQCHl2ZfVNVBdyQMCW2
LtKDPAu6bGAuPwFbMWArT8CCitZajeZm20BbWwJ4bk5eO8swGozVbXICHseAlWWAx40YsLYU0MC4
swywHbc6JtEpJbEk158A9EqO2T0DNO73ylOgcbfXngIlo6VcLaUIQe5JzJmdpWgOLxSgwRhn7+lO
qViA1gMZdP1yfYXwIm8IiLloXP0E3/5q37VxrABjGjULtDpcIJeAOrwwodRYNNMaR9ZR9/llG+0n
k9RZS1rT+tL57yT1Gpn1P4BUnFscpDq1reYyJauJCC+PTxKjZgA/Dsj3sN2/bFmwg4FDNhH2l6dn
VQT7+ekJFcFaT0+QCHbReHp+bPK6/OT0SNW2n54dEa7ZenpyJPqaT8+NRN/l01Mjwp00n54ZGQ5m
xicnRglZfnpelJCVp6fFJk98rnkvltcj3l4t3XkCEGtJjnTcJiRnXEw/O0pvPTHdvcVUObTBfUjK
P+Yen6f3n5QOdO260kFJTW0ZKOMXyHBRfNyCDBfJuP6m1HTKOHZo2JRxgj6lGmdn0JjtQapjZGvL
mRwqSz4YP/SaJLWPlpU1rs86cmLkPjGnpPdBbz4NpccltrrAFwXTRUTGm+zrMlzMMqYpmHi89++u
OripSTYE85qds0PMS7IU845lXrKZmNc466iySd6qbFk8yWHMvjhpd06OFURy+0d04e78vImqTup8
iWgz8rdd+c1W51feRaUEj/BftDvyaWAuLYKEodFpxBApYUSQw9ZJ4yfinot9J78Aiy46rZxDMDGf
LLLRNx0ef59cAKUVVyXY0KuTFra1eXmB3eGqzGiPR2ZteFbiqtVoVgzo6sK3JxcnrcYZNOPohM55
HYd2zOk2nnQfe6dXSJyrMy8aHQ/Psa/PFSJXl+IB+PVZoyNb6ezVk8PrtySSrh67vmicNd9eACkt
HMF4PAzS6eIpu9JkXpiwLs6enl0CTRdvvatL6E2PRqt1MJQJ2mk1gCVVF3PPLn+GKeaq1XzfPDsB
MQDQizbQIXJVF487jZ9OLkDcGhdH7xRaF6Px7Buf4XROrhSYi9PNRrVi9muu5hyCCEUH/QiIUJm4
9HUAQm2nT1Nv/bBPFrSt9knCK4E6WY1PstsJiHyrfVRY5RSRiQJo7xwUM6k3ps65Ifsq9tOZOtaG
7MP4VW/qlBqRw0ons5NsU9nee677oZrSBhEE/cW2+ElyOXV4rvPxoFCkFihZRVlSkBJvlW+SYK1B
bxSbj/AuNnDfEUgeeme/ijxoIAVBHn/O/N8flwC3mwhclsBtjABGy9MkGt4FyyqhchVVydTvr1Ts
pIHFqrLYiX8ThG55QNC3J2rvYZSXp2gqJXnQhyXPGn/5NVnw7Nd0Qbm6a/PaOFSCfGZOi/VgMeE7
hdh/CZ3n3oymXbLWptVchsegd0h8O4TgCSeQiMp6nnUzc3tPjDEYHxOOZE7RCY93en1xlB9MyHFM
Pl16vSAgc+NHrLmQLPv2iks+UfZmZl8QvJeqDD1UwXcErNLEDstjs1LLm5o4RQfoWaE9OUQRVT8e
8Ism5p7n+dEY4FRoj/zaeLAm9vb2xBq/SV17IiSexOn5T2Hd9GNUkvLT0SK6FUd+73YVwge9vBGI
K7OmQU98V8ImiLVwLQ+AyVrbj5OeyVEUi8Afr0BBBCW94fKGIszmMNXUI3/UW4zQ+7p8xYvmCKiG
Sv01q/Y4bBlRML/1o1sHG3QKoF6M6AVsmjQqDMw5+K4M/BFrB+GayHOBgiB2CcUvFaRMo3O3hRow
92+e2Qgo8eI2YG2foQn8GlrIp9W6U/DZi3ynt2pjZv6L2zLzP0NT+EUXCpaYzXubgSnaK8g0lPEC
owWZgs3Ivyvt74soHP2+2d/fj0dZapAlqLp5AVWWjBhhe+kiexmVKCDF78pOQv1CkT4gkh9+qDxJ
t/8Swv0XU+5/PtJHL6B89FLCR59AN4aSsCNdz6JwxdGHb3EB2pySVxp64+kdDj0oSpTaoy97yC1b
GyQlK4wkrBybODqIFyphjqFl1QB7vf4TS5DqgicQ9ofkcRNDTIbLMIr8WggJSPKw90/68xTqYLIq
5igTs71h8ns9mKCn8sDHRwevMnaPCgnieHBDOmmjlY+f2ZiBXp2hXmOfLhJAyxnbjnNz4vL/MJGl
hM+0mk920/6+lEI/3FwThFysOcWRENgCGdf5h0XAkpbpILZxs6K4WYbcZrTNLcgm8Sl5ZgKxR1RP
fCwVjC9l80vF/FI1v9TML1vml7r5Zbtg1hRGPSOzG83sbxSO2UgKJ/7cKj/ohdb3YDDyb4wCvahv
fIusb73ByAQdRKH5bWh969vV9Hp31vdFiq5ZZJcYznvW99kgMvCPTC4EPYdhlz2yelMYs9PRk6Pq
yBpVhug9NaaWDylT6jIHVLY0wmjqxQK5+kAyx9HytsSjaIVBlGyNm+je0iFkjSDger+nxecIO39s
fiMFNP4+m9vfh7PIKmxKEn4fzszcgW9VNLSKDmdWbixzlGkRdWsTMRr2LZJNtPOZ+S2YDk3IMCzZ
X8v214r9tWpRf2d8m43Nb72xOeSQQLuiEVeUkP+3/1Pl/3+Z8K8q+cDveAqHL92S8SUsVwvo0mY+
s85Sfg6HpA6HbCysprRVdvrQrNBQ5sIQo5kZGvFy7S4Mf/uu9OHAVoj5RZrUihmh1IzvaMOXPG8x
1eOV2+DQj9PtSGrKd0uU5PIBNyZugJSrO7lLVU1JNEGHOVfNSTbo6Aq9q76gPb3ZYtinx2bDF6j8
VPq378ofEs2xdt754ZJNgD6JnIf+zBuE/jhInESC6mEdRE76w3D+uE+nshPts4kSkQFRHJqCwEGX
sIrDXMtl9c0mvkObJUrh3J4Gg8Qk3CBKgFFgj8WkJ9hzke4TuezHfpepwdCAfXKsB184EPFw0g8e
6HkN5t8FvUSNvcGYa+wtQozyKohnHHQxSd1MUTfD0Dp4EKpPiJE6GM1hvZYoA9ocl8GHiPjoh3Q7
fXbsh+XtRAlU9rhIGAUCvoDaQyE66S1QWN5NtgB6hFswHc84uCNV0ffnNDKhTGUrWaZ3lyjzIGMp
YsByLlStJAotNGF2+kB37mA05TAW1DzJFMZWKyWZGWpe9nG3FLC0lTbqVbNv6/KwnGBxI34zsw7e
DcmUQFBr72MGzFwjCnGgm0BWF1QYTB70YwuSzAir1jAId+yvu/bXcinxvZz4Xkt830p8rye+bye+
J6ovJ+qvJOqvJOqvVBLfE62rJOirJOirJOirJOirJOirJOirJuirlhOO67o2QNeur7vN4PJxDvQX
imU9ESkgIZ16JpGRQOzC1AA7aSedtJtO4q5OpCWbA+qra57zFyMiUJ34JibH1ByqZp7kvGhOz2NH
meFYhVu1ijld68ULifExdqfHL4z5iXF8i6YvgQQGTpC7OIyOBGVp32ZdFF5hpEhpUVpKJJOti512
3pCwlVT6z4e5UhJcQW8lki0rGkw5loD1RLKDhEZLwu6m0lvJJmDaL8m6MPHnZAMo8RfTQkelInDN
gZbgkw0jLFiizmFMwuEdKBnQDaPgLhilOX8m27KdSmcDcxQfHb9cekdDJIgbe5c8caewtr3aT5Yl
jUzd+cmy75Kp5fpPlnWXTK4jjnoqubKF4DtpLOeWUY6i49yyrdE1nlsWMrrGc8veJa4R0ndY6Om+
fDrG4+ABKOOR9s3ngVrjzdPCfXl6CpJcSieeN5K9jamNZJdi4nFSLgnpWbLXqHwrKZcEe3WR6g9M
PznObVXkdbj4hjP7eRjM5wXx/fdGijG+C0Ygjeh2Gs43OBg3X7qhw8/HTdEYRVN8r9y75aDUonN2
iOf+QajCtUGm0q2zwr6Q6oxsneX2yqTb0WvK0uZmQqEgoPCubEKVNzfLDqixn9urxlCVzc2aA8q3
Ktza3NxyAPUtoPrmZt0BNBvl9iox1Pbm5o6rvtCiahdodxE/m032qjtGG5H8XScvKmatW8CyLRfC
wG7DFuDbqjjghjcAZwJWobVVGVEqlv59az/VIB8WDulYvdtX7Pfcah2/Ws+v1vUr9v2Knb9q7+dW
7v7cqv2/sgBkSkCy7qpVd8ndHbMIENat7th2gH0MHgFbLYbb2dysuvCFdzVgjlFvtZJB4Ny/UWoR
veuG+WnoAIM90XAityk+u3MYjTimKmWZwj+Kpd90u5LSiYxMPsSjR+afzyHL4DkOWQZfyCHL7u5/
pz+Wz+yL5as/la/+VL76U/nqT+WrP5WV/amcOv2pnDr8qUwj25PKafoI0TzdyHzgd0oPsluNK+/9
ce76jB4wdPLpQKRJq+G43PGycpXscn9ZVq6WXe5yWbmd7HLXS8qVS9nlmkvKVdzl2qf5YfGukMvj
hcoPP4h8flhYL1df1wvpO8f2qXfa+UsuUUeK3wD2c+skCZZiL4BdHSWhek4ofAudaJgbrpyES3UO
w1WScKnOYLjqKvS1kq2ouqhr4SMrGIrtzgpNIeC3zYtTGzbd9wwLozgFm+5vhu20ri+OVqC3c5xo
Vc0F9T4BtOMCSmAqO5uckKuKE+jSBqo5ga5toB0nUNMCKnM3OEjnx4DSjYkUCvVc2erVdHEaXzYC
awrTt90KnzVRLcn9y9Lcy6W510tzm1m5ME2UikmuFLJAy0WRT3JQ3+yjtvZPU8wycmAOKWTWUHlO
Ddloqs9DU1j+qISuJVGVpfgZsGuJHqM3PYCEBRDVVbmJsVY2z/NH5NlTujOH7yrcnefl8zobvjxI
ArCahohgBR0F8WJ6Zd14bKafrOBNRXz6skO3eqGHq+1v5foHvF02iCnXC66bghiTMK8/nr8lPv18
W2JUL1bYDCPYF9gGV3a3Uvtgw7HnETn23BYbL9kUfwmno18wLImMyYGbNj+Kpr0hBVWxN2YYKyBy
hi0hZMtClzwvbAmhWxa65JlhSwjfstAlzwtbQuiWhy75vxu2RJj73U+OW8LYPmPgEkb4eSKXiORe
8FNCl8iWfobYJbwNlwFMsoOXJC+UvMs2up4umMsbJzlgrasmY7/4g5q+ce2J7MAla7GP6TUz2Z9P
x8NeIhFqSqRE/iiRMkum6NrjAF2J2CkKgK9JZfiUeKWMT5fxit+T5jRX8lWXuveXF4hSkXjXeI+P
bg+PHGh6Jpow3Jb1qpCdNj4decVs4U2QaPR4LDfkMtScH/ZuPXSzk4fxHs7h42AKNa9Hw8I+n6Cj
EdF4Otlk06q40CwEMglehqnLLYeHvo8D2knzAYxbi9MKeqqn7u1Op3OPDAlwJRzDROaRLZ6pNh1d
np/DiAWmXVhhn7c4Tp+M+iK1Fgdmfv5rJFztr1CKCmHcxCv89jYuQj7xCa43Zmp/+xDnBqlIheuY
1n6MKOChUTWqcIjmLgi70yjYN9rCQQHpDi6cdgMv8mfDXmQxk9h5NJ3gKs3XsZMgwOk9mi9AySKV
FAeFqRvCd1IKX8n4qDaZFEzYpPOJoLARB4XFiLDn/uxUFbCi3d5wRFudmQyTGsZhUk+pYWyzIukd
+71bYK83uGddNm4G/rNtcCS7YOny0ESUZHmWGIiJKyEuAe3iAlhCvdGEsWcVwsoBMNmxbL8LGXPN
M/xGV6JWPqVcEVHtxpmHh5l8ccrHYgmDNS6H/PJ7MxkXdeUGqWKV0lMFzaLIag+mGY9mBV1G0Fcd
uVN2iJqP7NpjFDDIpe2eHO6OcmZJnOVkvaoTNKFQGrPFHIaGpMaulqbIiWXFSmkzA6MOP7oyxhmj
/GM/PcPEUqk+nt6/tR70291uQG0mBMIsFI1nONr5fYw37OcLomQ8ekvZKD/0bm92tLU1tHEeGjbj
OsrWqj9/pSGmvmk801H/vT/aj3PQ1Nl4UkdUoK0zmjkXv6vEL8q4ZOFVRiQsaXwPVLNhusA9sW3W
rUClZbQm5Y+YaVg9/SJTnjdvBAVllvOhtn4ub9D1MSxVD5usmnje24vrI9ix/nggauKf/xR5nXJw
IKpoKCMTOJIxA6KuI2TN9Bp0OutN5nmD13F8MsxDWkaQjYv1KAqySqtXC0LoiDjWcwyyglapyP/8
GpdNvugGQP2c+0G9wtCluYo/Cqbq8EbuFD1vMIhg4wrE9eFXGM3J5Qtw7H4achgK8eeHPdqDYApu
WaIAl3l9j3Y9keqeAP5OplQ+eIB9FobSnPLFZQSbt1EfVtCg91H4N7h0zUWJK0xY5St5N2OnvNpg
OhMRVR6Uab6Vqg3pybYeP4sDk+/5h40yhuf9r4fl5vcmNfxqA90u3Hq9EbQfj1ToeQAZp+txIePC
9Om9HZIWAxMg5SRetTqqwLVyxQoU6FPoAZXCPoctdow+xC0zdkd2HZJFuhyWeUZVqNs91SKRUZ1Z
Nt1EYxLlrhnPcE7I05QI00YRdKN7iliOh2yodU8Hnpdfp9mnUPA8uxhPSn/NmrkSP4mQUDjvwYz2
0tJI6OqlcX2dDnRDCo71Ijl+7KYm2G+vIcS5eBYK7jk0lPFAP7ofznu3Ii+TcpiW62HoyPIenazK
PuSdHNcJysnfvZ1E3+zrgpXlBcv1zJK15SWrlcySO8tL1muOkn/EErpSgT9MRQJ2EEFfb72sGFA6
xza8s0xmdITjaTi8GU780ehR4JEnvxbhObYbiNmCZnCfEPAmTdwGPsZrxqO5bwznPvEJE1rBwJL5
p64fhsMg/JM6oYsPp8JggM9XaJEdhlTAj0C+QL3cgN8f+aRwFrADsQhNSFDb8Se9RzYXQdJCinEG
cpkPNm82MfJcbzTMFwriTTcYTMPgTVwhkx8O56TAxojJaiZ4CHoYBHqTwie5oKhKfBczCuZ8Uqir
CGPC1NnZ3KIpmiNNiHt269OudohxKRZ48jmK+BgzNjm7hc2MkHyDRQ+tiIMHHyt2hOfk9hpvFvtT
Yb+Bv+vNFlpGPPxmPvHH77Cgfe8Wno0fdenf0orlh/0Yx8aPwR2M4Ym3mFH4+LEffQS85VjjkC3K
F0xHAOL+lhRA+yZNcuzFrXJV9cWbWnI1FW8vFhOCmGO8cVZZ8j7Nk6EPNRSgR7kU6Dt5HajWWRPu
JkCSCwV14way0Qs8CaTi2slmL2Wvfwcbj5F/Eym98b9JdlDpPRCZbH2yIXi+D2Mw0Zb/OQKDferu
Syk1qGDjXqFUIHqpV58tPlQKqxKryY8oqBvbJQKEAH9k8z7yB4F364/mOE7zfKbkFDPUuXCSenHn
/Avl7AvMZbSgecPw78QN5EKKLy5gKdgMn5TyZAF7OCeGtwu7dKOTR2BaQFxA7BCHYGg6to4mwr9H
Cks/r+aj/It6aDPNbenyQ9+M+2o9pNUQ9QgVGVxMJ6PHIt3wYLJG/Y119Kv7S9Aja9iHx8+sQYNf
W9uD/e6ePjQwWzruQvOUF0KDTyFl4K847d5IM3EcXr/Nsz3BPwQdf3/Mr8krAcwTPmzBo73v+t/8
dbKG+sJp8+zE8/ATnVV7MBH0px7sguc4J/xhPTtroZPaw/d5bzCeQwk6c442NzcL8aJinA7rlUOS
gaVEUXz7rSpZsG/e3XcvsXGfyL6bkQRqixmQzAcruQPCIlPlyQbWuLRCF85vv70+c+LN61OtwkOi
WUsrcTVeXlJ9FuMDvl1ZwfyAAb+AAUK5XPqshvhHvCmQVwYwQtVFE+wj6C3gLXyCfeQNnwBd+eGc
1e5/nbX+VyOGr0YMX40YvhoxfBkjBooC8M4yYpBJTrP2DNsE+xEuvrI+OfManU4L9hD04PiHH4w3
8bCU/5OV+Lx+5s4A6iV8wQI45sxjZ+kGZzacmfLJt6z9zIWcX5dLJPIVvDJ9fMPDVdogzEPjeThp
c3h/hoMWPZPYj6QlCzot5ibe2ef0m26NGGA3ZjhUV0V71cjGaVmIoPkBza6y23R5LEiP4z0v/pIE
QMxeXEsim0Id5v8rr/M3yrb5/E/tTuPoJyrfztXw+rFGTYy0Diw5yp5NXotuNHN5veu0pCjllMN7
NLeYhyWY+eH3nhj7s0jhGo6RiXk8ISykX1MQ085yZQtPWWLALqCTRdvTtz8ZztDzMh/5kUMoukWD
+RTUFGWK4nq70Wp5h432SX5CG0yl2E0K9OagnnpCgLFngae0z4zBcXv9PYyf8pksJTYEMTpZ9uSX
TkuWhb3ijz9yDQm4q3e/tr3OJcBvsYb5UFDmvorarRTyuNB2VqHtQmLnPPMRNNEuE+AuBrDxm3jC
6WLSX8CGCzqVq84nLwqQP69jgRV8maUl1KhzHi4mPQNVClGi3NPmW0nLkxnphXKhVaYGo0epTfIY
lkff0lCKoDz/zh+OyHgmphbp9OZTbzaY5PGztR3gFOzkePQaLYUyVBSbCp+tovAdBckq9wYdGRMt
w8g0jkC3wDic4G/Cabc9H2GmrpBupMwaSRgoNaNjdHFoqixttj6NXdukL7O+pmadTtFEaX4LCiDs
hEEFnkbk1Gxz1JdtMDbp96hUmxOTbDT0IJlHRM7JnQL0JQV5S76vKMm3LrgZwx9e54EobYjChhfS
FiMY8XaEfXZBveSfBO8uYCbnPdXgfrPNuptGmKaJCCHClEsZGa8LNCg5h225/K9bZjEmTu99E3BV
CDGOlDxNAhsWD3AcyncEHDE3gxgV6Jp9jcziENcfg0deG2ISYfnTBkhBgv/EcoxL1Dp5u50rPVSq
tMjIKOVofj7sAxeHc7Q8mc2AkRpRJp4twLOz6xt4tgCPFAe7OJlZKNF5gF0gRY8YDHviG9dK6/1y
ciHdwaDXRJQB+HYYL/rGiQ0PX5S+/JiHL55Orhdo1qQkewgr3IXMww+l332m/f9oxe3/6Ivs/ne2
P/Mr/ODrI/yvj/C/PsL/+gj/6yP8/9mP8HHja72/VwmxYyZlm0AW4GQBhDq4nObQ1gJHKd2y9Bew
mic3bojwqHH07sQ7Pbtuv7Od6em85sXppRWR0szCaI9VV1b7+vwcZM/yeAeZ5yfndEjSPLSCUGLW
VedIVVa3c96fy/TtVLqqxow4iVkgYd7bk453etLogPC2LWdqMr9t5pvRJhGA4h7KassJvpw2fzk5
9hrHyQColNc6+U/aJtohUHVWC6Mttu0wqNT6k9apd355wVWWk7w5a3Rg+J9zpeUEf3CEmq3Nlbcd
AG0TIMEujLsm25pgFIxFDoJZSTDo/Mg7OjtptLyzy7dWgEyZedxqNC/siJgq59eLxnnzCNXkzont
v48BYEq4bDE9la107i8ww3UwQHmlmsoEtbbZhjkFBc0KaKnzQWJO7HCYNK4aGGKyspNO9c7wzNSO
f0lifnn1q+RZteQaAXQbSCOkmuDO1XnTg9m09SsFrbQCW2L2CU6KXrPhYcjIi/dWOEsp9vGZVdUx
wEBSvA76IahuuwgDaegw5dWkGCjucW6ixe13153jy5+hU2ulpHydnJ50jt7BzknNcxRW3njWod9d
sLEtmxIqD6c5zGA3IZZP2Bj+t+qHDMv8FGK+/2UTCol2aER2w+nQsHD0w5tykTZydEpmpldssGoh
+QqaJ+TPs80Ih3fT2Wo7DQn6JVx+GZuN7MfOW+JdcD8K5vONK7/30Q/7AIKQuWPAfw5bvMltQLrj
D31/sjmOE/58O7OePuPdoi/PHYa/+1rj1t5O+6ZNH26WfwkmxISMFbPVfH95lVg04zTzjR/sYd/g
OQMfkPATP/scsNFq4DnAdeMMhtmxOlGYi7I4PywKtibEPccG2rtEMx90cFBwQSqHI717RoML2N1I
d8AcMCvw+2Toiy9kpncje5v/S7spFw8rmLURhFw04vMqudNHn9ugWVp4zhtXVyfHMJ7bjC+vMIvX
VAnOHfJV5iDt6UCiyeFWm6xEvNZpM5frhoH/UVCCZCskO6HbMEWhb4yOqwxkHndcxdrLirUzix1d
wiLloo4yXCWanSP0WZIuQRlZJZwcoIysxjhLUIarBK7gzfctRxGZk1Woc5VVCHKctGUWamcXOrl0
NgeSs6pods4zqoAcV6HOuwaqoekylOEqAUqj97bhKMEZ7q5sZXV+y935yMlWFotbmRx2FmkvLfJT
VpGfnEVOj1ztOD3KagSFxMhoB+VlFbw6zyoGOVmFTk7PGm8zilFeFheyCraXFcRp5fAkY745PMls
WTurYyHHXBVw1myeYmD65FwKqd7labtgw4JORPMPFUoWMTMdZWGHegl7d9THTlvp+sxcV+nThpPK
hgsWmu+AbTvxNs9dsM1zF2yn2XLAQqqLVVBdU+6nUpzSeVkFjzIKHbnIwu5Ok3WV0d4rZ3uvHLCH
jYufyl6rXE8X0FkZxS6uz92FIMNF1Ttn777TvWu4CHB5McpcqfxonF/joUCRkvBR4XBN5FNrl3Fn
6li9VkEjYdXlyDN/+CKraYSspqgEWpGUXu5BNyOX1ZNeIC+/nl8P1QRKJx5RR/Jqc0OqXeqW0NBW
dUw7jiHJERPm6EB9wmZoBk0bEYZbn2PAdRcGUOjwyqgo0ETctpZlI6+EU8U8Rl7jg/BuOMUT/cUM
X25B5RiQYjbSD7HRZjgO9C0u8fQ2kvWsodH5GqPxu8BgXzIYX8uDNj5x00qI1q6wLF4s3Cx8MtVj
k7FuIKJgjg9EMV4LHU6Fm8O7UNzTmyX5noofLOUn08lGNFtQiPJCHPAioSWD0MUKrtDRz7ljPI54
VEjqwK65Q5lCr9soN37UNZOFsydfKKry6DnixvCRALz36AkMIftGo08UiVJFvDt/xLbG+X/EVOFL
A+nCq8Ag4t9FCQZSeZ+f8i4joyeNl/Miu01xMCJpN94XT5HaS9D6HNxoyw8D5d9h77QnSk+0AYSI
Hikka5DPITwzCErhyYtxc7eudoKc9clb9mjFm8HoC90Mlnd2vl4Nfr0a/Ho1+PVq8OvV4P+Jq0Hj
YXiALoUEO1ES5LxJmm3xyPLVm+/722HvFmf0fhD1YJzFVvRp10Y8vTAyVXzIJvg8/qEwrC2+uPNh
NCNU7G1FJ42Cyc2cHISQr6MhGjIhudK/yOOcLOwCH6hiRzlUBRsvDR5pSuB09NiA0wihUslo82+8
CxB+1GO1ANYApLebxLApTnRVjAnRUp23/h3Gbv04md7ji48HNI4k4png+XQOOgun6OcjxCn5BgQV
kgi0bH7JgbPmYHiz4NNqZRfJDN4Ul3yMjaEjucvUOxResHC+huQZxjScLm5uTf4sgDHAIJzQfR2F
iW6PvKPLazT/78TM0QsXbBPmrLAb3EwzbFN6cRnRiTJO1vfDKOCgj31cFgJ6ByJQrWBE0BCTvelD
+Hby2lolOFzf4TND+rRvZ1YrKhM/JTIxUihn4qdE5o7K25FOa+XWICntghy03GLIHsoa3kx8fOL/
Ww3vmdTuFklvN99e8KXpWrvd8dbk/RQSRkVZQtS1FXrdpeQwuPut8oF8ah2i0O+IDXE+nEzDIn8v
4Xf/b1Mj2B+FQI1diZEnoX20n4NhpqUf+hDGGlnfJquk98bRYuygJQrCu6Bf/m37QyrT9+5gCwcy
y+S+4Y2gbEISuPsEcMzRKXB62P+tinAI2Ih6wyG0Gfa+i4FP7hRo4nj3s1WMdZa5LgolfVlSzhFS
sctqY+W3nfimMOHcOCUE6TnQMktukx1A+8i8rDUjwDnyvbOTi7edd7najgPs/OT8Em0VTDuLRKYq
b10KaxhlBmCZY6RyGUfOMhPQQJ0WnhvmLKuNROYTNFy33p4gJF0m50wDjwwYhc9JT+PK+7nx08n1
lWUPks42kSTGdexTz+NVbjbHQ5J/JEQkICdA7BsO3/DHAy+GcI0Uuomm3BkLaE96/LR8+onYqV+i
VGSVaj+jlAqZezOj8yRVtBhXvaQJFeX0OzkN8jHQSqxiTpVd1aDjSbVpT84pgScDMceuztMgfDrm
8ePHdHa0mM1oDYtxOKB0f6WzZDOxIThZpTtTmoErB5f7iYk9yJjZLQ5XnByejfw5bsSeweOKi8eD
gNakJe3+rVxzUjAP03XLVTFdtwquZgGowz2GzM5mFdAFoEbS1gedG3M/4V3UAUGvIsirZCZua643
+T/veT1Ulp7RAbVlY4mtTxLi0Z+O8TFMWrLiNqUo82fevf8xWMyeQdmWi7JxgLG+h1FqsTeIrjuk
/i7oQZWaNLmfwL3ElTITlFp9lPZfROrQScd7DztL2IPm0EqhJF9+2FB4wE/mXdJCSsOVl8GxRVMM
nFh+2NzMiTaxmJGh18XxyV9MEmspGGwL2nmctw2wxCqkTaLwZUfzCFLonkqDJ9Y0y5wyhtpxQbH1
ZAy0awNdHTXRccJp8y0Q0TiOAculTMCfW7A3NyAT7DaME2OYBJevr46Rwfh0MAbST2oSIiDIoxd7
DAB9jhx6m0f1pEFftoHZDVNzUsnMgXIq/fDysqN6sGLUbItLMUuEMuigfBcllOGkhXKOzo9MhcvI
uDox9ag4Ax8zgkzRE514j8xU3Qe05cQTuYVyAmyaskVZNnKR20Yuho9t5FxBPWK45Hep9apCqdxY
yUIXtLm8rju2j3N+AlixIiyAFkzbvjQNOgUN+/LPoQB+VgO3KIi9cWOl7Ds9tVsQ65AGn1OWge3P
ZxmIAdtXC4AiIb/AVcNW7XPeNHx1GPLVYchXhyFfHYb8j3UYYj+Ex7hp7YS/EJW20rP5diC9w5Pr
EDM2A87Y3iD0x4H9HH7ONgxxtvnoR/QX4/EjjLKJnDP0GX9PP6WGESH0Dlo1THoHli+FaIGjGmhx
I5eArHG8eaPcnsXZBXkOjZoLIue4E+gCTfq5zUI+0AFBnMgp+0nkz3JzluGthUgi7xuwBRt9NOJq
uDDrTv90YwEMxrJ89UaIVVbt7lIEnUXACMqAY6+6vVfaNRHgSl7ZLe6I1/C7jku5cJjDP+zUvWoF
DeLFt8HIchmHWcBREOusgtKSPlmQOoKGT7b5vWBn+fAnDGGOXrueaPG1XPCuIQgZuH1Kl8ym0fDh
jXIWs7xzbNhP6qYEqlU6bKu4DR2Gv6nD1D7tXavjnTd+US7BSw/bg8Egzr9OAPBjglfiVcILoO5S
jIaQ7rDXGdBQkYppcHZ58daqaHtg/5wZwNc2tPXEgX6uz5QgfErvRj3QPZ7qVgn0Sf2pcKzQkeVK
sVwVr+HPLvSk2pjNb9Ek7pX4xytiCAUZWp/QcmAk0KS1n1poVC8p7z4fg2DGSqY/l9ehMHfxqyYr
SEI026cCbXJFRCfQmbBDCWtYW5olYk+QacIoHzFyK2lJ8yiAJW5gndO5UZJoOYdN+WXb6zSaZ//J
lyx5i3MFhRtNVyTP9P0huVSViZGMTiTk6Rt+2/8kIZOxy5YLmQT6JCFTOFYQsmoVZwv6DV/1tajV
ofRLLLy/L4BtyLNXInFa8I9Eidk88EBZL9KHW9DF98Uf9JlKp2b7J+eU7GVFEcI02j+aXnez+Mds
FjJkq4YMod8GQ7LbyS3D9U0+ihpWgTrPUSne2qhK4fNsHlrEGdn6Jwb7EjxzssNBmYu3BphpTMmN
R5LiGnFoImfr28hZ+m1wFoNTaPbo2/tsdmr4WDS1QcAy+V1oqC/BSpuqpwiKafkUzWQ07L4Z+/Pb
zZ57RonzXzSZGMVXmEe2SkX0OQt/knqigY+1tnRMR5hZKesVhTG+5LM8GSdB7VkiMYJZGw8DekDl
rbQRwpgSYYCGiyO/R7ZGeH63jqcuwbiL58u6vI6u6FoQN16h/P7yyy+idbEnfl3AIgfraB+tNPsC
u8ifoLnLHq8zek/3n9eNY+8d7Hd/vmwdi3Iy5+zyZ8pgFtUqOzgAapUa8Qhkezzt94fVPE9Awi/K
GUt0QbJyvNvwvL/3h3dhMM4vIH/RLYrvFxjQRqigIvlJcCP+XWwsQrEnOOuPFZZKGmGJOJO0wOuo
IKE/6WNswAlZF+Fl8nQR8qOGF55RwpYjQ1Qx50VCSgVXWebqZVrn4A/xnnZ2eMRHd4YcMVGsSy2F
w9eQOkSqAHJUmG9jmJGvCIyRqIthxoYG6uRjTqyPB5OI8U0KWmkzgknKK2e+gOMjO+PzPhO/XSHi
tyXxq1bLlRnoNqFDh2hbf3x53jz22idnp/sKiITJcO8uCZvO0KoePQT0gx7oTVFg0grSaHyzZE+K
WELCmM9RN/yIkW9QiPCcfgKY8WC0sJpYzafTUfSmH3QXNzdB+AaaPZzP3pyDmoZnqlLClgN9gQPv
aiU+8MaHCK3Ly87Bv+WPrlvHzVbhzeYm/4/HHjz//VtegRUkta3FCOa18Uc6YTjCV4ttIV4fiI2f
eYu7cSM2LulazciEKugLKLRdaGVvHo7oFAkYfti8gL49EPh1OAj+LvJcZ6fRwiuwRuvoXaGIwlyI
wQEj8+rVhn4Vtnn17vLi1z08FH21Ab/2BEav65tZMoH+7AFNjK5gguBLdsIgP+hCud/Exu9iTRda
Ex9wJf63fPOi3WmcnXnIQPh6fNLu4Md/y+O7DLy+OySj5cIKKK5al28LMV3LscU0Yzy2yasN+oPB
n/4t3zqHCXTTh3/RFH7hv3A2tlsMPG52rrzLw/9oHzAzAQ75vNEfRurjdNaDjxiNIv6KhbnAHouH
QlOguo+OCrq7C2JjKv7tzwkwpOMYKLGl4RNGFV4jn58sHVMM8iVGVD0eUVyXUOQkbnOI6QxBwSRg
77ExCu6CUVHQ67DHcXc6GvaEIh0t5+cUWQKjFH5EY1XqlE1EtC4OUS7xpkGNhFOyRO5PxZ/GPj6t
Qz78ScjXIPPpTFBl9HINiwpkfo/uHVTUJ6gR1BUUJdJhnJxkb8b49O9jICm5jkwyriN0hjiM9mQK
zuOvNuAXt5qtS+TtMSD4020wmv0JA33dR3ShIeNqjOleCn2q4pUkAP6MoWfoZQVjAGzhYoLXW0Vx
tNGD9Wo6i8RwLolq8xMWDir2aqPBmFFXoyutHrqtpAdA3eFkMR+O8JrGknPQAmAgbPgRHXNSMnye
+13MMb+qXBw2KusmmKjPOh+QbvgaAr91zW9WTt/6NrDgTHxDC25sfXvAb0ooN3vIMP3akUbdwxwg
PmHYJdm1ZPjZoF9gGNbLW+ZVruHcpby7u1PE37tFdPJSot9l+l2h31X6vUW/63Syg2/C4tu/U/Rf
LDWJ5qS3SSDoMphvH+ntwLF/BzrD+TTq4i1luNHxYUT80MfU8Z9vZ6NN7SHm1Qa5G0UppDht0nHs
4ekxmaWLQ37vdIr5x9qWCgdrCOmbGsEsnN5QYO+Ib4HVfe6+eJwuRM9HFS2+IkU7e/l0ie9TQU7m
sOHDwzSaHoJwrC8L315ci7fBJAj9kbiim1VxxrerGBtPXsDKfQzCZ7FrXwRDeiclbatFRdVwpi5r
8aI2D1PUI6rtU377SFfYI3xapQo6Wx03rq+uoG+ns4CPCaFx6okHbAYGi1ERl/25vtLkFy58rbmv
r6TR6IcQDcez0RBfc/khXrU/At2vNpIPooCXT91S4mPnIOD77SVcpWAl6Hanj8/sRhG191foRhn+
kF50hEEvGN7htQFdHj/dWagFTeWFu7xaZu7tc1DbeVHch8N5oO6urW6E5SQh9kWxVQYYf/JxBOxu
zwF6LjZAUAeA/nQ0pRcAU5iFAf68IUqVcrm0Ua7iULtuN6QfHxqbZ9Mb9qkt3+eZ0XS7gR4SIPIY
drgv/Q8N8b17hNM2dgYdvwbsRolWMFDwkVbee/F5brwrxzVGdAe0qmHfkiJPSMJAPxs3qUGHwOqy
3Y9HqZrGNnu0VJJdgBAUCA0KDsPeYuSH8gkNzLB4Md8N5vcBiFXcGqQXviE5tMZx7EUhpt07NMGQ
8Z4D+drfn4EoSgqRfGD+R5T3GN89LoykszJTHvFFDfq7vvfxtCqSlZFQAcTGBk9LAifhxiwU5aqo
VPbKtb1ShSZL54UjrzxWeIiLk7OT83beLwiRxxi4BQ6dCmzCtDdCfYFvv5U+2AFdOTovXgOsk6rt
hdFdHz3+T+jFUGzdpTp4PQpGA8EeFq9BDb6+wLdyZAjFgIAEX5CMYJudgjIg1ollSYiCjBcud5hr
tMOewIiiLQ0sbGwyQyI6+RPaBc6gi9cSoYKtRoEcfqZGOSm22kTNnv0rWoVdxQkvbNbn76zSU73w
uej9XP2wlGAaC8HNk+QWk4xM8U3VirHXmNU/HojyAp2OI4KNHwfDYNSHkbmJkTBkaHslKtr9hrLy
XND8B/XfBGv7PJNw7/zzQHZkGm90C2vD/nO66rktRwocPaCarjrkACYhIvbHH500FrirBcfoyGQR
B+1YuUHYlcPxePE5+1InT4J7ivZKqTjNy07BJSM/pCwxFD/ISRpm5rg9BfH991b7hty+ffH69VDK
wT9eyZjdWM8/kX/cycggmOwVGQVgSJJbQ4tbirMOKGb9vqpJyigIqYs2hvrDEuiEzOL0doOyKnm7
VGahXc+SzGd35BOiCfq+9+6y3fGu8ZbmsNmR7bf6tMhBaiCtKJ/tcvaX6GhZUzbvVQ/9M2s0DY3R
lGNBSbVSCYwhIfiVGqfr4aa+PhDJno/HM3149kjc6r5gLEoJfnJ2/UFUK3icJ+VY1KsJ+eQMFTRc
6YVQCCuvV9fM5sRzBxPFZTcAukiSVVhFXp/ZXJLYdGttuY0rEutswy7lUZrgH4h4tHAFPBAkln3F
Mwa3OWThi/tafXoNrX92l0c7X2Qp/R4tgpz9i3Z+/kSoyUg7qYKZaGeFLoYxVX1GFz+zeU9MSv+N
nQuTQPW5nRt5GOgoeFrFdg7qXLKX+QaMUKZmaTlHR2qSlnKC9+UezFLxtP3kAh0Z6xxW9aXX7eiL
L9wGE/K6dRblCrWc8L8X5bjws5b9/De6MuQFl/2G4pbDzJt3Z3JIu3+lpvAiwVTTby49Ph2SuVQ/
SAvuHeexxP63ahCr6Q9Cq+OfXYl4s05MwKksmPT3pDUfJQFlCcZBVYg6z9iwKkLF7MS1QPw/Kopk
GKw1Nh4Ig0OIOu/ZM9xnXLzsZScWUWP1UfN5aenaozAsap+ROjWx5o0FVlnPFoDJpYcdFYgNWB1/
0wvUZ2qcGsGfc1mVxKUmh/QSuirrx+XPyPqNjZQ2/fmEZFx+kZjoKeDLiMsXabLq32d2zvN0slgH
W0GOsPzr1xKh2Vj2vfBk531OKXsGm8srsfmzcvk5Q3Q5eaqBn3NyfAbvaivx7nnEfUbeLSdPy139
v0nw6qtJ3vPI+5yit5xAOp3/YkeO6DCYptzl2wjztPTp/e7/I7Qr7nif37aXbHiTbZYT6cub/6y9
8zfW5lkr1y+tHX+UNvr/DlR7tDKc3JwvF63J09coL1M7rDuKJRr/0xcX5FzuX3Vd8VyGfInrimdy
S26XXttj88m9CLS08pLD06c7P9H9ouLsUHVqOpxwp4ry5mb1y/bsM9v7ufqWVNnqy3qo9xl7KLof
znu39k2LnI16fhSI0l4uvrEQFBdh38jejrPLjuzyVpxfceXX4/yqnd8PBj5MVns5t4SUimIbFsot
tC0CNGvW/cGXEZTnsf0JQUn0jxRxvd9ZQXb2V+s+jdPZf2Ujf9uRX4nzy1uO/KqRX7fzP/0qZ9Kr
fkZJd5+VxWSlr+rkYVHJnr7ED6KUXLYV5EMtcYt2IIzlT/LkqT6DTskaFJxfWz6oxM4Tg7KeOaaf
GHSv38CyAtp9UewsHXd0QivkHZlrjXr+AHy2MKx6MRtLgz7DnwQ3/twYkqsNyG0qz2VZsCi5lhyn
cubPGquOkWSMVBynO5njFHNrmaMUc8uOMYpyzWRLohh2g1mSGsXOblPGYkftTo7iD15eXRx7R2eN
dtuDtBgAnbcmASDNiF54cZwCaF7EQbpE47CdAoA0s4ozRxVnlifA45MjAwYfMXiQ1DyXDpNPjPqu
l8BeXyjoVxvZsgkig1JoJEW/GQSiF+wP4gDZKsXhzToPAH8yj/b0O/R/IHeLQttmFYU2eyqKtYvm
2Voxl/vHP3BpLP3xRxH/rv0wmU6CH9fEH8VVcPjhZi/qA5oEFpn+DCy9OzcWSF8dy2wQObFg+opY
yg6elFctvOMovLNyzXVX1fVVi4clR3FIXLH4cOYoDokrFp+FjuKQuHLxzXA6T/edTF8VS+SkIlqd
jCjcHDmooORn4FiM3UggnbDoQavN6dQwNwcvzHJcC0AVIUUawhVzINJrRQH4t/FtAldAfpMbraou
L0DyJ6aVsK7MbElmHWKty3VUIblu1HFYtqqA1cGfwEL1YuTlqom8shz5CrjXehnMOWrZuHv4UmM6
ehZysTbQyC2unCa4MhhNKfzBBvu7fiZ34kos7pxWvkwlFptOq1+okm2zktrnrGTGldQTfXKV6JMZ
PnzpobL1YvxWI64qnwl/6JapVoL+G/ma48XYLWFqVT4zdkuKEhPRJ2KvpLB7T1AvwtJGWE3MtjIe
oGuuJc+FzulkrciV/OMfyTaeJxsp8Ut32InKh5P+MESPkM+rvjdbDPvEhdR8hvFrvSQNBO9kc3Yd
/W5IrUzXcXzYStUA0M/FP8/E33Hgnz8X/zATfzONfyKGz68gk0HNNIOggmdzaBxlVXDedlQA4M+s
YPYxq4Krn9JdANDPxT/uZeFH3+RJ/OPes/H3M/GnBwFAPxN/yOxx4G85+B8m2ROP8vEYFgFcA1zD
HHadUm/E+x6pN/LHEk109NhUYO24iZTj/Oiis2W3b2sDjdn4qCVf2qiWC2Yr41omc9VK+bGkp9Pt
ZC0XnYpv11Ixaylv1DIrqXSLqhL8uLyS7tJKqtmV9OJKekYl1RS/oJJeUtVjTtlHwO6quDv0pVxR
xF1TrqVqelnHZNWhNQyrjrpdR92uo57FsgwRqyv5Nuq4umzXfVct+G82jV5YT4pfWE/389dTLTvq
6b2wHrxrj/sm0n1ThnpIO2vreprn5wkVrUy1KDPS/EYZDW6eJQIVpaZdm9VcV1yjRvvlQlHLrmar
a1REX5wSLWva6rpEOq4KPcVI2X5ey5IKKFa2nZC67VS7ypXtZ1djr9BYTfdLVJPsp/blaWJXg56M
6bkrmr5LxZQG7gubZNZ1ZteFr5UN9Zdqyawk2inGDwWKXEktPfe0LxNb5nA656B+dj0i73zVsPr4
wpAF3FU7RoWay0BfYviZi/FOcsxVdpZ2Z7SoLan/uvZSCmJPgEQIWlFXE+O0Nx3P0BXCCkSOywaR
9MUi05p4XsyobaRjGQ0Wq2IqNBEv59aqbNregN+FYhkpLZYeZPCdUvas+jTnrj9ZyJDoeu35RD9J
fNaSUGX6zLlNTm279gjdTc1sW+VsJWTJQNz1U0wSdcUkmCiWsUtSEUtaZasO/7ZWpMMio7ukr/51
ZJQz5bz+NBnlWoKOnfJuBX8t6ZhyUVNSTpCyndUxO0BKzSalZNGxnaCjvrVVrdPvbJ64JLJSMoVB
1aRVlYROVClbMvkCWaxUsri/q7mPO6fK8n6oVBzz9Mrtjsm5rtjSUClrdlRIGc3ugkptNV6U60Xd
/XVeoCvbS5heS5yn1hKTU34U+NEc9jz8GAcSp2HQf/N7EE6DyN336KNC8oA+5ogK7PmkdlVPKKf1
ytONfAb2RNPqq7Bw0quq/uOPJfu6wdDhL45SxzfKo6PIp+0XnrfTdihVZycXyc6iBsnAy7AHfm4l
jl0jVOLcNcaV1DO281mLUE0uPTl1LnWIMb8SLRkPHzjwcv7PYXBXFH+GBPgd3S4G8McfzYmJf+6G
veiZKvCOs/qdRM/xKq2oeO7WO7ldxV3k8zaRrZOzeAzX4im8Vow1eWOmqMZjuNN4W04cYsm7r7l/
86wqdmkViMcQYe5+DtTZ037nbaeylVFFeBPMV65FTrKEL73yc+Vl8su2ZJJ9WdWygUlN0Ghg77kt
5ElOz3FCzXHqTjj1wzXBjPdkTenJIXUTnaiN54XjX84v35vYR/2H8fQu0Yo/VgwV4PbpZ3hHXOL5
T0N9kfBtO5bTvyY6OBr4vdi7AvsIIxst6UGPHV7C4ogeyDgaKDHJchi43FVgjR0GUrGnXAUS0Odx
2AeIPo/PPiHS/t6Wuu2j6Tzppo/wuF31OZr8bG99gONTHfYBik/02QcYnuu2D4p8Bs99yNpPcd6H
kvl8/31UbokPP9m+n6HiOTC++yiOHm8mi0i0OaYRudmsxiKQGnt57bUu2vQL2KS7IXwmr8sqCks/
wPwwQvYyI0DCYNYSd344DKhrLfgomMNGAkczOoplhqF21wfNDt0M8sBRM0ORe83/OKQQCBrNBkYy
DyLyZCs5HXHnDifKnx97DJS9lyABZFcWRSxBX/s7VA7Zj5ttr9E+997FBoRGEsGx3/bebLSI8J8O
2bl2tIYGgN9qV9dxdIJo3h9OOTiVmSbDGDwJGALNiUTglIzM8qNpGMnhhPMPBfEQR1RlR+lXndZ+
nKbCRqC7Re9u7BtZZg5r9QkAGe+ZALqPZGlrBh6hZFhkAh/f2SvK0ubZVhwLB6AEs3MjCt82QIry
URHaKRMEfBNr35XWxFWr+VCHuf+hYIRTtWNmIIWwvo7q+oGlaopYR3MBGZctJqhuBG+O3cadAks9
qO6ic+pVXADsVw6ERceQ97x8fgFDMeizn8VgshhT5YORf4ezNlmQYgKrAN5igtF6Jyq/mMj2YXrN
yutNB4OsvGBp5igzaxgEQVbeZDTOypr60WOUlTkPPt4GD1m5EUzLmdQsKzfNpiba/ZiVh+uj359m
EjuOlmQGd76mR4U41z3MkT9ASUQBP7k4bjYuQL7fFs3vsPh1zk6spOuLny4uf74QCWxmUDohbeJV
uhKaolRiyUkxZpDXI8qSOqcuMe1GvQWGW+USDQSWOLAMBtvlCRXW00TRcX3no1KecSs4nU/D6Qh2
ZzsPDw9mEGwqMva5SAkVxaysHVHJyAKltJqRVSmJWkZWtSS2MrJqJVHPyKqXxLYjqzdbVCtC7LhK
9QZboHIKsZuZWQ+EGT/dyq2WtoUoO7kCuTXKdTIGMe88QK6TN73BXS2Azik72YNlyw+Y7WQRZtd2
MdvJJqRrm0q7WEXZO5S9Y8kMjBO930K7o5Mj8d5HYYHvFuBwt14yhAt3DiMBafGe6Q2H6+WAc3LR
j8P7ooPgMeo8oG1uql0WuvSPfWaiJViPHPr6AqnGFtCpCem8ugw5+Pd7vWA2R0iM4hvMHVpGpEto
r/io/EnMESs+GMZMUxDFhGFLggesQ0aSpojOPX8tjrKqYUEVwDuO+TBWp0A3n9KWQNfGyOJWrPVA
V1rbVEpPssOQ3R6CMLRLFAnko+9FPoG45JFBul7UJRCXUBLIuKdkwCWZBPLgKxCXdDK5GsQloQTy
twcF4pJSArnVIDusF2sR9Cu75vzWOD8WlV2cvhLzYDSDP0UN1wZV7Mg9/RGkSP6UaW+MEoCb/SAM
JsYG+W4HVU3aFN/tsmCAcPJHX4DsBQKUGTwKCyZ3Uql118u/R4EOEOfqQRMSdy8isyMZUpKnf1z9
aULqLhNbyCuS3sUIozERa0AH+xMG2Xq6GUMMDhhkdb6sctdmtEsGFKRvQe68lDhuZVcj2tWIerew
n/NvV8Oy27XIgcVvKRrIvJhO8BYBN5/njaN3sLHlOQQlxd4JPVW1N8vj94L4K0p5Xn758SCj67//
XkiQH9Ig0A7CYkB9k4IyO7RgaxjDWWRqGM2rtmg9ZGsXAF7FAWr9YEoW8G4KeDcTuJbCXMvGXEOF
JQHsXv4RuJzCXM7GXE0BV7OBayngWjZwPQVcXwK8lQLeygLeSrFuK5t19RRwPRt4JwW8kw1M9/8W
MKVkQddF4qdct1WU6k49paJAmls4KQQl/hKuCjl3pwTZzrVXFfbwoGTkRY+TOahNrhmc40o6p2wZ
ctJCUbOadB9UKx/jpazR+b4jfj6pVtSQM0BhEpoGMejRUfPNOz8MYVnqYE4SfLjj0Od26qnFNATV
xoQ7PBety/MrcXX0ptVJAoPeAzurud688NckFGz07wKpdlLkGfya2szsuDczOzuOts8eQ3887Kt6
r/ir6AS928l0NL15TBa43amWSjGz3g3nqKeJdztvqlKfSHUWFRFuVYzybt0rOOVFtGabFKPiO+tp
ivHrVYaWMpuZOopLWgECL0fUsHBDeLVSVU0NJZc4SpibnoLJqMrbKm3pacOlDSJMvVTWs0UWQfVS
RcO4WMcwVQ2TRXTQg7xAwmRXVtOIXFoRwVTUdASfsmCqGiaTQdt6Lt52zsEIg2ONf+BTBoxfVYyu
ZvE5jOq14ZDIqWXxkGGGBJPFw229Mm3TimROAbQE6PFKU0D7Td2hed/OZr4xaN/BNNEQrWb7KAnY
L5fuzNE9nMM2bhjBEDwul94noX+PpwKE/ssQhrT4y04pa6j+DllK+tzDASEqGqKSmBu2MuaGLcde
4za+rjSA2+8ydLpbYyQ7KYtuNV2lB6cQRsC+aKYg+m4cfozDz4DwJtPBbIEQXTdEEOMInBDVmFLn
UAAIqAQ9eCGEu7VV1RiAcLelGtNRddNRi+mouemoycYihJuOGlNqwDm3Y7e1mLM1N2drMWdrbs7W
/BG3GiDcbd6KW7RVSiyxs1s/ls7joAfLLCS55Y2gUc5MDOHYHE2N/p0/wSjLrWHUE+fqvKLROs9A
GY69eOi4mEkQ9v5NuNdGhNRC5FSRCOJcQbjmbYSoJStzHlIQZEdB2LrjJLIUrQu6B/RHoh2Mh6Cv
9GG7Ng0jgWCOee++vmWy9OfjI1Hf2inXUzrasFc1ppZO8AC7wiZtB9GuClS18zZUcFRN1XAHk5Ix
YV7gOR0kubsIgWNWJORHH43I8+UbaOdizrP0ER44ZfR6z+uSbxVbS6tWQvc8fl6ttN4cZ+wLoZRB
HxXt+r2P937Yj4Q6TBvCFjSluI0n5VJFTs9YoQ8VQnVzX5xfUI6rQDWzQDVdYORHc2nrsRFfp0lv
JBxz1OtBKwIPeix8lCf+tmvEiT9WjooWExAkaZWiD//EVaclZvvxd6z9buyT03v8/odY9P05XvX9
IXyu1CIHb/fy6wN5BTfA5IKQ8a6Lps+fotjc3CxkXZXFNxn9YUTefTw6cCVKMWkynWCqtG2/wFAN
6Llm2LcOMZiDEp6NcopGAWmm4y6hwRH+eoJjbSjHniwXw2Kmif5oGfDfolBi/Y/FeIYnvyCa4XQx
R1G0ccagJsa/LSvWD4OBLHMMHSXgqzwodDcT4SvSiOt+KvpWGbzPT5Vj+aODSAw6Jr3hYGg9vC5H
CZim7tXJFIDeoTDBRWlz0jcK4kAjf4+EIQBJJlsATOZwtmQ3MF1gyM1gBOMRjV3wnpRwoTEA7d8e
2R4Avo/ZiwbFhiV7F4o2q1hGtVCyqiUqakxIUhJPdsPQxiEfLYBgPkvjxvGj8kAb9qhq4miGBTLH
yaiPDWcIHhuQWTETNQyTZlBN09ciiA4Mjt+Ry8GAbCGoywYUaJj5vy+DJvoTLNKfTrgZ3UdxC/1E
lC6IxvimL0bMHII5NJxioMTR9F6bTSQmKpA5rG7cHQUetpaHtDVhxN+AUTTvyDju8zDwx0aC4SvF
k7MSZqJo0m0rMInDrqI5kxA/YzhitOUJg9kIbcuowXwvIsiPBdpjcR/DvKcsFNF4ic7S72Xhvy+G
wEFgA4slfO4tQhgv89EjMBXj76ExFcmDBNZBKoWIMBozB5pEiQqnsIIrrt6ThdE07Mtr1OAB2zcE
vJvKwFCe/+O0LG+RZfxK1XGY4zYM0DhSFgXy736iAroPJr9g6aLW5TJ+SRbG9TRR2LawQABV6IQu
vkG7g3GEw6E73JB34b3ZIioAhvPpZGqmUXPZKp66MU2hBOY/qqLGhIh9g5VvRLOgNxwMe3gpQl55
QaqjYASNCuxlhG/yoiJNIKNH2ZM0btlKCDUwkqNwMdmYD8fBBnuDo6u9pImTnMz67IhPSRmeyUMF
gT+RNzdzkizo2MmU180QKscz+aO3JxcbMv4zW2AJvL5U135j/xFnRdFsN7zBdEqOgmP28MChBRVp
iUdMG+OxsuBEHLPUnPv87nTB4celqENLuEUozD1I9OeB5gyMcRhgj9hyunloDniowf8X12dnHB55
LodoPB+EemaUeMiUkAzv5hymnMw9uwHMWTcLYHs8Kt74ip51+SFuGfV56JO5mRzlNGuy9hIpG0kZ
Xl0FkZVmYAZ5fUnVVMNGcxlNlm6UJe2OgrLHmQpcM6G7NDqcEGR/y/mYCePItRjZJKBot92AbWAn
vOhJnHSZS0uhRDeDRQf7hyLOwjQ0hs3Tppgtwtk0knHhuSfQaAPvp8NgNAQ5fSzSRDcc8NIgsSEQ
dxkvGDA5oUsUzXipAor1dclNNdAuZLTJgWbzUHaDLkt+GBdjLy4py57SUhPg0kNR4g0JUffg2PT5
dKbfx6AqgA0P72Sw3RmbYSKaPMXmRePOaY92MwCCY6tgIutO53NYZU18iIYXORlsFZHJzrZocs9v
MKneRIZ1W/OifeG9a5CjwsujXBzJIh6WsOzdwThKrGWnSrCw21EScNigJRpJsUEJTpMn543j45a0
C5Dtk5qIoj2aLwYDKVGmlBbF+a9GYV1sPlWiJacArns4KZICd3Zy8bbzThWa6H7XFMKi3Vesbl6c
XvKFtLXeaj1SwbXI+STeZmOIW5gB2Zsp9EiJ+gUW1545AfC2A2vy2KcP6Q7S2WVebWIgCxtVpPWB
bfnGj5yi+w4x8aMbNTNnKS7r+Lvg6Ce2w4jDYJNi1sehBQs8dh63isQL1QqEAK1BVocawB3OhaD1
oQVzp9G5biv2mswgtTDZZOwSiciWhbg7ZZ33uLzAPhEnK9VLRgepPnd3k7Wc5NclAdQoi/MU7Wru
zxdRUaR64dmMlYwEWkhBFNi8JCmU48nGOqXgkyvvB2iwT3uIQbxM+2relnP5zRBN2olEJfwxdNFe
MkIp7uUiT+j3w4hUdJVeiqcqnrxpKoD5kRZ+JXBsuo3ShQKEC/DYn/j4cvQeq5UoaBGR+cq+ieKq
a3N+nFhVnHT0SMi8ROGY6DULlAWKkj5GF6a4UUSJwis1jMsuLZBdNU3S81JR5CeoaGCg827Q83Ga
dXAVtKwe+unpk6alGwPclngKvIIhbaiCWSSxeifnL0UTzvSJGUSdo/ifJELiaRnq3QawswP58UX7
1/PDyzNh7L1YfWJAJBg4EmZJAHUFiwGPbNni22EfTaFBw4WVS63BGGDe1tFIVaGHPrQJWczhf80T
mibZTNvgzTDy6KRFMUXrAM/gSIf2N2qV7S7Qmskz5jKbBJqpGWhfJWI3yHJsei7sOVzm8VRuVgy8
w3MEUs1RVwaGk9X/Y9YWe5P20hG+hYq0lu1c7Kbdv/XxbEZO/UoNRv1Z4NZ5hO8naNvYHJh4HJXS
ToGmXFK9JEZ/dO8/RkTvcB4vzLyso+sSXhlglLGxo1QWgLHRdEItHk2nH2VPz4yeJo5hG7wZMg2I
tPoKNgQPUN/9VLMu0t44se57bKVsvGw1Lzqhf09HSub+FdW74MEfz0bovXuQqBdle4cUizi9dwtb
Wcyo8bypUXEreJ+ALQP2fuT94J5kTam0R7/5R3/QGwx6kwNzGdYQGSMP9jTAQrk2rsl0uaeUxpFJ
rhGOfdce1C4eczZWkqew54T+ntEUKR8z4/jnPZKciiTRF2qyhK1APOWJ4/ZVxJslGi/oxIZUPlBp
yWOHPd1ZY4Vrp0bIxxpm12si+fG5Oa1GQaCWuwCjb+J0pjZi8qDpXs32vFmKPg5nM2LrbTB2U4Mg
Htf1BCVIAQBnkaB2nqqk2r/p8ka5YaQNKds/Na+8v5y0Lk/aXqODRvYkjkZyUa8+waN+75bY8OnF
nia54J6e+vlq9k3XUbSxEZ/kLo8nfB/W6EU4jObDnlo/5/NgPJvH50kxCchh2UiYXALcbtJiEZjb
a5jEbyYoaU/2A66HwKW4O36+DWjTnNwLqRkKDxDkDBCoHXXkXFfM0h4V86iI0fctimkUscLrOgPd
FHygD6zTx6KPwVxpRLq3aEetDzU0b3GFGvKsSqfOqD1w5Oe4Kr0j5gr6RXV4TUbffPOgNox4UcPH
fwYGdSwLlZoa5L1mJD6tVHM/0x2lSC4ikRINneFgHq/GKAWlokSRoJ5ka6J0DtXdiIduhRKY9tmx
s7obAeagiWgXhwYZhXIfUkm+2/D6Ac5udNqzj2XfTe9R9UR5+/sCH++BCoK5f4pYvsOFmh4wSm4O
QyAZb6Y/olE6LN60zciXxIFg9bBg1oyLiodzHFPbRpddMLD7ySsPqhcfXMsl2jgktG+W9CdqQQeT
Es8TY9lF3YOnZq69Y03TpA9wY0Ag6D4Glzk6i93XDVY2uPKQ1hobMf6KbF6At0GJ5YDkja5vdHfS
RdF4jKJJayk/8I2EPumUCqXj7E0TwBeF9riUeGhI/pFS7yj5/0dXQm3YDfT9sG8Vx/F5HH+nIyyT
seaGiYTbbuemOg4wFgC1XiYeadq3kFYT1FWk5G/RoaSyfiqfAyIK3kuSZHSHN2Trmcs9hcFdfjSc
zwGMULwMAxp1vrR2MgiF5eKTypM16EsR+PXayyvfLr207Li+c9srlz+teOUTin98adnfd17caLIy
+5TCL24wmZR+UuHbTyr94uFJpnUvLUy2TC8tjBOLH44/cV5BDC9DQG8qXtzyu/DF7R4MJy8ti0aa
Ly5b/YSyowfx0rKDsPrykTGbvVi+0Jz+xWV3P6HsrPLiuQ/NsF5cduflc+7Yf/i7HFGfggGG9Isp
wJeVLy48Hj68uCybr31K8U+Y+sf6qaH6eSGeaFZ7+TAjU8uXFu6FD5+lCdNZMIFd/ounZFxPpmH1
xUu4XFAIxcswzPqzl2tcs799SsPl45VPa/qnIeE3CS9tBD40fHHZF+tOZP37CYVrL552oPDWJ5V+
uZaMtsgvLuu/mOb7+tZLiz5E82k4fiy/eBsIiZPoxZpEdPvyPRyWffAo0saL9acXq23Dv1c+YUg+
9Mr1ly+r1crTE4kunD6wQGs19EPkWYes0p4ay755k122B+uIozBQk6iX0DHVeEBhwauzH5E/bZ6d
WG01iuFDreeXwncPzyrlh1GQVUrk+eQq0RnkAglKhMENGr97aHGkq0GsCfgoAa+QQ95yzBHBFC1z
+/WlX/nzukmxeTKOuBNXrqtdthaUgfZpgBFpU2f0ZBom7RMOT4+LbMbg6/Nyum1QnkmU44AlcpYp
Xmh8N8bblQQJTCfTT/ajeGGAB3noWU6doqtDQMPQlO/A23wXSgfvsXWNP5jT5RkbJEfyionOrzd+
JEtWshqXzTGlyiZsOPeAAmlCK/Kr3Gijqb00LSOTO1lWH7oqcYu9vWiLbscJbAZpobeI/JvAHBrq
0JVuMbqjaY8sWMncbMg1DiNpXR7CUrkY+dpIXNzfssmPeRDLVxxDNHNXd+vqFg+LxSx1XZHzETQe
/mvLjYFtEKWqxkv3+2F0i4fRC+l8MWnGtKlM2MkclY/uiWmKMJtZw/jC38CEOOK5N7YksK29VhlI
xGHdnJupctLjMFxQhNMMRw6DUK5vAmk8z/JoGrjzRRIls4G7Qw5mbFklw9XxPKMb9gT51ID/wJcA
bDRl2oINJ+I2eDAuGaXpTl8+p8A7etAZEDTQh/Mw/G5u0WDyVrw9PiTy1d2/dAMpHySgE7G8Ntbi
iUteXurHEQVHayk04LDnWaZcdmc+3WUNvohEvzdpWVE1pKx9nl9LNFV3numqzNk8UaWa0anCZ03q
5wH0QJ/trNSzDhCzjOlV9a22RiT2yzmz+0h3psYzigiUhoAjxvB7Ftvgz+wlmipTtWZPmPi7aL3k
KOrLsOznH/FaJgUyfoBHIzB4wBtxIBfnoYTDmuZFs+MdN9uNdvvk/PDsxEPjxjz+Kop2p3XSOC+K
U/ni7PT64kg6sslo2PdUslAUeS6Ln5Lv3CxshSco8S4uvUbr6N2/lKIsB6V/WF5J6RPeJn7DywkG
JNA+Tuke9hO8TeNdEDqSnvvdzd5Sj9MW5BfwOr2zvV2z3E7zPI++EHEBW8yneO3eI2Mbjlcq7SiI
MEjBi80pGcnDzmb+DYsf2rvCqm9qevILxYdnX63Rbx/EAb99woCla6U1DmUu1nz61fs7/en35Z+R
/DuryQ8R/R3Bqk8fJgBIyOBTb4xJXfo19AmQwmHC78D/yB9G/GdGf6J7/EOIsLESUw/G1pzSbqlQ
bzSdzvhDKP+EIdXSG8/kn5r8u/PQu73B+OiMaTyj7zITP1eMzzXj8w59nk76/Pcu4KrmWDPj+v2B
8fz+QDgIsB8QAf3ZZM5/50RxQL9m1LCAGBo89FTzVOuChxn/oZikFP94beB3I/7LHTDwx/6D/DCc
8AfN8YFmOT3ooQ89/n37kdH1RjB05adQJjHPBr27ucKD2jpUSOxQX3b4C3UQCCZ12wBG7G3I+Ma+
/POgsIwD0D45UZI6HjLt49kj/+Wik+BG/VXNnSA6RjNR0Gh8QR+mzJ+ZAp75vY/yg+LOTLNnRu1j
VDNqI36Q1M40fEzsTJdUFc8knTMiVKIyiJ1NFDpN6yzszWRaGP09nPNnnajSGBc/9aIM2PRxj0WL
Lv+997l7ogeGuOd0JvtBsuJhIXERI2+oEm4OqK0D/rugP3P+TV9u6deQRfWWkob0S1E2ZNEYTkBD
IJxDpo6j5q6RDIz6Zfmnzn8r/KfGf3YkqlF/wAmDHfm3L/8G8u9MZcxUziySH/hvoFBxU0YkmfRp
6vdZCtXEwPMCD4ERN3ZEv0mA0CJI4hoTVSCXZfm3Iv8S+ePpnfxDTR0vJNiCwSbEjImia8Ije8KM
nzCrJyP+zWlM0YSomDCpEyJ1QuRP5mWFa841sOBMfsff3NfTkIf4NCQ2oexX1Icaf+j3FRr8XFGJ
MveOpz/8UFEfQNrKxmdOh4Gj8cBnnch4YOSU1QfOgnFTVh9kyuxRf4CJoqKwTWc9FrpZyL+nXeLP
LPJZmmbR7aiiPtTUB90YExd8VgBhDKDaoxsDHxiMJXjGEsy//N8lsjCg3goDIi4c0GgII+J3uOA/
NAFSb0W0VEZUUUS1RFWJKKJuiwL+zSMQGiD/yLmcPzE7gXj5h4QCNoUK00zOtZFcUiK5pEThiKQi
YvIintajeVn+qfNfxadozvXMd/jPQP5RX///7P1tlx23jSiMfo7X/RF7fFYmkt1yiqx3a5xnHL9k
9Bzb8bKck5nr8dLavfduuydSt053y5Ynk/94f9ItggQJgCwWa3fLdhx5Jd0tEAWCAAiC4Nve/T64
35aadULXtumTB0J7mP7UDmTJ/mD7wo0d1W9O7Yhma7n5dnsN/fTmYmvBz9HBTCG6+9A8KDP9hk7q
YC8unI2/uDDGrcKfOvzZOEovbPtfvHC/gNB3z2xAYX/gOPv9je154EJ9OOBiASDmYwEfCLyElry0
fv6l8/LO+758AYWgjf9+aRXw3y+95P8bZIS3FbCYDK8sMNEYvgiw++GNB/7v8wMJz/66efP9T97/
8k14n8X+z7wSa09F2tdXDMoXX/3+8edfT1i6AxzzLGw/g/b4yz9+8ZHAHVK4H3zwfzharZNoH3/y
B46nk1V/8PhDgdam0D76gGN1XRLr40/el7U2KcSPP/hCoCXF9/GHAs1cSJNAeySpjUm0zx9/8fU7
12fVO+6cgjHQusKP0hrEj9QxH+ljPqqP+ah6B86WrmrQ2i/06i/qlV/cXG2fl2NffVeC+ljaRrJX
PfpSGHiTtNv//euvTza/NjmyavNg009fqHz1n8h+k+xdn3/8WKAlaz8KrZpD++Kz978UDifZbb54
LNqgkn3/ceRIkmh/MrX+9dd/I2Ls6jfhg4wcf+3Qhwfm4XfzxJfWD3RtHmo0T7A9qCdo3T+opwY0
6kEzFTTtg2ZyeF3/QCkzDtRZR430m+FBZ94XVNo8APsmPBo4y9bv/WdoDO0R2GmW1tH+4ONPJ4zu
Z4WRbtcHn//p0Yf/a0LqAaNNI03D0qdumLN4k0762IgnvA/dQOLR4gFiwvroj48IFpjFFBk8/sBs
oof0ffvO8E79zlTDf775kT0x9NFLd8L/kTnrfPXi+c3mC3wv+95Eb/P/23zwRdff/883zVm+5yab
r99VanyT1/yHz798nzMY97EJ7dHHFEtZE19Cq+fRHgu0ehlN3Rbt3yRvsaszaI8+FWhJvT569DlH
S/imCE1l0CRzcdBk8D5/LMwp4etiPDWL98UXbMAwjm5A0mnDfxRxEIdtBu3LRwIvEUHFeGoeT6hl
Bkt2yrQY/w+VdgPeIoX1heiUbapTauiUcW/8PwdzyyHplBM92ylb2SkH0Sk/efShqLlJ1axMzZ9c
7ky1H27uTV9Z+o2k30v6Qu1m/Bnzav/8UynZZCeLvEkczExYX34ubCMRrUdovUWLxVAbMXxpDst/
fnV+eWWWWYLQJxpWKN2SJ+S1qRmmcNSrH5j3oSsY7s08SHcwMPftg36S5IDDs8rNvz78/RdmpFG5
EI3jpNXz4Zcf+JneMsZMPQRjhtsSGk8+efTpoy/fWkT8YpHhL+6UxlyTlmr5mIU5pp8onSEY0LVB
tyZQF9GPPkjX8IcvTCpJNVkUpKkCzVwsl/kgzfUjZ5S5UOvRxePD1Xfnu4MxBtVn9JTCLKc5g/n5
guofEWtuFjFmKlnsM3dUS1mverRozRRjjp01NOYavVSL3ROyQObTx9bIhkwg/vn/tji5wYvjpOvi
OOmGF+F8+oHB0TkBcpze4tBRrX9H26H9D3b7xebzwxWcpjangz+4fAF3G+EIdz2Nambfy0T1q+rr
d86u6BjXVm+yimFio3PDzefgXnJq+Zw7i/ZNG6tmKN4V/iI/nZmrm4Svzrncu/xgjiWbMcjNzdfj
zNT1+It3tiYHrgeMW+LATCLVJUj6VkiwShN4SjNOkZIhvUTSt0O6YEiJDJrB2j1/ysUZTw4itHSW
26DttxwrjocB65QJIjHllFjpzPUKrD3nK56WAtbZt1xDBWjpPN0qtKe80hmZnXEF3BLtnGtgRpvn
XLa3wrrhrYyn0RIrvTxTjnXgOm/SPZczr9Lmc07MuprH4p5CzVTIPVMBVobWvoiv6yKsmxJJPH3O
lR0nlSRWOvVUTuuZ8L8zWKKzzWHx3pFu4/O/cA2laVEsfVssIYm0Q786Z3psZrC4HhPLjBKrLsKa
p3UtHEDaVq+Fy1nGytAS8qoWsdLJ2RW0rrnhpLFuxMAWp1QkVnphphzrheA+ifTdMzbEN2lSFEsn
sb6AKYFuM9MPhpKO8754/JFByU0swmq+mosE+Wq+mhsIEqv5am5g5Kv5ai7OEav5aq5r8NV8Nefj
2Gq+xSpYzVdz0Q5fzVdz/oSv5ru2xkbNV/MdtXWr+WpWyZnV/JKPotX8ko+i1fySj/hqfs4kZ79Y
X8fKHQMlXEVfrK9j5a6EEq6iL9bXsXLnQwlX0Rfr6yjdL7GMSjdiZLEfy766tLvCoq3YXZGr/hPp
x5Z2V1hFLG6bcNRug0Z3V7gBYGl3hUNb2l2h5obn/O6KjBzvZHdFxsbD7grgR+yvmGUsuQfiZ4Wd
brDfBTFLj+6CmCfDd0FYYou7ICxaPLDyXRDqp9sFYRlc2gWh5mJjviFBzQXtfEPCbCzENyTMxjh8
p8FsdxY7DRy5OKATOwhm+/38DoJ5y2I7CGajVLEzYDZq4zsDFDqSFJY01HSz/4+UThrrC2GodmeA
sCqyjK/oMr5ES6/G50RIVuNda5ZW4y3a0mr8bLR91ML3rOcgi9qzrfTLzfNUCMYyjVkMtriWQfzi
R8ZINzq9IF2AzteXZzkI68uzNOeWi2dpkuXieRy5tKvo2hjtMbi0O8vfo0XLebRoFyUYS8pch5Hm
lK6UziKRldJZqZHVy1k663HSzSIrnBkcvxg5j4OLkfPcpBcLfwT8OY6PxmdLiyUM3fqD1SzNfeBX
KTNcrMUpqWsGhy5RWqyFJcq5sIGtGaq5eSFfDHQVziz5bDnWwmLgbLjHFvAcraUlt9mgkC+SObSF
RbLZyJEtRs1Gd2wxygk2vxjlSC0sRuWxuE0sLSDlaV0XYd2UYPlFn9lJAFv0cepeWvSx3awAS98W
6ymrMd3GZ8K+boPlF5CcVBcWkNTc1IEtILkKZ7C4HpcWfRzWwkKNw1pYXHF8LSyuOFoLCyJqZkLD
ljpchbmljlnPG9YxShy4hhQEx0kcfPTXHl1/a6752h+eV+Gc49gbrkG/Rka6NropJKMCmcYtHhpy
qjVS6MBxwRSn9VUYfz39HH11ysyUpp+GC9UDxEzEDEnLSqNqSFh1JvYt5Esnm0dr6kZSn8ZaNfCr
azNETT97+Gk4rluFPLVgmC3gteUs1a9YVGmWY3aPEWeTEqfujIWbX739NcKvtrK/LEpb21+myumz
xv7q7a/B8a4Hk4M0v7T9ZbHrcgbbVypcJrJkM+6gCd3dmGxLrGD0JmstoUZLKGSp/3FMtg0mCzaE
JlvfxmSHuxFnR7pTJTxAs9IDjD+OOLtgAdAXUfsNav8Ycar0gHGkeXoWHeNU95Rlagee/VUyV696
hEq369g2bY5TTnK4q8fynq6WRyeTdw2yUoNJRA0DVla5nzWRF7p3tAxFLKNBy7DtLWVTDETKZE2B
gVq32GQ9DMDAWKmhnDIZQfx8t4GAvYN00GDzySaRoly+sHY5vtal5XqXPjKtBSvB4e0EAlkYNQx/
hjkjuNEuvcL6m6mwPhGyN5W1mmoB2MtqwgpiRh2xKqyCpDqOE2HHRNjZ1kBLavNjNBQrU7NpoWVW
6dtpredaM3R6mxPIWbGpCLpzSorAJ4glxWuxYKlQSb8+qpUDa6VpWYstA6ECj43vi0fVMbI6ZiRo
DLJTkeNUoykYVcQPiHHQtzIrXXHXBA7Oa6WUiBKOI+X+VxPVkV6stRtBmPYqE/7BeALDiWoggQFu
wxSYwcH1b4NsRgDVukHRMehlDQvq1njB70Gp+d6MRzAcgb3Z1vSmdDDfDo0jZ20c4GOsK7Dvyvgj
BQ5JOXOvFewPaMwPsz1Aua5RG19XGyXWxtvVxt3VGvwYuCDzlXF34Ixq4/BgJlcbt1eDz7ObDtwo
WtcGFzYgGInVxl3UNeAa6kawteGzNgKsjQDtsHuUOdWzht66jmW0YcRvpBrcF6gxYTZg/EDtFkIV
AgWh3EKoQqBWxmVCvU1PlaNz3XnfqcqptJLKovRB8usr6hIVBVdfSoUMQTi6G2qj4dWMIKoybFbD
TEv4YE6r3xSzIOY6IBNLqWnKGzJyKrdpwIpq62p1gL5+2C3lRUXhhHfqo536mx8j7eEuItCDnfAP
c/FMsTZrLcOoaDBeVoMIZ7RPtRg/ETG/MpyZqGGIBA2+hcuo68TMpfRb6W5mLQZbucIqlxNK+fnQ
jDBduH2bOVBN3JYxDhfvGqcOHEJ2WSdi7cpgVt5AS6vro+rWCiTBB4xIhhc7Wy42vXWSIn7RDJxg
YPqo+XE9clJrRRBqjZrqTOL2zW0qpikIFRaMQ/d3YCGNStZ7lJVwhqyVIFOv0lSaH9PprnS01Mna
CdURjrapC51lKT3ifE0UC31LQdYjtBPiPwhXJ9FAKDH9MlUOPcxspl/uX439hS2MlhagD/mlBXVC
lxZcMn4uJ48rDMfm5RuaGYII/wTSO4vBipWGDtJovUzAmFxuLJlbtFKzOlddC4uKU4Mr+0vZXzWT
ZI0zPS/NV7hY0XRc/TT/JUxBQWwBNg1NhVJYKqpOYkOxTSg1lgJDcfZUaCy3kkkvDIXmCNcbjZVb
6+3E/GvwsiOdTJhViUnZNGKpWRWY1B0t4zU009WhKXkD+iV5FZpv02sMBM3iF+hVWhLBGD9h1e+9
xi9I/S2dadZr1O/9wC9Q/TQI8wPJ7FDx96x+moRcNTwsOP+/a/W/ypCylIe/52CvtI0/j9itlNt/
jKiqVBqvMkAq5eHvOXQp3Yz1KiORUh7+nmOE0ja+yiG/lIe/58G4tI3JHZxHSrasxiO2ZBb6XJtT
O0Z+x8mu4yMQyK/Cpc1SImIYWxSJr2BOCmHMKWVhWMlCSe1lNYsRw0pw5XJPX62VYJRzv60Ee+GR
bTuGle3Qa9sRLSrduh3C49l2jCvb0axtx3jn7WhTMwaFsd6axnQrvBWv4e5as3679R30zT4ZUTY0
UiultGZ/M6/hzmQ4JOO2nsZDpZTWbBzmNdxda1LRkb25Ra1szZrTJ7yGu2uNmN8vxFll6+s+zDrS
/Ic2MRm+NWMu8rtNvxzkLL3/uTDWC8aGnwtjQ2o0YPmjUkqjyDkcmwWSPceZ6tqWjVXCSI/N2JTW
qYQMfpy8yx2MaKNOjWgsR1JKqeZx69GZjruygyY1urGsRCmllkeyR+cW7qplXWKkO85uex7bHj2b
v6uWLXslcYxqILavsAe4bSHklKedBedOepZyeFfebl3+Y915VTfHdynWeJ5ffIztLl1pHIWUKu9O
FKeqn8ZHl+fG11jrci6nWCzLA8BP3OVUdVcjy99Fn1setn5yfdzVePh3oY/lwfYn18ddjeJ/F/oo
CBGO3L3gNirc7UK9qn6KiGF5fHiVO9OUutPAgakTt6fcYkMKbxq2eU3zft6hRFmHe1U7U5QqiCh+
Vj1U/RTxxU/dQwvCjJ+Xkn6KoOOnVlJB7PHzUtJPEYn81EoquDzniImuDQ+PDQnVEdfnFI4uLm49
JvibCfyKF0WUTl6scyebVe/KHPQRd+iskPyRxn5XkQ+7xaG0cy+3Uq5K3c2GlRV2ddsbfWbuQcot
1Ky9tSi5KckeRobDuhrPv/UriL7aq+A0HvTuj230mp0G8vRyZjdZTzvTWp76hCJU08C1JNOv3v4a
4BdcAjP9UvYXzBE6sOrpV2d/wWUnXeOy5uZPi7biXgBFbzU4UpGutzH2HEOERc4e3vLXdGNjf7X2
l6Hd9JVa0QJxo4KCa6zh3mV7DhdFXVe1+dHQI7jFF3etvT8hVZmzGtZmsPaj2l2vHy9yZi1MutwF
0psUGB9w8bpVRptjK67eiWgVF8QRA4UTewMYzlDCuefaR8DVYEe2Fd2F3oawvBXL16nDpqw1/t7y
dpSzoVcroDxaK5NSf6hSJhPW546/NlbVq71zcS7RRb+ZkLKYybvdKPZKp0/1ei++INCWCzR3Y2gx
k+unFgtMdqh7p/XqJOi+Qd2vvPrw6Ity8pLsvCTJzGfdvZUrG0KGh/lYu3j7V3o6UcyMZszYq35Q
gsVE6tu0KNR3Z5sOVLNiNMjVf1TdxMFDqh/FCvblEyJH3VLY8DsmHXk9plvXG5i9DK9dZKB8RG/E
rZOOg8ytk8vc3PJ6D0VPzhdMYMt1vkIso9SNIQNXqPbH3p+qNQrlhN2X6q/kUvYv+Ay+Mx9WECbA
NBIiehsHnNgjAUAO9tTDhvSwmTtsSQ7becNWWLjFFa5xtamI1mnP+k5wjta3olwrSIu5SK63s9nm
WLunJ+ONHBZvppm7m1PIywpjUWal8rIxxKLMkvJaGX8GifIA/TjxqvQEGFz29Kuzv+wEGG7cbFq4
FW/6BWWttjPMxv2y82Dk3/zZW4iddloSXT+uYHFuMiN1Dlmjpjz8wxl6xPmdcM1OmtyFPB1XKNbj
OaOrRUFor0wQ7YyFtUwiI5FIM7hfNtMCPE6/rAgH+8HgRdEM9tvRfjRa7NGSH7uEiKve/gIttMpq
QXmLaJVFU658nNcL3GHbQD7a/LJytMmjrg3KasdlkSr7yxLsLYm+Wy/uuXncmstEl8Ox1ZLgUsj6
hgVJTIH6sMbDzc0ZfzECKZbE8OOFKYWSNrXZ65qZzC1FGUuU58rcWFgsGDoLNjIxY6uZppoZnqFt
4tvRXZM8cWV0ahQK1yVPOEadpmUmQWyyw6aBeGjZOH7j6gzXRq2Gb9Mmo024ZtmcQsSNFaZyDXPU
xmYlzQ8owBADpqcwO4XJKcxNYWoKc1LDjDbcaMOONvalDUMaXgvoIAEHYyOTsQKRwV3NpRLrUlPy
bkbdsNKjcl3Mt9u2MW77ke0Gcom2r1z+sLIhE5V1qTV6nYFhzQxNoG7IJhB+1j9C1SViI2/BHbFc
JSzXWa232PokWKpzR9JiwVLbY3UMcpMNhgjbmt+aRHihbOpoNu49UpiCNinxH/kKRMMrdLnd286S
bZ/wbM56u7XcytvG4eU1WJaF1dgaRiwYgWwYBlGQ+QFjFKjelBrTUjDKta4Dw1X+CgY3axcwfpgB
hNzbb76CEc1e3t95AYx+XHBDi4tRIWkEIxAm7ukV8036Onl3i3ztbow35PIXxkf3xGt3RXyxWO8i
/kq1DHjPtm5Vy4Ccb125L2SWtzIU63ppcoM3OY0mF2wkpehEE21L1qioNDMfTygLOTlSnMUNmMva
W1EqFCXEpcHubD/Wvh932I/tcxwKe692fdk9zuElY3u0d/L2TQ7o2wZFPsyBvVe+0NGhl7M9Xbme
HgTtevngLCAVFd79YNHPrTGkREoy26G9Ib3Nb3uYSePcgtXEIjOM0RMN40JN1UaYdsFXcddTe7UG
WwdXXKO6gkvSRwRKoVVHBEp9IpopbZnd1lB5C69pa61dxy0+trVy8re2nSQyMe3qcaHAPjphmIDL
sUGwNmMPgdOKpYg+sQxiBm7TflOdGWEHF7CPo6u1IKqzA7LIruYYzotT7hU7TpyJjU+yrbydJtGr
IBmUbbHsELdr8R3uH+tTT2YqbfNm2ubNpnnPijFx9gqWdVkS2XLX5szQ5/hcK4DUPt0Odh53kIbv
mhXv4ajZC1xedestmysbP6Q2znba8No1esXOmdmbXl59s3Wzvtmptx47SAB0kAHoIAXQQQ6ga2w9
piVDs2Y70eyFMa9cKMh45xmHzWpDM6zvIENqh2kHmZFOw6y/qVdE7sPc3tJXbynwzcrGp9xjBxmh
id6KjOnwU3lFy+baZqecoqpgM4uqYMd1MamfyiE6Ple2nF4TgwEVBIt1JrCCN0cgaj0uxBoT3jMK
serVYVZp0GHZbyL2j5H6WnHrpfjVRVhtLkyCHe5rNriPCc/8U8Z5vgE/hsjntjW9ug5JJ3MuqFzL
9I8/alCmbTy4lue7WT89nmc4TrOS5x9/mOI8tzZYWR+mjHOpuB+N8yMsZP3YmNqZcjzPEL7Zdb1V
nOtq/UbadU/CE4dhw461DK44P7FoBAtn0oJAYW1hLadyCBzJ+DPgGGTqg/Oinc8JQiy/Yj6iq8So
Z0Y7qNGEF7gkV1V82FvsRjDsycFu4INdPRtV3HVWTNPLcqhIB5UQqwJnE2Tbq+MFnBilvIDVvJDr
JUkvhBVe0pL3HyWHpOldOEzcjW2uD1tnrBlCz75NiL38+d4qMXAt2HbhwGBtW8i5TnD8I9n2UOgu
bLQKFgU7T+e8h8b9b3rFApyuEkMXyvs4HyLfAM/6EBswD2ud9VESV4mxzqx49VXJkJJbDigdqNcy
fNTYt7xucdfrT1rNrdLIFZqFZadcpz1+2WltY25/WNx6EGCs9pNBK/XS9d/sFQCrj39qlZgsJjW0
oBeuiXVNWquHzCAcPFPprMB7oLBkvMrb36Yhifnj7Bqm2U1gFzJB/XYHDqxrwlAH23Ba127oHMtL
nUvLnD9lXyOjfYtngP0wsX73m1aJ2ePPW9akubcS+ApfkBjyzV6u28rJisj3xwU5dUvCSs1Ffsy9
B5reRoMhAjkqtt44dfqw548r90X75KEbbfGPJXedFNMtTdRKCbvzrU10btfD8fKC7niME6W329CN
9j9ru/pxXR69XSfuynaDb9er8qUeTa/WqahcA9mhfFlR05twSlzDTzxqiVYeHUCt0GDPBNS+llFC
Rvzcsz8bHOwynDBdZZzj36Fx8qb+CNKvE+FCwiMcEzjUPHCo/058/NE94JYBRK2luErcxSsJIVYG
uLeU2NEhRJ2+tOO1daVkteZyqbmEUOGSWUkSqJDr9u/Qh/8Eyu3WDaFHefP+71AVxw6nt9XH310+
Z/W8pk33dqBYfBvqWrH+A6WAWmp+x942u1K+TT519AqfmtYzN4r9vQzlP3vN/gMmp1oaWf5Ycq7z
Pah/hT0o8z48Dvctjmxrqi+fSzapta9f3LCXCHVx1HulppVYj/sFD35yavhjdeB+eQg8pjdZ37au
Q6fvA/yFDok/lb7TScJ/hIGxdMpeJO3yQaJdCDL7H6+HtSuDzp/FlJbOZqMEzfr9f3eYrEndbzgr
yzUdAyRQfOr9Di7A1W1qr/KP35Q16rzFfpb2iNxgobtxjmYmW/BqHc3fe+7wVr37FSVk2+j2ZtO3
YKmiu8Xte8C3aTrcbnaysXdXnay5MNhw42/AtTk7OJptu8PJultwxQ24lj0jrXALbnjvYfY+XHbn
HygMNptbarD5+fhLunTbv3pNtCf84q9q7Z2IdlBWkdWX6lHo0Kr1eD0KHdq2Glx4Q6NMj6tO59Bb
o0vvO/tf+8PZ+cVh89lHnzy+9+/3N/euz//7cHk2/flb/Our6uv794WJXN9cvdjdbM63XfPk8vnu
cn94MpnJ4WJ/uNj98MaDy+fhn+eH62A7f7UVmQNh90/gXNiJh1QWMrXnbycct7YldcDVFqJj3NaW
tAG3sZAmxu1tSR9wOwvpYtzRlowBd7CQIcZV2DjSOuWapxLtU66BirRQuSaqRBuVa6QirVSumSrR
TuUaqkhLlWuqSrRVucYq0lrlmqsS7dWuvZq0V7v26kR7tWuvphpFlSbaq117NWmvdu3VifZq115N
2qtde3Wivdq1V5P2atdenWhv7dpmXFSJvmpXZrq7hzmZGT8Q4bu2GafgYdgJ6gS+k0/dFvLj5FMT
+dROPnVCPrWTT03kUzv51An5NK5tDbGHxsmsSdhD43htCuXTOFk0dZl8GiefhnoFdAsJ+2mcfBoi
n8bJp0nIp3HyaYh8GiefJiGf1rWtJfJpnXzahHxa17aWtLd1MmtTPhCdIGlv69rbJtrbuva2pL2t
a2+baG/r2tuS9rauvW2ivZ1rb0fa27n2don2dq69HWlv59rbJdrbufZ2pL2da2+XaG/n2ttRz4+u
P9HezrXNHJAosbfeta0n/qFzMjOn0iJ817ae2H/vZNYn7L93beuJf+gdP32KH9c2MxPxMCczEz1F
+Dgw9oXtdW3riT30TmZ9wh4G17aB2MPgZDYk7GFwdQ/EHgYnsyFhD4OTz1DoPwcni6EtxHfyHLpC
fCfPoVCeg5PnQKMNDDcS8hydPEciz9HJc0zIc3R1j0Seo5PnmJDn6OQzEvmMTsZjon+Nrr0jae/o
ZDamYisMrkh7R9feMRVfVRhgVSzC8iFWKsaqMMiqaJRV4TBZpeKsCgOtio6sFYZaVSrWqjDYqmi0
VWG4VaXirQoDropGXBWGXFUyxvRBJpWBDzOTcaYPNFmk6UOFZKzpg00WbfpwMxlv+oCTRZw+5EzG
nD7oZFGnDztTcafCwFPRyFNh6KlSsafSPjDSZaOFwnBV6cJ4Q2HAqjSLyFBmqZhVYYCqNPEq83Mi
hQEqZJECFCVvYt94noGS4ZErSl4nxiaFgRjkqAr4wmBX0Wg3h49SodGuqv2UKCVfDHgVjXhzdaBs
ayLb+TmkwgBZ0Qh5fh6pMBiG+bq3KWdSKXyUeF02n8TgGXIAwT+ge0h9gVqjMXjWZjGoVjSqVhia
Q9Yx/sZPOpvyb1AXTUe/QY02iXhEYUCuaES+9A3qpBmKecMgHO5oD9+gtppU/8BAHG6ADlCUf5uI
3xQG43BhdICiBtqUfjAgh8x+gPpUQEoGGNgrGtkvfYNya4eivoWBPNwOFqigzNqUzDCYhwRegKLM
upTM0EXDyfIARZl1KZl1PslBZYbTBbiGO/4G20+jfYVTBsi8xd9ga7uxSGY4QVB0hpDDR8n0ZT4Y
JxSKziiyvR+nFIrOKRROKlRqVqFwCgEZ2NJvfCqKWiROUOCe8/gblC6dXyicYKjUDEPhFEPROYbC
SYZKzTIUTjMUnWconGio1ExD4dRB0bmDwgkIXF8Vf4MyoPMBhZMKuCoh/gZlMLCcnE/KpWSA0wJF
5wUKJwYqNTNQODVQdG6gcHKgUrMDhVMBNTZF1onTCTWWjd44dYA8fgk+ypfOP3L4KMWxzOONPj1a
1Ns1zktgzaEEH9OpVVFv1ziz0XRmo3Fmo1MzG40zG01nNhpnNjo1s9E4s9F0ZqNxZqNTMxuNMxtN
ZzYaZzY6NbPRGNhoVSYv5dPPZfLC+Q4s5JTgo3xVYfyvcXYEq0RlX6A+VFusQ5xPaVXULzTOpWCx
KkBRqyoxsmmclWlVZut+KYCtBfjFgORqQEj96/JvUCd0TraeL9RTchXBLxnQGZn2ixE6ET1ov/TA
1h4WvkEZs/UHvwCRWoHQOCvTdFamcX4HS8XxNyhnOjNb+sYv1dTl36BU66LxQONsTtPZ3FIdKGc6
Q9M4z9OpVQyNszTNZmmZmb/GeZqm87TsFzjv0nTepXH+plOrHxrnJJqufyx9k64HtdWkfAzOl3TD
1tH8QlqyPShROltb+gblTGdeGudw8Dxd/A1Kmq6hLH2TrAfncDq1kqJxXqZbVdw/cYan28JoWuNM
Trdl3gnng5rOB7N21vol0cU+YwbRP33yyUn4I6aGcqbzRI0zTo1rQIm9InQjwO7y2fOnh5vD1ZOb
7enTwxsPBIBuA6heTtzYHyebB8r+32zYmH4Gzl8jZZDG9u6wfh7ta80EImB1aSx4BzZgqaGkRtXp
NFpvjHuZmobJAcErU9GPK1ZVEywDfakYFmzJKqRVNzOCaComsLqM2l1izXBWhqUgh0pkpouU1BR1
o0aVYA1zooVB9scV7TSy1kV4MJz+uKrSMOCWtGEoxWt/7DYchfXjd6nb2RA8Df9z7Oyl/KsjbFsX
eYQfH6tQFjOD6ySLoUQWkxcd19da5h/LaM2O6MLZ1nMNEGFEPcObeVi+ELFvSxFF1TMtmRDHQsRh
KKx6LGx1WxW2ulWFrW51U4hY14WITSliW4rYlSL2bMiZNDWLyDXTzqmwHZpCxLEqrHrsyijCObcy
xKGs6k4VNqbTVSliV1h1XdqYurQxTWljeIyUodiWaqYrNLOuKzSzri9tjDTcmZmR6gYh8JmAekLs
ihCFA58Z9eDdv7VDy93NtcoGqY4KzUDdjEwpHFR0AnGeXJHE+qIGFGIVibUvGor7maGYY41lWEXi
H2eiHIE106kEVpGGxiINqaosxKmKIj5VFTVTVUXtVFVZQqUqa2lZokSpIq1Pk/cytDK5qTK5qTK5
FSaiVJncdJncujK53SlaWW+/w7RWWaR/mwr1wEeTebTxzqrUfNY5j/aKxPrKkfTAc0s/D65+jkiT
pJoytLYMrStD6++uAV2RMQ/dq/IRRXHKWJaf/ZHT9quRzD9XpfYnVd+Z3xISncsPjTJrMjd9GMXM
ZS7Trsa+4hTn5hmjmJtnEJtCHvuulMehkOJQFVIc6lKKpTwOPKnUzs0pR5Fo6OaSIeOoSinqUop1
KcWmlGJbSrEroviTeoOhKNb8kZlSuixQLstjF1ObCeJVN/BUZzOXCe5E8jSDOBYiyhRdUVz984hF
lpGUu9aCKmEOjXc6OnvDQUyHKuHyLUEtg5aaC9Y4HDa2NdCgLJ5K4mG15l6NvoG7d0xyr66dF061
BHAN1oQ7FuFCK8z4V4ALt/6Y3ewFuHD1yljGbwO4ZfzCVUNVGb9wx5zZU1qAC9c/mQRvAS5c/mJ2
ChbgGr21TREuvG3ftmW4MIBQvTXjLK6GwaYJuO08XbjPaaiKcOFqnaEr4gH0ZsbeArqgt3EowjV6
66qmiAe4r0eVtW0E3K4Etwd/q3UJD3A3VqeL2mZiSNXVRW2D67a6pqhtxhIm3CK99e46rSK6HeAW
2WQPeuuKbLIHvfUFbRPuOZmQhwuK4HaoxgwNOCykhg+LCp7MUFxGBUdmtlAj6jwDLYzJqgS1A9S6
BLUH1LYEdQDUvgQVxp66pFmwlNA0Jc3SUNyUNEuDthrSrFQwY1FBW02fRkVTcZHDNEgSA6xpsGfq
Mj/MBWN23DMjGlyPdyLWZCOixocuEwVGjWsuI9rrEqJggMbHFBLtCGYq5AmYQynm0JYwCuZvlpvL
GB2L9AQdZSzVU1sV6QkCg6pUT60q0hNEEKpUT63pK8tEIdQwPbCMaF0VELUxCVyGV0S0KSCqqhpG
+HoopdqWUQVVNcVUuzKqoKs2SxV8WQW3+blRyNGlzkdX038W3f3lPkGGdPQJI97gPoUVtPt52n6O
5KhOyG12vkIQu0XEqVl8Q15CEQ5vyDc/II6rm48SW2h+U1dlvA7z9ChiUzerWcUdDIusDoWsLlgV
stro9ax2ZayKrcTzrJZZQINbW1awOi4oLHTcen3HrUs7bncE42Uytv1x7As7rplTlSDCpUZliLoU
sS5FbEoRC90V3HdUhlgoR7gNqQxxLERUVSliqWZUqWZUqWZUqWZUqWZUqWZUqWZUqWZUqWZ0WjPS
ffTr3ceC2wvuY1hLGy6WKnUfcKdUmSiWDUBXZvJX4vWbeRYF4nrP3JSFPU1fNpjC/VYlI9SwejBV
GHossTqUDaaqLhNrgyPjGlYLpcrXwzKszo9xnNX19l/at3TVru+4bSHxtlrPeKHl2v7YlPrZptTP
NqVesS0dr9rS8aotHa/aUnfVlo5Xbakc21I5tqXjVVs6XrWlmulKNdOVaqYr1UxXqpmuVDNdqWa6
Us10pZrp0prhYxPuJYKEhnAFle/i/k/3UenIhydB1lFf40G6UqvqS42lL7WBmWyDkEDLJNAPZSLg
A0uf2gHvMPuj6A/z9BMNLbW4vlQZQ6kyhrQyhAzGI6wMN0It2nB/TA/p14SvQ6mPGEoVMZQqYkwr
wvjLl2bMd22H9tslqfbVoXlhNj6kUJA3a2eFWUjaa9QUV9VsUOMFBPX2ywlAizcfTv00grxTNN5W
rW7bVirjupqdv6w2Gm4zur5Tm1HzNnOcGG9t0kyMSr8qMfZ3K8ZMWvkoMY53K8bZKeotxVjfutdw
Mc5Py7gH43tK5z3YOD9cCcRVqQz7yXw49/MaZuq7HWYwg7WspLFISQrHrZ+/IG/dK5kgm0JrV3yj
5Lwg9Xza5uc8EB/lIZu7HWjaV+Uhm7sdaNpM4uooMd7tQMMP+tyhGFt1p2Ls5n3YUWLEKyTuSoyz
edrbivFuhwKczi96sLpwKGjmhwKBqOYVmG67yixr/LyGmfZuh5l+PsTnSkJXtaikgjUXyl+X5e8n
QbNPYxLExeyH/agwnFS4u2cd9YJVl7iJQ+rw30+JpxXmDYpzd/DVwPt+OjdoMfVR9Jsy+j9vu8XV
xlWWVbKPBxDHY3pFZpLlHYwOTbTuJXkLw92g+SbBHnXDVAPb5BuLmtx6aHFhk65ZOSjAhS2tsPV9
EddY9uQ16yJc4Hcs4neAYx5VEb+DPXJTxq/dBDuW4MJDyvCodwGuaVtrxqsCXGhbU4YLbWvncL3Z
uHG1Hxfy0h5vYenK4y2krz3ewpKix1vIcju8oaoK8VQh3sJyosdbWEnyeAuLiR6vTB/D0nYxj1em
j2Fps5jHK9TH0lYxj1eoj6WNYh6vUB9L28Q8XqE+ljaJebxCfSxtEfN4hfqY2SAW4xXqQxfqY2nb
lsfL6wP3SE9jQl6ABDEvwYDY5FkkiKU8LmxQCYgLG1SMMoYaMOsFkoCpofK8BnHRZCK5IMmAmN9k
gEecIVhqYdDpboemNM4u7obea7TXaK8CrX+NdhTaz1mnP2e0n7NOUymE12h/32iq0C5f4/2d4pXa
wRye0n6zwB1RfI33Gu813s8fL3Vnymu813iv8f4u8HRqxfI13i8HrzBR9xrvNd5rvJ8hXvJqz9d4
vxS828+8a9zh/FPPBF7jvcZ7jfej4f3cPdtrvGPx7J7k4bZ4qm7sPr822FY9t4gzIdsrPpsyZPMT
XkIuQTYocCVMCbK9FrOQZ3vdZSHPdgdfIc/2ekpdhAxXmLe1KkM25W1TiAy7A9tCZKPBtitENj9b
2KvpkNu5kHRCbgGZaLCd3bJR24vMB12GDBo0mytL2AANjk0ZZbgTu6qKkOHi0K7qitiA28w7VdZA
uM68U0MZstFgp5syNszPri5sYAvIhQ2Eq7GbwgbC3dhNmQbtpeZtmQbtreZdmYnaa827MhO195r3
cw3EnU+13XxsPlvaX+dQG/iZ3xJnUY3eJtQSqnY7l7t9O49qvOf0sy1BHeBnfu+XEc8DaP/S8xAB
Md16VADedaVhl7Q7p1OnslkeE5xxCtNX7jFnrmWSJGH4LKoaNlAXVT1zk1Fp1QmC+etQ1rcFOkcZ
5ozAI8wGrppOYBrezQ/GZWX7WpN8h8R4Bn8ezWFWqcvrKUmHl3zMzFHkT9XoupDJbk45SuH5UIuZ
vgje7ewcFy4Y8nhDvncbPAW3k40zF/RgW5AifeGBOcKBnFnxf/uvTPPdCaIZ4gruPuvI4yMp1xka
lvZFEbtNYDd1QVGgl/aYET16V36WQRNOlGho5qBCVHFPXnAZcohG5SlEWbOqFs4gEMT05nNZdV+R
qsdi4+jNmYQu/irmY2bTf8QHee0m+XwroVimJVXN7JePqq5J1apcBCZu7+KvYj5mgoCID3iowfGR
fKojUMwP1QFxJlKIqu67Mkvth6rUUuuy3t6Tp3XSrTZuwLq7BdsHRG0cQ9rmOGJtKKY7CY5tFrEx
Ls70kib2oJU89Vf5z0wHMTFd7EI5+c7gtUnynOHetCxt+5ziYHxoYDipJkAcDcX8Rn5ANPFM15Lz
ebNMduAeFwY6QDR6mjkYxuuujSPtQt2pnJjFNIoC+0xg8spb8JAL4yxgdoCZNmVee2+8Iql9LLMT
Mw3qTdoi500BcQRW0mMeY8XMf3oVRJb2p4Bp/WSBvuCcaDVzUonXXhuXSmpXZYIwp0t74xVyPhUQ
QXszh5I4K53xquGs6Lx/gVedKp0/sGUxB3BuaQ/Dax+NY20LLNcYbd+PBZY7WNda4AVM0qUfVbrt
g1fCQFQAfhuuinVszDktreEANNxTu4A6QlYHLoF1fKTuawi1m04MbzGZvjxfPRA1PgSuLBa4XmLR
Oegh6biORVPJCVFj0wqGN+PfYJ4w/W8eE47ojklMX3eDM5KFIdDhNXrBQmzNhj2VrllgwiMyqozH
mbojHhfu0g30Fnol4s0cxeMtgZeb4FXDpTbDc1BNWoNR3QuH9nybZ0IYUbNRSVdiO5A36QptZyl8
cnjtwrHaQK9Qf+MyPaUhBaUXToo71NF4ETcmG4ZTdyBYVKMWjXHjAir4pqU5ukVlmYk2OboaRIWH
Oi1iBk8V4uk5PG8WLvembMjk/FSb9KQT6mizzDBILeFashBfIWpqY6ElC/loGNGWcB3ZpogsZK7h
oogUrp9a4EUxcKV4HQ87nmhvjM5fpO9oNqk3Gi0qXhSSzQxhTmgpL3QnaMgfXtCmbNJBZZQZUCHt
oDJSJ6jtDCryiag0ZUcZxaGe4uFjxFWuRTaVnEDEmsEqJvtpR9/PU+M3oGnTwduxTSFixQ4RKIbM
QAazNZgheusSJukwzVyPJFwybPYGsy5g00z2jC9cZtPMRau+gE3Tx7tqLKBpDKgz1zXEk1ySO/F/
uo9MztDMORIz4+T0wH1mvlBt8rNkosZ9ZqZWZt4Sf8ZFbiy8C++apnqOQzRarEOuJoNpqq3DDCCV
WXGYRo0kD5UKZx2mUSN5fHReOSY46OgDzhlU8xe9TGbeOEwn65oxTZWxauTZ+p6WnNM4kkZF7j0J
iSn4NDTp64cZVKOljtwTNC9808vZi74ZVo2e3JMNC/UbPdFnrmdR4WLyjl6VNMtqDXZNX1SdZRWm
Ct3gXWLyFIDDNOQH0v4MKuRYSDYmNf46VKOrYSiianQF5hpjzvqR2viyDswxQX/ekcDd492Yzrhk
PEltPGIHZhV/x0Vvct595a0kuUHfYRqXRB6Fz6GaCT25oEqn1tgcqknBkPdckwkgh2qyLsr3veRe
ZIc5/ex16Hs5VJN30STvkkoAO1STNtNNEVWTKdNe/gxz3krM/LY38UPiq5yVmJb2YQmsYGHAfWc0
Wuvkd1z0RkB94ztocjOYwzT6bIiQMqiQRSPZNz0repN07pshTZWxanTk3iTK+xwNmH0SU/BplNmO
Je7RJNF7euvcvHs0+urpK9bzrJqRvu/SwxOv3yiz72aW8gSqUVQ3k8gTrBpFwYPXy6waRQ2qwFBM
Wq4fZpaRBKpR1dCWGIpJLvRDn6bqUTsTspuGtDVRa52MJAAX9rM1ZbgGo23ncL24cLrSdsFam2TI
FzCDCbTJDhAwuzwmvMKpKth3Uy++cGZxzaxyCMwmt4EgrsmQ1MPSc1EWdwS6wwJdN7XU9czWH7SY
gAlLJzqzZ4UQXVhZokTHBaIKKOMl104JSeNW9LZQnF8mPRu8M6rg+eIpqA72kkGtAbVfRtUwoi3d
2+dQIfmycGUboMKDQc3C7itENVn8ZuHCOLwotFl6Hs613+TmR7egvyCqFlDrRVS7e7mgSRYxn3J0
ErVzsyLh1zColggfHo/WY11kKD2glhgKzPmWHgZ0qLCvcuGuQKt9M01pZvqfRDUrM0s3eaIC2qUr
K4FmbaaT06xuWG4/JIenad2yTdmUc6FB18PCVYRWohAnzTw1JlEhHV8gfOv7Zq6IBC81cswwqLXR
Lb0MFTaGpVDDreewyb+yA4X2/q9NTSrgUWQFSfzJpxkf1EcKkLgt4A5FuCM4AFWCa/JNE25ThGt7
YRG/rhum+Q1Ka1C+7YLBBsQxj9iCLuxosWDZFtUqQReg2uT3kslaVBiDlkzWpeCbhYssA+LSc6dQ
uTbxfbP0jinS1GO1IPqAWCB6DccvFu76RFSYJZc0SdmNSgXynFBhr4wqQdXWSIvMZADUEjMZYfN7
EQOQ4156SNZrf2ExzyO2S5cvW/E3gFpIcxpSusW2O8SFsddWDh5naeizqMbhDEVNgmT80tOODhXG
n6Xow6DCW4O6XrrJ2OHCAqnyIkiuejpc63uHqgjXhvU+Ap8ZV9ooAP9x8DqcToxLo07ArBfGBsQc
1YKDCohJBxXXPdalXI51MZftQv8IiAv9A/bX4IMbVSR0idiXIg5ziDjdd4j4wrpLTtRNBrVnqMnV
UYV3StvNGjHNHGJyWdav7S8s3ybwutReKYbnnpdQOpViXqo5SdGvtKZfn4goToNNGWKfOsBxG7z0
gxa3aLJO6jmBeUs9I7HFa9UJZtqdByZ1ZIzJjXY/M8TkXoufC6J2a9rJ521+YsQRH/hMYZpxBSaE
FhOTZ1WMGSzNTJYUf2cy6Z0BUeNDkzFi4DLelJH2owyxL0UcC2t+9XhMNMI3JteoflIGp1GwoSzW
aW/bwQ+2iSztzBrrpyA1OuRjCocKk90hHyQBagWnsZbySA7V5DuXJmcWFU6CL4XHDtUE6EtvbjhU
k0Vdys7hSZZpcrosKoeYD79c5SYztHDSx6LCE7H1wqlgX30983ZDjDhzflfqHlIyushMYLKrS8wE
FtyWcg0OFbKdC6OuE5Sh2hUIakI1eaNuYR7nUEczGSoU/zQ5zeeQCWK7LChI+kFqbplPuPCiX5hv
eu0vLTV5xLFA9HUF3qSekZL3eg63BtxcapQgw7JE36SRJRctbPPNpGcJYT9PPJmf7uLRhcn7hfPh
aaIBc0xiBla921cLvSogJj1KXPeoS7kcdTGX7YJBB8SkQYe6GxPZ2AMjpvedRCFdoNlCxMIG5vSo
Z3JGo03GhjRHmk/AhFzskF+5wh3G9dKTW4jY1AWI04BnEkJLz185VNjmu9TtLSrkYgtQR5uMrErE
BLnIallMk3s2glq43QJRIcW6NN5CwGO30ZZIVcHFBEvLptAquA5j1AXtr8Hp6EIzWUqEezOZOd8p
xWR6ZlskUdhWOHN9hEQFH1eACiub0+hUIiYwkyafsnbVQzZ2KdyxqJBiLekmsGhTF0kVEo1zmxY4
qq7gNMDMO4TBnVlcyNzawCM3lllkWDaDy7QSyIILsxKv547hCMK4LSK7JIgvHGs4PZgdJQLmwlKc
xxyrUppjVUxTF9PUaZpBpB6zXbDWgLjQ+6PLSWYGKLhJBG/NsZgz07KyIyMJvC61Ccrj6bHzfblL
8xgwVRnmeh6HLI/r8cZkCrPwPI1qK4vTmjUC93RvagM9QeySiIn31sMnQ/KTxn/SyE/gFrPEJ53/
pIs/0WUt6KpmbQvgnrS1LUg3OtcClW50Y2vgqH7rbXQaxaL7P8k3TeobuyPYfhT+Jl91ya9IVSpV
15D8KtJFHZQ2FOqibpKf5HRRd8lPcrqoh+QncQuawI4qNaemS3+Ta0MzpL/JNaKt0t/ErWgJR/n2
wi2DCcxce2HDbOKbXHu7Ov1Nrr32TEpJK+AOv7WtmGl5rhX9TMtzrehnWh63YiCYY2Erhjb9Ta4V
Q5/+JteKYZypJ+HN4GBWjJp3Z2Od/GjJn8HhqsRnCw5t7NOfSZ30VZAVO5CS0UlfjelvMjrplUp/
k9FJr+r0N3ErFOFIFbZCq/Q3uVboOv1NrhW6nakntqxee7XFB2nmLKsP9xklztHMWlZfq/Rnecvq
6zr9WaSThshKF+qkadPf5HTS9OlvcjppxvQ3cSvaUh/dt0MaM9ferkp/k2tvp9Pf5NrbNaWt6GZG
1mwrZlqea0U/0/JcK/qZlsetGAJmse0NTfqbXCuGLv1NrhXDkP7GT4ZasrfKzWTr5GzNxDY9vuvo
pmEZxGYW0a9it24epuDwQe1kzW6pTuCaOKYUFxJKhbiQuy/EHcv5batyfltVzm9rRodSXNjiWojb
rMBtV+B2K3DhUJzDbfO20/ZEb+ze5gTuUK/AHct5GNtiuvbyh1LcvpgHuE6hlK4ay3F1W85DvaJt
9Yq2NSva1pTrDe4mKKXbldskzKBK6fZzbfMO1Y7bLSxMLOSmHaq5lG3mylE/fHVuiNADeLP5e6YA
E5KnE+qYRGX1wz6AZmZjm+QUFFAVoRqqXWmjRlgTX2wU5Npt1n+hUWZ7frO0imIxwVAW1tosJqxK
lQkKbuZYWOtyqGatr0/LNCGoukT7NRzmq0u0b+g1vVrm1FRfdwUGDXnSmUuEEw1q0lyKBoHm4SmN
pQaZRa52aUXWYhpyC/eHOUyj+XGJJsQadrvCzF2XEhcOHruFVjW3dORwYQUvHE7K4sIC1szKXBCs
xfXrBJZscsca7kDTcycvFTrKgNmEQ+3pY3IedQQ3lUA1/edlz6jCidbEilhg1dBpKsvswtqkw4Vt
Lo1akKzFBa8+DkncIFmL2wDDdVq2AdlMLRrcdZraeRl4aGF3KGy1mfFYgazFBR7qnCoIMngNcrvz
jCQsMtjuzNYkv+Hf4fq1x5ziOjDHChq3sM3a4Volq4V1WoesoXEzyJILEPHM2VUjePMDcRumuZnG
+SXIzq9VplfjCGadxAztIuti2Z29ZnDRcFvtnIUJ1KEqQbX4NWNgMuQMbrMCt12B263A7QVu0r4c
7rACdyzHVdUKXLUCV6/AlXrL4Uq95XCl3nK4Um853BV6Uyv0plboTa/QWzgyUoC7Qm9a6i15fMLh
Sr3lcKXecrhSbzlcobc6hyv0lvM7WuitTrp+i1sLvdUZ+dZqBa7QW/LBNsStV+A2K3DbFfx25bqo
pd4yuqil3nK6kHrL8Nus0FvYqrsss2aF3poVemuk3nL8Sr1ldNFIvWV00Ui9ZXTRSL3l+F2ht1bq
LSMzvCGoCHeF3lqptxy/Um+Z+KGVesvhSr3lcKXecrhSbxnbaaXeMrbTSb1lbKeTesvIt5N6y+Gu
6G/dCj/ZSb3lcKXecvyuGN+6FeNbt2J861f4yX6F3voV/a1fobd+hd76FeNbv2J861eMb73UW04X
K/zksEJvg9RbRmbDCr0NK/Q2rBjfhhXj27BifBtWjG+D1FuO3xV6G1eMb+MKvY0r9DauGN9GqbeM
Lkapt4wuRqm3jC5Gqbccvyv0Nkq9zctsqMr1NuA5pSLc8vFtkPmSjC4GmS/J6GKQ+ZKMLgaZL8ny
W663QeZLsjJboTeZL8niSr1l+JX5kpwuZL4kpwuZL8npQuZLsvyu0JvMl9TJPbMOd4XeZL4khyvz
JVncFXqT+ZKc3mS+JKc3mS/J6U3mS7L8rtBblC/J6C3Kl+Tku0JvUb4kh7tCb1G+JKO3KF+S0VuU
L8nobUW+ZIjyJTncFXqL8iU5+a7QW5QvyeGu0JvMlzQ5ukJv7fw8dpD5kiyuzE8m9/g5XJmfTO5y
drhCb+k1Oocr9JZ80B5xx3JcmS/JyVfmS9pMH5L5kjbTh2S+JL2U5nCl3jK2LvMlWdyu3B5kviQr
B6m3nByk3jJykPmSXNtkviSLK/WWkYPMl+T6hcyX5PqFzJfk+oXMl+RsXeZLsrhDeb+Q+ZKcPch8
Sc4eZL4kZw8yX5LTscyXZHFX+EmZL8nKQeotJwept5wcZH/LtU3qLYMr8yU5OQyqvF/IfEmuX8h8
Sa5fyHxJztZlviSLK8e3TL+Q+ZKcPch8Sc4eZL4kZw8yX5LTscyXZHFX+EmZL8nJQeZLcnKQ+ZKs
HGR/y7VN6i2HK/WWk4Nc757vF6PMl2T6xSjzJZl+Mcp8ScbWR5kvyeLK8W2+X4wyX5Kxh1HmSzL2
MMp8ScYeRpkvyeh4lPmSHK7Ml2TsYYz2l2TsIdpfkrEHmS/J2YPMl+R0LPMlWdxyPznKfEnOHmS+
JGcPMl+SsweZL8npWOZLsrjlfnKM9pdk7CHaX5KxB5kvydmDzJfkdCzzJVnc8nhylPmSnD3IfEnO
HmS+JGcPMl+S07HMl2Rxy+PJUeZLcvYg8yU5e5D5kpw9yHxJTscyX5LDlfmSnD3IfEnOHmS+JGcP
Ub4kYw9RviSjY5kvyeKWz7vHKF+Sk8MKPxnlSzJykPmSXNuifEkOt9xPdlGcOt8vuihOzeFKe8jh
SnvI4Up7mO+bXRSn5nClPeRwpT3kcKU9zOP2Mk7N4kq95XCl3jL+TMohsydylHLI4sp4fRbXHFou
wtVg62hnY9Z2LG6zArddgdutwO0FbloXFndYgTuW44YzSwW4agWuXoEr9ZbDlXpLPf2rMBPFLCf1
XuTPETN56OQ15mvMnwlm/feBWZdjJt91SWK2xZjF8lyB2c9hapnSn0ddQVRHm3LLWf2HEn79SoSf
2733Wvhe+LlN0EcLP9o2Xs7q7ECvo/25xTFBjqjso+VE/6HMJLfn5HgzOZ7VfyThD69kdMoewXgt
fC/8VzI6RWdaXgs/KfxXMzrlDi28Fr4Xvhxv70b4ud2Wr4Xvhf9qBtzc9tV/NOF3dyDR7Fme49WU
O2HxWk1HqKl+JWp6Pb+/YzW9muH+6ExAU1x/WzxtLMdk6+p5zOIsfpt8rjmJWSyleUyt5b7aFRIt
7iJtcRdpi7tIW2zO85g6SiuusJJfQutza+e/fMsXQ84/mOXn9hP98lsvd1b8Y1l+bo/lL1/3cvfL
P5blD8e2/hdh+XJnzj+U5WfP4vzidS+T9P9guv+HjvWG+h9a90fHer8I3cvd8P9Yus/tE//lt/74
WK/Y8ucx443sGdTcfvN8/eU9bxZzjK4SyKBKb3IH9a/hNLcpXqDm9sRn669npa91dONMuY+ctf6J
qvRS5cni2VZNVOVyUrkEclTl6sfdyHV4JXKVEX+5XDO8Rrft3Amv8pzZXfAa1T87+k71yw0nd9Cq
CDPjreV5uHKqbfGY3pXHFK9p3inNn9G+av9wA2ZBa3MsK/fqSEBceB8InsOr4O2ZqvLPRuRQa0Ct
F1FN9U2VfpwpgVjQoKnyDirvsPI++TiWw+0Bt1/GBQZmHhNKIBY0qa7M+cG6UlWBROHFocq9JiRQ
AfrSOFrVw2tbA7DQ++dTaCiryeuS/nlJTB3Dgz3u2ccmU0NlrBFe7FldA3nQNn0K0yOa17X6mHrF
X8cU1LsM/4qjHiMfPSMfyv0kndGgjkfwX89Ih/OvK9AweU2nvAV1W9KCwegXXtpb3YKxsAXTzwYe
vlrbAvJkb64FvUE9xobIU735FhgtN8f0gTan5dDL4C6Tpj3GTtvCfmz2PjTtMW3oCtugAbk9poZc
Xw41KFvDMVLqZmw18kXG3a22o74psSOLeox8+hn5sH6gjJtr+mN6cl/Wk5VxdM1wTE8eSnqyqgH1
mJ48lPVkZRhvhmN6wTjTC0QLTC8bj7GhccZbRy0wWh6P6QNjTsukHxtXbd8kXllDWxX2Y+PX2+qI
NrRVYT9u1cyIGT+4HT6Z6cUx7RnZ5GgX9GBA1KF39WMhcR1eF+/TZ7M9Zn0E9aaY+ky/yhA3mYgi
udQzXidHWydpEwPrwkcdRNMuqF/ohwa3wpueEkwF7rswk8P3DQleEzhpGCf4jeMjfS8JpV3qbGLa
t/2G8aMrvPcpxVGyYy9Ql1LH7OWcKdyS++4Vcz+8Su4xq/equMf8WrHF341VCj5Ef7ptK+e9gb/b
r0g2vzxvENISBK8qYyHB6h2TK5VqaoB4zehrRn8MRjO+Ra/wLXhn3C/It9zBaIc3yL2q0a55pWN1
+4rH6nZ+rL4L7ptXzP3a0fTvPNLAGxlLZNP98rzB60jjNaOvGb0No+OJ/bHEKKNX4wWSKVcSmqRK
2zQjhRrvnkz0/CP5Hn8Mvhu823Il30P6WmGg2DJMnk4r5JyRn2W9Y9+wio7lvf+xeB+O433WXhq8
GP4V24uaj+mP5Lv9cfjuZvkObgr3zNXa7qCQ+x1CCz1mHdLkbNN0jDqOdRo1Uf+Q3phhuDI/PCZg
9zFJL+IxRlQpRI3vFVhWAfEYPLNPxOzvATyl/KlxW3WdErtDxUPO1TKmopgpSSKiLkWsSxGbIsTa
J1nd7pYqh9qXo05eY+zSthk0pCOVpzVZiodxO+xGqW3/4XfJpnCHclyT0/W46TYFXL0Ct1mB263A
HcpxmxVta1a0rVnRtoa2LXV3NcUdinFH2AbhcOvUHdMUtyd0U6MBxR0J3dRqHME1zqAYty7nt2/L
+e37FXTHEroa3g9X46BKKGt4QXzCbmZoBzfi98Wb7WiZHX0UsyvFbFUS09T0suWYjZnlA6fdkCQ6
mM3GZiF87Jbqd2OMUmavVhEmXF5Wgkn8sk7zGSF2qccuAA/eXtVwKZXxNgY39WiCwzUSqqE3JnBZ
/fD2qq5npC/IYtJpiejktNmgmHwn1tHsofquiNUBcNOKEmTHQlbhfVZdd+k9qpwoPjeyrADjjCei
bRFuDbglyprk2hTK1bh43VRl3GIUrVz3nyULZziU3eiHniXt5wEZWG6HImTY59BQT59DBjaHqgxZ
A3IZzxBjN2Mhz8Zz2m06Bchm+xJscylBNkprdVuGbAKwlgYsOWSjwbYpRDYabNsyZNOTVMvG6vSo
A8imvKWDavLRGoesAXksQzYabIe2jA3Q4KjKKIMGx74M2Wiwq+oyNnpALmyg0WCn2jJko8FOqyI2
zJrLhFzWQNi429VlDTSrLRNyWQPNWUXVNWUaNMapurZMg+Zs4YRcZqItaLArM9EWNNgVNdC/Q40O
t0tO20yMo5uKefz02OAwW4qpx1nMUjyf0SrAHIoxR4qZjjQtJr6Y6DCT80uHqXhKJ1M9TlxdJpmN
dGFhxv+JX9XzFUheGhYktNHSD+BrQb8tp89X/tqlnBd+1vMUVipniKhiXTcnTabMnNx1NSt3iamK
ac7rUmLWxTSbYpqsG+WkxPM5yQf4ELMvNmQ9zDI6bwV4WHbWzoIV+L1yCTsTrNTFGquLNVYXa6ye
15iQbp3pZZJod4ybqDPqk7wMR7iJekl9AbXJqC/jJnCKU+Am8EHFAjfRFCuzKe5+TVtMc16XErMv
pjnf+yTmWOomcMfLsptoVbEht/M9bt4K2qXhLlhB2xS7ibZYY22xxtpijbXzGpPS5TcK5IKZjqmM
YeJhZcRULFmuM9r1z0IkUGX9rGPlgsOumeVUYs6Hh5LRTD5IouLaaEGbikPJbizF7Of1JDFVqUT5
AtE8zXo+iBZC6ptieeIRjgJ59l1x/X15/UN5/cVaGqpS2Q+qjGZTqCMNx+8K6y7sSXzQy9Y9ryGJ
WTwhG1gvyg0m/p2DfhF1rJhnTF4JhqiqnCr6uzFG9el/h1rPU5UMNPO84lI4orbzVIVYx/lQXmL2
xZjzqpKY87EEl2krXp3NJQOq+b7ERdpWmYFJ1l/Po8r6S0emtjzBURX2qLbUP7TFCY62KvR3bWlf
bhXX0Hw41PLsRhazLsZsijGZfur51E6rmH4y3rZVhVLKxDfBNBVQxORbkxvlABWTFg61Ti4NOVRV
jqrLUety1IahNrlmtRyV7rBowsZnPyewH/E9UF2OlZ7R56+7hwqUrGGYryGMAxZ1nK+hC5vIOX3M
aKToB09nUVGbdaIFoQIla9B83kRrOD2xPxCV77hrM+KsuWZzkq/bjOQFaldONadPgTqUU83oUKA2
vB/mhOXXaBOos7bd6GLbbuoSy5OGgWmNWdMLhuEXY1OmJ3gpV2FTrsKmXIVNRoWzwm4z3VDQxzzH
SkfSZtQpHElbpE6hzXZJm8GRtDltzttL2xU7EgwjChxJW67ZtrxzdlUxVUyClFDV5VQzOpSoTbEj
6dojHElXPkh2mR45bxhdZowUjgSzIwWOpC9XIeZHCoTdl6uwz6iwsYImyHxmlwuKeq5EhjqAvIbQ
V/2rGX0CGQgPhHI/jyyZEN0uJ7Jxnl+BOmRiU+HkMFuSYiAk9S1qeWw6lMemQ1OOmtGYRO2K5Tr0
5VSHcrlmZhJCrmP5TAIzJwUMjLqcgXJtjeXaGttiFYxdOdVybY3lfWss7ltdVaytDrMnJajFfaur
hD/MuaIOEyh4lkNlnGeHORTnPNucR+yqbp6yBsqaUPZnVRKUwXCHNiAPGZ6BjYawMWZ4hlze0Htk
3DWSoiykjHmV5WigU7ocNaM7iZoJRyLNKa65nPmoTF+LlKwyI1lka2qYR5ZMlPe38jxLV55n6crz
LF15nqXTxd6x08VjWae5xvS8H+tEdiWLOpSjjsWotdBWcs+6Q+Xayrjnri7XVl2kLQ2oqK02x4BF
bRlqnTx35FC7ctS+HHUoRx0ZapNWAaD63IlDpbsSBz/PGPw0w36k+DQjw4rfBmLps4vFVahAyRrq
+RrCHNqiNvM1bH0FW0G/nacfoiiLKnbUsRaECpSsQWz2oTXsT+wPROU76tqcOLlmc5Jvq4zkBaoq
p5rTp0Cty6lmdChReT/MCavt5lFnbbvti227HUosTxoG5k5mTS8YhriqJCcWnztZFnZXrsKuXIVd
RoWzwu4y3VDS745yJF1GncKRdEXqFNrslrQZHEmf0+a8vWBKpcCR+JTKsiPpyzXbl3fOvi2nmtOn
QO3LqWZ0KFHHYkcyVEc4kkEV2/aQ6ZHzhjFkxkjhSHyGZdmRDOUqHMpVOJSrcMiokE44LDKf++WC
opErkaPC+xv2F6IrPpXh6JY2UYbfpZJCF4yIrpcJOscmw7NAzcSnwtGN3TwDwmeN5fHpWB6fjmMp
al/ltCZQValc+0qXU61L5dpXmdkEl2tfZbQlGcjMJiQDfTkDxdrqq3JtqapYBT67UkC1XFuquG/1
qrhv9apcW6p47ter4r7VK+ET886oV3zPHh+vhAvtMbuC6bO8X+wxw5KiTZNSFhm94pii3Z7gL0Sv
M3yTxJRFbnJ89yf4C9HbedpC2jozb5CofTlqTocCNROaRPoTb9HlzMjnW4qGwN6/B1c0BPZ1nUEX
jJT3vfK8S1+ed+nL8y59ed6lr8s9ZVM+rvk9KxZVz4dZvci2ZFHrctSmHFVoK3l81qFmohCJWq6t
JqOtMFq6ts/lHnOIderJOUDUWuz+mUctpnksYvLh5iQi3bC583ONnZ9qkE9wojEvgVHuoGD6D+RV
Mf2wF9vSb+fpHzz5w7HURaqPcR/Iqxx9dq777MT+QPpiM06pNrMSH+YlcjTN8e5pik0kxTTnhaRH
udukvlNb7rsSW8saQ2xswRj6ft7YjhbyKzCGPmMMtxey2FFy5w5DbEO5Y4ch8yp37TB8MuYOHcaQ
MeujafavgOaRtpxzGGJLzh07jDEz+N2BwxjbeWM7VsjjKzCGMWMMOytg2Xqcu8xTHcSOT37RkJ0c
qkFyi1MRjmzVMKhAu55Hz0rhToLGZh6VuZtc5WHX78rK20LUVx6x3o0sh59SluNPWHn7U4pdbJP/
kSvP9J8f14TbrJsRPomPPVm32K7xdQy5A7pdRHdM0bXpOLsLb4lf4GEXsZDk16biBmn9KbrHjes/
LuIthrBu3q5uPYT18+g/bi/4RSHq0oDoJ0Ss02eyX5W7zRhxQG3MHSrmsG1Dr95jZ34FsimHC1NK
kDUgj2XItUE288wSZNOqZizk2eQY4Sx9CTJc2VkV8gxXdqqhDBmu7KTXMuaQ4cpOeiN5BhkufGyb
QmRTDkfTCpBNnlC17D7Eah4Z5ExvzW4zlEHOgypDBjkPfRkbIGd4aaGAMsh5HIuQTW5Mwd77AjZM
0kvB5vQSyhqQ+zJk01Ngs3MJGw0gFzbQaBC20JZQhos1m8IGwsWaTZkGe7gatS3TILzpDrv1CigP
oMGuzEQH0GA/10A7toOvjcOL9MVUC4j+KgRT38ivuuLXOQtMdlcFv4fUV47LfgpyeS45odL3cRLc
luAmL3gguL1nge0GSqEOgdvk7etm2BpMkAXJ4+pk/p52i9kYzIW73y1mazDbJGZoP2B2ZgNU5dtP
Ww97yMh2sip81ZuvpubZ25eSa3AW0eAYO0uQFyxP7YIE6SLLI1yhEVhO3ldvMZWhufCMiMWcrAW2
E6MZzDNqfO5o8Be1YFJwkNRarr419+kTK0wuVVpUozC4XjqBKuo37qiqqhJWB0BtSnid6oZNU8jA
WGIyo2ED9i918VeMlxHeMqqqYZmX0Wydgg0xjhedvJzYohqMShXoDZ6KVvAk/DIDU909eRpJqzJh
dOazEYWhM7yADnVah4KXSWI9RLiOFz1PdQSqaQfBUc0uqgl14SEDi2pcQd8UWPFo9NCbEXDRikcF
iqsLPMNodlH1Y7UkAZNU6I1bgHXArAQsqnmNqE/bo0Q1XqxPdyOBCm5MjThEJHccOExTbELq2NtK
msaN6TpFU2IaLzYs9QaL2pgUu2c0rSmLaYadYeEZE4dq3FhLhvMMqtHUuDRAWlSjqXHJrC2q6X1O
U/MGaFAH47q6fihCNSPOuDREW1QNbi5t1xLX+M0xcJC8Msqhmj5gaGf9rEVtgYP0+ChxjcdSXlwz
jtaigstSJQobKhh3VInGBuO0YLNWFTtNIQTjtGCvVNa/WlQYbVSRysBrtZXnYN69DNZr6RJPMCgY
b3SJgxmMqPre9/CcLZoBrO/7IlRQWV3iDgaTCAA/lxACU8NoeFWqhe5mWZh1XaNhdsINDZtFVXCH
2oTrW6ZriYssKNXZn2a643zirBiUe8rPO6UuPX4NUe463RkIXhWhMXJ15fem9ouYdTFmU4zZzmL6
5vhLgetmwagJ5kIIhZh0qphkcwkxUfew4FMI5sIE4RVwacyxnjMNhjZvQWvQlECbs9ufOx42Vw3V
bdsbtNYEPLfxIenSXuO9xvul4dXVz5zB13i/bLwah8GfK4Ov8V7jvcbLdGDcaPZzZfA13i0V3P/M
GfyF4nXJVdgfHzHMuzCdoGeWtFKYCzktj1kvrVIRzHSWKmrQhNmEJmWnfhNqV446FKPC2olFbUvn
nnmarxSxTc+3Q3MW8oMEM50iSomoXPCqVPC3FlKiRTMrcCnMYiktZYcJ5lIiLWCWW2ddlaPqctTm
F2Xzdamvq+uFBeuA2ZQLvikV/N0KqR4Lp2U1ngNaQmzFo64ZxMKAshG5iz65C8Vi1oWY/rmRAsy+
uPbSBomngedFVBdqx7+xkUAMFozJ/3pmLdLfzhwwYcNfHXegGHUku1pm+ppZeqlH+zh8urf5HWuA
2/gHo/ocWUNw4K8zJrfM4VlgQvHngOcVCVvzKn+Z7bCIOZZiistWcpiqALOO2qOq4zC9EhETDpbn
3DDsOqlqYHFmq4jE1YC7sEqEd8hNmAuDNcFcGDLwKHewy+ZHwRuUxEvvyxx8Nw9L3el1rCGquRCt
T3oig6dhl1SNu9aMaWRQNaCqRVRTM+xgz+nFIy7Feq7yFipvfJuSW1gcbge47TKuZWDBggJiQZOm
2keofSiQqJmx1PBBiUSX+kRAlA3628M3Hrzx4Ppme3O+2+wuL65vNtc3Vy92N5vzbdc8ebY9v3hy
sz19enjjQfj7q683723+amuxN6qAS7Fb6yr/34unTwP4cHY2EPBfNyboNqM8ynhix7F84puQIj6s
Jd5Q4ooR7ylx8h8lLsGWuDkjoHvBub4r4k1CLHUg3kmx6BmZF3PeBOJ9LPPmdgptc8R3ac4PDJwR
SxeIDxHx4ZbE+0B8BA0QheoVnNem65lzNuZEjKUO15IPd0Q/EPfcwyaIMdBXVazX7nZ6VVWWvCon
b6LDmDzpq0oluF/tCTh5nSWvysmnuSf91WRhnIfGbu/dZIK8UmdnjnzY+xyIm1krXMZzNPldlSE/
/TXo9lVRb4B8t0B+sJWsJ69NuKJhE/IrqqCxFcQCol13TkAoPKwADkDF8ocXlV4R+QboZ43Te82U
5yHGGXYtC+Mcq1uQ9+JPkQfr6V8VdWucQwn54Qjy2gZ1Ott1b1VBCxXUJeKfZu/rKzCU2yLtHkW+
B/KqhPxR4gH2hxL9Hkcf+B9i9ZK+u82aZ8X6LqmDuIbYtd0VeesaqGdrI9c5Q1+JYbFLDyzwKiyl
3hZRr8uoj13Fqesi6nJIT1E3aTtVD5x8fWfkIRzpak6+O4p8OEnDyNdwcIeS7wvIS/A893RE7wTv
qnhAqWPikKOHzdZH0w+dNkEfXP74qqjDiML8cYdnIZDOqi5bx9zDk4aviLz1CLTP9tIjNH7E4vRH
a5dqIMFUOLrlwzVIc+lcBYeZBnhPTTzyXAXUeobYp6UnKtKnJTqW3plgkLAP181y6n5uvjCNM/JX
sXqnWHPk9IXbWTHHTQ0omgbjCfKFs1Aj1jT5Pkde31o6TZWl35XRN7n6GfqK0z/ObWb4p9aTGG91
gn6ZbRqNKzJkaXcGa9GznUnfAFZdk3k0GbWY9UeJqVU1RLN0uz5Lff8t2gAXLdgadMvaADcm3UEb
akKdt0ENsZRuo4e4DRWNym+ph3QbqjGW0m30ENtS1d6NLdWztlS1eVtKe6PS/gBVwNLpfBXjSlX3
sZTGrJTWVNCnhTRmhbS2BYZCL7t0LKMjm4DUZQX9q1OC69HZGobcqJyowacQqWcds71hRQ1xgtJK
qY59xm3aMERtUEM8/hzbhiHZBjXEUjqmDc4rJdpQjbGmj2lDPduGasyP0mvbENtS1d6NLdWztlR1
eVvaFtaQ7g/WsyaGaVLFdqW5GoZll1NNTkxravDURZdT7Z20wak60Qal4xqOaUM92waV8N6kDbvS
QTQdCDhVZ+OlfbWuipT/zsdLa2pIj6IqHy6tbUJiFK26eJw+sgnpUbTq4u5AFV3ap9N+ySmatqGP
3EZT2IbMBIUu1eho/XlVDTMTlLq7kzZkJihjcydtyExQxlhKt9FDog1VrOlj9TDThiqW0m30kJig
dHdjS5kJSpe3pXQ6Y90EhcVkURXjSlXHExR4u21eSmsqmHGtVVZIa1uQmqCwnNutmjAzQWFpqztW
gq2hytYw5PJ6hRMUlrqKe8OKGuYmKE1+dFjbhji415W6szakg3tdxVI6pg3zExSlYk0f04b5CYpS
sZRu04bEBKW/G1vKTFD6vC0dCmvITVDGbBXbteYau1bdZv3SmhratG/VXdZtrG7DmJhkxePPsW0Y
021QsZSOaQOaa9wGpe9GD/VsG1R9N3rANiTyiIk44Ng2zCQSh6wedqXBTG6imIiM6SxrZcyXHEez
ceuaGmZ6XD5sXduE1ESxj+OlI5swM1Hs+6yiS31rbqLIJiiD3Cw7DMl94WfJ3aCDtSXDpO8O3LPe
CX0uJO5Yo92+Q3pje7YCTfsz7Pe9W/qyAWSINt5JVtDctgH1XdOXDSAdzZxQkhUMt21Ae9f0ZQNI
P651XMHutg3o75q+bAAZcup4X67fWMz9RPFiN+nCJiejGfthKwOnnmS/E/RhSGbi6RP0U+JZQ59K
Z5T0B6xG0Ofgv/KjL725fjUouMpVsJ3dK9EkKzAPnfTscE1d1dkmTDU0pTWYQSBZw5itITfUiBoa
N9kxl2P2TRAS8aNm/iltdEhWUGKjlR3ePPEh4j49ElvudWxCZtjl8tFDT3RstgO3wkjT7JsdljDg
uxpMjK5lA6ALEx9qbo1m5OeOZ0UuAsnjbb+EvqZ5c7MhQDbgtKiXwR0VY2hEkJCm6+d3XUHjlkw8
/TpBP6mBNQ2oX10F0ADi5+BUEac/c65HbtKdbwDxEW2bIJ+Ufzl54iDMxERsCFPJDhAPYsFDc/9D
iA/x/uWyk3JDwjtYzTavijw800F71gjUQ5Q+u3Xc/iKScVN7I3y4oplM7WkE5GpQx9XgqZ/wyRIN
gW7RBjfTEG2wb5PRUfIWjahnG9HQIaarYjXrIg80a0TtK6IONkScZ6ek/GdilNm8te/Anv2Rpnw7
OcCsqiDt3MameYUtsDW0uRpW75/CcZJmfLuckFbVkByFpxr6V9gGV8VwJ4ogXZmbkqrHrJjW1JC2
pamGrJhu2QZXRVZMxZrA9FBsTU0V2+sx1lTPWlNTxYq4uza4KqgmElFd2eQPo4poclbRxa47pm9z
aMzxJSo4JCuYC4viwIXuUojoZyP3oonBVAHVQB1lD5p16Q+zIMQHNnrkuWti+uuyEzF9OnPqosCx
9LR8auKn7M1LnviQkH6K+BnPwQfpG4q8F+u6fZU1gIbpwBnFRVNkdMuJWd2+wgqgAfQiilVT47IG
6Ib0gD5ypCF2PF5C7aurACREfEQf+yCVznAVS0hpGvn2cuqaNdKUE9JRbD2JiAyXvZy8qiZTg2zC
XEejifY7rwG0QJsQT5DTeeSkFiJPvTPkiR81K0Pl5IsGArqzxSSouHjmQqJVCmheYQ3QBKrhyJXm
Kii1UppK7qWru/1grGs6mA2xr1N9qgnlPZlOoobIEenbZhnpDGpI+KF0HqSce+LmhiiBpm+dYoSr
ul9VBSAfYj5DlKHTt04x1nQ7zl1XAA0gLm6IXNxMkq68ASPT8B3Tt3P8fqGCYg3PzsCJmx4iN61v
P6FpXhl9N6GhnThy03VVpSpYNRDQ/SV3XgOYKa1ADgSTjG4d8tJTCHddARzep/SjkDrnp8saoGlE
OkbjjL59yEuXg+66ApAQpR8taOVsqHSsp+tNYzTx7jM1FFipraF+hTWAkGgFifHslhEpnfiNidHm
lhEps1HpqxUOZbdSQPMKa4AmkPFslM46W0GxlVIh9TJFN3NPw1nqGoh0Yl+zbOyd12BvKiEVDLKC
emUFKV/Uv7oKoAFkuBmjxa2Zm0TW6WB4hTWYJrArmKpK1qDuQAnjK6wBmqBoBdGQ4HutqKBKVZD0
F3Qjnap0YoUuVUE0psH2Cx2HdrqpqldXAUiI3qdTRWmc5va7QJqKVZHYhJAe94sjF7pSDQeWJP11
6fZEZFQxLXdRPjl3iSapIQxojP2OEo8Cx2nQLx6R0+Khdz6pOJnfz2h4x+njrrxIOj09y63iO5lm
TKj8nrlBkJc9AKc3Uj67EvJjJ7nXReTPCsibZUDVSPpyLeJ4+qa/aa7eIXHXXBH9+bvmGkH/Ti+b
o/skla5j6ZTN7md61rhAfCwiHp4U4pZDN5ekyRfP+JLkqeG4m6cJeT2T94u4b2Pyu5PNQNMqcNFA
LSL1MvLwPEQr6A+Gfr9Ev0g6tU7TnzoWHVZ0n9gln2rA7CKilH9fZcnPLXSX7qA2NahsDXO7k87O
qmQNXR3XQMctdxKC7mnYlh8kUEFKQUR1TF4dRz7SgAkdeup6Uucgkrnjcg23WfLjSvIpDXfZGraz
mwDLNUx7WeqkRdJ/lotoyJIfV5JPiWjM1rCdHQCKRTTQjpw6y5HMjhaLiEU/tyc/NIK+qusxW8O4
soaEEtgd5XEN29kEcrkSqKuIz6PsurI2QHyWUIKquJCiCvYrK0gIaZq6VNk6Duk6IjFhHQkxTXUw
c4qi9V2hU5oTFLtyOia/X0k+ZUtttoZDoc/LCIldkltHu4d2hf1hVkR9lvx+JfmUiIZsDYfC7pYT
EesNUfA1l/coFRG7Nj4mP3dd0QoRsZvj4xrmLhJeIaKR+bxOxka7wjOKftotg6OxztLfH0G/Ey1g
fbmPW1C2i26+BW2W/v4I+rIFrCdH8emu8JjlfAv6LP39EfRb0QLWlaMIb1cYIM12tDFLfr+SfHJU
q7JVHAoDsOygRjtzo+VMdufXPBYCmPREWbHsXEx+v4J8NNN0DaizNRzSNcTxEZFPNO7TGhK5hHam
Bt6GRB4EctZ0W7hqVZzATJ/WLUuzsDuclMky86OQh2HOSoV45p530uziBtXWUQ3b29dAFWAWMXkN
Z3fQBqYDm+SlG8WwgoSZ0oW/2TPHdNd8gn7mXblatqDrIyM9sblpVsHxm26TS8eqGkUF4lT2ATPt
vIIJfMYqaJMd2eSMqsUKUi2Yq6AfpZKHVipZ1FC4mQgyLsmD5TpPv/CO/NE2oGsj+nWWvuqMwZvV
aG6kBwb29BMaaPL8505NUw1UNrsby2dR/kn6KfmnppnsbZQU+bKUryGf5F52YUm+bBRQTUL8VvoL
4i8cZpQ71J+oYEn+5Sl31SQrkBqoRQVl52pnW8DutUhUoG+rA3b2JVlB2Vg8KyJ2+CVZQdnpF2OM
6cz7koTKlqShAXKgAfpLAip7zlHNrRzoJfkkZ2Yx/XpOw2pJPuVjgErxL8cASb/8XV0lo1HgX44B
cuUG/8vTr1PxNPAvnVBEv4h/kyxO05c+SNIv62B1Sr9AP++CtB9kFuinwhSgL0cBSb+sf9XdHP2F
/lt4qrye8w96of9WdRn/KQ9q6NcL/bdwzRiWVOUgD/QX+u/MHsYkfRnnAv2F/rtiWbqW/RfoL/Xf
8iClTsp/qf+W7eMF+nIIBvpL/bdsJzXQl+OL8W/1Uv8tOxEB9OUADPwv9d+yIyMw0UtFibXsv8e/
Tp4MIGrZf4+jPxtiNbL/Hk8/Of6yJRTDQVeS/DZTDEXpG/n0cvwF+qz/RpeHHXZJ+59NFfTRJIzt
bGiHqILDygpkLoJPA7rUjq2khIp3bI2CfLRjK9kBindsaUE+2rE1079Kd2z1gn60Y+to+jY+V4J+
tGOriP78jq1W0L/b50HZFK+P81iFG4fmH3NnU7xEBaUbn5rUBdJQAXsFM+5f6ccwynN9dcUm8n10
td3ZkAzhVmQTh5bWYLY4CCHNXAS7Qgt0lBlUVMHMjb8rKqBeYtCyAnXrFtADU2qoYxElZ/JrKqAd
eWhiEd26AurphrgnNMmesKYCOtIMXdyCW1dAR5ohuq+4auc6QmEFIzfTIaqgv3UFzEzHyExv3QJm
pmZlXa6ezFlRVVaBHtiAY1bWpb+b03JhDYplvcfEAlByxr2qCbQnjIkFoOScck0T6KAzRus/h+3+
dhVozVbJxig1etAzTajna2g0bwMdE8bo1txDl5xYptuQCtzpoSw1Rvs9tZrbt5LoCiQ5QWXU52tY
ee9vEy3Q6CrRhoq2oXByT6jzCtjsbIyG/sOQnF2usVTikOBlGGlHc1u4Sitgt5snKjisc0i1VIJi
15tXkT86m92EVtwCna9gd+sW1LSCKHapMEMtKzikKzAzVvGkA3uvrYodnl4RQab6mmLvXyUq6FZ4
VNMZ6qgC+lJBFa+op9OYa1rQ5ytobt2CgVYQh19ze0pXaJn15Tj+am4ZXKie9eU4/upuXQHry1H8
pW7fAtaXx8hhp/fRJR12ejWrbxcqKFvwS1awOzF7b6p8BTPnH0uuMR7MPkYqILMwLvkvW+6bE9BA
I2x485Qni+ZuMi666d/Ihz3mpOLDlVWdVPCh5/S7xO4wo196iESrxF2A+mjyYJ7UenQXbQAsPF2p
UotlZujt2fOpOso2HnPTf6gBcrGKvSkTV3F264iCvSmj40na3IrNnCOtIkdKD6rAa9uyhpnAcUUN
1FXXUVR0zH3/Qg/TLGfI1nF260GfPbtcR4FR9qGoGU2bXDKtgZprnTgqPaPqop2GA3OldaIzp5cW
S30Fe8E23gs783Rd2U5SEE6TpT8n/tQ+Uti+xe49tRtJ6fELeJkyakLaH800QUVN6O6UfsVbcGKT
RKECFVdQeCpvVgdDlv42TX+dDqiraKJzQsMu2QfKm8Deu47pb9P0VzWBvXjdRKd4hl3hmbPZJugs
/W2a/rom0M7cxMeEDuVNmLn3oM1WcEhXkGwDvC4Qt2Gqg3W3aC15t6I3JK+OY2/uxfQPK3rDTBv4
c9RNHCGtMKV0E7os/cMKU5ptAvNJ0Unt3YpxId2EIUv/sGJcmG0C80lRZm23wiclewN7ojimf1jh
k+Y6A3vft0nEeOlIvniqyZ/3TVYw04b5ChpeQZ2vYMXOwOTKJn9/so3mgnMtKJzssCMMuo3Cx9JL
q+cSzCxFruODJKXXhs/Tp/04PkZS+tzSPH3aj9smDn7Ldl6lg1/FFjR1amPR2fHigUMZ1Ee0dv2A
HJebuZDCzqFqQt98VpNpjm9CzY5QYxXqyCqiWZR9u4Bu/7lNK0wLdNSKxjq7+m6aUc81Y6qCdeU+
2YxBJ6sYEspopTnV7NZYHe9jWlNDK+3VqaK9mzY4VbRRFdO3/d00op5phNmNTGtIrEklVwbLnQZ7
8r0d0/aabsFcr5OKHuIaImstrEG2wCl6vJs2kD4n1cDerb9FI+qZRkw10OG/i6a2umKxynr3ylrQ
RdO2yZBuN7px/uPl3+G2aTy2MxouHpOL5LevgbUh2pp1dgdtoK7bLC7IdHZ6ulCSzjbsakY+vpVK
r7sTKV4jV6yCyB0N+jZvK0MFdFjo4ySYvs3bx1ABHRWGqJ8N+jZvE0MFNIyM3hxQc9dTlN8SrHg2
+M6rcO8j0t4WPT2QraPspmCl6N1IOrGDrfCStvkpFd0Imapg5nLL8hkPPYymh8RLznPzzlKnyhQd
OaS5J1aK6WumgWhYW3NHYZq+M6K/PXzjwRsPrm+2N+e7ze7y4vpms/t2e7XZn18/udmePj189fXm
vc1f33hQvdyCO9z18NPMBB1EH8zPPYXsAKcKELWzTJ5sDKURcE+te4V4AGKsl2Ml/4a7HV7CTYsv
YbsFgRhKDpb9QsUQiw/y7JCnma+rKnxhf7aA09ivFZGJo6SiL475KSnBLb1OprtbUbI/bRvtz35O
fvD3mccHiQPsYLUNP6tTkAf8bXy410dP/m6D1YxbS+nUft2GmqxGrL5GYj327w5+DpRX1zo4bvNy
28FP26426M6V1uFri1N3oQbzt6G0H3N2OFThu90ZgQC9AeBmKQ14gvoOOtA4EHpU4rbtW6IP5aka
SkMdyhXUWg2k1hlKNemPZkUMrGAry63W4DjUy+qwzB9S0kQShzMp07OBlG6l3HWNVhV01wONURP9
q2DpA+mvtL22nv2pk1MTrOQM9NiQ3kIpWT5gl+TLzmoW/JNZcDCUrJ0ORE5WB3lKbYLSNqYErdhb
a9SByzbmVeFXIKd2CQttjlqKIvAD2tOcXdfBSpldE76DRUDriM2yL06lRTfUYtvAfZPwT7HVqQNa
DHK5P5Olh4r2u/0+tJ56ujOiTedhBqkP9ON5bTuJw89uP28dhpL9QtMvxuOsQJ8tW4Heh75kfew4
BitEP94RL9uTv9topIh95uj7N/jMIbTC+UbiSYaIXtpXhbjAeiMIe7mvqkJptQ+0JT2wgp5Yv/VD
B9mKM+rDxpRdQOuEZSzZRUW17H1YsCf2hQo2ab9o90t2QShRnY8FdkFkglbgxv/CXpG1cevXaFva
+S8Qf0fxVSzx5V6B44nEAU9Hsaz/agKu7SFnUQ+xnrPxfcJQWt1DiG3te2wPWKbtIfv1PcTDcTSP
yms6mu/me4jvHxXl6bCXrTgM8m9qIwdqI3XsM+d6SC/GSU+b+YIhbz127K4kpdMUJb3Up5Jjac9x
0v3Ojmh0nHHWU833qMBTibQaotlecfwwmrORiWi7Oy1ru+wttVqWkJ33yXEmRGJWEtRy1/UioEQs
cN+FVrhetCvrRSFWcTEYHWf6qBfRceaU96IwA6L9qKL9ZBf1IjrO9LS3HONrUcvK2wWM5gW9pSJ2
0Z6l7MJQWtD5aYFdDNQ/2ZlCpYItrxtnIhsHSgc6bozZtttxiemurct6hWiXj8Cj6JBiWW8Ds56K
6N/OSKg/5pmHeBZ4IB5mJHboIHRESMTjI8Xtoq9rzkeO0p5+t4sojfxr+m2YATncPvoafu5IfKdI
1sXO+NqBysn5fDKvpnPRHZl5WEhD+uZuSymxuWX00363A24O1u+qwJkZnUKcWdURbhVaZEcyh0nq
dFHoWTwDcvZkvd6p7C2xj9N+hhZG87MZvVg+tpSDVpZ6T2fLia30GS/LaZyyOcJZlD85I3FSF7VF
E0pnvjcHiVOfekbmApSDPcVJ+PEz0oPoz9m8j5V+zyEhG8K8ThU4d9+dpfTlS/cJTwd/04ha7SIa
ZC5qsztoBZTGjvJh7QL+th7G+uZT0uqBxb6dGJc9pcgWnPWCvdh5+GmP2gz2VM9pu5uBCM6kL6Cc
5bOhjLOOzoDs19WQ48z2XQeBPmMtCGeKFfFcNpfmOCd+yOZBrdytD6aZzy0bEfak3XP5OJv7sHKw
7dr5KB68yiFYtCs/zVFqKKYfsUJeZdeHr+d6raVUEd2oPfaGQOn0bIYPwD0QPk73kkuMMBxPxJOU
5FgtjZAZg9G8keXVEDjY6TQlawWn3s9AVnsny1vih04L+Ks1iwvgu/bAy73ObWnUH4MsYUZNpWn1
PwYadgWGcpP2htBbIj3T6Nvl3qKMr8NkEt9Hc4E5S9rGNZxSnmLdbonu9qMs7amNn1FKJdZT09jM
riC0vBSyIaR8nLMekm+1mDTTj3Ki1tMDJTtu0BYx2dj42NqzjfuRJzoK1KEPaNLvbCRmv7ZrFxWJ
ynG8q0iG0VK1/quaiU/Sc7NoLtUS3XXBVmkplevWr8Cko2jbT+gMst3L0paWsryKm7fYcZxEASXW
sR/oeLdtZHlDdDrOUbLarCglO9rTcioPyxPTvCK1oe5EFtBrnnxtY9izM655pDcy//SKrID6zK0s
pfLb+h6QtQLqLXeylPaxtrsrK9hxK6hleU10NxxmKPl1J2IFSpZTeXSHyAoaIgGcm7dSF6zP16HV
TvNkfc55a5frsTGp9UOnSQ2XZDjDCtdI+z9dAyDrxE6iyTUAkush2UanW+pPaHbNlrakZziJH6f5
U8qlZjzZn9Tn72Yo1UGitZ+/E0okenSa30WaJyumTo9+/0OYczLNE3t3X5CVzyapzZA7LJlFj0SW
bmZsuXf9juGSiJrhkrV8ByEtRe/bkJlaNbNCx2YHZJy248K+pa0baBxiZ6b7CHKK38VfhdkrzQU5
SL+GM4ifknV4eocIsktxFuacDmsbfTdIzliUYtdhB9Y6sq+iJXGmhbj8XYXfcd/h9zwM4QtF5rgW
QnecjGRuNgL3dtZdtTRPZ0cm2mtPSfw5O1NoqcRdj2xleU+izdNG6o5idpxSlFdJcNAEHdivRj8a
Ej9Oy8ccB3RWEzKIYTdOCTcjodGf8dJAyZUfZrhpgv4d5p7Xnx7NFR054buulqUtLdVxdo3iNhRX
LVkKrARmbUVTW4ikH2oDOemcpmgbT4l3lfWHEUGRXKrTMLVVOm+xpT2vX1LaU1wSqy5bCki8QYv3
Gt5KbgZauktJI1Civaw/XeIAv6qYxOks2pZTfXWR36WYPF9g109otGz3vNBIzHo66ZNoblvaU1Ef
tPZeBb63e6Y70rdd+dlMu4j/cZgH2u/yHFDdjToqrainG+e8Yi01S9clCvtdHXh11tHL0o7prp/z
kMQKasLZYr+z+w9IK2icqcjuBFe65/VLStQn2bmK2xdJOBgIZ6kMDc0IbLcRJOprrPSUWsFsNtzq
+UxCKK8+OqTli61I1dM3MaU+yviy0naetqTURvW12xxtG9Xgfjrb/zvb5y2WXY21/Z/MWK0vGGd9
wbKGk/rtOQTsKbJx9kUhbZDTTn49RGM6KyXj+JoeXFPdKVnaMJ76WnLAKNGRgkTOSz24ohpuJVVF
S+dHTkuJ9uBO9oojenATQbK2v21X9OAxgpzGrWPlxIrLRyzFYt/uIMvpSByvMjJMNrZ0ZwUcgBXQ
2Kf1Ixb0O7ITzJXPjVgWk9qCzeIyX2AlRGOB2vaKIcjMzs27KFfG5+YlGmwiH9yqmBIrJ/TY6j+B
uJ33ftWarATaEruinv+a7DsIcLBM4i1pFNXR/KhdXRkDPduv3CodSpx4Vree0RAOSAY0Z7HROoLN
vtLIJLJYai9b7yOCxCkutb0tnc0ved+aw9BvzHpfsj7HV3HzNtTFkH2qHtLvdmWtmKQfeZjmkNjz
QMv3t9cdnVuOUTzGZkm+pWnd0fnsWNjq4DOZdqIZHysls7xVumsjSJ+qh+iuK2vFJP0uggwLurP7
M+jMiJzFcN7Q7kHYUq9i15kOq3ptNOcEL6AJNyPNT5CYzvVEEatKSjQioCeRFkZUP1oHiQ/Z8Xog
seqauKCLelZ3mqun25bHBU00a2jErEHGBc2ptOLZdV17+qFCCEgcYGeV5J9+cYjHC7L6VLuox2VL
6GxjDDZURSPggUic9zua76a5GecR7MpoNFOgmD4zanHJniy2B8iWztmILWUxXbz3glGa8zO2VFFK
8denc/G9LSXx/WGglKjlzkluoJKbj6LpSpDFJbQT7a1jSqzFTfg6L7nTswVK+a/nep+me0OYbxyI
/XZoxQiviFxT0aHKczM3B7Slzhew3kR059ZhafRF1hQcxK7PoBWQWYqNx2xEWJGYbnkeFFkm8TB1
5O/inWh8DK57Tn2edryTQiXiAla+m29FLi6oopiuysYFVdKjRiMCmeMwSDIW8KVu1a10fprUSmK8
i3fjsS8yuRlJSUU6V9kxTm15GwrGOzuni/QvT35LX3B2ttQKL+WaQ6DfRSvw7IuG/LQrEtGcUqEf
P7qv5XJiNV07rol853TqZzXLEauKokqV7MfECpLzmkWdnjJKFpac1/jSxfg+UDpEXx+y4+6BrC+h
Pa3tazqy0rqKRwT2RYmVWhnXsRXE+0RYKRlXC/04ybQwyFy+1fUWups9r/P9PoL4MT3y47ac7Jix
OmrpjMWu8dr6mad7Nf1O05MeFjJnsbbUW2xBv4s1mLRY0u+Sc9LFftcyShaWHYfOFmekgRLdX+og
c+sZtvSUa+WofhdDtgv9rsRi7Tizj62gitbsWCndebum3+kIEuU5Rb+rC1phpdxHkMReI1YONNgY
F0XDNsIM0TBE0ZXkOY6GF3ht4tF8n5192X0zzEd4XsEyrZewcQ05L7suJj7KMnUE6Rcsszj7U/UJ
y8yuHVZkZX6NZR52EnIW5WaEZRZre3eQkH0iW8vKNdfLMX5cRVl5Pdciv6pR6sfZjk4LSVpv8OPV
YoYpqRV+AsTCMnNcvO2lzI/vTuXXu2xsthOzZ1gJpKuu1mOQebWdV9m6c9pclriO5mw6GRkFidNT
mAvajCELY0s1plpRELFGsdFhbpyxpQdOO9eD2X1Ithct9GCb/2M+tSfatB6VxB9utagNfQl3BdAv
bKRIsdpoZd6ubdgVHbtjT7vYl57M6ol3tmOVHQUqMtLZNuyoN3dyaoiE7Bp6Tc7DuxsK7H5Jup+b
3FuD9zycEp/KTqUB1ZasfNTbwKulbVfK8RSB5HOeSxVxGW55AnvaB8t15z2j3Cblsom49Lvj+6Bn
J18yO3TyrSXfzP6cnPZ0d7f1FZS/NsefZusIlsMt+dpaTCk3NhoK+UxbB9UL3fsZc6OEtKDfUW5I
RDtSy1yUXJQ1svuO6Q1ewMEpqW0bnVz15zmBj7NItz3ltZ/nJho5LTeRHqkmtvsUN5aX0IMpNx3l
pi2T1oyn6wMW5Y/eJ7EV/QAk7jnETDblj97B1qkUNzndnUa6o9Lf9pwbqbvTiBt2+4nVfMYbQj5z
0R/O+5nW+5ngC86ofPeBc9feOf3vUNek30GLqBewEXopl8DTGbEC6rUryaWiWtlyLokVWK9Nv94G
nhyXZM4hrRT8eIkHiuzijEqxj22c8ldHdkE9gt1zE6w0jMGz3IySmwOVlo+Vgo0z7xxJa0u+7sge
yZFb5hEjCc4OAq8gcSo7Jb+mvFaR5IJ3gNXucR03uz3nxs5/Q2/ZHma4OY2s1PpmKjm8we3ocRdX
8fzIuQtacPzNRS/2pEwkLX/awnJYr+SGxlK7eGyhOx9jbnaRtMKdc2Gngl1NtpxXZBynK9/Wuu0+
4IbsZqhYb2lJCa2bzTYAYmu2EXW4zSd4OpYFIH7NlSpZqgV/gaeKSHmWP7t7jvLXIH9AiZwloxzQ
L5qGlFayFEepUpnmOQavQnL2juddSqacY4rf7JjEK1luM7Gl/IFXiWS6o/wNy/z5k6GWQ9KbdCXp
uRjX2q2dxcPfYb8UjAjEC4y0x5G4hp4PHUk99u/5e41stpnunmhJH3SlhJLYpUs1Ys+E7cnXJDIJ
fOQoVYQPK31KqRJf+29R4oSPqidfE9+Sls0MTzpox8mG5BEU6XEJnhSdUdfkvBxt0S4jG9m6M8KH
olKGL84yX6Pl4Sy/0vJra3V03m/5pvd72tv8gs2FdfOc1c3b3Mh4stEXlSzNokjJcou1GQS/aym6
OycnWW69brcaUqqk/cZfO4slp/OpXP3t6itl05PWNXvGky3PWJ332pr0JVI6DpSnvGx21OaiHrWr
5ryKXStxe7KtbHbha1t6EDYH3vcQ5GStzu3SroNUlr1eQet0KHVS3gb+lPeDMz6T5DOdfKnmyci+
6H2rYKtOyg2hZMcWYX/BP1k57qkFjlLKeyGb0hGhoRZINU9298378Z60SBPNK7LDftH7VmitXjZK
ymac0W91RkdzJ5tOysb6EHc7pM2MknuSKhbTuTvR6b0XY9COs9U+2MWafWJxz9lSndaSb9yxb9cC
bH7CjgiN4Nzzbde/6oC/89F1iOxrcjrK7ehfFW2U9js6TjdUp35tINfvWtrviE5d6Yp+RzPjNvqi
ttUv9LuR2NaBjMe2lI5ea/pdRX33QbbubJYn1zeobGr5tRZ85PpdS2VD4xYbF8yMidjvOiob4lkr
kmGKow06K2zwngfbm4jHXTuW+rNJ1t7oeGi9SjbOoH4QV3GpTJsSPqw9UYnuGCX7dUamXjZWosQu
UOJ9JFObQa7oWEpujNmTPt16rxHm5paPoh32lqcx5mk2L2C/aPkX3D4zuypVaCP9usrWtt9TiVf+
fYIjWspuKayiG5UTX2jJa7C57Dqn5Zxq2766kKwNbNx+sZVf7MlI56zD5rDs2CEsBSiJXR5oYfk9
HpJ7mAENkptdzI2NEchIxuwWVwLbwHNLb52yd4KQ2FeTvWvuRhN7Jw3aE8kXuX3TdE3MQraBVzsm
uv7t58TgxyMvULSWr0JLuO62kWTpF+PiyUqYlVkOSAxxSvKn9EZNVxrtOOOUBkqJZH9KTppW7k6q
U0Jj3/NyHwHb0mjfBKdEY6N9W8aBHxmttbVsNCfvVbnyZp4DvxJsMevbW0G4vzlYwTh33sOWintZ
clbQU3sj5yWriI94D5egRNpN1x/XWAG1Orujh0p2S0szOiBrrxa3LuPAexWWp2O6peXJXkFPWHhM
5+mCZ7iNRQClkcMqd15y1iLI2tb8KUzLc0v1eCpLO1o6ewrT4VLbIru0cxYhJU6tiq55012GTsti
74qkxMbMap4D3gY8L+X6wF6Wn1HfN3Nri8NkPdie2LqlFXSyXWM0BrNSsrK8ZAUN1V1sI7TUj6Vp
K2ioxZA54horoJa0I3dBOhuhpcIzRpSoPS36SWzDnutuK8sP1E8mb0XylLg9Rb3WRZsFsVRmd5eN
G/YRZG7nmLMneqNl/o4BGz/tknA5R5j7upmBuzjdxZkub52Mr8r7T3qOMNYRZO7shC1tqMTzFkPj
CXrbcHhrisR00T57hkv7WvJOL5jfZcc12gd3oywNHh9yYpFNMlza15KjStSDh8Cts3oa3wF8R0vF
GUhJiebsnAxuZwWxnufOBCmsrdQKaLyw1bLUZx5UKJmzAhpVbkk8s8YKqCXtOlkaPH7YPTFnBTW1
p+SokrYCGsHZHSTMRmipiPIjStRiol4bW0SYv2dn1PCT7XKupKWLGXUV+hT7omQct5gN2/NQSZkm
vugiiJ/ngJyq0rpPdxGlmlJK1K0jiFqqLcjpdB99nefvjENgpkgip4F8kc/7sbPWzsbrbMxcxzpX
pHT+pLEt35XxgRnueUqJLBnlIzmmB69Sk5MURbkZSnuIVyRYG+lJc/rmjYWI/AjZjXPLeVBoXRtF
wG12BLd3RAVfNbM6SV/Sg++6uJRQ7RKndyguXYHrkiP4cjxO55PDLiol3IS7wKJ4nNwO7HAzIzj9
KmSQ7Xd0nctSpTH43G2NSInG4P2qEXzGCnyezEPmzj3bUrK/YMkKaLRB7611mqWlbd4KaIzTETss
tAL6hpJtby9L6Xr6kDjJxyhRKyjJ0PR05HS6ayVVOk/r56JapEStgLy6cReRfXOQkLm3Cx3+WVFM
Z2MmqsdIy6cssu/mckTkZRmHSUbRwpiul1Y1NLI0eB6IMOYyp/TtLUspkzclkVgfeHJ61JIqnXn0
IsKVlGjOwZ6CuaUVnEaQudNqtnRXbgU0U0nfKKn8TerEP83lhSwlIqGWzMDXWAG1JPrWREXuqPdW
EPlGRonak/CTOSug+fHuTFKlM49+Pk9nKVGLmem16Ugm6C6fUW90BElYJisnmYJ1uYhinmLIdoEn
kkvL2yodudstk3gX+pQrn8texZEWu3O4KMvfS3vv/YoDrCOQ/d41GdPnbJXOJnv2KlSeAxpLdTtZ
qpjP7GZuw6/I6OYozdyAuMoK2giSuHGLlRNvlLcCOjbju0nMSmj5XARnKVF7GY6zAtqG3q8yBCug
/rWPvDajRO2J3ayRlweNlrpRUg0RNVjBXE7MUqL2FN2KEiwiyGnFDD3KReAtYLNfRLkIqpXMGXiL
20RfZ3MRp+ydGwcj0UN5S7e7BKXozCWrO8pF0NXnTH7c1hflIk4z/EFvOYto2P0KwOWOwO0IM5IT
rSE+DuvBI6kvvkVx8N4DrZHmOZbuXTuLIdYuVIAc/A5Q2I1DPK7djUH32zBIlBsMnIXIfoikSV9b
p1QdhOQf/G7mM2I3dk8umS/GUqE/a18aduPQt8Fiv2Brc705HvXQP7WyViZ9+92ZpEpPnVSHeJVk
IW9Fvx457bBKUpOMwOzXTcSZby+0ruT2GEtpH0GY96U618SWGYRaNKkhNd4lonZr16eSUpPED1Zg
291VqfoE7W2wttZbHsiJ1Od66mIe1FPlPtPC+kDD9c7DGqpgBU1UUxtRtVqbOcuO9kS9gIr2qx4G
yVl8FiOZz6RR4JxVRafiKhX3lsR30WvrNv8o729Ot87plsRadIcNnaeNfmdz8OMl/ZjFH3Td0VHq
VeCpoqcZ4q/JXMX5OL+TFywz8gKzfLSBhhvPekaJvI80x8eWfD3SHZsNyiyMUuWy6QnVbsd4snvU
szxV5Oue7o70I2PgKS8bTWVDd2n6N7xmcockv8fezialAxnJ0BeslZPLoVlMv8M2yKnNfn0gX/dk
f7srrcrlRFeqR3LWJbyYkpNTT74e6E75JthCkEwBT+RUgpMNPdtRI/4MT+T8spPNIL+W5/JyrTuj
VkBPOTVBB8m8ShPa6GSzlV/Hr0iH8UzmotWctDT2CqynpTpgd3fZnZnxydaa7iOwPmQvS/2eB1s+
BnkcqJe1XNLzI0kfW2oFmvYQelLG3+CVs4JT2kNa+bU8Q5izgj3tIXQvfBOsbd4KGtpDevl1I2RT
wBPJAdL9ObR11bxl2nUQ2kO0/HoUPSTXOjpzGmlPbYIO0nINM0Unm0Z+raMe4mIY8ndmDYicNHV9
Q8tS6r3aBUp0XGtOZSnt682+KBetsVb/XS1L/X2HtnzMUapJW+hp/3ArG6FEXkmi2cvSeX+g1FKd
kzPVczN3egId/VMuxyG+3snawgne9J6Hdiu/2CXnKulcdIJeLeltM94V5ER3Qdr+T/Zq13T/ji0l
N66EVx3D3hDaE+j5BtdTD8HqK3L3yejHM5LxqwhuhTVhT6RSoa8E23cp0DLdO8Et2j3uwOlITpS9
KGw9sfUzfs9giHrOSGRF3y6O7xOkVtpxK7DStPevtIR/ktnZRTzRPt26WZnzHpYSPdk+cFzfj+0N
WAlKDS0n/biJfBylWpH6U2+rDoRqS+acMY6j6vsMWOY29CkrX7oaQj2/9LjpEaElcx96+w0t7WiL
DnlKNZVZLylRLXcka5l6MYe2/oxyEPV/JtH9rC+w5V0EIXP2VA6D8rEjfFgvxXoOGV1Zz9GUJ+v9
aA8eyVhKbdXu9GL0tnRvSNzD415rx5+YS2wd41NJzop8i1uXSvTOPl13E0vI2zDEvmRsOdLfndIe
zHiqI55INpliKu+VwdORDCj1ZTQr0xNrdPZH7R3vyRJ8JrVGVpbd1zW3UpnroVZ6Sq10SLd38HWC
V7Etpu9SHiF3kDjZqU5bZPfNxXzEGlI76sdX6HzL21X5147qeIwj8x1Wt91VR2Izp19clyIjHT2n
HGdDmVaaQA97MN1JybCIxdBdIWy34BalkY596cuMDreWpRUtVXmf2Z9FELLfR+aApWVq4v8PM7OD
eGzm412/k+XUE/fJ3cK+tGerbhZmY2lyq2DIwaTG0tAbQi663CZjO6vdqTlmkyQTy2wyOvkraw4S
Z3Vbzx/XHXtlNm9hdR/tiQ0lykfcLvcCcMSHlBa0LrrJo0j6JE7nnq6OR4F4rLUSoFkS/xM8HfGs
W7ILIdZ21UpM5w0TEqeZzLiGmvRE9lVN7Ynixv61IjeLu3c2adxSsTjTckPvmLF5cyEPzrHdL4u3
M3QkunFrUWSvXMClN50KzIr6J1kHxvHxd7sIE+PMBG5hi/y40LB1TrIrjOHOcEbn254n8p2ekcQ2
qkGLGoAnsu9nnb685060bohwqxkuB1GDbF01I5We1kB2eqRaN5eh0XS3uM317WWpP11oy0+DZCuy
/i3fb6tmXqdI7y9wGesh0KOr5wc/L8De5W/+sWf1aok1kLjK3UIcRVR1yo+TbGgJN4Pm9YRZPsXq
KTf2VcoZboI3JBInK5IJHxd7YvtVh5gwKyO4Q4zbBtvPaSWM5rEkOpJzqMksiuFUTHc2R3AaSYLu
nqBc1pybkFeJuWkbyU0XceNk6XGAp5ibKmAxbkiuRGol5A4TslaRBklEyDCxt/h7gFBHdM3Ozl72
flxDye0o34p6FTs32xKv4qLoQ+o7/pWfB9PvdoQDPc8B4msvdzIPpuVkTO+HMtpB4mqXq1st0oPW
0S+ybalIZon6WIzHqV4G0qcOJEaYk/WOjS3UShgNnaNBcyW4lm/nd1QGMWch4hK62SEmRKwWl5yX
Zrg0FozkHuoMlPTZDKWYP5XChNh3u9w6m52O67G5aMET8RJM8zazl32BCWPftWPcQM/22B2b7A4h
TdZ92BgXzVU01aP3LdDvDqXc9JQbm2/3IxxEGGSdiY1xM9zEPnHHspDxGKfj2Nx+t0thklGK4tIX
LgojDynxLmrjaTSqtNE4OGDGj0pin26Ru+U/o5Ug8baSNbXxGBeNg9qPcDDbINzEMjuNsvhM1r6l
Mn46ncGNNe927/oRP1hBnC05kNxnRfyn631bjhOykHRti+7uSlClEvV9mlgBwaK7eJivneNb0xm1
q2NA6+daq8nM3f591nKq0jI18T1uxtVLqprm8u0cgO2nG8lNU27XhW2RnWG0wQrSLY38E+0Jdo3y
TPI0jBIHX11JSxBzW9SiDxHV3lMNceYZ6f+0FaVeGXpLFMfvoli/PUicUWRPoAfHmWzbHzLW41dV
PG3gKeKgifx1TfZTJvoxuxWFcuP2jwvcVDS8TbyIutwfMHakdnvwvSF4OraCPBBtzlClXPpVt7g/
9BzLngx448HfHr7x4I0H1zfbm/PdZnd5cX2zub65erG72Zxvu+bJ/vz6ycX22eFa/POrrzfvbf76
xoO/buyRX0iRnWxUtfnbiYXWDjr9TweouYgTgripYPRQswEJKeiAOwYKjYeOnoCuA2obCATUffh+
8MA2fN974Gn4vPPA3n9eB6Zq/3mtAk2DMwJqS2qqLNT8IkwR3MDAnuDWTIYOtwt068pDm4ZLtrK4
ga4xTjCZ6Veg2xO6pL2EruZ6dHRbxgPSVUyPSDfo3DhZbFuorQu4bbCEjuC2zBIcbk/sYwj8Dsw+
LLt9YGwI3AbZ1IQqsVtCteO26KQwMg6QbsuMEaVAuG1Cy4guCW5gtya4xEYCu4GxXZBiqKsNMghs
NZ7XNtSkCFFiS4RqRetHqjWtHyUQ5HIaGhWIbn2bGuIPCCrpzgG3DlR7jzoEAl3gNAilDpwSJxPa
H4RyFpoflHIINBtaO9Lsae1Is6bGBh524lMYq4MS8VugaVJHGUXMljYJMRuqUsSsGU14y3OCBk5N
NKcHK9MxNFUzOLEAXhA43jJ4aF/H4IQbBg/t2VIw8QoUzN0YglUVah0pelB1y9BJ32Zw5h4CuKbi
DeCG6ieAWyr3AO4ouFE4Og7MRD24Z0YKC1oGPHIiDkzGWMCuHVhxbARrjt06cM2xEdxwbNcc1XJs
BLNW6m5wA3Cg3VKwoo0PYOoiYVTGdhJ98gLiwnlBEO+OwslIrVmBJhLmXxAZUzgZEbYM3nAL9vCW
mzDCRZQQ4B23VQ/vma0iuOeDrIeTYEEx+MhsG8EDs6gAZhYVwJHCMHLTUmFYUEmFYYESCnNwEi5p
XqClwrCgFgrDYHAUCkN4LxSG8EEoDKNCJRTm4CR0qRl+xRXmwGTg1AyuhMIQrrnCHJh4e03BDVcY
glupsMaJv5UKw4JaKgwLGqEwBydRiuYFrVQYFnRCYQ5Oopgtg1dCYQhXQmEOTgKPlsG1UBjCa64w
ByaRlmbwRigM4S1XmAPz0T2Ae64wBA9CYUPnxD8IhfmCTijMF/RcYQgnIZhmBSQ2Vbxg5ApDeCvH
dITXXGEe3nCFIZxMWloG55OOAO+YwhBMAz4G77nCPHxgCkPwwOJGDx4rpjAPZqFEDTN1A2a9N4BZ
7w1g1nsDuBVyt+OmJnGKpgWKxEFKlJDRixcQb8gLiDXw2iuhdYQroXWEa6F1hIeaRwYX3dfDpTUg
XFgDgoV2ESy068BKaBfBSmigd/BRagAL2kgDWKKlBrCglhrAgkZqAAtEKOLhYmTzcDGyIZz4+pHB
K6EBhCuhAYRrrgEEN1wDCG65BhDMI0oPJp3Xjkc2AtUkTmtZAfGUNS8IStsxSkSZvIDUzQsGbhYI
JyHElsHFLMfDxTQH4a1wiB4uuoCH8y6A4E6OYAiXIxjCxQjmwL0IORAsQg4Ey5BjUE5otVCYL1BC
Yb5Ac4UhnMwbNC+ohMJ8gezHDk5CiC3DH7nCPH7FFYbwTvYYxOepuwAfmcI8GTmCIVyOYAgXPs6B
ex5yeDAPOTw4CjlqJ/5OKgwLGqkwLGiFwhyczIU0L6ilwrCgEQpzcBJCbBlcC4UhvBYKc3AS87UM
Ll0cwoWLc2ASpGsGr4TCEK64whAsBiUHHsSghGAlFNa70YpMAlpeoIXCfEHNFYZwGqfwAiUU5gs0
V5iD15UM6hEug3qEy6DewZWchSG+nIUhvpiFObCW02ZEl9NmhItpM5JhaZsAHpjCPHgUCoO1IvO7
FwrzBa1QmC/ouMIQTuI7zQsaoTBfIIPLyglUBvUIl0E9wmVQ7+BKhnEIF7MwD+ezMARrMW32cDFt
9nA+bUZwzfMcHszzHB4s8xyDWzYaZdCBBYMMOnyBCDo8JRl0+AIZdPgCEXQ4eF2JoMPDZWoV4TK3
imtachaGcBl3I1zE3Q6sRdDh4SLo8HAedCC45kGHB/Ogw4NFlhL1SNKFFMzGx0Z1DjxwIgjm6wjK
VdlUHBvBimM3Dqw5NoJrju0cRtNwbATzjHNnQ+S6Z6s/AVzRxgdwNHq4djYyw+ALZIbBF4gMA8I7
mWHAglZmGHyByDAgvBfOyMOFM/Jw4YwQPsiAGuEyoEa4CKgdeBTxmYeL+MzDeXzmwI2YgyJYzEE9
OFKYM2MSvLasgESvNf+iEgpz8C4a7rEgGu6xQA73Dt7LGRDC5QwI4XIG5OCjCKgRPoiA2sN5QO3A
TSXiMw8X8ZmH8/gMwXwlJYBrrjAEN1JhtRN/FJ9hQRSfYYGMzxy8k8O9L5DDvS8Qwz3CBzEDQngv
ZkAeX8yAED6KgNrDRUDt4TygduCGRB+awWuhMITzHAOCFc8xeDDPMXiwzDEMrRN/FJ9hQRSfYYGM
zxy8i4Z7LIiGeyyQw72DD3IGhHA5A0K4nAE5OIkYWwZvuMI8vGUKc+CGRB+awTuuMA/vmcIQTOJv
TcFsHdSDNfeUnfOUZDxqKZgtpQdwJ7TeI3WZqPAFMlHhC0SiAuG1nPf6Ajnv9QVi3ovwViRdEU4G
7Y7BR651hBO/3TK4WCn3cL5SjmAyzmoG57seApyvrCOY2LKmYB7neLBUWOf2lGiZqPAFMlHhC0Si
AuE0sccLOqEwXyD2WSCceO4tg4ssuYeLLDnCid9uGbzmCvPwhikMwWSc1QzecoV5eMcUhuCBz3s9
mM97PVjOe3vtxB+t72NBtL6PBXJ938GbaH3fFZCoXfEv5Pq+g7ciqe7hcn0f4XJ938GJ324ZXK7v
I1ys7zvwIBMVDt7LRAXCRaLCgUc+7/Vgsb6P4Gje2zhpyvV9XyDX932BWN9HOE3s8QK5vu8LxPo+
wsmcYcvgchUE4XIVxMF7kVlCeCcySx6fZ5YQPMhEBcJlogLhIlHhwKOY9yJYzHsRzAblpnIdT8xH
Apz16gAmOQoKZmMygluxwcmDe067d2DFaSOY72TyYD4F9+CR024dWOxFRDDf94RgPr0KYMVpK0ek
5bQRzHdJIVjx6b0H00EAvLSrlLgzLUqIdEUJtWtaQD0aL6ELhaKEeDVRQvwaLyGD44EX0GCDFtB9
qbyAhhusgMQbDE7nBayATgxYAZkZUHgng31fIGMChIvtKgjvhf/xcOF/PFz4H4SPwv8gfBD+x+Nz
/+PAXSX8j4cL/+Ph3P8gWHH/48Hc/3hwKxXsLJ8mVnkJGfv3/JPIJlwBXSTiJXSfoCghgYQoCWo4
5dUElnteoIVNOng7SJvEgk7aJBb0wiYdnC4XsYJOhD0eLvJlCB/EaouHi9UWDxerLQgfRfLew0Xy
3sN58t6Bu0rkgj1c5II9nOeCEaz4eqYH8/VMDx6ETbaDM7BG2qQv0cImfUEtbBIL6OSRl9CtkKKk
kjbpS5SwSV9NI2zSF7TcJhFO5muaFZBoSfEvKm6TCCdTNsULRGTn4SIliPBB5HA9XORwPVzkcBE+
ihyuh4scrofzHK4Dd5XI4Xq4yOF6OM/hIljxHC6CRWbCg5W0ydoZWB/ZJJa00iaxoJM26QronJ+X
0N2eoqSObBJLGmmTWE0vbRILBmGTDt410iaxQEubxIJa2KSD9zID4AvE5lQPF1lPhA8iTe3hIk3t
4SJN7eBdJdLUiD+KNLWH8zQ1klEiTe3hIk3t4TxNjWDN09QezNPUHswzBTWaKvfBHsx9sAdzH+zB
bOqg3FJGR6KCLQGTkKCj2KwvBTDL8gUwy/IFcMc5cYELGQu2FKw5JwiuOScOTALvlmIPnBME80lM
64YrsWDowXxG4cE1J1I5MJ+WeDBfFvVgPg1sRgfmZ1E8mM/JPJg3p3Gab/nEzoP5ERUPZharzF3C
yoC5+ejGYfdMaR6b69Jj10yXHrvjYMRmovLYPLPlsQdugx674WDErplBeOyOgxGbrV0ocwjTYHcN
B9uUTUdc5ZZiVxzssFve0zw2N3tPmynNY/NchMemK0AUm3cSxKazG4qtORhpK24Q7thgX3GZOPsm
0fGWYJOJ3JZit9wgEHvgMkHsnhsEHiLlvgqx6cE0QpuuvVBs7sI8NvcnHrvnMumdTLjD066n0ZV0
iq05GLEVlwliNxyM2Nw9OuyeJ4oQuydBfkuxNQcjtuIyQeyGgxG75o1vXU8TbsaNDQMfjhCbrmET
bH72M9CuOBixR954i93zRBFi93R3G8EmsWdLsEmoWlPaFQcjtkieaYc9cHDtOCF7Oih2x8GIzXyV
x9Yic+iwebDgsWuRmENsFis1lVOx4nPHAOcjI4JJQL6j2OJwsAPz/WABrDltJ1m67EfBfERHMA8i
ArjhtBtHpOG0Ecw3DCFY7H/yYJHvrRwRoUwEC2U6cC20hmAaQpsYt3OVknFXixIiXVFCF69pAd22
wEtI3LTlJSTQ6sQ3xNJEPYHpAy+gs1Fa0NPpKCug81FWQCakFM6WetgHdK2HFZAuTeHR+o0vEBt/
PFzsi3fwgbjXLYOLTQYeLjYZIJy4jZbBxSYDD+ebDBBM/QmDi00GHs43GSC4Zm4pgPkmAwTT6N7q
0Vk+Te+JEnLXBy+IbMIV0OO6vISE9K0oITGSKAlqOOXV0Ks+WEEvbNLB2WoWK1DSJrFAC5t0cBLU
KF4g9jZ5uNgC4eADGfW2DN4Km0R4J2zSwWnSmMF7YZMIH7hNOjA9WU7hdLM3w6+4TTown/4FsOY2
ieBa2GTbOwMbpU36kl7YpC8YhE1iAd0hykvoBhtR0kqb9CWdsEksIFF6z+uvuE0inJ6k5QWNsElf
0HKbRDg928gLxPYtDxe7PBx8ICHXlsJJ4NYxuNiWg3CaNGZwsS3Hw/m2HATT3UMMLrbleDjfloNg
nk0IYL4tx4M7aZPaKVhHNokllbRJLFDSJl0B3djLS0jCoeUlJHFRi5JR2iRWo6VNYkEtbNLB6WFh
XtBLm8SCQdikdqYht/niB3R1nn0gNrIgnC06U7jYeeThYucRwmnSmMHFziMP5/lEBNMNUgwudh55
ON95hGCenApgvvPIg0WetYGZxiD2MLY2MzeMstsgunDxHl+mZRFfbFL1+Hyp1aGPLY9SHPbY8kyr
xxYLDogtBOCweerGY9O0kI0DnMBonC1K6N1MvITujKIFdLMZL6G74kQJsU5RQuxT1BOYPvACOvTT
goGO/ayADv6sQCxqIHyMFn+xIFr8xQK5+Gvho4oWf11BJRd/ES4Xfx1cy8VfhMvFX4TLxV8HJ6NI
y+By8RfhYvHXgRs6XFO4XPxFuFj8deCOL2p4MF/U6LSze7FPoXY2JGP5dnQ2TLqPKAns73mBNBUs
oFvjeQnp0q0oIRMhURLEccoKyKyw5wUjN1UHH6toTdh9MEZrwviFXBPGu8CiNWEskGvCCJdrwnh5
mFwTRrhcE0a4XBPGy8bkmjDC5ZowwsWaMF5+JteEES7XhBEu1oTxLjN+6sCD+akDD5YJhBZvbov2
zmAJCZn3/BO5dwYL6O5/XkLGk1aURHtnfIncO+OrkXtnfIHYO+PgYxWtCWNBtCaMBXJN2MHpmQ5e
INeEES7XhB1cD8ImES7XhBEu14QdvJFrwg5OlwUZXMQqDtzKNWGEy+AD4WJN2IE7nvPwYJ7zQHAf
+UnlDCzeO4Ml0d4ZLIj2zrgCuo+fl9DTCaIk3juDJdHeGawm2juDBXLvjHIW1kubxIJW2iQWdMIm
HZweW+EF4sSkh4vDPginC+YUTlfMGb44nYVwljegcHE6y8P56SwEs12YFC4DX4Tz01kI7nnOw4N5
zsOD+ZqOW8Qee75g68HM2XooPwiMl0zylW23iDTypZvG3fk78qvyancB1Ciu3/TghmM3DtxybAR3
HFw7MEu918jgqDm4d2DOiVv/GcXlUtpNBUYxm3eSGvlghaIaBSeO73HgYMf3OHKwleAUilccrhDO
r0XVFcJ5Q/HyyariLXXnoyc4T1w0Hs7bGuD85lV3MkxVfJWOwEW9eFsn3x1bK4/PtY1XbVb8HGLt
ToNPcCblAULaCcqk6a8w5aLHSz8rvgOtVih7zWXsLyDVQsYoey3sGmWmeVtHfzOrsGwP58cFtOeT
W1Tl72DlM9cGZVzzldPew3nQNWK7RFbfw/m5fV2jrhq2BOtNhHjOmoLZTg/PJD9qGMBc3x3aQcNl
0KNseFaj7j3vvF+NqNuW67z3cK7zHnXLt93UPbaq5ToP8Jbjo8xabgsBzvvV6OG8vR7ecdfqddsK
OSC8Uxwf5dly+Xh4x228xnbxSWRde/q8XZ2/2pfbeIfy7IR+Uf58s0jdejq8XR3qt+Or0g3Kp+cr
5AHOV4MbbG/Pl7EDnG8Ta9Dv8JGXwHl7vfXzPSa1t3N+wxSB8yB09PRFH0U436+hR+wX4kKkAOeH
Fny/ENfYBjgfnDtPR+jXw8U44fnk7Q1wtoOkcbd3K3ofNcBH5+HJeLmFI4oI53T8Swt0NKYVVDQy
4DWQQE+zKipRgHWQVFnH2jBw+IhwfjU6VkDvw+4IfXF9dqDPx69AX4moDOnzcTDQJ2PpyPjn70kE
/msGD/xrDvf8E9samQ7E0wFBB2RwUEwHjSjwemZb6kIbSHzSMhnxMSzIqOJw3wa2CY/Q5/fpB/p8
eAv0Gw73OmCbExuNdMhYDlaKdPj+4MZtClT0Tm6Au37MLvFmFdAghdVAFy80rYKEQbbA18G2woUq
SBzRsTaIfuPbIPoN0hfbazz9lvtkT1/spPX0W9FvkD6JGUamg473A89/y+Gef9FvPP81N/egg0H0
A6+Dnpt70EEnCrwO2JZBogMehfkaGtFvsIJG9BsvI7bJkNDnl/YH+nw6GeiLfuPpt9x+a4fPn8ho
6gbhvN/ULcJFv3FxAL2iXLEK6FYVVgPdkKJpFTQhrWkdfDt1qILEDh2tgW8hDRX0ot/4NnD/7unz
m80DfT7vDvQH0W+QPokFRqYD/n5M0IEYP7wORL/x/LfC3H0FlSjwOhiFuXsdDKLA66Dn9ut10HG4
1wHvN0EHot8g/Z5PdoIOKg739MX44emLfuPp883TNT4mweMuhfG5EmmREfuZ2JWPcbvi11PUI/LD
b0FQfnwaxHzK4/O5psfn1ybUo3+ugm+A9u0dWZyp6hbhYot/g3A+V26dH9I8D6J9/C+2lLrTZkpX
At4jHb465ucFfLdRXXk6PB6uPB2eJML7yit+O1/ttrgqetU3wFukIxJwfk7P9V41iC/0hfMRfnNf
7XYQK3Grd11phHM9uuP6Sou8T+X8veaHokm9YgkAkyH0Ju6RF1AvwUvEqmsoEBeHhAK6gYoV8B1r
Hi7vzAwFfG9agHO7C3B+o1KAc/saXTypxeGxgM/9DZqLOFTmXmJTWlyv2tg13ylCF3C36MuNIlDh
RhSoCLijIqCOCN+zjo6vEmBcumLsufMbit57DWe50DprNvslcNGrNfIiTnmh9ZPeaDbKtw3C+a7w
AOeRaOvbyrMSAZ+bGWZn6S3cDYPztH+AcytT6PX4LZgas8Ls0mhj95hGptdMDwzOtxQFOLczjRbS
sAYTfPF4lsKkIrsXXJTwFRxSwLdSKxzcNF80UZi0YFdZK0aKRBgjL+BXS5ACvpUjVC5OmfnK+Rsp
hFDLmfVwfgopwHkEEOrlx2VCvWSlHaabmPOhd+FrUSJWhEkJX36DAitzvqGefBGpHEv6SOW+RKrc
F0iVY/U0L8e/4KZOClquDw/vuD48XMjd1zxyPXl80bddpECvJG8YXPRtDxd9G0d+8V4RrpjQC8mt
vAd8r4vGiKKE39xFCvhNLFBga2dHohSubdBbnG0X86RIxDbyAn7CgRTw7eSh8pGL3Fc+MpF7QvSm
9IbB+ZnIAOfBK9Zb8+DP10sv9oYupms0Aho2ixK5WTWUiKsQcQ5BLyIXX8jXbLCEXkWuRIm4rC0U
iMt3sPpabpoLX4hreXyBuEE+wPlGiwDnpu5r5g/rEXy+ba7yL9bxfXABzoOoAOejGAbptbg7E4P6
Wr4Gg6uP9G78gcF5gwNc9G0XL9CbvjXDl30b15foHeBKlIi+HQpE3+4HrJ33bfcsiWJ38ytGqhXD
ZygQw2coEMOnr7zlw6evnD8RSgjx4TPAxa0FHs7deKiXD5+hXjl8+ie9atG3SYno26SE920ogOpr
3rfJF5E7x5JODp+hRAyfoUAMn776Tgyf4QsxfIYCPnwGOB8+A5zLPdQsfLnHl3JvsNfXMmwJJTJs
CSUibGnQtdQibAlfyLDFl0RhSygRcg8FQu6+ehm2hC+E3EMBl3uA86PioQYu34AfhYXofOguYpjy
+VcHG2nx4RvS28Q3si+Eb+g1cvwb0UvCJzLI9AVkozeSsgWkX/E6ZL/ytOiYrdk3QxSw+m9IK8U3
MpT1n5BMNP9Cxrj+Cxnj+gKSWGatp6u0vA4ZFXtSZBzhX4hw2X/AkrkEX4TRHl/cPePxRXjt8UV4
7eHiihjfZOHHPX2e8Gxd/2h4Yk3hlL0RVy+0LcLFpjnnrxpxnUKgz28uCfT5NR2BPr+tIdAntqdM
JKIwt0mvsnNFYDdQNERFvqL4K18XSejzqoiHG3lNfSVLsCIVfYP10EVVUU8tSkI9Wpb4eqJvfD00
2OD19KIk1EMPwPASfvpCdQoLWknMsxZV02FJVI0vkdXgq8j0hDdtDL2XbaAc0wvYBsbXIL9AidEj
dqwOGrqzOoguG1bHKL/AOqif5XXwezhJHVoU+DrkF74OfmyT1NEL6fo62PkGAm84XCG8FYQ8T7IG
VOwoavBwUQPqmx65M7tdifWOoiTYKB3djd90p3sUvZPZlaCn6gZJDZtSR/Ugz3VUz4DmG9Uzov1S
22LtGZQo8e2hO4d5e+hOaN6evpLUsD1NVA+2p4nqwfboqB5sD3sQjbenFiWhPfSaCd6eWpb49mhJ
zbcnqse3J6rHtyeqx7eH9hnenl6UhPYQm+YF7BKW4CtJOLHj7e9FgW8+CSh4Ab9SqcMRll3Mz+UV
tcPLS7bDF4h29AiX7fDyle0YsUC2wxfwduBWU/rSQkPV0bEuRoRO72/VVLj0fktNZUgvnmyoqNqo
jg4LZB3Y8FHWgXZFz3uydrCuRdtBN7KxdtAdPKwd9O481o6oDmxHVIdrB712XdF20IvXFW9HzQtC
O/gVYaEZ/Oa50AotCPlWyBp8K0QNvhGiBt8Gdu8SaULPzdy3gEfzAc5XWvyoSGy2Yy3mN4CFFvNs
TYDzbBD2bXqZ+Y4JSPDv5SP493DBf49wwb+Xp+AfPWMl+Pdwkc2qUP60T2uiAXpnuRs3vSulPU4R
qdKXK1yJ943R+Ox9YFSPd3VRPd6nRfX4MYP2bdaeMRo3sT10UZe3Z5Czad+eOA7A9rRRPdieNqoH
21NH9WB76Cq0aE80bvr2iAl9aE4tCnxrotHZtyaqxbdG1uIbI2vxbSF9nTdFDlG+JXKI8gViqMXR
nISoHW96Lwp800mH4QV8Hu1H8yhg8KKSrfCSkq3wBaIVOJa3shVetLIVOGTXshW+gLfCj+U0d0l1
0Wk5anoPS2fwRLTsOnIqQXapPpVUG9XhvaCsw7s7WYcfP8gXrB21HDWxHaRHjbQZJFc90lZ0clzG
VkQ1YCtkDdgIJWrANtCbh1gTxJjpW8Cv1wwt4Le2hhaIMdk3QND3/Av6nn9B3/PPr5wN/IsxyvMv
xigPF2MsjuHiOujQXn53Zmgvz5gFOF819WO4uDU2yEfw7+Uj+PdwwT+O4ZJ/L0/BP7pDJfj3cM6/
H8PpKXitiAbaMRonvQONxlbvxqJvMIdBj3CxetjDJKweequ64vV00TdYD73ZhlcjRxZfixyLfCXy
C18HsVleh3Sxvg7pYn2BGCjQbCvpxT1TsgocDzpZhS8QVWBGphNJ8tD1pL/0fUx6WG/s8gsnKfpU
0EiraIQ3wxoa4f2wAomP9MXN64G+8DaevvBOnr7A9/RFftvTF73P0xe9z8OF90A1N6J3e34EffQS
kr6HC/o98i8idO1eu1L0NnctSuilBayEPhuMBdYOmBPXVYdwcf4Qj7OTKJdXwAdkUsAOxgU46e0d
ZUhcFuQZEgdGUU6VEqtlpGYSw4oScmiDF/C+S8TEtErExLd7u23sIw2sWQXEMY0MzrbzEzjfphuk
JHaMeCmJY6xeSmIDiEL6fN+th/PjqhqP53f8WKpWbqyjl5BrRl9sCuyQDtlNAfdx4MZuekF5I0rk
A2KhRF7Y5e6lVvQicFtQ4yfkKq+GfSLWJLS7iVnR+8A1/2Tkaw/hE7pgKz4RF9OFT8Q9TOELcXtO
VWOBuBoS99rTRwt4FURZmtdBhN+wT4iXEp/Q3RDsE3FBVPiC7pJgX4hresIX4m6V0HSWbiEt57c7
hRpIt1HMhEjINNKCXr4PEwrExSvIbS9vUkZue3EXhnsKeSQWbw3O19AIs/IF4hKXUCBuUw488c2g
gSUmwLrz12r0whCQkOJzOC9aeke9Zl+IBGf4QlXCDvwX7Awp+UBxbXt8fgeqb5wWY1uDbeBnzQOc
4RNhDKLNvmLSKxTjtBFt9l+wo5nkg5Y32eOzY2EEv+NN8/j8mH4QhRi/fJO5/w9whk9EMYoWo+WR
uf1I4XXFG+DhijOEDeAnJLy/pvf3w/aPAeFiq72H8/NZAc7DMDzf0vPzR2ocEc7PPbnzoOMg+lOF
5Pkbvh5O1/UYnI+neFyJXgMOcIVwcQ2GcuzwC8jwJhZ6A3nD4PzGlQDnp8IqlIK4o1V5NoV0bLNG
8b4lXmDT8weHApy/OETgItpAI+GXnGiFVs4PXNd6dOzwq5Y1diJxt1WAc+kEOJeOxs4iLnB11zMp
em831OubxcXg4fwOFQLnYtAoBnGBJt7L0/O7UiBWsXB+ti/A+RlBT4bvE3CXeSl64XzD4PzJpwDn
MWCLtsxjSYWHpHr+OrNyl1QrerNzw+DidjEP5zMrPELZi52KeOSy5zsbdY3896y9BM59bYDzXdt4
tLwXV5ng0fKeX4mi8Aohdh0/JJDxEiF2tb8oIW0WJSJ/3Xu2eLqr92yRrASjRFcgeIF4kc3DeaLN
1yyeP+rRrvkZWnLmluDb7YS+cTJFFUrI9JMVEB/VKcYVTxx4edAtlpwSz5QEOH85CuH01u+aVDyI
Ux8ojoFfrUaOGnO3g0eoB350WI0twnl/cPfCqUHsKMQrgujrC2D3DcL5Pd4BLvjxcDEHRD4Vd3eo
5kGJfuLhvP8PHs77f4CL0zIeznfsDxrhIjSoEM75H9ygSG/214wO39HZIJxf36bHHumI0z6eDj9N
hFc6DTzcJXCehw5wod8G6xV8onw09/t4ppc+4dIwuNjhjXDx+GPjchSDuAauQTmIl5u0P4LPghuY
4Fv6XA4BzuUQ4FwOQ4X1ipMB2B95qNjgsK4rPj65mx4VfZumYXBxwgDh/Bo7gMPvRtgD6qsR8mmQ
HxHeYP/lD00SOD/cE+D8ikU9YL3ijC36jabj9aLexdXKAS7O5CKcX3sDcNtfeRiDVwvQe+bNoWg0
c3qwhsH5q2IeTHbsU7C4Xw3B/EogD+bnthHcMQ8fsMlkzgRaaJgkXtszOJkjOTgIpufZRQw86K3T
PcOvOB3Ep0dfRlovWZ9mcH5PUKDPtuAHdkjukqE3nIzHJ+RbWi25PYHByfPKhPzAZpyBOvHiFJ1E
cXuKHqzplNZJxjgGJy8qU17YAo4nTuK3M4qtGRGPTdIhpuNgf6VXq/ACEm85uB24eETnOzKJzw4M
v+F0PD5ZcmH1ElEyOEkmEPpjJTJDnj65FYPxM3A6Hp8EJFtSLw3xKJwe0dhSflj8iuTpteU1Q+c3
9QV84qc7yg4JLBk84B8oeXbbWKBO3BxD7xgVj07uD1KhUvpkxZ7C6X1yipCnWTxF6NMbTCg+CV5q
hk90NVJ+SO6NwfkdfYEfdpeZJ0+vI2HompPx+PSiflot6bgMHujvKXn2ymegTnTF0DtGxaOT9yJo
naSfM3hA7wnxms1fPHESXZ1R7IoR8ayM3Gw6pNJws/HwmqvbjeHspRADd2M4vc28Z/ia0/H4ipuN
r7fjZuPh/CqvQJ/N1QL5npuNR+cXQQb8lpuNr3bgZuPhPVM4kicRTkuo07QXQ68YFc/MyMwG66Th
JYWTcLSnxNnFd4GXlpmNx24YEY9N9l0YD90gnAybvIAkHxwc6Hci5e5ib/rixoHhd5yOxyfuj9ZL
ny9j/BD3R+nTkIvSpyEXw+d3sgZ+SMi1pfwQ98fg/FrAQJ8cqqfskJCLofPLNAM+Cbk6Wi1xfwxO
3lgl5PkDyoE6GWcpOgm5DhSdnMxUpNKBh8cBzsNjT37k4bGnP/LwOODz8NjjDzw8DvXy8DjAeXgc
6LPwOLDDw+OAzsPjgM/D41AtD48DnIXHjrymF/i3lDoPjwM3LDwO6Cw8DnXy8DjAWXgceGHhsSOu
6dsAZxSbhccBW3Gz0Q6drjxVFm7xO25OiE+GvD3D53f+enziX+uKwOlwDfkr5Ec8HFk7+nQYZ/zT
R6IofX7VcKAvHj/19Gtuxp6+eJ3Gt3fg5u3xyW2gDL/n9urlIx4J83JmG8U8+yQiGCj3xCEz6iRQ
oNTpgiYjLy7O8/QJ9y1tLU2kk9bSF9oZPgmAKD6Jp/eUfZZ9CLLh24A882IFwtGmp3EYcWKBjLpm
vHjq7CxLoE5e5aEN5SOPlwtxugydREoMnzhjgi62o3nO2WF7zzk9c0E5D+I6o7SD6g6Udsc48VJh
GZ9Amy8SKQduhbF7uFipRFb40pHH5qv0Hpsn4j02z9e5q1i1fELBw+mOdpMJwyZ13HQDnG23COCG
WVeA8zsPPZhfKu/B4u54BItrZxHMM2cKm9TzWayHd3wW6+4j1Oz1AQAgHT6L9fi9mMV6fD6LDfzw
WWyA81ls4IfPYpH8wGexAV3MYj0+n8WGavksNsDZLDaQ57NYT53PYgM6n8V6dDaLDXXyWWyAs1ms
J85X4Tzxkc1iAzafxXpWxCNGSES8udEjnN9THeBiAcUzww4ENBiQ8IeWAphfZjp46iwt7lbBteIP
LQWwWAysEU6mkqagRzifsAc4n7C7jZyavgMAq5yDw1d8wh7w+YQ94PMJe6iXT9gDnE/YA32+uOrJ
8wl7QOcT9oDPJ+yhWj5hD3A2YffkNZuwe+qaT9gDOpuwB2bYhN3XqfiEPfDCJuyBOJuwB17YhD1g
swl7wKYTdhOqt1jAZuyshE7ZXQFUEd1Y1bkvajppZ190gpT/gk7baeU1nbczrujEndZBV9NYHQ2d
urMvKkHKc0Un74wrOntnBXT6zuoQl+J5pugEnn3QCEr+CzqFZ3XTOTwrIJN4WgWJjzpWA53GM54G
Tsh/wCfyHp/ecU8ZavkEP+CTGSzD5xN/j09nwpTPjicEVIf4xClQ/jueKAj06XOUlD5PIAT6NecH
6bc8sRDaSzrQQNvLEw4Bn/REhs8TER5fPHoe+OdXaHn2+bq7lw7PWwTpEFfKqPN8RiAv76dB+jzP
EejLaw+wtTz/EaRDPALDZ3mRIBx+wYanwo8pIfN0Mz7lnWdRAnFigZR6x7IrgTqLvAN1lnQJguHn
PH07eS4moPOUYsBnOZrAOluGCnIRR9MQm2/pQs57ltEJtNmaVaDNEj2BtjivibTZdgB3VammuzQU
gSv+sKW78VRrcVGCp8JvT/PYfCuSx+bBmds+q2u+cVS57bO65jM4pRTC+c4lt+9V13w2qdy+V13z
nRIK2az5/lmFAq75jguFEqbXG5qu7e7bF2tnDYaiTDK+rfzBndBWcS7Ot5U/uBPaKs7X+bY23PB8
W/krj6Gt4hxgaCtJZ7m2GlbpbZGmWcg+PfxrWKyQf7oLqWEFbEu/vVwN4DwidxULZ4X10vc1dpQ8
e5DDOAl3abCmL36YToUZF/rix47UQK8D25IKGnbRBCvg/dDdSqwb8VSKb4LYJ+dboEYO7xDO9xG7
W5I1fZFDsQpI0N/wGgSnvgZ+AUOogZ+M98qnS2lc+fzQCyngt0wG5ZOkrvI9TCyW445B/kQgaS9/
6Iy0V7j2YBN8CuFtQlVcEK4GesVQx1Q/chvycN65g0nwUxWevthqiXRa/tqucqdCtDwC74616Ja/
5qvc8RXd8ou8lTs2qVslHHSHcO4Q0SBa/roekQ93cp7/SsgB+a+4k/P8V9zJef7F2XLPvxiOPP/i
Ms/APxsb3c0Emt4ja8BonPyq3h49Ln9ytEeH2zPZ9+hX+YvcPVbJXy/ofZXMEHocRHo2iXW9hG9V
wGGIDOe0iXTBlrWRvWnm20jXj0kb+fHb0Ea2v8+3sWPW4tvIc5q+jfQI72kYgEgPaEh76NkQTdpD
ojYz/AQ4O3bd+5Gf5zuwUp4BxkrpY0A7Qpw9+jMEcdHXiaahx2241vQNol2gTm8+2wbi9HoM1VA4
S8i7h4F1y0cLzzq/rMNzTgblJqhf81NkPcZz9DAaI07CP0adxe2BesXASF0zFQVN87ODXqNkXqSp
pukLMUTTdNK7D7Ecy9liH+JrNEH9fL9dUH/PzCWon6Vyg/pZ3wrqZ4OwVzOxrR0Fs3DTa5/vnfe0
+dZqT4Q/KO4uWNEtP/vXo5Pn+8J79PF8W3iPLp7vLkfdt/w9NdQ9vYOnJnzzvVuBb9b4wDd3Q8i3
5m4I+eZraJ5vfjLU882zi55vomKTohjR2uiB6wl3RE9Jj6APFM7d1uhHJs3xPbzj+Gj8ZDIL+B4u
+HSrDfRC8o7wzx6qooyyl6ooR+zJK1o1fSML8iDKF1SiYET/MPICjYFeLVIquPTH3vkizaDXaCqi
hpZd0Erh3NeOvv/wvQEBzo/uY5vpJS96oHB+OTGqgV160hAzoisq1IzIlKOhZsQu9yPmQu8xoGbE
nsMh5kLTOcyMRs4nmhFdnSL8sxfBCP/0CbGO8EkfHesaakOk3h2zoUEUoA01YjrobUhsBgg2xJf9
vQm1bJroLaUVmvRwNuR5QxHr4QHOhkJvJzSxweyHzTe8+bQs44Ws0yvwTXohWAm/swDh9Gp8wPdW
wjcfIpxemQ/43np6jj8gPrvHALlnN+kT9ukbcJ2mxjNyuDeegcPRRkhIeKC20/JsmzedViQM0HKI
Dg/UcPgzwt5w+BU2wUBYlOPB/NK6YB8Dw0Zwx9bdgtn0DBvBHYvxvdV0LJXrrYbMFUdiHHSqyIyG
PSrsbUPxFEGwGZZbD6YxcnQPZ8/9BpNheeJgMXyzk7cYOrUgTNIn/RThhj4B2FOL6fiiobcYorye
WkzHE7feYjoWv3iL6Vm0402DT9GCxbBAxZsGf4w6WAyLX4JpsElEALN5XrAYviDjbiDU9MZ1mHTV
aAT8ZYQA55dYuxsINX1iAfA9nEdTnTdVHk0FeM/5dKlx+rhDR/jX7L4kwqhmV5YTjnQv4iOsmj5v
aEIUd3hS04cSAe6r5tHR4GvmwdGAk6ROzO8xbBWrQdiCtueBX4DzkRwbRh/T0AOF80iq8zbLI6kA
5xEZqoA949FQE+KXkXtTIeF4Q01Ii9kfmgq9WJqaEJkYaWpCmkdSAc4T396EyCytJvzT1x87wr8m
AX9H+NQDj4y8/dDVqB2xH6rfHbUfHhkF++GBkbcfep0/NR+2/9JbiViTDHA+KUUjoSfwqPEMPOGB
NjLwGCrAWQzlTYeIeEssh84/FbEQMkmEDJGH88sivYXUIqPk4TyKChbCoygP59fJesOhp7wJ+/R1
yY6wSd+j7Ag79AXLTlPDCewcqN2wswXebAYWE3mrGVhI5I1mYOsG3mjoQ6HEOEYW5gUwG8q9bYw8
6+XBLHoKpsFzRAgeWQjmLWZkYZK3GDLbGolhNCK75Q2GXeXk7YJtpKH2wnZoebNoePwUzIWtjHhz
IZPjfWCdvpyqRmotI4d7a+ERkbcWEqL3xFqIRntiLSNPZPlKWTjkrWXkuRxHRNwPi5zTy2w7ai0s
aYPtoTfcdtRaWC4HW0nv4+2otbDICUXe8XsMBgxw6TM8ExgDWRJ+afMyO4JZntXdjaHpDbUmvMW1
Rv42tXs6WtPreg0Y7ZbvKHYPG2t2gzBjnK/4e8752X3POZ0+Ec75CxGe85YlMT3nLfMUnnN+w7vn
vOVLqp7zhk84PefsDlgK5/OeBvsQiXkJefps8I6Qoc8Gm5hrxMWQiqXxFW5ErPmjHUievu61DdTp
PciqoXAu4AatkRsS8s6fzPWs8ztcUO70od4myJ2+06sYcZ7HD9R5UsNT58kLpF4xH+2V2nJ/GcyR
56yCUtl1QV6pLc8WBKXy5HxQKk/OB6WKOZ5XKjNsr1R+F6JXHpdM0CnzXl6nfFnV09Ys3+6J8Pto
sJ/Sp19U6Kcdv9UG+yl9EEaFfsqexgka7fjyAWq044sNgW+Wbw8yYY33fCvmoz3f/GZFz7fi81Xk
W/GJKfKt2Nji+ebvUbc4oJOwwIBx4KbJ0wmMAzTNkU5gNOeBLQ63aLUDW35r0bkObLRo0bkOfFWu
cjYuAmPP+MCziJ7zgY2hnvOB2WzgnI2KgXOWOPCc92y08Jz3bLTwnPc8ge45p/cha8J5xzMBHt7z
GFIheWJxhDx953tHyNAHw41H73ADi+Lhb4V+kc2CkDp9aGIbiNMnQhSplD650QXe6YMbmrBes0Hd
c06INEHs9I3rJoidvhCuKHF6RRWlzp9l8tQ1y3UH6mznVtBpxyv1uuM3IAc4S3EGnfKz2IF30qcZ
72JxHnVKnFRPdMovvQ06ZW4+6I4tAgQwD2m9Splz9bT59kNPhO8+xF7a8c2H2EvZ3fWhl3b85lHs
pR2/kwoVKi7xR4WKu/o933wroeeb7yT0fPONhIFvNlYEvtlY4fmu2Vjh+a55PI988xVoHFXFmcIR
43m+a7R2L8jrju8yrXtPhznj2t2DqTv+Qn2A8+tJa3fPpu749acBLm7sbz2f/FSWh/NrS+u2RXjN
4cg/n0zULY6C4jrTAO85vkY4vzM/wMWBLYTze0LrAXsH9e0U3nM5BDhvV4B3nD5aQ19x+h6uOX0P
5/YQ4EK/WC8ZbU29rcdn97kF+CDswcOFHj2cy61B++y53Dx84HJrsLOQ0R82X9duD5NoV6DDnQJC
+e4OhPI7LEe0QX6SsPE2O1a8Tg8Xx/QQLDZqI5hZQoPbMzt+ILH2cTU/kFj7+I9fnNr4HjQKyXg4
357pq+Vb5J3+enEiEaHiVkKFcM3hngrfsolQ1lKPa9v5t4dvPHhjf352tnlwtTno7XDW6Pqwn/r/
9O+x3+3a7djs1Gm9ubm8fHr92/3h9MU33xyufvvycHF+8/y359uuebC9fnazPX3n2zcePHiw2f62
APNXn15ebB4fnk8S2Kj+Xd2+O8ULcNL97UpV1Rtvv/32ZqLw3W8vXjx9+qsvv32x+X+3F5tJHlX1
LvzP3gPzdjX998a//uvmgToxR6berk6qzb/+6xsPfvvWhtW3mRj7t8N2f7janF1ebXaXz55vdzeH
/ebR+w+mtl4+313uD5sJ9enh+p03Hmw2mw8un/9wdf7NtzdwgceJvd3j46vDYfP48uzm++3VYfPx
5YuL/fbm/PLiZPPoYoffXdxcnZ++MMRPf9j8/vJ08+n24npq7uXZ5oMfvrl4cb15/OL588urm82/
PIOSf90B+J2Jq99N2jBUvvz2/Hpzdv70sJl+P99OuNPXf/jw9yebP7z/+GSzvdhvbr49bP7w2Z82
p+cXL27Onxq24dM81sYwfmaace2a8XDzw+WLzW4S79Vhf37tmAdS08fPDJXfTiJ7djlZyQ8WNDV7
EqQhfXO4enZteMN6/nC4OFxtn24+f3H69HwHVD453x0urg+b7dQSA73+1orGfDIn0Iebw/lUfrX5
7nB1Pf0bCE19aGLk3vbGcHw1Kc1g3p8Y/GHzdHsTkFdIIjR4vzm/AJxvL59P7fp2qmX61w9A6Pvz
p083p4fNi+vD2YunJ5sJf/PnR1/+2x//9OXm/c/+Y/Pn97/44v3PvvyPhxPmzbeXU+nhu4Oldv7s
+dPzw96S2V5dbS9ufjDy+vSjLz74t+mb93//6JNHX/6HadjHj7787KPHjzcf//GLzfubz9//4stH
H/zpk/e/2Hz+py8+/+Pjj97ZTD3GKyYhbS/pM9CXad7hZktM4z8mRV9P/D3db77dfneYFL47nH83
NX079YjnP8zrESkDle3Ty4tvoKUTtjPTh5vrwwE+BqP94I+f/8ejz/4wcfzobHNxeXOy+f7q/GZC
uDQ4QGW+K02x7ceTnP7ydFLI45sJ7WbzYPPx+dlU38dPLy+vTqZOdX1jMD99H0hV5nzvA1WbreJ/
evz+VOtbvzUt/l/nZ5Ohnk19vGuevP/400nYT/5tAk+w84uDBBv8i93TF5MfeNP4jne+fdMAJ0/y
5dSs51fnz7ZXPzBPYfrms8mnbF48R9GdXT59evn9+cU37wIPk3G92N2AK3rybHt+8QS+m3yx4dtR
Pkz+4gc0PmONk3AteTDC3eXV1eH6+eXF/tqJb3OxfXawFZ5fgwA2jq13oNLN1D+vz7+5mPQ6KXty
HQb/yfkkipcPrSG4mm9+eA507McPU1V9+R+ffzSp9PAUuoerjLZqpuLdt9srR/eJqYZXfPHi2enU
XU3VL26ev7i5BosFY8rRmz574j7g9E63k9GfX1xfbL7bPn1xiKltHt1MmvrB9GHwY+fWA5lh4Olh
8hzXWCG0CSg5obB6nm2v/2K4nmo5nwicT4xPUvnj5x/88cOpd/5/D1eXBrA/303eaCIwdaDJ74D0
EhUYYpy8++IadWuaBKI2Ps2MLJF6/vj5R5Pj+fCxrcSpZ2KpXEO2xq/arzkrZ0+33xCtLDLy8Sfv
/+GxN5RFO7F2CZUIkzReYWp+0EySiYcOMjlxM66eXU8+4vzi5tJV7L+2/Y3XGkg/dOGP6eMfbXff
0homBzkR3xjCEzvPL6+vz02XfDN8/SaMRtv9/tzgb59C3dcvzs7OXx6uXd+duNs+vXFjJaH+m+vJ
FCcXfG68mTGS7789n+qf6gQqzy9vJq9wvn369IeNic0OV9M/J2f+/DB14ovd+cF7dCMzzxK4kqkQ
x+rd4Wpy/xfeUAUT2DuA0J+BAcA0/nhSK+0rBjS5v7+Egfv3j758bBzw4/9t+AcSf/z448cffent
PcHbD9AJt0+vL82gcGAtcnq2gwNaS2jl9YHahOEHBtNv7Li93Xz4/h8eAmPPLydDQBxwegcrVGMf
gCGsAwj9EPE7ETT2dX3YXu1swAJUppFj/yRg3bsP6gMTh6Jn25vdt5MLdwY/IaCqPjMtBrM4GFsL
NC4OB9uRJolvn0O4ANp6cTUNcdeX9pvzs833VjYwcgtVQsGvds+ev/P05p0XFzsfJMS2YcR8ejmN
pW8+vXkTmH9z+uDNzfcQFhheOCuWlJWcbdNkvOBmsWGPL58xZq43e9DvFF783xfnRlMX1NWCmkCd
F2CdW8v94dnzmx+kvRjPTQmDKDxZgr23Xd/UGug6mpYSmtIUsJ5PvZVa070pZuP2BfWAl38aeEJO
SVPvi55hurQZvs3I+dEXnz767P1Pnnzwx08//+Sj6Z/g74xH8Xb9xwvTwWknmKJjEoreRMyC+rbY
dU3tQGhq8/X5FJNb5RnN/WB1NjXDoRqutxc75wx5aCJ6BI9PJp/ghlUXFE+9IvAzNec6Glumrgau
JPj2900nubmGQe+djbK9E7wNEE24HCcCP6aRAShRWzyY3klY5du5IrJ63/n8iymc/Y5YFQwXD5Tp
yTh43QCfewwepyH5/IIPVoQSqQGdHHJufBUfNP3wQ4cSG5y6ptn46OLg2OLVXr84df5CBFrnN2G4
jcaT76cJmx0ZwK/A4OCmG6cHV63zKjPhiCX97qZ31fJi7A7E/767UYHDR0YRwc/7jvUDdCunfdpM
2vVoMPCltXHwI9d2TJ9QLkyjp/73DOYpOF6ZKeT2+vrwbCIOCpnM6vLpd4fIBRP7mn5dnX8DPZtH
VnLOMNF+Yj673oQ+6f3Jk0efffjRv0/1PZ+qnLiz9pSIoMAYnm3/YiYqXvsHUbVR7yePfx+Ru/Rz
G6BMR+lJjM8PO+yuhJhzb5vJUiuwGQyKoa99c+l73OFlMHE6WH13viW10O4E0cXDyfcrSdjN2De7
F1cQLnlq6EJCIkW03uUHgLP95ffOZfguYKOIdxyZPx82f7m4/H4ajX8DM+gtRAd25std9dQdpj4x
4by4MPMcU7FyRIzne8dL6UvoNyaYffr99ofp183m6WE7WezUPW07kz4veG1gcOoLuuLd9dx1CGAv
zD+/+trGPN6Ec97V9hQzY/HVKNrnzswQcBLUSfyu8XA4T95eEEXbcPr86fnND04EqSB/IjWNXJPf
fgfDUyOPSU0vroHk/mAdQgjOIru2U1yj3UvIJp1tdzeXZsQ32Qo3Pf3ucGWC5Xv377sOKMRsWvUE
hm7mbL5kXf8HkyCYOvXND37yZgWxfWaSJTQ6mpEwfu/90P+aXNP52a1zsxOP7+yWE7OA9gqysmYH
T5SVhcpMSvbD4DuhhAkqTsOalT6fjD2x1xavT8l+OAVp0+h0eX16uJrE8ODLaRqx+Ze9gT7712+f
P33n2+evU7GvU7GvU7F3mop1qdV/Mf396uadb39HgTY+ByBNw04mYVZwIBObTM5iKvezjz756NPH
97b3f3Xv3uSz708O/vy/D5MMJ9Dmtxv/j6+qr+/fv++ivJzz8YxPeF8czFQ8PbQY9dr83/Tniwuw
3BeTV9386bNHX4ap1iTO3TQgvHgW8n+QFn3jgUF+cnMJ/9rck+nHE/IRkDU/7rtYMEFv43KtkO2Y
aLjhaorh3rPp7j9+vrlnSd93ZdN0ZIJsfvfeZtj88z9v7kE17zl004onjzb/8z+bGPypEaQZc//q
xl4rEYdiEsdP3n9oi/4G7D51Rhs+uJ4sdxrW77lW/Woq+NXO5HJJ5e9OsATpRw83p1PwZSZ98pNP
Zz75dP6T38988vv5Tz6e+eTj8MnG/Se+/OTdmNq/z1D7d8LAZOvbF09vGOYDE5H86m9EzFfOWq0h
/M0oebKFNx5M8cXFjbUUMPZ7p2f7J989226eHZ5t9/upK7uJB5nPPDHznc1b5icaXbDQm2kEvpm6
+fXTy5uv6q+nfxwmBzs5/wn0ZIpZTyBo9MZo0CaDPdn8l6lpe/Pi+gSyTWYy92x7Yvj+bvvUknvy
bGrnufHWV/C9SW/ciHSyTa6/NVny9W4WCTIfb50LHJhMvnW4mtr81oQ//bwxkyzA+P3HHz75tz8+
/vLJn55MFKa5rM19QJmR2OkPk+88nXr6FEar7uuHvCP6PmprM/VcHb4xxB0y9jgj0ge/M8Sun0xN
efLUeLGpe1WuT6XLN50Tpymc9DSJ+4cnJkycIob3HNj+01UlhOmROOGHzm6mlk4YsQKQkmnme5t7
9+6ZUec+Gs79zT9vqpdn4GcTujOtxY9/t9Gufc5KH2BA7WhtHkz08W9LFohYgzGVv2UbMPWJ/ZMJ
8fLqhydnLy529/1nJ047J97r23/fP4G23w9MWZr/FITu/RLW4iqYLOXyCqtB2/XVBaqyYb5PToOI
ZcJlru00bxoqphnQzdPDA6dCsK3LKxPQ2SnCTTU12VjdN4ebp9BnbVOA9o1KFm7e3gxOaKYXTjgT
lX/eWH6wixpJTuDf/W6jnPoeopKnITKUblpbrM78f598ElAVoDrcprO4tcG6v/kfU6AA0p9Z0L/8
y0Yhb+ZzbWtS5mtdp2sCriFz8p7tYtCEJ6ZHf4Wt+fod332ptZHuhAo9Ay94hrq0wMkFHLaTY3rz
q19ff71588TWZ/kMg1YZCWsEb+LgakfNDOOHl4cdeI2vHNfUSQRtvbfRZnAmLVPSZicbu/7L+fPN
J4BljOvTTx55hb/rLApGXd+VNTVb0/vfTnV/Z8bW81xfOBeRYjgOEj579Ilj9JvLKeLcH+yM/snZ
FAsf9vipEQqKyaS8cO3EVHeyESGSh90PfdlReG/z2Z8+KahwkhVocfp5sPmjE0Nmmr2860I2S9bS
nXQOq6H/jCGUCfeefPbHJ59/8dGH91GCU4wEvLk+cH+9+RHbWW94957/utL7+8Z8IQJmvNwP7Tap
KxPJbnc3L3j6MTS9rMZfmxVQJ6DQYbw2HvzOLy5PQfcqOfjuE+KDyToqoG8C7nv/Bf/c/NfmX1zk
H9V533QXycd/ff1w8/bb/yV7zqUzv8PTMxPbkPDienKmCSI+cQetDUyaELasiSe+iUjFMvEgycR7
Pnj/7MMnjz799E9dg9Gy7fcmC2tSjyamnEa8aTCA3OizZ5N1G//x9HK7t+qdPrBrOcZvg4mYMcD5
3t65bV+ge++UwXv394HCRmBpxLIuvpNU3BijoFgrQgRHEQPX4rO6o5919X0S6dr+cYTgtO+vxACc
++z0Ay42Y2sXl8/feflbiMHfeUmcqPkvSBLbEY1gockb8l+mnbpK4CKqw7TDKZlg3EIqX/7hS2FN
XZUQA+QZTqfvd98eXAaTmVJkS5bHCetX6fba1rYjQ0ExGqO5T0IHKsvqPvxuImvwbZjCNYgUL23P
Pby8uZq83X0nFDstOdn8MzAPRmV74PQZWuZf3e9VrtB8/9B/aEefSwiuf+V09CsYRX+Fs17H3+7p
NN2yNdt6w9QQNPTBJ+8/fvzkg8dfvusoreDJVTEBPWs4nZyv6ouP/oBVeVMCGhAavrf5zfY3xrsS
uLLwq9/c9+03TfEttaK2mv6r/QU1V+/a38r91u53/S5Bahywdb8797t3SGYVCgSxuefmWlPrt1fv
/OXXL8xgSHP59zdB6UwYvjLVvfurqUW75z8IalfXu8lnJz7oZz44vX6e/mCY/+D65vLqkP5qnOPr
YnuT/KLWM1/sdt+lP5hr+ou5Kppq5ouz59dX6S+amS8mO0l+0M198PzsOv1BO/PB05kK5lp9iPBJ
/mXe7FYanfEKhTEDdGhXFXE0f3N/cdfP+uvu7vprQla7q3f2u7S61Qz++c2zJH7SZA3+d9skfrIr
TfjPb9L46d5tKpgz2HT3Nl/MfZDsqOaD87Q/0HNCPT9LN0LPS/U8zZOelev585k66lmm0t1OJ/sp
VDGj6mQ/NR98m2Yp7QmmD56e71d4ArCmtJjSrmD64Ob5zAdzxnG4PE9/MGew51dXVfqLWXO6ulLJ
L/pZe7q60ukvZg3q6qpOfzFrUDfpsaWfs6fnz2Y+mNP27tnM8DXMtfvpnGyHuXY/Tci2wPnvflrn
vzpm/fWeRYgucUDD4pJo8dFnH64NTL+6+vX+67uo+/3fP8a6JyIuR8AD15I50Ke/N2stTRgM43EQ
RkE7Br6colZb25v/enq1u755k1qKwxkCzrPzlymMMWBcf/viLIWyDSjbp8lqTgPG1eE7hvE3JzhM
dl/dX20gb8KakNeHjDBEVmwSpDkF8OTDjz549On7nzx5/OgPn0F+bF2tT58as4Qlho1dZ+BWsZKL
P312NB8vFvlYSbN6OVF9maVaMjv7RPY3u7RnViMO19diOWTztq0hrFNwN+RTu+Y/lm/DFQxrQP81
EVKm22DGL5zFCdmDMjG896ZjI0rvsYVMmsrHumfz6N9cXb54/uQUti5c/bChSVm6HqAhLwgLI/dX
5SQfPsSMnZnTv+tXQs32HZ+uvpdafLwPAoNsjc1Bv5tYpyDLYi4Nr7rJc9VvpbLxbonJ4jqmeJr7
3fIsrpXTfnuzHTa//l+VUrGFmnyJzTZBUsNn0v92671p3xwuSvamAdor2Jumh66NN6dBbWZzmt13
Y/b9b66/vXpx8Rc8DcROC8e71Oj+NGV3qcHPBn7C679Vt7Dxxu9d+/PV+c3N4YIfJT7xB4kvn76A
vXInr88Sv97A9noD26vbwDZ5hz9/e/7UnbwyfmLyAg/eSroEsIbD9hrO4Jht1+YcwQkK+4dJd9fg
VSZ+nh0u9pdTR94+m5gGStfPt+aQjvdFZou5Pel27dvLDlvBeYftZH2TBozpbXc/7IyYv7naPp9i
2A/f/8N9Qzc++HcNpoxsnV+FU47h7MCJ6WnfHyaT3V7jrQl4wsk13e7duzYGvZ/4JgcT+cmIraU8
TY6ub6Cbb2Fbh9mYbk7MuX6yv3Qu1S42mLrM6d795tL2ATgzhIcorNBPDwaLVLa3xxmAjK0Cd5Jf
W1s9PUxy3ZlDXxegovOL82fn/211KzQBRNyJM9E8c9DjxdWOHAaH7UVGyMYpIdfX5njcjdkaTw6k
WEM5sdK3hz/tzpDrS2M55/YoCdqOEc0FOWPgz2hs2V5Fup9yf34Z7bGcQqNvBPBwdXVxGe273MJp
st1TsfHy6fnp+enh6uYHAb/enh0e7MzyvCz44XpqswB+c7iZvG1iT6fpUTPgB9t3dumC87mCZ3MF
p3MFZ3MFL+cK9lBA5WlEdHHz1ErZbU59cu8xdJH7m6npYAgIoMeNzBkJ7zkxZjP7886uLp+ZfT6/
nf7/4PxCv/PtO3AKxZ4Dtach/JE1u7VoGlUOu60p+H7qXhCXnNpebUI3P7D8/uMPp3jNcrmHHRCT
AZ+df/Piyg0ycNhwU9t10ZvJeqYeb3zGgweHC2PADyzs+r3t5CDOvQuA9sA49/3l1V8MFdujzalT
R8xQmYRo/py6oTlCCDbsRebOZkxCmELpp5ff33s5ha4hs2ID03v3DNivNpoFRxPVp4l8O4khQ8Us
TGpJLNBypIhe7l2fTJ/9J+xJwFzQvev7ZupYDU9fwo8pkI6Z2EzVSfjUQgMGg6B7FDfPry4nP/7s
idsBZba3PIQNnRuIlN28KbERemYH9PQv2AMdvrh5Ninvcnfv36dP/n2armxeWkAg8O/3g6HaY0T8
Fgw8qQtH6N3xH2PMLy7O/+8LMLupT9gzc5dnYAnQGrgbASbv9y6mofz7y004b2XjwS2OReAar52j
n3yxO2xvTom5oezJ4f/e5+fn4LgTcCOOs5pJNT3qGS6J+NIdAoUBxowz/MS5m1Run4MXhwNjpltc
Tt3aTRTAQ794yrbVAEV/ssgxZ8dMy97mLb97jbLoRIzCTR2A2pq52NXTHybmpo50ZSa+06A2RVc4
czebUa9t3DCNHFfuRNlzM07ag8L7Pdoh1sPYZBNZfyGG5xNOVc6cOyVn2SFQo3JmdYRTbE4a7H4G
qOszca7Mn5TllILGJ5FOn+Dnj+gpOGu/7loIvJPjwn2MJ3n/tnnLDr2nZh/pW2/BnszD3p6ee+i2
VG8ub54eLlwPtP++iUBWuDsIKbCvOunJqyXElRf+kDc3ayEuatt45uw31/zgX+qINx4BZDK4ePEs
bBTDzuAPJ4ej0AW2nGLKdOOLm0X9W7RA4/Hhhp6Z3qZOxd+73O1eXMHJSXKmeosXkbgTD6yx59dP
kFCoa+7s9iLT6XPa/m6QTBfxvgQPZC/Xtd8/fRIdz/794czM0gz2NAMl+oaI+d79DRyu/O7yL2ao
v2EHnMN+QPQb0VwhHNDk7txfRDBJnNym4+i8fzb9a5qT7aeI5PyGVmjuW+DH/8M9JxDwTGWOiLUH
6T3COQR+0cDvDVHTtSaJKnLK30rYV4vnUz3Pv0H/5GrN8IUcxd9OdngFaJ4Id+bnZ8483Rhp/nF1
eXnDJzS/IWw5QsbT3n/Hp3Lglh2YLD+1uQZ3l1FS8QmR8dsSxLF5x6s4PU9uL7igRnp+ER2jd2S/
mCa3cM2TPe++hzs9wBPCPRXOOfGb9yhV+OQhOZX/xwtxqwObX4Kvon49HGc5mPMvNAY45y0GwcBV
DnvjYMjRaPRenLEXV5GnFBTjs9bc99iDMeR725TMQWL2PTkrTGjI8+DiLqyYjPggUPu3KRx9ZlJh
9tQ0xmXX38I9Hd/C2WveG9056R113F/yI+Hma586MMoSNJi+7Agurw2L4gBQujHPHJUndjiZBvUJ
akRvA0sfTYNxvZ9KRsAcxqTfjG98+oNL2+1lzAedNE52cDuceqPJPzlDFGza3w9JiUPfvGV68Vf1
1w+NEOz11MbX/vvm3v7y4jdmILkSA5v5wGyXN6cBHiLQ/AMOsVtBOOosHKFXpHhPbSZ2NFtExrHr
yyub6XQTz+ffbk8PN+e7abSDrktTZ1HXpbVxObFwIt1tQ6d1uSdxoUHS2G2X9ZfRBCY8lp1yXVsJ
veX4iGwFpHlzBXAa6lkYiwDfePD/cQdIXaKI+FTXp3jbJ7E9d022zEA0tUn/RwmzOYaf39rB49mk
vHf1yQwVS+f9P59s/mx+TPL78/tfeFKTOR4mRzBp9frdOsmIOUcbWuWxhVBhD+5MQ3ig5CnAeiXX
4O7bv1yniCDCJHxzOcwMljEig7D5X8axYgxp/AEfd96aI4BUHpkhFHbtTp3C5u7McbTNvUmM9112
mu/hzvx378/w0SR3m9We/v3FfWvDV9dXu4gzc29amjuuCcCD/mBvGzPscmleHb65fshFB6DbiG6O
QCw6JzjXaCI5fYTorPhzkjNbZ24vOST3/fb7J+7QRYKgmbO4ExkTh7TTG9KOlHExprtfU9/iDoqb
KqAsuBJZIvyM6UPgAM2sR+QfnKWK24UAai6FLnY2jyRN7nXcnApK0lQMDUhyGpQTuKstTOa4bV6/
OJ23I6/ULJYZdSB68T31fLINDPvj7vAyRw2xAOmr5uvZBn70cvf0xbW95oV5QLPNwQzxc6w+DxPF
Z3SWDLxNZjPbTvY1MTDXr/HKLHcr1f6h+PTD8z0kic21hVY2sBg3BX9GWt/8Pzwin8b4i4yJfDhF
BmbGCtZhsa+JvRuvnrb2yRxTpn6+S9j5RWKGcm/yjL+d+vg0NTuHe2XF7OVaJAcvn4eRFiLhb/8y
L2DTMhLf74EgEctU7zEfG4kAH9dSGgBNCgRKEjKx4eiEhCk5dqng97+1Pg1WwXB17PqAN+JCWL8X
s6aJgYkUEdFU5UMWXdhri95yDTCtsY2TrQFosjVQIlrjEb67nCzT7DWZlEsy4iebd9555/7m/S+/
/OLR7//05UdPPv/i0WdffvxEPeRffr+9ulj9JQnDNkZt5qaSJ36ZT1ALp/6DsT155m7WIK1EWT6B
xPX15h4XsSElIYSCv37LsIIIZrPkSaSJzFfBFtKfmt1heYogVLjp8glMge6xgcRRkC0/O0xexd45
YdGECBOfTA72Cab8HTZUPWHTf0nOzAlHUpFpqIFLtIns9cFr1LTkKsXUZMvuN/5TsmkJhWD1nv1a
1mcS7MaYRBW5f4Ei4EdaSqG5E2HYIHGEXTIixDiEzKCp51dn/roNaz20vgj74ok1ianK75683CT3
xHmLD9YzL5LZGu6AtlOvrOLp5eVfXjw34bB13ctm677A+xCv+CeRGcKGTaIeO8uU4k8m2LFXuxn0
jOFN4wGcpHeEZVJhhqHwQarzYMrjCUt1pPsZ0GNT6KRt8dz2OazjeW6jxPfJbEo8FlqEgnL7Zmdd
aAEpYPGbw82T51eHs/OXT8w4ldXrXA42sUBV1BZH9OnT7XNwW3uzsWkSLL27ONllbVPd6hPv4tk+
s8iMoyzx8lR5uxPuzJrLHNFFpuTnGYMLy8VL3oPt4U24dbpumqaVZjOkhtNd5/rbCe0vayi6nYpp
ci+ut99MNX386JOPZoR/dn5xfv2t6dQZrpzeT81NHAbLtDt2Kzh64UID/9MPbAkmYKCc3A8XJyU8
T3PeXSQqcnvYoLmGdM41yiK4Q/eJ+yeymvbZmNj1DYulhigJyUDikHD9xoM4EH52uDaqtVGti9O/
2z4B57a9cqkdB5xITeHcPQM2FxfBh3ZHt9+6cn2zhwuxntx789fX724+Mlcevbt58/4J24JiP/ou
+sozY6pwSFtzM5Wt1EJeHl6eT1yo+w/dvWSshXHAXtDChfblWvjnqT54p+UO2/g3nI/t95vP3v/0
I7znmO8UPHEXZcPbKtOE+4v3/2zzrn/2c7B4NmKSzJnpiD2CNhv6wXVw/go3c2rNp5feowkleTUK
zTW9/Z69X5iUmGsWGJdvkcsrXl4d3EYiwMX7uOQHUx+hDLgK7FV2Bv4Vsmoui8LNSoSG/eLZ4dn1
4ebePTc7EF/Ck2dx9e4CIYFsb7OZKns5oe5fTMF7sIoIFYT7Xrh2MUIgqUJ/hw0gukMcDP/tt7+m
VnRldxQ9xQ2zJKnhHrYwm6HOv9tOn978P8x2zs2S59LEc6/iqede3yeT/vOH4TKkvXrwO2MH//Te
Zq/hT36XG949DTf0nNsbes43/7Jx303/ePttvN3OkYPGn3+NJN0/vQ0Jwu6fSnQ0FFGU9nCdLypz
KSHR2cyM13cyOtHewJp1PDk23N4PC1SPDRDrg/uwL2AfO9wrRfRk+ZlcoVHq9qlJXf+A+yVs8vpw
/eKp3aKw3Tx7sft2c22s3r61kGnIJtKl+fnQpyCnr7+qXipz/uXrh1LBtv9sfAeCO72rcIfe9G/X
W6R6QTpUuaYep8mv3TEy4IHsgYqp2FtbaW3SXgxZYhtvv20rtsShvd49SEu3jJu/rAW/t8FvEYrO
LEqAbORmSI5hvBfQuh8Z/wlp8XFNDKx9BaQm72AuSQtr4h9ewt6+82tiU2hSPnEbdUeXjov6o3AW
1oxtSs9w5dmaDP5XcOjnXmAQDvQFIPzTdddzP2T8jfgSnxN8j2YB5fBDE4R8+HF51Pdip5Yegiy+
HATIR5MiKSN0GHIyQJ6NElzPIl4JS99+O+Gevjk3R3jmctOb7MabBTfFM3t2jTT2VRY6s7LmVwPj
7wz0Pt+yAClos0vv/Ip5EZ8Ln4YmvJjWJ9cJDE0Aatz8zt+R57+ULtixBqw89F+bFpGvfR3R17bp
5mfcR22PwHS77BE2OT/Z/oPfTZ8bU3W1TMZt7lMJxWblwQRS0AQ5fGGHBfXHPgrI2IYZDFeXq4qA
oQ5XhY8iPJuuL5H1geiWO7J0wPuSbQjpS07F6Z5ksWVP8p9M/YgyQfuRExjya/qRsyLSj7A09CM6
e3vjwXwG+nxns3m7p4ftld/beZ0MZ8yFfrA85QckI8n4SzCFCTlaRiMDmzQng+8WMIM9EbbPd5PR
mGsPzFLiNEaeRBznCL8soPwySxqd0yeXl38xL1dOQoiWix8aeXzwxUfvf/mRfThmu7k4fA+7x90G
QHvduVWvVd21uyGdb60LC/50GxyNUvOLBGY7/RM7uwHlTnZ442cyZN2a/NOsdd1cEcjL68OOBEJ+
LdabxYl9js7bAmzR24e/3bK2X6Tydypc7J5N8wPC45uPPnj3zZNNza7/9H1QTiz8h5u3N3W40I/U
x64RDneCzhKit7rfg3ab61pvrnbfXt2zHP7mP//zN/fvm5Cb3JUa1QjfOzlFFL4qJeBUERF4e5GA
i3AemXMYeDTq2fPLa7NbxO0fgAh7Gq3crudn8GSRWaSwi53ulS9z0OQsbKQ1NmkkYPzXxe5gz2Pa
nXTk1bSDPSb9/cHuAHaH683dqWFxfWofyFfqGByJE9zvNojyqyDL4HhhIHMiIqhBalXQvh/4bKGs
1Zn+4eVNMH9vdda2tzeX56G+tzfqPmPkHvnYK4zhpxXH2EBi5mvTM9zXU794W72t6jdZt8D/HH+q
fkjh/p6Pf7Jm/D//s6Ec/suGSh//s0mkJ/fedFcmHCzxX1/DbpPJ3++fHvb/eWFSPihIUunfmLTR
/H6TtL7Jr7pnGK25uc2R1gqnqdvzp9vdAV9vdFV87w7t+aNR0I3xESZRxWRpsH/l+/NrkzEySaRn
l9+F7emHZ8wW/2nWGLnFmP/eii2M2S1Fje32b3OjUyKE8nZgHfjOhkvgqMASQkXm6YngcKyFwR2+
7htRJC9J/Z/Q6f5p/mNXFMfB5lIQ9Obio5ON/2Mmfnb/TQRggUh8f9/Z/H3WVmvz7wWRXMKoZstF
4Ajq9QMfQXhAPKWZCxovBpNAeDaUj9vMWNx2m/f8BpvIbnbJSNFu4JGBVzpOnHDNrU5YwRQX+qkv
//z+feHlbBy/wyBwY4V0sf86ET1bIjQHGHIY+BlPZLDv7jP6ucxfwCEjld/vxjF8aEnnO7xvEUnj
V6Gn+eoRxJ21/OIrZnm05P4DuKF/cRghArC+GHaclbhB46EOWAS8wp3J5kJ1syTuTrI51sE2zUCK
G8TCXlJ3A4Q7GcA3FoZQZurmWI0ZDlwboKc7TSRuxf/YHHw82Ty/fP4CLtP3Vbl9qIffXB38aX2y
89lvCH9x6syCnG1DBycHobcw5gqdxg9kRd6V4C867tgiYN7B727yZa4IU+huqSmFZZ+AiONyJ4mT
YI3Oor6HmzHS8ZAUohXQ275vgNdggSqpCILVhysFHhrjJkJBPADINy7Z0+yHzh25QMGmu2jQjX77
Yk+mWR9PZm6OShi7d3tff2PeFD19YCu26emLpz88tB77+sXVwe9ZNecDJ/Gdwtk+qNtP5RIzqdm9
UwfFd08dfJI/mkOrjR2U3rpnd8YclE0WR4haImr2vs1OBU+Zikr+aaIQYZj/kg+o+D6R+oqsCxAt
YOgBnGD8ocNTBfEK5NweMicqu4R+Zp7SOrt8bvytvQjifPfOzenTadL35pV7uwFM/vTF2Ve6agYq
FfMxi1/ssu4Ur+62ZvA2L4hvCFFwnyadOxmPiVrJOw4fnl/vtld7d6zbvOLjXdeZuZLBPAdz5rM0
099TyHv2HAm4DvtPZzAmTvBIRReo64e8I/vJdgDdPHvuIVTFMR+bwEgikOPPZuFvx+qjx48/f/+D
j4CCH/AMtc2DjfqaRldJhElpv/nP6jd0VmTd0cS8eUbnxdlDUaFplgkYf/PwN3Mznbffpk3HZgNF
IDl5OdpuEbNuT02K9V7yHn9T+dtvx0yfY+QR+y/hmZ33gkIetFDHG8fob5rkTjxP4zO8GcrVw1ms
uQRaQDdHzs4vXhy4OOg47k8g29DjapqWTx3AHHfw3pQcIRWqnGsLG544/xfwDjaRlrSOKe7wZgl1
CA3/lf8zZTCohFKjMf8lDMdJK/wjjLeyRtEAb+Ynv/n5cG9ovuWIxozJzhFKZs3PxT5uqOLkwpSF
TRzop2bq9yu86pOV2oDLxOdkgmNCq/vCbia8wpjqaPYTbK9gNlP1VzEVuxZpuwdRIemun0bBDCTj
bCgThTH2s/97DbaR1QMzppgxP+SZdp3Q7eRsLeJs99TcBXAvDIl2DfT0xTdOvrj9581f77EF0xB8
YiemNI/+kX1fRKS7zREyc19AWP4jYzQLO9J70q8O06gJfz8/2Vz4P0z8b30ZTZJPyD5Z/dZbFjkA
LiTATiMMwK+M7Eh63L016GehE3US19h+ufHvBgJFy/R7G1k3LoHHPNis2XubwAvUYCDoZZyn2iWf
6Itz/WAPeFqKo4UFAEQSsU1YWmDDWCLkmQtLpP/nzjLhi4v8MKfCpGP+S3vCuVnV3JSKp+nNHxgL
vP3mcro3l3mGpi9mnwMfx2egI7bMf+bqIFO7qv2Ti3CD5rVlSjHfQzlZlb4mjRQpbPPfUWls89/t
Utnmv2hI/adUXSSnIMZT/qpUgJO1MuLv35/iMD9tNV4futPe7HW8kEuB/sJE8H17yveji/35d+d7
8TbdtbvFDs6M2jnx5FimuRNcAyKvVSTkDCdmAmWy6dMcGzu5SYois+cuu2UE8ZZbDXWMnhBKU/R5
PpcH29xzp5nNdahmIndx2Jndolfn9tIId2XBow8IPWD1PjNBtqgo1xONEzTWY80o7gHefanIESzO
GlxymXkF99E/mW0bc30f3X5hXGXxT+7ZUWExDsEhopQ64K+jbjdWfR0ynqJtbOMVHzLMf9HaO0Qi
J5OLmO1GNMz4lY0x7r35AYjadW1YWIdQI2Sfwzuyf3q+x5vmXKIDrnkJcZQbgieG4Q/4HIdftvPN
jbyu7bibGjdxXURJEkgxzZx7mwB0dzH6zwmcnFE6zuFq+w//z+Mnn/3xs4+AJy8iTsFdfJwn8ujT
zz959NGHBXQ+LiL0cY6SuTA9T+XD9798P8uL8W4LjHz2+MsvcjTccbNdnszjzz/64NHHjz7IUrq5
fL5A5cs/fh4opHH++OW/ffRFMreWPAjpnA+B7L79y4mIbL+hThjm5Gh8dkeI2YGNZyXhmhELNnfd
iCSn3XF+9f9n70/b27iRhWH4s3I9P6KjObZFm5LZTYqSrNhntDq8R9uh5ESOxw+fZrMp9ZjbsElZ
nsTnt78obI290YxzlvcOr8QiuwuFQqFQKBQKBSbpWHNpQfWEJnZcEuAsZ0aB0qfzHMdr5fTrRPjO
cnWw0C6zkX9HoUmMG0EifGdpK7iHGT0rBt/rghf77C1mAXpDMq6wp3IUOssDZPaAGo+VwpOyMwaY
aVZnaYFB95OGjahV2U/6JFfdo/WAVcJDqNyuUA9HqCipku0tiaKyYiiYXzxDXYkWcCDhbLHDZloX
kQ43qW0l8t/rIJVXLO4FSrU1FDBQWUMR2thCAf2qY2okO+Z72fmnuZ84iQ21gZ50QY/+T6RL1BPa
tA0lOSTTGUKJ14pSD/698AdA2eBVkceDIKEeWsh4Q8/y1lm+QxyrCwEyOOSXJFTEIS1wAQxEXKWQ
E5BnUqNEFcmAceJobG/jpQANqilyBOf8UgWynoDjXLN0PvoiTh0s6XUcjEjCRdJqyFCtGeHkVA/n
QQ8aRUJE8JRJhjL0e030TcBHMo/5pEcnOlQAxzGjf4VJjExgdOpqyEaqgqGo2I4htNqefxCV4p09
slvNPsGoKQforCHPP2R7bR5/pvtrrDcgWdS+DfyzBv6zG3yugXd9XIKIiJc/4/+70qkjbLiz81yi
m7CTC75Alk8BrzbJzQ04tDuHcYDpoxDaqS6kPNWEDAhWNppwglDRHv+ePZE6n0dcy7ehdbu9bhNW
muqL40N4U3S8AaSDQYyvrv5GSq+Z3p0fWYudH1uLnV/bSD26eteBcuLiqRgCKgc2Nsw8IEMeO8Qw
A8F0QbaL5qyB6DMzs0woBn1fHB0rjswbB2G7CcfskzcO0j0mHOPEG8exFcfAEwftbwOOce7bFiYZ
JizJbAl3iYoBaWz0/oj9bQHkNInhLDD626d/E/qXDWT6a0b+zujbWT7HmTsxZngAVrSwW2AI5/BK
pZKRO80NZyFUbgTyngGyncfxwqU4INHsCLIVoOqpOYMDKugFcMSWR+/oulFQmt8T5ObzoexyxYwi
+dD6KGum4qpNQrViGuFb8Z7Fz/h7YTbDrn0XrVtZQa1YaOwsNDYXyqJ2tAOLSByBRkqxGybp3cuF
4B10m1rxXVvhsLTwONprNlDx8Wp1j5uhrXB53bM8XQ6mUHshH78DUViGyNycAhXMrkevoDAIseDR
x35M6CRJNRQBQmT004Gw3onaqJ+R0jC82VkXTR6Cd9cT6+4637FQcOBO9MJyHu1ZaDtvNjTaUO/6
YW2GVtpYJ6M6aTeZUBbOZm5qimE8ZKz27WM1wvFmJf19GGojJ6oqfIeR1n+RZ/9FVh4h8j1xmPjs
4Fhi5di4Wdp0lX1HhtHfrMo/BQkWMj8GnjftDESEeOJoVmNgVjCQbGbQuWYbN+vZxBrThdnT0nks
2dwaw+skKb+yp4lR6Zx2oQotqIBXrUixcKzcapk5zvA0vfGYuG7a0VD5O7Pyl8XIlohb56p8Fau5
THQxmLnFYO4UgyzarjpKrrqaBGRR6VhTB6wRS6s6ll738kbrfkSPZ/d3InP3MzwtbzwtJ55tbzzb
K4pj7h7uzdJ+1niLViJn+mBvtisLzHVXH6BNX46cN80cYXja3nja5ZytNPCWjglsJW6/O9fmsFWY
reAxcLsqr02crsZn4zRGEiAVKyeLG4lcKzMRnhWLSkNGoJLcma7FJIQ/eq0f60WA10w9fB/QJBE8
BlhcNcKotZ2SgkWlcEJPOJ23fooJWa8H7ZptlEN4Sp4vx8VdvDRunjQC8vRM2H0842mOKVzMswSu
cypW7cUHjmsEn9J0Bt5kfFswPRmfLfCxJzjV8SklwSL47lwBnxZ0hLeAxPWysQkMsjjrVTAr+IEf
PqSIDPFEGjb4FEFGpNUJvueIMOXZk/zZ3yck2kZvBrmSlMCs1+oQH7sm9QulZN9ULa3hdSCU2Dc4
LL7Kj6SfskqyYnVNE1aJAjFGArVtFSjcZ4JPVePn9CGdjxDv4NQPua/pSb755knOmRUEMrd0m48U
K2lNcVb5QBz6JJ87PpZM8rgTwacinpNjx6PR9DO5PVu475fWkD4m6WxRBG/F/TyF8/JgtJK7Z5NU
ufoPK4JssYSgHX5pFkUnhnIpJ1H5oTWIb8JndtlxK2MKBZqPgbukJhafFM/BIG3YVvRnFQVJ2igy
yrh5IcZ4CzptY0OSK3r2SKwFH4i1hBKSo9AC+AeSK4XsoVrPIKNlurHM1jMpFJ0G6uGZBgIHZ+Q6
oXto40M8z2IabbfMF/ROgPQxThajL9oeGW/w06ciTTyupGj6Oq5tXT3xTYg2gE94KAqZdcxQQPK6
frZa6Ae9kMAhyWfJOEPmCK7lyO3a5G75y+75wc3L087J2XEwSe8gBgtXtcT3jAutWk5GKRqALDQH
3xsVC0NtFOMrOdlNFP3RNNE3IAXmBqqeUWe2o/s0+RRgnbWRD2uvX+cXQXwHtzexS/OC/MI46xD7
hLu/Sel17/BaGvo13JcDfhl2hE6IKJZH2VZOI4thBKytGTotH5KAX9VHjwl8EUSaQxY+Xx2sGQ1x
DszXr29vbzVuiFFRUnWsmD9XRCxyo7FX24oIPjIfJEKUwtq0qk+HnghfGxGqnKT7H4SVyUqcTL4Z
I6fzLUROMjZs+TibXJRzstFRMyq+NZ1Xr7kot2rNq9Q6RXbp76z0v7zKlTqWbKX/3p79b6h1OTHt
nzprxUV+lxogOasoOnlE6/tc8BGUwVc5dE2ap9Q1jGYxW8y1QTorzDWjfSPu1XJvUNi06hKhvaWO
xvPz3X2bAjNRm9x/WoHac3EHwJ9a1RNyGlWidYQD/vHS2GRuijarTnHYCs5Dwedhszwlg9XK527J
vW6F/erqqr2+EsVfxoH+fAtMMMSCnYo9drj9LcTrsFqH/Q5yv8louHl7E20nFUleZfQe7nyL4eDg
rrpcyCYP8UgJ2TfUaFwUZuqaYa2cLTl4pCK+jFkjfDAMM2mEsUPG5p3esCEwrUYWRwZ2QXh3Hjxl
fDq6PD7pXV1e33Qujvxox84PH9qj4LxZgfzIH3YnON/9Bo2VZcPa6+KEp5xizvIErZZH4uJ449lW
Mp0MnoE7ZUpv3qtJ7ivsZsDFmB8GfceFtJXe94wMkTjKbeNoG5kW0pyN5hE62kId2jLIvhDUmskF
gNiSNBCWVA5GBpbyz86YwJczKzBmS8vV6eaLD1us/lzndHvY8pxpy3WiMQ5OrzB0V+hRFZkt9AnZ
2my7mMzm034qCIlDHKRcfVJ/YiTYb+srt4ZOJkgIBsXbhmr+fsNzcW9y1P2/jP1mE7ElqXcrq8B7
6cso4il1SSr3iHocpsYRVqMsJgdvhuN0fqdvZzDEBtaSEvZT1MYtiirWcWgeOR5bg6f6yW1t+8HA
g3gwgGNcTXw6eDwOWzUjP1yGCaBYnSWGWBTF7rbwROJOufXeLMMCH9AzHkY84lLNtC/kxe7RKgwe
/XEyZ+Ovh8whVkRROR++yu5VfNXImOrKCbkYBnNpMoC/Wx+y8Uejt9eiQaWtj55kJ2gmlxqQTPeL
YYOYqTFtI0tWXn+DTVPIl/IJ6MYe8HwKR4GSeILPJcKOlZxGhRytj+cpnPwTGjWGrUnI2biYBjHs
0MQ4kR4+708uJ7e61aFtrrTuvBewXHkleJe2qoVtds4iNem7xDCSw2Fm32+cLIJ/KH52TNY/CFn/
UNLD/wPTtVZOD8mQ+A8gCKYd8V9udGsR3KJU4fMxwZsgVMZWcVYmBzsPmcOdo+AJTaFjXFwpyK2J
wuQ0cfL5I/hfSFjKNlk6R3XQHTQJA0lgsZHBxTxfaoGQqV7amhSERe/ghKZKpal8renFcCYrDIGT
vJBv35NNXZrzF/NY2jj+PM8WJN84JPwYkIyl7MdG5+jVk7wmbCQTrHWO085TWn9RvXVDmV1PxW4N
pwEo/48cTuK8J7VI2s9vReUHsukRAPGFwDocQoT1ZPe6d9C9lWL4mN1EldaH7vXRx3V5B5BEJrf3
XcUOr6/MxXZ4Mc13K5S9vrnsnpgR7JYj6F4c3JgL75UXPj3qGstGYXnZk9Ozg7fm0q3y0kfXx+ay
2+Vlr21l2x71np5ZiPborNNrC7s8+um0Yynr003H5rJNQ6ZfrcFHP5nLRuVlOzfm8dDy6OCr02tj
2bZH2TNztW0P2TixFC1Ew3QEiCmIoxIFcWwZLx790Lk5Nw9Tj6I/HZhFx6MXbsxFPQT2ra2sh8B2
riwjJfQYoh1bWY8R2ulYVLEP0acWNnv1rm14+/Rv58pSs88YtYyzqOlTsVkmfRR450cLzR6D9Kxj
VuA+uqHzk5nRPsrh5spS1kMqTy475rI+Unlj1sE7PiP43FLWo3+Pzi3Kf6flpQ7RKHapwy1wbq2i
0baWs9X02VacGOey8oLj4cg4k/mUvDeVLBe3rcxIbOhBbWYs6EHs7JOxpAexg8WKOndrYGath/GK
ihp566Gtt3KzCJXr6q2ZuaSH2A6M/eKhpbdyc0kPURj0V9TQWyNzOz1kYWGus1xLbs2NUuRhW28l
M6MUeZipW/PcWNJnbJvVic/YNja06cGibGAs6TPQYmNJn3FmrtNnmBl52/IYZnOjyLc8hllqpLbl
MVj6kxWXK1uZkbctD0l4GBtLypJQvFfmWzVBge3cTvfkLUttqCVSpK4T7gHRfSc1JaGikML3yTP9
wga9lQfdD3978tEYZyEm7sM+lt7fXN4ShOkdcVl44QJYN7on9eAJeOd2/TD6IWt5Yuu70B12n/hg
OXTSdNT90Ol2/Xh/1O0h2BJsZxWwnZVh82rgkRPJKWd6wwfZqSeyyA+ZswPf+rXvrZOkK05SGPhg
u/LF1pbRrWl4xPTZ3ClMLqj8NJl+Du7R/4spdal+CZ48EdMfF+eLoDjzAMN3+RYdRZ38xUud4Mw5
f/GSHYB0MeT4sOuF6Ng9zDqeaDpuNOfXChq1V86v3d37Nz8yEJwTzfmRH5rzIzcav05CcC40Xb82
CbpGk9pjq9T+ZUWhlTJjo0npFLus6sGuNXMtmZBO2TFrFzItFEjDc+vGcVSO46gMByJUj9VSe87Q
GCll+OQ6nT9kSfrcntG3i7MLn3R/6hxZMi9zddpwYkHvneWPTs+d5dF7Z/mrbrvpRAAATgzd6xMn
AvR+X9r04h1+8X7flMQQb22K2W9JOvuNmnjYuc73a/kuKYsJ4kqWbCy/buwX96cWG8oSJBuk7LpQ
w71pGjwr8z2/YxT2en1DIMTaikPZa/JmJd6KDD48yT8G9zFkLy/udYGIGOFapuKQcCBdA1tcCssq
2Se1EAPcWN+KVXmEnGgHjIMq/NWjCSBgjL0ll4J+U/YjJsCudc5CIUj+OXqJNbtZE2+74z76Fj3g
X+W36QYheqT0wmGNmSITjezXWK8m9P+o3cskcSNhefuzHBaF2QTOeC7JNRWARdikdzPBfsJGjK9Y
U1nA8owyLqB6fg1oroaA6ixxWQlJXHtIPX6AdM+/ItV48DPcW/gz+9NdD75ircUjR3ANRLqnCyTa
OJWvGB4kcONn9CWb3L0K5vk8Aa5sPMlrbLRCQSoU/DKtAjkRRE5e8QIefazrBQg1OJ/wvwfr68Gr
YD3AycDvcpwNDYPzGcFYztIKE/EAL/WlL+WUFO2w/o14bUmGb6uHy4uR0igCOnkEjdSRuZC2o5iC
/j4RsZHuBYKxmJVJjTQSEHHPnjzDi4J6gKwiNAKO8L8ICRgnOF9tEsMhfyGBMzPscKqAZLGMR4J8
8+T6MCRw84qbScToELhVSvOKyJwWUmhPSMZcHHfCCxaRKGoPFaEmwgKLsxjGzd/XkXyicfBkIP+/
XlfHvxW3BonvHZFloq4+FJIsM/LlTOEGUD1BN0jyr1jYxAH/zyWOB3oOR9rZwJ4tF/jlxrO/rz+j
AgrvEReLmlgGe/QO4xDSmQMsXCPFC9O05AROWEVRuVpTeP1k63n+97//fX2dcoKV3MRU1Orkz/53
RfAZpo0AkXuD6ZtSyvCQW5OC0aCH14U6lBRHaxyUBMIJqRXZZS1f63xk0ZHNy3zd//uEvqQD/WAy
ENc6cNlvMcIl+28A72QT8FdR2EkGimhfk11JPSwneXYH01B+Dy5LVPWTAVMHATQ8KxpEAghR9f9g
1ZO+x6rhH/Zpld4LL2TDxiwVMGAx+sdHPYcdFH0T7Kj5rbR5mPEaE61PwCovyEeeRBUu/X0idA4F
EfqIJkpQukrXxX8h03xwcXJ2vXGLZJde2HBbe8m+fWh8rNV4ReVanFQtKXO17HTWq6DfpzMEbNPv
kspblxUNLkhtwftPoGOkq5940QYLExXKK9ZyMYyAUVgM0cjGf7GwyFWpv61kIQX5X0UWvptF/q3q
gsBXGbDYSRC2wSC4vumyqFMkCDg7D6wg5RTQVEQIQA9uQ/gSPIcMXvjCGlqOXb+0mIuLT4Rhjq9E
h9ta6DEXXMNkX1ifPgrrUw4A3CU/kKUEaWoU8RHfgRIQ9m4ppWQxTI446Q2Aa7zWiru7xDLMLmRX
dlnKw6VeIoHycNYaoyUQEt4KUQ8iITjGP1iMCxpVOmq2cmiKDoSbM3PxUj4NFC7SEc8eFlnjRDhj
+0iKFLiZUIIu2gZXuiBiakjbMg6AhkgnA7OvRMfVIOV/kMoXvh6Fq9QGCAszhN0qSn4QgQCxfAFE
1IKXWH2vkUst7VRgq6fG0QzhOtAfCrudiHcGzd2Xj7YmyiEGnbXZx6JIsWTCAyejdgavlLx4g0mn
sGzTb0027rEyBj38hqazIsnZ6PALss1Nxk4n9zNTD8p3//Ca5Aq4yi+pQO1eA/JHUXVgHgePwRvE
HvSXt+NXo3w/Agc/kvLC04/m0UCg2Yh4pNwXuKqQ7jU89eYah6YGRojI2EvS+hcvZB+hLklfxeh4
SlQ/WyzgPj2kt8fxp7RHf1NlJl19opaY46sP1VbS1/w6sDRHxlaWp/iSXZ4QBD9GoOS0kul5aHke
6c/zT9msh0/msOHPwXuLaQ9eC2/YqQHCkMDAE0ruc3onXJYTJgJP6DWadexighXnAO4J4inmemRt
RCVIQYdLMunCMxzCIf7G2MQHCt598TbkQtcp1ZAkfEwTk6NJ8iYJHw+kUxhdwlMkYmh5lcC9knw4
UP3J30oLKYKpeCejA9UqlNOFhtBek6wUgwonqCyF9zX6ewQevQdO4z7kQOJDQrnYUMQy8RmhR2BL
Mc+IreJSiZ/iE2Kvi07GD5HpNZ1niy/oBetteMfukZb7Gxgcqn2GO34D/fvDD3B/6G96qaeiQ1B9
+eaNen4MyFKhXqNqxOHCRETSIGSrAa01svweRomyx6CLpakvFKjZPH3grOfkTRENWOU1o502iUui
HNtQBK+Hk43axV3ABVXxny/oT9a/LwTDS6KJ8s3ACGr2Iq0jqotkOZ/3cP5M9KJOF3H1YBznn4z3
n+APgUJ0eWoYrpJZbaISQS/5T1jMYbkkNfCMEMULIEzSSYyUlRRVgZab9X2x2znhwHdBa6Hn0iJK
nMFFcZmQ7jeoacYJNvnYmW39aL2Atwp4UhC1S4ohp1SNCJyI+oWMKdl6GOOknJxfNRjaaICTvmNc
gb5Bo3tMmdKHMtQrAE+Dfw/C4JVmAPepHwJ+AZthcHMK8ZTaJzYPVEEAzMOHFjaZCabGU9S49Y+S
JjWPFIDCowTMOHWkmPvC0AWGgcmkg9KK0yo78GNh8RxvGJd1dFUfXBR/UTtdUypD2jbchqbJYCME
SYp4ClIhUlBQpNAFFrVZ0D9JP1N5EyVv4z+JZoXW1WBG4t3PpcLcBRyduRc238C5+B67qpHn49Ha
yGbCUHScAzPIPIz0At32E5d+JhGk/VoPWg0DdeUKRJRS4jIjN31v0qkHJJdIN1El7pYUjl8dTHQM
CFNgPEJAkxiyX6tzFd7Soelsxtm/cGqOYAabgwh7P5ukkFJ3tMhQRQGN5krieboeTFA7lLu/yLgC
quJkgad+fCV3kRVdGyhEgBHvmXeyc927/lvnCpcJ/k5KbWwUigOZ+d+/JmlK6FucBaIAIFkOAAJe
FM9D/bmwPqCpePlklEnWnD4rMdby6etRHja0GaC9JgstRI2gF2zoSTEd8Hbq3hNSzDL1SVMm6/cC
lWTrFAusifh7XwcKFaDQBBR9tNBOgaTpjv2UQcSlWqhXISzXCBPU1Qdu9PekhmI0q6zpF5POGp+3
4I9I+Bq7Sb4vDzbycCIsKb4qDocGOBl+CJroj+69VmnJpD56/KioqExcRWkjKqupw5iOQL6JQryr
oJ17sB2wL13EyR/3iDOxIb9eTBc9EwhWFm/TSTqHHNLgA0YEQeDKGGnKOd61T5FOTO5hICfTOVpM
z6aTAfYSE58xUI8JzybBycWNSXvcpZPCZvPTHcUIpNPnct6bDod5uqDrLN6QfWGA5zhY4jU9WUXb
Dc+JkOHX/BXsFqeDXv/LIs35w3+l8ynV5ExT8McDsvXX2F+DpA6TbJHFo+xfKUnqgLMiNIAp+CaG
uyQJ/rnM0sXWFuUIoCLJIDA8+i8uYlTwZFkHfs7TZ3iTfzYlvRrAGMGJ++PJF8o1aIqUHEIZb5KS
9FKeZgVgsRFYhUwHFEKtXcVCvZmaPmjIww2SY8ejZDliQhiPcRdMh0GORklK+woPS8w9yi9IwkNz
rdAaY7yllc4f8MQ4+hKM4vkdwjebzaeP2RhPhQ7W0bYyqXlBREnSCKFBI3BEdOBrkaoCQnx+Waqd
8tFmkkm4IxH3mmLfmWqSuXwx/YzTvyeM0Zi9nCHikAC7jyODBKAv6ZFvIGhDgnwhj0hwEmv6Rm2W
rpBg/2ZbSJPBXgIhig6sBcWmDYerGyoVlyKlKkQhRtMPYwiKWQg1ooYXSOsBNiSLMsK++8kE28+Y
4TDlEdu4/yVA5XBuFVgKteEXy/BPFO90RhPyMOmeDNAbuPsEYP4C4wP3D8S8AN5sPE4HGSoJWf6H
SLuUi7powBD1+eK1cDKVt/WDwL4XAVIqv6FR/NhqgFdqQ5/U37yBlJ1PEciwVoYsxMhMWJ5C/DIy
lNvS9CzYlZcXZ+97ndNfTrqXG2jyoQbkBv5e6L/vC/0nvpHNR/FNofyoRVq8l5We8EKxPHnfX+P+
iifBOvN2IP0F80ltXbyIRJWGHSoJfKIU5UHvVqWp5QblRDYoBUtRmwJd3UflYFe5u+JnkkIrJXKf
p/9cwhUtJDsYX3no/ECjZpGDuQbMQHwjV8VQSQcYLu4JvkuBDha4zmIeNMnL6RAQ0BxKjLuIYT8i
oAfwr+EJBN+ZhGaFEYS7ZcNizEHhfDqCEYSpIZneeOXCZM6UsyyGxLwp7NVi8SABYZsTpEfg9g/B
jh6opC8jGtSilfsKrzxYkBFb99qHblFQMohFO0dXkfBRbDmD7UynmUJPzdNxnE1wX6Yk4AiJRzzK
p8E9ucchxhwP1qk5BB1Gq8OKcl0UByQvcY6HE6RmQwwhUiP0i3OmtkyrxZSN0wY+whiOuL2kTND2
xYhhAUD3niHJ2KL4Ca4zapeGxMJYM6wRZElgxmMqq40Ua4x5PEFDAkc/YtEGKwgCoMhwWCtsTVyI
mk9I3RMTXn0FLMa6B5WcjcAAQ3hJHfAN6k9jpoXWCoZmRpsz0/Qt8e8IryK1gGYTrWGWA5eYeDIg
5tjfp++L3Zm1ta+cPBY/npmkO9gUJnJhHMn78ayoIBNC3Rio6COAZTylY49Yr2kg6L2whqUXvuJ7
ehi5+DozZA0FxMCKP8eou2heQjKwyDjY3cRSRDsEtCQ2+hgSWVQgfBjq3Q5EasI24AC3HVrb5eQC
JvSAIWlxwF0RDvX9dQa3bn1Onz3AaEb22OALty0HCC3DgClkSGhxMVp3kBosUh72jXTJgl6URwQQ
iTtZbVHlTxRRjO+DG8XCHXmcCXPyesJEGAc4c3zgGMPrS4lXX1LOAZIRcjDFcfSM6HjwD7iUCnTQ
FKqgfZwXYwJ6GeuRUB/KeKxgafoBG72SfAshU5Li5gYaMsSLiJA1bJeOpw+pbJhiFOzEQ6C9wdcZ
aW/pWOCxMWGNHb8QFNYOfcQWB5uv8cJgbU1eP2xusgEpYtef6sZE2NgXhjotYRjJdgxRwzqIJX1K
bqnjnU52g+nsL2hQWXti2uBoBup1GCyf76e56Db5gk8NBsR9iwb2D0GrsdfGpWD49lMyggf0BC5d
zEMMPjaX8CSXB/kou7tfjL7gctPBYB8L+3I2Q7W2mKWjDXGQ88Zjk42ANTzem8hAwpd8LcCzMB/H
IyQyMUzIfNYU5LKK54DrcZPfwOKTlcvIet70ju/b/hBs4D1hJJfA0Nr/qkEThvqo2aaPGI18bHyb
YdSUhlHw9HXwn2xPveJwauxqtiU/RajrNmzt0FzFPMyfaz3RXYQmY6iAU1UQRI6ygZKENSC8r7EC
L17Lc7WEvlC4a0JA+Cv8Ds21d1Okup8McNpXceWeDWr7GkMkBGAUuQt+LUyAa276sumODlW67ldN
tmLSYMEhTHDeCFGDBYsVbwjIiWjRSG4JZQxo/UFkg+4csnoJswliWJrjlxs7IOUc2ZNgt1arifjY
q2IpUgwBIrAKn2CZcCf6nvEKrDAWStlltJiVFUomuvyFnRcmvuZVgegmkSWB+2MN4qB5MMjSyLzm
kFbrurg2Xj0Z2CVWWDYypcTXboYgZN5rqEaqgfQtYsN+Oj1cXHBTDBIsPPRKqEZiDAACQPP5AyzG
vBLTeQJhK0ZeltqWdqgERKpi/wz6/iQIo+J2zjXhHMa66DwtgvcfnzSiRxyEX+jFx4+SP9F8mMPe
SumsHGosWAm58lNpO1MHDvewMfQqKYKq4GPc96dLWE7rr0jRP3kUD5sF+DhB3Rg2RrfoUxb9VjdF
C7IolZp2Eg3rWTFIjqpRJcQrlZwTSdG4IgLM2CPyYQdVqJnK6UlbXZpoZ5SDbHVvD4fhYioee1nY
zrzQHgOfCIv5mC3mLEoQzftCGK8o0ggI0veDR23zDdyQB2zGx+5u3l+d9I7fX+AtATn8goU5fFfc
cCThYWEP0kMWAyEXwQSLnV+8Em5sLgISqfrRNjqFqGG4VloNKcSPFR2uBBprWsmpvaSTIBYFhjXQ
qL8cfthtfKwH9EuxtShumDq12HP6Aw9rUrM6qHE1eKcerlBWt5eolhNi6E0ajpzA4045UUxyeve6
EupOg/fxYTfTvlHOGoWoQ3qPnT9dVwL1H9kJCFJKvIgaF1XDcjYw614EdFuIVK9oHpaIf0TLrxl4
BGZy0QmFToAjBWgpvzHCZFME5FWf7uMUjBInRHL2jx03sNLipVZsoVzP7/R9+jt6sFLfosdv6Fkm
YXOe+pM4crzhnsNWe4iXn+hLhNd96T+X8ajOE2DytZ2Y500mMUuRnvgn1twhVvP8siZHcBqChD8Q
ZvirMEfBG3GjBUBKtjRDcmKZnHH4Hqv9SHiEO/03HGIWEpOpAIJf8nscMMnfwy/5vRAaVoAJD8UZ
iheSDsXzUuJTYzES/MXh8U8hkVNDGSPfB/ZuUQLjKEbxWc2CGXfIa0qRHiwWkB5iNBqjyeALxUyw
Eeh9Ic6sg4PrQAhBwEhEyN1o2kdcxksRtPApJgcsrxQh3krpwKUXuDokvNlDPIIZns5ccZIgxtFA
ExODatzrmD6Co4YYGcSvSirBPhbRVV0yXnlg912Cid9wDIOaEIjp2r2nhkTx61H6JR+OlLtP7mey
whOp00CUcxFCn9oKFxCS4kbgXE+9FJMq4wNu7JUixpL+KqAKhS8CsMOa7LFwRFNXo2xlV2z635EN
f+VwplYSjmcKtbKVoEa1cDpTpJXMQMTIZM+Ko5pr4uAwYCZmKldwP3CcwlOosDjdg1nMvB9K8Te0
OHQBOYynIWHHKRma74yHH8WzkVRU14putxyLhE/CLXNO1CYlKhPJUV0M/IjkmnY+UmpwcUaSefUo
qeT0IvG7Md9gQQMTNX5IUeIL2bjB3gfqbGMHJQ0uMOOBS9YM5dDlGkfElSU/Evra6LXhrflBGhvc
han3+fevTfzlzSpOSLLy1nmkzhHVeHEqvOxFgYj4bzh/vsqibTpSyjUCPVG6ZhJgZz/J5z2leiT0
JLGQY3hprLJgfhR1nOEw6RpBx0+O0p/iooxVqJwpY1h5LPBXeR5VrUdsmN2li95sng6zR+xO3qAp
d8nAU1LxMsuLPEn2C6sW3lK3PdjNFIFiHLAjzkLKza1nZOog4itPZbR0gphEKxdPnBQHUAuyzYsx
kM3lAsLkmYxik25jjMUz1WJCxfXxWOCv+9yEYpLapuVSYvSJVVPt5sMG0gEQtlyRDowsaWVCqACB
sbVsxkBncO3cQkU46xUoirD1Qn3ORLP8+2CmUQ6tgjpmQg2krVynzVQn64y1YSa2QNhn4wBjsocj
+RsYheqqt91iy111airYaj49xRvNumiDEoBPS30PZ1gY3+EJVoK4h357jQ+sKTNBAfw6+E/+/ivz
UdHlyGvemfvFG9rv9PyPltHnVw1HQy/M1riCOed37OM0Q1NshtYmaNwhE1xdNOJtb1grYl9wNgkG
2XCYQpcT27nYSSS2ejIdjeIZiRLJ5gEdDeYDIgSyN08Hy8kgnix6gt1vOluu+L+4r4WdusCyQRxj
AEq8yOBuYqJIfrwmHihwB5qWmYp7yhKsXKYWZpCwQEElpF9R61BtbUtJOQEb8U/hGI0UqdIhjE5k
3uLLGD8HaDLrpzR8BFxwqZK3SRhExWxZeI7Y7MWTGnAdTdLALBYxhPZ8npKcULBskxPCTYMUIMjw
3cJIQ1iAjXg+NXo1Zh39QeSzpRneJ8eihkQOztpNhqMM9T4Ol4dIPIyKni/bgLR8NC9pZMQejCHq
op/KeEmVJK6PYELfQMQxpg3Il1eThRbPubSX1IxH0F448YaoHc+USUlIkRQ8R3/LJiVId3Fwc9Pt
HL67Oem9u3h3fXLMZim8AbZIjc0k0f94Pc0bhVowH2ZYQkAMxlNsFHxiLoiNnb0aGbTj2WNyj9bN
EiROMrix3apBPEvYaAQ4Lia/ny5HA2BoOpku7+6LwFK+bsVHJUiKQrpMUbJ6wbsP0Xb7436gfTgC
kqnRjADeEQSULacQK0ASe4JwE5ZA1kac4JJcYk8CIqQmTKaTVGrAZEry0vaG0+WEXd1pctY7cxDS
vgWY4Dke3iwxnbSSFy9EFZOdoM7jd9qiB1vpP7difmu76D4S78Gd57zMVfdJkcdZgQewMT6j+Vq6
8lRr+N6eav9CpjV8USuuCvpw35FkDYtD0puQDHemm1eFS13x2IH8ooAaS4d2o+tTiky89kKrFD5F
LDGSGBz3RqkIQ9wO1OfBVbcYP9YLwDn1EIth5zVidYTtBdPtzHYOqLUAAtZBiAPwDLiAn+t4SShk
UVQpZSnwvd4mtTosFoaGCCmM+U2uGTvLjNONkmtdub6m55t47swnOSsnJSLlLMKHYsWMvqIo0OdF
oaIHlAboufaIy5HHOxGJw+AB3FU7R7ZPQSV+vmVg3/U0GMZoSsehskycWDQ4RPfh+4GFqMqYIzVt
ZYLWZViyMcFCfpeJo6FvMJfwgHzxApaW3eOTqw3O1kxniXw5jBONwl4jOk13NDSQFy8AUZG8VgFw
JEwWLojGnQ6q35ndcXXFg2eV/6sVD+LACopHKFVN8YjVVVE8wM0/WPMwWSjRPEIL9HHhHrW4BizO
v2vUGtEopH2LUYvHnWvU0j/csSShp+0vbgnnvcfSa7PxmEMH4/9qxbUaQgcVv6ezdI70KIRF1ZUn
ofYk+ljkHCO7ScSUl214zMd6QP7FqhDnNM4tDiqKQ7XhiVZBqzPsGmJ7eZhPfosCcaFL0DAAMb+O
uDTWd0DISvcpKS6uJfddxYg3pzgPQV2GiNLZlw9htIf4+pw4HbmlH0NQzUBQNGJIAe842MoPo11z
lhEwfGeIb7gaYTiyLLJQHyzb4XXwIlA9n/h5TaidvKThcoJbkzznqfCot+t72gTTRhzE1fYm6Wea
LKxISgAvZ2RnRyMHf5fyZup5QHM53oozkdEOuAuvbOE4kN6yUAdaD6FRSbBaUMPgaLOfC44RMfXJ
ApaDJHsfCaYm2zYYvmbYtMEeYFrCuIuh8JAH2gs7K1R3KP5AIsEbrGZl61HdPBOr0c5baYJOD8mp
2eIUOB6sOuF7B5Qt+8JjPmhEb+vEtB3LThnx19J+K3Vqobd09E4UbGJEgqqvaVYNUZ1BiiwDowR5
Z3E1rAEFBRrzFd/2Gh+XkEmbROywypSZgKGQfcgGNWAA5GOOvaPuTsGduykDMDcr0f480xJ7rTCo
1KGDi0kYSKhGkaHPGkWmTQv6joVrSwJG4pifPqeJJdS9Au4CrgeGHQLWAyzSRcslzDUgyx4WCkcV
aeUsNlvwUsNZbbofK6TK4E8VeaMu9MbjkH4a9GPMAIHlh6h9IdE3CTRVw00NoaeYKJyWH6oVfmIm
FW5zrsaEZ+JoLOJR1VdEIb5CY0ssKo5ztazwTi1MeSxgEoWfBsNKC0htmDsjGQsBM9zxxPzm5cHH
Cpq/T5QHJQHYJv+yZYwwt7OSQN4WR4e9smT0kp1r9J2kh1MD01STi0/llvfRvjGrDKg6VAH8iYQR
hustQsqgPE15hk8Hk7csApe8hV81HodZQCEB6U2Xi9mSRK8RYOFhTS8Cpw4EYPyTraWUrVy1a7bV
pCQEI7ebyTFngld4yIlQ0GP2GGwi2rTCpgP+meGiAo7bcwTra1oMIvTH6Zj5SkO2NCgKkw4Ki/h9
gVTm0RUot6QFpLNCYdSXW/G27arn+Ey0aHrL5iDfJyfmNrHywN7mgoeXUb1MzLBQ3dAmJ7PRvF7s
j0n2N67XYoB/sNi5kh1KLSSnDQp+knj0ieRhoBF/lItESRWbhp1hkC2eQd4jZNjxJRB35tWLzDTg
UBtmoxE4JTE0CQrcoqeBaVm8txHDMWBcEWRUGs3u0RKJbH72vzBCoB1CggBuMmP+OWJUKYhoJ4MM
yhGqSH5FlVWUYaH1IGrFPCz0PJt0ldTt9rrfFFUDQjWuhcuDWBj2RcXJmNiMjAqPswkW27oAEVcj
kmXNh0HxhqeUFJbJrBBJ3SaMreKdtLlaWMrPWYsn8voLaz4W1DddSHdHSM2Fz1QNSRReiQcyhAhF
SRcozqAiRlEqrcUqijggTHG6kG+Q4B2mEfJhSqKLPgZSsllmo7u8GIRhcsZKNF+4bA5Mp+HshPUU
i6yMSBIzkmfafXxCVMNFpX+fFN/Nh6Pkha/UvZLRKRqYjcd1dsMr3b5XLEj+XDxvY3klzua88yiH
h4SE3sM4hp4fILi66QCO4S6X5WiECV0BJzZVLBh/NVvbgjUumN5aW0UvXQlEWAoRlUI0SyFaNghs
NinvCjVCdKioO+UTTnjWQ3+5d4nCiOEmolb1PHmW3yO4T8EGFmeX/cEGELdZca5lIXiK2n7CY2IF
koEiPP64hbUxj5kRXulb3bqdREb+C7GYfB2SqULB5oU8Omya3DABCxLFr5G7vLo47l2FvPOgsKto
qBaNarws2NWVqo2+Y0kIKlWJ1tqan0rq0niUxcIlGhs6DPXE8OiIjPmrirIaRftFHB3EM0QknuHi
5Ozk/DrYwOWK0VLbD168yBhvlJc0Lhch0V7QWtTntloYnoI7Fx3qKNvcpMCCjEjIyeLnt9fB1fXJ
u+NL+k4TSwytHOwW4pmu5tO7eTzGCZDR5EJtP5Y37vLqpnN50bvuHh13umtRo0FOSeHuICWC0RRZ
87Q0nnboUPx1PZ8ng2y+Xoclxz+XGczK8fxuSQJHyR6jhP9rnZTDx82hGGzVFCXIh5R7NnjGoB+Q
jkJ1r9cd0D9x6Pt0NMOoHdD3DLrBXjigG8DOfeHwmGgRUNpkc0C40/BVwCDCrQY+TDcj3dErFiGP
6SMygTca/DoyqZ5lHt+hmf20c3ZC7tdK43GdHZdZLHNW6ZDVykDW30HJV/iK4c2fgt+QvFFaPqIH
A/wAdwT83CRd+Rr9D4ThR8DJj8X0ZyWc0sGox44LvBTZwJso8zuIHsPh2c/RjwdGMBxpxrtVEPSE
6mU3ptWK1eJzQpW4acOObzBPWkET2MuAn5BGFEsvxys7AWhDbYZgPcFpBVi3I1nvgdCjoYWJB6yI
nw8/De7hNKQwHOqwBof55OTylM4f+edskdyjxnBbmM8oSZwrA+4VYi1vI8KJatoXFjNCMSThr+QH
D/BgTRHDmq34AEOTK4vpassEdq/W8u+4HBVCZGCl8zk0mhdDaiRejhZyqcYrDb3gNQfeTXD2BWAv
ZVNRAzbhQtFJQjnEDNugcOlQwSEASsTAMM5GeEd2OcHzNk6UGE/uUnoz9nSOr8Zmd8uihk2miDXF
9di4NzFmfO4XAcDMguFqjLzRNB6QNKv0inPm7sUvZK873xOkho8w2+W9mF55ZXrXd7wbOt5ljndj
x7tHx7sBa0VJkLN2Xpjl4R9m1D2xXEwhBXGCBuoXnvlkAJ4KqBASE6Cp6phkGksH2eJ7mLjkCziV
4+zim+LOTtNb3XksvBRXeawZljQJ7LWkwSGOPNicB2kU7w5bUTMdtFvwe28nSbbjvVYS9ptI8qaj
/CUej3fp/OVjOskWs5e45eCjireS7zY3N4P4ZTng2jka+dfpLAgbQbjzKtp+FbXR6j2MgheNEE3o
L168CBCCh5cTtOhZu7lfBv8nngSNMGg0XuH/gnBvp4GA0ee7v/4VPPitcA/9rjeCv/4V2xBidWja
QNbMJmrT/3fwTHJvkeiyo+nsyxzydSG0e7t1+HevjuhpNPC/If43wv+2cIFTyIRwPR0uPkM0/il4
Y2LiA+tMEoYTHGf9JRWQ4/ghGwTn07yfzhFTNm/QsA5+GMDT8V/vZ6Ot+9kW6uI3dLkiyd0MTq5N
h8Hb48N68PbgmiT5A/fZ24t3QT+bLBfZKN+iRd1Q+PgAzpufU/L3gy/TJY6UQsMCkjxgojEquEcc
sLxEWmQ8HdA7ucfIxB3QYHbYHeHpkaAekot+FFwt+6MswVjOsiSdIBWLTOAZPM3vCUugiI2R+0Ga
4bx8dJrAiCKcMXwjXgDFc2rr1XASP8g8zoErcKJo8IBlo71HhjA5aYF+kZTtn8GX2cfHLobLEeQp
WAQ/d25+vHx3ExxcvA9+Puh2Dy5u3u/jYCc0GwTpQ0qwkXhCEsmO2ogs7MUX4Nf5SffoR1Tm4LBz
1rl5Dw077dxcnFxfB6eX3eAguDro3nSO3p0ddIOrd92ry+sTyNmY8o4xcJtzeoj7C5qXLmJBNN6j
jqbx1vfxA0RaJmn2gJoOaddnX+z9yDBjLDE2NPgJACym+0GekhxQWGiPLq/edy7eEqcx0ob14PM8
W6T0zoGSIbQdopfx5NMIdcg1HHyBW1lOsyGq73Q0naKp7XCaLwDy/ACjakRh2NgMmzBQ310fcFfx
X7JJMloOIFUxVQZb9+v4BV1JHKwV+VcO0LAX3kTyq4iuTKTUrUiB4nTOyGQW1yf9o43H2trahnTM
aQM9w/uuaKGJ746BNS4v0RmPwxaU2lBLQbE3bwKcCwmV3hnS4k24e+bv3+FDtbYyO6RMk5aJdsrL
AF4o06BkNnGePk5ntxm72saoixpyob6rUNNU5sZZDyOuKRVx1lK0RyjyU1q5ltvqJSKP1jdbchFn
8y1lvLi8I5VpuYqwztwTi/zi1TESl3/x6hjgmXGIgTdUGWHjo7X+UbCB75zjz/AYWiNDSX2H5HYN
hFd/3ofnffX5DQK/0aBvEPCNBvtTuoYESX16u9a/1Z5F6GGkP43hsVYb6lB4rtV3ixp5q7XwF4Tk
Fw3HLwjFLwyD4EGZwZiM633olv7lDM2poBoIJ/q1Wj3YGKOnv2EG1cRyiE40aFDJeqKUxS3o46/A
jQSwEF2zxpAByG/AMB0lKBaMtT6oudESOtHDgasGQnusV0Q0rX9VVJxKK8NwenW3Veq69ano1lgL
jH5aUT2trQECz+rIa9TvKavZUi15pIrDDRonR0LVgV41qxmGDqn5JmY1HxnrhX8RNPyLSThSKy2q
VNnKK4tZZUc2ptrxx7/Ev/SLrjM3i3P0F14VDLUB562Nob+Qf/vm3iRVS/1ZH65YP+/boRcpRQ9j
RfwuJ7myM3pVEjIslxN88phYPWAwiy5yorZpGp8J2fTEV5sspuRCpeF8OiZRduQ+AcWve3J+hQxh
tISrk1zC3KkrViJ7IMC3i72ixIMCR2E3cWCPOImwtMxoiZ9P52DpS7mJxvE/+AmGmnQ/xK/r8WCw
Xl8LkAEojrRgYxffFkP/Q6z9tYtMzy5an3SbX+ukIV/rVZCEMpJ6cBTqiPJl340o1BCthqThQw1q
1qzlRhX5cGdSwp2mH5JkXIqmlDfTeSmOqAzHoweSZmkn3Y8MUiMgaYkYji5uotiFCPrJhqnti6lM
bvYEBnfOz3dX7O7GY1/ocCeisi7HqDxoKusxjCcqx1Pa9RhRsxzRePogI6JWyC4ZUuKA0EqDDkSL
/4fiMqlglqfLwZTchDNAevtznAeDFJyJkFits8B+Z3o9Gy/Fw1jYviDdMAOtOU9H0wSy2W0hHf7X
2WgxHQ7RvCScocPqIZcbwekXGBC2rDpTVS64eNOv+AyVD1HxojyfVjGasIr+BmRRKbLQH1nLjSys
RFm4lecSo+0tLdV/uKU++EJ/fOHWcrn0o69UtxL6PPCF/viAPk/+laptRp8n/8rxIaXrJcb6nG1G
5iXGvsi8xNgXma8Y+5g4uKWeYuyLz1eMQx+xw/T5ibEvPl8xDj3FzleMvfDFD3deYhx5jdmHOy8x
9kUWbs3jf3lwLvJsaeSDL/THR3VAGXk+tilFF3lQ54UuGc/CrfSfHtTt+agBhC7yQBf6o2uVoQsr
URdu3S38GluuU3Bjy9GF/uhaZehCf+rIusEgKDJp2jKkb8U398GnLUY0fLKJTLFhv6XYicg0jCJU
jEShYezgU5Dsy1FRHp5t7NUQcUJxqLkXmeqGNECjBSke1Qs3WLDReExUy/IK4buK7KzGyFJfZAji
KiRr8m5kRnZXmTIXssqUuZq52FpOEiwDLnyhP9sq4PPi3Ar0OZm3An2O9tLUU058YQWxm6RbxSq6
Okbr4Cpwl2L27mvSdg9azRhdtLZcgzk0Dxk7pS3XaA7NY8YuQy3XcLbQ5sRWmTZnS50DJjQPGDfr
KiD0494KFLoZuAKFria7B3VYdVC3Skd1CUr3SHEP67DqsG6VjusSlE4dhDrfrYNCffS87TacE1hl
hCBNCGkZraNyXeyk1s2IlZBXorwUdejN5bsVEHrSSiTCgxEWat2MWAm5L+UeTFHHtFuWV0DoKxFe
jLBT+w268HdRXoq6giyvgLCSRHgwYiVZXgm5H+WtEq6EJarOYolUxuhLbRkvyugt4cVK2KvRXorb
W6BbJYrIjLGaXHjwYgWRbpWqpd9Juwdfqihov75bTc/58mI1Fe3bj7+P9lLcVWR6BYzV5MKDF6vJ
9ErYvWdDebGIsAYUb6SrJPt2tsnFVY7rPHRNq17Y6PqrFJsfbQK2Sj4uDV1YhW0roHNzzhehN/NW
QFjJxyWjU7WGG51xMeyNsKqHS0NcoaeNC2FvhNX8WwLaZsWBrLu3ypE5xEf3b1nQ+Umj7uAqR1fN
v6Xh8+9io3urHF8J93wx+jNwBYzV/FsyvkoD2uLe8sZY2bulYa7S32Vj2o2xZG5emj25A+7G9Xca
IsH0xhb57KNUps25i1KZNldLF0urA1dEWGETqgpCP+6tQKGbgStQ6GgyEmsa6WhFp9n2DnRo1E3n
FhO2HGHZHO1BaZVNKC9KV9uDWtrwhlXHc4sOaB9s5RLZogO6Cm3uLZSqtDlb6h4uoXm4lPCuAkZP
/q1AYwkPV6DR1WrnoA6rDupW2aguwVg6T3vQWmkTyovW1fagnBoodHkOzevLqvj893FKlJuT1jJf
dXXcVeguxVxp+6kqPv/dJy8urLj5VB23/05DGUfsnkKzU6MqPv/9m3Iu2Gn9/b33e+guxVxp26kq
viqy4MGFFTedquOusLfgnDMqKuKWu8/MCCvs2pTMRyur4lZZD34DyktRV9tuqoqwkkR4MGLVzabq
yCvsKZQxpYpC9uq21TSbJyNWU8meXfi7KC9FXW2bqSrCShLhwYhVN5mqI/ee+RTvDnOPDVbaZKqM
7Dx850CoebIsCCPRuepE6EmhgLCaL0vDV2mzaRV8pRz0xVmFiSvgrOLPkrGpCqR0y0kbLd74Knqz
NLzVNpzK6Vx1v2lpQ2vZInpnOchrdGaVo0Py40Ko+rMsCGWBdCL0o1BA6G6we9BYNorKeLgCynI+
+iKtxMsVkDpROgf4SltQrpHzO3egyiituAFVTulK+0/4XJ3BHki5B9ffWYha7Yss8tqdsHlGRXze
Tv+JPeJfx+dH33TuiNrhSDW71U0kwmg303SkKqXlM48nzRWP9PjRbOaueyw5RDSsKqItl4yGVWW0
VSKkYVUhbZVIaVhVSluymDqQVpDSliymPkir9bgkpm70VU+oeNFcXUrJmrB0ZFV0TpGl6ypYK535
KBu6oT4oKh1YWQF/lT0DT/5U3DlYBWul0yt+XAlX4PpoVfxVfMc+/KnivPLvy9X8QP5cUZVWpQMt
K+CvsrfgyZ+KOwyrYK10usWPKyvJ+qr4K3mXy+aiinq9JXdmBazVzouUTHYr6/WW3K0V8Ffaf/Dj
T9VNiBWwVjv34sWVFWS9JauwCvgreZ89+FNFr/v35Wp63Z8rq+l1/15dTa/764Iqet1fb62m1/01
wGp63V+DrabXtUUl86akK2xXqEtKCy7By1XJ66Ghq+AcNiwnLeh8qTNaCzJOdSD7HO2w+7cUnDqd
K3k8NOyVj3h4UGzjbDV/h4C2+ikPh2xWP0fhFs7q5yjc0rnSGQWTzpNxVpJOq6vDgrNqX1s8HRr2
6qcVyimuIJ0UP72VUPjvV1C0jQIWAMmNhX+By4WGwUHxLeJf+0fFV5wSt/jZbcbij37x40Z4cSM8
/yktvt8KXyPxeyz+EArfClX/IgD9UsCMC2LHMrFjkdixSOxYIHYsEDsWiB3fCl8j8Xss/hAKC8SO
BWLHArGQQy2WfonvcP5d9bfcJvrw1vBEpIXPxfIT5TfNDWd6JiLDQvxN7i7r+95d1v9D7i7bxoUN
d5f1pbvLDle4uyzC/27jf9u4wJ93l/15d9mfd5f9r7+77LAh3FCGZKUhvJLfhFXuLjuE6zPoTWTG
K77IdU3SBU/HPvc7bUv3nd1XLnLlc/GUfKva1dx5Ixa930q6d+zne6+bt5pyGZ+bt5QiifMeNVpE
as1t26c1+IIv4QYo3J9ra6Rf1euhjtGLY+0erXv0tHOvPr6K0eMr7Yapqzk8nquPER/Rc/Sv/qKP
X2jXWiGW4BeJdt9VGz2/bRsusUIcgTusAvlinLZyhdVtW7pi5ypGVB3z64O0i3Wu+L06mHpysc4x
vUOI4bzC9+YAAPpzrOFPPPEnZfgTHT/uSLkRpvuJaH/3eZ1J0aYBq1O7oYiUcjdQIAANMOclRZ5E
4Ldzwy1FFnLwk7l8cVLbyBfjzUltRhElL+HkDQryUkaefnVS25dTElEyr+p3mDBYWf0e0hjn7ioR
aeBf5x60GLnXTeMYKAMmsn3hajdWGXqPsSt3g7UFpKaRULS2c1+IRl+4rktujVjN/5ILqvr6BVWH
v++CKmYesKm+S1QgkSX0OWzUdclDy3dkIDxGZMEd43/ZLTuHhjzZzC3Qn28N08/gCDrsEhy1wmfQ
n1tfQKmtZAQA9H0ovyfvLC/HyChmb0MNNbwVcIesOF0THnZ19rBb8Qy8wfXHmBtJPRjUg5TzhKwu
BVRXq+PS+FtgvZG1VTW8Q1OXJdPJYCufLT7RzsNcZp3PApXk7mAlCNuvvOHVjpZLqZ3OS7ESekXm
IpOFpSm6ePASxqY44B1NCR10WZpiKTKw90pkJm1g6xUHvKMpkYMuS1OsRay90rSRZukVB7yjKU0H
XZamWIpgmaRaR6qFbUQ7ipiIYzupFpGx1OSSTUdNLkmz1OQSHUdNLkGw1OTqWUdNej8J6sxDnzFV
5qPLFDXmoccEFeajwwT15aG/mOry0V2K2vLQW4LK8tFZAwfXdSEaWLluhnWRrsvawMV1E7id67pU
DqxcN8O6SNeFd+DiukXWRSPIrY+qqyJRC3mooeoaaOBqgUUYKimegasFli6rpG+y2KJyQosaoQWU
Li6BNs5uvIyFJF2QnCVMwyC0KBRawIjeCu1ohC4ZrIytEcYSZjUUWlQLLWBEb4V2NEKXPlbG1ghL
CXtP6BJLCxjRW6EdjTBKuEUvOUpYVJMQs2ctYSLMqJ2YiNiqsQuioxq7XNmqsYuKoxp7z9uqsXem
oxq9b+bpQlFYN7gIAm4Jpsn55XGv2z28Nhd2FCQL2OC3EgySBOqIwjIKCmk0FvaiQhxmCpawlAls
yBkLVqjexoSwlAnikDQW9qBi4JKEqIQJA5skRL5M0BSqjsjJhIFLEiJ/JjgkoVnKBIskNP2Z4JaE
ZikTHJLQ9B8O4jJQxBL66QRZDekIyqXZVrvPYHTWXjaWBq62+4wCZ+3lQuxou4/4OWs3SI/gAOVf
r4TvN8IFhtOHlAhWg3gbqYO4ga/8RF+/1oOLy95V9wT2Cs4Orm8EIcOkKyFpo/l83jchbP0ehFsz
3HYF5fZqKOfDzETgrgPbVbfzkxtpP/+81TChTUrQWnCFJlyD6rjSWWLAFDY0TIayD2NLo0IjrywU
YCym5oR7XliKAZHGn7aMsoVb0zk/fxeFYkSj6GyKRyPJE17nG7Rka6HOIzAP0ZdDQ7ZNEQsmwgOF
NXRTJYmNbiPO0JesClg8KCu8ujq+pjez6OzpgcKbJHszm97MKlzDHlhKKRs4JWvbk1kDu2RpKLxJ
sjdz25NZA6dkaVg8KHNJ1o43s6ySpaHwJsnezB1vZrkkS8PipyCY8aAgDKspLcmMMKLyHzt2iqpo
hhKKfEfzwM2jKsOvhCL/IePkURUZL6HILpeGDWtDdACOzAg2Ir6vTHaU68HNwduwaTAPChpnqp8z
bBhcPzPVB0ehIgUKS2g2nimQmo+H4DNDqjhldwaBDI00ystdEdKGk1IgABtI5esHE3AkG+tXhcEy
mc5UQydyGTqk1H2GpMVYLLTZRyXBI0roCFlxykEjN29vou3k/4LAERdzBNawIcT5YgseWRWfnc/G
aA+TM9YQ5OEE0/vC0B3GkA4HpBwzYHLmGgI4nGAGkXFULpNpgVSjNDyDMyrFZPiHYnhHYHgGXlSK
t/APs/COrjCpYntQRegWJhmvS0wMw9/RATLeCgEToXecRFgpPCL0ioowsVYJhrCBaFvaJsbrG5Bm
KGWry9QzSqCDDcRAlt5v+paiCUrbRvQIYvCOXfALWfCKVPAIUPCOS/ALR/CKQjCOW+8hq23pGYer
90jVtu6Mo9R7gGpbdMbBWTYuLR5YYzhqQGP2zVZAEe0pWQHXZ5c3UfBbkJoMgc/pY7ZQLYGIefkb
NndzUYy1XSxTssUg1ymwheOw+siFouZinlVLc2DEHXJl1bIZUS5TqU6NbteGhFDUXMyr6oGpd11b
GUUxublee3lynRrdrh0Qoai5mGfVht517Z0UxeTmeu3ayXVqdLs27ISi5mL+40iwEKLSXTqlnFx5
6DcAZaskKt2bU8ppdZaPAtXCikp35JRyWp0+omhqp58smet0ysNiOlNVcbNcFbNSTHjFImUSJNYo
0NoUNGpZSXMpv4qlgdosV8OslNxUPy0s1qgR7RQ/XtJcyqfigalXnbLLSslN9dPAYo0a0U6p5yXN
pfwqNvSqc8iwUnJT/bSvWKNGdOlgG5h61U/3cvkX1EOzXPVKxeSqyzQvF0OtRq8xY66xVPBVtdss
V7tSMa1GD/kztdFLgsw1GsRANrs1Q/t3WNm6D9x4auv312Cz6JPRVJ9GtvmcoHpGp9LscSOCskFg
K6KMOV5Q875O1blCrCZ0VyMpk22u723ASjPC0mZoqoMXtDRD0BhiNc5mDEy9YfAPcWClGVFJMwzK
nhc0NmNg7I2otBmG3jC4oziw0oxmaTMsvWFwEhYFtGY0S4VKVmnbXG07oWWqzC7GQkY0/C6pNeO3
yaCqkre5SnZCa/jtwmGi39XPZvyGXtO9DajX2qU2bqK4G5RCJXN1YvY3iEisM1KiOxyUcp6VCyOH
I3DN24niclAKVapVJ9017Se600Ep51X5wNjLLsMhUdwOSqFKteqku+yORHc8KOU8Kzf1sstySRTX
g1KoUq066S77N9GdD0o5/1ElBqy2S23gxOJ+EAv7CKdeq994stRaPiS00OB2qS2cWFwQYmGfLtJr
9ZMqS61OwdC8EKjYTrmKXqiGpFimTJaMfggRhwe5lmJ+VcsDd6dcPS9Ug1MsU6VOnW6nJGrOCKWY
T9Wqat4pV80L1TAVy1SpU6fbOQQ0h4RSzK9qU+86B9BCNWDFMlXq1OkuHXuqThaLeY8jUWHslKtk
s1tCLOshkXqdXiPIUmfpKNDU8U65Oja7JsSyHn2j1+klS5Y6PQ9l3PjFqIMLQVjs02g/OcJIJs8Y
p16CZuVYdQlvWIW8iphWilkvcIaVmKdEF5egWTl2XcJbgXl6lHEJppVi2AucUQXmaXHsJWhWjmWX
8HozzxTPXoJppZj2AmezEvOskmdEs3Jsu4S3AvNckmfEtFqMO0UaWrRV1Th3CV21cWanrKpGKaGs
igYwxrwXqKoO1xLKqg0vJ8+qjoUSytyySxBCrr15PEnugxkkh04WSjY/GpOrReTS2Pgd4r0v/Par
BMerjrbZFjjaxPeh8l4LKVXew3pQfN9U3msB9ZqzktCgwpjoUGFMtKgwTdnsufo9dwAcNoqvRYp9
vMdS/DwWrgS4L75fCUn5r+bFdyRF4o+++CMR8vu3izT5coXjosKxUOFYqHAsVDgWKxyLFY7FCsdC
hRDDL/wgkq88SMQHwq6T+alAj5Jb0PZcKoFHhAQpP/l2efgHvnn4B39IHv5my5yGfyCl4T9eIQ1/
SJLx/5l8/8/k+38m3/8fn3y/LK3vQEnr++t6PBis19G3IvH+8fsLwVnzK35xeXVx3Ouih8Wvzvl5
FIkPus1eJM+L9W9RSdiSK7FUgY/br9fVKhqGKvjJMhOe5P7TVu6Hpys1H9tafQtWOOsGHPi91I2n
D1UYKZB3YOVcBZwHcNecROruN0fatQnRBOxPHWVVHnqbc9/CLBj6mgXDP8QsaG+3zXbBULILTle5
nudPi+BPi+BPi+B/vEVQeh3PULyO57QuXsczlN+EwptIfhWJGPunkeseHnrfSyjdK3Pa8iiCr4jh
Rf7DUYJdxCPd9tONPUpIVHX7Veu4HjpKsAt1WmKJGw+q5NuBbn3aIVF169MOqeW3ri40toPc8uNz
yQ8v8r6cqqgt3wp0Gq0h8VJv2jltoact9el/rPX/Q33WjdeQHGhP++ipdrHP9XAN9af69AZhuNEw
3KKnt/pThPdWw3uL2nCrteG2LVwWxJ++X+u/N10gFGMPoHwrSazeHxTL15rESDjJWX5DOfgGjU1k
DPDv9VDDg0a4/XYUBR98gy4bmDDDv6eRjr9VEX/Lhb9loL+owXQJkb0NrDbtBiK5RcZ6byM3/0Eo
DPy/VflzG/nxn+Bz8P82MvC/G3eRgDNZMfOny+vo9lkdN/yyH+CZxp8urhGB/wZjyCBXNwaZvlFl
+kaR6f5/FIQaWNFnZP4HoxJokzmBKfoPk6D3yT1dppuFCswwZhMdoXJ5F+B670MoQQff3hsJJTcK
vdeQOyXCgF2XCAG9OiJROT82F/gtfCb4MaP/l9yENNRvQjr9fTchcduMrGuH82QWb+WQuHBIri4G
oeaZBej+02lIrkI+hf8NFyFjLLCfUQWHdauT0hRaaQq9adrKIyuWqAKWphVL042lwJP/c76wczpU
uWSkBeOw8NmIwcFjSo+Fy6HKZTs9Vh6HKo9dOCwcDlUOm7k7ziaEtWvDOtcZPG3HI7jxOHOsXY2Q
VMRgZy8mKHSiC30IIsy1I4n8kDSdSJrlSOJHJ3+3vfgbP1bE4OAvEOTg77YXfwGJg7/bXvwFJA7+
bvvwN+YCbEbS9uFv7BRgIwo7g2MuwVZ05QyOuQRbkZQzOOYSbEXiw2AmwWYkO34MdkmwEYWLwUyE
reh8GMxE2IrEh8FMhK1IHAyWnO4CbwQEBVsKliBL7DTqnfxH77Rp5E4/l7CBxVjgEznt5vIkvZOp
CgQ8YXW6ED4naaE/aWPwQ8N2j4U6D4WKMUzsKBwCpJKRSkgKFD4TzOMWSYtkKN/c8ypvLR77VW8r
3i8tnj8u7LUnXsWttQ9Ki8/i5JOldLRbXvnneGaru+VVemsyMvd7c9uz/NxSvl2udiYDW9PL+Y4K
J2Nb8XK+T21dHqWlZR/thYce4y15WGwN3dbUrjSTGEggOACBLwa7GmL0OIypXWkqstLjtKV2pZnI
gcNhSu1KE5EVx9LJ3D0/5i4rYChj7tLJ3T0/7i6d7N3zY+/Syd89P/5uLebLSeKypmI/HhNEdno0
NKVSTCmzW1WxpyhTRHbLKvaUZ4rIbl3FvkJdyvW+p2SXsV3DUy7fpXzv+wp5KeP7vpJeyvm+lfMS
rsehza5NSkrn6YJ1WMNEQYM5FSBkZAcJAv7bN821CBOmoiIee88R2kInbaE3bbTDrJiiCpiaTkxN
L0zJaD50cp65GyxlHbxmJRvugYEJcLCXOSisxDsYyvwS1rIOFjJ3hKns/Sc305hVgaPNLAgcnFOL
O7iHKXFwj1kkLkqcLGTmiBuBg4/MFtEQSDGBWwo/BATO9PSQ1F4p+l4oy1aZzuz27vLWNPdsZWLZ
GAirbQzMjDsDJUjsgjGzbA2E1bYGZpa9gbDa3sDMsjkQVt0cmFl3B0L/3YEZ3x7wxeDis217IPTf
HphZ9wdC//2BmXWDIKyyQTAzO1hDNpV7bRDMTA5WNwoHi80OVhFduf9vZnawikjKHTgzs4NVRFLu
YJ2ZHawcidcOwczkYHWjcDHY6GAV0fkw2OhgFZH4MNjoYBWReDDYskfAsXjtEcyMmwRuHA4WW3YJ
RHwePLZsE4hYPJhs2ScQsXhx2S3HXhsFM+NOgRuHk8tuSfbaKphZ9gpELF5cdsuy32bBcJaMZ1vp
Px2cbja8OE3wVEPiYDUjy8rsZsOL2QyPld3Nhhe7GR4rw5sNL7EGPKOFi92hN7tHi2pIStgNZNnZ
HXqzG/DY2R16sxvw2Nkd+rM7dbE78md3Wg1JGbtTF7sjf3anLnZH/uxOXeyOvNl95y/dzVK/FsX4
jdF5y3kFjJ4SXwGjp+z7YvQfBd4YvzE67/FQAaPnyKiA0XOMeGJcTqbzgatnmnVf/YRRVcPjR5y9
V5reWoqisndH01tRUVT2fmh666qJ2/LxW4xSRNWwlHB+4rZ9/NakHJGd637rUo7IznO/tSlG5DZ/
/NanFFE1LGU8dxtAfstUjsjOc7+lKkdk57nfcpUgcmp/vxUrRVQNSynPnVrfb9nKEdl57rdy5Yjs
PPdbvGJEbkNIklDPyWLisIRWxOct8VVQesp+FZSeo8Abpf948Ef5rfF5j4wqKD3HSBWUnqPFE2WJ
PeTn96GIqmHxIczeI37OH47I3g9+/h+OyM59XxeQKZCSIakS4zkzBXlyRCsEec54lKeZtrACbZYo
z6KdHt5jS5inoYklONQoT47B0fFC11sj1zie0si1WRG65onBNTqsoWsiOnfcycweuyYicYeczOzB
ayISd5zPzBG9xrGURq/NbOFrdhSlHDbGr4n4vFhsDGATsXjx2BjBJmLxYrI1mIpjKg1hmzlj2Ox4
yuXZFkwl4vQTalswlYjJT7JtwVQiJk/xLmV9aRzbzB3IZkfkIemlzC+NZFNR2blfGsqmorKz3yeW
TdhxCQKylc6OW+Nrtxr8P8B0FZZEP/Cdl5WwOYJ/hC0YN+awAp2kH9z4okr4mqX4mt74mG/Chi+s
2C/YRbESNne/MFeFG7N/vzCPhRuff78wx4UbX4V+SR39ElYfL9iNsRK2kn5JHf0SVh8vzKvhxleh
X1JHv4TVx4vgvrahrDpkmBt7FXzuzhHc2W7k/v0juLXdKP27SHBvu1H69xLSknyqd2jKsEo3EZwr
IiyddPjc78ZeaeLhRoAbZ6XJh1sDbpyVJqDSrgordhXBuSLC0nmotKvCil3FcJbMR5W6iuEsmZOq
dVVa0lVh9VFFcK6IsHRqcndVWH1UMZwlU1S1rkpLuiqsPqqITmW9ZdeqlfqKI8UJSVdA6jNbsS5z
oq86X7E+cyKtOmOxTnMiLekygvbl82CWp8vBdHM64yk14/70IcUpc4Sa71Yw15kb2tSSu8rmerlT
Www5qWKuu+msbq6X4atqrjvxrWCuu/FVNdc9+2UFc72s3VXN9TJ8Vc11F75JFb8DArgKS4Y+iXtY
BZu7YyZVHA+ehPp7HrwR+roevBBW8T14IlwRW0nfVHE+eLfcV515I/TVZ34IKyg0T4QrYivrmwoa
zbvlvirNG6GvTvNCWMUIYAidSvKu6rjxm2wmVawAT0Krj5tShFXHjRvhCuOmBOGK2Mr6ZoVxU9ry
quOmFGHVceNCWMlx5zMQ/d121XRaJaedJ6H+LjtvhL4OOx+Edyt6gUps/OpeIO/lzUpeoHJyq3uB
fHBW9QKVmOgreYHKca6IsHTFs5IXyIcFVb1APjireoHKVj+V/OC+6wB/R3j1VVAlT3gFgv1d4ZWQ
+vrCfc34SmqwAtIVMZavjCopwkpc8NWElZD6qkJf076SLqyAdEWM5aulStqwEhd81WElpL760Hfl
tNL4KltDVB9f/iuolcaXB8HVx5cX0qrjq2wJsNL48kC6IsbyVdVK48uLC1XHlxfSquOrbIVV2l9V
5y++57QSxvKVFt9wcqOvttriG05upNVWXHzDyY20RB8WaEdxnm9BLlOCDW4dYYdqxB0ryNW0ZyIL
l59YEAj1MwSupGWYFNrPEjZtq6+MHDsSP5L4ltxkukhfBcPJdI5vwgtITr7lkFyglg3SySJL4lFx
Ccb34m4dFBNjTen1O8FG43GXO27qgemQgIlDgK6IN/0GyMRIUw1duAK6yI4uWgFd046uuQI6e1eE
q3HP1hkrorN3R7had9g7JFytQ+xdElbtEjqQvuHwoBi/MbpvOEY4xm82TDjGbzZSOMZvOFg4zm+O
8BuOGAHnNxs0As5vNm7iwUA6owPoZBmvckQSX0/9zVBJJ3UUbOEK2CIrtmgFbE0rtuYK2NTxIQtz
ZXRm2lZEpg4LeVCsgC6yoVulH9TBIA+FKujGsy/aWIhkfS9ha5Vh+4aotLEQydNGVWyRFVu0Aram
FVtzBWzaXCEr9qrozLStiEybIuQJojq6yIZulX7QJgZ5WqiCLlaHgiC9Mh7L6n0cVyruJiW04Ao9
SVEFXhB3bwxNC4amNwZFsAVJ9EZhosGKwM1TRZQFQa7QoMiMwp+risgKAutGIS8lBhb7cm/Vpaxi
x/xudBbTcm/VtfHAYlfurbo6HliMyr3fYfV/y17hOL85wm/YNQLOb9Y7As5v1kFgOGmdI3Oyqh1m
MvxXR2Y0OXmPrIDOYHLyzlgBncHk5P1Q1eTUR4ks0hWNAFVz/T5kRnunGBrV0RnsnWJUVEdnsHeK
AVHN3lH7QWCc72w20KZnF4IyarTpea+azaNyW+B1BRTa9LznY/VwJDO+qtK7qboNPjOvqlbGZRPv
6ub8jC+rjNgqSveML6uM2CoK98xgzQcC37ykYaYa9KUYSggKrej8JHxmMOsFJH4yPjNY9gISXynP
l32zGy1eZQpE2L4hKrMbLV5lMsXYTG60eJW5FGMzudHiVaZSjM1o08SreL4wOjNtKyIz2jTxKm40
is5g08SruNEoOoNNE6/kRsvNyiauMpfmFRG4yTGpmrjKZJqbNU1cZTbNzYomruJEyHUnQiBIpTcS
Mx2rOBJy3ZEgoPNnr2qrCEj8+ataKwISPwbDUDAvjPqral/Twmh1ZEYl0l9Vl5sXRv1Vlbl5YdRf
aWGU6/Z4ILDOVyQGBkl3oSijyCDp/WqKRLPKBSTekq7Z5QISf8tcV9QESQWbUHdIusq7LEJdTXNk
vvagrqU5Cl9rUFfSHIW3Q9K24klWWYVPzCuelXEZVzzJKgv6iW3Fk6yynp/YVjzJKsv5iX0jKVll
rTix7ST9Dmy2nqi+9pzY95KSVVafE/tmUrLK+nNi3k1KKqjyiWE7yVW+hBhd0yQVtPjEvKGUVNDh
E/OOUlLBGJxYtpSSCgp8YtxTcmEoYazBa5VU0OETy65SUkGJTyzbSkkFO3Bid8wOVta8Js/s78Bm
1B+DlTW52Tc7WFmXm52zg9W0udk7O6imQAzuWReGUno0SR9U1CEmB+2gohIxeWgH1exAq8EyWMmt
arFYVkdmE/QVnLRWm2WwkpfWarQMVnLT8nlSsesHVUxybaYsRVFGkWHNM6hil/Pp0ojE0zLnE6YR
iaesP0J/jQT23Eakv9IVhJMgW35LbPdWZNVEiSCzk1ZNzh8R62WmCY306T2MYFkJg5OYewsqr7kd
I7ARUyKMhbcjHaXJQkBCUZSwg5aHFvF5H//3a+Mr+4qbC4Bf96HAX5aTQToMho3ia/Et4l/7p+L3
VvH9P4qv3Vj43i++XxcY+zcCzK34XYC/Faq6bfPvY4GEsUDCuCBhLJAwFkgYCySMBRLGt+J3AV4g
YSyQAD0h/RDwMvWsPmhpEMqjW7EIOx8lPLqRqoT7vKXfMnn4+g3lgVAAS8p3g2w4DDbnQRrFu8NW
1EwH7Rb83ttJku14r5WE/WawmE5H+ctB2l/e3aXzl4/pJFvMXmZxu7U5nSWb2Vby3ebmZhC/LAdc
O59Ogut0FoSNINx5FW2/itpB1Aij4EUjbDS+e/HiRYAQPLycLEejtZv7ZfB/4knQCING4xX+Lwj3
dhoIGH2+++tfg82w3mzuot/1RvDXv363+fJ5IFYXILI6B5uoTf9f51mAHk4HabCI+6N0Cw+Qo+ns
yzy7u18gtHsQDLa3BzcqIOT43wj/u43/beMCp/M0Da6nw8XneJ4Gp1PEy3iRTSf1oDNJGM7JYp71
l4t0EPS/BMfxQzYIzqd5H+4SmW/exJO74IcBPB3/9X422rqfbSXT8Rs6ZG/uszwYZqM0QH9n8XwB
GRXfHh/Wg7cH13V8lAvyK769eBf0s8lykY3yLVrUDRUAwUMgP6fk7wdfpssgQfydp4Msp0RjVKgw
Pjb2cjoPxlMkJF/IIxCdOUa9SOdjnu0R6nmbTtJ5PAqulv1RlmAsZ1mSTvI0iFFL4Gl+T1gCRWyM
3A/SDL2fBw/pPEe/MSLUD4iQjXgBFM9RPwJkDRH4JRjFiwK4AieKBg+CbIJh7qcz1K57VAv69QUj
+pyNRkE/DZZ5OlyO6gGCD37u3Px4+e4mOLh4H/x80O0eXNy830eQi/speps+pARbNp6NsnRA0MTz
eTxZfAF+nZ90j35EZQ4OO2edm/fQsNPOzcXJ9XVwetkNDoKrg+5N5+jd2UE3uHrXvbq8PtkK0JDh
HWPgNuf0EPcXNC9dxIJovEcdnSP6RgNy/m+eJmn2gJoeBwkaAvZ+ZJgxlng0RbILLUXQVEz3gzxN
cWEstEeXV+87F28RxZ0hnEGsB5/n2QIBTAGmZAhth+hlPPk0Qh1yvUBgi2AzOM2GqL7T0XQ6rweH
03wBkOcHGFUjCsPGZthsoGnw3fUBqhXOMCIVl02S0RIN9XWmDNBEjl8gzZdN0qDTWOsctFu9m/dX
J70OmgyFV/KbUHgTya8iwAgKZ4JEaZlAG5CMLRAj0tEgf4VpYWX7RxuPtbW1jY0NoKiHiiD53UDP
gqdwD0WtFvzwQxBGNaFE596jSNQUi9zEHkWaSpG7sAmlKhXq+9TTFov8lPi0piEVSX1qkXj2s5Nn
TVMtt5VZduvT+kii69an9eGeVCTyaEqzJRdx9r+ljLM1jGW7chlnc1g9MpubriI7Rj63nbUMKWk7
Ypn3PiMglKp579WdkjD/4jXO5CJeQwYIM+qUcZx/UlTK+GitfxRsbIZCNePO/RpSHOrTm3itD4fJ
1ado6K8RDaC966MXffXpT8kaGsja0xQ9TdWnPyNKftYouV3r32rPUF23Wl23qK5bra7bCD2N9Kcx
PNZaiIQbnuu4I0Ae6dgRO241Xty21/C1b/LT96jK91qN71GF77X6fkGwv2iwvyDYXxhs8fxy9kv8
C2Ioag8Mzrjeryf1QT2tD2vB37/bXNvoX86QLVQLfgsw0j75hhAl+Bt0xQB/wxxJ6Vf0Ho2YOkEx
Rih+A7rwv334FxX7DXOS/OnXbBTB6BeIqt9hsoLg99BFvqL+uKtCIvmTSJTeRreEOhhsAkUgNISi
WyAI1cJqQG/gXxUL0iS0lTUXIvgCYjBghKOPghn+eR9r+Pv++Pvl+PsK/pv4BtF15Bafoi7QDqSy
mz7rpve8l44MskMqv8F9cdMnbYR/j4yE3CZHBqFZiRhQCkNGliYvNrJQKZ24JtCkCkoTyBDlo6kU
QvOSUcKavOPaRMLU7mrif9saOqsoyBiJKJglgaI2iULzFs0IyDDi7DeMV6EmPl5hGiG8BzWe0lqD
QKkT8xjB/gYq31gzMTFVQQT3VGUaiHTg+WrICQrcNBF5uAubkpY9fXd2Fu4E4nQM14oOh41GOEwa
Z2dsJn6Xo2USWr5kk2yRxWgRi1aDkyU8JHY+rB4xDupdIPM28QGiV9M5XjFP0fPpLLhLErQGn47R
qgstD2OEc3JHVy2MMOyXCRr1Rh3cc0AEwShVInzPe9mHj8FrqO9Xwg1EdGdz8QUtZkUrgid6CTby
6RyWvXGSIOrQIyBvHP9jOqcekhpfSBEfZH+exp+2svX6WqdRpzIbbFCP4mMDeyIhJ00Ufq0Ht73O
Re/87NbgUJ1MZwoW0GwcD/PQ+qC6zyaLElyhL67k/tNWLiHDiHD5blQPbt7eRNt9k3N2PH1Yrwed
uirsuPwOc7Oydh2iL12Lx5n1/vnlT1wXMOmW8GPUcT3o14OkHgwKvIjOg7dhk9Mp0LiVzxafwIOM
sAcbnK5GreABg9rKxjMFMtQgAUDBFSq4KBoFjwo1MNIVGaDMdKmQ83ShtTU0tpVBUrwCsN5cAJYa
ExqbDCgVKkNjqwFQbXlobDmDNFJJgKk3F72SO6ijD9QmkWhU9NCwWSEVw4VIKq4uES40kMIdtRTS
NMfTybNFME/HcN/LFEkwdSXlaTpGqmX0BZyL4OKZLKjO3cypelHqpRr5N5EAuHEaP+aUuDZs9CaQ
FGXdXvfyBjeh1SppuMSvBuNX56pKsSYrdtU1FiOqRi8YxVDwoNuk7fQv2ShKokbuVirbjBi5qLxe
8l+Pi9BcMOTssZSLLOXCknItS7nIVS6309kqKWejc7uknI3Otqtc8q/HEG9xmkrulpSMrCX3Suuc
W0ompXXaSg7MJVnZQTpjBYONog8igK8HR1eX1200g52dXLRMpfP7OS+OVks4ER7bmZbwXNy0LeW3
lgKC9zSXXrFZTihHoxQRwlpMdQtSO4guuOm+3TpHNRh0Tfq4qFIBbqiNUBuW8NuQ6Y3eReRIxNJn
WEKlR3CvxtXJRLKy9a8KNeiUeuDh7QUd6YHJIH4iilAQ5L6Ohll0N6d0tYjXbJ2oLq+KSdJJZtIR
QvGQZFkjwYLdFqy6Au/R+YqYaSpJjlmZUBkLFkPMyzVUFSyxdKMRAUwYxNG5BeJfLP+piCVUsRRA
BaJQRRRPBhKi0EAOACVjCZUNTMVlqk9HpUFN5wKTdGuTVDedi5jsUAVNupFJa9MRGYBE2ik2Gxt0
lEZIG04T14woQ9FevTkVvh6dC2J92LnRVkDwkeVbkW62FGKDplCY2rBB+NnAAX9L5Rro4BFqsA2f
frZgAwhVKgwhhb0ANykAhZFkACxGiooz1HGKsBJaDbYYEAVag5RStIUgFIid0EbMZiIsiA3AdLRQ
tKGDt4U8UrQlwEa8RgosaI2wcuuEUWllG61AxG+HLyrQ8ZtZzdDr+OWxit5KP6TxenEgj9e1igPV
MEQRSmGIVkDKx6ZjVE5iPipRPcKUpHAV4CYFoDAtGQCLkabiDHWcIqyEVoMtxk6B1qCfKdpCvArE
TmgjZjMRFsQGYDp6KNrQwdti+FC0JcBGvEYKLGiNsHLrhHnNyjY+Kgv8dnhxVKr4zawuRqWKXx6V
6K30A0YlwwZJPdDCguRwx0asuIMnevbqPH5fWVVFiW4UM7Sw8PFAG1ZAS5aZJmrxvqCIOSoicAvk
NqyjClibHljHGV1LlyBtMKTMC1WCtFr7PZG2SpGG1SkNfXjKkUa+za/SUZ5IW6VIw4qUzuLkE5L+
PIeB5dtTDT+seQWskSfWVilWhQOlWJcTwBtCYLz/AAj9sEblWMPqWFslWMOVaMWjwH8MeHOgFGtY
HWurBGtYkdbZOJuE2PnlqwVUL44Za/xYGasXrVG1OcCL0oo4y+nM40FYoe1NHxW4fAxNE7WGr6lr
v/NDCHM1bZcsoe0eDTch/RGQGvYnZsRYWSvH2lDUlGWzBBC2XAhDmZ2lCAU3rQVdZfqiwn9c1uSG
b5PdKCV8fo0uRViZRr9+DpWhSKzH7d/T05VQ+nZOqCg3N52e3VMF6ch73PhMboDQe9z4IBR2DjwE
yIs+vwY39fnhyM5EvzZXwDmdJZNFBQmybG5SfCsc4+sUx/g6xbfiQNhZcbLuqPjauTcf0MNhLcJP
4YzeT4nwPS2+/yyguvU43heJZwAjCUqo4VagQjjv1n9ffP1FQPSLcJKvaOZYaKZ0CFBu5lho5lho
5lho5lho5vhW+Go7QhiJ5wwjCUqoQWimeOpwXDRzLDRzLDRTljbLY7EuvMEl/3ofK7/70m/qhBOf
NaUf8kFEGrlkeCSz+9udSBz7nkgc/yEnEsMwtBxJHEtHEs9XP5L450HEPw8i/nkQ8X//QcRz8SDi
eV08iHguvxEOIp5H8qtKBxHPKx9d8jkhJ5/C8ju7FkpFVjgf1nIVMR4Pu227T8gNjUfX2u4jcuaa
dvz4vMbv6oxHGdJPMHBQH9XkTntf+Yjaj9lk4TjWKZ7rE44kna/1z72ObJmPYZmPT7XQ05Z+qAqO
bLX1I1ttOLLV1o9s7aDHO9pxq7X+e/UZtHwNt99wtIoe+Qiqn/nos2Ab+6mPfuA896Gdy2iDlJSe
/OCHIaD5rsMf5DzUjlpLi51WCWxVtJx0tzSEaHjzzVknTnasx0F1ixzaMdTxXjyx4lkNPiJTHFax
14cPysiVtmM8ZlgvSxW2+Xk2IldGdrXxQSMAkBFLmHWeFT3Njz2RSoxcc9V0DlXJ++ZiTefawTJc
5UAU/HOxEh252A56kMiviqJVqXpi69zSrv8lp2/G+umb8296+gaOp8RbOGTgvCHEtvOQWnw+xbCt
Sgomo7lactuvpF4ljmw+XaXKHXtJVjabPMQjnFCMlQQtIAUtIRyGhF2f+45CkbnQeGgrEznKbFnJ
a1pL5fPRv0g6QAuFTUe5zFYutJf7gtZ/1nJNa7nhaJnfz3MroThhKC162ule36ChenHZu+qeHBde
KI5tNI0HLmRxFWREMrZSQaiUHqMuOb1VJUWLVOHmMxP41vJzvdwu7W7jkQuGgBybGzu6Xj7uptQP
p+W0wu/FKKQSBPiMXBmG0IyBS9NSQcBKt3g5wx7R3FZq21Uqzy2l2lKpq27nJ4OQzG2ld9yl1e5m
vQ12F2Wyz8kca1H38RpyishYEMdqH/E6Lc12IOATxBEJiLO1PB6NpkmBBGNoF1T3rk6v68H15Sn8
cwb/dNmo/Y2O2d/OL4973e7htYFAJ3YVKwna+80DuUf7SUzgdbd3tjIL9xiKd+fWrreV5bMsKr9S
5aGAABFg2GSYT/spDvExlW8Kp4ksu3G4/Gdb+T2/8qj+wFQ+lOrHA9BBghnFnjeK+eetYbwcLQBT
w9Qaws1SNByLBU3kheZzGZpmCZpskWCjwVg6SnFpKHZ2gOdOi3ABlsyKZViKpVxIyeHvbre3up5q
4J45PvxdOHC3dH4fDnLe9W+/CwfWuVfnR78HxzbBcfx7cGANe35d3pZsMSeCZsKC5ez4xg9LZsOC
5azjxFLeIuG0KSBahSnFwVMibCvh4NN5Z3UcxQHhv62Mg0/uRNhWwlHMUFjYqsxuxSFXImQr1b/D
DZSrdx2VAq5QkQ4b2XRYY4/pUZd0Aoo7K4pYQuFWqBhTbEXVr4RqbtfwjcSvXXO7em8M3Ch44Pl9
nN/beig2RyXQkov4zlaw7yw4i23lUqmcpd2L+JOt/NBdXvRT5MRmbwh2qSPlh1BOLUVyQTsThQwT
uZvAlcttAbaOM7FqqE3gatHQVhRkNbVJR7PFi1mYhPeTFuldOg9gMS9kbBjhQEXCf+4VDDZadbaq
fWzwJoGCMBGHcGxNFj54Qg88sQeeZgmeqAxHWN6myKdNYXmbIp82heVtapXhiMrb1PJpU1TeppZP
m6LyNu2W4WiWt2nXp03N8jbt+rSpWd6msI2RREYsITbWd4VWoTX50fVxGTZPZOem03IyOsqtMvpC
b/oYQk98fiTGHiQ2q5AYl5PY9CeRXH7kEpSWj9LMnbzjiMq1Zu5sIUdUqjbL27Xtozh92rXtozl9
2rXtoTrL29X2UZ4+7Wr7aE+fdrU91Gd5u3Z8FKhPu3Z8NKhPu3Y8VOhWqSLWtZ4Ji0e7dN1kQVTW
Ll2DGAS6tF17PuPLp117PuPLp117PuOrtF1xebtaXu2KfcaXT7tin/FV2q6+z/jyaVffZ3z5tKvv
M77y0oYl5Q0DNB4tS7xmMJ+mJV5TWGnTBl5zmE/TBl6TmE/TBl6zWGnT0vKmtfyalnrNYz5NS70m
stKmDb1mMp+mDb2mMp+mDX3GWj+Lczee0GuJDXjKWxd6LbMprpL2hT5LbZ/2eS23PdvnteT2bJ/P
stunfV5Lb8/2eS2/PdvnswT3aZ/XMtyzfV5Lcc/2+SzHt+LknyW6JfRarSE8Hs3zWq8RVGWt81qx
ebTOa83m1zqvVZtf67zWbR6t81q5+bXOa+3m1zqv1ZtH67zWb36t81rB+bXOZw3Xps1zunFEK7Pc
jUMReuLz8TQJnCshs4JDrKw7dJz+pJY6xpJKjrGy7tZxlpK6uzXMRqMSAfJaNgEeD7n2WjlRXGWC
7bV4SlhQrB1R5GXRYUTlLYy8TDqGrKSJkZdN59NEL6POt4leVp1vE73MOp8metl1vk30Mux8m+hl
2fk00cu0822il23n20Qv4y6hke0OPF7GHeDxaKCXdUdxlbXPy7zzaJ+XeefZPi/7zrN9XgaeR/u8
DDzP9nlZeJ7t8zLxPNrnZeJ5ts/LxvNsn5ejngxmYpgFgQudl8eeoyNtLUPoOytyM6cMoefM6NVg
L1d+lQZ7ufSrNNjLte/fYC8ff5UGe/n6qzTYy+fv32AvK7ZKg71M2SoNdtizPDLoKk+Xg+nmdEbS
FNzho/qLNA9Gg8fx9CGYp6Npgg/TS3e9ACn0/qDyCA5SiNNRD/CZ98uri+Pe2fHt+eVPRso6YszS
55fZJJmn4xTV0IebaO6yfJHOlTN/Z8edi6PuyduNpH5fM7EmxIShFc29wBcWV3d5fYOK19myRgmS
YriDDRYVZYyBUsFCDSw2gTUlsEgDCdUKI2OFoVphZKwwVCtsaSCRWmHLWGGkVtgyVhipFe5qIE21
wl1jhU21wl1jhU21Qhq1IQG19F5kPkwVTu1G5p9U4ZR+NFS6rfeksdJtvSuNlW5rfWmotK33prHS
tt6dxkrbWn8aKt3Re9RY6Y7epcZKd/Q+1Tt+V+/T2FTprt6nsanSXb1P9Ur39D41Vrqn96mx0j29
T/VKY71PjZXGep8aK431PtUr7et9aqy0r/epsdK+YZzqtSaGgWqsNjGMVGO9iWGo6vUODGPVWO/A
MFiN9Q4Mo1WvNzUMV2O9qWG8GutNDQNWr3doGLHGeoeGIWusd6j3L91xEsFCw3wqbCipoGoXC/tF
KqjayabKDXOrrXLD/GqrXJ9jjZUb5llb5Ya51la5Pt8aKzfMubbKDfOurXLD3Ev3OiQww+xb+M5V
SE1Xc9e1Cqlpa0PVhjnYUrVhFrZUbZiHTVUbZmJL1Ya52FK1YTY2VW2Yjy1VG2ZkS9XanMw3ACQw
w7Qh+PdVULVuwX2vgqqCxpyeIlxk0C6iT1OFVWVNdFmqsKq0Ges3KBhr/QYNY63foGKM9Rt0jLV+
g5Kx1m/QMsb6DWrGWr9Bz1jrNyga6nGTwAyKRnCoqaB673N/mQqqd75euUHV2Co36Bpb5QZlY6rc
oGxslRu0ja1yg7oxVW5QN7bKDfrGVrlhESC7bCRow2pA9cio8ObRXzhcVHijBjBTY1gmOKkxLBec
1BiWDQ5qDOsHJzWGdYSTGsN6wkGNYYZwUmOYJpzU8LmCJU2mL4UEKaUHifj5vnNbHgWEg7kjSvA0
S/CUHWJrhuW0+Bw+a4bltJQdPmtG5bT4HBprRuW0lB0aazbLafE57NVsltNSejxLFRgWlPFNkLkC
MQBdeWiHKodu8qrjK6Fwa56OynqhVd6bGE/5jlaz5THofEjaLicp8iRp22Ps+ZDULiep5UlS22MI
+pC0U07SridJOz4jkdLkkk5FlkqkvTK+0vFY1trQJKblVFbH6aZ0dyuflcZwNfs+/YsRefRw397D
xebO0fnV7dGPZG/H3lrD3g5h4RHfZdJQ9q6qI9V5qKEN26vSCmF7JTSHbUq1ZQdwZap7yIASk1ez
x0jSgpb+ODTBRmKOa/awBdmt1Ye7QVN7ONmY1IOcXxn863oynj0m93frf5msb63/JYebEOFDwdG3
DYbuL3+Z/FZ8z4lN6Yuod7UqonVqofpQFFZA5KSoFFHsSVGzAiInRQiR1Jm7dBQofbkL+JHu0nsg
bAOh4FkpYb4LBZBYDYXCdRsVGsNdKMxUlKGIy6nQesuFwkyF2k/4zcHZGXQUH4MhjMG6eG+38uGQ
kTdkyxty1wOyEC8CJbYEKTEWdyA+RkqsVqwB6Rv1d+9KfRK29Sc6FGhO7RmqUXsWak8i7UlLe7Kr
PpmUkwmNZqKCxQTMNltYC7YV1LPV5skd46KenFJ0oTe62Add0wtdVN7SPd+WRl4t3fNtaeTV0j3f
lrbKWxr7trTl1dLYt6Utr5bGvi3dLW9p37elu14t7fu2dNerpX13SxnCYbpI7uMB30FyIlWPH9aD
zsWRKf+UiNQZjcbRhiugtcekcbTNCmh3vVjQrMaCXU8WNKuxYNeTBc1qLGAeADcL2lWlgKwcy1jQ
rioFfEFahraaFPiwYKeqFPixYKeqFPixYKeMBQzxXboYbuXZndJ+GVvCUJ0aFBTGkD7OnBgGpRhy
Vf3KCNJSBAM3gqEZAUFREhCajcfpIIsXqSkitHN+fnIsLJZ5f2wbFskIeK/vGQ6KEfsEhEqArpBQ
CdAWFFoAlYSFSoCuwFAJ0BYaWgCVBIdKgK7wUAnQFiBaAJWEiEqAriBRCdAeJlqAlQWKSpDOUFEJ
0h4sWoCVhYtKkM6AUQnSHjJagJUFjUqQzrBRCdIeOFqAlYWOSpDO4FEJ0h4+WoCVBZBKkM4QUgnS
HkRagJWFkUqQzkBSCdIeSlqAlQWTSpDOcFIJ0h5QWoCVhZRKkM6gUgnSEVZawJUGlkqg7tBSCdQR
XFrAlYaXSqDuAFMJ1BFiWsCVBplKoO4wUwnUEWhawJWGmkqg7mBTCdQVbsoBfQJOJeCykFMJ2BV0
WgB6hJ1KwGWBpxKwK/S0APQIPpWAy8JPJWBXAGoB6BGCKgGXBaFKwK4w1AKwPBBVgi0JRZVgXcGo
BWB5OKoEWxKQKsG6QlILwPKgVAm2JCxVgnUFphaA5aGpEmxJcKoE6wpPLQA9AlQl4LIQVQnYGaTK
Ib3CVCXo0kBVCdoZqlpA+gSrStCl4aoStDNgtYD0CVmVoEuDViVoZ9hqAekTuCpBl4auStCu4NUC
0CN8VQIuC2CVgF0hrAWgRxCrBFwWxioBuwJZC0CPUFYJuCyYVQJ2hbMWgB4BrRJwWUirBOwR1FrA
+4a1SiW8AlulEh6hrQW8b3CrVMIrvFUq4RHgWsD7hrhKJbyCXKUSHmGuBbxvoKtUwivUVSqhB7vi
14I77XoBt7p7+tGwL8zHj8bjWMCPFjv8aDTctkAMlDeVOVCIp9UBmxJgZAAKVWyRBVuoYmsZgCIV
W8uCLVKx7RqAmiq2XQu2poqNB04qgC2dd0V4mA6rsM+CdFtnoRXptsZFC9K2zkkr0rbGTAvSHZ2h
VqQ7OlIW9KZA9nWsYlSbDi0NvOK1MPBOR9N4kU3uNmdTGD3gzlZyKwyNmd3bRcQcv+7j1J4rYmjL
x6ngCX3wmCL4FDzNMjyDskY1PRo18GhU06NRA49GNT0aZYxHF5GEHo3a9WhU6NGoXY9GhR6NSssa
1fBoVOrRqIZHo1KPRjU8GpWb70sQ0bQ9mpVbL0xQMHmMK5+R1fYZWeVN2/Fo2sCraTteo8unaTs+
46u8adseTbNfc6Fg8hhjPk3b9hll5U1reTQt9Wpay2uk+TSt5TXWjOdrRDSxR9Ny6+UJCiaPsWbL
6K5g8hhrpU3rezRt4NW0vtdY82la32uslTZtz6Np9isvFEweY82naXteY620abseTUu9mrbrNdZ8
mrbrN6+Vti31aFtuvz9BQeUzs/m0LvWb2kpbN/Ro3cCvdUO/yc2ndUO/2a20dQOP1jnuvlBQ+cxv
Pq0b+E1wpa1LPFqX+rUu8ZvifFqXeLTOlulawBP6zASuTNcKrtLmuTJdK7g89Iotg7CAKfJbiLpS
CCvYPJSLK4ewgs1Dv/i00m9l6ttKv/Wpbyu9VqlerfRbqvq20m/B6ttKr2WrVyv91q6+rfRbwfq2
0m8da0krLCLyW8k68goryLxGpTWxsILMa1CWNtFvRevZRL9FrWcT/da1Hk30W9l6NtFvcevZRL/1
rUcT/Va4nk30W+R6NtGxznW5cj1T1Z6yBCTmQ7ztupKr9lQ6MmIPTiauY47dHK7LXcMaXKjDxSY4
ecuLuHZlIG3vnLtuNbhQh9Mr1fbLietVBtKCF7hrVYMLdTi9Ui1ggbhGZaCGVmlqrLShVZoaK21o
lVLXpQym7YgLrkkNUutXc89qe+HMtSiDaTvhgutQg9R611y1tgfOXH8ymBaKILj2NEitj81Va0EI
zDUng2mBGILrTYPUetpctRaCwVxnMpi2kS24xjRIra9jY9XaxjVzbclg2n614LrSILW+NletxUQx
15MMpoUUCK4lDVLra3PVWggBcw3JYFqEheD60SC1vjZXrUVUcNeNDKcF5oquGQ1UH9nm2rXAXO5a
keG0wFzRdaKB6oPbXLsWmMtdHzKcFhItujY0UH18m2vXQqK5a0KG08LBRdeDBqoPcXPtWjg4dx1I
cHoMouQa0GBDM6xWvx6BKCztJUg96k5ZumvQmvCJCx0NWpM/MxUmy8FOhcl+sFNhsCIsVJhMCTsV
JoPCToXBrLBQYbIt7FSYLAw7FSY7g1rsMqDJ0hAscg3YIBXc4taADUJhIMFkcVhJMBkdVhJMdoeR
BJPlYSXBZHxYSTDZH0YSTBaIlQSTEWIlgdshNHCFv7UvdnKIH5MCV/JFaeCKnCrQdFIUkJSvzuRU
gRY8ZQEncq5AGxIPYpoexJQFisgJHW1IPIgJPYgpC/CQcw3akHgQ0/AgxppvTETU9yDImW9MQWaj
yrm0n8XZXA3VmhGRV2/lJNXhg81SsNZpZHdNzPhGfgm20Btb7IGt6YVtUNrMpm8zBz7NbPo2c+DT
zKZvM3dLmxn6NnPXp5mhbzN3fZoZ+jaTBUO5kLX9xdZLcNv+guslum1v0fVo7I6/8Ho1dsdffL0a
u+MtwB6N3fYXYa/GbvsLsVdjt/3FOC5tbOwvxrFPY2N/MY59Ghv7i3F5Y/v+YuzV2L6/GHs1tu8v
xuWN3fMXY6/G7vmLsVdj9ypo41Jkqb8Y516tTSuoY6/mphX0cSmyob8g+zV3WEEhezV3WEEjlyIb
+IuyX3MHFVSyV3MH/sLMd+Ed+KTAER98Ho2Wwkc8cZa1WwoiKZEbr3ZXsJK9213BVvZut7/F7Nfu
Cmazd7srGM/e7a5gQrPtbRe6Cka0uMldgtJfyout7hKU/kJe3ugKxrRvoyvY076NrmBS+zS6glHt
2+gKdrVvo0tM61L3h3/itY243q8ntcBEToj/Q5ZvX6GlHiTu8IYZTRfFAxvqwdFuTZV7diSbhzVY
oGIJqmmAGgjVNUl1YVuFketrkvqMYLEE1jSB7Qo1hpYad+UaQ0uNu3KNoaXGfEtkatvGVIWtbRtb
Fca2LYyVKt2xslapdcfKXKXaHRt7pXq3rQxW6t22slipd9vK5FioN7YxOZarjW1MjuVaYxuTxUr7
ViYrtfatTFaq7VuZLNa7Z2WyUu+elclKvXt2SRagUqskK/WmVlFW6k2tsiwADe2yrNQ7tAuzUvHQ
Ls0C1MAuzUrNA7s4KzUPrKwukqbwzWMjE+WUKXzr2AkbS7Bmniv127WzgQC7jjZQYNXUKgl2dW0g
wa60DSTYVTfPVcK3ai2MFTKV8I1aF2gsgdq6QKzcrsT12u16XK/ersrl+u3KXK/frs/1+mWVznNq
CNbSGZg8s3mKkwDLO0T4ESjDtfOGI9qUnYMxm3gEL012WoYnLMcT+eCJyvHEPniaZXjSx2RUimjg
wSBA5MWlgQeXKLJyVg08WEWRlfNr4MGvYbwcLUoxpR4Mw5jYSqQEWSnDGLLIA1kpwxiy2AOZH8OY
mDmxDb2ZJshaGUZPzgkCV4bRk32C1JVhNPHQrN48A9zPTk9ujn6UYtwNJJAZU0ke5FoBFupUrACr
aTV6T1KaJujQBB3ZoCMTdGyDburQTM1p4GrQo67MTEUM1Isqy1TE0ARRMZmKGNrB1Y8Gr0au6krG
VMTQEFGVmIoYGiIqDFMRW0NYt2hl1EBYy+A3lbO2SOggUzlrs4ReMpWTk30JAGK6r3Qcz+4h5dd0
ls7jRTad5HL0VnHPgJihX3AekVsGwFtjvPCvuGXAVn5QWl6JH5OLp6XFB67iQ3Nxp8vL09t1WmRY
M+VH2zGc4+mU3jMgHuWRMuU7D/NIkM7jPBKk/UCPlC3feaRHgnQe6pEg7cd6CrBQq3rXUnVoiLw0
Vx26DvcUYA2t6tRSdcMQcWmuuuE+4iPlyy855CPBlhzzkWBdB32krPklR30k2JLDPhKs67hPAVh+
4EeCLTnyI8G6Dv0UgOXHfiTYkoM/Eqzr6I+UR7/k8I8EW3L8R4J1HQCSsumXHAGSYEsOAUmwrmNA
BWD5QSAJtuQokATrOgxUAJYfB5JgSw4ESbDOI0FSXv2yQ0EScNmxIAnYeTBIyq5fdjRIAi47HCQB
O48HFZAeB4Qk4LIjQhKw85BQAelxTEgCLjsoJAE7jwo5EpYbDgs5MpYbjgs5UpZrB4YcibqNR4Yc
qbqNh4Ycybq1Y0OOdN3Gg0OOhN3Go0OOlN3a4SFHGnXj8SFHInXjASJHKnXtCJEjsbzxEJEjtbzx
GJEjubx6kMiRxtt0lMiRyNt0mMiRyls9TuRI5m06UORI5206UuRI6K0eKnLkVjcdK3JkVzcdLHLk
V1ePFjnyzJsOFzkyzZuOFxlyzUsHjEpS4+ZVUlSfunNU7yhuJgg4KM9RTddgZZmgi5VVWSpourIq
SwZdrJfKskHT9VJZ5utiFVSW+pqugsoScxdrm7LM3MUBHxVUS64sH+ExgMsyZEyv7HRWWsNVmNNE
lJ+GU4BKF/AGV2UxHvyclRK8h7tSgvdwWErwPi7LokAFp6VUyNdtKRXydVxKhbxcl0WJCs5LqZCv
+1Iq5OvAlAp5uzCLUlWdmFLJSm5MqWQlR6ZU0uzKlMb4rzDK+O4F/u/Xxlf2FV5+BcCv+1CAYjpv
FF+Lb8W16/3iaf9W+CpA3DaF7y3hezsWf/SLH6A3+K9xUcP4VvgaCd+bwveW8F2oYSzWMJZqQLqq
Kf0QQfHvlvJTqJwrOvGJ/gi7VdXfEgz2q343yIbDYHMepFG8O2xFzXTQbsHvvZ0k2Y73WknYbwaL
6XSUvxyk/eXdXTp/+ZhOssXsZRa3W5vTWbL5uJV8t7m5GcQvywHXzqeT4DqdBWEjCHdeRduvonYQ
NcIoeNEIG43vXrx4ESAEDy8ny9Fo7eZ+GfyfeBI0wqDReIX/C8K9nQYCRp/v/vrXYDOsh7u76He9
Efz1r99tonlFrC5AZHUONlGb/r/bZwF6OB2kwSLuj9ItLKNH09mXeXZ3v0Bo98AhsLe3h0ZFAxx/
6N8oOJ2naXA9HS4+x8jCOZ0i3mGXPJpWkAlFcUwW86y/XKQDmLlusvF0cf8l+DkejYIfULnR6K/J
l7vJElnE0/EbOjhu7rM8QEu7NEB/Z/F8EUyHwdvjw3rw9uC6HsSTQbC4T4O3F++CfjZZLrJRvkWL
uqECoHMIVOeU6v3gy3QZJIiNczSl5pRWjAoVHgOWl9N5MJ4iWfhCHoGEzDHqRTof50Abq+dtOknn
8Si4WvZHWYKxnGVJOsnTIEYtgaf5PeEEFLHxbz9IM/R+Hjyk8xz9xoiQEYYI2YgXQPEcdRdA1hCB
X4IRMgU4cAVOFA0eBNkEw9xPZ6hd96gW9OsLRvQZ2TJBPw2WeTpcjuoBgg9+7tz8ePnuJji4eB/8
fNDtHlzcvN9HkIv7KXqbPqQEWzaejbJ0QNDE83k8WXwBfp2fdI9+RGUODjtnnZv30LDTzs3FyfV1
cHrZDQ6Cq4PuTefo3dlBN7h610XGyQkyda5T3jEGbnNOD3F/QfPSRSyIxnvU0TmibzQI7uOHFHV4
kmYPqOlxkCBJt/cjw4yxxKPp5A63FEFTMd0P8jTFhbHQHl1eve9cvEUUd4bBZLqoB5/n2QIBTAEG
Y7GPnO0QvYwnn0aoQ64XCGwRbAan2RDVh9YV03k9OJyiFQWCPD/AqBpRGDY2wybsBLy7PqAmIdJk
yGQcLdGIXmdjfut+HV7AJdQDZElSgQ7yWZpkQ9TM280lUknB4stMNSxvGwH+dA7ard7N+6uT3i2a
poT3a9KbkFUzQfK1TKBhSPAWiDvpaJC/knH3D6HCjcfa2sbGBpDayyY5EuwN9Ch4GjQed2q14Icf
gnZNKHMM8LYCISnQ3BZLXMUeRcJIKjJ3FWkOSZmGWOSnxKOWSCry872TsiZtTFMsc9t0FdkxFmn7
NCbaEcu892kM9EtRZox7c22N9GqwsRkKCMfH6MWx+vAqRk+vYu3xHB7P1cc/JYH4QRxXIRBDUUn0
r/ritikXRb9ViDYqedtWH79HT9/Th8VjYpzQAwKITf3LGVLPteA3grlPvrU3khpabf39u020hFrb
GCOg3zAp8K8o0wTde4KvPqi5EMKX9xsDB2L4972EHYkmQq0QCtzrAxpW/qdEKnQVIz4ec5pwbWJ5
6DZCF+Y3oQz18EDEiYB+w90Cf44l/FhK5ErqqV4NFaY+rzMp6hywOlPGDlYvKeVNABrunIT6cGUi
8FsktkNPcvCTOZYsoi2xjdaj5pjwPe89fvgYvAal/ytblvTnafxp6xEtRG7JOr8J0stCoho4Cgwt
O961I3lpwdc1k+lMKf5eKM+OuzlR3CPD2Y0jLMUxnj7A2g/NHVhSScgDlOqG2Efxrt3SSrJOPOye
YckGZpORTQiRuhZWZsS7QQ4tsCPmN29vMOqr65N3x5ea+6M/H20N08/rda41UG2kccLiEEEJEA4o
wEXd2wwiVCDIW+vrMbL3WOlQxw+vxQq4Q56ua9BDjXFwvMnOOolxiGuJyLWGwDAB69XvROvojGQ6
GWzls8Un0i2cTwZec1DKz6tSQEP3mHqIg3PQqxJYNEBkcg1dx0Elcl2AJmlykaCQa4Md6NyNLFQM
VO66AA3kRi4SFHLtsBp3m1YqFO66AA3kNl0kKOTaYLHgqKPYJZOGIe0UNAW3U4BM6sLVJQpuZ28b
cDu7UMHt7BoDbgO/BTXh0hM+KsJfOwiKwakZBKXg0go+CsFfFwhqwKkHBgbOGTrbZ/j7j/yBiXNG
OJ1zBmnxGez+43xg4pxN5qgou8Z3haEtjmrXsK4wogcmKm2d5zeQByYqbSx3jV/JUuHfr4xmy22d
r1HAoDiWrIlDhNXXUPFG5DJN4tHI1zRhoKWmiYjTwzTh4B6mCYH1Mk0YaKlpIuL0ME04uIdpArCe
pgkDLTVNRJwepgkH9zBNCKyXacJAS00TEaeHacLBPUwTLjgepokE62Ga8F72ME0kWA/ThHeJh2ki
wXqYJpx/HqaJBFtZtWFEK2wI3hYbgrfCY+KqKH4eF1+vhG2+q3nx/aek+I60oGXDsC1UMpYrGReV
jIVKxkIlY6GSsViJvGcoVkLcCcJPAQVT2MIDYYFpfoqo+Qabep5ben/Iht5OtGPc0CPbeafLCXa3
57DZECdJmufYx59Mx7M4gX0ecZtP3+UT9/dC/G8T/7vts9f38zxbLNIJ7G4dTvvBeTzJUfOnw+AI
7/Ch0qMlJq4e/DDGL//c+/tz7+/Pvb8/fO8vzsdovOPtP/ObZJ24nxEdSfAwzQbBXboAt3MPQtCy
x2ADrb3zRZDcx/Pg+fM6/VLb54UQc9FQhRAzZFsPeiBbk7sexKtJRe0lxnE2IfD8hR0Y1NkoBcEv
oOuB8NVSJ9/HCuLZbPRFxMNf1ZWqodL0cTFH6hNxpNfPFjmChkrYP1bgAi5APFtO8uxugofbQqYK
/SZquYfGMegahZp6kE6W44L6HkxoCoLRNEGagG4VEEYKSNzlDfsOz8fxp7QnPAF5EzGKHDaywoQU
/6DdvUjuQUQE7DJKSQy+2yQvRaSLFHVeb5Dmifr7Q9hWNkqwNUW2r99ddG5653XhR0f6ESCba/28
01lHX9bQBNsoTpeCHl4Biw8NZ+KPW1L67FYrjf75CrGYa/BsfbO56Yv/3EDdOW9jS2hjuBIWHxpO
DaVPvUvLqGjdp76lpd45pL1zyNq/K7TfheXQgOXwsKyXYlcvHZbgPzTg9+EQpe6ctzFR26hQOfCW
pVNDPaelXBhy/GQJg61XMD7x5EnnGTTK0bxNlGTw/OqmG2wsZ9iWDZ5tPQNbIYalUA0eHZ9c3xDD
E+CYpRIP/rHMwahBECT+nky9SHVQYxJ+TJCSRq/nC2Zh0edEG2Fri5hBUBtWSWA9z7fo/CrMlN9t
OqfK2WLOZkukmRa17zaxSiJPkuA1aLTkHs0/BBI1EtRdEGRDhCj4/jVe+NUoX9lu2jgdJ4hvG4Cx
HtA6kKkA30hx+MDbD+wx0ofBs783nvG38BA9S4IXQUgf4vVlOqLGTlEdnl4IqSNk3G3I1ZiIGSlU
jMzVv3gdjIq60X//DxaK04warehv+si6Bk1p8y/MVCX2BVnFIKGZz9N8Np0M8LMpxnh9091HZt5i
OZ+gZRPwczpBZuE0zcEsQ5M0sn+V7sQzznebTgMGPWd9SCYoIlavg8Z+8SxF9CN2Zf9KEe1k0iT4
8lrwkj9XbRRWOkNlNwjaF4AKykT7xJAFsQCJGc/w33ogIv8A9W4G4cda8AaHJUm9yHkh9vbnezBa
aW0/vMbVGXqfCaq52uxj0d1EbklU1BrCgQY/4UYGlCGwta8MFCSNwr9+LRaglGYaNIdgTM+o9BZg
NubxFots0CWORV0QKQObVFowI35NEdGTeIyXp0jGkK3fuTg+uQWVgWtZXeRUCxhqwSOgqsBhRJhe
UdxE00mAqCB4nCDUvwWGD42PW/Cmh1+xfvjtt4J+JI0COBNSodA3E1U7kZlSn69sFuiQjJbjo0Rm
MACDp0+lEmqrAaPYx2u0LWu0MZub+/TH1//uYWFXxMUKigwQ7D4oPDe4hvODzkXv5OKGUgBKejif
joOr7slPvaPL86uzk5uTbo2UxQsDNGIuDs5PvsGg0laKbJSxBQaatR8KKHldA70jDz6x9/SVLoZX
BkyPCaOPQmYFZaJAUHDsoVRchRFljTXy4xYHyEsmeQ0d/05xygAft/JlHyQhS3OZfjoEFHzfm5qA
lX9JNfp4Uccc5aNcUJL+ym2LR+jPBAnTQ1o6SA7Ak6CMBTi3h2wSbIT2vwRcxnt4roCnl1dHl8cn
2D8nSjigQbYMHDKSZZqvvL/btLsuuPmK52zeRmkSKYDHcf7JwAul3MctgNuXi2IniEdRgCNF4Rzs
fTZcxGNQUFqvayWnw2GeLoKnQbvJRhSlF//54QeODuOnBOE/6js6gaNa6benwX8CEhypyQik/CcQ
YveeEG9OcNi5uQ4my3EfcRwpQlyTrM4ur3pXl50L1M1IxyLwy9PT65Mb1HTuuBxkOWlvAP7QL8Q7
y9Q6wvcQj5YQer8hlM5ppdSTKld5fn0IwnR2jRaOOSySioKIxgbo7QzcQmQTAKCJDseohtk8h+Ok
C2zvFNRv1RTRg3NRJg8Y4lYPL7FAb8Jv9Ib0G/+Zc7FDv5FgU7uFdAsrDOuADV4WzUy7ohItXjxB
LxQNIvnUpjOEnvP4Q1HBixcfCwMVAQJHEegumpEV9BIYFbiNEEQKytSonVCA9ONFHBDqkeBRoH8n
0vEK/5TAB+kIw2MCNnHpfXYgMKD82YA/qEJ4CSK6gcQ2eBoQiX3zhuAoCC3oR1ykCPmbPNiUHoqG
FH795rXOU5mMXUyDhauIrmh7u6ZVuSvWRzsxNy1K9P7zrUphFogaEIpwIB5tQNfiZzWD/p7jKUsY
4fEY4kGok2ABdj/4Jpmlg4wSYWhTu4dTidELw5kOlGI859A2UPg/HZxhiMurLdjmSgO0mL5b3ItD
klTPDSzMNaQBCN3pQJ0T5IFpHpPPpzNEhup9ns7EgTmdwbr+dbBNhfG5dSR9FAbmBmDBR0FaWr/i
StHKAKHRNIdIIa65Hgj9Smh5QYjhPZd/zuAcvFBnU6kziZHF3ngMG68YJrAOCB2hLx1YAaxxEnb3
RRToQVEE3uDge074V4mO6HfREbYxIcDl7wGAFn4aNKOd9m6NLBbYUsFOIFk58OaE7TKqmyrVqCRZ
hpBKIu8GRDInw0hC8ttr0hIrPVxxCD3eQKoILak2ZCEAyxJ/MYugP8VtgwxijlH1LfZFJPcF6Qn+
SuuHr7oOwlWIWqiLn+doDp9MJ5v/SudToj6gYrNngpoSI7QAQjoKV3F1dnB0wpdQxMbEOicjW9Vw
AAUO6ZkUiW0HSjIqZ6M4SY3bSRg5VyqSF+IDLoVsOlIDhka9Rgsocw/mTkOdP3Rkw1F8l7NiSCqw
R5q0uHca9U7+o3cKR6HEx2cnF/C83To/urjR5EXfYMIpRhHznk/DOvonKmSB82YY1YNhU5jDHcQi
Kk1ECgIUgqyOhoBcqD9H5iQteHGMipGRPY18gJsEGI2YcPMNHQY1JMVhnXfr0yEZqxgqkqAiEapJ
oaCFwwg6cNhkXguh2yyuiYJleLQl0+Vkgdm2htOd0KlwvERdkP5zGY+CdmsTA73CourLHdTF7VL+
mCSTvESj14NhiFgfjmHyBaaBTkFcg2gj0n4H90RVobtkYrRcEI7WSg4Z3FiYumGpnBPLRPKs4Aqo
NnFpCK6RaDxKHMymeQZL4qDw9GHTBqqlFhDeoJmkd3jpXCiwmBEJ8Rm00gSiMTAS8OP0IXZjOUEm
TnB0nyafEOWjEddkxTqJrGTABUTDMNLgPrtDMEQBzubZdJ4tvpgUnGuHnPdaqWaDlfVyPl/AtkYr
/MhXt2hiQfyRHsEksJhLj6AoNvKgGtmHi5sPPQeUvWZuIfEdaxx7C+85LSLmjxw1JcH8kpKsvmyx
FRpdKOhuG8nMDF4ba+HKUjHxpfUQlEBUEGaYyNmX6yRzpvgEptwmUP1r46u8xkOjsmeuTlDXzPIV
rWjZOMDG81NkcAilLIwrWiPAQtLqT9mssIiJUU8HazGKt/j2LNEWeNFHTWuqQwVubb7mCKnWEOqD
tQUZetRjCwVTIqNooOFNshT2SMU6KXLcm9RLIh/8DvFx74IGWOeGaJHb4CymLBfFk1L0M1IQo8/x
lzxAihbpgDENocvBiULSDxRhaIxashgC98kaKB/weyTLUTxHSmYAfTNEGgK35X4+Xd7ds31evLUL
qKnlBMXBv5dNlzlWHMMYibXUdra6MA8m1gHERn7Fu0KHfPGi0Pacn6/JTgDr0N1GTff1w044aD2s
H+MAW3+oMIkiw6FmuEH5dJSOvgQJUZBDcI6vrQnw9eBziuMZE46M7J7vYusmTZZYLQM4LkmMYcw0
4thCoKRoJvYLjVgcTT8jkGZRku/FQj+BzGzhU8zodWcovBGnKqrQMaF3U9ZlyOb8gsvhvtNK7QdT
mIE+I9VYD2AWkbqZqfq1YuwwXg/RigH4D0wH/L/iSqh3dDkhwk5SJuwXrx73aSswAzcesb4MHmHP
iZgtweOLFzUCQTqRVT3Be2j4QL5zEG2IIzl4rIlDaU1oR4ZrIWSjx2ylhH58ZYD0C0DDPhu3K1Ta
irEp+t0wq/BaJ9ipMccbKyKrG2axsbcFMZyMr7wT+PbZ9wyLyP+KtBQ1sQq+MrPx9ODs7ObH7uW7
tz8SMxGP0fAVe0/lEMahrnGxyTNBIlUIIhY91goRVBoMbMG9xUxTf20gKAK2diVrWuUhXdAqakJk
HCFhn7/jXPJgUMQZdDydPEODIZ6D2xnPU+p8AabXagyKPm4V4/IALEA0JEBhg2saNZArmXi0T5Tc
OI2xgYeM1TgIo01UPytPfZzc3pTN3A8fqaEr6i0aDevVP4z/4GP47Te5P15790fk6g95ju7gLYQg
3MYkp1w+48FgDkH7YpwSphi8i5QLgNRl7X+O5VkVTfUxcONn7OPE8ynR8oiXELwsGugUL3YqIBpo
5gluiNP5lGq3z/DfHGlyNKsgLY3w5FOs2nGMdb5MkjQd8I4QrZsNxro3EPmBhwB7ojtWiA3MLWMZ
cIebH3gmp3u6qqFMu5nXGrS3t3F+IKVH4z6U36gJHceGSnc5KUwNA4vY3ImnKBKIhHeIuQRPUmkd
VogntbNpA9/QWBiZMO58ge19WfZJuY9beMGCl2aC8cU+AkssxRnEvjKZKn4htlCiniDBiSN/UJfy
Ot8oCxhxMtC1O537zFTiHgR3ioiDvCTjWZmFNCgmE9JswgXE3Adyy5SFGvmyb4YS2C7wl1VbQIPV
rho2ZCxmORv/c7Ssng9GVDt8vk/pshzLk1I9qAC6ni7MXPgINnqkrxz429c41iIP1vsx0hPEiKRh
msSQxjStb0FbxEIRLoRefpGpJ+dQ1BaS8peicYcmgAxPKOKEw/cx8exC69vSlIpEvbxsYkqfxdSw
OZmvxX9wdDj1w4j9rij2Qt5kNSOFtYn1sbmndCXJIpOsS/linWud6OiCX/AtcXfS0ZTO4dinJITq
k9mgj6yFAdJcPFwBonJwX2JPsxp3Y4j4/25TPUhg8rqoQTeSs5lsnM4yHO+FO8dUEd4PJA3cML2v
oXEyGk0T9NYQEEeg6G4hQrX5Bsf44ajHARJ/HtpD32K/0GujJ5H7uAVcy3FvulzMljhIQS8kvC8K
8bAFHpNAX/A4CBUND9Sg5alPE+/COXyejY+GQmFJodBUKCopFJkKNUsKNU2FWiWFWkIh4nw3geM3
BSCSeR7bhSGKV0j+UvRmkmR42/kpGoziow9EPlmlpl3mY4hu4fvM+lCDtaawzyPZ052L6wuyz4xG
HvXOIgMyBi9PNmCWGwmIw1qqzoiA6HEySs2Dk8+y+ti0HhzS/KF8KjR5WDEWdt6IbefQEvagOKBb
3AMyBKxJfsWkbzdslNgiPlNTrYW1DpT4EEa7ssOxisFVlEoyo7BpkXjipsgC/2tXKIJFB3HYEG9P
9aQQiB18MKgWHjD3UfRgUpMz6RfTE54S+8iqDs3WZ0I1oha6JYXCitYja5QWsLagR8iymmpsSnHl
uMaPoL++J6cHRJsP2BAvGBvWt9aZu0B+YUBYM1ibqOGojlCsAHejqbFS4KPqlKA2p8w+Kyo5zlBA
g2nKFKvEvkYBcmEEoH/evFFDf4eU4dBCPB6Dp5bJQ1hziZV8VQanYUbH/Uk4TmZt05JA+pjYIapU
IXCH69DrNJ4n98UGuBSar8QW451w7E4tQvjv6Ta5GGPMN7qwzmHxxaIy9bJyrCcb5XMehEV0lQqM
kg4ETWdIB+0RHSQdOlkOh9mjsB+kjDd+LgQfz8GmClpzIXXmqV0J/oCE1+IX6pmmpwQENkRIx7gD
oRmUdxC0TJGw+eTSaFpAsIRZZCCYwz3eSoGdshbGYOWamOph3BNiVLG06zGY4iGLOwbXh+2wQo8V
I1pEocasUxNYiE8nyOjgh6HPNQ7Dp/Wd0HrWgStUzAt+pc3Sg7vFRgms1PQ/fylUUCAn/PvK5yi5
GnAsCA0SZ4d9eTlYXpB2B64Y3tqCkj9uEdstHhWtoKqyUGjFMsUVGS0rOdJmq1oV+CTqVrYaknSz
FG2B4cga0xBQQAebfswDL8xp5fEQOIePaMDRDelsBnuK9/sFpCQkwHhCg3ZNBx8OwT5mtBpL588g
uBGO7uVZPxuBowSt+7PJw/QTtZEhYQfnR40d7punoxQc2ZAAA5WfLucJqm2ZF5tVLGSSGMeFCnfr
brqYJrWZgPFBgXTCz3Gy4G279mclyIqy/t0mOxFbvCjWHS+QCUJ6Ru4YEqotTGPaMRmxG6ALsgXu
AR5f8b+pF2wT52pzZbGS+79m7mTrFuVYoTBXCk0nwP5LsXKRF3SVJM2Q98QsK0iXEOEgJ6p1mTOJ
jDAMcVqfjQ2cueR5jY82wkjyMiWxWF/NuSS4Uv4ii6LwHEdXy0dpaBcen1xtaGzlvcbY+dtvtMAb
bIYvatQRtSFZvfzApvQYTVY1FrAod4vQI0+lEmTNh1v8LTJe3ftlvLr/I66waTbNGa/uiwtsql9e
Q9Ja4X/buED1y2yO4wckb+fTvJ/OETM2b2K0+vhhAE/Hf72fjbbuZ39mtvozs9Wfma2+aWarIc7q
xyKpez8WCV3FZ2qmq+LuGwoM7FkimxwYFPf7sK+Fac1fsZrYLSiXM8flNPTelKZ4b8r4craG742Q
bhEhaPDzx1odgMRaTjvd65u1NSlAHB4Jd+z0Ohe987NbCYY9FO6APFDxwJPi/VW385P8Hp4U7y8u
0YOTYxmEPiygrs8ubyIZBj8S6sGJcpWa8DOh0TQEfs0UFy80SYzbX7NG9BcFzi+Pe93u4TVbmolF
2DuBUnL1pUIqeSh20UG3d3T001oRbE4eSABXp9cyAHogY7g+VjBcC2w9CoWXR6HwYld8sSuWaEtF
2sWrt92G8Ar9EkbKlfCmcyVKh/Diqiu+6HUvb6SX8EDsb6nodVd61TuTX/bO5NfvzpX3785l1jcl
rgnCcSiy7FBg2WEkvhAk80hCdiQiOxWRnYaipIovBGSnIi5RaE9b4ouW0Fyxjiuhjiuxjiuhjq5Y
oiuU6IolumIJkSqxgd1mTyqDfop8Prp614GnwokK9qgAOj5EXS9WQB4IADcqwI0M0FEBOiqAWkVH
qeJcensuvbpWypIHAp//pgCQBwLA+ZECgB+IAMcqgMJmpYYuqUBgNNJX26IUwm/h9cVNFIuv4bf8
uq+87suvE+V1Ir3elt/KNbfll21RPC6v2xJd+IEC0FcB+gpAogIIxHXOz0Vph5/yy5bytiW/3lFe
70ivo0h+HUXS65aCvCUgv748FV6iX+KrM+nVmfiqK73qSvXtytXtyi/fKdSgBzKAyqldhVfo97tW
oILoWN7t6kAyLXuxXNNeLL/uK6/70ut3CtffRcrrUH0fKgAtFUBuw7u2WkNbqaKtYmgrGLaVJqAH
MsCOwgL0QAFQMewoGPaU93vC64sjSduhn5L5I1IPP6WXbfmlMF7PDyFYQCxMnwggP8IDURDpE8k+
EquAn8XLm4O3oUg6/q287qvvBcbcvL2JRG2Efyuv++p7tXyiAiQSQLtV2IAEAnofgaQTtP79ve4R
D9fIH+IWae61NbcIcYn8mMawlserNlg2whtX3u+No9p/v5NEWd/RGBK85LovelN5LKzyfsi/5C8h
ziTfun8jr/8GWQ6JjukS8LtNgMK590+Pez8iO7/3Dq0geoedm2IrEHvWDLEv0ELqIMUChW88veic
QYgdzrKZjUbpHVpj40AZFnpZgB4QoMkivYPYzdEy2OhsgqPgHN+9WjMU6eAicCgcwFlRVMxW4BwX
GKfj6fxLsGFHfIjh+mhZDmefDq1wpxhuOJrGsL2+SZJqbpxa4W8xPHYo8JD/jVsr+PH7C1zg+Msk
HmcJE1QJ8OLdOQa+hmdflc4BxGq/4NSkpn7BN9xKuGl6WLFfLEASYy0wIlOh4RYwI08tsGcFP9cB
ZN0AQ3g+jr+AS4s1A4kV7V0dM3AUSgocxYfQ0OgksezYDQRMTucxOboFZ7P7EAI8ncV3MU2xSkLW
yDl5EodB8x31h4OXyWy5Kd6ZgEkoOm46I8mvxI7DGhp1HBV6hhtp2PN31zfB4QnxlHxfxP5Calvw
58eTRS63UVhiY3SwDw1hxNCaeXqX5eBfTPJBsBHPt9DfmqX40U+O4skDKZ48WIpfnV7bi8+GOS6O
/pqKH4W4KEkuRtoYhCa4XR1u14ivbUDYNkC+7ZJxczdvGN52ruh4KQ4AsXNcG9nM1JKrLi4xA380
BAkWLNiYzc0FwL+AC82nCzxMLKW30HsjhmtW5xTuwUCjASJ4lrlYODfXDQ6KkrJnuPTWyFb+3XkJ
gnfnBAOcpJWkmUOwaNZXRsFq0p7M5gOzbP2Fpl2KGptR20TmYSjOAFq59uausVTkLBU2N8NtoyxL
FEOi5/l0VIHaU0It2QpXNKeAxVCQEJyncH9gtZIixZUKtgit0+V8cV+p5JXYykLejaBSu9ywXRGt
k4CuhNUNKrKnBLIXmWE3Rtk4o3MJ0jWbd/OmMhzofOsaDOeUEgoKxwcHgznZ+jDQxlHDsZJ5miyc
yJkDjCRRny2zwQeE76MBkvjBMNygP7dC3RRQCytUp4DKHFBFjZm9RuIAIxzKrVDEC0aU1ic7FHaF
EahxYoc6LqCs/OryCudCfUXvjMdIpEGind0D/iuMZBvOi9KD3RvNkGaAwwqlZVRI4FTDJSOxZBi8
oAV3NiOjBsTuNr2gUOhVQK4Ua1pKJ5bSzcZmM0Sl0fJrB63GtvHmqHF+NreaaODWZmijm0z/bRPZ
zchYBnv49FLtpshfs8LHvj9XUaB0z1o0cRVthptN4zQBTj+iwcjpgBCXL2QJ2htYi74jaoqfLYgM
pckcZxQp4jiSUWyrKJoRkzBrTxH/koxnx0qKkYXEA+WDwjrjXl+SZcouLobsF8gpMYdTABCiYixw
JhYAIKSD4VTIyGSaX192hS4ucqtye4/pbWQj5wgHcSjYGLYr9vqunVlwbtjW/bvvyMSdjGet58vf
i0wWRBXLZlgBkRddJoxWhLsMYTV8FknbkwVtz8ixZnOz2arb5Q07lkWWmdG0N0NwTCEFaaVnr1+O
BjeqBE/YklRJy40IqVAXrh0JlzYWo+di61poInAgexeFiqIy6TnAFm070ESRSFNk13bQvsiucd9F
LYUcM6sQOe061t0uTrUkrrc0VNH/G7YZs5yI3rUVdd5WW2gpprSmrZEwmi7yGCvxra0tY+0XR02x
FU2MQVwivQpevNxEfYxGBHheTZM8uPrJ/UzGCbuB44XN5ZwTva0c3R0QqhwvH4krs5gqmsaSZNNA
0P6GkjvGtTKa6S20Ws0DvIkgjSbC3kV8B/4HaF5bHE1Y8VgR9b0wwYg0Wkh4w0EaRmTGVwmxD0Sy
p+GBAmuGhkPmyeZHKSbUSCcOJP/UBqeSbymOqNlsNTbOakYhPL49v6Ses8mXIP8y7k9H9eAOB6FB
SvJuDwMTOClHiGAIXr67uAEUfyGpNqijEdz8wQbzCEKA0/eMBNU7XETw9sb4ojnsbcQ1HP/U6x78
XBd//6z97qLfDpx5Oo4niyzJZcTXvYvLi5O69KRzfnXWOTk2PjyVnx4f3BwocBfXN1350fXVyVHn
tHOkPL25vJKfXN78eGJqBQvD7rGzxnOxDd3r3sHF+7r0u9v7m/rg3cXBjfKsHmAlEOJ9IzxvRE1Q
+mQcwihAOghNKK1ws4VetLY3W2gObu9shiHzbRbI+hhba3ezDbcohxEaAzsK0GFXIuDo9Fz+Det3
+QmSvG5XfXSmPcJVNzd36hCJuF0Pd+tRG+jY2d7c2avvmmg5Vog5VX/2pd/gZZV/Sz87CjYkBCfd
nzpHJ5iyo+6Hk8vOR1gioq+dn7ofFWLQul8qjlb48u/zI+W3zKcrxIGA7j0xmxx1AuKFUtFVd44p
EoAQoyINCvFOfIAZLnf3LcZz0CVHh7JJgJ9CE4k0KCiPaIEjqcBRV635mvQl+ksWXvLr7jVhKMT1
puN0ssCO1E06LBKE8kQ4s6BKaO/06to4vPKUDzF5YJ30LtAwPTj62wma/n58f12X3h1ensoP0Iju
nvS6J2/lx2eXB8f608PrK3ghP+yiQXrYuSEXVUlvjk7PTuQnF8ed7s173h7Els4EMjYS53Lch0jo
mGR84kwJxOMTSq6B4hVlAsJ4AWtIGpjMcRC+qmd+9mmR4ynOPpXlYl2TFM1wQ/CxooUj6y5M6L9T
dC5tx3MszFkl57DxiOhSmiOiUaYTCKEvaCyK8WnBhaAA4t8Yqi7zWOJjHHWcoov4+Ps0VRSMsyXE
3ecBqFzQVjgvCxJxVAXdTeLxaCdv8YREQ5LZdRx3RfICVOc1ycWG3g2nkPNFbYPYNQCzL8jIzecp
ST6GDw5gtOzigyJNWcEe4ZxGcv+Jhu2LKTZ4IkqIX0AVD1HT0bj9fI+krjjQnZHzbbDLvITNp3QA
V/7dmfEVuz7jeP4JTi7A6aMaw4kxcbz43RalrrhfkOCB6ApkfiDboQaaCYfBwwNkPLALq5DdUMOR
5Vy+6/Q8K6ZPxsgRdDECVPjnmnAxEK1OR0ltJv1slD7ocEZcaIxwXo4vb8i5uOf8NQYGOh3A9DUX
ALzTn75kt1/g06TTRfqSHHkiaU2VYcWFE85PXdRvIap+46L2ww9hWPtt47YmxM5fXN6cbBCA29qb
NwjgaeMxPBUgAAcGuIVXO6enNUrYQYDvBYZVG1wNPM9mC0QM+dqnF+MgYU3wzfR4o5xlIEQyhJqC
FB3uB2hCGifsug5IBQcHbmAhCEciEPwon3KVktOMqXRPjl6EJu6X3s2ny1nQxxE0c1IAH+v8QvbY
U5wgpZ8uPqdw6gQNL1aV2uXFtcdQB91Lhy7ENfRoDV/28V3GrydTVucXNEu/ZhUAckhFCX7rdJEU
WcPkMAvMKfyNpeWxaOxCMRQpbWh4AGTzpokKESt14eUrAf2V0EAZNdRLy1lIkkrhdSntR6FPXhla
LWe9ERFdcH8lSd1k2KWgdw0JuZ1MxCOJS0dDfCcMXC6JDRSkK5CosTNKQ4hewYeZ4IQOwYG1FU1p
D6IKSX15UkFcOSO/SCBlqh3yfmzRw2mZfHoXzTJxjmYB1G1zASTmBOBMVPTKXpzYc4KVPt6HJJmZ
lQbhGBJ8XpSfGQoKtYvGzWhApjHSGicuPPkjHSNQg5M4Q3FgCIyh5RjJ3BeBf/1iI7Fm5BXNocU5
dSDIKlt+4nyPqPQJqAM2YeCc/KDr2KSndhOd9PDVP19gNk/jOTufhjNa03YJETU5ZhhHVJSh3fIl
IOnTWJNplgIaeUfyQgutlCNveCUftj+KLb6ckIS5JG2WnJaKUA/n/jCDMzSTZogKLDT0UDiRe7oV
zU1oHgZBcvmnk4dsPp2ArY2Mn+UMbmKWeCaMypzelkQU/YBdqgQUQApOaGs6mn4uVJaUGIql+OLN
e0cF3HLov1bgYVerLpSkmsAjAi2aGFuK9nHOynAZtJQFQtCYP5H2seayDqDdAUOEWAEOzakeiOOn
ydY2wh9+aNTwTjAN5yIhAdmEXirBJiZxghbR8FNogCms0SggnEsZ0ut9JsPslkwocCby7NaKCx9V
AzyRRNEorkIQPs8GSJo1Em+TPSAz644mvsUsshUlh9igbKtoiNAK3IYIabXRFysOdlwOsGwXWJJ4
Qm+14HEZA3sTyFE5QNGWORrM8nQ5mG5O7e3nZ+ig+A4ujgVwjnTy4lVwGkGWk9OmvROkw3WAZFdD
gmAAS7u1iWCsmMRTd4Bnj/QqnDEG+wbu85jP+zht/NHpuZ0b9DgeFjAiq7MpLHeSOV6cw9kfrlOJ
vGMzbxwnc5ynWrRBx/E/pnM+v0BiKPnuFDpkFDo2MnLeE9+319xhJz3l9T0loZcgec0Fy0RwXiIB
v+4dXZMoNh5vZ9juxoCwll8T479sgGgdT8PvaPhKaYmDQxqD2M+no+WCXQ9hp4Ts43auNufpSLzL
RfSxcjuCzlUe9h2GtBh4+B1drli4HOB/qSKGFWu6CH46OHt3Aqs5MRIVmwnF1EUesuttrk/OTunE
S+cbPY6xuLn1mCVbnATpfA7ClCTLeV4PnuNbbEiiMIqHyvqAn03n+U/offXysiOJ0cQpXv8XkCrY
EWulQpLaRbwN0LAw30BL8zydw2VEjgutwOCsC1YP7lySm0Z4+hznRC3YfSIMLI3TeFVuYDQMOgOb
MfPyBRxox+kHUH88x11p4XbBIpFrFAh7hQhnufFKOS4wC/NU5HNVzhb3PFVgLbbQCGdF1mKOC7w9
YASTG+YhEz4RGDAT4J4Ciet4HAhbJlICnMWcoqX0oS7qYbuBtJ3nd6HjV7nTNpNqEqxHfs1RYU5h
HD9OPwfDWB5qiJejdEiv/C3SMOiKt0CMQcU8M5hkSOS6JoeCB/dosI+J4MQ0x/QYdpgQaZu4UM75
YjUFRYaB6OyTkNYsHXIvAUgp4Pmdhpms8sBLWKyqQG1RAgfIUB7HI5xKEdL1A6r79LH2yjQ/QYTp
2cHb3vHJUef84Kx33Xl7QW0QyOKjV8L58LuqeXchVBSS6fARElgaTN7CK6H+/hC2P4rzB542iD2P
1gd07SLN21RC2SqHXwYTCFcrkxUUrJD5IkpcvrIUGUBoRiClBQa0nrbFkGpI+J734g9AvidwVgV4
XAW4XwV4WAV48IH0j6vAc49sXc4an1vWX7ZET/s+9DgSGZO8a2su545UB04l5Z+Hat8xFMRlX1lm
KT4wpkGMSUiyObn0apT15/H8i7TmrBPtx68+4RtYNDkNODy0YzivRGG3T2SGqxM/KPvyREzIKUqY
CaTDeVDL7zhZSf7AoSHH2UoG9EckndqBMBnheKWRgq0kCDbR3I2WjJuj9CEdBQwANjdwHxyyFPqo
RLJ4XGwlJNfQfRo/gO+E2Yxq1qqo0dgJbuYZrBmCt8gWmCL19cPijnz7K0jl1nD+hlVzi+kBIfBI
BBWQe32KFFBEWhb+SaBsCaC4PvZNAgXra1IJxVhnWyj+OaGKtjtTP6H2KUmfcOnqiZ/EpE8YxcqJ
n7hZ+z8m8dNsPr2bx2MhyxMkgfrhfrGYvXr58vPnz1t3k+XWdH73ckSw5C/fIIqo34kfxl1k4xSf
wxXO5y4GSIepD7/kL8fIetNhs6kBtDjfKz+Hs1XK42EyWYyUZ8sJko+B8hAtBSZqXfH8bqZWgwyo
WEVIbHbl4V26QCKrnULG438+wqeQC2D09CW0APxWyVihTTm5/JdsCMeWe70f319BHMj1ZbdHZxik
dJCaLiy4Hw9+OkF22+G7t0hfq/VBEm08IbxkBUm15Dh8ken6MenhM31DSBD5HP1C9vZglNLrRIqr
VYPBdJwN5McPaNLp3SF7edGDDQKY4hc4D3MPKUG5NDwE8H3RdQlH6A4vAumzEb47g2RbrVZNBry+
tgA2FMDjQzNgpGK8sQG2VYzHZsDmngLYsQHuqIA3FkCtagtgqGLsdnrXP3ZOZfCWmF3q9ByC/Xvn
B9d/E2Eaj00sD9BLD9kcdeG0N7v/klOLJQcDCmkIvrrAuuQBzl6pD5/P4Ck3bz7PYS9jjnUbkRRR
UJCi7y3oPieXEhBGkHUKvqDAGxYhLU9AD58lKtqMelSCK5YBSvyKWAYDsgZYKlGexBM1wNBC2iZK
pl/NG4ZaKWdruGqWDZUzeQSyIF+rsXjsYS+4CRlpgtaCDfRw8w3EB2zN8jl4UEUZBF9qk9XM6yKr
hu82F0jxpoveOJ71WP4CWY6IGPEqKekyDOiTWXwHekouXaN3KuvleJZ4qBqVE5Kr0vvqcMXQmNuj
3tXB2xPWmu9f8/pq4s1R9IIpwFdTb5QaLydQDXtfL3B2fjlh9x6wj0YUeyHcHya02EznvgxL8CG5
AkajMZgiLvTmcPQ/MEibSJ2fvOPPVffyptc9OTiuFxzaNzII9hagcRqjZsRNt7FOt1MAFvCsm5hE
GcD7mH30NMYC975KosvoeRHQ/n4abIith8u4amJK47fpAjZH3t78iGxfiGnGWwwQHPUsR4blcAiJ
8yHrKJZrfrkjkm34Skz+G7jzbEjM7jG4ncdf8EvilMA3l9NhAaFAfFyghV3vYRwzXHVY6fWAiOA5
QWDpKml8j9LJ3eK+zhaAgsekh6PAcJxXMdyw1t9XdlmLcSmNGDrVC5rgKZ3etHEiTy1hvWjTUzLe
8ZWoNWO3nnQu96WuxJewCRVAdOgIts3fHUk+x4AOldesNkTff7IptN0Urh8hX/BdwBm5CxguZiGs
Q99fvJAapOgUGGgGrUbqfhFk4qUFNB83Hw4lDYYP6eoPGVyH9Xy2bxLqhiCvV3PoQu5cHyNhRKOG
XA0Ki0TU+8sxz5RLwj2yCUsOn7I9fo6A3YwHUk/EXRRSym+S05uMZc6AjF7wvcyJ5Eqi7CuOOHE7
zqqABAQxpiZ3ewx3296DpTFRun4DY9p8M5wBQ4a94XKS1IAoeIhqT+NxPVh/N/k0mX5mbX0y+Ptk
vU6JZuJR3EtFKz1IFst4NPpS54OdhVgxMQPnCvv+AsQILmuUuhrWnOCOh0VzvgLlpTp6/YDS1nh8
sg4ZYR/brWAd34csVQ0NLkVG2yKqRRwplOClKU5HA07xdBbDsQ+claqOb56FRes4Q0uyZAle6jHE
cGKXQz6Lk5Q5sMhUDSwNkH3yCe4SwNF62Gss+tX/zxJnTADBEi/SRZTcp49C+BJdCg1oaCm5l2MC
oLDOpw4MfMtrf4pWxW/RmgFvavX/MViOZ7BAfsjwLQxpNg9APDZQY0i95IwLTZFNCUh5oBEbCfgE
TAb3A6AyPUYnV+iVhoCfIAvdTORS7CzMNzqQgXEktJuSxUnH8xCjnLSzF1enPpDJp9WGjBw8h02n
SF9PtNrQcoNcd7cRkycIG/oSHNzcdDuH725Oeu8u3l3T8zWWj5OrGiY3ndBa+ItU+6gZMf93MQvL
lqqyRuJa/0G3UjEP2a2MAPGbBST8CHPVbilchOHCdilg8yNZDHPqmElP21vDhBs5gBTI/59xwA3Y
woDNqBRw+yPxRJQCtglgeWN2MOB2u3ov9f8QOfXkWOjbB5FnpzY/riCnYfu/V06r9tgfQm/1Hisj
m97bMskWPU25bji1bp1stT3ntssaveYw4HMa3qGTZjjeeGR85OmCTHh1SJvCLvcl82RhXdNpchQ/
wJbCa8xNapcviZnXoy/3xQL4vkECDV8ZrAQDbtMY7jmDfJInF8edgws0gfzt4vLnCwlumizSRd5D
hjDpx9dBKL0XWwiX9wg/JTjCKXI3MfoivROsb4ZHXzxKJSgwsc5pEclWl6Alm4WBGw0amWTVYFCL
agCm4twC0MqxN1IpJG+zUYya5uyfr2SrGwshZRUW1GDjtHN2EjxHFrHqzCRB1/IzkDvbmJwV/UcP
uHM3lHlg4AfjHj1kRWA7kObxuHN9cH19cn54dtLrXJxebgiQ9QCTSsWmkHwBZMtXPP6CllYNvThZ
4smuKP091l+aShHuTjQUIatpkGnEx31xL0ItYOrNs87NzdmJAfs4xsMXLdlfvoQxDL+xG3lfWtbP
EnxlHyIQ9RVa2+N9/ReEFnjy4jXpNtlzAQY/+EZfYwQQItoYwv1NbIYTdFiwgfsGDPFG2B49vngy
ePUkCdByEpf8Tyj67qyO8Zns140NEa4GHgLZv5LNTFbv06eUwteCJ5cWrNWCfw+ePX8WvAqeBc9k
NwRJwvCarGpIlATOIYyoqAdPBQaTYoK0wEdx4olOI/YBH/puD81pUrUGhgW/ar4+1RFDBpTmh2Ef
k+8MujTIUFP6dTjwpLZIRaHS9KQRPaKu66uwX91N+So15Wsh5JYCaPWtOUxxx/ygOcP6qHmfCu8P
1Wl8DwitaE6ODXtAwXakQal7QPAJZairqwsDsjDSoRgy2EhiHxnqoGuiK9jToEx07Sg1nhlx6VAm
XE0ZysiuIGirUCZUKr8OzLi2VSgfXOdmZJEG5cMvM10NFaqMrs5Np9v728l7A7pdA5SArvGoygSG
uro2URbpUOYNSw2qo2wkS7Ja4LpVmSpQD7kKO2ah0KEksvQ2dm0tlNrYNbZQbSOC+unE2kN8c08M
zgN1OKN7uDNsOGkbagL4LP/wERaxr5EqDoLW39ZBlQW75G/Ypr+DwMNTiICCdksoEaxH25UxBOG5
iAHRdF4RQ9iWMbSrYkBUn69/3ZcXRRuEl3C9oyh4aA6mL354Lcoamn6Vza78AwXcFBF8RBM0IY1M
tuKWLTZaqdXdW8zptnzdFI477+ErWIPni7m8n0PqrAfjGP5aNnf4NK3LxzhG8tEi8vHzIe0S7Y8P
V98dYfh3Ryfw52fy6yJerH/l1VMGvUbT+nzzTbbI8FanrDOeStqBNoi0jhWcodUX3piWFOpTUXXS
crMY04ZMPLVcMQk+laY7fB2cBKChQt8QEjr0AJx8ZXDUCFgPPjyJBh+DJ6MBsjiQ0RgQ2xH+NPGf
CL3I8Xvln3WJ3esYA4EFPHgbI5O7hLWONa7QTk+FSUAvM0cCiMoo2vGpqAj1Qg8x+IhncZ0LH1NJ
lCdO2k7EegSjxd2gM6UQtQKchQTb5KlohrgLqaw7KC9zrJYxtYiIMAzUD+TrRx2nNCKKGfmpPPly
77+gP9CKwCvIgyoVAyRObIHzQiAZf8qXJsLSV9s6xllI+nkPFlpIaw3HvXw6LLxN9A0MGcAE3pit
fj5D+lH8iQ8RwbqLeQwpnqIYeoBYIAY51dSxxvC8YoMsQE/4D0bJ6yeDOoTWviZ7ger+rEJTXXpU
11taLLq0NQ1lhbaqAY5Nh9A21spNaXGlsRYDy4RubGy0I1RuY4Nz+AUlFR48oCK14AmaFWvoOfzA
i9om/aWsSFgdb3jzHEsTieXBHDQY4/GTHCklnJkwM0wWnLoPnORN1ryPBnjEyydBE8cNRGiZuw6z
/itpRUXXaji2pwAW11WcUFpKkRgBl9Ck8FXAJWidCQB4Ug2wkRk2MsE2OSzW3gy2aYJtmfG2TLDb
ZthtE2zbTEPbBLtjxrtjgt01w+6aYPfMNOyZYMPGK2NfNIzAoRnY1HOgGUxUhKauW8wsImHsu7Bl
JsPYeeH2KyMZxt4L22bMxu4Ld8zAxv4Ld81kGDsw3DNjNvZgZO7ByNiDUWgkIzKPvciM2Tj4oqYZ
2NiDUctMhrEHo20zZmMPRuYejIw9GO2YyTD2YLRrxmzswcjcg5GxB5sNIxlNYw82zWOwaepBy8eg
k/sN02jtfyAk+Gj1WT43EAZ3x2igaFY2gKKnBqxzE12zuS9VWaFYXjwZcAQZsjRgHVjb4GQaY3A1
hEIl8j5Ivhhgh2SBP2ybTMj+/A+zIB19KrCZ9akCa5yT+8Y5uR+ZZcWkFvpNM16TVugb5+S+cU7u
b5tpMOmEftuM16QS+jtmvEQjqJ2Je+G/qjv/NJv+NJv+p5hNxonmMJ58AhcKbJ7N4byvbf5hkPry
UFDHT+npJtiBCwN824vlbQO9DbUmIFOONrbEkENmnAHQIE0GjH3UEJM+5ThFJQKwhi5HlqGhfoOE
IqvQAGgQTwNGXLlBhDhOlVCDBCFDU6/fZGYiI9MAaGi6ASOu3CCRHKdKqEGdILvVUL+h9chmNQCa
mq5jxJUbxInjVAk1SBQygw31m1q/bQI0NV3HiCs3iBPHqRJqkKjINJhMNnVkGkwme9qAkQwQkzxZ
R5NJpkzDyWSkR6bhZDLQDRhJ7SaJso0nk0pumgaUyepvmgaUyeI3YCS1G2SqaRtRpqUxtXs1h+h/
nTU7SOamyS6Zb6E3BsN/MbaAozcG8IfYNO8C+ENsWJYsYgt29Ma0CjEujgC7cYGU5cZlD8AbwTOj
HQDg2cwAPrQRj96YOJnNDbYA5mRmpia2NBa9MZGTW8nJTejHNt5kpo69tzb23kDMKBtYwNEbk9hY
O+rBwJrFzCbDi5kBPJ1mFnD0xkDMfG5yJAAx87lx1Yeem0xTWsJknqLnJqcQLWGyUdHzpp0qk6Ga
LR6sQ/fBMBbHNnD0xuB8GCcPZnrgjUEiBK4qEoHeGOEtPIU3hk5+6CV9URNjJQinbJCWjEejfpx8
6pFhrGrf+L9O+36aG50J8Xzrk1m0PpmXq6SASbI+zY1uBVLAJFif5kbfAilgkqtP5tUrKWBaBH2a
G70MpIBpGftpbnQ1kAKmtewn82KWFDAuaPPEQhJ6Y3Bn5MaZgWy2GcFzg+yKW4g6RZN4YRhPQBF6
Yxh/uVHD0svFdfDEOLrpZeIa+NJKzdJIzdA8MyP4oXlmXtj4j94YdJN5bqN3meu6A5AbwUcG5KkA
LdOSJkZ10ZvT6JfJcqyGZs+NES94e3hOgxdY8EiNhC4UsSMqYR+eDD4GPBwjeqQBGPpyH9NRVMCj
I2qu4AhrPARqAylHY72MHrs/TmUyzmUm3x3M+xAGgsknzXhIBWeyure9S3a1i4ZLXcgXAXCo2dTM
Qf+/sJkq7Tvw58XrIDLtEwf4DmYkIMK40B6Zj9TyZgN49rEOtUBksvAQHlgXLyvQOtBpVR+V0Dow
0TqQaP0qpPmFNKQ4tyaLZzBeHKEeoM//tc9ScEpRbQU2pMx6kJX0A8SgERS/FlT/uo60Rxh8rZMf
/ZT//HV9ORN+xAn9IZYdD0cMBH7cFz/Qtx0FOEsEdFlR7a/rs08G3BJdg4VQdiDWOuC1ioVzkfSZ
+GOQCT/yzFB20BcgRmLZhfhmvjAT3VIeJTOgNiLUZrmAYWxiaSa2NBuIlMfij4Gp1SL2ecaqRT9S
E3h/IlYlYn8Y6+BwpqUeNHhmkH11ewuy425YhBAnkdUzIQmRtdaCqthnJMSH6yB8GxRkvKNJToWE
AHjIw3EoUjsJDELDf7D5Bg+oYCApWniPFAJ6i0cVeTHY3OTfyQ1FG6EUcgSlNotSXA0gNfKcVqQd
vICXuAAE1YTBb78FGxs4NvYNDiiCe2ZqNV21FOoJhwMx7Psu5C40r5+M4KCGUvXGRghBlxhFjad0
YYW/yk0cwOEZYG9JWBNhI0Ug4JBEaFF9il7M6YS1mEvT1dZi7p6Y/z5BFh2am6/Y5PwQq2ySHrC5
G0ngbKREkAbrMb6/KRjjIp/SL1JMlDrzsDOYJCJxnkP8mPoMr6wshsCCGAJPOWxm3qoPBv8DGjgw
NHBQoYGDooFfWa610RQtjCGfEWzB4tOxNK0CqqOHs/YAOH6znPgBZzhNX+8xnfTuv8zSOay/A2vy
NKAU0hEWsCCk/AfhDE1HqKQalNICyukJ7fXpY1j8KKcvxwNV0Q6m4ziblGCBpkvkQJOmM3ltME8X
Yg4pExv4dy4e/MkWaiN8XjtyNO6rZeL5HRzJfg0NM74M4SVpovF99FE/bYnroc0awnXVhYxMZ8Ip
adR+GvgoqnCed+sI53CB1FuAIaDn52A43KaTggzpnNrddDGFo6hhoQ/JF8JboxAysXsqiRijHgri
Q29q4iicuhMU9MnB0dHJtaKi+XG6fIGmzXl9HfEwWYxIHnmc3n0YZ3Av1OYmuUwK0b1ukaH1Oeq+
bERudVjm6XwTJ6nBWYGDPF38uxxayqZ0J99xDwGjXnH+wEES9IfoAi0f58MU7uKAOzZwar75qIc4
ly0KQ4U9w9ykC2IkFYIRwgvR0+dc5XyOwSTBQkbK4RyD9syF2mwFGV/huqdgwZZSqF8hg9xkOKUJ
FslxZmGoCb8SfOC0waV2gWa4h16eJvRp8WxCHoaN52GjQf7Zl0WMVIxa0ltOZvi2CC2rnSpe8pFK
Lv8aJmFSkHhZkGC0oVS60PqepEbQs+3h86iEWeKoMhNqIZaiF4hlKCjmLdyYgcWmkYsU7dTMvOFw
tMzvWYSYaqchw/V0Cje74sqUPFYmrpT0VTkrLOxQe05tL/v9VcdmWDo/Sf4Oy6T1l5t///tv6x82
kORCkP6ToPCzunkziSfTfJSmaD58uqC3jwi6g3KGJgM15Tw1iQ0ZrjAwxVH9TZK2ltmlxI8iHUfn
xqntDJpiu7Lvk+VYXPdcpzj/BmTyFpc9IAC0HZJIYhMZ0UOsRpHjyzFNLUAstNxkl+aCYSp1hppR
sKhmUFqNbh3mgnkoVaMamcALsB/rqC7DKZDCi2k9Clczn4WDj3LAL+/hqxxfw/3AZ/KRNFkZbLDz
W8FTVgpnI9h4oCkU2UNNVzxn6RY3+FE6tBSTDoqrB+dqNbGW3yxTM6/6PxnovqZmWB5E9siY/XOT
T4jKMIBUZNhviJOTGG66UDISzpMxGtvwBqmJbLaOOSTqKlrhUzWHw74gcAZUs3zuiwuBliDL/Akj
+9sl+PoNX3T9ImOSnD5RTViJL+pAenfaSx9n8+DXk9urbu/wAG5rx1+v353Tb2eXbztH9PtV9/KY
OG/wMInhHnZcfoP02PP+cqhpujlcpqHUB99qHBG+pQRjEPAIlhV+VuSz6ENCTgSxL1kFWU7Mxo0N
yctZe94X3SH9Fy9oMcAA6Yf2JUHF1XyVW7icwOUgJU1UyE0KWwZVIjQQWsYU+OcM36qa8AGdxEgA
njWeBVtbW8GzvWevBB+aPPAIMakyHIEQkrxogVYXyBbGxD5FMtQwzfQpCBXmtSm7B5+V+zFqJ1yj
HY+UvBmKdGn5gZVZn7I81bUF7hrBZCCMeCEyADemxrtPqFbqJdxi6A8J07+VsrK/78Ng3rfiQ00Y
7lRek3TAupEkCzL7wKnMPvj5tQJU1Deep3AU/ln8DI7Aox8/oB//eob0uFmRM/gDEf6XcviGCL/n
hkeS9Kz3DNyR9MfWM5MbMsUdqItiH8rozk74cDnMBsjGgQtd5sEYjXa4wy0ewp0lqHurC6bSFZJg
wQeyxyKSgk1DJh0Y0/0PCOKjUog8FNZVBSF3OLWWONdpSW546cTII8DxvTF/MXzo2DeInzitTPC8
0keTyiCC7QlwYeGpxda32M4sSmVyKWOHGcxfrT2YYl0diM3Vh/XTB2vK6oLP5g5nSGWr/TkWu2fZ
szqz0kFz6E4b8cPFkSZOhxunSGm224dtary1/sASwlYl1bBcMphaBkjVoNaopln2aD7d/1p9vlGi
z4teJ0YF0+XU+gDzxJWvfFNWmIBNmXih8LPaMz0ZPuMO0ysIyMAaE1uEBssWl6WNIlcG6TBejhYC
U7RuYleGPXuSPAPBAsakOdzQRKK+RBJV8kTvoGT8fQvjzZYjE6+bmJBq7xhpio1kHe4jrb/1vjZ6
hexWF3x0y6sQUsnoII82xUecXsSF4A23lg36yDJiDUIh80AQfmBBWJjkNYtjxjZesY8Jq7gXzwzF
oLNevBb7hX10UWbwm0Z41d1D+Pa8jG+wnnAz7r+UdfJbaO1zr9bq4xg+dEIuss8YmsceFYtmPEDp
/Qa4SfH8zrUsmqe5OKaeCzYleQyXC8dgf8YD0Gx4kSRmvl9h+cS0Si6snygaVD8yGb+vjo1eOQ17
AMjAwXfkZZN4MVWdUwhDgeA5wiB5iM2LOsIjEu1kvbgHv4FUjug3X5nih7ngHWQPta0tgS3U86qV
tXkWn4pVf4AfH/196EotgitW3fOgi37Yc6M3O/waHJ0f90663ctuHX+9/Bv52z25Ojm4Id//413n
hkZsUI9jMoVr5QY4ykKJwdAijsTH9+mIezoUSjaeox81KuZwVxJ2te4LGzRKCTRG0Pc5vZw9D8Si
nCZ62gTS77DMnLJgkDbvy5m/jDXlqJqZuRYqubN8vjUg15PD1wzveeWfslkwfUBrFHq6kegOfBG6
INj6hS6/vWa3r/3G7kL7jd51tm8r8/R18J/kgjVBejQpZFfCqQpRYAmWCGlylrawGIY6o6Gm7SBy
CRUKrhtsFbE2qgBdXad1HhFUnw68m5p7TzZRJnTvTtA3+OYubUWgTjlPAQwN5Qm4WgxTjb29gvKc
oHlRruYbyBaj1nhr0IYkZDeHTNoOTVvXdqlT0aiGs1W+dbEWSfaW3RIuS5K1qkh7iXU5ERyVVTfB
ZyKGPP0OqU/6Zqn3FggiB/S7ZCxb1c/19b4L7DeGTln4VersMvXxv05ngRXxzyWql+wel858AGvv
2u/ZBgLRSusE6bpoewmVCdnyBTJh3vcRsTS5t6jWYlsXIg7ZrK5U4zf9CmncWV3ILhac7sbbCqnn
Cd7LL1JkvdAtM3pXlHATA9b6gN1D6wMY0vrEd1RF8ZdU5KqMEW+psKRSxV8RyIUtjBEKmvPXEHp4
6c1AdHxRhOytLgP++gxfE/WHCEC03TZCzv6UC6NcFPwS99hnFGA/mCESeI+jXy9eQ2ojdac9Eygo
1AV2o75COmMmql91Ex9JpjEzvXJL4NhySyC7IVAsKgSi0ET0GXhPdiGd/yZN519HKC1BzaajI1+/
+RjAVp55EFil3330pqUG0+qXTMI5mQjuGPtIdgvQIt8CgA+oqLvV8JFDoHCgCYC15EmYsXAyDeKH
OBvF/ZSUDLBhm/+92pxccWRaF0F2bohsdrMkaDzu7gzFT+PdmbGkaCEfSiz7Pcs5PJBNUQH+8/Dn
mPhNq8ie/AKiSL6VUA7KhHLwBwolYcV/q1AWE4XSMhpx1BQ63VopwK4+EgZeI0HtB7RiZNfBkgAk
OCmC1hwbjcdkhzzfbtf+G4aGsdd/hp7GHQ15qlANJMu3pccv/1Z0d7k9k8INmT4DSgzfs3UlPhhb
TXyAqB8UcTdrMQSpbmxbAbnCkydBLoek1l2pVni2iUaeFf/Al5CBHyGmri48KOy6Vnx1d8Xx/b9E
mYMNb11Q/ZdJ3xurtv0jOkMTUuy+kq6m/h/TP+nkz+5BA4d3zv+kvsFcqGAIfduJn/fBPM1fBezm
M6TnaL4Euh5ni3BtsSG2kR+afRzFi0BtA7Syn7HTJIZNHmmTRjuIi3GS41nDUXxHDpLTOn4Nbk8u
ep2Ddosdcbvo/e2ke9G7vr45uaoH63jPZZ2fJLbC418Q0QT1eMDfHHYPLo5+RCUWfSSyyb27zMnt
TefiBkEjMUPsKAM+OrkiwEk6KwP+6YQghrQ9btCrbuenS2AKHJublnDl6uAMO/1GbrBrDJaXgZ2c
doDGYeYG62KweRnY+fk7BDYeL91ghwfHvfOrAwCdxQ7Q08vu0QmSGCwupXDHhyAmfXfVN12QjHkJ
0BEAJQRIuKTPLHTvgb5P6RcXhcCby596N5e9IyBgPH2AOLWkhI6ffsTS9nBfJmudy+uDKwjkXs+m
eTzLGOnCPXm/QrZUiC7EpmupCxruABU0oDlSH72AAHZDcD09+T/X9j+0KHiCA+YHGxZ8XMYTT2Kl
JfGmJbbiiL1xLKw4Fv48seKYe+NAw8GCA9LB+OEQTk8YTQVIlyRZBWLaB5ZkpK7bzVoRs3PNQlVW
Rla2El1K/sXVaMPGk4k42SkCn1LHCBtzLu+TK5XDk4FgQzzJ6R1WVpeX4yy4kwTYXSwMbe2ONvGz
TkzfAb5Zhi5TBusuZ7AnUwbflimDFZgy+GOY4hY3tpupy5vlJLE5AQEvZDjvrxzCx/ynsqxexgr0
VT6w696QNx/QFUHNUXcmrTB4/WQQTObkcPnrJ6NlkKNJLh3gS2x7wzkyfPHTcfwI2wnw/W+H5oRO
7EwwbQ/7yZAXT7QaHMhovZ/6RhUUAOnTCWy34vXQ6yeEUrxggrYt3aTKpQUSBSSWiol1IGtU8WT0
4Es2uVOPWBepeuGttWwyj/N77Vi1kPGPvLeWz++Xi8H088SKgAFsPFnW1sWOIY/hluN8OrGhNx76
FjL60Q14S+k+JDNwFKfvreXny8nExVr63lr+/mFsLYve2TsUxvydg3CyJHNNlWWqhlRnSHbCVIVq
6l713p7c9E7PDt5el16NSYflU4b4D1IyWttxfQFeEUMayd3R4yvI28jI2MJvbNOduJzOPm6RbFTm
yU8BRdYMmm+UWhxzIE0Vpdfn6lBR2auTEqwTjLYmPk9zP50iuHgMbpP+nGS9QzMuODLmcFIbUjUi
cvqCkWV15NLDOXiN8uxJ/ox4RdAqxcs1pbz1cwn10wfjcshjspSNvj9M5MvFnYs6EvBAkFJPlx6j
nnYzXkv+9lvA0vBYDXHDeMAd9k0HhCDWCTHozLzyGjUQEfACRwRsPrPgKRk3li0j+KNKNT0OwE72
foLYPfyoRqw7dn8xg6fhpDN+WtAaIgGCBxRKQfS/g8dMAJj1OTOrDywKZq7hfHYzKi4QdIEe8J/G
Uyzs8/RpwKslaTOtVespFHibCTN0Edg3w6tHQdhHOSkHPCGobUcLtZNf2CnIVh4zdaKBjyOax0KC
wFcDI2URxzsj8E1Baz4apJT97XVAiypjUJBhkhRyPZB0i5oisJoavP6jZv7coQ5LukJo0cvnwTFe
t8FBnCHk74FQW4jqJj+ODxGify4zOFmDalxkOH/I3BDM/S2CZc2duepONnDIGAXKjikxOVIOGFoD
RcQUKeT0tHAe6imLJiXvaXSVfLwafROP0RAYg0LURh47VcIGn4DIwU57dAc9GoCzT/vv8TynjRL5
8F+08SVt44infdiP/MPHUvcwnPaxRChb4344essUI0QUQ2Y52j9qKfkJ0FGyCebTXnHfap2fO4Jk
VWBjjuIv/BSG+FI+pFT45+neFuxaoEGOJmv6szhqJMDeTdex/ztfjtMgfUyTJWTYo9B3UxEUoroB
GIeH09XZnELiZwIsBG6L9COZRcwTCMeR3UIBIQibluMx2SSqkpYTX4jFl2PcYhzDKxeAJwIkcY4C
c5BSicXwP1qAPBFK4GCsooQQm0VLkCdCiaQvMHU5WWSjgG4GkgJJX6Idx+lg6knEjokq+krhmMAt
YIixIH0nds6EFaRRAKZy9JVQDA+Q9Tr9gqYW4cA4LUTeyETOmBygSl7CsutlMn8Zz18u0K/5y0H/
JZqFXuL6X1JPIid8JvZb+rDOfNvBlJowrMvSB1H80wXrLdDtSMcx4U8XAhiMXU4a/cF1SwFHLIni
32L/Sj/ziCwKOqjFXIz2iavIHFrs9SurNvzSqkJw+moKZdoml4FHcU7SVzNtrZBP/ggEgD3Si8f9
7G45XRZ3sLBJASYQ9Ge/eArnU16bzpxuFefxkaHyIzayUO/MUjg9jMjapJSqB3LxATl9HwO94o2x
pC2hynijaPXmG3wOdF0ysLyNFPhT1EmqLDgyHlhsCHhLoijxIRVeQsaC5yqJ2dKiqXwak1Z0YiAF
JHxRS6iLv4QnsdWWeYDgNUBArh7VvzmBJHeJknQHd1tiXougrj8HXWnIKUk8SkJvmtYx+PiRzCfL
mo1P5gVDKRteMccTCIQpTblUvE6gVRaaymj9V5LgxLbWwXLxVKhRt/clc1Dhh9H69I6bYoQRVuP8
6WYXGFVzOEnNdDkZgA/tC1ajFWO0qO55DVnpi0GKo54EA5tBvRbOMwhdLw5MQcHRurleK+4keUwn
2WLmPnJPqMN6FK0d4gSnHs5j+sayt8VfkoUkOa3Pc2ejxWCKdFJtH4YCjOo4SVKSFQZM7vl0FAh5
tl/a0uNWS0MrnvM3+uPcruf0EU4DbvJ7wnjPiVoeNEg8Gk0T1FU4ZeaG+LZm3OgBP4pI4/dSESOl
eNZhi5N4PkeWJa61jGD44zs/yRuIyGYgpi70kYnfWhIZcV3Pi8qpE6pkz63Qe0W+3NK+40RUzFMr
R2z40GaqwI9G15FXNHyOsNUNWY43E2FCyeOtPOaptPHVC2Jy7X0RiviTighuNMzT8WzxBfsbnhIY
MTMp1kRcFWxcd97i4D0ESbMB22WBlRIEwZxbCGbk/nL4IYx2Rc1vSvPHtfFtOuncXL2RvV16ImN5
kh6i/shpPhuW5hZywKBfi0FGcrAZ7Co92TRJZoc0JXzh3mMlKxI22dD7N3CvCDImoInwe5OenXn2
94nqNpRBFB8yT0rPDW4ioYZqMehrfu7YcSHIV1G8RilqB/HLQaSOYpn+/owHftkOChT7rqLOlAd2
r46h3cd0vchVl9Jwf9XYMOZTK1OPeCYQDpA787GX5okXZcBz+1XMGC+CqnqKMk7iX6FW+YyfjKYS
gZV0p4ylTG2KflRyyUge36XkdhHDyXn89pVgrgnRFtQ++uH48vygc/Em+PDT0dW7j3xbnWd6K+4d
QBZbwta6sJB9kE2q5N60TCXg+XS2ADW8fi9c4+BY1SJw0L8jKCY6z+DzK1vXN9ii/dn9M+m+qAZ+
B/8JN0YxMumyVrsWAGk14gNGdfawC3mDNBhaijQmkFInFNGpAAv/pqzceWq4e0NuuHs1oRntPR85
JBj+XcWg3qQREN8m9nCA9TmezlPKzZxtYj8IGc6riD4UhYPYgG7C3BrAIzh4xR8Wso9f/UAumcLf
3wSRxBVD862mAh7zcEhwMc0warEVLKhkoC9KdQbRvf3FHCxwVKqhLGesJPA2vZav7qMSJVAWCrci
sXUI08bSuoXnVHz5HD1/HpxNkY0dPMTzDDR0/go/HE8H6avgCH9PNpFSRRrgywg9Wj+8Pl6nj/tx
niWb0+EQvX8VtPDTRdzf/JwNFvfsAeqhdLLYRM/zTYJ1ko3wmxO0bIYvL78bZHCr2DxIo3h32Iqa
6aDdgt97O0myHe+1krDfxJer5C9HWf8xeXkef0qHaAh9t7m5GcQvTa/WztFgvk5nQdgIwp1X0far
qB1EjTAKXjTCRuO7Fy9eBH1zyZtlSkqGqPCr5s6rxp5Y8q9/DTZ36jvBi516O0A/zjsXl11gMOwQ
B0c33bPedffoevML7atXr01PX2CNnqCxspWI7/9t4+jy4rTztne7264JUL3H3TaC3DRAwo6iBArW
sQXrQfdcAo3nYxlSoW+2nCEWuUDIBIcggC/tbWBMu0U48/bdyfWNXKb48NI9hFyAlBkgQxIe+EAj
wrNBBfj7h3EP3+nD+GwqQxgtUcRYbQLHvJbBKbs9oAuCaJnqowRocw0V6b3PeHk5SB9eTpaj0drN
/TL4PzFSJmHQaLzC/wXh3k4DATfoEAnr2/Cz3kCSgKb14ST9Z7Dxb0gnLvuIE7X6l5oozF+g2Zgg
troDwBx6QuoLHY4zSuk1HXKUTZaPvTx+SD1B5ym+C9pNBJOC3nKRjayIAWr4uRcns8yjTQR6NI3h
hkcMjkym058xOE4qjJRKQFHCUmWKxh/7jf4si19xPt66hj0FHOFWYAEE/wY7zLM56v5HUn0dPVIq
ggRM4sMaUtlrI7R8yocIGOIZupeXN7WXaMp5CdezEKGCX/+28dfTWvBvfzU19t82ZvEiR/27CJ5s
XdfRP4lcN1SLxANHRqyhApsdwFsw4uD6vPfjcbdgRn8JZvDWPW03/8LYcy+x517FY2QH4p3AEqlK
kS3sRe0VL2bnUTZJRstBCkCbGLpgExbiV2p9mBFbVz9eXrx/FYw/beZfxkg4P+WbIErSg3GWJ5iC
zQStMidQDseaICS94w5pIyMwYN1EnwAu/u3lbBQvkCU3hjZKKHDvjz8NsnmwOaN9iwFOzq9u3vdO
O2cnUjUYHeI9F4pRli/Qb45YKFeDpsu1ocrwju46WkHGywWaaJDVHo9GX4IEra8X6SAYLMfjLwF2
rwT3KQyXAJTZFrIq1pHtRyhUuaZXFBjI0ToeyNkIkoHAsqdPg7J+Bn4+R03e0otzPvviYfAmhNCX
5WjwMCV9AuVV8TF2gUB07kUqE22sRDdxlUgUPmG3gs6IFXBifMNZ/jmm+OjQKR0eOHQCBscraaAU
30G+UX9szoeyOtKFwSIyCvdWm7NjOg3gF6CszFO3AvYHzOCtdjGD0+WCRltAnt/cZ3mAiJtDNnT0
dThPU7SCHS4+x/N0P/gyXaL1JEQqDZAKmGf95SINMtjvH7ycztmaIxt+gYdIl6OBDImVIalyDgf1
4cfbi3fBWZrn6N3bdAKXuwRXy/4oS8g6JkvSCURj58EMnsLZiqD/BZc8BWKuKTHBKWwt4Tsf94M0
Q+9J/XCrMngAoq2Q1Uhx1gPwncQLaMWcLm1rAWxQoAGJqKElt6zMKNo8wHctINT30xlq3j1Cihr8
ORuNgj6+S3K4HNUxDgQd/Ny5+fHy3U1wcPE++Pmg2z24uHm/j6AX95C/AIIVMK5sPBtlCPVn2LyY
IFU4HWIU5yfdox9RmYPDzlnn5j204rRzc3FyfR2coiXLQXB10L3pHL07O+gGV++6V5fXJ1sBEqGU
sZsw1sRyzm6+4h+kizhDIsGZ8H4Kx5DwnaH3yOZCXZ+k2QMiMw6S6exLxV7F7hFoOSpUMHcfVsho
aV0PPs+zBdzAqfc3xlP0eT3oTJKterAdIrB48glph+B6gQogJKfZEFVwOppO0ar9cIqsPwR+fhAE
jSgMG5thE42W4N31AWvjS3oaZALHQQ6OSGznzeXl2XXvR/QCPYVIA+2F+Oqq0zs/OPqxc3HS+7lz
fPNjAGYOe310eX6FNAvSJidXJxfHJxc3vXedixukQ+TIQ/jHWYoUEmAXX2YpEK3jCZZtyGjDAIrn
ufScF1w2I+ExuLty6Ymc3G65a3qFxGSOhj3O3Mha0etl03E6Lh4gpQ+aPL5LxaaStROw8RDNGpi3
2NgFr7PCeNpf/4v9HqalhHlukID+iJlhW5wZvu2Ha5DTdxdHN53Li1fY64ea0lv0e8l9mnzKl2MO
hZTYwfnJzUn3GsEdLodDpEn4ZzO4mmKHN6gGmkkRwhsRQ9ADpHIxunSAMUmfs3Ryh5SBgIk+wXoL
qSAJG6eme3LzrksoDoIjSmuwsdytcZDjk+ujbueKtOwoHiVLmEbyIMnm8HUesCZCVVIt9hnmf8d0
WzLP/jmB/t82gX7TD9XuAaoVdniH8+kYXOEvB/MMZI6soRZY279c9MFdk28lfBInK43gB6QtYH5C
tu0b4fG65umBbaWiVLGwEkv9gKuME1Ipfvfd5nJX02VIPWCBBd1VJ28niNcPaW9Jt+iR4iFbX2sI
NMdXy4IjH349R/Md3CBCNN8LCo3d/mt0o4m+w/lt8VbF2hrBAXop2Mhx7qrnFOzFC3wb+f+vvW9t
TyNHGv08+RVK9pkMOBiD77En2SU2djjj2zE4yZy8efrB0Ni9AZrtBsfenexvP1WlS0tqddPYzuzO
vGFnHeiWSlJJKlWV6vIDXRL8IK2dKF7X13seWXF3mC3G0MtvcERtb6SEF+IaArqZouVBD+fImaLv
3+nud7r756C7htDyQbDI7caRLrJYj9UG6kAf4RmL7+KpP2JE12gbhMNh+IWvxK5iqjEo3iWgBxAm
HxEUTqHIpjIKJtMwQjsYBM2v4md4f0w4jn29kGgl5qvMh69V1Sm+s/neluV4Tyd+j2929n9mwzug
KbWawIKejhx2uYeD6l4SeUSyu+2RiSYQYujQx/VPuz/g2cLXBSz5Z+12x3tGgKj42iqV/6e/+wMV
hG+KVRR4GgN6kNFTdagJaDnyb7xRMA6jXdeL7t+TF/VNeEOJ070erIwpdeov2BA+DAA4tKLwPwGx
ChFiNCgPHb2tCFAdwRKvf9z6ZPehm929brqD8tVldq1LsxYMIPRHaLr5nE2isA9zAj92VEItNATC
BFvIcotkh7B3kC7ht5j5t3DAwsyurQr04o6rmmPmDXxcWzVGl7RGb7AnjfZeqyVfMOiTCUfiafUj
2dFxlw3yeEgWEM9r7yETQWsJ9xCy/B4I4ue/emenIIzj8V3R3x03j0/Pf0X7buPx2VGjAxTv2Dto
NkCuaEKBVaNA5xyjJpt1OnvwbN141jjz3jd+aV6cwZsN2W8phtv7ALecGAQPlqnvCKw0b+WgepBN
ABLgsWc8jF0PryYugKsf65uE48x+eTyFmaRZimDBYJsfQB48ge+I69rcwXYn3pfuZ382yR3qyO9d
d8dBPOI7vEYJgG9hmY67wsI6mk2m7gVT/7hpoufG7wFN45CSuvwp7mGKTMpqt0C9a7fAcyHUr1nd
BniEipWVDx8+SBo1CuHswlAOVL477eIhg3d0xOFUr/9KzHKHqCzyC1QEWhYJaITgicck0lF/hFKq
Sm4n0GiAFyYwAPS0zS7DEEcPh8w/2U040y0dTZ0TFvSi/o2nkspnvI+SNFe83xHvNz8nsJ/NgxY5
VL9rnXcucCHs758Dz+AdN85E/1GGTgwPYWnD0vEowy7qaHYTaR9aoIS7OzDNFYYl4Gudz8KuqWUy
zsr7q3VcV8luhjld8htwz/WXad3/H5P5/a7j/84qP0BFwfZgIFFwdT2l7LvAP26xVtz9PGO/dkfd
ayR8P9/JbzDVN12SHWH87O+T12m9Iv+8a8CwsVibOOkYNuQEts4v1V8Uci29BDooR1NbK3GF3rE3
sEJNfYRQV1gPUZyV9hEZL5S9hPHeTXawzJNlyfs+WVZhg8ReKclDQlQcoenlEhr/KCNeoV3ArKCi
Drxefn3bu6ZgGe+a5/KFMIBFEp1YCmtt0nUwMpZBbtMVM5LMkqyQ5aq139yDndP03v56Bhutofwq
U8+9N6cXJ3vNkgQo3R9KSRMVPCq0ChcHBzA+Xg/+6bw17dXRCAw4kAgtHrxLWNs9Hybb1zCkIDNh
GqoZoZ6RX1zp2R5tTrQ+xYhs+qmOFgOENaaacfnYpZNzq+LVcEIlXzGPj+tdq316rkyYajeTJGBU
UknGVuIM2/7pce3dmTV9zjrkr5FCX6PtNc4PFdptj6h+6OESUZA07D1XDzXLWRfOgUa4kG4b1mpp
a3ENqZUZxJ6IZueFwC0FowL7gg5c/IhzBv4LxyDjUPI7OPDEZkWBtwSnVKxKP3uqt4uTAO9/+y2v
N+VnVVW9HXLS2w/9ePwTHN2DAXCkRG8x8MBwqoquuI2KzU0pu+Ac8GwsAhAmfCMxOVyfEMGaHS9j
bcmQkpEHnCBZTaNDwpLWuMDRqDspQg14qp8JBaDPCIyPATA9kutf4U6GleudNQ6bXrv1/5q4QOTm
oY5oNERfj9AFzOkF4/MBskdcvra46BtP9sz9XZLtmPFRnaqws/PTjnfebJC7Dn5/f97qNOeD4KNm
Kwks250k7QzPR0NOIEtlLWc2IqqML39jJQH3OQaXkZjDtDnlvK2DENOTOBvnTyM5pizdPMbsjXhb
GUO7EUP6tz2miok992YgnynyLUXrtbxlKRVKphvxyorEWH/5Nb7ifqZyfpLjA88w6a8sUm4Lp2Lh
USxeaH7Bt+SMIpdiMkM9LTe48OQtLbxWRdrwlANxz46tKIZnZjQG4Xgc4iCbbWB2tdLpQw6jAJJz
hOFxnE+lxBqLoVDWGuMzQoL7ZfQ5GI0yB2sJrxMPdkGKzHRv4Ry2WI6e5jLKl3MwuunqxxG64xjB
HURfoe/8goktJV+dBbuffY/fPYny2ISzqEIOid8UaIctXU7sEBVvLlpH+x4P2C99tO1eldlrB7JK
B+89EFqOmm2vebIPWxFkde+4dQK7KXmDprb8lUYz0I2SzD9px9FRoZBkOFQ60ec6HmB6oU2NtUia
1RarE54jrgTN5DKtWY2bugpBbgGJzuEcaY/m4D0TF4bJYPSJTWF4qZw9qjQmtSFpUB8wEPwH1jPs
nwQg+cItOMW7jjUFBc26QAUywMr6qg/Lr9VXSfgX65ETICbEnIhIZ3bv8npg1XN1I119PBt5o77u
TY6fzJVDRq+ptSM2eSmTCmgUNXshcRurzJ3x4BUkGlS9w2YRcO7GT6iTNl4iUxkD4QRZ7zyWfmDX
qazOkmND/JiABivJhGadGhaT4aA0FXloqE1C2yN7rf+s5E+NEL8w2hcFNBioDYVGAFfo6QjyQHop
GtPR4+7sJn9OPAWqxNGHGqBdajx73t6szd1u7hKO/eUomN5J8BdmciefwKc5XzdrKharVd1NaxeA
mcydvd0W7Ji14heofZmORUis5R/dhzRDp1VY6f472dv/MXXuT74bnHzXoucanKD8TV8uOi2n6Umq
QHLpqMlmu4kCmhXXP+8yoS5ysgkLaot2k+hf99BZcBDM0hk+VJu9m9ZB3lP3kOraAupMRy+y1YGi
wn+LcK55IiBXxE07hj7xd3wU4mD+gV/MlFCLIWv0QqAz/tSngoKjwrNU8mGlf6lKu7Xdr2VhuLpP
tYnwGe7lnLXlpgbcw2LajaY89Q6WyEWoXk1L2ZNbTy7OyVRk45QDAznguHnMvW7RLKFGn4ujVAnU
qkEJPAhlCZU3xfPQyY87ZXg08BMfA9Z1xcUEv3ZC6x6kUCTTCN/O3jUyml+ugZqjsge+f4ax+UMV
vQ3xZFl6/It9ZfEkGOP1B1mMyHQf6Rt8i+Q8iK3gNhY53AQv8C3c7rf/JEzE94v77yzHH/jinvM7
niQubz3Nt01/KA5J4VeL2Jcnhq2gV9HI1BE9T/GuU/wphou+8b34Gn/mVFJnL++Gqr2k/57kALAS
JujVUAynRHKeECttffNkdcRF3lRiZ+6EiAa2rhdLUFFZZHJ+rJdAJK1MdlNL6qviWbTKOhuXV7eS
ulGRE+ZGlTWLKdW7hjcDiVngDHxgFMqENdVGY7Kli+ICQ7ODLF4MH0VXyNVkMHY1luZW79lcVoMg
PBjPjVkfjB/ebF7TOgeiEYQ/iZdqViibXH7IKv0tzBrXV/8k3NF3Fct3fsdWsUhbwXjahz5Zvohu
x8aftdgsr00o6BgH/7fK41NhvrLCZZjU6yBcmUThNOxRiBATaiGTxaK2h+mwn6TCuQp66DyAMTx/
+vBThf3k458x/snMfWd+fgqwcBf/bOKf9YLVlrHwAP98+alCLh7zK2mhQ3cNOfrotLFPUva2S8om
CbuEfqP12uq6+KesYUWcpog3mI1LH9UoXFwuYIAmwlsuv+Y1+B0Nv3vFhtMWG8vN1sm7xpF2zQAc
C6W208FcDsPLipqkJES0fFIuz4Nsm3I4BksJMxYZrDFQ/6p6Q/oVfk+Lk7CbUYw73sqZeiGRoxeH
zoziKnkYCAMETYWSUZBcXAzAKTTpNaPuCEj6Z8KttM9AnuIkZOIVu/On2v2oZrhDTkoYI/dmtLxW
rfFISHCi+KPZs8IIx+N6IXzzAL196ICTlU8ybWERFZrZI9srbwqyxzQqkZbKPXHKkgsW4OQOE4BM
zaJ8FcqlrF9otu/GvesoHONq73V7175ugmElcJezjXnRX7E1PTwrBrW6CdHfBL2vnw161YD9WHvG
doBFi55Rj2BWgzLmRRd5pfLitLLlR/qIg0KbQmKx+aLiclkh41QmOXNyrwzglKS6ClW0+qbATfZD
UtThTXCNEIikOgSkcPtjCq/IQtTyfAmgDN0nUz/Yl3D801RhlF8042mKL+21rKlDgbvWrnjprWhS
vKrrr2QXxLvVjCUvVKhuWWEwiSMPyHJ3NpzyoNi7Fo55Zoqi+laFZm5xR9tUqDdF5C221Jve4r6A
4mrV7J8en523TjoHHpowNfeVUanjwh54tegOOBcUm1fUXkH7HQRMZ5E0HsAHmu0V/lx+bWc44E+J
hwgm0ojQJmi7mv6XxuH9QM5vB60Px03VDw1UN6oibrWMEgaq7czNWs1eVA2oYv3iiP38M9tcS3eU
QyaZC0PbN/bYb8mvNyfpCgC034vco4Z3kyna2NQ3sL3VzL0sVoW5DtAnT/8uBvsliUFenU+tBatR
FXEjJP+Fxq6YdPTUQ4vgUw+4bxI0ZXFutHoNrCaU5Pawb1sHHaNMikZg5Gn7mSyc7EVK32DcU6gy
iVYKC1m3ErKUlgxMPufanW9GEM1p4VIoMiviWzIdmK0JJwLoB5+EwRc1AcRrJYeWxXoleI9iP9KK
mUyLLKZadh61CiN6eH6PlF0qp6MSp62A/QKgKkYL7zoMP8el5461KM9Uu5qA/Vxhqbz75zENobEb
8YXztRda0W+hulitpyOafNddfNdd/Ll0F6Y+oojewB/T8ZhWJ2TqGfzhwPFwEFhBnZxqlNkY1mA/
pURJO2f+/M9U5WcyTLZwwU+FkAIKshLAIviHQ6uC78jUVepUEhbzybJxfQQiUl8m70KWPuXokbpB
Ej5LccRP83l6C5MT7gNrAgx0hZjdMeffY8Np5aT6psqubrpa+BRi8rtDAvNEeUG4kyyjtCXhpjNT
Cl9Jx8iVnwqOUPQS5a5CahmFDKgBHQG2LmGPDDWFxuelfSVtBlAqcN6evgHp8fCER/WQn9rt2vra
5vrW+suNtfXV9cH6tnwDSHwGdaDK5vqzBMwh+i0gqA4QIAWmVFq/OPr557VaeblUp6+rtXJZgFk/
RIel9WMHENQoJUDqomIKMQCkfuyIqZFxYSci6NiiPk63DLGRfqGCmH0lVB02T5rnrT3vbbOx3zzf
1fiL1snBKRbB0wEp1iCIQLimeBQyoEXI8c0w+DhnGqZkMALLhNdJsiRidG0ibpKo6vUctiW86+ke
MmGx4tRv8I8YoUCoTMU9VDEmr8PL7MqYa2sSxrtm5UkYxMGUdz63+uVsQBq9XaouQxVBFRFFTqId
kbubnmn3RCOv7xyvuLP9ig3gpaaI2yJhUvgcDZOdX8+a1PIrqT9VTzvN8+PWSePIfn7cPLYfnTXQ
RbgN89KRwXPa3n6j03AV3GvsvYWtfXF83Dj/1VUANXaNTue89Sa7OnY5+y05ZGYV2W+iPX/WW5CQ
m/sUzMT59rz5f0mbmPnyvNFpnbZdr982jrI7ddY8P/COT0+yC5yf7hn4dRbq7GWj5rx52GrDpGYX
aGdX7mBOiayX747zphPe5lRUbqH2+5NzDzOWpR6/O2+k1t9x44Nc8rjQxZrXtEL4hswSSGpjSyJG
Y8WyURQ7FcUqXW3XR2eHIQhsl9xRlcCJNIVWOdxxqXK21SMKdVgwoy0UwuP5UMZJBkALwPgGGJcC
AKiYNKvVYPBUOFg/zcxknOa5DYnH3HM6A0A2hmxohJ5iYDJHSKK9e4A6syZVhdp8uznBPIwZ7J+z
35ZNrD9abNiZYzbvAJgah+L7xG9g/EakYyrp3InuxaIKOpy30n7BSmEN1YpFuSBPGQ2HgDW1lvQ+
VRLscHzow00lYkT5vKTNXXaPqe3FuqstIc73qi4/pCMItUg/sqBqLHDqCunJskkGl2QM3AwqqJaP
5E7Y0uQ6kGyHgw9bElEEh7s6ooR2WwIpqyu2UhpEmb1O2tcxCJyToNnTMGQxLtcC84TdRWdM2Tbl
tB0oThFfL7/mzGNV8c4Y+EQXGFyFhXLY4KBc5QSH+YrZSDAKZ5bKRZUBQvComsacP5fI5DGLPcEd
8hJytiSGTPhL5ZKKcmz3S7YtISy/noe9pKSNOslmpgq6sJJGgVvyE/IKa/RRcTP2v5BsIfQs+PUI
cyMppQ/tXH4PDfIa567xJI38OLaZdSxOY+CfZfFLiDBYkse6h+oy0j3JRqo4/ZpXnE8adUbFNuVR
A5/IeKrmtob62mlPI+A6AuydVDlgff5UtXGPXQ7ovMY73SVUne1m7zXVEYMcGEv+hTbY19aStff/
GPb9BE9VilcDU6qkrlwasLLSnUzQeECsAv6UjyFz5Sfr4YW5R5eLaTMyV6zcObz9+ftGlhO7RhPh
5Ru1TRJMFqAa4rpeBF4R2MirVxGLJ1k4yVXnChMoVhRF4RmXyOJYfmE2IwEVIDNUah6JoUKLkBcc
Yf/vs3iqVBRCd+Cg4i/yIOojm3dvSVv7yp96hCao4OItTXkkYy+nt6XOBCabMnUSPrWw7OT7oFd6
L3da414YRRjJSgEqws2IxzouXQjJ5bTvJ4U8RPSYz3uvrLTwilAeOiZPTcyY6q/ewzQTKfFt80EG
cilmgh9FniP6CeU31mRU2a4hjmY2i0epCGiHtGIAm8hHj/WH9iaRdhUe6FF+T4R24HG7IoV8JRfl
9+GscfS47Sdye7KGkyU1pzdU8HH6YwgRosyO8Yo2b2pv5kjVLE+s1m8vJOrnXV5IcrObPFK3Frp4
K5hfi44m8qUt5Yp4Hm48t8bot0QCGtHx4tKiAv3akGedrZzAxIzD2dW1HkBysSYlKpDyq6ZfMKVs
o7T2r19rtyz2aTTnjssSeYtd8tDHvEUx+lBJLrTsKxw4v0u3FXZXZqVS6RZ3QumuXGZ/Zfhjh36Y
a/F+yji1EpX2HOcAfuiswBClgul1d8zWDlm3R6kB0Lzr3WGDnTeOoS6lXmBM1K1KC9eattb0ZmE0
UBfthggp2nWXBMAXsV5HgPKHsZ9VHHFmNPNCNUOqlNrtHncYrpmxUKU4oRBmqP7Zc96KMlvjP8uc
OrnXZsawX+tdsLj99UP2b/jzIvJx3aWHKFF6K5yea7VdqLZ+WAR3JiJAyEq6oW2ux0NFxlbVHrsM
fvkaLqgM5kemHeo3u/tSu86eCz2aGAGHU3ZR97RmWVHwHM3yAl0izT57nlRWvdLg2V3j7ghm3kN4
Ngiu6Di/BOQh7R/4xIjGFDz/4+r6p8TATLkErK3Kb6vr8Ke+/bKi+QuI/6w6jv8sO7E5HSTDZy+e
jUbd6E46UvBG1jJa2HiEZnErdKdo3vNxW2tydb3+aGPCC96P9Y3VAiPK+I9X2qyw9Qr+3YKJ2YDB
8y7yv5vrsnh9lf7P66y7ps74T4EkUGpWM6C6AVprAeBtE0jZUQFdobS+mdQiwFsZgJP/VgVMXonD
BsgvdbDrSU83FMDVjXXeCzGx2J/sP1rPZQOim/mtZM8a7ideXIGtrxN+1SKov1xVMFdrAuZ9Vhra
3/LltlqrPXS5rW+oudqmb1ubvIvJoliUIuTV21atravW1nFxbs9H8EL/ra1qq1wNbrvOm9tazat8
jxY5MZWLSOwiHB8u3dV1PtAC+HFsCbmy8/+IJSCW2OI9uMeYqW1Cr77LEcvrRQftbn6xTdH3L2dX
gvzq50nWFLufL9bmILj1+3RCG+eJe3ALgo78f5A/lwG5XoNpXK3jXG7j3K49sIEILZFikzNA4qfo
39aWJOg17an1fd1eNlv37NN1dyhI2qaTV9H/W39kUvG7VVoMJRM/GnijcCxW9pq+tOmIxiNmWxK2
ZHUjSyN3Zs04mb/JUFPtra4l7SaE6ZHbrBltftvJ/D1bW3CJRGHPYPc/1mvrD2UI9GebnG3Ef2wO
SLwqgIZ6xiEgqPSamwXHlZSx0ec0t5VXazMLJ2sZx8Ujzta0J6QEtzxmj8P9/fH6o/xs0nRXrnai
MatbHKkJYjMwnMwp7f3aNlaGP6tr8o+YWKTgmcyMamJNQdO5aAFCULX0bArgq8nhRD8yxICkdEZ/
FkRp7DsYkZeFuaB7zOIUnfeozfX5nEjef79PvcUGdzNyqwrqtTo//Op8Gjmvsk7fN17yVw9umU+k
QVBzpQbnHk7YcjeBIU59G0fhIoNZuK1XCoAUXc4ir2mQtFnrnOoK4TCjs4ssCAtwMZgLT5ZKkGIu
lDkYznjnTmKqqcq51a1unpAYnIgHOWbql91p79o02uUD1F4m3z9+eiVa/hdbwAYdP8/naQa1skL1
OK+GUPN+rWR0yWXtbnfF0AHmdsEoOa/plB293W6iBMxtNClWbLCatbd7pFZctaxhUgKbQi3a9v7u
ZpWaqEDbquy8DqS8Cey2E2k8t9mk2LwWUx4KdouJLJ7bYlJsbouW10OqQSmh57cnSxVqzvCjcDbI
Jfb5TfJy8xq1vTPsJpVAntugKjWvOZe/h92kIfDmNmuUnNt0hidJqnlbmMrvgl16bjcsX5VU81I6
yG9WlprXnMv7xW7SEABymzVKzm26nTtQySPnNxgXG6btp2M3prjj3NZUqXnNpTx/7PYShjW3waRY
gRZzhie41HltFRya7ZvkaC3JCDinySRhXdKuwdKpO1a3q5GRvywQPJXttytaVqxSecV+4k3Lbqfe
1L1swm8Fn6rciNh4ZLFL+scol1iVmYULXoivrGD2cTYKY25PGAyCXhd9lIIpWkVzq6cBhn7CLO1R
MJmG0Q5Vq+9QlOH+LqvtANboe2JQ8q5x1ALuUFw7ewf7aEhS4n640mXhtry0zRMOst/YrRZyvtX2
qL5VWUbGL9+iXUsaipprFUL/yTK/2iY7QIfVlBZsb4mXnHSn11rWRQlo0Ncz8eCPcOKPS0mdCjv1
9s6B4v926p3vvz8Hrn5zfd00/MCKMFE5CW5PCN0IWliZYSznH+MqO8SgACIiBCajF9EenqUWyDMx
ZfFsMgmj6dP/GT+TRm40tN0fkirzHL3TczjoO0wXAMtkxTSIwpGwYJiG3uHB+/l2amRWRjUGWjgX
w3taM7Xi3SCbEtu2iugC92PGjtGKRdtnaXtHUwz77mMCg6S22ldrhrBOSXapwp4rQOU5U7fXHcuc
jSfJpkFK+DRr9phj+lKzV9gEDnr36lUy8CocMWSMk+7yPg+uJZcbdbTHk5HFsx5mLxjMhhlt15xN
Q+W+hjUicAmmy5SiKZm8bCQeoXuWoDmw/qvs6gHrvhDmxIui9niL2eLJQRcyxZNeNXvXfu+zjAAg
nWS+XPuRz8FxBxcRTJoJsmv5rDDMkYJvPAEgy5pb5GxRW0/sIT6VcffG56axSxMt517qZRn/QcKi
rYiJ4Uwgp59T9XbrkJVTcyOnBk3u8oxDxTxL4FWx3bA/gmg+nbNwdRcmIFMU0W/9s4jGRwk5+iEa
HIrIsGzUnVTYF1/azNY3P3N7WQKgz1J33MfCFKSBwt+Qbe00hGXcxRg8PhraDtkmNMZHQVNJYDCw
0aWPZsPV1Gzq9BXNO2F5UvX70lcMAT4ZjDH4Hv5D/hZG3lR+IE5HE4xOab7Kos0SverEpPiWqsvr
nz1CmVWSesqjYrlg8K6jTOtZyfBy6TktQiMAC7Ar6Xnhr3RTXo1Gaca8aUterKdhrqQhtCw8fSVz
It9gAkJ9y6uNgrjFDaLgzT1ilPuvZr48VnvAXPy9YRj7ijIXoogrSwIzYnfYzfXvxt1R0Bve4cKm
XZesZVURdwK907z8yMOOV5aw4KTWSGQ1abiTAo2t4UlFO3GEvkJ41GowVV0JW7RMQVTsVO8S2x/J
nimTTAvcJDuhxLdG2Zn6PDkmXJJNgU9G0nO9txZHKVeP7GEh/kRDKm5QnGVz1ZDns2z04ctJnWja
+XXTRY9wldUVx/LUcWgBQsXQyo6xZfZT5D0XVbX5eOBgMolaKftwlP1ffk3HJAeU20FFszh0uZBh
A8DRw18qmpnRox8Bn/VNivZ27P3C5OAy+5/xYlk0pMvDLHiF4vDPRhAr/TxXqzXAvVXKAG3sM3Tc
S6j13O1mcWWPsccWgiFHWMkn6f/Fm3IFGI5hb4ZZpfSWKaw3rTc/Fsdj6ghOxHC5fGHy+DJJFq/w
fyVBQNiyly1QhoQgF5hrjPZeyTilVdvAP/qfNWmkVmHtZvMXr93sGNNEwQEfQ2pp40kFuzMRXJwc
aHoa0jPHn1sCGp2EacnMrdDR884QGSrKLZaZFU9VpErCf9yMmVKKaEjlVVF0gkWNVbVTsQ7yNKkG
EbP1vG2h4nXgzqDQukh6OOAFJOKnWLV6fTNyiBtJv6WDLWkROaJkj9+SlhKXgFSBKAcKfb54Y2mt
lSqpt2/qenjqv2AaAFX8p9/PlWZMZ6RMmUB2vgSzVU46+4NxsKAYfXXN21FLd9S9u+TNEpfVx7Dl
El+YhM6PIuQ1Z5gGW8GC2h/8MfSc4pvCf/+YYdDNYXgVYLTcS7/XRQGr36UI4cAHci4gHDMe3pl9
odlW8CheDCY4ZKftn2Lm3/q9GZVD/VWVnfPu6F3h+gHeTHesAPm3PX8i499hF4kr5aDh5wUX9YIp
ReaPwruqe0NJpSSf1f3WuZwA9mzlphth7FzMLLJCKFx5Zlc4aB3hBWrzoPVBaHe8Z/Y+naOk5BkG
ULnWHVkJ0xyqSjnjuqSUKAA/njU6bzGgV8L3wpDMldwlSmMoN8+9019+e49/PsCfMp5uy7CDbS03
oxzzuL2bJ6fNk46+7rWi+jZo0kSisPsTytyCRQwiVHtaqksTgL31xfY3ujP6DJCMgdS2NjZU9+d2
7mJMCbJgiQv9GO8eD/UPoP3eFEWNB3T16yNgniMdcN7Y22u2dx2kJmTn7z+wCYaPiClOMYxo8aHk
E1vYQ0NDJU7hdfjD1FaAdxqKRCm5xLFinb02vdM4xHmqc9JlYlFSoIUhWcPMPY1FH3pK9ctRn+71
bmZZ1Xe1lbQz0tjf1y70EgaTGgaXhb7E6XEDoYgXOLVqhSZyQaA2z6lIJ7NoJ55QyKm1GYVAS6vw
tcsfdB0lUZxqsJLuuptbqXmyL6qYdQxv1HIKhBFxPgk5R0mavVG/hBmTuUrBwyswVPKMnGkqHSFE
bcdNOIQSij3qq1AqsLi8vdOTd0AyW6cn3Lbo9PzX3aTgpKvfQNGT67tY8uR6vFJ8R5kqLJUZPlcZ
K5GPxxNxmVclrGAnUqoPrMWNkzDaOu8p75z3/k3qLmiIc2EO+ckyMJIl89nwOrYxE12n3WtLUI79
TK/+inV28Gv6/ik1Z0l2yXuFC3TPp3Bw5mFLVjBYP7u8m2p5YooAQX1r7Ik8MyLXBCteHaRNs27x
qka608H4njXV+jGVyekEq0t6Ncm+ujZSSrKIYM/F4qmSJVXqUEoekaN5KyzGJ6EaltwjXADUAzUK
1tToR4Ix9EKxIVHNjbVUNbrVKHIAiqw5em5WFJ3nIkrPySMaWWIfoaZBhDGUQIMCESRlsqk0FaeY
ARV2fKwBWTt8owHATDDUPXpbek2vK8x8/CL5rSV7g9rtzul5UytZYfYTqKs/Mqu/uTg4QHunUwOE
6ymAsR87QZ25YZ1lADvLgGatJzPae0WVy/yUcgGUDaVL0iqd69jBV+uHb+Bckec8DzAqu65O/1ds
3ZhK+FVh1WpVPVqRu79PZ5VNO5bKz7VuLr+GH/hiV/Ex5iE+4nogPIr0VVfRyboKHjfqv3hhSERa
IWBLjVgiFkuWbjV7kedRCOxosvCNblr8jKH25h3XNrWzS9Yyy90uJkoyQd5rLxWE7dxoGbhbYPst
1vrZIs0X27EFO1BoO9ufuXs4o14hal+k12rTu/e/A4y90cwD4bV2DszfdOvi5uMwZ+dgKoy6LDdn
G3GuBOM4I8u8KDXif3lalZIA9fMrYwZKcxFvh8bkGncQj1GEwOx2Wq0yrRrsQVmZKAKvlRA4va9i
MPhAxPIRXVxiWtWcmoQCUXWBGjJlkiFT7Dfbe+etMyAU3rvmeRuEoeRKgV8DGPxJ4eXqyENJC0ZP
2MatAmzTC3N9acUfUbbQs8bdnzl/VLZe7xIw6tpPNSFm5rvHvxF/KF9tYVXnq42uF+artVoLMNRa
LeJB5BbRnquNqT0DsTvqXVfdtOCVe/oKQeHpQa0n5lWb0eXUgZURDLo15km4BrNxj6fU+uJzzbxt
QUJqeIoIf7Z6vHK8eoap8IY88PC7Toug8SxYjB1EdM/axTtXHhlWpkXTbk0wlRrmvQmuZiEFrcfM
N0PRHIG79K8wQQ6lCqvRkaR3hpK2sgG/ZED8dsmyJIjYZIibmyuZ0OaJgFFacJ7NaoXyxPX0PFja
FdgknNAVq4e6GkS3f9vtTUtlvHwdinDU1Oo0GKEmAA1q/Ckj1ZsPlIX9hNlax1MvjPp+9BO+x/x/
PiXIuekOZ36F4zyICRbg4MYfB/gWiiq0G9iR4yZUJNBwVboszzjZo9mYb27mTrRgblh+m0HpYu0K
9NAKFOiwVZMqgyz1DF/dWhC/lBJF20Scp3fY/Djiv2WBM3QyzkLu3VaAILub5DYmIkSfZrxUMS9m
BeOBN01RzwkpcD5Nesjt44VpC2qF9aEalz+Y50r70BLWSGQyjeK9auIrM9D3UXOmxc/KCpZdjsMI
rV0xleFd8vJfmla6dYpubWcHJ5WkFyYbLj/GbH+tuMEJWcUAlxJpioMDASDVQaesYoNjmfDObIBu
4cPZPWklud/cO2rAmPZPj/c6R7vcDJnmEw7JUrIfgf2urwpe+bjMfvuN6S+f6+wreWI4D1NuBT8I
ohGl0KSqSLtUPOuPPw77n/76rKITgiK3FpopprC+VHtc8bCJIabOByQ1F0u8wmnoXLWaUIvJROIr
7EwcCOqBrScrJ/cdiEwMdVpOCufoEgzxqFQ/fGPXJQULv38Qj1wfgRrd2QVtvsxM5Ewgnf1MMVBN
9Yhxu1KxbnPKFoQXL5x2Yy9eIBVIaITWB/2iJ92dkhaT1RWSVUeS2dMHd6xUUkJnCjZLdzRH1MXL
zyxIC/dSsGw9lXY5hy9JuHW5f4wICwU/zy1rVVpQsNegD09fZQR+dmwxg4fjrOE0EGyhM9J26Iy1
Dev8vZ9A7fb7ATKnABknAsGSjbODCQROPVQw0M5YEQsgWtjVhKcCPnV/JvLMwktpoCx8URSQcEhm
84KBkoIl2h5J0KVyVVtYmuehukAV3oWuaSdry0TZkmNguehyUK0vthJ4dItHWg8ay37vxZDhz2kw
IGW24nxOvSfkZ+HeLB58quo70GYTobxkvtLCmYKbqgWn6yckEI6qunQo32cC+pQpAtolNVX4PahI
8evKb7t6Wqdcu0OmRsoDJIxkEP/AdVGWv5hgiL3psDqrUmp5kpOqg2H3SveGcZW5nMwpMOrewtRA
IZfidHFlaTKe3MYKnUdmr3t0N/OheSL4Ry+BaxbkCwbJE+UvBiYM/tVGwtcUlOSL5zn/oeclTk2F
IqrkMnhlspYG5CJufVwczV+eJec91rLOrFo+fvnwdO7aINVz1vTQMWA4VUKXeWyhFZyaRjiROCzt
8v5hM5mZ8cFh6RuOFx+JPtUuIxA5z7oRRxFiZBj6L07LbO1shtJ1Dma4qoxXZSnlYxZi3Ggx9dcL
GE0o2mEsjqquYx2g1up3xEtKgb/AgnmIzbfEbGGLb1NfI0k/+bkSnEzveaclN3PagLrbwI/bPURh
gjRbnP67JhjOB8qR4AV9wXcoyvsWuOblcDAg4108UePY73Nv1znU2EpFmtqaZvJRYaE2n4S4s4zO
lQ/+6UchYMnvRuSdK7Y5FwIek28sZr2Zs3/SDCZWrTgZTx0DAvU0RP0E1LDvBGFFFJnDW7tcd+xM
R2FuriN534ZYobmcp3EO+hVTRalXBm4EeLEl/Juok2kp0/r0UHzzb6dedwycAcMHU/5rN7PolC1h
IVgIz7XyValb1VTbGU7Tlppb7SZZB/qPoRQ8+s2nB/u//JrXoeAO3AngeVpHhtMsABXSZmFLKUaC
6v8YKyWctGkutgg0nuaVoSI0ciOxepk95w+OG+1fdvVT3Lxv4MsTp9m0IC1zrCR55PIYOJ1Bs4mI
4YRASwnXEToicMScthcRL3ELUGuGIxxeAurrRb8F1B4rxSQ+WH4d+VdxNSBZ4XZbZM8Z0OeydnGU
LtqNqoNJHPFFRFQWf3p9f9CdDaclB/BeVA2mAdaor6N9yGq6CAfYagC0s/a519hjvyW/3pw4YfZ7
hqO+8W4y7WJzG3pzSUIs2nGALbHdjPlHUVBHlpOimBPgpDErSyaRgLMFGQGYph0eiGGPO3p0BRNK
tL/LJpG/fInSZIhLEM2rZ+Lq8SgYz26BLMWwaJ7wC72hH6/gX9w7qBtqDRhvBpafOuIE+CAWriV9
upEjCFIM49L8qBt9hrdS2l4Ox8t9fwRnb4XUVnSP12Vn4T6j0Iq0sghMKJs1uvDqVdIHcdmJ4rCA
3hd6t+Fdkr33w4cPOwg+iNEdTCi1oOQdQIvpxpI2jIDfD31Sj13DM3mhKHydXFh3kPh8DtKi/3Nk
rPE04xrSVZL3ak5BPWSURiLtCCrpkwj/KLKAP6oqX5bu7iEnH3eI3ESqtJxDrbxcWXZx68RAfZPq
baLRUXtPP3OTXfecTk/rov8A3ZO78WhlckX39tVrMc3SGYNfP515b1r8iqxmv2qoVxv2q331alN3
IBEg1SyU6jhiraEyfw7bmzQ7sF9jX4QxS3et4YTTcMDhDlmw2N2A9p2A9h2A+kAy7hQUG85xw3v/
hsOp3dYQElsty/rkp8wuu73PSdgM6ZCR7hKAutiToNYtULMx0QiytigAq3Hunb/nsFYJ0ksxKoRF
7MNz0Ts+KNtgygtjCl2c7dXI+StRLMu10XFLiY+z1BfU8ERFyiymwEg4kKdGn/Cu86nwTzNe4C1o
QimwSG80KT0T5y3wT2Zp4jqS8oC/E04jDf+RlG/y10RMVE18Ccb98EvsbkJCUi7kTXRhxHbe82qK
sWGAo2AU/BPDt45jw6dc9FDWCPqwlQJYviCjxwxjc0IFtg6Tv2H0XomQ1gxU4ftAmyfiIE7POgde
a7950oEle4bxQ9d3i4Iiq0ET0ulJ4dqTK4w+jEtAUpXfFF34TW3s3/KPAddH38u/6VuoXLhvn/07
S3wvph/Fj+TwD3jkQGFMxKcLZkufxYkIb6WmOB1QDT/P1FrBBVZNrZEHTvjGn2bCL/b+6yZ84/Em
XL4tRJ2GyA8vSpuIiV6AMvHybrq09Zg0aetPs0T/C2nSlnuJ8sl94AKl5ZmKp3Ix/jwOv4zNxclK
P8ZlIcExcX7HFDfVXMM212wbwB6FGO/iphsFyF/FO1yWC/v+Dtuj7z20plyOp3dDePTsTXv/mXh8
2Y2D3jK36N9h6/QUWOvlL0F/ei0fwMYFZC3D83iZQx0HQ3rTHPd3OAuO9pxsOWL+and7sL665vc3
1/H3y61eb6P7cr1Xv1xDt/hhjGErbnsryKmtSI6Ntq4HnDPekFZ7T5aXl1l3pWjxH45hStv+hNVr
rL61s7qxs7oJMkl9lb2o1Wu1Jy9evGArff9mZTwbDn/oXM/Y/+kCEuusVtuh/1j95VYNCsPnyd/+
BjJ7ZWvtJfyu1Njf/oZYftQPYS5z5EL0PedPyPyDa7lBqO6KFRr7FEshEZQpAAogKuoCX42W0JEP
1cLBFFVru+wunFGYx8jvB7FkukEgACl+JYzkagkGd/hwBrMdUbvANo9U/LzDkwt2hBJJxA79sR/B
gjsjC2S+AoOeP8YgKDEju+T4GiWXO6p5gJ1pi86wgxAaIPq6SzWlM8ZqtS6bEsCyh5eMAs1aqM51
OEFkdac4BGmoPYv9wWxYIRhQmr1vdd6eXnRY4+RX9r5xft446fy6q2Li+jc+hxWMJsMA1SJo9DkG
GhEOCMRx83zvLdRpvGkdtTq/4iX+Qatz0my32cHpOWuws8Z5p7V3ASIDO7s4PzttN6sMFqYvEchR
5UKiQiCSIQoU2fenQLniBAm/wiSKOKDXGDsn8nt+cIOmqXSNs+A8kT6YNDhTDbm7SGDH4bQihCuy
K7JmkEviahYrrDXuVStsow7FuuPPsKBZewoVAMhBMIAGDoZhGFXYmxBWNBQ/Bhm4tlqv15bra7AH
2UW7oca4BwOJgqvrKSv1yrCFa2sV9gsgFiDDgAgXDLYGdm7qcw0Z7iJcaR0014c1fgi0FM2dfp7y
B9Ur/uBvl7D5q2N/+jq7tS3WirufZ+zX7qh7jVHJfr4T3/6G4QFh61V7YfXvk9e8I+yCTxiFap2s
jph/OwljPL3E+3edQGrbEossIYULM372czztA/ar16/1h7MxdL5PD7XHz26vvEkU3AA5qF4/M17o
cbckNXEWST8Fudt+6I9Xrm9GK3TLE9PLREA/OzjxOqfeL29K5NvCSuJfkNJLiS0B6tpr5bJQfIpo
SbBEMQwBX3L8PL0GilEKqn5VKwOHTRT4sdzaZ6vHZd07wDIZXx0lNxpGUz9BfaAAP/E2BTDeKm/x
LwBZNSa0mTzS7wgHlNkk2igCyF07GERiloTqrmDgjX3U4cC+WtSB4Wo0x6NKKftkDAREA/dlWVJf
tdQC2hUovhZKqpIqWqEmdR4qxXInGruiVlgq09RzAr7riJ9Bd07iRjCFIYqkG1KEvDxk4epLrtko
4t/ITzQr3Mjo8ZzElHPYb1agVCt8gvMuTDClPR59Ec0qcPBFfLrI9AyxxbEs8ALt6H5S2TdMFHEM
6xOvi3pUzlVQ2KLSRtnoQuLwmBHANMvvLK9eBu96KGLpkn0r7FogLzE/yJFb4EHquBFsPPP74TIu
NkQcp7ENGU7ui2Zqyy8X0JpH3FaI+xPWB9oJtGHUveM3Ln0fb0BQyRoHo+4QjpRwFg/vqnDWIcBr
EaKOuCnsAn7hvlO8CQyN7nJdklsNjugbbzaWHetzS9sFVvq8xbggFSB3HPYqmTcjpnbKJQcf9uCg
d/s9oVcUNJAfpBsxltw9uNfwc2qjkmRXgV/loksZzVapRvq21HFPqrpsxso2b3jJnQ37oO1nWTF7
S5/OaPly3XahzrixwVtS2DC7tiSQUxg3AKpQX+RU2e4XmukJXwnOFDP60aIWu3648J58DD6ZXU+m
5KPsgPAf4KV3zaKyjPKR10iPRiXVWF5bV+6J8gCPL7n5kV3yoxtiZl2GxARrMQNi8anJgadv//GT
touQXWJal4zpc0whDd4K0IkfpXnYV0ROg4oc8499toJ/iJah1sE9RoUCc1ckeSx62qKBv8mluLZx
noqNkzQhrXYQPeYJQR6DmZG2iKbSfX1yWf8o9FQVROCVbHudJWUJkGfboxnsyPLLr3u7eTsfyyVO
2virMBXEwsVcwgYgP4ynaP4BUj5IZc+Cyasfa/XN4S0ckzXxlVRQhjGI8fPSiAa/gg7Y0iGah98X
ijbMo4ZWCFIrykFIS/V3h3sHXvND57yB6s42+40/aTc73t651zo/l09CHtxNU0Gqgg0o2NnTsJpj
y1ERE6umL23Gr29Isjjw+WpgAlZBr7sl9n/QCQfkcgw/n4mAmqPfVwX6ndllZc28eJ8dUSrO8ZaV
27iS7a8YR+aenBOg4h5bMjtUxVyDX4tVIUPOJB6DO99ToC9pTE029r8I8f2nWDS/zENCY/NVNa25
ESuwgIKagVMLyLeNafHbQyNa0OgXiWlxP6Enj1RmhIkoSC3tyCsu2Sc/EEVul2GehU3v+I5N/DG1
icrFKc/TQypdf0hhb9X0S2u9khFCw7+Z9q5B0uZAkOymnCL5ecHy6in7Ppulw0ujo+ZhY+9XjMvs
vds7u2jbnmYGXG6PjdnCg09VsxEgucNUUHZz3zm4AGtnoi9bKoSIWSSR62miWM5MuUlbLlOBU1/Y
LowbZBkh65d4NyxiR/Ell5ZEAxNH6GwydsfQqZnRHkRlqesyakvIiSzGC6gWTSEtVxgzeqLYEeOp
my3hcdHlHjMqFNVvGJVgfYqQVokjgKtdirWMpmhmm+xHXOE/Bi7G1hpjupn53dWnA7B7GUzlLwtX
krftJaW47PlcgKgwZwXhaphhNixNqBASbWsBzIVpFYEjV5OkeqOPzDnRZH7lao9YevGiEKXU16f4
mqEscm3ayc3CwsACuhVDHMjSoSiC3zDuYICOSvZLPhJRhSS5z5QuFnIFMPwADGYyU1RCfHBcaKzl
84S3dKoKdK5oTBwm3kIAiy8y1xnZlHSVrtUa539F3VhcG+Tw4ImzAHG0smIhjYYSSw2RtJCIKRdW
cY7W0E7nL6wHMLWsmMJvnhmzzvPSRZHHT/Ki9SRLjTXn3lPY2sRxHA7v16CsO3Iy8OraxNyVU380
CenaWNp56PsR2XrFXIi1rPjxhOuY6mzKAix9ai+mfCC1zVGAFU8vFnGzkr62ManTxRh473CMWVGC
WNgUzGJk3JahX2HU5xKNvDtDJnUSfiY11GxEN81VY1C5F11SRqE7LJaooXNEAgmPGyzXbn8ckh3X
yHQmy0yfoGbwG8hNWYnx9M6ZnG5BEchaeMUSRcgqy6+1WGLaDahdyhQqU+vHjM3qqG+rKpJdL0P/
y4bkc1cnNBpD1ZKfEqy2ty3A4g1aT19U3fCNIqoZk9Ts6jKDNln3lhjkGSFP5Rs/8sKx74WRN/3y
WAoQ8/Owk0P7PMIh4urWgudJ5sgKHy1ZnVjolMnuhvPAUSHtFHEl1qSm+D1JJ2XIkjxW1WKPaibv
n6bqomHVtL69c9vNO3juv5K0Cx5j3tnCE2jNGNNRv8jlgGtXTq9RLHnkDfkYe/HRtuHDduCDNt9D
913xLadfW2dmCXRdZ5sbFY9euVVy9CdJRfPScF5qwfm6eel9WTCUr7GdLTXVtWhabefnlvCthyvK
F+z0GwOFH0td+IrZcRnct8FPpyiuXgbTUqC0CbZ1NkUwG88Sf8DUWIuRzMCONpAerjVkwi2f3v99
dNS8m5WrPuNy1lpM9yHAVvalAXr4TmX89ZxBPQq1vj+NfiBlvg89vgcVvh/tXYjJIWR8CQAkK5mT
p3Z9D+0VPuxx55P2uXdwen7c6GAMfe/0pLkzt1Dn/enOHBKQyWMvLEE7Pg/go41P1ia+Z6/U/N+b
mzU+DoYKP5eR3/28O3+O3p43m4vMkuS5HjhBjzA3jzYtjzgjBSZDOANpOFd5QZMwCHxHSg8Kk5sw
+CUb+tcFKDq65xsk/T9+t/9QvjmbPN+LF74nC/x7cr7inC/A96oqb98d7wCzfAXLgSYk5s4WgI9/
8FtsQD/3UOqFo1GSi5DfiWIvVISpVGR1V6xz19skzLjrrRHYPKPAmV1Chh9Punlyzou3kxwySc+1
0FracJJ4oJiNEVHCY8ldzgbaL7548FI7hXfCK/kQfFTNf0phvytDhCLmr8Mh3avCG2KeNTZdgYVt
Ku8jpcIO323jTPMoGwPHTD+WAvt+1JoYzyLCib6Afy+ZLH235MRKEYnMPURjlz6WDHaP60j8FLmS
fCRBb8FLyiDjhtK5XgQG4rt46o/0YRN6A/TW7gU++c3FSKNkkQQZtnTYhhUC226ZItUNgCCqLClx
+uLT9M5Q+1wzpJCPillRXFF7VxQ/PEK3vmK3n/yuNpbUmV8VjH3uCH3pU+RBRMFUOphGhKN+9y5r
5SWEMr3iJD+YF+dPo3nBpyyp3TaRNpCCfTaREu+wH4NnFWi/iJF0ur9ZGac1Wh98eoyuy0hVSL05
4Hv03NIILR7FMXXwNt919t6emJzxvFDX9xmXm46anI1xtaRhvPYpdVjJM1CnkxnWTPJIVPtPPpi3
+3TSQHWf/o8jLLBj5yUHrfAxUS1qiFWFsq8KUxY+eockY0CxDYxuwQjGeNfXPDk9bh4X6K8bcaKD
FZbgKxNdGBaawrABJdGmpriVRnKUU6Iflwl0uj/3WaaL9VC80DrKzUkeokTTJz+jhnidqXYTfnO4
HATfAiznLIDDQcaaj5UrXJ8bvjoDpT/J9lvDLogZoaLz3FczNEdJ6iUVSt+SBHISBmmEzJmuaE7h
vFxEliyQmaRLkAwVWjYRBqzUAM61XDzVyUIKhGLJCRKQxVITZCUjSK0+uU7EIIWr+UOVAo8lkufJ
4jkS93xYsCMq5pNJ1+djjGcTP8qeSHKEDAE7vQgkFQzIgP5XGfEjrS7CNtSreMgD5gSnk83RQky5
eHIrYj+y7PnmeDkIm6CEO56juFHQs7U06lui01AlMLVi6XliNKR39gAVEDxO/zBhU4Uzfsr0nDm4
AWkpk+FdqUKnp88RBLajLG0KHBzK/Q5GZ8R44cx2Ags6/qPwuJKPyrv5h/NzmMWsIRR0gXDpDLOl
XXSaBrKSqeVnz59rcmRe4c770wUKo9rZNSAZMwYkFgx4QZFf0V9r1IWd/gDf2+eOPCUK0Y53bnTz
tSLjfmC5wl3CQ/35c5ZzDvPDo5xzp4s/1Z55Q4HpVZDtkoyMEwIKRRSVsqbwKZBrw4EGkXzm+Sv2
b8FpNFon7Wbn4sz7x8yP7nJqipQ0pEgb9wOeNFRyNXy/yL4ZQOYngFkgu4ulbpIRCYq4fmV153dI
ZJKZxwQvBWh3jDXaXmCnp80DM3MzZJN9SS5e5W5qI4JpfvH3p8aojTM4L3GpUVhPc6qZSuJHHVA6
sCnTk5qndFcutxlXV/KumIU6yJ1+JEubwEmLs1IhP/Hkq5l33Z3NaykxjtxN1RQ2pULI1cDZChKj
vEPeda5lO3EzhcVKAC042MzYKUk+d30AhbF/j27ozA7qjJ9rF5TzQ5BzTZreb9oyQHRq78685sGZ
1zg6Ot3zzjrNzFFgoCphDL9g/0k81VpXoQCSYJy5exk4BTMVSaGtJ0v7g8Djq8Hr+3FPFMSv+o6X
dyFcoPkoI3zoMDEjofYYIcCjHMRLTksGPud5JFZSzz8ZhEJ4dPKO6JkX+JNyOXNPlbIQU+ZVzYrY
f6yUws9SWadKlLMCX3CNmqPl5dcChEYYbDzNqUkNP6CqZOxeseZByztuHp+e/+rtN9t7562zzuk5
rqJ2i4KbplCw/Joias6vmaqH8jmJVlasUVWAfPPyCugJEKU8kgqHhv1yJ1RVcJKI6MYw3r/JvD35
o5ERQSrSbMxMxEctJphYMta5L3WQ4rgQlwOM1X780Yji++Wa4l3V3TyF7kSkY9tx3nPvlgIymDZG
hxx2iRILS8mU+UiU3boiZfkr1jrhucCOD06s2zFp9GHWW8B9RxPFnTFsEr8WVtyRp9jocvwICSD1
Jxeoa6HImJnDoYp7Y4rb82J3WV3REJQnVtB1KYhzuk1/jhFViST8/E2sPo9niPr8d7XoN2MWGehw
GB091hgfc5BFRpny5XCInOLlEmt3B/70jseNEc6KqODoyxuLHVWS1asY3DLy0CGWQv4GYxhQN2Yf
gLwQABFGLxwn91hkyllNgKxW2QBv3tGcRIcRTDFe8E9Tdj2LpghRq7NWZdMIDg6qhFfKMUnLvbCf
hLWIeQ/8vlZvvcqGfWDM0MyQklRfcjKx3B0S8awABeGhb6HbY7Zdf7mKwTnjCqtWNTAbVXbVRwEB
6cMdLAbq8rjPBtBVzKOtkIeBguEthroyR7BZ5YU4fj770dgfejFhMYYJ0EpuVdlk6lGXg9hoUyu0
XWV9/3J2RTOBWhYx9nTDL6FhICiUUMXCF93Ny66rKisW/dqXqhHsBr/Jx9Q5UzNBgtv1WWcZuBuc
S8+KyzW5UHv+nLQU/Je2hvUoavE0CpODI4GkEV2uyPFvKTTz9Bo6+OrHPqk8+T2x6HbGTdefJLo5
buSioc152W8Q13wb3v6Occ3lmEXA5TYF1DQjmkez8ThJxPA9svn3yObfI5v/ESObyzi4ehTzYDxF
oTy2gptPg5FvPZoXBF0reRevKABFY6NfBtNwEhcNiF4gknrBmOl4gi0tsX1uzY/BxWfSkhrjUsAk
Ttl0RvQvMSqssj2YbbyhiYI+sS+Y4JiSPAKscTheprzBkT8Zdnv+CJPNCcCwqNV1I/a/VK5iHar3
4cMH1j5+uyN3GrKqAdJD2BdfqB/ETtANLTKosnkMDHb8ptXxzhudJp5xEqSWs22/eUABxFqd5nkb
j/LSOteRic/KEmzDEVJg6uM6wwmMWYRbDWTmcMKYC9xBY68D1AdYTpPrxijvPmoaYx/qJyzj2q3S
vvCVKNE/ixDDpSEQlTIx1Cuj4CqClVLBMM+4iqe4krta8Hgeqom6C9xu7zMB+nIdgLTONT1afGjs
BudB8cfnAGNT8w7oxjUi4oYH5Tw6/zC3NistieflEoYuXypXKIT5EgMa1HXKIbmmFq4K+JZkpnSk
MjNCPHuq9QbbLzPXjVObFyGzI0rhm7ZCyw3nN9d2Wzfd1i+K2FMZ1WI27aOy6LffMEG5/giTGMch
RZprv73o7J++P/HkkJyDubdzrsGzpkNFUMhSmvcRSKmxBy14aKfJHQ9cuux+MhkCaqk06gu15lOu
ENw7PXnXPOm0Tk8aR0I7aKEINx/WSlSJTy1dYkYFTYdJzL7FhLd9ilwYUbD1rorWjnoUytGgorZ/
8ZOw7WgXJ0yMKRc8Pz3e+3zjin1Ee+pLVzNaq7K34Rfa4PMDt3cHU0EIOBHFED5m9HYp6tnh20XV
SZenX0pufPMiumNDi0Z0n6dMeJQ4AAXuUub3RCVPwCpcl4/GKhXHC9xQVtIFefPuXNxKyjOVrVIh
n8rogAHA67XV9U92AUTs3xW0v9sByyfJbWYyAF33OOGpkPWBmK9fvMq/2jCoCN37T1IaVnPPw9Yu
4hVB/T/B/vf1SwnDdNHSorITGE3JLP/C3s8//2zfPZQBqGMt5DRjGfzLcT6dG/n9xB46zdqcCO7E
olsK97+nte1BgTwBCIq2d2gkvNjslotEX8DP94VGK+APudAEIYH1hobHJ7tpwH/H4y6x6sVo9CvG
TzSwTXVJ1nYtVCuBQwIFzp2/u0Hhp/jSvSyn7orkx17G+uerYx9aF5pWsfTG/Lszp8IjYKH46Hvp
0btGnfR9DqNmH+5/gtQC/+lg8hlr4h75DTIWQX0u8RaE+hGTHSy0iIpHDrVix6OICrXTspkDn1rZ
BYKg3xulC+8idyztRTdQdpBtd/DsLDi5cbgXzYx074jci4aNTsAYsaMzI0Y/lf5G940ZnXWF7vRD
NoJmp91CBR0Ss3Zj2XPRTZNGqiw9ADr93nBNwCt5F0W/qzwfiHXaozek5YlckCzdP+I51yRnRzrP
s/R2dKR4BG7e8CLT574S1DyGCL2WK5veclZsb2fkNEEt5ob3Tq76MqNJETV51OM4m6AUosXzKQV/
fI+Ac7r5iUVFbY946q8rfcM8RcGcgARm3wsFI5hDBL5hNIKcsvlB0mkZwGSbiSLlFDxKWAMXL/nQ
sAaPnckSP+5slo5A7RblzkpwiR9HvhctXPw9DN0cxDIv8aXWBwfjI/tiMUAbablibhrM+b3PBWEE
mjDsnxxMZLJ4dLrkoujfIKwf98t+bEr8X0qKVaXvMZD+uDGQbIZceNUvGh8pRdKLbMp54fiz4hl9
P/jZfywM0bc4r3PDEGH+7eIhiPAui3bMMl1dkf4zgP2bVBHuJnrIoZoz6tCuc0rzwvsIPF0Vi5bz
3AyXk5n2VDuabeCLOBTMEaruEYJpvrJkq1xI6IKJO0Gzzi6wQWiZqpEyVwgbi0SZUVGcuryaFTPe
hIAHY256yyse2MoIc8Nzg3/w7xnsRu+BoZeQUU3y+mM5/RXF8aE1DDkCnosUd06A1i1aaOckTl4B
JKvQM1ljS8BlYRyPMlOpirueL4diQWhY7iK/X5gjrkVIepJ2Q7lnd4oFD+LN48Rxx2qyIikaZUnp
M0zWd7HQOo/ALFvhUMjoagHeOPmFR2mA1l/pc9woA0CnaHOoHpLvfbqSMCogKzZpcx4vKfPzuKLC
mqTbM7Wci8cgcQUptVj2uvGIzOfRh1EEEmAf9g6OGodtb7/55uJQTReURDaLuUoetd5pGVy+bWiT
FbQ2pQNZpZTS4mcK1M+00AXZ0oxD6mhNBbJV/xI+EZfR1AzhcqJM1vglLPEVwnR42I15BQ6PDOAo
eooe88GMvQO1PazmFWqnAMRpOO0OPSqth2gBiPRGM7njcGdxYl/dm0URViR2MGOatOxHCbuE1Fiw
mID7fvhFqM+LdFjTyds97kQzcnM28WpNkMKeXfsN74IaKTe4RMxoEOSGevsr8El7jaMjjwe0Mn0M
K1CZWFZNCLPB41GTNMFKl36vC8hl/SCaBn6/fM9GPweTZJ+llWjQEeRvXLbDGROYF8SBcpdpc4Nm
YnyB+NhClXVC9tn3J5wvE/GwQRifwMRcBsNgeufY3ZmRIzyBVOdtj+kXLeXHAmZXpo43w8Qq823S
nWJGVhrtnxN6KTkDmQg781SdDsuvuauY9w9/NPOG4RUumrvs8EgnIXNWUN5OV7DtxlXjaFeRCsl9
NX33mLrNLRQnCsdDx4l+ktvXwIaRNEhBALW8wwMzwXTDiSHdkwyHJqTN6EOAC3oY9AKKMDaNwqEe
EJYGWmG00bjVtxkk9qk66LUOqmeADsOWeteqyE9/qyZ/qFXldtNJv1cQW0F3CEvXGwF589D0uZRy
e/29UtykJtYVeCYnzMxfoL81NSW9a9+P74DRgTEKz0kD4SUVMBm2y+dLtHIy/fLrNTRTIkySW3F6
dK0x+kj0hQgoMiYuL6N1ESyBGZATdLIBwku6+B3243Bm5xwu1IscxheR9Rc0ch1oq/EYyL044hTz
wfEnEWByGt8wqbzDIdcQ/3T1WJ4IiCeYVraQLKBFUktWMaA6GAFhv4JJ0sJmvWCGJo7cr+A/2NF+
b8oZj9uRDD1lRUJ3mjnNiSiXKfgUDian+uoOJEdsBA9Y6xs9hhrvScLqKkc0xU/SsNFtrkuHSuxj
9KyAJ+iB8vF0NoHHQERVxwLOTMkT9hqXTlW9RV5bNgKQYSX0l9G/lTRnOK1QDwkDWWNjVQImx4El
FSiQ058mg9CQl4pjKAKFuEPN7F2cnzdPOil1n2sOZTqiBaM5iGl0BaxwzKSYTWNSC8cye1BYNgXa
GZTtwRHHFohzlzcJrsh7GWRo0Xh8YqIWDsgHO0j4W6O6doqel9JZlZwa4OkkRGZSJxLcx+hfDjUz
F0Q8wTMUC9iNH21htN829k/fe6dnXvOk8eao6R2dHu63zju/zgWCHCjpC40vLDeohyLK/piYRyFJ
oY90wdWe/HALRfgxxa1SSVHzF+xNq9P2QCKBYZ4combtOft3yX6I11PbWrOCh+eHwfXdxI+QCfW4
ikuYTxHuRcGK3oOyBQiEnWKAPqPVoAXIXAFPZcd++409lYLUPMwrjagQX9Ft925h5CPjyjnA4Z3y
2OFCogzEYEmh+BEXCgpNtdvBIGeMK+gvT+sERYDl/gjI5xV6qDIuCiiZF8QSox0t7uUc+aMkuVGt
HLmpZeHxYizdGf2ka9ivZd6nBZYy/aOCFxnDlkxEl3wzScEgXM6qrBXHM37aYZ8ZyUIA/oqHmDQa
Vu60VBWOH+5C6NpB9dTqSjsX6rjkL1N4KxIqipnRbvj9Zga6BbXsTibAUCgFBPlhqVEttHh1Ukw3
iVzsJ+kKGqKMZXE48jHKx2yCXtvckWvkvFlFCEJOF5d7yJPTUWoa0+ZjRA+qlhX4sZwOSJ+Ow00j
4tULHJxFAjba6bzTOMiKF+YICVZLHw5yDBa04r1361uyxqOxKE67zTyYGZOYF3ZTVrW4iDOTjUBu
ozo/AudC3E+xSJRWR7LiUGaxM6Zq18wbDyVwNfKwabw4vx+W9Ibtkr7TuhhOq46RKyL4FXKETn7v
OmopD8DknQnEck8xIaY4CeTXuG5TupaS7IGnG8ZQqhorIh5ieAQ4D78ARjCWBpKqie9zT9Ev1yGc
FnTaYvCMO3JYN5cURt2YCso/QH2wPybfWMQbghiFIzpT7aPuqZoCp6PTAxhF/DiZxbNm85dCtVP6
X8mnJLHJC8ExmEyihSq0ucv9ybh3xzkI+PVLord3Ojw5Tg78mA5MxvJoU54jeakfzkT2I1wdyyrq
NGp3qjYnZGpr0azUFVpz113HIHEalBe50Tc1YMUcDvEzx+mQF1nI8ZAGI50P9YdF3A/xo5ne6I/N
X/dxScTPo7ol4mdOc4IApl/lOCk+n+elaGEpA3g23dCLKVuok+S6Bllr+zmdc9l72SS1hrtuoRZJ
yFmsyYx1gh8twLCSr7O685jNZs2FfcGgf/IvG3Z46IEfh7es9ONwtgL/L+NNQz5VNfitwdhaUXMq
n7gSS+ifb2FWLj9u8/ITFzmfZ1UuP+Jun/CIASFIvhiFN341s2etJHBW5I+6EQbnIwkwu8pB68Nx
c0dcoFIEGIxLYRwL+ic165rxO0ZpVbOO+mj8ssN+jL/9xCM3MY3I3IfPJV26lV3ox0/GiYqfzL3g
4sxPlC71xKE/lZ8C6nD9U8ga/8EjyfAvQB5G+5U/ovkGhA5ng28wzHuDNrlwJ/VPzDpSr7MYMCLf
6hAz66QDFavwkezH/g43Yfixz6WKCWxffkHrmEgue+TKIiytnXMeK3Q3DuSmVLLEkteWMEUnLMbH
8lptvIEtlekEdBELLlK9fpXc+VJRq4UXVod/Zhu1dNwegqfZ17xWm2hJuyx2rlaFXc4SmwYt/5O+
zcBPtgZKR9j9NFFFD5V0/GW3Rkp+HqKZkp/imyxFWmDxnFm2PhQh1gh9hAGT+GmUPl++lUi4d9Rs
nNxfJkSe6iEyIVtQKBwMZ/G1JhWedRaUCM0HKVWIuftSa3tlhY53Ws+xxhTZZOY5Faiwut45+9Yv
xSo0gDMRvtkUgRikUSOcL5rK+dEoGOP5MfdmdEIJVLWQ8LsmpcsI1qFH6igUwT4rPkf6ZCtovD8v
xFay8Z8XD4slP7qGbcE6ehwsOwLWA0O+Wy51aoQFe5gQwJRTIL6eE1/9gY3Pa71I3HPWnvUw88DT
xDTf5afOYxPCK/OKaBLGU9KhJ4043pbsyyLZPmYURLLCDz9ujY4eA/0g7nWjPsDqcYsHWtlKIyRe
e/jQozLG2qyTBSTBXVrR2yLLJLov9nqXZHzBoyh2I5BVo24UDO/4BoZz6tKffvExSwQGyFT2Y7Sg
UlhI4OqJ9ZwFUqigaD5UJ9nu0NXIj/0p7eqYFJ+Rfixl0cJaQv5qBn9lZKPkDZichA6dpvp3vczS
Vo9J8x7AOqQpXsIoJJzXRfusebLPhHnWj7VtEYvGbfqmNVFgCurGFBBWH9sEgbMQOfzBPKiJ7VS2
vnje7BRhD/Tjn2ZGXXXwMsYplBIEvoX1xunBweNabKhF9b4bkYEK3ucIGwIgWLnmG5avvTAGtrpX
6Ga+lr6ZZ/fq6rxrept9cBlokPuObughAcwvLEzc9SWROJ/LPghhOiMIk1ZdzzyWVM/KpVYsS4PF
Qz4j/1DKr6BSKzgyKzx9+ufLrWCG6Z6XXcEs/Q3yK6xv/T7pFexhZ8V938yM+442bCL0O2xAloR+
T33eNURyhjY5M8eAhQng4ZfqL3/0NA3MD9Ax90l+toYKpkMoAbpgFBELJ1i1DF0Hfq2LPIyo+T2p
w/+2pA4i28EA1usgsUNuvGt6500e1eNtEtRes1N+a11LB8hT9Gc9ygCE9y7Iftdrmy9Xd9Zqm/2t
7Y2tl6vbPUTZrT9eRgKwDEI/nQnV66kROz87Rzf/1C+OjLZ58Gunu5bcEfPBY1Zv/lm1wFOq9smN
GNcOD/wtfW5R2kKruFTIiTmtUQZh/Kxha/mFjxsfRG+o8Lziwm4ciue0zQOWcXcMHKR76rUcBH+K
g3Y6u4zn5y8Sxb7B0bq6vaqfrX/gY2fOefP9IPnfdJCYKXNys9g4ks5oKWxwUyiLNHL6uWOzK7Jw
IyRd+VNS2B6cAUnbbx40Lo46VeUsSpsXxAof8+bxnYHcXhSEsxhg9P3eUDiZsemXkFHqmXiHrczi
aEV0Z6Ubj1YGk1n1GjcYwTBeXwbTeCUOrmS0m+sq9xxCpyKYte4wDhknzrHRSb6OuT/7FBmufujH
ZNk3o6yFAn4fnexAYPR70+FdmTy5NFwa54rnNdrt5vGbo189T88tpAaAGYdmdKx7nLTrB416VLpV
GW7gU7Ich+BtWQOjt/hk2SiaxFkbTOLIE36jlA8mlRNER8yuCp5JYQMYOaTEcSBs3tHIXPdDxuOW
/wbkEFB57AvbN2FSQUENquwNYnf6U8yibu+uShmhlNyM4LnvGLwUulFX3DiM6qMsru2oGE4NiB4e
A+2yuYc5RRMx7zngEd0dKQThVPdGfU24nyYdFtK1w9H99OJkr1miBgTICh7otlpLFPSAjOrxKGBW
DIW/pV0AatHzYREK5cJkMOZBcNKO1JppNSINS+K9x46swzishZLtqI5UQzQe9Pig3rXap+d8egDH
tZuJF0rTvqRCN7r6WMOQdXpi6GQ2neXrWJ6mzfl6FV+n0Npoe43zw5IWlcWstYa1xMQ4C6x/MgyB
ARnUCw+931VJ4dimfrt1QWK2QrpuouVgx32h2TYCvzg8C1LRX+w1nR0OJEMrmBVlQA8z4GX5y5nb
xqiSmL5rsbCtbNi4/tCaABbxzW5+CUCcmgezjG3Sn/FWgkgXSdvFFoi8kOxMa6cag5rvNhz0dX2e
WdlMQm2F++teAUxhT6/niNdmfPl1tkOB1qiVncnh5ZiUqN3+iFm3E2eUIrTCdC/JdinRygqvchH5
S3dbcGs/lWVfdnf47nWeHnPvdsTmKuGJsVTOdKnQryehtZSfTpZiNgN7cilGo8uSLGqu5wfO99NX
FrzCvdVXnHOL0VbACxFap/aKMPb1wzfJA3FsAsUevTa3ceEG7M1v06/5mKEr0r8DnwlE6vMYE9EJ
tkr3Osu1sMdZFfYWqUAupp2XE47aqSvzDPmRWhjwcsFpRvGlDBJQZssOJ6ry3DaoT1LmNVPS7Tfb
e+etsw5wJe+a5+3W6YnT7cnC9bXf7WMwA8EtC1MUHvuHFCtmtJkFlxz/Yp6vppuam8bpR6ojplzW
6avvUPvWRiXbEDoPTORJIQ4x46gmepFecIUU+sv4CoWZyZVQElLNNpeizzrn3IP6rNNEbQEq/CIR
/AKJ0zIXKf8qpFMp9hjVcIXUL45wbZhxTNZQ6FHCAKWyTPgk3cB8sjqaxyvlUHw7xJF+zBg577JB
mAwGD6NnM0vyGlrnjzJlCOPIkWlujE2S7/Bjyx1c4BB8ckvZzLu5L+dLzcMPX/IIUugks1tcZEp4
J/mLLNQ8siRPcVQFYrA4Tgk3F6VFzUpCvGgUqpTUf4FhiV6YS5QS0K4Yz8pOdoa8hmBvI5/BL9sT
ywQtwM1x4wyv8M+b+2RqsvwaDUmM8Ksc0CsqedBoHTX3cwclLAsyxEXDK9Q0yNMmAPotJ0K+FRfT
2BnT80MWkBXNeczu5zeTJ+mmwdcpQrZcaSlXtEXskDKTsCgOYTJLBHUcDg5Jk+jEPaXN7HnLkUOv
zYVgsa82Z/XtJl+jhabvsFZPzArVQWKjZXKRMduKJDvVdDry0fJrK/Ce9gYvrVSMvbRwLl3eC6VZ
dWRXTp8gKXn+/odR+hByDp4PMfsYlSx45V6GruKDrevGtRzn+oqze+Tw1EqHOUBmTbtfrLIBLHJk
12QwDMxpP/Kn1+FctZb2uJa9zvgWWGyh5YzO7pEUgnkzZqWKvWJVfM6VrAWbeqst9Edl+wDBsb8A
v8cdZs+8N62OsUxqqSKplSRZQw2E0JSviNzLE7Qx5cFWXY0e7nlAoE/3Gp3mPnVg46WqT2+Vdfi8
2q7+2NDLNoTWqT3qzdSoW6fM+pitcBhl/cqZzj4M0Hj29tc2vm3zihs1NThgZqp6SNzruzjAi2Ok
rH4cI75iYDQwXNuUItaVXQg4O4Fm2r8QjyQ6lW67zDmk5+zfGNlncHFUdpJOMVMFyWeaOTX3mHQy
MDaDSAtKrpE/p3ZQjqvD1BdHkQYLoXxKk5GnT0slLP9c4oh8tp4az1qnyjMyg9iksJN4ef8p8WM+
0vdNOW0jSp9FMZpxESYdXh+O1RRKRH8WwPnrVymkp/CXdriZi306c0xkFQBLXgDWVBWpJ16YNQWh
KKcCLfzRbURhHfXQNNJlr6LeFTFSucyo2pn5vGodau+sbe3UXupV0WRlrV7ZYi/g7yaarDA0rvwN
Z6IaX8OyhvGmd0/m5ze9PnBVfhUTXNyzPu6mSYQqmllcuP6yWZ8zonhZDGIEJonDhYkPC7av3YFh
TckPFO8/qSYfMH7gwcJIfB/MReVvNKPr25WX7MX6lj6j98Gm3SPmzmH4cRxRSqL4U3b9F8v3/LwQ
MzpnNic3mf1f1vuvV57Tc6P+A/qv4d9eTdIKYj7+H6f9BVcjb//eRM1l5q7e3Z+oXRciamuVbSBq
a2ILKGtKdHO5OD7bQ9PHdnMP0825Rv1MbrhneXXhJGpn1qVQa0+YZslp1xe87tkZsPfnzcO2UV9K
0HKxouUUct7+kCzAfDYWAbTd/WseHZycdpreSeO4afcPsyYRLA6HuPiY/L05JLKeQhkN2iIaTlZJ
ZN24QWitb/DDgtSsYlp4NGCU6ZGVQPM0PIWF6hzQwDAcuoRf8rxgbXvT8yiogPb0Fh7CuL0ylGe6
+Rg1AW+5YZk/tIB1eaVlRyVpeMZStbrRKKsleCXrxP69dwBvO+dsFwW+gRXq2nbtT2KF+t354bvN
6gOcH9K+Rlu/j6/RAgaz/FgrZEbbD0fmw5+BvE7vJn5M1qCJ6J/QZHH7dJdSkeiFlFsD/zW9nc5V
y6biOZgqAgWIJEouXFbzFJboYg2Hkrgop3US3Yn78pFIIUFKuSTgsKjo0gM9d7VPpo3lXXcGYWHd
gEdYbzQp8bSz/C5yeB17XoXpjyJ8lIyYv7Iwm0AkEMat4NwKZWp0tyD4aGHwkQCfzBg0uPyaLgd/
ZpH8nmMFZdZ5nVfHyGYhgohgN0Kgy0P4N4hlGPEvGL8MzSOGaOpLSsNggKbJlGONw0iFJunPMNMN
6VmFBtKXDA1XP7Jn5mp+Vqrd/viMnZ23buEof4ZRw7Wf5cqC5dMxnhReKvwrv6aNkqeRfIrLUaZM
0TCW0uUle7U7m4beFAhjPKTAI6h9RR1/VprqZJUSI4Af9HgiwanCLkOgp5gZ6CaIpjPKviMNrdES
G92s5c/IV9Uz+kD6FlloxRhQPVHXsBgZD0xwwEXJUpn9LckbcjkLhv1qL2Wsre1PtLgLh30c6Mxl
neFI1Z1NzXQzV57Ct4CpK37S24obuwLTXjFjDi+BnAlEKQr8OJkMd/VROsU3fyTsF5XBBiYP1jYi
L/VKeN/z57n3XffJYgptiN2e3HDSM3EZlKRb5umDloCjXV3fTeyUADU0FHnzriFGi76hbQE7cyYN
86k5TPxwu6lUBszlAqtORZpZYOFB8YLrjmWun/uuuwcuO0Ul0kCuBl/wm50D/l+tUxGVtgPMKDBn
8mfr/zW/av38l0gRrxXVn9ilpcWQCdx+mlHrzF3tLLPe4cF7WZa+au/NRPMGBgGBAilJynnxoLxi
/tZSzRfY2VjMaClQ+n4pz787bCAaMPYKfUriAY2CvZDvKY6DOls/1ipML1dmHxM4FbZ2+AYOt4/r
h28qrFqtojGSHJ9K0K1Tm9IalEiQgFcN/1ECRPGXmZYOPOkb5QPXSQLOSYBLWU5Q8CkhWfCjmiZk
+HQeKaPxqmCScuQfA7ymFLV/1ucujQq7+Ctjxsx7qCQ4lg1A9T9pazdVRKZhsFpczqk0r2Pm+F04
EOGtbWiv2fGxWr7aPGkDSw9Oq/KC1UlgPvYOd51V0oPN6MmyBtYFykCB1oNlG7ZV2UTLV2Mi5519
cv//Iw6jKZ5kFb2AlhSeCE2FPU9JLOVveHrmH4cPOgrvcww+8AgkVPANjuxtWlzJPPFFNpZF8rAY
awu6p3VIpyFGCsT0DDk8UDI6Knji+/fU1c0MScRsvqjvpPo8iiJiIV6fWr0vvy9ay1x5+TULLEtu
wgzEYDmRlxfO3JvJfEguhzxV9awM/EmSgoH/npfBt9ja1Yi7YAB6XRL1KaCinhLUcf4P+8lhqDic
b5Rgafm1sEx8bnhBOVLWGx8zyxLptQxLl6yBmMT/Ic4zCfeSsG06dI1j6z8qw8b1ytS1B/mwEDqM
09GFIsmlycQmwn8uL78Jz2eyQA4Tzl1OZKVdSlOC+6JAMhIXn4fNpx2nlsp6ihI+E/3l16jElR5H
e6cn75onndbpSeNIuB+lo2pjpe5UXtSYvkrv37jLm/6Z+gGDH2dyD+Q4tKlQnJmRzWQ3p7xky/KT
nWgQ9OVbVixVYphlOFKnMoa59b6pfe7e1sZurpm7RSO4mSxUetE/Gj+XOLcAVzfsC65OhSk80K2V
E1PlqhYkPZNnyGIXFmIF+M2v01dKP/m47QhZVi2ip5tzaDNxXU+HMb1AK+cMWLbz1GA8+Q+rSFWO
+ZPT9q9tc7oSJlyZkKe4JdNnwVFgialtkQxV2ym6VUzKgekDt1FAEwXSNrCf9RwTf01+7DC76G6q
JWlxo5F0dz9sLWjKRcO508sFkEVbdVFk6TqalBbCMb6UOoKIiHuoqKZwkBQiSMJRJqteJW8W5can
AbvL5cTzzEVvmgBI7KIgUAy5eayVw86Mtj3wf1P+Pa/23OAWyby6DNrYEjaC2dNkY8uvJVNh2I8t
6T9NnlggLgpuqCiFu0d9yp4HFPsdbZC3744dIh4sKf4BXvddJ5CUhXjc5OYzpw1pU3u2euwBEwGs
QxHmjqLw8NEwCZFdjQZmjg2NUPG05VbnXe7w7GnJtf+fM+djNPa3wvFaGllo3lXxr86nwGfU2Y4e
19uawSU29r8AyMjnrLN7mxSW8aF7CcMNkMvpHC7sKbaYrQDLYLxFvxlNDMVJx2BUzkTL9mRoE0II
4BmTsRcvXEjDCMmp8ZZgZMuu0mXHgGWlTMoOBR13S1qB3DRfmeyb45NDHosD0dxr03vOlqmSUSwg
WxFjYO6+Il5mGeeCY5o+celKI1ZWfVlQMdzzL6I1kg+MWD9aWAFUWAWUfYvmhhP7PTQk8nj0BRCC
Y/Ft0Q4JC/gl/u98mxgYPpyi0HfMuxD/s5I84e4FJkMRT2Op7cFHzeEAw3MCJrHD/cg8UZxMlCbF
aesr4+iQr0XnrLS19vmTVr3o5wOnQxIq9pbvWo41+Ck0gtcYR4rj3tgovMYCOwQPKDGtIqgG8WFu
Y1nH1gFcWzoHhYU8RnjJydxJXURsDzpOBo1WHkWWzVy74Pzq7bcdYClOD9FXriJWWUWtv9yqngey
zNU4HHheaSmDlKBwmgukAP9pzMAcWtKfjQoH4ROfh3ObPAAIlMXYGtgDAhRNUZ7En/jVtXPl9jEv
cPEvhktGvwQNJTvutar20MJShbZdeHdkV/kK5KMRerJsASITLQUmlsZOu3lKEaBSGiWZLw+/f81a
DH98/y1hZD7P0PtbRPLf+m7n/d3O+7ud93/czltF16djnI5wM6q+8Vy36tbjkosIybJa8+jAa8DC
8fYbnYbWLXiOT1aP2m8chY8be29bKpI+ax5Ds97mOr/Hz2a3xXFCsVOmzCb52klncUG2PO1SiWT7
R6tveBrsPqKac/fRdIC7/2l118NUXfO6/w1EN33Ufx7RLReR/7186+5/2i1kN5WGQqOFf/z0E/wS
y7sMw2mWr1/y/l5ur1r1Aq6vq/U1dOjn/yROmhKIF4y6Vzrtwxf4DJ008bN/eswvFT2MPtbcx6Rp
y69hMcNEJtLNKIh7XMSJp7PBABD3Qn8jHxJEEhFKlGCR1hE3wsbO+N1oSFnZymUpP6iFJO89e9js
fWfFHw6GIUXgzJkardC950eHUWCSttbRkRb+kh+tMK/jhjcCID8N0CogmasEOV/5V1LtwAH/gfxm
d1LIe4aJeNaqtWXuWPtMWviIasQX7KRUJTAWbxRfluBfvN9TQHC6L/1nbMd8BFCptvDcyumFiI0q
K3y997TmOdYm77+FX+3aekrewhAXQtVGLgTAPkO/aG9gHKSEDT/GeMAqKNIs8pfjid8LBjj1QI2I
gadqV6EfMxCGeI4VwNQyJncdZtTlyyP+o2c5myP5fRfp/teJdNjqFGaBEgTC8jn0oz57C2f8qDse
s58/R91bf/i3GOa12vdfZ3je/hxP+0HIc6Xoz2CMqYcRZhQxHxrutXoKFkDpNPVwtPIZ5R7hi5u8
wWgK8H+rPD4VN1wrXPpLvQ7ClUkUTsMekDgbaq5PccpRGIlwbxoNpYhp9Bpp5gDTxo5GodVLJZ9K
uurNpsEwSeVz38Ak9kfMW2Jpzq89gUW9CnrcaszBtACbjdyDZr6TmCkSgYQFzy3OpJqVuBl09QmH
Pr8y54+m4bQ7FNZp6kaGsz6wRzCBZWbpVb00mQ6KUNwZ5deyb9iYVh2RXWDIVg2UYJJHuiGPgEFm
UtC5acTT4Tp6LRIz60KKlNyJhURbKL4Y2NLlxDAWmlu+XNJ690LPAJ3HeCbpH2ISuCUEyuYrr5+T
x+oWOlauwvIVarNhRYlxJ1xWMuCkJEXRlVMoQ+rahcaRSl9gT7WjNF9Jo2Rl6Ksrs7x/M+1dp6vw
x45aYn1XofhFVWtMW/fzaplNyoqqRbndnkhzNxFMm5vbUoJ68QBv0fCo714Coe7TkZZIAUnsYgUo
DvnJ/cVnYx8qYLj8IQgK3KBbckVUVmxpvEHjl2bNYwxq3To5OPVOLo55hJ7S5aSs3dU4C58dnGjF
tGtKGjwsXuAxPnuXw/DSefmira2w70kTZaNu7F9Vb3Sre1fNoT921kNL5uUC8C4ny69RRxYlnXB2
LqMKN9R1dMq8wcEqeFJg3vshah5fsZKL9BlBzAnn2u3QC6FVCfW96QGXgIHeEapxW8zX4KhPzblm
IBr3JnelEpegysaiFvAqBhBkPD54hxfNdsfbO94/ap00yxkTIwF8TNUgRzAY/U//U/vJecllUnbN
hDWXtFdEiAmg0BqVt2oTmdfCib1iUNy6jlyYrCbwTLqaPFeElW4rtctK3FZHzcPG3q8UvvXd3tlF
m24rtTnX4Cy/JpUnfkXXPU5WvNmEIouPuvFnzR3cqEZpadxnrPk0s7IztwU1x1ZWPnz4UKReZqu4
JDJOd/8WJKixpR+TdpfpjHq7FjfE8bXwunFoluXyEUaOfN0UXivogkPk2MfUjSAuoA31irGOuN5X
W0CkRk9A8EtlebhKwgyAz9rnKNBhXuFurxdGfRH+pd04YmvV1er6DmvsgYixRwfMmxM6V6B0VfWA
gyYeHDAqA/ljMsLGHvst+dUyfr2R0Ue16sFEzjBwL6O4irbfZAd/ly7bG2CkbBHCeBPZOxG0RIYm
++GHH2B4B60Px01XV7tRdcC761wPdogQrWb0cXX70z0JsJidFP/ocCT9+k2ZfXNB42YzvqtgBNWE
W4OHpg5K6KWrY4CI5v9CaIJydOCfoo1M59QDYZ0QIYvj5kcnggHuBAtZskxKDkE9pv1MFtZZb5s1
V2UMum1TdlmK0k2/SvZ9RV6QFcKax5V1hZB36f8vRB/RSo+uFNGWLcAsshxz12H4ObbSmgrMugo+
17CumdMXKS4mSVnVO+N/ce5BU5wDlbUuQrNEw8QrJjkQyctUWrObh5HOG1qpDy8j/QDgrDt2guTr
VdPP0hKsMEA3dBVjallvChngPru+GamVuhwHoT+aPSun8wtKhvfgPXL23ptGu2mGi6ZFqfF4MKak
OPm1ZBb/SnEYXK3VUgAzZMCvhdDHz5vVEawVLZmdJ9w66YwXVFtNLdpfQ8sGX8Y4fwKsGY/FjtOH
X02PFKOxjxjxW3OX5AsmrVSh2ZMeoCrEU4/pCZUm4WSG5jjS5cnzb7u9qeIlDNF7QXNugWfiLhxW
6nkfY7i2c11vNxXpgOeaVltupCXryN5xhq8Cp45cqvqwh+mEkuA0JS3HlDOHqDPnYnbJZIO7PcaX
HEnhTMcKaGrUlw3le32TTaFGnufqipZAaEwTEJEiTwX1w5fZ3Hn6fREuXHG0pWc/xjuiOvwLhWQM
N6zwjKmkpMNbO5gbWsoeXJzsoUMuxgG0+lBxd7qc7nGWY8Nj7IxksS25+3MPdwfgken7+/NWp1m8
voUfXZInc+9Xhi91TpQLEdBIo6Zl10JxeGOraE2jvhaYaW7GxzkJHwUYsVX02EFZrt55/unQNQHp
U1WwZRnO344Kk27faF97I52yM96TIJPzXt91Kd11KpGi6cVddsBLfNQtF3UTm8rvJDcYwiuF/CX3
DHPnRcOPe+7OkJX5pU5JtvDzK2PFl+bCYcvmFlEaLpxdO8siUQ1cDWUVSUxGaEjpVj8DU3jl7+gq
0Ql01iAt2IOfYjrwUTgO0ZiWEYfNSZumXx351+EXpURFqBhIw0G2d3YS/O/s/Cv5UWHWxHxV0JAB
oUvEySzCvHmWrtZg8BcnhiBI/8CRq2bDeJpJupIijvPCRaG0y4RsAoWXH3l3HvZtR1rknpY14oTK
k8uJoTq5TKKsFVJz53EPc1TfbnZiJPOUJVcuCvVZmgJLYEksfeYzUDJtKZzbex2VglLKLM4znTMT
gyAakUkBLsAf42cV69B2XPf8p0UWMePPoY3edKhPO39i+FLyR9VZNUFsVarQyIXo9LjROmk3Oxdn
Hm+Sq/3mgKAVXJtTaNS9hb66C/bo7BM9gCnzknrpwsJM5lVqa2tFNWECqmjkQOBJR4q1Ehx432E/
9lNrIeo5HMSUUKxENepJWgrom9lhAZgblrGt509yYXwWxOUiC+YfM1/pNWnU/XAu/nPHnkykJIrC
xID6oS6eUx1M0osGo7zEyuIzX+1ZZi/mQnFR5fltu3ijNCf0R10hyT1oJtUogPx8dfO0nNMRRXPy
8ZwD4eZ6MuWpYIfh1aqEZD5dcM2n1AWOkw41H99KU6ArO80LwLR0ratJDRHbPj6Tcg65eJ4szNeA
1q1Rwk6ZitpvL/n+fhJu3qiFe7M29PnhHAleoiQ2YAu1n3YHa3Fm+q3tXNbsj21oj4rvMM6y/JVv
72XErSoXsN6u115W6uvsBf1b0yy4+QUsB+XJtPX6qn/iWk3ZHxGsOwlu1cV8BxRBkjIf2Bq88hPg
L6mmnU+SrnQEXbcuJxXd6Jzun/KUCxR2mMnVTFWfJ5sGWvkhgXhU9/ib0113FdpbzjrJvaa+Kwhf
IDz5sefflmjEMLQKq9PRWCdSUWE0fgGxTDELnqBVPJ+fVTE/qxsVmMaF50cYUDgQyYPdsf9KHL7g
VYVqx8pEfy+scoC2qQdU45Ydcq3JDkPlj8GnskgVVudTsL5egb3z7baIrRPHPDSPuAle/EemkCui
nlK2B/Yjxr4g1gd+lcplOS/O7fJ8hAppETjUqCfnWU41nknGXH/lE7e1yiduc+3+e6fC/g7Ly7mD
jFmg9yKhDsU3/K+cFeEYBZilYK0iNL7A8Yc9T4uGp0VbhdI0Vfc46KSltuuYk+/uccipqgWOuA2i
nC/gny2eQdEwS6d87LfbmwhzedTrosk4U9hKz6LmB61pj5NPfV0RzLlFV5N5SZXFW1ztI7OKG7DK
6Xo8C7lW798lHeRyvVwWJ8sWHfgvtjasxJJ4RI8uS2XcuyNY0SAEBEMfGMFnowGgnZym8H/PZLID
s2pEdfHbJVDmwI9KVoEvjgJmHkQjDWKqV1a3oFfQox29P8vp/ixY6UvBSszut0rEOLfb/dFlIUwW
qsc5hfVtSmm5ul7jvngp+zwVwlMROsox9UQ6VqILNXJnwyB2hUC33LE1t2KMPOpdzgYV94lnnWvd
W2wl5k6YixgRJlk6J3do+C8v6btXfoHu5p7GZjf68ZRfh3KuVQQaj7iFD/WbML65AXtoAw+Y9Zcc
5XQAYA/RrtAbdgEOsBJhyildDQVED8rYQzp2q9R1d9wf+iJOHB9GRcjYUNhOwn7THc6ob9pkPg7k
JQWaLOdQ786kyx6cjTdQhcXouYWnmmid6xrhIc4TFZk3Q1yNnQWfjJts+PSKh1JwAOezhkoLTDBb
rDG01+R2IadtRvpzDMwyCv5JLmFxeoQYdjjmvq2ZXeCqAFHM0Q/kCjCCJm8Yr8OWp9dROLuibLVy
PuEx7ti+fxP0XI1lLG97ExQ6wslfi5+SK+T22OPnpBEcKL/QN/BY3Vzb0j1WH/VDEr3q/gopb2+C
OIyWgwGOGN7Sn0O5OBLsT0O+ij74WrCeMz8aBTHdxAfcAfbyjl2h16UPhJPcWMMBrY8rH80CKPAP
tBlDhfByCmQNDYa5ByQBJC9ItCiW/qZ4NQprIuwFlC2wH/ZmI388pYXKKPADK6GP4zPp34jJAKch
Aev73aF0MFUOrNJdNPLRfbDHfSD5BAfCpxJfD2E7iFagOoGjYDUxjmKGcY2wzxXheIt3wzRE4T1b
0XxcYbvRsuHRkDSf3dgfDhEKxssX3p+yl1SObo0RwVOBMmr7y3U4MkcUxARuALIFd9yFUv0QUEgt
/93vTaUj6CDEhI04TKD4/YA2+46azM41+vyEQOF6KjTPOARJgs8CvyNOJly8iq+73FtXbBJUbfBl
po0uwp6AWDLmBnRhxOmMNWrNY/htk7VPDzrvG+dN1moj5/+utd/cZ88abfj9rKJ8gaUfMDs9IL/g
X1qYNqv54ewc/XpPzwlc6/jsqNWE562TvaOL/dbJIXsDdU9OO+yodQzyxD7IK9SoANdqthGg5THM
PZHn+QxDN/YB9Enr5OAcWmoeN086VWgZnrEmGoqw9tvG0RE2R/AaFzCSc+wr2zs9+/W8dfi2w96e
Hu034eGbJvSw8eaoyZuDAe4dNVrHFbbfOKZs5vD0FCDxcWJR3lP2/m0TH2O7DfiP1L84pL3Tk845
/KzAiM87qvr7VrtZYY3zVhu6zId5fgrNIIqh1ikBgronTQ4J0W/OEhTB3xftptmn/WbjCGC2EYBe
ITPvLnrdPtNjNHne21/PmufvWu3Tc691IOKQ6FJKdgmCwp4mrOvhycWemcYcHrY75629jtc4abc4
O07cDCy2cTi+G4WzWLrsr8zGtHCJMpGvNjqJjCmC2bPE5p/O3DZVmaEHNz/yODsSI02Nwv6sx73f
a7dA+tdqcGZUZfZUGA/d/J90mucHjb2mtGbyPPb6lVZBR4C33zxonTSpIvd5goW7f9Qsca6AbtDZ
/3DxHH8gYsWdx784C7A02WVfARI/x3lnPfaXv1DieintPbBF3lBeIxKBSTsLNFOsU6h7nF+BeGLv
L3/hFTmHTNX13uW1Vib4+f2hcpq0nQVHfLLxlgHA21w3YLgbSOoLUYeijPrIMjvYLBSFkhrIGqIY
Z3Qs6n4pXY+BAwCWuoyXJbDG8EG5iteQ8BBX2pdrEvVqZU39gP3rnJ4etfXdfeVoogRAKgxBCvDw
G3WovBEbvFhVeX3W+jt/SCZ1arTbzeM3R79in+VCt+Q9eR+wm3Ti7Lzliefs2fDWph4NdA9REUPe
tc7/b8wJFp3anFLIvJPw0mt19uQk0W8KLFejwMJV9o6nwWDBtMeAz/ejdP3jvYa3d7xn1q9jfXjD
eqMeZwWj2WSaUfmsaVZeVZUnvlWZRnjcvQ1GsxFqpy+hR8ALiGwdbO/sAqkkG4FYHCxPohBTTwE9
pgmJOZkEAHCKwCF7uCOTSwGbOb7iiaSCGKUSv/eZeybrl3uDAHg4wGA3uWPVd4/tEsl4HD6UoU6J
cYkZGdYT+wl9OgP0GkDQ9QZO1rZ31tjfP0+2DpHtWm0Anx59q10cOWpZGjFRCz/rSa2s1Ze3/mb4
jVbgvP2GDxPtnK5XS50CZlGjnE3IZZaD44MTMbbSv2EwZS3K4WTqDSaRf8XUjTtiWbO/MkeFsXo+
rsocofjhWo1whnEKPYzwNrqji6YVsnIEZrW+uXx5N8X4KQAH5Qh1x/6VzXalwxFv96bbY/bVf6KC
MC3otT6SgQFKrTt6NH/+dBChbcF46vUix9tpmP2Oak7izFe9ySzoO172MGG74/ll/MV4SgPDuHLR
jd/f2diSllUCJ8mykpiB/4vFJJ71742tvnczsrrDHwNv5cIjbOTLyOtfpsfV9yajnuMpRs8YpdED
gKajPDRs56MBhgz/F2gQY9MDRRvLGJHG8O+u8bRPT/tu/y4mfFhvvBstaZdVRna3/nH15acMMNeT
IL/y6seXG592C207dnMVfaxv6vvO2pfd8ec6D1eNxdjKCn/EI9CXItiE0Vq9DCe0P6Y3NdbtoRdj
guxC3bgs0I9auh+1zH7UM/phNjvuul3uoEPZr2h/ftzImB85C2sf6/WsKYTNn/VmzsJY/7i1WXhu
e4DT1W0dqelNm67X70VAaAHBe+e1vHKw33Zz3990c99H8U09waK7zGTalX3ZngNr9eNWPqwAsS6A
1TdzS8Z2cuFUa2v5TQWT/PeDfNQAX5jfA2hgDoRBPAfASOJidT234PXcWVz/uLadj/ph0Jetbea3
dpM/7ukk/70fBvnDjqKP63OWyfRG9nVrNXdtjm5yAQGfnV8AULcxbwMMo6imdkDudoSS9XnNbX5c
N2isJItFybSkQhv3oSvADRIH481bmzMkvTRmTD0Sz1AtKlTJ8B/64EDJ2XgaDNlJt0MqcIpEGI59
EyxZQ0hhBdin4VCEN/bHaHjXp2NECipAHaoUmU/7AK8pXydCT9/HHIcRBdBGg11s2xFChTSn+mdJ
T7iLWqcujO9LVesh1uPOYQASlal01xnHKUAgXzlaRBGmN4siXwQssautZCCdX/k4urGbRucEZQGQ
PVRpETwyEy6edd4kkxwmZfqD69xC14ULjbILGTzhhldPEwMc5MifdtGRLwDcemhBSQulzl6Rq5Z8
S+wh4KLCauKNWCtpgMiQkOEWgKmhBr1eQZ0GrFu5vGSwAiqK069zLxnDiOKP25wVwtrhWAGJ86p9
Tqp99qOxPyxWbTqaKM5r6o8mSS1W8qtXVVp9dAeF1knhJC4/WU5tJtRZGKk8SfZOLe+bxnkVdSCv
2Eh8e4FVPW73miqOr/DeGtGGSag5Zr90QbqHp8M7up+kq5RUVdxkV8n9GEwNBVwNkVjd4D4Kpgxl
slTFq1Dme/0CdeJq0b0mjhg5ljknER9XBsHWhRiHwGJkBtClmptJX6UbSFeDt94w/KIOBCf93/y4
tr6xmcXdjkZe96YbDPVDIgPQ1sf12ksC5BgNdhS7Y/Se7LRV+CociKOmVcj8KeDp+Vpiod7H+zem
AuUl/pu4NIQ/xyT2Z31YH4I8aCQa6Pukq+7XMChsPBti/HrUrGCYi1G3dx2M9eTwPMJwgxP7zFIC
Er+xIvMc9WpnR8vTHQBpxjARHBxZyGFU5Dt88oQbhsubUdtpUvM+rLITOHURQqLMEy1UxRVPTm0l
J0s7GzvZd0IMqIMAvHnQkiEtcLBy69gQkpzrKQjdsQ0EC0fBZBpGBjyyKnC4nu9yeAKAVlm6pksg
wgyT1/5Y+ySHo9E4ygpJSEtHcVhxrlYnHt2BJFI7QdeGCtRjKK+DE3kfq3nA4kquJrTJEX5Gdz9V
wFqK87kB9inkmd84dUQtLZwgGlA87QRrwkvrkES3bMfpdI/4IezypcUAaJzFAboejuHPKziYKaR6
YPNJuZ94NkENsN+vZiAk7ZBrrctJt/9xrZ5Bu1KTYz8Qc5mt40W+Ds8Xc9J5kDC+5+/cSrrJ1HcS
XU2otLV6GeqoiJzVHKMze2H8ou5mXZRZJcvGsYT0Gd7p2jZ3c1PgYOpKV+ws00/KGGpgbKMbWRo9
w8XAUJmkxRqbl/q4na2zIgVH7vte5rvLeJL3jiLQZgNOdFfOXq1mvhz0oryKa6aK3pK9URjKfNuL
+5nv4px3vcEwG+ggzu7uIMh5188d5np2b0CkR0q2tmqweA65fi0bUbM507OZV3kwyRkzVN7Kqwwc
ZV7d7dy6V+N6rop2AmI94gbjTGfiZpjdAT+3by8/rm/kdm5V65xkj41938vb972F9r1bRZqnHs1T
jc5TixZRic5ThxZTheapQXNVoHnqzzzVZ67aM1flmafuLKTqzFNzzlVxFlJv5qk289SaeSrNOerM
QqrMPDVmrgpznvqymOoyV22Zq7JMtrXOM5jxdfUt7gD4cS3nBLvMO61RMZNL/3IWfR7N7g2y6YR7
WZC7aXfKqS1qQPHynLjyqI63YFXmJsCkidIqTpOKODi/n+h0UiBS3FPX7FqKyhqMhG0TMLD1xxZ5
vczlq4L811Hu28lnedGYlJDRgXcYXe1VJiP8f0+Yt7jh3OZM923efN/mkKpbsZ1TmDOYYy1ktOj9
mdRGJEo5mXo8RF+fy9kVl9iylganNLc9kHfyyCwvkUPBeQH36Ek0xPeWYMjHoMlu3Ho5uiR1Pyqa
x33S3qFhMs8JhEJjIt/2jKULT4Lh0AAnzMYxJm0JrxTuMJs5ctBktMll9DKgpkUqxGEXZHw0G+/G
eO8QTA1YX3y0Oxe5cVRtTGraZRv1VVbaXF/aLjNhdSfVQyriftUABmP0buAFNlviBdgK28a+4CvY
q2isiKb1sbnRuRm7BsgfCft7RJu+jRFOlA1IjcDulwbEeHUSTv0dhtnWIpqf1aWl+rpQMr16RT/r
LB6GU7NeFj2SGMjezZfxx9Xaet5+FyPMW1Dn7Wb1xGt3Gnu/NPe9s7e/ttlN0GVnjSMPXlEsLqN8
m9wJhnfy1mn805SWjzhlKpTCit6RSQy/l0LLtq6FScSx0Byia9EKeirAwquydii9LObiiUZJKhAM
LigW/PyjEE9BZdl3uHfgNT90zhuU1F75ZtbLGBq97ePOnEZdsqawbOCoarvZ8fbOvdb5uaq6qqoC
yUdGpLaz9qmarhqOKW8EfmTVtTJXt3U/+wKJiFtR0Nl245yMIiWA9bIMtcImN3AUVUGwqWpq9Upy
J+BW7vB0Mmqt8IaW+GON7M9hM4wsuxYhRGqb6HACIwDrLeWs82lVkUqI4Z0JgeRBdigZ2PXNSC0d
kZWFkAX79ZJSdfMVJgERNmOVuCypncQaRBs9ulsaRn63f5douqU939nqsdc86Zz/mppH7+y89Q6X
joduX/xT+ndpefXiqFx2aqHEiITuzKXeT69YB6Lz1Emu4spNDgZfYzcTFk6MsRjuBTI2Vu1m4kE5
/BjvSWlXI3DsuDthQSh0/Eg2uZ5eUXhy1IEm7ZsBXkNMwp7SXSbF4tg8Kvx/zLpDgmc1YRunomPE
/ulx7d2ZF4R4AkyY/qkJROyF4xsf0wKl7i5I+UrRC6SuX/gW9ULoZjwJ6a6Xei67kqpSZS1MUyeu
SWI1nIphJBry9Xp4doCuEO+4z3cQiygKMPi+L26W0ZyXr9ufgKaG4+WbabAC/6f4ODkYwEFNQ+xm
goF6CgOZw3CO3EYYjSFdVXAiuNl9Se1zeop9mIZ0g6w+a6Kn5+JejHblYEZXUphhL2/mKRCRMfPS
yvmC3uB9FHnvcdoi+ABfpWsUhunwwF4f/Fo5p/F/dicyzLhqfEMavdNCcGFc7BSMl+q+TBNbJrtd
KJdqd1O0699i4FMaGQZ354nOgdUIJTHNAsorYnb0BJNbAihS7IkfDUZhdn35Xv9si/pXGNpLXibB
eskaTIEBe3g4eASQf17KNuA0HEziL3iK3wSx7Vmgg6NinirGN4ukF41+H2/UWivcRl5QPIoYltu/
IPR4Ubn76ukZEU78yQ63pghPjWDoX/n9grMlowLQrFF0ClFWfvQ6zYMzr3F0dAqnWUca5tdu60aI
/aRDyrlhNv4mI5BgzTEI3K1pk6rfl+Fm5r+rQlwBEHGAzdOBMeELHzdbP4h85GGJal3eqZ7TS2W7
whlZn199w9LBCbz0p198WPGUeDTiRxfdk6sAkayLN6GwUWdAbyParFnDRI8fEWs+IcycQq0IhguJ
HfVKHB5kzI+4zCMP2pHeaLdbhyceMjV0JWh9aknROSUVg2mDLKdAIG5o1lMgahkgUBNGbgw0au6G
glerYxgZFthJZEkZs3s0Aw4WpN73eysX+F/ToomyjTGs3d51ui/1VLezSqZGLgqWaZqmw0sG4kHv
M7EDduvw1qO3FsjVVOtZJVOtq4JlF540H3LilM+AP5UbuI+yrRNJk6ueVir5rKW6mVUy1U2jIO/q
meSDxuRklFy5290BXtL5WU91J6tkqjtBWBZkw7Jque4KmxA8fofdO9RuhOZtbhI2uyKdaaUJIyWp
jYG98kfV69dKTxL5shyRD9ivPiqcEnYlOzI3iqY/WGpQLafhLkqWqV2PwQdGUJo44kjIaRYUtLnA
nnYvM2GgpQgfjEbnHWA4zcoFY1mtZALhZis/5Nu8uGsnVi969bkGLz8YShanycsPcw1efkiuwX5I
AMbXyBSgOgLTIhOYhA+GR7PRmHzyZD5TvhacAKLwiw0AHxWoHUbBlXdLdXuzKA4jOIhv8ShMPCrd
de7MOndWna+yYRnW1ZoVYpx2f8haFMQgEAumRTpJz62eJTTdhpYQNP2yryV6paHcdNHnJeLMCe4w
cgqVvMclcPBj507pJwliCc51+AUo55W0PCZIGgPDdU3cExD5pae6s2LCKrXFAiViY1i/+F2M7SFM
uEMM2TEk6joVoiOFTbVI5Yd2i0cN++GHH+rr1vPW/2vC41KdQozJgpwGH4VXaqvoto28F5vr7Jc3
bJlbD63DV2Hzl2r9uHF21twnpYfohc5gGq+pM6IvdjXep1Ou3UVrwEa7xUofgL8iy3XNKLwMHNeU
BoMJtHK6c3rQhrFLNAjcv9WMb626pNJADc7pGSpBz2EowPe6358ftBCvqSrsBTqwljMqtY+9/U5m
tXpGtXZ+tdWManun75rnmbXWMmq1Onvefmat9ZxarcxaGzkDy661mVHrsNnxWu+yR7aVU69zll1v
O6uXc+q9zKjXPM1ZIt2cxlqd48x6lxn1Om8b7beZtXoZtc5g2g4bmdX6mbN9nrNG/Bz8n2ejcZCD
kZxq9azNhvV+yamXtdsO9rJnrZ6113Bse2cXrWys1LM2HFY9O86pmLXnsGLz4KhxmF01c+PNr5q1
+5CGvWlm18vbfWftnPnI237n5zWvcwr/rGdWz9qFx40POJ9QoivZ/gO88UAVwZACPilx3T4P0krw
AcX9C4Mf0vpvqcZp0g0Rv0we+F0ULObDpeKkW08DXhWA4ShE7h9VhVFog/zQPNk7PQZqeoJJv7ni
GLbUds346OEXrBq4GJAG1tI1skMvCOeAUy2SXjLmJzLAVhJyDfp+x+N0jYRCFYVVIw7fQAt6YSpT
CF6vi9wav5IBnigGwRaYg3C8wrmpOAOsNMl3zkCIBhe813Deb6lBawEfSFNzetY5AJ7iAArVMl+f
cJZB4aYlXPJEA5Q6mjoNA8AwbFMTQcCG+hhwQwZgQ5WCdFyQcdoQGTzmh/DKQVuH7oRHbYkk3jkP
CYgazCginCg5i+n6m3tCbfHLbYyDH0zvpLaLAAyDz5xZhqZmt9IHCm/RbFyaCGjtN086HmZuAhZs
S2hXuHbCaobkGN6PdSkdkHsGhkysFm1iXahQ5jWxcf8mNoT6Y37hk9MOkivGY/CkRXttpblk+1Gf
y0zvyTNLFjSlEvLfQ7mUrpX58pclaRsMZAXho/qDIZ9StY7UfWIwae7rSeogco8UYslkipdxmJDs
B7mcvgQ86h2IhFKlJEsKUdIa0OQKG9h1vPnscwmzoXcBHvL1OA0iCREFqh8Sg7ZEsnILVqkLCB71
BeYri4ippw3kRSnZevP84Pj0xHtrBGmjkNIYPrd6/ZqRuR6qe0Rb1WtYZv+YBbC+pLYIi3rXfrev
wzCqvOaqXQyoc3Ds3d7e0pE0GXSjK7lIYm9aEU/Uza18AOs6+YGGJhiiysBQekQCUVkXxXbb5ZxL
ZatX84tSf+cX4yNJssk75zp5BVBUOD339Moge1oI0JvRirgcuDZiUOktuqPrqZX25I+UoCQvnuuK
ZD0KRX/VSn+DMLAvX37bKLD6UEXUzT0V9rPUK0P3a1usEwUYtpMdwgESDvvs5+kV//Y3vB6uDqLX
qvb3WLDfY8F+jwX7PRbsfWPBWgcXhZa7eHPU2uMHzn7zzcUh8Jh25Nf8clzD7E9XDpW9YrLcyT44
8ruf0/KjBQvFbhQK2/r1aLrYoSommfA3CJ4RP0cyAwocQ7RA9idzGj3xfmmen3jtdqd5Rvd2qCiu
lTPgchG7RKOZhHiBA/vsSxcZYvqZUlS7W6NfqrV6VmvT7mcMmQW0vXddDHDnDWylvbcC8GoKcBIq
JRj/nbPAcwE3P3RaJx11r8mtRB8H8F7zzAS8ngIsYj0UB0rb3QC6kQLKVfErKtYFUVDORCOZLcVA
skFamV7TTcT8SeVqH6PRzfRIRjN+r3LWOCJ5mpW6UxK0i7QAdZg5rK3sFtr3aKGdbmE7uwW841y0
BaxjtfAy1UI0CEQrjpmoyBik/q3fm9/gebrBenprKytRkc8E2+XqkrkNHB9fpBpI7+bLbl9mY7Au
Juc28Kax7x2fNYwG1K4+oFibGBwJeg+ydD40OMz2mkDnrO6upaH1L4tC239jQUvv31bnfOWscz53
pB0thquElt64rc4eQNurHtHfQ/63MR/4Xhq42qB4ZOlzT8Y1c48qutjZY4l9aEemw1GBgzTz43tN
/xkgpXHSPmp0mtxulOtXkszBUoEr3WZl+ANuQm/YyVuVblDHp7viyarjy8gOnGF+UON1soI8iu4Q
4QqIbUcUQOcoV/2vDHuz6wr9mR5q6kmuFbqjdDml08njbB5H3NWF/yICr17+W4i89W8r8iZDzRJ4
t7MFXtbocCH2u8z7Xeb9LvN+l3m/rcz79t2xd9w8xosUV76TeSWTshgf7FDzo9MtBPDdcfJu1X73
S/Iu4U8PnSwDeSjICPkuX4zj49apuKJmpTVADHWsbBfg4e9L6BbLixwbCTfeHTa8BE7ttmHf5MoC
HE7tdpXOFw2CCPCvdUbr2YukF2VnFdE9jFfi6B1G8acY+AKy3dYLC1TZUZW3YATW15tow7Jtmq2Y
rb4wQJXdNec08ubi4KB57tnDSbX9wgZazoZRrMkzu01nV164oKfbPivaOE5H4wz2klpXA7/nytEg
SsnFVa/Zq+us9UYH4qeAUAFjcRr1Dw/eq6HLNXbIlkEq0BacUVisSKOAdGZ812kZe5B86Q7OG8dN
j6NI+bLAtuGeVpezwcDKD0K1jk7fe7g3OFsNXWdkNPmFNozD04cqwWA1Dr12u0aBB+DhJVp9p4q3
Tgm/qvg6MeXiobuK2k+iygZ1y7/q9u7IG8ld6y2cMcloareblJsQDnx7NITIE0rNeOnjZS2xIIB3
aQYtvJf0Fk7eAYLVvHAyihGOyqkiYp6TOX+BzLSLsPAK3Dey3Tok5Gxu1NZfrvvrGxvb8O82DuHZ
2xas8dbZwTPdmJ7nj6QslRQo2B3ELCu/AH6nO1DnvXP+OfQnvCFEEQhRWVxg4qW/gbi0CuLKN5WX
eGJTEHzj/EvCVtz9PGO/dkfd6+60y36+k9+6U4x1QDYzvZD9fUKCk0t4f9dgR1SsTV4WMQx+AsP/
pfrL91yT32Wt77LWd1nrW8ta7ca7ZhFJyyqnG9VUqyvwX0Lyn6VfapmDnwnugjre1uK8MDSU8qMd
duWP/YioCnrDXIbc65bnoEZqVGVqWGjttb2JtCJGJmh9bbu+Cr8Nfw7o/EHrCM1hD4nHAnZsfW1z
vb7+cnWw6W8CG3FxxPWozz7AmYZjfOaGINJR6snJ+KfOjUUF34FpuekI4QNKaYMpVrap1MW0cMJ/
1epvKsSzFoZZq32ASf8GYTTqTlOBmFVVShTnYyh1veq7xNUeHW144rguBlbgNqvB0HeAknl9jF6Q
8ftHQE/908cf/e7tJxaO5dwhRZQBDhIvqf0m7DWQpNQS6/x61iy9bTZgZ1Yw9L8bpzJyCT+Zzy6e
GMG2sfD1F65oxmg59gTAJ+Bhx77uZnUBgFbYqtG+BrJ4++kI8viEPvAltwvvzoCarjm7AFWNLvC0
4SIyiD/u8YP+ptubBOzVa3YThHF3EvTo+5C+ih6L+uZDV4O8QAqVwTi+6SVxFZNVipm30EDyr3/9
K/oUzoZiOV36YnEBzwCjSKptQ63b6WTXfDLpDikDvCdCnqRe9z+qyMUZWDwiOarC1t2Y5ANDbPIo
SYSP2Vgd3t3hHQVPull+jVSsGkT/8Mb+F+gQ8TIYUrtoFVUAatU0GsanAH0R1axgUCaMzDTCPzeU
d5ejDXg/coW70UJsZU4auTempkwFttUejZLYTPIhhoTyHIWTmchBeqd1DGfdhhvl2C2OcGHOP+zN
+EXd8uub6agK/0/yVyzREjqN5CpKXtJawn/u2NAn2qBM6D1ge4el8l85D4gOoFSP5wAFGU4FIMPK
+AZznwIWSuVqRpO8arEWFYhQgbj0KecO1ozR7H829EUNXTSA7Wm9lfX7YTW1YMSmfmJa4r8TigPv
5OLYO2ud8PvldRldpROKMFrvOst9WEB9mQOEzlCAiSC9CBa3uCgUeReGyLJfXZNpCUyiSjGEpss3
1A8eH+MLetDfkIu7A5gQWEHW6fZ55lM+hlSDKyocsQuIvaQxRF92OGJBKxyhFOUrkabojhLYMLbD
jHi9opDIw1EXj3dY3VFIQYJFN53F7kKTcNiN0EMhD5JobjW30BT9tHmnk0LpYmTTn3xyG1xThbac
sGQ6Eiv+NbytbxICkGrIGOVfgX3wh/3YjsBnkAN5OLmO6SiyyQ8+jfWnlKgCn4bouOwPHa/gmHCA
ATENO8uTnbgKoBLNE3p+pSPKWJSYpwV+TC+HH1M7cM4BJYpX2KabXAr8lKkLyfbHw50rCI55cmPz
9Kb3jnyc2s7IyEQmETcZ1buwjuOd+ibmkjg7hp/Ndx3vzdEvVfrR7rR3GF/oSVIm3QohDc4fIzTm
BNc82WE825gb2ldrvfEMJTdT73L4WYt6bLyejiKP8m7z2K/HXuf4nFrEf981jmCrr15S4iLfX45m
4zEX3Gdj2Xj2siXmymLtEpwzGfEwZ+Ibe2etCttyzzqCElzJbNLH05EO5Cs601FXAAfRbCLSWicB
Sni3jINCczjaSfl56Q5YFXSQAshbnOa/l849vZWY1TfXXm7u9Fdfrm0MXvZW61sDrHnrj0msWwYG
1B9Wr68qdotaHCSRRiTm0QRUoxuVrVSvhOOgFpVFQ40s7MnCHKACD10eJY6HwHglcJyoTsGr4MHW
i3wRdIFrWiidDZxqn31/AjPCXZ+4RCV1LKQSxcMxkDF4Ug3b6EnUMS0Mn0v58cYAtJfEnOOh7Srm
QJQfluimlW4ob3gpOqsJk7DYNP8xo5Tw4xKlinqPpeGg11fSmu37Vc3fdOmpNzdg7riDEW7N9V2K
HShcDlPbQfa3OMANDeDGYwDc0gCmt4ZCkJuonJ51vINmo3MBb8gnsdXBrO5nZ6gfqrDtYjtARQbl
Ki9ULcdATGErLxPLCEtzFktpRdeTUEf2TvdRffFBTPP2nMsTQ7X0J7w6iYPQH82KXZzIst/Cymz1
G9+aqGHew8rsu1vV92uP79ce3689fje3qnbrtHl8Mc+pSi/FXarogYwD3NPDhjzhoT9lqGMKoUVr
cBSMKWhnRCGtDt5zt+I9mCgBX1iMUQP71JVYRUnGkOjcn4M7NGGagu1XwaTCopevQCzo8nbl7QEF
Vu7jXlpGudayRZPDSdrHiDXw5U1jD0OF1GSYhoMA97sg6WzwhQKtBSoLLZc/SK02CKIRbTDRr7kt
osGHd/AeW5POYhhFVwSApLgMInrvPFCN/X0yhHr7axsYHAQoTf/Rg+ALYKI3DAF7KCLNg0XeA63j
JkKRIaEPhjPAgcv7IFX94Oii/RYwufeWIGxp/YCT6h+kSZgL47z5fymYGUKQ6rpzCvpNeXXVcpgH
SE6od94ENpCuq16q1UXqKQyKqBzE5oHbbx613qHNGZAXANU1d4JaoyCHxModjE+rdBYrUfeNNJhl
HmeT8pQInRmml3T1ZO+N4UOGl28yyg53fhLxQ7u9XtqFI4EBKwW+ke+GvtKhk62zFkVkEZF0MW5P
t8+ytw8Ae9/4pXlx5r3bO7swFjI5eiUSL0pzt35vNs0ZG9SgmKRtMp3jS9gdxkAw7nxTavkSzHym
bbomcGUnykjBlJV+KStrmJVrozt1v4i23Y9fuh/XaxnPE40mXjDK1UahUf3cAfa6wEs5gQLL6G4N
XtSzXqxmvVhzvvAm3f5qkgLSGtWqUAwVCm+Rdyw9REJR9CRHMknKFJFILueA6Mx8DqIOUHbWtnZq
L3UQKKesbVa22Av6C4IKZuL4G7kvexTG9tUrdgqbiw6hZXUIc/9mKED8O3DtJxfABOE1Tzj2y9Un
tEIYv1YDIauCNgM7yVpKcvRK7T1pIV5w44L5BZnc1JLwoiDu8YL2pwb9YBLwQTcYxt2BdtB/ufZF
kCbSq+KbMUYAvaQU2TwNE4hBH/xx9SEz3w9Hvekwb95liXvPugJQZM5frlbqazDr8O8mTDvLcx/j
gPnNW4J6LLp/etxonQBLA5RZEEmOSjLm//lnL69Q+QlzpJoWjfGExKRv/dcTpX+GjShSVykXPybC
0RjNLOlRiDyucfEMrVgC5nKyK1VjowlZrQLLSAFmeTBoCstq6dSS2qPu7cgf7UqrXhy7jJMuvBVw
CR/vd3SiaQO5jQPvpktA0B4kFZrW8qa0QJHWXZ2AXjAacaRwj1H4SV1AwKmIewhC3tVdT6YUb9cb
hkB5OUKO4Cui493bsw7FrK1qhPIJ++qeMfRHLLKg9BplqEIrc2Nru7JaZy82tup8ZWavEYyAhDwD
v5Mv1KRZZSraZUL3hemiVPw6LaYeIbArAg4nBgNi1e11jugyW1fBa4phrXW71L9ojcqA5iW5UMuG
+tIZxQy+D+gwG8a+OqqPKceSsMQGau2PJtO7HdQeIEHjlircPIiMjPxhH3iJkf80rTGmRADqsMxM
C58xrOxXcz1Vs6op0xsmpgmFtSkqolQcaGOO+PmTniNRBV7iWtt+Wcejb3vzJZ196aEh7bHoHUKa
BGMMWO6RoIL5EIwDZ73urITNW8tPr7TqrHSVX0lLDpCzGM3P+vqTF/eohMg8vcTg41OeQYNfAemH
sQZtite8PF+GJyyldGgbmRgSE+T4rG86K4HkkNUMVtqiiX65QTzOy7V1TlOcEy0/6QUehKjkUncG
SDSNJ7t5ldOLJfUkt356+q0n2h3t/L3JmPUkt+30jCRP8ivOLjFo/2UyH+pJbr0kIKv8yCe792a9
0EwWLRX+kcd9aYXuzYDpMArwYNurldV1oD6rxprkXlF4/Id02wcL8yvPiPumqgWwNxJoyEQs45Bd
0eUkpuAEER3Nn3iOD9ymFgG3G7J+0yGeeT7JlLlB6Ak3rn9ZDAnB4JdBtoUAadX8lEEJqtY8OHDs
59CATDeAz+lWeAn6+I+Z5iikfN5OPemwt9/EoDTHjfNfoVaNHLxk0qhX6Ix2UDP0A1bVdnPv9GQf
K9fTVbcyq1J+QjRDocW7qjClsDtR86of8hoi4etHF0Dd4HPbkxA/1j+lBNvUfHEFERPHJ9pAYNK5
aRQOV5okMynjD0oWQ5F76SJwKu6Cerz0UFhDMoIjjZ5Fegwe3dU7a6D/GLbhtU7PTs87be/odK+B
eubqg7YwcePxvD0sSz1oEysgBXbxxjoJUvAPF5/1q1mOC5jI1ilqGs8OTthmbonmu87e2xO2uim2
nim+mPe+vCp31zvYp+W25SqBvLv0EcSLYWfzZ6qHP7zkd8dDc+OvbW/iQvrtN+0hSNQepwcv/rJI
aS6PN3nWsndBFPQDqR3FnCQxv+CCZYfJPElU/KvBZ2hja5239luNExr9ywctr3medov512UuLQGi
wMKq11Yr2+wF/iMkdJfxQRMvyGq6iQGid7HpMFxH6GIcXlreJfZ6kAdBuq7ljfgM4FuVu9Eoo114
k6oKAs595zUIV9DWJcRUQHlza5a79/xaYArM8epGpb7BXuA/q0Q9TBYXr1rOTzunXuNNy/sAE7bG
bVOf3dL35e5l8GxOjc31pMbmOq+xnFmD+Hr+eUZGZnNaaJzLbLsY6HckimesP3jMsgCdwAHxrpk1
6PQS0lfvvYBuruct6oVBIuJyFvrC8ACxD138n/EeJG/ViwL3Xu6yfoF1/nKr8hLEr61MjQ7B8oKR
4HgXo1/EFZlXKsh8Yijwj780PzT3SNdwwiM0oGkwk3qNHO2LdX3gU3o4tMQSfFqiHXG0H4x5ektg
jzzsy66rEN3mJsbOQpumYQJZcDoJ1pC5eFFfq3M1RSb+MIi3LsnmfpbwmEWtYIDhSgNMUgAsXBck
PGR/QMhvHrQKgxKmpcJVQRi8XM8w77zfF7eOhYHxZAw8O1wIojbKytKPTfaOqx4UJePTfN44OUQz
OO/N6WmHswhsnedyN7Nh02U6l6USZcgcGFL5sZMLrTDur307s6HB41idgbkQEQ/YxrwBFe2CsNfB
kJTHXGV9zJP93ZfiwKM8ekOv701teO0iVxt1ZJvWuPb4IcyQ4oSo6WJMkOF1W4DxkVyPxuz8f23Y
G8bt5BEA


--=-Sfh9NpehBPpgCCvRbkpp
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--=-Sfh9NpehBPpgCCvRbkpp--


From xen-devel-bounces@lists.xen.org Tue Sep 11 10:49:10 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 2012 10:49:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TBO1a-00051p-18; Tue, 11 Sep 2012 10:48: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 1TBO1Y-00051d-8j
	for xen-devel@lists.xen.org; Tue, 11 Sep 2012 10:48:57 +0000
Received: from [85.158.143.35:38284] by server-2.bemta-4.messagelabs.com id
	B4/A6-21239-7171F405; Tue, 11 Sep 2012 10:48:55 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1347360489!12549349!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDg1NjI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30450 invoked from network); 11 Sep 2012 10:48:10 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Sep 2012 10:48:10 -0000
X-IronPort-AV: E=Sophos;i="4.80,404,1344211200"; 
	d="gz'50?scan'50,208,50";a="14466528"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Sep 2012 10: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.279.1;
	Tue, 11 Sep 2012 11:48:04 +0100
Message-ID: <1347360482.5305.143.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: xen-devel <xen-devel@lists.xen.org>
Date: Tue, 11 Sep 2012 11:48:02 +0100
Organization: Citrix Systems, Inc.
Content-Type: multipart/mixed; boundary="=-Sfh9NpehBPpgCCvRbkpp"
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Subject: [Xen-devel] [PATCH] tools: drop ia64 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

--=-Sfh9NpehBPpgCCvRbkpp
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit

Removed support from libxc and mini-os.

This also took me under xen/include/public via various symlinks.

Dropped tools/debugger/xenitp entirely, it was described upon commit as:
"Xenitp is a low-level debugger for ia64" and doesn't appear to be
linked into the build anywhere.

 99 files changed, 14 insertions(+), 32361 deletions(-)

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

Patch is compressed and attached because it is 1.2M in size
uncompressed.

--=-Sfh9NpehBPpgCCvRbkpp
Content-Type: application/x-gzip; name="tools-drop-ia64.patch.gz"
Content-Disposition: attachment; filename="tools-drop-ia64.patch.gz"
Content-Transfer-Encoding: base64

H4sICEkHT1AAA3Rvb2xzLWRyb3AtaWE2NC5wYXRjaADsXHlX40iS/xs+RQxV3W0XsmzZYLAp6rUx
BtQNmLVMV9fOm9HIUgpr0VU6OLq3v/tGpCRLtmUDdczbfUsdWMqMOyMz45fCegNnp6BPNfeGhSwC
X4v06eYbuA5ZALLmQl9z/AmzbXhvaa6op3c/61YUWA+i7jkfkPpYixhIrZ291m672exArdVuNLD9
0jMYyMfQ2dP1Xa2zo0uTlrG3M9nd7ezu652GttvYaTb2Ozu7erPFzH1kudIC5kYArKntmzvYarR3
9HanrbUlg+n7+ybbZ1Jnr91pdbQ9qdPajDzPDrtgBJ4PltbegTD2fS+IxM3NEXO8O2ZkLWAGngO2
NXnQQXMNcCzXqnkhEo6nVgiaHXqA0m7BYRC7Bgbggbl1y9Xt2GB1P57Ylg53lgZ3WmB5cQjho2Nb
7i1JOEb1Pqri1tQNNolvblhQRwFW5AN6ZAXMfhTAiuBeC8FgoR5YE2SIfc8FDKODPVrY3dz6PWEh
g8D27ms2u2M2ZBLB9ALu5hZ3wfBY6P6EnKhcC1A7TNgm2YSSLRdvoymDSWzZBpI/3k9ZwNBY6HTA
tGwWpgNvCCDtID2OeWR5bljZrgrQarbaEuq1WdJWq25uKtaNy4yaZ5q1yWP3ufmxaVimCbVgbkzp
vpgWwB6iQAvr6aDU+55rWjeic7tZq9VAq6/q3rjA+CnMB6kB0l63udtttqHZkJqw3ZAwCbe3t2Gy
mnscs4RbQgHd1l630Sly//wz1DrCHmzTD7xhDzyRfh9cqvLleDA66fUH6m+DkSIPLzdhE97AOHik
YTAtHB0vjvgAaIE+tSKmR3HAwNQcy36EcW90OhirvVH/TD3pXYjEe2IFYYRjwvRbwLFCVkzB/bYq
iiLlg+65kWbhAECFsoB6Wk0h/XxMLto7VXGz9gZkE1wvoiaywIU4ZPC2QnYXFFeh9mGWUAKgms3t
57JugmWyz1B5WyFXQxxt94ZbICzTVgXqQJYFp+GQODaB2SH7oiShwNbJ+PqFdssopcuzZZnuOWmD
0/iu7sa2vTGexvALJntDgkajy/8BLkINJG6kWSIJ7RbeCg1MExwAGgPFZ7ql2eCkOmehFjnBZo3i
NBoOxxiHt5X+9ehYHlXrojj7t1lLF580/kRbLc6MnCBhKe0i53nTPC3FBhe/hJaPiDLqK9A9hFCz
Rb3Ytn0I6MBSW2Q5bKnRuotEZaHNvF9qohXPc58n0nGWmvhyuNQa4tQxllpxDSZtS+2qGjueYVit
JeOwx7DuynvyjrRrePTLLGpesS2N2mIbd3GxkaK22IZRW2xKo/YskejxYlMStcXWJGqLrVnUFtvz
qJX0pMEp7wlLe8pYujQfNMPwAwzgA15jq8onBy4uM7JqlcbgFOfF8OSERoj4bpir4vZEg5319JSL
Yk+Y95wBJLou5Eu5NlTSCZbt+Kku+bJfrSMnlkehOCWdmm13i1alhOfyETfpbaWgukqUBSORYgMn
ex/XXgVqHrz9meb+1dXJee9UqcLb9/MSzub4SR7yh7gF1FwGW/V/1j7U4c+wjh9vDAwWNtYPwP9r
C96jKPiA4hN5ZbYWJeNeUAztvHdng96xmnUmDvRGVQjuoCBtjp+U6jbT3C5SBw7UzBXxeonWTM5C
NBabcW/6ur2kOMnX7yY55XfYT6QdKd9QRL6BbM0UhlsU4nod3p4EjB0px10IA70ePoZ1LHBvWeAu
WijcgSRKaFOjUZca9cYO2bnb6jZaYJgBDB58eMslAv/Z9/zHwLqZRlDRq5xLANmNsBTtewEWQRpV
hZyyh8UfpwwhQAwRYMUtUkcqxsXSYBJHmLLNurRbJ0kweYQLrKGxhEZhLtME+MWbunCmBYEVeq4A
ffyMLFcD2QsMDRcoIbFqjGJ+jSdaeIs8R94EEQYWHgKvhRWsZbGYizyswDyTF159z/HjiJuK+7Di
mdE9wgs41yapvCWPcss/9kaj3uX4ExzLSv+8J18MRrO+8ZmsgDI8GSPRAPD6ajT8TT4eHMPRJ+wc
QH949Wkkn56N4Wx4foz1IfQuj7H1cjySj67Hw5HC5Wz1FOTe4p29y08w+P1qNFAUGI5Avrg6l1Fg
aoY8UDD+l/3z62P58hR9vx7DJVYOXMy5fCGPkXY8FLj2ZV4YngA60D/D296RfC6jX6T0RB5fksKT
4SgZS7jqjcZy//q8N4Kr69HVUBkA+TgLwrGIZqBqGPw2uByDctY7Pweqhc+51WMlTZ+Cq3A0QBN7
R+cD0sMdxSk+6I/Jo/yqjwFE684FUK4GfRkvuKTB7wN0pzf6JJAClKsM/uMaCZEAjnsXvVP0rlIS
mUJQuBwcIiyxBhdkNUZDuT5SxvL4ejyA0+HwmMdcGYx+k/sD5QDOhwqP2bUyEFDLuMeVZ3IwakiD
DUfXiszjx8HA6PpqjDigimP+EaODxvaQ/5gHenjJ/cbRGY4+cTkonYLCx0KAj2cD7BtRbHnoehQT
BUPYH+dkpBIDOi74y0VdDk7PZVz++gOiGJKgj7IyqOLIyWjgKUkl7R97KOKau09pgsYll3KSjVlC
C3xsQT6B3vFvMnmQMmA2KHJmCoWwf5YOQT5tlmYUIRcOguJoivUvn5kczBgsmbcB+xyzMCIqDZGs
bXM5fuBNbOZgLyGuEJA1Aas5/YQhsp8gcI448CZsbSDM1iOEV1rEpUyjyO/WaeFltuezQLTIPIKl
dbx1Qy8OdJYaj4tsiMxkshjhko/3aIQ+q1GwZBc1GxEwQmO8vLG9CS4q5b1ceXunNkGbQg6aCY4z
AvBIbhmMSDLWLt38CaJjWZs1oAig1qAlHWqB6Juh0BQa9Jf6XM8XLSheHhxs1v4C4nYskgOQaD6S
cXLKp5c4epScp5hbxzKtUTgbT+VLBTBJBgkDFjZYFlk3YO4fBmR9samDTa1SfeYka3YSi0wdq9gH
E8z2obmf9U2o7ymGvUOzU2Ao6LAWWChNI9xmK1I1vX1sIHySoA4TDDEkis1A9zUxlPBW8NGatmDu
lfuwUn4zk88S+TWU/46UkRJubMVvV8F0nURR59DcE1CdKc2N01NqWpmaz6RGy1VIjVxHqkJqcE9Q
R3kCrNayM3NGQi3o0Tv6wdVIy2okHA2B/jVe5MruzBVSgv5sJ5o+r3UI1UgNIe19gUvt2fiTtseZ
tjR8+0vK9rkuDN7+CzXtzfxqkl8SaZLIL2kxF/JUkKQvdGt/5hYpe5wpe5RWu0XKvsCvTqYqaPLU
SzIcnVwcLbcwXHs8MdovVCU1ZjFsUQyxKiat78jL1W41uFudcl2La0mua7YyfEZVURC7OlQ+J/OM
Lzjmg8hbMz3FpWp+NU2kxF5k0ZH0vYWFLu45aHCwDxXLxHj97RAS126yBTMoSnSWl+rnrdGDy+N8
hebmLPpbuJwEYsAiMfSjW5jkWkTmGv5sf/pqTBQ/HxTF3xUVNUtQUfxiWBS/4qJXXPSKi15x0Ssu
+mJcFK8HRqXdRWQUu2uwUfytwNFsC13CR9eX/26ElFY3BJCwOCxU2GthUsq1l1TL81yvWOkVK71i
pVes9EKsRDApB0gL+Cj+3wSQVi3S3xIixd8QI4XPx0jh98JIzZ0VGCl8MUYKc4wk7ic4abfekOot
vGyhqd0mzjbHz3ASCa69AqVXoPQKlF6B0v97oMRFtJpPgZ0ingrX46ml7gwqhd/sOZI1X5qkuzF6
8SLIhCw3zGUBWh6wG1yM0eM4ZEY37cQ/iKSwkFofHtco0reeoA+9oEC+v4YaN5rYjgrEZEqoB/Tr
zzOD027T9jAR3Zua7yH7rDdM/EE0JyA2Ewg/pRUuzz5mWDr9WvQiud9OAvTHQ7RDIcgAZXrfIjRZ
qLIm82CzvYw/94r4cz0iLD6ha8/lwVMMiD05KnS8u6QGbjw0TNMwFpVxsxjWAmYHiYLmrNysItr4
ariJSLMI/pYq4XYZ6FsrsFVdBK3LtfxeGVx9wtCd6jK0KzMXBbeF540Fid2tzsPSbWj+s9baWZKc
mLy3EhGUyUb2JdRWhjWWTX5C8N4c0mg+B2ksPdheiTRoZ7CZFibP2S0TJx0S4MqC0z6kzeJbQJEn
Fr9vDUXCbwFF8t9tfRKKZKTfA4rslkKRVOMLoEhmI4ciLcITrXoDAQEhkq6028WLUJ/eM+t2+vrM
5hWKvEKRVyjyCkXmoEh2qLaiHnY0i77zNodHkkV3JR4p6+Z4JOl4Co+01uGRYgH8xIEgToQeTj68
+nIUsv6JlGsIoKP92KHhUNne/SIqWcePqGTGPlli31/DPYdSXgRDBDqCph8S/cjK8KdRSQ4rJI5M
ONvUsw36OiKWW5llphc4L4MhfCgiaNJ0cXycDlTI4QxKAE48SbBPQ0ilJMgjNrNCOfHheXgl5cow
y0sO3/9dT8q++BHWCx6Tfc3TuBc9Kfvqh1gveGD25U/lXp+U/R9+Ukbr395hbeE0ZLbmfM+nZ2WQ
9kuens2krhHbrELAw7YNldqkSpGjvge01U6kcVQ/txgWhFqT1fi2sL0mv2zwgn11CeBaZQDXeh7A
TYqDrwS4sy+1rge3Kdl3ALadHNamX13s86/w0RcKazi6D8yoBVTjHZrNmrlLY1YzJfxs0WdzD4l0
zw0jzY1qN/68iG0UMWymbT0ll/sAWhgyB4vJoHZvRdOa7vsLZNvPVW96WG3WzEBzWFJRUO23JMp0
vRq9PwALj+Qm+Qpqck3f+tajGhZ/Wkhf/15wKRV3fpyIQ2mIWN1UAnZ/XQbk3yBenwIZ3XfIgWa7
nWdB/R0m/zs49hC4Tx7h2GKRowVwpk1deG8kd+IU73424/+yojCuhRYVQWHykgTkpf/f8E8mEkZY
9IXJyQUBAsIp9J1+HNEEM/CWieVqwSOv60IBKLkIptCnF0dcDM5bfrxGQhDtBAwQhKSIBQED1clG
gnsIIpkelvv3lBWYE4bF3yHBxRCjw6Iuv5HEBev4kV1qFsEqcOKQal168UECvSbeHXWlJzpcCtD6
E1k6gjCOx2wUSHJyzdzFebNQq25rloNAigtpLpuCKgthyUxBX40YzftO1qSHmpkow9NjKpW1bOzq
BDz5qyEcLOQDS7PDPPx83Ehy0RFxlglPnvX0rsdn/Fhj/oAH/vUvfrrz00/UxUV92RHPwukOl/RF
JzylpzuJYQsnPCVHPAVPk2OYkuMdLutlRzzrjneSteF5RzxPHe9wWc844nn6dIdLeuqE5/mnO1xc
gXT5iOclxzuJm6VHPC893uGi5o94vt9ye6XRGQ8tc5F2y9zkrUPp+fZMMT+j2ay9yd7J8T7buLxQ
nH4o64gefbaqz7YmK3p87YYtdNFLjfD/KobAusNabpmFDjAmmn67go/2WlX34xXdU7Q+4EchKwjY
HS5yq/yjssKzFx2ZRYZef1HehYUznTrxXv6oAec0rp+OF9CqzYXCxPMi3JHCEEMVinxo6HyFmu9Y
MPFCdpCwJksoLem4tsbJ23zSd/JQEw57zTNrhvaIS7jpCRDG+hQLNqAxiLQJqdJw302LLSHZDQ0j
QNXZIX84xbwxVOLPlQjpfoH7BO0mt4zvsmKaRrFLGwNXz/nU8gbuQ0G8GsG7s09XtIQow5FaVHwI
lQXC6u+KrB71lEEihRuG24+OJjHVvM8uT+5P01AlYUo9pVNTHI8ItyrrD366lbwFR8m3q4Uw8CHx
NaxNs5JBw9uQ3nuBpVVGYXuagbs3j0JqEyaqyjOR+lUu4R0sNFwVnShh4PRHeHtFd+SRjtHgGlXd
MVQbPf17f3hxgSuleo6rqqrI/znYlv5xkOTYnWcZmEIk9D6wIqZaUaBaFd7g4230DvDjSoAYo9Nq
qvwoL7lDigjuehgMzI6NDcgb/bBA4d/iyv0nUvBAM7izgijW7CyKSUQ2VFULHQRcd56NxYPNKluO
d7ehB6Jlaoc/NLag24WtYKvC9VWrB7k8SlgIcayeEhRZAUo6OJjJqvghvH8Pcg/tlMfySL1Sqv9d
8W/nG38dfKrOFF7FEcUjeV0ZziQ+LpTBWM+7oZ3UPdlxJbkGpSZhkEVrA3/+/YfGPw5/kGYmIWtV
4FfvKlkE31VpBGYmKLyMsv5IdK3wOQzsP0Rrq5rh2WSYHc3HrLFVqlUr1JSOTD7a5BzPjA3KtZBF
ajpcqh9iXuiVBjfDYQ72VX5EagEaAg+/Z1bwFs3c4IHC0pPvKjRCUTo2eCGSGp+O+pCOU/r07JKW
MCuap3I0JLsaD9SLnvrx6CChRs30mFGL0oeb8yxaUbCm6yyZhYuSjSKZgQ4+LtP4dqr96hxTYHR5
kBpr3WGAb+gxPr3pbl57kLL0Ruro4+8HBSuy57TzKnyXlq/ZQFdxCH2tkq9PYjIwGH1ai6tV+PAB
pJ2DgghGrjQyV9iDznyeFgYzWUAPEpK9e4P2gw1cnC4IFfhxgA7Q6/VgwnSN4JUGVqTXjUjPV7kQ
sXY2SRNmBzeL/PcYInvyN95ezzNIV+2V5gtJNBVVav/Kk2hp0UnSic+8MU5G/hwSHYM8QCtlJ4S5
glQMzl11NDjd4/pWZLQ0myQYQdlN3gnGvUKUzgIX+IKalwRqVlukKzPOOB2S+ZVN/H5KUZxj6RKe
MauzJzy8loBDJCGyDZFKJxzUPtb+R73+r2Pc9lROw50Us80HE2f2BMb23JvqjyUmEstf5Hth85xZ
4PmVTMnwamaPAD9ybbOozHlIO6Oa79aVwsaNOwWP8KwlX/bpPXaYYoQ8Z7XDjKxQn/BUyntEN1Bp
dSdn50XXPmRdB/Mc85XBIlOhd4HPtLWbMjW8fVFHhAWZ6phumYasr5SH3UX61N1YxZZ0L3Bm1aTh
OddiudJFknUSEh083fDPWkml5vgRn3AlVqQ9B8tDGKn84C4scbzYvcCJjqj8NGKZK+ta5PCMhKyM
Jesr4bFZWVTTntXTIC/CwsXNNC/I6LzMwYqYF2KoZbG8o5jnBAfL/My01PARtU9KufPuFby4YeK2
v5I36V7Lq/Liar0ATrNaCr1BlpNsrBEzI3pCDuKckPa4NIfXy0uJS0SmuZ6maexgVWSHq4WWkj9H
bODdv0QskT8l1sNqQn14ptCE+FkiH18i8rFEpOmH91ppqvCeEg6aSUE+bZcZiwRr+FelaKG/hBvX
uf9h78/727iRxHH4b/rzvAhE2WRImZJ5ibqi7FCXzY2uJSknmYy//WuSTYljXtNN6shM9rU/dQBo
oBtNUbI9u/tZK7FEAoVCoVAACkChCvbDS2o3AZaUz6rdyN+39DA08qONMkBGQbyNlJOBwMlgU4Iu
QnQyPYKlc4L2NdLlLhojxJt+3LX2p6rMm1hFtzaCpq5uZfDmAhbiSW/2mCiDEpFHHWi9ADsMP79k
foOtS2qrSZif2I6KDVH+AAz8019Lf1J8Emfo3Bqd0BrNlJvF4QA2/fMQ/k+2b80AXkOfm7mcySVU
+13zOaqFU1yIAh8VEYfeprfeBpiAzwOmFz9tAhlQA7lbRuXz8qpz6tG5K+xgrkgP3VegOH0lIC8v
dO7sZhZO57Q3KONmFPVadBZ5VRD/FHZSI510DEm8IaefvN5CmUDnDQeU3OpYVZ454Gh/Y1HRYgki
6j8GMI/Y+ndCBTVZ/T2WSexT8T7Mw5Fr6ZdiPRrKTsEZHg/SIHE+lis69iYehRmHN9w3KC1GIglF
GEDlE5mf1GmHBSPDXOXNdCBBfbe21QoGZSWCRGpGct+CGXTIdlWIacRG3YAgYsPy38/HsN+jHQHs
OSfzj/m1k9PmRhuW+mDcAYg98V1/k/6HXvmuv0f/rxWNrpqPN4/9xyL+PZ9O5rf06dfADxNA76aL
kKGGkwXuwOBjO8ALIEkcUQeJWO1f8Mbw4EAAMd71BV0mnDZPjr1O8/zkL5cXJ8RdTTJUgIV+x0Lo
pjtCJ9ODYdD/5q8TOpzI5cidtqMMVoRtFNCGEW6e90Tp4bsHKCc3e5p+BV2ULSZoQv4HOesWJhMt
JhfEwIfdfF8Sg+5Zkzs4mZ6cIAxJUAeFxtxiSPEAQMzpBA+tLo8vaR5LwhKNLIOmPjnB08u/oVne
eDiZhlLm8CPUaYwqnKKkuoMOuN+ftNRXmPf52AbRQCEujIcJ9X2N6/sD8V+lh4H8oUMGybPWYjLB
az+YtH4BVVkilQKIHWLRhzV9CxJTMjBI+afjBLoztU5sBXXtSPWt7Fn3rq6w70BLR4CgPHUDAzul
PolZ7dcsvHKThIsPAdCyvJjI62SBLX8CI2OwkJ43jt7BgmeeHqtD/VUoTW7ysghWONUdAaJZSrBj
z0ddGEz6wwFNTbjWwk4ooTKIH+mFSjy0UP5u0EAYYWi7Y/0AEREJi41GjplPM6/QHtaXW1dIsC/x
cqS+YxpXiC9wXfdCYw1903dMUTzoeHAvx7FHeDbuoRI6VwczkmtUJJe7wr6N2Bc7XRSFYx4DeL0v
esDmWyxoFFr9VvFz8+cKDTyiSFq+4/EmMOsm9CdzjBkygNppzMHkcINrxRSDjKBVSITN6eLFGE5y
fExFCJXFfKSer6Bm7kfRtDf00Y7EtnbgGCV55OGaevCyVsCKCFk/8Efq6FS/h5EWK2g6TdZJNFfz
vSDSorJHw/FQ1qKMLeR5MrRigUerSHORjV7wb0BNpCAwEaz72r4iwHs+jAwDwsE3dW/oEeq6iDAq
CmAZBvpeS1Epb/Sm0oJGsozqvr+FfrVaNGTJGYB2BVXz84D+FFhINf8tAFVaBnpx2dywnY28ukwZ
rEhLFXXBGDFB3OMyC6Z+9diOLlfx/o5v5YzmhUgKWX5hwAt85aBsecymbBq0vDtxG6LIZ0RF8XOz
8w5v//XbpctTsgz4qXlxXDRNT0wjEsPoxGFZQbUuNTMpMranDE3ISOLi8qJ5cdqCqshSw/WWCOtj
oxSyNmmzWUjyOVX6SREZrxS1vYiylBBJAwvDFqMB/x+hUQe2KjbMIPsL09KiqC0tuKWtS6hIWllc
KquOixNGhX1gdxWadChbDIuq45MGbD7fooGJVWJTWztk2jronSNZD/LlwDop9Xcg3NPQm+BZ5m+4
nUXtbe39u6uO6MS3g2tFvqsp8VZ2rWlcInbODlV2WWYf+3Nfp2NGRWY0Rng5ga8jHBgArpqCs1AB
RM2s4gJmIBgtRvaWg8CfYGt3DiNOwdRNFMnMbZWJF2wbh8O5bsOOA3WD7skUGADtmrjtXGKQYuBh
GPgfTSZoCMXDE7rHgaGOT6TCcDGLkShutuT7SVGuairL1VRmLc6spTK34sytVGY9zqynMrfjzO1U
5k6cuZPK3I0zFb+uUBm+gM3WFV+sqrZWFMOwn+K1UmeXMztFtGixkf1SqaQ7xoAgEMW5t/I504m6
mNQQWviGEe6D++L0aqMlN18aSLHxwu/ge9ZoMbaRKE5i7KKFMbwoM8XJSszJiuLkMSo2cbLi4fWE
3ohBoRZepAaTXqAqrZY0jIzUFvR5aFmgCKk4emq/hTr1FyPdK9WKGwhmjJmGUew8m94H4caVvoOm
aQUqVdAIqxjbIcXrECB6tzY2xdU21DYK+CmCBZAS0GosoNUUW6sxW6spAa3GAlrdTWbWSjqzVkpl
luPMciqzEmemhnAtHsK11BCuxUO4pljVbGxAN6RktLZl5dPkgSA6v57ONyeXWopVtZhVtRSrajGr
ailWbcWs2kqxaitm1VaKVVsxq7ZSrNqKWbWVYtVWzKqt1Gy3Fc92W6nZbiue7bZSwrQVC9NWikNb
MYe2Uhzaijm0leJQPeZQPcWhesyheopD9ZhD9RSH6jGH6ikO1WMO1VMcqsccqqc4VI85VE9xqB5z
qM4c+oMOfdAyoB8M5IU5nw5pMyvYpOT2tvdJtdios0EUaLR0tcoVGKAjBbq9Aaucgh1Ne2ifnYdd
ymv8UkiVC3N7ZH6ik8Kw692EiC2ZOnCmziC1bqcGUQ624ESN8mKQqPcut1fe1+Zj2lTnDzEcRN58
Pz5F60892PnPPBiH0zBPH6n9aJswH6jzNCwkeouwOYj4LE0dYIAWeoVbNKnx7akzyvhkElHSoWT+
u6hAhxnzwcaPVNFkMTbOV9IKoQn4IYF2OJzxGdhmuT56gO8DP/6qqwEo+WHgJxHMotBGELkQAJTC
ECUxRKFwFYnCBODNTFi0RjNXuRtJajRLFA8TxefO4t2S5GyyeLduF+9uO4vX5d/tZO07wgUf7iSr
iewOCaOeq5pIthKykxWBfmghKG+56i3X1IetFIJ6AsG2E0FdfUg1FbRFG8GuE8GO+rCbRAAKo4Wg
UnYhqJTUh3IKQSWBoOpEUFEfqikECSZWnEysKCZWUkysJJhYcTKxophYSTGxkmBixcnEimJiJcXE
aoKJVScTq4qJ1bK8WUibdA5Gi+g2jPb3eVLiCQx2mev5PE1p64U8XRvA3+/VGOdbOby++YbhN++s
I1ucKDbv0ISQkdJ1CV06aeNTtGa92ldJZAEshvJeKG5nbzDehBWI5kb5ZaROneVci/nG5xFf/yB2
smVTkz2QL8cWLEL4aUIGmgyNB9z5IcDHKPfFkJwl7Qt5Xcb3feIHvD2NLQepnu/RERj+lAc7ZExZ
VXdskpCNA2obmUCQYSV/7uIWkz//wVUg5NPYuYiriami/6XLDgp4HU5F/7DaXMKm/mA3/fVrs9XL
KTo4ML/GrX79muk0pPa7vnEdAf39GkP3riNwIW6TLIdE4j/LPn8x70/vJ/n2u+vO8eXPF94Mdy7T
gbzo/bTDfhnddflRPwF9iVeU5Z3P+YqSVBp6OojHmX6IZh7/kiPzr+8tv763/Pre8ut7y6/vLbPf
Wz7/2SOuOis/bXz6PaT5klA/VQvQgzl7JNJuvtBZyP1me9N8tqBUAfm6C83+0WjJG6ATEK2L4Ler
ov7qxx+78cde/FHaBMFXqMi0pYlNsmCvPb6Sm21phQgJpu1hDBsrqA4ine8+kMVQKRr9nFqWQDE0
1ubOubg+OyNCSgVUGtGICToeRkk7YWtl1JK0ElLGY6wdouYjv2vzH/34MiD2UiehGylY3CIxv58K
Ytxi2EeGkx82LB+JEt6qB39f+KPh/LHI8/j9EBbjsrqXis3cJPcRSW88y8cYYQ31RrC6mCld2RuS
UOgULMNwXatXuEQhYY+nDd4MsyRleB6M2ZIN64G09mPUIcM26lc0Xer3JvOiGBbRQOdoOrk7D8hi
TxppT8NHry8tE6YhKsdouQ3Ssg6/FRw2e4GnNvyBtj947za4fx9M+tPwN1Dm8MJtbTH5OAG9c00V
RKhyHUkb3Gts4WJCwodnTbAQR7TJifihJZeaTgbDmwV70Ytbh8mkyGfDFEqqEtm9kY/PyNqNM6/9
a7tzcu51cPnw3l43jxOQfm+GSn7j6Kq5HKhSUmCVUgIyHnDfxyPGHHhxqn5O2Ap8VjeSHQqLIx3D
mZ2qWp/oeKdhcPwyQdqeWUM4gTUpOVctWIq8w/f5tRPKQaNHepTsz2FbOaNtiVmGqoA+Vvss6nR8
Twd0mXAbP54OwzFe77Pk6OkHysopILnfygO6guSfEjjaoonvvxfrKFfi9esh76e0QA5RHDFTbpLs
DGnnTJNH3FKB89GGTV/KeEpTsL+kbCu4G5JVhCqrrL9yws0MVcCJ1WD/RozZMP9zIH7XDzc1LBka
PgmFm1W0PCQaYDwqWXMMV2K2o29bDNqWkCx3OP9I4/wlz1tQ0p96vLLP46uvSXPMX0roMquT5zuG
gAOLzwlRjCfSZydEviyjJTOeSVFMEQhJItJYZqkUHQ/oM2mGuQDlgCs71pXlab59ou3qoIRmDLwo
QLeMzG71JjcKblApicgMcSAlS1rsW0IFgiM6jzM0730QoqGe8ka2CSRIy5CatvEjAsuPGpqXYhMt
/FzdPkZtNG2UqIS4WIzxQjyNm7AhPGxaR1RG1nBBdqSXAyrGtUSwc+rdirwmRh269PApHMxQCcHD
6+A9PmBJELjxYwa4Vi6s0yaFH6f7VkB7QO69ZdhTwE/jZriL9+2n8GrA5ThROkEUyPvz0wSnoQ3s
iRLKdlV1MEyGya7N5Rx9m5kjXptZVueDDoca4hXsCeKnLPKoLR6C+gTRtGAXyWc7eEQEY0qsSdjc
mhw1vVtQWkRsSvDNN98YrTeZK88ezZUUP+Iw1S+Y0u3bX1KIni2t3HyJKW65Ojh0SQD347k/mwX9
5uUVtK0983vBMjGAIin45WJ25Y+Opv2A/OM6f6x2Wy/Gdbtptk6zLUP8mFJZLxAnkQhbOIXSUVR2
5pP+VNv+kJNsU9z6dwHaSoI6t5iRhvaeH66z2Bpm5MFdED7S8gqT8/UFPsXYIC8ksC2ckR8GPESi
2AN4KERv0KGcLNEO5hJxg1FCJ8CeBzcfwf2wL4+MUHaj+WIwwNPBSBZNuPIg89mJ1ib1+qA2QaqY
9CMgnQwrz9GbnMsL8UBOtnq6B/UAhfH85Pyy9asnW2mefS8D//lQHncTkMXGA7FcAOIbkaeruT4q
JGYCXEVx87Qn5JTPw4JP4uKp4PrIcGjxDf2YcwA9GswgX+bQa6urd7+2vc6l12rVl0h0jlnMkqYO
70HiLqb3Qi50Zudxp4Mcpjt7Uz/Yh02Zev+ot/AzWXmeapNXU8Rs45YiAipdAljgobNcaVsGoxWX
J4HUG5nlFcoHkrKlxsGB2kDIvKWnCuhREvi2JxYT2szg6GaOQxn2KaO4TMIh55Q1ifzgu9GCrQ74
u3kasR935NtgjoZk1Iv6/EF5N0Ld7CaYwySGZxuyBzOOV1i6rHdp0GeuLnzLJdSe8kkK0NBjzvsK
NwkGgEkGJevdp5OUVlxSqs3oM6fn8xMmjk1hbN0F+7qStt/2ZlOSFi8BanlkDARzglE2UL38bpS1
F1KlTHhJ2ipHCiSXjs2O1QxK5E1wYvv6NC3mNSJdFVsnS98TjbBv3eSN51vIKIrvI3+k706zXzeS
dy74ljwv4Jko0X0iUVPcJnsZPp0uMOgITGuJc4GEGmic+6UWYPsBJqoUU5juJosgXoRXZgUeymTy
AhEgANem5utPankD0MWNpp9ntNwm6PO0vlJ6sv2V0mfmQKVk8eAFHFAkZfHgj0+/qsZD+aduqhHm
C1xU13Z3P+tFNT/p+no3/fVu+uvd9Ne76a930/9T76b9aPz8K+gn/OFS9iAzezoYgM6ddSduevA1
bke5Sgos5Y3xECcno0zhF9gZvaFFRm0iKVXPBo3whqYWfi+aC8u13CzinQVs6Yb4+N+CP6cFINDg
WxthpZSTAVQpDZa/bjTLKS+e/G51EtxrPLnlucPhsmzoLBgRrV/zyUYX6KpjjNRvDsU/Bf3t4XZo
egd07mLwqTDq5XJv3ogIz4Pgi7i/xcCE94EwGAZF5t3hfHPye262U5ztHqBpcXmbCl5HQUSY+/MN
zU9gldpq/jupPxhwaQdtBOfhIthT+9J4R6qBdl1ACi9A7e9L+pn2AzqaaLVPvLPGX35FDHQHDTIj
WjjxyabWD8KZKiwtXXNcYW8U+LyChuQphF2bStjyniy/dTCcaWTbB9yfOmGHGDnB2GRchd/vU6HK
YKPcLcInqkqdqUGDQti64sttOoz75ptveA3tBrFrTPJtDEsePReYRmRlsYmhp7C787OdAtY9yoGk
HeTRq87JmdfuwMwvNkS+/MMPMonObCjda79rnnbIZ9H+vuI24lnSGfnZbsHdDUT5G9bUVEdbAFg0
N5/5xAZiAMIjE40c6JVynXNCO2cbcrY5R/Fa50azAxgtLLTcqcTFiyDAlZ6Ow3Go6uggQCBaOQdi
c3NTyDMS5RdYN0JLrskFYrPqSzRFVz3J7dCZdZlZN5qiM7dl5naiNRIAWoP52KK4QbGIAzC5/EB+
KHmbIduSQwGkD5J3ZAo6JB4i3JaRAIMUBy6PMzmhxfOIBhtEB2FJoQ8HaixU9sxhB7MHNzZgFyac
rEoZYW82B1BDyK2bTO9RpOM6Ty6OXZOWPYurruF5XAh7Is+Yw1t0bMXKNKrJJUFNxqHHFLtnb3pK
sYGPG4zpW8heowc6Ez0FpyoWPMHSlAKLRHpqtlpS0NNH7QDK8bcRiVqez1vbLa/5z/hjJ/583Pln
7q80SnVSy8w+PTO/vCuYwoLMQDGIK6wfaODDCz2FTfq9MRGHcz0KvpwsYTz54XC6iMRDhwILqxLT
0ACvI/gYHbNG6Mrs8OKgLEGoeviVCaQkCPcFLEJjdKWRlBNDepJ8TWgBySNj0AXwigKmfTwXxfiO
QR/rx/uMVRSC4aSUyzXiCxIbS3zNLoHLG8MJTBsaCcqOVcQltMSnDfhVVWZVd/5oASstzVZQ3NDU
zMU/2VbsegxhOZreLHCQw7i8ieYfc/VirbiF8SZzm7jy52QYytG0h2kUKCCHX1R8yhieuocLhTMs
UJaChR+NZXazO+0/yp4EfEZPwgSW7jZZLMZVOQh3cnquigeuOV0BWPXgRi0GqMFgnORgJDDkUm7U
3yGJ/A067ENxhyd7dV4cu54mahH2ZsagNuDNjFkvq4Rdf+kAOjX+WoavlfhrBb5W469V+FqLv9bg
q5qTu3U5DrXEp/jU5SWF5DUhM4QCSEYe5Ky52OSBmmGQoUuYmU1BetgZUwnVrljBknIgRSi1DkiE
5qTvElZj9ErfiPpKkyOAGoMaE9lmMbY4RQ5ROIn4gacf3pSNiAHwtWJ/pZB1rpEUV8Ck6eFDgwGH
A0BAC3MHOW42jO/wkb8BW8IZDRP6ChIC3CEZpe8gItAVcX6NZJ8HngRUY09XBkwVmvUEEc7UkBnl
qO6DP9/MwmCU10yj1IJWZZle0GZZyOmyhKaXxHhA1YQR0u+iFiZJdLxkgQq6c0BTYo7D+8p5kB2m
meOL8f1Gfz5IifX7gr7z/Y3GuItDTCro5MtUTZ4KoloyRh3G0eVBp0UTxhbhlU2RzWZ9XPYZjyvy
7BBkcIEwlQ64gLmZYtL67F2CAsHS2/zolWP5El2p49Iopms4Zb6kwCMbbzBxo5UqGEKODmRHGErh
zPguB6OUJF0Pbm769sAULEP2qLQEXw/II1o2rXs3PiOE7t+jpMTqBxnlPQ5eUqbvoILL9C2ZvrVk
EUOMhYzlqMrLkbn2aBnl1UMPjc80Z2esKBjI95NWFVNmeT149lLgnIHj9aH8ypyvKyv0v8F9+TKg
JReM+S0H+gke5qyLULCGWxrJMn3T6lK50ngyE+27c5vjMW4rhhPggb9kP6+20jAftH/22ldFYCSZ
jnMyTAKQ3JLJMq2MaVctmaa7ISxXDn4DRB+KkH12tEH4iKMYOoc3XgxXB7hqieAO21cbVEMMGCs4
DL2N0GWCbl00OhtUeQw+CzXkToz36rS9wehjSONAwdrgGUTJamobsjKDKj58oNkBN3nbxQ05fUbB
nIlIbyh37CoM+q4BeWODCY2bMoisVkteIuzhBjFVg456RqfyztTVHq6stbWhqtQIFlDI822xjne3
kDDqyR2xwrk5GMLACGsGn+rEp5rBpVqMYJEmS6LYMkjbJhRbBootqwmSB4dV1YRDuwndDOE+abw9
aaWrNnr5sExV142q6xbstiGmFYLdNmC3M6X0kMTnsGxIXtklA4fULYcVA66SZh8LmW5roocle06J
vsOqgUrNtt2ycbLRraSl0qD8lLh8aHRot+ai/JRbaPRaV6vcVbvPB8zMgZwbcnGRgWpst2ZSuGVT
qMpXDSqJb6dGYwdVC7aWpPTU4PGglka+tRT5lgVrDiwHdlfbLRan8VPbDegUo+0KHMwp7y6vYNfu
itLSCiolR++Vl1ZQKdvQleUVVBwVLO/fit3BleU9XHF0cWV5H1fsTq4s7+SKS8CXd3LF7uTK8k6u
ODq5sryTK3YnV5d3ctXRydXy8iJlqQHkwp2DcpFOMA0tJ6fXbVR00jqJ1nHRkFAeeavsvNyIspaz
LqajflEk0ibBvb2JtFEUtC6aoeaoawo5tdraDC0slpJTMvUhapZWquT1Bmr7850csewgmtFqdmVo
Pcb1xXZ8avNHXKz8AadK0lZa1uqG9Il8N4DNIx1ixtWg3pHSmsKZ0byZ3hCma2GdSCpPWmVxXLfU
5S4gE5VWxFh7oU03w6doZWVKKWIEmarKvNlJ17VlaWN8jRZrY8sWft1lm+NgvMnXnLkd2uhDNSC2
IPeK2pql0SBba4mCQE6qJJK5ZSkyWFIthtS+bjnu+mcTpJUURFt/DkFaZcGS2zFB2wfdSloWS5rd
WjMFBQaKEvVmn2zH6phUXbTWIu/pFnHn4BWo1kTwJq1b01/KB6Q0mJ1OVOzEOpRWWXlE+APYrhcS
9OwaqhTPh92qA22lFG9LpIJDtBioKmVDlWLdRqs1cpCMeiZqW9BZeWIdXYFG84HVNYOKObnGuAZW
1w+q5hzvQlNbCc3WU2i4x5/EI9u3DNHOaoh2n0LE3fQkItlVyxCtxunKk6yurMbrypPMrqzG7MqT
zK6sxuzKbgIshShWAtISaC72JV7sxwNYw9+k1nye1QZqIwZrJ2wyqkj5ZDrL5aSaQOC5hFoQz0Os
NTiWdNdb/GGEZoR0RcjPdXy68WRNwT4b4TR+XkVzx6vEbc1KdzOlYhn+i+9m5MVLfK4EC3yNtzZz
k1BpMv/KOCQL6zGcOnNVqNynUrzppJNB4yRI1bG0bPAwnHtcQJ9sGWmGvubgEzPQ8ygsJRaV96ki
xP7dpjrRc3PpoYxWq467iG7JqMFGpDu2PV90OVDHIpoFE+4+8R9orAGp0tgRyOp9DPo6MC/d8HUD
gcFH58GEfD7Swxy78x+CCQb+8Cg4i67dkzXpO1vub1yddHeXiry08kp14Hmmc6zebdD3pvqU6s26
+DnA4F1/mot7f0L+8SlYAJlEgkqiHuLHeiMfqcNOuRofsFcOeDVtH707Ob680j644g4GZuc0s923
P8hxZPaTLf9Eu+ibYOKBEvK0Gy8N+CVidtTKKQvpIx1rIN8rAP7S9kuMpT+vOfRXi+ivFtFfLaK/
WkR/tYh+yiI6bXyMLrOzDJNpIU7kmcbKdiquSWzjyYbM3/aDAca4Oj45hd7IR4/jIl4YFuiJ7V/x
RTo6cI3dt/51svHjmgAwsSa+KwlY9dfEt3f40hNIX9sTe2JtuCbyiKKQxO5Bn1S4itngIa7niWrW
EFqsfVdaExI/o9836W//JR/Ni0FBuQjKw1exXigVNn4MDEIuT08JrtgvTuO6ZeO/7RcFnylMMVhY
UQC612Ja2E+CiTUv+n2tqCoVBQQxYbilBDjqA+Aa/WZwgWFKM4CjOQLTbxM4lzOb2jnFVkATCtQc
0z84wBdFv0gRzTRnmn85QVQAbrRTsimaFwoWG3+2cFuHjyZyuqq1w9/RJa0WPBZkTYLHaIXCa5aU
eBHtG3xVj74TMI57ZCI15NZCfd5KoLbKK5J/OW9cXZ0ct07etgG8XdC+3zCuLXpGwk1IryjD4KBG
cHMnHYQxt3sDENrOqXd0ek7v7DgVtWRMvQKUcSr504bUw/aVkYpndZSMR3hGei/qM+b2sZnau+PU
o/dG6kLhuLZxDMgjOqSfXrVbJn2cegVpJEEyWdJnkXfDaW/NtDmndVR0T9mQCkMCMytm+6o6uWom
o2tvmV6uWxnbcca2VQO6TUf+QU7J5GtdJ5uIuts62UYzYPjTBPxgWyfb8GHU4w5qHxng7LeZMnCp
7fxq5EWy79pW35GDe4yZ2zSZOVR91LT7aChlqGnJkPbFTx3Qalx5F9fnFrXDgS/LNUxsqhK7juFY
UqRw0KRgzxzYDukdRgEkhj8e6iv/MTxR4Cjb5EtZyqaz+2Q+ihvdByQzQs5opTJQbumIPpWBzOID
92RWV1Zz6KiHho08PU9mjnqUdcZ9/uaNkcXDCs+NVJdZ2SrXmXnD1LxNEcMWB5pb1HnK64pJc40p
rmXlb3H+VlZ+nfPrWfnbnL+dkd8tMzfLWfkVzq9k5Vc5v5qVz+07zGpfl9t3mNW+Add/mlX/gOs/
zap/wPWfZtU/4PpPt/R4oHUGl6FNI5rzbDBBVRPfvTQvTi9BMC+ow+WypC3rvLEfffTQagsWI8BF
hvZe4/i4ReuRs0gPtmIBnW55bKjXN8oepcqROGI+TjCpXJyTKLN5lcrDQUV5p+10nq/yGmmcY4Xz
/Hl5M18Tk8aqm5FuRdeffKRJEfMPGxc/waToginT8v9b6UMMWfZa5XoSdhYGPdgth55mAewejy4x
5LDBi1cbpqvUT31LTzrMk6/pGepLOH6vVv+XnBbxc/2vwVC/BkP9Ggz1azDUzxEM9X/MS/NZOLyb
zlZ4hs7/sec07MSRdFkqX97QhRAeX/ubDNDBEaTuBTnuO0Ion1X5mymMFbxO4Y31R8p+HXuGxGHI
mFrAXwZfzEzgAtf0hi4NWTsRm31/7rNWVFzz79Hn1+bNaNr1RzkuhAkUiTKnq3q1wVl7gAY9JIqf
QIs6+oncNLZx4o8BsTRfkxqsYL9xOLaZF5IBGOmIWhupKclwMIhfMWo7PwgIkCPIu6K4Gd4FE0ag
Tc0REC2+6DAec04egh5fV0CZ3m3Ay1HqMZ/mj7w4JLakXsex+Q7oZGGJ70Fx1qPwtosJzJ99XNIA
Mx2e+wL9vbN9k7xzXX49+4oekIjUa/z4aYZ6a2swtDkZ4tSJvjSlJNI9IzVXXjfuMWTCJWgSSmzR
ZL5N1ypaEA13e7Knwt+2Pog9/apbirTqLhIKDbmNkMrDojwi0myHFFkqiGLplK/WD0o//MBGUaDT
Hf/iweSpM6sHZVdm/Ows/C2sfOBHyup79YPxaFnVUVlWR/Xz1FFbVkf90+oAAfyZ3U2wX0fsMNkf
OLR5ceYHF5oeVd/7xpnyC9BpxV5W6ThP07eVok8+yyLR2UoSi8Rpiw4loC0G3o47myRMv8PPFg8u
v0RGzLZcdU5gh+WV6z/ZTdhe2oTtlZrQJh+oMA/M5cz5MXiM5OM45gQPHYtCJJAfav908qvXOnm7
JX74QfBL6p9amFiAQa6/Qxuax6pk1S65vXrJcu2g9FA2WzX7CM0iGzL2ni0J1mRSfrkGAFUDQIZG
tdiALjpnaKwAHYU+EvitGk66nbNDU/jo8Q9yBKXQ5kl558AldrKTmp0mJLYL/xT8et3mnwmETNC9
XN4+MF1cmK1HhwXzYZhwfTDwTX8J6oF7B9EimrgblFePEVGOMiYranQ6+n1GP5jRjFUMqzCZO1qn
AOkF/A70RNF4JGBN7LnhHF/5wW/ok/oH8zEB5vRzfUeOwkBdJUSb/XFY/jzJGYIxdqDJxKrrKzyW
SDKMHUHUTf6WB0kgch+xbTLV7ReivIdUoWuH+4BGPkhQiixjwJIORkec5B4vWe0ddJ2ykExOBafk
z+DktHF91jEwUt7xkZllc54Ab2YHnncTPwqE1XlAjKjEtfd7YVy7rlsrS5ywdZClE2HYhnqMHg1/
S2TMPEJNClU34E0wIcuhvhj5vz9a769RrSG/NNrTAt/Ph/NHCt42NC2qUs+5KvRyFANi4EaUiqLZ
Gdaq6Nf+RorhVgJP2kg5TTio3aEkOMki6lRUzTzS4a7iEcb2YeTkQekQSjrUHL1pDzQYQNUiBr2s
l4u6L4wn/ku1R9IcNfwMncD00SehrTq+Upa1uPzq1ww8vmAxEA/RUKADbdi6kQEMaZR8ZIUGU+ZF
1+nPbH11BNs6r32CfnZgc3PMx47vGymf4aWHekku+Giq9kRxyWLUnw9U/YolCfs2aypv0rs/WNSI
cmy82mvIGZ33ASI+MpUPGhZhYO5ZdCKovGqzr/RR3O8LMuHCtHwhsX6TPaFxJLuYsPRiv1yR23BQ
EgAGBk2CPqOQodrAypfkgHLNYx/0FtHHDbtbktfGiDRZ1i7jjfr8sBfQfdCPSqRxn3GorCutH2zj
JkFPNbcj6emoVuTpAL0teb+cXKDGQqI4mOAqn87UpckbUtGlzOTTSo42D4Q1hy038UJPO1ri8aZH
WPJdcuRyCuZYrZxmm8wRVgWsnqgcVIsxS+hZHr6bqnzQ4ysKRoO93C1e7P555i/I4Za0vmX0CCCf
wPdHOMBH06l0GaF3bLH1Z3/qTaYzZAXa8pYeSmVDKMpF9n6U6YNClf7Ec+O7+QrHxgj0BU6Nt7dr
X+jUWKgALiA/e+RyA7Z+QQ/N+ihMubgF/W/E28bPfsb89Yj56xHz1yPmr0fMn+WI2Thm/tccMj/r
FJnCGUyCUKrDeFIHUwDUjZOLvnPWs61yMUprPWgg6NLQOs8bTmYL4yCVjaQX3Y0QJh5QVyMuX9nd
y6k3Kn6vhwutPGK6vx3C3hJDqIQ+xoaEIjg30gGAvxjNuXy1tJfrluRjR0m2zIHt4CwM+mj9DYMz
DTGrloozhNIkI24KA7In8qViuXCApwpFkS8XS4WD4YRVUNId445UyncTtOZT2OM2mq38oAzLQqUo
0ESiWymQgzz1fDg3KB/81i1/KFYruX07owIZlThj3zZfvHqqBuNtUpfemmlMZk6FHte566BGtE7e
ch0h4A5TrWCnD9Dx3IpyXbVCZchWqAxXK5ZWYTzcFKBQgBYp27Bjtg5KqhrMAjvuArS5SpCEEk9D
Mme9merjjYYv2MWMnLl7fJ7Njm5gmQ6FfpcFxdU+Bq8IQDvrBTNetlHwlbq7qSqK+GQimmLEGVRj
MNCMtKyXjh6Ng3IUSlR7YbwRgqMNHWKIQxxpvEJtv/X2SPlv3YS5m13L0u4ZxhfsO7XRPZUnEwdh
CDij1bilccMQb4Ym9LJqurjBa4e/LcYztexO8Ciuu0BtWdADVDGcCbTuK+jJL3cdGY+T9oScPXbw
1y5KQgl/kUxUkPdoqSFK+iVA7s80m1A5RK623FynfkaARHEDYvid5K6TNEfqogRopcp57DTsDcx6
aIVsTd/yWT1MKN584IVR4PF7vPiYsFI+UHY2tIeADZb45ps4u3IgjVvs3Hi3Qn4kKuUPKp9OynQm
+QipfCB3szKbjg95w7F7IG0I5dkf74hKB2xwaB0I0slDeZfe9PKxBomQPJmLzyboULeSgBjGL7ve
4Dk3dIoUFBILyXDqYNxZa4bTeQaqGCa9aOlWjI9O5SOzReq9OxNbMkhRo8aAtVG/vUozop3Bh5tZ
kexZN6hcXAk59IqZERHYVWuDUBm06Pf60IFJDwNEerlqkD6fJVhsdkJc3GwL2tQi6QiHp+SDYRjN
xU28cNPlhdFSMrc1G5uYgmn+xWMuGIFQpOCCwAG6uwQiLKMP1fJSCPLcakLElyHkqpVdmI1RL0+I
Cs2C3eheg28dKAfHclF3Ocx78waKbEqGar/RNKOU+eLbv5OBkqJYMYjUKY9AzxaGERk/OUzg2VSn
Z9XyQVn2dE3Ix+5VfTeijsIuJzTUcfqhp4Z3Q1xKbv2Ie5wXAUmhJoiLQoM3ACOeAsoXXepYyCRe
nrFN0RMcl2OVyj4Ps5pGVm/7cU7Zznm9w44eYd4RsassKCE4RflygZR9DbaTAtt1gGnvOhpMO8+x
wCopsKoLrJYC23KBpZpQcTWhkmpCxdUE5TtGwlQl/eY5lDZsL7JDPXaaopO3i4bf1dSYwUIAAQO+
6hxTO3I8ZeSjs29YTbPzIaNSXZIPY7aytSQf6Kssoa8C9FWW0FfFeyyDPmPcluSxeReNU0Cg4/2H
0gnUabQ5SI0hWEnckPN1WLlm+6dV7gPt9+d8ALplg2bNMp+88h0dvU+vT0ftY2s1LONq2Ovd6YQK
JUTqabpjKdcF0mu4XdSgpe2qNnqilsiJih5VpBtGjyrSy5He14BCiM8vlD5YSEPAYjTYXQoBq5EY
lMsWjE0cPRxRyyg+JsGXI91tm9RDowXaE0vJ6IFu3cmXonprsqFqihf1binZIUW1lHG+5U2fatzO
Zr4ss80XRi8TxVd8D9JCXwm4EaEltdU+Koqr07bNNUhIdyiCpkSGXRwZkhp75CfPPt0lzdHFs3RP
jQ6TmlG0wHGc2MC82uBNDSsVRkSLkQ+fDUB6L00bCGIh3oTQLZhHRt6vYv8/aSY1k/xpuvhzdHou
E/FK7wG2iGrbp05SSBuZTaNo2B098l0st8e4Rec7N9P2fD+9X9j58JSo8OX5K7rf3PydOgcFtlSs
7sQejoeDMV3ysqUbwEOZsY3ZsSEgEGLSksvlJW7H+G41xeTD9lW7c9k6oRR8nZMYyG2Hct9K7iXK
B8b9dEIwM3YY5VzyutSUPwNXgiG2mBrIyYQqHM75Llw1i4TOJpKSjCmgwn2I5bGk3ucHf5ehTqYj
Pf+mr+Ir2omKWTib3woSCFSnD+SXGuWUt8S47WZLALXbSNHP3Fx0KZVVEKYDPmNkaX4xx51GvJW9
yc/nNnS/7hq819k4VFDAQvLWuFTcdT1P2xeg1KKvght/qA0bzNUs3k5bs7M03Vi6PpoAL9UXENWZ
ugi+mUlfFwsygliMAsH2JAnzErMV9QPSJsk/GvarOrkxTm3MtqGjHu2h03BcpN120zXnq9hjkV6m
Yh9FrvORzGM33tBEfAGfPGZT+yO+csmlMecLxokVbLPkmZntZEjvrkp6RfAh527z6XOucDDcdB1g
dUlVec4h1rIzqcTZoXHmZPuvtpmaUCdXOviJ14zy7ofYdWV87mOcM5USAKahWj3jmMscDHVWioyn
ZRvmG7TEAZc0Z9RTHk1KKLCDmYzQ3QVJuXfVUUmchpkDzjGu1LDSJvO++D0Ip/Tuva96QPk8qlo+
j/BY+g053e/5YV8fD6syemrFydM5a9J8i9cjdNtI9nMwLW0Cj8M+bfmNDuVZL917FaP37ImOjDho
5tXaJXl4ZzNrKzySMSfqqZNMUBGUrcDMBrG25cscW+HSLhuV8VhC8+KTKltHI8QwlYjSQ8n8FCtc
PJFrLYBVErUZDPrxQfxztIJ9fOyeNQjs5T1jICQW9/S6q3mZwGcsu9w0qdNYLsqVZsWlk1qEKgnq
OMlRSg916umxcmqP3dP20jPoJGsM1+vu6SF2hmpQZG8SlBf1SuwyMzWCB5GTWe2jpdQ9KdkxUPbE
8OqZp8cqtAJSkzw9JsJ0CKBoxhxLHh7Hfv9j7peryfbNZ1bbLc7Hh8Vj6XgfptyNuNnOw2S9C36V
ue9NS4N7d8u+zUtJ0VDTD2dbe9tuSQrAWMabML1dO/u3u70cvR11ZVuiX9rP1vEznfAqHTh9MqTe
QdCx8qvPf0r8ggPD5H1t4rwwmZ04LjxdflqYzE4cFiazE2eFyezEUWEyO3FSeLr0oPBV6ki9CZvp
u4AtNlVokMRBun5CwAWl1Sn2nbRc8ONT8hwr6XjiTvY9aFJ+C9sswlmW8c+0CFTsI/NYNJJH6arb
Ejfc+0JfVcuDS+jIcsKHMd5s24BVdqgb+9F/Gu3Oqmh3n4MWBGc1tJXys9BWVkVbfRba2qpot56F
dtUuqzyryyqrdlnlWV1WXbXLqmaXyclvxcN3/WrCPno/xxs+PtbPnmZdN572IpW61jx96lYzCZC6
1ExOl6k7zSRA8kpz6Wojz1pXP/jPWAr1sX5aB7OP9aUCBMDGQssgcrF1HvxnVxulcEeEqmyjWvXg
//Spc//Tp479T5889V92hONso3lWYz/NSbTy2txNJLElMHCEmope6W3L9jdv+AVTfPTcOm2q010z
RITrLMUwRZHHyuTYxB2qrFzcltH7aAtAkcqk5xaHlQqFLpNuVjK2CBT08jfE86FouHLZMNzBaPWM
tXo/LlmjkhVVkv28bBh+Xeyi1C/YAVBoizc0DSMQBaTWD9itlRlvi3YXWOIDRacssourDS6eOBf3
Dfg6wdfM81yEiYUj0XwjXA8fQIwzKEhijAGNnVFW4EoOYGwcryX6PJaI2L6AoqjhfFsw1KbrKDB9
ZLMPADIeYJcA01Cdnll2UvSeZ/6nCI2ixT2/B6antEURTZWBJr0Hno+6bKUZkQXntNdbhN9o/YrH
0c7BhvQoVtR7HzxEGOJBo3xGEUdMqJuRIun0khYROhBIHwi+ik8mnZnqVke+Q9sg1XnHOivXT9X4
BKi8ZZ4AlfkEqIzvhvht8dRz8NzsW/k2Jq4kZq0acsowjP03qaZXqnrbQFcNpBdIMyL1iN+Mdx2/
k2F5EQeZ1GVWrBZzVR8bXIVmdaoTgXUyZDiJ/8nphjrWtA7T4/MgUtWh5EYwmBXpqDaiKPTSCTP7
Ntfd55z9jNnRLemvTLcFe7hNUyuyDgZqOr/HN6BBGE4paAYSeqTDcWq36vqlnzFENpcKs7n8KQ99
ttlZRV0dVUv6sNOmMj5/X3FY4MB9YmQg+AstMVcaVc8ZNDHrVx8rjkF7tMGBtLtDA417e27s37O2
5NKGkN5gYpfQayrDBsVyr5+YJXmGcw/D1JytOzh7/I9oArA9wtlKB71sq37Q08VWHLvcGMGVrfSM
Ec3LOSqrBrjOjQnLnFDSPYcYNjZ+VOfho0daJ9gXSv8brVkIZ4Nkjmseiq2+dDNFopllIdtB8cnk
LoQmrsQVLlAU7PGb5kh0p/NbccfPD/EklT/2tI6jdjvGnmTl+Q77Al8489X/F5r8rIkrEQUkfhsX
hHx1Evs50o6CcVY6abXyMN8U2EGxfC1dgk6GRHZsjAfmOflRkRZXrUAMxLnm+47Hc+sEBoVymqyq
2JyGN7nE63v0o0xA+wwi3QPdDu/m3rffIpZ9VRrvB7MyyH/Ofk6loDOcfeWp2iiylyb2mEgt6KLQ
FTNnLeyniF47m7wkLMhKajA5IdStxnIZLJFstXpC029RZvUu3mDD0qZmpPdBb44PWIiTeShWoK01
yGMkKiURjaagidGlcb1GOPjKl166iTsujCOgtmPClusOuFiKDP9O5PsFmVVc8x/WYi5VK9v1nbg7
RdrlwibetyWFoShkwUQ6dZti9Pt3Vx2vE/qTaCTjO8CiBYtjIQZpxrdNXufssCjKBFErmUDHoLBy
boVyd6zcxgh4jH6XvBSyKoH3SiU5+OIejgvFyPl5fCEeYQcqEo654Pt9dOs5Hk8ne8Yaz/sTgr4n
Nb0/7IshziagfU80SrQ5N65N49dPalLChWxzwYH20i+8i1UsilGk5WttO3B6bzzbDP6em5VrxRks
7LiZV5f+b97kIbmgJgeBrQAcA/Jnygv0bYA6SezIZhsUMnTAE3vdoaBJjM0xy1Byjqze5T09puA/
q7I9gku0s14qciQzR9viOhPtKz0MuIUSwtnC7We2UCvpqdZx12uUe4YGm3w7b/o1Wt2nkeGVqymj
8PSn+CoZ6U55PCod/Fc+H3sDMp77i3+CKA8GA8Mpzs5B3vCKlPSwYzsYSrrWMZ8CjOh0JZfPl3/4
AfFdnp56V1ghYT9veD8fxhnnDcxh7z3CLEHpZsKxCUh0npFzHaOSM11Lo+W1fjaQtYjChCcU2SPd
4Zyv8ksb5bKCImWxx8s5ulrQ/uL4hCHtKggQEMNZ6Y6PW9GHj0wGtrAXEXxROZjwXcZsbpns4KVf
VV/6KbNlaw4A7WGT6lLlnGdOaiI7dkxjZkSqd8p+EfYHyb3/MIKkoI8nA92g58vQPY69Wp7jecS7
LCtmmbrL0Zc4pqIt3YLIQr404+jzo/hHWDKl67e8H4lhHyR/ONfDRA6Lgnp7Fwb3wz6seBPQ50M9
lvyb4Bu52sVzO7HigtqrJ/aaXAP01L7lmNrldtDaKUqruB1m2B09uWV3JpZrA7OflVepOPStmk7i
tSPuwgS1BeUx0rVC/hQ8eufDKCqKOrVqJ71MxiDbBNKzQdAKxTsczotiB7MrpVLWatyghykMu0uw
jkXZBCrT4l6xaTpExzPmwgxwtMRXbMJOHkiQR57WmACQVvuqTWIriEBCgVdVIAdgaImv1jJgdgim
RjA7GTA9gtkimJ4bBtAjDDG9lkFPjekhrtcy6KkxPcT6WgY9NaaHWF6z6bkCcfcupnPvCoYGDBfQ
h4jnWzZJKAKxRwwAIoZvlZ/q6hY5lgB44vtWJbO7NSAxf6tqAcon6t6JspUDOOqArYT8DCNyiI73
Ay05ewAo9cPWlgV64Xe8o+kkWowVQuqJrboF1YZt+0IpmhXqh61tN4+3qB8q1A9biUEUdBc3kEf8
39q18q4npDMDglYwgBlpgtG4qtwFfgIyWszQvQTAEufMAtwdXavAKWxV0YTXu8KtqneKJ7OoYxNo
bxko6NewT61yV/QtyLPpfRCCsAzvhqMARIdUcaBDleFuCawyHf9jMPEOAbJ3q+C4TwY2t4GCUeC1
58FMgVGn1DOGR72MLK9St9TLGTAVgqFuqVcyYKoEQ91Tr2bA0FCsUcfUM4ZifYtgqC/qWxkwdYKh
TqjXM2C2CYbYX88QtzqJW43YXbfFrdnwqhVzrNSI2fVdBxRNjQgIUMxrPwuKJ9Aac7ubQRVNNDXm
dsbEV+8TDHO7nwETIMwWczvIgBkQDHN74IbZpkl2i7i9nSFF2yRFW8Tt7Qwp2iYp2iJub2dI0TZJ
0RbxejtDirZJiraI09sZUrRNUrRFfN7OkKJtkqIt4vN2hhRtkxRtEZ+3M6Rom6SoTnzezlg8tncJ
hvi8vZsB4xMM89nPgOkSDPM5Q362SX7qzOcM+dkm+akznzPkZ5vkp858zpCfbZKfOvOZ5OfTPHFh
yjTiYFSjfvSUT64E+BfwzrVTj51zXV53rq473ull67zRya8Fo0G9RnVvjIbz+ShYK2iYRuvoXR6z
CvHNIm4wDQdoV++OW22KgyU49uVVxzu7bBzvYwJtB+IEuhpos1MdLoNAMUJxIOSHDZHP57d++CFf
LxcKr/nkhH4KmFXGbWmlJOO7yXr3xD/EH2KvRw+NhNgEZBkoZCmPDE8OxKb8TmdYgAaYgkfSefpe
WJUU3MaIf3CgmHVZFr/9ISsLErURayTN7LtWsJd0kwL8/kwKsHIuZtS+GSUxR89HzT9UgSytPpX5
Y8ipqs5wmqyUU17QIFXQRr0JKmZ5cyddg8x4cUW6vKwPncoG96NhN3Y5KT2zaWcsuEVkoWucNd9e
5GG2eCN2OHKQdOol8p4Hu3FE4flh6D9qod9kuE0rl7i9x2RZGUTWEqwB7Gg1TgNqScXuWpdVuUJ9
A4DJqC/OMuuLU9P1GciM+ggZnklHphBQwnM6P/ePWL4976hz2fLOmu2O58nxqvLWFW4ogoFSO61r
BG7HEP953TjOlwopdLATT2FTwtxP0t9/Lv16bJr1Hi9rRl82Ywndx0/RDfogrFccjID9thptSGW+
YDA6cLjqzqr2E2uMK+tGVvd0o2d2TrwqYFH9xZ/NdIJeJVi2SbQ/NYzUePx01HGE+RIBxx3OQI/x
RV338aVxo2wvoG35hJq8gUp/cWN/4t9gwTk7WLyCOYcPyue46eRz2NMwCA7bx1/KVehXd6Ff3YV+
dRf61V3o54xI5fDcmRXoezzW3jx19OPGL975yTls5U4aua1XGzO8+fDmvOvy7/zh6DcTBGiqfNin
0Me5GMTrTeaQuIBUvI6nwjDr7tsWJ1Eg7vxwiMeuPO8yCX0124yGk49oikLTuOBNrxfvkfEWiDxX
8WUQhhmSI0HHbyKeBHSWLzQxtI/77UNR7rH406SPfzlcAn6KN5m/fSCydXFEzoGpuJ5Jnz8gAfxp
ZmTPIJ8NXYYDaJ5413h/AlrW4RFj3EF6bgN/9tsWrJ/rsKRWaljfAtDhya4YTWGeQQDcnlqpBSpX
jPUs/umGH1cFxURPXl25i4jXKqo3fS24UbASskp5aNm3AD0cSP+xVyH6U6eoCCg2ZIwiV+fe7WLy
MWLruAjXkJ64mw77IJBYxotlLY/JBY6sjdiGbIZGYB/za1c6kpaBNx8V9v46WaPAnXgBnx9CA0r7
ppAPgfbyB/ENpcOXA1EpoGaWo0pI2g4c8BtW2geyclOklB6+K+2MHgBGfiqK7zDCA3qbzX/H14dR
Aegq0tWwhajorKvMkCx6RNObOKQHte4PeYrCvNMhD7zx2O6vdRktYDaYeLOiSOSN/QfOkXzWg2Ec
4aK9r1hfFH/bt7KLYsLdoUcNcG0ewjbYw9bmaSwSoXIsCcgPp4tJfzGTEJBYiHHMHEjY5mfm53Ul
BY1yxsJpoTTwvBZ5VfGGcBSX/awxbRgDXNphRkn0Y793C9PY6f3bTfzogeDJ8y+6kQ1s4jOhXztz
gB6JZhwF8zwJ/3ohlg2yaZJjLk7lBsGAK29Ks5N7HV1DBkYaoYZhRZ6j8SLNU+UEDqQD/RvQ7dTl
A9jUQPt/iBlUEN9/L0wG/4AlCmrkQAGEN5gIOUhXhwPfoSNd8iTUDQZTiz5JRy53BapAxzt8n18T
4hTZziNalWDoPRxhaqSNHvSQypHAGrXvJ0eavYZ9wAZHTwC9Ln9QIqLkwgJHGJo/KOMPxQgtUz8g
h7LYcDuUvn5XZgOVeIoNqnIcvaswwVjKnmYFTwjLWfCHCEaw/lOrL3GjN7yRLeAGptunIRytkvMQ
t2SV3syE4ZlVtyGjCX/IIZFZTclYhMy1So7DV/KhAe8G2NHFHexOcEPQZDut0XTKxmH0NHl4A0vD
HMdk4uWxXr3+hkSjDa6QK9YPIqGP2asYwuEE5M0pOkw+tbzgwUQWwAfmNIrxRPwoxhJnjgjgzkd6
hnF3w791Y4XJrvxvjHtdLzlCLAEWr8uCCvwhNYpEJElf9Bfj8aM+eOXxk1wM+8EYtmaeDB7nIYft
1VEtgHL5k9+Q4/xJEWAXUhZGHmwTqYYE0klinRV0nY8b84K8IOEfK1Q4N/NdMEIDW+2qSBkB3Uzm
c7+72YvbiZb30DCPbKCiBAUUPZ4rgr0sCJidvT5IUpgiGffn/QCnFTsdthohna3AJn46HvZBGRj2
8YhgLtaDMEyiwQCGkrk4DV4eX7J4N9rtk1YnX9JdTOvdq424RV7wkHfQvs5GX9HnaEBGJ1ktkxrQ
8rapDpVN3MNKpuPZCPYh38gbAf6RzQYJOxBl8c9/ijyTid9LuMRq6giiUNhPlYWeh6zjy/Pmsdc+
OTt1gCBhhJFGnJQyqVEIz7vz88zD30of7PhPujewyYtJpnhhtDQyTk31wmIsSyBjhGDSzJ43yIw7
3zG8PLRaH96QLhXlkZ5p2A/MCjGN9rBofBn3w5OV0eCJ54hZZbxsTkAUSs//2Q8newIKoF0gPWkZ
YidjdwX9Tbnv+NTT2sgfPX1cS0Bf4ry2VP2c57XifBrhlP0vPndtBfp8EedQPJ2TdqfRdBHK87ru
cOJz/FrUMdiNXqgOOAkNHV6iySwdguI5Bp834kkrDLG7YZ88dcsHO67TQz7oC3HvO+eTRNDTbeo4
GgqTRdfX0qs3nv7yBto+ciQs8MPHi0VWNEaAkI6Sdc06lERMFjopG/nDsYwVISppUtAFaswWRQq0
tb/oBV+KGnkqpFDZZ9h8ICymaJkLo24ehEN/FMXs17EezIZo4RKdd822+6D08Fc6Z+OTRTqQpFO/
5uE1XuSJ/+//o4PUP/0Js/gM8uJX89hUnpga56HG4WnRcXpaxPrMw9blR6lE0lMHqUwYtOy42aZD
z5PjTZFxkCpbSkeoRkP16SmfZ8oT1ONm6wTPP5sX8acj4BuQd1YU7auToyZ+OPnlBNrSaP1alHjb
J/95DUCQyVOHPIHNP8EZ6JWj6xadAyMr2teH7U6zc905EW8vL4/bhAsqgIn8ffPopL0vzi7bxLRr
PJE9bnQaRACgAY5BNnw+vG43iXew3Thpta6v8ESWTczfXf4MzAF6G1D8mBh9eUHNBj5dtuio3H1K
HB8Mt4GDR53kgTIe7+KJcdxecXHy9qz59uTi6MQ6Ry7oc+QmV/1z41duJp8l61PiU1uGi9Svonkq
Gsfvm0i+BAZxaDel6FyeEqr29dE72QV21KlnHCSPht2MHNTNpqOseFQ6VBWFWORjPjYE5pdfg34Q
QYo/4k/mmTLlzyAHJoHwcR/1xqvGmYcyIiiJXlnqU3ETa0SvaSOKCaUT0PY/r7H75WJ8YuxXzC9V
80sNNT/WquLELROibn7ZNr/sSI1XeRFVlBD1eaQAK8b6oBrCisgQh7+j1RQH08zmDWBJxYSXtuzF
jXIThBeGrGxGm5iK1C/wBG2jaiYzMOqdvJVOZpSzMipGBjGV6/vDuHhI7BDp5gzk5vikfcQPNq4u
YS7AQxh66MQ3gRQfQz47oe5hB0TS/awMyQR0xBY+6vaB95qaDRRvVvKGGPAYzYOxfNG6DinwSXOQ
elYdN0e/1bFx/yATWbTERvt/9bdcF3+ok1e8U1if6TNZPomIz1PQfTOurNBofiKpDsJt+YOqlOww
Bjq8C8a98UydOmqZKuSZ8I0fqUmgI/sYeLdQJM62m28vGp1rnJRqynomPhQ/RHciqgQdeEAZ0Sa2
8PNURZ/sUn3+QncOqr0FIWnAs4vUuT6ehpgkUgth67CgY5HXr+X5hQz7kl+fyYQeun11SMcePcPB
V1HcmJzRo/Hc4/WlCQJQst6fMRtzuT5R/lSJ9cKMD1LseU4c8AkevYm7evdr2+tceq3Wdr4/o6YF
BIoPnuWxnnmQBvOjuIIsfDwen53ZFchiesrdRIl+utbIrjUufoOtXV7uZuagtZ2ktSjeXlmEy6NM
m9KiMKsuGCw0JTsfCwHJzvfmCgMFKD51fFzbD8g1zZ4rb4aHajw+12cfjCuXT9zeoQuEFTZ4DPYl
4vPumjs88QlbPLdFjh2Xl0675e0ttWmBTghwCMs2f7W/+Wp/89X+5qv9zf9K+5v54yzI2jnxDP7c
XdXDmE4/nzLr4SvF+JoAfcfHR5E4qwzuN9umlQyderKXN76GDkI2sNjXZ6JkI+Pd+6OPhulF8kj1
D2PPxejW5Y1LD77MA48T8zirinV2cELY8+uK2gKhh+VZ5qyTTb+1u5CYhcTGGpb8YihZEqzgSbbl
5QW5lV1ALVrdk2sf/3SuLD14QbOL8v24ipkqH2DyZYWsGDQbgoH6uXUFPqnmI+p2p3H0E9lneHSg
ftmC0UHV6uLIDbxI8/kS0r7q/z6v4ciJn3nhb+fYSCn2SkSqZ6y32xQXQHeOyUPzknoaRfdpHGjd
nC5IbqBOSZE+vb44yttC5iB2NsCNYelhp+JAVrORaZlxgNbVRoHIRSEy9oex5JDEmqNA+VKSLmeT
wrSvoWmHRluHDNiiSJe1biFlac6OEqXRJcNdEgXFYVFWT6TeBnMvLFeNjpko05oEbYxO5aobxZO7
IHyExZGuvvjRSkR+GsmMY4gBc+W4ine14WLiYY4azIYl1ps3/anXXUSP3mg6neWNDWaKTgODvIiy
+Z7MVzvH76K9VB8V5GVpgKY6Xb//De1wPA/lw/M+x73LfDgOntbLGeoLqOWVnc+ml/+YVsojWh0S
ujm2xXAs8d9pKf/1xubrjc3XG5uvNzZfb2ysG5vn3tYsv5OhtcudFQyGWTl3MLIjue1QqgogwlVE
TCMPP+/r24r4Emfe8/zRfJ9cp8IXDKlHETcXM1DUAsv82y4097rTqV0QEzILDMLg74tg0nt0UKHj
xy2FGs7H3p08DTfO5oeRN0Ir+MfAD8kABT8ozWyQp6/iO1Fj2x19/m1kgSoQZ8oDZbOkzlaWYGU+
pSQLSsM4TJ5ImkB/xJquNh8zaKcT8Jh8NqAJZtPeLZtqmU1h+255jSMvWWAxyQs8Y6cygg/aiWw6
VgeKsR02hwrUDsTy+rV9UQNJDhpvQGHs+4+atUzZmA+85qKPr38VgRqJ1HnzAKY5Tof5pT2zCSI+
zKXcspFbLats3NhCTrUsbVMJtGKAbu2aoBUEfV3ZMaGrBvRuyYSGnK3d1zbumgFdrpT2Y2jI2S29
rpZM6C0TeqtsQEMOFE8gr5vgOyY45ED5BPZtA7xSrhjgkAPlE9h3TPBa1QCHHCifAN81wbdNcMiB
8gliyqW9uH9KNQMccqB8Anu5bIBXLfDyHpSPsasT/lgg/pDD1xJeGg9ofwdyJX4UlZQoU2WvD1Aq
cf+cKd/qLnI6gW0X6NJvYas6BQ1ogn4eOC5RgFpWBCr5BDQ03AdslMobxt6Adb1GFIFShQoeuvob
4nlmOPZHjAZ1PX8O42QTZtLy7k5po1zZABZVqntbu/A/YTj4kYbVAebjSfDkAB2dQQMO0DMU6Mzh
ATrWgon+AB3CAF3wN1bEYO26gNVuT5oyq5MmOiDBoMQDUAtxcq6US/WNUmWjtC1K9b3Kzl65LqZ8
xCofOkTiHq3f2foyEtXKRnc4/0bk303v0dEdKOoRLSk4FUeCLfFAv2f9kurzR7hJfKQ3YTCnd0fB
OMIrI1YyZyO/h6e4QEupuoPcLO+KUnWvXNsr7RTkOqomfcvSzxt/xIqTdqbxjOTIwAmKZmmHca2c
t5zlkOFU0Hxm5cI/nDjLQ/+oRzpWG6yJO5bVAyxgyy5gBobWS3Yq0gXJ1XopkaHmZ+YEDgx8l8Tz
Mox6dHhlFyBIBAKZRpBqeQuxJqBSSxOCF3lFMvA+uYCM8FGjWsNfbUwiD3erXu+xN0J7VbW483fb
ICPPiVBbXj/XL4k3tjpRSFpiuKqcT1MVTpKVTagiCzfUFVdcKCQmj8PRVAZF6k/HuKkEhg1H/Ds/
8SdTOYUUcLjgUOQZozkQXSqJFg7+aAQCgk4sccOmHdar55ijIRSj4KawwX8IJsq5JR//EBqPK8+z
iufNuX6HEcgsNgKRH5XBAncAHkndc4/28PTT4hrhRHgMtHHACFHwgF15PHLsgTxdXP6cOGcCjS0P
BQqsJbYCHXNyPuZ5X73EQMMh2E91vDO6suAuoakCZ55HEUh3kLFL/yIXjK/c5nLHqzgYP9GQrVVk
I8+JGSwvebtu9kldlDbZaHMhi2/OYnMZfJRYMI0o8Cgsow2wpJDDYGVFETOC4pbwapEgHvfjvVv5
1iiD47E27OC3PSJYWlRg8IAExTwrtPR0KG9IgkxJEaCYo/J/UDsJYguX+C8M4SGTiWACxZKoOMdw
CocG3pcV+zQ/GuUYPjGFyAbn5CZnc37nTWDk4RwmiyGhydwfzZGtnkHpBVM98zJKQSFWMlIVbRwY
uAwDBDlKqW893bf54A76duLh7SVufab4UlmO0xn5k47IgXR05bh2iWcvPVTtXl02RleRGDm1wSoy
nU8nw57XwzkmX9jT8vwteQ+OZzeYTCJ8/MJ6Es1BZGOlFvR4Hk4idUkgTHl0PQBp9DHdjg1r+2nA
JcSCks2HFQq1ejjxagOQIr3TAS6fxp4ZmCTW53eK//PfJZUuXs/vNn5k6QASbHHBoABv1rUiSRIl
wRcMf9E+OUKLnGv4m5TQAllUjoe9cGpicL1J2jd6Dq3LOFAfrTFqKcPrc1pELFs5DNgu26SOluOi
WmI3bdUsOZsYVZhdmmF/GMVLz5OL02pz92nr5D+9VqPTvGzbk3dkl40tO9uq1GEDT7lK6f8Lscmd
xGJZS8pHQI6VgV7zCGlglzrUkGZcJsrY0nLdXmrijB9/BF2cfZrn3mQBfS/y+fIZPhMCWFTuCvKJ
oKXPPL/+yir1V7LrT9s9pgRTG0DatnIgXHRWbsM/iu9GffHud22AJseDs00OrKpTRIjH4IjsDfwr
ikPovETSmokfyjY7RzZIkoYl3bcCXJqDTxUqr4i8/BLklRWRZ/a9qR8x86w+ZNNHS5OntVO+S3bI
bmKVdQ8wofK44kyhEwN/OKIgR+Ialq6bPWF0qGytgzq5fGCMCeWw5d1fRDl234LfgECyT8UPsmaY
rD5yTBaYzI0QNGiX2Wmen7S89yfoeE6UHoJBrDvQy7dMdU1pU4Oh0v3nY0pIaRiJF9HAmKa6Y1a6
sxqE7oldTYisQuCFvt05r6Hhb6Dz38Bf845YKK1jz+hzSpAY7SVT9V9SxdLk44yM7UV9gPjy/Xxc
0BOuqvPktLnRgVyotL9J/0Nvftffo/+JiPl489h/NDsbUs6nk/kt5f1Ke2n48A5PAyhvOCErPPjY
puW4kNQFmU51VGEiYbw8geZkzc9ELrkAABda9YqHi9l6izsFKeayc7FjWBq66KLvbhj+Pf++2fpP
D0ZnUSQU1aK4uD47i7dBVPBAbJQT7MYoo7x/IWmIYCt5S7edfVm5+G5IPEcMDkNypdHgO9boo8fC
m9fAxkYgvQOJNUG5UZC7h2dpwHf51DDM2MbqxHD0u9fPW09VX22Qy8vkYLVtsj7N9OEhwOfKK3gJ
1IBfwACiupt2FXikDT3zRwXAX6qLd9MRTC7icISO4/2wL364pZTunxfR5rA7JgOIomgenkPpEHqb
bqX5ajkcoo2neAtTE8Zw/2HOCZs3nPDnLhC7OQnmsa9BiiwC68FN6I/xXIVshpX17754nC5A0cUj
qtigFqMxyTtwtr4lREM8P+kH7PUBBsJYW5e+vbgWMpaBuCJTXHHG5rh4LiotdgN0J6T1aLTIiA1s
yYsGtXJfBEM6EVUuJyqqkjNl4CuNe/P+HIkPxZQMRApk+YyTsy5rGrsmmBC3VXv0up3OAjasGM61
DR1sRgaLUZFwALQ2ieXLUzaL3dcmzXjRyNFxxrPREA0F0MvrZP4IbeC3xInrdmDwU7ftmwKENNC2
CktYTRbpUzobm8PkEhnN/xU6OQISQWI4Zl/QC4Z3GDqGrCqe7kdpbjyV9tvSUpn5uS9gDoTta1Hc
h0O+IEj1MN/z614G4Z70NtGLu+gEZNZzhQfgRdFeIIYqBoo4nEZzhDxvCFGqlMvljXK1tC2u2w19
rfzGkHAyY4G/49RzbXIH/hAoY/YHGF0ezgubPdrt6QmB+XV0609uQPF+wUOC5/u4g9VkMn22gW0c
eSgBAE3R81s6h14N8GuulGc9WKiOLs/PvfPmBQexbIuqviuXKIlp1gZWZdBDSE89UYnf23Fcot/S
yD/orbkiAFB5N7hCehzlMX+LDptAeca/m7OCcXWvamXAfWVLLGPnBeTZYYFbeRniFo38leMomQaD
yj5/UTjv2KPg1CPXgvGJOKXri3ORV3HETn7ptPKciQrAViFewgVG5fJAheh4FXpfJOFiZS0DybaJ
xANKrIIOhytNPtVXs54Qnamcu/r8jhANFwAChDmawTCTfsVG/K0gmWE/1rSZjEuJSpE20nyVIM2g
u4vBIAiddzvESHVgAR9B98hgdsJJn8RpnFLlM2gr5BnzP7UYNy/Omhcn3ulZ461WRJSkgRTn/WK3
gE6P/YL4QeS7oCX/u8Ave/TFvOKP2y298US9JBkk/ev4W52KMelJxyLkTC/j/quHnkH6SsUnewZb
sc8zTpQPUj3Jlxm75/tRlDis2+H1W7UZebMukfIjUCX+bDFOgkFHbog5gfgV3ThHvY0fJyH5R4li
Qu5vhxiRM6/p/UE2iqhB+wq7pNp9JDyvSDFw9jdoogr7frqoEiZ2dChDrKqv7JXxd7m95kyohqv7
LvY9SJfsUnbwbddQM0ZezzMeQbeNeV0MNu+MsyjdIm5oSvWWfrmA62Gck5cnBI2XAddnykuVeWvS
wwUbQxvO47mNG2M8MpQ7BGVGXBRGLWrgbJw0L943ziiNQ1rLLlYz9PD16w/kyUqxV/cw3nZqvkrD
A+EQAGvbo4mXz5g1+Xg+BboG/qFyiUOFuBGqAslrc2sErbm4bF8dSXpY2GFp/giFxuq9m44tOZzA
pgafbvwNzUrprYQ/COZ4//smlmiH6GYyKZ5jgKXNYz5mR7ixfzPsGQDnjbfNI2P6Sho58VwRTzD8
EgMX2eQMg2liHV1/SS9Vk25InsCcs0nXj+hthnX1jgKux0vccI1J/BifzppvTGBnQE7dhBwccYnC
xoYUe6wwPZ7zhPa1QSyfPmlCcKuNJa2hyRjf0FUwmf4ikv4UehJ9FeGBPzsgxKeAZF4916TRNGkO
17iqAjbPflhj8lZGxZT99D3W+ZsmW72bRaIupqxhmyyRpXDytG5QEuvls/o15cuWf55cXTLKZayb
60B6IVuhW1cKHVmv9fZTgqZvIgg8nvYMQea2WRKA3fQNligkxvT5yXk8mIzFJ60+Sk3IrDNenXkh
VkyKpw+at6xKqU3Ug9HKWgkRrtEFkZ6/rcao6RYSkcnGcy+7D9YL2udElh2kFiSQXuKpZ+jx3nTm
lqmHnre6WBk/1pzRG/eVRjOdJbyWkQnM0/iyJE/2v0P0FAhClFPTmB/e4DA+KFly+WpDu0cAmnkW
IyO7txcd2GtfXpGXQeZbGAzorbzEJJLzAnsptAvwzKXN72zU7GPuWcgTRZaih9lrEQcMZ2tRG5sB
IdbpC163KpcOKVIYRKksKMbUl2i4UbbmQVNrsMaaMaMZi7fIa6Ez5M2wFUt55khv+oi0jR/J/Z6H
LzoKNgqZPwmlhz4rc123cAW8CcTfk7jFupmcKKyZAvgezL2ncSvnD7rNwmy0UZFlz2n3en8xNjr9
KXmKoZeK0lzGtFwFpYJdihDPjlZBhnAJRKbbClNtBFVzMr2fkGsF9nMgWLKnMyHvJ2ItEQf7vrnz
kQphlrQ6JFTgzMYDYF3NLkWhZvl4ZiYJcJjSWUs9vZek0xm6jE9M1Km59cnZc/kkupim3eZn/aTn
btvCL6a6isbsRWHTXuS1YKGZZXrZjNtPy9Pq7Y/Xlk9uRqyiLFlO1JqhdV7pMdm1gkpJ+a3yIa1s
ZK3EWrq+tyZAZWeLLdYMLPKUs0wzUV9Wky5Cz7qP3UOWaYprdcOQa8tWP5I04361WvFgJzXyb6T2
Rx+BOwAF02Ccjs3ivO9xyjhvXHm3U5g3Abnhcz0B4c9mI/n60QDUU4QbigKOw/ZABxIWj8F8L2Gk
wBWVHr5jz0L0VW6T9fQRe0BPkIVveGFvGXmzeZBBkwniJIirTFC1Aj3y2t9BVT+4G/YCg08JkuJ8
N0GuyrnuN29++eUXKgFwm8Lv4YkqeSTDGySAVgjxLGnzlW2bYM7G8STx7tcrfEnXvmytOjEs3Fqn
cQwLwKiAu9W85OGT8jiWS7nfSjnbymWOE7PzxLJRs14A8vFe1ejI9JhePmNmTbq0P077x8AGZkwW
0SJCF/lZJ6iw8CHyZD+pUgmv1KEy408sUOQuxItuF/M+LuGAdJ9DwfEPfN+EORE9E0mnBziTFNrv
rjvHlz9fqNqsMsunQEWf+2j6e2yVvVAZbaNHgV4PODAJRsjshPBh4RXXlklw35BtzfHntPohaZKM
5uUkbkmFF90kTXLZZZx6qVgAqo/B6DGPSA74OOzXtjprlTRKOxcQQb0TmM42abwgUpJJ9Jg3e8x/
DxkLfGp+o511YIo0UktQWnZT6qGvcHzOA8jU0F+iOiV1JlSq5fVF3A9LZDVDd5FsNLBJDkq2P03E
ICBff88g4jPKxMrNiQXCKdpObialWj5C1PtlVu1/Obl4f9JSpffMPVBmhxF6Niu1kKB1ieRntByT
4rrZVwnPdmpPql6OOhsu3w57w2nc7viwQrDHG+iwJ7uuPQ9118HnzK5DXM6uk1p0TJDsOUkJo83s
QJ5I9aiKG5NwMv/kSEggcoyGrKqXCM4XF3hFw2rSjgW76PXpv5dog4zV6J7O9PDIr06u5xv04pen
CHaRLCdxgwKi1lsqGHJZt7U1Xs9tqhNqQOLrAc82sSbAH3BUy20DLbeQ4ZLK9tG7k2M8FZPoYMGx
8RvX6/byqNeyJeMsjV22z30U8BKLNRUExW2mpnJXsU3rZhbuLAIuXManx9XtvdKuWRht1SrVIuS+
hj/baKwm1OX4RctrnaDHi5NjcimLbkJ2XolXeGUKeW/R4Mk7bTXOIZ0ctXQDMSIjC5BRNGcK/o6m
F2QC5OPEOxkMbxYhW1n9EkxIXZXhBj2Kl+h58dV8sga0HSYbTpEFUdNB+9Igiv58stB6fOEk3iiV
h1Vv6Xe1UMA2S03ByhHr6oAMlfT9F8mAtMqx7Hjc8uCCfJFsOBGtICfbIB+vt4t1EhLbmrFH1oyV
ovhJNMQpVBaEbpCtongb/o5vyH8X58PRNCKwa3KiEe2JRujfDSf9W3G1gN3loz/zQ3/cHY7ED77M
2ZzZOX9eTIbRo+EnSuN6ppMpug9GIXxFd3nQ5SCaE5JNY5Z457F5525xR7wu70hmxLZVelrdeNip
e9UKGlcJkFuYg2TQ0LznYRYKeyG7ZL3GRluJkjxICqY1V1yOIo7K+mic0HtKsXY9iXf6qGYN50EP
5/k1BKHx8imCS4a0pL2RE9foKfFNw3+JuC+V2PaW5hjuSK/ROnrnkd+fNnSlMds4sjhMF6ylZLdQ
rv8kDUPQRpVOOnj+0gjisEO5co1iGOoiLkCYcHL58g8/5M2ShYJpneR5TieMsBWuuIHsA9K8URW9
DceXJxk4CwXz2FVNpDjTpziDrfk8AoOWiasKC8J+AUGppeMDpYy0t8XGS4O7f2bfcl89QH/1AP3V
A/RXD9CfxwN0Ylk8P3cuiSrZ0DnWOBrOmpnEz45nC0qOkVydXrC980Mhl8cwmWRLcxPA94IBhREX
AJShjBCaFhSkoTk3AlHQvwc7Dw1bOW/GeXEuxfcDkDGhzKmvXIMNBjuWGFKuozpusxFIBCjDd5/G
0m3ZFceRBgewnS4IOw4kphXR+UyJfsfBD/ktWZG8Zpgvoky8vwfhNI/uQJNYuehEPc72sxArZDLg
JuGTkeCBUjOkY4kbldQFWCQ+nx4gXYuvqgpI8C+gDeyWlmkDPflk6yXeaxswN8v1DBZC2HbRTZl+
lRXQ0irUtWHCsW0caKIf9EY+PwGLvpQD269Kxlcl46uS8VXJ+CJKBp2qOvUMI8fUK/C53FoqRsN+
jn3GXOLW3JgUZaUWLLkKctjGwzd8E80+ty78Dkj7AO25o9lwhB7E2aLbLhLNUpbPudCRNgvTaV1X
4dkgcmAEwtKpI2nd6miEHzfCH+CjV9WGTVcjwpqjyi1HWt2Rtu0iolt2NLfiSKs60hzUdLfkyT2F
VpxBB3rz3IAQ2knVdFItnbSVTuKIEYm0bUfajiNtN51WKTnSyo40RyMqjlZUHM2oONpRcbSj4mhH
xdGOiqMdVUc7qtgOvpDBADE4mtMDzPzs8buSODD1S8NG7KdtLBNgeK/c40CJpjcBoAKWahwIJrhY
l6CgfIzza2G5umZe48nMfe27JKX46jnqM+q+M2jYtPfxGeqvLvEFNOB6+TPFy35SsfXxySm3BHpp
MRh81We/6rNf9dmv+uz/En2WF4Sr5sXZ5dFPeC8YK7TpLFOj9efT8bCXOCfTRTwqc01Fobv/IUrC
erFuwmDwiFzJmYc5uTIvY/YCyrbfXujf00rikYtJNRN783Ux6n1MGniH/LIaxus/pGG6djQ4nj30
bm88v/d3r1rJf5+H0hs/RoirEBu8J4kuJkiVHs3kO1RCf+AAcTy5SLZmMUm0R6zH7YFVHwqgE0es
Zi2a1zbDYLQJE7X47TuK4RyW/jr563xN7O2JtXDNbo707Ac/kDkOxtPwcU0scaqMnDNJm4ePz+D1
qjxOsMnJWeUyYTljDW0nKcCfR92JVrzui77MVV955zOqNmouEN/oy/lGG49FC+Y8QCnG6M1RZOa8
hxHzvAKK0l+hezZvRtOuP8px8r5Opph9Odip6BT05JcA42979BW/27Udm3VJJNDNM4nE7vZUUz5P
t8vpbpWel6BfoPO3SmlvXE+4CpJxwpTXf6MhL/cM9MUuhu1j6vLu7g4I9+JGtPxuJN2FLT2C/hqw
7GvAsq8By74GLPsasMwVsEyq/OeNo3foSqrRuTxvHtk6vyNPLzTv/XA4XUQqaiV8m9/C9DakYGCs
SaLu27vFhYiXGXUiMMOpetIL1LmDGfkCJoj2+RX5sNnM0Ek8vM09Pzz7lYwGl4d8Ngg2Y6xGorsY
jmB2WvAMxcqoqtBy0Ht0fvXL0bu3+eh3DL8zLgqyfp/d+SMyKae/6GaEFRHPQ33c82KNXOsoubXx
9A74tNnr3R18V9nfJ608zpVErIlvo9/F2ib+DcZiTXxXOviuVvyuWuSiXIqKgMp+EK6RCgw689rB
GD6vz7QKliN9H98QIrUIgd+YZvymwRWw1P8LFtva0zFO9GgxyItkzLC4g+RGwfOMrcIO7hRSuv5O
XrNGAq0jR+VnzVn1XVIbbyd29G4CEqwOKsPa3Pt7Zv8k9gzJPY5FernupL1ct4lHME09frHIp4QU
/ZTqbkDl8zWAt2mujZbVAATTDaCNmtkASkg1wNjPJRtQ+6INgF3tv6ABUMtnaQB7XUz1QL1mNwDB
dAM4FI/RAOXo224ApbobsPP5esDRAOyBL9+Al/SAPnHihaoNq++Jd3bZOM7jUoBqfR+de+NLiALP
jq4mf/stwX37rTeXcyg1f9SnrpO5dvONIsAFnkv/IU9UaF5NAIm7/XhBiKHSy8baqL9G9MJSALXT
KlBeUwWFUHP/XTzdc2pyEZCpcmrX227FxTtOosQ/TJLij6uxipd4D4MbfWXXS9iFkvp/i1vSMN/F
NDwC1eDsdn1O888KYlVMpom7QpJzDp5Ec80TqMjJE3fz3ZxK8OQTmi9FJZpPw+ArDzQPnhov/zNZ
gKtVepXCe9qigMVvrYzqdxoguqVQYeU6gFTcIPTitQpK5FrNDYBWKEVRByVnbYeV/G8XtAdMgZpL
Ki3PDEF7IF5Q8aRVL6tT4oUx67i6E8vlkv357beICDrHuWJgEbE+4zoF8tbsP6qQcqYYsAf1CSMD
r3UsccNgAgeAbd9IS23wlPJEGLHEdCbupOpBRaz7nG8OEMaY4+TEx6pJXPkfFskv5pFz6P/reaT0
s8/MI5Q5U9bKehNYJLd4xdxOMffPgg1UibdaRQaCEZKCqsXbAQkFwyQFtROrrBIKhgpBLSGsN8I4
L0ja9/+1jDYJh9SlAC3yJCASmAK0KJSASCMBLiHS7/eJxNfLKCQgpC8JZZFHUEhcEsqijaCQstfL
CYsW3Xno97hvN5b2rYZEEpOgdgdrUKQzCWr3sgZFYjfMOdEoY6fJoWBOkWpxCubeDkiz8ZVOPOK7
K5lDXWeCcoINrLACL01Q/OrGqhqD0MkkWcJJcrmeprlczyDaBI6pNsBNsk1gRbcDs6YS4V2UYxkn
6dVKmvRqJYN0Ezgm3QA3STeBFekOzJpMhHeRjmWcpNdradLrtQzSTeCYdAPcJN0EVqQ7MGsyEd5F
OpZxko7Kik18WmqZSoa0pd5Js42SRD5dtSLOwhpLvZNWbIgNnxqVIsVYB9nZYzNVID1CUy3QZTLG
qaMhuPinGoKJWQ1JFYiT3Q1JFVCJSxqiy7gysiYc0mWtdjjmD6bWBlVTkJN8G5Snn2zCEzTEM1Cm
FKWpzpj5YoFxUb9kukwXcUyaTlniUllTZ4Y0pRuEqZkNSheJ0zMalC6iUpc1KC7lyslcC2BRtycl
x8zOFBNkYmlw0m+h5FUhm2wTq7EsZMqTBZ9eu9LSlCZ7yfqVLOBYw5yS5GxFVkEpMsmW8EH9EjFK
tySjiBKXZEsywC1BcbZEFXS2hV5pWC1xrLBML4Mm1mgn+TZSXp+zCbfwGit0phTZBdJ6RFqMHKQv
USZSJRwahVOQqFCWWpEhSKnG8IXDEklyNCajjBKbVGMy4C2RcTZGFdQ3pQ0CIC+y5G4rZFOZO3+0
wCceU3QS5c9he83WKny/QTfew4G2fJnfT7kE+2Qhb1OwZSH/Pwa66UDj4fsRNOKhGO2EBZ8/S6ya
Fo7HWRST6YSyyZbmfhjpe/bkaQQ5SFO8Hc/iSerT7uDk4bDrcjJ160Phwjgp667KQeXnuCl0USnx
rkLl/y2R+NRLwSyRALyfUSS+BJUS7ypUJicxJszYOFpjLAve2K1ZHZDeOXKutdaqKrOA7elUVZhF
SkopWYX+1PpvDtllNbloy1rsYpyuUvHEvaJ4z+ZhLDnsybIfzZUPzuBhpj5GYcJvtBQZd2vyhjhS
glgv9O3oGiLPOQWqRH3Bap4p+5+5CYq1n6UJblkEih29DamuVqtIY7KAvlV1NHtmj2YVvyRZMqt1
s0zO86sNpSXoiyoXCYrZd+oNR7JQZu0xB+9Sxg/GkaV31WnlLxrnJ+o+KvNyzbxnwALffptBMc6J
kEPXaOYdw19j+jWGJeTf8SXBH0bpzOuQZURm9e7zCF3a00Ts56A1WwyeQ+sTciFpTZy3kyBEFAUt
mUrqsiMdlGJHqlJ7M87IEWa5LZdsDj5ZBv1G7budSlrSWEtGbVcvtVBFolsq867pm+Qah2syLcil
gmk2tERtiK2eXLRmaA9Js6YX0Mr6w3JaEyucRRkup27uLi9n7moSTVUWoGz92R3OxXQWSBc9tsmn
NflhawCYvFRPFuOiSEi8EWNYdy7Ay7tE0Jyw8SmJkOzDoF9pcQHhp2CY4rXIQ5XovmqLeIhEHwhy
D0kZ34sqR6XqT1/JKGP6uhO/QO2C7irFP5Emo8PyGVsVRXRBX3K6BcvzJHuYu89l0NiPPn4RDiFi
KPFf+QSTCqYAZ/DoeyLLkupP5xLpLnOMPGbxCH3Mz1fhFA82dOyQUF4w43sMh5xAlWRR4TfFoA/4
22aJua8jImG8eFLixYZoB3Ph01DB7ZvaK8wjYhft0KgkoNwTh0N6GA6F+WUQVL0nGnE0bw7XhQ+2
7H2YqeOlSFhBqHSUqazBpwAcHBrvm2FLxs8SNVUqa0yqfBY6kfiRIjjeT2elB63KWSqWY7dYJqQm
z4IOeAmolCUDeliDFBzh5y8tB+i7XgmCgwyHINhhFbimTxUJwGKJhP8JIuGcg1aSCn+pVHz/HKnw
nyMV/5USC/erU/OxinrNEoM5nth8lvepUPtKj1MJ7gu8TK3u1t0vU/EtkKDbHREtxmN8YjgdWB4A
adgQ++SbQXq3ihwJ0JENoYJccQsaSxBKRySAozmZB6PoT+LktOl1ptPRx+HcK2+WS5vl2ma9wp4Q
KC48ukTHQzBkyBjdlOD7pfil4ZBDMwKrNv+nP4plT87lDfhVKzIDIDucTZmVm8bTR3ypd9o8apDv
CIdTD/YncXFpPkb8+V2j077EJ3JFfq+oH7PxQ7XY+UfKVUfCAUfRfMGoX1Gm3zHSyzkbuXoop9/J
yYdxAMV+cFqXUFK/RtRtxGeCjfOrs5NNcfLQC2YcGt1n7zIgBbGfFekghuf0KWVITzjSVaX0eIOe
9PGh2gRkBp8Rowd1PDoV2sNM8DCjmVt6mUHBGnKEdwGT9HQ2g/5Rj1jxlFX75UG8o1FAMejwTSvo
2vNH9a5ZOpmRvn3I1c9wgs87qb/V+9mInL6Mhn53OBrOH03HOjoR28CUTQYh5JDU49gh30BQbQhC
jUOSayZTP2g8oAA6E8NkOlCYpuFYj5w03zYVnSrC+b0fUtBTYAQ+KcaXgDyo6QV1tMAHg1ZV+agg
7ofQOCytKGdAphN4cRzQ+hZG9FaZF9gpvjEZPYqpej9Nbw6xXrRYgK1sEA4jWE0jxQEVyklQT7OT
Lf16G8b6R+D+mnplvoZQa7QPxol+c022U+aj6zD4RFIzWCBa6RdJzWs0zbEDn1v/LkA5gqIzqG4o
O+se+BFNgzuc5JDo6WQAkjaPxWvCQV0Yfki3A8MIe4tmTK4V24rTl/RDNN6Mp2L1wJrm5AnL9jjo
o7cn0Q/9wVxWO2YpQaeEdDERGb6NCBtXof038RtwvHzACTrC2X4BSyb2R5+6SfBDcmhJ18cJecpy
wwySRDGdxNIidR9zdzS9mbKHpubcnwxBW6ArlRBqwg6KWKrYTRo+ytcZ6qlpapKkzp5Tm6IhND5E
Rsp3qtcTmirac4y9QbXS0OVGo2qGwEzpJT1MR0NdBuyCjPdBGv1H9M/EL9zRnZZ8/ypHOBBEGCPH
u1xcx6zHuCrh6QevqgiUgIn0Iu8XkhoS/0CGBeydtFqXrQxw2D0NVVhrgPhB+lG2EbSvj45wmnf9
lGxQtDPnCtOgkA85+XKCPIrW3Tz2YOFonJ90TlrpIpVEkeuL9vXV1WULX5hn1FJNFDkEug6vT09P
WunwE7JILVmEwTuXl177HB/ap4tsJYpcXHa81knj+FcHp2SReqLI8Qm+enfzTBbZThT5udXsnHiw
RnZOjpIskEV2EkVgffUuTzFI0uV1CzrTUWQ3UeT95dn1+Yl3dEnv6+1qVFeW3GVOr21uWWWS/X9x
6Z2fHDcbDpbpMkkBoAIeaidvUyKgyiQlAPvm9PL6Ii0ycZmkCDRI8KGPLpqZ9aRlANl8he4SMutJ
CgHyoHF1hZpQZpmkFHSa5yeoNi3jW1IMkAftTmPZwCkn5aBxRhLtLKfGZ1IOGofuwWmWSc0DR+dX
T0wdlaQcdE47T5ZJygGOm8ujyzNXOVWmVkjOgTjlwrzzE0Z8fXv269U7uxTNyMkWUZnjkzOY1LzT
RvPsunWSKpNsEZXhAZ4sosskW0RlMmYrVaYm53XlFlUdbecAjYcHEAv2hary8ZBpPUe5HMYvK5dD
qpqZyr6fslErwy/7tvsBWOf7fthH8gSFJJM7P8P3AMeDBRQcV1jlm+fyuTYoHqTe4ZnlmzegndwN
I1ZkDdSW6lpkyAXo7aEo1wWf8Iz9v5GSIYtPFuMuVoaQo+m9BTmcOCHV0UhO0bBvJr4j6tvD3wMr
+ah1VK3s26VZE5V+bBNebJPsSCVIRivnGMCCDugokqs2MmBlLFqGH4Pcr4Ef7st0jA2FHpo2YE/6
yy/SRTO/9MjhCcP8dj8GBKhyJQFz7D8qXAqmWk7AvJsuzApLWFs1WddwspgH+ybM1m4Cph2gU6Ll
MFd+v2wx/MKfTCNZUBba3d0tyn9cWnEmh8z8y3RCdADwRrlWK6ESTn9BLCql2naaASPc0OwnqMBu
/4P7D5DqfqPTQ+ugZBoaUJsKneXSRC0HXuP4P67bHe+48esZebyEn9JDqeyAbF5YUBKyIol4T7ZH
xr4mQYXiQ4oK0Mx4w35yTPX85fLiROLePj3lOcAhiIkRMB2Rpyfdk+Vgoy5mfjgnf6kwBEcj5UE9
Ltfo9RawAXw0JAmU8PnvKSGZR53pX4JwqtHjIT+ds9KGYYOlQWBTqazRSz1/5quNmZ7TVGvMmVTk
1/Er+nxmlhVEPubfejEL5XphfynCKAPhE8WQjnv/Y7CYxaWVoxb9dMukaiVCMjCm0Oj56JzezfIJ
D26p76Tbsfk8FLR5fhShz+cAMzplkYd10wkuMkN/xAjYdRltsH8+LLZbxfbPsK8OJoliP2MSbMWn
PT7uoA10Cpc/uvcfcU/3MYAto0YYY+ATYnle8vziwHo+bMHDSUm+jzdo1ORWh4ZWCNtOFDfa8ek1
ULMfD9BxjJwMhmp94Oo7+GyXHOqXWMwB4myKC8HRtB8UzYRjf+7LhMPpdN7GeJq9IDLgzGQDusW0
OQokcqgMEVPXxCh+TSeKYwyxrSGuJ4sIFzCZy4mNo6tmK6ANtllqV5dCAM65eN/mzDIGEtIAnHnu
wzLfb14WXYlX03Denvk94CAWrxRFTxe/8kfU0ByjrhZFP0btP8Tc5/wayLwxV3A/e9h/8cQ+m0bR
ENWRHnlpvOHOjg+uWTZY/pPT6vnJ+WXrV+/6KJeDmdT+KTtBf3aBVtygHQdozQ166ADdyaD1JA1b
LqGqgcy4fYzQhFY1exZOMdQnqW6T5Uz4+SqJt4xXFC7QVgq0kgX6Swq0RqBAK1MTBn9fDPEc0dej
FcbxTEXfcNV+fYFLIKDdSXAsubmQBY5P2ket5lXnsuW9P2m18cBblF1KOwkZshBt3cOU8q1BKHqY
Bnli3UVp1qoaL4zVCim9M0Cho4wkqs5dyZ5sY1iufQlgVJx7z6HKdL5W3i9Idb4cXGHgUSunMZe+
3vcTI6ofRL1wOJtPVYsUFy+ChzkPymMNkr+ah0VUuQt4zpWBZb2AZ2BqBSwIKFMQrwUVKzy5vuMq
qEKx+XzDS4HK0KAql0fjCt0feu5B1EUrKybZyqOL1jjvfRBGcv+Sy2qMkMyGagCssP8E+T2cnaGn
ZlM6J3aRfRx0FzfHwwhmr6HaPuVo+7eu7rR1Tco8Xry9bh6nVrHsXQeJH64eWjMnbRtTKqmUqqVI
Y0rtt50P+0JJys1i2E/vgo5kRG8+He7QthBPdJFSU92OT2ylYJ1ftb0OetD0EFQa8f0D9Nmgu9uv
9CuDInyu9Hd28G+53K8W2aIQQXZ9Sqzjbwx097BLvyvb+LtKJXsYWe+h1hd/2L7TcX1bVm+19AXr
rZSMqoVQNe/s1HeCnW0qGdQGZUfN3R5VVNE179DvHtdMmUzxTjlZc/v8sHnZtiqOq5aNLn+ZRrcb
Z17713bn5Hx59ZXPWz1MsMfNt/WawMMBikYPUgp7n0B8z8NOoIbCwmpFcM69Ozq+sqSDCC09DHa3
yrvVnT7WU6+UulRfJRgoOoHv1IbtXfztUztq3TilThRuUzps+iWdzlOInjmg+AiC15N4DObeB5P+
NHwLX9i+jc6MOLHDYejlmHUgS54Y4SCejfw5uS6+88MhAqWHK66mb88uD6FH3zdaHORB9iT++Qcu
xocnteNTbupu9aghO5MY06BvpWP6XWK2lR5OuEOJLaUqdeshCfGR7sj3kiLay9DSFaXUAkWQd3F5
gSfljU7zzDwi1upHOaPc4eVlR3rJlSfTdrlKRjmpiJhlrHK1ZCPIU5IRsSWl4DR+aZ5fn8c1JK5U
yqVKbYWdsepGY90xjwzXc4qgC/RLpLKlcK3H0mWtmOux9hBZy+w6LRZ6hZXiiGnJpfLVRgbBGOkp
ppr80qeXTJtsXd/KLVs3xs0qi3j0iZw067M4mcXIp/motvvDqOfczPJMIXez8yO0zzK+/+yHY/N7
+3Yx70/vJ2q2wJODubm5Wsoeho4eo3kwTrDHREQHr3PaT6tshSjHeW36anPCZoXNci7lkq+s8UDi
dTu8ufXG08nUo8tofbDCxnnvIPcI0wvp6VFuxwXsx4d3sB/nlcM5RaoZQfnchgH89qLRoduG0sNW
fatS26pu1WrB1tZW5frs7InSrZP3Tdqu5PN0X2za7MBk8R+woVEgP/xQrheEenTxT+Eq0LwwCrAW
7tq5pM++c7l3fQpniAGJkRWRPJqIty7xiRxU/xZ6HD6rXUtk5rXtvNQJGpX+mVKSOBJw7STcG62n
q+1vms7MnQWik6Wl/g3Kvqo9pdDnckecdMUpqno902PFaM9hMSieTqiVCtrkhWsqRFjciJmTjckX
E23bRvuGZwubDPd4ULXgUDiH9Pl0MuzRmFB12UNeDV/6SqNGTiM8XDzFez2ZWKYPS0RZJNZpS4U0
BhSvtVs4ona3qpVSbbdWqe0uKasr+HLjydDkFJ9sFS4xsHhcmXv002E4xhhjvHhgVM83dKrDdsHT
gTh612ihX494PVFF9A0ZllGJ4o4Q6cs6qs28fsxJ7bg5eUcp1okB5DUn+5llLhdzdyHIcJRS15Mn
YTgNHQXbc8xKMCRxGrpvMcQENM9ZE3yzMaoDEprHT9gwidByBjI54FS0beItbqJ9sVrNGne6lwhG
rhTOyJlJGUklOAcOR5tntbBW2q07cs8b7Z9oaJzizVC6MIaqB12ykhqTgNXrXBJUm+yapHafh/Hi
U6x7Gwke6FDO94nK/12UxZ4oFYQ86aGXFXgU4EFtHKRzH83ymQlq6TDvXcR8fIUw1orOZuj+aOSp
wzI8IJNvUotic3NTrd5GICs2BPssduK30IEh1k8+dlcyGU8W+RJBrapbpvX4Z/0hHUi3QQY+kjoo
tPayvaEj1BMUzD8w1dB4p5shNBfEdsfl7ChFFdhcSYPsn0RDnAIfpcXgyobkw5QduQoSOaSINzeh
P0YzTAryqcJ17ovH6UL0fLyFiiNgCn6GouJecshMTETDVb5NQKtPHQ7y7cW1eBtMghAUjiuKnSnO
2LoZJl06VBQVfqoSqYCbQR/tm7EwxpaKY2Oewjrb9/lydhoW+dotpqz/igNxztDuH8106c4N0ZwN
J4sH8TEIJ2wujXaubK5JAS7nU8MKUwcrnfm9j3g4vCTwpjTTNqJufsEYqhTHiaLEumKkLo2PSpie
FSN1aXxU7vhnxUhdGh+Vu/85MVKfiI8qjb//j8ZIfWVEgvrkEKmE7DNGSOVD+s8SIPVVIkTSp8RH
5WZ+hvCoKjKqfN7yVHRU792vV8BxYA6GyzZMs5MZpon2QzB5w5ZvaCcPcxqZadv5UQ8GhyNdzrnS
sFvTQbWBjg66OlmIiwC1T7E2GwWw2sAIm/xpruSdxwXNRP1hCCNu9LimtAk6FXgDizce4cGk+wYf
FABkiMuiatxo+BGm5/yDMgr3PAqdNJx4wQOslPP8N99AZlGYJo2LiV0qqwybkIO2AZN94o2i5+lF
Om/n+OhC2E6pFNOPAFM/iTLVFJbaC7BsJbH0xqQJqguuKArGoPhizHaYYUh9oHZtYMNMs38lSrrV
pXzsab2gnELkLX/dklEhbQ5UIn0XBxYD8VQ6/l+7suCuMaSJXY2jW24EIAIKCfx/FNzklg1yYR0p
Fz6NYrvPC9DnFtVmg9wteHYDKokGwL/Kl21EMruS0cbP1MCqo4Hwr1r4b2xjMrvqYsHnEtFaBgPg
X+1/MBOS2bUUjz4Xg7aWMAj+bRX+t/Iomb31OeZA3u4bJa1V3pvO6B0+rAfK2xNsI3g3nygHK70n
V/pVi/T4sMobTuMS9AEPN4u0ZRHroOI7C5O2AfR5/H4wxpBY2zLqVsVXphV6vwvbs2cUoT2YPDKC
UpquRPHFdGYQrdvvRDmdzT35wDO/vPJoEc1APUpoHRHoTm5weedkUxmCJjadcAHj6MZWFD/LEQ4f
Ic0WKx3exMBf4Nhmu/q5gpH/GJ93PBnKWgf5/cKP7flsp/Q1AvXXCNRfI1B/jUD9NQL1J0SgTh+t
cGidq2v7ybuVahyOrNE6NsB1bM0wbTjW1pk46FvBDX5qSXcAaJ8ciXyrVYhn5xYZLQ+GwagvlNmq
shSzvGq20M46lyulk88P/1LK5crpjKt2LldxJXtnJxe5XD2d1UL7vB1nOpep1Jz1l3M526e9ymse
/+JBb0BlZVf2+8ZZHu23iuGwT7bNFB4V/TDFxBbEPyGHAIx0oIgvh03GB+IqNs3/KXiMOZ+/+sng
OnxZle0A6r1Psx2Tfz5Ocx3TW8dptmP6L5BedaRz/yUZizk/nfya7g6ZQf2R6g6Jz90f1BZ0X5DL
sbOrONUOuN3sNJcxKLbtJAQILRtRcmXZYmhlUCPqrrxE0+2cZNttOmTj3XlUtOys8uoKBLzmrBOy
uOBWBt4KSHg1cx64arfYYwh+wEnAGeYdMr1DxzuUUkqYAPA69QTEfgejARuutzUpmQLA89Mz1xsY
J+Q777DZyW2582zpiuELrmbg1TYUMBgAw91opfincnprtMgEAbIdMFClq7rmERGeK6fGIWUi5T/8
kIAuwLYp/S7H2XtNid3VD80kcjfuWhbuq5+SvbNjPQ/SgMfJF1KVUgZgqsNrmZDvEpA7GZDthFiW
SxmAVwnAShbgcdMGrGUBthOAO5kY7XdhTKIL8MymsZIJ2LEx1jIBW3bf7GQCHl2ZfVNVBdyQMCW2
LtKDPAu6bGAuPwFbMWArT8CCitZajeZm20BbWwJ4bk5eO8swGozVbXICHseAlWWAx40YsLYU0MC4
swywHbc6JtEpJbEk158A9EqO2T0DNO73ylOgcbfXngIlo6VcLaUIQe5JzJmdpWgOLxSgwRhn7+lO
qViA1gMZdP1yfYXwIm8IiLloXP0E3/5q37VxrABjGjULtDpcIJeAOrwwodRYNNMaR9ZR9/llG+0n
k9RZS1rT+tL57yT1Gpn1P4BUnFscpDq1reYyJauJCC+PTxKjZgA/Dsj3sN2/bFmwg4FDNhH2l6dn
VQT7+ekJFcFaT0+QCHbReHp+bPK6/OT0SNW2n54dEa7ZenpyJPqaT8+NRN/l01Mjwp00n54ZGQ5m
xicnRglZfnpelJCVp6fFJk98rnkvltcj3l4t3XkCEGtJjnTcJiRnXEw/O0pvPTHdvcVUObTBfUjK
P+Yen6f3n5QOdO260kFJTW0ZKOMXyHBRfNyCDBfJuP6m1HTKOHZo2JRxgj6lGmdn0JjtQapjZGvL
mRwqSz4YP/SaJLWPlpU1rs86cmLkPjGnpPdBbz4NpccltrrAFwXTRUTGm+zrMlzMMqYpmHi89++u
OripSTYE85qds0PMS7IU845lXrKZmNc466iySd6qbFk8yWHMvjhpd06OFURy+0d04e78vImqTup8
iWgz8rdd+c1W51feRaUEj/BftDvyaWAuLYKEodFpxBApYUSQw9ZJ4yfinot9J78Aiy46rZxDMDGf
LLLRNx0ef59cAKUVVyXY0KuTFra1eXmB3eGqzGiPR2ZteFbiqtVoVgzo6sK3JxcnrcYZNOPohM55
HYd2zOk2nnQfe6dXSJyrMy8aHQ/Psa/PFSJXl+IB+PVZoyNb6ezVk8PrtySSrh67vmicNd9eACkt
HMF4PAzS6eIpu9JkXpiwLs6enl0CTRdvvatL6E2PRqt1MJQJ2mk1gCVVF3PPLn+GKeaq1XzfPDsB
MQDQizbQIXJVF487jZ9OLkDcGhdH7xRaF6Px7Buf4XROrhSYi9PNRrVi9muu5hyCCEUH/QiIUJm4
9HUAQm2nT1Nv/bBPFrSt9knCK4E6WY1PstsJiHyrfVRY5RSRiQJo7xwUM6k3ps65Ifsq9tOZOtaG
7MP4VW/qlBqRw0ons5NsU9nee677oZrSBhEE/cW2+ElyOXV4rvPxoFCkFihZRVlSkBJvlW+SYK1B
bxSbj/AuNnDfEUgeeme/ijxoIAVBHn/O/N8flwC3mwhclsBtjABGy9MkGt4FyyqhchVVydTvr1Ts
pIHFqrLYiX8ThG55QNC3J2rvYZSXp2gqJXnQhyXPGn/5NVnw7Nd0Qbm6a/PaOFSCfGZOi/VgMeE7
hdh/CZ3n3oymXbLWptVchsegd0h8O4TgCSeQiMp6nnUzc3tPjDEYHxOOZE7RCY93en1xlB9MyHFM
Pl16vSAgc+NHrLmQLPv2iks+UfZmZl8QvJeqDD1UwXcErNLEDstjs1LLm5o4RQfoWaE9OUQRVT8e
8Ism5p7n+dEY4FRoj/zaeLAm9vb2xBq/SV17IiSexOn5T2Hd9GNUkvLT0SK6FUd+73YVwge9vBGI
K7OmQU98V8ImiLVwLQ+AyVrbj5OeyVEUi8Afr0BBBCW94fKGIszmMNXUI3/UW4zQ+7p8xYvmCKiG
Sv01q/Y4bBlRML/1o1sHG3QKoF6M6AVsmjQqDMw5+K4M/BFrB+GayHOBgiB2CcUvFaRMo3O3hRow
92+e2Qgo8eI2YG2foQn8GlrIp9W6U/DZi3ynt2pjZv6L2zLzP0NT+EUXCpaYzXubgSnaK8g0lPEC
owWZgs3Ivyvt74soHP2+2d/fj0dZapAlqLp5AVWWjBhhe+kiexmVKCDF78pOQv1CkT4gkh9+qDxJ
t/8Swv0XU+5/PtJHL6B89FLCR59AN4aSsCNdz6JwxdGHb3EB2pySVxp64+kdDj0oSpTaoy97yC1b
GyQlK4wkrBybODqIFyphjqFl1QB7vf4TS5DqgicQ9ofkcRNDTIbLMIr8WggJSPKw90/68xTqYLIq
5igTs71h8ns9mKCn8sDHRwevMnaPCgnieHBDOmmjlY+f2ZiBXp2hXmOfLhJAyxnbjnNz4vL/MJGl
hM+0mk920/6+lEI/3FwThFysOcWRENgCGdf5h0XAkpbpILZxs6K4WYbcZrTNLcgm8Sl5ZgKxR1RP
fCwVjC9l80vF/FI1v9TML1vml7r5Zbtg1hRGPSOzG83sbxSO2UgKJ/7cKj/ohdb3YDDyb4wCvahv
fIusb73ByAQdRKH5bWh969vV9Hp31vdFiq5ZZJcYznvW99kgMvCPTC4EPYdhlz2yelMYs9PRk6Pq
yBpVhug9NaaWDylT6jIHVLY0wmjqxQK5+kAyx9HytsSjaIVBlGyNm+je0iFkjSDger+nxecIO39s
fiMFNP4+m9vfh7PIKmxKEn4fzszcgW9VNLSKDmdWbixzlGkRdWsTMRr2LZJNtPOZ+S2YDk3IMCzZ
X8v214r9tWpRf2d8m43Nb72xOeSQQLuiEVeUkP+3/1Pl/3+Z8K8q+cDveAqHL92S8SUsVwvo0mY+
s85Sfg6HpA6HbCysprRVdvrQrNBQ5sIQo5kZGvFy7S4Mf/uu9OHAVoj5RZrUihmh1IzvaMOXPG8x
1eOV2+DQj9PtSGrKd0uU5PIBNyZugJSrO7lLVU1JNEGHOVfNSTbo6Aq9q76gPb3ZYtinx2bDF6j8
VPq378ofEs2xdt754ZJNgD6JnIf+zBuE/jhInESC6mEdRE76w3D+uE+nshPts4kSkQFRHJqCwEGX
sIrDXMtl9c0mvkObJUrh3J4Gg8Qk3CBKgFFgj8WkJ9hzke4TuezHfpepwdCAfXKsB184EPFw0g8e
6HkN5t8FvUSNvcGYa+wtQozyKohnHHQxSd1MUTfD0Dp4EKpPiJE6GM1hvZYoA9ocl8GHiPjoh3Q7
fXbsh+XtRAlU9rhIGAUCvoDaQyE66S1QWN5NtgB6hFswHc84uCNV0ffnNDKhTGUrWaZ3lyjzIGMp
YsByLlStJAotNGF2+kB37mA05TAW1DzJFMZWKyWZGWpe9nG3FLC0lTbqVbNv6/KwnGBxI34zsw7e
DcmUQFBr72MGzFwjCnGgm0BWF1QYTB70YwuSzAir1jAId+yvu/bXcinxvZz4Xkt830p8rye+bye+
J6ovJ+qvJOqvJOqvVBLfE62rJOirJOirJOirJOirJOirJOirJuirlhOO67o2QNeur7vN4PJxDvQX
imU9ESkgIZ16JpGRQOzC1AA7aSedtJtO4q5OpCWbA+qra57zFyMiUJ34JibH1ByqZp7kvGhOz2NH
meFYhVu1ijld68ULifExdqfHL4z5iXF8i6YvgQQGTpC7OIyOBGVp32ZdFF5hpEhpUVpKJJOti512
3pCwlVT6z4e5UhJcQW8lki0rGkw5loD1RLKDhEZLwu6m0lvJJmDaL8m6MPHnZAMo8RfTQkelInDN
gZbgkw0jLFiizmFMwuEdKBnQDaPgLhilOX8m27KdSmcDcxQfHb9cekdDJIgbe5c8caewtr3aT5Yl
jUzd+cmy75Kp5fpPlnWXTK4jjnoqubKF4DtpLOeWUY6i49yyrdE1nlsWMrrGc8veJa4R0ndY6Om+
fDrG4+ABKOOR9s3ngVrjzdPCfXl6CpJcSieeN5K9jamNZJdi4nFSLgnpWbLXqHwrKZcEe3WR6g9M
PznObVXkdbj4hjP7eRjM5wXx/fdGijG+C0Ygjeh2Gs43OBg3X7qhw8/HTdEYRVN8r9y75aDUonN2
iOf+QajCtUGm0q2zwr6Q6oxsneX2yqTb0WvK0uZmQqEgoPCubEKVNzfLDqixn9urxlCVzc2aA8q3
Ktza3NxyAPUtoPrmZt0BNBvl9iox1Pbm5o6rvtCiahdodxE/m032qjtGG5H8XScvKmatW8CyLRfC
wG7DFuDbqjjghjcAZwJWobVVGVEqlv59az/VIB8WDulYvdtX7Pfcah2/Ws+v1vUr9v2Knb9q7+dW
7v7cqv2/sgBkSkCy7qpVd8ndHbMIENat7th2gH0MHgFbLYbb2dysuvCFdzVgjlFvtZJB4Ny/UWoR
veuG+WnoAIM90XAityk+u3MYjTimKmWZwj+Kpd90u5LSiYxMPsSjR+afzyHL4DkOWQZfyCHL7u5/
pz+Wz+yL5as/la/+VL76U/nqT+WrP5WV/amcOv2pnDr8qUwj25PKafoI0TzdyHzgd0oPsluNK+/9
ce76jB4wdPLpQKRJq+G43PGycpXscn9ZVq6WXe5yWbmd7HLXS8qVS9nlmkvKVdzl2qf5YfGukMvj
hcoPP4h8flhYL1df1wvpO8f2qXfa+UsuUUeK3wD2c+skCZZiL4BdHSWhek4ofAudaJgbrpyES3UO
w1WScKnOYLjqKvS1kq2ouqhr4SMrGIrtzgpNIeC3zYtTGzbd9wwLozgFm+5vhu20ri+OVqC3c5xo
Vc0F9T4BtOMCSmAqO5uckKuKE+jSBqo5ga5toB0nUNMCKnM3OEjnx4DSjYkUCvVc2erVdHEaXzYC
awrTt90KnzVRLcn9y9Lcy6W510tzm1m5ME2UikmuFLJAy0WRT3JQ3+yjtvZPU8wycmAOKWTWUHlO
Ddloqs9DU1j+qISuJVGVpfgZsGuJHqM3PYCEBRDVVbmJsVY2z/NH5NlTujOH7yrcnefl8zobvjxI
ArCahohgBR0F8WJ6Zd14bKafrOBNRXz6skO3eqGHq+1v5foHvF02iCnXC66bghiTMK8/nr8lPv18
W2JUL1bYDCPYF9gGV3a3Uvtgw7HnETn23BYbL9kUfwmno18wLImMyYGbNj+Kpr0hBVWxN2YYKyBy
hi0hZMtClzwvbAmhWxa65JlhSwjfstAlzwtbQuiWhy75vxu2RJj73U+OW8LYPmPgEkb4eSKXiORe
8FNCl8iWfobYJbwNlwFMsoOXJC+UvMs2up4umMsbJzlgrasmY7/4g5q+ce2J7MAla7GP6TUz2Z9P
x8NeIhFqSqRE/iiRMkum6NrjAF2J2CkKgK9JZfiUeKWMT5fxit+T5jRX8lWXuveXF4hSkXjXeI+P
bg+PHGh6Jpow3Jb1qpCdNj4decVs4U2QaPR4LDfkMtScH/ZuPXSzk4fxHs7h42AKNa9Hw8I+n6Cj
EdF4Otlk06q40CwEMglehqnLLYeHvo8D2knzAYxbi9MKeqqn7u1Op3OPDAlwJRzDROaRLZ6pNh1d
np/DiAWmXVhhn7c4Tp+M+iK1Fgdmfv5rJFztr1CKCmHcxCv89jYuQj7xCa43Zmp/+xDnBqlIheuY
1n6MKOChUTWqcIjmLgi70yjYN9rCQQHpDi6cdgMv8mfDXmQxk9h5NJ3gKs3XsZMgwOk9mi9AySKV
FAeFqRvCd1IKX8n4qDaZFEzYpPOJoLARB4XFiLDn/uxUFbCi3d5wRFudmQyTGsZhUk+pYWyzIukd
+71bYK83uGddNm4G/rNtcCS7YOny0ESUZHmWGIiJKyEuAe3iAlhCvdGEsWcVwsoBMNmxbL8LGXPN
M/xGV6JWPqVcEVHtxpmHh5l8ccrHYgmDNS6H/PJ7MxkXdeUGqWKV0lMFzaLIag+mGY9mBV1G0Fcd
uVN2iJqP7NpjFDDIpe2eHO6OcmZJnOVkvaoTNKFQGrPFHIaGpMaulqbIiWXFSmkzA6MOP7oyxhmj
/GM/PcPEUqk+nt6/tR70291uQG0mBMIsFI1nONr5fYw37OcLomQ8ekvZKD/0bm92tLU1tHEeGjbj
OsrWqj9/pSGmvmk801H/vT/aj3PQ1Nl4UkdUoK0zmjkXv6vEL8q4ZOFVRiQsaXwPVLNhusA9sW3W
rUClZbQm5Y+YaVg9/SJTnjdvBAVllvOhtn4ub9D1MSxVD5usmnje24vrI9ix/nggauKf/xR5nXJw
IKpoKCMTOJIxA6KuI2TN9Bp0OutN5nmD13F8MsxDWkaQjYv1KAqySqtXC0LoiDjWcwyyglapyP/8
GpdNvugGQP2c+0G9wtCluYo/Cqbq8EbuFD1vMIhg4wrE9eFXGM3J5Qtw7H4achgK8eeHPdqDYApu
WaIAl3l9j3Y9keqeAP5OplQ+eIB9FobSnPLFZQSbt1EfVtCg91H4N7h0zUWJK0xY5St5N2OnvNpg
OhMRVR6Uab6Vqg3pybYeP4sDk+/5h40yhuf9r4fl5vcmNfxqA90u3Hq9EbQfj1ToeQAZp+txIePC
9Om9HZIWAxMg5SRetTqqwLVyxQoU6FPoAZXCPoctdow+xC0zdkd2HZJFuhyWeUZVqNs91SKRUZ1Z
Nt1EYxLlrhnPcE7I05QI00YRdKN7iliOh2yodU8Hnpdfp9mnUPA8uxhPSn/NmrkSP4mQUDjvwYz2
0tJI6OqlcX2dDnRDCo71Ijl+7KYm2G+vIcS5eBYK7jk0lPFAP7ofznu3Ii+TcpiW62HoyPIenazK
PuSdHNcJysnfvZ1E3+zrgpXlBcv1zJK15SWrlcySO8tL1muOkn/EErpSgT9MRQJ2EEFfb72sGFA6
xza8s0xmdITjaTi8GU780ehR4JEnvxbhObYbiNmCZnCfEPAmTdwGPsZrxqO5bwznPvEJE1rBwJL5
p64fhsMg/JM6oYsPp8JggM9XaJEdhlTAj0C+QL3cgN8f+aRwFrADsQhNSFDb8Se9RzYXQdJCinEG
cpkPNm82MfJcbzTMFwriTTcYTMPgTVwhkx8O56TAxojJaiZ4CHoYBHqTwie5oKhKfBczCuZ8Uqir
CGPC1NnZ3KIpmiNNiHt269OudohxKRZ48jmK+BgzNjm7hc2MkHyDRQ+tiIMHHyt2hOfk9hpvFvtT
Yb+Bv+vNFlpGPPxmPvHH77Cgfe8Wno0fdenf0orlh/0Yx8aPwR2M4Ym3mFH4+LEffQS85VjjkC3K
F0xHAOL+lhRA+yZNcuzFrXJV9cWbWnI1FW8vFhOCmGO8cVZZ8j7Nk6EPNRSgR7kU6Dt5HajWWRPu
JkCSCwV14way0Qs8CaTi2slmL2Wvfwcbj5F/Eym98b9JdlDpPRCZbH2yIXi+D2Mw0Zb/OQKDferu
Syk1qGDjXqFUIHqpV58tPlQKqxKryY8oqBvbJQKEAH9k8z7yB4F364/mOE7zfKbkFDPUuXCSenHn
/Avl7AvMZbSgecPw78QN5EKKLy5gKdgMn5TyZAF7OCeGtwu7dKOTR2BaQFxA7BCHYGg6to4mwr9H
Cks/r+aj/It6aDPNbenyQ9+M+2o9pNUQ9QgVGVxMJ6PHIt3wYLJG/Y119Kv7S9Aja9iHx8+sQYNf
W9uD/e6ePjQwWzruQvOUF0KDTyFl4K847d5IM3EcXr/Nsz3BPwQdf3/Mr8krAcwTPmzBo73v+t/8
dbKG+sJp8+zE8/ATnVV7MBH0px7sguc4J/xhPTtroZPaw/d5bzCeQwk6c442NzcL8aJinA7rlUOS
gaVEUXz7rSpZsG/e3XcvsXGfyL6bkQRqixmQzAcruQPCIlPlyQbWuLRCF85vv70+c+LN61OtwkOi
WUsrcTVeXlJ9FuMDvl1ZwfyAAb+AAUK5XPqshvhHvCmQVwYwQtVFE+wj6C3gLXyCfeQNnwBd+eGc
1e5/nbX+VyOGr0YMX40YvhoxfBkjBooC8M4yYpBJTrP2DNsE+xEuvrI+OfManU4L9hD04PiHH4w3
8bCU/5OV+Lx+5s4A6iV8wQI45sxjZ+kGZzacmfLJt6z9zIWcX5dLJPIVvDJ9fMPDVdogzEPjeThp
c3h/hoMWPZPYj6QlCzot5ibe2ef0m26NGGA3ZjhUV0V71cjGaVmIoPkBza6y23R5LEiP4z0v/pIE
QMxeXEsim0Id5v8rr/M3yrb5/E/tTuPoJyrfztXw+rFGTYy0Diw5yp5NXotuNHN5veu0pCjllMN7
NLeYhyWY+eH3nhj7s0jhGo6RiXk8ISykX1MQ085yZQtPWWLALqCTRdvTtz8ZztDzMh/5kUMoukWD
+RTUFGWK4nq70Wp5h432SX5CG0yl2E0K9OagnnpCgLFngae0z4zBcXv9PYyf8pksJTYEMTpZ9uSX
TkuWhb3ijz9yDQm4q3e/tr3OJcBvsYb5UFDmvorarRTyuNB2VqHtQmLnPPMRNNEuE+AuBrDxm3jC
6WLSX8CGCzqVq84nLwqQP69jgRV8maUl1KhzHi4mPQNVClGi3NPmW0nLkxnphXKhVaYGo0epTfIY
lkff0lCKoDz/zh+OyHgmphbp9OZTbzaY5PGztR3gFOzkePQaLYUyVBSbCp+tovAdBckq9wYdGRMt
w8g0jkC3wDic4G/Cabc9H2GmrpBupMwaSRgoNaNjdHFoqixttj6NXdukL7O+pmadTtFEaX4LCiDs
hEEFnkbk1Gxz1JdtMDbp96hUmxOTbDT0IJlHRM7JnQL0JQV5S76vKMm3LrgZwx9e54EobYjChhfS
FiMY8XaEfXZBveSfBO8uYCbnPdXgfrPNuptGmKaJCCHClEsZGa8LNCg5h225/K9bZjEmTu99E3BV
CDGOlDxNAhsWD3AcyncEHDE3gxgV6Jp9jcziENcfg0deG2ISYfnTBkhBgv/EcoxL1Dp5u50rPVSq
tMjIKOVofj7sAxeHc7Q8mc2AkRpRJp4twLOz6xt4tgCPFAe7OJlZKNF5gF0gRY8YDHviG9dK6/1y
ciHdwaDXRJQB+HYYL/rGiQ0PX5S+/JiHL55Orhdo1qQkewgr3IXMww+l332m/f9oxe3/6Ivs/ne2
P/Mr/ODrI/yvj/C/PsL/+gj/6yP8/9mP8HHja72/VwmxYyZlm0AW4GQBhDq4nObQ1gJHKd2y9Bew
mic3bojwqHH07sQ7Pbtuv7Od6em85sXppRWR0szCaI9VV1b7+vwcZM/yeAeZ5yfndEjSPLSCUGLW
VedIVVa3c96fy/TtVLqqxow4iVkgYd7bk453etLogPC2LWdqMr9t5pvRJhGA4h7KassJvpw2fzk5
9hrHyQColNc6+U/aJtohUHVWC6Mttu0wqNT6k9apd355wVWWk7w5a3Rg+J9zpeUEf3CEmq3Nlbcd
AG0TIMEujLsm25pgFIxFDoJZSTDo/Mg7OjtptLyzy7dWgEyZedxqNC/siJgq59eLxnnzCNXkzont
v48BYEq4bDE9la107i8ww3UwQHmlmsoEtbbZhjkFBc0KaKnzQWJO7HCYNK4aGGKyspNO9c7wzNSO
f0lifnn1q+RZteQaAXQbSCOkmuDO1XnTg9m09SsFrbQCW2L2CU6KXrPhYcjIi/dWOEsp9vGZVdUx
wEBSvA76IahuuwgDaegw5dWkGCjucW6ixe13153jy5+hU2ulpHydnJ50jt7BzknNcxRW3njWod9d
sLEtmxIqD6c5zGA3IZZP2Bj+t+qHDMv8FGK+/2UTCol2aER2w+nQsHD0w5tykTZydEpmpldssGoh
+QqaJ+TPs80Ih3fT2Wo7DQn6JVx+GZuN7MfOW+JdcD8K5vONK7/30Q/7AIKQuWPAfw5bvMltQLrj
D31/sjmOE/58O7OePuPdoi/PHYa/+1rj1t5O+6ZNH26WfwkmxISMFbPVfH95lVg04zTzjR/sYd/g
OQMfkPATP/scsNFq4DnAdeMMhtmxOlGYi7I4PywKtibEPccG2rtEMx90cFBwQSqHI717RoML2N1I
d8AcMCvw+2Toiy9kpncje5v/S7spFw8rmLURhFw04vMqudNHn9ugWVp4zhtXVyfHMJ7bjC+vMIvX
VAnOHfJV5iDt6UCiyeFWm6xEvNZpM5frhoH/UVCCZCskO6HbMEWhb4yOqwxkHndcxdrLirUzix1d
wiLloo4yXCWanSP0WZIuQRlZJZwcoIysxjhLUIarBK7gzfctRxGZk1Woc5VVCHKctGUWamcXOrl0
NgeSs6pods4zqoAcV6HOuwaqoekylOEqAUqj97bhKMEZ7q5sZXV+y935yMlWFotbmRx2FmkvLfJT
VpGfnEVOj1ztOD3KagSFxMhoB+VlFbw6zyoGOVmFTk7PGm8zilFeFheyCraXFcRp5fAkY745PMls
WTurYyHHXBVw1myeYmD65FwKqd7labtgw4JORPMPFUoWMTMdZWGHegl7d9THTlvp+sxcV+nThpPK
hgsWmu+AbTvxNs9dsM1zF2yn2XLAQqqLVVBdU+6nUpzSeVkFjzIKHbnIwu5Ok3WV0d4rZ3uvHLCH
jYufyl6rXE8X0FkZxS6uz92FIMNF1Ttn777TvWu4CHB5McpcqfxonF/joUCRkvBR4XBN5FNrl3Fn
6li9VkEjYdXlyDN/+CKraYSspqgEWpGUXu5BNyOX1ZNeIC+/nl8P1QRKJx5RR/Jqc0OqXeqW0NBW
dUw7jiHJERPm6EB9wmZoBk0bEYZbn2PAdRcGUOjwyqgo0ETctpZlI6+EU8U8Rl7jg/BuOMUT/cUM
X25B5RiQYjbSD7HRZjgO9C0u8fQ2kvWsodH5GqPxu8BgXzIYX8uDNj5x00qI1q6wLF4s3Cx8MtVj
k7FuIKJgjg9EMV4LHU6Fm8O7UNzTmyX5noofLOUn08lGNFtQiPJCHPAioSWD0MUKrtDRz7ljPI54
VEjqwK65Q5lCr9soN37UNZOFsydfKKry6DnixvCRALz36AkMIftGo08UiVJFvDt/xLbG+X/EVOFL
A+nCq8Ag4t9FCQZSeZ+f8i4joyeNl/Miu01xMCJpN94XT5HaS9D6HNxoyw8D5d9h77QnSk+0AYSI
Hikka5DPITwzCErhyYtxc7eudoKc9clb9mjFm8HoC90Mlnd2vl4Nfr0a/Ho1+PVq8OvV4P+Jq0Hj
YXiALoUEO1ES5LxJmm3xyPLVm+/722HvFmf0fhD1YJzFVvRp10Y8vTAyVXzIJvg8/qEwrC2+uPNh
NCNU7G1FJ42Cyc2cHISQr6MhGjIhudK/yOOcLOwCH6hiRzlUBRsvDR5pSuB09NiA0wihUslo82+8
CxB+1GO1ANYApLebxLApTnRVjAnRUp23/h3Gbv04md7ji48HNI4k4png+XQOOgun6OcjxCn5BgQV
kgi0bH7JgbPmYHiz4NNqZRfJDN4Ul3yMjaEjucvUOxResHC+huQZxjScLm5uTf4sgDHAIJzQfR2F
iW6PvKPLazT/78TM0QsXbBPmrLAb3EwzbFN6cRnRiTJO1vfDKOCgj31cFgJ6ByJQrWBE0BCTvelD
+Hby2lolOFzf4TND+rRvZ1YrKhM/JTIxUihn4qdE5o7K25FOa+XWICntghy03GLIHsoa3kx8fOL/
Ww3vmdTuFklvN99e8KXpWrvd8dbk/RQSRkVZQtS1FXrdpeQwuPut8oF8ah2i0O+IDXE+nEzDIn8v
4Xf/b1Mj2B+FQI1diZEnoX20n4NhpqUf+hDGGlnfJquk98bRYuygJQrCu6Bf/m37QyrT9+5gCwcy
y+S+4Y2gbEISuPsEcMzRKXB62P+tinAI2Ih6wyG0Gfa+i4FP7hRo4nj3s1WMdZa5LgolfVlSzhFS
sctqY+W3nfimMOHcOCUE6TnQMktukx1A+8i8rDUjwDnyvbOTi7edd7najgPs/OT8Em0VTDuLRKYq
b10KaxhlBmCZY6RyGUfOMhPQQJ0WnhvmLKuNROYTNFy33p4gJF0m50wDjwwYhc9JT+PK+7nx08n1
lWUPks42kSTGdexTz+NVbjbHQ5J/JEQkICdA7BsO3/DHAy+GcI0Uuomm3BkLaE96/LR8+onYqV+i
VGSVaj+jlAqZezOj8yRVtBhXvaQJFeX0OzkN8jHQSqxiTpVd1aDjSbVpT84pgScDMceuztMgfDrm
8ePHdHa0mM1oDYtxOKB0f6WzZDOxIThZpTtTmoErB5f7iYk9yJjZLQ5XnByejfw5bsSeweOKi8eD
gNakJe3+rVxzUjAP03XLVTFdtwquZgGowz2GzM5mFdAFoEbS1gedG3M/4V3UAUGvIsirZCZua643
+T/veT1Ulp7RAbVlY4mtTxLi0Z+O8TFMWrLiNqUo82fevf8xWMyeQdmWi7JxgLG+h1FqsTeIrjuk
/i7oQZWaNLmfwL3ElTITlFp9lPZfROrQScd7DztL2IPm0EqhJF9+2FB4wE/mXdJCSsOVl8GxRVMM
nFh+2NzMiTaxmJGh18XxyV9MEmspGGwL2nmctw2wxCqkTaLwZUfzCFLonkqDJ9Y0y5wyhtpxQbH1
ZAy0awNdHTXRccJp8y0Q0TiOAculTMCfW7A3NyAT7DaME2OYBJevr46Rwfh0MAbST2oSIiDIoxd7
DAB9jhx6m0f1pEFftoHZDVNzUsnMgXIq/fDysqN6sGLUbItLMUuEMuigfBcllOGkhXKOzo9MhcvI
uDox9ag4Ax8zgkzRE514j8xU3Qe05cQTuYVyAmyaskVZNnKR20Yuho9t5FxBPWK45Hep9apCqdxY
yUIXtLm8rju2j3N+AlixIiyAFkzbvjQNOgUN+/LPoQB+VgO3KIi9cWOl7Ds9tVsQ65AGn1OWge3P
ZxmIAdtXC4AiIb/AVcNW7XPeNHx1GPLVYchXhyFfHYb8j3UYYj+Ex7hp7YS/EJW20rP5diC9w5Pr
EDM2A87Y3iD0x4H9HH7ONgxxtvnoR/QX4/EjjLKJnDP0GX9PP6WGESH0Dlo1THoHli+FaIGjGmhx
I5eArHG8eaPcnsXZBXkOjZoLIue4E+gCTfq5zUI+0AFBnMgp+0nkz3JzluGthUgi7xuwBRt9NOJq
uDDrTv90YwEMxrJ89UaIVVbt7lIEnUXACMqAY6+6vVfaNRHgSl7ZLe6I1/C7jku5cJjDP+zUvWoF
DeLFt8HIchmHWcBREOusgtKSPlmQOoKGT7b5vWBn+fAnDGGOXrueaPG1XPCuIQgZuH1Kl8ym0fDh
jXIWs7xzbNhP6qYEqlU6bKu4DR2Gv6nD1D7tXavjnTd+US7BSw/bg8Egzr9OAPBjglfiVcILoO5S
jIaQ7rDXGdBQkYppcHZ58daqaHtg/5wZwNc2tPXEgX6uz5QgfErvRj3QPZ7qVgn0Sf2pcKzQkeVK
sVwVr+HPLvSk2pjNb9Ek7pX4xytiCAUZWp/QcmAk0KS1n1poVC8p7z4fg2DGSqY/l9ehMHfxqyYr
SEI026cCbXJFRCfQmbBDCWtYW5olYk+QacIoHzFyK2lJ8yiAJW5gndO5UZJoOYdN+WXb6zSaZ//J
lyx5i3MFhRtNVyTP9P0huVSViZGMTiTk6Rt+2/8kIZOxy5YLmQT6JCFTOFYQsmoVZwv6DV/1tajV
ofRLLLy/L4BtyLNXInFa8I9Eidk88EBZL9KHW9DF98Uf9JlKp2b7J+eU7GVFEcI02j+aXnez+Mds
FjJkq4YMod8GQ7LbyS3D9U0+ihpWgTrPUSne2qhK4fNsHlrEGdn6Jwb7EjxzssNBmYu3BphpTMmN
R5LiGnFoImfr28hZ+m1wFoNTaPbo2/tsdmr4WDS1QcAy+V1oqC/BSpuqpwiKafkUzWQ07L4Z+/Pb
zZ57RonzXzSZGMVXmEe2SkX0OQt/knqigY+1tnRMR5hZKesVhTG+5LM8GSdB7VkiMYJZGw8DekDl
rbQRwpgSYYCGiyO/R7ZGeH63jqcuwbiL58u6vI6u6FoQN16h/P7yyy+idbEnfl3AIgfraB+tNPsC
u8ifoLnLHq8zek/3n9eNY+8d7Hd/vmwdi3Iy5+zyZ8pgFtUqOzgAapUa8Qhkezzt94fVPE9Awi/K
GUt0QbJyvNvwvL/3h3dhMM4vIH/RLYrvFxjQRqigIvlJcCP+XWwsQrEnOOuPFZZKGmGJOJO0wOuo
IKE/6WNswAlZF+Fl8nQR8qOGF55RwpYjQ1Qx50VCSgVXWebqZVrn4A/xnnZ2eMRHd4YcMVGsSy2F
w9eQOkSqAHJUmG9jmJGvCIyRqIthxoYG6uRjTqyPB5OI8U0KWmkzgknKK2e+gOMjO+PzPhO/XSHi
tyXxq1bLlRnoNqFDh2hbf3x53jz22idnp/sKiITJcO8uCZvO0KoePQT0gx7oTVFg0grSaHyzZE+K
WELCmM9RN/yIkW9QiPCcfgKY8WC0sJpYzafTUfSmH3QXNzdB+AaaPZzP3pyDmoZnqlLClgN9gQPv
aiU+8MaHCK3Ly87Bv+WPrlvHzVbhzeYm/4/HHjz//VtegRUkta3FCOa18Uc6YTjCV4ttIV4fiI2f
eYu7cSM2LulazciEKugLKLRdaGVvHo7oFAkYfti8gL49EPh1OAj+LvJcZ6fRwiuwRuvoXaGIwlyI
wQEj8+rVhn4Vtnn17vLi1z08FH21Ab/2BEav65tZMoH+7AFNjK5gguBLdsIgP+hCud/Exu9iTRda
Ex9wJf63fPOi3WmcnXnIQPh6fNLu4Md/y+O7DLy+OySj5cIKKK5al28LMV3LscU0Yzy2yasN+oPB
n/4t3zqHCXTTh3/RFH7hv3A2tlsMPG52rrzLw/9oHzAzAQ75vNEfRurjdNaDjxiNIv6KhbnAHouH
QlOguo+OCrq7C2JjKv7tzwkwpOMYKLGl4RNGFV4jn58sHVMM8iVGVD0eUVyXUOQkbnOI6QxBwSRg
77ExCu6CUVHQ67DHcXc6GvaEIh0t5+cUWQKjFH5EY1XqlE1EtC4OUS7xpkGNhFOyRO5PxZ/GPj6t
Qz78ScjXIPPpTFBl9HINiwpkfo/uHVTUJ6gR1BUUJdJhnJxkb8b49O9jICm5jkwyriN0hjiM9mQK
zuOvNuAXt5qtS+TtMSD4020wmv0JA33dR3ShIeNqjOleCn2q4pUkAP6MoWfoZQVjAGzhYoLXW0Vx
tNGD9Wo6i8RwLolq8xMWDir2aqPBmFFXoyutHrqtpAdA3eFkMR+O8JrGknPQAmAgbPgRHXNSMnye
+13MMb+qXBw2KusmmKjPOh+QbvgaAr91zW9WTt/6NrDgTHxDC25sfXvAb0ooN3vIMP3akUbdwxwg
PmHYJdm1ZPjZoF9gGNbLW+ZVruHcpby7u1PE37tFdPJSot9l+l2h31X6vUW/63Syg2/C4tu/U/Rf
LDWJ5qS3SSDoMphvH+ntwLF/BzrD+TTq4i1luNHxYUT80MfU8Z9vZ6NN7SHm1Qa5G0UppDht0nHs
4ekxmaWLQ37vdIr5x9qWCgdrCOmbGsEsnN5QYO+Ib4HVfe6+eJwuRM9HFS2+IkU7e/l0ie9TQU7m
sOHDwzSaHoJwrC8L315ci7fBJAj9kbiim1VxxrerGBtPXsDKfQzCZ7FrXwRDeiclbatFRdVwpi5r
8aI2D1PUI6rtU377SFfYI3xapQo6Wx03rq+uoG+ns4CPCaFx6okHbAYGi1ERl/25vtLkFy58rbmv
r6TR6IcQDcez0RBfc/khXrU/At2vNpIPooCXT91S4mPnIOD77SVcpWAl6Hanj8/sRhG191foRhn+
kF50hEEvGN7htQFdHj/dWagFTeWFu7xaZu7tc1DbeVHch8N5oO6urW6E5SQh9kWxVQYYf/JxBOxu
zwF6LjZAUAeA/nQ0pRcAU5iFAf68IUqVcrm0Ua7iULtuN6QfHxqbZ9Mb9qkt3+eZ0XS7gR4SIPIY
drgv/Q8N8b17hNM2dgYdvwbsRolWMFDwkVbee/F5brwrxzVGdAe0qmHfkiJPSMJAPxs3qUGHwOqy
3Y9HqZrGNnu0VJJdgBAUCA0KDsPeYuSH8gkNzLB4Md8N5vcBiFXcGqQXviE5tMZx7EUhpt07NMGQ
8Z4D+drfn4EoSgqRfGD+R5T3GN89LoykszJTHvFFDfq7vvfxtCqSlZFQAcTGBk9LAifhxiwU5aqo
VPbKtb1ShSZL54UjrzxWeIiLk7OT83beLwiRxxi4BQ6dCmzCtDdCfYFvv5U+2AFdOTovXgOsk6rt
hdFdHz3+T+jFUGzdpTp4PQpGA8EeFq9BDb6+wLdyZAjFgIAEX5CMYJudgjIg1ollSYiCjBcud5hr
tMOewIiiLQ0sbGwyQyI6+RPaBc6gi9cSoYKtRoEcfqZGOSm22kTNnv0rWoVdxQkvbNbn76zSU73w
uej9XP2wlGAaC8HNk+QWk4xM8U3VirHXmNU/HojyAp2OI4KNHwfDYNSHkbmJkTBkaHslKtr9hrLy
XND8B/XfBGv7PJNw7/zzQHZkGm90C2vD/nO66rktRwocPaCarjrkACYhIvbHH500FrirBcfoyGQR
B+1YuUHYlcPxePE5+1InT4J7ivZKqTjNy07BJSM/pCwxFD/ISRpm5rg9BfH991b7hty+ffH69VDK
wT9eyZjdWM8/kX/cycggmOwVGQVgSJJbQ4tbirMOKGb9vqpJyigIqYs2hvrDEuiEzOL0doOyKnm7
VGahXc+SzGd35BOiCfq+9+6y3fGu8ZbmsNmR7bf6tMhBaiCtKJ/tcvaX6GhZUzbvVQ/9M2s0DY3R
lGNBSbVSCYwhIfiVGqfr4aa+PhDJno/HM3149kjc6r5gLEoJfnJ2/UFUK3icJ+VY1KsJ+eQMFTRc
6YVQCCuvV9fM5sRzBxPFZTcAukiSVVhFXp/ZXJLYdGttuY0rEutswy7lUZrgH4h4tHAFPBAkln3F
Mwa3OWThi/tafXoNrX92l0c7X2Qp/R4tgpz9i3Z+/kSoyUg7qYKZaGeFLoYxVX1GFz+zeU9MSv+N
nQuTQPW5nRt5GOgoeFrFdg7qXLKX+QaMUKZmaTlHR2qSlnKC9+UezFLxtP3kAh0Z6xxW9aXX7eiL
L9wGE/K6dRblCrWc8L8X5bjws5b9/De6MuQFl/2G4pbDzJt3Z3JIu3+lpvAiwVTTby49Ph2SuVQ/
SAvuHeexxP63ahCr6Q9Cq+OfXYl4s05MwKksmPT3pDUfJQFlCcZBVYg6z9iwKkLF7MS1QPw/Kopk
GKw1Nh4Ig0OIOu/ZM9xnXLzsZScWUWP1UfN5aenaozAsap+ROjWx5o0FVlnPFoDJpYcdFYgNWB1/
0wvUZ2qcGsGfc1mVxKUmh/QSuirrx+XPyPqNjZQ2/fmEZFx+kZjoKeDLiMsXabLq32d2zvN0slgH
W0GOsPzr1xKh2Vj2vfBk531OKXsGm8srsfmzcvk5Q3Q5eaqBn3NyfAbvaivx7nnEfUbeLSdPy139
v0nw6qtJ3vPI+5yit5xAOp3/YkeO6DCYptzl2wjztPTp/e7/I7Qr7nif37aXbHiTbZYT6cub/6y9
8zfW5lkr1y+tHX+UNvr/DlR7tDKc3JwvF63J09coL1M7rDuKJRr/0xcX5FzuX3Vd8VyGfInrimdy
S26XXttj88m9CLS08pLD06c7P9H9ouLsUHVqOpxwp4ry5mb1y/bsM9v7ufqWVNnqy3qo9xl7KLof
znu39k2LnI16fhSI0l4uvrEQFBdh38jejrPLjuzyVpxfceXX4/yqnd8PBj5MVns5t4SUimIbFsot
tC0CNGvW/cGXEZTnsf0JQUn0jxRxvd9ZQXb2V+s+jdPZf2Ujf9uRX4nzy1uO/KqRX7fzP/0qZ9Kr
fkZJd5+VxWSlr+rkYVHJnr7ED6KUXLYV5EMtcYt2IIzlT/LkqT6DTskaFJxfWz6oxM4Tg7KeOaaf
GHSv38CyAtp9UewsHXd0QivkHZlrjXr+AHy2MKx6MRtLgz7DnwQ3/twYkqsNyG0qz2VZsCi5lhyn
cubPGquOkWSMVBynO5njFHNrmaMUc8uOMYpyzWRLohh2g1mSGsXOblPGYkftTo7iD15eXRx7R2eN
dtuDtBgAnbcmASDNiF54cZwCaF7EQbpE47CdAoA0s4ozRxVnlifA45MjAwYfMXiQ1DyXDpNPjPqu
l8BeXyjoVxvZsgkig1JoJEW/GQSiF+wP4gDZKsXhzToPAH8yj/b0O/R/IHeLQttmFYU2eyqKtYvm
2Voxl/vHP3BpLP3xRxH/rv0wmU6CH9fEH8VVcPjhZi/qA5oEFpn+DCy9OzcWSF8dy2wQObFg+opY
yg6elFctvOMovLNyzXVX1fVVi4clR3FIXLH4cOYoDokrFp+FjuKQuHLxzXA6T/edTF8VS+SkIlqd
jCjcHDmooORn4FiM3UggnbDoQavN6dQwNwcvzHJcC0AVIUUawhVzINJrRQH4t/FtAldAfpMbraou
L0DyJ6aVsK7MbElmHWKty3VUIblu1HFYtqqA1cGfwEL1YuTlqom8shz5CrjXehnMOWrZuHv4UmM6
ehZysTbQyC2unCa4MhhNKfzBBvu7fiZ34kos7pxWvkwlFptOq1+okm2zktrnrGTGldQTfXKV6JMZ
PnzpobL1YvxWI64qnwl/6JapVoL+G/ma48XYLWFqVT4zdkuKEhPRJ2KvpLB7T1AvwtJGWE3MtjIe
oGuuJc+FzulkrciV/OMfyTaeJxsp8Ut32InKh5P+MESPkM+rvjdbDPvEhdR8hvFrvSQNBO9kc3Yd
/W5IrUzXcXzYStUA0M/FP8/E33Hgnz8X/zATfzONfyKGz68gk0HNNIOggmdzaBxlVXDedlQA4M+s
YPYxq4Krn9JdANDPxT/uZeFH3+RJ/OPes/H3M/GnBwFAPxN/yOxx4G85+B8m2ROP8vEYFgFcA1zD
HHadUm/E+x6pN/LHEk109NhUYO24iZTj/Oiis2W3b2sDjdn4qCVf2qiWC2Yr41omc9VK+bGkp9Pt
ZC0XnYpv11Ixaylv1DIrqXSLqhL8uLyS7tJKqtmV9OJKekYl1RS/oJJeUtVjTtlHwO6quDv0pVxR
xF1TrqVqelnHZNWhNQyrjrpdR92uo57FsgwRqyv5Nuq4umzXfVct+G82jV5YT4pfWE/389dTLTvq
6b2wHrxrj/sm0n1ThnpIO2vreprn5wkVrUy1KDPS/EYZDW6eJQIVpaZdm9VcV1yjRvvlQlHLrmar
a1REX5wSLWva6rpEOq4KPcVI2X5ey5IKKFa2nZC67VS7ypXtZ1djr9BYTfdLVJPsp/blaWJXg56M
6bkrmr5LxZQG7gubZNZ1ZteFr5UN9Zdqyawk2inGDwWKXEktPfe0LxNb5nA656B+dj0i73zVsPr4
wpAF3FU7RoWay0BfYviZi/FOcsxVdpZ2Z7SoLan/uvZSCmJPgEQIWlFXE+O0Nx3P0BXCCkSOywaR
9MUi05p4XsyobaRjGQ0Wq2IqNBEv59aqbNregN+FYhkpLZYeZPCdUvas+jTnrj9ZyJDoeu35RD9J
fNaSUGX6zLlNTm279gjdTc1sW+VsJWTJQNz1U0wSdcUkmCiWsUtSEUtaZasO/7ZWpMMio7ukr/51
ZJQz5bz+NBnlWoKOnfJuBX8t6ZhyUVNSTpCyndUxO0BKzSalZNGxnaCjvrVVrdPvbJ64JLJSMoVB
1aRVlYROVClbMvkCWaxUsri/q7mPO6fK8n6oVBzz9Mrtjsm5rtjSUClrdlRIGc3ugkptNV6U60Xd
/XVeoCvbS5heS5yn1hKTU34U+NEc9jz8GAcSp2HQf/N7EE6DyN336KNC8oA+5ogK7PmkdlVPKKf1
ytONfAb2RNPqq7Bw0quq/uOPJfu6wdDhL45SxzfKo6PIp+0XnrfTdihVZycXyc6iBsnAy7AHfm4l
jl0jVOLcNcaV1DO281mLUE0uPTl1LnWIMb8SLRkPHzjwcv7PYXBXFH+GBPgd3S4G8McfzYmJf+6G
veiZKvCOs/qdRM/xKq2oeO7WO7ldxV3k8zaRrZOzeAzX4im8Vow1eWOmqMZjuNN4W04cYsm7r7l/
86wqdmkViMcQYe5+DtTZ037nbaeylVFFeBPMV65FTrKEL73yc+Vl8su2ZJJ9WdWygUlN0Ghg77kt
5ElOz3FCzXHqTjj1wzXBjPdkTenJIXUTnaiN54XjX84v35vYR/2H8fQu0Yo/VgwV4PbpZ3hHXOL5
T0N9kfBtO5bTvyY6OBr4vdi7AvsIIxst6UGPHV7C4ogeyDgaKDHJchi43FVgjR0GUrGnXAUS0Odx
2AeIPo/PPiHS/t6Wuu2j6Tzppo/wuF31OZr8bG99gONTHfYBik/02QcYnuu2D4p8Bs99yNpPcd6H
kvl8/31UbokPP9m+n6HiOTC++yiOHm8mi0i0OaYRudmsxiKQGnt57bUu2vQL2KS7IXwmr8sqCks/
wPwwQvYyI0DCYNYSd344DKhrLfgomMNGAkczOoplhqF21wfNDt0M8sBRM0ORe83/OKQQCBrNBkYy
DyLyZCs5HXHnDifKnx97DJS9lyABZFcWRSxBX/s7VA7Zj5ttr9E+997FBoRGEsGx3/bebLSI8J8O
2bl2tIYGgN9qV9dxdIJo3h9OOTiVmSbDGDwJGALNiUTglIzM8qNpGMnhhPMPBfEQR1RlR+lXndZ+
nKbCRqC7Re9u7BtZZg5r9QkAGe+ZALqPZGlrBh6hZFhkAh/f2SvK0ubZVhwLB6AEs3MjCt82QIry
URHaKRMEfBNr35XWxFWr+VCHuf+hYIRTtWNmIIWwvo7q+oGlaopYR3MBGZctJqhuBG+O3cadAks9
qO6ic+pVXADsVw6ERceQ97x8fgFDMeizn8VgshhT5YORf4ezNlmQYgKrAN5igtF6Jyq/mMj2YXrN
yutNB4OsvGBp5igzaxgEQVbeZDTOypr60WOUlTkPPt4GD1m5EUzLmdQsKzfNpiba/ZiVh+uj359m
EjuOlmQGd76mR4U41z3MkT9ASUQBP7k4bjYuQL7fFs3vsPh1zk6spOuLny4uf74QCWxmUDohbeJV
uhKaolRiyUkxZpDXI8qSOqcuMe1GvQWGW+USDQSWOLAMBtvlCRXW00TRcX3no1KecSs4nU/D6Qh2
ZzsPDw9mEGwqMva5SAkVxaysHVHJyAKltJqRVSmJWkZWtSS2MrJqJVHPyKqXxLYjqzdbVCtC7LhK
9QZboHIKsZuZWQ+EGT/dyq2WtoUoO7kCuTXKdTIGMe88QK6TN73BXS2Azik72YNlyw+Y7WQRZtd2
MdvJJqRrm0q7WEXZO5S9Y8kMjBO930K7o5Mj8d5HYYHvFuBwt14yhAt3DiMBafGe6Q2H6+WAc3LR
j8P7ooPgMeo8oG1uql0WuvSPfWaiJViPHPr6AqnGFtCpCem8ugw5+Pd7vWA2R0iM4hvMHVpGpEto
r/io/EnMESs+GMZMUxDFhGFLggesQ0aSpojOPX8tjrKqYUEVwDuO+TBWp0A3n9KWQNfGyOJWrPVA
V1rbVEpPssOQ3R6CMLRLFAnko+9FPoG45JFBul7UJRCXUBLIuKdkwCWZBPLgKxCXdDK5GsQloQTy
twcF4pJSArnVIDusF2sR9Cu75vzWOD8WlV2cvhLzYDSDP0UN1wZV7Mg9/RGkSP6UaW+MEoCb/SAM
JsYG+W4HVU3aFN/tsmCAcPJHX4DsBQKUGTwKCyZ3Uql118u/R4EOEOfqQRMSdy8isyMZUpKnf1z9
aULqLhNbyCuS3sUIozERa0AH+xMG2Xq6GUMMDhhkdb6sctdmtEsGFKRvQe68lDhuZVcj2tWIerew
n/NvV8Oy27XIgcVvKRrIvJhO8BYBN5/njaN3sLHlOQQlxd4JPVW1N8vj94L4K0p5Xn758SCj67//
XkiQH9Ig0A7CYkB9k4IyO7RgaxjDWWRqGM2rtmg9ZGsXAF7FAWr9YEoW8G4KeDcTuJbCXMvGXEOF
JQHsXv4RuJzCXM7GXE0BV7OBayngWjZwPQVcXwK8lQLeygLeSrFuK5t19RRwPRt4JwW8kw1M9/8W
MKVkQddF4qdct1WU6k49paJAmls4KQQl/hKuCjl3pwTZzrVXFfbwoGTkRY+TOahNrhmc40o6p2wZ
ctJCUbOadB9UKx/jpazR+b4jfj6pVtSQM0BhEpoGMejRUfPNOz8MYVnqYE4SfLjj0Od26qnFNATV
xoQ7PBety/MrcXX0ptVJAoPeAzurud688NckFGz07wKpdlLkGfya2szsuDczOzuOts8eQ3887Kt6
r/ir6AS928l0NL15TBa43amWSjGz3g3nqKeJdztvqlKfSHUWFRFuVYzybt0rOOVFtGabFKPiO+tp
ivHrVYaWMpuZOopLWgECL0fUsHBDeLVSVU0NJZc4SpibnoLJqMrbKm3pacOlDSJMvVTWs0UWQfVS
RcO4WMcwVQ2TRXTQg7xAwmRXVtOIXFoRwVTUdASfsmCqGiaTQdt6Lt52zsEIg2ONf+BTBoxfVYyu
ZvE5jOq14ZDIqWXxkGGGBJPFw229Mm3TimROAbQE6PFKU0D7Td2hed/OZr4xaN/BNNEQrWb7KAnY
L5fuzNE9nMM2bhjBEDwul94noX+PpwKE/ssQhrT4y04pa6j+DllK+tzDASEqGqKSmBu2MuaGLcde
4za+rjSA2+8ydLpbYyQ7KYtuNV2lB6cQRsC+aKYg+m4cfozDz4DwJtPBbIEQXTdEEOMInBDVmFLn
UAAIqAQ9eCGEu7VV1RiAcLelGtNRddNRi+mouemoycYihJuOGlNqwDm3Y7e1mLM1N2drMWdrbs7W
/BG3GiDcbd6KW7RVSiyxs1s/ls7joAfLLCS55Y2gUc5MDOHYHE2N/p0/wSjLrWHUE+fqvKLROs9A
GY69eOi4mEkQ9v5NuNdGhNRC5FSRCOJcQbjmbYSoJStzHlIQZEdB2LrjJLIUrQu6B/RHoh2Mh6Cv
9GG7Ng0jgWCOee++vmWy9OfjI1Hf2inXUzrasFc1ppZO8AC7wiZtB9GuClS18zZUcFRN1XAHk5Ix
YV7gOR0kubsIgWNWJORHH43I8+UbaOdizrP0ER44ZfR6z+uSbxVbS6tWQvc8fl6ttN4cZ+wLoZRB
HxXt+r2P937Yj4Q6TBvCFjSluI0n5VJFTs9YoQ8VQnVzX5xfUI6rQDWzQDVdYORHc2nrsRFfp0lv
JBxz1OtBKwIPeix8lCf+tmvEiT9WjooWExAkaZWiD//EVaclZvvxd6z9buyT03v8/odY9P05XvX9
IXyu1CIHb/fy6wN5BTfA5IKQ8a6Lps+fotjc3CxkXZXFNxn9YUTefTw6cCVKMWkynWCqtG2/wFAN
6Llm2LcOMZiDEp6NcopGAWmm4y6hwRH+eoJjbSjHniwXw2Kmif5oGfDfolBi/Y/FeIYnvyCa4XQx
R1G0ccagJsa/LSvWD4OBLHMMHSXgqzwodDcT4SvSiOt+KvpWGbzPT5Vj+aODSAw6Jr3hYGg9vC5H
CZim7tXJFIDeoTDBRWlz0jcK4kAjf4+EIQBJJlsATOZwtmQ3MF1gyM1gBOMRjV3wnpRwoTEA7d8e
2R4Avo/ZiwbFhiV7F4o2q1hGtVCyqiUqakxIUhJPdsPQxiEfLYBgPkvjxvGj8kAb9qhq4miGBTLH
yaiPDWcIHhuQWTETNQyTZlBN09ciiA4Mjt+Ry8GAbCGoywYUaJj5vy+DJvoTLNKfTrgZ3UdxC/1E
lC6IxvimL0bMHII5NJxioMTR9F6bTSQmKpA5rG7cHQUetpaHtDVhxN+AUTTvyDju8zDwx0aC4SvF
k7MSZqJo0m0rMInDrqI5kxA/YzhitOUJg9kIbcuowXwvIsiPBdpjcR/DvKcsFNF4ic7S72Xhvy+G
wEFgA4slfO4tQhgv89EjMBXj76ExFcmDBNZBKoWIMBozB5pEiQqnsIIrrt6ThdE07Mtr1OAB2zcE
vJvKwFCe/+O0LG+RZfxK1XGY4zYM0DhSFgXy736iAroPJr9g6aLW5TJ+SRbG9TRR2LawQABV6IQu
vkG7g3GEw6E73JB34b3ZIioAhvPpZGqmUXPZKp66MU2hBOY/qqLGhIh9g5VvRLOgNxwMe3gpQl55
QaqjYASNCuxlhG/yoiJNIKNH2ZM0btlKCDUwkqNwMdmYD8fBBnuDo6u9pImTnMz67IhPSRmeyUMF
gT+RNzdzkizo2MmU180QKscz+aO3JxcbMv4zW2AJvL5U135j/xFnRdFsN7zBdEqOgmP28MChBRVp
iUdMG+OxsuBEHLPUnPv87nTB4celqENLuEUozD1I9OeB5gyMcRhgj9hyunloDniowf8X12dnHB55
LodoPB+EemaUeMiUkAzv5hymnMw9uwHMWTcLYHs8Kt74ip51+SFuGfV56JO5mRzlNGuy9hIpG0kZ
Xl0FkZVmYAZ5fUnVVMNGcxlNlm6UJe2OgrLHmQpcM6G7NDqcEGR/y/mYCePItRjZJKBot92AbWAn
vOhJnHSZS0uhRDeDRQf7hyLOwjQ0hs3Tppgtwtk0knHhuSfQaAPvp8NgNAQ5fSzSRDcc8NIgsSEQ
dxkvGDA5oUsUzXipAor1dclNNdAuZLTJgWbzUHaDLkt+GBdjLy4py57SUhPg0kNR4g0JUffg2PT5
dKbfx6AqgA0P72Sw3RmbYSKaPMXmRePOaY92MwCCY6tgIutO53NYZU18iIYXORlsFZHJzrZocs9v
MKneRIZ1W/OifeG9a5CjwsujXBzJIh6WsOzdwThKrGWnSrCw21EScNigJRpJsUEJTpMn543j45a0
C5Dtk5qIoj2aLwYDKVGmlBbF+a9GYV1sPlWiJacArns4KZICd3Zy8bbzThWa6H7XFMKi3Vesbl6c
XvKFtLXeaj1SwbXI+STeZmOIW5gB2Zsp9EiJ+gUW1545AfC2A2vy2KcP6Q7S2WVebWIgCxtVpPWB
bfnGj5yi+w4x8aMbNTNnKS7r+Lvg6Ce2w4jDYJNi1sehBQs8dh63isQL1QqEAK1BVocawB3OhaD1
oQVzp9G5biv2mswgtTDZZOwSiciWhbg7ZZ33uLzAPhEnK9VLRgepPnd3k7Wc5NclAdQoi/MU7Wru
zxdRUaR64dmMlYwEWkhBFNi8JCmU48nGOqXgkyvvB2iwT3uIQbxM+2relnP5zRBN2olEJfwxdNFe
MkIp7uUiT+j3w4hUdJVeiqcqnrxpKoD5kRZ+JXBsuo3ShQKEC/DYn/j4cvQeq5UoaBGR+cq+ieKq
a3N+nFhVnHT0SMi8ROGY6DULlAWKkj5GF6a4UUSJwis1jMsuLZBdNU3S81JR5CeoaGCg827Q83Ga
dXAVtKwe+unpk6alGwPclngKvIIhbaiCWSSxeifnL0UTzvSJGUSdo/ifJELiaRnq3QawswP58UX7
1/PDyzNh7L1YfWJAJBg4EmZJAHUFiwGPbNni22EfTaFBw4WVS63BGGDe1tFIVaGHPrQJWczhf80T
mibZTNvgzTDy6KRFMUXrAM/gSIf2N2qV7S7Qmskz5jKbBJqpGWhfJWI3yHJsei7sOVzm8VRuVgy8
w3MEUs1RVwaGk9X/Y9YWe5P20hG+hYq0lu1c7Kbdv/XxbEZO/UoNRv1Z4NZ5hO8naNvYHJh4HJXS
ToGmXFK9JEZ/dO8/RkTvcB4vzLyso+sSXhlglLGxo1QWgLHRdEItHk2nH2VPz4yeJo5hG7wZMg2I
tPoKNgQPUN/9VLMu0t44se57bKVsvGw1Lzqhf09HSub+FdW74MEfz0bovXuQqBdle4cUizi9dwtb
Wcyo8bypUXEreJ+ALQP2fuT94J5kTam0R7/5R3/QGwx6kwNzGdYQGSMP9jTAQrk2rsl0uaeUxpFJ
rhGOfdce1C4eczZWkqew54T+ntEUKR8z4/jnPZKciiTRF2qyhK1APOWJ4/ZVxJslGi/oxIZUPlBp
yWOHPd1ZY4Vrp0bIxxpm12si+fG5Oa1GQaCWuwCjb+J0pjZi8qDpXs32vFmKPg5nM2LrbTB2U4Mg
Htf1BCVIAQBnkaB2nqqk2r/p8ka5YaQNKds/Na+8v5y0Lk/aXqODRvYkjkZyUa8+waN+75bY8OnF
nia54J6e+vlq9k3XUbSxEZ/kLo8nfB/W6EU4jObDnlo/5/NgPJvH50kxCchh2UiYXALcbtJiEZjb
a5jEbyYoaU/2A66HwKW4O36+DWjTnNwLqRkKDxDkDBCoHXXkXFfM0h4V86iI0fctimkUscLrOgPd
FHygD6zTx6KPwVxpRLq3aEetDzU0b3GFGvKsSqfOqD1w5Oe4Kr0j5gr6RXV4TUbffPOgNox4UcPH
fwYGdSwLlZoa5L1mJD6tVHM/0x2lSC4ikRINneFgHq/GKAWlokSRoJ5ka6J0DtXdiIduhRKY9tmx
s7obAeagiWgXhwYZhXIfUkm+2/D6Ac5udNqzj2XfTe9R9UR5+/sCH++BCoK5f4pYvsOFmh4wSm4O
QyAZb6Y/olE6LN60zciXxIFg9bBg1oyLiodzHFPbRpddMLD7ySsPqhcfXMsl2jgktG+W9CdqQQeT
Es8TY9lF3YOnZq69Y03TpA9wY0Ag6D4Glzk6i93XDVY2uPKQ1hobMf6KbF6At0GJ5YDkja5vdHfS
RdF4jKJJayk/8I2EPumUCqXj7E0TwBeF9riUeGhI/pFS7yj5/0dXQm3YDfT9sG8Vx/F5HH+nIyyT
seaGiYTbbuemOg4wFgC1XiYeadq3kFYT1FWk5G/RoaSyfiqfAyIK3kuSZHSHN2Trmcs9hcFdfjSc
zwGMULwMAxp1vrR2MgiF5eKTypM16EsR+PXayyvfLr207Li+c9srlz+teOUTin98adnfd17caLIy
+5TCL24wmZR+UuHbTyr94uFJpnUvLUy2TC8tjBOLH44/cV5BDC9DQG8qXtzyu/DF7R4MJy8ti0aa
Ly5b/YSyowfx0rKDsPrykTGbvVi+0Jz+xWV3P6HsrPLiuQ/NsF5cduflc+7Yf/i7HFGfggGG9Isp
wJeVLy48Hj68uCybr31K8U+Y+sf6qaH6eSGeaFZ7+TAjU8uXFu6FD5+lCdNZMIFd/ounZFxPpmH1
xUu4XFAIxcswzPqzl2tcs799SsPl45VPa/qnIeE3CS9tBD40fHHZF+tOZP37CYVrL552oPDWJ5V+
uZaMtsgvLuu/mOb7+tZLiz5E82k4fiy/eBsIiZPoxZpEdPvyPRyWffAo0saL9acXq23Dv1c+YUg+
9Mr1ly+r1crTE4kunD6wQGs19EPkWYes0p4ay755k122B+uIozBQk6iX0DHVeEBhwauzH5E/bZ6d
WG01iuFDreeXwncPzyrlh1GQVUrk+eQq0RnkAglKhMENGr97aHGkq0GsCfgoAa+QQ95yzBHBFC1z
+/WlX/nzukmxeTKOuBNXrqtdthaUgfZpgBFpU2f0ZBom7RMOT4+LbMbg6/Nyum1QnkmU44AlcpYp
Xmh8N8bblQQJTCfTT/ajeGGAB3noWU6doqtDQMPQlO/A23wXSgfvsXWNP5jT5RkbJEfyionOrzd+
JEtWshqXzTGlyiZsOPeAAmlCK/Kr3Gijqb00LSOTO1lWH7oqcYu9vWiLbscJbAZpobeI/JvAHBrq
0JVuMbqjaY8sWMncbMg1DiNpXR7CUrkY+dpIXNzfssmPeRDLVxxDNHNXd+vqFg+LxSx1XZHzETQe
/mvLjYFtEKWqxkv3+2F0i4fRC+l8MWnGtKlM2MkclY/uiWmKMJtZw/jC38CEOOK5N7YksK29VhlI
xGHdnJupctLjMFxQhNMMRw6DUK5vAmk8z/JoGrjzRRIls4G7Qw5mbFklw9XxPKMb9gT51ID/wJcA
bDRl2oINJ+I2eDAuGaXpTl8+p8A7etAZEDTQh/Mw/G5u0WDyVrw9PiTy1d2/dAMpHySgE7G8Ntbi
iUteXurHEQVHayk04LDnWaZcdmc+3WUNvohEvzdpWVE1pKx9nl9LNFV3numqzNk8UaWa0anCZ03q
5wH0QJ/trNSzDhCzjOlV9a22RiT2yzmz+0h3psYzigiUhoAjxvB7Ftvgz+wlmipTtWZPmPi7aL3k
KOrLsOznH/FaJgUyfoBHIzB4wBtxIBfnoYTDmuZFs+MdN9uNdvvk/PDsxEPjxjz+Kop2p3XSOC+K
U/ni7PT64kg6sslo2PdUslAUeS6Ln5Lv3CxshSco8S4uvUbr6N2/lKIsB6V/WF5J6RPeJn7DywkG
JNA+Tuke9hO8TeNdEDqSnvvdzd5Sj9MW5BfwOr2zvV2z3E7zPI++EHEBW8yneO3eI2Mbjlcq7SiI
MEjBi80pGcnDzmb+DYsf2rvCqm9qevILxYdnX63Rbx/EAb99woCla6U1DmUu1nz61fs7/en35Z+R
/DuryQ8R/R3Bqk8fJgBIyOBTb4xJXfo19AmQwmHC78D/yB9G/GdGf6J7/EOIsLESUw/G1pzSbqlQ
bzSdzvhDKP+EIdXSG8/kn5r8u/PQu73B+OiMaTyj7zITP1eMzzXj8w59nk76/Pcu4KrmWDPj+v2B
8fz+QDgIsB8QAf3ZZM5/50RxQL9m1LCAGBo89FTzVOuChxn/oZikFP94beB3I/7LHTDwx/6D/DCc
8AfN8YFmOT3ooQ89/n37kdH1RjB05adQJjHPBr27ucKD2jpUSOxQX3b4C3UQCCZ12wBG7G3I+Ma+
/POgsIwD0D45UZI6HjLt49kj/+Wik+BG/VXNnSA6RjNR0Gh8QR+mzJ+ZAp75vY/yg+LOTLNnRu1j
VDNqI36Q1M40fEzsTJdUFc8knTMiVKIyiJ1NFDpN6yzszWRaGP09nPNnnajSGBc/9aIM2PRxj0WL
Lv+997l7ogeGuOd0JvtBsuJhIXERI2+oEm4OqK0D/rugP3P+TV9u6deQRfWWkob0S1E2ZNEYTkBD
IJxDpo6j5q6RDIz6Zfmnzn8r/KfGf3YkqlF/wAmDHfm3L/8G8u9MZcxUziySH/hvoFBxU0YkmfRp
6vdZCtXEwPMCD4ERN3ZEv0mA0CJI4hoTVSCXZfm3Iv8S+ePpnfxDTR0vJNiCwSbEjImia8Ije8KM
nzCrJyP+zWlM0YSomDCpEyJ1QuRP5mWFa841sOBMfsff3NfTkIf4NCQ2oexX1Icaf+j3FRr8XFGJ
MveOpz/8UFEfQNrKxmdOh4Gj8cBnnch4YOSU1QfOgnFTVh9kyuxRf4CJoqKwTWc9FrpZyL+nXeLP
LPJZmmbR7aiiPtTUB90YExd8VgBhDKDaoxsDHxiMJXjGEsy//N8lsjCg3goDIi4c0GgII+J3uOA/
NAFSb0W0VEZUUUS1RFWJKKJuiwL+zSMQGiD/yLmcPzE7gXj5h4QCNoUK00zOtZFcUiK5pEThiKQi
YvIintajeVn+qfNfxadozvXMd/jPQP5RX///7P1tlx23jSiMfo7X/RF7fFYmkt1yiqx3a5xnHL9k
9Bzb8bKck5nr8dLavfduuydSt053y5Ynk/94f9ItggQJgCwWa3fLdhx5Jd0tEAWCAAiC4Nve/T64
35aadULXtumTB0J7mP7UDmTJ/mD7wo0d1W9O7Yhma7n5dnsN/fTmYmvBz9HBTCG6+9A8KDP9hk7q
YC8unI2/uDDGrcKfOvzZOEovbPtfvHC/gNB3z2xAYX/gOPv9je154EJ9OOBiASDmYwEfCLyElry0
fv6l8/LO+758AYWgjf9+aRXw3y+95P8bZIS3FbCYDK8sMNEYvgiw++GNB/7v8wMJz/66efP9T97/
8k14n8X+z7wSa09F2tdXDMoXX/3+8edfT1i6AxzzLGw/g/b4yz9+8ZHAHVK4H3zwfzharZNoH3/y
B46nk1V/8PhDgdam0D76gGN1XRLr40/el7U2KcSPP/hCoCXF9/GHAs1cSJNAeySpjUm0zx9/8fU7
12fVO+6cgjHQusKP0hrEj9QxH+ljPqqP+ah6B86WrmrQ2i/06i/qlV/cXG2fl2NffVeC+ljaRrJX
PfpSGHiTtNv//euvTza/NjmyavNg009fqHz1n8h+k+xdn3/8WKAlaz8KrZpD++Kz978UDifZbb54
LNqgkn3/ceRIkmh/MrX+9dd/I2Ls6jfhg4wcf+3Qhwfm4XfzxJfWD3RtHmo0T7A9qCdo3T+opwY0
6kEzFTTtg2ZyeF3/QCkzDtRZR430m+FBZ94XVNo8APsmPBo4y9bv/WdoDO0R2GmW1tH+4ONPJ4zu
Z4WRbtcHn//p0Yf/a0LqAaNNI03D0qdumLN4k0762IgnvA/dQOLR4gFiwvroj48IFpjFFBk8/sBs
oof0ffvO8E79zlTDf775kT0x9NFLd8L/kTnrfPXi+c3mC3wv+95Eb/P/23zwRdff/883zVm+5yab
r99VanyT1/yHz798nzMY97EJ7dHHFEtZE19Cq+fRHgu0ehlN3Rbt3yRvsaszaI8+FWhJvT569DlH
S/imCE1l0CRzcdBk8D5/LMwp4etiPDWL98UXbMAwjm5A0mnDfxRxEIdtBu3LRwIvEUHFeGoeT6hl
Bkt2yrQY/w+VdgPeIoX1heiUbapTauiUcW/8PwdzyyHplBM92ylb2SkH0Sk/efShqLlJ1axMzZ9c
7ky1H27uTV9Z+o2k30v6Qu1m/Bnzav/8UynZZCeLvEkczExYX34ubCMRrUdovUWLxVAbMXxpDst/
fnV+eWWWWYLQJxpWKN2SJ+S1qRmmcNSrH5j3oSsY7s08SHcwMPftg36S5IDDs8rNvz78/RdmpFG5
EI3jpNXz4Zcf+JneMsZMPQRjhtsSGk8+efTpoy/fWkT8YpHhL+6UxlyTlmr5mIU5pp8onSEY0LVB
tyZQF9GPPkjX8IcvTCpJNVkUpKkCzVwsl/kgzfUjZ5S5UOvRxePD1Xfnu4MxBtVn9JTCLKc5g/n5
guofEWtuFjFmKlnsM3dUS1mverRozRRjjp01NOYavVSL3ROyQObTx9bIhkwg/vn/tji5wYvjpOvi
OOmGF+F8+oHB0TkBcpze4tBRrX9H26H9D3b7xebzwxWcpjangz+4fAF3G+EIdz2Nambfy0T1q+rr
d86u6BjXVm+yimFio3PDzefgXnJq+Zw7i/ZNG6tmKN4V/iI/nZmrm4Svzrncu/xgjiWbMcjNzdfj
zNT1+It3tiYHrgeMW+LATCLVJUj6VkiwShN4SjNOkZIhvUTSt0O6YEiJDJrB2j1/ysUZTw4itHSW
26DttxwrjocB65QJIjHllFjpzPUKrD3nK56WAtbZt1xDBWjpPN0qtKe80hmZnXEF3BLtnGtgRpvn
XLa3wrrhrYyn0RIrvTxTjnXgOm/SPZczr9Lmc07MuprH4p5CzVTIPVMBVobWvoiv6yKsmxJJPH3O
lR0nlSRWOvVUTuuZ8L8zWKKzzWHx3pFu4/O/cA2laVEsfVssIYm0Q786Z3psZrC4HhPLjBKrLsKa
p3UtHEDaVq+Fy1nGytAS8qoWsdLJ2RW0rrnhpLFuxMAWp1QkVnphphzrheA+ifTdMzbEN2lSFEsn
sb6AKYFuM9MPhpKO8754/JFByU0swmq+mosE+Wq+mhsIEqv5am5g5Kv5ai7OEav5aq5r8NV8Nefj
2Gq+xSpYzVdz0Q5fzVdz/oSv5ru2xkbNV/MdtXWr+WpWyZnV/JKPotX8ko+i1fySj/hqfs4kZ79Y
X8fKHQMlXEVfrK9j5a6EEq6iL9bXsXLnQwlX0Rfr6yjdL7GMSjdiZLEfy766tLvCoq3YXZGr/hPp
x5Z2V1hFLG6bcNRug0Z3V7gBYGl3hUNb2l2h5obn/O6KjBzvZHdFxsbD7grgR+yvmGUsuQfiZ4Wd
brDfBTFLj+6CmCfDd0FYYou7ICxaPLDyXRDqp9sFYRlc2gWh5mJjviFBzQXtfEPCbCzENyTMxjh8
p8FsdxY7DRy5OKATOwhm+/38DoJ5y2I7CGajVLEzYDZq4zsDFDqSFJY01HSz/4+UThrrC2GodmeA
sCqyjK/oMr5ES6/G50RIVuNda5ZW4y3a0mr8bLR91ML3rOcgi9qzrfTLzfNUCMYyjVkMtriWQfzi
R8ZINzq9IF2AzteXZzkI68uzNOeWi2dpkuXieRy5tKvo2hjtMbi0O8vfo0XLebRoFyUYS8pch5Hm
lK6UziKRldJZqZHVy1k663HSzSIrnBkcvxg5j4OLkfPcpBcLfwT8OY6PxmdLiyUM3fqD1SzNfeBX
KTNcrMUpqWsGhy5RWqyFJcq5sIGtGaq5eSFfDHQVziz5bDnWwmLgbLjHFvAcraUlt9mgkC+SObSF
RbLZyJEtRs1Gd2wxygk2vxjlSC0sRuWxuE0sLSDlaV0XYd2UYPlFn9lJAFv0cepeWvSx3awAS98W
6ymrMd3GZ8K+boPlF5CcVBcWkNTc1IEtILkKZ7C4HpcWfRzWwkKNw1pYXHF8LSyuOFoLCyJqZkLD
ljpchbmljlnPG9YxShy4hhQEx0kcfPTXHl1/a6752h+eV+Gc49gbrkG/Rka6NropJKMCmcYtHhpy
qjVS6MBxwRSn9VUYfz39HH11ysyUpp+GC9UDxEzEDEnLSqNqSFh1JvYt5Esnm0dr6kZSn8ZaNfCr
azNETT97+Gk4rluFPLVgmC3gteUs1a9YVGmWY3aPEWeTEqfujIWbX739NcKvtrK/LEpb21+myumz
xv7q7a/B8a4Hk4M0v7T9ZbHrcgbbVypcJrJkM+6gCd3dmGxLrGD0JmstoUZLKGSp/3FMtg0mCzaE
JlvfxmSHuxFnR7pTJTxAs9IDjD+OOLtgAdAXUfsNav8Ycar0gHGkeXoWHeNU95Rlagee/VUyV696
hEq369g2bY5TTnK4q8fynq6WRyeTdw2yUoNJRA0DVla5nzWRF7p3tAxFLKNBy7DtLWVTDETKZE2B
gVq32GQ9DMDAWKmhnDIZQfx8t4GAvYN00GDzySaRoly+sHY5vtal5XqXPjKtBSvB4e0EAlkYNQx/
hjkjuNEuvcL6m6mwPhGyN5W1mmoB2MtqwgpiRh2xKqyCpDqOE2HHRNjZ1kBLavNjNBQrU7NpoWVW
6dtpredaM3R6mxPIWbGpCLpzSorAJ4glxWuxYKlQSb8+qpUDa6VpWYstA6ECj43vi0fVMbI6ZiRo
DLJTkeNUoykYVcQPiHHQtzIrXXHXBA7Oa6WUiBKOI+X+VxPVkV6stRtBmPYqE/7BeALDiWoggQFu
wxSYwcH1b4NsRgDVukHRMehlDQvq1njB70Gp+d6MRzAcgb3Z1vSmdDDfDo0jZ20c4GOsK7Dvyvgj
BQ5JOXOvFewPaMwPsz1Aua5RG19XGyXWxtvVxt3VGvwYuCDzlXF34Ixq4/BgJlcbt1eDz7ObDtwo
WtcGFzYgGInVxl3UNeAa6kawteGzNgKsjQDtsHuUOdWzht66jmW0YcRvpBrcF6gxYTZg/EDtFkIV
AgWh3EKoQqBWxmVCvU1PlaNz3XnfqcqptJLKovRB8usr6hIVBVdfSoUMQTi6G2qj4dWMIKoybFbD
TEv4YE6r3xSzIOY6IBNLqWnKGzJyKrdpwIpq62p1gL5+2C3lRUXhhHfqo536mx8j7eEuItCDnfAP
c/FMsTZrLcOoaDBeVoMIZ7RPtRg/ETG/MpyZqGGIBA2+hcuo68TMpfRb6W5mLQZbucIqlxNK+fnQ
jDBduH2bOVBN3JYxDhfvGqcOHEJ2WSdi7cpgVt5AS6vro+rWCiTBB4xIhhc7Wy42vXWSIn7RDJxg
YPqo+XE9clJrRRBqjZrqTOL2zW0qpikIFRaMQ/d3YCGNStZ7lJVwhqyVIFOv0lSaH9PprnS01Mna
CdURjrapC51lKT3ifE0UC31LQdYjtBPiPwhXJ9FAKDH9MlUOPcxspl/uX439hS2MlhagD/mlBXVC
lxZcMn4uJ48rDMfm5RuaGYII/wTSO4vBipWGDtJovUzAmFxuLJlbtFKzOlddC4uKU4Mr+0vZXzWT
ZI0zPS/NV7hY0XRc/TT/JUxBQWwBNg1NhVJYKqpOYkOxTSg1lgJDcfZUaCy3kkkvDIXmCNcbjZVb
6+3E/GvwsiOdTJhViUnZNGKpWRWY1B0t4zU009WhKXkD+iV5FZpv02sMBM3iF+hVWhLBGD9h1e+9
xi9I/S2dadZr1O/9wC9Q/TQI8wPJ7FDx96x+moRcNTwsOP+/a/W/ypCylIe/52CvtI0/j9itlNt/
jKiqVBqvMkAq5eHvOXQp3Yz1KiORUh7+nmOE0ja+yiG/lIe/58G4tI3JHZxHSrasxiO2ZBb6XJtT
O0Z+x8mu4yMQyK/Cpc1SImIYWxSJr2BOCmHMKWVhWMlCSe1lNYsRw0pw5XJPX62VYJRzv60Ee+GR
bTuGle3Qa9sRLSrduh3C49l2jCvb0axtx3jn7WhTMwaFsd6axnQrvBWv4e5as3679R30zT4ZUTY0
UiultGZ/M6/hzmQ4JOO2nsZDpZTWbBzmNdxda1LRkb25Ra1szZrTJ7yGu2uNmN8vxFll6+s+zDrS
/Ic2MRm+NWMu8rtNvxzkLL3/uTDWC8aGnwtjQ2o0YPmjUkqjyDkcmwWSPceZ6tqWjVXCSI/N2JTW
qYQMfpy8yx2MaKNOjWgsR1JKqeZx69GZjruygyY1urGsRCmllkeyR+cW7qplXWKkO85uex7bHj2b
v6uWLXslcYxqILavsAe4bSHklKedBedOepZyeFfebl3+Y915VTfHdynWeJ5ffIztLl1pHIWUKu9O
FKeqn8ZHl+fG11jrci6nWCzLA8BP3OVUdVcjy99Fn1setn5yfdzVePh3oY/lwfYn18ddjeJ/F/oo
CBGO3L3gNirc7UK9qn6KiGF5fHiVO9OUutPAgakTt6fcYkMKbxq2eU3zft6hRFmHe1U7U5QqiCh+
Vj1U/RTxxU/dQwvCjJ+Xkn6KoOOnVlJB7PHzUtJPEYn81EoquDzniImuDQ+PDQnVEdfnFI4uLm49
JvibCfyKF0WUTl6scyebVe/KHPQRd+iskPyRxn5XkQ+7xaG0cy+3Uq5K3c2GlRV2ddsbfWbuQcot
1Ky9tSi5KckeRobDuhrPv/UriL7aq+A0HvTuj230mp0G8vRyZjdZTzvTWp76hCJU08C1JNOv3v4a
4BdcAjP9UvYXzBE6sOrpV2d/wWUnXeOy5uZPi7biXgBFbzU4UpGutzH2HEOERc4e3vLXdGNjf7X2
l6Hd9JVa0QJxo4KCa6zh3mV7DhdFXVe1+dHQI7jFF3etvT8hVZmzGtZmsPaj2l2vHy9yZi1MutwF
0psUGB9w8bpVRptjK67eiWgVF8QRA4UTewMYzlDCuefaR8DVYEe2Fd2F3oawvBXL16nDpqw1/t7y
dpSzoVcroDxaK5NSf6hSJhPW546/NlbVq71zcS7RRb+ZkLKYybvdKPZKp0/1ei++INCWCzR3Y2gx
k+unFgtMdqh7p/XqJOi+Qd2vvPrw6Ity8pLsvCTJzGfdvZUrG0KGh/lYu3j7V3o6UcyMZszYq35Q
gsVE6tu0KNR3Z5sOVLNiNMjVf1TdxMFDqh/FCvblEyJH3VLY8DsmHXk9plvXG5i9DK9dZKB8RG/E
rZOOg8ytk8vc3PJ6D0VPzhdMYMt1vkIso9SNIQNXqPbH3p+qNQrlhN2X6q/kUvYv+Ay+Mx9WECbA
NBIiehsHnNgjAUAO9tTDhvSwmTtsSQ7becNWWLjFFa5xtamI1mnP+k5wjta3olwrSIu5SK63s9nm
WLunJ+ONHBZvppm7m1PIywpjUWal8rIxxKLMkvJaGX8GifIA/TjxqvQEGFz29Kuzv+wEGG7cbFq4
FW/6BWWttjPMxv2y82Dk3/zZW4iddloSXT+uYHFuMiN1Dlmjpjz8wxl6xPmdcM1OmtyFPB1XKNbj
OaOrRUFor0wQ7YyFtUwiI5FIM7hfNtMCPE6/rAgH+8HgRdEM9tvRfjRa7NGSH7uEiKve/gIttMpq
QXmLaJVFU658nNcL3GHbQD7a/LJytMmjrg3KasdlkSr7yxLsLYm+Wy/uuXncmstEl8Ox1ZLgUsj6
hgVJTIH6sMbDzc0ZfzECKZbE8OOFKYWSNrXZ65qZzC1FGUuU58rcWFgsGDoLNjIxY6uZppoZnqFt
4tvRXZM8cWV0ahQK1yVPOEadpmUmQWyyw6aBeGjZOH7j6gzXRq2Gb9Mmo024ZtmcQsSNFaZyDXPU
xmYlzQ8owBADpqcwO4XJKcxNYWoKc1LDjDbcaMOONvalDUMaXgvoIAEHYyOTsQKRwV3NpRLrUlPy
bkbdsNKjcl3Mt9u2MW77ke0Gcom2r1z+sLIhE5V1qTV6nYFhzQxNoG7IJhB+1j9C1SViI2/BHbFc
JSzXWa232PokWKpzR9JiwVLbY3UMcpMNhgjbmt+aRHihbOpoNu49UpiCNinxH/kKRMMrdLnd286S
bZ/wbM56u7XcytvG4eU1WJaF1dgaRiwYgWwYBlGQ+QFjFKjelBrTUjDKta4Dw1X+CgY3axcwfpgB
hNzbb76CEc1e3t95AYx+XHBDi4tRIWkEIxAm7ukV8036Onl3i3ztbow35PIXxkf3xGt3RXyxWO8i
/kq1DHjPtm5Vy4Ccb125L2SWtzIU63ppcoM3OY0mF2wkpehEE21L1qioNDMfTygLOTlSnMUNmMva
W1EqFCXEpcHubD/Wvh932I/tcxwKe692fdk9zuElY3u0d/L2TQ7o2wZFPsyBvVe+0NGhl7M9Xbme
HgTtevngLCAVFd79YNHPrTGkREoy26G9Ib3Nb3uYSePcgtXEIjOM0RMN40JN1UaYdsFXcddTe7UG
WwdXXKO6gkvSRwRKoVVHBEp9IpopbZnd1lB5C69pa61dxy0+trVy8re2nSQyMe3qcaHAPjphmIDL
sUGwNmMPgdOKpYg+sQxiBm7TflOdGWEHF7CPo6u1IKqzA7LIruYYzotT7hU7TpyJjU+yrbydJtGr
IBmUbbHsELdr8R3uH+tTT2YqbfNm2ubNpnnPijFx9gqWdVkS2XLX5szQ5/hcK4DUPt0Odh53kIbv
mhXv4ajZC1xedestmysbP6Q2znba8No1esXOmdmbXl59s3Wzvtmptx47SAB0kAHoIAXQQQ6ga2w9
piVDs2Y70eyFMa9cKMh45xmHzWpDM6zvIENqh2kHmZFOw6y/qVdE7sPc3tJXbynwzcrGp9xjBxmh
id6KjOnwU3lFy+baZqecoqpgM4uqYMd1MamfyiE6Ple2nF4TgwEVBIt1JrCCN0cgaj0uxBoT3jMK
serVYVZp0GHZbyL2j5H6WnHrpfjVRVhtLkyCHe5rNriPCc/8U8Z5vgE/hsjntjW9ug5JJ3MuqFzL
9I8/alCmbTy4lue7WT89nmc4TrOS5x9/mOI8tzZYWR+mjHOpuB+N8yMsZP3YmNqZcjzPEL7Zdb1V
nOtq/UbadU/CE4dhw461DK44P7FoBAtn0oJAYW1hLadyCBzJ+DPgGGTqg/Oinc8JQiy/Yj6iq8So
Z0Y7qNGEF7gkV1V82FvsRjDsycFu4INdPRtV3HVWTNPLcqhIB5UQqwJnE2Tbq+MFnBilvIDVvJDr
JUkvhBVe0pL3HyWHpOldOEzcjW2uD1tnrBlCz75NiL38+d4qMXAt2HbhwGBtW8i5TnD8I9n2UOgu
bLQKFgU7T+e8h8b9b3rFApyuEkMXyvs4HyLfAM/6EBswD2ud9VESV4mxzqx49VXJkJJbDigdqNcy
fNTYt7xucdfrT1rNrdLIFZqFZadcpz1+2WltY25/WNx6EGCs9pNBK/XS9d/sFQCrj39qlZgsJjW0
oBeuiXVNWquHzCAcPFPprMB7oLBkvMrb36Yhifnj7Bqm2U1gFzJB/XYHDqxrwlAH23Ba127oHMtL
nUvLnD9lXyOjfYtngP0wsX73m1aJ2ePPW9akubcS+ApfkBjyzV6u28rJisj3xwU5dUvCSs1Ffsy9
B5reRoMhAjkqtt44dfqw548r90X75KEbbfGPJXedFNMtTdRKCbvzrU10btfD8fKC7niME6W329CN
9j9ru/pxXR69XSfuynaDb9er8qUeTa/WqahcA9mhfFlR05twSlzDTzxqiVYeHUCt0GDPBNS+llFC
Rvzcsz8bHOwynDBdZZzj36Fx8qb+CNKvE+FCwiMcEzjUPHCo/058/NE94JYBRK2luErcxSsJIVYG
uLeU2NEhRJ2+tOO1daVkteZyqbmEUOGSWUkSqJDr9u/Qh/8Eyu3WDaFHefP+71AVxw6nt9XH310+
Z/W8pk33dqBYfBvqWrH+A6WAWmp+x942u1K+TT519AqfmtYzN4r9vQzlP3vN/gMmp1oaWf5Ycq7z
Pah/hT0o8z48Dvctjmxrqi+fSzapta9f3LCXCHVx1HulppVYj/sFD35yavhjdeB+eQg8pjdZ37au
Q6fvA/yFDok/lb7TScJ/hIGxdMpeJO3yQaJdCDL7H6+HtSuDzp/FlJbOZqMEzfr9f3eYrEndbzgr
yzUdAyRQfOr9Di7A1W1qr/KP35Q16rzFfpb2iNxgobtxjmYmW/BqHc3fe+7wVr37FSVk2+j2ZtO3
YKmiu8Xte8C3aTrcbnaysXdXnay5MNhw42/AtTk7OJptu8PJultwxQ24lj0jrXALbnjvYfY+XHbn
HygMNptbarD5+fhLunTbv3pNtCf84q9q7Z2IdlBWkdWX6lHo0Kr1eD0KHdq2Glx4Q6NMj6tO59Bb
o0vvO/tf+8PZ+cVh89lHnzy+9+/3N/euz//7cHk2/flb/Our6uv794WJXN9cvdjdbM63XfPk8vnu
cn94MpnJ4WJ/uNj98MaDy+fhn+eH62A7f7UVmQNh90/gXNiJh1QWMrXnbycct7YldcDVFqJj3NaW
tAG3sZAmxu1tSR9wOwvpYtzRlowBd7CQIcZV2DjSOuWapxLtU66BirRQuSaqRBuVa6QirVSumSrR
TuUaqkhLlWuqSrRVucYq0lrlmqsS7dWuvZq0V7v26kR7tWuvphpFlSbaq117NWmvdu3VifZq115N
2qtde3Wivdq1V5P2atdenWhv7dpmXFSJvmpXZrq7hzmZGT8Q4bu2GafgYdgJ6gS+k0/dFvLj5FMT
+dROPnVCPrWTT03kUzv51An5NK5tDbGHxsmsSdhD43htCuXTOFk0dZl8GiefhnoFdAsJ+2mcfBoi
n8bJp0nIp3HyaYh8GiefJiGf1rWtJfJpnXzahHxa17aWtLd1MmtTPhCdIGlv69rbJtrbuva2pL2t
a2+baG/r2tuS9rauvW2ivZ1rb0fa27n2don2dq69HWlv59rbJdrbufZ2pL2da2+XaG/n2ttRz4+u
P9HezrXNHJAosbfeta0n/qFzMjOn0iJ817ae2H/vZNYn7L93beuJf+gdP32KH9c2MxPxMCczEz1F
+Dgw9oXtdW3riT30TmZ9wh4G17aB2MPgZDYk7GFwdQ/EHgYnsyFhD4OTz1DoPwcni6EtxHfyHLpC
fCfPoVCeg5PnQKMNDDcS8hydPEciz9HJc0zIc3R1j0Seo5PnmJDn6OQzEvmMTsZjon+Nrr0jae/o
ZDamYisMrkh7R9feMRVfVRhgVSzC8iFWKsaqMMiqaJRV4TBZpeKsCgOtio6sFYZaVSrWqjDYqmi0
VWG4VaXirQoDropGXBWGXFUyxvRBJpWBDzOTcaYPNFmk6UOFZKzpg00WbfpwMxlv+oCTRZw+5EzG
nD7oZFGnDztTcafCwFPRyFNh6KlSsafSPjDSZaOFwnBV6cJ4Q2HAqjSLyFBmqZhVYYCqNPEq83Mi
hQEqZJECFCVvYt94noGS4ZErSl4nxiaFgRjkqAr4wmBX0Wg3h49SodGuqv2UKCVfDHgVjXhzdaBs
ayLb+TmkwgBZ0Qh5fh6pMBiG+bq3KWdSKXyUeF02n8TgGXIAwT+ge0h9gVqjMXjWZjGoVjSqVhia
Q9Yx/sZPOpvyb1AXTUe/QY02iXhEYUCuaES+9A3qpBmKecMgHO5oD9+gtppU/8BAHG6ADlCUf5uI
3xQG43BhdICiBtqUfjAgh8x+gPpUQEoGGNgrGtkvfYNya4eivoWBPNwOFqigzNqUzDCYhwRegKLM
upTM0EXDyfIARZl1KZl1PslBZYbTBbiGO/4G20+jfYVTBsi8xd9ga7uxSGY4QVB0hpDDR8n0ZT4Y
JxSKziiyvR+nFIrOKRROKlRqVqFwCgEZ2NJvfCqKWiROUOCe8/gblC6dXyicYKjUDEPhFEPROYbC
SYZKzTIUTjMUnWconGio1ExD4dRB0bmDwgkIXF8Vf4MyoPMBhZMKuCoh/gZlMLCcnE/KpWSA0wJF
5wUKJwYqNTNQODVQdG6gcHKgUrMDhVMBNTZF1onTCTWWjd44dYA8fgk+ypfOP3L4KMWxzOONPj1a
1Ns1zktgzaEEH9OpVVFv1ziz0XRmo3Fmo1MzG40zG01nNhpnNjo1s9E4s9F0ZqNxZqNTMxuNMxtN
ZzYaZzY6NbPRGNhoVSYv5dPPZfLC+Q4s5JTgo3xVYfyvcXYEq0RlX6A+VFusQ5xPaVXULzTOpWCx
KkBRqyoxsmmclWlVZut+KYCtBfjFgORqQEj96/JvUCd0TraeL9RTchXBLxnQGZn2ixE6ET1ov/TA
1h4WvkEZs/UHvwCRWoHQOCvTdFamcX4HS8XxNyhnOjNb+sYv1dTl36BU66LxQONsTtPZ3FIdKGc6
Q9M4z9OpVQyNszTNZmmZmb/GeZqm87TsFzjv0nTepXH+plOrHxrnJJqufyx9k64HtdWkfAzOl3TD
1tH8QlqyPShROltb+gblTGdeGudw8Dxd/A1Kmq6hLH2TrAfncDq1kqJxXqZbVdw/cYan28JoWuNM
Trdl3gnng5rOB7N21vol0cU+YwbRP33yyUn4I6aGcqbzRI0zTo1rQIm9InQjwO7y2fOnh5vD1ZOb
7enTwxsPBIBuA6heTtzYHyebB8r+32zYmH4Gzl8jZZDG9u6wfh7ta80EImB1aSx4BzZgqaGkRtXp
NFpvjHuZmobJAcErU9GPK1ZVEywDfakYFmzJKqRVNzOCaComsLqM2l1izXBWhqUgh0pkpouU1BR1
o0aVYA1zooVB9scV7TSy1kV4MJz+uKrSMOCWtGEoxWt/7DYchfXjd6nb2RA8Df9z7Oyl/KsjbFsX
eYQfH6tQFjOD6ySLoUQWkxcd19da5h/LaM2O6MLZ1nMNEGFEPcObeVi+ELFvSxFF1TMtmRDHQsRh
KKx6LGx1WxW2ulWFrW51U4hY14WITSliW4rYlSL2bMiZNDWLyDXTzqmwHZpCxLEqrHrsyijCObcy
xKGs6k4VNqbTVSliV1h1XdqYurQxTWljeIyUodiWaqYrNLOuKzSzri9tjDTcmZmR6gYh8JmAekLs
ihCFA58Z9eDdv7VDy93NtcoGqY4KzUDdjEwpHFR0AnGeXJHE+qIGFGIVibUvGor7maGYY41lWEXi
H2eiHIE106kEVpGGxiINqaosxKmKIj5VFTVTVUXtVFVZQqUqa2lZokSpIq1Pk/cytDK5qTK5qTK5
FSaiVJncdJncujK53SlaWW+/w7RWWaR/mwr1wEeTebTxzqrUfNY5j/aKxPrKkfTAc0s/D65+jkiT
pJoytLYMrStD6++uAV2RMQ/dq/IRRXHKWJaf/ZHT9quRzD9XpfYnVd+Z3xISncsPjTJrMjd9GMXM
ZS7Trsa+4hTn5hmjmJtnEJtCHvuulMehkOJQFVIc6lKKpTwOPKnUzs0pR5Fo6OaSIeOoSinqUop1
KcWmlGJbSrEroviTeoOhKNb8kZlSuixQLstjF1ObCeJVN/BUZzOXCe5E8jSDOBYiyhRdUVz984hF
lpGUu9aCKmEOjXc6OnvDQUyHKuHyLUEtg5aaC9Y4HDa2NdCgLJ5K4mG15l6NvoG7d0xyr66dF061
BHAN1oQ7FuFCK8z4V4ALt/6Y3ewFuHD1yljGbwO4ZfzCVUNVGb9wx5zZU1qAC9c/mQRvAS5c/mJ2
ChbgGr21TREuvG3ftmW4MIBQvTXjLK6GwaYJuO08XbjPaaiKcOFqnaEr4gH0ZsbeArqgt3EowjV6
66qmiAe4r0eVtW0E3K4Etwd/q3UJD3A3VqeL2mZiSNXVRW2D67a6pqhtxhIm3CK99e46rSK6HeAW
2WQPeuuKbLIHvfUFbRPuOZmQhwuK4HaoxgwNOCykhg+LCp7MUFxGBUdmtlAj6jwDLYzJqgS1A9S6
BLUH1LYEdQDUvgQVxp66pFmwlNA0Jc3SUNyUNEuDthrSrFQwY1FBW02fRkVTcZHDNEgSA6xpsGfq
Mj/MBWN23DMjGlyPdyLWZCOixocuEwVGjWsuI9rrEqJggMbHFBLtCGYq5AmYQynm0JYwCuZvlpvL
GB2L9AQdZSzVU1sV6QkCg6pUT60q0hNEEKpUT63pK8tEIdQwPbCMaF0VELUxCVyGV0S0KSCqqhpG
+HoopdqWUQVVNcVUuzKqoKs2SxV8WQW3+blRyNGlzkdX038W3f3lPkGGdPQJI97gPoUVtPt52n6O
5KhOyG12vkIQu0XEqVl8Q15CEQ5vyDc/II6rm48SW2h+U1dlvA7z9ChiUzerWcUdDIusDoWsLlgV
stro9ax2ZayKrcTzrJZZQINbW1awOi4oLHTcen3HrUs7bncE42Uytv1x7As7rplTlSDCpUZliLoU
sS5FbEoRC90V3HdUhlgoR7gNqQxxLERUVSliqWZUqWZUqWZUqWZUqWZUqWZUqWZUqWZUqWZ0WjPS
ffTr3ceC2wvuY1hLGy6WKnUfcKdUmSiWDUBXZvJX4vWbeRYF4nrP3JSFPU1fNpjC/VYlI9SwejBV
GHossTqUDaaqLhNrgyPjGlYLpcrXwzKszo9xnNX19l/at3TVru+4bSHxtlrPeKHl2v7YlPrZptTP
NqVesS0dr9rS8aotHa/aUnfVlo5Xbakc21I5tqXjVVs6XrWlmulKNdOVaqYr1UxXqpmuVDNdqWa6
Us10pZrp0prhYxPuJYKEhnAFle/i/k/3UenIhydB1lFf40G6UqvqS42lL7WBmWyDkEDLJNAPZSLg
A0uf2gHvMPuj6A/z9BMNLbW4vlQZQ6kyhrQyhAzGI6wMN0It2nB/TA/p14SvQ6mPGEoVMZQqYkwr
wvjLl2bMd22H9tslqfbVoXlhNj6kUJA3a2eFWUjaa9QUV9VsUOMFBPX2ywlAizcfTv00grxTNN5W
rW7bVirjupqdv6w2Gm4zur5Tm1HzNnOcGG9t0kyMSr8qMfZ3K8ZMWvkoMY53K8bZKeotxVjfutdw
Mc5Py7gH43tK5z3YOD9cCcRVqQz7yXw49/MaZuq7HWYwg7WspLFISQrHrZ+/IG/dK5kgm0JrV3yj
5Lwg9Xza5uc8EB/lIZu7HWjaV+Uhm7sdaNpM4uooMd7tQMMP+tyhGFt1p2Ls5n3YUWLEKyTuSoyz
edrbivFuhwKczi96sLpwKGjmhwKBqOYVmG67yixr/LyGmfZuh5l+PsTnSkJXtaikgjUXyl+X5e8n
QbNPYxLExeyH/agwnFS4u2cd9YJVl7iJQ+rw30+JpxXmDYpzd/DVwPt+OjdoMfVR9Jsy+j9vu8XV
xlWWVbKPBxDHY3pFZpLlHYwOTbTuJXkLw92g+SbBHnXDVAPb5BuLmtx6aHFhk65ZOSjAhS2tsPV9
EddY9uQ16yJc4Hcs4neAYx5VEb+DPXJTxq/dBDuW4MJDyvCodwGuaVtrxqsCXGhbU4YLbWvncL3Z
uHG1Hxfy0h5vYenK4y2krz3ewpKix1vIcju8oaoK8VQh3sJyosdbWEnyeAuLiR6vTB/D0nYxj1em
j2Fps5jHK9TH0lYxj1eoj6WNYh6vUB9L28Q8XqE+ljaJebxCfSxtEfN4hfqY2SAW4xXqQxfqY2nb
lsfL6wP3SE9jQl6ABDEvwYDY5FkkiKU8LmxQCYgLG1SMMoYaMOsFkoCpofK8BnHRZCK5IMmAmN9k
gEecIVhqYdDpboemNM4u7obea7TXaK8CrX+NdhTaz1mnP2e0n7NOUymE12h/32iq0C5f4/2d4pXa
wRye0n6zwB1RfI33Gu813s8fL3Vnymu813iv8f4u8HRqxfI13i8HrzBR9xrvNd5rvJ8hXvJqz9d4
vxS828+8a9zh/FPPBF7jvcZ7jfej4f3cPdtrvGPx7J7k4bZ4qm7sPr822FY9t4gzIdsrPpsyZPMT
XkIuQTYocCVMCbK9FrOQZ3vdZSHPdgdfIc/2ekpdhAxXmLe1KkM25W1TiAy7A9tCZKPBtitENj9b
2KvpkNu5kHRCbgGZaLCd3bJR24vMB12GDBo0mytL2AANjk0ZZbgTu6qKkOHi0K7qitiA28w7VdZA
uM68U0MZstFgp5syNszPri5sYAvIhQ2Eq7GbwgbC3dhNmQbtpeZtmQbtreZdmYnaa827MhO195r3
cw3EnU+13XxsPlvaX+dQG/iZ3xJnUY3eJtQSqnY7l7t9O49qvOf0sy1BHeBnfu+XEc8DaP/S8xAB
Md16VADedaVhl7Q7p1OnslkeE5xxCtNX7jFnrmWSJGH4LKoaNlAXVT1zk1Fp1QmC+etQ1rcFOkcZ
5ozAI8wGrppOYBrezQ/GZWX7WpN8h8R4Bn8ezWFWqcvrKUmHl3zMzFHkT9XoupDJbk45SuH5UIuZ
vgje7ewcFy4Y8nhDvncbPAW3k40zF/RgW5AifeGBOcKBnFnxf/uvTPPdCaIZ4gruPuvI4yMp1xka
lvZFEbtNYDd1QVGgl/aYET16V36WQRNOlGho5qBCVHFPXnAZcohG5SlEWbOqFs4gEMT05nNZdV+R
qsdi4+jNmYQu/irmY2bTf8QHee0m+XwroVimJVXN7JePqq5J1apcBCZu7+KvYj5mgoCID3iowfGR
fKojUMwP1QFxJlKIqu67Mkvth6rUUuuy3t6Tp3XSrTZuwLq7BdsHRG0cQ9rmOGJtKKY7CY5tFrEx
Ls70kib2oJU89Vf5z0wHMTFd7EI5+c7gtUnynOHetCxt+5ziYHxoYDipJkAcDcX8Rn5ANPFM15Lz
ebNMduAeFwY6QDR6mjkYxuuujSPtQt2pnJjFNIoC+0xg8spb8JAL4yxgdoCZNmVee2+8Iql9LLMT
Mw3qTdoi500BcQRW0mMeY8XMf3oVRJb2p4Bp/WSBvuCcaDVzUonXXhuXSmpXZYIwp0t74xVyPhUQ
QXszh5I4K53xquGs6Lx/gVedKp0/sGUxB3BuaQ/Dax+NY20LLNcYbd+PBZY7WNda4AVM0qUfVbrt
g1fCQFQAfhuuinVszDktreEANNxTu4A6QlYHLoF1fKTuawi1m04MbzGZvjxfPRA1PgSuLBa4XmLR
Oegh6biORVPJCVFj0wqGN+PfYJ4w/W8eE47ojklMX3eDM5KFIdDhNXrBQmzNhj2VrllgwiMyqozH
mbojHhfu0g30Fnol4s0cxeMtgZeb4FXDpTbDc1BNWoNR3QuH9nybZ0IYUbNRSVdiO5A36QptZyl8
cnjtwrHaQK9Qf+MyPaUhBaUXToo71NF4ETcmG4ZTdyBYVKMWjXHjAir4pqU5ukVlmYk2OboaRIWH
Oi1iBk8V4uk5PG8WLvembMjk/FSb9KQT6mizzDBILeFashBfIWpqY6ElC/loGNGWcB3ZpogsZK7h
oogUrp9a4EUxcKV4HQ87nmhvjM5fpO9oNqk3Gi0qXhSSzQxhTmgpL3QnaMgfXtCmbNJBZZQZUCHt
oDJSJ6jtDCryiag0ZUcZxaGe4uFjxFWuRTaVnEDEmsEqJvtpR9/PU+M3oGnTwduxTSFixQ4RKIbM
QAazNZgheusSJukwzVyPJFwybPYGsy5g00z2jC9cZtPMRau+gE3Tx7tqLKBpDKgz1zXEk1ySO/F/
uo9MztDMORIz4+T0wH1mvlBt8rNkosZ9ZqZWZt4Sf8ZFbiy8C++apnqOQzRarEOuJoNpqq3DDCCV
WXGYRo0kD5UKZx2mUSN5fHReOSY46OgDzhlU8xe9TGbeOEwn65oxTZWxauTZ+p6WnNM4kkZF7j0J
iSn4NDTp64cZVKOljtwTNC9808vZi74ZVo2e3JMNC/UbPdFnrmdR4WLyjl6VNMtqDXZNX1SdZRWm
Ct3gXWLyFIDDNOQH0v4MKuRYSDYmNf46VKOrYSiianQF5hpjzvqR2viyDswxQX/ekcDd492Yzrhk
PEltPGIHZhV/x0Vvct595a0kuUHfYRqXRB6Fz6GaCT25oEqn1tgcqknBkPdckwkgh2qyLsr3veRe
ZIc5/ex16Hs5VJN30STvkkoAO1STNtNNEVWTKdNe/gxz3krM/LY38UPiq5yVmJb2YQmsYGHAfWc0
Wuvkd1z0RkB94ztocjOYwzT6bIiQMqiQRSPZNz0repN07pshTZWxanTk3iTK+xwNmH0SU/BplNmO
Je7RJNF7euvcvHs0+urpK9bzrJqRvu/SwxOv3yiz72aW8gSqUVQ3k8gTrBpFwYPXy6waRQ2qwFBM
Wq4fZpaRBKpR1dCWGIpJLvRDn6bqUTsTspuGtDVRa52MJAAX9rM1ZbgGo23ncL24cLrSdsFam2TI
FzCDCbTJDhAwuzwmvMKpKth3Uy++cGZxzaxyCMwmt4EgrsmQ1MPSc1EWdwS6wwJdN7XU9czWH7SY
gAlLJzqzZ4UQXVhZokTHBaIKKOMl104JSeNW9LZQnF8mPRu8M6rg+eIpqA72kkGtAbVfRtUwoi3d
2+dQIfmycGUboMKDQc3C7itENVn8ZuHCOLwotFl6Hs613+TmR7egvyCqFlDrRVS7e7mgSRYxn3J0
ErVzsyLh1zColggfHo/WY11kKD2glhgKzPmWHgZ0qLCvcuGuQKt9M01pZvqfRDUrM0s3eaIC2qUr
K4FmbaaT06xuWG4/JIenad2yTdmUc6FB18PCVYRWohAnzTw1JlEhHV8gfOv7Zq6IBC81cswwqLXR
Lb0MFTaGpVDDreewyb+yA4X2/q9NTSrgUWQFSfzJpxkf1EcKkLgt4A5FuCM4AFWCa/JNE25ThGt7
YRG/rhum+Q1Ka1C+7YLBBsQxj9iCLuxosWDZFtUqQReg2uT3kslaVBiDlkzWpeCbhYssA+LSc6dQ
uTbxfbP0jinS1GO1IPqAWCB6DccvFu76RFSYJZc0SdmNSgXynFBhr4wqQdXWSIvMZADUEjMZYfN7
EQOQ4156SNZrf2ExzyO2S5cvW/E3gFpIcxpSusW2O8SFsddWDh5naeizqMbhDEVNgmT80tOODhXG
n6Xow6DCW4O6XrrJ2OHCAqnyIkiuejpc63uHqgjXhvU+Ap8ZV9ooAP9x8DqcToxLo07ArBfGBsQc
1YKDCohJBxXXPdalXI51MZftQv8IiAv9A/bX4IMbVSR0idiXIg5ziDjdd4j4wrpLTtRNBrVnqMnV
UYV3StvNGjHNHGJyWdav7S8s3ybwutReKYbnnpdQOpViXqo5SdGvtKZfn4goToNNGWKfOsBxG7z0
gxa3aLJO6jmBeUs9I7HFa9UJZtqdByZ1ZIzJjXY/M8TkXoufC6J2a9rJ521+YsQRH/hMYZpxBSaE
FhOTZ1WMGSzNTJYUf2cy6Z0BUeNDkzFi4DLelJH2owyxL0UcC2t+9XhMNMI3JteoflIGp1GwoSzW
aW/bwQ+2iSztzBrrpyA1OuRjCocKk90hHyQBagWnsZbySA7V5DuXJmcWFU6CL4XHDtUE6EtvbjhU
k0Vdys7hSZZpcrosKoeYD79c5SYztHDSx6LCE7H1wqlgX30983ZDjDhzflfqHlIyushMYLKrS8wE
FtyWcg0OFbKdC6OuE5Sh2hUIakI1eaNuYR7nUEczGSoU/zQ5zeeQCWK7LChI+kFqbplPuPCiX5hv
eu0vLTV5xLFA9HUF3qSekZL3eg63BtxcapQgw7JE36SRJRctbPPNpGcJYT9PPJmf7uLRhcn7hfPh
aaIBc0xiBla921cLvSogJj1KXPeoS7kcdTGX7YJBB8SkQYe6GxPZ2AMjpvedRCFdoNlCxMIG5vSo
Z3JGo03GhjRHmk/AhFzskF+5wh3G9dKTW4jY1AWI04BnEkJLz185VNjmu9TtLSrkYgtQR5uMrErE
BLnIallMk3s2glq43QJRIcW6NN5CwGO30ZZIVcHFBEvLptAquA5j1AXtr8Hp6EIzWUqEezOZOd8p
xWR6ZlskUdhWOHN9hEQFH1eACiub0+hUIiYwkyafsnbVQzZ2KdyxqJBiLekmsGhTF0kVEo1zmxY4
qq7gNMDMO4TBnVlcyNzawCM3lllkWDaDy7QSyIILsxKv547hCMK4LSK7JIgvHGs4PZgdJQLmwlKc
xxyrUppjVUxTF9PUaZpBpB6zXbDWgLjQ+6PLSWYGKLhJBG/NsZgz07KyIyMJvC61Ccrj6bHzfblL
8xgwVRnmeh6HLI/r8cZkCrPwPI1qK4vTmjUC93RvagM9QeySiIn31sMnQ/KTxn/SyE/gFrPEJ53/
pIs/0WUt6KpmbQvgnrS1LUg3OtcClW50Y2vgqH7rbXQaxaL7P8k3TeobuyPYfhT+Jl91ya9IVSpV
15D8KtJFHZQ2FOqibpKf5HRRd8lPcrqoh+QncQuawI4qNaemS3+Ta0MzpL/JNaKt0t/ErWgJR/n2
wi2DCcxce2HDbOKbXHu7Ov1Nrr32TEpJK+AOv7WtmGl5rhX9TMtzrehnWh63YiCYY2Erhjb9Ta4V
Q5/+JteKYZypJ+HN4GBWjJp3Z2Od/GjJn8HhqsRnCw5t7NOfSZ30VZAVO5CS0UlfjelvMjrplUp/
k9FJr+r0N3ErFOFIFbZCq/Q3uVboOv1NrhW6nakntqxee7XFB2nmLKsP9xklztHMWlZfq/Rnecvq
6zr9WaSThshKF+qkadPf5HTS9OlvcjppxvQ3cSvaUh/dt0MaM9ferkp/k2tvp9Pf5NrbNaWt6GZG
1mwrZlqea0U/0/JcK/qZlsetGAJmse0NTfqbXCuGLv1NrhXDkP7GT4ZasrfKzWTr5GzNxDY9vuvo
pmEZxGYW0a9it24epuDwQe1kzW6pTuCaOKYUFxJKhbiQuy/EHcv5batyfltVzm9rRodSXNjiWojb
rMBtV+B2K3DhUJzDbfO20/ZEb+ze5gTuUK/AHct5GNtiuvbyh1LcvpgHuE6hlK4ay3F1W85DvaJt
9Yq2NSva1pTrDe4mKKXbldskzKBK6fZzbfMO1Y7bLSxMLOSmHaq5lG3mylE/fHVuiNADeLP5e6YA
E5KnE+qYRGX1wz6AZmZjm+QUFFAVoRqqXWmjRlgTX2wU5Npt1n+hUWZ7frO0imIxwVAW1tosJqxK
lQkKbuZYWOtyqGatr0/LNCGoukT7NRzmq0u0b+g1vVrm1FRfdwUGDXnSmUuEEw1q0lyKBoHm4SmN
pQaZRa52aUXWYhpyC/eHOUyj+XGJJsQadrvCzF2XEhcOHruFVjW3dORwYQUvHE7K4sIC1szKXBCs
xfXrBJZscsca7kDTcycvFTrKgNmEQ+3pY3IedQQ3lUA1/edlz6jCidbEilhg1dBpKsvswtqkw4Vt
Lo1akKzFBa8+DkncIFmL2wDDdVq2AdlMLRrcdZraeRl4aGF3KGy1mfFYgazFBR7qnCoIMngNcrvz
jCQsMtjuzNYkv+Hf4fq1x5ziOjDHChq3sM3a4Volq4V1WoesoXEzyJILEPHM2VUjePMDcRumuZnG
+SXIzq9VplfjCGadxAztIuti2Z29ZnDRcFvtnIUJ1KEqQbX4NWNgMuQMbrMCt12B263A7QVu0r4c
7rACdyzHVdUKXLUCV6/AlXrL4Uq95XCl3nK4Um853BV6Uyv0plboTa/QWzgyUoC7Qm9a6i15fMLh
Sr3lcKXecrhSbzlcobc6hyv0lvM7WuitTrp+i1sLvdUZ+dZqBa7QW/LBNsStV+A2K3DbFfx25bqo
pd4yuqil3nK6kHrL8Nus0FvYqrsss2aF3poVemuk3nL8Sr1ldNFIvWV00Ui9ZXTRSL3l+F2ht1bq
LSMzvCGoCHeF3lqptxy/Um+Z+KGVesvhSr3lcKXecrhSbxnbaaXeMrbTSb1lbKeTesvIt5N6y+Gu
6G/dCj/ZSb3lcKXecvyuGN+6FeNbt2J861f4yX6F3voV/a1fobd+hd76FeNbv2J861eMb73UW04X
K/zksEJvg9RbRmbDCr0NK/Q2rBjfhhXj27BifBtWjG+D1FuO3xV6G1eMb+MKvY0r9DauGN9GqbeM
Lkapt4wuRqm3jC5Gqbccvyv0Nkq9zctsqMr1NuA5pSLc8vFtkPmSjC4GmS/J6GKQ+ZKMLgaZL8ny
W663QeZLsjJboTeZL8niSr1l+JX5kpwuZL4kpwuZL8npQuZLsvyu0JvMl9TJPbMOd4XeZL4khyvz
JVncFXqT+ZKc3mS+JKc3mS/J6U3mS7L8rtBblC/J6C3Kl+Tku0JvUb4kh7tCb1G+JKO3KF+S0VuU
L8nobUW+ZIjyJTncFXqL8iU5+a7QW5QvyeGu0JvMlzQ5ukJv7fw8dpD5kiyuzE8m9/g5XJmfTO5y
drhCb+k1Oocr9JZ80B5xx3JcmS/JyVfmS9pMH5L5kjbTh2S+JL2U5nCl3jK2LvMlWdyu3B5kviQr
B6m3nByk3jJykPmSXNtkviSLK/WWkYPMl+T6hcyX5PqFzJfk+oXMl+RsXeZLsrhDeb+Q+ZKcPch8
Sc4eZL4kZw8yX5LTscyXZHFX+EmZL8nKQeotJwept5wcZH/LtU3qLYMr8yU5OQyqvF/IfEmuX8h8
Sa5fyHxJztZlviSLK8e3TL+Q+ZKcPch8Sc4eZL4kZw8yX5LTscyXZHFX+EmZL8nJQeZLcnKQ+ZKs
HGR/y7VN6i2HK/WWk4Nc757vF6PMl2T6xSjzJZl+Mcp8ScbWR5kvyeLK8W2+X4wyX5Kxh1HmSzL2
MMp8ScYeRpkvyeh4lPmSHK7Ml2TsYYz2l2TsIdpfkrEHmS/J2YPMl+R0LPMlWdxyPznKfEnOHmS+
JGcPMl+SsweZL8npWOZLsrjlfnKM9pdk7CHaX5KxB5kvydmDzJfkdCzzJVnc8nhylPmSnD3IfEnO
HmS+JGcPMl+S07HMl2Rxy+PJUeZLcvYg8yU5e5D5kpw9yHxJTscyX5LDlfmSnD3IfEnOHmS+JGcP
Ub4kYw9RviSjY5kvyeKWz7vHKF+Sk8MKPxnlSzJykPmSXNuifEkOt9xPdlGcOt8vuihOzeFKe8jh
SnvI4Up7mO+bXRSn5nClPeRwpT3kcKU9zOP2Mk7N4kq95XCl3jL+TMohsydylHLI4sp4fRbXHFou
wtVg62hnY9Z2LG6zArddgdutwO0FbloXFndYgTuW44YzSwW4agWuXoEr9ZbDlXpLPf2rMBPFLCf1
XuTPETN56OQ15mvMnwlm/feBWZdjJt91SWK2xZjF8lyB2c9hapnSn0ddQVRHm3LLWf2HEn79SoSf
2733Wvhe+LlN0EcLP9o2Xs7q7ECvo/25xTFBjqjso+VE/6HMJLfn5HgzOZ7VfyThD69kdMoewXgt
fC/8VzI6RWdaXgs/KfxXMzrlDi28Fr4Xvhxv70b4ud2Wr4Xvhf9qBtzc9tV/NOF3dyDR7Fme49WU
O2HxWk1HqKl+JWp6Pb+/YzW9muH+6ExAU1x/WzxtLMdk6+p5zOIsfpt8rjmJWSyleUyt5b7aFRIt
7iJtcRdpi7tIW2zO85g6SiuusJJfQutza+e/fMsXQ84/mOXn9hP98lsvd1b8Y1l+bo/lL1/3cvfL
P5blD8e2/hdh+XJnzj+U5WfP4vzidS+T9P9guv+HjvWG+h9a90fHer8I3cvd8P9Yus/tE//lt/74
WK/Y8ucx443sGdTcfvN8/eU9bxZzjK4SyKBKb3IH9a/hNLcpXqDm9sRn669npa91dONMuY+ctf6J
qvRS5cni2VZNVOVyUrkEclTl6sfdyHV4JXKVEX+5XDO8Rrft3Amv8pzZXfAa1T87+k71yw0nd9Cq
CDPjreV5uHKqbfGY3pXHFK9p3inNn9G+av9wA2ZBa3MsK/fqSEBceB8InsOr4O2ZqvLPRuRQa0Ct
F1FN9U2VfpwpgVjQoKnyDirvsPI++TiWw+0Bt1/GBQZmHhNKIBY0qa7M+cG6UlWBROHFocq9JiRQ
AfrSOFrVw2tbA7DQ++dTaCiryeuS/nlJTB3Dgz3u2ccmU0NlrBFe7FldA3nQNn0K0yOa17X6mHrF
X8cU1LsM/4qjHiMfPSMfyv0kndGgjkfwX89Ih/OvK9AweU2nvAV1W9KCwegXXtpb3YKxsAXTzwYe
vlrbAvJkb64FvUE9xobIU735FhgtN8f0gTan5dDL4C6Tpj3GTtvCfmz2PjTtMW3oCtugAbk9poZc
Xw41KFvDMVLqZmw18kXG3a22o74psSOLeox8+hn5sH6gjJtr+mN6cl/Wk5VxdM1wTE8eSnqyqgH1
mJ48lPVkZRhvhmN6wTjTC0QLTC8bj7GhccZbRy0wWh6P6QNjTsukHxtXbd8kXllDWxX2Y+PX2+qI
NrRVYT9u1cyIGT+4HT6Z6cUx7RnZ5GgX9GBA1KF39WMhcR1eF+/TZ7M9Zn0E9aaY+ky/yhA3mYgi
udQzXidHWydpEwPrwkcdRNMuqF/ohwa3wpueEkwF7rswk8P3DQleEzhpGCf4jeMjfS8JpV3qbGLa
t/2G8aMrvPcpxVGyYy9Ql1LH7OWcKdyS++4Vcz+8Su4xq/equMf8WrHF341VCj5Ef7ptK+e9gb/b
r0g2vzxvENISBK8qYyHB6h2TK5VqaoB4zehrRn8MRjO+Ra/wLXhn3C/It9zBaIc3yL2q0a55pWN1
+4rH6nZ+rL4L7ptXzP3a0fTvPNLAGxlLZNP98rzB60jjNaOvGb0No+OJ/bHEKKNX4wWSKVcSmqRK
2zQjhRrvnkz0/CP5Hn8Mvhu823Il30P6WmGg2DJMnk4r5JyRn2W9Y9+wio7lvf+xeB+O433WXhq8
GP4V24uaj+mP5Lv9cfjuZvkObgr3zNXa7qCQ+x1CCz1mHdLkbNN0jDqOdRo1Uf+Q3phhuDI/PCZg
9zFJL+IxRlQpRI3vFVhWAfEYPLNPxOzvATyl/KlxW3WdErtDxUPO1TKmopgpSSKiLkWsSxGbIsTa
J1nd7pYqh9qXo05eY+zSthk0pCOVpzVZiodxO+xGqW3/4XfJpnCHclyT0/W46TYFXL0Ct1mB263A
HcpxmxVta1a0rVnRtoa2LXV3NcUdinFH2AbhcOvUHdMUtyd0U6MBxR0J3dRqHME1zqAYty7nt2/L
+e37FXTHEroa3g9X46BKKGt4QXzCbmZoBzfi98Wb7WiZHX0UsyvFbFUS09T0suWYjZnlA6fdkCQ6
mM3GZiF87Jbqd2OMUmavVhEmXF5Wgkn8sk7zGSF2qccuAA/eXtVwKZXxNgY39WiCwzUSqqE3JnBZ
/fD2qq5npC/IYtJpiejktNmgmHwn1tHsofquiNUBcNOKEmTHQlbhfVZdd+k9qpwoPjeyrADjjCei
bRFuDbglyprk2hTK1bh43VRl3GIUrVz3nyULZziU3eiHniXt5wEZWG6HImTY59BQT59DBjaHqgxZ
A3IZzxBjN2Mhz8Zz2m06Bchm+xJscylBNkprdVuGbAKwlgYsOWSjwbYpRDYabNsyZNOTVMvG6vSo
A8imvKWDavLRGoesAXksQzYabIe2jA3Q4KjKKIMGx74M2Wiwq+oyNnpALmyg0WCn2jJko8FOqyI2
zJrLhFzWQNi429VlDTSrLRNyWQPNWUXVNWUaNMapurZMg+Zs4YRcZqItaLArM9EWNNgVNdC/Q40O
t0tO20yMo5uKefz02OAwW4qpx1nMUjyf0SrAHIoxR4qZjjQtJr6Y6DCT80uHqXhKJ1M9TlxdJpmN
dGFhxv+JX9XzFUheGhYktNHSD+BrQb8tp89X/tqlnBd+1vMUVipniKhiXTcnTabMnNx1NSt3iamK
ac7rUmLWxTSbYpqsG+WkxPM5yQf4ELMvNmQ9zDI6bwV4WHbWzoIV+L1yCTsTrNTFGquLNVYXa6ye
15iQbp3pZZJod4ybqDPqk7wMR7iJekl9AbXJqC/jJnCKU+Am8EHFAjfRFCuzKe5+TVtMc16XErMv
pjnf+yTmWOomcMfLsptoVbEht/M9bt4K2qXhLlhB2xS7ibZYY22xxtpijbXzGpPS5TcK5IKZjqmM
YeJhZcRULFmuM9r1z0IkUGX9rGPlgsOumeVUYs6Hh5LRTD5IouLaaEGbikPJbizF7Of1JDFVqUT5
AtE8zXo+iBZC6ptieeIRjgJ59l1x/X15/UN5/cVaGqpS2Q+qjGZTqCMNx+8K6y7sSXzQy9Y9ryGJ
WTwhG1gvyg0m/p2DfhF1rJhnTF4JhqiqnCr6uzFG9el/h1rPU5UMNPO84lI4orbzVIVYx/lQXmL2
xZjzqpKY87EEl2krXp3NJQOq+b7ERdpWmYFJ1l/Po8r6S0emtjzBURX2qLbUP7TFCY62KvR3bWlf
bhXX0Hw41PLsRhazLsZsijGZfur51E6rmH4y3rZVhVLKxDfBNBVQxORbkxvlABWTFg61Ti4NOVRV
jqrLUety1IahNrlmtRyV7rBowsZnPyewH/E9UF2OlZ7R56+7hwqUrGGYryGMAxZ1nK+hC5vIOX3M
aKToB09nUVGbdaIFoQIla9B83kRrOD2xPxCV77hrM+KsuWZzkq/bjOQFaldONadPgTqUU83oUKA2
vB/mhOXXaBOos7bd6GLbbuoSy5OGgWmNWdMLhuEXY1OmJ3gpV2FTrsKmXIVNRoWzwm4z3VDQxzzH
SkfSZtQpHElbpE6hzXZJm8GRtDltzttL2xU7EgwjChxJW67ZtrxzdlUxVUyClFDV5VQzOpSoTbEj
6dojHElXPkh2mR45bxhdZowUjgSzIwWOpC9XIeZHCoTdl6uwz6iwsYImyHxmlwuKeq5EhjqAvIbQ
V/2rGX0CGQgPhHI/jyyZEN0uJ7Jxnl+BOmRiU+HkMFuSYiAk9S1qeWw6lMemQ1OOmtGYRO2K5Tr0
5VSHcrlmZhJCrmP5TAIzJwUMjLqcgXJtjeXaGttiFYxdOdVybY3lfWss7ltdVaytDrMnJajFfaur
hD/MuaIOEyh4lkNlnGeHORTnPNucR+yqbp6yBsqaUPZnVRKUwXCHNiAPGZ6BjYawMWZ4hlze0Htk
3DWSoiykjHmV5WigU7ocNaM7iZoJRyLNKa65nPmoTF+LlKwyI1lka2qYR5ZMlPe38jxLV55n6crz
LF15nqXTxd6x08VjWae5xvS8H+tEdiWLOpSjjsWotdBWcs+6Q+Xayrjnri7XVl2kLQ2oqK02x4BF
bRlqnTx35FC7ctS+HHUoRx0ZapNWAaD63IlDpbsSBz/PGPw0w36k+DQjw4rfBmLps4vFVahAyRrq
+RrCHNqiNvM1bH0FW0G/nacfoiiLKnbUsRaECpSsQWz2oTXsT+wPROU76tqcOLlmc5Jvq4zkBaoq
p5rTp0Cty6lmdChReT/MCavt5lFnbbvti227HUosTxoG5k5mTS8YhriqJCcWnztZFnZXrsKuXIVd
RoWzwu4y3VDS745yJF1GncKRdEXqFNrslrQZHEmf0+a8vWBKpcCR+JTKsiPpyzXbl3fOvi2nmtOn
QO3LqWZ0KFHHYkcyVEc4kkEV2/aQ6ZHzhjFkxkjhSHyGZdmRDOUqHMpVOJSrcMiokE44LDKf++WC
opErkaPC+xv2F6IrPpXh6JY2UYbfpZJCF4yIrpcJOscmw7NAzcSnwtGN3TwDwmeN5fHpWB6fjmMp
al/ltCZQValc+0qXU61L5dpXmdkEl2tfZbQlGcjMJiQDfTkDxdrqq3JtqapYBT67UkC1XFuquG/1
qrhv9apcW6p47ter4r7VK+ET886oV3zPHh+vhAvtMbuC6bO8X+wxw5KiTZNSFhm94pii3Z7gL0Sv
M3yTxJRFbnJ89yf4C9HbedpC2jozb5CofTlqTocCNROaRPoTb9HlzMjnW4qGwN6/B1c0BPZ1nUEX
jJT3vfK8S1+ed+nL8y59ed6lr8s9ZVM+rvk9KxZVz4dZvci2ZFHrctSmHFVoK3l81qFmohCJWq6t
JqOtMFq6ts/lHnOIderJOUDUWuz+mUctpnksYvLh5iQi3bC583ONnZ9qkE9wojEvgVHuoGD6D+RV
Mf2wF9vSb+fpHzz5w7HURaqPcR/Iqxx9dq777MT+QPpiM06pNrMSH+YlcjTN8e5pik0kxTTnhaRH
udukvlNb7rsSW8saQ2xswRj6ft7YjhbyKzCGPmMMtxey2FFy5w5DbEO5Y4ch8yp37TB8MuYOHcaQ
MeujafavgOaRtpxzGGJLzh07jDEz+N2BwxjbeWM7VsjjKzCGMWMMOytg2Xqcu8xTHcSOT37RkJ0c
qkFyi1MRjmzVMKhAu55Hz0rhToLGZh6VuZtc5WHX78rK20LUVx6x3o0sh59SluNPWHn7U4pdbJP/
kSvP9J8f14TbrJsRPomPPVm32K7xdQy5A7pdRHdM0bXpOLsLb4lf4GEXsZDk16biBmn9KbrHjes/
LuIthrBu3q5uPYT18+g/bi/4RSHq0oDoJ0Ss02eyX5W7zRhxQG3MHSrmsG1Dr95jZ34FsimHC1NK
kDUgj2XItUE288wSZNOqZizk2eQY4Sx9CTJc2VkV8gxXdqqhDBmu7KTXMuaQ4cpOeiN5BhkufGyb
QmRTDkfTCpBNnlC17D7Eah4Z5ExvzW4zlEHOgypDBjkPfRkbIGd4aaGAMsh5HIuQTW5Mwd77AjZM
0kvB5vQSyhqQ+zJk01Ngs3MJGw0gFzbQaBC20JZQhos1m8IGwsWaTZkGe7gatS3TILzpDrv1CigP
oMGuzEQH0GA/10A7toOvjcOL9MVUC4j+KgRT38ivuuLXOQtMdlcFv4fUV47LfgpyeS45odL3cRLc
luAmL3gguL1nge0GSqEOgdvk7etm2BpMkAXJ4+pk/p52i9kYzIW73y1mazDbJGZoP2B2ZgNU5dtP
Ww97yMh2sip81ZuvpubZ25eSa3AW0eAYO0uQFyxP7YIE6SLLI1yhEVhO3ldvMZWhufCMiMWcrAW2
E6MZzDNqfO5o8Be1YFJwkNRarr419+kTK0wuVVpUozC4XjqBKuo37qiqqhJWB0BtSnid6oZNU8jA
WGIyo2ED9i918VeMlxHeMqqqYZmX0Wydgg0xjhedvJzYohqMShXoDZ6KVvAk/DIDU909eRpJqzJh
dOazEYWhM7yADnVah4KXSWI9RLiOFz1PdQSqaQfBUc0uqgl14SEDi2pcQd8UWPFo9NCbEXDRikcF
iqsLPMNodlH1Y7UkAZNU6I1bgHXArAQsqnmNqE/bo0Q1XqxPdyOBCm5MjThEJHccOExTbELq2NtK
msaN6TpFU2IaLzYs9QaL2pgUu2c0rSmLaYadYeEZE4dq3FhLhvMMqtHUuDRAWlSjqXHJrC2q6X1O
U/MGaFAH47q6fihCNSPOuDREW1QNbi5t1xLX+M0xcJC8Msqhmj5gaGf9rEVtgYP0+ChxjcdSXlwz
jtaigstSJQobKhh3VInGBuO0YLNWFTtNIQTjtGCvVNa/WlQYbVSRysBrtZXnYN69DNZr6RJPMCgY
b3SJgxmMqPre9/CcLZoBrO/7IlRQWV3iDgaTCAA/lxACU8NoeFWqhe5mWZh1XaNhdsINDZtFVXCH
2oTrW6ZriYssKNXZn2a643zirBiUe8rPO6UuPX4NUe463RkIXhWhMXJ15fem9ouYdTFmU4zZzmL6
5vhLgetmwagJ5kIIhZh0qphkcwkxUfew4FMI5sIE4RVwacyxnjMNhjZvQWvQlECbs9ufOx42Vw3V
bdsbtNYEPLfxIenSXuO9xvul4dXVz5zB13i/bLwah8GfK4Ov8V7jvcbLdGDcaPZzZfA13i0V3P/M
GfyF4nXJVdgfHzHMuzCdoGeWtFKYCzktj1kvrVIRzHSWKmrQhNmEJmWnfhNqV446FKPC2olFbUvn
nnmarxSxTc+3Q3MW8oMEM50iSomoXPCqVPC3FlKiRTMrcCnMYiktZYcJ5lIiLWCWW2ddlaPqctTm
F2Xzdamvq+uFBeuA2ZQLvikV/N0KqR4Lp2U1ngNaQmzFo64ZxMKAshG5iz65C8Vi1oWY/rmRAsy+
uPbSBomngedFVBdqx7+xkUAMFozJ/3pmLdLfzhwwYcNfHXegGHUku1pm+ppZeqlH+zh8urf5HWuA
2/gHo/ocWUNw4K8zJrfM4VlgQvHngOcVCVvzKn+Z7bCIOZZiistWcpiqALOO2qOq4zC9EhETDpbn
3DDsOqlqYHFmq4jE1YC7sEqEd8hNmAuDNcFcGDLwKHewy+ZHwRuUxEvvyxx8Nw9L3el1rCGquRCt
T3oig6dhl1SNu9aMaWRQNaCqRVRTM+xgz+nFIy7Feq7yFipvfJuSW1gcbge47TKuZWDBggJiQZOm
2keofSiQqJmx1PBBiUSX+kRAlA3628M3Hrzx4Ppme3O+2+wuL65vNtc3Vy92N5vzbdc8ebY9v3hy
sz19enjjQfj7q683723+amuxN6qAS7Fb6yr/34unTwP4cHY2EPBfNyboNqM8ynhix7F84puQIj6s
Jd5Q4ooR7ylx8h8lLsGWuDkjoHvBub4r4k1CLHUg3kmx6BmZF3PeBOJ9LPPmdgptc8R3ac4PDJwR
SxeIDxHx4ZbE+0B8BA0QheoVnNem65lzNuZEjKUO15IPd0Q/EPfcwyaIMdBXVazX7nZ6VVWWvCon
b6LDmDzpq0oluF/tCTh5nSWvysmnuSf91WRhnIfGbu/dZIK8UmdnjnzY+xyIm1krXMZzNPldlSE/
/TXo9lVRb4B8t0B+sJWsJ69NuKJhE/IrqqCxFcQCol13TkAoPKwADkDF8ocXlV4R+QboZ43Te82U
5yHGGXYtC+Mcq1uQ9+JPkQfr6V8VdWucQwn54Qjy2gZ1Ott1b1VBCxXUJeKfZu/rKzCU2yLtHkW+
B/KqhPxR4gH2hxL9Hkcf+B9i9ZK+u82aZ8X6LqmDuIbYtd0VeesaqGdrI9c5Q1+JYbFLDyzwKiyl
3hZRr8uoj13Fqesi6nJIT1E3aTtVD5x8fWfkIRzpak6+O4p8OEnDyNdwcIeS7wvIS/A893RE7wTv
qnhAqWPikKOHzdZH0w+dNkEfXP74qqjDiML8cYdnIZDOqi5bx9zDk4aviLz1CLTP9tIjNH7E4vRH
a5dqIMFUOLrlwzVIc+lcBYeZBnhPTTzyXAXUeobYp6UnKtKnJTqW3plgkLAP181y6n5uvjCNM/JX
sXqnWHPk9IXbWTHHTQ0omgbjCfKFs1Aj1jT5Pkde31o6TZWl35XRN7n6GfqK0z/ObWb4p9aTGG91
gn6ZbRqNKzJkaXcGa9GznUnfAFZdk3k0GbWY9UeJqVU1RLN0uz5Lff8t2gAXLdgadMvaADcm3UEb
akKdt0ENsZRuo4e4DRWNym+ph3QbqjGW0m30ENtS1d6NLdWztlS1eVtKe6PS/gBVwNLpfBXjSlX3
sZTGrJTWVNCnhTRmhbS2BYZCL7t0LKMjm4DUZQX9q1OC69HZGobcqJyowacQqWcds71hRQ1xgtJK
qY59xm3aMERtUEM8/hzbhiHZBjXEUjqmDc4rJdpQjbGmj2lDPduGasyP0mvbENtS1d6NLdWztlR1
eVvaFtaQ7g/WsyaGaVLFdqW5GoZll1NNTkxravDURZdT7Z20wak60Qal4xqOaUM92waV8N6kDbvS
QTQdCDhVZ+OlfbWuipT/zsdLa2pIj6IqHy6tbUJiFK26eJw+sgnpUbTq4u5AFV3ap9N+ySmatqGP
3EZT2IbMBIUu1eho/XlVDTMTlLq7kzZkJihjcydtyExQxlhKt9FDog1VrOlj9TDThiqW0m30kJig
dHdjS5kJSpe3pXQ6Y90EhcVkURXjSlXHExR4u21eSmsqmHGtVVZIa1uQmqCwnNutmjAzQWFpqztW
gq2hytYw5PJ6hRMUlrqKe8OKGuYmKE1+dFjbhji415W6szakg3tdxVI6pg3zExSlYk0f04b5CYpS
sZRu04bEBKW/G1vKTFD6vC0dCmvITVDGbBXbteYau1bdZv3SmhratG/VXdZtrG7DmJhkxePPsW0Y
021QsZSOaQOaa9wGpe9GD/VsG1R9N3rANiTyiIk44Ng2zCQSh6wedqXBTG6imIiM6SxrZcyXHEez
ceuaGmZ6XD5sXduE1ESxj+OlI5swM1Hs+6yiS31rbqLIJiiD3Cw7DMl94WfJ3aCDtSXDpO8O3LPe
CX0uJO5Yo92+Q3pje7YCTfsz7Pe9W/qyAWSINt5JVtDctgH1XdOXDSAdzZxQkhUMt21Ae9f0ZQNI
P651XMHutg3o75q+bAAZcup4X67fWMz9RPFiN+nCJiejGfthKwOnnmS/E/RhSGbi6RP0U+JZQ59K
Z5T0B6xG0Ofgv/KjL725fjUouMpVsJ3dK9EkKzAPnfTscE1d1dkmTDU0pTWYQSBZw5itITfUiBoa
N9kxl2P2TRAS8aNm/iltdEhWUGKjlR3ePPEh4j49ElvudWxCZtjl8tFDT3RstgO3wkjT7JsdljDg
uxpMjK5lA6ALEx9qbo1m5OeOZ0UuAsnjbb+EvqZ5c7MhQDbgtKiXwR0VY2hEkJCm6+d3XUHjlkw8
/TpBP6mBNQ2oX10F0ADi5+BUEac/c65HbtKdbwDxEW2bIJ+Ufzl54iDMxERsCFPJDhAPYsFDc/9D
iA/x/uWyk3JDwjtYzTavijw800F71gjUQ5Q+u3Xc/iKScVN7I3y4oplM7WkE5GpQx9XgqZ/wyRIN
gW7RBjfTEG2wb5PRUfIWjahnG9HQIaarYjXrIg80a0TtK6IONkScZ6ek/GdilNm8te/Anv2Rpnw7
OcCsqiDt3MameYUtsDW0uRpW75/CcZJmfLuckFbVkByFpxr6V9gGV8VwJ4ogXZmbkqrHrJjW1JC2
pamGrJhu2QZXRVZMxZrA9FBsTU0V2+sx1lTPWlNTxYq4uza4KqgmElFd2eQPo4poclbRxa47pm9z
aMzxJSo4JCuYC4viwIXuUojoZyP3oonBVAHVQB1lD5p16Q+zIMQHNnrkuWti+uuyEzF9OnPqosCx
9LR8auKn7M1LnviQkH6K+BnPwQfpG4q8F+u6fZU1gIbpwBnFRVNkdMuJWd2+wgqgAfQiilVT47IG
6Ib0gD5ypCF2PF5C7aurACREfEQf+yCVznAVS0hpGvn2cuqaNdKUE9JRbD2JiAyXvZy8qiZTg2zC
XEejifY7rwG0QJsQT5DTeeSkFiJPvTPkiR81K0Pl5IsGArqzxSSouHjmQqJVCmheYQ3QBKrhyJXm
Kii1UppK7qWru/1grGs6mA2xr1N9qgnlPZlOoobIEenbZhnpDGpI+KF0HqSce+LmhiiBpm+dYoSr
ul9VBSAfYj5DlKHTt04x1nQ7zl1XAA0gLm6IXNxMkq68ASPT8B3Tt3P8fqGCYg3PzsCJmx4iN61v
P6FpXhl9N6GhnThy03VVpSpYNRDQ/SV3XgOYKa1ADgSTjG4d8tJTCHddARzep/SjkDrnp8saoGlE
OkbjjL59yEuXg+66ApAQpR8taOVsqHSsp+tNYzTx7jM1FFipraF+hTWAkGgFifHslhEpnfiNidHm
lhEps1HpqxUOZbdSQPMKa4AmkPFslM46W0GxlVIh9TJFN3NPw1nqGoh0Yl+zbOyd12BvKiEVDLKC
emUFKV/Uv7oKoAFkuBmjxa2Zm0TW6WB4hTWYJrArmKpK1qDuQAnjK6wBmqBoBdGQ4HutqKBKVZD0
F3Qjnap0YoUuVUE0psH2Cx2HdrqpqldXAUiI3qdTRWmc5va7QJqKVZHYhJAe94sjF7pSDQeWJP11
6fZEZFQxLXdRPjl3iSapIQxojP2OEo8Cx2nQLx6R0+Khdz6pOJnfz2h4x+njrrxIOj09y63iO5lm
TKj8nrlBkJc9AKc3Uj67EvJjJ7nXReTPCsibZUDVSPpyLeJ4+qa/aa7eIXHXXBH9+bvmGkH/Ti+b
o/skla5j6ZTN7md61rhAfCwiHp4U4pZDN5ekyRfP+JLkqeG4m6cJeT2T94u4b2Pyu5PNQNMqcNFA
LSL1MvLwPEQr6A+Gfr9Ev0g6tU7TnzoWHVZ0n9gln2rA7CKilH9fZcnPLXSX7qA2NahsDXO7k87O
qmQNXR3XQMctdxKC7mnYlh8kUEFKQUR1TF4dRz7SgAkdeup6Uucgkrnjcg23WfLjSvIpDXfZGraz
mwDLNUx7WeqkRdJ/lotoyJIfV5JPiWjM1rCdHQCKRTTQjpw6y5HMjhaLiEU/tyc/NIK+qusxW8O4
soaEEtgd5XEN29kEcrkSqKuIz6PsurI2QHyWUIKquJCiCvYrK0gIaZq6VNk6Duk6IjFhHQkxTXUw
c4qi9V2hU5oTFLtyOia/X0k+ZUtttoZDoc/LCIldkltHu4d2hf1hVkR9lvx+JfmUiIZsDYfC7pYT
EesNUfA1l/coFRG7Nj4mP3dd0QoRsZvj4xrmLhJeIaKR+bxOxka7wjOKftotg6OxztLfH0G/Ey1g
fbmPW1C2i26+BW2W/v4I+rIFrCdH8emu8JjlfAv6LP39EfRb0QLWlaMIb1cYIM12tDFLfr+SfHJU
q7JVHAoDsOygRjtzo+VMdufXPBYCmPREWbHsXEx+v4J8NNN0DaizNRzSNcTxEZFPNO7TGhK5hHam
Bt6GRB4EctZ0W7hqVZzATJ/WLUuzsDuclMky86OQh2HOSoV45p530uziBtXWUQ3b29dAFWAWMXkN
Z3fQBqYDm+SlG8WwgoSZ0oW/2TPHdNd8gn7mXblatqDrIyM9sblpVsHxm26TS8eqGkUF4lT2ATPt
vIIJfMYqaJMd2eSMqsUKUi2Yq6AfpZKHVipZ1FC4mQgyLsmD5TpPv/CO/NE2oGsj+nWWvuqMwZvV
aG6kBwb29BMaaPL8505NUw1UNrsby2dR/kn6KfmnppnsbZQU+bKUryGf5F52YUm+bBRQTUL8VvoL
4i8cZpQ71J+oYEn+5Sl31SQrkBqoRQVl52pnW8DutUhUoG+rA3b2JVlB2Vg8KyJ2+CVZQdnpF2OM
6cz7koTKlqShAXKgAfpLAip7zlHNrRzoJfkkZ2Yx/XpOw2pJPuVjgErxL8cASb/8XV0lo1HgX44B
cuUG/8vTr1PxNPAvnVBEv4h/kyxO05c+SNIv62B1Sr9AP++CtB9kFuinwhSgL0cBSb+sf9XdHP2F
/lt4qrye8w96of9WdRn/KQ9q6NcL/bdwzRiWVOUgD/QX+u/MHsYkfRnnAv2F/rtiWbqW/RfoL/Xf
8iClTsp/qf+W7eMF+nIIBvpL/bdsJzXQl+OL8W/1Uv8tOxEB9OUADPwv9d+yIyMw0UtFibXsv8e/
Tp4MIGrZf4+jPxtiNbL/Hk8/Of6yJRTDQVeS/DZTDEXpG/n0cvwF+qz/RpeHHXZJ+59NFfTRJIzt
bGiHqILDygpkLoJPA7rUjq2khIp3bI2CfLRjK9kBindsaUE+2rE1079Kd2z1gn60Y+to+jY+V4J+
tGOriP78jq1W0L/b50HZFK+P81iFG4fmH3NnU7xEBaUbn5rUBdJQAXsFM+5f6ccwynN9dcUm8n10
td3ZkAzhVmQTh5bWYLY4CCHNXAS7Qgt0lBlUVMHMjb8rKqBeYtCyAnXrFtADU2qoYxElZ/JrKqAd
eWhiEd26AurphrgnNMmesKYCOtIMXdyCW1dAR5ohuq+4auc6QmEFIzfTIaqgv3UFzEzHyExv3QJm
pmZlXa6ezFlRVVaBHtiAY1bWpb+b03JhDYplvcfEAlByxr2qCbQnjIkFoOScck0T6KAzRus/h+3+
dhVozVbJxig1etAzTajna2g0bwMdE8bo1txDl5xYptuQCtzpoSw1Rvs9tZrbt5LoCiQ5QWXU52tY
ee9vEy3Q6CrRhoq2oXByT6jzCtjsbIyG/sOQnF2usVTikOBlGGlHc1u4Sitgt5snKjisc0i1VIJi
15tXkT86m92EVtwCna9gd+sW1LSCKHapMEMtKzikKzAzVvGkA3uvrYodnl4RQab6mmLvXyUq6FZ4
VNMZ6qgC+lJBFa+op9OYa1rQ5ytobt2CgVYQh19ze0pXaJn15Tj+am4ZXKie9eU4/upuXQHry1H8
pW7fAtaXx8hhp/fRJR12ejWrbxcqKFvwS1awOzF7b6p8BTPnH0uuMR7MPkYqILMwLvkvW+6bE9BA
I2x485Qni+ZuMi666d/Ihz3mpOLDlVWdVPCh5/S7xO4wo196iESrxF2A+mjyYJ7UenQXbQAsPF2p
UotlZujt2fOpOso2HnPTf6gBcrGKvSkTV3F264iCvSmj40na3IrNnCOtIkdKD6rAa9uyhpnAcUUN
1FXXUVR0zH3/Qg/TLGfI1nF260GfPbtcR4FR9qGoGU2bXDKtgZprnTgqPaPqop2GA3OldaIzp5cW
S30Fe8E23gs783Rd2U5SEE6TpT8n/tQ+Uti+xe49tRtJ6fELeJkyakLaH800QUVN6O6UfsVbcGKT
RKECFVdQeCpvVgdDlv42TX+dDqiraKJzQsMu2QfKm8Deu47pb9P0VzWBvXjdRKd4hl3hmbPZJugs
/W2a/rom0M7cxMeEDuVNmLn3oM1WcEhXkGwDvC4Qt2Gqg3W3aC15t6I3JK+OY2/uxfQPK3rDTBv4
c9RNHCGtMKV0E7os/cMKU5ptAvNJ0Unt3YpxId2EIUv/sGJcmG0C80lRZm23wiclewN7ojimf1jh
k+Y6A3vft0nEeOlIvniqyZ/3TVYw04b5ChpeQZ2vYMXOwOTKJn9/so3mgnMtKJzssCMMuo3Cx9JL
q+cSzCxFruODJKXXhs/Tp/04PkZS+tzSPH3aj9smDn7Ldl6lg1/FFjR1amPR2fHigUMZ1Ee0dv2A
HJebuZDCzqFqQt98VpNpjm9CzY5QYxXqyCqiWZR9u4Bu/7lNK0wLdNSKxjq7+m6aUc81Y6qCdeU+
2YxBJ6sYEspopTnV7NZYHe9jWlNDK+3VqaK9mzY4VbRRFdO3/d00op5phNmNTGtIrEklVwbLnQZ7
8r0d0/aabsFcr5OKHuIaImstrEG2wCl6vJs2kD4n1cDerb9FI+qZRkw10OG/i6a2umKxynr3ylrQ
RdO2yZBuN7px/uPl3+G2aTy2MxouHpOL5LevgbUh2pp1dgdtoK7bLC7IdHZ6ulCSzjbsakY+vpVK
r7sTKV4jV6yCyB0N+jZvK0MFdFjo4ySYvs3bx1ABHRWGqJ8N+jZvE0MFNIyM3hxQc9dTlN8SrHg2
+M6rcO8j0t4WPT2QraPspmCl6N1IOrGDrfCStvkpFd0Imapg5nLL8hkPPYymh8RLznPzzlKnyhQd
OaS5J1aK6WumgWhYW3NHYZq+M6K/PXzjwRsPrm+2N+e7ze7y4vpms/t2e7XZn18/udmePj189fXm
vc1f33hQvdyCO9z18NPMBB1EH8zPPYXsAKcKELWzTJ5sDKURcE+te4V4AGKsl2Ml/4a7HV7CTYsv
YbsFgRhKDpb9QsUQiw/y7JCnma+rKnxhf7aA09ivFZGJo6SiL475KSnBLb1OprtbUbI/bRvtz35O
fvD3mccHiQPsYLUNP6tTkAf8bXy410dP/m6D1YxbS+nUft2GmqxGrL5GYj327w5+DpRX1zo4bvNy
28FP26426M6V1uFri1N3oQbzt6G0H3N2OFThu90ZgQC9AeBmKQ14gvoOOtA4EHpU4rbtW6IP5aka
SkMdyhXUWg2k1hlKNemPZkUMrGAry63W4DjUy+qwzB9S0kQShzMp07OBlG6l3HWNVhV01wONURP9
q2DpA+mvtL22nv2pk1MTrOQM9NiQ3kIpWT5gl+TLzmoW/JNZcDCUrJ0ORE5WB3lKbYLSNqYErdhb
a9SByzbmVeFXIKd2CQttjlqKIvAD2tOcXdfBSpldE76DRUDriM2yL06lRTfUYtvAfZPwT7HVqQNa
DHK5P5Olh4r2u/0+tJ56ujOiTedhBqkP9ON5bTuJw89uP28dhpL9QtMvxuOsQJ8tW4Heh75kfew4
BitEP94RL9uTv9topIh95uj7N/jMIbTC+UbiSYaIXtpXhbjAeiMIe7mvqkJptQ+0JT2wgp5Yv/VD
B9mKM+rDxpRdQOuEZSzZRUW17H1YsCf2hQo2ab9o90t2QShRnY8FdkFkglbgxv/CXpG1cevXaFva
+S8Qf0fxVSzx5V6B44nEAU9Hsaz/agKu7SFnUQ+xnrPxfcJQWt1DiG3te2wPWKbtIfv1PcTDcTSP
yms6mu/me4jvHxXl6bCXrTgM8m9qIwdqI3XsM+d6SC/GSU+b+YIhbz127K4kpdMUJb3Up5Jjac9x
0v3Ojmh0nHHWU833qMBTibQaotlecfwwmrORiWi7Oy1ru+wttVqWkJ33yXEmRGJWEtRy1/UioEQs
cN+FVrhetCvrRSFWcTEYHWf6qBfRceaU96IwA6L9qKL9ZBf1IjrO9LS3HONrUcvK2wWM5gW9pSJ2
0Z6l7MJQWtD5aYFdDNQ/2ZlCpYItrxtnIhsHSgc6bozZtttxiemurct6hWiXj8Cj6JBiWW8Ds56K
6N/OSKg/5pmHeBZ4IB5mJHboIHRESMTjI8Xtoq9rzkeO0p5+t4sojfxr+m2YATncPvoafu5IfKdI
1sXO+NqBysn5fDKvpnPRHZl5WEhD+uZuSymxuWX00363A24O1u+qwJkZnUKcWdURbhVaZEcyh0nq
dFHoWTwDcvZkvd6p7C2xj9N+hhZG87MZvVg+tpSDVpZ6T2fLia30GS/LaZyyOcJZlD85I3FSF7VF
E0pnvjcHiVOfekbmApSDPcVJ+PEz0oPoz9m8j5V+zyEhG8K8ThU4d9+dpfTlS/cJTwd/04ha7SIa
ZC5qsztoBZTGjvJh7QL+th7G+uZT0uqBxb6dGJc9pcgWnPWCvdh5+GmP2gz2VM9pu5uBCM6kL6Cc
5bOhjLOOzoDs19WQ48z2XQeBPmMtCGeKFfFcNpfmOCd+yOZBrdytD6aZzy0bEfak3XP5OJv7sHKw
7dr5KB68yiFYtCs/zVFqKKYfsUJeZdeHr+d6raVUEd2oPfaGQOn0bIYPwD0QPk73kkuMMBxPxJOU
5FgtjZAZg9G8keXVEDjY6TQlawWn3s9AVnsny1vih04L+Ks1iwvgu/bAy73ObWnUH4MsYUZNpWn1
PwYadgWGcpP2htBbIj3T6Nvl3qKMr8NkEt9Hc4E5S9rGNZxSnmLdbonu9qMs7amNn1FKJdZT09jM
riC0vBSyIaR8nLMekm+1mDTTj3Ki1tMDJTtu0BYx2dj42NqzjfuRJzoK1KEPaNLvbCRmv7ZrFxWJ
ynG8q0iG0VK1/quaiU/Sc7NoLtUS3XXBVmkplevWr8Cko2jbT+gMst3L0paWsryKm7fYcZxEASXW
sR/oeLdtZHlDdDrOUbLarCglO9rTcioPyxPTvCK1oe5EFtBrnnxtY9izM655pDcy//SKrID6zK0s
pfLb+h6QtQLqLXeylPaxtrsrK9hxK6hleU10NxxmKPl1J2IFSpZTeXSHyAoaIgGcm7dSF6zP16HV
TvNkfc55a5frsTGp9UOnSQ2XZDjDCtdI+z9dAyDrxE6iyTUAkush2UanW+pPaHbNlrakZziJH6f5
U8qlZjzZn9Tn72Yo1UGitZ+/E0okenSa30WaJyumTo9+/0OYczLNE3t3X5CVzyapzZA7LJlFj0SW
bmZsuXf9juGSiJrhkrV8ByEtRe/bkJlaNbNCx2YHZJy248K+pa0baBxiZ6b7CHKK38VfhdkrzQU5
SL+GM4ifknV4eocIsktxFuacDmsbfTdIzliUYtdhB9Y6sq+iJXGmhbj8XYXfcd/h9zwM4QtF5rgW
QnecjGRuNgL3dtZdtTRPZ0cm2mtPSfw5O1NoqcRdj2xleU+izdNG6o5idpxSlFdJcNAEHdivRj8a
Ej9Oy8ccB3RWEzKIYTdOCTcjodGf8dJAyZUfZrhpgv4d5p7Xnx7NFR054buulqUtLdVxdo3iNhRX
LVkKrARmbUVTW4ikH2oDOemcpmgbT4l3lfWHEUGRXKrTMLVVOm+xpT2vX1LaU1wSqy5bCki8QYv3
Gt5KbgZauktJI1Civaw/XeIAv6qYxOks2pZTfXWR36WYPF9g109otGz3vNBIzHo66ZNoblvaU1Ef
tPZeBb63e6Y70rdd+dlMu4j/cZgH2u/yHFDdjToqrainG+e8Yi01S9clCvtdHXh11tHL0o7prp/z
kMQKasLZYr+z+w9IK2icqcjuBFe65/VLStQn2bmK2xdJOBgIZ6kMDc0IbLcRJOprrPSUWsFsNtzq
+UxCKK8+OqTli61I1dM3MaU+yviy0naetqTURvW12xxtG9Xgfjrb/zvb5y2WXY21/Z/MWK0vGGd9
wbKGk/rtOQTsKbJx9kUhbZDTTn49RGM6KyXj+JoeXFPdKVnaMJ76WnLAKNGRgkTOSz24ohpuJVVF
S+dHTkuJ9uBO9oojenATQbK2v21X9OAxgpzGrWPlxIrLRyzFYt/uIMvpSByvMjJMNrZ0ZwUcgBXQ
2Kf1Ixb0O7ITzJXPjVgWk9qCzeIyX2AlRGOB2vaKIcjMzs27KFfG5+YlGmwiH9yqmBIrJ/TY6j+B
uJ33ftWarATaEruinv+a7DsIcLBM4i1pFNXR/KhdXRkDPduv3CodSpx4Vree0RAOSAY0Z7HROoLN
vtLIJLJYai9b7yOCxCkutb0tnc0ved+aw9BvzHpfsj7HV3HzNtTFkH2qHtLvdmWtmKQfeZjmkNjz
QMv3t9cdnVuOUTzGZkm+pWnd0fnsWNjq4DOZdqIZHysls7xVumsjSJ+qh+iuK2vFJP0uggwLurP7
M+jMiJzFcN7Q7kHYUq9i15kOq3ptNOcEL6AJNyPNT5CYzvVEEatKSjQioCeRFkZUP1oHiQ/Z8Xog
seqauKCLelZ3mqun25bHBU00a2jErEHGBc2ptOLZdV17+qFCCEgcYGeV5J9+cYjHC7L6VLuox2VL
6GxjDDZURSPggUic9zua76a5GecR7MpoNFOgmD4zanHJniy2B8iWztmILWUxXbz3glGa8zO2VFFK
8denc/G9LSXx/WGglKjlzkluoJKbj6LpSpDFJbQT7a1jSqzFTfg6L7nTswVK+a/nep+me0OYbxyI
/XZoxQiviFxT0aHKczM3B7Slzhew3kR059ZhafRF1hQcxK7PoBWQWYqNx2xEWJGYbnkeFFkm8TB1
5O/inWh8DK57Tn2edryTQiXiAla+m29FLi6oopiuysYFVdKjRiMCmeMwSDIW8KVu1a10fprUSmK8
i3fjsS8yuRlJSUU6V9kxTm15GwrGOzuni/QvT35LX3B2ttQKL+WaQ6DfRSvw7IuG/LQrEtGcUqEf
P7qv5XJiNV07rol853TqZzXLEauKokqV7MfECpLzmkWdnjJKFpac1/jSxfg+UDpEXx+y4+6BrC+h
Pa3tazqy0rqKRwT2RYmVWhnXsRXE+0RYKRlXC/04ybQwyFy+1fUWups9r/P9PoL4MT3y47ac7Jix
OmrpjMWu8dr6mad7Nf1O05MeFjJnsbbUW2xBv4s1mLRY0u+Sc9LFftcyShaWHYfOFmekgRLdX+og
c+sZtvSUa+WofhdDtgv9rsRi7Tizj62gitbsWCndebum3+kIEuU5Rb+rC1phpdxHkMReI1YONNgY
F0XDNsIM0TBE0ZXkOY6GF3ht4tF8n5192X0zzEd4XsEyrZewcQ05L7suJj7KMnUE6Rcsszj7U/UJ
y8yuHVZkZX6NZR52EnIW5WaEZRZre3eQkH0iW8vKNdfLMX5cRVl5Pdciv6pR6sfZjk4LSVpv8OPV
YoYpqRV+AsTCMnNcvO2lzI/vTuXXu2xsthOzZ1gJpKuu1mOQebWdV9m6c9pclriO5mw6GRkFidNT
mAvajCELY0s1plpRELFGsdFhbpyxpQdOO9eD2X1Ithct9GCb/2M+tSfatB6VxB9utagNfQl3BdAv
bKRIsdpoZd6ubdgVHbtjT7vYl57M6ol3tmOVHQUqMtLZNuyoN3dyaoiE7Bp6Tc7DuxsK7H5Jup+b
3FuD9zycEp/KTqUB1ZasfNTbwKulbVfK8RSB5HOeSxVxGW55AnvaB8t15z2j3Cblsom49Lvj+6Bn
J18yO3TyrSXfzP6cnPZ0d7f1FZS/NsefZusIlsMt+dpaTCk3NhoK+UxbB9UL3fsZc6OEtKDfUW5I
RDtSy1yUXJQ1svuO6Q1ewMEpqW0bnVz15zmBj7NItz3ltZ/nJho5LTeRHqkmtvsUN5aX0IMpNx3l
pi2T1oyn6wMW5Y/eJ7EV/QAk7jnETDblj97B1qkUNzndnUa6o9Lf9pwbqbvTiBt2+4nVfMYbQj5z
0R/O+5nW+5ngC86ofPeBc9feOf3vUNek30GLqBewEXopl8DTGbEC6rUryaWiWtlyLokVWK9Nv94G
nhyXZM4hrRT8eIkHiuzijEqxj22c8ldHdkE9gt1zE6w0jMGz3IySmwOVlo+Vgo0z7xxJa0u+7sge
yZFb5hEjCc4OAq8gcSo7Jb+mvFaR5IJ3gNXucR03uz3nxs5/Q2/ZHma4OY2s1PpmKjm8we3ocRdX
8fzIuQtacPzNRS/2pEwkLX/awnJYr+SGxlK7eGyhOx9jbnaRtMKdc2Gngl1NtpxXZBynK9/Wuu0+
4IbsZqhYb2lJCa2bzTYAYmu2EXW4zSd4OpYFIH7NlSpZqgV/gaeKSHmWP7t7jvLXIH9AiZwloxzQ
L5qGlFayFEepUpnmOQavQnL2juddSqacY4rf7JjEK1luM7Gl/IFXiWS6o/wNy/z5k6GWQ9KbdCXp
uRjX2q2dxcPfYb8UjAjEC4y0x5G4hp4PHUk99u/5e41stpnunmhJH3SlhJLYpUs1Ys+E7cnXJDIJ
fOQoVYQPK31KqRJf+29R4oSPqidfE9+Sls0MTzpox8mG5BEU6XEJnhSdUdfkvBxt0S4jG9m6M8KH
olKGL84yX6Pl4Sy/0vJra3V03m/5pvd72tv8gs2FdfOc1c3b3Mh4stEXlSzNokjJcou1GQS/aym6
OycnWW69brcaUqqk/cZfO4slp/OpXP3t6itl05PWNXvGky3PWJ332pr0JVI6DpSnvGx21OaiHrWr
5ryKXStxe7KtbHbha1t6EDYH3vcQ5GStzu3SroNUlr1eQet0KHVS3gb+lPeDMz6T5DOdfKnmyci+
6H2rYKtOyg2hZMcWYX/BP1k57qkFjlLKeyGb0hGhoRZINU9298378Z60SBPNK7LDftH7VmitXjZK
ymac0W91RkdzJ5tOysb6EHc7pM2MknuSKhbTuTvR6b0XY9COs9U+2MWafWJxz9lSndaSb9yxb9cC
bH7CjgiN4Nzzbde/6oC/89F1iOxrcjrK7ehfFW2U9js6TjdUp35tINfvWtrviE5d6Yp+RzPjNvqi
ttUv9LuR2NaBjMe2lI5ea/pdRX33QbbubJYn1zeobGr5tRZ85PpdS2VD4xYbF8yMidjvOiob4lkr
kmGKow06K2zwngfbm4jHXTuW+rNJ1t7oeGi9SjbOoH4QV3GpTJsSPqw9UYnuGCX7dUamXjZWosQu
UOJ9JFObQa7oWEpujNmTPt16rxHm5paPoh32lqcx5mk2L2C/aPkX3D4zuypVaCP9usrWtt9TiVf+
fYIjWspuKayiG5UTX2jJa7C57Dqn5Zxq2766kKwNbNx+sZVf7MlI56zD5rDs2CEsBSiJXR5oYfk9
HpJ7mAENkptdzI2NEchIxuwWVwLbwHNLb52yd4KQ2FeTvWvuRhN7Jw3aE8kXuX3TdE3MQraBVzsm
uv7t58TgxyMvULSWr0JLuO62kWTpF+PiyUqYlVkOSAxxSvKn9EZNVxrtOOOUBkqJZH9KTppW7k6q
U0Jj3/NyHwHb0mjfBKdEY6N9W8aBHxmttbVsNCfvVbnyZp4DvxJsMevbW0G4vzlYwTh33sOWintZ
clbQU3sj5yWriI94D5egRNpN1x/XWAG1Orujh0p2S0szOiBrrxa3LuPAexWWp2O6peXJXkFPWHhM
5+mCZ7iNRQClkcMqd15y1iLI2tb8KUzLc0v1eCpLO1o6ewrT4VLbIru0cxYhJU6tiq55012GTsti
74qkxMbMap4D3gY8L+X6wF6Wn1HfN3Nri8NkPdie2LqlFXSyXWM0BrNSsrK8ZAUN1V1sI7TUj6Vp
K2ioxZA54horoJa0I3dBOhuhpcIzRpSoPS36SWzDnutuK8sP1E8mb0XylLg9Rb3WRZsFsVRmd5eN
G/YRZG7nmLMneqNl/o4BGz/tknA5R5j7upmBuzjdxZkub52Mr8r7T3qOMNYRZO7shC1tqMTzFkPj
CXrbcHhrisR00T57hkv7WvJOL5jfZcc12gd3oywNHh9yYpFNMlza15KjStSDh8Cts3oa3wF8R0vF
GUhJiebsnAxuZwWxnufOBCmsrdQKaLyw1bLUZx5UKJmzAhpVbkk8s8YKqCXtOlkaPH7YPTFnBTW1
p+SokrYCGsHZHSTMRmipiPIjStRiol4bW0SYv2dn1PCT7XKupKWLGXUV+hT7omQct5gN2/NQSZkm
vugiiJ/ngJyq0rpPdxGlmlJK1K0jiFqqLcjpdB99nefvjENgpkgip4F8kc/7sbPWzsbrbMxcxzpX
pHT+pLEt35XxgRnueUqJLBnlIzmmB69Sk5MURbkZSnuIVyRYG+lJc/rmjYWI/AjZjXPLeVBoXRtF
wG12BLd3RAVfNbM6SV/Sg++6uJRQ7RKndyguXYHrkiP4cjxO55PDLiol3IS7wKJ4nNwO7HAzIzj9
KmSQ7Xd0nctSpTH43G2NSInG4P2qEXzGCnyezEPmzj3bUrK/YMkKaLRB7611mqWlbd4KaIzTETss
tAL6hpJtby9L6Xr6kDjJxyhRKyjJ0PR05HS6ayVVOk/r56JapEStgLy6cReRfXOQkLm3Cx3+WVFM
Z2MmqsdIy6cssu/mckTkZRmHSUbRwpiul1Y1NLI0eB6IMOYyp/TtLUspkzclkVgfeHJ61JIqnXn0
IsKVlGjOwZ6CuaUVnEaQudNqtnRXbgU0U0nfKKn8TerEP83lhSwlIqGWzMDXWAG1JPrWREXuqPdW
EPlGRonak/CTOSug+fHuTFKlM49+Pk9nKVGLmem16Ugm6C6fUW90BElYJisnmYJ1uYhinmLIdoEn
kkvL2yodudstk3gX+pQrn8texZEWu3O4KMvfS3vv/YoDrCOQ/d41GdPnbJXOJnv2KlSeAxpLdTtZ
qpjP7GZuw6/I6OYozdyAuMoK2giSuHGLlRNvlLcCOjbju0nMSmj5XARnKVF7GY6zAtqG3q8yBCug
/rWPvDajRO2J3ayRlweNlrpRUg0RNVjBXE7MUqL2FN2KEiwiyGnFDD3KReAtYLNfRLkIqpXMGXiL
20RfZ3MRp+ydGwcj0UN5S7e7BKXozCWrO8pF0NXnTH7c1hflIk4z/EFvOYto2P0KwOWOwO0IM5IT
rSE+DuvBI6kvvkVx8N4DrZHmOZbuXTuLIdYuVIAc/A5Q2I1DPK7djUH32zBIlBsMnIXIfoikSV9b
p1QdhOQf/G7mM2I3dk8umS/GUqE/a18aduPQt8Fiv2Brc705HvXQP7WyViZ9+92ZpEpPnVSHeJVk
IW9Fvx457bBKUpOMwOzXTcSZby+0ruT2GEtpH0GY96U618SWGYRaNKkhNd4lonZr16eSUpPED1Zg
291VqfoE7W2wttZbHsiJ1Od66mIe1FPlPtPC+kDD9c7DGqpgBU1UUxtRtVqbOcuO9kS9gIr2qx4G
yVl8FiOZz6RR4JxVRafiKhX3lsR30WvrNv8o729Ot87plsRadIcNnaeNfmdz8OMl/ZjFH3Td0VHq
VeCpoqcZ4q/JXMX5OL+TFywz8gKzfLSBhhvPekaJvI80x8eWfD3SHZsNyiyMUuWy6QnVbsd4snvU
szxV5Oue7o70I2PgKS8bTWVDd2n6N7xmcockv8fezialAxnJ0BeslZPLoVlMv8M2yKnNfn0gX/dk
f7srrcrlRFeqR3LWJbyYkpNTT74e6E75JthCkEwBT+RUgpMNPdtRI/4MT+T8spPNIL+W5/JyrTuj
VkBPOTVBB8m8ShPa6GSzlV/Hr0iH8UzmotWctDT2CqynpTpgd3fZnZnxydaa7iOwPmQvS/2eB1s+
BnkcqJe1XNLzI0kfW2oFmvYQelLG3+CVs4JT2kNa+bU8Q5izgj3tIXQvfBOsbd4KGtpDevl1I2RT
wBPJAdL9ObR11bxl2nUQ2kO0/HoUPSTXOjpzGmlPbYIO0nINM0Unm0Z+raMe4mIY8ndmDYicNHV9
Q8tS6r3aBUp0XGtOZSnt682+KBetsVb/XS1L/X2HtnzMUapJW+hp/3ArG6FEXkmi2cvSeX+g1FKd
kzPVczN3egId/VMuxyG+3snawgne9J6Hdiu/2CXnKulcdIJeLeltM94V5ER3Qdr+T/Zq13T/ji0l
N66EVx3D3hDaE+j5BtdTD8HqK3L3yejHM5LxqwhuhTVhT6RSoa8E23cp0DLdO8Et2j3uwOlITpS9
KGw9sfUzfs9giHrOSGRF3y6O7xOkVtpxK7DStPevtIR/ktnZRTzRPt26WZnzHpYSPdk+cFzfj+0N
WAlKDS0n/biJfBylWpH6U2+rDoRqS+acMY6j6vsMWOY29CkrX7oaQj2/9LjpEaElcx96+w0t7WiL
DnlKNZVZLylRLXcka5l6MYe2/oxyEPV/JtH9rC+w5V0EIXP2VA6D8rEjfFgvxXoOGV1Zz9GUJ+v9
aA8eyVhKbdXu9GL0tnRvSNzD415rx5+YS2wd41NJzop8i1uXSvTOPl13E0vI2zDEvmRsOdLfndIe
zHiqI55INpliKu+VwdORDCj1ZTQr0xNrdPZH7R3vyRJ8JrVGVpbd1zW3UpnroVZ6Sq10SLd38HWC
V7Etpu9SHiF3kDjZqU5bZPfNxXzEGlI76sdX6HzL21X5147qeIwj8x1Wt91VR2Izp19clyIjHT2n
HGdDmVaaQA97MN1JybCIxdBdIWy34BalkY596cuMDreWpRUtVXmf2Z9FELLfR+aApWVq4v8PM7OD
eGzm412/k+XUE/fJ3cK+tGerbhZmY2lyq2DIwaTG0tAbQi663CZjO6vdqTlmkyQTy2wyOvkraw4S
Z3Vbzx/XHXtlNm9hdR/tiQ0lykfcLvcCcMSHlBa0LrrJo0j6JE7nnq6OR4F4rLUSoFkS/xM8HfGs
W7ILIdZ21UpM5w0TEqeZzLiGmvRE9lVN7Ynixv61IjeLu3c2adxSsTjTckPvmLF5cyEPzrHdL4u3
M3QkunFrUWSvXMClN50KzIr6J1kHxvHxd7sIE+PMBG5hi/y40LB1TrIrjOHOcEbn254n8p2ekcQ2
qkGLGoAnsu9nnb685060bohwqxkuB1GDbF01I5We1kB2eqRaN5eh0XS3uM317WWpP11oy0+DZCuy
/i3fb6tmXqdI7y9wGesh0KOr5wc/L8De5W/+sWf1aok1kLjK3UIcRVR1yo+TbGgJN4Pm9YRZPsXq
KTf2VcoZboI3JBInK5IJHxd7YvtVh5gwKyO4Q4zbBtvPaSWM5rEkOpJzqMksiuFUTHc2R3AaSYLu
nqBc1pybkFeJuWkbyU0XceNk6XGAp5ibKmAxbkiuRGol5A4TslaRBklEyDCxt/h7gFBHdM3Ozl72
flxDye0o34p6FTs32xKv4qLoQ+o7/pWfB9PvdoQDPc8B4msvdzIPpuVkTO+HMtpB4mqXq1st0oPW
0S+ybalIZon6WIzHqV4G0qcOJEaYk/WOjS3UShgNnaNBcyW4lm/nd1QGMWch4hK62SEmRKwWl5yX
Zrg0FozkHuoMlPTZDKWYP5XChNh3u9w6m52O67G5aMET8RJM8zazl32BCWPftWPcQM/22B2b7A4h
TdZ92BgXzVU01aP3LdDvDqXc9JQbm2/3IxxEGGSdiY1xM9zEPnHHspDxGKfj2Nx+t0thklGK4tIX
LgojDynxLmrjaTSqtNE4OGDGj0pin26Ru+U/o5Ug8baSNbXxGBeNg9qPcDDbINzEMjuNsvhM1r6l
Mn46ncGNNe927/oRP1hBnC05kNxnRfyn631bjhOykHRti+7uSlClEvV9mlgBwaK7eJivneNb0xm1
q2NA6+daq8nM3f591nKq0jI18T1uxtVLqprm8u0cgO2nG8lNU27XhW2RnWG0wQrSLY38E+0Jdo3y
TPI0jBIHX11JSxBzW9SiDxHV3lMNceYZ6f+0FaVeGXpLFMfvoli/PUicUWRPoAfHmWzbHzLW41dV
PG3gKeKgifx1TfZTJvoxuxWFcuP2jwvcVDS8TbyIutwfMHakdnvwvSF4OraCPBBtzlClXPpVt7g/
9BzLngx448HfHr7x4I0H1zfbm/PdZnd5cX2zub65erG72Zxvu+bJ/vz6ycX22eFa/POrrzfvbf76
xoO/buyRX0iRnWxUtfnbiYXWDjr9TweouYgTgripYPRQswEJKeiAOwYKjYeOnoCuA2obCATUffh+
8MA2fN974Gn4vPPA3n9eB6Zq/3mtAk2DMwJqS2qqLNT8IkwR3MDAnuDWTIYOtwt068pDm4ZLtrK4
ga4xTjCZ6Veg2xO6pL2EruZ6dHRbxgPSVUyPSDfo3DhZbFuorQu4bbCEjuC2zBIcbk/sYwj8Dsw+
LLt9YGwI3AbZ1IQqsVtCteO26KQwMg6QbsuMEaVAuG1Cy4guCW5gtya4xEYCu4GxXZBiqKsNMghs
NZ7XNtSkCFFiS4RqRetHqjWtHyUQ5HIaGhWIbn2bGuIPCCrpzgG3DlR7jzoEAl3gNAilDpwSJxPa
H4RyFpoflHIINBtaO9Lsae1Is6bGBh524lMYq4MS8VugaVJHGUXMljYJMRuqUsSsGU14y3OCBk5N
NKcHK9MxNFUzOLEAXhA43jJ4aF/H4IQbBg/t2VIw8QoUzN0YglUVah0pelB1y9BJ32Zw5h4CuKbi
DeCG6ieAWyr3AO4ouFE4Og7MRD24Z0YKC1oGPHIiDkzGWMCuHVhxbARrjt06cM2xEdxwbNcc1XJs
BLNW6m5wA3Cg3VKwoo0PYOoiYVTGdhJ98gLiwnlBEO+OwslIrVmBJhLmXxAZUzgZEbYM3nAL9vCW
mzDCRZQQ4B23VQ/vma0iuOeDrIeTYEEx+MhsG8EDs6gAZhYVwJHCMHLTUmFYUEmFYYESCnNwEi5p
XqClwrCgFgrDYHAUCkN4LxSG8EEoDKNCJRTm4CR0qRl+xRXmwGTg1AyuhMIQrrnCHJh4e03BDVcY
glupsMaJv5UKw4JaKgwLGqEwBydRiuYFrVQYFnRCYQ5Oopgtg1dCYQhXQmEOTgKPlsG1UBjCa64w
ByaRlmbwRigM4S1XmAPz0T2Ae64wBA9CYUPnxD8IhfmCTijMF/RcYQgnIZhmBSQ2Vbxg5ApDeCvH
dITXXGEe3nCFIZxMWloG55OOAO+YwhBMAz4G77nCPHxgCkPwwOJGDx4rpjAPZqFEDTN1A2a9N4BZ
7w1g1nsDuBVyt+OmJnGKpgWKxEFKlJDRixcQb8gLiDXw2iuhdYQroXWEa6F1hIeaRwYX3dfDpTUg
XFgDgoV2ESy068BKaBfBSmigd/BRagAL2kgDWKKlBrCglhrAgkZqAAtEKOLhYmTzcDGyIZz4+pHB
K6EBhCuhAYRrrgEEN1wDCG65BhDMI0oPJp3Xjkc2AtUkTmtZAfGUNS8IStsxSkSZvIDUzQsGbhYI
JyHElsHFLMfDxTQH4a1wiB4uuoCH8y6A4E6OYAiXIxjCxQjmwL0IORAsQg4Ey5BjUE5otVCYL1BC
Yb5Ac4UhnMwbNC+ohMJ8gezHDk5CiC3DH7nCPH7FFYbwTvYYxOepuwAfmcI8GTmCIVyOYAgXPs6B
ex5yeDAPOTw4CjlqJ/5OKgwLGqkwLGiFwhyczIU0L6ilwrCgEQpzcBJCbBlcC4UhvBYKc3AS87UM
Ll0cwoWLc2ASpGsGr4TCEK64whAsBiUHHsSghGAlFNa70YpMAlpeoIXCfEHNFYZwGqfwAiUU5gs0
V5iD15UM6hEug3qEy6DewZWchSG+nIUhvpiFObCW02ZEl9NmhItpM5JhaZsAHpjCPHgUCoO1IvO7
FwrzBa1QmC/ouMIQTuI7zQsaoTBfIIPLyglUBvUIl0E9wmVQ7+BKhnEIF7MwD+ezMARrMW32cDFt
9nA+bUZwzfMcHszzHB4s8xyDWzYaZdCBBYMMOnyBCDo8JRl0+AIZdPgCEXQ4eF2JoMPDZWoV4TK3
imtachaGcBl3I1zE3Q6sRdDh4SLo8HAedCC45kGHB/Ogw4NFlhL1SNKFFMzGx0Z1DjxwIgjm6wjK
VdlUHBvBimM3Dqw5NoJrju0cRtNwbATzjHNnQ+S6Z6s/AVzRxgdwNHq4djYyw+ALZIbBF4gMA8I7
mWHAglZmGHyByDAgvBfOyMOFM/Jw4YwQPsiAGuEyoEa4CKgdeBTxmYeL+MzDeXzmwI2YgyJYzEE9
OFKYM2MSvLasgESvNf+iEgpz8C4a7rEgGu6xQA73Dt7LGRDC5QwI4XIG5OCjCKgRPoiA2sN5QO3A
TSXiMw8X8ZmH8/gMwXwlJYBrrjAEN1JhtRN/FJ9hQRSfYYGMzxy8k8O9L5DDvS8Qwz3CBzEDQngv
ZkAeX8yAED6KgNrDRUDt4TygduCGRB+awWuhMITzHAOCFc8xeDDPMXiwzDEMrRN/FJ9hQRSfYYGM
zxy8i4Z7LIiGeyyQw72DD3IGhHA5A0K4nAE5OIkYWwZvuMI8vGUKc+CGRB+awTuuMA/vmcIQTOJv
TcFsHdSDNfeUnfOUZDxqKZgtpQdwJ7TeI3WZqPAFMlHhC0SiAuG1nPf6Ajnv9QVi3ovwViRdEU4G
7Y7BR651hBO/3TK4WCn3cL5SjmAyzmoG57seApyvrCOY2LKmYB7neLBUWOf2lGiZqPAFMlHhC0Si
AuE0sccLOqEwXyD2WSCceO4tg4ssuYeLLDnCid9uGbzmCvPwhikMwWSc1QzecoV5eMcUhuCBz3s9
mM97PVjOe3vtxB+t72NBtL6PBXJ938GbaH3fFZCoXfEv5Pq+g7ciqe7hcn0f4XJ938GJ324ZXK7v
I1ys7zvwIBMVDt7LRAXCRaLCgUc+7/Vgsb6P4Gje2zhpyvV9XyDX932BWN9HOE3s8QK5vu8LxPo+
wsmcYcvgchUE4XIVxMF7kVlCeCcySx6fZ5YQPMhEBcJlogLhIlHhwKOY9yJYzHsRzAblpnIdT8xH
Apz16gAmOQoKZmMygluxwcmDe067d2DFaSOY72TyYD4F9+CR024dWOxFRDDf94RgPr0KYMVpK0ek
5bQRzHdJIVjx6b0H00EAvLSrlLgzLUqIdEUJtWtaQD0aL6ELhaKEeDVRQvwaLyGD44EX0GCDFtB9
qbyAhhusgMQbDE7nBayATgxYAZkZUHgng31fIGMChIvtKgjvhf/xcOF/PFz4H4SPwv8gfBD+x+Nz
/+PAXSX8j4cL/+Ph3P8gWHH/48Hc/3hwKxXsLJ8mVnkJGfv3/JPIJlwBXSTiJXSfoCghgYQoCWo4
5dUElnteoIVNOng7SJvEgk7aJBb0wiYdnC4XsYJOhD0eLvJlCB/EaouHi9UWDxerLQgfRfLew0Xy
3sN58t6Bu0rkgj1c5II9nOeCEaz4eqYH8/VMDx6ETbaDM7BG2qQv0cImfUEtbBIL6OSRl9CtkKKk
kjbpS5SwSV9NI2zSF7TcJhFO5muaFZBoSfEvKm6TCCdTNsULRGTn4SIliPBB5HA9XORwPVzkcBE+
ihyuh4scrofzHK4Dd5XI4Xq4yOF6OM/hIljxHC6CRWbCg5W0ydoZWB/ZJJa00iaxoJM26QronJ+X
0N2eoqSObBJLGmmTWE0vbRILBmGTDt410iaxQEubxIJa2KSD9zID4AvE5lQPF1lPhA8iTe3hIk3t
4SJN7eBdJdLUiD+KNLWH8zQ1klEiTe3hIk3t4TxNjWDN09QezNPUHswzBTWaKvfBHsx9sAdzH+zB
bOqg3FJGR6KCLQGTkKCj2KwvBTDL8gUwy/IFcMc5cYELGQu2FKw5JwiuOScOTALvlmIPnBME80lM
64YrsWDowXxG4cE1J1I5MJ+WeDBfFvVgPg1sRgfmZ1E8mM/JPJg3p3Gab/nEzoP5ERUPZharzF3C
yoC5+ejGYfdMaR6b69Jj10yXHrvjYMRmovLYPLPlsQdugx674WDErplBeOyOgxGbrV0ocwjTYHcN
B9uUTUdc5ZZiVxzssFve0zw2N3tPmynNY/NchMemK0AUm3cSxKazG4qtORhpK24Q7thgX3GZOPsm
0fGWYJOJ3JZit9wgEHvgMkHsnhsEHiLlvgqx6cE0QpuuvVBs7sI8NvcnHrvnMumdTLjD066n0ZV0
iq05GLEVlwliNxyM2Nw9OuyeJ4oQuydBfkuxNQcjtuIyQeyGgxG75o1vXU8TbsaNDQMfjhCbrmET
bH72M9CuOBixR954i93zRBFi93R3G8EmsWdLsEmoWlPaFQcjtkieaYc9cHDtOCF7Oih2x8GIzXyV
x9Yic+iwebDgsWuRmENsFis1lVOx4nPHAOcjI4JJQL6j2OJwsAPz/WABrDltJ1m67EfBfERHMA8i
ArjhtBtHpOG0Ecw3DCFY7H/yYJHvrRwRoUwEC2U6cC20hmAaQpsYt3OVknFXixIiXVFCF69pAd22
wEtI3LTlJSTQ6sQ3xNJEPYHpAy+gs1Fa0NPpKCug81FWQCakFM6WetgHdK2HFZAuTeHR+o0vEBt/
PFzsi3fwgbjXLYOLTQYeLjYZIJy4jZbBxSYDD+ebDBBM/QmDi00GHs43GSC4Zm4pgPkmAwTT6N7q
0Vk+Te+JEnLXBy+IbMIV0OO6vISE9K0oITGSKAlqOOXV0Ks+WEEvbNLB2WoWK1DSJrFAC5t0cBLU
KF4g9jZ5uNgC4eADGfW2DN4Km0R4J2zSwWnSmMF7YZMIH7hNOjA9WU7hdLM3w6+4TTown/4FsOY2
ieBa2GTbOwMbpU36kl7YpC8YhE1iAd0hykvoBhtR0kqb9CWdsEksIFF6z+uvuE0inJ6k5QWNsElf
0HKbRDg928gLxPYtDxe7PBx8ICHXlsJJ4NYxuNiWg3CaNGZwsS3Hw/m2HATT3UMMLrbleDjfloNg
nk0IYL4tx4M7aZPaKVhHNokllbRJLFDSJl0B3djLS0jCoeUlJHFRi5JR2iRWo6VNYkEtbNLB6WFh
XtBLm8SCQdikdqYht/niB3R1nn0gNrIgnC06U7jYeeThYucRwmnSmMHFziMP5/lEBNMNUgwudh55
ON95hGCenApgvvPIg0WetYGZxiD2MLY2MzeMstsgunDxHl+mZRFfbFL1+Hyp1aGPLY9SHPbY8kyr
xxYLDogtBOCweerGY9O0kI0DnMBonC1K6N1MvITujKIFdLMZL6G74kQJsU5RQuxT1BOYPvACOvTT
goGO/ayADv6sQCxqIHyMFn+xIFr8xQK5+Gvho4oWf11BJRd/ES4Xfx1cy8VfhMvFX4TLxV8HJ6NI
y+By8RfhYvHXgRs6XFO4XPxFuFj8deCOL2p4MF/U6LSze7FPoXY2JGP5dnQ2TLqPKAns73mBNBUs
oFvjeQnp0q0oIRMhURLEccoKyKyw5wUjN1UHH6toTdh9MEZrwviFXBPGu8CiNWEskGvCCJdrwnh5
mFwTRrhcE0a4XBPGy8bkmjDC5ZowwsWaMF5+JteEES7XhBEu1oTxLjN+6sCD+akDD5YJhBZvbov2
zmAJCZn3/BO5dwYL6O5/XkLGk1aURHtnfIncO+OrkXtnfIHYO+PgYxWtCWNBtCaMBXJN2MHpmQ5e
INeEES7XhB1cD8ImES7XhBEu14QdvJFrwg5OlwUZXMQqDtzKNWGEy+AD4WJN2IE7nvPwYJ7zQHAf
+UnlDCzeO4Ml0d4ZLIj2zrgCuo+fl9DTCaIk3juDJdHeGawm2juDBXLvjHIW1kubxIJW2iQWdMIm
HZweW+EF4sSkh4vDPginC+YUTlfMGb44nYVwljegcHE6y8P56SwEs12YFC4DX4Tz01kI7nnOw4N5
zsOD+ZqOW8Qee75g68HM2XooPwiMl0zylW23iDTypZvG3fk78qvyancB1Ciu3/TghmM3DtxybAR3
HFw7MEu918jgqDm4d2DOiVv/GcXlUtpNBUYxm3eSGvlghaIaBSeO73HgYMf3OHKwleAUilccrhDO
r0XVFcJ5Q/HyyariLXXnoyc4T1w0Hs7bGuD85lV3MkxVfJWOwEW9eFsn3x1bK4/PtY1XbVb8HGLt
ToNPcCblAULaCcqk6a8w5aLHSz8rvgOtVih7zWXsLyDVQsYoey3sGmWmeVtHfzOrsGwP58cFtOeT
W1Tl72DlM9cGZVzzldPew3nQNWK7RFbfw/m5fV2jrhq2BOtNhHjOmoLZTg/PJD9qGMBc3x3aQcNl
0KNseFaj7j3vvF+NqNuW67z3cK7zHnXLt93UPbaq5ToP8Jbjo8xabgsBzvvV6OG8vR7ecdfqddsK
OSC8Uxwf5dly+Xh4x228xnbxSWRde/q8XZ2/2pfbeIfy7IR+Uf58s0jdejq8XR3qt+Or0g3Kp+cr
5AHOV4MbbG/Pl7EDnG8Ta9Dv8JGXwHl7vfXzPSa1t3N+wxSB8yB09PRFH0U436+hR+wX4kKkAOeH
Fny/ENfYBjgfnDtPR+jXw8U44fnk7Q1wtoOkcbd3K3ofNcBH5+HJeLmFI4oI53T8Swt0NKYVVDQy
4DWQQE+zKipRgHWQVFnH2jBw+IhwfjU6VkDvw+4IfXF9dqDPx69AX4moDOnzcTDQJ2PpyPjn70kE
/msGD/xrDvf8E9samQ7E0wFBB2RwUEwHjSjwemZb6kIbSHzSMhnxMSzIqOJw3wa2CY/Q5/fpB/p8
eAv0Gw73OmCbExuNdMhYDlaKdPj+4MZtClT0Tm6Au37MLvFmFdAghdVAFy80rYKEQbbA18G2woUq
SBzRsTaIfuPbIPoN0hfbazz9lvtkT1/spPX0W9FvkD6JGUamg473A89/y+Gef9FvPP81N/egg0H0
A6+Dnpt70EEnCrwO2JZBogMehfkaGtFvsIJG9BsvI7bJkNDnl/YH+nw6GeiLfuPpt9x+a4fPn8ho
6gbhvN/ULcJFv3FxAL2iXLEK6FYVVgPdkKJpFTQhrWkdfDt1qILEDh2tgW8hDRX0ot/4NnD/7unz
m80DfT7vDvQH0W+QPokFRqYD/n5M0IEYP7wORL/x/LfC3H0FlSjwOhiFuXsdDKLA66Dn9ut10HG4
1wHvN0EHot8g/Z5PdoIOKg739MX44emLfuPp883TNT4mweMuhfG5EmmREfuZ2JWPcbvi11PUI/LD
b0FQfnwaxHzK4/O5psfn1ybUo3+ugm+A9u0dWZyp6hbhYot/g3A+V26dH9I8D6J9/C+2lLrTZkpX
At4jHb465ucFfLdRXXk6PB6uPB2eJML7yit+O1/ttrgqetU3wFukIxJwfk7P9V41iC/0hfMRfnNf
7XYQK3Grd11phHM9uuP6Sou8T+X8veaHokm9YgkAkyH0Ju6RF1AvwUvEqmsoEBeHhAK6gYoV8B1r
Hi7vzAwFfG9agHO7C3B+o1KAc/saXTypxeGxgM/9DZqLOFTmXmJTWlyv2tg13ylCF3C36MuNIlDh
RhSoCLijIqCOCN+zjo6vEmBcumLsufMbit57DWe50DprNvslcNGrNfIiTnmh9ZPeaDbKtw3C+a7w
AOeRaOvbyrMSAZ+bGWZn6S3cDYPztH+AcytT6PX4LZgas8Ls0mhj95hGptdMDwzOtxQFOLczjRbS
sAYTfPF4lsKkIrsXXJTwFRxSwLdSKxzcNF80UZi0YFdZK0aKRBgjL+BXS5ACvpUjVC5OmfnK+Rsp
hFDLmfVwfgopwHkEEOrlx2VCvWSlHaabmPOhd+FrUSJWhEkJX36DAitzvqGefBGpHEv6SOW+RKrc
F0iVY/U0L8e/4KZOClquDw/vuD48XMjd1zxyPXl80bddpECvJG8YXPRtDxd9G0d+8V4RrpjQC8mt
vAd8r4vGiKKE39xFCvhNLFBga2dHohSubdBbnG0X86RIxDbyAn7CgRTw7eSh8pGL3Fc+MpF7QvSm
9IbB+ZnIAOfBK9Zb8+DP10sv9oYupms0Aho2ixK5WTWUiKsQcQ5BLyIXX8jXbLCEXkWuRIm4rC0U
iMt3sPpabpoLX4hreXyBuEE+wPlGiwDnpu5r5g/rEXy+ba7yL9bxfXABzoOoAOejGAbptbg7E4P6
Wr4Gg6uP9G78gcF5gwNc9G0XL9CbvjXDl30b15foHeBKlIi+HQpE3+4HrJ33bfcsiWJ38ytGqhXD
ZygQw2coEMOnr7zlw6evnD8RSgjx4TPAxa0FHs7deKiXD5+hXjl8+ie9atG3SYno26SE920ogOpr
3rfJF5E7x5JODp+hRAyfoUAMn776Tgyf4QsxfIYCPnwGOB8+A5zLPdQsfLnHl3JvsNfXMmwJJTJs
CSUibGnQtdQibAlfyLDFl0RhSygRcg8FQu6+ehm2hC+E3EMBl3uA86PioQYu34AfhYXofOguYpjy
+VcHG2nx4RvS28Q3si+Eb+g1cvwb0UvCJzLI9AVkozeSsgWkX/E6ZL/ytOiYrdk3QxSw+m9IK8U3
MpT1n5BMNP9Cxrj+Cxnj+gKSWGatp6u0vA4ZFXtSZBzhX4hw2X/AkrkEX4TRHl/cPePxRXjt8UV4
7eHiihjfZOHHPX2e8Gxd/2h4Yk3hlL0RVy+0LcLFpjnnrxpxnUKgz28uCfT5NR2BPr+tIdAntqdM
JKIwt0mvsnNFYDdQNERFvqL4K18XSejzqoiHG3lNfSVLsCIVfYP10EVVUU8tSkI9Wpb4eqJvfD00
2OD19KIk1EMPwPASfvpCdQoLWknMsxZV02FJVI0vkdXgq8j0hDdtDL2XbaAc0wvYBsbXIL9AidEj
dqwOGrqzOoguG1bHKL/AOqif5XXwezhJHVoU+DrkF74OfmyT1NEL6fo62PkGAm84XCG8FYQ8T7IG
VOwoavBwUQPqmx65M7tdifWOoiTYKB3djd90p3sUvZPZlaCn6gZJDZtSR/Ugz3VUz4DmG9Uzov1S
22LtGZQo8e2hO4d5e+hOaN6evpLUsD1NVA+2p4nqwfboqB5sD3sQjbenFiWhPfSaCd6eWpb49mhJ
zbcnqse3J6rHtyeqx7eH9hnenl6UhPYQm+YF7BKW4CtJOLHj7e9FgW8+CSh4Ab9SqcMRll3Mz+UV
tcPLS7bDF4h29AiX7fDyle0YsUC2wxfwduBWU/rSQkPV0bEuRoRO72/VVLj0fktNZUgvnmyoqNqo
jg4LZB3Y8FHWgXZFz3uydrCuRdtBN7KxdtAdPKwd9O481o6oDmxHVIdrB712XdF20IvXFW9HzQtC
O/gVYaEZ/Oa50AotCPlWyBp8K0QNvhGiBt8Gdu8SaULPzdy3gEfzAc5XWvyoSGy2Yy3mN4CFFvNs
TYDzbBD2bXqZ+Y4JSPDv5SP493DBf49wwb+Xp+AfPWMl+Pdwkc2qUP60T2uiAXpnuRs3vSulPU4R
qdKXK1yJ943R+Ox9YFSPd3VRPd6nRfX4MYP2bdaeMRo3sT10UZe3Z5Czad+eOA7A9rRRPdieNqoH
21NH9WB76Cq0aE80bvr2iAl9aE4tCnxrotHZtyaqxbdG1uIbI2vxbSF9nTdFDlG+JXKI8gViqMXR
nISoHW96Lwp800mH4QV8Hu1H8yhg8KKSrfCSkq3wBaIVOJa3shVetLIVOGTXshW+gLfCj+U0d0l1
0Wk5anoPS2fwRLTsOnIqQXapPpVUG9XhvaCsw7s7WYcfP8gXrB21HDWxHaRHjbQZJFc90lZ0clzG
VkQ1YCtkDdgIJWrANtCbh1gTxJjpW8Cv1wwt4Le2hhaIMdk3QND3/Av6nn9B3/PPr5wN/IsxyvMv
xigPF2MsjuHiOujQXn53Zmgvz5gFOF819WO4uDU2yEfw7+Uj+PdwwT+O4ZJ/L0/BP7pDJfj3cM6/
H8PpKXitiAbaMRonvQONxlbvxqJvMIdBj3CxetjDJKweequ64vV00TdYD73ZhlcjRxZfixyLfCXy
C18HsVleh3Sxvg7pYn2BGCjQbCvpxT1TsgocDzpZhS8QVWBGphNJ8tD1pL/0fUx6WG/s8gsnKfpU
0EiraIQ3wxoa4f2wAomP9MXN64G+8DaevvBOnr7A9/RFftvTF73P0xe9z8OF90A1N6J3e34EffQS
kr6HC/o98i8idO1eu1L0NnctSuilBayEPhuMBdYOmBPXVYdwcf4Qj7OTKJdXwAdkUsAOxgU46e0d
ZUhcFuQZEgdGUU6VEqtlpGYSw4oScmiDF/C+S8TEtErExLd7u23sIw2sWQXEMY0MzrbzEzjfphuk
JHaMeCmJY6xeSmIDiEL6fN+th/PjqhqP53f8WKpWbqyjl5BrRl9sCuyQDtlNAfdx4MZuekF5I0rk
A2KhRF7Y5e6lVvQicFtQ4yfkKq+GfSLWJLS7iVnR+8A1/2Tkaw/hE7pgKz4RF9OFT8Q9TOELcXtO
VWOBuBoS99rTRwt4FURZmtdBhN+wT4iXEp/Q3RDsE3FBVPiC7pJgX4hresIX4m6V0HSWbiEt57c7
hRpIt1HMhEjINNKCXr4PEwrExSvIbS9vUkZue3EXhnsKeSQWbw3O19AIs/IF4hKXUCBuUw488c2g
gSUmwLrz12r0whCQkOJzOC9aeke9Zl+IBGf4QlXCDvwX7Awp+UBxbXt8fgeqb5wWY1uDbeBnzQOc
4RNhDKLNvmLSKxTjtBFt9l+wo5nkg5Y32eOzY2EEv+NN8/j8mH4QhRi/fJO5/w9whk9EMYoWo+WR
uf1I4XXFG+DhijOEDeAnJLy/pvf3w/aPAeFiq72H8/NZAc7DMDzf0vPzR2ocEc7PPbnzoOMg+lOF
5Pkbvh5O1/UYnI+neFyJXgMOcIVwcQ2GcuzwC8jwJhZ6A3nD4PzGlQDnp8IqlIK4o1V5NoV0bLNG
8b4lXmDT8weHApy/OETgItpAI+GXnGiFVs4PXNd6dOzwq5Y1diJxt1WAc+kEOJeOxs4iLnB11zMp
em831OubxcXg4fwOFQLnYtAoBnGBJt7L0/O7UiBWsXB+ti/A+RlBT4bvE3CXeSl64XzD4PzJpwDn
MWCLtsxjSYWHpHr+OrNyl1QrerNzw+DidjEP5zMrPELZi52KeOSy5zsbdY3896y9BM59bYDzXdt4
tLwXV5ng0fKeX4mi8Aohdh0/JJDxEiF2tb8oIW0WJSJ/3Xu2eLqr92yRrASjRFcgeIF4kc3DeaLN
1yyeP+rRrvkZWnLmluDb7YS+cTJFFUrI9JMVEB/VKcYVTxx4edAtlpwSz5QEOH85CuH01u+aVDyI
Ux8ojoFfrUaOGnO3g0eoB350WI0twnl/cPfCqUHsKMQrgujrC2D3DcL5Pd4BLvjxcDEHRD4Vd3eo
5kGJfuLhvP8PHs77f4CL0zIeznfsDxrhIjSoEM75H9ygSG/214wO39HZIJxf36bHHumI0z6eDj9N
hFc6DTzcJXCehw5wod8G6xV8onw09/t4ppc+4dIwuNjhjXDx+GPjchSDuAauQTmIl5u0P4LPghuY
4Fv6XA4BzuUQ4FwOQ4X1ipMB2B95qNjgsK4rPj65mx4VfZumYXBxwgDh/Bo7gMPvRtgD6qsR8mmQ
HxHeYP/lD00SOD/cE+D8ikU9YL3ijC36jabj9aLexdXKAS7O5CKcX3sDcNtfeRiDVwvQe+bNoWg0
c3qwhsH5q2IeTHbsU7C4Xw3B/EogD+bnthHcMQ8fsMlkzgRaaJgkXtszOJkjOTgIpufZRQw86K3T
PcOvOB3Ep0dfRlovWZ9mcH5PUKDPtuAHdkjukqE3nIzHJ+RbWi25PYHByfPKhPzAZpyBOvHiFJ1E
cXuKHqzplNZJxjgGJy8qU17YAo4nTuK3M4qtGRGPTdIhpuNgf6VXq/ACEm85uB24eETnOzKJzw4M
v+F0PD5ZcmH1ElEyOEkmEPpjJTJDnj65FYPxM3A6Hp8EJFtSLw3xKJwe0dhSflj8iuTpteU1Q+c3
9QV84qc7yg4JLBk84B8oeXbbWKBO3BxD7xgVj07uD1KhUvpkxZ7C6X1yipCnWTxF6NMbTCg+CV5q
hk90NVJ+SO6NwfkdfYEfdpeZJ0+vI2HompPx+PSiflot6bgMHujvKXn2ymegTnTF0DtGxaOT9yJo
naSfM3hA7wnxms1fPHESXZ1R7IoR8ayM3Gw6pNJws/HwmqvbjeHspRADd2M4vc28Z/ia0/H4ipuN
r7fjZuPh/CqvQJ/N1QL5npuNR+cXQQb8lpuNr3bgZuPhPVM4kicRTkuo07QXQ68YFc/MyMwG66Th
JYWTcLSnxNnFd4GXlpmNx24YEY9N9l0YD90gnAybvIAkHxwc6Hci5e5ib/rixoHhd5yOxyfuj9ZL
ny9j/BD3R+nTkIvSpyEXw+d3sgZ+SMi1pfwQ98fg/FrAQJ8cqqfskJCLofPLNAM+Cbk6Wi1xfwxO
3lgl5PkDyoE6GWcpOgm5DhSdnMxUpNKBh8cBzsNjT37k4bGnP/LwOODz8NjjDzw8DvXy8DjAeXgc
6LPwOLDDw+OAzsPjgM/D41AtD48DnIXHjrymF/i3lDoPjwM3LDwO6Cw8DnXy8DjAWXgceGHhsSOu
6dsAZxSbhccBW3Gz0Q6drjxVFm7xO25OiE+GvD3D53f+enziX+uKwOlwDfkr5Ec8HFk7+nQYZ/zT
R6IofX7VcKAvHj/19Gtuxp6+eJ3Gt3fg5u3xyW2gDL/n9urlIx4J83JmG8U8+yQiGCj3xCEz6iRQ
oNTpgiYjLy7O8/QJ9y1tLU2kk9bSF9oZPgmAKD6Jp/eUfZZ9CLLh24A882IFwtGmp3EYcWKBjLpm
vHjq7CxLoE5e5aEN5SOPlwtxugydREoMnzhjgi62o3nO2WF7zzk9c0E5D+I6o7SD6g6Udsc48VJh
GZ9Amy8SKQduhbF7uFipRFb40pHH5qv0Hpsn4j02z9e5q1i1fELBw+mOdpMJwyZ13HQDnG23COCG
WVeA8zsPPZhfKu/B4u54BItrZxHMM2cKm9TzWayHd3wW6+4j1Oz1AQAgHT6L9fi9mMV6fD6LDfzw
WWyA81ls4IfPYpH8wGexAV3MYj0+n8WGavksNsDZLDaQ57NYT53PYgM6n8V6dDaLDXXyWWyAs1ms
J85X4Tzxkc1iAzafxXpWxCNGSES8udEjnN9THeBiAcUzww4ENBiQ8IeWAphfZjp46iwt7lbBteIP
LQWwWAysEU6mkqagRzifsAc4n7C7jZyavgMAq5yDw1d8wh7w+YQ94PMJe6iXT9gDnE/YA32+uOrJ
8wl7QOcT9oDPJ+yhWj5hD3A2YffkNZuwe+qaT9gDOpuwB2bYhN3XqfiEPfDCJuyBOJuwB17YhD1g
swl7wKYTdhOqt1jAZuyshE7ZXQFUEd1Y1bkvajppZ190gpT/gk7baeU1nbczrujEndZBV9NYHQ2d
urMvKkHKc0Un74wrOntnBXT6zuoQl+J5pugEnn3QCEr+CzqFZ3XTOTwrIJN4WgWJjzpWA53GM54G
Tsh/wCfyHp/ecU8ZavkEP+CTGSzD5xN/j09nwpTPjicEVIf4xClQ/jueKAj06XOUlD5PIAT6NecH
6bc8sRDaSzrQQNvLEw4Bn/REhs8TER5fPHoe+OdXaHn2+bq7lw7PWwTpEFfKqPN8RiAv76dB+jzP
EejLaw+wtTz/EaRDPALDZ3mRIBx+wYanwo8pIfN0Mz7lnWdRAnFigZR6x7IrgTqLvAN1lnQJguHn
PH07eS4moPOUYsBnOZrAOluGCnIRR9MQm2/pQs57ltEJtNmaVaDNEj2BtjivibTZdgB3VammuzQU
gSv+sKW78VRrcVGCp8JvT/PYfCuSx+bBmds+q2u+cVS57bO65jM4pRTC+c4lt+9V13w2qdy+V13z
nRIK2az5/lmFAq75jguFEqbXG5qu7e7bF2tnDYaiTDK+rfzBndBWcS7Ot5U/uBPaKs7X+bY23PB8
W/krj6Gt4hxgaCtJZ7m2GlbpbZGmWcg+PfxrWKyQf7oLqWEFbEu/vVwN4DwidxULZ4X10vc1dpQ8
e5DDOAl3abCmL36YToUZF/rix47UQK8D25IKGnbRBCvg/dDdSqwb8VSKb4LYJ+dboEYO7xDO9xG7
W5I1fZFDsQpI0N/wGgSnvgZ+AUOogZ+M98qnS2lc+fzQCyngt0wG5ZOkrvI9TCyW445B/kQgaS9/
6Iy0V7j2YBN8CuFtQlVcEK4GesVQx1Q/chvycN65g0nwUxWevthqiXRa/tqucqdCtDwC74616Ja/
5qvc8RXd8ou8lTs2qVslHHSHcO4Q0SBa/roekQ93cp7/SsgB+a+4k/P8V9zJef7F2XLPvxiOPP/i
Ms/APxsb3c0Emt4ja8BonPyq3h49Ln9ytEeH2zPZ9+hX+YvcPVbJXy/ofZXMEHocRHo2iXW9hG9V
wGGIDOe0iXTBlrWRvWnm20jXj0kb+fHb0Ea2v8+3sWPW4tvIc5q+jfQI72kYgEgPaEh76NkQTdpD
ojYz/AQ4O3bd+5Gf5zuwUp4BxkrpY0A7Qpw9+jMEcdHXiaahx2241vQNol2gTm8+2wbi9HoM1VA4
S8i7h4F1y0cLzzq/rMNzTgblJqhf81NkPcZz9DAaI07CP0adxe2BesXASF0zFQVN87ODXqNkXqSp
pukLMUTTdNK7D7Ecy9liH+JrNEH9fL9dUH/PzCWon6Vyg/pZ3wrqZ4OwVzOxrR0Fs3DTa5/vnfe0
+dZqT4Q/KO4uWNEtP/vXo5Pn+8J79PF8W3iPLp7vLkfdt/w9NdQ9vYOnJnzzvVuBb9b4wDd3Q8i3
5m4I+eZraJ5vfjLU882zi55vomKTohjR2uiB6wl3RE9Jj6APFM7d1uhHJs3xPbzj+Gj8ZDIL+B4u
+HSrDfRC8o7wzx6qooyyl6ooR+zJK1o1fSML8iDKF1SiYET/MPICjYFeLVIquPTH3vkizaDXaCqi
hpZd0Erh3NeOvv/wvQEBzo/uY5vpJS96oHB+OTGqgV160hAzoisq1IzIlKOhZsQu9yPmQu8xoGbE
nsMh5kLTOcyMRs4nmhFdnSL8sxfBCP/0CbGO8EkfHesaakOk3h2zoUEUoA01YjrobUhsBgg2xJf9
vQm1bJroLaUVmvRwNuR5QxHr4QHOhkJvJzSxweyHzTe8+bQs44Ws0yvwTXohWAm/swDh9Gp8wPdW
wjcfIpxemQ/43np6jj8gPrvHALlnN+kT9ukbcJ2mxjNyuDeegcPRRkhIeKC20/JsmzedViQM0HKI
Dg/UcPgzwt5w+BU2wUBYlOPB/NK6YB8Dw0Zwx9bdgtn0DBvBHYvxvdV0LJXrrYbMFUdiHHSqyIyG
PSrsbUPxFEGwGZZbD6YxcnQPZ8/9BpNheeJgMXyzk7cYOrUgTNIn/RThhj4B2FOL6fiiobcYorye
WkzHE7feYjoWv3iL6Vm0402DT9GCxbBAxZsGf4w6WAyLX4JpsElEALN5XrAYviDjbiDU9MZ1mHTV
aAT8ZYQA55dYuxsINX1iAfA9nEdTnTdVHk0FeM/5dKlx+rhDR/jX7L4kwqhmV5YTjnQv4iOsmj5v
aEIUd3hS04cSAe6r5tHR4GvmwdGAk6ROzO8xbBWrQdiCtueBX4DzkRwbRh/T0AOF80iq8zbLI6kA
5xEZqoA949FQE+KXkXtTIeF4Q01Ii9kfmgq9WJqaEJkYaWpCmkdSAc4T396EyCytJvzT1x87wr8m
AX9H+NQDj4y8/dDVqB2xH6rfHbUfHhkF++GBkbcfep0/NR+2/9JbiViTDHA+KUUjoSfwqPEMPOGB
NjLwGCrAWQzlTYeIeEssh84/FbEQMkmEDJGH88sivYXUIqPk4TyKChbCoygP59fJesOhp7wJ+/R1
yY6wSd+j7Ag79AXLTlPDCewcqN2wswXebAYWE3mrGVhI5I1mYOsG3mjoQ6HEOEYW5gUwG8q9bYw8
6+XBLHoKpsFzRAgeWQjmLWZkYZK3GDLbGolhNCK75Q2GXeXk7YJtpKH2wnZoebNoePwUzIWtjHhz
IZPjfWCdvpyqRmotI4d7a+ERkbcWEqL3xFqIRntiLSNPZPlKWTjkrWXkuRxHRNwPi5zTy2w7ai0s
aYPtoTfcdtRaWC4HW0nv4+2otbDICUXe8XsMBgxw6TM8ExgDWRJ+afMyO4JZntXdjaHpDbUmvMW1
Rv42tXs6WtPreg0Y7ZbvKHYPG2t2gzBjnK/4e8752X3POZ0+Ec75CxGe85YlMT3nLfMUnnN+w7vn
vOVLqp7zhk84PefsDlgK5/OeBvsQiXkJefps8I6Qoc8Gm5hrxMWQiqXxFW5ErPmjHUievu61DdTp
PciqoXAu4AatkRsS8s6fzPWs8ztcUO70od4myJ2+06sYcZ7HD9R5UsNT58kLpF4xH+2V2nJ/GcyR
56yCUtl1QV6pLc8WBKXy5HxQKk/OB6WKOZ5XKjNsr1R+F6JXHpdM0CnzXl6nfFnV09Ys3+6J8Pto
sJ/Sp19U6Kcdv9UG+yl9EEaFfsqexgka7fjyAWq044sNgW+Wbw8yYY33fCvmoz3f/GZFz7fi81Xk
W/GJKfKt2Nji+ebvUbc4oJOwwIBx4KbJ0wmMAzTNkU5gNOeBLQ63aLUDW35r0bkObLRo0bkOfFWu
cjYuAmPP+MCziJ7zgY2hnvOB2WzgnI2KgXOWOPCc92y08Jz3bLTwnPc8ge45p/cha8J5xzMBHt7z
GFIheWJxhDx953tHyNAHw41H73ADi+Lhb4V+kc2CkDp9aGIbiNMnQhSplD650QXe6YMbmrBes0Hd
c06INEHs9I3rJoidvhCuKHF6RRWlzp9l8tQ1y3UH6mznVtBpxyv1uuM3IAc4S3EGnfKz2IF30qcZ
72JxHnVKnFRPdMovvQ06ZW4+6I4tAgQwD2m9Splz9bT59kNPhO8+xF7a8c2H2EvZ3fWhl3b85lHs
pR2/kwoVKi7xR4WKu/o933wroeeb7yT0fPONhIFvNlYEvtlY4fmu2Vjh+a55PI988xVoHFXFmcIR
43m+a7R2L8jrju8yrXtPhznj2t2DqTv+Qn2A8+tJa3fPpu749acBLm7sbz2f/FSWh/NrS+u2RXjN
4cg/n0zULY6C4jrTAO85vkY4vzM/wMWBLYTze0LrAXsH9e0U3nM5BDhvV4B3nD5aQ19x+h6uOX0P
5/YQ4EK/WC8ZbU29rcdn97kF+CDswcOFHj2cy61B++y53Dx84HJrsLOQ0R82X9duD5NoV6DDnQJC
+e4OhPI7LEe0QX6SsPE2O1a8Tg8Xx/QQLDZqI5hZQoPbMzt+ILH2cTU/kFj7+I9fnNr4HjQKyXg4
357pq+Vb5J3+enEiEaHiVkKFcM3hngrfsolQ1lKPa9v5t4dvPHhjf352tnlwtTno7XDW6Pqwn/r/
9O+x3+3a7djs1Gm9ubm8fHr92/3h9MU33xyufvvycHF+8/y359uuebC9fnazPX3n2zcePHiw2f62
APNXn15ebB4fnk8S2Kj+Xd2+O8ULcNL97UpV1Rtvv/32ZqLw3W8vXjx9+qsvv32x+X+3F5tJHlX1
LvzP3gPzdjX998a//uvmgToxR6berk6qzb/+6xsPfvvWhtW3mRj7t8N2f7janF1ebXaXz55vdzeH
/ebR+w+mtl4+313uD5sJ9enh+p03Hmw2mw8un/9wdf7NtzdwgceJvd3j46vDYfP48uzm++3VYfPx
5YuL/fbm/PLiZPPoYoffXdxcnZ++MMRPf9j8/vJ08+n24npq7uXZ5oMfvrl4cb15/OL588urm82/
PIOSf90B+J2Jq99N2jBUvvz2/Hpzdv70sJl+P99OuNPXf/jw9yebP7z/+GSzvdhvbr49bP7w2Z82
p+cXL27Onxq24dM81sYwfmaace2a8XDzw+WLzW4S79Vhf37tmAdS08fPDJXfTiJ7djlZyQ8WNDV7
EqQhfXO4enZteMN6/nC4OFxtn24+f3H69HwHVD453x0urg+b7dQSA73+1orGfDIn0Iebw/lUfrX5
7nB1Pf0bCE19aGLk3vbGcHw1Kc1g3p8Y/GHzdHsTkFdIIjR4vzm/AJxvL59P7fp2qmX61w9A6Pvz
p083p4fNi+vD2YunJ5sJf/PnR1/+2x//9OXm/c/+Y/Pn97/44v3PvvyPhxPmzbeXU+nhu4Oldv7s
+dPzw96S2V5dbS9ufjDy+vSjLz74t+mb93//6JNHX/6HadjHj7787KPHjzcf//GLzfubz9//4stH
H/zpk/e/2Hz+py8+/+Pjj97ZTD3GKyYhbS/pM9CXad7hZktM4z8mRV9P/D3db77dfneYFL47nH83
NX079YjnP8zrESkDle3Ty4tvoKUTtjPTh5vrwwE+BqP94I+f/8ejz/4wcfzobHNxeXOy+f7q/GZC
uDQ4QGW+K02x7ceTnP7ydFLI45sJ7WbzYPPx+dlU38dPLy+vTqZOdX1jMD99H0hV5nzvA1WbreJ/
evz+VOtbvzUt/l/nZ5Ohnk19vGuevP/400nYT/5tAk+w84uDBBv8i93TF5MfeNP4jne+fdMAJ0/y
5dSs51fnz7ZXPzBPYfrms8mnbF48R9GdXT59evn9+cU37wIPk3G92N2AK3rybHt+8QS+m3yx4dtR
Pkz+4gc0PmONk3AteTDC3eXV1eH6+eXF/tqJb3OxfXawFZ5fgwA2jq13oNLN1D+vz7+5mPQ6KXty
HQb/yfkkipcPrSG4mm9+eA507McPU1V9+R+ffzSp9PAUuoerjLZqpuLdt9srR/eJqYZXfPHi2enU
XU3VL26ev7i5BosFY8rRmz574j7g9E63k9GfX1xfbL7bPn1xiKltHt1MmvrB9GHwY+fWA5lh4Olh
8hzXWCG0CSg5obB6nm2v/2K4nmo5nwicT4xPUvnj5x/88cOpd/5/D1eXBrA/303eaCIwdaDJ74D0
EhUYYpy8++IadWuaBKI2Ps2MLJF6/vj5R5Pj+fCxrcSpZ2KpXEO2xq/arzkrZ0+33xCtLDLy8Sfv
/+GxN5RFO7F2CZUIkzReYWp+0EySiYcOMjlxM66eXU8+4vzi5tJV7L+2/Y3XGkg/dOGP6eMfbXff
0homBzkR3xjCEzvPL6+vz02XfDN8/SaMRtv9/tzgb59C3dcvzs7OXx6uXd+duNs+vXFjJaH+m+vJ
FCcXfG68mTGS7789n+qf6gQqzy9vJq9wvn369IeNic0OV9M/J2f+/DB14ovd+cF7dCMzzxK4kqkQ
x+rd4Wpy/xfeUAUT2DuA0J+BAcA0/nhSK+0rBjS5v7+Egfv3j758bBzw4/9t+AcSf/z448cffent
PcHbD9AJt0+vL82gcGAtcnq2gwNaS2jl9YHahOEHBtNv7Li93Xz4/h8eAmPPLydDQBxwegcrVGMf
gCGsAwj9EPE7ETT2dX3YXu1swAJUppFj/yRg3bsP6gMTh6Jn25vdt5MLdwY/IaCqPjMtBrM4GFsL
NC4OB9uRJolvn0O4ANp6cTUNcdeX9pvzs833VjYwcgtVQsGvds+ev/P05p0XFzsfJMS2YcR8ejmN
pW8+vXkTmH9z+uDNzfcQFhheOCuWlJWcbdNkvOBmsWGPL58xZq43e9DvFF783xfnRlMX1NWCmkCd
F2CdW8v94dnzmx+kvRjPTQmDKDxZgr23Xd/UGug6mpYSmtIUsJ5PvZVa070pZuP2BfWAl38aeEJO
SVPvi55hurQZvs3I+dEXnz767P1Pnnzwx08//+Sj6Z/g74xH8Xb9xwvTwWknmKJjEoreRMyC+rbY
dU3tQGhq8/X5FJNb5RnN/WB1NjXDoRqutxc75wx5aCJ6BI9PJp/ghlUXFE+9IvAzNec6Glumrgau
JPj2900nubmGQe+djbK9E7wNEE24HCcCP6aRAShRWzyY3klY5du5IrJ63/n8iymc/Y5YFQwXD5Tp
yTh43QCfewwepyH5/IIPVoQSqQGdHHJufBUfNP3wQ4cSG5y6ptn46OLg2OLVXr84df5CBFrnN2G4
jcaT76cJmx0ZwK/A4OCmG6cHV63zKjPhiCX97qZ31fJi7A7E/767UYHDR0YRwc/7jvUDdCunfdpM
2vVoMPCltXHwI9d2TJ9QLkyjp/73DOYpOF6ZKeT2+vrwbCIOCpnM6vLpd4fIBRP7mn5dnX8DPZtH
VnLOMNF+Yj673oQ+6f3Jk0efffjRv0/1PZ+qnLiz9pSIoMAYnm3/YiYqXvsHUbVR7yePfx+Ru/Rz
G6BMR+lJjM8PO+yuhJhzb5vJUiuwGQyKoa99c+l73OFlMHE6WH13viW10O4E0cXDyfcrSdjN2De7
F1cQLnlq6EJCIkW03uUHgLP95ffOZfguYKOIdxyZPx82f7m4/H4ajX8DM+gtRAd25std9dQdpj4x
4by4MPMcU7FyRIzne8dL6UvoNyaYffr99ofp183m6WE7WezUPW07kz4veG1gcOoLuuLd9dx1CGAv
zD+/+trGPN6Ec97V9hQzY/HVKNrnzswQcBLUSfyu8XA4T95eEEXbcPr86fnND04EqSB/IjWNXJPf
fgfDUyOPSU0vroHk/mAdQgjOIru2U1yj3UvIJp1tdzeXZsQ32Qo3Pf3ucGWC5Xv377sOKMRsWvUE
hm7mbL5kXf8HkyCYOvXND37yZgWxfWaSJTQ6mpEwfu/90P+aXNP52a1zsxOP7+yWE7OA9gqysmYH
T5SVhcpMSvbD4DuhhAkqTsOalT6fjD2x1xavT8l+OAVp0+h0eX16uJrE8ODLaRqx+Ze9gT7712+f
P33n2+evU7GvU7GvU7F3mop1qdV/Mf396uadb39HgTY+ByBNw04mYVZwIBObTM5iKvezjz756NPH
97b3f3Xv3uSz708O/vy/D5MMJ9Dmtxv/j6+qr+/fv++ivJzz8YxPeF8czFQ8PbQY9dr83/Tniwuw
3BeTV9386bNHX4ap1iTO3TQgvHgW8n+QFn3jgUF+cnMJ/9rck+nHE/IRkDU/7rtYMEFv43KtkO2Y
aLjhaorh3rPp7j9+vrlnSd93ZdN0ZIJsfvfeZtj88z9v7kE17zl004onjzb/8z+bGPypEaQZc//q
xl4rEYdiEsdP3n9oi/4G7D51Rhs+uJ4sdxrW77lW/Woq+NXO5HJJ5e9OsATpRw83p1PwZSZ98pNP
Zz75dP6T38988vv5Tz6e+eTj8MnG/Se+/OTdmNq/z1D7d8LAZOvbF09vGOYDE5H86m9EzFfOWq0h
/M0oebKFNx5M8cXFjbUUMPZ7p2f7J989226eHZ5t9/upK7uJB5nPPDHznc1b5icaXbDQm2kEvpm6
+fXTy5uv6q+nfxwmBzs5/wn0ZIpZTyBo9MZo0CaDPdn8l6lpe/Pi+gSyTWYy92x7Yvj+bvvUknvy
bGrnufHWV/C9SW/ciHSyTa6/NVny9W4WCTIfb50LHJhMvnW4mtr81oQ//bwxkyzA+P3HHz75tz8+
/vLJn55MFKa5rM19QJmR2OkPk+88nXr6FEar7uuHvCP6PmprM/VcHb4xxB0y9jgj0ge/M8Sun0xN
efLUeLGpe1WuT6XLN50Tpymc9DSJ+4cnJkycIob3HNj+01UlhOmROOGHzm6mlk4YsQKQkmnme5t7
9+6ZUec+Gs79zT9vqpdn4GcTujOtxY9/t9Gufc5KH2BA7WhtHkz08W9LFohYgzGVv2UbMPWJ/ZMJ
8fLqhydnLy529/1nJ047J97r23/fP4G23w9MWZr/FITu/RLW4iqYLOXyCqtB2/XVBaqyYb5PToOI
ZcJlru00bxoqphnQzdPDA6dCsK3LKxPQ2SnCTTU12VjdN4ebp9BnbVOA9o1KFm7e3gxOaKYXTjgT
lX/eWH6wixpJTuDf/W6jnPoeopKnITKUblpbrM78f598ElAVoDrcprO4tcG6v/kfU6AA0p9Z0L/8
y0Yhb+ZzbWtS5mtdp2sCriFz8p7tYtCEJ6ZHf4Wt+fod332ptZHuhAo9Ay94hrq0wMkFHLaTY3rz
q19ff71588TWZ/kMg1YZCWsEb+LgakfNDOOHl4cdeI2vHNfUSQRtvbfRZnAmLVPSZicbu/7L+fPN
J4BljOvTTx55hb/rLApGXd+VNTVb0/vfTnV/Z8bW81xfOBeRYjgOEj579Ilj9JvLKeLcH+yM/snZ
FAsf9vipEQqKyaS8cO3EVHeyESGSh90PfdlReG/z2Z8+KahwkhVocfp5sPmjE0Nmmr2860I2S9bS
nXQOq6H/jCGUCfeefPbHJ59/8dGH91GCU4wEvLk+cH+9+RHbWW94957/utL7+8Z8IQJmvNwP7Tap
KxPJbnc3L3j6MTS9rMZfmxVQJ6DQYbw2HvzOLy5PQfcqOfjuE+KDyToqoG8C7nv/Bf/c/NfmX1zk
H9V533QXycd/ff1w8/bb/yV7zqUzv8PTMxPbkPDienKmCSI+cQetDUyaELasiSe+iUjFMvEgycR7
Pnj/7MMnjz799E9dg9Gy7fcmC2tSjyamnEa8aTCA3OizZ5N1G//x9HK7t+qdPrBrOcZvg4mYMcD5
3t65bV+ge++UwXv394HCRmBpxLIuvpNU3BijoFgrQgRHEQPX4rO6o5919X0S6dr+cYTgtO+vxACc
++z0Ay42Y2sXl8/feflbiMHfeUmcqPkvSBLbEY1gockb8l+mnbpK4CKqw7TDKZlg3EIqX/7hS2FN
XZUQA+QZTqfvd98eXAaTmVJkS5bHCetX6fba1rYjQ0ExGqO5T0IHKsvqPvxuImvwbZjCNYgUL23P
Pby8uZq83X0nFDstOdn8MzAPRmV74PQZWuZf3e9VrtB8/9B/aEefSwiuf+V09CsYRX+Fs17H3+7p
NN2yNdt6w9QQNPTBJ+8/fvzkg8dfvusoreDJVTEBPWs4nZyv6ouP/oBVeVMCGhAavrf5zfY3xrsS
uLLwq9/c9+03TfEttaK2mv6r/QU1V+/a38r91u53/S5Bahywdb8797t3SGYVCgSxuefmWlPrt1fv
/OXXL8xgSHP59zdB6UwYvjLVvfurqUW75z8IalfXu8lnJz7oZz44vX6e/mCY/+D65vLqkP5qnOPr
YnuT/KLWM1/sdt+lP5hr+ou5Kppq5ouz59dX6S+amS8mO0l+0M198PzsOv1BO/PB05kK5lp9iPBJ
/mXe7FYanfEKhTEDdGhXFXE0f3N/cdfP+uvu7vprQla7q3f2u7S61Qz++c2zJH7SZA3+d9skfrIr
TfjPb9L46d5tKpgz2HT3Nl/MfZDsqOaD87Q/0HNCPT9LN0LPS/U8zZOelev585k66lmm0t1OJ/sp
VDGj6mQ/NR98m2Yp7QmmD56e71d4ArCmtJjSrmD64Ob5zAdzxnG4PE9/MGew51dXVfqLWXO6ulLJ
L/pZe7q60ukvZg3q6qpOfzFrUDfpsaWfs6fnz2Y+mNP27tnM8DXMtfvpnGyHuXY/Tci2wPnvflrn
vzpm/fWeRYgucUDD4pJo8dFnH64NTL+6+vX+67uo+/3fP8a6JyIuR8AD15I50Ke/N2stTRgM43EQ
RkE7Br6colZb25v/enq1u755k1qKwxkCzrPzlymMMWBcf/viLIWyDSjbp8lqTgPG1eE7hvE3JzhM
dl/dX20gb8KakNeHjDBEVmwSpDkF8OTDjz549On7nzx5/OgPn0F+bF2tT58as4Qlho1dZ+BWsZKL
P312NB8vFvlYSbN6OVF9maVaMjv7RPY3u7RnViMO19diOWTztq0hrFNwN+RTu+Y/lm/DFQxrQP81
EVKm22DGL5zFCdmDMjG896ZjI0rvsYVMmsrHumfz6N9cXb54/uQUti5c/bChSVm6HqAhLwgLI/dX
5SQfPsSMnZnTv+tXQs32HZ+uvpdafLwPAoNsjc1Bv5tYpyDLYi4Nr7rJc9VvpbLxbonJ4jqmeJr7
3fIsrpXTfnuzHTa//l+VUrGFmnyJzTZBUsNn0v92671p3xwuSvamAdor2Jumh66NN6dBbWZzmt13
Y/b9b66/vXpx8Rc8DcROC8e71Oj+NGV3qcHPBn7C679Vt7Dxxu9d+/PV+c3N4YIfJT7xB4kvn76A
vXInr88Sv97A9noD26vbwDZ5hz9/e/7UnbwyfmLyAg/eSroEsIbD9hrO4Jht1+YcwQkK+4dJd9fg
VSZ+nh0u9pdTR94+m5gGStfPt+aQjvdFZou5Pel27dvLDlvBeYftZH2TBozpbXc/7IyYv7naPp9i
2A/f/8N9Qzc++HcNpoxsnV+FU47h7MCJ6WnfHyaT3V7jrQl4wsk13e7duzYGvZ/4JgcT+cmIraU8
TY6ub6Cbb2Fbh9mYbk7MuX6yv3Qu1S42mLrM6d795tL2ATgzhIcorNBPDwaLVLa3xxmAjK0Cd5Jf
W1s9PUxy3ZlDXxegovOL82fn/211KzQBRNyJM9E8c9DjxdWOHAaH7UVGyMYpIdfX5njcjdkaTw6k
WEM5sdK3hz/tzpDrS2M55/YoCdqOEc0FOWPgz2hs2V5Fup9yf34Z7bGcQqNvBPBwdXVxGe273MJp
st1TsfHy6fnp+enh6uYHAb/enh0e7MzyvCz44XpqswB+c7iZvG1iT6fpUTPgB9t3dumC87mCZ3MF
p3MFZ3MFL+cK9lBA5WlEdHHz1ErZbU59cu8xdJH7m6npYAgIoMeNzBkJ7zkxZjP7886uLp+ZfT6/
nf7/4PxCv/PtO3AKxZ4Dtach/JE1u7VoGlUOu60p+H7qXhCXnNpebUI3P7D8/uMPp3jNcrmHHRCT
AZ+df/Piyg0ycNhwU9t10ZvJeqYeb3zGgweHC2PADyzs+r3t5CDOvQuA9sA49/3l1V8MFdujzalT
R8xQmYRo/py6oTlCCDbsRebOZkxCmELpp5ff33s5ha4hs2ID03v3DNivNpoFRxPVp4l8O4khQ8Us
TGpJLNBypIhe7l2fTJ/9J+xJwFzQvev7ZupYDU9fwo8pkI6Z2EzVSfjUQgMGg6B7FDfPry4nP/7s
idsBZba3PIQNnRuIlN28KbERemYH9PQv2AMdvrh5Ninvcnfv36dP/n2armxeWkAg8O/3g6HaY0T8
Fgw8qQtH6N3xH2PMLy7O/+8LMLupT9gzc5dnYAnQGrgbASbv9y6mofz7y004b2XjwS2OReAar52j
n3yxO2xvTom5oezJ4f/e5+fn4LgTcCOOs5pJNT3qGS6J+NIdAoUBxowz/MS5m1Run4MXhwNjpltc
Tt3aTRTAQ794yrbVAEV/ssgxZ8dMy97mLb97jbLoRIzCTR2A2pq52NXTHybmpo50ZSa+06A2RVc4
czebUa9t3DCNHFfuRNlzM07ag8L7Pdoh1sPYZBNZfyGG5xNOVc6cOyVn2SFQo3JmdYRTbE4a7H4G
qOszca7Mn5TllILGJ5FOn+Dnj+gpOGu/7loIvJPjwn2MJ3n/tnnLDr2nZh/pW2/BnszD3p6ee+i2
VG8ub54eLlwPtP++iUBWuDsIKbCvOunJqyXElRf+kDc3ayEuatt45uw31/zgX+qINx4BZDK4ePEs
bBTDzuAPJ4ej0AW2nGLKdOOLm0X9W7RA4/Hhhp6Z3qZOxd+73O1eXMHJSXKmeosXkbgTD6yx59dP
kFCoa+7s9iLT6XPa/m6QTBfxvgQPZC/Xtd8/fRIdz/794czM0gz2NAMl+oaI+d79DRyu/O7yL2ao
v2EHnMN+QPQb0VwhHNDk7txfRDBJnNym4+i8fzb9a5qT7aeI5PyGVmjuW+DH/8M9JxDwTGWOiLUH
6T3COQR+0cDvDVHTtSaJKnLK30rYV4vnUz3Pv0H/5GrN8IUcxd9OdngFaJ4Id+bnZ8483Rhp/nF1
eXnDJzS/IWw5QsbT3n/Hp3Lglh2YLD+1uQZ3l1FS8QmR8dsSxLF5x6s4PU9uL7igRnp+ER2jd2S/
mCa3cM2TPe++hzs9wBPCPRXOOfGb9yhV+OQhOZX/xwtxqwObX4Kvon49HGc5mPMvNAY45y0GwcBV
DnvjYMjRaPRenLEXV5GnFBTjs9bc99iDMeR725TMQWL2PTkrTGjI8+DiLqyYjPggUPu3KRx9ZlJh
9tQ0xmXX38I9Hd/C2WveG9056R113F/yI+Hma586MMoSNJi+7Agurw2L4gBQujHPHJUndjiZBvUJ
akRvA0sfTYNxvZ9KRsAcxqTfjG98+oNL2+1lzAedNE52cDuceqPJPzlDFGza3w9JiUPfvGV68Vf1
1w+NEOz11MbX/vvm3v7y4jdmILkSA5v5wGyXN6cBHiLQ/AMOsVtBOOosHKFXpHhPbSZ2NFtExrHr
yyub6XQTz+ffbk8PN+e7abSDrktTZ1HXpbVxObFwIt1tQ6d1uSdxoUHS2G2X9ZfRBCY8lp1yXVsJ
veX4iGwFpHlzBXAa6lkYiwDfePD/cQdIXaKI+FTXp3jbJ7E9d022zEA0tUn/RwmzOYaf39rB49mk
vHf1yQwVS+f9P59s/mx+TPL78/tfeFKTOR4mRzBp9frdOsmIOUcbWuWxhVBhD+5MQ3ig5CnAeiXX
4O7bv1yniCDCJHxzOcwMljEig7D5X8axYgxp/AEfd96aI4BUHpkhFHbtTp3C5u7McbTNvUmM9112
mu/hzvx378/w0SR3m9We/v3FfWvDV9dXu4gzc29amjuuCcCD/mBvGzPscmleHb65fshFB6DbiG6O
QCw6JzjXaCI5fYTorPhzkjNbZ24vOST3/fb7J+7QRYKgmbO4ExkTh7TTG9KOlHExprtfU9/iDoqb
KqAsuBJZIvyM6UPgAM2sR+QfnKWK24UAai6FLnY2jyRN7nXcnApK0lQMDUhyGpQTuKstTOa4bV6/
OJ23I6/ULJYZdSB68T31fLINDPvj7vAyRw2xAOmr5uvZBn70cvf0xbW95oV5QLPNwQzxc6w+DxPF
Z3SWDLxNZjPbTvY1MTDXr/HKLHcr1f6h+PTD8z0kic21hVY2sBg3BX9GWt/8Pzwin8b4i4yJfDhF
BmbGCtZhsa+JvRuvnrb2yRxTpn6+S9j5RWKGcm/yjL+d+vg0NTuHe2XF7OVaJAcvn4eRFiLhb/8y
L2DTMhLf74EgEctU7zEfG4kAH9dSGgBNCgRKEjKx4eiEhCk5dqng97+1Pg1WwXB17PqAN+JCWL8X
s6aJgYkUEdFU5UMWXdhri95yDTCtsY2TrQFosjVQIlrjEb67nCzT7DWZlEsy4iebd9555/7m/S+/
/OLR7//05UdPPv/i0WdffvxEPeRffr+9ulj9JQnDNkZt5qaSJ36ZT1ALp/6DsT155m7WIK1EWT6B
xPX15h4XsSElIYSCv37LsIIIZrPkSaSJzFfBFtKfmt1heYogVLjp8glMge6xgcRRkC0/O0xexd45
YdGECBOfTA72Cab8HTZUPWHTf0nOzAlHUpFpqIFLtIns9cFr1LTkKsXUZMvuN/5TsmkJhWD1nv1a
1mcS7MaYRBW5f4Ei4EdaSqG5E2HYIHGEXTIixDiEzKCp51dn/roNaz20vgj74ok1ianK75683CT3
xHmLD9YzL5LZGu6AtlOvrOLp5eVfXjw34bB13ctm677A+xCv+CeRGcKGTaIeO8uU4k8m2LFXuxn0
jOFN4wGcpHeEZVJhhqHwQarzYMrjCUt1pPsZ0GNT6KRt8dz2OazjeW6jxPfJbEo8FlqEgnL7Zmdd
aAEpYPGbw82T51eHs/OXT8w4ldXrXA42sUBV1BZH9OnT7XNwW3uzsWkSLL27ONllbVPd6hPv4tk+
s8iMoyzx8lR5uxPuzJrLHNFFpuTnGYMLy8VL3oPt4U24dbpumqaVZjOkhtNd5/rbCe0vayi6nYpp
ci+ut99MNX386JOPZoR/dn5xfv2t6dQZrpzeT81NHAbLtDt2Kzh64UID/9MPbAkmYKCc3A8XJyU8
T3PeXSQqcnvYoLmGdM41yiK4Q/eJ+yeymvbZmNj1DYulhigJyUDikHD9xoM4EH52uDaqtVGti9O/
2z4B57a9cqkdB5xITeHcPQM2FxfBh3ZHt9+6cn2zhwuxntx789fX724+Mlcevbt58/4J24JiP/ou
+sozY6pwSFtzM5Wt1EJeHl6eT1yo+w/dvWSshXHAXtDChfblWvjnqT54p+UO2/g3nI/t95vP3v/0
I7znmO8UPHEXZcPbKtOE+4v3/2zzrn/2c7B4NmKSzJnpiD2CNhv6wXVw/go3c2rNp5feowkleTUK
zTW9/Z69X5iUmGsWGJdvkcsrXl4d3EYiwMX7uOQHUx+hDLgK7FV2Bv4Vsmoui8LNSoSG/eLZ4dn1
4ebePTc7EF/Ck2dx9e4CIYFsb7OZKns5oe5fTMF7sIoIFYT7Xrh2MUIgqUJ/hw0gukMcDP/tt7+m
VnRldxQ9xQ2zJKnhHrYwm6HOv9tOn978P8x2zs2S59LEc6/iqede3yeT/vOH4TKkvXrwO2MH//Te
Zq/hT36XG949DTf0nNsbes43/7Jx303/ePttvN3OkYPGn3+NJN0/vQ0Jwu6fSnQ0FFGU9nCdLypz
KSHR2cyM13cyOtHewJp1PDk23N4PC1SPDRDrg/uwL2AfO9wrRfRk+ZlcoVHq9qlJXf+A+yVs8vpw
/eKp3aKw3Tx7sft2c22s3r61kGnIJtKl+fnQpyCnr7+qXipz/uXrh1LBtv9sfAeCO72rcIfe9G/X
W6R6QTpUuaYep8mv3TEy4IHsgYqp2FtbaW3SXgxZYhtvv20rtsShvd49SEu3jJu/rAW/t8FvEYrO
LEqAbORmSI5hvBfQuh8Z/wlp8XFNDKx9BaQm72AuSQtr4h9ewt6+82tiU2hSPnEbdUeXjov6o3AW
1oxtSs9w5dmaDP5XcOjnXmAQDvQFIPzTdddzP2T8jfgSnxN8j2YB5fBDE4R8+HF51Pdip5Yegiy+
HATIR5MiKSN0GHIyQJ6NElzPIl4JS99+O+Gevjk3R3jmctOb7MabBTfFM3t2jTT2VRY6s7LmVwPj
7wz0Pt+yAClos0vv/Ip5EZ8Ln4YmvJjWJ9cJDE0Aatz8zt+R57+ULtixBqw89F+bFpGvfR3R17bp
5mfcR22PwHS77BE2OT/Z/oPfTZ8bU3W1TMZt7lMJxWblwQRS0AQ5fGGHBfXHPgrI2IYZDFeXq4qA
oQ5XhY8iPJuuL5H1geiWO7J0wPuSbQjpS07F6Z5ksWVP8p9M/YgyQfuRExjya/qRsyLSj7A09CM6
e3vjwXwG+nxns3m7p4ftld/beZ0MZ8yFfrA85QckI8n4SzCFCTlaRiMDmzQng+8WMIM9EbbPd5PR
mGsPzFLiNEaeRBznCL8soPwySxqd0yeXl38xL1dOQoiWix8aeXzwxUfvf/mRfThmu7k4fA+7x90G
QHvduVWvVd21uyGdb60LC/50GxyNUvOLBGY7/RM7uwHlTnZ442cyZN2a/NOsdd1cEcjL68OOBEJ+
LdabxYl9js7bAmzR24e/3bK2X6Tydypc7J5N8wPC45uPPnj3zZNNza7/9H1QTiz8h5u3N3W40I/U
x64RDneCzhKit7rfg3ab61pvrnbfXt2zHP7mP//zN/fvm5Cb3JUa1QjfOzlFFL4qJeBUERF4e5GA
i3AemXMYeDTq2fPLa7NbxO0fgAh7Gq3crudn8GSRWaSwi53ulS9z0OQsbKQ1NmkkYPzXxe5gz2Pa
nXTk1bSDPSb9/cHuAHaH683dqWFxfWofyFfqGByJE9zvNojyqyDL4HhhIHMiIqhBalXQvh/4bKGs
1Zn+4eVNMH9vdda2tzeX56G+tzfqPmPkHvnYK4zhpxXH2EBi5mvTM9zXU794W72t6jdZt8D/HH+q
fkjh/p6Pf7Jm/D//s6Ec/suGSh//s0mkJ/fedFcmHCzxX1/DbpPJ3++fHvb/eWFSPihIUunfmLTR
/H6TtL7Jr7pnGK25uc2R1gqnqdvzp9vdAV9vdFV87w7t+aNR0I3xESZRxWRpsH/l+/NrkzEySaRn
l9+F7emHZ8wW/2nWGLnFmP/eii2M2S1Fje32b3OjUyKE8nZgHfjOhkvgqMASQkXm6YngcKyFwR2+
7htRJC9J/Z/Q6f5p/mNXFMfB5lIQ9Obio5ON/2Mmfnb/TQRggUh8f9/Z/H3WVmvz7wWRXMKoZstF
4Ajq9QMfQXhAPKWZCxovBpNAeDaUj9vMWNx2m/f8BpvIbnbJSNFu4JGBVzpOnHDNrU5YwRQX+qkv
//z+feHlbBy/wyBwY4V0sf86ET1bIjQHGHIY+BlPZLDv7jP6ucxfwCEjld/vxjF8aEnnO7xvEUnj
V6Gn+eoRxJ21/OIrZnm05P4DuKF/cRghArC+GHaclbhB46EOWAS8wp3J5kJ1syTuTrI51sE2zUCK
G8TCXlJ3A4Q7GcA3FoZQZurmWI0ZDlwboKc7TSRuxf/YHHw82Ty/fP4CLtP3Vbl9qIffXB38aX2y
89lvCH9x6syCnG1DBycHobcw5gqdxg9kRd6V4C867tgiYN7B727yZa4IU+huqSmFZZ+AiONyJ4mT
YI3Oor6HmzHS8ZAUohXQ275vgNdggSqpCILVhysFHhrjJkJBPADINy7Z0+yHzh25QMGmu2jQjX77
Yk+mWR9PZm6OShi7d3tff2PeFD19YCu26emLpz88tB77+sXVwe9ZNecDJ/Gdwtk+qNtP5RIzqdm9
UwfFd08dfJI/mkOrjR2U3rpnd8YclE0WR4haImr2vs1OBU+Zikr+aaIQYZj/kg+o+D6R+oqsCxAt
YOgBnGD8ocNTBfEK5NweMicqu4R+Zp7SOrt8bvytvQjifPfOzenTadL35pV7uwFM/vTF2Ve6agYq
FfMxi1/ssu4Ur+62ZvA2L4hvCFFwnyadOxmPiVrJOw4fnl/vtld7d6zbvOLjXdeZuZLBPAdz5rM0
099TyHv2HAm4DvtPZzAmTvBIRReo64e8I/vJdgDdPHvuIVTFMR+bwEgikOPPZuFvx+qjx48/f/+D
j4CCH/AMtc2DjfqaRldJhElpv/nP6jd0VmTd0cS8eUbnxdlDUaFplgkYf/PwN3Mznbffpk3HZgNF
IDl5OdpuEbNuT02K9V7yHn9T+dtvx0yfY+QR+y/hmZ33gkIetFDHG8fob5rkTjxP4zO8GcrVw1ms
uQRaQDdHzs4vXhy4OOg47k8g29DjapqWTx3AHHfw3pQcIRWqnGsLG544/xfwDjaRlrSOKe7wZgl1
CA3/lf8zZTCohFKjMf8lDMdJK/wjjLeyRtEAb+Ynv/n5cG9ovuWIxozJzhFKZs3PxT5uqOLkwpSF
TRzop2bq9yu86pOV2oDLxOdkgmNCq/vCbia8wpjqaPYTbK9gNlP1VzEVuxZpuwdRIemun0bBDCTj
bCgThTH2s/97DbaR1QMzppgxP+SZdp3Q7eRsLeJs99TcBXAvDIl2DfT0xTdOvrj9581f77EF0xB8
YiemNI/+kX1fRKS7zREyc19AWP4jYzQLO9J70q8O06gJfz8/2Vz4P0z8b30ZTZJPyD5Z/dZbFjkA
LiTATiMMwK+M7Eh63L016GehE3US19h+ufHvBgJFy/R7G1k3LoHHPNis2XubwAvUYCDoZZyn2iWf
6Itz/WAPeFqKo4UFAEQSsU1YWmDDWCLkmQtLpP/nzjLhi4v8MKfCpGP+S3vCuVnV3JSKp+nNHxgL
vP3mcro3l3mGpi9mnwMfx2egI7bMf+bqIFO7qv2Ti3CD5rVlSjHfQzlZlb4mjRQpbPPfUWls89/t
Utnmv2hI/adUXSSnIMZT/qpUgJO1MuLv35/iMD9tNV4futPe7HW8kEuB/sJE8H17yveji/35d+d7
8TbdtbvFDs6M2jnx5FimuRNcAyKvVSTkDCdmAmWy6dMcGzu5SYois+cuu2UE8ZZbDXWMnhBKU/R5
PpcH29xzp5nNdahmIndx2Jndolfn9tIId2XBow8IPWD1PjNBtqgo1xONEzTWY80o7gHefanIESzO
GlxymXkF99E/mW0bc30f3X5hXGXxT+7ZUWExDsEhopQ64K+jbjdWfR0ynqJtbOMVHzLMf9HaO0Qi
J5OLmO1GNMz4lY0x7r35AYjadW1YWIdQI2Sfwzuyf3q+x5vmXKIDrnkJcZQbgieG4Q/4HIdftvPN
jbyu7bibGjdxXURJEkgxzZx7mwB0dzH6zwmcnFE6zuFq+w//z+Mnn/3xs4+AJy8iTsFdfJwn8ujT
zz959NGHBXQ+LiL0cY6SuTA9T+XD9798P8uL8W4LjHz2+MsvcjTccbNdnszjzz/64NHHjz7IUrq5
fL5A5cs/fh4opHH++OW/ffRFMreWPAjpnA+B7L79y4mIbL+hThjm5Gh8dkeI2YGNZyXhmhELNnfd
iCSn3XF+9f9n70/b27iRhWH4s3I9P6KjObZFm5LZTYqSrNhntDq8R9uh5ESOxw+fZrMp9ZjbsElZ
nsTnt78obI290YxzlvcOr8QiuwuFQqFQKBQKBSbpWHNpQfWEJnZcEuAsZ0aB0qfzHMdr5fTrRPjO
cnWw0C6zkX9HoUmMG0EifGdpK7iHGT0rBt/rghf77C1mAXpDMq6wp3IUOssDZPaAGo+VwpOyMwaY
aVZnaYFB95OGjahV2U/6JFfdo/WAVcJDqNyuUA9HqCipku0tiaKyYiiYXzxDXYkWcCDhbLHDZloX
kQ43qW0l8t/rIJVXLO4FSrU1FDBQWUMR2thCAf2qY2okO+Z72fmnuZ84iQ21gZ50QY/+T6RL1BPa
tA0lOSTTGUKJ14pSD/698AdA2eBVkceDIKEeWsh4Q8/y1lm+QxyrCwEyOOSXJFTEIS1wAQxEXKWQ
E5BnUqNEFcmAceJobG/jpQANqilyBOf8UgWynoDjXLN0PvoiTh0s6XUcjEjCRdJqyFCtGeHkVA/n
QQ8aRUJE8JRJhjL0e030TcBHMo/5pEcnOlQAxzGjf4VJjExgdOpqyEaqgqGo2I4htNqefxCV4p09
slvNPsGoKQforCHPP2R7bR5/pvtrrDcgWdS+DfyzBv6zG3yugXd9XIKIiJc/4/+70qkjbLiz81yi
m7CTC75Alk8BrzbJzQ04tDuHcYDpoxDaqS6kPNWEDAhWNppwglDRHv+ePZE6n0dcy7ehdbu9bhNW
muqL40N4U3S8AaSDQYyvrv5GSq+Z3p0fWYudH1uLnV/bSD26eteBcuLiqRgCKgc2Nsw8IEMeO8Qw
A8F0QbaL5qyB6DMzs0woBn1fHB0rjswbB2G7CcfskzcO0j0mHOPEG8exFcfAEwftbwOOce7bFiYZ
JizJbAl3iYoBaWz0/oj9bQHkNInhLDD626d/E/qXDWT6a0b+zujbWT7HmTsxZngAVrSwW2AI5/BK
pZKRO80NZyFUbgTyngGyncfxwqU4INHsCLIVoOqpOYMDKugFcMSWR+/oulFQmt8T5ObzoexyxYwi
+dD6KGum4qpNQrViGuFb8Z7Fz/h7YTbDrn0XrVtZQa1YaOwsNDYXyqJ2tAOLSByBRkqxGybp3cuF
4B10m1rxXVvhsLTwONprNlDx8Wp1j5uhrXB53bM8XQ6mUHshH78DUViGyNycAhXMrkevoDAIseDR
x35M6CRJNRQBQmT004Gw3onaqJ+R0jC82VkXTR6Cd9cT6+4637FQcOBO9MJyHu1ZaDtvNjTaUO/6
YW2GVtpYJ6M6aTeZUBbOZm5qimE8ZKz27WM1wvFmJf19GGojJ6oqfIeR1n+RZ/9FVh4h8j1xmPjs
4Fhi5di4Wdp0lX1HhtHfrMo/BQkWMj8GnjftDESEeOJoVmNgVjCQbGbQuWYbN+vZxBrThdnT0nks
2dwaw+skKb+yp4lR6Zx2oQotqIBXrUixcKzcapk5zvA0vfGYuG7a0VD5O7Pyl8XIlohb56p8Fau5
THQxmLnFYO4UgyzarjpKrrqaBGRR6VhTB6wRS6s6ll738kbrfkSPZ/d3InP3MzwtbzwtJ55tbzzb
K4pj7h7uzdJ+1niLViJn+mBvtisLzHVXH6BNX46cN80cYXja3nja5ZytNPCWjglsJW6/O9fmsFWY
reAxcLsqr02crsZn4zRGEiAVKyeLG4lcKzMRnhWLSkNGoJLcma7FJIQ/eq0f60WA10w9fB/QJBE8
BlhcNcKotZ2SgkWlcEJPOJ23fooJWa8H7ZptlEN4Sp4vx8VdvDRunjQC8vRM2H0842mOKVzMswSu
cypW7cUHjmsEn9J0Bt5kfFswPRmfLfCxJzjV8SklwSL47lwBnxZ0hLeAxPWysQkMsjjrVTAr+IEf
PqSIDPFEGjb4FEFGpNUJvueIMOXZk/zZ3yck2kZvBrmSlMCs1+oQH7sm9QulZN9ULa3hdSCU2Dc4
LL7Kj6SfskqyYnVNE1aJAjFGArVtFSjcZ4JPVePn9CGdjxDv4NQPua/pSb755knOmRUEMrd0m48U
K2lNcVb5QBz6JJ87PpZM8rgTwacinpNjx6PR9DO5PVu475fWkD4m6WxRBG/F/TyF8/JgtJK7Z5NU
ufoPK4JssYSgHX5pFkUnhnIpJ1H5oTWIb8JndtlxK2MKBZqPgbukJhafFM/BIG3YVvRnFQVJ2igy
yrh5IcZ4CzptY0OSK3r2SKwFH4i1hBKSo9AC+AeSK4XsoVrPIKNlurHM1jMpFJ0G6uGZBgIHZ+Q6
oXto40M8z2IabbfMF/ROgPQxThajL9oeGW/w06ciTTyupGj6Oq5tXT3xTYg2gE94KAqZdcxQQPK6
frZa6Ae9kMAhyWfJOEPmCK7lyO3a5G75y+75wc3L087J2XEwSe8gBgtXtcT3jAutWk5GKRqALDQH
3xsVC0NtFOMrOdlNFP3RNNE3IAXmBqqeUWe2o/s0+RRgnbWRD2uvX+cXQXwHtzexS/OC/MI46xD7
hLu/Sel17/BaGvo13JcDfhl2hE6IKJZH2VZOI4thBKytGTotH5KAX9VHjwl8EUSaQxY+Xx2sGQ1x
DszXr29vbzVuiFFRUnWsmD9XRCxyo7FX24oIPjIfJEKUwtq0qk+HnghfGxGqnKT7H4SVyUqcTL4Z
I6fzLUROMjZs+TibXJRzstFRMyq+NZ1Xr7kot2rNq9Q6RXbp76z0v7zKlTqWbKX/3p79b6h1OTHt
nzprxUV+lxogOasoOnlE6/tc8BGUwVc5dE2ap9Q1jGYxW8y1QTorzDWjfSPu1XJvUNi06hKhvaWO
xvPz3X2bAjNRm9x/WoHac3EHwJ9a1RNyGlWidYQD/vHS2GRuijarTnHYCs5Dwedhszwlg9XK527J
vW6F/erqqr2+EsVfxoH+fAtMMMSCnYo9drj9LcTrsFqH/Q5yv8louHl7E20nFUleZfQe7nyL4eDg
rrpcyCYP8UgJ2TfUaFwUZuqaYa2cLTl4pCK+jFkjfDAMM2mEsUPG5p3esCEwrUYWRwZ2QXh3Hjxl
fDq6PD7pXV1e33Qujvxox84PH9qj4LxZgfzIH3YnON/9Bo2VZcPa6+KEp5xizvIErZZH4uJ449lW
Mp0MnoE7ZUpv3qtJ7ivsZsDFmB8GfceFtJXe94wMkTjKbeNoG5kW0pyN5hE62kId2jLIvhDUmskF
gNiSNBCWVA5GBpbyz86YwJczKzBmS8vV6eaLD1us/lzndHvY8pxpy3WiMQ5OrzB0V+hRFZkt9AnZ
2my7mMzm034qCIlDHKRcfVJ/YiTYb+srt4ZOJkgIBsXbhmr+fsNzcW9y1P2/jP1mE7ElqXcrq8B7
6cso4il1SSr3iHocpsYRVqMsJgdvhuN0fqdvZzDEBtaSEvZT1MYtiirWcWgeOR5bg6f6yW1t+8HA
g3gwgGNcTXw6eDwOWzUjP1yGCaBYnSWGWBTF7rbwROJOufXeLMMCH9AzHkY84lLNtC/kxe7RKgwe
/XEyZ+Ovh8whVkRROR++yu5VfNXImOrKCbkYBnNpMoC/Wx+y8Uejt9eiQaWtj55kJ2gmlxqQTPeL
YYOYqTFtI0tWXn+DTVPIl/IJ6MYe8HwKR4GSeILPJcKOlZxGhRytj+cpnPwTGjWGrUnI2biYBjHs
0MQ4kR4+708uJ7e61aFtrrTuvBewXHkleJe2qoVtds4iNem7xDCSw2Fm32+cLIJ/KH52TNY/CFn/
UNLD/wPTtVZOD8mQ+A8gCKYd8V9udGsR3KJU4fMxwZsgVMZWcVYmBzsPmcOdo+AJTaFjXFwpyK2J
wuQ0cfL5I/hfSFjKNlk6R3XQHTQJA0lgsZHBxTxfaoGQqV7amhSERe/ghKZKpal8renFcCYrDIGT
vJBv35NNXZrzF/NY2jj+PM8WJN84JPwYkIyl7MdG5+jVk7wmbCQTrHWO085TWn9RvXVDmV1PxW4N
pwEo/48cTuK8J7VI2s9vReUHsukRAPGFwDocQoT1ZPe6d9C9lWL4mN1EldaH7vXRx3V5B5BEJrf3
XcUOr6/MxXZ4Mc13K5S9vrnsnpgR7JYj6F4c3JgL75UXPj3qGstGYXnZk9Ozg7fm0q3y0kfXx+ay
2+Vlr21l2x71np5ZiPborNNrC7s8+um0Yynr003H5rJNQ6ZfrcFHP5nLRuVlOzfm8dDy6OCr02tj
2bZH2TNztW0P2TixFC1Ew3QEiCmIoxIFcWwZLx790Lk5Nw9Tj6I/HZhFx6MXbsxFPQT2ra2sh8B2
riwjJfQYoh1bWY8R2ulYVLEP0acWNnv1rm14+/Rv58pSs88YtYyzqOlTsVkmfRR450cLzR6D9Kxj
VuA+uqHzk5nRPsrh5spS1kMqTy475rI+Unlj1sE7PiP43FLWo3+Pzi3Kf6flpQ7RKHapwy1wbq2i
0baWs9X02VacGOey8oLj4cg4k/mUvDeVLBe3rcxIbOhBbWYs6EHs7JOxpAexg8WKOndrYGath/GK
ihp566Gtt3KzCJXr6q2ZuaSH2A6M/eKhpbdyc0kPURj0V9TQWyNzOz1kYWGus1xLbs2NUuRhW28l
M6MUeZipW/PcWNJnbJvVic/YNja06cGibGAs6TPQYmNJn3FmrtNnmBl52/IYZnOjyLc8hllqpLbl
MVj6kxWXK1uZkbctD0l4GBtLypJQvFfmWzVBge3cTvfkLUttqCVSpK4T7gHRfSc1JaGikML3yTP9
wga9lQfdD3978tEYZyEm7sM+lt7fXN4ShOkdcVl44QJYN7on9eAJeOd2/TD6IWt5Yuu70B12n/hg
OXTSdNT90Ol2/Xh/1O0h2BJsZxWwnZVh82rgkRPJKWd6wwfZqSeyyA+ZswPf+rXvrZOkK05SGPhg
u/LF1pbRrWl4xPTZ3ClMLqj8NJl+Du7R/4spdal+CZ48EdMfF+eLoDjzAMN3+RYdRZ38xUud4Mw5
f/GSHYB0MeT4sOuF6Ng9zDqeaDpuNOfXChq1V86v3d37Nz8yEJwTzfmRH5rzIzcav05CcC40Xb82
CbpGk9pjq9T+ZUWhlTJjo0npFLus6sGuNXMtmZBO2TFrFzItFEjDc+vGcVSO46gMByJUj9VSe87Q
GCll+OQ6nT9kSfrcntG3i7MLn3R/6hxZMi9zddpwYkHvneWPTs+d5dF7Z/mrbrvpRAAATgzd6xMn
AvR+X9r04h1+8X7flMQQb22K2W9JOvuNmnjYuc73a/kuKYsJ4kqWbCy/buwX96cWG8oSJBuk7LpQ
w71pGjwr8z2/YxT2en1DIMTaikPZa/JmJd6KDD48yT8G9zFkLy/udYGIGOFapuKQcCBdA1tcCssq
2Se1EAPcWN+KVXmEnGgHjIMq/NWjCSBgjL0ll4J+U/YjJsCudc5CIUj+OXqJNbtZE2+74z76Fj3g
X+W36QYheqT0wmGNmSITjezXWK8m9P+o3cskcSNhefuzHBaF2QTOeC7JNRWARdikdzPBfsJGjK9Y
U1nA8owyLqB6fg1oroaA6ixxWQlJXHtIPX6AdM+/ItV48DPcW/gz+9NdD75ircUjR3ANRLqnCyTa
OJWvGB4kcONn9CWb3L0K5vk8Aa5sPMlrbLRCQSoU/DKtAjkRRE5e8QIefazrBQg1OJ/wvwfr68Gr
YD3AycDvcpwNDYPzGcFYztIKE/EAL/WlL+WUFO2w/o14bUmGb6uHy4uR0igCOnkEjdSRuZC2o5iC
/j4RsZHuBYKxmJVJjTQSEHHPnjzDi4J6gKwiNAKO8L8ICRgnOF9tEsMhfyGBMzPscKqAZLGMR4J8
8+T6MCRw84qbScToELhVSvOKyJwWUmhPSMZcHHfCCxaRKGoPFaEmwgKLsxjGzd/XkXyicfBkIP+/
XlfHvxW3BonvHZFloq4+FJIsM/LlTOEGUD1BN0jyr1jYxAH/zyWOB3oOR9rZwJ4tF/jlxrO/rz+j
AgrvEReLmlgGe/QO4xDSmQMsXCPFC9O05AROWEVRuVpTeP1k63n+97//fX2dcoKV3MRU1Orkz/53
RfAZpo0AkXuD6ZtSyvCQW5OC0aCH14U6lBRHaxyUBMIJqRXZZS1f63xk0ZHNy3zd//uEvqQD/WAy
ENc6cNlvMcIl+28A72QT8FdR2EkGimhfk11JPSwneXYH01B+Dy5LVPWTAVMHATQ8KxpEAghR9f9g
1ZO+x6rhH/Zpld4LL2TDxiwVMGAx+sdHPYcdFH0T7Kj5rbR5mPEaE61PwCovyEeeRBUu/X0idA4F
EfqIJkpQukrXxX8h03xwcXJ2vXGLZJde2HBbe8m+fWh8rNV4ReVanFQtKXO17HTWq6DfpzMEbNPv
kspblxUNLkhtwftPoGOkq5940QYLExXKK9ZyMYyAUVgM0cjGf7GwyFWpv61kIQX5X0UWvptF/q3q
gsBXGbDYSRC2wSC4vumyqFMkCDg7D6wg5RTQVEQIQA9uQ/gSPIcMXvjCGlqOXb+0mIuLT4Rhjq9E
h9ta6DEXXMNkX1ifPgrrUw4A3CU/kKUEaWoU8RHfgRIQ9m4ppWQxTI446Q2Aa7zWiru7xDLMLmRX
dlnKw6VeIoHycNYaoyUQEt4KUQ8iITjGP1iMCxpVOmq2cmiKDoSbM3PxUj4NFC7SEc8eFlnjRDhj
+0iKFLiZUIIu2gZXuiBiakjbMg6AhkgnA7OvRMfVIOV/kMoXvh6Fq9QGCAszhN0qSn4QgQCxfAFE
1IKXWH2vkUst7VRgq6fG0QzhOtAfCrudiHcGzd2Xj7YmyiEGnbXZx6JIsWTCAyejdgavlLx4g0mn
sGzTb0027rEyBj38hqazIsnZ6PALss1Nxk4n9zNTD8p3//Ca5Aq4yi+pQO1eA/JHUXVgHgePwRvE
HvSXt+NXo3w/Agc/kvLC04/m0UCg2Yh4pNwXuKqQ7jU89eYah6YGRojI2EvS+hcvZB+hLklfxeh4
SlQ/WyzgPj2kt8fxp7RHf1NlJl19opaY46sP1VbS1/w6sDRHxlaWp/iSXZ4QBD9GoOS0kul5aHke
6c/zT9msh0/msOHPwXuLaQ9eC2/YqQHCkMDAE0ruc3onXJYTJgJP6DWadexighXnAO4J4inmemRt
RCVIQYdLMunCMxzCIf7G2MQHCt598TbkQtcp1ZAkfEwTk6NJ8iYJHw+kUxhdwlMkYmh5lcC9knw4
UP3J30oLKYKpeCejA9UqlNOFhtBek6wUgwonqCyF9zX6ewQevQdO4z7kQOJDQrnYUMQy8RmhR2BL
Mc+IreJSiZ/iE2Kvi07GD5HpNZ1niy/oBetteMfukZb7Gxgcqn2GO34D/fvDD3B/6G96qaeiQ1B9
+eaNen4MyFKhXqNqxOHCRETSIGSrAa01svweRomyx6CLpakvFKjZPH3grOfkTRENWOU1o502iUui
HNtQBK+Hk43axV3ABVXxny/oT9a/LwTDS6KJ8s3ACGr2Iq0jqotkOZ/3cP5M9KJOF3H1YBznn4z3
n+APgUJ0eWoYrpJZbaISQS/5T1jMYbkkNfCMEMULIEzSSYyUlRRVgZab9X2x2znhwHdBa6Hn0iJK
nMFFcZmQ7jeoacYJNvnYmW39aL2Atwp4UhC1S4ohp1SNCJyI+oWMKdl6GOOknJxfNRjaaICTvmNc
gb5Bo3tMmdKHMtQrAE+Dfw/C4JVmAPepHwJ+AZthcHMK8ZTaJzYPVEEAzMOHFjaZCabGU9S49Y+S
JjWPFIDCowTMOHWkmPvC0AWGgcmkg9KK0yo78GNh8RxvGJd1dFUfXBR/UTtdUypD2jbchqbJYCME
SYp4ClIhUlBQpNAFFrVZ0D9JP1N5EyVv4z+JZoXW1WBG4t3PpcLcBRyduRc238C5+B67qpHn49Ha
yGbCUHScAzPIPIz0At32E5d+JhGk/VoPWg0DdeUKRJRS4jIjN31v0qkHJJdIN1El7pYUjl8dTHQM
CFNgPEJAkxiyX6tzFd7Soelsxtm/cGqOYAabgwh7P5ukkFJ3tMhQRQGN5krieboeTFA7lLu/yLgC
quJkgad+fCV3kRVdGyhEgBHvmXeyc927/lvnCpcJ/k5KbWwUigOZ+d+/JmlK6FucBaIAIFkOAAJe
FM9D/bmwPqCpePlklEnWnD4rMdby6etRHja0GaC9JgstRI2gF2zoSTEd8Hbq3hNSzDL1SVMm6/cC
lWTrFAusifh7XwcKFaDQBBR9tNBOgaTpjv2UQcSlWqhXISzXCBPU1Qdu9PekhmI0q6zpF5POGp+3
4I9I+Bq7Sb4vDzbycCIsKb4qDocGOBl+CJroj+69VmnJpD56/KioqExcRWkjKqupw5iOQL6JQryr
oJ17sB2wL13EyR/3iDOxIb9eTBc9EwhWFm/TSTqHHNLgA0YEQeDKGGnKOd61T5FOTO5hICfTOVpM
z6aTAfYSE58xUI8JzybBycWNSXvcpZPCZvPTHcUIpNPnct6bDod5uqDrLN6QfWGA5zhY4jU9WUXb
Dc+JkOHX/BXsFqeDXv/LIs35w3+l8ynV5ExT8McDsvXX2F+DpA6TbJHFo+xfKUnqgLMiNIAp+CaG
uyQJ/rnM0sXWFuUIoCLJIDA8+i8uYlTwZFkHfs7TZ3iTfzYlvRrAGMGJ++PJF8o1aIqUHEIZb5KS
9FKeZgVgsRFYhUwHFEKtXcVCvZmaPmjIww2SY8ejZDliQhiPcRdMh0GORklK+woPS8w9yi9IwkNz
rdAaY7yllc4f8MQ4+hKM4vkdwjebzaeP2RhPhQ7W0bYyqXlBREnSCKFBI3BEdOBrkaoCQnx+Waqd
8tFmkkm4IxH3mmLfmWqSuXwx/YzTvyeM0Zi9nCHikAC7jyODBKAv6ZFvIGhDgnwhj0hwEmv6Rm2W
rpBg/2ZbSJPBXgIhig6sBcWmDYerGyoVlyKlKkQhRtMPYwiKWQg1ooYXSOsBNiSLMsK++8kE28+Y
4TDlEdu4/yVA5XBuFVgKteEXy/BPFO90RhPyMOmeDNAbuPsEYP4C4wP3D8S8AN5sPE4HGSoJWf6H
SLuUi7powBD1+eK1cDKVt/WDwL4XAVIqv6FR/NhqgFdqQ5/U37yBlJ1PEciwVoYsxMhMWJ5C/DIy
lNvS9CzYlZcXZ+97ndNfTrqXG2jyoQbkBv5e6L/vC/0nvpHNR/FNofyoRVq8l5We8EKxPHnfX+P+
iifBOvN2IP0F80ltXbyIRJWGHSoJfKIU5UHvVqWp5QblRDYoBUtRmwJd3UflYFe5u+JnkkIrJXKf
p/9cwhUtJDsYX3no/ECjZpGDuQbMQHwjV8VQSQcYLu4JvkuBDha4zmIeNMnL6RAQ0BxKjLuIYT8i
oAfwr+EJBN+ZhGaFEYS7ZcNizEHhfDqCEYSpIZneeOXCZM6UsyyGxLwp7NVi8SABYZsTpEfg9g/B
jh6opC8jGtSilfsKrzxYkBFb99qHblFQMohFO0dXkfBRbDmD7UynmUJPzdNxnE1wX6Yk4AiJRzzK
p8E9ucchxhwP1qk5BB1Gq8OKcl0UByQvcY6HE6RmQwwhUiP0i3OmtkyrxZSN0wY+whiOuL2kTND2
xYhhAUD3niHJ2KL4Ca4zapeGxMJYM6wRZElgxmMqq40Ua4x5PEFDAkc/YtEGKwgCoMhwWCtsTVyI
mk9I3RMTXn0FLMa6B5WcjcAAQ3hJHfAN6k9jpoXWCoZmRpsz0/Qt8e8IryK1gGYTrWGWA5eYeDIg
5tjfp++L3Zm1ta+cPBY/npmkO9gUJnJhHMn78ayoIBNC3Rio6COAZTylY49Yr2kg6L2whqUXvuJ7
ehi5+DozZA0FxMCKP8eou2heQjKwyDjY3cRSRDsEtCQ2+hgSWVQgfBjq3Q5EasI24AC3HVrb5eQC
JvSAIWlxwF0RDvX9dQa3bn1Onz3AaEb22OALty0HCC3DgClkSGhxMVp3kBosUh72jXTJgl6URwQQ
iTtZbVHlTxRRjO+DG8XCHXmcCXPyesJEGAc4c3zgGMPrS4lXX1LOAZIRcjDFcfSM6HjwD7iUCnTQ
FKqgfZwXYwJ6GeuRUB/KeKxgafoBG72SfAshU5Li5gYaMsSLiJA1bJeOpw+pbJhiFOzEQ6C9wdcZ
aW/pWOCxMWGNHb8QFNYOfcQWB5uv8cJgbU1eP2xusgEpYtef6sZE2NgXhjotYRjJdgxRwzqIJX1K
bqnjnU52g+nsL2hQWXti2uBoBup1GCyf76e56Db5gk8NBsR9iwb2D0GrsdfGpWD49lMyggf0BC5d
zEMMPjaX8CSXB/kou7tfjL7gctPBYB8L+3I2Q7W2mKWjDXGQ88Zjk42ANTzem8hAwpd8LcCzMB/H
IyQyMUzIfNYU5LKK54DrcZPfwOKTlcvIet70ju/b/hBs4D1hJJfA0Nr/qkEThvqo2aaPGI18bHyb
YdSUhlHw9HXwn2xPveJwauxqtiU/RajrNmzt0FzFPMyfaz3RXYQmY6iAU1UQRI6ygZKENSC8r7EC
L17Lc7WEvlC4a0JA+Cv8Ds21d1Okup8McNpXceWeDWr7GkMkBGAUuQt+LUyAa276sumODlW67ldN
tmLSYMEhTHDeCFGDBYsVbwjIiWjRSG4JZQxo/UFkg+4csnoJswliWJrjlxs7IOUc2ZNgt1arifjY
q2IpUgwBIrAKn2CZcCf6nvEKrDAWStlltJiVFUomuvyFnRcmvuZVgegmkSWB+2MN4qB5MMjSyLzm
kFbrurg2Xj0Z2CVWWDYypcTXboYgZN5rqEaqgfQtYsN+Oj1cXHBTDBIsPPRKqEZiDAACQPP5AyzG
vBLTeQJhK0ZeltqWdqgERKpi/wz6/iQIo+J2zjXhHMa66DwtgvcfnzSiRxyEX+jFx4+SP9F8mMPe
SumsHGosWAm58lNpO1MHDvewMfQqKYKq4GPc96dLWE7rr0jRP3kUD5sF+DhB3Rg2RrfoUxb9VjdF
C7IolZp2Eg3rWTFIjqpRJcQrlZwTSdG4IgLM2CPyYQdVqJnK6UlbXZpoZ5SDbHVvD4fhYioee1nY
zrzQHgOfCIv5mC3mLEoQzftCGK8o0ggI0veDR23zDdyQB2zGx+5u3l+d9I7fX+AtATn8goU5fFfc
cCThYWEP0kMWAyEXwQSLnV+8Em5sLgISqfrRNjqFqGG4VloNKcSPFR2uBBprWsmpvaSTIBYFhjXQ
qL8cfthtfKwH9EuxtShumDq12HP6Aw9rUrM6qHE1eKcerlBWt5eolhNi6E0ajpzA4045UUxyeve6
EupOg/fxYTfTvlHOGoWoQ3qPnT9dVwL1H9kJCFJKvIgaF1XDcjYw614EdFuIVK9oHpaIf0TLrxl4
BGZy0QmFToAjBWgpvzHCZFME5FWf7uMUjBInRHL2jx03sNLipVZsoVzP7/R9+jt6sFLfosdv6Fkm
YXOe+pM4crzhnsNWe4iXn+hLhNd96T+X8ajOE2DytZ2Y500mMUuRnvgn1twhVvP8siZHcBqChD8Q
ZvirMEfBG3GjBUBKtjRDcmKZnHH4Hqv9SHiEO/03HGIWEpOpAIJf8nscMMnfwy/5vRAaVoAJD8UZ
iheSDsXzUuJTYzES/MXh8U8hkVNDGSPfB/ZuUQLjKEbxWc2CGXfIa0qRHiwWkB5iNBqjyeALxUyw
Eeh9Ic6sg4PrQAhBwEhEyN1o2kdcxksRtPApJgcsrxQh3krpwKUXuDokvNlDPIIZns5ccZIgxtFA
ExODatzrmD6Co4YYGcSvSirBPhbRVV0yXnlg912Cid9wDIOaEIjp2r2nhkTx61H6JR+OlLtP7mey
whOp00CUcxFCn9oKFxCS4kbgXE+9FJMq4wNu7JUixpL+KqAKhS8CsMOa7LFwRFNXo2xlV2z635EN
f+VwplYSjmcKtbKVoEa1cDpTpJXMQMTIZM+Ko5pr4uAwYCZmKldwP3CcwlOosDjdg1nMvB9K8Te0
OHQBOYynIWHHKRma74yHH8WzkVRU14putxyLhE/CLXNO1CYlKhPJUV0M/IjkmnY+UmpwcUaSefUo
qeT0IvG7Md9gQQMTNX5IUeIL2bjB3gfqbGMHJQ0uMOOBS9YM5dDlGkfElSU/Evra6LXhrflBGhvc
han3+fevTfzlzSpOSLLy1nmkzhHVeHEqvOxFgYj4bzh/vsqibTpSyjUCPVG6ZhJgZz/J5z2leiT0
JLGQY3hprLJgfhR1nOEw6RpBx0+O0p/iooxVqJwpY1h5LPBXeR5VrUdsmN2li95sng6zR+xO3qAp
d8nAU1LxMsuLPEn2C6sW3lK3PdjNFIFiHLAjzkLKza1nZOog4itPZbR0gphEKxdPnBQHUAuyzYsx
kM3lAsLkmYxik25jjMUz1WJCxfXxWOCv+9yEYpLapuVSYvSJVVPt5sMG0gEQtlyRDowsaWVCqACB
sbVsxkBncO3cQkU46xUoirD1Qn3ORLP8+2CmUQ6tgjpmQg2krVynzVQn64y1YSa2QNhn4wBjsocj
+RsYheqqt91iy111airYaj49xRvNumiDEoBPS30PZ1gY3+EJVoK4h357jQ+sKTNBAfw6+E/+/ivz
UdHlyGvemfvFG9rv9PyPltHnVw1HQy/M1riCOed37OM0Q1NshtYmaNwhE1xdNOJtb1grYl9wNgkG
2XCYQpcT27nYSSS2ejIdjeIZiRLJ5gEdDeYDIgSyN08Hy8kgnix6gt1vOluu+L+4r4WdusCyQRxj
AEq8yOBuYqJIfrwmHihwB5qWmYp7yhKsXKYWZpCwQEElpF9R61BtbUtJOQEb8U/hGI0UqdIhjE5k
3uLLGD8HaDLrpzR8BFxwqZK3SRhExWxZeI7Y7MWTGnAdTdLALBYxhPZ8npKcULBskxPCTYMUIMjw
3cJIQ1iAjXg+NXo1Zh39QeSzpRneJ8eihkQOztpNhqMM9T4Ol4dIPIyKni/bgLR8NC9pZMQejCHq
op/KeEmVJK6PYELfQMQxpg3Il1eThRbPubSX1IxH0F448YaoHc+USUlIkRQ8R3/LJiVId3Fwc9Pt
HL67Oem9u3h3fXLMZim8AbZIjc0k0f94Pc0bhVowH2ZYQkAMxlNsFHxiLoiNnb0aGbTj2WNyj9bN
EiROMrix3apBPEvYaAQ4Lia/ny5HA2BoOpku7+6LwFK+bsVHJUiKQrpMUbJ6wbsP0Xb7436gfTgC
kqnRjADeEQSULacQK0ASe4JwE5ZA1kac4JJcYk8CIqQmTKaTVGrAZEry0vaG0+WEXd1pctY7cxDS
vgWY4Dke3iwxnbSSFy9EFZOdoM7jd9qiB1vpP7difmu76D4S78Gd57zMVfdJkcdZgQewMT6j+Vq6
8lRr+N6eav9CpjV8USuuCvpw35FkDYtD0puQDHemm1eFS13x2IH8ooAaS4d2o+tTiky89kKrFD5F
LDGSGBz3RqkIQ9wO1OfBVbcYP9YLwDn1EIth5zVidYTtBdPtzHYOqLUAAtZBiAPwDLiAn+t4SShk
UVQpZSnwvd4mtTosFoaGCCmM+U2uGTvLjNONkmtdub6m55t47swnOSsnJSLlLMKHYsWMvqIo0OdF
oaIHlAboufaIy5HHOxGJw+AB3FU7R7ZPQSV+vmVg3/U0GMZoSsehskycWDQ4RPfh+4GFqMqYIzVt
ZYLWZViyMcFCfpeJo6FvMJfwgHzxApaW3eOTqw3O1kxniXw5jBONwl4jOk13NDSQFy8AUZG8VgFw
JEwWLojGnQ6q35ndcXXFg2eV/6sVD+LACopHKFVN8YjVVVE8wM0/WPMwWSjRPEIL9HHhHrW4BizO
v2vUGtEopH2LUYvHnWvU0j/csSShp+0vbgnnvcfSa7PxmEMH4/9qxbUaQgcVv6ezdI70KIRF1ZUn
ofYk+ljkHCO7ScSUl214zMd6QP7FqhDnNM4tDiqKQ7XhiVZBqzPsGmJ7eZhPfosCcaFL0DAAMb+O
uDTWd0DISvcpKS6uJfddxYg3pzgPQV2GiNLZlw9htIf4+pw4HbmlH0NQzUBQNGJIAe842MoPo11z
lhEwfGeIb7gaYTiyLLJQHyzb4XXwIlA9n/h5TaidvKThcoJbkzznqfCot+t72gTTRhzE1fYm6Wea
LKxISgAvZ2RnRyMHf5fyZup5QHM53oozkdEOuAuvbOE4kN6yUAdaD6FRSbBaUMPgaLOfC44RMfXJ
ApaDJHsfCaYm2zYYvmbYtMEeYFrCuIuh8JAH2gs7K1R3KP5AIsEbrGZl61HdPBOr0c5baYJOD8mp
2eIUOB6sOuF7B5Qt+8JjPmhEb+vEtB3LThnx19J+K3Vqobd09E4UbGJEgqqvaVYNUZ1BiiwDowR5
Z3E1rAEFBRrzFd/2Gh+XkEmbROywypSZgKGQfcgGNWAA5GOOvaPuTsGduykDMDcr0f480xJ7rTCo
1KGDi0kYSKhGkaHPGkWmTQv6joVrSwJG4pifPqeJJdS9Au4CrgeGHQLWAyzSRcslzDUgyx4WCkcV
aeUsNlvwUsNZbbofK6TK4E8VeaMu9MbjkH4a9GPMAIHlh6h9IdE3CTRVw00NoaeYKJyWH6oVfmIm
FW5zrsaEZ+JoLOJR1VdEIb5CY0ssKo5ztazwTi1MeSxgEoWfBsNKC0htmDsjGQsBM9zxxPzm5cHH
Cpq/T5QHJQHYJv+yZYwwt7OSQN4WR4e9smT0kp1r9J2kh1MD01STi0/llvfRvjGrDKg6VAH8iYQR
hustQsqgPE15hk8Hk7csApe8hV81HodZQCEB6U2Xi9mSRK8RYOFhTS8Cpw4EYPyTraWUrVy1a7bV
pCQEI7ebyTFngld4yIlQ0GP2GGwi2rTCpgP+meGiAo7bcwTra1oMIvTH6Zj5SkO2NCgKkw4Ki/h9
gVTm0RUot6QFpLNCYdSXW/G27arn+Ey0aHrL5iDfJyfmNrHywN7mgoeXUb1MzLBQ3dAmJ7PRvF7s
j0n2N67XYoB/sNi5kh1KLSSnDQp+knj0ieRhoBF/lItESRWbhp1hkC2eQd4jZNjxJRB35tWLzDTg
UBtmoxE4JTE0CQrcoqeBaVm8txHDMWBcEWRUGs3u0RKJbH72vzBCoB1CggBuMmP+OWJUKYhoJ4MM
yhGqSH5FlVWUYaH1IGrFPCz0PJt0ldTt9rrfFFUDQjWuhcuDWBj2RcXJmNiMjAqPswkW27oAEVcj
kmXNh0HxhqeUFJbJrBBJ3SaMreKdtLlaWMrPWYsn8voLaz4W1DddSHdHSM2Fz1QNSRReiQcyhAhF
SRcozqAiRlEqrcUqijggTHG6kG+Q4B2mEfJhSqKLPgZSsllmo7u8GIRhcsZKNF+4bA5Mp+HshPUU
i6yMSBIzkmfafXxCVMNFpX+fFN/Nh6Pkha/UvZLRKRqYjcd1dsMr3b5XLEj+XDxvY3klzua88yiH
h4SE3sM4hp4fILi66QCO4S6X5WiECV0BJzZVLBh/NVvbgjUumN5aW0UvXQlEWAoRlUI0SyFaNghs
NinvCjVCdKioO+UTTnjWQ3+5d4nCiOEmolb1PHmW3yO4T8EGFmeX/cEGELdZca5lIXiK2n7CY2IF
koEiPP64hbUxj5kRXulb3bqdREb+C7GYfB2SqULB5oU8Omya3DABCxLFr5G7vLo47l2FvPOgsKto
qBaNarws2NWVqo2+Y0kIKlWJ1tqan0rq0niUxcIlGhs6DPXE8OiIjPmrirIaRftFHB3EM0QknuHi
5Ozk/DrYwOWK0VLbD168yBhvlJc0Lhch0V7QWtTntloYnoI7Fx3qKNvcpMCCjEjIyeLnt9fB1fXJ
u+NL+k4TSwytHOwW4pmu5tO7eTzGCZDR5EJtP5Y37vLqpnN50bvuHh13umtRo0FOSeHuICWC0RRZ
87Q0nnboUPx1PZ8ng2y+Xoclxz+XGczK8fxuSQJHyR6jhP9rnZTDx82hGGzVFCXIh5R7NnjGoB+Q
jkJ1r9cd0D9x6Pt0NMOoHdD3DLrBXjigG8DOfeHwmGgRUNpkc0C40/BVwCDCrQY+TDcj3dErFiGP
6SMygTca/DoyqZ5lHt+hmf20c3ZC7tdK43GdHZdZLHNW6ZDVykDW30HJV/iK4c2fgt+QvFFaPqIH
A/wAdwT83CRd+Rr9D4ThR8DJj8X0ZyWc0sGox44LvBTZwJso8zuIHsPh2c/RjwdGMBxpxrtVEPSE
6mU3ptWK1eJzQpW4acOObzBPWkET2MuAn5BGFEsvxys7AWhDbYZgPcFpBVi3I1nvgdCjoYWJB6yI
nw8/De7hNKQwHOqwBof55OTylM4f+edskdyjxnBbmM8oSZwrA+4VYi1vI8KJatoXFjNCMSThr+QH
D/BgTRHDmq34AEOTK4vpassEdq/W8u+4HBVCZGCl8zk0mhdDaiRejhZyqcYrDb3gNQfeTXD2BWAv
ZVNRAzbhQtFJQjnEDNugcOlQwSEASsTAMM5GeEd2OcHzNk6UGE/uUnoz9nSOr8Zmd8uihk2miDXF
9di4NzFmfO4XAcDMguFqjLzRNB6QNKv0inPm7sUvZK873xOkho8w2+W9mF55ZXrXd7wbOt5ljndj
x7tHx7sBa0VJkLN2Xpjl4R9m1D2xXEwhBXGCBuoXnvlkAJ4KqBASE6Cp6phkGksH2eJ7mLjkCziV
4+zim+LOTtNb3XksvBRXeawZljQJ7LWkwSGOPNicB2kU7w5bUTMdtFvwe28nSbbjvVYS9ptI8qaj
/CUej3fp/OVjOskWs5e45eCjireS7zY3N4P4ZTng2jka+dfpLAgbQbjzKtp+FbXR6j2MgheNEE3o
L168CBCCh5cTtOhZu7lfBv8nngSNMGg0XuH/gnBvp4GA0ee7v/4VPPitcA/9rjeCv/4V2xBidWja
QNbMJmrT/3fwTHJvkeiyo+nsyxzydSG0e7t1+HevjuhpNPC/If43wv+2cIFTyIRwPR0uPkM0/il4
Y2LiA+tMEoYTHGf9JRWQ4/ghGwTn07yfzhFTNm/QsA5+GMDT8V/vZ6Ot+9kW6uI3dLkiyd0MTq5N
h8Hb48N68PbgmiT5A/fZ24t3QT+bLBfZKN+iRd1Q+PgAzpufU/L3gy/TJY6UQsMCkjxgojEquEcc
sLxEWmQ8HdA7ucfIxB3QYHbYHeHpkaAekot+FFwt+6MswVjOsiSdIBWLTOAZPM3vCUugiI2R+0Ga
4bx8dJrAiCKcMXwjXgDFc2rr1XASP8g8zoErcKJo8IBlo71HhjA5aYF+kZTtn8GX2cfHLobLEeQp
WAQ/d25+vHx3ExxcvA9+Puh2Dy5u3u/jYCc0GwTpQ0qwkXhCEsmO2ogs7MUX4Nf5SffoR1Tm4LBz
1rl5Dw077dxcnFxfB6eX3eAguDro3nSO3p0ddIOrd92ry+sTyNmY8o4xcJtzeoj7C5qXLmJBNN6j
jqbx1vfxA0RaJmn2gJoOaddnX+z9yDBjLDE2NPgJACym+0GekhxQWGiPLq/edy7eEqcx0ob14PM8
W6T0zoGSIbQdopfx5NMIdcg1HHyBW1lOsyGq73Q0naKp7XCaLwDy/ACjakRh2NgMmzBQ310fcFfx
X7JJMloOIFUxVQZb9+v4BV1JHKwV+VcO0LAX3kTyq4iuTKTUrUiB4nTOyGQW1yf9o43H2trahnTM
aQM9w/uuaKGJ746BNS4v0RmPwxaU2lBLQbE3bwKcCwmV3hnS4k24e+bv3+FDtbYyO6RMk5aJdsrL
AF4o06BkNnGePk5ntxm72saoixpyob6rUNNU5sZZDyOuKRVx1lK0RyjyU1q5ltvqJSKP1jdbchFn
8y1lvLi8I5VpuYqwztwTi/zi1TESl3/x6hjgmXGIgTdUGWHjo7X+UbCB75zjz/AYWiNDSX2H5HYN
hFd/3ofnffX5DQK/0aBvEPCNBvtTuoYESX16u9a/1Z5F6GGkP43hsVYb6lB4rtV3ixp5q7XwF4Tk
Fw3HLwjFLwyD4EGZwZiM633olv7lDM2poBoIJ/q1Wj3YGKOnv2EG1cRyiE40aFDJeqKUxS3o46/A
jQSwEF2zxpAByG/AMB0lKBaMtT6oudESOtHDgasGQnusV0Q0rX9VVJxKK8NwenW3Veq69ano1lgL
jH5aUT2trQECz+rIa9TvKavZUi15pIrDDRonR0LVgV41qxmGDqn5JmY1HxnrhX8RNPyLSThSKy2q
VNnKK4tZZUc2ptrxx7/Ev/SLrjM3i3P0F14VDLUB562Nob+Qf/vm3iRVS/1ZH65YP+/boRcpRQ9j
RfwuJ7myM3pVEjIslxN88phYPWAwiy5yorZpGp8J2fTEV5sspuRCpeF8OiZRduQ+AcWve3J+hQxh
tISrk1zC3KkrViJ7IMC3i72ixIMCR2E3cWCPOImwtMxoiZ9P52DpS7mJxvE/+AmGmnQ/xK/r8WCw
Xl8LkAEojrRgYxffFkP/Q6z9tYtMzy5an3SbX+ukIV/rVZCEMpJ6cBTqiPJl340o1BCthqThQw1q
1qzlRhX5cGdSwp2mH5JkXIqmlDfTeSmOqAzHoweSZmkn3Y8MUiMgaYkYji5uotiFCPrJhqnti6lM
bvYEBnfOz3dX7O7GY1/ocCeisi7HqDxoKusxjCcqx1Pa9RhRsxzRePogI6JWyC4ZUuKA0EqDDkSL
/4fiMqlglqfLwZTchDNAevtznAeDFJyJkFits8B+Z3o9Gy/Fw1jYviDdMAOtOU9H0wSy2W0hHf7X
2WgxHQ7RvCScocPqIZcbwekXGBC2rDpTVS64eNOv+AyVD1HxojyfVjGasIr+BmRRKbLQH1nLjSys
RFm4lecSo+0tLdV/uKU++EJ/fOHWcrn0o69UtxL6PPCF/viAPk/+laptRp8n/8rxIaXrJcb6nG1G
5iXGvsi8xNgXma8Y+5g4uKWeYuyLz1eMQx+xw/T5ibEvPl8xDj3FzleMvfDFD3deYhx5jdmHOy8x
9kUWbs3jf3lwLvJsaeSDL/THR3VAGXk+tilFF3lQ54UuGc/CrfSfHtTt+agBhC7yQBf6o2uVoQsr
URdu3S38GluuU3Bjy9GF/uhaZehCf+rIusEgKDJp2jKkb8U398GnLUY0fLKJTLFhv6XYicg0jCJU
jEShYezgU5Dsy1FRHp5t7NUQcUJxqLkXmeqGNECjBSke1Qs3WLDReExUy/IK4buK7KzGyFJfZAji
KiRr8m5kRnZXmTIXssqUuZq52FpOEiwDLnyhP9sq4PPi3Ar0OZm3An2O9tLUU058YQWxm6RbxSq6
Okbr4Cpwl2L27mvSdg9azRhdtLZcgzk0Dxk7pS3XaA7NY8YuQy3XcLbQ5sRWmTZnS50DJjQPGDfr
KiD0494KFLoZuAKFria7B3VYdVC3Skd1CUr3SHEP67DqsG6VjusSlE4dhDrfrYNCffS87TacE1hl
hCBNCGkZraNyXeyk1s2IlZBXorwUdejN5bsVEHrSSiTCgxEWat2MWAm5L+UeTFHHtFuWV0DoKxFe
jLBT+w268HdRXoq6giyvgLCSRHgwYiVZXgm5H+WtEq6EJarOYolUxuhLbRkvyugt4cVK2KvRXorb
W6BbJYrIjLGaXHjwYgWRbpWqpd9Juwdfqihov75bTc/58mI1Fe3bj7+P9lLcVWR6BYzV5MKDF6vJ
9ErYvWdDebGIsAYUb6SrJPt2tsnFVY7rPHRNq17Y6PqrFJsfbQK2Sj4uDV1YhW0roHNzzhehN/NW
QFjJxyWjU7WGG51xMeyNsKqHS0NcoaeNC2FvhNX8WwLaZsWBrLu3ypE5xEf3b1nQ+Umj7uAqR1fN
v6Xh8+9io3urHF8J93wx+jNwBYzV/FsyvkoD2uLe8sZY2bulYa7S32Vj2o2xZG5emj25A+7G9Xca
IsH0xhb57KNUps25i1KZNldLF0urA1dEWGETqgpCP+6tQKGbgStQ6GgyEmsa6WhFp9n2DnRo1E3n
FhO2HGHZHO1BaZVNKC9KV9uDWtrwhlXHc4sOaB9s5RLZogO6Cm3uLZSqtDlb6h4uoXm4lPCuAkZP
/q1AYwkPV6DR1WrnoA6rDupW2aguwVg6T3vQWmkTyovW1fagnBoodHkOzevLqvj893FKlJuT1jJf
dXXcVeguxVxp+6kqPv/dJy8urLj5VB23/05DGUfsnkKzU6MqPv/9m3Iu2Gn9/b33e+guxVxp26kq
viqy4MGFFTedquOusLfgnDMqKuKWu8/MCCvs2pTMRyur4lZZD34DyktRV9tuqoqwkkR4MGLVzabq
yCvsKZQxpYpC9uq21TSbJyNWU8meXfi7KC9FXW2bqSrCShLhwYhVN5mqI/ee+RTvDnOPDVbaZKqM
7Dx850CoebIsCCPRuepE6EmhgLCaL0vDV2mzaRV8pRz0xVmFiSvgrOLPkrGpCqR0y0kbLd74Knqz
NLzVNpzK6Vx1v2lpQ2vZInpnOchrdGaVo0Py40Ko+rMsCGWBdCL0o1BA6G6we9BYNorKeLgCynI+
+iKtxMsVkDpROgf4SltQrpHzO3egyiituAFVTulK+0/4XJ3BHki5B9ffWYha7Yss8tqdsHlGRXze
Tv+JPeJfx+dH33TuiNrhSDW71U0kwmg303SkKqXlM48nzRWP9PjRbOaueyw5RDSsKqItl4yGVWW0
VSKkYVUhbZVIaVhVSluymDqQVpDSliymPkir9bgkpm70VU+oeNFcXUrJmrB0ZFV0TpGl6ypYK535
KBu6oT4oKh1YWQF/lT0DT/5U3DlYBWul0yt+XAlX4PpoVfxVfMc+/KnivPLvy9X8QP5cUZVWpQMt
K+CvsrfgyZ+KOwyrYK10usWPKyvJ+qr4K3mXy+aiinq9JXdmBazVzouUTHYr6/WW3K0V8Ffaf/Dj
T9VNiBWwVjv34sWVFWS9JauwCvgreZ89+FNFr/v35Wp63Z8rq+l1/15dTa/764Iqet1fb62m1/01
wGp63V+DrabXtUUl86akK2xXqEtKCy7By1XJ66Ghq+AcNiwnLeh8qTNaCzJOdSD7HO2w+7cUnDqd
K3k8NOyVj3h4UGzjbDV/h4C2+ikPh2xWP0fhFs7q5yjc0rnSGQWTzpNxVpJOq6vDgrNqX1s8HRr2
6qcVyimuIJ0UP72VUPjvV1C0jQIWAMmNhX+By4WGwUHxLeJf+0fFV5wSt/jZbcbij37x40Z4cSM8
/yktvt8KXyPxeyz+EArfClX/IgD9UsCMC2LHMrFjkdixSOxYIHYsEDsWiB3fCl8j8Xss/hAKC8SO
BWLHArGQQy2WfonvcP5d9bfcJvrw1vBEpIXPxfIT5TfNDWd6JiLDQvxN7i7r+95d1v9D7i7bxoUN
d5f1pbvLDle4uyzC/27jf9u4wJ93l/15d9mfd5f9r7+77LAh3FCGZKUhvJLfhFXuLjuE6zPoTWTG
K77IdU3SBU/HPvc7bUv3nd1XLnLlc/GUfKva1dx5Ixa930q6d+zne6+bt5pyGZ+bt5QiifMeNVpE
as1t26c1+IIv4QYo3J9ra6Rf1euhjtGLY+0erXv0tHOvPr6K0eMr7Yapqzk8nquPER/Rc/Sv/qKP
X2jXWiGW4BeJdt9VGz2/bRsusUIcgTusAvlinLZyhdVtW7pi5ypGVB3z64O0i3Wu+L06mHpysc4x
vUOI4bzC9+YAAPpzrOFPPPEnZfgTHT/uSLkRpvuJaH/3eZ1J0aYBq1O7oYiUcjdQIAANMOclRZ5E
4Ldzwy1FFnLwk7l8cVLbyBfjzUltRhElL+HkDQryUkaefnVS25dTElEyr+p3mDBYWf0e0hjn7ioR
aeBf5x60GLnXTeMYKAMmsn3hajdWGXqPsSt3g7UFpKaRULS2c1+IRl+4rktujVjN/5ILqvr6BVWH
v++CKmYesKm+S1QgkSX0OWzUdclDy3dkIDxGZMEd43/ZLTuHhjzZzC3Qn28N08/gCDrsEhy1wmfQ
n1tfQKmtZAQA9H0ovyfvLC/HyChmb0MNNbwVcIesOF0THnZ19rBb8Qy8wfXHmBtJPRjUg5TzhKwu
BVRXq+PS+FtgvZG1VTW8Q1OXJdPJYCufLT7RzsNcZp3PApXk7mAlCNuvvOHVjpZLqZ3OS7ESekXm
IpOFpSm6ePASxqY44B1NCR10WZpiKTKw90pkJm1g6xUHvKMpkYMuS1OsRay90rSRZukVB7yjKU0H
XZamWIpgmaRaR6qFbUQ7ipiIYzupFpGx1OSSTUdNLkmz1OQSHUdNLkGw1OTqWUdNej8J6sxDnzFV
5qPLFDXmoccEFeajwwT15aG/mOry0V2K2vLQW4LK8tFZAwfXdSEaWLluhnWRrsvawMV1E7id67pU
DqxcN8O6SNeFd+DiukXWRSPIrY+qqyJRC3mooeoaaOBqgUUYKimegasFli6rpG+y2KJyQosaoQWU
Li6BNs5uvIyFJF2QnCVMwyC0KBRawIjeCu1ohC4ZrIytEcYSZjUUWlQLLWBEb4V2NEKXPlbG1ghL
CXtP6BJLCxjRW6EdjTBKuEUvOUpYVJMQs2ctYSLMqJ2YiNiqsQuioxq7XNmqsYuKoxp7z9uqsXem
oxq9b+bpQlFYN7gIAm4Jpsn55XGv2z28Nhd2FCQL2OC3EgySBOqIwjIKCmk0FvaiQhxmCpawlAls
yBkLVqjexoSwlAnikDQW9qBi4JKEqIQJA5skRL5M0BSqjsjJhIFLEiJ/JjgkoVnKBIskNP2Z4JaE
ZikTHJLQ9B8O4jJQxBL66QRZDekIyqXZVrvPYHTWXjaWBq62+4wCZ+3lQuxou4/4OWs3SI/gAOVf
r4TvN8IFhtOHlAhWg3gbqYO4ga/8RF+/1oOLy95V9wT2Cs4Orm8EIcOkKyFpo/l83jchbP0ehFsz
3HYF5fZqKOfDzETgrgPbVbfzkxtpP/+81TChTUrQWnCFJlyD6rjSWWLAFDY0TIayD2NLo0IjrywU
YCym5oR7XliKAZHGn7aMsoVb0zk/fxeFYkSj6GyKRyPJE17nG7Rka6HOIzAP0ZdDQ7ZNEQsmwgOF
NXRTJYmNbiPO0JesClg8KCu8ujq+pjez6OzpgcKbJHszm97MKlzDHlhKKRs4JWvbk1kDu2RpKLxJ
sjdz25NZA6dkaVg8KHNJ1o43s6ySpaHwJsnezB1vZrkkS8PipyCY8aAgDKspLcmMMKLyHzt2iqpo
hhKKfEfzwM2jKsOvhCL/IePkURUZL6HILpeGDWtDdACOzAg2Ir6vTHaU68HNwduwaTAPChpnqp8z
bBhcPzPVB0ehIgUKS2g2nimQmo+H4DNDqjhldwaBDI00ystdEdKGk1IgABtI5esHE3AkG+tXhcEy
mc5UQydyGTqk1H2GpMVYLLTZRyXBI0roCFlxykEjN29vou3k/4LAERdzBNawIcT5YgseWRWfnc/G
aA+TM9YQ5OEE0/vC0B3GkA4HpBwzYHLmGgI4nGAGkXFULpNpgVSjNDyDMyrFZPiHYnhHYHgGXlSK
t/APs/COrjCpYntQRegWJhmvS0wMw9/RATLeCgEToXecRFgpPCL0ioowsVYJhrCBaFvaJsbrG5Bm
KGWry9QzSqCDDcRAlt5v+paiCUrbRvQIYvCOXfALWfCKVPAIUPCOS/ALR/CKQjCOW+8hq23pGYer
90jVtu6Mo9R7gGpbdMbBWTYuLR5YYzhqQGP2zVZAEe0pWQHXZ5c3UfBbkJoMgc/pY7ZQLYGIefkb
NndzUYy1XSxTssUg1ymwheOw+siFouZinlVLc2DEHXJl1bIZUS5TqU6NbteGhFDUXMyr6oGpd11b
GUUxublee3lynRrdrh0Qoai5mGfVht517Z0UxeTmeu3ayXVqdLs27ISi5mL+40iwEKLSXTqlnFx5
6DcAZaskKt2bU8ppdZaPAtXCikp35JRyWp0+omhqp58smet0ysNiOlNVcbNcFbNSTHjFImUSJNYo
0NoUNGpZSXMpv4qlgdosV8OslNxUPy0s1qgR7RQ/XtJcyqfigalXnbLLSslN9dPAYo0a0U6p5yXN
pfwqNvSqc8iwUnJT/bSvWKNGdOlgG5h61U/3cvkX1EOzXPVKxeSqyzQvF0OtRq8xY66xVPBVtdss
V7tSMa1GD/kztdFLgsw1GsRANrs1Q/t3WNm6D9x4auv312Cz6JPRVJ9GtvmcoHpGp9LscSOCskFg
K6KMOV5Q875O1blCrCZ0VyMpk22u723ASjPC0mZoqoMXtDRD0BhiNc5mDEy9YfAPcWClGVFJMwzK
nhc0NmNg7I2otBmG3jC4oziw0oxmaTMsvWFwEhYFtGY0S4VKVmnbXG07oWWqzC7GQkY0/C6pNeO3
yaCqkre5SnZCa/jtwmGi39XPZvyGXtO9DajX2qU2bqK4G5RCJXN1YvY3iEisM1KiOxyUcp6VCyOH
I3DN24niclAKVapVJ9017Se600Ep51X5wNjLLsMhUdwOSqFKteqku+yORHc8KOU8Kzf1sstySRTX
g1KoUq066S77N9GdD0o5/1ElBqy2S23gxOJ+EAv7CKdeq994stRaPiS00OB2qS2cWFwQYmGfLtJr
9ZMqS61OwdC8EKjYTrmKXqiGpFimTJaMfggRhwe5lmJ+VcsDd6dcPS9Ug1MsU6VOnW6nJGrOCKWY
T9Wqat4pV80L1TAVy1SpU6fbOQQ0h4RSzK9qU+86B9BCNWDFMlXq1OkuHXuqThaLeY8jUWHslKtk
s1tCLOshkXqdXiPIUmfpKNDU8U65Oja7JsSyHn2j1+klS5Y6PQ9l3PjFqIMLQVjs02g/OcJIJs8Y
p16CZuVYdQlvWIW8iphWilkvcIaVmKdEF5egWTl2XcJbgXl6lHEJppVi2AucUQXmaXHsJWhWjmWX
8HozzxTPXoJppZj2AmezEvOskmdEs3Jsu4S3AvNckmfEtFqMO0UaWrRV1Th3CV21cWanrKpGKaGs
igYwxrwXqKoO1xLKqg0vJ8+qjoUSytyySxBCrr15PEnugxkkh04WSjY/GpOrReTS2Pgd4r0v/Par
BMerjrbZFjjaxPeh8l4LKVXew3pQfN9U3msB9ZqzktCgwpjoUGFMtKgwTdnsufo9dwAcNoqvRYp9
vMdS/DwWrgS4L75fCUn5r+bFdyRF4o+++CMR8vu3izT5coXjosKxUOFYqHAsVDgWKxyLFY7FCsdC
hRDDL/wgkq88SMQHwq6T+alAj5Jb0PZcKoFHhAQpP/l2efgHvnn4B39IHv5my5yGfyCl4T9eIQ1/
SJLx/5l8/8/k+38m3/8fn3y/LK3vQEnr++t6PBis19G3IvH+8fsLwVnzK35xeXVx3Ouih8Wvzvl5
FIkPus1eJM+L9W9RSdiSK7FUgY/br9fVKhqGKvjJMhOe5P7TVu6Hpys1H9tafQtWOOsGHPi91I2n
D1UYKZB3YOVcBZwHcNecROruN0fatQnRBOxPHWVVHnqbc9/CLBj6mgXDP8QsaG+3zXbBULILTle5
nudPi+BPi+BPi+B/vEVQeh3PULyO57QuXsczlN+EwptIfhWJGPunkeseHnrfSyjdK3Pa8iiCr4jh
Rf7DUYJdxCPd9tONPUpIVHX7Veu4HjpKsAt1WmKJGw+q5NuBbn3aIVF169MOqeW3ri40toPc8uNz
yQ8v8r6cqqgt3wp0Gq0h8VJv2jltoact9el/rPX/Q33WjdeQHGhP++ipdrHP9XAN9af69AZhuNEw
3KKnt/pThPdWw3uL2nCrteG2LVwWxJ++X+u/N10gFGMPoHwrSazeHxTL15rESDjJWX5DOfgGjU1k
DPDv9VDDg0a4/XYUBR98gy4bmDDDv6eRjr9VEX/Lhb9loL+owXQJkb0NrDbtBiK5RcZ6byM3/0Eo
DPy/VflzG/nxn+Bz8P82MvC/G3eRgDNZMfOny+vo9lkdN/yyH+CZxp8urhGB/wZjyCBXNwaZvlFl
+kaR6f5/FIQaWNFnZP4HoxJokzmBKfoPk6D3yT1dppuFCswwZhMdoXJ5F+B670MoQQff3hsJJTcK
vdeQOyXCgF2XCAG9OiJROT82F/gtfCb4MaP/l9yENNRvQjr9fTchcduMrGuH82QWb+WQuHBIri4G
oeaZBej+02lIrkI+hf8NFyFjLLCfUQWHdauT0hRaaQq9adrKIyuWqAKWphVL042lwJP/c76wczpU
uWSkBeOw8NmIwcFjSo+Fy6HKZTs9Vh6HKo9dOCwcDlUOm7k7ziaEtWvDOtcZPG3HI7jxOHOsXY2Q
VMRgZy8mKHSiC30IIsy1I4n8kDSdSJrlSOJHJ3+3vfgbP1bE4OAvEOTg77YXfwGJg7/bXvwFJA7+
bvvwN+YCbEbS9uFv7BRgIwo7g2MuwVZ05QyOuQRbkZQzOOYSbEXiw2AmwWYkO34MdkmwEYWLwUyE
reh8GMxE2IrEh8FMhK1IHAyWnO4CbwQEBVsKliBL7DTqnfxH77Rp5E4/l7CBxVjgEznt5vIkvZOp
CgQ8YXW6ED4naaE/aWPwQ8N2j4U6D4WKMUzsKBwCpJKRSkgKFD4TzOMWSYtkKN/c8ypvLR77VW8r
3i8tnj8u7LUnXsWttQ9Ki8/i5JOldLRbXvnneGaru+VVemsyMvd7c9uz/NxSvl2udiYDW9PL+Y4K
J2Nb8XK+T21dHqWlZR/thYce4y15WGwN3dbUrjSTGEggOACBLwa7GmL0OIypXWkqstLjtKV2pZnI
gcNhSu1KE5EVx9LJ3D0/5i4rYChj7tLJ3T0/7i6d7N3zY+/Syd89P/5uLebLSeKypmI/HhNEdno0
NKVSTCmzW1WxpyhTRHbLKvaUZ4rIbl3FvkJdyvW+p2SXsV3DUy7fpXzv+wp5KeP7vpJeyvm+lfMS
rsehza5NSkrn6YJ1WMNEQYM5FSBkZAcJAv7bN821CBOmoiIee88R2kInbaE3bbTDrJiiCpiaTkxN
L0zJaD50cp65GyxlHbxmJRvugYEJcLCXOSisxDsYyvwS1rIOFjJ3hKns/Sc305hVgaPNLAgcnFOL
O7iHKXFwj1kkLkqcLGTmiBuBg4/MFtEQSDGBWwo/BATO9PSQ1F4p+l4oy1aZzuz27vLWNPdsZWLZ
GAirbQzMjDsDJUjsgjGzbA2E1bYGZpa9gbDa3sDMsjkQVt0cmFl3B0L/3YEZ3x7wxeDis217IPTf
HphZ9wdC//2BmXWDIKyyQTAzO1hDNpV7bRDMTA5WNwoHi80OVhFduf9vZnawikjKHTgzs4NVRFLu
YJ2ZHawcidcOwczkYHWjcDHY6GAV0fkw2OhgFZH4MNjoYBWReDDYskfAsXjtEcyMmwRuHA4WW3YJ
RHwePLZsE4hYPJhs2ScQsXhx2S3HXhsFM+NOgRuHk8tuSfbaKphZ9gpELF5cdsuy32bBcJaMZ1vp
Px2cbja8OE3wVEPiYDUjy8rsZsOL2QyPld3Nhhe7GR4rw5sNL7EGPKOFi92hN7tHi2pIStgNZNnZ
HXqzG/DY2R16sxvw2Nkd+rM7dbE78md3Wg1JGbtTF7sjf3anLnZH/uxOXeyOvNl95y/dzVK/FsX4
jdF5y3kFjJ4SXwGjp+z7YvQfBd4YvzE67/FQAaPnyKiA0XOMeGJcTqbzgatnmnVf/YRRVcPjR5y9
V5reWoqisndH01tRUVT2fmh666qJ2/LxW4xSRNWwlHB+4rZ9/NakHJGd637rUo7IznO/tSlG5DZ/
/NanFFE1LGU8dxtAfstUjsjOc7+lKkdk57nfcpUgcmp/vxUrRVQNSynPnVrfb9nKEdl57rdy5Yjs
PPdbvGJEbkNIklDPyWLisIRWxOct8VVQesp+FZSeo8Abpf948Ef5rfF5j4wqKD3HSBWUnqPFE2WJ
PeTn96GIqmHxIczeI37OH47I3g9+/h+OyM59XxeQKZCSIakS4zkzBXlyRCsEec54lKeZtrACbZYo
z6KdHt5jS5inoYklONQoT47B0fFC11sj1zie0si1WRG65onBNTqsoWsiOnfcycweuyYicYeczOzB
ayISd5zPzBG9xrGURq/NbOFrdhSlHDbGr4n4vFhsDGATsXjx2BjBJmLxYrI1mIpjKg1hmzlj2Ox4
yuXZFkwl4vQTalswlYjJT7JtwVQiJk/xLmV9aRzbzB3IZkfkIemlzC+NZFNR2blfGsqmorKz3yeW
TdhxCQKylc6OW+Nrtxr8P8B0FZZEP/Cdl5WwOYJ/hC0YN+awAp2kH9z4okr4mqX4mt74mG/Chi+s
2C/YRbESNne/MFeFG7N/vzCPhRuff78wx4UbX4V+SR39ElYfL9iNsRK2kn5JHf0SVh8vzKvhxleh
X1JHv4TVx4vgvrahrDpkmBt7FXzuzhHc2W7k/v0juLXdKP27SHBvu1H69xLSknyqd2jKsEo3EZwr
IiyddPjc78ZeaeLhRoAbZ6XJh1sDbpyVJqDSrgordhXBuSLC0nmotKvCil3FcJbMR5W6iuEsmZOq
dVVa0lVh9VFFcK6IsHRqcndVWH1UMZwlU1S1rkpLuiqsPqqITmW9ZdeqlfqKI8UJSVdA6jNbsS5z
oq86X7E+cyKtOmOxTnMiLekygvbl82CWp8vBdHM64yk14/70IcUpc4Sa71Yw15kb2tSSu8rmerlT
Www5qWKuu+msbq6X4atqrjvxrWCuu/FVNdc9+2UFc72s3VXN9TJ8Vc11F75JFb8DArgKS4Y+iXtY
BZu7YyZVHA+ehPp7HrwR+roevBBW8T14IlwRW0nfVHE+eLfcV515I/TVZ34IKyg0T4QrYivrmwoa
zbvlvirNG6GvTvNCWMUIYAidSvKu6rjxm2wmVawAT0Krj5tShFXHjRvhCuOmBOGK2Mr6ZoVxU9ry
quOmFGHVceNCWMlx5zMQ/d121XRaJaedJ6H+LjtvhL4OOx+Edyt6gUps/OpeIO/lzUpeoHJyq3uB
fHBW9QKVmOgreYHKca6IsHTFs5IXyIcFVb1APjireoHKVj+V/OC+6wB/R3j1VVAlT3gFgv1d4ZWQ
+vrCfc34SmqwAtIVMZavjCopwkpc8NWElZD6qkJf076SLqyAdEWM5aulStqwEhd81WElpL760Hfl
tNL4KltDVB9f/iuolcaXB8HVx5cX0qrjq2wJsNL48kC6IsbyVdVK48uLC1XHlxfSquOrbIVV2l9V
5y++57QSxvKVFt9wcqOvttriG05upNVWXHzDyY20RB8WaEdxnm9BLlOCDW4dYYdqxB0ryNW0ZyIL
l59YEAj1MwSupGWYFNrPEjZtq6+MHDsSP5L4ltxkukhfBcPJdI5vwgtITr7lkFyglg3SySJL4lFx
Ccb34m4dFBNjTen1O8FG43GXO27qgemQgIlDgK6IN/0GyMRIUw1duAK6yI4uWgFd046uuQI6e1eE
q3HP1hkrorN3R7had9g7JFytQ+xdElbtEjqQvuHwoBi/MbpvOEY4xm82TDjGbzZSOMZvOFg4zm+O
8BuOGAHnNxs0As5vNm7iwUA6owPoZBmvckQSX0/9zVBJJ3UUbOEK2CIrtmgFbE0rtuYK2NTxIQtz
ZXRm2lZEpg4LeVCsgC6yoVulH9TBIA+FKujGsy/aWIhkfS9ha5Vh+4aotLEQydNGVWyRFVu0Aram
FVtzBWzaXCEr9qrozLStiEybIuQJojq6yIZulX7QJgZ5WqiCLlaHgiC9Mh7L6n0cVyruJiW04Ao9
SVEFXhB3bwxNC4amNwZFsAVJ9EZhosGKwM1TRZQFQa7QoMiMwp+risgKAutGIS8lBhb7cm/Vpaxi
x/xudBbTcm/VtfHAYlfurbo6HliMyr3fYfV/y17hOL85wm/YNQLOb9Y7As5v1kFgOGmdI3Oyqh1m
MvxXR2Y0OXmPrIDOYHLyzlgBncHk5P1Q1eTUR4ks0hWNAFVz/T5kRnunGBrV0RnsnWJUVEdnsHeK
AVHN3lH7QWCc72w20KZnF4IyarTpea+azaNyW+B1BRTa9LznY/VwJDO+qtK7qboNPjOvqlbGZRPv
6ub8jC+rjNgqSveML6uM2CoK98xgzQcC37ykYaYa9KUYSggKrej8JHxmMOsFJH4yPjNY9gISXynP
l32zGy1eZQpE2L4hKrMbLV5lMsXYTG60eJW5FGMzudHiVaZSjM1o08SreL4wOjNtKyIz2jTxKm40
is5g08SruNEoOoNNE6/kRsvNyiauMpfmFRG4yTGpmrjKZJqbNU1cZTbNzYomruJEyHUnQiBIpTcS
Mx2rOBJy3ZEgoPNnr2qrCEj8+ataKwISPwbDUDAvjPqral/Twmh1ZEYl0l9Vl5sXRv1Vlbl5YdRf
aWGU6/Z4ILDOVyQGBkl3oSijyCDp/WqKRLPKBSTekq7Z5QISf8tcV9QESQWbUHdIusq7LEJdTXNk
vvagrqU5Cl9rUFfSHIW3Q9K24klWWYVPzCuelXEZVzzJKgv6iW3Fk6yynp/YVjzJKsv5iX0jKVll
rTix7ST9Dmy2nqi+9pzY95KSVVafE/tmUrLK+nNi3k1KKqjyiWE7yVW+hBhd0yQVtPjEvKGUVNDh
E/OOUlLBGJxYtpSSCgp8YtxTcmEoYazBa5VU0OETy65SUkGJTyzbSkkFO3Bid8wOVta8Js/s78Bm
1B+DlTW52Tc7WFmXm52zg9W0udk7O6imQAzuWReGUno0SR9U1CEmB+2gohIxeWgH1exAq8EyWMmt
arFYVkdmE/QVnLRWm2WwkpfWarQMVnLT8nlSsesHVUxybaYsRVFGkWHNM6hil/Pp0ojE0zLnE6YR
iaesP0J/jQT23Eakv9IVhJMgW35LbPdWZNVEiSCzk1ZNzh8R62WmCY306T2MYFkJg5OYewsqr7kd
I7ARUyKMhbcjHaXJQkBCUZSwg5aHFvF5H//3a+Mr+4qbC4Bf96HAX5aTQToMho3ia/Et4l/7p+L3
VvH9P4qv3Vj43i++XxcY+zcCzK34XYC/Faq6bfPvY4GEsUDCuCBhLJAwFkgYCySMBRLGt+J3AV4g
YSyQAD0h/RDwMvWsPmhpEMqjW7EIOx8lPLqRqoT7vKXfMnn4+g3lgVAAS8p3g2w4DDbnQRrFu8NW
1EwH7Rb83ttJku14r5WE/WawmE5H+ctB2l/e3aXzl4/pJFvMXmZxu7U5nSWb2Vby3ebmZhC/LAdc
O59Ogut0FoSNINx5FW2/itpB1Aij4EUjbDS+e/HiRYAQPLycLEejtZv7ZfB/4knQCING4xX+Lwj3
dhoIGH2+++tfg82w3mzuot/1RvDXv363+fJ5IFYXILI6B5uoTf9f51mAHk4HabCI+6N0Cw+Qo+ns
yzy7u18gtHsQDLa3BzcqIOT43wj/u43/beMCp/M0Da6nw8XneJ4Gp1PEy3iRTSf1oDNJGM7JYp71
l4t0EPS/BMfxQzYIzqd5H+4SmW/exJO74IcBPB3/9X422rqfbSXT8Rs6ZG/uszwYZqM0QH9n8XwB
GRXfHh/Wg7cH13V8lAvyK769eBf0s8lykY3yLVrUDRUAwUMgP6fk7wdfpssgQfydp4Msp0RjVKgw
Pjb2cjoPxlMkJF/IIxCdOUa9SOdjnu0R6nmbTtJ5PAqulv1RlmAsZ1mSTvI0iFFL4Gl+T1gCRWyM
3A/SDL2fBw/pPEe/MSLUD4iQjXgBFM9RPwJkDRH4JRjFiwK4AieKBg+CbIJh7qcz1K57VAv69QUj
+pyNRkE/DZZ5OlyO6gGCD37u3Px4+e4mOLh4H/x80O0eXNy830eQi/speps+pARbNp6NsnRA0MTz
eTxZfAF+nZ90j35EZQ4OO2edm/fQsNPOzcXJ9XVwetkNDoKrg+5N5+jd2UE3uHrXvbq8PtkK0JDh
HWPgNuf0EPcXNC9dxIJovEcdnSP6RgNy/m+eJmn2gJoeBwkaAvZ+ZJgxlng0RbILLUXQVEz3gzxN
cWEstEeXV+87F28RxZ0hnEGsB5/n2QIBTAGmZAhth+hlPPk0Qh1yvUBgi2AzOM2GqL7T0XQ6rweH
03wBkOcHGFUjCsPGZthsoGnw3fUBqhXOMCIVl02S0RIN9XWmDNBEjl8gzZdN0qDTWOsctFu9m/dX
J70OmgyFV/KbUHgTya8iwAgKZ4JEaZlAG5CMLRAj0tEgf4VpYWX7RxuPtbW1jY0NoKiHiiD53UDP
gqdwD0WtFvzwQxBGNaFE596jSNQUi9zEHkWaSpG7sAmlKhXq+9TTFov8lPi0piEVSX1qkXj2s5Nn
TVMtt5VZduvT+kii69an9eGeVCTyaEqzJRdx9r+ljLM1jGW7chlnc1g9MpubriI7Rj63nbUMKWk7
Ypn3PiMglKp579WdkjD/4jXO5CJeQwYIM+qUcZx/UlTK+GitfxRsbIZCNePO/RpSHOrTm3itD4fJ
1ado6K8RDaC966MXffXpT8kaGsja0xQ9TdWnPyNKftYouV3r32rPUF23Wl23qK5bra7bCD2N9Kcx
PNZaiIQbnuu4I0Ae6dgRO241Xty21/C1b/LT96jK91qN71GF77X6fkGwv2iwvyDYXxhs8fxy9kv8
C2Ioag8Mzrjeryf1QT2tD2vB37/bXNvoX86QLVQLfgsw0j75hhAl+Bt0xQB/wxxJ6Vf0Ho2YOkEx
Rih+A7rwv334FxX7DXOS/OnXbBTB6BeIqt9hsoLg99BFvqL+uKtCIvmTSJTeRreEOhhsAkUgNISi
WyAI1cJqQG/gXxUL0iS0lTUXIvgCYjBghKOPghn+eR9r+Pv++Pvl+PsK/pv4BtF15Bafoi7QDqSy
mz7rpve8l44MskMqv8F9cdMnbYR/j4yE3CZHBqFZiRhQCkNGliYvNrJQKZ24JtCkCkoTyBDlo6kU
QvOSUcKavOPaRMLU7mrif9saOqsoyBiJKJglgaI2iULzFs0IyDDi7DeMV6EmPl5hGiG8BzWe0lqD
QKkT8xjB/gYq31gzMTFVQQT3VGUaiHTg+WrICQrcNBF5uAubkpY9fXd2Fu4E4nQM14oOh41GOEwa
Z2dsJn6Xo2USWr5kk2yRxWgRi1aDkyU8JHY+rB4xDupdIPM28QGiV9M5XjFP0fPpLLhLErQGn47R
qgstD2OEc3JHVy2MMOyXCRr1Rh3cc0AEwShVInzPe9mHj8FrqO9Xwg1EdGdz8QUtZkUrgid6CTby
6RyWvXGSIOrQIyBvHP9jOqcekhpfSBEfZH+exp+2svX6WqdRpzIbbFCP4mMDeyIhJ00Ufq0Ht73O
Re/87NbgUJ1MZwoW0GwcD/PQ+qC6zyaLElyhL67k/tNWLiHDiHD5blQPbt7eRNt9k3N2PH1Yrwed
uirsuPwOc7Oydh2iL12Lx5n1/vnlT1wXMOmW8GPUcT3o14OkHgwKvIjOg7dhk9Mp0LiVzxafwIOM
sAcbnK5GreABg9rKxjMFMtQgAUDBFSq4KBoFjwo1MNIVGaDMdKmQ83ShtTU0tpVBUrwCsN5cAJYa
ExqbDCgVKkNjqwFQbXlobDmDNFJJgKk3F72SO6ijD9QmkWhU9NCwWSEVw4VIKq4uES40kMIdtRTS
NMfTybNFME/HcN/LFEkwdSXlaTpGqmX0BZyL4OKZLKjO3cypelHqpRr5N5EAuHEaP+aUuDZs9CaQ
FGXdXvfyBjeh1SppuMSvBuNX56pKsSYrdtU1FiOqRi8YxVDwoNuk7fQv2ShKokbuVirbjBi5qLxe
8l+Pi9BcMOTssZSLLOXCknItS7nIVS6309kqKWejc7uknI3Otqtc8q/HEG9xmkrulpSMrCX3Suuc
W0ompXXaSg7MJVnZQTpjBYONog8igK8HR1eX1200g52dXLRMpfP7OS+OVks4ER7bmZbwXNy0LeW3
lgKC9zSXXrFZTihHoxQRwlpMdQtSO4guuOm+3TpHNRh0Tfq4qFIBbqiNUBuW8NuQ6Y3eReRIxNJn
WEKlR3CvxtXJRLKy9a8KNeiUeuDh7QUd6YHJIH4iilAQ5L6Ohll0N6d0tYjXbJ2oLq+KSdJJZtIR
QvGQZFkjwYLdFqy6Au/R+YqYaSpJjlmZUBkLFkPMyzVUFSyxdKMRAUwYxNG5BeJfLP+piCVUsRRA
BaJQRRRPBhKi0EAOACVjCZUNTMVlqk9HpUFN5wKTdGuTVDedi5jsUAVNupFJa9MRGYBE2ik2Gxt0
lEZIG04T14woQ9FevTkVvh6dC2J92LnRVkDwkeVbkW62FGKDplCY2rBB+NnAAX9L5Rro4BFqsA2f
frZgAwhVKgwhhb0ANykAhZFkACxGiooz1HGKsBJaDbYYEAVag5RStIUgFIid0EbMZiIsiA3AdLRQ
tKGDt4U8UrQlwEa8RgosaI2wcuuEUWllG61AxG+HLyrQ8ZtZzdDr+OWxit5KP6TxenEgj9e1igPV
MEQRSmGIVkDKx6ZjVE5iPipRPcKUpHAV4CYFoDAtGQCLkabiDHWcIqyEVoMtxk6B1qCfKdpCvArE
TmgjZjMRFsQGYDp6KNrQwdti+FC0JcBGvEYKLGiNsHLrhHnNyjY+Kgv8dnhxVKr4zawuRqWKXx6V
6K30A0YlwwZJPdDCguRwx0asuIMnevbqPH5fWVVFiW4UM7Sw8PFAG1ZAS5aZJmrxvqCIOSoicAvk
NqyjClibHljHGV1LlyBtMKTMC1WCtFr7PZG2SpGG1SkNfXjKkUa+za/SUZ5IW6VIw4qUzuLkE5L+
PIeB5dtTDT+seQWskSfWVilWhQOlWJcTwBtCYLz/AAj9sEblWMPqWFslWMOVaMWjwH8MeHOgFGtY
HWurBGtYkdbZOJuE2PnlqwVUL44Za/xYGasXrVG1OcCL0oo4y+nM40FYoe1NHxW4fAxNE7WGr6lr
v/NDCHM1bZcsoe0eDTch/RGQGvYnZsRYWSvH2lDUlGWzBBC2XAhDmZ2lCAU3rQVdZfqiwn9c1uSG
b5PdKCV8fo0uRViZRr9+DpWhSKzH7d/T05VQ+nZOqCg3N52e3VMF6ch73PhMboDQe9z4IBR2DjwE
yIs+vwY39fnhyM5EvzZXwDmdJZNFBQmybG5SfCsc4+sUx/g6xbfiQNhZcbLuqPjauTcf0MNhLcJP
4YzeT4nwPS2+/yyguvU43heJZwAjCUqo4VagQjjv1n9ffP1FQPSLcJKvaOZYaKZ0CFBu5lho5lho
5lho5lho5vhW+Go7QhiJ5wwjCUqoQWimeOpwXDRzLDRzLDRTljbLY7EuvMEl/3ofK7/70m/qhBOf
NaUf8kFEGrlkeCSz+9udSBz7nkgc/yEnEsMwtBxJHEtHEs9XP5L450HEPw8i/nkQ8X//QcRz8SDi
eV08iHguvxEOIp5H8qtKBxHPKx9d8jkhJ5/C8ju7FkpFVjgf1nIVMR4Pu227T8gNjUfX2u4jcuaa
dvz4vMbv6oxHGdJPMHBQH9XkTntf+Yjaj9lk4TjWKZ7rE44kna/1z72ObJmPYZmPT7XQ05Z+qAqO
bLX1I1ttOLLV1o9s7aDHO9pxq7X+e/UZtHwNt99wtIoe+Qiqn/nos2Ab+6mPfuA896Gdy2iDlJSe
/OCHIaD5rsMf5DzUjlpLi51WCWxVtJx0tzSEaHjzzVknTnasx0F1ixzaMdTxXjyx4lkNPiJTHFax
14cPysiVtmM8ZlgvSxW2+Xk2IldGdrXxQSMAkBFLmHWeFT3Njz2RSoxcc9V0DlXJ++ZiTefawTJc
5UAU/HOxEh252A56kMiviqJVqXpi69zSrv8lp2/G+umb8296+gaOp8RbOGTgvCHEtvOQWnw+xbCt
Sgomo7lactuvpF4ljmw+XaXKHXtJVjabPMQjnFCMlQQtIAUtIRyGhF2f+45CkbnQeGgrEznKbFnJ
a1pL5fPRv0g6QAuFTUe5zFYutJf7gtZ/1nJNa7nhaJnfz3MroThhKC162ule36ChenHZu+qeHBde
KI5tNI0HLmRxFWREMrZSQaiUHqMuOb1VJUWLVOHmMxP41vJzvdwu7W7jkQuGgBybGzu6Xj7uptQP
p+W0wu/FKKQSBPiMXBmG0IyBS9NSQcBKt3g5wx7R3FZq21Uqzy2l2lKpq27nJ4OQzG2ld9yl1e5m
vQ12F2Wyz8kca1H38RpyishYEMdqH/E6Lc12IOATxBEJiLO1PB6NpkmBBGNoF1T3rk6v68H15Sn8
cwb/dNmo/Y2O2d/OL4973e7htYFAJ3YVKwna+80DuUf7SUzgdbd3tjIL9xiKd+fWrreV5bMsKr9S
5aGAABFg2GSYT/spDvExlW8Kp4ksu3G4/Gdb+T2/8qj+wFQ+lOrHA9BBghnFnjeK+eetYbwcLQBT
w9Qaws1SNByLBU3kheZzGZpmCZpskWCjwVg6SnFpKHZ2gOdOi3ABlsyKZViKpVxIyeHvbre3up5q
4J45PvxdOHC3dH4fDnLe9W+/CwfWuVfnR78HxzbBcfx7cGANe35d3pZsMSeCZsKC5ez4xg9LZsOC
5azjxFLeIuG0KSBahSnFwVMibCvh4NN5Z3UcxQHhv62Mg0/uRNhWwlHMUFjYqsxuxSFXImQr1b/D
DZSrdx2VAq5QkQ4b2XRYY4/pUZd0Aoo7K4pYQuFWqBhTbEXVr4RqbtfwjcSvXXO7em8M3Ch44Pl9
nN/beig2RyXQkov4zlaw7yw4i23lUqmcpd2L+JOt/NBdXvRT5MRmbwh2qSPlh1BOLUVyQTsThQwT
uZvAlcttAbaOM7FqqE3gatHQVhRkNbVJR7PFi1mYhPeTFuldOg9gMS9kbBjhQEXCf+4VDDZadbaq
fWzwJoGCMBGHcGxNFj54Qg88sQeeZgmeqAxHWN6myKdNYXmbIp82heVtapXhiMrb1PJpU1TeppZP
m6LyNu2W4WiWt2nXp03N8jbt+rSpWd6msI2RREYsITbWd4VWoTX50fVxGTZPZOem03IyOsqtMvpC
b/oYQk98fiTGHiQ2q5AYl5PY9CeRXH7kEpSWj9LMnbzjiMq1Zu5sIUdUqjbL27Xtozh92rXtozl9
2rXtoTrL29X2UZ4+7Wr7aE+fdrU91Gd5u3Z8FKhPu3Z8NKhPu3Y8VOhWqSLWtZ4Ji0e7dN1kQVTW
Ll2DGAS6tF17PuPLp117PuPLp117PuOrtF1xebtaXu2KfcaXT7tin/FV2q6+z/jyaVffZ3z5tKvv
M77y0oYl5Q0DNB4tS7xmMJ+mJV5TWGnTBl5zmE/TBl6TmE/TBl6zWGnT0vKmtfyalnrNYz5NS70m
stKmDb1mMp+mDb2mMp+mDX3GWj+Lczee0GuJDXjKWxd6LbMprpL2hT5LbZ/2eS23PdvnteT2bJ/P
stunfV5Lb8/2eS2/PdvnswT3aZ/XMtyzfV5Lcc/2+SzHt+LknyW6JfRarSE8Hs3zWq8RVGWt81qx
ebTOa83m1zqvVZtf67zWbR6t81q5+bXOa+3m1zqv1ZtH67zWb36t81rB+bXOZw3Xps1zunFEK7Pc
jUMReuLz8TQJnCshs4JDrKw7dJz+pJY6xpJKjrGy7tZxlpK6uzXMRqMSAfJaNgEeD7n2WjlRXGWC
7bV4SlhQrB1R5GXRYUTlLYy8TDqGrKSJkZdN59NEL6POt4leVp1vE73MOp8metl1vk30Mux8m+hl
2fk00cu0822il23n20Qv4y6hke0OPF7GHeDxaKCXdUdxlbXPy7zzaJ+XeefZPi/7zrN9XgaeR/u8
DDzP9nlZeJ7t8zLxPNrnZeJ5ts/LxvNsn5ejngxmYpgFgQudl8eeoyNtLUPoOytyM6cMoefM6NVg
L1d+lQZ7ufSrNNjLte/fYC8ff5UGe/n6qzTYy+fv32AvK7ZKg71M2SoNdtizPDLoKk+Xg+nmdEbS
FNzho/qLNA9Gg8fx9CGYp6Npgg/TS3e9ACn0/qDyCA5SiNNRD/CZ98uri+Pe2fHt+eVPRso6YszS
55fZJJmn4xTV0IebaO6yfJHOlTN/Z8edi6PuyduNpH5fM7EmxIShFc29wBcWV3d5fYOK19myRgmS
YriDDRYVZYyBUsFCDSw2gTUlsEgDCdUKI2OFoVphZKwwVCtsaSCRWmHLWGGkVtgyVhipFe5qIE21
wl1jhU21wl1jhU21Qhq1IQG19F5kPkwVTu1G5p9U4ZR+NFS6rfeksdJtvSuNlW5rfWmotK33prHS
tt6dxkrbWn8aKt3Re9RY6Y7epcZKd/Q+1Tt+V+/T2FTprt6nsanSXb1P9Ur39D41Vrqn96mx0j29
T/VKY71PjZXGep8aK431PtUr7et9aqy0r/epsdK+YZzqtSaGgWqsNjGMVGO9iWGo6vUODGPVWO/A
MFiN9Q4Mo1WvNzUMV2O9qWG8GutNDQNWr3doGLHGeoeGIWusd6j3L91xEsFCw3wqbCipoGoXC/tF
KqjayabKDXOrrXLD/GqrXJ9jjZUb5llb5Ya51la5Pt8aKzfMubbKDfOurXLD3Ev3OiQww+xb+M5V
SE1Xc9e1Cqlpa0PVhjnYUrVhFrZUbZiHTVUbZmJL1Ya52FK1YTY2VW2Yjy1VG2ZkS9XanMw3ACQw
w7Qh+PdVULVuwX2vgqqCxpyeIlxk0C6iT1OFVWVNdFmqsKq0Ges3KBhr/QYNY63foGKM9Rt0jLV+
g5Kx1m/QMsb6DWrGWr9Bz1jrNyga6nGTwAyKRnCoqaB673N/mQqqd75euUHV2Co36Bpb5QZlY6rc
oGxslRu0ja1yg7oxVW5QN7bKDfrGVrlhESC7bCRow2pA9cio8ObRXzhcVHijBjBTY1gmOKkxLBec
1BiWDQ5qDOsHJzWGdYSTGsN6wkGNYYZwUmOYJpzU8LmCJU2mL4UEKaUHifj5vnNbHgWEg7kjSvA0
S/CUHWJrhuW0+Bw+a4bltJQdPmtG5bT4HBprRuW0lB0aazbLafE57NVsltNSejxLFRgWlPFNkLkC
MQBdeWiHKodu8qrjK6Fwa56OynqhVd6bGE/5jlaz5THofEjaLicp8iRp22Ps+ZDULiep5UlS22MI
+pC0U07SridJOz4jkdLkkk5FlkqkvTK+0vFY1trQJKblVFbH6aZ0dyuflcZwNfs+/YsRefRw397D
xebO0fnV7dGPZG/H3lrD3g5h4RHfZdJQ9q6qI9V5qKEN26vSCmF7JTSHbUq1ZQdwZap7yIASk1ez
x0jSgpb+ODTBRmKOa/awBdmt1Ye7QVN7ONmY1IOcXxn863oynj0m93frf5msb63/JYebEOFDwdG3
DYbuL3+Z/FZ8z4lN6Yuod7UqonVqofpQFFZA5KSoFFHsSVGzAiInRQiR1Jm7dBQofbkL+JHu0nsg
bAOh4FkpYb4LBZBYDYXCdRsVGsNdKMxUlKGIy6nQesuFwkyF2k/4zcHZGXQUH4MhjMG6eG+38uGQ
kTdkyxty1wOyEC8CJbYEKTEWdyA+RkqsVqwB6Rv1d+9KfRK29Sc6FGhO7RmqUXsWak8i7UlLe7Kr
PpmUkwmNZqKCxQTMNltYC7YV1LPV5skd46KenFJ0oTe62Add0wtdVN7SPd+WRl4t3fNtaeTV0j3f
lrbKWxr7trTl1dLYt6Utr5bGvi3dLW9p37elu14t7fu2dNerpX13SxnCYbpI7uMB30FyIlWPH9aD
zsWRKf+UiNQZjcbRhiugtcekcbTNCmh3vVjQrMaCXU8WNKuxYNeTBc1qLGAeADcL2lWlgKwcy1jQ
rioFfEFahraaFPiwYKeqFPixYKeqFPixYKeMBQzxXboYbuXZndJ+GVvCUJ0aFBTGkD7OnBgGpRhy
Vf3KCNJSBAM3gqEZAUFREhCajcfpIIsXqSkitHN+fnIsLJZ5f2wbFskIeK/vGQ6KEfsEhEqArpBQ
CdAWFFoAlYSFSoCuwFAJ0BYaWgCVBIdKgK7wUAnQFiBaAJWEiEqAriBRCdAeJlqAlQWKSpDOUFEJ
0h4sWoCVhYtKkM6AUQnSHjJagJUFjUqQzrBRCdIeOFqAlYWOSpDO4FEJ0h4+WoCVBZBKkM4QUgnS
HkRagJWFkUqQzkBSCdIeSlqAlQWTSpDOcFIJ0h5QWoCVhZRKkM6gUgnSEVZawJUGlkqg7tBSCdQR
XFrAlYaXSqDuAFMJ1BFiWsCVBplKoO4wUwnUEWhawJWGmkqg7mBTCdQVbsoBfQJOJeCykFMJ2BV0
WgB6hJ1KwGWBpxKwK/S0APQIPpWAy8JPJWBXAGoB6BGCKgGXBaFKwK4w1AKwPBBVgi0JRZVgXcGo
BWB5OKoEWxKQKsG6QlILwPKgVAm2JCxVgnUFphaA5aGpEmxJcKoE6wpPLQA9AlQl4LIQVQnYGaTK
Ib3CVCXo0kBVCdoZqlpA+gSrStCl4aoStDNgtYD0CVmVoEuDViVoZ9hqAekTuCpBl4auStCu4NUC
0CN8VQIuC2CVgF0hrAWgRxCrBFwWxioBuwJZC0CPUFYJuCyYVQJ2hbMWgB4BrRJwWUirBOwR1FrA
+4a1SiW8AlulEh6hrQW8b3CrVMIrvFUq4RHgWsD7hrhKJbyCXKUSHmGuBbxvoKtUwivUVSqhB7vi
14I77XoBt7p7+tGwL8zHj8bjWMCPFjv8aDTctkAMlDeVOVCIp9UBmxJgZAAKVWyRBVuoYmsZgCIV
W8uCLVKx7RqAmiq2XQu2poqNB04qgC2dd0V4mA6rsM+CdFtnoRXptsZFC9K2zkkr0rbGTAvSHZ2h
VqQ7OlIW9KZA9nWsYlSbDi0NvOK1MPBOR9N4kU3uNmdTGD3gzlZyKwyNmd3bRcQcv+7j1J4rYmjL
x6ngCX3wmCL4FDzNMjyDskY1PRo18GhU06NRA49GNT0aZYxHF5GEHo3a9WhU6NGoXY9GhR6NSssa
1fBoVOrRqIZHo1KPRjU8GpWb70sQ0bQ9mpVbL0xQMHmMK5+R1fYZWeVN2/Fo2sCraTteo8unaTs+
46u8adseTbNfc6Fg8hhjPk3b9hll5U1reTQt9Wpay2uk+TSt5TXWjOdrRDSxR9Ny6+UJCiaPsWbL
6K5g8hhrpU3rezRt4NW0vtdY82la32uslTZtz6Np9isvFEweY82naXteY620abseTUu9mrbrNdZ8
mrbrN6+Vti31aFtuvz9BQeUzs/m0LvWb2kpbN/Ro3cCvdUO/yc2ndUO/2a20dQOP1jnuvlBQ+cxv
Pq0b+E1wpa1LPFqX+rUu8ZvifFqXeLTOlulawBP6zASuTNcKrtLmuTJdK7g89Iotg7CAKfJbiLpS
CCvYPJSLK4ewgs1Dv/i00m9l6ttKv/Wpbyu9VqlerfRbqvq20m/B6ttKr2WrVyv91q6+rfRbwfq2
0m8da0krLCLyW8k68goryLxGpTWxsILMa1CWNtFvRevZRL9FrWcT/da1Hk30W9l6NtFvcevZRL/1
rUcT/Va4nk30W+R6NtGxznW5cj1T1Z6yBCTmQ7ztupKr9lQ6MmIPTiauY47dHK7LXcMaXKjDxSY4
ecuLuHZlIG3vnLtuNbhQh9Mr1fbLietVBtKCF7hrVYMLdTi9Ui1ggbhGZaCGVmlqrLShVZoaK21o
lVLXpQym7YgLrkkNUutXc89qe+HMtSiDaTvhgutQg9R611y1tgfOXH8ymBaKILj2NEitj81Va0EI
zDUng2mBGILrTYPUetpctRaCwVxnMpi2kS24xjRIra9jY9XaxjVzbclg2n614LrSILW+NletxUQx
15MMpoUUCK4lDVLra3PVWggBcw3JYFqEheD60SC1vjZXrUVUcNeNDKcF5oquGQ1UH9nm2rXAXO5a
keG0wFzRdaKB6oPbXLsWmMtdHzKcFhItujY0UH18m2vXQqK5a0KG08LBRdeDBqoPcXPtWjg4dx1I
cHoMouQa0GBDM6xWvx6BKCztJUg96k5ZumvQmvCJCx0NWpM/MxUmy8FOhcl+sFNhsCIsVJhMCTsV
JoPCToXBrLBQYbIt7FSYLAw7FSY7g1rsMqDJ0hAscg3YIBXc4taADUJhIMFkcVhJMBkdVhJMdoeR
BJPlYSXBZHxYSTDZH0YSTBaIlQSTEWIlgdshNHCFv7UvdnKIH5MCV/JFaeCKnCrQdFIUkJSvzuRU
gRY8ZQEncq5AGxIPYpoexJQFisgJHW1IPIgJPYgpC/CQcw3akHgQ0/AgxppvTETU9yDImW9MQWaj
yrm0n8XZXA3VmhGRV2/lJNXhg81SsNZpZHdNzPhGfgm20Btb7IGt6YVtUNrMpm8zBz7NbPo2c+DT
zKZvM3dLmxn6NnPXp5mhbzN3fZoZ+jaTBUO5kLX9xdZLcNv+guslum1v0fVo7I6/8Ho1dsdffL0a
u+MtwB6N3fYXYa/GbvsLsVdjt/3FOC5tbOwvxrFPY2N/MY59Ghv7i3F5Y/v+YuzV2L6/GHs1tu8v
xuWN3fMXY6/G7vmLsVdj9ypo41Jkqb8Y516tTSuoY6/mphX0cSmyob8g+zV3WEEhezV3WEEjlyIb
+IuyX3MHFVSyV3MH/sLMd+Ed+KTAER98Ho2Wwkc8cZa1WwoiKZEbr3ZXsJK9213BVvZut7/F7Nfu
Cmazd7srGM/e7a5gQrPtbRe6Cka0uMldgtJfyout7hKU/kJe3ugKxrRvoyvY076NrmBS+zS6glHt
2+gKdrVvo0tM61L3h3/itY243q8ntcBEToj/Q5ZvX6GlHiTu8IYZTRfFAxvqwdFuTZV7diSbhzVY
oGIJqmmAGgjVNUl1YVuFketrkvqMYLEE1jSB7Qo1hpYad+UaQ0uNu3KNoaXGfEtkatvGVIWtbRtb
Fca2LYyVKt2xslapdcfKXKXaHRt7pXq3rQxW6t22slipd9vK5FioN7YxOZarjW1MjuVaYxuTxUr7
ViYrtfatTFaq7VuZLNa7Z2WyUu+elclKvXt2SRagUqskK/WmVlFW6k2tsiwADe2yrNQ7tAuzUvHQ
Ls0C1MAuzUrNA7s4KzUPrKwukqbwzWMjE+WUKXzr2AkbS7Bmniv127WzgQC7jjZQYNXUKgl2dW0g
wa60DSTYVTfPVcK3ai2MFTKV8I1aF2gsgdq6QKzcrsT12u16XK/ersrl+u3KXK/frs/1+mWVznNq
CNbSGZg8s3mKkwDLO0T4ESjDtfOGI9qUnYMxm3gEL012WoYnLMcT+eCJyvHEPniaZXjSx2RUimjg
wSBA5MWlgQeXKLJyVg08WEWRlfNr4MGvYbwcLUoxpR4Mw5jYSqQEWSnDGLLIA1kpwxiy2AOZH8OY
mDmxDb2ZJshaGUZPzgkCV4bRk32C1JVhNPHQrN48A9zPTk9ujn6UYtwNJJAZU0ke5FoBFupUrACr
aTV6T1KaJujQBB3ZoCMTdGyDburQTM1p4GrQo67MTEUM1Isqy1TE0ARRMZmKGNrB1Y8Gr0au6krG
VMTQEFGVmIoYGiIqDFMRW0NYt2hl1EBYy+A3lbO2SOggUzlrs4ReMpWTk30JAGK6r3Qcz+4h5dd0
ls7jRTad5HL0VnHPgJihX3AekVsGwFtjvPCvuGXAVn5QWl6JH5OLp6XFB67iQ3Nxp8vL09t1WmRY
M+VH2zGc4+mU3jMgHuWRMuU7D/NIkM7jPBKk/UCPlC3feaRHgnQe6pEg7cd6CrBQq3rXUnVoiLw0
Vx26DvcUYA2t6tRSdcMQcWmuuuE+4iPlyy855CPBlhzzkWBdB32krPklR30k2JLDPhKs67hPAVh+
4EeCLTnyI8G6Dv0UgOXHfiTYkoM/Eqzr6I+UR7/k8I8EW3L8R4J1HQCSsumXHAGSYEsOAUmwrmNA
BWD5QSAJtuQokATrOgxUAJYfB5JgSw4ESbDOI0FSXv2yQ0EScNmxIAnYeTBIyq5fdjRIAi47HCQB
O48HFZAeB4Qk4LIjQhKw85BQAelxTEgCLjsoJAE7jwo5EpYbDgs5MpYbjgs5UpZrB4YcibqNR4Yc
qbqNh4Ycybq1Y0OOdN3Gg0OOhN3Go0OOlN3a4SFHGnXj8SFHInXjASJHKnXtCJEjsbzxEJEjtbzx
GJEjubx6kMiRxtt0lMiRyNt0mMiRyls9TuRI5m06UORI5206UuRI6K0eKnLkVjcdK3JkVzcdLHLk
V1ePFjnyzJsOFzkyzZuOFxlyzUsHjEpS4+ZVUlSfunNU7yhuJgg4KM9RTddgZZmgi5VVWSpourIq
SwZdrJfKskHT9VJZ5utiFVSW+pqugsoScxdrm7LM3MUBHxVUS64sH+ExgMsyZEyv7HRWWsNVmNNE
lJ+GU4BKF/AGV2UxHvyclRK8h7tSgvdwWErwPi7LokAFp6VUyNdtKRXydVxKhbxcl0WJCs5LqZCv
+1Iq5OvAlAp5uzCLUlWdmFLJSm5MqWQlR6ZU0uzKlMb4rzDK+O4F/u/Xxlf2FV5+BcCv+1CAYjpv
FF+Lb8W16/3iaf9W+CpA3DaF7y3hezsWf/SLH6A3+K9xUcP4VvgaCd+bwveW8F2oYSzWMJZqQLqq
Kf0QQfHvlvJTqJwrOvGJ/gi7VdXfEgz2q343yIbDYHMepFG8O2xFzXTQbsHvvZ0k2Y73WknYbwaL
6XSUvxyk/eXdXTp/+ZhOssXsZRa3W5vTWbL5uJV8t7m5GcQvywHXzqeT4DqdBWEjCHdeRduvonYQ
NcIoeNEIG43vXrx4ESAEDy8ny9Fo7eZ+GfyfeBI0wqDReIX/C8K9nQYCRp/v/vrXYDOsh7u76He9
Efz1r99tonlFrC5AZHUONlGb/r/bZwF6OB2kwSLuj9ItLKNH09mXeXZ3v0Bo98AhsLe3h0ZFAxx/
6N8oOJ2naXA9HS4+x8jCOZ0i3mGXPJpWkAlFcUwW86y/XKQDmLlusvF0cf8l+DkejYIfULnR6K/J
l7vJElnE0/EbOjhu7rM8QEu7NEB/Z/F8EUyHwdvjw3rw9uC6HsSTQbC4T4O3F++CfjZZLrJRvkWL
uqECoHMIVOeU6v3gy3QZJIiNczSl5pRWjAoVHgOWl9N5MJ4iWfhCHoGEzDHqRTof50Abq+dtOknn
8Si4WvZHWYKxnGVJOsnTIEYtgaf5PeEEFLHxbz9IM/R+Hjyk8xz9xoiQEYYI2YgXQPEcdRdA1hCB
X4IRMgU4cAVOFA0eBNkEw9xPZ6hd96gW9OsLRvQZ2TJBPw2WeTpcjuoBgg9+7tz8ePnuJji4eB/8
fNDtHlzcvN9HkIv7KXqbPqQEWzaejbJ0QNDE83k8WXwBfp2fdI9+RGUODjtnnZv30LDTzs3FyfV1
cHrZDQ6Cq4PuTefo3dlBN7h610XGyQkyda5T3jEGbnNOD3F/QfPSRSyIxnvU0TmibzQI7uOHFHV4
kmYPqOlxkCBJt/cjw4yxxKPp5A63FEFTMd0P8jTFhbHQHl1eve9cvEUUd4bBZLqoB5/n2QIBTAEG
Y7GPnO0QvYwnn0aoQ64XCGwRbAan2RDVh9YV03k9OJyiFQWCPD/AqBpRGDY2wybsBLy7PqAmIdJk
yGQcLdGIXmdjfut+HV7AJdQDZElSgQ7yWZpkQ9TM280lUknB4stMNSxvGwH+dA7ard7N+6uT3i2a
poT3a9KbkFUzQfK1TKBhSPAWiDvpaJC/knH3D6HCjcfa2sbGBpDayyY5EuwN9Ch4GjQed2q14Icf
gnZNKHMM8LYCISnQ3BZLXMUeRcJIKjJ3FWkOSZmGWOSnxKOWSCry872TsiZtTFMsc9t0FdkxFmn7
NCbaEcu892kM9EtRZox7c22N9GqwsRkKCMfH6MWx+vAqRk+vYu3xHB7P1cc/JYH4QRxXIRBDUUn0
r/ritikXRb9ViDYqedtWH79HT9/Th8VjYpzQAwKITf3LGVLPteA3grlPvrU3khpabf39u020hFrb
GCOg3zAp8K8o0wTde4KvPqi5EMKX9xsDB2L4972EHYkmQq0QCtzrAxpW/qdEKnQVIz4ec5pwbWJ5
6DZCF+Y3oQz18EDEiYB+w90Cf44l/FhK5ErqqV4NFaY+rzMp6hywOlPGDlYvKeVNABrunIT6cGUi
8FsktkNPcvCTOZYsoi2xjdaj5pjwPe89fvgYvAal/ytblvTnafxp6xEtRG7JOr8J0stCoho4Cgwt
O961I3lpwdc1k+lMKf5eKM+OuzlR3CPD2Y0jLMUxnj7A2g/NHVhSScgDlOqG2Efxrt3SSrJOPOye
YckGZpORTQiRuhZWZsS7QQ4tsCPmN29vMOqr65N3x5ea+6M/H20N08/rda41UG2kccLiEEEJEA4o
wEXd2wwiVCDIW+vrMbL3WOlQxw+vxQq4Q56ua9BDjXFwvMnOOolxiGuJyLWGwDAB69XvROvojGQ6
GWzls8Un0i2cTwZec1DKz6tSQEP3mHqIg3PQqxJYNEBkcg1dx0Elcl2AJmlykaCQa4Md6NyNLFQM
VO66AA3kRi4SFHLtsBp3m1YqFO66AA3kNl0kKOTaYLHgqKPYJZOGIe0UNAW3U4BM6sLVJQpuZ28b
cDu7UMHt7BoDbgO/BTXh0hM+KsJfOwiKwakZBKXg0go+CsFfFwhqwKkHBgbOGTrbZ/j7j/yBiXNG
OJ1zBmnxGez+43xg4pxN5qgou8Z3haEtjmrXsK4wogcmKm2d5zeQByYqbSx3jV/JUuHfr4xmy22d
r1HAoDiWrIlDhNXXUPFG5DJN4tHI1zRhoKWmiYjTwzTh4B6mCYH1Mk0YaKlpIuL0ME04uIdpArCe
pgkDLTVNRJwepgkH9zBNCKyXacJAS00TEaeHacLBPUwTLjgepokE62Ga8F72ME0kWA/ThHeJh2ki
wXqYJpx/HqaJBFtZtWFEK2wI3hYbgrfCY+KqKH4eF1+vhG2+q3nx/aek+I60oGXDsC1UMpYrGReV
jIVKxkIlY6GSsViJvGcoVkLcCcJPAQVT2MIDYYFpfoqo+Qabep5ben/Iht5OtGPc0CPbeafLCXa3
57DZECdJmufYx59Mx7M4gX0ecZtP3+UT9/dC/G8T/7vts9f38zxbLNIJ7G4dTvvBeTzJUfOnw+AI
7/Ch0qMlJq4e/DDGL//c+/tz7+/Pvb8/fO8vzsdovOPtP/ObZJ24nxEdSfAwzQbBXboAt3MPQtCy
x2ADrb3zRZDcx/Pg+fM6/VLb54UQc9FQhRAzZFsPeiBbk7sexKtJRe0lxnE2IfD8hR0Y1NkoBcEv
oOuB8NVSJ9/HCuLZbPRFxMNf1ZWqodL0cTFH6hNxpNfPFjmChkrYP1bgAi5APFtO8uxugofbQqYK
/SZquYfGMegahZp6kE6W44L6HkxoCoLRNEGagG4VEEYKSNzlDfsOz8fxp7QnPAF5EzGKHDaywoQU
/6DdvUjuQUQE7DJKSQy+2yQvRaSLFHVeb5Dmifr7Q9hWNkqwNUW2r99ddG5653XhR0f6ESCba/28
01lHX9bQBNsoTpeCHl4Biw8NZ+KPW1L67FYrjf75CrGYa/BsfbO56Yv/3EDdOW9jS2hjuBIWHxpO
DaVPvUvLqGjdp76lpd45pL1zyNq/K7TfheXQgOXwsKyXYlcvHZbgPzTg9+EQpe6ctzFR26hQOfCW
pVNDPaelXBhy/GQJg61XMD7x5EnnGTTK0bxNlGTw/OqmG2wsZ9iWDZ5tPQNbIYalUA0eHZ9c3xDD
E+CYpRIP/rHMwahBECT+nky9SHVQYxJ+TJCSRq/nC2Zh0edEG2Fri5hBUBtWSWA9z7fo/CrMlN9t
OqfK2WLOZkukmRa17zaxSiJPkuA1aLTkHs0/BBI1EtRdEGRDhCj4/jVe+NUoX9lu2jgdJ4hvG4Cx
HtA6kKkA30hx+MDbD+wx0ofBs783nvG38BA9S4IXQUgf4vVlOqLGTlEdnl4IqSNk3G3I1ZiIGSlU
jMzVv3gdjIq60X//DxaK04warehv+si6Bk1p8y/MVCX2BVnFIKGZz9N8Np0M8LMpxnh9091HZt5i
OZ+gZRPwczpBZuE0zcEsQ5M0sn+V7sQzznebTgMGPWd9SCYoIlavg8Z+8SxF9CN2Zf9KEe1k0iT4
8lrwkj9XbRRWOkNlNwjaF4AKykT7xJAFsQCJGc/w33ogIv8A9W4G4cda8AaHJUm9yHkh9vbnezBa
aW0/vMbVGXqfCaq52uxj0d1EbklU1BrCgQY/4UYGlCGwta8MFCSNwr9+LRaglGYaNIdgTM+o9BZg
NubxFots0CWORV0QKQObVFowI35NEdGTeIyXp0jGkK3fuTg+uQWVgWtZXeRUCxhqwSOgqsBhRJhe
UdxE00mAqCB4nCDUvwWGD42PW/Cmh1+xfvjtt4J+JI0COBNSodA3E1U7kZlSn69sFuiQjJbjo0Rm
MACDp0+lEmqrAaPYx2u0LWu0MZub+/TH1//uYWFXxMUKigwQ7D4oPDe4hvODzkXv5OKGUgBKejif
joOr7slPvaPL86uzk5uTbo2UxQsDNGIuDs5PvsGg0laKbJSxBQaatR8KKHldA70jDz6x9/SVLoZX
BkyPCaOPQmYFZaJAUHDsoVRchRFljTXy4xYHyEsmeQ0d/05xygAft/JlHyQhS3OZfjoEFHzfm5qA
lX9JNfp4Uccc5aNcUJL+ym2LR+jPBAnTQ1o6SA7Ak6CMBTi3h2wSbIT2vwRcxnt4roCnl1dHl8cn
2D8nSjigQbYMHDKSZZqvvL/btLsuuPmK52zeRmkSKYDHcf7JwAul3MctgNuXi2IniEdRgCNF4Rzs
fTZcxGNQUFqvayWnw2GeLoKnQbvJRhSlF//54QeODuOnBOE/6js6gaNa6benwX8CEhypyQik/CcQ
YveeEG9OcNi5uQ4my3EfcRwpQlyTrM4ur3pXl50L1M1IxyLwy9PT65Mb1HTuuBxkOWlvAP7QL8Q7
y9Q6wvcQj5YQer8hlM5ppdSTKld5fn0IwnR2jRaOOSySioKIxgbo7QzcQmQTAKCJDseohtk8h+Ok
C2zvFNRv1RTRg3NRJg8Y4lYPL7FAb8Jv9Ib0G/+Zc7FDv5FgU7uFdAsrDOuADV4WzUy7ohItXjxB
LxQNIvnUpjOEnvP4Q1HBixcfCwMVAQJHEegumpEV9BIYFbiNEEQKytSonVCA9ONFHBDqkeBRoH8n
0vEK/5TAB+kIw2MCNnHpfXYgMKD82YA/qEJ4CSK6gcQ2eBoQiX3zhuAoCC3oR1ykCPmbPNiUHoqG
FH795rXOU5mMXUyDhauIrmh7u6ZVuSvWRzsxNy1K9P7zrUphFogaEIpwIB5tQNfiZzWD/p7jKUsY
4fEY4kGok2ABdj/4Jpmlg4wSYWhTu4dTidELw5kOlGI859A2UPg/HZxhiMurLdjmSgO0mL5b3ItD
klTPDSzMNaQBCN3pQJ0T5IFpHpPPpzNEhup9ns7EgTmdwbr+dbBNhfG5dSR9FAbmBmDBR0FaWr/i
StHKAKHRNIdIIa65Hgj9Smh5QYjhPZd/zuAcvFBnU6kziZHF3ngMG68YJrAOCB2hLx1YAaxxEnb3
RRToQVEE3uDge074V4mO6HfREbYxIcDl7wGAFn4aNKOd9m6NLBbYUsFOIFk58OaE7TKqmyrVqCRZ
hpBKIu8GRDInw0hC8ttr0hIrPVxxCD3eQKoILak2ZCEAyxJ/MYugP8VtgwxijlH1LfZFJPcF6Qn+
SuuHr7oOwlWIWqiLn+doDp9MJ5v/SudToj6gYrNngpoSI7QAQjoKV3F1dnB0wpdQxMbEOicjW9Vw
AAUO6ZkUiW0HSjIqZ6M4SY3bSRg5VyqSF+IDLoVsOlIDhka9Rgsocw/mTkOdP3Rkw1F8l7NiSCqw
R5q0uHca9U7+o3cKR6HEx2cnF/C83To/urjR5EXfYMIpRhHznk/DOvonKmSB82YY1YNhU5jDHcQi
Kk1ECgIUgqyOhoBcqD9H5iQteHGMipGRPY18gJsEGI2YcPMNHQY1JMVhnXfr0yEZqxgqkqAiEapJ
oaCFwwg6cNhkXguh2yyuiYJleLQl0+Vkgdm2htOd0KlwvERdkP5zGY+CdmsTA73CourLHdTF7VL+
mCSTvESj14NhiFgfjmHyBaaBTkFcg2gj0n4H90RVobtkYrRcEI7WSg4Z3FiYumGpnBPLRPKs4Aqo
NnFpCK6RaDxKHMymeQZL4qDw9GHTBqqlFhDeoJmkd3jpXCiwmBEJ8Rm00gSiMTAS8OP0IXZjOUEm
TnB0nyafEOWjEddkxTqJrGTABUTDMNLgPrtDMEQBzubZdJ4tvpgUnGuHnPdaqWaDlfVyPl/AtkYr
/MhXt2hiQfyRHsEksJhLj6AoNvKgGtmHi5sPPQeUvWZuIfEdaxx7C+85LSLmjxw1JcH8kpKsvmyx
FRpdKOhuG8nMDF4ba+HKUjHxpfUQlEBUEGaYyNmX6yRzpvgEptwmUP1r46u8xkOjsmeuTlDXzPIV
rWjZOMDG81NkcAilLIwrWiPAQtLqT9mssIiJUU8HazGKt/j2LNEWeNFHTWuqQwVubb7mCKnWEOqD
tQUZetRjCwVTIqNooOFNshT2SMU6KXLcm9RLIh/8DvFx74IGWOeGaJHb4CymLBfFk1L0M1IQo8/x
lzxAihbpgDENocvBiULSDxRhaIxashgC98kaKB/weyTLUTxHSmYAfTNEGgK35X4+Xd7ds31evLUL
qKnlBMXBv5dNlzlWHMMYibXUdra6MA8m1gHERn7Fu0KHfPGi0Pacn6/JTgDr0N1GTff1w044aD2s
H+MAW3+oMIkiw6FmuEH5dJSOvgQJUZBDcI6vrQnw9eBziuMZE46M7J7vYusmTZZYLQM4LkmMYcw0
4thCoKRoJvYLjVgcTT8jkGZRku/FQj+BzGzhU8zodWcovBGnKqrQMaF3U9ZlyOb8gsvhvtNK7QdT
mIE+I9VYD2AWkbqZqfq1YuwwXg/RigH4D0wH/L/iSqh3dDkhwk5SJuwXrx73aSswAzcesb4MHmHP
iZgtweOLFzUCQTqRVT3Be2j4QL5zEG2IIzl4rIlDaU1oR4ZrIWSjx2ylhH58ZYD0C0DDPhu3K1Ta
irEp+t0wq/BaJ9ipMccbKyKrG2axsbcFMZyMr7wT+PbZ9wyLyP+KtBQ1sQq+MrPx9ODs7ObH7uW7
tz8SMxGP0fAVe0/lEMahrnGxyTNBIlUIIhY91goRVBoMbMG9xUxTf20gKAK2diVrWuUhXdAqakJk
HCFhn7/jXPJgUMQZdDydPEODIZ6D2xnPU+p8AabXagyKPm4V4/IALEA0JEBhg2saNZArmXi0T5Tc
OI2xgYeM1TgIo01UPytPfZzc3pTN3A8fqaEr6i0aDevVP4z/4GP47Te5P15790fk6g95ju7gLYQg
3MYkp1w+48FgDkH7YpwSphi8i5QLgNRl7X+O5VkVTfUxcONn7OPE8ynR8oiXELwsGugUL3YqIBpo
5gluiNP5lGq3z/DfHGlyNKsgLY3w5FOs2nGMdb5MkjQd8I4QrZsNxro3EPmBhwB7ojtWiA3MLWMZ
cIebH3gmp3u6qqFMu5nXGrS3t3F+IKVH4z6U36gJHceGSnc5KUwNA4vY3ImnKBKIhHeIuQRPUmkd
VogntbNpA9/QWBiZMO58ge19WfZJuY9beMGCl2aC8cU+AkssxRnEvjKZKn4htlCiniDBiSN/UJfy
Ot8oCxhxMtC1O537zFTiHgR3ioiDvCTjWZmFNCgmE9JswgXE3Adyy5SFGvmyb4YS2C7wl1VbQIPV
rho2ZCxmORv/c7Ssng9GVDt8vk/pshzLk1I9qAC6ni7MXPgINnqkrxz429c41iIP1vsx0hPEiKRh
msSQxjStb0FbxEIRLoRefpGpJ+dQ1BaS8peicYcmgAxPKOKEw/cx8exC69vSlIpEvbxsYkqfxdSw
OZmvxX9wdDj1w4j9rij2Qt5kNSOFtYn1sbmndCXJIpOsS/linWud6OiCX/AtcXfS0ZTO4dinJITq
k9mgj6yFAdJcPFwBonJwX2JPsxp3Y4j4/25TPUhg8rqoQTeSs5lsnM4yHO+FO8dUEd4PJA3cML2v
oXEyGk0T9NYQEEeg6G4hQrX5Bsf44ajHARJ/HtpD32K/0GujJ5H7uAVcy3FvulzMljhIQS8kvC8K
8bAFHpNAX/A4CBUND9Sg5alPE+/COXyejY+GQmFJodBUKCopFJkKNUsKNU2FWiWFWkIh4nw3geM3
BSCSeR7bhSGKV0j+UvRmkmR42/kpGoziow9EPlmlpl3mY4hu4fvM+lCDtaawzyPZ052L6wuyz4xG
HvXOIgMyBi9PNmCWGwmIw1qqzoiA6HEySs2Dk8+y+ti0HhzS/KF8KjR5WDEWdt6IbefQEvagOKBb
3AMyBKxJfsWkbzdslNgiPlNTrYW1DpT4EEa7ssOxisFVlEoyo7BpkXjipsgC/2tXKIJFB3HYEG9P
9aQQiB18MKgWHjD3UfRgUpMz6RfTE54S+8iqDs3WZ0I1oha6JYXCitYja5QWsLagR8iymmpsSnHl
uMaPoL++J6cHRJsP2BAvGBvWt9aZu0B+YUBYM1ibqOGojlCsAHejqbFS4KPqlKA2p8w+Kyo5zlBA
g2nKFKvEvkYBcmEEoH/evFFDf4eU4dBCPB6Dp5bJQ1hziZV8VQanYUbH/Uk4TmZt05JA+pjYIapU
IXCH69DrNJ4n98UGuBSar8QW451w7E4tQvjv6Ta5GGPMN7qwzmHxxaIy9bJyrCcb5XMehEV0lQqM
kg4ETWdIB+0RHSQdOlkOh9mjsB+kjDd+LgQfz8GmClpzIXXmqV0J/oCE1+IX6pmmpwQENkRIx7gD
oRmUdxC0TJGw+eTSaFpAsIRZZCCYwz3eSoGdshbGYOWamOph3BNiVLG06zGY4iGLOwbXh+2wQo8V
I1pEocasUxNYiE8nyOjgh6HPNQ7Dp/Wd0HrWgStUzAt+pc3Sg7vFRgms1PQ/fylUUCAn/PvK5yi5
GnAsCA0SZ4d9eTlYXpB2B64Y3tqCkj9uEdstHhWtoKqyUGjFMsUVGS0rOdJmq1oV+CTqVrYaknSz
FG2B4cga0xBQQAebfswDL8xp5fEQOIePaMDRDelsBnuK9/sFpCQkwHhCg3ZNBx8OwT5mtBpL588g
uBGO7uVZPxuBowSt+7PJw/QTtZEhYQfnR40d7punoxQc2ZAAA5WfLucJqm2ZF5tVLGSSGMeFCnfr
brqYJrWZgPFBgXTCz3Gy4G279mclyIqy/t0mOxFbvCjWHS+QCUJ6Ru4YEqotTGPaMRmxG6ALsgXu
AR5f8b+pF2wT52pzZbGS+79m7mTrFuVYoTBXCk0nwP5LsXKRF3SVJM2Q98QsK0iXEOEgJ6p1mTOJ
jDAMcVqfjQ2cueR5jY82wkjyMiWxWF/NuSS4Uv4ii6LwHEdXy0dpaBcen1xtaGzlvcbY+dtvtMAb
bIYvatQRtSFZvfzApvQYTVY1FrAod4vQI0+lEmTNh1v8LTJe3ftlvLr/I66waTbNGa/uiwtsql9e
Q9Ja4X/buED1y2yO4wckb+fTvJ/OETM2b2K0+vhhAE/Hf72fjbbuZ39mtvozs9Wfma2+aWarIc7q
xyKpez8WCV3FZ2qmq+LuGwoM7FkimxwYFPf7sK+Fac1fsZrYLSiXM8flNPTelKZ4b8r4craG742Q
bhEhaPDzx1odgMRaTjvd65u1NSlAHB4Jd+z0Ohe987NbCYY9FO6APFDxwJPi/VW385P8Hp4U7y8u
0YOTYxmEPiygrs8ubyIZBj8S6sGJcpWa8DOh0TQEfs0UFy80SYzbX7NG9BcFzi+Pe93u4TVbmolF
2DuBUnL1pUIqeSh20UG3d3T001oRbE4eSABXp9cyAHogY7g+VjBcC2w9CoWXR6HwYld8sSuWaEtF
2sWrt92G8Ar9EkbKlfCmcyVKh/Diqiu+6HUvb6SX8EDsb6nodVd61TuTX/bO5NfvzpX3785l1jcl
rgnCcSiy7FBg2WEkvhAk80hCdiQiOxWRnYaipIovBGSnIi5RaE9b4ouW0Fyxjiuhjiuxjiuhjq5Y
oiuU6IolumIJkSqxgd1mTyqDfop8Prp614GnwokK9qgAOj5EXS9WQB4IADcqwI0M0FEBOiqAWkVH
qeJcensuvbpWypIHAp//pgCQBwLA+ZECgB+IAMcqgMJmpYYuqUBgNNJX26IUwm/h9cVNFIuv4bf8
uq+87suvE+V1Ir3elt/KNbfll21RPC6v2xJd+IEC0FcB+gpAogIIxHXOz0Vph5/yy5bytiW/3lFe
70ivo0h+HUXS65aCvCUgv748FV6iX+KrM+nVmfiqK73qSvXtytXtyi/fKdSgBzKAyqldhVfo97tW
oILoWN7t6kAyLXuxXNNeLL/uK6/70ut3CtffRcrrUH0fKgAtFUBuw7u2WkNbqaKtYmgrGLaVJqAH
MsCOwgL0QAFQMewoGPaU93vC64sjSduhn5L5I1IPP6WXbfmlMF7PDyFYQCxMnwggP8IDURDpE8k+
EquAn8XLm4O3oUg6/q287qvvBcbcvL2JRG2Efyuv++p7tXyiAiQSQLtV2IAEAnofgaQTtP79ve4R
D9fIH+IWae61NbcIcYn8mMawlserNlg2whtX3u+No9p/v5NEWd/RGBK85LovelN5LKzyfsi/5C8h
ziTfun8jr/8GWQ6JjukS8LtNgMK590+Pez8iO7/3Dq0geoedm2IrEHvWDLEv0ELqIMUChW88veic
QYgdzrKZjUbpHVpj40AZFnpZgB4QoMkivYPYzdEy2OhsgqPgHN+9WjMU6eAicCgcwFlRVMxW4BwX
GKfj6fxLsGFHfIjh+mhZDmefDq1wpxhuOJrGsL2+SZJqbpxa4W8xPHYo8JD/jVsr+PH7C1zg+Msk
HmcJE1QJ8OLdOQa+hmdflc4BxGq/4NSkpn7BN9xKuGl6WLFfLEASYy0wIlOh4RYwI08tsGcFP9cB
ZN0AQ3g+jr+AS4s1A4kV7V0dM3AUSgocxYfQ0OgksezYDQRMTucxOboFZ7P7EAI8ncV3MU2xSkLW
yDl5EodB8x31h4OXyWy5Kd6ZgEkoOm46I8mvxI7DGhp1HBV6hhtp2PN31zfB4QnxlHxfxP5Calvw
58eTRS63UVhiY3SwDw1hxNCaeXqX5eBfTPJBsBHPt9DfmqX40U+O4skDKZ48WIpfnV7bi8+GOS6O
/pqKH4W4KEkuRtoYhCa4XR1u14ivbUDYNkC+7ZJxczdvGN52ruh4KQ4AsXNcG9nM1JKrLi4xA380
BAkWLNiYzc0FwL+AC82nCzxMLKW30HsjhmtW5xTuwUCjASJ4lrlYODfXDQ6KkrJnuPTWyFb+3XkJ
gnfnBAOcpJWkmUOwaNZXRsFq0p7M5gOzbP2Fpl2KGptR20TmYSjOAFq59uausVTkLBU2N8NtoyxL
FEOi5/l0VIHaU0It2QpXNKeAxVCQEJyncH9gtZIixZUKtgit0+V8cV+p5JXYykLejaBSu9ywXRGt
k4CuhNUNKrKnBLIXmWE3Rtk4o3MJ0jWbd/OmMhzofOsaDOeUEgoKxwcHgznZ+jDQxlHDsZJ5miyc
yJkDjCRRny2zwQeE76MBkvjBMNygP7dC3RRQCytUp4DKHFBFjZm9RuIAIxzKrVDEC0aU1ic7FHaF
EahxYoc6LqCs/OryCudCfUXvjMdIpEGind0D/iuMZBvOi9KD3RvNkGaAwwqlZVRI4FTDJSOxZBi8
oAV3NiOjBsTuNr2gUOhVQK4Ua1pKJ5bSzcZmM0Sl0fJrB63GtvHmqHF+NreaaODWZmijm0z/bRPZ
zchYBnv49FLtpshfs8LHvj9XUaB0z1o0cRVthptN4zQBTj+iwcjpgBCXL2QJ2htYi74jaoqfLYgM
pckcZxQp4jiSUWyrKJoRkzBrTxH/koxnx0qKkYXEA+WDwjrjXl+SZcouLobsF8gpMYdTABCiYixw
JhYAIKSD4VTIyGSaX192hS4ucqtye4/pbWQj5wgHcSjYGLYr9vqunVlwbtjW/bvvyMSdjGet58vf
i0wWRBXLZlgBkRddJoxWhLsMYTV8FknbkwVtz8ixZnOz2arb5Q07lkWWmdG0N0NwTCEFaaVnr1+O
BjeqBE/YklRJy40IqVAXrh0JlzYWo+di61poInAgexeFiqIy6TnAFm070ESRSFNk13bQvsiucd9F
LYUcM6sQOe061t0uTrUkrrc0VNH/G7YZs5yI3rUVdd5WW2gpprSmrZEwmi7yGCvxra0tY+0XR02x
FU2MQVwivQpevNxEfYxGBHheTZM8uPrJ/UzGCbuB44XN5ZwTva0c3R0QqhwvH4krs5gqmsaSZNNA
0P6GkjvGtTKa6S20Ws0DvIkgjSbC3kV8B/4HaF5bHE1Y8VgR9b0wwYg0Wkh4w0EaRmTGVwmxD0Sy
p+GBAmuGhkPmyeZHKSbUSCcOJP/UBqeSbymOqNlsNTbOakYhPL49v6Ses8mXIP8y7k9H9eAOB6FB
SvJuDwMTOClHiGAIXr67uAEUfyGpNqijEdz8wQbzCEKA0/eMBNU7XETw9sb4ojnsbcQ1HP/U6x78
XBd//6z97qLfDpx5Oo4niyzJZcTXvYvLi5O69KRzfnXWOTk2PjyVnx4f3BwocBfXN1350fXVyVHn
tHOkPL25vJKfXN78eGJqBQvD7rGzxnOxDd3r3sHF+7r0u9v7m/rg3cXBjfKsHmAlEOJ9IzxvRE1Q
+mQcwihAOghNKK1ws4VetLY3W2gObu9shiHzbRbI+hhba3ezDbcohxEaAzsK0GFXIuDo9Fz+Det3
+QmSvG5XfXSmPcJVNzd36hCJuF0Pd+tRG+jY2d7c2avvmmg5Vog5VX/2pd/gZZV/Sz87CjYkBCfd
nzpHJ5iyo+6Hk8vOR1gioq+dn7ofFWLQul8qjlb48u/zI+W3zKcrxIGA7j0xmxx1AuKFUtFVd44p
EoAQoyINCvFOfIAZLnf3LcZz0CVHh7JJgJ9CE4k0KCiPaIEjqcBRV635mvQl+ksWXvLr7jVhKMT1
puN0ssCO1E06LBKE8kQ4s6BKaO/06to4vPKUDzF5YJ30LtAwPTj62wma/n58f12X3h1ensoP0Iju
nvS6J2/lx2eXB8f608PrK3ghP+yiQXrYuSEXVUlvjk7PTuQnF8ed7s173h7Els4EMjYS53Lch0jo
mGR84kwJxOMTSq6B4hVlAsJ4AWtIGpjMcRC+qmd+9mmR4ynOPpXlYl2TFM1wQ/CxooUj6y5M6L9T
dC5tx3MszFkl57DxiOhSmiOiUaYTCKEvaCyK8WnBhaAA4t8Yqi7zWOJjHHWcoov4+Ps0VRSMsyXE
3ecBqFzQVjgvCxJxVAXdTeLxaCdv8YREQ5LZdRx3RfICVOc1ycWG3g2nkPNFbYPYNQCzL8jIzecp
ST6GDw5gtOzigyJNWcEe4ZxGcv+Jhu2LKTZ4IkqIX0AVD1HT0bj9fI+krjjQnZHzbbDLvITNp3QA
V/7dmfEVuz7jeP4JTi7A6aMaw4kxcbz43RalrrhfkOCB6ApkfiDboQaaCYfBwwNkPLALq5DdUMOR
5Vy+6/Q8K6ZPxsgRdDECVPjnmnAxEK1OR0ltJv1slD7ocEZcaIxwXo4vb8i5uOf8NQYGOh3A9DUX
ALzTn75kt1/g06TTRfqSHHkiaU2VYcWFE85PXdRvIap+46L2ww9hWPtt47YmxM5fXN6cbBCA29qb
NwjgaeMxPBUgAAcGuIVXO6enNUrYQYDvBYZVG1wNPM9mC0QM+dqnF+MgYU3wzfR4o5xlIEQyhJqC
FB3uB2hCGifsug5IBQcHbmAhCEciEPwon3KVktOMqXRPjl6EJu6X3s2ny1nQxxE0c1IAH+v8QvbY
U5wgpZ8uPqdw6gQNL1aV2uXFtcdQB91Lhy7ENfRoDV/28V3GrydTVucXNEu/ZhUAckhFCX7rdJEU
WcPkMAvMKfyNpeWxaOxCMRQpbWh4AGTzpokKESt14eUrAf2V0EAZNdRLy1lIkkrhdSntR6FPXhla
LWe9ERFdcH8lSd1k2KWgdw0JuZ1MxCOJS0dDfCcMXC6JDRSkK5CosTNKQ4hewYeZ4IQOwYG1FU1p
D6IKSX15UkFcOSO/SCBlqh3yfmzRw2mZfHoXzTJxjmYB1G1zASTmBOBMVPTKXpzYc4KVPt6HJJmZ
lQbhGBJ8XpSfGQoKtYvGzWhApjHSGicuPPkjHSNQg5M4Q3FgCIyh5RjJ3BeBf/1iI7Fm5BXNocU5
dSDIKlt+4nyPqPQJqAM2YeCc/KDr2KSndhOd9PDVP19gNk/jOTufhjNa03YJETU5ZhhHVJSh3fIl
IOnTWJNplgIaeUfyQgutlCNveCUftj+KLb6ckIS5JG2WnJaKUA/n/jCDMzSTZogKLDT0UDiRe7oV
zU1oHgZBcvmnk4dsPp2ArY2Mn+UMbmKWeCaMypzelkQU/YBdqgQUQApOaGs6mn4uVJaUGIql+OLN
e0cF3HLov1bgYVerLpSkmsAjAi2aGFuK9nHOynAZtJQFQtCYP5H2seayDqDdAUOEWAEOzakeiOOn
ydY2wh9+aNTwTjAN5yIhAdmEXirBJiZxghbR8FNogCms0SggnEsZ0ut9JsPslkwocCby7NaKCx9V
AzyRRNEorkIQPs8GSJo1Em+TPSAz644mvsUsshUlh9igbKtoiNAK3IYIabXRFysOdlwOsGwXWJJ4
Qm+14HEZA3sTyFE5QNGWORrM8nQ5mG5O7e3nZ+ig+A4ujgVwjnTy4lVwGkGWk9OmvROkw3WAZFdD
gmAAS7u1iWCsmMRTd4Bnj/QqnDEG+wbu85jP+zht/NHpuZ0b9DgeFjAiq7MpLHeSOV6cw9kfrlOJ
vGMzbxwnc5ynWrRBx/E/pnM+v0BiKPnuFDpkFDo2MnLeE9+319xhJz3l9T0loZcgec0Fy0RwXiIB
v+4dXZMoNh5vZ9juxoCwll8T479sgGgdT8PvaPhKaYmDQxqD2M+no+WCXQ9hp4Ts43auNufpSLzL
RfSxcjuCzlUe9h2GtBh4+B1drli4HOB/qSKGFWu6CH46OHt3Aqs5MRIVmwnF1EUesuttrk/OTunE
S+cbPY6xuLn1mCVbnATpfA7ClCTLeV4PnuNbbEiiMIqHyvqAn03n+U/offXysiOJ0cQpXv8XkCrY
EWulQpLaRbwN0LAw30BL8zydw2VEjgutwOCsC1YP7lySm0Z4+hznRC3YfSIMLI3TeFVuYDQMOgOb
MfPyBRxox+kHUH88x11p4XbBIpFrFAh7hQhnufFKOS4wC/NU5HNVzhb3PFVgLbbQCGdF1mKOC7w9
YASTG+YhEz4RGDAT4J4Ciet4HAhbJlICnMWcoqX0oS7qYbuBtJ3nd6HjV7nTNpNqEqxHfs1RYU5h
HD9OPwfDWB5qiJejdEiv/C3SMOiKt0CMQcU8M5hkSOS6JoeCB/dosI+J4MQ0x/QYdpgQaZu4UM75
YjUFRYaB6OyTkNYsHXIvAUgp4Pmdhpms8sBLWKyqQG1RAgfIUB7HI5xKEdL1A6r79LH2yjQ/QYTp
2cHb3vHJUef84Kx33Xl7QW0QyOKjV8L58LuqeXchVBSS6fARElgaTN7CK6H+/hC2P4rzB542iD2P
1gd07SLN21RC2SqHXwYTCFcrkxUUrJD5IkpcvrIUGUBoRiClBQa0nrbFkGpI+J734g9AvidwVgV4
XAW4XwV4WAV48IH0j6vAc49sXc4an1vWX7ZET/s+9DgSGZO8a2su545UB04l5Z+Hat8xFMRlX1lm
KT4wpkGMSUiyObn0apT15/H8i7TmrBPtx68+4RtYNDkNODy0YzivRGG3T2SGqxM/KPvyREzIKUqY
CaTDeVDL7zhZSf7AoSHH2UoG9EckndqBMBnheKWRgq0kCDbR3I2WjJuj9CEdBQwANjdwHxyyFPqo
RLJ4XGwlJNfQfRo/gO+E2Yxq1qqo0dgJbuYZrBmCt8gWmCL19cPijnz7K0jl1nD+hlVzi+kBIfBI
BBWQe32KFFBEWhb+SaBsCaC4PvZNAgXra1IJxVhnWyj+OaGKtjtTP6H2KUmfcOnqiZ/EpE8YxcqJ
n7hZ+z8m8dNsPr2bx2MhyxMkgfrhfrGYvXr58vPnz1t3k+XWdH73ckSw5C/fIIqo34kfxl1k4xSf
wxXO5y4GSIepD7/kL8fIetNhs6kBtDjfKz+Hs1XK42EyWYyUZ8sJko+B8hAtBSZqXfH8bqZWgwyo
WEVIbHbl4V26QCKrnULG438+wqeQC2D09CW0APxWyVihTTm5/JdsCMeWe70f319BHMj1ZbdHZxik
dJCaLiy4Hw9+OkF22+G7t0hfq/VBEm08IbxkBUm15Dh8ken6MenhM31DSBD5HP1C9vZglNLrRIqr
VYPBdJwN5McPaNLp3SF7edGDDQKY4hc4D3MPKUG5NDwE8H3RdQlH6A4vAumzEb47g2RbrVZNBry+
tgA2FMDjQzNgpGK8sQG2VYzHZsDmngLYsQHuqIA3FkCtagtgqGLsdnrXP3ZOZfCWmF3q9ByC/Xvn
B9d/E2Eaj00sD9BLD9kcdeG0N7v/klOLJQcDCmkIvrrAuuQBzl6pD5/P4Ck3bz7PYS9jjnUbkRRR
UJCi7y3oPieXEhBGkHUKvqDAGxYhLU9AD58lKtqMelSCK5YBSvyKWAYDsgZYKlGexBM1wNBC2iZK
pl/NG4ZaKWdruGqWDZUzeQSyIF+rsXjsYS+4CRlpgtaCDfRw8w3EB2zN8jl4UEUZBF9qk9XM6yKr
hu82F0jxpoveOJ71WP4CWY6IGPEqKekyDOiTWXwHekouXaN3KuvleJZ4qBqVE5Kr0vvqcMXQmNuj
3tXB2xPWmu9f8/pq4s1R9IIpwFdTb5QaLydQDXtfL3B2fjlh9x6wj0YUeyHcHya02EznvgxL8CG5
AkajMZgiLvTmcPQ/MEibSJ2fvOPPVffyptc9OTiuFxzaNzII9hagcRqjZsRNt7FOt1MAFvCsm5hE
GcD7mH30NMYC975KosvoeRHQ/n4abIith8u4amJK47fpAjZH3t78iGxfiGnGWwwQHPUsR4blcAiJ
8yHrKJZrfrkjkm34Skz+G7jzbEjM7jG4ncdf8EvilMA3l9NhAaFAfFyghV3vYRwzXHVY6fWAiOA5
QWDpKml8j9LJ3eK+zhaAgsekh6PAcJxXMdyw1t9XdlmLcSmNGDrVC5rgKZ3etHEiTy1hvWjTUzLe
8ZWoNWO3nnQu96WuxJewCRVAdOgIts3fHUk+x4AOldesNkTff7IptN0Urh8hX/BdwBm5CxguZiGs
Q99fvJAapOgUGGgGrUbqfhFk4qUFNB83Hw4lDYYP6eoPGVyH9Xy2bxLqhiCvV3PoQu5cHyNhRKOG
XA0Ki0TU+8sxz5RLwj2yCUsOn7I9fo6A3YwHUk/EXRRSym+S05uMZc6AjF7wvcyJ5Eqi7CuOOHE7
zqqABAQxpiZ3ewx3296DpTFRun4DY9p8M5wBQ4a94XKS1IAoeIhqT+NxPVh/N/k0mX5mbX0y+Ptk
vU6JZuJR3EtFKz1IFst4NPpS54OdhVgxMQPnCvv+AsQILmuUuhrWnOCOh0VzvgLlpTp6/YDS1nh8
sg4ZYR/brWAd34csVQ0NLkVG2yKqRRwplOClKU5HA07xdBbDsQ+claqOb56FRes4Q0uyZAle6jHE
cGKXQz6Lk5Q5sMhUDSwNkH3yCe4SwNF62Gss+tX/zxJnTADBEi/SRZTcp49C+BJdCg1oaCm5l2MC
oLDOpw4MfMtrf4pWxW/RmgFvavX/MViOZ7BAfsjwLQxpNg9APDZQY0i95IwLTZFNCUh5oBEbCfgE
TAb3A6AyPUYnV+iVhoCfIAvdTORS7CzMNzqQgXEktJuSxUnH8xCjnLSzF1enPpDJp9WGjBw8h02n
SF9PtNrQcoNcd7cRkycIG/oSHNzcdDuH725Oeu8u3l3T8zWWj5OrGiY3ndBa+ItU+6gZMf93MQvL
lqqyRuJa/0G3UjEP2a2MAPGbBST8CHPVbilchOHCdilg8yNZDHPqmElP21vDhBs5gBTI/59xwA3Y
woDNqBRw+yPxRJQCtglgeWN2MOB2u3ov9f8QOfXkWOjbB5FnpzY/riCnYfu/V06r9tgfQm/1Hisj
m97bMskWPU25bji1bp1stT3ntssaveYw4HMa3qGTZjjeeGR85OmCTHh1SJvCLvcl82RhXdNpchQ/
wJbCa8xNapcviZnXoy/3xQL4vkECDV8ZrAQDbtMY7jmDfJInF8edgws0gfzt4vLnCwlumizSRd5D
hjDpx9dBKL0XWwiX9wg/JTjCKXI3MfoivROsb4ZHXzxKJSgwsc5pEclWl6Alm4WBGw0amWTVYFCL
agCm4twC0MqxN1IpJG+zUYya5uyfr2SrGwshZRUW1GDjtHN2EjxHFrHqzCRB1/IzkDvbmJwV/UcP
uHM3lHlg4AfjHj1kRWA7kObxuHN9cH19cn54dtLrXJxebgiQ9QCTSsWmkHwBZMtXPP6CllYNvThZ
4smuKP091l+aShHuTjQUIatpkGnEx31xL0ItYOrNs87NzdmJAfs4xsMXLdlfvoQxDL+xG3lfWtbP
EnxlHyIQ9RVa2+N9/ReEFnjy4jXpNtlzAQY/+EZfYwQQItoYwv1NbIYTdFiwgfsGDPFG2B49vngy
ePUkCdByEpf8Tyj67qyO8Zns140NEa4GHgLZv5LNTFbv06eUwteCJ5cWrNWCfw+ePX8WvAqeBc9k
NwRJwvCarGpIlATOIYyoqAdPBQaTYoK0wEdx4olOI/YBH/puD81pUrUGhgW/ar4+1RFDBpTmh2Ef
k+8MujTIUFP6dTjwpLZIRaHS9KQRPaKu66uwX91N+So15Wsh5JYCaPWtOUxxx/ygOcP6qHmfCu8P
1Wl8DwitaE6ODXtAwXakQal7QPAJZairqwsDsjDSoRgy2EhiHxnqoGuiK9jToEx07Sg1nhlx6VAm
XE0ZysiuIGirUCZUKr8OzLi2VSgfXOdmZJEG5cMvM10NFaqMrs5Np9v728l7A7pdA5SArvGoygSG
uro2URbpUOYNSw2qo2wkS7Ja4LpVmSpQD7kKO2ah0KEksvQ2dm0tlNrYNbZQbSOC+unE2kN8c08M
zgN1OKN7uDNsOGkbagL4LP/wERaxr5EqDoLW39ZBlQW75G/Ypr+DwMNTiICCdksoEaxH25UxBOG5
iAHRdF4RQ9iWMbSrYkBUn69/3ZcXRRuEl3C9oyh4aA6mL354Lcoamn6Vza78AwXcFBF8RBM0IY1M
tuKWLTZaqdXdW8zptnzdFI477+ErWIPni7m8n0PqrAfjGP5aNnf4NK3LxzhG8tEi8vHzIe0S7Y8P
V98dYfh3Ryfw52fy6yJerH/l1VMGvUbT+nzzTbbI8FanrDOeStqBNoi0jhWcodUX3piWFOpTUXXS
crMY04ZMPLVcMQk+laY7fB2cBKChQt8QEjr0AJx8ZXDUCFgPPjyJBh+DJ6MBsjiQ0RgQ2xH+NPGf
CL3I8Xvln3WJ3esYA4EFPHgbI5O7hLWONa7QTk+FSUAvM0cCiMoo2vGpqAj1Qg8x+IhncZ0LH1NJ
lCdO2k7EegSjxd2gM6UQtQKchQTb5KlohrgLqaw7KC9zrJYxtYiIMAzUD+TrRx2nNCKKGfmpPPly
77+gP9CKwCvIgyoVAyRObIHzQiAZf8qXJsLSV9s6xllI+nkPFlpIaw3HvXw6LLxN9A0MGcAE3pit
fj5D+lH8iQ8RwbqLeQwpnqIYeoBYIAY51dSxxvC8YoMsQE/4D0bJ6yeDOoTWviZ7ger+rEJTXXpU
11taLLq0NQ1lhbaqAY5Nh9A21spNaXGlsRYDy4RubGy0I1RuY4Nz+AUlFR48oCK14AmaFWvoOfzA
i9om/aWsSFgdb3jzHEsTieXBHDQY4/GTHCklnJkwM0wWnLoPnORN1ryPBnjEyydBE8cNRGiZuw6z
/itpRUXXaji2pwAW11WcUFpKkRgBl9Ck8FXAJWidCQB4Ug2wkRk2MsE2OSzW3gy2aYJtmfG2TLDb
ZthtE2zbTEPbBLtjxrtjgt01w+6aYPfMNOyZYMPGK2NfNIzAoRnY1HOgGUxUhKauW8wsImHsu7Bl
JsPYeeH2KyMZxt4L22bMxu4Ld8zAxv4Ld81kGDsw3DNjNvZgZO7ByNiDUWgkIzKPvciM2Tj4oqYZ
2NiDUctMhrEHo20zZmMPRuYejIw9GO2YyTD2YLRrxmzswcjcg5GxB5sNIxlNYw82zWOwaepBy8eg
k/sN02jtfyAk+Gj1WT43EAZ3x2igaFY2gKKnBqxzE12zuS9VWaFYXjwZcAQZsjRgHVjb4GQaY3A1
hEIl8j5Ivhhgh2SBP2ybTMj+/A+zIB19KrCZ9akCa5yT+8Y5uR+ZZcWkFvpNM16TVugb5+S+cU7u
b5tpMOmEftuM16QS+jtmvEQjqJ2Je+G/qjv/NJv+NJv+p5hNxonmMJ58AhcKbJ7N4byvbf5hkPry
UFDHT+npJtiBCwN824vlbQO9DbUmIFOONrbEkENmnAHQIE0GjH3UEJM+5ThFJQKwhi5HlqGhfoOE
IqvQAGgQTwNGXLlBhDhOlVCDBCFDU6/fZGYiI9MAaGi6ASOu3CCRHKdKqEGdILvVUL+h9chmNQCa
mq5jxJUbxInjVAk1SBQygw31m1q/bQI0NV3HiCs3iBPHqRJqkKjINJhMNnVkGkwme9qAkQwQkzxZ
R5NJpkzDyWSkR6bhZDLQDRhJ7SaJso0nk0pumgaUyepvmgaUyeI3YCS1G2SqaRtRpqUxtXs1h+h/
nTU7SOamyS6Zb6E3BsN/MbaAozcG8IfYNO8C+ENsWJYsYgt29Ma0CjEujgC7cYGU5cZlD8AbwTOj
HQDg2cwAPrQRj96YOJnNDbYA5mRmpia2NBa9MZGTW8nJTejHNt5kpo69tzb23kDMKBtYwNEbk9hY
O+rBwJrFzCbDi5kBPJ1mFnD0xkDMfG5yJAAx87lx1Yeem0xTWsJknqLnJqcQLWGyUdHzpp0qk6Ga
LR6sQ/fBMBbHNnD0xuB8GCcPZnrgjUEiBK4qEoHeGOEtPIU3hk5+6CV9URNjJQinbJCWjEejfpx8
6pFhrGrf+L9O+36aG50J8Xzrk1m0PpmXq6SASbI+zY1uBVLAJFif5kbfAilgkqtP5tUrKWBaBH2a
G70MpIBpGftpbnQ1kAKmtewn82KWFDAuaPPEQhJ6Y3Bn5MaZgWy2GcFzg+yKW4g6RZN4YRhPQBF6
Yxh/uVHD0svFdfDEOLrpZeIa+NJKzdJIzdA8MyP4oXlmXtj4j94YdJN5bqN3meu6A5AbwUcG5KkA
LdOSJkZ10ZvT6JfJcqyGZs+NES94e3hOgxdY8EiNhC4UsSMqYR+eDD4GPBwjeqQBGPpyH9NRVMCj
I2qu4AhrPARqAylHY72MHrs/TmUyzmUm3x3M+xAGgsknzXhIBWeyure9S3a1i4ZLXcgXAXCo2dTM
Qf+/sJkq7Tvw58XrIDLtEwf4DmYkIMK40B6Zj9TyZgN49rEOtUBksvAQHlgXLyvQOtBpVR+V0Dow
0TqQaP0qpPmFNKQ4tyaLZzBeHKEeoM//tc9ScEpRbQU2pMx6kJX0A8SgERS/FlT/uo60Rxh8rZMf
/ZT//HV9ORN+xAn9IZYdD0cMBH7cFz/Qtx0FOEsEdFlR7a/rs08G3BJdg4VQdiDWOuC1ioVzkfSZ
+GOQCT/yzFB20BcgRmLZhfhmvjAT3VIeJTOgNiLUZrmAYWxiaSa2NBuIlMfij4Gp1SL2ecaqRT9S
E3h/IlYlYn8Y6+BwpqUeNHhmkH11ewuy425YhBAnkdUzIQmRtdaCqthnJMSH6yB8GxRkvKNJToWE
AHjIw3EoUjsJDELDf7D5Bg+oYCApWniPFAJ6i0cVeTHY3OTfyQ1FG6EUcgSlNotSXA0gNfKcVqQd
vICXuAAE1YTBb78FGxs4NvYNDiiCe2ZqNV21FOoJhwMx7Psu5C40r5+M4KCGUvXGRghBlxhFjad0
YYW/yk0cwOEZYG9JWBNhI0Ug4JBEaFF9il7M6YS1mEvT1dZi7p6Y/z5BFh2am6/Y5PwQq2ySHrC5
G0ngbKREkAbrMb6/KRjjIp/SL1JMlDrzsDOYJCJxnkP8mPoMr6wshsCCGAJPOWxm3qoPBv8DGjgw
NHBQoYGDooFfWa610RQtjCGfEWzB4tOxNK0CqqOHs/YAOH6znPgBZzhNX+8xnfTuv8zSOay/A2vy
NKAU0hEWsCCk/AfhDE1HqKQalNICyukJ7fXpY1j8KKcvxwNV0Q6m4ziblGCBpkvkQJOmM3ltME8X
Yg4pExv4dy4e/MkWaiN8XjtyNO6rZeL5HRzJfg0NM74M4SVpovF99FE/bYnroc0awnXVhYxMZ8Ip
adR+GvgoqnCed+sI53CB1FuAIaDn52A43KaTggzpnNrddDGFo6hhoQ/JF8JboxAysXsqiRijHgri
Q29q4iicuhMU9MnB0dHJtaKi+XG6fIGmzXl9HfEwWYxIHnmc3n0YZ3Av1OYmuUwK0b1ukaH1Oeq+
bERudVjm6XwTJ6nBWYGDPF38uxxayqZ0J99xDwGjXnH+wEES9IfoAi0f58MU7uKAOzZwar75qIc4
ly0KQ4U9w9ykC2IkFYIRwgvR0+dc5XyOwSTBQkbK4RyD9syF2mwFGV/huqdgwZZSqF8hg9xkOKUJ
FslxZmGoCb8SfOC0waV2gWa4h16eJvRp8WxCHoaN52GjQf7Zl0WMVIxa0ltOZvi2CC2rnSpe8pFK
Lv8aJmFSkHhZkGC0oVS60PqepEbQs+3h86iEWeKoMhNqIZaiF4hlKCjmLdyYgcWmkYsU7dTMvOFw
tMzvWYSYaqchw/V0Cje74sqUPFYmrpT0VTkrLOxQe05tL/v9VcdmWDo/Sf4Oy6T1l5t///tv6x82
kORCkP6ToPCzunkziSfTfJSmaD58uqC3jwi6g3KGJgM15Tw1iQ0ZrjAwxVH9TZK2ltmlxI8iHUfn
xqntDJpiu7Lvk+VYXPdcpzj/BmTyFpc9IAC0HZJIYhMZ0UOsRpHjyzFNLUAstNxkl+aCYSp1hppR
sKhmUFqNbh3mgnkoVaMamcALsB/rqC7DKZDCi2k9Clczn4WDj3LAL+/hqxxfw/3AZ/KRNFkZbLDz
W8FTVgpnI9h4oCkU2UNNVzxn6RY3+FE6tBSTDoqrB+dqNbGW3yxTM6/6PxnovqZmWB5E9siY/XOT
T4jKMIBUZNhviJOTGG66UDISzpMxGtvwBqmJbLaOOSTqKlrhUzWHw74gcAZUs3zuiwuBliDL/Akj
+9sl+PoNX3T9ImOSnD5RTViJL+pAenfaSx9n8+DXk9urbu/wAG5rx1+v353Tb2eXbztH9PtV9/KY
OG/wMInhHnZcfoP02PP+cqhpujlcpqHUB99qHBG+pQRjEPAIlhV+VuSz6ENCTgSxL1kFWU7Mxo0N
yctZe94X3SH9Fy9oMcAA6Yf2JUHF1XyVW7icwOUgJU1UyE0KWwZVIjQQWsYU+OcM36qa8AGdxEgA
njWeBVtbW8GzvWevBB+aPPAIMakyHIEQkrxogVYXyBbGxD5FMtQwzfQpCBXmtSm7B5+V+zFqJ1yj
HY+UvBmKdGn5gZVZn7I81bUF7hrBZCCMeCEyADemxrtPqFbqJdxi6A8J07+VsrK/78Ng3rfiQ00Y
7lRek3TAupEkCzL7wKnMPvj5tQJU1Deep3AU/ln8DI7Aox8/oB//eob0uFmRM/gDEf6XcviGCL/n
hkeS9Kz3DNyR9MfWM5MbMsUdqItiH8rozk74cDnMBsjGgQtd5sEYjXa4wy0ewp0lqHurC6bSFZJg
wQeyxyKSgk1DJh0Y0/0PCOKjUog8FNZVBSF3OLWWONdpSW546cTII8DxvTF/MXzo2DeInzitTPC8
0keTyiCC7QlwYeGpxda32M4sSmVyKWOHGcxfrT2YYl0diM3Vh/XTB2vK6oLP5g5nSGWr/TkWu2fZ
szqz0kFz6E4b8cPFkSZOhxunSGm224dtary1/sASwlYl1bBcMphaBkjVoNaopln2aD7d/1p9vlGi
z4teJ0YF0+XU+gDzxJWvfFNWmIBNmXih8LPaMz0ZPuMO0ysIyMAaE1uEBssWl6WNIlcG6TBejhYC
U7RuYleGPXuSPAPBAsakOdzQRKK+RBJV8kTvoGT8fQvjzZYjE6+bmJBq7xhpio1kHe4jrb/1vjZ6
hexWF3x0y6sQUsnoII82xUecXsSF4A23lg36yDJiDUIh80AQfmBBWJjkNYtjxjZesY8Jq7gXzwzF
oLNevBb7hX10UWbwm0Z41d1D+Pa8jG+wnnAz7r+UdfJbaO1zr9bq4xg+dEIuss8YmsceFYtmPEDp
/Qa4SfH8zrUsmqe5OKaeCzYleQyXC8dgf8YD0Gx4kSRmvl9h+cS0Si6snygaVD8yGb+vjo1eOQ17
AMjAwXfkZZN4MVWdUwhDgeA5wiB5iM2LOsIjEu1kvbgHv4FUjug3X5nih7ngHWQPta0tgS3U86qV
tXkWn4pVf4AfH/196EotgitW3fOgi37Yc6M3O/waHJ0f90663ctuHX+9/Bv52z25Ojm4Id//413n
hkZsUI9jMoVr5QY4ykKJwdAijsTH9+mIezoUSjaeox81KuZwVxJ2te4LGzRKCTRG0Pc5vZw9D8Si
nCZ62gTS77DMnLJgkDbvy5m/jDXlqJqZuRYqubN8vjUg15PD1wzveeWfslkwfUBrFHq6kegOfBG6
INj6hS6/vWa3r/3G7kL7jd51tm8r8/R18J/kgjVBejQpZFfCqQpRYAmWCGlylrawGIY6o6Gm7SBy
CRUKrhtsFbE2qgBdXad1HhFUnw68m5p7TzZRJnTvTtA3+OYubUWgTjlPAQwN5Qm4WgxTjb29gvKc
oHlRruYbyBaj1nhr0IYkZDeHTNoOTVvXdqlT0aiGs1W+dbEWSfaW3RIuS5K1qkh7iXU5ERyVVTfB
ZyKGPP0OqU/6Zqn3FggiB/S7ZCxb1c/19b4L7DeGTln4VersMvXxv05ngRXxzyWql+wel858AGvv
2u/ZBgLRSusE6bpoewmVCdnyBTJh3vcRsTS5t6jWYlsXIg7ZrK5U4zf9CmncWV3ILhac7sbbCqnn
Cd7LL1JkvdAtM3pXlHATA9b6gN1D6wMY0vrEd1RF8ZdU5KqMEW+psKRSxV8RyIUtjBEKmvPXEHp4
6c1AdHxRhOytLgP++gxfE/WHCEC03TZCzv6UC6NcFPwS99hnFGA/mCESeI+jXy9eQ2ojdac9Eygo
1AV2o75COmMmql91Ex9JpjEzvXJL4NhySyC7IVAsKgSi0ET0GXhPdiGd/yZN519HKC1BzaajI1+/
+RjAVp55EFil3330pqUG0+qXTMI5mQjuGPtIdgvQIt8CgA+oqLvV8JFDoHCgCYC15EmYsXAyDeKH
OBvF/ZSUDLBhm/+92pxccWRaF0F2bohsdrMkaDzu7gzFT+PdmbGkaCEfSiz7Pcs5PJBNUQH+8/Dn
mPhNq8ie/AKiSL6VUA7KhHLwBwolYcV/q1AWE4XSMhpx1BQ63VopwK4+EgZeI0HtB7RiZNfBkgAk
OCmC1hwbjcdkhzzfbtf+G4aGsdd/hp7GHQ15qlANJMu3pccv/1Z0d7k9k8INmT4DSgzfs3UlPhhb
TXyAqB8UcTdrMQSpbmxbAbnCkydBLoek1l2pVni2iUaeFf/Al5CBHyGmri48KOy6Vnx1d8Xx/b9E
mYMNb11Q/ZdJ3xurtv0jOkMTUuy+kq6m/h/TP+nkz+5BA4d3zv+kvsFcqGAIfduJn/fBPM1fBezm
M6TnaL4Euh5ni3BtsSG2kR+afRzFi0BtA7Syn7HTJIZNHmmTRjuIi3GS41nDUXxHDpLTOn4Nbk8u
ep2Ddosdcbvo/e2ke9G7vr45uaoH63jPZZ2fJLbC418Q0QT1eMDfHHYPLo5+RCUWfSSyyb27zMnt
TefiBkEjMUPsKAM+OrkiwEk6KwP+6YQghrQ9btCrbuenS2AKHJublnDl6uAMO/1GbrBrDJaXgZ2c
doDGYeYG62KweRnY+fk7BDYeL91ghwfHvfOrAwCdxQ7Q08vu0QmSGCwupXDHhyAmfXfVN12QjHkJ
0BEAJQRIuKTPLHTvgb5P6RcXhcCby596N5e9IyBgPH2AOLWkhI6ffsTS9nBfJmudy+uDKwjkXs+m
eTzLGOnCPXm/QrZUiC7EpmupCxruABU0oDlSH72AAHZDcD09+T/X9j+0KHiCA+YHGxZ8XMYTT2Kl
JfGmJbbiiL1xLKw4Fv48seKYe+NAw8GCA9LB+OEQTk8YTQVIlyRZBWLaB5ZkpK7bzVoRs3PNQlVW
Rla2El1K/sXVaMPGk4k42SkCn1LHCBtzLu+TK5XDk4FgQzzJ6R1WVpeX4yy4kwTYXSwMbe2ONvGz
TkzfAb5Zhi5TBusuZ7AnUwbflimDFZgy+GOY4hY3tpupy5vlJLE5AQEvZDjvrxzCx/ynsqxexgr0
VT6w696QNx/QFUHNUXcmrTB4/WQQTObkcPnrJ6NlkKNJLh3gS2x7wzkyfPHTcfwI2wnw/W+H5oRO
7EwwbQ/7yZAXT7QaHMhovZ/6RhUUAOnTCWy34vXQ6yeEUrxggrYt3aTKpQUSBSSWiol1IGtU8WT0
4Es2uVOPWBepeuGttWwyj/N77Vi1kPGPvLeWz++Xi8H088SKgAFsPFnW1sWOIY/hluN8OrGhNx76
FjL60Q14S+k+JDNwFKfvreXny8nExVr63lr+/mFsLYve2TsUxvydg3CyJHNNlWWqhlRnSHbCVIVq
6l713p7c9E7PDt5el16NSYflU4b4D1IyWttxfQFeEUMayd3R4yvI28jI2MJvbNOduJzOPm6RbFTm
yU8BRdYMmm+UWhxzIE0Vpdfn6lBR2auTEqwTjLYmPk9zP50iuHgMbpP+nGS9QzMuODLmcFIbUjUi
cvqCkWV15NLDOXiN8uxJ/ox4RdAqxcs1pbz1cwn10wfjcshjspSNvj9M5MvFnYs6EvBAkFJPlx6j
nnYzXkv+9lvA0vBYDXHDeMAd9k0HhCDWCTHozLzyGjUQEfACRwRsPrPgKRk3li0j+KNKNT0OwE72
foLYPfyoRqw7dn8xg6fhpDN+WtAaIgGCBxRKQfS/g8dMAJj1OTOrDywKZq7hfHYzKi4QdIEe8J/G
Uyzs8/RpwKslaTOtVespFHibCTN0Edg3w6tHQdhHOSkHPCGobUcLtZNf2CnIVh4zdaKBjyOax0KC
wFcDI2URxzsj8E1Baz4apJT97XVAiypjUJBhkhRyPZB0i5oisJoavP6jZv7coQ5LukJo0cvnwTFe
t8FBnCHk74FQW4jqJj+ODxGify4zOFmDalxkOH/I3BDM/S2CZc2duepONnDIGAXKjikxOVIOGFoD
RcQUKeT0tHAe6imLJiXvaXSVfLwafROP0RAYg0LURh47VcIGn4DIwU57dAc9GoCzT/vv8TynjRL5
8F+08SVt44infdiP/MPHUvcwnPaxRChb4344essUI0QUQ2Y52j9qKfkJ0FGyCebTXnHfap2fO4Jk
VWBjjuIv/BSG+FI+pFT45+neFuxaoEGOJmv6szhqJMDeTdex/ztfjtMgfUyTJWTYo9B3UxEUoroB
GIeH09XZnELiZwIsBG6L9COZRcwTCMeR3UIBIQibluMx2SSqkpYTX4jFl2PcYhzDKxeAJwIkcY4C
c5BSicXwP1qAPBFK4GCsooQQm0VLkCdCiaQvMHU5WWSjgG4GkgJJX6Idx+lg6knEjokq+krhmMAt
YIixIH0nds6EFaRRAKZy9JVQDA+Q9Tr9gqYW4cA4LUTeyETOmBygSl7CsutlMn8Zz18u0K/5y0H/
JZqFXuL6X1JPIid8JvZb+rDOfNvBlJowrMvSB1H80wXrLdDtSMcx4U8XAhiMXU4a/cF1SwFHLIni
32L/Sj/ziCwKOqjFXIz2iavIHFrs9SurNvzSqkJw+moKZdoml4FHcU7SVzNtrZBP/ggEgD3Si8f9
7G45XRZ3sLBJASYQ9Ge/eArnU16bzpxuFefxkaHyIzayUO/MUjg9jMjapJSqB3LxATl9HwO94o2x
pC2hynijaPXmG3wOdF0ysLyNFPhT1EmqLDgyHlhsCHhLoijxIRVeQsaC5yqJ2dKiqXwak1Z0YiAF
JHxRS6iLv4QnsdWWeYDgNUBArh7VvzmBJHeJknQHd1tiXougrj8HXWnIKUk8SkJvmtYx+PiRzCfL
mo1P5gVDKRteMccTCIQpTblUvE6gVRaaymj9V5LgxLbWwXLxVKhRt/clc1Dhh9H69I6bYoQRVuP8
6WYXGFVzOEnNdDkZgA/tC1ajFWO0qO55DVnpi0GKo54EA5tBvRbOMwhdLw5MQcHRurleK+4keUwn
2WLmPnJPqMN6FK0d4gSnHs5j+sayt8VfkoUkOa3Pc2ejxWCKdFJtH4YCjOo4SVKSFQZM7vl0FAh5
tl/a0uNWS0MrnvM3+uPcruf0EU4DbvJ7wnjPiVoeNEg8Gk0T1FU4ZeaG+LZm3OgBP4pI4/dSESOl
eNZhi5N4PkeWJa61jGD44zs/yRuIyGYgpi70kYnfWhIZcV3Pi8qpE6pkz63Qe0W+3NK+40RUzFMr
R2z40GaqwI9G15FXNHyOsNUNWY43E2FCyeOtPOaptPHVC2Jy7X0RiviTighuNMzT8WzxBfsbnhIY
MTMp1kRcFWxcd97i4D0ESbMB22WBlRIEwZxbCGbk/nL4IYx2Rc1vSvPHtfFtOuncXL2RvV16ImN5
kh6i/shpPhuW5hZywKBfi0FGcrAZ7Co92TRJZoc0JXzh3mMlKxI22dD7N3CvCDImoInwe5OenXn2
94nqNpRBFB8yT0rPDW4ioYZqMehrfu7YcSHIV1G8RilqB/HLQaSOYpn+/owHftkOChT7rqLOlAd2
r46h3cd0vchVl9Jwf9XYMOZTK1OPeCYQDpA787GX5okXZcBz+1XMGC+CqnqKMk7iX6FW+YyfjKYS
gZV0p4ylTG2KflRyyUge36XkdhHDyXn89pVgrgnRFtQ++uH48vygc/Em+PDT0dW7j3xbnWd6K+4d
QBZbwta6sJB9kE2q5N60TCXg+XS2ADW8fi9c4+BY1SJw0L8jKCY6z+DzK1vXN9ii/dn9M+m+qAZ+
B/8JN0YxMumyVrsWAGk14gNGdfawC3mDNBhaijQmkFInFNGpAAv/pqzceWq4e0NuuHs1oRntPR85
JBj+XcWg3qQREN8m9nCA9TmezlPKzZxtYj8IGc6riD4UhYPYgG7C3BrAIzh4xR8Wso9f/UAumcLf
3wSRxBVD862mAh7zcEhwMc0warEVLKhkoC9KdQbRvf3FHCxwVKqhLGesJPA2vZav7qMSJVAWCrci
sXUI08bSuoXnVHz5HD1/HpxNkY0dPMTzDDR0/go/HE8H6avgCH9PNpFSRRrgywg9Wj+8Pl6nj/tx
niWb0+EQvX8VtPDTRdzf/JwNFvfsAeqhdLLYRM/zTYJ1ko3wmxO0bIYvL78bZHCr2DxIo3h32Iqa
6aDdgt97O0myHe+1krDfxJer5C9HWf8xeXkef0qHaAh9t7m5GcQvTa/WztFgvk5nQdgIwp1X0far
qB1EjTAKXjTCRuO7Fy9eBH1zyZtlSkqGqPCr5s6rxp5Y8q9/DTZ36jvBi516O0A/zjsXl11gMOwQ
B0c33bPedffoevML7atXr01PX2CNnqCxspWI7/9t4+jy4rTztne7264JUL3H3TaC3DRAwo6iBArW
sQXrQfdcAo3nYxlSoW+2nCEWuUDIBIcggC/tbWBMu0U48/bdyfWNXKb48NI9hFyAlBkgQxIe+EAj
wrNBBfj7h3EP3+nD+GwqQxgtUcRYbQLHvJbBKbs9oAuCaJnqowRocw0V6b3PeHk5SB9eTpaj0drN
/TL4PzFSJmHQaLzC/wXh3k4DATfoEAnr2/Cz3kCSgKb14ST9Z7Dxb0gnLvuIE7X6l5oozF+g2Zgg
troDwBx6QuoLHY4zSuk1HXKUTZaPvTx+SD1B5ym+C9pNBJOC3nKRjayIAWr4uRcns8yjTQR6NI3h
hkcMjkym058xOE4qjJRKQFHCUmWKxh/7jf4si19xPt66hj0FHOFWYAEE/wY7zLM56v5HUn0dPVIq
ggRM4sMaUtlrI7R8yocIGOIZupeXN7WXaMp5CdezEKGCX/+28dfTWvBvfzU19t82ZvEiR/27CJ5s
XdfRP4lcN1SLxANHRqyhApsdwFsw4uD6vPfjcbdgRn8JZvDWPW03/8LYcy+x517FY2QH4p3AEqlK
kS3sRe0VL2bnUTZJRstBCkCbGLpgExbiV2p9mBFbVz9eXrx/FYw/beZfxkg4P+WbIErSg3GWJ5iC
zQStMidQDseaICS94w5pIyMwYN1EnwAu/u3lbBQvkCU3hjZKKHDvjz8NsnmwOaN9iwFOzq9u3vdO
O2cnUjUYHeI9F4pRli/Qb45YKFeDpsu1ocrwju46WkHGywWaaJDVHo9GX4IEra8X6SAYLMfjLwF2
rwT3KQyXAJTZFrIq1pHtRyhUuaZXFBjI0ToeyNkIkoHAsqdPg7J+Bn4+R03e0otzPvviYfAmhNCX
5WjwMCV9AuVV8TF2gUB07kUqE22sRDdxlUgUPmG3gs6IFXBifMNZ/jmm+OjQKR0eOHQCBscraaAU
30G+UX9szoeyOtKFwSIyCvdWm7NjOg3gF6CszFO3AvYHzOCtdjGD0+WCRltAnt/cZ3mAiJtDNnT0
dThPU7SCHS4+x/N0P/gyXaL1JEQqDZAKmGf95SINMtjvH7ycztmaIxt+gYdIl6OBDImVIalyDgf1
4cfbi3fBWZrn6N3bdAKXuwRXy/4oS8g6JkvSCURj58EMnsLZiqD/BZc8BWKuKTHBKWwt4Tsf94M0
Q+9J/XCrMngAoq2Q1Uhx1gPwncQLaMWcLm1rAWxQoAGJqKElt6zMKNo8wHctINT30xlq3j1Cihr8
ORuNgj6+S3K4HNUxDgQd/Ny5+fHy3U1wcPE++Pmg2z24uHm/j6AX95C/AIIVMK5sPBtlCPVn2LyY
IFU4HWIU5yfdox9RmYPDzlnn5j204rRzc3FyfR2coiXLQXB10L3pHL07O+gGV++6V5fXJ1sBEqGU
sZsw1sRyzm6+4h+kizhDIsGZ8H4Kx5DwnaH3yOZCXZ+k2QMiMw6S6exLxV7F7hFoOSpUMHcfVsho
aV0PPs+zBdzAqfc3xlP0eT3oTJKterAdIrB48glph+B6gQogJKfZEFVwOppO0ar9cIqsPwR+fhAE
jSgMG5thE42W4N31AWvjS3oaZALHQQ6OSGznzeXl2XXvR/QCPYVIA+2F+Oqq0zs/OPqxc3HS+7lz
fPNjAGYOe310eX6FNAvSJidXJxfHJxc3vXedixukQ+TIQ/jHWYoUEmAXX2YpEK3jCZZtyGjDAIrn
ufScF1w2I+ExuLty6Ymc3G65a3qFxGSOhj3O3Mha0etl03E6Lh4gpQ+aPL5LxaaStROw8RDNGpi3
2NgFr7PCeNpf/4v9HqalhHlukID+iJlhW5wZvu2Ha5DTdxdHN53Li1fY64ea0lv0e8l9mnzKl2MO
hZTYwfnJzUn3GsEdLodDpEn4ZzO4mmKHN6gGmkkRwhsRQ9ADpHIxunSAMUmfs3Ryh5SBgIk+wXoL
qSAJG6eme3LzrksoDoIjSmuwsdytcZDjk+ujbueKtOwoHiVLmEbyIMnm8HUesCZCVVIt9hnmf8d0
WzLP/jmB/t82gX7TD9XuAaoVdniH8+kYXOEvB/MMZI6soRZY279c9MFdk28lfBInK43gB6QtYH5C
tu0b4fG65umBbaWiVLGwEkv9gKuME1Ipfvfd5nJX02VIPWCBBd1VJ28niNcPaW9Jt+iR4iFbX2sI
NMdXy4IjH349R/Md3CBCNN8LCo3d/mt0o4m+w/lt8VbF2hrBAXop2Mhx7qrnFOzFC3wb+f+vvW9t
TyNHGv08+RVK9pkMOBiD77En2SU2djjj2zE4yZy8efrB0Ni9AZrtBsfenexvP1WlS0tqddPYzuzO
vGFnHeiWSlJJKlWV6vIDXRL8IK2dKF7X13seWXF3mC3G0MtvcERtb6SEF+IaArqZouVBD+fImaLv
3+nud7r756C7htDyQbDI7caRLrJYj9UG6kAf4RmL7+KpP2JE12gbhMNh+IWvxK5iqjEo3iWgBxAm
HxEUTqHIpjIKJtMwQjsYBM2v4md4f0w4jn29kGgl5qvMh69V1Sm+s/neluV4Tyd+j2929n9mwzug
KbWawIKejhx2uYeD6l4SeUSyu+2RiSYQYujQx/VPuz/g2cLXBSz5Z+12x3tGgKj42iqV/6e/+wMV
hG+KVRR4GgN6kNFTdagJaDnyb7xRMA6jXdeL7t+TF/VNeEOJ070erIwpdeov2BA+DAA4tKLwPwGx
ChFiNCgPHb2tCFAdwRKvf9z6ZPehm929brqD8tVldq1LsxYMIPRHaLr5nE2isA9zAj92VEItNATC
BFvIcotkh7B3kC7ht5j5t3DAwsyurQr04o6rmmPmDXxcWzVGl7RGb7AnjfZeqyVfMOiTCUfiafUj
2dFxlw3yeEgWEM9r7yETQWsJ9xCy/B4I4ue/emenIIzj8V3R3x03j0/Pf0X7buPx2VGjAxTv2Dto
NkCuaEKBVaNA5xyjJpt1OnvwbN141jjz3jd+aV6cwZsN2W8phtv7ALecGAQPlqnvCKw0b+WgepBN
ABLgsWc8jF0PryYugKsf65uE48x+eTyFmaRZimDBYJsfQB48ge+I69rcwXYn3pfuZ382yR3qyO9d
d8dBPOI7vEYJgG9hmY67wsI6mk2m7gVT/7hpoufG7wFN45CSuvwp7mGKTMpqt0C9a7fAcyHUr1nd
BniEipWVDx8+SBo1CuHswlAOVL477eIhg3d0xOFUr/9KzHKHqCzyC1QEWhYJaITgicck0lF/hFKq
Sm4n0GiAFyYwAPS0zS7DEEcPh8w/2U040y0dTZ0TFvSi/o2nkspnvI+SNFe83xHvNz8nsJ/NgxY5
VL9rnXcucCHs758Dz+AdN85E/1GGTgwPYWnD0vEowy7qaHYTaR9aoIS7OzDNFYYl4Gudz8KuqWUy
zsr7q3VcV8luhjld8htwz/WXad3/H5P5/a7j/84qP0BFwfZgIFFwdT2l7LvAP26xVtz9PGO/dkfd
ayR8P9/JbzDVN12SHWH87O+T12m9Iv+8a8CwsVibOOkYNuQEts4v1V8Uci29BDooR1NbK3GF3rE3
sEJNfYRQV1gPUZyV9hEZL5S9hPHeTXawzJNlyfs+WVZhg8ReKclDQlQcoenlEhr/KCNeoV3ArKCi
Drxefn3bu6ZgGe+a5/KFMIBFEp1YCmtt0nUwMpZBbtMVM5LMkqyQ5aq139yDndP03v56Bhutofwq
U8+9N6cXJ3vNkgQo3R9KSRMVPCq0ChcHBzA+Xg/+6bw17dXRCAw4kAgtHrxLWNs9Hybb1zCkIDNh
GqoZoZ6RX1zp2R5tTrQ+xYhs+qmOFgOENaaacfnYpZNzq+LVcEIlXzGPj+tdq316rkyYajeTJGBU
UknGVuIM2/7pce3dmTV9zjrkr5FCX6PtNc4PFdptj6h+6OESUZA07D1XDzXLWRfOgUa4kG4b1mpp
a3ENqZUZxJ6IZueFwC0FowL7gg5c/IhzBv4LxyDjUPI7OPDEZkWBtwSnVKxKP3uqt4uTAO9/+y2v
N+VnVVW9HXLS2w/9ePwTHN2DAXCkRG8x8MBwqoquuI2KzU0pu+Ac8GwsAhAmfCMxOVyfEMGaHS9j
bcmQkpEHnCBZTaNDwpLWuMDRqDspQg14qp8JBaDPCIyPATA9kutf4U6GleudNQ6bXrv1/5q4QOTm
oY5oNERfj9AFzOkF4/MBskdcvra46BtP9sz9XZLtmPFRnaqws/PTjnfebJC7Dn5/f97qNOeD4KNm
Kwks250k7QzPR0NOIEtlLWc2IqqML39jJQH3OQaXkZjDtDnlvK2DENOTOBvnTyM5pizdPMbsjXhb
GUO7EUP6tz2miok992YgnynyLUXrtbxlKRVKphvxyorEWH/5Nb7ifqZyfpLjA88w6a8sUm4Lp2Lh
USxeaH7Bt+SMIpdiMkM9LTe48OQtLbxWRdrwlANxz46tKIZnZjQG4Xgc4iCbbWB2tdLpQw6jAJJz
hOFxnE+lxBqLoVDWGuMzQoL7ZfQ5GI0yB2sJrxMPdkGKzHRv4Ry2WI6e5jLKl3MwuunqxxG64xjB
HURfoe/8goktJV+dBbuffY/fPYny2ISzqEIOid8UaIctXU7sEBVvLlpH+x4P2C99tO1eldlrB7JK
B+89EFqOmm2vebIPWxFkde+4dQK7KXmDprb8lUYz0I2SzD9px9FRoZBkOFQ60ec6HmB6oU2NtUia
1RarE54jrgTN5DKtWY2bugpBbgGJzuEcaY/m4D0TF4bJYPSJTWF4qZw9qjQmtSFpUB8wEPwH1jPs
nwQg+cItOMW7jjUFBc26QAUywMr6qg/Lr9VXSfgX65ETICbEnIhIZ3bv8npg1XN1I119PBt5o77u
TY6fzJVDRq+ptSM2eSmTCmgUNXshcRurzJ3x4BUkGlS9w2YRcO7GT6iTNl4iUxkD4QRZ7zyWfmDX
qazOkmND/JiABivJhGadGhaT4aA0FXloqE1C2yN7rf+s5E+NEL8w2hcFNBioDYVGAFfo6QjyQHop
GtPR4+7sJn9OPAWqxNGHGqBdajx73t6szd1u7hKO/eUomN5J8BdmciefwKc5XzdrKharVd1NaxeA
mcydvd0W7Ji14heofZmORUis5R/dhzRDp1VY6f472dv/MXXuT74bnHzXoucanKD8TV8uOi2n6Umq
QHLpqMlmu4kCmhXXP+8yoS5ysgkLaot2k+hf99BZcBDM0hk+VJu9m9ZB3lP3kOraAupMRy+y1YGi
wn+LcK55IiBXxE07hj7xd3wU4mD+gV/MlFCLIWv0QqAz/tSngoKjwrNU8mGlf6lKu7Xdr2VhuLpP
tYnwGe7lnLXlpgbcw2LajaY89Q6WyEWoXk1L2ZNbTy7OyVRk45QDAznguHnMvW7RLKFGn4ujVAnU
qkEJPAhlCZU3xfPQyY87ZXg08BMfA9Z1xcUEv3ZC6x6kUCTTCN/O3jUyml+ugZqjsge+f4ax+UMV
vQ3xZFl6/It9ZfEkGOP1B1mMyHQf6Rt8i+Q8iK3gNhY53AQv8C3c7rf/JEzE94v77yzHH/jinvM7
niQubz3Nt01/KA5J4VeL2Jcnhq2gV9HI1BE9T/GuU/wphou+8b34Gn/mVFJnL++Gqr2k/57kALAS
JujVUAynRHKeECttffNkdcRF3lRiZ+6EiAa2rhdLUFFZZHJ+rJdAJK1MdlNL6qviWbTKOhuXV7eS
ulGRE+ZGlTWLKdW7hjcDiVngDHxgFMqENdVGY7Kli+ICQ7ODLF4MH0VXyNVkMHY1luZW79lcVoMg
PBjPjVkfjB/ebF7TOgeiEYQ/iZdqViibXH7IKv0tzBrXV/8k3NF3Fct3fsdWsUhbwXjahz5Zvohu
x8aftdgsr00o6BgH/7fK41NhvrLCZZjU6yBcmUThNOxRiBATaiGTxaK2h+mwn6TCuQp66DyAMTx/
+vBThf3k458x/snMfWd+fgqwcBf/bOKf9YLVlrHwAP98+alCLh7zK2mhQ3cNOfrotLFPUva2S8om
CbuEfqP12uq6+KesYUWcpog3mI1LH9UoXFwuYIAmwlsuv+Y1+B0Nv3vFhtMWG8vN1sm7xpF2zQAc
C6W208FcDsPLipqkJES0fFIuz4Nsm3I4BksJMxYZrDFQ/6p6Q/oVfk+Lk7CbUYw73sqZeiGRoxeH
zoziKnkYCAMETYWSUZBcXAzAKTTpNaPuCEj6Z8KttM9AnuIkZOIVu/On2v2oZrhDTkoYI/dmtLxW
rfFISHCi+KPZs8IIx+N6IXzzAL196ICTlU8ybWERFZrZI9srbwqyxzQqkZbKPXHKkgsW4OQOE4BM
zaJ8FcqlrF9otu/GvesoHONq73V7175ugmElcJezjXnRX7E1PTwrBrW6CdHfBL2vnw161YD9WHvG
doBFi55Rj2BWgzLmRRd5pfLitLLlR/qIg0KbQmKx+aLiclkh41QmOXNyrwzglKS6ClW0+qbATfZD
UtThTXCNEIikOgSkcPtjCq/IQtTyfAmgDN0nUz/Yl3D801RhlF8042mKL+21rKlDgbvWrnjprWhS
vKrrr2QXxLvVjCUvVKhuWWEwiSMPyHJ3NpzyoNi7Fo55Zoqi+laFZm5xR9tUqDdF5C221Jve4r6A
4mrV7J8en523TjoHHpowNfeVUanjwh54tegOOBcUm1fUXkH7HQRMZ5E0HsAHmu0V/lx+bWc44E+J
hwgm0ojQJmi7mv6XxuH9QM5vB60Px03VDw1UN6oibrWMEgaq7czNWs1eVA2oYv3iiP38M9tcS3eU
QyaZC0PbN/bYb8mvNyfpCgC034vco4Z3kyna2NQ3sL3VzL0sVoW5DtAnT/8uBvsliUFenU+tBatR
FXEjJP+Fxq6YdPTUQ4vgUw+4bxI0ZXFutHoNrCaU5Pawb1sHHaNMikZg5Gn7mSyc7EVK32DcU6gy
iVYKC1m3ErKUlgxMPufanW9GEM1p4VIoMiviWzIdmK0JJwLoB5+EwRc1AcRrJYeWxXoleI9iP9KK
mUyLLKZadh61CiN6eH6PlF0qp6MSp62A/QKgKkYL7zoMP8el5461KM9Uu5qA/Vxhqbz75zENobEb
8YXztRda0W+hulitpyOafNddfNdd/Ll0F6Y+oojewB/T8ZhWJ2TqGfzhwPFwEFhBnZxqlNkY1mA/
pURJO2f+/M9U5WcyTLZwwU+FkAIKshLAIviHQ6uC78jUVepUEhbzybJxfQQiUl8m70KWPuXokbpB
Ej5LccRP83l6C5MT7gNrAgx0hZjdMeffY8Np5aT6psqubrpa+BRi8rtDAvNEeUG4kyyjtCXhpjNT
Cl9Jx8iVnwqOUPQS5a5CahmFDKgBHQG2LmGPDDWFxuelfSVtBlAqcN6evgHp8fCER/WQn9rt2vra
5vrW+suNtfXV9cH6tnwDSHwGdaDK5vqzBMwh+i0gqA4QIAWmVFq/OPr557VaeblUp6+rtXJZgFk/
RIel9WMHENQoJUDqomIKMQCkfuyIqZFxYSci6NiiPk63DLGRfqGCmH0lVB02T5rnrT3vbbOx3zzf
1fiL1snBKRbB0wEp1iCIQLimeBQyoEXI8c0w+DhnGqZkMALLhNdJsiRidG0ibpKo6vUctiW86+ke
MmGx4tRv8I8YoUCoTMU9VDEmr8PL7MqYa2sSxrtm5UkYxMGUdz63+uVsQBq9XaouQxVBFRFFTqId
kbubnmn3RCOv7xyvuLP9ig3gpaaI2yJhUvgcDZOdX8+a1PIrqT9VTzvN8+PWSePIfn7cPLYfnTXQ
RbgN89KRwXPa3n6j03AV3GvsvYWtfXF83Dj/1VUANXaNTue89Sa7OnY5+y05ZGYV2W+iPX/WW5CQ
m/sUzMT59rz5f0mbmPnyvNFpnbZdr982jrI7ddY8P/COT0+yC5yf7hn4dRbq7GWj5rx52GrDpGYX
aGdX7mBOiayX747zphPe5lRUbqH2+5NzDzOWpR6/O2+k1t9x44Nc8rjQxZrXtEL4hswSSGpjSyJG
Y8WyURQ7FcUqXW3XR2eHIQhsl9xRlcCJNIVWOdxxqXK21SMKdVgwoy0UwuP5UMZJBkALwPgGGJcC
AKiYNKvVYPBUOFg/zcxknOa5DYnH3HM6A0A2hmxohJ5iYDJHSKK9e4A6syZVhdp8uznBPIwZ7J+z
35ZNrD9abNiZYzbvAJgah+L7xG9g/EakYyrp3InuxaIKOpy30n7BSmEN1YpFuSBPGQ2HgDW1lvQ+
VRLscHzow00lYkT5vKTNXXaPqe3FuqstIc73qi4/pCMItUg/sqBqLHDqCunJskkGl2QM3AwqqJaP
5E7Y0uQ6kGyHgw9bElEEh7s6ooR2WwIpqyu2UhpEmb1O2tcxCJyToNnTMGQxLtcC84TdRWdM2Tbl
tB0oThFfL7/mzGNV8c4Y+EQXGFyFhXLY4KBc5QSH+YrZSDAKZ5bKRZUBQvComsacP5fI5DGLPcEd
8hJytiSGTPhL5ZKKcmz3S7YtISy/noe9pKSNOslmpgq6sJJGgVvyE/IKa/RRcTP2v5BsIfQs+PUI
cyMppQ/tXH4PDfIa567xJI38OLaZdSxOY+CfZfFLiDBYkse6h+oy0j3JRqo4/ZpXnE8adUbFNuVR
A5/IeKrmtob62mlPI+A6AuydVDlgff5UtXGPXQ7ovMY73SVUne1m7zXVEYMcGEv+hTbY19aStff/
GPb9BE9VilcDU6qkrlwasLLSnUzQeECsAv6UjyFz5Sfr4YW5R5eLaTMyV6zcObz9+ftGlhO7RhPh
5Ru1TRJMFqAa4rpeBF4R2MirVxGLJ1k4yVXnChMoVhRF4RmXyOJYfmE2IwEVIDNUah6JoUKLkBcc
Yf/vs3iqVBRCd+Cg4i/yIOojm3dvSVv7yp96hCao4OItTXkkYy+nt6XOBCabMnUSPrWw7OT7oFd6
L3da414YRRjJSgEqws2IxzouXQjJ5bTvJ4U8RPSYz3uvrLTwilAeOiZPTcyY6q/ewzQTKfFt80EG
cilmgh9FniP6CeU31mRU2a4hjmY2i0epCGiHtGIAm8hHj/WH9iaRdhUe6FF+T4R24HG7IoV8JRfl
9+GscfS47Sdye7KGkyU1pzdU8HH6YwgRosyO8Yo2b2pv5kjVLE+s1m8vJOrnXV5IcrObPFK3Frp4
K5hfi44m8qUt5Yp4Hm48t8bot0QCGtHx4tKiAv3akGedrZzAxIzD2dW1HkBysSYlKpDyq6ZfMKVs
o7T2r19rtyz2aTTnjssSeYtd8tDHvEUx+lBJLrTsKxw4v0u3FXZXZqVS6RZ3QumuXGZ/Zfhjh36Y
a/F+yji1EpX2HOcAfuiswBClgul1d8zWDlm3R6kB0Lzr3WGDnTeOoS6lXmBM1K1KC9eattb0ZmE0
UBfthggp2nWXBMAXsV5HgPKHsZ9VHHFmNPNCNUOqlNrtHncYrpmxUKU4oRBmqP7Zc96KMlvjP8uc
OrnXZsawX+tdsLj99UP2b/jzIvJx3aWHKFF6K5yea7VdqLZ+WAR3JiJAyEq6oW2ux0NFxlbVHrsM
fvkaLqgM5kemHeo3u/tSu86eCz2aGAGHU3ZR97RmWVHwHM3yAl0izT57nlRWvdLg2V3j7ghm3kN4
Ngiu6Di/BOQh7R/4xIjGFDz/4+r6p8TATLkErK3Kb6vr8Ke+/bKi+QuI/6w6jv8sO7E5HSTDZy+e
jUbd6E46UvBG1jJa2HiEZnErdKdo3vNxW2tydb3+aGPCC96P9Y3VAiPK+I9X2qyw9Qr+3YKJ2YDB
8y7yv5vrsnh9lf7P66y7ps74T4EkUGpWM6C6AVprAeBtE0jZUQFdobS+mdQiwFsZgJP/VgVMXonD
BsgvdbDrSU83FMDVjXXeCzGx2J/sP1rPZQOim/mtZM8a7ideXIGtrxN+1SKov1xVMFdrAuZ9Vhra
3/LltlqrPXS5rW+oudqmb1ubvIvJoliUIuTV21atravW1nFxbs9H8EL/ra1qq1wNbrvOm9tazat8
jxY5MZWLSOwiHB8u3dV1PtAC+HFsCbmy8/+IJSCW2OI9uMeYqW1Cr77LEcvrRQftbn6xTdH3L2dX
gvzq50nWFLufL9bmILj1+3RCG+eJe3ALgo78f5A/lwG5XoNpXK3jXG7j3K49sIEILZFikzNA4qfo
39aWJOg17an1fd1eNlv37NN1dyhI2qaTV9H/W39kUvG7VVoMJRM/GnijcCxW9pq+tOmIxiNmWxK2
ZHUjSyN3Zs04mb/JUFPtra4l7SaE6ZHbrBltftvJ/D1bW3CJRGHPYPc/1mvrD2UI9GebnG3Ef2wO
SLwqgIZ6xiEgqPSamwXHlZSx0ec0t5VXazMLJ2sZx8Ujzta0J6QEtzxmj8P9/fH6o/xs0nRXrnai
MatbHKkJYjMwnMwp7f3aNlaGP6tr8o+YWKTgmcyMamJNQdO5aAFCULX0bArgq8nhRD8yxICkdEZ/
FkRp7DsYkZeFuaB7zOIUnfeozfX5nEjef79PvcUGdzNyqwrqtTo//Op8Gjmvsk7fN17yVw9umU+k
QVBzpQbnHk7YcjeBIU59G0fhIoNZuK1XCoAUXc4ir2mQtFnrnOoK4TCjs4ssCAtwMZgLT5ZKkGIu
lDkYznjnTmKqqcq51a1unpAYnIgHOWbql91p79o02uUD1F4m3z9+eiVa/hdbwAYdP8/naQa1skL1
OK+GUPN+rWR0yWXtbnfF0AHmdsEoOa/plB293W6iBMxtNClWbLCatbd7pFZctaxhUgKbQi3a9v7u
ZpWaqEDbquy8DqS8Cey2E2k8t9mk2LwWUx4KdouJLJ7bYlJsbouW10OqQSmh57cnSxVqzvCjcDbI
Jfb5TfJy8xq1vTPsJpVAntugKjWvOZe/h92kIfDmNmuUnNt0hidJqnlbmMrvgl16bjcsX5VU81I6
yG9WlprXnMv7xW7SEABymzVKzm26nTtQySPnNxgXG6btp2M3prjj3NZUqXnNpTx/7PYShjW3waRY
gRZzhie41HltFRya7ZvkaC3JCDinySRhXdKuwdKpO1a3q5GRvywQPJXttytaVqxSecV+4k3Lbqfe
1L1swm8Fn6rciNh4ZLFL+scol1iVmYULXoivrGD2cTYKY25PGAyCXhd9lIIpWkVzq6cBhn7CLO1R
MJmG0Q5Vq+9QlOH+LqvtANboe2JQ8q5x1ALuUFw7ewf7aEhS4n640mXhtry0zRMOst/YrRZyvtX2
qL5VWUbGL9+iXUsaipprFUL/yTK/2iY7QIfVlBZsb4mXnHSn11rWRQlo0Ncz8eCPcOKPS0mdCjv1
9s6B4v926p3vvz8Hrn5zfd00/MCKMFE5CW5PCN0IWliZYSznH+MqO8SgACIiBCajF9EenqUWyDMx
ZfFsMgmj6dP/GT+TRm40tN0fkirzHL3TczjoO0wXAMtkxTSIwpGwYJiG3uHB+/l2amRWRjUGWjgX
w3taM7Xi3SCbEtu2iugC92PGjtGKRdtnaXtHUwz77mMCg6S22ldrhrBOSXapwp4rQOU5U7fXHcuc
jSfJpkFK+DRr9phj+lKzV9gEDnr36lUy8CocMWSMk+7yPg+uJZcbdbTHk5HFsx5mLxjMhhlt15xN
Q+W+hjUicAmmy5SiKZm8bCQeoXuWoDmw/qvs6gHrvhDmxIui9niL2eLJQRcyxZNeNXvXfu+zjAAg
nWS+XPuRz8FxBxcRTJoJsmv5rDDMkYJvPAEgy5pb5GxRW0/sIT6VcffG56axSxMt517qZRn/QcKi
rYiJ4Uwgp59T9XbrkJVTcyOnBk3u8oxDxTxL4FWx3bA/gmg+nbNwdRcmIFMU0W/9s4jGRwk5+iEa
HIrIsGzUnVTYF1/azNY3P3N7WQKgz1J33MfCFKSBwt+Qbe00hGXcxRg8PhraDtkmNMZHQVNJYDCw
0aWPZsPV1Gzq9BXNO2F5UvX70lcMAT4ZjDH4Hv5D/hZG3lR+IE5HE4xOab7Kos0SverEpPiWqsvr
nz1CmVWSesqjYrlg8K6jTOtZyfBy6TktQiMAC7Ar6Xnhr3RTXo1Gaca8aUterKdhrqQhtCw8fSVz
It9gAkJ9y6uNgrjFDaLgzT1ilPuvZr48VnvAXPy9YRj7ijIXoogrSwIzYnfYzfXvxt1R0Bve4cKm
XZesZVURdwK907z8yMOOV5aw4KTWSGQ1abiTAo2t4UlFO3GEvkJ41GowVV0JW7RMQVTsVO8S2x/J
nimTTAvcJDuhxLdG2Zn6PDkmXJJNgU9G0nO9txZHKVeP7GEh/kRDKm5QnGVz1ZDns2z04ctJnWja
+XXTRY9wldUVx/LUcWgBQsXQyo6xZfZT5D0XVbX5eOBgMolaKftwlP1ffk3HJAeU20FFszh0uZBh
A8DRw18qmpnRox8Bn/VNivZ27P3C5OAy+5/xYlk0pMvDLHiF4vDPRhAr/TxXqzXAvVXKAG3sM3Tc
S6j13O1mcWWPsccWgiFHWMkn6f/Fm3IFGI5hb4ZZpfSWKaw3rTc/Fsdj6ghOxHC5fGHy+DJJFq/w
fyVBQNiyly1QhoQgF5hrjPZeyTilVdvAP/qfNWmkVmHtZvMXr93sGNNEwQEfQ2pp40kFuzMRXJwc
aHoa0jPHn1sCGp2EacnMrdDR884QGSrKLZaZFU9VpErCf9yMmVKKaEjlVVF0gkWNVbVTsQ7yNKkG
EbP1vG2h4nXgzqDQukh6OOAFJOKnWLV6fTNyiBtJv6WDLWkROaJkj9+SlhKXgFSBKAcKfb54Y2mt
lSqpt2/qenjqv2AaAFX8p9/PlWZMZ6RMmUB2vgSzVU46+4NxsKAYfXXN21FLd9S9u+TNEpfVx7Dl
El+YhM6PIuQ1Z5gGW8GC2h/8MfSc4pvCf/+YYdDNYXgVYLTcS7/XRQGr36UI4cAHci4gHDMe3pl9
odlW8CheDCY4ZKftn2Lm3/q9GZVD/VWVnfPu6F3h+gHeTHesAPm3PX8i499hF4kr5aDh5wUX9YIp
ReaPwruqe0NJpSSf1f3WuZwA9mzlphth7FzMLLJCKFx5Zlc4aB3hBWrzoPVBaHe8Z/Y+naOk5BkG
ULnWHVkJ0xyqSjnjuqSUKAA/njU6bzGgV8L3wpDMldwlSmMoN8+9019+e49/PsCfMp5uy7CDbS03
oxzzuL2bJ6fNk46+7rWi+jZo0kSisPsTytyCRQwiVHtaqksTgL31xfY3ujP6DJCMgdS2NjZU9+d2
7mJMCbJgiQv9GO8eD/UPoP3eFEWNB3T16yNgniMdcN7Y22u2dx2kJmTn7z+wCYaPiClOMYxo8aHk
E1vYQ0NDJU7hdfjD1FaAdxqKRCm5xLFinb02vdM4xHmqc9JlYlFSoIUhWcPMPY1FH3pK9ctRn+71
bmZZ1Xe1lbQz0tjf1y70EgaTGgaXhb7E6XEDoYgXOLVqhSZyQaA2z6lIJ7NoJ55QyKm1GYVAS6vw
tcsfdB0lUZxqsJLuuptbqXmyL6qYdQxv1HIKhBFxPgk5R0mavVG/hBmTuUrBwyswVPKMnGkqHSFE
bcdNOIQSij3qq1AqsLi8vdOTd0AyW6cn3Lbo9PzX3aTgpKvfQNGT67tY8uR6vFJ8R5kqLJUZPlcZ
K5GPxxNxmVclrGAnUqoPrMWNkzDaOu8p75z3/k3qLmiIc2EO+ckyMJIl89nwOrYxE12n3WtLUI79
TK/+inV28Gv6/ik1Z0l2yXuFC3TPp3Bw5mFLVjBYP7u8m2p5YooAQX1r7Ik8MyLXBCteHaRNs27x
qka608H4njXV+jGVyekEq0t6Ncm+ujZSSrKIYM/F4qmSJVXqUEoekaN5KyzGJ6EaltwjXADUAzUK
1tToR4Ix9EKxIVHNjbVUNbrVKHIAiqw5em5WFJ3nIkrPySMaWWIfoaZBhDGUQIMCESRlsqk0FaeY
ARV2fKwBWTt8owHATDDUPXpbek2vK8x8/CL5rSV7g9rtzul5UytZYfYTqKs/Mqu/uTg4QHunUwOE
6ymAsR87QZ25YZ1lADvLgGatJzPae0WVy/yUcgGUDaVL0iqd69jBV+uHb+Bckec8DzAqu65O/1ds
3ZhK+FVh1WpVPVqRu79PZ5VNO5bKz7VuLr+GH/hiV/Ex5iE+4nogPIr0VVfRyboKHjfqv3hhSERa
IWBLjVgiFkuWbjV7kedRCOxosvCNblr8jKH25h3XNrWzS9Yyy90uJkoyQd5rLxWE7dxoGbhbYPst
1vrZIs0X27EFO1BoO9ufuXs4o14hal+k12rTu/e/A4y90cwD4bV2DszfdOvi5uMwZ+dgKoy6LDdn
G3GuBOM4I8u8KDXif3lalZIA9fMrYwZKcxFvh8bkGncQj1GEwOx2Wq0yrRrsQVmZKAKvlRA4va9i
MPhAxPIRXVxiWtWcmoQCUXWBGjJlkiFT7Dfbe+etMyAU3rvmeRuEoeRKgV8DGPxJ4eXqyENJC0ZP
2MatAmzTC3N9acUfUbbQs8bdnzl/VLZe7xIw6tpPNSFm5rvHvxF/KF9tYVXnq42uF+artVoLMNRa
LeJB5BbRnquNqT0DsTvqXVfdtOCVe/oKQeHpQa0n5lWb0eXUgZURDLo15km4BrNxj6fU+uJzzbxt
QUJqeIoIf7Z6vHK8eoap8IY88PC7Toug8SxYjB1EdM/axTtXHhlWpkXTbk0wlRrmvQmuZiEFrcfM
N0PRHIG79K8wQQ6lCqvRkaR3hpK2sgG/ZED8dsmyJIjYZIibmyuZ0OaJgFFacJ7NaoXyxPX0PFja
FdgknNAVq4e6GkS3f9vtTUtlvHwdinDU1Oo0GKEmAA1q/Ckj1ZsPlIX9hNlax1MvjPp+9BO+x/x/
PiXIuekOZ36F4zyICRbg4MYfB/gWiiq0G9iR4yZUJNBwVboszzjZo9mYb27mTrRgblh+m0HpYu0K
9NAKFOiwVZMqgyz1DF/dWhC/lBJF20Scp3fY/Djiv2WBM3QyzkLu3VaAILub5DYmIkSfZrxUMS9m
BeOBN01RzwkpcD5Nesjt44VpC2qF9aEalz+Y50r70BLWSGQyjeK9auIrM9D3UXOmxc/KCpZdjsMI
rV0xleFd8vJfmla6dYpubWcHJ5WkFyYbLj/GbH+tuMEJWcUAlxJpioMDASDVQaesYoNjmfDObIBu
4cPZPWklud/cO2rAmPZPj/c6R7vcDJnmEw7JUrIfgf2urwpe+bjMfvuN6S+f6+wreWI4D1NuBT8I
ohGl0KSqSLtUPOuPPw77n/76rKITgiK3FpopprC+VHtc8bCJIabOByQ1F0u8wmnoXLWaUIvJROIr
7EwcCOqBrScrJ/cdiEwMdVpOCufoEgzxqFQ/fGPXJQULv38Qj1wfgRrd2QVtvsxM5Ewgnf1MMVBN
9Yhxu1KxbnPKFoQXL5x2Yy9eIBVIaITWB/2iJ92dkhaT1RWSVUeS2dMHd6xUUkJnCjZLdzRH1MXL
zyxIC/dSsGw9lXY5hy9JuHW5f4wICwU/zy1rVVpQsNegD09fZQR+dmwxg4fjrOE0EGyhM9J26Iy1
Dev8vZ9A7fb7ATKnABknAsGSjbODCQROPVQw0M5YEQsgWtjVhKcCPnV/JvLMwktpoCx8URSQcEhm
84KBkoIl2h5J0KVyVVtYmuehukAV3oWuaSdry0TZkmNguehyUK0vthJ4dItHWg8ay37vxZDhz2kw
IGW24nxOvSfkZ+HeLB58quo70GYTobxkvtLCmYKbqgWn6yckEI6qunQo32cC+pQpAtolNVX4PahI
8evKb7t6Wqdcu0OmRsoDJIxkEP/AdVGWv5hgiL3psDqrUmp5kpOqg2H3SveGcZW5nMwpMOrewtRA
IZfidHFlaTKe3MYKnUdmr3t0N/OheSL4Ry+BaxbkCwbJE+UvBiYM/tVGwtcUlOSL5zn/oeclTk2F
IqrkMnhlspYG5CJufVwczV+eJec91rLOrFo+fvnwdO7aINVz1vTQMWA4VUKXeWyhFZyaRjiROCzt
8v5hM5mZ8cFh6RuOFx+JPtUuIxA5z7oRRxFiZBj6L07LbO1shtJ1Dma4qoxXZSnlYxZi3Ggx9dcL
GE0o2mEsjqquYx2g1up3xEtKgb/AgnmIzbfEbGGLb1NfI0k/+bkSnEzveaclN3PagLrbwI/bPURh
gjRbnP67JhjOB8qR4AV9wXcoyvsWuOblcDAg4108UePY73Nv1znU2EpFmtqaZvJRYaE2n4S4s4zO
lQ/+6UchYMnvRuSdK7Y5FwIek28sZr2Zs3/SDCZWrTgZTx0DAvU0RP0E1LDvBGFFFJnDW7tcd+xM
R2FuriN534ZYobmcp3EO+hVTRalXBm4EeLEl/Juok2kp0/r0UHzzb6dedwycAcMHU/5rN7PolC1h
IVgIz7XyValb1VTbGU7Tlppb7SZZB/qPoRQ8+s2nB/u//JrXoeAO3AngeVpHhtMsABXSZmFLKUaC
6v8YKyWctGkutgg0nuaVoSI0ciOxepk95w+OG+1fdvVT3Lxv4MsTp9m0IC1zrCR55PIYOJ1Bs4mI
4YRASwnXEToicMScthcRL3ELUGuGIxxeAurrRb8F1B4rxSQ+WH4d+VdxNSBZ4XZbZM8Z0OeydnGU
LtqNqoNJHPFFRFQWf3p9f9CdDaclB/BeVA2mAdaor6N9yGq6CAfYagC0s/a519hjvyW/3pw4YfZ7
hqO+8W4y7WJzG3pzSUIs2nGALbHdjPlHUVBHlpOimBPgpDErSyaRgLMFGQGYph0eiGGPO3p0BRNK
tL/LJpG/fInSZIhLEM2rZ+Lq8SgYz26BLMWwaJ7wC72hH6/gX9w7qBtqDRhvBpafOuIE+CAWriV9
upEjCFIM49L8qBt9hrdS2l4Ox8t9fwRnb4XUVnSP12Vn4T6j0Iq0sghMKJs1uvDqVdIHcdmJ4rCA
3hd6t+Fdkr33w4cPOwg+iNEdTCi1oOQdQIvpxpI2jIDfD31Sj13DM3mhKHydXFh3kPh8DtKi/3Nk
rPE04xrSVZL3ak5BPWSURiLtCCrpkwj/KLKAP6oqX5bu7iEnH3eI3ESqtJxDrbxcWXZx68RAfZPq
baLRUXtPP3OTXfecTk/rov8A3ZO78WhlckX39tVrMc3SGYNfP515b1r8iqxmv2qoVxv2q331alN3
IBEg1SyU6jhiraEyfw7bmzQ7sF9jX4QxS3et4YTTcMDhDlmw2N2A9p2A9h2A+kAy7hQUG85xw3v/
hsOp3dYQElsty/rkp8wuu73PSdgM6ZCR7hKAutiToNYtULMx0QiytigAq3Hunb/nsFYJ0ksxKoRF
7MNz0Ts+KNtgygtjCl2c7dXI+StRLMu10XFLiY+z1BfU8ERFyiymwEg4kKdGn/Cu86nwTzNe4C1o
QimwSG80KT0T5y3wT2Zp4jqS8oC/E04jDf+RlG/y10RMVE18Ccb98EvsbkJCUi7kTXRhxHbe82qK
sWGAo2AU/BPDt45jw6dc9FDWCPqwlQJYviCjxwxjc0IFtg6Tv2H0XomQ1gxU4ftAmyfiIE7POgde
a7950oEle4bxQ9d3i4Iiq0ET0ulJ4dqTK4w+jEtAUpXfFF34TW3s3/KPAddH38u/6VuoXLhvn/07
S3wvph/Fj+TwD3jkQGFMxKcLZkufxYkIb6WmOB1QDT/P1FrBBVZNrZEHTvjGn2bCL/b+6yZ84/Em
XL4tRJ2GyA8vSpuIiV6AMvHybrq09Zg0aetPs0T/C2nSlnuJ8sl94AKl5ZmKp3Ix/jwOv4zNxclK
P8ZlIcExcX7HFDfVXMM212wbwB6FGO/iphsFyF/FO1yWC/v+Dtuj7z20plyOp3dDePTsTXv/mXh8
2Y2D3jK36N9h6/QUWOvlL0F/ei0fwMYFZC3D83iZQx0HQ3rTHPd3OAuO9pxsOWL+and7sL665vc3
1/H3y61eb6P7cr1Xv1xDt/hhjGErbnsryKmtSI6Ntq4HnDPekFZ7T5aXl1l3pWjxH45hStv+hNVr
rL61s7qxs7oJMkl9lb2o1Wu1Jy9evGArff9mZTwbDn/oXM/Y/+kCEuusVtuh/1j95VYNCsPnyd/+
BjJ7ZWvtJfyu1Njf/oZYftQPYS5z5EL0PedPyPyDa7lBqO6KFRr7FEshEZQpAAogKuoCX42W0JEP
1cLBFFVru+wunFGYx8jvB7FkukEgACl+JYzkagkGd/hwBrMdUbvANo9U/LzDkwt2hBJJxA79sR/B
gjsjC2S+AoOeP8YgKDEju+T4GiWXO6p5gJ1pi86wgxAaIPq6SzWlM8ZqtS6bEsCyh5eMAs1aqM51
OEFkdac4BGmoPYv9wWxYIRhQmr1vdd6eXnRY4+RX9r5xft446fy6q2Li+jc+hxWMJsMA1SJo9DkG
GhEOCMRx83zvLdRpvGkdtTq/4iX+Qatz0my32cHpOWuws8Z5p7V3ASIDO7s4PzttN6sMFqYvEchR
5UKiQiCSIQoU2fenQLniBAm/wiSKOKDXGDsn8nt+cIOmqXSNs+A8kT6YNDhTDbm7SGDH4bQihCuy
K7JmkEviahYrrDXuVStsow7FuuPPsKBZewoVAMhBMIAGDoZhGFXYmxBWNBQ/Bhm4tlqv15bra7AH
2UW7oca4BwOJgqvrKSv1yrCFa2sV9gsgFiDDgAgXDLYGdm7qcw0Z7iJcaR0014c1fgi0FM2dfp7y
B9Ur/uBvl7D5q2N/+jq7tS3WirufZ+zX7qh7jVHJfr4T3/6G4QFh61V7YfXvk9e8I+yCTxiFap2s
jph/OwljPL3E+3edQGrbEossIYULM372czztA/ar16/1h7MxdL5PD7XHz26vvEkU3AA5qF4/M17o
cbckNXEWST8Fudt+6I9Xrm9GK3TLE9PLREA/OzjxOqfeL29K5NvCSuJfkNJLiS0B6tpr5bJQfIpo
SbBEMQwBX3L8PL0GilEKqn5VKwOHTRT4sdzaZ6vHZd07wDIZXx0lNxpGUz9BfaAAP/E2BTDeKm/x
LwBZNSa0mTzS7wgHlNkk2igCyF07GERiloTqrmDgjX3U4cC+WtSB4Wo0x6NKKftkDAREA/dlWVJf
tdQC2hUovhZKqpIqWqEmdR4qxXInGruiVlgq09RzAr7riJ9Bd07iRjCFIYqkG1KEvDxk4epLrtko
4t/ITzQr3Mjo8ZzElHPYb1agVCt8gvMuTDClPR59Ec0qcPBFfLrI9AyxxbEs8ALt6H5S2TdMFHEM
6xOvi3pUzlVQ2KLSRtnoQuLwmBHANMvvLK9eBu96KGLpkn0r7FogLzE/yJFb4EHquBFsPPP74TIu
NkQcp7ENGU7ui2Zqyy8X0JpH3FaI+xPWB9oJtGHUveM3Ln0fb0BQyRoHo+4QjpRwFg/vqnDWIcBr
EaKOuCnsAn7hvlO8CQyN7nJdklsNjugbbzaWHetzS9sFVvq8xbggFSB3HPYqmTcjpnbKJQcf9uCg
d/s9oVcUNJAfpBsxltw9uNfwc2qjkmRXgV/loksZzVapRvq21HFPqrpsxso2b3jJnQ37oO1nWTF7
S5/OaPly3XahzrixwVtS2DC7tiSQUxg3AKpQX+RU2e4XmukJXwnOFDP60aIWu3648J58DD6ZXU+m
5KPsgPAf4KV3zaKyjPKR10iPRiXVWF5bV+6J8gCPL7n5kV3yoxtiZl2GxARrMQNi8anJgadv//GT
touQXWJal4zpc0whDd4K0IkfpXnYV0ROg4oc8499toJ/iJah1sE9RoUCc1ckeSx62qKBv8mluLZx
noqNkzQhrXYQPeYJQR6DmZG2iKbSfX1yWf8o9FQVROCVbHudJWUJkGfboxnsyPLLr3u7eTsfyyVO
2virMBXEwsVcwgYgP4ynaP4BUj5IZc+Cyasfa/XN4S0ckzXxlVRQhjGI8fPSiAa/gg7Y0iGah98X
ijbMo4ZWCFIrykFIS/V3h3sHXvND57yB6s42+40/aTc73t651zo/l09CHtxNU0Gqgg0o2NnTsJpj
y1ERE6umL23Gr29Isjjw+WpgAlZBr7sl9n/QCQfkcgw/n4mAmqPfVwX6ndllZc28eJ8dUSrO8ZaV
27iS7a8YR+aenBOg4h5bMjtUxVyDX4tVIUPOJB6DO99ToC9pTE029r8I8f2nWDS/zENCY/NVNa25
ESuwgIKagVMLyLeNafHbQyNa0OgXiWlxP6Enj1RmhIkoSC3tyCsu2Sc/EEVul2GehU3v+I5N/DG1
icrFKc/TQypdf0hhb9X0S2u9khFCw7+Z9q5B0uZAkOymnCL5ecHy6in7Ppulw0ujo+ZhY+9XjMvs
vds7u2jbnmYGXG6PjdnCg09VsxEgucNUUHZz3zm4AGtnoi9bKoSIWSSR62miWM5MuUlbLlOBU1/Y
LowbZBkh65d4NyxiR/Ell5ZEAxNH6GwydsfQqZnRHkRlqesyakvIiSzGC6gWTSEtVxgzeqLYEeOp
my3hcdHlHjMqFNVvGJVgfYqQVokjgKtdirWMpmhmm+xHXOE/Bi7G1hpjupn53dWnA7B7GUzlLwtX
krftJaW47PlcgKgwZwXhaphhNixNqBASbWsBzIVpFYEjV5OkeqOPzDnRZH7lao9YevGiEKXU16f4
mqEscm3ayc3CwsACuhVDHMjSoSiC3zDuYICOSvZLPhJRhSS5z5QuFnIFMPwADGYyU1RCfHBcaKzl
84S3dKoKdK5oTBwm3kIAiy8y1xnZlHSVrtUa539F3VhcG+Tw4ImzAHG0smIhjYYSSw2RtJCIKRdW
cY7W0E7nL6wHMLWsmMJvnhmzzvPSRZHHT/Ki9SRLjTXn3lPY2sRxHA7v16CsO3Iy8OraxNyVU380
CenaWNp56PsR2XrFXIi1rPjxhOuY6mzKAix9ai+mfCC1zVGAFU8vFnGzkr62ManTxRh473CMWVGC
WNgUzGJk3JahX2HU5xKNvDtDJnUSfiY11GxEN81VY1C5F11SRqE7LJaooXNEAgmPGyzXbn8ckh3X
yHQmy0yfoGbwG8hNWYnx9M6ZnG5BEchaeMUSRcgqy6+1WGLaDahdyhQqU+vHjM3qqG+rKpJdL0P/
y4bkc1cnNBpD1ZKfEqy2ty3A4g1aT19U3fCNIqoZk9Ts6jKDNln3lhjkGSFP5Rs/8sKx74WRN/3y
WAoQ8/Owk0P7PMIh4urWgudJ5sgKHy1ZnVjolMnuhvPAUSHtFHEl1qSm+D1JJ2XIkjxW1WKPaibv
n6bqomHVtL69c9vNO3juv5K0Cx5j3tnCE2jNGNNRv8jlgGtXTq9RLHnkDfkYe/HRtuHDduCDNt9D
913xLadfW2dmCXRdZ5sbFY9euVVy9CdJRfPScF5qwfm6eel9WTCUr7GdLTXVtWhabefnlvCthyvK
F+z0GwOFH0td+IrZcRnct8FPpyiuXgbTUqC0CbZ1NkUwG88Sf8DUWIuRzMCONpAerjVkwi2f3v99
dNS8m5WrPuNy1lpM9yHAVvalAXr4TmX89ZxBPQq1vj+NfiBlvg89vgcVvh/tXYjJIWR8CQAkK5mT
p3Z9D+0VPuxx55P2uXdwen7c6GAMfe/0pLkzt1Dn/enOHBKQyWMvLEE7Pg/go41P1ia+Z6/U/N+b
mzU+DoYKP5eR3/28O3+O3p43m4vMkuS5HjhBjzA3jzYtjzgjBSZDOANpOFd5QZMwCHxHSg8Kk5sw
+CUb+tcFKDq65xsk/T9+t/9QvjmbPN+LF74nC/x7cr7inC/A96oqb98d7wCzfAXLgSYk5s4WgI9/
8FtsQD/3UOqFo1GSi5DfiWIvVISpVGR1V6xz19skzLjrrRHYPKPAmV1Chh9Punlyzou3kxwySc+1
0FracJJ4oJiNEVHCY8ldzgbaL7548FI7hXfCK/kQfFTNf0phvytDhCLmr8Mh3avCG2KeNTZdgYVt
Ku8jpcIO323jTPMoGwPHTD+WAvt+1JoYzyLCib6Afy+ZLH235MRKEYnMPURjlz6WDHaP60j8FLmS
fCRBb8FLyiDjhtK5XgQG4rt46o/0YRN6A/TW7gU++c3FSKNkkQQZtnTYhhUC226ZItUNgCCqLClx
+uLT9M5Q+1wzpJCPillRXFF7VxQ/PEK3vmK3n/yuNpbUmV8VjH3uCH3pU+RBRMFUOphGhKN+9y5r
5SWEMr3iJD+YF+dPo3nBpyyp3TaRNpCCfTaREu+wH4NnFWi/iJF0ur9ZGac1Wh98eoyuy0hVSL05
4Hv03NIILR7FMXXwNt919t6emJzxvFDX9xmXm46anI1xtaRhvPYpdVjJM1CnkxnWTPJIVPtPPpi3
+3TSQHWf/o8jLLBj5yUHrfAxUS1qiFWFsq8KUxY+eockY0CxDYxuwQjGeNfXPDk9bh4X6K8bcaKD
FZbgKxNdGBaawrABJdGmpriVRnKUU6Iflwl0uj/3WaaL9VC80DrKzUkeokTTJz+jhnidqXYTfnO4
HATfAiznLIDDQcaaj5UrXJ8bvjoDpT/J9lvDLogZoaLz3FczNEdJ6iUVSt+SBHISBmmEzJmuaE7h
vFxEliyQmaRLkAwVWjYRBqzUAM61XDzVyUIKhGLJCRKQxVITZCUjSK0+uU7EIIWr+UOVAo8lkufJ
4jkS93xYsCMq5pNJ1+djjGcTP8qeSHKEDAE7vQgkFQzIgP5XGfEjrS7CNtSreMgD5gSnk83RQky5
eHIrYj+y7PnmeDkIm6CEO56juFHQs7U06lui01AlMLVi6XliNKR39gAVEDxO/zBhU4Uzfsr0nDm4
AWkpk+FdqUKnp88RBLajLG0KHBzK/Q5GZ8R44cx2Ags6/qPwuJKPyrv5h/NzmMWsIRR0gXDpDLOl
XXSaBrKSqeVnz59rcmRe4c770wUKo9rZNSAZMwYkFgx4QZFf0V9r1IWd/gDf2+eOPCUK0Y53bnTz
tSLjfmC5wl3CQ/35c5ZzDvPDo5xzp4s/1Z55Q4HpVZDtkoyMEwIKRRSVsqbwKZBrw4EGkXzm+Sv2
b8FpNFon7Wbn4sz7x8yP7nJqipQ0pEgb9wOeNFRyNXy/yL4ZQOYngFkgu4ulbpIRCYq4fmV153dI
ZJKZxwQvBWh3jDXaXmCnp80DM3MzZJN9SS5e5W5qI4JpfvH3p8aojTM4L3GpUVhPc6qZSuJHHVA6
sCnTk5qndFcutxlXV/KumIU6yJ1+JEubwEmLs1IhP/Hkq5l33Z3NaykxjtxN1RQ2pULI1cDZChKj
vEPeda5lO3EzhcVKAC042MzYKUk+d30AhbF/j27ozA7qjJ9rF5TzQ5BzTZreb9oyQHRq78685sGZ
1zg6Ot3zzjrNzFFgoCphDL9g/0k81VpXoQCSYJy5exk4BTMVSaGtJ0v7g8Djq8Hr+3FPFMSv+o6X
dyFcoPkoI3zoMDEjofYYIcCjHMRLTksGPud5JFZSzz8ZhEJ4dPKO6JkX+JNyOXNPlbIQU+ZVzYrY
f6yUws9SWadKlLMCX3CNmqPl5dcChEYYbDzNqUkNP6CqZOxeseZByztuHp+e/+rtN9t7562zzuk5
rqJ2i4KbplCw/Joias6vmaqH8jmJVlasUVWAfPPyCugJEKU8kgqHhv1yJ1RVcJKI6MYw3r/JvD35
o5ERQSrSbMxMxEctJphYMta5L3WQ4rgQlwOM1X780Yji++Wa4l3V3TyF7kSkY9tx3nPvlgIymDZG
hxx2iRILS8mU+UiU3boiZfkr1jrhucCOD06s2zFp9GHWW8B9RxPFnTFsEr8WVtyRp9jocvwICSD1
Jxeoa6HImJnDoYp7Y4rb82J3WV3REJQnVtB1KYhzuk1/jhFViST8/E2sPo9niPr8d7XoN2MWGehw
GB091hgfc5BFRpny5XCInOLlEmt3B/70jseNEc6KqODoyxuLHVWS1asY3DLy0CGWQv4GYxhQN2Yf
gLwQABFGLxwn91hkyllNgKxW2QBv3tGcRIcRTDFe8E9Tdj2LpghRq7NWZdMIDg6qhFfKMUnLvbCf
hLWIeQ/8vlZvvcqGfWDM0MyQklRfcjKx3B0S8awABeGhb6HbY7Zdf7mKwTnjCqtWNTAbVXbVRwEB
6cMdLAbq8rjPBtBVzKOtkIeBguEthroyR7BZ5YU4fj770dgfejFhMYYJ0EpuVdlk6lGXg9hoUyu0
XWV9/3J2RTOBWhYx9nTDL6FhICiUUMXCF93Ny66rKisW/dqXqhHsBr/Jx9Q5UzNBgtv1WWcZuBuc
S8+KyzW5UHv+nLQU/Je2hvUoavE0CpODI4GkEV2uyPFvKTTz9Bo6+OrHPqk8+T2x6HbGTdefJLo5
buSioc152W8Q13wb3v6Occ3lmEXA5TYF1DQjmkez8ThJxPA9svn3yObfI5v/ESObyzi4ehTzYDxF
oTy2gptPg5FvPZoXBF0reRevKABFY6NfBtNwEhcNiF4gknrBmOl4gi0tsX1uzY/BxWfSkhrjUsAk
Ttl0RvQvMSqssj2YbbyhiYI+sS+Y4JiSPAKscTheprzBkT8Zdnv+CJPNCcCwqNV1I/a/VK5iHar3
4cMH1j5+uyN3GrKqAdJD2BdfqB/ETtANLTKosnkMDHb8ptXxzhudJp5xEqSWs22/eUABxFqd5nkb
j/LSOteRic/KEmzDEVJg6uM6wwmMWYRbDWTmcMKYC9xBY68D1AdYTpPrxijvPmoaYx/qJyzj2q3S
vvCVKNE/ixDDpSEQlTIx1Cuj4CqClVLBMM+4iqe4krta8Hgeqom6C9xu7zMB+nIdgLTONT1afGjs
BudB8cfnAGNT8w7oxjUi4oYH5Tw6/zC3NistieflEoYuXypXKIT5EgMa1HXKIbmmFq4K+JZkpnSk
MjNCPHuq9QbbLzPXjVObFyGzI0rhm7ZCyw3nN9d2Wzfd1i+K2FMZ1WI27aOy6LffMEG5/giTGMch
RZprv73o7J++P/HkkJyDubdzrsGzpkNFUMhSmvcRSKmxBy14aKfJHQ9cuux+MhkCaqk06gu15lOu
ENw7PXnXPOm0Tk8aR0I7aKEINx/WSlSJTy1dYkYFTYdJzL7FhLd9ilwYUbD1rorWjnoUytGgorZ/
8ZOw7WgXJ0yMKRc8Pz3e+3zjin1Ee+pLVzNaq7K34Rfa4PMDt3cHU0EIOBHFED5m9HYp6tnh20XV
SZenX0pufPMiumNDi0Z0n6dMeJQ4AAXuUub3RCVPwCpcl4/GKhXHC9xQVtIFefPuXNxKyjOVrVIh
n8rogAHA67XV9U92AUTs3xW0v9sByyfJbWYyAF33OOGpkPWBmK9fvMq/2jCoCN37T1IaVnPPw9Yu
4hVB/T/B/vf1SwnDdNHSorITGE3JLP/C3s8//2zfPZQBqGMt5DRjGfzLcT6dG/n9xB46zdqcCO7E
olsK97+nte1BgTwBCIq2d2gkvNjslotEX8DP94VGK+APudAEIYH1hobHJ7tpwH/H4y6x6sVo9CvG
TzSwTXVJ1nYtVCuBQwIFzp2/u0Hhp/jSvSyn7orkx17G+uerYx9aF5pWsfTG/Lszp8IjYKH46Hvp
0btGnfR9DqNmH+5/gtQC/+lg8hlr4h75DTIWQX0u8RaE+hGTHSy0iIpHDrVix6OICrXTspkDn1rZ
BYKg3xulC+8idyztRTdQdpBtd/DsLDi5cbgXzYx074jci4aNTsAYsaMzI0Y/lf5G940ZnXWF7vRD
NoJmp91CBR0Ss3Zj2XPRTZNGqiw9ADr93nBNwCt5F0W/qzwfiHXaozek5YlckCzdP+I51yRnRzrP
s/R2dKR4BG7e8CLT574S1DyGCL2WK5veclZsb2fkNEEt5ob3Tq76MqNJETV51OM4m6AUosXzKQV/
fI+Ac7r5iUVFbY946q8rfcM8RcGcgARm3wsFI5hDBL5hNIKcsvlB0mkZwGSbiSLlFDxKWAMXL/nQ
sAaPnckSP+5slo5A7RblzkpwiR9HvhctXPw9DN0cxDIv8aXWBwfjI/tiMUAbablibhrM+b3PBWEE
mjDsnxxMZLJ4dLrkoujfIKwf98t+bEr8X0qKVaXvMZD+uDGQbIZceNUvGh8pRdKLbMp54fiz4hl9
P/jZfywM0bc4r3PDEGH+7eIhiPAui3bMMl1dkf4zgP2bVBHuJnrIoZoz6tCuc0rzwvsIPF0Vi5bz
3AyXk5n2VDuabeCLOBTMEaruEYJpvrJkq1xI6IKJO0Gzzi6wQWiZqpEyVwgbi0SZUVGcuryaFTPe
hIAHY256yyse2MoIc8Nzg3/w7xnsRu+BoZeQUU3y+mM5/RXF8aE1DDkCnosUd06A1i1aaOckTl4B
JKvQM1ljS8BlYRyPMlOpirueL4diQWhY7iK/X5gjrkVIepJ2Q7lnd4oFD+LN48Rxx2qyIikaZUnp
M0zWd7HQOo/ALFvhUMjoagHeOPmFR2mA1l/pc9woA0CnaHOoHpLvfbqSMCogKzZpcx4vKfPzuKLC
mqTbM7Wci8cgcQUptVj2uvGIzOfRh1EEEmAf9g6OGodtb7/55uJQTReURDaLuUoetd5pGVy+bWiT
FbQ2pQNZpZTS4mcK1M+00AXZ0oxD6mhNBbJV/xI+EZfR1AzhcqJM1vglLPEVwnR42I15BQ6PDOAo
eooe88GMvQO1PazmFWqnAMRpOO0OPSqth2gBiPRGM7njcGdxYl/dm0URViR2MGOatOxHCbuE1Fiw
mID7fvhFqM+LdFjTyds97kQzcnM28WpNkMKeXfsN74IaKTe4RMxoEOSGevsr8El7jaMjjwe0Mn0M
K1CZWFZNCLPB41GTNMFKl36vC8hl/SCaBn6/fM9GPweTZJ+llWjQEeRvXLbDGROYF8SBcpdpc4Nm
YnyB+NhClXVC9tn3J5wvE/GwQRifwMRcBsNgeufY3ZmRIzyBVOdtj+kXLeXHAmZXpo43w8Qq823S
nWJGVhrtnxN6KTkDmQg781SdDsuvuauY9w9/NPOG4RUumrvs8EgnIXNWUN5OV7DtxlXjaFeRCsl9
NX33mLrNLRQnCsdDx4l+ktvXwIaRNEhBALW8wwMzwXTDiSHdkwyHJqTN6EOAC3oY9AKKMDaNwqEe
EJYGWmG00bjVtxkk9qk66LUOqmeADsOWeteqyE9/qyZ/qFXldtNJv1cQW0F3CEvXGwF589D0uZRy
e/29UtykJtYVeCYnzMxfoL81NSW9a9+P74DRgTEKz0kD4SUVMBm2y+dLtHIy/fLrNTRTIkySW3F6
dK0x+kj0hQgoMiYuL6N1ESyBGZATdLIBwku6+B3243Bm5xwu1IscxheR9Rc0ch1oq/EYyL044hTz
wfEnEWByGt8wqbzDIdcQ/3T1WJ4IiCeYVraQLKBFUktWMaA6GAFhv4JJ0sJmvWCGJo7cr+A/2NF+
b8oZj9uRDD1lRUJ3mjnNiSiXKfgUDian+uoOJEdsBA9Y6xs9hhrvScLqKkc0xU/SsNFtrkuHSuxj
9KyAJ+iB8vF0NoHHQERVxwLOTMkT9hqXTlW9RV5bNgKQYSX0l9G/lTRnOK1QDwkDWWNjVQImx4El
FSiQ058mg9CQl4pjKAKFuEPN7F2cnzdPOil1n2sOZTqiBaM5iGl0BaxwzKSYTWNSC8cye1BYNgXa
GZTtwRHHFohzlzcJrsh7GWRo0Xh8YqIWDsgHO0j4W6O6doqel9JZlZwa4OkkRGZSJxLcx+hfDjUz
F0Q8wTMUC9iNH21htN829k/fe6dnXvOk8eao6R2dHu63zju/zgWCHCjpC40vLDeohyLK/piYRyFJ
oY90wdWe/HALRfgxxa1SSVHzF+xNq9P2QCKBYZ4combtOft3yX6I11PbWrOCh+eHwfXdxI+QCfW4
ikuYTxHuRcGK3oOyBQiEnWKAPqPVoAXIXAFPZcd++409lYLUPMwrjagQX9Ft925h5CPjyjnA4Z3y
2OFCogzEYEmh+BEXCgpNtdvBIGeMK+gvT+sERYDl/gjI5xV6qDIuCiiZF8QSox0t7uUc+aMkuVGt
HLmpZeHxYizdGf2ka9ivZd6nBZYy/aOCFxnDlkxEl3wzScEgXM6qrBXHM37aYZ8ZyUIA/oqHmDQa
Vu60VBWOH+5C6NpB9dTqSjsX6rjkL1N4KxIqipnRbvj9Zga6BbXsTibAUCgFBPlhqVEttHh1Ukw3
iVzsJ+kKGqKMZXE48jHKx2yCXtvckWvkvFlFCEJOF5d7yJPTUWoa0+ZjRA+qlhX4sZwOSJ+Ow00j
4tULHJxFAjba6bzTOMiKF+YICVZLHw5yDBa04r1361uyxqOxKE67zTyYGZOYF3ZTVrW4iDOTjUBu
ozo/AudC3E+xSJRWR7LiUGaxM6Zq18wbDyVwNfKwabw4vx+W9Ibtkr7TuhhOq46RKyL4FXKETn7v
OmopD8DknQnEck8xIaY4CeTXuG5TupaS7IGnG8ZQqhorIh5ieAQ4D78ARjCWBpKqie9zT9Ev1yGc
FnTaYvCMO3JYN5cURt2YCso/QH2wPybfWMQbghiFIzpT7aPuqZoCp6PTAxhF/DiZxbNm85dCtVP6
X8mnJLHJC8ExmEyihSq0ucv9ybh3xzkI+PVLord3Ojw5Tg78mA5MxvJoU54jeakfzkT2I1wdyyrq
NGp3qjYnZGpr0azUFVpz113HIHEalBe50Tc1YMUcDvEzx+mQF1nI8ZAGI50P9YdF3A/xo5ne6I/N
X/dxScTPo7ol4mdOc4IApl/lOCk+n+elaGEpA3g23dCLKVuok+S6Bllr+zmdc9l72SS1hrtuoRZJ
yFmsyYx1gh8twLCSr7O685jNZs2FfcGgf/IvG3Z46IEfh7es9ONwtgL/L+NNQz5VNfitwdhaUXMq
n7gSS+ifb2FWLj9u8/ITFzmfZ1UuP+Jun/CIASFIvhiFN341s2etJHBW5I+6EQbnIwkwu8pB68Nx
c0dcoFIEGIxLYRwL+ic165rxO0ZpVbOO+mj8ssN+jL/9xCM3MY3I3IfPJV26lV3ox0/GiYqfzL3g
4sxPlC71xKE/lZ8C6nD9U8ga/8EjyfAvQB5G+5U/ovkGhA5ng28wzHuDNrlwJ/VPzDpSr7MYMCLf
6hAz66QDFavwkezH/g43Yfixz6WKCWxffkHrmEgue+TKIiytnXMeK3Q3DuSmVLLEkteWMEUnLMbH
8lptvIEtlekEdBELLlK9fpXc+VJRq4UXVod/Zhu1dNwegqfZ17xWm2hJuyx2rlaFXc4SmwYt/5O+
zcBPtgZKR9j9NFFFD5V0/GW3Rkp+HqKZkp/imyxFWmDxnFm2PhQh1gh9hAGT+GmUPl++lUi4d9Rs
nNxfJkSe6iEyIVtQKBwMZ/G1JhWedRaUCM0HKVWIuftSa3tlhY53Ws+xxhTZZOY5Faiwut45+9Yv
xSo0gDMRvtkUgRikUSOcL5rK+dEoGOP5MfdmdEIJVLWQ8LsmpcsI1qFH6igUwT4rPkf6ZCtovD8v
xFay8Z8XD4slP7qGbcE6ehwsOwLWA0O+Wy51aoQFe5gQwJRTIL6eE1/9gY3Pa71I3HPWnvUw88DT
xDTf5afOYxPCK/OKaBLGU9KhJ4043pbsyyLZPmYURLLCDz9ujY4eA/0g7nWjPsDqcYsHWtlKIyRe
e/jQozLG2qyTBSTBXVrR2yLLJLov9nqXZHzBoyh2I5BVo24UDO/4BoZz6tKffvExSwQGyFT2Y7Sg
UlhI4OqJ9ZwFUqigaD5UJ9nu0NXIj/0p7eqYFJ+Rfixl0cJaQv5qBn9lZKPkDZichA6dpvp3vczS
Vo9J8x7AOqQpXsIoJJzXRfusebLPhHnWj7VtEYvGbfqmNVFgCurGFBBWH9sEgbMQOfzBPKiJ7VS2
vnje7BRhD/Tjn2ZGXXXwMsYplBIEvoX1xunBweNabKhF9b4bkYEK3ucIGwIgWLnmG5avvTAGtrpX
6Ga+lr6ZZ/fq6rxrept9cBlokPuObughAcwvLEzc9SWROJ/LPghhOiMIk1ZdzzyWVM/KpVYsS4PF
Qz4j/1DKr6BSKzgyKzx9+ufLrWCG6Z6XXcEs/Q3yK6xv/T7pFexhZ8V938yM+442bCL0O2xAloR+
T33eNURyhjY5M8eAhQng4ZfqL3/0NA3MD9Ax90l+toYKpkMoAbpgFBELJ1i1DF0Hfq2LPIyo+T2p
w/+2pA4i28EA1usgsUNuvGt6500e1eNtEtRes1N+a11LB8hT9Gc9ygCE9y7Iftdrmy9Xd9Zqm/2t
7Y2tl6vbPUTZrT9eRgKwDEI/nQnV66kROz87Rzf/1C+OjLZ58Gunu5bcEfPBY1Zv/lm1wFOq9smN
GNcOD/wtfW5R2kKruFTIiTmtUQZh/Kxha/mFjxsfRG+o8Lziwm4ciue0zQOWcXcMHKR76rUcBH+K
g3Y6u4zn5y8Sxb7B0bq6vaqfrX/gY2fOefP9IPnfdJCYKXNys9g4ks5oKWxwUyiLNHL6uWOzK7Jw
IyRd+VNS2B6cAUnbbx40Lo46VeUsSpsXxAof8+bxnYHcXhSEsxhg9P3eUDiZsemXkFHqmXiHrczi
aEV0Z6Ubj1YGk1n1GjcYwTBeXwbTeCUOrmS0m+sq9xxCpyKYte4wDhknzrHRSb6OuT/7FBmufujH
ZNk3o6yFAn4fnexAYPR70+FdmTy5NFwa54rnNdrt5vGbo189T88tpAaAGYdmdKx7nLTrB416VLpV
GW7gU7Ich+BtWQOjt/hk2SiaxFkbTOLIE36jlA8mlRNER8yuCp5JYQMYOaTEcSBs3tHIXPdDxuOW
/wbkEFB57AvbN2FSQUENquwNYnf6U8yibu+uShmhlNyM4LnvGLwUulFX3DiM6qMsru2oGE4NiB4e
A+2yuYc5RRMx7zngEd0dKQThVPdGfU24nyYdFtK1w9H99OJkr1miBgTICh7otlpLFPSAjOrxKGBW
DIW/pV0AatHzYREK5cJkMOZBcNKO1JppNSINS+K9x46swzishZLtqI5UQzQe9Pig3rXap+d8egDH
tZuJF0rTvqRCN7r6WMOQdXpi6GQ2neXrWJ6mzfl6FV+n0Npoe43zw5IWlcWstYa1xMQ4C6x/MgyB
ARnUCw+931VJ4dimfrt1QWK2QrpuouVgx32h2TYCvzg8C1LRX+w1nR0OJEMrmBVlQA8z4GX5y5nb
xqiSmL5rsbCtbNi4/tCaABbxzW5+CUCcmgezjG3Sn/FWgkgXSdvFFoi8kOxMa6cag5rvNhz0dX2e
WdlMQm2F++teAUxhT6/niNdmfPl1tkOB1qiVncnh5ZiUqN3+iFm3E2eUIrTCdC/JdinRygqvchH5
S3dbcGs/lWVfdnf47nWeHnPvdsTmKuGJsVTOdKnQryehtZSfTpZiNgN7cilGo8uSLGqu5wfO99NX
FrzCvdVXnHOL0VbACxFap/aKMPb1wzfJA3FsAsUevTa3ceEG7M1v06/5mKEr0r8DnwlE6vMYE9EJ
tkr3Osu1sMdZFfYWqUAupp2XE47aqSvzDPmRWhjwcsFpRvGlDBJQZssOJ6ry3DaoT1LmNVPS7Tfb
e+etsw5wJe+a5+3W6YnT7cnC9bXf7WMwA8EtC1MUHvuHFCtmtJkFlxz/Yp6vppuam8bpR6ojplzW
6avvUPvWRiXbEDoPTORJIQ4x46gmepFecIUU+sv4CoWZyZVQElLNNpeizzrn3IP6rNNEbQEq/CIR
/AKJ0zIXKf8qpFMp9hjVcIXUL45wbZhxTNZQ6FHCAKWyTPgk3cB8sjqaxyvlUHw7xJF+zBg577JB
mAwGD6NnM0vyGlrnjzJlCOPIkWlujE2S7/Bjyx1c4BB8ckvZzLu5L+dLzcMPX/IIUugks1tcZEp4
J/mLLNQ8siRPcVQFYrA4Tgk3F6VFzUpCvGgUqpTUf4FhiV6YS5QS0K4Yz8pOdoa8hmBvI5/BL9sT
ywQtwM1x4wyv8M+b+2RqsvwaDUmM8Ksc0CsqedBoHTX3cwclLAsyxEXDK9Q0yNMmAPotJ0K+FRfT
2BnT80MWkBXNeczu5zeTJ+mmwdcpQrZcaSlXtEXskDKTsCgOYTJLBHUcDg5Jk+jEPaXN7HnLkUOv
zYVgsa82Z/XtJl+jhabvsFZPzArVQWKjZXKRMduKJDvVdDry0fJrK/Ce9gYvrVSMvbRwLl3eC6VZ
dWRXTp8gKXn+/odR+hByDp4PMfsYlSx45V6GruKDrevGtRzn+oqze+Tw1EqHOUBmTbtfrLIBLHJk
12QwDMxpP/Kn1+FctZb2uJa9zvgWWGyh5YzO7pEUgnkzZqWKvWJVfM6VrAWbeqst9Edl+wDBsb8A
v8cdZs+8N62OsUxqqSKplSRZQw2E0JSviNzLE7Qx5cFWXY0e7nlAoE/3Gp3mPnVg46WqT2+Vdfi8
2q7+2NDLNoTWqT3qzdSoW6fM+pitcBhl/cqZzj4M0Hj29tc2vm3zihs1NThgZqp6SNzruzjAi2Ok
rH4cI75iYDQwXNuUItaVXQg4O4Fm2r8QjyQ6lW67zDmk5+zfGNlncHFUdpJOMVMFyWeaOTX3mHQy
MDaDSAtKrpE/p3ZQjqvD1BdHkQYLoXxKk5GnT0slLP9c4oh8tp4az1qnyjMyg9iksJN4ef8p8WM+
0vdNOW0jSp9FMZpxESYdXh+O1RRKRH8WwPnrVymkp/CXdriZi306c0xkFQBLXgDWVBWpJ16YNQWh
KKcCLfzRbURhHfXQNNJlr6LeFTFSucyo2pn5vGodau+sbe3UXupV0WRlrV7ZYi/g7yaarDA0rvwN
Z6IaX8OyhvGmd0/m5ze9PnBVfhUTXNyzPu6mSYQqmllcuP6yWZ8zonhZDGIEJonDhYkPC7av3YFh
TckPFO8/qSYfMH7gwcJIfB/MReVvNKPr25WX7MX6lj6j98Gm3SPmzmH4cRxRSqL4U3b9F8v3/LwQ
MzpnNic3mf1f1vuvV57Tc6P+A/qv4d9eTdIKYj7+H6f9BVcjb//eRM1l5q7e3Z+oXRciamuVbSBq
a2ILKGtKdHO5OD7bQ9PHdnMP0825Rv1MbrhneXXhJGpn1qVQa0+YZslp1xe87tkZsPfnzcO2UV9K
0HKxouUUct7+kCzAfDYWAbTd/WseHZycdpreSeO4afcPsyYRLA6HuPiY/L05JLKeQhkN2iIaTlZJ
ZN24QWitb/DDgtSsYlp4NGCU6ZGVQPM0PIWF6hzQwDAcuoRf8rxgbXvT8yiogPb0Fh7CuL0ylGe6
+Rg1AW+5YZk/tIB1eaVlRyVpeMZStbrRKKsleCXrxP69dwBvO+dsFwW+gRXq2nbtT2KF+t354bvN
6gOcH9K+Rlu/j6/RAgaz/FgrZEbbD0fmw5+BvE7vJn5M1qCJ6J/QZHH7dJdSkeiFlFsD/zW9nc5V
y6biOZgqAgWIJEouXFbzFJboYg2Hkrgop3US3Yn78pFIIUFKuSTgsKjo0gM9d7VPpo3lXXcGYWHd
gEdYbzQp8bSz/C5yeB17XoXpjyJ8lIyYv7Iwm0AkEMat4NwKZWp0tyD4aGHwkQCfzBg0uPyaLgd/
ZpH8nmMFZdZ5nVfHyGYhgohgN0Kgy0P4N4hlGPEvGL8MzSOGaOpLSsNggKbJlGONw0iFJunPMNMN
6VmFBtKXDA1XP7Jn5mp+Vqrd/viMnZ23buEof4ZRw7Wf5cqC5dMxnhReKvwrv6aNkqeRfIrLUaZM
0TCW0uUle7U7m4beFAhjPKTAI6h9RR1/VprqZJUSI4Af9HgiwanCLkOgp5gZ6CaIpjPKviMNrdES
G92s5c/IV9Uz+kD6FlloxRhQPVHXsBgZD0xwwEXJUpn9LckbcjkLhv1qL2Wsre1PtLgLh30c6Mxl
neFI1Z1NzXQzV57Ct4CpK37S24obuwLTXjFjDi+BnAlEKQr8OJkMd/VROsU3fyTsF5XBBiYP1jYi
L/VKeN/z57n3XffJYgptiN2e3HDSM3EZlKRb5umDloCjXV3fTeyUADU0FHnzriFGi76hbQE7cyYN
86k5TPxwu6lUBszlAqtORZpZYOFB8YLrjmWun/uuuwcuO0Ul0kCuBl/wm50D/l+tUxGVtgPMKDBn
8mfr/zW/av38l0gRrxXVn9ilpcWQCdx+mlHrzF3tLLPe4cF7WZa+au/NRPMGBgGBAilJynnxoLxi
/tZSzRfY2VjMaClQ+n4pz787bCAaMPYKfUriAY2CvZDvKY6DOls/1ipML1dmHxM4FbZ2+AYOt4/r
h28qrFqtojGSHJ9K0K1Tm9IalEiQgFcN/1ECRPGXmZYOPOkb5QPXSQLOSYBLWU5Q8CkhWfCjmiZk
+HQeKaPxqmCScuQfA7ymFLV/1ucujQq7+Ctjxsx7qCQ4lg1A9T9pazdVRKZhsFpczqk0r2Pm+F04
EOGtbWiv2fGxWr7aPGkDSw9Oq/KC1UlgPvYOd51V0oPN6MmyBtYFykCB1oNlG7ZV2UTLV2Mi5519
cv//Iw6jKZ5kFb2AlhSeCE2FPU9JLOVveHrmH4cPOgrvcww+8AgkVPANjuxtWlzJPPFFNpZF8rAY
awu6p3VIpyFGCsT0DDk8UDI6Knji+/fU1c0MScRsvqjvpPo8iiJiIV6fWr0vvy9ay1x5+TULLEtu
wgzEYDmRlxfO3JvJfEguhzxV9awM/EmSgoH/npfBt9ja1Yi7YAB6XRL1KaCinhLUcf4P+8lhqDic
b5Rgafm1sEx8bnhBOVLWGx8zyxLptQxLl6yBmMT/Ic4zCfeSsG06dI1j6z8qw8b1ytS1B/mwEDqM
09GFIsmlycQmwn8uL78Jz2eyQA4Tzl1OZKVdSlOC+6JAMhIXn4fNpx2nlsp6ihI+E/3l16jElR5H
e6cn75onndbpSeNIuB+lo2pjpe5UXtSYvkrv37jLm/6Z+gGDH2dyD+Q4tKlQnJmRzWQ3p7xky/KT
nWgQ9OVbVixVYphlOFKnMoa59b6pfe7e1sZurpm7RSO4mSxUetE/Gj+XOLcAVzfsC65OhSk80K2V
E1PlqhYkPZNnyGIXFmIF+M2v01dKP/m47QhZVi2ip5tzaDNxXU+HMb1AK+cMWLbz1GA8+Q+rSFWO
+ZPT9q9tc7oSJlyZkKe4JdNnwVFgialtkQxV2ym6VUzKgekDt1FAEwXSNrCf9RwTf01+7DC76G6q
JWlxo5F0dz9sLWjKRcO508sFkEVbdVFk6TqalBbCMb6UOoKIiHuoqKZwkBQiSMJRJqteJW8W5can
AbvL5cTzzEVvmgBI7KIgUAy5eayVw86Mtj3wf1P+Pa/23OAWyby6DNrYEjaC2dNkY8uvJVNh2I8t
6T9NnlggLgpuqCiFu0d9yp4HFPsdbZC3744dIh4sKf4BXvddJ5CUhXjc5OYzpw1pU3u2euwBEwGs
QxHmjqLw8NEwCZFdjQZmjg2NUPG05VbnXe7w7GnJtf+fM+djNPa3wvFaGllo3lXxr86nwGfU2Y4e
19uawSU29r8AyMjnrLN7mxSW8aF7CcMNkMvpHC7sKbaYrQDLYLxFvxlNDMVJx2BUzkTL9mRoE0II
4BmTsRcvXEjDCMmp8ZZgZMuu0mXHgGWlTMoOBR13S1qB3DRfmeyb45NDHosD0dxr03vOlqmSUSwg
WxFjYO6+Il5mGeeCY5o+celKI1ZWfVlQMdzzL6I1kg+MWD9aWAFUWAWUfYvmhhP7PTQk8nj0BRCC
Y/Ft0Q4JC/gl/u98mxgYPpyi0HfMuxD/s5I84e4FJkMRT2Op7cFHzeEAw3MCJrHD/cg8UZxMlCbF
aesr4+iQr0XnrLS19vmTVr3o5wOnQxIq9pbvWo41+Ck0gtcYR4rj3tgovMYCOwQPKDGtIqgG8WFu
Y1nH1gFcWzoHhYU8RnjJydxJXURsDzpOBo1WHkWWzVy74Pzq7bcdYClOD9FXriJWWUWtv9yqngey
zNU4HHheaSmDlKBwmgukAP9pzMAcWtKfjQoH4ROfh3ObPAAIlMXYGtgDAhRNUZ7En/jVtXPl9jEv
cPEvhktGvwQNJTvutar20MJShbZdeHdkV/kK5KMRerJsASITLQUmlsZOu3lKEaBSGiWZLw+/f81a
DH98/y1hZD7P0PtbRPLf+m7n/d3O+7ud93/czltF16djnI5wM6q+8Vy36tbjkosIybJa8+jAa8DC
8fYbnYbWLXiOT1aP2m8chY8be29bKpI+ax5Ds97mOr/Hz2a3xXFCsVOmzCb52klncUG2PO1SiWT7
R6tveBrsPqKac/fRdIC7/2l118NUXfO6/w1EN33Ufx7RLReR/7186+5/2i1kN5WGQqOFf/z0E/wS
y7sMw2mWr1/y/l5ur1r1Aq6vq/U1dOjn/yROmhKIF4y6Vzrtwxf4DJ008bN/eswvFT2MPtbcx6Rp
y69hMcNEJtLNKIh7XMSJp7PBABD3Qn8jHxJEEhFKlGCR1hE3wsbO+N1oSFnZymUpP6iFJO89e9js
fWfFHw6GIUXgzJkardC950eHUWCSttbRkRb+kh+tMK/jhjcCID8N0CogmasEOV/5V1LtwAH/gfxm
d1LIe4aJeNaqtWXuWPtMWviIasQX7KRUJTAWbxRfluBfvN9TQHC6L/1nbMd8BFCptvDcyumFiI0q
K3y997TmOdYm77+FX+3aekrewhAXQtVGLgTAPkO/aG9gHKSEDT/GeMAqKNIs8pfjid8LBjj1QI2I
gadqV6EfMxCGeI4VwNQyJncdZtTlyyP+o2c5myP5fRfp/teJdNjqFGaBEgTC8jn0oz57C2f8qDse
s58/R91bf/i3GOa12vdfZ3je/hxP+0HIc6Xoz2CMqYcRZhQxHxrutXoKFkDpNPVwtPIZ5R7hi5u8
wWgK8H+rPD4VN1wrXPpLvQ7ClUkUTsMekDgbaq5PccpRGIlwbxoNpYhp9Bpp5gDTxo5GodVLJZ9K
uurNpsEwSeVz38Ak9kfMW2Jpzq89gUW9CnrcaszBtACbjdyDZr6TmCkSgYQFzy3OpJqVuBl09QmH
Pr8y54+m4bQ7FNZp6kaGsz6wRzCBZWbpVb00mQ6KUNwZ5deyb9iYVh2RXWDIVg2UYJJHuiGPgEFm
UtC5acTT4Tp6LRIz60KKlNyJhURbKL4Y2NLlxDAWmlu+XNJ690LPAJ3HeCbpH2ISuCUEyuYrr5+T
x+oWOlauwvIVarNhRYlxJ1xWMuCkJEXRlVMoQ+rahcaRSl9gT7WjNF9Jo2Rl6Ksrs7x/M+1dp6vw
x45aYn1XofhFVWtMW/fzaplNyoqqRbndnkhzNxFMm5vbUoJ68QBv0fCo714Coe7TkZZIAUnsYgUo
DvnJ/cVnYx8qYLj8IQgK3KBbckVUVmxpvEHjl2bNYwxq3To5OPVOLo55hJ7S5aSs3dU4C58dnGjF
tGtKGjwsXuAxPnuXw/DSefmira2w70kTZaNu7F9Vb3Sre1fNoT921kNL5uUC8C4ny69RRxYlnXB2
LqMKN9R1dMq8wcEqeFJg3vshah5fsZKL9BlBzAnn2u3QC6FVCfW96QGXgIHeEapxW8zX4KhPzblm
IBr3JnelEpegysaiFvAqBhBkPD54hxfNdsfbO94/ap00yxkTIwF8TNUgRzAY/U//U/vJecllUnbN
hDWXtFdEiAmg0BqVt2oTmdfCib1iUNy6jlyYrCbwTLqaPFeElW4rtctK3FZHzcPG3q8UvvXd3tlF
m24rtTnX4Cy/JpUnfkXXPU5WvNmEIouPuvFnzR3cqEZpadxnrPk0s7IztwU1x1ZWPnz4UKReZqu4
JDJOd/8WJKixpR+TdpfpjHq7FjfE8bXwunFoluXyEUaOfN0UXivogkPk2MfUjSAuoA31irGOuN5X
W0CkRk9A8EtlebhKwgyAz9rnKNBhXuFurxdGfRH+pd04YmvV1er6DmvsgYixRwfMmxM6V6B0VfWA
gyYeHDAqA/ljMsLGHvst+dUyfr2R0Ue16sFEzjBwL6O4irbfZAd/ly7bG2CkbBHCeBPZOxG0RIYm
++GHH2B4B60Px01XV7tRdcC761wPdogQrWb0cXX70z0JsJidFP/ocCT9+k2ZfXNB42YzvqtgBNWE
W4OHpg5K6KWrY4CI5v9CaIJydOCfoo1M59QDYZ0QIYvj5kcnggHuBAtZskxKDkE9pv1MFtZZb5s1
V2UMum1TdlmK0k2/SvZ9RV6QFcKax5V1hZB36f8vRB/RSo+uFNGWLcAsshxz12H4ObbSmgrMugo+
17CumdMXKS4mSVnVO+N/ce5BU5wDlbUuQrNEw8QrJjkQyctUWrObh5HOG1qpDy8j/QDgrDt2guTr
VdPP0hKsMEA3dBVjallvChngPru+GamVuhwHoT+aPSun8wtKhvfgPXL23ptGu2mGi6ZFqfF4MKak
OPm1ZBb/SnEYXK3VUgAzZMCvhdDHz5vVEawVLZmdJ9w66YwXVFtNLdpfQ8sGX8Y4fwKsGY/FjtOH
X02PFKOxjxjxW3OX5AsmrVSh2ZMeoCrEU4/pCZUm4WSG5jjS5cnzb7u9qeIlDNF7QXNugWfiLhxW
6nkfY7i2c11vNxXpgOeaVltupCXryN5xhq8Cp45cqvqwh+mEkuA0JS3HlDOHqDPnYnbJZIO7PcaX
HEnhTMcKaGrUlw3le32TTaFGnufqipZAaEwTEJEiTwX1w5fZ3Hn6fREuXHG0pWc/xjuiOvwLhWQM
N6zwjKmkpMNbO5gbWsoeXJzsoUMuxgG0+lBxd7qc7nGWY8Nj7IxksS25+3MPdwfgken7+/NWp1m8
voUfXZInc+9Xhi91TpQLEdBIo6Zl10JxeGOraE2jvhaYaW7GxzkJHwUYsVX02EFZrt55/unQNQHp
U1WwZRnO344Kk27faF97I52yM96TIJPzXt91Kd11KpGi6cVddsBLfNQtF3UTm8rvJDcYwiuF/CX3
DHPnRcOPe+7OkJX5pU5JtvDzK2PFl+bCYcvmFlEaLpxdO8siUQ1cDWUVSUxGaEjpVj8DU3jl7+gq
0Ql01iAt2IOfYjrwUTgO0ZiWEYfNSZumXx351+EXpURFqBhIw0G2d3YS/O/s/Cv5UWHWxHxV0JAB
oUvEySzCvHmWrtZg8BcnhiBI/8CRq2bDeJpJupIijvPCRaG0y4RsAoWXH3l3HvZtR1rknpY14oTK
k8uJoTq5TKKsFVJz53EPc1TfbnZiJPOUJVcuCvVZmgJLYEksfeYzUDJtKZzbex2VglLKLM4znTMT
gyAakUkBLsAf42cV69B2XPf8p0UWMePPoY3edKhPO39i+FLyR9VZNUFsVarQyIXo9LjROmk3Oxdn
Hm+Sq/3mgKAVXJtTaNS9hb66C/bo7BM9gCnzknrpwsJM5lVqa2tFNWECqmjkQOBJR4q1Ehx432E/
9lNrIeo5HMSUUKxENepJWgrom9lhAZgblrGt509yYXwWxOUiC+YfM1/pNWnU/XAu/nPHnkykJIrC
xID6oS6eUx1M0osGo7zEyuIzX+1ZZi/mQnFR5fltu3ijNCf0R10hyT1oJtUogPx8dfO0nNMRRXPy
8ZwD4eZ6MuWpYIfh1aqEZD5dcM2n1AWOkw41H99KU6ArO80LwLR0ratJDRHbPj6Tcg65eJ4szNeA
1q1Rwk6ZitpvL/n+fhJu3qiFe7M29PnhHAleoiQ2YAu1n3YHa3Fm+q3tXNbsj21oj4rvMM6y/JVv
72XErSoXsN6u115W6uvsBf1b0yy4+QUsB+XJtPX6qn/iWk3ZHxGsOwlu1cV8BxRBkjIf2Bq88hPg
L6mmnU+SrnQEXbcuJxXd6Jzun/KUCxR2mMnVTFWfJ5sGWvkhgXhU9/ib0113FdpbzjrJvaa+Kwhf
IDz5sefflmjEMLQKq9PRWCdSUWE0fgGxTDELnqBVPJ+fVTE/qxsVmMaF50cYUDgQyYPdsf9KHL7g
VYVqx8pEfy+scoC2qQdU45Ydcq3JDkPlj8GnskgVVudTsL5egb3z7baIrRPHPDSPuAle/EemkCui
nlK2B/Yjxr4g1gd+lcplOS/O7fJ8hAppETjUqCfnWU41nknGXH/lE7e1yiduc+3+e6fC/g7Ly7mD
jFmg9yKhDsU3/K+cFeEYBZilYK0iNL7A8Yc9T4uGp0VbhdI0Vfc46KSltuuYk+/uccipqgWOuA2i
nC/gny2eQdEwS6d87LfbmwhzedTrosk4U9hKz6LmB61pj5NPfV0RzLlFV5N5SZXFW1ztI7OKG7DK
6Xo8C7lW798lHeRyvVwWJ8sWHfgvtjasxJJ4RI8uS2XcuyNY0SAEBEMfGMFnowGgnZym8H/PZLID
s2pEdfHbJVDmwI9KVoEvjgJmHkQjDWKqV1a3oFfQox29P8vp/ixY6UvBSszut0rEOLfb/dFlIUwW
qsc5hfVtSmm5ul7jvngp+zwVwlMROsox9UQ6VqILNXJnwyB2hUC33LE1t2KMPOpdzgYV94lnnWvd
W2wl5k6YixgRJlk6J3do+C8v6btXfoHu5p7GZjf68ZRfh3KuVQQaj7iFD/WbML65AXtoAw+Y9Zcc
5XQAYA/RrtAbdgEOsBJhyildDQVED8rYQzp2q9R1d9wf+iJOHB9GRcjYUNhOwn7THc6ob9pkPg7k
JQWaLOdQ786kyx6cjTdQhcXouYWnmmid6xrhIc4TFZk3Q1yNnQWfjJts+PSKh1JwAOezhkoLTDBb
rDG01+R2IadtRvpzDMwyCv5JLmFxeoQYdjjmvq2ZXeCqAFHM0Q/kCjCCJm8Yr8OWp9dROLuibLVy
PuEx7ti+fxP0XI1lLG97ExQ6wslfi5+SK+T22OPnpBEcKL/QN/BY3Vzb0j1WH/VDEr3q/gopb2+C
OIyWgwGOGN7Sn0O5OBLsT0O+ij74WrCeMz8aBTHdxAfcAfbyjl2h16UPhJPcWMMBrY8rH80CKPAP
tBlDhfByCmQNDYa5ByQBJC9ItCiW/qZ4NQprIuwFlC2wH/ZmI388pYXKKPADK6GP4zPp34jJAKch
Aev73aF0MFUOrNJdNPLRfbDHfSD5BAfCpxJfD2E7iFagOoGjYDUxjmKGcY2wzxXheIt3wzRE4T1b
0XxcYbvRsuHRkDSf3dgfDhEKxssX3p+yl1SObo0RwVOBMmr7y3U4MkcUxARuALIFd9yFUv0QUEgt
/93vTaUj6CDEhI04TKD4/YA2+46azM41+vyEQOF6KjTPOARJgs8CvyNOJly8iq+73FtXbBJUbfBl
po0uwp6AWDLmBnRhxOmMNWrNY/htk7VPDzrvG+dN1moj5/+utd/cZ88abfj9rKJ8gaUfMDs9IL/g
X1qYNqv54ewc/XpPzwlc6/jsqNWE562TvaOL/dbJIXsDdU9OO+yodQzyxD7IK9SoANdqthGg5THM
PZHn+QxDN/YB9Enr5OAcWmoeN086VWgZnrEmGoqw9tvG0RE2R/AaFzCSc+wr2zs9+/W8dfi2w96e
Hu034eGbJvSw8eaoyZuDAe4dNVrHFbbfOKZs5vD0FCDxcWJR3lP2/m0TH2O7DfiP1L84pL3Tk845
/KzAiM87qvr7VrtZYY3zVhu6zId5fgrNIIqh1ikBgronTQ4J0W/OEhTB3xftptmn/WbjCGC2EYBe
ITPvLnrdPtNjNHne21/PmufvWu3Tc691IOKQ6FJKdgmCwp4mrOvhycWemcYcHrY75629jtc4abc4
O07cDCy2cTi+G4WzWLrsr8zGtHCJMpGvNjqJjCmC2bPE5p/O3DZVmaEHNz/yODsSI02Nwv6sx73f
a7dA+tdqcGZUZfZUGA/d/J90mucHjb2mtGbyPPb6lVZBR4C33zxonTSpIvd5goW7f9Qsca6AbtDZ
/3DxHH8gYsWdx784C7A02WVfARI/x3lnPfaXv1DieintPbBF3lBeIxKBSTsLNFOsU6h7nF+BeGLv
L3/hFTmHTNX13uW1Vib4+f2hcpq0nQVHfLLxlgHA21w3YLgbSOoLUYeijPrIMjvYLBSFkhrIGqIY
Z3Qs6n4pXY+BAwCWuoyXJbDG8EG5iteQ8BBX2pdrEvVqZU39gP3rnJ4etfXdfeVoogRAKgxBCvDw
G3WovBEbvFhVeX3W+jt/SCZ1arTbzeM3R79in+VCt+Q9eR+wm3Ti7Lzliefs2fDWph4NdA9REUPe
tc7/b8wJFp3anFLIvJPw0mt19uQk0W8KLFejwMJV9o6nwWDBtMeAz/ejdP3jvYa3d7xn1q9jfXjD
eqMeZwWj2WSaUfmsaVZeVZUnvlWZRnjcvQ1GsxFqpy+hR8ALiGwdbO/sAqkkG4FYHCxPohBTTwE9
pgmJOZkEAHCKwCF7uCOTSwGbOb7iiaSCGKUSv/eZeybrl3uDAHg4wGA3uWPVd4/tEsl4HD6UoU6J
cYkZGdYT+wl9OgP0GkDQ9QZO1rZ31tjfP0+2DpHtWm0Anx59q10cOWpZGjFRCz/rSa2s1Ze3/mb4
jVbgvP2GDxPtnK5XS50CZlGjnE3IZZaD44MTMbbSv2EwZS3K4WTqDSaRf8XUjTtiWbO/MkeFsXo+
rsocofjhWo1whnEKPYzwNrqji6YVsnIEZrW+uXx5N8X4KQAH5Qh1x/6VzXalwxFv96bbY/bVf6KC
MC3otT6SgQFKrTt6NH/+dBChbcF46vUix9tpmP2Oak7izFe9ySzoO172MGG74/ll/MV4SgPDuHLR
jd/f2diSllUCJ8mykpiB/4vFJJ71742tvnczsrrDHwNv5cIjbOTLyOtfpsfV9yajnuMpRs8YpdED
gKajPDRs56MBhgz/F2gQY9MDRRvLGJHG8O+u8bRPT/tu/y4mfFhvvBstaZdVRna3/nH15acMMNeT
IL/y6seXG592C207dnMVfaxv6vvO2pfd8ec6D1eNxdjKCn/EI9CXItiE0Vq9DCe0P6Y3NdbtoRdj
guxC3bgs0I9auh+1zH7UM/phNjvuul3uoEPZr2h/ftzImB85C2sf6/WsKYTNn/VmzsJY/7i1WXhu
e4DT1W0dqelNm67X70VAaAHBe+e1vHKw33Zz3990c99H8U09waK7zGTalX3ZngNr9eNWPqwAsS6A
1TdzS8Z2cuFUa2v5TQWT/PeDfNQAX5jfA2hgDoRBPAfASOJidT234PXcWVz/uLadj/ph0Jetbea3
dpM/7ukk/70fBvnDjqKP63OWyfRG9nVrNXdtjm5yAQGfnV8AULcxbwMMo6imdkDudoSS9XnNbX5c
N2isJItFybSkQhv3oSvADRIH481bmzMkvTRmTD0Sz1AtKlTJ8B/64EDJ2XgaDNlJt0MqcIpEGI59
EyxZQ0hhBdin4VCEN/bHaHjXp2NECipAHaoUmU/7AK8pXydCT9/HHIcRBdBGg11s2xFChTSn+mdJ
T7iLWqcujO9LVesh1uPOYQASlal01xnHKUAgXzlaRBGmN4siXwQssautZCCdX/k4urGbRucEZQGQ
PVRpETwyEy6edd4kkxwmZfqD69xC14ULjbILGTzhhldPEwMc5MifdtGRLwDcemhBSQulzl6Rq5Z8
S+wh4KLCauKNWCtpgMiQkOEWgKmhBr1eQZ0GrFu5vGSwAiqK069zLxnDiOKP25wVwtrhWAGJ86p9
Tqp99qOxPyxWbTqaKM5r6o8mSS1W8qtXVVp9dAeF1knhJC4/WU5tJtRZGKk8SfZOLe+bxnkVdSCv
2Eh8e4FVPW73miqOr/DeGtGGSag5Zr90QbqHp8M7up+kq5RUVdxkV8n9GEwNBVwNkVjd4D4Kpgxl
slTFq1Dme/0CdeJq0b0mjhg5ljknER9XBsHWhRiHwGJkBtClmptJX6UbSFeDt94w/KIOBCf93/y4
tr6xmcXdjkZe96YbDPVDIgPQ1sf12ksC5BgNdhS7Y/Se7LRV+CociKOmVcj8KeDp+Vpiod7H+zem
AuUl/pu4NIQ/xyT2Z31YH4I8aCQa6Pukq+7XMChsPBti/HrUrGCYi1G3dx2M9eTwPMJwgxP7zFIC
Er+xIvMc9WpnR8vTHQBpxjARHBxZyGFU5Dt88oQbhsubUdtpUvM+rLITOHURQqLMEy1UxRVPTm0l
J0s7GzvZd0IMqIMAvHnQkiEtcLBy69gQkpzrKQjdsQ0EC0fBZBpGBjyyKnC4nu9yeAKAVlm6pksg
wgyT1/5Y+ySHo9E4ygpJSEtHcVhxrlYnHt2BJFI7QdeGCtRjKK+DE3kfq3nA4kquJrTJEX5Gdz9V
wFqK87kB9inkmd84dUQtLZwgGlA87QRrwkvrkES3bMfpdI/4IezypcUAaJzFAboejuHPKziYKaR6
YPNJuZ94NkENsN+vZiAk7ZBrrctJt/9xrZ5Bu1KTYz8Qc5mt40W+Ds8Xc9J5kDC+5+/cSrrJ1HcS
XU2otLV6GeqoiJzVHKMze2H8ou5mXZRZJcvGsYT0Gd7p2jZ3c1PgYOpKV+ws00/KGGpgbKMbWRo9
w8XAUJmkxRqbl/q4na2zIgVH7vte5rvLeJL3jiLQZgNOdFfOXq1mvhz0oryKa6aK3pK9URjKfNuL
+5nv4px3vcEwG+ggzu7uIMh5188d5np2b0CkR0q2tmqweA65fi0bUbM507OZV3kwyRkzVN7Kqwwc
ZV7d7dy6V+N6rop2AmI94gbjTGfiZpjdAT+3by8/rm/kdm5V65xkj41938vb972F9r1bRZqnHs1T
jc5TixZRic5ThxZTheapQXNVoHnqzzzVZ67aM1flmafuLKTqzFNzzlVxFlJv5qk289SaeSrNOerM
QqrMPDVmrgpznvqymOoyV22Zq7JMtrXOM5jxdfUt7gD4cS3nBLvMO61RMZNL/3IWfR7N7g2y6YR7
WZC7aXfKqS1qQPHynLjyqI63YFXmJsCkidIqTpOKODi/n+h0UiBS3FPX7FqKyhqMhG0TMLD1xxZ5
vczlq4L811Hu28lnedGYlJDRgXcYXe1VJiP8f0+Yt7jh3OZM923efN/mkKpbsZ1TmDOYYy1ktOj9
mdRGJEo5mXo8RF+fy9kVl9iylganNLc9kHfyyCwvkUPBeQH36Ek0xPeWYMjHoMlu3Ho5uiR1Pyqa
x33S3qFhMs8JhEJjIt/2jKULT4Lh0AAnzMYxJm0JrxTuMJs5ctBktMll9DKgpkUqxGEXZHw0G+/G
eO8QTA1YX3y0Oxe5cVRtTGraZRv1VVbaXF/aLjNhdSfVQyriftUABmP0buAFNlviBdgK28a+4CvY
q2isiKb1sbnRuRm7BsgfCft7RJu+jRFOlA1IjcDulwbEeHUSTv0dhtnWIpqf1aWl+rpQMr16RT/r
LB6GU7NeFj2SGMjezZfxx9Xaet5+FyPMW1Dn7Wb1xGt3Gnu/NPe9s7e/ttlN0GVnjSMPXlEsLqN8
m9wJhnfy1mn805SWjzhlKpTCit6RSQy/l0LLtq6FScSx0Byia9EKeirAwquydii9LObiiUZJKhAM
LigW/PyjEE9BZdl3uHfgNT90zhuU1F75ZtbLGBq97ePOnEZdsqawbOCoarvZ8fbOvdb5uaq6qqoC
yUdGpLaz9qmarhqOKW8EfmTVtTJXt3U/+wKJiFtR0Nl245yMIiWA9bIMtcImN3AUVUGwqWpq9Upy
J+BW7vB0Mmqt8IaW+GON7M9hM4wsuxYhRGqb6HACIwDrLeWs82lVkUqI4Z0JgeRBdigZ2PXNSC0d
kZWFkAX79ZJSdfMVJgERNmOVuCypncQaRBs9ulsaRn63f5douqU939nqsdc86Zz/mppH7+y89Q6X
joduX/xT+ndpefXiqFx2aqHEiITuzKXeT69YB6Lz1Emu4spNDgZfYzcTFk6MsRjuBTI2Vu1m4kE5
/BjvSWlXI3DsuDthQSh0/Eg2uZ5eUXhy1IEm7ZsBXkNMwp7SXSbF4tg8Kvx/zLpDgmc1YRunomPE
/ulx7d2ZF4R4AkyY/qkJROyF4xsf0wKl7i5I+UrRC6SuX/gW9ULoZjwJ6a6Xei67kqpSZS1MUyeu
SWI1nIphJBry9Xp4doCuEO+4z3cQiygKMPi+L26W0ZyXr9ufgKaG4+WbabAC/6f4ODkYwEFNQ+xm
goF6CgOZw3CO3EYYjSFdVXAiuNl9Se1zeop9mIZ0g6w+a6Kn5+JejHblYEZXUphhL2/mKRCRMfPS
yvmC3uB9FHnvcdoi+ABfpWsUhunwwF4f/Fo5p/F/dicyzLhqfEMavdNCcGFc7BSMl+q+TBNbJrtd
KJdqd1O0699i4FMaGQZ354nOgdUIJTHNAsorYnb0BJNbAihS7IkfDUZhdn35Xv9si/pXGNpLXibB
eskaTIEBe3g4eASQf17KNuA0HEziL3iK3wSx7Vmgg6NinirGN4ukF41+H2/UWivcRl5QPIoYltu/
IPR4Ubn76ukZEU78yQ63pghPjWDoX/n9grMlowLQrFF0ClFWfvQ6zYMzr3F0dAqnWUca5tdu60aI
/aRDyrlhNv4mI5BgzTEI3K1pk6rfl+Fm5r+rQlwBEHGAzdOBMeELHzdbP4h85GGJal3eqZ7TS2W7
whlZn199w9LBCbz0p198WPGUeDTiRxfdk6sAkayLN6GwUWdAbyParFnDRI8fEWs+IcycQq0IhguJ
HfVKHB5kzI+4zCMP2pHeaLdbhyceMjV0JWh9aknROSUVg2mDLKdAIG5o1lMgahkgUBNGbgw0au6G
glerYxgZFthJZEkZs3s0Aw4WpN73eysX+F/ToomyjTGs3d51ui/1VLezSqZGLgqWaZqmw0sG4kHv
M7EDduvw1qO3FsjVVOtZJVOtq4JlF540H3LilM+AP5UbuI+yrRNJk6ueVir5rKW6mVUy1U2jIO/q
meSDxuRklFy5290BXtL5WU91J6tkqjtBWBZkw7Jque4KmxA8fofdO9RuhOZtbhI2uyKdaaUJIyWp
jYG98kfV69dKTxL5shyRD9ivPiqcEnYlOzI3iqY/WGpQLafhLkqWqV2PwQdGUJo44kjIaRYUtLnA
nnYvM2GgpQgfjEbnHWA4zcoFY1mtZALhZis/5Nu8uGsnVi969bkGLz8YShanycsPcw1efkiuwX5I
AMbXyBSgOgLTIhOYhA+GR7PRmHzyZD5TvhacAKLwiw0AHxWoHUbBlXdLdXuzKA4jOIhv8ShMPCrd
de7MOndWna+yYRnW1ZoVYpx2f8haFMQgEAumRTpJz62eJTTdhpYQNP2yryV6paHcdNHnJeLMCe4w
cgqVvMclcPBj507pJwliCc51+AUo55W0PCZIGgPDdU3cExD5pae6s2LCKrXFAiViY1i/+F2M7SFM
uEMM2TEk6joVoiOFTbVI5Yd2i0cN++GHH+rr1vPW/2vC41KdQozJgpwGH4VXaqvoto28F5vr7Jc3
bJlbD63DV2Hzl2r9uHF21twnpYfohc5gGq+pM6IvdjXep1Ou3UVrwEa7xUofgL8iy3XNKLwMHNeU
BoMJtHK6c3rQhrFLNAjcv9WMb626pNJADc7pGSpBz2EowPe6358ftBCvqSrsBTqwljMqtY+9/U5m
tXpGtXZ+tdWManun75rnmbXWMmq1Onvefmat9ZxarcxaGzkDy661mVHrsNnxWu+yR7aVU69zll1v
O6uXc+q9zKjXPM1ZIt2cxlqd48x6lxn1Om8b7beZtXoZtc5g2g4bmdX6mbN9nrNG/Bz8n2ejcZCD
kZxq9azNhvV+yamXtdsO9rJnrZ6113Bse2cXrWys1LM2HFY9O86pmLXnsGLz4KhxmF01c+PNr5q1
+5CGvWlm18vbfWftnPnI237n5zWvcwr/rGdWz9qFx40POJ9QoivZ/gO88UAVwZACPilx3T4P0krw
AcX9C4Mf0vpvqcZp0g0Rv0we+F0ULObDpeKkW08DXhWA4ShE7h9VhVFog/zQPNk7PQZqeoJJv7ni
GLbUds346OEXrBq4GJAG1tI1skMvCOeAUy2SXjLmJzLAVhJyDfp+x+N0jYRCFYVVIw7fQAt6YSpT
CF6vi9wav5IBnigGwRaYg3C8wrmpOAOsNMl3zkCIBhe813Deb6lBawEfSFNzetY5AJ7iAArVMl+f
cJZB4aYlXPJEA5Q6mjoNA8AwbFMTQcCG+hhwQwZgQ5WCdFyQcdoQGTzmh/DKQVuH7oRHbYkk3jkP
CYgazCginCg5i+n6m3tCbfHLbYyDH0zvpLaLAAyDz5xZhqZmt9IHCm/RbFyaCGjtN086HmZuAhZs
S2hXuHbCaobkGN6PdSkdkHsGhkysFm1iXahQ5jWxcf8mNoT6Y37hk9MOkivGY/CkRXttpblk+1Gf
y0zvyTNLFjSlEvLfQ7mUrpX58pclaRsMZAXho/qDIZ9StY7UfWIwae7rSeogco8UYslkipdxmJDs
B7mcvgQ86h2IhFKlJEsKUdIa0OQKG9h1vPnscwmzoXcBHvL1OA0iCREFqh8Sg7ZEsnILVqkLCB71
BeYri4ippw3kRSnZevP84Pj0xHtrBGmjkNIYPrd6/ZqRuR6qe0Rb1WtYZv+YBbC+pLYIi3rXfrev
wzCqvOaqXQyoc3Ds3d7e0pE0GXSjK7lIYm9aEU/Uza18AOs6+YGGJhiiysBQekQCUVkXxXbb5ZxL
ZatX84tSf+cX4yNJssk75zp5BVBUOD339Moge1oI0JvRirgcuDZiUOktuqPrqZX25I+UoCQvnuuK
ZD0KRX/VSn+DMLAvX37bKLD6UEXUzT0V9rPUK0P3a1usEwUYtpMdwgESDvvs5+kV//Y3vB6uDqLX
qvb3WLDfY8F+jwX7PRbsfWPBWgcXhZa7eHPU2uMHzn7zzcUh8Jh25Nf8clzD7E9XDpW9YrLcyT44
8ruf0/KjBQvFbhQK2/r1aLrYoSommfA3CJ4RP0cyAwocQ7RA9idzGj3xfmmen3jtdqd5Rvd2qCiu
lTPgchG7RKOZhHiBA/vsSxcZYvqZUlS7W6NfqrV6VmvT7mcMmQW0vXddDHDnDWylvbcC8GoKcBIq
JRj/nbPAcwE3P3RaJx11r8mtRB8H8F7zzAS8ngIsYj0UB0rb3QC6kQLKVfErKtYFUVDORCOZLcVA
skFamV7TTcT8SeVqH6PRzfRIRjN+r3LWOCJ5mpW6UxK0i7QAdZg5rK3sFtr3aKGdbmE7uwW841y0
BaxjtfAy1UI0CEQrjpmoyBik/q3fm9/gebrBenprKytRkc8E2+XqkrkNHB9fpBpI7+bLbl9mY7Au
Juc28Kax7x2fNYwG1K4+oFibGBwJeg+ydD40OMz2mkDnrO6upaH1L4tC239jQUvv31bnfOWscz53
pB0thquElt64rc4eQNurHtHfQ/63MR/4Xhq42qB4ZOlzT8Y1c48qutjZY4l9aEemw1GBgzTz43tN
/xkgpXHSPmp0mtxulOtXkszBUoEr3WZl+ANuQm/YyVuVblDHp7viyarjy8gOnGF+UON1soI8iu4Q
4QqIbUcUQOcoV/2vDHuz6wr9mR5q6kmuFbqjdDml08njbB5H3NWF/yICr17+W4i89W8r8iZDzRJ4
t7MFXtbocCH2u8z7Xeb9LvN+l3m/rcz79t2xd9w8xosUV76TeSWTshgf7FDzo9MtBPDdcfJu1X73
S/Iu4U8PnSwDeSjICPkuX4zj49apuKJmpTVADHWsbBfg4e9L6BbLixwbCTfeHTa8BE7ttmHf5MoC
HE7tdpXOFw2CCPCvdUbr2YukF2VnFdE9jFfi6B1G8acY+AKy3dYLC1TZUZW3YATW15tow7Jtmq2Y
rb4wQJXdNec08ubi4KB57tnDSbX9wgZazoZRrMkzu01nV164oKfbPivaOE5H4wz2klpXA7/nytEg
SsnFVa/Zq+us9UYH4qeAUAFjcRr1Dw/eq6HLNXbIlkEq0BacUVisSKOAdGZ812kZe5B86Q7OG8dN
j6NI+bLAtuGeVpezwcDKD0K1jk7fe7g3OFsNXWdkNPmFNozD04cqwWA1Dr12u0aBB+DhJVp9p4q3
Tgm/qvg6MeXiobuK2k+iygZ1y7/q9u7IG8ld6y2cMcloareblJsQDnx7NITIE0rNeOnjZS2xIIB3
aQYtvJf0Fk7eAYLVvHAyihGOyqkiYp6TOX+BzLSLsPAK3Dey3Tok5Gxu1NZfrvvrGxvb8O82DuHZ
2xas8dbZwTPdmJ7nj6QslRQo2B3ELCu/AH6nO1DnvXP+OfQnvCFEEQhRWVxg4qW/gbi0CuLKN5WX
eGJTEHzj/EvCVtz9PGO/dkfd6+60y36+k9+6U4x1QDYzvZD9fUKCk0t4f9dgR1SsTV4WMQx+AsP/
pfrL91yT32Wt77LWd1nrW8ta7ca7ZhFJyyqnG9VUqyvwX0Lyn6VfapmDnwnugjre1uK8MDSU8qMd
duWP/YioCnrDXIbc65bnoEZqVGVqWGjttb2JtCJGJmh9bbu+Cr8Nfw7o/EHrCM1hD4nHAnZsfW1z
vb7+cnWw6W8CG3FxxPWozz7AmYZjfOaGINJR6snJ+KfOjUUF34FpuekI4QNKaYMpVrap1MW0cMJ/
1epvKsSzFoZZq32ASf8GYTTqTlOBmFVVShTnYyh1veq7xNUeHW144rguBlbgNqvB0HeAknl9jF6Q
8ftHQE/908cf/e7tJxaO5dwhRZQBDhIvqf0m7DWQpNQS6/x61iy9bTZgZ1Yw9L8bpzJyCT+Zzy6e
GMG2sfD1F65oxmg59gTAJ+Bhx77uZnUBgFbYqtG+BrJ4++kI8viEPvAltwvvzoCarjm7AFWNLvC0
4SIyiD/u8YP+ptubBOzVa3YThHF3EvTo+5C+ih6L+uZDV4O8QAqVwTi+6SVxFZNVipm30EDyr3/9
K/oUzoZiOV36YnEBzwCjSKptQ63b6WTXfDLpDikDvCdCnqRe9z+qyMUZWDwiOarC1t2Y5ANDbPIo
SYSP2Vgd3t3hHQVPull+jVSsGkT/8Mb+F+gQ8TIYUrtoFVUAatU0GsanAH0R1axgUCaMzDTCPzeU
d5ejDXg/coW70UJsZU4auTempkwFttUejZLYTPIhhoTyHIWTmchBeqd1DGfdhhvl2C2OcGHOP+zN
+EXd8uub6agK/0/yVyzREjqN5CpKXtJawn/u2NAn2qBM6D1ge4el8l85D4gOoFSP5wAFGU4FIMPK
+AZznwIWSuVqRpO8arEWFYhQgbj0KecO1ozR7H829EUNXTSA7Wm9lfX7YTW1YMSmfmJa4r8TigPv
5OLYO2ud8PvldRldpROKMFrvOst9WEB9mQOEzlCAiSC9CBa3uCgUeReGyLJfXZNpCUyiSjGEpss3
1A8eH+MLetDfkIu7A5gQWEHW6fZ55lM+hlSDKyocsQuIvaQxRF92OGJBKxyhFOUrkabojhLYMLbD
jHi9opDIw1EXj3dY3VFIQYJFN53F7kKTcNiN0EMhD5JobjW30BT9tHmnk0LpYmTTn3xyG1xThbac
sGQ6Eiv+NbytbxICkGrIGOVfgX3wh/3YjsBnkAN5OLmO6SiyyQ8+jfWnlKgCn4bouOwPHa/gmHCA
ATENO8uTnbgKoBLNE3p+pSPKWJSYpwV+TC+HH1M7cM4BJYpX2KabXAr8lKkLyfbHw50rCI55cmPz
9Kb3jnyc2s7IyEQmETcZ1buwjuOd+ibmkjg7hp/Ndx3vzdEvVfrR7rR3GF/oSVIm3QohDc4fIzTm
BNc82WE825gb2ldrvfEMJTdT73L4WYt6bLyejiKP8m7z2K/HXuf4nFrEf981jmCrr15S4iLfX45m
4zEX3Gdj2Xj2siXmymLtEpwzGfEwZ+Ibe2etCttyzzqCElzJbNLH05EO5Cs601FXAAfRbCLSWicB
Sni3jINCczjaSfl56Q5YFXSQAshbnOa/l849vZWY1TfXXm7u9Fdfrm0MXvZW61sDrHnrj0msWwYG
1B9Wr68qdotaHCSRRiTm0QRUoxuVrVSvhOOgFpVFQ40s7MnCHKACD10eJY6HwHglcJyoTsGr4MHW
i3wRdIFrWiidDZxqn31/AjPCXZ+4RCV1LKQSxcMxkDF4Ug3b6EnUMS0Mn0v58cYAtJfEnOOh7Srm
QJQfluimlW4ob3gpOqsJk7DYNP8xo5Tw4xKlinqPpeGg11fSmu37Vc3fdOmpNzdg7riDEW7N9V2K
HShcDlPbQfa3OMANDeDGYwDc0gCmt4ZCkJuonJ51vINmo3MBb8gnsdXBrO5nZ6gfqrDtYjtARQbl
Ki9ULcdATGErLxPLCEtzFktpRdeTUEf2TvdRffFBTPP2nMsTQ7X0J7w6iYPQH82KXZzIst/Cymz1
G9+aqGHew8rsu1vV92uP79ce3689fje3qnbrtHl8Mc+pSi/FXarogYwD3NPDhjzhoT9lqGMKoUVr
cBSMKWhnRCGtDt5zt+I9mCgBX1iMUQP71JVYRUnGkOjcn4M7NGGagu1XwaTCopevQCzo8nbl7QEF
Vu7jXlpGudayRZPDSdrHiDXw5U1jD0OF1GSYhoMA97sg6WzwhQKtBSoLLZc/SK02CKIRbTDRr7kt
osGHd/AeW5POYhhFVwSApLgMInrvPFCN/X0yhHr7axsYHAQoTf/Rg+ALYKI3DAF7KCLNg0XeA63j
JkKRIaEPhjPAgcv7IFX94Oii/RYwufeWIGxp/YCT6h+kSZgL47z5fymYGUKQ6rpzCvpNeXXVcpgH
SE6od94ENpCuq16q1UXqKQyKqBzE5oHbbx613qHNGZAXANU1d4JaoyCHxModjE+rdBYrUfeNNJhl
HmeT8pQInRmml3T1ZO+N4UOGl28yyg53fhLxQ7u9XtqFI4EBKwW+ke+GvtKhk62zFkVkEZF0MW5P
t8+ytw8Ae9/4pXlx5r3bO7swFjI5eiUSL0pzt35vNs0ZG9SgmKRtMp3jS9gdxkAw7nxTavkSzHym
bbomcGUnykjBlJV+KStrmJVrozt1v4i23Y9fuh/XaxnPE40mXjDK1UahUf3cAfa6wEs5gQLL6G4N
XtSzXqxmvVhzvvAm3f5qkgLSGtWqUAwVCm+Rdyw9REJR9CRHMknKFJFILueA6Mx8DqIOUHbWtnZq
L3UQKKesbVa22Av6C4IKZuL4G7kvexTG9tUrdgqbiw6hZXUIc/9mKED8O3DtJxfABOE1Tzj2y9Un
tEIYv1YDIauCNgM7yVpKcvRK7T1pIV5w44L5BZnc1JLwoiDu8YL2pwb9YBLwQTcYxt2BdtB/ufZF
kCbSq+KbMUYAvaQU2TwNE4hBH/xx9SEz3w9Hvekwb95liXvPugJQZM5frlbqazDr8O8mTDvLcx/j
gPnNW4J6LLp/etxonQBLA5RZEEmOSjLm//lnL69Q+QlzpJoWjfGExKRv/dcTpX+GjShSVykXPybC
0RjNLOlRiDyucfEMrVgC5nKyK1VjowlZrQLLSAFmeTBoCstq6dSS2qPu7cgf7UqrXhy7jJMuvBVw
CR/vd3SiaQO5jQPvpktA0B4kFZrW8qa0QJHWXZ2AXjAacaRwj1H4SV1AwKmIewhC3tVdT6YUb9cb
hkB5OUKO4Cui493bsw7FrK1qhPIJ++qeMfRHLLKg9BplqEIrc2Nru7JaZy82tup8ZWavEYyAhDwD
v5Mv1KRZZSraZUL3hemiVPw6LaYeIbArAg4nBgNi1e11jugyW1fBa4phrXW71L9ojcqA5iW5UMuG
+tIZxQy+D+gwG8a+OqqPKceSsMQGau2PJtO7HdQeIEHjlircPIiMjPxhH3iJkf80rTGmRADqsMxM
C58xrOxXcz1Vs6op0xsmpgmFtSkqolQcaGOO+PmTniNRBV7iWtt+Wcejb3vzJZ196aEh7bHoHUKa
BGMMWO6RoIL5EIwDZ73urITNW8tPr7TqrHSVX0lLDpCzGM3P+vqTF/eohMg8vcTg41OeQYNfAemH
sQZtite8PF+GJyyldGgbmRgSE+T4rG86K4HkkNUMVtqiiX65QTzOy7V1TlOcEy0/6QUehKjkUncG
SDSNJ7t5ldOLJfUkt356+q0n2h3t/L3JmPUkt+30jCRP8ivOLjFo/2UyH+pJbr0kIKv8yCe792a9
0EwWLRX+kcd9aYXuzYDpMArwYNurldV1oD6rxprkXlF4/Id02wcL8yvPiPumqgWwNxJoyEQs45Bd
0eUkpuAEER3Nn3iOD9ymFgG3G7J+0yGeeT7JlLlB6Ak3rn9ZDAnB4JdBtoUAadX8lEEJqtY8OHDs
59CATDeAz+lWeAn6+I+Z5iikfN5OPemwt9/EoDTHjfNfoVaNHLxk0qhX6Ix2UDP0A1bVdnPv9GQf
K9fTVbcyq1J+QjRDocW7qjClsDtR86of8hoi4etHF0Dd4HPbkxA/1j+lBNvUfHEFERPHJ9pAYNK5
aRQOV5okMynjD0oWQ5F76SJwKu6Cerz0UFhDMoIjjZ5Fegwe3dU7a6D/GLbhtU7PTs87be/odK+B
eubqg7YwcePxvD0sSz1oEysgBXbxxjoJUvAPF5/1q1mOC5jI1ilqGs8OTthmbonmu87e2xO2uim2
nim+mPe+vCp31zvYp+W25SqBvLv0EcSLYWfzZ6qHP7zkd8dDc+OvbW/iQvrtN+0hSNQepwcv/rJI
aS6PN3nWsndBFPQDqR3FnCQxv+CCZYfJPElU/KvBZ2hja5239luNExr9ywctr3medov512UuLQGi
wMKq11Yr2+wF/iMkdJfxQRMvyGq6iQGid7HpMFxH6GIcXlreJfZ6kAdBuq7ljfgM4FuVu9Eoo114
k6oKAs595zUIV9DWJcRUQHlza5a79/xaYArM8epGpb7BXuA/q0Q9TBYXr1rOTzunXuNNy/sAE7bG
bVOf3dL35e5l8GxOjc31pMbmOq+xnFmD+Hr+eUZGZnNaaJzLbLsY6HckimesP3jMsgCdwAHxrpk1
6PQS0lfvvYBuruct6oVBIuJyFvrC8ACxD138n/EeJG/ViwL3Xu6yfoF1/nKr8hLEr61MjQ7B8oKR
4HgXo1/EFZlXKsh8Yijwj780PzT3SNdwwiM0oGkwk3qNHO2LdX3gU3o4tMQSfFqiHXG0H4x5ektg
jzzsy66rEN3mJsbOQpumYQJZcDoJ1pC5eFFfq3M1RSb+MIi3LsnmfpbwmEWtYIDhSgNMUgAsXBck
PGR/QMhvHrQKgxKmpcJVQRi8XM8w77zfF7eOhYHxZAw8O1wIojbKytKPTfaOqx4UJePTfN44OUQz
OO/N6WmHswhsnedyN7Nh02U6l6USZcgcGFL5sZMLrTDur307s6HB41idgbkQEQ/YxrwBFe2CsNfB
kJTHXGV9zJP93ZfiwKM8ekOv701teO0iVxt1ZJvWuPb4IcyQ4oSo6WJMkOF1W4DxkVyPxuz8f23Y
G8bt5BEA


--=-Sfh9NpehBPpgCCvRbkpp
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--=-Sfh9NpehBPpgCCvRbkpp--


From xen-devel-bounces@lists.xen.org Tue Sep 11 10:49:52 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 2012 10:49: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 1TBO2K-00057Y-Ut; Tue, 11 Sep 2012 10:49: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 1TBO2J-00057B-0H
	for xen-devel@lists.xen.org; Tue, 11 Sep 2012 10:49:43 +0000
Received: from [85.158.139.83:12823] by server-2.bemta-5.messagelabs.com id
	2E/DB-11456-5471F405; Tue, 11 Sep 2012 10:49:41 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1347360581!25545775!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQwNzc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18948 invoked from network); 11 Sep 2012 10:49:41 -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;
	11 Sep 2012 10:49:41 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 11 Sep 2012 11:49:40 +0100
Message-Id: <504F3362020000780009A8A4@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 11 Sep 2012 11:49:38 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Keir Fraser" <keir@xen.org>
References: <504F2C00020000780009A808@nat28.tlf.novell.com>
	<CC74D415.4B6AA%keir@xen.org>
In-Reply-To: <CC74D415.4B6AA%keir@xen.org>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH RFC 5/8] ns16550: MMIO adjustments
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 11.09.12 at 12:42, Keir Fraser <keir@xen.org> wrote:
> On 11/09/2012 11:18, "Jan Beulich" <JBeulich@suse.com> wrote:
> 
>> On x86 ioremap() is not suitable here, set_fixmap() must be used
>> instead.
> 
> Is that just because we don't have ioremap()?

Depends - I would assume even if we had it, it wouldn't be available
as early as it's needed here.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 11 10:49:52 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 2012 10:49: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 1TBO2K-00057Y-Ut; Tue, 11 Sep 2012 10:49: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 1TBO2J-00057B-0H
	for xen-devel@lists.xen.org; Tue, 11 Sep 2012 10:49:43 +0000
Received: from [85.158.139.83:12823] by server-2.bemta-5.messagelabs.com id
	2E/DB-11456-5471F405; Tue, 11 Sep 2012 10:49:41 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1347360581!25545775!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQwNzc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18948 invoked from network); 11 Sep 2012 10:49:41 -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;
	11 Sep 2012 10:49:41 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 11 Sep 2012 11:49:40 +0100
Message-Id: <504F3362020000780009A8A4@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 11 Sep 2012 11:49:38 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Keir Fraser" <keir@xen.org>
References: <504F2C00020000780009A808@nat28.tlf.novell.com>
	<CC74D415.4B6AA%keir@xen.org>
In-Reply-To: <CC74D415.4B6AA%keir@xen.org>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH RFC 5/8] ns16550: MMIO adjustments
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 11.09.12 at 12:42, Keir Fraser <keir@xen.org> wrote:
> On 11/09/2012 11:18, "Jan Beulich" <JBeulich@suse.com> wrote:
> 
>> On x86 ioremap() is not suitable here, set_fixmap() must be used
>> instead.
> 
> Is that just because we don't have ioremap()?

Depends - I would assume even if we had it, it wouldn't be available
as early as it's needed here.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 11 10:51:59 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 2012 10:51:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TBO4M-0005JA-Gm; Tue, 11 Sep 2012 10:51:50 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1TBO4L-0005J2-Uw
	for xen-devel@lists.xen.org; Tue, 11 Sep 2012 10:51:50 +0000
Received: from [85.158.139.83:36355] by server-9.bemta-5.messagelabs.com id
	FE/3B-20529-5C71F405; Tue, 11 Sep 2012 10:51:49 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1347360708!30091549!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQwNzc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1608 invoked from network); 11 Sep 2012 10:51:48 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-10.tower-182.messagelabs.com with SMTP;
	11 Sep 2012 10:51:48 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 11 Sep 2012 11:51:48 +0100
Message-Id: <504F33E1020000780009A8A7@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 11 Sep 2012 11:51:45 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Keir Fraser" <keir@xen.org>
References: <20559.4620.289290.810165@mariner.uk.xensource.com>
	<CC74D493.4B6AB%keir@xen.org>
In-Reply-To: <CC74D493.4B6AB%keir@xen.org>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [ANNOUNCE] Xen x86 32-bit hypervisor end of life
 after 4.2
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 11.09.12 at 12:44, Keir Fraser <keir@xen.org> wrote:
> Okay, I'll stub out in xen/Makefile and install something into
> dist/install/boot.

If you're already in the process of doing this, may I ask that you
please don't remove xen/arch/x86/cpu/centaur.c (as a pending
patch of mine will make use of this for properly enabling 64-bit
support on VIA CPUs)?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 11 10:51:59 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 2012 10:51:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TBO4M-0005JA-Gm; Tue, 11 Sep 2012 10:51:50 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1TBO4L-0005J2-Uw
	for xen-devel@lists.xen.org; Tue, 11 Sep 2012 10:51:50 +0000
Received: from [85.158.139.83:36355] by server-9.bemta-5.messagelabs.com id
	FE/3B-20529-5C71F405; Tue, 11 Sep 2012 10:51:49 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1347360708!30091549!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQwNzc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1608 invoked from network); 11 Sep 2012 10:51:48 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-10.tower-182.messagelabs.com with SMTP;
	11 Sep 2012 10:51:48 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 11 Sep 2012 11:51:48 +0100
Message-Id: <504F33E1020000780009A8A7@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 11 Sep 2012 11:51:45 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Keir Fraser" <keir@xen.org>
References: <20559.4620.289290.810165@mariner.uk.xensource.com>
	<CC74D493.4B6AB%keir@xen.org>
In-Reply-To: <CC74D493.4B6AB%keir@xen.org>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [ANNOUNCE] Xen x86 32-bit hypervisor end of life
 after 4.2
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 11.09.12 at 12:44, Keir Fraser <keir@xen.org> wrote:
> Okay, I'll stub out in xen/Makefile and install something into
> dist/install/boot.

If you're already in the process of doing this, may I ask that you
please don't remove xen/arch/x86/cpu/centaur.c (as a pending
patch of mine will make use of this for properly enabling 64-bit
support on VIA CPUs)?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 11 10:57:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 2012 10:57:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TBO9Y-0005ZI-Aq; Tue, 11 Sep 2012 10:57:12 +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 1TBO9W-0005ZA-Le
	for xen-devel@lists.xen.org; Tue, 11 Sep 2012 10:57:11 +0000
Received: from [85.158.139.83:36174] by server-7.bemta-5.messagelabs.com id
	5B/3A-19703-5091F405; Tue, 11 Sep 2012 10:57:09 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1347361028!25547804!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-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5322 invoked from network); 11 Sep 2012 10:57:09 -0000
Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com)
	(74.125.83.45)
	by server-14.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Sep 2012 10:57:09 -0000
Received: by eeke53 with SMTP id e53so300267eek.32
	for <xen-devel@lists.xen.org>; Tue, 11 Sep 2012 03:57:08 -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=2OCgCOkPVOTXt3X7p5MCPxdNPDw62U3S+IMPEbrJaIc=;
	b=BirXl/XdX92e+ECewJv7E9L6wli9s50I48WhK9B+vRMvxDGJQPvLxVuRhT1TkTYq8m
	zjShkXKnyKH9V86CziXOfgbPxbIbVpJw6n3QcMBVbGb1Q0aEOECE0ln35eDw+uqZf2U5
	P0Qg9gLuASFbksE4ZWFT4IgKmwKK+Zr9mtG3Y4RzEeLWRcGS5XLU6aGtRNeTiGuFQe6b
	ttiycZgXjOsYml1deTnTIoZkhVFLy/z4G3RFxVX5sNyrhLnSvR9MPmHmrL8kYzTj9WOy
	aECoWiHQ+z1V2o9w8IE6lFlgTqJPMBjrEK5kB0oaqFgd3BNUAkji8WnDyZHiIj4k3Wol
	Ws6Q==
Received: by 10.14.202.66 with SMTP id c42mr25096837eeo.35.1347361028699;
	Tue, 11 Sep 2012 03:57:08 -0700 (PDT)
Received: from [192.168.1.69] (host86-184-74-117.range86-184.btcentralplus.com.
	[86.184.74.117])
	by mx.google.com with ESMTPS id e7sm46067168eep.2.2012.09.11.03.57.06
	(version=SSLv3 cipher=OTHER); Tue, 11 Sep 2012 03:57:07 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Tue, 11 Sep 2012 11:57:00 +0100
From: Keir Fraser <keir.xen@gmail.com>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <CC74D78C.3E773%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [ANNOUNCE] Xen x86 32-bit hypervisor end of life
	after 4.2
Thread-Index: Ac2QDCsOOqZ7z8My/0e+AJCSXgwp1Q==
In-Reply-To: <504F33E1020000780009A8A7@nat28.tlf.novell.com>
Mime-version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [ANNOUNCE] Xen x86 32-bit hypervisor end of life
 after 4.2
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/09/2012 11:51, "Jan Beulich" <JBeulich@suse.com> wrote:

>>>> On 11.09.12 at 12:44, Keir Fraser <keir@xen.org> wrote:
>> Okay, I'll stub out in xen/Makefile and install something into
>> dist/install/boot.
> 
> If you're already in the process of doing this, may I ask that you
> please don't remove xen/arch/x86/cpu/centaur.c (as a pending
> patch of mine will make use of this for properly enabling 64-bit
> support on VIA CPUs)?

I'm waiting for the okay from IanJ before I start. And, okay, I won't remove
centaur.c. I will probably just do a rough prune to start with anyway, then
others can go in and help finish the job off.

 -- Keir

> Jan
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 11 10:57:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 2012 10:57:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TBO9Y-0005ZI-Aq; Tue, 11 Sep 2012 10:57:12 +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 1TBO9W-0005ZA-Le
	for xen-devel@lists.xen.org; Tue, 11 Sep 2012 10:57:11 +0000
Received: from [85.158.139.83:36174] by server-7.bemta-5.messagelabs.com id
	5B/3A-19703-5091F405; Tue, 11 Sep 2012 10:57:09 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1347361028!25547804!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-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5322 invoked from network); 11 Sep 2012 10:57:09 -0000
Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com)
	(74.125.83.45)
	by server-14.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Sep 2012 10:57:09 -0000
Received: by eeke53 with SMTP id e53so300267eek.32
	for <xen-devel@lists.xen.org>; Tue, 11 Sep 2012 03:57:08 -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=2OCgCOkPVOTXt3X7p5MCPxdNPDw62U3S+IMPEbrJaIc=;
	b=BirXl/XdX92e+ECewJv7E9L6wli9s50I48WhK9B+vRMvxDGJQPvLxVuRhT1TkTYq8m
	zjShkXKnyKH9V86CziXOfgbPxbIbVpJw6n3QcMBVbGb1Q0aEOECE0ln35eDw+uqZf2U5
	P0Qg9gLuASFbksE4ZWFT4IgKmwKK+Zr9mtG3Y4RzEeLWRcGS5XLU6aGtRNeTiGuFQe6b
	ttiycZgXjOsYml1deTnTIoZkhVFLy/z4G3RFxVX5sNyrhLnSvR9MPmHmrL8kYzTj9WOy
	aECoWiHQ+z1V2o9w8IE6lFlgTqJPMBjrEK5kB0oaqFgd3BNUAkji8WnDyZHiIj4k3Wol
	Ws6Q==
Received: by 10.14.202.66 with SMTP id c42mr25096837eeo.35.1347361028699;
	Tue, 11 Sep 2012 03:57:08 -0700 (PDT)
Received: from [192.168.1.69] (host86-184-74-117.range86-184.btcentralplus.com.
	[86.184.74.117])
	by mx.google.com with ESMTPS id e7sm46067168eep.2.2012.09.11.03.57.06
	(version=SSLv3 cipher=OTHER); Tue, 11 Sep 2012 03:57:07 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Tue, 11 Sep 2012 11:57:00 +0100
From: Keir Fraser <keir.xen@gmail.com>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <CC74D78C.3E773%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [ANNOUNCE] Xen x86 32-bit hypervisor end of life
	after 4.2
Thread-Index: Ac2QDCsOOqZ7z8My/0e+AJCSXgwp1Q==
In-Reply-To: <504F33E1020000780009A8A7@nat28.tlf.novell.com>
Mime-version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [ANNOUNCE] Xen x86 32-bit hypervisor end of life
 after 4.2
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/09/2012 11:51, "Jan Beulich" <JBeulich@suse.com> wrote:

>>>> On 11.09.12 at 12:44, Keir Fraser <keir@xen.org> wrote:
>> Okay, I'll stub out in xen/Makefile and install something into
>> dist/install/boot.
> 
> If you're already in the process of doing this, may I ask that you
> please don't remove xen/arch/x86/cpu/centaur.c (as a pending
> patch of mine will make use of this for properly enabling 64-bit
> support on VIA CPUs)?

I'm waiting for the okay from IanJ before I start. And, okay, I won't remove
centaur.c. I will probably just do a rough prune to start with anyway, then
others can go in and help finish the job off.

 -- Keir

> Jan
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 11 11:30:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 2012 11:30:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TBOf7-00064U-DB; Tue, 11 Sep 2012 11:29: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 1TBOf6-00064O-6N
	for xen-devel@lists.xen.org; Tue, 11 Sep 2012 11:29:48 +0000
Received: from [85.158.139.83:19291] by server-1.bemta-5.messagelabs.com id
	6C/3B-32692-BA02F405; Tue, 11 Sep 2012 11:29:47 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1347362986!29801769!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQwNzc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11000 invoked from network); 11 Sep 2012 11:29:46 -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;
	11 Sep 2012 11:29:46 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 11 Sep 2012 12:29:45 +0100
Message-Id: <504F3CC7020000780009A8C7@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 11 Sep 2012 12:29:43 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__PartE0D1F2B7.0__="
Subject: [Xen-devel] [PATCH] PCI: bus scan adjustments
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=__PartE0D1F2B7.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

As done elsewhere, the ns16550 code shouldn't look at non-zero
functions of a device if that isn't multi-function.

Also both there and in pass-through's _scan_pci_devices() skip looking
at non-zero functions when the device at function zero doesn't exist.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
---
Note that to apply cleanly, this has to go on top of the serial console
improvement series posted earlier.

--- a/xen/drivers/char/ns16550.c
+++ b/xen/drivers/char/ns16550.c
@@ -470,21 +470,28 @@ static int
 pci_uart_config (struct ns16550 *uart, int skip_amt, int bar_idx)
 {
     uint32_t bar, len;
-    int b, d, f;
+    int b, d, f, nextf;
=20
     /* NB. Start at bus 1 to avoid AMT: a plug-in card cannot be on bus =
0. */
     for ( b =3D skip_amt ? 1 : 0; b < 0x100; b++ )
     {
         for ( d =3D 0; d < 0x20; d++ )
         {
-            for ( f =3D 0; f < 0x8; f++ )
+            for ( f =3D 0; f < 8; f =3D nextf )
             {
+                nextf =3D (f || (pci_conf_read16(0, b, d, f, PCI_HEADER_TY=
PE) &
+                               0x80)) ? f + 1 : 8;
+
                 switch ( pci_conf_read16(0, b, d, f, PCI_CLASS_DEVICE) )
                 {
                 case 0x0700: /* single port serial */
                 case 0x0702: /* multi port serial */
                 case 0x0780: /* other (e.g serial+parallel) */
                     break;
+                case 0xffff:
+                    if ( !f )
+                        nextf =3D 8;
+                    /* fall through */
                 default:
                     continue;
                 }
--- a/xen/drivers/passthrough/pci.c
+++ b/xen/drivers/passthrough/pci.c
@@ -665,7 +665,11 @@ static int __init _scan_pci_devices(stru
             for ( func =3D 0; func < 8; func++ )
             {
                 if ( pci_device_detect(pseg->nr, bus, dev, func) =3D=3D 0 =
)
+                {
+                    if ( !func )
+                        break;
                     continue;
+                }
=20
                 pdev =3D alloc_pdev(pseg, bus, PCI_DEVFN(dev, func));
                 if ( !pdev )




--=__PartE0D1F2B7.0__=
Content-Type: text/plain; name="pci-scan-adjust.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="pci-scan-adjust.patch"

PCI: bus scan adjustments=0A=0AAs done elsewhere, the ns16550 code =
shouldn't look at non-zero=0Afunctions of a device if that isn't multi-func=
tion.=0A=0AAlso both there and in pass-through's _scan_pci_devices() skip =
looking=0Aat non-zero functions when the device at function zero doesn't =
exist.=0A=0ASigned-off-by: Jan Beulich <jbeulich@suse.com>=0A---=0ANote =
that to apply cleanly, this has to go on top of the serial console=0Aimprov=
ement series posted earlier.=0A=0A--- a/xen/drivers/char/ns16550.c=0A+++ =
b/xen/drivers/char/ns16550.c=0A@@ -470,21 +470,28 @@ static int=0A =
pci_uart_config (struct ns16550 *uart, int skip_amt, int bar_idx)=0A {=0A  =
   uint32_t bar, len;=0A-    int b, d, f;=0A+    int b, d, f, nextf;=0A =
=0A     /* NB. Start at bus 1 to avoid AMT: a plug-in card cannot be on =
bus 0. */=0A     for ( b =3D skip_amt ? 1 : 0; b < 0x100; b++ )=0A     =
{=0A         for ( d =3D 0; d < 0x20; d++ )=0A         {=0A-            =
for ( f =3D 0; f < 0x8; f++ )=0A+            for ( f =3D 0; f < 8; f =3D =
nextf )=0A             {=0A+                nextf =3D (f || (pci_conf_read1=
6(0, b, d, f, PCI_HEADER_TYPE) &=0A+                               0x80)) =
? f + 1 : 8;=0A+=0A                 switch ( pci_conf_read16(0, b, d, f, =
PCI_CLASS_DEVICE) )=0A                 {=0A                 case 0x0700: =
/* single port serial */=0A                 case 0x0702: /* multi port =
serial */=0A                 case 0x0780: /* other (e.g serial+parallel) =
*/=0A                     break;=0A+                case 0xffff:=0A+       =
             if ( !f )=0A+                        nextf =3D 8;=0A+         =
           /* fall through */=0A                 default:=0A               =
      continue;=0A                 }=0A--- a/xen/drivers/passthrough/pci.c=
=0A+++ b/xen/drivers/passthrough/pci.c=0A@@ -665,7 +665,11 @@ static int =
__init _scan_pci_devices(stru=0A             for ( func =3D 0; func < 8; =
func++ )=0A             {=0A                 if ( pci_device_detect(pseg->n=
r, bus, dev, func) =3D=3D 0 )=0A+                {=0A+                    =
if ( !func )=0A+                        break;=0A                     =
continue;=0A+                }=0A =0A                 pdev =3D alloc_pdev(p=
seg, bus, PCI_DEVFN(dev, func));=0A                 if ( !pdev )=0A
--=__PartE0D1F2B7.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

--=__PartE0D1F2B7.0__=--


From xen-devel-bounces@lists.xen.org Tue Sep 11 11:30:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 2012 11:30:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TBOf7-00064U-DB; Tue, 11 Sep 2012 11:29: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 1TBOf6-00064O-6N
	for xen-devel@lists.xen.org; Tue, 11 Sep 2012 11:29:48 +0000
Received: from [85.158.139.83:19291] by server-1.bemta-5.messagelabs.com id
	6C/3B-32692-BA02F405; Tue, 11 Sep 2012 11:29:47 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1347362986!29801769!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQwNzc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11000 invoked from network); 11 Sep 2012 11:29:46 -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;
	11 Sep 2012 11:29:46 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 11 Sep 2012 12:29:45 +0100
Message-Id: <504F3CC7020000780009A8C7@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 11 Sep 2012 12:29:43 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__PartE0D1F2B7.0__="
Subject: [Xen-devel] [PATCH] PCI: bus scan adjustments
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=__PartE0D1F2B7.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

As done elsewhere, the ns16550 code shouldn't look at non-zero
functions of a device if that isn't multi-function.

Also both there and in pass-through's _scan_pci_devices() skip looking
at non-zero functions when the device at function zero doesn't exist.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
---
Note that to apply cleanly, this has to go on top of the serial console
improvement series posted earlier.

--- a/xen/drivers/char/ns16550.c
+++ b/xen/drivers/char/ns16550.c
@@ -470,21 +470,28 @@ static int
 pci_uart_config (struct ns16550 *uart, int skip_amt, int bar_idx)
 {
     uint32_t bar, len;
-    int b, d, f;
+    int b, d, f, nextf;
=20
     /* NB. Start at bus 1 to avoid AMT: a plug-in card cannot be on bus =
0. */
     for ( b =3D skip_amt ? 1 : 0; b < 0x100; b++ )
     {
         for ( d =3D 0; d < 0x20; d++ )
         {
-            for ( f =3D 0; f < 0x8; f++ )
+            for ( f =3D 0; f < 8; f =3D nextf )
             {
+                nextf =3D (f || (pci_conf_read16(0, b, d, f, PCI_HEADER_TY=
PE) &
+                               0x80)) ? f + 1 : 8;
+
                 switch ( pci_conf_read16(0, b, d, f, PCI_CLASS_DEVICE) )
                 {
                 case 0x0700: /* single port serial */
                 case 0x0702: /* multi port serial */
                 case 0x0780: /* other (e.g serial+parallel) */
                     break;
+                case 0xffff:
+                    if ( !f )
+                        nextf =3D 8;
+                    /* fall through */
                 default:
                     continue;
                 }
--- a/xen/drivers/passthrough/pci.c
+++ b/xen/drivers/passthrough/pci.c
@@ -665,7 +665,11 @@ static int __init _scan_pci_devices(stru
             for ( func =3D 0; func < 8; func++ )
             {
                 if ( pci_device_detect(pseg->nr, bus, dev, func) =3D=3D 0 =
)
+                {
+                    if ( !func )
+                        break;
                     continue;
+                }
=20
                 pdev =3D alloc_pdev(pseg, bus, PCI_DEVFN(dev, func));
                 if ( !pdev )




--=__PartE0D1F2B7.0__=
Content-Type: text/plain; name="pci-scan-adjust.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="pci-scan-adjust.patch"

PCI: bus scan adjustments=0A=0AAs done elsewhere, the ns16550 code =
shouldn't look at non-zero=0Afunctions of a device if that isn't multi-func=
tion.=0A=0AAlso both there and in pass-through's _scan_pci_devices() skip =
looking=0Aat non-zero functions when the device at function zero doesn't =
exist.=0A=0ASigned-off-by: Jan Beulich <jbeulich@suse.com>=0A---=0ANote =
that to apply cleanly, this has to go on top of the serial console=0Aimprov=
ement series posted earlier.=0A=0A--- a/xen/drivers/char/ns16550.c=0A+++ =
b/xen/drivers/char/ns16550.c=0A@@ -470,21 +470,28 @@ static int=0A =
pci_uart_config (struct ns16550 *uart, int skip_amt, int bar_idx)=0A {=0A  =
   uint32_t bar, len;=0A-    int b, d, f;=0A+    int b, d, f, nextf;=0A =
=0A     /* NB. Start at bus 1 to avoid AMT: a plug-in card cannot be on =
bus 0. */=0A     for ( b =3D skip_amt ? 1 : 0; b < 0x100; b++ )=0A     =
{=0A         for ( d =3D 0; d < 0x20; d++ )=0A         {=0A-            =
for ( f =3D 0; f < 0x8; f++ )=0A+            for ( f =3D 0; f < 8; f =3D =
nextf )=0A             {=0A+                nextf =3D (f || (pci_conf_read1=
6(0, b, d, f, PCI_HEADER_TYPE) &=0A+                               0x80)) =
? f + 1 : 8;=0A+=0A                 switch ( pci_conf_read16(0, b, d, f, =
PCI_CLASS_DEVICE) )=0A                 {=0A                 case 0x0700: =
/* single port serial */=0A                 case 0x0702: /* multi port =
serial */=0A                 case 0x0780: /* other (e.g serial+parallel) =
*/=0A                     break;=0A+                case 0xffff:=0A+       =
             if ( !f )=0A+                        nextf =3D 8;=0A+         =
           /* fall through */=0A                 default:=0A               =
      continue;=0A                 }=0A--- a/xen/drivers/passthrough/pci.c=
=0A+++ b/xen/drivers/passthrough/pci.c=0A@@ -665,7 +665,11 @@ static int =
__init _scan_pci_devices(stru=0A             for ( func =3D 0; func < 8; =
func++ )=0A             {=0A                 if ( pci_device_detect(pseg->n=
r, bus, dev, func) =3D=3D 0 )=0A+                {=0A+                    =
if ( !func )=0A+                        break;=0A                     =
continue;=0A+                }=0A =0A                 pdev =3D alloc_pdev(p=
seg, bus, PCI_DEVFN(dev, func));=0A                 if ( !pdev )=0A
--=__PartE0D1F2B7.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

--=__PartE0D1F2B7.0__=--


From xen-devel-bounces@lists.xen.org Tue Sep 11 11:34:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 2012 11:34:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TBOix-0006IC-25; Tue, 11 Sep 2012 11:33:47 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1TBOiv-0006I6-Gd
	for xen-devel@lists.xen.org; Tue, 11 Sep 2012 11:33:45 +0000
Received: from [85.158.139.83:56410] by server-2.bemta-5.messagelabs.com id
	94/0C-11456-8912F405; Tue, 11 Sep 2012 11:33:44 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1347363223!27637055!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQwNzc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19941 invoked from network); 11 Sep 2012 11:33:43 -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;
	11 Sep 2012 11:33:43 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 11 Sep 2012 12:33:43 +0100
Message-Id: <504F3DB3020000780009A8CB@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 11 Sep 2012 12:33:39 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__PartD5E4C783.0__="
Subject: [Xen-devel] [PATCH] PCI: don't allow guest assignment of devices
 used by Xen
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<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.

--=__PartD5E4C783.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

This covers the devices used for the console and the AMD IOMMU ones (as
would be any others that might get passed to pci_ro_device()).

Boot video device determination cloned from similar Linux logic.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
---
Note that to apply cleanly, this has to go on top of the serial console
improvement series posted earlier.

--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -311,9 +311,12 @@ void __init arch_init_memory(void)
      * Initialise our DOMID_XEN domain.
      * Any Xen-heap pages that we will allow to be mapped will have
      * their domain field set to dom_xen.
+     * Hidden PCI devices will also be associated with this domain
+     * (but be [partly] controlled by Dom0 nevertheless).
      */
     dom_xen =3D domain_create(DOMID_XEN, DOMCRF_dummy, 0);
     BUG_ON(IS_ERR(dom_xen));
+    INIT_LIST_HEAD(&dom_xen->arch.pdev_list);
=20
     /*
      * Initialise our DOMID_IO domain.
--- a/xen/drivers/char/ehci-dbgp.c
+++ b/xen/drivers/char/ehci-dbgp.c
@@ -1364,6 +1364,8 @@ static void __init ehci_dbgp_init_postir
     init_timer(&dbgp->timer, ehci_dbgp_poll, port, 0);
=20
     ehci_dbgp_setup_postirq(dbgp);
+
+    pci_hide_device(dbgp->bus, PCI_DEVFN(dbgp->slot, dbgp->func));
 }
=20
 static int ehci_dbgp_check_release(struct ehci_dbgp *dbgp)
--- a/xen/drivers/char/ns16550.c
+++ b/xen/drivers/char/ns16550.c
@@ -334,6 +334,10 @@ static void __init ns16550_init_postirq(
     }
=20
     ns16550_setup_postirq(uart);
+
+    if ( uart->bar || uart->ps_bdf_enable )
+        pci_hide_device(uart->ps_bdf[0], PCI_DEVFN(uart->ps_bdf[1],
+                                                   uart->ps_bdf[2]));
 }
=20
 static void ns16550_suspend(struct serial_port *port)
--- a/xen/drivers/passthrough/iommu.c
+++ b/xen/drivers/passthrough/iommu.c
@@ -208,7 +208,7 @@ static int device_assigned(u16 seg, u8 b
     pdev =3D pci_get_pdev_by_domain(dom0, seg, bus, devfn);
     spin_unlock(&pcidevs_lock);
=20
-    return pdev ? 0 : -1;
+    return pdev ? 0 : -EBUSY;
 }
=20
 static int assign_device(struct domain *d, u16 seg, u8 bus, u8 devfn)
@@ -614,7 +614,8 @@ int iommu_do_domctl(
         bus =3D (domctl->u.assign_device.machine_sbdf >> 8) & 0xff;
         devfn =3D domctl->u.assign_device.machine_sbdf & 0xff;
=20
-        ret =3D assign_device(d, seg, bus, devfn);
+        ret =3D device_assigned(seg, bus, devfn) ?:
+              assign_device(d, seg, bus, devfn);
         if ( ret )
             printk(XENLOG_G_ERR "XEN_DOMCTL_assign_device: "
                    "assign %04x:%02x:%02x.%u to dom%d failed (%d)\n",
--- a/xen/drivers/passthrough/pci.c
+++ b/xen/drivers/passthrough/pci.c
@@ -208,6 +208,31 @@ static void free_pdev(struct pci_seg *ps
     xfree(pdev);
 }
=20
+static void _pci_hide_device(struct pci_dev *pdev)
+{
+    if ( pdev->domain )
+        return;
+    pdev->domain =3D dom_xen;
+    list_add(&pdev->domain_list, &dom_xen->arch.pdev_list);
+}
+
+int __init pci_hide_device(int bus, int devfn)
+{
+    struct pci_dev *pdev;
+    int rc =3D -ENOMEM;
+
+    spin_lock(&pcidevs_lock);
+    pdev =3D alloc_pdev(get_pseg(0), bus, devfn);
+    if ( pdev )
+    {
+        _pci_hide_device(pdev);
+        rc =3D 0;
+    }
+    spin_unlock(&pcidevs_lock);
+
+    return rc;
+}
+
 int __init pci_ro_device(int seg, int bus, int devfn)
 {
     struct pci_seg *pseg =3D alloc_pseg(seg);
@@ -231,6 +256,7 @@ int __init pci_ro_device(int seg, int bu
=20
     __set_bit(PCI_BDF2(bus, devfn), pseg->ro_map);
     arch_pci_ro_device(seg, PCI_BDF2(bus, devfn));
+    _pci_hide_device(pdev);
=20
     return 0;
 }
@@ -718,9 +744,22 @@ static int __init _setup_dom0_pci_device
             if ( !pdev )
                 continue;
=20
-            pdev->domain =3D ctxt->d;
-            list_add(&pdev->domain_list, &ctxt->d->arch.pdev_list);
-            ctxt->handler(pdev);
+            if ( !pdev->domain )
+            {
+                pdev->domain =3D ctxt->d;
+                list_add(&pdev->domain_list, &ctxt->d->arch.pdev_list);
+                ctxt->handler(pdev);
+            }
+            else if ( pdev->domain =3D=3D dom_xen )
+            {
+                pdev->domain =3D ctxt->d;
+                ctxt->handler(pdev);
+                pdev->domain =3D dom_xen;
+            }
+            else if ( pdev->domain !=3D ctxt->d )
+                printk(XENLOG_WARNING "Dom%d owning %04x:%02x:%02x.%u?\n",=

+                       pdev->domain->domain_id, pseg->nr, bus,
+                       PCI_SLOT(devfn), PCI_FUNC(devfn));
         }
     }
=20
--- a/xen/drivers/video/vga.c
+++ b/xen/drivers/video/vga.c
@@ -9,6 +9,7 @@
 #include <xen/lib.h>
 #include <xen/mm.h>
 #include <xen/vga.h>
+#include <xen/pci.h>
 #include <asm/io.h>
=20
 /* Filled in by arch boot code. */
@@ -106,6 +107,61 @@ void __init vga_endboot(void)
=20
     if ( !vgacon_keep )
         vga_puts =3D vga_noop_puts;
+    else
+    {
+        int bus, devfn;
+
+        for ( bus =3D 0; bus < 256; ++bus )
+            for ( devfn =3D 0; devfn < 256; ++devfn )
+            {
+                const struct pci_dev *pdev;
+                u8 b =3D bus, df =3D devfn, sb;
+
+                spin_lock(&pcidevs_lock);
+                pdev =3D pci_get_pdev(0, bus, devfn);
+                spin_unlock(&pcidevs_lock);
+
+                if ( !pdev ||
+                     pci_conf_read16(0, bus, PCI_SLOT(devfn), PCI_FUNC(dev=
fn),
+                                     PCI_CLASS_DEVICE) !=3D 0x0300 ||
+                     !(pci_conf_read16(0, bus, PCI_SLOT(devfn),
+                                       PCI_FUNC(devfn), PCI_COMMAND) &
+                       (PCI_COMMAND_IO | PCI_COMMAND_MEMORY)) )
+                    continue;
+
+                while ( b )
+                {
+                    switch ( find_upstream_bridge(0, &b, &df, &sb) )
+                    {
+                    case 0:
+                        b =3D 0;
+                        break;
+                    case 1:
+                        switch ( pci_conf_read8(0, b, PCI_SLOT(df),
+                                                PCI_FUNC(df),
+                                                PCI_HEADER_TYPE) )
+                        {
+                        case PCI_HEADER_TYPE_BRIDGE:
+                        case PCI_HEADER_TYPE_CARDBUS:
+                            if ( pci_conf_read16(0, b, PCI_SLOT(df),
+                                                 PCI_FUNC(df),
+                                                 PCI_BRIDGE_CONTROL) &
+                                 PCI_BRIDGE_CTL_VGA )
+                                continue;
+                            break;
+                        }
+                        break;
+                    }
+                    break;
+                }
+                if ( !b )
+                {
+                    printk(XENLOG_INFO "Boot video device %02x:%02x.%u\n",=

+                           bus, PCI_SLOT(devfn), PCI_FUNC(devfn));
+                    pci_hide_device(bus, devfn);
+                }
+            }
+    }
=20
     switch ( vga_console_info.video_type )
     {
--- a/xen/include/xen/pci.h
+++ b/xen/include/xen/pci.h
@@ -103,6 +103,7 @@ int pci_add_device(u16 seg, u8 bus, u8 d
 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);
+int pci_hide_device(int bus, int devfn);
 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);



--=__PartD5E4C783.0__=
Content-Type: text/plain; name="pci-disallow-assign.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="pci-disallow-assign.patch"

PCI: don't allow guest assignment of devices used by Xen=0A=0AThis covers =
the devices used for the console and the AMD IOMMU ones (as=0Awould be any =
others that might get passed to pci_ro_device()).=0A=0ABoot video device =
determination cloned from similar Linux logic.=0A=0ASigned-off-by: Jan =
Beulich <jbeulich@suse.com>=0A---=0ANote that to apply cleanly, this has =
to go on top of the serial console=0Aimprovement series posted earlier.=0A=
=0A--- a/xen/arch/x86/mm.c=0A+++ b/xen/arch/x86/mm.c=0A@@ -311,9 +311,12 =
@@ void __init arch_init_memory(void)=0A      * Initialise our DOMID_XEN =
domain.=0A      * Any Xen-heap pages that we will allow to be mapped will =
have=0A      * their domain field set to dom_xen.=0A+     * Hidden PCI =
devices will also be associated with this domain=0A+     * (but be =
[partly] controlled by Dom0 nevertheless).=0A      */=0A     dom_xen =3D =
domain_create(DOMID_XEN, DOMCRF_dummy, 0);=0A     BUG_ON(IS_ERR(dom_xen));=
=0A+    INIT_LIST_HEAD(&dom_xen->arch.pdev_list);=0A =0A     /*=0A      * =
Initialise our DOMID_IO domain.=0A--- a/xen/drivers/char/ehci-dbgp.c=0A+++ =
b/xen/drivers/char/ehci-dbgp.c=0A@@ -1364,6 +1364,8 @@ static void __init =
ehci_dbgp_init_postir=0A     init_timer(&dbgp->timer, ehci_dbgp_poll, =
port, 0);=0A =0A     ehci_dbgp_setup_postirq(dbgp);=0A+=0A+    pci_hide_dev=
ice(dbgp->bus, PCI_DEVFN(dbgp->slot, dbgp->func));=0A }=0A =0A static int =
ehci_dbgp_check_release(struct ehci_dbgp *dbgp)=0A--- a/xen/drivers/char/ns=
16550.c=0A+++ b/xen/drivers/char/ns16550.c=0A@@ -334,6 +334,10 @@ static =
void __init ns16550_init_postirq(=0A     }=0A =0A     ns16550_setup_postirq=
(uart);=0A+=0A+    if ( uart->bar || uart->ps_bdf_enable )=0A+        =
pci_hide_device(uart->ps_bdf[0], PCI_DEVFN(uart->ps_bdf[1],=0A+            =
                                       uart->ps_bdf[2]));=0A }=0A =0A =
static void ns16550_suspend(struct serial_port *port)=0A--- a/xen/drivers/p=
assthrough/iommu.c=0A+++ b/xen/drivers/passthrough/iommu.c=0A@@ -208,7 =
+208,7 @@ static int device_assigned(u16 seg, u8 b=0A     pdev =3D =
pci_get_pdev_by_domain(dom0, seg, bus, devfn);=0A     spin_unlock(&pcidevs_=
lock);=0A =0A-    return pdev ? 0 : -1;=0A+    return pdev ? 0 : -EBUSY;=0A=
 }=0A =0A static int assign_device(struct domain *d, u16 seg, u8 bus, u8 =
devfn)=0A@@ -614,7 +614,8 @@ int iommu_do_domctl(=0A         bus =3D =
(domctl->u.assign_device.machine_sbdf >> 8) & 0xff;=0A         devfn =3D =
domctl->u.assign_device.machine_sbdf & 0xff;=0A =0A-        ret =3D =
assign_device(d, seg, bus, devfn);=0A+        ret =3D device_assigned(seg, =
bus, devfn) ?:=0A+              assign_device(d, seg, bus, devfn);=0A      =
   if ( ret )=0A             printk(XENLOG_G_ERR "XEN_DOMCTL_assign_device:=
 "=0A                    "assign %04x:%02x:%02x.%u to dom%d failed =
(%d)\n",=0A--- a/xen/drivers/passthrough/pci.c=0A+++ b/xen/drivers/passthro=
ugh/pci.c=0A@@ -208,6 +208,31 @@ static void free_pdev(struct pci_seg =
*ps=0A     xfree(pdev);=0A }=0A =0A+static void _pci_hide_device(struct =
pci_dev *pdev)=0A+{=0A+    if ( pdev->domain )=0A+        return;=0A+    =
pdev->domain =3D dom_xen;=0A+    list_add(&pdev->domain_list, &dom_xen->arc=
h.pdev_list);=0A+}=0A+=0A+int __init pci_hide_device(int bus, int =
devfn)=0A+{=0A+    struct pci_dev *pdev;=0A+    int rc =3D -ENOMEM;=0A+=0A+=
    spin_lock(&pcidevs_lock);=0A+    pdev =3D alloc_pdev(get_pseg(0), bus, =
devfn);=0A+    if ( pdev )=0A+    {=0A+        _pci_hide_device(pdev);=0A+ =
       rc =3D 0;=0A+    }=0A+    spin_unlock(&pcidevs_lock);=0A+=0A+    =
return rc;=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@@ -231,6 =
+256,7 @@ int __init pci_ro_device(int seg, int bu=0A =0A     __set_bit(PCI=
_BDF2(bus, devfn), pseg->ro_map);=0A     arch_pci_ro_device(seg, PCI_BDF2(b=
us, devfn));=0A+    _pci_hide_device(pdev);=0A =0A     return 0;=0A }=0A@@ =
-718,9 +744,22 @@ static int __init _setup_dom0_pci_device=0A             =
if ( !pdev )=0A                 continue;=0A =0A-            pdev->domain =
=3D ctxt->d;=0A-            list_add(&pdev->domain_list, &ctxt->d->arch.pde=
v_list);=0A-            ctxt->handler(pdev);=0A+            if ( !pdev->dom=
ain )=0A+            {=0A+                pdev->domain =3D ctxt->d;=0A+    =
            list_add(&pdev->domain_list, &ctxt->d->arch.pdev_list);=0A+    =
            ctxt->handler(pdev);=0A+            }=0A+            else if ( =
pdev->domain =3D=3D dom_xen )=0A+            {=0A+                =
pdev->domain =3D ctxt->d;=0A+                ctxt->handler(pdev);=0A+      =
          pdev->domain =3D dom_xen;=0A+            }=0A+            else =
if ( pdev->domain !=3D ctxt->d )=0A+                printk(XENLOG_WARNING =
"Dom%d owning %04x:%02x:%02x.%u?\n",=0A+                       pdev->domain=
->domain_id, pseg->nr, bus,=0A+                       PCI_SLOT(devfn), =
PCI_FUNC(devfn));=0A         }=0A     }=0A =0A--- a/xen/drivers/video/vga.c=
=0A+++ b/xen/drivers/video/vga.c=0A@@ -9,6 +9,7 @@=0A #include <xen/lib.h>=
=0A #include <xen/mm.h>=0A #include <xen/vga.h>=0A+#include <xen/pci.h>=0A =
#include <asm/io.h>=0A =0A /* Filled in by arch boot code. */=0A@@ -106,6 =
+107,61 @@ void __init vga_endboot(void)=0A =0A     if ( !vgacon_keep )=0A =
        vga_puts =3D vga_noop_puts;=0A+    else=0A+    {=0A+        int =
bus, devfn;=0A+=0A+        for ( bus =3D 0; bus < 256; ++bus )=0A+         =
   for ( devfn =3D 0; devfn < 256; ++devfn )=0A+            {=0A+          =
      const struct pci_dev *pdev;=0A+                u8 b =3D bus, df =3D =
devfn, sb;=0A+=0A+                spin_lock(&pcidevs_lock);=0A+            =
    pdev =3D pci_get_pdev(0, bus, devfn);=0A+                spin_unlock(&p=
cidevs_lock);=0A+=0A+                if ( !pdev ||=0A+                     =
pci_conf_read16(0, bus, PCI_SLOT(devfn), PCI_FUNC(devfn),=0A+              =
                       PCI_CLASS_DEVICE) !=3D 0x0300 ||=0A+                =
     !(pci_conf_read16(0, bus, PCI_SLOT(devfn),=0A+                        =
               PCI_FUNC(devfn), PCI_COMMAND) &=0A+                       =
(PCI_COMMAND_IO | PCI_COMMAND_MEMORY)) )=0A+                    =
continue;=0A+=0A+                while ( b )=0A+                {=0A+      =
              switch ( find_upstream_bridge(0, &b, &df, &sb) )=0A+         =
           {=0A+                    case 0:=0A+                        b =
=3D 0;=0A+                        break;=0A+                    case =
1:=0A+                        switch ( pci_conf_read8(0, b, PCI_SLOT(df),=
=0A+                                                PCI_FUNC(df),=0A+      =
                                          PCI_HEADER_TYPE) )=0A+           =
             {=0A+                        case PCI_HEADER_TYPE_BRIDGE:=0A+ =
                       case PCI_HEADER_TYPE_CARDBUS:=0A+                   =
         if ( pci_conf_read16(0, b, PCI_SLOT(df),=0A+                      =
                           PCI_FUNC(df),=0A+                               =
                  PCI_BRIDGE_CONTROL) &=0A+                                =
 PCI_BRIDGE_CTL_VGA )=0A+                                continue;=0A+     =
                       break;=0A+                        }=0A+             =
           break;=0A+                    }=0A+                    =
break;=0A+                }=0A+                if ( !b )=0A+               =
 {=0A+                    printk(XENLOG_INFO "Boot video device %02x:%02x.%=
u\n",=0A+                           bus, PCI_SLOT(devfn), PCI_FUNC(devfn));=
=0A+                    pci_hide_device(bus, devfn);=0A+                =
}=0A+            }=0A+    }=0A =0A     switch ( vga_console_info.video_type=
 )=0A     {=0A--- a/xen/include/xen/pci.h=0A+++ b/xen/include/xen/pci.h=0A@=
@ -103,6 +103,7 @@ int pci_add_device(u16 seg, u8 bus, u8 d=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+int pci_hide_device(int bus, int devfn);=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
--=__PartD5E4C783.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

--=__PartD5E4C783.0__=--


From xen-devel-bounces@lists.xen.org Tue Sep 11 11:34:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 2012 11:34:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TBOix-0006IC-25; Tue, 11 Sep 2012 11:33:47 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1TBOiv-0006I6-Gd
	for xen-devel@lists.xen.org; Tue, 11 Sep 2012 11:33:45 +0000
Received: from [85.158.139.83:56410] by server-2.bemta-5.messagelabs.com id
	94/0C-11456-8912F405; Tue, 11 Sep 2012 11:33:44 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1347363223!27637055!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQwNzc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19941 invoked from network); 11 Sep 2012 11:33:43 -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;
	11 Sep 2012 11:33:43 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 11 Sep 2012 12:33:43 +0100
Message-Id: <504F3DB3020000780009A8CB@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 11 Sep 2012 12:33:39 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__PartD5E4C783.0__="
Subject: [Xen-devel] [PATCH] PCI: don't allow guest assignment of devices
 used by Xen
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<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.

--=__PartD5E4C783.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

This covers the devices used for the console and the AMD IOMMU ones (as
would be any others that might get passed to pci_ro_device()).

Boot video device determination cloned from similar Linux logic.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
---
Note that to apply cleanly, this has to go on top of the serial console
improvement series posted earlier.

--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -311,9 +311,12 @@ void __init arch_init_memory(void)
      * Initialise our DOMID_XEN domain.
      * Any Xen-heap pages that we will allow to be mapped will have
      * their domain field set to dom_xen.
+     * Hidden PCI devices will also be associated with this domain
+     * (but be [partly] controlled by Dom0 nevertheless).
      */
     dom_xen =3D domain_create(DOMID_XEN, DOMCRF_dummy, 0);
     BUG_ON(IS_ERR(dom_xen));
+    INIT_LIST_HEAD(&dom_xen->arch.pdev_list);
=20
     /*
      * Initialise our DOMID_IO domain.
--- a/xen/drivers/char/ehci-dbgp.c
+++ b/xen/drivers/char/ehci-dbgp.c
@@ -1364,6 +1364,8 @@ static void __init ehci_dbgp_init_postir
     init_timer(&dbgp->timer, ehci_dbgp_poll, port, 0);
=20
     ehci_dbgp_setup_postirq(dbgp);
+
+    pci_hide_device(dbgp->bus, PCI_DEVFN(dbgp->slot, dbgp->func));
 }
=20
 static int ehci_dbgp_check_release(struct ehci_dbgp *dbgp)
--- a/xen/drivers/char/ns16550.c
+++ b/xen/drivers/char/ns16550.c
@@ -334,6 +334,10 @@ static void __init ns16550_init_postirq(
     }
=20
     ns16550_setup_postirq(uart);
+
+    if ( uart->bar || uart->ps_bdf_enable )
+        pci_hide_device(uart->ps_bdf[0], PCI_DEVFN(uart->ps_bdf[1],
+                                                   uart->ps_bdf[2]));
 }
=20
 static void ns16550_suspend(struct serial_port *port)
--- a/xen/drivers/passthrough/iommu.c
+++ b/xen/drivers/passthrough/iommu.c
@@ -208,7 +208,7 @@ static int device_assigned(u16 seg, u8 b
     pdev =3D pci_get_pdev_by_domain(dom0, seg, bus, devfn);
     spin_unlock(&pcidevs_lock);
=20
-    return pdev ? 0 : -1;
+    return pdev ? 0 : -EBUSY;
 }
=20
 static int assign_device(struct domain *d, u16 seg, u8 bus, u8 devfn)
@@ -614,7 +614,8 @@ int iommu_do_domctl(
         bus =3D (domctl->u.assign_device.machine_sbdf >> 8) & 0xff;
         devfn =3D domctl->u.assign_device.machine_sbdf & 0xff;
=20
-        ret =3D assign_device(d, seg, bus, devfn);
+        ret =3D device_assigned(seg, bus, devfn) ?:
+              assign_device(d, seg, bus, devfn);
         if ( ret )
             printk(XENLOG_G_ERR "XEN_DOMCTL_assign_device: "
                    "assign %04x:%02x:%02x.%u to dom%d failed (%d)\n",
--- a/xen/drivers/passthrough/pci.c
+++ b/xen/drivers/passthrough/pci.c
@@ -208,6 +208,31 @@ static void free_pdev(struct pci_seg *ps
     xfree(pdev);
 }
=20
+static void _pci_hide_device(struct pci_dev *pdev)
+{
+    if ( pdev->domain )
+        return;
+    pdev->domain =3D dom_xen;
+    list_add(&pdev->domain_list, &dom_xen->arch.pdev_list);
+}
+
+int __init pci_hide_device(int bus, int devfn)
+{
+    struct pci_dev *pdev;
+    int rc =3D -ENOMEM;
+
+    spin_lock(&pcidevs_lock);
+    pdev =3D alloc_pdev(get_pseg(0), bus, devfn);
+    if ( pdev )
+    {
+        _pci_hide_device(pdev);
+        rc =3D 0;
+    }
+    spin_unlock(&pcidevs_lock);
+
+    return rc;
+}
+
 int __init pci_ro_device(int seg, int bus, int devfn)
 {
     struct pci_seg *pseg =3D alloc_pseg(seg);
@@ -231,6 +256,7 @@ int __init pci_ro_device(int seg, int bu
=20
     __set_bit(PCI_BDF2(bus, devfn), pseg->ro_map);
     arch_pci_ro_device(seg, PCI_BDF2(bus, devfn));
+    _pci_hide_device(pdev);
=20
     return 0;
 }
@@ -718,9 +744,22 @@ static int __init _setup_dom0_pci_device
             if ( !pdev )
                 continue;
=20
-            pdev->domain =3D ctxt->d;
-            list_add(&pdev->domain_list, &ctxt->d->arch.pdev_list);
-            ctxt->handler(pdev);
+            if ( !pdev->domain )
+            {
+                pdev->domain =3D ctxt->d;
+                list_add(&pdev->domain_list, &ctxt->d->arch.pdev_list);
+                ctxt->handler(pdev);
+            }
+            else if ( pdev->domain =3D=3D dom_xen )
+            {
+                pdev->domain =3D ctxt->d;
+                ctxt->handler(pdev);
+                pdev->domain =3D dom_xen;
+            }
+            else if ( pdev->domain !=3D ctxt->d )
+                printk(XENLOG_WARNING "Dom%d owning %04x:%02x:%02x.%u?\n",=

+                       pdev->domain->domain_id, pseg->nr, bus,
+                       PCI_SLOT(devfn), PCI_FUNC(devfn));
         }
     }
=20
--- a/xen/drivers/video/vga.c
+++ b/xen/drivers/video/vga.c
@@ -9,6 +9,7 @@
 #include <xen/lib.h>
 #include <xen/mm.h>
 #include <xen/vga.h>
+#include <xen/pci.h>
 #include <asm/io.h>
=20
 /* Filled in by arch boot code. */
@@ -106,6 +107,61 @@ void __init vga_endboot(void)
=20
     if ( !vgacon_keep )
         vga_puts =3D vga_noop_puts;
+    else
+    {
+        int bus, devfn;
+
+        for ( bus =3D 0; bus < 256; ++bus )
+            for ( devfn =3D 0; devfn < 256; ++devfn )
+            {
+                const struct pci_dev *pdev;
+                u8 b =3D bus, df =3D devfn, sb;
+
+                spin_lock(&pcidevs_lock);
+                pdev =3D pci_get_pdev(0, bus, devfn);
+                spin_unlock(&pcidevs_lock);
+
+                if ( !pdev ||
+                     pci_conf_read16(0, bus, PCI_SLOT(devfn), PCI_FUNC(dev=
fn),
+                                     PCI_CLASS_DEVICE) !=3D 0x0300 ||
+                     !(pci_conf_read16(0, bus, PCI_SLOT(devfn),
+                                       PCI_FUNC(devfn), PCI_COMMAND) &
+                       (PCI_COMMAND_IO | PCI_COMMAND_MEMORY)) )
+                    continue;
+
+                while ( b )
+                {
+                    switch ( find_upstream_bridge(0, &b, &df, &sb) )
+                    {
+                    case 0:
+                        b =3D 0;
+                        break;
+                    case 1:
+                        switch ( pci_conf_read8(0, b, PCI_SLOT(df),
+                                                PCI_FUNC(df),
+                                                PCI_HEADER_TYPE) )
+                        {
+                        case PCI_HEADER_TYPE_BRIDGE:
+                        case PCI_HEADER_TYPE_CARDBUS:
+                            if ( pci_conf_read16(0, b, PCI_SLOT(df),
+                                                 PCI_FUNC(df),
+                                                 PCI_BRIDGE_CONTROL) &
+                                 PCI_BRIDGE_CTL_VGA )
+                                continue;
+                            break;
+                        }
+                        break;
+                    }
+                    break;
+                }
+                if ( !b )
+                {
+                    printk(XENLOG_INFO "Boot video device %02x:%02x.%u\n",=

+                           bus, PCI_SLOT(devfn), PCI_FUNC(devfn));
+                    pci_hide_device(bus, devfn);
+                }
+            }
+    }
=20
     switch ( vga_console_info.video_type )
     {
--- a/xen/include/xen/pci.h
+++ b/xen/include/xen/pci.h
@@ -103,6 +103,7 @@ int pci_add_device(u16 seg, u8 bus, u8 d
 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);
+int pci_hide_device(int bus, int devfn);
 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);



--=__PartD5E4C783.0__=
Content-Type: text/plain; name="pci-disallow-assign.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="pci-disallow-assign.patch"

PCI: don't allow guest assignment of devices used by Xen=0A=0AThis covers =
the devices used for the console and the AMD IOMMU ones (as=0Awould be any =
others that might get passed to pci_ro_device()).=0A=0ABoot video device =
determination cloned from similar Linux logic.=0A=0ASigned-off-by: Jan =
Beulich <jbeulich@suse.com>=0A---=0ANote that to apply cleanly, this has =
to go on top of the serial console=0Aimprovement series posted earlier.=0A=
=0A--- a/xen/arch/x86/mm.c=0A+++ b/xen/arch/x86/mm.c=0A@@ -311,9 +311,12 =
@@ void __init arch_init_memory(void)=0A      * Initialise our DOMID_XEN =
domain.=0A      * Any Xen-heap pages that we will allow to be mapped will =
have=0A      * their domain field set to dom_xen.=0A+     * Hidden PCI =
devices will also be associated with this domain=0A+     * (but be =
[partly] controlled by Dom0 nevertheless).=0A      */=0A     dom_xen =3D =
domain_create(DOMID_XEN, DOMCRF_dummy, 0);=0A     BUG_ON(IS_ERR(dom_xen));=
=0A+    INIT_LIST_HEAD(&dom_xen->arch.pdev_list);=0A =0A     /*=0A      * =
Initialise our DOMID_IO domain.=0A--- a/xen/drivers/char/ehci-dbgp.c=0A+++ =
b/xen/drivers/char/ehci-dbgp.c=0A@@ -1364,6 +1364,8 @@ static void __init =
ehci_dbgp_init_postir=0A     init_timer(&dbgp->timer, ehci_dbgp_poll, =
port, 0);=0A =0A     ehci_dbgp_setup_postirq(dbgp);=0A+=0A+    pci_hide_dev=
ice(dbgp->bus, PCI_DEVFN(dbgp->slot, dbgp->func));=0A }=0A =0A static int =
ehci_dbgp_check_release(struct ehci_dbgp *dbgp)=0A--- a/xen/drivers/char/ns=
16550.c=0A+++ b/xen/drivers/char/ns16550.c=0A@@ -334,6 +334,10 @@ static =
void __init ns16550_init_postirq(=0A     }=0A =0A     ns16550_setup_postirq=
(uart);=0A+=0A+    if ( uart->bar || uart->ps_bdf_enable )=0A+        =
pci_hide_device(uart->ps_bdf[0], PCI_DEVFN(uart->ps_bdf[1],=0A+            =
                                       uart->ps_bdf[2]));=0A }=0A =0A =
static void ns16550_suspend(struct serial_port *port)=0A--- a/xen/drivers/p=
assthrough/iommu.c=0A+++ b/xen/drivers/passthrough/iommu.c=0A@@ -208,7 =
+208,7 @@ static int device_assigned(u16 seg, u8 b=0A     pdev =3D =
pci_get_pdev_by_domain(dom0, seg, bus, devfn);=0A     spin_unlock(&pcidevs_=
lock);=0A =0A-    return pdev ? 0 : -1;=0A+    return pdev ? 0 : -EBUSY;=0A=
 }=0A =0A static int assign_device(struct domain *d, u16 seg, u8 bus, u8 =
devfn)=0A@@ -614,7 +614,8 @@ int iommu_do_domctl(=0A         bus =3D =
(domctl->u.assign_device.machine_sbdf >> 8) & 0xff;=0A         devfn =3D =
domctl->u.assign_device.machine_sbdf & 0xff;=0A =0A-        ret =3D =
assign_device(d, seg, bus, devfn);=0A+        ret =3D device_assigned(seg, =
bus, devfn) ?:=0A+              assign_device(d, seg, bus, devfn);=0A      =
   if ( ret )=0A             printk(XENLOG_G_ERR "XEN_DOMCTL_assign_device:=
 "=0A                    "assign %04x:%02x:%02x.%u to dom%d failed =
(%d)\n",=0A--- a/xen/drivers/passthrough/pci.c=0A+++ b/xen/drivers/passthro=
ugh/pci.c=0A@@ -208,6 +208,31 @@ static void free_pdev(struct pci_seg =
*ps=0A     xfree(pdev);=0A }=0A =0A+static void _pci_hide_device(struct =
pci_dev *pdev)=0A+{=0A+    if ( pdev->domain )=0A+        return;=0A+    =
pdev->domain =3D dom_xen;=0A+    list_add(&pdev->domain_list, &dom_xen->arc=
h.pdev_list);=0A+}=0A+=0A+int __init pci_hide_device(int bus, int =
devfn)=0A+{=0A+    struct pci_dev *pdev;=0A+    int rc =3D -ENOMEM;=0A+=0A+=
    spin_lock(&pcidevs_lock);=0A+    pdev =3D alloc_pdev(get_pseg(0), bus, =
devfn);=0A+    if ( pdev )=0A+    {=0A+        _pci_hide_device(pdev);=0A+ =
       rc =3D 0;=0A+    }=0A+    spin_unlock(&pcidevs_lock);=0A+=0A+    =
return rc;=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@@ -231,6 =
+256,7 @@ int __init pci_ro_device(int seg, int bu=0A =0A     __set_bit(PCI=
_BDF2(bus, devfn), pseg->ro_map);=0A     arch_pci_ro_device(seg, PCI_BDF2(b=
us, devfn));=0A+    _pci_hide_device(pdev);=0A =0A     return 0;=0A }=0A@@ =
-718,9 +744,22 @@ static int __init _setup_dom0_pci_device=0A             =
if ( !pdev )=0A                 continue;=0A =0A-            pdev->domain =
=3D ctxt->d;=0A-            list_add(&pdev->domain_list, &ctxt->d->arch.pde=
v_list);=0A-            ctxt->handler(pdev);=0A+            if ( !pdev->dom=
ain )=0A+            {=0A+                pdev->domain =3D ctxt->d;=0A+    =
            list_add(&pdev->domain_list, &ctxt->d->arch.pdev_list);=0A+    =
            ctxt->handler(pdev);=0A+            }=0A+            else if ( =
pdev->domain =3D=3D dom_xen )=0A+            {=0A+                =
pdev->domain =3D ctxt->d;=0A+                ctxt->handler(pdev);=0A+      =
          pdev->domain =3D dom_xen;=0A+            }=0A+            else =
if ( pdev->domain !=3D ctxt->d )=0A+                printk(XENLOG_WARNING =
"Dom%d owning %04x:%02x:%02x.%u?\n",=0A+                       pdev->domain=
->domain_id, pseg->nr, bus,=0A+                       PCI_SLOT(devfn), =
PCI_FUNC(devfn));=0A         }=0A     }=0A =0A--- a/xen/drivers/video/vga.c=
=0A+++ b/xen/drivers/video/vga.c=0A@@ -9,6 +9,7 @@=0A #include <xen/lib.h>=
=0A #include <xen/mm.h>=0A #include <xen/vga.h>=0A+#include <xen/pci.h>=0A =
#include <asm/io.h>=0A =0A /* Filled in by arch boot code. */=0A@@ -106,6 =
+107,61 @@ void __init vga_endboot(void)=0A =0A     if ( !vgacon_keep )=0A =
        vga_puts =3D vga_noop_puts;=0A+    else=0A+    {=0A+        int =
bus, devfn;=0A+=0A+        for ( bus =3D 0; bus < 256; ++bus )=0A+         =
   for ( devfn =3D 0; devfn < 256; ++devfn )=0A+            {=0A+          =
      const struct pci_dev *pdev;=0A+                u8 b =3D bus, df =3D =
devfn, sb;=0A+=0A+                spin_lock(&pcidevs_lock);=0A+            =
    pdev =3D pci_get_pdev(0, bus, devfn);=0A+                spin_unlock(&p=
cidevs_lock);=0A+=0A+                if ( !pdev ||=0A+                     =
pci_conf_read16(0, bus, PCI_SLOT(devfn), PCI_FUNC(devfn),=0A+              =
                       PCI_CLASS_DEVICE) !=3D 0x0300 ||=0A+                =
     !(pci_conf_read16(0, bus, PCI_SLOT(devfn),=0A+                        =
               PCI_FUNC(devfn), PCI_COMMAND) &=0A+                       =
(PCI_COMMAND_IO | PCI_COMMAND_MEMORY)) )=0A+                    =
continue;=0A+=0A+                while ( b )=0A+                {=0A+      =
              switch ( find_upstream_bridge(0, &b, &df, &sb) )=0A+         =
           {=0A+                    case 0:=0A+                        b =
=3D 0;=0A+                        break;=0A+                    case =
1:=0A+                        switch ( pci_conf_read8(0, b, PCI_SLOT(df),=
=0A+                                                PCI_FUNC(df),=0A+      =
                                          PCI_HEADER_TYPE) )=0A+           =
             {=0A+                        case PCI_HEADER_TYPE_BRIDGE:=0A+ =
                       case PCI_HEADER_TYPE_CARDBUS:=0A+                   =
         if ( pci_conf_read16(0, b, PCI_SLOT(df),=0A+                      =
                           PCI_FUNC(df),=0A+                               =
                  PCI_BRIDGE_CONTROL) &=0A+                                =
 PCI_BRIDGE_CTL_VGA )=0A+                                continue;=0A+     =
                       break;=0A+                        }=0A+             =
           break;=0A+                    }=0A+                    =
break;=0A+                }=0A+                if ( !b )=0A+               =
 {=0A+                    printk(XENLOG_INFO "Boot video device %02x:%02x.%=
u\n",=0A+                           bus, PCI_SLOT(devfn), PCI_FUNC(devfn));=
=0A+                    pci_hide_device(bus, devfn);=0A+                =
}=0A+            }=0A+    }=0A =0A     switch ( vga_console_info.video_type=
 )=0A     {=0A--- a/xen/include/xen/pci.h=0A+++ b/xen/include/xen/pci.h=0A@=
@ -103,6 +103,7 @@ int pci_add_device(u16 seg, u8 bus, u8 d=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+int pci_hide_device(int bus, int devfn);=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
--=__PartD5E4C783.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

--=__PartD5E4C783.0__=--


From xen-devel-bounces@lists.xen.org Tue Sep 11 11:36:19 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 2012 11:36:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TBOlA-0006Qt-QG; Tue, 11 Sep 2012 11:36:04 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1TBOl9-0006Qj-92
	for xen-devel@lists.xen.org; Tue, 11 Sep 2012 11:36:03 +0000
Received: from [85.158.139.83:33272] by server-3.bemta-5.messagelabs.com id
	FB/10-21836-2222F405; Tue, 11 Sep 2012 11:36:02 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1347363360!22475851!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQwNzc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25591 invoked from network); 11 Sep 2012 11:36:00 -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;
	11 Sep 2012 11:36:00 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 11 Sep 2012 12:36:00 +0100
Message-Id: <504F3E3D020000780009A8D7@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 11 Sep 2012 12:35:57 +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 0/2] x86: construct initial page tables mostly
 statically
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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: x86: construct static parts of 1:1 mapping at build time
2: x86-64: construct static, uniform parts of page tables at build time

Note that to apply cleanly, this has to go on top of the serial console
improvement series posted earlier.

Signed-off-by: Jan Beulich <jbeulich@suse.com>


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 11 11:36:19 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 2012 11:36:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TBOlA-0006Qt-QG; Tue, 11 Sep 2012 11:36:04 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1TBOl9-0006Qj-92
	for xen-devel@lists.xen.org; Tue, 11 Sep 2012 11:36:03 +0000
Received: from [85.158.139.83:33272] by server-3.bemta-5.messagelabs.com id
	FB/10-21836-2222F405; Tue, 11 Sep 2012 11:36:02 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1347363360!22475851!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQwNzc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25591 invoked from network); 11 Sep 2012 11:36:00 -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;
	11 Sep 2012 11:36:00 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 11 Sep 2012 12:36:00 +0100
Message-Id: <504F3E3D020000780009A8D7@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 11 Sep 2012 12:35:57 +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 0/2] x86: construct initial page tables mostly
 statically
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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: x86: construct static parts of 1:1 mapping at build time
2: x86-64: construct static, uniform parts of page tables at build time

Note that to apply cleanly, this has to go on top of the serial console
improvement series posted earlier.

Signed-off-by: Jan Beulich <jbeulich@suse.com>


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 11 11:37:10 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 2012 11: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 1TBOlx-0006VH-7o; Tue, 11 Sep 2012 11:36: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 1TBOlw-0006V3-Ap
	for xen-devel@lists.xen.org; Tue, 11 Sep 2012 11:36:52 +0000
Received: from [85.158.139.83:51093] by server-9.bemta-5.messagelabs.com id
	1E/5E-20529-3522F405; Tue, 11 Sep 2012 11:36:51 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1347363404!25301352!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQwNzc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6140 invoked from network); 11 Sep 2012 11:36:45 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-4.tower-182.messagelabs.com with SMTP;
	11 Sep 2012 11:36:45 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 11 Sep 2012 12:36:44 +0100
Message-Id: <504F3E69020000780009A8DB@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 11 Sep 2012 12:36: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="=__Part0C3D1E59.0__="
Subject: [Xen-devel] [PATCH 1/2] x86: construct static parts of 1:1 mapping
 at build 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>
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.

--=__Part0C3D1E59.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

... rather than at boot time, removing unnecessary redundancy between
EFI and legacy boot code.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/arch/x86/boot/head.S
+++ b/xen/arch/x86/boot/head.S
@@ -124,14 +124,11 @@ __start:
         bt      $29,%edx
         jnc     bad_cpu
         /* Initialise L2 identity-map and xen page table entries (16MB). =
*/
-        mov     $sym_phys(l2_identmap),%edi
         mov     $sym_phys(l2_xenmap),%esi
         mov     $sym_phys(l2_bootmap),%edx
         mov     $0x1e3,%eax                  /* PRESENT+RW+A+D+2MB+GLOBAL =
*/
         mov     $8,%ecx
-1:      mov     %eax,(%edi)
-        add     $8,%edi
-        mov     %eax,(%esi)
+1:      mov     %eax,(%esi)
         add     $8,%esi
         mov     %eax,(%edx)
         add     $8,%edx
@@ -163,54 +160,11 @@ __start:
         mov     %eax,sym_phys(idle_pg_table) + l4_table_offset(DIRECTMAP_V=
IRT_START)*8
         mov     $(sym_phys(l3_xenmap)+7),%eax
         mov     %eax,sym_phys(idle_pg_table) + l4_table_offset(XEN_VIRT_ST=
ART)*8
-#else
-        /* Initialize low and high mappings of memory with 2MB pages */
-        mov     $sym_phys(idle_pg_table_l2),%edi
-        mov     $0xe3,%eax                   /* PRESENT+RW+A+D+2MB */
-1:      mov     %eax,__PAGE_OFFSET>>18(%edi) /* high mapping */
-        stosl                                /* low mapping */
-        add     $4,%edi
-        add     $(1<<L2_PAGETABLE_SHIFT),%eax
-        cmp     $DIRECTMAP_PHYS_END+0xe3,%eax
-        jne     1b
-1:      stosl   /* low mappings cover up to 16MB */
-        add     $4,%edi
-        add     $(1<<L2_PAGETABLE_SHIFT),%eax
-        cmp     $(16<<20)+0xe3,%eax
-        jne     1b
-        /* Initialise L2 fixmap page directory entry. */
-        mov     $(sym_phys(l1_fixmap)+7),%eax
-        mov     %eax,sym_phys(idle_pg_table_l2) + l2_table_offset(FIXADDR_=
TOP-1)*8
-#endif
-
-        /* Initialize 4kB mappings of first 2MB or 4MB of memory. */
-        mov     $sym_phys(l1_identmap),%edi
-        mov     $0x263,%eax                  /* PRESENT+RW+A+D+SMALL_PAGES=
 */
-#if defined(__x86_64__)
-        or      $0x100,%eax                  /* GLOBAL */
-#endif
-        xor     %ecx,%ecx
-1:      stosl
-        add     $4,%edi
-        add     $PAGE_SIZE,%eax
-        inc     %ecx
-        /* VGA hole (0xa0000-0xc0000) should be mapped UC. */
-        cmp     $0xa0,%ecx
-        jne     2f
-        or      $0x10,%eax                   /* +PCD */
-2:      cmp     $0xc0,%ecx
-        jne     2f
-        and     $~0x10,%eax                  /* -PCD */
-2:      cmp     $L1_PAGETABLE_ENTRIES,%ecx
-        jne     1b
-        sub     $(PAGE_SIZE-0x63),%edi
-#if defined(__x86_64__)
+        /* Hook 4kB mappings of first 2MB of memory into L2. */
+        mov     $sym_phys(l1_identmap)+__PAGE_HYPERVISOR,%edi
         mov     %edi,sym_phys(l2_identmap)
         mov     %edi,sym_phys(l2_xenmap)
         mov     %edi,sym_phys(l2_bootmap)
-#else
-        mov     %edi,sym_phys(idle_pg_table_l2)
-        mov     %edi,sym_phys(idle_pg_table_l2) + (__PAGE_OFFSET>>18)
 #endif
=20
         /* Apply relocations to bootstrap trampoline. */
@@ -269,3 +223,25 @@ __high_start:
 #else
 #include "x86_32.S"
 #endif
+
+        .section .data.page_aligned, "aw", @progbits
+        .p2align PAGE_SHIFT
+/*
+ * Mapping of first 2 megabytes of memory. This is mapped with 4kB =
mappings
+ * to avoid type conflicts with fixed-range MTRRs covering the lowest =
megabyte
+ * of physical memory. In any case the VGA hole should be mapped with =
type UC.
+ */
+        .globl l1_identmap
+l1_identmap:
+        pfn =3D 0
+        .rept L1_PAGETABLE_ENTRIES
+        /* VGA hole (0xa0000-0xc0000) should be mapped UC. */
+        .if pfn >=3D 0xa0 && pfn < 0xc0
+        .long (pfn << PAGE_SHIFT) | PAGE_HYPERVISOR_NOCACHE | MAP_SMALL_PA=
GES
+        .else
+        .long (pfn << PAGE_SHIFT) | PAGE_HYPERVISOR | MAP_SMALL_PAGES
+        .endif
+        .long 0
+        pfn =3D pfn + 1
+        .endr
+        .size l1_identmap, . - l1_identmap
--- a/xen/arch/x86/boot/x86_32.S
+++ b/xen/arch/x86/boot/x86_32.S
@@ -108,3 +108,24 @@ ENTRY(boot_cpu_gdt_table)
         .fill (PER_CPU_GDT_ENTRY - FLAT_RING3_DS / 8 - 1), 8, 0
         .quad 0x0000910000000000     /* per-CPU entry (limit =3D=3D cpu) =
*/
         .align PAGE_SIZE,0
+
+#define PAGE_HYPERVISOR         __PAGE_HYPERVISOR
+#define PAGE_HYPERVISOR_NOCACHE __PAGE_HYPERVISOR_NOCACHE
+
+/* Mapping of first 16 megabytes of memory. */
+        .globl idle_pg_table_l2
+idle_pg_table_l2:
+        range =3D 8
+        .irp count, l2_linear_offset(__PAGE_OFFSET), \
+                    (4 * L2_PAGETABLE_ENTRIES - l2_linear_offset(__PAGE_OF=
FSET) - 1)
+        .long sym_phys(l1_identmap) + PAGE_HYPERVISOR, 0
+        pfn =3D 1 << PAGETABLE_ORDER
+        .rept range - 1
+        .long (pfn << PAGE_SHIFT) | PAGE_HYPERVISOR | _PAGE_PSE, 0
+        pfn =3D pfn + (1 << PAGETABLE_ORDER)
+        .endr
+        .fill \count - range, 8, 0
+        range =3D DIRECTMAP_MBYTES / 2
+        .endr
+        .long sym_phys(l1_fixmap) + PAGE_HYPERVISOR, 0
+        .size idle_pg_table_l2, . - idle_pg_table_l2
--- a/xen/arch/x86/boot/x86_64.S
+++ b/xen/arch/x86/boot/x86_64.S
@@ -127,3 +127,15 @@ ENTRY(boot_cpu_compat_gdt_table)
         .fill (PER_CPU_GDT_ENTRY - __HYPERVISOR_CS32 / 8 - 1), 8, 0
         .quad 0x0000910000000000     /* per-CPU entry (limit =3D=3D cpu)  =
    */
         .align PAGE_SIZE, 0
+
+/* Mapping of first 16 megabytes of memory. */
+        .globl l2_identmap
+l2_identmap:
+        .quad 0
+        pfn =3D 0
+        .rept 7
+        pfn =3D pfn + (1 << PAGETABLE_ORDER)
+        .quad (pfn << PAGE_SHIFT) | PAGE_HYPERVISOR | _PAGE_PSE
+        .endr
+        .fill 4 * L2_PAGETABLE_ENTRIES - 8, 8, 0
+        .size l2_identmap, . - l2_identmap
--- a/xen/arch/x86/efi/boot.c
+++ b/xen/arch/x86/efi/boot.c
@@ -1119,8 +1119,6 @@ efi_start(EFI_HANDLE ImageHandle, EFI_SY
         unsigned int slot =3D (xen_phys_start >> L2_PAGETABLE_SHIFT) + i;
         paddr_t addr =3D slot << L2_PAGETABLE_SHIFT;
=20
-        l2_identmap[i] =3D l2e_from_paddr(i << L2_PAGETABLE_SHIFT,
-                                        PAGE_HYPERVISOR|_PAGE_PSE);
         l2_identmap[slot] =3D l2e_from_paddr(addr, PAGE_HYPERVISOR|_PAGE_P=
SE);
         l2_xenmap[i] =3D l2e_from_paddr(addr, PAGE_HYPERVISOR|_PAGE_PSE);
         slot &=3D L2_PAGETABLE_ENTRIES - 1;
@@ -1150,16 +1148,7 @@ efi_start(EFI_HANDLE ImageHandle, EFI_SY
         l4e_from_paddr((UINTN)l3_identmap, __PAGE_HYPERVISOR);
     idle_pg_table[l4_table_offset(XEN_VIRT_START)] =3D
         l4e_from_paddr((UINTN)l3_xenmap, __PAGE_HYPERVISOR);
-    /* Initialize 4kB mappings of first 2MB of memory. */
-    for ( i =3D 0; i < L1_PAGETABLE_ENTRIES; ++i )
-    {
-        unsigned int attr =3D PAGE_HYPERVISOR|MAP_SMALL_PAGES;
-
-        /* VGA hole (0xa0000-0xc0000) should be mapped UC. */
-        if ( i >=3D 0xa0 && i < 0xc0 )
-            attr |=3D _PAGE_PCD;
-        l1_identmap[i] =3D l1e_from_pfn(i, attr);
-    }
+    /* Hook 4kB mappings of first 2MB of memory into L2. */
     l2_identmap[0] =3D l2e_from_paddr((UINTN)l1_identmap, __PAGE_HYPERVISO=
R);
=20
     if ( gop )
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -121,15 +121,6 @@
 #include <asm/setup.h>
 #include <asm/fixmap.h>
=20
-/*
- * Mapping of first 2 or 4 megabytes of memory. This is mapped with 4kB
- * mappings to avoid type conflicts with fixed-range MTRRs covering the
- * lowest megabyte of physical memory. In any case the VGA hole should be
- * mapped with type UC.
- */
-l1_pgentry_t __attribute__ ((__section__ (".bss.page_aligned")))
-    l1_identmap[L1_PAGETABLE_ENTRIES];
-
 /* Mapping of the fixmap space needed early. */
 l1_pgentry_t __attribute__ ((__section__ (".bss.page_aligned")))
     l1_fixmap[L1_PAGETABLE_ENTRIES];
--- a/xen/arch/x86/x86_32/mm.c
+++ b/xen/arch/x86/x86_32/mm.c
@@ -31,9 +31,6 @@
 #include <asm/setup.h>
 #include <public/memory.h>
=20
-l2_pgentry_t __attribute__ ((__section__ (".bss.page_aligned")))
-    idle_pg_table_l2[4 * L2_PAGETABLE_ENTRIES];
-
 unsigned int __read_mostly PAGE_HYPERVISOR         =3D __PAGE_HYPERVISOR;
 unsigned int __read_mostly PAGE_HYPERVISOR_NOCACHE =3D __PAGE_HYPERVISOR_N=
OCACHE;
=20
--- a/xen/arch/x86/x86_64/mm.c
+++ b/xen/arch/x86/x86_64/mm.c
@@ -56,8 +56,6 @@ l4_pgentry_t __attribute__ ((__section__
 /* Enough page directories to map bottom 4GB of the memory map. */
 l3_pgentry_t __attribute__ ((__section__ (".bss.page_aligned")))
     l3_identmap[L3_PAGETABLE_ENTRIES];
-l2_pgentry_t __attribute__ ((__section__ (".bss.page_aligned")))
-    l2_identmap[4*L2_PAGETABLE_ENTRIES];
=20
 /* Enough page directories to map the Xen text and static data. */
 l3_pgentry_t __attribute__ ((__section__ (".bss.page_aligned")))
--- a/xen/include/asm-x86/page.h
+++ b/xen/include/asm-x86/page.h
@@ -1,15 +1,13 @@
 #ifndef __X86_PAGE_H__
 #define __X86_PAGE_H__
=20
+#include <xen/const.h>
+
 /*
  * It is important that the masks are signed quantities. This ensures =
that
  * the compiler sign-extends a 32-bit mask to 64 bits if that is =
required.
  */
-#ifndef __ASSEMBLY__
-#define PAGE_SIZE           (1L << PAGE_SHIFT)
-#else
-#define PAGE_SIZE           (1 << PAGE_SHIFT)
-#endif
+#define PAGE_SIZE           (_AC(1,L) << PAGE_SHIFT)
 #define PAGE_MASK           (~(PAGE_SIZE-1))
 #define PAGE_FLAG_MASK      (~0)
=20
@@ -319,21 +317,22 @@ void paging_init(void);
 void setup_idle_pagetable(void);
 #endif /* !defined(__ASSEMBLY__) */
=20
-#define _PAGE_PRESENT  0x001U
-#define _PAGE_RW       0x002U
-#define _PAGE_USER     0x004U
-#define _PAGE_PWT      0x008U
-#define _PAGE_PCD      0x010U
-#define _PAGE_ACCESSED 0x020U
-#define _PAGE_DIRTY    0x040U
-#define _PAGE_PAT      0x080U
-#define _PAGE_PSE      0x080U
-#define _PAGE_GLOBAL   0x100U
-#define _PAGE_AVAIL0   0x200U
-#define _PAGE_AVAIL1   0x400U
-#define _PAGE_AVAIL2   0x800U
-#define _PAGE_AVAIL    0xE00U
-#define _PAGE_PSE_PAT 0x1000U
+#define _PAGE_PRESENT  _AC(0x001,U)
+#define _PAGE_RW       _AC(0x002,U)
+#define _PAGE_USER     _AC(0x004,U)
+#define _PAGE_PWT      _AC(0x008,U)
+#define _PAGE_PCD      _AC(0x010,U)
+#define _PAGE_ACCESSED _AC(0x020,U)
+#define _PAGE_DIRTY    _AC(0x040,U)
+#define _PAGE_PAT      _AC(0x080,U)
+#define _PAGE_PSE      _AC(0x080,U)
+#define _PAGE_GLOBAL   _AC(0x100,U)
+#define _PAGE_AVAIL0   _AC(0x200,U)
+#define _PAGE_AVAIL1   _AC(0x400,U)
+#define _PAGE_AVAIL2   _AC(0x800,U)
+#define _PAGE_AVAIL    _AC(0xE00,U)
+#define _PAGE_PSE_PAT _AC(0x1000,U)
+/* non-architectural flags */
 #define _PAGE_PAGED   0x2000U
 #define _PAGE_SHARED  0x4000U
=20
@@ -354,6 +353,8 @@ void setup_idle_pagetable(void);
 #define __PAGE_HYPERVISOR_NOCACHE \
     (_PAGE_PRESENT | _PAGE_RW | _PAGE_DIRTY | _PAGE_PCD | _PAGE_ACCESSED)
=20
+#define MAP_SMALL_PAGES _PAGE_AVAIL0 /* don't use superpages mappings */
+
 #ifndef __ASSEMBLY__
=20
 /* Allocator functions for Xen pagetables. */
@@ -367,7 +368,6 @@ l3_pgentry_t *virt_to_xen_l3e(unsigned l
 extern void set_pdx_range(unsigned long smfn, unsigned long emfn);
=20
 /* Map machine page range in Xen virtual address space. */
-#define MAP_SMALL_PAGES _PAGE_AVAIL0 /* don't use superpages for the =
mapping */
 int map_pages_to_xen(
     unsigned long virt,
     unsigned long mfn,



--=__Part0C3D1E59.0__=
Content-Type: text/plain; name="x86-build-ident-map.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="x86-build-ident-map.patch"

x86: construct static parts of 1:1 mapping at build time=0A=0A... rather =
than at boot time, removing unnecessary redundancy between=0AEFI and =
legacy boot code.=0A=0ASigned-off-by: Jan Beulich <jbeulich@suse.com>=0A=0A=
--- a/xen/arch/x86/boot/head.S=0A+++ b/xen/arch/x86/boot/head.S=0A@@ =
-124,14 +124,11 @@ __start:=0A         bt      $29,%edx=0A         jnc     =
bad_cpu=0A         /* Initialise L2 identity-map and xen page table =
entries (16MB). */=0A-        mov     $sym_phys(l2_identmap),%edi=0A       =
  mov     $sym_phys(l2_xenmap),%esi=0A         mov     $sym_phys(l2_bootmap=
),%edx=0A         mov     $0x1e3,%eax                  /* PRESENT+RW+A+D+2M=
B+GLOBAL */=0A         mov     $8,%ecx=0A-1:      mov     %eax,(%edi)=0A-  =
      add     $8,%edi=0A-        mov     %eax,(%esi)=0A+1:      mov     =
%eax,(%esi)=0A         add     $8,%esi=0A         mov     %eax,(%edx)=0A   =
      add     $8,%edx=0A@@ -163,54 +160,11 @@ __start:=0A         mov     =
%eax,sym_phys(idle_pg_table) + l4_table_offset(DIRECTMAP_VIRT_START)*8=0A  =
       mov     $(sym_phys(l3_xenmap)+7),%eax=0A         mov     %eax,sym_ph=
ys(idle_pg_table) + l4_table_offset(XEN_VIRT_START)*8=0A-#else=0A-        =
/* Initialize low and high mappings of memory with 2MB pages */=0A-        =
mov     $sym_phys(idle_pg_table_l2),%edi=0A-        mov     $0xe3,%eax     =
              /* PRESENT+RW+A+D+2MB */=0A-1:      mov     %eax,__PAGE_OFFSE=
T>>18(%edi) /* high mapping */=0A-        stosl                            =
    /* low mapping */=0A-        add     $4,%edi=0A-        add     =
$(1<<L2_PAGETABLE_SHIFT),%eax=0A-        cmp     $DIRECTMAP_PHYS_END+0xe3,%=
eax=0A-        jne     1b=0A-1:      stosl   /* low mappings cover up to =
16MB */=0A-        add     $4,%edi=0A-        add     $(1<<L2_PAGETABLE_SHI=
FT),%eax=0A-        cmp     $(16<<20)+0xe3,%eax=0A-        jne     1b=0A-  =
      /* Initialise L2 fixmap page directory entry. */=0A-        mov     =
$(sym_phys(l1_fixmap)+7),%eax=0A-        mov     %eax,sym_phys(idle_pg_tabl=
e_l2) + l2_table_offset(FIXADDR_TOP-1)*8=0A-#endif=0A-=0A-        /* =
Initialize 4kB mappings of first 2MB or 4MB of memory. */=0A-        mov   =
  $sym_phys(l1_identmap),%edi=0A-        mov     $0x263,%eax               =
   /* PRESENT+RW+A+D+SMALL_PAGES */=0A-#if defined(__x86_64__)=0A-        =
or      $0x100,%eax                  /* GLOBAL */=0A-#endif=0A-        xor =
    %ecx,%ecx=0A-1:      stosl=0A-        add     $4,%edi=0A-        add   =
  $PAGE_SIZE,%eax=0A-        inc     %ecx=0A-        /* VGA hole (0xa0000-0=
xc0000) should be mapped UC. */=0A-        cmp     $0xa0,%ecx=0A-        =
jne     2f=0A-        or      $0x10,%eax                   /* +PCD =
*/=0A-2:      cmp     $0xc0,%ecx=0A-        jne     2f=0A-        and     =
$~0x10,%eax                  /* -PCD */=0A-2:      cmp     $L1_PAGETABLE_EN=
TRIES,%ecx=0A-        jne     1b=0A-        sub     $(PAGE_SIZE-0x63),%edi=
=0A-#if defined(__x86_64__)=0A+        /* Hook 4kB mappings of first 2MB =
of memory into L2. */=0A+        mov     $sym_phys(l1_identmap)+__PAGE_HYPE=
RVISOR,%edi=0A         mov     %edi,sym_phys(l2_identmap)=0A         mov   =
  %edi,sym_phys(l2_xenmap)=0A         mov     %edi,sym_phys(l2_bootmap)=0A-=
#else=0A-        mov     %edi,sym_phys(idle_pg_table_l2)=0A-        mov    =
 %edi,sym_phys(idle_pg_table_l2) + (__PAGE_OFFSET>>18)=0A #endif=0A =0A    =
     /* Apply relocations to bootstrap trampoline. */=0A@@ -269,3 +223,25 =
@@ __high_start:=0A #else=0A #include "x86_32.S"=0A #endif=0A+=0A+        =
.section .data.page_aligned, "aw", @progbits=0A+        .p2align PAGE_SHIFT=
=0A+/*=0A+ * Mapping of first 2 megabytes of memory. This is mapped with =
4kB mappings=0A+ * to avoid type conflicts with fixed-range MTRRs covering =
the lowest megabyte=0A+ * of physical memory. In any case the VGA hole =
should be mapped with type UC.=0A+ */=0A+        .globl l1_identmap=0A+l1_i=
dentmap:=0A+        pfn =3D 0=0A+        .rept L1_PAGETABLE_ENTRIES=0A+    =
    /* VGA hole (0xa0000-0xc0000) should be mapped UC. */=0A+        .if =
pfn >=3D 0xa0 && pfn < 0xc0=0A+        .long (pfn << PAGE_SHIFT) | =
PAGE_HYPERVISOR_NOCACHE | MAP_SMALL_PAGES=0A+        .else=0A+        =
.long (pfn << PAGE_SHIFT) | PAGE_HYPERVISOR | MAP_SMALL_PAGES=0A+        =
.endif=0A+        .long 0=0A+        pfn =3D pfn + 1=0A+        .endr=0A+  =
      .size l1_identmap, . - l1_identmap=0A--- a/xen/arch/x86/boot/x86_32.S=
=0A+++ b/xen/arch/x86/boot/x86_32.S=0A@@ -108,3 +108,24 @@ ENTRY(boot_cpu_g=
dt_table)=0A         .fill (PER_CPU_GDT_ENTRY - FLAT_RING3_DS / 8 - 1), 8, =
0=0A         .quad 0x0000910000000000     /* per-CPU entry (limit =3D=3D =
cpu) */=0A         .align PAGE_SIZE,0=0A+=0A+#define PAGE_HYPERVISOR       =
  __PAGE_HYPERVISOR=0A+#define PAGE_HYPERVISOR_NOCACHE __PAGE_HYPERVISOR_NO=
CACHE=0A+=0A+/* Mapping of first 16 megabytes of memory. */=0A+        =
.globl idle_pg_table_l2=0A+idle_pg_table_l2:=0A+        range =3D 8=0A+    =
    .irp count, l2_linear_offset(__PAGE_OFFSET), \=0A+                    =
(4 * L2_PAGETABLE_ENTRIES - l2_linear_offset(__PAGE_OFFSET) - 1)=0A+       =
 .long sym_phys(l1_identmap) + PAGE_HYPERVISOR, 0=0A+        pfn =3D 1 << =
PAGETABLE_ORDER=0A+        .rept range - 1=0A+        .long (pfn << =
PAGE_SHIFT) | PAGE_HYPERVISOR | _PAGE_PSE, 0=0A+        pfn =3D pfn + (1 =
<< PAGETABLE_ORDER)=0A+        .endr=0A+        .fill \count - range, 8, =
0=0A+        range =3D DIRECTMAP_MBYTES / 2=0A+        .endr=0A+        =
.long sym_phys(l1_fixmap) + PAGE_HYPERVISOR, 0=0A+        .size idle_pg_tab=
le_l2, . - idle_pg_table_l2=0A--- a/xen/arch/x86/boot/x86_64.S=0A+++ =
b/xen/arch/x86/boot/x86_64.S=0A@@ -127,3 +127,15 @@ ENTRY(boot_cpu_compat_g=
dt_table)=0A         .fill (PER_CPU_GDT_ENTRY - __HYPERVISOR_CS32 / 8 - =
1), 8, 0=0A         .quad 0x0000910000000000     /* per-CPU entry (limit =
=3D=3D cpu)      */=0A         .align PAGE_SIZE, 0=0A+=0A+/* Mapping of =
first 16 megabytes of memory. */=0A+        .globl l2_identmap=0A+l2_identm=
ap:=0A+        .quad 0=0A+        pfn =3D 0=0A+        .rept 7=0A+        =
pfn =3D pfn + (1 << PAGETABLE_ORDER)=0A+        .quad (pfn << PAGE_SHIFT) =
| PAGE_HYPERVISOR | _PAGE_PSE=0A+        .endr=0A+        .fill 4 * =
L2_PAGETABLE_ENTRIES - 8, 8, 0=0A+        .size l2_identmap, . - l2_identma=
p=0A--- a/xen/arch/x86/efi/boot.c=0A+++ b/xen/arch/x86/efi/boot.c=0A@@ =
-1119,8 +1119,6 @@ efi_start(EFI_HANDLE ImageHandle, EFI_SY=0A         =
unsigned int slot =3D (xen_phys_start >> L2_PAGETABLE_SHIFT) + i;=0A       =
  paddr_t addr =3D slot << L2_PAGETABLE_SHIFT;=0A =0A-        l2_identmap[i=
] =3D l2e_from_paddr(i << L2_PAGETABLE_SHIFT,=0A-                          =
              PAGE_HYPERVISOR|_PAGE_PSE);=0A         l2_identmap[slot] =3D =
l2e_from_paddr(addr, PAGE_HYPERVISOR|_PAGE_PSE);=0A         l2_xenmap[i] =
=3D l2e_from_paddr(addr, PAGE_HYPERVISOR|_PAGE_PSE);=0A         slot &=3D =
L2_PAGETABLE_ENTRIES - 1;=0A@@ -1150,16 +1148,7 @@ efi_start(EFI_HANDLE =
ImageHandle, EFI_SY=0A         l4e_from_paddr((UINTN)l3_identmap, =
__PAGE_HYPERVISOR);=0A     idle_pg_table[l4_table_offset(XEN_VIRT_START)] =
=3D=0A         l4e_from_paddr((UINTN)l3_xenmap, __PAGE_HYPERVISOR);=0A-    =
/* Initialize 4kB mappings of first 2MB of memory. */=0A-    for ( i =3D =
0; i < L1_PAGETABLE_ENTRIES; ++i )=0A-    {=0A-        unsigned int attr =
=3D PAGE_HYPERVISOR|MAP_SMALL_PAGES;=0A-=0A-        /* VGA hole (0xa0000-0x=
c0000) should be mapped UC. */=0A-        if ( i >=3D 0xa0 && i < 0xc0 =
)=0A-            attr |=3D _PAGE_PCD;=0A-        l1_identmap[i] =3D =
l1e_from_pfn(i, attr);=0A-    }=0A+    /* Hook 4kB mappings of first 2MB =
of memory into L2. */=0A     l2_identmap[0] =3D l2e_from_paddr((UINTN)l1_id=
entmap, __PAGE_HYPERVISOR);=0A =0A     if ( gop )=0A--- a/xen/arch/x86/mm.c=
=0A+++ b/xen/arch/x86/mm.c=0A@@ -121,15 +121,6 @@=0A #include <asm/setup.h>=
=0A #include <asm/fixmap.h>=0A =0A-/*=0A- * Mapping of first 2 or 4 =
megabytes of memory. This is mapped with 4kB=0A- * mappings to avoid type =
conflicts with fixed-range MTRRs covering the=0A- * lowest megabyte of =
physical memory. In any case the VGA hole should be=0A- * mapped with type =
UC.=0A- */=0A-l1_pgentry_t __attribute__ ((__section__ (".bss.page_aligned"=
)))=0A-    l1_identmap[L1_PAGETABLE_ENTRIES];=0A-=0A /* Mapping of the =
fixmap space needed early. */=0A l1_pgentry_t __attribute__ ((__section__ =
(".bss.page_aligned")))=0A     l1_fixmap[L1_PAGETABLE_ENTRIES];=0A--- =
a/xen/arch/x86/x86_32/mm.c=0A+++ b/xen/arch/x86/x86_32/mm.c=0A@@ -31,9 =
+31,6 @@=0A #include <asm/setup.h>=0A #include <public/memory.h>=0A =
=0A-l2_pgentry_t __attribute__ ((__section__ (".bss.page_aligned")))=0A-   =
 idle_pg_table_l2[4 * L2_PAGETABLE_ENTRIES];=0A-=0A unsigned int __read_mos=
tly PAGE_HYPERVISOR         =3D __PAGE_HYPERVISOR;=0A unsigned int =
__read_mostly PAGE_HYPERVISOR_NOCACHE =3D __PAGE_HYPERVISOR_NOCACHE;=0A =
=0A--- a/xen/arch/x86/x86_64/mm.c=0A+++ b/xen/arch/x86/x86_64/mm.c=0A@@ =
-56,8 +56,6 @@ l4_pgentry_t __attribute__ ((__section__=0A /* Enough page =
directories to map bottom 4GB of the memory map. */=0A l3_pgentry_t =
__attribute__ ((__section__ (".bss.page_aligned")))=0A     l3_identmap[L3_P=
AGETABLE_ENTRIES];=0A-l2_pgentry_t __attribute__ ((__section__ (".bss.page_=
aligned")))=0A-    l2_identmap[4*L2_PAGETABLE_ENTRIES];=0A =0A /* Enough =
page directories to map the Xen text and static data. */=0A l3_pgentry_t =
__attribute__ ((__section__ (".bss.page_aligned")))=0A--- a/xen/include/asm=
-x86/page.h=0A+++ b/xen/include/asm-x86/page.h=0A@@ -1,15 +1,13 @@=0A =
#ifndef __X86_PAGE_H__=0A #define __X86_PAGE_H__=0A =0A+#include <xen/const=
.h>=0A+=0A /*=0A  * It is important that the masks are signed quantities. =
This ensures that=0A  * the compiler sign-extends a 32-bit mask to 64 bits =
if that is required.=0A  */=0A-#ifndef __ASSEMBLY__=0A-#define PAGE_SIZE   =
        (1L << PAGE_SHIFT)=0A-#else=0A-#define PAGE_SIZE           (1 << =
PAGE_SHIFT)=0A-#endif=0A+#define PAGE_SIZE           (_AC(1,L) << =
PAGE_SHIFT)=0A #define PAGE_MASK           (~(PAGE_SIZE-1))=0A #define =
PAGE_FLAG_MASK      (~0)=0A =0A@@ -319,21 +317,22 @@ void paging_init(void)=
;=0A void setup_idle_pagetable(void);=0A #endif /* !defined(__ASSEMBLY__) =
*/=0A =0A-#define _PAGE_PRESENT  0x001U=0A-#define _PAGE_RW       =
0x002U=0A-#define _PAGE_USER     0x004U=0A-#define _PAGE_PWT      =
0x008U=0A-#define _PAGE_PCD      0x010U=0A-#define _PAGE_ACCESSED =
0x020U=0A-#define _PAGE_DIRTY    0x040U=0A-#define _PAGE_PAT      =
0x080U=0A-#define _PAGE_PSE      0x080U=0A-#define _PAGE_GLOBAL   =
0x100U=0A-#define _PAGE_AVAIL0   0x200U=0A-#define _PAGE_AVAIL1   =
0x400U=0A-#define _PAGE_AVAIL2   0x800U=0A-#define _PAGE_AVAIL    =
0xE00U=0A-#define _PAGE_PSE_PAT 0x1000U=0A+#define _PAGE_PRESENT  =
_AC(0x001,U)=0A+#define _PAGE_RW       _AC(0x002,U)=0A+#define _PAGE_USER  =
   _AC(0x004,U)=0A+#define _PAGE_PWT      _AC(0x008,U)=0A+#define =
_PAGE_PCD      _AC(0x010,U)=0A+#define _PAGE_ACCESSED _AC(0x020,U)=0A+#defi=
ne _PAGE_DIRTY    _AC(0x040,U)=0A+#define _PAGE_PAT      _AC(0x080,U)=0A+#d=
efine _PAGE_PSE      _AC(0x080,U)=0A+#define _PAGE_GLOBAL   _AC(0x100,U)=0A=
+#define _PAGE_AVAIL0   _AC(0x200,U)=0A+#define _PAGE_AVAIL1   _AC(0x400,U)=
=0A+#define _PAGE_AVAIL2   _AC(0x800,U)=0A+#define _PAGE_AVAIL    =
_AC(0xE00,U)=0A+#define _PAGE_PSE_PAT _AC(0x1000,U)=0A+/* non-architectural=
 flags */=0A #define _PAGE_PAGED   0x2000U=0A #define _PAGE_SHARED  =
0x4000U=0A =0A@@ -354,6 +353,8 @@ void setup_idle_pagetable(void);=0A =
#define __PAGE_HYPERVISOR_NOCACHE \=0A     (_PAGE_PRESENT | _PAGE_RW | =
_PAGE_DIRTY | _PAGE_PCD | _PAGE_ACCESSED)=0A =0A+#define MAP_SMALL_PAGES =
_PAGE_AVAIL0 /* don't use superpages mappings */=0A+=0A #ifndef __ASSEMBLY_=
_=0A =0A /* Allocator functions for Xen pagetables. */=0A@@ -367,7 +368,6 =
@@ l3_pgentry_t *virt_to_xen_l3e(unsigned l=0A extern void set_pdx_range(un=
signed long smfn, unsigned long emfn);=0A =0A /* Map machine page range in =
Xen virtual address space. */=0A-#define MAP_SMALL_PAGES _PAGE_AVAIL0 /* =
don't use superpages for the mapping */=0A int map_pages_to_xen(=0A     =
unsigned long virt,=0A     unsigned long mfn,=0A
--=__Part0C3D1E59.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

--=__Part0C3D1E59.0__=--


From xen-devel-bounces@lists.xen.org Tue Sep 11 11:37:10 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 2012 11: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 1TBOlx-0006VH-7o; Tue, 11 Sep 2012 11:36: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 1TBOlw-0006V3-Ap
	for xen-devel@lists.xen.org; Tue, 11 Sep 2012 11:36:52 +0000
Received: from [85.158.139.83:51093] by server-9.bemta-5.messagelabs.com id
	1E/5E-20529-3522F405; Tue, 11 Sep 2012 11:36:51 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1347363404!25301352!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQwNzc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6140 invoked from network); 11 Sep 2012 11:36:45 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-4.tower-182.messagelabs.com with SMTP;
	11 Sep 2012 11:36:45 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 11 Sep 2012 12:36:44 +0100
Message-Id: <504F3E69020000780009A8DB@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 11 Sep 2012 12:36: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="=__Part0C3D1E59.0__="
Subject: [Xen-devel] [PATCH 1/2] x86: construct static parts of 1:1 mapping
 at build 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>
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.

--=__Part0C3D1E59.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

... rather than at boot time, removing unnecessary redundancy between
EFI and legacy boot code.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/arch/x86/boot/head.S
+++ b/xen/arch/x86/boot/head.S
@@ -124,14 +124,11 @@ __start:
         bt      $29,%edx
         jnc     bad_cpu
         /* Initialise L2 identity-map and xen page table entries (16MB). =
*/
-        mov     $sym_phys(l2_identmap),%edi
         mov     $sym_phys(l2_xenmap),%esi
         mov     $sym_phys(l2_bootmap),%edx
         mov     $0x1e3,%eax                  /* PRESENT+RW+A+D+2MB+GLOBAL =
*/
         mov     $8,%ecx
-1:      mov     %eax,(%edi)
-        add     $8,%edi
-        mov     %eax,(%esi)
+1:      mov     %eax,(%esi)
         add     $8,%esi
         mov     %eax,(%edx)
         add     $8,%edx
@@ -163,54 +160,11 @@ __start:
         mov     %eax,sym_phys(idle_pg_table) + l4_table_offset(DIRECTMAP_V=
IRT_START)*8
         mov     $(sym_phys(l3_xenmap)+7),%eax
         mov     %eax,sym_phys(idle_pg_table) + l4_table_offset(XEN_VIRT_ST=
ART)*8
-#else
-        /* Initialize low and high mappings of memory with 2MB pages */
-        mov     $sym_phys(idle_pg_table_l2),%edi
-        mov     $0xe3,%eax                   /* PRESENT+RW+A+D+2MB */
-1:      mov     %eax,__PAGE_OFFSET>>18(%edi) /* high mapping */
-        stosl                                /* low mapping */
-        add     $4,%edi
-        add     $(1<<L2_PAGETABLE_SHIFT),%eax
-        cmp     $DIRECTMAP_PHYS_END+0xe3,%eax
-        jne     1b
-1:      stosl   /* low mappings cover up to 16MB */
-        add     $4,%edi
-        add     $(1<<L2_PAGETABLE_SHIFT),%eax
-        cmp     $(16<<20)+0xe3,%eax
-        jne     1b
-        /* Initialise L2 fixmap page directory entry. */
-        mov     $(sym_phys(l1_fixmap)+7),%eax
-        mov     %eax,sym_phys(idle_pg_table_l2) + l2_table_offset(FIXADDR_=
TOP-1)*8
-#endif
-
-        /* Initialize 4kB mappings of first 2MB or 4MB of memory. */
-        mov     $sym_phys(l1_identmap),%edi
-        mov     $0x263,%eax                  /* PRESENT+RW+A+D+SMALL_PAGES=
 */
-#if defined(__x86_64__)
-        or      $0x100,%eax                  /* GLOBAL */
-#endif
-        xor     %ecx,%ecx
-1:      stosl
-        add     $4,%edi
-        add     $PAGE_SIZE,%eax
-        inc     %ecx
-        /* VGA hole (0xa0000-0xc0000) should be mapped UC. */
-        cmp     $0xa0,%ecx
-        jne     2f
-        or      $0x10,%eax                   /* +PCD */
-2:      cmp     $0xc0,%ecx
-        jne     2f
-        and     $~0x10,%eax                  /* -PCD */
-2:      cmp     $L1_PAGETABLE_ENTRIES,%ecx
-        jne     1b
-        sub     $(PAGE_SIZE-0x63),%edi
-#if defined(__x86_64__)
+        /* Hook 4kB mappings of first 2MB of memory into L2. */
+        mov     $sym_phys(l1_identmap)+__PAGE_HYPERVISOR,%edi
         mov     %edi,sym_phys(l2_identmap)
         mov     %edi,sym_phys(l2_xenmap)
         mov     %edi,sym_phys(l2_bootmap)
-#else
-        mov     %edi,sym_phys(idle_pg_table_l2)
-        mov     %edi,sym_phys(idle_pg_table_l2) + (__PAGE_OFFSET>>18)
 #endif
=20
         /* Apply relocations to bootstrap trampoline. */
@@ -269,3 +223,25 @@ __high_start:
 #else
 #include "x86_32.S"
 #endif
+
+        .section .data.page_aligned, "aw", @progbits
+        .p2align PAGE_SHIFT
+/*
+ * Mapping of first 2 megabytes of memory. This is mapped with 4kB =
mappings
+ * to avoid type conflicts with fixed-range MTRRs covering the lowest =
megabyte
+ * of physical memory. In any case the VGA hole should be mapped with =
type UC.
+ */
+        .globl l1_identmap
+l1_identmap:
+        pfn =3D 0
+        .rept L1_PAGETABLE_ENTRIES
+        /* VGA hole (0xa0000-0xc0000) should be mapped UC. */
+        .if pfn >=3D 0xa0 && pfn < 0xc0
+        .long (pfn << PAGE_SHIFT) | PAGE_HYPERVISOR_NOCACHE | MAP_SMALL_PA=
GES
+        .else
+        .long (pfn << PAGE_SHIFT) | PAGE_HYPERVISOR | MAP_SMALL_PAGES
+        .endif
+        .long 0
+        pfn =3D pfn + 1
+        .endr
+        .size l1_identmap, . - l1_identmap
--- a/xen/arch/x86/boot/x86_32.S
+++ b/xen/arch/x86/boot/x86_32.S
@@ -108,3 +108,24 @@ ENTRY(boot_cpu_gdt_table)
         .fill (PER_CPU_GDT_ENTRY - FLAT_RING3_DS / 8 - 1), 8, 0
         .quad 0x0000910000000000     /* per-CPU entry (limit =3D=3D cpu) =
*/
         .align PAGE_SIZE,0
+
+#define PAGE_HYPERVISOR         __PAGE_HYPERVISOR
+#define PAGE_HYPERVISOR_NOCACHE __PAGE_HYPERVISOR_NOCACHE
+
+/* Mapping of first 16 megabytes of memory. */
+        .globl idle_pg_table_l2
+idle_pg_table_l2:
+        range =3D 8
+        .irp count, l2_linear_offset(__PAGE_OFFSET), \
+                    (4 * L2_PAGETABLE_ENTRIES - l2_linear_offset(__PAGE_OF=
FSET) - 1)
+        .long sym_phys(l1_identmap) + PAGE_HYPERVISOR, 0
+        pfn =3D 1 << PAGETABLE_ORDER
+        .rept range - 1
+        .long (pfn << PAGE_SHIFT) | PAGE_HYPERVISOR | _PAGE_PSE, 0
+        pfn =3D pfn + (1 << PAGETABLE_ORDER)
+        .endr
+        .fill \count - range, 8, 0
+        range =3D DIRECTMAP_MBYTES / 2
+        .endr
+        .long sym_phys(l1_fixmap) + PAGE_HYPERVISOR, 0
+        .size idle_pg_table_l2, . - idle_pg_table_l2
--- a/xen/arch/x86/boot/x86_64.S
+++ b/xen/arch/x86/boot/x86_64.S
@@ -127,3 +127,15 @@ ENTRY(boot_cpu_compat_gdt_table)
         .fill (PER_CPU_GDT_ENTRY - __HYPERVISOR_CS32 / 8 - 1), 8, 0
         .quad 0x0000910000000000     /* per-CPU entry (limit =3D=3D cpu)  =
    */
         .align PAGE_SIZE, 0
+
+/* Mapping of first 16 megabytes of memory. */
+        .globl l2_identmap
+l2_identmap:
+        .quad 0
+        pfn =3D 0
+        .rept 7
+        pfn =3D pfn + (1 << PAGETABLE_ORDER)
+        .quad (pfn << PAGE_SHIFT) | PAGE_HYPERVISOR | _PAGE_PSE
+        .endr
+        .fill 4 * L2_PAGETABLE_ENTRIES - 8, 8, 0
+        .size l2_identmap, . - l2_identmap
--- a/xen/arch/x86/efi/boot.c
+++ b/xen/arch/x86/efi/boot.c
@@ -1119,8 +1119,6 @@ efi_start(EFI_HANDLE ImageHandle, EFI_SY
         unsigned int slot =3D (xen_phys_start >> L2_PAGETABLE_SHIFT) + i;
         paddr_t addr =3D slot << L2_PAGETABLE_SHIFT;
=20
-        l2_identmap[i] =3D l2e_from_paddr(i << L2_PAGETABLE_SHIFT,
-                                        PAGE_HYPERVISOR|_PAGE_PSE);
         l2_identmap[slot] =3D l2e_from_paddr(addr, PAGE_HYPERVISOR|_PAGE_P=
SE);
         l2_xenmap[i] =3D l2e_from_paddr(addr, PAGE_HYPERVISOR|_PAGE_PSE);
         slot &=3D L2_PAGETABLE_ENTRIES - 1;
@@ -1150,16 +1148,7 @@ efi_start(EFI_HANDLE ImageHandle, EFI_SY
         l4e_from_paddr((UINTN)l3_identmap, __PAGE_HYPERVISOR);
     idle_pg_table[l4_table_offset(XEN_VIRT_START)] =3D
         l4e_from_paddr((UINTN)l3_xenmap, __PAGE_HYPERVISOR);
-    /* Initialize 4kB mappings of first 2MB of memory. */
-    for ( i =3D 0; i < L1_PAGETABLE_ENTRIES; ++i )
-    {
-        unsigned int attr =3D PAGE_HYPERVISOR|MAP_SMALL_PAGES;
-
-        /* VGA hole (0xa0000-0xc0000) should be mapped UC. */
-        if ( i >=3D 0xa0 && i < 0xc0 )
-            attr |=3D _PAGE_PCD;
-        l1_identmap[i] =3D l1e_from_pfn(i, attr);
-    }
+    /* Hook 4kB mappings of first 2MB of memory into L2. */
     l2_identmap[0] =3D l2e_from_paddr((UINTN)l1_identmap, __PAGE_HYPERVISO=
R);
=20
     if ( gop )
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -121,15 +121,6 @@
 #include <asm/setup.h>
 #include <asm/fixmap.h>
=20
-/*
- * Mapping of first 2 or 4 megabytes of memory. This is mapped with 4kB
- * mappings to avoid type conflicts with fixed-range MTRRs covering the
- * lowest megabyte of physical memory. In any case the VGA hole should be
- * mapped with type UC.
- */
-l1_pgentry_t __attribute__ ((__section__ (".bss.page_aligned")))
-    l1_identmap[L1_PAGETABLE_ENTRIES];
-
 /* Mapping of the fixmap space needed early. */
 l1_pgentry_t __attribute__ ((__section__ (".bss.page_aligned")))
     l1_fixmap[L1_PAGETABLE_ENTRIES];
--- a/xen/arch/x86/x86_32/mm.c
+++ b/xen/arch/x86/x86_32/mm.c
@@ -31,9 +31,6 @@
 #include <asm/setup.h>
 #include <public/memory.h>
=20
-l2_pgentry_t __attribute__ ((__section__ (".bss.page_aligned")))
-    idle_pg_table_l2[4 * L2_PAGETABLE_ENTRIES];
-
 unsigned int __read_mostly PAGE_HYPERVISOR         =3D __PAGE_HYPERVISOR;
 unsigned int __read_mostly PAGE_HYPERVISOR_NOCACHE =3D __PAGE_HYPERVISOR_N=
OCACHE;
=20
--- a/xen/arch/x86/x86_64/mm.c
+++ b/xen/arch/x86/x86_64/mm.c
@@ -56,8 +56,6 @@ l4_pgentry_t __attribute__ ((__section__
 /* Enough page directories to map bottom 4GB of the memory map. */
 l3_pgentry_t __attribute__ ((__section__ (".bss.page_aligned")))
     l3_identmap[L3_PAGETABLE_ENTRIES];
-l2_pgentry_t __attribute__ ((__section__ (".bss.page_aligned")))
-    l2_identmap[4*L2_PAGETABLE_ENTRIES];
=20
 /* Enough page directories to map the Xen text and static data. */
 l3_pgentry_t __attribute__ ((__section__ (".bss.page_aligned")))
--- a/xen/include/asm-x86/page.h
+++ b/xen/include/asm-x86/page.h
@@ -1,15 +1,13 @@
 #ifndef __X86_PAGE_H__
 #define __X86_PAGE_H__
=20
+#include <xen/const.h>
+
 /*
  * It is important that the masks are signed quantities. This ensures =
that
  * the compiler sign-extends a 32-bit mask to 64 bits if that is =
required.
  */
-#ifndef __ASSEMBLY__
-#define PAGE_SIZE           (1L << PAGE_SHIFT)
-#else
-#define PAGE_SIZE           (1 << PAGE_SHIFT)
-#endif
+#define PAGE_SIZE           (_AC(1,L) << PAGE_SHIFT)
 #define PAGE_MASK           (~(PAGE_SIZE-1))
 #define PAGE_FLAG_MASK      (~0)
=20
@@ -319,21 +317,22 @@ void paging_init(void);
 void setup_idle_pagetable(void);
 #endif /* !defined(__ASSEMBLY__) */
=20
-#define _PAGE_PRESENT  0x001U
-#define _PAGE_RW       0x002U
-#define _PAGE_USER     0x004U
-#define _PAGE_PWT      0x008U
-#define _PAGE_PCD      0x010U
-#define _PAGE_ACCESSED 0x020U
-#define _PAGE_DIRTY    0x040U
-#define _PAGE_PAT      0x080U
-#define _PAGE_PSE      0x080U
-#define _PAGE_GLOBAL   0x100U
-#define _PAGE_AVAIL0   0x200U
-#define _PAGE_AVAIL1   0x400U
-#define _PAGE_AVAIL2   0x800U
-#define _PAGE_AVAIL    0xE00U
-#define _PAGE_PSE_PAT 0x1000U
+#define _PAGE_PRESENT  _AC(0x001,U)
+#define _PAGE_RW       _AC(0x002,U)
+#define _PAGE_USER     _AC(0x004,U)
+#define _PAGE_PWT      _AC(0x008,U)
+#define _PAGE_PCD      _AC(0x010,U)
+#define _PAGE_ACCESSED _AC(0x020,U)
+#define _PAGE_DIRTY    _AC(0x040,U)
+#define _PAGE_PAT      _AC(0x080,U)
+#define _PAGE_PSE      _AC(0x080,U)
+#define _PAGE_GLOBAL   _AC(0x100,U)
+#define _PAGE_AVAIL0   _AC(0x200,U)
+#define _PAGE_AVAIL1   _AC(0x400,U)
+#define _PAGE_AVAIL2   _AC(0x800,U)
+#define _PAGE_AVAIL    _AC(0xE00,U)
+#define _PAGE_PSE_PAT _AC(0x1000,U)
+/* non-architectural flags */
 #define _PAGE_PAGED   0x2000U
 #define _PAGE_SHARED  0x4000U
=20
@@ -354,6 +353,8 @@ void setup_idle_pagetable(void);
 #define __PAGE_HYPERVISOR_NOCACHE \
     (_PAGE_PRESENT | _PAGE_RW | _PAGE_DIRTY | _PAGE_PCD | _PAGE_ACCESSED)
=20
+#define MAP_SMALL_PAGES _PAGE_AVAIL0 /* don't use superpages mappings */
+
 #ifndef __ASSEMBLY__
=20
 /* Allocator functions for Xen pagetables. */
@@ -367,7 +368,6 @@ l3_pgentry_t *virt_to_xen_l3e(unsigned l
 extern void set_pdx_range(unsigned long smfn, unsigned long emfn);
=20
 /* Map machine page range in Xen virtual address space. */
-#define MAP_SMALL_PAGES _PAGE_AVAIL0 /* don't use superpages for the =
mapping */
 int map_pages_to_xen(
     unsigned long virt,
     unsigned long mfn,



--=__Part0C3D1E59.0__=
Content-Type: text/plain; name="x86-build-ident-map.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="x86-build-ident-map.patch"

x86: construct static parts of 1:1 mapping at build time=0A=0A... rather =
than at boot time, removing unnecessary redundancy between=0AEFI and =
legacy boot code.=0A=0ASigned-off-by: Jan Beulich <jbeulich@suse.com>=0A=0A=
--- a/xen/arch/x86/boot/head.S=0A+++ b/xen/arch/x86/boot/head.S=0A@@ =
-124,14 +124,11 @@ __start:=0A         bt      $29,%edx=0A         jnc     =
bad_cpu=0A         /* Initialise L2 identity-map and xen page table =
entries (16MB). */=0A-        mov     $sym_phys(l2_identmap),%edi=0A       =
  mov     $sym_phys(l2_xenmap),%esi=0A         mov     $sym_phys(l2_bootmap=
),%edx=0A         mov     $0x1e3,%eax                  /* PRESENT+RW+A+D+2M=
B+GLOBAL */=0A         mov     $8,%ecx=0A-1:      mov     %eax,(%edi)=0A-  =
      add     $8,%edi=0A-        mov     %eax,(%esi)=0A+1:      mov     =
%eax,(%esi)=0A         add     $8,%esi=0A         mov     %eax,(%edx)=0A   =
      add     $8,%edx=0A@@ -163,54 +160,11 @@ __start:=0A         mov     =
%eax,sym_phys(idle_pg_table) + l4_table_offset(DIRECTMAP_VIRT_START)*8=0A  =
       mov     $(sym_phys(l3_xenmap)+7),%eax=0A         mov     %eax,sym_ph=
ys(idle_pg_table) + l4_table_offset(XEN_VIRT_START)*8=0A-#else=0A-        =
/* Initialize low and high mappings of memory with 2MB pages */=0A-        =
mov     $sym_phys(idle_pg_table_l2),%edi=0A-        mov     $0xe3,%eax     =
              /* PRESENT+RW+A+D+2MB */=0A-1:      mov     %eax,__PAGE_OFFSE=
T>>18(%edi) /* high mapping */=0A-        stosl                            =
    /* low mapping */=0A-        add     $4,%edi=0A-        add     =
$(1<<L2_PAGETABLE_SHIFT),%eax=0A-        cmp     $DIRECTMAP_PHYS_END+0xe3,%=
eax=0A-        jne     1b=0A-1:      stosl   /* low mappings cover up to =
16MB */=0A-        add     $4,%edi=0A-        add     $(1<<L2_PAGETABLE_SHI=
FT),%eax=0A-        cmp     $(16<<20)+0xe3,%eax=0A-        jne     1b=0A-  =
      /* Initialise L2 fixmap page directory entry. */=0A-        mov     =
$(sym_phys(l1_fixmap)+7),%eax=0A-        mov     %eax,sym_phys(idle_pg_tabl=
e_l2) + l2_table_offset(FIXADDR_TOP-1)*8=0A-#endif=0A-=0A-        /* =
Initialize 4kB mappings of first 2MB or 4MB of memory. */=0A-        mov   =
  $sym_phys(l1_identmap),%edi=0A-        mov     $0x263,%eax               =
   /* PRESENT+RW+A+D+SMALL_PAGES */=0A-#if defined(__x86_64__)=0A-        =
or      $0x100,%eax                  /* GLOBAL */=0A-#endif=0A-        xor =
    %ecx,%ecx=0A-1:      stosl=0A-        add     $4,%edi=0A-        add   =
  $PAGE_SIZE,%eax=0A-        inc     %ecx=0A-        /* VGA hole (0xa0000-0=
xc0000) should be mapped UC. */=0A-        cmp     $0xa0,%ecx=0A-        =
jne     2f=0A-        or      $0x10,%eax                   /* +PCD =
*/=0A-2:      cmp     $0xc0,%ecx=0A-        jne     2f=0A-        and     =
$~0x10,%eax                  /* -PCD */=0A-2:      cmp     $L1_PAGETABLE_EN=
TRIES,%ecx=0A-        jne     1b=0A-        sub     $(PAGE_SIZE-0x63),%edi=
=0A-#if defined(__x86_64__)=0A+        /* Hook 4kB mappings of first 2MB =
of memory into L2. */=0A+        mov     $sym_phys(l1_identmap)+__PAGE_HYPE=
RVISOR,%edi=0A         mov     %edi,sym_phys(l2_identmap)=0A         mov   =
  %edi,sym_phys(l2_xenmap)=0A         mov     %edi,sym_phys(l2_bootmap)=0A-=
#else=0A-        mov     %edi,sym_phys(idle_pg_table_l2)=0A-        mov    =
 %edi,sym_phys(idle_pg_table_l2) + (__PAGE_OFFSET>>18)=0A #endif=0A =0A    =
     /* Apply relocations to bootstrap trampoline. */=0A@@ -269,3 +223,25 =
@@ __high_start:=0A #else=0A #include "x86_32.S"=0A #endif=0A+=0A+        =
.section .data.page_aligned, "aw", @progbits=0A+        .p2align PAGE_SHIFT=
=0A+/*=0A+ * Mapping of first 2 megabytes of memory. This is mapped with =
4kB mappings=0A+ * to avoid type conflicts with fixed-range MTRRs covering =
the lowest megabyte=0A+ * of physical memory. In any case the VGA hole =
should be mapped with type UC.=0A+ */=0A+        .globl l1_identmap=0A+l1_i=
dentmap:=0A+        pfn =3D 0=0A+        .rept L1_PAGETABLE_ENTRIES=0A+    =
    /* VGA hole (0xa0000-0xc0000) should be mapped UC. */=0A+        .if =
pfn >=3D 0xa0 && pfn < 0xc0=0A+        .long (pfn << PAGE_SHIFT) | =
PAGE_HYPERVISOR_NOCACHE | MAP_SMALL_PAGES=0A+        .else=0A+        =
.long (pfn << PAGE_SHIFT) | PAGE_HYPERVISOR | MAP_SMALL_PAGES=0A+        =
.endif=0A+        .long 0=0A+        pfn =3D pfn + 1=0A+        .endr=0A+  =
      .size l1_identmap, . - l1_identmap=0A--- a/xen/arch/x86/boot/x86_32.S=
=0A+++ b/xen/arch/x86/boot/x86_32.S=0A@@ -108,3 +108,24 @@ ENTRY(boot_cpu_g=
dt_table)=0A         .fill (PER_CPU_GDT_ENTRY - FLAT_RING3_DS / 8 - 1), 8, =
0=0A         .quad 0x0000910000000000     /* per-CPU entry (limit =3D=3D =
cpu) */=0A         .align PAGE_SIZE,0=0A+=0A+#define PAGE_HYPERVISOR       =
  __PAGE_HYPERVISOR=0A+#define PAGE_HYPERVISOR_NOCACHE __PAGE_HYPERVISOR_NO=
CACHE=0A+=0A+/* Mapping of first 16 megabytes of memory. */=0A+        =
.globl idle_pg_table_l2=0A+idle_pg_table_l2:=0A+        range =3D 8=0A+    =
    .irp count, l2_linear_offset(__PAGE_OFFSET), \=0A+                    =
(4 * L2_PAGETABLE_ENTRIES - l2_linear_offset(__PAGE_OFFSET) - 1)=0A+       =
 .long sym_phys(l1_identmap) + PAGE_HYPERVISOR, 0=0A+        pfn =3D 1 << =
PAGETABLE_ORDER=0A+        .rept range - 1=0A+        .long (pfn << =
PAGE_SHIFT) | PAGE_HYPERVISOR | _PAGE_PSE, 0=0A+        pfn =3D pfn + (1 =
<< PAGETABLE_ORDER)=0A+        .endr=0A+        .fill \count - range, 8, =
0=0A+        range =3D DIRECTMAP_MBYTES / 2=0A+        .endr=0A+        =
.long sym_phys(l1_fixmap) + PAGE_HYPERVISOR, 0=0A+        .size idle_pg_tab=
le_l2, . - idle_pg_table_l2=0A--- a/xen/arch/x86/boot/x86_64.S=0A+++ =
b/xen/arch/x86/boot/x86_64.S=0A@@ -127,3 +127,15 @@ ENTRY(boot_cpu_compat_g=
dt_table)=0A         .fill (PER_CPU_GDT_ENTRY - __HYPERVISOR_CS32 / 8 - =
1), 8, 0=0A         .quad 0x0000910000000000     /* per-CPU entry (limit =
=3D=3D cpu)      */=0A         .align PAGE_SIZE, 0=0A+=0A+/* Mapping of =
first 16 megabytes of memory. */=0A+        .globl l2_identmap=0A+l2_identm=
ap:=0A+        .quad 0=0A+        pfn =3D 0=0A+        .rept 7=0A+        =
pfn =3D pfn + (1 << PAGETABLE_ORDER)=0A+        .quad (pfn << PAGE_SHIFT) =
| PAGE_HYPERVISOR | _PAGE_PSE=0A+        .endr=0A+        .fill 4 * =
L2_PAGETABLE_ENTRIES - 8, 8, 0=0A+        .size l2_identmap, . - l2_identma=
p=0A--- a/xen/arch/x86/efi/boot.c=0A+++ b/xen/arch/x86/efi/boot.c=0A@@ =
-1119,8 +1119,6 @@ efi_start(EFI_HANDLE ImageHandle, EFI_SY=0A         =
unsigned int slot =3D (xen_phys_start >> L2_PAGETABLE_SHIFT) + i;=0A       =
  paddr_t addr =3D slot << L2_PAGETABLE_SHIFT;=0A =0A-        l2_identmap[i=
] =3D l2e_from_paddr(i << L2_PAGETABLE_SHIFT,=0A-                          =
              PAGE_HYPERVISOR|_PAGE_PSE);=0A         l2_identmap[slot] =3D =
l2e_from_paddr(addr, PAGE_HYPERVISOR|_PAGE_PSE);=0A         l2_xenmap[i] =
=3D l2e_from_paddr(addr, PAGE_HYPERVISOR|_PAGE_PSE);=0A         slot &=3D =
L2_PAGETABLE_ENTRIES - 1;=0A@@ -1150,16 +1148,7 @@ efi_start(EFI_HANDLE =
ImageHandle, EFI_SY=0A         l4e_from_paddr((UINTN)l3_identmap, =
__PAGE_HYPERVISOR);=0A     idle_pg_table[l4_table_offset(XEN_VIRT_START)] =
=3D=0A         l4e_from_paddr((UINTN)l3_xenmap, __PAGE_HYPERVISOR);=0A-    =
/* Initialize 4kB mappings of first 2MB of memory. */=0A-    for ( i =3D =
0; i < L1_PAGETABLE_ENTRIES; ++i )=0A-    {=0A-        unsigned int attr =
=3D PAGE_HYPERVISOR|MAP_SMALL_PAGES;=0A-=0A-        /* VGA hole (0xa0000-0x=
c0000) should be mapped UC. */=0A-        if ( i >=3D 0xa0 && i < 0xc0 =
)=0A-            attr |=3D _PAGE_PCD;=0A-        l1_identmap[i] =3D =
l1e_from_pfn(i, attr);=0A-    }=0A+    /* Hook 4kB mappings of first 2MB =
of memory into L2. */=0A     l2_identmap[0] =3D l2e_from_paddr((UINTN)l1_id=
entmap, __PAGE_HYPERVISOR);=0A =0A     if ( gop )=0A--- a/xen/arch/x86/mm.c=
=0A+++ b/xen/arch/x86/mm.c=0A@@ -121,15 +121,6 @@=0A #include <asm/setup.h>=
=0A #include <asm/fixmap.h>=0A =0A-/*=0A- * Mapping of first 2 or 4 =
megabytes of memory. This is mapped with 4kB=0A- * mappings to avoid type =
conflicts with fixed-range MTRRs covering the=0A- * lowest megabyte of =
physical memory. In any case the VGA hole should be=0A- * mapped with type =
UC.=0A- */=0A-l1_pgentry_t __attribute__ ((__section__ (".bss.page_aligned"=
)))=0A-    l1_identmap[L1_PAGETABLE_ENTRIES];=0A-=0A /* Mapping of the =
fixmap space needed early. */=0A l1_pgentry_t __attribute__ ((__section__ =
(".bss.page_aligned")))=0A     l1_fixmap[L1_PAGETABLE_ENTRIES];=0A--- =
a/xen/arch/x86/x86_32/mm.c=0A+++ b/xen/arch/x86/x86_32/mm.c=0A@@ -31,9 =
+31,6 @@=0A #include <asm/setup.h>=0A #include <public/memory.h>=0A =
=0A-l2_pgentry_t __attribute__ ((__section__ (".bss.page_aligned")))=0A-   =
 idle_pg_table_l2[4 * L2_PAGETABLE_ENTRIES];=0A-=0A unsigned int __read_mos=
tly PAGE_HYPERVISOR         =3D __PAGE_HYPERVISOR;=0A unsigned int =
__read_mostly PAGE_HYPERVISOR_NOCACHE =3D __PAGE_HYPERVISOR_NOCACHE;=0A =
=0A--- a/xen/arch/x86/x86_64/mm.c=0A+++ b/xen/arch/x86/x86_64/mm.c=0A@@ =
-56,8 +56,6 @@ l4_pgentry_t __attribute__ ((__section__=0A /* Enough page =
directories to map bottom 4GB of the memory map. */=0A l3_pgentry_t =
__attribute__ ((__section__ (".bss.page_aligned")))=0A     l3_identmap[L3_P=
AGETABLE_ENTRIES];=0A-l2_pgentry_t __attribute__ ((__section__ (".bss.page_=
aligned")))=0A-    l2_identmap[4*L2_PAGETABLE_ENTRIES];=0A =0A /* Enough =
page directories to map the Xen text and static data. */=0A l3_pgentry_t =
__attribute__ ((__section__ (".bss.page_aligned")))=0A--- a/xen/include/asm=
-x86/page.h=0A+++ b/xen/include/asm-x86/page.h=0A@@ -1,15 +1,13 @@=0A =
#ifndef __X86_PAGE_H__=0A #define __X86_PAGE_H__=0A =0A+#include <xen/const=
.h>=0A+=0A /*=0A  * It is important that the masks are signed quantities. =
This ensures that=0A  * the compiler sign-extends a 32-bit mask to 64 bits =
if that is required.=0A  */=0A-#ifndef __ASSEMBLY__=0A-#define PAGE_SIZE   =
        (1L << PAGE_SHIFT)=0A-#else=0A-#define PAGE_SIZE           (1 << =
PAGE_SHIFT)=0A-#endif=0A+#define PAGE_SIZE           (_AC(1,L) << =
PAGE_SHIFT)=0A #define PAGE_MASK           (~(PAGE_SIZE-1))=0A #define =
PAGE_FLAG_MASK      (~0)=0A =0A@@ -319,21 +317,22 @@ void paging_init(void)=
;=0A void setup_idle_pagetable(void);=0A #endif /* !defined(__ASSEMBLY__) =
*/=0A =0A-#define _PAGE_PRESENT  0x001U=0A-#define _PAGE_RW       =
0x002U=0A-#define _PAGE_USER     0x004U=0A-#define _PAGE_PWT      =
0x008U=0A-#define _PAGE_PCD      0x010U=0A-#define _PAGE_ACCESSED =
0x020U=0A-#define _PAGE_DIRTY    0x040U=0A-#define _PAGE_PAT      =
0x080U=0A-#define _PAGE_PSE      0x080U=0A-#define _PAGE_GLOBAL   =
0x100U=0A-#define _PAGE_AVAIL0   0x200U=0A-#define _PAGE_AVAIL1   =
0x400U=0A-#define _PAGE_AVAIL2   0x800U=0A-#define _PAGE_AVAIL    =
0xE00U=0A-#define _PAGE_PSE_PAT 0x1000U=0A+#define _PAGE_PRESENT  =
_AC(0x001,U)=0A+#define _PAGE_RW       _AC(0x002,U)=0A+#define _PAGE_USER  =
   _AC(0x004,U)=0A+#define _PAGE_PWT      _AC(0x008,U)=0A+#define =
_PAGE_PCD      _AC(0x010,U)=0A+#define _PAGE_ACCESSED _AC(0x020,U)=0A+#defi=
ne _PAGE_DIRTY    _AC(0x040,U)=0A+#define _PAGE_PAT      _AC(0x080,U)=0A+#d=
efine _PAGE_PSE      _AC(0x080,U)=0A+#define _PAGE_GLOBAL   _AC(0x100,U)=0A=
+#define _PAGE_AVAIL0   _AC(0x200,U)=0A+#define _PAGE_AVAIL1   _AC(0x400,U)=
=0A+#define _PAGE_AVAIL2   _AC(0x800,U)=0A+#define _PAGE_AVAIL    =
_AC(0xE00,U)=0A+#define _PAGE_PSE_PAT _AC(0x1000,U)=0A+/* non-architectural=
 flags */=0A #define _PAGE_PAGED   0x2000U=0A #define _PAGE_SHARED  =
0x4000U=0A =0A@@ -354,6 +353,8 @@ void setup_idle_pagetable(void);=0A =
#define __PAGE_HYPERVISOR_NOCACHE \=0A     (_PAGE_PRESENT | _PAGE_RW | =
_PAGE_DIRTY | _PAGE_PCD | _PAGE_ACCESSED)=0A =0A+#define MAP_SMALL_PAGES =
_PAGE_AVAIL0 /* don't use superpages mappings */=0A+=0A #ifndef __ASSEMBLY_=
_=0A =0A /* Allocator functions for Xen pagetables. */=0A@@ -367,7 +368,6 =
@@ l3_pgentry_t *virt_to_xen_l3e(unsigned l=0A extern void set_pdx_range(un=
signed long smfn, unsigned long emfn);=0A =0A /* Map machine page range in =
Xen virtual address space. */=0A-#define MAP_SMALL_PAGES _PAGE_AVAIL0 /* =
don't use superpages for the mapping */=0A int map_pages_to_xen(=0A     =
unsigned long virt,=0A     unsigned long mfn,=0A
--=__Part0C3D1E59.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

--=__Part0C3D1E59.0__=--


From xen-devel-bounces@lists.xen.org Tue Sep 11 11:37:32 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 2012 11:37:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TBOmJ-0006YZ-Le; Tue, 11 Sep 2012 11:37: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 1TBOmI-0006YC-Ar
	for xen-devel@lists.xen.org; Tue, 11 Sep 2012 11:37:14 +0000
Received: from [85.158.139.83:46675] by server-3.bemta-5.messagelabs.com id
	8F/C2-21836-9622F405; Tue, 11 Sep 2012 11:37:13 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1347363432!25938335!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQwNzc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26213 invoked from network); 11 Sep 2012 11:37: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 SMTP;
	11 Sep 2012 11:37:12 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 11 Sep 2012 12:37:11 +0100
Message-Id: <504F3E85020000780009A8DF@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 11 Sep 2012 12:37:09 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part20113275.0__="
Subject: [Xen-devel] [PATCH 2/2] x86-64: construct static,
 uniform parts of page tables at build 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>
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.

--=__Part20113275.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

... rather than at boot time, removing unnecessary redundancy between
EFI and legacy boot code.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/arch/x86/boot/head.S
+++ b/xen/arch/x86/boot/head.S
@@ -123,46 +123,19 @@ __start:
         /* Check for availability of long mode. */
         bt      $29,%edx
         jnc     bad_cpu
-        /* Initialise L2 identity-map and xen page table entries (16MB). =
*/
-        mov     $sym_phys(l2_xenmap),%esi
+        /* Initialise L2 boot-map page table entries (16MB). */
         mov     $sym_phys(l2_bootmap),%edx
-        mov     $0x1e3,%eax                  /* PRESENT+RW+A+D+2MB+GLOBAL =
*/
+        mov     $PAGE_HYPERVISOR|_PAGE_PSE,%eax
         mov     $8,%ecx
-1:      mov     %eax,(%esi)
-        add     $8,%esi
-        mov     %eax,(%edx)
+1:      mov     %eax,(%edx)
         add     $8,%edx
         add     $(1<<L2_PAGETABLE_SHIFT),%eax
         loop    1b
-        /* Initialise L2 fixmap page directory entry. */
-        mov     $(sym_phys(l1_fixmap)+7),%eax
-        mov     %eax,sym_phys(l2_fixmap) + l2_table_offset(FIXADDR_TOP-1)*=
8
-        /* Initialise L3 identity-map page directory entries. */
-        mov     $sym_phys(l3_identmap),%edi
-        mov     $(sym_phys(l2_identmap)+7),%eax
-        mov     $4,%ecx
-1:      mov     %eax,(%edi)
-        add     $8,%edi
-        add     $PAGE_SIZE,%eax
-        loop    1b
-        /* Initialise L3 xen-map and fixmap page directory entries. */
-        mov     $(sym_phys(l2_xenmap)+7),%eax
-        mov     %eax,sym_phys(l3_xenmap) + l3_table_offset(XEN_VIRT_START)=
*8
-        mov     $(sym_phys(l2_fixmap)+7),%eax
-        mov     %eax,sym_phys(l3_xenmap) + l3_table_offset(FIXADDR_TOP-1)*=
8
         /* Initialise L3 boot-map page directory entry. */
-        mov     $(sym_phys(l2_bootmap)+7),%eax
+        mov     $sym_phys(l2_bootmap)+__PAGE_HYPERVISOR,%eax
         mov     %eax,sym_phys(l3_bootmap) + 0*8
-        /* Hook identity-map, xen-map, and boot-map L3 tables into PML4. =
*/
-        mov     $(sym_phys(l3_bootmap)+7),%eax
-        mov     %eax,sym_phys(idle_pg_table) + 0*8
-        mov     $(sym_phys(l3_identmap)+7),%eax
-        mov     %eax,sym_phys(idle_pg_table) + l4_table_offset(DIRECTMAP_V=
IRT_START)*8
-        mov     $(sym_phys(l3_xenmap)+7),%eax
-        mov     %eax,sym_phys(idle_pg_table) + l4_table_offset(XEN_VIRT_ST=
ART)*8
         /* Hook 4kB mappings of first 2MB of memory into L2. */
         mov     $sym_phys(l1_identmap)+__PAGE_HYPERVISOR,%edi
-        mov     %edi,sym_phys(l2_identmap)
         mov     %edi,sym_phys(l2_xenmap)
         mov     %edi,sym_phys(l2_bootmap)
 #endif
--- a/xen/arch/x86/boot/x86_64.S
+++ b/xen/arch/x86/boot/x86_64.S
@@ -128,10 +128,13 @@ ENTRY(boot_cpu_compat_gdt_table)
         .quad 0x0000910000000000     /* per-CPU entry (limit =3D=3D cpu)  =
    */
         .align PAGE_SIZE, 0
=20
+	.globl __page_tables_start, __page_tables_end
+__page_tables_start:
+
 /* Mapping of first 16 megabytes of memory. */
         .globl l2_identmap
 l2_identmap:
-        .quad 0
+        .quad sym_phys(l1_identmap) + __PAGE_HYPERVISOR
         pfn =3D 0
         .rept 7
         pfn =3D pfn + (1 << PAGETABLE_ORDER)
@@ -139,3 +142,68 @@ l2_identmap:
         .endr
         .fill 4 * L2_PAGETABLE_ENTRIES - 8, 8, 0
         .size l2_identmap, . - l2_identmap
+
+        .globl l2_xenmap
+l2_xenmap:
+        idx =3D 0
+        .rept 8
+        .quad sym_phys(__image_base__) + (idx << L2_PAGETABLE_SHIFT) + =
(PAGE_HYPERVISOR | _PAGE_PSE)
+        idx =3D idx + 1
+        .endr
+        .fill L2_PAGETABLE_ENTRIES - 8, 8, 0
+        .size l2_xenmap, . - l2_xenmap
+
+l2_fixmap:
+        idx =3D 0
+        .rept L2_PAGETABLE_ENTRIES
+        .if idx =3D=3D l2_table_offset(FIXADDR_TOP - 1)
+        .quad sym_phys(l1_fixmap) + __PAGE_HYPERVISOR
+        .else
+        .quad 0
+        .endif
+        idx =3D idx + 1
+        .endr
+        .size l2_fixmap, . - l2_fixmap
+
+        .globl l3_identmap
+l3_identmap:
+        idx =3D 0
+        .rept 4
+        .quad sym_phys(l2_identmap) + (idx << PAGE_SHIFT) + __PAGE_HYPERVI=
SOR
+        idx =3D idx + 1
+        .endr
+        .fill L3_PAGETABLE_ENTRIES - 4, 8, 0
+        .size l3_identmap, . - l3_identmap
+
+l3_xenmap:
+        idx =3D 0
+        .rept L3_PAGETABLE_ENTRIES
+        .if idx =3D=3D l3_table_offset(XEN_VIRT_START)
+        .quad sym_phys(l2_xenmap) + __PAGE_HYPERVISOR
+        .elseif idx =3D=3D l3_table_offset(FIXADDR_TOP - 1)
+        .quad sym_phys(l2_fixmap) + __PAGE_HYPERVISOR
+        .else
+        .quad 0
+        .endif
+        idx =3D idx + 1
+        .endr
+        .size l3_xenmap, . - l3_xenmap
+
+/* Top-level master (and idle-domain) page directory. */
+        .globl idle_pg_table
+idle_pg_table:
+        .quad sym_phys(l3_bootmap) + __PAGE_HYPERVISOR
+        idx =3D 1
+        .rept L4_PAGETABLE_ENTRIES - 1
+        .if idx =3D=3D l4_table_offset(DIRECTMAP_VIRT_START)
+        .quad sym_phys(l3_identmap) + __PAGE_HYPERVISOR
+        .elseif idx =3D=3D l4_table_offset(XEN_VIRT_START)
+        .quad sym_phys(l3_xenmap) + __PAGE_HYPERVISOR
+        .else
+        .quad 0
+        .endif
+        idx =3D idx + 1
+        .endr
+        .size idle_pg_table, . - idle_pg_table
+
+__page_tables_end:
--- a/xen/arch/x86/efi/boot.c
+++ b/xen/arch/x86/efi/boot.c
@@ -573,6 +573,10 @@ static int __init set_color(u32 mask, in
    return max(*pos + *sz, bpp);
 }
=20
+extern const intpte_t __page_tables_start[], __page_tables_end[];
+#define in_page_tables(v) ((intpte_t *)(v) >=3D __page_tables_start && \
+                           (intpte_t *)(v) < __page_tables_end)
+
 #define PE_BASE_RELOC_ABS      0
 #define PE_BASE_RELOC_HIGHLOW  3
 #define PE_BASE_RELOC_DIR64   10
@@ -604,11 +608,19 @@ static void __init relocate_image(unsign
                 break;
             case PE_BASE_RELOC_HIGHLOW:
                 if ( delta )
+                {
                     *(u32 *)addr +=3D delta;
+                    if ( in_page_tables(addr) )
+                        *(u32 *)addr +=3D xen_phys_start;
+                }
                 break;
             case PE_BASE_RELOC_DIR64:
                 if ( delta )
+                {
                     *(u64 *)addr +=3D delta;
+                    if ( in_page_tables(addr) )
+                        *(intpte_t *)addr +=3D xen_phys_start;
+                }
                 break;
             default:
                 blexit(L"Unsupported relocation type\r\n");
@@ -1113,43 +1125,21 @@ efi_start(EFI_HANDLE ImageHandle, EFI_SY
         *(u16 *)(*trampoline_ptr + (long)trampoline_ptr) =3D
             trampoline_phys >> 4;
=20
-    /* Initialise L2 identity-map and xen page table entries (16MB). */
+    /* Initialise L2 identity-map and boot-map page table entries (16MB). =
*/
     for ( i =3D 0; i < 8; ++i )
     {
         unsigned int slot =3D (xen_phys_start >> L2_PAGETABLE_SHIFT) + i;
         paddr_t addr =3D slot << L2_PAGETABLE_SHIFT;
=20
         l2_identmap[slot] =3D l2e_from_paddr(addr, PAGE_HYPERVISOR|_PAGE_P=
SE);
-        l2_xenmap[i] =3D l2e_from_paddr(addr, PAGE_HYPERVISOR|_PAGE_PSE);
         slot &=3D L2_PAGETABLE_ENTRIES - 1;
         l2_bootmap[slot] =3D l2e_from_paddr(addr, __PAGE_HYPERVISOR|_PAGE_=
PSE);
     }
-    /* Initialise L2 fixmap page directory entry. */
-    l2_fixmap[l2_table_offset(FIXADDR_TOP - 1)] =3D
-        l2e_from_paddr((UINTN)l1_fixmap, __PAGE_HYPERVISOR);
-    /* Initialise L3 identity-map page directory entries. */
-    for ( i =3D 0; i < ARRAY_SIZE(l2_identmap) / L2_PAGETABLE_ENTRIES; =
++i )
-        l3_identmap[i] =3D l3e_from_paddr((UINTN)(l2_identmap +
-                                                i * L2_PAGETABLE_ENTRIES),=

-                                        __PAGE_HYPERVISOR);
-    /* Initialise L3 xen-map and fixmap page directory entries. */
-    l3_xenmap[l3_table_offset(XEN_VIRT_START)] =3D
-        l3e_from_paddr((UINTN)l2_xenmap, __PAGE_HYPERVISOR);
-    l3_xenmap[l3_table_offset(FIXADDR_TOP - 1)] =3D
-        l3e_from_paddr((UINTN)l2_fixmap, __PAGE_HYPERVISOR);
     /* Initialise L3 boot-map page directory entries. */
     l3_bootmap[l3_table_offset(xen_phys_start)] =3D
         l3e_from_paddr((UINTN)l2_bootmap, __PAGE_HYPERVISOR);
     l3_bootmap[l3_table_offset(xen_phys_start + (8 << L2_PAGETABLE_SHIFT) =
- 1)] =3D
         l3e_from_paddr((UINTN)l2_bootmap, __PAGE_HYPERVISOR);
-    /* Hook identity-map, xen-map, and boot-map L3 tables into PML4. */
-    idle_pg_table[0] =3D l4e_from_paddr((UINTN)l3_bootmap, __PAGE_HYPERVIS=
OR);
-    idle_pg_table[l4_table_offset(DIRECTMAP_VIRT_START)] =3D
-        l4e_from_paddr((UINTN)l3_identmap, __PAGE_HYPERVISOR);
-    idle_pg_table[l4_table_offset(XEN_VIRT_START)] =3D
-        l4e_from_paddr((UINTN)l3_xenmap, __PAGE_HYPERVISOR);
-    /* Hook 4kB mappings of first 2MB of memory into L2. */
-    l2_identmap[0] =3D l2e_from_paddr((UINTN)l1_identmap, __PAGE_HYPERVISO=
R);
=20
     if ( gop )
     {
--- a/xen/arch/x86/x86_64/mm.c
+++ b/xen/arch/x86/x86_64/mm.c
@@ -49,24 +49,6 @@ unsigned int __read_mostly pfn_pdx_hole_
=20
 unsigned int __read_mostly m2p_compat_vstart =3D __HYPERVISOR_COMPAT_VIRT_=
START;
=20
-/* Top-level master (and idle-domain) page directory. */
-l4_pgentry_t __attribute__ ((__section__ (".bss.page_aligned")))
-    idle_pg_table[L4_PAGETABLE_ENTRIES];
-
-/* Enough page directories to map bottom 4GB of the memory map. */
-l3_pgentry_t __attribute__ ((__section__ (".bss.page_aligned")))
-    l3_identmap[L3_PAGETABLE_ENTRIES];
-
-/* Enough page directories to map the Xen text and static data. */
-l3_pgentry_t __attribute__ ((__section__ (".bss.page_aligned")))
-    l3_xenmap[L3_PAGETABLE_ENTRIES];
-l2_pgentry_t __attribute__ ((__section__ (".bss.page_aligned")))
-    l2_xenmap[L2_PAGETABLE_ENTRIES];
-
-/* Enough page directories to map the early fixmap space. */
-l2_pgentry_t __attribute__ ((__section__ (".bss.page_aligned")))
-    l2_fixmap[L2_PAGETABLE_ENTRIES];
-
 /* Enough page directories to map into the bottom 1GB. */
 l3_pgentry_t __attribute__ ((__section__ (".bss.page_aligned")))
     l3_bootmap[L3_PAGETABLE_ENTRIES];
--- a/xen/arch/x86/xen.lds.S
+++ b/xen/arch/x86/xen.lds.S
@@ -42,6 +42,10 @@ PHDRS
 }
 SECTIONS
 {
+#if defined(__x86_64__) && !defined(EFI)
+  . =3D __XEN_VIRT_START;
+  __image_base__ =3D .;
+#endif
   . =3D __XEN_VIRT_START + 0x100000;
   _start =3D .;
   .text : {
--- a/xen/include/asm-x86/page.h
+++ b/xen/include/asm-x86/page.h
@@ -304,11 +304,8 @@ extern l2_pgentry_t   idle_pg_table_l2[
 extern l2_pgentry_t  *compat_idle_pg_table_l2;
 extern unsigned int   m2p_compat_vstart;
 extern l2_pgentry_t l2_xenmap[L2_PAGETABLE_ENTRIES],
-    l2_fixmap[L2_PAGETABLE_ENTRIES],
     l2_bootmap[L2_PAGETABLE_ENTRIES];
-extern l3_pgentry_t l3_xenmap[L3_PAGETABLE_ENTRIES],
-    l3_identmap[L3_PAGETABLE_ENTRIES],
-    l3_bootmap[L3_PAGETABLE_ENTRIES];
+extern l3_pgentry_t l3_bootmap[L3_PAGETABLE_ENTRIES];
 #endif
 extern l2_pgentry_t l2_identmap[4*L2_PAGETABLE_ENTRIES];
 extern l1_pgentry_t l1_identmap[L1_PAGETABLE_ENTRIES],



--=__Part20113275.0__=
Content-Type: text/plain; name="x86_64-build-page-tables.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="x86_64-build-page-tables.patch"

x86-64: construct static, uniform parts of page tables at build time=0A=0A.=
.. rather than at boot time, removing unnecessary redundancy between=0AEFI =
and legacy boot code.=0A=0ASigned-off-by: Jan Beulich <jbeulich@suse.com>=
=0A=0A--- a/xen/arch/x86/boot/head.S=0A+++ b/xen/arch/x86/boot/head.S=0A@@ =
-123,46 +123,19 @@ __start:=0A         /* Check for availability of long =
mode. */=0A         bt      $29,%edx=0A         jnc     bad_cpu=0A-        =
/* Initialise L2 identity-map and xen page table entries (16MB). */=0A-    =
    mov     $sym_phys(l2_xenmap),%esi=0A+        /* Initialise L2 boot-map =
page table entries (16MB). */=0A         mov     $sym_phys(l2_bootmap),%edx=
=0A-        mov     $0x1e3,%eax                  /* PRESENT+RW+A+D+2MB+GLOB=
AL */=0A+        mov     $PAGE_HYPERVISOR|_PAGE_PSE,%eax=0A         mov    =
 $8,%ecx=0A-1:      mov     %eax,(%esi)=0A-        add     $8,%esi=0A-     =
   mov     %eax,(%edx)=0A+1:      mov     %eax,(%edx)=0A         add     =
$8,%edx=0A         add     $(1<<L2_PAGETABLE_SHIFT),%eax=0A         loop   =
 1b=0A-        /* Initialise L2 fixmap page directory entry. */=0A-        =
mov     $(sym_phys(l1_fixmap)+7),%eax=0A-        mov     %eax,sym_phys(l2_f=
ixmap) + l2_table_offset(FIXADDR_TOP-1)*8=0A-        /* Initialise L3 =
identity-map page directory entries. */=0A-        mov     $sym_phys(l3_ide=
ntmap),%edi=0A-        mov     $(sym_phys(l2_identmap)+7),%eax=0A-        =
mov     $4,%ecx=0A-1:      mov     %eax,(%edi)=0A-        add     =
$8,%edi=0A-        add     $PAGE_SIZE,%eax=0A-        loop    1b=0A-       =
 /* Initialise L3 xen-map and fixmap page directory entries. */=0A-        =
mov     $(sym_phys(l2_xenmap)+7),%eax=0A-        mov     %eax,sym_phys(l3_x=
enmap) + l3_table_offset(XEN_VIRT_START)*8=0A-        mov     $(sym_phys(l2=
_fixmap)+7),%eax=0A-        mov     %eax,sym_phys(l3_xenmap) + l3_table_off=
set(FIXADDR_TOP-1)*8=0A         /* Initialise L3 boot-map page directory =
entry. */=0A-        mov     $(sym_phys(l2_bootmap)+7),%eax=0A+        mov =
    $sym_phys(l2_bootmap)+__PAGE_HYPERVISOR,%eax=0A         mov     =
%eax,sym_phys(l3_bootmap) + 0*8=0A-        /* Hook identity-map, xen-map, =
and boot-map L3 tables into PML4. */=0A-        mov     $(sym_phys(l3_bootm=
ap)+7),%eax=0A-        mov     %eax,sym_phys(idle_pg_table) + 0*8=0A-      =
  mov     $(sym_phys(l3_identmap)+7),%eax=0A-        mov     %eax,sym_phys(=
idle_pg_table) + l4_table_offset(DIRECTMAP_VIRT_START)*8=0A-        mov    =
 $(sym_phys(l3_xenmap)+7),%eax=0A-        mov     %eax,sym_phys(idle_pg_tab=
le) + l4_table_offset(XEN_VIRT_START)*8=0A         /* Hook 4kB mappings of =
first 2MB of memory into L2. */=0A         mov     $sym_phys(l1_identmap)+_=
_PAGE_HYPERVISOR,%edi=0A-        mov     %edi,sym_phys(l2_identmap)=0A     =
    mov     %edi,sym_phys(l2_xenmap)=0A         mov     %edi,sym_phys(l2_bo=
otmap)=0A #endif=0A--- a/xen/arch/x86/boot/x86_64.S=0A+++ b/xen/arch/x86/bo=
ot/x86_64.S=0A@@ -128,10 +128,13 @@ ENTRY(boot_cpu_compat_gdt_table)=0A    =
     .quad 0x0000910000000000     /* per-CPU entry (limit =3D=3D cpu)      =
*/=0A         .align PAGE_SIZE, 0=0A =0A+	.globl __page_tables_start,=
 __page_tables_end=0A+__page_tables_start:=0A+=0A /* Mapping of first 16 =
megabytes of memory. */=0A         .globl l2_identmap=0A l2_identmap:=0A-  =
      .quad 0=0A+        .quad sym_phys(l1_identmap) + __PAGE_HYPERVISOR=0A=
         pfn =3D 0=0A         .rept 7=0A         pfn =3D pfn + (1 << =
PAGETABLE_ORDER)=0A@@ -139,3 +142,68 @@ l2_identmap:=0A         .endr=0A   =
      .fill 4 * L2_PAGETABLE_ENTRIES - 8, 8, 0=0A         .size l2_identmap=
, . - l2_identmap=0A+=0A+        .globl l2_xenmap=0A+l2_xenmap:=0A+        =
idx =3D 0=0A+        .rept 8=0A+        .quad sym_phys(__image_base__) + =
(idx << L2_PAGETABLE_SHIFT) + (PAGE_HYPERVISOR | _PAGE_PSE)=0A+        idx =
=3D idx + 1=0A+        .endr=0A+        .fill L2_PAGETABLE_ENTRIES - 8, 8, =
0=0A+        .size l2_xenmap, . - l2_xenmap=0A+=0A+l2_fixmap:=0A+        =
idx =3D 0=0A+        .rept L2_PAGETABLE_ENTRIES=0A+        .if idx =3D=3D =
l2_table_offset(FIXADDR_TOP - 1)=0A+        .quad sym_phys(l1_fixmap) + =
__PAGE_HYPERVISOR=0A+        .else=0A+        .quad 0=0A+        .endif=0A+=
        idx =3D idx + 1=0A+        .endr=0A+        .size l2_fixmap, . - =
l2_fixmap=0A+=0A+        .globl l3_identmap=0A+l3_identmap:=0A+        idx =
=3D 0=0A+        .rept 4=0A+        .quad sym_phys(l2_identmap) + (idx << =
PAGE_SHIFT) + __PAGE_HYPERVISOR=0A+        idx =3D idx + 1=0A+        =
.endr=0A+        .fill L3_PAGETABLE_ENTRIES - 4, 8, 0=0A+        .size =
l3_identmap, . - l3_identmap=0A+=0A+l3_xenmap:=0A+        idx =3D 0=0A+    =
    .rept L3_PAGETABLE_ENTRIES=0A+        .if idx =3D=3D l3_table_offset(XE=
N_VIRT_START)=0A+        .quad sym_phys(l2_xenmap) + __PAGE_HYPERVISOR=0A+ =
       .elseif idx =3D=3D l3_table_offset(FIXADDR_TOP - 1)=0A+        =
.quad sym_phys(l2_fixmap) + __PAGE_HYPERVISOR=0A+        .else=0A+        =
.quad 0=0A+        .endif=0A+        idx =3D idx + 1=0A+        .endr=0A+  =
      .size l3_xenmap, . - l3_xenmap=0A+=0A+/* Top-level master (and =
idle-domain) page directory. */=0A+        .globl idle_pg_table=0A+idle_pg_=
table:=0A+        .quad sym_phys(l3_bootmap) + __PAGE_HYPERVISOR=0A+       =
 idx =3D 1=0A+        .rept L4_PAGETABLE_ENTRIES - 1=0A+        .if idx =
=3D=3D l4_table_offset(DIRECTMAP_VIRT_START)=0A+        .quad sym_phys(l3_i=
dentmap) + __PAGE_HYPERVISOR=0A+        .elseif idx =3D=3D l4_table_offset(=
XEN_VIRT_START)=0A+        .quad sym_phys(l3_xenmap) + __PAGE_HYPERVISOR=0A=
+        .else=0A+        .quad 0=0A+        .endif=0A+        idx =3D idx =
+ 1=0A+        .endr=0A+        .size idle_pg_table, . - idle_pg_table=0A+=
=0A+__page_tables_end:=0A--- a/xen/arch/x86/efi/boot.c=0A+++ b/xen/arch/x86=
/efi/boot.c=0A@@ -573,6 +573,10 @@ static int __init set_color(u32 mask, =
in=0A    return max(*pos + *sz, bpp);=0A }=0A =0A+extern const intpte_t =
__page_tables_start[], __page_tables_end[];=0A+#define in_page_tables(v) =
((intpte_t *)(v) >=3D __page_tables_start && \=0A+                         =
  (intpte_t *)(v) < __page_tables_end)=0A+=0A #define PE_BASE_RELOC_ABS    =
  0=0A #define PE_BASE_RELOC_HIGHLOW  3=0A #define PE_BASE_RELOC_DIR64   =
10=0A@@ -604,11 +608,19 @@ static void __init relocate_image(unsign=0A     =
            break;=0A             case PE_BASE_RELOC_HIGHLOW:=0A           =
      if ( delta )=0A+                {=0A                     *(u32 =
*)addr +=3D delta;=0A+                    if ( in_page_tables(addr) )=0A+  =
                      *(u32 *)addr +=3D xen_phys_start;=0A+                =
}=0A                 break;=0A             case PE_BASE_RELOC_DIR64:=0A    =
             if ( delta )=0A+                {=0A                     =
*(u64 *)addr +=3D delta;=0A+                    if ( in_page_tables(addr) =
)=0A+                        *(intpte_t *)addr +=3D xen_phys_start;=0A+    =
            }=0A                 break;=0A             default:=0A         =
        blexit(L"Unsupported relocation type\r\n");=0A@@ -1113,43 +1125,21 =
@@ efi_start(EFI_HANDLE ImageHandle, EFI_SY=0A         *(u16 *)(*trampoline=
_ptr + (long)trampoline_ptr) =3D=0A             trampoline_phys >> 4;=0A =
=0A-    /* Initialise L2 identity-map and xen page table entries (16MB). =
*/=0A+    /* Initialise L2 identity-map and boot-map page table entries =
(16MB). */=0A     for ( i =3D 0; i < 8; ++i )=0A     {=0A         unsigned =
int slot =3D (xen_phys_start >> L2_PAGETABLE_SHIFT) + i;=0A         =
paddr_t addr =3D slot << L2_PAGETABLE_SHIFT;=0A =0A         l2_identmap[slo=
t] =3D l2e_from_paddr(addr, PAGE_HYPERVISOR|_PAGE_PSE);=0A-        =
l2_xenmap[i] =3D l2e_from_paddr(addr, PAGE_HYPERVISOR|_PAGE_PSE);=0A       =
  slot &=3D L2_PAGETABLE_ENTRIES - 1;=0A         l2_bootmap[slot] =3D =
l2e_from_paddr(addr, __PAGE_HYPERVISOR|_PAGE_PSE);=0A     }=0A-    /* =
Initialise L2 fixmap page directory entry. */=0A-    l2_fixmap[l2_table_off=
set(FIXADDR_TOP - 1)] =3D=0A-        l2e_from_paddr((UINTN)l1_fixmap, =
__PAGE_HYPERVISOR);=0A-    /* Initialise L3 identity-map page directory =
entries. */=0A-    for ( i =3D 0; i < ARRAY_SIZE(l2_identmap) / L2_PAGETABL=
E_ENTRIES; ++i )=0A-        l3_identmap[i] =3D l3e_from_paddr((UINTN)(l2_id=
entmap +=0A-                                                i * L2_PAGETABL=
E_ENTRIES),=0A-                                        __PAGE_HYPERVISOR);=
=0A-    /* Initialise L3 xen-map and fixmap page directory entries. */=0A- =
   l3_xenmap[l3_table_offset(XEN_VIRT_START)] =3D=0A-        l3e_from_paddr=
((UINTN)l2_xenmap, __PAGE_HYPERVISOR);=0A-    l3_xenmap[l3_table_offset(FIX=
ADDR_TOP - 1)] =3D=0A-        l3e_from_paddr((UINTN)l2_fixmap, __PAGE_HYPER=
VISOR);=0A     /* Initialise L3 boot-map page directory entries. */=0A     =
l3_bootmap[l3_table_offset(xen_phys_start)] =3D=0A         l3e_from_paddr((=
UINTN)l2_bootmap, __PAGE_HYPERVISOR);=0A     l3_bootmap[l3_table_offset(xen=
_phys_start + (8 << L2_PAGETABLE_SHIFT) - 1)] =3D=0A         l3e_from_paddr=
((UINTN)l2_bootmap, __PAGE_HYPERVISOR);=0A-    /* Hook identity-map, =
xen-map, and boot-map L3 tables into PML4. */=0A-    idle_pg_table[0] =3D =
l4e_from_paddr((UINTN)l3_bootmap, __PAGE_HYPERVISOR);=0A-    idle_pg_table[=
l4_table_offset(DIRECTMAP_VIRT_START)] =3D=0A-        l4e_from_paddr((UINTN=
)l3_identmap, __PAGE_HYPERVISOR);=0A-    idle_pg_table[l4_table_offset(XEN_=
VIRT_START)] =3D=0A-        l4e_from_paddr((UINTN)l3_xenmap, __PAGE_HYPERVI=
SOR);=0A-    /* Hook 4kB mappings of first 2MB of memory into L2. */=0A-   =
 l2_identmap[0] =3D l2e_from_paddr((UINTN)l1_identmap, __PAGE_HYPERVISOR);=
=0A =0A     if ( gop )=0A     {=0A--- a/xen/arch/x86/x86_64/mm.c=0A+++ =
b/xen/arch/x86/x86_64/mm.c=0A@@ -49,24 +49,6 @@ unsigned int __read_mostly =
pfn_pdx_hole_=0A =0A unsigned int __read_mostly m2p_compat_vstart =3D =
__HYPERVISOR_COMPAT_VIRT_START;=0A =0A-/* Top-level master (and idle-domain=
) page directory. */=0A-l4_pgentry_t __attribute__ ((__section__ (".bss.pag=
e_aligned")))=0A-    idle_pg_table[L4_PAGETABLE_ENTRIES];=0A-=0A-/* Enough =
page directories to map bottom 4GB of the memory map. */=0A-l3_pgentry_t =
__attribute__ ((__section__ (".bss.page_aligned")))=0A-    l3_identmap[L3_P=
AGETABLE_ENTRIES];=0A-=0A-/* Enough page directories to map the Xen text =
and static data. */=0A-l3_pgentry_t __attribute__ ((__section__ (".bss.page=
_aligned")))=0A-    l3_xenmap[L3_PAGETABLE_ENTRIES];=0A-l2_pgentry_t =
__attribute__ ((__section__ (".bss.page_aligned")))=0A-    l2_xenmap[L2_PAG=
ETABLE_ENTRIES];=0A-=0A-/* Enough page directories to map the early fixmap =
space. */=0A-l2_pgentry_t __attribute__ ((__section__ (".bss.page_aligned")=
))=0A-    l2_fixmap[L2_PAGETABLE_ENTRIES];=0A-=0A /* Enough page directorie=
s to map into the bottom 1GB. */=0A l3_pgentry_t __attribute__ ((__section_=
_ (".bss.page_aligned")))=0A     l3_bootmap[L3_PAGETABLE_ENTRIES];=0A--- =
a/xen/arch/x86/xen.lds.S=0A+++ b/xen/arch/x86/xen.lds.S=0A@@ -42,6 +42,10 =
@@ PHDRS=0A }=0A SECTIONS=0A {=0A+#if defined(__x86_64__) && !defined(EFI)=
=0A+  . =3D __XEN_VIRT_START;=0A+  __image_base__ =3D .;=0A+#endif=0A   . =
=3D __XEN_VIRT_START + 0x100000;=0A   _start =3D .;=0A   .text : {=0A--- =
a/xen/include/asm-x86/page.h=0A+++ b/xen/include/asm-x86/page.h=0A@@ =
-304,11 +304,8 @@ extern l2_pgentry_t   idle_pg_table_l2[=0A extern =
l2_pgentry_t  *compat_idle_pg_table_l2;=0A extern unsigned int   m2p_compat=
_vstart;=0A extern l2_pgentry_t l2_xenmap[L2_PAGETABLE_ENTRIES],=0A-    =
l2_fixmap[L2_PAGETABLE_ENTRIES],=0A     l2_bootmap[L2_PAGETABLE_ENTRIES];=
=0A-extern l3_pgentry_t l3_xenmap[L3_PAGETABLE_ENTRIES],=0A-    l3_identmap=
[L3_PAGETABLE_ENTRIES],=0A-    l3_bootmap[L3_PAGETABLE_ENTRIES];=0A+extern =
l3_pgentry_t l3_bootmap[L3_PAGETABLE_ENTRIES];=0A #endif=0A extern =
l2_pgentry_t l2_identmap[4*L2_PAGETABLE_ENTRIES];=0A extern l1_pgentry_t =
l1_identmap[L1_PAGETABLE_ENTRIES],=0A
--=__Part20113275.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

--=__Part20113275.0__=--


From xen-devel-bounces@lists.xen.org Tue Sep 11 11:37:32 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 2012 11:37:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TBOmJ-0006YZ-Le; Tue, 11 Sep 2012 11:37: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 1TBOmI-0006YC-Ar
	for xen-devel@lists.xen.org; Tue, 11 Sep 2012 11:37:14 +0000
Received: from [85.158.139.83:46675] by server-3.bemta-5.messagelabs.com id
	8F/C2-21836-9622F405; Tue, 11 Sep 2012 11:37:13 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1347363432!25938335!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQwNzc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26213 invoked from network); 11 Sep 2012 11:37: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 SMTP;
	11 Sep 2012 11:37:12 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 11 Sep 2012 12:37:11 +0100
Message-Id: <504F3E85020000780009A8DF@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 11 Sep 2012 12:37:09 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part20113275.0__="
Subject: [Xen-devel] [PATCH 2/2] x86-64: construct static,
 uniform parts of page tables at build 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>
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.

--=__Part20113275.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

... rather than at boot time, removing unnecessary redundancy between
EFI and legacy boot code.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/arch/x86/boot/head.S
+++ b/xen/arch/x86/boot/head.S
@@ -123,46 +123,19 @@ __start:
         /* Check for availability of long mode. */
         bt      $29,%edx
         jnc     bad_cpu
-        /* Initialise L2 identity-map and xen page table entries (16MB). =
*/
-        mov     $sym_phys(l2_xenmap),%esi
+        /* Initialise L2 boot-map page table entries (16MB). */
         mov     $sym_phys(l2_bootmap),%edx
-        mov     $0x1e3,%eax                  /* PRESENT+RW+A+D+2MB+GLOBAL =
*/
+        mov     $PAGE_HYPERVISOR|_PAGE_PSE,%eax
         mov     $8,%ecx
-1:      mov     %eax,(%esi)
-        add     $8,%esi
-        mov     %eax,(%edx)
+1:      mov     %eax,(%edx)
         add     $8,%edx
         add     $(1<<L2_PAGETABLE_SHIFT),%eax
         loop    1b
-        /* Initialise L2 fixmap page directory entry. */
-        mov     $(sym_phys(l1_fixmap)+7),%eax
-        mov     %eax,sym_phys(l2_fixmap) + l2_table_offset(FIXADDR_TOP-1)*=
8
-        /* Initialise L3 identity-map page directory entries. */
-        mov     $sym_phys(l3_identmap),%edi
-        mov     $(sym_phys(l2_identmap)+7),%eax
-        mov     $4,%ecx
-1:      mov     %eax,(%edi)
-        add     $8,%edi
-        add     $PAGE_SIZE,%eax
-        loop    1b
-        /* Initialise L3 xen-map and fixmap page directory entries. */
-        mov     $(sym_phys(l2_xenmap)+7),%eax
-        mov     %eax,sym_phys(l3_xenmap) + l3_table_offset(XEN_VIRT_START)=
*8
-        mov     $(sym_phys(l2_fixmap)+7),%eax
-        mov     %eax,sym_phys(l3_xenmap) + l3_table_offset(FIXADDR_TOP-1)*=
8
         /* Initialise L3 boot-map page directory entry. */
-        mov     $(sym_phys(l2_bootmap)+7),%eax
+        mov     $sym_phys(l2_bootmap)+__PAGE_HYPERVISOR,%eax
         mov     %eax,sym_phys(l3_bootmap) + 0*8
-        /* Hook identity-map, xen-map, and boot-map L3 tables into PML4. =
*/
-        mov     $(sym_phys(l3_bootmap)+7),%eax
-        mov     %eax,sym_phys(idle_pg_table) + 0*8
-        mov     $(sym_phys(l3_identmap)+7),%eax
-        mov     %eax,sym_phys(idle_pg_table) + l4_table_offset(DIRECTMAP_V=
IRT_START)*8
-        mov     $(sym_phys(l3_xenmap)+7),%eax
-        mov     %eax,sym_phys(idle_pg_table) + l4_table_offset(XEN_VIRT_ST=
ART)*8
         /* Hook 4kB mappings of first 2MB of memory into L2. */
         mov     $sym_phys(l1_identmap)+__PAGE_HYPERVISOR,%edi
-        mov     %edi,sym_phys(l2_identmap)
         mov     %edi,sym_phys(l2_xenmap)
         mov     %edi,sym_phys(l2_bootmap)
 #endif
--- a/xen/arch/x86/boot/x86_64.S
+++ b/xen/arch/x86/boot/x86_64.S
@@ -128,10 +128,13 @@ ENTRY(boot_cpu_compat_gdt_table)
         .quad 0x0000910000000000     /* per-CPU entry (limit =3D=3D cpu)  =
    */
         .align PAGE_SIZE, 0
=20
+	.globl __page_tables_start, __page_tables_end
+__page_tables_start:
+
 /* Mapping of first 16 megabytes of memory. */
         .globl l2_identmap
 l2_identmap:
-        .quad 0
+        .quad sym_phys(l1_identmap) + __PAGE_HYPERVISOR
         pfn =3D 0
         .rept 7
         pfn =3D pfn + (1 << PAGETABLE_ORDER)
@@ -139,3 +142,68 @@ l2_identmap:
         .endr
         .fill 4 * L2_PAGETABLE_ENTRIES - 8, 8, 0
         .size l2_identmap, . - l2_identmap
+
+        .globl l2_xenmap
+l2_xenmap:
+        idx =3D 0
+        .rept 8
+        .quad sym_phys(__image_base__) + (idx << L2_PAGETABLE_SHIFT) + =
(PAGE_HYPERVISOR | _PAGE_PSE)
+        idx =3D idx + 1
+        .endr
+        .fill L2_PAGETABLE_ENTRIES - 8, 8, 0
+        .size l2_xenmap, . - l2_xenmap
+
+l2_fixmap:
+        idx =3D 0
+        .rept L2_PAGETABLE_ENTRIES
+        .if idx =3D=3D l2_table_offset(FIXADDR_TOP - 1)
+        .quad sym_phys(l1_fixmap) + __PAGE_HYPERVISOR
+        .else
+        .quad 0
+        .endif
+        idx =3D idx + 1
+        .endr
+        .size l2_fixmap, . - l2_fixmap
+
+        .globl l3_identmap
+l3_identmap:
+        idx =3D 0
+        .rept 4
+        .quad sym_phys(l2_identmap) + (idx << PAGE_SHIFT) + __PAGE_HYPERVI=
SOR
+        idx =3D idx + 1
+        .endr
+        .fill L3_PAGETABLE_ENTRIES - 4, 8, 0
+        .size l3_identmap, . - l3_identmap
+
+l3_xenmap:
+        idx =3D 0
+        .rept L3_PAGETABLE_ENTRIES
+        .if idx =3D=3D l3_table_offset(XEN_VIRT_START)
+        .quad sym_phys(l2_xenmap) + __PAGE_HYPERVISOR
+        .elseif idx =3D=3D l3_table_offset(FIXADDR_TOP - 1)
+        .quad sym_phys(l2_fixmap) + __PAGE_HYPERVISOR
+        .else
+        .quad 0
+        .endif
+        idx =3D idx + 1
+        .endr
+        .size l3_xenmap, . - l3_xenmap
+
+/* Top-level master (and idle-domain) page directory. */
+        .globl idle_pg_table
+idle_pg_table:
+        .quad sym_phys(l3_bootmap) + __PAGE_HYPERVISOR
+        idx =3D 1
+        .rept L4_PAGETABLE_ENTRIES - 1
+        .if idx =3D=3D l4_table_offset(DIRECTMAP_VIRT_START)
+        .quad sym_phys(l3_identmap) + __PAGE_HYPERVISOR
+        .elseif idx =3D=3D l4_table_offset(XEN_VIRT_START)
+        .quad sym_phys(l3_xenmap) + __PAGE_HYPERVISOR
+        .else
+        .quad 0
+        .endif
+        idx =3D idx + 1
+        .endr
+        .size idle_pg_table, . - idle_pg_table
+
+__page_tables_end:
--- a/xen/arch/x86/efi/boot.c
+++ b/xen/arch/x86/efi/boot.c
@@ -573,6 +573,10 @@ static int __init set_color(u32 mask, in
    return max(*pos + *sz, bpp);
 }
=20
+extern const intpte_t __page_tables_start[], __page_tables_end[];
+#define in_page_tables(v) ((intpte_t *)(v) >=3D __page_tables_start && \
+                           (intpte_t *)(v) < __page_tables_end)
+
 #define PE_BASE_RELOC_ABS      0
 #define PE_BASE_RELOC_HIGHLOW  3
 #define PE_BASE_RELOC_DIR64   10
@@ -604,11 +608,19 @@ static void __init relocate_image(unsign
                 break;
             case PE_BASE_RELOC_HIGHLOW:
                 if ( delta )
+                {
                     *(u32 *)addr +=3D delta;
+                    if ( in_page_tables(addr) )
+                        *(u32 *)addr +=3D xen_phys_start;
+                }
                 break;
             case PE_BASE_RELOC_DIR64:
                 if ( delta )
+                {
                     *(u64 *)addr +=3D delta;
+                    if ( in_page_tables(addr) )
+                        *(intpte_t *)addr +=3D xen_phys_start;
+                }
                 break;
             default:
                 blexit(L"Unsupported relocation type\r\n");
@@ -1113,43 +1125,21 @@ efi_start(EFI_HANDLE ImageHandle, EFI_SY
         *(u16 *)(*trampoline_ptr + (long)trampoline_ptr) =3D
             trampoline_phys >> 4;
=20
-    /* Initialise L2 identity-map and xen page table entries (16MB). */
+    /* Initialise L2 identity-map and boot-map page table entries (16MB). =
*/
     for ( i =3D 0; i < 8; ++i )
     {
         unsigned int slot =3D (xen_phys_start >> L2_PAGETABLE_SHIFT) + i;
         paddr_t addr =3D slot << L2_PAGETABLE_SHIFT;
=20
         l2_identmap[slot] =3D l2e_from_paddr(addr, PAGE_HYPERVISOR|_PAGE_P=
SE);
-        l2_xenmap[i] =3D l2e_from_paddr(addr, PAGE_HYPERVISOR|_PAGE_PSE);
         slot &=3D L2_PAGETABLE_ENTRIES - 1;
         l2_bootmap[slot] =3D l2e_from_paddr(addr, __PAGE_HYPERVISOR|_PAGE_=
PSE);
     }
-    /* Initialise L2 fixmap page directory entry. */
-    l2_fixmap[l2_table_offset(FIXADDR_TOP - 1)] =3D
-        l2e_from_paddr((UINTN)l1_fixmap, __PAGE_HYPERVISOR);
-    /* Initialise L3 identity-map page directory entries. */
-    for ( i =3D 0; i < ARRAY_SIZE(l2_identmap) / L2_PAGETABLE_ENTRIES; =
++i )
-        l3_identmap[i] =3D l3e_from_paddr((UINTN)(l2_identmap +
-                                                i * L2_PAGETABLE_ENTRIES),=

-                                        __PAGE_HYPERVISOR);
-    /* Initialise L3 xen-map and fixmap page directory entries. */
-    l3_xenmap[l3_table_offset(XEN_VIRT_START)] =3D
-        l3e_from_paddr((UINTN)l2_xenmap, __PAGE_HYPERVISOR);
-    l3_xenmap[l3_table_offset(FIXADDR_TOP - 1)] =3D
-        l3e_from_paddr((UINTN)l2_fixmap, __PAGE_HYPERVISOR);
     /* Initialise L3 boot-map page directory entries. */
     l3_bootmap[l3_table_offset(xen_phys_start)] =3D
         l3e_from_paddr((UINTN)l2_bootmap, __PAGE_HYPERVISOR);
     l3_bootmap[l3_table_offset(xen_phys_start + (8 << L2_PAGETABLE_SHIFT) =
- 1)] =3D
         l3e_from_paddr((UINTN)l2_bootmap, __PAGE_HYPERVISOR);
-    /* Hook identity-map, xen-map, and boot-map L3 tables into PML4. */
-    idle_pg_table[0] =3D l4e_from_paddr((UINTN)l3_bootmap, __PAGE_HYPERVIS=
OR);
-    idle_pg_table[l4_table_offset(DIRECTMAP_VIRT_START)] =3D
-        l4e_from_paddr((UINTN)l3_identmap, __PAGE_HYPERVISOR);
-    idle_pg_table[l4_table_offset(XEN_VIRT_START)] =3D
-        l4e_from_paddr((UINTN)l3_xenmap, __PAGE_HYPERVISOR);
-    /* Hook 4kB mappings of first 2MB of memory into L2. */
-    l2_identmap[0] =3D l2e_from_paddr((UINTN)l1_identmap, __PAGE_HYPERVISO=
R);
=20
     if ( gop )
     {
--- a/xen/arch/x86/x86_64/mm.c
+++ b/xen/arch/x86/x86_64/mm.c
@@ -49,24 +49,6 @@ unsigned int __read_mostly pfn_pdx_hole_
=20
 unsigned int __read_mostly m2p_compat_vstart =3D __HYPERVISOR_COMPAT_VIRT_=
START;
=20
-/* Top-level master (and idle-domain) page directory. */
-l4_pgentry_t __attribute__ ((__section__ (".bss.page_aligned")))
-    idle_pg_table[L4_PAGETABLE_ENTRIES];
-
-/* Enough page directories to map bottom 4GB of the memory map. */
-l3_pgentry_t __attribute__ ((__section__ (".bss.page_aligned")))
-    l3_identmap[L3_PAGETABLE_ENTRIES];
-
-/* Enough page directories to map the Xen text and static data. */
-l3_pgentry_t __attribute__ ((__section__ (".bss.page_aligned")))
-    l3_xenmap[L3_PAGETABLE_ENTRIES];
-l2_pgentry_t __attribute__ ((__section__ (".bss.page_aligned")))
-    l2_xenmap[L2_PAGETABLE_ENTRIES];
-
-/* Enough page directories to map the early fixmap space. */
-l2_pgentry_t __attribute__ ((__section__ (".bss.page_aligned")))
-    l2_fixmap[L2_PAGETABLE_ENTRIES];
-
 /* Enough page directories to map into the bottom 1GB. */
 l3_pgentry_t __attribute__ ((__section__ (".bss.page_aligned")))
     l3_bootmap[L3_PAGETABLE_ENTRIES];
--- a/xen/arch/x86/xen.lds.S
+++ b/xen/arch/x86/xen.lds.S
@@ -42,6 +42,10 @@ PHDRS
 }
 SECTIONS
 {
+#if defined(__x86_64__) && !defined(EFI)
+  . =3D __XEN_VIRT_START;
+  __image_base__ =3D .;
+#endif
   . =3D __XEN_VIRT_START + 0x100000;
   _start =3D .;
   .text : {
--- a/xen/include/asm-x86/page.h
+++ b/xen/include/asm-x86/page.h
@@ -304,11 +304,8 @@ extern l2_pgentry_t   idle_pg_table_l2[
 extern l2_pgentry_t  *compat_idle_pg_table_l2;
 extern unsigned int   m2p_compat_vstart;
 extern l2_pgentry_t l2_xenmap[L2_PAGETABLE_ENTRIES],
-    l2_fixmap[L2_PAGETABLE_ENTRIES],
     l2_bootmap[L2_PAGETABLE_ENTRIES];
-extern l3_pgentry_t l3_xenmap[L3_PAGETABLE_ENTRIES],
-    l3_identmap[L3_PAGETABLE_ENTRIES],
-    l3_bootmap[L3_PAGETABLE_ENTRIES];
+extern l3_pgentry_t l3_bootmap[L3_PAGETABLE_ENTRIES];
 #endif
 extern l2_pgentry_t l2_identmap[4*L2_PAGETABLE_ENTRIES];
 extern l1_pgentry_t l1_identmap[L1_PAGETABLE_ENTRIES],



--=__Part20113275.0__=
Content-Type: text/plain; name="x86_64-build-page-tables.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="x86_64-build-page-tables.patch"

x86-64: construct static, uniform parts of page tables at build time=0A=0A.=
.. rather than at boot time, removing unnecessary redundancy between=0AEFI =
and legacy boot code.=0A=0ASigned-off-by: Jan Beulich <jbeulich@suse.com>=
=0A=0A--- a/xen/arch/x86/boot/head.S=0A+++ b/xen/arch/x86/boot/head.S=0A@@ =
-123,46 +123,19 @@ __start:=0A         /* Check for availability of long =
mode. */=0A         bt      $29,%edx=0A         jnc     bad_cpu=0A-        =
/* Initialise L2 identity-map and xen page table entries (16MB). */=0A-    =
    mov     $sym_phys(l2_xenmap),%esi=0A+        /* Initialise L2 boot-map =
page table entries (16MB). */=0A         mov     $sym_phys(l2_bootmap),%edx=
=0A-        mov     $0x1e3,%eax                  /* PRESENT+RW+A+D+2MB+GLOB=
AL */=0A+        mov     $PAGE_HYPERVISOR|_PAGE_PSE,%eax=0A         mov    =
 $8,%ecx=0A-1:      mov     %eax,(%esi)=0A-        add     $8,%esi=0A-     =
   mov     %eax,(%edx)=0A+1:      mov     %eax,(%edx)=0A         add     =
$8,%edx=0A         add     $(1<<L2_PAGETABLE_SHIFT),%eax=0A         loop   =
 1b=0A-        /* Initialise L2 fixmap page directory entry. */=0A-        =
mov     $(sym_phys(l1_fixmap)+7),%eax=0A-        mov     %eax,sym_phys(l2_f=
ixmap) + l2_table_offset(FIXADDR_TOP-1)*8=0A-        /* Initialise L3 =
identity-map page directory entries. */=0A-        mov     $sym_phys(l3_ide=
ntmap),%edi=0A-        mov     $(sym_phys(l2_identmap)+7),%eax=0A-        =
mov     $4,%ecx=0A-1:      mov     %eax,(%edi)=0A-        add     =
$8,%edi=0A-        add     $PAGE_SIZE,%eax=0A-        loop    1b=0A-       =
 /* Initialise L3 xen-map and fixmap page directory entries. */=0A-        =
mov     $(sym_phys(l2_xenmap)+7),%eax=0A-        mov     %eax,sym_phys(l3_x=
enmap) + l3_table_offset(XEN_VIRT_START)*8=0A-        mov     $(sym_phys(l2=
_fixmap)+7),%eax=0A-        mov     %eax,sym_phys(l3_xenmap) + l3_table_off=
set(FIXADDR_TOP-1)*8=0A         /* Initialise L3 boot-map page directory =
entry. */=0A-        mov     $(sym_phys(l2_bootmap)+7),%eax=0A+        mov =
    $sym_phys(l2_bootmap)+__PAGE_HYPERVISOR,%eax=0A         mov     =
%eax,sym_phys(l3_bootmap) + 0*8=0A-        /* Hook identity-map, xen-map, =
and boot-map L3 tables into PML4. */=0A-        mov     $(sym_phys(l3_bootm=
ap)+7),%eax=0A-        mov     %eax,sym_phys(idle_pg_table) + 0*8=0A-      =
  mov     $(sym_phys(l3_identmap)+7),%eax=0A-        mov     %eax,sym_phys(=
idle_pg_table) + l4_table_offset(DIRECTMAP_VIRT_START)*8=0A-        mov    =
 $(sym_phys(l3_xenmap)+7),%eax=0A-        mov     %eax,sym_phys(idle_pg_tab=
le) + l4_table_offset(XEN_VIRT_START)*8=0A         /* Hook 4kB mappings of =
first 2MB of memory into L2. */=0A         mov     $sym_phys(l1_identmap)+_=
_PAGE_HYPERVISOR,%edi=0A-        mov     %edi,sym_phys(l2_identmap)=0A     =
    mov     %edi,sym_phys(l2_xenmap)=0A         mov     %edi,sym_phys(l2_bo=
otmap)=0A #endif=0A--- a/xen/arch/x86/boot/x86_64.S=0A+++ b/xen/arch/x86/bo=
ot/x86_64.S=0A@@ -128,10 +128,13 @@ ENTRY(boot_cpu_compat_gdt_table)=0A    =
     .quad 0x0000910000000000     /* per-CPU entry (limit =3D=3D cpu)      =
*/=0A         .align PAGE_SIZE, 0=0A =0A+	.globl __page_tables_start,=
 __page_tables_end=0A+__page_tables_start:=0A+=0A /* Mapping of first 16 =
megabytes of memory. */=0A         .globl l2_identmap=0A l2_identmap:=0A-  =
      .quad 0=0A+        .quad sym_phys(l1_identmap) + __PAGE_HYPERVISOR=0A=
         pfn =3D 0=0A         .rept 7=0A         pfn =3D pfn + (1 << =
PAGETABLE_ORDER)=0A@@ -139,3 +142,68 @@ l2_identmap:=0A         .endr=0A   =
      .fill 4 * L2_PAGETABLE_ENTRIES - 8, 8, 0=0A         .size l2_identmap=
, . - l2_identmap=0A+=0A+        .globl l2_xenmap=0A+l2_xenmap:=0A+        =
idx =3D 0=0A+        .rept 8=0A+        .quad sym_phys(__image_base__) + =
(idx << L2_PAGETABLE_SHIFT) + (PAGE_HYPERVISOR | _PAGE_PSE)=0A+        idx =
=3D idx + 1=0A+        .endr=0A+        .fill L2_PAGETABLE_ENTRIES - 8, 8, =
0=0A+        .size l2_xenmap, . - l2_xenmap=0A+=0A+l2_fixmap:=0A+        =
idx =3D 0=0A+        .rept L2_PAGETABLE_ENTRIES=0A+        .if idx =3D=3D =
l2_table_offset(FIXADDR_TOP - 1)=0A+        .quad sym_phys(l1_fixmap) + =
__PAGE_HYPERVISOR=0A+        .else=0A+        .quad 0=0A+        .endif=0A+=
        idx =3D idx + 1=0A+        .endr=0A+        .size l2_fixmap, . - =
l2_fixmap=0A+=0A+        .globl l3_identmap=0A+l3_identmap:=0A+        idx =
=3D 0=0A+        .rept 4=0A+        .quad sym_phys(l2_identmap) + (idx << =
PAGE_SHIFT) + __PAGE_HYPERVISOR=0A+        idx =3D idx + 1=0A+        =
.endr=0A+        .fill L3_PAGETABLE_ENTRIES - 4, 8, 0=0A+        .size =
l3_identmap, . - l3_identmap=0A+=0A+l3_xenmap:=0A+        idx =3D 0=0A+    =
    .rept L3_PAGETABLE_ENTRIES=0A+        .if idx =3D=3D l3_table_offset(XE=
N_VIRT_START)=0A+        .quad sym_phys(l2_xenmap) + __PAGE_HYPERVISOR=0A+ =
       .elseif idx =3D=3D l3_table_offset(FIXADDR_TOP - 1)=0A+        =
.quad sym_phys(l2_fixmap) + __PAGE_HYPERVISOR=0A+        .else=0A+        =
.quad 0=0A+        .endif=0A+        idx =3D idx + 1=0A+        .endr=0A+  =
      .size l3_xenmap, . - l3_xenmap=0A+=0A+/* Top-level master (and =
idle-domain) page directory. */=0A+        .globl idle_pg_table=0A+idle_pg_=
table:=0A+        .quad sym_phys(l3_bootmap) + __PAGE_HYPERVISOR=0A+       =
 idx =3D 1=0A+        .rept L4_PAGETABLE_ENTRIES - 1=0A+        .if idx =
=3D=3D l4_table_offset(DIRECTMAP_VIRT_START)=0A+        .quad sym_phys(l3_i=
dentmap) + __PAGE_HYPERVISOR=0A+        .elseif idx =3D=3D l4_table_offset(=
XEN_VIRT_START)=0A+        .quad sym_phys(l3_xenmap) + __PAGE_HYPERVISOR=0A=
+        .else=0A+        .quad 0=0A+        .endif=0A+        idx =3D idx =
+ 1=0A+        .endr=0A+        .size idle_pg_table, . - idle_pg_table=0A+=
=0A+__page_tables_end:=0A--- a/xen/arch/x86/efi/boot.c=0A+++ b/xen/arch/x86=
/efi/boot.c=0A@@ -573,6 +573,10 @@ static int __init set_color(u32 mask, =
in=0A    return max(*pos + *sz, bpp);=0A }=0A =0A+extern const intpte_t =
__page_tables_start[], __page_tables_end[];=0A+#define in_page_tables(v) =
((intpte_t *)(v) >=3D __page_tables_start && \=0A+                         =
  (intpte_t *)(v) < __page_tables_end)=0A+=0A #define PE_BASE_RELOC_ABS    =
  0=0A #define PE_BASE_RELOC_HIGHLOW  3=0A #define PE_BASE_RELOC_DIR64   =
10=0A@@ -604,11 +608,19 @@ static void __init relocate_image(unsign=0A     =
            break;=0A             case PE_BASE_RELOC_HIGHLOW:=0A           =
      if ( delta )=0A+                {=0A                     *(u32 =
*)addr +=3D delta;=0A+                    if ( in_page_tables(addr) )=0A+  =
                      *(u32 *)addr +=3D xen_phys_start;=0A+                =
}=0A                 break;=0A             case PE_BASE_RELOC_DIR64:=0A    =
             if ( delta )=0A+                {=0A                     =
*(u64 *)addr +=3D delta;=0A+                    if ( in_page_tables(addr) =
)=0A+                        *(intpte_t *)addr +=3D xen_phys_start;=0A+    =
            }=0A                 break;=0A             default:=0A         =
        blexit(L"Unsupported relocation type\r\n");=0A@@ -1113,43 +1125,21 =
@@ efi_start(EFI_HANDLE ImageHandle, EFI_SY=0A         *(u16 *)(*trampoline=
_ptr + (long)trampoline_ptr) =3D=0A             trampoline_phys >> 4;=0A =
=0A-    /* Initialise L2 identity-map and xen page table entries (16MB). =
*/=0A+    /* Initialise L2 identity-map and boot-map page table entries =
(16MB). */=0A     for ( i =3D 0; i < 8; ++i )=0A     {=0A         unsigned =
int slot =3D (xen_phys_start >> L2_PAGETABLE_SHIFT) + i;=0A         =
paddr_t addr =3D slot << L2_PAGETABLE_SHIFT;=0A =0A         l2_identmap[slo=
t] =3D l2e_from_paddr(addr, PAGE_HYPERVISOR|_PAGE_PSE);=0A-        =
l2_xenmap[i] =3D l2e_from_paddr(addr, PAGE_HYPERVISOR|_PAGE_PSE);=0A       =
  slot &=3D L2_PAGETABLE_ENTRIES - 1;=0A         l2_bootmap[slot] =3D =
l2e_from_paddr(addr, __PAGE_HYPERVISOR|_PAGE_PSE);=0A     }=0A-    /* =
Initialise L2 fixmap page directory entry. */=0A-    l2_fixmap[l2_table_off=
set(FIXADDR_TOP - 1)] =3D=0A-        l2e_from_paddr((UINTN)l1_fixmap, =
__PAGE_HYPERVISOR);=0A-    /* Initialise L3 identity-map page directory =
entries. */=0A-    for ( i =3D 0; i < ARRAY_SIZE(l2_identmap) / L2_PAGETABL=
E_ENTRIES; ++i )=0A-        l3_identmap[i] =3D l3e_from_paddr((UINTN)(l2_id=
entmap +=0A-                                                i * L2_PAGETABL=
E_ENTRIES),=0A-                                        __PAGE_HYPERVISOR);=
=0A-    /* Initialise L3 xen-map and fixmap page directory entries. */=0A- =
   l3_xenmap[l3_table_offset(XEN_VIRT_START)] =3D=0A-        l3e_from_paddr=
((UINTN)l2_xenmap, __PAGE_HYPERVISOR);=0A-    l3_xenmap[l3_table_offset(FIX=
ADDR_TOP - 1)] =3D=0A-        l3e_from_paddr((UINTN)l2_fixmap, __PAGE_HYPER=
VISOR);=0A     /* Initialise L3 boot-map page directory entries. */=0A     =
l3_bootmap[l3_table_offset(xen_phys_start)] =3D=0A         l3e_from_paddr((=
UINTN)l2_bootmap, __PAGE_HYPERVISOR);=0A     l3_bootmap[l3_table_offset(xen=
_phys_start + (8 << L2_PAGETABLE_SHIFT) - 1)] =3D=0A         l3e_from_paddr=
((UINTN)l2_bootmap, __PAGE_HYPERVISOR);=0A-    /* Hook identity-map, =
xen-map, and boot-map L3 tables into PML4. */=0A-    idle_pg_table[0] =3D =
l4e_from_paddr((UINTN)l3_bootmap, __PAGE_HYPERVISOR);=0A-    idle_pg_table[=
l4_table_offset(DIRECTMAP_VIRT_START)] =3D=0A-        l4e_from_paddr((UINTN=
)l3_identmap, __PAGE_HYPERVISOR);=0A-    idle_pg_table[l4_table_offset(XEN_=
VIRT_START)] =3D=0A-        l4e_from_paddr((UINTN)l3_xenmap, __PAGE_HYPERVI=
SOR);=0A-    /* Hook 4kB mappings of first 2MB of memory into L2. */=0A-   =
 l2_identmap[0] =3D l2e_from_paddr((UINTN)l1_identmap, __PAGE_HYPERVISOR);=
=0A =0A     if ( gop )=0A     {=0A--- a/xen/arch/x86/x86_64/mm.c=0A+++ =
b/xen/arch/x86/x86_64/mm.c=0A@@ -49,24 +49,6 @@ unsigned int __read_mostly =
pfn_pdx_hole_=0A =0A unsigned int __read_mostly m2p_compat_vstart =3D =
__HYPERVISOR_COMPAT_VIRT_START;=0A =0A-/* Top-level master (and idle-domain=
) page directory. */=0A-l4_pgentry_t __attribute__ ((__section__ (".bss.pag=
e_aligned")))=0A-    idle_pg_table[L4_PAGETABLE_ENTRIES];=0A-=0A-/* Enough =
page directories to map bottom 4GB of the memory map. */=0A-l3_pgentry_t =
__attribute__ ((__section__ (".bss.page_aligned")))=0A-    l3_identmap[L3_P=
AGETABLE_ENTRIES];=0A-=0A-/* Enough page directories to map the Xen text =
and static data. */=0A-l3_pgentry_t __attribute__ ((__section__ (".bss.page=
_aligned")))=0A-    l3_xenmap[L3_PAGETABLE_ENTRIES];=0A-l2_pgentry_t =
__attribute__ ((__section__ (".bss.page_aligned")))=0A-    l2_xenmap[L2_PAG=
ETABLE_ENTRIES];=0A-=0A-/* Enough page directories to map the early fixmap =
space. */=0A-l2_pgentry_t __attribute__ ((__section__ (".bss.page_aligned")=
))=0A-    l2_fixmap[L2_PAGETABLE_ENTRIES];=0A-=0A /* Enough page directorie=
s to map into the bottom 1GB. */=0A l3_pgentry_t __attribute__ ((__section_=
_ (".bss.page_aligned")))=0A     l3_bootmap[L3_PAGETABLE_ENTRIES];=0A--- =
a/xen/arch/x86/xen.lds.S=0A+++ b/xen/arch/x86/xen.lds.S=0A@@ -42,6 +42,10 =
@@ PHDRS=0A }=0A SECTIONS=0A {=0A+#if defined(__x86_64__) && !defined(EFI)=
=0A+  . =3D __XEN_VIRT_START;=0A+  __image_base__ =3D .;=0A+#endif=0A   . =
=3D __XEN_VIRT_START + 0x100000;=0A   _start =3D .;=0A   .text : {=0A--- =
a/xen/include/asm-x86/page.h=0A+++ b/xen/include/asm-x86/page.h=0A@@ =
-304,11 +304,8 @@ extern l2_pgentry_t   idle_pg_table_l2[=0A extern =
l2_pgentry_t  *compat_idle_pg_table_l2;=0A extern unsigned int   m2p_compat=
_vstart;=0A extern l2_pgentry_t l2_xenmap[L2_PAGETABLE_ENTRIES],=0A-    =
l2_fixmap[L2_PAGETABLE_ENTRIES],=0A     l2_bootmap[L2_PAGETABLE_ENTRIES];=
=0A-extern l3_pgentry_t l3_xenmap[L3_PAGETABLE_ENTRIES],=0A-    l3_identmap=
[L3_PAGETABLE_ENTRIES],=0A-    l3_bootmap[L3_PAGETABLE_ENTRIES];=0A+extern =
l3_pgentry_t l3_bootmap[L3_PAGETABLE_ENTRIES];=0A #endif=0A extern =
l2_pgentry_t l2_identmap[4*L2_PAGETABLE_ENTRIES];=0A extern l1_pgentry_t =
l1_identmap[L1_PAGETABLE_ENTRIES],=0A
--=__Part20113275.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

--=__Part20113275.0__=--


From xen-devel-bounces@lists.xen.org Tue Sep 11 11:40:44 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 2012 11: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 1TBOpP-0006qv-Ei; Tue, 11 Sep 2012 11:40:27 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <steve@zentific.com>) id 1TBOpN-0006qc-6S
	for xen-devel@lists.xen.org; Tue, 11 Sep 2012 11:40:25 +0000
Received: from [85.158.143.99:17472] by server-3.bemta-4.messagelabs.com id
	FD/FF-08232-8232F405; Tue, 11 Sep 2012 11:40:24 +0000
X-Env-Sender: steve@zentific.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1347363613!29744808!1
X-Originating-IP: [209.85.212.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16542 invoked from network); 11 Sep 2012 11:40:23 -0000
Received: from mail-vb0-f45.google.com (HELO mail-vb0-f45.google.com)
	(209.85.212.45)
	by server-9.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Sep 2012 11:40:23 -0000
Received: by vbip1 with SMTP id p1so595304vbi.32
	for <xen-devel@lists.xen.org>; Tue, 11 Sep 2012 04:40:13 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to
	:cc:content-type:x-gm-message-state;
	bh=asJydkzj8yJ0vQBhgzrLI0JKEuB+BHxc56If2ZY7HnI=;
	b=MSI4bMMQZ6sH7K4W+LRadJfC52qBeRLsyHcCbMysoZAkKofCb8TtLEluOOZAo0sF+R
	8OvgJJ7NzpiNQXKtqJaYPvssiIAlHITHjyxPmCyQ7XNVRRm+ZLHnMgfYDHPfLPS7TsQz
	38En3IoPsKSrhtRmmwKWyIo5AQ6P5CwL/y4IJLOZd8qpltbAyGTf6aGOIYW3Rkof9id4
	RheUATrXGRgvhvInkewYhKSJ36Ceg0jQL5rToqb1EVbtIrL18Q8XuhmpmgM1H4kITHxF
	X4a6OpUaHRi00rtZvCD/o+pl1Vwoc+YeJHTCaiGXH6Xlo3+38KTt/p1zfN+hd0qLRSa2
	rIYQ==
Received: by 10.52.240.171 with SMTP id wb11mr19820897vdc.86.1347363613162;
	Tue, 11 Sep 2012 04:40:13 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.220.25.76 with HTTP; Tue, 11 Sep 2012 04:39:32 -0700 (PDT)
In-Reply-To: <20120911072225.GB78597@ocelot.phlegethon.org>
References: <CANSvah6PU5SOKd19qfbvTXvz4spcPYVUQHmiirmm5hPvmzR+pg@mail.gmail.com>
	<CC741C8D.4B3AF%keir@xen.org>
	<CANSvah6nWfKP9-PLSkhbFcO2ONmfj5Hhs-+3r0MhjOUHU1qNfg@mail.gmail.com>
	<CAB10MZDy0zTQNO5APyWMgbhiKw+4uXZ2pYMKHqJ3MNKR5gLjjA@mail.gmail.com>
	<CANSvah4NN05Zimm2BmKO9ofC04G+D7Svrg+2xwp0yM16Cn3CRw@mail.gmail.com>
	<20120911072225.GB78597@ocelot.phlegethon.org>
From: Steven Maresca <steve@zentific.com>
Date: Tue, 11 Sep 2012 07:39:32 -0400
Message-ID: <CANSvah6AY1-yyNmCp4dU5jSUr8zBxwoBOVo1ux8nO8U-yScYYg@mail.gmail.com>
To: Tim Deegan <tim@xen.org>
X-Gm-Message-State: ALoCoQmQv75xJy6Cp4YEV6/XGJDpRou6cxbEi8HAlhB97e06gtsBo8V2hO30jvg5nTkFyMpxJOan
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] mem_event: fix regression affecting CR3,
 CR4 memory events
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Sep 11, 2012 at 3:22 AM, Tim Deegan <tim@xen.org> wrote:
> At 23:56 -0400 on 10 Sep (1347321409), Steven Maresca wrote:
>> On Mon, Sep 10, 2012 at 9:49 PM, Aravindh Puthiyaparambil
>> <aravindh@virtuata.com> wrote:
>> > On Mon, Sep 10, 2012 at 3:06 PM, Steven Maresca <steve@zentific.com> wrote:
>> >> On Mon, Sep 10, 2012 at 5:39 PM, Keir Fraser <keir@xen.org> wrote:
>> >>> On 10/09/2012 22:20, "Steven Maresca" <steve@zentific.com> wrote:
>> >>>
>> >>>> Given the refactoring in the commit related to the regression
>> >>>> http://xenbits.xen.org/hg/xen-unstable.hg/rev/1276926e3795, it seemed
>> >>>> (to me anyway) that inserting calls as shown in the patch would be
>> >>>> cleaner, but I can definitely come up with some drawbacks.  However, I
>> >>>> wanted to get this fixed for 4.2 if at all possible, so I wanted to
>> >>>> send regardless.
>> >>>>
>> >>>> In terms of drawbacks, this will require some ifdefs for x86_64, for example.
>> >>>>
>> >>>> Any suggestions for the cleanest means of achieving the same in vmx.c?
>> >>>
>> >>> I don't understand this at all. The original commit moved some CR handling
>> >>> to common HVM code. Your patch adds some mem_event calls into that common
>> >>> HVM code. What would need to be "achieved" in vmx.c? What ifdefs would be
>> >>> required for x86_64?
>> >>>
>> >>>  -- Keir
>> >>>
>> >>>
>> >>
>> >> Keir,
>> >>
>> >> In the process of moving CR handling to common code, that commit
>> >> removed calls to hvm_memory_event_cr3() and hvm_memory_event_cr4().
>> >> Without some patch restoring the calls to those two functions, current
>> >> xen-unstable and xen-4.2-testing only reference them as function
>> >> prototypes and function definitions -- there are no calls whatsoever.
>> >>
>> >> I only mentioned an ifdef relative to x86_64 because of the #ifdef
>> >> __x86_64__  around the function definitions. ( I know in the hvm.h
>> >> itself they're just empty inline functions if not __x86_64__. )
>> >>
>> >> Regarding vmx.c: hvm_memory_event_cr0 is called within vmx_cr_access.
>> >> The patch I sent restoring the calls to hvm_memory_event_cr4 and
>> >> hvm_memory_event_cr3 could be treated similarly, that's all.
>> >
>> > Looks good to me.
>> > Acked-by: Aravindh Puthiyaparambil <aravindh@virtuata.com>
>> >
>> > Cheers,
>> > Aravindh
>>
>> Adding Tim Deegan as suggested.
>>
>> Tim, this is a regression fix for CR3/CR4 memory events
>> unintentionally removed during some refactoring of HVM CR handling.
>> If at all possible, for 4.2 inclusion before we officially leave RC.
>
> I think it's too late to get any more code changes in to 4.2.0, so this
> will have to wait for 4.2.1.  Ian?
>
> The patch looks OK, but why didn't you put the memory_event calls back
> in mov_to_cr(), which is where they were before that?
>
> Cheers,
>
> Tim.

Tim,

This bugfix could definitely be placed in hvm_mov_to_cr() - it just
seemed more localized if placed in the hvm_set_cr*() functions. I'll
happily defer to preference, if you have one.

Thanks,
Steve

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 11 11:40:44 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 2012 11: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 1TBOpP-0006qv-Ei; Tue, 11 Sep 2012 11:40:27 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <steve@zentific.com>) id 1TBOpN-0006qc-6S
	for xen-devel@lists.xen.org; Tue, 11 Sep 2012 11:40:25 +0000
Received: from [85.158.143.99:17472] by server-3.bemta-4.messagelabs.com id
	FD/FF-08232-8232F405; Tue, 11 Sep 2012 11:40:24 +0000
X-Env-Sender: steve@zentific.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1347363613!29744808!1
X-Originating-IP: [209.85.212.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16542 invoked from network); 11 Sep 2012 11:40:23 -0000
Received: from mail-vb0-f45.google.com (HELO mail-vb0-f45.google.com)
	(209.85.212.45)
	by server-9.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Sep 2012 11:40:23 -0000
Received: by vbip1 with SMTP id p1so595304vbi.32
	for <xen-devel@lists.xen.org>; Tue, 11 Sep 2012 04:40:13 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to
	:cc:content-type:x-gm-message-state;
	bh=asJydkzj8yJ0vQBhgzrLI0JKEuB+BHxc56If2ZY7HnI=;
	b=MSI4bMMQZ6sH7K4W+LRadJfC52qBeRLsyHcCbMysoZAkKofCb8TtLEluOOZAo0sF+R
	8OvgJJ7NzpiNQXKtqJaYPvssiIAlHITHjyxPmCyQ7XNVRRm+ZLHnMgfYDHPfLPS7TsQz
	38En3IoPsKSrhtRmmwKWyIo5AQ6P5CwL/y4IJLOZd8qpltbAyGTf6aGOIYW3Rkof9id4
	RheUATrXGRgvhvInkewYhKSJ36Ceg0jQL5rToqb1EVbtIrL18Q8XuhmpmgM1H4kITHxF
	X4a6OpUaHRi00rtZvCD/o+pl1Vwoc+YeJHTCaiGXH6Xlo3+38KTt/p1zfN+hd0qLRSa2
	rIYQ==
Received: by 10.52.240.171 with SMTP id wb11mr19820897vdc.86.1347363613162;
	Tue, 11 Sep 2012 04:40:13 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.220.25.76 with HTTP; Tue, 11 Sep 2012 04:39:32 -0700 (PDT)
In-Reply-To: <20120911072225.GB78597@ocelot.phlegethon.org>
References: <CANSvah6PU5SOKd19qfbvTXvz4spcPYVUQHmiirmm5hPvmzR+pg@mail.gmail.com>
	<CC741C8D.4B3AF%keir@xen.org>
	<CANSvah6nWfKP9-PLSkhbFcO2ONmfj5Hhs-+3r0MhjOUHU1qNfg@mail.gmail.com>
	<CAB10MZDy0zTQNO5APyWMgbhiKw+4uXZ2pYMKHqJ3MNKR5gLjjA@mail.gmail.com>
	<CANSvah4NN05Zimm2BmKO9ofC04G+D7Svrg+2xwp0yM16Cn3CRw@mail.gmail.com>
	<20120911072225.GB78597@ocelot.phlegethon.org>
From: Steven Maresca <steve@zentific.com>
Date: Tue, 11 Sep 2012 07:39:32 -0400
Message-ID: <CANSvah6AY1-yyNmCp4dU5jSUr8zBxwoBOVo1ux8nO8U-yScYYg@mail.gmail.com>
To: Tim Deegan <tim@xen.org>
X-Gm-Message-State: ALoCoQmQv75xJy6Cp4YEV6/XGJDpRou6cxbEi8HAlhB97e06gtsBo8V2hO30jvg5nTkFyMpxJOan
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] mem_event: fix regression affecting CR3,
 CR4 memory events
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Sep 11, 2012 at 3:22 AM, Tim Deegan <tim@xen.org> wrote:
> At 23:56 -0400 on 10 Sep (1347321409), Steven Maresca wrote:
>> On Mon, Sep 10, 2012 at 9:49 PM, Aravindh Puthiyaparambil
>> <aravindh@virtuata.com> wrote:
>> > On Mon, Sep 10, 2012 at 3:06 PM, Steven Maresca <steve@zentific.com> wrote:
>> >> On Mon, Sep 10, 2012 at 5:39 PM, Keir Fraser <keir@xen.org> wrote:
>> >>> On 10/09/2012 22:20, "Steven Maresca" <steve@zentific.com> wrote:
>> >>>
>> >>>> Given the refactoring in the commit related to the regression
>> >>>> http://xenbits.xen.org/hg/xen-unstable.hg/rev/1276926e3795, it seemed
>> >>>> (to me anyway) that inserting calls as shown in the patch would be
>> >>>> cleaner, but I can definitely come up with some drawbacks.  However, I
>> >>>> wanted to get this fixed for 4.2 if at all possible, so I wanted to
>> >>>> send regardless.
>> >>>>
>> >>>> In terms of drawbacks, this will require some ifdefs for x86_64, for example.
>> >>>>
>> >>>> Any suggestions for the cleanest means of achieving the same in vmx.c?
>> >>>
>> >>> I don't understand this at all. The original commit moved some CR handling
>> >>> to common HVM code. Your patch adds some mem_event calls into that common
>> >>> HVM code. What would need to be "achieved" in vmx.c? What ifdefs would be
>> >>> required for x86_64?
>> >>>
>> >>>  -- Keir
>> >>>
>> >>>
>> >>
>> >> Keir,
>> >>
>> >> In the process of moving CR handling to common code, that commit
>> >> removed calls to hvm_memory_event_cr3() and hvm_memory_event_cr4().
>> >> Without some patch restoring the calls to those two functions, current
>> >> xen-unstable and xen-4.2-testing only reference them as function
>> >> prototypes and function definitions -- there are no calls whatsoever.
>> >>
>> >> I only mentioned an ifdef relative to x86_64 because of the #ifdef
>> >> __x86_64__  around the function definitions. ( I know in the hvm.h
>> >> itself they're just empty inline functions if not __x86_64__. )
>> >>
>> >> Regarding vmx.c: hvm_memory_event_cr0 is called within vmx_cr_access.
>> >> The patch I sent restoring the calls to hvm_memory_event_cr4 and
>> >> hvm_memory_event_cr3 could be treated similarly, that's all.
>> >
>> > Looks good to me.
>> > Acked-by: Aravindh Puthiyaparambil <aravindh@virtuata.com>
>> >
>> > Cheers,
>> > Aravindh
>>
>> Adding Tim Deegan as suggested.
>>
>> Tim, this is a regression fix for CR3/CR4 memory events
>> unintentionally removed during some refactoring of HVM CR handling.
>> If at all possible, for 4.2 inclusion before we officially leave RC.
>
> I think it's too late to get any more code changes in to 4.2.0, so this
> will have to wait for 4.2.1.  Ian?
>
> The patch looks OK, but why didn't you put the memory_event calls back
> in mov_to_cr(), which is where they were before that?
>
> Cheers,
>
> Tim.

Tim,

This bugfix could definitely be placed in hvm_mov_to_cr() - it just
seemed more localized if placed in the hvm_set_cr*() functions. I'll
happily defer to preference, if you have one.

Thanks,
Steve

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 11 11:41:48 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 2012 11: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 1TBOqV-0006xd-Tc; Tue, 11 Sep 2012 11:41: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 1TBOqU-0006xR-Km
	for xen-devel@lists.xen.org; Tue, 11 Sep 2012 11:41:34 +0000
Received: from [85.158.138.51:3239] by server-10.bemta-3.messagelabs.com id
	0D/1B-10411-D632F405; Tue, 11 Sep 2012 11:41:33 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1347363692!11212091!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQwNzc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19865 invoked from network); 11 Sep 2012 11:41:32 -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;
	11 Sep 2012 11:41:32 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 11 Sep 2012 12:41:32 +0100
Message-Id: <504F3F8A020000780009A8F9@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 11 Sep 2012 12:41:30 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part2E1F3C7A.0__="
Subject: [Xen-devel] [PATCH] x86: retrieve keyboard shift status flags from
	BIOS
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
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.

--=__Part2E1F3C7A.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Recent Linux tries to make use of this, and has no way of getting at
these bits without Xen assisting it.

There doesn't appear to be a way to obtain the same information from
UEFI.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/arch/x86/boot/trampoline.S
+++ b/xen/arch/x86/boot/trampoline.S
@@ -184,11 +184,16 @@ trampoline_boot_cpu_entry:
          *  1. Get memory map.
          *  2. Get Enhanced Disk Drive (EDD) information.
          *  3. Set video mode.
+         *  4. Get keyboard shift flags.
          */
         call    get_memory_map
         call    get_edd
         call    video
=20
+        mov     $0x0200,%ax
+        int     $0x16
+        mov     %al,bootsym(kbd_shift_flags)
+
         /* Disable irqs before returning to protected mode. */
         cli
=20
@@ -221,6 +226,10 @@ trampoline_boot_cpu_entry:
 skip_realmode:
         .byte   0
=20
+        .globl kbd_shift_flags
+kbd_shift_flags:
+        .byte   0
+
 rm_idt: .word   256*4-1, 0, 0
=20
 #include "mem.S"
--- a/xen/arch/x86/platform_hypercall.c
+++ b/xen/arch/x86/platform_hypercall.c
@@ -29,6 +29,7 @@
 #include <asm/edd.h>
 #include <asm/mtrr.h>
 #include <asm/io_apic.h>
+#include <asm/setup.h>
 #include "cpu/mtrr/mtrr.h"
 #include <xsm/xsm.h>
=20
@@ -319,6 +320,18 @@ ret_t do_platform_op(XEN_GUEST_HANDLE(xe
                                      u.firmware_info.u.efi_info) )
                 ret =3D -EFAULT;
             break;
+        case XEN_FW_KBD_SHIFT_FLAGS:
+            ret =3D -ESRCH;
+            if ( op->u.firmware_info.index !=3D 0 )
+                break;
+
+            op->u.firmware_info.u.kbd_shift_flags =3D bootsym(kbd_shift_fl=
ags);
+
+            ret =3D 0;
+            if ( copy_field_to_guest(u_xenpf_op, op,
+                                     u.firmware_info.u.kbd_shift_flags) )
+                ret =3D -EFAULT;
+            break;
         default:
             ret =3D -EINVAL;
             break;
--- a/xen/include/asm-x86/setup.h
+++ b/xen/include/asm-x86/setup.h
@@ -41,4 +41,6 @@ int xen_in_range(unsigned long mfn);
 void microcode_grab_module(
     unsigned long *, const multiboot_info_t *, void *(*)(const module_t =
*));
=20
+extern uint8_t kbd_shift_flags;
+
 #endif
--- a/xen/include/public/platform.h
+++ b/xen/include/public/platform.h
@@ -218,6 +218,7 @@ DEFINE_XEN_GUEST_HANDLE(xenpf_efi_runtim
 #define  XEN_FW_EFI_VENDOR         2
 #define  XEN_FW_EFI_MEM_INFO       3
 #define  XEN_FW_EFI_RT_VERSION     4
+#define XEN_FW_KBD_SHIFT_FLAGS    5
 struct xenpf_firmware_info {
     /* IN variables. */
     uint32_t type;
@@ -266,6 +267,9 @@ struct xenpf_firmware_info {
                 uint32_t type;
             } mem;
         } efi_info; /* XEN_FW_EFI_INFO */
+
+        /* Int16, Fn02: Get keyboard shift flags. */
+        uint8_t kbd_shift_flags; /* XEN_FW_KBD_SHIFT_FLAGS */
     } u;
 };
 typedef struct xenpf_firmware_info xenpf_firmware_info_t;




--=__Part2E1F3C7A.0__=
Content-Type: text/plain; name="x86-boot-keyboard-state.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="x86-boot-keyboard-state.patch"

x86: retrieve keyboard shift status flags from BIOS=0A=0ARecent Linux =
tries to make use of this, and has no way of getting at=0Athese bits =
without Xen assisting it.=0A=0AThere doesn't appear to be a way to obtain =
the same information from=0AUEFI.=0A=0ASigned-off-by: Jan Beulich =
<jbeulich@suse.com>=0A=0A--- a/xen/arch/x86/boot/trampoline.S=0A+++ =
b/xen/arch/x86/boot/trampoline.S=0A@@ -184,11 +184,16 @@ trampoline_boot_cp=
u_entry:=0A          *  1. Get memory map.=0A          *  2. Get Enhanced =
Disk Drive (EDD) information.=0A          *  3. Set video mode.=0A+        =
 *  4. Get keyboard shift flags.=0A          */=0A         call    =
get_memory_map=0A         call    get_edd=0A         call    video=0A =0A+ =
       mov     $0x0200,%ax=0A+        int     $0x16=0A+        mov     =
%al,bootsym(kbd_shift_flags)=0A+=0A         /* Disable irqs before =
returning to protected mode. */=0A         cli=0A =0A@@ -221,6 +226,10 @@ =
trampoline_boot_cpu_entry:=0A skip_realmode:=0A         .byte   0=0A =0A+  =
      .globl kbd_shift_flags=0A+kbd_shift_flags:=0A+        .byte   =
0=0A+=0A rm_idt: .word   256*4-1, 0, 0=0A =0A #include "mem.S"=0A--- =
a/xen/arch/x86/platform_hypercall.c=0A+++ b/xen/arch/x86/platform_hypercall=
.c=0A@@ -29,6 +29,7 @@=0A #include <asm/edd.h>=0A #include <asm/mtrr.h>=0A =
#include <asm/io_apic.h>=0A+#include <asm/setup.h>=0A #include "cpu/mtrr/mt=
rr.h"=0A #include <xsm/xsm.h>=0A =0A@@ -319,6 +320,18 @@ ret_t do_platform_=
op(XEN_GUEST_HANDLE(xe=0A                                      u.firmware_i=
nfo.u.efi_info) )=0A                 ret =3D -EFAULT;=0A             =
break;=0A+        case XEN_FW_KBD_SHIFT_FLAGS:=0A+            ret =3D =
-ESRCH;=0A+            if ( op->u.firmware_info.index !=3D 0 )=0A+         =
       break;=0A+=0A+            op->u.firmware_info.u.kbd_shift_flags =3D =
bootsym(kbd_shift_flags);=0A+=0A+            ret =3D 0;=0A+            if =
( copy_field_to_guest(u_xenpf_op, op,=0A+                                  =
   u.firmware_info.u.kbd_shift_flags) )=0A+                ret =3D =
-EFAULT;=0A+            break;=0A         default:=0A             ret =3D =
-EINVAL;=0A             break;=0A--- a/xen/include/asm-x86/setup.h=0A+++ =
b/xen/include/asm-x86/setup.h=0A@@ -41,4 +41,6 @@ int xen_in_range(unsigned=
 long mfn);=0A void microcode_grab_module(=0A     unsigned long *, const =
multiboot_info_t *, void *(*)(const module_t *));=0A =0A+extern uint8_t =
kbd_shift_flags;=0A+=0A #endif=0A--- a/xen/include/public/platform.h=0A+++ =
b/xen/include/public/platform.h=0A@@ -218,6 +218,7 @@ DEFINE_XEN_GUEST_HAND=
LE(xenpf_efi_runtim=0A #define  XEN_FW_EFI_VENDOR         2=0A #define  =
XEN_FW_EFI_MEM_INFO       3=0A #define  XEN_FW_EFI_RT_VERSION     =
4=0A+#define XEN_FW_KBD_SHIFT_FLAGS    5=0A struct xenpf_firmware_info =
{=0A     /* IN variables. */=0A     uint32_t type;=0A@@ -266,6 +267,9 @@ =
struct xenpf_firmware_info {=0A                 uint32_t type;=0A          =
   } mem;=0A         } efi_info; /* XEN_FW_EFI_INFO */=0A+=0A+        /* =
Int16, Fn02: Get keyboard shift flags. */=0A+        uint8_t kbd_shift_flag=
s; /* XEN_FW_KBD_SHIFT_FLAGS */=0A     } u;=0A };=0A typedef struct =
xenpf_firmware_info xenpf_firmware_info_t;=0A
--=__Part2E1F3C7A.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

--=__Part2E1F3C7A.0__=--


From xen-devel-bounces@lists.xen.org Tue Sep 11 11:41:48 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 2012 11: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 1TBOqV-0006xd-Tc; Tue, 11 Sep 2012 11:41: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 1TBOqU-0006xR-Km
	for xen-devel@lists.xen.org; Tue, 11 Sep 2012 11:41:34 +0000
Received: from [85.158.138.51:3239] by server-10.bemta-3.messagelabs.com id
	0D/1B-10411-D632F405; Tue, 11 Sep 2012 11:41:33 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1347363692!11212091!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQwNzc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19865 invoked from network); 11 Sep 2012 11:41:32 -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;
	11 Sep 2012 11:41:32 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 11 Sep 2012 12:41:32 +0100
Message-Id: <504F3F8A020000780009A8F9@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 11 Sep 2012 12:41:30 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part2E1F3C7A.0__="
Subject: [Xen-devel] [PATCH] x86: retrieve keyboard shift status flags from
	BIOS
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
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.

--=__Part2E1F3C7A.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Recent Linux tries to make use of this, and has no way of getting at
these bits without Xen assisting it.

There doesn't appear to be a way to obtain the same information from
UEFI.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/arch/x86/boot/trampoline.S
+++ b/xen/arch/x86/boot/trampoline.S
@@ -184,11 +184,16 @@ trampoline_boot_cpu_entry:
          *  1. Get memory map.
          *  2. Get Enhanced Disk Drive (EDD) information.
          *  3. Set video mode.
+         *  4. Get keyboard shift flags.
          */
         call    get_memory_map
         call    get_edd
         call    video
=20
+        mov     $0x0200,%ax
+        int     $0x16
+        mov     %al,bootsym(kbd_shift_flags)
+
         /* Disable irqs before returning to protected mode. */
         cli
=20
@@ -221,6 +226,10 @@ trampoline_boot_cpu_entry:
 skip_realmode:
         .byte   0
=20
+        .globl kbd_shift_flags
+kbd_shift_flags:
+        .byte   0
+
 rm_idt: .word   256*4-1, 0, 0
=20
 #include "mem.S"
--- a/xen/arch/x86/platform_hypercall.c
+++ b/xen/arch/x86/platform_hypercall.c
@@ -29,6 +29,7 @@
 #include <asm/edd.h>
 #include <asm/mtrr.h>
 #include <asm/io_apic.h>
+#include <asm/setup.h>
 #include "cpu/mtrr/mtrr.h"
 #include <xsm/xsm.h>
=20
@@ -319,6 +320,18 @@ ret_t do_platform_op(XEN_GUEST_HANDLE(xe
                                      u.firmware_info.u.efi_info) )
                 ret =3D -EFAULT;
             break;
+        case XEN_FW_KBD_SHIFT_FLAGS:
+            ret =3D -ESRCH;
+            if ( op->u.firmware_info.index !=3D 0 )
+                break;
+
+            op->u.firmware_info.u.kbd_shift_flags =3D bootsym(kbd_shift_fl=
ags);
+
+            ret =3D 0;
+            if ( copy_field_to_guest(u_xenpf_op, op,
+                                     u.firmware_info.u.kbd_shift_flags) )
+                ret =3D -EFAULT;
+            break;
         default:
             ret =3D -EINVAL;
             break;
--- a/xen/include/asm-x86/setup.h
+++ b/xen/include/asm-x86/setup.h
@@ -41,4 +41,6 @@ int xen_in_range(unsigned long mfn);
 void microcode_grab_module(
     unsigned long *, const multiboot_info_t *, void *(*)(const module_t =
*));
=20
+extern uint8_t kbd_shift_flags;
+
 #endif
--- a/xen/include/public/platform.h
+++ b/xen/include/public/platform.h
@@ -218,6 +218,7 @@ DEFINE_XEN_GUEST_HANDLE(xenpf_efi_runtim
 #define  XEN_FW_EFI_VENDOR         2
 #define  XEN_FW_EFI_MEM_INFO       3
 #define  XEN_FW_EFI_RT_VERSION     4
+#define XEN_FW_KBD_SHIFT_FLAGS    5
 struct xenpf_firmware_info {
     /* IN variables. */
     uint32_t type;
@@ -266,6 +267,9 @@ struct xenpf_firmware_info {
                 uint32_t type;
             } mem;
         } efi_info; /* XEN_FW_EFI_INFO */
+
+        /* Int16, Fn02: Get keyboard shift flags. */
+        uint8_t kbd_shift_flags; /* XEN_FW_KBD_SHIFT_FLAGS */
     } u;
 };
 typedef struct xenpf_firmware_info xenpf_firmware_info_t;




--=__Part2E1F3C7A.0__=
Content-Type: text/plain; name="x86-boot-keyboard-state.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="x86-boot-keyboard-state.patch"

x86: retrieve keyboard shift status flags from BIOS=0A=0ARecent Linux =
tries to make use of this, and has no way of getting at=0Athese bits =
without Xen assisting it.=0A=0AThere doesn't appear to be a way to obtain =
the same information from=0AUEFI.=0A=0ASigned-off-by: Jan Beulich =
<jbeulich@suse.com>=0A=0A--- a/xen/arch/x86/boot/trampoline.S=0A+++ =
b/xen/arch/x86/boot/trampoline.S=0A@@ -184,11 +184,16 @@ trampoline_boot_cp=
u_entry:=0A          *  1. Get memory map.=0A          *  2. Get Enhanced =
Disk Drive (EDD) information.=0A          *  3. Set video mode.=0A+        =
 *  4. Get keyboard shift flags.=0A          */=0A         call    =
get_memory_map=0A         call    get_edd=0A         call    video=0A =0A+ =
       mov     $0x0200,%ax=0A+        int     $0x16=0A+        mov     =
%al,bootsym(kbd_shift_flags)=0A+=0A         /* Disable irqs before =
returning to protected mode. */=0A         cli=0A =0A@@ -221,6 +226,10 @@ =
trampoline_boot_cpu_entry:=0A skip_realmode:=0A         .byte   0=0A =0A+  =
      .globl kbd_shift_flags=0A+kbd_shift_flags:=0A+        .byte   =
0=0A+=0A rm_idt: .word   256*4-1, 0, 0=0A =0A #include "mem.S"=0A--- =
a/xen/arch/x86/platform_hypercall.c=0A+++ b/xen/arch/x86/platform_hypercall=
.c=0A@@ -29,6 +29,7 @@=0A #include <asm/edd.h>=0A #include <asm/mtrr.h>=0A =
#include <asm/io_apic.h>=0A+#include <asm/setup.h>=0A #include "cpu/mtrr/mt=
rr.h"=0A #include <xsm/xsm.h>=0A =0A@@ -319,6 +320,18 @@ ret_t do_platform_=
op(XEN_GUEST_HANDLE(xe=0A                                      u.firmware_i=
nfo.u.efi_info) )=0A                 ret =3D -EFAULT;=0A             =
break;=0A+        case XEN_FW_KBD_SHIFT_FLAGS:=0A+            ret =3D =
-ESRCH;=0A+            if ( op->u.firmware_info.index !=3D 0 )=0A+         =
       break;=0A+=0A+            op->u.firmware_info.u.kbd_shift_flags =3D =
bootsym(kbd_shift_flags);=0A+=0A+            ret =3D 0;=0A+            if =
( copy_field_to_guest(u_xenpf_op, op,=0A+                                  =
   u.firmware_info.u.kbd_shift_flags) )=0A+                ret =3D =
-EFAULT;=0A+            break;=0A         default:=0A             ret =3D =
-EINVAL;=0A             break;=0A--- a/xen/include/asm-x86/setup.h=0A+++ =
b/xen/include/asm-x86/setup.h=0A@@ -41,4 +41,6 @@ int xen_in_range(unsigned=
 long mfn);=0A void microcode_grab_module(=0A     unsigned long *, const =
multiboot_info_t *, void *(*)(const module_t *));=0A =0A+extern uint8_t =
kbd_shift_flags;=0A+=0A #endif=0A--- a/xen/include/public/platform.h=0A+++ =
b/xen/include/public/platform.h=0A@@ -218,6 +218,7 @@ DEFINE_XEN_GUEST_HAND=
LE(xenpf_efi_runtim=0A #define  XEN_FW_EFI_VENDOR         2=0A #define  =
XEN_FW_EFI_MEM_INFO       3=0A #define  XEN_FW_EFI_RT_VERSION     =
4=0A+#define XEN_FW_KBD_SHIFT_FLAGS    5=0A struct xenpf_firmware_info =
{=0A     /* IN variables. */=0A     uint32_t type;=0A@@ -266,6 +267,9 @@ =
struct xenpf_firmware_info {=0A                 uint32_t type;=0A          =
   } mem;=0A         } efi_info; /* XEN_FW_EFI_INFO */=0A+=0A+        /* =
Int16, Fn02: Get keyboard shift flags. */=0A+        uint8_t kbd_shift_flag=
s; /* XEN_FW_KBD_SHIFT_FLAGS */=0A     } u;=0A };=0A typedef struct =
xenpf_firmware_info xenpf_firmware_info_t;=0A
--=__Part2E1F3C7A.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

--=__Part2E1F3C7A.0__=--


From xen-devel-bounces@lists.xen.org Tue Sep 11 11:48:20 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 2012 11: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 1TBOwo-0007DK-OV; Tue, 11 Sep 2012 11:48:06 +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 1TBOwn-0007DF-BG
	for xen-devel@lists.xen.org; Tue, 11 Sep 2012 11:48:05 +0000
Received: from [85.158.139.83:2736] by server-12.bemta-5.messagelabs.com id
	B2/43-18300-4F42F405; Tue, 11 Sep 2012 11:48:04 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1347364082!25304588!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDc0Mjk0Nw==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12742 invoked from network); 11 Sep 2012 11:48:04 -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; 11 Sep 2012 11:48:04 -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 q8BBluSY027799
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 11 Sep 2012 11:47:56 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
	q8BBlsEl002359
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 11 Sep 2012 11:47:55 GMT
Received: from abhmt105.oracle.com (abhmt105.oracle.com [141.146.116.57])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q8BBlsBb026127; Tue, 11 Sep 2012 06:47:54 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 11 Sep 2012 04:47:54 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id EEA1B402E4; Tue, 11 Sep 2012 07:37:15 -0400 (EDT)
Date: Tue, 11 Sep 2012 07:37:15 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Matt Wilson <msw@amazon.com>, jforbes@redhat.com, kernel-maint@redhat.com
Message-ID: <20120911113715.GA28221@phenom.dumpdata.com>
References: <1347018043-21252-1-git-send-email-stefan.bader@canonical.com>
	<504A05B00200007800099C7B@nat28.tlf.novell.com>
	<5049F4E9.9050306@canonical.com>
	<504A1A950200007800099D4C@nat28.tlf.novell.com>
	<20120907142251.GA20096@linuxtx.org>
	<504A32800200007800099E40@nat28.tlf.novell.com>
	<1347033622.2980.12.camel@fedora64.linuxtx.org>
	<20120911024047.GA7620@u002268147cd4502c336d.ant.amazon.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120911024047.GA7620@u002268147cd4502c336d.ant.amazon.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	"Justin M. Forbes" <jmforbes@linuxtx.org>,
	Stefan Bader <stefan.bader@canonical.com>,
	Jan Beulich <JBeulich@suse.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH/RFC] Fix xsave bug on older Xen hypervisors
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Sep 10, 2012 at 07:40:47PM -0700, Matt Wilson wrote:
> On Fri, Sep 07, 2012 at 11:00:22AM -0500, Justin M. Forbes wrote:
> > On Fri, 2012-09-07 at 16:44 +0100, Jan Beulich wrote:
> > > 
> > > All of this still doesn't provide evidence that a plain upstream
> > > kernel is actually having any problems in the first place. Further,
> > > if you say EC2 has a crippled hypervisor patch - is that patch
> > > available for looking at somewhere?
> > 
> > Yes, I can verify that a plain upstream kernel has problems in the first
> > place, which is why we are carrying a patch to simply disable xsave all
> > together in the pv guest.
> > EC2 is not carrying a patch to cripple the hypervisor, there was an old
> > xen bug that makes all this fail.  The correct fix for that bug is to
> > patch the hypervisor, but they have not done so. Upstream xen has had
> > the fix for quite some time, but that doesn't change the fact that a lot
> > of xen guest usage these days is on EC2.  This is no different than
> > putting in a quirk to work around a firmware bug in common use.
> 
> I've done some testing and have results that indicate otherwise. The
> out-of-tree xen_write_cr4() patch is not needed as of 2.6.39. I tested
> 3.2.21 on a machine that has XSAVE capabilities:
> 
> [ec2-user@ip-10-160-18-80 ~]$ cpuid -1 -i | grep -i xsave/xstor
>       XSAVE/XSTOR states                      = true
>       OS-enabled XSAVE/XSTOR                  = false
> 
> on an older hypervisor build:
> 
> [ec2-user@ip-10-160-18-80 ~]$ cat /sys/hypervisor/version/major
> 3
> [ec2-user@ip-10-160-18-80 ~]$ cat /sys/hypervisor/version/minor
> 0
> 
> and it boots without a problem. This patch correctly detects that the
> hypervisor supports XSAVE by testing for OSXSAVE:
> 
> commit 947ccf9c3c30307b774af3666ee74fcd9f47f646
> Author:     Shan Haitao <haitao.shan@intel.com>
> AuthorDate: Tue Nov 9 11:43:36 2010 -0800
> Commit:     Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> CommitDate: Wed Apr 6 08:31:13 2011 -0400
> 
>     xen: Allow PV-OPS kernel to detect whether XSAVE is supported
>     
>     Xen fails to mask XSAVE from the cpuid feature, despite not historically
>     supporting guest use of XSAVE.  However, now that XSAVE support has been
>     added to Xen, we need to reliably detect its presence.
>     
>     The most reliable way to do this is to look at the OSXSAVE feature in
>     cpuid which is set iff the OS (Xen, in this case), has set
>     CR4.OSXSAVE.
> 
> Matt

Hey Matt,

Thank you for testing. CC-ing some of the Fedora folks so they are aware that they
can ditch the: fix_xen_guest_on_old_EC2.patch 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 11 11:48:20 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 2012 11: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 1TBOwo-0007DK-OV; Tue, 11 Sep 2012 11:48:06 +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 1TBOwn-0007DF-BG
	for xen-devel@lists.xen.org; Tue, 11 Sep 2012 11:48:05 +0000
Received: from [85.158.139.83:2736] by server-12.bemta-5.messagelabs.com id
	B2/43-18300-4F42F405; Tue, 11 Sep 2012 11:48:04 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1347364082!25304588!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDc0Mjk0Nw==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12742 invoked from network); 11 Sep 2012 11:48:04 -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; 11 Sep 2012 11:48:04 -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 q8BBluSY027799
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 11 Sep 2012 11:47:56 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
	q8BBlsEl002359
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 11 Sep 2012 11:47:55 GMT
Received: from abhmt105.oracle.com (abhmt105.oracle.com [141.146.116.57])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q8BBlsBb026127; Tue, 11 Sep 2012 06:47:54 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 11 Sep 2012 04:47:54 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id EEA1B402E4; Tue, 11 Sep 2012 07:37:15 -0400 (EDT)
Date: Tue, 11 Sep 2012 07:37:15 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Matt Wilson <msw@amazon.com>, jforbes@redhat.com, kernel-maint@redhat.com
Message-ID: <20120911113715.GA28221@phenom.dumpdata.com>
References: <1347018043-21252-1-git-send-email-stefan.bader@canonical.com>
	<504A05B00200007800099C7B@nat28.tlf.novell.com>
	<5049F4E9.9050306@canonical.com>
	<504A1A950200007800099D4C@nat28.tlf.novell.com>
	<20120907142251.GA20096@linuxtx.org>
	<504A32800200007800099E40@nat28.tlf.novell.com>
	<1347033622.2980.12.camel@fedora64.linuxtx.org>
	<20120911024047.GA7620@u002268147cd4502c336d.ant.amazon.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120911024047.GA7620@u002268147cd4502c336d.ant.amazon.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	"Justin M. Forbes" <jmforbes@linuxtx.org>,
	Stefan Bader <stefan.bader@canonical.com>,
	Jan Beulich <JBeulich@suse.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH/RFC] Fix xsave bug on older Xen hypervisors
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Sep 10, 2012 at 07:40:47PM -0700, Matt Wilson wrote:
> On Fri, Sep 07, 2012 at 11:00:22AM -0500, Justin M. Forbes wrote:
> > On Fri, 2012-09-07 at 16:44 +0100, Jan Beulich wrote:
> > > 
> > > All of this still doesn't provide evidence that a plain upstream
> > > kernel is actually having any problems in the first place. Further,
> > > if you say EC2 has a crippled hypervisor patch - is that patch
> > > available for looking at somewhere?
> > 
> > Yes, I can verify that a plain upstream kernel has problems in the first
> > place, which is why we are carrying a patch to simply disable xsave all
> > together in the pv guest.
> > EC2 is not carrying a patch to cripple the hypervisor, there was an old
> > xen bug that makes all this fail.  The correct fix for that bug is to
> > patch the hypervisor, but they have not done so. Upstream xen has had
> > the fix for quite some time, but that doesn't change the fact that a lot
> > of xen guest usage these days is on EC2.  This is no different than
> > putting in a quirk to work around a firmware bug in common use.
> 
> I've done some testing and have results that indicate otherwise. The
> out-of-tree xen_write_cr4() patch is not needed as of 2.6.39. I tested
> 3.2.21 on a machine that has XSAVE capabilities:
> 
> [ec2-user@ip-10-160-18-80 ~]$ cpuid -1 -i | grep -i xsave/xstor
>       XSAVE/XSTOR states                      = true
>       OS-enabled XSAVE/XSTOR                  = false
> 
> on an older hypervisor build:
> 
> [ec2-user@ip-10-160-18-80 ~]$ cat /sys/hypervisor/version/major
> 3
> [ec2-user@ip-10-160-18-80 ~]$ cat /sys/hypervisor/version/minor
> 0
> 
> and it boots without a problem. This patch correctly detects that the
> hypervisor supports XSAVE by testing for OSXSAVE:
> 
> commit 947ccf9c3c30307b774af3666ee74fcd9f47f646
> Author:     Shan Haitao <haitao.shan@intel.com>
> AuthorDate: Tue Nov 9 11:43:36 2010 -0800
> Commit:     Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> CommitDate: Wed Apr 6 08:31:13 2011 -0400
> 
>     xen: Allow PV-OPS kernel to detect whether XSAVE is supported
>     
>     Xen fails to mask XSAVE from the cpuid feature, despite not historically
>     supporting guest use of XSAVE.  However, now that XSAVE support has been
>     added to Xen, we need to reliably detect its presence.
>     
>     The most reliable way to do this is to look at the OSXSAVE feature in
>     cpuid which is set iff the OS (Xen, in this case), has set
>     CR4.OSXSAVE.
> 
> Matt

Hey Matt,

Thank you for testing. CC-ing some of the Fedora folks so they are aware that they
can ditch the: fix_xen_guest_on_old_EC2.patch 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 11 11:53:25 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 2012 11: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 1TBP1i-0007Li-GM; Tue, 11 Sep 2012 11:53:10 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1TBP1g-0007Lb-B2
	for xen-devel@lists.xen.org; Tue, 11 Sep 2012 11:53:08 +0000
Received: from [85.158.139.83:26700] by server-11.bemta-5.messagelabs.com id
	73/0A-24658-3262F405; Tue, 11 Sep 2012 11:53:07 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1347364386!25305950!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQwNzc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6733 invoked from network); 11 Sep 2012 11:53:06 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-4.tower-182.messagelabs.com with SMTP;
	11 Sep 2012 11:53:06 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 11 Sep 2012 12:53:06 +0100
Message-Id: <504F423E020000780009A91D@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 11 Sep 2012 12:53:02 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part5F6E4D0E.0__="
Subject: [Xen-devel] [PATCH] x86: use only a single branch for
 upcall-pending exit path checks
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
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.

--=__Part5F6E4D0E.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

This utilizes the fact that the two bytes of interest are adjacent to
one another and that the resulting 16-bit values of interest are within
a contiguous range of numbers.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/arch/x86/x86_32/entry.S
+++ b/xen/arch/x86/x86_32/entry.S
@@ -219,10 +219,10 @@ test_all_events:
         jnz  process_nmi
 test_guest_events:
         movl VCPU_vcpu_info(%ebx),%eax
-        testb $0xFF,VCPUINFO_upcall_mask(%eax)
-        jnz  restore_all_guest
-        testb $0xFF,VCPUINFO_upcall_pending(%eax)
-        jz   restore_all_guest
+        movzwl VCPUINFO_upcall_pending(%eax),%eax
+        decl %eax
+        cmpl $0xfe,%eax
+        ja   restore_all_guest
 /*process_guest_events:*/
         sti
         leal VCPU_trap_bounce(%ebx),%edx
--- a/xen/arch/x86/x86_64/compat/entry.S
+++ b/xen/arch/x86/x86_64/compat/entry.S
@@ -108,10 +108,10 @@ ENTRY(compat_test_all_events)
         jnz   compat_process_nmi
 compat_test_guest_events:
         movq  VCPU_vcpu_info(%rbx),%rax
-        testb $0xFF,COMPAT_VCPUINFO_upcall_mask(%rax)
-        jnz   compat_restore_all_guest
-        testb $0xFF,COMPAT_VCPUINFO_upcall_pending(%rax)
-        jz    compat_restore_all_guest
+        movzwl COMPAT_VCPUINFO_upcall_pending(%rax),%eax
+        decl  %eax
+        cmpl  $0xfe,%eax
+        ja    compat_restore_all_guest
 /*compat_process_guest_events:*/
         sti
         leaq  VCPU_trap_bounce(%rbx),%rdx
--- a/xen/arch/x86/x86_64/entry.S
+++ b/xen/arch/x86/x86_64/entry.S
@@ -199,8 +199,8 @@ test_all_events:
         movl  VCPU_processor(%rbx),%eax
         shl   $IRQSTAT_shift,%rax
         leaq  irq_stat(%rip),%rcx
-        testl $~0,(%rcx,%rax,1)
-        jnz   process_softirqs
+        cmpl  $0,(%rcx,%rax,1)
+        jne   process_softirqs
         testb $1,VCPU_mce_pending(%rbx)
         jnz   process_mce
 .Ltest_guest_nmi:
@@ -208,10 +208,10 @@ test_all_events:
         jnz   process_nmi
 test_guest_events:
         movq  VCPU_vcpu_info(%rbx),%rax
-        testb $0xFF,VCPUINFO_upcall_mask(%rax)
-        jnz   restore_all_guest
-        testb $0xFF,VCPUINFO_upcall_pending(%rax)
-        jz    restore_all_guest
+        movzwl VCPUINFO_upcall_pending(%rax),%eax
+        decl  %eax
+        cmpl  $0xfe,%eax
+        ja    restore_all_guest
 /*process_guest_events:*/
         sti
         leaq  VCPU_trap_bounce(%rbx),%rdx




--=__Part5F6E4D0E.0__=
Content-Type: text/plain; name="x86-upcall-pending.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="x86-upcall-pending.patch"

x86: use only a single branch for upcall-pending exit path checks=0A=0AThis=
 utilizes the fact that the two bytes of interest are adjacent to=0Aone =
another and that the resulting 16-bit values of interest are within=0Aa =
contiguous range of numbers.=0A=0ASigned-off-by: Jan Beulich <jbeulich@suse=
.com>=0A=0A--- a/xen/arch/x86/x86_32/entry.S=0A+++ b/xen/arch/x86/x86_32/en=
try.S=0A@@ -219,10 +219,10 @@ test_all_events:=0A         jnz  process_nmi=
=0A test_guest_events:=0A         movl VCPU_vcpu_info(%ebx),%eax=0A-       =
 testb $0xFF,VCPUINFO_upcall_mask(%eax)=0A-        jnz  restore_all_guest=
=0A-        testb $0xFF,VCPUINFO_upcall_pending(%eax)=0A-        jz   =
restore_all_guest=0A+        movzwl VCPUINFO_upcall_pending(%eax),%eax=0A+ =
       decl %eax=0A+        cmpl $0xfe,%eax=0A+        ja   restore_all_gue=
st=0A /*process_guest_events:*/=0A         sti=0A         leal VCPU_trap_bo=
unce(%ebx),%edx=0A--- a/xen/arch/x86/x86_64/compat/entry.S=0A+++ b/xen/arch=
/x86/x86_64/compat/entry.S=0A@@ -108,10 +108,10 @@ ENTRY(compat_test_all_ev=
ents)=0A         jnz   compat_process_nmi=0A compat_test_guest_events:=0A  =
       movq  VCPU_vcpu_info(%rbx),%rax=0A-        testb $0xFF,COMPAT_VCPUIN=
FO_upcall_mask(%rax)=0A-        jnz   compat_restore_all_guest=0A-        =
testb $0xFF,COMPAT_VCPUINFO_upcall_pending(%rax)=0A-        jz    =
compat_restore_all_guest=0A+        movzwl COMPAT_VCPUINFO_upcall_pending(%=
rax),%eax=0A+        decl  %eax=0A+        cmpl  $0xfe,%eax=0A+        ja  =
  compat_restore_all_guest=0A /*compat_process_guest_events:*/=0A         =
sti=0A         leaq  VCPU_trap_bounce(%rbx),%rdx=0A--- a/xen/arch/x86/x86_6=
4/entry.S=0A+++ b/xen/arch/x86/x86_64/entry.S=0A@@ -199,8 +199,8 @@ =
test_all_events:=0A         movl  VCPU_processor(%rbx),%eax=0A         shl =
  $IRQSTAT_shift,%rax=0A         leaq  irq_stat(%rip),%rcx=0A-        =
testl $~0,(%rcx,%rax,1)=0A-        jnz   process_softirqs=0A+        cmpl  =
$0,(%rcx,%rax,1)=0A+        jne   process_softirqs=0A         testb =
$1,VCPU_mce_pending(%rbx)=0A         jnz   process_mce=0A .Ltest_guest_nmi:=
=0A@@ -208,10 +208,10 @@ test_all_events:=0A         jnz   process_nmi=0A =
test_guest_events:=0A         movq  VCPU_vcpu_info(%rbx),%rax=0A-        =
testb $0xFF,VCPUINFO_upcall_mask(%rax)=0A-        jnz   restore_all_guest=
=0A-        testb $0xFF,VCPUINFO_upcall_pending(%rax)=0A-        jz    =
restore_all_guest=0A+        movzwl VCPUINFO_upcall_pending(%rax),%eax=0A+ =
       decl  %eax=0A+        cmpl  $0xfe,%eax=0A+        ja    restore_all_=
guest=0A /*process_guest_events:*/=0A         sti=0A         leaq  =
VCPU_trap_bounce(%rbx),%rdx=0A
--=__Part5F6E4D0E.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

--=__Part5F6E4D0E.0__=--


From xen-devel-bounces@lists.xen.org Tue Sep 11 11:53:25 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 2012 11: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 1TBP1i-0007Li-GM; Tue, 11 Sep 2012 11:53:10 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1TBP1g-0007Lb-B2
	for xen-devel@lists.xen.org; Tue, 11 Sep 2012 11:53:08 +0000
Received: from [85.158.139.83:26700] by server-11.bemta-5.messagelabs.com id
	73/0A-24658-3262F405; Tue, 11 Sep 2012 11:53:07 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1347364386!25305950!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQwNzc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6733 invoked from network); 11 Sep 2012 11:53:06 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-4.tower-182.messagelabs.com with SMTP;
	11 Sep 2012 11:53:06 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 11 Sep 2012 12:53:06 +0100
Message-Id: <504F423E020000780009A91D@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 11 Sep 2012 12:53:02 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part5F6E4D0E.0__="
Subject: [Xen-devel] [PATCH] x86: use only a single branch for
 upcall-pending exit path checks
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
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.

--=__Part5F6E4D0E.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

This utilizes the fact that the two bytes of interest are adjacent to
one another and that the resulting 16-bit values of interest are within
a contiguous range of numbers.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/arch/x86/x86_32/entry.S
+++ b/xen/arch/x86/x86_32/entry.S
@@ -219,10 +219,10 @@ test_all_events:
         jnz  process_nmi
 test_guest_events:
         movl VCPU_vcpu_info(%ebx),%eax
-        testb $0xFF,VCPUINFO_upcall_mask(%eax)
-        jnz  restore_all_guest
-        testb $0xFF,VCPUINFO_upcall_pending(%eax)
-        jz   restore_all_guest
+        movzwl VCPUINFO_upcall_pending(%eax),%eax
+        decl %eax
+        cmpl $0xfe,%eax
+        ja   restore_all_guest
 /*process_guest_events:*/
         sti
         leal VCPU_trap_bounce(%ebx),%edx
--- a/xen/arch/x86/x86_64/compat/entry.S
+++ b/xen/arch/x86/x86_64/compat/entry.S
@@ -108,10 +108,10 @@ ENTRY(compat_test_all_events)
         jnz   compat_process_nmi
 compat_test_guest_events:
         movq  VCPU_vcpu_info(%rbx),%rax
-        testb $0xFF,COMPAT_VCPUINFO_upcall_mask(%rax)
-        jnz   compat_restore_all_guest
-        testb $0xFF,COMPAT_VCPUINFO_upcall_pending(%rax)
-        jz    compat_restore_all_guest
+        movzwl COMPAT_VCPUINFO_upcall_pending(%rax),%eax
+        decl  %eax
+        cmpl  $0xfe,%eax
+        ja    compat_restore_all_guest
 /*compat_process_guest_events:*/
         sti
         leaq  VCPU_trap_bounce(%rbx),%rdx
--- a/xen/arch/x86/x86_64/entry.S
+++ b/xen/arch/x86/x86_64/entry.S
@@ -199,8 +199,8 @@ test_all_events:
         movl  VCPU_processor(%rbx),%eax
         shl   $IRQSTAT_shift,%rax
         leaq  irq_stat(%rip),%rcx
-        testl $~0,(%rcx,%rax,1)
-        jnz   process_softirqs
+        cmpl  $0,(%rcx,%rax,1)
+        jne   process_softirqs
         testb $1,VCPU_mce_pending(%rbx)
         jnz   process_mce
 .Ltest_guest_nmi:
@@ -208,10 +208,10 @@ test_all_events:
         jnz   process_nmi
 test_guest_events:
         movq  VCPU_vcpu_info(%rbx),%rax
-        testb $0xFF,VCPUINFO_upcall_mask(%rax)
-        jnz   restore_all_guest
-        testb $0xFF,VCPUINFO_upcall_pending(%rax)
-        jz    restore_all_guest
+        movzwl VCPUINFO_upcall_pending(%rax),%eax
+        decl  %eax
+        cmpl  $0xfe,%eax
+        ja    restore_all_guest
 /*process_guest_events:*/
         sti
         leaq  VCPU_trap_bounce(%rbx),%rdx




--=__Part5F6E4D0E.0__=
Content-Type: text/plain; name="x86-upcall-pending.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="x86-upcall-pending.patch"

x86: use only a single branch for upcall-pending exit path checks=0A=0AThis=
 utilizes the fact that the two bytes of interest are adjacent to=0Aone =
another and that the resulting 16-bit values of interest are within=0Aa =
contiguous range of numbers.=0A=0ASigned-off-by: Jan Beulich <jbeulich@suse=
.com>=0A=0A--- a/xen/arch/x86/x86_32/entry.S=0A+++ b/xen/arch/x86/x86_32/en=
try.S=0A@@ -219,10 +219,10 @@ test_all_events:=0A         jnz  process_nmi=
=0A test_guest_events:=0A         movl VCPU_vcpu_info(%ebx),%eax=0A-       =
 testb $0xFF,VCPUINFO_upcall_mask(%eax)=0A-        jnz  restore_all_guest=
=0A-        testb $0xFF,VCPUINFO_upcall_pending(%eax)=0A-        jz   =
restore_all_guest=0A+        movzwl VCPUINFO_upcall_pending(%eax),%eax=0A+ =
       decl %eax=0A+        cmpl $0xfe,%eax=0A+        ja   restore_all_gue=
st=0A /*process_guest_events:*/=0A         sti=0A         leal VCPU_trap_bo=
unce(%ebx),%edx=0A--- a/xen/arch/x86/x86_64/compat/entry.S=0A+++ b/xen/arch=
/x86/x86_64/compat/entry.S=0A@@ -108,10 +108,10 @@ ENTRY(compat_test_all_ev=
ents)=0A         jnz   compat_process_nmi=0A compat_test_guest_events:=0A  =
       movq  VCPU_vcpu_info(%rbx),%rax=0A-        testb $0xFF,COMPAT_VCPUIN=
FO_upcall_mask(%rax)=0A-        jnz   compat_restore_all_guest=0A-        =
testb $0xFF,COMPAT_VCPUINFO_upcall_pending(%rax)=0A-        jz    =
compat_restore_all_guest=0A+        movzwl COMPAT_VCPUINFO_upcall_pending(%=
rax),%eax=0A+        decl  %eax=0A+        cmpl  $0xfe,%eax=0A+        ja  =
  compat_restore_all_guest=0A /*compat_process_guest_events:*/=0A         =
sti=0A         leaq  VCPU_trap_bounce(%rbx),%rdx=0A--- a/xen/arch/x86/x86_6=
4/entry.S=0A+++ b/xen/arch/x86/x86_64/entry.S=0A@@ -199,8 +199,8 @@ =
test_all_events:=0A         movl  VCPU_processor(%rbx),%eax=0A         shl =
  $IRQSTAT_shift,%rax=0A         leaq  irq_stat(%rip),%rcx=0A-        =
testl $~0,(%rcx,%rax,1)=0A-        jnz   process_softirqs=0A+        cmpl  =
$0,(%rcx,%rax,1)=0A+        jne   process_softirqs=0A         testb =
$1,VCPU_mce_pending(%rbx)=0A         jnz   process_mce=0A .Ltest_guest_nmi:=
=0A@@ -208,10 +208,10 @@ test_all_events:=0A         jnz   process_nmi=0A =
test_guest_events:=0A         movq  VCPU_vcpu_info(%rbx),%rax=0A-        =
testb $0xFF,VCPUINFO_upcall_mask(%rax)=0A-        jnz   restore_all_guest=
=0A-        testb $0xFF,VCPUINFO_upcall_pending(%rax)=0A-        jz    =
restore_all_guest=0A+        movzwl VCPUINFO_upcall_pending(%rax),%eax=0A+ =
       decl  %eax=0A+        cmpl  $0xfe,%eax=0A+        ja    restore_all_=
guest=0A /*process_guest_events:*/=0A         sti=0A         leaq  =
VCPU_trap_bounce(%rbx),%rdx=0A
--=__Part5F6E4D0E.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

--=__Part5F6E4D0E.0__=--


From xen-devel-bounces@lists.xen.org Tue Sep 11 11:56:44 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 2012 11:56: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 1TBP4z-0007TJ-49; Tue, 11 Sep 2012 11:56:33 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <zhenzhong.duan@oracle.com>) id 1TBP4y-0007TB-4y
	for xen-devel@lists.xen.org; Tue, 11 Sep 2012 11:56:32 +0000
Received: from [85.158.143.99:14337] by server-1.bemta-4.messagelabs.com id
	22/4B-12504-FE62F405; Tue, 11 Sep 2012 11:56:31 +0000
X-Env-Sender: zhenzhong.duan@oracle.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1347364527!23321359!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzMyNjc3\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31082 invoked from network); 11 Sep 2012 11:55:29 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-10.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 11 Sep 2012 11:55:29 -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 q8BBtP3F017368
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 11 Sep 2012 11:55:25 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
	q8BBtOdo013236
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 11 Sep 2012 11:55:25 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
	q8BBtOgO030903; Tue, 11 Sep 2012 06:55:24 -0500
Received: from [192.168.1.100] (/123.151.32.77)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 11 Sep 2012 04:55:24 -0700
Message-ID: <504F26F0.20600@oracle.com>
Date: Tue, 11 Sep 2012 19:56:32 +0800
From: "zhenzhong.duan" <zhenzhong.duan@oracle.com>
Organization: oracle
User-Agent: Mozilla/5.0 (Windows NT 5.1;
	rv:12.0) Gecko/20120428 Thunderbird/12.0.1
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <504764270200007800098DE1@nat28.tlf.novell.com>
	<504A01790200007800099C52@nat28.tlf.novell.com>
	<504F1412020000780009A750@nat28.tlf.novell.com>
	<504F01D6.3050903@oracle.com>
	<504F23B2020000780009A79B@nat28.tlf.novell.com>
	<504F0C0C.6020804@oracle.com>
	<504F2DD8020000780009A85B@nat28.tlf.novell.com>
In-Reply-To: <504F2DD8020000780009A85B@nat28.tlf.novell.com>
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: dan.magenheimer@oracle.com, Ian Campbell <ian.campbell@citrix.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Ping: [PATCH 09/11,
	v2] tmem: reduce severity of log messages
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: zhenzhong.duan@oracle.com
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 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

Cgrkuo4gMjAxMi0wOS0xMSAxODoyNiwgSmFuIEJldWxpY2gg5YaZ6YGTOgo+Pj4+IE9uIDExLjA5
LjEyIGF0IDEyOjAxLCBEdWFuWmhlbnpob25nPHpoZW56aG9uZy5kdWFuQG9yYWNsZS5jb20+ICB3
cm90ZToKPj4gSmFuIEJldWxpY2ggd3JvdGU6Cj4+Pj4+PiBPbiAxMS4wOS4xMiBhdCAxMToxOCwg
RHVhblpoZW56aG9uZzx6aGVuemhvbmcuZHVhbkBvcmFjbGUuY29tPiAgd3JvdGU6Cj4+Pj4+Pgo+
Pj4+IERhbiBpcyBvZmZsaW5lIHJlY2VudGx5Lgo+Pj4+IFdoYXQgYWJvdXQgJ3ByaW50aygidG1l
bV9yZWxpbnF1aXNoX3BhZ2U6IGZhaWxpbmcgb3JkZXI9JWRcbiIsIG9yZGVyKScsCj4+Pj4gbW9y
ZSBsaWtlIGEgIGd1ZXN0IGxldmVsIG1zZy4KPj4+Pgo+Pj4gVGhhdCdzIGRlYmF0YWJsZSwgYnV0
IHRoZSBtZXNzYWdlIGlzIGVuYWJsZWQgZm9yIGRlYnVnIGJ1aWxkcwo+Pj4gb25seSBhbnl3YXku
IENvdWxkIGJlIG1ha2UgWEVOTE9HX0RFQlVHLCBidXQgdGhhdCB3b3VsZAo+Pj4gcmVxdWlyZSB5
ZXQgYW5vdGhlciBoZWxwZXIgaW4gdG1lbV94ZW4uaC4gSSdkIHdhbnQgdG8gbGVhdmUKPj4+IHRo
aXMgYWxvbmUgZm9yIHRoZSBtb21lbnQuCj4+IE9rLgo+PiB6ZHVhbgo+IElzIHRoYXQgYW4gYWNr
IG9uIHRoZSBwYXRjaCB0aGVuPwpIb3BlIERhbiBkb24ndCBoYXZlIG90aGVyIHN1Z2dlc3Rpb24u
CgpBY2tlZC1ieTogWmhlbnpob25nIER1YW4gPHpoZW56aG9uZy5kdWFuQG9yYWNsZS5jb20+Cgp6
ZHVhbgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVu
LWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwOi8vbGlzdHMu
eGVuLm9yZy94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xen.org Tue Sep 11 11:56:44 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 2012 11:56: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 1TBP4z-0007TJ-49; Tue, 11 Sep 2012 11:56:33 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <zhenzhong.duan@oracle.com>) id 1TBP4y-0007TB-4y
	for xen-devel@lists.xen.org; Tue, 11 Sep 2012 11:56:32 +0000
Received: from [85.158.143.99:14337] by server-1.bemta-4.messagelabs.com id
	22/4B-12504-FE62F405; Tue, 11 Sep 2012 11:56:31 +0000
X-Env-Sender: zhenzhong.duan@oracle.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1347364527!23321359!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzMyNjc3\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31082 invoked from network); 11 Sep 2012 11:55:29 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-10.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 11 Sep 2012 11:55:29 -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 q8BBtP3F017368
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 11 Sep 2012 11:55:25 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
	q8BBtOdo013236
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 11 Sep 2012 11:55:25 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
	q8BBtOgO030903; Tue, 11 Sep 2012 06:55:24 -0500
Received: from [192.168.1.100] (/123.151.32.77)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 11 Sep 2012 04:55:24 -0700
Message-ID: <504F26F0.20600@oracle.com>
Date: Tue, 11 Sep 2012 19:56:32 +0800
From: "zhenzhong.duan" <zhenzhong.duan@oracle.com>
Organization: oracle
User-Agent: Mozilla/5.0 (Windows NT 5.1;
	rv:12.0) Gecko/20120428 Thunderbird/12.0.1
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <504764270200007800098DE1@nat28.tlf.novell.com>
	<504A01790200007800099C52@nat28.tlf.novell.com>
	<504F1412020000780009A750@nat28.tlf.novell.com>
	<504F01D6.3050903@oracle.com>
	<504F23B2020000780009A79B@nat28.tlf.novell.com>
	<504F0C0C.6020804@oracle.com>
	<504F2DD8020000780009A85B@nat28.tlf.novell.com>
In-Reply-To: <504F2DD8020000780009A85B@nat28.tlf.novell.com>
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: dan.magenheimer@oracle.com, Ian Campbell <ian.campbell@citrix.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Ping: [PATCH 09/11,
	v2] tmem: reduce severity of log messages
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: zhenzhong.duan@oracle.com
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 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

Cgrkuo4gMjAxMi0wOS0xMSAxODoyNiwgSmFuIEJldWxpY2gg5YaZ6YGTOgo+Pj4+IE9uIDExLjA5
LjEyIGF0IDEyOjAxLCBEdWFuWmhlbnpob25nPHpoZW56aG9uZy5kdWFuQG9yYWNsZS5jb20+ICB3
cm90ZToKPj4gSmFuIEJldWxpY2ggd3JvdGU6Cj4+Pj4+PiBPbiAxMS4wOS4xMiBhdCAxMToxOCwg
RHVhblpoZW56aG9uZzx6aGVuemhvbmcuZHVhbkBvcmFjbGUuY29tPiAgd3JvdGU6Cj4+Pj4+Pgo+
Pj4+IERhbiBpcyBvZmZsaW5lIHJlY2VudGx5Lgo+Pj4+IFdoYXQgYWJvdXQgJ3ByaW50aygidG1l
bV9yZWxpbnF1aXNoX3BhZ2U6IGZhaWxpbmcgb3JkZXI9JWRcbiIsIG9yZGVyKScsCj4+Pj4gbW9y
ZSBsaWtlIGEgIGd1ZXN0IGxldmVsIG1zZy4KPj4+Pgo+Pj4gVGhhdCdzIGRlYmF0YWJsZSwgYnV0
IHRoZSBtZXNzYWdlIGlzIGVuYWJsZWQgZm9yIGRlYnVnIGJ1aWxkcwo+Pj4gb25seSBhbnl3YXku
IENvdWxkIGJlIG1ha2UgWEVOTE9HX0RFQlVHLCBidXQgdGhhdCB3b3VsZAo+Pj4gcmVxdWlyZSB5
ZXQgYW5vdGhlciBoZWxwZXIgaW4gdG1lbV94ZW4uaC4gSSdkIHdhbnQgdG8gbGVhdmUKPj4+IHRo
aXMgYWxvbmUgZm9yIHRoZSBtb21lbnQuCj4+IE9rLgo+PiB6ZHVhbgo+IElzIHRoYXQgYW4gYWNr
IG9uIHRoZSBwYXRjaCB0aGVuPwpIb3BlIERhbiBkb24ndCBoYXZlIG90aGVyIHN1Z2dlc3Rpb24u
CgpBY2tlZC1ieTogWmhlbnpob25nIER1YW4gPHpoZW56aG9uZy5kdWFuQG9yYWNsZS5jb20+Cgp6
ZHVhbgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVu
LWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwOi8vbGlzdHMu
eGVuLm9yZy94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xen.org Tue Sep 11 11:57:21 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 2012 11:57:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TBP5c-0007Xd-N7; Tue, 11 Sep 2012 11:57:12 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1TBP5b-0007XM-Kz
	for xen-devel@lists.xen.org; Tue, 11 Sep 2012 11:57:11 +0000
Received: from [85.158.143.35:4538] by server-3.bemta-4.messagelabs.com id
	93/20-08232-7172F405; Tue, 11 Sep 2012 11:57:11 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1347364139!6004210!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQwNzc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13747 invoked from network); 11 Sep 2012 11:49:05 -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;
	11 Sep 2012 11:49:05 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 11 Sep 2012 12:48:59 +0100
Message-Id: <504F4148020000780009A919@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 11 Sep 2012 12:48:56 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part6A5B7838.0__="
Subject: [Xen-devel] [PATCH] x86-64/EFI: allow chaining of config files
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
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.

--=__Part6A5B7838.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Namely when making use the CONFIG_XEN_COMPAT_* options in the legacy
Linux kernels, newer kernels may not be compatible with older
hypervisors, so trying to boot such a combination makes little sense.
Booting older kernels on newer hypervisors, however, has to always
work.

With the way xen.efi looks for its configuration file, allowing
individual configuration files to refer only to compatible kernels,
and referring from an older- to a newer-hypervisor one (the kernels
of which will, as said, necessarily be compatible with the older
hypervisor) allows to greatly reduce redundancy at least in
development environments where one frequently wants multiple
hypervisors and kernles to be installed in parallel.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/docs/misc/efi.markdown
+++ b/docs/misc/efi.markdown
@@ -75,6 +75,13 @@ Specifies an XSM module to load.
=20
 Specifies a CPU microcode blob to load.
=20
+###`chain=3D<filename>`
+
+Specifies an alternate configuration file to use in case the specified =
section
+(and in particular its `kernel=3D` setting) can't be found in the default =
(or
+specified) configuration file. This is only meaningful in the [global] =
section
+and really not meant to be used together with the `-cfg=3D` command line =
option.
+
 Filenames must be specified relative to the location of the EFI binary.
=20
 Extra options to be passed to Xen can also be specified on the command =
line,
--- a/xen/arch/x86/efi/boot.c
+++ b/xen/arch/x86/efi/boot.c
@@ -809,7 +809,26 @@ efi_start(EFI_HANDLE ImageHandle, EFI_SY
     else
         section.s =3D get_value(&cfg, "global", "default");
=20
-    name.s =3D get_value(&cfg, section.s, "kernel");
+    for ( ; ; )
+    {
+        name.s =3D get_value(&cfg, section.s, "kernel");
+        if ( name.s )
+            break;
+        name.s =3D get_value(&cfg, "global", "chain");
+        if ( !name.s )
+            break;
+        efi_bs->FreePages(cfg.addr, PFN_UP(cfg.size));
+        cfg.addr =3D 0;
+        if ( !read_file(dir_handle, s2w(&name), &cfg) )
+        {
+            PrintStr(L"Chained configuration file '");
+            PrintStr(name.w);
+            efi_bs->FreePool(name.w);
+            blexit(L"'not found\r\n");
+        }
+        pre_parse(&cfg);
+        efi_bs->FreePool(name.w);
+    }
     if ( !name.s )
         blexit(L"No Dom0 kernel image specified\r\n");
     split_value(name.s);




--=__Part6A5B7838.0__=
Content-Type: text/plain; name="x86-efi-chain-cfg.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="x86-efi-chain-cfg.patch"

x86-64/EFI: allow chaining of config files=0A=0ANamely when making use the =
CONFIG_XEN_COMPAT_* options in the legacy=0ALinux kernels, newer kernels =
may not be compatible with older=0Ahypervisors, so trying to boot such a =
combination makes little sense.=0ABooting older kernels on newer hypervisor=
s, however, has to always=0Awork.=0A=0AWith the way xen.efi looks for its =
configuration file, allowing=0Aindividual configuration files to refer =
only to compatible kernels,=0Aand referring from an older- to a newer-hyper=
visor one (the kernels=0Aof which will, as said, necessarily be compatible =
with the older=0Ahypervisor) allows to greatly reduce redundancy at least =
in=0Adevelopment environments where one frequently wants multiple=0Ahypervi=
sors and kernles to be installed in parallel.=0A=0ASigned-off-by: Jan =
Beulich <jbeulich@suse.com>=0A=0A--- a/docs/misc/efi.markdown=0A+++ =
b/docs/misc/efi.markdown=0A@@ -75,6 +75,13 @@ Specifies an XSM module to =
load.=0A =0A Specifies a CPU microcode blob to load.=0A =0A+###`chain=3D<fi=
lename>`=0A+=0A+Specifies an alternate configuration file to use in case =
the specified section=0A+(and in particular its `kernel=3D` setting) can't =
be found in the default (or=0A+specified) configuration file. This is only =
meaningful in the [global] section=0A+and really not meant to be used =
together with the `-cfg=3D` command line option.=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--- =
a/xen/arch/x86/efi/boot.c=0A+++ b/xen/arch/x86/efi/boot.c=0A@@ -809,7 =
+809,26 @@ efi_start(EFI_HANDLE ImageHandle, EFI_SY=0A     else=0A         =
section.s =3D get_value(&cfg, "global", "default");=0A =0A-    name.s =3D =
get_value(&cfg, section.s, "kernel");=0A+    for ( ; ; )=0A+    {=0A+      =
  name.s =3D get_value(&cfg, section.s, "kernel");=0A+        if ( name.s =
)=0A+            break;=0A+        name.s =3D get_value(&cfg, "global", =
"chain");=0A+        if ( !name.s )=0A+            break;=0A+        =
efi_bs->FreePages(cfg.addr, PFN_UP(cfg.size));=0A+        cfg.addr =3D =
0;=0A+        if ( !read_file(dir_handle, s2w(&name), &cfg) )=0A+        =
{=0A+            PrintStr(L"Chained configuration file '");=0A+            =
PrintStr(name.w);=0A+            efi_bs->FreePool(name.w);=0A+            =
blexit(L"'not found\r\n");=0A+        }=0A+        pre_parse(&cfg);=0A+    =
    efi_bs->FreePool(name.w);=0A+    }=0A     if ( !name.s )=0A         =
blexit(L"No Dom0 kernel image specified\r\n");=0A     split_value(name.s);=
=0A
--=__Part6A5B7838.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

--=__Part6A5B7838.0__=--


From xen-devel-bounces@lists.xen.org Tue Sep 11 11:57:21 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 2012 11:57:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TBP5c-0007Xd-N7; Tue, 11 Sep 2012 11:57:12 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1TBP5b-0007XM-Kz
	for xen-devel@lists.xen.org; Tue, 11 Sep 2012 11:57:11 +0000
Received: from [85.158.143.35:4538] by server-3.bemta-4.messagelabs.com id
	93/20-08232-7172F405; Tue, 11 Sep 2012 11:57:11 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1347364139!6004210!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQwNzc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13747 invoked from network); 11 Sep 2012 11:49:05 -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;
	11 Sep 2012 11:49:05 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 11 Sep 2012 12:48:59 +0100
Message-Id: <504F4148020000780009A919@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 11 Sep 2012 12:48:56 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part6A5B7838.0__="
Subject: [Xen-devel] [PATCH] x86-64/EFI: allow chaining of config files
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
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.

--=__Part6A5B7838.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Namely when making use the CONFIG_XEN_COMPAT_* options in the legacy
Linux kernels, newer kernels may not be compatible with older
hypervisors, so trying to boot such a combination makes little sense.
Booting older kernels on newer hypervisors, however, has to always
work.

With the way xen.efi looks for its configuration file, allowing
individual configuration files to refer only to compatible kernels,
and referring from an older- to a newer-hypervisor one (the kernels
of which will, as said, necessarily be compatible with the older
hypervisor) allows to greatly reduce redundancy at least in
development environments where one frequently wants multiple
hypervisors and kernles to be installed in parallel.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/docs/misc/efi.markdown
+++ b/docs/misc/efi.markdown
@@ -75,6 +75,13 @@ Specifies an XSM module to load.
=20
 Specifies a CPU microcode blob to load.
=20
+###`chain=3D<filename>`
+
+Specifies an alternate configuration file to use in case the specified =
section
+(and in particular its `kernel=3D` setting) can't be found in the default =
(or
+specified) configuration file. This is only meaningful in the [global] =
section
+and really not meant to be used together with the `-cfg=3D` command line =
option.
+
 Filenames must be specified relative to the location of the EFI binary.
=20
 Extra options to be passed to Xen can also be specified on the command =
line,
--- a/xen/arch/x86/efi/boot.c
+++ b/xen/arch/x86/efi/boot.c
@@ -809,7 +809,26 @@ efi_start(EFI_HANDLE ImageHandle, EFI_SY
     else
         section.s =3D get_value(&cfg, "global", "default");
=20
-    name.s =3D get_value(&cfg, section.s, "kernel");
+    for ( ; ; )
+    {
+        name.s =3D get_value(&cfg, section.s, "kernel");
+        if ( name.s )
+            break;
+        name.s =3D get_value(&cfg, "global", "chain");
+        if ( !name.s )
+            break;
+        efi_bs->FreePages(cfg.addr, PFN_UP(cfg.size));
+        cfg.addr =3D 0;
+        if ( !read_file(dir_handle, s2w(&name), &cfg) )
+        {
+            PrintStr(L"Chained configuration file '");
+            PrintStr(name.w);
+            efi_bs->FreePool(name.w);
+            blexit(L"'not found\r\n");
+        }
+        pre_parse(&cfg);
+        efi_bs->FreePool(name.w);
+    }
     if ( !name.s )
         blexit(L"No Dom0 kernel image specified\r\n");
     split_value(name.s);




--=__Part6A5B7838.0__=
Content-Type: text/plain; name="x86-efi-chain-cfg.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="x86-efi-chain-cfg.patch"

x86-64/EFI: allow chaining of config files=0A=0ANamely when making use the =
CONFIG_XEN_COMPAT_* options in the legacy=0ALinux kernels, newer kernels =
may not be compatible with older=0Ahypervisors, so trying to boot such a =
combination makes little sense.=0ABooting older kernels on newer hypervisor=
s, however, has to always=0Awork.=0A=0AWith the way xen.efi looks for its =
configuration file, allowing=0Aindividual configuration files to refer =
only to compatible kernels,=0Aand referring from an older- to a newer-hyper=
visor one (the kernels=0Aof which will, as said, necessarily be compatible =
with the older=0Ahypervisor) allows to greatly reduce redundancy at least =
in=0Adevelopment environments where one frequently wants multiple=0Ahypervi=
sors and kernles to be installed in parallel.=0A=0ASigned-off-by: Jan =
Beulich <jbeulich@suse.com>=0A=0A--- a/docs/misc/efi.markdown=0A+++ =
b/docs/misc/efi.markdown=0A@@ -75,6 +75,13 @@ Specifies an XSM module to =
load.=0A =0A Specifies a CPU microcode blob to load.=0A =0A+###`chain=3D<fi=
lename>`=0A+=0A+Specifies an alternate configuration file to use in case =
the specified section=0A+(and in particular its `kernel=3D` setting) can't =
be found in the default (or=0A+specified) configuration file. This is only =
meaningful in the [global] section=0A+and really not meant to be used =
together with the `-cfg=3D` command line option.=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--- =
a/xen/arch/x86/efi/boot.c=0A+++ b/xen/arch/x86/efi/boot.c=0A@@ -809,7 =
+809,26 @@ efi_start(EFI_HANDLE ImageHandle, EFI_SY=0A     else=0A         =
section.s =3D get_value(&cfg, "global", "default");=0A =0A-    name.s =3D =
get_value(&cfg, section.s, "kernel");=0A+    for ( ; ; )=0A+    {=0A+      =
  name.s =3D get_value(&cfg, section.s, "kernel");=0A+        if ( name.s =
)=0A+            break;=0A+        name.s =3D get_value(&cfg, "global", =
"chain");=0A+        if ( !name.s )=0A+            break;=0A+        =
efi_bs->FreePages(cfg.addr, PFN_UP(cfg.size));=0A+        cfg.addr =3D =
0;=0A+        if ( !read_file(dir_handle, s2w(&name), &cfg) )=0A+        =
{=0A+            PrintStr(L"Chained configuration file '");=0A+            =
PrintStr(name.w);=0A+            efi_bs->FreePool(name.w);=0A+            =
blexit(L"'not found\r\n");=0A+        }=0A+        pre_parse(&cfg);=0A+    =
    efi_bs->FreePool(name.w);=0A+    }=0A     if ( !name.s )=0A         =
blexit(L"No Dom0 kernel image specified\r\n");=0A     split_value(name.s);=
=0A
--=__Part6A5B7838.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

--=__Part6A5B7838.0__=--


From xen-devel-bounces@lists.xen.org Tue Sep 11 12:01:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 2012 12: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 1TBP9K-0007tF-2C; Tue, 11 Sep 2012 12:01:02 +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 1TBP9I-0007si-CX
	for xen-devel@lists.xen.org; Tue, 11 Sep 2012 12:01:00 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1347364685!9125756!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQwNzc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29213 invoked from network); 11 Sep 2012 11:58:06 -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;
	11 Sep 2012 11:58:06 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 11 Sep 2012 12:58:04 +0100
Message-Id: <504F4368020000780009A927@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 11 Sep 2012 12:58:00 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part08391A58.0__="
Subject: [Xen-devel] [PATCH] gnttab: cleanup of number-of-active-frames
 calculations
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<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.

--=__Part08391A58.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

max_nr_active_grant_frames() is merly is special case of
num_act_frames_from_sha_frames(), so there's no need to have a special
case implementation for it.

Further, some of the related definitions (including the "struct
active_grant_entry" definition itself) can (and hence should) really be
private to grant_table.c.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/common/grant_table.c
+++ b/xen/common/grant_table.c
@@ -127,10 +127,45 @@ shared_entry_header(struct grant_table *
     else
         return &shared_entry_v2(t, ref).hdr;
 }
+
+/* Active grant entry - used for shadowing GTF_permit_access grants. */
+struct active_grant_entry {
+    u32           pin;    /* Reference count information.             */
+    domid_t       domid;  /* Domain being granted access.             */
+    struct domain *trans_domain;
+    uint32_t      trans_gref;
+    unsigned long frame;  /* Frame being granted.                     */
+    unsigned long gfn;    /* Guest's idea of the frame being granted. */
+    unsigned      is_sub_page:1; /* True if this is a sub-page grant. */
+    unsigned      start:15; /* For sub-page grants, the start offset
+                               in the page.                           */
+    unsigned      length:16; /* For sub-page grants, the length of the
+                                grant.                                */
+};
+
 #define ACGNT_PER_PAGE (PAGE_SIZE / sizeof(struct active_grant_entry))
 #define active_entry(t, e) \
     ((t)->active[(e)/ACGNT_PER_PAGE][(e)%ACGNT_PER_PAGE])
=20
+static inline unsigned int
+num_act_frames_from_sha_frames(const unsigned int num)
+{
+    /* How many frames are needed for the active grant table,
+     * given the size of the shared grant table? */
+    unsigned int sha_per_page =3D PAGE_SIZE / sizeof(grant_entry_v1_t);
+    unsigned int num_sha_entries =3D num * sha_per_page;
+    return (num_sha_entries + (ACGNT_PER_PAGE - 1)) / ACGNT_PER_PAGE;
+}
+
+#define max_nr_active_grant_frames \
+    num_act_frames_from_sha_frames(max_nr_grant_frames)
+
+static inline unsigned int
+nr_active_grant_frames(struct grant_table *gt)
+{
+    return num_act_frames_from_sha_frames(nr_grant_frames(gt));
+}
+
 /* Check if the page has been paged out, or needs unsharing.=20
    If rc =3D=3D GNTST_okay, *page contains the page struct with a ref =
taken.
    Caller must do put_page(*page).
@@ -2542,13 +2577,6 @@ do_grant_table_op(
 #include "compat/grant_table.c"
 #endif
=20
-static unsigned int max_nr_active_grant_frames(void)
-{
-    return (((max_nr_grant_frames * (PAGE_SIZE / sizeof(grant_entry_v1_t))=
) +=20
-                    ((PAGE_SIZE / sizeof(struct active_grant_entry))-1))=
=20
-                   / (PAGE_SIZE / sizeof(struct active_grant_entry)));
-}
-
 int=20
 grant_table_create(
     struct domain *d)
@@ -2565,7 +2593,7 @@ grant_table_create(
=20
     /* Active grant table. */
     if ( (t->active =3D xzalloc_array(struct active_grant_entry *,
-                                    max_nr_active_grant_frames())) =3D=3D =
NULL )
+                                    max_nr_active_grant_frames)) =3D=3D =
NULL )
         goto no_mem_1;
     for ( i =3D 0;
           i < num_act_frames_from_sha_frames(INITIAL_NR_GRANT_FRAMES); =
i++ )
--- a/xen/include/xen/grant_table.h
+++ b/xen/include/xen/grant_table.h
@@ -28,21 +28,6 @@
 #include <asm/page.h>
 #include <asm/grant_table.h>
=20
-/* Active grant entry - used for shadowing GTF_permit_access grants. */
-struct active_grant_entry {
-    u32           pin;    /* Reference count information.             */
-    domid_t       domid;  /* Domain being granted access.             */
-    struct domain *trans_domain;
-    uint32_t      trans_gref;
-    unsigned long frame;  /* Frame being granted.                     */
-    unsigned long gfn;    /* Guest's idea of the frame being granted. */
-    unsigned      is_sub_page:1; /* True if this is a sub-page grant. */
-    unsigned      start:15; /* For sub-page grants, the start offset
-                               in the page.                           */
-    unsigned      length:16; /* For sub-page grants, the length of the
-                                grant.                                */
-};
-
  /* Count of writable host-CPU mappings. */
 #define GNTPIN_hstw_shift    (0)
 #define GNTPIN_hstw_inc      (1 << GNTPIN_hstw_shift)
@@ -147,23 +132,4 @@ static inline unsigned int grant_to_stat
         GRANT_STATUS_PER_PAGE;
 }
=20
-static inline unsigned int
-num_act_frames_from_sha_frames(const unsigned int num)
-{
-    /* How many frames are needed for the active grant table,
-     * given the size of the shared grant table? */
-    unsigned act_per_page =3D PAGE_SIZE / sizeof(struct active_grant_entry=
);
-    unsigned sha_per_page =3D PAGE_SIZE / sizeof(grant_entry_v1_t);
-    unsigned num_sha_entries =3D num * sha_per_page;
-    unsigned num_act_frames =3D
-        (num_sha_entries + (act_per_page-1)) / act_per_page;
-    return num_act_frames;
-}
-
-static inline unsigned int
-nr_active_grant_frames(struct grant_table *gt)
-{
-    return num_act_frames_from_sha_frames(nr_grant_frames(gt));
-}
-
 #endif /* __XEN_GRANT_TABLE_H__ */



--=__Part08391A58.0__=
Content-Type: text/plain; name="gnttab-max-nr-active.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="gnttab-max-nr-active.patch"

gnttab: cleanup of number-of-active-frames calculations=0A=0Amax_nr_active_=
grant_frames() is merly is special case of=0Anum_act_frames_from_sha_frames=
(), so there's no need to have a special=0Acase implementation for =
it.=0A=0AFurther, some of the related definitions (including the "struct=0A=
active_grant_entry" definition itself) can (and hence should) really =
be=0Aprivate to grant_table.c.=0A=0ASigned-off-by: Jan Beulich <jbeulich@su=
se.com>=0A=0A--- a/xen/common/grant_table.c=0A+++ b/xen/common/grant_table.=
c=0A@@ -127,10 +127,45 @@ shared_entry_header(struct grant_table *=0A     =
else=0A         return &shared_entry_v2(t, ref).hdr;=0A }=0A+=0A+/* Active =
grant entry - used for shadowing GTF_permit_access grants. */=0A+struct =
active_grant_entry {=0A+    u32           pin;    /* Reference count =
information.             */=0A+    domid_t       domid;  /* Domain being =
granted access.             */=0A+    struct domain *trans_domain;=0A+    =
uint32_t      trans_gref;=0A+    unsigned long frame;  /* Frame being =
granted.                     */=0A+    unsigned long gfn;    /* Guest's =
idea of the frame being granted. */=0A+    unsigned      is_sub_page:1; /* =
True if this is a sub-page grant. */=0A+    unsigned      start:15; /* For =
sub-page grants, the start offset=0A+                               in the =
page.                           */=0A+    unsigned      length:16; /* For =
sub-page grants, the length of the=0A+                                =
grant.                                */=0A+};=0A+=0A #define ACGNT_PER_PAG=
E (PAGE_SIZE / sizeof(struct active_grant_entry))=0A #define active_entry(t=
, e) \=0A     ((t)->active[(e)/ACGNT_PER_PAGE][(e)%ACGNT_PER_PAGE])=0A =
=0A+static inline unsigned int=0A+num_act_frames_from_sha_frames(const =
unsigned int num)=0A+{=0A+    /* How many frames are needed for the active =
grant table,=0A+     * given the size of the shared grant table? */=0A+    =
unsigned int sha_per_page =3D PAGE_SIZE / sizeof(grant_entry_v1_t);=0A+    =
unsigned int num_sha_entries =3D num * sha_per_page;=0A+    return =
(num_sha_entries + (ACGNT_PER_PAGE - 1)) / ACGNT_PER_PAGE;=0A+}=0A+=0A+#def=
ine max_nr_active_grant_frames \=0A+    num_act_frames_from_sha_frames(max_=
nr_grant_frames)=0A+=0A+static inline unsigned int=0A+nr_active_grant_frame=
s(struct grant_table *gt)=0A+{=0A+    return num_act_frames_from_sha_frames=
(nr_grant_frames(gt));=0A+}=0A+=0A /* Check if the page has been paged =
out, or needs unsharing. =0A    If rc =3D=3D GNTST_okay, *page contains =
the page struct with a ref taken.=0A    Caller must do put_page(*page).=0A@=
@ -2542,13 +2577,6 @@ do_grant_table_op(=0A #include "compat/grant_table.c"=
=0A #endif=0A =0A-static unsigned int max_nr_active_grant_frames(void)=0A-{=
=0A-    return (((max_nr_grant_frames * (PAGE_SIZE / sizeof(grant_entry_v1_=
t))) + =0A-                    ((PAGE_SIZE / sizeof(struct active_grant_ent=
ry))-1)) =0A-                   / (PAGE_SIZE / sizeof(struct active_grant_e=
ntry)));=0A-}=0A-=0A int =0A grant_table_create(=0A     struct domain =
*d)=0A@@ -2565,7 +2593,7 @@ grant_table_create(=0A =0A     /* Active grant =
table. */=0A     if ( (t->active =3D xzalloc_array(struct active_grant_entr=
y *,=0A-                                    max_nr_active_grant_frames())) =
=3D=3D NULL )=0A+                                    max_nr_active_grant_fr=
ames)) =3D=3D NULL )=0A         goto no_mem_1;=0A     for ( i =3D 0;=0A    =
       i < num_act_frames_from_sha_frames(INITIAL_NR_GRANT_FRAMES); i++ =
)=0A--- a/xen/include/xen/grant_table.h=0A+++ b/xen/include/xen/grant_table=
.h=0A@@ -28,21 +28,6 @@=0A #include <asm/page.h>=0A #include <asm/grant_tab=
le.h>=0A =0A-/* Active grant entry - used for shadowing GTF_permit_access =
grants. */=0A-struct active_grant_entry {=0A-    u32           pin;    /* =
Reference count information.             */=0A-    domid_t       domid;  =
/* Domain being granted access.             */=0A-    struct domain =
*trans_domain;=0A-    uint32_t      trans_gref;=0A-    unsigned long =
frame;  /* Frame being granted.                     */=0A-    unsigned =
long gfn;    /* Guest's idea of the frame being granted. */=0A-    =
unsigned      is_sub_page:1; /* True if this is a sub-page grant. */=0A-   =
 unsigned      start:15; /* For sub-page grants, the start offset=0A-      =
                         in the page.                           */=0A-    =
unsigned      length:16; /* For sub-page grants, the length of the=0A-     =
                           grant.                                =
*/=0A-};=0A-=0A  /* Count of writable host-CPU mappings. */=0A #define =
GNTPIN_hstw_shift    (0)=0A #define GNTPIN_hstw_inc      (1 << GNTPIN_hstw_=
shift)=0A@@ -147,23 +132,4 @@ static inline unsigned int grant_to_stat=0A  =
       GRANT_STATUS_PER_PAGE;=0A }=0A =0A-static inline unsigned int=0A-num=
_act_frames_from_sha_frames(const unsigned int num)=0A-{=0A-    /* How =
many frames are needed for the active grant table,=0A-     * given the =
size of the shared grant table? */=0A-    unsigned act_per_page =3D =
PAGE_SIZE / sizeof(struct active_grant_entry);=0A-    unsigned sha_per_page=
 =3D PAGE_SIZE / sizeof(grant_entry_v1_t);=0A-    unsigned num_sha_entries =
=3D num * sha_per_page;=0A-    unsigned num_act_frames =3D=0A-        =
(num_sha_entries + (act_per_page-1)) / act_per_page;=0A-    return =
num_act_frames;=0A-}=0A-=0A-static inline unsigned int=0A-nr_active_grant_f=
rames(struct grant_table *gt)=0A-{=0A-    return num_act_frames_from_sha_fr=
ames(nr_grant_frames(gt));=0A-}=0A-=0A #endif /* __XEN_GRANT_TABLE_H__ =
*/=0A
--=__Part08391A58.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

--=__Part08391A58.0__=--


From xen-devel-bounces@lists.xen.org Tue Sep 11 12:01:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 2012 12: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 1TBP9K-0007tF-2C; Tue, 11 Sep 2012 12:01:02 +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 1TBP9I-0007si-CX
	for xen-devel@lists.xen.org; Tue, 11 Sep 2012 12:01:00 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1347364685!9125756!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQwNzc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29213 invoked from network); 11 Sep 2012 11:58:06 -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;
	11 Sep 2012 11:58:06 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 11 Sep 2012 12:58:04 +0100
Message-Id: <504F4368020000780009A927@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 11 Sep 2012 12:58:00 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part08391A58.0__="
Subject: [Xen-devel] [PATCH] gnttab: cleanup of number-of-active-frames
 calculations
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<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.

--=__Part08391A58.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

max_nr_active_grant_frames() is merly is special case of
num_act_frames_from_sha_frames(), so there's no need to have a special
case implementation for it.

Further, some of the related definitions (including the "struct
active_grant_entry" definition itself) can (and hence should) really be
private to grant_table.c.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/common/grant_table.c
+++ b/xen/common/grant_table.c
@@ -127,10 +127,45 @@ shared_entry_header(struct grant_table *
     else
         return &shared_entry_v2(t, ref).hdr;
 }
+
+/* Active grant entry - used for shadowing GTF_permit_access grants. */
+struct active_grant_entry {
+    u32           pin;    /* Reference count information.             */
+    domid_t       domid;  /* Domain being granted access.             */
+    struct domain *trans_domain;
+    uint32_t      trans_gref;
+    unsigned long frame;  /* Frame being granted.                     */
+    unsigned long gfn;    /* Guest's idea of the frame being granted. */
+    unsigned      is_sub_page:1; /* True if this is a sub-page grant. */
+    unsigned      start:15; /* For sub-page grants, the start offset
+                               in the page.                           */
+    unsigned      length:16; /* For sub-page grants, the length of the
+                                grant.                                */
+};
+
 #define ACGNT_PER_PAGE (PAGE_SIZE / sizeof(struct active_grant_entry))
 #define active_entry(t, e) \
     ((t)->active[(e)/ACGNT_PER_PAGE][(e)%ACGNT_PER_PAGE])
=20
+static inline unsigned int
+num_act_frames_from_sha_frames(const unsigned int num)
+{
+    /* How many frames are needed for the active grant table,
+     * given the size of the shared grant table? */
+    unsigned int sha_per_page =3D PAGE_SIZE / sizeof(grant_entry_v1_t);
+    unsigned int num_sha_entries =3D num * sha_per_page;
+    return (num_sha_entries + (ACGNT_PER_PAGE - 1)) / ACGNT_PER_PAGE;
+}
+
+#define max_nr_active_grant_frames \
+    num_act_frames_from_sha_frames(max_nr_grant_frames)
+
+static inline unsigned int
+nr_active_grant_frames(struct grant_table *gt)
+{
+    return num_act_frames_from_sha_frames(nr_grant_frames(gt));
+}
+
 /* Check if the page has been paged out, or needs unsharing.=20
    If rc =3D=3D GNTST_okay, *page contains the page struct with a ref =
taken.
    Caller must do put_page(*page).
@@ -2542,13 +2577,6 @@ do_grant_table_op(
 #include "compat/grant_table.c"
 #endif
=20
-static unsigned int max_nr_active_grant_frames(void)
-{
-    return (((max_nr_grant_frames * (PAGE_SIZE / sizeof(grant_entry_v1_t))=
) +=20
-                    ((PAGE_SIZE / sizeof(struct active_grant_entry))-1))=
=20
-                   / (PAGE_SIZE / sizeof(struct active_grant_entry)));
-}
-
 int=20
 grant_table_create(
     struct domain *d)
@@ -2565,7 +2593,7 @@ grant_table_create(
=20
     /* Active grant table. */
     if ( (t->active =3D xzalloc_array(struct active_grant_entry *,
-                                    max_nr_active_grant_frames())) =3D=3D =
NULL )
+                                    max_nr_active_grant_frames)) =3D=3D =
NULL )
         goto no_mem_1;
     for ( i =3D 0;
           i < num_act_frames_from_sha_frames(INITIAL_NR_GRANT_FRAMES); =
i++ )
--- a/xen/include/xen/grant_table.h
+++ b/xen/include/xen/grant_table.h
@@ -28,21 +28,6 @@
 #include <asm/page.h>
 #include <asm/grant_table.h>
=20
-/* Active grant entry - used for shadowing GTF_permit_access grants. */
-struct active_grant_entry {
-    u32           pin;    /* Reference count information.             */
-    domid_t       domid;  /* Domain being granted access.             */
-    struct domain *trans_domain;
-    uint32_t      trans_gref;
-    unsigned long frame;  /* Frame being granted.                     */
-    unsigned long gfn;    /* Guest's idea of the frame being granted. */
-    unsigned      is_sub_page:1; /* True if this is a sub-page grant. */
-    unsigned      start:15; /* For sub-page grants, the start offset
-                               in the page.                           */
-    unsigned      length:16; /* For sub-page grants, the length of the
-                                grant.                                */
-};
-
  /* Count of writable host-CPU mappings. */
 #define GNTPIN_hstw_shift    (0)
 #define GNTPIN_hstw_inc      (1 << GNTPIN_hstw_shift)
@@ -147,23 +132,4 @@ static inline unsigned int grant_to_stat
         GRANT_STATUS_PER_PAGE;
 }
=20
-static inline unsigned int
-num_act_frames_from_sha_frames(const unsigned int num)
-{
-    /* How many frames are needed for the active grant table,
-     * given the size of the shared grant table? */
-    unsigned act_per_page =3D PAGE_SIZE / sizeof(struct active_grant_entry=
);
-    unsigned sha_per_page =3D PAGE_SIZE / sizeof(grant_entry_v1_t);
-    unsigned num_sha_entries =3D num * sha_per_page;
-    unsigned num_act_frames =3D
-        (num_sha_entries + (act_per_page-1)) / act_per_page;
-    return num_act_frames;
-}
-
-static inline unsigned int
-nr_active_grant_frames(struct grant_table *gt)
-{
-    return num_act_frames_from_sha_frames(nr_grant_frames(gt));
-}
-
 #endif /* __XEN_GRANT_TABLE_H__ */



--=__Part08391A58.0__=
Content-Type: text/plain; name="gnttab-max-nr-active.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="gnttab-max-nr-active.patch"

gnttab: cleanup of number-of-active-frames calculations=0A=0Amax_nr_active_=
grant_frames() is merly is special case of=0Anum_act_frames_from_sha_frames=
(), so there's no need to have a special=0Acase implementation for =
it.=0A=0AFurther, some of the related definitions (including the "struct=0A=
active_grant_entry" definition itself) can (and hence should) really =
be=0Aprivate to grant_table.c.=0A=0ASigned-off-by: Jan Beulich <jbeulich@su=
se.com>=0A=0A--- a/xen/common/grant_table.c=0A+++ b/xen/common/grant_table.=
c=0A@@ -127,10 +127,45 @@ shared_entry_header(struct grant_table *=0A     =
else=0A         return &shared_entry_v2(t, ref).hdr;=0A }=0A+=0A+/* Active =
grant entry - used for shadowing GTF_permit_access grants. */=0A+struct =
active_grant_entry {=0A+    u32           pin;    /* Reference count =
information.             */=0A+    domid_t       domid;  /* Domain being =
granted access.             */=0A+    struct domain *trans_domain;=0A+    =
uint32_t      trans_gref;=0A+    unsigned long frame;  /* Frame being =
granted.                     */=0A+    unsigned long gfn;    /* Guest's =
idea of the frame being granted. */=0A+    unsigned      is_sub_page:1; /* =
True if this is a sub-page grant. */=0A+    unsigned      start:15; /* For =
sub-page grants, the start offset=0A+                               in the =
page.                           */=0A+    unsigned      length:16; /* For =
sub-page grants, the length of the=0A+                                =
grant.                                */=0A+};=0A+=0A #define ACGNT_PER_PAG=
E (PAGE_SIZE / sizeof(struct active_grant_entry))=0A #define active_entry(t=
, e) \=0A     ((t)->active[(e)/ACGNT_PER_PAGE][(e)%ACGNT_PER_PAGE])=0A =
=0A+static inline unsigned int=0A+num_act_frames_from_sha_frames(const =
unsigned int num)=0A+{=0A+    /* How many frames are needed for the active =
grant table,=0A+     * given the size of the shared grant table? */=0A+    =
unsigned int sha_per_page =3D PAGE_SIZE / sizeof(grant_entry_v1_t);=0A+    =
unsigned int num_sha_entries =3D num * sha_per_page;=0A+    return =
(num_sha_entries + (ACGNT_PER_PAGE - 1)) / ACGNT_PER_PAGE;=0A+}=0A+=0A+#def=
ine max_nr_active_grant_frames \=0A+    num_act_frames_from_sha_frames(max_=
nr_grant_frames)=0A+=0A+static inline unsigned int=0A+nr_active_grant_frame=
s(struct grant_table *gt)=0A+{=0A+    return num_act_frames_from_sha_frames=
(nr_grant_frames(gt));=0A+}=0A+=0A /* Check if the page has been paged =
out, or needs unsharing. =0A    If rc =3D=3D GNTST_okay, *page contains =
the page struct with a ref taken.=0A    Caller must do put_page(*page).=0A@=
@ -2542,13 +2577,6 @@ do_grant_table_op(=0A #include "compat/grant_table.c"=
=0A #endif=0A =0A-static unsigned int max_nr_active_grant_frames(void)=0A-{=
=0A-    return (((max_nr_grant_frames * (PAGE_SIZE / sizeof(grant_entry_v1_=
t))) + =0A-                    ((PAGE_SIZE / sizeof(struct active_grant_ent=
ry))-1)) =0A-                   / (PAGE_SIZE / sizeof(struct active_grant_e=
ntry)));=0A-}=0A-=0A int =0A grant_table_create(=0A     struct domain =
*d)=0A@@ -2565,7 +2593,7 @@ grant_table_create(=0A =0A     /* Active grant =
table. */=0A     if ( (t->active =3D xzalloc_array(struct active_grant_entr=
y *,=0A-                                    max_nr_active_grant_frames())) =
=3D=3D NULL )=0A+                                    max_nr_active_grant_fr=
ames)) =3D=3D NULL )=0A         goto no_mem_1;=0A     for ( i =3D 0;=0A    =
       i < num_act_frames_from_sha_frames(INITIAL_NR_GRANT_FRAMES); i++ =
)=0A--- a/xen/include/xen/grant_table.h=0A+++ b/xen/include/xen/grant_table=
.h=0A@@ -28,21 +28,6 @@=0A #include <asm/page.h>=0A #include <asm/grant_tab=
le.h>=0A =0A-/* Active grant entry - used for shadowing GTF_permit_access =
grants. */=0A-struct active_grant_entry {=0A-    u32           pin;    /* =
Reference count information.             */=0A-    domid_t       domid;  =
/* Domain being granted access.             */=0A-    struct domain =
*trans_domain;=0A-    uint32_t      trans_gref;=0A-    unsigned long =
frame;  /* Frame being granted.                     */=0A-    unsigned =
long gfn;    /* Guest's idea of the frame being granted. */=0A-    =
unsigned      is_sub_page:1; /* True if this is a sub-page grant. */=0A-   =
 unsigned      start:15; /* For sub-page grants, the start offset=0A-      =
                         in the page.                           */=0A-    =
unsigned      length:16; /* For sub-page grants, the length of the=0A-     =
                           grant.                                =
*/=0A-};=0A-=0A  /* Count of writable host-CPU mappings. */=0A #define =
GNTPIN_hstw_shift    (0)=0A #define GNTPIN_hstw_inc      (1 << GNTPIN_hstw_=
shift)=0A@@ -147,23 +132,4 @@ static inline unsigned int grant_to_stat=0A  =
       GRANT_STATUS_PER_PAGE;=0A }=0A =0A-static inline unsigned int=0A-num=
_act_frames_from_sha_frames(const unsigned int num)=0A-{=0A-    /* How =
many frames are needed for the active grant table,=0A-     * given the =
size of the shared grant table? */=0A-    unsigned act_per_page =3D =
PAGE_SIZE / sizeof(struct active_grant_entry);=0A-    unsigned sha_per_page=
 =3D PAGE_SIZE / sizeof(grant_entry_v1_t);=0A-    unsigned num_sha_entries =
=3D num * sha_per_page;=0A-    unsigned num_act_frames =3D=0A-        =
(num_sha_entries + (act_per_page-1)) / act_per_page;=0A-    return =
num_act_frames;=0A-}=0A-=0A-static inline unsigned int=0A-nr_active_grant_f=
rames(struct grant_table *gt)=0A-{=0A-    return num_act_frames_from_sha_fr=
ames(nr_grant_frames(gt));=0A-}=0A-=0A #endif /* __XEN_GRANT_TABLE_H__ =
*/=0A
--=__Part08391A58.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

--=__Part08391A58.0__=--


From xen-devel-bounces@lists.xen.org Tue Sep 11 12:34:17 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 2012 12:34: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 1TBPf8-0008Pd-CP; Tue, 11 Sep 2012 12:33:54 +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 1TBPf7-0008PY-B0
	for xen-devel@lists.xen.org; Tue, 11 Sep 2012 12:33:53 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1347366811!10562892!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQwNzc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21670 invoked from network); 11 Sep 2012 12:33:31 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-12.tower-27.messagelabs.com with SMTP;
	11 Sep 2012 12:33:31 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 11 Sep 2012 13:33:30 +0100
Message-Id: <504F4BB7020000780009A95F@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 11 Sep 2012 13:33:27 +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 0/3] passthrough/x86: use PCI/MSI definitions
 and functions where possible
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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: amd iommu: use PCI macros instead of open coding them
2: amd iommu: use base platform MSI implementation
3: VT-d: use msi_compose_msg()

Signed-off-by: Jan Beulich <jbeulich@suse.com>


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 11 12:34:17 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 2012 12:34: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 1TBPf8-0008Pd-CP; Tue, 11 Sep 2012 12:33:54 +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 1TBPf7-0008PY-B0
	for xen-devel@lists.xen.org; Tue, 11 Sep 2012 12:33:53 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1347366811!10562892!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQwNzc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21670 invoked from network); 11 Sep 2012 12:33:31 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-12.tower-27.messagelabs.com with SMTP;
	11 Sep 2012 12:33:31 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 11 Sep 2012 13:33:30 +0100
Message-Id: <504F4BB7020000780009A95F@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 11 Sep 2012 13:33:27 +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 0/3] passthrough/x86: use PCI/MSI definitions
 and functions where possible
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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: amd iommu: use PCI macros instead of open coding them
2: amd iommu: use base platform MSI implementation
3: VT-d: use msi_compose_msg()

Signed-off-by: Jan Beulich <jbeulich@suse.com>


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 11 12:35:21 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 2012 12:35:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TBPgF-00006v-RK; Tue, 11 Sep 2012 12:35:03 +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 1TBPgE-00006a-1U
	for xen-devel@lists.xen.org; Tue, 11 Sep 2012 12:35:02 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1347366889!9279000!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQwNzc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3956 invoked from network); 11 Sep 2012 12:34:49 -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;
	11 Sep 2012 12:34:49 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 11 Sep 2012 13:34:48 +0100
Message-Id: <504F4C04020000780009A964@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 11 Sep 2012 13:34:44 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__PartAC9DBEF4.1__="
Cc: Wei Wang <wei.wang2@amd.com>
Subject: [Xen-devel] [PATCH 1/3] amd iommu: use PCI macros
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
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.

--=__PartAC9DBEF4.1__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

... instead of open coding them.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/drivers/passthrough/amd/iommu_init.c
+++ b/xen/drivers/passthrough/amd/iommu_init.c
@@ -455,9 +455,9 @@ static void iommu_msi_set_affinity(struc
     unsigned int dest;
     struct amd_iommu *iommu =3D desc->action->dev_id;
     u16 seg =3D iommu->seg;
-    u8 bus =3D (iommu->bdf >> 8) & 0xff;
-    u8 dev =3D PCI_SLOT(iommu->bdf & 0xff);
-    u8 func =3D PCI_FUNC(iommu->bdf & 0xff);
+    u8 bus =3D PCI_BUS(iommu->bdf);
+    u8 dev =3D PCI_SLOT(iommu->bdf);
+    u8 func =3D PCI_FUNC(iommu->bdf);
=20
     dest =3D set_desc_affinity(desc, mask);
=20
@@ -495,13 +495,13 @@ static void iommu_msi_set_affinity(struc
 static void amd_iommu_msi_enable(struct amd_iommu *iommu, int flag)
 {
     u16 control;
-    int bus =3D (iommu->bdf >> 8) & 0xff;
-    int dev =3D PCI_SLOT(iommu->bdf & 0xff);
-    int func =3D PCI_FUNC(iommu->bdf & 0xff);
+    int bus =3D PCI_BUS(iommu->bdf);
+    int dev =3D PCI_SLOT(iommu->bdf);
+    int func =3D PCI_FUNC(iommu->bdf);
=20
     control =3D pci_conf_read16(iommu->seg, bus, dev, func,
         iommu->msi_cap + PCI_MSI_FLAGS);
-    control &=3D ~(1);
+    control &=3D ~PCI_MSI_FLAGS_ENABLE;
     if ( flag )
         control |=3D flag;
     pci_conf_write16(iommu->seg, bus, dev, func,
--- a/xen/drivers/passthrough/amd/iommu_intr.c
+++ b/xen/drivers/passthrough/amd/iommu_intr.c
@@ -272,7 +272,7 @@ static void update_intremap_entry_from_m
     spinlock_t *lock;
     int offset;
=20
-    bdf =3D (pdev->bus << 8) | pdev->devfn;
+    bdf =3D PCI_BDF2(pdev->bus, pdev->devfn);
     req_id =3D get_dma_requestor_id(pdev->seg, bdf);
     alias_id =3D get_intremap_requestor_id(pdev->seg, bdf);
=20
@@ -340,17 +340,16 @@ void amd_iommu_msi_msg_update_ire(
     struct msi_desc *msi_desc, struct msi_msg *msg)
 {
     struct pci_dev *pdev =3D msi_desc->dev;
-    struct amd_iommu *iommu =3D NULL;
+    int bdf =3D PCI_BDF2(pdev->bus, pdev->devfn);
+    struct amd_iommu *iommu;
=20
     if ( !iommu_intremap )
         return;
=20
-    iommu =3D find_iommu_for_device(pdev->seg, (pdev->bus << 8) | =
pdev->devfn);
-
+    iommu =3D find_iommu_for_device(pdev->seg, bdf);
     if ( !iommu )
     {
-        AMD_IOMMU_DEBUG("Fail to find iommu for MSI device id =3D =
0x%x\n",
-                       (pdev->bus << 8) | pdev->devfn);
+        AMD_IOMMU_DEBUG("Fail to find iommu for MSI device id =3D %#x\n", =
bdf);
         return;
     }
=20
--- a/xen/drivers/passthrough/amd/iommu_map.c
+++ b/xen/drivers/passthrough/amd/iommu_map.c
@@ -597,7 +597,7 @@ static int update_paging_mode(struct dom
         /* Update device table entries using new root table and paging =
mode */
         for_each_pdev( d, pdev )
         {
-            bdf =3D (pdev->bus << 8) | pdev->devfn;
+            bdf =3D PCI_BDF2(pdev->bus, pdev->devfn);
             req_id =3D get_dma_requestor_id(pdev->seg, bdf);
             iommu =3D find_iommu_for_device(pdev->seg, bdf);
             if ( !iommu )
--- a/xen/drivers/passthrough/amd/pci_amd_iommu.c
+++ b/xen/drivers/passthrough/amd/pci_amd_iommu.c
@@ -373,7 +373,7 @@ static int reassign_device( struct domai
 static int amd_iommu_assign_device(struct domain *d, u16 seg, u8 bus, u8 =
devfn)
 {
     struct ivrs_mappings *ivrs_mappings =3D get_ivrs_mappings(seg);
-    int bdf =3D (bus << 8) | devfn;
+    int bdf =3D PCI_BDF2(bus, devfn);
     int req_id =3D get_dma_requestor_id(seg, bdf);
=20
     if ( ivrs_mappings[req_id].unity_map_enable )
@@ -499,12 +499,9 @@ static int amd_iommu_remove_device(struc
=20
 static int amd_iommu_group_id(u16 seg, u8 bus, u8 devfn)
 {
-    int rt;
-    int bdf =3D (bus << 8) | devfn;
-    rt =3D ( bdf < ivrs_bdf_entries ) ?
-        get_dma_requestor_id(seg, bdf) :
-        bdf;
-    return rt;
+    int bdf =3D PCI_BDF2(bus, devfn);
+
+    return (bdf < ivrs_bdf_entries) ? get_dma_requestor_id(seg, bdf) : =
bdf;
 }
=20
 #include <asm/io_apic.h>




--=__PartAC9DBEF4.1__=
Content-Type: text/plain; name="amd-iommu-PCI-macros.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="amd-iommu-PCI-macros.patch"

amd iommu: use PCI macros=0A=0A... instead of open coding them.=0A=0ASigned=
-off-by: Jan Beulich <jbeulich@suse.com>=0A=0A--- a/xen/drivers/passthrough=
/amd/iommu_init.c=0A+++ b/xen/drivers/passthrough/amd/iommu_init.c=0A@@ =
-455,9 +455,9 @@ static void iommu_msi_set_affinity(struc=0A     unsigned =
int dest;=0A     struct amd_iommu *iommu =3D desc->action->dev_id;=0A     =
u16 seg =3D iommu->seg;=0A-    u8 bus =3D (iommu->bdf >> 8) & 0xff;=0A-    =
u8 dev =3D PCI_SLOT(iommu->bdf & 0xff);=0A-    u8 func =3D PCI_FUNC(iommu->=
bdf & 0xff);=0A+    u8 bus =3D PCI_BUS(iommu->bdf);=0A+    u8 dev =3D =
PCI_SLOT(iommu->bdf);=0A+    u8 func =3D PCI_FUNC(iommu->bdf);=0A =0A     =
dest =3D set_desc_affinity(desc, mask);=0A =0A@@ -495,13 +495,13 @@ static =
void iommu_msi_set_affinity(struc=0A static void amd_iommu_msi_enable(struc=
t amd_iommu *iommu, int flag)=0A {=0A     u16 control;=0A-    int bus =3D =
(iommu->bdf >> 8) & 0xff;=0A-    int dev =3D PCI_SLOT(iommu->bdf & =
0xff);=0A-    int func =3D PCI_FUNC(iommu->bdf & 0xff);=0A+    int bus =3D =
PCI_BUS(iommu->bdf);=0A+    int dev =3D PCI_SLOT(iommu->bdf);=0A+    int =
func =3D PCI_FUNC(iommu->bdf);=0A =0A     control =3D pci_conf_read16(iommu=
->seg, bus, dev, func,=0A         iommu->msi_cap + PCI_MSI_FLAGS);=0A-    =
control &=3D ~(1);=0A+    control &=3D ~PCI_MSI_FLAGS_ENABLE;=0A     if ( =
flag )=0A         control |=3D flag;=0A     pci_conf_write16(iommu->seg, =
bus, dev, func,=0A--- a/xen/drivers/passthrough/amd/iommu_intr.c=0A+++ =
b/xen/drivers/passthrough/amd/iommu_intr.c=0A@@ -272,7 +272,7 @@ static =
void update_intremap_entry_from_m=0A     spinlock_t *lock;=0A     int =
offset;=0A =0A-    bdf =3D (pdev->bus << 8) | pdev->devfn;=0A+    bdf =3D =
PCI_BDF2(pdev->bus, pdev->devfn);=0A     req_id =3D get_dma_requestor_id(pd=
ev->seg, bdf);=0A     alias_id =3D get_intremap_requestor_id(pdev->seg, =
bdf);=0A =0A@@ -340,17 +340,16 @@ void amd_iommu_msi_msg_update_ire(=0A    =
 struct msi_desc *msi_desc, struct msi_msg *msg)=0A {=0A     struct =
pci_dev *pdev =3D msi_desc->dev;=0A-    struct amd_iommu *iommu =3D =
NULL;=0A+    int bdf =3D PCI_BDF2(pdev->bus, pdev->devfn);=0A+    struct =
amd_iommu *iommu;=0A =0A     if ( !iommu_intremap )=0A         return;=0A =
=0A-    iommu =3D find_iommu_for_device(pdev->seg, (pdev->bus << 8) | =
pdev->devfn);=0A-=0A+    iommu =3D find_iommu_for_device(pdev->seg, =
bdf);=0A     if ( !iommu )=0A     {=0A-        AMD_IOMMU_DEBUG("Fail to =
find iommu for MSI device id =3D 0x%x\n",=0A-                       =
(pdev->bus << 8) | pdev->devfn);=0A+        AMD_IOMMU_DEBUG("Fail to find =
iommu for MSI device id =3D %#x\n", bdf);=0A         return;=0A     }=0A =
=0A--- a/xen/drivers/passthrough/amd/iommu_map.c=0A+++ b/xen/drivers/passth=
rough/amd/iommu_map.c=0A@@ -597,7 +597,7 @@ static int update_paging_mode(s=
truct dom=0A         /* Update device table entries using new root table =
and paging mode */=0A         for_each_pdev( d, pdev )=0A         {=0A-    =
        bdf =3D (pdev->bus << 8) | pdev->devfn;=0A+            bdf =3D =
PCI_BDF2(pdev->bus, pdev->devfn);=0A             req_id =3D get_dma_request=
or_id(pdev->seg, bdf);=0A             iommu =3D find_iommu_for_device(pdev-=
>seg, bdf);=0A             if ( !iommu )=0A--- a/xen/drivers/passthrough/am=
d/pci_amd_iommu.c=0A+++ b/xen/drivers/passthrough/amd/pci_amd_iommu.c=0A@@ =
-373,7 +373,7 @@ static int reassign_device( struct domai=0A static int =
amd_iommu_assign_device(struct domain *d, u16 seg, u8 bus, u8 devfn)=0A =
{=0A     struct ivrs_mappings *ivrs_mappings =3D get_ivrs_mappings(seg);=0A=
-    int bdf =3D (bus << 8) | devfn;=0A+    int bdf =3D PCI_BDF2(bus, =
devfn);=0A     int req_id =3D get_dma_requestor_id(seg, bdf);=0A =0A     =
if ( ivrs_mappings[req_id].unity_map_enable )=0A@@ -499,12 +499,9 @@ =
static int amd_iommu_remove_device(struc=0A =0A static int amd_iommu_group_=
id(u16 seg, u8 bus, u8 devfn)=0A {=0A-    int rt;=0A-    int bdf =3D (bus =
<< 8) | devfn;=0A-    rt =3D ( bdf < ivrs_bdf_entries ) ?=0A-        =
get_dma_requestor_id(seg, bdf) :=0A-        bdf;=0A-    return rt;=0A+    =
int bdf =3D PCI_BDF2(bus, devfn);=0A+=0A+    return (bdf < ivrs_bdf_entries=
) ? get_dma_requestor_id(seg, bdf) : bdf;=0A }=0A =0A #include <asm/io_apic=
.h>=0A
--=__PartAC9DBEF4.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

--=__PartAC9DBEF4.1__=--


From xen-devel-bounces@lists.xen.org Tue Sep 11 12:35:21 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 2012 12:35:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TBPgF-00006v-RK; Tue, 11 Sep 2012 12:35:03 +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 1TBPgE-00006a-1U
	for xen-devel@lists.xen.org; Tue, 11 Sep 2012 12:35:02 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1347366889!9279000!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQwNzc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3956 invoked from network); 11 Sep 2012 12:34:49 -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;
	11 Sep 2012 12:34:49 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 11 Sep 2012 13:34:48 +0100
Message-Id: <504F4C04020000780009A964@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 11 Sep 2012 13:34:44 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__PartAC9DBEF4.1__="
Cc: Wei Wang <wei.wang2@amd.com>
Subject: [Xen-devel] [PATCH 1/3] amd iommu: use PCI macros
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
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.

--=__PartAC9DBEF4.1__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

... instead of open coding them.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/drivers/passthrough/amd/iommu_init.c
+++ b/xen/drivers/passthrough/amd/iommu_init.c
@@ -455,9 +455,9 @@ static void iommu_msi_set_affinity(struc
     unsigned int dest;
     struct amd_iommu *iommu =3D desc->action->dev_id;
     u16 seg =3D iommu->seg;
-    u8 bus =3D (iommu->bdf >> 8) & 0xff;
-    u8 dev =3D PCI_SLOT(iommu->bdf & 0xff);
-    u8 func =3D PCI_FUNC(iommu->bdf & 0xff);
+    u8 bus =3D PCI_BUS(iommu->bdf);
+    u8 dev =3D PCI_SLOT(iommu->bdf);
+    u8 func =3D PCI_FUNC(iommu->bdf);
=20
     dest =3D set_desc_affinity(desc, mask);
=20
@@ -495,13 +495,13 @@ static void iommu_msi_set_affinity(struc
 static void amd_iommu_msi_enable(struct amd_iommu *iommu, int flag)
 {
     u16 control;
-    int bus =3D (iommu->bdf >> 8) & 0xff;
-    int dev =3D PCI_SLOT(iommu->bdf & 0xff);
-    int func =3D PCI_FUNC(iommu->bdf & 0xff);
+    int bus =3D PCI_BUS(iommu->bdf);
+    int dev =3D PCI_SLOT(iommu->bdf);
+    int func =3D PCI_FUNC(iommu->bdf);
=20
     control =3D pci_conf_read16(iommu->seg, bus, dev, func,
         iommu->msi_cap + PCI_MSI_FLAGS);
-    control &=3D ~(1);
+    control &=3D ~PCI_MSI_FLAGS_ENABLE;
     if ( flag )
         control |=3D flag;
     pci_conf_write16(iommu->seg, bus, dev, func,
--- a/xen/drivers/passthrough/amd/iommu_intr.c
+++ b/xen/drivers/passthrough/amd/iommu_intr.c
@@ -272,7 +272,7 @@ static void update_intremap_entry_from_m
     spinlock_t *lock;
     int offset;
=20
-    bdf =3D (pdev->bus << 8) | pdev->devfn;
+    bdf =3D PCI_BDF2(pdev->bus, pdev->devfn);
     req_id =3D get_dma_requestor_id(pdev->seg, bdf);
     alias_id =3D get_intremap_requestor_id(pdev->seg, bdf);
=20
@@ -340,17 +340,16 @@ void amd_iommu_msi_msg_update_ire(
     struct msi_desc *msi_desc, struct msi_msg *msg)
 {
     struct pci_dev *pdev =3D msi_desc->dev;
-    struct amd_iommu *iommu =3D NULL;
+    int bdf =3D PCI_BDF2(pdev->bus, pdev->devfn);
+    struct amd_iommu *iommu;
=20
     if ( !iommu_intremap )
         return;
=20
-    iommu =3D find_iommu_for_device(pdev->seg, (pdev->bus << 8) | =
pdev->devfn);
-
+    iommu =3D find_iommu_for_device(pdev->seg, bdf);
     if ( !iommu )
     {
-        AMD_IOMMU_DEBUG("Fail to find iommu for MSI device id =3D =
0x%x\n",
-                       (pdev->bus << 8) | pdev->devfn);
+        AMD_IOMMU_DEBUG("Fail to find iommu for MSI device id =3D %#x\n", =
bdf);
         return;
     }
=20
--- a/xen/drivers/passthrough/amd/iommu_map.c
+++ b/xen/drivers/passthrough/amd/iommu_map.c
@@ -597,7 +597,7 @@ static int update_paging_mode(struct dom
         /* Update device table entries using new root table and paging =
mode */
         for_each_pdev( d, pdev )
         {
-            bdf =3D (pdev->bus << 8) | pdev->devfn;
+            bdf =3D PCI_BDF2(pdev->bus, pdev->devfn);
             req_id =3D get_dma_requestor_id(pdev->seg, bdf);
             iommu =3D find_iommu_for_device(pdev->seg, bdf);
             if ( !iommu )
--- a/xen/drivers/passthrough/amd/pci_amd_iommu.c
+++ b/xen/drivers/passthrough/amd/pci_amd_iommu.c
@@ -373,7 +373,7 @@ static int reassign_device( struct domai
 static int amd_iommu_assign_device(struct domain *d, u16 seg, u8 bus, u8 =
devfn)
 {
     struct ivrs_mappings *ivrs_mappings =3D get_ivrs_mappings(seg);
-    int bdf =3D (bus << 8) | devfn;
+    int bdf =3D PCI_BDF2(bus, devfn);
     int req_id =3D get_dma_requestor_id(seg, bdf);
=20
     if ( ivrs_mappings[req_id].unity_map_enable )
@@ -499,12 +499,9 @@ static int amd_iommu_remove_device(struc
=20
 static int amd_iommu_group_id(u16 seg, u8 bus, u8 devfn)
 {
-    int rt;
-    int bdf =3D (bus << 8) | devfn;
-    rt =3D ( bdf < ivrs_bdf_entries ) ?
-        get_dma_requestor_id(seg, bdf) :
-        bdf;
-    return rt;
+    int bdf =3D PCI_BDF2(bus, devfn);
+
+    return (bdf < ivrs_bdf_entries) ? get_dma_requestor_id(seg, bdf) : =
bdf;
 }
=20
 #include <asm/io_apic.h>




--=__PartAC9DBEF4.1__=
Content-Type: text/plain; name="amd-iommu-PCI-macros.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="amd-iommu-PCI-macros.patch"

amd iommu: use PCI macros=0A=0A... instead of open coding them.=0A=0ASigned=
-off-by: Jan Beulich <jbeulich@suse.com>=0A=0A--- a/xen/drivers/passthrough=
/amd/iommu_init.c=0A+++ b/xen/drivers/passthrough/amd/iommu_init.c=0A@@ =
-455,9 +455,9 @@ static void iommu_msi_set_affinity(struc=0A     unsigned =
int dest;=0A     struct amd_iommu *iommu =3D desc->action->dev_id;=0A     =
u16 seg =3D iommu->seg;=0A-    u8 bus =3D (iommu->bdf >> 8) & 0xff;=0A-    =
u8 dev =3D PCI_SLOT(iommu->bdf & 0xff);=0A-    u8 func =3D PCI_FUNC(iommu->=
bdf & 0xff);=0A+    u8 bus =3D PCI_BUS(iommu->bdf);=0A+    u8 dev =3D =
PCI_SLOT(iommu->bdf);=0A+    u8 func =3D PCI_FUNC(iommu->bdf);=0A =0A     =
dest =3D set_desc_affinity(desc, mask);=0A =0A@@ -495,13 +495,13 @@ static =
void iommu_msi_set_affinity(struc=0A static void amd_iommu_msi_enable(struc=
t amd_iommu *iommu, int flag)=0A {=0A     u16 control;=0A-    int bus =3D =
(iommu->bdf >> 8) & 0xff;=0A-    int dev =3D PCI_SLOT(iommu->bdf & =
0xff);=0A-    int func =3D PCI_FUNC(iommu->bdf & 0xff);=0A+    int bus =3D =
PCI_BUS(iommu->bdf);=0A+    int dev =3D PCI_SLOT(iommu->bdf);=0A+    int =
func =3D PCI_FUNC(iommu->bdf);=0A =0A     control =3D pci_conf_read16(iommu=
->seg, bus, dev, func,=0A         iommu->msi_cap + PCI_MSI_FLAGS);=0A-    =
control &=3D ~(1);=0A+    control &=3D ~PCI_MSI_FLAGS_ENABLE;=0A     if ( =
flag )=0A         control |=3D flag;=0A     pci_conf_write16(iommu->seg, =
bus, dev, func,=0A--- a/xen/drivers/passthrough/amd/iommu_intr.c=0A+++ =
b/xen/drivers/passthrough/amd/iommu_intr.c=0A@@ -272,7 +272,7 @@ static =
void update_intremap_entry_from_m=0A     spinlock_t *lock;=0A     int =
offset;=0A =0A-    bdf =3D (pdev->bus << 8) | pdev->devfn;=0A+    bdf =3D =
PCI_BDF2(pdev->bus, pdev->devfn);=0A     req_id =3D get_dma_requestor_id(pd=
ev->seg, bdf);=0A     alias_id =3D get_intremap_requestor_id(pdev->seg, =
bdf);=0A =0A@@ -340,17 +340,16 @@ void amd_iommu_msi_msg_update_ire(=0A    =
 struct msi_desc *msi_desc, struct msi_msg *msg)=0A {=0A     struct =
pci_dev *pdev =3D msi_desc->dev;=0A-    struct amd_iommu *iommu =3D =
NULL;=0A+    int bdf =3D PCI_BDF2(pdev->bus, pdev->devfn);=0A+    struct =
amd_iommu *iommu;=0A =0A     if ( !iommu_intremap )=0A         return;=0A =
=0A-    iommu =3D find_iommu_for_device(pdev->seg, (pdev->bus << 8) | =
pdev->devfn);=0A-=0A+    iommu =3D find_iommu_for_device(pdev->seg, =
bdf);=0A     if ( !iommu )=0A     {=0A-        AMD_IOMMU_DEBUG("Fail to =
find iommu for MSI device id =3D 0x%x\n",=0A-                       =
(pdev->bus << 8) | pdev->devfn);=0A+        AMD_IOMMU_DEBUG("Fail to find =
iommu for MSI device id =3D %#x\n", bdf);=0A         return;=0A     }=0A =
=0A--- a/xen/drivers/passthrough/amd/iommu_map.c=0A+++ b/xen/drivers/passth=
rough/amd/iommu_map.c=0A@@ -597,7 +597,7 @@ static int update_paging_mode(s=
truct dom=0A         /* Update device table entries using new root table =
and paging mode */=0A         for_each_pdev( d, pdev )=0A         {=0A-    =
        bdf =3D (pdev->bus << 8) | pdev->devfn;=0A+            bdf =3D =
PCI_BDF2(pdev->bus, pdev->devfn);=0A             req_id =3D get_dma_request=
or_id(pdev->seg, bdf);=0A             iommu =3D find_iommu_for_device(pdev-=
>seg, bdf);=0A             if ( !iommu )=0A--- a/xen/drivers/passthrough/am=
d/pci_amd_iommu.c=0A+++ b/xen/drivers/passthrough/amd/pci_amd_iommu.c=0A@@ =
-373,7 +373,7 @@ static int reassign_device( struct domai=0A static int =
amd_iommu_assign_device(struct domain *d, u16 seg, u8 bus, u8 devfn)=0A =
{=0A     struct ivrs_mappings *ivrs_mappings =3D get_ivrs_mappings(seg);=0A=
-    int bdf =3D (bus << 8) | devfn;=0A+    int bdf =3D PCI_BDF2(bus, =
devfn);=0A     int req_id =3D get_dma_requestor_id(seg, bdf);=0A =0A     =
if ( ivrs_mappings[req_id].unity_map_enable )=0A@@ -499,12 +499,9 @@ =
static int amd_iommu_remove_device(struc=0A =0A static int amd_iommu_group_=
id(u16 seg, u8 bus, u8 devfn)=0A {=0A-    int rt;=0A-    int bdf =3D (bus =
<< 8) | devfn;=0A-    rt =3D ( bdf < ivrs_bdf_entries ) ?=0A-        =
get_dma_requestor_id(seg, bdf) :=0A-        bdf;=0A-    return rt;=0A+    =
int bdf =3D PCI_BDF2(bus, devfn);=0A+=0A+    return (bdf < ivrs_bdf_entries=
) ? get_dma_requestor_id(seg, bdf) : bdf;=0A }=0A =0A #include <asm/io_apic=
.h>=0A
--=__PartAC9DBEF4.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

--=__PartAC9DBEF4.1__=--


From xen-devel-bounces@lists.xen.org Tue Sep 11 12:36:22 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 2012 12: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 1TBPhI-0000CU-AB; Tue, 11 Sep 2012 12:36:08 +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 1TBPhG-0000Be-GQ
	for xen-devel@lists.xen.org; Tue, 11 Sep 2012 12:36:06 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1347366952!7144283!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQwNzc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17729 invoked from network); 11 Sep 2012 12:35:52 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-5.tower-27.messagelabs.com with SMTP;
	11 Sep 2012 12:35:52 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 11 Sep 2012 13:35:52 +0100
Message-Id: <504F4C45020000780009A96C@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 11 Sep 2012 13:35:49 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part72436035.1__="
Cc: xiantao.zhang@intel.com
Subject: [Xen-devel] [PATCH 3/3] VT-d: use msi_compose_msg()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<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.

--=__Part72436035.1__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

... instead of open coding it.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/drivers/passthrough/vtd/iommu.c
+++ b/xen/drivers/passthrough/vtd/iommu.c
@@ -1079,22 +1079,11 @@ static void dma_msi_set_affinity(struct=20
         return;
     }
=20
-    memset(&msg, 0, sizeof(msg));=20
-    msg.data =3D MSI_DATA_VECTOR(desc->arch.vector) & 0xff;
-    msg.data |=3D 1 << 14;
-    msg.data |=3D (INT_DELIVERY_MODE !=3D dest_LowestPrio) ?
-        MSI_DATA_DELIVERY_FIXED:
-        MSI_DATA_DELIVERY_LOWPRI;
-
-    /* Follow MSI setting */
+    msi_compose_msg(desc, &msg);
+    /* Are these overrides really needed? */
     if (x2apic_enabled)
         msg.address_hi =3D dest & 0xFFFFFF00;
-    msg.address_lo =3D (MSI_ADDRESS_HEADER << (MSI_ADDRESS_HEADER_SHIFT + =
8));
-    msg.address_lo |=3D INT_DEST_MODE ? MSI_ADDR_DESTMODE_LOGIC:
-                    MSI_ADDR_DESTMODE_PHYS;
-    msg.address_lo |=3D (INT_DELIVERY_MODE !=3D dest_LowestPrio) ?
-                    MSI_ADDR_REDIRECTION_CPU:
-                    MSI_ADDR_REDIRECTION_LOWPRI;
+    msg.address_lo &=3D ~MSI_ADDR_DEST_ID_MASK;
     msg.address_lo |=3D MSI_ADDR_DEST_ID(dest & 0xff);
 #else
     memset(&msg, 0, sizeof(msg));




--=__Part72436035.1__=
Content-Type: text/plain; name="VT-d-MSI.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="VT-d-MSI.patch"

VT-d: use msi_compose_msg()=0A=0A... instead of open coding it.=0A=0ASigned=
-off-by: Jan Beulich <jbeulich@suse.com>=0A=0A--- a/xen/drivers/passthrough=
/vtd/iommu.c=0A+++ b/xen/drivers/passthrough/vtd/iommu.c=0A@@ -1079,22 =
+1079,11 @@ static void dma_msi_set_affinity(struct =0A         return;=0A =
    }=0A =0A-    memset(&msg, 0, sizeof(msg)); =0A-    msg.data =3D =
MSI_DATA_VECTOR(desc->arch.vector) & 0xff;=0A-    msg.data |=3D 1 << =
14;=0A-    msg.data |=3D (INT_DELIVERY_MODE !=3D dest_LowestPrio) ?=0A-    =
    MSI_DATA_DELIVERY_FIXED:=0A-        MSI_DATA_DELIVERY_LOWPRI;=0A-=0A-  =
  /* Follow MSI setting */=0A+    msi_compose_msg(desc, &msg);=0A+    /* =
Are these overrides really needed? */=0A     if (x2apic_enabled)=0A        =
 msg.address_hi =3D dest & 0xFFFFFF00;=0A-    msg.address_lo =3D (MSI_ADDRE=
SS_HEADER << (MSI_ADDRESS_HEADER_SHIFT + 8));=0A-    msg.address_lo |=3D =
INT_DEST_MODE ? MSI_ADDR_DESTMODE_LOGIC:=0A-                    MSI_ADDR_DE=
STMODE_PHYS;=0A-    msg.address_lo |=3D (INT_DELIVERY_MODE !=3D dest_Lowest=
Prio) ?=0A-                    MSI_ADDR_REDIRECTION_CPU:=0A-               =
     MSI_ADDR_REDIRECTION_LOWPRI;=0A+    msg.address_lo &=3D ~MSI_ADDR_DEST=
_ID_MASK;=0A     msg.address_lo |=3D MSI_ADDR_DEST_ID(dest & 0xff);=0A =
#else=0A     memset(&msg, 0, sizeof(msg));=0A
--=__Part72436035.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

--=__Part72436035.1__=--


From xen-devel-bounces@lists.xen.org Tue Sep 11 12:36:22 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 2012 12: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 1TBPhI-0000CU-AB; Tue, 11 Sep 2012 12:36:08 +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 1TBPhG-0000Be-GQ
	for xen-devel@lists.xen.org; Tue, 11 Sep 2012 12:36:06 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1347366952!7144283!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQwNzc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17729 invoked from network); 11 Sep 2012 12:35:52 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-5.tower-27.messagelabs.com with SMTP;
	11 Sep 2012 12:35:52 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 11 Sep 2012 13:35:52 +0100
Message-Id: <504F4C45020000780009A96C@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 11 Sep 2012 13:35:49 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part72436035.1__="
Cc: xiantao.zhang@intel.com
Subject: [Xen-devel] [PATCH 3/3] VT-d: use msi_compose_msg()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<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.

--=__Part72436035.1__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

... instead of open coding it.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/drivers/passthrough/vtd/iommu.c
+++ b/xen/drivers/passthrough/vtd/iommu.c
@@ -1079,22 +1079,11 @@ static void dma_msi_set_affinity(struct=20
         return;
     }
=20
-    memset(&msg, 0, sizeof(msg));=20
-    msg.data =3D MSI_DATA_VECTOR(desc->arch.vector) & 0xff;
-    msg.data |=3D 1 << 14;
-    msg.data |=3D (INT_DELIVERY_MODE !=3D dest_LowestPrio) ?
-        MSI_DATA_DELIVERY_FIXED:
-        MSI_DATA_DELIVERY_LOWPRI;
-
-    /* Follow MSI setting */
+    msi_compose_msg(desc, &msg);
+    /* Are these overrides really needed? */
     if (x2apic_enabled)
         msg.address_hi =3D dest & 0xFFFFFF00;
-    msg.address_lo =3D (MSI_ADDRESS_HEADER << (MSI_ADDRESS_HEADER_SHIFT + =
8));
-    msg.address_lo |=3D INT_DEST_MODE ? MSI_ADDR_DESTMODE_LOGIC:
-                    MSI_ADDR_DESTMODE_PHYS;
-    msg.address_lo |=3D (INT_DELIVERY_MODE !=3D dest_LowestPrio) ?
-                    MSI_ADDR_REDIRECTION_CPU:
-                    MSI_ADDR_REDIRECTION_LOWPRI;
+    msg.address_lo &=3D ~MSI_ADDR_DEST_ID_MASK;
     msg.address_lo |=3D MSI_ADDR_DEST_ID(dest & 0xff);
 #else
     memset(&msg, 0, sizeof(msg));




--=__Part72436035.1__=
Content-Type: text/plain; name="VT-d-MSI.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="VT-d-MSI.patch"

VT-d: use msi_compose_msg()=0A=0A... instead of open coding it.=0A=0ASigned=
-off-by: Jan Beulich <jbeulich@suse.com>=0A=0A--- a/xen/drivers/passthrough=
/vtd/iommu.c=0A+++ b/xen/drivers/passthrough/vtd/iommu.c=0A@@ -1079,22 =
+1079,11 @@ static void dma_msi_set_affinity(struct =0A         return;=0A =
    }=0A =0A-    memset(&msg, 0, sizeof(msg)); =0A-    msg.data =3D =
MSI_DATA_VECTOR(desc->arch.vector) & 0xff;=0A-    msg.data |=3D 1 << =
14;=0A-    msg.data |=3D (INT_DELIVERY_MODE !=3D dest_LowestPrio) ?=0A-    =
    MSI_DATA_DELIVERY_FIXED:=0A-        MSI_DATA_DELIVERY_LOWPRI;=0A-=0A-  =
  /* Follow MSI setting */=0A+    msi_compose_msg(desc, &msg);=0A+    /* =
Are these overrides really needed? */=0A     if (x2apic_enabled)=0A        =
 msg.address_hi =3D dest & 0xFFFFFF00;=0A-    msg.address_lo =3D (MSI_ADDRE=
SS_HEADER << (MSI_ADDRESS_HEADER_SHIFT + 8));=0A-    msg.address_lo |=3D =
INT_DEST_MODE ? MSI_ADDR_DESTMODE_LOGIC:=0A-                    MSI_ADDR_DE=
STMODE_PHYS;=0A-    msg.address_lo |=3D (INT_DELIVERY_MODE !=3D dest_Lowest=
Prio) ?=0A-                    MSI_ADDR_REDIRECTION_CPU:=0A-               =
     MSI_ADDR_REDIRECTION_LOWPRI;=0A+    msg.address_lo &=3D ~MSI_ADDR_DEST=
_ID_MASK;=0A     msg.address_lo |=3D MSI_ADDR_DEST_ID(dest & 0xff);=0A =
#else=0A     memset(&msg, 0, sizeof(msg));=0A
--=__Part72436035.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

--=__Part72436035.1__=--


From xen-devel-bounces@lists.xen.org Tue Sep 11 12:37:19 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 2012 12:37: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 1TBPiA-0000JH-Uq; Tue, 11 Sep 2012 12:37:02 +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 1TBPi8-0000IB-Iz
	for xen-devel@lists.xen.org; Tue, 11 Sep 2012 12:37:01 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1347366919!9979361!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQwNzc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5890 invoked from network); 11 Sep 2012 12:35:19 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-4.tower-27.messagelabs.com with SMTP;
	11 Sep 2012 12:35:19 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 11 Sep 2012 13:35:19 +0100
Message-Id: <504F4C24020000780009A968@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 11 Sep 2012 13:35:16 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part53624114.1__="
Cc: Wei Wang <wei.wang2@amd.com>
Subject: [Xen-devel] [PATCH 2/3] amd iommu: use base platform MSI
	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

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.

--=__Part53624114.1__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Given that here, other than for VT-d, the MSI interface gets surfaced
through a normal PCI device, the code should use as much as possible of
the "normal" MSI support code.

Further, the code can (and should) follow the "normal" MSI code in
distinguishing the maskable and non-maskable cases at the IRQ
controller level rather than checking the respective flag in the
individual actors.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/arch/x86/msi.c
+++ b/xen/arch/x86/msi.c
@@ -126,13 +126,23 @@ void msi_compose_msg(struct irq_desc *de
     unsigned dest;
     int vector =3D desc->arch.vector;
=20
-    if ( cpumask_empty(desc->arch.cpu_mask) ) {
+    memset(msg, 0, sizeof(*msg));
+    if ( !cpumask_intersects(desc->arch.cpu_mask, &cpu_online_map) ) {
         dprintk(XENLOG_ERR,"%s, compose msi message error!!\n", __func__);=

         return;
     }
=20
     if ( vector ) {
-        dest =3D cpu_mask_to_apicid(desc->arch.cpu_mask);
+        cpumask_var_t mask;
+
+        if ( alloc_cpumask_var(&mask) )
+        {
+            cpumask_and(mask, desc->arch.cpu_mask, &cpu_online_map);
+            dest =3D cpu_mask_to_apicid(mask);
+            free_cpumask_var(mask);
+        }
+        else
+            dest =3D cpu_mask_to_apicid(desc->arch.cpu_mask);
=20
         msg->address_hi =3D MSI_ADDR_BASE_HI;
         msg->address_lo =3D
@@ -281,23 +291,27 @@ static void set_msi_affinity(struct irq_
     write_msi_msg(msi_desc, &msg);
 }
=20
+void __msi_set_enable(u16 seg, u8 bus, u8 slot, u8 func, int pos, int =
enable)
+{
+    u16 control =3D pci_conf_read16(seg, bus, slot, func, pos + PCI_MSI_FL=
AGS);
+
+    control &=3D ~PCI_MSI_FLAGS_ENABLE;
+    if ( enable )
+        control |=3D PCI_MSI_FLAGS_ENABLE;
+    pci_conf_write16(seg, bus, slot, func, pos + PCI_MSI_FLAGS, control);
+}
+
 static void msi_set_enable(struct pci_dev *dev, int enable)
 {
     int pos;
-    u16 control, seg =3D dev->seg;
+    u16 seg =3D dev->seg;
     u8 bus =3D dev->bus;
     u8 slot =3D PCI_SLOT(dev->devfn);
     u8 func =3D PCI_FUNC(dev->devfn);
=20
     pos =3D pci_find_cap_offset(seg, bus, slot, func, PCI_CAP_ID_MSI);
     if ( pos )
-    {
-        control =3D pci_conf_read16(seg, bus, slot, func, pos + PCI_MSI_FL=
AGS);
-        control &=3D ~PCI_MSI_FLAGS_ENABLE;
-        if ( enable )
-            control |=3D PCI_MSI_FLAGS_ENABLE;
-        pci_conf_write16(seg, bus, slot, func, pos + PCI_MSI_FLAGS, =
control);
-    }
+        __msi_set_enable(seg, bus, slot, func, pos, enable);
 }
=20
 static void msix_set_enable(struct pci_dev *dev, int enable)
@@ -379,12 +393,12 @@ static int msi_get_mask_bit(const struct
     return -1;
 }
=20
-static void mask_msi_irq(struct irq_desc *desc)
+void mask_msi_irq(struct irq_desc *desc)
 {
     msi_set_mask_bit(desc, 1);
 }
=20
-static void unmask_msi_irq(struct irq_desc *desc)
+void unmask_msi_irq(struct irq_desc *desc)
 {
     msi_set_mask_bit(desc, 0);
 }
@@ -395,7 +409,7 @@ static unsigned int startup_msi_irq(stru
     return 0;
 }
=20
-static void ack_nonmaskable_msi_irq(struct irq_desc *desc)
+void ack_nonmaskable_msi_irq(struct irq_desc *desc)
 {
     irq_complete_move(desc);
     move_native_irq(desc);
@@ -407,7 +421,7 @@ static void ack_maskable_msi_irq(struct=20
     ack_APIC_irq(); /* ACKTYPE_NONE */
 }
=20
-static void end_nonmaskable_msi_irq(struct irq_desc *desc, u8 vector)
+void end_nonmaskable_msi_irq(struct irq_desc *desc, u8 vector)
 {
     ack_APIC_irq(); /* ACKTYPE_EOI */
 }
--- a/xen/drivers/passthrough/amd/iommu_detect.c
+++ b/xen/drivers/passthrough/amd/iommu_detect.c
@@ -31,7 +31,6 @@ static int __init get_iommu_msi_capabili
     u16 seg, u8 bus, u8 dev, u8 func, struct amd_iommu *iommu)
 {
     int pos;
-    u16 control;
=20
     pos =3D pci_find_cap_offset(seg, bus, dev, func, PCI_CAP_ID_MSI);
=20
@@ -41,9 +40,6 @@ static int __init get_iommu_msi_capabili
     AMD_IOMMU_DEBUG("Found MSI capability block at %#x\n", pos);
=20
     iommu->msi_cap =3D pos;
-    control =3D pci_conf_read16(seg, bus, dev, func,
-                              iommu->msi_cap + PCI_MSI_FLAGS);
-    iommu->maskbit =3D control & PCI_MSI_FLAGS_MASKBIT;
     return 0;
 }
=20
--- a/xen/drivers/passthrough/amd/iommu_init.c
+++ b/xen/drivers/passthrough/amd/iommu_init.c
@@ -467,20 +467,9 @@ static void iommu_msi_set_affinity(struc
         return;
     }
=20
-    memset(&msg, 0, sizeof(msg));=20
-    msg.data =3D MSI_DATA_VECTOR(desc->arch.vector) & 0xff;
-    msg.data |=3D 1 << 14;
-    msg.data |=3D (INT_DELIVERY_MODE !=3D dest_LowestPrio) ?
-        MSI_DATA_DELIVERY_FIXED:
-        MSI_DATA_DELIVERY_LOWPRI;
-
-    msg.address_hi =3D0;
-    msg.address_lo =3D (MSI_ADDRESS_HEADER << (MSI_ADDRESS_HEADER_SHIFT + =
8));=20
-    msg.address_lo |=3D INT_DEST_MODE ? MSI_ADDR_DESTMODE_LOGIC:
-                    MSI_ADDR_DESTMODE_PHYS;
-    msg.address_lo |=3D (INT_DELIVERY_MODE !=3D dest_LowestPrio) ?
-                    MSI_ADDR_REDIRECTION_CPU:
-                    MSI_ADDR_REDIRECTION_LOWPRI;
+    msi_compose_msg(desc, &msg);
+    /* Is this override really needed? */
+    msg.address_lo &=3D ~MSI_ADDR_DEST_ID_MASK;
     msg.address_lo |=3D MSI_ADDR_DEST_ID(dest & 0xff);
=20
     pci_conf_write32(seg, bus, dev, func,
@@ -494,18 +483,8 @@ static void iommu_msi_set_affinity(struc
=20
 static void amd_iommu_msi_enable(struct amd_iommu *iommu, int flag)
 {
-    u16 control;
-    int bus =3D PCI_BUS(iommu->bdf);
-    int dev =3D PCI_SLOT(iommu->bdf);
-    int func =3D PCI_FUNC(iommu->bdf);
-
-    control =3D pci_conf_read16(iommu->seg, bus, dev, func,
-        iommu->msi_cap + PCI_MSI_FLAGS);
-    control &=3D ~PCI_MSI_FLAGS_ENABLE;
-    if ( flag )
-        control |=3D flag;
-    pci_conf_write16(iommu->seg, bus, dev, func,
-        iommu->msi_cap + PCI_MSI_FLAGS, control);
+    __msi_set_enable(iommu->seg, PCI_BUS(iommu->bdf), PCI_SLOT(iommu->bdf)=
,
+                     PCI_FUNC(iommu->bdf), iommu->msi_cap, flag);
 }
=20
 static void iommu_msi_unmask(struct irq_desc *desc)
@@ -513,10 +492,6 @@ static void iommu_msi_unmask(struct irq_
     unsigned long flags;
     struct amd_iommu *iommu =3D desc->action->dev_id;
=20
-    /* FIXME: do not support mask bits at the moment */
-    if ( iommu->maskbit )
-        return;
-
     spin_lock_irqsave(&iommu->lock, flags);
     amd_iommu_msi_enable(iommu, IOMMU_CONTROL_ENABLED);
     spin_unlock_irqrestore(&iommu->lock, flags);
@@ -529,10 +504,6 @@ static void iommu_msi_mask(struct irq_de
=20
     irq_complete_move(desc);
=20
-    /* FIXME: do not support mask bits at the moment */
-    if ( iommu->maskbit )
-        return;
-
     spin_lock_irqsave(&iommu->lock, flags);
     amd_iommu_msi_enable(iommu, IOMMU_CONTROL_DISABLED);
     spin_unlock_irqrestore(&iommu->lock, flags);
@@ -562,6 +533,37 @@ static hw_irq_controller iommu_msi_type=20
     .set_affinity =3D iommu_msi_set_affinity,
 };
=20
+static unsigned int iommu_maskable_msi_startup(struct irq_desc *desc)
+{
+    iommu_msi_unmask(desc);
+    unmask_msi_irq(desc);
+    return 0;
+}
+
+static void iommu_maskable_msi_shutdown(struct irq_desc *desc)
+{
+    mask_msi_irq(desc);
+    iommu_msi_mask(desc);
+}
+
+/*
+ * While the names may appear mismatched, we indeed want to use the non-
+ * maskable flavors here, as we want the ACK to be issued in ->end().
+ */
+#define iommu_maskable_msi_ack ack_nonmaskable_msi_irq
+#define iommu_maskable_msi_end end_nonmaskable_msi_irq
+
+static hw_irq_controller iommu_maskable_msi_type =3D {
+    .typename =3D "IOMMU-M-MSI",
+    .startup =3D iommu_maskable_msi_startup,
+    .shutdown =3D iommu_maskable_msi_shutdown,
+    .enable =3D unmask_msi_irq,
+    .disable =3D mask_msi_irq,
+    .ack =3D iommu_maskable_msi_ack,
+    .end =3D iommu_maskable_msi_end,
+    .set_affinity =3D iommu_msi_set_affinity,
+};
+
 static void parse_event_log_entry(struct amd_iommu *iommu, u32 entry[])
 {
     u16 domain_id, device_id, bdf, cword, flags;
@@ -784,6 +786,7 @@ static void iommu_interrupt_handler(int=20
 static int __init set_iommu_interrupt_handler(struct amd_iommu *iommu)
 {
     int irq, ret;
+    u16 control;
=20
     irq =3D create_irq(NUMA_NO_NODE);
     if ( irq <=3D 0 )
@@ -792,7 +795,11 @@ static int __init set_iommu_interrupt_ha
         return 0;
     }
    =20
-    irq_desc[irq].handler =3D &iommu_msi_type;
+    control =3D pci_conf_read16(iommu->seg, PCI_BUS(iommu->bdf),
+                              PCI_SLOT(iommu->bdf), PCI_FUNC(iommu->bdf),
+                              iommu->msi_cap + PCI_MSI_FLAGS);
+    irq_desc[irq].handler =3D control & PCI_MSI_FLAGS_MASKBIT ?
+                            &iommu_maskable_msi_type : &iommu_msi_type;
     ret =3D request_irq(irq, iommu_interrupt_handler, 0, "amd_iommu", =
iommu);
     if ( ret )
     {
--- a/xen/include/asm-x86/amd-iommu.h
+++ b/xen/include/asm-x86/amd-iommu.h
@@ -83,6 +83,7 @@ struct amd_iommu {
     u16 seg;
     u16 bdf;
     u16 cap_offset;
+    u8 msi_cap;
     iommu_cap_t cap;
=20
     u8 ht_flags;
@@ -101,9 +102,6 @@ struct amd_iommu {
     uint64_t exclusion_base;
     uint64_t exclusion_limit;
=20
-    int msi_cap;
-    int maskbit;
-
     int enabled;
     int irq;
 };
--- a/xen/include/asm-x86/msi.h
+++ b/xen/include/asm-x86/msi.h
@@ -153,18 +153,6 @@ int msi_free_irq(struct msi_desc *entry)
 /*
  * MSI Defined Data Structures
  */
-#define MSI_ADDRESS_HEADER		0xfee
-#define MSI_ADDRESS_HEADER_SHIFT	12
-#define MSI_ADDRESS_HEADER_MASK		0xfff000
-#define MSI_ADDRESS_DEST_ID_MASK	0xfff0000f
-#define MSI_TARGET_CPU_MASK		0xff
-#define MSI_TARGET_CPU_SHIFT		12
-#define MSI_DELIVERY_MODE		0
-#define MSI_LEVEL_MODE			1	/* Edge always assert */
-#define MSI_TRIGGER_MODE		0	/* MSI is edge sensitive =
*/
-#define MSI_PHYSICAL_MODE		0
-#define MSI_LOGICAL_MODE		1
-#define MSI_REDIRECTION_HINT_MODE	0
=20
 struct msg_data {
 #if defined(__LITTLE_ENDIAN_BITFIELD)
@@ -213,5 +201,10 @@ struct msg_address {
 } __attribute__ ((packed));
=20
 void msi_compose_msg(struct irq_desc *, struct msi_msg *);
+void __msi_set_enable(u16 seg, u8 bus, u8 slot, u8 func, int pos, int =
enable);
+void mask_msi_irq(struct irq_desc *);
+void unmask_msi_irq(struct irq_desc *);
+void ack_nonmaskable_msi_irq(struct irq_desc *);
+void end_nonmaskable_msi_irq(struct irq_desc *, u8 vector);
=20
 #endif /* __ASM_MSI_H */



--=__Part53624114.1__=
Content-Type: text/plain; name="amd-iommu-MSI.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="amd-iommu-MSI.patch"

amd iommu: use base platform MSI implementation=0A=0AGiven that here, =
other than for VT-d, the MSI interface gets surfaced=0Athrough a normal =
PCI device, the code should use as much as possible of=0Athe "normal" MSI =
support code.=0A=0AFurther, the code can (and should) follow the "normal" =
MSI code in=0Adistinguishing the maskable and non-maskable cases at the =
IRQ=0Acontroller level rather than checking the respective flag in =
the=0Aindividual actors.=0A=0ASigned-off-by: Jan Beulich <jbeulich@suse.com=
>=0A=0A--- a/xen/arch/x86/msi.c=0A+++ b/xen/arch/x86/msi.c=0A@@ -126,13 =
+126,23 @@ void msi_compose_msg(struct irq_desc *de=0A     unsigned =
dest;=0A     int vector =3D desc->arch.vector;=0A =0A-    if ( cpumask_empt=
y(desc->arch.cpu_mask) ) {=0A+    memset(msg, 0, sizeof(*msg));=0A+    if =
( !cpumask_intersects(desc->arch.cpu_mask, &cpu_online_map) ) {=0A         =
dprintk(XENLOG_ERR,"%s, compose msi message error!!\n", __func__);=0A      =
   return;=0A     }=0A =0A     if ( vector ) {=0A-        dest =3D =
cpu_mask_to_apicid(desc->arch.cpu_mask);=0A+        cpumask_var_t =
mask;=0A+=0A+        if ( alloc_cpumask_var(&mask) )=0A+        {=0A+      =
      cpumask_and(mask, desc->arch.cpu_mask, &cpu_online_map);=0A+         =
   dest =3D cpu_mask_to_apicid(mask);=0A+            free_cpumask_var(mask)=
;=0A+        }=0A+        else=0A+            dest =3D cpu_mask_to_apicid(d=
esc->arch.cpu_mask);=0A =0A         msg->address_hi =3D MSI_ADDR_BASE_HI;=
=0A         msg->address_lo =3D=0A@@ -281,23 +291,27 @@ static void =
set_msi_affinity(struct irq_=0A     write_msi_msg(msi_desc, &msg);=0A }=0A =
=0A+void __msi_set_enable(u16 seg, u8 bus, u8 slot, u8 func, int pos, int =
enable)=0A+{=0A+    u16 control =3D pci_conf_read16(seg, bus, slot, func, =
pos + PCI_MSI_FLAGS);=0A+=0A+    control &=3D ~PCI_MSI_FLAGS_ENABLE;=0A+   =
 if ( enable )=0A+        control |=3D PCI_MSI_FLAGS_ENABLE;=0A+    =
pci_conf_write16(seg, bus, slot, func, pos + PCI_MSI_FLAGS, control);=0A+}=
=0A+=0A static void msi_set_enable(struct pci_dev *dev, int enable)=0A =
{=0A     int pos;=0A-    u16 control, seg =3D dev->seg;=0A+    u16 seg =3D =
dev->seg;=0A     u8 bus =3D dev->bus;=0A     u8 slot =3D PCI_SLOT(dev->devf=
n);=0A     u8 func =3D PCI_FUNC(dev->devfn);=0A =0A     pos =3D pci_find_ca=
p_offset(seg, bus, slot, func, PCI_CAP_ID_MSI);=0A     if ( pos )=0A-    =
{=0A-        control =3D pci_conf_read16(seg, bus, slot, func, pos + =
PCI_MSI_FLAGS);=0A-        control &=3D ~PCI_MSI_FLAGS_ENABLE;=0A-        =
if ( enable )=0A-            control |=3D PCI_MSI_FLAGS_ENABLE;=0A-        =
pci_conf_write16(seg, bus, slot, func, pos + PCI_MSI_FLAGS, control);=0A-  =
  }=0A+        __msi_set_enable(seg, bus, slot, func, pos, enable);=0A =
}=0A =0A static void msix_set_enable(struct pci_dev *dev, int enable)=0A@@ =
-379,12 +393,12 @@ static int msi_get_mask_bit(const struct=0A     return =
-1;=0A }=0A =0A-static void mask_msi_irq(struct irq_desc *desc)=0A+void =
mask_msi_irq(struct irq_desc *desc)=0A {=0A     msi_set_mask_bit(desc, =
1);=0A }=0A =0A-static void unmask_msi_irq(struct irq_desc *desc)=0A+void =
unmask_msi_irq(struct irq_desc *desc)=0A {=0A     msi_set_mask_bit(desc, =
0);=0A }=0A@@ -395,7 +409,7 @@ static unsigned int startup_msi_irq(stru=0A =
    return 0;=0A }=0A =0A-static void ack_nonmaskable_msi_irq(struct =
irq_desc *desc)=0A+void ack_nonmaskable_msi_irq(struct irq_desc *desc)=0A =
{=0A     irq_complete_move(desc);=0A     move_native_irq(desc);=0A@@ =
-407,7 +421,7 @@ static void ack_maskable_msi_irq(struct =0A     ack_APIC_i=
rq(); /* ACKTYPE_NONE */=0A }=0A =0A-static void end_nonmaskable_msi_irq(st=
ruct irq_desc *desc, u8 vector)=0A+void end_nonmaskable_msi_irq(struct =
irq_desc *desc, u8 vector)=0A {=0A     ack_APIC_irq(); /* ACKTYPE_EOI =
*/=0A }=0A--- a/xen/drivers/passthrough/amd/iommu_detect.c=0A+++ b/xen/driv=
ers/passthrough/amd/iommu_detect.c=0A@@ -31,7 +31,6 @@ static int __init =
get_iommu_msi_capabili=0A     u16 seg, u8 bus, u8 dev, u8 func, struct =
amd_iommu *iommu)=0A {=0A     int pos;=0A-    u16 control;=0A =0A     pos =
=3D pci_find_cap_offset(seg, bus, dev, func, PCI_CAP_ID_MSI);=0A =0A@@ =
-41,9 +40,6 @@ static int __init get_iommu_msi_capabili=0A     AMD_IOMMU_DE=
BUG("Found MSI capability block at %#x\n", pos);=0A =0A     iommu->msi_cap =
=3D pos;=0A-    control =3D pci_conf_read16(seg, bus, dev, func,=0A-       =
                       iommu->msi_cap + PCI_MSI_FLAGS);=0A-    iommu->maskb=
it =3D control & PCI_MSI_FLAGS_MASKBIT;=0A     return 0;=0A }=0A =0A--- =
a/xen/drivers/passthrough/amd/iommu_init.c=0A+++ b/xen/drivers/passthrough/=
amd/iommu_init.c=0A@@ -467,20 +467,9 @@ static void iommu_msi_set_affinity(=
struc=0A         return;=0A     }=0A =0A-    memset(&msg, 0, sizeof(msg)); =
=0A-    msg.data =3D MSI_DATA_VECTOR(desc->arch.vector) & 0xff;=0A-    =
msg.data |=3D 1 << 14;=0A-    msg.data |=3D (INT_DELIVERY_MODE !=3D =
dest_LowestPrio) ?=0A-        MSI_DATA_DELIVERY_FIXED:=0A-        =
MSI_DATA_DELIVERY_LOWPRI;=0A-=0A-    msg.address_hi =3D0;=0A-    msg.addres=
s_lo =3D (MSI_ADDRESS_HEADER << (MSI_ADDRESS_HEADER_SHIFT + 8)); =0A-    =
msg.address_lo |=3D INT_DEST_MODE ? MSI_ADDR_DESTMODE_LOGIC:=0A-           =
         MSI_ADDR_DESTMODE_PHYS;=0A-    msg.address_lo |=3D (INT_DELIVERY_M=
ODE !=3D dest_LowestPrio) ?=0A-                    MSI_ADDR_REDIRECTION_CPU=
:=0A-                    MSI_ADDR_REDIRECTION_LOWPRI;=0A+    msi_compose_ms=
g(desc, &msg);=0A+    /* Is this override really needed? */=0A+    =
msg.address_lo &=3D ~MSI_ADDR_DEST_ID_MASK;=0A     msg.address_lo |=3D =
MSI_ADDR_DEST_ID(dest & 0xff);=0A =0A     pci_conf_write32(seg, bus, dev, =
func,=0A@@ -494,18 +483,8 @@ static void iommu_msi_set_affinity(struc=0A =
=0A static void amd_iommu_msi_enable(struct amd_iommu *iommu, int flag)=0A =
{=0A-    u16 control;=0A-    int bus =3D PCI_BUS(iommu->bdf);=0A-    int =
dev =3D PCI_SLOT(iommu->bdf);=0A-    int func =3D PCI_FUNC(iommu->bdf);=0A-=
=0A-    control =3D pci_conf_read16(iommu->seg, bus, dev, func,=0A-        =
iommu->msi_cap + PCI_MSI_FLAGS);=0A-    control &=3D ~PCI_MSI_FLAGS_ENABLE;=
=0A-    if ( flag )=0A-        control |=3D flag;=0A-    pci_conf_write16(i=
ommu->seg, bus, dev, func,=0A-        iommu->msi_cap + PCI_MSI_FLAGS, =
control);=0A+    __msi_set_enable(iommu->seg, PCI_BUS(iommu->bdf), =
PCI_SLOT(iommu->bdf),=0A+                     PCI_FUNC(iommu->bdf), =
iommu->msi_cap, flag);=0A }=0A =0A static void iommu_msi_unmask(struct =
irq_desc *desc)=0A@@ -513,10 +492,6 @@ static void iommu_msi_unmask(struct =
irq_=0A     unsigned long flags;=0A     struct amd_iommu *iommu =3D =
desc->action->dev_id;=0A =0A-    /* FIXME: do not support mask bits at the =
moment */=0A-    if ( iommu->maskbit )=0A-        return;=0A-=0A     =
spin_lock_irqsave(&iommu->lock, flags);=0A     amd_iommu_msi_enable(iommu, =
IOMMU_CONTROL_ENABLED);=0A     spin_unlock_irqrestore(&iommu->lock, =
flags);=0A@@ -529,10 +504,6 @@ static void iommu_msi_mask(struct irq_de=0A =
=0A     irq_complete_move(desc);=0A =0A-    /* FIXME: do not support mask =
bits at the moment */=0A-    if ( iommu->maskbit )=0A-        return;=0A-=
=0A     spin_lock_irqsave(&iommu->lock, flags);=0A     amd_iommu_msi_enable=
(iommu, IOMMU_CONTROL_DISABLED);=0A     spin_unlock_irqrestore(&iommu->lock=
, flags);=0A@@ -562,6 +533,37 @@ static hw_irq_controller iommu_msi_type =
=0A     .set_affinity =3D iommu_msi_set_affinity,=0A };=0A =0A+static =
unsigned int iommu_maskable_msi_startup(struct irq_desc *desc)=0A+{=0A+    =
iommu_msi_unmask(desc);=0A+    unmask_msi_irq(desc);=0A+    return =
0;=0A+}=0A+=0A+static void iommu_maskable_msi_shutdown(struct irq_desc =
*desc)=0A+{=0A+    mask_msi_irq(desc);=0A+    iommu_msi_mask(desc);=0A+}=0A=
+=0A+/*=0A+ * While the names may appear mismatched, we indeed want to use =
the non-=0A+ * maskable flavors here, as we want the ACK to be issued in =
->end().=0A+ */=0A+#define iommu_maskable_msi_ack ack_nonmaskable_msi_irq=
=0A+#define iommu_maskable_msi_end end_nonmaskable_msi_irq=0A+=0A+static =
hw_irq_controller iommu_maskable_msi_type =3D {=0A+    .typename =3D =
"IOMMU-M-MSI",=0A+    .startup =3D iommu_maskable_msi_startup,=0A+    =
.shutdown =3D iommu_maskable_msi_shutdown,=0A+    .enable =3D unmask_msi_ir=
q,=0A+    .disable =3D mask_msi_irq,=0A+    .ack =3D iommu_maskable_msi_ack=
,=0A+    .end =3D iommu_maskable_msi_end,=0A+    .set_affinity =3D =
iommu_msi_set_affinity,=0A+};=0A+=0A static void parse_event_log_entry(stru=
ct amd_iommu *iommu, u32 entry[])=0A {=0A     u16 domain_id, device_id, =
bdf, cword, flags;=0A@@ -784,6 +786,7 @@ static void iommu_interrupt_handle=
r(int =0A static int __init set_iommu_interrupt_handler(struct amd_iommu =
*iommu)=0A {=0A     int irq, ret;=0A+    u16 control;=0A =0A     irq =3D =
create_irq(NUMA_NO_NODE);=0A     if ( irq <=3D 0 )=0A@@ -792,7 +795,11 @@ =
static int __init set_iommu_interrupt_ha=0A         return 0;=0A     }=0A  =
   =0A-    irq_desc[irq].handler =3D &iommu_msi_type;=0A+    control =3D =
pci_conf_read16(iommu->seg, PCI_BUS(iommu->bdf),=0A+                       =
       PCI_SLOT(iommu->bdf), PCI_FUNC(iommu->bdf),=0A+                     =
         iommu->msi_cap + PCI_MSI_FLAGS);=0A+    irq_desc[irq].handler =3D =
control & PCI_MSI_FLAGS_MASKBIT ?=0A+                            &iommu_mas=
kable_msi_type : &iommu_msi_type;=0A     ret =3D request_irq(irq, =
iommu_interrupt_handler, 0, "amd_iommu", iommu);=0A     if ( ret )=0A     =
{=0A--- a/xen/include/asm-x86/amd-iommu.h=0A+++ b/xen/include/asm-x86/amd-i=
ommu.h=0A@@ -83,6 +83,7 @@ struct amd_iommu {=0A     u16 seg;=0A     u16 =
bdf;=0A     u16 cap_offset;=0A+    u8 msi_cap;=0A     iommu_cap_t cap;=0A =
=0A     u8 ht_flags;=0A@@ -101,9 +102,6 @@ struct amd_iommu {=0A     =
uint64_t exclusion_base;=0A     uint64_t exclusion_limit;=0A =0A-    int =
msi_cap;=0A-    int maskbit;=0A-=0A     int enabled;=0A     int irq;=0A =
};=0A--- a/xen/include/asm-x86/msi.h=0A+++ b/xen/include/asm-x86/msi.h=0A@@=
 -153,18 +153,6 @@ int msi_free_irq(struct msi_desc *entry)=0A /*=0A  * =
MSI Defined Data Structures=0A  */=0A-#define MSI_ADDRESS_HEADER		=
0xfee=0A-#define MSI_ADDRESS_HEADER_SHIFT	12=0A-#define MSI_ADDRESS_H=
EADER_MASK		0xfff000=0A-#define MSI_ADDRESS_DEST_ID_MASK	=
0xfff0000f=0A-#define MSI_TARGET_CPU_MASK		0xff=0A-#define =
MSI_TARGET_CPU_SHIFT		12=0A-#define MSI_DELIVERY_MODE		=
0=0A-#define MSI_LEVEL_MODE			1	/* Edge always =
assert */=0A-#define MSI_TRIGGER_MODE		0	/* MSI is edge =
sensitive */=0A-#define MSI_PHYSICAL_MODE		0=0A-#define =
MSI_LOGICAL_MODE		1=0A-#define MSI_REDIRECTION_HINT_MODE	=
0=0A =0A struct msg_data {=0A #if defined(__LITTLE_ENDIAN_BITFIELD)=0A@@ =
-213,5 +201,10 @@ struct msg_address {=0A } __attribute__ ((packed));=0A =
=0A void msi_compose_msg(struct irq_desc *, struct msi_msg *);=0A+void =
__msi_set_enable(u16 seg, u8 bus, u8 slot, u8 func, int pos, int =
enable);=0A+void mask_msi_irq(struct irq_desc *);=0A+void unmask_msi_irq(st=
ruct irq_desc *);=0A+void ack_nonmaskable_msi_irq(struct irq_desc =
*);=0A+void end_nonmaskable_msi_irq(struct irq_desc *, u8 vector);=0A =0A =
#endif /* __ASM_MSI_H */=0A
--=__Part53624114.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

--=__Part53624114.1__=--


From xen-devel-bounces@lists.xen.org Tue Sep 11 12:37:19 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 2012 12:37: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 1TBPiA-0000JH-Uq; Tue, 11 Sep 2012 12:37:02 +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 1TBPi8-0000IB-Iz
	for xen-devel@lists.xen.org; Tue, 11 Sep 2012 12:37:01 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1347366919!9979361!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQwNzc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5890 invoked from network); 11 Sep 2012 12:35:19 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-4.tower-27.messagelabs.com with SMTP;
	11 Sep 2012 12:35:19 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 11 Sep 2012 13:35:19 +0100
Message-Id: <504F4C24020000780009A968@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 11 Sep 2012 13:35:16 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part53624114.1__="
Cc: Wei Wang <wei.wang2@amd.com>
Subject: [Xen-devel] [PATCH 2/3] amd iommu: use base platform MSI
	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

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.

--=__Part53624114.1__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Given that here, other than for VT-d, the MSI interface gets surfaced
through a normal PCI device, the code should use as much as possible of
the "normal" MSI support code.

Further, the code can (and should) follow the "normal" MSI code in
distinguishing the maskable and non-maskable cases at the IRQ
controller level rather than checking the respective flag in the
individual actors.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/arch/x86/msi.c
+++ b/xen/arch/x86/msi.c
@@ -126,13 +126,23 @@ void msi_compose_msg(struct irq_desc *de
     unsigned dest;
     int vector =3D desc->arch.vector;
=20
-    if ( cpumask_empty(desc->arch.cpu_mask) ) {
+    memset(msg, 0, sizeof(*msg));
+    if ( !cpumask_intersects(desc->arch.cpu_mask, &cpu_online_map) ) {
         dprintk(XENLOG_ERR,"%s, compose msi message error!!\n", __func__);=

         return;
     }
=20
     if ( vector ) {
-        dest =3D cpu_mask_to_apicid(desc->arch.cpu_mask);
+        cpumask_var_t mask;
+
+        if ( alloc_cpumask_var(&mask) )
+        {
+            cpumask_and(mask, desc->arch.cpu_mask, &cpu_online_map);
+            dest =3D cpu_mask_to_apicid(mask);
+            free_cpumask_var(mask);
+        }
+        else
+            dest =3D cpu_mask_to_apicid(desc->arch.cpu_mask);
=20
         msg->address_hi =3D MSI_ADDR_BASE_HI;
         msg->address_lo =3D
@@ -281,23 +291,27 @@ static void set_msi_affinity(struct irq_
     write_msi_msg(msi_desc, &msg);
 }
=20
+void __msi_set_enable(u16 seg, u8 bus, u8 slot, u8 func, int pos, int =
enable)
+{
+    u16 control =3D pci_conf_read16(seg, bus, slot, func, pos + PCI_MSI_FL=
AGS);
+
+    control &=3D ~PCI_MSI_FLAGS_ENABLE;
+    if ( enable )
+        control |=3D PCI_MSI_FLAGS_ENABLE;
+    pci_conf_write16(seg, bus, slot, func, pos + PCI_MSI_FLAGS, control);
+}
+
 static void msi_set_enable(struct pci_dev *dev, int enable)
 {
     int pos;
-    u16 control, seg =3D dev->seg;
+    u16 seg =3D dev->seg;
     u8 bus =3D dev->bus;
     u8 slot =3D PCI_SLOT(dev->devfn);
     u8 func =3D PCI_FUNC(dev->devfn);
=20
     pos =3D pci_find_cap_offset(seg, bus, slot, func, PCI_CAP_ID_MSI);
     if ( pos )
-    {
-        control =3D pci_conf_read16(seg, bus, slot, func, pos + PCI_MSI_FL=
AGS);
-        control &=3D ~PCI_MSI_FLAGS_ENABLE;
-        if ( enable )
-            control |=3D PCI_MSI_FLAGS_ENABLE;
-        pci_conf_write16(seg, bus, slot, func, pos + PCI_MSI_FLAGS, =
control);
-    }
+        __msi_set_enable(seg, bus, slot, func, pos, enable);
 }
=20
 static void msix_set_enable(struct pci_dev *dev, int enable)
@@ -379,12 +393,12 @@ static int msi_get_mask_bit(const struct
     return -1;
 }
=20
-static void mask_msi_irq(struct irq_desc *desc)
+void mask_msi_irq(struct irq_desc *desc)
 {
     msi_set_mask_bit(desc, 1);
 }
=20
-static void unmask_msi_irq(struct irq_desc *desc)
+void unmask_msi_irq(struct irq_desc *desc)
 {
     msi_set_mask_bit(desc, 0);
 }
@@ -395,7 +409,7 @@ static unsigned int startup_msi_irq(stru
     return 0;
 }
=20
-static void ack_nonmaskable_msi_irq(struct irq_desc *desc)
+void ack_nonmaskable_msi_irq(struct irq_desc *desc)
 {
     irq_complete_move(desc);
     move_native_irq(desc);
@@ -407,7 +421,7 @@ static void ack_maskable_msi_irq(struct=20
     ack_APIC_irq(); /* ACKTYPE_NONE */
 }
=20
-static void end_nonmaskable_msi_irq(struct irq_desc *desc, u8 vector)
+void end_nonmaskable_msi_irq(struct irq_desc *desc, u8 vector)
 {
     ack_APIC_irq(); /* ACKTYPE_EOI */
 }
--- a/xen/drivers/passthrough/amd/iommu_detect.c
+++ b/xen/drivers/passthrough/amd/iommu_detect.c
@@ -31,7 +31,6 @@ static int __init get_iommu_msi_capabili
     u16 seg, u8 bus, u8 dev, u8 func, struct amd_iommu *iommu)
 {
     int pos;
-    u16 control;
=20
     pos =3D pci_find_cap_offset(seg, bus, dev, func, PCI_CAP_ID_MSI);
=20
@@ -41,9 +40,6 @@ static int __init get_iommu_msi_capabili
     AMD_IOMMU_DEBUG("Found MSI capability block at %#x\n", pos);
=20
     iommu->msi_cap =3D pos;
-    control =3D pci_conf_read16(seg, bus, dev, func,
-                              iommu->msi_cap + PCI_MSI_FLAGS);
-    iommu->maskbit =3D control & PCI_MSI_FLAGS_MASKBIT;
     return 0;
 }
=20
--- a/xen/drivers/passthrough/amd/iommu_init.c
+++ b/xen/drivers/passthrough/amd/iommu_init.c
@@ -467,20 +467,9 @@ static void iommu_msi_set_affinity(struc
         return;
     }
=20
-    memset(&msg, 0, sizeof(msg));=20
-    msg.data =3D MSI_DATA_VECTOR(desc->arch.vector) & 0xff;
-    msg.data |=3D 1 << 14;
-    msg.data |=3D (INT_DELIVERY_MODE !=3D dest_LowestPrio) ?
-        MSI_DATA_DELIVERY_FIXED:
-        MSI_DATA_DELIVERY_LOWPRI;
-
-    msg.address_hi =3D0;
-    msg.address_lo =3D (MSI_ADDRESS_HEADER << (MSI_ADDRESS_HEADER_SHIFT + =
8));=20
-    msg.address_lo |=3D INT_DEST_MODE ? MSI_ADDR_DESTMODE_LOGIC:
-                    MSI_ADDR_DESTMODE_PHYS;
-    msg.address_lo |=3D (INT_DELIVERY_MODE !=3D dest_LowestPrio) ?
-                    MSI_ADDR_REDIRECTION_CPU:
-                    MSI_ADDR_REDIRECTION_LOWPRI;
+    msi_compose_msg(desc, &msg);
+    /* Is this override really needed? */
+    msg.address_lo &=3D ~MSI_ADDR_DEST_ID_MASK;
     msg.address_lo |=3D MSI_ADDR_DEST_ID(dest & 0xff);
=20
     pci_conf_write32(seg, bus, dev, func,
@@ -494,18 +483,8 @@ static void iommu_msi_set_affinity(struc
=20
 static void amd_iommu_msi_enable(struct amd_iommu *iommu, int flag)
 {
-    u16 control;
-    int bus =3D PCI_BUS(iommu->bdf);
-    int dev =3D PCI_SLOT(iommu->bdf);
-    int func =3D PCI_FUNC(iommu->bdf);
-
-    control =3D pci_conf_read16(iommu->seg, bus, dev, func,
-        iommu->msi_cap + PCI_MSI_FLAGS);
-    control &=3D ~PCI_MSI_FLAGS_ENABLE;
-    if ( flag )
-        control |=3D flag;
-    pci_conf_write16(iommu->seg, bus, dev, func,
-        iommu->msi_cap + PCI_MSI_FLAGS, control);
+    __msi_set_enable(iommu->seg, PCI_BUS(iommu->bdf), PCI_SLOT(iommu->bdf)=
,
+                     PCI_FUNC(iommu->bdf), iommu->msi_cap, flag);
 }
=20
 static void iommu_msi_unmask(struct irq_desc *desc)
@@ -513,10 +492,6 @@ static void iommu_msi_unmask(struct irq_
     unsigned long flags;
     struct amd_iommu *iommu =3D desc->action->dev_id;
=20
-    /* FIXME: do not support mask bits at the moment */
-    if ( iommu->maskbit )
-        return;
-
     spin_lock_irqsave(&iommu->lock, flags);
     amd_iommu_msi_enable(iommu, IOMMU_CONTROL_ENABLED);
     spin_unlock_irqrestore(&iommu->lock, flags);
@@ -529,10 +504,6 @@ static void iommu_msi_mask(struct irq_de
=20
     irq_complete_move(desc);
=20
-    /* FIXME: do not support mask bits at the moment */
-    if ( iommu->maskbit )
-        return;
-
     spin_lock_irqsave(&iommu->lock, flags);
     amd_iommu_msi_enable(iommu, IOMMU_CONTROL_DISABLED);
     spin_unlock_irqrestore(&iommu->lock, flags);
@@ -562,6 +533,37 @@ static hw_irq_controller iommu_msi_type=20
     .set_affinity =3D iommu_msi_set_affinity,
 };
=20
+static unsigned int iommu_maskable_msi_startup(struct irq_desc *desc)
+{
+    iommu_msi_unmask(desc);
+    unmask_msi_irq(desc);
+    return 0;
+}
+
+static void iommu_maskable_msi_shutdown(struct irq_desc *desc)
+{
+    mask_msi_irq(desc);
+    iommu_msi_mask(desc);
+}
+
+/*
+ * While the names may appear mismatched, we indeed want to use the non-
+ * maskable flavors here, as we want the ACK to be issued in ->end().
+ */
+#define iommu_maskable_msi_ack ack_nonmaskable_msi_irq
+#define iommu_maskable_msi_end end_nonmaskable_msi_irq
+
+static hw_irq_controller iommu_maskable_msi_type =3D {
+    .typename =3D "IOMMU-M-MSI",
+    .startup =3D iommu_maskable_msi_startup,
+    .shutdown =3D iommu_maskable_msi_shutdown,
+    .enable =3D unmask_msi_irq,
+    .disable =3D mask_msi_irq,
+    .ack =3D iommu_maskable_msi_ack,
+    .end =3D iommu_maskable_msi_end,
+    .set_affinity =3D iommu_msi_set_affinity,
+};
+
 static void parse_event_log_entry(struct amd_iommu *iommu, u32 entry[])
 {
     u16 domain_id, device_id, bdf, cword, flags;
@@ -784,6 +786,7 @@ static void iommu_interrupt_handler(int=20
 static int __init set_iommu_interrupt_handler(struct amd_iommu *iommu)
 {
     int irq, ret;
+    u16 control;
=20
     irq =3D create_irq(NUMA_NO_NODE);
     if ( irq <=3D 0 )
@@ -792,7 +795,11 @@ static int __init set_iommu_interrupt_ha
         return 0;
     }
    =20
-    irq_desc[irq].handler =3D &iommu_msi_type;
+    control =3D pci_conf_read16(iommu->seg, PCI_BUS(iommu->bdf),
+                              PCI_SLOT(iommu->bdf), PCI_FUNC(iommu->bdf),
+                              iommu->msi_cap + PCI_MSI_FLAGS);
+    irq_desc[irq].handler =3D control & PCI_MSI_FLAGS_MASKBIT ?
+                            &iommu_maskable_msi_type : &iommu_msi_type;
     ret =3D request_irq(irq, iommu_interrupt_handler, 0, "amd_iommu", =
iommu);
     if ( ret )
     {
--- a/xen/include/asm-x86/amd-iommu.h
+++ b/xen/include/asm-x86/amd-iommu.h
@@ -83,6 +83,7 @@ struct amd_iommu {
     u16 seg;
     u16 bdf;
     u16 cap_offset;
+    u8 msi_cap;
     iommu_cap_t cap;
=20
     u8 ht_flags;
@@ -101,9 +102,6 @@ struct amd_iommu {
     uint64_t exclusion_base;
     uint64_t exclusion_limit;
=20
-    int msi_cap;
-    int maskbit;
-
     int enabled;
     int irq;
 };
--- a/xen/include/asm-x86/msi.h
+++ b/xen/include/asm-x86/msi.h
@@ -153,18 +153,6 @@ int msi_free_irq(struct msi_desc *entry)
 /*
  * MSI Defined Data Structures
  */
-#define MSI_ADDRESS_HEADER		0xfee
-#define MSI_ADDRESS_HEADER_SHIFT	12
-#define MSI_ADDRESS_HEADER_MASK		0xfff000
-#define MSI_ADDRESS_DEST_ID_MASK	0xfff0000f
-#define MSI_TARGET_CPU_MASK		0xff
-#define MSI_TARGET_CPU_SHIFT		12
-#define MSI_DELIVERY_MODE		0
-#define MSI_LEVEL_MODE			1	/* Edge always assert */
-#define MSI_TRIGGER_MODE		0	/* MSI is edge sensitive =
*/
-#define MSI_PHYSICAL_MODE		0
-#define MSI_LOGICAL_MODE		1
-#define MSI_REDIRECTION_HINT_MODE	0
=20
 struct msg_data {
 #if defined(__LITTLE_ENDIAN_BITFIELD)
@@ -213,5 +201,10 @@ struct msg_address {
 } __attribute__ ((packed));
=20
 void msi_compose_msg(struct irq_desc *, struct msi_msg *);
+void __msi_set_enable(u16 seg, u8 bus, u8 slot, u8 func, int pos, int =
enable);
+void mask_msi_irq(struct irq_desc *);
+void unmask_msi_irq(struct irq_desc *);
+void ack_nonmaskable_msi_irq(struct irq_desc *);
+void end_nonmaskable_msi_irq(struct irq_desc *, u8 vector);
=20
 #endif /* __ASM_MSI_H */



--=__Part53624114.1__=
Content-Type: text/plain; name="amd-iommu-MSI.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="amd-iommu-MSI.patch"

amd iommu: use base platform MSI implementation=0A=0AGiven that here, =
other than for VT-d, the MSI interface gets surfaced=0Athrough a normal =
PCI device, the code should use as much as possible of=0Athe "normal" MSI =
support code.=0A=0AFurther, the code can (and should) follow the "normal" =
MSI code in=0Adistinguishing the maskable and non-maskable cases at the =
IRQ=0Acontroller level rather than checking the respective flag in =
the=0Aindividual actors.=0A=0ASigned-off-by: Jan Beulich <jbeulich@suse.com=
>=0A=0A--- a/xen/arch/x86/msi.c=0A+++ b/xen/arch/x86/msi.c=0A@@ -126,13 =
+126,23 @@ void msi_compose_msg(struct irq_desc *de=0A     unsigned =
dest;=0A     int vector =3D desc->arch.vector;=0A =0A-    if ( cpumask_empt=
y(desc->arch.cpu_mask) ) {=0A+    memset(msg, 0, sizeof(*msg));=0A+    if =
( !cpumask_intersects(desc->arch.cpu_mask, &cpu_online_map) ) {=0A         =
dprintk(XENLOG_ERR,"%s, compose msi message error!!\n", __func__);=0A      =
   return;=0A     }=0A =0A     if ( vector ) {=0A-        dest =3D =
cpu_mask_to_apicid(desc->arch.cpu_mask);=0A+        cpumask_var_t =
mask;=0A+=0A+        if ( alloc_cpumask_var(&mask) )=0A+        {=0A+      =
      cpumask_and(mask, desc->arch.cpu_mask, &cpu_online_map);=0A+         =
   dest =3D cpu_mask_to_apicid(mask);=0A+            free_cpumask_var(mask)=
;=0A+        }=0A+        else=0A+            dest =3D cpu_mask_to_apicid(d=
esc->arch.cpu_mask);=0A =0A         msg->address_hi =3D MSI_ADDR_BASE_HI;=
=0A         msg->address_lo =3D=0A@@ -281,23 +291,27 @@ static void =
set_msi_affinity(struct irq_=0A     write_msi_msg(msi_desc, &msg);=0A }=0A =
=0A+void __msi_set_enable(u16 seg, u8 bus, u8 slot, u8 func, int pos, int =
enable)=0A+{=0A+    u16 control =3D pci_conf_read16(seg, bus, slot, func, =
pos + PCI_MSI_FLAGS);=0A+=0A+    control &=3D ~PCI_MSI_FLAGS_ENABLE;=0A+   =
 if ( enable )=0A+        control |=3D PCI_MSI_FLAGS_ENABLE;=0A+    =
pci_conf_write16(seg, bus, slot, func, pos + PCI_MSI_FLAGS, control);=0A+}=
=0A+=0A static void msi_set_enable(struct pci_dev *dev, int enable)=0A =
{=0A     int pos;=0A-    u16 control, seg =3D dev->seg;=0A+    u16 seg =3D =
dev->seg;=0A     u8 bus =3D dev->bus;=0A     u8 slot =3D PCI_SLOT(dev->devf=
n);=0A     u8 func =3D PCI_FUNC(dev->devfn);=0A =0A     pos =3D pci_find_ca=
p_offset(seg, bus, slot, func, PCI_CAP_ID_MSI);=0A     if ( pos )=0A-    =
{=0A-        control =3D pci_conf_read16(seg, bus, slot, func, pos + =
PCI_MSI_FLAGS);=0A-        control &=3D ~PCI_MSI_FLAGS_ENABLE;=0A-        =
if ( enable )=0A-            control |=3D PCI_MSI_FLAGS_ENABLE;=0A-        =
pci_conf_write16(seg, bus, slot, func, pos + PCI_MSI_FLAGS, control);=0A-  =
  }=0A+        __msi_set_enable(seg, bus, slot, func, pos, enable);=0A =
}=0A =0A static void msix_set_enable(struct pci_dev *dev, int enable)=0A@@ =
-379,12 +393,12 @@ static int msi_get_mask_bit(const struct=0A     return =
-1;=0A }=0A =0A-static void mask_msi_irq(struct irq_desc *desc)=0A+void =
mask_msi_irq(struct irq_desc *desc)=0A {=0A     msi_set_mask_bit(desc, =
1);=0A }=0A =0A-static void unmask_msi_irq(struct irq_desc *desc)=0A+void =
unmask_msi_irq(struct irq_desc *desc)=0A {=0A     msi_set_mask_bit(desc, =
0);=0A }=0A@@ -395,7 +409,7 @@ static unsigned int startup_msi_irq(stru=0A =
    return 0;=0A }=0A =0A-static void ack_nonmaskable_msi_irq(struct =
irq_desc *desc)=0A+void ack_nonmaskable_msi_irq(struct irq_desc *desc)=0A =
{=0A     irq_complete_move(desc);=0A     move_native_irq(desc);=0A@@ =
-407,7 +421,7 @@ static void ack_maskable_msi_irq(struct =0A     ack_APIC_i=
rq(); /* ACKTYPE_NONE */=0A }=0A =0A-static void end_nonmaskable_msi_irq(st=
ruct irq_desc *desc, u8 vector)=0A+void end_nonmaskable_msi_irq(struct =
irq_desc *desc, u8 vector)=0A {=0A     ack_APIC_irq(); /* ACKTYPE_EOI =
*/=0A }=0A--- a/xen/drivers/passthrough/amd/iommu_detect.c=0A+++ b/xen/driv=
ers/passthrough/amd/iommu_detect.c=0A@@ -31,7 +31,6 @@ static int __init =
get_iommu_msi_capabili=0A     u16 seg, u8 bus, u8 dev, u8 func, struct =
amd_iommu *iommu)=0A {=0A     int pos;=0A-    u16 control;=0A =0A     pos =
=3D pci_find_cap_offset(seg, bus, dev, func, PCI_CAP_ID_MSI);=0A =0A@@ =
-41,9 +40,6 @@ static int __init get_iommu_msi_capabili=0A     AMD_IOMMU_DE=
BUG("Found MSI capability block at %#x\n", pos);=0A =0A     iommu->msi_cap =
=3D pos;=0A-    control =3D pci_conf_read16(seg, bus, dev, func,=0A-       =
                       iommu->msi_cap + PCI_MSI_FLAGS);=0A-    iommu->maskb=
it =3D control & PCI_MSI_FLAGS_MASKBIT;=0A     return 0;=0A }=0A =0A--- =
a/xen/drivers/passthrough/amd/iommu_init.c=0A+++ b/xen/drivers/passthrough/=
amd/iommu_init.c=0A@@ -467,20 +467,9 @@ static void iommu_msi_set_affinity(=
struc=0A         return;=0A     }=0A =0A-    memset(&msg, 0, sizeof(msg)); =
=0A-    msg.data =3D MSI_DATA_VECTOR(desc->arch.vector) & 0xff;=0A-    =
msg.data |=3D 1 << 14;=0A-    msg.data |=3D (INT_DELIVERY_MODE !=3D =
dest_LowestPrio) ?=0A-        MSI_DATA_DELIVERY_FIXED:=0A-        =
MSI_DATA_DELIVERY_LOWPRI;=0A-=0A-    msg.address_hi =3D0;=0A-    msg.addres=
s_lo =3D (MSI_ADDRESS_HEADER << (MSI_ADDRESS_HEADER_SHIFT + 8)); =0A-    =
msg.address_lo |=3D INT_DEST_MODE ? MSI_ADDR_DESTMODE_LOGIC:=0A-           =
         MSI_ADDR_DESTMODE_PHYS;=0A-    msg.address_lo |=3D (INT_DELIVERY_M=
ODE !=3D dest_LowestPrio) ?=0A-                    MSI_ADDR_REDIRECTION_CPU=
:=0A-                    MSI_ADDR_REDIRECTION_LOWPRI;=0A+    msi_compose_ms=
g(desc, &msg);=0A+    /* Is this override really needed? */=0A+    =
msg.address_lo &=3D ~MSI_ADDR_DEST_ID_MASK;=0A     msg.address_lo |=3D =
MSI_ADDR_DEST_ID(dest & 0xff);=0A =0A     pci_conf_write32(seg, bus, dev, =
func,=0A@@ -494,18 +483,8 @@ static void iommu_msi_set_affinity(struc=0A =
=0A static void amd_iommu_msi_enable(struct amd_iommu *iommu, int flag)=0A =
{=0A-    u16 control;=0A-    int bus =3D PCI_BUS(iommu->bdf);=0A-    int =
dev =3D PCI_SLOT(iommu->bdf);=0A-    int func =3D PCI_FUNC(iommu->bdf);=0A-=
=0A-    control =3D pci_conf_read16(iommu->seg, bus, dev, func,=0A-        =
iommu->msi_cap + PCI_MSI_FLAGS);=0A-    control &=3D ~PCI_MSI_FLAGS_ENABLE;=
=0A-    if ( flag )=0A-        control |=3D flag;=0A-    pci_conf_write16(i=
ommu->seg, bus, dev, func,=0A-        iommu->msi_cap + PCI_MSI_FLAGS, =
control);=0A+    __msi_set_enable(iommu->seg, PCI_BUS(iommu->bdf), =
PCI_SLOT(iommu->bdf),=0A+                     PCI_FUNC(iommu->bdf), =
iommu->msi_cap, flag);=0A }=0A =0A static void iommu_msi_unmask(struct =
irq_desc *desc)=0A@@ -513,10 +492,6 @@ static void iommu_msi_unmask(struct =
irq_=0A     unsigned long flags;=0A     struct amd_iommu *iommu =3D =
desc->action->dev_id;=0A =0A-    /* FIXME: do not support mask bits at the =
moment */=0A-    if ( iommu->maskbit )=0A-        return;=0A-=0A     =
spin_lock_irqsave(&iommu->lock, flags);=0A     amd_iommu_msi_enable(iommu, =
IOMMU_CONTROL_ENABLED);=0A     spin_unlock_irqrestore(&iommu->lock, =
flags);=0A@@ -529,10 +504,6 @@ static void iommu_msi_mask(struct irq_de=0A =
=0A     irq_complete_move(desc);=0A =0A-    /* FIXME: do not support mask =
bits at the moment */=0A-    if ( iommu->maskbit )=0A-        return;=0A-=
=0A     spin_lock_irqsave(&iommu->lock, flags);=0A     amd_iommu_msi_enable=
(iommu, IOMMU_CONTROL_DISABLED);=0A     spin_unlock_irqrestore(&iommu->lock=
, flags);=0A@@ -562,6 +533,37 @@ static hw_irq_controller iommu_msi_type =
=0A     .set_affinity =3D iommu_msi_set_affinity,=0A };=0A =0A+static =
unsigned int iommu_maskable_msi_startup(struct irq_desc *desc)=0A+{=0A+    =
iommu_msi_unmask(desc);=0A+    unmask_msi_irq(desc);=0A+    return =
0;=0A+}=0A+=0A+static void iommu_maskable_msi_shutdown(struct irq_desc =
*desc)=0A+{=0A+    mask_msi_irq(desc);=0A+    iommu_msi_mask(desc);=0A+}=0A=
+=0A+/*=0A+ * While the names may appear mismatched, we indeed want to use =
the non-=0A+ * maskable flavors here, as we want the ACK to be issued in =
->end().=0A+ */=0A+#define iommu_maskable_msi_ack ack_nonmaskable_msi_irq=
=0A+#define iommu_maskable_msi_end end_nonmaskable_msi_irq=0A+=0A+static =
hw_irq_controller iommu_maskable_msi_type =3D {=0A+    .typename =3D =
"IOMMU-M-MSI",=0A+    .startup =3D iommu_maskable_msi_startup,=0A+    =
.shutdown =3D iommu_maskable_msi_shutdown,=0A+    .enable =3D unmask_msi_ir=
q,=0A+    .disable =3D mask_msi_irq,=0A+    .ack =3D iommu_maskable_msi_ack=
,=0A+    .end =3D iommu_maskable_msi_end,=0A+    .set_affinity =3D =
iommu_msi_set_affinity,=0A+};=0A+=0A static void parse_event_log_entry(stru=
ct amd_iommu *iommu, u32 entry[])=0A {=0A     u16 domain_id, device_id, =
bdf, cword, flags;=0A@@ -784,6 +786,7 @@ static void iommu_interrupt_handle=
r(int =0A static int __init set_iommu_interrupt_handler(struct amd_iommu =
*iommu)=0A {=0A     int irq, ret;=0A+    u16 control;=0A =0A     irq =3D =
create_irq(NUMA_NO_NODE);=0A     if ( irq <=3D 0 )=0A@@ -792,7 +795,11 @@ =
static int __init set_iommu_interrupt_ha=0A         return 0;=0A     }=0A  =
   =0A-    irq_desc[irq].handler =3D &iommu_msi_type;=0A+    control =3D =
pci_conf_read16(iommu->seg, PCI_BUS(iommu->bdf),=0A+                       =
       PCI_SLOT(iommu->bdf), PCI_FUNC(iommu->bdf),=0A+                     =
         iommu->msi_cap + PCI_MSI_FLAGS);=0A+    irq_desc[irq].handler =3D =
control & PCI_MSI_FLAGS_MASKBIT ?=0A+                            &iommu_mas=
kable_msi_type : &iommu_msi_type;=0A     ret =3D request_irq(irq, =
iommu_interrupt_handler, 0, "amd_iommu", iommu);=0A     if ( ret )=0A     =
{=0A--- a/xen/include/asm-x86/amd-iommu.h=0A+++ b/xen/include/asm-x86/amd-i=
ommu.h=0A@@ -83,6 +83,7 @@ struct amd_iommu {=0A     u16 seg;=0A     u16 =
bdf;=0A     u16 cap_offset;=0A+    u8 msi_cap;=0A     iommu_cap_t cap;=0A =
=0A     u8 ht_flags;=0A@@ -101,9 +102,6 @@ struct amd_iommu {=0A     =
uint64_t exclusion_base;=0A     uint64_t exclusion_limit;=0A =0A-    int =
msi_cap;=0A-    int maskbit;=0A-=0A     int enabled;=0A     int irq;=0A =
};=0A--- a/xen/include/asm-x86/msi.h=0A+++ b/xen/include/asm-x86/msi.h=0A@@=
 -153,18 +153,6 @@ int msi_free_irq(struct msi_desc *entry)=0A /*=0A  * =
MSI Defined Data Structures=0A  */=0A-#define MSI_ADDRESS_HEADER		=
0xfee=0A-#define MSI_ADDRESS_HEADER_SHIFT	12=0A-#define MSI_ADDRESS_H=
EADER_MASK		0xfff000=0A-#define MSI_ADDRESS_DEST_ID_MASK	=
0xfff0000f=0A-#define MSI_TARGET_CPU_MASK		0xff=0A-#define =
MSI_TARGET_CPU_SHIFT		12=0A-#define MSI_DELIVERY_MODE		=
0=0A-#define MSI_LEVEL_MODE			1	/* Edge always =
assert */=0A-#define MSI_TRIGGER_MODE		0	/* MSI is edge =
sensitive */=0A-#define MSI_PHYSICAL_MODE		0=0A-#define =
MSI_LOGICAL_MODE		1=0A-#define MSI_REDIRECTION_HINT_MODE	=
0=0A =0A struct msg_data {=0A #if defined(__LITTLE_ENDIAN_BITFIELD)=0A@@ =
-213,5 +201,10 @@ struct msg_address {=0A } __attribute__ ((packed));=0A =
=0A void msi_compose_msg(struct irq_desc *, struct msi_msg *);=0A+void =
__msi_set_enable(u16 seg, u8 bus, u8 slot, u8 func, int pos, int =
enable);=0A+void mask_msi_irq(struct irq_desc *);=0A+void unmask_msi_irq(st=
ruct irq_desc *);=0A+void ack_nonmaskable_msi_irq(struct irq_desc =
*);=0A+void end_nonmaskable_msi_irq(struct irq_desc *, u8 vector);=0A =0A =
#endif /* __ASM_MSI_H */=0A
--=__Part53624114.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

--=__Part53624114.1__=--


From xen-devel-bounces@lists.xen.org Tue Sep 11 12:47:34 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 2012 12: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 1TBPs6-0000ew-2W; Tue, 11 Sep 2012 12:47:18 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1TBPs4-0000er-MX
	for xen-devel@lists.xen.org; Tue, 11 Sep 2012 12:47:16 +0000
Received: from [85.158.143.35:20065] by server-1.bemta-4.messagelabs.com id
	33/20-12504-3D23F405; Tue, 11 Sep 2012 12:47:15 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1347367595!6688702!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQwNzc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13502 invoked from network); 11 Sep 2012 12:46:36 -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;
	11 Sep 2012 12:46:36 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 11 Sep 2012 13:46:35 +0100
Message-Id: <504F4EC8020000780009A993@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 11 Sep 2012 13:46:32 +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 0/3] x86/hvm: miscellaneous 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

1: don't use indirect calls without need
2: constify static data where possible
3: mark save/restore registration code __init

Signed-off-by: Jan Beulich <jbeulich@suse.com>


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 11 12:47:34 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 2012 12: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 1TBPs6-0000ew-2W; Tue, 11 Sep 2012 12:47:18 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1TBPs4-0000er-MX
	for xen-devel@lists.xen.org; Tue, 11 Sep 2012 12:47:16 +0000
Received: from [85.158.143.35:20065] by server-1.bemta-4.messagelabs.com id
	33/20-12504-3D23F405; Tue, 11 Sep 2012 12:47:15 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1347367595!6688702!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQwNzc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13502 invoked from network); 11 Sep 2012 12:46:36 -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;
	11 Sep 2012 12:46:36 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 11 Sep 2012 13:46:35 +0100
Message-Id: <504F4EC8020000780009A993@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 11 Sep 2012 13:46:32 +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 0/3] x86/hvm: miscellaneous 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

1: don't use indirect calls without need
2: constify static data where possible
3: mark save/restore registration code __init

Signed-off-by: Jan Beulich <jbeulich@suse.com>


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 11 12:47:54 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 2012 12: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 1TBPsT-0000gl-Fl; Tue, 11 Sep 2012 12:47:41 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1TBPsS-0000gY-34
	for xen-devel@lists.xen.org; Tue, 11 Sep 2012 12:47:40 +0000
Received: from [85.158.143.35:36164] by server-3.bemta-4.messagelabs.com id
	2A/B8-08232-BE23F405; Tue, 11 Sep 2012 12:47:39 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1347367647!12570720!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQwNzc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27171 invoked from network); 11 Sep 2012 12:47:28 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-11.tower-21.messagelabs.com with SMTP;
	11 Sep 2012 12:47:28 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 11 Sep 2012 13:47:27 +0100
Message-Id: <504F4EFB020000780009A997@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 11 Sep 2012 13:47:23 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part8EBF9CCB.0__="
Subject: [Xen-devel] [PATCH 1/3] x86/hvm: don't use indirect calls without
	need
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<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.

--=__Part8EBF9CCB.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Direct calls perform better, so we should prefer them and use indirect
ones only when there indeed is a need for indirection.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/arch/x86/apic.c
+++ b/xen/arch/x86/apic.c
@@ -1373,7 +1373,7 @@ void error_interrupt(struct cpu_user_reg
 void pmu_apic_interrupt(struct cpu_user_regs *regs)
 {
     ack_APIC_irq();
-    hvm_do_pmu_interrupt(regs);
+    vpmu_do_interrupt(regs);
 }
=20
 /*
--- a/xen/arch/x86/hvm/svm/svm.c
+++ b/xen/arch/x86/hvm/svm/svm.c
@@ -73,6 +73,8 @@ bool_t cpu_has_lmsl;
 #define set_segment_register(name, value)  \
     asm volatile ( "movw %%ax ,%%" STR(name) "" : : "a" (value) )
=20
+static void svm_update_guest_efer(struct vcpu *);
+
 static struct hvm_function_table svm_function_table;
=20
 /* va of hardware host save area     */
@@ -269,9 +271,9 @@ static int svm_vmcb_restore(struct vcpu=20
     v->arch.hvm_vcpu.guest_cr[2] =3D c->cr2;
     v->arch.hvm_vcpu.guest_cr[3] =3D c->cr3;
     v->arch.hvm_vcpu.guest_cr[4] =3D c->cr4;
-    hvm_update_guest_cr(v, 0);
-    hvm_update_guest_cr(v, 2);
-    hvm_update_guest_cr(v, 4);
+    svm_update_guest_cr(v, 0);
+    svm_update_guest_cr(v, 2);
+    svm_update_guest_cr(v, 4);
=20
     /* Load sysenter MSRs into both VMCB save area and VCPU fields. */
     vmcb->sysenter_cs =3D v->arch.hvm_svm.guest_sysenter_cs =3D c->sysente=
r_cs;
@@ -330,7 +332,7 @@ static void svm_load_cpu_state(struct vc
     vmcb->cstar      =3D data->msr_cstar;
     vmcb->sfmask     =3D data->msr_syscall_mask;
     v->arch.hvm_vcpu.guest_efer =3D data->msr_efer;
-    hvm_update_guest_efer(v);
+    svm_update_guest_efer(v);
=20
     hvm_set_guest_tsc(v, data->tsc);
 }
@@ -426,12 +428,7 @@ static int svm_guest_x86_mode(struct vcp
     return (likely(vmcb->cs.attr.fields.db) ? 4 : 2);
 }
=20
-static void svm_update_host_cr3(struct vcpu *v)
-{
-    /* SVM doesn't have a HOST_CR3 equivalent to update. */
-}
-
-static void svm_update_guest_cr(struct vcpu *v, unsigned int cr)
+void svm_update_guest_cr(struct vcpu *v, unsigned int cr)
 {
     struct vmcb_struct *vmcb =3D v->arch.hvm_svm.vmcb;
     uint64_t value;
@@ -1128,11 +1125,6 @@ static int svm_event_pending(struct vcpu
     return vmcb->eventinj.fields.v;
 }
=20
-static int svm_do_pmu_interrupt(struct cpu_user_regs *regs)
-{
-    return vpmu_do_interrupt(regs);
-}
-
 static void svm_cpu_dead(unsigned int cpu)
 {
     free_xenheap_page(per_cpu(hsa, cpu));
@@ -1997,7 +1989,6 @@ static struct hvm_function_table __read_
     .get_segment_register =3D svm_get_segment_register,
     .set_segment_register =3D svm_set_segment_register,
     .get_shadow_gs_base   =3D svm_get_shadow_gs_base,
-    .update_host_cr3      =3D svm_update_host_cr3,
     .update_guest_cr      =3D svm_update_guest_cr,
     .update_guest_efer    =3D svm_update_guest_efer,
     .set_guest_pat        =3D svm_set_guest_pat,
@@ -2006,7 +1997,6 @@ static struct hvm_function_table __read_
     .inject_trap          =3D svm_inject_trap,
     .init_hypercall_page  =3D svm_init_hypercall_page,
     .event_pending        =3D svm_event_pending,
-    .do_pmu_interrupt     =3D svm_do_pmu_interrupt,
     .cpuid_intercept      =3D svm_cpuid_intercept,
     .wbinvd_intercept     =3D svm_wbinvd_intercept,
     .fpu_dirty_intercept  =3D svm_fpu_dirty_intercept,
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -709,8 +709,8 @@ static void vmx_ctxt_switch_to(struct vc
         .fields =3D { .type =3D 0xb, .s =3D 0, .dpl =3D 0, .p =3D 1, .avl =
=3D 0,    \
                     .l =3D 0, .db =3D 0, .g =3D 0, .pad =3D 0 } }).bytes)
=20
-static void vmx_get_segment_register(struct vcpu *v, enum x86_segment =
seg,
-                                     struct segment_register *reg)
+void vmx_get_segment_register(struct vcpu *v, enum x86_segment seg,
+                              struct segment_register *reg)
 {
     uint32_t attr =3D 0;
=20
@@ -1461,11 +1461,6 @@ static int vmx_event_pending(struct vcpu
     return (__vmread(VM_ENTRY_INTR_INFO) & INTR_INFO_VALID_MASK);
 }
=20
-static int vmx_do_pmu_interrupt(struct cpu_user_regs *regs)
-{
-    return vpmu_do_interrupt(regs);
-}
-
 static void vmx_set_uc_mode(struct vcpu *v)
 {
     if ( paging_mode_hap(v->domain) )
@@ -1527,7 +1522,6 @@ static struct hvm_function_table __read_
     .inject_trap          =3D vmx_inject_trap,
     .init_hypercall_page  =3D vmx_init_hypercall_page,
     .event_pending        =3D vmx_event_pending,
-    .do_pmu_interrupt     =3D vmx_do_pmu_interrupt,
     .cpu_up               =3D vmx_cpu_up,
     .cpu_down             =3D vmx_cpu_down,
     .cpuid_intercept      =3D vmx_cpuid_intercept,
@@ -1642,7 +1636,7 @@ static void vmx_cpuid_intercept(
     {
         case 0x80000001:
             /* SYSCALL is visible iff running in long mode. */
-            hvm_get_segment_register(v, x86_seg_cs, &cs);
+            vmx_get_segment_register(v, x86_seg_cs, &cs);
             if ( cs.attr.fields.l )
                 *edx |=3D cpufeat_mask(X86_FEATURE_SYSCALL);
             else
--- a/xen/arch/x86/hvm/vmx/vvmx.c
+++ b/xen/arch/x86/hvm/vmx/vvmx.c
@@ -291,8 +291,6 @@ static int vmx_inst_check_privilege(stru
     struct vcpu *v =3D current;
     struct segment_register cs;
=20
-    hvm_get_segment_register(v, x86_seg_cs, &cs);
-
     if ( vmxop_check )
     {
         if ( !(v->arch.hvm_vcpu.guest_cr[0] & X86_CR0_PE) ||
@@ -302,6 +300,8 @@ static int vmx_inst_check_privilege(stru
     else if ( !vcpu_2_nvmx(v).vmxon_region_pa )
         goto invalid_op;
=20
+    vmx_get_segment_register(v, x86_seg_cs, &cs);
+
     if ( (regs->eflags & X86_EFLAGS_VM) ||
          (hvm_long_mode_enabled(v) && cs.attr.fields.l =3D=3D 0) )
         goto invalid_op;
@@ -358,13 +358,13 @@ static int decode_vmx_inst(struct cpu_us
=20
         if ( hvm_long_mode_enabled(v) )
         {
-            hvm_get_segment_register(v, x86_seg_cs, &seg);
+            vmx_get_segment_register(v, x86_seg_cs, &seg);
             mode_64bit =3D seg.attr.fields.l;
         }
=20
         if ( info.fields.segment > VMX_SREG_GS )
             goto gp_fault;
-        hvm_get_segment_register(v, sreg_to_index[info.fields.segment], =
&seg);
+        vmx_get_segment_register(v, sreg_to_index[info.fields.segment], =
&seg);
         seg_base =3D seg.base;
=20
         base =3D info.fields.base_reg_invalid ? 0 :
--- a/xen/include/asm-x86/hvm/hvm.h
+++ b/xen/include/asm-x86/hvm/hvm.h
@@ -137,7 +137,6 @@ struct hvm_function_table {
     void (*init_hypercall_page)(struct domain *d, void *hypercall_page);
=20
     int  (*event_pending)(struct vcpu *v);
-    int  (*do_pmu_interrupt)(struct cpu_user_regs *regs);
=20
     int  (*cpu_up_prepare)(unsigned int cpu);
     void (*cpu_dead)(unsigned int cpu);
@@ -270,7 +269,8 @@ hvm_guest_x86_mode(struct vcpu *v)
 static inline void
 hvm_update_host_cr3(struct vcpu *v)
 {
-    hvm_funcs.update_host_cr3(v);
+    if ( hvm_funcs.update_host_cr3 )
+        hvm_funcs.update_host_cr3(v);
 }
=20
 static inline void hvm_update_guest_cr(struct vcpu *v, unsigned int cr)
@@ -334,11 +334,6 @@ static inline int hvm_event_pending(stru
     return hvm_funcs.event_pending(v);
 }
=20
-static inline int hvm_do_pmu_interrupt(struct cpu_user_regs *regs)
-{
-    return hvm_funcs.do_pmu_interrupt(regs);
-}
-
 /* These reserved bits in lower 32 remain 0 after any load of CR0 */
 #define HVM_CR0_GUEST_RESERVED_BITS             \
     (~((unsigned long)                          \
--- a/xen/include/asm-x86/hvm/svm/svm.h
+++ b/xen/include/asm-x86/hvm/svm/svm.h
@@ -66,6 +66,7 @@ static inline void svm_invlpga(unsigned=20
=20
 unsigned long *svm_msrbit(unsigned long *msr_bitmap, uint32_t msr);
 void __update_guest_eip(struct cpu_user_regs *regs, unsigned int =
inst_len);
+void svm_update_guest_cr(struct vcpu *, unsigned int cr);
=20
 extern u32 svm_feature_flags;
=20
--- a/xen/include/asm-x86/hvm/vmx/vmx.h
+++ b/xen/include/asm-x86/hvm/vmx/vmx.h
@@ -387,6 +387,8 @@ static inline int __vmxon(u64 addr)
     return rc;
 }
=20
+void vmx_get_segment_register(struct vcpu *, enum x86_segment,
+                              struct segment_register *);
 void vmx_inject_extint(int trap);
 void vmx_inject_nmi(void);
=20



--=__Part8EBF9CCB.0__=
Content-Type: text/plain; name="hvm-no-indirect-calls.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="hvm-no-indirect-calls.patch"

x86/hvm: don't use indirect calls without need=0A=0ADirect calls perform =
better, so we should prefer them and use indirect=0Aones only when there =
indeed is a need for indirection.=0A=0ASigned-off-by: Jan Beulich =
<jbeulich@suse.com>=0A=0A--- a/xen/arch/x86/apic.c=0A+++ b/xen/arch/x86/api=
c.c=0A@@ -1373,7 +1373,7 @@ void error_interrupt(struct cpu_user_reg=0A =
void pmu_apic_interrupt(struct cpu_user_regs *regs)=0A {=0A     ack_APIC_ir=
q();=0A-    hvm_do_pmu_interrupt(regs);=0A+    vpmu_do_interrupt(regs);=0A =
}=0A =0A /*=0A--- a/xen/arch/x86/hvm/svm/svm.c=0A+++ b/xen/arch/x86/hvm/svm=
/svm.c=0A@@ -73,6 +73,8 @@ bool_t cpu_has_lmsl;=0A #define set_segment_regi=
ster(name, value)  \=0A     asm volatile ( "movw %%ax ,%%" STR(name) "" : =
: "a" (value) )=0A =0A+static void svm_update_guest_efer(struct vcpu =
*);=0A+=0A static struct hvm_function_table svm_function_table;=0A =0A /* =
va of hardware host save area     */=0A@@ -269,9 +271,9 @@ static int =
svm_vmcb_restore(struct vcpu =0A     v->arch.hvm_vcpu.guest_cr[2] =3D =
c->cr2;=0A     v->arch.hvm_vcpu.guest_cr[3] =3D c->cr3;=0A     v->arch.hvm_=
vcpu.guest_cr[4] =3D c->cr4;=0A-    hvm_update_guest_cr(v, 0);=0A-    =
hvm_update_guest_cr(v, 2);=0A-    hvm_update_guest_cr(v, 4);=0A+    =
svm_update_guest_cr(v, 0);=0A+    svm_update_guest_cr(v, 2);=0A+    =
svm_update_guest_cr(v, 4);=0A =0A     /* Load sysenter MSRs into both VMCB =
save area and VCPU fields. */=0A     vmcb->sysenter_cs =3D v->arch.hvm_svm.=
guest_sysenter_cs =3D c->sysenter_cs;=0A@@ -330,7 +332,7 @@ static void =
svm_load_cpu_state(struct vc=0A     vmcb->cstar      =3D data->msr_cstar;=
=0A     vmcb->sfmask     =3D data->msr_syscall_mask;=0A     v->arch.hvm_vcp=
u.guest_efer =3D data->msr_efer;=0A-    hvm_update_guest_efer(v);=0A+    =
svm_update_guest_efer(v);=0A =0A     hvm_set_guest_tsc(v, data->tsc);=0A =
}=0A@@ -426,12 +428,7 @@ static int svm_guest_x86_mode(struct vcp=0A     =
return (likely(vmcb->cs.attr.fields.db) ? 4 : 2);=0A }=0A =0A-static void =
svm_update_host_cr3(struct vcpu *v)=0A-{=0A-    /* SVM doesn't have a =
HOST_CR3 equivalent to update. */=0A-}=0A-=0A-static void svm_update_guest_=
cr(struct vcpu *v, unsigned int cr)=0A+void svm_update_guest_cr(struct =
vcpu *v, unsigned int cr)=0A {=0A     struct vmcb_struct *vmcb =3D =
v->arch.hvm_svm.vmcb;=0A     uint64_t value;=0A@@ -1128,11 +1125,6 @@ =
static int svm_event_pending(struct vcpu=0A     return vmcb->eventinj.field=
s.v;=0A }=0A =0A-static int svm_do_pmu_interrupt(struct cpu_user_regs =
*regs)=0A-{=0A-    return vpmu_do_interrupt(regs);=0A-}=0A-=0A static void =
svm_cpu_dead(unsigned int cpu)=0A {=0A     free_xenheap_page(per_cpu(hsa, =
cpu));=0A@@ -1997,7 +1989,6 @@ static struct hvm_function_table __read_=0A =
    .get_segment_register =3D svm_get_segment_register,=0A     .set_segment=
_register =3D svm_set_segment_register,=0A     .get_shadow_gs_base   =3D =
svm_get_shadow_gs_base,=0A-    .update_host_cr3      =3D svm_update_host_cr=
3,=0A     .update_guest_cr      =3D svm_update_guest_cr,=0A     .update_gue=
st_efer    =3D svm_update_guest_efer,=0A     .set_guest_pat        =3D =
svm_set_guest_pat,=0A@@ -2006,7 +1997,6 @@ static struct hvm_function_table=
 __read_=0A     .inject_trap          =3D svm_inject_trap,=0A     =
.init_hypercall_page  =3D svm_init_hypercall_page,=0A     .event_pending   =
     =3D svm_event_pending,=0A-    .do_pmu_interrupt     =3D svm_do_pmu_int=
errupt,=0A     .cpuid_intercept      =3D svm_cpuid_intercept,=0A     =
.wbinvd_intercept     =3D svm_wbinvd_intercept,=0A     .fpu_dirty_intercept=
  =3D svm_fpu_dirty_intercept,=0A--- a/xen/arch/x86/hvm/vmx/vmx.c=0A+++ =
b/xen/arch/x86/hvm/vmx/vmx.c=0A@@ -709,8 +709,8 @@ static void vmx_ctxt_swi=
tch_to(struct vc=0A         .fields =3D { .type =3D 0xb, .s =3D 0, .dpl =
=3D 0, .p =3D 1, .avl =3D 0,    \=0A                     .l =3D 0, .db =3D =
0, .g =3D 0, .pad =3D 0 } }).bytes)=0A =0A-static void vmx_get_segment_regi=
ster(struct vcpu *v, enum x86_segment seg,=0A-                             =
        struct segment_register *reg)=0A+void vmx_get_segment_register(stru=
ct vcpu *v, enum x86_segment seg,=0A+                              struct =
segment_register *reg)=0A {=0A     uint32_t attr =3D 0;=0A =0A@@ -1461,11 =
+1461,6 @@ static int vmx_event_pending(struct vcpu=0A     return =
(__vmread(VM_ENTRY_INTR_INFO) & INTR_INFO_VALID_MASK);=0A }=0A =0A-static =
int vmx_do_pmu_interrupt(struct cpu_user_regs *regs)=0A-{=0A-    return =
vpmu_do_interrupt(regs);=0A-}=0A-=0A static void vmx_set_uc_mode(struct =
vcpu *v)=0A {=0A     if ( paging_mode_hap(v->domain) )=0A@@ -1527,7 =
+1522,6 @@ static struct hvm_function_table __read_=0A     .inject_trap    =
      =3D vmx_inject_trap,=0A     .init_hypercall_page  =3D vmx_init_hyperc=
all_page,=0A     .event_pending        =3D vmx_event_pending,=0A-    =
.do_pmu_interrupt     =3D vmx_do_pmu_interrupt,=0A     .cpu_up             =
  =3D vmx_cpu_up,=0A     .cpu_down             =3D vmx_cpu_down,=0A     =
.cpuid_intercept      =3D vmx_cpuid_intercept,=0A@@ -1642,7 +1636,7 @@ =
static void vmx_cpuid_intercept(=0A     {=0A         case 0x80000001:=0A   =
          /* SYSCALL is visible iff running in long mode. */=0A-           =
 hvm_get_segment_register(v, x86_seg_cs, &cs);=0A+            vmx_get_segme=
nt_register(v, x86_seg_cs, &cs);=0A             if ( cs.attr.fields.l )=0A =
                *edx |=3D cpufeat_mask(X86_FEATURE_SYSCALL);=0A            =
 else=0A--- a/xen/arch/x86/hvm/vmx/vvmx.c=0A+++ b/xen/arch/x86/hvm/vmx/vvmx=
.c=0A@@ -291,8 +291,6 @@ static int vmx_inst_check_privilege(stru=0A     =
struct vcpu *v =3D current;=0A     struct segment_register cs;=0A =0A-    =
hvm_get_segment_register(v, x86_seg_cs, &cs);=0A-=0A     if ( vmxop_check =
)=0A     {=0A         if ( !(v->arch.hvm_vcpu.guest_cr[0] & X86_CR0_PE) =
||=0A@@ -302,6 +300,8 @@ static int vmx_inst_check_privilege(stru=0A     =
else if ( !vcpu_2_nvmx(v).vmxon_region_pa )=0A         goto invalid_op;=0A =
=0A+    vmx_get_segment_register(v, x86_seg_cs, &cs);=0A+=0A     if ( =
(regs->eflags & X86_EFLAGS_VM) ||=0A          (hvm_long_mode_enabled(v) && =
cs.attr.fields.l =3D=3D 0) )=0A         goto invalid_op;=0A@@ -358,13 =
+358,13 @@ static int decode_vmx_inst(struct cpu_us=0A =0A         if ( =
hvm_long_mode_enabled(v) )=0A         {=0A-            hvm_get_segment_regi=
ster(v, x86_seg_cs, &seg);=0A+            vmx_get_segment_register(v, =
x86_seg_cs, &seg);=0A             mode_64bit =3D seg.attr.fields.l;=0A     =
    }=0A =0A         if ( info.fields.segment > VMX_SREG_GS )=0A           =
  goto gp_fault;=0A-        hvm_get_segment_register(v, sreg_to_index[info.=
fields.segment], &seg);=0A+        vmx_get_segment_register(v, sreg_to_inde=
x[info.fields.segment], &seg);=0A         seg_base =3D seg.base;=0A =0A    =
     base =3D info.fields.base_reg_invalid ? 0 :=0A--- a/xen/include/asm-x8=
6/hvm/hvm.h=0A+++ b/xen/include/asm-x86/hvm/hvm.h=0A@@ -137,7 +137,6 @@ =
struct hvm_function_table {=0A     void (*init_hypercall_page)(struct =
domain *d, void *hypercall_page);=0A =0A     int  (*event_pending)(struct =
vcpu *v);=0A-    int  (*do_pmu_interrupt)(struct cpu_user_regs *regs);=0A =
=0A     int  (*cpu_up_prepare)(unsigned int cpu);=0A     void (*cpu_dead)(u=
nsigned int cpu);=0A@@ -270,7 +269,8 @@ hvm_guest_x86_mode(struct vcpu =
*v)=0A static inline void=0A hvm_update_host_cr3(struct vcpu *v)=0A {=0A-  =
  hvm_funcs.update_host_cr3(v);=0A+    if ( hvm_funcs.update_host_cr3 =
)=0A+        hvm_funcs.update_host_cr3(v);=0A }=0A =0A static inline void =
hvm_update_guest_cr(struct vcpu *v, unsigned int cr)=0A@@ -334,11 +334,6 =
@@ static inline int hvm_event_pending(stru=0A     return hvm_funcs.event_p=
ending(v);=0A }=0A =0A-static inline int hvm_do_pmu_interrupt(struct =
cpu_user_regs *regs)=0A-{=0A-    return hvm_funcs.do_pmu_interrupt(regs);=
=0A-}=0A-=0A /* These reserved bits in lower 32 remain 0 after any load of =
CR0 */=0A #define HVM_CR0_GUEST_RESERVED_BITS             \=0A     =
(~((unsigned long)                          \=0A--- a/xen/include/asm-x86/h=
vm/svm/svm.h=0A+++ b/xen/include/asm-x86/hvm/svm/svm.h=0A@@ -66,6 +66,7 @@ =
static inline void svm_invlpga(unsigned =0A =0A unsigned long *svm_msrbit(u=
nsigned long *msr_bitmap, uint32_t msr);=0A void __update_guest_eip(struct =
cpu_user_regs *regs, unsigned int inst_len);=0A+void svm_update_guest_cr(st=
ruct vcpu *, unsigned int cr);=0A =0A extern u32 svm_feature_flags;=0A =
=0A--- a/xen/include/asm-x86/hvm/vmx/vmx.h=0A+++ b/xen/include/asm-x86/hvm/=
vmx/vmx.h=0A@@ -387,6 +387,8 @@ static inline int __vmxon(u64 addr)=0A     =
return rc;=0A }=0A =0A+void vmx_get_segment_register(struct vcpu *, enum =
x86_segment,=0A+                              struct segment_register =
*);=0A void vmx_inject_extint(int trap);=0A void vmx_inject_nmi(void);=0A =
=0A
--=__Part8EBF9CCB.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

--=__Part8EBF9CCB.0__=--


From xen-devel-bounces@lists.xen.org Tue Sep 11 12:47:54 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 2012 12: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 1TBPsT-0000gl-Fl; Tue, 11 Sep 2012 12:47:41 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1TBPsS-0000gY-34
	for xen-devel@lists.xen.org; Tue, 11 Sep 2012 12:47:40 +0000
Received: from [85.158.143.35:36164] by server-3.bemta-4.messagelabs.com id
	2A/B8-08232-BE23F405; Tue, 11 Sep 2012 12:47:39 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1347367647!12570720!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQwNzc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27171 invoked from network); 11 Sep 2012 12:47:28 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-11.tower-21.messagelabs.com with SMTP;
	11 Sep 2012 12:47:28 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 11 Sep 2012 13:47:27 +0100
Message-Id: <504F4EFB020000780009A997@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 11 Sep 2012 13:47:23 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part8EBF9CCB.0__="
Subject: [Xen-devel] [PATCH 1/3] x86/hvm: don't use indirect calls without
	need
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<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.

--=__Part8EBF9CCB.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Direct calls perform better, so we should prefer them and use indirect
ones only when there indeed is a need for indirection.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/arch/x86/apic.c
+++ b/xen/arch/x86/apic.c
@@ -1373,7 +1373,7 @@ void error_interrupt(struct cpu_user_reg
 void pmu_apic_interrupt(struct cpu_user_regs *regs)
 {
     ack_APIC_irq();
-    hvm_do_pmu_interrupt(regs);
+    vpmu_do_interrupt(regs);
 }
=20
 /*
--- a/xen/arch/x86/hvm/svm/svm.c
+++ b/xen/arch/x86/hvm/svm/svm.c
@@ -73,6 +73,8 @@ bool_t cpu_has_lmsl;
 #define set_segment_register(name, value)  \
     asm volatile ( "movw %%ax ,%%" STR(name) "" : : "a" (value) )
=20
+static void svm_update_guest_efer(struct vcpu *);
+
 static struct hvm_function_table svm_function_table;
=20
 /* va of hardware host save area     */
@@ -269,9 +271,9 @@ static int svm_vmcb_restore(struct vcpu=20
     v->arch.hvm_vcpu.guest_cr[2] =3D c->cr2;
     v->arch.hvm_vcpu.guest_cr[3] =3D c->cr3;
     v->arch.hvm_vcpu.guest_cr[4] =3D c->cr4;
-    hvm_update_guest_cr(v, 0);
-    hvm_update_guest_cr(v, 2);
-    hvm_update_guest_cr(v, 4);
+    svm_update_guest_cr(v, 0);
+    svm_update_guest_cr(v, 2);
+    svm_update_guest_cr(v, 4);
=20
     /* Load sysenter MSRs into both VMCB save area and VCPU fields. */
     vmcb->sysenter_cs =3D v->arch.hvm_svm.guest_sysenter_cs =3D c->sysente=
r_cs;
@@ -330,7 +332,7 @@ static void svm_load_cpu_state(struct vc
     vmcb->cstar      =3D data->msr_cstar;
     vmcb->sfmask     =3D data->msr_syscall_mask;
     v->arch.hvm_vcpu.guest_efer =3D data->msr_efer;
-    hvm_update_guest_efer(v);
+    svm_update_guest_efer(v);
=20
     hvm_set_guest_tsc(v, data->tsc);
 }
@@ -426,12 +428,7 @@ static int svm_guest_x86_mode(struct vcp
     return (likely(vmcb->cs.attr.fields.db) ? 4 : 2);
 }
=20
-static void svm_update_host_cr3(struct vcpu *v)
-{
-    /* SVM doesn't have a HOST_CR3 equivalent to update. */
-}
-
-static void svm_update_guest_cr(struct vcpu *v, unsigned int cr)
+void svm_update_guest_cr(struct vcpu *v, unsigned int cr)
 {
     struct vmcb_struct *vmcb =3D v->arch.hvm_svm.vmcb;
     uint64_t value;
@@ -1128,11 +1125,6 @@ static int svm_event_pending(struct vcpu
     return vmcb->eventinj.fields.v;
 }
=20
-static int svm_do_pmu_interrupt(struct cpu_user_regs *regs)
-{
-    return vpmu_do_interrupt(regs);
-}
-
 static void svm_cpu_dead(unsigned int cpu)
 {
     free_xenheap_page(per_cpu(hsa, cpu));
@@ -1997,7 +1989,6 @@ static struct hvm_function_table __read_
     .get_segment_register =3D svm_get_segment_register,
     .set_segment_register =3D svm_set_segment_register,
     .get_shadow_gs_base   =3D svm_get_shadow_gs_base,
-    .update_host_cr3      =3D svm_update_host_cr3,
     .update_guest_cr      =3D svm_update_guest_cr,
     .update_guest_efer    =3D svm_update_guest_efer,
     .set_guest_pat        =3D svm_set_guest_pat,
@@ -2006,7 +1997,6 @@ static struct hvm_function_table __read_
     .inject_trap          =3D svm_inject_trap,
     .init_hypercall_page  =3D svm_init_hypercall_page,
     .event_pending        =3D svm_event_pending,
-    .do_pmu_interrupt     =3D svm_do_pmu_interrupt,
     .cpuid_intercept      =3D svm_cpuid_intercept,
     .wbinvd_intercept     =3D svm_wbinvd_intercept,
     .fpu_dirty_intercept  =3D svm_fpu_dirty_intercept,
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -709,8 +709,8 @@ static void vmx_ctxt_switch_to(struct vc
         .fields =3D { .type =3D 0xb, .s =3D 0, .dpl =3D 0, .p =3D 1, .avl =
=3D 0,    \
                     .l =3D 0, .db =3D 0, .g =3D 0, .pad =3D 0 } }).bytes)
=20
-static void vmx_get_segment_register(struct vcpu *v, enum x86_segment =
seg,
-                                     struct segment_register *reg)
+void vmx_get_segment_register(struct vcpu *v, enum x86_segment seg,
+                              struct segment_register *reg)
 {
     uint32_t attr =3D 0;
=20
@@ -1461,11 +1461,6 @@ static int vmx_event_pending(struct vcpu
     return (__vmread(VM_ENTRY_INTR_INFO) & INTR_INFO_VALID_MASK);
 }
=20
-static int vmx_do_pmu_interrupt(struct cpu_user_regs *regs)
-{
-    return vpmu_do_interrupt(regs);
-}
-
 static void vmx_set_uc_mode(struct vcpu *v)
 {
     if ( paging_mode_hap(v->domain) )
@@ -1527,7 +1522,6 @@ static struct hvm_function_table __read_
     .inject_trap          =3D vmx_inject_trap,
     .init_hypercall_page  =3D vmx_init_hypercall_page,
     .event_pending        =3D vmx_event_pending,
-    .do_pmu_interrupt     =3D vmx_do_pmu_interrupt,
     .cpu_up               =3D vmx_cpu_up,
     .cpu_down             =3D vmx_cpu_down,
     .cpuid_intercept      =3D vmx_cpuid_intercept,
@@ -1642,7 +1636,7 @@ static void vmx_cpuid_intercept(
     {
         case 0x80000001:
             /* SYSCALL is visible iff running in long mode. */
-            hvm_get_segment_register(v, x86_seg_cs, &cs);
+            vmx_get_segment_register(v, x86_seg_cs, &cs);
             if ( cs.attr.fields.l )
                 *edx |=3D cpufeat_mask(X86_FEATURE_SYSCALL);
             else
--- a/xen/arch/x86/hvm/vmx/vvmx.c
+++ b/xen/arch/x86/hvm/vmx/vvmx.c
@@ -291,8 +291,6 @@ static int vmx_inst_check_privilege(stru
     struct vcpu *v =3D current;
     struct segment_register cs;
=20
-    hvm_get_segment_register(v, x86_seg_cs, &cs);
-
     if ( vmxop_check )
     {
         if ( !(v->arch.hvm_vcpu.guest_cr[0] & X86_CR0_PE) ||
@@ -302,6 +300,8 @@ static int vmx_inst_check_privilege(stru
     else if ( !vcpu_2_nvmx(v).vmxon_region_pa )
         goto invalid_op;
=20
+    vmx_get_segment_register(v, x86_seg_cs, &cs);
+
     if ( (regs->eflags & X86_EFLAGS_VM) ||
          (hvm_long_mode_enabled(v) && cs.attr.fields.l =3D=3D 0) )
         goto invalid_op;
@@ -358,13 +358,13 @@ static int decode_vmx_inst(struct cpu_us
=20
         if ( hvm_long_mode_enabled(v) )
         {
-            hvm_get_segment_register(v, x86_seg_cs, &seg);
+            vmx_get_segment_register(v, x86_seg_cs, &seg);
             mode_64bit =3D seg.attr.fields.l;
         }
=20
         if ( info.fields.segment > VMX_SREG_GS )
             goto gp_fault;
-        hvm_get_segment_register(v, sreg_to_index[info.fields.segment], =
&seg);
+        vmx_get_segment_register(v, sreg_to_index[info.fields.segment], =
&seg);
         seg_base =3D seg.base;
=20
         base =3D info.fields.base_reg_invalid ? 0 :
--- a/xen/include/asm-x86/hvm/hvm.h
+++ b/xen/include/asm-x86/hvm/hvm.h
@@ -137,7 +137,6 @@ struct hvm_function_table {
     void (*init_hypercall_page)(struct domain *d, void *hypercall_page);
=20
     int  (*event_pending)(struct vcpu *v);
-    int  (*do_pmu_interrupt)(struct cpu_user_regs *regs);
=20
     int  (*cpu_up_prepare)(unsigned int cpu);
     void (*cpu_dead)(unsigned int cpu);
@@ -270,7 +269,8 @@ hvm_guest_x86_mode(struct vcpu *v)
 static inline void
 hvm_update_host_cr3(struct vcpu *v)
 {
-    hvm_funcs.update_host_cr3(v);
+    if ( hvm_funcs.update_host_cr3 )
+        hvm_funcs.update_host_cr3(v);
 }
=20
 static inline void hvm_update_guest_cr(struct vcpu *v, unsigned int cr)
@@ -334,11 +334,6 @@ static inline int hvm_event_pending(stru
     return hvm_funcs.event_pending(v);
 }
=20
-static inline int hvm_do_pmu_interrupt(struct cpu_user_regs *regs)
-{
-    return hvm_funcs.do_pmu_interrupt(regs);
-}
-
 /* These reserved bits in lower 32 remain 0 after any load of CR0 */
 #define HVM_CR0_GUEST_RESERVED_BITS             \
     (~((unsigned long)                          \
--- a/xen/include/asm-x86/hvm/svm/svm.h
+++ b/xen/include/asm-x86/hvm/svm/svm.h
@@ -66,6 +66,7 @@ static inline void svm_invlpga(unsigned=20
=20
 unsigned long *svm_msrbit(unsigned long *msr_bitmap, uint32_t msr);
 void __update_guest_eip(struct cpu_user_regs *regs, unsigned int =
inst_len);
+void svm_update_guest_cr(struct vcpu *, unsigned int cr);
=20
 extern u32 svm_feature_flags;
=20
--- a/xen/include/asm-x86/hvm/vmx/vmx.h
+++ b/xen/include/asm-x86/hvm/vmx/vmx.h
@@ -387,6 +387,8 @@ static inline int __vmxon(u64 addr)
     return rc;
 }
=20
+void vmx_get_segment_register(struct vcpu *, enum x86_segment,
+                              struct segment_register *);
 void vmx_inject_extint(int trap);
 void vmx_inject_nmi(void);
=20



--=__Part8EBF9CCB.0__=
Content-Type: text/plain; name="hvm-no-indirect-calls.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="hvm-no-indirect-calls.patch"

x86/hvm: don't use indirect calls without need=0A=0ADirect calls perform =
better, so we should prefer them and use indirect=0Aones only when there =
indeed is a need for indirection.=0A=0ASigned-off-by: Jan Beulich =
<jbeulich@suse.com>=0A=0A--- a/xen/arch/x86/apic.c=0A+++ b/xen/arch/x86/api=
c.c=0A@@ -1373,7 +1373,7 @@ void error_interrupt(struct cpu_user_reg=0A =
void pmu_apic_interrupt(struct cpu_user_regs *regs)=0A {=0A     ack_APIC_ir=
q();=0A-    hvm_do_pmu_interrupt(regs);=0A+    vpmu_do_interrupt(regs);=0A =
}=0A =0A /*=0A--- a/xen/arch/x86/hvm/svm/svm.c=0A+++ b/xen/arch/x86/hvm/svm=
/svm.c=0A@@ -73,6 +73,8 @@ bool_t cpu_has_lmsl;=0A #define set_segment_regi=
ster(name, value)  \=0A     asm volatile ( "movw %%ax ,%%" STR(name) "" : =
: "a" (value) )=0A =0A+static void svm_update_guest_efer(struct vcpu =
*);=0A+=0A static struct hvm_function_table svm_function_table;=0A =0A /* =
va of hardware host save area     */=0A@@ -269,9 +271,9 @@ static int =
svm_vmcb_restore(struct vcpu =0A     v->arch.hvm_vcpu.guest_cr[2] =3D =
c->cr2;=0A     v->arch.hvm_vcpu.guest_cr[3] =3D c->cr3;=0A     v->arch.hvm_=
vcpu.guest_cr[4] =3D c->cr4;=0A-    hvm_update_guest_cr(v, 0);=0A-    =
hvm_update_guest_cr(v, 2);=0A-    hvm_update_guest_cr(v, 4);=0A+    =
svm_update_guest_cr(v, 0);=0A+    svm_update_guest_cr(v, 2);=0A+    =
svm_update_guest_cr(v, 4);=0A =0A     /* Load sysenter MSRs into both VMCB =
save area and VCPU fields. */=0A     vmcb->sysenter_cs =3D v->arch.hvm_svm.=
guest_sysenter_cs =3D c->sysenter_cs;=0A@@ -330,7 +332,7 @@ static void =
svm_load_cpu_state(struct vc=0A     vmcb->cstar      =3D data->msr_cstar;=
=0A     vmcb->sfmask     =3D data->msr_syscall_mask;=0A     v->arch.hvm_vcp=
u.guest_efer =3D data->msr_efer;=0A-    hvm_update_guest_efer(v);=0A+    =
svm_update_guest_efer(v);=0A =0A     hvm_set_guest_tsc(v, data->tsc);=0A =
}=0A@@ -426,12 +428,7 @@ static int svm_guest_x86_mode(struct vcp=0A     =
return (likely(vmcb->cs.attr.fields.db) ? 4 : 2);=0A }=0A =0A-static void =
svm_update_host_cr3(struct vcpu *v)=0A-{=0A-    /* SVM doesn't have a =
HOST_CR3 equivalent to update. */=0A-}=0A-=0A-static void svm_update_guest_=
cr(struct vcpu *v, unsigned int cr)=0A+void svm_update_guest_cr(struct =
vcpu *v, unsigned int cr)=0A {=0A     struct vmcb_struct *vmcb =3D =
v->arch.hvm_svm.vmcb;=0A     uint64_t value;=0A@@ -1128,11 +1125,6 @@ =
static int svm_event_pending(struct vcpu=0A     return vmcb->eventinj.field=
s.v;=0A }=0A =0A-static int svm_do_pmu_interrupt(struct cpu_user_regs =
*regs)=0A-{=0A-    return vpmu_do_interrupt(regs);=0A-}=0A-=0A static void =
svm_cpu_dead(unsigned int cpu)=0A {=0A     free_xenheap_page(per_cpu(hsa, =
cpu));=0A@@ -1997,7 +1989,6 @@ static struct hvm_function_table __read_=0A =
    .get_segment_register =3D svm_get_segment_register,=0A     .set_segment=
_register =3D svm_set_segment_register,=0A     .get_shadow_gs_base   =3D =
svm_get_shadow_gs_base,=0A-    .update_host_cr3      =3D svm_update_host_cr=
3,=0A     .update_guest_cr      =3D svm_update_guest_cr,=0A     .update_gue=
st_efer    =3D svm_update_guest_efer,=0A     .set_guest_pat        =3D =
svm_set_guest_pat,=0A@@ -2006,7 +1997,6 @@ static struct hvm_function_table=
 __read_=0A     .inject_trap          =3D svm_inject_trap,=0A     =
.init_hypercall_page  =3D svm_init_hypercall_page,=0A     .event_pending   =
     =3D svm_event_pending,=0A-    .do_pmu_interrupt     =3D svm_do_pmu_int=
errupt,=0A     .cpuid_intercept      =3D svm_cpuid_intercept,=0A     =
.wbinvd_intercept     =3D svm_wbinvd_intercept,=0A     .fpu_dirty_intercept=
  =3D svm_fpu_dirty_intercept,=0A--- a/xen/arch/x86/hvm/vmx/vmx.c=0A+++ =
b/xen/arch/x86/hvm/vmx/vmx.c=0A@@ -709,8 +709,8 @@ static void vmx_ctxt_swi=
tch_to(struct vc=0A         .fields =3D { .type =3D 0xb, .s =3D 0, .dpl =
=3D 0, .p =3D 1, .avl =3D 0,    \=0A                     .l =3D 0, .db =3D =
0, .g =3D 0, .pad =3D 0 } }).bytes)=0A =0A-static void vmx_get_segment_regi=
ster(struct vcpu *v, enum x86_segment seg,=0A-                             =
        struct segment_register *reg)=0A+void vmx_get_segment_register(stru=
ct vcpu *v, enum x86_segment seg,=0A+                              struct =
segment_register *reg)=0A {=0A     uint32_t attr =3D 0;=0A =0A@@ -1461,11 =
+1461,6 @@ static int vmx_event_pending(struct vcpu=0A     return =
(__vmread(VM_ENTRY_INTR_INFO) & INTR_INFO_VALID_MASK);=0A }=0A =0A-static =
int vmx_do_pmu_interrupt(struct cpu_user_regs *regs)=0A-{=0A-    return =
vpmu_do_interrupt(regs);=0A-}=0A-=0A static void vmx_set_uc_mode(struct =
vcpu *v)=0A {=0A     if ( paging_mode_hap(v->domain) )=0A@@ -1527,7 =
+1522,6 @@ static struct hvm_function_table __read_=0A     .inject_trap    =
      =3D vmx_inject_trap,=0A     .init_hypercall_page  =3D vmx_init_hyperc=
all_page,=0A     .event_pending        =3D vmx_event_pending,=0A-    =
.do_pmu_interrupt     =3D vmx_do_pmu_interrupt,=0A     .cpu_up             =
  =3D vmx_cpu_up,=0A     .cpu_down             =3D vmx_cpu_down,=0A     =
.cpuid_intercept      =3D vmx_cpuid_intercept,=0A@@ -1642,7 +1636,7 @@ =
static void vmx_cpuid_intercept(=0A     {=0A         case 0x80000001:=0A   =
          /* SYSCALL is visible iff running in long mode. */=0A-           =
 hvm_get_segment_register(v, x86_seg_cs, &cs);=0A+            vmx_get_segme=
nt_register(v, x86_seg_cs, &cs);=0A             if ( cs.attr.fields.l )=0A =
                *edx |=3D cpufeat_mask(X86_FEATURE_SYSCALL);=0A            =
 else=0A--- a/xen/arch/x86/hvm/vmx/vvmx.c=0A+++ b/xen/arch/x86/hvm/vmx/vvmx=
.c=0A@@ -291,8 +291,6 @@ static int vmx_inst_check_privilege(stru=0A     =
struct vcpu *v =3D current;=0A     struct segment_register cs;=0A =0A-    =
hvm_get_segment_register(v, x86_seg_cs, &cs);=0A-=0A     if ( vmxop_check =
)=0A     {=0A         if ( !(v->arch.hvm_vcpu.guest_cr[0] & X86_CR0_PE) =
||=0A@@ -302,6 +300,8 @@ static int vmx_inst_check_privilege(stru=0A     =
else if ( !vcpu_2_nvmx(v).vmxon_region_pa )=0A         goto invalid_op;=0A =
=0A+    vmx_get_segment_register(v, x86_seg_cs, &cs);=0A+=0A     if ( =
(regs->eflags & X86_EFLAGS_VM) ||=0A          (hvm_long_mode_enabled(v) && =
cs.attr.fields.l =3D=3D 0) )=0A         goto invalid_op;=0A@@ -358,13 =
+358,13 @@ static int decode_vmx_inst(struct cpu_us=0A =0A         if ( =
hvm_long_mode_enabled(v) )=0A         {=0A-            hvm_get_segment_regi=
ster(v, x86_seg_cs, &seg);=0A+            vmx_get_segment_register(v, =
x86_seg_cs, &seg);=0A             mode_64bit =3D seg.attr.fields.l;=0A     =
    }=0A =0A         if ( info.fields.segment > VMX_SREG_GS )=0A           =
  goto gp_fault;=0A-        hvm_get_segment_register(v, sreg_to_index[info.=
fields.segment], &seg);=0A+        vmx_get_segment_register(v, sreg_to_inde=
x[info.fields.segment], &seg);=0A         seg_base =3D seg.base;=0A =0A    =
     base =3D info.fields.base_reg_invalid ? 0 :=0A--- a/xen/include/asm-x8=
6/hvm/hvm.h=0A+++ b/xen/include/asm-x86/hvm/hvm.h=0A@@ -137,7 +137,6 @@ =
struct hvm_function_table {=0A     void (*init_hypercall_page)(struct =
domain *d, void *hypercall_page);=0A =0A     int  (*event_pending)(struct =
vcpu *v);=0A-    int  (*do_pmu_interrupt)(struct cpu_user_regs *regs);=0A =
=0A     int  (*cpu_up_prepare)(unsigned int cpu);=0A     void (*cpu_dead)(u=
nsigned int cpu);=0A@@ -270,7 +269,8 @@ hvm_guest_x86_mode(struct vcpu =
*v)=0A static inline void=0A hvm_update_host_cr3(struct vcpu *v)=0A {=0A-  =
  hvm_funcs.update_host_cr3(v);=0A+    if ( hvm_funcs.update_host_cr3 =
)=0A+        hvm_funcs.update_host_cr3(v);=0A }=0A =0A static inline void =
hvm_update_guest_cr(struct vcpu *v, unsigned int cr)=0A@@ -334,11 +334,6 =
@@ static inline int hvm_event_pending(stru=0A     return hvm_funcs.event_p=
ending(v);=0A }=0A =0A-static inline int hvm_do_pmu_interrupt(struct =
cpu_user_regs *regs)=0A-{=0A-    return hvm_funcs.do_pmu_interrupt(regs);=
=0A-}=0A-=0A /* These reserved bits in lower 32 remain 0 after any load of =
CR0 */=0A #define HVM_CR0_GUEST_RESERVED_BITS             \=0A     =
(~((unsigned long)                          \=0A--- a/xen/include/asm-x86/h=
vm/svm/svm.h=0A+++ b/xen/include/asm-x86/hvm/svm/svm.h=0A@@ -66,6 +66,7 @@ =
static inline void svm_invlpga(unsigned =0A =0A unsigned long *svm_msrbit(u=
nsigned long *msr_bitmap, uint32_t msr);=0A void __update_guest_eip(struct =
cpu_user_regs *regs, unsigned int inst_len);=0A+void svm_update_guest_cr(st=
ruct vcpu *, unsigned int cr);=0A =0A extern u32 svm_feature_flags;=0A =
=0A--- a/xen/include/asm-x86/hvm/vmx/vmx.h=0A+++ b/xen/include/asm-x86/hvm/=
vmx/vmx.h=0A@@ -387,6 +387,8 @@ static inline int __vmxon(u64 addr)=0A     =
return rc;=0A }=0A =0A+void vmx_get_segment_register(struct vcpu *, enum =
x86_segment,=0A+                              struct segment_register =
*);=0A void vmx_inject_extint(int trap);=0A void vmx_inject_nmi(void);=0A =
=0A
--=__Part8EBF9CCB.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

--=__Part8EBF9CCB.0__=--


From xen-devel-bounces@lists.xen.org Tue Sep 11 12:48:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 2012 12:48:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TBPsi-0000iz-3C; Tue, 11 Sep 2012 12:47:56 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1TBPsg-0000iT-Tw
	for xen-devel@lists.xen.org; Tue, 11 Sep 2012 12:47:55 +0000
Received: from [85.158.143.35:37517] by server-2.bemta-4.messagelabs.com id
	16/50-21239-AF23F405; Tue, 11 Sep 2012 12:47:54 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1347367672!11909690!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQwNzc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5484 invoked from network); 11 Sep 2012 12:47: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;
	11 Sep 2012 12:47:52 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 11 Sep 2012 13:47:52 +0100
Message-Id: <504F4F15020000780009A99B@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 11 Sep 2012 13:47:49 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__PartA091B2E5.0__="
Subject: [Xen-devel] [PATCH 2/3] x86/hvm: constify static data where possible
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<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.

--=__PartA091B2E5.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

In a few cases this also extends to making them static in the first
place.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -3123,7 +3123,7 @@ typedef unsigned long hvm_hypercall_t(
=20
 #if defined(__i386__)
=20
-static hvm_hypercall_t *hvm_hypercall32_table[NR_hypercalls] =3D {
+static hvm_hypercall_t *const hvm_hypercall32_table[NR_hypercalls] =3D {
     [ __HYPERVISOR_memory_op ] =3D (hvm_hypercall_t *)hvm_memory_op,
     [ __HYPERVISOR_grant_table_op ] =3D (hvm_hypercall_t *)hvm_grant_table=
_op,
     [ __HYPERVISOR_vcpu_op ] =3D (hvm_hypercall_t *)hvm_vcpu_op,
@@ -3208,7 +3208,7 @@ static long hvm_physdev_op_compat32(
     }
 }
=20
-static hvm_hypercall_t *hvm_hypercall64_table[NR_hypercalls] =3D {
+static hvm_hypercall_t *const hvm_hypercall64_table[NR_hypercalls] =3D {
     [ __HYPERVISOR_memory_op ] =3D (hvm_hypercall_t *)hvm_memory_op,
     [ __HYPERVISOR_grant_table_op ] =3D (hvm_hypercall_t *)hvm_grant_table=
_op,
     [ __HYPERVISOR_vcpu_op ] =3D (hvm_hypercall_t *)hvm_vcpu_op,
@@ -3225,7 +3225,7 @@ static hvm_hypercall_t *hvm_hypercall64_
 #define COMPAT_CALL(x)                                        \
     [ __HYPERVISOR_ ## x ] =3D (hvm_hypercall_t *) compat_ ## x
=20
-static hvm_hypercall_t *hvm_hypercall32_table[NR_hypercalls] =3D {
+static hvm_hypercall_t *const hvm_hypercall32_table[NR_hypercalls] =3D {
     [ __HYPERVISOR_memory_op ] =3D (hvm_hypercall_t *)hvm_memory_op_compat=
32,
     [ __HYPERVISOR_grant_table_op ] =3D (hvm_hypercall_t *)hvm_grant_table=
_op_compat32,
     [ __HYPERVISOR_vcpu_op ] =3D (hvm_hypercall_t *)hvm_vcpu_op_compat32,
--- a/xen/arch/x86/hvm/mtrr.c
+++ b/xen/arch/x86/hvm/mtrr.c
@@ -34,14 +34,14 @@ static uint32_t size_or_mask;
 #define pat_cr_2_paf(pat_cr,n)  ((((uint64_t)pat_cr) >> ((n)<<3)) & 0xff)
=20
 /* PAT entry to PTE flags (PAT, PCD, PWT bits). */
-static uint8_t pat_entry_2_pte_flags[8] =3D {
+static const uint8_t pat_entry_2_pte_flags[8] =3D {
     0,           _PAGE_PWT,
     _PAGE_PCD,   _PAGE_PCD | _PAGE_PWT,
     _PAGE_PAT,   _PAGE_PAT | _PAGE_PWT,
     _PAGE_PAT | _PAGE_PCD, _PAGE_PAT | _PAGE_PCD | _PAGE_PWT };
=20
 /* Effective mm type lookup table, according to MTRR and PAT. */
-static uint8_t mm_type_tbl[MTRR_NUM_TYPES][PAT_TYPE_NUMS] =3D {
+static const uint8_t mm_type_tbl[MTRR_NUM_TYPES][PAT_TYPE_NUMS] =3D {
 /********PAT(UC,WC,RS,RS,WT,WP,WB,UC-)*/
 /* RS means reserved type(2,3), and type is hardcoded here */
  /*MTRR(UC):(UC,WC,RS,RS,UC,UC,UC,UC)*/
--- a/xen/arch/x86/hvm/stdvga.c
+++ b/xen/arch/x86/hvm/stdvga.c
@@ -59,7 +59,7 @@ static const uint32_t mask16[16] =3D {
 };
=20
 /* force some bits to zero */
-const uint8_t sr_mask[8] =3D {
+static const uint8_t sr_mask[8] =3D {
     (uint8_t)~0xfc,
     (uint8_t)~0xc2,
     (uint8_t)~0xf0,
@@ -70,7 +70,7 @@ const uint8_t sr_mask[8] =3D {
     (uint8_t)~0x00,
 };
=20
-const uint8_t gr_mask[9] =3D {
+static const uint8_t gr_mask[9] =3D {
     (uint8_t)~0xf0, /* 0x00 */
     (uint8_t)~0xf0, /* 0x01 */
     (uint8_t)~0xf0, /* 0x02 */
--- a/xen/arch/x86/hvm/svm/emulate.c
+++ b/xen/arch/x86/hvm/svm/emulate.c
@@ -109,7 +109,7 @@ MAKE_INSTR(STGI,   3, 0x0f, 0x01, 0xdc);
 MAKE_INSTR(CLGI,   3, 0x0f, 0x01, 0xdd);
 MAKE_INSTR(INVLPGA,3, 0x0f, 0x01, 0xdf);
=20
-static const u8 *opc_bytes[INSTR_MAX_COUNT] =3D=20
+static const u8 *const opc_bytes[INSTR_MAX_COUNT] =3D
 {
     [INSTR_INVD]   =3D OPCODE_INVD,
     [INSTR_WBINVD] =3D OPCODE_WBINVD,
--- a/xen/arch/x86/hvm/svm/vpmu.c
+++ b/xen/arch/x86/hvm/svm/vpmu.c
@@ -44,13 +44,13 @@
 #define set_guest_mode(msr) (msr |=3D (1ULL << MSR_F10H_EVNTSEL_GO_SHIFT))=

 #define is_overflowed(msr) (!((msr) & (1ULL << (MSR_F10H_COUNTER_LENGTH-1)=
)))
=20
-static int __read_mostly num_counters =3D 0;
-static u32 __read_mostly *counters =3D NULL;
-static u32 __read_mostly *ctrls =3D NULL;
-static bool_t __read_mostly k7_counters_mirrored =3D 0;
+static unsigned int __read_mostly num_counters;
+static const u32 __read_mostly *counters;
+static const u32 __read_mostly *ctrls;
+static bool_t __read_mostly k7_counters_mirrored;
=20
 /* PMU Counter MSRs. */
-u32 AMD_F10H_COUNTERS[] =3D {
+static const u32 AMD_F10H_COUNTERS[] =3D {
     MSR_K7_PERFCTR0,
     MSR_K7_PERFCTR1,
     MSR_K7_PERFCTR2,
@@ -58,14 +58,14 @@ u32 AMD_F10H_COUNTERS[] =3D {
 };
=20
 /* PMU Control MSRs. */
-u32 AMD_F10H_CTRLS[] =3D {
+static const u32 AMD_F10H_CTRLS[] =3D {
     MSR_K7_EVNTSEL0,
     MSR_K7_EVNTSEL1,
     MSR_K7_EVNTSEL2,
     MSR_K7_EVNTSEL3
 };
=20
-u32 AMD_F15H_COUNTERS[] =3D {
+static const u32 AMD_F15H_COUNTERS[] =3D {
     MSR_AMD_FAM15H_PERFCTR0,
     MSR_AMD_FAM15H_PERFCTR1,
     MSR_AMD_FAM15H_PERFCTR2,
@@ -74,7 +74,7 @@ u32 AMD_F15H_COUNTERS[] =3D {
     MSR_AMD_FAM15H_PERFCTR5
 };
=20
-u32 AMD_F15H_CTRLS[] =3D {
+static const u32 AMD_F15H_CTRLS[] =3D {
     MSR_AMD_FAM15H_EVNTSEL0,
     MSR_AMD_FAM15H_EVNTSEL1,
     MSR_AMD_FAM15H_EVNTSEL2,
@@ -161,7 +161,7 @@ static int amd_vpmu_do_interrupt(struct=20
=20
 static inline void context_restore(struct vcpu *v)
 {
-    u64 i;
+    unsigned int i;
     struct vpmu_struct *vpmu =3D vcpu_vpmu(v);
     struct amd_vpmu_context *ctxt =3D vpmu->context;
=20
@@ -198,7 +198,7 @@ static void amd_vpmu_restore(struct vcpu
=20
 static inline void context_save(struct vcpu *v)
 {
-    int i;
+    unsigned int i;
     struct vpmu_struct *vpmu =3D vcpu_vpmu(v);
     struct amd_vpmu_context *ctxt =3D vpmu->context;
=20
@@ -225,7 +225,7 @@ static void amd_vpmu_save(struct vcpu *v
=20
 static void context_update(unsigned int msr, u64 msr_content)
 {
-    int i;
+    unsigned int i;
     struct vcpu *v =3D current;
     struct vpmu_struct *vpmu =3D vcpu_vpmu(v);
     struct amd_vpmu_context *ctxt =3D vpmu->context;
@@ -294,7 +294,7 @@ static int amd_vpmu_do_rdmsr(unsigned in
=20
 static int amd_vpmu_initialise(struct vcpu *v)
 {
-    struct amd_vpmu_context *ctxt =3D NULL;
+    struct amd_vpmu_context *ctxt;
     struct vpmu_struct *vpmu =3D vcpu_vpmu(v);
     uint8_t family =3D current_cpu_data.x86;
=20
@@ -323,7 +323,7 @@ static int amd_vpmu_initialise(struct vc
 	 }
     }
=20
-    ctxt =3D xzalloc_bytes(sizeof(struct amd_vpmu_context));
+    ctxt =3D xzalloc(struct amd_vpmu_context);
     if ( !ctxt )
     {
         gdprintk(XENLOG_WARNING, "Insufficient memory for PMU, "
@@ -332,7 +332,7 @@ static int amd_vpmu_initialise(struct vc
         return -ENOMEM;
     }
=20
-    vpmu->context =3D (void *)ctxt;
+    vpmu->context =3D ctxt;
     vpmu_set(vpmu, VPMU_CONTEXT_ALLOCATED);
     return 0;
 }
--- a/xen/arch/x86/hvm/vlapic.c
+++ b/xen/arch/x86/hvm/vlapic.c
@@ -53,7 +53,7 @@
     LVT_MASK | APIC_MODE_MASK | APIC_INPUT_POLARITY |\
     APIC_LVT_REMOTE_IRR | APIC_LVT_LEVEL_TRIGGER
=20
-static unsigned int vlapic_lvt_mask[VLAPIC_LVT_NUM] =3D
+static const unsigned int vlapic_lvt_mask[VLAPIC_LVT_NUM] =3D
 {
      /* LVTT */
      LVT_MASK | APIC_TIMER_MODE_MASK,
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -149,7 +149,7 @@ static void vmx_vcpu_destroy(struct vcpu
=20
 static DEFINE_PER_CPU(struct vmx_msr_state, host_msr_state);
=20
-static u32 msr_index[] =3D
+static const u32 msr_index[] =3D
 {
     MSR_LSTAR, MSR_STAR, MSR_SYSCALL_MASK
 };
--- a/xen/arch/x86/hvm/vmx/vpmu_core2.c
+++ b/xen/arch/x86/hvm/vmx/vpmu_core2.c
@@ -101,28 +101,30 @@ static void handle_pmc_quirk(u64 msr_con
     }
 }
=20
-u32 core2_counters_msr[] =3D   {
+static const u32 core2_counters_msr[] =3D {
     MSR_CORE_PERF_FIXED_CTR0,
     MSR_CORE_PERF_FIXED_CTR1,
-    MSR_CORE_PERF_FIXED_CTR2};
+    MSR_CORE_PERF_FIXED_CTR2
+};
=20
 /* Core 2 Non-architectual Performance Control MSRs. */
-u32 core2_ctrls_msr[] =3D {
+static const u32 core2_ctrls_msr[] =3D {
     MSR_CORE_PERF_FIXED_CTR_CTRL,
     MSR_IA32_PEBS_ENABLE,
-    MSR_IA32_DS_AREA};
+    MSR_IA32_DS_AREA
+};
=20
 struct pmumsr {
     unsigned int num;
-    u32 *msr;
+    const u32 *msr;
 };
=20
-struct pmumsr core2_counters =3D {
+static const struct pmumsr core2_counters =3D {
     3,
     core2_counters_msr
 };
=20
-struct pmumsr core2_ctrls =3D {
+static const struct pmumsr core2_ctrls =3D {
     3,
     core2_ctrls_msr
 };
--- a/xen/arch/x86/hvm/vmx/vvmx.c
+++ b/xen/arch/x86/hvm/vmx/vvmx.c
@@ -107,7 +107,7 @@ uint32_t nvmx_vcpu_asid(struct vcpu *v)
     return 0;
 }
=20
-enum x86_segment sreg_to_index[] =3D {
+static const enum x86_segment sreg_to_index[] =3D {
     [VMX_SREG_ES] =3D x86_seg_es,
     [VMX_SREG_CS] =3D x86_seg_cs,
     [VMX_SREG_SS] =3D x86_seg_ss,
@@ -633,7 +633,7 @@ u64 nvmx_get_tsc_offset(struct vcpu *v)
 /*
  * Context synchronized between shadow and virtual VMCS.
  */
-static unsigned long vmcs_gstate_field[] =3D {
+static const u16 vmcs_gstate_field[] =3D {
     /* 16 BITS */
     GUEST_ES_SELECTOR,
     GUEST_CS_SELECTOR,
@@ -698,7 +698,7 @@ static unsigned long vmcs_gstate_field[]
 /*
  * Context: shadow -> virtual VMCS
  */
-static unsigned long vmcs_ro_field[] =3D {
+static const u16 vmcs_ro_field[] =3D {
     GUEST_PHYSICAL_ADDRESS,
     VM_INSTRUCTION_ERROR,
     VM_EXIT_REASON,
@@ -713,9 +713,9 @@ static unsigned long vmcs_ro_field[] =3D {
 };
=20
 static struct vmcs_host_to_guest {
-    unsigned long host_field;
-    unsigned long guest_field;
-} vmcs_h2g_field[] =3D {
+    u16 host_field;
+    u16 guest_field;
+} const vmcs_h2g_field[] =3D {
     {HOST_ES_SELECTOR, GUEST_ES_SELECTOR},
     {HOST_CS_SELECTOR, GUEST_CS_SELECTOR},
     {HOST_SS_SELECTOR, GUEST_SS_SELECTOR},



--=__PartA091B2E5.0__=
Content-Type: text/plain; name="hvm-arrays.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="hvm-arrays.patch"

x86/hvm: constify static data where possible=0A=0AIn a few cases this also =
extends to making them static in the first=0Aplace.=0A=0ASigned-off-by: =
Jan Beulich <jbeulich@suse.com>=0A=0A--- a/xen/arch/x86/hvm/hvm.c=0A+++ =
b/xen/arch/x86/hvm/hvm.c=0A@@ -3123,7 +3123,7 @@ typedef unsigned long =
hvm_hypercall_t(=0A =0A #if defined(__i386__)=0A =0A-static hvm_hypercall_t=
 *hvm_hypercall32_table[NR_hypercalls] =3D {=0A+static hvm_hypercall_t =
*const hvm_hypercall32_table[NR_hypercalls] =3D {=0A     [ __HYPERVISOR_mem=
ory_op ] =3D (hvm_hypercall_t *)hvm_memory_op,=0A     [ __HYPERVISOR_grant_=
table_op ] =3D (hvm_hypercall_t *)hvm_grant_table_op,=0A     [ __HYPERVISOR=
_vcpu_op ] =3D (hvm_hypercall_t *)hvm_vcpu_op,=0A@@ -3208,7 +3208,7 @@ =
static long hvm_physdev_op_compat32(=0A     }=0A }=0A =0A-static hvm_hyperc=
all_t *hvm_hypercall64_table[NR_hypercalls] =3D {=0A+static hvm_hypercall_t=
 *const hvm_hypercall64_table[NR_hypercalls] =3D {=0A     [ __HYPERVISOR_me=
mory_op ] =3D (hvm_hypercall_t *)hvm_memory_op,=0A     [ __HYPERVISOR_grant=
_table_op ] =3D (hvm_hypercall_t *)hvm_grant_table_op,=0A     [ __HYPERVISO=
R_vcpu_op ] =3D (hvm_hypercall_t *)hvm_vcpu_op,=0A@@ -3225,7 +3225,7 @@ =
static hvm_hypercall_t *hvm_hypercall64_=0A #define COMPAT_CALL(x)         =
                               \=0A     [ __HYPERVISOR_ ## x ] =3D =
(hvm_hypercall_t *) compat_ ## x=0A =0A-static hvm_hypercall_t *hvm_hyperca=
ll32_table[NR_hypercalls] =3D {=0A+static hvm_hypercall_t *const hvm_hyperc=
all32_table[NR_hypercalls] =3D {=0A     [ __HYPERVISOR_memory_op ] =3D =
(hvm_hypercall_t *)hvm_memory_op_compat32,=0A     [ __HYPERVISOR_grant_tabl=
e_op ] =3D (hvm_hypercall_t *)hvm_grant_table_op_compat32,=0A     [ =
__HYPERVISOR_vcpu_op ] =3D (hvm_hypercall_t *)hvm_vcpu_op_compat32,=0A--- =
a/xen/arch/x86/hvm/mtrr.c=0A+++ b/xen/arch/x86/hvm/mtrr.c=0A@@ -34,14 =
+34,14 @@ static uint32_t size_or_mask;=0A #define pat_cr_2_paf(pat_cr,n)  =
((((uint64_t)pat_cr) >> ((n)<<3)) & 0xff)=0A =0A /* PAT entry to PTE flags =
(PAT, PCD, PWT bits). */=0A-static uint8_t pat_entry_2_pte_flags[8] =3D =
{=0A+static const uint8_t pat_entry_2_pte_flags[8] =3D {=0A     0,         =
  _PAGE_PWT,=0A     _PAGE_PCD,   _PAGE_PCD | _PAGE_PWT,=0A     _PAGE_PAT,  =
 _PAGE_PAT | _PAGE_PWT,=0A     _PAGE_PAT | _PAGE_PCD, _PAGE_PAT | =
_PAGE_PCD | _PAGE_PWT };=0A =0A /* Effective mm type lookup table, =
according to MTRR and PAT. */=0A-static uint8_t mm_type_tbl[MTRR_NUM_TYPES]=
[PAT_TYPE_NUMS] =3D {=0A+static const uint8_t mm_type_tbl[MTRR_NUM_TYPES][P=
AT_TYPE_NUMS] =3D {=0A /********PAT(UC,WC,RS,RS,WT,WP,WB,UC-)*/=0A /* RS =
means reserved type(2,3), and type is hardcoded here */=0A  /*MTRR(UC):(UC,=
WC,RS,RS,UC,UC,UC,UC)*/=0A--- a/xen/arch/x86/hvm/stdvga.c=0A+++ b/xen/arch/=
x86/hvm/stdvga.c=0A@@ -59,7 +59,7 @@ static const uint32_t mask16[16] =3D =
{=0A };=0A =0A /* force some bits to zero */=0A-const uint8_t sr_mask[8] =
=3D {=0A+static const uint8_t sr_mask[8] =3D {=0A     (uint8_t)~0xfc,=0A   =
  (uint8_t)~0xc2,=0A     (uint8_t)~0xf0,=0A@@ -70,7 +70,7 @@ const uint8_t =
sr_mask[8] =3D {=0A     (uint8_t)~0x00,=0A };=0A =0A-const uint8_t =
gr_mask[9] =3D {=0A+static const uint8_t gr_mask[9] =3D {=0A     (uint8_t)~=
0xf0, /* 0x00 */=0A     (uint8_t)~0xf0, /* 0x01 */=0A     (uint8_t)~0xf0, =
/* 0x02 */=0A--- a/xen/arch/x86/hvm/svm/emulate.c=0A+++ b/xen/arch/x86/hvm/=
svm/emulate.c=0A@@ -109,7 +109,7 @@ MAKE_INSTR(STGI,   3, 0x0f, 0x01, =
0xdc);=0A MAKE_INSTR(CLGI,   3, 0x0f, 0x01, 0xdd);=0A MAKE_INSTR(INVLPGA,3,=
 0x0f, 0x01, 0xdf);=0A =0A-static const u8 *opc_bytes[INSTR_MAX_COUNT] =3D =
=0A+static const u8 *const opc_bytes[INSTR_MAX_COUNT] =3D=0A {=0A     =
[INSTR_INVD]   =3D OPCODE_INVD,=0A     [INSTR_WBINVD] =3D OPCODE_WBINVD,=0A=
--- a/xen/arch/x86/hvm/svm/vpmu.c=0A+++ b/xen/arch/x86/hvm/svm/vpmu.c=0A@@ =
-44,13 +44,13 @@=0A #define set_guest_mode(msr) (msr |=3D (1ULL << =
MSR_F10H_EVNTSEL_GO_SHIFT))=0A #define is_overflowed(msr) (!((msr) & (1ULL =
<< (MSR_F10H_COUNTER_LENGTH-1))))=0A =0A-static int __read_mostly =
num_counters =3D 0;=0A-static u32 __read_mostly *counters =3D NULL;=0A-stat=
ic u32 __read_mostly *ctrls =3D NULL;=0A-static bool_t __read_mostly =
k7_counters_mirrored =3D 0;=0A+static unsigned int __read_mostly num_counte=
rs;=0A+static const u32 __read_mostly *counters;=0A+static const u32 =
__read_mostly *ctrls;=0A+static bool_t __read_mostly k7_counters_mirrored;=
=0A =0A /* PMU Counter MSRs. */=0A-u32 AMD_F10H_COUNTERS[] =3D {=0A+static =
const u32 AMD_F10H_COUNTERS[] =3D {=0A     MSR_K7_PERFCTR0,=0A     =
MSR_K7_PERFCTR1,=0A     MSR_K7_PERFCTR2,=0A@@ -58,14 +58,14 @@ u32 =
AMD_F10H_COUNTERS[] =3D {=0A };=0A =0A /* PMU Control MSRs. */=0A-u32 =
AMD_F10H_CTRLS[] =3D {=0A+static const u32 AMD_F10H_CTRLS[] =3D {=0A     =
MSR_K7_EVNTSEL0,=0A     MSR_K7_EVNTSEL1,=0A     MSR_K7_EVNTSEL2,=0A     =
MSR_K7_EVNTSEL3=0A };=0A =0A-u32 AMD_F15H_COUNTERS[] =3D {=0A+static const =
u32 AMD_F15H_COUNTERS[] =3D {=0A     MSR_AMD_FAM15H_PERFCTR0,=0A     =
MSR_AMD_FAM15H_PERFCTR1,=0A     MSR_AMD_FAM15H_PERFCTR2,=0A@@ -74,7 +74,7 =
@@ u32 AMD_F15H_COUNTERS[] =3D {=0A     MSR_AMD_FAM15H_PERFCTR5=0A };=0A =
=0A-u32 AMD_F15H_CTRLS[] =3D {=0A+static const u32 AMD_F15H_CTRLS[] =3D =
{=0A     MSR_AMD_FAM15H_EVNTSEL0,=0A     MSR_AMD_FAM15H_EVNTSEL1,=0A     =
MSR_AMD_FAM15H_EVNTSEL2,=0A@@ -161,7 +161,7 @@ static int amd_vpmu_do_inter=
rupt(struct =0A =0A static inline void context_restore(struct vcpu *v)=0A =
{=0A-    u64 i;=0A+    unsigned int i;=0A     struct vpmu_struct *vpmu =3D =
vcpu_vpmu(v);=0A     struct amd_vpmu_context *ctxt =3D vpmu->context;=0A =
=0A@@ -198,7 +198,7 @@ static void amd_vpmu_restore(struct vcpu=0A =0A =
static inline void context_save(struct vcpu *v)=0A {=0A-    int i;=0A+    =
unsigned int i;=0A     struct vpmu_struct *vpmu =3D vcpu_vpmu(v);=0A     =
struct amd_vpmu_context *ctxt =3D vpmu->context;=0A =0A@@ -225,7 +225,7 @@ =
static void amd_vpmu_save(struct vcpu *v=0A =0A static void context_update(=
unsigned int msr, u64 msr_content)=0A {=0A-    int i;=0A+    unsigned int =
i;=0A     struct vcpu *v =3D current;=0A     struct vpmu_struct *vpmu =3D =
vcpu_vpmu(v);=0A     struct amd_vpmu_context *ctxt =3D vpmu->context;=0A@@ =
-294,7 +294,7 @@ static int amd_vpmu_do_rdmsr(unsigned in=0A =0A static =
int amd_vpmu_initialise(struct vcpu *v)=0A {=0A-    struct amd_vpmu_context=
 *ctxt =3D NULL;=0A+    struct amd_vpmu_context *ctxt;=0A     struct =
vpmu_struct *vpmu =3D vcpu_vpmu(v);=0A     uint8_t family =3D current_cpu_d=
ata.x86;=0A =0A@@ -323,7 +323,7 @@ static int amd_vpmu_initialise(struct =
vc=0A 	 }=0A     }=0A =0A-    ctxt =3D xzalloc_bytes(sizeof(struct =
amd_vpmu_context));=0A+    ctxt =3D xzalloc(struct amd_vpmu_context);=0A   =
  if ( !ctxt )=0A     {=0A         gdprintk(XENLOG_WARNING, "Insufficient =
memory for PMU, "=0A@@ -332,7 +332,7 @@ static int amd_vpmu_initialise(stru=
ct vc=0A         return -ENOMEM;=0A     }=0A =0A-    vpmu->context =3D =
(void *)ctxt;=0A+    vpmu->context =3D ctxt;=0A     vpmu_set(vpmu, =
VPMU_CONTEXT_ALLOCATED);=0A     return 0;=0A }=0A--- a/xen/arch/x86/hvm/vla=
pic.c=0A+++ b/xen/arch/x86/hvm/vlapic.c=0A@@ -53,7 +53,7 @@=0A     =
LVT_MASK | APIC_MODE_MASK | APIC_INPUT_POLARITY |\=0A     APIC_LVT_REMOTE_I=
RR | APIC_LVT_LEVEL_TRIGGER=0A =0A-static unsigned int vlapic_lvt_mask[VLAP=
IC_LVT_NUM] =3D=0A+static const unsigned int vlapic_lvt_mask[VLAPIC_LVT_NUM=
] =3D=0A {=0A      /* LVTT */=0A      LVT_MASK | APIC_TIMER_MODE_MASK,=0A--=
- a/xen/arch/x86/hvm/vmx/vmx.c=0A+++ b/xen/arch/x86/hvm/vmx/vmx.c=0A@@ =
-149,7 +149,7 @@ static void vmx_vcpu_destroy(struct vcpu=0A =0A static =
DEFINE_PER_CPU(struct vmx_msr_state, host_msr_state);=0A =0A-static u32 =
msr_index[] =3D=0A+static const u32 msr_index[] =3D=0A {=0A     MSR_LSTAR, =
MSR_STAR, MSR_SYSCALL_MASK=0A };=0A--- a/xen/arch/x86/hvm/vmx/vpmu_core2.c=
=0A+++ b/xen/arch/x86/hvm/vmx/vpmu_core2.c=0A@@ -101,28 +101,30 @@ static =
void handle_pmc_quirk(u64 msr_con=0A     }=0A }=0A =0A-u32 core2_counters_m=
sr[] =3D   {=0A+static const u32 core2_counters_msr[] =3D {=0A     =
MSR_CORE_PERF_FIXED_CTR0,=0A     MSR_CORE_PERF_FIXED_CTR1,=0A-    =
MSR_CORE_PERF_FIXED_CTR2};=0A+    MSR_CORE_PERF_FIXED_CTR2=0A+};=0A =0A /* =
Core 2 Non-architectual Performance Control MSRs. */=0A-u32 core2_ctrls_msr=
[] =3D {=0A+static const u32 core2_ctrls_msr[] =3D {=0A     MSR_CORE_PERF_F=
IXED_CTR_CTRL,=0A     MSR_IA32_PEBS_ENABLE,=0A-    MSR_IA32_DS_AREA};=0A+  =
  MSR_IA32_DS_AREA=0A+};=0A =0A struct pmumsr {=0A     unsigned int =
num;=0A-    u32 *msr;=0A+    const u32 *msr;=0A };=0A =0A-struct pmumsr =
core2_counters =3D {=0A+static const struct pmumsr core2_counters =3D {=0A =
    3,=0A     core2_counters_msr=0A };=0A =0A-struct pmumsr core2_ctrls =
=3D {=0A+static const struct pmumsr core2_ctrls =3D {=0A     3,=0A     =
core2_ctrls_msr=0A };=0A--- a/xen/arch/x86/hvm/vmx/vvmx.c=0A+++ b/xen/arch/=
x86/hvm/vmx/vvmx.c=0A@@ -107,7 +107,7 @@ uint32_t nvmx_vcpu_asid(struct =
vcpu *v)=0A     return 0;=0A }=0A =0A-enum x86_segment sreg_to_index[] =3D =
{=0A+static const enum x86_segment sreg_to_index[] =3D {=0A     [VMX_SREG_E=
S] =3D x86_seg_es,=0A     [VMX_SREG_CS] =3D x86_seg_cs,=0A     [VMX_SREG_SS=
] =3D x86_seg_ss,=0A@@ -633,7 +633,7 @@ u64 nvmx_get_tsc_offset(struct =
vcpu *v)=0A /*=0A  * Context synchronized between shadow and virtual =
VMCS.=0A  */=0A-static unsigned long vmcs_gstate_field[] =3D {=0A+static =
const u16 vmcs_gstate_field[] =3D {=0A     /* 16 BITS */=0A     GUEST_ES_SE=
LECTOR,=0A     GUEST_CS_SELECTOR,=0A@@ -698,7 +698,7 @@ static unsigned =
long vmcs_gstate_field[]=0A /*=0A  * Context: shadow -> virtual VMCS=0A  =
*/=0A-static unsigned long vmcs_ro_field[] =3D {=0A+static const u16 =
vmcs_ro_field[] =3D {=0A     GUEST_PHYSICAL_ADDRESS,=0A     VM_INSTRUCTION_=
ERROR,=0A     VM_EXIT_REASON,=0A@@ -713,9 +713,9 @@ static unsigned long =
vmcs_ro_field[] =3D {=0A };=0A =0A static struct vmcs_host_to_guest {=0A-  =
  unsigned long host_field;=0A-    unsigned long guest_field;=0A-} =
vmcs_h2g_field[] =3D {=0A+    u16 host_field;=0A+    u16 guest_field;=0A+} =
const vmcs_h2g_field[] =3D {=0A     {HOST_ES_SELECTOR, GUEST_ES_SELECTOR},=
=0A     {HOST_CS_SELECTOR, GUEST_CS_SELECTOR},=0A     {HOST_SS_SELECTOR, =
GUEST_SS_SELECTOR},=0A
--=__PartA091B2E5.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

--=__PartA091B2E5.0__=--


From xen-devel-bounces@lists.xen.org Tue Sep 11 12:48:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 2012 12:48:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TBPsi-0000iz-3C; Tue, 11 Sep 2012 12:47:56 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1TBPsg-0000iT-Tw
	for xen-devel@lists.xen.org; Tue, 11 Sep 2012 12:47:55 +0000
Received: from [85.158.143.35:37517] by server-2.bemta-4.messagelabs.com id
	16/50-21239-AF23F405; Tue, 11 Sep 2012 12:47:54 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1347367672!11909690!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQwNzc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5484 invoked from network); 11 Sep 2012 12:47: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;
	11 Sep 2012 12:47:52 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 11 Sep 2012 13:47:52 +0100
Message-Id: <504F4F15020000780009A99B@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 11 Sep 2012 13:47:49 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__PartA091B2E5.0__="
Subject: [Xen-devel] [PATCH 2/3] x86/hvm: constify static data where possible
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<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.

--=__PartA091B2E5.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

In a few cases this also extends to making them static in the first
place.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -3123,7 +3123,7 @@ typedef unsigned long hvm_hypercall_t(
=20
 #if defined(__i386__)
=20
-static hvm_hypercall_t *hvm_hypercall32_table[NR_hypercalls] =3D {
+static hvm_hypercall_t *const hvm_hypercall32_table[NR_hypercalls] =3D {
     [ __HYPERVISOR_memory_op ] =3D (hvm_hypercall_t *)hvm_memory_op,
     [ __HYPERVISOR_grant_table_op ] =3D (hvm_hypercall_t *)hvm_grant_table=
_op,
     [ __HYPERVISOR_vcpu_op ] =3D (hvm_hypercall_t *)hvm_vcpu_op,
@@ -3208,7 +3208,7 @@ static long hvm_physdev_op_compat32(
     }
 }
=20
-static hvm_hypercall_t *hvm_hypercall64_table[NR_hypercalls] =3D {
+static hvm_hypercall_t *const hvm_hypercall64_table[NR_hypercalls] =3D {
     [ __HYPERVISOR_memory_op ] =3D (hvm_hypercall_t *)hvm_memory_op,
     [ __HYPERVISOR_grant_table_op ] =3D (hvm_hypercall_t *)hvm_grant_table=
_op,
     [ __HYPERVISOR_vcpu_op ] =3D (hvm_hypercall_t *)hvm_vcpu_op,
@@ -3225,7 +3225,7 @@ static hvm_hypercall_t *hvm_hypercall64_
 #define COMPAT_CALL(x)                                        \
     [ __HYPERVISOR_ ## x ] =3D (hvm_hypercall_t *) compat_ ## x
=20
-static hvm_hypercall_t *hvm_hypercall32_table[NR_hypercalls] =3D {
+static hvm_hypercall_t *const hvm_hypercall32_table[NR_hypercalls] =3D {
     [ __HYPERVISOR_memory_op ] =3D (hvm_hypercall_t *)hvm_memory_op_compat=
32,
     [ __HYPERVISOR_grant_table_op ] =3D (hvm_hypercall_t *)hvm_grant_table=
_op_compat32,
     [ __HYPERVISOR_vcpu_op ] =3D (hvm_hypercall_t *)hvm_vcpu_op_compat32,
--- a/xen/arch/x86/hvm/mtrr.c
+++ b/xen/arch/x86/hvm/mtrr.c
@@ -34,14 +34,14 @@ static uint32_t size_or_mask;
 #define pat_cr_2_paf(pat_cr,n)  ((((uint64_t)pat_cr) >> ((n)<<3)) & 0xff)
=20
 /* PAT entry to PTE flags (PAT, PCD, PWT bits). */
-static uint8_t pat_entry_2_pte_flags[8] =3D {
+static const uint8_t pat_entry_2_pte_flags[8] =3D {
     0,           _PAGE_PWT,
     _PAGE_PCD,   _PAGE_PCD | _PAGE_PWT,
     _PAGE_PAT,   _PAGE_PAT | _PAGE_PWT,
     _PAGE_PAT | _PAGE_PCD, _PAGE_PAT | _PAGE_PCD | _PAGE_PWT };
=20
 /* Effective mm type lookup table, according to MTRR and PAT. */
-static uint8_t mm_type_tbl[MTRR_NUM_TYPES][PAT_TYPE_NUMS] =3D {
+static const uint8_t mm_type_tbl[MTRR_NUM_TYPES][PAT_TYPE_NUMS] =3D {
 /********PAT(UC,WC,RS,RS,WT,WP,WB,UC-)*/
 /* RS means reserved type(2,3), and type is hardcoded here */
  /*MTRR(UC):(UC,WC,RS,RS,UC,UC,UC,UC)*/
--- a/xen/arch/x86/hvm/stdvga.c
+++ b/xen/arch/x86/hvm/stdvga.c
@@ -59,7 +59,7 @@ static const uint32_t mask16[16] =3D {
 };
=20
 /* force some bits to zero */
-const uint8_t sr_mask[8] =3D {
+static const uint8_t sr_mask[8] =3D {
     (uint8_t)~0xfc,
     (uint8_t)~0xc2,
     (uint8_t)~0xf0,
@@ -70,7 +70,7 @@ const uint8_t sr_mask[8] =3D {
     (uint8_t)~0x00,
 };
=20
-const uint8_t gr_mask[9] =3D {
+static const uint8_t gr_mask[9] =3D {
     (uint8_t)~0xf0, /* 0x00 */
     (uint8_t)~0xf0, /* 0x01 */
     (uint8_t)~0xf0, /* 0x02 */
--- a/xen/arch/x86/hvm/svm/emulate.c
+++ b/xen/arch/x86/hvm/svm/emulate.c
@@ -109,7 +109,7 @@ MAKE_INSTR(STGI,   3, 0x0f, 0x01, 0xdc);
 MAKE_INSTR(CLGI,   3, 0x0f, 0x01, 0xdd);
 MAKE_INSTR(INVLPGA,3, 0x0f, 0x01, 0xdf);
=20
-static const u8 *opc_bytes[INSTR_MAX_COUNT] =3D=20
+static const u8 *const opc_bytes[INSTR_MAX_COUNT] =3D
 {
     [INSTR_INVD]   =3D OPCODE_INVD,
     [INSTR_WBINVD] =3D OPCODE_WBINVD,
--- a/xen/arch/x86/hvm/svm/vpmu.c
+++ b/xen/arch/x86/hvm/svm/vpmu.c
@@ -44,13 +44,13 @@
 #define set_guest_mode(msr) (msr |=3D (1ULL << MSR_F10H_EVNTSEL_GO_SHIFT))=

 #define is_overflowed(msr) (!((msr) & (1ULL << (MSR_F10H_COUNTER_LENGTH-1)=
)))
=20
-static int __read_mostly num_counters =3D 0;
-static u32 __read_mostly *counters =3D NULL;
-static u32 __read_mostly *ctrls =3D NULL;
-static bool_t __read_mostly k7_counters_mirrored =3D 0;
+static unsigned int __read_mostly num_counters;
+static const u32 __read_mostly *counters;
+static const u32 __read_mostly *ctrls;
+static bool_t __read_mostly k7_counters_mirrored;
=20
 /* PMU Counter MSRs. */
-u32 AMD_F10H_COUNTERS[] =3D {
+static const u32 AMD_F10H_COUNTERS[] =3D {
     MSR_K7_PERFCTR0,
     MSR_K7_PERFCTR1,
     MSR_K7_PERFCTR2,
@@ -58,14 +58,14 @@ u32 AMD_F10H_COUNTERS[] =3D {
 };
=20
 /* PMU Control MSRs. */
-u32 AMD_F10H_CTRLS[] =3D {
+static const u32 AMD_F10H_CTRLS[] =3D {
     MSR_K7_EVNTSEL0,
     MSR_K7_EVNTSEL1,
     MSR_K7_EVNTSEL2,
     MSR_K7_EVNTSEL3
 };
=20
-u32 AMD_F15H_COUNTERS[] =3D {
+static const u32 AMD_F15H_COUNTERS[] =3D {
     MSR_AMD_FAM15H_PERFCTR0,
     MSR_AMD_FAM15H_PERFCTR1,
     MSR_AMD_FAM15H_PERFCTR2,
@@ -74,7 +74,7 @@ u32 AMD_F15H_COUNTERS[] =3D {
     MSR_AMD_FAM15H_PERFCTR5
 };
=20
-u32 AMD_F15H_CTRLS[] =3D {
+static const u32 AMD_F15H_CTRLS[] =3D {
     MSR_AMD_FAM15H_EVNTSEL0,
     MSR_AMD_FAM15H_EVNTSEL1,
     MSR_AMD_FAM15H_EVNTSEL2,
@@ -161,7 +161,7 @@ static int amd_vpmu_do_interrupt(struct=20
=20
 static inline void context_restore(struct vcpu *v)
 {
-    u64 i;
+    unsigned int i;
     struct vpmu_struct *vpmu =3D vcpu_vpmu(v);
     struct amd_vpmu_context *ctxt =3D vpmu->context;
=20
@@ -198,7 +198,7 @@ static void amd_vpmu_restore(struct vcpu
=20
 static inline void context_save(struct vcpu *v)
 {
-    int i;
+    unsigned int i;
     struct vpmu_struct *vpmu =3D vcpu_vpmu(v);
     struct amd_vpmu_context *ctxt =3D vpmu->context;
=20
@@ -225,7 +225,7 @@ static void amd_vpmu_save(struct vcpu *v
=20
 static void context_update(unsigned int msr, u64 msr_content)
 {
-    int i;
+    unsigned int i;
     struct vcpu *v =3D current;
     struct vpmu_struct *vpmu =3D vcpu_vpmu(v);
     struct amd_vpmu_context *ctxt =3D vpmu->context;
@@ -294,7 +294,7 @@ static int amd_vpmu_do_rdmsr(unsigned in
=20
 static int amd_vpmu_initialise(struct vcpu *v)
 {
-    struct amd_vpmu_context *ctxt =3D NULL;
+    struct amd_vpmu_context *ctxt;
     struct vpmu_struct *vpmu =3D vcpu_vpmu(v);
     uint8_t family =3D current_cpu_data.x86;
=20
@@ -323,7 +323,7 @@ static int amd_vpmu_initialise(struct vc
 	 }
     }
=20
-    ctxt =3D xzalloc_bytes(sizeof(struct amd_vpmu_context));
+    ctxt =3D xzalloc(struct amd_vpmu_context);
     if ( !ctxt )
     {
         gdprintk(XENLOG_WARNING, "Insufficient memory for PMU, "
@@ -332,7 +332,7 @@ static int amd_vpmu_initialise(struct vc
         return -ENOMEM;
     }
=20
-    vpmu->context =3D (void *)ctxt;
+    vpmu->context =3D ctxt;
     vpmu_set(vpmu, VPMU_CONTEXT_ALLOCATED);
     return 0;
 }
--- a/xen/arch/x86/hvm/vlapic.c
+++ b/xen/arch/x86/hvm/vlapic.c
@@ -53,7 +53,7 @@
     LVT_MASK | APIC_MODE_MASK | APIC_INPUT_POLARITY |\
     APIC_LVT_REMOTE_IRR | APIC_LVT_LEVEL_TRIGGER
=20
-static unsigned int vlapic_lvt_mask[VLAPIC_LVT_NUM] =3D
+static const unsigned int vlapic_lvt_mask[VLAPIC_LVT_NUM] =3D
 {
      /* LVTT */
      LVT_MASK | APIC_TIMER_MODE_MASK,
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -149,7 +149,7 @@ static void vmx_vcpu_destroy(struct vcpu
=20
 static DEFINE_PER_CPU(struct vmx_msr_state, host_msr_state);
=20
-static u32 msr_index[] =3D
+static const u32 msr_index[] =3D
 {
     MSR_LSTAR, MSR_STAR, MSR_SYSCALL_MASK
 };
--- a/xen/arch/x86/hvm/vmx/vpmu_core2.c
+++ b/xen/arch/x86/hvm/vmx/vpmu_core2.c
@@ -101,28 +101,30 @@ static void handle_pmc_quirk(u64 msr_con
     }
 }
=20
-u32 core2_counters_msr[] =3D   {
+static const u32 core2_counters_msr[] =3D {
     MSR_CORE_PERF_FIXED_CTR0,
     MSR_CORE_PERF_FIXED_CTR1,
-    MSR_CORE_PERF_FIXED_CTR2};
+    MSR_CORE_PERF_FIXED_CTR2
+};
=20
 /* Core 2 Non-architectual Performance Control MSRs. */
-u32 core2_ctrls_msr[] =3D {
+static const u32 core2_ctrls_msr[] =3D {
     MSR_CORE_PERF_FIXED_CTR_CTRL,
     MSR_IA32_PEBS_ENABLE,
-    MSR_IA32_DS_AREA};
+    MSR_IA32_DS_AREA
+};
=20
 struct pmumsr {
     unsigned int num;
-    u32 *msr;
+    const u32 *msr;
 };
=20
-struct pmumsr core2_counters =3D {
+static const struct pmumsr core2_counters =3D {
     3,
     core2_counters_msr
 };
=20
-struct pmumsr core2_ctrls =3D {
+static const struct pmumsr core2_ctrls =3D {
     3,
     core2_ctrls_msr
 };
--- a/xen/arch/x86/hvm/vmx/vvmx.c
+++ b/xen/arch/x86/hvm/vmx/vvmx.c
@@ -107,7 +107,7 @@ uint32_t nvmx_vcpu_asid(struct vcpu *v)
     return 0;
 }
=20
-enum x86_segment sreg_to_index[] =3D {
+static const enum x86_segment sreg_to_index[] =3D {
     [VMX_SREG_ES] =3D x86_seg_es,
     [VMX_SREG_CS] =3D x86_seg_cs,
     [VMX_SREG_SS] =3D x86_seg_ss,
@@ -633,7 +633,7 @@ u64 nvmx_get_tsc_offset(struct vcpu *v)
 /*
  * Context synchronized between shadow and virtual VMCS.
  */
-static unsigned long vmcs_gstate_field[] =3D {
+static const u16 vmcs_gstate_field[] =3D {
     /* 16 BITS */
     GUEST_ES_SELECTOR,
     GUEST_CS_SELECTOR,
@@ -698,7 +698,7 @@ static unsigned long vmcs_gstate_field[]
 /*
  * Context: shadow -> virtual VMCS
  */
-static unsigned long vmcs_ro_field[] =3D {
+static const u16 vmcs_ro_field[] =3D {
     GUEST_PHYSICAL_ADDRESS,
     VM_INSTRUCTION_ERROR,
     VM_EXIT_REASON,
@@ -713,9 +713,9 @@ static unsigned long vmcs_ro_field[] =3D {
 };
=20
 static struct vmcs_host_to_guest {
-    unsigned long host_field;
-    unsigned long guest_field;
-} vmcs_h2g_field[] =3D {
+    u16 host_field;
+    u16 guest_field;
+} const vmcs_h2g_field[] =3D {
     {HOST_ES_SELECTOR, GUEST_ES_SELECTOR},
     {HOST_CS_SELECTOR, GUEST_CS_SELECTOR},
     {HOST_SS_SELECTOR, GUEST_SS_SELECTOR},



--=__PartA091B2E5.0__=
Content-Type: text/plain; name="hvm-arrays.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="hvm-arrays.patch"

x86/hvm: constify static data where possible=0A=0AIn a few cases this also =
extends to making them static in the first=0Aplace.=0A=0ASigned-off-by: =
Jan Beulich <jbeulich@suse.com>=0A=0A--- a/xen/arch/x86/hvm/hvm.c=0A+++ =
b/xen/arch/x86/hvm/hvm.c=0A@@ -3123,7 +3123,7 @@ typedef unsigned long =
hvm_hypercall_t(=0A =0A #if defined(__i386__)=0A =0A-static hvm_hypercall_t=
 *hvm_hypercall32_table[NR_hypercalls] =3D {=0A+static hvm_hypercall_t =
*const hvm_hypercall32_table[NR_hypercalls] =3D {=0A     [ __HYPERVISOR_mem=
ory_op ] =3D (hvm_hypercall_t *)hvm_memory_op,=0A     [ __HYPERVISOR_grant_=
table_op ] =3D (hvm_hypercall_t *)hvm_grant_table_op,=0A     [ __HYPERVISOR=
_vcpu_op ] =3D (hvm_hypercall_t *)hvm_vcpu_op,=0A@@ -3208,7 +3208,7 @@ =
static long hvm_physdev_op_compat32(=0A     }=0A }=0A =0A-static hvm_hyperc=
all_t *hvm_hypercall64_table[NR_hypercalls] =3D {=0A+static hvm_hypercall_t=
 *const hvm_hypercall64_table[NR_hypercalls] =3D {=0A     [ __HYPERVISOR_me=
mory_op ] =3D (hvm_hypercall_t *)hvm_memory_op,=0A     [ __HYPERVISOR_grant=
_table_op ] =3D (hvm_hypercall_t *)hvm_grant_table_op,=0A     [ __HYPERVISO=
R_vcpu_op ] =3D (hvm_hypercall_t *)hvm_vcpu_op,=0A@@ -3225,7 +3225,7 @@ =
static hvm_hypercall_t *hvm_hypercall64_=0A #define COMPAT_CALL(x)         =
                               \=0A     [ __HYPERVISOR_ ## x ] =3D =
(hvm_hypercall_t *) compat_ ## x=0A =0A-static hvm_hypercall_t *hvm_hyperca=
ll32_table[NR_hypercalls] =3D {=0A+static hvm_hypercall_t *const hvm_hyperc=
all32_table[NR_hypercalls] =3D {=0A     [ __HYPERVISOR_memory_op ] =3D =
(hvm_hypercall_t *)hvm_memory_op_compat32,=0A     [ __HYPERVISOR_grant_tabl=
e_op ] =3D (hvm_hypercall_t *)hvm_grant_table_op_compat32,=0A     [ =
__HYPERVISOR_vcpu_op ] =3D (hvm_hypercall_t *)hvm_vcpu_op_compat32,=0A--- =
a/xen/arch/x86/hvm/mtrr.c=0A+++ b/xen/arch/x86/hvm/mtrr.c=0A@@ -34,14 =
+34,14 @@ static uint32_t size_or_mask;=0A #define pat_cr_2_paf(pat_cr,n)  =
((((uint64_t)pat_cr) >> ((n)<<3)) & 0xff)=0A =0A /* PAT entry to PTE flags =
(PAT, PCD, PWT bits). */=0A-static uint8_t pat_entry_2_pte_flags[8] =3D =
{=0A+static const uint8_t pat_entry_2_pte_flags[8] =3D {=0A     0,         =
  _PAGE_PWT,=0A     _PAGE_PCD,   _PAGE_PCD | _PAGE_PWT,=0A     _PAGE_PAT,  =
 _PAGE_PAT | _PAGE_PWT,=0A     _PAGE_PAT | _PAGE_PCD, _PAGE_PAT | =
_PAGE_PCD | _PAGE_PWT };=0A =0A /* Effective mm type lookup table, =
according to MTRR and PAT. */=0A-static uint8_t mm_type_tbl[MTRR_NUM_TYPES]=
[PAT_TYPE_NUMS] =3D {=0A+static const uint8_t mm_type_tbl[MTRR_NUM_TYPES][P=
AT_TYPE_NUMS] =3D {=0A /********PAT(UC,WC,RS,RS,WT,WP,WB,UC-)*/=0A /* RS =
means reserved type(2,3), and type is hardcoded here */=0A  /*MTRR(UC):(UC,=
WC,RS,RS,UC,UC,UC,UC)*/=0A--- a/xen/arch/x86/hvm/stdvga.c=0A+++ b/xen/arch/=
x86/hvm/stdvga.c=0A@@ -59,7 +59,7 @@ static const uint32_t mask16[16] =3D =
{=0A };=0A =0A /* force some bits to zero */=0A-const uint8_t sr_mask[8] =
=3D {=0A+static const uint8_t sr_mask[8] =3D {=0A     (uint8_t)~0xfc,=0A   =
  (uint8_t)~0xc2,=0A     (uint8_t)~0xf0,=0A@@ -70,7 +70,7 @@ const uint8_t =
sr_mask[8] =3D {=0A     (uint8_t)~0x00,=0A };=0A =0A-const uint8_t =
gr_mask[9] =3D {=0A+static const uint8_t gr_mask[9] =3D {=0A     (uint8_t)~=
0xf0, /* 0x00 */=0A     (uint8_t)~0xf0, /* 0x01 */=0A     (uint8_t)~0xf0, =
/* 0x02 */=0A--- a/xen/arch/x86/hvm/svm/emulate.c=0A+++ b/xen/arch/x86/hvm/=
svm/emulate.c=0A@@ -109,7 +109,7 @@ MAKE_INSTR(STGI,   3, 0x0f, 0x01, =
0xdc);=0A MAKE_INSTR(CLGI,   3, 0x0f, 0x01, 0xdd);=0A MAKE_INSTR(INVLPGA,3,=
 0x0f, 0x01, 0xdf);=0A =0A-static const u8 *opc_bytes[INSTR_MAX_COUNT] =3D =
=0A+static const u8 *const opc_bytes[INSTR_MAX_COUNT] =3D=0A {=0A     =
[INSTR_INVD]   =3D OPCODE_INVD,=0A     [INSTR_WBINVD] =3D OPCODE_WBINVD,=0A=
--- a/xen/arch/x86/hvm/svm/vpmu.c=0A+++ b/xen/arch/x86/hvm/svm/vpmu.c=0A@@ =
-44,13 +44,13 @@=0A #define set_guest_mode(msr) (msr |=3D (1ULL << =
MSR_F10H_EVNTSEL_GO_SHIFT))=0A #define is_overflowed(msr) (!((msr) & (1ULL =
<< (MSR_F10H_COUNTER_LENGTH-1))))=0A =0A-static int __read_mostly =
num_counters =3D 0;=0A-static u32 __read_mostly *counters =3D NULL;=0A-stat=
ic u32 __read_mostly *ctrls =3D NULL;=0A-static bool_t __read_mostly =
k7_counters_mirrored =3D 0;=0A+static unsigned int __read_mostly num_counte=
rs;=0A+static const u32 __read_mostly *counters;=0A+static const u32 =
__read_mostly *ctrls;=0A+static bool_t __read_mostly k7_counters_mirrored;=
=0A =0A /* PMU Counter MSRs. */=0A-u32 AMD_F10H_COUNTERS[] =3D {=0A+static =
const u32 AMD_F10H_COUNTERS[] =3D {=0A     MSR_K7_PERFCTR0,=0A     =
MSR_K7_PERFCTR1,=0A     MSR_K7_PERFCTR2,=0A@@ -58,14 +58,14 @@ u32 =
AMD_F10H_COUNTERS[] =3D {=0A };=0A =0A /* PMU Control MSRs. */=0A-u32 =
AMD_F10H_CTRLS[] =3D {=0A+static const u32 AMD_F10H_CTRLS[] =3D {=0A     =
MSR_K7_EVNTSEL0,=0A     MSR_K7_EVNTSEL1,=0A     MSR_K7_EVNTSEL2,=0A     =
MSR_K7_EVNTSEL3=0A };=0A =0A-u32 AMD_F15H_COUNTERS[] =3D {=0A+static const =
u32 AMD_F15H_COUNTERS[] =3D {=0A     MSR_AMD_FAM15H_PERFCTR0,=0A     =
MSR_AMD_FAM15H_PERFCTR1,=0A     MSR_AMD_FAM15H_PERFCTR2,=0A@@ -74,7 +74,7 =
@@ u32 AMD_F15H_COUNTERS[] =3D {=0A     MSR_AMD_FAM15H_PERFCTR5=0A };=0A =
=0A-u32 AMD_F15H_CTRLS[] =3D {=0A+static const u32 AMD_F15H_CTRLS[] =3D =
{=0A     MSR_AMD_FAM15H_EVNTSEL0,=0A     MSR_AMD_FAM15H_EVNTSEL1,=0A     =
MSR_AMD_FAM15H_EVNTSEL2,=0A@@ -161,7 +161,7 @@ static int amd_vpmu_do_inter=
rupt(struct =0A =0A static inline void context_restore(struct vcpu *v)=0A =
{=0A-    u64 i;=0A+    unsigned int i;=0A     struct vpmu_struct *vpmu =3D =
vcpu_vpmu(v);=0A     struct amd_vpmu_context *ctxt =3D vpmu->context;=0A =
=0A@@ -198,7 +198,7 @@ static void amd_vpmu_restore(struct vcpu=0A =0A =
static inline void context_save(struct vcpu *v)=0A {=0A-    int i;=0A+    =
unsigned int i;=0A     struct vpmu_struct *vpmu =3D vcpu_vpmu(v);=0A     =
struct amd_vpmu_context *ctxt =3D vpmu->context;=0A =0A@@ -225,7 +225,7 @@ =
static void amd_vpmu_save(struct vcpu *v=0A =0A static void context_update(=
unsigned int msr, u64 msr_content)=0A {=0A-    int i;=0A+    unsigned int =
i;=0A     struct vcpu *v =3D current;=0A     struct vpmu_struct *vpmu =3D =
vcpu_vpmu(v);=0A     struct amd_vpmu_context *ctxt =3D vpmu->context;=0A@@ =
-294,7 +294,7 @@ static int amd_vpmu_do_rdmsr(unsigned in=0A =0A static =
int amd_vpmu_initialise(struct vcpu *v)=0A {=0A-    struct amd_vpmu_context=
 *ctxt =3D NULL;=0A+    struct amd_vpmu_context *ctxt;=0A     struct =
vpmu_struct *vpmu =3D vcpu_vpmu(v);=0A     uint8_t family =3D current_cpu_d=
ata.x86;=0A =0A@@ -323,7 +323,7 @@ static int amd_vpmu_initialise(struct =
vc=0A 	 }=0A     }=0A =0A-    ctxt =3D xzalloc_bytes(sizeof(struct =
amd_vpmu_context));=0A+    ctxt =3D xzalloc(struct amd_vpmu_context);=0A   =
  if ( !ctxt )=0A     {=0A         gdprintk(XENLOG_WARNING, "Insufficient =
memory for PMU, "=0A@@ -332,7 +332,7 @@ static int amd_vpmu_initialise(stru=
ct vc=0A         return -ENOMEM;=0A     }=0A =0A-    vpmu->context =3D =
(void *)ctxt;=0A+    vpmu->context =3D ctxt;=0A     vpmu_set(vpmu, =
VPMU_CONTEXT_ALLOCATED);=0A     return 0;=0A }=0A--- a/xen/arch/x86/hvm/vla=
pic.c=0A+++ b/xen/arch/x86/hvm/vlapic.c=0A@@ -53,7 +53,7 @@=0A     =
LVT_MASK | APIC_MODE_MASK | APIC_INPUT_POLARITY |\=0A     APIC_LVT_REMOTE_I=
RR | APIC_LVT_LEVEL_TRIGGER=0A =0A-static unsigned int vlapic_lvt_mask[VLAP=
IC_LVT_NUM] =3D=0A+static const unsigned int vlapic_lvt_mask[VLAPIC_LVT_NUM=
] =3D=0A {=0A      /* LVTT */=0A      LVT_MASK | APIC_TIMER_MODE_MASK,=0A--=
- a/xen/arch/x86/hvm/vmx/vmx.c=0A+++ b/xen/arch/x86/hvm/vmx/vmx.c=0A@@ =
-149,7 +149,7 @@ static void vmx_vcpu_destroy(struct vcpu=0A =0A static =
DEFINE_PER_CPU(struct vmx_msr_state, host_msr_state);=0A =0A-static u32 =
msr_index[] =3D=0A+static const u32 msr_index[] =3D=0A {=0A     MSR_LSTAR, =
MSR_STAR, MSR_SYSCALL_MASK=0A };=0A--- a/xen/arch/x86/hvm/vmx/vpmu_core2.c=
=0A+++ b/xen/arch/x86/hvm/vmx/vpmu_core2.c=0A@@ -101,28 +101,30 @@ static =
void handle_pmc_quirk(u64 msr_con=0A     }=0A }=0A =0A-u32 core2_counters_m=
sr[] =3D   {=0A+static const u32 core2_counters_msr[] =3D {=0A     =
MSR_CORE_PERF_FIXED_CTR0,=0A     MSR_CORE_PERF_FIXED_CTR1,=0A-    =
MSR_CORE_PERF_FIXED_CTR2};=0A+    MSR_CORE_PERF_FIXED_CTR2=0A+};=0A =0A /* =
Core 2 Non-architectual Performance Control MSRs. */=0A-u32 core2_ctrls_msr=
[] =3D {=0A+static const u32 core2_ctrls_msr[] =3D {=0A     MSR_CORE_PERF_F=
IXED_CTR_CTRL,=0A     MSR_IA32_PEBS_ENABLE,=0A-    MSR_IA32_DS_AREA};=0A+  =
  MSR_IA32_DS_AREA=0A+};=0A =0A struct pmumsr {=0A     unsigned int =
num;=0A-    u32 *msr;=0A+    const u32 *msr;=0A };=0A =0A-struct pmumsr =
core2_counters =3D {=0A+static const struct pmumsr core2_counters =3D {=0A =
    3,=0A     core2_counters_msr=0A };=0A =0A-struct pmumsr core2_ctrls =
=3D {=0A+static const struct pmumsr core2_ctrls =3D {=0A     3,=0A     =
core2_ctrls_msr=0A };=0A--- a/xen/arch/x86/hvm/vmx/vvmx.c=0A+++ b/xen/arch/=
x86/hvm/vmx/vvmx.c=0A@@ -107,7 +107,7 @@ uint32_t nvmx_vcpu_asid(struct =
vcpu *v)=0A     return 0;=0A }=0A =0A-enum x86_segment sreg_to_index[] =3D =
{=0A+static const enum x86_segment sreg_to_index[] =3D {=0A     [VMX_SREG_E=
S] =3D x86_seg_es,=0A     [VMX_SREG_CS] =3D x86_seg_cs,=0A     [VMX_SREG_SS=
] =3D x86_seg_ss,=0A@@ -633,7 +633,7 @@ u64 nvmx_get_tsc_offset(struct =
vcpu *v)=0A /*=0A  * Context synchronized between shadow and virtual =
VMCS.=0A  */=0A-static unsigned long vmcs_gstate_field[] =3D {=0A+static =
const u16 vmcs_gstate_field[] =3D {=0A     /* 16 BITS */=0A     GUEST_ES_SE=
LECTOR,=0A     GUEST_CS_SELECTOR,=0A@@ -698,7 +698,7 @@ static unsigned =
long vmcs_gstate_field[]=0A /*=0A  * Context: shadow -> virtual VMCS=0A  =
*/=0A-static unsigned long vmcs_ro_field[] =3D {=0A+static const u16 =
vmcs_ro_field[] =3D {=0A     GUEST_PHYSICAL_ADDRESS,=0A     VM_INSTRUCTION_=
ERROR,=0A     VM_EXIT_REASON,=0A@@ -713,9 +713,9 @@ static unsigned long =
vmcs_ro_field[] =3D {=0A };=0A =0A static struct vmcs_host_to_guest {=0A-  =
  unsigned long host_field;=0A-    unsigned long guest_field;=0A-} =
vmcs_h2g_field[] =3D {=0A+    u16 host_field;=0A+    u16 guest_field;=0A+} =
const vmcs_h2g_field[] =3D {=0A     {HOST_ES_SELECTOR, GUEST_ES_SELECTOR},=
=0A     {HOST_CS_SELECTOR, GUEST_CS_SELECTOR},=0A     {HOST_SS_SELECTOR, =
GUEST_SS_SELECTOR},=0A
--=__PartA091B2E5.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

--=__PartA091B2E5.0__=--


From xen-devel-bounces@lists.xen.org Tue Sep 11 12:48:54 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 2012 12: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 1TBPtT-0000qp-IM; Tue, 11 Sep 2012 12:48: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 1TBPtR-0000qS-T4
	for xen-devel@lists.xen.org; Tue, 11 Sep 2012 12:48:42 +0000
Received: from [85.158.143.35:38105] by server-1.bemta-4.messagelabs.com id
	04/F2-12504-9233F405; Tue, 11 Sep 2012 12:48:41 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1347367700!11909829!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQwNzc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7756 invoked from network); 11 Sep 2012 12:48:20 -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;
	11 Sep 2012 12:48:20 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 11 Sep 2012 13:48:20 +0100
Message-Id: <504F4F30020000780009A99F@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 11 Sep 2012 13:48:16 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part44755600.0__="
Subject: [Xen-devel] [PATCH 3/3] x86/hvm: mark save/restore registration
 code __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>
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.

--=__Part44755600.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -995,7 +995,7 @@ static int hvm_load_cpu_xsave_states(str
 /* We need variable length data chunk for xsave area, hence customized
  * declaration other than HVM_REGISTER_SAVE_RESTORE.
  */
-static int __hvm_register_CPU_XSAVE_save_and_restore(void)
+static int __init __hvm_register_CPU_XSAVE_save_and_restore(void)
 {
     hvm_register_savevm(CPU_XSAVE_CODE,
                         "CPU_XSAVE",
--- a/xen/common/hvm/save.c
+++ b/xen/common/hvm/save.c
@@ -40,11 +40,11 @@ static struct {=20
 } hvm_sr_handlers [HVM_SAVE_CODE_MAX + 1] =3D {{NULL, NULL, "<?>"},};
=20
 /* Init-time function to add entries to that list */
-void hvm_register_savevm(uint16_t typecode,=20
-                         const char *name,
-                         hvm_save_handler save_state,
-                         hvm_load_handler load_state,
-                         size_t size, int kind)
+void __init hvm_register_savevm(uint16_t typecode,
+                                const char *name,
+                                hvm_save_handler save_state,
+                                hvm_load_handler load_state,
+                                size_t size, int kind)
 {
     ASSERT(typecode <=3D HVM_SAVE_CODE_MAX);
     ASSERT(hvm_sr_handlers[typecode].save =3D=3D NULL);
--- a/xen/include/xen/hvm/save.h
+++ b/xen/include/xen/hvm/save.h
@@ -19,6 +19,7 @@
 #define __XEN_HVM_SAVE_H__
=20
 #include <xen/types.h>
+#include <xen/init.h>
 #include <public/xen.h>
 #include <public/hvm/save.h>
=20
@@ -108,7 +109,7 @@ void hvm_register_savevm(uint16_t typeco
 /* Syntactic sugar around that function: specify the max number of
  * saves, and this calculates the size of buffer needed */
 #define HVM_REGISTER_SAVE_RESTORE(_x, _save, _load, _num, _k)             =
\
-static int __hvm_register_##_x##_save_and_restore(void)                   =
\
+static int __init __hvm_register_##_x##_save_and_restore(void)            =
\
 {                                                                         =
\
     hvm_register_savevm(HVM_SAVE_CODE(_x),                                =
\
                         #_x,                                              =
\




--=__Part44755600.0__=
Content-Type: text/plain; name="hvm-sr-init.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="hvm-sr-init.patch"

x86/hvm: mark save/restore registration code __init=0A=0ASigned-off-by: =
Jan Beulich <jbeulich@suse.com>=0A=0A--- a/xen/arch/x86/hvm/hvm.c=0A+++ =
b/xen/arch/x86/hvm/hvm.c=0A@@ -995,7 +995,7 @@ static int hvm_load_cpu_xsav=
e_states(str=0A /* We need variable length data chunk for xsave area, =
hence customized=0A  * declaration other than HVM_REGISTER_SAVE_RESTORE.=0A=
  */=0A-static int __hvm_register_CPU_XSAVE_save_and_restore(void)=0A+stati=
c int __init __hvm_register_CPU_XSAVE_save_and_restore(void)=0A {=0A     =
hvm_register_savevm(CPU_XSAVE_CODE,=0A                         "CPU_XSAVE",=
=0A--- a/xen/common/hvm/save.c=0A+++ b/xen/common/hvm/save.c=0A@@ -40,11 =
+40,11 @@ static struct { =0A } hvm_sr_handlers [HVM_SAVE_CODE_MAX + 1] =
=3D {{NULL, NULL, "<?>"},};=0A =0A /* Init-time function to add entries to =
that list */=0A-void hvm_register_savevm(uint16_t typecode, =0A-           =
              const char *name,=0A-                         hvm_save_handle=
r save_state,=0A-                         hvm_load_handler load_state,=0A- =
                        size_t size, int kind)=0A+void __init hvm_register_=
savevm(uint16_t typecode,=0A+                                const char =
*name,=0A+                                hvm_save_handler save_state,=0A+ =
                               hvm_load_handler load_state,=0A+            =
                    size_t size, int kind)=0A {=0A     ASSERT(typecode =
<=3D HVM_SAVE_CODE_MAX);=0A     ASSERT(hvm_sr_handlers[typecode].save =
=3D=3D NULL);=0A--- a/xen/include/xen/hvm/save.h=0A+++ b/xen/include/xen/hv=
m/save.h=0A@@ -19,6 +19,7 @@=0A #define __XEN_HVM_SAVE_H__=0A =0A #include =
<xen/types.h>=0A+#include <xen/init.h>=0A #include <public/xen.h>=0A =
#include <public/hvm/save.h>=0A =0A@@ -108,7 +109,7 @@ void hvm_register_sa=
vevm(uint16_t typeco=0A /* Syntactic sugar around that function: specify =
the max number of=0A  * saves, and this calculates the size of buffer =
needed */=0A #define HVM_REGISTER_SAVE_RESTORE(_x, _save, _load, _num, _k) =
            \=0A-static int __hvm_register_##_x##_save_and_restore(void)   =
                \=0A+static int __init __hvm_register_##_x##_save_and_resto=
re(void)            \=0A {                                                 =
                        \=0A     hvm_register_savevm(HVM_SAVE_CODE(_x),    =
                            \=0A                         #_x,              =
                                \=0A
--=__Part44755600.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

--=__Part44755600.0__=--


From xen-devel-bounces@lists.xen.org Tue Sep 11 12:48:54 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 2012 12: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 1TBPtT-0000qp-IM; Tue, 11 Sep 2012 12:48: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 1TBPtR-0000qS-T4
	for xen-devel@lists.xen.org; Tue, 11 Sep 2012 12:48:42 +0000
Received: from [85.158.143.35:38105] by server-1.bemta-4.messagelabs.com id
	04/F2-12504-9233F405; Tue, 11 Sep 2012 12:48:41 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1347367700!11909829!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQwNzc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7756 invoked from network); 11 Sep 2012 12:48:20 -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;
	11 Sep 2012 12:48:20 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 11 Sep 2012 13:48:20 +0100
Message-Id: <504F4F30020000780009A99F@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 11 Sep 2012 13:48:16 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part44755600.0__="
Subject: [Xen-devel] [PATCH 3/3] x86/hvm: mark save/restore registration
 code __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>
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.

--=__Part44755600.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -995,7 +995,7 @@ static int hvm_load_cpu_xsave_states(str
 /* We need variable length data chunk for xsave area, hence customized
  * declaration other than HVM_REGISTER_SAVE_RESTORE.
  */
-static int __hvm_register_CPU_XSAVE_save_and_restore(void)
+static int __init __hvm_register_CPU_XSAVE_save_and_restore(void)
 {
     hvm_register_savevm(CPU_XSAVE_CODE,
                         "CPU_XSAVE",
--- a/xen/common/hvm/save.c
+++ b/xen/common/hvm/save.c
@@ -40,11 +40,11 @@ static struct {=20
 } hvm_sr_handlers [HVM_SAVE_CODE_MAX + 1] =3D {{NULL, NULL, "<?>"},};
=20
 /* Init-time function to add entries to that list */
-void hvm_register_savevm(uint16_t typecode,=20
-                         const char *name,
-                         hvm_save_handler save_state,
-                         hvm_load_handler load_state,
-                         size_t size, int kind)
+void __init hvm_register_savevm(uint16_t typecode,
+                                const char *name,
+                                hvm_save_handler save_state,
+                                hvm_load_handler load_state,
+                                size_t size, int kind)
 {
     ASSERT(typecode <=3D HVM_SAVE_CODE_MAX);
     ASSERT(hvm_sr_handlers[typecode].save =3D=3D NULL);
--- a/xen/include/xen/hvm/save.h
+++ b/xen/include/xen/hvm/save.h
@@ -19,6 +19,7 @@
 #define __XEN_HVM_SAVE_H__
=20
 #include <xen/types.h>
+#include <xen/init.h>
 #include <public/xen.h>
 #include <public/hvm/save.h>
=20
@@ -108,7 +109,7 @@ void hvm_register_savevm(uint16_t typeco
 /* Syntactic sugar around that function: specify the max number of
  * saves, and this calculates the size of buffer needed */
 #define HVM_REGISTER_SAVE_RESTORE(_x, _save, _load, _num, _k)             =
\
-static int __hvm_register_##_x##_save_and_restore(void)                   =
\
+static int __init __hvm_register_##_x##_save_and_restore(void)            =
\
 {                                                                         =
\
     hvm_register_savevm(HVM_SAVE_CODE(_x),                                =
\
                         #_x,                                              =
\




--=__Part44755600.0__=
Content-Type: text/plain; name="hvm-sr-init.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="hvm-sr-init.patch"

x86/hvm: mark save/restore registration code __init=0A=0ASigned-off-by: =
Jan Beulich <jbeulich@suse.com>=0A=0A--- a/xen/arch/x86/hvm/hvm.c=0A+++ =
b/xen/arch/x86/hvm/hvm.c=0A@@ -995,7 +995,7 @@ static int hvm_load_cpu_xsav=
e_states(str=0A /* We need variable length data chunk for xsave area, =
hence customized=0A  * declaration other than HVM_REGISTER_SAVE_RESTORE.=0A=
  */=0A-static int __hvm_register_CPU_XSAVE_save_and_restore(void)=0A+stati=
c int __init __hvm_register_CPU_XSAVE_save_and_restore(void)=0A {=0A     =
hvm_register_savevm(CPU_XSAVE_CODE,=0A                         "CPU_XSAVE",=
=0A--- a/xen/common/hvm/save.c=0A+++ b/xen/common/hvm/save.c=0A@@ -40,11 =
+40,11 @@ static struct { =0A } hvm_sr_handlers [HVM_SAVE_CODE_MAX + 1] =
=3D {{NULL, NULL, "<?>"},};=0A =0A /* Init-time function to add entries to =
that list */=0A-void hvm_register_savevm(uint16_t typecode, =0A-           =
              const char *name,=0A-                         hvm_save_handle=
r save_state,=0A-                         hvm_load_handler load_state,=0A- =
                        size_t size, int kind)=0A+void __init hvm_register_=
savevm(uint16_t typecode,=0A+                                const char =
*name,=0A+                                hvm_save_handler save_state,=0A+ =
                               hvm_load_handler load_state,=0A+            =
                    size_t size, int kind)=0A {=0A     ASSERT(typecode =
<=3D HVM_SAVE_CODE_MAX);=0A     ASSERT(hvm_sr_handlers[typecode].save =
=3D=3D NULL);=0A--- a/xen/include/xen/hvm/save.h=0A+++ b/xen/include/xen/hv=
m/save.h=0A@@ -19,6 +19,7 @@=0A #define __XEN_HVM_SAVE_H__=0A =0A #include =
<xen/types.h>=0A+#include <xen/init.h>=0A #include <public/xen.h>=0A =
#include <public/hvm/save.h>=0A =0A@@ -108,7 +109,7 @@ void hvm_register_sa=
vevm(uint16_t typeco=0A /* Syntactic sugar around that function: specify =
the max number of=0A  * saves, and this calculates the size of buffer =
needed */=0A #define HVM_REGISTER_SAVE_RESTORE(_x, _save, _load, _num, _k) =
            \=0A-static int __hvm_register_##_x##_save_and_restore(void)   =
                \=0A+static int __init __hvm_register_##_x##_save_and_resto=
re(void)            \=0A {                                                 =
                        \=0A     hvm_register_savevm(HVM_SAVE_CODE(_x),    =
                            \=0A                         #_x,              =
                                \=0A
--=__Part44755600.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

--=__Part44755600.0__=--


From xen-devel-bounces@lists.xen.org Tue Sep 11 12:49:41 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 2012 12:49: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 1TBPuI-0000zG-0k; Tue, 11 Sep 2012 12:49: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 1TBPuG-0000yw-DH
	for xen-devel@lists.xensource.com; Tue, 11 Sep 2012 12:49:32 +0000
Received: from [85.158.143.35:48777] by server-1.bemta-4.messagelabs.com id
	4F/94-12504-B533F405; Tue, 11 Sep 2012 12:49:31 +0000
X-Env-Sender: fantonifabio@tiscali.it
X-Msg-Ref: server-11.tower-21.messagelabs.com!1347367771!12571249!1
X-Originating-IP: [94.23.245.208]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6228 invoked from network); 11 Sep 2012 12:49:31 -0000
Received: from lnx3.fantu.it (HELO lnx3.fantu.it) (94.23.245.208)
	by server-11.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 11 Sep 2012 12:49:31 -0000
Received: from localhost (localhost.localdomain [127.0.0.1])
	by lnx3.fantu.it (Postfix) with ESMTP id E6BED401987
	for <xen-devel@lists.xensource.com>;
	Tue, 11 Sep 2012 14:49:30 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at lnx3.fantu.it
Received: from lnx3.fantu.it ([127.0.0.1])
	by localhost (lnx3.fantu.it [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id o-xE3whVrzX0 for <xen-devel@lists.xensource.com>;
	Tue, 11 Sep 2012 14:49:30 +0200 (CEST)
Received: from [192.168.178.50]
	(host159-164-dynamic.56-82-r.retail.telecomitalia.it [82.56.164.159])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: prova@fantu.it)
	by lnx3.fantu.it (Postfix) with ESMTPSA id 4B473401471
	for <xen-devel@lists.xensource.com>;
	Tue, 11 Sep 2012 14:49:30 +0200 (CEST)
Message-ID: <504F3355.2070201@tiscali.it>
Date: Tue, 11 Sep 2012 14:49:25 +0200
From: Fabio Fantoni <fantonifabio@tiscali.it>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:14.0) Gecko/20120713 Thunderbird/14.0
MIME-Version: 1.0
To: xen-devel <xen-devel@lists.xensource.com>
Subject: [Xen-devel] Start xen on UEFI system with grub
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="===============2514569458688343562=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Questo è un messaggio firmato digitalmente in formato MIME.

--===============2514569458688343562==
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms070409060305090101070108"

Questo è un messaggio firmato digitalmente in formato MIME.

--------------ms070409060305090101070108
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: quoted-printable

I have Wheezy 64 bit dom0 with kernel 3.2 from repository and xen 4.2=20
from source.
I want use UEFI without xen.efi which fails on compiling xen.
Should I use "ucode" or something similar?
Is possible? If is possible what I must do?
Thanks for any reply.


--------------ms070409060305090101070108
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: Firma crittografica S/MIME

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINhjCC
BjQwggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT
DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp
Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3
MTAyNDIxMDI1NVoXDTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T
dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu
aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs
aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOM
KqANy9BV7V0igWdGxA8IU77L3aTxErQ+fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi
8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke/s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8M
DP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHksw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y
2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHHtOkzUreG//CsFnB9+uaYSlR65cdG
zTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB
Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd+q9rMfPIHeOsuzAfBgNV
HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH
MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3
dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu
c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v
c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0
dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93
d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqp
Jw3I07QWke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Mic
c/NXcs7kPBRdn6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9Jphw
UPTXwHovjavRnhUQHLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMc
p+reg9901zkyT3fDW/ivJVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT
+HBDYtbuvexNftwNQKD5193A7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1X
hwby6mLhkbaXslkVtwEWT3Van49rKjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvO
hNz/QplNa+VkIsrcp7+8ZhP1l1b2U6MaxIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC
0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqh
AChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H75dVCV33K6FuxZrf09yTz+Vx/PkdRUYk
XmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHSjCCBjKgAwIBAgICHmMwDQYJKoZIhvcNAQEF
BQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJT
ZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD
bGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0xMjAzMTgyMjE0MzBa
Fw0xNDAzMjAwODU3MDlaMIGMMRkwFwYDVQQNExBlQjZPRTM3UlJOUHlsNW0yMQswCQYDVQQG
EwJJVDEQMA4GA1UECBMHQmVyZ2FtbzEQMA4GA1UEBxMHUm92ZXR0YTEWMBQGA1UEAxMNRmFi
aW8gRmFudG9uaTEmMCQGCSqGSIb3DQEJARYXZmFudG9uaWZhYmlvQHRpc2NhbGkuaXQwggEi
MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC1XhckXsX23vgJq76s2f0KT8U8Msov5QgV
10eQBb2wL/TzcmqtZotI7ztKVhio3ehHg+mfu+3EqOkX9Umgut8rP0bPi7AGjkPXbOTT/cSU
Xz2Kw31VGOmiOVoUFGvpQitp3weCkhUJLBipI8EpNyBXpjtQ9yCpnIAqfuc77ybfSnCy7tTR
MBq1BUkfjH1+GL45riosuS4+F+MSUvlYzLiT4rAduAX1Y2IuORDsf9Bce8GBxa6syP9rCyzl
Vk7DIX5k8j2vlnyRATIypn5CQLQxGT6e0f6ac4gvWOHwO2QEBsmZKKs1ZidE4q/9OoNXYX6A
jnHtp1H1vcrek/vVcs19AgMBAAGjggOyMIIDrjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAd
BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFFan8cbEWWBmSTWFtLk2
YNdAcGUbMB8GA1UdIwQYMBaAFK5Vg2/sMcq59x36r2sx88gd46y7MCIGA1UdEQQbMBmBF2Zh
bnRvbmlmYWJpb0B0aXNjYWxpLml0MIICIQYDVR0gBIICGDCCAhQwggIQBgsrBgEEAYG1NwEC
AjCCAf8wLgYIKwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYw
NAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYw
gfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMC
AQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNjb3JkaW5nIHRvIHRoZSBDbGFz
cyAyIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3ks
IHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGluIGNvbXBsaWFuY2Ug
b2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMIGcBggrBgEFBQcCAjCBjzAnFiBT
dGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgECGmRMaWFiaWxpdHkgYW5kIHdh
cnJhbnRpZXMgYXJlIGxpbWl0ZWQhIFNlZSBzZWN0aW9uICJMZWdhbCBhbmQgTGltaXRhdGlv
bnMiIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3kuMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6
Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUyLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYI
KwYBBQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MyL2NsaWVudC9j
YTBCBggrBgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNz
Mi5jbGllbnQuY2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzAN
BgkqhkiG9w0BAQUFAAOCAQEAjzHNqifpDVMkH1TSPFZVIiQ4fh49/V5JMpstgqEZPDaDe5r8
h+fMBZtUa6LLMco03Z9BNEXlqlXKiFk8feVYB8obEjz7YYq1XhO9q7JUmkSs0WGIH4xU0XB1
kPC8T8H+5E//84poYSFHE4pA+Ff68UANP2/EuFJWMjegiefnOr8aM42OAcUkjEWSlautIIX8
oD2GizwQYjWdDDjEonbuMKFP6rY2xGI3PSLI3IVU2opb0/itNhQui3WRxafloJqTlriY8m8+
qSLr2HGftbBlbyzVWB8o//aW0H0LMabjkIvrm7Zmh2vcCxiSxGBwYASuSYXGuQiKAgGptUs1
XJLZuzGCA9owggPWAgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20g
THRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG
A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EC
Ah5jMAkGBSsOAwIaBQCgggIbMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcN
AQkFMQ8XDTEyMDkxMTEyNDkyNVowIwYJKoZIhvcNAQkEMRYEFIj9WSY9ibrABXdftEieeDJJ
mMTqMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggqhkiG
9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcN
AwICASgwgaQGCSsGAQQBgjcQBDGBljCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0
YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25p
bmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp
ZW50IENBAgIeYzCBpgYLKoZIhvcNAQkQAgsxgZaggZMwgYwxCzAJBgNVBAYTAklMMRYwFAYD
VQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0
ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRp
YXRlIENsaWVudCBDQQICHmMwDQYJKoZIhvcNAQEBBQAEggEApKvazzLuSUklTRqbM0iZyO07
vjlkLTl19eg7s7LIKGHceri+zAkWAG9M0AKBkBooyhktW8EzzdFDTM4GhZ1DykPu4M54ryFn
D//idW9JnQYjiPxc/DJCGC/qMpTxgjwTNwrIBCO4nz3Ny9QPrkUZ47SONZxyvyy5H3mktOvw
ulEkiBkUe1dAHeuQCK1UZ8DwLztSoJM56f7rPhLjFdZNwBHW9phnh7n5nyNtHoI/k5MaILZB
M1cbvYDjJUitxx6QkD54BR2sdTxFHJDZ7oiMfSwCN8WiKVKMjy2znVdAn8h1UlsIt12ZmN5l
ZD6oVlOPyup+0n+jBoPil3q7jKGrtwAAAAAAAA==
--------------ms070409060305090101070108--


--===============2514569458688343562==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============2514569458688343562==--


From xen-devel-bounces@lists.xen.org Tue Sep 11 12:49:41 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 2012 12:49: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 1TBPuI-0000zG-0k; Tue, 11 Sep 2012 12:49: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 1TBPuG-0000yw-DH
	for xen-devel@lists.xensource.com; Tue, 11 Sep 2012 12:49:32 +0000
Received: from [85.158.143.35:48777] by server-1.bemta-4.messagelabs.com id
	4F/94-12504-B533F405; Tue, 11 Sep 2012 12:49:31 +0000
X-Env-Sender: fantonifabio@tiscali.it
X-Msg-Ref: server-11.tower-21.messagelabs.com!1347367771!12571249!1
X-Originating-IP: [94.23.245.208]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6228 invoked from network); 11 Sep 2012 12:49:31 -0000
Received: from lnx3.fantu.it (HELO lnx3.fantu.it) (94.23.245.208)
	by server-11.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 11 Sep 2012 12:49:31 -0000
Received: from localhost (localhost.localdomain [127.0.0.1])
	by lnx3.fantu.it (Postfix) with ESMTP id E6BED401987
	for <xen-devel@lists.xensource.com>;
	Tue, 11 Sep 2012 14:49:30 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at lnx3.fantu.it
Received: from lnx3.fantu.it ([127.0.0.1])
	by localhost (lnx3.fantu.it [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id o-xE3whVrzX0 for <xen-devel@lists.xensource.com>;
	Tue, 11 Sep 2012 14:49:30 +0200 (CEST)
Received: from [192.168.178.50]
	(host159-164-dynamic.56-82-r.retail.telecomitalia.it [82.56.164.159])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: prova@fantu.it)
	by lnx3.fantu.it (Postfix) with ESMTPSA id 4B473401471
	for <xen-devel@lists.xensource.com>;
	Tue, 11 Sep 2012 14:49:30 +0200 (CEST)
Message-ID: <504F3355.2070201@tiscali.it>
Date: Tue, 11 Sep 2012 14:49:25 +0200
From: Fabio Fantoni <fantonifabio@tiscali.it>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:14.0) Gecko/20120713 Thunderbird/14.0
MIME-Version: 1.0
To: xen-devel <xen-devel@lists.xensource.com>
Subject: [Xen-devel] Start xen on UEFI system with grub
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="===============2514569458688343562=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Questo è un messaggio firmato digitalmente in formato MIME.

--===============2514569458688343562==
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms070409060305090101070108"

Questo è un messaggio firmato digitalmente in formato MIME.

--------------ms070409060305090101070108
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: quoted-printable

I have Wheezy 64 bit dom0 with kernel 3.2 from repository and xen 4.2=20
from source.
I want use UEFI without xen.efi which fails on compiling xen.
Should I use "ucode" or something similar?
Is possible? If is possible what I must do?
Thanks for any reply.


--------------ms070409060305090101070108
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: Firma crittografica S/MIME

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINhjCC
BjQwggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT
DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp
Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3
MTAyNDIxMDI1NVoXDTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T
dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu
aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs
aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOM
KqANy9BV7V0igWdGxA8IU77L3aTxErQ+fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi
8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke/s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8M
DP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHksw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y
2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHHtOkzUreG//CsFnB9+uaYSlR65cdG
zTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB
Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd+q9rMfPIHeOsuzAfBgNV
HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH
MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3
dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu
c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v
c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0
dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93
d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqp
Jw3I07QWke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Mic
c/NXcs7kPBRdn6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9Jphw
UPTXwHovjavRnhUQHLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMc
p+reg9901zkyT3fDW/ivJVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT
+HBDYtbuvexNftwNQKD5193A7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1X
hwby6mLhkbaXslkVtwEWT3Van49rKjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvO
hNz/QplNa+VkIsrcp7+8ZhP1l1b2U6MaxIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC
0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqh
AChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H75dVCV33K6FuxZrf09yTz+Vx/PkdRUYk
XmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHSjCCBjKgAwIBAgICHmMwDQYJKoZIhvcNAQEF
BQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJT
ZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD
bGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0xMjAzMTgyMjE0MzBa
Fw0xNDAzMjAwODU3MDlaMIGMMRkwFwYDVQQNExBlQjZPRTM3UlJOUHlsNW0yMQswCQYDVQQG
EwJJVDEQMA4GA1UECBMHQmVyZ2FtbzEQMA4GA1UEBxMHUm92ZXR0YTEWMBQGA1UEAxMNRmFi
aW8gRmFudG9uaTEmMCQGCSqGSIb3DQEJARYXZmFudG9uaWZhYmlvQHRpc2NhbGkuaXQwggEi
MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC1XhckXsX23vgJq76s2f0KT8U8Msov5QgV
10eQBb2wL/TzcmqtZotI7ztKVhio3ehHg+mfu+3EqOkX9Umgut8rP0bPi7AGjkPXbOTT/cSU
Xz2Kw31VGOmiOVoUFGvpQitp3weCkhUJLBipI8EpNyBXpjtQ9yCpnIAqfuc77ybfSnCy7tTR
MBq1BUkfjH1+GL45riosuS4+F+MSUvlYzLiT4rAduAX1Y2IuORDsf9Bce8GBxa6syP9rCyzl
Vk7DIX5k8j2vlnyRATIypn5CQLQxGT6e0f6ac4gvWOHwO2QEBsmZKKs1ZidE4q/9OoNXYX6A
jnHtp1H1vcrek/vVcs19AgMBAAGjggOyMIIDrjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAd
BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFFan8cbEWWBmSTWFtLk2
YNdAcGUbMB8GA1UdIwQYMBaAFK5Vg2/sMcq59x36r2sx88gd46y7MCIGA1UdEQQbMBmBF2Zh
bnRvbmlmYWJpb0B0aXNjYWxpLml0MIICIQYDVR0gBIICGDCCAhQwggIQBgsrBgEEAYG1NwEC
AjCCAf8wLgYIKwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYw
NAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYw
gfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMC
AQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNjb3JkaW5nIHRvIHRoZSBDbGFz
cyAyIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3ks
IHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGluIGNvbXBsaWFuY2Ug
b2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMIGcBggrBgEFBQcCAjCBjzAnFiBT
dGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgECGmRMaWFiaWxpdHkgYW5kIHdh
cnJhbnRpZXMgYXJlIGxpbWl0ZWQhIFNlZSBzZWN0aW9uICJMZWdhbCBhbmQgTGltaXRhdGlv
bnMiIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3kuMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6
Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUyLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYI
KwYBBQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MyL2NsaWVudC9j
YTBCBggrBgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNz
Mi5jbGllbnQuY2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzAN
BgkqhkiG9w0BAQUFAAOCAQEAjzHNqifpDVMkH1TSPFZVIiQ4fh49/V5JMpstgqEZPDaDe5r8
h+fMBZtUa6LLMco03Z9BNEXlqlXKiFk8feVYB8obEjz7YYq1XhO9q7JUmkSs0WGIH4xU0XB1
kPC8T8H+5E//84poYSFHE4pA+Ff68UANP2/EuFJWMjegiefnOr8aM42OAcUkjEWSlautIIX8
oD2GizwQYjWdDDjEonbuMKFP6rY2xGI3PSLI3IVU2opb0/itNhQui3WRxafloJqTlriY8m8+
qSLr2HGftbBlbyzVWB8o//aW0H0LMabjkIvrm7Zmh2vcCxiSxGBwYASuSYXGuQiKAgGptUs1
XJLZuzGCA9owggPWAgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20g
THRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG
A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EC
Ah5jMAkGBSsOAwIaBQCgggIbMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcN
AQkFMQ8XDTEyMDkxMTEyNDkyNVowIwYJKoZIhvcNAQkEMRYEFIj9WSY9ibrABXdftEieeDJJ
mMTqMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggqhkiG
9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcN
AwICASgwgaQGCSsGAQQBgjcQBDGBljCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0
YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25p
bmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp
ZW50IENBAgIeYzCBpgYLKoZIhvcNAQkQAgsxgZaggZMwgYwxCzAJBgNVBAYTAklMMRYwFAYD
VQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0
ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRp
YXRlIENsaWVudCBDQQICHmMwDQYJKoZIhvcNAQEBBQAEggEApKvazzLuSUklTRqbM0iZyO07
vjlkLTl19eg7s7LIKGHceri+zAkWAG9M0AKBkBooyhktW8EzzdFDTM4GhZ1DykPu4M54ryFn
D//idW9JnQYjiPxc/DJCGC/qMpTxgjwTNwrIBCO4nz3Ny9QPrkUZ47SONZxyvyy5H3mktOvw
ulEkiBkUe1dAHeuQCK1UZ8DwLztSoJM56f7rPhLjFdZNwBHW9phnh7n5nyNtHoI/k5MaILZB
M1cbvYDjJUitxx6QkD54BR2sdTxFHJDZ7oiMfSwCN8WiKVKMjy2znVdAn8h1UlsIt12ZmN5l
ZD6oVlOPyup+0n+jBoPil3q7jKGrtwAAAAAAAA==
--------------ms070409060305090101070108--


--===============2514569458688343562==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============2514569458688343562==--


From xen-devel-bounces@lists.xen.org Tue Sep 11 12:55:16 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 2012 12: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 1TBPzc-0001Pu-0V; Tue, 11 Sep 2012 12:55:04 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1TBPza-0001Pp-G7
	for xen-devel@lists.xensource.com; Tue, 11 Sep 2012 12:55:02 +0000
Received: from [85.158.139.83:17182] by server-9.bemta-5.messagelabs.com id
	06/29-20529-5A43F405; Tue, 11 Sep 2012 12:55:01 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1347368099!22498259!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDc0Mjk0Nw==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32081 invoked from network); 11 Sep 2012 12:55:01 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-16.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 11 Sep 2012 12:55:01 -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 q8BCsdW6001204
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 11 Sep 2012 12:54:40 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
	q8BCsc1i010379
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 11 Sep 2012 12:54:39 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
	q8BCscvw008975; Tue, 11 Sep 2012 07:54:38 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 11 Sep 2012 05:54:37 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 8544E402E4; Tue, 11 Sep 2012 08:43:59 -0400 (EDT)
Date: Tue, 11 Sep 2012 08:43:59 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Thomas Gleixner <tglx@linutronix.de>
Message-ID: <20120911124359.GA5459@phenom.dumpdata.com>
References: <1345580561-8506-1-git-send-email-attilio.rao@citrix.com>
	<alpine.LFD.2.02.1208212315330.2856@ionos>
	<20120822135753.GA30964@phenom.dumpdata.com>
	<alpine.LFD.2.02.1208221618380.2856@ionos>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <alpine.LFD.2.02.1208221618380.2856@ionos>
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, Ian.Campbell@citrix.com,
	Stefano.Stabellini@eu.citrix.com, x86@kernel.org,
	linux-kernel@vger.kernel.org, mingo@redhat.com, hpa@zytor.com,
	Attilio Rao <attilio.rao@citrix.com>
Subject: Re: [Xen-devel] [PATCH v2 0/5] X86/XEN: Merge
 x86_init.paging.pagetable_setup_start and
 x86_init.paging.pagetable_setup_done setup functions and document its
 semantic
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 overall result is basically the same, but it's way simpler to look
> > > at obvious and well done patches than checking whether a subtle copy
> > > and paste bug happened in 3/5 of the first version. Copy and paste is
> > > the #1 cause for subtle bugs. :)
> > > 
> > > I'm waiting for the ack of Xen folks before taking it into tip.

In case you are waiting for that - Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> > 
> > I've some extra patches that modify the new "paginig_init" in the Xen
> > code that I am going to propose for v3.7 - so will have some merge
> > conflicts. Let me figure that out and also run this set of patches
> > (and also the previous one .. which I think you didn't have a
> > chance to look since you were on vacation?) on an overnight
> 
> Which previous one ?
> 
> > test to make sure there are no fallout.
> > 
> > With the merge issues that are going to prop up (x86 tip tree
> > and my tree in linux-next) should I just take these patches
> > in my tree with your Ack? Or should I just ingest your tiptree
> > in my tree and that way solve the merge issue? What's your
> > preference!
> 
> Having it in tip in an extra branch which you pull into your
> tree. That's the easiest one.

ping? Which branch should I pull?
> 
> Thanks,
> 
> 	tglx

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 11 12:55:16 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 2012 12: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 1TBPzc-0001Pu-0V; Tue, 11 Sep 2012 12:55:04 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1TBPza-0001Pp-G7
	for xen-devel@lists.xensource.com; Tue, 11 Sep 2012 12:55:02 +0000
Received: from [85.158.139.83:17182] by server-9.bemta-5.messagelabs.com id
	06/29-20529-5A43F405; Tue, 11 Sep 2012 12:55:01 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1347368099!22498259!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDc0Mjk0Nw==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32081 invoked from network); 11 Sep 2012 12:55:01 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-16.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 11 Sep 2012 12:55:01 -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 q8BCsdW6001204
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 11 Sep 2012 12:54:40 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
	q8BCsc1i010379
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 11 Sep 2012 12:54:39 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
	q8BCscvw008975; Tue, 11 Sep 2012 07:54:38 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 11 Sep 2012 05:54:37 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 8544E402E4; Tue, 11 Sep 2012 08:43:59 -0400 (EDT)
Date: Tue, 11 Sep 2012 08:43:59 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Thomas Gleixner <tglx@linutronix.de>
Message-ID: <20120911124359.GA5459@phenom.dumpdata.com>
References: <1345580561-8506-1-git-send-email-attilio.rao@citrix.com>
	<alpine.LFD.2.02.1208212315330.2856@ionos>
	<20120822135753.GA30964@phenom.dumpdata.com>
	<alpine.LFD.2.02.1208221618380.2856@ionos>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <alpine.LFD.2.02.1208221618380.2856@ionos>
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, Ian.Campbell@citrix.com,
	Stefano.Stabellini@eu.citrix.com, x86@kernel.org,
	linux-kernel@vger.kernel.org, mingo@redhat.com, hpa@zytor.com,
	Attilio Rao <attilio.rao@citrix.com>
Subject: Re: [Xen-devel] [PATCH v2 0/5] X86/XEN: Merge
 x86_init.paging.pagetable_setup_start and
 x86_init.paging.pagetable_setup_done setup functions and document its
 semantic
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 overall result is basically the same, but it's way simpler to look
> > > at obvious and well done patches than checking whether a subtle copy
> > > and paste bug happened in 3/5 of the first version. Copy and paste is
> > > the #1 cause for subtle bugs. :)
> > > 
> > > I'm waiting for the ack of Xen folks before taking it into tip.

In case you are waiting for that - Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> > 
> > I've some extra patches that modify the new "paginig_init" in the Xen
> > code that I am going to propose for v3.7 - so will have some merge
> > conflicts. Let me figure that out and also run this set of patches
> > (and also the previous one .. which I think you didn't have a
> > chance to look since you were on vacation?) on an overnight
> 
> Which previous one ?
> 
> > test to make sure there are no fallout.
> > 
> > With the merge issues that are going to prop up (x86 tip tree
> > and my tree in linux-next) should I just take these patches
> > in my tree with your Ack? Or should I just ingest your tiptree
> > in my tree and that way solve the merge issue? What's your
> > preference!
> 
> Having it in tip in an extra branch which you pull into your
> tree. That's the easiest one.

ping? Which branch should I pull?
> 
> Thanks,
> 
> 	tglx

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 11 12:58:38 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 2012 12: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 1TBQ2p-0001X4-KU; Tue, 11 Sep 2012 12:58:23 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1TBQ2o-0001Wy-OF
	for xen-devel@lists.xen.org; Tue, 11 Sep 2012 12:58:22 +0000
Received: from [85.158.143.99:33560] by server-1.bemta-4.messagelabs.com id
	96/55-12504-D653F405; Tue, 11 Sep 2012 12:58:21 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1347368293!24410706!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQwNzc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8078 invoked from network); 11 Sep 2012 12:58:14 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-2.tower-216.messagelabs.com with SMTP;
	11 Sep 2012 12:58:14 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 11 Sep 2012 13:58:13 +0100
Message-Id: <504F5182020000780009A9CC@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 11 Sep 2012 13:58:10 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: <fantonifabio@tiscali.it>
References: <504F3355.2070201@tiscali.it>
In-Reply-To: <504F3355.2070201@tiscali.it>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Start xen on UEFI system with grub
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.09.12 at 14:49, Fabio Fantoni <fantonifabio@tiscali.it> wrote:
> I have Wheezy 64 bit dom0 with kernel 3.2 from repository and xen 4.2 
> from source.
> I want use UEFI without xen.efi

Why?

> which fails on compiling xen.

How? All you would need is xen.gz for that purpose (but of course
that won't have any EFI specific bits in it).

> Should I use "ucode" or something similar?

That's completely unrelated.

> Is possible? If is possible what I must do?

Without you telling us precisely what doesn't work, we can hardly
answer that.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 11 12:58:38 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 2012 12: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 1TBQ2p-0001X4-KU; Tue, 11 Sep 2012 12:58:23 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1TBQ2o-0001Wy-OF
	for xen-devel@lists.xen.org; Tue, 11 Sep 2012 12:58:22 +0000
Received: from [85.158.143.99:33560] by server-1.bemta-4.messagelabs.com id
	96/55-12504-D653F405; Tue, 11 Sep 2012 12:58:21 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1347368293!24410706!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQwNzc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8078 invoked from network); 11 Sep 2012 12:58:14 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-2.tower-216.messagelabs.com with SMTP;
	11 Sep 2012 12:58:14 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 11 Sep 2012 13:58:13 +0100
Message-Id: <504F5182020000780009A9CC@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 11 Sep 2012 13:58:10 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: <fantonifabio@tiscali.it>
References: <504F3355.2070201@tiscali.it>
In-Reply-To: <504F3355.2070201@tiscali.it>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Start xen on UEFI system with grub
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.09.12 at 14:49, Fabio Fantoni <fantonifabio@tiscali.it> wrote:
> I have Wheezy 64 bit dom0 with kernel 3.2 from repository and xen 4.2 
> from source.
> I want use UEFI without xen.efi

Why?

> which fails on compiling xen.

How? All you would need is xen.gz for that purpose (but of course
that won't have any EFI specific bits in it).

> Should I use "ucode" or something similar?

That's completely unrelated.

> Is possible? If is possible what I must do?

Without you telling us precisely what doesn't work, we can hardly
answer that.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 11 13:10:18 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 2012 13: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 1TBQE7-0001sB-Tx; Tue, 11 Sep 2012 13:10:03 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jwboyer@gmail.com>) id 1TBQB4-0001rV-Ls
	for xen-devel@lists.xen.org; Tue, 11 Sep 2012 13:06:54 +0000
Received: from [85.158.143.35:37642] by server-2.bemta-4.messagelabs.com id
	5D/97-21239-E673F405; Tue, 11 Sep 2012 13:06:54 +0000
X-Env-Sender: jwboyer@gmail.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1347368811!6016668!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-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31173 invoked from network); 11 Sep 2012 13:06:52 -0000
Received: from mail-vc0-f173.google.com (HELO mail-vc0-f173.google.com)
	(209.85.220.173)
	by server-4.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Sep 2012 13:06:52 -0000
Received: by vcbfl15 with SMTP id fl15so738634vcb.32
	for <xen-devel@lists.xen.org>; Tue, 11 Sep 2012 06:06:51 -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=+zTMJvb+gWvgtENwBTczEZ4Fyz8g3g86HRHa5mKY1as=;
	b=ZHYkYyiqZCUOY/ScOOa4zka6MK2lXIvj4fznrQgmCXdXoEOlR3JsX0PIDmp4ItBjDb
	Hajx9x/CbGGxICW0AnN+UbN3UtBPZxEkYKdc3J/VvdzUJy77w9GEs3kYLnl+656p3kbg
	b4/ZCD21SntDdp2WKvsXp+rfFLHNc7FbZ1ucG3ZCnCi1NFB9yWn3vuF7sECFpiWVS3FA
	pfSmziWmPYnhWof9tQe4euIXzvLcrt5lQN7nP1ncCXfUrJF3XRklJVmnXUuR1DRPpU4h
	DVltvH0Gp/Ktez3lOB35/Gx8fI1R74p0WG3n7E+Pp5+9BuNdDfYM/7hC94D1ntAFKVcp
	BC7g==
MIME-Version: 1.0
Received: by 10.52.31.3 with SMTP id w3mr13561350vdh.33.1347368811269; Tue, 11
	Sep 2012 06:06:51 -0700 (PDT)
Received: by 10.59.1.102 with HTTP; Tue, 11 Sep 2012 06:06:51 -0700 (PDT)
In-Reply-To: <20120911113715.GA28221@phenom.dumpdata.com>
References: <1347018043-21252-1-git-send-email-stefan.bader@canonical.com>
	<504A05B00200007800099C7B@nat28.tlf.novell.com>
	<5049F4E9.9050306@canonical.com>
	<504A1A950200007800099D4C@nat28.tlf.novell.com>
	<20120907142251.GA20096@linuxtx.org>
	<504A32800200007800099E40@nat28.tlf.novell.com>
	<1347033622.2980.12.camel@fedora64.linuxtx.org>
	<20120911024047.GA7620@u002268147cd4502c336d.ant.amazon.com>
	<20120911113715.GA28221@phenom.dumpdata.com>
Date: Tue, 11 Sep 2012 09:06:51 -0400
Message-ID: <CA+5PVA48UY6ckcKF3fMVvGk4rDtaZucff82gshyLkVgZEpppcw@mail.gmail.com>
From: Josh Boyer <jwboyer@gmail.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
X-Mailman-Approved-At: Tue, 11 Sep 2012 13:10:03 +0000
Cc: jforbes@redhat.com, "Justin M. Forbes" <jmforbes@linuxtx.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Stefan Bader <stefan.bader@canonical.com>,
	xen-devel@lists.xen.org, Jan Beulich <JBeulich@suse.com>,
	Matt Wilson <msw@amazon.com>
Subject: Re: [Xen-devel] [PATCH/RFC] Fix xsave bug on older Xen hypervisors
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Sep 11, 2012 at 7:37 AM, Konrad Rzeszutek Wilk
<konrad.wilk@oracle.com> wrote:
> On Mon, Sep 10, 2012 at 07:40:47PM -0700, Matt Wilson wrote:
>> > Yes, I can verify that a plain upstream kernel has problems in the first
>> > place, which is why we are carrying a patch to simply disable xsave all
>> > together in the pv guest.
>> > EC2 is not carrying a patch to cripple the hypervisor, there was an old
>> > xen bug that makes all this fail.  The correct fix for that bug is to
>> > patch the hypervisor, but they have not done so. Upstream xen has had
>> > the fix for quite some time, but that doesn't change the fact that a lot
>> > of xen guest usage these days is on EC2.  This is no different than
>> > putting in a quirk to work around a firmware bug in common use.
>>
>> I've done some testing and have results that indicate otherwise. The
>> out-of-tree xen_write_cr4() patch is not needed as of 2.6.39. I tested
>> 3.2.21 on a machine that has XSAVE capabilities:
>>
>> [ec2-user@ip-10-160-18-80 ~]$ cpuid -1 -i | grep -i xsave/xstor
>>       XSAVE/XSTOR states                      = true
>>       OS-enabled XSAVE/XSTOR                  = false
>>
>> on an older hypervisor build:
>>
>> [ec2-user@ip-10-160-18-80 ~]$ cat /sys/hypervisor/version/major
>> 3
>> [ec2-user@ip-10-160-18-80 ~]$ cat /sys/hypervisor/version/minor
>> 0
>>
>> and it boots without a problem. This patch correctly detects that the
>> hypervisor supports XSAVE by testing for OSXSAVE:
>>
>> commit 947ccf9c3c30307b774af3666ee74fcd9f47f646
>> Author:     Shan Haitao <haitao.shan@intel.com>
>> AuthorDate: Tue Nov 9 11:43:36 2010 -0800
>> Commit:     Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
>> CommitDate: Wed Apr 6 08:31:13 2011 -0400
>>
>>     xen: Allow PV-OPS kernel to detect whether XSAVE is supported
>>
>>     Xen fails to mask XSAVE from the cpuid feature, despite not historically
>>     supporting guest use of XSAVE.  However, now that XSAVE support has been
>>     added to Xen, we need to reliably detect its presence.
>>
>>     The most reliable way to do this is to look at the OSXSAVE feature in
>>     cpuid which is set iff the OS (Xen, in this case), has set
>>     CR4.OSXSAVE.
>>
>> Matt
>
> Hey Matt,
>
> Thank you for testing. CC-ing some of the Fedora folks so they are aware that they
> can ditch the: fix_xen_guest_on_old_EC2.patch

Ditched.  Thanks Matt and Konrad.

(BTW, kernel-team@fedoraproject.org is the easiest way to get things to
the fedora kernel team.)

josh

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 11 13:10:18 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 2012 13: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 1TBQE7-0001sB-Tx; Tue, 11 Sep 2012 13:10:03 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jwboyer@gmail.com>) id 1TBQB4-0001rV-Ls
	for xen-devel@lists.xen.org; Tue, 11 Sep 2012 13:06:54 +0000
Received: from [85.158.143.35:37642] by server-2.bemta-4.messagelabs.com id
	5D/97-21239-E673F405; Tue, 11 Sep 2012 13:06:54 +0000
X-Env-Sender: jwboyer@gmail.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1347368811!6016668!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-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31173 invoked from network); 11 Sep 2012 13:06:52 -0000
Received: from mail-vc0-f173.google.com (HELO mail-vc0-f173.google.com)
	(209.85.220.173)
	by server-4.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Sep 2012 13:06:52 -0000
Received: by vcbfl15 with SMTP id fl15so738634vcb.32
	for <xen-devel@lists.xen.org>; Tue, 11 Sep 2012 06:06:51 -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=+zTMJvb+gWvgtENwBTczEZ4Fyz8g3g86HRHa5mKY1as=;
	b=ZHYkYyiqZCUOY/ScOOa4zka6MK2lXIvj4fznrQgmCXdXoEOlR3JsX0PIDmp4ItBjDb
	Hajx9x/CbGGxICW0AnN+UbN3UtBPZxEkYKdc3J/VvdzUJy77w9GEs3kYLnl+656p3kbg
	b4/ZCD21SntDdp2WKvsXp+rfFLHNc7FbZ1ucG3ZCnCi1NFB9yWn3vuF7sECFpiWVS3FA
	pfSmziWmPYnhWof9tQe4euIXzvLcrt5lQN7nP1ncCXfUrJF3XRklJVmnXUuR1DRPpU4h
	DVltvH0Gp/Ktez3lOB35/Gx8fI1R74p0WG3n7E+Pp5+9BuNdDfYM/7hC94D1ntAFKVcp
	BC7g==
MIME-Version: 1.0
Received: by 10.52.31.3 with SMTP id w3mr13561350vdh.33.1347368811269; Tue, 11
	Sep 2012 06:06:51 -0700 (PDT)
Received: by 10.59.1.102 with HTTP; Tue, 11 Sep 2012 06:06:51 -0700 (PDT)
In-Reply-To: <20120911113715.GA28221@phenom.dumpdata.com>
References: <1347018043-21252-1-git-send-email-stefan.bader@canonical.com>
	<504A05B00200007800099C7B@nat28.tlf.novell.com>
	<5049F4E9.9050306@canonical.com>
	<504A1A950200007800099D4C@nat28.tlf.novell.com>
	<20120907142251.GA20096@linuxtx.org>
	<504A32800200007800099E40@nat28.tlf.novell.com>
	<1347033622.2980.12.camel@fedora64.linuxtx.org>
	<20120911024047.GA7620@u002268147cd4502c336d.ant.amazon.com>
	<20120911113715.GA28221@phenom.dumpdata.com>
Date: Tue, 11 Sep 2012 09:06:51 -0400
Message-ID: <CA+5PVA48UY6ckcKF3fMVvGk4rDtaZucff82gshyLkVgZEpppcw@mail.gmail.com>
From: Josh Boyer <jwboyer@gmail.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
X-Mailman-Approved-At: Tue, 11 Sep 2012 13:10:03 +0000
Cc: jforbes@redhat.com, "Justin M. Forbes" <jmforbes@linuxtx.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Stefan Bader <stefan.bader@canonical.com>,
	xen-devel@lists.xen.org, Jan Beulich <JBeulich@suse.com>,
	Matt Wilson <msw@amazon.com>
Subject: Re: [Xen-devel] [PATCH/RFC] Fix xsave bug on older Xen hypervisors
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Sep 11, 2012 at 7:37 AM, Konrad Rzeszutek Wilk
<konrad.wilk@oracle.com> wrote:
> On Mon, Sep 10, 2012 at 07:40:47PM -0700, Matt Wilson wrote:
>> > Yes, I can verify that a plain upstream kernel has problems in the first
>> > place, which is why we are carrying a patch to simply disable xsave all
>> > together in the pv guest.
>> > EC2 is not carrying a patch to cripple the hypervisor, there was an old
>> > xen bug that makes all this fail.  The correct fix for that bug is to
>> > patch the hypervisor, but they have not done so. Upstream xen has had
>> > the fix for quite some time, but that doesn't change the fact that a lot
>> > of xen guest usage these days is on EC2.  This is no different than
>> > putting in a quirk to work around a firmware bug in common use.
>>
>> I've done some testing and have results that indicate otherwise. The
>> out-of-tree xen_write_cr4() patch is not needed as of 2.6.39. I tested
>> 3.2.21 on a machine that has XSAVE capabilities:
>>
>> [ec2-user@ip-10-160-18-80 ~]$ cpuid -1 -i | grep -i xsave/xstor
>>       XSAVE/XSTOR states                      = true
>>       OS-enabled XSAVE/XSTOR                  = false
>>
>> on an older hypervisor build:
>>
>> [ec2-user@ip-10-160-18-80 ~]$ cat /sys/hypervisor/version/major
>> 3
>> [ec2-user@ip-10-160-18-80 ~]$ cat /sys/hypervisor/version/minor
>> 0
>>
>> and it boots without a problem. This patch correctly detects that the
>> hypervisor supports XSAVE by testing for OSXSAVE:
>>
>> commit 947ccf9c3c30307b774af3666ee74fcd9f47f646
>> Author:     Shan Haitao <haitao.shan@intel.com>
>> AuthorDate: Tue Nov 9 11:43:36 2010 -0800
>> Commit:     Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
>> CommitDate: Wed Apr 6 08:31:13 2011 -0400
>>
>>     xen: Allow PV-OPS kernel to detect whether XSAVE is supported
>>
>>     Xen fails to mask XSAVE from the cpuid feature, despite not historically
>>     supporting guest use of XSAVE.  However, now that XSAVE support has been
>>     added to Xen, we need to reliably detect its presence.
>>
>>     The most reliable way to do this is to look at the OSXSAVE feature in
>>     cpuid which is set iff the OS (Xen, in this case), has set
>>     CR4.OSXSAVE.
>>
>> Matt
>
> Hey Matt,
>
> Thank you for testing. CC-ing some of the Fedora folks so they are aware that they
> can ditch the: fix_xen_guest_on_old_EC2.patch

Ditched.  Thanks Matt and Konrad.

(BTW, kernel-team@fedoraproject.org is the easiest way to get things to
the fedora kernel team.)

josh

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 11 13:12:39 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 2012 13:12: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 1TBQGP-0001yI-RH; Tue, 11 Sep 2012 13:12:25 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1TBQGO-0001xr-38
	for xen-devel@lists.xen.org; Tue, 11 Sep 2012 13:12:24 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1347369110!3556792!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-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19568 invoked from network); 11 Sep 2012 13:11:50 -0000
Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com)
	(74.125.83.45)
	by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Sep 2012 13:11:50 -0000
Received: by eeke53 with SMTP id e53so429253eek.32
	for <xen-devel@lists.xen.org>; Tue, 11 Sep 2012 06:11:50 -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=r3OmaeGl9CKllw1hObphZqH5UckRRPnx/qYv1HUZl5w=;
	b=yvMIsoUcIpqK67vBwqXUs8/AucYI+IVSdqkFPNwG/MZHx19ugoQ39TqhU7HoD8wiDa
	fauaAJ612TUtgguFEqGkvonBidtJFzvhN/0XmNYs5qR0d54o4cSg4I7ERvEKWwIddoAV
	WDaGUCfqVUnBo6mV1tmjhG5Q+3AMhk6pzU1hyE0c9XE3RUzmor9OkVaKmXbrM2U6WpZw
	3MAAZZDhhSrkiqzftMXf2bXkYb7VQ6MArKSsdY6TC/2oRI6xH97iz8N4aztI1ClCCsnh
	qti/NHXs+c1iytPwWzuu90yy5GEBDqTQRV6omA1iUCSLZR/SPQ+gzKlTS3agzSm0HDx6
	6RWw==
Received: by 10.14.179.200 with SMTP id h48mr25674106eem.12.1347369110427;
	Tue, 11 Sep 2012 06:11:50 -0700 (PDT)
Received: from [192.168.1.3] ([86.184.74.117])
	by mx.google.com with ESMTPS id y1sm47039509eel.0.2012.09.11.06.11.38
	(version=SSLv3 cipher=OTHER); Tue, 11 Sep 2012 06:11:49 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.33.0.120411
Date: Tue, 11 Sep 2012 14:11:30 +0100
From: Keir Fraser <keir@xen.org>
To: Jan Beulich <JBeulich@suse.com>,
	xen-devel <xen-devel@lists.xen.org>
Message-ID: <CC74F712.4B6F5%keir@xen.org>
Thread-Topic: [Xen-devel] [PATCH RFC 0/8] console improvements
Thread-Index: Ac2QHvUmjgfj4NRyxU+6mpseNkfaVw==
In-Reply-To: <504F2A71020000780009A7ED@nat28.tlf.novell.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] [PATCH RFC 0/8] console improvements
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/09/2012 11:11, "Jan Beulich" <JBeulich@suse.com> wrote:

> This series adds support for an EHCI debug port based console, and
> does some other improvements and cleanup noticed to be desirable
> during the implementation of the former as follow-up.
> 
> 1: x86: allow early use of fixmaps
> 2: console: prepare for non-COMn port support
> 3: console: add EHCI debug port based serial console
> 4: serial: avoid fully initializing unused consoles
> 5: ns16550: MMIO adjustments
> 6: ns16550: PCI initialization adjustments
> 7: ns16550: command line parsing adjustments
> 8: drop tx_fifo_size
> 
> Note that this also requires a Dom0 kernel side enhancement,
> which I'm reproducing below for reference (intending to submit
> this only when the public interface change on the hypervisor
> side is approved, which in turn will take its time due to the
> current feature freeze).
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Acked-by: Keir Fraser <keir@xen.org>

> --- a/drivers/usb/early/ehci-dbgp.c
> +++ b/drivers/usb/early/ehci-dbgp.c
> @@ -491,7 +491,7 @@ static int ehci_wait_for_port(int port);
>   * Return -ENODEV for any general failure
>   * Return -EIO if wait for port fails
>   */
> -int dbgp_external_startup(void)
> +static int _dbgp_external_startup(void)
>  {
> int devnum;
> struct usb_debug_descriptor dbgp_desc;
> @@ -613,6 +613,11 @@ err:
> goto try_again;
> return -ENODEV;
>  }
> +
> +int dbgp_external_startup(struct usb_hcd *hcd)
> +{
> + return xen_dbgp_external_startup(hcd) ?: _dbgp_external_startup();
> +}
>  EXPORT_SYMBOL_GPL(dbgp_external_startup);
>  
>  static int ehci_reset_port(int port)
> @@ -804,7 +809,7 @@ try_next_port:
> dbgp_ehci_status("ehci skip - already configured");
> }
>  
> - ret = dbgp_external_startup();
> + ret = _dbgp_external_startup();
> if (ret == -EIO)
> goto next_debug_port;
>  
> @@ -934,7 +939,7 @@ static void early_dbgp_write(struct cons
> ctrl = readl(&ehci_debug->control);
> if (!(ctrl & DBGP_ENABLED)) {
> dbgp_not_safe = 1;
> -   dbgp_external_startup();
> +   _dbgp_external_startup();
> } else {
> cmd |= CMD_RUN;
> writel(cmd, &ehci_regs->command);
> @@ -974,10 +979,14 @@ struct console early_dbgp_console = {
> .index = -1,
>  };
>  
> -int dbgp_reset_prep(void)
> +int dbgp_reset_prep(struct usb_hcd *hcd)
>  {
> + int ret = xen_dbgp_reset_prep(hcd);
> u32 ctrl;
>  
> + if (ret)
> +  return ret;
> +
> dbgp_not_safe = 1;
> if (!ehci_debug)
> return 0;
> --- a/drivers/usb/host/ehci-hcd.c
> +++ b/drivers/usb/host/ehci-hcd.c
> @@ -321,7 +321,7 @@ static int ehci_reset (struct ehci_hcd *
>  
> /* If the EHCI debug controller is active, special care must be
> * taken before and after a host controller reset */
> - if (ehci->debug && !dbgp_reset_prep())
> + if (ehci->debug && !dbgp_reset_prep(ehci_to_hcd(ehci)))
> ehci->debug = NULL;
>  
> command |= CMD_RESET;
> @@ -345,7 +345,7 @@ static int ehci_reset (struct ehci_hcd *
> tdi_reset (ehci);
>  
> if (ehci->debug)
> -  dbgp_external_startup();
> +  dbgp_external_startup(ehci_to_hcd(ehci));
>  
> ehci->port_c_suspend = ehci->suspended_ports =
> ehci->resuming_ports = 0;
> --- a/drivers/usb/host/ehci-hub.c
> +++ b/drivers/usb/host/ehci-hub.c
> @@ -347,10 +347,10 @@ static int ehci_bus_resume (struct usb_h
> }
>  
> if (unlikely(ehci->debug)) {
> -  if (!dbgp_reset_prep())
> +  if (!dbgp_reset_prep(hcd))
> ehci->debug = NULL;
> else
> -   dbgp_external_startup();
> +   dbgp_external_startup(hcd);
> }
>  
> /* Ideally and we've got a real resume here, and no port's power
> --- a/drivers/xen/Makefile
> +++ b/drivers/xen/Makefile
> @@ -21,6 +21,7 @@ CFLAGS_features.o   := $(nostackp)
>  endif
>  
>  priv-$(CONFIG_PCI)   := pci.o
> +priv-$(CONFIG_USB_SUPPORT)  += dbgp.o
>  
>  obj-$(CONFIG_XEN)   += features.o $(xen-backend-y) $(xen-backend-m)
>  obj-$(CONFIG_XEN_PRIVILEGED_GUEST) += $(priv-y)
> @@ -37,7 +38,7 @@ obj-$(CONFIG_XEN_SYS_HYPERVISOR) += sys-
>  obj-$(CONFIG_XEN_PVHVM)   += platform-pci.o
>  obj-$(CONFIG_XEN_TMEM)   += tmem.o
>  obj-$(CONFIG_SWIOTLB_XEN)  += swiotlb-xen.o
> -obj-$(CONFIG_XEN_DOM0)   += pci.o
> +obj-$(CONFIG_XEN_DOM0)   += pci.o dbgp.o
>  obj-$(CONFIG_XEN_PCIDEV_BACKEND) += xen-pciback/
>  obj-$(CONFIG_XEN_PRIVCMD)  += $(xen-privcmd_y)
>  obj-$(CONFIG_XEN_ACPI_PROCESSOR) += xen-acpi-processor.o
> --- /dev/null
> +++ b/drivers/xen/dbgp.c
> @@ -0,0 +1,48 @@
> +#include <linux/pci.h>
> +#include <linux/usb.h>
> +#include <linux/usb/ehci_def.h>
> +#include <linux/usb/hcd.h>
> +#include <asm/xen/hypercall.h>
> +#include <xen/interface/physdev.h>
> +#include <xen/xen.h>
> +
> +static int xen_dbgp_op(struct usb_hcd *hcd, int op)
> +{
> + const struct device *ctrlr = hcd_to_bus(hcd)->controller;
> + struct physdev_dbgp_op dbgp;
> +
> + if (!xen_initial_domain())
> +  return 0;
> +
> + dbgp.op = op;
> +
> +#ifdef CONFIG_PCI
> + if (ctrlr->bus == &pci_bus_type) {
> +  const struct pci_dev *pdev = to_pci_dev(ctrlr);
> +
> +  dbgp.u.pci.seg = pci_domain_nr(pdev->bus);
> +  dbgp.u.pci.bus = pdev->bus->number;
> +  dbgp.u.pci.devfn = pdev->devfn;
> +  dbgp.bus = PHYSDEVOP_DBGP_BUS_PCI;
> + } else
> +#endif
> +  dbgp.bus = PHYSDEVOP_DBGP_BUS_UNKNOWN;
> +
> + return HYPERVISOR_physdev_op(PHYSDEVOP_dbgp_op, &dbgp);
> +}
> +
> +int xen_dbgp_reset_prep(struct usb_hcd *hcd)
> +{
> + return xen_dbgp_op(hcd, PHYSDEVOP_DBGP_RESET_PREPARE);
> +}
> +
> +int xen_dbgp_external_startup(struct usb_hcd *hcd)
> +{
> + return xen_dbgp_op(hcd, PHYSDEVOP_DBGP_RESET_DONE);
> +}
> +
> +#ifndef CONFIG_EARLY_PRINTK_DBGP
> +#include <linux/export.h>
> +EXPORT_SYMBOL_GPL(xen_dbgp_reset_prep);
> +EXPORT_SYMBOL_GPL(xen_dbgp_external_startup);
> +#endif
> --- a/include/linux/usb/ehci_def.h
> +++ b/include/linux/usb/ehci_def.h
> @@ -207,18 +207,35 @@ extern int __init early_dbgp_init(char *
>  extern struct console early_dbgp_console;
>  #endif /* CONFIG_EARLY_PRINTK_DBGP */
>  
> +struct usb_hcd;
> +
> +#if defined(CONFIG_XEN_PRIVILEGED_GUEST) || defined(CONFIG_XEN_DOM0)
> +extern int xen_dbgp_reset_prep(struct usb_hcd *);
> +extern int xen_dbgp_external_startup(struct usb_hcd *);
> +#else
> +static inline int xen_dbgp_reset_prep(struct usb_hcd *hcd)
> +{
> + return 1; /* Shouldn't this be 0? */
> +}
> +
> +static inline int xen_dbgp_external_startup(struct usb_hcd *hcd)
> +{
> + return -1;
> +}
> +#endif
> +
>  #ifdef CONFIG_EARLY_PRINTK_DBGP
>  /* Call backs from ehci host driver to ehci debug driver */
> -extern int dbgp_external_startup(void);
> -extern int dbgp_reset_prep(void);
> +extern int dbgp_external_startup(struct usb_hcd *);
> +extern int dbgp_reset_prep(struct usb_hcd *hcd);
>  #else
> -static inline int dbgp_reset_prep(void)
> +static inline int dbgp_reset_prep(struct usb_hcd *hcd)
>  {
> - return 1;
> + return xen_dbgp_reset_prep(hcd);
>  }
> -static inline int dbgp_external_startup(void)
> +static inline int dbgp_external_startup(struct usb_hcd *hcd)
>  {
> - return -1;
> + return xen_dbgp_external_startup(hcd);
>  }
>  #endif
>  
> --- a/include/xen/interface/physdev.h
> +++ b/include/xen/interface/physdev.h
> @@ -307,6 +307,24 @@ struct physdev_pci_device {
>  typedef struct physdev_pci_device physdev_pci_device_t;
>  DEFINE_XEN_GUEST_HANDLE(physdev_pci_device_t);
>  
> +#define PHYSDEVOP_DBGP_RESET_PREPARE    1
> +#define PHYSDEVOP_DBGP_RESET_DONE       2
> +
> +#define PHYSDEVOP_DBGP_BUS_UNKNOWN      0
> +#define PHYSDEVOP_DBGP_BUS_PCI          1
> +
> +#define PHYSDEVOP_dbgp_op               29
> +struct physdev_dbgp_op {
> +    /* IN */
> +    uint8_t op;
> +    uint8_t bus;
> +    union {
> +        struct physdev_pci_device pci;
> +    } u;
> +};
> +typedef struct physdev_dbgp_op physdev_dbgp_op_t;
> +DEFINE_XEN_GUEST_HANDLE(physdev_dbgp_op_t);
> +
>  /*
>   * Notify that some PIRQ-bound event channels have been unmasked.
>   * ** This command is obsolete since interface version 0x00030202 and is **
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 11 13:12:39 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 2012 13:12: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 1TBQGP-0001yI-RH; Tue, 11 Sep 2012 13:12:25 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1TBQGO-0001xr-38
	for xen-devel@lists.xen.org; Tue, 11 Sep 2012 13:12:24 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1347369110!3556792!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-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19568 invoked from network); 11 Sep 2012 13:11:50 -0000
Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com)
	(74.125.83.45)
	by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Sep 2012 13:11:50 -0000
Received: by eeke53 with SMTP id e53so429253eek.32
	for <xen-devel@lists.xen.org>; Tue, 11 Sep 2012 06:11:50 -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=r3OmaeGl9CKllw1hObphZqH5UckRRPnx/qYv1HUZl5w=;
	b=yvMIsoUcIpqK67vBwqXUs8/AucYI+IVSdqkFPNwG/MZHx19ugoQ39TqhU7HoD8wiDa
	fauaAJ612TUtgguFEqGkvonBidtJFzvhN/0XmNYs5qR0d54o4cSg4I7ERvEKWwIddoAV
	WDaGUCfqVUnBo6mV1tmjhG5Q+3AMhk6pzU1hyE0c9XE3RUzmor9OkVaKmXbrM2U6WpZw
	3MAAZZDhhSrkiqzftMXf2bXkYb7VQ6MArKSsdY6TC/2oRI6xH97iz8N4aztI1ClCCsnh
	qti/NHXs+c1iytPwWzuu90yy5GEBDqTQRV6omA1iUCSLZR/SPQ+gzKlTS3agzSm0HDx6
	6RWw==
Received: by 10.14.179.200 with SMTP id h48mr25674106eem.12.1347369110427;
	Tue, 11 Sep 2012 06:11:50 -0700 (PDT)
Received: from [192.168.1.3] ([86.184.74.117])
	by mx.google.com with ESMTPS id y1sm47039509eel.0.2012.09.11.06.11.38
	(version=SSLv3 cipher=OTHER); Tue, 11 Sep 2012 06:11:49 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.33.0.120411
Date: Tue, 11 Sep 2012 14:11:30 +0100
From: Keir Fraser <keir@xen.org>
To: Jan Beulich <JBeulich@suse.com>,
	xen-devel <xen-devel@lists.xen.org>
Message-ID: <CC74F712.4B6F5%keir@xen.org>
Thread-Topic: [Xen-devel] [PATCH RFC 0/8] console improvements
Thread-Index: Ac2QHvUmjgfj4NRyxU+6mpseNkfaVw==
In-Reply-To: <504F2A71020000780009A7ED@nat28.tlf.novell.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] [PATCH RFC 0/8] console improvements
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/09/2012 11:11, "Jan Beulich" <JBeulich@suse.com> wrote:

> This series adds support for an EHCI debug port based console, and
> does some other improvements and cleanup noticed to be desirable
> during the implementation of the former as follow-up.
> 
> 1: x86: allow early use of fixmaps
> 2: console: prepare for non-COMn port support
> 3: console: add EHCI debug port based serial console
> 4: serial: avoid fully initializing unused consoles
> 5: ns16550: MMIO adjustments
> 6: ns16550: PCI initialization adjustments
> 7: ns16550: command line parsing adjustments
> 8: drop tx_fifo_size
> 
> Note that this also requires a Dom0 kernel side enhancement,
> which I'm reproducing below for reference (intending to submit
> this only when the public interface change on the hypervisor
> side is approved, which in turn will take its time due to the
> current feature freeze).
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Acked-by: Keir Fraser <keir@xen.org>

> --- a/drivers/usb/early/ehci-dbgp.c
> +++ b/drivers/usb/early/ehci-dbgp.c
> @@ -491,7 +491,7 @@ static int ehci_wait_for_port(int port);
>   * Return -ENODEV for any general failure
>   * Return -EIO if wait for port fails
>   */
> -int dbgp_external_startup(void)
> +static int _dbgp_external_startup(void)
>  {
> int devnum;
> struct usb_debug_descriptor dbgp_desc;
> @@ -613,6 +613,11 @@ err:
> goto try_again;
> return -ENODEV;
>  }
> +
> +int dbgp_external_startup(struct usb_hcd *hcd)
> +{
> + return xen_dbgp_external_startup(hcd) ?: _dbgp_external_startup();
> +}
>  EXPORT_SYMBOL_GPL(dbgp_external_startup);
>  
>  static int ehci_reset_port(int port)
> @@ -804,7 +809,7 @@ try_next_port:
> dbgp_ehci_status("ehci skip - already configured");
> }
>  
> - ret = dbgp_external_startup();
> + ret = _dbgp_external_startup();
> if (ret == -EIO)
> goto next_debug_port;
>  
> @@ -934,7 +939,7 @@ static void early_dbgp_write(struct cons
> ctrl = readl(&ehci_debug->control);
> if (!(ctrl & DBGP_ENABLED)) {
> dbgp_not_safe = 1;
> -   dbgp_external_startup();
> +   _dbgp_external_startup();
> } else {
> cmd |= CMD_RUN;
> writel(cmd, &ehci_regs->command);
> @@ -974,10 +979,14 @@ struct console early_dbgp_console = {
> .index = -1,
>  };
>  
> -int dbgp_reset_prep(void)
> +int dbgp_reset_prep(struct usb_hcd *hcd)
>  {
> + int ret = xen_dbgp_reset_prep(hcd);
> u32 ctrl;
>  
> + if (ret)
> +  return ret;
> +
> dbgp_not_safe = 1;
> if (!ehci_debug)
> return 0;
> --- a/drivers/usb/host/ehci-hcd.c
> +++ b/drivers/usb/host/ehci-hcd.c
> @@ -321,7 +321,7 @@ static int ehci_reset (struct ehci_hcd *
>  
> /* If the EHCI debug controller is active, special care must be
> * taken before and after a host controller reset */
> - if (ehci->debug && !dbgp_reset_prep())
> + if (ehci->debug && !dbgp_reset_prep(ehci_to_hcd(ehci)))
> ehci->debug = NULL;
>  
> command |= CMD_RESET;
> @@ -345,7 +345,7 @@ static int ehci_reset (struct ehci_hcd *
> tdi_reset (ehci);
>  
> if (ehci->debug)
> -  dbgp_external_startup();
> +  dbgp_external_startup(ehci_to_hcd(ehci));
>  
> ehci->port_c_suspend = ehci->suspended_ports =
> ehci->resuming_ports = 0;
> --- a/drivers/usb/host/ehci-hub.c
> +++ b/drivers/usb/host/ehci-hub.c
> @@ -347,10 +347,10 @@ static int ehci_bus_resume (struct usb_h
> }
>  
> if (unlikely(ehci->debug)) {
> -  if (!dbgp_reset_prep())
> +  if (!dbgp_reset_prep(hcd))
> ehci->debug = NULL;
> else
> -   dbgp_external_startup();
> +   dbgp_external_startup(hcd);
> }
>  
> /* Ideally and we've got a real resume here, and no port's power
> --- a/drivers/xen/Makefile
> +++ b/drivers/xen/Makefile
> @@ -21,6 +21,7 @@ CFLAGS_features.o   := $(nostackp)
>  endif
>  
>  priv-$(CONFIG_PCI)   := pci.o
> +priv-$(CONFIG_USB_SUPPORT)  += dbgp.o
>  
>  obj-$(CONFIG_XEN)   += features.o $(xen-backend-y) $(xen-backend-m)
>  obj-$(CONFIG_XEN_PRIVILEGED_GUEST) += $(priv-y)
> @@ -37,7 +38,7 @@ obj-$(CONFIG_XEN_SYS_HYPERVISOR) += sys-
>  obj-$(CONFIG_XEN_PVHVM)   += platform-pci.o
>  obj-$(CONFIG_XEN_TMEM)   += tmem.o
>  obj-$(CONFIG_SWIOTLB_XEN)  += swiotlb-xen.o
> -obj-$(CONFIG_XEN_DOM0)   += pci.o
> +obj-$(CONFIG_XEN_DOM0)   += pci.o dbgp.o
>  obj-$(CONFIG_XEN_PCIDEV_BACKEND) += xen-pciback/
>  obj-$(CONFIG_XEN_PRIVCMD)  += $(xen-privcmd_y)
>  obj-$(CONFIG_XEN_ACPI_PROCESSOR) += xen-acpi-processor.o
> --- /dev/null
> +++ b/drivers/xen/dbgp.c
> @@ -0,0 +1,48 @@
> +#include <linux/pci.h>
> +#include <linux/usb.h>
> +#include <linux/usb/ehci_def.h>
> +#include <linux/usb/hcd.h>
> +#include <asm/xen/hypercall.h>
> +#include <xen/interface/physdev.h>
> +#include <xen/xen.h>
> +
> +static int xen_dbgp_op(struct usb_hcd *hcd, int op)
> +{
> + const struct device *ctrlr = hcd_to_bus(hcd)->controller;
> + struct physdev_dbgp_op dbgp;
> +
> + if (!xen_initial_domain())
> +  return 0;
> +
> + dbgp.op = op;
> +
> +#ifdef CONFIG_PCI
> + if (ctrlr->bus == &pci_bus_type) {
> +  const struct pci_dev *pdev = to_pci_dev(ctrlr);
> +
> +  dbgp.u.pci.seg = pci_domain_nr(pdev->bus);
> +  dbgp.u.pci.bus = pdev->bus->number;
> +  dbgp.u.pci.devfn = pdev->devfn;
> +  dbgp.bus = PHYSDEVOP_DBGP_BUS_PCI;
> + } else
> +#endif
> +  dbgp.bus = PHYSDEVOP_DBGP_BUS_UNKNOWN;
> +
> + return HYPERVISOR_physdev_op(PHYSDEVOP_dbgp_op, &dbgp);
> +}
> +
> +int xen_dbgp_reset_prep(struct usb_hcd *hcd)
> +{
> + return xen_dbgp_op(hcd, PHYSDEVOP_DBGP_RESET_PREPARE);
> +}
> +
> +int xen_dbgp_external_startup(struct usb_hcd *hcd)
> +{
> + return xen_dbgp_op(hcd, PHYSDEVOP_DBGP_RESET_DONE);
> +}
> +
> +#ifndef CONFIG_EARLY_PRINTK_DBGP
> +#include <linux/export.h>
> +EXPORT_SYMBOL_GPL(xen_dbgp_reset_prep);
> +EXPORT_SYMBOL_GPL(xen_dbgp_external_startup);
> +#endif
> --- a/include/linux/usb/ehci_def.h
> +++ b/include/linux/usb/ehci_def.h
> @@ -207,18 +207,35 @@ extern int __init early_dbgp_init(char *
>  extern struct console early_dbgp_console;
>  #endif /* CONFIG_EARLY_PRINTK_DBGP */
>  
> +struct usb_hcd;
> +
> +#if defined(CONFIG_XEN_PRIVILEGED_GUEST) || defined(CONFIG_XEN_DOM0)
> +extern int xen_dbgp_reset_prep(struct usb_hcd *);
> +extern int xen_dbgp_external_startup(struct usb_hcd *);
> +#else
> +static inline int xen_dbgp_reset_prep(struct usb_hcd *hcd)
> +{
> + return 1; /* Shouldn't this be 0? */
> +}
> +
> +static inline int xen_dbgp_external_startup(struct usb_hcd *hcd)
> +{
> + return -1;
> +}
> +#endif
> +
>  #ifdef CONFIG_EARLY_PRINTK_DBGP
>  /* Call backs from ehci host driver to ehci debug driver */
> -extern int dbgp_external_startup(void);
> -extern int dbgp_reset_prep(void);
> +extern int dbgp_external_startup(struct usb_hcd *);
> +extern int dbgp_reset_prep(struct usb_hcd *hcd);
>  #else
> -static inline int dbgp_reset_prep(void)
> +static inline int dbgp_reset_prep(struct usb_hcd *hcd)
>  {
> - return 1;
> + return xen_dbgp_reset_prep(hcd);
>  }
> -static inline int dbgp_external_startup(void)
> +static inline int dbgp_external_startup(struct usb_hcd *hcd)
>  {
> - return -1;
> + return xen_dbgp_external_startup(hcd);
>  }
>  #endif
>  
> --- a/include/xen/interface/physdev.h
> +++ b/include/xen/interface/physdev.h
> @@ -307,6 +307,24 @@ struct physdev_pci_device {
>  typedef struct physdev_pci_device physdev_pci_device_t;
>  DEFINE_XEN_GUEST_HANDLE(physdev_pci_device_t);
>  
> +#define PHYSDEVOP_DBGP_RESET_PREPARE    1
> +#define PHYSDEVOP_DBGP_RESET_DONE       2
> +
> +#define PHYSDEVOP_DBGP_BUS_UNKNOWN      0
> +#define PHYSDEVOP_DBGP_BUS_PCI          1
> +
> +#define PHYSDEVOP_dbgp_op               29
> +struct physdev_dbgp_op {
> +    /* IN */
> +    uint8_t op;
> +    uint8_t bus;
> +    union {
> +        struct physdev_pci_device pci;
> +    } u;
> +};
> +typedef struct physdev_dbgp_op physdev_dbgp_op_t;
> +DEFINE_XEN_GUEST_HANDLE(physdev_dbgp_op_t);
> +
>  /*
>   * Notify that some PIRQ-bound event channels have been unmasked.
>   * ** This command is obsolete since interface version 0x00030202 and is **
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 11 13:12:39 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 2012 13:12: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 1TBQGP-0001yB-G3; Tue, 11 Sep 2012 13:12:25 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1TBQGN-0001xp-IJ
	for xen-devel@lists.xen.org; Tue, 11 Sep 2012 13:12:23 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1347369110!3556792!2
X-Originating-IP: [74.125.83.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20234 invoked from network); 11 Sep 2012 13:12:00 -0000
Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com)
	(74.125.83.45)
	by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Sep 2012 13:12:00 -0000
Received: by mail-ee0-f45.google.com with SMTP id e53so429253eek.32
	for <xen-devel@lists.xen.org>; Tue, 11 Sep 2012 06:12:00 -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=7GS5RLCAwXXbNQUDCnoZaQPY19Vtq62Tah9sM0S1vC4=;
	b=x4s7oNmUFT0ycls42V5CSLTyeGKeATe+vvdtK+I6SlHes1MOu5Drvb0nTJeNxJ4Svf
	Klc3IjbUiUtQW7YvaZyQCxJvX6tdQB9q1M4ywTwWFr8DtxcQme4Sy1RROjF7bUzgJDKO
	ow9yIC338RMzdXCKOf1gUdtyWZ8Z+yX8mUEOD+6eHyggBmqLwYIK3oCmnsLG609FpKT0
	0QSvmQ0PXh46FVRF1loc75Hlrt+RQhS49AVO3HTiepbrvnV269flEcWmbHvmd4pEGaIA
	IkBWQC8ZwcELm9UE7XB8AVkNSqq/DPOQHXqraUaYxtEGmJbyy2VL7PZfk7EXltZR7wSv
	En8Q==
Received: by 10.14.203.73 with SMTP id e49mr25574021eeo.27.1347369120812;
	Tue, 11 Sep 2012 06:12:00 -0700 (PDT)
Received: from [192.168.1.3] ([86.184.74.117])
	by mx.google.com with ESMTPS id y1sm47039509eel.0.2012.09.11.06.11.51
	(version=SSLv3 cipher=OTHER); Tue, 11 Sep 2012 06:12:00 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.33.0.120411
Date: Tue, 11 Sep 2012 14:11:50 +0100
From: Keir Fraser <keir@xen.org>
To: Jan Beulich <JBeulich@suse.com>,
	xen-devel <xen-devel@lists.xen.org>
Message-ID: <CC74F726.4B6F6%keir@xen.org>
Thread-Topic: [Xen-devel] [PATCH] PCI: bus scan adjustments
Thread-Index: Ac2QHwESLk6jtyzK506X7jjd6Js/VA==
In-Reply-To: <504F3CC7020000780009A8C7@nat28.tlf.novell.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] [PATCH] PCI: bus scan adjustments
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/09/2012 12:29, "Jan Beulich" <JBeulich@suse.com> wrote:

> As done elsewhere, the ns16550 code shouldn't look at non-zero
> functions of a device if that isn't multi-function.
> 
> Also both there and in pass-through's _scan_pci_devices() skip looking
> at non-zero functions when the device at function zero doesn't exist.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> ---
> Note that to apply cleanly, this has to go on top of the serial console
> improvement series posted earlier.

Acked-by: Keir Fraser <keir@xen.org>

> --- a/xen/drivers/char/ns16550.c
> +++ b/xen/drivers/char/ns16550.c
> @@ -470,21 +470,28 @@ static int
>  pci_uart_config (struct ns16550 *uart, int skip_amt, int bar_idx)
>  {
>      uint32_t bar, len;
> -    int b, d, f;
> +    int b, d, f, nextf;
>  
>      /* NB. Start at bus 1 to avoid AMT: a plug-in card cannot be on bus 0. */
>      for ( b = skip_amt ? 1 : 0; b < 0x100; b++ )
>      {
>          for ( d = 0; d < 0x20; d++ )
>          {
> -            for ( f = 0; f < 0x8; f++ )
> +            for ( f = 0; f < 8; f = nextf )
>              {
> +                nextf = (f || (pci_conf_read16(0, b, d, f, PCI_HEADER_TYPE) &
> +                               0x80)) ? f + 1 : 8;
> +
>                  switch ( pci_conf_read16(0, b, d, f, PCI_CLASS_DEVICE) )
>                  {
>                  case 0x0700: /* single port serial */
>                  case 0x0702: /* multi port serial */
>                  case 0x0780: /* other (e.g serial+parallel) */
>                      break;
> +                case 0xffff:
> +                    if ( !f )
> +                        nextf = 8;
> +                    /* fall through */
>                  default:
>                      continue;
>                  }
> --- a/xen/drivers/passthrough/pci.c
> +++ b/xen/drivers/passthrough/pci.c
> @@ -665,7 +665,11 @@ static int __init _scan_pci_devices(stru
>              for ( func = 0; func < 8; func++ )
>              {
>                  if ( pci_device_detect(pseg->nr, bus, dev, func) == 0 )
> +                {
> +                    if ( !func )
> +                        break;
>                      continue;
> +                }
>  
>                  pdev = alloc_pdev(pseg, bus, PCI_DEVFN(dev, func));
>                  if ( !pdev )
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Sep 11 13:12:39 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 2012 13:12: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 1TBQGP-0001yB-G3; Tue, 11 Sep 2012 13:12:25 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1TBQGN-0001xp-IJ
	for xen-devel@lists.xen.org; Tue, 11 Sep 2012 13:12:23 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1347369110!3556792!2
X-Originating-IP: [74.125.83.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20234 invoked from network); 11 Sep 2012 13:12:00 -0000
Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com)
	(74.125.83.45)
	by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Sep 2012 13:12:00 -0000
Received: by mail-ee0-f45.google.com with SMTP id e53so429253eek.32
	for <xen-devel@lists.xen.org>; Tue, 11 Sep 2012 06:12:00 -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=7GS5RLCAwXXbNQUDCnoZaQPY19Vtq62Tah9sM0S1vC4=;
	b=x4s7oNmUFT0ycls42V5CSLTyeGKeATe+vvdtK+I6SlHes1MOu5Drvb0nTJeNxJ4Svf
	Klc3IjbUiUtQW7YvaZyQCxJvX6tdQB9q1M4ywTwWFr8DtxcQme4Sy1RROjF7bUzgJDKO
	ow9yIC338RMzdXCKOf1gUdtyWZ8Z+yX8mUEOD+6eHyggBmqLwYIK3oCmnsLG609FpKT0
	0QSvmQ0PXh46FVRF1loc75Hlrt+RQhS49AVO3HTiepbrvnV269flEcWmbHvmd4pEGaIA
	IkBWQC8ZwcELm9UE7XB8AVkNSqq/DPOQHXqraUaYxtEGmJbyy2VL7PZfk7EXltZR7wSv
	En8Q==
Received: by 10.14.203.73 with SMTP id e49mr25574021eeo.27.1347369120812;
	Tue, 11 Sep 2012 06:12:00 -0700 (PDT)
Received: from [192.168.1.3] ([86.184.74.117])
	by mx.google.com with ESMTPS id y1sm47039509eel.0.2012.09.11.06.11.51
	(version=SSLv3 cipher=OTHER); Tue, 11 Sep 2012 06:12:00 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.33.0.120411
Date: Tue, 11 Sep 2012 14:11:50 +0100
From: Keir Fraser <keir@xen.org>
To: Jan Beulich <JBeulich@suse.com>,
	xen-devel <xen-devel@lists.xen.org>
Message-ID: <CC74F726.4B6F6%keir@xen.org>
Thread-Topic: [Xen-devel] [PATCH] PCI: bus scan adjustments
Thread-Index: Ac2QHwESLk6jtyzK506X7jjd6Js/VA==
In-Reply-To: <504F3CC7020000780009A8C7@nat28.tlf.novell.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] [PATCH] PCI: bus scan adjustments
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/09/2012 12:29, "Jan Beulich" <JBeulich@suse.com> wrote:

> As done elsewhere, the ns16550 code shouldn't look at non-zero
> functions of a device if that isn't multi-function.
> 
> Also both there and in pass-through's _scan_pci_devices() skip looking
> at non-zero functions when the device at function zero doesn't exist.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> ---
> Note that to apply cleanly, this has to go on top of the serial console
> improvement series posted earlier.

Acked-by: Keir Fraser <keir@xen.org>

> --- a/xen/drivers/char/ns16550.c
> +++ b/xen/drivers/char/ns16550.c
> @@ -470,21 +470,28 @@ static int
>  pci_uart_config (struct ns16550 *uart, int skip_amt, int bar_idx)
>  {
>      uint32_t bar, len;
> -    int b, d, f;
> +    int b, d, f, nextf;
>  
>      /* NB. Start at bus 1 to avoid AMT: a plug-in card cannot be on bus 0. */
>      for ( b = skip_amt ? 1 : 0; b < 0x100; b++ )
>      {
>          for ( d = 0; d < 0x20; d++ )
>          {
> -            for ( f = 0; f < 0x8; f++ )
> +            for ( f = 0; f < 8; f = nextf )
>              {
> +                nextf = (f || (pci_conf_read16(0, b, d, f, PCI_HEADER_TYPE) &
> +                               0x80)) ? f + 1 : 8;
> +
>                  switch ( pci_conf_read16(0, b, d, f, PCI_CLASS_DEVICE) )
>                  {
>                  case 0x0700: /* single port serial */
>                  case 0x0702: /* multi port serial */
>                  case 0x0780: /* other (e.g serial+parallel) */
>                      break;
> +                case 0xffff:
> +                    if ( !f )
> +                        nextf = 8;
> +                    /* fall through */
>                  default:
>                      continue;
>                  }
> --- a/xen/drivers/passthrough/pci.c
> +++ b/xen/drivers/passthrough/pci.c
> @@ -665,7 +665,11 @@ static int __init _scan_pci_devices(stru
>              for ( func = 0; func < 8; func++ )
>              {
>                  if ( pci_device_detect(pseg->nr, bus, dev, func) == 0 )
> +                {
> +                    if ( !func )
> +                        break;
>                      continue;
> +                }
>  
>                  pdev = alloc_pdev(pseg, bus, PCI_DEVFN(dev, func));
>                  if ( !pdev )
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Sep 11 13:12:50 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 2012 13:12:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TBQGc-0001zn-80; Tue, 11 Sep 2012 13:12:38 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1TBQGa-0001yo-Bu
	for xen-devel@lists.xen.org; Tue, 11 Sep 2012 13:12:36 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1347369110!3556792!3
X-Originating-IP: [74.125.83.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21858 invoked from network); 11 Sep 2012 13:12:15 -0000
Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com)
	(74.125.83.45)
	by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Sep 2012 13:12:15 -0000
Received: by mail-ee0-f45.google.com with SMTP id e53so429253eek.32
	for <xen-devel@lists.xen.org>; Tue, 11 Sep 2012 06:12:15 -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=NAPEYIjlEh0wkwotkNEUDI7898dbcOLKQpJddHeS7lM=;
	b=V7rcHMHrr3AQ9YoOZpofbqZiApkUQ9UBCvdccZYDyXM8mhOqK3gBdzNX4mA6+EWoms
	M+pdk+IeBjJsN66SlO4HatRnB8dXeoe/P9Cbpd/4kGQFNEZylnK2myeRMql+ssWRaQJq
	a0cvRmGjeROdRO1vjFmBfY/RD25sd/2jzEUazWdL2wBeNLef938mwFnFaDL06K7hRzeg
	9LmdFWktPEvqwqhiWIhwfLz+V4tYdsP+1XAZpHnHeWnfJQi4MujGXYD6hXuhqKEQNCXS
	ndQ0Zk5pUCciNL/e6XgnNxWke6P5s4xj5R4Y/SfBOrB9taPUYVlcU+A81AW2u3za5jS2
	tGgw==
Received: by 10.14.207.9 with SMTP id m9mr25455819eeo.5.1347369135754;
	Tue, 11 Sep 2012 06:12:15 -0700 (PDT)
Received: from [192.168.1.3] (host86-184-74-117.range86-184.btcentralplus.com.
	[86.184.74.117])
	by mx.google.com with ESMTPS id i41sm47014469eem.7.2012.09.11.06.12.10
	(version=SSLv3 cipher=OTHER); Tue, 11 Sep 2012 06:12:14 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.33.0.120411
Date: Tue, 11 Sep 2012 14:12:06 +0100
From: Keir Fraser <keir@xen.org>
To: Jan Beulich <JBeulich@suse.com>,
	xen-devel <xen-devel@lists.xen.org>
Message-ID: <CC74F736.4B6F7%keir@xen.org>
Thread-Topic: [Xen-devel] [PATCH] PCI: don't allow guest assignment of devices
	used by Xen
Thread-Index: Ac2QHwqc7Wd3EgombUi4EGijej81Vw==
In-Reply-To: <504F3DB3020000780009A8CB@nat28.tlf.novell.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] [PATCH] PCI: don't allow guest assignment of
 devices used by Xen
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/09/2012 12:33, "Jan Beulich" <JBeulich@suse.com> wrote:

> This covers the devices used for the console and the AMD IOMMU ones (as
> would be any others that might get passed to pci_ro_device()).
> 
> Boot video device determination cloned from similar Linux logic.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Acked-by: Keir Fraser <keir@xen.org>

> ---
> Note that to apply cleanly, this has to go on top of the serial console
> improvement series posted earlier.
> 
> --- a/xen/arch/x86/mm.c
> +++ b/xen/arch/x86/mm.c
> @@ -311,9 +311,12 @@ void __init arch_init_memory(void)
>       * Initialise our DOMID_XEN domain.
>       * Any Xen-heap pages that we will allow to be mapped will have
>       * their domain field set to dom_xen.
> +     * Hidden PCI devices will also be associated with this domain
> +     * (but be [partly] controlled by Dom0 nevertheless).
>       */
>      dom_xen = domain_create(DOMID_XEN, DOMCRF_dummy, 0);
>      BUG_ON(IS_ERR(dom_xen));
> +    INIT_LIST_HEAD(&dom_xen->arch.pdev_list);
>  
>      /*
>       * Initialise our DOMID_IO domain.
> --- a/xen/drivers/char/ehci-dbgp.c
> +++ b/xen/drivers/char/ehci-dbgp.c
> @@ -1364,6 +1364,8 @@ static void __init ehci_dbgp_init_postir
>      init_timer(&dbgp->timer, ehci_dbgp_poll, port, 0);
>  
>      ehci_dbgp_setup_postirq(dbgp);
> +
> +    pci_hide_device(dbgp->bus, PCI_DEVFN(dbgp->slot, dbgp->func));
>  }
>  
>  static int ehci_dbgp_check_release(struct ehci_dbgp *dbgp)
> --- a/xen/drivers/char/ns16550.c
> +++ b/xen/drivers/char/ns16550.c
> @@ -334,6 +334,10 @@ static void __init ns16550_init_postirq(
>      }
>  
>      ns16550_setup_postirq(uart);
> +
> +    if ( uart->bar || uart->ps_bdf_enable )
> +        pci_hide_device(uart->ps_bdf[0], PCI_DEVFN(uart->ps_bdf[1],
> +                                                   uart->ps_bdf[2]));
>  }
>  
>  static void ns16550_suspend(struct serial_port *port)
> --- a/xen/drivers/passthrough/iommu.c
> +++ b/xen/drivers/passthrough/iommu.c
> @@ -208,7 +208,7 @@ static int device_assigned(u16 seg, u8 b
>      pdev = pci_get_pdev_by_domain(dom0, seg, bus, devfn);
>      spin_unlock(&pcidevs_lock);
>  
> -    return pdev ? 0 : -1;
> +    return pdev ? 0 : -EBUSY;
>  }
>  
>  static int assign_device(struct domain *d, u16 seg, u8 bus, u8 devfn)
> @@ -614,7 +614,8 @@ int iommu_do_domctl(
>          bus = (domctl->u.assign_device.machine_sbdf >> 8) & 0xff;
>          devfn = domctl->u.assign_device.machine_sbdf & 0xff;
>  
> -        ret = assign_device(d, seg, bus, devfn);
> +        ret = device_assigned(seg, bus, devfn) ?:
> +              assign_device(d, seg, bus, devfn);
>          if ( ret )
>              printk(XENLOG_G_ERR "XEN_DOMCTL_assign_device: "
>                     "assign %04x:%02x:%02x.%u to dom%d failed (%d)\n",
> --- a/xen/drivers/passthrough/pci.c
> +++ b/xen/drivers/passthrough/pci.c
> @@ -208,6 +208,31 @@ static void free_pdev(struct pci_seg *ps
>      xfree(pdev);
>  }
>  
> +static void _pci_hide_device(struct pci_dev *pdev)
> +{
> +    if ( pdev->domain )
> +        return;
> +    pdev->domain = dom_xen;
> +    list_add(&pdev->domain_list, &dom_xen->arch.pdev_list);
> +}
> +
> +int __init pci_hide_device(int bus, int devfn)
> +{
> +    struct pci_dev *pdev;
> +    int rc = -ENOMEM;
> +
> +    spin_lock(&pcidevs_lock);
> +    pdev = alloc_pdev(get_pseg(0), bus, devfn);
> +    if ( pdev )
> +    {
> +        _pci_hide_device(pdev);
> +        rc = 0;
> +    }
> +    spin_unlock(&pcidevs_lock);
> +
> +    return rc;
> +}
> +
>  int __init pci_ro_device(int seg, int bus, int devfn)
>  {
>      struct pci_seg *pseg = alloc_pseg(seg);
> @@ -231,6 +256,7 @@ int __init pci_ro_device(int seg, int bu
>  
>      __set_bit(PCI_BDF2(bus, devfn), pseg->ro_map);
>      arch_pci_ro_device(seg, PCI_BDF2(bus, devfn));
> +    _pci_hide_device(pdev);
>  
>      return 0;
>  }
> @@ -718,9 +744,22 @@ static int __init _setup_dom0_pci_device
>              if ( !pdev )
>                  continue;
>  
> -            pdev->domain = ctxt->d;
> -            list_add(&pdev->domain_list, &ctxt->d->arch.pdev_list);
> -            ctxt->handler(pdev);
> +            if ( !pdev->domain )
> +            {
> +                pdev->domain = ctxt->d;
> +                list_add(&pdev->domain_list, &ctxt->d->arch.pdev_list);
> +                ctxt->handler(pdev);
> +            }
> +            else if ( pdev->domain == dom_xen )
> +            {
> +                pdev->domain = ctxt->d;
> +                ctxt->handler(pdev);
> +                pdev->domain = dom_xen;
> +            }
> +            else if ( pdev->domain != ctxt->d )
> +                printk(XENLOG_WARNING "Dom%d owning %04x:%02x:%02x.%u?\n",
> +                       pdev->domain->domain_id, pseg->nr, bus,
> +                       PCI_SLOT(devfn), PCI_FUNC(devfn));
>          }
>      }
>  
> --- a/xen/drivers/video/vga.c
> +++ b/xen/drivers/video/vga.c
> @@ -9,6 +9,7 @@
>  #include <xen/lib.h>
>  #include <xen/mm.h>
>  #include <xen/vga.h>
> +#include <xen/pci.h>
>  #include <asm/io.h>
>  
>  /* Filled in by arch boot code. */
> @@ -106,6 +107,61 @@ void __init vga_endboot(void)
>  
>      if ( !vgacon_keep )
>          vga_puts = vga_noop_puts;
> +    else
> +    {
> +        int bus, devfn;
> +
> +        for ( bus = 0; bus < 256; ++bus )
> +            for ( devfn = 0; devfn < 256; ++devfn )
> +            {
> +                const struct pci_dev *pdev;
> +                u8 b = bus, df = devfn, sb;
> +
> +                spin_lock(&pcidevs_lock);
> +                pdev = pci_get_pdev(0, bus, devfn);
> +                spin_unlock(&pcidevs_lock);
> +
> +                if ( !pdev ||
> +                     pci_conf_read16(0, bus, PCI_SLOT(devfn),
> PCI_FUNC(devfn),
> +                                     PCI_CLASS_DEVICE) != 0x0300 ||
> +                     !(pci_conf_read16(0, bus, PCI_SLOT(devfn),
> +                                       PCI_FUNC(devfn), PCI_COMMAND) &
> +                       (PCI_COMMAND_IO | PCI_COMMAND_MEMORY)) )
> +                    continue;
> +
> +                while ( b )
> +                {
> +                    switch ( find_upstream_bridge(0, &b, &df, &sb) )
> +                    {
> +                    case 0:
> +                        b = 0;
> +                        break;
> +                    case 1:
> +                        switch ( pci_conf_read8(0, b, PCI_SLOT(df),
> +                                                PCI_FUNC(df),
> +                                                PCI_HEADER_TYPE) )
> +                        {
> +                        case PCI_HEADER_TYPE_BRIDGE:
> +                        case PCI_HEADER_TYPE_CARDBUS:
> +                            if ( pci_conf_read16(0, b, PCI_SLOT(df),
> +                                                 PCI_FUNC(df),
> +                                                 PCI_BRIDGE_CONTROL) &
> +                                 PCI_BRIDGE_CTL_VGA )
> +                                continue;
> +                            break;
> +                        }
> +                        break;
> +                    }
> +                    break;
> +                }
> +                if ( !b )
> +                {
> +                    printk(XENLOG_INFO "Boot video device %02x:%02x.%u\n",
> +                           bus, PCI_SLOT(devfn), PCI_FUNC(devfn));
> +                    pci_hide_device(bus, devfn);
> +                }
> +            }
> +    }
>  
>      switch ( vga_console_info.video_type )
>      {
> --- a/xen/include/xen/pci.h
> +++ b/xen/include/xen/pci.h
> @@ -103,6 +103,7 @@ int pci_add_device(u16 seg, u8 bus, u8 d
>  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);
> +int pci_hide_device(int bus, int devfn);
>  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 Tue Sep 11 13:12:50 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 2012 13:12:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TBQGc-0001zn-80; Tue, 11 Sep 2012 13:12:38 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1TBQGa-0001yo-Bu
	for xen-devel@lists.xen.org; Tue, 11 Sep 2012 13:12:36 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1347369110!3556792!3
X-Originating-IP: [74.125.83.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21858 invoked from network); 11 Sep 2012 13:12:15 -0000
Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com)
	(74.125.83.45)
	by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Sep 2012 13:12:15 -0000
Received: by mail-ee0-f45.google.com with SMTP id e53so429253eek.32
	for <xen-devel@lists.xen.org>; Tue, 11 Sep 2012 06:12:15 -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=NAPEYIjlEh0wkwotkNEUDI7898dbcOLKQpJddHeS7lM=;
	b=V7rcHMHrr3AQ9YoOZpofbqZiApkUQ9UBCvdccZYDyXM8mhOqK3gBdzNX4mA6+EWoms
	M+pdk+IeBjJsN66SlO4HatRnB8dXeoe/P9Cbpd/4kGQFNEZylnK2myeRMql+ssWRaQJq
	a0cvRmGjeROdRO1vjFmBfY/RD25sd/2jzEUazWdL2wBeNLef938mwFnFaDL06K7hRzeg
	9LmdFWktPEvqwqhiWIhwfLz+V4tYdsP+1XAZpHnHeWnfJQi4MujGXYD6hXuhqKEQNCXS
	ndQ0Zk5pUCciNL/e6XgnNxWke6P5s4xj5R4Y/SfBOrB9taPUYVlcU+A81AW2u3za5jS2
	tGgw==
Received: by 10.14.207.9 with SMTP id m9mr25455819eeo.5.1347369135754;
	Tue, 11 Sep 2012 06:12:15 -0700 (PDT)
Received: from [192.168.1.3] (host86-184-74-117.range86-184.btcentralplus.com.
	[86.184.74.117])
	by mx.google.com with ESMTPS id i41sm47014469eem.7.2012.09.11.06.12.10
	(version=SSLv3 cipher=OTHER); Tue, 11 Sep 2012 06:12:14 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.33.0.120411
Date: Tue, 11 Sep 2012 14:12:06 +0100
From: Keir Fraser <keir@xen.org>
To: Jan Beulich <JBeulich@suse.com>,
	xen-devel <xen-devel@lists.xen.org>
Message-ID: <CC74F736.4B6F7%keir@xen.org>
Thread-Topic: [Xen-devel] [PATCH] PCI: don't allow guest assignment of devices
	used by Xen
Thread-Index: Ac2QHwqc7Wd3EgombUi4EGijej81Vw==
In-Reply-To: <504F3DB3020000780009A8CB@nat28.tlf.novell.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] [PATCH] PCI: don't allow guest assignment of
 devices used by Xen
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/09/2012 12:33, "Jan Beulich" <JBeulich@suse.com> wrote:

> This covers the devices used for the console and the AMD IOMMU ones (as
> would be any others that might get passed to pci_ro_device()).
> 
> Boot video device determination cloned from similar Linux logic.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Acked-by: Keir Fraser <keir@xen.org>

> ---
> Note that to apply cleanly, this has to go on top of the serial console
> improvement series posted earlier.
> 
> --- a/xen/arch/x86/mm.c
> +++ b/xen/arch/x86/mm.c
> @@ -311,9 +311,12 @@ void __init arch_init_memory(void)
>       * Initialise our DOMID_XEN domain.
>       * Any Xen-heap pages that we will allow to be mapped will have
>       * their domain field set to dom_xen.
> +     * Hidden PCI devices will also be associated with this domain
> +     * (but be [partly] controlled by Dom0 nevertheless).
>       */
>      dom_xen = domain_create(DOMID_XEN, DOMCRF_dummy, 0);
>      BUG_ON(IS_ERR(dom_xen));
> +    INIT_LIST_HEAD(&dom_xen->arch.pdev_list);
>  
>      /*
>       * Initialise our DOMID_IO domain.
> --- a/xen/drivers/char/ehci-dbgp.c
> +++ b/xen/drivers/char/ehci-dbgp.c
> @@ -1364,6 +1364,8 @@ static void __init ehci_dbgp_init_postir
>      init_timer(&dbgp->timer, ehci_dbgp_poll, port, 0);
>  
>      ehci_dbgp_setup_postirq(dbgp);
> +
> +    pci_hide_device(dbgp->bus, PCI_DEVFN(dbgp->slot, dbgp->func));
>  }
>  
>  static int ehci_dbgp_check_release(struct ehci_dbgp *dbgp)
> --- a/xen/drivers/char/ns16550.c
> +++ b/xen/drivers/char/ns16550.c
> @@ -334,6 +334,10 @@ static void __init ns16550_init_postirq(
>      }
>  
>      ns16550_setup_postirq(uart);
> +
> +    if ( uart->bar || uart->ps_bdf_enable )
> +        pci_hide_device(uart->ps_bdf[0], PCI_DEVFN(uart->ps_bdf[1],
> +                                                   uart->ps_bdf[2]));
>  }
>  
>  static void ns16550_suspend(struct serial_port *port)
> --- a/xen/drivers/passthrough/iommu.c
> +++ b/xen/drivers/passthrough/iommu.c
> @@ -208,7 +208,7 @@ static int device_assigned(u16 seg, u8 b
>      pdev = pci_get_pdev_by_domain(dom0, seg, bus, devfn);
>      spin_unlock(&pcidevs_lock);
>  
> -    return pdev ? 0 : -1;
> +    return pdev ? 0 : -EBUSY;
>  }
>  
>  static int assign_device(struct domain *d, u16 seg, u8 bus, u8 devfn)
> @@ -614,7 +614,8 @@ int iommu_do_domctl(
>          bus = (domctl->u.assign_device.machine_sbdf >> 8) & 0xff;
>          devfn = domctl->u.assign_device.machine_sbdf & 0xff;
>  
> -        ret = assign_device(d, seg, bus, devfn);
> +        ret = device_assigned(seg, bus, devfn) ?:
> +              assign_device(d, seg, bus, devfn);
>          if ( ret )
>              printk(XENLOG_G_ERR "XEN_DOMCTL_assign_device: "
>                     "assign %04x:%02x:%02x.%u to dom%d failed (%d)\n",
> --- a/xen/drivers/passthrough/pci.c
> +++ b/xen/drivers/passthrough/pci.c
> @@ -208,6 +208,31 @@ static void free_pdev(struct pci_seg *ps
>      xfree(pdev);
>  }
>  
> +static void _pci_hide_device(struct pci_dev *pdev)
> +{
> +    if ( pdev->domain )
> +        return;
> +    pdev->domain = dom_xen;
> +    list_add(&pdev->domain_list, &dom_xen->arch.pdev_list);
> +}
> +
> +int __init pci_hide_device(int bus, int devfn)
> +{
> +    struct pci_dev *pdev;
> +    int rc = -ENOMEM;
> +
> +    spin_lock(&pcidevs_lock);
> +    pdev = alloc_pdev(get_pseg(0), bus, devfn);
> +    if ( pdev )
> +    {
> +        _pci_hide_device(pdev);
> +        rc = 0;
> +    }
> +    spin_unlock(&pcidevs_lock);
> +
> +    return rc;
> +}
> +
>  int __init pci_ro_device(int seg, int bus, int devfn)
>  {
>      struct pci_seg *pseg = alloc_pseg(seg);
> @@ -231,6 +256,7 @@ int __init pci_ro_device(int seg, int bu
>  
>      __set_bit(PCI_BDF2(bus, devfn), pseg->ro_map);
>      arch_pci_ro_device(seg, PCI_BDF2(bus, devfn));
> +    _pci_hide_device(pdev);
>  
>      return 0;
>  }
> @@ -718,9 +744,22 @@ static int __init _setup_dom0_pci_device
>              if ( !pdev )
>                  continue;
>  
> -            pdev->domain = ctxt->d;
> -            list_add(&pdev->domain_list, &ctxt->d->arch.pdev_list);
> -            ctxt->handler(pdev);
> +            if ( !pdev->domain )
> +            {
> +                pdev->domain = ctxt->d;
> +                list_add(&pdev->domain_list, &ctxt->d->arch.pdev_list);
> +                ctxt->handler(pdev);
> +            }
> +            else if ( pdev->domain == dom_xen )
> +            {
> +                pdev->domain = ctxt->d;
> +                ctxt->handler(pdev);
> +                pdev->domain = dom_xen;
> +            }
> +            else if ( pdev->domain != ctxt->d )
> +                printk(XENLOG_WARNING "Dom%d owning %04x:%02x:%02x.%u?\n",
> +                       pdev->domain->domain_id, pseg->nr, bus,
> +                       PCI_SLOT(devfn), PCI_FUNC(devfn));
>          }
>      }
>  
> --- a/xen/drivers/video/vga.c
> +++ b/xen/drivers/video/vga.c
> @@ -9,6 +9,7 @@
>  #include <xen/lib.h>
>  #include <xen/mm.h>
>  #include <xen/vga.h>
> +#include <xen/pci.h>
>  #include <asm/io.h>
>  
>  /* Filled in by arch boot code. */
> @@ -106,6 +107,61 @@ void __init vga_endboot(void)
>  
>      if ( !vgacon_keep )
>          vga_puts = vga_noop_puts;
> +    else
> +    {
> +        int bus, devfn;
> +
> +        for ( bus = 0; bus < 256; ++bus )
> +            for ( devfn = 0; devfn < 256; ++devfn )
> +            {
> +                const struct pci_dev *pdev;
> +                u8 b = bus, df = devfn, sb;
> +
> +                spin_lock(&pcidevs_lock);
> +                pdev = pci_get_pdev(0, bus, devfn);
> +                spin_unlock(&pcidevs_lock);
> +
> +                if ( !pdev ||
> +                     pci_conf_read16(0, bus, PCI_SLOT(devfn),
> PCI_FUNC(devfn),
> +                                     PCI_CLASS_DEVICE) != 0x0300 ||
> +                     !(pci_conf_read16(0, bus, PCI_SLOT(devfn),
> +                                       PCI_FUNC(devfn), PCI_COMMAND) &
> +                       (PCI_COMMAND_IO | PCI_COMMAND_MEMORY)) )
> +                    continue;
> +
> +                while ( b )
> +                {
> +                    switch ( find_upstream_bridge(0, &b, &df, &sb) )
> +                    {
> +                    case 0:
> +                        b = 0;
> +                        break;
> +                    case 1:
> +                        switch ( pci_conf_read8(0, b, PCI_SLOT(df),
> +                                                PCI_FUNC(df),
> +                                                PCI_HEADER_TYPE) )
> +                        {
> +                        case PCI_HEADER_TYPE_BRIDGE:
> +                        case PCI_HEADER_TYPE_CARDBUS:
> +                            if ( pci_conf_read16(0, b, PCI_SLOT(df),
> +                                                 PCI_FUNC(df),
> +                                                 PCI_BRIDGE_CONTROL) &
> +                                 PCI_BRIDGE_CTL_VGA )
> +                                continue;
> +                            break;
> +                        }
> +                        break;
> +                    }
> +                    break;
> +                }
> +                if ( !b )
> +                {
> +                    printk(XENLOG_INFO "Boot video device %02x:%02x.%u\n",
> +                           bus, PCI_SLOT(devfn), PCI_FUNC(devfn));
> +                    pci_hide_device(bus, devfn);
> +                }
> +            }
> +    }
>  
>      switch ( vga_console_info.video_type )
>      {
> --- a/xen/include/xen/pci.h
> +++ b/xen/include/xen/pci.h
> @@ -103,6 +103,7 @@ int pci_add_device(u16 seg, u8 bus, u8 d
>  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);
> +int pci_hide_device(int bus, int devfn);
>  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 Tue Sep 11 13:13:18 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 2012 13: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 1TBQH5-00027P-TC; Tue, 11 Sep 2012 13:13:07 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1TBQH4-000263-95
	for xen-devel@lists.xen.org; Tue, 11 Sep 2012 13:13:06 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1347369110!3556792!4
X-Originating-IP: [74.125.83.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22793 invoked from network); 11 Sep 2012 13:12:28 -0000
Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com)
	(74.125.83.45)
	by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Sep 2012 13:12:28 -0000
Received: by mail-ee0-f45.google.com with SMTP id e53so429253eek.32
	for <xen-devel@lists.xen.org>; Tue, 11 Sep 2012 06:12:28 -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=3rkMu15rRdWfGgTKD9pWO3JHg8/b3QJeRZF5Xcu+TpU=;
	b=PXbweQaRzayLbF//TIGYPvctHL+V+X+R2Xtbx30o2r+UoJNRKFAfk/uy3W215M2U2E
	4AHnZD/+HahDLr9R86SjEA7z2eRjPkbO0WGX8vwp4ueSOKFw6dvUBJXWzP01z6ksg6Wj
	ja+gc1KjYvT35cQKPVnzS4OHeVFUSFnPxkH6CGg0omYaGQK5VtFEsRGricaOtqY8NNK3
	HQ+48r6HmmOzntR0qYF0NtTGh4ZuPJn10xSA1VU9Jw/leTIwhXjvy8vFofH8RM2KCLPB
	BfgqOfQNwBzFOUaFYirqOIrz3vr2cf+fIcthk1oVTb+wNvWNWB7UVb1vaRjA0/kTpTPQ
	SR8g==
Received: by 10.14.224.73 with SMTP id w49mr25663180eep.37.1347369147799;
	Tue, 11 Sep 2012 06:12:27 -0700 (PDT)
Received: from [192.168.1.3] (host86-184-74-117.range86-184.btcentralplus.com.
	[86.184.74.117])
	by mx.google.com with ESMTPS id h2sm47034228eeo.3.2012.09.11.06.12.24
	(version=SSLv3 cipher=OTHER); Tue, 11 Sep 2012 06:12:26 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.33.0.120411
Date: Tue, 11 Sep 2012 14:12:21 +0100
From: Keir Fraser <keir@xen.org>
To: Jan Beulich <JBeulich@suse.com>,
	xen-devel <xen-devel@lists.xen.org>
Message-ID: <CC74F745.4B703%keir@xen.org>
Thread-Topic: [Xen-devel] [PATCH 0/2] x86: construct initial page tables
	mostly statically
Thread-Index: Ac2QHxOMWKUJXf1h90CLw4DxHYzy2g==
In-Reply-To: <504F3E3D020000780009A8D7@nat28.tlf.novell.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] [PATCH 0/2] x86: construct initial page tables
 mostly statically
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/09/2012 12:35, "Jan Beulich" <JBeulich@suse.com> wrote:

> 1: x86: construct static parts of 1:1 mapping at build time
> 2: x86-64: construct static, uniform parts of page tables at build time
> 
> Note that to apply cleanly, this has to go on top of the serial console
> improvement series posted earlier.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Acked-by: Keir Fraser <keir@xen.org>

> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 11 13:13:18 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 2012 13: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 1TBQH5-00027P-TC; Tue, 11 Sep 2012 13:13:07 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1TBQH4-000263-95
	for xen-devel@lists.xen.org; Tue, 11 Sep 2012 13:13:06 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1347369110!3556792!4
X-Originating-IP: [74.125.83.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22793 invoked from network); 11 Sep 2012 13:12:28 -0000
Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com)
	(74.125.83.45)
	by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Sep 2012 13:12:28 -0000
Received: by mail-ee0-f45.google.com with SMTP id e53so429253eek.32
	for <xen-devel@lists.xen.org>; Tue, 11 Sep 2012 06:12:28 -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=3rkMu15rRdWfGgTKD9pWO3JHg8/b3QJeRZF5Xcu+TpU=;
	b=PXbweQaRzayLbF//TIGYPvctHL+V+X+R2Xtbx30o2r+UoJNRKFAfk/uy3W215M2U2E
	4AHnZD/+HahDLr9R86SjEA7z2eRjPkbO0WGX8vwp4ueSOKFw6dvUBJXWzP01z6ksg6Wj
	ja+gc1KjYvT35cQKPVnzS4OHeVFUSFnPxkH6CGg0omYaGQK5VtFEsRGricaOtqY8NNK3
	HQ+48r6HmmOzntR0qYF0NtTGh4ZuPJn10xSA1VU9Jw/leTIwhXjvy8vFofH8RM2KCLPB
	BfgqOfQNwBzFOUaFYirqOIrz3vr2cf+fIcthk1oVTb+wNvWNWB7UVb1vaRjA0/kTpTPQ
	SR8g==
Received: by 10.14.224.73 with SMTP id w49mr25663180eep.37.1347369147799;
	Tue, 11 Sep 2012 06:12:27 -0700 (PDT)
Received: from [192.168.1.3] (host86-184-74-117.range86-184.btcentralplus.com.
	[86.184.74.117])
	by mx.google.com with ESMTPS id h2sm47034228eeo.3.2012.09.11.06.12.24
	(version=SSLv3 cipher=OTHER); Tue, 11 Sep 2012 06:12:26 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.33.0.120411
Date: Tue, 11 Sep 2012 14:12:21 +0100
From: Keir Fraser <keir@xen.org>
To: Jan Beulich <JBeulich@suse.com>,
	xen-devel <xen-devel@lists.xen.org>
Message-ID: <CC74F745.4B703%keir@xen.org>
Thread-Topic: [Xen-devel] [PATCH 0/2] x86: construct initial page tables
	mostly statically
Thread-Index: Ac2QHxOMWKUJXf1h90CLw4DxHYzy2g==
In-Reply-To: <504F3E3D020000780009A8D7@nat28.tlf.novell.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] [PATCH 0/2] x86: construct initial page tables
 mostly statically
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/09/2012 12:35, "Jan Beulich" <JBeulich@suse.com> wrote:

> 1: x86: construct static parts of 1:1 mapping at build time
> 2: x86-64: construct static, uniform parts of page tables at build time
> 
> Note that to apply cleanly, this has to go on top of the serial console
> improvement series posted earlier.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Acked-by: Keir Fraser <keir@xen.org>

> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 11 13:17:59 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 2012 13:17:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TBQLY-0002bE-KO; Tue, 11 Sep 2012 13:17:44 +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 1TBQLX-0002b4-E2
	for xen-devel@lists.xen.org; Tue, 11 Sep 2012 13:17:43 +0000
Received: from [85.158.138.51:48435] by server-7.bemta-3.messagelabs.com id
	B1/D7-32000-6F93F405; Tue, 11 Sep 2012 13:17:42 +0000
X-Env-Sender: fantonifabio@tiscali.it
X-Msg-Ref: server-4.tower-174.messagelabs.com!1347369461!29420709!1
X-Originating-IP: [94.23.245.208]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9716 invoked from network); 11 Sep 2012 13:17:41 -0000
Received: from lnx3.fantu.it (HELO lnx3.fantu.it) (94.23.245.208)
	by server-4.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 11 Sep 2012 13:17:41 -0000
Received: from localhost (localhost.localdomain [127.0.0.1])
	by lnx3.fantu.it (Postfix) with ESMTP id 7342D402656;
	Tue, 11 Sep 2012 15:17:41 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at lnx3.fantu.it
Received: from lnx3.fantu.it ([127.0.0.1])
	by localhost (lnx3.fantu.it [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id Kxk6spDldroK; Tue, 11 Sep 2012 15:17:41 +0200 (CEST)
Received: from [192.168.178.50]
	(host159-164-dynamic.56-82-r.retail.telecomitalia.it [82.56.164.159])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: prova@fantu.it)
	by lnx3.fantu.it (Postfix) with ESMTPSA id 8DFA5401995;
	Tue, 11 Sep 2012 15:17:40 +0200 (CEST)
Message-ID: <504F39F0.10701@tiscali.it>
Date: Tue, 11 Sep 2012 15:17:36 +0200
From: Fabio Fantoni <fantonifabio@tiscali.it>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:14.0) Gecko/20120713 Thunderbird/14.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <504F3355.2070201@tiscali.it>
	<504F5182020000780009A9CC@nat28.tlf.novell.com>
In-Reply-To: <504F5182020000780009A9CC@nat28.tlf.novell.com>
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Start xen on UEFI system with grub
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="===============0770639874514300649=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Questo è un messaggio firmato digitalmente in formato MIME.

--===============0770639874514300649==
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms050304020403070009010700"

Questo è un messaggio firmato digitalmente in formato MIME.

--------------ms050304020403070009010700
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable

Il 11/09/2012 14:58, Jan Beulich ha scritto:
>>>> On 11.09.12 at 14:49, Fabio Fantoni <fantonifabio@tiscali.it> wrote:=

>> I have Wheezy 64 bit dom0 with kernel 3.2 from repository and xen 4.2
>> from source.
>> I want use UEFI without xen.efi
> Why?
>
>> which fails on compiling xen.
> How? All you would need is xen.gz for that purpose (but of course
> that won't have any EFI specific bits in it).
>
>> Should I use "ucode" or something similar?
> That's completely unrelated.
>
>> Is possible? If is possible what I must do?
> Without you telling us precisely what doesn't work, we can hardly
> answer that.
>
> Jan
>
>
>
> -----
> Nessun virus nel messaggio.
> Controllato da AVG - www.avg.com
> Versione: 2012.0.2221 / Database dei virus: 2437/5261 -  Data di rilasc=
io: 10/09/2012
>
>
>
We need do "multilevel" boot on Dell poweredge server working in all=20
cases, booting lvm volume and fallback.
With bios is impossible, bugs cause problem in some case.
With efi I not see bugs on boot cases but efibootmgr is not working with =

grub2 and xen.gz and we can't specify lvm for "static" boot order also=20
with different disks.
xen.efi not compile when we build xen on Wheezy and probably is not=20
possible boot with lvm volume, fallback options ecc...
UEFI with grub2 seem the best option but with xen hypervisor seem not=20
load efi variable.
Thanks for any help and sorry for bad english


--------------ms050304020403070009010700
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: Firma crittografica S/MIME

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINhjCC
BjQwggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT
DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp
Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3
MTAyNDIxMDI1NVoXDTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T
dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu
aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs
aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOM
KqANy9BV7V0igWdGxA8IU77L3aTxErQ+fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi
8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke/s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8M
DP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHksw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y
2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHHtOkzUreG//CsFnB9+uaYSlR65cdG
zTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB
Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd+q9rMfPIHeOsuzAfBgNV
HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH
MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3
dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu
c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v
c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0
dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93
d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqp
Jw3I07QWke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Mic
c/NXcs7kPBRdn6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9Jphw
UPTXwHovjavRnhUQHLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMc
p+reg9901zkyT3fDW/ivJVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT
+HBDYtbuvexNftwNQKD5193A7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1X
hwby6mLhkbaXslkVtwEWT3Van49rKjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvO
hNz/QplNa+VkIsrcp7+8ZhP1l1b2U6MaxIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC
0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqh
AChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H75dVCV33K6FuxZrf09yTz+Vx/PkdRUYk
XmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHSjCCBjKgAwIBAgICHmMwDQYJKoZIhvcNAQEF
BQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJT
ZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD
bGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0xMjAzMTgyMjE0MzBa
Fw0xNDAzMjAwODU3MDlaMIGMMRkwFwYDVQQNExBlQjZPRTM3UlJOUHlsNW0yMQswCQYDVQQG
EwJJVDEQMA4GA1UECBMHQmVyZ2FtbzEQMA4GA1UEBxMHUm92ZXR0YTEWMBQGA1UEAxMNRmFi
aW8gRmFudG9uaTEmMCQGCSqGSIb3DQEJARYXZmFudG9uaWZhYmlvQHRpc2NhbGkuaXQwggEi
MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC1XhckXsX23vgJq76s2f0KT8U8Msov5QgV
10eQBb2wL/TzcmqtZotI7ztKVhio3ehHg+mfu+3EqOkX9Umgut8rP0bPi7AGjkPXbOTT/cSU
Xz2Kw31VGOmiOVoUFGvpQitp3weCkhUJLBipI8EpNyBXpjtQ9yCpnIAqfuc77ybfSnCy7tTR
MBq1BUkfjH1+GL45riosuS4+F+MSUvlYzLiT4rAduAX1Y2IuORDsf9Bce8GBxa6syP9rCyzl
Vk7DIX5k8j2vlnyRATIypn5CQLQxGT6e0f6ac4gvWOHwO2QEBsmZKKs1ZidE4q/9OoNXYX6A
jnHtp1H1vcrek/vVcs19AgMBAAGjggOyMIIDrjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAd
BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFFan8cbEWWBmSTWFtLk2
YNdAcGUbMB8GA1UdIwQYMBaAFK5Vg2/sMcq59x36r2sx88gd46y7MCIGA1UdEQQbMBmBF2Zh
bnRvbmlmYWJpb0B0aXNjYWxpLml0MIICIQYDVR0gBIICGDCCAhQwggIQBgsrBgEEAYG1NwEC
AjCCAf8wLgYIKwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYw
NAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYw
gfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMC
AQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNjb3JkaW5nIHRvIHRoZSBDbGFz
cyAyIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3ks
IHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGluIGNvbXBsaWFuY2Ug
b2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMIGcBggrBgEFBQcCAjCBjzAnFiBT
dGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgECGmRMaWFiaWxpdHkgYW5kIHdh
cnJhbnRpZXMgYXJlIGxpbWl0ZWQhIFNlZSBzZWN0aW9uICJMZWdhbCBhbmQgTGltaXRhdGlv
bnMiIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3kuMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6
Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUyLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYI
KwYBBQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MyL2NsaWVudC9j
YTBCBggrBgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNz
Mi5jbGllbnQuY2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzAN
BgkqhkiG9w0BAQUFAAOCAQEAjzHNqifpDVMkH1TSPFZVIiQ4fh49/V5JMpstgqEZPDaDe5r8
h+fMBZtUa6LLMco03Z9BNEXlqlXKiFk8feVYB8obEjz7YYq1XhO9q7JUmkSs0WGIH4xU0XB1
kPC8T8H+5E//84poYSFHE4pA+Ff68UANP2/EuFJWMjegiefnOr8aM42OAcUkjEWSlautIIX8
oD2GizwQYjWdDDjEonbuMKFP6rY2xGI3PSLI3IVU2opb0/itNhQui3WRxafloJqTlriY8m8+
qSLr2HGftbBlbyzVWB8o//aW0H0LMabjkIvrm7Zmh2vcCxiSxGBwYASuSYXGuQiKAgGptUs1
XJLZuzGCA9owggPWAgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20g
THRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG
A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EC
Ah5jMAkGBSsOAwIaBQCgggIbMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcN
AQkFMQ8XDTEyMDkxMTEzMTczNlowIwYJKoZIhvcNAQkEMRYEFCypihtwCSCMLgwibjYyLHe1
/YOdMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggqhkiG
9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcN
AwICASgwgaQGCSsGAQQBgjcQBDGBljCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0
YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25p
bmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp
ZW50IENBAgIeYzCBpgYLKoZIhvcNAQkQAgsxgZaggZMwgYwxCzAJBgNVBAYTAklMMRYwFAYD
VQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0
ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRp
YXRlIENsaWVudCBDQQICHmMwDQYJKoZIhvcNAQEBBQAEggEAJGbD5YUZIuG7oJqCmSTo1YoI
3d63TwThzMh9wR0G4twJJZ9FLasej7RNlfJCfGmQWQc9OAJzXWwNgFZ9bA8i7YjTZ+Xg/Y7/
5Eas0u+7LIXCgIjY1v4kuyam83HSdEo4rgia6mqMdYWXioLJGJfpAG+A9BTyglSKdwtZJ6jq
TvzB4ngkGVEOJfaJZ6bJJ6ub5fJLVfTG/2TK7fVZrt+d+fTD3W4zqsUfDceIwvu5UzZpSS/w
M9sbyI3PNveRlot5pq9nHEmkQRNk8xPk/OoFtATiLbTZtCqf3JqOXXAU+JyXs2i8QnZTKSNQ
HHN2sGRcwFo6MXrF4cka/+qi/167oQAAAAAAAA==
--------------ms050304020403070009010700--


--===============0770639874514300649==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============0770639874514300649==--


From xen-devel-bounces@lists.xen.org Tue Sep 11 13:17:59 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 2012 13:17:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TBQLY-0002bE-KO; Tue, 11 Sep 2012 13:17:44 +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 1TBQLX-0002b4-E2
	for xen-devel@lists.xen.org; Tue, 11 Sep 2012 13:17:43 +0000
Received: from [85.158.138.51:48435] by server-7.bemta-3.messagelabs.com id
	B1/D7-32000-6F93F405; Tue, 11 Sep 2012 13:17:42 +0000
X-Env-Sender: fantonifabio@tiscali.it
X-Msg-Ref: server-4.tower-174.messagelabs.com!1347369461!29420709!1
X-Originating-IP: [94.23.245.208]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9716 invoked from network); 11 Sep 2012 13:17:41 -0000
Received: from lnx3.fantu.it (HELO lnx3.fantu.it) (94.23.245.208)
	by server-4.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 11 Sep 2012 13:17:41 -0000
Received: from localhost (localhost.localdomain [127.0.0.1])
	by lnx3.fantu.it (Postfix) with ESMTP id 7342D402656;
	Tue, 11 Sep 2012 15:17:41 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at lnx3.fantu.it
Received: from lnx3.fantu.it ([127.0.0.1])
	by localhost (lnx3.fantu.it [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id Kxk6spDldroK; Tue, 11 Sep 2012 15:17:41 +0200 (CEST)
Received: from [192.168.178.50]
	(host159-164-dynamic.56-82-r.retail.telecomitalia.it [82.56.164.159])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: prova@fantu.it)
	by lnx3.fantu.it (Postfix) with ESMTPSA id 8DFA5401995;
	Tue, 11 Sep 2012 15:17:40 +0200 (CEST)
Message-ID: <504F39F0.10701@tiscali.it>
Date: Tue, 11 Sep 2012 15:17:36 +0200
From: Fabio Fantoni <fantonifabio@tiscali.it>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:14.0) Gecko/20120713 Thunderbird/14.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <504F3355.2070201@tiscali.it>
	<504F5182020000780009A9CC@nat28.tlf.novell.com>
In-Reply-To: <504F5182020000780009A9CC@nat28.tlf.novell.com>
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Start xen on UEFI system with grub
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="===============0770639874514300649=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Questo è un messaggio firmato digitalmente in formato MIME.

--===============0770639874514300649==
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms050304020403070009010700"

Questo è un messaggio firmato digitalmente in formato MIME.

--------------ms050304020403070009010700
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable

Il 11/09/2012 14:58, Jan Beulich ha scritto:
>>>> On 11.09.12 at 14:49, Fabio Fantoni <fantonifabio@tiscali.it> wrote:=

>> I have Wheezy 64 bit dom0 with kernel 3.2 from repository and xen 4.2
>> from source.
>> I want use UEFI without xen.efi
> Why?
>
>> which fails on compiling xen.
> How? All you would need is xen.gz for that purpose (but of course
> that won't have any EFI specific bits in it).
>
>> Should I use "ucode" or something similar?
> That's completely unrelated.
>
>> Is possible? If is possible what I must do?
> Without you telling us precisely what doesn't work, we can hardly
> answer that.
>
> Jan
>
>
>
> -----
> Nessun virus nel messaggio.
> Controllato da AVG - www.avg.com
> Versione: 2012.0.2221 / Database dei virus: 2437/5261 -  Data di rilasc=
io: 10/09/2012
>
>
>
We need do "multilevel" boot on Dell poweredge server working in all=20
cases, booting lvm volume and fallback.
With bios is impossible, bugs cause problem in some case.
With efi I not see bugs on boot cases but efibootmgr is not working with =

grub2 and xen.gz and we can't specify lvm for "static" boot order also=20
with different disks.
xen.efi not compile when we build xen on Wheezy and probably is not=20
possible boot with lvm volume, fallback options ecc...
UEFI with grub2 seem the best option but with xen hypervisor seem not=20
load efi variable.
Thanks for any help and sorry for bad english


--------------ms050304020403070009010700
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: Firma crittografica S/MIME

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINhjCC
BjQwggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT
DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp
Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3
MTAyNDIxMDI1NVoXDTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T
dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu
aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs
aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOM
KqANy9BV7V0igWdGxA8IU77L3aTxErQ+fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi
8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke/s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8M
DP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHksw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y
2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHHtOkzUreG//CsFnB9+uaYSlR65cdG
zTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB
Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd+q9rMfPIHeOsuzAfBgNV
HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH
MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3
dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu
c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v
c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0
dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93
d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqp
Jw3I07QWke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Mic
c/NXcs7kPBRdn6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9Jphw
UPTXwHovjavRnhUQHLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMc
p+reg9901zkyT3fDW/ivJVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT
+HBDYtbuvexNftwNQKD5193A7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1X
hwby6mLhkbaXslkVtwEWT3Van49rKjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvO
hNz/QplNa+VkIsrcp7+8ZhP1l1b2U6MaxIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC
0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqh
AChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H75dVCV33K6FuxZrf09yTz+Vx/PkdRUYk
XmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHSjCCBjKgAwIBAgICHmMwDQYJKoZIhvcNAQEF
BQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJT
ZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD
bGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0xMjAzMTgyMjE0MzBa
Fw0xNDAzMjAwODU3MDlaMIGMMRkwFwYDVQQNExBlQjZPRTM3UlJOUHlsNW0yMQswCQYDVQQG
EwJJVDEQMA4GA1UECBMHQmVyZ2FtbzEQMA4GA1UEBxMHUm92ZXR0YTEWMBQGA1UEAxMNRmFi
aW8gRmFudG9uaTEmMCQGCSqGSIb3DQEJARYXZmFudG9uaWZhYmlvQHRpc2NhbGkuaXQwggEi
MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC1XhckXsX23vgJq76s2f0KT8U8Msov5QgV
10eQBb2wL/TzcmqtZotI7ztKVhio3ehHg+mfu+3EqOkX9Umgut8rP0bPi7AGjkPXbOTT/cSU
Xz2Kw31VGOmiOVoUFGvpQitp3weCkhUJLBipI8EpNyBXpjtQ9yCpnIAqfuc77ybfSnCy7tTR
MBq1BUkfjH1+GL45riosuS4+F+MSUvlYzLiT4rAduAX1Y2IuORDsf9Bce8GBxa6syP9rCyzl
Vk7DIX5k8j2vlnyRATIypn5CQLQxGT6e0f6ac4gvWOHwO2QEBsmZKKs1ZidE4q/9OoNXYX6A
jnHtp1H1vcrek/vVcs19AgMBAAGjggOyMIIDrjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAd
BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFFan8cbEWWBmSTWFtLk2
YNdAcGUbMB8GA1UdIwQYMBaAFK5Vg2/sMcq59x36r2sx88gd46y7MCIGA1UdEQQbMBmBF2Zh
bnRvbmlmYWJpb0B0aXNjYWxpLml0MIICIQYDVR0gBIICGDCCAhQwggIQBgsrBgEEAYG1NwEC
AjCCAf8wLgYIKwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYw
NAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYw
gfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMC
AQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNjb3JkaW5nIHRvIHRoZSBDbGFz
cyAyIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3ks
IHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGluIGNvbXBsaWFuY2Ug
b2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMIGcBggrBgEFBQcCAjCBjzAnFiBT
dGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgECGmRMaWFiaWxpdHkgYW5kIHdh
cnJhbnRpZXMgYXJlIGxpbWl0ZWQhIFNlZSBzZWN0aW9uICJMZWdhbCBhbmQgTGltaXRhdGlv
bnMiIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3kuMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6
Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUyLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYI
KwYBBQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MyL2NsaWVudC9j
YTBCBggrBgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNz
Mi5jbGllbnQuY2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzAN
BgkqhkiG9w0BAQUFAAOCAQEAjzHNqifpDVMkH1TSPFZVIiQ4fh49/V5JMpstgqEZPDaDe5r8
h+fMBZtUa6LLMco03Z9BNEXlqlXKiFk8feVYB8obEjz7YYq1XhO9q7JUmkSs0WGIH4xU0XB1
kPC8T8H+5E//84poYSFHE4pA+Ff68UANP2/EuFJWMjegiefnOr8aM42OAcUkjEWSlautIIX8
oD2GizwQYjWdDDjEonbuMKFP6rY2xGI3PSLI3IVU2opb0/itNhQui3WRxafloJqTlriY8m8+
qSLr2HGftbBlbyzVWB8o//aW0H0LMabjkIvrm7Zmh2vcCxiSxGBwYASuSYXGuQiKAgGptUs1
XJLZuzGCA9owggPWAgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20g
THRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG
A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EC
Ah5jMAkGBSsOAwIaBQCgggIbMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcN
AQkFMQ8XDTEyMDkxMTEzMTczNlowIwYJKoZIhvcNAQkEMRYEFCypihtwCSCMLgwibjYyLHe1
/YOdMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggqhkiG
9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcN
AwICASgwgaQGCSsGAQQBgjcQBDGBljCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0
YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25p
bmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp
ZW50IENBAgIeYzCBpgYLKoZIhvcNAQkQAgsxgZaggZMwgYwxCzAJBgNVBAYTAklMMRYwFAYD
VQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0
ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRp
YXRlIENsaWVudCBDQQICHmMwDQYJKoZIhvcNAQEBBQAEggEAJGbD5YUZIuG7oJqCmSTo1YoI
3d63TwThzMh9wR0G4twJJZ9FLasej7RNlfJCfGmQWQc9OAJzXWwNgFZ9bA8i7YjTZ+Xg/Y7/
5Eas0u+7LIXCgIjY1v4kuyam83HSdEo4rgia6mqMdYWXioLJGJfpAG+A9BTyglSKdwtZJ6jq
TvzB4ngkGVEOJfaJZ6bJJ6ub5fJLVfTG/2TK7fVZrt+d+fTD3W4zqsUfDceIwvu5UzZpSS/w
M9sbyI3PNveRlot5pq9nHEmkQRNk8xPk/OoFtATiLbTZtCqf3JqOXXAU+JyXs2i8QnZTKSNQ
HHN2sGRcwFo6MXrF4cka/+qi/167oQAAAAAAAA==
--------------ms050304020403070009010700--


--===============0770639874514300649==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============0770639874514300649==--


From xen-devel-bounces@lists.xen.org Tue Sep 11 13:21:30 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 2012 13:21:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TBQP1-0002k5-8t; Tue, 11 Sep 2012 13:21:19 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Christoph.Egger@amd.com>) id 1TBQOz-0002jt-Md
	for xen-devel@lists.xen.org; Tue, 11 Sep 2012 13:21:18 +0000
X-Env-Sender: Christoph.Egger@amd.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1347369661!3558848!1
X-Originating-IP: [213.199.154.205]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28360 invoked from network); 11 Sep 2012 13:21:02 -0000
Received: from am1ehsobe002.messaging.microsoft.com (HELO
	am1outboundpool.messaging.microsoft.com) (213.199.154.205)
	by server-14.tower-27.messagelabs.com with AES128-SHA encrypted SMTP;
	11 Sep 2012 13:21:02 -0000
Received: from mail51-am1-R.bigfish.com (10.3.201.230) by
	AM1EHSOBE003.bigfish.com (10.3.204.23) with Microsoft SMTP Server id
	14.1.225.23; Tue, 11 Sep 2012 13:21:01 +0000
Received: from mail51-am1 (localhost [127.0.0.1])	by mail51-am1-R.bigfish.com
	(Postfix) with ESMTP id 035E9460113	for <xen-devel@lists.xen.org>;
	Tue, 11 Sep 2012 13:21: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: 0
X-BigFish: VPS0(zzc85fhc85dhzz1202h1d1ahzz8275bhz2dh668h839hd25he5bhf0ah107ah1288h12a5h12bdh34h1155h)
Received: from mail51-am1 (localhost.localdomain [127.0.0.1]) by mail51-am1
	(MessageSwitch) id 1347369658533735_11253;
	Tue, 11 Sep 2012 13:20:58 +0000 (UTC)
Received: from AM1EHSMHS008.bigfish.com (unknown [10.3.201.225])	by
	mail51-am1.bigfish.com (Postfix) with ESMTP id 7DDD71E0240	for
	<xen-devel@lists.xen.org>; Tue, 11 Sep 2012 13:20:58 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	AM1EHSMHS008.bigfish.com (10.3.207.108) with Microsoft SMTP Server id
	14.1.225.23; Tue, 11 Sep 2012 13:20:55 +0000
X-WSS-ID: 0MA6T2T-01-GU3-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 2AC5410280A6	for <xen-devel@lists.xen.org>;
	Tue, 11 Sep 2012 08:20:53 -0500 (CDT)
Received: from sausexhtp01.amd.com (163.181.3.165) by sausexedgep01.amd.com
	(163.181.36.54) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Tue, 11 Sep 2012 08:34:36 -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;
	Tue, 11 Sep 2012 08:20:54 -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; Tue, 11 Sep 2012
	09:20:52 -0400
Message-ID: <504F3AB3.9060902@amd.com>
Date: Tue, 11 Sep 2012 15:20:51 +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="------------020706030801040308010207"
X-OriginatorOrg: amd.com
Subject: [Xen-devel] [PATCH] MCE: use new common mce handler on AMD CPUs
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--------------020706030801040308010207
Content-Type: text/plain; charset="ISO-8859-15"
Content-Transfer-Encoding: 7bit


Factor common machine check handler out of intel specific code
and move it into common files.
Replace old common mce handler with new one and use it on AMD CPUs.
No functional changes on Intel side.
While here fix some whitespace nits and comments.

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
Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen
Registergericht Muenchen, HRB Nr. 43632

--------------020706030801040308010207
Content-Type: text/plain; charset="us-ascii"; name="xen_mce_handler.diff"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="xen_mce_handler.diff"
Content-Description: xen_mce_handler.diff

# User Christoph Egger
# Date 1347363969 -7200
Factor common machine check handler out of intel specific code
and move it into common files.
Replace old common mce handler with new one and use it on AMD CPUs.
No functional changes on Intel side.
While here fix some whitespace nits and comments.

Signed-off-by: Christoph Egger <Christoph.Egger@amd.com>

diff -r 9592e8808109 -r 1ff906461666 xen/arch/x86/cpu/mcheck/amd_k8.c
--- a/xen/arch/x86/cpu/mcheck/amd_k8.c
+++ b/xen/arch/x86/cpu/mcheck/amd_k8.c
@@ -72,7 +72,7 @@
 /* Machine Check Handler for AMD K8 family series */
 static void k8_machine_check(struct cpu_user_regs *regs, long error_code)
 {
-	mcheck_cmn_handler(regs, error_code, mca_allbanks);
+	mcheck_cmn_handler(regs, error_code, mca_allbanks, NULL);
 }
 
 /* AMD K8 machine check */
@@ -83,6 +83,7 @@ enum mcheck_type amd_k8_mcheck_init(stru
 
 	quirkflag = mcequirk_lookup_amd_quirkdata(c);
 
+	mce_handler_init();
 	x86_mce_vector_register(k8_machine_check);
 
 	for (i = 0; i < nr_mce_banks; i++) {
diff -r 9592e8808109 -r 1ff906461666 xen/arch/x86/cpu/mcheck/mce.c
--- a/xen/arch/x86/cpu/mcheck/mce.c
+++ b/xen/arch/x86/cpu/mcheck/mce.c
@@ -23,6 +23,8 @@
 #include <asm/msr.h>
 
 #include "mce.h"
+#include "barrier.h"
+#include "util.h"
 
 bool_t __read_mostly mce_disabled;
 invbool_param("mce", mce_disabled);
@@ -161,8 +163,30 @@ void mce_need_clearbank_register(mce_nee
     mc_need_clearbank_scan = cbfunc;
 }
 
+
+static struct mce_softirq_barrier mce_inside_bar, mce_severity_bar;
+static struct mce_softirq_barrier mce_trap_bar;
+
+/*
+ * mce_logout_lock should only be used in the trap handler,
+ * while MCIP has not been cleared yet in the global status
+ * register. Other use is not safe, since an MCE trap can
+ * happen at any moment, which would cause lock recursion.
+ */
+static DEFINE_SPINLOCK(mce_logout_lock);
+
+static atomic_t severity_cpu = ATOMIC_INIT(-1);
+static atomic_t found_error = ATOMIC_INIT(0);
+static cpumask_t mce_fatal_cpus;
+
+const struct mca_error_handler *__read_mostly mce_dhandlers;
+const struct mca_error_handler *__read_mostly mce_uhandlers;
+unsigned int __read_mostly mce_dhandler_num;
+unsigned int __read_mostly mce_uhandler_num;
+
+
 static void mca_init_bank(enum mca_source who,
-                                         struct mc_info *mi, int bank)
+    struct mc_info *mi, int bank)
 {
     struct mcinfo_bank *mib;
 
@@ -252,8 +276,9 @@ static int mca_init_global(uint32_t flag
  * For Intel latest CPU, whether to clear the error bank status needs to
  * be judged by the callback function defined above.
  */
-mctelem_cookie_t mcheck_mca_logout(enum mca_source who, struct mca_banks *bankmask,
-                                   struct mca_summary *sp, struct mca_banks* clear_bank)
+mctelem_cookie_t
+mcheck_mca_logout(enum mca_source who, struct mca_banks *bankmask,
+                  struct mca_summary *sp, struct mca_banks *clear_bank)
 {
     uint64_t gstatus, status;
     struct mcinfo_global *mig = NULL; /* on stack */
@@ -291,7 +316,7 @@ mctelem_cookie_t mcheck_mca_logout(enum 
     /* If no mc_recovery_scan callback handler registered,
      * this error is not recoverable
      */
-    recover = (mc_recoverable_scan)? 1: 0;
+    recover = (mc_recoverable_scan) ? 1 : 0;
 
     for (i = 0; i < nr_mce_banks; i++) {
         /* Skip bank if corresponding bit in bankmask is clear */
@@ -311,15 +336,14 @@ mctelem_cookie_t mcheck_mca_logout(enum 
 
         /* If this is the first bank with valid MCA DATA, then
          * try to reserve an entry from the urgent/nonurgent queue
-         * depending on whethere we are called from an exception or
+         * depending on whether we are called from an exception or
          * a poller;  this can fail (for example dom0 may not
          * yet have consumed past telemetry). */
         if (errcnt++ == 0) {
             if ( (mctc = mctelem_reserve(which)) != NULL ) {
                 mci = mctelem_dataptr(mctc);
                 mcinfo_clear(mci);
-                mig = (struct mcinfo_global*)x86_mcinfo_reserve
-                    (mci, sizeof(struct mcinfo_global));
+                mig = x86_mcinfo_reserve(mci, sizeof(struct mcinfo_global));
                 /* mc_info should at least hold up the global information */
                 ASSERT(mig);
                 mca_init_global(mc_flags, mig);
@@ -382,227 +406,141 @@ mctelem_cookie_t mcheck_mca_logout(enum 
     return mci != NULL ? mctc : NULL; /* may be NULL */
 }
 
-#define DOM_NORMAL 0
-#define DOM0_TRAP 1
-#define DOMU_TRAP 2
-#define DOMU_KILLED 4
+static void mce_spin_lock(spinlock_t *lk)
+{
+      while (!spin_trylock(lk)) {
+              cpu_relax();
+              mce_panic_check();
+      }
+}
+
+static void mce_spin_unlock(spinlock_t *lk)
+{
+      spin_unlock(lk);
+}
+
+static enum mce_result mce_action(struct cpu_user_regs *regs,
+    mctelem_cookie_t mctc);
+
+/*
+ * Return:
+ * -1: if system can't be recovered
+ * 0: Continue to next step
+ */
+static int mce_urgent_action(struct cpu_user_regs *regs,
+                              mctelem_cookie_t mctc)
+{
+    uint64_t gstatus;
+
+    if ( mctc == NULL)
+        return 0;
+
+    gstatus = mca_rdmsr(MSR_IA32_MCG_STATUS);
+
+    /*
+     * FIXME: When RIPV = EIPV = 0, it's a little bit tricky. It may be an
+     * asynchronic error, currently we have no way to precisely locate
+     * whether the error occur at guest or hypervisor.
+     * To avoid handling error in wrong way, we treat it as unrecovered.
+     *
+     * Another unrecovered case is RIPV = 0 while in hypervisor
+     * since Xen is not pre-emptible.
+     */
+    if ( !(gstatus & MCG_STATUS_RIPV) &&
+         (!(gstatus & MCG_STATUS_EIPV) || !guest_mode(regs)) )
+        return -1;
+
+    return mce_action(regs, mctc) == MCER_RESET ? -1 : 0;
+}
 
 /* Shared #MC handler. */
 void mcheck_cmn_handler(struct cpu_user_regs *regs, long error_code,
-                        struct mca_banks *bankmask)
+    struct mca_banks *bankmask, struct mca_banks *clear_bank)
 {
-    int xen_state_lost, dom0_state_lost, domU_state_lost;
-    struct vcpu *v = current;
-    struct domain *curdom = v->domain;
-    domid_t domid = curdom->domain_id;
-    int ctx_xen, ctx_dom0, ctx_domU;
-    uint32_t dom_state = DOM_NORMAL;
+    uint64_t gstatus;
     mctelem_cookie_t mctc = NULL;
     struct mca_summary bs;
-    struct mc_info *mci = NULL;
-    int irqlocked = 0;
-    uint64_t gstatus;
-    int ripv;
 
-    /* This handler runs as interrupt gate. So IPIs from the
-     * polling service routine are defered until we're finished.
-     */
+    mce_spin_lock(&mce_logout_lock);
 
-    /* Disable interrupts for the _vcpu_. It may not re-scheduled to
-     * another physical CPU. */
-    vcpu_schedule_lock_irq(v);
-    irqlocked = 1;
+    if (clear_bank != NULL) {
+        memset( clear_bank->bank_map, 0x0,
+            sizeof(long) * BITS_TO_LONGS(clear_bank->num));
+    }
+    mctc = mcheck_mca_logout(MCA_MCE_SCAN, bankmask, &bs, clear_bank);
 
-    /* Read global status;  if it does not indicate machine check
-     * in progress then bail as long as we have a valid ip to return to. */
-    gstatus = mca_rdmsr(MSR_IA32_MCG_STATUS);
-    ripv = ((gstatus & MCG_STATUS_RIPV) != 0);
-    if (!(gstatus & MCG_STATUS_MCIP) && ripv) {
-        add_taint(TAINT_MACHINE_CHECK); /* questionable */
-        vcpu_schedule_unlock_irq(v);
-        irqlocked = 0;
-        goto cmn_handler_done;
+    if (bs.errcnt) {
+        /*
+         * Uncorrected errors must be dealt with in softirq context.
+         */
+        if (bs.uc || bs.pcc) {
+            add_taint(TAINT_MACHINE_CHECK);
+            if (mctc != NULL)
+                mctelem_defer(mctc);
+            /*
+             * For PCC=1 and can't be recovered, context is lost, so
+             * reboot now without clearing the banks, and deal with
+             * the telemetry after reboot (the MSRs are sticky)
+             */
+            if (bs.pcc || !bs.recoverable)
+                cpumask_set_cpu(smp_processor_id(), &mce_fatal_cpus);
+        } else {
+            if (mctc != NULL)
+                mctelem_commit(mctc);
+        }
+        atomic_set(&found_error, 1);
+
+        /* The last CPU will be take check/clean-up etc */
+        atomic_set(&severity_cpu, smp_processor_id());
+
+        mce_printk(MCE_CRITICAL, "MCE: clear_bank map %lx on CPU%d\n",
+                *((unsigned long*)clear_bank), smp_processor_id());
+        if (clear_bank != NULL)
+            mcheck_mca_clearbanks(clear_bank);
+    } else {
+        if (mctc != NULL)
+            mctelem_dismiss(mctc);
     }
+    mce_spin_unlock(&mce_logout_lock);
 
-    /* Go and grab error telemetry.  We must choose whether to commit
-     * for logging or dismiss the cookie that is returned, and must not
-     * reference the cookie after that action.
-     */
-    mctc = mcheck_mca_logout(MCA_MCE_HANDLER, bankmask, &bs, NULL);
-    if (mctc != NULL)
-        mci = (struct mc_info *)mctelem_dataptr(mctc);
-
-    /* Clear MCIP or another #MC will enter shutdown state */
-    gstatus &= ~MCG_STATUS_MCIP;
-    mca_wrmsr(MSR_IA32_MCG_STATUS, gstatus);
-    wmb();
-
-    /* If no valid errors and our stack is intact, we're done */
-    if (ripv && bs.errcnt == 0) {
-        vcpu_schedule_unlock_irq(v);
-        irqlocked = 0;
-        goto cmn_handler_done;
-    }
-
-    if (bs.uc || bs.pcc)
-        add_taint(TAINT_MACHINE_CHECK);
-
-    /* Machine check exceptions will usually be for UC and/or PCC errors,
-     * but it is possible to configure machine check for some classes
-     * of corrected error.
-     *
-     * UC errors could compromise any domain or the hypervisor
-     * itself - for example a cache writeback of modified data that
-     * turned out to be bad could be for data belonging to anyone, not
-     * just the current domain.  In the absence of known data poisoning
-     * to prevent consumption of such bad data in the system we regard
-     * all UC errors as terminal.  It may be possible to attempt some
-     * heuristics based on the address affected, which guests have
-     * mappings to that mfn etc.
-     *
-     * PCC errors apply to the current context.
-     *
-     * If MCG_STATUS indicates !RIPV then even a #MC that is not UC
-     * and not PCC is terminal - the return instruction pointer
-     * pushed onto the stack is bogus.  If the interrupt context is
-     * the hypervisor or dom0 the game is over, otherwise we can
-     * limit the impact to a single domU but only if we trampoline
-     * somewhere safely - we can't return and unwind the stack.
-     * Since there is no trampoline in place we will treat !RIPV
-     * as terminal for any context.
-     */
-    ctx_xen = SEG_PL(regs->cs) == 0;
-    ctx_dom0 = !ctx_xen && (domid == 0);
-    ctx_domU = !ctx_xen && !ctx_dom0;
-
-    xen_state_lost = bs.uc != 0 || (ctx_xen && (bs.pcc || !ripv)) ||
-        !ripv;
-    dom0_state_lost = bs.uc != 0 || (ctx_dom0 && (bs.pcc || !ripv));
-    domU_state_lost = bs.uc != 0 || (ctx_domU && (bs.pcc || !ripv));
-
-    if (xen_state_lost) {
-        /* Now we are going to panic anyway. Allow interrupts, so that
-         * printk on serial console can work. */
-        vcpu_schedule_unlock_irq(v);
-        irqlocked = 0;
-
-        printk("Terminal machine check exception occurred in "
-               "hypervisor context.\n");
-
-        /* If MCG_STATUS_EIPV indicates, the IP on the stack is related
-         * to the error then it makes sense to print a stack trace.
-         * That can be useful for more detailed error analysis and/or
-         * error case studies to figure out, if we can clear
-         * xen_impacted and kill a DomU instead
-         * (i.e. if a guest only control structure is affected, but then
-         * we must ensure the bad pages are not re-used again).
-         */
-        if (bs.eipv & MCG_STATUS_EIPV) {
-            printk("MCE: Instruction Pointer is related to the "
-                   "error, therefore print the execution state.\n");
-            show_execution_state(regs);
-        }
-
-        /* Commit the telemetry so that panic flow can find it. */
-        if (mctc != NULL) {
-            x86_mcinfo_dump(mci);
-            mctelem_commit(mctc);
-        }
-        mc_panic("Hypervisor state lost due to machine check "
-                 "exception.\n");
-        /*NOTREACHED*/
-    }
+    mce_barrier_enter(&mce_trap_bar);
+    if ( mctc != NULL && mce_urgent_action(regs, mctc))
+        cpumask_set_cpu(smp_processor_id(), &mce_fatal_cpus);
+    mce_barrier_exit(&mce_trap_bar);
 
     /*
-     * Xen hypervisor state is intact.  If dom0 state is lost then
-     * give it a chance to decide what to do if it has registered
-     * a handler for this event, otherwise panic.
-     *
-     * XXFM Could add some Solaris dom0 contract kill here?
+     * Wait until everybody has processed the trap.
      */
-    if (dom0_state_lost) {
-        if (dom0 && dom0->max_vcpus && dom0->vcpu[0] &&
-            guest_has_trap_callback(dom0, 0, TRAP_machine_check)) {
-            dom_state = DOM0_TRAP;
-            send_guest_trap(dom0, 0, TRAP_machine_check);
-            /* XXFM case of return with !ripv ??? */
-        } else {
-            /* Commit telemetry for panic flow. */
-            if (mctc != NULL) {
-                x86_mcinfo_dump(mci);
-                mctelem_commit(mctc);
-            }
-            mc_panic("Dom0 state lost due to machine check "
-                     "exception\n");
-            /*NOTREACHED*/
+    mce_barrier_enter(&mce_trap_bar);
+    if (atomic_read(&severity_cpu) == smp_processor_id())
+    {
+        /* According to SDM, if no error bank found on any cpus,
+         * something unexpected happening, we can't do any
+         * recovery job but to reset the system.
+         */
+        if (atomic_read(&found_error) == 0)
+            mc_panic("MCE: No CPU found valid MCE, need reset\n");
+        if (!cpumask_empty(&mce_fatal_cpus))
+        {
+            char *ebufp, ebuf[96] = "MCE: Fatal error happened on CPUs ";
+            ebufp = ebuf + strlen(ebuf);
+            cpumask_scnprintf(ebufp, 95 - strlen(ebuf), &mce_fatal_cpus);
+            mc_panic(ebuf);
         }
+        atomic_set(&found_error, 0);
     }
+    mce_barrier_exit(&mce_trap_bar); 
 
-    /*
-     * If a domU has lost state then send it a trap if it has registered
-     * a handler, otherwise crash the domain.
-     * XXFM Revisit this functionality.
-     */
-    if (domU_state_lost) {
-        if (guest_has_trap_callback(v->domain, v->vcpu_id,
-                                    TRAP_machine_check)) {
-            dom_state = DOMU_TRAP;
-            send_guest_trap(curdom, v->vcpu_id,
-                            TRAP_machine_check);
-        } else {
-            dom_state = DOMU_KILLED;
-            /* Enable interrupts. This basically results in
-             * calling sti on the *physical* cpu. But after
-             * domain_crash() the vcpu pointer is invalid.
-             * Therefore, we must unlock the irqs before killing
-             * it. */
-            vcpu_schedule_unlock_irq(v);
-            irqlocked = 0;
+    /* Clear flags after above fatal check */
+    mce_barrier_enter(&mce_trap_bar);
+    gstatus = mca_rdmsr(MSR_IA32_MCG_STATUS);
+    if ((gstatus & MCG_STATUS_MCIP) != 0) {
+        mce_printk(MCE_CRITICAL, "MCE: Clear MCIP@ last step");
+        mca_wrmsr(MSR_IA32_MCG_STATUS, gstatus & ~MCG_STATUS_MCIP);
+    }
+    mce_barrier_exit(&mce_trap_bar);
 
-            /* DomU is impacted. Kill it and continue. */
-            domain_crash(curdom);
-        }
-    }
-
-    switch (dom_state) {
-    case DOM0_TRAP:
-    case DOMU_TRAP:
-        /* Enable interrupts. */
-        vcpu_schedule_unlock_irq(v);
-        irqlocked = 0;
-
-        /* guest softirqs and event callbacks are scheduled
-         * immediately after this handler exits. */
-        break;
-    case DOMU_KILLED:
-        /* Nothing to do here. */
-        break;
-
-    case DOM_NORMAL:
-        vcpu_schedule_unlock_irq(v);
-        irqlocked = 0;
-        break;
-    }
-
- cmn_handler_done:
-    BUG_ON(irqlocked);
-    BUG_ON(!ripv);
-
-    if (bs.errcnt) {
-        /* Not panicing, so forward telemetry to dom0 now if it
-         * is interested. */
-        if (dom0_vmce_enabled()) {
-            if (mctc != NULL)
-                mctelem_commit(mctc);
-            send_global_virq(VIRQ_MCA);
-        } else {
-            x86_mcinfo_dump(mci);
-            if (mctc != NULL)
-                mctelem_dismiss(mctc);
-        }
-    } else if (mctc != NULL) {
-        mctelem_dismiss(mctc);
-    }
+    raise_softirq(MACHINE_CHECK_SOFTIRQ);
 }
 
 void mcheck_mca_clearbanks(struct mca_banks *bankmask)
@@ -1628,3 +1566,191 @@ void mc_panic(char *s)
     mc_panic_dump();
     panic("HARDWARE ERROR");
 }
+
+/* Machine Check owner judge algorithm:
+ * When error happens, all cpus serially read its msr banks.
+ * The first CPU who fetches the error bank's info will clear
+ * this bank. Later readers can't get any information again.
+ * The first CPU is the actual mce_owner
+ *
+ * For Fatal (pcc=1) error, it might cause machine crash
+ * before we're able to log. For avoiding log missing, we adopt two
+ * round scanning:
+ * Round1: simply scan. If found pcc = 1 or ripv = 0, simply reset.
+ * All MCE banks are sticky, when boot up, MCE polling mechanism
+ * will help to collect and log those MCE errors.
+ * Round2: Do all MCE processing logic as normal.
+ */
+
+/* Maybe called in MCE context, no lock, no printk */
+static enum mce_result mce_action(struct cpu_user_regs *regs,
+                      mctelem_cookie_t mctc)
+{
+    struct mc_info *local_mi;
+    enum mce_result bank_result = MCER_NOERROR;
+    enum mce_result worst_result = MCER_NOERROR;
+    struct mcinfo_common *mic = NULL;
+    struct mca_binfo binfo;
+    const struct mca_error_handler *handlers = mce_dhandlers;
+    unsigned int i, handler_num = mce_dhandler_num;
+
+    /* When in mce context, regs is valid */
+    if (regs)
+    {
+        handler_num = mce_uhandler_num;
+        handlers = mce_uhandlers;
+    }
+
+    /* At least a default handler should be registerd */
+    ASSERT(handler_num);
+
+    local_mi = (struct mc_info*)mctelem_dataptr(mctc);
+    x86_mcinfo_lookup(mic, local_mi, MC_TYPE_GLOBAL);
+    if (mic == NULL) {
+        printk(KERN_ERR "MCE: get local buffer entry failed\n ");
+        return MCER_CONTINUE;
+    }
+
+    memset(&binfo, 0, sizeof(binfo));
+    binfo.mig = (struct mcinfo_global *)mic;
+    binfo.mi = local_mi;
+
+    /* Processing bank information */
+    x86_mcinfo_lookup(mic, local_mi, MC_TYPE_BANK);
+
+    for ( ; bank_result != MCER_RESET && mic && mic->size;
+          mic = x86_mcinfo_next(mic) )
+    {
+        if (mic->type != MC_TYPE_BANK) {
+            continue;
+        }
+        binfo.mib = (struct mcinfo_bank*)mic;
+        binfo.bank = binfo.mib->mc_bank;
+        bank_result = MCER_NOERROR;
+        for ( i = 0; i < handler_num; i++ ) {
+            if (handlers[i].owned_error(binfo.mib->mc_status))
+            {
+                handlers[i].recovery_handler(&binfo, &bank_result, regs);
+                if (worst_result < bank_result)
+                    worst_result = bank_result;
+                break;
+            }
+        }
+        ASSERT(i != handler_num);
+    }
+
+    return worst_result;
+}
+
+/*
+ * Called from mctelem_process_deferred. Return 1 if the telemetry
+ * should be committed for dom0 consumption, 0 if it should be
+ * dismissed.
+ */
+static int mce_delayed_action(mctelem_cookie_t mctc)
+{
+    enum mce_result result;
+    int ret = 0;
+
+    result = mce_action(NULL, mctc);
+
+    switch (result)
+    {
+    case MCER_RESET:
+        dprintk(XENLOG_ERR, "MCE delayed action failed\n");
+        is_mc_panic = 1;
+        x86_mcinfo_dump(mctelem_dataptr(mctc));
+        panic("MCE: Software recovery failed for the UCR\n");
+        break;
+    case MCER_RECOVERED:
+        dprintk(XENLOG_INFO, "MCE: Error is successfully recovered\n");
+        ret  = 1;
+        break;
+    case MCER_CONTINUE:
+        dprintk(XENLOG_INFO, "MCE: Error can't be recovered, "
+            "system is tainted\n");
+        x86_mcinfo_dump(mctelem_dataptr(mctc));
+        ret = 1;
+        break;
+    default:
+        ret = 0;
+        break;
+    }
+    return ret;
+}
+
+/* Softirq Handler for this MCE# processing */
+static void mce_softirq(void)
+{
+    int cpu = smp_processor_id();
+    unsigned int workcpu;
+
+    mce_printk(MCE_VERBOSE, "CPU%d enter softirq\n", cpu);
+
+    mce_barrier_enter(&mce_inside_bar);
+
+    /*
+     * Everybody is here. Now let's see who gets to do the
+     * recovery work. Right now we just see if there's a CPU
+     * that did not have any problems, and pick that one.
+     *
+     * First, just set a default value: the last CPU who reaches this
+     * will overwrite the value and become the default.
+     */
+
+    atomic_set(&severity_cpu, cpu);
+
+    mce_barrier_enter(&mce_severity_bar);
+    if (!mctelem_has_deferred(cpu))
+        atomic_set(&severity_cpu, cpu);
+    mce_barrier_exit(&mce_severity_bar);
+
+    /* We choose severity_cpu for further processing */
+    if (atomic_read(&severity_cpu) == cpu) {
+
+        mce_printk(MCE_VERBOSE, "CPU%d handling errors\n", cpu);
+
+        /* Step1: Fill DOM0 LOG buffer, vMCE injection buffer and
+         * vMCE MSRs virtualization buffer
+         */
+        for_each_online_cpu(workcpu) {
+            mctelem_process_deferred(workcpu, mce_delayed_action);
+        }
+
+        /* Step2: Send Log to DOM0 through vIRQ */
+        if (dom0_vmce_enabled()) {
+            mce_printk(MCE_VERBOSE, "MCE: send MCE# to DOM0 through virq\n");
+            send_global_virq(VIRQ_MCA);
+        }
+    }
+
+    mce_barrier_exit(&mce_inside_bar);
+}
+
+/* Machine Check owner judge algorithm:
+ * When error happens, all cpus serially read its msr banks.
+ * The first CPU who fetches the error bank's info will clear
+ * this bank. Later readers can't get any infor again.
+ * The first CPU is the actual mce_owner
+ *
+ * For Fatal (pcc=1) error, it might cause machine crash
+ * before we're able to log. For avoiding log missing, we adopt two
+ * round scanning:
+ * Round1: simply scan. If found pcc = 1 or ripv = 0, simply reset.
+ * All MCE banks are sticky, when boot up, MCE polling mechanism
+ * will help to collect and log those MCE errors.
+ * Round2: Do all MCE processing logic as normal.
+ */
+void mce_handler_init(void)
+{
+    if (smp_processor_id() != 0)
+        return;
+
+    /* callback register, do we really need so many callback? */
+    /* mce handler data initialization */
+    mce_barrier_init(&mce_inside_bar);
+    mce_barrier_init(&mce_severity_bar);
+    mce_barrier_init(&mce_trap_bar);
+    spin_lock_init(&mce_logout_lock);
+    open_softirq(MACHINE_CHECK_SOFTIRQ, mce_softirq);
+}
diff -r 9592e8808109 -r 1ff906461666 xen/arch/x86/cpu/mcheck/mce.h
--- a/xen/arch/x86/cpu/mcheck/mce.h
+++ b/xen/arch/x86/cpu/mcheck/mce.h
@@ -78,7 +78,8 @@ extern void x86_mce_vector_register(x86_
 
 /* Common generic MCE handler that implementations may nominate
  * via x86_mce_vector_register. */
-extern void mcheck_cmn_handler(struct cpu_user_regs *, long, struct mca_banks *);
+extern void mcheck_cmn_handler(struct cpu_user_regs *, long,
+    struct mca_banks *, struct mca_banks *);
 
 /* Register a handler for judging whether mce is recoverable. */
 typedef int (*mce_recoverable_t)(u64 status);
@@ -166,16 +167,28 @@ void *x86_mcinfo_reserve(struct mc_info 
 void x86_mcinfo_dump(struct mc_info *mi);
 
 int fill_vmsr_data(struct mcinfo_bank *mc_bank, struct domain *d,
-        uint64_t gstatus);
+    uint64_t gstatus);
 int inject_vmce(struct domain *d);
-int vmce_domain_inject(struct mcinfo_bank *bank, struct domain *d, struct mcinfo_global *global);
+int vmce_domain_inject(struct mcinfo_bank *bank, struct domain *d,
+    struct mcinfo_global *global);
 
 static inline int mce_vendor_bank_msr(const struct vcpu *v, uint32_t msr)
 {
-    if ( boot_cpu_data.x86_vendor == X86_VENDOR_INTEL &&
-         msr >= MSR_IA32_MC0_CTL2 &&
-         msr < MSR_IA32_MCx_CTL2(v->arch.mcg_cap & MCG_CAP_COUNT) )
-          return 1;
+    switch (boot_cpu_data.x86_vendor) {
+    case X86_VENDOR_INTEL:
+        if (msr >= MSR_IA32_MC0_CTL2 &&
+            msr < MSR_IA32_MCx_CTL2(v->arch.mcg_cap & MCG_CAP_COUNT) )
+            return 1;
+        break;
+    case X86_VENDOR_AMD:
+        switch (msr) {
+        case MSR_F10_MC4_MISC1:
+        case MSR_F10_MC4_MISC2:
+        case MSR_F10_MC4_MISC3:
+            return 1;
+        }
+        break;
+    }
     return 0;
 }
 
@@ -188,27 +201,35 @@ static inline int mce_bank_msr(const str
     return 0;
 }
 
+/* MC softirq */
+void mce_handler_init(void);
+
+extern const struct mca_error_handler *mce_dhandlers;
+extern const struct mca_error_handler *mce_uhandlers;
+extern unsigned int mce_dhandler_num;
+extern unsigned int mce_uhandler_num;
+
 /* Fields are zero when not available */
 struct mce {
-    __u64 status;
-    __u64 misc;
-    __u64 addr;
-    __u64 mcgstatus;
-    __u64 ip;
-    __u64 tsc;      /* cpu time stamp counter */
-    __u64 time;     /* wall time_t when error was detected */
-    __u8  cpuvendor;        /* cpu vendor as encoded in system.h */
-    __u8  inject_flags;     /* software inject flags */
-    __u16  pad;
-    __u32 cpuid;    /* CPUID 1 EAX */
-    __u8  cs;               /* code segment */
-    __u8  bank;     /* machine check bank */
-    __u8  cpu;      /* cpu number; obsolete; use extcpu now */
-    __u8  finished;   /* entry is valid */
-    __u32 extcpu;   /* linux cpu number that detected the error */
-    __u32 socketid; /* CPU socket ID */
-    __u32 apicid;   /* CPU initial apic ID */
-    __u64 mcgcap;   /* MCGCAP MSR: machine check capabilities of CPU */
+    uint64_t status;
+    uint64_t misc;
+    uint64_t addr;
+    uint64_t mcgstatus;
+    uint64_t ip;
+    uint64_t tsc;      /* cpu time stamp counter */
+    uint64_t time;     /* wall time_t when error was detected */
+    uint8_t  cpuvendor;        /* cpu vendor as encoded in system.h */
+    uint8_t  inject_flags;     /* software inject flags */
+    uint16_t pad;
+    uint32_t cpuid;    /* CPUID 1 EAX */
+    uint8_t  cs;       /* code segment */
+    uint8_t  bank;     /* machine check bank */
+    uint8_t  cpu;      /* cpu number; obsolete; use extcpu now */
+    uint8_t  finished; /* entry is valid */
+    uint32_t extcpu;   /* linux cpu number that detected the error */
+    uint32_t socketid; /* CPU socket ID */
+    uint32_t apicid;   /* CPU initial apic ID */
+    uint64_t mcgcap;   /* MCGCAP MSR: machine check capabilities of CPU */
 };
 
 extern int apei_write_mce(struct mce *m);
diff -r 9592e8808109 -r 1ff906461666 xen/arch/x86/cpu/mcheck/mce_intel.c
--- a/xen/arch/x86/cpu/mcheck/mce_intel.c
+++ b/xen/arch/x86/cpu/mcheck/mce_intel.c
@@ -166,244 +166,6 @@ static void intel_init_thermal(struct cp
 }
 #endif /* CONFIG_X86_MCE_THERMAL */
 
-static struct mce_softirq_barrier mce_inside_bar, mce_severity_bar;
-static struct mce_softirq_barrier mce_trap_bar;
-
-/*
- * mce_logout_lock should only be used in the trap handler,
- * while MCIP has not been cleared yet in the global status
- * register. Other use is not safe, since an MCE trap can
- * happen at any moment, which would cause lock recursion.
- */
-static DEFINE_SPINLOCK(mce_logout_lock);
-
-static atomic_t severity_cpu = ATOMIC_INIT(-1);
-static atomic_t found_error = ATOMIC_INIT(0);
-static cpumask_t mce_fatal_cpus;
-
-static const struct mca_error_handler *__read_mostly mce_dhandlers;
-static const struct mca_error_handler *__read_mostly mce_uhandlers;
-static unsigned int __read_mostly mce_dhandler_num;
-static unsigned int __read_mostly mce_uhandler_num;
-
-/* Maybe called in MCE context, no lock, no printk */
-static enum mce_result mce_action(struct cpu_user_regs *regs,
-                      mctelem_cookie_t mctc)
-{
-    struct mc_info *local_mi;
-    enum mce_result bank_result = MCER_NOERROR;
-    enum mce_result worst_result = MCER_NOERROR;
-    struct mcinfo_common *mic = NULL;
-    struct mca_binfo binfo;
-    const struct mca_error_handler *handlers = mce_dhandlers;
-    unsigned int i, handler_num = mce_dhandler_num;
-
-    /* When in mce context, regs is valid */
-    if (regs)
-    {
-        handler_num = mce_uhandler_num;
-        handlers = mce_uhandlers;
-    }
-
-    /* At least a default handler should be registerd */
-    ASSERT(handler_num);
-
-    local_mi = (struct mc_info*)mctelem_dataptr(mctc);
-    x86_mcinfo_lookup(mic, local_mi, MC_TYPE_GLOBAL);
-    if (mic == NULL) {
-        printk(KERN_ERR "MCE: get local buffer entry failed\n ");
-        return MCER_CONTINUE;
-    }
-
-    memset(&binfo, 0, sizeof(binfo));
-    binfo.mig = (struct mcinfo_global *)mic;
-    binfo.mi = local_mi;
-
-    /* Processing bank information */
-    x86_mcinfo_lookup(mic, local_mi, MC_TYPE_BANK);
-
-    for ( ; bank_result != MCER_RESET && mic && mic->size;
-          mic = x86_mcinfo_next(mic) )
-    {
-        if (mic->type != MC_TYPE_BANK) {
-            continue;
-        }
-        binfo.mib = (struct mcinfo_bank*)mic;
-        binfo.bank = binfo.mib->mc_bank;
-        bank_result = MCER_NOERROR;
-        for ( i = 0; i < handler_num; i++ ) {
-            if (handlers[i].owned_error(binfo.mib->mc_status))
-            {
-                handlers[i].recovery_handler(&binfo, &bank_result, regs);
-                if (worst_result < bank_result)
-                    worst_result = bank_result;
-                break;
-            }
-        }
-        ASSERT(i != handler_num);
-    }
-
-    return worst_result;
-}
-
-/*
- * Called from mctelem_process_deferred. Return 1 if the telemetry
- * should be committed for dom0 consumption, 0 if it should be
- * dismissed.
- */
-static int mce_delayed_action(mctelem_cookie_t mctc)
-{
-    enum mce_result result;
-    int ret = 0;
-
-    result = mce_action(NULL, mctc);
-
-    switch (result)
-    {
-    case MCER_RESET:
-        dprintk(XENLOG_ERR, "MCE delayed action failed\n");
-        is_mc_panic = 1;
-        x86_mcinfo_dump(mctelem_dataptr(mctc));
-        panic("MCE: Software recovery failed for the UCR\n");
-        break;
-    case MCER_RECOVERED:
-        dprintk(XENLOG_INFO, "MCE: Error is successfully recovered\n");
-        ret  = 1;
-        break;
-    case MCER_CONTINUE:
-        dprintk(XENLOG_INFO, "MCE: Error can't be recovered, "
-            "system is tainted\n");
-        x86_mcinfo_dump(mctelem_dataptr(mctc));
-        ret = 1;
-        break;
-    default:
-        ret = 0;
-        break;
-    }
-    return ret;
-}
-
-/* Softirq Handler for this MCE# processing */
-static void mce_softirq(void)
-{
-    int cpu = smp_processor_id();
-    unsigned int workcpu;
-
-    mce_printk(MCE_VERBOSE, "CPU%d enter softirq\n", cpu);
-
-    mce_barrier_enter(&mce_inside_bar);
-
-    /*
-     * Everybody is here. Now let's see who gets to do the
-     * recovery work. Right now we just see if there's a CPU
-     * that did not have any problems, and pick that one.
-     *
-     * First, just set a default value: the last CPU who reaches this
-     * will overwrite the value and become the default.
-     */
-
-    atomic_set(&severity_cpu, cpu);
-
-    mce_barrier_enter(&mce_severity_bar);
-    if (!mctelem_has_deferred(cpu))
-        atomic_set(&severity_cpu, cpu);
-    mce_barrier_exit(&mce_severity_bar);
-
-    /* We choose severity_cpu for further processing */
-    if (atomic_read(&severity_cpu) == cpu) {
-
-        mce_printk(MCE_VERBOSE, "CPU%d handling errors\n", cpu);
-
-        /* Step1: Fill DOM0 LOG buffer, vMCE injection buffer and
-         * vMCE MSRs virtualization buffer
-         */
-        for_each_online_cpu(workcpu) {
-            mctelem_process_deferred(workcpu, mce_delayed_action);
-        }
-
-        /* Step2: Send Log to DOM0 through vIRQ */
-        if (dom0_vmce_enabled()) {
-            mce_printk(MCE_VERBOSE, "MCE: send MCE# to DOM0 through virq\n");
-            send_global_virq(VIRQ_MCA);
-        }
-    }
-
-    mce_barrier_exit(&mce_inside_bar);
-}
-
-/*
- * Return:
- * -1: if system can't be recoved
- * 0: Continoue to next step
- */
-static int mce_urgent_action(struct cpu_user_regs *regs,
-                              mctelem_cookie_t mctc)
-{
-    uint64_t gstatus;
-
-    if ( mctc == NULL)
-        return 0;
-
-    gstatus = mca_rdmsr(MSR_IA32_MCG_STATUS);
-
-    /*
-     * FIXME: When RIPV = EIPV = 0, it's a little bit tricky. It may be an
-     * asynchronic error, currently we have no way to precisely locate
-     * whether the error occur at guest or hypervisor.
-     * To avoid handling error in wrong way, we treat it as unrecovered.
-     *
-     * Another unrecovered case is RIPV = 0 while in hypervisor
-     * since Xen is not pre-emptible.
-     */
-    if ( !(gstatus & MCG_STATUS_RIPV) &&
-         (!(gstatus & MCG_STATUS_EIPV) || !guest_mode(regs)) )
-        return -1;
-
-    return mce_action(regs, mctc) == MCER_RESET ? -1 : 0;
-}
-
-/* Machine Check owner judge algorithm:
- * When error happens, all cpus serially read its msr banks.
- * The first CPU who fetches the error bank's info will clear
- * this bank. Later readers can't get any infor again.
- * The first CPU is the actual mce_owner
- *
- * For Fatal (pcc=1) error, it might cause machine crash
- * before we're able to log. For avoiding log missing, we adopt two
- * round scanning:
- * Round1: simply scan. If found pcc = 1 or ripv = 0, simply reset.
- * All MCE banks are sticky, when boot up, MCE polling mechanism
- * will help to collect and log those MCE errors.
- * Round2: Do all MCE processing logic as normal.
- */
-
-static void mce_handler_init(void)
-{
-    if (smp_processor_id() != 0)
-        return;
-
-    /* callback register, do we really need so many callback? */
-    /* mce handler data initialization */
-    mce_barrier_init(&mce_inside_bar);
-    mce_barrier_init(&mce_severity_bar);
-    mce_barrier_init(&mce_trap_bar);
-    spin_lock_init(&mce_logout_lock);
-    open_softirq(MACHINE_CHECK_SOFTIRQ, mce_softirq);
-}
-
-static void mce_spin_lock(spinlock_t *lk)
-{
-      while (!spin_trylock(lk)) {
-              cpu_relax();
-              mce_panic_check();
-      }
-}
-
-static void mce_spin_unlock(spinlock_t *lk)
-{
-      spin_unlock(lk);
-}
-
 /* Intel MCE handler */
 static inline void intel_get_extended_msr(struct mcinfo_extended *ext, u32 msr)
 {
@@ -731,88 +493,8 @@ static const struct mca_error_handler in
 
 static void intel_machine_check(struct cpu_user_regs * regs, long error_code)
 {
-    uint64_t gstatus;
-    mctelem_cookie_t mctc = NULL;
-    struct mca_summary bs;
-    struct mca_banks *clear_bank;
-
-    mce_spin_lock(&mce_logout_lock);
-
-    clear_bank = __get_cpu_var(mce_clear_banks);
-    memset( clear_bank->bank_map, 0x0,
-        sizeof(long) * BITS_TO_LONGS(clear_bank->num));
-    mctc = mcheck_mca_logout(MCA_MCE_SCAN, mca_allbanks, &bs, clear_bank);
-
-    if (bs.errcnt) {
-        /*
-         * Uncorrected errors must be dealth with in softirq context.
-         */
-        if (bs.uc || bs.pcc) {
-            add_taint(TAINT_MACHINE_CHECK);
-            if (mctc != NULL)
-                mctelem_defer(mctc);
-            /*
-             * For PCC=1 and can't be recovered, context is lost, so reboot now without
-             * clearing  the banks, and deal with the telemetry after reboot
-             * (the MSRs are sticky)
-             */
-            if (bs.pcc || !bs.recoverable)
-                cpumask_set_cpu(smp_processor_id(), &mce_fatal_cpus);
-        } else {
-            if (mctc != NULL)
-                mctelem_commit(mctc);
-        }
-        atomic_set(&found_error, 1);
-
-        /* The last CPU will be take check/clean-up etc */
-        atomic_set(&severity_cpu, smp_processor_id());
-
-        mce_printk(MCE_CRITICAL, "MCE: clear_bank map %lx on CPU%d\n",
-                *((unsigned long*)clear_bank), smp_processor_id());
-        mcheck_mca_clearbanks(clear_bank);
-    } else {
-        if (mctc != NULL)
-            mctelem_dismiss(mctc);
-    }
-    mce_spin_unlock(&mce_logout_lock);
-
-    mce_barrier_enter(&mce_trap_bar);
-    if ( mctc != NULL && mce_urgent_action(regs, mctc))
-        cpumask_set_cpu(smp_processor_id(), &mce_fatal_cpus);
-    mce_barrier_exit(&mce_trap_bar);
-    /*
-     * Wait until everybody has processed the trap.
-     */
-    mce_barrier_enter(&mce_trap_bar);
-    if (atomic_read(&severity_cpu) == smp_processor_id())
-    {
-        /* According to SDM, if no error bank found on any cpus,
-         * something unexpected happening, we can't do any
-         * recovery job but to reset the system.
-         */
-        if (atomic_read(&found_error) == 0)
-            mc_panic("MCE: No CPU found valid MCE, need reset\n");
-        if (!cpumask_empty(&mce_fatal_cpus))
-        {
-            char *ebufp, ebuf[96] = "MCE: Fatal error happened on CPUs ";
-            ebufp = ebuf + strlen(ebuf);
-            cpumask_scnprintf(ebufp, 95 - strlen(ebuf), &mce_fatal_cpus);
-            mc_panic(ebuf);
-        }
-        atomic_set(&found_error, 0);
-    }
-    mce_barrier_exit(&mce_trap_bar);
-
-    /* Clear flags after above fatal check */
-    mce_barrier_enter(&mce_trap_bar);
-    gstatus = mca_rdmsr(MSR_IA32_MCG_STATUS);
-    if ((gstatus & MCG_STATUS_MCIP) != 0) {
-        mce_printk(MCE_CRITICAL, "MCE: Clear MCIP@ last step");
-        mca_wrmsr(MSR_IA32_MCG_STATUS, gstatus & ~MCG_STATUS_MCIP);
-    }
-    mce_barrier_exit(&mce_trap_bar);
-
-    raise_softirq(MACHINE_CHECK_SOFTIRQ);
+    mcheck_cmn_handler(regs, error_code, mca_allbanks,
+        __get_cpu_var(mce_clear_banks));
 }
 
 /* According to MCA OS writer guide, CMCI handler need to clear bank when
diff -r 9592e8808109 -r 1ff906461666 xen/arch/x86/cpu/mcheck/x86_mca.h
--- a/xen/arch/x86/cpu/mcheck/x86_mca.h
+++ b/xen/arch/x86/cpu/mcheck/x86_mca.h
@@ -32,11 +32,11 @@
 /* Bitfield of the MSR_IA32_MCG_CAP register */
 #define MCG_CAP_COUNT           0x00000000000000ffULL
 #define MCG_CTL_P               (1ULL<<8)
-#define MCG_EXT_P               (1ULL<<9)
-#define MCG_CMCI_P              (1ULL<<10)
-#define MCG_TES_P               (1ULL<<11)
-#define MCG_EXT_CNT             16
-#define MCG_SER_P               (1ULL<<24)
+#define MCG_EXT_P               (1ULL<<9)  /* Intel specific */
+#define MCG_CMCI_P              (1ULL<<10) /* Intel specific */
+#define MCG_TES_P               (1ULL<<11) /* Intel specific */
+#define MCG_EXT_CNT             16         /* Intel specific */
+#define MCG_SER_P               (1ULL<<24) /* Intel specific */
 /* Other bits are reserved */
 
 /* Bitfield of the MSR_IA32_MCG_STATUS register */
@@ -53,9 +53,9 @@
 /* Other information */
 #define MCi_STATUS_OTHER        0x01ffffff00000000ULL
 /* Action Required flag */
-#define MCi_STATUS_AR           0x0080000000000000ULL
+#define MCi_STATUS_AR           0x0080000000000000ULL  /* Intel specific */
 /* Signaling flag */
-#define MCi_STATUS_S            0x0100000000000000ULL
+#define MCi_STATUS_S            0x0100000000000000ULL  /* Intel specific */
 /* processor context corrupt */
 #define MCi_STATUS_PCC          0x0200000000000000ULL
 /* MSR_K8_MCi_ADDR register valid */
@@ -100,7 +100,7 @@ struct mca_banks
     unsigned long *bank_map;
 };
 
-static inline void mcabanks_clear(int bit, struct mca_banks *banks)    \
+static inline void mcabanks_clear(int bit, struct mca_banks *banks)
 {
     if (!banks || !banks->bank_map || bit >= banks->num)
         return ;
@@ -125,7 +125,7 @@ struct mca_banks *mcabanks_alloc(void);
 void mcabanks_free(struct mca_banks *banks);
 extern struct mca_banks *mca_allbanks;
 
-/*Keep bank so that we can get staus even if mib is NULL */
+/* Keep bank so that we can get status even if mib is NULL */
 struct mca_binfo {
     int bank;
     struct mcinfo_global *mig;
@@ -138,7 +138,7 @@ enum mce_result
 {
     MCER_NOERROR,
     MCER_RECOVERED,
-    /* Not recoverd, but can continue */
+    /* Not recovered, but can continue */
     MCER_CONTINUE,
     MCER_RESET,
 };
@@ -149,7 +149,7 @@ struct mca_error_handler
      * identified by mca_code. Otherwise, we might need to have
      * a seperate function to decode the corresponding actions
      * for the particular mca error later.
-    */
+     */
     int (*owned_error)(uint64_t status);
     void (*recovery_handler)(struct mca_binfo *binfo,
                     enum mce_result *result, struct cpu_user_regs *regs);

--------------020706030801040308010207
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--------------020706030801040308010207--


From xen-devel-bounces@lists.xen.org Tue Sep 11 13:21:30 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 2012 13:21:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TBQP1-0002k5-8t; Tue, 11 Sep 2012 13:21:19 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Christoph.Egger@amd.com>) id 1TBQOz-0002jt-Md
	for xen-devel@lists.xen.org; Tue, 11 Sep 2012 13:21:18 +0000
X-Env-Sender: Christoph.Egger@amd.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1347369661!3558848!1
X-Originating-IP: [213.199.154.205]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28360 invoked from network); 11 Sep 2012 13:21:02 -0000
Received: from am1ehsobe002.messaging.microsoft.com (HELO
	am1outboundpool.messaging.microsoft.com) (213.199.154.205)
	by server-14.tower-27.messagelabs.com with AES128-SHA encrypted SMTP;
	11 Sep 2012 13:21:02 -0000
Received: from mail51-am1-R.bigfish.com (10.3.201.230) by
	AM1EHSOBE003.bigfish.com (10.3.204.23) with Microsoft SMTP Server id
	14.1.225.23; Tue, 11 Sep 2012 13:21:01 +0000
Received: from mail51-am1 (localhost [127.0.0.1])	by mail51-am1-R.bigfish.com
	(Postfix) with ESMTP id 035E9460113	for <xen-devel@lists.xen.org>;
	Tue, 11 Sep 2012 13:21: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: 0
X-BigFish: VPS0(zzc85fhc85dhzz1202h1d1ahzz8275bhz2dh668h839hd25he5bhf0ah107ah1288h12a5h12bdh34h1155h)
Received: from mail51-am1 (localhost.localdomain [127.0.0.1]) by mail51-am1
	(MessageSwitch) id 1347369658533735_11253;
	Tue, 11 Sep 2012 13:20:58 +0000 (UTC)
Received: from AM1EHSMHS008.bigfish.com (unknown [10.3.201.225])	by
	mail51-am1.bigfish.com (Postfix) with ESMTP id 7DDD71E0240	for
	<xen-devel@lists.xen.org>; Tue, 11 Sep 2012 13:20:58 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	AM1EHSMHS008.bigfish.com (10.3.207.108) with Microsoft SMTP Server id
	14.1.225.23; Tue, 11 Sep 2012 13:20:55 +0000
X-WSS-ID: 0MA6T2T-01-GU3-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 2AC5410280A6	for <xen-devel@lists.xen.org>;
	Tue, 11 Sep 2012 08:20:53 -0500 (CDT)
Received: from sausexhtp01.amd.com (163.181.3.165) by sausexedgep01.amd.com
	(163.181.36.54) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Tue, 11 Sep 2012 08:34:36 -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;
	Tue, 11 Sep 2012 08:20:54 -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; Tue, 11 Sep 2012
	09:20:52 -0400
Message-ID: <504F3AB3.9060902@amd.com>
Date: Tue, 11 Sep 2012 15:20:51 +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="------------020706030801040308010207"
X-OriginatorOrg: amd.com
Subject: [Xen-devel] [PATCH] MCE: use new common mce handler on AMD CPUs
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--------------020706030801040308010207
Content-Type: text/plain; charset="ISO-8859-15"
Content-Transfer-Encoding: 7bit


Factor common machine check handler out of intel specific code
and move it into common files.
Replace old common mce handler with new one and use it on AMD CPUs.
No functional changes on Intel side.
While here fix some whitespace nits and comments.

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
Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen
Registergericht Muenchen, HRB Nr. 43632

--------------020706030801040308010207
Content-Type: text/plain; charset="us-ascii"; name="xen_mce_handler.diff"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="xen_mce_handler.diff"
Content-Description: xen_mce_handler.diff

# User Christoph Egger
# Date 1347363969 -7200
Factor common machine check handler out of intel specific code
and move it into common files.
Replace old common mce handler with new one and use it on AMD CPUs.
No functional changes on Intel side.
While here fix some whitespace nits and comments.

Signed-off-by: Christoph Egger <Christoph.Egger@amd.com>

diff -r 9592e8808109 -r 1ff906461666 xen/arch/x86/cpu/mcheck/amd_k8.c
--- a/xen/arch/x86/cpu/mcheck/amd_k8.c
+++ b/xen/arch/x86/cpu/mcheck/amd_k8.c
@@ -72,7 +72,7 @@
 /* Machine Check Handler for AMD K8 family series */
 static void k8_machine_check(struct cpu_user_regs *regs, long error_code)
 {
-	mcheck_cmn_handler(regs, error_code, mca_allbanks);
+	mcheck_cmn_handler(regs, error_code, mca_allbanks, NULL);
 }
 
 /* AMD K8 machine check */
@@ -83,6 +83,7 @@ enum mcheck_type amd_k8_mcheck_init(stru
 
 	quirkflag = mcequirk_lookup_amd_quirkdata(c);
 
+	mce_handler_init();
 	x86_mce_vector_register(k8_machine_check);
 
 	for (i = 0; i < nr_mce_banks; i++) {
diff -r 9592e8808109 -r 1ff906461666 xen/arch/x86/cpu/mcheck/mce.c
--- a/xen/arch/x86/cpu/mcheck/mce.c
+++ b/xen/arch/x86/cpu/mcheck/mce.c
@@ -23,6 +23,8 @@
 #include <asm/msr.h>
 
 #include "mce.h"
+#include "barrier.h"
+#include "util.h"
 
 bool_t __read_mostly mce_disabled;
 invbool_param("mce", mce_disabled);
@@ -161,8 +163,30 @@ void mce_need_clearbank_register(mce_nee
     mc_need_clearbank_scan = cbfunc;
 }
 
+
+static struct mce_softirq_barrier mce_inside_bar, mce_severity_bar;
+static struct mce_softirq_barrier mce_trap_bar;
+
+/*
+ * mce_logout_lock should only be used in the trap handler,
+ * while MCIP has not been cleared yet in the global status
+ * register. Other use is not safe, since an MCE trap can
+ * happen at any moment, which would cause lock recursion.
+ */
+static DEFINE_SPINLOCK(mce_logout_lock);
+
+static atomic_t severity_cpu = ATOMIC_INIT(-1);
+static atomic_t found_error = ATOMIC_INIT(0);
+static cpumask_t mce_fatal_cpus;
+
+const struct mca_error_handler *__read_mostly mce_dhandlers;
+const struct mca_error_handler *__read_mostly mce_uhandlers;
+unsigned int __read_mostly mce_dhandler_num;
+unsigned int __read_mostly mce_uhandler_num;
+
+
 static void mca_init_bank(enum mca_source who,
-                                         struct mc_info *mi, int bank)
+    struct mc_info *mi, int bank)
 {
     struct mcinfo_bank *mib;
 
@@ -252,8 +276,9 @@ static int mca_init_global(uint32_t flag
  * For Intel latest CPU, whether to clear the error bank status needs to
  * be judged by the callback function defined above.
  */
-mctelem_cookie_t mcheck_mca_logout(enum mca_source who, struct mca_banks *bankmask,
-                                   struct mca_summary *sp, struct mca_banks* clear_bank)
+mctelem_cookie_t
+mcheck_mca_logout(enum mca_source who, struct mca_banks *bankmask,
+                  struct mca_summary *sp, struct mca_banks *clear_bank)
 {
     uint64_t gstatus, status;
     struct mcinfo_global *mig = NULL; /* on stack */
@@ -291,7 +316,7 @@ mctelem_cookie_t mcheck_mca_logout(enum 
     /* If no mc_recovery_scan callback handler registered,
      * this error is not recoverable
      */
-    recover = (mc_recoverable_scan)? 1: 0;
+    recover = (mc_recoverable_scan) ? 1 : 0;
 
     for (i = 0; i < nr_mce_banks; i++) {
         /* Skip bank if corresponding bit in bankmask is clear */
@@ -311,15 +336,14 @@ mctelem_cookie_t mcheck_mca_logout(enum 
 
         /* If this is the first bank with valid MCA DATA, then
          * try to reserve an entry from the urgent/nonurgent queue
-         * depending on whethere we are called from an exception or
+         * depending on whether we are called from an exception or
          * a poller;  this can fail (for example dom0 may not
          * yet have consumed past telemetry). */
         if (errcnt++ == 0) {
             if ( (mctc = mctelem_reserve(which)) != NULL ) {
                 mci = mctelem_dataptr(mctc);
                 mcinfo_clear(mci);
-                mig = (struct mcinfo_global*)x86_mcinfo_reserve
-                    (mci, sizeof(struct mcinfo_global));
+                mig = x86_mcinfo_reserve(mci, sizeof(struct mcinfo_global));
                 /* mc_info should at least hold up the global information */
                 ASSERT(mig);
                 mca_init_global(mc_flags, mig);
@@ -382,227 +406,141 @@ mctelem_cookie_t mcheck_mca_logout(enum 
     return mci != NULL ? mctc : NULL; /* may be NULL */
 }
 
-#define DOM_NORMAL 0
-#define DOM0_TRAP 1
-#define DOMU_TRAP 2
-#define DOMU_KILLED 4
+static void mce_spin_lock(spinlock_t *lk)
+{
+      while (!spin_trylock(lk)) {
+              cpu_relax();
+              mce_panic_check();
+      }
+}
+
+static void mce_spin_unlock(spinlock_t *lk)
+{
+      spin_unlock(lk);
+}
+
+static enum mce_result mce_action(struct cpu_user_regs *regs,
+    mctelem_cookie_t mctc);
+
+/*
+ * Return:
+ * -1: if system can't be recovered
+ * 0: Continue to next step
+ */
+static int mce_urgent_action(struct cpu_user_regs *regs,
+                              mctelem_cookie_t mctc)
+{
+    uint64_t gstatus;
+
+    if ( mctc == NULL)
+        return 0;
+
+    gstatus = mca_rdmsr(MSR_IA32_MCG_STATUS);
+
+    /*
+     * FIXME: When RIPV = EIPV = 0, it's a little bit tricky. It may be an
+     * asynchronic error, currently we have no way to precisely locate
+     * whether the error occur at guest or hypervisor.
+     * To avoid handling error in wrong way, we treat it as unrecovered.
+     *
+     * Another unrecovered case is RIPV = 0 while in hypervisor
+     * since Xen is not pre-emptible.
+     */
+    if ( !(gstatus & MCG_STATUS_RIPV) &&
+         (!(gstatus & MCG_STATUS_EIPV) || !guest_mode(regs)) )
+        return -1;
+
+    return mce_action(regs, mctc) == MCER_RESET ? -1 : 0;
+}
 
 /* Shared #MC handler. */
 void mcheck_cmn_handler(struct cpu_user_regs *regs, long error_code,
-                        struct mca_banks *bankmask)
+    struct mca_banks *bankmask, struct mca_banks *clear_bank)
 {
-    int xen_state_lost, dom0_state_lost, domU_state_lost;
-    struct vcpu *v = current;
-    struct domain *curdom = v->domain;
-    domid_t domid = curdom->domain_id;
-    int ctx_xen, ctx_dom0, ctx_domU;
-    uint32_t dom_state = DOM_NORMAL;
+    uint64_t gstatus;
     mctelem_cookie_t mctc = NULL;
     struct mca_summary bs;
-    struct mc_info *mci = NULL;
-    int irqlocked = 0;
-    uint64_t gstatus;
-    int ripv;
 
-    /* This handler runs as interrupt gate. So IPIs from the
-     * polling service routine are defered until we're finished.
-     */
+    mce_spin_lock(&mce_logout_lock);
 
-    /* Disable interrupts for the _vcpu_. It may not re-scheduled to
-     * another physical CPU. */
-    vcpu_schedule_lock_irq(v);
-    irqlocked = 1;
+    if (clear_bank != NULL) {
+        memset( clear_bank->bank_map, 0x0,
+            sizeof(long) * BITS_TO_LONGS(clear_bank->num));
+    }
+    mctc = mcheck_mca_logout(MCA_MCE_SCAN, bankmask, &bs, clear_bank);
 
-    /* Read global status;  if it does not indicate machine check
-     * in progress then bail as long as we have a valid ip to return to. */
-    gstatus = mca_rdmsr(MSR_IA32_MCG_STATUS);
-    ripv = ((gstatus & MCG_STATUS_RIPV) != 0);
-    if (!(gstatus & MCG_STATUS_MCIP) && ripv) {
-        add_taint(TAINT_MACHINE_CHECK); /* questionable */
-        vcpu_schedule_unlock_irq(v);
-        irqlocked = 0;
-        goto cmn_handler_done;
+    if (bs.errcnt) {
+        /*
+         * Uncorrected errors must be dealt with in softirq context.
+         */
+        if (bs.uc || bs.pcc) {
+            add_taint(TAINT_MACHINE_CHECK);
+            if (mctc != NULL)
+                mctelem_defer(mctc);
+            /*
+             * For PCC=1 and can't be recovered, context is lost, so
+             * reboot now without clearing the banks, and deal with
+             * the telemetry after reboot (the MSRs are sticky)
+             */
+            if (bs.pcc || !bs.recoverable)
+                cpumask_set_cpu(smp_processor_id(), &mce_fatal_cpus);
+        } else {
+            if (mctc != NULL)
+                mctelem_commit(mctc);
+        }
+        atomic_set(&found_error, 1);
+
+        /* The last CPU will be take check/clean-up etc */
+        atomic_set(&severity_cpu, smp_processor_id());
+
+        mce_printk(MCE_CRITICAL, "MCE: clear_bank map %lx on CPU%d\n",
+                *((unsigned long*)clear_bank), smp_processor_id());
+        if (clear_bank != NULL)
+            mcheck_mca_clearbanks(clear_bank);
+    } else {
+        if (mctc != NULL)
+            mctelem_dismiss(mctc);
     }
+    mce_spin_unlock(&mce_logout_lock);
 
-    /* Go and grab error telemetry.  We must choose whether to commit
-     * for logging or dismiss the cookie that is returned, and must not
-     * reference the cookie after that action.
-     */
-    mctc = mcheck_mca_logout(MCA_MCE_HANDLER, bankmask, &bs, NULL);
-    if (mctc != NULL)
-        mci = (struct mc_info *)mctelem_dataptr(mctc);
-
-    /* Clear MCIP or another #MC will enter shutdown state */
-    gstatus &= ~MCG_STATUS_MCIP;
-    mca_wrmsr(MSR_IA32_MCG_STATUS, gstatus);
-    wmb();
-
-    /* If no valid errors and our stack is intact, we're done */
-    if (ripv && bs.errcnt == 0) {
-        vcpu_schedule_unlock_irq(v);
-        irqlocked = 0;
-        goto cmn_handler_done;
-    }
-
-    if (bs.uc || bs.pcc)
-        add_taint(TAINT_MACHINE_CHECK);
-
-    /* Machine check exceptions will usually be for UC and/or PCC errors,
-     * but it is possible to configure machine check for some classes
-     * of corrected error.
-     *
-     * UC errors could compromise any domain or the hypervisor
-     * itself - for example a cache writeback of modified data that
-     * turned out to be bad could be for data belonging to anyone, not
-     * just the current domain.  In the absence of known data poisoning
-     * to prevent consumption of such bad data in the system we regard
-     * all UC errors as terminal.  It may be possible to attempt some
-     * heuristics based on the address affected, which guests have
-     * mappings to that mfn etc.
-     *
-     * PCC errors apply to the current context.
-     *
-     * If MCG_STATUS indicates !RIPV then even a #MC that is not UC
-     * and not PCC is terminal - the return instruction pointer
-     * pushed onto the stack is bogus.  If the interrupt context is
-     * the hypervisor or dom0 the game is over, otherwise we can
-     * limit the impact to a single domU but only if we trampoline
-     * somewhere safely - we can't return and unwind the stack.
-     * Since there is no trampoline in place we will treat !RIPV
-     * as terminal for any context.
-     */
-    ctx_xen = SEG_PL(regs->cs) == 0;
-    ctx_dom0 = !ctx_xen && (domid == 0);
-    ctx_domU = !ctx_xen && !ctx_dom0;
-
-    xen_state_lost = bs.uc != 0 || (ctx_xen && (bs.pcc || !ripv)) ||
-        !ripv;
-    dom0_state_lost = bs.uc != 0 || (ctx_dom0 && (bs.pcc || !ripv));
-    domU_state_lost = bs.uc != 0 || (ctx_domU && (bs.pcc || !ripv));
-
-    if (xen_state_lost) {
-        /* Now we are going to panic anyway. Allow interrupts, so that
-         * printk on serial console can work. */
-        vcpu_schedule_unlock_irq(v);
-        irqlocked = 0;
-
-        printk("Terminal machine check exception occurred in "
-               "hypervisor context.\n");
-
-        /* If MCG_STATUS_EIPV indicates, the IP on the stack is related
-         * to the error then it makes sense to print a stack trace.
-         * That can be useful for more detailed error analysis and/or
-         * error case studies to figure out, if we can clear
-         * xen_impacted and kill a DomU instead
-         * (i.e. if a guest only control structure is affected, but then
-         * we must ensure the bad pages are not re-used again).
-         */
-        if (bs.eipv & MCG_STATUS_EIPV) {
-            printk("MCE: Instruction Pointer is related to the "
-                   "error, therefore print the execution state.\n");
-            show_execution_state(regs);
-        }
-
-        /* Commit the telemetry so that panic flow can find it. */
-        if (mctc != NULL) {
-            x86_mcinfo_dump(mci);
-            mctelem_commit(mctc);
-        }
-        mc_panic("Hypervisor state lost due to machine check "
-                 "exception.\n");
-        /*NOTREACHED*/
-    }
+    mce_barrier_enter(&mce_trap_bar);
+    if ( mctc != NULL && mce_urgent_action(regs, mctc))
+        cpumask_set_cpu(smp_processor_id(), &mce_fatal_cpus);
+    mce_barrier_exit(&mce_trap_bar);
 
     /*
-     * Xen hypervisor state is intact.  If dom0 state is lost then
-     * give it a chance to decide what to do if it has registered
-     * a handler for this event, otherwise panic.
-     *
-     * XXFM Could add some Solaris dom0 contract kill here?
+     * Wait until everybody has processed the trap.
      */
-    if (dom0_state_lost) {
-        if (dom0 && dom0->max_vcpus && dom0->vcpu[0] &&
-            guest_has_trap_callback(dom0, 0, TRAP_machine_check)) {
-            dom_state = DOM0_TRAP;
-            send_guest_trap(dom0, 0, TRAP_machine_check);
-            /* XXFM case of return with !ripv ??? */
-        } else {
-            /* Commit telemetry for panic flow. */
-            if (mctc != NULL) {
-                x86_mcinfo_dump(mci);
-                mctelem_commit(mctc);
-            }
-            mc_panic("Dom0 state lost due to machine check "
-                     "exception\n");
-            /*NOTREACHED*/
+    mce_barrier_enter(&mce_trap_bar);
+    if (atomic_read(&severity_cpu) == smp_processor_id())
+    {
+        /* According to SDM, if no error bank found on any cpus,
+         * something unexpected happening, we can't do any
+         * recovery job but to reset the system.
+         */
+        if (atomic_read(&found_error) == 0)
+            mc_panic("MCE: No CPU found valid MCE, need reset\n");
+        if (!cpumask_empty(&mce_fatal_cpus))
+        {
+            char *ebufp, ebuf[96] = "MCE: Fatal error happened on CPUs ";
+            ebufp = ebuf + strlen(ebuf);
+            cpumask_scnprintf(ebufp, 95 - strlen(ebuf), &mce_fatal_cpus);
+            mc_panic(ebuf);
         }
+        atomic_set(&found_error, 0);
     }
+    mce_barrier_exit(&mce_trap_bar); 
 
-    /*
-     * If a domU has lost state then send it a trap if it has registered
-     * a handler, otherwise crash the domain.
-     * XXFM Revisit this functionality.
-     */
-    if (domU_state_lost) {
-        if (guest_has_trap_callback(v->domain, v->vcpu_id,
-                                    TRAP_machine_check)) {
-            dom_state = DOMU_TRAP;
-            send_guest_trap(curdom, v->vcpu_id,
-                            TRAP_machine_check);
-        } else {
-            dom_state = DOMU_KILLED;
-            /* Enable interrupts. This basically results in
-             * calling sti on the *physical* cpu. But after
-             * domain_crash() the vcpu pointer is invalid.
-             * Therefore, we must unlock the irqs before killing
-             * it. */
-            vcpu_schedule_unlock_irq(v);
-            irqlocked = 0;
+    /* Clear flags after above fatal check */
+    mce_barrier_enter(&mce_trap_bar);
+    gstatus = mca_rdmsr(MSR_IA32_MCG_STATUS);
+    if ((gstatus & MCG_STATUS_MCIP) != 0) {
+        mce_printk(MCE_CRITICAL, "MCE: Clear MCIP@ last step");
+        mca_wrmsr(MSR_IA32_MCG_STATUS, gstatus & ~MCG_STATUS_MCIP);
+    }
+    mce_barrier_exit(&mce_trap_bar);
 
-            /* DomU is impacted. Kill it and continue. */
-            domain_crash(curdom);
-        }
-    }
-
-    switch (dom_state) {
-    case DOM0_TRAP:
-    case DOMU_TRAP:
-        /* Enable interrupts. */
-        vcpu_schedule_unlock_irq(v);
-        irqlocked = 0;
-
-        /* guest softirqs and event callbacks are scheduled
-         * immediately after this handler exits. */
-        break;
-    case DOMU_KILLED:
-        /* Nothing to do here. */
-        break;
-
-    case DOM_NORMAL:
-        vcpu_schedule_unlock_irq(v);
-        irqlocked = 0;
-        break;
-    }
-
- cmn_handler_done:
-    BUG_ON(irqlocked);
-    BUG_ON(!ripv);
-
-    if (bs.errcnt) {
-        /* Not panicing, so forward telemetry to dom0 now if it
-         * is interested. */
-        if (dom0_vmce_enabled()) {
-            if (mctc != NULL)
-                mctelem_commit(mctc);
-            send_global_virq(VIRQ_MCA);
-        } else {
-            x86_mcinfo_dump(mci);
-            if (mctc != NULL)
-                mctelem_dismiss(mctc);
-        }
-    } else if (mctc != NULL) {
-        mctelem_dismiss(mctc);
-    }
+    raise_softirq(MACHINE_CHECK_SOFTIRQ);
 }
 
 void mcheck_mca_clearbanks(struct mca_banks *bankmask)
@@ -1628,3 +1566,191 @@ void mc_panic(char *s)
     mc_panic_dump();
     panic("HARDWARE ERROR");
 }
+
+/* Machine Check owner judge algorithm:
+ * When error happens, all cpus serially read its msr banks.
+ * The first CPU who fetches the error bank's info will clear
+ * this bank. Later readers can't get any information again.
+ * The first CPU is the actual mce_owner
+ *
+ * For Fatal (pcc=1) error, it might cause machine crash
+ * before we're able to log. For avoiding log missing, we adopt two
+ * round scanning:
+ * Round1: simply scan. If found pcc = 1 or ripv = 0, simply reset.
+ * All MCE banks are sticky, when boot up, MCE polling mechanism
+ * will help to collect and log those MCE errors.
+ * Round2: Do all MCE processing logic as normal.
+ */
+
+/* Maybe called in MCE context, no lock, no printk */
+static enum mce_result mce_action(struct cpu_user_regs *regs,
+                      mctelem_cookie_t mctc)
+{
+    struct mc_info *local_mi;
+    enum mce_result bank_result = MCER_NOERROR;
+    enum mce_result worst_result = MCER_NOERROR;
+    struct mcinfo_common *mic = NULL;
+    struct mca_binfo binfo;
+    const struct mca_error_handler *handlers = mce_dhandlers;
+    unsigned int i, handler_num = mce_dhandler_num;
+
+    /* When in mce context, regs is valid */
+    if (regs)
+    {
+        handler_num = mce_uhandler_num;
+        handlers = mce_uhandlers;
+    }
+
+    /* At least a default handler should be registerd */
+    ASSERT(handler_num);
+
+    local_mi = (struct mc_info*)mctelem_dataptr(mctc);
+    x86_mcinfo_lookup(mic, local_mi, MC_TYPE_GLOBAL);
+    if (mic == NULL) {
+        printk(KERN_ERR "MCE: get local buffer entry failed\n ");
+        return MCER_CONTINUE;
+    }
+
+    memset(&binfo, 0, sizeof(binfo));
+    binfo.mig = (struct mcinfo_global *)mic;
+    binfo.mi = local_mi;
+
+    /* Processing bank information */
+    x86_mcinfo_lookup(mic, local_mi, MC_TYPE_BANK);
+
+    for ( ; bank_result != MCER_RESET && mic && mic->size;
+          mic = x86_mcinfo_next(mic) )
+    {
+        if (mic->type != MC_TYPE_BANK) {
+            continue;
+        }
+        binfo.mib = (struct mcinfo_bank*)mic;
+        binfo.bank = binfo.mib->mc_bank;
+        bank_result = MCER_NOERROR;
+        for ( i = 0; i < handler_num; i++ ) {
+            if (handlers[i].owned_error(binfo.mib->mc_status))
+            {
+                handlers[i].recovery_handler(&binfo, &bank_result, regs);
+                if (worst_result < bank_result)
+                    worst_result = bank_result;
+                break;
+            }
+        }
+        ASSERT(i != handler_num);
+    }
+
+    return worst_result;
+}
+
+/*
+ * Called from mctelem_process_deferred. Return 1 if the telemetry
+ * should be committed for dom0 consumption, 0 if it should be
+ * dismissed.
+ */
+static int mce_delayed_action(mctelem_cookie_t mctc)
+{
+    enum mce_result result;
+    int ret = 0;
+
+    result = mce_action(NULL, mctc);
+
+    switch (result)
+    {
+    case MCER_RESET:
+        dprintk(XENLOG_ERR, "MCE delayed action failed\n");
+        is_mc_panic = 1;
+        x86_mcinfo_dump(mctelem_dataptr(mctc));
+        panic("MCE: Software recovery failed for the UCR\n");
+        break;
+    case MCER_RECOVERED:
+        dprintk(XENLOG_INFO, "MCE: Error is successfully recovered\n");
+        ret  = 1;
+        break;
+    case MCER_CONTINUE:
+        dprintk(XENLOG_INFO, "MCE: Error can't be recovered, "
+            "system is tainted\n");
+        x86_mcinfo_dump(mctelem_dataptr(mctc));
+        ret = 1;
+        break;
+    default:
+        ret = 0;
+        break;
+    }
+    return ret;
+}
+
+/* Softirq Handler for this MCE# processing */
+static void mce_softirq(void)
+{
+    int cpu = smp_processor_id();
+    unsigned int workcpu;
+
+    mce_printk(MCE_VERBOSE, "CPU%d enter softirq\n", cpu);
+
+    mce_barrier_enter(&mce_inside_bar);
+
+    /*
+     * Everybody is here. Now let's see who gets to do the
+     * recovery work. Right now we just see if there's a CPU
+     * that did not have any problems, and pick that one.
+     *
+     * First, just set a default value: the last CPU who reaches this
+     * will overwrite the value and become the default.
+     */
+
+    atomic_set(&severity_cpu, cpu);
+
+    mce_barrier_enter(&mce_severity_bar);
+    if (!mctelem_has_deferred(cpu))
+        atomic_set(&severity_cpu, cpu);
+    mce_barrier_exit(&mce_severity_bar);
+
+    /* We choose severity_cpu for further processing */
+    if (atomic_read(&severity_cpu) == cpu) {
+
+        mce_printk(MCE_VERBOSE, "CPU%d handling errors\n", cpu);
+
+        /* Step1: Fill DOM0 LOG buffer, vMCE injection buffer and
+         * vMCE MSRs virtualization buffer
+         */
+        for_each_online_cpu(workcpu) {
+            mctelem_process_deferred(workcpu, mce_delayed_action);
+        }
+
+        /* Step2: Send Log to DOM0 through vIRQ */
+        if (dom0_vmce_enabled()) {
+            mce_printk(MCE_VERBOSE, "MCE: send MCE# to DOM0 through virq\n");
+            send_global_virq(VIRQ_MCA);
+        }
+    }
+
+    mce_barrier_exit(&mce_inside_bar);
+}
+
+/* Machine Check owner judge algorithm:
+ * When error happens, all cpus serially read its msr banks.
+ * The first CPU who fetches the error bank's info will clear
+ * this bank. Later readers can't get any infor again.
+ * The first CPU is the actual mce_owner
+ *
+ * For Fatal (pcc=1) error, it might cause machine crash
+ * before we're able to log. For avoiding log missing, we adopt two
+ * round scanning:
+ * Round1: simply scan. If found pcc = 1 or ripv = 0, simply reset.
+ * All MCE banks are sticky, when boot up, MCE polling mechanism
+ * will help to collect and log those MCE errors.
+ * Round2: Do all MCE processing logic as normal.
+ */
+void mce_handler_init(void)
+{
+    if (smp_processor_id() != 0)
+        return;
+
+    /* callback register, do we really need so many callback? */
+    /* mce handler data initialization */
+    mce_barrier_init(&mce_inside_bar);
+    mce_barrier_init(&mce_severity_bar);
+    mce_barrier_init(&mce_trap_bar);
+    spin_lock_init(&mce_logout_lock);
+    open_softirq(MACHINE_CHECK_SOFTIRQ, mce_softirq);
+}
diff -r 9592e8808109 -r 1ff906461666 xen/arch/x86/cpu/mcheck/mce.h
--- a/xen/arch/x86/cpu/mcheck/mce.h
+++ b/xen/arch/x86/cpu/mcheck/mce.h
@@ -78,7 +78,8 @@ extern void x86_mce_vector_register(x86_
 
 /* Common generic MCE handler that implementations may nominate
  * via x86_mce_vector_register. */
-extern void mcheck_cmn_handler(struct cpu_user_regs *, long, struct mca_banks *);
+extern void mcheck_cmn_handler(struct cpu_user_regs *, long,
+    struct mca_banks *, struct mca_banks *);
 
 /* Register a handler for judging whether mce is recoverable. */
 typedef int (*mce_recoverable_t)(u64 status);
@@ -166,16 +167,28 @@ void *x86_mcinfo_reserve(struct mc_info 
 void x86_mcinfo_dump(struct mc_info *mi);
 
 int fill_vmsr_data(struct mcinfo_bank *mc_bank, struct domain *d,
-        uint64_t gstatus);
+    uint64_t gstatus);
 int inject_vmce(struct domain *d);
-int vmce_domain_inject(struct mcinfo_bank *bank, struct domain *d, struct mcinfo_global *global);
+int vmce_domain_inject(struct mcinfo_bank *bank, struct domain *d,
+    struct mcinfo_global *global);
 
 static inline int mce_vendor_bank_msr(const struct vcpu *v, uint32_t msr)
 {
-    if ( boot_cpu_data.x86_vendor == X86_VENDOR_INTEL &&
-         msr >= MSR_IA32_MC0_CTL2 &&
-         msr < MSR_IA32_MCx_CTL2(v->arch.mcg_cap & MCG_CAP_COUNT) )
-          return 1;
+    switch (boot_cpu_data.x86_vendor) {
+    case X86_VENDOR_INTEL:
+        if (msr >= MSR_IA32_MC0_CTL2 &&
+            msr < MSR_IA32_MCx_CTL2(v->arch.mcg_cap & MCG_CAP_COUNT) )
+            return 1;
+        break;
+    case X86_VENDOR_AMD:
+        switch (msr) {
+        case MSR_F10_MC4_MISC1:
+        case MSR_F10_MC4_MISC2:
+        case MSR_F10_MC4_MISC3:
+            return 1;
+        }
+        break;
+    }
     return 0;
 }
 
@@ -188,27 +201,35 @@ static inline int mce_bank_msr(const str
     return 0;
 }
 
+/* MC softirq */
+void mce_handler_init(void);
+
+extern const struct mca_error_handler *mce_dhandlers;
+extern const struct mca_error_handler *mce_uhandlers;
+extern unsigned int mce_dhandler_num;
+extern unsigned int mce_uhandler_num;
+
 /* Fields are zero when not available */
 struct mce {
-    __u64 status;
-    __u64 misc;
-    __u64 addr;
-    __u64 mcgstatus;
-    __u64 ip;
-    __u64 tsc;      /* cpu time stamp counter */
-    __u64 time;     /* wall time_t when error was detected */
-    __u8  cpuvendor;        /* cpu vendor as encoded in system.h */
-    __u8  inject_flags;     /* software inject flags */
-    __u16  pad;
-    __u32 cpuid;    /* CPUID 1 EAX */
-    __u8  cs;               /* code segment */
-    __u8  bank;     /* machine check bank */
-    __u8  cpu;      /* cpu number; obsolete; use extcpu now */
-    __u8  finished;   /* entry is valid */
-    __u32 extcpu;   /* linux cpu number that detected the error */
-    __u32 socketid; /* CPU socket ID */
-    __u32 apicid;   /* CPU initial apic ID */
-    __u64 mcgcap;   /* MCGCAP MSR: machine check capabilities of CPU */
+    uint64_t status;
+    uint64_t misc;
+    uint64_t addr;
+    uint64_t mcgstatus;
+    uint64_t ip;
+    uint64_t tsc;      /* cpu time stamp counter */
+    uint64_t time;     /* wall time_t when error was detected */
+    uint8_t  cpuvendor;        /* cpu vendor as encoded in system.h */
+    uint8_t  inject_flags;     /* software inject flags */
+    uint16_t pad;
+    uint32_t cpuid;    /* CPUID 1 EAX */
+    uint8_t  cs;       /* code segment */
+    uint8_t  bank;     /* machine check bank */
+    uint8_t  cpu;      /* cpu number; obsolete; use extcpu now */
+    uint8_t  finished; /* entry is valid */
+    uint32_t extcpu;   /* linux cpu number that detected the error */
+    uint32_t socketid; /* CPU socket ID */
+    uint32_t apicid;   /* CPU initial apic ID */
+    uint64_t mcgcap;   /* MCGCAP MSR: machine check capabilities of CPU */
 };
 
 extern int apei_write_mce(struct mce *m);
diff -r 9592e8808109 -r 1ff906461666 xen/arch/x86/cpu/mcheck/mce_intel.c
--- a/xen/arch/x86/cpu/mcheck/mce_intel.c
+++ b/xen/arch/x86/cpu/mcheck/mce_intel.c
@@ -166,244 +166,6 @@ static void intel_init_thermal(struct cp
 }
 #endif /* CONFIG_X86_MCE_THERMAL */
 
-static struct mce_softirq_barrier mce_inside_bar, mce_severity_bar;
-static struct mce_softirq_barrier mce_trap_bar;
-
-/*
- * mce_logout_lock should only be used in the trap handler,
- * while MCIP has not been cleared yet in the global status
- * register. Other use is not safe, since an MCE trap can
- * happen at any moment, which would cause lock recursion.
- */
-static DEFINE_SPINLOCK(mce_logout_lock);
-
-static atomic_t severity_cpu = ATOMIC_INIT(-1);
-static atomic_t found_error = ATOMIC_INIT(0);
-static cpumask_t mce_fatal_cpus;
-
-static const struct mca_error_handler *__read_mostly mce_dhandlers;
-static const struct mca_error_handler *__read_mostly mce_uhandlers;
-static unsigned int __read_mostly mce_dhandler_num;
-static unsigned int __read_mostly mce_uhandler_num;
-
-/* Maybe called in MCE context, no lock, no printk */
-static enum mce_result mce_action(struct cpu_user_regs *regs,
-                      mctelem_cookie_t mctc)
-{
-    struct mc_info *local_mi;
-    enum mce_result bank_result = MCER_NOERROR;
-    enum mce_result worst_result = MCER_NOERROR;
-    struct mcinfo_common *mic = NULL;
-    struct mca_binfo binfo;
-    const struct mca_error_handler *handlers = mce_dhandlers;
-    unsigned int i, handler_num = mce_dhandler_num;
-
-    /* When in mce context, regs is valid */
-    if (regs)
-    {
-        handler_num = mce_uhandler_num;
-        handlers = mce_uhandlers;
-    }
-
-    /* At least a default handler should be registerd */
-    ASSERT(handler_num);
-
-    local_mi = (struct mc_info*)mctelem_dataptr(mctc);
-    x86_mcinfo_lookup(mic, local_mi, MC_TYPE_GLOBAL);
-    if (mic == NULL) {
-        printk(KERN_ERR "MCE: get local buffer entry failed\n ");
-        return MCER_CONTINUE;
-    }
-
-    memset(&binfo, 0, sizeof(binfo));
-    binfo.mig = (struct mcinfo_global *)mic;
-    binfo.mi = local_mi;
-
-    /* Processing bank information */
-    x86_mcinfo_lookup(mic, local_mi, MC_TYPE_BANK);
-
-    for ( ; bank_result != MCER_RESET && mic && mic->size;
-          mic = x86_mcinfo_next(mic) )
-    {
-        if (mic->type != MC_TYPE_BANK) {
-            continue;
-        }
-        binfo.mib = (struct mcinfo_bank*)mic;
-        binfo.bank = binfo.mib->mc_bank;
-        bank_result = MCER_NOERROR;
-        for ( i = 0; i < handler_num; i++ ) {
-            if (handlers[i].owned_error(binfo.mib->mc_status))
-            {
-                handlers[i].recovery_handler(&binfo, &bank_result, regs);
-                if (worst_result < bank_result)
-                    worst_result = bank_result;
-                break;
-            }
-        }
-        ASSERT(i != handler_num);
-    }
-
-    return worst_result;
-}
-
-/*
- * Called from mctelem_process_deferred. Return 1 if the telemetry
- * should be committed for dom0 consumption, 0 if it should be
- * dismissed.
- */
-static int mce_delayed_action(mctelem_cookie_t mctc)
-{
-    enum mce_result result;
-    int ret = 0;
-
-    result = mce_action(NULL, mctc);
-
-    switch (result)
-    {
-    case MCER_RESET:
-        dprintk(XENLOG_ERR, "MCE delayed action failed\n");
-        is_mc_panic = 1;
-        x86_mcinfo_dump(mctelem_dataptr(mctc));
-        panic("MCE: Software recovery failed for the UCR\n");
-        break;
-    case MCER_RECOVERED:
-        dprintk(XENLOG_INFO, "MCE: Error is successfully recovered\n");
-        ret  = 1;
-        break;
-    case MCER_CONTINUE:
-        dprintk(XENLOG_INFO, "MCE: Error can't be recovered, "
-            "system is tainted\n");
-        x86_mcinfo_dump(mctelem_dataptr(mctc));
-        ret = 1;
-        break;
-    default:
-        ret = 0;
-        break;
-    }
-    return ret;
-}
-
-/* Softirq Handler for this MCE# processing */
-static void mce_softirq(void)
-{
-    int cpu = smp_processor_id();
-    unsigned int workcpu;
-
-    mce_printk(MCE_VERBOSE, "CPU%d enter softirq\n", cpu);
-
-    mce_barrier_enter(&mce_inside_bar);
-
-    /*
-     * Everybody is here. Now let's see who gets to do the
-     * recovery work. Right now we just see if there's a CPU
-     * that did not have any problems, and pick that one.
-     *
-     * First, just set a default value: the last CPU who reaches this
-     * will overwrite the value and become the default.
-     */
-
-    atomic_set(&severity_cpu, cpu);
-
-    mce_barrier_enter(&mce_severity_bar);
-    if (!mctelem_has_deferred(cpu))
-        atomic_set(&severity_cpu, cpu);
-    mce_barrier_exit(&mce_severity_bar);
-
-    /* We choose severity_cpu for further processing */
-    if (atomic_read(&severity_cpu) == cpu) {
-
-        mce_printk(MCE_VERBOSE, "CPU%d handling errors\n", cpu);
-
-        /* Step1: Fill DOM0 LOG buffer, vMCE injection buffer and
-         * vMCE MSRs virtualization buffer
-         */
-        for_each_online_cpu(workcpu) {
-            mctelem_process_deferred(workcpu, mce_delayed_action);
-        }
-
-        /* Step2: Send Log to DOM0 through vIRQ */
-        if (dom0_vmce_enabled()) {
-            mce_printk(MCE_VERBOSE, "MCE: send MCE# to DOM0 through virq\n");
-            send_global_virq(VIRQ_MCA);
-        }
-    }
-
-    mce_barrier_exit(&mce_inside_bar);
-}
-
-/*
- * Return:
- * -1: if system can't be recoved
- * 0: Continoue to next step
- */
-static int mce_urgent_action(struct cpu_user_regs *regs,
-                              mctelem_cookie_t mctc)
-{
-    uint64_t gstatus;
-
-    if ( mctc == NULL)
-        return 0;
-
-    gstatus = mca_rdmsr(MSR_IA32_MCG_STATUS);
-
-    /*
-     * FIXME: When RIPV = EIPV = 0, it's a little bit tricky. It may be an
-     * asynchronic error, currently we have no way to precisely locate
-     * whether the error occur at guest or hypervisor.
-     * To avoid handling error in wrong way, we treat it as unrecovered.
-     *
-     * Another unrecovered case is RIPV = 0 while in hypervisor
-     * since Xen is not pre-emptible.
-     */
-    if ( !(gstatus & MCG_STATUS_RIPV) &&
-         (!(gstatus & MCG_STATUS_EIPV) || !guest_mode(regs)) )
-        return -1;
-
-    return mce_action(regs, mctc) == MCER_RESET ? -1 : 0;
-}
-
-/* Machine Check owner judge algorithm:
- * When error happens, all cpus serially read its msr banks.
- * The first CPU who fetches the error bank's info will clear
- * this bank. Later readers can't get any infor again.
- * The first CPU is the actual mce_owner
- *
- * For Fatal (pcc=1) error, it might cause machine crash
- * before we're able to log. For avoiding log missing, we adopt two
- * round scanning:
- * Round1: simply scan. If found pcc = 1 or ripv = 0, simply reset.
- * All MCE banks are sticky, when boot up, MCE polling mechanism
- * will help to collect and log those MCE errors.
- * Round2: Do all MCE processing logic as normal.
- */
-
-static void mce_handler_init(void)
-{
-    if (smp_processor_id() != 0)
-        return;
-
-    /* callback register, do we really need so many callback? */
-    /* mce handler data initialization */
-    mce_barrier_init(&mce_inside_bar);
-    mce_barrier_init(&mce_severity_bar);
-    mce_barrier_init(&mce_trap_bar);
-    spin_lock_init(&mce_logout_lock);
-    open_softirq(MACHINE_CHECK_SOFTIRQ, mce_softirq);
-}
-
-static void mce_spin_lock(spinlock_t *lk)
-{
-      while (!spin_trylock(lk)) {
-              cpu_relax();
-              mce_panic_check();
-      }
-}
-
-static void mce_spin_unlock(spinlock_t *lk)
-{
-      spin_unlock(lk);
-}
-
 /* Intel MCE handler */
 static inline void intel_get_extended_msr(struct mcinfo_extended *ext, u32 msr)
 {
@@ -731,88 +493,8 @@ static const struct mca_error_handler in
 
 static void intel_machine_check(struct cpu_user_regs * regs, long error_code)
 {
-    uint64_t gstatus;
-    mctelem_cookie_t mctc = NULL;
-    struct mca_summary bs;
-    struct mca_banks *clear_bank;
-
-    mce_spin_lock(&mce_logout_lock);
-
-    clear_bank = __get_cpu_var(mce_clear_banks);
-    memset( clear_bank->bank_map, 0x0,
-        sizeof(long) * BITS_TO_LONGS(clear_bank->num));
-    mctc = mcheck_mca_logout(MCA_MCE_SCAN, mca_allbanks, &bs, clear_bank);
-
-    if (bs.errcnt) {
-        /*
-         * Uncorrected errors must be dealth with in softirq context.
-         */
-        if (bs.uc || bs.pcc) {
-            add_taint(TAINT_MACHINE_CHECK);
-            if (mctc != NULL)
-                mctelem_defer(mctc);
-            /*
-             * For PCC=1 and can't be recovered, context is lost, so reboot now without
-             * clearing  the banks, and deal with the telemetry after reboot
-             * (the MSRs are sticky)
-             */
-            if (bs.pcc || !bs.recoverable)
-                cpumask_set_cpu(smp_processor_id(), &mce_fatal_cpus);
-        } else {
-            if (mctc != NULL)
-                mctelem_commit(mctc);
-        }
-        atomic_set(&found_error, 1);
-
-        /* The last CPU will be take check/clean-up etc */
-        atomic_set(&severity_cpu, smp_processor_id());
-
-        mce_printk(MCE_CRITICAL, "MCE: clear_bank map %lx on CPU%d\n",
-                *((unsigned long*)clear_bank), smp_processor_id());
-        mcheck_mca_clearbanks(clear_bank);
-    } else {
-        if (mctc != NULL)
-            mctelem_dismiss(mctc);
-    }
-    mce_spin_unlock(&mce_logout_lock);
-
-    mce_barrier_enter(&mce_trap_bar);
-    if ( mctc != NULL && mce_urgent_action(regs, mctc))
-        cpumask_set_cpu(smp_processor_id(), &mce_fatal_cpus);
-    mce_barrier_exit(&mce_trap_bar);
-    /*
-     * Wait until everybody has processed the trap.
-     */
-    mce_barrier_enter(&mce_trap_bar);
-    if (atomic_read(&severity_cpu) == smp_processor_id())
-    {
-        /* According to SDM, if no error bank found on any cpus,
-         * something unexpected happening, we can't do any
-         * recovery job but to reset the system.
-         */
-        if (atomic_read(&found_error) == 0)
-            mc_panic("MCE: No CPU found valid MCE, need reset\n");
-        if (!cpumask_empty(&mce_fatal_cpus))
-        {
-            char *ebufp, ebuf[96] = "MCE: Fatal error happened on CPUs ";
-            ebufp = ebuf + strlen(ebuf);
-            cpumask_scnprintf(ebufp, 95 - strlen(ebuf), &mce_fatal_cpus);
-            mc_panic(ebuf);
-        }
-        atomic_set(&found_error, 0);
-    }
-    mce_barrier_exit(&mce_trap_bar);
-
-    /* Clear flags after above fatal check */
-    mce_barrier_enter(&mce_trap_bar);
-    gstatus = mca_rdmsr(MSR_IA32_MCG_STATUS);
-    if ((gstatus & MCG_STATUS_MCIP) != 0) {
-        mce_printk(MCE_CRITICAL, "MCE: Clear MCIP@ last step");
-        mca_wrmsr(MSR_IA32_MCG_STATUS, gstatus & ~MCG_STATUS_MCIP);
-    }
-    mce_barrier_exit(&mce_trap_bar);
-
-    raise_softirq(MACHINE_CHECK_SOFTIRQ);
+    mcheck_cmn_handler(regs, error_code, mca_allbanks,
+        __get_cpu_var(mce_clear_banks));
 }
 
 /* According to MCA OS writer guide, CMCI handler need to clear bank when
diff -r 9592e8808109 -r 1ff906461666 xen/arch/x86/cpu/mcheck/x86_mca.h
--- a/xen/arch/x86/cpu/mcheck/x86_mca.h
+++ b/xen/arch/x86/cpu/mcheck/x86_mca.h
@@ -32,11 +32,11 @@
 /* Bitfield of the MSR_IA32_MCG_CAP register */
 #define MCG_CAP_COUNT           0x00000000000000ffULL
 #define MCG_CTL_P               (1ULL<<8)
-#define MCG_EXT_P               (1ULL<<9)
-#define MCG_CMCI_P              (1ULL<<10)
-#define MCG_TES_P               (1ULL<<11)
-#define MCG_EXT_CNT             16
-#define MCG_SER_P               (1ULL<<24)
+#define MCG_EXT_P               (1ULL<<9)  /* Intel specific */
+#define MCG_CMCI_P              (1ULL<<10) /* Intel specific */
+#define MCG_TES_P               (1ULL<<11) /* Intel specific */
+#define MCG_EXT_CNT             16         /* Intel specific */
+#define MCG_SER_P               (1ULL<<24) /* Intel specific */
 /* Other bits are reserved */
 
 /* Bitfield of the MSR_IA32_MCG_STATUS register */
@@ -53,9 +53,9 @@
 /* Other information */
 #define MCi_STATUS_OTHER        0x01ffffff00000000ULL
 /* Action Required flag */
-#define MCi_STATUS_AR           0x0080000000000000ULL
+#define MCi_STATUS_AR           0x0080000000000000ULL  /* Intel specific */
 /* Signaling flag */
-#define MCi_STATUS_S            0x0100000000000000ULL
+#define MCi_STATUS_S            0x0100000000000000ULL  /* Intel specific */
 /* processor context corrupt */
 #define MCi_STATUS_PCC          0x0200000000000000ULL
 /* MSR_K8_MCi_ADDR register valid */
@@ -100,7 +100,7 @@ struct mca_banks
     unsigned long *bank_map;
 };
 
-static inline void mcabanks_clear(int bit, struct mca_banks *banks)    \
+static inline void mcabanks_clear(int bit, struct mca_banks *banks)
 {
     if (!banks || !banks->bank_map || bit >= banks->num)
         return ;
@@ -125,7 +125,7 @@ struct mca_banks *mcabanks_alloc(void);
 void mcabanks_free(struct mca_banks *banks);
 extern struct mca_banks *mca_allbanks;
 
-/*Keep bank so that we can get staus even if mib is NULL */
+/* Keep bank so that we can get status even if mib is NULL */
 struct mca_binfo {
     int bank;
     struct mcinfo_global *mig;
@@ -138,7 +138,7 @@ enum mce_result
 {
     MCER_NOERROR,
     MCER_RECOVERED,
-    /* Not recoverd, but can continue */
+    /* Not recovered, but can continue */
     MCER_CONTINUE,
     MCER_RESET,
 };
@@ -149,7 +149,7 @@ struct mca_error_handler
      * identified by mca_code. Otherwise, we might need to have
      * a seperate function to decode the corresponding actions
      * for the particular mca error later.
-    */
+     */
     int (*owned_error)(uint64_t status);
     void (*recovery_handler)(struct mca_binfo *binfo,
                     enum mce_result *result, struct cpu_user_regs *regs);

--------------020706030801040308010207
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--------------020706030801040308010207--


From xen-devel-bounces@lists.xen.org Tue Sep 11 13:22:22 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 2012 13: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 1TBQPr-0002ot-Ut; Tue, 11 Sep 2012 13:22:11 +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 1TBQPq-0002oh-F3
	for xen-devel@lists.xen.org; Tue, 11 Sep 2012 13:22:10 +0000
Received: from [85.158.143.99:13550] by server-3.bemta-4.messagelabs.com id
	05/F4-08232-10B3F405; Tue, 11 Sep 2012 13:22:09 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-7.tower-216.messagelabs.com!1347369699!26368182!1
X-Originating-IP: [63.239.67.9]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29710 invoked from network); 11 Sep 2012 13:21:40 -0000
Received: from emvm-gh1-uea08.nsa.gov (HELO nsa.gov) (63.239.67.9)
	by server-7.tower-216.messagelabs.com with SMTP;
	11 Sep 2012 13:21:40 -0000
X-TM-IMSS-Message-ID: <342a1e5e000f2be2@nsa.gov>
Received: from tarius.tycho.ncsc.mil ([144.51.3.1]) by nsa.gov ([63.239.67.9])
	with ESMTP (TREND IMSS SMTP Service 7.1) id 342a1e5e000f2be2 ;
	Tue, 11 Sep 2012 09:21:29 -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 q8BDLZSu017783; 
	Tue, 11 Sep 2012 09:21:35 -0400
Message-ID: <504F3ADF.8030402@tycho.nsa.gov>
Date: Tue, 11 Sep 2012 09:21:35 -0400
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Organization: National Security Agency
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120828 Thunderbird/15.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <CC741177.4B381%keir@xen.org> <504E5760.5070605@tycho.nsa.gov>
	<504F0DE3020000780009A727@nat28.tlf.novell.com>
In-Reply-To: <504F0DE3020000780009A727@nat28.tlf.novell.com>
Cc: Keir Fraser <keir@xen.org>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH v2] Merge IS_PRIV checks into XSM hooks
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 09/11/2012 04:09 AM, Jan Beulich wrote:
>>>> On 10.09.12 at 23:10, Daniel De Graaf <dgdegra@tycho.nsa.gov> wrote:
>> On 09/10/2012 04:51 PM, Keir Fraser wrote:
>>> On 10/09/2012 20:48, "Daniel De Graaf" <dgdegra@tycho.nsa.gov> wrote:
>>>
>>>> Overall, this series should not change the behavior of Xen when XSM is
>>>> not enabled; however, in some cases, the exact errors that are returned
>>>> will be different because security checks have been moved below validity
>>>> checks. Also, once applied, newly introduced domctls and sysctls will
>>>> not automatically be guarded by IS_PRIV checks - they will need to add
>>>> their own permission checking code.
>>>
>>> How do we guard against accidentally forgetting to do this?
>>
>> The same way you guard against it when adding a new hypercall: when adding
>> new functionality that needs access checks, also add the access checks.
> 
> Except that previously the access check was done centrally at the
> top of do_domctl(), so newly added sub-functions didn't need to
> worry.
> 
> Jan
> 

One addition I am considering is an extra XSM hook at the start of do_domctl
and do_sysctl that takes only the command (and domain, for domctl); this
could be used to restrict access to unknown domctl/sysctls, and would fix
the issues of adding sub-functions without access checks.

-- 
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 Tue Sep 11 13:22:22 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 2012 13: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 1TBQPr-0002ot-Ut; Tue, 11 Sep 2012 13:22:11 +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 1TBQPq-0002oh-F3
	for xen-devel@lists.xen.org; Tue, 11 Sep 2012 13:22:10 +0000
Received: from [85.158.143.99:13550] by server-3.bemta-4.messagelabs.com id
	05/F4-08232-10B3F405; Tue, 11 Sep 2012 13:22:09 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-7.tower-216.messagelabs.com!1347369699!26368182!1
X-Originating-IP: [63.239.67.9]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29710 invoked from network); 11 Sep 2012 13:21:40 -0000
Received: from emvm-gh1-uea08.nsa.gov (HELO nsa.gov) (63.239.67.9)
	by server-7.tower-216.messagelabs.com with SMTP;
	11 Sep 2012 13:21:40 -0000
X-TM-IMSS-Message-ID: <342a1e5e000f2be2@nsa.gov>
Received: from tarius.tycho.ncsc.mil ([144.51.3.1]) by nsa.gov ([63.239.67.9])
	with ESMTP (TREND IMSS SMTP Service 7.1) id 342a1e5e000f2be2 ;
	Tue, 11 Sep 2012 09:21:29 -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 q8BDLZSu017783; 
	Tue, 11 Sep 2012 09:21:35 -0400
Message-ID: <504F3ADF.8030402@tycho.nsa.gov>
Date: Tue, 11 Sep 2012 09:21:35 -0400
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Organization: National Security Agency
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120828 Thunderbird/15.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <CC741177.4B381%keir@xen.org> <504E5760.5070605@tycho.nsa.gov>
	<504F0DE3020000780009A727@nat28.tlf.novell.com>
In-Reply-To: <504F0DE3020000780009A727@nat28.tlf.novell.com>
Cc: Keir Fraser <keir@xen.org>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH v2] Merge IS_PRIV checks into XSM hooks
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 09/11/2012 04:09 AM, Jan Beulich wrote:
>>>> On 10.09.12 at 23:10, Daniel De Graaf <dgdegra@tycho.nsa.gov> wrote:
>> On 09/10/2012 04:51 PM, Keir Fraser wrote:
>>> On 10/09/2012 20:48, "Daniel De Graaf" <dgdegra@tycho.nsa.gov> wrote:
>>>
>>>> Overall, this series should not change the behavior of Xen when XSM is
>>>> not enabled; however, in some cases, the exact errors that are returned
>>>> will be different because security checks have been moved below validity
>>>> checks. Also, once applied, newly introduced domctls and sysctls will
>>>> not automatically be guarded by IS_PRIV checks - they will need to add
>>>> their own permission checking code.
>>>
>>> How do we guard against accidentally forgetting to do this?
>>
>> The same way you guard against it when adding a new hypercall: when adding
>> new functionality that needs access checks, also add the access checks.
> 
> Except that previously the access check was done centrally at the
> top of do_domctl(), so newly added sub-functions didn't need to
> worry.
> 
> Jan
> 

One addition I am considering is an extra XSM hook at the start of do_domctl
and do_sysctl that takes only the command (and domain, for domctl); this
could be used to restrict access to unknown domctl/sysctls, and would fix
the issues of adding sub-functions without access checks.

-- 
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 Tue Sep 11 13:24:43 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 2012 13:24: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 1TBQSA-0002zj-GM; Tue, 11 Sep 2012 13:24:34 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1TBQS9-0002zN-Pr
	for xen-devel@lists.xen.org; Tue, 11 Sep 2012 13:24:33 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-15.tower-27.messagelabs.com!1347369865!3585575!1
X-Originating-IP: [63.239.67.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24041 invoked from network); 11 Sep 2012 13:24:25 -0000
Received: from emvm-gh1-uea09.nsa.gov (HELO nsa.gov) (63.239.67.10)
	by server-15.tower-27.messagelabs.com with SMTP;
	11 Sep 2012 13:24:25 -0000
X-TM-IMSS-Message-ID: <342c65f8000f89ff@nsa.gov>
Received: from tarius.tycho.ncsc.mil ([144.51.3.1]) by nsa.gov
	([63.239.67.10]) with ESMTP (TREND IMSS SMTP Service 7.1) id
	342c65f8000f89ff ; Tue, 11 Sep 2012 09:26:31 -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 q8BDOL8U018186; 
	Tue, 11 Sep 2012 09:24:21 -0400
Message-ID: <504F3B85.3010103@tycho.nsa.gov>
Date: Tue, 11 Sep 2012 09:24:21 -0400
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Organization: National Security Agency
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120828 Thunderbird/15.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <1347306553-20980-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1347306553-20980-11-git-send-email-dgdegra@tycho.nsa.gov>
	<504F0811020000780009A6D5@nat28.tlf.novell.com>
In-Reply-To: <504F0811020000780009A6D5@nat28.tlf.novell.com>
Cc: Keir Fraser <keir@xen.org>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 10/20] xsm: Add IS_PRIV checks to dummy XSM
	module
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 09/11/2012 03:44 AM, Jan Beulich wrote:
>>>> On 10.09.12 at 21:49, Daniel De Graaf <dgdegra@tycho.nsa.gov> wrote:
>> --- a/xen/include/xsm/xsm.h
>> +++ b/xen/include/xsm/xsm.h
>> @@ -21,11 +21,7 @@
>>  typedef void xsm_op_t;
>>  DEFINE_XEN_GUEST_HANDLE(xsm_op_t);
>>  
>> -#ifdef XSM_ENABLE
>> -    #define xsm_call(fn) xsm_ops->fn
>> -#else
>> -    #define xsm_call(fn) 0
>> -#endif
>> +#define xsm_call(fn) xsm_ops->fn
> 
> So am I getting it right that with XSM disabled this now adds an
> indirect call in almost every hypercall? I'm not really in favor of
> that, particularly not if that affects hot path ones like the MMU
> operations.
> 
> Jan
> 

No. With XSM disabled, this part of the header file is not used;
instead, xsm/dummy.h is included with XSM_DEFAULT set up to generate
inline functions. So there should be no slowdown if XSM is disabled.

-- 
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 Tue Sep 11 13:24:43 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 2012 13:24: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 1TBQSA-0002zj-GM; Tue, 11 Sep 2012 13:24:34 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1TBQS9-0002zN-Pr
	for xen-devel@lists.xen.org; Tue, 11 Sep 2012 13:24:33 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-15.tower-27.messagelabs.com!1347369865!3585575!1
X-Originating-IP: [63.239.67.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24041 invoked from network); 11 Sep 2012 13:24:25 -0000
Received: from emvm-gh1-uea09.nsa.gov (HELO nsa.gov) (63.239.67.10)
	by server-15.tower-27.messagelabs.com with SMTP;
	11 Sep 2012 13:24:25 -0000
X-TM-IMSS-Message-ID: <342c65f8000f89ff@nsa.gov>
Received: from tarius.tycho.ncsc.mil ([144.51.3.1]) by nsa.gov
	([63.239.67.10]) with ESMTP (TREND IMSS SMTP Service 7.1) id
	342c65f8000f89ff ; Tue, 11 Sep 2012 09:26:31 -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 q8BDOL8U018186; 
	Tue, 11 Sep 2012 09:24:21 -0400
Message-ID: <504F3B85.3010103@tycho.nsa.gov>
Date: Tue, 11 Sep 2012 09:24:21 -0400
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Organization: National Security Agency
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120828 Thunderbird/15.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <1347306553-20980-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1347306553-20980-11-git-send-email-dgdegra@tycho.nsa.gov>
	<504F0811020000780009A6D5@nat28.tlf.novell.com>
In-Reply-To: <504F0811020000780009A6D5@nat28.tlf.novell.com>
Cc: Keir Fraser <keir@xen.org>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 10/20] xsm: Add IS_PRIV checks to dummy XSM
	module
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 09/11/2012 03:44 AM, Jan Beulich wrote:
>>>> On 10.09.12 at 21:49, Daniel De Graaf <dgdegra@tycho.nsa.gov> wrote:
>> --- a/xen/include/xsm/xsm.h
>> +++ b/xen/include/xsm/xsm.h
>> @@ -21,11 +21,7 @@
>>  typedef void xsm_op_t;
>>  DEFINE_XEN_GUEST_HANDLE(xsm_op_t);
>>  
>> -#ifdef XSM_ENABLE
>> -    #define xsm_call(fn) xsm_ops->fn
>> -#else
>> -    #define xsm_call(fn) 0
>> -#endif
>> +#define xsm_call(fn) xsm_ops->fn
> 
> So am I getting it right that with XSM disabled this now adds an
> indirect call in almost every hypercall? I'm not really in favor of
> that, particularly not if that affects hot path ones like the MMU
> operations.
> 
> Jan
> 

No. With XSM disabled, this part of the header file is not used;
instead, xsm/dummy.h is included with XSM_DEFAULT set up to generate
inline functions. So there should be no slowdown if XSM is disabled.

-- 
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 Tue Sep 11 13:27:06 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 2012 13:27:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TBQUR-0003AX-24; Tue, 11 Sep 2012 13:26:55 +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 1TBQUP-0003AN-83
	for xen-devel@lists.xen.org; Tue, 11 Sep 2012 13:26:53 +0000
Received: from [85.158.143.99:32331] by server-2.bemta-4.messagelabs.com id
	95/31-21239-C1C3F405; Tue, 11 Sep 2012 13:26:52 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-6.tower-216.messagelabs.com!1347370002!22725485!1
X-Originating-IP: [63.239.67.9]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18520 invoked from network); 11 Sep 2012 13:26:51 -0000
Received: from emvm-gh1-uea08.nsa.gov (HELO nsa.gov) (63.239.67.9)
	by server-6.tower-216.messagelabs.com with SMTP;
	11 Sep 2012 13:26:51 -0000
X-TM-IMSS-Message-ID: <342ebea2000f2d9f@nsa.gov>
Received: from tarius.tycho.ncsc.mil ([144.51.3.1]) by nsa.gov ([63.239.67.9])
	with ESMTP (TREND IMSS SMTP Service 7.1) id 342ebea2000f2d9f ;
	Tue, 11 Sep 2012 09:26:32 -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 q8BDQc6B018321; 
	Tue, 11 Sep 2012 09:26:38 -0400
Message-ID: <504F3C0E.8020901@tycho.nsa.gov>
Date: Tue, 11 Sep 2012 09:26:38 -0400
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Organization: National Security Agency
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120828 Thunderbird/15.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <1347306553-20980-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1347306553-20980-13-git-send-email-dgdegra@tycho.nsa.gov>
	<504F0603020000780009A6CC@nat28.tlf.novell.com>
In-Reply-To: <504F0603020000780009A6CC@nat28.tlf.novell.com>
Cc: Keir Fraser <keir@xen.org>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 12/20] xen: avoid calling
 rcu_lock_*target_domain when an XSM hook 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 09/11/2012 03:36 AM, Jan Beulich wrote:
>>>> On 10.09.12 at 21:49, Daniel De Graaf <dgdegra@tycho.nsa.gov> wrote:
>> --- a/xen/common/grant_table.c
>> +++ b/xen/common/grant_table.c
>> @@ -195,30 +195,6 @@ double_gt_unlock(struct grant_table *lgt, struct 
>> grant_table *rgt)
>>          spin_unlock(&rgt->lock);
>>  }
>>  
>> -static struct domain *gt_lock_target_domain_by_id(domid_t dom)
>> -{
>> -    struct domain *d;
>> -    int rc = GNTST_general_error;
>> -
>> -    switch ( rcu_lock_target_domain_by_id(dom, &d) )
>> -    {
>> -    case 0:
>> -        return d;
>> -
>> -    case -ESRCH:
>> -        gdprintk(XENLOG_INFO, "Bad domid %d.\n", dom);
>> -        rc = GNTST_bad_domain;
>> -        break;
>> -
>> -    case -EPERM:
>> -        rc = GNTST_permission_denied;
>> -        break;
>> -    }
>> -
>> -    ASSERT(rc < 0 && -rc <= MAX_ERRNO);
>> -    return ERR_PTR(rc);
>> -}
>> -
> 
> Removing that function again is fine as long as you retain the
> distinguished error codes, which ...
> 
>>  static inline int
>>  __get_maptrack_handle(
>>      struct grant_table *t)
>> @@ -1304,11 +1280,12 @@ gnttab_setup_table(
>>          goto out1;
>>      }
>>  
>> -    d = gt_lock_target_domain_by_id(op.dom);
>> -    if ( IS_ERR(d) )
>> +    d = rcu_lock_domain_by_any_id(op.dom);
>> +    if ( d == NULL )
>>      {
>> -        op.status = PTR_ERR(d);
>> -        goto out1;
>> +        gdprintk(XENLOG_INFO, "Bad domid %d.\n", op.dom);
>> +        op.status = GNTST_bad_domain;
> 
> ... you don't.

Actually, I do. The only distinguishing error code here is
GNTST_permission_denied, which is now only triggered by the XSM
hook.

>> --- a/xen/common/memory.c
>> +++ b/xen/common/memory.c
>> @@ -570,7 +570,8 @@ long do_memory_op(unsigned long cmd, 
>> XEN_GUEST_HANDLE(void) arg)
>>               && (reservation.mem_flags & XENMEMF_populate_on_demand) )
>>              args.memflags |= MEMF_populate_on_demand;
>>  
>> -        if ( unlikely(rcu_lock_target_domain_by_id(reservation.domid, &d)) )
>> +        d = rcu_lock_domain_by_any_id(reservation.domid);
>> +        if ( d == NULL )
>>              return start_extent;
>>          args.domain = d;
>>  
>> @@ -619,9 +620,9 @@ long do_memory_op(unsigned long cmd, 
>> XEN_GUEST_HANDLE(void) arg)
>>          if ( copy_from_guest(&domid, arg, 1) )
>>              return -EFAULT;
>>  
>> -        rc = rcu_lock_target_domain_by_id(domid, &d);
>> -        if ( rc )
>> -            return rc;
>> +        d = rcu_lock_domain_by_any_id(domid);
>> +        if ( d == NULL )
>> +            return -ESRCH;
> 
> And quite similarly here and further down you're losing -EPERM.
> 
> Jan
> 
Same logic: rcu_lock_domain_by_any_id will succeed where -EPERM was
returned by rcu_lock_target_domain_by_id; the check is moved to the
XSM hook.

-- 
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 Tue Sep 11 13:27:06 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 2012 13:27:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TBQUR-0003AX-24; Tue, 11 Sep 2012 13:26:55 +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 1TBQUP-0003AN-83
	for xen-devel@lists.xen.org; Tue, 11 Sep 2012 13:26:53 +0000
Received: from [85.158.143.99:32331] by server-2.bemta-4.messagelabs.com id
	95/31-21239-C1C3F405; Tue, 11 Sep 2012 13:26:52 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-6.tower-216.messagelabs.com!1347370002!22725485!1
X-Originating-IP: [63.239.67.9]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18520 invoked from network); 11 Sep 2012 13:26:51 -0000
Received: from emvm-gh1-uea08.nsa.gov (HELO nsa.gov) (63.239.67.9)
	by server-6.tower-216.messagelabs.com with SMTP;
	11 Sep 2012 13:26:51 -0000
X-TM-IMSS-Message-ID: <342ebea2000f2d9f@nsa.gov>
Received: from tarius.tycho.ncsc.mil ([144.51.3.1]) by nsa.gov ([63.239.67.9])
	with ESMTP (TREND IMSS SMTP Service 7.1) id 342ebea2000f2d9f ;
	Tue, 11 Sep 2012 09:26:32 -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 q8BDQc6B018321; 
	Tue, 11 Sep 2012 09:26:38 -0400
Message-ID: <504F3C0E.8020901@tycho.nsa.gov>
Date: Tue, 11 Sep 2012 09:26:38 -0400
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Organization: National Security Agency
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120828 Thunderbird/15.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <1347306553-20980-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1347306553-20980-13-git-send-email-dgdegra@tycho.nsa.gov>
	<504F0603020000780009A6CC@nat28.tlf.novell.com>
In-Reply-To: <504F0603020000780009A6CC@nat28.tlf.novell.com>
Cc: Keir Fraser <keir@xen.org>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 12/20] xen: avoid calling
 rcu_lock_*target_domain when an XSM hook 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 09/11/2012 03:36 AM, Jan Beulich wrote:
>>>> On 10.09.12 at 21:49, Daniel De Graaf <dgdegra@tycho.nsa.gov> wrote:
>> --- a/xen/common/grant_table.c
>> +++ b/xen/common/grant_table.c
>> @@ -195,30 +195,6 @@ double_gt_unlock(struct grant_table *lgt, struct 
>> grant_table *rgt)
>>          spin_unlock(&rgt->lock);
>>  }
>>  
>> -static struct domain *gt_lock_target_domain_by_id(domid_t dom)
>> -{
>> -    struct domain *d;
>> -    int rc = GNTST_general_error;
>> -
>> -    switch ( rcu_lock_target_domain_by_id(dom, &d) )
>> -    {
>> -    case 0:
>> -        return d;
>> -
>> -    case -ESRCH:
>> -        gdprintk(XENLOG_INFO, "Bad domid %d.\n", dom);
>> -        rc = GNTST_bad_domain;
>> -        break;
>> -
>> -    case -EPERM:
>> -        rc = GNTST_permission_denied;
>> -        break;
>> -    }
>> -
>> -    ASSERT(rc < 0 && -rc <= MAX_ERRNO);
>> -    return ERR_PTR(rc);
>> -}
>> -
> 
> Removing that function again is fine as long as you retain the
> distinguished error codes, which ...
> 
>>  static inline int
>>  __get_maptrack_handle(
>>      struct grant_table *t)
>> @@ -1304,11 +1280,12 @@ gnttab_setup_table(
>>          goto out1;
>>      }
>>  
>> -    d = gt_lock_target_domain_by_id(op.dom);
>> -    if ( IS_ERR(d) )
>> +    d = rcu_lock_domain_by_any_id(op.dom);
>> +    if ( d == NULL )
>>      {
>> -        op.status = PTR_ERR(d);
>> -        goto out1;
>> +        gdprintk(XENLOG_INFO, "Bad domid %d.\n", op.dom);
>> +        op.status = GNTST_bad_domain;
> 
> ... you don't.

Actually, I do. The only distinguishing error code here is
GNTST_permission_denied, which is now only triggered by the XSM
hook.

>> --- a/xen/common/memory.c
>> +++ b/xen/common/memory.c
>> @@ -570,7 +570,8 @@ long do_memory_op(unsigned long cmd, 
>> XEN_GUEST_HANDLE(void) arg)
>>               && (reservation.mem_flags & XENMEMF_populate_on_demand) )
>>              args.memflags |= MEMF_populate_on_demand;
>>  
>> -        if ( unlikely(rcu_lock_target_domain_by_id(reservation.domid, &d)) )
>> +        d = rcu_lock_domain_by_any_id(reservation.domid);
>> +        if ( d == NULL )
>>              return start_extent;
>>          args.domain = d;
>>  
>> @@ -619,9 +620,9 @@ long do_memory_op(unsigned long cmd, 
>> XEN_GUEST_HANDLE(void) arg)
>>          if ( copy_from_guest(&domid, arg, 1) )
>>              return -EFAULT;
>>  
>> -        rc = rcu_lock_target_domain_by_id(domid, &d);
>> -        if ( rc )
>> -            return rc;
>> +        d = rcu_lock_domain_by_any_id(domid);
>> +        if ( d == NULL )
>> +            return -ESRCH;
> 
> And quite similarly here and further down you're losing -EPERM.
> 
> Jan
> 
Same logic: rcu_lock_domain_by_any_id will succeed where -EPERM was
returned by rcu_lock_target_domain_by_id; the check is moved to the
XSM hook.

-- 
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 Tue Sep 11 13:33:17 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 2012 13:33: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 1TBQaM-0003Om-SL; Tue, 11 Sep 2012 13:33:02 +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 1TBQaL-0003Np-H2
	for xen-devel@lists.xen.org; Tue, 11 Sep 2012 13:33:01 +0000
Received: from [85.158.138.51:10723] by server-12.bemta-3.messagelabs.com id
	11/05-10384-C8D3F405; Tue, 11 Sep 2012 13:33:00 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1347370379!28141524!1
X-Originating-IP: [74.125.83.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13790 invoked from network); 11 Sep 2012 13:32:59 -0000
Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com)
	(74.125.83.45)
	by server-15.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Sep 2012 13:32:59 -0000
Received: by eeke53 with SMTP id e53so452369eek.32
	for <xen-devel@lists.xen.org>; Tue, 11 Sep 2012 06:32:59 -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=ZqAl0tUhqcLr8e8g/FCCJ8hrUZAPhcc2ABo64KB7UVk=;
	b=EuOrhamVqExsX6YDhQQR43IfblE23Jq+3Z1PVE5/c2FPOyfnKS8zM6xUd8/AaYOlPC
	YjYlIz+9ssyHnnUP/x+fSmiRhoBBF1wLpgej/5zVFg1h3l8buwNA/KYIddSGHORaZYo4
	v0aS92j/4Zvp0wArezU5DoUsetB11RvqvHWlP4ZgikYkvP3VUpimLJ+IYNRn8M0e+5Hn
	HW3VTYdoWQfEZkimnuUkqgTSN/RALtF0M4PgycPGwSXIWzya3QMCZ6t22MTJ8f/AmvHq
	DiKJfsC0mITxPl7oSFuBLtsoOrFT8tvhDNw0QPQfm/z7ypNihfGcJW5FCF3qMXw5+bwc
	AzVQ==
Received: by 10.14.199.67 with SMTP id w43mr25670417een.33.1347370379487;
	Tue, 11 Sep 2012 06:32:59 -0700 (PDT)
Received: from [192.168.1.3] (host86-184-74-117.range86-184.btcentralplus.com.
	[86.184.74.117])
	by mx.google.com with ESMTPS id h42sm47175681eem.5.2012.09.11.06.32.57
	(version=SSLv3 cipher=OTHER); Tue, 11 Sep 2012 06:32:58 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.33.0.120411
Date: Tue, 11 Sep 2012 14:32:55 +0100
From: Keir Fraser <keir@xen.org>
To: Jan Beulich <JBeulich@suse.com>,
	xen-devel <xen-devel@lists.xen.org>
Message-ID: <CC74FC17.4B713%keir@xen.org>
Thread-Topic: [Xen-devel] [PATCH 0/3] x86/hvm: miscellaneous cleanup
Thread-Index: Ac2QIfMSaX6Lhx2HE0WdjLw/Tc4Xsg==
In-Reply-To: <504F4EC8020000780009A993@nat28.tlf.novell.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] [PATCH 0/3] x86/hvm: miscellaneous cleanup
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/09/2012 13:46, "Jan Beulich" <JBeulich@suse.com> wrote:

> 1: don't use indirect calls without need
> 2: constify static data where possible
> 3: mark save/restore registration code __init
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Acked-by: Keir Fraser <keir@xen.org>

> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 11 13:33:17 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 2012 13:33: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 1TBQaM-0003Om-SL; Tue, 11 Sep 2012 13:33:02 +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 1TBQaL-0003Np-H2
	for xen-devel@lists.xen.org; Tue, 11 Sep 2012 13:33:01 +0000
Received: from [85.158.138.51:10723] by server-12.bemta-3.messagelabs.com id
	11/05-10384-C8D3F405; Tue, 11 Sep 2012 13:33:00 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1347370379!28141524!1
X-Originating-IP: [74.125.83.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13790 invoked from network); 11 Sep 2012 13:32:59 -0000
Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com)
	(74.125.83.45)
	by server-15.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Sep 2012 13:32:59 -0000
Received: by eeke53 with SMTP id e53so452369eek.32
	for <xen-devel@lists.xen.org>; Tue, 11 Sep 2012 06:32:59 -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=ZqAl0tUhqcLr8e8g/FCCJ8hrUZAPhcc2ABo64KB7UVk=;
	b=EuOrhamVqExsX6YDhQQR43IfblE23Jq+3Z1PVE5/c2FPOyfnKS8zM6xUd8/AaYOlPC
	YjYlIz+9ssyHnnUP/x+fSmiRhoBBF1wLpgej/5zVFg1h3l8buwNA/KYIddSGHORaZYo4
	v0aS92j/4Zvp0wArezU5DoUsetB11RvqvHWlP4ZgikYkvP3VUpimLJ+IYNRn8M0e+5Hn
	HW3VTYdoWQfEZkimnuUkqgTSN/RALtF0M4PgycPGwSXIWzya3QMCZ6t22MTJ8f/AmvHq
	DiKJfsC0mITxPl7oSFuBLtsoOrFT8tvhDNw0QPQfm/z7ypNihfGcJW5FCF3qMXw5+bwc
	AzVQ==
Received: by 10.14.199.67 with SMTP id w43mr25670417een.33.1347370379487;
	Tue, 11 Sep 2012 06:32:59 -0700 (PDT)
Received: from [192.168.1.3] (host86-184-74-117.range86-184.btcentralplus.com.
	[86.184.74.117])
	by mx.google.com with ESMTPS id h42sm47175681eem.5.2012.09.11.06.32.57
	(version=SSLv3 cipher=OTHER); Tue, 11 Sep 2012 06:32:58 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.33.0.120411
Date: Tue, 11 Sep 2012 14:32:55 +0100
From: Keir Fraser <keir@xen.org>
To: Jan Beulich <JBeulich@suse.com>,
	xen-devel <xen-devel@lists.xen.org>
Message-ID: <CC74FC17.4B713%keir@xen.org>
Thread-Topic: [Xen-devel] [PATCH 0/3] x86/hvm: miscellaneous cleanup
Thread-Index: Ac2QIfMSaX6Lhx2HE0WdjLw/Tc4Xsg==
In-Reply-To: <504F4EC8020000780009A993@nat28.tlf.novell.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] [PATCH 0/3] x86/hvm: miscellaneous cleanup
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/09/2012 13:46, "Jan Beulich" <JBeulich@suse.com> wrote:

> 1: don't use indirect calls without need
> 2: constify static data where possible
> 3: mark save/restore registration code __init
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Acked-by: Keir Fraser <keir@xen.org>

> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 11 13:33:35 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 2012 13: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 1TBQak-0003Vh-A8; Tue, 11 Sep 2012 13:33: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 1TBQaj-0003V1-C6
	for xen-devel@lists.xen.org; Tue, 11 Sep 2012 13:33:25 +0000
Received: from [85.158.143.99:48275] by server-3.bemta-4.messagelabs.com id
	46/BC-08232-4AD3F405; Tue, 11 Sep 2012 13:33:24 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1347370404!29775006!1
X-Originating-IP: [209.85.215.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27244 invoked from network); 11 Sep 2012 13:33:24 -0000
Received: from mail-ey0-f173.google.com (HELO mail-ey0-f173.google.com)
	(209.85.215.173)
	by server-9.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Sep 2012 13:33:24 -0000
Received: by eaac13 with SMTP id c13so292693eaa.32
	for <xen-devel@lists.xen.org>; Tue, 11 Sep 2012 06:33: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:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=1IqZHrCF31t62zToyFucEQdFpnUOTy/mF1YHRpCZ/7c=;
	b=NI7mL4OyGAXkZ5QKv3838CEKQ6kAaMDUcYAozj2loT9Sz7wUO1TbmNlYQGwfZRmaRs
	prHG3RmPyK/dcFxacMQizOhIlIhhJ7jM752iREb+TLFz+6M7i7BTL6ggFhNwb4x/XQv5
	sze9YkJ8cMJGKL4mp1BV82M1HpmXwGlTcBkMSj7G+xQBvUx2n8dQxl3I05I5SRfMjE8Z
	/cqzsmyJNouXyCgTxA4WQEDz0CookzIL+4asK7OmwdY/47H83W4LmqfOiTExv3U+9L09
	qnsVKdojTjlPCOAZjeFkU0tOEgbxp3TLOJFcu6Rj3v00V3daUgGIh2h6QZd6Nu7uDUw3
	0N4g==
Received: by 10.14.202.131 with SMTP id d3mr25956389eeo.32.1347370404046;
	Tue, 11 Sep 2012 06:33:24 -0700 (PDT)
Received: from [192.168.1.3] (host86-184-74-117.range86-184.btcentralplus.com.
	[86.184.74.117])
	by mx.google.com with ESMTPS id e7sm47190899eep.2.2012.09.11.06.33.20
	(version=SSLv3 cipher=OTHER); Tue, 11 Sep 2012 06:33:22 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.33.0.120411
Date: Tue, 11 Sep 2012 14:33:17 +0100
From: Keir Fraser <keir@xen.org>
To: Jan Beulich <JBeulich@suse.com>,
	xen-devel <xen-devel@lists.xen.org>
Message-ID: <CC74FC2D.4B714%keir@xen.org>
Thread-Topic: [Xen-devel] [PATCH 0/3] passthrough/x86: use PCI/MSI definitions
	and functions where possible
Thread-Index: Ac2QIgAvTrCJjBi6xkOLr6SOiEFgTg==
In-Reply-To: <504F4BB7020000780009A95F@nat28.tlf.novell.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] [PATCH 0/3] passthrough/x86: use PCI/MSI
 definitions and functions where possible
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/09/2012 13:33, "Jan Beulich" <JBeulich@suse.com> wrote:

> 1: amd iommu: use PCI macros instead of open coding them
> 2: amd iommu: use base platform MSI implementation
> 3: VT-d: use msi_compose_msg()
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Acked-by: Keir Fraser <keir@xen.org>

> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 11 13:33:35 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 2012 13: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 1TBQak-0003Vh-A8; Tue, 11 Sep 2012 13:33: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 1TBQaj-0003V1-C6
	for xen-devel@lists.xen.org; Tue, 11 Sep 2012 13:33:25 +0000
Received: from [85.158.143.99:48275] by server-3.bemta-4.messagelabs.com id
	46/BC-08232-4AD3F405; Tue, 11 Sep 2012 13:33:24 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1347370404!29775006!1
X-Originating-IP: [209.85.215.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27244 invoked from network); 11 Sep 2012 13:33:24 -0000
Received: from mail-ey0-f173.google.com (HELO mail-ey0-f173.google.com)
	(209.85.215.173)
	by server-9.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Sep 2012 13:33:24 -0000
Received: by eaac13 with SMTP id c13so292693eaa.32
	for <xen-devel@lists.xen.org>; Tue, 11 Sep 2012 06:33: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:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=1IqZHrCF31t62zToyFucEQdFpnUOTy/mF1YHRpCZ/7c=;
	b=NI7mL4OyGAXkZ5QKv3838CEKQ6kAaMDUcYAozj2loT9Sz7wUO1TbmNlYQGwfZRmaRs
	prHG3RmPyK/dcFxacMQizOhIlIhhJ7jM752iREb+TLFz+6M7i7BTL6ggFhNwb4x/XQv5
	sze9YkJ8cMJGKL4mp1BV82M1HpmXwGlTcBkMSj7G+xQBvUx2n8dQxl3I05I5SRfMjE8Z
	/cqzsmyJNouXyCgTxA4WQEDz0CookzIL+4asK7OmwdY/47H83W4LmqfOiTExv3U+9L09
	qnsVKdojTjlPCOAZjeFkU0tOEgbxp3TLOJFcu6Rj3v00V3daUgGIh2h6QZd6Nu7uDUw3
	0N4g==
Received: by 10.14.202.131 with SMTP id d3mr25956389eeo.32.1347370404046;
	Tue, 11 Sep 2012 06:33:24 -0700 (PDT)
Received: from [192.168.1.3] (host86-184-74-117.range86-184.btcentralplus.com.
	[86.184.74.117])
	by mx.google.com with ESMTPS id e7sm47190899eep.2.2012.09.11.06.33.20
	(version=SSLv3 cipher=OTHER); Tue, 11 Sep 2012 06:33:22 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.33.0.120411
Date: Tue, 11 Sep 2012 14:33:17 +0100
From: Keir Fraser <keir@xen.org>
To: Jan Beulich <JBeulich@suse.com>,
	xen-devel <xen-devel@lists.xen.org>
Message-ID: <CC74FC2D.4B714%keir@xen.org>
Thread-Topic: [Xen-devel] [PATCH 0/3] passthrough/x86: use PCI/MSI definitions
	and functions where possible
Thread-Index: Ac2QIgAvTrCJjBi6xkOLr6SOiEFgTg==
In-Reply-To: <504F4BB7020000780009A95F@nat28.tlf.novell.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] [PATCH 0/3] passthrough/x86: use PCI/MSI
 definitions and functions where possible
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/09/2012 13:33, "Jan Beulich" <JBeulich@suse.com> wrote:

> 1: amd iommu: use PCI macros instead of open coding them
> 2: amd iommu: use base platform MSI implementation
> 3: VT-d: use msi_compose_msg()
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Acked-by: Keir Fraser <keir@xen.org>

> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 11 13:34:09 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 2012 13:34:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TBQbF-0003av-NN; Tue, 11 Sep 2012 13:33:57 +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 1TBQbE-0003aS-80
	for xen-devel@lists.xen.org; Tue, 11 Sep 2012 13:33:56 +0000
Received: from [85.158.143.99:54436] by server-3.bemta-4.messagelabs.com id
	C1/FD-08232-3CD3F405; Tue, 11 Sep 2012 13:33:55 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-12.tower-216.messagelabs.com!1347370434!24501587!1
X-Originating-IP: [63.239.67.9]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8596 invoked from network); 11 Sep 2012 13:33:55 -0000
Received: from emvm-gh1-uea08.nsa.gov (HELO nsa.gov) (63.239.67.9)
	by server-12.tower-216.messagelabs.com with SMTP;
	11 Sep 2012 13:33:55 -0000
X-TM-IMSS-Message-ID: <34354510000f2ffb@nsa.gov>
Received: from tarius.tycho.ncsc.mil ([144.51.3.1]) by nsa.gov ([63.239.67.9])
	with ESMTP (TREND IMSS SMTP Service 7.1) id 34354510000f2ffb ;
	Tue, 11 Sep 2012 09:33:40 -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 q8BDXkqu018915; 
	Tue, 11 Sep 2012 09:33:46 -0400
Message-ID: <504F3DBA.5040904@tycho.nsa.gov>
Date: Tue, 11 Sep 2012 09:33:46 -0400
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Organization: National Security Agency
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120828 Thunderbird/15.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <1347306553-20980-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1347306553-20980-12-git-send-email-dgdegra@tycho.nsa.gov>
	<504F045E020000780009A6B2@nat28.tlf.novell.com>
	<1347354323.5305.136.camel@zakaz.uk.xensource.com>
In-Reply-To: <1347354323.5305.136.camel@zakaz.uk.xensource.com>
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 11/20] xen: use XSM instead of IS_PRIV where
 duplicated
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 09/11/2012 05:05 AM, Ian Campbell wrote:
> On Tue, 2012-09-11 at 08:29 +0100, Jan Beulich wrote:
>>>  * do_console_io has changed to IS_PRIV from an explicit domid==0
>>
>> I see a point in actually limiting this to Dom0 - that's the only
>> domain that can't possibly have a virtual console. But I'm not
>> really opposed to changing this.
> 
> On a debug and/or verbose build of the hypervisor any domain can log
> here, and pvops Linux with earlyprintk=xen and/or xen_raw_printk will do
> so - it's quite useful for debugging early start of day issues in guest
> kernels. Although I suppose we can always comment out the check locally
> when doing such debugging.

I did keep the #ifdef VERBOSE around that IS_PRIV check, although it's
not noted in the commit message. I also take advantage of earlyprintk=xen
for debugging and for minios output.
 
> It occurs to me now that perhaps this should be handled more like the
> HVM port e9 stuff (i.e. with rate limiting etc) anyway.
> 
> Ian.
> 

I also have a patch for debugging that prepends "(domid) " to the console
output to help sorting out the serial log output when many domains are
using it (which is quite helpful during bootup). Combined with rate
limiting, this should make domU serial output useful in production builds.

-- 
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 Tue Sep 11 13:34:09 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 2012 13:34:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TBQbF-0003av-NN; Tue, 11 Sep 2012 13:33:57 +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 1TBQbE-0003aS-80
	for xen-devel@lists.xen.org; Tue, 11 Sep 2012 13:33:56 +0000
Received: from [85.158.143.99:54436] by server-3.bemta-4.messagelabs.com id
	C1/FD-08232-3CD3F405; Tue, 11 Sep 2012 13:33:55 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-12.tower-216.messagelabs.com!1347370434!24501587!1
X-Originating-IP: [63.239.67.9]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8596 invoked from network); 11 Sep 2012 13:33:55 -0000
Received: from emvm-gh1-uea08.nsa.gov (HELO nsa.gov) (63.239.67.9)
	by server-12.tower-216.messagelabs.com with SMTP;
	11 Sep 2012 13:33:55 -0000
X-TM-IMSS-Message-ID: <34354510000f2ffb@nsa.gov>
Received: from tarius.tycho.ncsc.mil ([144.51.3.1]) by nsa.gov ([63.239.67.9])
	with ESMTP (TREND IMSS SMTP Service 7.1) id 34354510000f2ffb ;
	Tue, 11 Sep 2012 09:33:40 -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 q8BDXkqu018915; 
	Tue, 11 Sep 2012 09:33:46 -0400
Message-ID: <504F3DBA.5040904@tycho.nsa.gov>
Date: Tue, 11 Sep 2012 09:33:46 -0400
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Organization: National Security Agency
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120828 Thunderbird/15.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <1347306553-20980-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1347306553-20980-12-git-send-email-dgdegra@tycho.nsa.gov>
	<504F045E020000780009A6B2@nat28.tlf.novell.com>
	<1347354323.5305.136.camel@zakaz.uk.xensource.com>
In-Reply-To: <1347354323.5305.136.camel@zakaz.uk.xensource.com>
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 11/20] xen: use XSM instead of IS_PRIV where
 duplicated
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 09/11/2012 05:05 AM, Ian Campbell wrote:
> On Tue, 2012-09-11 at 08:29 +0100, Jan Beulich wrote:
>>>  * do_console_io has changed to IS_PRIV from an explicit domid==0
>>
>> I see a point in actually limiting this to Dom0 - that's the only
>> domain that can't possibly have a virtual console. But I'm not
>> really opposed to changing this.
> 
> On a debug and/or verbose build of the hypervisor any domain can log
> here, and pvops Linux with earlyprintk=xen and/or xen_raw_printk will do
> so - it's quite useful for debugging early start of day issues in guest
> kernels. Although I suppose we can always comment out the check locally
> when doing such debugging.

I did keep the #ifdef VERBOSE around that IS_PRIV check, although it's
not noted in the commit message. I also take advantage of earlyprintk=xen
for debugging and for minios output.
 
> It occurs to me now that perhaps this should be handled more like the
> HVM port e9 stuff (i.e. with rate limiting etc) anyway.
> 
> Ian.
> 

I also have a patch for debugging that prepends "(domid) " to the console
output to help sorting out the serial log output when many domains are
using it (which is quite helpful during bootup). Combined with rate
limiting, this should make domU serial output useful in production builds.

-- 
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 Tue Sep 11 13:34:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 2012 13:34:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TBQbM-0003c6-56; Tue, 11 Sep 2012 13:34:04 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1TBQbK-0003am-Lp
	for xen-devel@lists.xen.org; Tue, 11 Sep 2012 13:34:02 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1347370436!9988861!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-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25384 invoked from network); 11 Sep 2012 13:33:56 -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;
	11 Sep 2012 13:33:56 -0000
Received: by eeke53 with SMTP id e53so453481eek.32
	for <xen-devel@lists.xen.org>; Tue, 11 Sep 2012 06:33:56 -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=Ie6hkR/aaPjf60gS67aTM691XxbG7WAIEbw0rjXX5ak=;
	b=eA4znpBEp54oWtse0qfrpm5KqDrQxoagNpufAbTdwazw5FTsuhF0zkzhHgWgd7cDTU
	TOXHxJpKRbgp1w1GkBlWocVqa0T8SFMc5pvnsGONfu25FwTZMjlO7kisBV+jNBuJ2UEN
	ayvLL+ETa+8GyRPb5KN2jMa0VuXX4iEqvh70ev8ZUEPnKR0pB96vqfcVNDNEm5aeEieZ
	WasaYd8dzwNizOrNmon5wYdqWkO39rpvSoEz+3Qdt/h71pY01WIxA3mTQNO+Zi6GmxO8
	u57AH/an/shKzfYqhrFFdaMzoiSM8guiVHf9oCGEgckubQMhy+D3fukfah//5OASAAYa
	rvCQ==
Received: by 10.14.172.193 with SMTP id t41mr25741031eel.25.1347370436285;
	Tue, 11 Sep 2012 06:33:56 -0700 (PDT)
Received: from [192.168.1.3] (host86-184-74-117.range86-184.btcentralplus.com.
	[86.184.74.117])
	by mx.google.com with ESMTPS id v3sm47159221eep.10.2012.09.11.06.33.50
	(version=SSLv3 cipher=OTHER); Tue, 11 Sep 2012 06:33:55 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.33.0.120411
Date: Tue, 11 Sep 2012 14:33:38 +0100
From: Keir Fraser <keir@xen.org>
To: Jan Beulich <JBeulich@suse.com>,
	xen-devel <xen-devel@lists.xen.org>
Message-ID: <CC74FC42.4B715%keir@xen.org>
Thread-Topic: [Xen-devel] [PATCH] x86: retrieve keyboard shift status flags
	from BIOS
Thread-Index: Ac2QIgyzbEDjQ4qkQkKJ9cxawZxeWw==
In-Reply-To: <504F3F8A020000780009A8F9@nat28.tlf.novell.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] [PATCH] x86: retrieve keyboard shift status flags
 from BIOS
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/09/2012 12:41, "Jan Beulich" <JBeulich@suse.com> wrote:

> Recent Linux tries to make use of this, and has no way of getting at
> these bits without Xen assisting it.
> 
> There doesn't appear to be a way to obtain the same information from
> UEFI.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Acked-by: Keir Fraser <keir@xen.org>

> --- a/xen/arch/x86/boot/trampoline.S
> +++ b/xen/arch/x86/boot/trampoline.S
> @@ -184,11 +184,16 @@ trampoline_boot_cpu_entry:
>           *  1. Get memory map.
>           *  2. Get Enhanced Disk Drive (EDD) information.
>           *  3. Set video mode.
> +         *  4. Get keyboard shift flags.
>           */
>          call    get_memory_map
>          call    get_edd
>          call    video
>  
> +        mov     $0x0200,%ax
> +        int     $0x16
> +        mov     %al,bootsym(kbd_shift_flags)
> +
>          /* Disable irqs before returning to protected mode. */
>          cli
>  
> @@ -221,6 +226,10 @@ trampoline_boot_cpu_entry:
>  skip_realmode:
>          .byte   0
>  
> +        .globl kbd_shift_flags
> +kbd_shift_flags:
> +        .byte   0
> +
>  rm_idt: .word   256*4-1, 0, 0
>  
>  #include "mem.S"
> --- a/xen/arch/x86/platform_hypercall.c
> +++ b/xen/arch/x86/platform_hypercall.c
> @@ -29,6 +29,7 @@
>  #include <asm/edd.h>
>  #include <asm/mtrr.h>
>  #include <asm/io_apic.h>
> +#include <asm/setup.h>
>  #include "cpu/mtrr/mtrr.h"
>  #include <xsm/xsm.h>
>  
> @@ -319,6 +320,18 @@ ret_t do_platform_op(XEN_GUEST_HANDLE(xe
>                                       u.firmware_info.u.efi_info) )
>                  ret = -EFAULT;
>              break;
> +        case XEN_FW_KBD_SHIFT_FLAGS:
> +            ret = -ESRCH;
> +            if ( op->u.firmware_info.index != 0 )
> +                break;
> +
> +            op->u.firmware_info.u.kbd_shift_flags = bootsym(kbd_shift_flags);
> +
> +            ret = 0;
> +            if ( copy_field_to_guest(u_xenpf_op, op,
> +                                     u.firmware_info.u.kbd_shift_flags) )
> +                ret = -EFAULT;
> +            break;
>          default:
>              ret = -EINVAL;
>              break;
> --- a/xen/include/asm-x86/setup.h
> +++ b/xen/include/asm-x86/setup.h
> @@ -41,4 +41,6 @@ int xen_in_range(unsigned long mfn);
>  void microcode_grab_module(
>      unsigned long *, const multiboot_info_t *, void *(*)(const module_t *));
>  
> +extern uint8_t kbd_shift_flags;
> +
>  #endif
> --- a/xen/include/public/platform.h
> +++ b/xen/include/public/platform.h
> @@ -218,6 +218,7 @@ DEFINE_XEN_GUEST_HANDLE(xenpf_efi_runtim
>  #define  XEN_FW_EFI_VENDOR         2
>  #define  XEN_FW_EFI_MEM_INFO       3
>  #define  XEN_FW_EFI_RT_VERSION     4
> +#define XEN_FW_KBD_SHIFT_FLAGS    5
>  struct xenpf_firmware_info {
>      /* IN variables. */
>      uint32_t type;
> @@ -266,6 +267,9 @@ struct xenpf_firmware_info {
>                  uint32_t type;
>              } mem;
>          } efi_info; /* XEN_FW_EFI_INFO */
> +
> +        /* Int16, Fn02: Get keyboard shift flags. */
> +        uint8_t kbd_shift_flags; /* XEN_FW_KBD_SHIFT_FLAGS */
>      } u;
>  };
>  typedef struct xenpf_firmware_info xenpf_firmware_info_t;
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Sep 11 13:34:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 2012 13:34:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TBQbM-0003c6-56; Tue, 11 Sep 2012 13:34:04 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1TBQbK-0003am-Lp
	for xen-devel@lists.xen.org; Tue, 11 Sep 2012 13:34:02 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1347370436!9988861!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-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25384 invoked from network); 11 Sep 2012 13:33:56 -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;
	11 Sep 2012 13:33:56 -0000
Received: by eeke53 with SMTP id e53so453481eek.32
	for <xen-devel@lists.xen.org>; Tue, 11 Sep 2012 06:33:56 -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=Ie6hkR/aaPjf60gS67aTM691XxbG7WAIEbw0rjXX5ak=;
	b=eA4znpBEp54oWtse0qfrpm5KqDrQxoagNpufAbTdwazw5FTsuhF0zkzhHgWgd7cDTU
	TOXHxJpKRbgp1w1GkBlWocVqa0T8SFMc5pvnsGONfu25FwTZMjlO7kisBV+jNBuJ2UEN
	ayvLL+ETa+8GyRPb5KN2jMa0VuXX4iEqvh70ev8ZUEPnKR0pB96vqfcVNDNEm5aeEieZ
	WasaYd8dzwNizOrNmon5wYdqWkO39rpvSoEz+3Qdt/h71pY01WIxA3mTQNO+Zi6GmxO8
	u57AH/an/shKzfYqhrFFdaMzoiSM8guiVHf9oCGEgckubQMhy+D3fukfah//5OASAAYa
	rvCQ==
Received: by 10.14.172.193 with SMTP id t41mr25741031eel.25.1347370436285;
	Tue, 11 Sep 2012 06:33:56 -0700 (PDT)
Received: from [192.168.1.3] (host86-184-74-117.range86-184.btcentralplus.com.
	[86.184.74.117])
	by mx.google.com with ESMTPS id v3sm47159221eep.10.2012.09.11.06.33.50
	(version=SSLv3 cipher=OTHER); Tue, 11 Sep 2012 06:33:55 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.33.0.120411
Date: Tue, 11 Sep 2012 14:33:38 +0100
From: Keir Fraser <keir@xen.org>
To: Jan Beulich <JBeulich@suse.com>,
	xen-devel <xen-devel@lists.xen.org>
Message-ID: <CC74FC42.4B715%keir@xen.org>
Thread-Topic: [Xen-devel] [PATCH] x86: retrieve keyboard shift status flags
	from BIOS
Thread-Index: Ac2QIgyzbEDjQ4qkQkKJ9cxawZxeWw==
In-Reply-To: <504F3F8A020000780009A8F9@nat28.tlf.novell.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] [PATCH] x86: retrieve keyboard shift status flags
 from BIOS
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/09/2012 12:41, "Jan Beulich" <JBeulich@suse.com> wrote:

> Recent Linux tries to make use of this, and has no way of getting at
> these bits without Xen assisting it.
> 
> There doesn't appear to be a way to obtain the same information from
> UEFI.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Acked-by: Keir Fraser <keir@xen.org>

> --- a/xen/arch/x86/boot/trampoline.S
> +++ b/xen/arch/x86/boot/trampoline.S
> @@ -184,11 +184,16 @@ trampoline_boot_cpu_entry:
>           *  1. Get memory map.
>           *  2. Get Enhanced Disk Drive (EDD) information.
>           *  3. Set video mode.
> +         *  4. Get keyboard shift flags.
>           */
>          call    get_memory_map
>          call    get_edd
>          call    video
>  
> +        mov     $0x0200,%ax
> +        int     $0x16
> +        mov     %al,bootsym(kbd_shift_flags)
> +
>          /* Disable irqs before returning to protected mode. */
>          cli
>  
> @@ -221,6 +226,10 @@ trampoline_boot_cpu_entry:
>  skip_realmode:
>          .byte   0
>  
> +        .globl kbd_shift_flags
> +kbd_shift_flags:
> +        .byte   0
> +
>  rm_idt: .word   256*4-1, 0, 0
>  
>  #include "mem.S"
> --- a/xen/arch/x86/platform_hypercall.c
> +++ b/xen/arch/x86/platform_hypercall.c
> @@ -29,6 +29,7 @@
>  #include <asm/edd.h>
>  #include <asm/mtrr.h>
>  #include <asm/io_apic.h>
> +#include <asm/setup.h>
>  #include "cpu/mtrr/mtrr.h"
>  #include <xsm/xsm.h>
>  
> @@ -319,6 +320,18 @@ ret_t do_platform_op(XEN_GUEST_HANDLE(xe
>                                       u.firmware_info.u.efi_info) )
>                  ret = -EFAULT;
>              break;
> +        case XEN_FW_KBD_SHIFT_FLAGS:
> +            ret = -ESRCH;
> +            if ( op->u.firmware_info.index != 0 )
> +                break;
> +
> +            op->u.firmware_info.u.kbd_shift_flags = bootsym(kbd_shift_flags);
> +
> +            ret = 0;
> +            if ( copy_field_to_guest(u_xenpf_op, op,
> +                                     u.firmware_info.u.kbd_shift_flags) )
> +                ret = -EFAULT;
> +            break;
>          default:
>              ret = -EINVAL;
>              break;
> --- a/xen/include/asm-x86/setup.h
> +++ b/xen/include/asm-x86/setup.h
> @@ -41,4 +41,6 @@ int xen_in_range(unsigned long mfn);
>  void microcode_grab_module(
>      unsigned long *, const multiboot_info_t *, void *(*)(const module_t *));
>  
> +extern uint8_t kbd_shift_flags;
> +
>  #endif
> --- a/xen/include/public/platform.h
> +++ b/xen/include/public/platform.h
> @@ -218,6 +218,7 @@ DEFINE_XEN_GUEST_HANDLE(xenpf_efi_runtim
>  #define  XEN_FW_EFI_VENDOR         2
>  #define  XEN_FW_EFI_MEM_INFO       3
>  #define  XEN_FW_EFI_RT_VERSION     4
> +#define XEN_FW_KBD_SHIFT_FLAGS    5
>  struct xenpf_firmware_info {
>      /* IN variables. */
>      uint32_t type;
> @@ -266,6 +267,9 @@ struct xenpf_firmware_info {
>                  uint32_t type;
>              } mem;
>          } efi_info; /* XEN_FW_EFI_INFO */
> +
> +        /* Int16, Fn02: Get keyboard shift flags. */
> +        uint8_t kbd_shift_flags; /* XEN_FW_KBD_SHIFT_FLAGS */
>      } u;
>  };
>  typedef struct xenpf_firmware_info xenpf_firmware_info_t;
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Sep 11 13:34:24 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 2012 13:34: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 1TBQbY-0003fB-Id; Tue, 11 Sep 2012 13:34:16 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1TBQbW-0003cy-9X
	for xen-devel@lists.xen.org; Tue, 11 Sep 2012 13:34:14 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1347370436!9988861!2
X-Originating-IP: [74.125.83.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26377 invoked from network); 11 Sep 2012 13:34:08 -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;
	11 Sep 2012 13:34:08 -0000
Received: by mail-ee0-f45.google.com with SMTP id e53so453481eek.32
	for <xen-devel@lists.xen.org>; Tue, 11 Sep 2012 06:34:08 -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=m1MvsiNKX/BQotBo8o4I0haVqTQVkjWMQCdHFefnh/Q=;
	b=Z+c6lVvkuywa0CA8J7e2dLImCHQPevtcir7pOTGy25Y0phZ3JAEnZpTWRrVWSWJPt7
	z8eOKIQFMau97cRhv3a/YSyFo/jkprtjzc6M8YFydy5K5hWKayra5Rv00fBnCgmnDQu2
	eFCbA/h0dcJwGokg04IkDGew8nR6yX+6PY6Y3SysWQ/vNyaLNcVTg62rHlaJgdzbFIw2
	C5rZdDiI/CukisZWe2RgG8TEeXihLYH5ATm50rnmbt2EHX6I2dO3oO24j/tCOOxLeT2u
	ll5SDEaCsh6/ICjrmsPt9Rs1rcp+09gaFXtVgMzNkbxmI/NoAbYuytKezIFNazDhmfTn
	EXww==
Received: by 10.14.211.3 with SMTP id v3mr25524951eeo.43.1347370448111;
	Tue, 11 Sep 2012 06:34:08 -0700 (PDT)
Received: from [192.168.1.3] (host86-184-74-117.range86-184.btcentralplus.com.
	[86.184.74.117])
	by mx.google.com with ESMTPS id v3sm47159221eep.10.2012.09.11.06.34.02
	(version=SSLv3 cipher=OTHER); Tue, 11 Sep 2012 06:34:06 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.33.0.120411
Date: Tue, 11 Sep 2012 14:33:52 +0100
From: Keir Fraser <keir@xen.org>
To: Jan Beulich <JBeulich@suse.com>,
	xen-devel <xen-devel@lists.xen.org>
Message-ID: <CC74FC50.4B716%keir@xen.org>
Thread-Topic: [Xen-devel] [PATCH] x86: use only a single branch for
	upcall-pending exit path checks
Thread-Index: Ac2QIhUL7H/ZQ/DhD0ehQHzETAi7gg==
In-Reply-To: <504F423E020000780009A91D@nat28.tlf.novell.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] [PATCH] x86: use only a single branch for
 upcall-pending exit path checks
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/09/2012 12:53, "Jan Beulich" <JBeulich@suse.com> wrote:

> This utilizes the fact that the two bytes of interest are adjacent to
> one another and that the resulting 16-bit values of interest are within
> a contiguous range of numbers.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Acked-by: Keir Fraser <keir@xen.org>

> --- a/xen/arch/x86/x86_32/entry.S
> +++ b/xen/arch/x86/x86_32/entry.S
> @@ -219,10 +219,10 @@ test_all_events:
>          jnz  process_nmi
>  test_guest_events:
>          movl VCPU_vcpu_info(%ebx),%eax
> -        testb $0xFF,VCPUINFO_upcall_mask(%eax)
> -        jnz  restore_all_guest
> -        testb $0xFF,VCPUINFO_upcall_pending(%eax)
> -        jz   restore_all_guest
> +        movzwl VCPUINFO_upcall_pending(%eax),%eax
> +        decl %eax
> +        cmpl $0xfe,%eax
> +        ja   restore_all_guest
>  /*process_guest_events:*/
>          sti
>          leal VCPU_trap_bounce(%ebx),%edx
> --- a/xen/arch/x86/x86_64/compat/entry.S
> +++ b/xen/arch/x86/x86_64/compat/entry.S
> @@ -108,10 +108,10 @@ ENTRY(compat_test_all_events)
>          jnz   compat_process_nmi
>  compat_test_guest_events:
>          movq  VCPU_vcpu_info(%rbx),%rax
> -        testb $0xFF,COMPAT_VCPUINFO_upcall_mask(%rax)
> -        jnz   compat_restore_all_guest
> -        testb $0xFF,COMPAT_VCPUINFO_upcall_pending(%rax)
> -        jz    compat_restore_all_guest
> +        movzwl COMPAT_VCPUINFO_upcall_pending(%rax),%eax
> +        decl  %eax
> +        cmpl  $0xfe,%eax
> +        ja    compat_restore_all_guest
>  /*compat_process_guest_events:*/
>          sti
>          leaq  VCPU_trap_bounce(%rbx),%rdx
> --- a/xen/arch/x86/x86_64/entry.S
> +++ b/xen/arch/x86/x86_64/entry.S
> @@ -199,8 +199,8 @@ test_all_events:
>          movl  VCPU_processor(%rbx),%eax
>          shl   $IRQSTAT_shift,%rax
>          leaq  irq_stat(%rip),%rcx
> -        testl $~0,(%rcx,%rax,1)
> -        jnz   process_softirqs
> +        cmpl  $0,(%rcx,%rax,1)
> +        jne   process_softirqs
>          testb $1,VCPU_mce_pending(%rbx)
>          jnz   process_mce
>  .Ltest_guest_nmi:
> @@ -208,10 +208,10 @@ test_all_events:
>          jnz   process_nmi
>  test_guest_events:
>          movq  VCPU_vcpu_info(%rbx),%rax
> -        testb $0xFF,VCPUINFO_upcall_mask(%rax)
> -        jnz   restore_all_guest
> -        testb $0xFF,VCPUINFO_upcall_pending(%rax)
> -        jz    restore_all_guest
> +        movzwl VCPUINFO_upcall_pending(%rax),%eax
> +        decl  %eax
> +        cmpl  $0xfe,%eax
> +        ja    restore_all_guest
>  /*process_guest_events:*/
>          sti
>          leaq  VCPU_trap_bounce(%rbx),%rdx
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Sep 11 13:34:24 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 2012 13:34: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 1TBQbY-0003fB-Id; Tue, 11 Sep 2012 13:34:16 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1TBQbW-0003cy-9X
	for xen-devel@lists.xen.org; Tue, 11 Sep 2012 13:34:14 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1347370436!9988861!2
X-Originating-IP: [74.125.83.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26377 invoked from network); 11 Sep 2012 13:34:08 -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;
	11 Sep 2012 13:34:08 -0000
Received: by mail-ee0-f45.google.com with SMTP id e53so453481eek.32
	for <xen-devel@lists.xen.org>; Tue, 11 Sep 2012 06:34:08 -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=m1MvsiNKX/BQotBo8o4I0haVqTQVkjWMQCdHFefnh/Q=;
	b=Z+c6lVvkuywa0CA8J7e2dLImCHQPevtcir7pOTGy25Y0phZ3JAEnZpTWRrVWSWJPt7
	z8eOKIQFMau97cRhv3a/YSyFo/jkprtjzc6M8YFydy5K5hWKayra5Rv00fBnCgmnDQu2
	eFCbA/h0dcJwGokg04IkDGew8nR6yX+6PY6Y3SysWQ/vNyaLNcVTg62rHlaJgdzbFIw2
	C5rZdDiI/CukisZWe2RgG8TEeXihLYH5ATm50rnmbt2EHX6I2dO3oO24j/tCOOxLeT2u
	ll5SDEaCsh6/ICjrmsPt9Rs1rcp+09gaFXtVgMzNkbxmI/NoAbYuytKezIFNazDhmfTn
	EXww==
Received: by 10.14.211.3 with SMTP id v3mr25524951eeo.43.1347370448111;
	Tue, 11 Sep 2012 06:34:08 -0700 (PDT)
Received: from [192.168.1.3] (host86-184-74-117.range86-184.btcentralplus.com.
	[86.184.74.117])
	by mx.google.com with ESMTPS id v3sm47159221eep.10.2012.09.11.06.34.02
	(version=SSLv3 cipher=OTHER); Tue, 11 Sep 2012 06:34:06 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.33.0.120411
Date: Tue, 11 Sep 2012 14:33:52 +0100
From: Keir Fraser <keir@xen.org>
To: Jan Beulich <JBeulich@suse.com>,
	xen-devel <xen-devel@lists.xen.org>
Message-ID: <CC74FC50.4B716%keir@xen.org>
Thread-Topic: [Xen-devel] [PATCH] x86: use only a single branch for
	upcall-pending exit path checks
Thread-Index: Ac2QIhUL7H/ZQ/DhD0ehQHzETAi7gg==
In-Reply-To: <504F423E020000780009A91D@nat28.tlf.novell.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] [PATCH] x86: use only a single branch for
 upcall-pending exit path checks
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/09/2012 12:53, "Jan Beulich" <JBeulich@suse.com> wrote:

> This utilizes the fact that the two bytes of interest are adjacent to
> one another and that the resulting 16-bit values of interest are within
> a contiguous range of numbers.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Acked-by: Keir Fraser <keir@xen.org>

> --- a/xen/arch/x86/x86_32/entry.S
> +++ b/xen/arch/x86/x86_32/entry.S
> @@ -219,10 +219,10 @@ test_all_events:
>          jnz  process_nmi
>  test_guest_events:
>          movl VCPU_vcpu_info(%ebx),%eax
> -        testb $0xFF,VCPUINFO_upcall_mask(%eax)
> -        jnz  restore_all_guest
> -        testb $0xFF,VCPUINFO_upcall_pending(%eax)
> -        jz   restore_all_guest
> +        movzwl VCPUINFO_upcall_pending(%eax),%eax
> +        decl %eax
> +        cmpl $0xfe,%eax
> +        ja   restore_all_guest
>  /*process_guest_events:*/
>          sti
>          leal VCPU_trap_bounce(%ebx),%edx
> --- a/xen/arch/x86/x86_64/compat/entry.S
> +++ b/xen/arch/x86/x86_64/compat/entry.S
> @@ -108,10 +108,10 @@ ENTRY(compat_test_all_events)
>          jnz   compat_process_nmi
>  compat_test_guest_events:
>          movq  VCPU_vcpu_info(%rbx),%rax
> -        testb $0xFF,COMPAT_VCPUINFO_upcall_mask(%rax)
> -        jnz   compat_restore_all_guest
> -        testb $0xFF,COMPAT_VCPUINFO_upcall_pending(%rax)
> -        jz    compat_restore_all_guest
> +        movzwl COMPAT_VCPUINFO_upcall_pending(%rax),%eax
> +        decl  %eax
> +        cmpl  $0xfe,%eax
> +        ja    compat_restore_all_guest
>  /*compat_process_guest_events:*/
>          sti
>          leaq  VCPU_trap_bounce(%rbx),%rdx
> --- a/xen/arch/x86/x86_64/entry.S
> +++ b/xen/arch/x86/x86_64/entry.S
> @@ -199,8 +199,8 @@ test_all_events:
>          movl  VCPU_processor(%rbx),%eax
>          shl   $IRQSTAT_shift,%rax
>          leaq  irq_stat(%rip),%rcx
> -        testl $~0,(%rcx,%rax,1)
> -        jnz   process_softirqs
> +        cmpl  $0,(%rcx,%rax,1)
> +        jne   process_softirqs
>          testb $1,VCPU_mce_pending(%rbx)
>          jnz   process_mce
>  .Ltest_guest_nmi:
> @@ -208,10 +208,10 @@ test_all_events:
>          jnz   process_nmi
>  test_guest_events:
>          movq  VCPU_vcpu_info(%rbx),%rax
> -        testb $0xFF,VCPUINFO_upcall_mask(%rax)
> -        jnz   restore_all_guest
> -        testb $0xFF,VCPUINFO_upcall_pending(%rax)
> -        jz    restore_all_guest
> +        movzwl VCPUINFO_upcall_pending(%rax),%eax
> +        decl  %eax
> +        cmpl  $0xfe,%eax
> +        ja    restore_all_guest
>  /*process_guest_events:*/
>          sti
>          leaq  VCPU_trap_bounce(%rbx),%rdx
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Sep 11 13:34:29 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 2012 13:34:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TBQbd-0003hJ-6K; Tue, 11 Sep 2012 13:34: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 1TBQbb-0003gf-UA
	for xen-devel@lists.xen.org; Tue, 11 Sep 2012 13:34:20 +0000
Received: from [85.158.143.35:36222] by server-2.bemta-4.messagelabs.com id
	40/C0-21239-BDD3F405; Tue, 11 Sep 2012 13:34:19 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1347370458!13156707!1
X-Originating-IP: [209.85.215.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9717 invoked from network); 11 Sep 2012 13:34:18 -0000
Received: from mail-ey0-f173.google.com (HELO mail-ey0-f173.google.com)
	(209.85.215.173)
	by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Sep 2012 13:34:18 -0000
Received: by eaac13 with SMTP id c13so293294eaa.32
	for <xen-devel@lists.xen.org>; Tue, 11 Sep 2012 06:34:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:user-agent:date:subject:from:to:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=6m7LkXHZuBG22GSs4pyLXSPVEgWDvdeq+NAc1BoygTw=;
	b=nLSYUqRnv3ncYLmr7dv+nP4bVS3rtE0zbIVpo0J4r1stbP8go0ni4CcJQAKQOupQFp
	c1ccDQZtjAObPIRBauvgWz9qVMoA3/ICAx6uV5uwfgBxKrEJQUCa8+71Thnt4lPQxLZW
	pYdYIEo6wRMnJh5jp+0yV3ugwyBveOhK23SOvqVTVB5Xcj+M4xygpmihUgPTU3Ov+d/C
	n55ifWy+90+FZ/5eWzInDdRNhPZzr67vVpNzV9PYpksCIBlDxVY3eI0dvWgBX9tTrQXQ
	s2jWgb0We6mHwpYNg2fyyLsSG0VLD+hR1Aydw39O1eUlZY9XttE1ky8RmAwTtX10E99A
	BsBQ==
Received: by 10.14.180.68 with SMTP id i44mr25710606eem.20.1347370458380;
	Tue, 11 Sep 2012 06:34:18 -0700 (PDT)
Received: from [192.168.1.3] (host86-184-74-117.range86-184.btcentralplus.com.
	[86.184.74.117])
	by mx.google.com with ESMTPS id v3sm47159221eep.10.2012.09.11.06.34.09
	(version=SSLv3 cipher=OTHER); Tue, 11 Sep 2012 06:34:16 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.33.0.120411
Date: Tue, 11 Sep 2012 14:34:05 +0100
From: Keir Fraser <keir@xen.org>
To: Jan Beulich <JBeulich@suse.com>,
	xen-devel <xen-devel@lists.xen.org>
Message-ID: <CC74FC5D.4B717%keir@xen.org>
Thread-Topic: [Xen-devel] [PATCH] x86-64/EFI: allow chaining of config files
Thread-Index: Ac2QIhzLnBXZ/DuiI0+q/y8rM7fv3Q==
In-Reply-To: <504F4148020000780009A919@nat28.tlf.novell.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] [PATCH] x86-64/EFI: allow chaining of config files
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/09/2012 12:48, "Jan Beulich" <JBeulich@suse.com> wrote:

> Namely when making use the CONFIG_XEN_COMPAT_* options in the legacy
> Linux kernels, newer kernels may not be compatible with older
> hypervisors, so trying to boot such a combination makes little sense.
> Booting older kernels on newer hypervisors, however, has to always
> work.
> 
> With the way xen.efi looks for its configuration file, allowing
> individual configuration files to refer only to compatible kernels,
> and referring from an older- to a newer-hypervisor one (the kernels
> of which will, as said, necessarily be compatible with the older
> hypervisor) allows to greatly reduce redundancy at least in
> development environments where one frequently wants multiple
> hypervisors and kernles to be installed in parallel.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Acked-by: Keir Fraser <keir@xen.org>

> --- a/docs/misc/efi.markdown
> +++ b/docs/misc/efi.markdown
> @@ -75,6 +75,13 @@ Specifies an XSM module to load.
>  
>  Specifies a CPU microcode blob to load.
>  
> +###`chain=<filename>`
> +
> +Specifies an alternate configuration file to use in case the specified
> section
> +(and in particular its `kernel=` setting) can't be found in the default (or
> +specified) configuration file. This is only meaningful in the [global]
> section
> +and really not meant to be used together with the `-cfg=` command line
> option.
> +
>  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,
> --- a/xen/arch/x86/efi/boot.c
> +++ b/xen/arch/x86/efi/boot.c
> @@ -809,7 +809,26 @@ efi_start(EFI_HANDLE ImageHandle, EFI_SY
>      else
>          section.s = get_value(&cfg, "global", "default");
>  
> -    name.s = get_value(&cfg, section.s, "kernel");
> +    for ( ; ; )
> +    {
> +        name.s = get_value(&cfg, section.s, "kernel");
> +        if ( name.s )
> +            break;
> +        name.s = get_value(&cfg, "global", "chain");
> +        if ( !name.s )
> +            break;
> +        efi_bs->FreePages(cfg.addr, PFN_UP(cfg.size));
> +        cfg.addr = 0;
> +        if ( !read_file(dir_handle, s2w(&name), &cfg) )
> +        {
> +            PrintStr(L"Chained configuration file '");
> +            PrintStr(name.w);
> +            efi_bs->FreePool(name.w);
> +            blexit(L"'not found\r\n");
> +        }
> +        pre_parse(&cfg);
> +        efi_bs->FreePool(name.w);
> +    }
>      if ( !name.s )
>          blexit(L"No Dom0 kernel image specified\r\n");
>      split_value(name.s);
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Sep 11 13:34:29 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 2012 13:34:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TBQbd-0003hJ-6K; Tue, 11 Sep 2012 13:34: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 1TBQbb-0003gf-UA
	for xen-devel@lists.xen.org; Tue, 11 Sep 2012 13:34:20 +0000
Received: from [85.158.143.35:36222] by server-2.bemta-4.messagelabs.com id
	40/C0-21239-BDD3F405; Tue, 11 Sep 2012 13:34:19 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1347370458!13156707!1
X-Originating-IP: [209.85.215.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9717 invoked from network); 11 Sep 2012 13:34:18 -0000
Received: from mail-ey0-f173.google.com (HELO mail-ey0-f173.google.com)
	(209.85.215.173)
	by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Sep 2012 13:34:18 -0000
Received: by eaac13 with SMTP id c13so293294eaa.32
	for <xen-devel@lists.xen.org>; Tue, 11 Sep 2012 06:34:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:user-agent:date:subject:from:to:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=6m7LkXHZuBG22GSs4pyLXSPVEgWDvdeq+NAc1BoygTw=;
	b=nLSYUqRnv3ncYLmr7dv+nP4bVS3rtE0zbIVpo0J4r1stbP8go0ni4CcJQAKQOupQFp
	c1ccDQZtjAObPIRBauvgWz9qVMoA3/ICAx6uV5uwfgBxKrEJQUCa8+71Thnt4lPQxLZW
	pYdYIEo6wRMnJh5jp+0yV3ugwyBveOhK23SOvqVTVB5Xcj+M4xygpmihUgPTU3Ov+d/C
	n55ifWy+90+FZ/5eWzInDdRNhPZzr67vVpNzV9PYpksCIBlDxVY3eI0dvWgBX9tTrQXQ
	s2jWgb0We6mHwpYNg2fyyLsSG0VLD+hR1Aydw39O1eUlZY9XttE1ky8RmAwTtX10E99A
	BsBQ==
Received: by 10.14.180.68 with SMTP id i44mr25710606eem.20.1347370458380;
	Tue, 11 Sep 2012 06:34:18 -0700 (PDT)
Received: from [192.168.1.3] (host86-184-74-117.range86-184.btcentralplus.com.
	[86.184.74.117])
	by mx.google.com with ESMTPS id v3sm47159221eep.10.2012.09.11.06.34.09
	(version=SSLv3 cipher=OTHER); Tue, 11 Sep 2012 06:34:16 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.33.0.120411
Date: Tue, 11 Sep 2012 14:34:05 +0100
From: Keir Fraser <keir@xen.org>
To: Jan Beulich <JBeulich@suse.com>,
	xen-devel <xen-devel@lists.xen.org>
Message-ID: <CC74FC5D.4B717%keir@xen.org>
Thread-Topic: [Xen-devel] [PATCH] x86-64/EFI: allow chaining of config files
Thread-Index: Ac2QIhzLnBXZ/DuiI0+q/y8rM7fv3Q==
In-Reply-To: <504F4148020000780009A919@nat28.tlf.novell.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] [PATCH] x86-64/EFI: allow chaining of config files
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 11/09/2012 12:48, "Jan Beulich" <JBeulich@suse.com> wrote:

> Namely when making use the CONFIG_XEN_COMPAT_* options in the legacy
> Linux kernels, newer kernels may not be compatible with older
> hypervisors, so trying to boot such a combination makes little sense.
> Booting older kernels on newer hypervisors, however, has to always
> work.
> 
> With the way xen.efi looks for its configuration file, allowing
> individual configuration files to refer only to compatible kernels,
> and referring from an older- to a newer-hypervisor one (the kernels
> of which will, as said, necessarily be compatible with the older
> hypervisor) allows to greatly reduce redundancy at least in
> development environments where one frequently wants multiple
> hypervisors and kernles to be installed in parallel.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Acked-by: Keir Fraser <keir@xen.org>

> --- a/docs/misc/efi.markdown
> +++ b/docs/misc/efi.markdown
> @@ -75,6 +75,13 @@ Specifies an XSM module to load.
>  
>  Specifies a CPU microcode blob to load.
>  
> +###`chain=<filename>`
> +
> +Specifies an alternate configuration file to use in case the specified
> section
> +(and in particular its `kernel=` setting) can't be found in the default (or
> +specified) configuration file. This is only meaningful in the [global]
> section
> +and really not meant to be used together with the `-cfg=` command line
> option.
> +
>  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,
> --- a/xen/arch/x86/efi/boot.c
> +++ b/xen/arch/x86/efi/boot.c
> @@ -809,7 +809,26 @@ efi_start(EFI_HANDLE ImageHandle, EFI_SY
>      else
>          section.s = get_value(&cfg, "global", "default");
>  
> -    name.s = get_value(&cfg, section.s, "kernel");
> +    for ( ; ; )
> +    {
> +        name.s = get_value(&cfg, section.s, "kernel");
> +        if ( name.s )
> +            break;
> +        name.s = get_value(&cfg, "global", "chain");
> +        if ( !name.s )
> +            break;
> +        efi_bs->FreePages(cfg.addr, PFN_UP(cfg.size));
> +        cfg.addr = 0;
> +        if ( !read_file(dir_handle, s2w(&name), &cfg) )
> +        {
> +            PrintStr(L"Chained configuration file '");
> +            PrintStr(name.w);
> +            efi_bs->FreePool(name.w);
> +            blexit(L"'not found\r\n");
> +        }
> +        pre_parse(&cfg);
> +        efi_bs->FreePool(name.w);
> +    }
>      if ( !name.s )
>          blexit(L"No Dom0 kernel image specified\r\n");
>      split_value(name.s);
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Sep 11 13:34:42 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 2012 13:34: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 1TBQbt-0003o9-Js; Tue, 11 Sep 2012 13:34:37 +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 1TBQbs-0003nV-7b
	for xen-devel@lists.xen.org; Tue, 11 Sep 2012 13:34:36 +0000
Received: from [85.158.143.99:61211] by server-3.bemta-4.messagelabs.com id
	30/7F-08232-BED3F405; Tue, 11 Sep 2012 13:34:35 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-10.tower-216.messagelabs.com!1347370448!23346213!1
X-Originating-IP: [63.239.67.9]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3349 invoked from network); 11 Sep 2012 13:34:10 -0000
Received: from emvm-gh1-uea08.nsa.gov (HELO nsa.gov) (63.239.67.9)
	by server-10.tower-216.messagelabs.com with SMTP;
	11 Sep 2012 13:34:10 -0000
X-TM-IMSS-Message-ID: <3435803c000f3008@nsa.gov>
Received: from tarius.tycho.ncsc.mil ([144.51.3.1]) by nsa.gov ([63.239.67.9])
	with ESMTP (TREND IMSS SMTP Service 7.1) id 3435803c000f3008 ;
	Tue, 11 Sep 2012 09:33:55 -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 q8BDY1MH018941; 
	Tue, 11 Sep 2012 09:34:01 -0400
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: Ian Campbell <Ian.Campbell@citrix.com>
Date: Tue, 11 Sep 2012 09:33:57 -0400
Message-Id: <1347370437-31882-1-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.11.4
In-Reply-To: <504F3DBA.5040904@tycho.nsa.gov>
References: <504F3DBA.5040904@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>, keir@xen.org,
	Jan Beulich <JBeulich@suse.com>, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH] xen/console: Add domain ID to output if VERBOSE
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 compiling with VERBOSE, any domain can output to the serial
console; add a domain ID prefix similar to the (XEN) prefix used by the
hypervisor to make it possible to distinguish the source of each
message. This is especially useful for debugging stub domains.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 xen/drivers/char/console.c | 16 ++++++++++++++++
 1 file changed, 16 insertions(+)

diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c
index e10bed5..ccef303 100644
--- a/xen/drivers/char/console.c
+++ b/xen/drivers/char/console.c
@@ -324,6 +324,10 @@ static long guest_console_write(XEN_GUEST_HANDLE(char) buffer, int count)
 {
     char kbuf[128], *kptr;
     int kcount;
+#ifdef VERBOSE
+    static domid_t active = DOMID_IDLE;
+    char pbuf[10];
+#endif
 
     while ( count > 0 )
     {
@@ -339,6 +343,18 @@ static long guest_console_write(XEN_GUEST_HANDLE(char) buffer, int count)
 
         spin_lock_irq(&console_lock);
 
+#ifdef VERBOSE
+        snprintf(pbuf, sizeof(pbuf), "(%d) ", current->domain->domain_id);
+        if (active != current->domain->domain_id) {
+            sercon_puts(pbuf);
+            vga_puts(pbuf);
+
+            active = current->domain->domain_id;
+        }
+        if (strchr(kbuf, '\n'))
+            active = DOMID_IDLE;
+#endif
+
         sercon_puts(kbuf);
         vga_puts(kbuf);
 
-- 
1.7.11.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 11 13:34:42 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 2012 13:34: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 1TBQbt-0003o9-Js; Tue, 11 Sep 2012 13:34:37 +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 1TBQbs-0003nV-7b
	for xen-devel@lists.xen.org; Tue, 11 Sep 2012 13:34:36 +0000
Received: from [85.158.143.99:61211] by server-3.bemta-4.messagelabs.com id
	30/7F-08232-BED3F405; Tue, 11 Sep 2012 13:34:35 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-10.tower-216.messagelabs.com!1347370448!23346213!1
X-Originating-IP: [63.239.67.9]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3349 invoked from network); 11 Sep 2012 13:34:10 -0000
Received: from emvm-gh1-uea08.nsa.gov (HELO nsa.gov) (63.239.67.9)
	by server-10.tower-216.messagelabs.com with SMTP;
	11 Sep 2012 13:34:10 -0000
X-TM-IMSS-Message-ID: <3435803c000f3008@nsa.gov>
Received: from tarius.tycho.ncsc.mil ([144.51.3.1]) by nsa.gov ([63.239.67.9])
	with ESMTP (TREND IMSS SMTP Service 7.1) id 3435803c000f3008 ;
	Tue, 11 Sep 2012 09:33:55 -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 q8BDY1MH018941; 
	Tue, 11 Sep 2012 09:34:01 -0400
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: Ian Campbell <Ian.Campbell@citrix.com>
Date: Tue, 11 Sep 2012 09:33:57 -0400
Message-Id: <1347370437-31882-1-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.11.4
In-Reply-To: <504F3DBA.5040904@tycho.nsa.gov>
References: <504F3DBA.5040904@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>, keir@xen.org,
	Jan Beulich <JBeulich@suse.com>, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH] xen/console: Add domain ID to output if VERBOSE
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 compiling with VERBOSE, any domain can output to the serial
console; add a domain ID prefix similar to the (XEN) prefix used by the
hypervisor to make it possible to distinguish the source of each
message. This is especially useful for debugging stub domains.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 xen/drivers/char/console.c | 16 ++++++++++++++++
 1 file changed, 16 insertions(+)

diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c
index e10bed5..ccef303 100644
--- a/xen/drivers/char/console.c
+++ b/xen/drivers/char/console.c
@@ -324,6 +324,10 @@ static long guest_console_write(XEN_GUEST_HANDLE(char) buffer, int count)
 {
     char kbuf[128], *kptr;
     int kcount;
+#ifdef VERBOSE
+    static domid_t active = DOMID_IDLE;
+    char pbuf[10];
+#endif
 
     while ( count > 0 )
     {
@@ -339,6 +343,18 @@ static long guest_console_write(XEN_GUEST_HANDLE(char) buffer, int count)
 
         spin_lock_irq(&console_lock);
 
+#ifdef VERBOSE
+        snprintf(pbuf, sizeof(pbuf), "(%d) ", current->domain->domain_id);
+        if (active != current->domain->domain_id) {
+            sercon_puts(pbuf);
+            vga_puts(pbuf);
+
+            active = current->domain->domain_id;
+        }
+        if (strchr(kbuf, '\n'))
+            active = DOMID_IDLE;
+#endif
+
         sercon_puts(kbuf);
         vga_puts(kbuf);
 
-- 
1.7.11.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 11 13:34:59 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 2012 13:34:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TBQcA-0003u1-1U; Tue, 11 Sep 2012 13:34:54 +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 1TBQc8-0003tS-GN
	for xen-devel@lists.xen.org; Tue, 11 Sep 2012 13:34:52 +0000
Received: from [85.158.138.51:35454] by server-2.bemta-3.messagelabs.com id
	F5/4F-04862-BFD3F405; Tue, 11 Sep 2012 13:34:51 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1347370490!21036668!1
X-Originating-IP: [209.85.215.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30131 invoked from network); 11 Sep 2012 13:34:51 -0000
Received: from mail-ey0-f173.google.com (HELO mail-ey0-f173.google.com)
	(209.85.215.173)
	by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Sep 2012 13:34:51 -0000
Received: by eaac13 with SMTP id c13so293667eaa.32
	for <xen-devel@lists.xen.org>; Tue, 11 Sep 2012 06:34:50 -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=8MC4+UYqNdS4/XGXIRwRKvQZcH92i2IymWvfvNgu5Uk=;
	b=japwcFiPnkZpqHsZKw1gIOU4mEsikJQYEHYjCsE7ArvYJ7WsSJFOdP+3L3q/vl5LOW
	xyu8uhh2J+JBmmhAsNiwMe6QrYFzPAK5Bdz/Ju3NX2Pq7+oCpPcGOdggq4FgbXsaBwiJ
	I4J9FAn70IA+Y4gcm3x0C5RiFBtn3ao/stDRXkm8wS8lwzx0a4aOIuPGJI49GnY9Uf7o
	UcrrNS/6kHBQ96yQJpkPIzXMXazcmeEetNXPsU/wplIIo5fBDP8yOuyZ8sS3zDdHdlq9
	Bs5aQlQol7CnznxpTbOyItuFBgO5lJwYk2zLpMPp6DgoMnMMMMiWrlcT9IPW/e7o0c41
	V1hQ==
Received: by 10.14.0.198 with SMTP id 46mr25680368eeb.30.1347370490712;
	Tue, 11 Sep 2012 06:34:50 -0700 (PDT)
Received: from [192.168.1.3] (host86-184-74-117.range86-184.btcentralplus.com.
	[86.184.74.117])
	by mx.google.com with ESMTPS id e7sm47200983eep.2.2012.09.11.06.34.48
	(version=SSLv3 cipher=OTHER); Tue, 11 Sep 2012 06:34:49 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.33.0.120411
Date: Tue, 11 Sep 2012 14:34:39 +0100
From: Keir Fraser <keir@xen.org>
To: Jan Beulich <JBeulich@suse.com>,
	xen-devel <xen-devel@lists.xen.org>
Message-ID: <CC74FC7F.4B718%keir@xen.org>
Thread-Topic: [Xen-devel] [PATCH] gnttab: cleanup of number-of-active-frames
	calculations
Thread-Index: Ac2QIjEPDEQvLasERkinsfZecVffFA==
In-Reply-To: <504F4368020000780009A927@nat28.tlf.novell.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] [PATCH] gnttab: cleanup of number-of-active-frames
 calculations
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/09/2012 12:58, "Jan Beulich" <JBeulich@suse.com> wrote:

> max_nr_active_grant_frames() is merly is special case of
> num_act_frames_from_sha_frames(), so there's no need to have a special
> case implementation for it.
> 
> Further, some of the related definitions (including the "struct
> active_grant_entry" definition itself) can (and hence should) really be
> private to grant_table.c.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Acked-by: Keir Fraser <keir@xen.org>

> --- a/xen/common/grant_table.c
> +++ b/xen/common/grant_table.c
> @@ -127,10 +127,45 @@ shared_entry_header(struct grant_table *
>      else
>          return &shared_entry_v2(t, ref).hdr;
>  }
> +
> +/* Active grant entry - used for shadowing GTF_permit_access grants. */
> +struct active_grant_entry {
> +    u32           pin;    /* Reference count information.             */
> +    domid_t       domid;  /* Domain being granted access.             */
> +    struct domain *trans_domain;
> +    uint32_t      trans_gref;
> +    unsigned long frame;  /* Frame being granted.                     */
> +    unsigned long gfn;    /* Guest's idea of the frame being granted. */
> +    unsigned      is_sub_page:1; /* True if this is a sub-page grant. */
> +    unsigned      start:15; /* For sub-page grants, the start offset
> +                               in the page.                           */
> +    unsigned      length:16; /* For sub-page grants, the length of the
> +                                grant.                                */
> +};
> +
>  #define ACGNT_PER_PAGE (PAGE_SIZE / sizeof(struct active_grant_entry))
>  #define active_entry(t, e) \
>      ((t)->active[(e)/ACGNT_PER_PAGE][(e)%ACGNT_PER_PAGE])
>  
> +static inline unsigned int
> +num_act_frames_from_sha_frames(const unsigned int num)
> +{
> +    /* How many frames are needed for the active grant table,
> +     * given the size of the shared grant table? */
> +    unsigned int sha_per_page = PAGE_SIZE / sizeof(grant_entry_v1_t);
> +    unsigned int num_sha_entries = num * sha_per_page;
> +    return (num_sha_entries + (ACGNT_PER_PAGE - 1)) / ACGNT_PER_PAGE;
> +}
> +
> +#define max_nr_active_grant_frames \
> +    num_act_frames_from_sha_frames(max_nr_grant_frames)
> +
> +static inline unsigned int
> +nr_active_grant_frames(struct grant_table *gt)
> +{
> +    return num_act_frames_from_sha_frames(nr_grant_frames(gt));
> +}
> +
>  /* Check if the page has been paged out, or needs unsharing.
>     If rc == GNTST_okay, *page contains the page struct with a ref taken.
>     Caller must do put_page(*page).
> @@ -2542,13 +2577,6 @@ do_grant_table_op(
>  #include "compat/grant_table.c"
>  #endif
>  
> -static unsigned int max_nr_active_grant_frames(void)
> -{
> -    return (((max_nr_grant_frames * (PAGE_SIZE / sizeof(grant_entry_v1_t))) +
> -                    ((PAGE_SIZE / sizeof(struct active_grant_entry))-1))
> -                   / (PAGE_SIZE / sizeof(struct active_grant_entry)));
> -}
> -
>  int 
>  grant_table_create(
>      struct domain *d)
> @@ -2565,7 +2593,7 @@ grant_table_create(
>  
>      /* Active grant table. */
>      if ( (t->active = xzalloc_array(struct active_grant_entry *,
> -                                    max_nr_active_grant_frames())) == NULL )
> +                                    max_nr_active_grant_frames)) == NULL )
>          goto no_mem_1;
>      for ( i = 0;
>            i < num_act_frames_from_sha_frames(INITIAL_NR_GRANT_FRAMES); i++ )
> --- a/xen/include/xen/grant_table.h
> +++ b/xen/include/xen/grant_table.h
> @@ -28,21 +28,6 @@
>  #include <asm/page.h>
>  #include <asm/grant_table.h>
>  
> -/* Active grant entry - used for shadowing GTF_permit_access grants. */
> -struct active_grant_entry {
> -    u32           pin;    /* Reference count information.             */
> -    domid_t       domid;  /* Domain being granted access.             */
> -    struct domain *trans_domain;
> -    uint32_t      trans_gref;
> -    unsigned long frame;  /* Frame being granted.                     */
> -    unsigned long gfn;    /* Guest's idea of the frame being granted. */
> -    unsigned      is_sub_page:1; /* True if this is a sub-page grant. */
> -    unsigned      start:15; /* For sub-page grants, the start offset
> -                               in the page.                           */
> -    unsigned      length:16; /* For sub-page grants, the length of the
> -                                grant.                                */
> -};
> -
>   /* Count of writable host-CPU mappings. */
>  #define GNTPIN_hstw_shift    (0)
>  #define GNTPIN_hstw_inc      (1 << GNTPIN_hstw_shift)
> @@ -147,23 +132,4 @@ static inline unsigned int grant_to_stat
>          GRANT_STATUS_PER_PAGE;
>  }
>  
> -static inline unsigned int
> -num_act_frames_from_sha_frames(const unsigned int num)
> -{
> -    /* How many frames are needed for the active grant table,
> -     * given the size of the shared grant table? */
> -    unsigned act_per_page = PAGE_SIZE / sizeof(struct active_grant_entry);
> -    unsigned sha_per_page = PAGE_SIZE / sizeof(grant_entry_v1_t);
> -    unsigned num_sha_entries = num * sha_per_page;
> -    unsigned num_act_frames =
> -        (num_sha_entries + (act_per_page-1)) / act_per_page;
> -    return num_act_frames;
> -}
> -
> -static inline unsigned int
> -nr_active_grant_frames(struct grant_table *gt)
> -{
> -    return num_act_frames_from_sha_frames(nr_grant_frames(gt));
> -}
> -
>  #endif /* __XEN_GRANT_TABLE_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 Sep 11 13:34:59 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 2012 13:34:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TBQcA-0003u1-1U; Tue, 11 Sep 2012 13:34:54 +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 1TBQc8-0003tS-GN
	for xen-devel@lists.xen.org; Tue, 11 Sep 2012 13:34:52 +0000
Received: from [85.158.138.51:35454] by server-2.bemta-3.messagelabs.com id
	F5/4F-04862-BFD3F405; Tue, 11 Sep 2012 13:34:51 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1347370490!21036668!1
X-Originating-IP: [209.85.215.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30131 invoked from network); 11 Sep 2012 13:34:51 -0000
Received: from mail-ey0-f173.google.com (HELO mail-ey0-f173.google.com)
	(209.85.215.173)
	by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Sep 2012 13:34:51 -0000
Received: by eaac13 with SMTP id c13so293667eaa.32
	for <xen-devel@lists.xen.org>; Tue, 11 Sep 2012 06:34:50 -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=8MC4+UYqNdS4/XGXIRwRKvQZcH92i2IymWvfvNgu5Uk=;
	b=japwcFiPnkZpqHsZKw1gIOU4mEsikJQYEHYjCsE7ArvYJ7WsSJFOdP+3L3q/vl5LOW
	xyu8uhh2J+JBmmhAsNiwMe6QrYFzPAK5Bdz/Ju3NX2Pq7+oCpPcGOdggq4FgbXsaBwiJ
	I4J9FAn70IA+Y4gcm3x0C5RiFBtn3ao/stDRXkm8wS8lwzx0a4aOIuPGJI49GnY9Uf7o
	UcrrNS/6kHBQ96yQJpkPIzXMXazcmeEetNXPsU/wplIIo5fBDP8yOuyZ8sS3zDdHdlq9
	Bs5aQlQol7CnznxpTbOyItuFBgO5lJwYk2zLpMPp6DgoMnMMMMiWrlcT9IPW/e7o0c41
	V1hQ==
Received: by 10.14.0.198 with SMTP id 46mr25680368eeb.30.1347370490712;
	Tue, 11 Sep 2012 06:34:50 -0700 (PDT)
Received: from [192.168.1.3] (host86-184-74-117.range86-184.btcentralplus.com.
	[86.184.74.117])
	by mx.google.com with ESMTPS id e7sm47200983eep.2.2012.09.11.06.34.48
	(version=SSLv3 cipher=OTHER); Tue, 11 Sep 2012 06:34:49 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.33.0.120411
Date: Tue, 11 Sep 2012 14:34:39 +0100
From: Keir Fraser <keir@xen.org>
To: Jan Beulich <JBeulich@suse.com>,
	xen-devel <xen-devel@lists.xen.org>
Message-ID: <CC74FC7F.4B718%keir@xen.org>
Thread-Topic: [Xen-devel] [PATCH] gnttab: cleanup of number-of-active-frames
	calculations
Thread-Index: Ac2QIjEPDEQvLasERkinsfZecVffFA==
In-Reply-To: <504F4368020000780009A927@nat28.tlf.novell.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] [PATCH] gnttab: cleanup of number-of-active-frames
 calculations
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/09/2012 12:58, "Jan Beulich" <JBeulich@suse.com> wrote:

> max_nr_active_grant_frames() is merly is special case of
> num_act_frames_from_sha_frames(), so there's no need to have a special
> case implementation for it.
> 
> Further, some of the related definitions (including the "struct
> active_grant_entry" definition itself) can (and hence should) really be
> private to grant_table.c.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Acked-by: Keir Fraser <keir@xen.org>

> --- a/xen/common/grant_table.c
> +++ b/xen/common/grant_table.c
> @@ -127,10 +127,45 @@ shared_entry_header(struct grant_table *
>      else
>          return &shared_entry_v2(t, ref).hdr;
>  }
> +
> +/* Active grant entry - used for shadowing GTF_permit_access grants. */
> +struct active_grant_entry {
> +    u32           pin;    /* Reference count information.             */
> +    domid_t       domid;  /* Domain being granted access.             */
> +    struct domain *trans_domain;
> +    uint32_t      trans_gref;
> +    unsigned long frame;  /* Frame being granted.                     */
> +    unsigned long gfn;    /* Guest's idea of the frame being granted. */
> +    unsigned      is_sub_page:1; /* True if this is a sub-page grant. */
> +    unsigned      start:15; /* For sub-page grants, the start offset
> +                               in the page.                           */
> +    unsigned      length:16; /* For sub-page grants, the length of the
> +                                grant.                                */
> +};
> +
>  #define ACGNT_PER_PAGE (PAGE_SIZE / sizeof(struct active_grant_entry))
>  #define active_entry(t, e) \
>      ((t)->active[(e)/ACGNT_PER_PAGE][(e)%ACGNT_PER_PAGE])
>  
> +static inline unsigned int
> +num_act_frames_from_sha_frames(const unsigned int num)
> +{
> +    /* How many frames are needed for the active grant table,
> +     * given the size of the shared grant table? */
> +    unsigned int sha_per_page = PAGE_SIZE / sizeof(grant_entry_v1_t);
> +    unsigned int num_sha_entries = num * sha_per_page;
> +    return (num_sha_entries + (ACGNT_PER_PAGE - 1)) / ACGNT_PER_PAGE;
> +}
> +
> +#define max_nr_active_grant_frames \
> +    num_act_frames_from_sha_frames(max_nr_grant_frames)
> +
> +static inline unsigned int
> +nr_active_grant_frames(struct grant_table *gt)
> +{
> +    return num_act_frames_from_sha_frames(nr_grant_frames(gt));
> +}
> +
>  /* Check if the page has been paged out, or needs unsharing.
>     If rc == GNTST_okay, *page contains the page struct with a ref taken.
>     Caller must do put_page(*page).
> @@ -2542,13 +2577,6 @@ do_grant_table_op(
>  #include "compat/grant_table.c"
>  #endif
>  
> -static unsigned int max_nr_active_grant_frames(void)
> -{
> -    return (((max_nr_grant_frames * (PAGE_SIZE / sizeof(grant_entry_v1_t))) +
> -                    ((PAGE_SIZE / sizeof(struct active_grant_entry))-1))
> -                   / (PAGE_SIZE / sizeof(struct active_grant_entry)));
> -}
> -
>  int 
>  grant_table_create(
>      struct domain *d)
> @@ -2565,7 +2593,7 @@ grant_table_create(
>  
>      /* Active grant table. */
>      if ( (t->active = xzalloc_array(struct active_grant_entry *,
> -                                    max_nr_active_grant_frames())) == NULL )
> +                                    max_nr_active_grant_frames)) == NULL )
>          goto no_mem_1;
>      for ( i = 0;
>            i < num_act_frames_from_sha_frames(INITIAL_NR_GRANT_FRAMES); i++ )
> --- a/xen/include/xen/grant_table.h
> +++ b/xen/include/xen/grant_table.h
> @@ -28,21 +28,6 @@
>  #include <asm/page.h>
>  #include <asm/grant_table.h>
>  
> -/* Active grant entry - used for shadowing GTF_permit_access grants. */
> -struct active_grant_entry {
> -    u32           pin;    /* Reference count information.             */
> -    domid_t       domid;  /* Domain being granted access.             */
> -    struct domain *trans_domain;
> -    uint32_t      trans_gref;
> -    unsigned long frame;  /* Frame being granted.                     */
> -    unsigned long gfn;    /* Guest's idea of the frame being granted. */
> -    unsigned      is_sub_page:1; /* True if this is a sub-page grant. */
> -    unsigned      start:15; /* For sub-page grants, the start offset
> -                               in the page.                           */
> -    unsigned      length:16; /* For sub-page grants, the length of the
> -                                grant.                                */
> -};
> -
>   /* Count of writable host-CPU mappings. */
>  #define GNTPIN_hstw_shift    (0)
>  #define GNTPIN_hstw_inc      (1 << GNTPIN_hstw_shift)
> @@ -147,23 +132,4 @@ static inline unsigned int grant_to_stat
>          GRANT_STATUS_PER_PAGE;
>  }
>  
> -static inline unsigned int
> -num_act_frames_from_sha_frames(const unsigned int num)
> -{
> -    /* How many frames are needed for the active grant table,
> -     * given the size of the shared grant table? */
> -    unsigned act_per_page = PAGE_SIZE / sizeof(struct active_grant_entry);
> -    unsigned sha_per_page = PAGE_SIZE / sizeof(grant_entry_v1_t);
> -    unsigned num_sha_entries = num * sha_per_page;
> -    unsigned num_act_frames =
> -        (num_sha_entries + (act_per_page-1)) / act_per_page;
> -    return num_act_frames;
> -}
> -
> -static inline unsigned int
> -nr_active_grant_frames(struct grant_table *gt)
> -{
> -    return num_act_frames_from_sha_frames(nr_grant_frames(gt));
> -}
> -
>  #endif /* __XEN_GRANT_TABLE_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 Sep 11 13:37:20 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 2012 13:37:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TBQeN-0004PN-K8; Tue, 11 Sep 2012 13:37:11 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <agasheac@gmail.com>) id 1TBQeM-0004PB-6o
	for xen-devel@lists.xen.org; Tue, 11 Sep 2012 13:37:10 +0000
Received: from [85.158.143.35:58596] by server-2.bemta-4.messagelabs.com id
	0C/96-21239-58E3F405; Tue, 11 Sep 2012 13:37:09 +0000
X-Env-Sender: agasheac@gmail.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1347370620!17801038!1
X-Originating-IP: [209.85.210.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-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22091 invoked from network); 11 Sep 2012 13:37:01 -0000
Received: from mail-iy0-f173.google.com (HELO mail-iy0-f173.google.com)
	(209.85.210.173)
	by server-14.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Sep 2012 13:37:01 -0000
Received: by iakx26 with SMTP id x26so470989iak.32
	for <xen-devel@lists.xen.org>; Tue, 11 Sep 2012 06:37:00 -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=VXxSGJoIOArZFmfTT8DZytahhtnqyTnur+vjgaiN5q4=;
	b=SgWyMeXTwbnL9K8rOC4zL8BhuCbKFytRGMzP+KkJxnkL2FI6AZUFlCETGMV1x9oUza
	MTRcgnLdcoj48Xu6ml6g8q+Ao7kpeF19W7UynBxbCPYISuwSFMXyVDr1RP4kmnUKfM7p
	OXNvFpHSXL0gRu72Uza/Kbs0l1yTH/2Qs+7PFjLCC3zd5LWtKP8UaSnkm1MEU6lj3LMj
	RWt3O9X1YZuPt13Lw3jk+Sfwxz7nuV4sZMyobUzXne+UY8X/kIr9DoaO71fFXQBs3TMS
	rbo27Tzg8WPKs2OIwj9JP2uF9JafeVy4cyhDU/7cLDo0lRMjwkXPLJ31DEoSRK30frdY
	ymkQ==
MIME-Version: 1.0
Received: by 10.50.34.196 with SMTP id b4mr16376401igj.4.1347370620033; Tue,
	11 Sep 2012 06:37:00 -0700 (PDT)
Received: by 10.42.152.131 with HTTP; Tue, 11 Sep 2012 06:37:00 -0700 (PDT)
Date: Tue, 11 Sep 2012 19:07:00 +0530
Message-ID: <CAMQ5s704d8-UscdPtpJ8GPMs_YzTjiOupdi9mWfpfDrRnYV=vQ@mail.gmail.com>
From: =?UTF-8?B?4KSF4KSo4KS/4KSV4KWH4KSkIOCkhuCkl+CkvuCktuClhyA=?=
	<agasheac@gmail.com>
To: xen-devel@lists.xen.org
Subject: [Xen-devel] xen not able to use total physical memory present in
	the system (192GB)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0776943475209096230=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============0776943475209096230==
Content-Type: multipart/alternative; boundary=14dae934086d3019e904c96d2b30

--14dae934086d3019e904c96d2b30
Content-Type: text/plain; charset=ISO-8859-1

Hi

I am using xen-4.1.2 with fedora-16 (kernel version 3.1.0.7) as dom0 on
system having 192GB of RAM.

When i booted system xm info shows (total _memory parameter as 192GB and
free_memory as 25MB) full memory but /proc/meminfo reports 132GB and xm
list also reports 192GB for dom0

When I ran first VM with 32GB RAM, xm info started reporting memory for
dom0 around 132GB and 32GB for VM and cat /proc/meminfo on dom0 reported
around 100GB. I am able to boot 4 VMs with this setup but 5th VM fails to
boot with not enough memory.


ultimately not able to use full system memory ? 60GB went missing from
memory.

http://old-list-archives.xen.org/archives/html/xen-devel/2009-07/msg00521.html

On this thread,

Jan mentined

"the hypervisor has been validated to work fine with 1Tb for much longer, it was
really the Dom0 kernel that had issues when not passing a dom0_mem=
option".

I am not using this option "dom0_mem". Is anybody faced any issue like this ?


Thanks,
Aniket

--14dae934086d3019e904c96d2b30
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi<br><br>I am using xen-4.1.2 with fedora-16 (kernel version 3.1.0.7) as d=
om0 on system having 192GB of RAM.<br><br>When i booted system xm info show=
s (total _memory parameter as 192GB and free_memory as 25MB) full memory bu=
t /proc/meminfo reports 132GB and xm list also reports 192GB for dom0<br>
<br>When I ran first VM with 32GB RAM, xm info started reporting memory for=
 dom0 around 132GB and 32GB for VM and cat /proc/meminfo on dom0 reported a=
round 100GB. I am able to boot 4 VMs with this setup but 5th VM fails to bo=
ot with not enough memory.<br>
<br><br>ultimately not able to use full system memory ? 60GB went missing f=
rom memory. <br><br><a href=3D"http://old-list-archives.xen.org/archives/ht=
ml/xen-devel/2009-07/msg00521.html">http://old-list-archives.xen.org/archiv=
es/html/xen-devel/2009-07/msg00521.html</a><br>
<br>On this thread, <br><br>Jan mentined <br><pre>&quot;the hypervisor has =
been validated to work fine with 1Tb for much longer, it was
really the Dom0 kernel that had issues when not passing a dom0_mem=3D
option&quot;.<br><br>I am not using this option &quot;dom0_mem&quot;. Is an=
ybody faced any issue like this ?<br><br><br>Thanks,<br>Aniket<br></pre><br=
>

--14dae934086d3019e904c96d2b30--


--===============0776943475209096230==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============0776943475209096230==--


From xen-devel-bounces@lists.xen.org Tue Sep 11 13:37:20 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 2012 13:37:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TBQeN-0004PN-K8; Tue, 11 Sep 2012 13:37:11 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <agasheac@gmail.com>) id 1TBQeM-0004PB-6o
	for xen-devel@lists.xen.org; Tue, 11 Sep 2012 13:37:10 +0000
Received: from [85.158.143.35:58596] by server-2.bemta-4.messagelabs.com id
	0C/96-21239-58E3F405; Tue, 11 Sep 2012 13:37:09 +0000
X-Env-Sender: agasheac@gmail.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1347370620!17801038!1
X-Originating-IP: [209.85.210.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-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22091 invoked from network); 11 Sep 2012 13:37:01 -0000
Received: from mail-iy0-f173.google.com (HELO mail-iy0-f173.google.com)
	(209.85.210.173)
	by server-14.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Sep 2012 13:37:01 -0000
Received: by iakx26 with SMTP id x26so470989iak.32
	for <xen-devel@lists.xen.org>; Tue, 11 Sep 2012 06:37:00 -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=VXxSGJoIOArZFmfTT8DZytahhtnqyTnur+vjgaiN5q4=;
	b=SgWyMeXTwbnL9K8rOC4zL8BhuCbKFytRGMzP+KkJxnkL2FI6AZUFlCETGMV1x9oUza
	MTRcgnLdcoj48Xu6ml6g8q+Ao7kpeF19W7UynBxbCPYISuwSFMXyVDr1RP4kmnUKfM7p
	OXNvFpHSXL0gRu72Uza/Kbs0l1yTH/2Qs+7PFjLCC3zd5LWtKP8UaSnkm1MEU6lj3LMj
	RWt3O9X1YZuPt13Lw3jk+Sfwxz7nuV4sZMyobUzXne+UY8X/kIr9DoaO71fFXQBs3TMS
	rbo27Tzg8WPKs2OIwj9JP2uF9JafeVy4cyhDU/7cLDo0lRMjwkXPLJ31DEoSRK30frdY
	ymkQ==
MIME-Version: 1.0
Received: by 10.50.34.196 with SMTP id b4mr16376401igj.4.1347370620033; Tue,
	11 Sep 2012 06:37:00 -0700 (PDT)
Received: by 10.42.152.131 with HTTP; Tue, 11 Sep 2012 06:37:00 -0700 (PDT)
Date: Tue, 11 Sep 2012 19:07:00 +0530
Message-ID: <CAMQ5s704d8-UscdPtpJ8GPMs_YzTjiOupdi9mWfpfDrRnYV=vQ@mail.gmail.com>
From: =?UTF-8?B?4KSF4KSo4KS/4KSV4KWH4KSkIOCkhuCkl+CkvuCktuClhyA=?=
	<agasheac@gmail.com>
To: xen-devel@lists.xen.org
Subject: [Xen-devel] xen not able to use total physical memory present in
	the system (192GB)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0776943475209096230=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============0776943475209096230==
Content-Type: multipart/alternative; boundary=14dae934086d3019e904c96d2b30

--14dae934086d3019e904c96d2b30
Content-Type: text/plain; charset=ISO-8859-1

Hi

I am using xen-4.1.2 with fedora-16 (kernel version 3.1.0.7) as dom0 on
system having 192GB of RAM.

When i booted system xm info shows (total _memory parameter as 192GB and
free_memory as 25MB) full memory but /proc/meminfo reports 132GB and xm
list also reports 192GB for dom0

When I ran first VM with 32GB RAM, xm info started reporting memory for
dom0 around 132GB and 32GB for VM and cat /proc/meminfo on dom0 reported
around 100GB. I am able to boot 4 VMs with this setup but 5th VM fails to
boot with not enough memory.


ultimately not able to use full system memory ? 60GB went missing from
memory.

http://old-list-archives.xen.org/archives/html/xen-devel/2009-07/msg00521.html

On this thread,

Jan mentined

"the hypervisor has been validated to work fine with 1Tb for much longer, it was
really the Dom0 kernel that had issues when not passing a dom0_mem=
option".

I am not using this option "dom0_mem". Is anybody faced any issue like this ?


Thanks,
Aniket

--14dae934086d3019e904c96d2b30
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi<br><br>I am using xen-4.1.2 with fedora-16 (kernel version 3.1.0.7) as d=
om0 on system having 192GB of RAM.<br><br>When i booted system xm info show=
s (total _memory parameter as 192GB and free_memory as 25MB) full memory bu=
t /proc/meminfo reports 132GB and xm list also reports 192GB for dom0<br>
<br>When I ran first VM with 32GB RAM, xm info started reporting memory for=
 dom0 around 132GB and 32GB for VM and cat /proc/meminfo on dom0 reported a=
round 100GB. I am able to boot 4 VMs with this setup but 5th VM fails to bo=
ot with not enough memory.<br>
<br><br>ultimately not able to use full system memory ? 60GB went missing f=
rom memory. <br><br><a href=3D"http://old-list-archives.xen.org/archives/ht=
ml/xen-devel/2009-07/msg00521.html">http://old-list-archives.xen.org/archiv=
es/html/xen-devel/2009-07/msg00521.html</a><br>
<br>On this thread, <br><br>Jan mentined <br><pre>&quot;the hypervisor has =
been validated to work fine with 1Tb for much longer, it was
really the Dom0 kernel that had issues when not passing a dom0_mem=3D
option&quot;.<br><br>I am not using this option &quot;dom0_mem&quot;. Is an=
ybody faced any issue like this ?<br><br><br>Thanks,<br>Aniket<br></pre><br=
>

--14dae934086d3019e904c96d2b30--


--===============0776943475209096230==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============0776943475209096230==--


From xen-devel-bounces@lists.xen.org Tue Sep 11 13:40:59 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 2012 13:40:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TBQhv-0004in-8R; Tue, 11 Sep 2012 13:40:51 +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 1TBQht-0004id-Op
	for xen-devel@lists.xen.org; Tue, 11 Sep 2012 13:40:49 +0000
Received: from [85.158.138.51:60401] by server-9.bemta-3.messagelabs.com id
	8F/D8-15390-06F3F405; Tue, 11 Sep 2012 13:40:48 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-13.tower-174.messagelabs.com!1347370847!11242876!1
X-Originating-IP: [63.239.67.9]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6640 invoked from network); 11 Sep 2012 13:40:47 -0000
Received: from emvm-gh1-uea08.nsa.gov (HELO nsa.gov) (63.239.67.9)
	by server-13.tower-174.messagelabs.com with SMTP;
	11 Sep 2012 13:40:47 -0000
X-TM-IMSS-Message-ID: <343ba4db000f31a9@nsa.gov>
Received: from tarius.tycho.ncsc.mil ([144.51.3.1]) by nsa.gov ([63.239.67.9])
	with ESMTP (TREND IMSS SMTP Service 7.1) id 343ba4db000f31a9 ;
	Tue, 11 Sep 2012 09:40:37 -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 q8BDeh5Q019525; 
	Tue, 11 Sep 2012 09:40:43 -0400
Message-ID: <504F3F5B.6070200@tycho.nsa.gov>
Date: Tue, 11 Sep 2012 09:40:43 -0400
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Organization: National Security Agency
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120828 Thunderbird/15.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <1347306553-20980-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1347306553-20980-18-git-send-email-dgdegra@tycho.nsa.gov>
	<504F0AA9020000780009A704@nat28.tlf.novell.com>
In-Reply-To: <504F0AA9020000780009A704@nat28.tlf.novell.com>
Cc: Tim Deegan <tim@xen.org>, Keir Fraser <keir@xen.org>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 17/20] arch/x86: use XSM hooks for
 get_pg_owner access checks
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 09/11/2012 03:55 AM, Jan Beulich wrote:
>>>> On 10.09.12 at 21:49, Daniel De Graaf <dgdegra@tycho.nsa.gov> wrote:
>> --- a/xen/arch/x86/mm.c
>> +++ b/xen/arch/x86/mm.c
>> @@ -2882,11 +2882,6 @@ static struct domain *get_pg_owner(domid_t domid)
>>          pg_owner = rcu_lock_domain(dom_io);
>>          break;
>>      case DOMID_XEN:
>> -        if ( !IS_PRIV(curr) )
>> -        {
>> -            MEM_LOG("Cannot set foreign dom");
>> -            break;
>> -        }
>>          pg_owner = rcu_lock_domain(dom_xen);
>>          break;
>>      default:
>> @@ -2895,12 +2890,6 @@ static struct domain *get_pg_owner(domid_t domid)
>>              MEM_LOG("Unknown domain '%u'", domid);
>>              break;
>>          }
>> -        if ( !IS_PRIV_FOR(curr, pg_owner) )
>> -        {
>> -            MEM_LOG("Cannot set foreign dom");
>> -            rcu_unlock_domain(pg_owner);
>> -            pg_owner = NULL;
>> -        }
>>          break;
>>      }
>>  
>> @@ -3008,6 +2997,13 @@ long do_mmuext_op(
>>          goto out;
>>      }
>>  
>> +    rc = xsm_mmuext_op(d, pg_owner);
>> +    if ( rc )
>> +    {
>> +        rcu_unlock_domain(pg_owner);
>> +        goto out;
>> +    }
>> +
> 
> While this part is fine, ...
> 
>>      for ( i = 0; i < count; i++ )
>>      {
>>          if ( hypercall_preempt_check() )
>> @@ -3483,11 +3479,6 @@ long do_mmu_update(
>>              rc = -EINVAL;
>>              goto out;
>>          }
>> -        if ( !IS_PRIV_FOR(d, pt_owner) )
>> -        {
>> -            rc = -ESRCH;
>> -            goto out;
>> -        }
> 
> ... this one isn't (at least in conjunction with them all becoming
> indirect calls unconditionally) - you replace a single validation per
> set of requests with one validation per request.
> 
> Jan
> 
> 

Is it still a problem if the check is inlined? If so, I could add an
additional XSM hook where the old IS_PRIV check was done, and make the
check inside the loop an inlined noop in the XSM-disabled case.

-- 
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 Tue Sep 11 13:40:59 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 2012 13:40:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TBQhv-0004in-8R; Tue, 11 Sep 2012 13:40:51 +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 1TBQht-0004id-Op
	for xen-devel@lists.xen.org; Tue, 11 Sep 2012 13:40:49 +0000
Received: from [85.158.138.51:60401] by server-9.bemta-3.messagelabs.com id
	8F/D8-15390-06F3F405; Tue, 11 Sep 2012 13:40:48 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-13.tower-174.messagelabs.com!1347370847!11242876!1
X-Originating-IP: [63.239.67.9]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6640 invoked from network); 11 Sep 2012 13:40:47 -0000
Received: from emvm-gh1-uea08.nsa.gov (HELO nsa.gov) (63.239.67.9)
	by server-13.tower-174.messagelabs.com with SMTP;
	11 Sep 2012 13:40:47 -0000
X-TM-IMSS-Message-ID: <343ba4db000f31a9@nsa.gov>
Received: from tarius.tycho.ncsc.mil ([144.51.3.1]) by nsa.gov ([63.239.67.9])
	with ESMTP (TREND IMSS SMTP Service 7.1) id 343ba4db000f31a9 ;
	Tue, 11 Sep 2012 09:40:37 -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 q8BDeh5Q019525; 
	Tue, 11 Sep 2012 09:40:43 -0400
Message-ID: <504F3F5B.6070200@tycho.nsa.gov>
Date: Tue, 11 Sep 2012 09:40:43 -0400
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Organization: National Security Agency
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120828 Thunderbird/15.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <1347306553-20980-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1347306553-20980-18-git-send-email-dgdegra@tycho.nsa.gov>
	<504F0AA9020000780009A704@nat28.tlf.novell.com>
In-Reply-To: <504F0AA9020000780009A704@nat28.tlf.novell.com>
Cc: Tim Deegan <tim@xen.org>, Keir Fraser <keir@xen.org>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 17/20] arch/x86: use XSM hooks for
 get_pg_owner access checks
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 09/11/2012 03:55 AM, Jan Beulich wrote:
>>>> On 10.09.12 at 21:49, Daniel De Graaf <dgdegra@tycho.nsa.gov> wrote:
>> --- a/xen/arch/x86/mm.c
>> +++ b/xen/arch/x86/mm.c
>> @@ -2882,11 +2882,6 @@ static struct domain *get_pg_owner(domid_t domid)
>>          pg_owner = rcu_lock_domain(dom_io);
>>          break;
>>      case DOMID_XEN:
>> -        if ( !IS_PRIV(curr) )
>> -        {
>> -            MEM_LOG("Cannot set foreign dom");
>> -            break;
>> -        }
>>          pg_owner = rcu_lock_domain(dom_xen);
>>          break;
>>      default:
>> @@ -2895,12 +2890,6 @@ static struct domain *get_pg_owner(domid_t domid)
>>              MEM_LOG("Unknown domain '%u'", domid);
>>              break;
>>          }
>> -        if ( !IS_PRIV_FOR(curr, pg_owner) )
>> -        {
>> -            MEM_LOG("Cannot set foreign dom");
>> -            rcu_unlock_domain(pg_owner);
>> -            pg_owner = NULL;
>> -        }
>>          break;
>>      }
>>  
>> @@ -3008,6 +2997,13 @@ long do_mmuext_op(
>>          goto out;
>>      }
>>  
>> +    rc = xsm_mmuext_op(d, pg_owner);
>> +    if ( rc )
>> +    {
>> +        rcu_unlock_domain(pg_owner);
>> +        goto out;
>> +    }
>> +
> 
> While this part is fine, ...
> 
>>      for ( i = 0; i < count; i++ )
>>      {
>>          if ( hypercall_preempt_check() )
>> @@ -3483,11 +3479,6 @@ long do_mmu_update(
>>              rc = -EINVAL;
>>              goto out;
>>          }
>> -        if ( !IS_PRIV_FOR(d, pt_owner) )
>> -        {
>> -            rc = -ESRCH;
>> -            goto out;
>> -        }
> 
> ... this one isn't (at least in conjunction with them all becoming
> indirect calls unconditionally) - you replace a single validation per
> set of requests with one validation per request.
> 
> Jan
> 
> 

Is it still a problem if the check is inlined? If so, I could add an
additional XSM hook where the old IS_PRIV check was done, and make the
check inside the loop an inlined noop in the XSM-disabled case.

-- 
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 Tue Sep 11 13:49:29 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 2012 13:49:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TBQq1-0004ue-7q; Tue, 11 Sep 2012 13:49:13 +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 1TBQpz-0004uZ-Ez
	for xen-devel@lists.xen.org; Tue, 11 Sep 2012 13:49:11 +0000
Received: from [85.158.138.51:53582] by server-3.bemta-3.messagelabs.com id
	A2/A7-21322-6514F405; Tue, 11 Sep 2012 13:49:10 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-16.tower-174.messagelabs.com!1347371349!29835305!1
X-Originating-IP: [63.239.67.9]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1619 invoked from network); 11 Sep 2012 13:49:09 -0000
Received: from emvm-gh1-uea08.nsa.gov (HELO nsa.gov) (63.239.67.9)
	by server-16.tower-174.messagelabs.com with SMTP;
	11 Sep 2012 13:49:09 -0000
X-TM-IMSS-Message-ID: <34433ef8000f339f@nsa.gov>
Received: from tarius.tycho.ncsc.mil ([144.51.3.1]) by nsa.gov ([63.239.67.9])
	with ESMTP (TREND IMSS SMTP Service 7.1) id 34433ef8000f339f ;
	Tue, 11 Sep 2012 09:48:56 -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 q8BDn1aC019792; 
	Tue, 11 Sep 2012 09:49:01 -0400
Message-ID: <504F414D.5070504@tycho.nsa.gov>
Date: Tue, 11 Sep 2012 09:49:01 -0400
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Organization: National Security Agency
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120828 Thunderbird/15.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <CC741BAD.4B395%keir@xen.org>
	<1347353677.5305.130.camel@zakaz.uk.xensource.com>
In-Reply-To: <1347353677.5305.130.camel@zakaz.uk.xensource.com>
Cc: Keir Fraser <keir@xen.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v2] Merge IS_PRIV checks into XSM hooks
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 09/11/2012 04:54 AM, Ian Campbell wrote:
> On Mon, 2012-09-10 at 22:35 +0100, Keir Fraser wrote:
>> On 10/09/2012 22:10, "Daniel De Graaf" <dgdegra@tycho.nsa.gov> wrote:
>>
>>> On 09/10/2012 04:51 PM, Keir Fraser wrote:
>>>> On 10/09/2012 20:48, "Daniel De Graaf" <dgdegra@tycho.nsa.gov> wrote:
>>>>
>>>>> Overall, this series should not change the behavior of Xen when XSM is
>>>>> not enabled; however, in some cases, the exact errors that are returned
>>>>> will be different because security checks have been moved below validity
>>>>> checks. Also, once applied, newly introduced domctls and sysctls will
>>>>> not automatically be guarded by IS_PRIV checks - they will need to add
>>>>> their own permission checking code.
>>>>
>>>> How do we guard against accidentally forgetting to do this?
>>>
>>> The same way you guard against it when adding a new hypercall: when adding
>>> new functionality that needs access checks, also add the access checks.
>>
>> So... We just shouldn't accidentally forget. That will work well. ;)
>> Historically XSM has not been top of many committers' checklists.
> 
> Can we play tricks like
> 
> 	int did_priv_check;
> 
> 	switch(op)
> 	case FOO:
> 		if (xsm_check_foo(&did_priv_check))
> 		....
> 		break;
> 	}
> 	ASSERT(did_priv_check)
> 
> I'd expect the compiler to catch missing checks due to the use of the
> uninitialised var, although that relies somewhat on the switch not being
> too big and confusing it.

This is almost certainly going to confuse the compiler, since often the
XSM hook is after some minimal parameter validation which will break on
failure. Using an initialized variable would work, but I like the other
option better.

> The other option might be to define domctl_do_perm_check, which has a
> similar switch over op but an explicit default: return -EPERM. Then call
> that from the top of do_domctl instead of scattering the priv checks
> throughout the main switch statement? That way if you forget to add the
> perm check it simply won't work and you'll see that the first time you
> try and test it...

Or even just default back to IS_PRIV, and a FLASK unknown_domctl permission
that is documented as only for development (or just -EPERM in FLASK, since
most developers who would turn that on would also be interested in adding
the full XSM hook).

> Or an array of do_perm_check function pointers of NR_DOMCTL in size and
> a NULL check? The differing prototypes probably make this one a
> non-starter without loads of per op helper functions.
> 
> Ian.


-- 
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 Tue Sep 11 13:49:29 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 2012 13:49:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TBQq1-0004ue-7q; Tue, 11 Sep 2012 13:49:13 +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 1TBQpz-0004uZ-Ez
	for xen-devel@lists.xen.org; Tue, 11 Sep 2012 13:49:11 +0000
Received: from [85.158.138.51:53582] by server-3.bemta-3.messagelabs.com id
	A2/A7-21322-6514F405; Tue, 11 Sep 2012 13:49:10 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-16.tower-174.messagelabs.com!1347371349!29835305!1
X-Originating-IP: [63.239.67.9]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1619 invoked from network); 11 Sep 2012 13:49:09 -0000
Received: from emvm-gh1-uea08.nsa.gov (HELO nsa.gov) (63.239.67.9)
	by server-16.tower-174.messagelabs.com with SMTP;
	11 Sep 2012 13:49:09 -0000
X-TM-IMSS-Message-ID: <34433ef8000f339f@nsa.gov>
Received: from tarius.tycho.ncsc.mil ([144.51.3.1]) by nsa.gov ([63.239.67.9])
	with ESMTP (TREND IMSS SMTP Service 7.1) id 34433ef8000f339f ;
	Tue, 11 Sep 2012 09:48:56 -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 q8BDn1aC019792; 
	Tue, 11 Sep 2012 09:49:01 -0400
Message-ID: <504F414D.5070504@tycho.nsa.gov>
Date: Tue, 11 Sep 2012 09:49:01 -0400
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Organization: National Security Agency
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120828 Thunderbird/15.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <CC741BAD.4B395%keir@xen.org>
	<1347353677.5305.130.camel@zakaz.uk.xensource.com>
In-Reply-To: <1347353677.5305.130.camel@zakaz.uk.xensource.com>
Cc: Keir Fraser <keir@xen.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v2] Merge IS_PRIV checks into XSM hooks
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 09/11/2012 04:54 AM, Ian Campbell wrote:
> On Mon, 2012-09-10 at 22:35 +0100, Keir Fraser wrote:
>> On 10/09/2012 22:10, "Daniel De Graaf" <dgdegra@tycho.nsa.gov> wrote:
>>
>>> On 09/10/2012 04:51 PM, Keir Fraser wrote:
>>>> On 10/09/2012 20:48, "Daniel De Graaf" <dgdegra@tycho.nsa.gov> wrote:
>>>>
>>>>> Overall, this series should not change the behavior of Xen when XSM is
>>>>> not enabled; however, in some cases, the exact errors that are returned
>>>>> will be different because security checks have been moved below validity
>>>>> checks. Also, once applied, newly introduced domctls and sysctls will
>>>>> not automatically be guarded by IS_PRIV checks - they will need to add
>>>>> their own permission checking code.
>>>>
>>>> How do we guard against accidentally forgetting to do this?
>>>
>>> The same way you guard against it when adding a new hypercall: when adding
>>> new functionality that needs access checks, also add the access checks.
>>
>> So... We just shouldn't accidentally forget. That will work well. ;)
>> Historically XSM has not been top of many committers' checklists.
> 
> Can we play tricks like
> 
> 	int did_priv_check;
> 
> 	switch(op)
> 	case FOO:
> 		if (xsm_check_foo(&did_priv_check))
> 		....
> 		break;
> 	}
> 	ASSERT(did_priv_check)
> 
> I'd expect the compiler to catch missing checks due to the use of the
> uninitialised var, although that relies somewhat on the switch not being
> too big and confusing it.

This is almost certainly going to confuse the compiler, since often the
XSM hook is after some minimal parameter validation which will break on
failure. Using an initialized variable would work, but I like the other
option better.

> The other option might be to define domctl_do_perm_check, which has a
> similar switch over op but an explicit default: return -EPERM. Then call
> that from the top of do_domctl instead of scattering the priv checks
> throughout the main switch statement? That way if you forget to add the
> perm check it simply won't work and you'll see that the first time you
> try and test it...

Or even just default back to IS_PRIV, and a FLASK unknown_domctl permission
that is documented as only for development (or just -EPERM in FLASK, since
most developers who would turn that on would also be interested in adding
the full XSM hook).

> Or an array of do_perm_check function pointers of NR_DOMCTL in size and
> a NULL check? The differing prototypes probably make this one a
> non-starter without loads of per op helper functions.
> 
> Ian.


-- 
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 Tue Sep 11 13:52:38 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 2012 13: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 1TBQt5-00054i-Vo; Tue, 11 Sep 2012 13:52:23 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1TBQt4-00054c-I1
	for xen-devel@lists.xensource.com; Tue, 11 Sep 2012 13:52:22 +0000
Received: from [85.158.143.99:12746] by server-3.bemta-4.messagelabs.com id
	43/C6-08232-5124F405; Tue, 11 Sep 2012 13:52:21 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1347371540!22223393!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDg1NjI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30717 invoked from network); 11 Sep 2012 13:52:21 -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;
	11 Sep 2012 13:52:21 -0000
X-IronPort-AV: E=Sophos;i="4.80,404,1344211200"; d="scan'208";a="14472283"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Sep 2012 13:52:20 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Tue, 11 Sep 2012 14:52: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 1TBQt2-0007NV-Jy;
	Tue, 11 Sep 2012 13:52:20 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1TBQt2-0002pz-5A;
	Tue, 11 Sep 2012 14:52:20 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-13676-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Tue, 11 Sep 2012 14:52:20 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [qemu-upstream-unstable test] 13676: 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 13676 qemu-upstream-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13676/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail like 13670
 test-amd64-i386-xl-qemuu-win7-amd64  9 guest-localmigrate      fail like 13670
 test-amd64-i386-xl-qemuu-win-vcpus1  9 guest-localmigrate      fail like 13670
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  9 guest-localmigrate fail like 13670
 test-i386-i386-xl-qemuu-winxpsp3  9 guest-localmigrate         fail like 13670
 test-amd64-amd64-xl-qemuu-win  9 guest-localmigrate           fail  like 13670
 test-i386-i386-xl-qemuu-win   9 guest-localmigrate           fail   like 13670
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail like 13670

Tests which did not succeed, but are not blocking:
 test-i386-i386-qemuu-win     16 leak-check/check             fail   never pass
 test-amd64-amd64-qemuu-win   16 leak-check/check             fail   never pass
 test-amd64-i386-qemuu-win    16 leak-check/check             fail   never pass
 test-amd64-i386-xend-qemuu-winxpsp3 16 leak-check/check        fail never pass
 test-amd64-i386-qemuu-win-vcpus1 16 leak-check/check           fail never pass

version targeted for testing:
 qemuu                cdf4d2bb4006805f209712fbb8ed1f83127e9984
baseline version:
 qemuu                9e63a82dd13cdfc80c1f401cc99a682ab4b81542

------------------------------------------------------------
People who touched revisions under test:
  Frediano Ziglio <frediano.ziglio@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-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-win-vcpus1                             fail    
 test-amd64-i386-xl-qemuu-win-vcpus1                          fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-amd64-qemuu-win                                   fail    
 test-amd64-i386-qemuu-win                                    fail    
 test-i386-i386-qemuu-win                                     fail    
 test-amd64-amd64-xl-qemuu-win                                fail    
 test-i386-i386-xl-qemuu-win                                  fail    
 test-amd64-i386-xend-qemuu-winxpsp3                          fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=qemu-upstream-unstable
+ revision=cdf4d2bb4006805f209712fbb8ed1f83127e9984
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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 cdf4d2bb4006805f209712fbb8ed1f83127e9984
+ branch=qemu-upstream-unstable
+ revision=cdf4d2bb4006805f209712fbb8ed1f83127e9984
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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/hg/staging/xen-unstable.hg
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : xen@xenbits.xensource.com:git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.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 cdf4d2bb4006805f209712fbb8ed1f83127e9984:master
Counting objects: 5, done.
Compressing objects: 100% (1/1)   
Compressing objects: 100% (1/1), done.
Writing objects:  33% (1/3)   
Writing objects:  66% (2/3)   
Writing objects: 100% (3/3)   
Writing objects: 100% (3/3), 694 bytes, done.
Total 3 (delta 2), reused 3 (delta 2)
To xen@xenbits.xensource.com:git/qemu-upstream-unstable.git
   9e63a82..cdf4d2b  cdf4d2bb4006805f209712fbb8ed1f83127e9984 -> master

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 11 13:52:38 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 2012 13: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 1TBQt5-00054i-Vo; Tue, 11 Sep 2012 13:52:23 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1TBQt4-00054c-I1
	for xen-devel@lists.xensource.com; Tue, 11 Sep 2012 13:52:22 +0000
Received: from [85.158.143.99:12746] by server-3.bemta-4.messagelabs.com id
	43/C6-08232-5124F405; Tue, 11 Sep 2012 13:52:21 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1347371540!22223393!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDg1NjI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30717 invoked from network); 11 Sep 2012 13:52:21 -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;
	11 Sep 2012 13:52:21 -0000
X-IronPort-AV: E=Sophos;i="4.80,404,1344211200"; d="scan'208";a="14472283"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Sep 2012 13:52:20 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Tue, 11 Sep 2012 14:52: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 1TBQt2-0007NV-Jy;
	Tue, 11 Sep 2012 13:52:20 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1TBQt2-0002pz-5A;
	Tue, 11 Sep 2012 14:52:20 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-13676-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Tue, 11 Sep 2012 14:52:20 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [qemu-upstream-unstable test] 13676: 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 13676 qemu-upstream-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13676/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail like 13670
 test-amd64-i386-xl-qemuu-win7-amd64  9 guest-localmigrate      fail like 13670
 test-amd64-i386-xl-qemuu-win-vcpus1  9 guest-localmigrate      fail like 13670
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  9 guest-localmigrate fail like 13670
 test-i386-i386-xl-qemuu-winxpsp3  9 guest-localmigrate         fail like 13670
 test-amd64-amd64-xl-qemuu-win  9 guest-localmigrate           fail  like 13670
 test-i386-i386-xl-qemuu-win   9 guest-localmigrate           fail   like 13670
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail like 13670

Tests which did not succeed, but are not blocking:
 test-i386-i386-qemuu-win     16 leak-check/check             fail   never pass
 test-amd64-amd64-qemuu-win   16 leak-check/check             fail   never pass
 test-amd64-i386-qemuu-win    16 leak-check/check             fail   never pass
 test-amd64-i386-xend-qemuu-winxpsp3 16 leak-check/check        fail never pass
 test-amd64-i386-qemuu-win-vcpus1 16 leak-check/check           fail never pass

version targeted for testing:
 qemuu                cdf4d2bb4006805f209712fbb8ed1f83127e9984
baseline version:
 qemuu                9e63a82dd13cdfc80c1f401cc99a682ab4b81542

------------------------------------------------------------
People who touched revisions under test:
  Frediano Ziglio <frediano.ziglio@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-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-win-vcpus1                             fail    
 test-amd64-i386-xl-qemuu-win-vcpus1                          fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-amd64-qemuu-win                                   fail    
 test-amd64-i386-qemuu-win                                    fail    
 test-i386-i386-qemuu-win                                     fail    
 test-amd64-amd64-xl-qemuu-win                                fail    
 test-i386-i386-xl-qemuu-win                                  fail    
 test-amd64-i386-xend-qemuu-winxpsp3                          fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=qemu-upstream-unstable
+ revision=cdf4d2bb4006805f209712fbb8ed1f83127e9984
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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 cdf4d2bb4006805f209712fbb8ed1f83127e9984
+ branch=qemu-upstream-unstable
+ revision=cdf4d2bb4006805f209712fbb8ed1f83127e9984
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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/hg/staging/xen-unstable.hg
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : xen@xenbits.xensource.com:git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.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 cdf4d2bb4006805f209712fbb8ed1f83127e9984:master
Counting objects: 5, done.
Compressing objects: 100% (1/1)   
Compressing objects: 100% (1/1), done.
Writing objects:  33% (1/3)   
Writing objects:  66% (2/3)   
Writing objects: 100% (3/3)   
Writing objects: 100% (3/3), 694 bytes, done.
Total 3 (delta 2), reused 3 (delta 2)
To xen@xenbits.xensource.com:git/qemu-upstream-unstable.git
   9e63a82..cdf4d2b  cdf4d2bb4006805f209712fbb8ed1f83127e9984 -> master

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 11 14:10:41 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 2012 14:10:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TBRAU-0005a4-Uz; Tue, 11 Sep 2012 14:10:22 +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 1TBRAT-0005Zj-MA
	for xen-devel@lists.xen.org; Tue, 11 Sep 2012 14:10:21 +0000
Received: from [85.158.143.35:51889] by server-3.bemta-4.messagelabs.com id
	C7/AE-08232-D464F405; Tue, 11 Sep 2012 14:10:21 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-16.tower-21.messagelabs.com!1347372619!15269110!1
X-Originating-IP: [63.239.67.9]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3080 invoked from network); 11 Sep 2012 14:10:19 -0000
Received: from emvm-gh1-uea08.nsa.gov (HELO nsa.gov) (63.239.67.9)
	by server-16.tower-21.messagelabs.com with SMTP;
	11 Sep 2012 14:10:19 -0000
X-TM-IMSS-Message-ID: <34569bd7000f3a4c@nsa.gov>
Received: from tarius.tycho.ncsc.mil ([144.51.3.1]) by nsa.gov ([63.239.67.9])
	with ESMTP (TREND IMSS SMTP Service 7.1) id 34569bd7000f3a4c ;
	Tue, 11 Sep 2012 10:10:05 -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 q8BEAAZP021467; 
	Tue, 11 Sep 2012 10:10:10 -0400
Message-ID: <504F4642.2080608@tycho.nsa.gov>
Date: Tue, 11 Sep 2012 10:10:10 -0400
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Organization: National Security Agency
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120828 Thunderbird/15.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <1347306553-20980-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1347306553-20980-12-git-send-email-dgdegra@tycho.nsa.gov>
	<504F045E020000780009A6B2@nat28.tlf.novell.com>
In-Reply-To: <504F045E020000780009A6B2@nat28.tlf.novell.com>
Cc: Keir Fraser <keir@xen.org>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 11/20] xen: use XSM instead of IS_PRIV where
	duplicated
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 09/11/2012 03:29 AM, Jan Beulich wrote:
>>>> On 10.09.12 at 21:49, Daniel De Graaf <dgdegra@tycho.nsa.gov> wrote:
>> Some checks are removed due to non-obvious duplicates in their callers:
>>
>>  * acpi_enter_sleep is checked by its only caller
>>  * map_domain_pirq has IS_PRIV_FOR checked in physdev_map_pirq
> 
> ... and ioapic_guest_write(). Please have this list complete, as it
> is going to be necessary to fully validate this (now and
> retrospectively once applied) for the absence of security holes.

I'll check callers again when resubmitting; I didn't generate this list
the first time I was doing the checks, so it has obviously missed a few.
The ioapic_guest_write function is checked by PHYSDEVOP_apic_write, so
it's also protected.

> 
>>  * PHYSDEVOP_alloc_irq_vector is a noop, does not need IS_PRIV
> 
> NAK. This nevertheless is a privileged operation (i.e. must not
> succeed for unprivileged guests).

Do we depend on this behavior? Anyway, I'll revert this chunk or replace
it with an xsm hook if there's an appropriate one.

>>  * Many PHYSDEVOP access checks are within the implementation functions
> 
> For the above named reason, please fully document this.
> 

Will do on resubmit.

[snip remainder, addressed in the thread with Ian's reply]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 11 14:10:41 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 2012 14:10:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TBRAU-0005a4-Uz; Tue, 11 Sep 2012 14:10:22 +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 1TBRAT-0005Zj-MA
	for xen-devel@lists.xen.org; Tue, 11 Sep 2012 14:10:21 +0000
Received: from [85.158.143.35:51889] by server-3.bemta-4.messagelabs.com id
	C7/AE-08232-D464F405; Tue, 11 Sep 2012 14:10:21 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-16.tower-21.messagelabs.com!1347372619!15269110!1
X-Originating-IP: [63.239.67.9]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3080 invoked from network); 11 Sep 2012 14:10:19 -0000
Received: from emvm-gh1-uea08.nsa.gov (HELO nsa.gov) (63.239.67.9)
	by server-16.tower-21.messagelabs.com with SMTP;
	11 Sep 2012 14:10:19 -0000
X-TM-IMSS-Message-ID: <34569bd7000f3a4c@nsa.gov>
Received: from tarius.tycho.ncsc.mil ([144.51.3.1]) by nsa.gov ([63.239.67.9])
	with ESMTP (TREND IMSS SMTP Service 7.1) id 34569bd7000f3a4c ;
	Tue, 11 Sep 2012 10:10:05 -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 q8BEAAZP021467; 
	Tue, 11 Sep 2012 10:10:10 -0400
Message-ID: <504F4642.2080608@tycho.nsa.gov>
Date: Tue, 11 Sep 2012 10:10:10 -0400
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Organization: National Security Agency
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120828 Thunderbird/15.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <1347306553-20980-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1347306553-20980-12-git-send-email-dgdegra@tycho.nsa.gov>
	<504F045E020000780009A6B2@nat28.tlf.novell.com>
In-Reply-To: <504F045E020000780009A6B2@nat28.tlf.novell.com>
Cc: Keir Fraser <keir@xen.org>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 11/20] xen: use XSM instead of IS_PRIV where
	duplicated
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 09/11/2012 03:29 AM, Jan Beulich wrote:
>>>> On 10.09.12 at 21:49, Daniel De Graaf <dgdegra@tycho.nsa.gov> wrote:
>> Some checks are removed due to non-obvious duplicates in their callers:
>>
>>  * acpi_enter_sleep is checked by its only caller
>>  * map_domain_pirq has IS_PRIV_FOR checked in physdev_map_pirq
> 
> ... and ioapic_guest_write(). Please have this list complete, as it
> is going to be necessary to fully validate this (now and
> retrospectively once applied) for the absence of security holes.

I'll check callers again when resubmitting; I didn't generate this list
the first time I was doing the checks, so it has obviously missed a few.
The ioapic_guest_write function is checked by PHYSDEVOP_apic_write, so
it's also protected.

> 
>>  * PHYSDEVOP_alloc_irq_vector is a noop, does not need IS_PRIV
> 
> NAK. This nevertheless is a privileged operation (i.e. must not
> succeed for unprivileged guests).

Do we depend on this behavior? Anyway, I'll revert this chunk or replace
it with an xsm hook if there's an appropriate one.

>>  * Many PHYSDEVOP access checks are within the implementation functions
> 
> For the above named reason, please fully document this.
> 

Will do on resubmit.

[snip remainder, addressed in the thread with Ian's reply]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 11 14:11:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 2012 14:11:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TBRAx-0005cB-C9; Tue, 11 Sep 2012 14:10:51 +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 1TBRAv-0005bb-Vb
	for Xen-devel@lists.xensource.com; Tue, 11 Sep 2012 14:10:50 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1347372625!5395813!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDg1NjI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29061 invoked from network); 11 Sep 2012 14:10:26 -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;
	11 Sep 2012 14:10:26 -0000
X-IronPort-AV: E=Sophos;i="4.80,405,1344211200"; d="scan'208";a="14472899"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Sep 2012 14:10: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.279.1;
	Tue, 11 Sep 2012 15:10:25 +0100
Message-ID: <1347372623.5305.170.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Mukesh Rathor <mukesh.rathor@oracle.com>
Date: Tue, 11 Sep 2012 15:10:23 +0100
In-Reply-To: <20120815180716.0049bffe@mantra.us.oracle.com>
References: <20120815180716.0049bffe@mantra.us.oracle.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [RFC PATCH 8/8]: PVH: privcmd changes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-08-16 at 02:07 +0100, Mukesh Rathor wrote:
> ---
>  drivers/xen/privcmd.c |   68 +++++++++++++++++++++++++++++++++++++++++++++++-
>  1 files changed, 66 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/xen/privcmd.c b/drivers/xen/privcmd.c
> index ccee0f1..0a240ab 100644
> --- a/drivers/xen/privcmd.c
> +++ b/drivers/xen/privcmd.c
> @@ -33,6 +33,7 @@
>  #include <xen/features.h>
>  #include <xen/page.h>
>  #include <xen/xen-ops.h>
> +#include <xen/balloon.h>
>  
>  #include "privcmd.h"
>  
> @@ -199,6 +200,10 @@ static long privcmd_ioctl_mmap(void __user *udata)
>  	if (!xen_initial_domain())
>  		return -EPERM;
>  
> +	/* PVH: TBD/FIXME. For now we only support privcmd_ioctl_mmap_batch */
> +	if (xen_pvh_domain())
> +		return -ENOSYS;
> +
>  	if (copy_from_user(&mmapcmd, udata, sizeof(mmapcmd)))
>  		return -EFAULT;
>  
> @@ -251,6 +256,8 @@ struct mmap_batch_state {
>  	xen_pfn_t __user *user;
>  };
>  
> +/* PVH dom0: if domU being created is PV, then mfn is mfn(addr on bus). If
> + * it's PVH then mfn is pfn (input to HAP). */
>  static int mmap_batch_fn(void *data, void *state)
>  {
>  	xen_pfn_t *mfnp = data;
> @@ -274,6 +281,40 @@ static int mmap_return_errors(void *data, void *state)
>  	return put_user(*mfnp, st->user++);
>  }
>  
> +/* Allocate pfns that are then mapped with gmfns from foreign domid. Update
> + * the vma with the page info to use later.
> + * Returns: 0 if success, otherwise -errno
> + */
> +static int pvh_privcmd_resv_pfns(struct vm_area_struct *vma, int numpgs)
> +{
> +	int rc;
> +	struct xen_pvh_sav_pfn_info *savp;
> +
> +	savp = kzalloc(sizeof(struct xen_pvh_sav_pfn_info), GFP_KERNEL);
> +	if (savp == NULL)
> +		return -ENOMEM;
> +
> +	savp->sp_paga = kcalloc(numpgs, sizeof(savp->sp_paga[0]), GFP_KERNEL);
> +	if (savp->sp_paga == NULL) {
> +		kfree(savp);
> +		return -ENOMEM;
> +	}
> +
> +	rc = alloc_xenballooned_pages(numpgs, savp->sp_paga, 0);
> +	if (rc != 0) {
> +		pr_warn("%s Could not alloc %d pfns rc:%d\n", __FUNCTION__,
> +			numpgs, rc);
> +		kfree(savp->sp_paga);
> +		kfree(savp);
> +		return -ENOMEM;
> +	}

I've just been building on this patch to make proper mmap foreign
support on ARM and I was looking for the place which freed this, both
the pages back to the balloon and then the array itself. There is code
in privcmd_close which unmaps the P2M, but I can't find the code which
frees things back to the balloon. Have I missed something?

I think we also need to think about the layering / abstraction a bit
here too. Currently on setup the caller allocates the array iff pvh and
stores it in the opaque vma->vm_private, then calls
xen_remap_domain_mfn_range which iff pvh calls pvh_add_to_xen_p2m which
assumes that the caller has seeded the vm_private with the correct
struct. xen_remap_domain_mfn_range also sets up the stage 1 PT mappings.

On teardown the iff pvh is in the caller which calls pvh_rem_xen_p2m
directly (this API is unbalanced with the setup side). The stage 1 PT
mappings are torn down implicitly somewhere else (in generic code, I
think you said).

(BTW, the terminology I'm using is stage 1 == guest OS page tables,
stage 2 == HAP)

I think you can't rely on the implicit teardown here since you need to
unmap before you hand the page back to the balloon. The reason this
doesn't look necessary now is that you don't give the page back.

Also not ordering the stage 1 and stage 2 teardown correctly is
dangerous, depending on the eventual ordering you potentially turn an
erroneous access to a virtual address, which should result in a guest OS
level page fault (and e.g. a seg fault to the offending process) into a
hypervisor shoots the guest due to an unexpected stage 2 fault type
failure, which is somewhat undesirable ;-)

With that in mind I think you do in the end need to add
xen_unmap_domain_mfn_range which does the unmap from both stage 1 and
stage 2 -- that balances out the interface (making pvh_rem_xen_p2m
internal) too, which is nice. This function may turn out to be a nop
on !pvh, but that's ok (although maybe there would be no harm in doing
explicit unmaps, for consistency?).

WRT passing data between interfaces in vma->vm_private, which is pretty
subtle, can we push that whole thing down into
xen_{remap,unmap}_domain_mfn_range too? This would make the requirement
on the caller be simple "never use vm_private", as opposed to now where
the requirement is "sometimes you might have to allocate some stuff and
stick it in here". The downside is that it pushes code which could be
generic down into per-arch stuff, although with suitable generic helper
functions this isn't so bad (whatever happened to
{alloc,free}_empty_pages_and_pagevec from the classic kernels? Those did
exactly what we want here, I think)

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 11 14:11:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 2012 14:11:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TBRAx-0005cB-C9; Tue, 11 Sep 2012 14:10:51 +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 1TBRAv-0005bb-Vb
	for Xen-devel@lists.xensource.com; Tue, 11 Sep 2012 14:10:50 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1347372625!5395813!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDg1NjI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29061 invoked from network); 11 Sep 2012 14:10:26 -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;
	11 Sep 2012 14:10:26 -0000
X-IronPort-AV: E=Sophos;i="4.80,405,1344211200"; d="scan'208";a="14472899"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Sep 2012 14:10: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.279.1;
	Tue, 11 Sep 2012 15:10:25 +0100
Message-ID: <1347372623.5305.170.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Mukesh Rathor <mukesh.rathor@oracle.com>
Date: Tue, 11 Sep 2012 15:10:23 +0100
In-Reply-To: <20120815180716.0049bffe@mantra.us.oracle.com>
References: <20120815180716.0049bffe@mantra.us.oracle.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [RFC PATCH 8/8]: PVH: privcmd changes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-08-16 at 02:07 +0100, Mukesh Rathor wrote:
> ---
>  drivers/xen/privcmd.c |   68 +++++++++++++++++++++++++++++++++++++++++++++++-
>  1 files changed, 66 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/xen/privcmd.c b/drivers/xen/privcmd.c
> index ccee0f1..0a240ab 100644
> --- a/drivers/xen/privcmd.c
> +++ b/drivers/xen/privcmd.c
> @@ -33,6 +33,7 @@
>  #include <xen/features.h>
>  #include <xen/page.h>
>  #include <xen/xen-ops.h>
> +#include <xen/balloon.h>
>  
>  #include "privcmd.h"
>  
> @@ -199,6 +200,10 @@ static long privcmd_ioctl_mmap(void __user *udata)
>  	if (!xen_initial_domain())
>  		return -EPERM;
>  
> +	/* PVH: TBD/FIXME. For now we only support privcmd_ioctl_mmap_batch */
> +	if (xen_pvh_domain())
> +		return -ENOSYS;
> +
>  	if (copy_from_user(&mmapcmd, udata, sizeof(mmapcmd)))
>  		return -EFAULT;
>  
> @@ -251,6 +256,8 @@ struct mmap_batch_state {
>  	xen_pfn_t __user *user;
>  };
>  
> +/* PVH dom0: if domU being created is PV, then mfn is mfn(addr on bus). If
> + * it's PVH then mfn is pfn (input to HAP). */
>  static int mmap_batch_fn(void *data, void *state)
>  {
>  	xen_pfn_t *mfnp = data;
> @@ -274,6 +281,40 @@ static int mmap_return_errors(void *data, void *state)
>  	return put_user(*mfnp, st->user++);
>  }
>  
> +/* Allocate pfns that are then mapped with gmfns from foreign domid. Update
> + * the vma with the page info to use later.
> + * Returns: 0 if success, otherwise -errno
> + */
> +static int pvh_privcmd_resv_pfns(struct vm_area_struct *vma, int numpgs)
> +{
> +	int rc;
> +	struct xen_pvh_sav_pfn_info *savp;
> +
> +	savp = kzalloc(sizeof(struct xen_pvh_sav_pfn_info), GFP_KERNEL);
> +	if (savp == NULL)
> +		return -ENOMEM;
> +
> +	savp->sp_paga = kcalloc(numpgs, sizeof(savp->sp_paga[0]), GFP_KERNEL);
> +	if (savp->sp_paga == NULL) {
> +		kfree(savp);
> +		return -ENOMEM;
> +	}
> +
> +	rc = alloc_xenballooned_pages(numpgs, savp->sp_paga, 0);
> +	if (rc != 0) {
> +		pr_warn("%s Could not alloc %d pfns rc:%d\n", __FUNCTION__,
> +			numpgs, rc);
> +		kfree(savp->sp_paga);
> +		kfree(savp);
> +		return -ENOMEM;
> +	}

I've just been building on this patch to make proper mmap foreign
support on ARM and I was looking for the place which freed this, both
the pages back to the balloon and then the array itself. There is code
in privcmd_close which unmaps the P2M, but I can't find the code which
frees things back to the balloon. Have I missed something?

I think we also need to think about the layering / abstraction a bit
here too. Currently on setup the caller allocates the array iff pvh and
stores it in the opaque vma->vm_private, then calls
xen_remap_domain_mfn_range which iff pvh calls pvh_add_to_xen_p2m which
assumes that the caller has seeded the vm_private with the correct
struct. xen_remap_domain_mfn_range also sets up the stage 1 PT mappings.

On teardown the iff pvh is in the caller which calls pvh_rem_xen_p2m
directly (this API is unbalanced with the setup side). The stage 1 PT
mappings are torn down implicitly somewhere else (in generic code, I
think you said).

(BTW, the terminology I'm using is stage 1 == guest OS page tables,
stage 2 == HAP)

I think you can't rely on the implicit teardown here since you need to
unmap before you hand the page back to the balloon. The reason this
doesn't look necessary now is that you don't give the page back.

Also not ordering the stage 1 and stage 2 teardown correctly is
dangerous, depending on the eventual ordering you potentially turn an
erroneous access to a virtual address, which should result in a guest OS
level page fault (and e.g. a seg fault to the offending process) into a
hypervisor shoots the guest due to an unexpected stage 2 fault type
failure, which is somewhat undesirable ;-)

With that in mind I think you do in the end need to add
xen_unmap_domain_mfn_range which does the unmap from both stage 1 and
stage 2 -- that balances out the interface (making pvh_rem_xen_p2m
internal) too, which is nice. This function may turn out to be a nop
on !pvh, but that's ok (although maybe there would be no harm in doing
explicit unmaps, for consistency?).

WRT passing data between interfaces in vma->vm_private, which is pretty
subtle, can we push that whole thing down into
xen_{remap,unmap}_domain_mfn_range too? This would make the requirement
on the caller be simple "never use vm_private", as opposed to now where
the requirement is "sometimes you might have to allocate some stuff and
stick it in here". The downside is that it pushes code which could be
generic down into per-arch stuff, although with suitable generic helper
functions this isn't so bad (whatever happened to
{alloc,free}_empty_pages_and_pagevec from the classic kernels? Those did
exactly what we want here, I think)

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 11 14:12:01 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 2012 14:12:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TBRBm-0005hs-TZ; Tue, 11 Sep 2012 14:11:42 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1TBRBl-0005he-F8
	for xen-devel@lists.xen.org; Tue, 11 Sep 2012 14:11:41 +0000
Received: from [85.158.143.99:11968] by server-3.bemta-4.messagelabs.com id
	7F/91-08232-C964F405; Tue, 11 Sep 2012 14:11:40 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1347372700!24511502!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQwNzc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4419 invoked from network); 11 Sep 2012 14:11:40 -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;
	11 Sep 2012 14:11:40 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 11 Sep 2012 15:11:40 +0100
Message-Id: <504F62B8020000780009AA96@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 11 Sep 2012 15:11:36 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Daniel De Graaf" <dgdegra@tycho.nsa.gov>
References: <CC741177.4B381%keir@xen.org> <504E5760.5070605@tycho.nsa.gov>
	<504F0DE3020000780009A727@nat28.tlf.novell.com>
	<504F3ADF.8030402@tycho.nsa.gov>
In-Reply-To: <504F3ADF.8030402@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 v2] Merge IS_PRIV checks into XSM hooks
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.09.12 at 15:21, Daniel De Graaf <dgdegra@tycho.nsa.gov> wrote:
> On 09/11/2012 04:09 AM, Jan Beulich wrote:
>>>>> On 10.09.12 at 23:10, Daniel De Graaf <dgdegra@tycho.nsa.gov> wrote:
>>> On 09/10/2012 04:51 PM, Keir Fraser wrote:
>>>> On 10/09/2012 20:48, "Daniel De Graaf" <dgdegra@tycho.nsa.gov> wrote:
>>>>
>>>>> Overall, this series should not change the behavior of Xen when XSM is
>>>>> not enabled; however, in some cases, the exact errors that are returned
>>>>> will be different because security checks have been moved below validity
>>>>> checks. Also, once applied, newly introduced domctls and sysctls will
>>>>> not automatically be guarded by IS_PRIV checks - they will need to add
>>>>> their own permission checking code.
>>>>
>>>> How do we guard against accidentally forgetting to do this?
>>>
>>> The same way you guard against it when adding a new hypercall: when adding
>>> new functionality that needs access checks, also add the access checks.
>> 
>> Except that previously the access check was done centrally at the
>> top of do_domctl(), so newly added sub-functions didn't need to
>> worry.
> 
> One addition I am considering is an extra XSM hook at the start of do_domctl
> and do_sysctl that takes only the command (and domain, for domctl); this
> could be used to restrict access to unknown domctl/sysctls, and would fix
> the issues of adding sub-functions without access checks.

That sounds reasonable, the more that the performance aspect
of these additions doesn't matter for these two hypercalls.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 11 14:12:01 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 2012 14:12:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TBRBm-0005hs-TZ; Tue, 11 Sep 2012 14:11:42 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1TBRBl-0005he-F8
	for xen-devel@lists.xen.org; Tue, 11 Sep 2012 14:11:41 +0000
Received: from [85.158.143.99:11968] by server-3.bemta-4.messagelabs.com id
	7F/91-08232-C964F405; Tue, 11 Sep 2012 14:11:40 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1347372700!24511502!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQwNzc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4419 invoked from network); 11 Sep 2012 14:11:40 -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;
	11 Sep 2012 14:11:40 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 11 Sep 2012 15:11:40 +0100
Message-Id: <504F62B8020000780009AA96@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 11 Sep 2012 15:11:36 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Daniel De Graaf" <dgdegra@tycho.nsa.gov>
References: <CC741177.4B381%keir@xen.org> <504E5760.5070605@tycho.nsa.gov>
	<504F0DE3020000780009A727@nat28.tlf.novell.com>
	<504F3ADF.8030402@tycho.nsa.gov>
In-Reply-To: <504F3ADF.8030402@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 v2] Merge IS_PRIV checks into XSM hooks
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.09.12 at 15:21, Daniel De Graaf <dgdegra@tycho.nsa.gov> wrote:
> On 09/11/2012 04:09 AM, Jan Beulich wrote:
>>>>> On 10.09.12 at 23:10, Daniel De Graaf <dgdegra@tycho.nsa.gov> wrote:
>>> On 09/10/2012 04:51 PM, Keir Fraser wrote:
>>>> On 10/09/2012 20:48, "Daniel De Graaf" <dgdegra@tycho.nsa.gov> wrote:
>>>>
>>>>> Overall, this series should not change the behavior of Xen when XSM is
>>>>> not enabled; however, in some cases, the exact errors that are returned
>>>>> will be different because security checks have been moved below validity
>>>>> checks. Also, once applied, newly introduced domctls and sysctls will
>>>>> not automatically be guarded by IS_PRIV checks - they will need to add
>>>>> their own permission checking code.
>>>>
>>>> How do we guard against accidentally forgetting to do this?
>>>
>>> The same way you guard against it when adding a new hypercall: when adding
>>> new functionality that needs access checks, also add the access checks.
>> 
>> Except that previously the access check was done centrally at the
>> top of do_domctl(), so newly added sub-functions didn't need to
>> worry.
> 
> One addition I am considering is an extra XSM hook at the start of do_domctl
> and do_sysctl that takes only the command (and domain, for domctl); this
> could be used to restrict access to unknown domctl/sysctls, and would fix
> the issues of adding sub-functions without access checks.

That sounds reasonable, the more that the performance aspect
of these additions doesn't matter for these two hypercalls.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 11 14:12:22 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 2012 14:12:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TBRCB-0005lc-Bn; Tue, 11 Sep 2012 14:12:07 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1TBRCA-0005lL-0f
	for xen-devel@lists.xen.org; Tue, 11 Sep 2012 14:12:06 +0000
Received: from [85.158.143.99:16462] by server-2.bemta-4.messagelabs.com id
	F2/0F-21239-5B64F405; Tue, 11 Sep 2012 14:12:05 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1347372608!22228299!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQwNzc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8655 invoked from network); 11 Sep 2012 14:10:08 -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;
	11 Sep 2012 14:10:08 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 11 Sep 2012 15:10:07 +0100
Message-Id: <504F625D020000780009AA85@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 11 Sep 2012 15:10:05 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: <fantonifabio@tiscali.it>
References: <504F3355.2070201@tiscali.it>
	<504F5182020000780009A9CC@nat28.tlf.novell.com>
	<504F39F0.10701@tiscali.it>
In-Reply-To: <504F39F0.10701@tiscali.it>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Start xen on UEFI system with grub
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.09.12 at 15:17, Fabio Fantoni <fantonifabio@tiscali.it> wrote:
> xen.efi not compile when we build xen on Wheezy and probably is not 
> possible boot with lvm volume, fallback options ecc...

Just get a suitable tool chain installed then.

> UEFI with grub2 seem the best option but with xen hypervisor seem not 
> load efi variable.

Sure, because only xen.efi has the code to deal with such.

(Btw., I assume you aren't aware that any boot manager
whatsoever, other than the one coming with EFI, is sort of
bogus under EFI?)

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 11 14:12:22 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 2012 14:12:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TBRCB-0005lc-Bn; Tue, 11 Sep 2012 14:12:07 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1TBRCA-0005lL-0f
	for xen-devel@lists.xen.org; Tue, 11 Sep 2012 14:12:06 +0000
Received: from [85.158.143.99:16462] by server-2.bemta-4.messagelabs.com id
	F2/0F-21239-5B64F405; Tue, 11 Sep 2012 14:12:05 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1347372608!22228299!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQwNzc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8655 invoked from network); 11 Sep 2012 14:10:08 -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;
	11 Sep 2012 14:10:08 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 11 Sep 2012 15:10:07 +0100
Message-Id: <504F625D020000780009AA85@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 11 Sep 2012 15:10:05 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: <fantonifabio@tiscali.it>
References: <504F3355.2070201@tiscali.it>
	<504F5182020000780009A9CC@nat28.tlf.novell.com>
	<504F39F0.10701@tiscali.it>
In-Reply-To: <504F39F0.10701@tiscali.it>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Start xen on UEFI system with grub
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.09.12 at 15:17, Fabio Fantoni <fantonifabio@tiscali.it> wrote:
> xen.efi not compile when we build xen on Wheezy and probably is not 
> possible boot with lvm volume, fallback options ecc...

Just get a suitable tool chain installed then.

> UEFI with grub2 seem the best option but with xen hypervisor seem not 
> load efi variable.

Sure, because only xen.efi has the code to deal with such.

(Btw., I assume you aren't aware that any boot manager
whatsoever, other than the one coming with EFI, is sort of
bogus under EFI?)

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 11 14:12:58 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 2012 14:12:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TBRCc-0005qc-QE; Tue, 11 Sep 2012 14:12:34 +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 1TBRCb-0005qN-PI
	for xen-devel@lists.xen.org; Tue, 11 Sep 2012 14:12:33 +0000
Received: from [85.158.143.99:19336] by server-1.bemta-4.messagelabs.com id
	E8/E2-12504-1D64F405; Tue, 11 Sep 2012 14:12:33 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-4.tower-216.messagelabs.com!1347372636!24469523!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA0OTYyMDY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22935 invoked from network); 11 Sep 2012 14:10:37 -0000
Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25)
	by server-4.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 11 Sep 2012 14:10:37 -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 A42602879;
	Tue, 11 Sep 2012 17:10:35 +0300 (EEST)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id 740B52005D; Tue, 11 Sep 2012 17:10:35 +0300 (EEST)
Date: Tue, 11 Sep 2012 17:10:35 +0300
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: ?????????????????? ??????????????? <agasheac@gmail.com>
Message-ID: <20120911141035.GR8912@reaktio.net>
References: <CAMQ5s704d8-UscdPtpJ8GPMs_YzTjiOupdi9mWfpfDrRnYV=vQ@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAMQ5s704d8-UscdPtpJ8GPMs_YzTjiOupdi9mWfpfDrRnYV=vQ@mail.gmail.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] xen not able to use total physical memory present
 in the system (192GB)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Sep 11, 2012 at 07:07:00PM +0530, ?????????????????? ???????????????  wrote:
>    Hi
> 

Hello,

>    I am using xen-4.1.2 with fedora-16 (kernel version 3.1.0.7) as dom0 on
>    system having 192GB of RAM.
> 
>    When i booted system xm info shows (total _memory parameter as 192GB and
>    free_memory as 25MB) full memory but /proc/meminfo reports 132GB and xm
>    list also reports 192GB for dom0
> 

"xm list" reports 192 GB for dom0. So dom0 does have 192 GB allocated from Xen,
but the issue probably is that the Linux dom0 kernel isn't able to use all of it.

>    When I ran first VM with 32GB RAM, xm info started reporting memory for
>    dom0 around 132GB and 32GB for VM and cat /proc/meminfo on dom0 reported
>    around 100GB. I am able to boot 4 VMs with this setup but 5th VM fails to
>    boot with not enough memory.
> 
>    ultimately not able to use full system memory ? 60GB went missing from
>    memory.
> 

Why do you want to have all the memory in dom0 ? 

You should limit/dedicate dom0 to, say, 2 GB of memory, and leave the rest of the memory
free in the Xen hypervisor so it can be used for other VMs. 

See: http://wiki.xen.org/wiki/XenBestPractices

-- Pasi


>    [1]http://old-list-archives.xen.org/archives/html/xen-devel/2009-07/msg00521.html
> 
>    On this thread,
> 
>    Jan mentined
> 
>  "the hypervisor has been validated to work fine with 1Tb for much longer, it was
>  really the Dom0 kernel that had issues when not passing a dom0_mem=
>  option".
> 
>  I am not using this option "dom0_mem". Is anybody faced any issue like this ?
> 
>  Thanks,
>  Aniket
> 
> References
> 
>    Visible links
>    1. http://old-list-archives.xen.org/archives/html/xen-devel/2009-07/msg00521.html

> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 11 14:12:58 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 2012 14:12:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TBRCc-0005qc-QE; Tue, 11 Sep 2012 14:12:34 +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 1TBRCb-0005qN-PI
	for xen-devel@lists.xen.org; Tue, 11 Sep 2012 14:12:33 +0000
Received: from [85.158.143.99:19336] by server-1.bemta-4.messagelabs.com id
	E8/E2-12504-1D64F405; Tue, 11 Sep 2012 14:12:33 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-4.tower-216.messagelabs.com!1347372636!24469523!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA0OTYyMDY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22935 invoked from network); 11 Sep 2012 14:10:37 -0000
Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25)
	by server-4.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 11 Sep 2012 14:10:37 -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 A42602879;
	Tue, 11 Sep 2012 17:10:35 +0300 (EEST)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id 740B52005D; Tue, 11 Sep 2012 17:10:35 +0300 (EEST)
Date: Tue, 11 Sep 2012 17:10:35 +0300
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: ?????????????????? ??????????????? <agasheac@gmail.com>
Message-ID: <20120911141035.GR8912@reaktio.net>
References: <CAMQ5s704d8-UscdPtpJ8GPMs_YzTjiOupdi9mWfpfDrRnYV=vQ@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAMQ5s704d8-UscdPtpJ8GPMs_YzTjiOupdi9mWfpfDrRnYV=vQ@mail.gmail.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] xen not able to use total physical memory present
 in the system (192GB)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Sep 11, 2012 at 07:07:00PM +0530, ?????????????????? ???????????????  wrote:
>    Hi
> 

Hello,

>    I am using xen-4.1.2 with fedora-16 (kernel version 3.1.0.7) as dom0 on
>    system having 192GB of RAM.
> 
>    When i booted system xm info shows (total _memory parameter as 192GB and
>    free_memory as 25MB) full memory but /proc/meminfo reports 132GB and xm
>    list also reports 192GB for dom0
> 

"xm list" reports 192 GB for dom0. So dom0 does have 192 GB allocated from Xen,
but the issue probably is that the Linux dom0 kernel isn't able to use all of it.

>    When I ran first VM with 32GB RAM, xm info started reporting memory for
>    dom0 around 132GB and 32GB for VM and cat /proc/meminfo on dom0 reported
>    around 100GB. I am able to boot 4 VMs with this setup but 5th VM fails to
>    boot with not enough memory.
> 
>    ultimately not able to use full system memory ? 60GB went missing from
>    memory.
> 

Why do you want to have all the memory in dom0 ? 

You should limit/dedicate dom0 to, say, 2 GB of memory, and leave the rest of the memory
free in the Xen hypervisor so it can be used for other VMs. 

See: http://wiki.xen.org/wiki/XenBestPractices

-- Pasi


>    [1]http://old-list-archives.xen.org/archives/html/xen-devel/2009-07/msg00521.html
> 
>    On this thread,
> 
>    Jan mentined
> 
>  "the hypervisor has been validated to work fine with 1Tb for much longer, it was
>  really the Dom0 kernel that had issues when not passing a dom0_mem=
>  option".
> 
>  I am not using this option "dom0_mem". Is anybody faced any issue like this ?
> 
>  Thanks,
>  Aniket
> 
> References
> 
>    Visible links
>    1. http://old-list-archives.xen.org/archives/html/xen-devel/2009-07/msg00521.html

> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 11 14:15:36 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 2012 14:15:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TBRFM-0006D3-IK; Tue, 11 Sep 2012 14:15: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 1TBRFK-0006CR-NV
	for xen-devel@lists.xen.org; Tue, 11 Sep 2012 14:15:22 +0000
Received: from [85.158.143.99:43306] by server-3.bemta-4.messagelabs.com id
	86/E9-08232-7774F405; Tue, 11 Sep 2012 14:15:19 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1347372917!23355769!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQwNzc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20141 invoked from network); 11 Sep 2012 14:15:18 -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;
	11 Sep 2012 14:15:18 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 11 Sep 2012 15:15:17 +0100
Message-Id: <504F6391020000780009AAB1@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 11 Sep 2012 15:15:13 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Daniel De Graaf" <dgdegra@tycho.nsa.gov>
References: <1347306553-20980-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1347306553-20980-13-git-send-email-dgdegra@tycho.nsa.gov>
	<504F0603020000780009A6CC@nat28.tlf.novell.com>
	<504F3C0E.8020901@tycho.nsa.gov>
In-Reply-To: <504F3C0E.8020901@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 12/20] xen: avoid calling
 rcu_lock_*target_domain when an XSM hook 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 11.09.12 at 15:26, Daniel De Graaf <dgdegra@tycho.nsa.gov> wrote:
> On 09/11/2012 03:36 AM, Jan Beulich wrote:
>>>>> On 10.09.12 at 21:49, Daniel De Graaf <dgdegra@tycho.nsa.gov> wrote:
>>> --- a/xen/common/grant_table.c
>>> +++ b/xen/common/grant_table.c
>>> @@ -195,30 +195,6 @@ double_gt_unlock(struct grant_table *lgt, struct 
>>> grant_table *rgt)
>>>          spin_unlock(&rgt->lock);
>>>  }
>>>  
>>> -static struct domain *gt_lock_target_domain_by_id(domid_t dom)
>>> -{
>>> -    struct domain *d;
>>> -    int rc = GNTST_general_error;
>>> -
>>> -    switch ( rcu_lock_target_domain_by_id(dom, &d) )
>>> -    {
>>> -    case 0:
>>> -        return d;
>>> -
>>> -    case -ESRCH:
>>> -        gdprintk(XENLOG_INFO, "Bad domid %d.\n", dom);
>>> -        rc = GNTST_bad_domain;
>>> -        break;
>>> -
>>> -    case -EPERM:
>>> -        rc = GNTST_permission_denied;
>>> -        break;
>>> -    }
>>> -
>>> -    ASSERT(rc < 0 && -rc <= MAX_ERRNO);
>>> -    return ERR_PTR(rc);
>>> -}
>>> -
>> 
>> Removing that function again is fine as long as you retain the
>> distinguished error codes, which ...
>> 
>>>  static inline int
>>>  __get_maptrack_handle(
>>>      struct grant_table *t)
>>> @@ -1304,11 +1280,12 @@ gnttab_setup_table(
>>>          goto out1;
>>>      }
>>>  
>>> -    d = gt_lock_target_domain_by_id(op.dom);
>>> -    if ( IS_ERR(d) )
>>> +    d = rcu_lock_domain_by_any_id(op.dom);
>>> +    if ( d == NULL )
>>>      {
>>> -        op.status = PTR_ERR(d);
>>> -        goto out1;
>>> +        gdprintk(XENLOG_INFO, "Bad domid %d.\n", op.dom);
>>> +        op.status = GNTST_bad_domain;
>> 
>> ... you don't.
> 
> Actually, I do. The only distinguishing error code here is
> GNTST_permission_denied, which is now only triggered by the XSM
> hook.

Ah, okay, that wasn't visible from the patch context (and the
sum of the patches was too large to track all the details
mentally). Sorry for the noise then.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 11 14:15:36 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 2012 14:15:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TBRFM-0006D3-IK; Tue, 11 Sep 2012 14:15: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 1TBRFK-0006CR-NV
	for xen-devel@lists.xen.org; Tue, 11 Sep 2012 14:15:22 +0000
Received: from [85.158.143.99:43306] by server-3.bemta-4.messagelabs.com id
	86/E9-08232-7774F405; Tue, 11 Sep 2012 14:15:19 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1347372917!23355769!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQwNzc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20141 invoked from network); 11 Sep 2012 14:15:18 -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;
	11 Sep 2012 14:15:18 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 11 Sep 2012 15:15:17 +0100
Message-Id: <504F6391020000780009AAB1@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 11 Sep 2012 15:15:13 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Daniel De Graaf" <dgdegra@tycho.nsa.gov>
References: <1347306553-20980-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1347306553-20980-13-git-send-email-dgdegra@tycho.nsa.gov>
	<504F0603020000780009A6CC@nat28.tlf.novell.com>
	<504F3C0E.8020901@tycho.nsa.gov>
In-Reply-To: <504F3C0E.8020901@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 12/20] xen: avoid calling
 rcu_lock_*target_domain when an XSM hook 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 11.09.12 at 15:26, Daniel De Graaf <dgdegra@tycho.nsa.gov> wrote:
> On 09/11/2012 03:36 AM, Jan Beulich wrote:
>>>>> On 10.09.12 at 21:49, Daniel De Graaf <dgdegra@tycho.nsa.gov> wrote:
>>> --- a/xen/common/grant_table.c
>>> +++ b/xen/common/grant_table.c
>>> @@ -195,30 +195,6 @@ double_gt_unlock(struct grant_table *lgt, struct 
>>> grant_table *rgt)
>>>          spin_unlock(&rgt->lock);
>>>  }
>>>  
>>> -static struct domain *gt_lock_target_domain_by_id(domid_t dom)
>>> -{
>>> -    struct domain *d;
>>> -    int rc = GNTST_general_error;
>>> -
>>> -    switch ( rcu_lock_target_domain_by_id(dom, &d) )
>>> -    {
>>> -    case 0:
>>> -        return d;
>>> -
>>> -    case -ESRCH:
>>> -        gdprintk(XENLOG_INFO, "Bad domid %d.\n", dom);
>>> -        rc = GNTST_bad_domain;
>>> -        break;
>>> -
>>> -    case -EPERM:
>>> -        rc = GNTST_permission_denied;
>>> -        break;
>>> -    }
>>> -
>>> -    ASSERT(rc < 0 && -rc <= MAX_ERRNO);
>>> -    return ERR_PTR(rc);
>>> -}
>>> -
>> 
>> Removing that function again is fine as long as you retain the
>> distinguished error codes, which ...
>> 
>>>  static inline int
>>>  __get_maptrack_handle(
>>>      struct grant_table *t)
>>> @@ -1304,11 +1280,12 @@ gnttab_setup_table(
>>>          goto out1;
>>>      }
>>>  
>>> -    d = gt_lock_target_domain_by_id(op.dom);
>>> -    if ( IS_ERR(d) )
>>> +    d = rcu_lock_domain_by_any_id(op.dom);
>>> +    if ( d == NULL )
>>>      {
>>> -        op.status = PTR_ERR(d);
>>> -        goto out1;
>>> +        gdprintk(XENLOG_INFO, "Bad domid %d.\n", op.dom);
>>> +        op.status = GNTST_bad_domain;
>> 
>> ... you don't.
> 
> Actually, I do. The only distinguishing error code here is
> GNTST_permission_denied, which is now only triggered by the XSM
> hook.

Ah, okay, that wasn't visible from the patch context (and the
sum of the patches was too large to track all the details
mentally). Sorry for the noise then.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 11 14:16:42 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 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 1TBRGU-0006MB-1D; Tue, 11 Sep 2012 14:16:34 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1TBRGS-0006Lq-4P
	for xen-devel@lists.xen.org; Tue, 11 Sep 2012 14:16:32 +0000
Received: from [85.158.143.99:53507] by server-1.bemta-4.messagelabs.com id
	12/EB-12504-FB74F405; Tue, 11 Sep 2012 14:16:31 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1347372987!28850241!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQwNzc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 879 invoked from network); 11 Sep 2012 14:16:27 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-13.tower-216.messagelabs.com with SMTP;
	11 Sep 2012 14:16:27 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 11 Sep 2012 15:16:26 +0100
Message-Id: <504F63D8020000780009AAB4@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 11 Sep 2012 15:16:24 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Daniel De Graaf" <dgdegra@tycho.nsa.gov>
References: <1347306553-20980-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1347306553-20980-18-git-send-email-dgdegra@tycho.nsa.gov>
	<504F0AA9020000780009A704@nat28.tlf.novell.com>
	<504F3F5B.6070200@tycho.nsa.gov>
In-Reply-To: <504F3F5B.6070200@tycho.nsa.gov>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Tim Deegan <tim@xen.org>, Keir Fraser <keir@xen.org>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 17/20] arch/x86: use XSM hooks for
 get_pg_owner access checks
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 11.09.12 at 15:40, Daniel De Graaf <dgdegra@tycho.nsa.gov> wrote:
> On 09/11/2012 03:55 AM, Jan Beulich wrote:
>>>>> On 10.09.12 at 21:49, Daniel De Graaf <dgdegra@tycho.nsa.gov> wrote:
>>> --- a/xen/arch/x86/mm.c
>>> +++ b/xen/arch/x86/mm.c
>>> @@ -2882,11 +2882,6 @@ static struct domain *get_pg_owner(domid_t domid)
>>>          pg_owner = rcu_lock_domain(dom_io);
>>>          break;
>>>      case DOMID_XEN:
>>> -        if ( !IS_PRIV(curr) )
>>> -        {
>>> -            MEM_LOG("Cannot set foreign dom");
>>> -            break;
>>> -        }
>>>          pg_owner = rcu_lock_domain(dom_xen);
>>>          break;
>>>      default:
>>> @@ -2895,12 +2890,6 @@ static struct domain *get_pg_owner(domid_t domid)
>>>              MEM_LOG("Unknown domain '%u'", domid);
>>>              break;
>>>          }
>>> -        if ( !IS_PRIV_FOR(curr, pg_owner) )
>>> -        {
>>> -            MEM_LOG("Cannot set foreign dom");
>>> -            rcu_unlock_domain(pg_owner);
>>> -            pg_owner = NULL;
>>> -        }
>>>          break;
>>>      }
>>>  
>>> @@ -3008,6 +2997,13 @@ long do_mmuext_op(
>>>          goto out;
>>>      }
>>>  
>>> +    rc = xsm_mmuext_op(d, pg_owner);
>>> +    if ( rc )
>>> +    {
>>> +        rcu_unlock_domain(pg_owner);
>>> +        goto out;
>>> +    }
>>> +
>> 
>> While this part is fine, ...
>> 
>>>      for ( i = 0; i < count; i++ )
>>>      {
>>>          if ( hypercall_preempt_check() )
>>> @@ -3483,11 +3479,6 @@ long do_mmu_update(
>>>              rc = -EINVAL;
>>>              goto out;
>>>          }
>>> -        if ( !IS_PRIV_FOR(d, pt_owner) )
>>> -        {
>>> -            rc = -ESRCH;
>>> -            goto out;
>>> -        }
>> 
>> ... this one isn't (at least in conjunction with them all becoming
>> indirect calls unconditionally) - you replace a single validation per
>> set of requests with one validation per request.
> 
> Is it still a problem if the check is inlined? If so, I could add an
> additional XSM hook where the old IS_PRIV check was done, and make the
> check inside the loop an inlined noop in the XSM-disabled case.

It's not a problem for the inlined case I would say, but I do
think that performance here matters even if XSM is enabled.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 11 14:16:42 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 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 1TBRGU-0006MB-1D; Tue, 11 Sep 2012 14:16:34 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1TBRGS-0006Lq-4P
	for xen-devel@lists.xen.org; Tue, 11 Sep 2012 14:16:32 +0000
Received: from [85.158.143.99:53507] by server-1.bemta-4.messagelabs.com id
	12/EB-12504-FB74F405; Tue, 11 Sep 2012 14:16:31 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1347372987!28850241!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQwNzc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 879 invoked from network); 11 Sep 2012 14:16:27 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-13.tower-216.messagelabs.com with SMTP;
	11 Sep 2012 14:16:27 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 11 Sep 2012 15:16:26 +0100
Message-Id: <504F63D8020000780009AAB4@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 11 Sep 2012 15:16:24 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Daniel De Graaf" <dgdegra@tycho.nsa.gov>
References: <1347306553-20980-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1347306553-20980-18-git-send-email-dgdegra@tycho.nsa.gov>
	<504F0AA9020000780009A704@nat28.tlf.novell.com>
	<504F3F5B.6070200@tycho.nsa.gov>
In-Reply-To: <504F3F5B.6070200@tycho.nsa.gov>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Tim Deegan <tim@xen.org>, Keir Fraser <keir@xen.org>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 17/20] arch/x86: use XSM hooks for
 get_pg_owner access checks
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 11.09.12 at 15:40, Daniel De Graaf <dgdegra@tycho.nsa.gov> wrote:
> On 09/11/2012 03:55 AM, Jan Beulich wrote:
>>>>> On 10.09.12 at 21:49, Daniel De Graaf <dgdegra@tycho.nsa.gov> wrote:
>>> --- a/xen/arch/x86/mm.c
>>> +++ b/xen/arch/x86/mm.c
>>> @@ -2882,11 +2882,6 @@ static struct domain *get_pg_owner(domid_t domid)
>>>          pg_owner = rcu_lock_domain(dom_io);
>>>          break;
>>>      case DOMID_XEN:
>>> -        if ( !IS_PRIV(curr) )
>>> -        {
>>> -            MEM_LOG("Cannot set foreign dom");
>>> -            break;
>>> -        }
>>>          pg_owner = rcu_lock_domain(dom_xen);
>>>          break;
>>>      default:
>>> @@ -2895,12 +2890,6 @@ static struct domain *get_pg_owner(domid_t domid)
>>>              MEM_LOG("Unknown domain '%u'", domid);
>>>              break;
>>>          }
>>> -        if ( !IS_PRIV_FOR(curr, pg_owner) )
>>> -        {
>>> -            MEM_LOG("Cannot set foreign dom");
>>> -            rcu_unlock_domain(pg_owner);
>>> -            pg_owner = NULL;
>>> -        }
>>>          break;
>>>      }
>>>  
>>> @@ -3008,6 +2997,13 @@ long do_mmuext_op(
>>>          goto out;
>>>      }
>>>  
>>> +    rc = xsm_mmuext_op(d, pg_owner);
>>> +    if ( rc )
>>> +    {
>>> +        rcu_unlock_domain(pg_owner);
>>> +        goto out;
>>> +    }
>>> +
>> 
>> While this part is fine, ...
>> 
>>>      for ( i = 0; i < count; i++ )
>>>      {
>>>          if ( hypercall_preempt_check() )
>>> @@ -3483,11 +3479,6 @@ long do_mmu_update(
>>>              rc = -EINVAL;
>>>              goto out;
>>>          }
>>> -        if ( !IS_PRIV_FOR(d, pt_owner) )
>>> -        {
>>> -            rc = -ESRCH;
>>> -            goto out;
>>> -        }
>> 
>> ... this one isn't (at least in conjunction with them all becoming
>> indirect calls unconditionally) - you replace a single validation per
>> set of requests with one validation per request.
> 
> Is it still a problem if the check is inlined? If so, I could add an
> additional XSM hook where the old IS_PRIV check was done, and make the
> check inside the loop an inlined noop in the XSM-disabled case.

It's not a problem for the inlined case I would say, but I do
think that performance here matters even if XSM is enabled.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 11 14:23:56 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 2012 14:23:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TBRNI-0006aq-Tw; Tue, 11 Sep 2012 14:23:36 +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 1TBRNH-0006al-Nl
	for xen-devel@lists.xen.org; Tue, 11 Sep 2012 14:23:36 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1347373407!10581685!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDg1NjI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20249 invoked from network); 11 Sep 2012 14:23:28 -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;
	11 Sep 2012 14:23:28 -0000
X-IronPort-AV: E=Sophos;i="4.80,405,1344211200"; d="scan'208";a="14473335"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Sep 2012 14:23: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.279.1; Tue, 11 Sep 2012 15:23: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
	1TBRN9-0007ae-GD; Tue, 11 Sep 2012 14:23:27 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1TBRN9-0006Xd-CF;
	Tue, 11 Sep 2012 15:23:27 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20559.18783.257111.373451@mariner.uk.xensource.com>
Date: Tue, 11 Sep 2012 15:23:27 +0100
To: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Cc: Ian Campbell <Ian.Campbell@citrix.com>, Jan Beulich <JBeulich@suse.com>
Subject: [Xen-devel] [PATCH] libxl: Tolerate xl config files missing
	trailing newline
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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:
> Also I wrote:
> > However, xl fails on config files which are missing the final
> > newline.  This should be fixed for 4.2.
> 
> My patch for this didn't make it into 4.2 RC4.

Should this go into 4.2.0 or be held for 4.2.1 (or is it not 4.2.x
material at all) ?

Ian.

From: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [PATCH] libxl: Tolerate xl config files missing trailing newline

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>

---
 tools/libxl/libxlu_cfg_y.c |  154 +++++++++++++++++++++++---------------------
 tools/libxl/libxlu_cfg_y.y |   12 ++-
 2 files changed, 88 insertions(+), 78 deletions(-)

diff --git a/tools/libxl/libxlu_cfg_y.c b/tools/libxl/libxlu_cfg_y.c
index 5214386..218933e 100644
--- a/tools/libxl/libxlu_cfg_y.c
+++ b/tools/libxl/libxlu_cfg_y.c
@@ -373,18 +373,18 @@ union yyalloc
 #endif
 
 /* YYFINAL -- State number of the termination state.  */
-#define YYFINAL  2
+#define YYFINAL  3
 /* YYLAST -- Last index in YYTABLE.  */
-#define YYLAST   23
+#define YYLAST   24
 
 /* YYNTOKENS -- Number of terminals.  */
 #define YYNTOKENS  12
 /* YYNNTS -- Number of nonterminals.  */
-#define YYNNTS  9
+#define YYNNTS  11
 /* YYNRULES -- Number of rules.  */
-#define YYNRULES  19
+#define YYNRULES  22
 /* YYNRULES -- Number of states.  */
-#define YYNSTATES  28
+#define YYNSTATES  30
 
 /* YYTRANSLATE(YYLEX) -- Bison symbol number corresponding to YYLEX.  */
 #define YYUNDEFTOK  2
@@ -430,26 +430,28 @@ static const yytype_uint8 yytranslate[] =
    YYRHS.  */
 static const yytype_uint8 yyprhs[] =
 {
-       0,     0,     3,     4,     7,    12,    14,    17,    19,    21,
-      23,    28,    30,    32,    33,    35,    39,    42,    48,    49
+       0,     0,     3,     5,     8,     9,    12,    15,    17,    20,
+      24,    26,    28,    30,    35,    37,    39,    40,    42,    46,
+      49,    55,    56
 };
 
 /* YYRHS -- A `-1'-separated list of the rules' RHS.  */
 static const yytype_int8 yyrhs[] =
 {
-      13,     0,    -1,    -1,    13,    14,    -1,     3,     7,    16,
-      15,    -1,    15,    -1,     1,     6,    -1,     6,    -1,     8,
-      -1,    17,    -1,     9,    20,    18,    10,    -1,     4,    -1,
-       5,    -1,    -1,    19,    -1,    19,    11,    20,    -1,    17,
-      20,    -1,    19,    11,    20,    17,    20,    -1,    -1,    20,
-       6,    -1
+      13,     0,    -1,    14,    -1,    14,    16,    -1,    -1,    14,
+      15,    -1,    16,    17,    -1,    17,    -1,     1,     6,    -1,
+       3,     7,    18,    -1,     6,    -1,     8,    -1,    19,    -1,
+       9,    22,    20,    10,    -1,     4,    -1,     5,    -1,    -1,
+      21,    -1,    21,    11,    22,    -1,    19,    22,    -1,    21,
+      11,    22,    19,    22,    -1,    -1,    22,     6,    -1
 };
 
 /* YYRLINE[YYN] -- source line where rule number YYN was defined.  */
 static const yytype_uint8 yyrline[] =
 {
-       0,    47,    47,    48,    50,    52,    53,    55,    56,    58,
-      59,    61,    62,    64,    65,    66,    68,    69,    71,    73
+       0,    47,    47,    48,    50,    51,    53,    54,    55,    57,
+      59,    60,    62,    63,    65,    66,    68,    69,    70,    72,
+      73,    75,    77
 };
 #endif
 
@@ -459,8 +461,8 @@ static const yytype_uint8 yyrline[] =
 static const char *const yytname[] =
 {
   "$end", "error", "$undefined", "IDENT", "STRING", "NUMBER", "NEWLINE",
-  "'='", "';'", "'['", "']'", "','", "$accept", "file", "assignment",
-  "endstmt", "value", "atom", "valuelist", "values", "nlok", 0
+  "'='", "';'", "'['", "']'", "','", "$accept", "file", "stmts", "stmt",
+  "assignment", "endstmt", "value", "atom", "valuelist", "values", "nlok", 0
 };
 #endif
 
@@ -477,15 +479,17 @@ static const yytype_uint16 yytoknum[] =
 /* YYR1[YYN] -- Symbol number of symbol that rule YYN derives.  */
 static const yytype_uint8 yyr1[] =
 {
-       0,    12,    13,    13,    14,    14,    14,    15,    15,    16,
-      16,    17,    17,    18,    18,    18,    19,    19,    20,    20
+       0,    12,    13,    13,    14,    14,    15,    15,    15,    16,
+      17,    17,    18,    18,    19,    19,    20,    20,    20,    21,
+      21,    22,    22
 };
 
 /* YYR2[YYN] -- Number of symbols composing right hand side of rule YYN.  */
 static const yytype_uint8 yyr2[] =
 {
-       0,     2,     0,     2,     4,     1,     2,     1,     1,     1,
-       4,     1,     1,     0,     1,     3,     2,     5,     0,     2
+       0,     2,     1,     2,     0,     2,     2,     1,     2,     3,
+       1,     1,     1,     4,     1,     1,     0,     1,     3,     2,
+       5,     0,     2
 };
 
 /* YYDEFACT[STATE-NAME] -- Default rule to reduce with in state
@@ -493,59 +497,61 @@ static const yytype_uint8 yyr2[] =
    means the default is an error.  */
 static const yytype_uint8 yydefact[] =
 {
-       2,     0,     1,     0,     0,     7,     8,     3,     5,     6,
-       0,    11,    12,    18,     0,     9,    13,     4,    19,    18,
-       0,    14,    16,    10,    18,    15,    18,    17
+       4,     0,     0,     1,     0,     0,    10,    11,     5,     3,
+       7,     8,     0,     6,    14,    15,    21,     9,    12,    16,
+      22,    21,     0,    17,    19,    13,    21,    18,    21,    20
 };
 
 /* YYDEFGOTO[NTERM-NUM].  */
 static const yytype_int8 yydefgoto[] =
 {
-      -1,     1,     7,     8,    14,    15,    20,    21,    16
+      -1,     1,     2,     8,     9,    10,    17,    18,    22,    23,
+      19
 };
 
 /* YYPACT[STATE-NUM] -- Index in YYTABLE of the portion describing
    STATE-NUM.  */
-#define YYPACT_NINF -17
+#define YYPACT_NINF -18
 static const yytype_int8 yypact[] =
 {
-     -17,     2,   -17,    -5,    -3,   -17,   -17,   -17,   -17,   -17,
-      10,   -17,   -17,   -17,    14,   -17,    12,   -17,   -17,   -17,
-      11,    -4,     6,   -17,   -17,    12,   -17,     6
+     -18,     4,     0,   -18,    -1,     6,   -18,   -18,   -18,     3,
+     -18,   -18,    11,   -18,   -18,   -18,   -18,   -18,   -18,    13,
+     -18,   -18,    12,    10,    17,   -18,   -18,    13,   -18,    17
 };
 
 /* YYPGOTO[NTERM-NUM].  */
 static const yytype_int8 yypgoto[] =
 {
-     -17,   -17,   -17,     9,   -17,   -16,   -17,   -17,   -13
+     -18,   -18,   -18,   -18,   -18,    15,   -18,   -17,   -18,   -18,
+     -14
 };
 
 /* YYTABLE[YYPACT[STATE-NUM]].  What to do in state STATE-NUM.  If
    positive, shift that token.  If negative, reduce the rule which
    number is the opposite.  If zero, do what YYDEFACT says.
    If YYTABLE_NINF, syntax error.  */
-#define YYTABLE_NINF -1
-static const yytype_uint8 yytable[] =
+#define YYTABLE_NINF -3
+static const yytype_int8 yytable[] =
 {
-      19,     9,     2,     3,    10,     4,    22,    24,     5,    26,
-       6,    25,    18,    27,    11,    12,    11,    12,    18,    13,
-       5,    23,     6,    17
+      -2,     4,    21,     5,     3,    11,     6,    24,     7,     6,
+      28,     7,    27,    12,    29,    14,    15,    14,    15,    20,
+      16,    26,    25,    20,    13
 };
 
 static const yytype_uint8 yycheck[] =
 {
-      16,     6,     0,     1,     7,     3,    19,    11,     6,    25,
-       8,    24,     6,    26,     4,     5,     4,     5,     6,     9,
-       6,    10,     8,    14
+       0,     1,    19,     3,     0,     6,     6,    21,     8,     6,
+      27,     8,    26,     7,    28,     4,     5,     4,     5,     6,
+       9,    11,    10,     6,     9
 };
 
 /* YYSTOS[STATE-NUM] -- The (internal number of the) accessing
    symbol of state STATE-NUM.  */
 static const yytype_uint8 yystos[] =
 {
-       0,    13,     0,     1,     3,     6,     8,    14,    15,     6,
-       7,     4,     5,     9,    16,    17,    20,    15,     6,    17,
-      18,    19,    20,    10,    11,    20,    17,    20
+       0,    13,    14,     0,     1,     3,     6,     8,    15,    16,
+      17,     6,     7,    17,     4,     5,     9,    18,    19,    22,
+       6,    19,    20,    21,    22,    10,    11,    22,    19,    22
 };
 
 #define yyerrok		(yyerrstatus = 0)
@@ -1077,7 +1083,7 @@ yydestruct (yymsg, yytype, yyvaluep, yylocationp, ctx)
 	{ free((yyvaluep->string)); };
 
 /* Line 1000 of yacc.c  */
-#line 1081 "libxlu_cfg_y.c"
+#line 1087 "libxlu_cfg_y.c"
 	break;
       case 4: /* "STRING" */
 
@@ -1086,7 +1092,7 @@ yydestruct (yymsg, yytype, yyvaluep, yylocationp, ctx)
 	{ free((yyvaluep->string)); };
 
 /* Line 1000 of yacc.c  */
-#line 1090 "libxlu_cfg_y.c"
+#line 1096 "libxlu_cfg_y.c"
 	break;
       case 5: /* "NUMBER" */
 
@@ -1095,43 +1101,43 @@ yydestruct (yymsg, yytype, yyvaluep, yylocationp, ctx)
 	{ free((yyvaluep->string)); };
 
 /* Line 1000 of yacc.c  */
-#line 1099 "libxlu_cfg_y.c"
+#line 1105 "libxlu_cfg_y.c"
 	break;
-      case 16: /* "value" */
+      case 18: /* "value" */
 
 /* Line 1000 of yacc.c  */
 #line 43 "libxlu_cfg_y.y"
 	{ xlu__cfg_set_free((yyvaluep->setting)); };
 
 /* Line 1000 of yacc.c  */
-#line 1108 "libxlu_cfg_y.c"
+#line 1114 "libxlu_cfg_y.c"
 	break;
-      case 17: /* "atom" */
+      case 19: /* "atom" */
 
 /* Line 1000 of yacc.c  */
 #line 40 "libxlu_cfg_y.y"
 	{ free((yyvaluep->string)); };
 
 /* Line 1000 of yacc.c  */
-#line 1117 "libxlu_cfg_y.c"
+#line 1123 "libxlu_cfg_y.c"
 	break;
-      case 18: /* "valuelist" */
+      case 20: /* "valuelist" */
 
 /* Line 1000 of yacc.c  */
 #line 43 "libxlu_cfg_y.y"
 	{ xlu__cfg_set_free((yyvaluep->setting)); };
 
 /* Line 1000 of yacc.c  */
-#line 1126 "libxlu_cfg_y.c"
+#line 1132 "libxlu_cfg_y.c"
 	break;
-      case 19: /* "values" */
+      case 21: /* "values" */
 
 /* Line 1000 of yacc.c  */
 #line 43 "libxlu_cfg_y.y"
 	{ xlu__cfg_set_free((yyvaluep->setting)); };
 
 /* Line 1000 of yacc.c  */
-#line 1135 "libxlu_cfg_y.c"
+#line 1141 "libxlu_cfg_y.c"
 	break;
 
       default:
@@ -1459,80 +1465,80 @@ yyreduce:
   YY_REDUCE_PRINT (yyn);
   switch (yyn)
     {
-        case 4:
+        case 9:
 
 /* Line 1455 of yacc.c  */
-#line 51 "libxlu_cfg_y.y"
-    { xlu__cfg_set_store(ctx,(yyvsp[(1) - (4)].string),(yyvsp[(3) - (4)].setting),(yylsp[(3) - (4)]).first_line); ;}
+#line 57 "libxlu_cfg_y.y"
+    { xlu__cfg_set_store(ctx,(yyvsp[(1) - (3)].string),(yyvsp[(3) - (3)].setting),(yylsp[(3) - (3)]).first_line); ;}
     break;
 
-  case 9:
+  case 12:
 
 /* Line 1455 of yacc.c  */
-#line 58 "libxlu_cfg_y.y"
+#line 62 "libxlu_cfg_y.y"
     { (yyval.setting)= xlu__cfg_set_mk(ctx,1,(yyvsp[(1) - (1)].string)); ;}
     break;
 
-  case 10:
+  case 13:
 
 /* Line 1455 of yacc.c  */
-#line 59 "libxlu_cfg_y.y"
+#line 63 "libxlu_cfg_y.y"
     { (yyval.setting)= (yyvsp[(3) - (4)].setting); ;}
     break;
 
-  case 11:
+  case 14:
 
 /* Line 1455 of yacc.c  */
-#line 61 "libxlu_cfg_y.y"
+#line 65 "libxlu_cfg_y.y"
     { (yyval.string)= (yyvsp[(1) - (1)].string); ;}
     break;
 
-  case 12:
+  case 15:
 
 /* Line 1455 of yacc.c  */
-#line 62 "libxlu_cfg_y.y"
+#line 66 "libxlu_cfg_y.y"
     { (yyval.string)= (yyvsp[(1) - (1)].string); ;}
     break;
 
-  case 13:
+  case 16:
 
 /* Line 1455 of yacc.c  */
-#line 64 "libxlu_cfg_y.y"
+#line 68 "libxlu_cfg_y.y"
     { (yyval.setting)= xlu__cfg_set_mk(ctx,0,0); ;}
     break;
 
-  case 14:
+  case 17:
 
 /* Line 1455 of yacc.c  */
-#line 65 "libxlu_cfg_y.y"
+#line 69 "libxlu_cfg_y.y"
     { (yyval.setting)= (yyvsp[(1) - (1)].setting); ;}
     break;
 
-  case 15:
+  case 18:
 
 /* Line 1455 of yacc.c  */
-#line 66 "libxlu_cfg_y.y"
+#line 70 "libxlu_cfg_y.y"
     { (yyval.setting)= (yyvsp[(1) - (3)].setting); ;}
     break;
 
-  case 16:
+  case 19:
 
 /* Line 1455 of yacc.c  */
-#line 68 "libxlu_cfg_y.y"
+#line 72 "libxlu_cfg_y.y"
     { (yyval.setting)= xlu__cfg_set_mk(ctx,2,(yyvsp[(1) - (2)].string)); ;}
     break;
 
-  case 17:
+  case 20:
 
 /* Line 1455 of yacc.c  */
-#line 69 "libxlu_cfg_y.y"
+#line 73 "libxlu_cfg_y.y"
     { xlu__cfg_set_add(ctx,(yyvsp[(1) - (5)].setting),(yyvsp[(4) - (5)].string)); (yyval.setting)= (yyvsp[(1) - (5)].setting); ;}
     break;
 
 
 
 /* Line 1455 of yacc.c  */
-#line 1536 "libxlu_cfg_y.c"
+#line 1542 "libxlu_cfg_y.c"
       default: break;
     }
   YY_SYMBOL_PRINT ("-> $$ =", yyr1[yyn], &yyval, &yyloc);
diff --git a/tools/libxl/libxlu_cfg_y.y b/tools/libxl/libxlu_cfg_y.y
index 29aedca..aa9f787 100644
--- a/tools/libxl/libxlu_cfg_y.y
+++ b/tools/libxl/libxlu_cfg_y.y
@@ -44,14 +44,18 @@
 
 %%
 
-file: /* empty */
- |     file assignment
+file:  stmts
+ |     stmts assignment
 
-assignment: IDENT '=' value endstmt
-                            { xlu__cfg_set_store(ctx,$1,$3,@3.first_line); }
+stmts:  /* empty */
+ |      stmts stmt
+
+stmt:   assignment endstmt
  |      endstmt
  |      error NEWLINE
 
+assignment: IDENT '=' value { xlu__cfg_set_store(ctx,$1,$3,@3.first_line); }
+
 endstmt: NEWLINE
  |      ';'
 
-- 
tg: (9213e8a..) t/xen/xl.cfg.no-final-newline-ok (depends on: t/xen/xl.cfg.mem-fix)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 11 14:23:56 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 2012 14:23:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TBRNI-0006aq-Tw; Tue, 11 Sep 2012 14:23:36 +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 1TBRNH-0006al-Nl
	for xen-devel@lists.xen.org; Tue, 11 Sep 2012 14:23:36 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1347373407!10581685!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDg1NjI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20249 invoked from network); 11 Sep 2012 14:23:28 -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;
	11 Sep 2012 14:23:28 -0000
X-IronPort-AV: E=Sophos;i="4.80,405,1344211200"; d="scan'208";a="14473335"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Sep 2012 14:23: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.279.1; Tue, 11 Sep 2012 15:23: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
	1TBRN9-0007ae-GD; Tue, 11 Sep 2012 14:23:27 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1TBRN9-0006Xd-CF;
	Tue, 11 Sep 2012 15:23:27 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20559.18783.257111.373451@mariner.uk.xensource.com>
Date: Tue, 11 Sep 2012 15:23:27 +0100
To: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Cc: Ian Campbell <Ian.Campbell@citrix.com>, Jan Beulich <JBeulich@suse.com>
Subject: [Xen-devel] [PATCH] libxl: Tolerate xl config files missing
	trailing newline
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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:
> Also I wrote:
> > However, xl fails on config files which are missing the final
> > newline.  This should be fixed for 4.2.
> 
> My patch for this didn't make it into 4.2 RC4.

Should this go into 4.2.0 or be held for 4.2.1 (or is it not 4.2.x
material at all) ?

Ian.

From: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [PATCH] libxl: Tolerate xl config files missing trailing newline

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>

---
 tools/libxl/libxlu_cfg_y.c |  154 +++++++++++++++++++++++---------------------
 tools/libxl/libxlu_cfg_y.y |   12 ++-
 2 files changed, 88 insertions(+), 78 deletions(-)

diff --git a/tools/libxl/libxlu_cfg_y.c b/tools/libxl/libxlu_cfg_y.c
index 5214386..218933e 100644
--- a/tools/libxl/libxlu_cfg_y.c
+++ b/tools/libxl/libxlu_cfg_y.c
@@ -373,18 +373,18 @@ union yyalloc
 #endif
 
 /* YYFINAL -- State number of the termination state.  */
-#define YYFINAL  2
+#define YYFINAL  3
 /* YYLAST -- Last index in YYTABLE.  */
-#define YYLAST   23
+#define YYLAST   24
 
 /* YYNTOKENS -- Number of terminals.  */
 #define YYNTOKENS  12
 /* YYNNTS -- Number of nonterminals.  */
-#define YYNNTS  9
+#define YYNNTS  11
 /* YYNRULES -- Number of rules.  */
-#define YYNRULES  19
+#define YYNRULES  22
 /* YYNRULES -- Number of states.  */
-#define YYNSTATES  28
+#define YYNSTATES  30
 
 /* YYTRANSLATE(YYLEX) -- Bison symbol number corresponding to YYLEX.  */
 #define YYUNDEFTOK  2
@@ -430,26 +430,28 @@ static const yytype_uint8 yytranslate[] =
    YYRHS.  */
 static const yytype_uint8 yyprhs[] =
 {
-       0,     0,     3,     4,     7,    12,    14,    17,    19,    21,
-      23,    28,    30,    32,    33,    35,    39,    42,    48,    49
+       0,     0,     3,     5,     8,     9,    12,    15,    17,    20,
+      24,    26,    28,    30,    35,    37,    39,    40,    42,    46,
+      49,    55,    56
 };
 
 /* YYRHS -- A `-1'-separated list of the rules' RHS.  */
 static const yytype_int8 yyrhs[] =
 {
-      13,     0,    -1,    -1,    13,    14,    -1,     3,     7,    16,
-      15,    -1,    15,    -1,     1,     6,    -1,     6,    -1,     8,
-      -1,    17,    -1,     9,    20,    18,    10,    -1,     4,    -1,
-       5,    -1,    -1,    19,    -1,    19,    11,    20,    -1,    17,
-      20,    -1,    19,    11,    20,    17,    20,    -1,    -1,    20,
-       6,    -1
+      13,     0,    -1,    14,    -1,    14,    16,    -1,    -1,    14,
+      15,    -1,    16,    17,    -1,    17,    -1,     1,     6,    -1,
+       3,     7,    18,    -1,     6,    -1,     8,    -1,    19,    -1,
+       9,    22,    20,    10,    -1,     4,    -1,     5,    -1,    -1,
+      21,    -1,    21,    11,    22,    -1,    19,    22,    -1,    21,
+      11,    22,    19,    22,    -1,    -1,    22,     6,    -1
 };
 
 /* YYRLINE[YYN] -- source line where rule number YYN was defined.  */
 static const yytype_uint8 yyrline[] =
 {
-       0,    47,    47,    48,    50,    52,    53,    55,    56,    58,
-      59,    61,    62,    64,    65,    66,    68,    69,    71,    73
+       0,    47,    47,    48,    50,    51,    53,    54,    55,    57,
+      59,    60,    62,    63,    65,    66,    68,    69,    70,    72,
+      73,    75,    77
 };
 #endif
 
@@ -459,8 +461,8 @@ static const yytype_uint8 yyrline[] =
 static const char *const yytname[] =
 {
   "$end", "error", "$undefined", "IDENT", "STRING", "NUMBER", "NEWLINE",
-  "'='", "';'", "'['", "']'", "','", "$accept", "file", "assignment",
-  "endstmt", "value", "atom", "valuelist", "values", "nlok", 0
+  "'='", "';'", "'['", "']'", "','", "$accept", "file", "stmts", "stmt",
+  "assignment", "endstmt", "value", "atom", "valuelist", "values", "nlok", 0
 };
 #endif
 
@@ -477,15 +479,17 @@ static const yytype_uint16 yytoknum[] =
 /* YYR1[YYN] -- Symbol number of symbol that rule YYN derives.  */
 static const yytype_uint8 yyr1[] =
 {
-       0,    12,    13,    13,    14,    14,    14,    15,    15,    16,
-      16,    17,    17,    18,    18,    18,    19,    19,    20,    20
+       0,    12,    13,    13,    14,    14,    15,    15,    15,    16,
+      17,    17,    18,    18,    19,    19,    20,    20,    20,    21,
+      21,    22,    22
 };
 
 /* YYR2[YYN] -- Number of symbols composing right hand side of rule YYN.  */
 static const yytype_uint8 yyr2[] =
 {
-       0,     2,     0,     2,     4,     1,     2,     1,     1,     1,
-       4,     1,     1,     0,     1,     3,     2,     5,     0,     2
+       0,     2,     1,     2,     0,     2,     2,     1,     2,     3,
+       1,     1,     1,     4,     1,     1,     0,     1,     3,     2,
+       5,     0,     2
 };
 
 /* YYDEFACT[STATE-NAME] -- Default rule to reduce with in state
@@ -493,59 +497,61 @@ static const yytype_uint8 yyr2[] =
    means the default is an error.  */
 static const yytype_uint8 yydefact[] =
 {
-       2,     0,     1,     0,     0,     7,     8,     3,     5,     6,
-       0,    11,    12,    18,     0,     9,    13,     4,    19,    18,
-       0,    14,    16,    10,    18,    15,    18,    17
+       4,     0,     0,     1,     0,     0,    10,    11,     5,     3,
+       7,     8,     0,     6,    14,    15,    21,     9,    12,    16,
+      22,    21,     0,    17,    19,    13,    21,    18,    21,    20
 };
 
 /* YYDEFGOTO[NTERM-NUM].  */
 static const yytype_int8 yydefgoto[] =
 {
-      -1,     1,     7,     8,    14,    15,    20,    21,    16
+      -1,     1,     2,     8,     9,    10,    17,    18,    22,    23,
+      19
 };
 
 /* YYPACT[STATE-NUM] -- Index in YYTABLE of the portion describing
    STATE-NUM.  */
-#define YYPACT_NINF -17
+#define YYPACT_NINF -18
 static const yytype_int8 yypact[] =
 {
-     -17,     2,   -17,    -5,    -3,   -17,   -17,   -17,   -17,   -17,
-      10,   -17,   -17,   -17,    14,   -17,    12,   -17,   -17,   -17,
-      11,    -4,     6,   -17,   -17,    12,   -17,     6
+     -18,     4,     0,   -18,    -1,     6,   -18,   -18,   -18,     3,
+     -18,   -18,    11,   -18,   -18,   -18,   -18,   -18,   -18,    13,
+     -18,   -18,    12,    10,    17,   -18,   -18,    13,   -18,    17
 };
 
 /* YYPGOTO[NTERM-NUM].  */
 static const yytype_int8 yypgoto[] =
 {
-     -17,   -17,   -17,     9,   -17,   -16,   -17,   -17,   -13
+     -18,   -18,   -18,   -18,   -18,    15,   -18,   -17,   -18,   -18,
+     -14
 };
 
 /* YYTABLE[YYPACT[STATE-NUM]].  What to do in state STATE-NUM.  If
    positive, shift that token.  If negative, reduce the rule which
    number is the opposite.  If zero, do what YYDEFACT says.
    If YYTABLE_NINF, syntax error.  */
-#define YYTABLE_NINF -1
-static const yytype_uint8 yytable[] =
+#define YYTABLE_NINF -3
+static const yytype_int8 yytable[] =
 {
-      19,     9,     2,     3,    10,     4,    22,    24,     5,    26,
-       6,    25,    18,    27,    11,    12,    11,    12,    18,    13,
-       5,    23,     6,    17
+      -2,     4,    21,     5,     3,    11,     6,    24,     7,     6,
+      28,     7,    27,    12,    29,    14,    15,    14,    15,    20,
+      16,    26,    25,    20,    13
 };
 
 static const yytype_uint8 yycheck[] =
 {
-      16,     6,     0,     1,     7,     3,    19,    11,     6,    25,
-       8,    24,     6,    26,     4,     5,     4,     5,     6,     9,
-       6,    10,     8,    14
+       0,     1,    19,     3,     0,     6,     6,    21,     8,     6,
+      27,     8,    26,     7,    28,     4,     5,     4,     5,     6,
+       9,    11,    10,     6,     9
 };
 
 /* YYSTOS[STATE-NUM] -- The (internal number of the) accessing
    symbol of state STATE-NUM.  */
 static const yytype_uint8 yystos[] =
 {
-       0,    13,     0,     1,     3,     6,     8,    14,    15,     6,
-       7,     4,     5,     9,    16,    17,    20,    15,     6,    17,
-      18,    19,    20,    10,    11,    20,    17,    20
+       0,    13,    14,     0,     1,     3,     6,     8,    15,    16,
+      17,     6,     7,    17,     4,     5,     9,    18,    19,    22,
+       6,    19,    20,    21,    22,    10,    11,    22,    19,    22
 };
 
 #define yyerrok		(yyerrstatus = 0)
@@ -1077,7 +1083,7 @@ yydestruct (yymsg, yytype, yyvaluep, yylocationp, ctx)
 	{ free((yyvaluep->string)); };
 
 /* Line 1000 of yacc.c  */
-#line 1081 "libxlu_cfg_y.c"
+#line 1087 "libxlu_cfg_y.c"
 	break;
       case 4: /* "STRING" */
 
@@ -1086,7 +1092,7 @@ yydestruct (yymsg, yytype, yyvaluep, yylocationp, ctx)
 	{ free((yyvaluep->string)); };
 
 /* Line 1000 of yacc.c  */
-#line 1090 "libxlu_cfg_y.c"
+#line 1096 "libxlu_cfg_y.c"
 	break;
       case 5: /* "NUMBER" */
 
@@ -1095,43 +1101,43 @@ yydestruct (yymsg, yytype, yyvaluep, yylocationp, ctx)
 	{ free((yyvaluep->string)); };
 
 /* Line 1000 of yacc.c  */
-#line 1099 "libxlu_cfg_y.c"
+#line 1105 "libxlu_cfg_y.c"
 	break;
-      case 16: /* "value" */
+      case 18: /* "value" */
 
 /* Line 1000 of yacc.c  */
 #line 43 "libxlu_cfg_y.y"
 	{ xlu__cfg_set_free((yyvaluep->setting)); };
 
 /* Line 1000 of yacc.c  */
-#line 1108 "libxlu_cfg_y.c"
+#line 1114 "libxlu_cfg_y.c"
 	break;
-      case 17: /* "atom" */
+      case 19: /* "atom" */
 
 /* Line 1000 of yacc.c  */
 #line 40 "libxlu_cfg_y.y"
 	{ free((yyvaluep->string)); };
 
 /* Line 1000 of yacc.c  */
-#line 1117 "libxlu_cfg_y.c"
+#line 1123 "libxlu_cfg_y.c"
 	break;
-      case 18: /* "valuelist" */
+      case 20: /* "valuelist" */
 
 /* Line 1000 of yacc.c  */
 #line 43 "libxlu_cfg_y.y"
 	{ xlu__cfg_set_free((yyvaluep->setting)); };
 
 /* Line 1000 of yacc.c  */
-#line 1126 "libxlu_cfg_y.c"
+#line 1132 "libxlu_cfg_y.c"
 	break;
-      case 19: /* "values" */
+      case 21: /* "values" */
 
 /* Line 1000 of yacc.c  */
 #line 43 "libxlu_cfg_y.y"
 	{ xlu__cfg_set_free((yyvaluep->setting)); };
 
 /* Line 1000 of yacc.c  */
-#line 1135 "libxlu_cfg_y.c"
+#line 1141 "libxlu_cfg_y.c"
 	break;
 
       default:
@@ -1459,80 +1465,80 @@ yyreduce:
   YY_REDUCE_PRINT (yyn);
   switch (yyn)
     {
-        case 4:
+        case 9:
 
 /* Line 1455 of yacc.c  */
-#line 51 "libxlu_cfg_y.y"
-    { xlu__cfg_set_store(ctx,(yyvsp[(1) - (4)].string),(yyvsp[(3) - (4)].setting),(yylsp[(3) - (4)]).first_line); ;}
+#line 57 "libxlu_cfg_y.y"
+    { xlu__cfg_set_store(ctx,(yyvsp[(1) - (3)].string),(yyvsp[(3) - (3)].setting),(yylsp[(3) - (3)]).first_line); ;}
     break;
 
-  case 9:
+  case 12:
 
 /* Line 1455 of yacc.c  */
-#line 58 "libxlu_cfg_y.y"
+#line 62 "libxlu_cfg_y.y"
     { (yyval.setting)= xlu__cfg_set_mk(ctx,1,(yyvsp[(1) - (1)].string)); ;}
     break;
 
-  case 10:
+  case 13:
 
 /* Line 1455 of yacc.c  */
-#line 59 "libxlu_cfg_y.y"
+#line 63 "libxlu_cfg_y.y"
     { (yyval.setting)= (yyvsp[(3) - (4)].setting); ;}
     break;
 
-  case 11:
+  case 14:
 
 /* Line 1455 of yacc.c  */
-#line 61 "libxlu_cfg_y.y"
+#line 65 "libxlu_cfg_y.y"
     { (yyval.string)= (yyvsp[(1) - (1)].string); ;}
     break;
 
-  case 12:
+  case 15:
 
 /* Line 1455 of yacc.c  */
-#line 62 "libxlu_cfg_y.y"
+#line 66 "libxlu_cfg_y.y"
     { (yyval.string)= (yyvsp[(1) - (1)].string); ;}
     break;
 
-  case 13:
+  case 16:
 
 /* Line 1455 of yacc.c  */
-#line 64 "libxlu_cfg_y.y"
+#line 68 "libxlu_cfg_y.y"
     { (yyval.setting)= xlu__cfg_set_mk(ctx,0,0); ;}
     break;
 
-  case 14:
+  case 17:
 
 /* Line 1455 of yacc.c  */
-#line 65 "libxlu_cfg_y.y"
+#line 69 "libxlu_cfg_y.y"
     { (yyval.setting)= (yyvsp[(1) - (1)].setting); ;}
     break;
 
-  case 15:
+  case 18:
 
 /* Line 1455 of yacc.c  */
-#line 66 "libxlu_cfg_y.y"
+#line 70 "libxlu_cfg_y.y"
     { (yyval.setting)= (yyvsp[(1) - (3)].setting); ;}
     break;
 
-  case 16:
+  case 19:
 
 /* Line 1455 of yacc.c  */
-#line 68 "libxlu_cfg_y.y"
+#line 72 "libxlu_cfg_y.y"
     { (yyval.setting)= xlu__cfg_set_mk(ctx,2,(yyvsp[(1) - (2)].string)); ;}
     break;
 
-  case 17:
+  case 20:
 
 /* Line 1455 of yacc.c  */
-#line 69 "libxlu_cfg_y.y"
+#line 73 "libxlu_cfg_y.y"
     { xlu__cfg_set_add(ctx,(yyvsp[(1) - (5)].setting),(yyvsp[(4) - (5)].string)); (yyval.setting)= (yyvsp[(1) - (5)].setting); ;}
     break;
 
 
 
 /* Line 1455 of yacc.c  */
-#line 1536 "libxlu_cfg_y.c"
+#line 1542 "libxlu_cfg_y.c"
       default: break;
     }
   YY_SYMBOL_PRINT ("-> $$ =", yyr1[yyn], &yyval, &yyloc);
diff --git a/tools/libxl/libxlu_cfg_y.y b/tools/libxl/libxlu_cfg_y.y
index 29aedca..aa9f787 100644
--- a/tools/libxl/libxlu_cfg_y.y
+++ b/tools/libxl/libxlu_cfg_y.y
@@ -44,14 +44,18 @@
 
 %%
 
-file: /* empty */
- |     file assignment
+file:  stmts
+ |     stmts assignment
 
-assignment: IDENT '=' value endstmt
-                            { xlu__cfg_set_store(ctx,$1,$3,@3.first_line); }
+stmts:  /* empty */
+ |      stmts stmt
+
+stmt:   assignment endstmt
  |      endstmt
  |      error NEWLINE
 
+assignment: IDENT '=' value { xlu__cfg_set_store(ctx,$1,$3,@3.first_line); }
+
 endstmt: NEWLINE
  |      ';'
 
-- 
tg: (9213e8a..) t/xen/xl.cfg.no-final-newline-ok (depends on: t/xen/xl.cfg.mem-fix)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 11 14:24:10 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 2012 14:24: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 1TBRNe-0006cE-B2; Tue, 11 Sep 2012 14:23:58 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1TBRNc-0006bp-NX
	for xen-devel@lists.xen.org; Tue, 11 Sep 2012 14:23:56 +0000
Received: from [85.158.143.35:13421] by server-3.bemta-4.messagelabs.com id
	DF/0C-08232-C794F405; Tue, 11 Sep 2012 14:23:56 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1347373435!17738221!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQwNzc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6015 invoked from network); 11 Sep 2012 14:23:55 -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;
	11 Sep 2012 14:23:55 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 11 Sep 2012 15:23:54 +0100
Message-Id: <504F6599020000780009AADE@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 11 Sep 2012 15:23:53 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Campbell" <Ian.Campbell@citrix.com>,
	"Daniel De Graaf" <dgdegra@tycho.nsa.gov>
References: <504F3DBA.5040904@tycho.nsa.gov>
	<1347370437-31882-1-git-send-email-dgdegra@tycho.nsa.gov>
In-Reply-To: <1347370437-31882-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] xen/console: Add domain ID to output if
	VERBOSE
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.09.12 at 15:33, Daniel De Graaf <dgdegra@tycho.nsa.gov> wrote:
> @@ -339,6 +343,18 @@ static long guest_console_write(XEN_GUEST_HANDLE(char) 
> buffer, int count)
>  
>          spin_lock_irq(&console_lock);
>  
> +#ifdef VERBOSE
> +        snprintf(pbuf, sizeof(pbuf), "(%d) ", current->domain->domain_id);
> +        if (active != current->domain->domain_id) {
> +            sercon_puts(pbuf);
> +            vga_puts(pbuf);
> +
> +            active = current->domain->domain_id;
> +        }
> +        if (strchr(kbuf, '\n'))
> +            active = DOMID_IDLE;
> +#endif

This is too simplistic - you ought to be dealing with embedded '\n',
not just trailing ones.

Jan

> +
>          sercon_puts(kbuf);
>          vga_puts(kbuf);
>  
> -- 
> 1.7.11.4




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 11 14:24:10 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 2012 14:24: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 1TBRNe-0006cE-B2; Tue, 11 Sep 2012 14:23:58 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1TBRNc-0006bp-NX
	for xen-devel@lists.xen.org; Tue, 11 Sep 2012 14:23:56 +0000
Received: from [85.158.143.35:13421] by server-3.bemta-4.messagelabs.com id
	DF/0C-08232-C794F405; Tue, 11 Sep 2012 14:23:56 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1347373435!17738221!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQwNzc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6015 invoked from network); 11 Sep 2012 14:23:55 -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;
	11 Sep 2012 14:23:55 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 11 Sep 2012 15:23:54 +0100
Message-Id: <504F6599020000780009AADE@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 11 Sep 2012 15:23:53 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Campbell" <Ian.Campbell@citrix.com>,
	"Daniel De Graaf" <dgdegra@tycho.nsa.gov>
References: <504F3DBA.5040904@tycho.nsa.gov>
	<1347370437-31882-1-git-send-email-dgdegra@tycho.nsa.gov>
In-Reply-To: <1347370437-31882-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] xen/console: Add domain ID to output if
	VERBOSE
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.09.12 at 15:33, Daniel De Graaf <dgdegra@tycho.nsa.gov> wrote:
> @@ -339,6 +343,18 @@ static long guest_console_write(XEN_GUEST_HANDLE(char) 
> buffer, int count)
>  
>          spin_lock_irq(&console_lock);
>  
> +#ifdef VERBOSE
> +        snprintf(pbuf, sizeof(pbuf), "(%d) ", current->domain->domain_id);
> +        if (active != current->domain->domain_id) {
> +            sercon_puts(pbuf);
> +            vga_puts(pbuf);
> +
> +            active = current->domain->domain_id;
> +        }
> +        if (strchr(kbuf, '\n'))
> +            active = DOMID_IDLE;
> +#endif

This is too simplistic - you ought to be dealing with embedded '\n',
not just trailing ones.

Jan

> +
>          sercon_puts(kbuf);
>          vga_puts(kbuf);
>  
> -- 
> 1.7.11.4




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 11 14:27:31 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 2012 14: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 1TBRQu-0006p5-Hk; Tue, 11 Sep 2012 14:27: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 1TBRQt-0006oa-BC
	for xen-devel@lists.xen.org; Tue, 11 Sep 2012 14:27:19 +0000
Received: from [85.158.139.83:55053] by server-5.bemta-5.messagelabs.com id
	4C/03-30514-64A4F405; Tue, 11 Sep 2012 14:27:18 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1347373591!25985602!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDg1NjI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28809 invoked from network); 11 Sep 2012 14:26:31 -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;
	11 Sep 2012 14:26:31 -0000
X-IronPort-AV: E=Sophos;i="4.80,405,1344211200"; d="scan'208";a="14473452"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Sep 2012 14:26: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.279.1;
	Tue, 11 Sep 2012 15:26:31 +0100
Message-ID: <1347373589.5305.172.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Tue, 11 Sep 2012 15:26:29 +0100
In-Reply-To: <504F6599020000780009AADE@nat28.tlf.novell.com>
References: <504F3DBA.5040904@tycho.nsa.gov>
	<1347370437-31882-1-git-send-email-dgdegra@tycho.nsa.gov>
	<504F6599020000780009AADE@nat28.tlf.novell.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>, "Keir \(Xen.org\)" <keir@xen.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] xen/console: Add domain ID to output if
	VERBOSE
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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-09-11 at 15:23 +0100, Jan Beulich wrote:
> >>> On 11.09.12 at 15:33, Daniel De Graaf <dgdegra@tycho.nsa.gov> wrote:
> > @@ -339,6 +343,18 @@ static long guest_console_write(XEN_GUEST_HANDLE(char) 
> > buffer, int count)
> >  
> >          spin_lock_irq(&console_lock);
> >  
> > +#ifdef VERBOSE
> > +        snprintf(pbuf, sizeof(pbuf), "(%d) ", current->domain->domain_id);
> > +        if (active != current->domain->domain_id) {
> > +            sercon_puts(pbuf);
> > +            vga_puts(pbuf);
> > +
> > +            active = current->domain->domain_id;
> > +        }
> > +        if (strchr(kbuf, '\n'))
> > +            active = DOMID_IDLE;
> > +#endif
> 
> This is too simplistic - you ought to be dealing with embedded '\n',
> not just trailing ones.

hvm_print_line should perhaps become more generic?

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 11 14:27:31 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 2012 14: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 1TBRQu-0006p5-Hk; Tue, 11 Sep 2012 14:27: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 1TBRQt-0006oa-BC
	for xen-devel@lists.xen.org; Tue, 11 Sep 2012 14:27:19 +0000
Received: from [85.158.139.83:55053] by server-5.bemta-5.messagelabs.com id
	4C/03-30514-64A4F405; Tue, 11 Sep 2012 14:27:18 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1347373591!25985602!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDg1NjI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28809 invoked from network); 11 Sep 2012 14:26:31 -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;
	11 Sep 2012 14:26:31 -0000
X-IronPort-AV: E=Sophos;i="4.80,405,1344211200"; d="scan'208";a="14473452"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Sep 2012 14:26: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.279.1;
	Tue, 11 Sep 2012 15:26:31 +0100
Message-ID: <1347373589.5305.172.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Tue, 11 Sep 2012 15:26:29 +0100
In-Reply-To: <504F6599020000780009AADE@nat28.tlf.novell.com>
References: <504F3DBA.5040904@tycho.nsa.gov>
	<1347370437-31882-1-git-send-email-dgdegra@tycho.nsa.gov>
	<504F6599020000780009AADE@nat28.tlf.novell.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>, "Keir \(Xen.org\)" <keir@xen.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] xen/console: Add domain ID to output if
	VERBOSE
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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-09-11 at 15:23 +0100, Jan Beulich wrote:
> >>> On 11.09.12 at 15:33, Daniel De Graaf <dgdegra@tycho.nsa.gov> wrote:
> > @@ -339,6 +343,18 @@ static long guest_console_write(XEN_GUEST_HANDLE(char) 
> > buffer, int count)
> >  
> >          spin_lock_irq(&console_lock);
> >  
> > +#ifdef VERBOSE
> > +        snprintf(pbuf, sizeof(pbuf), "(%d) ", current->domain->domain_id);
> > +        if (active != current->domain->domain_id) {
> > +            sercon_puts(pbuf);
> > +            vga_puts(pbuf);
> > +
> > +            active = current->domain->domain_id;
> > +        }
> > +        if (strchr(kbuf, '\n'))
> > +            active = DOMID_IDLE;
> > +#endif
> 
> This is too simplistic - you ought to be dealing with embedded '\n',
> not just trailing ones.

hvm_print_line should perhaps become more generic?

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 11 14:27:54 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 2012 14:27:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TBRQs-0006oc-Vl; Tue, 11 Sep 2012 14:27:18 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1TBRQq-0006oP-Vf
	for xen-devel@lists.xen.org; Tue, 11 Sep 2012 14:27:17 +0000
Received: from [85.158.143.35:33763] by server-2.bemta-4.messagelabs.com id
	21/9E-21239-44A4F405; Tue, 11 Sep 2012 14:27:16 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1347373635!10404389!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQwNzc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4767 invoked from network); 11 Sep 2012 14:27:15 -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;
	11 Sep 2012 14:27:15 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 11 Sep 2012 15:27:15 +0100
Message-Id: <504F6660020000780009AAE1@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 11 Sep 2012 15:27:12 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "=?UTF-8?B?4KSF4KSo4KS/4KSV4KWH4KSkIOCkhuCkl+CkvuCktuClhw==?="
	<agasheac@gmail.com>
References: <CAMQ5s704d8-UscdPtpJ8GPMs_YzTjiOupdi9mWfpfDrRnYV=vQ@mail.gmail.com>
In-Reply-To: <CAMQ5s704d8-UscdPtpJ8GPMs_YzTjiOupdi9mWfpfDrRnYV=vQ@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] xen not able to use total physical memory present
 in the system (192GB)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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+IE9uIDExLjA5LjEyIGF0IDE1OjM3LCDgpIXgpKjgpL/gpJXgpYfgpKQg4KSG4KSX4KS+4KS2
4KWHIDxhZ2FzaGVhY0BnbWFpbC5jb20+IHdyb3RlOgo+IEkgYW0gdXNpbmcgeGVuLTQuMS4yIHdp
dGggZmVkb3JhLTE2IChrZXJuZWwgdmVyc2lvbiAzLjEuMC43KSBhcyBkb20wIG9uCj4gc3lzdGVt
IGhhdmluZyAxOTJHQiBvZiBSQU0uCj4gCj4gV2hlbiBpIGJvb3RlZCBzeXN0ZW0geG0gaW5mbyBz
aG93cyAodG90YWwgX21lbW9yeSBwYXJhbWV0ZXIgYXMgMTkyR0IgYW5kCj4gZnJlZV9tZW1vcnkg
YXMgMjVNQikgZnVsbCBtZW1vcnkgYnV0IC9wcm9jL21lbWluZm8gcmVwb3J0cyAxMzJHQiBhbmQg
eG0KPiBsaXN0IGFsc28gcmVwb3J0cyAxOTJHQiBmb3IgZG9tMAo+IAo+IFdoZW4gSSByYW4gZmly
c3QgVk0gd2l0aCAzMkdCIFJBTSwgeG0gaW5mbyBzdGFydGVkIHJlcG9ydGluZyBtZW1vcnkgZm9y
Cj4gZG9tMCBhcm91bmQgMTMyR0IgYW5kIDMyR0IgZm9yIFZNIGFuZCBjYXQgL3Byb2MvbWVtaW5m
byBvbiBkb20wIHJlcG9ydGVkCj4gYXJvdW5kIDEwMEdCLiBJIGFtIGFibGUgdG8gYm9vdCA0IFZN
cyB3aXRoIHRoaXMgc2V0dXAgYnV0IDV0aCBWTSBmYWlscyB0bwo+IGJvb3Qgd2l0aCBub3QgZW5v
dWdoIG1lbW9yeS4KCldpdGhvdXQgeW91IHByb3ZpZGluZyBsb2dzLCB3ZSBjYW4gb25seSBndWVz
cyAtIGxpa2UgUGFzaSBkaWQgLSB0aGF0CnRoaXMgbWF5IGJlIGEgRG9tMCBrZXJuZWwgaXNzdWUu
CgpBbmQgLSB5b3UgYXJlbid0LCBieSBjaGFuY2UsIHJ1bm5pbmcgYSAzMi1iaXQgRG9tMCBrZXJu
ZWw/CgpKYW4KCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
Clhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbi5vcmcKaHR0cDovL2xp
c3RzLnhlbi5vcmcveGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Tue Sep 11 14:27:54 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 2012 14:27:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TBRQs-0006oc-Vl; Tue, 11 Sep 2012 14:27:18 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1TBRQq-0006oP-Vf
	for xen-devel@lists.xen.org; Tue, 11 Sep 2012 14:27:17 +0000
Received: from [85.158.143.35:33763] by server-2.bemta-4.messagelabs.com id
	21/9E-21239-44A4F405; Tue, 11 Sep 2012 14:27:16 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1347373635!10404389!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQwNzc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4767 invoked from network); 11 Sep 2012 14:27:15 -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;
	11 Sep 2012 14:27:15 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 11 Sep 2012 15:27:15 +0100
Message-Id: <504F6660020000780009AAE1@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 11 Sep 2012 15:27:12 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "=?UTF-8?B?4KSF4KSo4KS/4KSV4KWH4KSkIOCkhuCkl+CkvuCktuClhw==?="
	<agasheac@gmail.com>
References: <CAMQ5s704d8-UscdPtpJ8GPMs_YzTjiOupdi9mWfpfDrRnYV=vQ@mail.gmail.com>
In-Reply-To: <CAMQ5s704d8-UscdPtpJ8GPMs_YzTjiOupdi9mWfpfDrRnYV=vQ@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] xen not able to use total physical memory present
 in the system (192GB)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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+IE9uIDExLjA5LjEyIGF0IDE1OjM3LCDgpIXgpKjgpL/gpJXgpYfgpKQg4KSG4KSX4KS+4KS2
4KWHIDxhZ2FzaGVhY0BnbWFpbC5jb20+IHdyb3RlOgo+IEkgYW0gdXNpbmcgeGVuLTQuMS4yIHdp
dGggZmVkb3JhLTE2IChrZXJuZWwgdmVyc2lvbiAzLjEuMC43KSBhcyBkb20wIG9uCj4gc3lzdGVt
IGhhdmluZyAxOTJHQiBvZiBSQU0uCj4gCj4gV2hlbiBpIGJvb3RlZCBzeXN0ZW0geG0gaW5mbyBz
aG93cyAodG90YWwgX21lbW9yeSBwYXJhbWV0ZXIgYXMgMTkyR0IgYW5kCj4gZnJlZV9tZW1vcnkg
YXMgMjVNQikgZnVsbCBtZW1vcnkgYnV0IC9wcm9jL21lbWluZm8gcmVwb3J0cyAxMzJHQiBhbmQg
eG0KPiBsaXN0IGFsc28gcmVwb3J0cyAxOTJHQiBmb3IgZG9tMAo+IAo+IFdoZW4gSSByYW4gZmly
c3QgVk0gd2l0aCAzMkdCIFJBTSwgeG0gaW5mbyBzdGFydGVkIHJlcG9ydGluZyBtZW1vcnkgZm9y
Cj4gZG9tMCBhcm91bmQgMTMyR0IgYW5kIDMyR0IgZm9yIFZNIGFuZCBjYXQgL3Byb2MvbWVtaW5m
byBvbiBkb20wIHJlcG9ydGVkCj4gYXJvdW5kIDEwMEdCLiBJIGFtIGFibGUgdG8gYm9vdCA0IFZN
cyB3aXRoIHRoaXMgc2V0dXAgYnV0IDV0aCBWTSBmYWlscyB0bwo+IGJvb3Qgd2l0aCBub3QgZW5v
dWdoIG1lbW9yeS4KCldpdGhvdXQgeW91IHByb3ZpZGluZyBsb2dzLCB3ZSBjYW4gb25seSBndWVz
cyAtIGxpa2UgUGFzaSBkaWQgLSB0aGF0CnRoaXMgbWF5IGJlIGEgRG9tMCBrZXJuZWwgaXNzdWUu
CgpBbmQgLSB5b3UgYXJlbid0LCBieSBjaGFuY2UsIHJ1bm5pbmcgYSAzMi1iaXQgRG9tMCBrZXJu
ZWw/CgpKYW4KCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
Clhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbi5vcmcKaHR0cDovL2xp
c3RzLnhlbi5vcmcveGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Tue Sep 11 14:28:51 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 2012 14:28: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 1TBRSG-00071X-1X; Tue, 11 Sep 2012 14:28:44 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andreslc@gridcentric.ca>) id 1TBRSE-00071J-C1
	for xen-devel@lists.xen.org; Tue, 11 Sep 2012 14:28:42 +0000
Received: from [85.158.143.99:50018] by server-1.bemta-4.messagelabs.com id
	3F/D3-12504-99A4F405; Tue, 11 Sep 2012 14:28:41 +0000
X-Env-Sender: andreslc@gridcentric.ca
X-Msg-Ref: server-16.tower-216.messagelabs.com!1347373720!18537371!1
X-Originating-IP: [209.85.161.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22067 invoked from network); 11 Sep 2012 14:28:41 -0000
Received: from mail-gg0-f173.google.com (HELO mail-gg0-f173.google.com)
	(209.85.161.173)
	by server-16.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Sep 2012 14:28:41 -0000
Received: by ggna5 with SMTP id a5so102937ggn.32
	for <xen-devel@lists.xen.org>; Tue, 11 Sep 2012 07:28:39 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=subject:mime-version:content-type:from:in-reply-to:date:cc
	:content-transfer-encoding:message-id:references:to:x-mailer
	:x-gm-message-state;
	bh=THY/7Og+zD8uocGl8Y9jKV99wwkK2jUCeLgu/Q4NhYs=;
	b=O6L2st/fYTduwY02Sp1kckV4q/26yJZS0z2dLGah8+KrAC7hFnGhVqOoI4xsRpMowj
	zr9mImIr11j+54CEFxJrYPkjvZ5onkvOIp7YQI72RLzXvhsPGrUoHnmw5i9LUv0IzfJL
	5EWsEsHsW4uBM04v+CDO4x9ye3N0nHulc8kwFZrv90SqgLqWFCV0DgKfXIpS8sGt2yCf
	69vq7BcqV50en2Ycl0paiN/G5ElX2JDR7ZDob3jWeI7u6PNq7/12g7e/oKXSxR7nJ7e4
	GRWWk88uqKE4ALP3bp7UX77jetC/dpYsv+1riqB1HTAYIrVRsZn9k7SFlxzxdUZCcNHW
	Xxkw==
Received: by 10.236.143.4 with SMTP id k4mr15842874yhj.111.1347373719731;
	Tue, 11 Sep 2012 07:28:39 -0700 (PDT)
Received: from [192.168.7.212] ([206.223.182.18])
	by mx.google.com with ESMTPS id y13sm14471544anj.5.2012.09.11.07.28.37
	(version=TLSv1/SSLv3 cipher=OTHER);
	Tue, 11 Sep 2012 07:28:38 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1278)
From: Andres Lagar-Cavilla <andreslc@gridcentric.ca>
In-Reply-To: <1347294370.5305.116.camel@zakaz.uk.xensource.com>
Date: Tue, 11 Sep 2012 10:28:37 -0400
Message-Id: <73F7FCEA-3263-4A2D-99DC-F75901963118@gridcentric.ca>
References: <99b7a5af9b3059bac273.1346676538@cosworth.uk.xensource.com>
	<20551.26024.217179.594711@mariner.uk.xensource.com>
	<1346856750.17325.110.camel@zakaz.uk.xensource.com>
	<1347294370.5305.116.camel@zakaz.uk.xensource.com>
To: "Daniel De Graaf" <dgdegra@tycho.nsa.gov>
X-Mailer: Apple Mail (2.1278)
X-Gm-Message-State: ALoCoQn//PfXIU4BWk+/Zu6zqqQJ5Fntb7kEb+7rvPLiRF+eb3TOJvl74JrMic6jEynaF95SaLVY
Cc: Keir Fraser <keir@xen.org>, "Tim \(Xen.org\)" <tim@xen.org>,
	Jan Beulich <JBeulich@suse.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 13/20] arch/x86: Add missing domctl and
	mem_sharing XSM hooks
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 looks good but I have one concern. In the hunk below you dropped the cd->is_dying check.
Andres

> diff --git a/xen/arch/x86/mm/mem_sharing.c b/xen/arch/x86/mm/mem_sharing.c
> index 5103285..395d302 100644
> --- a/xen/arch/x86/mm/mem_sharing.c
> +++ b/xen/arch/x86/mm/mem_sharing.c
> @@ -34,6 +34,7 @@
>  #include <asm/atomic.h>
>  #include <xen/rcupdate.h>
>  #include <asm/event.h>
> +#include <xsm/xsm.h>
>  
>  #include "mm-locks.h"
>  
> @@ -1345,11 +1346,18 @@ int mem_sharing_memop(struct domain *d, 
> xen_mem_sharing_op_t *mec)
>              if ( !mem_sharing_enabled(d) )
>                  return -EINVAL;
>  
> -            cd = get_mem_event_op_target(mec->u.share.client_domain, &rc);
> +            cd = rcu_lock_domain_by_any_id(mec->u.share.client_domain);
>              if ( !cd )
> +                return -ESRCH;
> +
> +            rc = xsm_mem_sharing_op(d, cd, mec->op);
> +            if ( rc )
> +            {
> +                rcu_unlock_domain(cd);
>                  return rc;
> +            }
>  
> -            if ( !mem_sharing_enabled(cd) )
> +            if ( cd == current->domain || !mem_sharing_enabled(cd) )
>              {
>                  rcu_unlock_domain(cd);
>                  return -EINVAL;
> @@ -1401,11 +1409,18 @@ int mem_sharing_memop(struct domain *d, 
> xen_mem_sharing_op_t *mec)
>              if ( !mem_sharing_enabled(d) )
>                  return -EINVAL;
>  
> -            cd = get_mem_event_op_target(mec->u.share.client_domain, &rc);
> +            cd = rcu_lock_domain_by_any_id(mec->u.share.client_domain);
>              if ( !cd )
> +                return -ESRCH;
> +
> +            rc = xsm_mem_sharing_op(d, cd, mec->op);
> +            if ( rc )
> +            {
> +                rcu_unlock_domain(cd);
>                  return rc;
> +            }
>  
> -            if ( !mem_sharing_enabled(cd) )
> +            if ( cd == current->domain || !mem_sharing_enabled(cd) )
>              {
>                  rcu_unlock_domain(cd);
>                  return -EINVAL;
> 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 11 14:28:51 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 2012 14:28: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 1TBRSG-00071X-1X; Tue, 11 Sep 2012 14:28:44 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andreslc@gridcentric.ca>) id 1TBRSE-00071J-C1
	for xen-devel@lists.xen.org; Tue, 11 Sep 2012 14:28:42 +0000
Received: from [85.158.143.99:50018] by server-1.bemta-4.messagelabs.com id
	3F/D3-12504-99A4F405; Tue, 11 Sep 2012 14:28:41 +0000
X-Env-Sender: andreslc@gridcentric.ca
X-Msg-Ref: server-16.tower-216.messagelabs.com!1347373720!18537371!1
X-Originating-IP: [209.85.161.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22067 invoked from network); 11 Sep 2012 14:28:41 -0000
Received: from mail-gg0-f173.google.com (HELO mail-gg0-f173.google.com)
	(209.85.161.173)
	by server-16.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Sep 2012 14:28:41 -0000
Received: by ggna5 with SMTP id a5so102937ggn.32
	for <xen-devel@lists.xen.org>; Tue, 11 Sep 2012 07:28:39 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=subject:mime-version:content-type:from:in-reply-to:date:cc
	:content-transfer-encoding:message-id:references:to:x-mailer
	:x-gm-message-state;
	bh=THY/7Og+zD8uocGl8Y9jKV99wwkK2jUCeLgu/Q4NhYs=;
	b=O6L2st/fYTduwY02Sp1kckV4q/26yJZS0z2dLGah8+KrAC7hFnGhVqOoI4xsRpMowj
	zr9mImIr11j+54CEFxJrYPkjvZ5onkvOIp7YQI72RLzXvhsPGrUoHnmw5i9LUv0IzfJL
	5EWsEsHsW4uBM04v+CDO4x9ye3N0nHulc8kwFZrv90SqgLqWFCV0DgKfXIpS8sGt2yCf
	69vq7BcqV50en2Ycl0paiN/G5ElX2JDR7ZDob3jWeI7u6PNq7/12g7e/oKXSxR7nJ7e4
	GRWWk88uqKE4ALP3bp7UX77jetC/dpYsv+1riqB1HTAYIrVRsZn9k7SFlxzxdUZCcNHW
	Xxkw==
Received: by 10.236.143.4 with SMTP id k4mr15842874yhj.111.1347373719731;
	Tue, 11 Sep 2012 07:28:39 -0700 (PDT)
Received: from [192.168.7.212] ([206.223.182.18])
	by mx.google.com with ESMTPS id y13sm14471544anj.5.2012.09.11.07.28.37
	(version=TLSv1/SSLv3 cipher=OTHER);
	Tue, 11 Sep 2012 07:28:38 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1278)
From: Andres Lagar-Cavilla <andreslc@gridcentric.ca>
In-Reply-To: <1347294370.5305.116.camel@zakaz.uk.xensource.com>
Date: Tue, 11 Sep 2012 10:28:37 -0400
Message-Id: <73F7FCEA-3263-4A2D-99DC-F75901963118@gridcentric.ca>
References: <99b7a5af9b3059bac273.1346676538@cosworth.uk.xensource.com>
	<20551.26024.217179.594711@mariner.uk.xensource.com>
	<1346856750.17325.110.camel@zakaz.uk.xensource.com>
	<1347294370.5305.116.camel@zakaz.uk.xensource.com>
To: "Daniel De Graaf" <dgdegra@tycho.nsa.gov>
X-Mailer: Apple Mail (2.1278)
X-Gm-Message-State: ALoCoQn//PfXIU4BWk+/Zu6zqqQJ5Fntb7kEb+7rvPLiRF+eb3TOJvl74JrMic6jEynaF95SaLVY
Cc: Keir Fraser <keir@xen.org>, "Tim \(Xen.org\)" <tim@xen.org>,
	Jan Beulich <JBeulich@suse.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 13/20] arch/x86: Add missing domctl and
	mem_sharing XSM hooks
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 looks good but I have one concern. In the hunk below you dropped the cd->is_dying check.
Andres

> diff --git a/xen/arch/x86/mm/mem_sharing.c b/xen/arch/x86/mm/mem_sharing.c
> index 5103285..395d302 100644
> --- a/xen/arch/x86/mm/mem_sharing.c
> +++ b/xen/arch/x86/mm/mem_sharing.c
> @@ -34,6 +34,7 @@
>  #include <asm/atomic.h>
>  #include <xen/rcupdate.h>
>  #include <asm/event.h>
> +#include <xsm/xsm.h>
>  
>  #include "mm-locks.h"
>  
> @@ -1345,11 +1346,18 @@ int mem_sharing_memop(struct domain *d, 
> xen_mem_sharing_op_t *mec)
>              if ( !mem_sharing_enabled(d) )
>                  return -EINVAL;
>  
> -            cd = get_mem_event_op_target(mec->u.share.client_domain, &rc);
> +            cd = rcu_lock_domain_by_any_id(mec->u.share.client_domain);
>              if ( !cd )
> +                return -ESRCH;
> +
> +            rc = xsm_mem_sharing_op(d, cd, mec->op);
> +            if ( rc )
> +            {
> +                rcu_unlock_domain(cd);
>                  return rc;
> +            }
>  
> -            if ( !mem_sharing_enabled(cd) )
> +            if ( cd == current->domain || !mem_sharing_enabled(cd) )
>              {
>                  rcu_unlock_domain(cd);
>                  return -EINVAL;
> @@ -1401,11 +1409,18 @@ int mem_sharing_memop(struct domain *d, 
> xen_mem_sharing_op_t *mec)
>              if ( !mem_sharing_enabled(d) )
>                  return -EINVAL;
>  
> -            cd = get_mem_event_op_target(mec->u.share.client_domain, &rc);
> +            cd = rcu_lock_domain_by_any_id(mec->u.share.client_domain);
>              if ( !cd )
> +                return -ESRCH;
> +
> +            rc = xsm_mem_sharing_op(d, cd, mec->op);
> +            if ( rc )
> +            {
> +                rcu_unlock_domain(cd);
>                  return rc;
> +            }
>  
> -            if ( !mem_sharing_enabled(cd) )
> +            if ( cd == current->domain || !mem_sharing_enabled(cd) )
>              {
>                  rcu_unlock_domain(cd);
>                  return -EINVAL;
> 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 11 14:31:44 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 2012 14:31:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TBRUj-0007FC-KW; Tue, 11 Sep 2012 14:31: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 1TBRUh-0007Ew-Ux
	for xen-devel@lists.xen.org; Tue, 11 Sep 2012 14:31:16 +0000
Received: from [85.158.143.99:60260] by server-2.bemta-4.messagelabs.com id
	A6/36-21239-33B4F405; Tue, 11 Sep 2012 14:31:15 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1347373864!26385824!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDg1NjI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28622 invoked from network); 11 Sep 2012 14:31:13 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Sep 2012 14:31:13 -0000
X-IronPort-AV: E=Sophos;i="4.80,405,1344211200"; d="scan'208";a="14473629"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Sep 2012 14:31: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.279.1;
	Tue, 11 Sep 2012 15:31:03 +0100
Message-ID: <1347373862.5305.176.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Tue, 11 Sep 2012 15:31:02 +0100
In-Reply-To: <20559.18783.257111.373451@mariner.uk.xensource.com>
References: <20559.18783.257111.373451@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Jan Beulich <JBeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] libxl: Tolerate xl config files missing
	trailing newline
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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-09-11 at 15:23 +0100, Ian Jackson wrote:
> I wrote:
> > Also I wrote:
> > > However, xl fails on config files which are missing the final
> > > newline.  This should be fixed for 4.2.
> > 
> > My patch for this didn't make it into 4.2 RC4.
> 
> Should this go into 4.2.0 or be held for 4.2.1 (or is it not 4.2.x
> material at all) ?

4.2.1 IMHO, the workaround for 4.2.0 is obvious enough, I think.

BTW, does this correctly handle the way extra args are pinned onto the
end in create in xl (I mean the stuff which comes from the cmdline which
are glommed onto the end of the config file internally).

On a related note Bastian complained a while ago that the line numbers
reported on syntax error were bogus/meaningless (and a little confusing)
for parameters from the command line -- can you think of a way to fix
that (for 4.3 of course). I was thinking along the lines of supporting
and injecting a "#pragma everything-from-here-from-the-command-line",
but maybe you have a better idea, like iterative parsing of multiple
inputs.

> 
> Ian.
> 
> From: Ian Jackson <ian.jackson@eu.citrix.com>
> Subject: [PATCH] libxl: Tolerate xl config files missing trailing newline
> 
> Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
> 
> ---
>  tools/libxl/libxlu_cfg_y.c |  154 +++++++++++++++++++++++---------------------
>  tools/libxl/libxlu_cfg_y.y |   12 ++-
>  2 files changed, 88 insertions(+), 78 deletions(-)
> 
> diff --git a/tools/libxl/libxlu_cfg_y.c b/tools/libxl/libxlu_cfg_y.c
> index 5214386..218933e 100644
> --- a/tools/libxl/libxlu_cfg_y.c
> +++ b/tools/libxl/libxlu_cfg_y.c
> @@ -373,18 +373,18 @@ union yyalloc
>  #endif
>  
>  /* YYFINAL -- State number of the termination state.  */
> -#define YYFINAL  2
> +#define YYFINAL  3
>  /* YYLAST -- Last index in YYTABLE.  */
> -#define YYLAST   23
> +#define YYLAST   24
>  
>  /* YYNTOKENS -- Number of terminals.  */
>  #define YYNTOKENS  12
>  /* YYNNTS -- Number of nonterminals.  */
> -#define YYNNTS  9
> +#define YYNNTS  11
>  /* YYNRULES -- Number of rules.  */
> -#define YYNRULES  19
> +#define YYNRULES  22
>  /* YYNRULES -- Number of states.  */
> -#define YYNSTATES  28
> +#define YYNSTATES  30
>  
>  /* YYTRANSLATE(YYLEX) -- Bison symbol number corresponding to YYLEX.  */
>  #define YYUNDEFTOK  2
> @@ -430,26 +430,28 @@ static const yytype_uint8 yytranslate[] =
>     YYRHS.  */
>  static const yytype_uint8 yyprhs[] =
>  {
> -       0,     0,     3,     4,     7,    12,    14,    17,    19,    21,
> -      23,    28,    30,    32,    33,    35,    39,    42,    48,    49
> +       0,     0,     3,     5,     8,     9,    12,    15,    17,    20,
> +      24,    26,    28,    30,    35,    37,    39,    40,    42,    46,
> +      49,    55,    56
>  };
>  
>  /* YYRHS -- A `-1'-separated list of the rules' RHS.  */
>  static const yytype_int8 yyrhs[] =
>  {
> -      13,     0,    -1,    -1,    13,    14,    -1,     3,     7,    16,
> -      15,    -1,    15,    -1,     1,     6,    -1,     6,    -1,     8,
> -      -1,    17,    -1,     9,    20,    18,    10,    -1,     4,    -1,
> -       5,    -1,    -1,    19,    -1,    19,    11,    20,    -1,    17,
> -      20,    -1,    19,    11,    20,    17,    20,    -1,    -1,    20,
> -       6,    -1
> +      13,     0,    -1,    14,    -1,    14,    16,    -1,    -1,    14,
> +      15,    -1,    16,    17,    -1,    17,    -1,     1,     6,    -1,
> +       3,     7,    18,    -1,     6,    -1,     8,    -1,    19,    -1,
> +       9,    22,    20,    10,    -1,     4,    -1,     5,    -1,    -1,
> +      21,    -1,    21,    11,    22,    -1,    19,    22,    -1,    21,
> +      11,    22,    19,    22,    -1,    -1,    22,     6,    -1
>  };
>  
>  /* YYRLINE[YYN] -- source line where rule number YYN was defined.  */
>  static const yytype_uint8 yyrline[] =
>  {
> -       0,    47,    47,    48,    50,    52,    53,    55,    56,    58,
> -      59,    61,    62,    64,    65,    66,    68,    69,    71,    73
> +       0,    47,    47,    48,    50,    51,    53,    54,    55,    57,
> +      59,    60,    62,    63,    65,    66,    68,    69,    70,    72,
> +      73,    75,    77
>  };
>  #endif
>  
> @@ -459,8 +461,8 @@ static const yytype_uint8 yyrline[] =
>  static const char *const yytname[] =
>  {
>    "$end", "error", "$undefined", "IDENT", "STRING", "NUMBER", "NEWLINE",
> -  "'='", "';'", "'['", "']'", "','", "$accept", "file", "assignment",
> -  "endstmt", "value", "atom", "valuelist", "values", "nlok", 0
> +  "'='", "';'", "'['", "']'", "','", "$accept", "file", "stmts", "stmt",
> +  "assignment", "endstmt", "value", "atom", "valuelist", "values", "nlok", 0
>  };
>  #endif
>  
> @@ -477,15 +479,17 @@ static const yytype_uint16 yytoknum[] =
>  /* YYR1[YYN] -- Symbol number of symbol that rule YYN derives.  */
>  static const yytype_uint8 yyr1[] =
>  {
> -       0,    12,    13,    13,    14,    14,    14,    15,    15,    16,
> -      16,    17,    17,    18,    18,    18,    19,    19,    20,    20
> +       0,    12,    13,    13,    14,    14,    15,    15,    15,    16,
> +      17,    17,    18,    18,    19,    19,    20,    20,    20,    21,
> +      21,    22,    22
>  };
>  
>  /* YYR2[YYN] -- Number of symbols composing right hand side of rule YYN.  */
>  static const yytype_uint8 yyr2[] =
>  {
> -       0,     2,     0,     2,     4,     1,     2,     1,     1,     1,
> -       4,     1,     1,     0,     1,     3,     2,     5,     0,     2
> +       0,     2,     1,     2,     0,     2,     2,     1,     2,     3,
> +       1,     1,     1,     4,     1,     1,     0,     1,     3,     2,
> +       5,     0,     2
>  };
>  
>  /* YYDEFACT[STATE-NAME] -- Default rule to reduce with in state
> @@ -493,59 +497,61 @@ static const yytype_uint8 yyr2[] =
>     means the default is an error.  */
>  static const yytype_uint8 yydefact[] =
>  {
> -       2,     0,     1,     0,     0,     7,     8,     3,     5,     6,
> -       0,    11,    12,    18,     0,     9,    13,     4,    19,    18,
> -       0,    14,    16,    10,    18,    15,    18,    17
> +       4,     0,     0,     1,     0,     0,    10,    11,     5,     3,
> +       7,     8,     0,     6,    14,    15,    21,     9,    12,    16,
> +      22,    21,     0,    17,    19,    13,    21,    18,    21,    20
>  };
>  
>  /* YYDEFGOTO[NTERM-NUM].  */
>  static const yytype_int8 yydefgoto[] =
>  {
> -      -1,     1,     7,     8,    14,    15,    20,    21,    16
> +      -1,     1,     2,     8,     9,    10,    17,    18,    22,    23,
> +      19
>  };
>  
>  /* YYPACT[STATE-NUM] -- Index in YYTABLE of the portion describing
>     STATE-NUM.  */
> -#define YYPACT_NINF -17
> +#define YYPACT_NINF -18
>  static const yytype_int8 yypact[] =
>  {
> -     -17,     2,   -17,    -5,    -3,   -17,   -17,   -17,   -17,   -17,
> -      10,   -17,   -17,   -17,    14,   -17,    12,   -17,   -17,   -17,
> -      11,    -4,     6,   -17,   -17,    12,   -17,     6
> +     -18,     4,     0,   -18,    -1,     6,   -18,   -18,   -18,     3,
> +     -18,   -18,    11,   -18,   -18,   -18,   -18,   -18,   -18,    13,
> +     -18,   -18,    12,    10,    17,   -18,   -18,    13,   -18,    17
>  };
>  
>  /* YYPGOTO[NTERM-NUM].  */
>  static const yytype_int8 yypgoto[] =
>  {
> -     -17,   -17,   -17,     9,   -17,   -16,   -17,   -17,   -13
> +     -18,   -18,   -18,   -18,   -18,    15,   -18,   -17,   -18,   -18,
> +     -14
>  };
>  
>  /* YYTABLE[YYPACT[STATE-NUM]].  What to do in state STATE-NUM.  If
>     positive, shift that token.  If negative, reduce the rule which
>     number is the opposite.  If zero, do what YYDEFACT says.
>     If YYTABLE_NINF, syntax error.  */
> -#define YYTABLE_NINF -1
> -static const yytype_uint8 yytable[] =
> +#define YYTABLE_NINF -3
> +static const yytype_int8 yytable[] =
>  {
> -      19,     9,     2,     3,    10,     4,    22,    24,     5,    26,
> -       6,    25,    18,    27,    11,    12,    11,    12,    18,    13,
> -       5,    23,     6,    17
> +      -2,     4,    21,     5,     3,    11,     6,    24,     7,     6,
> +      28,     7,    27,    12,    29,    14,    15,    14,    15,    20,
> +      16,    26,    25,    20,    13
>  };
>  
>  static const yytype_uint8 yycheck[] =
>  {
> -      16,     6,     0,     1,     7,     3,    19,    11,     6,    25,
> -       8,    24,     6,    26,     4,     5,     4,     5,     6,     9,
> -       6,    10,     8,    14
> +       0,     1,    19,     3,     0,     6,     6,    21,     8,     6,
> +      27,     8,    26,     7,    28,     4,     5,     4,     5,     6,
> +       9,    11,    10,     6,     9
>  };
>  
>  /* YYSTOS[STATE-NUM] -- The (internal number of the) accessing
>     symbol of state STATE-NUM.  */
>  static const yytype_uint8 yystos[] =
>  {
> -       0,    13,     0,     1,     3,     6,     8,    14,    15,     6,
> -       7,     4,     5,     9,    16,    17,    20,    15,     6,    17,
> -      18,    19,    20,    10,    11,    20,    17,    20
> +       0,    13,    14,     0,     1,     3,     6,     8,    15,    16,
> +      17,     6,     7,    17,     4,     5,     9,    18,    19,    22,
> +       6,    19,    20,    21,    22,    10,    11,    22,    19,    22
>  };
>  
>  #define yyerrok		(yyerrstatus = 0)
> @@ -1077,7 +1083,7 @@ yydestruct (yymsg, yytype, yyvaluep, yylocationp, ctx)
>  	{ free((yyvaluep->string)); };
>  
>  /* Line 1000 of yacc.c  */
> -#line 1081 "libxlu_cfg_y.c"
> +#line 1087 "libxlu_cfg_y.c"
>  	break;
>        case 4: /* "STRING" */
>  
> @@ -1086,7 +1092,7 @@ yydestruct (yymsg, yytype, yyvaluep, yylocationp, ctx)
>  	{ free((yyvaluep->string)); };
>  
>  /* Line 1000 of yacc.c  */
> -#line 1090 "libxlu_cfg_y.c"
> +#line 1096 "libxlu_cfg_y.c"
>  	break;
>        case 5: /* "NUMBER" */
>  
> @@ -1095,43 +1101,43 @@ yydestruct (yymsg, yytype, yyvaluep, yylocationp, ctx)
>  	{ free((yyvaluep->string)); };
>  
>  /* Line 1000 of yacc.c  */
> -#line 1099 "libxlu_cfg_y.c"
> +#line 1105 "libxlu_cfg_y.c"
>  	break;
> -      case 16: /* "value" */
> +      case 18: /* "value" */
>  
>  /* Line 1000 of yacc.c  */
>  #line 43 "libxlu_cfg_y.y"
>  	{ xlu__cfg_set_free((yyvaluep->setting)); };
>  
>  /* Line 1000 of yacc.c  */
> -#line 1108 "libxlu_cfg_y.c"
> +#line 1114 "libxlu_cfg_y.c"
>  	break;
> -      case 17: /* "atom" */
> +      case 19: /* "atom" */
>  
>  /* Line 1000 of yacc.c  */
>  #line 40 "libxlu_cfg_y.y"
>  	{ free((yyvaluep->string)); };
>  
>  /* Line 1000 of yacc.c  */
> -#line 1117 "libxlu_cfg_y.c"
> +#line 1123 "libxlu_cfg_y.c"
>  	break;
> -      case 18: /* "valuelist" */
> +      case 20: /* "valuelist" */
>  
>  /* Line 1000 of yacc.c  */
>  #line 43 "libxlu_cfg_y.y"
>  	{ xlu__cfg_set_free((yyvaluep->setting)); };
>  
>  /* Line 1000 of yacc.c  */
> -#line 1126 "libxlu_cfg_y.c"
> +#line 1132 "libxlu_cfg_y.c"
>  	break;
> -      case 19: /* "values" */
> +      case 21: /* "values" */
>  
>  /* Line 1000 of yacc.c  */
>  #line 43 "libxlu_cfg_y.y"
>  	{ xlu__cfg_set_free((yyvaluep->setting)); };
>  
>  /* Line 1000 of yacc.c  */
> -#line 1135 "libxlu_cfg_y.c"
> +#line 1141 "libxlu_cfg_y.c"
>  	break;
>  
>        default:
> @@ -1459,80 +1465,80 @@ yyreduce:
>    YY_REDUCE_PRINT (yyn);
>    switch (yyn)
>      {
> -        case 4:
> +        case 9:
>  
>  /* Line 1455 of yacc.c  */
> -#line 51 "libxlu_cfg_y.y"
> -    { xlu__cfg_set_store(ctx,(yyvsp[(1) - (4)].string),(yyvsp[(3) - (4)].setting),(yylsp[(3) - (4)]).first_line); ;}
> +#line 57 "libxlu_cfg_y.y"
> +    { xlu__cfg_set_store(ctx,(yyvsp[(1) - (3)].string),(yyvsp[(3) - (3)].setting),(yylsp[(3) - (3)]).first_line); ;}
>      break;
>  
> -  case 9:
> +  case 12:
>  
>  /* Line 1455 of yacc.c  */
> -#line 58 "libxlu_cfg_y.y"
> +#line 62 "libxlu_cfg_y.y"
>      { (yyval.setting)= xlu__cfg_set_mk(ctx,1,(yyvsp[(1) - (1)].string)); ;}
>      break;
>  
> -  case 10:
> +  case 13:
>  
>  /* Line 1455 of yacc.c  */
> -#line 59 "libxlu_cfg_y.y"
> +#line 63 "libxlu_cfg_y.y"
>      { (yyval.setting)= (yyvsp[(3) - (4)].setting); ;}
>      break;
>  
> -  case 11:
> +  case 14:
>  
>  /* Line 1455 of yacc.c  */
> -#line 61 "libxlu_cfg_y.y"
> +#line 65 "libxlu_cfg_y.y"
>      { (yyval.string)= (yyvsp[(1) - (1)].string); ;}
>      break;
>  
> -  case 12:
> +  case 15:
>  
>  /* Line 1455 of yacc.c  */
> -#line 62 "libxlu_cfg_y.y"
> +#line 66 "libxlu_cfg_y.y"
>      { (yyval.string)= (yyvsp[(1) - (1)].string); ;}
>      break;
>  
> -  case 13:
> +  case 16:
>  
>  /* Line 1455 of yacc.c  */
> -#line 64 "libxlu_cfg_y.y"
> +#line 68 "libxlu_cfg_y.y"
>      { (yyval.setting)= xlu__cfg_set_mk(ctx,0,0); ;}
>      break;
>  
> -  case 14:
> +  case 17:
>  
>  /* Line 1455 of yacc.c  */
> -#line 65 "libxlu_cfg_y.y"
> +#line 69 "libxlu_cfg_y.y"
>      { (yyval.setting)= (yyvsp[(1) - (1)].setting); ;}
>      break;
>  
> -  case 15:
> +  case 18:
>  
>  /* Line 1455 of yacc.c  */
> -#line 66 "libxlu_cfg_y.y"
> +#line 70 "libxlu_cfg_y.y"
>      { (yyval.setting)= (yyvsp[(1) - (3)].setting); ;}
>      break;
>  
> -  case 16:
> +  case 19:
>  
>  /* Line 1455 of yacc.c  */
> -#line 68 "libxlu_cfg_y.y"
> +#line 72 "libxlu_cfg_y.y"
>      { (yyval.setting)= xlu__cfg_set_mk(ctx,2,(yyvsp[(1) - (2)].string)); ;}
>      break;
>  
> -  case 17:
> +  case 20:
>  
>  /* Line 1455 of yacc.c  */
> -#line 69 "libxlu_cfg_y.y"
> +#line 73 "libxlu_cfg_y.y"
>      { xlu__cfg_set_add(ctx,(yyvsp[(1) - (5)].setting),(yyvsp[(4) - (5)].string)); (yyval.setting)= (yyvsp[(1) - (5)].setting); ;}
>      break;
>  
> 
> 
>  /* Line 1455 of yacc.c  */
> -#line 1536 "libxlu_cfg_y.c"
> +#line 1542 "libxlu_cfg_y.c"
>        default: break;
>      }
>    YY_SYMBOL_PRINT ("-> $$ =", yyr1[yyn], &yyval, &yyloc);
> diff --git a/tools/libxl/libxlu_cfg_y.y b/tools/libxl/libxlu_cfg_y.y
> index 29aedca..aa9f787 100644
> --- a/tools/libxl/libxlu_cfg_y.y
> +++ b/tools/libxl/libxlu_cfg_y.y
> @@ -44,14 +44,18 @@
>  
>  %%
>  
> -file: /* empty */
> - |     file assignment
> +file:  stmts
> + |     stmts assignment
>  
> -assignment: IDENT '=' value endstmt
> -                            { xlu__cfg_set_store(ctx,$1,$3,@3.first_line); }
> +stmts:  /* empty */
> + |      stmts stmt
> +
> +stmt:   assignment endstmt
>   |      endstmt
>   |      error NEWLINE
>  
> +assignment: IDENT '=' value { xlu__cfg_set_store(ctx,$1,$3,@3.first_line); }
> +
>  endstmt: NEWLINE
>   |      ';'
>  



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 11 14:31:44 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 2012 14:31:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TBRUj-0007FC-KW; Tue, 11 Sep 2012 14:31: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 1TBRUh-0007Ew-Ux
	for xen-devel@lists.xen.org; Tue, 11 Sep 2012 14:31:16 +0000
Received: from [85.158.143.99:60260] by server-2.bemta-4.messagelabs.com id
	A6/36-21239-33B4F405; Tue, 11 Sep 2012 14:31:15 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1347373864!26385824!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDg1NjI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28622 invoked from network); 11 Sep 2012 14:31:13 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Sep 2012 14:31:13 -0000
X-IronPort-AV: E=Sophos;i="4.80,405,1344211200"; d="scan'208";a="14473629"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Sep 2012 14:31: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.279.1;
	Tue, 11 Sep 2012 15:31:03 +0100
Message-ID: <1347373862.5305.176.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Tue, 11 Sep 2012 15:31:02 +0100
In-Reply-To: <20559.18783.257111.373451@mariner.uk.xensource.com>
References: <20559.18783.257111.373451@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Jan Beulich <JBeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] libxl: Tolerate xl config files missing
	trailing newline
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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-09-11 at 15:23 +0100, Ian Jackson wrote:
> I wrote:
> > Also I wrote:
> > > However, xl fails on config files which are missing the final
> > > newline.  This should be fixed for 4.2.
> > 
> > My patch for this didn't make it into 4.2 RC4.
> 
> Should this go into 4.2.0 or be held for 4.2.1 (or is it not 4.2.x
> material at all) ?

4.2.1 IMHO, the workaround for 4.2.0 is obvious enough, I think.

BTW, does this correctly handle the way extra args are pinned onto the
end in create in xl (I mean the stuff which comes from the cmdline which
are glommed onto the end of the config file internally).

On a related note Bastian complained a while ago that the line numbers
reported on syntax error were bogus/meaningless (and a little confusing)
for parameters from the command line -- can you think of a way to fix
that (for 4.3 of course). I was thinking along the lines of supporting
and injecting a "#pragma everything-from-here-from-the-command-line",
but maybe you have a better idea, like iterative parsing of multiple
inputs.

> 
> Ian.
> 
> From: Ian Jackson <ian.jackson@eu.citrix.com>
> Subject: [PATCH] libxl: Tolerate xl config files missing trailing newline
> 
> Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
> 
> ---
>  tools/libxl/libxlu_cfg_y.c |  154 +++++++++++++++++++++++---------------------
>  tools/libxl/libxlu_cfg_y.y |   12 ++-
>  2 files changed, 88 insertions(+), 78 deletions(-)
> 
> diff --git a/tools/libxl/libxlu_cfg_y.c b/tools/libxl/libxlu_cfg_y.c
> index 5214386..218933e 100644
> --- a/tools/libxl/libxlu_cfg_y.c
> +++ b/tools/libxl/libxlu_cfg_y.c
> @@ -373,18 +373,18 @@ union yyalloc
>  #endif
>  
>  /* YYFINAL -- State number of the termination state.  */
> -#define YYFINAL  2
> +#define YYFINAL  3
>  /* YYLAST -- Last index in YYTABLE.  */
> -#define YYLAST   23
> +#define YYLAST   24
>  
>  /* YYNTOKENS -- Number of terminals.  */
>  #define YYNTOKENS  12
>  /* YYNNTS -- Number of nonterminals.  */
> -#define YYNNTS  9
> +#define YYNNTS  11
>  /* YYNRULES -- Number of rules.  */
> -#define YYNRULES  19
> +#define YYNRULES  22
>  /* YYNRULES -- Number of states.  */
> -#define YYNSTATES  28
> +#define YYNSTATES  30
>  
>  /* YYTRANSLATE(YYLEX) -- Bison symbol number corresponding to YYLEX.  */
>  #define YYUNDEFTOK  2
> @@ -430,26 +430,28 @@ static const yytype_uint8 yytranslate[] =
>     YYRHS.  */
>  static const yytype_uint8 yyprhs[] =
>  {
> -       0,     0,     3,     4,     7,    12,    14,    17,    19,    21,
> -      23,    28,    30,    32,    33,    35,    39,    42,    48,    49
> +       0,     0,     3,     5,     8,     9,    12,    15,    17,    20,
> +      24,    26,    28,    30,    35,    37,    39,    40,    42,    46,
> +      49,    55,    56
>  };
>  
>  /* YYRHS -- A `-1'-separated list of the rules' RHS.  */
>  static const yytype_int8 yyrhs[] =
>  {
> -      13,     0,    -1,    -1,    13,    14,    -1,     3,     7,    16,
> -      15,    -1,    15,    -1,     1,     6,    -1,     6,    -1,     8,
> -      -1,    17,    -1,     9,    20,    18,    10,    -1,     4,    -1,
> -       5,    -1,    -1,    19,    -1,    19,    11,    20,    -1,    17,
> -      20,    -1,    19,    11,    20,    17,    20,    -1,    -1,    20,
> -       6,    -1
> +      13,     0,    -1,    14,    -1,    14,    16,    -1,    -1,    14,
> +      15,    -1,    16,    17,    -1,    17,    -1,     1,     6,    -1,
> +       3,     7,    18,    -1,     6,    -1,     8,    -1,    19,    -1,
> +       9,    22,    20,    10,    -1,     4,    -1,     5,    -1,    -1,
> +      21,    -1,    21,    11,    22,    -1,    19,    22,    -1,    21,
> +      11,    22,    19,    22,    -1,    -1,    22,     6,    -1
>  };
>  
>  /* YYRLINE[YYN] -- source line where rule number YYN was defined.  */
>  static const yytype_uint8 yyrline[] =
>  {
> -       0,    47,    47,    48,    50,    52,    53,    55,    56,    58,
> -      59,    61,    62,    64,    65,    66,    68,    69,    71,    73
> +       0,    47,    47,    48,    50,    51,    53,    54,    55,    57,
> +      59,    60,    62,    63,    65,    66,    68,    69,    70,    72,
> +      73,    75,    77
>  };
>  #endif
>  
> @@ -459,8 +461,8 @@ static const yytype_uint8 yyrline[] =
>  static const char *const yytname[] =
>  {
>    "$end", "error", "$undefined", "IDENT", "STRING", "NUMBER", "NEWLINE",
> -  "'='", "';'", "'['", "']'", "','", "$accept", "file", "assignment",
> -  "endstmt", "value", "atom", "valuelist", "values", "nlok", 0
> +  "'='", "';'", "'['", "']'", "','", "$accept", "file", "stmts", "stmt",
> +  "assignment", "endstmt", "value", "atom", "valuelist", "values", "nlok", 0
>  };
>  #endif
>  
> @@ -477,15 +479,17 @@ static const yytype_uint16 yytoknum[] =
>  /* YYR1[YYN] -- Symbol number of symbol that rule YYN derives.  */
>  static const yytype_uint8 yyr1[] =
>  {
> -       0,    12,    13,    13,    14,    14,    14,    15,    15,    16,
> -      16,    17,    17,    18,    18,    18,    19,    19,    20,    20
> +       0,    12,    13,    13,    14,    14,    15,    15,    15,    16,
> +      17,    17,    18,    18,    19,    19,    20,    20,    20,    21,
> +      21,    22,    22
>  };
>  
>  /* YYR2[YYN] -- Number of symbols composing right hand side of rule YYN.  */
>  static const yytype_uint8 yyr2[] =
>  {
> -       0,     2,     0,     2,     4,     1,     2,     1,     1,     1,
> -       4,     1,     1,     0,     1,     3,     2,     5,     0,     2
> +       0,     2,     1,     2,     0,     2,     2,     1,     2,     3,
> +       1,     1,     1,     4,     1,     1,     0,     1,     3,     2,
> +       5,     0,     2
>  };
>  
>  /* YYDEFACT[STATE-NAME] -- Default rule to reduce with in state
> @@ -493,59 +497,61 @@ static const yytype_uint8 yyr2[] =
>     means the default is an error.  */
>  static const yytype_uint8 yydefact[] =
>  {
> -       2,     0,     1,     0,     0,     7,     8,     3,     5,     6,
> -       0,    11,    12,    18,     0,     9,    13,     4,    19,    18,
> -       0,    14,    16,    10,    18,    15,    18,    17
> +       4,     0,     0,     1,     0,     0,    10,    11,     5,     3,
> +       7,     8,     0,     6,    14,    15,    21,     9,    12,    16,
> +      22,    21,     0,    17,    19,    13,    21,    18,    21,    20
>  };
>  
>  /* YYDEFGOTO[NTERM-NUM].  */
>  static const yytype_int8 yydefgoto[] =
>  {
> -      -1,     1,     7,     8,    14,    15,    20,    21,    16
> +      -1,     1,     2,     8,     9,    10,    17,    18,    22,    23,
> +      19
>  };
>  
>  /* YYPACT[STATE-NUM] -- Index in YYTABLE of the portion describing
>     STATE-NUM.  */
> -#define YYPACT_NINF -17
> +#define YYPACT_NINF -18
>  static const yytype_int8 yypact[] =
>  {
> -     -17,     2,   -17,    -5,    -3,   -17,   -17,   -17,   -17,   -17,
> -      10,   -17,   -17,   -17,    14,   -17,    12,   -17,   -17,   -17,
> -      11,    -4,     6,   -17,   -17,    12,   -17,     6
> +     -18,     4,     0,   -18,    -1,     6,   -18,   -18,   -18,     3,
> +     -18,   -18,    11,   -18,   -18,   -18,   -18,   -18,   -18,    13,
> +     -18,   -18,    12,    10,    17,   -18,   -18,    13,   -18,    17
>  };
>  
>  /* YYPGOTO[NTERM-NUM].  */
>  static const yytype_int8 yypgoto[] =
>  {
> -     -17,   -17,   -17,     9,   -17,   -16,   -17,   -17,   -13
> +     -18,   -18,   -18,   -18,   -18,    15,   -18,   -17,   -18,   -18,
> +     -14
>  };
>  
>  /* YYTABLE[YYPACT[STATE-NUM]].  What to do in state STATE-NUM.  If
>     positive, shift that token.  If negative, reduce the rule which
>     number is the opposite.  If zero, do what YYDEFACT says.
>     If YYTABLE_NINF, syntax error.  */
> -#define YYTABLE_NINF -1
> -static const yytype_uint8 yytable[] =
> +#define YYTABLE_NINF -3
> +static const yytype_int8 yytable[] =
>  {
> -      19,     9,     2,     3,    10,     4,    22,    24,     5,    26,
> -       6,    25,    18,    27,    11,    12,    11,    12,    18,    13,
> -       5,    23,     6,    17
> +      -2,     4,    21,     5,     3,    11,     6,    24,     7,     6,
> +      28,     7,    27,    12,    29,    14,    15,    14,    15,    20,
> +      16,    26,    25,    20,    13
>  };
>  
>  static const yytype_uint8 yycheck[] =
>  {
> -      16,     6,     0,     1,     7,     3,    19,    11,     6,    25,
> -       8,    24,     6,    26,     4,     5,     4,     5,     6,     9,
> -       6,    10,     8,    14
> +       0,     1,    19,     3,     0,     6,     6,    21,     8,     6,
> +      27,     8,    26,     7,    28,     4,     5,     4,     5,     6,
> +       9,    11,    10,     6,     9
>  };
>  
>  /* YYSTOS[STATE-NUM] -- The (internal number of the) accessing
>     symbol of state STATE-NUM.  */
>  static const yytype_uint8 yystos[] =
>  {
> -       0,    13,     0,     1,     3,     6,     8,    14,    15,     6,
> -       7,     4,     5,     9,    16,    17,    20,    15,     6,    17,
> -      18,    19,    20,    10,    11,    20,    17,    20
> +       0,    13,    14,     0,     1,     3,     6,     8,    15,    16,
> +      17,     6,     7,    17,     4,     5,     9,    18,    19,    22,
> +       6,    19,    20,    21,    22,    10,    11,    22,    19,    22
>  };
>  
>  #define yyerrok		(yyerrstatus = 0)
> @@ -1077,7 +1083,7 @@ yydestruct (yymsg, yytype, yyvaluep, yylocationp, ctx)
>  	{ free((yyvaluep->string)); };
>  
>  /* Line 1000 of yacc.c  */
> -#line 1081 "libxlu_cfg_y.c"
> +#line 1087 "libxlu_cfg_y.c"
>  	break;
>        case 4: /* "STRING" */
>  
> @@ -1086,7 +1092,7 @@ yydestruct (yymsg, yytype, yyvaluep, yylocationp, ctx)
>  	{ free((yyvaluep->string)); };
>  
>  /* Line 1000 of yacc.c  */
> -#line 1090 "libxlu_cfg_y.c"
> +#line 1096 "libxlu_cfg_y.c"
>  	break;
>        case 5: /* "NUMBER" */
>  
> @@ -1095,43 +1101,43 @@ yydestruct (yymsg, yytype, yyvaluep, yylocationp, ctx)
>  	{ free((yyvaluep->string)); };
>  
>  /* Line 1000 of yacc.c  */
> -#line 1099 "libxlu_cfg_y.c"
> +#line 1105 "libxlu_cfg_y.c"
>  	break;
> -      case 16: /* "value" */
> +      case 18: /* "value" */
>  
>  /* Line 1000 of yacc.c  */
>  #line 43 "libxlu_cfg_y.y"
>  	{ xlu__cfg_set_free((yyvaluep->setting)); };
>  
>  /* Line 1000 of yacc.c  */
> -#line 1108 "libxlu_cfg_y.c"
> +#line 1114 "libxlu_cfg_y.c"
>  	break;
> -      case 17: /* "atom" */
> +      case 19: /* "atom" */
>  
>  /* Line 1000 of yacc.c  */
>  #line 40 "libxlu_cfg_y.y"
>  	{ free((yyvaluep->string)); };
>  
>  /* Line 1000 of yacc.c  */
> -#line 1117 "libxlu_cfg_y.c"
> +#line 1123 "libxlu_cfg_y.c"
>  	break;
> -      case 18: /* "valuelist" */
> +      case 20: /* "valuelist" */
>  
>  /* Line 1000 of yacc.c  */
>  #line 43 "libxlu_cfg_y.y"
>  	{ xlu__cfg_set_free((yyvaluep->setting)); };
>  
>  /* Line 1000 of yacc.c  */
> -#line 1126 "libxlu_cfg_y.c"
> +#line 1132 "libxlu_cfg_y.c"
>  	break;
> -      case 19: /* "values" */
> +      case 21: /* "values" */
>  
>  /* Line 1000 of yacc.c  */
>  #line 43 "libxlu_cfg_y.y"
>  	{ xlu__cfg_set_free((yyvaluep->setting)); };
>  
>  /* Line 1000 of yacc.c  */
> -#line 1135 "libxlu_cfg_y.c"
> +#line 1141 "libxlu_cfg_y.c"
>  	break;
>  
>        default:
> @@ -1459,80 +1465,80 @@ yyreduce:
>    YY_REDUCE_PRINT (yyn);
>    switch (yyn)
>      {
> -        case 4:
> +        case 9:
>  
>  /* Line 1455 of yacc.c  */
> -#line 51 "libxlu_cfg_y.y"
> -    { xlu__cfg_set_store(ctx,(yyvsp[(1) - (4)].string),(yyvsp[(3) - (4)].setting),(yylsp[(3) - (4)]).first_line); ;}
> +#line 57 "libxlu_cfg_y.y"
> +    { xlu__cfg_set_store(ctx,(yyvsp[(1) - (3)].string),(yyvsp[(3) - (3)].setting),(yylsp[(3) - (3)]).first_line); ;}
>      break;
>  
> -  case 9:
> +  case 12:
>  
>  /* Line 1455 of yacc.c  */
> -#line 58 "libxlu_cfg_y.y"
> +#line 62 "libxlu_cfg_y.y"
>      { (yyval.setting)= xlu__cfg_set_mk(ctx,1,(yyvsp[(1) - (1)].string)); ;}
>      break;
>  
> -  case 10:
> +  case 13:
>  
>  /* Line 1455 of yacc.c  */
> -#line 59 "libxlu_cfg_y.y"
> +#line 63 "libxlu_cfg_y.y"
>      { (yyval.setting)= (yyvsp[(3) - (4)].setting); ;}
>      break;
>  
> -  case 11:
> +  case 14:
>  
>  /* Line 1455 of yacc.c  */
> -#line 61 "libxlu_cfg_y.y"
> +#line 65 "libxlu_cfg_y.y"
>      { (yyval.string)= (yyvsp[(1) - (1)].string); ;}
>      break;
>  
> -  case 12:
> +  case 15:
>  
>  /* Line 1455 of yacc.c  */
> -#line 62 "libxlu_cfg_y.y"
> +#line 66 "libxlu_cfg_y.y"
>      { (yyval.string)= (yyvsp[(1) - (1)].string); ;}
>      break;
>  
> -  case 13:
> +  case 16:
>  
>  /* Line 1455 of yacc.c  */
> -#line 64 "libxlu_cfg_y.y"
> +#line 68 "libxlu_cfg_y.y"
>      { (yyval.setting)= xlu__cfg_set_mk(ctx,0,0); ;}
>      break;
>  
> -  case 14:
> +  case 17:
>  
>  /* Line 1455 of yacc.c  */
> -#line 65 "libxlu_cfg_y.y"
> +#line 69 "libxlu_cfg_y.y"
>      { (yyval.setting)= (yyvsp[(1) - (1)].setting); ;}
>      break;
>  
> -  case 15:
> +  case 18:
>  
>  /* Line 1455 of yacc.c  */
> -#line 66 "libxlu_cfg_y.y"
> +#line 70 "libxlu_cfg_y.y"
>      { (yyval.setting)= (yyvsp[(1) - (3)].setting); ;}
>      break;
>  
> -  case 16:
> +  case 19:
>  
>  /* Line 1455 of yacc.c  */
> -#line 68 "libxlu_cfg_y.y"
> +#line 72 "libxlu_cfg_y.y"
>      { (yyval.setting)= xlu__cfg_set_mk(ctx,2,(yyvsp[(1) - (2)].string)); ;}
>      break;
>  
> -  case 17:
> +  case 20:
>  
>  /* Line 1455 of yacc.c  */
> -#line 69 "libxlu_cfg_y.y"
> +#line 73 "libxlu_cfg_y.y"
>      { xlu__cfg_set_add(ctx,(yyvsp[(1) - (5)].setting),(yyvsp[(4) - (5)].string)); (yyval.setting)= (yyvsp[(1) - (5)].setting); ;}
>      break;
>  
> 
> 
>  /* Line 1455 of yacc.c  */
> -#line 1536 "libxlu_cfg_y.c"
> +#line 1542 "libxlu_cfg_y.c"
>        default: break;
>      }
>    YY_SYMBOL_PRINT ("-> $$ =", yyr1[yyn], &yyval, &yyloc);
> diff --git a/tools/libxl/libxlu_cfg_y.y b/tools/libxl/libxlu_cfg_y.y
> index 29aedca..aa9f787 100644
> --- a/tools/libxl/libxlu_cfg_y.y
> +++ b/tools/libxl/libxlu_cfg_y.y
> @@ -44,14 +44,18 @@
>  
>  %%
>  
> -file: /* empty */
> - |     file assignment
> +file:  stmts
> + |     stmts assignment
>  
> -assignment: IDENT '=' value endstmt
> -                            { xlu__cfg_set_store(ctx,$1,$3,@3.first_line); }
> +stmts:  /* empty */
> + |      stmts stmt
> +
> +stmt:   assignment endstmt
>   |      endstmt
>   |      error NEWLINE
>  
> +assignment: IDENT '=' value { xlu__cfg_set_store(ctx,$1,$3,@3.first_line); }
> +
>  endstmt: NEWLINE
>   |      ';'
>  



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 11 14:32:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 2012 14:32: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 1TBRUo-0007Fr-1E; Tue, 11 Sep 2012 14:31:22 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1TBRUn-0007Fe-HQ
	for xen-devel@lists.xen.org; Tue, 11 Sep 2012 14:31:21 +0000
Received: from [85.158.143.35:55579] by server-1.bemta-4.messagelabs.com id
	07/29-12504-83B4F405; Tue, 11 Sep 2012 14:31:20 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1347373879!17811809!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQwNzc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2394 invoked from network); 11 Sep 2012 14:31:19 -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;
	11 Sep 2012 14:31:19 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 11 Sep 2012 15:31:19 +0100
Message-Id: <504F6754020000780009AB04@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 11 Sep 2012 15:31:16 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Jackson" <Ian.Jackson@eu.citrix.com>
References: <20559.18783.257111.373451@mariner.uk.xensource.com>
In-Reply-To: <20559.18783.257111.373451@mariner.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] libxl: Tolerate xl config files missing
 trailing newline
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.09.12 at 16:23, Ian Jackson <Ian.Jackson@eu.citrix.com> wrote:
> I wrote:
>> Also I wrote:
>> > However, xl fails on config files which are missing the final
>> > newline.  This should be fixed for 4.2.
>> 
>> My patch for this didn't make it into 4.2 RC4.
> 
> Should this go into 4.2.0 or be held for 4.2.1 (or is it not 4.2.x
> material at all) ?

If you feel good about the change despite its size, then I see
no reason for it to not go in right away, under the compatibility-
with-xend hat.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 11 14:32:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 2012 14:32: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 1TBRUo-0007Fr-1E; Tue, 11 Sep 2012 14:31:22 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1TBRUn-0007Fe-HQ
	for xen-devel@lists.xen.org; Tue, 11 Sep 2012 14:31:21 +0000
Received: from [85.158.143.35:55579] by server-1.bemta-4.messagelabs.com id
	07/29-12504-83B4F405; Tue, 11 Sep 2012 14:31:20 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1347373879!17811809!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQwNzc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2394 invoked from network); 11 Sep 2012 14:31:19 -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;
	11 Sep 2012 14:31:19 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 11 Sep 2012 15:31:19 +0100
Message-Id: <504F6754020000780009AB04@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 11 Sep 2012 15:31:16 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Jackson" <Ian.Jackson@eu.citrix.com>
References: <20559.18783.257111.373451@mariner.uk.xensource.com>
In-Reply-To: <20559.18783.257111.373451@mariner.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] libxl: Tolerate xl config files missing
 trailing newline
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.09.12 at 16:23, Ian Jackson <Ian.Jackson@eu.citrix.com> wrote:
> I wrote:
>> Also I wrote:
>> > However, xl fails on config files which are missing the final
>> > newline.  This should be fixed for 4.2.
>> 
>> My patch for this didn't make it into 4.2 RC4.
> 
> Should this go into 4.2.0 or be held for 4.2.1 (or is it not 4.2.x
> material at all) ?

If you feel good about the change despite its size, then I see
no reason for it to not go in right away, under the compatibility-
with-xend hat.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 11 14:33:43 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 2012 14: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 1TBRWz-0007WO-Iw; Tue, 11 Sep 2012 14:33:37 +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 1TBRWx-0007WE-OX
	for xen-devel@lists.xen.org; Tue, 11 Sep 2012 14:33:35 +0000
Received: from [85.158.138.51:65038] by server-11.bemta-3.messagelabs.com id
	38/96-30250-EBB4F405; Tue, 11 Sep 2012 14:33:34 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-9.tower-174.messagelabs.com!1347374013!28252940!1
X-Originating-IP: [63.239.67.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14950 invoked from network); 11 Sep 2012 14:33:34 -0000
Received: from emvm-gh1-uea09.nsa.gov (HELO nsa.gov) (63.239.67.10)
	by server-9.tower-174.messagelabs.com with SMTP;
	11 Sep 2012 14:33:34 -0000
X-TM-IMSS-Message-ID: <346bad16000f9d0d@nsa.gov>
Received: from tarius.tycho.ncsc.mil ([144.51.3.1]) by nsa.gov
	([63.239.67.10]) with ESMTP (TREND IMSS SMTP Service 7.1) id
	346bad16000f9d0d ; Tue, 11 Sep 2012 10:35:38 -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 q8BEXSCN023174; 
	Tue, 11 Sep 2012 10:33:28 -0400
Message-ID: <504F4BB8.7090601@tycho.nsa.gov>
Date: Tue, 11 Sep 2012 10:33:28 -0400
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Organization: National Security Agency
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120828 Thunderbird/15.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <1347306553-20980-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1347306553-20980-18-git-send-email-dgdegra@tycho.nsa.gov>
	<504F0AA9020000780009A704@nat28.tlf.novell.com>
	<504F3F5B.6070200@tycho.nsa.gov>
	<504F63D8020000780009AAB4@nat28.tlf.novell.com>
In-Reply-To: <504F63D8020000780009AAB4@nat28.tlf.novell.com>
Cc: Tim Deegan <tim@xen.org>, Keir Fraser <keir@xen.org>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 17/20] arch/x86: use XSM hooks for
 get_pg_owner access checks
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 09/11/2012 10:16 AM, Jan Beulich wrote:
>>>> On 11.09.12 at 15:40, Daniel De Graaf <dgdegra@tycho.nsa.gov> wrote:
>> On 09/11/2012 03:55 AM, Jan Beulich wrote:
>>>>>> On 10.09.12 at 21:49, Daniel De Graaf <dgdegra@tycho.nsa.gov> wrote:
>>>> --- a/xen/arch/x86/mm.c
>>>> +++ b/xen/arch/x86/mm.c
>>>> @@ -2882,11 +2882,6 @@ static struct domain *get_pg_owner(domid_t domid)
>>>>          pg_owner = rcu_lock_domain(dom_io);
>>>>          break;
>>>>      case DOMID_XEN:
>>>> -        if ( !IS_PRIV(curr) )
>>>> -        {
>>>> -            MEM_LOG("Cannot set foreign dom");
>>>> -            break;
>>>> -        }
>>>>          pg_owner = rcu_lock_domain(dom_xen);
>>>>          break;
>>>>      default:
>>>> @@ -2895,12 +2890,6 @@ static struct domain *get_pg_owner(domid_t domid)
>>>>              MEM_LOG("Unknown domain '%u'", domid);
>>>>              break;
>>>>          }
>>>> -        if ( !IS_PRIV_FOR(curr, pg_owner) )
>>>> -        {
>>>> -            MEM_LOG("Cannot set foreign dom");
>>>> -            rcu_unlock_domain(pg_owner);
>>>> -            pg_owner = NULL;
>>>> -        }
>>>>          break;
>>>>      }
>>>>  
>>>> @@ -3008,6 +2997,13 @@ long do_mmuext_op(
>>>>          goto out;
>>>>      }
>>>>  
>>>> +    rc = xsm_mmuext_op(d, pg_owner);
>>>> +    if ( rc )
>>>> +    {
>>>> +        rcu_unlock_domain(pg_owner);
>>>> +        goto out;
>>>> +    }
>>>> +
>>>
>>> While this part is fine, ...
>>>
>>>>      for ( i = 0; i < count; i++ )
>>>>      {
>>>>          if ( hypercall_preempt_check() )
>>>> @@ -3483,11 +3479,6 @@ long do_mmu_update(
>>>>              rc = -EINVAL;
>>>>              goto out;
>>>>          }
>>>> -        if ( !IS_PRIV_FOR(d, pt_owner) )
>>>> -        {
>>>> -            rc = -ESRCH;
>>>> -            goto out;
>>>> -        } 
>>>
>>> ... this one isn't (at least in conjunction with them all becoming
>>> indirect calls unconditionally) - you replace a single validation per
>>> set of requests with one validation per request.
>>
>> Is it still a problem if the check is inlined? If so, I could add an
>> additional XSM hook where the old IS_PRIV check was done, and make the
>> check inside the loop an inlined noop in the XSM-disabled case.
> 
> It's not a problem for the inlined case I would say, but I do
> think that performance here matters even if XSM is enabled.
> 
> Jan
> 

That's a problem that should probably be addressed in a different patch,
since the current XSM hook is already implemented as one per request.
This is because it needs access to the page being mapped in order to check
for MMIO mappings. Since those are not the normal case, I think this could
be improved using a lazier hook - or by dropping the per-request XSM check,
because I think it might be re-implementing the existing mmio rangeset
checks, and should just rely on those.

-- 
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 Tue Sep 11 14:33:43 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 2012 14: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 1TBRWz-0007WO-Iw; Tue, 11 Sep 2012 14:33:37 +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 1TBRWx-0007WE-OX
	for xen-devel@lists.xen.org; Tue, 11 Sep 2012 14:33:35 +0000
Received: from [85.158.138.51:65038] by server-11.bemta-3.messagelabs.com id
	38/96-30250-EBB4F405; Tue, 11 Sep 2012 14:33:34 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-9.tower-174.messagelabs.com!1347374013!28252940!1
X-Originating-IP: [63.239.67.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14950 invoked from network); 11 Sep 2012 14:33:34 -0000
Received: from emvm-gh1-uea09.nsa.gov (HELO nsa.gov) (63.239.67.10)
	by server-9.tower-174.messagelabs.com with SMTP;
	11 Sep 2012 14:33:34 -0000
X-TM-IMSS-Message-ID: <346bad16000f9d0d@nsa.gov>
Received: from tarius.tycho.ncsc.mil ([144.51.3.1]) by nsa.gov
	([63.239.67.10]) with ESMTP (TREND IMSS SMTP Service 7.1) id
	346bad16000f9d0d ; Tue, 11 Sep 2012 10:35:38 -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 q8BEXSCN023174; 
	Tue, 11 Sep 2012 10:33:28 -0400
Message-ID: <504F4BB8.7090601@tycho.nsa.gov>
Date: Tue, 11 Sep 2012 10:33:28 -0400
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Organization: National Security Agency
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120828 Thunderbird/15.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <1347306553-20980-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1347306553-20980-18-git-send-email-dgdegra@tycho.nsa.gov>
	<504F0AA9020000780009A704@nat28.tlf.novell.com>
	<504F3F5B.6070200@tycho.nsa.gov>
	<504F63D8020000780009AAB4@nat28.tlf.novell.com>
In-Reply-To: <504F63D8020000780009AAB4@nat28.tlf.novell.com>
Cc: Tim Deegan <tim@xen.org>, Keir Fraser <keir@xen.org>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 17/20] arch/x86: use XSM hooks for
 get_pg_owner access checks
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 09/11/2012 10:16 AM, Jan Beulich wrote:
>>>> On 11.09.12 at 15:40, Daniel De Graaf <dgdegra@tycho.nsa.gov> wrote:
>> On 09/11/2012 03:55 AM, Jan Beulich wrote:
>>>>>> On 10.09.12 at 21:49, Daniel De Graaf <dgdegra@tycho.nsa.gov> wrote:
>>>> --- a/xen/arch/x86/mm.c
>>>> +++ b/xen/arch/x86/mm.c
>>>> @@ -2882,11 +2882,6 @@ static struct domain *get_pg_owner(domid_t domid)
>>>>          pg_owner = rcu_lock_domain(dom_io);
>>>>          break;
>>>>      case DOMID_XEN:
>>>> -        if ( !IS_PRIV(curr) )
>>>> -        {
>>>> -            MEM_LOG("Cannot set foreign dom");
>>>> -            break;
>>>> -        }
>>>>          pg_owner = rcu_lock_domain(dom_xen);
>>>>          break;
>>>>      default:
>>>> @@ -2895,12 +2890,6 @@ static struct domain *get_pg_owner(domid_t domid)
>>>>              MEM_LOG("Unknown domain '%u'", domid);
>>>>              break;
>>>>          }
>>>> -        if ( !IS_PRIV_FOR(curr, pg_owner) )
>>>> -        {
>>>> -            MEM_LOG("Cannot set foreign dom");
>>>> -            rcu_unlock_domain(pg_owner);
>>>> -            pg_owner = NULL;
>>>> -        }
>>>>          break;
>>>>      }
>>>>  
>>>> @@ -3008,6 +2997,13 @@ long do_mmuext_op(
>>>>          goto out;
>>>>      }
>>>>  
>>>> +    rc = xsm_mmuext_op(d, pg_owner);
>>>> +    if ( rc )
>>>> +    {
>>>> +        rcu_unlock_domain(pg_owner);
>>>> +        goto out;
>>>> +    }
>>>> +
>>>
>>> While this part is fine, ...
>>>
>>>>      for ( i = 0; i < count; i++ )
>>>>      {
>>>>          if ( hypercall_preempt_check() )
>>>> @@ -3483,11 +3479,6 @@ long do_mmu_update(
>>>>              rc = -EINVAL;
>>>>              goto out;
>>>>          }
>>>> -        if ( !IS_PRIV_FOR(d, pt_owner) )
>>>> -        {
>>>> -            rc = -ESRCH;
>>>> -            goto out;
>>>> -        } 
>>>
>>> ... this one isn't (at least in conjunction with them all becoming
>>> indirect calls unconditionally) - you replace a single validation per
>>> set of requests with one validation per request.
>>
>> Is it still a problem if the check is inlined? If so, I could add an
>> additional XSM hook where the old IS_PRIV check was done, and make the
>> check inside the loop an inlined noop in the XSM-disabled case.
> 
> It's not a problem for the inlined case I would say, but I do
> think that performance here matters even if XSM is enabled.
> 
> Jan
> 

That's a problem that should probably be addressed in a different patch,
since the current XSM hook is already implemented as one per request.
This is because it needs access to the page being mapped in order to check
for MMIO mappings. Since those are not the normal case, I think this could
be improved using a lazier hook - or by dropping the per-request XSM check,
because I think it might be re-implementing the existing mmio rangeset
checks, and should just rely on those.

-- 
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 Tue Sep 11 14:35:33 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 2012 14:35:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TBRYX-0007pd-7g; Tue, 11 Sep 2012 14:35:13 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1TBRYV-0007ou-L0
	for xen-devel@lists.xen.org; Tue, 11 Sep 2012 14:35:11 +0000
Received: from [85.158.138.51:24429] by server-10.bemta-3.messagelabs.com id
	4E/7D-10411-E1C4F405; Tue, 11 Sep 2012 14:35:10 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1347374105!23595365!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDg1NjI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6224 invoked from network); 11 Sep 2012 14:35: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;
	11 Sep 2012 14:35:07 -0000
X-IronPort-AV: E=Sophos;i="4.80,405,1344211200"; d="scan'208";a="14473779"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Sep 2012 14:35: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.279.1; Tue, 11 Sep 2012 15:35: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
	1TBRYO-0007hk-U1; Tue, 11 Sep 2012 14:35:04 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1TBRYO-0006rX-QK;
	Tue, 11 Sep 2012 15:35:04 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20559.19480.717230.760237@mariner.uk.xensource.com>
Date: Tue, 11 Sep 2012 15:35:04 +0100
To: Olaf Hering <olaf@aepfle.de>
In-Reply-To: <20120907132824.GA18208@aepfle.de>
References: <cc71fe7029b27cb95d26.1346951697@probook.site>
	<1347007260.30018.39.camel@zakaz.uk.xensource.com>
	<20553.52602.892916.502689@mariner.uk.xensource.com>
	<20120907132824.GA18208@aepfle.de>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: [Xen-devel] [PATCH] libxl: Fix missing dependency in api check rule
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Olaf Hering writes ("Re: [Xen-devel] [PATCH] libxl: add missing dependencies of libxl.h"):
> On Fri, Sep 07, Ian Jackson wrote:
> > -_%.api-for-check: %.h
> > +_%.api-for-check: %.h $(filter-out %.api-ok, $(AUTOINCS))
> >  	$(CC) $(CPPFLAGS) $(CFLAGS) $(CFLAGS_$*.o) -c -E $< $(APPEND_CFLAGS) \
> >  		-DLIBXL_EXTERNAL_CALLERS_ONLY=LIBXL_EXTERNAL_CALLERS_ONLY \
> >  		>$@.new
> > 
> > Can you confirm that this fixes it for you ?
> 
> The package builds fine with this change.
> The failure if fixes happend only once.

Hmm.

Adding this:  (WARNING DO NOT APPLY THIS BIT)

diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
index a9d9ec6..5f2332c 100644
--- a/tools/libxl/Makefile
+++ b/tools/libxl/Makefile
@@ -132,6 +132,7 @@ _paths.h: genpath
 
 _libxl_list.h: $(XEN_INCLUDE)/xen-external/bsd-sys-queue-h-seddery $(XEN_INCLUDE)/xen-external/bsd-sys-queue.h
 	$(PERL) $^ --prefix=libxl >$@.new
+	sleep 10
 	$(call move-if-changed,$@.new,$@)
 
 _libxl_save_msgs_helper.c _libxl_save_msgs_callout.c \

allowed me to repro the failure and confirm that my proposed change
fixes it.

So (for -unstable and 4.2), the fix is below.

Ian.


Subject: [PATCH] libxl: Fix missing dependency in api check rule

Without this, the api check cpp run might happen before the various
autogenerated files which are #include by libxl.h are ready.

We need to filter out the api-ok file from AUTOINCS to avoid a
circular dependency.  The result is that the api check is the last
thing to be done before make considers the AUTOINCS all done and can
start work on compiling .c files into .o's.

Reported-by: Olaf Hering <olaf@aepfle.de>
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>

diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
index 5f2332c..c298e97 100644
--- a/tools/libxl/Makefile
+++ b/tools/libxl/Makefile
@@ -119,7 +119,7 @@ libxl.api-ok: check-libxl-api-rules _libxl.api-for-check
 	$(PERL) $^
 	touch $@
 
-_%.api-for-check: %.h
+_%.api-for-check: %.h $(filter-out %.api-ok, $(AUTOINCS))
 	$(CC) $(CPPFLAGS) $(CFLAGS) $(CFLAGS_$*.o) -c -E $< $(APPEND_CFLAGS) \
 		-DLIBXL_EXTERNAL_CALLERS_ONLY=LIBXL_EXTERNAL_CALLERS_ONLY \
 		>$@.new


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 11 14:35:33 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 2012 14:35:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TBRYX-0007pd-7g; Tue, 11 Sep 2012 14:35:13 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1TBRYV-0007ou-L0
	for xen-devel@lists.xen.org; Tue, 11 Sep 2012 14:35:11 +0000
Received: from [85.158.138.51:24429] by server-10.bemta-3.messagelabs.com id
	4E/7D-10411-E1C4F405; Tue, 11 Sep 2012 14:35:10 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1347374105!23595365!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDg1NjI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6224 invoked from network); 11 Sep 2012 14:35: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;
	11 Sep 2012 14:35:07 -0000
X-IronPort-AV: E=Sophos;i="4.80,405,1344211200"; d="scan'208";a="14473779"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Sep 2012 14:35: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.279.1; Tue, 11 Sep 2012 15:35: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
	1TBRYO-0007hk-U1; Tue, 11 Sep 2012 14:35:04 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1TBRYO-0006rX-QK;
	Tue, 11 Sep 2012 15:35:04 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20559.19480.717230.760237@mariner.uk.xensource.com>
Date: Tue, 11 Sep 2012 15:35:04 +0100
To: Olaf Hering <olaf@aepfle.de>
In-Reply-To: <20120907132824.GA18208@aepfle.de>
References: <cc71fe7029b27cb95d26.1346951697@probook.site>
	<1347007260.30018.39.camel@zakaz.uk.xensource.com>
	<20553.52602.892916.502689@mariner.uk.xensource.com>
	<20120907132824.GA18208@aepfle.de>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: [Xen-devel] [PATCH] libxl: Fix missing dependency in api check rule
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Olaf Hering writes ("Re: [Xen-devel] [PATCH] libxl: add missing dependencies of libxl.h"):
> On Fri, Sep 07, Ian Jackson wrote:
> > -_%.api-for-check: %.h
> > +_%.api-for-check: %.h $(filter-out %.api-ok, $(AUTOINCS))
> >  	$(CC) $(CPPFLAGS) $(CFLAGS) $(CFLAGS_$*.o) -c -E $< $(APPEND_CFLAGS) \
> >  		-DLIBXL_EXTERNAL_CALLERS_ONLY=LIBXL_EXTERNAL_CALLERS_ONLY \
> >  		>$@.new
> > 
> > Can you confirm that this fixes it for you ?
> 
> The package builds fine with this change.
> The failure if fixes happend only once.

Hmm.

Adding this:  (WARNING DO NOT APPLY THIS BIT)

diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
index a9d9ec6..5f2332c 100644
--- a/tools/libxl/Makefile
+++ b/tools/libxl/Makefile
@@ -132,6 +132,7 @@ _paths.h: genpath
 
 _libxl_list.h: $(XEN_INCLUDE)/xen-external/bsd-sys-queue-h-seddery $(XEN_INCLUDE)/xen-external/bsd-sys-queue.h
 	$(PERL) $^ --prefix=libxl >$@.new
+	sleep 10
 	$(call move-if-changed,$@.new,$@)
 
 _libxl_save_msgs_helper.c _libxl_save_msgs_callout.c \

allowed me to repro the failure and confirm that my proposed change
fixes it.

So (for -unstable and 4.2), the fix is below.

Ian.


Subject: [PATCH] libxl: Fix missing dependency in api check rule

Without this, the api check cpp run might happen before the various
autogenerated files which are #include by libxl.h are ready.

We need to filter out the api-ok file from AUTOINCS to avoid a
circular dependency.  The result is that the api check is the last
thing to be done before make considers the AUTOINCS all done and can
start work on compiling .c files into .o's.

Reported-by: Olaf Hering <olaf@aepfle.de>
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>

diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
index 5f2332c..c298e97 100644
--- a/tools/libxl/Makefile
+++ b/tools/libxl/Makefile
@@ -119,7 +119,7 @@ libxl.api-ok: check-libxl-api-rules _libxl.api-for-check
 	$(PERL) $^
 	touch $@
 
-_%.api-for-check: %.h
+_%.api-for-check: %.h $(filter-out %.api-ok, $(AUTOINCS))
 	$(CC) $(CPPFLAGS) $(CFLAGS) $(CFLAGS_$*.o) -c -E $< $(APPEND_CFLAGS) \
 		-DLIBXL_EXTERNAL_CALLERS_ONLY=LIBXL_EXTERNAL_CALLERS_ONLY \
 		>$@.new


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 11 14:40:25 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 2012 14:40: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 1TBRcx-00084f-VT; Tue, 11 Sep 2012 14:39: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 1TBRcw-00084V-I7
	for xen-devel@lists.xen.org; Tue, 11 Sep 2012 14:39:46 +0000
Received: from [85.158.138.51:17469] by server-8.bemta-3.messagelabs.com id
	3D/10-24700-F2D4F405; Tue, 11 Sep 2012 14:39:43 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1347374382!25896936!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDg1NjI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15408 invoked from network); 11 Sep 2012 14:39:43 -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;
	11 Sep 2012 14:39:43 -0000
X-IronPort-AV: E=Sophos;i="4.80,405,1344211200"; d="scan'208";a="14473964"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Sep 2012 14:39: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.279.1; Tue, 11 Sep 2012 15:39: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
	1TBRcr-0007j3-7a; Tue, 11 Sep 2012 14:39:41 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1TBRcr-0006s1-3G;
	Tue, 11 Sep 2012 15:39:41 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20559.19756.993187.326445@mariner.uk.xensource.com>
Date: Tue, 11 Sep 2012 15:39:40 +0100
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1347373862.5305.176.camel@zakaz.uk.xensource.com>
References: <20559.18783.257111.373451@mariner.uk.xensource.com>
	<1347373862.5305.176.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@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] libxl: Tolerate xl config files missing
	trailing newline
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("Re: [PATCH] libxl: Tolerate xl config files missing trailing newline"):
> BTW, does this correctly handle the way extra args are pinned onto the
> end in create in xl (I mean the stuff which comes from the cmdline which
> are glommed onto the end of the config file internally).

Yes.  The code there does this:

            config_len += sprintf(config_data + config_len, "\n%s\n",
                            extra_config);

So the actual config file gets a newline appended before the
additional parameters.  If you use this feature then the "Tolerate xl
config files missing trailing newline" patch is not needed.

> On Tue, 2012-09-11 at 15:23 +0100, Ian Jackson wrote:
> > Should this go into 4.2.0 or be held for 4.2.1 (or is it not 4.2.x
> > material at all) ?
> 
> 4.2.1 IMHO, the workaround for 4.2.0 is obvious enough, I think.
> 
Fair enough.

> On a related note Bastian complained a while ago that the line numbers
> reported on syntax error were bogus/meaningless (and a little confusing)
> for parameters from the command line -- can you think of a way to fix
> that (for 4.3 of course). I was thinking along the lines of supporting
> and injecting a "#pragma everything-from-here-from-the-command-line",
> but maybe you have a better idea, like iterative parsing of multiple
> inputs.

Iterative parsing of multiple inputs is the correct answer.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 11 14:40:25 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 2012 14:40: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 1TBRcx-00084f-VT; Tue, 11 Sep 2012 14:39: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 1TBRcw-00084V-I7
	for xen-devel@lists.xen.org; Tue, 11 Sep 2012 14:39:46 +0000
Received: from [85.158.138.51:17469] by server-8.bemta-3.messagelabs.com id
	3D/10-24700-F2D4F405; Tue, 11 Sep 2012 14:39:43 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1347374382!25896936!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDg1NjI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15408 invoked from network); 11 Sep 2012 14:39:43 -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;
	11 Sep 2012 14:39:43 -0000
X-IronPort-AV: E=Sophos;i="4.80,405,1344211200"; d="scan'208";a="14473964"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Sep 2012 14:39: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.279.1; Tue, 11 Sep 2012 15:39: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
	1TBRcr-0007j3-7a; Tue, 11 Sep 2012 14:39:41 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1TBRcr-0006s1-3G;
	Tue, 11 Sep 2012 15:39:41 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20559.19756.993187.326445@mariner.uk.xensource.com>
Date: Tue, 11 Sep 2012 15:39:40 +0100
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1347373862.5305.176.camel@zakaz.uk.xensource.com>
References: <20559.18783.257111.373451@mariner.uk.xensource.com>
	<1347373862.5305.176.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@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] libxl: Tolerate xl config files missing
	trailing newline
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("Re: [PATCH] libxl: Tolerate xl config files missing trailing newline"):
> BTW, does this correctly handle the way extra args are pinned onto the
> end in create in xl (I mean the stuff which comes from the cmdline which
> are glommed onto the end of the config file internally).

Yes.  The code there does this:

            config_len += sprintf(config_data + config_len, "\n%s\n",
                            extra_config);

So the actual config file gets a newline appended before the
additional parameters.  If you use this feature then the "Tolerate xl
config files missing trailing newline" patch is not needed.

> On Tue, 2012-09-11 at 15:23 +0100, Ian Jackson wrote:
> > Should this go into 4.2.0 or be held for 4.2.1 (or is it not 4.2.x
> > material at all) ?
> 
> 4.2.1 IMHO, the workaround for 4.2.0 is obvious enough, I think.
> 
Fair enough.

> On a related note Bastian complained a while ago that the line numbers
> reported on syntax error were bogus/meaningless (and a little confusing)
> for parameters from the command line -- can you think of a way to fix
> that (for 4.3 of course). I was thinking along the lines of supporting
> and injecting a "#pragma everything-from-here-from-the-command-line",
> but maybe you have a better idea, like iterative parsing of multiple
> inputs.

Iterative parsing of multiple inputs is the correct answer.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 11 14:40:29 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 2012 14: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 1TBRdU-00086s-Ch; Tue, 11 Sep 2012 14:40: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 1TBRdT-00086f-6R
	for xen-devel@lists.xen.org; Tue, 11 Sep 2012 14:40:19 +0000
Received: from [85.158.138.51:23228] by server-11.bemta-3.messagelabs.com id
	DC/DA-30250-25D4F405; Tue, 11 Sep 2012 14:40:18 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1347374417!21906374!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDg1NjI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14890 invoked from network); 11 Sep 2012 14:40:17 -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;
	11 Sep 2012 14:40:17 -0000
X-IronPort-AV: E=Sophos;i="4.80,405,1344211200"; d="scan'208";a="14473983"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Sep 2012 14:40: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.279.1;
	Tue, 11 Sep 2012 15:40:16 +0100
Message-ID: <1347374415.5305.178.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Tue, 11 Sep 2012 15:40:15 +0100
In-Reply-To: <20559.19480.717230.760237@mariner.uk.xensource.com>
References: <cc71fe7029b27cb95d26.1346951697@probook.site>
	<1347007260.30018.39.camel@zakaz.uk.xensource.com>
	<20553.52602.892916.502689@mariner.uk.xensource.com>
	<20120907132824.GA18208@aepfle.de>
	<20559.19480.717230.760237@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Olaf Hering <olaf@aepfle.de>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] libxl: Fix missing dependency in api check
	rule
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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-09-11 at 15:35 +0100, Ian Jackson wrote:
> Olaf Hering writes ("Re: [Xen-devel] [PATCH] libxl: add missing dependencies of libxl.h"):
> > On Fri, Sep 07, Ian Jackson wrote:
> > > -_%.api-for-check: %.h
> > > +_%.api-for-check: %.h $(filter-out %.api-ok, $(AUTOINCS))
> > >  	$(CC) $(CPPFLAGS) $(CFLAGS) $(CFLAGS_$*.o) -c -E $< $(APPEND_CFLAGS) \
> > >  		-DLIBXL_EXTERNAL_CALLERS_ONLY=LIBXL_EXTERNAL_CALLERS_ONLY \
> > >  		>$@.new
> > > 
> > > Can you confirm that this fixes it for you ?
> > 
> > The package builds fine with this change.
> > The failure if fixes happend only once.
> 
> Hmm.
> 
> Adding this:  (WARNING DO NOT APPLY THIS BIT)
> 
> diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
> index a9d9ec6..5f2332c 100644
> --- a/tools/libxl/Makefile
> +++ b/tools/libxl/Makefile
> @@ -132,6 +132,7 @@ _paths.h: genpath
>  
>  _libxl_list.h: $(XEN_INCLUDE)/xen-external/bsd-sys-queue-h-seddery $(XEN_INCLUDE)/xen-external/bsd-sys-queue.h
>  	$(PERL) $^ --prefix=libxl >$@.new
> +	sleep 10
>  	$(call move-if-changed,$@.new,$@)
>  
>  _libxl_save_msgs_helper.c _libxl_save_msgs_callout.c \
> 
> allowed me to repro the failure and confirm that my proposed change
> fixes it.
> 
> So (for -unstable and 4.2), the fix is below.
> 
> Ian.
> 
> 
> Subject: [PATCH] libxl: Fix missing dependency in api check rule
> 
> Without this, the api check cpp run might happen before the various
> autogenerated files which are #include by libxl.h are ready.
> 
> We need to filter out the api-ok file from AUTOINCS to avoid a
> circular dependency.  The result is that the api check is the last
> thing to be done before make considers the AUTOINCS all done and can
> start work on compiling .c files into .o's.
> 
> Reported-by: Olaf Hering <olaf@aepfle.de>
> Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>

Acked-by: Ian Campbell <ian.campbell@citrix.com>

I'm ok with this for 4.2.0.

Although I do wonder if this:

> -_%.api-for-check: %.h
> +_%.api-for-check: %.h $(filter-out %.api-ok, $(AUTOINCS))

Indicates that libxl.api-ok doesn't strictly speaking belong in
AUTOINCS.




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 11 14:40:29 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 2012 14: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 1TBRdU-00086s-Ch; Tue, 11 Sep 2012 14:40: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 1TBRdT-00086f-6R
	for xen-devel@lists.xen.org; Tue, 11 Sep 2012 14:40:19 +0000
Received: from [85.158.138.51:23228] by server-11.bemta-3.messagelabs.com id
	DC/DA-30250-25D4F405; Tue, 11 Sep 2012 14:40:18 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1347374417!21906374!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDg1NjI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14890 invoked from network); 11 Sep 2012 14:40:17 -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;
	11 Sep 2012 14:40:17 -0000
X-IronPort-AV: E=Sophos;i="4.80,405,1344211200"; d="scan'208";a="14473983"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Sep 2012 14:40: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.279.1;
	Tue, 11 Sep 2012 15:40:16 +0100
Message-ID: <1347374415.5305.178.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Tue, 11 Sep 2012 15:40:15 +0100
In-Reply-To: <20559.19480.717230.760237@mariner.uk.xensource.com>
References: <cc71fe7029b27cb95d26.1346951697@probook.site>
	<1347007260.30018.39.camel@zakaz.uk.xensource.com>
	<20553.52602.892916.502689@mariner.uk.xensource.com>
	<20120907132824.GA18208@aepfle.de>
	<20559.19480.717230.760237@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Olaf Hering <olaf@aepfle.de>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] libxl: Fix missing dependency in api check
	rule
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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-09-11 at 15:35 +0100, Ian Jackson wrote:
> Olaf Hering writes ("Re: [Xen-devel] [PATCH] libxl: add missing dependencies of libxl.h"):
> > On Fri, Sep 07, Ian Jackson wrote:
> > > -_%.api-for-check: %.h
> > > +_%.api-for-check: %.h $(filter-out %.api-ok, $(AUTOINCS))
> > >  	$(CC) $(CPPFLAGS) $(CFLAGS) $(CFLAGS_$*.o) -c -E $< $(APPEND_CFLAGS) \
> > >  		-DLIBXL_EXTERNAL_CALLERS_ONLY=LIBXL_EXTERNAL_CALLERS_ONLY \
> > >  		>$@.new
> > > 
> > > Can you confirm that this fixes it for you ?
> > 
> > The package builds fine with this change.
> > The failure if fixes happend only once.
> 
> Hmm.
> 
> Adding this:  (WARNING DO NOT APPLY THIS BIT)
> 
> diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
> index a9d9ec6..5f2332c 100644
> --- a/tools/libxl/Makefile
> +++ b/tools/libxl/Makefile
> @@ -132,6 +132,7 @@ _paths.h: genpath
>  
>  _libxl_list.h: $(XEN_INCLUDE)/xen-external/bsd-sys-queue-h-seddery $(XEN_INCLUDE)/xen-external/bsd-sys-queue.h
>  	$(PERL) $^ --prefix=libxl >$@.new
> +	sleep 10
>  	$(call move-if-changed,$@.new,$@)
>  
>  _libxl_save_msgs_helper.c _libxl_save_msgs_callout.c \
> 
> allowed me to repro the failure and confirm that my proposed change
> fixes it.
> 
> So (for -unstable and 4.2), the fix is below.
> 
> Ian.
> 
> 
> Subject: [PATCH] libxl: Fix missing dependency in api check rule
> 
> Without this, the api check cpp run might happen before the various
> autogenerated files which are #include by libxl.h are ready.
> 
> We need to filter out the api-ok file from AUTOINCS to avoid a
> circular dependency.  The result is that the api check is the last
> thing to be done before make considers the AUTOINCS all done and can
> start work on compiling .c files into .o's.
> 
> Reported-by: Olaf Hering <olaf@aepfle.de>
> Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>

Acked-by: Ian Campbell <ian.campbell@citrix.com>

I'm ok with this for 4.2.0.

Although I do wonder if this:

> -_%.api-for-check: %.h
> +_%.api-for-check: %.h $(filter-out %.api-ok, $(AUTOINCS))

Indicates that libxl.api-ok doesn't strictly speaking belong in
AUTOINCS.




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 11 14:50:55 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 2012 14: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 1TBRn8-00009G-4v; Tue, 11 Sep 2012 14:50:18 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1TBRn7-00009A-2V
	for xen-devel@lists.xen.org; Tue, 11 Sep 2012 14:50:17 +0000
Received: from [85.158.143.99:39339] by server-1.bemta-4.messagelabs.com id
	DC/FC-12504-8AF4F405; Tue, 11 Sep 2012 14:50:16 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1347375014!29757596!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQwNzc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2740 invoked from network); 11 Sep 2012 14:50:15 -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;
	11 Sep 2012 14:50:15 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 11 Sep 2012 15:50:13 +0100
Message-Id: <504F6BC4020000780009AB37@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 11 Sep 2012 15:50:12 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Daniel De Graaf" <dgdegra@tycho.nsa.gov>
References: <1347306553-20980-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1347306553-20980-18-git-send-email-dgdegra@tycho.nsa.gov>
	<504F0AA9020000780009A704@nat28.tlf.novell.com>
	<504F3F5B.6070200@tycho.nsa.gov>
	<504F63D8020000780009AAB4@nat28.tlf.novell.com>
	<504F4BB8.7090601@tycho.nsa.gov>
In-Reply-To: <504F4BB8.7090601@tycho.nsa.gov>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Tim Deegan <tim@xen.org>, Keir Fraser <keir@xen.org>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 17/20] arch/x86: use XSM hooks for
 get_pg_owner access checks
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 11.09.12 at 16:33, Daniel De Graaf <dgdegra@tycho.nsa.gov> wrote:
> On 09/11/2012 10:16 AM, Jan Beulich wrote:
>>>>> On 11.09.12 at 15:40, Daniel De Graaf <dgdegra@tycho.nsa.gov> wrote:
>>> On 09/11/2012 03:55 AM, Jan Beulich wrote:
>>>>>>> On 10.09.12 at 21:49, Daniel De Graaf <dgdegra@tycho.nsa.gov> wrote:
>>>>> --- a/xen/arch/x86/mm.c
>>>>> +++ b/xen/arch/x86/mm.c
>>>>> @@ -2882,11 +2882,6 @@ static struct domain *get_pg_owner(domid_t domid)
>>>>>          pg_owner = rcu_lock_domain(dom_io);
>>>>>          break;
>>>>>      case DOMID_XEN:
>>>>> -        if ( !IS_PRIV(curr) )
>>>>> -        {
>>>>> -            MEM_LOG("Cannot set foreign dom");
>>>>> -            break;
>>>>> -        }
>>>>>          pg_owner = rcu_lock_domain(dom_xen);
>>>>>          break;
>>>>>      default:
>>>>> @@ -2895,12 +2890,6 @@ static struct domain *get_pg_owner(domid_t domid)
>>>>>              MEM_LOG("Unknown domain '%u'", domid);
>>>>>              break;
>>>>>          }
>>>>> -        if ( !IS_PRIV_FOR(curr, pg_owner) )
>>>>> -        {
>>>>> -            MEM_LOG("Cannot set foreign dom");
>>>>> -            rcu_unlock_domain(pg_owner);
>>>>> -            pg_owner = NULL;
>>>>> -        }
>>>>>          break;
>>>>>      }
>>>>>  
>>>>> @@ -3008,6 +2997,13 @@ long do_mmuext_op(
>>>>>          goto out;
>>>>>      }
>>>>>  
>>>>> +    rc = xsm_mmuext_op(d, pg_owner);
>>>>> +    if ( rc )
>>>>> +    {
>>>>> +        rcu_unlock_domain(pg_owner);
>>>>> +        goto out;
>>>>> +    }
>>>>> +
>>>>
>>>> While this part is fine, ...
>>>>
>>>>>      for ( i = 0; i < count; i++ )
>>>>>      {
>>>>>          if ( hypercall_preempt_check() )
>>>>> @@ -3483,11 +3479,6 @@ long do_mmu_update(
>>>>>              rc = -EINVAL;
>>>>>              goto out;
>>>>>          }
>>>>> -        if ( !IS_PRIV_FOR(d, pt_owner) )
>>>>> -        {
>>>>> -            rc = -ESRCH;
>>>>> -            goto out;
>>>>> -        } 
>>>>
>>>> ... this one isn't (at least in conjunction with them all becoming
>>>> indirect calls unconditionally) - you replace a single validation per
>>>> set of requests with one validation per request.
>>>
>>> Is it still a problem if the check is inlined? If so, I could add an
>>> additional XSM hook where the old IS_PRIV check was done, and make the
>>> check inside the loop an inlined noop in the XSM-disabled case.
>> 
>> It's not a problem for the inlined case I would say, but I do
>> think that performance here matters even if XSM is enabled.
> 
> That's a problem that should probably be addressed in a different patch,
> since the current XSM hook is already implemented as one per request.

That's true for the pin-page case in do_mmuext_op(), but not
for any other of its sub-ops (particularly not for the TLB
flushing ones, for which I can't even see how XSM denying the
operation could be useful in any way, the more that presently
foreigndom/pg_owner is being ignored for many of these, i.e.
they act locally even if an otherwise valid foreign domain was
specified).

> This is because it needs access to the page being mapped in order to check
> for MMIO mappings. Since those are not the normal case, I think this could
> be improved using a lazier hook - or by dropping the per-request XSM check,
> because I think it might be re-implementing the existing mmio rangeset
> checks, and should just rely on those.

Indeed - if the per-request check makes no sense, then dropping
that one would be the preferred route over the one you took
here. Same for do_mmu_update().

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 11 14:50:55 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 2012 14: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 1TBRn8-00009G-4v; Tue, 11 Sep 2012 14:50:18 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1TBRn7-00009A-2V
	for xen-devel@lists.xen.org; Tue, 11 Sep 2012 14:50:17 +0000
Received: from [85.158.143.99:39339] by server-1.bemta-4.messagelabs.com id
	DC/FC-12504-8AF4F405; Tue, 11 Sep 2012 14:50:16 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1347375014!29757596!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQwNzc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2740 invoked from network); 11 Sep 2012 14:50:15 -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;
	11 Sep 2012 14:50:15 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 11 Sep 2012 15:50:13 +0100
Message-Id: <504F6BC4020000780009AB37@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 11 Sep 2012 15:50:12 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Daniel De Graaf" <dgdegra@tycho.nsa.gov>
References: <1347306553-20980-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1347306553-20980-18-git-send-email-dgdegra@tycho.nsa.gov>
	<504F0AA9020000780009A704@nat28.tlf.novell.com>
	<504F3F5B.6070200@tycho.nsa.gov>
	<504F63D8020000780009AAB4@nat28.tlf.novell.com>
	<504F4BB8.7090601@tycho.nsa.gov>
In-Reply-To: <504F4BB8.7090601@tycho.nsa.gov>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Tim Deegan <tim@xen.org>, Keir Fraser <keir@xen.org>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 17/20] arch/x86: use XSM hooks for
 get_pg_owner access checks
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 11.09.12 at 16:33, Daniel De Graaf <dgdegra@tycho.nsa.gov> wrote:
> On 09/11/2012 10:16 AM, Jan Beulich wrote:
>>>>> On 11.09.12 at 15:40, Daniel De Graaf <dgdegra@tycho.nsa.gov> wrote:
>>> On 09/11/2012 03:55 AM, Jan Beulich wrote:
>>>>>>> On 10.09.12 at 21:49, Daniel De Graaf <dgdegra@tycho.nsa.gov> wrote:
>>>>> --- a/xen/arch/x86/mm.c
>>>>> +++ b/xen/arch/x86/mm.c
>>>>> @@ -2882,11 +2882,6 @@ static struct domain *get_pg_owner(domid_t domid)
>>>>>          pg_owner = rcu_lock_domain(dom_io);
>>>>>          break;
>>>>>      case DOMID_XEN:
>>>>> -        if ( !IS_PRIV(curr) )
>>>>> -        {
>>>>> -            MEM_LOG("Cannot set foreign dom");
>>>>> -            break;
>>>>> -        }
>>>>>          pg_owner = rcu_lock_domain(dom_xen);
>>>>>          break;
>>>>>      default:
>>>>> @@ -2895,12 +2890,6 @@ static struct domain *get_pg_owner(domid_t domid)
>>>>>              MEM_LOG("Unknown domain '%u'", domid);
>>>>>              break;
>>>>>          }
>>>>> -        if ( !IS_PRIV_FOR(curr, pg_owner) )
>>>>> -        {
>>>>> -            MEM_LOG("Cannot set foreign dom");
>>>>> -            rcu_unlock_domain(pg_owner);
>>>>> -            pg_owner = NULL;
>>>>> -        }
>>>>>          break;
>>>>>      }
>>>>>  
>>>>> @@ -3008,6 +2997,13 @@ long do_mmuext_op(
>>>>>          goto out;
>>>>>      }
>>>>>  
>>>>> +    rc = xsm_mmuext_op(d, pg_owner);
>>>>> +    if ( rc )
>>>>> +    {
>>>>> +        rcu_unlock_domain(pg_owner);
>>>>> +        goto out;
>>>>> +    }
>>>>> +
>>>>
>>>> While this part is fine, ...
>>>>
>>>>>      for ( i = 0; i < count; i++ )
>>>>>      {
>>>>>          if ( hypercall_preempt_check() )
>>>>> @@ -3483,11 +3479,6 @@ long do_mmu_update(
>>>>>              rc = -EINVAL;
>>>>>              goto out;
>>>>>          }
>>>>> -        if ( !IS_PRIV_FOR(d, pt_owner) )
>>>>> -        {
>>>>> -            rc = -ESRCH;
>>>>> -            goto out;
>>>>> -        } 
>>>>
>>>> ... this one isn't (at least in conjunction with them all becoming
>>>> indirect calls unconditionally) - you replace a single validation per
>>>> set of requests with one validation per request.
>>>
>>> Is it still a problem if the check is inlined? If so, I could add an
>>> additional XSM hook where the old IS_PRIV check was done, and make the
>>> check inside the loop an inlined noop in the XSM-disabled case.
>> 
>> It's not a problem for the inlined case I would say, but I do
>> think that performance here matters even if XSM is enabled.
> 
> That's a problem that should probably be addressed in a different patch,
> since the current XSM hook is already implemented as one per request.

That's true for the pin-page case in do_mmuext_op(), but not
for any other of its sub-ops (particularly not for the TLB
flushing ones, for which I can't even see how XSM denying the
operation could be useful in any way, the more that presently
foreigndom/pg_owner is being ignored for many of these, i.e.
they act locally even if an otherwise valid foreign domain was
specified).

> This is because it needs access to the page being mapped in order to check
> for MMIO mappings. Since those are not the normal case, I think this could
> be improved using a lazier hook - or by dropping the per-request XSM check,
> because I think it might be re-implementing the existing mmio rangeset
> checks, and should just rely on those.

Indeed - if the per-request check makes no sense, then dropping
that one would be the preferred route over the one you took
here. Same for do_mmu_update().

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 11 15:38:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 2012 15: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 1TBSXP-0000oW-5r; Tue, 11 Sep 2012 15:38:07 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1TBSXN-0000oO-Q4
	for xen-devel@lists.xen.org; Tue, 11 Sep 2012 15:38:05 +0000
Received: from [85.158.143.99:9761] by server-3.bemta-4.messagelabs.com id
	D5/49-08232-DDA5F405; Tue, 11 Sep 2012 15:38:05 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1347377884!22249433!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDg1NjI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8600 invoked from network); 11 Sep 2012 15:38:04 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Sep 2012 15:38:04 -0000
X-IronPort-AV: E=Sophos;i="4.80,405,1344211200"; d="scan'208";a="14475630"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Sep 2012 15:38: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.279.1; Tue, 11 Sep 2012 16:38: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
	1TBSXL-00086f-O1; Tue, 11 Sep 2012 15:38:03 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1TBSXL-0006wU-JF;
	Tue, 11 Sep 2012 16:38:03 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20559.23254.36907.59582@mariner.uk.xensource.com>
Date: Tue, 11 Sep 2012 16:37:58 +0100
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1347374415.5305.178.camel@zakaz.uk.xensource.com>
References: <cc71fe7029b27cb95d26.1346951697@probook.site>
	<1347007260.30018.39.camel@zakaz.uk.xensource.com>
	<20553.52602.892916.502689@mariner.uk.xensource.com>
	<20120907132824.GA18208@aepfle.de>
	<20559.19480.717230.760237@mariner.uk.xensource.com>
	<1347374415.5305.178.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Olaf Hering <olaf@aepfle.de>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] libxl: Fix missing dependency in api check
	rule
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("Re: [PATCH] libxl: Fix missing dependency in api check rule"):
> Although I do wonder if this:
> 
> > -_%.api-for-check: %.h
> > +_%.api-for-check: %.h $(filter-out %.api-ok, $(AUTOINCS))
> 
> Indicates that libxl.api-ok doesn't strictly speaking belong in
> AUTOINCS.

It would be possible to instead write:

-$(LIBXL_OBJS) $(LIBXLU_OBJS) $(XL_OBJS) $(SAVE_HELPER_OBJS): $(AUTOINCS)
+$(LIBXL_OBJS) $(LIBXLU_OBJS) $(XL_OBJS) $(SAVE_HELPER_OBJS): $(AUTOINCS) libxl.api-ok

If you'd prefer that I'd be happy to test that it actually works.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 11 15:38:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 2012 15: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 1TBSXP-0000oW-5r; Tue, 11 Sep 2012 15:38:07 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1TBSXN-0000oO-Q4
	for xen-devel@lists.xen.org; Tue, 11 Sep 2012 15:38:05 +0000
Received: from [85.158.143.99:9761] by server-3.bemta-4.messagelabs.com id
	D5/49-08232-DDA5F405; Tue, 11 Sep 2012 15:38:05 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1347377884!22249433!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDg1NjI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8600 invoked from network); 11 Sep 2012 15:38:04 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Sep 2012 15:38:04 -0000
X-IronPort-AV: E=Sophos;i="4.80,405,1344211200"; d="scan'208";a="14475630"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Sep 2012 15:38: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.279.1; Tue, 11 Sep 2012 16:38: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
	1TBSXL-00086f-O1; Tue, 11 Sep 2012 15:38:03 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1TBSXL-0006wU-JF;
	Tue, 11 Sep 2012 16:38:03 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20559.23254.36907.59582@mariner.uk.xensource.com>
Date: Tue, 11 Sep 2012 16:37:58 +0100
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1347374415.5305.178.camel@zakaz.uk.xensource.com>
References: <cc71fe7029b27cb95d26.1346951697@probook.site>
	<1347007260.30018.39.camel@zakaz.uk.xensource.com>
	<20553.52602.892916.502689@mariner.uk.xensource.com>
	<20120907132824.GA18208@aepfle.de>
	<20559.19480.717230.760237@mariner.uk.xensource.com>
	<1347374415.5305.178.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Olaf Hering <olaf@aepfle.de>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] libxl: Fix missing dependency in api check
	rule
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("Re: [PATCH] libxl: Fix missing dependency in api check rule"):
> Although I do wonder if this:
> 
> > -_%.api-for-check: %.h
> > +_%.api-for-check: %.h $(filter-out %.api-ok, $(AUTOINCS))
> 
> Indicates that libxl.api-ok doesn't strictly speaking belong in
> AUTOINCS.

It would be possible to instead write:

-$(LIBXL_OBJS) $(LIBXLU_OBJS) $(XL_OBJS) $(SAVE_HELPER_OBJS): $(AUTOINCS)
+$(LIBXL_OBJS) $(LIBXLU_OBJS) $(XL_OBJS) $(SAVE_HELPER_OBJS): $(AUTOINCS) libxl.api-ok

If you'd prefer that I'd be happy to test that it actually works.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 11 16:04:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 2012 16:04:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TBSw6-0001cb-Dz; Tue, 11 Sep 2012 16:03:38 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1TBSw4-0001cV-Q4
	for xen-devel@lists.xen.org; Tue, 11 Sep 2012 16:03:37 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1347379407!9165733!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDg1NjI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31579 invoked from network); 11 Sep 2012 16:03: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;
	11 Sep 2012 16:03:28 -0000
X-IronPort-AV: E=Sophos;i="4.80,406,1344211200"; d="scan'208";a="14476321"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Sep 2012 16:03: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.279.1; Tue, 11 Sep 2012 17:03:27 +0100
Date: Tue, 11 Sep 2012 17:02:47 +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: <20120905140600.GA5844@phenom.dumpdata.com>
Message-ID: <alpine.DEB.2.02.1209111652590.15568@kaball.uk.xensource.com>
References: <1136369816.20120904183757@eikelenboom.it>
	<20120904163347.GH23361@phenom.dumpdata.com>
	<143844933.20120904191941@eikelenboom.it>
	<CAOvdn6U_yHgtZwv9MWazdLbd3NLq3pwGXnZY5sL2UVBhV_FUoQ@mail.gmail.com>
	<1813712325.20120904213459@eikelenboom.it>
	<048EAD622912254A9DEA24C1734613C18C864C3C5D@FTLPMAILBOX02.citrite.net>
	<20120905140600.GA5844@phenom.dumpdata.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: Sander Eikelenboom <linux@eikelenboom.it>,
	Robert Phillips <robert.phillips@citrix.com>, Ben Guthro <ben@guthro.net>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] dom0 linux 3.6.0-rc4,
 crash due to ballooning althoug dom0_mem=X, max:X set
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 5 Sep 2012, Konrad Rzeszutek Wilk wrote:
> On Tue, Sep 04, 2012 at 04:27:20PM -0400, Robert Phillips wrote:
> > Ben,
> > 
> > You have asked me to provide the rationale behind the gnttab_old_mfn patch, which you emailed to Sander earlier today. 
> > Here are my findings.
> > 
> > I found that xen_blkbk_map() in drivers/block/xen-blkback/blkback.c has changed from our previous version.  It now calls gnttab_map_refs() in drivers/xen/grant-table.c.
> > 
> > That function first calls HYPERVISOR_grant_table_op(GNTTABOP_map_grant_ref, ... ) and then calls m2p_add_override() in p2m.c
> 
> And HYPERVISOR_grant_table_op .. would populate map_ops[i].bus_addr with the machine address..
> 
> > which is where I made my change.
> > 
> > The unpatched code was saving the pfn's old mfn in kmap_op->dev_bus_addr.  
> > 
> > kmap_op is of type struct gnttab_map_grant_ref.  That data type is used to record grant table mappings so later they can be unmapped correctly.
> 
> Right, but the blkback makes a distinction by passing NULL as kmap_op, which means it should
> use the old mechanism. Meaning that once the hypercall is done, the map_ops[i].bus_addr is not
> used anymore..
> 
> > 
> > The problem with saving the old mfn in kmap_op->dev_bus_addr is that it is later overwritten by __gnttab_map_grant_ref() in xen/common/grant_table.c
> 
> Uh, so the problem of saving the old mfn in dev_bus_addr has been there for a long long time then?
> Even before this patch set?

I think that Robert identified the real problem: dev_bus_addr shouldn't
have been used here. However the bug only shows up if we are batching
the grant table operations, that we started doing since
f62805f1f30a40e354bd036b4cb799863a39be4b.
That's why Sander's bisection found that
f62805f1f30a40e354bd036b4cb799863a39be4b is the culprit.

However the fix is incorrect because it is modifying a struct that is
part of the Xen ABI.
I am appending an alternative fix that doesn't need any changes to
public headers.

Sander, could you please let me know if it fixes the problem for you?

---


diff --git a/arch/x86/include/asm/xen/page.h b/arch/x86/include/asm/xen/page.h
index 93971e8..472b9b7 100644
--- a/arch/x86/include/asm/xen/page.h
+++ b/arch/x86/include/asm/xen/page.h
@@ -51,7 +51,8 @@ extern unsigned long set_phys_range_identity(unsigned long pfn_s,
 
 extern int m2p_add_override(unsigned long mfn, struct page *page,
 			    struct gnttab_map_grant_ref *kmap_op);
-extern int m2p_remove_override(struct page *page, bool clear_pte);
+extern int m2p_remove_override(struct page *page,
+				struct gnttab_map_grant_ref *kmap_op);
 extern struct page *m2p_find_override(unsigned long mfn);
 extern unsigned long m2p_find_override_pfn(unsigned long mfn, unsigned long pfn);
 
diff --git a/arch/x86/xen/p2m.c b/arch/x86/xen/p2m.c
index 64effdc..2825594 100644
--- a/arch/x86/xen/p2m.c
+++ b/arch/x86/xen/p2m.c
@@ -734,9 +734,6 @@ int m2p_add_override(unsigned long mfn, struct page *page,
 
 			xen_mc_issue(PARAVIRT_LAZY_MMU);
 		}
-		/* let's use dev_bus_addr to record the old mfn instead */
-		kmap_op->dev_bus_addr = page->index;
-		page->index = (unsigned long) kmap_op;
 	}
 	spin_lock_irqsave(&m2p_override_lock, flags);
 	list_add(&page->lru,  &m2p_overrides[mfn_hash(mfn)]);
@@ -763,7 +760,8 @@ int m2p_add_override(unsigned long mfn, struct page *page,
 	return 0;
 }
 EXPORT_SYMBOL_GPL(m2p_add_override);
-int m2p_remove_override(struct page *page, bool clear_pte)
+int m2p_remove_override(struct page *page,
+		struct gnttab_map_grant_ref *kmap_op)
 {
 	unsigned long flags;
 	unsigned long mfn;
@@ -793,10 +791,8 @@ int m2p_remove_override(struct page *page, bool clear_pte)
 	WARN_ON(!PagePrivate(page));
 	ClearPagePrivate(page);
 
-	if (clear_pte) {
-		struct gnttab_map_grant_ref *map_op =
-			(struct gnttab_map_grant_ref *) page->index;
-		set_phys_to_machine(pfn, map_op->dev_bus_addr);
+	set_phys_to_machine(pfn, page->index);
+	if (kmap_op != NULL) {
 		if (!PageHighMem(page)) {
 			struct multicall_space mcs;
 			struct gnttab_unmap_grant_ref *unmap_op;
@@ -808,13 +804,13 @@ int m2p_remove_override(struct page *page, bool clear_pte)
 			 * issued. In this case handle is going to -1 because
 			 * it hasn't been modified yet.
 			 */
-			if (map_op->handle == -1)
+			if (kmap_op->handle == -1)
 				xen_mc_flush();
 			/*
-			 * Now if map_op->handle is negative it means that the
+			 * Now if kmap_op->handle is negative it means that the
 			 * hypercall actually returned an error.
 			 */
-			if (map_op->handle == GNTST_general_error) {
+			if (kmap_op->handle == GNTST_general_error) {
 				printk(KERN_WARNING "m2p_remove_override: "
 						"pfn %lx mfn %lx, failed to modify kernel mappings",
 						pfn, mfn);
@@ -824,8 +820,8 @@ int m2p_remove_override(struct page *page, bool clear_pte)
 			mcs = xen_mc_entry(
 					sizeof(struct gnttab_unmap_grant_ref));
 			unmap_op = mcs.args;
-			unmap_op->host_addr = map_op->host_addr;
-			unmap_op->handle = map_op->handle;
+			unmap_op->host_addr = kmap_op->host_addr;
+			unmap_op->handle = kmap_op->handle;
 			unmap_op->dev_bus_addr = 0;
 
 			MULTI_grant_table_op(mcs.mc,
@@ -836,10 +832,9 @@ int m2p_remove_override(struct page *page, bool clear_pte)
 			set_pte_at(&init_mm, address, ptep,
 					pfn_pte(pfn, PAGE_KERNEL));
 			__flush_tlb_single(address);
-			map_op->host_addr = 0;
+			kmap_op->host_addr = 0;
 		}
-	} 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
diff --git a/drivers/block/xen-blkback/blkback.c b/drivers/block/xen-blkback/blkback.c
index 73f196c..c6decb9 100644
--- a/drivers/block/xen-blkback/blkback.c
+++ b/drivers/block/xen-blkback/blkback.c
@@ -337,7 +337,7 @@ static void xen_blkbk_unmap(struct pending_req *req)
 		invcount++;
 	}
 
-	ret = gnttab_unmap_refs(unmap, pages, invcount, false);
+	ret = gnttab_unmap_refs(unmap, NULL, pages, invcount);
 	BUG_ON(ret);
 }
 
diff --git a/drivers/xen/gntdev.c b/drivers/xen/gntdev.c
index 1ffd03b..7f12416 100644
--- a/drivers/xen/gntdev.c
+++ b/drivers/xen/gntdev.c
@@ -314,8 +314,9 @@ static int __unmap_grant_pages(struct grant_map *map, int offset, int pages)
 		}
 	}
 
-	err = gnttab_unmap_refs(map->unmap_ops + offset, map->pages + offset,
-				pages, true);
+	err = gnttab_unmap_refs(map->unmap_ops + offset,
+			use_ptemod ? map->kmap_ops + offset : NULL, map->pages + offset,
+			pages);
 	if (err)
 		return err;
 
diff --git a/drivers/xen/grant-table.c b/drivers/xen/grant-table.c
index 0bfc1ef..0067266 100644
--- a/drivers/xen/grant-table.c
+++ b/drivers/xen/grant-table.c
@@ -870,7 +870,8 @@ int gnttab_map_refs(struct gnttab_map_grant_ref *map_ops,
 EXPORT_SYMBOL_GPL(gnttab_map_refs);
 
 int gnttab_unmap_refs(struct gnttab_unmap_grant_ref *unmap_ops,
-		      struct page **pages, unsigned int count, bool clear_pte)
+		      struct gnttab_map_grant_ref *kmap_ops,
+		      struct page **pages, unsigned int count)
 {
 	int i, ret;
 	bool lazy = false;
@@ -888,7 +889,8 @@ int gnttab_unmap_refs(struct gnttab_unmap_grant_ref *unmap_ops,
 	}
 
 	for (i = 0; i < count; i++) {
-		ret = m2p_remove_override(pages[i], clear_pte);
+		ret = m2p_remove_override(pages[i], kmap_ops ?
+				       &kmap_ops[i] : NULL);
 		if (ret)
 			return ret;
 	}
diff --git a/include/xen/grant_table.h b/include/xen/grant_table.h
index 11e27c3..f19fff8 100644
--- a/include/xen/grant_table.h
+++ b/include/xen/grant_table.h
@@ -187,6 +187,7 @@ int gnttab_map_refs(struct gnttab_map_grant_ref *map_ops,
 		    struct gnttab_map_grant_ref *kmap_ops,
 		    struct page **pages, unsigned int count);
 int gnttab_unmap_refs(struct gnttab_unmap_grant_ref *unmap_ops,
-		      struct page **pages, unsigned int count, bool clear_pte);
+		      struct gnttab_map_grant_ref *kunmap_ops,
+		      struct page **pages, unsigned int count);
 
 #endif /* __ASM_GNTTAB_H__ */

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 11 16:04:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 2012 16:04:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TBSw6-0001cb-Dz; Tue, 11 Sep 2012 16:03:38 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1TBSw4-0001cV-Q4
	for xen-devel@lists.xen.org; Tue, 11 Sep 2012 16:03:37 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1347379407!9165733!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDg1NjI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31579 invoked from network); 11 Sep 2012 16:03: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;
	11 Sep 2012 16:03:28 -0000
X-IronPort-AV: E=Sophos;i="4.80,406,1344211200"; d="scan'208";a="14476321"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Sep 2012 16:03: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.279.1; Tue, 11 Sep 2012 17:03:27 +0100
Date: Tue, 11 Sep 2012 17:02:47 +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: <20120905140600.GA5844@phenom.dumpdata.com>
Message-ID: <alpine.DEB.2.02.1209111652590.15568@kaball.uk.xensource.com>
References: <1136369816.20120904183757@eikelenboom.it>
	<20120904163347.GH23361@phenom.dumpdata.com>
	<143844933.20120904191941@eikelenboom.it>
	<CAOvdn6U_yHgtZwv9MWazdLbd3NLq3pwGXnZY5sL2UVBhV_FUoQ@mail.gmail.com>
	<1813712325.20120904213459@eikelenboom.it>
	<048EAD622912254A9DEA24C1734613C18C864C3C5D@FTLPMAILBOX02.citrite.net>
	<20120905140600.GA5844@phenom.dumpdata.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: Sander Eikelenboom <linux@eikelenboom.it>,
	Robert Phillips <robert.phillips@citrix.com>, Ben Guthro <ben@guthro.net>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] dom0 linux 3.6.0-rc4,
 crash due to ballooning althoug dom0_mem=X, max:X set
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 5 Sep 2012, Konrad Rzeszutek Wilk wrote:
> On Tue, Sep 04, 2012 at 04:27:20PM -0400, Robert Phillips wrote:
> > Ben,
> > 
> > You have asked me to provide the rationale behind the gnttab_old_mfn patch, which you emailed to Sander earlier today. 
> > Here are my findings.
> > 
> > I found that xen_blkbk_map() in drivers/block/xen-blkback/blkback.c has changed from our previous version.  It now calls gnttab_map_refs() in drivers/xen/grant-table.c.
> > 
> > That function first calls HYPERVISOR_grant_table_op(GNTTABOP_map_grant_ref, ... ) and then calls m2p_add_override() in p2m.c
> 
> And HYPERVISOR_grant_table_op .. would populate map_ops[i].bus_addr with the machine address..
> 
> > which is where I made my change.
> > 
> > The unpatched code was saving the pfn's old mfn in kmap_op->dev_bus_addr.  
> > 
> > kmap_op is of type struct gnttab_map_grant_ref.  That data type is used to record grant table mappings so later they can be unmapped correctly.
> 
> Right, but the blkback makes a distinction by passing NULL as kmap_op, which means it should
> use the old mechanism. Meaning that once the hypercall is done, the map_ops[i].bus_addr is not
> used anymore..
> 
> > 
> > The problem with saving the old mfn in kmap_op->dev_bus_addr is that it is later overwritten by __gnttab_map_grant_ref() in xen/common/grant_table.c
> 
> Uh, so the problem of saving the old mfn in dev_bus_addr has been there for a long long time then?
> Even before this patch set?

I think that Robert identified the real problem: dev_bus_addr shouldn't
have been used here. However the bug only shows up if we are batching
the grant table operations, that we started doing since
f62805f1f30a40e354bd036b4cb799863a39be4b.
That's why Sander's bisection found that
f62805f1f30a40e354bd036b4cb799863a39be4b is the culprit.

However the fix is incorrect because it is modifying a struct that is
part of the Xen ABI.
I am appending an alternative fix that doesn't need any changes to
public headers.

Sander, could you please let me know if it fixes the problem for you?

---


diff --git a/arch/x86/include/asm/xen/page.h b/arch/x86/include/asm/xen/page.h
index 93971e8..472b9b7 100644
--- a/arch/x86/include/asm/xen/page.h
+++ b/arch/x86/include/asm/xen/page.h
@@ -51,7 +51,8 @@ extern unsigned long set_phys_range_identity(unsigned long pfn_s,
 
 extern int m2p_add_override(unsigned long mfn, struct page *page,
 			    struct gnttab_map_grant_ref *kmap_op);
-extern int m2p_remove_override(struct page *page, bool clear_pte);
+extern int m2p_remove_override(struct page *page,
+				struct gnttab_map_grant_ref *kmap_op);
 extern struct page *m2p_find_override(unsigned long mfn);
 extern unsigned long m2p_find_override_pfn(unsigned long mfn, unsigned long pfn);
 
diff --git a/arch/x86/xen/p2m.c b/arch/x86/xen/p2m.c
index 64effdc..2825594 100644
--- a/arch/x86/xen/p2m.c
+++ b/arch/x86/xen/p2m.c
@@ -734,9 +734,6 @@ int m2p_add_override(unsigned long mfn, struct page *page,
 
 			xen_mc_issue(PARAVIRT_LAZY_MMU);
 		}
-		/* let's use dev_bus_addr to record the old mfn instead */
-		kmap_op->dev_bus_addr = page->index;
-		page->index = (unsigned long) kmap_op;
 	}
 	spin_lock_irqsave(&m2p_override_lock, flags);
 	list_add(&page->lru,  &m2p_overrides[mfn_hash(mfn)]);
@@ -763,7 +760,8 @@ int m2p_add_override(unsigned long mfn, struct page *page,
 	return 0;
 }
 EXPORT_SYMBOL_GPL(m2p_add_override);
-int m2p_remove_override(struct page *page, bool clear_pte)
+int m2p_remove_override(struct page *page,
+		struct gnttab_map_grant_ref *kmap_op)
 {
 	unsigned long flags;
 	unsigned long mfn;
@@ -793,10 +791,8 @@ int m2p_remove_override(struct page *page, bool clear_pte)
 	WARN_ON(!PagePrivate(page));
 	ClearPagePrivate(page);
 
-	if (clear_pte) {
-		struct gnttab_map_grant_ref *map_op =
-			(struct gnttab_map_grant_ref *) page->index;
-		set_phys_to_machine(pfn, map_op->dev_bus_addr);
+	set_phys_to_machine(pfn, page->index);
+	if (kmap_op != NULL) {
 		if (!PageHighMem(page)) {
 			struct multicall_space mcs;
 			struct gnttab_unmap_grant_ref *unmap_op;
@@ -808,13 +804,13 @@ int m2p_remove_override(struct page *page, bool clear_pte)
 			 * issued. In this case handle is going to -1 because
 			 * it hasn't been modified yet.
 			 */
-			if (map_op->handle == -1)
+			if (kmap_op->handle == -1)
 				xen_mc_flush();
 			/*
-			 * Now if map_op->handle is negative it means that the
+			 * Now if kmap_op->handle is negative it means that the
 			 * hypercall actually returned an error.
 			 */
-			if (map_op->handle == GNTST_general_error) {
+			if (kmap_op->handle == GNTST_general_error) {
 				printk(KERN_WARNING "m2p_remove_override: "
 						"pfn %lx mfn %lx, failed to modify kernel mappings",
 						pfn, mfn);
@@ -824,8 +820,8 @@ int m2p_remove_override(struct page *page, bool clear_pte)
 			mcs = xen_mc_entry(
 					sizeof(struct gnttab_unmap_grant_ref));
 			unmap_op = mcs.args;
-			unmap_op->host_addr = map_op->host_addr;
-			unmap_op->handle = map_op->handle;
+			unmap_op->host_addr = kmap_op->host_addr;
+			unmap_op->handle = kmap_op->handle;
 			unmap_op->dev_bus_addr = 0;
 
 			MULTI_grant_table_op(mcs.mc,
@@ -836,10 +832,9 @@ int m2p_remove_override(struct page *page, bool clear_pte)
 			set_pte_at(&init_mm, address, ptep,
 					pfn_pte(pfn, PAGE_KERNEL));
 			__flush_tlb_single(address);
-			map_op->host_addr = 0;
+			kmap_op->host_addr = 0;
 		}
-	} 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
diff --git a/drivers/block/xen-blkback/blkback.c b/drivers/block/xen-blkback/blkback.c
index 73f196c..c6decb9 100644
--- a/drivers/block/xen-blkback/blkback.c
+++ b/drivers/block/xen-blkback/blkback.c
@@ -337,7 +337,7 @@ static void xen_blkbk_unmap(struct pending_req *req)
 		invcount++;
 	}
 
-	ret = gnttab_unmap_refs(unmap, pages, invcount, false);
+	ret = gnttab_unmap_refs(unmap, NULL, pages, invcount);
 	BUG_ON(ret);
 }
 
diff --git a/drivers/xen/gntdev.c b/drivers/xen/gntdev.c
index 1ffd03b..7f12416 100644
--- a/drivers/xen/gntdev.c
+++ b/drivers/xen/gntdev.c
@@ -314,8 +314,9 @@ static int __unmap_grant_pages(struct grant_map *map, int offset, int pages)
 		}
 	}
 
-	err = gnttab_unmap_refs(map->unmap_ops + offset, map->pages + offset,
-				pages, true);
+	err = gnttab_unmap_refs(map->unmap_ops + offset,
+			use_ptemod ? map->kmap_ops + offset : NULL, map->pages + offset,
+			pages);
 	if (err)
 		return err;
 
diff --git a/drivers/xen/grant-table.c b/drivers/xen/grant-table.c
index 0bfc1ef..0067266 100644
--- a/drivers/xen/grant-table.c
+++ b/drivers/xen/grant-table.c
@@ -870,7 +870,8 @@ int gnttab_map_refs(struct gnttab_map_grant_ref *map_ops,
 EXPORT_SYMBOL_GPL(gnttab_map_refs);
 
 int gnttab_unmap_refs(struct gnttab_unmap_grant_ref *unmap_ops,
-		      struct page **pages, unsigned int count, bool clear_pte)
+		      struct gnttab_map_grant_ref *kmap_ops,
+		      struct page **pages, unsigned int count)
 {
 	int i, ret;
 	bool lazy = false;
@@ -888,7 +889,8 @@ int gnttab_unmap_refs(struct gnttab_unmap_grant_ref *unmap_ops,
 	}
 
 	for (i = 0; i < count; i++) {
-		ret = m2p_remove_override(pages[i], clear_pte);
+		ret = m2p_remove_override(pages[i], kmap_ops ?
+				       &kmap_ops[i] : NULL);
 		if (ret)
 			return ret;
 	}
diff --git a/include/xen/grant_table.h b/include/xen/grant_table.h
index 11e27c3..f19fff8 100644
--- a/include/xen/grant_table.h
+++ b/include/xen/grant_table.h
@@ -187,6 +187,7 @@ int gnttab_map_refs(struct gnttab_map_grant_ref *map_ops,
 		    struct gnttab_map_grant_ref *kmap_ops,
 		    struct page **pages, unsigned int count);
 int gnttab_unmap_refs(struct gnttab_unmap_grant_ref *unmap_ops,
-		      struct page **pages, unsigned int count, bool clear_pte);
+		      struct gnttab_map_grant_ref *kunmap_ops,
+		      struct page **pages, unsigned int count);
 
 #endif /* __ASM_GNTTAB_H__ */

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 11 16:09:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 2012 16: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 1TBT0d-0001o1-9v; Tue, 11 Sep 2012 16:08:19 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1TBT0b-0001nv-To
	for xen-devel@lists.xen.org; Tue, 11 Sep 2012 16:08:18 +0000
Received: from [85.158.138.51:50591] by server-5.bemta-3.messagelabs.com id
	E2/AA-13133-1F16F405; Tue, 11 Sep 2012 16:08:17 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1347379696!29954410!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDg1NjI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21862 invoked from network); 11 Sep 2012 16:08:16 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Sep 2012 16:08:16 -0000
X-IronPort-AV: E=Sophos;i="4.80,406,1344211200"; d="scan'208";a="14476450"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Sep 2012 16:08: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.279.1;
	Tue, 11 Sep 2012 17:08:15 +0100
Message-ID: <1347379694.5305.179.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Tue, 11 Sep 2012 17:08:14 +0100
In-Reply-To: <20559.23254.36907.59582@mariner.uk.xensource.com>
References: <cc71fe7029b27cb95d26.1346951697@probook.site>
	<1347007260.30018.39.camel@zakaz.uk.xensource.com>
	<20553.52602.892916.502689@mariner.uk.xensource.com>
	<20120907132824.GA18208@aepfle.de>
	<20559.19480.717230.760237@mariner.uk.xensource.com>
	<1347374415.5305.178.camel@zakaz.uk.xensource.com>
	<20559.23254.36907.59582@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Olaf Hering <olaf@aepfle.de>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] libxl: Fix missing dependency in api check
	rule
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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-09-11 at 16:37 +0100, Ian Jackson wrote:
> Ian Campbell writes ("Re: [PATCH] libxl: Fix missing dependency in api check rule"):
> > Although I do wonder if this:
> > 
> > > -_%.api-for-check: %.h
> > > +_%.api-for-check: %.h $(filter-out %.api-ok, $(AUTOINCS))
> > 
> > Indicates that libxl.api-ok doesn't strictly speaking belong in
> > AUTOINCS.
> 
> It would be possible to instead write:
> 
> -$(LIBXL_OBJS) $(LIBXLU_OBJS) $(XL_OBJS) $(SAVE_HELPER_OBJS): $(AUTOINCS)
> +$(LIBXL_OBJS) $(LIBXLU_OBJS) $(XL_OBJS) $(SAVE_HELPER_OBJS): $(AUTOINCS) libxl.api-ok
> 
> If you'd prefer that I'd be happy to test that it actually works.

Please do.

Perhaps $(APICHECKS) ? Up to you.

> 
> Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 11 16:09:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 2012 16: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 1TBT0d-0001o1-9v; Tue, 11 Sep 2012 16:08:19 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1TBT0b-0001nv-To
	for xen-devel@lists.xen.org; Tue, 11 Sep 2012 16:08:18 +0000
Received: from [85.158.138.51:50591] by server-5.bemta-3.messagelabs.com id
	E2/AA-13133-1F16F405; Tue, 11 Sep 2012 16:08:17 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1347379696!29954410!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDg1NjI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21862 invoked from network); 11 Sep 2012 16:08:16 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Sep 2012 16:08:16 -0000
X-IronPort-AV: E=Sophos;i="4.80,406,1344211200"; d="scan'208";a="14476450"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Sep 2012 16:08: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.279.1;
	Tue, 11 Sep 2012 17:08:15 +0100
Message-ID: <1347379694.5305.179.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Tue, 11 Sep 2012 17:08:14 +0100
In-Reply-To: <20559.23254.36907.59582@mariner.uk.xensource.com>
References: <cc71fe7029b27cb95d26.1346951697@probook.site>
	<1347007260.30018.39.camel@zakaz.uk.xensource.com>
	<20553.52602.892916.502689@mariner.uk.xensource.com>
	<20120907132824.GA18208@aepfle.de>
	<20559.19480.717230.760237@mariner.uk.xensource.com>
	<1347374415.5305.178.camel@zakaz.uk.xensource.com>
	<20559.23254.36907.59582@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Olaf Hering <olaf@aepfle.de>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] libxl: Fix missing dependency in api check
	rule
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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-09-11 at 16:37 +0100, Ian Jackson wrote:
> Ian Campbell writes ("Re: [PATCH] libxl: Fix missing dependency in api check rule"):
> > Although I do wonder if this:
> > 
> > > -_%.api-for-check: %.h
> > > +_%.api-for-check: %.h $(filter-out %.api-ok, $(AUTOINCS))
> > 
> > Indicates that libxl.api-ok doesn't strictly speaking belong in
> > AUTOINCS.
> 
> It would be possible to instead write:
> 
> -$(LIBXL_OBJS) $(LIBXLU_OBJS) $(XL_OBJS) $(SAVE_HELPER_OBJS): $(AUTOINCS)
> +$(LIBXL_OBJS) $(LIBXLU_OBJS) $(XL_OBJS) $(SAVE_HELPER_OBJS): $(AUTOINCS) libxl.api-ok
> 
> If you'd prefer that I'd be happy to test that it actually works.

Please do.

Perhaps $(APICHECKS) ? Up to you.

> 
> Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 11 16:12:11 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 2012 16:12:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TBT3v-0001wj-UC; Tue, 11 Sep 2012 16:11: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 1TBT3u-0001wS-LC
	for xen-devel@lists.xen.org; Tue, 11 Sep 2012 16:11:42 +0000
Received: from [85.158.139.83:21291] by server-3.bemta-5.messagelabs.com id
	2A/C2-21836-BB26F405; Tue, 11 Sep 2012 16:11:39 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1347379898!29877772!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDg1NjI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10205 invoked from network); 11 Sep 2012 16:11:38 -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 Sep 2012 16:11:38 -0000
X-IronPort-AV: E=Sophos;i="4.80,406,1344211200"; d="scan'208";a="14476527"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Sep 2012 16: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.279.1; Tue, 11 Sep 2012 17:10: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
	1TBT2v-0008Iu-AG; Tue, 11 Sep 2012 16:10:41 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1TBT2v-0006zu-6J;
	Tue, 11 Sep 2012 17:10:41 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20559.25217.65214.189461@mariner.uk.xensource.com>
Date: Tue, 11 Sep 2012 17:10:41 +0100
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1347379694.5305.179.camel@zakaz.uk.xensource.com>
References: <cc71fe7029b27cb95d26.1346951697@probook.site>
	<1347007260.30018.39.camel@zakaz.uk.xensource.com>
	<20553.52602.892916.502689@mariner.uk.xensource.com>
	<20120907132824.GA18208@aepfle.de>
	<20559.19480.717230.760237@mariner.uk.xensource.com>
	<1347374415.5305.178.camel@zakaz.uk.xensource.com>
	<20559.23254.36907.59582@mariner.uk.xensource.com>
	<1347379694.5305.179.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Olaf Hering <olaf@aepfle.de>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] libxl: Fix missing dependency in api check
	rule
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("Re: [PATCH] libxl: Fix missing dependency in api check rule"):
> On Tue, 2012-09-11 at 16:37 +0100, Ian Jackson wrote:
> > If you'd prefer that I'd be happy to test that it actually works.
> 
> Please do.
> 
> Perhaps $(APICHECKS) ? Up to you.

I think given it's just the one right now it will do to just have the
filename :-).

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 11 16:12:11 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 2012 16:12:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TBT3v-0001wj-UC; Tue, 11 Sep 2012 16:11: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 1TBT3u-0001wS-LC
	for xen-devel@lists.xen.org; Tue, 11 Sep 2012 16:11:42 +0000
Received: from [85.158.139.83:21291] by server-3.bemta-5.messagelabs.com id
	2A/C2-21836-BB26F405; Tue, 11 Sep 2012 16:11:39 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1347379898!29877772!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDg1NjI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10205 invoked from network); 11 Sep 2012 16:11:38 -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 Sep 2012 16:11:38 -0000
X-IronPort-AV: E=Sophos;i="4.80,406,1344211200"; d="scan'208";a="14476527"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Sep 2012 16: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.279.1; Tue, 11 Sep 2012 17:10: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
	1TBT2v-0008Iu-AG; Tue, 11 Sep 2012 16:10:41 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1TBT2v-0006zu-6J;
	Tue, 11 Sep 2012 17:10:41 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20559.25217.65214.189461@mariner.uk.xensource.com>
Date: Tue, 11 Sep 2012 17:10:41 +0100
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1347379694.5305.179.camel@zakaz.uk.xensource.com>
References: <cc71fe7029b27cb95d26.1346951697@probook.site>
	<1347007260.30018.39.camel@zakaz.uk.xensource.com>
	<20553.52602.892916.502689@mariner.uk.xensource.com>
	<20120907132824.GA18208@aepfle.de>
	<20559.19480.717230.760237@mariner.uk.xensource.com>
	<1347374415.5305.178.camel@zakaz.uk.xensource.com>
	<20559.23254.36907.59582@mariner.uk.xensource.com>
	<1347379694.5305.179.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Olaf Hering <olaf@aepfle.de>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] libxl: Fix missing dependency in api check
	rule
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("Re: [PATCH] libxl: Fix missing dependency in api check rule"):
> On Tue, 2012-09-11 at 16:37 +0100, Ian Jackson wrote:
> > If you'd prefer that I'd be happy to test that it actually works.
> 
> Please do.
> 
> Perhaps $(APICHECKS) ? Up to you.

I think given it's just the one right now it will do to just have the
filename :-).

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 11 17:14:45 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 2012 17: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 1TBU1g-0002M0-PI; Tue, 11 Sep 2012 17:13:28 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1TBU1e-0002Lv-E8
	for xen-devel@lists.xen.org; Tue, 11 Sep 2012 17:13:26 +0000
Received: from [85.158.138.51:25083] by server-11.bemta-3.messagelabs.com id
	90/CA-30250-5317F405; Tue, 11 Sep 2012 17:13:25 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1347383604!29882726!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDg1NjI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25700 invoked from network); 11 Sep 2012 17:13:24 -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;
	11 Sep 2012 17:13:24 -0000
X-IronPort-AV: E=Sophos;i="4.80,406,1344211200"; d="scan'208";a="14477457"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Sep 2012 17:13:23 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Tue, 11 Sep 2012 18:13:23 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1TBU1a-0000Je-TD; Tue, 11 Sep 2012 17:13:22 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1TBU1a-00008D-PG;
	Tue, 11 Sep 2012 18:13:22 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20559.28978.688776.985508@mariner.uk.xensource.com>
Date: Tue, 11 Sep 2012 18:13:22 +0100
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: Olaf Hering <olaf@aepfle.de>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: [Xen-devel] [PATCH v2] libxl: Fix missing dependency in api check
	rule
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Without this, the api check cpp run might happen before the various
autogenerated files which are #include by libxl.h are ready.

We need to remove the api-ok file from AUTOINCS to avoid a circular
dependency.  Instead, we list it explicitly as a dependency of the
object files.  The result is that the api check is the last thing to
be done before make considers the preparation done and can start work
on compiling .c files into .o's.

Reported-by: Olaf Hering <olaf@aepfle.de>
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>

---
v2: Remove .api-ok from AUTOINCS instead of using $(filter-out...)

 tools/libxl/Makefile |    8 ++++----
 1 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
index a9d9ec6..0986901 100644
--- a/tools/libxl/Makefile
+++ b/tools/libxl/Makefile
@@ -74,8 +74,7 @@ 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.api-ok
+	_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 \
@@ -102,7 +101,8 @@ testidl.c: libxl_types.idl gentest.py libxl.h $(AUTOINCS)
 all: $(CLIENTS) libxenlight.so libxenlight.a libxlutil.so libxlutil.a \
 	$(AUTOSRCS) $(AUTOINCS)
 
-$(LIBXL_OBJS) $(LIBXLU_OBJS) $(XL_OBJS) $(SAVE_HELPER_OBJS): $(AUTOINCS)
+$(LIBXL_OBJS) $(LIBXLU_OBJS) $(XL_OBJS) $(SAVE_HELPER_OBJS): \
+	$(AUTOINCS) libxl.api-ok
 
 %.c %.h:: %.y
 	@rm -f $*.[ch]
@@ -119,7 +119,7 @@ libxl.api-ok: check-libxl-api-rules _libxl.api-for-check
 	$(PERL) $^
 	touch $@
 
-_%.api-for-check: %.h
+_%.api-for-check: %.h $(AUTOINCS)
 	$(CC) $(CPPFLAGS) $(CFLAGS) $(CFLAGS_$*.o) -c -E $< $(APPEND_CFLAGS) \
 		-DLIBXL_EXTERNAL_CALLERS_ONLY=LIBXL_EXTERNAL_CALLERS_ONLY \
 		>$@.new
-- 
tg: (0730dd5..) t/xen/xl.make-api-depend-fix (depends on: base)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 11 17:14:45 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 2012 17: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 1TBU1g-0002M0-PI; Tue, 11 Sep 2012 17:13:28 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1TBU1e-0002Lv-E8
	for xen-devel@lists.xen.org; Tue, 11 Sep 2012 17:13:26 +0000
Received: from [85.158.138.51:25083] by server-11.bemta-3.messagelabs.com id
	90/CA-30250-5317F405; Tue, 11 Sep 2012 17:13:25 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1347383604!29882726!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDg1NjI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25700 invoked from network); 11 Sep 2012 17:13:24 -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;
	11 Sep 2012 17:13:24 -0000
X-IronPort-AV: E=Sophos;i="4.80,406,1344211200"; d="scan'208";a="14477457"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Sep 2012 17:13:23 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Tue, 11 Sep 2012 18:13:23 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1TBU1a-0000Je-TD; Tue, 11 Sep 2012 17:13:22 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1TBU1a-00008D-PG;
	Tue, 11 Sep 2012 18:13:22 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20559.28978.688776.985508@mariner.uk.xensource.com>
Date: Tue, 11 Sep 2012 18:13:22 +0100
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: Olaf Hering <olaf@aepfle.de>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: [Xen-devel] [PATCH v2] libxl: Fix missing dependency in api check
	rule
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Without this, the api check cpp run might happen before the various
autogenerated files which are #include by libxl.h are ready.

We need to remove the api-ok file from AUTOINCS to avoid a circular
dependency.  Instead, we list it explicitly as a dependency of the
object files.  The result is that the api check is the last thing to
be done before make considers the preparation done and can start work
on compiling .c files into .o's.

Reported-by: Olaf Hering <olaf@aepfle.de>
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>

---
v2: Remove .api-ok from AUTOINCS instead of using $(filter-out...)

 tools/libxl/Makefile |    8 ++++----
 1 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
index a9d9ec6..0986901 100644
--- a/tools/libxl/Makefile
+++ b/tools/libxl/Makefile
@@ -74,8 +74,7 @@ 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.api-ok
+	_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 \
@@ -102,7 +101,8 @@ testidl.c: libxl_types.idl gentest.py libxl.h $(AUTOINCS)
 all: $(CLIENTS) libxenlight.so libxenlight.a libxlutil.so libxlutil.a \
 	$(AUTOSRCS) $(AUTOINCS)
 
-$(LIBXL_OBJS) $(LIBXLU_OBJS) $(XL_OBJS) $(SAVE_HELPER_OBJS): $(AUTOINCS)
+$(LIBXL_OBJS) $(LIBXLU_OBJS) $(XL_OBJS) $(SAVE_HELPER_OBJS): \
+	$(AUTOINCS) libxl.api-ok
 
 %.c %.h:: %.y
 	@rm -f $*.[ch]
@@ -119,7 +119,7 @@ libxl.api-ok: check-libxl-api-rules _libxl.api-for-check
 	$(PERL) $^
 	touch $@
 
-_%.api-for-check: %.h
+_%.api-for-check: %.h $(AUTOINCS)
 	$(CC) $(CPPFLAGS) $(CFLAGS) $(CFLAGS_$*.o) -c -E $< $(APPEND_CFLAGS) \
 		-DLIBXL_EXTERNAL_CALLERS_ONLY=LIBXL_EXTERNAL_CALLERS_ONLY \
 		>$@.new
-- 
tg: (0730dd5..) t/xen/xl.make-api-depend-fix (depends on: base)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 11 17:27:23 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 2012 17: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 1TBUEU-0002XO-7E; Tue, 11 Sep 2012 17:26:42 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <john.stultz@linaro.org>) id 1TBUET-0002XJ-0M
	for xen-devel@lists.xensource.com; Tue, 11 Sep 2012 17:26:41 +0000
Received: from [85.158.139.83:7840] by server-5.bemta-5.messagelabs.com id
	42/4E-30514-0547F405; Tue, 11 Sep 2012 17:26:40 +0000
X-Env-Sender: john.stultz@linaro.org
X-Msg-Ref: server-2.tower-182.messagelabs.com!1347384398!29890055!1
X-Originating-IP: [32.97.182.137]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMzIuOTcuMTgyLjEzNyA9PiAzOTY5MTk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21033 invoked from network); 11 Sep 2012 17:26:39 -0000
Received: from e7.ny.us.ibm.com (HELO e7.ny.us.ibm.com) (32.97.182.137)
	by server-2.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 11 Sep 2012 17:26:39 -0000
Received: from /spool/local
	by e7.ny.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only!
	Violators will be prosecuted
	for <xen-devel@lists.xensource.com> from <john.stultz@linaro.org>;
	Tue, 11 Sep 2012 13:26:38 -0400
Received: from d01dlp01.pok.ibm.com (9.56.250.166)
	by e7.ny.us.ibm.com (192.168.1.107) with IBM ESMTP SMTP Gateway:
	Authorized Use Only! Violators will be prosecuted; 
	Tue, 11 Sep 2012 13:26:36 -0400
Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236])
	by d01dlp01.pok.ibm.com (Postfix) with ESMTP id 3F1CA38C8070
	for <xen-devel@lists.xensource.com>;
	Tue, 11 Sep 2012 13:26:35 -0400 (EDT)
Received: from d03av04.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170])
	by d01relay04.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id
	q8BHQWLo176574
	for <xen-devel@lists.xensource.com>; Tue, 11 Sep 2012 13:26:34 -0400
Received: from d03av04.boulder.ibm.com (loopback [127.0.0.1])
	by d03av04.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP
	id q8BHQDYJ007545
	for <xen-devel@lists.xensource.com>; Tue, 11 Sep 2012 11:26:14 -0600
Received: from [9.65.242.108] (sig-9-65-242-108.mts.ibm.com [9.65.242.108])
	by d03av04.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id
	q8BHQ9k2006609; Tue, 11 Sep 2012 11:26:10 -0600
Message-ID: <504F742D.6000701@linaro.org>
Date: Tue, 11 Sep 2012 10:26:05 -0700
From: John Stultz <john.stultz@linaro.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120827 Thunderbird/15.0
MIME-Version: 1.0
To: Daniel Lezcano <daniel.lezcano@linaro.org>
References: <1343164349-28550-1-git-send-email-daniel.lezcano@linaro.org>
	<201209062204.11288.rjw@sisk.pl> <50490920.9070204@linaro.org>
	<201209062318.42874.rjw@sisk.pl> <504A02BD.4000805@linaro.org>
	<504A2D73.3010702@linaro.org> <504A68A0.7010907@linaro.org>
	<504E1FE5.6090502@linaro.org> <504E4343.5070004@linaro.org>
	<504E8372.20904@linaro.org> <504EE124.3010401@linaro.org>
In-Reply-To: <504EE124.3010401@linaro.org>
X-Content-Scanned: Fidelis XPS MAILER
x-cbid: 12091117-5806-0000-0000-0000197BD068
Cc: prarit@redhat.com, xen-devel@lists.xensource.com,
	linaro-dev@lists.linaro.org, Peter Zijlstra <a.p.zijlstra@chello.nl>,
	linux-pm@vger.kernel.org, Frederic Weisbecker <fweisbec@gmail.com>,
	richardcochran@gmail.com, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	"Rafael J. Wysocki" <rjw@sisk.pl>, linux-acpi@vger.kernel.org,
	Thomas Gleixner <tglx@linutronix.de>, mingo@kernel.org, lenb@kernel.org
Subject: Re: [Xen-devel] CONFIG_NO_HZ + CONFIG_CPU_IDLE freeze the system
 (Was Re: [PATCH] acpi : remove power from acpi_processor_cx structure)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 09/10/2012 11:58 PM, Daniel Lezcano wrote:
>> Would you mind testing the following patch? It seems to resolve the
>> issue, but I've not yet run it through my test suite to make sure it
>> didn't break anything else.
> No problem, I will try it this evening.
>
> Is this problem related to all 32bits arch ?
I believe so. Although it didn't appear in my 32bit testing w/ kvm, but 
I suspect that is due to my distro userland setting lots of timers so 
that we don't hit those multi-second idle times, which could overflow 
32bit nanoseconds, or maybe some other kvm quirk.

Anyway, let me know if your testing goes well.

Thanks so much again for noticing and bisecting this down.
-john


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 11 17:27:23 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 2012 17: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 1TBUEU-0002XO-7E; Tue, 11 Sep 2012 17:26:42 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <john.stultz@linaro.org>) id 1TBUET-0002XJ-0M
	for xen-devel@lists.xensource.com; Tue, 11 Sep 2012 17:26:41 +0000
Received: from [85.158.139.83:7840] by server-5.bemta-5.messagelabs.com id
	42/4E-30514-0547F405; Tue, 11 Sep 2012 17:26:40 +0000
X-Env-Sender: john.stultz@linaro.org
X-Msg-Ref: server-2.tower-182.messagelabs.com!1347384398!29890055!1
X-Originating-IP: [32.97.182.137]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMzIuOTcuMTgyLjEzNyA9PiAzOTY5MTk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21033 invoked from network); 11 Sep 2012 17:26:39 -0000
Received: from e7.ny.us.ibm.com (HELO e7.ny.us.ibm.com) (32.97.182.137)
	by server-2.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 11 Sep 2012 17:26:39 -0000
Received: from /spool/local
	by e7.ny.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only!
	Violators will be prosecuted
	for <xen-devel@lists.xensource.com> from <john.stultz@linaro.org>;
	Tue, 11 Sep 2012 13:26:38 -0400
Received: from d01dlp01.pok.ibm.com (9.56.250.166)
	by e7.ny.us.ibm.com (192.168.1.107) with IBM ESMTP SMTP Gateway:
	Authorized Use Only! Violators will be prosecuted; 
	Tue, 11 Sep 2012 13:26:36 -0400
Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236])
	by d01dlp01.pok.ibm.com (Postfix) with ESMTP id 3F1CA38C8070
	for <xen-devel@lists.xensource.com>;
	Tue, 11 Sep 2012 13:26:35 -0400 (EDT)
Received: from d03av04.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170])
	by d01relay04.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id
	q8BHQWLo176574
	for <xen-devel@lists.xensource.com>; Tue, 11 Sep 2012 13:26:34 -0400
Received: from d03av04.boulder.ibm.com (loopback [127.0.0.1])
	by d03av04.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP
	id q8BHQDYJ007545
	for <xen-devel@lists.xensource.com>; Tue, 11 Sep 2012 11:26:14 -0600
Received: from [9.65.242.108] (sig-9-65-242-108.mts.ibm.com [9.65.242.108])
	by d03av04.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id
	q8BHQ9k2006609; Tue, 11 Sep 2012 11:26:10 -0600
Message-ID: <504F742D.6000701@linaro.org>
Date: Tue, 11 Sep 2012 10:26:05 -0700
From: John Stultz <john.stultz@linaro.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120827 Thunderbird/15.0
MIME-Version: 1.0
To: Daniel Lezcano <daniel.lezcano@linaro.org>
References: <1343164349-28550-1-git-send-email-daniel.lezcano@linaro.org>
	<201209062204.11288.rjw@sisk.pl> <50490920.9070204@linaro.org>
	<201209062318.42874.rjw@sisk.pl> <504A02BD.4000805@linaro.org>
	<504A2D73.3010702@linaro.org> <504A68A0.7010907@linaro.org>
	<504E1FE5.6090502@linaro.org> <504E4343.5070004@linaro.org>
	<504E8372.20904@linaro.org> <504EE124.3010401@linaro.org>
In-Reply-To: <504EE124.3010401@linaro.org>
X-Content-Scanned: Fidelis XPS MAILER
x-cbid: 12091117-5806-0000-0000-0000197BD068
Cc: prarit@redhat.com, xen-devel@lists.xensource.com,
	linaro-dev@lists.linaro.org, Peter Zijlstra <a.p.zijlstra@chello.nl>,
	linux-pm@vger.kernel.org, Frederic Weisbecker <fweisbec@gmail.com>,
	richardcochran@gmail.com, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	"Rafael J. Wysocki" <rjw@sisk.pl>, linux-acpi@vger.kernel.org,
	Thomas Gleixner <tglx@linutronix.de>, mingo@kernel.org, lenb@kernel.org
Subject: Re: [Xen-devel] CONFIG_NO_HZ + CONFIG_CPU_IDLE freeze the system
 (Was Re: [PATCH] acpi : remove power from acpi_processor_cx structure)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 09/10/2012 11:58 PM, Daniel Lezcano wrote:
>> Would you mind testing the following patch? It seems to resolve the
>> issue, but I've not yet run it through my test suite to make sure it
>> didn't break anything else.
> No problem, I will try it this evening.
>
> Is this problem related to all 32bits arch ?
I believe so. Although it didn't appear in my 32bit testing w/ kvm, but 
I suspect that is due to my distro userland setting lots of timers so 
that we don't hit those multi-second idle times, which could overflow 
32bit nanoseconds, or maybe some other kvm quirk.

Anyway, let me know if your testing goes well.

Thanks so much again for noticing and bisecting this down.
-john


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 11 17:29:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 2012 17:29:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TBUGW-0002cG-Ok; Tue, 11 Sep 2012 17:28: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 1TBUGU-0002c4-Pm
	for xen-devel@lists.xensource.com; Tue, 11 Sep 2012 17:28:47 +0000
Received: from [85.158.143.35:5813] by server-2.bemta-4.messagelabs.com id
	AF/54-21239-EC47F405; Tue, 11 Sep 2012 17:28:46 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1347384522!6791667!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDg1NjI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29606 invoked from network); 11 Sep 2012 17:28:42 -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;
	11 Sep 2012 17:28:42 -0000
X-IronPort-AV: E=Sophos;i="4.80,406,1344211200"; d="scan'208";a="14477664"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Sep 2012 17:28: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.279.1; Tue, 11 Sep 2012 18:28: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 1TBUGB-0000PE-Np;
	Tue, 11 Sep 2012 17:28:27 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1TBUGB-0003pM-8E;
	Tue, 11 Sep 2012 18:28:27 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-13677-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Tue, 11 Sep 2012 18:28:27 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13677: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 13677 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13677/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-rhel6hvm-amd  8 guest-stop                fail REGR. vs. 13668
 test-amd64-i386-qemuu-rhel6hvm-amd  8 guest-stop          fail REGR. vs. 13668
 test-amd64-i386-qemuu-rhel6hvm-intel  8 guest-stop        fail REGR. vs. 13668
 test-amd64-i386-rhel6hvm-intel  8 guest-stop              fail REGR. vs. 13668

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore            fail   like 13668
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail like 13668
 test-i386-i386-xl-qemuu-winxpsp3  9 guest-localmigrate         fail like 13668
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail like 13668

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-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
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass

version targeted for testing:
 xen                  0a9a4549e6b9
baseline version:
 xen                  7d770de90b7f

------------------------------------------------------------
People who touched revisions under test:
  Boris Ostrovsky <boris.ostrovsky@amd.com>
  Ian Campbell <ian.campbell@citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Keir Fraser <keir@xen.org>
  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                                 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.

------------------------------------------------------------
changeset:   25844:0a9a4549e6b9
tag:         tip
user:        Boris Ostrovsky <boris.ostrovsky@amd.com>
date:        Tue Sep 11 10:57:36 2012 +0200
    
    powernow: Update P-state directly when _PSD's CoordType is DOMAIN_COORD_TYPE_HW_ALL
    
    When _PSD's CoordType is DOMAIN_COORD_TYPE_HW_ALL (i.e. shared_type is
    CPUFREQ_SHARED_TYPE_HW) which most often is the case on servers, there
    is no reason to go into on_selected_cpus() code, we call call
    transition_pstate() directly.
    
    Signed-off-by: Boris Ostrovsky <boris.ostrovsky@amd.com>
    Committed-by: Jan Beulich <jbeulich@suse.com>
    
    
changeset:   25843:51090fe1ab97
user:        Jan Beulich <jbeulich@suse.com>
date:        Tue Sep 11 10:00:06 2012 +0200
    
    x86/HVM: assorted RTC emulation adjustments
    
    - don't look at RTC_PIE in rtc_timer_update(), and hence don't call the
      function on REG_B writes at all
    - only call alarm_timer_update() on REG_B writes when relevant bits
      change
    - only call check_update_timer() on REG_B writes when SET changes
    - instead properly handle AF and PF when the guest is not also setting
      AIE/PIE respectively (for UF this was already the case, only a
      comment was slightly inaccurate)
    - raise the RTC IRQ not only when UIE gets set while UF was already
      set, but generalize this to cover AIE and PIE as well
    - properly mask off bit 7 when retrieving the hour values in
      alarm_timer_update(), and properly use RTC_HOURS_ALARM's bit 7 when
      converting from 12- to 24-hour value
    - also handle the two other possible clock bases
    - use RTC_* names in a couple of places where literal numbers were used
      so far
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   25842:a1f73e989c24
user:        Jan Beulich <jbeulich@suse.com>
date:        Mon Sep 10 16:47:31 2012 +0200
    
    x86/hvm: don't give vector callback higher priority than NMI/MCE
    
    Those two should always be delivered first imo.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
    
    
changeset:   25841:7d770de90b7f
user:        Jan Beulich <JBeulich@suse.com>
date:        Mon Sep 10 11:13:56 2012 +0100
    
    docs: document "ucode=" hypervisor command line option
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Ian Campbell <ian.campbell@citrix.com>
    Committed-by: Ian Campbell <ian.campbell@citrix.com>
    
    
(qemu changes not included)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 11 17:29:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 2012 17:29:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TBUGW-0002cG-Ok; Tue, 11 Sep 2012 17:28: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 1TBUGU-0002c4-Pm
	for xen-devel@lists.xensource.com; Tue, 11 Sep 2012 17:28:47 +0000
Received: from [85.158.143.35:5813] by server-2.bemta-4.messagelabs.com id
	AF/54-21239-EC47F405; Tue, 11 Sep 2012 17:28:46 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1347384522!6791667!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDg1NjI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29606 invoked from network); 11 Sep 2012 17:28:42 -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;
	11 Sep 2012 17:28:42 -0000
X-IronPort-AV: E=Sophos;i="4.80,406,1344211200"; d="scan'208";a="14477664"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Sep 2012 17:28: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.279.1; Tue, 11 Sep 2012 18:28: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 1TBUGB-0000PE-Np;
	Tue, 11 Sep 2012 17:28:27 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1TBUGB-0003pM-8E;
	Tue, 11 Sep 2012 18:28:27 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-13677-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Tue, 11 Sep 2012 18:28:27 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13677: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 13677 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13677/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-rhel6hvm-amd  8 guest-stop                fail REGR. vs. 13668
 test-amd64-i386-qemuu-rhel6hvm-amd  8 guest-stop          fail REGR. vs. 13668
 test-amd64-i386-qemuu-rhel6hvm-intel  8 guest-stop        fail REGR. vs. 13668
 test-amd64-i386-rhel6hvm-intel  8 guest-stop              fail REGR. vs. 13668

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore            fail   like 13668
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail like 13668
 test-i386-i386-xl-qemuu-winxpsp3  9 guest-localmigrate         fail like 13668
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail like 13668

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-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
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass

version targeted for testing:
 xen                  0a9a4549e6b9
baseline version:
 xen                  7d770de90b7f

------------------------------------------------------------
People who touched revisions under test:
  Boris Ostrovsky <boris.ostrovsky@amd.com>
  Ian Campbell <ian.campbell@citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Keir Fraser <keir@xen.org>
  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                                 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.

------------------------------------------------------------
changeset:   25844:0a9a4549e6b9
tag:         tip
user:        Boris Ostrovsky <boris.ostrovsky@amd.com>
date:        Tue Sep 11 10:57:36 2012 +0200
    
    powernow: Update P-state directly when _PSD's CoordType is DOMAIN_COORD_TYPE_HW_ALL
    
    When _PSD's CoordType is DOMAIN_COORD_TYPE_HW_ALL (i.e. shared_type is
    CPUFREQ_SHARED_TYPE_HW) which most often is the case on servers, there
    is no reason to go into on_selected_cpus() code, we call call
    transition_pstate() directly.
    
    Signed-off-by: Boris Ostrovsky <boris.ostrovsky@amd.com>
    Committed-by: Jan Beulich <jbeulich@suse.com>
    
    
changeset:   25843:51090fe1ab97
user:        Jan Beulich <jbeulich@suse.com>
date:        Tue Sep 11 10:00:06 2012 +0200
    
    x86/HVM: assorted RTC emulation adjustments
    
    - don't look at RTC_PIE in rtc_timer_update(), and hence don't call the
      function on REG_B writes at all
    - only call alarm_timer_update() on REG_B writes when relevant bits
      change
    - only call check_update_timer() on REG_B writes when SET changes
    - instead properly handle AF and PF when the guest is not also setting
      AIE/PIE respectively (for UF this was already the case, only a
      comment was slightly inaccurate)
    - raise the RTC IRQ not only when UIE gets set while UF was already
      set, but generalize this to cover AIE and PIE as well
    - properly mask off bit 7 when retrieving the hour values in
      alarm_timer_update(), and properly use RTC_HOURS_ALARM's bit 7 when
      converting from 12- to 24-hour value
    - also handle the two other possible clock bases
    - use RTC_* names in a couple of places where literal numbers were used
      so far
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   25842:a1f73e989c24
user:        Jan Beulich <jbeulich@suse.com>
date:        Mon Sep 10 16:47:31 2012 +0200
    
    x86/hvm: don't give vector callback higher priority than NMI/MCE
    
    Those two should always be delivered first imo.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
    
    
changeset:   25841:7d770de90b7f
user:        Jan Beulich <JBeulich@suse.com>
date:        Mon Sep 10 11:13:56 2012 +0100
    
    docs: document "ucode=" hypervisor command line option
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Ian Campbell <ian.campbell@citrix.com>
    Committed-by: Ian Campbell <ian.campbell@citrix.com>
    
    
(qemu changes not included)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 11 18:19:46 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 2012 18: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 1TBV3P-00034l-SD; Tue, 11 Sep 2012 18:19: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 1TBV3O-00034g-Qw
	for xen-devel@lists.xensource.com; Tue, 11 Sep 2012 18:19:19 +0000
Received: from [85.158.139.83:53623] by server-9.bemta-5.messagelabs.com id
	DE/DB-20529-6A08F405; Tue, 11 Sep 2012 18:19:18 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1347387557!29896786!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDg1NjI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15522 invoked from network); 11 Sep 2012 18:19:17 -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 Sep 2012 18:19:17 -0000
X-IronPort-AV: E=Sophos;i="4.80,406,1344211200"; d="scan'208";a="14478380"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Sep 2012 18:19: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.279.1; Tue, 11 Sep 2012 19:19: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 1TBV3M-0000gE-5b;
	Tue, 11 Sep 2012 18:19:16 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1TBV3M-0002OG-43;
	Tue, 11 Sep 2012 19:19:16 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-13679-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Tue, 11 Sep 2012 19:19:16 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.0-testing test] 13679: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 13679 xen-4.0-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13679/

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. 13650
 build-amd64-oldkern           4 xen-build                 fail REGR. vs. 13650
 build-i386                    4 xen-build                 fail REGR. vs. 13650
 build-amd64                   4 xen-build                 fail REGR. vs. 13650

Tests which did not succeed, but are not blocking:
 test-amd64-i386-xl-multivcpu  1 xen-build-check(1)           blocked  n/a
 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-i386-xl            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pv            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  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-pv           1 xen-build-check(1)           blocked  n/a
 test-i386-i386-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-qemuu-rhel6hvm-intel  1 xen-build-check(1)         blocked n/a
 test-amd64-amd64-xl-sedf      1 xen-build-check(1)           blocked  n/a
 test-i386-i386-pair           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-credit2    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pair          1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pair         1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-amd  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 xen-build-check(1)         blocked n/a
 test-amd64-i386-win-vcpus1    1 xen-build-check(1)           blocked  n/a
 test-i386-i386-win            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xend-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win           1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-win          1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-winxpsp3-vcpus1  1 xen-build-check(1)           blocked n/a
 test-amd64-amd64-xl-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-win-vcpus1  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win       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-qemuu-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                  512168f88df9
baseline version:
 xen                  79444af3258c

------------------------------------------------------------
People who touched revisions under test:
------------------------------------------------------------

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-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.

------------------------------------------------------------
changeset:   21616:512168f88df9
tag:         tip
user:        Ian Jackson <Ian.Jackson@eu.citrix.com>
date:        Tue Sep 11 14:35:26 2012 +0100
    
    QEMU_TAG update
    
    
changeset:   21615:79444af3258c
user:        Ian Jackson <Ian.Jackson@eu.citrix.com>
date:        Wed Sep 05 12:40:12 2012 +0100
    
    QEMU_TAG update (XSA-17 / CVE-2012-3515)
    
    
(qemu changes not included)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 11 18:19:46 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 2012 18: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 1TBV3P-00034l-SD; Tue, 11 Sep 2012 18:19: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 1TBV3O-00034g-Qw
	for xen-devel@lists.xensource.com; Tue, 11 Sep 2012 18:19:19 +0000
Received: from [85.158.139.83:53623] by server-9.bemta-5.messagelabs.com id
	DE/DB-20529-6A08F405; Tue, 11 Sep 2012 18:19:18 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1347387557!29896786!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDg1NjI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15522 invoked from network); 11 Sep 2012 18:19:17 -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 Sep 2012 18:19:17 -0000
X-IronPort-AV: E=Sophos;i="4.80,406,1344211200"; d="scan'208";a="14478380"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Sep 2012 18:19: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.279.1; Tue, 11 Sep 2012 19:19: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 1TBV3M-0000gE-5b;
	Tue, 11 Sep 2012 18:19:16 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1TBV3M-0002OG-43;
	Tue, 11 Sep 2012 19:19:16 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-13679-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Tue, 11 Sep 2012 19:19:16 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.0-testing test] 13679: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 13679 xen-4.0-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13679/

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. 13650
 build-amd64-oldkern           4 xen-build                 fail REGR. vs. 13650
 build-i386                    4 xen-build                 fail REGR. vs. 13650
 build-amd64                   4 xen-build                 fail REGR. vs. 13650

Tests which did not succeed, but are not blocking:
 test-amd64-i386-xl-multivcpu  1 xen-build-check(1)           blocked  n/a
 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-i386-xl            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pv            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  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-pv           1 xen-build-check(1)           blocked  n/a
 test-i386-i386-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-qemuu-rhel6hvm-intel  1 xen-build-check(1)         blocked n/a
 test-amd64-amd64-xl-sedf      1 xen-build-check(1)           blocked  n/a
 test-i386-i386-pair           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-credit2    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pair          1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pair         1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-amd  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 xen-build-check(1)         blocked n/a
 test-amd64-i386-win-vcpus1    1 xen-build-check(1)           blocked  n/a
 test-i386-i386-win            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xend-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win           1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-win          1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-winxpsp3-vcpus1  1 xen-build-check(1)           blocked n/a
 test-amd64-amd64-xl-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-win-vcpus1  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win       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-qemuu-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                  512168f88df9
baseline version:
 xen                  79444af3258c

------------------------------------------------------------
People who touched revisions under test:
------------------------------------------------------------

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-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.

------------------------------------------------------------
changeset:   21616:512168f88df9
tag:         tip
user:        Ian Jackson <Ian.Jackson@eu.citrix.com>
date:        Tue Sep 11 14:35:26 2012 +0100
    
    QEMU_TAG update
    
    
changeset:   21615:79444af3258c
user:        Ian Jackson <Ian.Jackson@eu.citrix.com>
date:        Wed Sep 05 12:40:12 2012 +0100
    
    QEMU_TAG update (XSA-17 / CVE-2012-3515)
    
    
(qemu changes not included)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 11 18:25:52 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 2012 18: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 1TBV9K-0003EY-SL; Tue, 11 Sep 2012 18:25:26 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ketuzsezr@gmail.com>) id 1TBV9J-0003ER-Dy
	for xen-devel@lists.xen.org; Tue, 11 Sep 2012 18:25:25 +0000
Received: from [85.158.139.83:50625] by server-7.bemta-5.messagelabs.com id
	4F/3D-19703-4128F405; Tue, 11 Sep 2012 18:25:24 +0000
X-Env-Sender: ketuzsezr@gmail.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1347387922!29245054!1
X-Originating-IP: [209.85.212.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22260 invoked from network); 11 Sep 2012 18:25:23 -0000
Received: from mail-vb0-f45.google.com (HELO mail-vb0-f45.google.com)
	(209.85.212.45)
	by server-9.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Sep 2012 18:25:23 -0000
Received: by vbip1 with SMTP id p1so1319812vbi.32
	for <xen-devel@lists.xen.org>; Tue, 11 Sep 2012 11:25:22 -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=h542Egy8wclzJfMX+RRWH88RJID6XfLdaadKTjPt9DU=;
	b=RWpLQe693gpNJNfZhjNyFWgD4yYXuJtL73vsqh2h4pZSrA348xbRoE3LrlK/6G1Hzm
	40jMJDcdH7BaT6OFPBFrmFYxYPYnU0lAsWr5V/5rp8/xKza2gD85KesSazFfVCOxmAlR
	B2nyyWJ9jBPKnOKStraRJim1p8X4tOT8UUCraemWjHCD8plHjl08Q4aH6ojONqASbHCv
	PIxjSbtYhbmJRRL0QtcjCTB9TX9ThgijjuoClDmCr5DU5GSYWpLP9MlqO4DIWjMEr2l7
	/Bdq/43Bpyp/rNcTIX81VOK8OR2oKzxWEsBkqlMvaQFS+D80LCFV//RkdlVkKviwbD9P
	xIzg==
Received: by 10.221.13.72 with SMTP id pl8mr27074122vcb.5.1347387921828;
	Tue, 11 Sep 2012 11:25:21 -0700 (PDT)
Received: from phenom.dumpdata.com
	(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 a13sm12478105vdu.9.2012.09.11.11.25.19
	(version=TLSv1/SSLv3 cipher=OTHER);
	Tue, 11 Sep 2012 11:25:20 -0700 (PDT)
Date: Tue, 11 Sep 2012 14:14:40 -0400
From: Konrad Rzeszutek Wilk <konrad@kernel.org>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20120911181439.GA30767@phenom.dumpdata.com>
References: <504F2C54020000780009A830@nat28.tlf.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <504F2C54020000780009A830@nat28.tlf.novell.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 6/8] ns16550: PCI initialization adjustments
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Sep 11, 2012 at 11:19:32AM +0100, Jan Beulich wrote:
> Besides single-port serial cards, also accept multi-port ones and such
> providing mixed functionality (e.g. also having a parallel port).
> 
> Reading PCI_INTERRUPT_PIN before ACPI gets enabled generally produces
> an incorrect IRQ (below 16, whereas after enabling ACPI it frequently
> would end up at a higher one), so this is useful (almost) only when a
> system already boots in ACPI mode.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> 
> --- a/xen/drivers/char/ns16550.c
> +++ b/xen/drivers/char/ns16550.c
> @@ -468,7 +468,6 @@ static int __init check_existence(struct
>  static int
>  pci_uart_config (struct ns16550 *uart, int skip_amt, int bar_idx)
>  {
> -    uint16_t class;
>      uint32_t bar, len;
>      int b, d, f;
>  
> @@ -479,9 +478,15 @@ pci_uart_config (struct ns16550 *uart, i
>          {
>              for ( f = 0; f < 0x8; f++ )
>              {
> -                class = pci_conf_read16(0, b, d, f, PCI_CLASS_DEVICE);
> -                if ( class != 0x700 )
> +                switch ( pci_conf_read16(0, b, d, f, PCI_CLASS_DEVICE) )
> +                {
> +                case 0x0700: /* single port serial */
> +                case 0x0702: /* multi port serial */
> +                case 0x0780: /* other (e.g serial+parallel) */
> +                    break;
> +                default:
>                      continue;
> +                }
>  
>                  bar = pci_conf_read32(0, b, d, f,
>                                        PCI_BASE_ADDRESS_0 + bar_idx*4);
> @@ -504,7 +509,9 @@ pci_uart_config (struct ns16550 *uart, i
>                  uart->bar = bar;
>                  uart->bar_idx = bar_idx;
>                  uart->io_base = bar & ~PCI_BASE_ADDRESS_SPACE_IO;
> -                uart->irq = 0;
> +                uart->irq = pci_conf_read8(0, b, d, f, PCI_INTERRUPT_PIN) ?
> +                    pci_conf_read8(0, b, d, f, PCI_INTERRUPT_LINE) : 0;
> +printk("COM%d: BAR=%04x IRQ=%d\n", bar_idx + 1, bar, uart->irq);//temp

printk ?

>  
>                  return 0;
>              }
> 
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 11 18:25:52 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 2012 18: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 1TBV9K-0003EY-SL; Tue, 11 Sep 2012 18:25:26 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ketuzsezr@gmail.com>) id 1TBV9J-0003ER-Dy
	for xen-devel@lists.xen.org; Tue, 11 Sep 2012 18:25:25 +0000
Received: from [85.158.139.83:50625] by server-7.bemta-5.messagelabs.com id
	4F/3D-19703-4128F405; Tue, 11 Sep 2012 18:25:24 +0000
X-Env-Sender: ketuzsezr@gmail.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1347387922!29245054!1
X-Originating-IP: [209.85.212.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22260 invoked from network); 11 Sep 2012 18:25:23 -0000
Received: from mail-vb0-f45.google.com (HELO mail-vb0-f45.google.com)
	(209.85.212.45)
	by server-9.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Sep 2012 18:25:23 -0000
Received: by vbip1 with SMTP id p1so1319812vbi.32
	for <xen-devel@lists.xen.org>; Tue, 11 Sep 2012 11:25:22 -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=h542Egy8wclzJfMX+RRWH88RJID6XfLdaadKTjPt9DU=;
	b=RWpLQe693gpNJNfZhjNyFWgD4yYXuJtL73vsqh2h4pZSrA348xbRoE3LrlK/6G1Hzm
	40jMJDcdH7BaT6OFPBFrmFYxYPYnU0lAsWr5V/5rp8/xKza2gD85KesSazFfVCOxmAlR
	B2nyyWJ9jBPKnOKStraRJim1p8X4tOT8UUCraemWjHCD8plHjl08Q4aH6ojONqASbHCv
	PIxjSbtYhbmJRRL0QtcjCTB9TX9ThgijjuoClDmCr5DU5GSYWpLP9MlqO4DIWjMEr2l7
	/Bdq/43Bpyp/rNcTIX81VOK8OR2oKzxWEsBkqlMvaQFS+D80LCFV//RkdlVkKviwbD9P
	xIzg==
Received: by 10.221.13.72 with SMTP id pl8mr27074122vcb.5.1347387921828;
	Tue, 11 Sep 2012 11:25:21 -0700 (PDT)
Received: from phenom.dumpdata.com
	(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 a13sm12478105vdu.9.2012.09.11.11.25.19
	(version=TLSv1/SSLv3 cipher=OTHER);
	Tue, 11 Sep 2012 11:25:20 -0700 (PDT)
Date: Tue, 11 Sep 2012 14:14:40 -0400
From: Konrad Rzeszutek Wilk <konrad@kernel.org>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20120911181439.GA30767@phenom.dumpdata.com>
References: <504F2C54020000780009A830@nat28.tlf.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <504F2C54020000780009A830@nat28.tlf.novell.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 6/8] ns16550: PCI initialization adjustments
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Sep 11, 2012 at 11:19:32AM +0100, Jan Beulich wrote:
> Besides single-port serial cards, also accept multi-port ones and such
> providing mixed functionality (e.g. also having a parallel port).
> 
> Reading PCI_INTERRUPT_PIN before ACPI gets enabled generally produces
> an incorrect IRQ (below 16, whereas after enabling ACPI it frequently
> would end up at a higher one), so this is useful (almost) only when a
> system already boots in ACPI mode.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> 
> --- a/xen/drivers/char/ns16550.c
> +++ b/xen/drivers/char/ns16550.c
> @@ -468,7 +468,6 @@ static int __init check_existence(struct
>  static int
>  pci_uart_config (struct ns16550 *uart, int skip_amt, int bar_idx)
>  {
> -    uint16_t class;
>      uint32_t bar, len;
>      int b, d, f;
>  
> @@ -479,9 +478,15 @@ pci_uart_config (struct ns16550 *uart, i
>          {
>              for ( f = 0; f < 0x8; f++ )
>              {
> -                class = pci_conf_read16(0, b, d, f, PCI_CLASS_DEVICE);
> -                if ( class != 0x700 )
> +                switch ( pci_conf_read16(0, b, d, f, PCI_CLASS_DEVICE) )
> +                {
> +                case 0x0700: /* single port serial */
> +                case 0x0702: /* multi port serial */
> +                case 0x0780: /* other (e.g serial+parallel) */
> +                    break;
> +                default:
>                      continue;
> +                }
>  
>                  bar = pci_conf_read32(0, b, d, f,
>                                        PCI_BASE_ADDRESS_0 + bar_idx*4);
> @@ -504,7 +509,9 @@ pci_uart_config (struct ns16550 *uart, i
>                  uart->bar = bar;
>                  uart->bar_idx = bar_idx;
>                  uart->io_base = bar & ~PCI_BASE_ADDRESS_SPACE_IO;
> -                uart->irq = 0;
> +                uart->irq = pci_conf_read8(0, b, d, f, PCI_INTERRUPT_PIN) ?
> +                    pci_conf_read8(0, b, d, f, PCI_INTERRUPT_LINE) : 0;
> +printk("COM%d: BAR=%04x IRQ=%d\n", bar_idx + 1, bar, uart->irq);//temp

printk ?

>  
>                  return 0;
>              }
> 
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 11 18:40:21 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 2012 18: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 1TBVNL-0003Ss-C2; Tue, 11 Sep 2012 18:39:55 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ketuzsezr@gmail.com>) id 1TBVNJ-0003Sn-6F
	for xen-devel@lists.xen.org; Tue, 11 Sep 2012 18:39:53 +0000
Received: from [85.158.143.99:10725] by server-3.bemta-4.messagelabs.com id
	A8/3A-08232-8758F405; Tue, 11 Sep 2012 18:39:52 +0000
X-Env-Sender: ketuzsezr@gmail.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1347388790!29794755!1
X-Originating-IP: [209.85.220.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12467 invoked from network); 11 Sep 2012 18:39:51 -0000
Received: from mail-vc0-f173.google.com (HELO mail-vc0-f173.google.com)
	(209.85.220.173)
	by server-15.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Sep 2012 18:39:51 -0000
Received: by vcbfl15 with SMTP id fl15so1333098vcb.32
	for <xen-devel@lists.xen.org>; Tue, 11 Sep 2012 11:39:50 -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:content-transfer-encoding
	:in-reply-to:user-agent;
	bh=itVGjIYCx96mz6FcvQYNHsG4yR9drj8QNscJvW9wfPo=;
	b=sWvxY1BekPdVhe23It8W5I6aChjSPiXl7Csx09bjpmxZF2PyNDFodqwIP1S7RbK0a5
	iVva6w8QnSZHhi8RsqtNLrdM2yFOZnYWDB4AUEugmBrPXQOSrbeWSDhtwbq4K/ZSXRRD
	tEs62eR3Qxb7k7jIQPIKpsa6DOLn/jp7J9seArPolPoqsxF297O/VQ60VMwou4cGNiBY
	j86F5Jfn1tPS1M11KGKMHXWkYQDNqRHqHZNyRXuJbZqDRcB7kxzf/6xWcbAmce1D1w3o
	gMwJ1SX3tS62rQXyAxl5dnN8Csmlu6h04FF9rWsbUMPVjEESrnNZX76Xj6TvFxax2gva
	EilA==
Received: by 10.52.65.78 with SMTP id v14mr1049904vds.73.1347388790128;
	Tue, 11 Sep 2012 11:39:50 -0700 (PDT)
Received: from phenom.dumpdata.com
	(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 t12sm6016152vdi.18.2012.09.11.11.39.48
	(version=TLSv1/SSLv3 cipher=OTHER);
	Tue, 11 Sep 2012 11:39:48 -0700 (PDT)
Date: Tue, 11 Sep 2012 14:29:08 -0400
From: Konrad Rzeszutek Wilk <konrad@kernel.org>
To: =?utf-8?B?4KSF4KSo4KS/4KSV4KWH4KSkIOCkhuCkl+CkvuCktuClhw==?=
	<agasheac@gmail.com>
Message-ID: <20120911182907.GB30767@phenom.dumpdata.com>
References: <CAMQ5s704d8-UscdPtpJ8GPMs_YzTjiOupdi9mWfpfDrRnYV=vQ@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAMQ5s704d8-UscdPtpJ8GPMs_YzTjiOupdi9mWfpfDrRnYV=vQ@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] xen not able to use total physical memory present
 in the system (192GB)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gVHVlLCBTZXAgMTEsIDIwMTIgYXQgMDc6MDc6MDBQTSArMDUzMCwg4KSF4KSo4KS/4KSV4KWH
4KSkIOCkhuCkl+CkvuCktuClhyAgd3JvdGU6Cj4gSGkKPiAKPiBJIGFtIHVzaW5nIHhlbi00LjEu
MiB3aXRoIGZlZG9yYS0xNiAoa2VybmVsIHZlcnNpb24gMy4xLjAuNykgYXMgZG9tMCBvbgo+IHN5
c3RlbSBoYXZpbmcgMTkyR0Igb2YgUkFNLgoKCkNhbiB5b3UgY2hlY2sgL2Jvb3QvY29uZmlnKiB8
IGdyZXAgWEVOX01BWF9ET01BSU4KCgo+IAo+IFdoZW4gaSBib290ZWQgc3lzdGVtIHhtIGluZm8g
c2hvd3MgKHRvdGFsIF9tZW1vcnkgcGFyYW1ldGVyIGFzIDE5MkdCIGFuZAo+IGZyZWVfbWVtb3J5
IGFzIDI1TUIpIGZ1bGwgbWVtb3J5IGJ1dCAvcHJvYy9tZW1pbmZvIHJlcG9ydHMgMTMyR0IgYW5k
IHhtCj4gbGlzdCBhbHNvIHJlcG9ydHMgMTkyR0IgZm9yIGRvbTAKPiAKPiBXaGVuIEkgcmFuIGZp
cnN0IFZNIHdpdGggMzJHQiBSQU0sIHhtIGluZm8gc3RhcnRlZCByZXBvcnRpbmcgbWVtb3J5IGZv
cgo+IGRvbTAgYXJvdW5kIDEzMkdCIGFuZCAzMkdCIGZvciBWTSBhbmQgY2F0IC9wcm9jL21lbWlu
Zm8gb24gZG9tMCByZXBvcnRlZAo+IGFyb3VuZCAxMDBHQi4gSSBhbSBhYmxlIHRvIGJvb3QgNCBW
TXMgd2l0aCB0aGlzIHNldHVwIGJ1dCA1dGggVk0gZmFpbHMgdG8KPiBib290IHdpdGggbm90IGVu
b3VnaCBtZW1vcnkuCj4gCj4gCj4gdWx0aW1hdGVseSBub3QgYWJsZSB0byB1c2UgZnVsbCBzeXN0
ZW0gbWVtb3J5ID8gNjBHQiB3ZW50IG1pc3NpbmcgZnJvbQo+IG1lbW9yeS4KClRoZXJlIGFyZSBh
bHNvIHNvbWUgYnVnLWZpeGVzIGZvciB0aGlzIHRoYXQgSSd2ZSBiZWVuIHBvc3RpbmcgdGhhdApJ
IHBsYW4gdG8gaW50ZWdyYXRlIGluIHYzLjcuCgpBcmUgeW91IHVwIGZvciB0ZXN0aW5nIHRoZW0g
b3V0IGFuZCB0byBzZWUgaWYgdGhleSB3b3JrPwo+IAo+IGh0dHA6Ly9vbGQtbGlzdC1hcmNoaXZl
cy54ZW4ub3JnL2FyY2hpdmVzL2h0bWwveGVuLWRldmVsLzIwMDktMDcvbXNnMDA1MjEuaHRtbAo+
IAo+IE9uIHRoaXMgdGhyZWFkLAo+IAo+IEphbiBtZW50aW5lZAo+IAo+ICJ0aGUgaHlwZXJ2aXNv
ciBoYXMgYmVlbiB2YWxpZGF0ZWQgdG8gd29yayBmaW5lIHdpdGggMVRiIGZvciBtdWNoIGxvbmdl
ciwgaXQgd2FzCj4gcmVhbGx5IHRoZSBEb20wIGtlcm5lbCB0aGF0IGhhZCBpc3N1ZXMgd2hlbiBu
b3QgcGFzc2luZyBhIGRvbTBfbWVtPQo+IG9wdGlvbiIuCj4gCj4gSSBhbSBub3QgdXNpbmcgdGhp
cyBvcHRpb24gImRvbTBfbWVtIi4gSXMgYW55Ym9keSBmYWNlZCBhbnkgaXNzdWUgbGlrZSB0aGlz
ID8KPiAKPiAKPiBUaGFua3MsCj4gQW5pa2V0Cgo+IF9fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fCj4gWGVuLWRldmVsIG1haWxpbmcgbGlzdAo+IFhlbi1kZXZl
bEBsaXN0cy54ZW4ub3JnCj4gaHR0cDovL2xpc3RzLnhlbi5vcmcveGVuLWRldmVsCgoKX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxp
bmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwOi8vbGlzdHMueGVuLm9yZy94ZW4t
ZGV2ZWwK

From xen-devel-bounces@lists.xen.org Tue Sep 11 18:40:21 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 2012 18: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 1TBVNL-0003Ss-C2; Tue, 11 Sep 2012 18:39:55 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ketuzsezr@gmail.com>) id 1TBVNJ-0003Sn-6F
	for xen-devel@lists.xen.org; Tue, 11 Sep 2012 18:39:53 +0000
Received: from [85.158.143.99:10725] by server-3.bemta-4.messagelabs.com id
	A8/3A-08232-8758F405; Tue, 11 Sep 2012 18:39:52 +0000
X-Env-Sender: ketuzsezr@gmail.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1347388790!29794755!1
X-Originating-IP: [209.85.220.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12467 invoked from network); 11 Sep 2012 18:39:51 -0000
Received: from mail-vc0-f173.google.com (HELO mail-vc0-f173.google.com)
	(209.85.220.173)
	by server-15.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Sep 2012 18:39:51 -0000
Received: by vcbfl15 with SMTP id fl15so1333098vcb.32
	for <xen-devel@lists.xen.org>; Tue, 11 Sep 2012 11:39:50 -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:content-transfer-encoding
	:in-reply-to:user-agent;
	bh=itVGjIYCx96mz6FcvQYNHsG4yR9drj8QNscJvW9wfPo=;
	b=sWvxY1BekPdVhe23It8W5I6aChjSPiXl7Csx09bjpmxZF2PyNDFodqwIP1S7RbK0a5
	iVva6w8QnSZHhi8RsqtNLrdM2yFOZnYWDB4AUEugmBrPXQOSrbeWSDhtwbq4K/ZSXRRD
	tEs62eR3Qxb7k7jIQPIKpsa6DOLn/jp7J9seArPolPoqsxF297O/VQ60VMwou4cGNiBY
	j86F5Jfn1tPS1M11KGKMHXWkYQDNqRHqHZNyRXuJbZqDRcB7kxzf/6xWcbAmce1D1w3o
	gMwJ1SX3tS62rQXyAxl5dnN8Csmlu6h04FF9rWsbUMPVjEESrnNZX76Xj6TvFxax2gva
	EilA==
Received: by 10.52.65.78 with SMTP id v14mr1049904vds.73.1347388790128;
	Tue, 11 Sep 2012 11:39:50 -0700 (PDT)
Received: from phenom.dumpdata.com
	(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 t12sm6016152vdi.18.2012.09.11.11.39.48
	(version=TLSv1/SSLv3 cipher=OTHER);
	Tue, 11 Sep 2012 11:39:48 -0700 (PDT)
Date: Tue, 11 Sep 2012 14:29:08 -0400
From: Konrad Rzeszutek Wilk <konrad@kernel.org>
To: =?utf-8?B?4KSF4KSo4KS/4KSV4KWH4KSkIOCkhuCkl+CkvuCktuClhw==?=
	<agasheac@gmail.com>
Message-ID: <20120911182907.GB30767@phenom.dumpdata.com>
References: <CAMQ5s704d8-UscdPtpJ8GPMs_YzTjiOupdi9mWfpfDrRnYV=vQ@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAMQ5s704d8-UscdPtpJ8GPMs_YzTjiOupdi9mWfpfDrRnYV=vQ@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] xen not able to use total physical memory present
 in the system (192GB)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gVHVlLCBTZXAgMTEsIDIwMTIgYXQgMDc6MDc6MDBQTSArMDUzMCwg4KSF4KSo4KS/4KSV4KWH
4KSkIOCkhuCkl+CkvuCktuClhyAgd3JvdGU6Cj4gSGkKPiAKPiBJIGFtIHVzaW5nIHhlbi00LjEu
MiB3aXRoIGZlZG9yYS0xNiAoa2VybmVsIHZlcnNpb24gMy4xLjAuNykgYXMgZG9tMCBvbgo+IHN5
c3RlbSBoYXZpbmcgMTkyR0Igb2YgUkFNLgoKCkNhbiB5b3UgY2hlY2sgL2Jvb3QvY29uZmlnKiB8
IGdyZXAgWEVOX01BWF9ET01BSU4KCgo+IAo+IFdoZW4gaSBib290ZWQgc3lzdGVtIHhtIGluZm8g
c2hvd3MgKHRvdGFsIF9tZW1vcnkgcGFyYW1ldGVyIGFzIDE5MkdCIGFuZAo+IGZyZWVfbWVtb3J5
IGFzIDI1TUIpIGZ1bGwgbWVtb3J5IGJ1dCAvcHJvYy9tZW1pbmZvIHJlcG9ydHMgMTMyR0IgYW5k
IHhtCj4gbGlzdCBhbHNvIHJlcG9ydHMgMTkyR0IgZm9yIGRvbTAKPiAKPiBXaGVuIEkgcmFuIGZp
cnN0IFZNIHdpdGggMzJHQiBSQU0sIHhtIGluZm8gc3RhcnRlZCByZXBvcnRpbmcgbWVtb3J5IGZv
cgo+IGRvbTAgYXJvdW5kIDEzMkdCIGFuZCAzMkdCIGZvciBWTSBhbmQgY2F0IC9wcm9jL21lbWlu
Zm8gb24gZG9tMCByZXBvcnRlZAo+IGFyb3VuZCAxMDBHQi4gSSBhbSBhYmxlIHRvIGJvb3QgNCBW
TXMgd2l0aCB0aGlzIHNldHVwIGJ1dCA1dGggVk0gZmFpbHMgdG8KPiBib290IHdpdGggbm90IGVu
b3VnaCBtZW1vcnkuCj4gCj4gCj4gdWx0aW1hdGVseSBub3QgYWJsZSB0byB1c2UgZnVsbCBzeXN0
ZW0gbWVtb3J5ID8gNjBHQiB3ZW50IG1pc3NpbmcgZnJvbQo+IG1lbW9yeS4KClRoZXJlIGFyZSBh
bHNvIHNvbWUgYnVnLWZpeGVzIGZvciB0aGlzIHRoYXQgSSd2ZSBiZWVuIHBvc3RpbmcgdGhhdApJ
IHBsYW4gdG8gaW50ZWdyYXRlIGluIHYzLjcuCgpBcmUgeW91IHVwIGZvciB0ZXN0aW5nIHRoZW0g
b3V0IGFuZCB0byBzZWUgaWYgdGhleSB3b3JrPwo+IAo+IGh0dHA6Ly9vbGQtbGlzdC1hcmNoaXZl
cy54ZW4ub3JnL2FyY2hpdmVzL2h0bWwveGVuLWRldmVsLzIwMDktMDcvbXNnMDA1MjEuaHRtbAo+
IAo+IE9uIHRoaXMgdGhyZWFkLAo+IAo+IEphbiBtZW50aW5lZAo+IAo+ICJ0aGUgaHlwZXJ2aXNv
ciBoYXMgYmVlbiB2YWxpZGF0ZWQgdG8gd29yayBmaW5lIHdpdGggMVRiIGZvciBtdWNoIGxvbmdl
ciwgaXQgd2FzCj4gcmVhbGx5IHRoZSBEb20wIGtlcm5lbCB0aGF0IGhhZCBpc3N1ZXMgd2hlbiBu
b3QgcGFzc2luZyBhIGRvbTBfbWVtPQo+IG9wdGlvbiIuCj4gCj4gSSBhbSBub3QgdXNpbmcgdGhp
cyBvcHRpb24gImRvbTBfbWVtIi4gSXMgYW55Ym9keSBmYWNlZCBhbnkgaXNzdWUgbGlrZSB0aGlz
ID8KPiAKPiAKPiBUaGFua3MsCj4gQW5pa2V0Cgo+IF9fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fCj4gWGVuLWRldmVsIG1haWxpbmcgbGlzdAo+IFhlbi1kZXZl
bEBsaXN0cy54ZW4ub3JnCj4gaHR0cDovL2xpc3RzLnhlbi5vcmcveGVuLWRldmVsCgoKX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxp
bmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwOi8vbGlzdHMueGVuLm9yZy94ZW4t
ZGV2ZWwK

From xen-devel-bounces@lists.xen.org Tue Sep 11 18:44:31 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 2012 18:44:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TBVRV-0003Z9-4p; Tue, 11 Sep 2012 18:44:13 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <karrelsj@gmail.com>) id 1TBVRU-0003Z3-4v
	for xen-devel@lists.xen.org; Tue, 11 Sep 2012 18:44:12 +0000
Received: from [85.158.143.35:8952] by server-2.bemta-4.messagelabs.com id
	E1/AB-21239-B768F405; Tue, 11 Sep 2012 18:44:11 +0000
X-Env-Sender: karrelsj@gmail.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1347389050!15307733!1
X-Originating-IP: [74.125.82.51]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6990 invoked from network); 11 Sep 2012 18:44:10 -0000
Received: from mail-wg0-f51.google.com (HELO mail-wg0-f51.google.com)
	(74.125.82.51)
	by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Sep 2012 18:44:10 -0000
Received: by wgbed3 with SMTP id ed3so499805wgb.32
	for <xen-devel@lists.xen.org>; Tue, 11 Sep 2012 11:44:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to
	:cc:content-type;
	bh=7qNFj6crUIOPyfSpcaTlbhLxbdqrSP7QHrOVKClSAB4=;
	b=D3NQru0n/BKM3J3TYVWibXIWqDXjOCw9PZ7QCJlBjTfjHuAkuEzKGcm6QgCRd/bpYm
	yKmr6Q6CUp2h25XQClRriAkJnx4ljT4Ouiw9N59srPXIkH6eFFiOFYObaDanF3mRA2lW
	PgS2amrH7/yTEt1nXhEQ+4XZA9Nl1uZtlCA1De9jmHfAkGB1xSe8nxCoi4nkgu7uAZSj
	fRjBIgWDfzNViCnBhHzL/Nv17EW80ELWUIj0hJRVeW7E2aTWBtodERfaIInRbjqL5OPC
	XmqNsXPZcmtrSHDw3BZVXwuk5gdbEbsPyCcXXr2dOEjSaqrQZ8M8Pqa+VFWjTjKlkjmp
	8bhg==
Received: by 10.216.30.83 with SMTP id j61mr10585368wea.168.1347389050023;
	Tue, 11 Sep 2012 11:44:10 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.216.255.79 with HTTP; Tue, 11 Sep 2012 11:43:49 -0700 (PDT)
In-Reply-To: <CAFw--DdYkAo79TeZKDFZ5ZdaN4KiLmW2qcceY+cTxuLMdE3QGA@mail.gmail.com>
References: <CAFw--Dd0k7L+T_UJc0yHAkUGrY_-GDHaQjK3OM-1UdOp=J-wAQ@mail.gmail.com>
	<20120907085036.GA71093@ocelot.phlegethon.org>
	<CAFw--DdYkAo79TeZKDFZ5ZdaN4KiLmW2qcceY+cTxuLMdE3QGA@mail.gmail.com>
From: Jeffrey Karrels <karrelsj@gmail.com>
Date: Tue, 11 Sep 2012 11:43:49 -0700
Message-ID: <CAFw--Dche2NB0jjBdMyAYC=S92XkW9UpsaBsTRBcX4ZP_oOcxA@mail.gmail.com>
To: Tim Deegan <tim@xen.org>
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Clang/LLVM version requirements
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Sep 7, 2012 at 8:58 AM, Jeffrey Karrels <karrelsj@gmail.com> wrote:
>> Looks like the clang build has bitrotted a little - sorry.  It's too
>> late to fix this for 4.2 now but we can sort it out after we branch
>> (i.e. next week) and backport any build fixes for 4.2.1.

Just to keep the knowledge in the collective... I updated my clang and
llvm to the latest trunk:

[builder@xenbuild1 xen-unstable]$ /usr/local/bin/clang -v
clang version 3.2 (trunk 163631)
Target: x86_64-unknown-linux-gnu
Thread model: posix

After that I applied the patch that Tim previously posted and tried
another make. The xen build succeeded.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 11 18:44:31 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 2012 18:44:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TBVRV-0003Z9-4p; Tue, 11 Sep 2012 18:44:13 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <karrelsj@gmail.com>) id 1TBVRU-0003Z3-4v
	for xen-devel@lists.xen.org; Tue, 11 Sep 2012 18:44:12 +0000
Received: from [85.158.143.35:8952] by server-2.bemta-4.messagelabs.com id
	E1/AB-21239-B768F405; Tue, 11 Sep 2012 18:44:11 +0000
X-Env-Sender: karrelsj@gmail.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1347389050!15307733!1
X-Originating-IP: [74.125.82.51]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6990 invoked from network); 11 Sep 2012 18:44:10 -0000
Received: from mail-wg0-f51.google.com (HELO mail-wg0-f51.google.com)
	(74.125.82.51)
	by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Sep 2012 18:44:10 -0000
Received: by wgbed3 with SMTP id ed3so499805wgb.32
	for <xen-devel@lists.xen.org>; Tue, 11 Sep 2012 11:44:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to
	:cc:content-type;
	bh=7qNFj6crUIOPyfSpcaTlbhLxbdqrSP7QHrOVKClSAB4=;
	b=D3NQru0n/BKM3J3TYVWibXIWqDXjOCw9PZ7QCJlBjTfjHuAkuEzKGcm6QgCRd/bpYm
	yKmr6Q6CUp2h25XQClRriAkJnx4ljT4Ouiw9N59srPXIkH6eFFiOFYObaDanF3mRA2lW
	PgS2amrH7/yTEt1nXhEQ+4XZA9Nl1uZtlCA1De9jmHfAkGB1xSe8nxCoi4nkgu7uAZSj
	fRjBIgWDfzNViCnBhHzL/Nv17EW80ELWUIj0hJRVeW7E2aTWBtodERfaIInRbjqL5OPC
	XmqNsXPZcmtrSHDw3BZVXwuk5gdbEbsPyCcXXr2dOEjSaqrQZ8M8Pqa+VFWjTjKlkjmp
	8bhg==
Received: by 10.216.30.83 with SMTP id j61mr10585368wea.168.1347389050023;
	Tue, 11 Sep 2012 11:44:10 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.216.255.79 with HTTP; Tue, 11 Sep 2012 11:43:49 -0700 (PDT)
In-Reply-To: <CAFw--DdYkAo79TeZKDFZ5ZdaN4KiLmW2qcceY+cTxuLMdE3QGA@mail.gmail.com>
References: <CAFw--Dd0k7L+T_UJc0yHAkUGrY_-GDHaQjK3OM-1UdOp=J-wAQ@mail.gmail.com>
	<20120907085036.GA71093@ocelot.phlegethon.org>
	<CAFw--DdYkAo79TeZKDFZ5ZdaN4KiLmW2qcceY+cTxuLMdE3QGA@mail.gmail.com>
From: Jeffrey Karrels <karrelsj@gmail.com>
Date: Tue, 11 Sep 2012 11:43:49 -0700
Message-ID: <CAFw--Dche2NB0jjBdMyAYC=S92XkW9UpsaBsTRBcX4ZP_oOcxA@mail.gmail.com>
To: Tim Deegan <tim@xen.org>
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Clang/LLVM version requirements
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Sep 7, 2012 at 8:58 AM, Jeffrey Karrels <karrelsj@gmail.com> wrote:
>> Looks like the clang build has bitrotted a little - sorry.  It's too
>> late to fix this for 4.2 now but we can sort it out after we branch
>> (i.e. next week) and backport any build fixes for 4.2.1.

Just to keep the knowledge in the collective... I updated my clang and
llvm to the latest trunk:

[builder@xenbuild1 xen-unstable]$ /usr/local/bin/clang -v
clang version 3.2 (trunk 163631)
Target: x86_64-unknown-linux-gnu
Thread model: posix

After that I applied the patch that Tim previously posted and tried
another make. The xen build succeeded.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 11 18:51:46 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 2012 18:51:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TBVYW-0003lU-1W; Tue, 11 Sep 2012 18:51:28 +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 1TBVYU-0003lP-Q8
	for xen-devel@lists.xensource.com; Tue, 11 Sep 2012 18:51:27 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1347389476!10614339!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDg1NjI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14895 invoked from network); 11 Sep 2012 18:51:17 -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;
	11 Sep 2012 18:51:17 -0000
X-IronPort-AV: E=Sophos;i="4.80,406,1344211200"; d="scan'208";a="14478916"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Sep 2012 18:51: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.279.1; Tue, 11 Sep 2012 19:51: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 1TBVYI-0000qL-Pl;
	Tue, 11 Sep 2012 18:51:14 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1TBVYI-00064T-KK;
	Tue, 11 Sep 2012 19:51:14 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-13678-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Tue, 11 Sep 2012 19:51:14 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.2-testing test] 13678: 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 13678 xen-4.2-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13678/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore            fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-i386-i386-xl-qemuu-winxpsp3  9 guest-localmigrate         fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  8c67e5358efa
baseline version:
 xen                  317c8a48d81f

------------------------------------------------------------
People who touched revisions under test:
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Keir Fraser <keir@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                                 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                                     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-4.2-testing
+ revision=8c67e5358efa
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push xen-4.2-testing 8c67e5358efa
+ branch=xen-4.2-testing
+ revision=8c67e5358efa
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-4.2-testing
+ '[' xxen = xlinux ']'
+ linuxbranch=linux
+ : master
+ : tested/2.6.39.x
+ . ap-common
++ : xen@xenbits.xensource.com
++ : http://xenbits.xen.org/hg/staging/xen-4.2-testing.hg
++ : git://xenbits.xen.org/staging/qemu-xen-4.2-testing.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : xen@xenbits.xensource.com:git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.xen-4.2-testing
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-4.2-testing.git
++ : daily-cron.xen-4.2-testing
+ TREE_LINUX=xen@xenbits.xensource.com:git/linux-pvops.git
+ TREE_QEMU_UPSTREAM=xen@xenbits.xensource.com:git/qemu-upstream-4.2-testing.git
+ info_linux_tree xen-4.2-testing
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/xen-4.2-testing.hg
+ hg push -r 8c67e5358efa ssh://xen@xenbits.xensource.com/HG/xen-4.2-testing.hg
pushing to ssh://xen@xenbits.xensource.com/HG/xen-4.2-testing.hg
searching for changes
remote: adding changesets
remote: adding manifests
remote: adding file changes
remote: added 2 changesets with 2 changes to 2 files

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 11 18:51:46 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 2012 18:51:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TBVYW-0003lU-1W; Tue, 11 Sep 2012 18:51:28 +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 1TBVYU-0003lP-Q8
	for xen-devel@lists.xensource.com; Tue, 11 Sep 2012 18:51:27 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1347389476!10614339!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDg1NjI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14895 invoked from network); 11 Sep 2012 18:51:17 -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;
	11 Sep 2012 18:51:17 -0000
X-IronPort-AV: E=Sophos;i="4.80,406,1344211200"; d="scan'208";a="14478916"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Sep 2012 18:51: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.279.1; Tue, 11 Sep 2012 19:51: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 1TBVYI-0000qL-Pl;
	Tue, 11 Sep 2012 18:51:14 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1TBVYI-00064T-KK;
	Tue, 11 Sep 2012 19:51:14 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-13678-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Tue, 11 Sep 2012 19:51:14 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.2-testing test] 13678: 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 13678 xen-4.2-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13678/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore            fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-i386-i386-xl-qemuu-winxpsp3  9 guest-localmigrate         fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  8c67e5358efa
baseline version:
 xen                  317c8a48d81f

------------------------------------------------------------
People who touched revisions under test:
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Keir Fraser <keir@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                                 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                                     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-4.2-testing
+ revision=8c67e5358efa
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push xen-4.2-testing 8c67e5358efa
+ branch=xen-4.2-testing
+ revision=8c67e5358efa
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-4.2-testing
+ '[' xxen = xlinux ']'
+ linuxbranch=linux
+ : master
+ : tested/2.6.39.x
+ . ap-common
++ : xen@xenbits.xensource.com
++ : http://xenbits.xen.org/hg/staging/xen-4.2-testing.hg
++ : git://xenbits.xen.org/staging/qemu-xen-4.2-testing.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : xen@xenbits.xensource.com:git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.xen-4.2-testing
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-4.2-testing.git
++ : daily-cron.xen-4.2-testing
+ TREE_LINUX=xen@xenbits.xensource.com:git/linux-pvops.git
+ TREE_QEMU_UPSTREAM=xen@xenbits.xensource.com:git/qemu-upstream-4.2-testing.git
+ info_linux_tree xen-4.2-testing
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/xen-4.2-testing.hg
+ hg push -r 8c67e5358efa ssh://xen@xenbits.xensource.com/HG/xen-4.2-testing.hg
pushing to ssh://xen@xenbits.xensource.com/HG/xen-4.2-testing.hg
searching for changes
remote: adding changesets
remote: adding manifests
remote: adding file changes
remote: added 2 changesets with 2 changes to 2 files

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 11 18:54:59 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 2012 18: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 1TBVbg-0003s3-LC; Tue, 11 Sep 2012 18:54: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 1TBVbf-0003rw-Ho
	for xen-devel@lists.xen.org; Tue, 11 Sep 2012 18:54:43 +0000
Received: from [85.158.139.83:41504] by server-2.bemta-5.messagelabs.com id
	7E/3E-11456-2F88F405; Tue, 11 Sep 2012 18:54:42 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-14.tower-182.messagelabs.com!1347389681!25655555!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiA0MjU4NDk=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiA0MjU4NDk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23436 invoked from network); 11 Sep 2012 18:54:42 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-14.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 11 Sep 2012 18:54:42 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFGjC0PG1RG
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-082-188.pools.arcor-ip.net [88.65.82.188])
	by smtp.strato.de (jored mo22) (RZmta 30.14 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id R0015ao8BI3o1n ;
	Tue, 11 Sep 2012 20:54:41 +0200 (CEST)
Received: by probook.site (Postfix, from userid 1000)
	id E790E183AD; Tue, 11 Sep 2012 20:54:40 +0200 (CEST)
Date: Tue, 11 Sep 2012 20:54:40 +0200
From: Olaf Hering <olaf@aepfle.de>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Message-ID: <20120911185440.GA21566@aepfle.de>
References: <20559.28978.688776.985508@mariner.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20559.28978.688776.985508@mariner.uk.xensource.com>
User-Agent: Mutt/1.5.21.rev5555 (2012-07-20)
Cc: Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v2] libxl: Fix missing dependency in api
	check rule
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Sep 11, Ian Jackson wrote:

> Without this, the api check cpp run might happen before the various
> autogenerated files which are #include by libxl.h are ready.

The package still builds fine with this patch.

Tested-by: Olaf Hering <olaf@aepfle.de>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 11 18:54:59 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 2012 18: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 1TBVbg-0003s3-LC; Tue, 11 Sep 2012 18:54: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 1TBVbf-0003rw-Ho
	for xen-devel@lists.xen.org; Tue, 11 Sep 2012 18:54:43 +0000
Received: from [85.158.139.83:41504] by server-2.bemta-5.messagelabs.com id
	7E/3E-11456-2F88F405; Tue, 11 Sep 2012 18:54:42 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-14.tower-182.messagelabs.com!1347389681!25655555!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiA0MjU4NDk=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiA0MjU4NDk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23436 invoked from network); 11 Sep 2012 18:54:42 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-14.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 11 Sep 2012 18:54:42 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFGjC0PG1RG
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-082-188.pools.arcor-ip.net [88.65.82.188])
	by smtp.strato.de (jored mo22) (RZmta 30.14 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id R0015ao8BI3o1n ;
	Tue, 11 Sep 2012 20:54:41 +0200 (CEST)
Received: by probook.site (Postfix, from userid 1000)
	id E790E183AD; Tue, 11 Sep 2012 20:54:40 +0200 (CEST)
Date: Tue, 11 Sep 2012 20:54:40 +0200
From: Olaf Hering <olaf@aepfle.de>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Message-ID: <20120911185440.GA21566@aepfle.de>
References: <20559.28978.688776.985508@mariner.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20559.28978.688776.985508@mariner.uk.xensource.com>
User-Agent: Mutt/1.5.21.rev5555 (2012-07-20)
Cc: Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v2] libxl: Fix missing dependency in api
	check rule
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Sep 11, Ian Jackson wrote:

> Without this, the api check cpp run might happen before the various
> autogenerated files which are #include by libxl.h are ready.

The package still builds fine with this patch.

Tested-by: Olaf Hering <olaf@aepfle.de>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 11 19:00:52 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 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 1TBVhK-00049Z-Jn; Tue, 11 Sep 2012 19:00:34 +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 1TBVhI-00049U-Rs
	for xen-devel@lists.xen.org; Tue, 11 Sep 2012 19:00:33 +0000
Received: from [85.158.139.83:3935] by server-6.bemta-5.messagelabs.com id
	6C/F8-21336-05A8F405; Tue, 11 Sep 2012 19:00:32 +0000
X-Env-Sender: msw@amazon.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1347390030!25971126!1
X-Originating-IP: [72.21.198.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNzIuMjEuMTk4LjI1ID0+IDE3NDU5MQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32675 invoked from network); 11 Sep 2012 19:00:31 -0000
Received: from smtp-fw-4101.amazon.com (HELO smtp-fw-4101.amazon.com)
	(72.21.198.25)
	by server-7.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Sep 2012 19:00:31 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=amazon.com; i=msw@amazon.com; q=dns/txt; s=rte02;
	t=1347390031; x=1378926031;
	h=date:from:to:cc:subject:message-id:references:
	mime-version:in-reply-to;
	bh=f1KE5tDsjR2OWQ/Dk7TkuddXelLic+aTHR00eN/xHTA=;
	b=NFWk4KHtG1x4+WqsNauMJ8Zgkoso+4Isx2qmHECe03m8BV8jarauECu5
	fVl1LYeVLBc2jbfkupoK5BMd3lXkzg==;
X-IronPort-AV: E=Sophos;i="4.80,406,1344211200"; d="scan'208";a="794899753"
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; 11 Sep 2012 19:00:28 +0000
Received: from ex10-hub-9001.ant.amazon.com (ex10-hub-9001.ant.amazon.com
	[10.185.137.58])
	by smtp-in-9001.sea19.amazon.com (8.13.8/8.13.8) with ESMTP id
	q8BJ0R3i003551
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL);
	Tue, 11 Sep 2012 19:00:27 GMT
Received: from u002268147cd4502c336d.ant.amazon.com (10.224.80.42) by
	ex10-hub-9001.ant.amazon.com (10.185.137.58) with Microsoft SMTP Server
	id 14.2.247.3; Tue, 11 Sep 2012 12:00:13 -0700
Received: by u002268147cd4502c336d.ant.amazon.com (sSMTP sendmail emulation); 
	Tue, 11 Sep 2012 12:00:15 -0700
Date: Tue, 11 Sep 2012 12:00:15 -0700
From: Matt Wilson <msw@amazon.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120911190013.GA3375@u002268147cd4502c336d.ant.amazon.com>
References: <patchbomb.1346992557@u002268147cd4502c336d.ant.amazon.com>
	<3b3582f4dc423daa8040.1346992558@u002268147cd4502c336d.ant.amazon.com>
	<1347293350.5305.113.camel@zakaz.uk.xensource.com>
	<20120910204635.GA32584@u002268147cd4502c336d.ant.amazon.com>
	<1347350050.10570.100.camel@dagon.hellion.org.uk>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1347350050.10570.100.camel@dagon.hellion.org.uk>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 1 of 2 v3] tools: check for documentation
 generation tools at configure 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 Tue, Sep 11, 2012 at 08:54:10AM +0100, Ian Campbell wrote:
> > 
> > Yea, that could be better. Though I kind of like that it shows the
> > programs that were checked. It'd look like:
> >  
> >  markdown markdown_py is not available so some documentation won't be built
> > 
> > Maybe just drop 'is' to avoid the verb mismatch.
> 
> Or "m4_tolower($1) ($2) is not available ..."? (properly m4 quoted by
> someone who knows what they are doing, of course ;-))

Right, so the desired output would be: 
  markdown (markdown markdown_py) is not available so some documentation won't be built

I can work on that, but it'll probably be a few days before I can get
back to it.

Matt


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 11 19:00:52 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 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 1TBVhK-00049Z-Jn; Tue, 11 Sep 2012 19:00:34 +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 1TBVhI-00049U-Rs
	for xen-devel@lists.xen.org; Tue, 11 Sep 2012 19:00:33 +0000
Received: from [85.158.139.83:3935] by server-6.bemta-5.messagelabs.com id
	6C/F8-21336-05A8F405; Tue, 11 Sep 2012 19:00:32 +0000
X-Env-Sender: msw@amazon.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1347390030!25971126!1
X-Originating-IP: [72.21.198.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNzIuMjEuMTk4LjI1ID0+IDE3NDU5MQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32675 invoked from network); 11 Sep 2012 19:00:31 -0000
Received: from smtp-fw-4101.amazon.com (HELO smtp-fw-4101.amazon.com)
	(72.21.198.25)
	by server-7.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Sep 2012 19:00:31 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=amazon.com; i=msw@amazon.com; q=dns/txt; s=rte02;
	t=1347390031; x=1378926031;
	h=date:from:to:cc:subject:message-id:references:
	mime-version:in-reply-to;
	bh=f1KE5tDsjR2OWQ/Dk7TkuddXelLic+aTHR00eN/xHTA=;
	b=NFWk4KHtG1x4+WqsNauMJ8Zgkoso+4Isx2qmHECe03m8BV8jarauECu5
	fVl1LYeVLBc2jbfkupoK5BMd3lXkzg==;
X-IronPort-AV: E=Sophos;i="4.80,406,1344211200"; d="scan'208";a="794899753"
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; 11 Sep 2012 19:00:28 +0000
Received: from ex10-hub-9001.ant.amazon.com (ex10-hub-9001.ant.amazon.com
	[10.185.137.58])
	by smtp-in-9001.sea19.amazon.com (8.13.8/8.13.8) with ESMTP id
	q8BJ0R3i003551
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL);
	Tue, 11 Sep 2012 19:00:27 GMT
Received: from u002268147cd4502c336d.ant.amazon.com (10.224.80.42) by
	ex10-hub-9001.ant.amazon.com (10.185.137.58) with Microsoft SMTP Server
	id 14.2.247.3; Tue, 11 Sep 2012 12:00:13 -0700
Received: by u002268147cd4502c336d.ant.amazon.com (sSMTP sendmail emulation); 
	Tue, 11 Sep 2012 12:00:15 -0700
Date: Tue, 11 Sep 2012 12:00:15 -0700
From: Matt Wilson <msw@amazon.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120911190013.GA3375@u002268147cd4502c336d.ant.amazon.com>
References: <patchbomb.1346992557@u002268147cd4502c336d.ant.amazon.com>
	<3b3582f4dc423daa8040.1346992558@u002268147cd4502c336d.ant.amazon.com>
	<1347293350.5305.113.camel@zakaz.uk.xensource.com>
	<20120910204635.GA32584@u002268147cd4502c336d.ant.amazon.com>
	<1347350050.10570.100.camel@dagon.hellion.org.uk>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1347350050.10570.100.camel@dagon.hellion.org.uk>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 1 of 2 v3] tools: check for documentation
 generation tools at configure 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 Tue, Sep 11, 2012 at 08:54:10AM +0100, Ian Campbell wrote:
> > 
> > Yea, that could be better. Though I kind of like that it shows the
> > programs that were checked. It'd look like:
> >  
> >  markdown markdown_py is not available so some documentation won't be built
> > 
> > Maybe just drop 'is' to avoid the verb mismatch.
> 
> Or "m4_tolower($1) ($2) is not available ..."? (properly m4 quoted by
> someone who knows what they are doing, of course ;-))

Right, so the desired output would be: 
  markdown (markdown markdown_py) is not available so some documentation won't be built

I can work on that, but it'll probably be a few days before I can get
back to it.

Matt


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 11 19:16:34 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 2012 19: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 1TBVwY-0004Pe-Nn; Tue, 11 Sep 2012 19:16:18 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <bunkertor@tiscali.it>) id 1TBVwX-0004PZ-H1
	for xen-devel@lists.xen.org; Tue, 11 Sep 2012 19:16:17 +0000
Received: from [85.158.143.99:18565] by server-1.bemta-4.messagelabs.com id
	EC/C3-12504-00E8F405; Tue, 11 Sep 2012 19:16:16 +0000
X-Env-Sender: bunkertor@tiscali.it
X-Msg-Ref: server-4.tower-216.messagelabs.com!1347390976!24521691!1
X-Originating-IP: [213.205.33.246]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjEzLjIwNS4zMy4yNDYgPT4gMjM0MTQ=\n,
	ML_RADAR_SPEW_LINKS_14,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5683 invoked from network); 11 Sep 2012 19:16:16 -0000
Received: from michael.mail.tiscali.it (HELO michael.mail.tiscali.it)
	(213.205.33.246) by server-4.tower-216.messagelabs.com with SMTP;
	11 Sep 2012 19:16:16 -0000
Received: from [172.16.1.180] ([78.13.187.117])
	by michael.mail.tiscali.it with 
	id xvGF1j00r2YQQhq01vGFsB; Tue, 11 Sep 2012 21:16:16 +0200
Message-ID: <504F8DFF.9050208@tiscali.it>
Date: Tue, 11 Sep 2012 21:16:15 +0200
From: bunkertor <bunkertor@tiscali.it>
User-Agent: Mozilla/5.0 (Windows NT 5.1;
	rv:11.0) Gecko/20120327 Thunderbird/11.0.1
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <504E10DA.6040603@tiscali.it>
	<504F11E6020000780009A73E@nat28.tlf.novell.com>
In-Reply-To: <504F11E6020000780009A73E@nat28.tlf.novell.com>
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] grub error 28
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
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

Il 11/09/2012 10.26, Jan Beulich ha scritto:
>>>> On 10.09.12 at 18:10, bunkertor<bunkertor@tiscali.it>  wrote:
>> i compiled by myself xen-unstable from hg repo (changeset:
>> 25835:c70d70d85306)
>> but i'm facing a problem when i try to boot with xen kernel: Error 28
>> Selected item can not fit into memory.
>> i'm newbie and i cannot understand where i fail...
> Did you ever successfully run Xen on that system?

first time, hardware is brandnew.

>>       GNU GRUB  version 0.97  (640K lower / 3072K upper memory)
> Is the very small upper memory value perhaps causing your
> problem (i.e. are you dealing with a GrUB issue rather than a
> Xen one)? Admittedly I don't know what values GrUB would
> display normally, but the E820 map you presented looks
> quite unusual, so I wouldn't be surprised if that caused
> problems.
>
>>    [ Minimal BASH-like line editing is supported.  For the first word, TAB
>>      lists possible command completions.  Anywhere else TAB lists the
>> possible
>>      completions of a device/filename.]
>> grub>  root (hd0,0)
>> root (hd0,0)
>>    Filesystem type is ext2fs, partition type 0x83
>> grub>  kernel /xen.gz
>> kernel /xen.gz
>>      [Multiboot-elf,<0x964000:0x1a6db8:0x54248>(bad)
>>
>> Error 28: Selected item cannot fit into memory
> > From this, it pretty clearly is the (relatively small) hypervisor
> image itself.
>
> Jan
>
>
i solved with grub2 (from fedora16), installing last changeset of 
xen-unstable and konrad kernel.

============================================================================================================
[root@xen-02 ~]# xl info
host                   : xen-02
release                : 3.5.0+
version                : #1 SMP Tue Sep 11 19:40:37 CEST 2012
machine                : x86_64
nr_cpus                : 4
max_cpu_id             : 3
nr_nodes               : 1
cores_per_socket       : 4
threads_per_core       : 1
cpu_mhz                : 3093
hw_caps                : 
bfebfbff:28100800:00000000:00003f40:17bae3ff:00000000:00000001:00000000
virt_caps              : hvm
total_memory           : 16083
free_memory            : 13853
sharing_freed_memory   : 0
sharing_used_memory    : 0
free_cpus              : 0
xen_major              : 4
xen_minor              : 3
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          : Mon Sep 10 11:13:56 2012 +0100 25841:7d770de90b7f
xen_commandline        : placeholder dom0_mem=2048M
cc_compiler            : gcc (GCC) 4.6.3 20120306 (Red Hat 4.6.3-2)
cc_compile_by          : root
cc_compile_domain      :
cc_compile_date        : Tue Sep 11 19:19:34 CEST 2012
xend_config_format     : 4
[root@xen-02 ~]# cat /etc/redhat-release
Fedora release 16 (Verne)
[root@xen-02 ~]#
[root@xen-02 ~]# uptime
  20:57:28 up 5 min,  1 user,  load average: 0.01, 0.08, 0.05
[root@xen-02 ~]#
[root@xen-02 ~]# ls -ltrh /boot
totale 136M
-rwxr-xr-x. 1 root root 4,6M 23 ago 20.08 vmlinuz-3.4.9-2.fc16.x86_64
-rw-------. 1 root root 2,4M 23 ago 20.08 System.map-3.4.9-2.fc16.x86_64
-rw-r--r--. 1 root root 118K 23 ago 20.08 config-3.4.9-2.fc16.x86_64
drwx------. 2 root root  12K 11 set 18.37 lost+found
-rw-r--r--. 1 root root  13M 11 set 18.43 initramfs-3.4.9-2.fc16.x86_64.img
-rw-r--r--  1 root root  13M 11 set 19.19 xen-syms-4.3-unstable
lrwxrwxrwx  1 root root   19 11 set 19.19 xen.gz -> xen-4.3-unstable.gz
lrwxrwxrwx  1 root root   19 11 set 19.19 xen-4.gz -> xen-4.3-unstable.gz
-rw-r--r--  1 root root 779K 11 set 19.19 xen-4.3-unstable.gz
lrwxrwxrwx  1 root root   19 11 set 19.19 xen-4.3.gz -> xen-4.3-unstable.gz
-rw-r--r--  1 root root 119K 11 set 19.37 config-3.5.0
-rw-r--r--  1 root root 2,4M 11 set 19.40 System.map-3.5.0
-rw-r--r--  1 root root 4,7M 11 set 19.41 vmlinuz-3.5.0
-rw-r--r--  1 root root  96M 11 set 20.08 initramfs-3.5.0.img
drwxr-xr-x. 3 root root 7,0K 11 set 20.51 grub2
[root@xen-02 ~]#
============================================================================================================

i've noticed that booting from efi with standard linux distributions i 
can see more upper memory; but i'm not so close with it, so further test 
is needed.

thanks to all for help and patience
regards.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 11 19:16:34 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 2012 19: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 1TBVwY-0004Pe-Nn; Tue, 11 Sep 2012 19:16:18 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <bunkertor@tiscali.it>) id 1TBVwX-0004PZ-H1
	for xen-devel@lists.xen.org; Tue, 11 Sep 2012 19:16:17 +0000
Received: from [85.158.143.99:18565] by server-1.bemta-4.messagelabs.com id
	EC/C3-12504-00E8F405; Tue, 11 Sep 2012 19:16:16 +0000
X-Env-Sender: bunkertor@tiscali.it
X-Msg-Ref: server-4.tower-216.messagelabs.com!1347390976!24521691!1
X-Originating-IP: [213.205.33.246]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjEzLjIwNS4zMy4yNDYgPT4gMjM0MTQ=\n,
	ML_RADAR_SPEW_LINKS_14,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5683 invoked from network); 11 Sep 2012 19:16:16 -0000
Received: from michael.mail.tiscali.it (HELO michael.mail.tiscali.it)
	(213.205.33.246) by server-4.tower-216.messagelabs.com with SMTP;
	11 Sep 2012 19:16:16 -0000
Received: from [172.16.1.180] ([78.13.187.117])
	by michael.mail.tiscali.it with 
	id xvGF1j00r2YQQhq01vGFsB; Tue, 11 Sep 2012 21:16:16 +0200
Message-ID: <504F8DFF.9050208@tiscali.it>
Date: Tue, 11 Sep 2012 21:16:15 +0200
From: bunkertor <bunkertor@tiscali.it>
User-Agent: Mozilla/5.0 (Windows NT 5.1;
	rv:11.0) Gecko/20120327 Thunderbird/11.0.1
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <504E10DA.6040603@tiscali.it>
	<504F11E6020000780009A73E@nat28.tlf.novell.com>
In-Reply-To: <504F11E6020000780009A73E@nat28.tlf.novell.com>
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] grub error 28
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
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

Il 11/09/2012 10.26, Jan Beulich ha scritto:
>>>> On 10.09.12 at 18:10, bunkertor<bunkertor@tiscali.it>  wrote:
>> i compiled by myself xen-unstable from hg repo (changeset:
>> 25835:c70d70d85306)
>> but i'm facing a problem when i try to boot with xen kernel: Error 28
>> Selected item can not fit into memory.
>> i'm newbie and i cannot understand where i fail...
> Did you ever successfully run Xen on that system?

first time, hardware is brandnew.

>>       GNU GRUB  version 0.97  (640K lower / 3072K upper memory)
> Is the very small upper memory value perhaps causing your
> problem (i.e. are you dealing with a GrUB issue rather than a
> Xen one)? Admittedly I don't know what values GrUB would
> display normally, but the E820 map you presented looks
> quite unusual, so I wouldn't be surprised if that caused
> problems.
>
>>    [ Minimal BASH-like line editing is supported.  For the first word, TAB
>>      lists possible command completions.  Anywhere else TAB lists the
>> possible
>>      completions of a device/filename.]
>> grub>  root (hd0,0)
>> root (hd0,0)
>>    Filesystem type is ext2fs, partition type 0x83
>> grub>  kernel /xen.gz
>> kernel /xen.gz
>>      [Multiboot-elf,<0x964000:0x1a6db8:0x54248>(bad)
>>
>> Error 28: Selected item cannot fit into memory
> > From this, it pretty clearly is the (relatively small) hypervisor
> image itself.
>
> Jan
>
>
i solved with grub2 (from fedora16), installing last changeset of 
xen-unstable and konrad kernel.

============================================================================================================
[root@xen-02 ~]# xl info
host                   : xen-02
release                : 3.5.0+
version                : #1 SMP Tue Sep 11 19:40:37 CEST 2012
machine                : x86_64
nr_cpus                : 4
max_cpu_id             : 3
nr_nodes               : 1
cores_per_socket       : 4
threads_per_core       : 1
cpu_mhz                : 3093
hw_caps                : 
bfebfbff:28100800:00000000:00003f40:17bae3ff:00000000:00000001:00000000
virt_caps              : hvm
total_memory           : 16083
free_memory            : 13853
sharing_freed_memory   : 0
sharing_used_memory    : 0
free_cpus              : 0
xen_major              : 4
xen_minor              : 3
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          : Mon Sep 10 11:13:56 2012 +0100 25841:7d770de90b7f
xen_commandline        : placeholder dom0_mem=2048M
cc_compiler            : gcc (GCC) 4.6.3 20120306 (Red Hat 4.6.3-2)
cc_compile_by          : root
cc_compile_domain      :
cc_compile_date        : Tue Sep 11 19:19:34 CEST 2012
xend_config_format     : 4
[root@xen-02 ~]# cat /etc/redhat-release
Fedora release 16 (Verne)
[root@xen-02 ~]#
[root@xen-02 ~]# uptime
  20:57:28 up 5 min,  1 user,  load average: 0.01, 0.08, 0.05
[root@xen-02 ~]#
[root@xen-02 ~]# ls -ltrh /boot
totale 136M
-rwxr-xr-x. 1 root root 4,6M 23 ago 20.08 vmlinuz-3.4.9-2.fc16.x86_64
-rw-------. 1 root root 2,4M 23 ago 20.08 System.map-3.4.9-2.fc16.x86_64
-rw-r--r--. 1 root root 118K 23 ago 20.08 config-3.4.9-2.fc16.x86_64
drwx------. 2 root root  12K 11 set 18.37 lost+found
-rw-r--r--. 1 root root  13M 11 set 18.43 initramfs-3.4.9-2.fc16.x86_64.img
-rw-r--r--  1 root root  13M 11 set 19.19 xen-syms-4.3-unstable
lrwxrwxrwx  1 root root   19 11 set 19.19 xen.gz -> xen-4.3-unstable.gz
lrwxrwxrwx  1 root root   19 11 set 19.19 xen-4.gz -> xen-4.3-unstable.gz
-rw-r--r--  1 root root 779K 11 set 19.19 xen-4.3-unstable.gz
lrwxrwxrwx  1 root root   19 11 set 19.19 xen-4.3.gz -> xen-4.3-unstable.gz
-rw-r--r--  1 root root 119K 11 set 19.37 config-3.5.0
-rw-r--r--  1 root root 2,4M 11 set 19.40 System.map-3.5.0
-rw-r--r--  1 root root 4,7M 11 set 19.41 vmlinuz-3.5.0
-rw-r--r--  1 root root  96M 11 set 20.08 initramfs-3.5.0.img
drwxr-xr-x. 3 root root 7,0K 11 set 20.51 grub2
[root@xen-02 ~]#
============================================================================================================

i've noticed that booting from efi with standard linux distributions i 
can see more upper memory; but i'm not so close with it, so further test 
is needed.

thanks to all for help and patience
regards.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 11 21:28:35 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 2012 21: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 1TBY00-00054i-PN; Tue, 11 Sep 2012 21:28:00 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <daniel.lezcano@linaro.org>) id 1TBXzz-00054d-AB
	for xen-devel@lists.xensource.com; Tue, 11 Sep 2012 21:27:59 +0000
Received: from [85.158.143.35:48690] by server-2.bemta-4.messagelabs.com id
	BC/20-21239-EDCAF405; Tue, 11 Sep 2012 21:27:58 +0000
X-Env-Sender: daniel.lezcano@linaro.org
X-Msg-Ref: server-15.tower-21.messagelabs.com!1347398877!14177969!1
X-Originating-IP: [74.125.83.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32720 invoked from network); 11 Sep 2012 21:27:58 -0000
Received: from mail-ee0-f43.google.com (HELO mail-ee0-f43.google.com)
	(74.125.83.43)
	by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Sep 2012 21:27:58 -0000
Received: by eekd4 with SMTP id d4so842101eek.30
	for <xen-devel@lists.xensource.com>;
	Tue, 11 Sep 2012 14:27:57 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=message-id:date:from:user-agent:mime-version:to:cc:subject
	:references:in-reply-to:content-type:content-transfer-encoding
	:x-gm-message-state;
	bh=WsztsTSG4TAkfFE+2Aw+1xWn+x/hRCe69FL480eWjUs=;
	b=Z/lV3oc/QyDHs3Y0lSOWdh5gFLNRzNqTWuEWH3W+BF4kUtFtC/hn/X7GqceanSeU6S
	HTS3dI7KDaXvvMxgsSETubtb1MAnbAi1srch7ycUSXkEG2QsNr3GysTXn7QJAdelvjxw
	s7RKNQki1hpv/IiEuRGXY1h+SPdqXWaGj28r0EPDDLWdvNyGtHSOYrg5vK3lG/ozI9j6
	h526nfymK5vgbqfabbIJg/VwXjelKZwiRiCgBG5Yr2tYN2JQq5kFCPtucD3+p9dk/EhI
	iZRiSI5Gz8sjD0pYBMQbNTnOWFSjauYITKNPZ1CjqXTe6twO+ZR5JC4dkPnFFE0wYAgA
	2vBw==
Received: by 10.14.179.136 with SMTP id h8mr27674152eem.6.1347398877518;
	Tue, 11 Sep 2012 14:27:57 -0700 (PDT)
Received: from [192.168.1.11] (AToulouse-651-1-110-236.w109-222.abo.wanadoo.fr.
	[109.222.197.236])
	by mx.google.com with ESMTPS id r45sm50526914eem.6.2012.09.11.14.27.54
	(version=SSLv3 cipher=OTHER); Tue, 11 Sep 2012 14:27:56 -0700 (PDT)
Message-ID: <504FACD9.4020108@linaro.org>
Date: Tue, 11 Sep 2012 23:27:53 +0200
From: Daniel Lezcano <daniel.lezcano@linaro.org>
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:12.0) Gecko/20120430 Thunderbird/12.0.1
MIME-Version: 1.0
To: John Stultz <john.stultz@linaro.org>
References: <1343164349-28550-1-git-send-email-daniel.lezcano@linaro.org>
	<201209062204.11288.rjw@sisk.pl> <50490920.9070204@linaro.org>
	<201209062318.42874.rjw@sisk.pl> <504A02BD.4000805@linaro.org>
	<504A2D73.3010702@linaro.org> <504A68A0.7010907@linaro.org>
	<504E1FE5.6090502@linaro.org> <504E4343.5070004@linaro.org>
	<504E8372.20904@linaro.org>
In-Reply-To: <504E8372.20904@linaro.org>
X-Gm-Message-State: ALoCoQlqnKUzEClWhTo1ALEQC+rjAlI2FoVLe6Yn2QYYXI3u3nHsShIivO+zeCsV2+85aCGD4tR5
Cc: prarit@redhat.com, xen-devel@lists.xensource.com,
	linaro-dev@lists.linaro.org, Peter Zijlstra <a.p.zijlstra@chello.nl>,
	linux-pm@vger.kernel.org, Frederic Weisbecker <fweisbec@gmail.com>,
	richardcochran@gmail.com, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	"Rafael J. Wysocki" <rjw@sisk.pl>, linux-acpi@vger.kernel.org,
	Thomas Gleixner <tglx@linutronix.de>, mingo@kernel.org, lenb@kernel.org
Subject: Re: [Xen-devel] CONFIG_NO_HZ + CONFIG_CPU_IDLE freeze the system
 (Was Re: [PATCH] acpi : remove power from acpi_processor_cx structure)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gMDkvMTEvMjAxMiAwMjoxOCBBTSwgSm9obiBTdHVsdHogd3JvdGU6Cj4gT24gMDkvMTAvMjAx
MiAxMjo0NSBQTSwgRGFuaWVsIExlemNhbm8gd3JvdGU6Cj4+IE9uIDA5LzEwLzIwMTIgMDc6MTQg
UE0sIEpvaG4gU3R1bHR6IHdyb3RlOgo+Pj4gSW4gdGhlIG1lYW50aW1lLCBJJ2xsIHRyeSB0byBy
ZXByb2R1Y2Ugb24gbXkgVDYxLiBJZiB5b3UgY291bGQgc2VuZCBtZQo+Pj4geW91ciAuY29uZmln
LCBJJ2QgYXBwcmVjaWF0ZSBpdC4KPj4gaHR0cDovL3Bhc3RlYmluLmNvbS9xU3hxZmRESwo+Pgo+
PiBUaGUgaGVhZGVyIG9mIHRoZSBjb25maWcgZmlsZSBzaG93cyBmb3IgYSB2My41LXJjNyBiZWNh
dXNlIGl0IGlzIHRoZQo+PiByZXN1bHQgb2YgdGhlIGdpdC1iaXNlY3QuIElmIHlvdSBrZWVwIHRo
aXMgY29uZmlnIGZpbGUgZm9yIHRoZSBsYXRlc3QKPj4ga2VybmVsIHRoYXQgc2hvdWxkIHJlcHJv
ZHVjZSB0aGUgcHJvYmxlbS4KPj4KPj4gTGV0IG1lIGtub3cgaWYgeW91IHdlcmUgYWJsZSB0byBy
ZXByb2R1Y2UgdGhlIHByb2JsZW0uCj4gR3JlYXQhIFdpdGggdGhpcyBJIHdhcyBhYmxlIHRvIHF1
aWNrbHkgcmVwcm9kdWNlIHRoZSBwcm9ibGVtIGFuZCBJIHRoaW5rCj4gSSBoYXZlIGEgZml4Lgo+
IAo+IFdvdWxkIHlvdSBtaW5kIHRlc3RpbmcgdGhlIGZvbGxvd2luZyBwYXRjaD8gSXQgc2VlbXMg
dG8gcmVzb2x2ZSB0aGUKPiBpc3N1ZSwgYnV0IEkndmUgbm90IHlldCBydW4gaXQgdGhyb3VnaCBt
eSB0ZXN0IHN1aXRlIHRvIG1ha2Ugc3VyZSBpdAo+IGRpZG4ndCBicmVhayBhbnl0aGluZyBlbHNl
Lgo+IAo+IElmIGJvdGggeW91ciBhbmQgbXkgdGVzdGluZyBjb21lcyBiYWNrIG9rLCBJJ2xsIHN1
Ym1pdCBpdCB0byBUaG9tYXMuCgpTb3VuZHMgbGlrZSB0aGlzIHNvbHZlcyB0aGUgcHJvYmxlbS4g
V2l0aG91dCBlbm91Z2ggYmFja2dyb3VuZCBvbiB0aW1lcnMKaW4gZ2VuZXJhbCwgSSBkb24ndCBo
YXZlIGFuIG9waW5pb24gYWJvdXQgdGhlIHBhdGNoIGl0c2VsZiBidXQgSSBjYW4KY29uZmlybSB0
aGUgaXNzdWUgaXMgbm8gbG9uZ2VyIG9jY3VycmluZy4KClRoYW5rcwogIC0tIERhbmllbAoKLS0g
CiA8aHR0cDovL3d3dy5saW5hcm8ub3JnLz4gTGluYXJvLm9yZyDilIIgT3BlbiBzb3VyY2Ugc29m
dHdhcmUgZm9yIEFSTSBTb0NzCgpGb2xsb3cgTGluYXJvOiAgPGh0dHA6Ly93d3cuZmFjZWJvb2su
Y29tL3BhZ2VzL0xpbmFybz4gRmFjZWJvb2sgfAo8aHR0cDovL3R3aXR0ZXIuY29tLyMhL2xpbmFy
b29yZz4gVHdpdHRlciB8CjxodHRwOi8vd3d3LmxpbmFyby5vcmcvbGluYXJvLWJsb2cvPiBCbG9n
CgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRl
dmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwOi8vbGlzdHMueGVu
Lm9yZy94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xen.org Tue Sep 11 21:28:35 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 2012 21: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 1TBY00-00054i-PN; Tue, 11 Sep 2012 21:28:00 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <daniel.lezcano@linaro.org>) id 1TBXzz-00054d-AB
	for xen-devel@lists.xensource.com; Tue, 11 Sep 2012 21:27:59 +0000
Received: from [85.158.143.35:48690] by server-2.bemta-4.messagelabs.com id
	BC/20-21239-EDCAF405; Tue, 11 Sep 2012 21:27:58 +0000
X-Env-Sender: daniel.lezcano@linaro.org
X-Msg-Ref: server-15.tower-21.messagelabs.com!1347398877!14177969!1
X-Originating-IP: [74.125.83.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32720 invoked from network); 11 Sep 2012 21:27:58 -0000
Received: from mail-ee0-f43.google.com (HELO mail-ee0-f43.google.com)
	(74.125.83.43)
	by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Sep 2012 21:27:58 -0000
Received: by eekd4 with SMTP id d4so842101eek.30
	for <xen-devel@lists.xensource.com>;
	Tue, 11 Sep 2012 14:27:57 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=message-id:date:from:user-agent:mime-version:to:cc:subject
	:references:in-reply-to:content-type:content-transfer-encoding
	:x-gm-message-state;
	bh=WsztsTSG4TAkfFE+2Aw+1xWn+x/hRCe69FL480eWjUs=;
	b=Z/lV3oc/QyDHs3Y0lSOWdh5gFLNRzNqTWuEWH3W+BF4kUtFtC/hn/X7GqceanSeU6S
	HTS3dI7KDaXvvMxgsSETubtb1MAnbAi1srch7ycUSXkEG2QsNr3GysTXn7QJAdelvjxw
	s7RKNQki1hpv/IiEuRGXY1h+SPdqXWaGj28r0EPDDLWdvNyGtHSOYrg5vK3lG/ozI9j6
	h526nfymK5vgbqfabbIJg/VwXjelKZwiRiCgBG5Yr2tYN2JQq5kFCPtucD3+p9dk/EhI
	iZRiSI5Gz8sjD0pYBMQbNTnOWFSjauYITKNPZ1CjqXTe6twO+ZR5JC4dkPnFFE0wYAgA
	2vBw==
Received: by 10.14.179.136 with SMTP id h8mr27674152eem.6.1347398877518;
	Tue, 11 Sep 2012 14:27:57 -0700 (PDT)
Received: from [192.168.1.11] (AToulouse-651-1-110-236.w109-222.abo.wanadoo.fr.
	[109.222.197.236])
	by mx.google.com with ESMTPS id r45sm50526914eem.6.2012.09.11.14.27.54
	(version=SSLv3 cipher=OTHER); Tue, 11 Sep 2012 14:27:56 -0700 (PDT)
Message-ID: <504FACD9.4020108@linaro.org>
Date: Tue, 11 Sep 2012 23:27:53 +0200
From: Daniel Lezcano <daniel.lezcano@linaro.org>
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:12.0) Gecko/20120430 Thunderbird/12.0.1
MIME-Version: 1.0
To: John Stultz <john.stultz@linaro.org>
References: <1343164349-28550-1-git-send-email-daniel.lezcano@linaro.org>
	<201209062204.11288.rjw@sisk.pl> <50490920.9070204@linaro.org>
	<201209062318.42874.rjw@sisk.pl> <504A02BD.4000805@linaro.org>
	<504A2D73.3010702@linaro.org> <504A68A0.7010907@linaro.org>
	<504E1FE5.6090502@linaro.org> <504E4343.5070004@linaro.org>
	<504E8372.20904@linaro.org>
In-Reply-To: <504E8372.20904@linaro.org>
X-Gm-Message-State: ALoCoQlqnKUzEClWhTo1ALEQC+rjAlI2FoVLe6Yn2QYYXI3u3nHsShIivO+zeCsV2+85aCGD4tR5
Cc: prarit@redhat.com, xen-devel@lists.xensource.com,
	linaro-dev@lists.linaro.org, Peter Zijlstra <a.p.zijlstra@chello.nl>,
	linux-pm@vger.kernel.org, Frederic Weisbecker <fweisbec@gmail.com>,
	richardcochran@gmail.com, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	"Rafael J. Wysocki" <rjw@sisk.pl>, linux-acpi@vger.kernel.org,
	Thomas Gleixner <tglx@linutronix.de>, mingo@kernel.org, lenb@kernel.org
Subject: Re: [Xen-devel] CONFIG_NO_HZ + CONFIG_CPU_IDLE freeze the system
 (Was Re: [PATCH] acpi : remove power from acpi_processor_cx structure)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gMDkvMTEvMjAxMiAwMjoxOCBBTSwgSm9obiBTdHVsdHogd3JvdGU6Cj4gT24gMDkvMTAvMjAx
MiAxMjo0NSBQTSwgRGFuaWVsIExlemNhbm8gd3JvdGU6Cj4+IE9uIDA5LzEwLzIwMTIgMDc6MTQg
UE0sIEpvaG4gU3R1bHR6IHdyb3RlOgo+Pj4gSW4gdGhlIG1lYW50aW1lLCBJJ2xsIHRyeSB0byBy
ZXByb2R1Y2Ugb24gbXkgVDYxLiBJZiB5b3UgY291bGQgc2VuZCBtZQo+Pj4geW91ciAuY29uZmln
LCBJJ2QgYXBwcmVjaWF0ZSBpdC4KPj4gaHR0cDovL3Bhc3RlYmluLmNvbS9xU3hxZmRESwo+Pgo+
PiBUaGUgaGVhZGVyIG9mIHRoZSBjb25maWcgZmlsZSBzaG93cyBmb3IgYSB2My41LXJjNyBiZWNh
dXNlIGl0IGlzIHRoZQo+PiByZXN1bHQgb2YgdGhlIGdpdC1iaXNlY3QuIElmIHlvdSBrZWVwIHRo
aXMgY29uZmlnIGZpbGUgZm9yIHRoZSBsYXRlc3QKPj4ga2VybmVsIHRoYXQgc2hvdWxkIHJlcHJv
ZHVjZSB0aGUgcHJvYmxlbS4KPj4KPj4gTGV0IG1lIGtub3cgaWYgeW91IHdlcmUgYWJsZSB0byBy
ZXByb2R1Y2UgdGhlIHByb2JsZW0uCj4gR3JlYXQhIFdpdGggdGhpcyBJIHdhcyBhYmxlIHRvIHF1
aWNrbHkgcmVwcm9kdWNlIHRoZSBwcm9ibGVtIGFuZCBJIHRoaW5rCj4gSSBoYXZlIGEgZml4Lgo+
IAo+IFdvdWxkIHlvdSBtaW5kIHRlc3RpbmcgdGhlIGZvbGxvd2luZyBwYXRjaD8gSXQgc2VlbXMg
dG8gcmVzb2x2ZSB0aGUKPiBpc3N1ZSwgYnV0IEkndmUgbm90IHlldCBydW4gaXQgdGhyb3VnaCBt
eSB0ZXN0IHN1aXRlIHRvIG1ha2Ugc3VyZSBpdAo+IGRpZG4ndCBicmVhayBhbnl0aGluZyBlbHNl
Lgo+IAo+IElmIGJvdGggeW91ciBhbmQgbXkgdGVzdGluZyBjb21lcyBiYWNrIG9rLCBJJ2xsIHN1
Ym1pdCBpdCB0byBUaG9tYXMuCgpTb3VuZHMgbGlrZSB0aGlzIHNvbHZlcyB0aGUgcHJvYmxlbS4g
V2l0aG91dCBlbm91Z2ggYmFja2dyb3VuZCBvbiB0aW1lcnMKaW4gZ2VuZXJhbCwgSSBkb24ndCBo
YXZlIGFuIG9waW5pb24gYWJvdXQgdGhlIHBhdGNoIGl0c2VsZiBidXQgSSBjYW4KY29uZmlybSB0
aGUgaXNzdWUgaXMgbm8gbG9uZ2VyIG9jY3VycmluZy4KClRoYW5rcwogIC0tIERhbmllbAoKLS0g
CiA8aHR0cDovL3d3dy5saW5hcm8ub3JnLz4gTGluYXJvLm9yZyDilIIgT3BlbiBzb3VyY2Ugc29m
dHdhcmUgZm9yIEFSTSBTb0NzCgpGb2xsb3cgTGluYXJvOiAgPGh0dHA6Ly93d3cuZmFjZWJvb2su
Y29tL3BhZ2VzL0xpbmFybz4gRmFjZWJvb2sgfAo8aHR0cDovL3R3aXR0ZXIuY29tLyMhL2xpbmFy
b29yZz4gVHdpdHRlciB8CjxodHRwOi8vd3d3LmxpbmFyby5vcmcvbGluYXJvLWJsb2cvPiBCbG9n
CgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRl
dmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwOi8vbGlzdHMueGVu
Lm9yZy94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xen.org Tue Sep 11 21:58:29 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 2012 21:58:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TBYT3-0005JB-IC; Tue, 11 Sep 2012 21:58:01 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mukesh.rathor@oracle.com>) id 1TBYT1-0005J6-EX
	for Xen-devel@lists.xensource.com; Tue, 11 Sep 2012 21:57:59 +0000
Received: from [85.158.139.83:29188] by server-12.bemta-5.messagelabs.com id
	7C/AE-18300-6E3BF405; Tue, 11 Sep 2012 21:57:58 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1347400677!27752208!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDc0NDQwMA==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20991 invoked from network); 11 Sep 2012 21:57:58 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-15.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 11 Sep 2012 21:57:58 -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 q8BLvsjv003949
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 11 Sep 2012 21:57: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
	q8BLvsHn027101
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 11 Sep 2012 21:57:54 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
	q8BLvrYs015140; Tue, 11 Sep 2012 16:57:53 -0500
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 11 Sep 2012 14:57:53 -0700
Date: Tue, 11 Sep 2012 14:57:51 -0700
From: Mukesh Rathor <mukesh.rathor@oracle.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120911145751.599b8292@mantra.us.oracle.com>
In-Reply-To: <1347285352.5305.86.camel@zakaz.uk.xensource.com>
References: <20120815175724.3405043a@mantra.us.oracle.com>
	<1347285352.5305.86.camel@zakaz.uk.xensource.com>
Organization: Oracle Corporation
X-Mailer: Claws Mail 3.7.6 (GTK+ 2.18.9; x86_64-redhat-linux-gnu)
Mime-Version: 1.0
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: "Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [RFC PATCH 1/8]: PVH: Basic and preparatory changes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 10 Sep 2012 14:55:52 +0100
Ian Campbell <Ian.Campbell@citrix.com> wrote:

> On Thu, 2012-08-16 at 01:57 +0100, Mukesh Rathor wrote:
> > diff --git a/include/xen/xen.h b/include/xen/xen.h
> > index a164024..e823639 100644
> > --- a/include/xen/xen.h
> > +++ b/include/xen/xen.h
> > @@ -18,6 +18,10 @@ extern enum xen_domain_type xen_domain_type;
> >                                  xen_domain_type == XEN_PV_DOMAIN)
> >  #define xen_hvm_domain()       (xen_domain()
> > &&                        \ xen_domain_type == XEN_HVM_DOMAIN)
> > +/* xen_pv_domain check is necessary as start_info ptr is null in
> > HVM. Also,
> > + * note, xen PVH domain shares lot of HVM code */
> > +#define xen_pvh_domain()       (xen_pv_domain()
> > &&                     \
> > +                               (xen_start_info->flags &
> > SIF_IS_PVINHVM))
> 
> Can I suggest that for the time being this be gated on a new
> CONFIG_XEN_PVH option (I think it's new, I can't find one right now)
> which "depends EXPERIMENTAL".
> 
> We don't want to get into the situation where whatever goes into Linux
> now makes it into a distro (and is enabled) and is subsequently broken
> on top of whatever the final hypervisor side stuff ends up looking
> like. We've done the same for the ARM support for example.
> 
> Ian.

Well, I'm pretty much removing all xen_pv_domain() checks and moving to
other checks, like you guys wanted. This code is pretty intermingled and
can't be ifdef'd easily.

Mukesh

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 11 21:58:29 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 11 Sep 2012 21:58:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TBYT3-0005JB-IC; Tue, 11 Sep 2012 21:58:01 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mukesh.rathor@oracle.com>) id 1TBYT1-0005J6-EX
	for Xen-devel@lists.xensource.com; Tue, 11 Sep 2012 21:57:59 +0000
Received: from [85.158.139.83:29188] by server-12.bemta-5.messagelabs.com id
	7C/AE-18300-6E3BF405; Tue, 11 Sep 2012 21:57:58 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1347400677!27752208!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDc0NDQwMA==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20991 invoked from network); 11 Sep 2012 21:57:58 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-15.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 11 Sep 2012 21:57:58 -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 q8BLvsjv003949
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 11 Sep 2012 21:57: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
	q8BLvsHn027101
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 11 Sep 2012 21:57:54 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
	q8BLvrYs015140; Tue, 11 Sep 2012 16:57:53 -0500
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 11 Sep 2012 14:57:53 -0700
Date: Tue, 11 Sep 2012 14:57:51 -0700
From: Mukesh Rathor <mukesh.rathor@oracle.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120911145751.599b8292@mantra.us.oracle.com>
In-Reply-To: <1347285352.5305.86.camel@zakaz.uk.xensource.com>
References: <20120815175724.3405043a@mantra.us.oracle.com>
	<1347285352.5305.86.camel@zakaz.uk.xensource.com>
Organization: Oracle Corporation
X-Mailer: Claws Mail 3.7.6 (GTK+ 2.18.9; x86_64-redhat-linux-gnu)
Mime-Version: 1.0
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: "Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [RFC PATCH 1/8]: PVH: Basic and preparatory changes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 10 Sep 2012 14:55:52 +0100
Ian Campbell <Ian.Campbell@citrix.com> wrote:

> On Thu, 2012-08-16 at 01:57 +0100, Mukesh Rathor wrote:
> > diff --git a/include/xen/xen.h b/include/xen/xen.h
> > index a164024..e823639 100644
> > --- a/include/xen/xen.h
> > +++ b/include/xen/xen.h
> > @@ -18,6 +18,10 @@ extern enum xen_domain_type xen_domain_type;
> >                                  xen_domain_type == XEN_PV_DOMAIN)
> >  #define xen_hvm_domain()       (xen_domain()
> > &&                        \ xen_domain_type == XEN_HVM_DOMAIN)
> > +/* xen_pv_domain check is necessary as start_info ptr is null in
> > HVM. Also,
> > + * note, xen PVH domain shares lot of HVM code */
> > +#define xen_pvh_domain()       (xen_pv_domain()
> > &&                     \
> > +                               (xen_start_info->flags &
> > SIF_IS_PVINHVM))
> 
> Can I suggest that for the time being this be gated on a new
> CONFIG_XEN_PVH option (I think it's new, I can't find one right now)
> which "depends EXPERIMENTAL".
> 
> We don't want to get into the situation where whatever goes into Linux
> now makes it into a distro (and is enabled) and is subsequently broken
> on top of whatever the final hypervisor side stuff ends up looking
> like. We've done the same for the ARM support for example.
> 
> Ian.

Well, I'm pretty much removing all xen_pv_domain() checks and moving to
other checks, like you guys wanted. This code is pretty intermingled and
can't be ifdef'd easily.

Mukesh

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 12 01:32:54 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Sep 2012 01: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 1TBboT-0002gN-MB; Wed, 12 Sep 2012 01:32:21 +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 1TBboR-0002gI-Qa
	for Xen-devel@lists.xensource.com; Wed, 12 Sep 2012 01:32:20 +0000
Received: from [85.158.143.35:43314] by server-2.bemta-4.messagelabs.com id
	70/9E-21239-326EF405; Wed, 12 Sep 2012 01:32:19 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1347413537!6833819!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDc0NDQwMA==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12898 invoked from network); 12 Sep 2012 01:32:18 -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; 12 Sep 2012 01:32:18 -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 q8C1WEnX022940
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 12 Sep 2012 01:32:14 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
	q8C1WDKo018433
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 12 Sep 2012 01:32:13 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
	q8C1WCxx003734; Tue, 11 Sep 2012 20:32:12 -0500
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 11 Sep 2012 18:32:12 -0700
Date: Tue, 11 Sep 2012 18:32:10 -0700
From: Mukesh Rathor <mukesh.rathor@oracle.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120911183210.5c43f428@mantra.us.oracle.com>
In-Reply-To: <1347372623.5305.170.camel@zakaz.uk.xensource.com>
References: <20120815180716.0049bffe@mantra.us.oracle.com>
	<1347372623.5305.170.camel@zakaz.uk.xensource.com>
Organization: Oracle Corporation
X-Mailer: Claws Mail 3.7.6 (GTK+ 2.18.9; x86_64-redhat-linux-gnu)
Mime-Version: 1.0
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: "Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [RFC PATCH 8/8]: PVH: privcmd changes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 11 Sep 2012 15:10:23 +0100
Ian Campbell <Ian.Campbell@citrix.com> wrote:

> On Thu, 2012-08-16 at 02:07 +0100, Mukesh Rathor wrote:
> > ---
> >  drivers/xen/privcmd.c |   68
> > +	if (rc != 0) {
> > +		pr_warn("%s Could not alloc %d pfns rc:%d\n",
> > __FUNCTION__,
> > +			numpgs, rc);
> > +		kfree(savp->sp_paga);
> > +		kfree(savp);
> > +		return -ENOMEM;
> > +	}
> 
> I've just been building on this patch to make proper mmap foreign
> support on ARM and I was looking for the place which freed this, both
> the pages back to the balloon and then the array itself. There is code
> in privcmd_close which unmaps the P2M, but I can't find the code which
> frees things back to the balloon. Have I missed something?

You are right, I missed the free. Let me revisit it and make some changes.

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 Sep 12 01:32:54 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Sep 2012 01: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 1TBboT-0002gN-MB; Wed, 12 Sep 2012 01:32:21 +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 1TBboR-0002gI-Qa
	for Xen-devel@lists.xensource.com; Wed, 12 Sep 2012 01:32:20 +0000
Received: from [85.158.143.35:43314] by server-2.bemta-4.messagelabs.com id
	70/9E-21239-326EF405; Wed, 12 Sep 2012 01:32:19 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1347413537!6833819!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDc0NDQwMA==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12898 invoked from network); 12 Sep 2012 01:32:18 -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; 12 Sep 2012 01:32:18 -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 q8C1WEnX022940
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 12 Sep 2012 01:32:14 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
	q8C1WDKo018433
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 12 Sep 2012 01:32:13 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
	q8C1WCxx003734; Tue, 11 Sep 2012 20:32:12 -0500
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 11 Sep 2012 18:32:12 -0700
Date: Tue, 11 Sep 2012 18:32:10 -0700
From: Mukesh Rathor <mukesh.rathor@oracle.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120911183210.5c43f428@mantra.us.oracle.com>
In-Reply-To: <1347372623.5305.170.camel@zakaz.uk.xensource.com>
References: <20120815180716.0049bffe@mantra.us.oracle.com>
	<1347372623.5305.170.camel@zakaz.uk.xensource.com>
Organization: Oracle Corporation
X-Mailer: Claws Mail 3.7.6 (GTK+ 2.18.9; x86_64-redhat-linux-gnu)
Mime-Version: 1.0
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: "Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [RFC PATCH 8/8]: PVH: privcmd changes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 11 Sep 2012 15:10:23 +0100
Ian Campbell <Ian.Campbell@citrix.com> wrote:

> On Thu, 2012-08-16 at 02:07 +0100, Mukesh Rathor wrote:
> > ---
> >  drivers/xen/privcmd.c |   68
> > +	if (rc != 0) {
> > +		pr_warn("%s Could not alloc %d pfns rc:%d\n",
> > __FUNCTION__,
> > +			numpgs, rc);
> > +		kfree(savp->sp_paga);
> > +		kfree(savp);
> > +		return -ENOMEM;
> > +	}
> 
> I've just been building on this patch to make proper mmap foreign
> support on ARM and I was looking for the place which freed this, both
> the pages back to the balloon and then the array itself. There is code
> in privcmd_close which unmaps the P2M, but I can't find the code which
> frees things back to the balloon. Have I missed something?

You are right, I missed the free. Let me revisit it and make some changes.

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 Sep 12 05:40:48 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Sep 2012 05: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 1TBfgM-0004Gc-V6; Wed, 12 Sep 2012 05:40:14 +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 1TBfgL-0004GU-K5
	for xen-devel@lists.xensource.com; Wed, 12 Sep 2012 05:40:13 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1347428406!9230802!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDg3NTM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29112 invoked from network); 12 Sep 2012 05:40: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;
	12 Sep 2012 05:40:06 -0000
X-IronPort-AV: E=Sophos;i="4.80,408,1344211200"; d="scan'208";a="14484592"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Sep 2012 05: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.279.1; Wed, 12 Sep 2012 06: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 1TBfgE-0004Hv-04;
	Wed, 12 Sep 2012 05: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 1TBfgD-0007hY-Vv;
	Wed, 12 Sep 2012 06:40:05 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-13680-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 12 Sep 2012 06:40:05 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.1-testing test] 13680: regressions - trouble:
	broken/fail/pass
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 13680 xen-4.1-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13680/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-i386-i386-pv             9 guest-start               fail REGR. vs. 13657
 test-i386-i386-xl-winxpsp3    3 host-install(3)         broken REGR. vs. 13657
 test-amd64-i386-xl-win7-amd64  3 host-install(3)        broken REGR. vs. 13657
 test-i386-i386-xl             3 host-install(3)         broken REGR. vs. 13657
 test-i386-i386-xl-win         3 host-install(3)         broken REGR. vs. 13657
 test-i386-i386-win            3 host-install(3)         broken REGR. vs. 13657
 test-amd64-i386-xl-win-vcpus1  3 host-install(3)        broken REGR. vs. 13657
 test-amd64-i386-xl-winxpsp3-vcpus1  3 host-install(3)   broken REGR. vs. 13657
 test-amd64-i386-win           3 host-install(3)         broken REGR. vs. 13657
 test-amd64-i386-win-vcpus1    3 host-install(3)         broken REGR. vs. 13657
 test-amd64-amd64-xl-qemuu-winxpsp3  3 host-install(3)   broken REGR. vs. 13657
 test-amd64-i386-qemuu-rhel6hvm-intel  3 host-install(3) broken REGR. vs. 13657
 test-amd64-amd64-xl-win7-amd64  3 host-install(3)       broken REGR. vs. 13657
 test-amd64-i386-qemuu-rhel6hvm-amd  3 host-install(3)   broken REGR. vs. 13657
 test-amd64-i386-rhel6hvm-amd  3 host-install(3)         broken REGR. vs. 13657
 test-i386-i386-xl-qemuu-winxpsp3  3 host-install(3)     broken REGR. vs. 13657
 test-amd64-amd64-xl-winxpsp3  3 host-install(3)         broken REGR. vs. 13657
 test-amd64-i386-pair         3 host-install/src_host(3) broken REGR. vs. 13657
 test-amd64-i386-pair         4 host-install/dst_host(4) broken REGR. vs. 13657

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-pcipt-intel  8 debian-fixup                fail like 13657
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 13657

Tests which did not succeed, but are not blocking:
 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-amd64-xl-qemuu-win7-amd64 13 guest-stop             fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  9be1175d2ac3
baseline version:
 xen                  3e4782f17f5c

------------------------------------------------------------
People who touched revisions under test:
  Ian Jackson <ian.jackson@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                                            broken  
 test-amd64-i386-rhel6hvm-amd                                 broken  
 test-amd64-i386-qemuu-rhel6hvm-amd                           broken  
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               broken  
 test-amd64-i386-xl-win7-amd64                                broken  
 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                         broken  
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         broken  
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            fail    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   broken  
 test-amd64-i386-xl-win-vcpus1                                broken  
 test-amd64-i386-xl-winxpsp3-vcpus1                           broken  
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          broken  
 test-i386-i386-win                                           broken  
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        broken  
 test-amd64-amd64-xl-qemuu-winxpsp3                           broken  
 test-i386-i386-xl-qemuu-winxpsp3                             broken  
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 broken  
 test-i386-i386-xl-winxpsp3                                   broken  


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.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:   23354:9be1175d2ac3
tag:         tip
user:        Ian Jackson <Ian.Jackson@eu.citrix.com>
date:        Tue Sep 11 14:31:12 2012 +0100
    
    QEMU_TAG update
    
    
changeset:   23353:3e4782f17f5c
user:        Ian Jackson <Ian.Jackson@eu.citrix.com>
date:        Wed Sep 05 12:40:10 2012 +0100
    
    QEMU_TAG update (XSA-17 / CVE-2012-3515)
    
    
========================================
commit d7d453f51459b591faa96d1c123b5bfff7c5b6b6
Author: Ian Jackson <ian.jackson@eu.citrix.com>
Date:   Thu Sep 6 17:05:30 2012 +0100

    Disable qemu monitor by default.  The qemu monitor is an overly
    powerful feature which must be protected from untrusted (guest)
    administrators.
    
    Neither xl nor xend expect qemu to produce this monitor unless it is
    explicitly requested.
    
    This is a security problem, XSA-19.  Previously it was CVE-2007-0998
    in Red Hat but we haven't dealt with it in upstream.  We hope to have
    a new CVE for it here but we don't have one yet.
    
    Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
    (cherry picked from commit bacc0d302445c75f18f4c826750fb5853b60e7ca)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 12 05:40:48 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Sep 2012 05: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 1TBfgM-0004Gc-V6; Wed, 12 Sep 2012 05:40:14 +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 1TBfgL-0004GU-K5
	for xen-devel@lists.xensource.com; Wed, 12 Sep 2012 05:40:13 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1347428406!9230802!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDg3NTM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29112 invoked from network); 12 Sep 2012 05:40: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;
	12 Sep 2012 05:40:06 -0000
X-IronPort-AV: E=Sophos;i="4.80,408,1344211200"; d="scan'208";a="14484592"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Sep 2012 05: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.279.1; Wed, 12 Sep 2012 06: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 1TBfgE-0004Hv-04;
	Wed, 12 Sep 2012 05: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 1TBfgD-0007hY-Vv;
	Wed, 12 Sep 2012 06:40:05 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-13680-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 12 Sep 2012 06:40:05 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.1-testing test] 13680: regressions - trouble:
	broken/fail/pass
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 13680 xen-4.1-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13680/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-i386-i386-pv             9 guest-start               fail REGR. vs. 13657
 test-i386-i386-xl-winxpsp3    3 host-install(3)         broken REGR. vs. 13657
 test-amd64-i386-xl-win7-amd64  3 host-install(3)        broken REGR. vs. 13657
 test-i386-i386-xl             3 host-install(3)         broken REGR. vs. 13657
 test-i386-i386-xl-win         3 host-install(3)         broken REGR. vs. 13657
 test-i386-i386-win            3 host-install(3)         broken REGR. vs. 13657
 test-amd64-i386-xl-win-vcpus1  3 host-install(3)        broken REGR. vs. 13657
 test-amd64-i386-xl-winxpsp3-vcpus1  3 host-install(3)   broken REGR. vs. 13657
 test-amd64-i386-win           3 host-install(3)         broken REGR. vs. 13657
 test-amd64-i386-win-vcpus1    3 host-install(3)         broken REGR. vs. 13657
 test-amd64-amd64-xl-qemuu-winxpsp3  3 host-install(3)   broken REGR. vs. 13657
 test-amd64-i386-qemuu-rhel6hvm-intel  3 host-install(3) broken REGR. vs. 13657
 test-amd64-amd64-xl-win7-amd64  3 host-install(3)       broken REGR. vs. 13657
 test-amd64-i386-qemuu-rhel6hvm-amd  3 host-install(3)   broken REGR. vs. 13657
 test-amd64-i386-rhel6hvm-amd  3 host-install(3)         broken REGR. vs. 13657
 test-i386-i386-xl-qemuu-winxpsp3  3 host-install(3)     broken REGR. vs. 13657
 test-amd64-amd64-xl-winxpsp3  3 host-install(3)         broken REGR. vs. 13657
 test-amd64-i386-pair         3 host-install/src_host(3) broken REGR. vs. 13657
 test-amd64-i386-pair         4 host-install/dst_host(4) broken REGR. vs. 13657

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-pcipt-intel  8 debian-fixup                fail like 13657
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 13657

Tests which did not succeed, but are not blocking:
 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-amd64-xl-qemuu-win7-amd64 13 guest-stop             fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  9be1175d2ac3
baseline version:
 xen                  3e4782f17f5c

------------------------------------------------------------
People who touched revisions under test:
  Ian Jackson <ian.jackson@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                                            broken  
 test-amd64-i386-rhel6hvm-amd                                 broken  
 test-amd64-i386-qemuu-rhel6hvm-amd                           broken  
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               broken  
 test-amd64-i386-xl-win7-amd64                                broken  
 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                         broken  
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         broken  
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            fail    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   broken  
 test-amd64-i386-xl-win-vcpus1                                broken  
 test-amd64-i386-xl-winxpsp3-vcpus1                           broken  
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          broken  
 test-i386-i386-win                                           broken  
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        broken  
 test-amd64-amd64-xl-qemuu-winxpsp3                           broken  
 test-i386-i386-xl-qemuu-winxpsp3                             broken  
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 broken  
 test-i386-i386-xl-winxpsp3                                   broken  


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.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:   23354:9be1175d2ac3
tag:         tip
user:        Ian Jackson <Ian.Jackson@eu.citrix.com>
date:        Tue Sep 11 14:31:12 2012 +0100
    
    QEMU_TAG update
    
    
changeset:   23353:3e4782f17f5c
user:        Ian Jackson <Ian.Jackson@eu.citrix.com>
date:        Wed Sep 05 12:40:10 2012 +0100
    
    QEMU_TAG update (XSA-17 / CVE-2012-3515)
    
    
========================================
commit d7d453f51459b591faa96d1c123b5bfff7c5b6b6
Author: Ian Jackson <ian.jackson@eu.citrix.com>
Date:   Thu Sep 6 17:05:30 2012 +0100

    Disable qemu monitor by default.  The qemu monitor is an overly
    powerful feature which must be protected from untrusted (guest)
    administrators.
    
    Neither xl nor xend expect qemu to produce this monitor unless it is
    explicitly requested.
    
    This is a security problem, XSA-19.  Previously it was CVE-2007-0998
    in Red Hat but we haven't dealt with it in upstream.  We hope to have
    a new CVE for it here but we don't have one yet.
    
    Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
    (cherry picked from commit bacc0d302445c75f18f4c826750fb5853b60e7ca)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 12 07:37:37 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Sep 2012 07: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 1TBhVP-0004t1-EU; Wed, 12 Sep 2012 07:37: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 1TBhVO-0004sw-3L
	for Xen-devel@lists.xensource.com; Wed, 12 Sep 2012 07:37:02 +0000
Received: from [85.158.143.99:21537] by server-1.bemta-4.messagelabs.com id
	6E/3F-12504-D9B30505; Wed, 12 Sep 2012 07:37:01 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1347435420!29911104!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDg3NTM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 318 invoked from network); 12 Sep 2012 07:37:00 -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;
	12 Sep 2012 07:37:00 -0000
X-IronPort-AV: E=Sophos;i="4.80,408,1344211200"; d="scan'208";a="14486616"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Sep 2012 07:37: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.279.1;
	Wed, 12 Sep 2012 08:37:00 +0100
Message-ID: <1347435419.10570.107.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Mukesh Rathor <mukesh.rathor@oracle.com>
Date: Wed, 12 Sep 2012 08:36:59 +0100
In-Reply-To: <20120911183210.5c43f428@mantra.us.oracle.com>
References: <20120815180716.0049bffe@mantra.us.oracle.com>
	<1347372623.5305.170.camel@zakaz.uk.xensource.com>
	<20120911183210.5c43f428@mantra.us.oracle.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [RFC PATCH 8/8]: PVH: privcmd changes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-09-12 at 02:32 +0100, Mukesh Rathor wrote:
> On Tue, 11 Sep 2012 15:10:23 +0100
> Ian Campbell <Ian.Campbell@citrix.com> wrote:
> 
> > On Thu, 2012-08-16 at 02:07 +0100, Mukesh Rathor wrote:
> > > ---
> > >  drivers/xen/privcmd.c |   68
> > > +	if (rc != 0) {
> > > +		pr_warn("%s Could not alloc %d pfns rc:%d\n",
> > > __FUNCTION__,
> > > +			numpgs, rc);
> > > +		kfree(savp->sp_paga);
> > > +		kfree(savp);
> > > +		return -ENOMEM;
> > > +	}
> > 
> > I've just been building on this patch to make proper mmap foreign
> > support on ARM and I was looking for the place which freed this, both
> > the pages back to the balloon and then the array itself. There is code
> > in privcmd_close which unmaps the P2M, but I can't find the code which
> > frees things back to the balloon. Have I missed something?
> 
> You are right, I missed the free. Let me revisit it and make some changes.

Thanks.

Any comments on the rest of my mail? We need to agree what the interface
between the generic and the per-arch code is going to look like here.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 12 07:37:37 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Sep 2012 07: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 1TBhVP-0004t1-EU; Wed, 12 Sep 2012 07:37: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 1TBhVO-0004sw-3L
	for Xen-devel@lists.xensource.com; Wed, 12 Sep 2012 07:37:02 +0000
Received: from [85.158.143.99:21537] by server-1.bemta-4.messagelabs.com id
	6E/3F-12504-D9B30505; Wed, 12 Sep 2012 07:37:01 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1347435420!29911104!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDg3NTM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 318 invoked from network); 12 Sep 2012 07:37:00 -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;
	12 Sep 2012 07:37:00 -0000
X-IronPort-AV: E=Sophos;i="4.80,408,1344211200"; d="scan'208";a="14486616"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Sep 2012 07:37: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.279.1;
	Wed, 12 Sep 2012 08:37:00 +0100
Message-ID: <1347435419.10570.107.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Mukesh Rathor <mukesh.rathor@oracle.com>
Date: Wed, 12 Sep 2012 08:36:59 +0100
In-Reply-To: <20120911183210.5c43f428@mantra.us.oracle.com>
References: <20120815180716.0049bffe@mantra.us.oracle.com>
	<1347372623.5305.170.camel@zakaz.uk.xensource.com>
	<20120911183210.5c43f428@mantra.us.oracle.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [RFC PATCH 8/8]: PVH: privcmd changes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-09-12 at 02:32 +0100, Mukesh Rathor wrote:
> On Tue, 11 Sep 2012 15:10:23 +0100
> Ian Campbell <Ian.Campbell@citrix.com> wrote:
> 
> > On Thu, 2012-08-16 at 02:07 +0100, Mukesh Rathor wrote:
> > > ---
> > >  drivers/xen/privcmd.c |   68
> > > +	if (rc != 0) {
> > > +		pr_warn("%s Could not alloc %d pfns rc:%d\n",
> > > __FUNCTION__,
> > > +			numpgs, rc);
> > > +		kfree(savp->sp_paga);
> > > +		kfree(savp);
> > > +		return -ENOMEM;
> > > +	}
> > 
> > I've just been building on this patch to make proper mmap foreign
> > support on ARM and I was looking for the place which freed this, both
> > the pages back to the balloon and then the array itself. There is code
> > in privcmd_close which unmaps the P2M, but I can't find the code which
> > frees things back to the balloon. Have I missed something?
> 
> You are right, I missed the free. Let me revisit it and make some changes.

Thanks.

Any comments on the rest of my mail? We need to agree what the interface
between the generic and the per-arch code is going to look like here.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 12 07:39:09 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Sep 2012 07:39:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TBhWv-0004yQ-3R; Wed, 12 Sep 2012 07:38: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 1TBhWt-0004yC-HI
	for xen-devel@lists.xen.org; Wed, 12 Sep 2012 07:38:35 +0000
Received: from [85.158.138.51:59601] by server-3.bemta-3.messagelabs.com id
	7B/86-21322-AFB30505; Wed, 12 Sep 2012 07:38:34 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1347435510!28282518!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQyMDU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32229 invoked from network); 12 Sep 2012 07:38:31 -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;
	12 Sep 2012 07:38:31 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 12 Sep 2012 08:38:30 +0100
Message-Id: <5050584C020000780009AC42@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 12 Sep 2012 08:39:24 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Konrad Rzeszutek Wilk" <konrad@kernel.org>
References: <504F2C54020000780009A830@nat28.tlf.novell.com>
	<20120911181439.GA30767@phenom.dumpdata.com>
In-Reply-To: <20120911181439.GA30767@phenom.dumpdata.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 6/8] ns16550: PCI initialization adjustments
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 11.09.12 at 20:14, Konrad Rzeszutek Wilk <konrad@kernel.org> wrote:
> On Tue, Sep 11, 2012 at 11:19:32AM +0100, Jan Beulich wrote:
>> Besides single-port serial cards, also accept multi-port ones and such
>> providing mixed functionality (e.g. also having a parallel port).
>> 
>> Reading PCI_INTERRUPT_PIN before ACPI gets enabled generally produces
>> an incorrect IRQ (below 16, whereas after enabling ACPI it frequently
>> would end up at a higher one), so this is useful (almost) only when a
>> system already boots in ACPI mode.
>> 
>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
>> 
>> --- a/xen/drivers/char/ns16550.c
>> +++ b/xen/drivers/char/ns16550.c
>> @@ -468,7 +468,6 @@ static int __init check_existence(struct
>>  static int
>>  pci_uart_config (struct ns16550 *uart, int skip_amt, int bar_idx)
>>  {
>> -    uint16_t class;
>>      uint32_t bar, len;
>>      int b, d, f;
>>  
>> @@ -479,9 +478,15 @@ pci_uart_config (struct ns16550 *uart, i
>>          {
>>              for ( f = 0; f < 0x8; f++ )
>>              {
>> -                class = pci_conf_read16(0, b, d, f, PCI_CLASS_DEVICE);
>> -                if ( class != 0x700 )
>> +                switch ( pci_conf_read16(0, b, d, f, PCI_CLASS_DEVICE) )
>> +                {
>> +                case 0x0700: /* single port serial */
>> +                case 0x0702: /* multi port serial */
>> +                case 0x0780: /* other (e.g serial+parallel) */
>> +                    break;
>> +                default:
>>                      continue;
>> +                }
>>  
>>                  bar = pci_conf_read32(0, b, d, f,
>>                                        PCI_BASE_ADDRESS_0 + bar_idx*4);
>> @@ -504,7 +509,9 @@ pci_uart_config (struct ns16550 *uart, i
>>                  uart->bar = bar;
>>                  uart->bar_idx = bar_idx;
>>                  uart->io_base = bar & ~PCI_BASE_ADDRESS_SPACE_IO;
>> -                uart->irq = 0;
>> +                uart->irq = pci_conf_read8(0, b, d, f, PCI_INTERRUPT_PIN) ?
>> +                    pci_conf_read8(0, b, d, f, PCI_INTERRUPT_LINE) : 0;
>> +printk("COM%d: BAR=%04x IRQ=%d\n", bar_idx + 1, bar, uart->irq);//temp
> 
> printk ?

I had spotted this before committing, and removed it in time.

Thanks for noticing anyway,
Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 12 07:39:09 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Sep 2012 07:39:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TBhWv-0004yQ-3R; Wed, 12 Sep 2012 07:38: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 1TBhWt-0004yC-HI
	for xen-devel@lists.xen.org; Wed, 12 Sep 2012 07:38:35 +0000
Received: from [85.158.138.51:59601] by server-3.bemta-3.messagelabs.com id
	7B/86-21322-AFB30505; Wed, 12 Sep 2012 07:38:34 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1347435510!28282518!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQyMDU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32229 invoked from network); 12 Sep 2012 07:38:31 -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;
	12 Sep 2012 07:38:31 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 12 Sep 2012 08:38:30 +0100
Message-Id: <5050584C020000780009AC42@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 12 Sep 2012 08:39:24 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Konrad Rzeszutek Wilk" <konrad@kernel.org>
References: <504F2C54020000780009A830@nat28.tlf.novell.com>
	<20120911181439.GA30767@phenom.dumpdata.com>
In-Reply-To: <20120911181439.GA30767@phenom.dumpdata.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 6/8] ns16550: PCI initialization adjustments
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 11.09.12 at 20:14, Konrad Rzeszutek Wilk <konrad@kernel.org> wrote:
> On Tue, Sep 11, 2012 at 11:19:32AM +0100, Jan Beulich wrote:
>> Besides single-port serial cards, also accept multi-port ones and such
>> providing mixed functionality (e.g. also having a parallel port).
>> 
>> Reading PCI_INTERRUPT_PIN before ACPI gets enabled generally produces
>> an incorrect IRQ (below 16, whereas after enabling ACPI it frequently
>> would end up at a higher one), so this is useful (almost) only when a
>> system already boots in ACPI mode.
>> 
>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
>> 
>> --- a/xen/drivers/char/ns16550.c
>> +++ b/xen/drivers/char/ns16550.c
>> @@ -468,7 +468,6 @@ static int __init check_existence(struct
>>  static int
>>  pci_uart_config (struct ns16550 *uart, int skip_amt, int bar_idx)
>>  {
>> -    uint16_t class;
>>      uint32_t bar, len;
>>      int b, d, f;
>>  
>> @@ -479,9 +478,15 @@ pci_uart_config (struct ns16550 *uart, i
>>          {
>>              for ( f = 0; f < 0x8; f++ )
>>              {
>> -                class = pci_conf_read16(0, b, d, f, PCI_CLASS_DEVICE);
>> -                if ( class != 0x700 )
>> +                switch ( pci_conf_read16(0, b, d, f, PCI_CLASS_DEVICE) )
>> +                {
>> +                case 0x0700: /* single port serial */
>> +                case 0x0702: /* multi port serial */
>> +                case 0x0780: /* other (e.g serial+parallel) */
>> +                    break;
>> +                default:
>>                      continue;
>> +                }
>>  
>>                  bar = pci_conf_read32(0, b, d, f,
>>                                        PCI_BASE_ADDRESS_0 + bar_idx*4);
>> @@ -504,7 +509,9 @@ pci_uart_config (struct ns16550 *uart, i
>>                  uart->bar = bar;
>>                  uart->bar_idx = bar_idx;
>>                  uart->io_base = bar & ~PCI_BASE_ADDRESS_SPACE_IO;
>> -                uart->irq = 0;
>> +                uart->irq = pci_conf_read8(0, b, d, f, PCI_INTERRUPT_PIN) ?
>> +                    pci_conf_read8(0, b, d, f, PCI_INTERRUPT_LINE) : 0;
>> +printk("COM%d: BAR=%04x IRQ=%d\n", bar_idx + 1, bar, uart->irq);//temp
> 
> printk ?

I had spotted this before committing, and removed it in time.

Thanks for noticing anyway,
Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 12 08:13:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Sep 2012 08:13:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TBi3h-0005hz-N3; Wed, 12 Sep 2012 08:12:29 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1TBi3f-0005hu-BT
	for Xen-devel@lists.xensource.com; Wed, 12 Sep 2012 08:12:27 +0000
Received: from [85.158.139.83:46083] by server-5.bemta-5.messagelabs.com id
	C0/AC-30514-AE340505; Wed, 12 Sep 2012 08:12:26 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1347437545!22666687!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDg3NTM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12519 invoked from network); 12 Sep 2012 08:12:26 -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;
	12 Sep 2012 08:12:26 -0000
X-IronPort-AV: E=Sophos;i="4.80,408,1344211200"; d="scan'208";a="14487562"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Sep 2012 08:12:25 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 12 Sep 2012 09:12:25 +0100
Message-ID: <1347437545.25803.16.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Mukesh Rathor <mukesh.rathor@oracle.com>
Date: Wed, 12 Sep 2012 09:12:25 +0100
In-Reply-To: <20120911145751.599b8292@mantra.us.oracle.com>
References: <20120815175724.3405043a@mantra.us.oracle.com>
	<1347285352.5305.86.camel@zakaz.uk.xensource.com>
	<20120911145751.599b8292@mantra.us.oracle.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [RFC PATCH 1/8]: PVH: Basic and preparatory changes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-09-11 at 22:57 +0100, Mukesh Rathor wrote:
> On Mon, 10 Sep 2012 14:55:52 +0100
> Ian Campbell <Ian.Campbell@citrix.com> wrote:
> 
> > On Thu, 2012-08-16 at 01:57 +0100, Mukesh Rathor wrote:
> > > diff --git a/include/xen/xen.h b/include/xen/xen.h
> > > index a164024..e823639 100644
> > > --- a/include/xen/xen.h
> > > +++ b/include/xen/xen.h
> > > @@ -18,6 +18,10 @@ extern enum xen_domain_type xen_domain_type;
> > >                                  xen_domain_type == XEN_PV_DOMAIN)
> > >  #define xen_hvm_domain()       (xen_domain()
> > > &&                        \ xen_domain_type == XEN_HVM_DOMAIN)
> > > +/* xen_pv_domain check is necessary as start_info ptr is null in
> > > HVM. Also,
> > > + * note, xen PVH domain shares lot of HVM code */
> > > +#define xen_pvh_domain()       (xen_pv_domain()
> > > &&                     \
> > > +                               (xen_start_info->flags &
> > > SIF_IS_PVINHVM))
> > 
> > Can I suggest that for the time being this be gated on a new
> > CONFIG_XEN_PVH option (I think it's new, I can't find one right now)
> > which "depends EXPERIMENTAL".
> > 
> > We don't want to get into the situation where whatever goes into Linux
> > now makes it into a distro (and is enabled) and is subsequently broken
> > on top of whatever the final hypervisor side stuff ends up looking
> > like. We've done the same for the ARM support for example.
> > 
> > Ian.
> 
> Well, I'm pretty much removing all xen_pv_domain() checks and moving to
> other checks, like you guys wanted. This code is pretty intermingled and
> can't be ifdef'd easily.

It would likely be sufficient to just ifdef the bit which tells the
builder that this kernel image supports PVH, which I guess is one or
more XENFEATs in arch/x86/xen/xen-head.S?

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 12 08:13:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Sep 2012 08:13:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TBi3h-0005hz-N3; Wed, 12 Sep 2012 08:12:29 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1TBi3f-0005hu-BT
	for Xen-devel@lists.xensource.com; Wed, 12 Sep 2012 08:12:27 +0000
Received: from [85.158.139.83:46083] by server-5.bemta-5.messagelabs.com id
	C0/AC-30514-AE340505; Wed, 12 Sep 2012 08:12:26 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1347437545!22666687!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDg3NTM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12519 invoked from network); 12 Sep 2012 08:12:26 -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;
	12 Sep 2012 08:12:26 -0000
X-IronPort-AV: E=Sophos;i="4.80,408,1344211200"; d="scan'208";a="14487562"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Sep 2012 08:12:25 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 12 Sep 2012 09:12:25 +0100
Message-ID: <1347437545.25803.16.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Mukesh Rathor <mukesh.rathor@oracle.com>
Date: Wed, 12 Sep 2012 09:12:25 +0100
In-Reply-To: <20120911145751.599b8292@mantra.us.oracle.com>
References: <20120815175724.3405043a@mantra.us.oracle.com>
	<1347285352.5305.86.camel@zakaz.uk.xensource.com>
	<20120911145751.599b8292@mantra.us.oracle.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [RFC PATCH 1/8]: PVH: Basic and preparatory changes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-09-11 at 22:57 +0100, Mukesh Rathor wrote:
> On Mon, 10 Sep 2012 14:55:52 +0100
> Ian Campbell <Ian.Campbell@citrix.com> wrote:
> 
> > On Thu, 2012-08-16 at 01:57 +0100, Mukesh Rathor wrote:
> > > diff --git a/include/xen/xen.h b/include/xen/xen.h
> > > index a164024..e823639 100644
> > > --- a/include/xen/xen.h
> > > +++ b/include/xen/xen.h
> > > @@ -18,6 +18,10 @@ extern enum xen_domain_type xen_domain_type;
> > >                                  xen_domain_type == XEN_PV_DOMAIN)
> > >  #define xen_hvm_domain()       (xen_domain()
> > > &&                        \ xen_domain_type == XEN_HVM_DOMAIN)
> > > +/* xen_pv_domain check is necessary as start_info ptr is null in
> > > HVM. Also,
> > > + * note, xen PVH domain shares lot of HVM code */
> > > +#define xen_pvh_domain()       (xen_pv_domain()
> > > &&                     \
> > > +                               (xen_start_info->flags &
> > > SIF_IS_PVINHVM))
> > 
> > Can I suggest that for the time being this be gated on a new
> > CONFIG_XEN_PVH option (I think it's new, I can't find one right now)
> > which "depends EXPERIMENTAL".
> > 
> > We don't want to get into the situation where whatever goes into Linux
> > now makes it into a distro (and is enabled) and is subsequently broken
> > on top of whatever the final hypervisor side stuff ends up looking
> > like. We've done the same for the ARM support for example.
> > 
> > Ian.
> 
> Well, I'm pretty much removing all xen_pv_domain() checks and moving to
> other checks, like you guys wanted. This code is pretty intermingled and
> can't be ifdef'd easily.

It would likely be sufficient to just ifdef the bit which tells the
builder that this kernel image supports PVH, which I guess is one or
more XENFEATs in arch/x86/xen/xen-head.S?

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 12 08:13:46 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Sep 2012 08:13:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TBi4V-0005kR-4z; Wed, 12 Sep 2012 08:13:19 +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 1TBi4U-0005k8-DE
	for xen-devel@lists.xen.org; Wed, 12 Sep 2012 08:13:18 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1347437592!10098817!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQyMDU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18873 invoked from network); 12 Sep 2012 08:13:12 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-4.tower-27.messagelabs.com with SMTP;
	12 Sep 2012 08:13:12 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 12 Sep 2012 09:13:11 +0100
Message-Id: <5050606D020000780009AC5E@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 12 Sep 2012 09:14:05 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
References: <osstest-13677-mainreport@xen.org>
In-Reply-To: <osstest-13677-mainreport@xen.org>
Mime-Version: 1.0
Content-Disposition: inline
Cc: ian.jackson@eu.citrix.com
Subject: Re: [Xen-devel] [xen-unstable test] 13677: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.09.12 at 19:28, xen.org <ian.jackson@eu.citrix.com> wrote:
> flight 13677 xen-unstable real [real]
> http://www.chiark.greenend.org.uk/~xensrcts/logs/13677/ 
> 
> Regressions :-(
> 
> Tests which did not succeed and are blocking,
> including tests which could not be run:
>  test-amd64-i386-rhel6hvm-amd  8 guest-stop                fail REGR. vs. 13668
>  test-amd64-i386-qemuu-rhel6hvm-amd  8 guest-stop          fail REGR. vs. 13668
>  test-amd64-i386-qemuu-rhel6hvm-intel  8 guest-stop        fail REGR. vs. 13668
>  test-amd64-i386-rhel6hvm-intel  8 guest-stop              fail REGR. vs. 13668

While it seems very likely that if any, one of the two changes
of mine under test here have caused this, looking through the
logs I can't spot anything that would tell me what's wrong.
According to var-log-xen-qemu-dm-redhat.guest.osstest.log,
the guest went down (but it didn't even enter "dying" mode
yet according to the diagnostic output in the serial log). Nor
can I see any close relation between the behavior and the
changsets under test...

Any hints/help appreciated,
Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 12 08:13:46 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Sep 2012 08:13:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TBi4V-0005kR-4z; Wed, 12 Sep 2012 08:13:19 +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 1TBi4U-0005k8-DE
	for xen-devel@lists.xen.org; Wed, 12 Sep 2012 08:13:18 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1347437592!10098817!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQyMDU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18873 invoked from network); 12 Sep 2012 08:13:12 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-4.tower-27.messagelabs.com with SMTP;
	12 Sep 2012 08:13:12 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 12 Sep 2012 09:13:11 +0100
Message-Id: <5050606D020000780009AC5E@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 12 Sep 2012 09:14:05 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
References: <osstest-13677-mainreport@xen.org>
In-Reply-To: <osstest-13677-mainreport@xen.org>
Mime-Version: 1.0
Content-Disposition: inline
Cc: ian.jackson@eu.citrix.com
Subject: Re: [Xen-devel] [xen-unstable test] 13677: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.09.12 at 19:28, xen.org <ian.jackson@eu.citrix.com> wrote:
> flight 13677 xen-unstable real [real]
> http://www.chiark.greenend.org.uk/~xensrcts/logs/13677/ 
> 
> Regressions :-(
> 
> Tests which did not succeed and are blocking,
> including tests which could not be run:
>  test-amd64-i386-rhel6hvm-amd  8 guest-stop                fail REGR. vs. 13668
>  test-amd64-i386-qemuu-rhel6hvm-amd  8 guest-stop          fail REGR. vs. 13668
>  test-amd64-i386-qemuu-rhel6hvm-intel  8 guest-stop        fail REGR. vs. 13668
>  test-amd64-i386-rhel6hvm-intel  8 guest-stop              fail REGR. vs. 13668

While it seems very likely that if any, one of the two changes
of mine under test here have caused this, looking through the
logs I can't spot anything that would tell me what's wrong.
According to var-log-xen-qemu-dm-redhat.guest.osstest.log,
the guest went down (but it didn't even enter "dying" mode
yet according to the diagnostic output in the serial log). Nor
can I see any close relation between the behavior and the
changsets under test...

Any hints/help appreciated,
Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 12 09:49:23 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Sep 2012 09: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 1TBjYv-0006Ze-Mm; Wed, 12 Sep 2012 09:48:49 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1TBjYt-0006ZW-Ce
	for xen-devel@lists.xen.org; Wed, 12 Sep 2012 09:48:47 +0000
Received: from [85.158.143.99:56012] by server-1.bemta-4.messagelabs.com id
	C6/73-12504-E7A50505; Wed, 12 Sep 2012 09:48:46 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1347443326!24673106!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDg4MjM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8468 invoked from network); 12 Sep 2012 09:48:46 -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;
	12 Sep 2012 09:48:46 -0000
X-IronPort-AV: E=Sophos;i="4.80,408,1344211200"; d="scan'208";a="14490788"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Sep 2012 09:48: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.279.1;
	Wed, 12 Sep 2012 10:48:45 +0100
Message-ID: <1347443324.24226.30.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Wed, 12 Sep 2012 10:48:44 +0100
In-Reply-To: <5050606D020000780009AC5E@nat28.tlf.novell.com>
References: <osstest-13677-mainreport@xen.org>
	<5050606D020000780009AC5E@nat28.tlf.novell.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [xen-unstable test] 13677: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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-09-12 at 09:14 +0100, Jan Beulich wrote:
> >>> On 11.09.12 at 19:28, xen.org <ian.jackson@eu.citrix.com> wrote:
> > flight 13677 xen-unstable real [real]
> > http://www.chiark.greenend.org.uk/~xensrcts/logs/13677/ 
> > 
> > Regressions :-(
> > 
> > Tests which did not succeed and are blocking,
> > including tests which could not be run:
> >  test-amd64-i386-rhel6hvm-amd  8 guest-stop                fail REGR. vs. 13668
> >  test-amd64-i386-qemuu-rhel6hvm-amd  8 guest-stop          fail REGR. vs. 13668
> >  test-amd64-i386-qemuu-rhel6hvm-intel  8 guest-stop        fail REGR. vs. 13668
> >  test-amd64-i386-rhel6hvm-intel  8 guest-stop              fail REGR. vs. 13668
> 
> While it seems very likely that if any, one of the two changes
> of mine under test here have caused this, looking through the
> logs I can't spot anything that would tell me what's wrong.
> According to var-log-xen-qemu-dm-redhat.guest.osstest.log,
> the guest went down (but it didn't even enter "dying" mode
> yet according to the diagnostic output in the serial log). Nor
> can I see any close relation between the behavior and the
> changsets under test...

Looking at test-amd64-i386-rhel6hvm-amd in flight 13675 which succeeded
the guest log ends:
        Halting system...
        type=1128 audit(1347348133.094:15071): user pid=1432 uid=0 auid=4294967295 ses=4294967295 msg='init: exe="/sbin/reboot" hostname=? addr=? terminal=console res=success'
        md: stopping all md devices.
        xenbus_dev_shutdown: device/vkbd/0: Initialising != Connected, skipping
        xenbus_dev_shutdown: device/vbd/5632: Closed != Connected, skipping
        ACPI: Preparing to enter system sleep state S5
        Disabling non-boot CPUs ...
        Broke affinity for irq 4
        Broke affinity for irq 12
        SMP alternatives: switching to UP code
        Power down.
        shutdown requested in cpu_handle_ioreq
        Issued domain 2 poweroff
        
Whereas in the failing case it cuts off after "stopping all md devices".

13675 failed another sequence, lets assume for unrelated reasons. The
delta in the commits is just:

25844:0a9a4549e6b9 powernow: Update P-state directly when _PSD's CoordType is DOMAIN_COORD_TYPE_HW_ALL
25843:51090fe1ab97 x86/HVM: assorted RTC emulation adjustments

The first is a host level thing which I doubt would so consistently
effect HVM guests (and anyway, Intel tests are also failing). Which
pretty much leaves 25843:51090fe1ab97 or some weird heisenbug.

Is it outside the realms of possibility that the guest has managed to
limp along with the RTC being broken in some subtle way and only
eventually trips up when we come to shut down?

Looking back at 13675, is it possible that:

25842:a1f73e989c24 x86/hvm: don't give vector callback higher priority than NMI/MCE

is exposing a race in the guest or something? I very much doubt any NMI
or MCE are being injected at all 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 Sep 12 09:49:23 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Sep 2012 09: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 1TBjYv-0006Ze-Mm; Wed, 12 Sep 2012 09:48:49 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1TBjYt-0006ZW-Ce
	for xen-devel@lists.xen.org; Wed, 12 Sep 2012 09:48:47 +0000
Received: from [85.158.143.99:56012] by server-1.bemta-4.messagelabs.com id
	C6/73-12504-E7A50505; Wed, 12 Sep 2012 09:48:46 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1347443326!24673106!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDg4MjM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8468 invoked from network); 12 Sep 2012 09:48:46 -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;
	12 Sep 2012 09:48:46 -0000
X-IronPort-AV: E=Sophos;i="4.80,408,1344211200"; d="scan'208";a="14490788"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Sep 2012 09:48: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.279.1;
	Wed, 12 Sep 2012 10:48:45 +0100
Message-ID: <1347443324.24226.30.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Wed, 12 Sep 2012 10:48:44 +0100
In-Reply-To: <5050606D020000780009AC5E@nat28.tlf.novell.com>
References: <osstest-13677-mainreport@xen.org>
	<5050606D020000780009AC5E@nat28.tlf.novell.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [xen-unstable test] 13677: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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-09-12 at 09:14 +0100, Jan Beulich wrote:
> >>> On 11.09.12 at 19:28, xen.org <ian.jackson@eu.citrix.com> wrote:
> > flight 13677 xen-unstable real [real]
> > http://www.chiark.greenend.org.uk/~xensrcts/logs/13677/ 
> > 
> > Regressions :-(
> > 
> > Tests which did not succeed and are blocking,
> > including tests which could not be run:
> >  test-amd64-i386-rhel6hvm-amd  8 guest-stop                fail REGR. vs. 13668
> >  test-amd64-i386-qemuu-rhel6hvm-amd  8 guest-stop          fail REGR. vs. 13668
> >  test-amd64-i386-qemuu-rhel6hvm-intel  8 guest-stop        fail REGR. vs. 13668
> >  test-amd64-i386-rhel6hvm-intel  8 guest-stop              fail REGR. vs. 13668
> 
> While it seems very likely that if any, one of the two changes
> of mine under test here have caused this, looking through the
> logs I can't spot anything that would tell me what's wrong.
> According to var-log-xen-qemu-dm-redhat.guest.osstest.log,
> the guest went down (but it didn't even enter "dying" mode
> yet according to the diagnostic output in the serial log). Nor
> can I see any close relation between the behavior and the
> changsets under test...

Looking at test-amd64-i386-rhel6hvm-amd in flight 13675 which succeeded
the guest log ends:
        Halting system...
        type=1128 audit(1347348133.094:15071): user pid=1432 uid=0 auid=4294967295 ses=4294967295 msg='init: exe="/sbin/reboot" hostname=? addr=? terminal=console res=success'
        md: stopping all md devices.
        xenbus_dev_shutdown: device/vkbd/0: Initialising != Connected, skipping
        xenbus_dev_shutdown: device/vbd/5632: Closed != Connected, skipping
        ACPI: Preparing to enter system sleep state S5
        Disabling non-boot CPUs ...
        Broke affinity for irq 4
        Broke affinity for irq 12
        SMP alternatives: switching to UP code
        Power down.
        shutdown requested in cpu_handle_ioreq
        Issued domain 2 poweroff
        
Whereas in the failing case it cuts off after "stopping all md devices".

13675 failed another sequence, lets assume for unrelated reasons. The
delta in the commits is just:

25844:0a9a4549e6b9 powernow: Update P-state directly when _PSD's CoordType is DOMAIN_COORD_TYPE_HW_ALL
25843:51090fe1ab97 x86/HVM: assorted RTC emulation adjustments

The first is a host level thing which I doubt would so consistently
effect HVM guests (and anyway, Intel tests are also failing). Which
pretty much leaves 25843:51090fe1ab97 or some weird heisenbug.

Is it outside the realms of possibility that the guest has managed to
limp along with the RTC being broken in some subtle way and only
eventually trips up when we come to shut down?

Looking back at 13675, is it possible that:

25842:a1f73e989c24 x86/hvm: don't give vector callback higher priority than NMI/MCE

is exposing a race in the guest or something? I very much doubt any NMI
or MCE are being injected at all 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 Sep 12 09:58:38 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Sep 2012 09:58:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TBji0-0006j5-OU; Wed, 12 Sep 2012 09:58:12 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1TBjhz-0006j0-5y
	for xen-devel@lists.xensource.com; Wed, 12 Sep 2012 09:58:11 +0000
Received: from [85.158.143.99:52202] by server-1.bemta-4.messagelabs.com id
	85/18-12504-2BC50505; Wed, 12 Sep 2012 09:58:10 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1347443889!18693410!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDg4MjM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 817 invoked from network); 12 Sep 2012 09:58:09 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Sep 2012 09:58:09 -0000
X-IronPort-AV: E=Sophos;i="4.80,408,1344211200"; d="scan'208";a="14491024"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Sep 2012 09:57:50 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Wed, 12 Sep 2012 10:57: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 1TBjhd-0006HA-Nx;
	Wed, 12 Sep 2012 09:57:49 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1TBjhd-0007Sg-Gf;
	Wed, 12 Sep 2012 10:57:49 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-13683-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 12 Sep 2012 10:57:49 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.0-testing test] 13683: regressions - trouble:
	blocked/broken/fail/pass
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 13683 xen-4.0-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13683/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-i386                    4 xen-build                 fail REGR. vs. 13650
 build-amd64-oldkern           2 host-install(2)         broken REGR. vs. 13650
 build-amd64                   2 host-install(2)         broken REGR. vs. 13650
 build-amd64-pvops             2 host-install(2)         broken REGR. vs. 13650
 build-i386-oldkern            2 host-install(2)         broken REGR. vs. 13650

Tests which did not succeed, but are not blocking:
 test-amd64-i386-xl-multivcpu  1 xen-build-check(1)           blocked  n/a
 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-i386-xl            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pv            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  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-pv           1 xen-build-check(1)           blocked  n/a
 test-i386-i386-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-qemuu-rhel6hvm-intel  1 xen-build-check(1)         blocked n/a
 test-amd64-amd64-xl-sedf      1 xen-build-check(1)           blocked  n/a
 test-i386-i386-pair           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-credit2    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pair          1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pair         1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-amd  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 xen-build-check(1)         blocked n/a
 test-amd64-i386-win-vcpus1    1 xen-build-check(1)           blocked  n/a
 test-i386-i386-win            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xend-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win           1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-win          1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-winxpsp3-vcpus1  1 xen-build-check(1)           blocked n/a
 test-amd64-amd64-xl-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-win-vcpus1  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win       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-qemuu-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                  512168f88df9
baseline version:
 xen                  79444af3258c

------------------------------------------------------------
People who touched revisions under test:
------------------------------------------------------------

jobs:
 build-amd64                                                  broken  
 build-i386                                                   fail    
 build-amd64-oldkern                                          broken  
 build-i386-oldkern                                           broken  
 build-amd64-pvops                                            broken  
 build-i386-pvops                                             pass    
 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.

------------------------------------------------------------
changeset:   21616:512168f88df9
tag:         tip
user:        Ian Jackson <Ian.Jackson@eu.citrix.com>
date:        Tue Sep 11 14:35:26 2012 +0100
    
    QEMU_TAG update
    
    
changeset:   21615:79444af3258c
user:        Ian Jackson <Ian.Jackson@eu.citrix.com>
date:        Wed Sep 05 12:40:12 2012 +0100
    
    QEMU_TAG update (XSA-17 / CVE-2012-3515)
    
    
(qemu changes not included)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 12 09:58:38 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Sep 2012 09:58:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TBji0-0006j5-OU; Wed, 12 Sep 2012 09:58:12 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1TBjhz-0006j0-5y
	for xen-devel@lists.xensource.com; Wed, 12 Sep 2012 09:58:11 +0000
Received: from [85.158.143.99:52202] by server-1.bemta-4.messagelabs.com id
	85/18-12504-2BC50505; Wed, 12 Sep 2012 09:58:10 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1347443889!18693410!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDg4MjM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 817 invoked from network); 12 Sep 2012 09:58:09 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Sep 2012 09:58:09 -0000
X-IronPort-AV: E=Sophos;i="4.80,408,1344211200"; d="scan'208";a="14491024"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Sep 2012 09:57:50 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Wed, 12 Sep 2012 10:57: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 1TBjhd-0006HA-Nx;
	Wed, 12 Sep 2012 09:57:49 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1TBjhd-0007Sg-Gf;
	Wed, 12 Sep 2012 10:57:49 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-13683-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 12 Sep 2012 10:57:49 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.0-testing test] 13683: regressions - trouble:
	blocked/broken/fail/pass
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 13683 xen-4.0-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13683/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-i386                    4 xen-build                 fail REGR. vs. 13650
 build-amd64-oldkern           2 host-install(2)         broken REGR. vs. 13650
 build-amd64                   2 host-install(2)         broken REGR. vs. 13650
 build-amd64-pvops             2 host-install(2)         broken REGR. vs. 13650
 build-i386-oldkern            2 host-install(2)         broken REGR. vs. 13650

Tests which did not succeed, but are not blocking:
 test-amd64-i386-xl-multivcpu  1 xen-build-check(1)           blocked  n/a
 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-i386-xl            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pv            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  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-pv           1 xen-build-check(1)           blocked  n/a
 test-i386-i386-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-qemuu-rhel6hvm-intel  1 xen-build-check(1)         blocked n/a
 test-amd64-amd64-xl-sedf      1 xen-build-check(1)           blocked  n/a
 test-i386-i386-pair           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-credit2    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pair          1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pair         1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-amd  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 xen-build-check(1)         blocked n/a
 test-amd64-i386-win-vcpus1    1 xen-build-check(1)           blocked  n/a
 test-i386-i386-win            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xend-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win           1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-win          1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-winxpsp3-vcpus1  1 xen-build-check(1)           blocked n/a
 test-amd64-amd64-xl-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-win-vcpus1  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win       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-qemuu-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                  512168f88df9
baseline version:
 xen                  79444af3258c

------------------------------------------------------------
People who touched revisions under test:
------------------------------------------------------------

jobs:
 build-amd64                                                  broken  
 build-i386                                                   fail    
 build-amd64-oldkern                                          broken  
 build-i386-oldkern                                           broken  
 build-amd64-pvops                                            broken  
 build-i386-pvops                                             pass    
 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.

------------------------------------------------------------
changeset:   21616:512168f88df9
tag:         tip
user:        Ian Jackson <Ian.Jackson@eu.citrix.com>
date:        Tue Sep 11 14:35:26 2012 +0100
    
    QEMU_TAG update
    
    
changeset:   21615:79444af3258c
user:        Ian Jackson <Ian.Jackson@eu.citrix.com>
date:        Wed Sep 05 12:40:12 2012 +0100
    
    QEMU_TAG update (XSA-17 / CVE-2012-3515)
    
    
(qemu changes not included)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 12 09:58:42 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Sep 2012 09:58: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 1TBji7-0006jQ-4r; Wed, 12 Sep 2012 09:58:19 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xiantao.zhang@intel.com>) id 1TBji5-0006jG-4k
	for xen-devel@lists.xen.org; Wed, 12 Sep 2012 09:58:17 +0000
Received: from [85.158.143.35:30056] by server-3.bemta-4.messagelabs.com id
	95/EE-08232-8BC50505; Wed, 12 Sep 2012 09:58:16 +0000
X-Env-Sender: xiantao.zhang@intel.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1347443821!12724016!1
X-Originating-IP: [134.134.136.24]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjQgPT4gMzQyNzU1\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22147 invoked from network); 12 Sep 2012 09:57:02 -0000
Received: from mga09.intel.com (HELO mga09.intel.com) (134.134.136.24)
	by server-11.tower-21.messagelabs.com with SMTP;
	12 Sep 2012 09:57:02 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga102.jf.intel.com with ESMTP; 12 Sep 2012 02:56:42 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.80,408,1344236400"; d="scan'208";a="202114492"
Received: from fmsmsx105.amr.corp.intel.com ([10.19.9.36])
	by orsmga002.jf.intel.com with ESMTP; 12 Sep 2012 02:56:50 -0700
Received: from fmsmsx152.amr.corp.intel.com (10.19.17.221) by
	FMSMSX105.amr.corp.intel.com (10.19.9.36) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Wed, 12 Sep 2012 02:56:49 -0700
Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by
	fmsmsx152.amr.corp.intel.com (10.19.17.221) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Wed, 12 Sep 2012 02:56:49 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.239]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.175]) with mapi id
	14.01.0355.002; Wed, 12 Sep 2012 17:56:48 +0800
From: "Zhang, Xiantao" <xiantao.zhang@intel.com>
To: Jan Beulich <JBeulich@suse.com>, xen-devel <xen-devel@lists.xen.org>
Thread-Topic: [PATCH 3/3] VT-d: use msi_compose_msg()
Thread-Index: AQHNkBoKbSHj5U8uXkCu9VFzOSMLAZeGeXBg
Date: Wed, 12 Sep 2012 09:56:48 +0000
Message-ID: <B6C2EB9186482D47BD0C5A9A48345644032F7179@SHSMSX101.ccr.corp.intel.com>
References: <504F4C45020000780009A96C@nat28.tlf.novell.com>
In-Reply-To: <504F4C45020000780009A96C@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: "Zhang, Xiantao" <xiantao.zhang@intel.com>
Subject: Re: [Xen-devel] [PATCH 3/3] VT-d: use msi_compose_msg()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Acked-by: Xiantao Zhang <xiantao.zhang@intel.com>, Thanks! 
Xiantao

> -----Original Message-----
> From: Jan Beulich [mailto:JBeulich@suse.com]
> Sent: Tuesday, September 11, 2012 8:36 PM
> To: xen-devel
> Cc: Zhang, Xiantao
> Subject: [PATCH 3/3] VT-d: use msi_compose_msg()
> 
> ... instead of open coding it.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> 
> --- a/xen/drivers/passthrough/vtd/iommu.c
> +++ b/xen/drivers/passthrough/vtd/iommu.c
> @@ -1079,22 +1079,11 @@ static void dma_msi_set_affinity(struct
>          return;
>      }
> 
> -    memset(&msg, 0, sizeof(msg));
> -    msg.data = MSI_DATA_VECTOR(desc->arch.vector) & 0xff;
> -    msg.data |= 1 << 14;
> -    msg.data |= (INT_DELIVERY_MODE != dest_LowestPrio) ?
> -        MSI_DATA_DELIVERY_FIXED:
> -        MSI_DATA_DELIVERY_LOWPRI;
> -
> -    /* Follow MSI setting */
> +    msi_compose_msg(desc, &msg);
> +    /* Are these overrides really needed? */
>      if (x2apic_enabled)
>          msg.address_hi = dest & 0xFFFFFF00;
> -    msg.address_lo = (MSI_ADDRESS_HEADER <<
> (MSI_ADDRESS_HEADER_SHIFT + 8));
> -    msg.address_lo |= INT_DEST_MODE ? MSI_ADDR_DESTMODE_LOGIC:
> -                    MSI_ADDR_DESTMODE_PHYS;
> -    msg.address_lo |= (INT_DELIVERY_MODE != dest_LowestPrio) ?
> -                    MSI_ADDR_REDIRECTION_CPU:
> -                    MSI_ADDR_REDIRECTION_LOWPRI;
> +    msg.address_lo &= ~MSI_ADDR_DEST_ID_MASK;
>      msg.address_lo |= MSI_ADDR_DEST_ID(dest & 0xff);  #else
>      memset(&msg, 0, sizeof(msg));
> 
> 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 12 09:58:42 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Sep 2012 09:58: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 1TBji7-0006jQ-4r; Wed, 12 Sep 2012 09:58:19 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xiantao.zhang@intel.com>) id 1TBji5-0006jG-4k
	for xen-devel@lists.xen.org; Wed, 12 Sep 2012 09:58:17 +0000
Received: from [85.158.143.35:30056] by server-3.bemta-4.messagelabs.com id
	95/EE-08232-8BC50505; Wed, 12 Sep 2012 09:58:16 +0000
X-Env-Sender: xiantao.zhang@intel.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1347443821!12724016!1
X-Originating-IP: [134.134.136.24]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjQgPT4gMzQyNzU1\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22147 invoked from network); 12 Sep 2012 09:57:02 -0000
Received: from mga09.intel.com (HELO mga09.intel.com) (134.134.136.24)
	by server-11.tower-21.messagelabs.com with SMTP;
	12 Sep 2012 09:57:02 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga102.jf.intel.com with ESMTP; 12 Sep 2012 02:56:42 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.80,408,1344236400"; d="scan'208";a="202114492"
Received: from fmsmsx105.amr.corp.intel.com ([10.19.9.36])
	by orsmga002.jf.intel.com with ESMTP; 12 Sep 2012 02:56:50 -0700
Received: from fmsmsx152.amr.corp.intel.com (10.19.17.221) by
	FMSMSX105.amr.corp.intel.com (10.19.9.36) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Wed, 12 Sep 2012 02:56:49 -0700
Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by
	fmsmsx152.amr.corp.intel.com (10.19.17.221) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Wed, 12 Sep 2012 02:56:49 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.239]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.175]) with mapi id
	14.01.0355.002; Wed, 12 Sep 2012 17:56:48 +0800
From: "Zhang, Xiantao" <xiantao.zhang@intel.com>
To: Jan Beulich <JBeulich@suse.com>, xen-devel <xen-devel@lists.xen.org>
Thread-Topic: [PATCH 3/3] VT-d: use msi_compose_msg()
Thread-Index: AQHNkBoKbSHj5U8uXkCu9VFzOSMLAZeGeXBg
Date: Wed, 12 Sep 2012 09:56:48 +0000
Message-ID: <B6C2EB9186482D47BD0C5A9A48345644032F7179@SHSMSX101.ccr.corp.intel.com>
References: <504F4C45020000780009A96C@nat28.tlf.novell.com>
In-Reply-To: <504F4C45020000780009A96C@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: "Zhang, Xiantao" <xiantao.zhang@intel.com>
Subject: Re: [Xen-devel] [PATCH 3/3] VT-d: use msi_compose_msg()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Acked-by: Xiantao Zhang <xiantao.zhang@intel.com>, Thanks! 
Xiantao

> -----Original Message-----
> From: Jan Beulich [mailto:JBeulich@suse.com]
> Sent: Tuesday, September 11, 2012 8:36 PM
> To: xen-devel
> Cc: Zhang, Xiantao
> Subject: [PATCH 3/3] VT-d: use msi_compose_msg()
> 
> ... instead of open coding it.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> 
> --- a/xen/drivers/passthrough/vtd/iommu.c
> +++ b/xen/drivers/passthrough/vtd/iommu.c
> @@ -1079,22 +1079,11 @@ static void dma_msi_set_affinity(struct
>          return;
>      }
> 
> -    memset(&msg, 0, sizeof(msg));
> -    msg.data = MSI_DATA_VECTOR(desc->arch.vector) & 0xff;
> -    msg.data |= 1 << 14;
> -    msg.data |= (INT_DELIVERY_MODE != dest_LowestPrio) ?
> -        MSI_DATA_DELIVERY_FIXED:
> -        MSI_DATA_DELIVERY_LOWPRI;
> -
> -    /* Follow MSI setting */
> +    msi_compose_msg(desc, &msg);
> +    /* Are these overrides really needed? */
>      if (x2apic_enabled)
>          msg.address_hi = dest & 0xFFFFFF00;
> -    msg.address_lo = (MSI_ADDRESS_HEADER <<
> (MSI_ADDRESS_HEADER_SHIFT + 8));
> -    msg.address_lo |= INT_DEST_MODE ? MSI_ADDR_DESTMODE_LOGIC:
> -                    MSI_ADDR_DESTMODE_PHYS;
> -    msg.address_lo |= (INT_DELIVERY_MODE != dest_LowestPrio) ?
> -                    MSI_ADDR_REDIRECTION_CPU:
> -                    MSI_ADDR_REDIRECTION_LOWPRI;
> +    msg.address_lo &= ~MSI_ADDR_DEST_ID_MASK;
>      msg.address_lo |= MSI_ADDR_DEST_ID(dest & 0xff);  #else
>      memset(&msg, 0, sizeof(msg));
> 
> 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 12 10:07:51 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Sep 2012 10:07:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TBjqz-00078E-0z; Wed, 12 Sep 2012 10:07: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 1TBjqw-000789-Rt
	for xen-devel@lists.xen.org; Wed, 12 Sep 2012 10:07:27 +0000
Received: from [85.158.143.99:4720] by server-2.bemta-4.messagelabs.com id
	8E/F9-21239-EDE50505; Wed, 12 Sep 2012 10:07:26 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1347444445!20301495!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQyODU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1221 invoked from network); 12 Sep 2012 10:07:25 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-14.tower-216.messagelabs.com with SMTP;
	12 Sep 2012 10:07:25 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 12 Sep 2012 11:07:24 +0100
Message-Id: <50507B32020000780009AC9C@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 12 Sep 2012 11:08:18 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Campbell" <Ian.Campbell@citrix.com>
References: <osstest-13677-mainreport@xen.org>
	<5050606D020000780009AC5E@nat28.tlf.novell.com>
	<1347443324.24226.30.camel@zakaz.uk.xensource.com>
In-Reply-To: <1347443324.24226.30.camel@zakaz.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [xen-unstable test] 13677: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.09.12 at 11:48, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> On Wed, 2012-09-12 at 09:14 +0100, Jan Beulich wrote:
>> >>> On 11.09.12 at 19:28, xen.org <ian.jackson@eu.citrix.com> wrote:
>> > flight 13677 xen-unstable real [real]
>> > http://www.chiark.greenend.org.uk/~xensrcts/logs/13677/ 
>> > 
>> > Regressions :-(
>> > 
>> > Tests which did not succeed and are blocking,
>> > including tests which could not be run:
>> >  test-amd64-i386-rhel6hvm-amd  8 guest-stop                fail REGR. vs. 
> 13668
>> >  test-amd64-i386-qemuu-rhel6hvm-amd  8 guest-stop          fail REGR. vs. 
> 13668
>> >  test-amd64-i386-qemuu-rhel6hvm-intel  8 guest-stop        fail REGR. vs. 
> 13668
>> >  test-amd64-i386-rhel6hvm-intel  8 guest-stop              fail REGR. vs. 
> 13668
>> 
>> While it seems very likely that if any, one of the two changes
>> of mine under test here have caused this, looking through the
>> logs I can't spot anything that would tell me what's wrong.
>> According to var-log-xen-qemu-dm-redhat.guest.osstest.log,
>> the guest went down (but it didn't even enter "dying" mode
>> yet according to the diagnostic output in the serial log). Nor
>> can I see any close relation between the behavior and the
>> changsets under test...
> 
> Looking at test-amd64-i386-rhel6hvm-amd in flight 13675 which succeeded
> the guest log ends:
>         Halting system...
>         type=1128 audit(1347348133.094:15071): user pid=1432 uid=0 
> auid=4294967295 ses=4294967295 msg='init: exe="/sbin/reboot" hostname=? 
> addr=? terminal=console res=success'
>         md: stopping all md devices.
>         xenbus_dev_shutdown: device/vkbd/0: Initialising != Connected, 
> skipping
>         xenbus_dev_shutdown: device/vbd/5632: Closed != Connected, skipping
>         ACPI: Preparing to enter system sleep state S5
>         Disabling non-boot CPUs ...
>         Broke affinity for irq 4
>         Broke affinity for irq 12
>         SMP alternatives: switching to UP code
>         Power down.
>         shutdown requested in cpu_handle_ioreq
>         Issued domain 2 poweroff
>         
> Whereas in the failing case it cuts off after "stopping all md devices".
> 
> 13675 failed another sequence, lets assume for unrelated reasons. The
> delta in the commits is just:
> 
> 25844:0a9a4549e6b9 powernow: Update P-state directly when _PSD's CoordType 
> is DOMAIN_COORD_TYPE_HW_ALL
> 25843:51090fe1ab97 x86/HVM: assorted RTC emulation adjustments
> 
> The first is a host level thing which I doubt would so consistently
> effect HVM guests (and anyway, Intel tests are also failing). Which
> pretty much leaves 25843:51090fe1ab97 or some weird heisenbug.
> 
> Is it outside the realms of possibility that the guest has managed to
> limp along with the RTC being broken in some subtle way and only
> eventually trips up when we come to shut down?

That's certainly not impossible, but afaik Linux doesn't play with
the RTC unless told to by user space (whereas Windows, as we
know from the reporter of the problem that triggered putting
together these changes, does on its own at least under certain
circumstances, yet the Windows tests all go through fine).

Certainly this is the most likely candidate for having broken
something, and hence would be the prime candidate for reverting.
But before doing so, I'd want to see at least another run's results.

> Looking back at 13675, is it possible that:
> 
> 25842:a1f73e989c24 x86/hvm: don't give vector callback higher priority than 
> NMI/MCE
> 
> is exposing a race in the guest or something? I very much doubt any NMI
> or MCE are being injected at all though.

So do I.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 12 10:07:51 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Sep 2012 10:07:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TBjqz-00078E-0z; Wed, 12 Sep 2012 10:07: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 1TBjqw-000789-Rt
	for xen-devel@lists.xen.org; Wed, 12 Sep 2012 10:07:27 +0000
Received: from [85.158.143.99:4720] by server-2.bemta-4.messagelabs.com id
	8E/F9-21239-EDE50505; Wed, 12 Sep 2012 10:07:26 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1347444445!20301495!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQyODU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1221 invoked from network); 12 Sep 2012 10:07:25 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-14.tower-216.messagelabs.com with SMTP;
	12 Sep 2012 10:07:25 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 12 Sep 2012 11:07:24 +0100
Message-Id: <50507B32020000780009AC9C@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 12 Sep 2012 11:08:18 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Campbell" <Ian.Campbell@citrix.com>
References: <osstest-13677-mainreport@xen.org>
	<5050606D020000780009AC5E@nat28.tlf.novell.com>
	<1347443324.24226.30.camel@zakaz.uk.xensource.com>
In-Reply-To: <1347443324.24226.30.camel@zakaz.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [xen-unstable test] 13677: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.09.12 at 11:48, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> On Wed, 2012-09-12 at 09:14 +0100, Jan Beulich wrote:
>> >>> On 11.09.12 at 19:28, xen.org <ian.jackson@eu.citrix.com> wrote:
>> > flight 13677 xen-unstable real [real]
>> > http://www.chiark.greenend.org.uk/~xensrcts/logs/13677/ 
>> > 
>> > Regressions :-(
>> > 
>> > Tests which did not succeed and are blocking,
>> > including tests which could not be run:
>> >  test-amd64-i386-rhel6hvm-amd  8 guest-stop                fail REGR. vs. 
> 13668
>> >  test-amd64-i386-qemuu-rhel6hvm-amd  8 guest-stop          fail REGR. vs. 
> 13668
>> >  test-amd64-i386-qemuu-rhel6hvm-intel  8 guest-stop        fail REGR. vs. 
> 13668
>> >  test-amd64-i386-rhel6hvm-intel  8 guest-stop              fail REGR. vs. 
> 13668
>> 
>> While it seems very likely that if any, one of the two changes
>> of mine under test here have caused this, looking through the
>> logs I can't spot anything that would tell me what's wrong.
>> According to var-log-xen-qemu-dm-redhat.guest.osstest.log,
>> the guest went down (but it didn't even enter "dying" mode
>> yet according to the diagnostic output in the serial log). Nor
>> can I see any close relation between the behavior and the
>> changsets under test...
> 
> Looking at test-amd64-i386-rhel6hvm-amd in flight 13675 which succeeded
> the guest log ends:
>         Halting system...
>         type=1128 audit(1347348133.094:15071): user pid=1432 uid=0 
> auid=4294967295 ses=4294967295 msg='init: exe="/sbin/reboot" hostname=? 
> addr=? terminal=console res=success'
>         md: stopping all md devices.
>         xenbus_dev_shutdown: device/vkbd/0: Initialising != Connected, 
> skipping
>         xenbus_dev_shutdown: device/vbd/5632: Closed != Connected, skipping
>         ACPI: Preparing to enter system sleep state S5
>         Disabling non-boot CPUs ...
>         Broke affinity for irq 4
>         Broke affinity for irq 12
>         SMP alternatives: switching to UP code
>         Power down.
>         shutdown requested in cpu_handle_ioreq
>         Issued domain 2 poweroff
>         
> Whereas in the failing case it cuts off after "stopping all md devices".
> 
> 13675 failed another sequence, lets assume for unrelated reasons. The
> delta in the commits is just:
> 
> 25844:0a9a4549e6b9 powernow: Update P-state directly when _PSD's CoordType 
> is DOMAIN_COORD_TYPE_HW_ALL
> 25843:51090fe1ab97 x86/HVM: assorted RTC emulation adjustments
> 
> The first is a host level thing which I doubt would so consistently
> effect HVM guests (and anyway, Intel tests are also failing). Which
> pretty much leaves 25843:51090fe1ab97 or some weird heisenbug.
> 
> Is it outside the realms of possibility that the guest has managed to
> limp along with the RTC being broken in some subtle way and only
> eventually trips up when we come to shut down?

That's certainly not impossible, but afaik Linux doesn't play with
the RTC unless told to by user space (whereas Windows, as we
know from the reporter of the problem that triggered putting
together these changes, does on its own at least under certain
circumstances, yet the Windows tests all go through fine).

Certainly this is the most likely candidate for having broken
something, and hence would be the prime candidate for reverting.
But before doing so, I'd want to see at least another run's results.

> Looking back at 13675, is it possible that:
> 
> 25842:a1f73e989c24 x86/hvm: don't give vector callback higher priority than 
> NMI/MCE
> 
> is exposing a race in the guest or something? I very much doubt any NMI
> or MCE are being injected at all though.

So do I.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 12 10:09:21 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Sep 2012 10:09: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 1TBjsT-0007CG-GW; Wed, 12 Sep 2012 10:09:01 +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 1TBjsS-0007C2-Dx
	for xen-devel@lists.xensource.com; Wed, 12 Sep 2012 10:09:00 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1347444533!2997318!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDg4MjM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23087 invoked from network); 12 Sep 2012 10:08:53 -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;
	12 Sep 2012 10:08:53 -0000
X-IronPort-AV: E=Sophos;i="4.80,408,1344211200"; d="scan'208";a="14491340"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Sep 2012 10:08: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.279.1;
	Wed, 12 Sep 2012 11:08:53 +0100
Message-ID: <1347444531.24226.33.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 12 Sep 2012 11:08:51 +0100
In-Reply-To: <osstest-13683-mainreport@xen.org>
References: <osstest-13683-mainreport@xen.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [xen-4.0-testing test] 13683: regressions -
 trouble: blocked/broken/fail/pass
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-09-12 at 10:57 +0100, xen.org wrote:
> flight 13683 xen-4.0-testing real [real]
> http://www.chiark.greenend.org.uk/~xensrcts/logs/13683/
> 
> Regressions :-(
> 
> Tests which did not succeed and are blocking,
> including tests which could not be run:
>  build-i386                    4 xen-build                 fail REGR. vs. 13650

This one is a real failure:
        In file included from ./config-host.h:21,
                         from ./qemu-common.h:34,
                         from qemu-nbd.c:21:
        ./xen-config-host.h:31: error: expected '=', ',', ';', 'asm' or '__attribute__' before '*' token
        make[3]: *** [qemu-nbd.o] Error 1
        make[3]: *** Waiting for unfinished jobs....
        
[...]
> ------------------------------------------------------------
> changeset:   21616:512168f88df9
> tag:         tip
> user:        Ian Jackson <Ian.Jackson@eu.citrix.com>
> date:        Tue Sep 11 14:35:26 2012 +0100
>     
>     QEMU_TAG update

This is:
-QEMU_TAG := 091149d364e893e643a5da3175c3f84d2163cb3e
-# Wed Sep 5 12:31:40 2012 +0100                                                
-# console: bounds check whenever changing the cursor due to an escape code     
+QEMU_TAG ?= d7d453f51459b591faa96d1c123b5bfff7c5b6b6
+# Thu Sep 6 17:05:30 2012 +0100
+# Disable qemu monitor by default.  The qemu monitor is an overly
 

But d7.... is a commit in qemu-xen-4.1-testing.git. The correct commit
in qemu-xen-4.0-testing.git is eaa1bd612f50d2f253738ed19e14981e4ede98a5.

Not sure why it didn't fail when cloning this repo -- I guess it was
actually able to resolve the 4.1-testing commit, but then failed to
build it...

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 12 10:09:21 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Sep 2012 10:09: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 1TBjsT-0007CG-GW; Wed, 12 Sep 2012 10:09:01 +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 1TBjsS-0007C2-Dx
	for xen-devel@lists.xensource.com; Wed, 12 Sep 2012 10:09:00 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1347444533!2997318!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDg4MjM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23087 invoked from network); 12 Sep 2012 10:08:53 -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;
	12 Sep 2012 10:08:53 -0000
X-IronPort-AV: E=Sophos;i="4.80,408,1344211200"; d="scan'208";a="14491340"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Sep 2012 10:08: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.279.1;
	Wed, 12 Sep 2012 11:08:53 +0100
Message-ID: <1347444531.24226.33.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 12 Sep 2012 11:08:51 +0100
In-Reply-To: <osstest-13683-mainreport@xen.org>
References: <osstest-13683-mainreport@xen.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [xen-4.0-testing test] 13683: regressions -
 trouble: blocked/broken/fail/pass
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-09-12 at 10:57 +0100, xen.org wrote:
> flight 13683 xen-4.0-testing real [real]
> http://www.chiark.greenend.org.uk/~xensrcts/logs/13683/
> 
> Regressions :-(
> 
> Tests which did not succeed and are blocking,
> including tests which could not be run:
>  build-i386                    4 xen-build                 fail REGR. vs. 13650

This one is a real failure:
        In file included from ./config-host.h:21,
                         from ./qemu-common.h:34,
                         from qemu-nbd.c:21:
        ./xen-config-host.h:31: error: expected '=', ',', ';', 'asm' or '__attribute__' before '*' token
        make[3]: *** [qemu-nbd.o] Error 1
        make[3]: *** Waiting for unfinished jobs....
        
[...]
> ------------------------------------------------------------
> changeset:   21616:512168f88df9
> tag:         tip
> user:        Ian Jackson <Ian.Jackson@eu.citrix.com>
> date:        Tue Sep 11 14:35:26 2012 +0100
>     
>     QEMU_TAG update

This is:
-QEMU_TAG := 091149d364e893e643a5da3175c3f84d2163cb3e
-# Wed Sep 5 12:31:40 2012 +0100                                                
-# console: bounds check whenever changing the cursor due to an escape code     
+QEMU_TAG ?= d7d453f51459b591faa96d1c123b5bfff7c5b6b6
+# Thu Sep 6 17:05:30 2012 +0100
+# Disable qemu monitor by default.  The qemu monitor is an overly
 

But d7.... is a commit in qemu-xen-4.1-testing.git. The correct commit
in qemu-xen-4.0-testing.git is eaa1bd612f50d2f253738ed19e14981e4ede98a5.

Not sure why it didn't fail when cloning this repo -- I guess it was
actually able to resolve the 4.1-testing commit, but then failed to
build it...

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 12 10:12:48 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Sep 2012 10: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 1TBjvs-0007N5-8E; Wed, 12 Sep 2012 10:12: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 1TBjvq-0007Mx-D9
	for xen-devel@lists.xen.org; Wed, 12 Sep 2012 10:12:30 +0000
Received: from [85.158.143.35:54387] by server-2.bemta-4.messagelabs.com id
	4C/54-21239-D0060505; Wed, 12 Sep 2012 10:12:29 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1347444723!14267997!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDg4MjM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12471 invoked from network); 12 Sep 2012 10:12:04 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Sep 2012 10:12:04 -0000
X-IronPort-AV: E=Sophos;i="4.80,408,1344211200"; d="scan'208";a="14491431"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Sep 2012 10:12: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.279.1;
	Wed, 12 Sep 2012 11:12:03 +0100
Message-ID: <1347444721.24226.35.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Wed, 12 Sep 2012 11:12:01 +0100
In-Reply-To: <50507B32020000780009AC9C@nat28.tlf.novell.com>
References: <osstest-13677-mainreport@xen.org>
	<5050606D020000780009AC5E@nat28.tlf.novell.com>
	<1347443324.24226.30.camel@zakaz.uk.xensource.com>
	<50507B32020000780009AC9C@nat28.tlf.novell.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [xen-unstable test] 13677: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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-09-12 at 11:08 +0100, Jan Beulich wrote:
> > Is it outside the realms of possibility that the guest has managed to
> > limp along with the RTC being broken in some subtle way and only
> > eventually trips up when we come to shut down?
> 
> That's certainly not impossible, but afaik Linux doesn't play with
> the RTC unless told to by user space

I did wonder about an /etc/init.d/hwclock type thing, but I think that
would have run much earlier than this point.

>  (whereas Windows, as we
> know from the reporter of the problem that triggered putting
> together these changes, does on its own at least under certain
> circumstances, yet the Windows tests all go through fine).
> 
> Certainly this is the most likely candidate for having broken
> something, and hence would be the prime candidate for reverting.
> But before doing so, I'd want to see at least another run's results.

Ack. I'm installing a RHEL6.1 HVM guest anyway, since it's handy to have
one in my pocket.

The bisector also ought to make short work of this number of changesets.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 12 10:12:48 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Sep 2012 10: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 1TBjvs-0007N5-8E; Wed, 12 Sep 2012 10:12: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 1TBjvq-0007Mx-D9
	for xen-devel@lists.xen.org; Wed, 12 Sep 2012 10:12:30 +0000
Received: from [85.158.143.35:54387] by server-2.bemta-4.messagelabs.com id
	4C/54-21239-D0060505; Wed, 12 Sep 2012 10:12:29 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1347444723!14267997!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDg4MjM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12471 invoked from network); 12 Sep 2012 10:12:04 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Sep 2012 10:12:04 -0000
X-IronPort-AV: E=Sophos;i="4.80,408,1344211200"; d="scan'208";a="14491431"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Sep 2012 10:12: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.279.1;
	Wed, 12 Sep 2012 11:12:03 +0100
Message-ID: <1347444721.24226.35.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Wed, 12 Sep 2012 11:12:01 +0100
In-Reply-To: <50507B32020000780009AC9C@nat28.tlf.novell.com>
References: <osstest-13677-mainreport@xen.org>
	<5050606D020000780009AC5E@nat28.tlf.novell.com>
	<1347443324.24226.30.camel@zakaz.uk.xensource.com>
	<50507B32020000780009AC9C@nat28.tlf.novell.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [xen-unstable test] 13677: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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-09-12 at 11:08 +0100, Jan Beulich wrote:
> > Is it outside the realms of possibility that the guest has managed to
> > limp along with the RTC being broken in some subtle way and only
> > eventually trips up when we come to shut down?
> 
> That's certainly not impossible, but afaik Linux doesn't play with
> the RTC unless told to by user space

I did wonder about an /etc/init.d/hwclock type thing, but I think that
would have run much earlier than this point.

>  (whereas Windows, as we
> know from the reporter of the problem that triggered putting
> together these changes, does on its own at least under certain
> circumstances, yet the Windows tests all go through fine).
> 
> Certainly this is the most likely candidate for having broken
> something, and hence would be the prime candidate for reverting.
> But before doing so, I'd want to see at least another run's results.

Ack. I'm installing a RHEL6.1 HVM guest anyway, since it's handy to have
one in my pocket.

The bisector also ought to make short work of this number of changesets.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 12 10:25:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Sep 2012 10:25:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TBk7u-0007cm-4O; Wed, 12 Sep 2012 10:24:58 +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 1TBk7s-0007cW-VS
	for xen-devel@lists.xen.org; Wed, 12 Sep 2012 10:24:57 +0000
Received: from [85.158.138.51:59150] by server-11.bemta-3.messagelabs.com id
	B3/E2-30250-8F260505; Wed, 12 Sep 2012 10:24:56 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1347445495!30025088!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDg4MjM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19363 invoked from network); 12 Sep 2012 10:24:55 -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 Sep 2012 10:24:55 -0000
X-IronPort-AV: E=Sophos;i="4.80,408,1344211200"; d="scan'208";a="14491793"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Sep 2012 10:24: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.279.1; Wed, 12 Sep 2012 11:24:55 +0100
Date: Wed, 12 Sep 2012 11:24:14 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Jeffrey Karrels <karrelsj@gmail.com>
In-Reply-To: <CAFw--Dche2NB0jjBdMyAYC=S92XkW9UpsaBsTRBcX4ZP_oOcxA@mail.gmail.com>
Message-ID: <alpine.DEB.2.02.1209121123480.15568@kaball.uk.xensource.com>
References: <CAFw--Dd0k7L+T_UJc0yHAkUGrY_-GDHaQjK3OM-1UdOp=J-wAQ@mail.gmail.com>
	<20120907085036.GA71093@ocelot.phlegethon.org>
	<CAFw--DdYkAo79TeZKDFZ5ZdaN4KiLmW2qcceY+cTxuLMdE3QGA@mail.gmail.com>
	<CAFw--Dche2NB0jjBdMyAYC=S92XkW9UpsaBsTRBcX4ZP_oOcxA@mail.gmail.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>, "Tim \(Xen.org\)" <tim@xen.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Clang/LLVM version requirements
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 11 Sep 2012, Jeffrey Karrels wrote:
> On Fri, Sep 7, 2012 at 8:58 AM, Jeffrey Karrels <karrelsj@gmail.com> wrote:
> >> Looks like the clang build has bitrotted a little - sorry.  It's too
> >> late to fix this for 4.2 now but we can sort it out after we branch
> >> (i.e. next week) and backport any build fixes for 4.2.1.
> 
> Just to keep the knowledge in the collective... I updated my clang and
> llvm to the latest trunk:
> 
> [builder@xenbuild1 xen-unstable]$ /usr/local/bin/clang -v
> clang version 3.2 (trunk 163631)
> Target: x86_64-unknown-linux-gnu
> Thread model: posix
> 
> After that I applied the patch that Tim previously posted and tried
> another make. The xen build succeeded.

time to add a clang build target to the test system?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 12 10:25:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Sep 2012 10:25:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TBk7u-0007cm-4O; Wed, 12 Sep 2012 10:24:58 +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 1TBk7s-0007cW-VS
	for xen-devel@lists.xen.org; Wed, 12 Sep 2012 10:24:57 +0000
Received: from [85.158.138.51:59150] by server-11.bemta-3.messagelabs.com id
	B3/E2-30250-8F260505; Wed, 12 Sep 2012 10:24:56 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1347445495!30025088!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDg4MjM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19363 invoked from network); 12 Sep 2012 10:24:55 -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 Sep 2012 10:24:55 -0000
X-IronPort-AV: E=Sophos;i="4.80,408,1344211200"; d="scan'208";a="14491793"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Sep 2012 10:24: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.279.1; Wed, 12 Sep 2012 11:24:55 +0100
Date: Wed, 12 Sep 2012 11:24:14 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Jeffrey Karrels <karrelsj@gmail.com>
In-Reply-To: <CAFw--Dche2NB0jjBdMyAYC=S92XkW9UpsaBsTRBcX4ZP_oOcxA@mail.gmail.com>
Message-ID: <alpine.DEB.2.02.1209121123480.15568@kaball.uk.xensource.com>
References: <CAFw--Dd0k7L+T_UJc0yHAkUGrY_-GDHaQjK3OM-1UdOp=J-wAQ@mail.gmail.com>
	<20120907085036.GA71093@ocelot.phlegethon.org>
	<CAFw--DdYkAo79TeZKDFZ5ZdaN4KiLmW2qcceY+cTxuLMdE3QGA@mail.gmail.com>
	<CAFw--Dche2NB0jjBdMyAYC=S92XkW9UpsaBsTRBcX4ZP_oOcxA@mail.gmail.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>, "Tim \(Xen.org\)" <tim@xen.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Clang/LLVM version requirements
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 11 Sep 2012, Jeffrey Karrels wrote:
> On Fri, Sep 7, 2012 at 8:58 AM, Jeffrey Karrels <karrelsj@gmail.com> wrote:
> >> Looks like the clang build has bitrotted a little - sorry.  It's too
> >> late to fix this for 4.2 now but we can sort it out after we branch
> >> (i.e. next week) and backport any build fixes for 4.2.1.
> 
> Just to keep the knowledge in the collective... I updated my clang and
> llvm to the latest trunk:
> 
> [builder@xenbuild1 xen-unstable]$ /usr/local/bin/clang -v
> clang version 3.2 (trunk 163631)
> Target: x86_64-unknown-linux-gnu
> Thread model: posix
> 
> After that I applied the patch that Tim previously posted and tried
> another make. The xen build succeeded.

time to add a clang build target to the test system?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 12 10:29:20 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Sep 2012 10:29:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TBkBq-0007uo-QO; Wed, 12 Sep 2012 10:29:02 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <linux@eikelenboom.it>) id 1TBkBp-0007uU-6q
	for xen-devel@lists.xen.org; Wed, 12 Sep 2012 10:29:01 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-13.tower-27.messagelabs.com!1347445732!9598510!1
X-Originating-IP: [188.40.164.121]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22149 invoked from network); 12 Sep 2012 10:28:53 -0000
Received: from static.121.164.40.188.clients.your-server.de (HELO
	smtp.eikelenboom.it) (188.40.164.121)
	by server-13.tower-27.messagelabs.com with AES256-SHA encrypted SMTP;
	12 Sep 2012 10:28:53 -0000
Received: from 128-64-ftth.onsneteindhoven.nl ([88.159.64.128]:53052
	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 1TBkBw-0000e2-En; Wed, 12 Sep 2012 12:29:08 +0200
Date: Wed, 12 Sep 2012 12:28:48 +0200
From: Sander Eikelenboom <linux@eikelenboom.it>
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <1901811929.20120912122848@eikelenboom.it>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
In-Reply-To: <alpine.DEB.2.02.1209111652590.15568@kaball.uk.xensource.com>
References: <1136369816.20120904183757@eikelenboom.it>
	<20120904163347.GH23361@phenom.dumpdata.com>
	<143844933.20120904191941@eikelenboom.it>
	<CAOvdn6U_yHgtZwv9MWazdLbd3NLq3pwGXnZY5sL2UVBhV_FUoQ@mail.gmail.com>
	<1813712325.20120904213459@eikelenboom.it>
	<048EAD622912254A9DEA24C1734613C18C864C3C5D@FTLPMAILBOX02.citrite.net>
	<20120905140600.GA5844@phenom.dumpdata.com>
	<alpine.DEB.2.02.1209111652590.15568@kaball.uk.xensource.com>
MIME-Version: 1.0
Cc: Robert Phillips <robert.phillips@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Ben Guthro <ben@guthro.net>, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] dom0 linux 3.6.0-rc4,
	crash due to ballooning althoug dom0_mem=X, max:X 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


Tuesday, September 11, 2012, 6:02:47 PM, you wrote:

> On Wed, 5 Sep 2012, Konrad Rzeszutek Wilk wrote:
>> On Tue, Sep 04, 2012 at 04:27:20PM -0400, Robert Phillips wrote:
>> > Ben,
>> > 
>> > You have asked me to provide the rationale behind the gnttab_old_mfn patch, which you emailed to Sander earlier today. 
>> > Here are my findings.
>> > 
>> > I found that xen_blkbk_map() in drivers/block/xen-blkback/blkback.c has changed from our previous version.  It now calls gnttab_map_refs() in drivers/xen/grant-table.c.
>> > 
>> > That function first calls HYPERVISOR_grant_table_op(GNTTABOP_map_grant_ref, ... ) and then calls m2p_add_override() in p2m.c
>> 
>> And HYPERVISOR_grant_table_op .. would populate map_ops[i].bus_addr with the machine address..
>> 
>> > which is where I made my change.
>> > 
>> > The unpatched code was saving the pfn's old mfn in kmap_op->dev_bus_addr.  
>> > 
>> > kmap_op is of type struct gnttab_map_grant_ref.  That data type is used to record grant table mappings so later they can be unmapped correctly.
>> 
>> Right, but the blkback makes a distinction by passing NULL as kmap_op, which means it should
>> use the old mechanism. Meaning that once the hypercall is done, the map_ops[i].bus_addr is not
>> used anymore..
>> 
>> > 
>> > The problem with saving the old mfn in kmap_op->dev_bus_addr is that it is later overwritten by __gnttab_map_grant_ref() in xen/common/grant_table.c
>> 
>> Uh, so the problem of saving the old mfn in dev_bus_addr has been there for a long long time then?
>> Even before this patch set?

> I think that Robert identified the real problem: dev_bus_addr shouldn't
> have been used here. However the bug only shows up if we are batching
> the grant table operations, that we started doing since
> f62805f1f30a40e354bd036b4cb799863a39be4b.
> That's why Sander's bisection found that
> f62805f1f30a40e354bd036b4cb799863a39be4b is the culprit.

> However the fix is incorrect because it is modifying a struct that is
> part of the Xen ABI.
> I am appending an alternative fix that doesn't need any changes to
> public headers.

> Sander, could you please let me know if it fixes the problem for you?

It does !

Tested-By: Sander Eikelenboom <linux@eikelenboom.it>

> ---


> diff --git a/arch/x86/include/asm/xen/page.h b/arch/x86/include/asm/xen/page.h
> index 93971e8..472b9b7 100644
> --- a/arch/x86/include/asm/xen/page.h
> +++ b/arch/x86/include/asm/xen/page.h
> @@ -51,7 +51,8 @@ extern unsigned long set_phys_range_identity(unsigned long pfn_s,
>  
>  extern int m2p_add_override(unsigned long mfn, struct page *page,
>                             struct gnttab_map_grant_ref *kmap_op);
> -extern int m2p_remove_override(struct page *page, bool clear_pte);
> +extern int m2p_remove_override(struct page *page,
> +                               struct gnttab_map_grant_ref *kmap_op);
>  extern struct page *m2p_find_override(unsigned long mfn);
>  extern unsigned long m2p_find_override_pfn(unsigned long mfn, unsigned long pfn);
>  
> diff --git a/arch/x86/xen/p2m.c b/arch/x86/xen/p2m.c
> index 64effdc..2825594 100644
> --- a/arch/x86/xen/p2m.c
> +++ b/arch/x86/xen/p2m.c
> @@ -734,9 +734,6 @@ int m2p_add_override(unsigned long mfn, struct page *page,
>  
>                         xen_mc_issue(PARAVIRT_LAZY_MMU);
>                 }
> -               /* let's use dev_bus_addr to record the old mfn instead */
> -               kmap_op->dev_bus_addr = page->index;
> -               page->index = (unsigned long) kmap_op;
>         }
>         spin_lock_irqsave(&m2p_override_lock, flags);
>         list_add(&page->lru,  &m2p_overrides[mfn_hash(mfn)]);
> @@ -763,7 +760,8 @@ int m2p_add_override(unsigned long mfn, struct page *page,
>         return 0;
>  }
>  EXPORT_SYMBOL_GPL(m2p_add_override);
> -int m2p_remove_override(struct page *page, bool clear_pte)
> +int m2p_remove_override(struct page *page,
> +               struct gnttab_map_grant_ref *kmap_op)
>  {
>         unsigned long flags;
>         unsigned long mfn;
> @@ -793,10 +791,8 @@ int m2p_remove_override(struct page *page, bool clear_pte)
>         WARN_ON(!PagePrivate(page));
>         ClearPagePrivate(page);
>  
> -       if (clear_pte) {
> -               struct gnttab_map_grant_ref *map_op =
> -                       (struct gnttab_map_grant_ref *) page->index;
> -               set_phys_to_machine(pfn, map_op->dev_bus_addr);
> +       set_phys_to_machine(pfn, page->index);
> +       if (kmap_op != NULL) {
>                 if (!PageHighMem(page)) {
>                         struct multicall_space mcs;
>                         struct gnttab_unmap_grant_ref *unmap_op;
> @@ -808,13 +804,13 @@ int m2p_remove_override(struct page *page, bool clear_pte)
>                          * issued. In this case handle is going to -1 because
>                          * it hasn't been modified yet.
>                          */
> -                       if (map_op->handle == -1)
> +                       if (kmap_op->handle == -1)
>                                 xen_mc_flush();
>                         /*
> -                        * Now if map_op->handle is negative it means that the
> +                        * Now if kmap_op->handle is negative it means that the
>                          * hypercall actually returned an error.
>                          */
> -                       if (map_op->handle == GNTST_general_error) {
> +                       if (kmap_op->handle == GNTST_general_error) {
>                                 printk(KERN_WARNING "m2p_remove_override: "
>                                                 "pfn %lx mfn %lx, failed to modify kernel mappings",
>                                                 pfn, mfn);
> @@ -824,8 +820,8 @@ int m2p_remove_override(struct page *page, bool clear_pte)
>                         mcs = xen_mc_entry(
>                                         sizeof(struct gnttab_unmap_grant_ref));
>                         unmap_op = mcs.args;
> -                       unmap_op->host_addr = map_op->host_addr;
> -                       unmap_op->handle = map_op->handle;
> +                       unmap_op->host_addr = kmap_op->host_addr;
> +                       unmap_op->handle = kmap_op->handle;
>                         unmap_op->dev_bus_addr = 0;
>  
>                         MULTI_grant_table_op(mcs.mc,
> @@ -836,10 +832,9 @@ int m2p_remove_override(struct page *page, bool clear_pte)
>                         set_pte_at(&init_mm, address, ptep,
>                                         pfn_pte(pfn, PAGE_KERNEL));
>                         __flush_tlb_single(address);
> -                       map_op->host_addr = 0;
> +                       kmap_op->host_addr = 0;
>                 }
> -       } 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
> diff --git a/drivers/block/xen-blkback/blkback.c b/drivers/block/xen-blkback/blkback.c
> index 73f196c..c6decb9 100644
> --- a/drivers/block/xen-blkback/blkback.c
> +++ b/drivers/block/xen-blkback/blkback.c
> @@ -337,7 +337,7 @@ static void xen_blkbk_unmap(struct pending_req *req)
>                 invcount++;
>         }
>  
> -       ret = gnttab_unmap_refs(unmap, pages, invcount, false);
> +       ret = gnttab_unmap_refs(unmap, NULL, pages, invcount);
>         BUG_ON(ret);
>  }
>  
> diff --git a/drivers/xen/gntdev.c b/drivers/xen/gntdev.c
> index 1ffd03b..7f12416 100644
> --- a/drivers/xen/gntdev.c
> +++ b/drivers/xen/gntdev.c
> @@ -314,8 +314,9 @@ static int __unmap_grant_pages(struct grant_map *map, int offset, int pages)
>                 }
>         }
>  
> -       err = gnttab_unmap_refs(map->unmap_ops + offset, map->pages + offset,
> -                               pages, true);
> +       err = gnttab_unmap_refs(map->unmap_ops + offset,
> +                       use_ptemod ? map->kmap_ops + offset : NULL, map->pages + offset,
> +                       pages);
>         if (err)
>                 return err;
>  
> diff --git a/drivers/xen/grant-table.c b/drivers/xen/grant-table.c
> index 0bfc1ef..0067266 100644
> --- a/drivers/xen/grant-table.c
> +++ b/drivers/xen/grant-table.c
> @@ -870,7 +870,8 @@ int gnttab_map_refs(struct gnttab_map_grant_ref *map_ops,
>  EXPORT_SYMBOL_GPL(gnttab_map_refs);
>  
>  int gnttab_unmap_refs(struct gnttab_unmap_grant_ref *unmap_ops,
> -                     struct page **pages, unsigned int count, bool clear_pte)
> +                     struct gnttab_map_grant_ref *kmap_ops,
> +                     struct page **pages, unsigned int count)
>  {
>         int i, ret;
>         bool lazy = false;
> @@ -888,7 +889,8 @@ int gnttab_unmap_refs(struct gnttab_unmap_grant_ref *unmap_ops,
>         }
>  
>         for (i = 0; i < count; i++) {
> -               ret = m2p_remove_override(pages[i], clear_pte);
> +               ret = m2p_remove_override(pages[i], kmap_ops ?
> +                                      &kmap_ops[i] : NULL);
>                 if (ret)
>                         return ret;
>         }
> diff --git a/include/xen/grant_table.h b/include/xen/grant_table.h
> index 11e27c3..f19fff8 100644
> --- a/include/xen/grant_table.h
> +++ b/include/xen/grant_table.h
> @@ -187,6 +187,7 @@ int gnttab_map_refs(struct gnttab_map_grant_ref *map_ops,
>                     struct gnttab_map_grant_ref *kmap_ops,
>                     struct page **pages, unsigned int count);
>  int gnttab_unmap_refs(struct gnttab_unmap_grant_ref *unmap_ops,
> -                     struct page **pages, unsigned int count, bool clear_pte);
> +                     struct gnttab_map_grant_ref *kunmap_ops,
> +                     struct page **pages, unsigned int count);
>  
>  #endif /* __ASM_GNTTAB_H__ */



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 12 10:29:20 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Sep 2012 10:29:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TBkBq-0007uo-QO; Wed, 12 Sep 2012 10:29:02 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <linux@eikelenboom.it>) id 1TBkBp-0007uU-6q
	for xen-devel@lists.xen.org; Wed, 12 Sep 2012 10:29:01 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-13.tower-27.messagelabs.com!1347445732!9598510!1
X-Originating-IP: [188.40.164.121]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22149 invoked from network); 12 Sep 2012 10:28:53 -0000
Received: from static.121.164.40.188.clients.your-server.de (HELO
	smtp.eikelenboom.it) (188.40.164.121)
	by server-13.tower-27.messagelabs.com with AES256-SHA encrypted SMTP;
	12 Sep 2012 10:28:53 -0000
Received: from 128-64-ftth.onsneteindhoven.nl ([88.159.64.128]:53052
	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 1TBkBw-0000e2-En; Wed, 12 Sep 2012 12:29:08 +0200
Date: Wed, 12 Sep 2012 12:28:48 +0200
From: Sander Eikelenboom <linux@eikelenboom.it>
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <1901811929.20120912122848@eikelenboom.it>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
In-Reply-To: <alpine.DEB.2.02.1209111652590.15568@kaball.uk.xensource.com>
References: <1136369816.20120904183757@eikelenboom.it>
	<20120904163347.GH23361@phenom.dumpdata.com>
	<143844933.20120904191941@eikelenboom.it>
	<CAOvdn6U_yHgtZwv9MWazdLbd3NLq3pwGXnZY5sL2UVBhV_FUoQ@mail.gmail.com>
	<1813712325.20120904213459@eikelenboom.it>
	<048EAD622912254A9DEA24C1734613C18C864C3C5D@FTLPMAILBOX02.citrite.net>
	<20120905140600.GA5844@phenom.dumpdata.com>
	<alpine.DEB.2.02.1209111652590.15568@kaball.uk.xensource.com>
MIME-Version: 1.0
Cc: Robert Phillips <robert.phillips@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Ben Guthro <ben@guthro.net>, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] dom0 linux 3.6.0-rc4,
	crash due to ballooning althoug dom0_mem=X, max:X 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


Tuesday, September 11, 2012, 6:02:47 PM, you wrote:

> On Wed, 5 Sep 2012, Konrad Rzeszutek Wilk wrote:
>> On Tue, Sep 04, 2012 at 04:27:20PM -0400, Robert Phillips wrote:
>> > Ben,
>> > 
>> > You have asked me to provide the rationale behind the gnttab_old_mfn patch, which you emailed to Sander earlier today. 
>> > Here are my findings.
>> > 
>> > I found that xen_blkbk_map() in drivers/block/xen-blkback/blkback.c has changed from our previous version.  It now calls gnttab_map_refs() in drivers/xen/grant-table.c.
>> > 
>> > That function first calls HYPERVISOR_grant_table_op(GNTTABOP_map_grant_ref, ... ) and then calls m2p_add_override() in p2m.c
>> 
>> And HYPERVISOR_grant_table_op .. would populate map_ops[i].bus_addr with the machine address..
>> 
>> > which is where I made my change.
>> > 
>> > The unpatched code was saving the pfn's old mfn in kmap_op->dev_bus_addr.  
>> > 
>> > kmap_op is of type struct gnttab_map_grant_ref.  That data type is used to record grant table mappings so later they can be unmapped correctly.
>> 
>> Right, but the blkback makes a distinction by passing NULL as kmap_op, which means it should
>> use the old mechanism. Meaning that once the hypercall is done, the map_ops[i].bus_addr is not
>> used anymore..
>> 
>> > 
>> > The problem with saving the old mfn in kmap_op->dev_bus_addr is that it is later overwritten by __gnttab_map_grant_ref() in xen/common/grant_table.c
>> 
>> Uh, so the problem of saving the old mfn in dev_bus_addr has been there for a long long time then?
>> Even before this patch set?

> I think that Robert identified the real problem: dev_bus_addr shouldn't
> have been used here. However the bug only shows up if we are batching
> the grant table operations, that we started doing since
> f62805f1f30a40e354bd036b4cb799863a39be4b.
> That's why Sander's bisection found that
> f62805f1f30a40e354bd036b4cb799863a39be4b is the culprit.

> However the fix is incorrect because it is modifying a struct that is
> part of the Xen ABI.
> I am appending an alternative fix that doesn't need any changes to
> public headers.

> Sander, could you please let me know if it fixes the problem for you?

It does !

Tested-By: Sander Eikelenboom <linux@eikelenboom.it>

> ---


> diff --git a/arch/x86/include/asm/xen/page.h b/arch/x86/include/asm/xen/page.h
> index 93971e8..472b9b7 100644
> --- a/arch/x86/include/asm/xen/page.h
> +++ b/arch/x86/include/asm/xen/page.h
> @@ -51,7 +51,8 @@ extern unsigned long set_phys_range_identity(unsigned long pfn_s,
>  
>  extern int m2p_add_override(unsigned long mfn, struct page *page,
>                             struct gnttab_map_grant_ref *kmap_op);
> -extern int m2p_remove_override(struct page *page, bool clear_pte);
> +extern int m2p_remove_override(struct page *page,
> +                               struct gnttab_map_grant_ref *kmap_op);
>  extern struct page *m2p_find_override(unsigned long mfn);
>  extern unsigned long m2p_find_override_pfn(unsigned long mfn, unsigned long pfn);
>  
> diff --git a/arch/x86/xen/p2m.c b/arch/x86/xen/p2m.c
> index 64effdc..2825594 100644
> --- a/arch/x86/xen/p2m.c
> +++ b/arch/x86/xen/p2m.c
> @@ -734,9 +734,6 @@ int m2p_add_override(unsigned long mfn, struct page *page,
>  
>                         xen_mc_issue(PARAVIRT_LAZY_MMU);
>                 }
> -               /* let's use dev_bus_addr to record the old mfn instead */
> -               kmap_op->dev_bus_addr = page->index;
> -               page->index = (unsigned long) kmap_op;
>         }
>         spin_lock_irqsave(&m2p_override_lock, flags);
>         list_add(&page->lru,  &m2p_overrides[mfn_hash(mfn)]);
> @@ -763,7 +760,8 @@ int m2p_add_override(unsigned long mfn, struct page *page,
>         return 0;
>  }
>  EXPORT_SYMBOL_GPL(m2p_add_override);
> -int m2p_remove_override(struct page *page, bool clear_pte)
> +int m2p_remove_override(struct page *page,
> +               struct gnttab_map_grant_ref *kmap_op)
>  {
>         unsigned long flags;
>         unsigned long mfn;
> @@ -793,10 +791,8 @@ int m2p_remove_override(struct page *page, bool clear_pte)
>         WARN_ON(!PagePrivate(page));
>         ClearPagePrivate(page);
>  
> -       if (clear_pte) {
> -               struct gnttab_map_grant_ref *map_op =
> -                       (struct gnttab_map_grant_ref *) page->index;
> -               set_phys_to_machine(pfn, map_op->dev_bus_addr);
> +       set_phys_to_machine(pfn, page->index);
> +       if (kmap_op != NULL) {
>                 if (!PageHighMem(page)) {
>                         struct multicall_space mcs;
>                         struct gnttab_unmap_grant_ref *unmap_op;
> @@ -808,13 +804,13 @@ int m2p_remove_override(struct page *page, bool clear_pte)
>                          * issued. In this case handle is going to -1 because
>                          * it hasn't been modified yet.
>                          */
> -                       if (map_op->handle == -1)
> +                       if (kmap_op->handle == -1)
>                                 xen_mc_flush();
>                         /*
> -                        * Now if map_op->handle is negative it means that the
> +                        * Now if kmap_op->handle is negative it means that the
>                          * hypercall actually returned an error.
>                          */
> -                       if (map_op->handle == GNTST_general_error) {
> +                       if (kmap_op->handle == GNTST_general_error) {
>                                 printk(KERN_WARNING "m2p_remove_override: "
>                                                 "pfn %lx mfn %lx, failed to modify kernel mappings",
>                                                 pfn, mfn);
> @@ -824,8 +820,8 @@ int m2p_remove_override(struct page *page, bool clear_pte)
>                         mcs = xen_mc_entry(
>                                         sizeof(struct gnttab_unmap_grant_ref));
>                         unmap_op = mcs.args;
> -                       unmap_op->host_addr = map_op->host_addr;
> -                       unmap_op->handle = map_op->handle;
> +                       unmap_op->host_addr = kmap_op->host_addr;
> +                       unmap_op->handle = kmap_op->handle;
>                         unmap_op->dev_bus_addr = 0;
>  
>                         MULTI_grant_table_op(mcs.mc,
> @@ -836,10 +832,9 @@ int m2p_remove_override(struct page *page, bool clear_pte)
>                         set_pte_at(&init_mm, address, ptep,
>                                         pfn_pte(pfn, PAGE_KERNEL));
>                         __flush_tlb_single(address);
> -                       map_op->host_addr = 0;
> +                       kmap_op->host_addr = 0;
>                 }
> -       } 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
> diff --git a/drivers/block/xen-blkback/blkback.c b/drivers/block/xen-blkback/blkback.c
> index 73f196c..c6decb9 100644
> --- a/drivers/block/xen-blkback/blkback.c
> +++ b/drivers/block/xen-blkback/blkback.c
> @@ -337,7 +337,7 @@ static void xen_blkbk_unmap(struct pending_req *req)
>                 invcount++;
>         }
>  
> -       ret = gnttab_unmap_refs(unmap, pages, invcount, false);
> +       ret = gnttab_unmap_refs(unmap, NULL, pages, invcount);
>         BUG_ON(ret);
>  }
>  
> diff --git a/drivers/xen/gntdev.c b/drivers/xen/gntdev.c
> index 1ffd03b..7f12416 100644
> --- a/drivers/xen/gntdev.c
> +++ b/drivers/xen/gntdev.c
> @@ -314,8 +314,9 @@ static int __unmap_grant_pages(struct grant_map *map, int offset, int pages)
>                 }
>         }
>  
> -       err = gnttab_unmap_refs(map->unmap_ops + offset, map->pages + offset,
> -                               pages, true);
> +       err = gnttab_unmap_refs(map->unmap_ops + offset,
> +                       use_ptemod ? map->kmap_ops + offset : NULL, map->pages + offset,
> +                       pages);
>         if (err)
>                 return err;
>  
> diff --git a/drivers/xen/grant-table.c b/drivers/xen/grant-table.c
> index 0bfc1ef..0067266 100644
> --- a/drivers/xen/grant-table.c
> +++ b/drivers/xen/grant-table.c
> @@ -870,7 +870,8 @@ int gnttab_map_refs(struct gnttab_map_grant_ref *map_ops,
>  EXPORT_SYMBOL_GPL(gnttab_map_refs);
>  
>  int gnttab_unmap_refs(struct gnttab_unmap_grant_ref *unmap_ops,
> -                     struct page **pages, unsigned int count, bool clear_pte)
> +                     struct gnttab_map_grant_ref *kmap_ops,
> +                     struct page **pages, unsigned int count)
>  {
>         int i, ret;
>         bool lazy = false;
> @@ -888,7 +889,8 @@ int gnttab_unmap_refs(struct gnttab_unmap_grant_ref *unmap_ops,
>         }
>  
>         for (i = 0; i < count; i++) {
> -               ret = m2p_remove_override(pages[i], clear_pte);
> +               ret = m2p_remove_override(pages[i], kmap_ops ?
> +                                      &kmap_ops[i] : NULL);
>                 if (ret)
>                         return ret;
>         }
> diff --git a/include/xen/grant_table.h b/include/xen/grant_table.h
> index 11e27c3..f19fff8 100644
> --- a/include/xen/grant_table.h
> +++ b/include/xen/grant_table.h
> @@ -187,6 +187,7 @@ int gnttab_map_refs(struct gnttab_map_grant_ref *map_ops,
>                     struct gnttab_map_grant_ref *kmap_ops,
>                     struct page **pages, unsigned int count);
>  int gnttab_unmap_refs(struct gnttab_unmap_grant_ref *unmap_ops,
> -                     struct page **pages, unsigned int count, bool clear_pte);
> +                     struct gnttab_map_grant_ref *kunmap_ops,
> +                     struct page **pages, unsigned int count);
>  
>  #endif /* __ASM_GNTTAB_H__ */



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 12 10:32:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Sep 2012 10: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 1TBkEj-000842-EO; Wed, 12 Sep 2012 10:32:01 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1TBkEh-00083t-IB
	for xen-devel@lists.xen.org; Wed, 12 Sep 2012 10:31:59 +0000
Received: from [85.158.143.35:62874] by server-1.bemta-4.messagelabs.com id
	8D/21-12504-E9460505; Wed, 12 Sep 2012 10:31:58 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-14.tower-21.messagelabs.com!1347445906!17952876!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2686 invoked from network); 12 Sep 2012 10:31:48 -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; 12 Sep 2012 10:31:48 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1TBkET-000PiY-En; Wed, 12 Sep 2012 10:31:45 +0000
Date: Wed, 12 Sep 2012 11:31:45 +0100
From: Tim Deegan <tim@xen.org>
To: Jeffrey Karrels <karrelsj@gmail.com>
Message-ID: <20120912103145.GB97347@ocelot.phlegethon.org>
References: <CAFw--Dd0k7L+T_UJc0yHAkUGrY_-GDHaQjK3OM-1UdOp=J-wAQ@mail.gmail.com>
	<20120907085036.GA71093@ocelot.phlegethon.org>
	<CAFw--DdYkAo79TeZKDFZ5ZdaN4KiLmW2qcceY+cTxuLMdE3QGA@mail.gmail.com>
	<CAFw--Dche2NB0jjBdMyAYC=S92XkW9UpsaBsTRBcX4ZP_oOcxA@mail.gmail.com>
	<CAFw--Dd0k7L+T_UJc0yHAkUGrY_-GDHaQjK3OM-1UdOp=J-wAQ@mail.gmail.com>
	<20120907085036.GA71093@ocelot.phlegethon.org>
	<CAFw--DdYkAo79TeZKDFZ5ZdaN4KiLmW2qcceY+cTxuLMdE3QGA@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAFw--Dche2NB0jjBdMyAYC=S92XkW9UpsaBsTRBcX4ZP_oOcxA@mail.gmail.com>
	<CAFw--DdYkAo79TeZKDFZ5ZdaN4KiLmW2qcceY+cTxuLMdE3QGA@mail.gmail.com>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Clang/LLVM version requirements
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At 08:58 -0700 on 07 Sep (1347008330), Jeffrey Karrels wrote:
> > Looks like the clang build has bitrotted a little - sorry.  It's too
> > late to fix this for 4.2 now but we can sort it out after we branch
> > (i.e. next week) and backport any build fixes for 4.2.1.
> >
> 
> No worries. I can try and help out on this. Do you think it is
> worthwhile to start a Wiki page for this type of work.

Yes, I think so.  Lars Kurth can sort you out with whatever
accounts/permissions you need.

> I was working with cppcheck, sparse, clang on/for xen...

That all sounds great.  I'm in favour of any more analysis we can get,
at least if it doesn't need intrusive annotations.

At 11:43 -0700 on 11 Sep (1347363829), Jeffrey Karrels wrote:
> Just to keep the knowledge in the collective... I updated my clang and
> llvm to the latest trunk:
> 
> [builder@xenbuild1 xen-unstable]$ /usr/local/bin/clang -v
> clang version 3.2 (trunk 163631)
> Target: x86_64-unknown-linux-gnu
> Thread model: posix
> 
> After that I applied the patch that Tim previously posted and tried
> another make. The xen build succeeded.

Glad to hear it.  I'll sort out a better version of that patch
(i.e. that doesn't just remove the code but reimplements it in a
clang-friendly way) tomorrow.

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 12 10:32:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Sep 2012 10: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 1TBkEj-000842-EO; Wed, 12 Sep 2012 10:32:01 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1TBkEh-00083t-IB
	for xen-devel@lists.xen.org; Wed, 12 Sep 2012 10:31:59 +0000
Received: from [85.158.143.35:62874] by server-1.bemta-4.messagelabs.com id
	8D/21-12504-E9460505; Wed, 12 Sep 2012 10:31:58 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-14.tower-21.messagelabs.com!1347445906!17952876!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2686 invoked from network); 12 Sep 2012 10:31:48 -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; 12 Sep 2012 10:31:48 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1TBkET-000PiY-En; Wed, 12 Sep 2012 10:31:45 +0000
Date: Wed, 12 Sep 2012 11:31:45 +0100
From: Tim Deegan <tim@xen.org>
To: Jeffrey Karrels <karrelsj@gmail.com>
Message-ID: <20120912103145.GB97347@ocelot.phlegethon.org>
References: <CAFw--Dd0k7L+T_UJc0yHAkUGrY_-GDHaQjK3OM-1UdOp=J-wAQ@mail.gmail.com>
	<20120907085036.GA71093@ocelot.phlegethon.org>
	<CAFw--DdYkAo79TeZKDFZ5ZdaN4KiLmW2qcceY+cTxuLMdE3QGA@mail.gmail.com>
	<CAFw--Dche2NB0jjBdMyAYC=S92XkW9UpsaBsTRBcX4ZP_oOcxA@mail.gmail.com>
	<CAFw--Dd0k7L+T_UJc0yHAkUGrY_-GDHaQjK3OM-1UdOp=J-wAQ@mail.gmail.com>
	<20120907085036.GA71093@ocelot.phlegethon.org>
	<CAFw--DdYkAo79TeZKDFZ5ZdaN4KiLmW2qcceY+cTxuLMdE3QGA@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAFw--Dche2NB0jjBdMyAYC=S92XkW9UpsaBsTRBcX4ZP_oOcxA@mail.gmail.com>
	<CAFw--DdYkAo79TeZKDFZ5ZdaN4KiLmW2qcceY+cTxuLMdE3QGA@mail.gmail.com>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Clang/LLVM version requirements
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At 08:58 -0700 on 07 Sep (1347008330), Jeffrey Karrels wrote:
> > Looks like the clang build has bitrotted a little - sorry.  It's too
> > late to fix this for 4.2 now but we can sort it out after we branch
> > (i.e. next week) and backport any build fixes for 4.2.1.
> >
> 
> No worries. I can try and help out on this. Do you think it is
> worthwhile to start a Wiki page for this type of work.

Yes, I think so.  Lars Kurth can sort you out with whatever
accounts/permissions you need.

> I was working with cppcheck, sparse, clang on/for xen...

That all sounds great.  I'm in favour of any more analysis we can get,
at least if it doesn't need intrusive annotations.

At 11:43 -0700 on 11 Sep (1347363829), Jeffrey Karrels wrote:
> Just to keep the knowledge in the collective... I updated my clang and
> llvm to the latest trunk:
> 
> [builder@xenbuild1 xen-unstable]$ /usr/local/bin/clang -v
> clang version 3.2 (trunk 163631)
> Target: x86_64-unknown-linux-gnu
> Thread model: posix
> 
> After that I applied the patch that Tim previously posted and tried
> another make. The xen build succeeded.

Glad to hear it.  I'll sort out a better version of that patch
(i.e. that doesn't just remove the code but reimplements it in a
clang-friendly way) tomorrow.

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 12 10:35:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Sep 2012 10: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 1TBkHo-0008H6-EX; Wed, 12 Sep 2012 10:35:12 +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 1TBkHn-0008Gl-J6
	for xen-devel@lists.xen.org; Wed, 12 Sep 2012 10:35:11 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1347446105!9424202!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDg4MjM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21160 invoked from network); 12 Sep 2012 10:35:05 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Sep 2012 10:35:05 -0000
X-IronPort-AV: E=Sophos;i="4.80,408,1344211200"; d="scan'208";a="14492051"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Sep 2012 10:35: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.279.1;
	Wed, 12 Sep 2012 11:35:05 +0100
Message-ID: <1347446103.24226.41.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Wed, 12 Sep 2012 11:35:03 +0100
In-Reply-To: <1347444721.24226.35.camel@zakaz.uk.xensource.com>
References: <osstest-13677-mainreport@xen.org>
	<5050606D020000780009AC5E@nat28.tlf.novell.com>
	<1347443324.24226.30.camel@zakaz.uk.xensource.com>
	<50507B32020000780009AC9C@nat28.tlf.novell.com>
	<1347444721.24226.35.camel@zakaz.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [xen-unstable test] 13677: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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-09-12 at 11:12 +0100, Ian Campbell wrote:
> On Wed, 2012-09-12 at 11:08 +0100, Jan Beulich wrote:
> > > Is it outside the realms of possibility that the guest has managed to
> > > limp along with the RTC being broken in some subtle way and only
> > > eventually trips up when we come to shut down?
> > 
> > That's certainly not impossible, but afaik Linux doesn't play with
> > the RTC unless told to by user space
> 
> I did wonder about an /etc/init.d/hwclock type thing, but I think that
> would have run much earlier than this point.
> 
> >  (whereas Windows, as we
> > know from the reporter of the problem that triggered putting
> > together these changes, does on its own at least under certain
> > circumstances, yet the Windows tests all go through fine).
> > 
> > Certainly this is the most likely candidate for having broken
> > something, and hence would be the prime candidate for reverting.
> > But before doing so, I'd want to see at least another run's results.
> 
> Ack. I'm installing a RHEL6.1 HVM guest anyway, since it's handy to have
> one in my pocket.

25876:35fa512c60b2 "gnttab: cleanup of number-of-active-frames
calculations" for both => hangs:
        Syncing hardware clock to system time [  OK  ]
        Turning off swap:  [  OK  ]
        Unmounting file systems:  [  OK  ]
        init: Re-executing /sbin/init
        <silence>

Reverting just 25843:51090fe1ab97 "x86/HVM: assorted RTC emulation
adjustments" on top of 35fa... => works again.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 12 10:35:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Sep 2012 10: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 1TBkHo-0008H6-EX; Wed, 12 Sep 2012 10:35:12 +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 1TBkHn-0008Gl-J6
	for xen-devel@lists.xen.org; Wed, 12 Sep 2012 10:35:11 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1347446105!9424202!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDg4MjM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21160 invoked from network); 12 Sep 2012 10:35:05 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Sep 2012 10:35:05 -0000
X-IronPort-AV: E=Sophos;i="4.80,408,1344211200"; d="scan'208";a="14492051"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Sep 2012 10:35: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.279.1;
	Wed, 12 Sep 2012 11:35:05 +0100
Message-ID: <1347446103.24226.41.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Wed, 12 Sep 2012 11:35:03 +0100
In-Reply-To: <1347444721.24226.35.camel@zakaz.uk.xensource.com>
References: <osstest-13677-mainreport@xen.org>
	<5050606D020000780009AC5E@nat28.tlf.novell.com>
	<1347443324.24226.30.camel@zakaz.uk.xensource.com>
	<50507B32020000780009AC9C@nat28.tlf.novell.com>
	<1347444721.24226.35.camel@zakaz.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [xen-unstable test] 13677: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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-09-12 at 11:12 +0100, Ian Campbell wrote:
> On Wed, 2012-09-12 at 11:08 +0100, Jan Beulich wrote:
> > > Is it outside the realms of possibility that the guest has managed to
> > > limp along with the RTC being broken in some subtle way and only
> > > eventually trips up when we come to shut down?
> > 
> > That's certainly not impossible, but afaik Linux doesn't play with
> > the RTC unless told to by user space
> 
> I did wonder about an /etc/init.d/hwclock type thing, but I think that
> would have run much earlier than this point.
> 
> >  (whereas Windows, as we
> > know from the reporter of the problem that triggered putting
> > together these changes, does on its own at least under certain
> > circumstances, yet the Windows tests all go through fine).
> > 
> > Certainly this is the most likely candidate for having broken
> > something, and hence would be the prime candidate for reverting.
> > But before doing so, I'd want to see at least another run's results.
> 
> Ack. I'm installing a RHEL6.1 HVM guest anyway, since it's handy to have
> one in my pocket.

25876:35fa512c60b2 "gnttab: cleanup of number-of-active-frames
calculations" for both => hangs:
        Syncing hardware clock to system time [  OK  ]
        Turning off swap:  [  OK  ]
        Unmounting file systems:  [  OK  ]
        init: Re-executing /sbin/init
        <silence>

Reverting just 25843:51090fe1ab97 "x86/HVM: assorted RTC emulation
adjustments" on top of 35fa... => works again.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 12 10:39:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Sep 2012 10: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 1TBkLU-0008Se-2g; Wed, 12 Sep 2012 10:39: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 1TBkLS-0008SX-G8
	for xen-devel@lists.xen.org; Wed, 12 Sep 2012 10:38:58 +0000
Received: from [85.158.139.83:23973] by server-9.bemta-5.messagelabs.com id
	21/DE-20529-14660505; Wed, 12 Sep 2012 10:38:57 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1347446337!22829685!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDg4MjM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9592 invoked from network); 12 Sep 2012 10:38:57 -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 Sep 2012 10:38:57 -0000
X-IronPort-AV: E=Sophos;i="4.80,408,1344211200"; d="scan'208";a="14492144"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Sep 2012 10:38: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.279.1;
	Wed, 12 Sep 2012 11:38:14 +0100
Message-ID: <1347446293.24226.42.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Tim Deegan <tim@xen.org>
Date: Wed, 12 Sep 2012 11:38:13 +0100
In-Reply-To: <20120912103145.GB97347@ocelot.phlegethon.org>
References: <CAFw--Dd0k7L+T_UJc0yHAkUGrY_-GDHaQjK3OM-1UdOp=J-wAQ@mail.gmail.com>
	<20120907085036.GA71093@ocelot.phlegethon.org>
	<CAFw--DdYkAo79TeZKDFZ5ZdaN4KiLmW2qcceY+cTxuLMdE3QGA@mail.gmail.com>
	<CAFw--Dche2NB0jjBdMyAYC=S92XkW9UpsaBsTRBcX4ZP_oOcxA@mail.gmail.com>
	<CAFw--Dd0k7L+T_UJc0yHAkUGrY_-GDHaQjK3OM-1UdOp=J-wAQ@mail.gmail.com>
	<20120907085036.GA71093@ocelot.phlegethon.org>
	<CAFw--DdYkAo79TeZKDFZ5ZdaN4KiLmW2qcceY+cTxuLMdE3QGA@mail.gmail.com>
	<20120912103145.GB97347@ocelot.phlegethon.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Jeffrey Karrels <karrelsj@gmail.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Clang/LLVM version requirements
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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-09-12 at 11:31 +0100, Tim Deegan wrote:
> At 08:58 -0700 on 07 Sep (1347008330), Jeffrey Karrels wrote:
> > > Looks like the clang build has bitrotted a little - sorry.  It's too
> > > late to fix this for 4.2 now but we can sort it out after we branch
> > > (i.e. next week) and backport any build fixes for 4.2.1.
> > >
> > 
> > No worries. I can try and help out on this. Do you think it is
> > worthwhile to start a Wiki page for this type of work.
> 
> Yes, I think so.  Lars Kurth can sort you out with whatever
> accounts/permissions you need.

I think you just need to sign up. The new wiki has captcha and such so
no need to be approved by anyone etc like with the old wiki.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 12 10:39:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Sep 2012 10: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 1TBkLU-0008Se-2g; Wed, 12 Sep 2012 10:39: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 1TBkLS-0008SX-G8
	for xen-devel@lists.xen.org; Wed, 12 Sep 2012 10:38:58 +0000
Received: from [85.158.139.83:23973] by server-9.bemta-5.messagelabs.com id
	21/DE-20529-14660505; Wed, 12 Sep 2012 10:38:57 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1347446337!22829685!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDg4MjM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9592 invoked from network); 12 Sep 2012 10:38:57 -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 Sep 2012 10:38:57 -0000
X-IronPort-AV: E=Sophos;i="4.80,408,1344211200"; d="scan'208";a="14492144"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Sep 2012 10:38: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.279.1;
	Wed, 12 Sep 2012 11:38:14 +0100
Message-ID: <1347446293.24226.42.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Tim Deegan <tim@xen.org>
Date: Wed, 12 Sep 2012 11:38:13 +0100
In-Reply-To: <20120912103145.GB97347@ocelot.phlegethon.org>
References: <CAFw--Dd0k7L+T_UJc0yHAkUGrY_-GDHaQjK3OM-1UdOp=J-wAQ@mail.gmail.com>
	<20120907085036.GA71093@ocelot.phlegethon.org>
	<CAFw--DdYkAo79TeZKDFZ5ZdaN4KiLmW2qcceY+cTxuLMdE3QGA@mail.gmail.com>
	<CAFw--Dche2NB0jjBdMyAYC=S92XkW9UpsaBsTRBcX4ZP_oOcxA@mail.gmail.com>
	<CAFw--Dd0k7L+T_UJc0yHAkUGrY_-GDHaQjK3OM-1UdOp=J-wAQ@mail.gmail.com>
	<20120907085036.GA71093@ocelot.phlegethon.org>
	<CAFw--DdYkAo79TeZKDFZ5ZdaN4KiLmW2qcceY+cTxuLMdE3QGA@mail.gmail.com>
	<20120912103145.GB97347@ocelot.phlegethon.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Jeffrey Karrels <karrelsj@gmail.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Clang/LLVM version requirements
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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-09-12 at 11:31 +0100, Tim Deegan wrote:
> At 08:58 -0700 on 07 Sep (1347008330), Jeffrey Karrels wrote:
> > > Looks like the clang build has bitrotted a little - sorry.  It's too
> > > late to fix this for 4.2 now but we can sort it out after we branch
> > > (i.e. next week) and backport any build fixes for 4.2.1.
> > >
> > 
> > No worries. I can try and help out on this. Do you think it is
> > worthwhile to start a Wiki page for this type of work.
> 
> Yes, I think so.  Lars Kurth can sort you out with whatever
> accounts/permissions you need.

I think you just need to sign up. The new wiki has captcha and such so
no need to be approved by anyone etc like with the old wiki.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 12 10:42:39 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Sep 2012 10:42:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TBkOn-0000CJ-N3; Wed, 12 Sep 2012 10:42:25 +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 1TBkOm-0000By-6G
	for xen-devel@lists.xensource.com; Wed, 12 Sep 2012 10:42:24 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1347446460!10713734!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDg4MjM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9581 invoked from network); 12 Sep 2012 10:41:00 -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;
	12 Sep 2012 10:41:00 -0000
X-IronPort-AV: E=Sophos;i="4.80,408,1344211200"; d="scan'208";a="14492223"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Sep 2012 10:40: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.279.1; Wed, 12 Sep 2012 11:40: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
	1TBkNP-0006ac-Hf; Wed, 12 Sep 2012 10:40:59 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1TBkNP-0001rB-8x;
	Wed, 12 Sep 2012 11:40:59 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20560.26298.989157.971262@mariner.uk.xensource.com>
Date: Wed, 12 Sep 2012 11:40:58 +0100
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1347444531.24226.33.camel@zakaz.uk.xensource.com>
References: <osstest-13683-mainreport@xen.org>
	<1347444531.24226.33.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-4.0-testing test] 13683: regressions -
 trouble: blocked/broken/fail/pass
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("Re: [Xen-devel] [xen-4.0-testing test] 13683: regressions - trouble: blocked/broken/fail/pass"):
> +QEMU_TAG ?= d7d453f51459b591faa96d1c123b5bfff7c5b6b6
> +# Thu Sep 6 17:05:30 2012 +0100
> +# Disable qemu monitor by default.  The qemu monitor is an overly
>  
> 
> But d7.... is a commit in qemu-xen-4.1-testing.git. The correct commit
> in qemu-xen-4.0-testing.git is eaa1bd612f50d2f253738ed19e14981e4ede98a5.

This is my fault.  My shonky script for updating these (which I was
editing yesterday) had a bug that meant it always used the current
branch of my source git repo rather than the right branch, for finding
the tag value (although it would push the correcct thing).  I have
fixed it.

It seems that only 4.0 was affected.

> Not sure why it didn't fail when cloning this repo -- I guess it was
> actually able to resolve the 4.1-testing commit, but then failed to
> build it...

These repos tend to have a lot of surplus commits in because they all
have all the tags.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 12 10:42:39 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Sep 2012 10:42:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TBkOn-0000CJ-N3; Wed, 12 Sep 2012 10:42:25 +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 1TBkOm-0000By-6G
	for xen-devel@lists.xensource.com; Wed, 12 Sep 2012 10:42:24 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1347446460!10713734!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDg4MjM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9581 invoked from network); 12 Sep 2012 10:41:00 -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;
	12 Sep 2012 10:41:00 -0000
X-IronPort-AV: E=Sophos;i="4.80,408,1344211200"; d="scan'208";a="14492223"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Sep 2012 10:40: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.279.1; Wed, 12 Sep 2012 11:40: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
	1TBkNP-0006ac-Hf; Wed, 12 Sep 2012 10:40:59 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1TBkNP-0001rB-8x;
	Wed, 12 Sep 2012 11:40:59 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20560.26298.989157.971262@mariner.uk.xensource.com>
Date: Wed, 12 Sep 2012 11:40:58 +0100
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1347444531.24226.33.camel@zakaz.uk.xensource.com>
References: <osstest-13683-mainreport@xen.org>
	<1347444531.24226.33.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-4.0-testing test] 13683: regressions -
 trouble: blocked/broken/fail/pass
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("Re: [Xen-devel] [xen-4.0-testing test] 13683: regressions - trouble: blocked/broken/fail/pass"):
> +QEMU_TAG ?= d7d453f51459b591faa96d1c123b5bfff7c5b6b6
> +# Thu Sep 6 17:05:30 2012 +0100
> +# Disable qemu monitor by default.  The qemu monitor is an overly
>  
> 
> But d7.... is a commit in qemu-xen-4.1-testing.git. The correct commit
> in qemu-xen-4.0-testing.git is eaa1bd612f50d2f253738ed19e14981e4ede98a5.

This is my fault.  My shonky script for updating these (which I was
editing yesterday) had a bug that meant it always used the current
branch of my source git repo rather than the right branch, for finding
the tag value (although it would push the correcct thing).  I have
fixed it.

It seems that only 4.0 was affected.

> Not sure why it didn't fail when cloning this repo -- I guess it was
> actually able to resolve the 4.1-testing commit, but then failed to
> build it...

These repos tend to have a lot of surplus commits in because they all
have all the tags.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 12 11:15:16 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Sep 2012 11:15:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TBku8-0000Ua-DT; Wed, 12 Sep 2012 11:14:48 +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 1TBku7-0000UU-0C
	for xen-devel@lists.xen.org; Wed, 12 Sep 2012 11:14:47 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1347448477!10717659!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQyODU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30483 invoked from network); 12 Sep 2012 11:14:37 -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;
	12 Sep 2012 11:14:37 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 12 Sep 2012 12:14:34 +0100
Message-Id: <50508AEF020000780009ACD4@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 12 Sep 2012 12:15:27 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Campbell" <Ian.Campbell@citrix.com>
References: <osstest-13677-mainreport@xen.org>
	<5050606D020000780009AC5E@nat28.tlf.novell.com>
	<1347443324.24226.30.camel@zakaz.uk.xensource.com>
	<50507B32020000780009AC9C@nat28.tlf.novell.com>
	<1347444721.24226.35.camel@zakaz.uk.xensource.com>
	<1347446103.24226.41.camel@zakaz.uk.xensource.com>
In-Reply-To: <1347446103.24226.41.camel@zakaz.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [xen-unstable test] 13677: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.09.12 at 12:35, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> On Wed, 2012-09-12 at 11:12 +0100, Ian Campbell wrote:
>> On Wed, 2012-09-12 at 11:08 +0100, Jan Beulich wrote:
>> > > Is it outside the realms of possibility that the guest has managed to
>> > > limp along with the RTC being broken in some subtle way and only
>> > > eventually trips up when we come to shut down?
>> > 
>> > That's certainly not impossible, but afaik Linux doesn't play with
>> > the RTC unless told to by user space
>> 
>> I did wonder about an /etc/init.d/hwclock type thing, but I think that
>> would have run much earlier than this point.
>> 
>> >  (whereas Windows, as we
>> > know from the reporter of the problem that triggered putting
>> > together these changes, does on its own at least under certain
>> > circumstances, yet the Windows tests all go through fine).
>> > 
>> > Certainly this is the most likely candidate for having broken
>> > something, and hence would be the prime candidate for reverting.
>> > But before doing so, I'd want to see at least another run's results.
>> 
>> Ack. I'm installing a RHEL6.1 HVM guest anyway, since it's handy to have
>> one in my pocket.
> 
> 25876:35fa512c60b2 "gnttab: cleanup of number-of-active-frames
> calculations" for both => hangs:
>         Syncing hardware clock to system time [  OK  ]
>         Turning off swap:  [  OK  ]
>         Unmounting file systems:  [  OK  ]
>         init: Re-executing /sbin/init
>         <silence>
> 
> Reverting just 25843:51090fe1ab97 "x86/HVM: assorted RTC emulation
> adjustments" on top of 35fa... => works again.

In that case I'll just revert it in -unstable too. No idea what's wrong
with it, though.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 12 11:15:16 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Sep 2012 11:15:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TBku8-0000Ua-DT; Wed, 12 Sep 2012 11:14:48 +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 1TBku7-0000UU-0C
	for xen-devel@lists.xen.org; Wed, 12 Sep 2012 11:14:47 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1347448477!10717659!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQyODU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30483 invoked from network); 12 Sep 2012 11:14:37 -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;
	12 Sep 2012 11:14:37 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 12 Sep 2012 12:14:34 +0100
Message-Id: <50508AEF020000780009ACD4@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 12 Sep 2012 12:15:27 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Campbell" <Ian.Campbell@citrix.com>
References: <osstest-13677-mainreport@xen.org>
	<5050606D020000780009AC5E@nat28.tlf.novell.com>
	<1347443324.24226.30.camel@zakaz.uk.xensource.com>
	<50507B32020000780009AC9C@nat28.tlf.novell.com>
	<1347444721.24226.35.camel@zakaz.uk.xensource.com>
	<1347446103.24226.41.camel@zakaz.uk.xensource.com>
In-Reply-To: <1347446103.24226.41.camel@zakaz.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [xen-unstable test] 13677: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.09.12 at 12:35, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> On Wed, 2012-09-12 at 11:12 +0100, Ian Campbell wrote:
>> On Wed, 2012-09-12 at 11:08 +0100, Jan Beulich wrote:
>> > > Is it outside the realms of possibility that the guest has managed to
>> > > limp along with the RTC being broken in some subtle way and only
>> > > eventually trips up when we come to shut down?
>> > 
>> > That's certainly not impossible, but afaik Linux doesn't play with
>> > the RTC unless told to by user space
>> 
>> I did wonder about an /etc/init.d/hwclock type thing, but I think that
>> would have run much earlier than this point.
>> 
>> >  (whereas Windows, as we
>> > know from the reporter of the problem that triggered putting
>> > together these changes, does on its own at least under certain
>> > circumstances, yet the Windows tests all go through fine).
>> > 
>> > Certainly this is the most likely candidate for having broken
>> > something, and hence would be the prime candidate for reverting.
>> > But before doing so, I'd want to see at least another run's results.
>> 
>> Ack. I'm installing a RHEL6.1 HVM guest anyway, since it's handy to have
>> one in my pocket.
> 
> 25876:35fa512c60b2 "gnttab: cleanup of number-of-active-frames
> calculations" for both => hangs:
>         Syncing hardware clock to system time [  OK  ]
>         Turning off swap:  [  OK  ]
>         Unmounting file systems:  [  OK  ]
>         init: Re-executing /sbin/init
>         <silence>
> 
> Reverting just 25843:51090fe1ab97 "x86/HVM: assorted RTC emulation
> adjustments" on top of 35fa... => works again.

In that case I'll just revert it in -unstable too. No idea what's wrong
with it, though.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 12 11:30:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Sep 2012 11:30:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TBl8Y-0000ek-UG; Wed, 12 Sep 2012 11:29:42 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1TBl8X-0000ef-Fe
	for xen-devel@lists.xen.org; Wed, 12 Sep 2012 11:29:41 +0000
Received: from [85.158.143.35:8044] by server-2.bemta-4.messagelabs.com id
	80/00-21239-42270505; Wed, 12 Sep 2012 11:29:40 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1347449349!10206676!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDg4MjM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21238 invoked from network); 12 Sep 2012 11:29: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;
	12 Sep 2012 11:29:10 -0000
X-IronPort-AV: E=Sophos;i="4.80,408,1344211200"; d="scan'208";a="14493403"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Sep 2012 11:29:09 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Wed, 12 Sep 2012 12:29:09 +0100
Date: Wed, 12 Sep 2012 12:28:28 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Sander Eikelenboom <linux@eikelenboom.it>
In-Reply-To: <1901811929.20120912122848@eikelenboom.it>
Message-ID: <alpine.DEB.2.02.1209121228090.15568@kaball.uk.xensource.com>
References: <1136369816.20120904183757@eikelenboom.it>
	<20120904163347.GH23361@phenom.dumpdata.com>
	<143844933.20120904191941@eikelenboom.it>
	<CAOvdn6U_yHgtZwv9MWazdLbd3NLq3pwGXnZY5sL2UVBhV_FUoQ@mail.gmail.com>
	<1813712325.20120904213459@eikelenboom.it>
	<048EAD622912254A9DEA24C1734613C18C864C3C5D@FTLPMAILBOX02.citrite.net>
	<20120905140600.GA5844@phenom.dumpdata.com>
	<alpine.DEB.2.02.1209111652590.15568@kaball.uk.xensource.com>
	<1901811929.20120912122848@eikelenboom.it>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Ben Guthro <ben@guthro.net>, Robert Phillips <robert.phillips@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] dom0 linux 3.6.0-rc4,
 crash due to ballooning althoug dom0_mem=X, max:X set
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 12 Sep 2012, Sander Eikelenboom wrote:
> Tuesday, September 11, 2012, 6:02:47 PM, you wrote:
> 
> > On Wed, 5 Sep 2012, Konrad Rzeszutek Wilk wrote:
> >> On Tue, Sep 04, 2012 at 04:27:20PM -0400, Robert Phillips wrote:
> >> > Ben,
> >> > 
> >> > You have asked me to provide the rationale behind the gnttab_old_mfn patch, which you emailed to Sander earlier today. 
> >> > Here are my findings.
> >> > 
> >> > I found that xen_blkbk_map() in drivers/block/xen-blkback/blkback.c has changed from our previous version.  It now calls gnttab_map_refs() in drivers/xen/grant-table.c.
> >> > 
> >> > That function first calls HYPERVISOR_grant_table_op(GNTTABOP_map_grant_ref, ... ) and then calls m2p_add_override() in p2m.c
> >> 
> >> And HYPERVISOR_grant_table_op .. would populate map_ops[i].bus_addr with the machine address..
> >> 
> >> > which is where I made my change.
> >> > 
> >> > The unpatched code was saving the pfn's old mfn in kmap_op->dev_bus_addr.  
> >> > 
> >> > kmap_op is of type struct gnttab_map_grant_ref.  That data type is used to record grant table mappings so later they can be unmapped correctly.
> >> 
> >> Right, but the blkback makes a distinction by passing NULL as kmap_op, which means it should
> >> use the old mechanism. Meaning that once the hypercall is done, the map_ops[i].bus_addr is not
> >> used anymore..
> >> 
> >> > 
> >> > The problem with saving the old mfn in kmap_op->dev_bus_addr is that it is later overwritten by __gnttab_map_grant_ref() in xen/common/grant_table.c
> >> 
> >> Uh, so the problem of saving the old mfn in dev_bus_addr has been there for a long long time then?
> >> Even before this patch set?
> 
> > I think that Robert identified the real problem: dev_bus_addr shouldn't
> > have been used here. However the bug only shows up if we are batching
> > the grant table operations, that we started doing since
> > f62805f1f30a40e354bd036b4cb799863a39be4b.
> > That's why Sander's bisection found that
> > f62805f1f30a40e354bd036b4cb799863a39be4b is the culprit.
> 
> > However the fix is incorrect because it is modifying a struct that is
> > part of the Xen ABI.
> > I am appending an alternative fix that doesn't need any changes to
> > public headers.
> 
> > Sander, could you please let me know if it fixes the problem for you?
> 
> It does !
> 
> Tested-By: Sander Eikelenboom <linux@eikelenboom.it>
> 

Thanks for testing!


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 12 11:30:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Sep 2012 11:30:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TBl8Y-0000ek-UG; Wed, 12 Sep 2012 11:29:42 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1TBl8X-0000ef-Fe
	for xen-devel@lists.xen.org; Wed, 12 Sep 2012 11:29:41 +0000
Received: from [85.158.143.35:8044] by server-2.bemta-4.messagelabs.com id
	80/00-21239-42270505; Wed, 12 Sep 2012 11:29:40 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1347449349!10206676!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDg4MjM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21238 invoked from network); 12 Sep 2012 11:29: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;
	12 Sep 2012 11:29:10 -0000
X-IronPort-AV: E=Sophos;i="4.80,408,1344211200"; d="scan'208";a="14493403"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Sep 2012 11:29:09 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Wed, 12 Sep 2012 12:29:09 +0100
Date: Wed, 12 Sep 2012 12:28:28 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Sander Eikelenboom <linux@eikelenboom.it>
In-Reply-To: <1901811929.20120912122848@eikelenboom.it>
Message-ID: <alpine.DEB.2.02.1209121228090.15568@kaball.uk.xensource.com>
References: <1136369816.20120904183757@eikelenboom.it>
	<20120904163347.GH23361@phenom.dumpdata.com>
	<143844933.20120904191941@eikelenboom.it>
	<CAOvdn6U_yHgtZwv9MWazdLbd3NLq3pwGXnZY5sL2UVBhV_FUoQ@mail.gmail.com>
	<1813712325.20120904213459@eikelenboom.it>
	<048EAD622912254A9DEA24C1734613C18C864C3C5D@FTLPMAILBOX02.citrite.net>
	<20120905140600.GA5844@phenom.dumpdata.com>
	<alpine.DEB.2.02.1209111652590.15568@kaball.uk.xensource.com>
	<1901811929.20120912122848@eikelenboom.it>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Ben Guthro <ben@guthro.net>, Robert Phillips <robert.phillips@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] dom0 linux 3.6.0-rc4,
 crash due to ballooning althoug dom0_mem=X, max:X set
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 12 Sep 2012, Sander Eikelenboom wrote:
> Tuesday, September 11, 2012, 6:02:47 PM, you wrote:
> 
> > On Wed, 5 Sep 2012, Konrad Rzeszutek Wilk wrote:
> >> On Tue, Sep 04, 2012 at 04:27:20PM -0400, Robert Phillips wrote:
> >> > Ben,
> >> > 
> >> > You have asked me to provide the rationale behind the gnttab_old_mfn patch, which you emailed to Sander earlier today. 
> >> > Here are my findings.
> >> > 
> >> > I found that xen_blkbk_map() in drivers/block/xen-blkback/blkback.c has changed from our previous version.  It now calls gnttab_map_refs() in drivers/xen/grant-table.c.
> >> > 
> >> > That function first calls HYPERVISOR_grant_table_op(GNTTABOP_map_grant_ref, ... ) and then calls m2p_add_override() in p2m.c
> >> 
> >> And HYPERVISOR_grant_table_op .. would populate map_ops[i].bus_addr with the machine address..
> >> 
> >> > which is where I made my change.
> >> > 
> >> > The unpatched code was saving the pfn's old mfn in kmap_op->dev_bus_addr.  
> >> > 
> >> > kmap_op is of type struct gnttab_map_grant_ref.  That data type is used to record grant table mappings so later they can be unmapped correctly.
> >> 
> >> Right, but the blkback makes a distinction by passing NULL as kmap_op, which means it should
> >> use the old mechanism. Meaning that once the hypercall is done, the map_ops[i].bus_addr is not
> >> used anymore..
> >> 
> >> > 
> >> > The problem with saving the old mfn in kmap_op->dev_bus_addr is that it is later overwritten by __gnttab_map_grant_ref() in xen/common/grant_table.c
> >> 
> >> Uh, so the problem of saving the old mfn in dev_bus_addr has been there for a long long time then?
> >> Even before this patch set?
> 
> > I think that Robert identified the real problem: dev_bus_addr shouldn't
> > have been used here. However the bug only shows up if we are batching
> > the grant table operations, that we started doing since
> > f62805f1f30a40e354bd036b4cb799863a39be4b.
> > That's why Sander's bisection found that
> > f62805f1f30a40e354bd036b4cb799863a39be4b is the culprit.
> 
> > However the fix is incorrect because it is modifying a struct that is
> > part of the Xen ABI.
> > I am appending an alternative fix that doesn't need any changes to
> > public headers.
> 
> > Sander, could you please let me know if it fixes the problem for you?
> 
> It does !
> 
> Tested-By: Sander Eikelenboom <linux@eikelenboom.it>
> 

Thanks for testing!


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 12 11:36:36 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Sep 2012 11:36: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 1TBlEq-0000pt-Q1; Wed, 12 Sep 2012 11:36:12 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1TBlEp-0000pk-Ap
	for xen-devel@lists.xensource.com; Wed, 12 Sep 2012 11:36:11 +0000
Received: from [85.158.143.35:22578] by server-3.bemta-4.messagelabs.com id
	0B/D2-08232-AA370505; Wed, 12 Sep 2012 11:36:10 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1347449769!15429176!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDg4MjM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3152 invoked from network); 12 Sep 2012 11:36:09 -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;
	12 Sep 2012 11:36:09 -0000
X-IronPort-AV: E=Sophos;i="4.80,408,1344211200"; d="scan'208";a="14493597"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Sep 2012 11:36: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.279.1; Wed, 12 Sep 2012 12:36: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 1TBlEl-000734-VU;
	Wed, 12 Sep 2012 11:36:08 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1TBlEl-000640-L0;
	Wed, 12 Sep 2012 12:36:07 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-13682-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 12 Sep 2012 12:36:07 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13682: regressions - trouble:
	broken/fail/pass
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 13682 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13682/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-rhel6hvm-amd  8 guest-stop                fail REGR. vs. 13668
 test-amd64-i386-qemuu-rhel6hvm-amd  8 guest-stop          fail REGR. vs. 13668
 test-amd64-i386-rhel6hvm-intel  8 guest-stop              fail REGR. vs. 13668
 test-amd64-i386-xend-winxpsp3  3 host-install(3)        broken REGR. vs. 13668
 test-amd64-i386-win           3 host-install(3)         broken REGR. vs. 13668
 test-amd64-amd64-xl-qemuu-winxpsp3  3 host-install(3)   broken REGR. vs. 13668
 test-amd64-amd64-xl           3 host-install(3)         broken REGR. vs. 13668
 test-amd64-amd64-pv           3 host-install(3)         broken REGR. vs. 13668
 test-amd64-i386-xl-credit2    3 host-install(3)         broken REGR. vs. 13668
 test-amd64-i386-xl-multivcpu  3 host-install(3)         broken REGR. vs. 13668
 test-i386-i386-xl             3 host-install(3)         broken REGR. vs. 13668
 test-amd64-amd64-win          3 host-install(3)         broken REGR. vs. 13668
 test-i386-i386-pv             3 host-install(3)         broken REGR. vs. 13668
 test-amd64-i386-xl-win-vcpus1  3 host-install(3)        broken REGR. vs. 13668
 test-amd64-amd64-xl-qemuu-win7-amd64  3 host-install(3) broken REGR. vs. 13668
 test-amd64-i386-qemuu-rhel6hvm-intel  3 host-install(3) broken REGR. vs. 13668
 test-amd64-amd64-xl-winxpsp3  3 host-install(3)         broken REGR. vs. 13668
 test-amd64-i386-pv            3 host-install(3)         broken REGR. vs. 13668
 test-amd64-i386-win-vcpus1    3 host-install(3)         broken REGR. vs. 13668
 test-amd64-i386-xl            3 host-install(3)         broken REGR. vs. 13668
 test-amd64-amd64-xl-win       3 host-install(3)         broken REGR. vs. 13668
 test-amd64-amd64-pair        3 host-install/src_host(3) broken REGR. vs. 13668
 test-amd64-amd64-pair        4 host-install/dst_host(4) broken REGR. vs. 13668
 test-i386-i386-pair          4 host-install/dst_host(4) broken REGR. vs. 13668
 test-i386-i386-pair          3 host-install/src_host(3) broken REGR. vs. 13668
 test-amd64-i386-pair         4 host-install/dst_host(4) broken REGR. vs. 13668
 test-amd64-i386-pair         3 host-install/src_host(3) broken REGR. vs. 13668

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore            fail   like 13668
 test-i386-i386-xl-qemuu-winxpsp3  9 guest-localmigrate         fail like 13668
 test-amd64-amd64-xl-sedf      3 host-install(3)         broken REGR. vs. 13668
 test-amd64-amd64-xl-pcipt-intel  3 host-install(3)      broken REGR. vs. 13668

Tests which did not succeed, but are not blocking:
 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-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass

version targeted for testing:
 xen                  f47bc4eb8256
baseline version:
 xen                  7d770de90b7f

------------------------------------------------------------
People who touched revisions under test:
  Boris Ostrovsky <boris.ostrovsky@amd.com>
  Christoph Egger <Christoph.Egger@amd.com>
  Dan Magenheimer <dan.magenheimer@oracle.com>
  David Vrabel <david.vrabel@citrix.com>
  Ian Campbell <ian.campbell@citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Keir Fraser <keir@xen.org>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Wei Wang <wei.wang2@amd.com>
  Zhenzhong Duan <zhenzhong.duan@oracle.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                                          broken  
 test-amd64-i386-xl                                           broken  
 test-i386-i386-xl                                            broken  
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         broken  
 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                              broken  
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         broken  
 test-amd64-i386-xl-multivcpu                                 broken  
 test-amd64-amd64-pair                                        broken  
 test-amd64-i386-pair                                         broken  
 test-i386-i386-pair                                          broken  
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          broken  
 test-amd64-i386-pv                                           broken  
 test-i386-i386-pv                                            broken  
 test-amd64-amd64-xl-sedf                                     broken  
 test-amd64-i386-win-vcpus1                                   broken  
 test-amd64-i386-xl-win-vcpus1                                broken  
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         broken  
 test-amd64-i386-win                                          broken  
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      broken  
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           broken  
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                broken  
 test-amd64-amd64-xl-winxpsp3                                 broken  
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

(No revision log; it would be 494 lines long.)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 12 11:36:36 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Sep 2012 11:36: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 1TBlEq-0000pt-Q1; Wed, 12 Sep 2012 11:36:12 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1TBlEp-0000pk-Ap
	for xen-devel@lists.xensource.com; Wed, 12 Sep 2012 11:36:11 +0000
Received: from [85.158.143.35:22578] by server-3.bemta-4.messagelabs.com id
	0B/D2-08232-AA370505; Wed, 12 Sep 2012 11:36:10 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1347449769!15429176!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDg4MjM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3152 invoked from network); 12 Sep 2012 11:36:09 -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;
	12 Sep 2012 11:36:09 -0000
X-IronPort-AV: E=Sophos;i="4.80,408,1344211200"; d="scan'208";a="14493597"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Sep 2012 11:36: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.279.1; Wed, 12 Sep 2012 12:36: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 1TBlEl-000734-VU;
	Wed, 12 Sep 2012 11:36:08 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1TBlEl-000640-L0;
	Wed, 12 Sep 2012 12:36:07 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-13682-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 12 Sep 2012 12:36:07 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13682: regressions - trouble:
	broken/fail/pass
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 13682 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13682/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-rhel6hvm-amd  8 guest-stop                fail REGR. vs. 13668
 test-amd64-i386-qemuu-rhel6hvm-amd  8 guest-stop          fail REGR. vs. 13668
 test-amd64-i386-rhel6hvm-intel  8 guest-stop              fail REGR. vs. 13668
 test-amd64-i386-xend-winxpsp3  3 host-install(3)        broken REGR. vs. 13668
 test-amd64-i386-win           3 host-install(3)         broken REGR. vs. 13668
 test-amd64-amd64-xl-qemuu-winxpsp3  3 host-install(3)   broken REGR. vs. 13668
 test-amd64-amd64-xl           3 host-install(3)         broken REGR. vs. 13668
 test-amd64-amd64-pv           3 host-install(3)         broken REGR. vs. 13668
 test-amd64-i386-xl-credit2    3 host-install(3)         broken REGR. vs. 13668
 test-amd64-i386-xl-multivcpu  3 host-install(3)         broken REGR. vs. 13668
 test-i386-i386-xl             3 host-install(3)         broken REGR. vs. 13668
 test-amd64-amd64-win          3 host-install(3)         broken REGR. vs. 13668
 test-i386-i386-pv             3 host-install(3)         broken REGR. vs. 13668
 test-amd64-i386-xl-win-vcpus1  3 host-install(3)        broken REGR. vs. 13668
 test-amd64-amd64-xl-qemuu-win7-amd64  3 host-install(3) broken REGR. vs. 13668
 test-amd64-i386-qemuu-rhel6hvm-intel  3 host-install(3) broken REGR. vs. 13668
 test-amd64-amd64-xl-winxpsp3  3 host-install(3)         broken REGR. vs. 13668
 test-amd64-i386-pv            3 host-install(3)         broken REGR. vs. 13668
 test-amd64-i386-win-vcpus1    3 host-install(3)         broken REGR. vs. 13668
 test-amd64-i386-xl            3 host-install(3)         broken REGR. vs. 13668
 test-amd64-amd64-xl-win       3 host-install(3)         broken REGR. vs. 13668
 test-amd64-amd64-pair        3 host-install/src_host(3) broken REGR. vs. 13668
 test-amd64-amd64-pair        4 host-install/dst_host(4) broken REGR. vs. 13668
 test-i386-i386-pair          4 host-install/dst_host(4) broken REGR. vs. 13668
 test-i386-i386-pair          3 host-install/src_host(3) broken REGR. vs. 13668
 test-amd64-i386-pair         4 host-install/dst_host(4) broken REGR. vs. 13668
 test-amd64-i386-pair         3 host-install/src_host(3) broken REGR. vs. 13668

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore            fail   like 13668
 test-i386-i386-xl-qemuu-winxpsp3  9 guest-localmigrate         fail like 13668
 test-amd64-amd64-xl-sedf      3 host-install(3)         broken REGR. vs. 13668
 test-amd64-amd64-xl-pcipt-intel  3 host-install(3)      broken REGR. vs. 13668

Tests which did not succeed, but are not blocking:
 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-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass

version targeted for testing:
 xen                  f47bc4eb8256
baseline version:
 xen                  7d770de90b7f

------------------------------------------------------------
People who touched revisions under test:
  Boris Ostrovsky <boris.ostrovsky@amd.com>
  Christoph Egger <Christoph.Egger@amd.com>
  Dan Magenheimer <dan.magenheimer@oracle.com>
  David Vrabel <david.vrabel@citrix.com>
  Ian Campbell <ian.campbell@citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Keir Fraser <keir@xen.org>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Wei Wang <wei.wang2@amd.com>
  Zhenzhong Duan <zhenzhong.duan@oracle.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                                          broken  
 test-amd64-i386-xl                                           broken  
 test-i386-i386-xl                                            broken  
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         broken  
 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                              broken  
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         broken  
 test-amd64-i386-xl-multivcpu                                 broken  
 test-amd64-amd64-pair                                        broken  
 test-amd64-i386-pair                                         broken  
 test-i386-i386-pair                                          broken  
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          broken  
 test-amd64-i386-pv                                           broken  
 test-i386-i386-pv                                            broken  
 test-amd64-amd64-xl-sedf                                     broken  
 test-amd64-i386-win-vcpus1                                   broken  
 test-amd64-i386-xl-win-vcpus1                                broken  
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         broken  
 test-amd64-i386-win                                          broken  
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      broken  
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           broken  
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                broken  
 test-amd64-amd64-xl-winxpsp3                                 broken  
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

(No revision log; it would be 494 lines long.)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 12 11:46:36 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Sep 2012 11:46:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TBlOX-00012A-1C; Wed, 12 Sep 2012 11:46: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 1TBlOV-000122-Iz
	for xen-devel@lists.xensource.com; Wed, 12 Sep 2012 11:46:11 +0000
Received: from [85.158.138.51:2271] by server-8.bemta-3.messagelabs.com id
	E4/EE-24700-20670505; Wed, 12 Sep 2012 11:46:10 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1347450369!21253667!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDg4MjM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25575 invoked from network); 12 Sep 2012 11:46:10 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Sep 2012 11:46:10 -0000
X-IronPort-AV: E=Sophos;i="4.80,408,1344211200"; d="scan'208";a="14493878"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Sep 2012 11:45: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.279.1; Wed, 12 Sep 2012 12:45:11 +0100
Date: Wed, 12 Sep 2012 12:44:30 +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>
Message-ID: <alpine.DEB.2.02.1209121229590.15568@kaball.uk.xensource.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	linux-kernel@vger.kernel.org,
	Sander Eikelenboom <linux@eikelenboom.it>, ben@guthro.net,
	robert.phillips@citrix.com
Subject: [Xen-devel] [PATCH] xen/m2p: do not reuse kmap_op->dev_bus_addr
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

If the caller passes a valid kmap_op to m2p_add_override, we use
kmap_op->dev_bus_addr to store the original mfn, but dev_bus_addr is
part of the interface with Xen and if we are batching the hypercalls it
might not have been written by the hypervisor yet. That means that later
on Xen will write to it and we'll think that the original mfn is
actually what Xen has written to it.

Rather than "stealing" struct members from kmap_op, keep using
page->index to store the original mfn and add another parameter to
m2p_remove_override to get the corresponding kmap_op instead.
It is now responsibility of the caller to keep track of which kmap_op
corresponds to a particular page in the m2p_override (gntdev, the only
user of this interface that passes a valid kmap_op, is already doing that).

Tested-By: Sander Eikelenboom <linux@eikelenboom.it>
Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

diff --git a/arch/x86/include/asm/xen/page.h b/arch/x86/include/asm/xen/page.h
index 93971e8..472b9b7 100644
--- a/arch/x86/include/asm/xen/page.h
+++ b/arch/x86/include/asm/xen/page.h
@@ -51,7 +51,8 @@ extern unsigned long set_phys_range_identity(unsigned long pfn_s,
 
 extern int m2p_add_override(unsigned long mfn, struct page *page,
 			    struct gnttab_map_grant_ref *kmap_op);
-extern int m2p_remove_override(struct page *page, bool clear_pte);
+extern int m2p_remove_override(struct page *page,
+				struct gnttab_map_grant_ref *kmap_op);
 extern struct page *m2p_find_override(unsigned long mfn);
 extern unsigned long m2p_find_override_pfn(unsigned long mfn, unsigned long pfn);
 
diff --git a/arch/x86/xen/p2m.c b/arch/x86/xen/p2m.c
index 64effdc..2825594 100644
--- a/arch/x86/xen/p2m.c
+++ b/arch/x86/xen/p2m.c
@@ -734,9 +734,6 @@ int m2p_add_override(unsigned long mfn, struct page *page,
 
 			xen_mc_issue(PARAVIRT_LAZY_MMU);
 		}
-		/* let's use dev_bus_addr to record the old mfn instead */
-		kmap_op->dev_bus_addr = page->index;
-		page->index = (unsigned long) kmap_op;
 	}
 	spin_lock_irqsave(&m2p_override_lock, flags);
 	list_add(&page->lru,  &m2p_overrides[mfn_hash(mfn)]);
@@ -763,7 +760,8 @@ int m2p_add_override(unsigned long mfn, struct page *page,
 	return 0;
 }
 EXPORT_SYMBOL_GPL(m2p_add_override);
-int m2p_remove_override(struct page *page, bool clear_pte)
+int m2p_remove_override(struct page *page,
+		struct gnttab_map_grant_ref *kmap_op)
 {
 	unsigned long flags;
 	unsigned long mfn;
@@ -793,10 +791,8 @@ int m2p_remove_override(struct page *page, bool clear_pte)
 	WARN_ON(!PagePrivate(page));
 	ClearPagePrivate(page);
 
-	if (clear_pte) {
-		struct gnttab_map_grant_ref *map_op =
-			(struct gnttab_map_grant_ref *) page->index;
-		set_phys_to_machine(pfn, map_op->dev_bus_addr);
+	set_phys_to_machine(pfn, page->index);
+	if (kmap_op != NULL) {
 		if (!PageHighMem(page)) {
 			struct multicall_space mcs;
 			struct gnttab_unmap_grant_ref *unmap_op;
@@ -808,13 +804,13 @@ int m2p_remove_override(struct page *page, bool clear_pte)
 			 * issued. In this case handle is going to -1 because
 			 * it hasn't been modified yet.
 			 */
-			if (map_op->handle == -1)
+			if (kmap_op->handle == -1)
 				xen_mc_flush();
 			/*
-			 * Now if map_op->handle is negative it means that the
+			 * Now if kmap_op->handle is negative it means that the
 			 * hypercall actually returned an error.
 			 */
-			if (map_op->handle == GNTST_general_error) {
+			if (kmap_op->handle == GNTST_general_error) {
 				printk(KERN_WARNING "m2p_remove_override: "
 						"pfn %lx mfn %lx, failed to modify kernel mappings",
 						pfn, mfn);
@@ -824,8 +820,8 @@ int m2p_remove_override(struct page *page, bool clear_pte)
 			mcs = xen_mc_entry(
 					sizeof(struct gnttab_unmap_grant_ref));
 			unmap_op = mcs.args;
-			unmap_op->host_addr = map_op->host_addr;
-			unmap_op->handle = map_op->handle;
+			unmap_op->host_addr = kmap_op->host_addr;
+			unmap_op->handle = kmap_op->handle;
 			unmap_op->dev_bus_addr = 0;
 
 			MULTI_grant_table_op(mcs.mc,
@@ -836,10 +832,9 @@ int m2p_remove_override(struct page *page, bool clear_pte)
 			set_pte_at(&init_mm, address, ptep,
 					pfn_pte(pfn, PAGE_KERNEL));
 			__flush_tlb_single(address);
-			map_op->host_addr = 0;
+			kmap_op->host_addr = 0;
 		}
-	} 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
diff --git a/drivers/block/xen-blkback/blkback.c b/drivers/block/xen-blkback/blkback.c
index 73f196c..c6decb9 100644
--- a/drivers/block/xen-blkback/blkback.c
+++ b/drivers/block/xen-blkback/blkback.c
@@ -337,7 +337,7 @@ static void xen_blkbk_unmap(struct pending_req *req)
 		invcount++;
 	}
 
-	ret = gnttab_unmap_refs(unmap, pages, invcount, false);
+	ret = gnttab_unmap_refs(unmap, NULL, pages, invcount);
 	BUG_ON(ret);
 }
 
diff --git a/drivers/xen/gntdev.c b/drivers/xen/gntdev.c
index 1ffd03b..7f12416 100644
--- a/drivers/xen/gntdev.c
+++ b/drivers/xen/gntdev.c
@@ -314,8 +314,9 @@ static int __unmap_grant_pages(struct grant_map *map, int offset, int pages)
 		}
 	}
 
-	err = gnttab_unmap_refs(map->unmap_ops + offset, map->pages + offset,
-				pages, true);
+	err = gnttab_unmap_refs(map->unmap_ops + offset,
+			use_ptemod ? map->kmap_ops + offset : NULL, map->pages + offset,
+			pages);
 	if (err)
 		return err;
 
diff --git a/drivers/xen/grant-table.c b/drivers/xen/grant-table.c
index 0bfc1ef..0067266 100644
--- a/drivers/xen/grant-table.c
+++ b/drivers/xen/grant-table.c
@@ -870,7 +870,8 @@ int gnttab_map_refs(struct gnttab_map_grant_ref *map_ops,
 EXPORT_SYMBOL_GPL(gnttab_map_refs);
 
 int gnttab_unmap_refs(struct gnttab_unmap_grant_ref *unmap_ops,
-		      struct page **pages, unsigned int count, bool clear_pte)
+		      struct gnttab_map_grant_ref *kmap_ops,
+		      struct page **pages, unsigned int count)
 {
 	int i, ret;
 	bool lazy = false;
@@ -888,7 +889,8 @@ int gnttab_unmap_refs(struct gnttab_unmap_grant_ref *unmap_ops,
 	}
 
 	for (i = 0; i < count; i++) {
-		ret = m2p_remove_override(pages[i], clear_pte);
+		ret = m2p_remove_override(pages[i], kmap_ops ?
+				       &kmap_ops[i] : NULL);
 		if (ret)
 			return ret;
 	}
diff --git a/include/xen/grant_table.h b/include/xen/grant_table.h
index 11e27c3..f19fff8 100644
--- a/include/xen/grant_table.h
+++ b/include/xen/grant_table.h
@@ -187,6 +187,7 @@ int gnttab_map_refs(struct gnttab_map_grant_ref *map_ops,
 		    struct gnttab_map_grant_ref *kmap_ops,
 		    struct page **pages, unsigned int count);
 int gnttab_unmap_refs(struct gnttab_unmap_grant_ref *unmap_ops,
-		      struct page **pages, unsigned int count, bool clear_pte);
+		      struct gnttab_map_grant_ref *kunmap_ops,
+		      struct page **pages, unsigned int count);
 
 #endif /* __ASM_GNTTAB_H__ */

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 12 11:46:36 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Sep 2012 11:46:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TBlOX-00012A-1C; Wed, 12 Sep 2012 11:46: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 1TBlOV-000122-Iz
	for xen-devel@lists.xensource.com; Wed, 12 Sep 2012 11:46:11 +0000
Received: from [85.158.138.51:2271] by server-8.bemta-3.messagelabs.com id
	E4/EE-24700-20670505; Wed, 12 Sep 2012 11:46:10 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1347450369!21253667!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDg4MjM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25575 invoked from network); 12 Sep 2012 11:46:10 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Sep 2012 11:46:10 -0000
X-IronPort-AV: E=Sophos;i="4.80,408,1344211200"; d="scan'208";a="14493878"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Sep 2012 11:45: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.279.1; Wed, 12 Sep 2012 12:45:11 +0100
Date: Wed, 12 Sep 2012 12:44:30 +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>
Message-ID: <alpine.DEB.2.02.1209121229590.15568@kaball.uk.xensource.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	linux-kernel@vger.kernel.org,
	Sander Eikelenboom <linux@eikelenboom.it>, ben@guthro.net,
	robert.phillips@citrix.com
Subject: [Xen-devel] [PATCH] xen/m2p: do not reuse kmap_op->dev_bus_addr
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

If the caller passes a valid kmap_op to m2p_add_override, we use
kmap_op->dev_bus_addr to store the original mfn, but dev_bus_addr is
part of the interface with Xen and if we are batching the hypercalls it
might not have been written by the hypervisor yet. That means that later
on Xen will write to it and we'll think that the original mfn is
actually what Xen has written to it.

Rather than "stealing" struct members from kmap_op, keep using
page->index to store the original mfn and add another parameter to
m2p_remove_override to get the corresponding kmap_op instead.
It is now responsibility of the caller to keep track of which kmap_op
corresponds to a particular page in the m2p_override (gntdev, the only
user of this interface that passes a valid kmap_op, is already doing that).

Tested-By: Sander Eikelenboom <linux@eikelenboom.it>
Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

diff --git a/arch/x86/include/asm/xen/page.h b/arch/x86/include/asm/xen/page.h
index 93971e8..472b9b7 100644
--- a/arch/x86/include/asm/xen/page.h
+++ b/arch/x86/include/asm/xen/page.h
@@ -51,7 +51,8 @@ extern unsigned long set_phys_range_identity(unsigned long pfn_s,
 
 extern int m2p_add_override(unsigned long mfn, struct page *page,
 			    struct gnttab_map_grant_ref *kmap_op);
-extern int m2p_remove_override(struct page *page, bool clear_pte);
+extern int m2p_remove_override(struct page *page,
+				struct gnttab_map_grant_ref *kmap_op);
 extern struct page *m2p_find_override(unsigned long mfn);
 extern unsigned long m2p_find_override_pfn(unsigned long mfn, unsigned long pfn);
 
diff --git a/arch/x86/xen/p2m.c b/arch/x86/xen/p2m.c
index 64effdc..2825594 100644
--- a/arch/x86/xen/p2m.c
+++ b/arch/x86/xen/p2m.c
@@ -734,9 +734,6 @@ int m2p_add_override(unsigned long mfn, struct page *page,
 
 			xen_mc_issue(PARAVIRT_LAZY_MMU);
 		}
-		/* let's use dev_bus_addr to record the old mfn instead */
-		kmap_op->dev_bus_addr = page->index;
-		page->index = (unsigned long) kmap_op;
 	}
 	spin_lock_irqsave(&m2p_override_lock, flags);
 	list_add(&page->lru,  &m2p_overrides[mfn_hash(mfn)]);
@@ -763,7 +760,8 @@ int m2p_add_override(unsigned long mfn, struct page *page,
 	return 0;
 }
 EXPORT_SYMBOL_GPL(m2p_add_override);
-int m2p_remove_override(struct page *page, bool clear_pte)
+int m2p_remove_override(struct page *page,
+		struct gnttab_map_grant_ref *kmap_op)
 {
 	unsigned long flags;
 	unsigned long mfn;
@@ -793,10 +791,8 @@ int m2p_remove_override(struct page *page, bool clear_pte)
 	WARN_ON(!PagePrivate(page));
 	ClearPagePrivate(page);
 
-	if (clear_pte) {
-		struct gnttab_map_grant_ref *map_op =
-			(struct gnttab_map_grant_ref *) page->index;
-		set_phys_to_machine(pfn, map_op->dev_bus_addr);
+	set_phys_to_machine(pfn, page->index);
+	if (kmap_op != NULL) {
 		if (!PageHighMem(page)) {
 			struct multicall_space mcs;
 			struct gnttab_unmap_grant_ref *unmap_op;
@@ -808,13 +804,13 @@ int m2p_remove_override(struct page *page, bool clear_pte)
 			 * issued. In this case handle is going to -1 because
 			 * it hasn't been modified yet.
 			 */
-			if (map_op->handle == -1)
+			if (kmap_op->handle == -1)
 				xen_mc_flush();
 			/*
-			 * Now if map_op->handle is negative it means that the
+			 * Now if kmap_op->handle is negative it means that the
 			 * hypercall actually returned an error.
 			 */
-			if (map_op->handle == GNTST_general_error) {
+			if (kmap_op->handle == GNTST_general_error) {
 				printk(KERN_WARNING "m2p_remove_override: "
 						"pfn %lx mfn %lx, failed to modify kernel mappings",
 						pfn, mfn);
@@ -824,8 +820,8 @@ int m2p_remove_override(struct page *page, bool clear_pte)
 			mcs = xen_mc_entry(
 					sizeof(struct gnttab_unmap_grant_ref));
 			unmap_op = mcs.args;
-			unmap_op->host_addr = map_op->host_addr;
-			unmap_op->handle = map_op->handle;
+			unmap_op->host_addr = kmap_op->host_addr;
+			unmap_op->handle = kmap_op->handle;
 			unmap_op->dev_bus_addr = 0;
 
 			MULTI_grant_table_op(mcs.mc,
@@ -836,10 +832,9 @@ int m2p_remove_override(struct page *page, bool clear_pte)
 			set_pte_at(&init_mm, address, ptep,
 					pfn_pte(pfn, PAGE_KERNEL));
 			__flush_tlb_single(address);
-			map_op->host_addr = 0;
+			kmap_op->host_addr = 0;
 		}
-	} 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
diff --git a/drivers/block/xen-blkback/blkback.c b/drivers/block/xen-blkback/blkback.c
index 73f196c..c6decb9 100644
--- a/drivers/block/xen-blkback/blkback.c
+++ b/drivers/block/xen-blkback/blkback.c
@@ -337,7 +337,7 @@ static void xen_blkbk_unmap(struct pending_req *req)
 		invcount++;
 	}
 
-	ret = gnttab_unmap_refs(unmap, pages, invcount, false);
+	ret = gnttab_unmap_refs(unmap, NULL, pages, invcount);
 	BUG_ON(ret);
 }
 
diff --git a/drivers/xen/gntdev.c b/drivers/xen/gntdev.c
index 1ffd03b..7f12416 100644
--- a/drivers/xen/gntdev.c
+++ b/drivers/xen/gntdev.c
@@ -314,8 +314,9 @@ static int __unmap_grant_pages(struct grant_map *map, int offset, int pages)
 		}
 	}
 
-	err = gnttab_unmap_refs(map->unmap_ops + offset, map->pages + offset,
-				pages, true);
+	err = gnttab_unmap_refs(map->unmap_ops + offset,
+			use_ptemod ? map->kmap_ops + offset : NULL, map->pages + offset,
+			pages);
 	if (err)
 		return err;
 
diff --git a/drivers/xen/grant-table.c b/drivers/xen/grant-table.c
index 0bfc1ef..0067266 100644
--- a/drivers/xen/grant-table.c
+++ b/drivers/xen/grant-table.c
@@ -870,7 +870,8 @@ int gnttab_map_refs(struct gnttab_map_grant_ref *map_ops,
 EXPORT_SYMBOL_GPL(gnttab_map_refs);
 
 int gnttab_unmap_refs(struct gnttab_unmap_grant_ref *unmap_ops,
-		      struct page **pages, unsigned int count, bool clear_pte)
+		      struct gnttab_map_grant_ref *kmap_ops,
+		      struct page **pages, unsigned int count)
 {
 	int i, ret;
 	bool lazy = false;
@@ -888,7 +889,8 @@ int gnttab_unmap_refs(struct gnttab_unmap_grant_ref *unmap_ops,
 	}
 
 	for (i = 0; i < count; i++) {
-		ret = m2p_remove_override(pages[i], clear_pte);
+		ret = m2p_remove_override(pages[i], kmap_ops ?
+				       &kmap_ops[i] : NULL);
 		if (ret)
 			return ret;
 	}
diff --git a/include/xen/grant_table.h b/include/xen/grant_table.h
index 11e27c3..f19fff8 100644
--- a/include/xen/grant_table.h
+++ b/include/xen/grant_table.h
@@ -187,6 +187,7 @@ int gnttab_map_refs(struct gnttab_map_grant_ref *map_ops,
 		    struct gnttab_map_grant_ref *kmap_ops,
 		    struct page **pages, unsigned int count);
 int gnttab_unmap_refs(struct gnttab_unmap_grant_ref *unmap_ops,
-		      struct page **pages, unsigned int count, bool clear_pte);
+		      struct gnttab_map_grant_ref *kunmap_ops,
+		      struct page **pages, unsigned int count);
 
 #endif /* __ASM_GNTTAB_H__ */

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 12 11:54:48 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Sep 2012 11:54:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TBlWX-0001Bn-49; Wed, 12 Sep 2012 11:54:29 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1TBlWW-0001Bi-6i
	for xen-devel@lists.xensource.com; Wed, 12 Sep 2012 11:54:28 +0000
Received: from [85.158.139.83:16605] by server-5.bemta-5.messagelabs.com id
	98/3E-30514-3F770505; Wed, 12 Sep 2012 11:54:27 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1347450866!30054356!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDg4MjM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30446 invoked from network); 12 Sep 2012 11:54:26 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Sep 2012 11:54:26 -0000
X-IronPort-AV: E=Sophos;i="4.80,408,1344211200"; d="scan'208";a="14494144"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Sep 2012 11:54: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.279.1; Wed, 12 Sep 2012 12:54: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
	1TBlWT-00078j-Qe	for xen-devel@lists.xensource.com;
	Wed, 12 Sep 2012 11:54:25 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1TBlWT-0001wd-MZ	for
	xen-devel@lists.xensource.com; Wed, 12 Sep 2012 12:54:25 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20560.30705.565410.634968@mariner.uk.xensource.com>
Date: Wed, 12 Sep 2012 12:54:25 +0100
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
In-Reply-To: <osstest-13682-mainreport@xen.org>
References: <osstest-13682-mainreport@xen.org>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Subject: Re: [Xen-devel] [xen-unstable test] 13682: regressions - trouble:
	broken/fail/pass
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

xen.org writes ("[xen-unstable test] 13682: regressions - trouble: broken/fail/pass"):
> flight 13682 xen-unstable real [real]
> http://www.chiark.greenend.org.uk/~xensrcts/logs/13682/
> 
> Regressions :-(
> 
> Tests which did not succeed and are blocking,
> including tests which could not be run:
...
>  test-amd64-i386-xend-winxpsp3  3 host-install(3)     broken REGR. vs. 13668

These were an infrastructure problem which was fixed this morning.
(The local apt-cacher was down.)

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 12 11:54:48 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Sep 2012 11:54:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TBlWX-0001Bn-49; Wed, 12 Sep 2012 11:54:29 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1TBlWW-0001Bi-6i
	for xen-devel@lists.xensource.com; Wed, 12 Sep 2012 11:54:28 +0000
Received: from [85.158.139.83:16605] by server-5.bemta-5.messagelabs.com id
	98/3E-30514-3F770505; Wed, 12 Sep 2012 11:54:27 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1347450866!30054356!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDg4MjM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30446 invoked from network); 12 Sep 2012 11:54:26 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Sep 2012 11:54:26 -0000
X-IronPort-AV: E=Sophos;i="4.80,408,1344211200"; d="scan'208";a="14494144"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Sep 2012 11:54: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.279.1; Wed, 12 Sep 2012 12:54: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
	1TBlWT-00078j-Qe	for xen-devel@lists.xensource.com;
	Wed, 12 Sep 2012 11:54:25 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1TBlWT-0001wd-MZ	for
	xen-devel@lists.xensource.com; Wed, 12 Sep 2012 12:54:25 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20560.30705.565410.634968@mariner.uk.xensource.com>
Date: Wed, 12 Sep 2012 12:54:25 +0100
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
In-Reply-To: <osstest-13682-mainreport@xen.org>
References: <osstest-13682-mainreport@xen.org>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Subject: Re: [Xen-devel] [xen-unstable test] 13682: regressions - trouble:
	broken/fail/pass
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

xen.org writes ("[xen-unstable test] 13682: regressions - trouble: broken/fail/pass"):
> flight 13682 xen-unstable real [real]
> http://www.chiark.greenend.org.uk/~xensrcts/logs/13682/
> 
> Regressions :-(
> 
> Tests which did not succeed and are blocking,
> including tests which could not be run:
...
>  test-amd64-i386-xend-winxpsp3  3 host-install(3)     broken REGR. vs. 13668

These were an infrastructure problem which was fixed this morning.
(The local apt-cacher was down.)

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 12 12:13:29 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Sep 2012 12: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 1TBloY-0001js-UC; Wed, 12 Sep 2012 12:13:06 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1TBloX-0001jf-15
	for xen-devel@lists.xen.org; Wed, 12 Sep 2012 12:13:05 +0000
Received: from [85.158.139.83:55037] by server-7.bemta-5.messagelabs.com id
	A5/DF-19703-05C70505; Wed, 12 Sep 2012 12:13:04 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1347451983!30059652!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDg4MjM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15898 invoked from network); 12 Sep 2012 12:13:03 -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;
	12 Sep 2012 12:13:03 -0000
X-IronPort-AV: E=Sophos;i="4.80,408,1344211200"; d="scan'208";a="14494572"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Sep 2012 12:13:03 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 12 Sep 2012 13:13:03 +0100
Message-ID: <1347451982.24226.45.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Wed, 12 Sep 2012 13:13:02 +0100
In-Reply-To: <50508AEF020000780009ACD4@nat28.tlf.novell.com>
References: <osstest-13677-mainreport@xen.org>
	<5050606D020000780009AC5E@nat28.tlf.novell.com>
	<1347443324.24226.30.camel@zakaz.uk.xensource.com>
	<50507B32020000780009AC9C@nat28.tlf.novell.com>
	<1347444721.24226.35.camel@zakaz.uk.xensource.com>
	<1347446103.24226.41.camel@zakaz.uk.xensource.com>
	<50508AEF020000780009ACD4@nat28.tlf.novell.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [xen-unstable test] 13677: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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-09-12 at 12:15 +0100, Jan Beulich wrote:
> >>> On 12.09.12 at 12:35, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> > On Wed, 2012-09-12 at 11:12 +0100, Ian Campbell wrote:
> >> On Wed, 2012-09-12 at 11:08 +0100, Jan Beulich wrote:
> >> > > Is it outside the realms of possibility that the guest has managed to
> >> > > limp along with the RTC being broken in some subtle way and only
> >> > > eventually trips up when we come to shut down?
> >> > 
> >> > That's certainly not impossible, but afaik Linux doesn't play with
> >> > the RTC unless told to by user space
> >> 
> >> I did wonder about an /etc/init.d/hwclock type thing, but I think that
> >> would have run much earlier than this point.
> >> 
> >> >  (whereas Windows, as we
> >> > know from the reporter of the problem that triggered putting
> >> > together these changes, does on its own at least under certain
> >> > circumstances, yet the Windows tests all go through fine).
> >> > 
> >> > Certainly this is the most likely candidate for having broken
> >> > something, and hence would be the prime candidate for reverting.
> >> > But before doing so, I'd want to see at least another run's results.
> >> 
> >> Ack. I'm installing a RHEL6.1 HVM guest anyway, since it's handy to have
> >> one in my pocket.
> > 
> > 25876:35fa512c60b2 "gnttab: cleanup of number-of-active-frames
> > calculations" for both => hangs:
> >         Syncing hardware clock to system time [  OK  ]
> >         Turning off swap:  [  OK  ]
> >         Unmounting file systems:  [  OK  ]
> >         init: Re-executing /sbin/init
> >         <silence>
> > 
> > Reverting just 25843:51090fe1ab97 "x86/HVM: assorted RTC emulation
> > adjustments" on top of 35fa... => works again.
> 
> In that case I'll just revert it in -unstable too. No idea what's wrong
> with it, though.

I see you've done the revert. In case it is helpful the list of blocked
tasks (from SysRQ-t) is below. Not sure if/how ps2 might relate to the
rtc...

BTW, I couldn't repro with a Debian Squeeze kernel...

Ian.

SysRq : Show Blocked State
  task                PC stack   pid father
init          D c0477b83     0     1      0 0x00000000
 ee470ab0 00000086 ee485c70 c0477b83 000f4240 00000000 00000000 004dd658
 00000000 ef12a200 00000033 00000001 00000033 c0ae2120 c0ae2120 ee470d58
 c0ae2120 c0addb54 c0ae2120 ee470d58 ec8ce000 00000000 ee494000 00000004
Call Trace:
 [<c0477b83>] ? hrtimer_forward+0x163/0x1b0
 [<c0463430>] ? run_timer_softirq+0x20/0x2c0
 [<c04b6494>] ? __rcu_process_callbacks+0x44/0x2d0
 [<c04b6755>] ? rcu_process_callbacks+0x35/0x40
 [<c0459c35>] ? __do_softirq+0xb5/0x1b0
 [<c08231e5>] ? schedule_timeout+0x195/0x250
 [<c05f1245>] ? idr_remove+0x125/0x1b0
 [<c055c0b7>] ? fsnotify_add_notify_event+0xf7/0x240
 [<c0822f49>] ? wait_for_common+0xe9/0x150
 [<c044bf70>] ? default_wake_function+0x0/0x10
 [<c04712e0>] ? synchronize_sched+0x40/0x50
 [<c04712f0>] ? wakeme_after_rcu+0x0/0x10
 [<c04795ac>] ? __synchronize_srcu+0x3c/0xc0
 [<c04712a0>] ? synchronize_sched+0x0/0x50
 [<c055c46d>] ? fsnotify_put_group+0x4d/0x80
 [<c055e7a2>] ? inotify_release+0x12/0x20
 [<c052987c>] ? __fput+0xdc/0x1f0
 [<c05256b7>] ? filp_close+0x47/0x80
 [<c0525757>] ? sys_close+0x67/0xb0
 [<c052de9c>] ? setup_new_exec+0x17c/0x240
 [<c0569e93>] ? load_elf_binary+0x323/0x1690
 [<c05f627b>] ? strrchr+0xb/0x20
 [<c04fdb4b>] ? follow_page+0x33b/0x3f0
 [<c0502781>] ? __get_user_pages+0xf1/0x430
 [<c0473f20>] ? autoremove_wake_function+0x0/0x40
 [<c052d35c>] ? acct_arg_size+0x4c/0x70
 [<c052e5e8>] ? get_arg_page+0x88/0xb0
 [<c0569b70>] ? load_elf_binary+0x0/0x1690
 [<c052ecf0>] ? search_binary_handler+0xf0/0x310
 [<c052fc3e>] ? do_execve+0x1ee/0x2b0
 [<c05fa122>] ? strncpy_from_user+0x32/0x60
 [<c0408215>] ? sys_execve+0x25/0x60
 [<c0409adf>] ? sysenter_do_call+0x12/0x28
halt          D ec151da8     0  1218      1 0x00000080
 eec50030 00000082 00000002 ec151da8 c1a03b54 00000000 00000000 c04b2105
 0000000c eedee580 00000033 352530de 00000033 c0ae2120 c0ae2120 eec502d8
 c0ae2120 c0addb54 c0ae2120 eec502d8 c1a03b54 00000001 fffec5c4 eec50030
Call Trace:
 [<c04b2105>] ? handle_IRQ_event+0x45/0x140
 [<c0459e95>] ? irq_exit+0x35/0x70
 [<c040b1c0>] ? do_IRQ+0x50/0xc0
 [<c040a030>] ? common_interrupt+0x30/0x38
 [<c082317c>] ? schedule_timeout+0x12c/0x250
 [<c0824839>] ? _spin_unlock_irqrestore+0x9/0x10
 [<c0462de0>] ? process_timeout+0x0/0x10
 [<c0726317>] ? __ps2_command+0x247/0x3a0
 [<c0473f20>] ? autoremove_wake_function+0x0/0x40
 [<c07264e4>] ? ps2_command+0x24/0x40
 [<c07233b8>] ? serio_cleanup+0x28/0x40
 [<c06ae900>] ? device_shutdown+0x40/0x150
 [<c0479bf7>] ? blocking_notifier_call_chain+0x17/0x20
 [<c046d86d>] ? kernel_power_off+0xd/0x40
 [<c046db38>] ? sys_reboot+0x108/0x210
 [<c07702d6>] ? sys_recvfrom+0x146/0x160
 [<c0775d28>] ? skb_dequeue+0x48/0x70
 [<c07764a4>] ? skb_queue_purge+0x14/0x20
 [<c055cbcc>] ? fsnotify_clear_marks_by_inode+0x1c/0xb0
 [<c053ca06>] ? dput+0x76/0x110
 [<c0529904>] ? __fput+0x164/0x1f0
 [<c0541cc5>] ? mntput_no_expire+0x15/0xd0
 [<c04adecc>] ? audit_syscall_entry+0x21c/0x240
 [<c04adbe6>] ? audit_syscall_exit+0x216/0x240
 [<c0409adf>] ? sysenter_do_call+0x12/0x28



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 12 12:13:29 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Sep 2012 12: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 1TBloY-0001js-UC; Wed, 12 Sep 2012 12:13:06 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1TBloX-0001jf-15
	for xen-devel@lists.xen.org; Wed, 12 Sep 2012 12:13:05 +0000
Received: from [85.158.139.83:55037] by server-7.bemta-5.messagelabs.com id
	A5/DF-19703-05C70505; Wed, 12 Sep 2012 12:13:04 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1347451983!30059652!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDg4MjM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15898 invoked from network); 12 Sep 2012 12:13:03 -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;
	12 Sep 2012 12:13:03 -0000
X-IronPort-AV: E=Sophos;i="4.80,408,1344211200"; d="scan'208";a="14494572"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Sep 2012 12:13:03 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 12 Sep 2012 13:13:03 +0100
Message-ID: <1347451982.24226.45.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Wed, 12 Sep 2012 13:13:02 +0100
In-Reply-To: <50508AEF020000780009ACD4@nat28.tlf.novell.com>
References: <osstest-13677-mainreport@xen.org>
	<5050606D020000780009AC5E@nat28.tlf.novell.com>
	<1347443324.24226.30.camel@zakaz.uk.xensource.com>
	<50507B32020000780009AC9C@nat28.tlf.novell.com>
	<1347444721.24226.35.camel@zakaz.uk.xensource.com>
	<1347446103.24226.41.camel@zakaz.uk.xensource.com>
	<50508AEF020000780009ACD4@nat28.tlf.novell.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [xen-unstable test] 13677: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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-09-12 at 12:15 +0100, Jan Beulich wrote:
> >>> On 12.09.12 at 12:35, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> > On Wed, 2012-09-12 at 11:12 +0100, Ian Campbell wrote:
> >> On Wed, 2012-09-12 at 11:08 +0100, Jan Beulich wrote:
> >> > > Is it outside the realms of possibility that the guest has managed to
> >> > > limp along with the RTC being broken in some subtle way and only
> >> > > eventually trips up when we come to shut down?
> >> > 
> >> > That's certainly not impossible, but afaik Linux doesn't play with
> >> > the RTC unless told to by user space
> >> 
> >> I did wonder about an /etc/init.d/hwclock type thing, but I think that
> >> would have run much earlier than this point.
> >> 
> >> >  (whereas Windows, as we
> >> > know from the reporter of the problem that triggered putting
> >> > together these changes, does on its own at least under certain
> >> > circumstances, yet the Windows tests all go through fine).
> >> > 
> >> > Certainly this is the most likely candidate for having broken
> >> > something, and hence would be the prime candidate for reverting.
> >> > But before doing so, I'd want to see at least another run's results.
> >> 
> >> Ack. I'm installing a RHEL6.1 HVM guest anyway, since it's handy to have
> >> one in my pocket.
> > 
> > 25876:35fa512c60b2 "gnttab: cleanup of number-of-active-frames
> > calculations" for both => hangs:
> >         Syncing hardware clock to system time [  OK  ]
> >         Turning off swap:  [  OK  ]
> >         Unmounting file systems:  [  OK  ]
> >         init: Re-executing /sbin/init
> >         <silence>
> > 
> > Reverting just 25843:51090fe1ab97 "x86/HVM: assorted RTC emulation
> > adjustments" on top of 35fa... => works again.
> 
> In that case I'll just revert it in -unstable too. No idea what's wrong
> with it, though.

I see you've done the revert. In case it is helpful the list of blocked
tasks (from SysRQ-t) is below. Not sure if/how ps2 might relate to the
rtc...

BTW, I couldn't repro with a Debian Squeeze kernel...

Ian.

SysRq : Show Blocked State
  task                PC stack   pid father
init          D c0477b83     0     1      0 0x00000000
 ee470ab0 00000086 ee485c70 c0477b83 000f4240 00000000 00000000 004dd658
 00000000 ef12a200 00000033 00000001 00000033 c0ae2120 c0ae2120 ee470d58
 c0ae2120 c0addb54 c0ae2120 ee470d58 ec8ce000 00000000 ee494000 00000004
Call Trace:
 [<c0477b83>] ? hrtimer_forward+0x163/0x1b0
 [<c0463430>] ? run_timer_softirq+0x20/0x2c0
 [<c04b6494>] ? __rcu_process_callbacks+0x44/0x2d0
 [<c04b6755>] ? rcu_process_callbacks+0x35/0x40
 [<c0459c35>] ? __do_softirq+0xb5/0x1b0
 [<c08231e5>] ? schedule_timeout+0x195/0x250
 [<c05f1245>] ? idr_remove+0x125/0x1b0
 [<c055c0b7>] ? fsnotify_add_notify_event+0xf7/0x240
 [<c0822f49>] ? wait_for_common+0xe9/0x150
 [<c044bf70>] ? default_wake_function+0x0/0x10
 [<c04712e0>] ? synchronize_sched+0x40/0x50
 [<c04712f0>] ? wakeme_after_rcu+0x0/0x10
 [<c04795ac>] ? __synchronize_srcu+0x3c/0xc0
 [<c04712a0>] ? synchronize_sched+0x0/0x50
 [<c055c46d>] ? fsnotify_put_group+0x4d/0x80
 [<c055e7a2>] ? inotify_release+0x12/0x20
 [<c052987c>] ? __fput+0xdc/0x1f0
 [<c05256b7>] ? filp_close+0x47/0x80
 [<c0525757>] ? sys_close+0x67/0xb0
 [<c052de9c>] ? setup_new_exec+0x17c/0x240
 [<c0569e93>] ? load_elf_binary+0x323/0x1690
 [<c05f627b>] ? strrchr+0xb/0x20
 [<c04fdb4b>] ? follow_page+0x33b/0x3f0
 [<c0502781>] ? __get_user_pages+0xf1/0x430
 [<c0473f20>] ? autoremove_wake_function+0x0/0x40
 [<c052d35c>] ? acct_arg_size+0x4c/0x70
 [<c052e5e8>] ? get_arg_page+0x88/0xb0
 [<c0569b70>] ? load_elf_binary+0x0/0x1690
 [<c052ecf0>] ? search_binary_handler+0xf0/0x310
 [<c052fc3e>] ? do_execve+0x1ee/0x2b0
 [<c05fa122>] ? strncpy_from_user+0x32/0x60
 [<c0408215>] ? sys_execve+0x25/0x60
 [<c0409adf>] ? sysenter_do_call+0x12/0x28
halt          D ec151da8     0  1218      1 0x00000080
 eec50030 00000082 00000002 ec151da8 c1a03b54 00000000 00000000 c04b2105
 0000000c eedee580 00000033 352530de 00000033 c0ae2120 c0ae2120 eec502d8
 c0ae2120 c0addb54 c0ae2120 eec502d8 c1a03b54 00000001 fffec5c4 eec50030
Call Trace:
 [<c04b2105>] ? handle_IRQ_event+0x45/0x140
 [<c0459e95>] ? irq_exit+0x35/0x70
 [<c040b1c0>] ? do_IRQ+0x50/0xc0
 [<c040a030>] ? common_interrupt+0x30/0x38
 [<c082317c>] ? schedule_timeout+0x12c/0x250
 [<c0824839>] ? _spin_unlock_irqrestore+0x9/0x10
 [<c0462de0>] ? process_timeout+0x0/0x10
 [<c0726317>] ? __ps2_command+0x247/0x3a0
 [<c0473f20>] ? autoremove_wake_function+0x0/0x40
 [<c07264e4>] ? ps2_command+0x24/0x40
 [<c07233b8>] ? serio_cleanup+0x28/0x40
 [<c06ae900>] ? device_shutdown+0x40/0x150
 [<c0479bf7>] ? blocking_notifier_call_chain+0x17/0x20
 [<c046d86d>] ? kernel_power_off+0xd/0x40
 [<c046db38>] ? sys_reboot+0x108/0x210
 [<c07702d6>] ? sys_recvfrom+0x146/0x160
 [<c0775d28>] ? skb_dequeue+0x48/0x70
 [<c07764a4>] ? skb_queue_purge+0x14/0x20
 [<c055cbcc>] ? fsnotify_clear_marks_by_inode+0x1c/0xb0
 [<c053ca06>] ? dput+0x76/0x110
 [<c0529904>] ? __fput+0x164/0x1f0
 [<c0541cc5>] ? mntput_no_expire+0x15/0xd0
 [<c04adecc>] ? audit_syscall_entry+0x21c/0x240
 [<c04adbe6>] ? audit_syscall_exit+0x216/0x240
 [<c0409adf>] ? sysenter_do_call+0x12/0x28



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 12 12:45:20 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Sep 2012 12: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 1TBmJN-00025b-Pr; Wed, 12 Sep 2012 12:44:57 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Wei.Wang2@amd.com>) id 1TBmJL-00025W-Gl
	for xen-devel@lists.xen.org; Wed, 12 Sep 2012 12:44:56 +0000
Received: from [85.158.138.51:46021] by server-12.bemta-3.messagelabs.com id
	4B/C9-10384-6C380505; Wed, 12 Sep 2012 12:44:54 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1347453892!30232039!1
X-Originating-IP: [216.32.180.31]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13590 invoked from network); 12 Sep 2012 12:44:53 -0000
Received: from va3ehsobe005.messaging.microsoft.com (HELO
	va3outboundpool.messaging.microsoft.com) (216.32.180.31)
	by server-5.tower-174.messagelabs.com with AES128-SHA encrypted SMTP;
	12 Sep 2012 12:44:53 -0000
Received: from mail35-va3-R.bigfish.com (10.7.14.244) by
	VA3EHSOBE002.bigfish.com (10.7.40.22) with Microsoft SMTP Server id
	14.1.225.23; Wed, 12 Sep 2012 12:44:52 +0000
Received: from mail35-va3 (localhost [127.0.0.1])	by mail35-va3-R.bigfish.com
	(Postfix) with ESMTP id 42F7B4E00D2;
	Wed, 12 Sep 2012 12:44:52 +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: 6
X-BigFish: VPS6(zzbb2dI98dI9371I1432I4015I82c2szz1202h1d1ah1d2ahzz8275bhz2dh668h839he5bhf0ah107ah1288h12a5h12bdh1155h)
Received: from mail35-va3 (localhost.localdomain [127.0.0.1]) by mail35-va3
	(MessageSwitch) id 134745389182391_8756; Wed, 12 Sep 2012 12:44:51 +0000
	(UTC)
Received: from VA3EHSMHS030.bigfish.com (unknown [10.7.14.242])	by
	mail35-va3.bigfish.com (Postfix) with ESMTP id 0D6D4440019;
	Wed, 12 Sep 2012 12:44:51 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	VA3EHSMHS030.bigfish.com (10.7.99.40) with Microsoft SMTP Server id
	14.1.225.23; Wed, 12 Sep 2012 12:44:46 +0000
X-WSS-ID: 0MA8M2J-01-0A8-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 20909102809E;	Wed, 12 Sep 2012 07:44:43 -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, 12 Sep 2012 07:58:30 -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;
	Wed, 12 Sep 2012 07:44:44 -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, 12 Sep 2012
	08:44:43 -0400
Received: from [165.204.15.57] (gran.osrc.amd.com [165.204.15.57])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id 0B9CC49C0D5; Wed, 12 Sep 2012
	13:44:42 +0100 (BST)
Message-ID: <50508413.7070601@amd.com>
Date: Wed, 12 Sep 2012 14:46: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: <504F4C04020000780009A964@nat28.tlf.novell.com>
In-Reply-To: <504F4C04020000780009A964@nat28.tlf.novell.com>
X-OriginatorOrg: amd.com
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 1/3] amd iommu: use PCI macros
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Tested and Acked
Thanks,
Wei

On 09/11/2012 02:34 PM, Jan Beulich wrote:
> ... instead of open coding them.
>
> Signed-off-by: Jan Beulich<jbeulich@suse.com>
>
> --- a/xen/drivers/passthrough/amd/iommu_init.c
> +++ b/xen/drivers/passthrough/amd/iommu_init.c
> @@ -455,9 +455,9 @@ static void iommu_msi_set_affinity(struc
>       unsigned int dest;
>       struct amd_iommu *iommu = desc->action->dev_id;
>       u16 seg = iommu->seg;
> -    u8 bus = (iommu->bdf>>  8)&  0xff;
> -    u8 dev = PCI_SLOT(iommu->bdf&  0xff);
> -    u8 func = PCI_FUNC(iommu->bdf&  0xff);
> +    u8 bus = PCI_BUS(iommu->bdf);
> +    u8 dev = PCI_SLOT(iommu->bdf);
> +    u8 func = PCI_FUNC(iommu->bdf);
>
>       dest = set_desc_affinity(desc, mask);
>
> @@ -495,13 +495,13 @@ static void iommu_msi_set_affinity(struc
>   static void amd_iommu_msi_enable(struct amd_iommu *iommu, int flag)
>   {
>       u16 control;
> -    int bus = (iommu->bdf>>  8)&  0xff;
> -    int dev = PCI_SLOT(iommu->bdf&  0xff);
> -    int func = PCI_FUNC(iommu->bdf&  0xff);
> +    int bus = PCI_BUS(iommu->bdf);
> +    int dev = PCI_SLOT(iommu->bdf);
> +    int func = PCI_FUNC(iommu->bdf);
>
>       control = pci_conf_read16(iommu->seg, bus, dev, func,
>           iommu->msi_cap + PCI_MSI_FLAGS);
> -    control&= ~(1);
> +    control&= ~PCI_MSI_FLAGS_ENABLE;
>       if ( flag )
>           control |= flag;
>       pci_conf_write16(iommu->seg, bus, dev, func,
> --- a/xen/drivers/passthrough/amd/iommu_intr.c
> +++ b/xen/drivers/passthrough/amd/iommu_intr.c
> @@ -272,7 +272,7 @@ static void update_intremap_entry_from_m
>       spinlock_t *lock;
>       int offset;
>
> -    bdf = (pdev->bus<<  8) | pdev->devfn;
> +    bdf = PCI_BDF2(pdev->bus, pdev->devfn);
>       req_id = get_dma_requestor_id(pdev->seg, bdf);
>       alias_id = get_intremap_requestor_id(pdev->seg, bdf);
>
> @@ -340,17 +340,16 @@ void amd_iommu_msi_msg_update_ire(
>       struct msi_desc *msi_desc, struct msi_msg *msg)
>   {
>       struct pci_dev *pdev = msi_desc->dev;
> -    struct amd_iommu *iommu = NULL;
> +    int bdf = PCI_BDF2(pdev->bus, pdev->devfn);
> +    struct amd_iommu *iommu;
>
>       if ( !iommu_intremap )
>           return;
>
> -    iommu = find_iommu_for_device(pdev->seg, (pdev->bus<<  8) | pdev->devfn);
> -
> +    iommu = find_iommu_for_device(pdev->seg, bdf);
>       if ( !iommu )
>       {
> -        AMD_IOMMU_DEBUG("Fail to find iommu for MSI device id = 0x%x\n",
> -                       (pdev->bus<<  8) | pdev->devfn);
> +        AMD_IOMMU_DEBUG("Fail to find iommu for MSI device id = %#x\n", bdf);
>           return;
>       }
>
> --- a/xen/drivers/passthrough/amd/iommu_map.c
> +++ b/xen/drivers/passthrough/amd/iommu_map.c
> @@ -597,7 +597,7 @@ static int update_paging_mode(struct dom
>           /* Update device table entries using new root table and paging mode */
>           for_each_pdev( d, pdev )
>           {
> -            bdf = (pdev->bus<<  8) | pdev->devfn;
> +            bdf = PCI_BDF2(pdev->bus, pdev->devfn);
>               req_id = get_dma_requestor_id(pdev->seg, bdf);
>               iommu = find_iommu_for_device(pdev->seg, bdf);
>               if ( !iommu )
> --- a/xen/drivers/passthrough/amd/pci_amd_iommu.c
> +++ b/xen/drivers/passthrough/amd/pci_amd_iommu.c
> @@ -373,7 +373,7 @@ static int reassign_device( struct domai
>   static int amd_iommu_assign_device(struct domain *d, u16 seg, u8 bus, u8 devfn)
>   {
>       struct ivrs_mappings *ivrs_mappings = get_ivrs_mappings(seg);
> -    int bdf = (bus<<  8) | devfn;
> +    int bdf = PCI_BDF2(bus, devfn);
>       int req_id = get_dma_requestor_id(seg, bdf);
>
>       if ( ivrs_mappings[req_id].unity_map_enable )
> @@ -499,12 +499,9 @@ static int amd_iommu_remove_device(struc
>
>   static int amd_iommu_group_id(u16 seg, u8 bus, u8 devfn)
>   {
> -    int rt;
> -    int bdf = (bus<<  8) | devfn;
> -    rt = ( bdf<  ivrs_bdf_entries ) ?
> -        get_dma_requestor_id(seg, bdf) :
> -        bdf;
> -    return rt;
> +    int bdf = PCI_BDF2(bus, devfn);
> +
> +    return (bdf<  ivrs_bdf_entries) ? get_dma_requestor_id(seg, bdf) : bdf;
>   }
>
>   #include<asm/io_apic.h>
>
>
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 12 12:45:20 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Sep 2012 12: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 1TBmJN-00025b-Pr; Wed, 12 Sep 2012 12:44:57 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Wei.Wang2@amd.com>) id 1TBmJL-00025W-Gl
	for xen-devel@lists.xen.org; Wed, 12 Sep 2012 12:44:56 +0000
Received: from [85.158.138.51:46021] by server-12.bemta-3.messagelabs.com id
	4B/C9-10384-6C380505; Wed, 12 Sep 2012 12:44:54 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1347453892!30232039!1
X-Originating-IP: [216.32.180.31]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13590 invoked from network); 12 Sep 2012 12:44:53 -0000
Received: from va3ehsobe005.messaging.microsoft.com (HELO
	va3outboundpool.messaging.microsoft.com) (216.32.180.31)
	by server-5.tower-174.messagelabs.com with AES128-SHA encrypted SMTP;
	12 Sep 2012 12:44:53 -0000
Received: from mail35-va3-R.bigfish.com (10.7.14.244) by
	VA3EHSOBE002.bigfish.com (10.7.40.22) with Microsoft SMTP Server id
	14.1.225.23; Wed, 12 Sep 2012 12:44:52 +0000
Received: from mail35-va3 (localhost [127.0.0.1])	by mail35-va3-R.bigfish.com
	(Postfix) with ESMTP id 42F7B4E00D2;
	Wed, 12 Sep 2012 12:44:52 +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: 6
X-BigFish: VPS6(zzbb2dI98dI9371I1432I4015I82c2szz1202h1d1ah1d2ahzz8275bhz2dh668h839he5bhf0ah107ah1288h12a5h12bdh1155h)
Received: from mail35-va3 (localhost.localdomain [127.0.0.1]) by mail35-va3
	(MessageSwitch) id 134745389182391_8756; Wed, 12 Sep 2012 12:44:51 +0000
	(UTC)
Received: from VA3EHSMHS030.bigfish.com (unknown [10.7.14.242])	by
	mail35-va3.bigfish.com (Postfix) with ESMTP id 0D6D4440019;
	Wed, 12 Sep 2012 12:44:51 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	VA3EHSMHS030.bigfish.com (10.7.99.40) with Microsoft SMTP Server id
	14.1.225.23; Wed, 12 Sep 2012 12:44:46 +0000
X-WSS-ID: 0MA8M2J-01-0A8-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 20909102809E;	Wed, 12 Sep 2012 07:44:43 -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, 12 Sep 2012 07:58:30 -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;
	Wed, 12 Sep 2012 07:44:44 -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, 12 Sep 2012
	08:44:43 -0400
Received: from [165.204.15.57] (gran.osrc.amd.com [165.204.15.57])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id 0B9CC49C0D5; Wed, 12 Sep 2012
	13:44:42 +0100 (BST)
Message-ID: <50508413.7070601@amd.com>
Date: Wed, 12 Sep 2012 14:46: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: <504F4C04020000780009A964@nat28.tlf.novell.com>
In-Reply-To: <504F4C04020000780009A964@nat28.tlf.novell.com>
X-OriginatorOrg: amd.com
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 1/3] amd iommu: use PCI macros
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Tested and Acked
Thanks,
Wei

On 09/11/2012 02:34 PM, Jan Beulich wrote:
> ... instead of open coding them.
>
> Signed-off-by: Jan Beulich<jbeulich@suse.com>
>
> --- a/xen/drivers/passthrough/amd/iommu_init.c
> +++ b/xen/drivers/passthrough/amd/iommu_init.c
> @@ -455,9 +455,9 @@ static void iommu_msi_set_affinity(struc
>       unsigned int dest;
>       struct amd_iommu *iommu = desc->action->dev_id;
>       u16 seg = iommu->seg;
> -    u8 bus = (iommu->bdf>>  8)&  0xff;
> -    u8 dev = PCI_SLOT(iommu->bdf&  0xff);
> -    u8 func = PCI_FUNC(iommu->bdf&  0xff);
> +    u8 bus = PCI_BUS(iommu->bdf);
> +    u8 dev = PCI_SLOT(iommu->bdf);
> +    u8 func = PCI_FUNC(iommu->bdf);
>
>       dest = set_desc_affinity(desc, mask);
>
> @@ -495,13 +495,13 @@ static void iommu_msi_set_affinity(struc
>   static void amd_iommu_msi_enable(struct amd_iommu *iommu, int flag)
>   {
>       u16 control;
> -    int bus = (iommu->bdf>>  8)&  0xff;
> -    int dev = PCI_SLOT(iommu->bdf&  0xff);
> -    int func = PCI_FUNC(iommu->bdf&  0xff);
> +    int bus = PCI_BUS(iommu->bdf);
> +    int dev = PCI_SLOT(iommu->bdf);
> +    int func = PCI_FUNC(iommu->bdf);
>
>       control = pci_conf_read16(iommu->seg, bus, dev, func,
>           iommu->msi_cap + PCI_MSI_FLAGS);
> -    control&= ~(1);
> +    control&= ~PCI_MSI_FLAGS_ENABLE;
>       if ( flag )
>           control |= flag;
>       pci_conf_write16(iommu->seg, bus, dev, func,
> --- a/xen/drivers/passthrough/amd/iommu_intr.c
> +++ b/xen/drivers/passthrough/amd/iommu_intr.c
> @@ -272,7 +272,7 @@ static void update_intremap_entry_from_m
>       spinlock_t *lock;
>       int offset;
>
> -    bdf = (pdev->bus<<  8) | pdev->devfn;
> +    bdf = PCI_BDF2(pdev->bus, pdev->devfn);
>       req_id = get_dma_requestor_id(pdev->seg, bdf);
>       alias_id = get_intremap_requestor_id(pdev->seg, bdf);
>
> @@ -340,17 +340,16 @@ void amd_iommu_msi_msg_update_ire(
>       struct msi_desc *msi_desc, struct msi_msg *msg)
>   {
>       struct pci_dev *pdev = msi_desc->dev;
> -    struct amd_iommu *iommu = NULL;
> +    int bdf = PCI_BDF2(pdev->bus, pdev->devfn);
> +    struct amd_iommu *iommu;
>
>       if ( !iommu_intremap )
>           return;
>
> -    iommu = find_iommu_for_device(pdev->seg, (pdev->bus<<  8) | pdev->devfn);
> -
> +    iommu = find_iommu_for_device(pdev->seg, bdf);
>       if ( !iommu )
>       {
> -        AMD_IOMMU_DEBUG("Fail to find iommu for MSI device id = 0x%x\n",
> -                       (pdev->bus<<  8) | pdev->devfn);
> +        AMD_IOMMU_DEBUG("Fail to find iommu for MSI device id = %#x\n", bdf);
>           return;
>       }
>
> --- a/xen/drivers/passthrough/amd/iommu_map.c
> +++ b/xen/drivers/passthrough/amd/iommu_map.c
> @@ -597,7 +597,7 @@ static int update_paging_mode(struct dom
>           /* Update device table entries using new root table and paging mode */
>           for_each_pdev( d, pdev )
>           {
> -            bdf = (pdev->bus<<  8) | pdev->devfn;
> +            bdf = PCI_BDF2(pdev->bus, pdev->devfn);
>               req_id = get_dma_requestor_id(pdev->seg, bdf);
>               iommu = find_iommu_for_device(pdev->seg, bdf);
>               if ( !iommu )
> --- a/xen/drivers/passthrough/amd/pci_amd_iommu.c
> +++ b/xen/drivers/passthrough/amd/pci_amd_iommu.c
> @@ -373,7 +373,7 @@ static int reassign_device( struct domai
>   static int amd_iommu_assign_device(struct domain *d, u16 seg, u8 bus, u8 devfn)
>   {
>       struct ivrs_mappings *ivrs_mappings = get_ivrs_mappings(seg);
> -    int bdf = (bus<<  8) | devfn;
> +    int bdf = PCI_BDF2(bus, devfn);
>       int req_id = get_dma_requestor_id(seg, bdf);
>
>       if ( ivrs_mappings[req_id].unity_map_enable )
> @@ -499,12 +499,9 @@ static int amd_iommu_remove_device(struc
>
>   static int amd_iommu_group_id(u16 seg, u8 bus, u8 devfn)
>   {
> -    int rt;
> -    int bdf = (bus<<  8) | devfn;
> -    rt = ( bdf<  ivrs_bdf_entries ) ?
> -        get_dma_requestor_id(seg, bdf) :
> -        bdf;
> -    return rt;
> +    int bdf = PCI_BDF2(bus, devfn);
> +
> +    return (bdf<  ivrs_bdf_entries) ? get_dma_requestor_id(seg, bdf) : bdf;
>   }
>
>   #include<asm/io_apic.h>
>
>
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 12 12:47:07 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Sep 2012 12:47:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TBmL6-0002AC-A2; Wed, 12 Sep 2012 12:46:44 +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 1TBmL4-00029w-Ll
	for xen-devel@lists.xen.org; Wed, 12 Sep 2012 12:46:43 +0000
Received: from [85.158.143.35:28137] by server-3.bemta-4.messagelabs.com id
	B2/B5-08232-23480505; Wed, 12 Sep 2012 12:46:42 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1347453974!6881799!1
X-Originating-IP: [216.32.180.186]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19569 invoked from network); 12 Sep 2012 12:46:16 -0000
Received: from co1ehsobe003.messaging.microsoft.com (HELO
	co1outboundpool.messaging.microsoft.com) (216.32.180.186)
	by server-9.tower-21.messagelabs.com with AES128-SHA encrypted SMTP;
	12 Sep 2012 12:46:16 -0000
Received: from mail56-co1-R.bigfish.com (10.243.78.237) by
	CO1EHSOBE012.bigfish.com (10.243.66.75) with Microsoft SMTP Server id
	14.1.225.23; Wed, 12 Sep 2012 12:46:14 +0000
Received: from mail56-co1 (localhost [127.0.0.1])	by mail56-co1-R.bigfish.com
	(Postfix) with ESMTP id 4AC6CB000E5;
	Wed, 12 Sep 2012 12:46:14 +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(zzbb2dI98dI9371I1432I4015Izz1202h1d1ah1d2ahzz8275bhz2dh668h839he5bhf0ah107ah1288h12a5h12bdh1155h)
Received: from mail56-co1 (localhost.localdomain [127.0.0.1]) by mail56-co1
	(MessageSwitch) id 13474539714654_927;
	Wed, 12 Sep 2012 12:46:11 +0000 (UTC)
Received: from CO1EHSMHS013.bigfish.com (unknown [10.243.78.248])	by
	mail56-co1.bigfish.com (Postfix) with ESMTP id E948E3C0043;
	Wed, 12 Sep 2012 12:46:10 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	CO1EHSMHS013.bigfish.com (10.243.66.23) with Microsoft SMTP Server id
	14.1.225.23; Wed, 12 Sep 2012 12:46:09 +0000
X-WSS-ID: 0MA8M4R-02-DBR-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 2DD66C80D2;	Wed, 12 Sep 2012 07:46: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;
	Wed, 12 Sep 2012 07:59:53 -0500
Received: from storexhtp01.amd.com (172.24.4.3) by sausexdag02.amd.com
	(163.181.55.2) with Microsoft SMTP Server (TLS) id 14.1.323.3;
	Wed, 12 Sep 2012 07:46:07 -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, 12 Sep 2012
	08:46:05 -0400
Received: from [165.204.15.57] (gran.osrc.amd.com [165.204.15.57])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id C8B5549C0D5; Wed, 12 Sep 2012
	13:46:04 +0100 (BST)
Message-ID: <50508466.20309@amd.com>
Date: Wed, 12 Sep 2012 14:47:34 +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: <504F4C24020000780009A968@nat28.tlf.novell.com>
In-Reply-To: <504F4C24020000780009A968@nat28.tlf.novell.com>
X-OriginatorOrg: amd.com
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 2/3] amd iommu: use base platform MSI
	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-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi Jan
I found this patch triggered a xen BUG
Thanks,
Wei

XEN) Xen BUG at spinlock.c:48
(XEN) ----[ Xen-4.3-unstable  x86_64  debug=y  Tainted:    C ]----
(XEN) CPU:    0
(XEN) RIP:    e008:[<ffff82c4801254d2>] check_lock+0x32/0x3e
(XEN) RFLAGS: 0000000000010046   CONTEXT: hypervisor
(XEN) rax: 0000000000000000   rbx: ffff83014fff9868   rcx: 0000000000000001
(XEN) rdx: 0000000000000000   rsi: ffff83014fff8000   rdi: ffff83014fff986c
(XEN) rbp: ffff82c4802c7c80   rsp: ffff82c4802c7c80   r8:  0000000000000039
(XEN) r9:  ffff83014ff37cb0   r10: 00000000000000a0   r11: 0000000000000000
(XEN) r12: 0000000000000010   r13: 0000000000000020   r14: ffff83014fff9868
(XEN) r15: ffff83014fe9dee0   cr0: 000000008005003b   cr4: 00000000000006f0
(XEN) cr3: 0000000245c05000   cr2: ffff8800119720e0
(XEN) ds: 0000   es: 0000   fs: 0000   gs: 0000   ss: e010   cs: e008
(XEN) Xen stack trace from rsp=ffff82c4802c7c80:
(XEN)    ffff82c4802c7c98 ffff82c480125509 ffff83014fff8000 ffff82c4802c7cd8
(XEN)    ffff82c48012c2a3 00000000000000a0 0000000000000020 0000000000000010
(XEN)    0000000000000030 0000000000000000 ffff83014fe9dee0 ffff82c4802c7d28
(XEN)    ffff82c48012ca45 ffff82c4802c7cf8 ffff82c480136fd7 ffff82c4802c7d38
(XEN)    ffff82c4802c7d68 ffff83014fe03980 00000000000000b0 0000000000000000
(XEN)    ffff83014fe9dee0 ffff82c4802c7d58 ffff82c480166594 ffff83014fe03980
(XEN)    ffff83014fe03980 0000000000000039 0000000000000000 ffff82c4802c7d88
(XEN)    ffff82c4801667d7 0000000000000000 0000000000000000 ffff83014fe03980
(XEN)    ffff83014ff72000 ffff82c4802c7df8 ffff82c48016affa ffff82c4802c7dc8
(XEN)    ffff82c4802c7ea8 0000000000000246 ffff83014fe039a4 ffff83014ff137a0
(XEN)    ffff83014ff13300 ffff82c4802c7df8 0000000000000000 0000000000000039
(XEN)    0000000000000000 ffff82c4802c7e88 ffff82c4802c7e8c ffff82c4802c7e68
(XEN)    ffff82c48017cb01 ffff82c48027d7c0 0000000600000000 000001378013d9f4
(XEN)    ffff82c4802c7ea8 0000000000000002 ffff83014ff72000 ffff82c4802c7e68
(XEN)    fffffffffffffff2 000000000000000d ffff88000f5f1d40 ffff8300afafb000
(XEN)    0000000000000005 ffff82c4802c7ef8 ffff82c48017d3d4 ffff82c4802c7ec8
(XEN)    0000000000007ff0 ffffffffffffffff 0000001000000000 0000000000000000
(XEN)    0000000000000000 0000003910000000 ffff82c400000000 0000000000000000
(XEN)    ffffffff81d9e2f1 ffff82c4802c7ef8 ffff8300afafb000 ffff88000f5f1d40
(XEN)    ffff880015057838 ffff88000f555600 0000000000000005 00007d3b7fd380c7
(XEN) Xen call trace:
(XEN)    [<ffff82c4801254d2>] check_lock+0x32/0x3e
(XEN)    [<ffff82c480125509>] _spin_lock+0x11/0x5a
(XEN)    [<ffff82c48012c2a3>] xmem_pool_alloc+0x12b/0x49b
(XEN)    [<ffff82c48012ca45>] _xmalloc+0x132/0x222
(XEN)    [<ffff82c480166594>] msi_compose_msg+0xd1/0x195
(XEN)    [<ffff82c4801667d7>] setup_msi_irq+0x15/0x29
(XEN)    [<ffff82c48016affa>] map_domain_pirq+0x3b1/0x435
(XEN)    [<ffff82c48017cb01>] physdev_map_pirq+0x4a1/0x55d
(XEN)    [<ffff82c48017d3d4>] do_physdev_op+0x659/0x11f9
(XEN)    [<ffff82c480229188>] syscall_enter+0xc8/0x122
(XEN)
(XEN)
(XEN) ****************************************
(XEN) Panic on CPU 0:
(XEN) Xen BUG at spinlock.c:48


On 09/11/2012 02:35 PM, Jan Beulich wrote:
> Given that here, other than for VT-d, the MSI interface gets surfaced
> through a normal PCI device, the code should use as much as possible of
> the "normal" MSI support code.
>
> Further, the code can (and should) follow the "normal" MSI code in
> distinguishing the maskable and non-maskable cases at the IRQ
> controller level rather than checking the respective flag in the
> individual actors.
>
> Signed-off-by: Jan Beulich<jbeulich@suse.com>
>
> --- a/xen/arch/x86/msi.c
> +++ b/xen/arch/x86/msi.c
> @@ -126,13 +126,23 @@ void msi_compose_msg(struct irq_desc *de
>       unsigned dest;
>       int vector = desc->arch.vector;
>
> -    if ( cpumask_empty(desc->arch.cpu_mask) ) {
> +    memset(msg, 0, sizeof(*msg));
> +    if ( !cpumask_intersects(desc->arch.cpu_mask,&cpu_online_map) ) {
>           dprintk(XENLOG_ERR,"%s, compose msi message error!!\n", __func__);
>           return;
>       }
>
>       if ( vector ) {
> -        dest = cpu_mask_to_apicid(desc->arch.cpu_mask);
> +        cpumask_var_t mask;
> +
> +        if ( alloc_cpumask_var(&mask) )
> +        {
> +            cpumask_and(mask, desc->arch.cpu_mask,&cpu_online_map);
> +            dest = cpu_mask_to_apicid(mask);
> +            free_cpumask_var(mask);
> +        }
> +        else
> +            dest = cpu_mask_to_apicid(desc->arch.cpu_mask);
>
>           msg->address_hi = MSI_ADDR_BASE_HI;
>           msg->address_lo =
> @@ -281,23 +291,27 @@ static void set_msi_affinity(struct irq_
>       write_msi_msg(msi_desc,&msg);
>   }
>
> +void __msi_set_enable(u16 seg, u8 bus, u8 slot, u8 func, int pos, int enable)
> +{
> +    u16 control = pci_conf_read16(seg, bus, slot, func, pos + PCI_MSI_FLAGS);
> +
> +    control&= ~PCI_MSI_FLAGS_ENABLE;
> +    if ( enable )
> +        control |= PCI_MSI_FLAGS_ENABLE;
> +    pci_conf_write16(seg, bus, slot, func, pos + PCI_MSI_FLAGS, control);
> +}
> +
>   static void msi_set_enable(struct pci_dev *dev, int enable)
>   {
>       int pos;
> -    u16 control, seg = dev->seg;
> +    u16 seg = dev->seg;
>       u8 bus = dev->bus;
>       u8 slot = PCI_SLOT(dev->devfn);
>       u8 func = PCI_FUNC(dev->devfn);
>
>       pos = pci_find_cap_offset(seg, bus, slot, func, PCI_CAP_ID_MSI);
>       if ( pos )
> -    {
> -        control = pci_conf_read16(seg, bus, slot, func, pos + PCI_MSI_FLAGS);
> -        control&= ~PCI_MSI_FLAGS_ENABLE;
> -        if ( enable )
> -            control |= PCI_MSI_FLAGS_ENABLE;
> -        pci_conf_write16(seg, bus, slot, func, pos + PCI_MSI_FLAGS, control);
> -    }
> +        __msi_set_enable(seg, bus, slot, func, pos, enable);
>   }
>
>   static void msix_set_enable(struct pci_dev *dev, int enable)
> @@ -379,12 +393,12 @@ static int msi_get_mask_bit(const struct
>       return -1;
>   }
>
> -static void mask_msi_irq(struct irq_desc *desc)
> +void mask_msi_irq(struct irq_desc *desc)
>   {
>       msi_set_mask_bit(desc, 1);
>   }
>
> -static void unmask_msi_irq(struct irq_desc *desc)
> +void unmask_msi_irq(struct irq_desc *desc)
>   {
>       msi_set_mask_bit(desc, 0);
>   }
> @@ -395,7 +409,7 @@ static unsigned int startup_msi_irq(stru
>       return 0;
>   }
>
> -static void ack_nonmaskable_msi_irq(struct irq_desc *desc)
> +void ack_nonmaskable_msi_irq(struct irq_desc *desc)
>   {
>       irq_complete_move(desc);
>       move_native_irq(desc);
> @@ -407,7 +421,7 @@ static void ack_maskable_msi_irq(struct
>       ack_APIC_irq(); /* ACKTYPE_NONE */
>   }
>
> -static void end_nonmaskable_msi_irq(struct irq_desc *desc, u8 vector)
> +void end_nonmaskable_msi_irq(struct irq_desc *desc, u8 vector)
>   {
>       ack_APIC_irq(); /* ACKTYPE_EOI */
>   }
> --- a/xen/drivers/passthrough/amd/iommu_detect.c
> +++ b/xen/drivers/passthrough/amd/iommu_detect.c
> @@ -31,7 +31,6 @@ static int __init get_iommu_msi_capabili
>       u16 seg, u8 bus, u8 dev, u8 func, struct amd_iommu *iommu)
>   {
>       int pos;
> -    u16 control;
>
>       pos = pci_find_cap_offset(seg, bus, dev, func, PCI_CAP_ID_MSI);
>
> @@ -41,9 +40,6 @@ static int __init get_iommu_msi_capabili
>       AMD_IOMMU_DEBUG("Found MSI capability block at %#x\n", pos);
>
>       iommu->msi_cap = pos;
> -    control = pci_conf_read16(seg, bus, dev, func,
> -                              iommu->msi_cap + PCI_MSI_FLAGS);
> -    iommu->maskbit = control&  PCI_MSI_FLAGS_MASKBIT;
>       return 0;
>   }
>
> --- a/xen/drivers/passthrough/amd/iommu_init.c
> +++ b/xen/drivers/passthrough/amd/iommu_init.c
> @@ -467,20 +467,9 @@ static void iommu_msi_set_affinity(struc
>           return;
>       }
>
> -    memset(&msg, 0, sizeof(msg));
> -    msg.data = MSI_DATA_VECTOR(desc->arch.vector)&  0xff;
> -    msg.data |= 1<<  14;
> -    msg.data |= (INT_DELIVERY_MODE != dest_LowestPrio) ?
> -        MSI_DATA_DELIVERY_FIXED:
> -        MSI_DATA_DELIVERY_LOWPRI;
> -
> -    msg.address_hi =0;
> -    msg.address_lo = (MSI_ADDRESS_HEADER<<  (MSI_ADDRESS_HEADER_SHIFT + 8));
> -    msg.address_lo |= INT_DEST_MODE ? MSI_ADDR_DESTMODE_LOGIC:
> -                    MSI_ADDR_DESTMODE_PHYS;
> -    msg.address_lo |= (INT_DELIVERY_MODE != dest_LowestPrio) ?
> -                    MSI_ADDR_REDIRECTION_CPU:
> -                    MSI_ADDR_REDIRECTION_LOWPRI;
> +    msi_compose_msg(desc,&msg);
> +    /* Is this override really needed? */
> +    msg.address_lo&= ~MSI_ADDR_DEST_ID_MASK;
>       msg.address_lo |= MSI_ADDR_DEST_ID(dest&  0xff);
>
>       pci_conf_write32(seg, bus, dev, func,
> @@ -494,18 +483,8 @@ static void iommu_msi_set_affinity(struc
>
>   static void amd_iommu_msi_enable(struct amd_iommu *iommu, int flag)
>   {
> -    u16 control;
> -    int bus = PCI_BUS(iommu->bdf);
> -    int dev = PCI_SLOT(iommu->bdf);
> -    int func = PCI_FUNC(iommu->bdf);
> -
> -    control = pci_conf_read16(iommu->seg, bus, dev, func,
> -        iommu->msi_cap + PCI_MSI_FLAGS);
> -    control&= ~PCI_MSI_FLAGS_ENABLE;
> -    if ( flag )
> -        control |= flag;
> -    pci_conf_write16(iommu->seg, bus, dev, func,
> -        iommu->msi_cap + PCI_MSI_FLAGS, control);
> +    __msi_set_enable(iommu->seg, PCI_BUS(iommu->bdf), PCI_SLOT(iommu->bdf),
> +                     PCI_FUNC(iommu->bdf), iommu->msi_cap, flag);
>   }
>
>   static void iommu_msi_unmask(struct irq_desc *desc)
> @@ -513,10 +492,6 @@ static void iommu_msi_unmask(struct irq_
>       unsigned long flags;
>       struct amd_iommu *iommu = desc->action->dev_id;
>
> -    /* FIXME: do not support mask bits at the moment */
> -    if ( iommu->maskbit )
> -        return;
> -
>       spin_lock_irqsave(&iommu->lock, flags);
>       amd_iommu_msi_enable(iommu, IOMMU_CONTROL_ENABLED);
>       spin_unlock_irqrestore(&iommu->lock, flags);
> @@ -529,10 +504,6 @@ static void iommu_msi_mask(struct irq_de
>
>       irq_complete_move(desc);
>
> -    /* FIXME: do not support mask bits at the moment */
> -    if ( iommu->maskbit )
> -        return;
> -
>       spin_lock_irqsave(&iommu->lock, flags);
>       amd_iommu_msi_enable(iommu, IOMMU_CONTROL_DISABLED);
>       spin_unlock_irqrestore(&iommu->lock, flags);
> @@ -562,6 +533,37 @@ static hw_irq_controller iommu_msi_type
>       .set_affinity = iommu_msi_set_affinity,
>   };
>
> +static unsigned int iommu_maskable_msi_startup(struct irq_desc *desc)
> +{
> +    iommu_msi_unmask(desc);
> +    unmask_msi_irq(desc);
> +    return 0;
> +}
> +
> +static void iommu_maskable_msi_shutdown(struct irq_desc *desc)
> +{
> +    mask_msi_irq(desc);
> +    iommu_msi_mask(desc);
> +}
> +
> +/*
> + * While the names may appear mismatched, we indeed want to use the non-
> + * maskable flavors here, as we want the ACK to be issued in ->end().
> + */
> +#define iommu_maskable_msi_ack ack_nonmaskable_msi_irq
> +#define iommu_maskable_msi_end end_nonmaskable_msi_irq
> +
> +static hw_irq_controller iommu_maskable_msi_type = {
> +    .typename = "IOMMU-M-MSI",
> +    .startup = iommu_maskable_msi_startup,
> +    .shutdown = iommu_maskable_msi_shutdown,
> +    .enable = unmask_msi_irq,
> +    .disable = mask_msi_irq,
> +    .ack = iommu_maskable_msi_ack,
> +    .end = iommu_maskable_msi_end,
> +    .set_affinity = iommu_msi_set_affinity,
> +};
> +
>   static void parse_event_log_entry(struct amd_iommu *iommu, u32 entry[])
>   {
>       u16 domain_id, device_id, bdf, cword, flags;
> @@ -784,6 +786,7 @@ static void iommu_interrupt_handler(int
>   static int __init set_iommu_interrupt_handler(struct amd_iommu *iommu)
>   {
>       int irq, ret;
> +    u16 control;
>
>       irq = create_irq(NUMA_NO_NODE);
>       if ( irq<= 0 )
> @@ -792,7 +795,11 @@ static int __init set_iommu_interrupt_ha
>           return 0;
>       }
>
> -    irq_desc[irq].handler =&iommu_msi_type;
> +    control = pci_conf_read16(iommu->seg, PCI_BUS(iommu->bdf),
> +                              PCI_SLOT(iommu->bdf), PCI_FUNC(iommu->bdf),
> +                              iommu->msi_cap + PCI_MSI_FLAGS);
> +    irq_desc[irq].handler = control&  PCI_MSI_FLAGS_MASKBIT ?
> +&iommu_maskable_msi_type :&iommu_msi_type;
>       ret = request_irq(irq, iommu_interrupt_handler, 0, "amd_iommu", iommu);
>       if ( ret )
>       {
> --- a/xen/include/asm-x86/amd-iommu.h
> +++ b/xen/include/asm-x86/amd-iommu.h
> @@ -83,6 +83,7 @@ struct amd_iommu {
>       u16 seg;
>       u16 bdf;
>       u16 cap_offset;
> +    u8 msi_cap;
>       iommu_cap_t cap;
>
>       u8 ht_flags;
> @@ -101,9 +102,6 @@ struct amd_iommu {
>       uint64_t exclusion_base;
>       uint64_t exclusion_limit;
>
> -    int msi_cap;
> -    int maskbit;
> -
>       int enabled;
>       int irq;
>   };
> --- a/xen/include/asm-x86/msi.h
> +++ b/xen/include/asm-x86/msi.h
> @@ -153,18 +153,6 @@ int msi_free_irq(struct msi_desc *entry)
>   /*
>    * MSI Defined Data Structures
>    */
> -#define MSI_ADDRESS_HEADER		0xfee
> -#define MSI_ADDRESS_HEADER_SHIFT	12
> -#define MSI_ADDRESS_HEADER_MASK		0xfff000
> -#define MSI_ADDRESS_DEST_ID_MASK	0xfff0000f
> -#define MSI_TARGET_CPU_MASK		0xff
> -#define MSI_TARGET_CPU_SHIFT		12
> -#define MSI_DELIVERY_MODE		0
> -#define MSI_LEVEL_MODE			1	/* Edge always assert */
> -#define MSI_TRIGGER_MODE		0	/* MSI is edge sensitive */
> -#define MSI_PHYSICAL_MODE		0
> -#define MSI_LOGICAL_MODE		1
> -#define MSI_REDIRECTION_HINT_MODE	0
>
>   struct msg_data {
>   #if defined(__LITTLE_ENDIAN_BITFIELD)
> @@ -213,5 +201,10 @@ struct msg_address {
>   } __attribute__ ((packed));
>
>   void msi_compose_msg(struct irq_desc *, struct msi_msg *);
> +void __msi_set_enable(u16 seg, u8 bus, u8 slot, u8 func, int pos, int enable);
> +void mask_msi_irq(struct irq_desc *);
> +void unmask_msi_irq(struct irq_desc *);
> +void ack_nonmaskable_msi_irq(struct irq_desc *);
> +void end_nonmaskable_msi_irq(struct irq_desc *, u8 vector);
>
>   #endif /* __ASM_MSI_H */
>
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 12 12:47:07 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Sep 2012 12:47:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TBmL6-0002AC-A2; Wed, 12 Sep 2012 12:46:44 +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 1TBmL4-00029w-Ll
	for xen-devel@lists.xen.org; Wed, 12 Sep 2012 12:46:43 +0000
Received: from [85.158.143.35:28137] by server-3.bemta-4.messagelabs.com id
	B2/B5-08232-23480505; Wed, 12 Sep 2012 12:46:42 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1347453974!6881799!1
X-Originating-IP: [216.32.180.186]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19569 invoked from network); 12 Sep 2012 12:46:16 -0000
Received: from co1ehsobe003.messaging.microsoft.com (HELO
	co1outboundpool.messaging.microsoft.com) (216.32.180.186)
	by server-9.tower-21.messagelabs.com with AES128-SHA encrypted SMTP;
	12 Sep 2012 12:46:16 -0000
Received: from mail56-co1-R.bigfish.com (10.243.78.237) by
	CO1EHSOBE012.bigfish.com (10.243.66.75) with Microsoft SMTP Server id
	14.1.225.23; Wed, 12 Sep 2012 12:46:14 +0000
Received: from mail56-co1 (localhost [127.0.0.1])	by mail56-co1-R.bigfish.com
	(Postfix) with ESMTP id 4AC6CB000E5;
	Wed, 12 Sep 2012 12:46:14 +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(zzbb2dI98dI9371I1432I4015Izz1202h1d1ah1d2ahzz8275bhz2dh668h839he5bhf0ah107ah1288h12a5h12bdh1155h)
Received: from mail56-co1 (localhost.localdomain [127.0.0.1]) by mail56-co1
	(MessageSwitch) id 13474539714654_927;
	Wed, 12 Sep 2012 12:46:11 +0000 (UTC)
Received: from CO1EHSMHS013.bigfish.com (unknown [10.243.78.248])	by
	mail56-co1.bigfish.com (Postfix) with ESMTP id E948E3C0043;
	Wed, 12 Sep 2012 12:46:10 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	CO1EHSMHS013.bigfish.com (10.243.66.23) with Microsoft SMTP Server id
	14.1.225.23; Wed, 12 Sep 2012 12:46:09 +0000
X-WSS-ID: 0MA8M4R-02-DBR-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 2DD66C80D2;	Wed, 12 Sep 2012 07:46: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;
	Wed, 12 Sep 2012 07:59:53 -0500
Received: from storexhtp01.amd.com (172.24.4.3) by sausexdag02.amd.com
	(163.181.55.2) with Microsoft SMTP Server (TLS) id 14.1.323.3;
	Wed, 12 Sep 2012 07:46:07 -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, 12 Sep 2012
	08:46:05 -0400
Received: from [165.204.15.57] (gran.osrc.amd.com [165.204.15.57])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id C8B5549C0D5; Wed, 12 Sep 2012
	13:46:04 +0100 (BST)
Message-ID: <50508466.20309@amd.com>
Date: Wed, 12 Sep 2012 14:47:34 +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: <504F4C24020000780009A968@nat28.tlf.novell.com>
In-Reply-To: <504F4C24020000780009A968@nat28.tlf.novell.com>
X-OriginatorOrg: amd.com
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 2/3] amd iommu: use base platform MSI
	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-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi Jan
I found this patch triggered a xen BUG
Thanks,
Wei

XEN) Xen BUG at spinlock.c:48
(XEN) ----[ Xen-4.3-unstable  x86_64  debug=y  Tainted:    C ]----
(XEN) CPU:    0
(XEN) RIP:    e008:[<ffff82c4801254d2>] check_lock+0x32/0x3e
(XEN) RFLAGS: 0000000000010046   CONTEXT: hypervisor
(XEN) rax: 0000000000000000   rbx: ffff83014fff9868   rcx: 0000000000000001
(XEN) rdx: 0000000000000000   rsi: ffff83014fff8000   rdi: ffff83014fff986c
(XEN) rbp: ffff82c4802c7c80   rsp: ffff82c4802c7c80   r8:  0000000000000039
(XEN) r9:  ffff83014ff37cb0   r10: 00000000000000a0   r11: 0000000000000000
(XEN) r12: 0000000000000010   r13: 0000000000000020   r14: ffff83014fff9868
(XEN) r15: ffff83014fe9dee0   cr0: 000000008005003b   cr4: 00000000000006f0
(XEN) cr3: 0000000245c05000   cr2: ffff8800119720e0
(XEN) ds: 0000   es: 0000   fs: 0000   gs: 0000   ss: e010   cs: e008
(XEN) Xen stack trace from rsp=ffff82c4802c7c80:
(XEN)    ffff82c4802c7c98 ffff82c480125509 ffff83014fff8000 ffff82c4802c7cd8
(XEN)    ffff82c48012c2a3 00000000000000a0 0000000000000020 0000000000000010
(XEN)    0000000000000030 0000000000000000 ffff83014fe9dee0 ffff82c4802c7d28
(XEN)    ffff82c48012ca45 ffff82c4802c7cf8 ffff82c480136fd7 ffff82c4802c7d38
(XEN)    ffff82c4802c7d68 ffff83014fe03980 00000000000000b0 0000000000000000
(XEN)    ffff83014fe9dee0 ffff82c4802c7d58 ffff82c480166594 ffff83014fe03980
(XEN)    ffff83014fe03980 0000000000000039 0000000000000000 ffff82c4802c7d88
(XEN)    ffff82c4801667d7 0000000000000000 0000000000000000 ffff83014fe03980
(XEN)    ffff83014ff72000 ffff82c4802c7df8 ffff82c48016affa ffff82c4802c7dc8
(XEN)    ffff82c4802c7ea8 0000000000000246 ffff83014fe039a4 ffff83014ff137a0
(XEN)    ffff83014ff13300 ffff82c4802c7df8 0000000000000000 0000000000000039
(XEN)    0000000000000000 ffff82c4802c7e88 ffff82c4802c7e8c ffff82c4802c7e68
(XEN)    ffff82c48017cb01 ffff82c48027d7c0 0000000600000000 000001378013d9f4
(XEN)    ffff82c4802c7ea8 0000000000000002 ffff83014ff72000 ffff82c4802c7e68
(XEN)    fffffffffffffff2 000000000000000d ffff88000f5f1d40 ffff8300afafb000
(XEN)    0000000000000005 ffff82c4802c7ef8 ffff82c48017d3d4 ffff82c4802c7ec8
(XEN)    0000000000007ff0 ffffffffffffffff 0000001000000000 0000000000000000
(XEN)    0000000000000000 0000003910000000 ffff82c400000000 0000000000000000
(XEN)    ffffffff81d9e2f1 ffff82c4802c7ef8 ffff8300afafb000 ffff88000f5f1d40
(XEN)    ffff880015057838 ffff88000f555600 0000000000000005 00007d3b7fd380c7
(XEN) Xen call trace:
(XEN)    [<ffff82c4801254d2>] check_lock+0x32/0x3e
(XEN)    [<ffff82c480125509>] _spin_lock+0x11/0x5a
(XEN)    [<ffff82c48012c2a3>] xmem_pool_alloc+0x12b/0x49b
(XEN)    [<ffff82c48012ca45>] _xmalloc+0x132/0x222
(XEN)    [<ffff82c480166594>] msi_compose_msg+0xd1/0x195
(XEN)    [<ffff82c4801667d7>] setup_msi_irq+0x15/0x29
(XEN)    [<ffff82c48016affa>] map_domain_pirq+0x3b1/0x435
(XEN)    [<ffff82c48017cb01>] physdev_map_pirq+0x4a1/0x55d
(XEN)    [<ffff82c48017d3d4>] do_physdev_op+0x659/0x11f9
(XEN)    [<ffff82c480229188>] syscall_enter+0xc8/0x122
(XEN)
(XEN)
(XEN) ****************************************
(XEN) Panic on CPU 0:
(XEN) Xen BUG at spinlock.c:48


On 09/11/2012 02:35 PM, Jan Beulich wrote:
> Given that here, other than for VT-d, the MSI interface gets surfaced
> through a normal PCI device, the code should use as much as possible of
> the "normal" MSI support code.
>
> Further, the code can (and should) follow the "normal" MSI code in
> distinguishing the maskable and non-maskable cases at the IRQ
> controller level rather than checking the respective flag in the
> individual actors.
>
> Signed-off-by: Jan Beulich<jbeulich@suse.com>
>
> --- a/xen/arch/x86/msi.c
> +++ b/xen/arch/x86/msi.c
> @@ -126,13 +126,23 @@ void msi_compose_msg(struct irq_desc *de
>       unsigned dest;
>       int vector = desc->arch.vector;
>
> -    if ( cpumask_empty(desc->arch.cpu_mask) ) {
> +    memset(msg, 0, sizeof(*msg));
> +    if ( !cpumask_intersects(desc->arch.cpu_mask,&cpu_online_map) ) {
>           dprintk(XENLOG_ERR,"%s, compose msi message error!!\n", __func__);
>           return;
>       }
>
>       if ( vector ) {
> -        dest = cpu_mask_to_apicid(desc->arch.cpu_mask);
> +        cpumask_var_t mask;
> +
> +        if ( alloc_cpumask_var(&mask) )
> +        {
> +            cpumask_and(mask, desc->arch.cpu_mask,&cpu_online_map);
> +            dest = cpu_mask_to_apicid(mask);
> +            free_cpumask_var(mask);
> +        }
> +        else
> +            dest = cpu_mask_to_apicid(desc->arch.cpu_mask);
>
>           msg->address_hi = MSI_ADDR_BASE_HI;
>           msg->address_lo =
> @@ -281,23 +291,27 @@ static void set_msi_affinity(struct irq_
>       write_msi_msg(msi_desc,&msg);
>   }
>
> +void __msi_set_enable(u16 seg, u8 bus, u8 slot, u8 func, int pos, int enable)
> +{
> +    u16 control = pci_conf_read16(seg, bus, slot, func, pos + PCI_MSI_FLAGS);
> +
> +    control&= ~PCI_MSI_FLAGS_ENABLE;
> +    if ( enable )
> +        control |= PCI_MSI_FLAGS_ENABLE;
> +    pci_conf_write16(seg, bus, slot, func, pos + PCI_MSI_FLAGS, control);
> +}
> +
>   static void msi_set_enable(struct pci_dev *dev, int enable)
>   {
>       int pos;
> -    u16 control, seg = dev->seg;
> +    u16 seg = dev->seg;
>       u8 bus = dev->bus;
>       u8 slot = PCI_SLOT(dev->devfn);
>       u8 func = PCI_FUNC(dev->devfn);
>
>       pos = pci_find_cap_offset(seg, bus, slot, func, PCI_CAP_ID_MSI);
>       if ( pos )
> -    {
> -        control = pci_conf_read16(seg, bus, slot, func, pos + PCI_MSI_FLAGS);
> -        control&= ~PCI_MSI_FLAGS_ENABLE;
> -        if ( enable )
> -            control |= PCI_MSI_FLAGS_ENABLE;
> -        pci_conf_write16(seg, bus, slot, func, pos + PCI_MSI_FLAGS, control);
> -    }
> +        __msi_set_enable(seg, bus, slot, func, pos, enable);
>   }
>
>   static void msix_set_enable(struct pci_dev *dev, int enable)
> @@ -379,12 +393,12 @@ static int msi_get_mask_bit(const struct
>       return -1;
>   }
>
> -static void mask_msi_irq(struct irq_desc *desc)
> +void mask_msi_irq(struct irq_desc *desc)
>   {
>       msi_set_mask_bit(desc, 1);
>   }
>
> -static void unmask_msi_irq(struct irq_desc *desc)
> +void unmask_msi_irq(struct irq_desc *desc)
>   {
>       msi_set_mask_bit(desc, 0);
>   }
> @@ -395,7 +409,7 @@ static unsigned int startup_msi_irq(stru
>       return 0;
>   }
>
> -static void ack_nonmaskable_msi_irq(struct irq_desc *desc)
> +void ack_nonmaskable_msi_irq(struct irq_desc *desc)
>   {
>       irq_complete_move(desc);
>       move_native_irq(desc);
> @@ -407,7 +421,7 @@ static void ack_maskable_msi_irq(struct
>       ack_APIC_irq(); /* ACKTYPE_NONE */
>   }
>
> -static void end_nonmaskable_msi_irq(struct irq_desc *desc, u8 vector)
> +void end_nonmaskable_msi_irq(struct irq_desc *desc, u8 vector)
>   {
>       ack_APIC_irq(); /* ACKTYPE_EOI */
>   }
> --- a/xen/drivers/passthrough/amd/iommu_detect.c
> +++ b/xen/drivers/passthrough/amd/iommu_detect.c
> @@ -31,7 +31,6 @@ static int __init get_iommu_msi_capabili
>       u16 seg, u8 bus, u8 dev, u8 func, struct amd_iommu *iommu)
>   {
>       int pos;
> -    u16 control;
>
>       pos = pci_find_cap_offset(seg, bus, dev, func, PCI_CAP_ID_MSI);
>
> @@ -41,9 +40,6 @@ static int __init get_iommu_msi_capabili
>       AMD_IOMMU_DEBUG("Found MSI capability block at %#x\n", pos);
>
>       iommu->msi_cap = pos;
> -    control = pci_conf_read16(seg, bus, dev, func,
> -                              iommu->msi_cap + PCI_MSI_FLAGS);
> -    iommu->maskbit = control&  PCI_MSI_FLAGS_MASKBIT;
>       return 0;
>   }
>
> --- a/xen/drivers/passthrough/amd/iommu_init.c
> +++ b/xen/drivers/passthrough/amd/iommu_init.c
> @@ -467,20 +467,9 @@ static void iommu_msi_set_affinity(struc
>           return;
>       }
>
> -    memset(&msg, 0, sizeof(msg));
> -    msg.data = MSI_DATA_VECTOR(desc->arch.vector)&  0xff;
> -    msg.data |= 1<<  14;
> -    msg.data |= (INT_DELIVERY_MODE != dest_LowestPrio) ?
> -        MSI_DATA_DELIVERY_FIXED:
> -        MSI_DATA_DELIVERY_LOWPRI;
> -
> -    msg.address_hi =0;
> -    msg.address_lo = (MSI_ADDRESS_HEADER<<  (MSI_ADDRESS_HEADER_SHIFT + 8));
> -    msg.address_lo |= INT_DEST_MODE ? MSI_ADDR_DESTMODE_LOGIC:
> -                    MSI_ADDR_DESTMODE_PHYS;
> -    msg.address_lo |= (INT_DELIVERY_MODE != dest_LowestPrio) ?
> -                    MSI_ADDR_REDIRECTION_CPU:
> -                    MSI_ADDR_REDIRECTION_LOWPRI;
> +    msi_compose_msg(desc,&msg);
> +    /* Is this override really needed? */
> +    msg.address_lo&= ~MSI_ADDR_DEST_ID_MASK;
>       msg.address_lo |= MSI_ADDR_DEST_ID(dest&  0xff);
>
>       pci_conf_write32(seg, bus, dev, func,
> @@ -494,18 +483,8 @@ static void iommu_msi_set_affinity(struc
>
>   static void amd_iommu_msi_enable(struct amd_iommu *iommu, int flag)
>   {
> -    u16 control;
> -    int bus = PCI_BUS(iommu->bdf);
> -    int dev = PCI_SLOT(iommu->bdf);
> -    int func = PCI_FUNC(iommu->bdf);
> -
> -    control = pci_conf_read16(iommu->seg, bus, dev, func,
> -        iommu->msi_cap + PCI_MSI_FLAGS);
> -    control&= ~PCI_MSI_FLAGS_ENABLE;
> -    if ( flag )
> -        control |= flag;
> -    pci_conf_write16(iommu->seg, bus, dev, func,
> -        iommu->msi_cap + PCI_MSI_FLAGS, control);
> +    __msi_set_enable(iommu->seg, PCI_BUS(iommu->bdf), PCI_SLOT(iommu->bdf),
> +                     PCI_FUNC(iommu->bdf), iommu->msi_cap, flag);
>   }
>
>   static void iommu_msi_unmask(struct irq_desc *desc)
> @@ -513,10 +492,6 @@ static void iommu_msi_unmask(struct irq_
>       unsigned long flags;
>       struct amd_iommu *iommu = desc->action->dev_id;
>
> -    /* FIXME: do not support mask bits at the moment */
> -    if ( iommu->maskbit )
> -        return;
> -
>       spin_lock_irqsave(&iommu->lock, flags);
>       amd_iommu_msi_enable(iommu, IOMMU_CONTROL_ENABLED);
>       spin_unlock_irqrestore(&iommu->lock, flags);
> @@ -529,10 +504,6 @@ static void iommu_msi_mask(struct irq_de
>
>       irq_complete_move(desc);
>
> -    /* FIXME: do not support mask bits at the moment */
> -    if ( iommu->maskbit )
> -        return;
> -
>       spin_lock_irqsave(&iommu->lock, flags);
>       amd_iommu_msi_enable(iommu, IOMMU_CONTROL_DISABLED);
>       spin_unlock_irqrestore(&iommu->lock, flags);
> @@ -562,6 +533,37 @@ static hw_irq_controller iommu_msi_type
>       .set_affinity = iommu_msi_set_affinity,
>   };
>
> +static unsigned int iommu_maskable_msi_startup(struct irq_desc *desc)
> +{
> +    iommu_msi_unmask(desc);
> +    unmask_msi_irq(desc);
> +    return 0;
> +}
> +
> +static void iommu_maskable_msi_shutdown(struct irq_desc *desc)
> +{
> +    mask_msi_irq(desc);
> +    iommu_msi_mask(desc);
> +}
> +
> +/*
> + * While the names may appear mismatched, we indeed want to use the non-
> + * maskable flavors here, as we want the ACK to be issued in ->end().
> + */
> +#define iommu_maskable_msi_ack ack_nonmaskable_msi_irq
> +#define iommu_maskable_msi_end end_nonmaskable_msi_irq
> +
> +static hw_irq_controller iommu_maskable_msi_type = {
> +    .typename = "IOMMU-M-MSI",
> +    .startup = iommu_maskable_msi_startup,
> +    .shutdown = iommu_maskable_msi_shutdown,
> +    .enable = unmask_msi_irq,
> +    .disable = mask_msi_irq,
> +    .ack = iommu_maskable_msi_ack,
> +    .end = iommu_maskable_msi_end,
> +    .set_affinity = iommu_msi_set_affinity,
> +};
> +
>   static void parse_event_log_entry(struct amd_iommu *iommu, u32 entry[])
>   {
>       u16 domain_id, device_id, bdf, cword, flags;
> @@ -784,6 +786,7 @@ static void iommu_interrupt_handler(int
>   static int __init set_iommu_interrupt_handler(struct amd_iommu *iommu)
>   {
>       int irq, ret;
> +    u16 control;
>
>       irq = create_irq(NUMA_NO_NODE);
>       if ( irq<= 0 )
> @@ -792,7 +795,11 @@ static int __init set_iommu_interrupt_ha
>           return 0;
>       }
>
> -    irq_desc[irq].handler =&iommu_msi_type;
> +    control = pci_conf_read16(iommu->seg, PCI_BUS(iommu->bdf),
> +                              PCI_SLOT(iommu->bdf), PCI_FUNC(iommu->bdf),
> +                              iommu->msi_cap + PCI_MSI_FLAGS);
> +    irq_desc[irq].handler = control&  PCI_MSI_FLAGS_MASKBIT ?
> +&iommu_maskable_msi_type :&iommu_msi_type;
>       ret = request_irq(irq, iommu_interrupt_handler, 0, "amd_iommu", iommu);
>       if ( ret )
>       {
> --- a/xen/include/asm-x86/amd-iommu.h
> +++ b/xen/include/asm-x86/amd-iommu.h
> @@ -83,6 +83,7 @@ struct amd_iommu {
>       u16 seg;
>       u16 bdf;
>       u16 cap_offset;
> +    u8 msi_cap;
>       iommu_cap_t cap;
>
>       u8 ht_flags;
> @@ -101,9 +102,6 @@ struct amd_iommu {
>       uint64_t exclusion_base;
>       uint64_t exclusion_limit;
>
> -    int msi_cap;
> -    int maskbit;
> -
>       int enabled;
>       int irq;
>   };
> --- a/xen/include/asm-x86/msi.h
> +++ b/xen/include/asm-x86/msi.h
> @@ -153,18 +153,6 @@ int msi_free_irq(struct msi_desc *entry)
>   /*
>    * MSI Defined Data Structures
>    */
> -#define MSI_ADDRESS_HEADER		0xfee
> -#define MSI_ADDRESS_HEADER_SHIFT	12
> -#define MSI_ADDRESS_HEADER_MASK		0xfff000
> -#define MSI_ADDRESS_DEST_ID_MASK	0xfff0000f
> -#define MSI_TARGET_CPU_MASK		0xff
> -#define MSI_TARGET_CPU_SHIFT		12
> -#define MSI_DELIVERY_MODE		0
> -#define MSI_LEVEL_MODE			1	/* Edge always assert */
> -#define MSI_TRIGGER_MODE		0	/* MSI is edge sensitive */
> -#define MSI_PHYSICAL_MODE		0
> -#define MSI_LOGICAL_MODE		1
> -#define MSI_REDIRECTION_HINT_MODE	0
>
>   struct msg_data {
>   #if defined(__LITTLE_ENDIAN_BITFIELD)
> @@ -213,5 +201,10 @@ struct msg_address {
>   } __attribute__ ((packed));
>
>   void msi_compose_msg(struct irq_desc *, struct msi_msg *);
> +void __msi_set_enable(u16 seg, u8 bus, u8 slot, u8 func, int pos, int enable);
> +void mask_msi_irq(struct irq_desc *);
> +void unmask_msi_irq(struct irq_desc *);
> +void ack_nonmaskable_msi_irq(struct irq_desc *);
> +void end_nonmaskable_msi_irq(struct irq_desc *, u8 vector);
>
>   #endif /* __ASM_MSI_H */
>
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 12 13:09:46 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Sep 2012 13:09:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TBmh2-0002VM-Nx; Wed, 12 Sep 2012 13:09:24 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1TBmh0-0002VH-Tw
	for xen-devel@lists.xen.org; Wed, 12 Sep 2012 13:09:23 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1347455355!10737990!1
X-Originating-IP: [74.125.83.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22444 invoked from network); 12 Sep 2012 13:09:16 -0000
Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com)
	(74.125.83.45)
	by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Sep 2012 13:09:16 -0000
Received: by eeke53 with SMTP id e53so1350839eek.32
	for <xen-devel@lists.xen.org>; Wed, 12 Sep 2012 06:09:15 -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=eEPTEZg+DqkktVDhSFsdnH31zCPEGS11IXTh3iUlCxs=;
	b=uAIyVmeh6f9SsNsIkH5IX5HYdKaDbYLEqV1T/l2Ue6XtpXv1JLrR9aWxvRy+8aKrIt
	pZykePByAWNpvO40ILH3qsserKRnpx3BG3cXNsvSK/J1lITAPBzdq5QCUHq0fOffddjY
	06SPwhde850/E8r+GFmCbJWHAdG/GGVPTGBGvev2NXT9kHUpcGaMozsUuaIgGavUtTyk
	onYmou68Jv5xqXDF0hH8S3ni3gO9dVF0ZDX3XS6fjDTAhGXHxZfcywZepM+oF+izZx3O
	G4lKEuth/qIVpqIfc5XGkWRgVwTxE1zhhCSwi8Oa59/7y5TQNdvxnIDgPQy0m0gips8S
	nJww==
Received: by 10.14.213.137 with SMTP id a9mr30751618eep.38.1347455355742;
	Wed, 12 Sep 2012 06:09:15 -0700 (PDT)
Received: from [192.168.1.3] (host86-184-74-117.range86-184.btcentralplus.com.
	[86.184.74.117])
	by mx.google.com with ESMTPS id y1sm56133214eel.0.2012.09.12.06.09.13
	(version=SSLv3 cipher=OTHER); Wed, 12 Sep 2012 06:09:14 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.33.0.120411
Date: Wed, 12 Sep 2012 14:09:10 +0100
From: Keir Fraser <keir@xen.org>
To: Ian Campbell <Ian.Campbell@citrix.com>, xen-devel <xen-devel@lists.xen.org>
Message-ID: <CC764806.4B7E5%keir@xen.org>
Thread-Topic: [Xen-devel] [PATCH] tools: drop ia64 support.
Thread-Index: Ac2Q58wezpuHl9Yg2kGiUuDugUHjUg==
In-Reply-To: <1347360482.5305.143.camel@zakaz.uk.xensource.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] [PATCH] tools: drop ia64 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 11/09/2012 11:48, "Ian Campbell" <Ian.Campbell@citrix.com> wrote:

> Removed support from libxc and mini-os.
> 
> This also took me under xen/include/public via various symlinks.
> 
> Dropped tools/debugger/xenitp entirely, it was described upon commit as:
> "Xenitp is a low-level debugger for ia64" and doesn't appear to be
> linked into the build anywhere.
> 
>  99 files changed, 14 insertions(+), 32361 deletions(-)
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

Acked-by: Keir Fraser <keir@xen.org>

> Patch is compressed and attached because it is 1.2M in size
> uncompressed.
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Sep 12 13:09:46 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Sep 2012 13:09:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TBmh2-0002VM-Nx; Wed, 12 Sep 2012 13:09:24 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1TBmh0-0002VH-Tw
	for xen-devel@lists.xen.org; Wed, 12 Sep 2012 13:09:23 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1347455355!10737990!1
X-Originating-IP: [74.125.83.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22444 invoked from network); 12 Sep 2012 13:09:16 -0000
Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com)
	(74.125.83.45)
	by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Sep 2012 13:09:16 -0000
Received: by eeke53 with SMTP id e53so1350839eek.32
	for <xen-devel@lists.xen.org>; Wed, 12 Sep 2012 06:09:15 -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=eEPTEZg+DqkktVDhSFsdnH31zCPEGS11IXTh3iUlCxs=;
	b=uAIyVmeh6f9SsNsIkH5IX5HYdKaDbYLEqV1T/l2Ue6XtpXv1JLrR9aWxvRy+8aKrIt
	pZykePByAWNpvO40ILH3qsserKRnpx3BG3cXNsvSK/J1lITAPBzdq5QCUHq0fOffddjY
	06SPwhde850/E8r+GFmCbJWHAdG/GGVPTGBGvev2NXT9kHUpcGaMozsUuaIgGavUtTyk
	onYmou68Jv5xqXDF0hH8S3ni3gO9dVF0ZDX3XS6fjDTAhGXHxZfcywZepM+oF+izZx3O
	G4lKEuth/qIVpqIfc5XGkWRgVwTxE1zhhCSwi8Oa59/7y5TQNdvxnIDgPQy0m0gips8S
	nJww==
Received: by 10.14.213.137 with SMTP id a9mr30751618eep.38.1347455355742;
	Wed, 12 Sep 2012 06:09:15 -0700 (PDT)
Received: from [192.168.1.3] (host86-184-74-117.range86-184.btcentralplus.com.
	[86.184.74.117])
	by mx.google.com with ESMTPS id y1sm56133214eel.0.2012.09.12.06.09.13
	(version=SSLv3 cipher=OTHER); Wed, 12 Sep 2012 06:09:14 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.33.0.120411
Date: Wed, 12 Sep 2012 14:09:10 +0100
From: Keir Fraser <keir@xen.org>
To: Ian Campbell <Ian.Campbell@citrix.com>, xen-devel <xen-devel@lists.xen.org>
Message-ID: <CC764806.4B7E5%keir@xen.org>
Thread-Topic: [Xen-devel] [PATCH] tools: drop ia64 support.
Thread-Index: Ac2Q58wezpuHl9Yg2kGiUuDugUHjUg==
In-Reply-To: <1347360482.5305.143.camel@zakaz.uk.xensource.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] [PATCH] tools: drop ia64 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 11/09/2012 11:48, "Ian Campbell" <Ian.Campbell@citrix.com> wrote:

> Removed support from libxc and mini-os.
> 
> This also took me under xen/include/public via various symlinks.
> 
> Dropped tools/debugger/xenitp entirely, it was described upon commit as:
> "Xenitp is a low-level debugger for ia64" and doesn't appear to be
> linked into the build anywhere.
> 
>  99 files changed, 14 insertions(+), 32361 deletions(-)
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

Acked-by: Keir Fraser <keir@xen.org>

> Patch is compressed and attached because it is 1.2M in size
> uncompressed.
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Sep 12 13:16:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Sep 2012 13:16: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 1TBmny-0002f0-8r; Wed, 12 Sep 2012 13:16:34 +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 1TBmnv-0002ev-Tm
	for xen-devel@lists.xensource.com; Wed, 12 Sep 2012 13:16:32 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1347455785!9452697!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDg4MjM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22695 invoked from network); 12 Sep 2012 13:16:25 -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;
	12 Sep 2012 13:16:25 -0000
X-IronPort-AV: E=Sophos;i="4.80,410,1344211200"; d="scan'208";a="14496275"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Sep 2012 13:16: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.279.1; Wed, 12 Sep 2012 14:16: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 1TBmnm-0007ZG-2E;
	Wed, 12 Sep 2012 13:16:22 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1TBmnm-0002ZW-0m;
	Wed, 12 Sep 2012 14:16:22 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-13693-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 12 Sep 2012 14:16:22 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.0-testing test] 13693: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 13693 xen-4.0-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13693/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-i386                    4 xen-build                 fail REGR. vs. 13650
 build-amd64-oldkern           4 xen-build                 fail REGR. vs. 13650
 build-amd64                   4 xen-build                 fail REGR. vs. 13650
 build-i386-oldkern            4 xen-build                 fail REGR. vs. 13650

Tests which did not succeed, but are not blocking:
 test-amd64-i386-xl-multivcpu  1 xen-build-check(1)           blocked  n/a
 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-i386-xl            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pv            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  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-pv           1 xen-build-check(1)           blocked  n/a
 test-i386-i386-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-qemuu-rhel6hvm-intel  1 xen-build-check(1)         blocked n/a
 test-amd64-amd64-xl-sedf      1 xen-build-check(1)           blocked  n/a
 test-i386-i386-pair           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-credit2    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pair          1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pair         1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-amd  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 xen-build-check(1)         blocked n/a
 test-amd64-i386-win-vcpus1    1 xen-build-check(1)           blocked  n/a
 test-i386-i386-win            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xend-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win           1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-win          1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-winxpsp3-vcpus1  1 xen-build-check(1)           blocked n/a
 test-amd64-amd64-xl-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-win-vcpus1  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win       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-qemuu-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                  512168f88df9
baseline version:
 xen                  79444af3258c

------------------------------------------------------------
People who touched revisions under test:
------------------------------------------------------------

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-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.

------------------------------------------------------------
changeset:   21616:512168f88df9
tag:         tip
user:        Ian Jackson <Ian.Jackson@eu.citrix.com>
date:        Tue Sep 11 14:35:26 2012 +0100
    
    QEMU_TAG update
    
    
changeset:   21615:79444af3258c
user:        Ian Jackson <Ian.Jackson@eu.citrix.com>
date:        Wed Sep 05 12:40:12 2012 +0100
    
    QEMU_TAG update (XSA-17 / CVE-2012-3515)
    
    
(qemu changes not included)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 12 13:16:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Sep 2012 13:16: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 1TBmny-0002f0-8r; Wed, 12 Sep 2012 13:16:34 +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 1TBmnv-0002ev-Tm
	for xen-devel@lists.xensource.com; Wed, 12 Sep 2012 13:16:32 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1347455785!9452697!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDg4MjM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22695 invoked from network); 12 Sep 2012 13:16:25 -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;
	12 Sep 2012 13:16:25 -0000
X-IronPort-AV: E=Sophos;i="4.80,410,1344211200"; d="scan'208";a="14496275"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Sep 2012 13:16: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.279.1; Wed, 12 Sep 2012 14:16: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 1TBmnm-0007ZG-2E;
	Wed, 12 Sep 2012 13:16:22 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1TBmnm-0002ZW-0m;
	Wed, 12 Sep 2012 14:16:22 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-13693-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 12 Sep 2012 14:16:22 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.0-testing test] 13693: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 13693 xen-4.0-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13693/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-i386                    4 xen-build                 fail REGR. vs. 13650
 build-amd64-oldkern           4 xen-build                 fail REGR. vs. 13650
 build-amd64                   4 xen-build                 fail REGR. vs. 13650
 build-i386-oldkern            4 xen-build                 fail REGR. vs. 13650

Tests which did not succeed, but are not blocking:
 test-amd64-i386-xl-multivcpu  1 xen-build-check(1)           blocked  n/a
 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-i386-xl            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pv            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  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-pv           1 xen-build-check(1)           blocked  n/a
 test-i386-i386-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-qemuu-rhel6hvm-intel  1 xen-build-check(1)         blocked n/a
 test-amd64-amd64-xl-sedf      1 xen-build-check(1)           blocked  n/a
 test-i386-i386-pair           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-credit2    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pair          1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pair         1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-amd  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 xen-build-check(1)         blocked n/a
 test-amd64-i386-win-vcpus1    1 xen-build-check(1)           blocked  n/a
 test-i386-i386-win            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xend-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win           1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-win          1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-winxpsp3-vcpus1  1 xen-build-check(1)           blocked n/a
 test-amd64-amd64-xl-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-win-vcpus1  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win       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-qemuu-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                  512168f88df9
baseline version:
 xen                  79444af3258c

------------------------------------------------------------
People who touched revisions under test:
------------------------------------------------------------

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-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.

------------------------------------------------------------
changeset:   21616:512168f88df9
tag:         tip
user:        Ian Jackson <Ian.Jackson@eu.citrix.com>
date:        Tue Sep 11 14:35:26 2012 +0100
    
    QEMU_TAG update
    
    
changeset:   21615:79444af3258c
user:        Ian Jackson <Ian.Jackson@eu.citrix.com>
date:        Wed Sep 05 12:40:12 2012 +0100
    
    QEMU_TAG update (XSA-17 / CVE-2012-3515)
    
    
(qemu changes not included)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 12 13:20:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Sep 2012 13:20: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 1TBmrm-0002m5-Tp; Wed, 12 Sep 2012 13:20:30 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andreslc@gridcentric.ca>) id 1TBmrl-0002m0-74
	for xen-devel@lists.xen.org; Wed, 12 Sep 2012 13:20:29 +0000
Received: from [85.158.138.51:32575] by server-10.bemta-3.messagelabs.com id
	D0/49-10411-C1C80505; Wed, 12 Sep 2012 13:20:28 +0000
X-Env-Sender: andreslc@gridcentric.ca
X-Msg-Ref: server-3.tower-174.messagelabs.com!1347456026!22075874!1
X-Originating-IP: [209.85.160.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3641 invoked from network); 12 Sep 2012 13:20:27 -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;
	12 Sep 2012 13:20:27 -0000
Received: by ghy16 with SMTP id 16so449849ghy.32
	for <xen-devel@lists.xen.org>; Wed, 12 Sep 2012 06:20:26 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=subject:mime-version:content-type:from:in-reply-to:date:cc
	:content-transfer-encoding:message-id:references:to:x-mailer
	:x-gm-message-state;
	bh=/+WtPAIoGiStxxzOnHzWI1S8u/Xz8RtspwLRFgvvDEY=;
	b=KG912kFRwNO88i3C5E6RlL04QKD99Cl9e8/oDVIGZVmObQ/23JE06t8k6Ybhy0Xqm/
	C4snjr4DGAG30T5+RRNL7Q5wV/3ESckqKYdQX4c1OgtEJZiyVsqtxweOLWdZukqXNoUv
	+GrFETzaMjQcz9ni8FNxfSBIdCbCMrJ5sjCsokU1PbFoc1d3+UBGUti1EI3VjYEGD5s6
	FxPJ64g6izS/2G1V8oqZRBiyLVo/owh4qJakvLPgXKi44GLTElSpzy+Ba+chy9hDFRik
	4v2JvnPdKtP4zF3IRCd0Zm6jrDuydHTo8M/u+GYjoL/npPNhAgTlgSULONgKMswwQP58
	s/2w==
Received: by 10.236.161.135 with SMTP id w7mr19587954yhk.15.1347456025800;
	Wed, 12 Sep 2012 06:20:25 -0700 (PDT)
Received: from [192.168.7.212] ([206.223.182.18])
	by mx.google.com with ESMTPS id w5sm17593909anl.10.2012.09.12.06.20.24
	(version=TLSv1/SSLv3 cipher=OTHER);
	Wed, 12 Sep 2012 06:20:25 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1278)
From: Andres Lagar-Cavilla <andreslc@gridcentric.ca>
In-Reply-To: <4FAD394B-6A6C-44F1-AF1C-DC2F935639EE@gmail.com>
Date: Wed, 12 Sep 2012 09:20:24 -0400
Message-Id: <6F1AF3C5-6A5B-4C60-BC7E-F4ED8DD954C4@gridcentric.ca>
References: <1346086287-17674-1-git-send-email-andres@lagarcavilla.org>
	<5040CAEA.7000600@citrix.com>
	<160CC375-2682-4CBF-B1EC-06A9F3E49A40@gridcentric.ca>
	<A976B10C-58BE-4660-89E9-A8F85CAB5F19@gmail.com>
	<5040E210.2060702@citrix.com>
	<20120905162731.GD11949@phenom.dumpdata.com>
	<4FAD394B-6A6C-44F1-AF1C-DC2F935639EE@gmail.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Ian Campbell <ian.campbell@citrix.com>
X-Mailer: Apple Mail (2.1278)
X-Gm-Message-State: ALoCoQlcbP66diCO1VjMF1aE6/oPll3SeQJ6TY/lV+l4gPKLYMjyuJrr0PEqG5GFI5XL+gTMHFkz
Cc: xen-devel <xen-devel@lists.xen.org>, David Vrabel <david.vrabel@citrix.com>,
	Andres Lagar-Cavilla <andres@lagarcavilla.org>
Subject: Re: [Xen-devel] [PATCH] Xen backend support for paged out grant
	targets.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Sep 5, 2012, at 1:21 PM, Andres Lagar-Cavilla wrote:

> 
> On Sep 5, 2012, at 12:27 PM, Konrad Rzeszutek Wilk wrote:
> 
>> On Fri, Aug 31, 2012 at 05:10:56PM +0100, David Vrabel wrote:
>>> On 31/08/12 16:42, Andres Lagar-Cavilla wrote:
>>>> Actually acted upon your feedback ipso facto:
>>>> 
>>>> commit d5fab912caa1f0cf6be0a6773f502d3417a207b6
>>>> Author: Andres Lagar-Cavilla <andres@lagarcavilla.org>
>>>> Date:   Sun Aug 26 09:45:57 2012 -0400
>>>> 
>>>>   Xen backend support for paged out grant targets.
>>> 
>>> This looks mostly fine expect for the #define instead of inline functions.
>>> 
>>>> +#define gnttab_map_grant_no_eagain(_gop)                                    \
>>> 
>>> This name tripped me up previously. As I read this as:
>>> 
>>> gnttab_map_grant_no_[retries_for]_eagain().
>>> 
>>> Perhaps gnttab_map_grant_with_retries() ? Or similar?
>> 
>> gnttab_map_grant_retry ?
>> 
>> Besides that, it looks good to me. Ian Campbell needs to Ack so that
>> David Miller (the network maintainer) can pick it up. Please CC them
>> both and also LKML
Konrad, Ian, can I get some insight on the question I pose below. I have otherwise cleaned up the patch for 3.7.

Thanks
Andres
>> .
> 
> Sure will do. However, I need to bring attention to the following hunk:
> diff --git a/drivers/net/xen-netback/netback.c b/drivers/net/xen-netback/netback.c
> index 682633b..5610fd8 100644
> --- a/drivers/net/xen-netback/netback.c
> +++ b/drivers/net/xen-netback/netback.c
> @@ -635,9 +635,7 @@ static void xen_netbk_rx_action(struct xen_netbk *netbk)
> 		return;
> 
> 	BUG_ON(npo.copy_prod > ARRAY_SIZE(netbk->grant_copy_op));
> -	ret = HYPERVISOR_grant_table_op(GNTTABOP_copy, &netbk->grant_copy_op,
> -					npo.copy_prod);
> -	BUG_ON(ret != 0);
> +	gnttab_batch_copy_no_eagain(netbk->grant_copy_op, npo.copy_prod);
> 
> It seems like the (extant) code passes a struct gnttab_copy ** to the grant table hypercall (&netbk->grant_copy_op, defined as struct gnttab_copy [])
> 
> I "fixed" it to pass a struct gnttab_copy * (netbk->grant_copy_op, no '&'). This matches the other invocation of the grant copy hyper call (in netbk_tx_action). Did I fix it, though? I am confused as to how this could have ever worked.
> 
> (cc'ing Ian Campbell for more insight) 
> Andres
>>> 
>>> David
> 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 12 13:20:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Sep 2012 13:20: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 1TBmrm-0002m5-Tp; Wed, 12 Sep 2012 13:20:30 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andreslc@gridcentric.ca>) id 1TBmrl-0002m0-74
	for xen-devel@lists.xen.org; Wed, 12 Sep 2012 13:20:29 +0000
Received: from [85.158.138.51:32575] by server-10.bemta-3.messagelabs.com id
	D0/49-10411-C1C80505; Wed, 12 Sep 2012 13:20:28 +0000
X-Env-Sender: andreslc@gridcentric.ca
X-Msg-Ref: server-3.tower-174.messagelabs.com!1347456026!22075874!1
X-Originating-IP: [209.85.160.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3641 invoked from network); 12 Sep 2012 13:20:27 -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;
	12 Sep 2012 13:20:27 -0000
Received: by ghy16 with SMTP id 16so449849ghy.32
	for <xen-devel@lists.xen.org>; Wed, 12 Sep 2012 06:20:26 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=subject:mime-version:content-type:from:in-reply-to:date:cc
	:content-transfer-encoding:message-id:references:to:x-mailer
	:x-gm-message-state;
	bh=/+WtPAIoGiStxxzOnHzWI1S8u/Xz8RtspwLRFgvvDEY=;
	b=KG912kFRwNO88i3C5E6RlL04QKD99Cl9e8/oDVIGZVmObQ/23JE06t8k6Ybhy0Xqm/
	C4snjr4DGAG30T5+RRNL7Q5wV/3ESckqKYdQX4c1OgtEJZiyVsqtxweOLWdZukqXNoUv
	+GrFETzaMjQcz9ni8FNxfSBIdCbCMrJ5sjCsokU1PbFoc1d3+UBGUti1EI3VjYEGD5s6
	FxPJ64g6izS/2G1V8oqZRBiyLVo/owh4qJakvLPgXKi44GLTElSpzy+Ba+chy9hDFRik
	4v2JvnPdKtP4zF3IRCd0Zm6jrDuydHTo8M/u+GYjoL/npPNhAgTlgSULONgKMswwQP58
	s/2w==
Received: by 10.236.161.135 with SMTP id w7mr19587954yhk.15.1347456025800;
	Wed, 12 Sep 2012 06:20:25 -0700 (PDT)
Received: from [192.168.7.212] ([206.223.182.18])
	by mx.google.com with ESMTPS id w5sm17593909anl.10.2012.09.12.06.20.24
	(version=TLSv1/SSLv3 cipher=OTHER);
	Wed, 12 Sep 2012 06:20:25 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1278)
From: Andres Lagar-Cavilla <andreslc@gridcentric.ca>
In-Reply-To: <4FAD394B-6A6C-44F1-AF1C-DC2F935639EE@gmail.com>
Date: Wed, 12 Sep 2012 09:20:24 -0400
Message-Id: <6F1AF3C5-6A5B-4C60-BC7E-F4ED8DD954C4@gridcentric.ca>
References: <1346086287-17674-1-git-send-email-andres@lagarcavilla.org>
	<5040CAEA.7000600@citrix.com>
	<160CC375-2682-4CBF-B1EC-06A9F3E49A40@gridcentric.ca>
	<A976B10C-58BE-4660-89E9-A8F85CAB5F19@gmail.com>
	<5040E210.2060702@citrix.com>
	<20120905162731.GD11949@phenom.dumpdata.com>
	<4FAD394B-6A6C-44F1-AF1C-DC2F935639EE@gmail.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Ian Campbell <ian.campbell@citrix.com>
X-Mailer: Apple Mail (2.1278)
X-Gm-Message-State: ALoCoQlcbP66diCO1VjMF1aE6/oPll3SeQJ6TY/lV+l4gPKLYMjyuJrr0PEqG5GFI5XL+gTMHFkz
Cc: xen-devel <xen-devel@lists.xen.org>, David Vrabel <david.vrabel@citrix.com>,
	Andres Lagar-Cavilla <andres@lagarcavilla.org>
Subject: Re: [Xen-devel] [PATCH] Xen backend support for paged out grant
	targets.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Sep 5, 2012, at 1:21 PM, Andres Lagar-Cavilla wrote:

> 
> On Sep 5, 2012, at 12:27 PM, Konrad Rzeszutek Wilk wrote:
> 
>> On Fri, Aug 31, 2012 at 05:10:56PM +0100, David Vrabel wrote:
>>> On 31/08/12 16:42, Andres Lagar-Cavilla wrote:
>>>> Actually acted upon your feedback ipso facto:
>>>> 
>>>> commit d5fab912caa1f0cf6be0a6773f502d3417a207b6
>>>> Author: Andres Lagar-Cavilla <andres@lagarcavilla.org>
>>>> Date:   Sun Aug 26 09:45:57 2012 -0400
>>>> 
>>>>   Xen backend support for paged out grant targets.
>>> 
>>> This looks mostly fine expect for the #define instead of inline functions.
>>> 
>>>> +#define gnttab_map_grant_no_eagain(_gop)                                    \
>>> 
>>> This name tripped me up previously. As I read this as:
>>> 
>>> gnttab_map_grant_no_[retries_for]_eagain().
>>> 
>>> Perhaps gnttab_map_grant_with_retries() ? Or similar?
>> 
>> gnttab_map_grant_retry ?
>> 
>> Besides that, it looks good to me. Ian Campbell needs to Ack so that
>> David Miller (the network maintainer) can pick it up. Please CC them
>> both and also LKML
Konrad, Ian, can I get some insight on the question I pose below. I have otherwise cleaned up the patch for 3.7.

Thanks
Andres
>> .
> 
> Sure will do. However, I need to bring attention to the following hunk:
> diff --git a/drivers/net/xen-netback/netback.c b/drivers/net/xen-netback/netback.c
> index 682633b..5610fd8 100644
> --- a/drivers/net/xen-netback/netback.c
> +++ b/drivers/net/xen-netback/netback.c
> @@ -635,9 +635,7 @@ static void xen_netbk_rx_action(struct xen_netbk *netbk)
> 		return;
> 
> 	BUG_ON(npo.copy_prod > ARRAY_SIZE(netbk->grant_copy_op));
> -	ret = HYPERVISOR_grant_table_op(GNTTABOP_copy, &netbk->grant_copy_op,
> -					npo.copy_prod);
> -	BUG_ON(ret != 0);
> +	gnttab_batch_copy_no_eagain(netbk->grant_copy_op, npo.copy_prod);
> 
> It seems like the (extant) code passes a struct gnttab_copy ** to the grant table hypercall (&netbk->grant_copy_op, defined as struct gnttab_copy [])
> 
> I "fixed" it to pass a struct gnttab_copy * (netbk->grant_copy_op, no '&'). This matches the other invocation of the grant copy hyper call (in netbk_tx_action). Did I fix it, though? I am confused as to how this could have ever worked.
> 
> (cc'ing Ian Campbell for more insight) 
> Andres
>>> 
>>> David
> 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 12 13:37:32 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Sep 2012 13:37:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TBn7x-00030m-Ol; Wed, 12 Sep 2012 13:37:13 +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 1TBn7w-00030h-Nu
	for xen-devel@lists.xensource.com; Wed, 12 Sep 2012 13:37:12 +0000
Received: from [85.158.143.35:27449] by server-3.bemta-4.messagelabs.com id
	40/46-08232-80090505; Wed, 12 Sep 2012 13:37:12 +0000
X-Env-Sender: tglx@linutronix.de
X-Msg-Ref: server-6.tower-21.messagelabs.com!1347457031!17924871!1
X-Originating-IP: [62.245.132.108]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15433 invoked from network); 12 Sep 2012 13:37:11 -0000
Received: from www.linutronix.de (HELO Galois.linutronix.de) (62.245.132.108)
	by server-6.tower-21.messagelabs.com with AES256-SHA encrypted SMTP;
	12 Sep 2012 13:37:11 -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 1TBn7d-0005zT-NG; Wed, 12 Sep 2012 15:36:53 +0200
Date: Wed, 12 Sep 2012 15:36:52 +0200 (CEST)
From: Thomas Gleixner <tglx@linutronix.de>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
In-Reply-To: <20120911124359.GA5459@phenom.dumpdata.com>
Message-ID: <alpine.LFD.2.02.1209121255310.7093@ionos>
References: <1345580561-8506-1-git-send-email-attilio.rao@citrix.com>
	<alpine.LFD.2.02.1208212315330.2856@ionos>
	<20120822135753.GA30964@phenom.dumpdata.com>
	<alpine.LFD.2.02.1208221618380.2856@ionos>
	<20120911124359.GA5459@phenom.dumpdata.com>
User-Agent: Alpine 2.02 (LFD 1266 2009-07-14)
MIME-Version: 1.0
X-Linutronix-Spam-Score: -1.0
X-Linutronix-Spam-Level: -
X-Linutronix-Spam-Status: No , -1.0 points, 5.0 required, ALL_TRUSTED=-1,
	SHORTCIRCUIT=-0.0001
Cc: xen-devel@lists.xensource.com, Ian.Campbell@citrix.com,
	Stefano.Stabellini@eu.citrix.com, x86@kernel.org,
	linux-kernel@vger.kernel.org, mingo@redhat.com, hpa@zytor.com,
	Attilio Rao <attilio.rao@citrix.com>
Subject: Re: [Xen-devel] [PATCH v2 0/5] X86/XEN: Merge
 x86_init.paging.pagetable_setup_start and
 x86_init.paging.pagetable_setup_done setup functions and document its
 semantic
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 11 Sep 2012, Konrad Rzeszutek Wilk wrote:
> > > > The overall result is basically the same, but it's way simpler to look
> > > > at obvious and well done patches than checking whether a subtle copy
> > > > and paste bug happened in 3/5 of the first version. Copy and paste is
> > > > the #1 cause for subtle bugs. :)
> > > > 
> > > > I'm waiting for the ack of Xen folks before taking it into tip.
> 
> In case you are waiting for that - Acked-by: Konrad Rzeszutek Wilk
> <konrad.wilk@oracle.com>

Sorry missed the previous ack over traveling.

> > Having it in tip in an extra branch which you pull into your
> > tree. That's the easiest one.
> 
> ping? Which branch should I pull?

  tip/x86/platform head commit: 6428227

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 Sep 12 13:37:32 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Sep 2012 13:37:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TBn7x-00030m-Ol; Wed, 12 Sep 2012 13:37:13 +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 1TBn7w-00030h-Nu
	for xen-devel@lists.xensource.com; Wed, 12 Sep 2012 13:37:12 +0000
Received: from [85.158.143.35:27449] by server-3.bemta-4.messagelabs.com id
	40/46-08232-80090505; Wed, 12 Sep 2012 13:37:12 +0000
X-Env-Sender: tglx@linutronix.de
X-Msg-Ref: server-6.tower-21.messagelabs.com!1347457031!17924871!1
X-Originating-IP: [62.245.132.108]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15433 invoked from network); 12 Sep 2012 13:37:11 -0000
Received: from www.linutronix.de (HELO Galois.linutronix.de) (62.245.132.108)
	by server-6.tower-21.messagelabs.com with AES256-SHA encrypted SMTP;
	12 Sep 2012 13:37:11 -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 1TBn7d-0005zT-NG; Wed, 12 Sep 2012 15:36:53 +0200
Date: Wed, 12 Sep 2012 15:36:52 +0200 (CEST)
From: Thomas Gleixner <tglx@linutronix.de>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
In-Reply-To: <20120911124359.GA5459@phenom.dumpdata.com>
Message-ID: <alpine.LFD.2.02.1209121255310.7093@ionos>
References: <1345580561-8506-1-git-send-email-attilio.rao@citrix.com>
	<alpine.LFD.2.02.1208212315330.2856@ionos>
	<20120822135753.GA30964@phenom.dumpdata.com>
	<alpine.LFD.2.02.1208221618380.2856@ionos>
	<20120911124359.GA5459@phenom.dumpdata.com>
User-Agent: Alpine 2.02 (LFD 1266 2009-07-14)
MIME-Version: 1.0
X-Linutronix-Spam-Score: -1.0
X-Linutronix-Spam-Level: -
X-Linutronix-Spam-Status: No , -1.0 points, 5.0 required, ALL_TRUSTED=-1,
	SHORTCIRCUIT=-0.0001
Cc: xen-devel@lists.xensource.com, Ian.Campbell@citrix.com,
	Stefano.Stabellini@eu.citrix.com, x86@kernel.org,
	linux-kernel@vger.kernel.org, mingo@redhat.com, hpa@zytor.com,
	Attilio Rao <attilio.rao@citrix.com>
Subject: Re: [Xen-devel] [PATCH v2 0/5] X86/XEN: Merge
 x86_init.paging.pagetable_setup_start and
 x86_init.paging.pagetable_setup_done setup functions and document its
 semantic
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 11 Sep 2012, Konrad Rzeszutek Wilk wrote:
> > > > The overall result is basically the same, but it's way simpler to look
> > > > at obvious and well done patches than checking whether a subtle copy
> > > > and paste bug happened in 3/5 of the first version. Copy and paste is
> > > > the #1 cause for subtle bugs. :)
> > > > 
> > > > I'm waiting for the ack of Xen folks before taking it into tip.
> 
> In case you are waiting for that - Acked-by: Konrad Rzeszutek Wilk
> <konrad.wilk@oracle.com>

Sorry missed the previous ack over traveling.

> > Having it in tip in an extra branch which you pull into your
> > tree. That's the easiest one.
> 
> ping? Which branch should I pull?

  tip/x86/platform head commit: 6428227

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 Sep 12 13:45:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Sep 2012 13: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 1TBnFV-0003AD-N0; Wed, 12 Sep 2012 13:45:01 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andreslc@gridcentric.ca>) id 1TBnFT-0003A8-Qk
	for xen-devel@lists.xen.org; Wed, 12 Sep 2012 13:45:00 +0000
Received: from [85.158.143.35:38616] by server-3.bemta-4.messagelabs.com id
	DC/E7-08232-BD190505; Wed, 12 Sep 2012 13:44:59 +0000
X-Env-Sender: andreslc@gridcentric.ca
X-Msg-Ref: server-2.tower-21.messagelabs.com!1347457497!6945378!1
X-Originating-IP: [209.85.161.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22825 invoked from network); 12 Sep 2012 13:44:58 -0000
Received: from mail-gg0-f173.google.com (HELO mail-gg0-f173.google.com)
	(209.85.161.173)
	by server-2.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Sep 2012 13:44:58 -0000
Received: by ggna5 with SMTP id a5so415911ggn.32
	for <xen-devel@lists.xen.org>; Wed, 12 Sep 2012 06:44:57 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=from:content-type:content-transfer-encoding:subject:date:message-id
	:to:mime-version:x-mailer:x-gm-message-state;
	bh=+x0tvA1SK/AscchjbnXE+whkdAJJ+EXf2G/W/LoiUsY=;
	b=NthHmjqIrimjiX5mNy6Q1GmQ9wD30KILlR6EyyvgO3lDqpPBWnY9cYt38jcBfkg5UE
	A4KtEAdBx+i92bgsFEpkwvqJOSDcu0sX/bentAHlbHSyOMNBNtXxZ4p+hVGmkQ9jEDvg
	6zJzvkS1wGRkPf79U90DO1JXXaxXHRHaIOo6T1ExsfPrJtOkKqiYiMMsbyxTtQR+Re3x
	L4y6xpcvNvFbCJerD4QISzPcY6QhDOBsJqmvAVIjaq8/LaXtj3O6CQQ+n3ZlD0WP+oMa
	JupQe2S1DsrlrTSbSxptcNS+jpaM+tgAt66ZbDJFPIALiwdQv1irTk/E/fqAfEDtlA6s
	Vf6w==
Received: by 10.236.76.132 with SMTP id b4mr19640021yhe.106.1347457497098;
	Wed, 12 Sep 2012 06:44:57 -0700 (PDT)
Received: from [192.168.7.212] ([206.223.182.18])
	by mx.google.com with ESMTPS id i3sm17671677anl.0.2012.09.12.06.44.55
	(version=TLSv1/SSLv3 cipher=OTHER);
	Wed, 12 Sep 2012 06:44:56 -0700 (PDT)
From: Andres Lagar-Cavilla <andreslc@gridcentric.ca>
Date: Wed, 12 Sep 2012 09:44:55 -0400
Message-Id: <B5B91DB6-BC9C-4E0A-BCF3-243671577A40@gridcentric.ca>
To: xen-devel <xen-devel@lists.xen.org>,
	Ian Campbell <ian.campbell@citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Mime-Version: 1.0 (Apple Message framework v1278)
X-Mailer: Apple Mail (2.1278)
X-Gm-Message-State: ALoCoQn4uNZmOS2HHiVKQ9ULRame8ACVE9wP5saddbIW9zWR3qkaeiS8vi8Voq+VmQeiZVmroxxq
Subject: [Xen-devel] Libxenstore memory leak on static compile
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 statically compiling libxenstore.a, the USE_PTHREAD define is not applied. This results in cleanup_{pus/pop} being no-ops. cleanup_p* are used throughout xs.c:read_message to free malloc'ed objects.

In short, libxenstore.a will leak memory when reading xenstore messages. OOM killer awaits.

This could be solved by either turning on USE_PTHREAD for .a compilation (which, N.B. will not actually link libpthread but instead produce an object archive that needs to be eventually linked to libpthread.so), or by replacing cleanup_p* by proper free calls.

Thoughts?
Andres
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 12 13:45:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Sep 2012 13: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 1TBnFV-0003AD-N0; Wed, 12 Sep 2012 13:45:01 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andreslc@gridcentric.ca>) id 1TBnFT-0003A8-Qk
	for xen-devel@lists.xen.org; Wed, 12 Sep 2012 13:45:00 +0000
Received: from [85.158.143.35:38616] by server-3.bemta-4.messagelabs.com id
	DC/E7-08232-BD190505; Wed, 12 Sep 2012 13:44:59 +0000
X-Env-Sender: andreslc@gridcentric.ca
X-Msg-Ref: server-2.tower-21.messagelabs.com!1347457497!6945378!1
X-Originating-IP: [209.85.161.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22825 invoked from network); 12 Sep 2012 13:44:58 -0000
Received: from mail-gg0-f173.google.com (HELO mail-gg0-f173.google.com)
	(209.85.161.173)
	by server-2.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Sep 2012 13:44:58 -0000
Received: by ggna5 with SMTP id a5so415911ggn.32
	for <xen-devel@lists.xen.org>; Wed, 12 Sep 2012 06:44:57 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=from:content-type:content-transfer-encoding:subject:date:message-id
	:to:mime-version:x-mailer:x-gm-message-state;
	bh=+x0tvA1SK/AscchjbnXE+whkdAJJ+EXf2G/W/LoiUsY=;
	b=NthHmjqIrimjiX5mNy6Q1GmQ9wD30KILlR6EyyvgO3lDqpPBWnY9cYt38jcBfkg5UE
	A4KtEAdBx+i92bgsFEpkwvqJOSDcu0sX/bentAHlbHSyOMNBNtXxZ4p+hVGmkQ9jEDvg
	6zJzvkS1wGRkPf79U90DO1JXXaxXHRHaIOo6T1ExsfPrJtOkKqiYiMMsbyxTtQR+Re3x
	L4y6xpcvNvFbCJerD4QISzPcY6QhDOBsJqmvAVIjaq8/LaXtj3O6CQQ+n3ZlD0WP+oMa
	JupQe2S1DsrlrTSbSxptcNS+jpaM+tgAt66ZbDJFPIALiwdQv1irTk/E/fqAfEDtlA6s
	Vf6w==
Received: by 10.236.76.132 with SMTP id b4mr19640021yhe.106.1347457497098;
	Wed, 12 Sep 2012 06:44:57 -0700 (PDT)
Received: from [192.168.7.212] ([206.223.182.18])
	by mx.google.com with ESMTPS id i3sm17671677anl.0.2012.09.12.06.44.55
	(version=TLSv1/SSLv3 cipher=OTHER);
	Wed, 12 Sep 2012 06:44:56 -0700 (PDT)
From: Andres Lagar-Cavilla <andreslc@gridcentric.ca>
Date: Wed, 12 Sep 2012 09:44:55 -0400
Message-Id: <B5B91DB6-BC9C-4E0A-BCF3-243671577A40@gridcentric.ca>
To: xen-devel <xen-devel@lists.xen.org>,
	Ian Campbell <ian.campbell@citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Mime-Version: 1.0 (Apple Message framework v1278)
X-Mailer: Apple Mail (2.1278)
X-Gm-Message-State: ALoCoQn4uNZmOS2HHiVKQ9ULRame8ACVE9wP5saddbIW9zWR3qkaeiS8vi8Voq+VmQeiZVmroxxq
Subject: [Xen-devel] Libxenstore memory leak on static compile
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 statically compiling libxenstore.a, the USE_PTHREAD define is not applied. This results in cleanup_{pus/pop} being no-ops. cleanup_p* are used throughout xs.c:read_message to free malloc'ed objects.

In short, libxenstore.a will leak memory when reading xenstore messages. OOM killer awaits.

This could be solved by either turning on USE_PTHREAD for .a compilation (which, N.B. will not actually link libpthread but instead produce an object archive that needs to be eventually linked to libpthread.so), or by replacing cleanup_p* by proper free calls.

Thoughts?
Andres
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 12 13:46:56 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Sep 2012 13: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 1TBnH3-0003F4-63; Wed, 12 Sep 2012 13:46:37 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1TBnH1-0003Ev-JG
	for xen-devel@lists.xensource.com; Wed, 12 Sep 2012 13:46:35 +0000
Received: from [85.158.139.83:10125] by server-12.bemta-5.messagelabs.com id
	4B/FB-18300-A3290505; Wed, 12 Sep 2012 13:46:34 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1347457594!18804711!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDg4MjM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27584 invoked from network); 12 Sep 2012 13:46:34 -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;
	12 Sep 2012 13:46:34 -0000
X-IronPort-AV: E=Sophos;i="4.80,410,1344211200"; d="scan'208";a="14497266"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Sep 2012 13:46:34 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Wed, 12 Sep 2012 14:46: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
	1TBnGz-0007ma-Un	for xen-devel@lists.xensource.com;
	Wed, 12 Sep 2012 13:46:33 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1TBnGz-00022m-Pq	for
	xen-devel@lists.xensource.com; Wed, 12 Sep 2012 14:46:33 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20560.37433.653133.290651@mariner.uk.xensource.com>
Date: Wed, 12 Sep 2012 14:46:33 +0100
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
In-Reply-To: <osstest-13693-mainreport@xen.org>
References: <osstest-13693-mainreport@xen.org>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Subject: Re: [Xen-devel] [xen-4.0-testing test] 13693: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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.0-testing test] 13693: regressions - FAIL"):
> flight 13693 xen-4.0-testing real [real]
> http://www.chiark.greenend.org.uk/~xensrcts/logs/13693/
> 
> Regressions :-(
> 
> Tests which did not succeed and are blocking,
> including tests which could not be run:
>  build-i386                    4 xen-build            fail REGR. vs. 13650

This is the same as the previous failure; this build started before I
fixed the QEMU_TAG.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 12 13:46:56 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Sep 2012 13: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 1TBnH3-0003F4-63; Wed, 12 Sep 2012 13:46:37 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1TBnH1-0003Ev-JG
	for xen-devel@lists.xensource.com; Wed, 12 Sep 2012 13:46:35 +0000
Received: from [85.158.139.83:10125] by server-12.bemta-5.messagelabs.com id
	4B/FB-18300-A3290505; Wed, 12 Sep 2012 13:46:34 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1347457594!18804711!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDg4MjM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27584 invoked from network); 12 Sep 2012 13:46:34 -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;
	12 Sep 2012 13:46:34 -0000
X-IronPort-AV: E=Sophos;i="4.80,410,1344211200"; d="scan'208";a="14497266"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Sep 2012 13:46:34 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Wed, 12 Sep 2012 14:46: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
	1TBnGz-0007ma-Un	for xen-devel@lists.xensource.com;
	Wed, 12 Sep 2012 13:46:33 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1TBnGz-00022m-Pq	for
	xen-devel@lists.xensource.com; Wed, 12 Sep 2012 14:46:33 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20560.37433.653133.290651@mariner.uk.xensource.com>
Date: Wed, 12 Sep 2012 14:46:33 +0100
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
In-Reply-To: <osstest-13693-mainreport@xen.org>
References: <osstest-13693-mainreport@xen.org>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Subject: Re: [Xen-devel] [xen-4.0-testing test] 13693: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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.0-testing test] 13693: regressions - FAIL"):
> flight 13693 xen-4.0-testing real [real]
> http://www.chiark.greenend.org.uk/~xensrcts/logs/13693/
> 
> Regressions :-(
> 
> Tests which did not succeed and are blocking,
> including tests which could not be run:
>  build-i386                    4 xen-build            fail REGR. vs. 13650

This is the same as the previous failure; this build started before I
fixed the QEMU_TAG.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 12 13:47:23 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Sep 2012 13:47:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TBnHX-0003Hj-K5; Wed, 12 Sep 2012 13:47:07 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <tipbot@zytor.com>) id 1TBnHW-0003HY-Rr
	for xen-devel@lists.xensource.com; Wed, 12 Sep 2012 13:47:07 +0000
Received: from [85.158.138.51:59473] by server-4.bemta-3.messagelabs.com id
	7F/BF-24831-95290505; Wed, 12 Sep 2012 13:47:05 +0000
X-Env-Sender: tipbot@zytor.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1347457623!21285147!1
X-Originating-IP: [198.137.202.10]
X-SpamReason: No, hits=1.0 required=7.0 tests=X_MAILER_SPAM
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16218 invoked from network); 12 Sep 2012 13:47:05 -0000
Received: from terminus.zytor.com (HELO terminus.zytor.com) (198.137.202.10)
	by server-7.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 12 Sep 2012 13:47:05 -0000
Received: from terminus.zytor.com (localhost [127.0.0.1])
	by terminus.zytor.com (8.14.5/8.14.5) with ESMTP id q8CDkcgx020255
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 12 Sep 2012 06:46:43 -0700
Received: (from tipbot@localhost)
	by terminus.zytor.com (8.14.5/8.14.5/Submit) id q8CDkc5Q020252;
	Wed, 12 Sep 2012 06:46:38 -0700
Date: Wed, 12 Sep 2012 06:46:38 -0700
X-Authentication-Warning: terminus.zytor.com: tipbot set sender to
	tipbot@zytor.com using -f
From: tip-bot for Attilio Rao <attilio.rao@citrix.com>
Message-ID: <tip-73090f8993a40a2f67fed1ab866a928c68cd3765@git.kernel.org>
In-Reply-To: <1345580561-8506-2-git-send-email-attilio.rao@citrix.com>
References: <1345580561-8506-2-git-send-email-attilio.rao@citrix.com>
To: linux-tip-commits@vger.kernel.org
Git-Commit-ID: 73090f8993a40a2f67fed1ab866a928c68cd3765
X-Mailer: tip-git-log-daemon
Robot-ID: <tip-bot.git.kernel.org>
Robot-Unsubscribe: Contact <mailto:hpa@kernel.org>
	to get blacklisted from these emails
MIME-Version: 1.0
Content-Disposition: inline
Precedence: bulk
X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00,
	T_DATE_IN_FUTURE_96_Q autolearn=ham version=3.3.2
X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on terminus.zytor.com
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.6
	(terminus.zytor.com [127.0.0.1]);
	Wed, 12 Sep 2012 06:46:44 -0700 (PDT)
Cc: xen-devel@lists.xensource.com, Ian.Campbell@citrix.com,
	konrad.wilk@oracle.com, Stefano.Stabellini@eu.citrix.com,
	linux-kernel@vger.kernel.org, hpa@zytor.com,
	attilio.rao@citrix.com, tglx@linutronix.de, mingo@kernel.org
Subject: [Xen-devel] [tip:x86/platform] x86: Remove base argument from
 x86_init.paging. pagetable_setup_start
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Reply-To: mingo@kernel.org, hpa@zytor.com, linux-kernel@vger.kernel.org,
	konrad.wilk@oracle.com, Stefano.Stabellini@eu.citrix.com,
	Ian.Campbell@citrix.com, tglx@linutronix.de,
	attilio.rao@citrix.com, xen-devel@lists.xensource.com
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Commit-ID:  73090f8993a40a2f67fed1ab866a928c68cd3765
Gitweb:     http://git.kernel.org/tip/73090f8993a40a2f67fed1ab866a928c68cd3765
Author:     Attilio Rao <attilio.rao@citrix.com>
AuthorDate: Tue, 21 Aug 2012 21:22:37 +0100
Committer:  Thomas Gleixner <tglx@linutronix.de>
CommitDate: Wed, 12 Sep 2012 15:33:06 +0200

x86: Remove base argument from x86_init.paging.pagetable_setup_start

We either use swapper_pg_dir or the argument is unused. Preparatory
patch to simplify platform pagetable setup further.

Signed-off-by: Attilio Rao <attilio.rao@citrix.com>
Ackedb-by: <konrad.wilk@oracle.com>
Cc: <Ian.Campbell@citrix.com>
Cc: <Stefano.Stabellini@eu.citrix.com>
Cc: <xen-devel@lists.xensource.com>
Link: http://lkml.kernel.org/r/1345580561-8506-2-git-send-email-attilio.rao@citrix.com
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
---
 arch/x86/include/asm/pgtable_types.h |    6 +++---
 arch/x86/include/asm/x86_init.h      |    2 +-
 arch/x86/kernel/setup.c              |    2 +-
 arch/x86/kernel/x86_init.c           |    3 ++-
 arch/x86/mm/init_32.c                |    4 ++--
 arch/x86/xen/mmu.c                   |    2 +-
 6 files changed, 10 insertions(+), 9 deletions(-)

diff --git a/arch/x86/include/asm/pgtable_types.h b/arch/x86/include/asm/pgtable_types.h
index 013286a..e02b875 100644
--- a/arch/x86/include/asm/pgtable_types.h
+++ b/arch/x86/include/asm/pgtable_types.h
@@ -303,11 +303,11 @@ void set_pte_vaddr(unsigned long vaddr, pte_t pte);
 
 extern void native_pagetable_reserve(u64 start, u64 end);
 #ifdef CONFIG_X86_32
-extern void native_pagetable_setup_start(pgd_t *base);
+extern void native_pagetable_setup_start(void);
 extern void native_pagetable_setup_done(pgd_t *base);
 #else
-#define native_pagetable_setup_start x86_init_pgd_noop
-#define native_pagetable_setup_done  x86_init_pgd_noop
+#define native_pagetable_setup_start x86_init_pgd_start_noop
+#define native_pagetable_setup_done  x86_init_pgd_done_noop
 #endif
 
 struct seq_file;
diff --git a/arch/x86/include/asm/x86_init.h b/arch/x86/include/asm/x86_init.h
index 38155f6..782ba0c 100644
--- a/arch/x86/include/asm/x86_init.h
+++ b/arch/x86/include/asm/x86_init.h
@@ -85,7 +85,7 @@ struct x86_init_mapping {
  * @pagetable_setup_done:	platform specific post paging_init() call
  */
 struct x86_init_paging {
-	void (*pagetable_setup_start)(pgd_t *base);
+	void (*pagetable_setup_start)(void);
 	void (*pagetable_setup_done)(pgd_t *base);
 };
 
diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
index f4b9b80..90cbbe0 100644
--- a/arch/x86/kernel/setup.c
+++ b/arch/x86/kernel/setup.c
@@ -961,7 +961,7 @@ void __init setup_arch(char **cmdline_p)
 	kvmclock_init();
 #endif
 
-	x86_init.paging.pagetable_setup_start(swapper_pg_dir);
+	x86_init.paging.pagetable_setup_start();
 	paging_init();
 	x86_init.paging.pagetable_setup_done(swapper_pg_dir);
 
diff --git a/arch/x86/kernel/x86_init.c b/arch/x86/kernel/x86_init.c
index 9f3167e..3b88493 100644
--- a/arch/x86/kernel/x86_init.c
+++ b/arch/x86/kernel/x86_init.c
@@ -26,7 +26,8 @@
 
 void __cpuinit x86_init_noop(void) { }
 void __init x86_init_uint_noop(unsigned int unused) { }
-void __init x86_init_pgd_noop(pgd_t *unused) { }
+void __init x86_init_pgd_start_noop(void) { }
+void __init x86_init_pgd_done_noop(pgd_t *unused) { }
 int __init iommu_init_noop(void) { return 0; }
 void iommu_shutdown_noop(void) { }
 
diff --git a/arch/x86/mm/init_32.c b/arch/x86/mm/init_32.c
index 575d86f..c4aa1b2 100644
--- a/arch/x86/mm/init_32.c
+++ b/arch/x86/mm/init_32.c
@@ -445,10 +445,10 @@ static inline void permanent_kmaps_init(pgd_t *pgd_base)
 }
 #endif /* CONFIG_HIGHMEM */
 
-void __init native_pagetable_setup_start(pgd_t *base)
+void __init native_pagetable_setup_start(void)
 {
 	unsigned long pfn, va;
-	pgd_t *pgd;
+	pgd_t *pgd, *base = swapper_pg_dir;
 	pud_t *pud;
 	pmd_t *pmd;
 	pte_t *pte;
diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c
index 5141d80..32e66c8 100644
--- a/arch/x86/xen/mmu.c
+++ b/arch/x86/xen/mmu.c
@@ -1174,7 +1174,7 @@ static void xen_exit_mmap(struct mm_struct *mm)
 	spin_unlock(&mm->page_table_lock);
 }
 
-static void __init xen_pagetable_setup_start(pgd_t *base)
+static void __init xen_pagetable_setup_start(void)
 {
 }
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 12 13:47:23 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Sep 2012 13:47:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TBnHX-0003Hj-K5; Wed, 12 Sep 2012 13:47:07 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <tipbot@zytor.com>) id 1TBnHW-0003HY-Rr
	for xen-devel@lists.xensource.com; Wed, 12 Sep 2012 13:47:07 +0000
Received: from [85.158.138.51:59473] by server-4.bemta-3.messagelabs.com id
	7F/BF-24831-95290505; Wed, 12 Sep 2012 13:47:05 +0000
X-Env-Sender: tipbot@zytor.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1347457623!21285147!1
X-Originating-IP: [198.137.202.10]
X-SpamReason: No, hits=1.0 required=7.0 tests=X_MAILER_SPAM
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16218 invoked from network); 12 Sep 2012 13:47:05 -0000
Received: from terminus.zytor.com (HELO terminus.zytor.com) (198.137.202.10)
	by server-7.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 12 Sep 2012 13:47:05 -0000
Received: from terminus.zytor.com (localhost [127.0.0.1])
	by terminus.zytor.com (8.14.5/8.14.5) with ESMTP id q8CDkcgx020255
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 12 Sep 2012 06:46:43 -0700
Received: (from tipbot@localhost)
	by terminus.zytor.com (8.14.5/8.14.5/Submit) id q8CDkc5Q020252;
	Wed, 12 Sep 2012 06:46:38 -0700
Date: Wed, 12 Sep 2012 06:46:38 -0700
X-Authentication-Warning: terminus.zytor.com: tipbot set sender to
	tipbot@zytor.com using -f
From: tip-bot for Attilio Rao <attilio.rao@citrix.com>
Message-ID: <tip-73090f8993a40a2f67fed1ab866a928c68cd3765@git.kernel.org>
In-Reply-To: <1345580561-8506-2-git-send-email-attilio.rao@citrix.com>
References: <1345580561-8506-2-git-send-email-attilio.rao@citrix.com>
To: linux-tip-commits@vger.kernel.org
Git-Commit-ID: 73090f8993a40a2f67fed1ab866a928c68cd3765
X-Mailer: tip-git-log-daemon
Robot-ID: <tip-bot.git.kernel.org>
Robot-Unsubscribe: Contact <mailto:hpa@kernel.org>
	to get blacklisted from these emails
MIME-Version: 1.0
Content-Disposition: inline
Precedence: bulk
X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00,
	T_DATE_IN_FUTURE_96_Q autolearn=ham version=3.3.2
X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on terminus.zytor.com
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.6
	(terminus.zytor.com [127.0.0.1]);
	Wed, 12 Sep 2012 06:46:44 -0700 (PDT)
Cc: xen-devel@lists.xensource.com, Ian.Campbell@citrix.com,
	konrad.wilk@oracle.com, Stefano.Stabellini@eu.citrix.com,
	linux-kernel@vger.kernel.org, hpa@zytor.com,
	attilio.rao@citrix.com, tglx@linutronix.de, mingo@kernel.org
Subject: [Xen-devel] [tip:x86/platform] x86: Remove base argument from
 x86_init.paging. pagetable_setup_start
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Reply-To: mingo@kernel.org, hpa@zytor.com, linux-kernel@vger.kernel.org,
	konrad.wilk@oracle.com, Stefano.Stabellini@eu.citrix.com,
	Ian.Campbell@citrix.com, tglx@linutronix.de,
	attilio.rao@citrix.com, xen-devel@lists.xensource.com
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Commit-ID:  73090f8993a40a2f67fed1ab866a928c68cd3765
Gitweb:     http://git.kernel.org/tip/73090f8993a40a2f67fed1ab866a928c68cd3765
Author:     Attilio Rao <attilio.rao@citrix.com>
AuthorDate: Tue, 21 Aug 2012 21:22:37 +0100
Committer:  Thomas Gleixner <tglx@linutronix.de>
CommitDate: Wed, 12 Sep 2012 15:33:06 +0200

x86: Remove base argument from x86_init.paging.pagetable_setup_start

We either use swapper_pg_dir or the argument is unused. Preparatory
patch to simplify platform pagetable setup further.

Signed-off-by: Attilio Rao <attilio.rao@citrix.com>
Ackedb-by: <konrad.wilk@oracle.com>
Cc: <Ian.Campbell@citrix.com>
Cc: <Stefano.Stabellini@eu.citrix.com>
Cc: <xen-devel@lists.xensource.com>
Link: http://lkml.kernel.org/r/1345580561-8506-2-git-send-email-attilio.rao@citrix.com
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
---
 arch/x86/include/asm/pgtable_types.h |    6 +++---
 arch/x86/include/asm/x86_init.h      |    2 +-
 arch/x86/kernel/setup.c              |    2 +-
 arch/x86/kernel/x86_init.c           |    3 ++-
 arch/x86/mm/init_32.c                |    4 ++--
 arch/x86/xen/mmu.c                   |    2 +-
 6 files changed, 10 insertions(+), 9 deletions(-)

diff --git a/arch/x86/include/asm/pgtable_types.h b/arch/x86/include/asm/pgtable_types.h
index 013286a..e02b875 100644
--- a/arch/x86/include/asm/pgtable_types.h
+++ b/arch/x86/include/asm/pgtable_types.h
@@ -303,11 +303,11 @@ void set_pte_vaddr(unsigned long vaddr, pte_t pte);
 
 extern void native_pagetable_reserve(u64 start, u64 end);
 #ifdef CONFIG_X86_32
-extern void native_pagetable_setup_start(pgd_t *base);
+extern void native_pagetable_setup_start(void);
 extern void native_pagetable_setup_done(pgd_t *base);
 #else
-#define native_pagetable_setup_start x86_init_pgd_noop
-#define native_pagetable_setup_done  x86_init_pgd_noop
+#define native_pagetable_setup_start x86_init_pgd_start_noop
+#define native_pagetable_setup_done  x86_init_pgd_done_noop
 #endif
 
 struct seq_file;
diff --git a/arch/x86/include/asm/x86_init.h b/arch/x86/include/asm/x86_init.h
index 38155f6..782ba0c 100644
--- a/arch/x86/include/asm/x86_init.h
+++ b/arch/x86/include/asm/x86_init.h
@@ -85,7 +85,7 @@ struct x86_init_mapping {
  * @pagetable_setup_done:	platform specific post paging_init() call
  */
 struct x86_init_paging {
-	void (*pagetable_setup_start)(pgd_t *base);
+	void (*pagetable_setup_start)(void);
 	void (*pagetable_setup_done)(pgd_t *base);
 };
 
diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
index f4b9b80..90cbbe0 100644
--- a/arch/x86/kernel/setup.c
+++ b/arch/x86/kernel/setup.c
@@ -961,7 +961,7 @@ void __init setup_arch(char **cmdline_p)
 	kvmclock_init();
 #endif
 
-	x86_init.paging.pagetable_setup_start(swapper_pg_dir);
+	x86_init.paging.pagetable_setup_start();
 	paging_init();
 	x86_init.paging.pagetable_setup_done(swapper_pg_dir);
 
diff --git a/arch/x86/kernel/x86_init.c b/arch/x86/kernel/x86_init.c
index 9f3167e..3b88493 100644
--- a/arch/x86/kernel/x86_init.c
+++ b/arch/x86/kernel/x86_init.c
@@ -26,7 +26,8 @@
 
 void __cpuinit x86_init_noop(void) { }
 void __init x86_init_uint_noop(unsigned int unused) { }
-void __init x86_init_pgd_noop(pgd_t *unused) { }
+void __init x86_init_pgd_start_noop(void) { }
+void __init x86_init_pgd_done_noop(pgd_t *unused) { }
 int __init iommu_init_noop(void) { return 0; }
 void iommu_shutdown_noop(void) { }
 
diff --git a/arch/x86/mm/init_32.c b/arch/x86/mm/init_32.c
index 575d86f..c4aa1b2 100644
--- a/arch/x86/mm/init_32.c
+++ b/arch/x86/mm/init_32.c
@@ -445,10 +445,10 @@ static inline void permanent_kmaps_init(pgd_t *pgd_base)
 }
 #endif /* CONFIG_HIGHMEM */
 
-void __init native_pagetable_setup_start(pgd_t *base)
+void __init native_pagetable_setup_start(void)
 {
 	unsigned long pfn, va;
-	pgd_t *pgd;
+	pgd_t *pgd, *base = swapper_pg_dir;
 	pud_t *pud;
 	pmd_t *pmd;
 	pte_t *pte;
diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c
index 5141d80..32e66c8 100644
--- a/arch/x86/xen/mmu.c
+++ b/arch/x86/xen/mmu.c
@@ -1174,7 +1174,7 @@ static void xen_exit_mmap(struct mm_struct *mm)
 	spin_unlock(&mm->page_table_lock);
 }
 
-static void __init xen_pagetable_setup_start(pgd_t *base)
+static void __init xen_pagetable_setup_start(void)
 {
 }
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 12 13:48:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Sep 2012 13:48:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TBnIO-0003Ok-9F; Wed, 12 Sep 2012 13:48:00 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <tipbot@zytor.com>) id 1TBnIM-0003OQ-Ms
	for xen-devel@lists.xensource.com; Wed, 12 Sep 2012 13:47:58 +0000
Received: from [85.158.143.35:3509] by server-2.bemta-4.messagelabs.com id
	98/4B-21239-E8290505; Wed, 12 Sep 2012 13:47:58 +0000
X-Env-Sender: tipbot@zytor.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1347457675!13345298!1
X-Originating-IP: [198.137.202.10]
X-SpamReason: No, hits=1.5 required=7.0 tests=BODY_RANDOM_LONG, X_MAILER_SPAM
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12718 invoked from network); 12 Sep 2012 13:47:56 -0000
Received: from terminus.zytor.com (HELO terminus.zytor.com) (198.137.202.10)
	by server-3.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 12 Sep 2012 13:47:56 -0000
Received: from terminus.zytor.com (localhost [127.0.0.1])
	by terminus.zytor.com (8.14.5/8.14.5) with ESMTP id q8CDlYpt020366
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 12 Sep 2012 06:47:39 -0700
Received: (from tipbot@localhost)
	by terminus.zytor.com (8.14.5/8.14.5/Submit) id q8CDlYjY020363;
	Wed, 12 Sep 2012 06:47:34 -0700
Date: Wed, 12 Sep 2012 06:47:34 -0700
X-Authentication-Warning: terminus.zytor.com: tipbot set sender to
	tipbot@zytor.com using -f
From: tip-bot for Attilio Rao <attilio.rao@citrix.com>
Message-ID: <tip-7737b215ad0f94d20a87d98315da9f6cadaf35c9@git.kernel.org>
In-Reply-To: <1345580561-8506-3-git-send-email-attilio.rao@citrix.com>
References: <1345580561-8506-3-git-send-email-attilio.rao@citrix.com>
To: linux-tip-commits@vger.kernel.org
Git-Commit-ID: 7737b215ad0f94d20a87d98315da9f6cadaf35c9
X-Mailer: tip-git-log-daemon
Robot-ID: <tip-bot.git.kernel.org>
Robot-Unsubscribe: Contact <mailto:hpa@kernel.org>
	to get blacklisted from these emails
MIME-Version: 1.0
Content-Disposition: inline
Precedence: bulk
X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00,
	T_DATE_IN_FUTURE_96_Q autolearn=ham version=3.3.2
X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on terminus.zytor.com
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.6
	(terminus.zytor.com [127.0.0.1]);
	Wed, 12 Sep 2012 06:47:39 -0700 (PDT)
Cc: xen-devel@lists.xensource.com, Ian.Campbell@citrix.com,
	konrad.wilk@oracle.com, Stefano.Stabellini@eu.citrix.com,
	linux-kernel@vger.kernel.org, hpa@zytor.com,
	attilio.rao@citrix.com, tglx@linutronix.de, mingo@kernel.org
Subject: [Xen-devel] [tip:x86/platform] x86: Rename pagetable_setup_start()
 to pagetable_init()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Reply-To: mingo@kernel.org, hpa@zytor.com, linux-kernel@vger.kernel.org,
	konrad.wilk@oracle.com, Stefano.Stabellini@eu.citrix.com,
	Ian.Campbell@citrix.com, tglx@linutronix.de,
	attilio.rao@citrix.com, xen-devel@lists.xensource.com
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Commit-ID:  7737b215ad0f94d20a87d98315da9f6cadaf35c9
Gitweb:     http://git.kernel.org/tip/7737b215ad0f94d20a87d98315da9f6cadaf35c9
Author:     Attilio Rao <attilio.rao@citrix.com>
AuthorDate: Tue, 21 Aug 2012 21:22:38 +0100
Committer:  Thomas Gleixner <tglx@linutronix.de>
CommitDate: Wed, 12 Sep 2012 15:33:06 +0200

x86: Rename pagetable_setup_start() to pagetable_init()

In preparation for unifying the pagetable_setup_start() and
pagetable_setup_done() setup functions, rename appropriately all the
infrastructure related to pagetable_setup_start().

Signed-off-by: Attilio Rao <attilio.rao@citrix.com>
Ackedd-by: <konrad.wilk@oracle.com>
Cc: <Ian.Campbell@citrix.com>
Cc: <Stefano.Stabellini@eu.citrix.com>
Cc: <xen-devel@lists.xensource.com>
Link: http://lkml.kernel.org/r/1345580561-8506-3-git-send-email-attilio.rao@citrix.com
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
---
 arch/x86/include/asm/pgtable_types.h |    4 ++--
 arch/x86/include/asm/x86_init.h      |    4 ++--
 arch/x86/kernel/setup.c              |    2 +-
 arch/x86/kernel/x86_init.c           |    4 ++--
 arch/x86/mm/init_32.c                |    4 ++--
 arch/x86/xen/mmu.c                   |    4 ++--
 6 files changed, 11 insertions(+), 11 deletions(-)

diff --git a/arch/x86/include/asm/pgtable_types.h b/arch/x86/include/asm/pgtable_types.h
index e02b875..0c01e07 100644
--- a/arch/x86/include/asm/pgtable_types.h
+++ b/arch/x86/include/asm/pgtable_types.h
@@ -303,10 +303,10 @@ void set_pte_vaddr(unsigned long vaddr, pte_t pte);
 
 extern void native_pagetable_reserve(u64 start, u64 end);
 #ifdef CONFIG_X86_32
-extern void native_pagetable_setup_start(void);
+extern void native_pagetable_init(void);
 extern void native_pagetable_setup_done(pgd_t *base);
 #else
-#define native_pagetable_setup_start x86_init_pgd_start_noop
+#define native_pagetable_init        x86_init_pgd_init_noop
 #define native_pagetable_setup_done  x86_init_pgd_done_noop
 #endif
 
diff --git a/arch/x86/include/asm/x86_init.h b/arch/x86/include/asm/x86_init.h
index 782ba0c..24084b2 100644
--- a/arch/x86/include/asm/x86_init.h
+++ b/arch/x86/include/asm/x86_init.h
@@ -81,11 +81,11 @@ struct x86_init_mapping {
 
 /**
  * struct x86_init_paging - platform specific paging functions
- * @pagetable_setup_start:	platform specific pre paging_init() call
+ * @pagetable_init:		platform specific paging initialization call
  * @pagetable_setup_done:	platform specific post paging_init() call
  */
 struct x86_init_paging {
-	void (*pagetable_setup_start)(void);
+	void (*pagetable_init)(void);
 	void (*pagetable_setup_done)(pgd_t *base);
 };
 
diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
index 90cbbe0..61b7d98 100644
--- a/arch/x86/kernel/setup.c
+++ b/arch/x86/kernel/setup.c
@@ -961,7 +961,7 @@ void __init setup_arch(char **cmdline_p)
 	kvmclock_init();
 #endif
 
-	x86_init.paging.pagetable_setup_start();
+	x86_init.paging.pagetable_init();
 	paging_init();
 	x86_init.paging.pagetable_setup_done(swapper_pg_dir);
 
diff --git a/arch/x86/kernel/x86_init.c b/arch/x86/kernel/x86_init.c
index 3b88493..0e1e950 100644
--- a/arch/x86/kernel/x86_init.c
+++ b/arch/x86/kernel/x86_init.c
@@ -26,7 +26,7 @@
 
 void __cpuinit x86_init_noop(void) { }
 void __init x86_init_uint_noop(unsigned int unused) { }
-void __init x86_init_pgd_start_noop(void) { }
+void __init x86_init_pgd_init_noop(void) { }
 void __init x86_init_pgd_done_noop(pgd_t *unused) { }
 int __init iommu_init_noop(void) { return 0; }
 void iommu_shutdown_noop(void) { }
@@ -69,7 +69,7 @@ struct x86_init_ops x86_init __initdata = {
 	},
 
 	.paging = {
-		.pagetable_setup_start	= native_pagetable_setup_start,
+		.pagetable_init		= native_pagetable_init,
 		.pagetable_setup_done	= native_pagetable_setup_done,
 	},
 
diff --git a/arch/x86/mm/init_32.c b/arch/x86/mm/init_32.c
index c4aa1b2..0e38e0e 100644
--- a/arch/x86/mm/init_32.c
+++ b/arch/x86/mm/init_32.c
@@ -445,7 +445,7 @@ static inline void permanent_kmaps_init(pgd_t *pgd_base)
 }
 #endif /* CONFIG_HIGHMEM */
 
-void __init native_pagetable_setup_start(void)
+void __init native_pagetable_init(void)
 {
 	unsigned long pfn, va;
 	pgd_t *pgd, *base = swapper_pg_dir;
@@ -493,7 +493,7 @@ void __init native_pagetable_setup_done(pgd_t *base)
  * If we're booting paravirtualized under a hypervisor, then there are
  * more options: we may already be running PAE, and the pagetable may
  * or may not be based in swapper_pg_dir.  In any case,
- * paravirt_pagetable_setup_start() will set up swapper_pg_dir
+ * paravirt_pagetable_init() will set up swapper_pg_dir
  * appropriately for the rest of the initialization to work.
  *
  * In general, pagetable_init() assumes that the pagetable may already
diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c
index 32e66c8..624efbe 100644
--- a/arch/x86/xen/mmu.c
+++ b/arch/x86/xen/mmu.c
@@ -1174,7 +1174,7 @@ static void xen_exit_mmap(struct mm_struct *mm)
 	spin_unlock(&mm->page_table_lock);
 }
 
-static void __init xen_pagetable_setup_start(void)
+static void __init xen_pagetable_init(void)
 {
 }
 
@@ -2068,7 +2068,7 @@ static const struct pv_mmu_ops xen_mmu_ops __initconst = {
 void __init xen_init_mmu_ops(void)
 {
 	x86_init.mapping.pagetable_reserve = xen_mapping_pagetable_reserve;
-	x86_init.paging.pagetable_setup_start = xen_pagetable_setup_start;
+	x86_init.paging.pagetable_init = xen_pagetable_init;
 	x86_init.paging.pagetable_setup_done = xen_pagetable_setup_done;
 	pv_mmu_ops = xen_mmu_ops;
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 12 13:48:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Sep 2012 13:48:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TBnIO-0003Ok-9F; Wed, 12 Sep 2012 13:48:00 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <tipbot@zytor.com>) id 1TBnIM-0003OQ-Ms
	for xen-devel@lists.xensource.com; Wed, 12 Sep 2012 13:47:58 +0000
Received: from [85.158.143.35:3509] by server-2.bemta-4.messagelabs.com id
	98/4B-21239-E8290505; Wed, 12 Sep 2012 13:47:58 +0000
X-Env-Sender: tipbot@zytor.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1347457675!13345298!1
X-Originating-IP: [198.137.202.10]
X-SpamReason: No, hits=1.5 required=7.0 tests=BODY_RANDOM_LONG, X_MAILER_SPAM
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12718 invoked from network); 12 Sep 2012 13:47:56 -0000
Received: from terminus.zytor.com (HELO terminus.zytor.com) (198.137.202.10)
	by server-3.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 12 Sep 2012 13:47:56 -0000
Received: from terminus.zytor.com (localhost [127.0.0.1])
	by terminus.zytor.com (8.14.5/8.14.5) with ESMTP id q8CDlYpt020366
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 12 Sep 2012 06:47:39 -0700
Received: (from tipbot@localhost)
	by terminus.zytor.com (8.14.5/8.14.5/Submit) id q8CDlYjY020363;
	Wed, 12 Sep 2012 06:47:34 -0700
Date: Wed, 12 Sep 2012 06:47:34 -0700
X-Authentication-Warning: terminus.zytor.com: tipbot set sender to
	tipbot@zytor.com using -f
From: tip-bot for Attilio Rao <attilio.rao@citrix.com>
Message-ID: <tip-7737b215ad0f94d20a87d98315da9f6cadaf35c9@git.kernel.org>
In-Reply-To: <1345580561-8506-3-git-send-email-attilio.rao@citrix.com>
References: <1345580561-8506-3-git-send-email-attilio.rao@citrix.com>
To: linux-tip-commits@vger.kernel.org
Git-Commit-ID: 7737b215ad0f94d20a87d98315da9f6cadaf35c9
X-Mailer: tip-git-log-daemon
Robot-ID: <tip-bot.git.kernel.org>
Robot-Unsubscribe: Contact <mailto:hpa@kernel.org>
	to get blacklisted from these emails
MIME-Version: 1.0
Content-Disposition: inline
Precedence: bulk
X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00,
	T_DATE_IN_FUTURE_96_Q autolearn=ham version=3.3.2
X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on terminus.zytor.com
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.6
	(terminus.zytor.com [127.0.0.1]);
	Wed, 12 Sep 2012 06:47:39 -0700 (PDT)
Cc: xen-devel@lists.xensource.com, Ian.Campbell@citrix.com,
	konrad.wilk@oracle.com, Stefano.Stabellini@eu.citrix.com,
	linux-kernel@vger.kernel.org, hpa@zytor.com,
	attilio.rao@citrix.com, tglx@linutronix.de, mingo@kernel.org
Subject: [Xen-devel] [tip:x86/platform] x86: Rename pagetable_setup_start()
 to pagetable_init()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Reply-To: mingo@kernel.org, hpa@zytor.com, linux-kernel@vger.kernel.org,
	konrad.wilk@oracle.com, Stefano.Stabellini@eu.citrix.com,
	Ian.Campbell@citrix.com, tglx@linutronix.de,
	attilio.rao@citrix.com, xen-devel@lists.xensource.com
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Commit-ID:  7737b215ad0f94d20a87d98315da9f6cadaf35c9
Gitweb:     http://git.kernel.org/tip/7737b215ad0f94d20a87d98315da9f6cadaf35c9
Author:     Attilio Rao <attilio.rao@citrix.com>
AuthorDate: Tue, 21 Aug 2012 21:22:38 +0100
Committer:  Thomas Gleixner <tglx@linutronix.de>
CommitDate: Wed, 12 Sep 2012 15:33:06 +0200

x86: Rename pagetable_setup_start() to pagetable_init()

In preparation for unifying the pagetable_setup_start() and
pagetable_setup_done() setup functions, rename appropriately all the
infrastructure related to pagetable_setup_start().

Signed-off-by: Attilio Rao <attilio.rao@citrix.com>
Ackedd-by: <konrad.wilk@oracle.com>
Cc: <Ian.Campbell@citrix.com>
Cc: <Stefano.Stabellini@eu.citrix.com>
Cc: <xen-devel@lists.xensource.com>
Link: http://lkml.kernel.org/r/1345580561-8506-3-git-send-email-attilio.rao@citrix.com
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
---
 arch/x86/include/asm/pgtable_types.h |    4 ++--
 arch/x86/include/asm/x86_init.h      |    4 ++--
 arch/x86/kernel/setup.c              |    2 +-
 arch/x86/kernel/x86_init.c           |    4 ++--
 arch/x86/mm/init_32.c                |    4 ++--
 arch/x86/xen/mmu.c                   |    4 ++--
 6 files changed, 11 insertions(+), 11 deletions(-)

diff --git a/arch/x86/include/asm/pgtable_types.h b/arch/x86/include/asm/pgtable_types.h
index e02b875..0c01e07 100644
--- a/arch/x86/include/asm/pgtable_types.h
+++ b/arch/x86/include/asm/pgtable_types.h
@@ -303,10 +303,10 @@ void set_pte_vaddr(unsigned long vaddr, pte_t pte);
 
 extern void native_pagetable_reserve(u64 start, u64 end);
 #ifdef CONFIG_X86_32
-extern void native_pagetable_setup_start(void);
+extern void native_pagetable_init(void);
 extern void native_pagetable_setup_done(pgd_t *base);
 #else
-#define native_pagetable_setup_start x86_init_pgd_start_noop
+#define native_pagetable_init        x86_init_pgd_init_noop
 #define native_pagetable_setup_done  x86_init_pgd_done_noop
 #endif
 
diff --git a/arch/x86/include/asm/x86_init.h b/arch/x86/include/asm/x86_init.h
index 782ba0c..24084b2 100644
--- a/arch/x86/include/asm/x86_init.h
+++ b/arch/x86/include/asm/x86_init.h
@@ -81,11 +81,11 @@ struct x86_init_mapping {
 
 /**
  * struct x86_init_paging - platform specific paging functions
- * @pagetable_setup_start:	platform specific pre paging_init() call
+ * @pagetable_init:		platform specific paging initialization call
  * @pagetable_setup_done:	platform specific post paging_init() call
  */
 struct x86_init_paging {
-	void (*pagetable_setup_start)(void);
+	void (*pagetable_init)(void);
 	void (*pagetable_setup_done)(pgd_t *base);
 };
 
diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
index 90cbbe0..61b7d98 100644
--- a/arch/x86/kernel/setup.c
+++ b/arch/x86/kernel/setup.c
@@ -961,7 +961,7 @@ void __init setup_arch(char **cmdline_p)
 	kvmclock_init();
 #endif
 
-	x86_init.paging.pagetable_setup_start();
+	x86_init.paging.pagetable_init();
 	paging_init();
 	x86_init.paging.pagetable_setup_done(swapper_pg_dir);
 
diff --git a/arch/x86/kernel/x86_init.c b/arch/x86/kernel/x86_init.c
index 3b88493..0e1e950 100644
--- a/arch/x86/kernel/x86_init.c
+++ b/arch/x86/kernel/x86_init.c
@@ -26,7 +26,7 @@
 
 void __cpuinit x86_init_noop(void) { }
 void __init x86_init_uint_noop(unsigned int unused) { }
-void __init x86_init_pgd_start_noop(void) { }
+void __init x86_init_pgd_init_noop(void) { }
 void __init x86_init_pgd_done_noop(pgd_t *unused) { }
 int __init iommu_init_noop(void) { return 0; }
 void iommu_shutdown_noop(void) { }
@@ -69,7 +69,7 @@ struct x86_init_ops x86_init __initdata = {
 	},
 
 	.paging = {
-		.pagetable_setup_start	= native_pagetable_setup_start,
+		.pagetable_init		= native_pagetable_init,
 		.pagetable_setup_done	= native_pagetable_setup_done,
 	},
 
diff --git a/arch/x86/mm/init_32.c b/arch/x86/mm/init_32.c
index c4aa1b2..0e38e0e 100644
--- a/arch/x86/mm/init_32.c
+++ b/arch/x86/mm/init_32.c
@@ -445,7 +445,7 @@ static inline void permanent_kmaps_init(pgd_t *pgd_base)
 }
 #endif /* CONFIG_HIGHMEM */
 
-void __init native_pagetable_setup_start(void)
+void __init native_pagetable_init(void)
 {
 	unsigned long pfn, va;
 	pgd_t *pgd, *base = swapper_pg_dir;
@@ -493,7 +493,7 @@ void __init native_pagetable_setup_done(pgd_t *base)
  * If we're booting paravirtualized under a hypervisor, then there are
  * more options: we may already be running PAE, and the pagetable may
  * or may not be based in swapper_pg_dir.  In any case,
- * paravirt_pagetable_setup_start() will set up swapper_pg_dir
+ * paravirt_pagetable_init() will set up swapper_pg_dir
  * appropriately for the rest of the initialization to work.
  *
  * In general, pagetable_init() assumes that the pagetable may already
diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c
index 32e66c8..624efbe 100644
--- a/arch/x86/xen/mmu.c
+++ b/arch/x86/xen/mmu.c
@@ -1174,7 +1174,7 @@ static void xen_exit_mmap(struct mm_struct *mm)
 	spin_unlock(&mm->page_table_lock);
 }
 
-static void __init xen_pagetable_setup_start(void)
+static void __init xen_pagetable_init(void)
 {
 }
 
@@ -2068,7 +2068,7 @@ static const struct pv_mmu_ops xen_mmu_ops __initconst = {
 void __init xen_init_mmu_ops(void)
 {
 	x86_init.mapping.pagetable_reserve = xen_mapping_pagetable_reserve;
-	x86_init.paging.pagetable_setup_start = xen_pagetable_setup_start;
+	x86_init.paging.pagetable_init = xen_pagetable_init;
 	x86_init.paging.pagetable_setup_done = xen_pagetable_setup_done;
 	pv_mmu_ops = xen_mmu_ops;
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 12 13:49:09 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Sep 2012 13: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 1TBnJH-0003Xb-O1; Wed, 12 Sep 2012 13:48:55 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <tipbot@zytor.com>) id 1TBnJF-0003WY-TP
	for xen-devel@lists.xensource.com; Wed, 12 Sep 2012 13:48:54 +0000
X-Env-Sender: tipbot@zytor.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1347457725!7326993!1
X-Originating-IP: [198.137.202.10]
X-SpamReason: No, hits=1.0 required=7.0 tests=X_MAILER_SPAM
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11003 invoked from network); 12 Sep 2012 13:48:47 -0000
Received: from terminus.zytor.com (HELO terminus.zytor.com) (198.137.202.10)
	by server-5.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 12 Sep 2012 13:48:47 -0000
Received: from terminus.zytor.com (localhost [127.0.0.1])
	by terminus.zytor.com (8.14.5/8.14.5) with ESMTP id q8CDmT9S020561
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 12 Sep 2012 06:48:34 -0700
Received: (from tipbot@localhost)
	by terminus.zytor.com (8.14.5/8.14.5/Submit) id q8CDmTbf020558;
	Wed, 12 Sep 2012 06:48:29 -0700
Date: Wed, 12 Sep 2012 06:48:29 -0700
X-Authentication-Warning: terminus.zytor.com: tipbot set sender to
	tipbot@zytor.com using -f
From: tip-bot for Attilio Rao <attilio.rao@citrix.com>
Message-ID: <tip-843b8ed2ec598aae5e3516b21957ede62a070e36@git.kernel.org>
In-Reply-To: <1345580561-8506-4-git-send-email-attilio.rao@citrix.com>
References: <1345580561-8506-4-git-send-email-attilio.rao@citrix.com>
To: linux-tip-commits@vger.kernel.org
Git-Commit-ID: 843b8ed2ec598aae5e3516b21957ede62a070e36
X-Mailer: tip-git-log-daemon
Robot-ID: <tip-bot.git.kernel.org>
Robot-Unsubscribe: Contact <mailto:hpa@kernel.org>
	to get blacklisted from these emails
MIME-Version: 1.0
Content-Disposition: inline
Precedence: bulk
X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00,
	T_DATE_IN_FUTURE_96_Q autolearn=ham version=3.3.2
X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on terminus.zytor.com
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.6
	(terminus.zytor.com [127.0.0.1]);
	Wed, 12 Sep 2012 06:48:35 -0700 (PDT)
Cc: xen-devel@lists.xensource.com, Ian.Campbell@citrix.com,
	konrad.wilk@oracle.com, Stefano.Stabellini@eu.citrix.com,
	linux-kernel@vger.kernel.org, hpa@zytor.com,
	attilio.rao@citrix.com, tglx@linutronix.de, mingo@kernel.org
Subject: [Xen-devel] [tip:x86/platform] x86: Move paging_init() call to
 x86_init.paging .pagetable_init()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Reply-To: mingo@kernel.org, hpa@zytor.com, linux-kernel@vger.kernel.org,
	konrad.wilk@oracle.com, Stefano.Stabellini@eu.citrix.com,
	Ian.Campbell@citrix.com, tglx@linutronix.de,
	attilio.rao@citrix.com, xen-devel@lists.xensource.com
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Commit-ID:  843b8ed2ec598aae5e3516b21957ede62a070e36
Gitweb:     http://git.kernel.org/tip/843b8ed2ec598aae5e3516b21957ede62a070e36
Author:     Attilio Rao <attilio.rao@citrix.com>
AuthorDate: Tue, 21 Aug 2012 21:22:39 +0100
Committer:  Thomas Gleixner <tglx@linutronix.de>
CommitDate: Wed, 12 Sep 2012 15:33:06 +0200

x86: Move paging_init() call to x86_init.paging.pagetable_init()

Move the paging_init() call to the platform specific pagetable_init()
function, so we can get rid of the extra pagetable_setup_done()
function pointer.

Signed-off-by: Attilio Rao <attilio.rao@citrix.com>
Acked-by: <konrad.wilk@oracle.com>
Cc: <Ian.Campbell@citrix.com>
Cc: <Stefano.Stabellini@eu.citrix.com>
Cc: <xen-devel@lists.xensource.com>
Link: http://lkml.kernel.org/r/1345580561-8506-4-git-send-email-attilio.rao@citrix.com
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
---
 arch/x86/include/asm/pgtable_types.h |    2 +-
 arch/x86/kernel/setup.c              |    1 -
 arch/x86/kernel/x86_init.c           |    1 -
 arch/x86/mm/init_32.c                |    1 +
 arch/x86/xen/mmu.c                   |    1 +
 5 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/x86/include/asm/pgtable_types.h b/arch/x86/include/asm/pgtable_types.h
index 0c01e07..c93cb8e 100644
--- a/arch/x86/include/asm/pgtable_types.h
+++ b/arch/x86/include/asm/pgtable_types.h
@@ -306,7 +306,7 @@ extern void native_pagetable_reserve(u64 start, u64 end);
 extern void native_pagetable_init(void);
 extern void native_pagetable_setup_done(pgd_t *base);
 #else
-#define native_pagetable_init        x86_init_pgd_init_noop
+#define native_pagetable_init        paging_init
 #define native_pagetable_setup_done  x86_init_pgd_done_noop
 #endif
 
diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
index 61b7d98..315fd24 100644
--- a/arch/x86/kernel/setup.c
+++ b/arch/x86/kernel/setup.c
@@ -962,7 +962,6 @@ void __init setup_arch(char **cmdline_p)
 #endif
 
 	x86_init.paging.pagetable_init();
-	paging_init();
 	x86_init.paging.pagetable_setup_done(swapper_pg_dir);
 
 	if (boot_cpu_data.cpuid_level >= 0) {
diff --git a/arch/x86/kernel/x86_init.c b/arch/x86/kernel/x86_init.c
index 0e1e950..5f2478f 100644
--- a/arch/x86/kernel/x86_init.c
+++ b/arch/x86/kernel/x86_init.c
@@ -26,7 +26,6 @@
 
 void __cpuinit x86_init_noop(void) { }
 void __init x86_init_uint_noop(unsigned int unused) { }
-void __init x86_init_pgd_init_noop(void) { }
 void __init x86_init_pgd_done_noop(pgd_t *unused) { }
 int __init iommu_init_noop(void) { return 0; }
 void iommu_shutdown_noop(void) { }
diff --git a/arch/x86/mm/init_32.c b/arch/x86/mm/init_32.c
index 0e38e0e..e35b4b1 100644
--- a/arch/x86/mm/init_32.c
+++ b/arch/x86/mm/init_32.c
@@ -475,6 +475,7 @@ void __init native_pagetable_init(void)
 		pte_clear(NULL, va, pte);
 	}
 	paravirt_alloc_pmd(&init_mm, __pa(base) >> PAGE_SHIFT);
+	paging_init();
 }
 
 void __init native_pagetable_setup_done(pgd_t *base)
diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c
index 624efbe..c2ff7ea 100644
--- a/arch/x86/xen/mmu.c
+++ b/arch/x86/xen/mmu.c
@@ -1176,6 +1176,7 @@ static void xen_exit_mmap(struct mm_struct *mm)
 
 static void __init xen_pagetable_init(void)
 {
+	paging_init();
 }
 
 static __init void xen_mapping_pagetable_reserve(u64 start, u64 end)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 12 13:49:09 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Sep 2012 13: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 1TBnJH-0003Xb-O1; Wed, 12 Sep 2012 13:48:55 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <tipbot@zytor.com>) id 1TBnJF-0003WY-TP
	for xen-devel@lists.xensource.com; Wed, 12 Sep 2012 13:48:54 +0000
X-Env-Sender: tipbot@zytor.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1347457725!7326993!1
X-Originating-IP: [198.137.202.10]
X-SpamReason: No, hits=1.0 required=7.0 tests=X_MAILER_SPAM
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11003 invoked from network); 12 Sep 2012 13:48:47 -0000
Received: from terminus.zytor.com (HELO terminus.zytor.com) (198.137.202.10)
	by server-5.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 12 Sep 2012 13:48:47 -0000
Received: from terminus.zytor.com (localhost [127.0.0.1])
	by terminus.zytor.com (8.14.5/8.14.5) with ESMTP id q8CDmT9S020561
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 12 Sep 2012 06:48:34 -0700
Received: (from tipbot@localhost)
	by terminus.zytor.com (8.14.5/8.14.5/Submit) id q8CDmTbf020558;
	Wed, 12 Sep 2012 06:48:29 -0700
Date: Wed, 12 Sep 2012 06:48:29 -0700
X-Authentication-Warning: terminus.zytor.com: tipbot set sender to
	tipbot@zytor.com using -f
From: tip-bot for Attilio Rao <attilio.rao@citrix.com>
Message-ID: <tip-843b8ed2ec598aae5e3516b21957ede62a070e36@git.kernel.org>
In-Reply-To: <1345580561-8506-4-git-send-email-attilio.rao@citrix.com>
References: <1345580561-8506-4-git-send-email-attilio.rao@citrix.com>
To: linux-tip-commits@vger.kernel.org
Git-Commit-ID: 843b8ed2ec598aae5e3516b21957ede62a070e36
X-Mailer: tip-git-log-daemon
Robot-ID: <tip-bot.git.kernel.org>
Robot-Unsubscribe: Contact <mailto:hpa@kernel.org>
	to get blacklisted from these emails
MIME-Version: 1.0
Content-Disposition: inline
Precedence: bulk
X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00,
	T_DATE_IN_FUTURE_96_Q autolearn=ham version=3.3.2
X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on terminus.zytor.com
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.6
	(terminus.zytor.com [127.0.0.1]);
	Wed, 12 Sep 2012 06:48:35 -0700 (PDT)
Cc: xen-devel@lists.xensource.com, Ian.Campbell@citrix.com,
	konrad.wilk@oracle.com, Stefano.Stabellini@eu.citrix.com,
	linux-kernel@vger.kernel.org, hpa@zytor.com,
	attilio.rao@citrix.com, tglx@linutronix.de, mingo@kernel.org
Subject: [Xen-devel] [tip:x86/platform] x86: Move paging_init() call to
 x86_init.paging .pagetable_init()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Reply-To: mingo@kernel.org, hpa@zytor.com, linux-kernel@vger.kernel.org,
	konrad.wilk@oracle.com, Stefano.Stabellini@eu.citrix.com,
	Ian.Campbell@citrix.com, tglx@linutronix.de,
	attilio.rao@citrix.com, xen-devel@lists.xensource.com
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Commit-ID:  843b8ed2ec598aae5e3516b21957ede62a070e36
Gitweb:     http://git.kernel.org/tip/843b8ed2ec598aae5e3516b21957ede62a070e36
Author:     Attilio Rao <attilio.rao@citrix.com>
AuthorDate: Tue, 21 Aug 2012 21:22:39 +0100
Committer:  Thomas Gleixner <tglx@linutronix.de>
CommitDate: Wed, 12 Sep 2012 15:33:06 +0200

x86: Move paging_init() call to x86_init.paging.pagetable_init()

Move the paging_init() call to the platform specific pagetable_init()
function, so we can get rid of the extra pagetable_setup_done()
function pointer.

Signed-off-by: Attilio Rao <attilio.rao@citrix.com>
Acked-by: <konrad.wilk@oracle.com>
Cc: <Ian.Campbell@citrix.com>
Cc: <Stefano.Stabellini@eu.citrix.com>
Cc: <xen-devel@lists.xensource.com>
Link: http://lkml.kernel.org/r/1345580561-8506-4-git-send-email-attilio.rao@citrix.com
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
---
 arch/x86/include/asm/pgtable_types.h |    2 +-
 arch/x86/kernel/setup.c              |    1 -
 arch/x86/kernel/x86_init.c           |    1 -
 arch/x86/mm/init_32.c                |    1 +
 arch/x86/xen/mmu.c                   |    1 +
 5 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/x86/include/asm/pgtable_types.h b/arch/x86/include/asm/pgtable_types.h
index 0c01e07..c93cb8e 100644
--- a/arch/x86/include/asm/pgtable_types.h
+++ b/arch/x86/include/asm/pgtable_types.h
@@ -306,7 +306,7 @@ extern void native_pagetable_reserve(u64 start, u64 end);
 extern void native_pagetable_init(void);
 extern void native_pagetable_setup_done(pgd_t *base);
 #else
-#define native_pagetable_init        x86_init_pgd_init_noop
+#define native_pagetable_init        paging_init
 #define native_pagetable_setup_done  x86_init_pgd_done_noop
 #endif
 
diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
index 61b7d98..315fd24 100644
--- a/arch/x86/kernel/setup.c
+++ b/arch/x86/kernel/setup.c
@@ -962,7 +962,6 @@ void __init setup_arch(char **cmdline_p)
 #endif
 
 	x86_init.paging.pagetable_init();
-	paging_init();
 	x86_init.paging.pagetable_setup_done(swapper_pg_dir);
 
 	if (boot_cpu_data.cpuid_level >= 0) {
diff --git a/arch/x86/kernel/x86_init.c b/arch/x86/kernel/x86_init.c
index 0e1e950..5f2478f 100644
--- a/arch/x86/kernel/x86_init.c
+++ b/arch/x86/kernel/x86_init.c
@@ -26,7 +26,6 @@
 
 void __cpuinit x86_init_noop(void) { }
 void __init x86_init_uint_noop(unsigned int unused) { }
-void __init x86_init_pgd_init_noop(void) { }
 void __init x86_init_pgd_done_noop(pgd_t *unused) { }
 int __init iommu_init_noop(void) { return 0; }
 void iommu_shutdown_noop(void) { }
diff --git a/arch/x86/mm/init_32.c b/arch/x86/mm/init_32.c
index 0e38e0e..e35b4b1 100644
--- a/arch/x86/mm/init_32.c
+++ b/arch/x86/mm/init_32.c
@@ -475,6 +475,7 @@ void __init native_pagetable_init(void)
 		pte_clear(NULL, va, pte);
 	}
 	paravirt_alloc_pmd(&init_mm, __pa(base) >> PAGE_SHIFT);
+	paging_init();
 }
 
 void __init native_pagetable_setup_done(pgd_t *base)
diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c
index 624efbe..c2ff7ea 100644
--- a/arch/x86/xen/mmu.c
+++ b/arch/x86/xen/mmu.c
@@ -1176,6 +1176,7 @@ static void xen_exit_mmap(struct mm_struct *mm)
 
 static void __init xen_pagetable_init(void)
 {
+	paging_init();
 }
 
 static __init void xen_mapping_pagetable_reserve(u64 start, u64 end)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 12 13:49:56 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Sep 2012 13:49:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TBnK6-0003fW-6d; Wed, 12 Sep 2012 13:49:46 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <tipbot@zytor.com>) id 1TBnK5-0003fG-BW
	for xen-devel@lists.xensource.com; Wed, 12 Sep 2012 13:49:45 +0000
Received: from [85.158.139.83:45719] by server-11.bemta-5.messagelabs.com id
	FB/BC-24658-8F290505; Wed, 12 Sep 2012 13:49:44 +0000
X-Env-Sender: tipbot@zytor.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1347457782!27916987!1
X-Originating-IP: [198.137.202.10]
X-SpamReason: No, hits=1.0 required=7.0 tests=X_MAILER_SPAM
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10539 invoked from network); 12 Sep 2012 13:49:43 -0000
Received: from terminus.zytor.com (HELO terminus.zytor.com) (198.137.202.10)
	by server-15.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 12 Sep 2012 13:49:43 -0000
Received: from terminus.zytor.com (localhost [127.0.0.1])
	by terminus.zytor.com (8.14.5/8.14.5) with ESMTP id q8CDnPjO020686
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 12 Sep 2012 06:49:30 -0700
Received: (from tipbot@localhost)
	by terminus.zytor.com (8.14.5/8.14.5/Submit) id q8CDnOl2020683;
	Wed, 12 Sep 2012 06:49:24 -0700
Date: Wed, 12 Sep 2012 06:49:24 -0700
X-Authentication-Warning: terminus.zytor.com: tipbot set sender to
	tipbot@zytor.com using -f
From: tip-bot for Attilio Rao <attilio.rao@citrix.com>
Message-ID: <tip-c711288727a62f74d48032e56e51333dd104bf58@git.kernel.org>
In-Reply-To: <1345580561-8506-5-git-send-email-attilio.rao@citrix.com>
References: <1345580561-8506-5-git-send-email-attilio.rao@citrix.com>
To: linux-tip-commits@vger.kernel.org
Git-Commit-ID: c711288727a62f74d48032e56e51333dd104bf58
X-Mailer: tip-git-log-daemon
Robot-ID: <tip-bot.git.kernel.org>
Robot-Unsubscribe: Contact <mailto:hpa@kernel.org>
	to get blacklisted from these emails
MIME-Version: 1.0
Content-Disposition: inline
Precedence: bulk
X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00,
	T_DATE_IN_FUTURE_96_Q autolearn=ham version=3.3.2
X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on terminus.zytor.com
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.6
	(terminus.zytor.com [127.0.0.1]);
	Wed, 12 Sep 2012 06:49:30 -0700 (PDT)
Cc: xen-devel@lists.xensource.com, Ian.Campbell@citrix.com,
	konrad.wilk@oracle.com, Stefano.Stabellini@eu.citrix.com,
	linux-kernel@vger.kernel.org, hpa@zytor.com,
	attilio.rao@citrix.com, tglx@linutronix.de, mingo@kernel.org
Subject: [Xen-devel] [tip:x86/platform] x86: xen: Cleanup and remove
 x86_init.paging. pagetable_setup_done()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Reply-To: mingo@kernel.org, hpa@zytor.com, linux-kernel@vger.kernel.org,
	konrad.wilk@oracle.com, Stefano.Stabellini@eu.citrix.com,
	Ian.Campbell@citrix.com, tglx@linutronix.de,
	attilio.rao@citrix.com, xen-devel@lists.xensource.com
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Commit-ID:  c711288727a62f74d48032e56e51333dd104bf58
Gitweb:     http://git.kernel.org/tip/c711288727a62f74d48032e56e51333dd104bf58
Author:     Attilio Rao <attilio.rao@citrix.com>
AuthorDate: Tue, 21 Aug 2012 21:22:40 +0100
Committer:  Thomas Gleixner <tglx@linutronix.de>
CommitDate: Wed, 12 Sep 2012 15:33:06 +0200

x86: xen: Cleanup and remove x86_init.paging.pagetable_setup_done()

At this stage x86_init.paging.pagetable_setup_done is only used in the
XEN case. Move its content in the x86_init.paging.pagetable_init setup
function and remove the now unused x86_init.paging.pagetable_setup_done
remaining infrastructure.

Signed-off-by: Attilio Rao <attilio.rao@citrix.com>
Acked-by: <konrad.wilk@oracle.com>
Cc: <Ian.Campbell@citrix.com>
Cc: <Stefano.Stabellini@eu.citrix.com>
Cc: <xen-devel@lists.xensource.com>
Link: http://lkml.kernel.org/r/1345580561-8506-5-git-send-email-attilio.rao@citrix.com
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
---
 arch/x86/include/asm/pgtable_types.h |    2 --
 arch/x86/include/asm/x86_init.h      |    2 --
 arch/x86/kernel/setup.c              |    1 -
 arch/x86/kernel/x86_init.c           |    2 --
 arch/x86/mm/init_32.c                |    4 ----
 arch/x86/xen/mmu.c                   |   13 ++++---------
 6 files changed, 4 insertions(+), 20 deletions(-)

diff --git a/arch/x86/include/asm/pgtable_types.h b/arch/x86/include/asm/pgtable_types.h
index c93cb8e..db8fec6 100644
--- a/arch/x86/include/asm/pgtable_types.h
+++ b/arch/x86/include/asm/pgtable_types.h
@@ -304,10 +304,8 @@ void set_pte_vaddr(unsigned long vaddr, pte_t pte);
 extern void native_pagetable_reserve(u64 start, u64 end);
 #ifdef CONFIG_X86_32
 extern void native_pagetable_init(void);
-extern void native_pagetable_setup_done(pgd_t *base);
 #else
 #define native_pagetable_init        paging_init
-#define native_pagetable_setup_done  x86_init_pgd_done_noop
 #endif
 
 struct seq_file;
diff --git a/arch/x86/include/asm/x86_init.h b/arch/x86/include/asm/x86_init.h
index 24084b2..995ea5c 100644
--- a/arch/x86/include/asm/x86_init.h
+++ b/arch/x86/include/asm/x86_init.h
@@ -82,11 +82,9 @@ struct x86_init_mapping {
 /**
  * struct x86_init_paging - platform specific paging functions
  * @pagetable_init:		platform specific paging initialization call
- * @pagetable_setup_done:	platform specific post paging_init() call
  */
 struct x86_init_paging {
 	void (*pagetable_init)(void);
-	void (*pagetable_setup_done)(pgd_t *base);
 };
 
 /**
diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
index 315fd24..4f16547 100644
--- a/arch/x86/kernel/setup.c
+++ b/arch/x86/kernel/setup.c
@@ -962,7 +962,6 @@ void __init setup_arch(char **cmdline_p)
 #endif
 
 	x86_init.paging.pagetable_init();
-	x86_init.paging.pagetable_setup_done(swapper_pg_dir);
 
 	if (boot_cpu_data.cpuid_level >= 0) {
 		/* A CPU has %cr4 if and only if it has CPUID */
diff --git a/arch/x86/kernel/x86_init.c b/arch/x86/kernel/x86_init.c
index 5f2478f..7a3d075 100644
--- a/arch/x86/kernel/x86_init.c
+++ b/arch/x86/kernel/x86_init.c
@@ -26,7 +26,6 @@
 
 void __cpuinit x86_init_noop(void) { }
 void __init x86_init_uint_noop(unsigned int unused) { }
-void __init x86_init_pgd_done_noop(pgd_t *unused) { }
 int __init iommu_init_noop(void) { return 0; }
 void iommu_shutdown_noop(void) { }
 
@@ -69,7 +68,6 @@ struct x86_init_ops x86_init __initdata = {
 
 	.paging = {
 		.pagetable_init		= native_pagetable_init,
-		.pagetable_setup_done	= native_pagetable_setup_done,
 	},
 
 	.timers = {
diff --git a/arch/x86/mm/init_32.c b/arch/x86/mm/init_32.c
index e35b4b1..4f04db1 100644
--- a/arch/x86/mm/init_32.c
+++ b/arch/x86/mm/init_32.c
@@ -478,10 +478,6 @@ void __init native_pagetable_init(void)
 	paging_init();
 }
 
-void __init native_pagetable_setup_done(pgd_t *base)
-{
-}
-
 /*
  * Build a proper pagetable for the kernel mappings.  Up until this
  * point, we've been running on some set of pagetables constructed by
diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c
index c2ff7ea..7a769b7 100644
--- a/arch/x86/xen/mmu.c
+++ b/arch/x86/xen/mmu.c
@@ -1174,9 +1174,13 @@ static void xen_exit_mmap(struct mm_struct *mm)
 	spin_unlock(&mm->page_table_lock);
 }
 
+static void xen_post_allocator_init(void);
+
 static void __init xen_pagetable_init(void)
 {
 	paging_init();
+	xen_setup_shared_info();
+	xen_post_allocator_init();
 }
 
 static __init void xen_mapping_pagetable_reserve(u64 start, u64 end)
@@ -1193,14 +1197,6 @@ static __init void xen_mapping_pagetable_reserve(u64 start, u64 end)
 	}
 }
 
-static void xen_post_allocator_init(void);
-
-static void __init xen_pagetable_setup_done(pgd_t *base)
-{
-	xen_setup_shared_info();
-	xen_post_allocator_init();
-}
-
 static void xen_write_cr2(unsigned long cr2)
 {
 	this_cpu_read(xen_vcpu)->arch.cr2 = cr2;
@@ -2070,7 +2066,6 @@ void __init xen_init_mmu_ops(void)
 {
 	x86_init.mapping.pagetable_reserve = xen_mapping_pagetable_reserve;
 	x86_init.paging.pagetable_init = xen_pagetable_init;
-	x86_init.paging.pagetable_setup_done = xen_pagetable_setup_done;
 	pv_mmu_ops = xen_mmu_ops;
 
 	memset(dummy_mapping, 0xff, PAGE_SIZE);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 12 13:49:56 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Sep 2012 13:49:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TBnK6-0003fW-6d; Wed, 12 Sep 2012 13:49:46 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <tipbot@zytor.com>) id 1TBnK5-0003fG-BW
	for xen-devel@lists.xensource.com; Wed, 12 Sep 2012 13:49:45 +0000
Received: from [85.158.139.83:45719] by server-11.bemta-5.messagelabs.com id
	FB/BC-24658-8F290505; Wed, 12 Sep 2012 13:49:44 +0000
X-Env-Sender: tipbot@zytor.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1347457782!27916987!1
X-Originating-IP: [198.137.202.10]
X-SpamReason: No, hits=1.0 required=7.0 tests=X_MAILER_SPAM
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10539 invoked from network); 12 Sep 2012 13:49:43 -0000
Received: from terminus.zytor.com (HELO terminus.zytor.com) (198.137.202.10)
	by server-15.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 12 Sep 2012 13:49:43 -0000
Received: from terminus.zytor.com (localhost [127.0.0.1])
	by terminus.zytor.com (8.14.5/8.14.5) with ESMTP id q8CDnPjO020686
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 12 Sep 2012 06:49:30 -0700
Received: (from tipbot@localhost)
	by terminus.zytor.com (8.14.5/8.14.5/Submit) id q8CDnOl2020683;
	Wed, 12 Sep 2012 06:49:24 -0700
Date: Wed, 12 Sep 2012 06:49:24 -0700
X-Authentication-Warning: terminus.zytor.com: tipbot set sender to
	tipbot@zytor.com using -f
From: tip-bot for Attilio Rao <attilio.rao@citrix.com>
Message-ID: <tip-c711288727a62f74d48032e56e51333dd104bf58@git.kernel.org>
In-Reply-To: <1345580561-8506-5-git-send-email-attilio.rao@citrix.com>
References: <1345580561-8506-5-git-send-email-attilio.rao@citrix.com>
To: linux-tip-commits@vger.kernel.org
Git-Commit-ID: c711288727a62f74d48032e56e51333dd104bf58
X-Mailer: tip-git-log-daemon
Robot-ID: <tip-bot.git.kernel.org>
Robot-Unsubscribe: Contact <mailto:hpa@kernel.org>
	to get blacklisted from these emails
MIME-Version: 1.0
Content-Disposition: inline
Precedence: bulk
X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00,
	T_DATE_IN_FUTURE_96_Q autolearn=ham version=3.3.2
X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on terminus.zytor.com
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.6
	(terminus.zytor.com [127.0.0.1]);
	Wed, 12 Sep 2012 06:49:30 -0700 (PDT)
Cc: xen-devel@lists.xensource.com, Ian.Campbell@citrix.com,
	konrad.wilk@oracle.com, Stefano.Stabellini@eu.citrix.com,
	linux-kernel@vger.kernel.org, hpa@zytor.com,
	attilio.rao@citrix.com, tglx@linutronix.de, mingo@kernel.org
Subject: [Xen-devel] [tip:x86/platform] x86: xen: Cleanup and remove
 x86_init.paging. pagetable_setup_done()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Reply-To: mingo@kernel.org, hpa@zytor.com, linux-kernel@vger.kernel.org,
	konrad.wilk@oracle.com, Stefano.Stabellini@eu.citrix.com,
	Ian.Campbell@citrix.com, tglx@linutronix.de,
	attilio.rao@citrix.com, xen-devel@lists.xensource.com
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Commit-ID:  c711288727a62f74d48032e56e51333dd104bf58
Gitweb:     http://git.kernel.org/tip/c711288727a62f74d48032e56e51333dd104bf58
Author:     Attilio Rao <attilio.rao@citrix.com>
AuthorDate: Tue, 21 Aug 2012 21:22:40 +0100
Committer:  Thomas Gleixner <tglx@linutronix.de>
CommitDate: Wed, 12 Sep 2012 15:33:06 +0200

x86: xen: Cleanup and remove x86_init.paging.pagetable_setup_done()

At this stage x86_init.paging.pagetable_setup_done is only used in the
XEN case. Move its content in the x86_init.paging.pagetable_init setup
function and remove the now unused x86_init.paging.pagetable_setup_done
remaining infrastructure.

Signed-off-by: Attilio Rao <attilio.rao@citrix.com>
Acked-by: <konrad.wilk@oracle.com>
Cc: <Ian.Campbell@citrix.com>
Cc: <Stefano.Stabellini@eu.citrix.com>
Cc: <xen-devel@lists.xensource.com>
Link: http://lkml.kernel.org/r/1345580561-8506-5-git-send-email-attilio.rao@citrix.com
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
---
 arch/x86/include/asm/pgtable_types.h |    2 --
 arch/x86/include/asm/x86_init.h      |    2 --
 arch/x86/kernel/setup.c              |    1 -
 arch/x86/kernel/x86_init.c           |    2 --
 arch/x86/mm/init_32.c                |    4 ----
 arch/x86/xen/mmu.c                   |   13 ++++---------
 6 files changed, 4 insertions(+), 20 deletions(-)

diff --git a/arch/x86/include/asm/pgtable_types.h b/arch/x86/include/asm/pgtable_types.h
index c93cb8e..db8fec6 100644
--- a/arch/x86/include/asm/pgtable_types.h
+++ b/arch/x86/include/asm/pgtable_types.h
@@ -304,10 +304,8 @@ void set_pte_vaddr(unsigned long vaddr, pte_t pte);
 extern void native_pagetable_reserve(u64 start, u64 end);
 #ifdef CONFIG_X86_32
 extern void native_pagetable_init(void);
-extern void native_pagetable_setup_done(pgd_t *base);
 #else
 #define native_pagetable_init        paging_init
-#define native_pagetable_setup_done  x86_init_pgd_done_noop
 #endif
 
 struct seq_file;
diff --git a/arch/x86/include/asm/x86_init.h b/arch/x86/include/asm/x86_init.h
index 24084b2..995ea5c 100644
--- a/arch/x86/include/asm/x86_init.h
+++ b/arch/x86/include/asm/x86_init.h
@@ -82,11 +82,9 @@ struct x86_init_mapping {
 /**
  * struct x86_init_paging - platform specific paging functions
  * @pagetable_init:		platform specific paging initialization call
- * @pagetable_setup_done:	platform specific post paging_init() call
  */
 struct x86_init_paging {
 	void (*pagetable_init)(void);
-	void (*pagetable_setup_done)(pgd_t *base);
 };
 
 /**
diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
index 315fd24..4f16547 100644
--- a/arch/x86/kernel/setup.c
+++ b/arch/x86/kernel/setup.c
@@ -962,7 +962,6 @@ void __init setup_arch(char **cmdline_p)
 #endif
 
 	x86_init.paging.pagetable_init();
-	x86_init.paging.pagetable_setup_done(swapper_pg_dir);
 
 	if (boot_cpu_data.cpuid_level >= 0) {
 		/* A CPU has %cr4 if and only if it has CPUID */
diff --git a/arch/x86/kernel/x86_init.c b/arch/x86/kernel/x86_init.c
index 5f2478f..7a3d075 100644
--- a/arch/x86/kernel/x86_init.c
+++ b/arch/x86/kernel/x86_init.c
@@ -26,7 +26,6 @@
 
 void __cpuinit x86_init_noop(void) { }
 void __init x86_init_uint_noop(unsigned int unused) { }
-void __init x86_init_pgd_done_noop(pgd_t *unused) { }
 int __init iommu_init_noop(void) { return 0; }
 void iommu_shutdown_noop(void) { }
 
@@ -69,7 +68,6 @@ struct x86_init_ops x86_init __initdata = {
 
 	.paging = {
 		.pagetable_init		= native_pagetable_init,
-		.pagetable_setup_done	= native_pagetable_setup_done,
 	},
 
 	.timers = {
diff --git a/arch/x86/mm/init_32.c b/arch/x86/mm/init_32.c
index e35b4b1..4f04db1 100644
--- a/arch/x86/mm/init_32.c
+++ b/arch/x86/mm/init_32.c
@@ -478,10 +478,6 @@ void __init native_pagetable_init(void)
 	paging_init();
 }
 
-void __init native_pagetable_setup_done(pgd_t *base)
-{
-}
-
 /*
  * Build a proper pagetable for the kernel mappings.  Up until this
  * point, we've been running on some set of pagetables constructed by
diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c
index c2ff7ea..7a769b7 100644
--- a/arch/x86/xen/mmu.c
+++ b/arch/x86/xen/mmu.c
@@ -1174,9 +1174,13 @@ static void xen_exit_mmap(struct mm_struct *mm)
 	spin_unlock(&mm->page_table_lock);
 }
 
+static void xen_post_allocator_init(void);
+
 static void __init xen_pagetable_init(void)
 {
 	paging_init();
+	xen_setup_shared_info();
+	xen_post_allocator_init();
 }
 
 static __init void xen_mapping_pagetable_reserve(u64 start, u64 end)
@@ -1193,14 +1197,6 @@ static __init void xen_mapping_pagetable_reserve(u64 start, u64 end)
 	}
 }
 
-static void xen_post_allocator_init(void);
-
-static void __init xen_pagetable_setup_done(pgd_t *base)
-{
-	xen_setup_shared_info();
-	xen_post_allocator_init();
-}
-
 static void xen_write_cr2(unsigned long cr2)
 {
 	this_cpu_read(xen_vcpu)->arch.cr2 = cr2;
@@ -2070,7 +2066,6 @@ void __init xen_init_mmu_ops(void)
 {
 	x86_init.mapping.pagetable_reserve = xen_mapping_pagetable_reserve;
 	x86_init.paging.pagetable_init = xen_pagetable_init;
-	x86_init.paging.pagetable_setup_done = xen_pagetable_setup_done;
 	pv_mmu_ops = xen_mmu_ops;
 
 	memset(dummy_mapping, 0xff, PAGE_SIZE);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 12 13:50:53 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Sep 2012 13:50:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TBnL1-0003oi-LB; Wed, 12 Sep 2012 13:50:43 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <tipbot@zytor.com>) id 1TBnL0-0003oG-2H
	for xen-devel@lists.xensource.com; Wed, 12 Sep 2012 13:50:42 +0000
Received: from [85.158.143.99:15061] by server-1.bemta-4.messagelabs.com id
	77/62-12504-13390505; Wed, 12 Sep 2012 13:50:41 +0000
X-Env-Sender: tipbot@zytor.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1347457838!24737055!1
X-Originating-IP: [198.137.202.10]
X-SpamReason: No, hits=1.0 required=7.0 tests=X_MAILER_SPAM
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29034 invoked from network); 12 Sep 2012 13:50:40 -0000
Received: from terminus.zytor.com (HELO terminus.zytor.com) (198.137.202.10)
	by server-12.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 12 Sep 2012 13:50:40 -0000
Received: from terminus.zytor.com (localhost [127.0.0.1])
	by terminus.zytor.com (8.14.5/8.14.5) with ESMTP id q8CDoK1H020828
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 12 Sep 2012 06:50:25 -0700
Received: (from tipbot@localhost)
	by terminus.zytor.com (8.14.5/8.14.5/Submit) id q8CDoKGt020825;
	Wed, 12 Sep 2012 06:50:20 -0700
Date: Wed, 12 Sep 2012 06:50:20 -0700
X-Authentication-Warning: terminus.zytor.com: tipbot set sender to
	tipbot@zytor.com using -f
From: tip-bot for Attilio Rao <attilio.rao@citrix.com>
Message-ID: <tip-64282278989d5b0398dcb3ba7904cb00c621dc35@git.kernel.org>
In-Reply-To: <1345580561-8506-6-git-send-email-attilio.rao@citrix.com>
References: <1345580561-8506-6-git-send-email-attilio.rao@citrix.com>
To: linux-tip-commits@vger.kernel.org
Git-Commit-ID: 64282278989d5b0398dcb3ba7904cb00c621dc35
X-Mailer: tip-git-log-daemon
Robot-ID: <tip-bot.git.kernel.org>
Robot-Unsubscribe: Contact <mailto:hpa@kernel.org>
	to get blacklisted from these emails
MIME-Version: 1.0
Content-Disposition: inline
Precedence: bulk
X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00,
	T_DATE_IN_FUTURE_96_Q autolearn=ham version=3.3.2
X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on terminus.zytor.com
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.6
	(terminus.zytor.com [127.0.0.1]);
	Wed, 12 Sep 2012 06:50:26 -0700 (PDT)
Cc: xen-devel@lists.xensource.com, Ian.Campbell@citrix.com,
	konrad.wilk@oracle.com, Stefano.Stabellini@eu.citrix.com,
	linux-kernel@vger.kernel.org, hpa@zytor.com,
	attilio.rao@citrix.com, tglx@linutronix.de, mingo@kernel.org
Subject: [Xen-devel] [tip:x86/platform] x86: Document
	x86_init.paging.pagetable_init()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Reply-To: mingo@kernel.org, hpa@zytor.com, linux-kernel@vger.kernel.org,
	konrad.wilk@oracle.com, Stefano.Stabellini@eu.citrix.com,
	Ian.Campbell@citrix.com, tglx@linutronix.de,
	attilio.rao@citrix.com, xen-devel@lists.xensource.com
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Commit-ID:  64282278989d5b0398dcb3ba7904cb00c621dc35
Gitweb:     http://git.kernel.org/tip/64282278989d5b0398dcb3ba7904cb00c621dc35
Author:     Attilio Rao <attilio.rao@citrix.com>
AuthorDate: Tue, 21 Aug 2012 21:22:41 +0100
Committer:  Thomas Gleixner <tglx@linutronix.de>
CommitDate: Wed, 12 Sep 2012 15:33:07 +0200

x86: Document x86_init.paging.pagetable_init()

Signed-off-by: Attilio Rao <attilio.rao@citrix.com>
Acked-by: <konrad.wilk@oracle.com>
Cc: <Ian.Campbell@citrix.com>
Cc: <Stefano.Stabellini@eu.citrix.com>
Cc: <xen-devel@lists.xensource.com>
Link: http://lkml.kernel.org/r/1345580561-8506-6-git-send-email-attilio.rao@citrix.com
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
---
 arch/x86/include/asm/x86_init.h |    5 ++++-
 1 files changed, 4 insertions(+), 1 deletions(-)

diff --git a/arch/x86/include/asm/x86_init.h b/arch/x86/include/asm/x86_init.h
index 995ea5c..5769349 100644
--- a/arch/x86/include/asm/x86_init.h
+++ b/arch/x86/include/asm/x86_init.h
@@ -81,7 +81,10 @@ struct x86_init_mapping {
 
 /**
  * struct x86_init_paging - platform specific paging functions
- * @pagetable_init:		platform specific paging initialization call
+ * @pagetable_init:	platform specific paging initialization call to setup
+ *			the kernel pagetables and prepare accessors functions.
+ *			Callback must call paging_init(). Called once after the
+ *			direct mapping for phys memory is available.
  */
 struct x86_init_paging {
 	void (*pagetable_init)(void);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 12 13:50:53 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Sep 2012 13:50:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TBnL1-0003oi-LB; Wed, 12 Sep 2012 13:50:43 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <tipbot@zytor.com>) id 1TBnL0-0003oG-2H
	for xen-devel@lists.xensource.com; Wed, 12 Sep 2012 13:50:42 +0000
Received: from [85.158.143.99:15061] by server-1.bemta-4.messagelabs.com id
	77/62-12504-13390505; Wed, 12 Sep 2012 13:50:41 +0000
X-Env-Sender: tipbot@zytor.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1347457838!24737055!1
X-Originating-IP: [198.137.202.10]
X-SpamReason: No, hits=1.0 required=7.0 tests=X_MAILER_SPAM
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29034 invoked from network); 12 Sep 2012 13:50:40 -0000
Received: from terminus.zytor.com (HELO terminus.zytor.com) (198.137.202.10)
	by server-12.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 12 Sep 2012 13:50:40 -0000
Received: from terminus.zytor.com (localhost [127.0.0.1])
	by terminus.zytor.com (8.14.5/8.14.5) with ESMTP id q8CDoK1H020828
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 12 Sep 2012 06:50:25 -0700
Received: (from tipbot@localhost)
	by terminus.zytor.com (8.14.5/8.14.5/Submit) id q8CDoKGt020825;
	Wed, 12 Sep 2012 06:50:20 -0700
Date: Wed, 12 Sep 2012 06:50:20 -0700
X-Authentication-Warning: terminus.zytor.com: tipbot set sender to
	tipbot@zytor.com using -f
From: tip-bot for Attilio Rao <attilio.rao@citrix.com>
Message-ID: <tip-64282278989d5b0398dcb3ba7904cb00c621dc35@git.kernel.org>
In-Reply-To: <1345580561-8506-6-git-send-email-attilio.rao@citrix.com>
References: <1345580561-8506-6-git-send-email-attilio.rao@citrix.com>
To: linux-tip-commits@vger.kernel.org
Git-Commit-ID: 64282278989d5b0398dcb3ba7904cb00c621dc35
X-Mailer: tip-git-log-daemon
Robot-ID: <tip-bot.git.kernel.org>
Robot-Unsubscribe: Contact <mailto:hpa@kernel.org>
	to get blacklisted from these emails
MIME-Version: 1.0
Content-Disposition: inline
Precedence: bulk
X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00,
	T_DATE_IN_FUTURE_96_Q autolearn=ham version=3.3.2
X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on terminus.zytor.com
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.6
	(terminus.zytor.com [127.0.0.1]);
	Wed, 12 Sep 2012 06:50:26 -0700 (PDT)
Cc: xen-devel@lists.xensource.com, Ian.Campbell@citrix.com,
	konrad.wilk@oracle.com, Stefano.Stabellini@eu.citrix.com,
	linux-kernel@vger.kernel.org, hpa@zytor.com,
	attilio.rao@citrix.com, tglx@linutronix.de, mingo@kernel.org
Subject: [Xen-devel] [tip:x86/platform] x86: Document
	x86_init.paging.pagetable_init()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Reply-To: mingo@kernel.org, hpa@zytor.com, linux-kernel@vger.kernel.org,
	konrad.wilk@oracle.com, Stefano.Stabellini@eu.citrix.com,
	Ian.Campbell@citrix.com, tglx@linutronix.de,
	attilio.rao@citrix.com, xen-devel@lists.xensource.com
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Commit-ID:  64282278989d5b0398dcb3ba7904cb00c621dc35
Gitweb:     http://git.kernel.org/tip/64282278989d5b0398dcb3ba7904cb00c621dc35
Author:     Attilio Rao <attilio.rao@citrix.com>
AuthorDate: Tue, 21 Aug 2012 21:22:41 +0100
Committer:  Thomas Gleixner <tglx@linutronix.de>
CommitDate: Wed, 12 Sep 2012 15:33:07 +0200

x86: Document x86_init.paging.pagetable_init()

Signed-off-by: Attilio Rao <attilio.rao@citrix.com>
Acked-by: <konrad.wilk@oracle.com>
Cc: <Ian.Campbell@citrix.com>
Cc: <Stefano.Stabellini@eu.citrix.com>
Cc: <xen-devel@lists.xensource.com>
Link: http://lkml.kernel.org/r/1345580561-8506-6-git-send-email-attilio.rao@citrix.com
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
---
 arch/x86/include/asm/x86_init.h |    5 ++++-
 1 files changed, 4 insertions(+), 1 deletions(-)

diff --git a/arch/x86/include/asm/x86_init.h b/arch/x86/include/asm/x86_init.h
index 995ea5c..5769349 100644
--- a/arch/x86/include/asm/x86_init.h
+++ b/arch/x86/include/asm/x86_init.h
@@ -81,7 +81,10 @@ struct x86_init_mapping {
 
 /**
  * struct x86_init_paging - platform specific paging functions
- * @pagetable_init:		platform specific paging initialization call
+ * @pagetable_init:	platform specific paging initialization call to setup
+ *			the kernel pagetables and prepare accessors functions.
+ *			Callback must call paging_init(). Called once after the
+ *			direct mapping for phys memory is available.
  */
 struct x86_init_paging {
 	void (*pagetable_init)(void);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 12 14:57:17 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Sep 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 1TBoMv-0004S1-UC; Wed, 12 Sep 2012 14:56:45 +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 1TBoMt-0004Rw-SN
	for xen-devel@lists.xen.org; Wed, 12 Sep 2012 14:56:44 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1347461793!3047132!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDg4MjM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26389 invoked from network); 12 Sep 2012 14:56: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;
	12 Sep 2012 14:56:33 -0000
X-IronPort-AV: E=Sophos;i="4.80,410,1344211200"; d="scan'208";a="14499478"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Sep 2012 14:56:32 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 12 Sep 2012 15:56:32 +0100
Message-ID: <1347461790.24226.56.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Andres Lagar-Cavilla <andreslc@gridcentric.ca>
Date: Wed, 12 Sep 2012 15:56:30 +0100
In-Reply-To: <B5B91DB6-BC9C-4E0A-BCF3-243671577A40@gridcentric.ca>
References: <B5B91DB6-BC9C-4E0A-BCF3-243671577A40@gridcentric.ca>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Roger Pau Monne <roger.pau@citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Libxenstore memory leak on static compile
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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-09-12 at 14:44 +0100, Andres Lagar-Cavilla wrote:
> When statically compiling libxenstore.a, the USE_PTHREAD define is not
> applied. This results in cleanup_{pus/pop} being no-ops. cleanup_p*
> are used throughout xs.c:read_message to free malloc'ed objects.
> 
> In short, libxenstore.a will leak memory when reading xenstore
> messages. OOM killer awaits.
> 
> This could be solved by either turning on USE_PTHREAD for .a
> compilation (which, N.B. will not actually link libpthread but instead
> produce an object archive that needs to be eventually linked to
> libpthread.so), or by replacing cleanup_p* by proper free calls.

The reason for the non-pthreads static library was so that you could
build tiny statically linked xenstore clients against tiny libcs (like
uclibc) to have things small enough to fit in e.g. your installer initrd
or in your "guest tools" package.

It used to be that uclibc didn't have a pthreads library.  Maybe this
has changed though (Roger, CCd, would know).

We don't seem to use pthread_cleanup_push/pop very extensively, so I
think using proper free calls is probably the way to go?

Using that pthread facility as a cheap and nasty GC seems a bit wrong to
me anyhow.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 12 14:57:17 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Sep 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 1TBoMv-0004S1-UC; Wed, 12 Sep 2012 14:56:45 +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 1TBoMt-0004Rw-SN
	for xen-devel@lists.xen.org; Wed, 12 Sep 2012 14:56:44 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1347461793!3047132!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDg4MjM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26389 invoked from network); 12 Sep 2012 14:56: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;
	12 Sep 2012 14:56:33 -0000
X-IronPort-AV: E=Sophos;i="4.80,410,1344211200"; d="scan'208";a="14499478"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Sep 2012 14:56:32 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 12 Sep 2012 15:56:32 +0100
Message-ID: <1347461790.24226.56.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Andres Lagar-Cavilla <andreslc@gridcentric.ca>
Date: Wed, 12 Sep 2012 15:56:30 +0100
In-Reply-To: <B5B91DB6-BC9C-4E0A-BCF3-243671577A40@gridcentric.ca>
References: <B5B91DB6-BC9C-4E0A-BCF3-243671577A40@gridcentric.ca>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Roger Pau Monne <roger.pau@citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Libxenstore memory leak on static compile
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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-09-12 at 14:44 +0100, Andres Lagar-Cavilla wrote:
> When statically compiling libxenstore.a, the USE_PTHREAD define is not
> applied. This results in cleanup_{pus/pop} being no-ops. cleanup_p*
> are used throughout xs.c:read_message to free malloc'ed objects.
> 
> In short, libxenstore.a will leak memory when reading xenstore
> messages. OOM killer awaits.
> 
> This could be solved by either turning on USE_PTHREAD for .a
> compilation (which, N.B. will not actually link libpthread but instead
> produce an object archive that needs to be eventually linked to
> libpthread.so), or by replacing cleanup_p* by proper free calls.

The reason for the non-pthreads static library was so that you could
build tiny statically linked xenstore clients against tiny libcs (like
uclibc) to have things small enough to fit in e.g. your installer initrd
or in your "guest tools" package.

It used to be that uclibc didn't have a pthreads library.  Maybe this
has changed though (Roger, CCd, would know).

We don't seem to use pthread_cleanup_push/pop very extensively, so I
think using proper free calls is probably the way to go?

Using that pthread facility as a cheap and nasty GC seems a bit wrong to
me anyhow.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 12 15:04:21 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Sep 2012 15:04:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TBoTu-0004hQ-W6; Wed, 12 Sep 2012 15:03:58 +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 1TBoTt-0004hK-8P
	for xen-devel@lists.xen.org; Wed, 12 Sep 2012 15:03:57 +0000
Received: from [85.158.143.35:24404] by server-3.bemta-4.messagelabs.com id
	94/BB-08232-C54A0505; Wed, 12 Sep 2012 15:03:56 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1347462236!13360806!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDg4MjM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14230 invoked from network); 12 Sep 2012 15:03:56 -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;
	12 Sep 2012 15:03:56 -0000
X-IronPort-AV: E=Sophos;i="4.80,410,1344211200"; d="scan'208";a="14499690"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Sep 2012 15:03: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.279.1; Wed, 12 Sep 2012 16:03:52 +0100
Message-ID: <5050A457.7070201@citrix.com>
Date: Wed, 12 Sep 2012 16:03:51 +0100
From: Roger Pau Monne <roger.pau@citrix.com>
User-Agent: Postbox 3.0.5 (Macintosh/20120826)
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <B5B91DB6-BC9C-4E0A-BCF3-243671577A40@gridcentric.ca>
	<1347461790.24226.56.camel@zakaz.uk.xensource.com>
In-Reply-To: <1347461790.24226.56.camel@zakaz.uk.xensource.com>
X-Enigmail-Version: 1.2.2
Cc: Andres Lagar-Cavilla <andreslc@gridcentric.ca>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Libxenstore memory leak on static compile
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell wrote:
> On Wed, 2012-09-12 at 14:44 +0100, Andres Lagar-Cavilla wrote:
>> When statically compiling libxenstore.a, the USE_PTHREAD define is not
>> applied. This results in cleanup_{pus/pop} being no-ops. cleanup_p*
>> are used throughout xs.c:read_message to free malloc'ed objects.
>>
>> In short, libxenstore.a will leak memory when reading xenstore
>> messages. OOM killer awaits.
>>
>> This could be solved by either turning on USE_PTHREAD for .a
>> compilation (which, N.B. will not actually link libpthread but instead
>> produce an object archive that needs to be eventually linked to
>> libpthread.so), or by replacing cleanup_p* by proper free calls.
> 
> The reason for the non-pthreads static library was so that you could
> build tiny statically linked xenstore clients against tiny libcs (like
> uclibc) to have things small enough to fit in e.g. your installer initrd
> or in your "guest tools" package.
> 
> It used to be that uclibc didn't have a pthreads library.  Maybe this
> has changed though (Roger, CCd, would know).

Yes, uclibc added a pthread library back in 2002:

http://mailman.uclinux.org/pipermail/uclinux-dev/2002-March/007613.html

> We don't seem to use pthread_cleanup_push/pop very extensively, so I
> think using proper free calls is probably the way to go?
> 
> Using that pthread facility as a cheap and nasty GC seems a bit wrong to
> me anyhow.
> 
> Ian.
> 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 12 15:04:21 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Sep 2012 15:04:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TBoTu-0004hQ-W6; Wed, 12 Sep 2012 15:03:58 +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 1TBoTt-0004hK-8P
	for xen-devel@lists.xen.org; Wed, 12 Sep 2012 15:03:57 +0000
Received: from [85.158.143.35:24404] by server-3.bemta-4.messagelabs.com id
	94/BB-08232-C54A0505; Wed, 12 Sep 2012 15:03:56 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1347462236!13360806!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDg4MjM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14230 invoked from network); 12 Sep 2012 15:03:56 -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;
	12 Sep 2012 15:03:56 -0000
X-IronPort-AV: E=Sophos;i="4.80,410,1344211200"; d="scan'208";a="14499690"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Sep 2012 15:03: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.279.1; Wed, 12 Sep 2012 16:03:52 +0100
Message-ID: <5050A457.7070201@citrix.com>
Date: Wed, 12 Sep 2012 16:03:51 +0100
From: Roger Pau Monne <roger.pau@citrix.com>
User-Agent: Postbox 3.0.5 (Macintosh/20120826)
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <B5B91DB6-BC9C-4E0A-BCF3-243671577A40@gridcentric.ca>
	<1347461790.24226.56.camel@zakaz.uk.xensource.com>
In-Reply-To: <1347461790.24226.56.camel@zakaz.uk.xensource.com>
X-Enigmail-Version: 1.2.2
Cc: Andres Lagar-Cavilla <andreslc@gridcentric.ca>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Libxenstore memory leak on static compile
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell wrote:
> On Wed, 2012-09-12 at 14:44 +0100, Andres Lagar-Cavilla wrote:
>> When statically compiling libxenstore.a, the USE_PTHREAD define is not
>> applied. This results in cleanup_{pus/pop} being no-ops. cleanup_p*
>> are used throughout xs.c:read_message to free malloc'ed objects.
>>
>> In short, libxenstore.a will leak memory when reading xenstore
>> messages. OOM killer awaits.
>>
>> This could be solved by either turning on USE_PTHREAD for .a
>> compilation (which, N.B. will not actually link libpthread but instead
>> produce an object archive that needs to be eventually linked to
>> libpthread.so), or by replacing cleanup_p* by proper free calls.
> 
> The reason for the non-pthreads static library was so that you could
> build tiny statically linked xenstore clients against tiny libcs (like
> uclibc) to have things small enough to fit in e.g. your installer initrd
> or in your "guest tools" package.
> 
> It used to be that uclibc didn't have a pthreads library.  Maybe this
> has changed though (Roger, CCd, would know).

Yes, uclibc added a pthread library back in 2002:

http://mailman.uclinux.org/pipermail/uclinux-dev/2002-March/007613.html

> We don't seem to use pthread_cleanup_push/pop very extensively, so I
> think using proper free calls is probably the way to go?
> 
> Using that pthread facility as a cheap and nasty GC seems a bit wrong to
> me anyhow.
> 
> Ian.
> 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 12 15:04:38 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Sep 2012 15:04: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 1TBoUF-0004ib-CW; Wed, 12 Sep 2012 15:04: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 1TBoUD-0004iJ-8s
	for xen-devel@lists.xensource.com; Wed, 12 Sep 2012 15:04:17 +0000
Received: from [85.158.143.99:7430] by server-3.bemta-4.messagelabs.com id
	F8/7C-08232-074A0505; Wed, 12 Sep 2012 15:04:16 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1347462255!22978205!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDg4MjM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31778 invoked from network); 12 Sep 2012 15:04:16 -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;
	12 Sep 2012 15:04:16 -0000
X-IronPort-AV: E=Sophos;i="4.80,410,1344211200"; d="scan'208";a="14499704"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Sep 2012 15:04: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.279.1; Wed, 12 Sep 2012 16:04: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 1TBoU7-00008f-GN;
	Wed, 12 Sep 2012 15:04:11 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1TBoU7-0007EW-G2;
	Wed, 12 Sep 2012 16:04:11 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-13690-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 12 Sep 2012 16:04:11 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.1-testing test] 13690: trouble:
	blocked/broken/fail/pass
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 13690 xen-4.1-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13690/

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64-pvops             2 host-install(2)         broken REGR. vs. 13657

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-amd64-pv           1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl           1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf-pin  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 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 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-amd64-win          1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  1 xen-build-check(1)           blocked n/a
 test-amd64-i386-qemuu-rhel6hvm-intel 11 leak-check/check       fail never pass
 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-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       1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-qemuu-winxpsp3 13 guest-stop                 fail never pass
 test-amd64-amd64-xl-winxpsp3  1 xen-build-check(1)           blocked  n/a

version targeted for testing:
 xen                  9be1175d2ac3
baseline version:
 xen                  3e4782f17f5c

------------------------------------------------------------
People who touched revisions under test:
  Ian Jackson <ian.jackson@eu.citrix.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            broken  
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          blocked 
 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                         blocked 
 test-amd64-amd64-xl-win7-amd64                               blocked 
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              blocked 
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        blocked 
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 blocked 
 test-amd64-amd64-pv                                          blocked 
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     blocked 
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         blocked 
 test-amd64-i386-win                                          fail    
 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                                fail    
 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.

------------------------------------------------------------
changeset:   23354:9be1175d2ac3
tag:         tip
user:        Ian Jackson <Ian.Jackson@eu.citrix.com>
date:        Tue Sep 11 14:31:12 2012 +0100
    
    QEMU_TAG update
    
    
changeset:   23353:3e4782f17f5c
user:        Ian Jackson <Ian.Jackson@eu.citrix.com>
date:        Wed Sep 05 12:40:10 2012 +0100
    
    QEMU_TAG update (XSA-17 / CVE-2012-3515)
    
    
========================================
commit d7d453f51459b591faa96d1c123b5bfff7c5b6b6
Author: Ian Jackson <ian.jackson@eu.citrix.com>
Date:   Thu Sep 6 17:05:30 2012 +0100

    Disable qemu monitor by default.  The qemu monitor is an overly
    powerful feature which must be protected from untrusted (guest)
    administrators.
    
    Neither xl nor xend expect qemu to produce this monitor unless it is
    explicitly requested.
    
    This is a security problem, XSA-19.  Previously it was CVE-2007-0998
    in Red Hat but we haven't dealt with it in upstream.  We hope to have
    a new CVE for it here but we don't have one yet.
    
    Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
    (cherry picked from commit bacc0d302445c75f18f4c826750fb5853b60e7ca)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 12 15:04:38 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Sep 2012 15:04: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 1TBoUF-0004ib-CW; Wed, 12 Sep 2012 15:04: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 1TBoUD-0004iJ-8s
	for xen-devel@lists.xensource.com; Wed, 12 Sep 2012 15:04:17 +0000
Received: from [85.158.143.99:7430] by server-3.bemta-4.messagelabs.com id
	F8/7C-08232-074A0505; Wed, 12 Sep 2012 15:04:16 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1347462255!22978205!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDg4MjM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31778 invoked from network); 12 Sep 2012 15:04:16 -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;
	12 Sep 2012 15:04:16 -0000
X-IronPort-AV: E=Sophos;i="4.80,410,1344211200"; d="scan'208";a="14499704"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Sep 2012 15:04: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.279.1; Wed, 12 Sep 2012 16:04: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 1TBoU7-00008f-GN;
	Wed, 12 Sep 2012 15:04:11 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1TBoU7-0007EW-G2;
	Wed, 12 Sep 2012 16:04:11 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-13690-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 12 Sep 2012 16:04:11 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.1-testing test] 13690: trouble:
	blocked/broken/fail/pass
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 13690 xen-4.1-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13690/

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64-pvops             2 host-install(2)         broken REGR. vs. 13657

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-amd64-pv           1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl           1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf-pin  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 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 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-amd64-win          1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  1 xen-build-check(1)           blocked n/a
 test-amd64-i386-qemuu-rhel6hvm-intel 11 leak-check/check       fail never pass
 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-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       1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-qemuu-winxpsp3 13 guest-stop                 fail never pass
 test-amd64-amd64-xl-winxpsp3  1 xen-build-check(1)           blocked  n/a

version targeted for testing:
 xen                  9be1175d2ac3
baseline version:
 xen                  3e4782f17f5c

------------------------------------------------------------
People who touched revisions under test:
  Ian Jackson <ian.jackson@eu.citrix.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            broken  
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          blocked 
 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                         blocked 
 test-amd64-amd64-xl-win7-amd64                               blocked 
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              blocked 
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        blocked 
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 blocked 
 test-amd64-amd64-pv                                          blocked 
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     blocked 
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         blocked 
 test-amd64-i386-win                                          fail    
 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                                fail    
 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.

------------------------------------------------------------
changeset:   23354:9be1175d2ac3
tag:         tip
user:        Ian Jackson <Ian.Jackson@eu.citrix.com>
date:        Tue Sep 11 14:31:12 2012 +0100
    
    QEMU_TAG update
    
    
changeset:   23353:3e4782f17f5c
user:        Ian Jackson <Ian.Jackson@eu.citrix.com>
date:        Wed Sep 05 12:40:10 2012 +0100
    
    QEMU_TAG update (XSA-17 / CVE-2012-3515)
    
    
========================================
commit d7d453f51459b591faa96d1c123b5bfff7c5b6b6
Author: Ian Jackson <ian.jackson@eu.citrix.com>
Date:   Thu Sep 6 17:05:30 2012 +0100

    Disable qemu monitor by default.  The qemu monitor is an overly
    powerful feature which must be protected from untrusted (guest)
    administrators.
    
    Neither xl nor xend expect qemu to produce this monitor unless it is
    explicitly requested.
    
    This is a security problem, XSA-19.  Previously it was CVE-2007-0998
    in Red Hat but we haven't dealt with it in upstream.  We hope to have
    a new CVE for it here but we don't have one yet.
    
    Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
    (cherry picked from commit bacc0d302445c75f18f4c826750fb5853b60e7ca)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 12 15:09:59 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Sep 2012 15:09:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TBoZU-0004y4-5i; Wed, 12 Sep 2012 15:09:44 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andreslc@gridcentric.ca>) id 1TBoZR-0004xz-SC
	for xen-devel@lists.xen.org; Wed, 12 Sep 2012 15:09:42 +0000
Received: from [85.158.138.51:26288] by server-11.bemta-3.messagelabs.com id
	13/AB-30250-5B5A0505; Wed, 12 Sep 2012 15:09:41 +0000
X-Env-Sender: andreslc@gridcentric.ca
X-Msg-Ref: server-11.tower-174.messagelabs.com!1347462578!30167349!1
X-Originating-IP: [209.85.161.173]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
  RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32496 invoked from network); 12 Sep 2012 15:09:40 -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;
	12 Sep 2012 15:09:40 -0000
Received: by ggna5 with SMTP id a5so447296ggn.32
	for <xen-devel@lists.xen.org>; Wed, 12 Sep 2012 08:09:36 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=subject:mime-version:content-type:from:in-reply-to:date:cc
	:content-transfer-encoding:message-id:references:to:x-mailer
	:x-gm-message-state;
	bh=U7EAnQqFR++ZXiYoXghQMVWN6xSWirGFDbRic2FgTdo=;
	b=If7q9HCFsN3WVt5cyialazzT+acBvab68q6rX5UdIlckVhuy0OF9dSRGkIDk+SVqut
	k2J/jWdldz0xu/5tD0S+SLL/rjUWtDcFX9tOqyZR7ACyLZt6AVsEQC20RJYd8AlrfR/z
	DClN4NlW3v3xUkWh9VsAYc6xIKEB7hv9l3evIxpNV1/ikqiQncrMSGFDr3/KHUOCUaql
	s8gboKDoW2IGMbqSNQMCGPr99BPVMhNGOUsyByRTgim3jkA6GggrvWW2Nujwh4eaIEIT
	2tyryGbEa9n5qVrGz1DT3HhczXYTg7+rx0p7EPUzEXyzHU+3F1fs8UhUow8lwhm84swj
	/Ihg==
Received: by 10.236.108.194 with SMTP id q42mr20902842yhg.3.1347462575912;
	Wed, 12 Sep 2012 08:09:35 -0700 (PDT)
Received: from [192.168.7.212] ([206.223.182.18])
	by mx.google.com with ESMTPS id o11sm16433467anj.20.2012.09.12.08.09.34
	(version=TLSv1/SSLv3 cipher=OTHER);
	Wed, 12 Sep 2012 08:09:35 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1278)
From: Andres Lagar-Cavilla <andreslc@gridcentric.ca>
In-Reply-To: <5050A457.7070201@citrix.com>
Date: Wed, 12 Sep 2012 11:09:35 -0400
Message-Id: <3F05442F-4DA8-463A-A9B7-596B9853CFFD@gridcentric.ca>
References: <B5B91DB6-BC9C-4E0A-BCF3-243671577A40@gridcentric.ca>
	<1347461790.24226.56.camel@zakaz.uk.xensource.com>
	<5050A457.7070201@citrix.com>
To: Roger Pau Monne <roger.pau@citrix.com>
X-Mailer: Apple Mail (2.1278)
X-Gm-Message-State: ALoCoQlp1K3gsaVSxOHlhJ0zS4KL6nkdtwYFFXC/mKprJgUrxy2aHbLrhT8R/LtwLEHVWDFPUra+
Cc: Andres Lagar-Cavilla <andreslc@gridcentric.ca>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Libxenstore memory leak on static compile
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Sep 12, 2012, at 11:03 AM, Roger Pau Monne wrote:

> Ian Campbell wrote:
>> On Wed, 2012-09-12 at 14:44 +0100, Andres Lagar-Cavilla wrote:
>>> When statically compiling libxenstore.a, the USE_PTHREAD define is not
>>> applied. This results in cleanup_{pus/pop} being no-ops. cleanup_p*
>>> are used throughout xs.c:read_message to free malloc'ed objects.
>>> 
>>> In short, libxenstore.a will leak memory when reading xenstore
>>> messages. OOM killer awaits.
>>> 
>>> This could be solved by either turning on USE_PTHREAD for .a
>>> compilation (which, N.B. will not actually link libpthread but instead
>>> produce an object archive that needs to be eventually linked to
>>> libpthread.so), or by replacing cleanup_p* by proper free calls.
>> 
>> The reason for the non-pthreads static library was so that you could
>> build tiny statically linked xenstore clients against tiny libcs (like
>> uclibc) to have things small enough to fit in e.g. your installer initrd
>> or in your "guest tools" package.
>> 
>> It used to be that uclibc didn't have a pthreads library.  Maybe this
>> has changed though (Roger, CCd, would know).
> 
> Yes, uclibc added a pthread library back in 2002:
> 
> http://mailman.uclinux.org/pipermail/uclinux-dev/2002-March/007613.html
I have a simple fix to compile with pthread.h (below). It's really your call as to whether you want to maintain pthread-free versions of libraries for the next embedded femto-libc (and whether that is consistently applied throughout the tree, etc). Getting rid of pthread_push/pop as alternative is not bad at all.

Andres

# HG changeset patch
# Parent b3a8ef4c556cc9a2d310cd8dd1e2f625c92c8515
Compile xs.o with pthread support.

Otherwise messages are not freed in the statically linked libxenstore.a.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r b3a8ef4c556c tools/xenstore/Makefile
--- a/tools/xenstore/Makefile
+++ b/tools/xenstore/Makefile
@@ -81,6 +81,7 @@ libxenstore.so.$(MAJOR): libxenstore.so.
 	ln -sf $< $@
 
 xs.opic: CFLAGS += -DUSE_PTHREAD
+xs.o: CFLAGS += -DUSE_PTHREAD
 
 libxenstore.so.$(MAJOR).$(MINOR): xs.opic xs_lib.opic
 	$(CC) $(LDFLAGS) -Wl,$(SONAME_LDFLAG) -Wl,libxenstore.so.$(MAJOR) $(SHLIB_LDFLAGS) -o $@ $^ $(SOCKET_LIBS) -lpthread $(APPEND_LDFLAGS)

> 
>> We don't seem to use pthread_cleanup_push/pop very extensively, so I
>> think using proper free calls is probably the way to go?
>> 
>> Using that pthread facility as a cheap and nasty GC seems a bit wrong to
>> me anyhow.
>> 
>> Ian.
>> 
> 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 12 15:09:59 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Sep 2012 15:09:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TBoZU-0004y4-5i; Wed, 12 Sep 2012 15:09:44 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andreslc@gridcentric.ca>) id 1TBoZR-0004xz-SC
	for xen-devel@lists.xen.org; Wed, 12 Sep 2012 15:09:42 +0000
Received: from [85.158.138.51:26288] by server-11.bemta-3.messagelabs.com id
	13/AB-30250-5B5A0505; Wed, 12 Sep 2012 15:09:41 +0000
X-Env-Sender: andreslc@gridcentric.ca
X-Msg-Ref: server-11.tower-174.messagelabs.com!1347462578!30167349!1
X-Originating-IP: [209.85.161.173]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
  RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32496 invoked from network); 12 Sep 2012 15:09:40 -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;
	12 Sep 2012 15:09:40 -0000
Received: by ggna5 with SMTP id a5so447296ggn.32
	for <xen-devel@lists.xen.org>; Wed, 12 Sep 2012 08:09:36 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=subject:mime-version:content-type:from:in-reply-to:date:cc
	:content-transfer-encoding:message-id:references:to:x-mailer
	:x-gm-message-state;
	bh=U7EAnQqFR++ZXiYoXghQMVWN6xSWirGFDbRic2FgTdo=;
	b=If7q9HCFsN3WVt5cyialazzT+acBvab68q6rX5UdIlckVhuy0OF9dSRGkIDk+SVqut
	k2J/jWdldz0xu/5tD0S+SLL/rjUWtDcFX9tOqyZR7ACyLZt6AVsEQC20RJYd8AlrfR/z
	DClN4NlW3v3xUkWh9VsAYc6xIKEB7hv9l3evIxpNV1/ikqiQncrMSGFDr3/KHUOCUaql
	s8gboKDoW2IGMbqSNQMCGPr99BPVMhNGOUsyByRTgim3jkA6GggrvWW2Nujwh4eaIEIT
	2tyryGbEa9n5qVrGz1DT3HhczXYTg7+rx0p7EPUzEXyzHU+3F1fs8UhUow8lwhm84swj
	/Ihg==
Received: by 10.236.108.194 with SMTP id q42mr20902842yhg.3.1347462575912;
	Wed, 12 Sep 2012 08:09:35 -0700 (PDT)
Received: from [192.168.7.212] ([206.223.182.18])
	by mx.google.com with ESMTPS id o11sm16433467anj.20.2012.09.12.08.09.34
	(version=TLSv1/SSLv3 cipher=OTHER);
	Wed, 12 Sep 2012 08:09:35 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1278)
From: Andres Lagar-Cavilla <andreslc@gridcentric.ca>
In-Reply-To: <5050A457.7070201@citrix.com>
Date: Wed, 12 Sep 2012 11:09:35 -0400
Message-Id: <3F05442F-4DA8-463A-A9B7-596B9853CFFD@gridcentric.ca>
References: <B5B91DB6-BC9C-4E0A-BCF3-243671577A40@gridcentric.ca>
	<1347461790.24226.56.camel@zakaz.uk.xensource.com>
	<5050A457.7070201@citrix.com>
To: Roger Pau Monne <roger.pau@citrix.com>
X-Mailer: Apple Mail (2.1278)
X-Gm-Message-State: ALoCoQlp1K3gsaVSxOHlhJ0zS4KL6nkdtwYFFXC/mKprJgUrxy2aHbLrhT8R/LtwLEHVWDFPUra+
Cc: Andres Lagar-Cavilla <andreslc@gridcentric.ca>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Libxenstore memory leak on static compile
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Sep 12, 2012, at 11:03 AM, Roger Pau Monne wrote:

> Ian Campbell wrote:
>> On Wed, 2012-09-12 at 14:44 +0100, Andres Lagar-Cavilla wrote:
>>> When statically compiling libxenstore.a, the USE_PTHREAD define is not
>>> applied. This results in cleanup_{pus/pop} being no-ops. cleanup_p*
>>> are used throughout xs.c:read_message to free malloc'ed objects.
>>> 
>>> In short, libxenstore.a will leak memory when reading xenstore
>>> messages. OOM killer awaits.
>>> 
>>> This could be solved by either turning on USE_PTHREAD for .a
>>> compilation (which, N.B. will not actually link libpthread but instead
>>> produce an object archive that needs to be eventually linked to
>>> libpthread.so), or by replacing cleanup_p* by proper free calls.
>> 
>> The reason for the non-pthreads static library was so that you could
>> build tiny statically linked xenstore clients against tiny libcs (like
>> uclibc) to have things small enough to fit in e.g. your installer initrd
>> or in your "guest tools" package.
>> 
>> It used to be that uclibc didn't have a pthreads library.  Maybe this
>> has changed though (Roger, CCd, would know).
> 
> Yes, uclibc added a pthread library back in 2002:
> 
> http://mailman.uclinux.org/pipermail/uclinux-dev/2002-March/007613.html
I have a simple fix to compile with pthread.h (below). It's really your call as to whether you want to maintain pthread-free versions of libraries for the next embedded femto-libc (and whether that is consistently applied throughout the tree, etc). Getting rid of pthread_push/pop as alternative is not bad at all.

Andres

# HG changeset patch
# Parent b3a8ef4c556cc9a2d310cd8dd1e2f625c92c8515
Compile xs.o with pthread support.

Otherwise messages are not freed in the statically linked libxenstore.a.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r b3a8ef4c556c tools/xenstore/Makefile
--- a/tools/xenstore/Makefile
+++ b/tools/xenstore/Makefile
@@ -81,6 +81,7 @@ libxenstore.so.$(MAJOR): libxenstore.so.
 	ln -sf $< $@
 
 xs.opic: CFLAGS += -DUSE_PTHREAD
+xs.o: CFLAGS += -DUSE_PTHREAD
 
 libxenstore.so.$(MAJOR).$(MINOR): xs.opic xs_lib.opic
 	$(CC) $(LDFLAGS) -Wl,$(SONAME_LDFLAG) -Wl,libxenstore.so.$(MAJOR) $(SHLIB_LDFLAGS) -o $@ $^ $(SOCKET_LIBS) -lpthread $(APPEND_LDFLAGS)

> 
>> We don't seem to use pthread_cleanup_push/pop very extensively, so I
>> think using proper free calls is probably the way to go?
>> 
>> Using that pthread facility as a cheap and nasty GC seems a bit wrong to
>> me anyhow.
>> 
>> Ian.
>> 
> 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 12 15:56:53 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Sep 2012 15: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 1TBpIo-0005Gf-JA; Wed, 12 Sep 2012 15:56: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 1TBpIm-0005Ga-LO
	for xen-devel@lists.xen.org; Wed, 12 Sep 2012 15:56:32 +0000
Received: from [85.158.143.99:26055] by server-2.bemta-4.messagelabs.com id
	7C/05-21239-FA0B0505; Wed, 12 Sep 2012 15:56:31 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1347465391!29667750!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDg4MjM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7515 invoked from network); 12 Sep 2012 15:56: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;
	12 Sep 2012 15:56:31 -0000
X-IronPort-AV: E=Sophos;i="4.80,410,1344211200"; d="scan'208";a="14500943"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Sep 2012 15:56: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.279.1;
	Wed, 12 Sep 2012 16:56:29 +0100
Message-ID: <1347465388.24226.60.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Andres Lagar-Cavilla <andreslc@gridcentric.ca>
Date: Wed, 12 Sep 2012 16:56:28 +0100
In-Reply-To: <3F05442F-4DA8-463A-A9B7-596B9853CFFD@gridcentric.ca>
References: <B5B91DB6-BC9C-4E0A-BCF3-243671577A40@gridcentric.ca>
	<1347461790.24226.56.camel@zakaz.uk.xensource.com>
	<5050A457.7070201@citrix.com>
	<3F05442F-4DA8-463A-A9B7-596B9853CFFD@gridcentric.ca>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xen.org>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Roger Pau Monne <roger.pau@citrix.com>
Subject: Re: [Xen-devel] Libxenstore memory leak on static compile
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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-09-12 at 16:09 +0100, Andres Lagar-Cavilla wrote:
> On Sep 12, 2012, at 11:03 AM, Roger Pau Monne wrote:
> 
> > Ian Campbell wrote:
> >> On Wed, 2012-09-12 at 14:44 +0100, Andres Lagar-Cavilla wrote:
> >>> When statically compiling libxenstore.a, the USE_PTHREAD define is not
> >>> applied. This results in cleanup_{pus/pop} being no-ops. cleanup_p*
> >>> are used throughout xs.c:read_message to free malloc'ed objects.
> >>> 
> >>> In short, libxenstore.a will leak memory when reading xenstore
> >>> messages. OOM killer awaits.
> >>> 
> >>> This could be solved by either turning on USE_PTHREAD for .a
> >>> compilation (which, N.B. will not actually link libpthread but instead
> >>> produce an object archive that needs to be eventually linked to
> >>> libpthread.so), or by replacing cleanup_p* by proper free calls.
> >> 
> >> The reason for the non-pthreads static library was so that you could
> >> build tiny statically linked xenstore clients against tiny libcs (like
> >> uclibc) to have things small enough to fit in e.g. your installer initrd
> >> or in your "guest tools" package.
> >> 
> >> It used to be that uclibc didn't have a pthreads library.  Maybe this
> >> has changed though (Roger, CCd, would know).
> > 
> > Yes, uclibc added a pthread library back in 2002:
> > 
> > http://mailman.uclinux.org/pipermail/uclinux-dev/2002-March/007613.html
> I have a simple fix to compile with pthread.h (below). It's really your call as to whether you want to maintain pthread-free versions of libraries for the next embedded femto-libc (and whether that is consistently applied throughout the tree, etc). Getting rid of pthread_push/pop as alternative is not bad at all.
> 
> Andres
> 
> # HG changeset patch
> # Parent b3a8ef4c556cc9a2d310cd8dd1e2f625c92c8515
> Compile xs.o with pthread support.
> 
> Otherwise messages are not freed in the statically linked libxenstore.a.

If you do this then you may as well nuke the !USE_PTHREAD case
altogether, since this makes it pointless.

I'd prefer not to do that though.

> 
> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
> 
> diff -r b3a8ef4c556c tools/xenstore/Makefile
> --- a/tools/xenstore/Makefile
> +++ b/tools/xenstore/Makefile
> @@ -81,6 +81,7 @@ libxenstore.so.$(MAJOR): libxenstore.so.
>  	ln -sf $< $@
>  
>  xs.opic: CFLAGS += -DUSE_PTHREAD
> +xs.o: CFLAGS += -DUSE_PTHREAD
>  
>  libxenstore.so.$(MAJOR).$(MINOR): xs.opic xs_lib.opic
>  	$(CC) $(LDFLAGS) -Wl,$(SONAME_LDFLAG) -Wl,libxenstore.so.$(MAJOR) $(SHLIB_LDFLAGS) -o $@ $^ $(SOCKET_LIBS) -lpthread $(APPEND_LDFLAGS)
> 
> > 
> >> We don't seem to use pthread_cleanup_push/pop very extensively, so I
> >> think using proper free calls is probably the way to go?
> >> 
> >> Using that pthread facility as a cheap and nasty GC seems a bit wrong to
> >> me anyhow.
> >> 
> >> Ian.
> >> 
> > 
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 12 15:56:53 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Sep 2012 15: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 1TBpIo-0005Gf-JA; Wed, 12 Sep 2012 15:56: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 1TBpIm-0005Ga-LO
	for xen-devel@lists.xen.org; Wed, 12 Sep 2012 15:56:32 +0000
Received: from [85.158.143.99:26055] by server-2.bemta-4.messagelabs.com id
	7C/05-21239-FA0B0505; Wed, 12 Sep 2012 15:56:31 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1347465391!29667750!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDg4MjM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7515 invoked from network); 12 Sep 2012 15:56: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;
	12 Sep 2012 15:56:31 -0000
X-IronPort-AV: E=Sophos;i="4.80,410,1344211200"; d="scan'208";a="14500943"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Sep 2012 15:56: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.279.1;
	Wed, 12 Sep 2012 16:56:29 +0100
Message-ID: <1347465388.24226.60.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Andres Lagar-Cavilla <andreslc@gridcentric.ca>
Date: Wed, 12 Sep 2012 16:56:28 +0100
In-Reply-To: <3F05442F-4DA8-463A-A9B7-596B9853CFFD@gridcentric.ca>
References: <B5B91DB6-BC9C-4E0A-BCF3-243671577A40@gridcentric.ca>
	<1347461790.24226.56.camel@zakaz.uk.xensource.com>
	<5050A457.7070201@citrix.com>
	<3F05442F-4DA8-463A-A9B7-596B9853CFFD@gridcentric.ca>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xen.org>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Roger Pau Monne <roger.pau@citrix.com>
Subject: Re: [Xen-devel] Libxenstore memory leak on static compile
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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-09-12 at 16:09 +0100, Andres Lagar-Cavilla wrote:
> On Sep 12, 2012, at 11:03 AM, Roger Pau Monne wrote:
> 
> > Ian Campbell wrote:
> >> On Wed, 2012-09-12 at 14:44 +0100, Andres Lagar-Cavilla wrote:
> >>> When statically compiling libxenstore.a, the USE_PTHREAD define is not
> >>> applied. This results in cleanup_{pus/pop} being no-ops. cleanup_p*
> >>> are used throughout xs.c:read_message to free malloc'ed objects.
> >>> 
> >>> In short, libxenstore.a will leak memory when reading xenstore
> >>> messages. OOM killer awaits.
> >>> 
> >>> This could be solved by either turning on USE_PTHREAD for .a
> >>> compilation (which, N.B. will not actually link libpthread but instead
> >>> produce an object archive that needs to be eventually linked to
> >>> libpthread.so), or by replacing cleanup_p* by proper free calls.
> >> 
> >> The reason for the non-pthreads static library was so that you could
> >> build tiny statically linked xenstore clients against tiny libcs (like
> >> uclibc) to have things small enough to fit in e.g. your installer initrd
> >> or in your "guest tools" package.
> >> 
> >> It used to be that uclibc didn't have a pthreads library.  Maybe this
> >> has changed though (Roger, CCd, would know).
> > 
> > Yes, uclibc added a pthread library back in 2002:
> > 
> > http://mailman.uclinux.org/pipermail/uclinux-dev/2002-March/007613.html
> I have a simple fix to compile with pthread.h (below). It's really your call as to whether you want to maintain pthread-free versions of libraries for the next embedded femto-libc (and whether that is consistently applied throughout the tree, etc). Getting rid of pthread_push/pop as alternative is not bad at all.
> 
> Andres
> 
> # HG changeset patch
> # Parent b3a8ef4c556cc9a2d310cd8dd1e2f625c92c8515
> Compile xs.o with pthread support.
> 
> Otherwise messages are not freed in the statically linked libxenstore.a.

If you do this then you may as well nuke the !USE_PTHREAD case
altogether, since this makes it pointless.

I'd prefer not to do that though.

> 
> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
> 
> diff -r b3a8ef4c556c tools/xenstore/Makefile
> --- a/tools/xenstore/Makefile
> +++ b/tools/xenstore/Makefile
> @@ -81,6 +81,7 @@ libxenstore.so.$(MAJOR): libxenstore.so.
>  	ln -sf $< $@
>  
>  xs.opic: CFLAGS += -DUSE_PTHREAD
> +xs.o: CFLAGS += -DUSE_PTHREAD
>  
>  libxenstore.so.$(MAJOR).$(MINOR): xs.opic xs_lib.opic
>  	$(CC) $(LDFLAGS) -Wl,$(SONAME_LDFLAG) -Wl,libxenstore.so.$(MAJOR) $(SHLIB_LDFLAGS) -o $@ $^ $(SOCKET_LIBS) -lpthread $(APPEND_LDFLAGS)
> 
> > 
> >> We don't seem to use pthread_cleanup_push/pop very extensively, so I
> >> think using proper free calls is probably the way to go?
> >> 
> >> Using that pthread facility as a cheap and nasty GC seems a bit wrong to
> >> me anyhow.
> >> 
> >> Ian.
> >> 
> > 
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 12 16:00:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Sep 2012 16:00:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TBpMF-0005ot-DQ; Wed, 12 Sep 2012 16:00:07 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1TBpMC-0005Oy-GF
	for xen-devel@lists.xen.org; Wed, 12 Sep 2012 16:00:04 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-7.tower-27.messagelabs.com!1347465597!3056364!1
X-Originating-IP: [63.239.67.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4903 invoked from network); 12 Sep 2012 15:59:58 -0000
Received: from emvm-gh1-uea09.nsa.gov (HELO nsa.gov) (63.239.67.10)
	by server-7.tower-27.messagelabs.com with SMTP;
	12 Sep 2012 15:59:58 -0000
X-TM-IMSS-Message-ID: <39e12a5d001083e1@nsa.gov>
Received: from tarius.tycho.ncsc.mil ([144.51.3.1]) by nsa.gov
	([63.239.67.10]) with ESMTP (TREND IMSS SMTP Service 7.1) id
	39e12a5d001083e1 ; Wed, 12 Sep 2012 12:02:04 -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 q8CFxoOW006669; 
	Wed, 12 Sep 2012 11:59:56 -0400
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xen.org
Date: Wed, 12 Sep 2012 11:59:46 -0400
Message-Id: <1347465586-20009-23-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.11.4
In-Reply-To: <1347465586-20009-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1347465586-20009-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: dgdegra@tycho.nsa.gov, Dan Magenheimer <dan.magenheimer@oracle.com>
Subject: [Xen-devel] [PATCH 22/22] tmem: add XSM hooks
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This adds a pair of XSM hooks for tmem operations: xsm_tmem_op which
controls any use of tmem, and xsm_tmem_control which allows use of the
TMEM_CONTROL operations. By default, all domains can use tmem while only
IS_PRIV domains can use control operations.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Cc: Dan Magenheimer <dan.magenheimer@oracle.com>
---
 tools/flask/policy/policy/flask/access_vectors |  2 ++
 xen/common/tmem.c                              |  3 +++
 xen/include/xen/tmem_xen.h                     |  8 +++++++-
 xen/include/xsm/dummy.h                        | 12 ++++++++++++
 xen/include/xsm/xsm.h                          | 12 ++++++++++++
 xen/xsm/dummy.c                                |  2 ++
 xen/xsm/flask/hooks.c                          | 12 ++++++++++++
 xen/xsm/flask/include/av_perm_to_string.h      |  2 ++
 xen/xsm/flask/include/av_permissions.h         |  2 ++
 9 files changed, 54 insertions(+), 1 deletion(-)

diff --git a/tools/flask/policy/policy/flask/access_vectors b/tools/flask/policy/policy/flask/access_vectors
index caf65d2..7a7e253 100644
--- a/tools/flask/policy/policy/flask/access_vectors
+++ b/tools/flask/policy/policy/flask/access_vectors
@@ -35,6 +35,8 @@ class xen
 	lockprof
 	cpupool_op
 	sched_op
+	tmem_op
+	tmem_control
 }
 
 class domain
diff --git a/xen/common/tmem.c b/xen/common/tmem.c
index f4812b9..6d95296 100644
--- a/xen/common/tmem.c
+++ b/xen/common/tmem.c
@@ -2636,6 +2636,9 @@ EXPORT long do_tmem_op(tmem_cli_op_t uops)
     if ( !tmem_initialized )
         return -ENODEV;
 
+    if ( !tmh_current_permitted() )
+        return -EPERM;
+
     total_tmem_ops++;
 
     if ( tmh_lock_all )
diff --git a/xen/include/xen/tmem_xen.h b/xen/include/xen/tmem_xen.h
index 9492810..ae550af 100644
--- a/xen/include/xen/tmem_xen.h
+++ b/xen/include/xen/tmem_xen.h
@@ -16,6 +16,7 @@
 #include <xen/guest_access.h> /* copy_from_guest */
 #include <xen/hash.h> /* hash_long */
 #include <xen/domain_page.h> /* __map_domain_page */
+#include <xsm/xsm.h> /* xsm_tmem_control */
 #include <public/tmem.h>
 #ifdef CONFIG_COMPAT
 #include <compat/tmem.h>
@@ -326,9 +327,14 @@ static inline bool_t tmh_set_client_from_id(
     return rc;
 }
 
+static inline bool_t tmh_current_permitted(void)
+{
+    return !xsm_tmem_op();
+}
+
 static inline bool_t tmh_current_is_privileged(void)
 {
-    return IS_PRIV(current->domain);
+    return !xsm_tmem_control();
 }
 
 static inline uint8_t tmh_get_first_byte(pfp_t *pfp)
diff --git a/xen/include/xsm/dummy.h b/xen/include/xsm/dummy.h
index e5e8020..4ed010a 100644
--- a/xen/include/xsm/dummy.h
+++ b/xen/include/xsm/dummy.h
@@ -443,6 +443,18 @@ static XSM_DEFAULT(int, sched_op) (void)
     return 0;
 }
 
+static XSM_DEFAULT(int, tmem_op) (void)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, tmem_control) (void)
+{
+    if ( !IS_PRIV(current->domain) )
+        return -EPERM;
+    return 0;
+}
+
 static XSM_DEFAULT(long, __do_xsm_op)(XEN_GUEST_HANDLE(xsm_op_t) op)
 {
     return -ENOSYS;
diff --git a/xen/include/xsm/xsm.h b/xen/include/xsm/xsm.h
index 46d5cd6..d7ab92b 100644
--- a/xen/include/xsm/xsm.h
+++ b/xen/include/xsm/xsm.h
@@ -134,6 +134,8 @@ struct xsm_operations {
     int (*lockprof)(void);
     int (*cpupool_op)(void);
     int (*sched_op)(void);
+    int (*tmem_op)(void);
+    int (*tmem_control)(void);
 
     long (*__do_xsm_op) (XEN_GUEST_HANDLE(xsm_op_t) op);
 
@@ -610,6 +612,16 @@ static inline int xsm_sched_op(void)
     return xsm_ops->sched_op();
 }
 
+static inline int xsm_tmem_op(void)
+{
+    return xsm_ops->tmem_op();
+}
+
+static inline int xsm_tmem_control(void)
+{
+    return xsm_ops->tmem_control();
+}
+
 static inline long xsm___do_xsm_op (XEN_GUEST_HANDLE(xsm_op_t) op)
 {
     return xsm_ops->__do_xsm_op(op);
diff --git a/xen/xsm/dummy.c b/xen/xsm/dummy.c
index ddaf40b..e4fdfd7 100644
--- a/xen/xsm/dummy.c
+++ b/xen/xsm/dummy.c
@@ -120,6 +120,8 @@ void xsm_fixup_ops (struct xsm_operations *ops)
     set_to_dummy_if_null(ops, lockprof);
     set_to_dummy_if_null(ops, cpupool_op);
     set_to_dummy_if_null(ops, sched_op);
+    set_to_dummy_if_null(ops, tmem_op);
+    set_to_dummy_if_null(ops, tmem_control);
 
     set_to_dummy_if_null(ops, __do_xsm_op);
 
diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
index 2f33a9f..4553289 100644
--- a/xen/xsm/flask/hooks.c
+++ b/xen/xsm/flask/hooks.c
@@ -1077,6 +1077,16 @@ static inline int flask_sched_op(void)
     return domain_has_xen(current->domain, XEN__SCHED_OP);
 }
 
+static inline int flask_tmem_op(void)
+{
+    return domain_has_xen(current->domain, XEN__TMEM_OP);
+}
+
+static inline int flask_tmem_control(void)
+{
+    return domain_has_xen(current->domain, XEN__TMEM_CONTROL);
+}
+
 static int flask_perfcontrol(void)
 {
     return domain_has_xen(current->domain, XEN__PERFCONTROL);
@@ -1721,6 +1731,8 @@ static struct xsm_operations flask_ops = {
     .lockprof = flask_lockprof,
     .cpupool_op = flask_cpupool_op,
     .sched_op = flask_sched_op,
+    .tmem_op = flask_tmem_op,
+    .tmem_control = flask_tmem_control,
 
     .__do_xsm_op = do_flask_op,
 
diff --git a/xen/xsm/flask/include/av_perm_to_string.h b/xen/xsm/flask/include/av_perm_to_string.h
index 79d5939..c3f2370 100644
--- a/xen/xsm/flask/include/av_perm_to_string.h
+++ b/xen/xsm/flask/include/av_perm_to_string.h
@@ -29,6 +29,8 @@
    S_(SECCLASS_XEN, XEN__LOCKPROF, "lockprof")
    S_(SECCLASS_XEN, XEN__CPUPOOL_OP, "cpupool_op")
    S_(SECCLASS_XEN, XEN__SCHED_OP, "sched_op")
+   S_(SECCLASS_XEN, XEN__TMEM_OP, "tmem_op")
+   S_(SECCLASS_XEN, XEN__TMEM_CONTROL, "tmem_control")
    S_(SECCLASS_DOMAIN, DOMAIN__SETVCPUCONTEXT, "setvcpucontext")
    S_(SECCLASS_DOMAIN, DOMAIN__PAUSE, "pause")
    S_(SECCLASS_DOMAIN, DOMAIN__UNPAUSE, "unpause")
diff --git a/xen/xsm/flask/include/av_permissions.h b/xen/xsm/flask/include/av_permissions.h
index d982328..65302e8 100644
--- a/xen/xsm/flask/include/av_permissions.h
+++ b/xen/xsm/flask/include/av_permissions.h
@@ -29,6 +29,8 @@
 #define XEN__LOCKPROF                             0x08000000UL
 #define XEN__CPUPOOL_OP                           0x10000000UL
 #define XEN__SCHED_OP                             0x20000000UL
+#define XEN__TMEM_OP                              0x40000000UL
+#define XEN__TMEM_CONTROL                         0x80000000UL
 
 #define DOMAIN__SETVCPUCONTEXT                    0x00000001UL
 #define DOMAIN__PAUSE                             0x00000002UL
-- 
1.7.11.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 12 16:00:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Sep 2012 16:00:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TBpMA-0005TS-6u; Wed, 12 Sep 2012 16:00:02 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1TBpM8-0005Mn-AH
	for xen-devel@lists.xen.org; Wed, 12 Sep 2012 16:00:00 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-5.tower-27.messagelabs.com!1347465593!7348020!1
X-Originating-IP: [63.239.67.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12219 invoked from network); 12 Sep 2012 15:59:54 -0000
Received: from emvm-gh1-uea09.nsa.gov (HELO nsa.gov) (63.239.67.10)
	by server-5.tower-27.messagelabs.com with SMTP;
	12 Sep 2012 15:59:54 -0000
X-TM-IMSS-Message-ID: <39e11882001083d1@nsa.gov>
Received: from tarius.tycho.ncsc.mil ([144.51.3.1]) by nsa.gov
	([63.239.67.10]) with ESMTP (TREND IMSS SMTP Service 7.1) id
	39e11882001083d1 ; Wed, 12 Sep 2012 12:01:59 -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 q8CFxoOF006669; 
	Wed, 12 Sep 2012 11:59:52 -0400
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xen.org
Date: Wed, 12 Sep 2012 11:59:29 -0400
Message-Id: <1347465586-20009-6-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.11.4
In-Reply-To: <1347465586-20009-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1347465586-20009-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: dgdegra@tycho.nsa.gov, Ian Jackson <ian.jackson@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH 05/22] libxl: introduce XSM relabel on build
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Allow a domain to be built under one security label and run using a
different label. This can be used to prevent the domain builder or
control domain from having the ability to access a guest domain's memory
via map_foreign_range except during the build process where this is
required.

Note: this does not provide complete protection from a malicious dom0;
mappings created during the build process may persist after the relabel,
and could be used to indirectly access the guest's memory.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: Ian Campbell <ian.campbell@citrix.com>
---
 tools/libxc/xc_flask.c      | 10 ++++++++++
 tools/libxc/xenctrl.h       |  1 +
 tools/libxl/libxl_create.c  |  4 ++++
 tools/libxl/libxl_types.idl |  1 +
 tools/libxl/xl_cmdimpl.c    | 20 +++++++++++++++++++-
 5 files changed, 35 insertions(+), 1 deletion(-)

diff --git a/tools/libxc/xc_flask.c b/tools/libxc/xc_flask.c
index 80c5a2d..face1e0 100644
--- a/tools/libxc/xc_flask.c
+++ b/tools/libxc/xc_flask.c
@@ -422,6 +422,16 @@ int xc_flask_setavc_threshold(xc_interface *xch, int threshold)
     return xc_flask_op(xch, &op);
 }
 
+int xc_flask_relabel_domain(xc_interface *xch, int domid, uint32_t sid)
+{
+    DECLARE_FLASK_OP;
+    op.cmd = FLASK_RELABEL_DOMAIN;
+    op.u.relabel.domid = domid;
+    op.u.relabel.sid = sid;
+
+    return xc_flask_op(xch, &op);
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/tools/libxc/xenctrl.h b/tools/libxc/xenctrl.h
index b7741ca..0d595a0 100644
--- a/tools/libxc/xenctrl.h
+++ b/tools/libxc/xenctrl.h
@@ -2173,6 +2173,7 @@ int xc_flask_policyvers(xc_interface *xc_handle);
 int xc_flask_avc_hashstats(xc_interface *xc_handle, char *buf, int size);
 int xc_flask_getavc_threshold(xc_interface *xc_handle);
 int xc_flask_setavc_threshold(xc_interface *xc_handle, int threshold);
+int xc_flask_relabel_domain(xc_interface *xch, int domid, uint32_t sid);
 
 struct elf_binary;
 void xc_elf_set_logfile(xc_interface *xch, struct elf_binary *elf,
diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index ef17f05..6d7bf4e 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -1126,6 +1126,10 @@ static void domcreate_complete(libxl__egc *egc,
                                int rc)
 {
     STATE_AO_GC(dcs->ao);
+    libxl_domain_config *const d_config = dcs->guest_config;
+
+    if (!rc && d_config->b_info.exec_ssidref)
+        rc = xc_flask_relabel_domain(CTX->xch, dcs->guest_domid, d_config->b_info.exec_ssidref);
 
     if (rc) {
         if (dcs->guest_domid) {
diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
index 6d5c578..bc11591 100644
--- a/tools/libxl/libxl_types.idl
+++ b/tools/libxl/libxl_types.idl
@@ -262,6 +262,7 @@ libxl_domain_build_info = Struct("domain_build_info",[
     ("video_memkb",     MemKB),
     ("shadow_memkb",    MemKB),
     ("rtc_timeoffset",  uint32),
+    ("exec_ssidref",    uint32),
     ("localtime",       libxl_defbool),
     ("disable_migrate", libxl_defbool),
     ("cpuid",           libxl_cpuid_policy_list),
diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index 2d6ab97..9b5f291 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -595,16 +595,34 @@ static void parse_config_data(const char *config_source,
         exit(1);
     }
 
-    if (!xlu_cfg_get_string (config, "seclabel", &buf, 0)) {
+    if (!xlu_cfg_get_string (config, "init_seclabel", &buf, 0)) {
         e = libxl_flask_context_to_sid(ctx, (char *)buf, strlen(buf),
                                     &c_info->ssidref);
         if (e) {
             if (errno == ENOSYS) {
+                fprintf(stderr, "XSM Disabled: init_seclabel not supported\n");
+            } else {
+                fprintf(stderr, "Invalid init_seclabel: %s\n", buf);
+                exit(1);
+            }
+        }
+    }
+
+    if (!xlu_cfg_get_string (config, "seclabel", &buf, 0)) {
+        uint32_t ssidref;
+        e = libxl_flask_context_to_sid(ctx, (char *)buf, strlen(buf),
+                                    &ssidref);
+        if (e) {
+            if (errno == ENOSYS) {
                 fprintf(stderr, "XSM Disabled: seclabel not supported\n");
             } else {
                 fprintf(stderr, "Invalid seclabel: %s\n", buf);
                 exit(1);
             }
+        } else if (c_info->ssidref) {
+            b_info->exec_ssidref = ssidref;
+        } else {
+            c_info->ssidref = ssidref;
         }
     }
 
-- 
1.7.11.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 12 16:00:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Sep 2012 16:00:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TBpM8-0005Q0-8O; Wed, 12 Sep 2012 16:00:00 +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 1TBpM6-0005My-Vo
	for xen-devel@lists.xen.org; Wed, 12 Sep 2012 15:59:59 +0000
Received: from [85.158.138.51:27062] by server-4.bemta-3.messagelabs.com id
	9E/56-24831-E71B0505; Wed, 12 Sep 2012 15:59:58 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-16.tower-174.messagelabs.com!1347465597!30112715!1
X-Originating-IP: [63.239.67.9]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5369 invoked from network); 12 Sep 2012 15:59:57 -0000
Received: from emvm-gh1-uea08.nsa.gov (HELO nsa.gov) (63.239.67.9)
	by server-16.tower-174.messagelabs.com with SMTP;
	12 Sep 2012 15:59:57 -0000
X-TM-IMSS-Message-ID: <39e16b140010234e@nsa.gov>
Received: from tarius.tycho.ncsc.mil ([144.51.3.1]) by nsa.gov ([63.239.67.9])
	with ESMTP (TREND IMSS SMTP Service 7.1) id 39e16b140010234e ;
	Wed, 12 Sep 2012 11:59:48 -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 q8CFxoOT006669; 
	Wed, 12 Sep 2012 11:59:56 -0400
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xen.org
Date: Wed, 12 Sep 2012 11:59:43 -0400
Message-Id: <1347465586-20009-20-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.11.4
In-Reply-To: <1347465586-20009-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1347465586-20009-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Tim Deegan <tim@xen.org>, dgdegra@tycho.nsa.gov, Keir Fraser <keir@xen.org>,
	Jan Beulich <jbeulich@suse.com>
Subject: [Xen-devel] [PATCH 19/22] arch/x86: check remote MMIO remap
	permissions
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 domain is mapping pages from a different pg_owner domain, the
iomem_access checks are currently only applied to the pg_owner domain,
potentially allowing the current domain to bypass its more restrictive
iomem_access policy using another domain that it has access to.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Cc: Keir Fraser <keir@xen.org>
Cc: Jan Beulich <jbeulich@suse.com>
Cc: Tim Deegan <tim@xen.org>
---
 xen/arch/x86/mm.c | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
index 5c6ea2d..c0c2bf3 100644
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -754,6 +754,18 @@ get_page_from_l1e(
             return -EINVAL;
         }
 
+        if ( pg_owner != curr->domain &&
+             !iomem_access_permitted(curr->domain, mfn, mfn) )
+        {
+            if ( mfn != (PADDR_MASK >> PAGE_SHIFT) ) /* INVALID_MFN? */
+            {
+                MEM_LOG("Domain %u attempted to map I/O space %08lx in domain %u",
+                        curr->domain->domain_id, mfn, pg_owner->domain_id);
+                return -EPERM;
+            }
+            return -EINVAL;
+        }
+
         if ( !(l1f & _PAGE_RW) ||
              !rangeset_contains_singleton(mmio_ro_ranges, mfn) )
             return 0;
-- 
1.7.11.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 12 16:00:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Sep 2012 16:00:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TBpM9-0005R3-7u; Wed, 12 Sep 2012 16:00:01 +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 1TBpM7-0005My-Kx
	for xen-devel@lists.xen.org; Wed, 12 Sep 2012 15:59:59 +0000
Received: from [85.158.138.51:7163] by server-4.bemta-3.messagelabs.com id
	50/66-24831-E71B0505; Wed, 12 Sep 2012 15:59:58 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-3.tower-174.messagelabs.com!1347465597!22112236!1
X-Originating-IP: [63.239.67.9]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10694 invoked from network); 12 Sep 2012 15:59:57 -0000
Received: from emvm-gh1-uea08.nsa.gov (HELO nsa.gov) (63.239.67.9)
	by server-3.tower-174.messagelabs.com with SMTP;
	12 Sep 2012 15:59:57 -0000
X-TM-IMSS-Message-ID: <39e16a2a0010234d@nsa.gov>
Received: from tarius.tycho.ncsc.mil ([144.51.3.1]) by nsa.gov ([63.239.67.9])
	with ESMTP (TREND IMSS SMTP Service 7.1) id 39e16a2a0010234d ;
	Wed, 12 Sep 2012 11:59:47 -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 q8CFxoOS006669; 
	Wed, 12 Sep 2012 11:59:55 -0400
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xen.org
Date: Wed, 12 Sep 2012 11:59:42 -0400
Message-Id: <1347465586-20009-19-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.11.4
In-Reply-To: <1347465586-20009-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1347465586-20009-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Tim Deegan <tim@xen.org>, dgdegra@tycho.nsa.gov, Keir Fraser <keir@xen.org>,
	Jan Beulich <jbeulich@suse.com>
Subject: [Xen-devel] [PATCH 18/22] arch/x86: Add missing mem_sharing XSM
	hooks
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This patch adds splits up the mem_sharing and mem_event XSM hooks to
better cover what the code is doing. It also completes the support for
arch-specific domctls in FLASK.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Cc: Keir Fraser <keir@xen.org>
Cc: Jan Beulich <jbeulich@suse.com>
Cc: Tim Deegan <tim@xen.org>
---
 tools/flask/policy/policy/flask/access_vectors |  1 +
 xen/arch/x86/domctl.c                          |  8 ++---
 xen/arch/x86/mm/mem_event.c                    | 45 +++++++++-----------------
 xen/arch/x86/mm/mem_sharing.c                  | 25 +++++++++++---
 xen/include/asm-x86/mem_event.h                |  1 -
 xen/include/xsm/dummy.h                        | 23 ++++++++++++-
 xen/include/xsm/xsm.h                          | 24 ++++++++++++--
 xen/xsm/dummy.c                                |  5 ++-
 xen/xsm/flask/hooks.c                          | 25 ++++++++++++--
 xen/xsm/flask/include/av_perm_to_string.h      |  1 +
 xen/xsm/flask/include/av_permissions.h         |  1 +
 11 files changed, 113 insertions(+), 46 deletions(-)

diff --git a/tools/flask/policy/policy/flask/access_vectors b/tools/flask/policy/policy/flask/access_vectors
index ea65e45..45ac437 100644
--- a/tools/flask/policy/policy/flask/access_vectors
+++ b/tools/flask/policy/policy/flask/access_vectors
@@ -102,6 +102,7 @@ class hvm
     mem_sharing
     audit_p2m
     send_irq
+    share_mem
 }
 
 class event
diff --git a/xen/arch/x86/domctl.c b/xen/arch/x86/domctl.c
index a0ecd95..4a188e5 100644
--- a/xen/arch/x86/domctl.c
+++ b/xen/arch/x86/domctl.c
@@ -1449,10 +1449,8 @@ long arch_do_domctl(
         d = rcu_lock_domain_by_id(domctl->domain);
         if ( d != NULL )
         {
-            ret = xsm_mem_event(d);
-            if ( !ret )
-                ret = mem_event_domctl(d, &domctl->u.mem_event_op,
-                                       guest_handle_cast(u_domctl, void));
+            ret = mem_event_domctl(d, &domctl->u.mem_event_op,
+                                   guest_handle_cast(u_domctl, void));
             rcu_unlock_domain(d);
             copy_to_guest(u_domctl, domctl, 1);
         } 
@@ -1508,7 +1506,7 @@ long arch_do_domctl(
         d = rcu_lock_domain_by_id(domctl->domain);
         if ( d != NULL )
         {
-            ret = xsm_mem_event(d);
+            ret = xsm_mem_event_setup(d);
             if ( !ret ) {
                 p2m = p2m_get_hostp2m(d);
                 p2m->access_required = domctl->u.access_required.access_required;
diff --git a/xen/arch/x86/mm/mem_event.c b/xen/arch/x86/mm/mem_event.c
index d728889..d574541 100644
--- a/xen/arch/x86/mm/mem_event.c
+++ b/xen/arch/x86/mm/mem_event.c
@@ -29,6 +29,7 @@
 #include <asm/mem_paging.h>
 #include <asm/mem_access.h>
 #include <asm/mem_sharing.h>
+#include <xsm/xsm.h>
 
 /* for public/io/ring.h macros */
 #define xen_mb()   mb()
@@ -439,34 +440,22 @@ static void mem_sharing_notification(struct vcpu *v, unsigned int port)
         mem_sharing_sharing_resume(v->domain);
 }
 
-struct domain *get_mem_event_op_target(uint32_t domain, int *rc)
-{
-    struct domain *d;
-
-    /* Get the target domain */
-    *rc = rcu_lock_remote_target_domain_by_id(domain, &d);
-    if ( *rc != 0 )
-        return NULL;
-
-    /* Not dying? */
-    if ( d->is_dying )
-    {
-        rcu_unlock_domain(d);
-        *rc = -EINVAL;
-        return NULL;
-    }
-    
-    return d;
-}
-
 int do_mem_event_op(int op, uint32_t domain, void *arg)
 {
     int ret;
     struct domain *d;
 
-    d = get_mem_event_op_target(domain, &ret);
+    d = rcu_lock_domain_by_any_id(domain);
     if ( !d )
-        return ret;
+        return -ESRCH;
+
+    ret = -EINVAL;
+    if ( d->is_dying || d == current->domain )
+        goto out;
+
+    ret = xsm_mem_event_op(d, op);
+    if ( ret )
+        goto out;
 
     switch (op)
     {
@@ -483,6 +472,7 @@ int do_mem_event_op(int op, uint32_t domain, void *arg)
             ret = -ENOSYS;
     }
 
+ out:
     rcu_unlock_domain(d);
     return ret;
 }
@@ -516,6 +506,10 @@ int mem_event_domctl(struct domain *d, xen_domctl_mem_event_op_t *mec,
 {
     int rc;
 
+    rc = xsm_mem_event_control(d, mec->mode, mec->op);
+    if ( rc )
+        return rc;
+
     if ( unlikely(d == current->domain) )
     {
         gdprintk(XENLOG_INFO, "Tried to do a memory event op on itself.\n");
@@ -537,13 +531,6 @@ int mem_event_domctl(struct domain *d, xen_domctl_mem_event_op_t *mec,
         return -EINVAL;
     }
 
-    /* TODO: XSM hook */
-#if 0
-    rc = xsm_mem_event_control(d, mec->op);
-    if ( rc )
-        return rc;
-#endif
-
     rc = -ENOSYS;
 
     switch ( mec->mode )
diff --git a/xen/arch/x86/mm/mem_sharing.c b/xen/arch/x86/mm/mem_sharing.c
index 5103285..eff8ae5 100644
--- a/xen/arch/x86/mm/mem_sharing.c
+++ b/xen/arch/x86/mm/mem_sharing.c
@@ -34,6 +34,7 @@
 #include <asm/atomic.h>
 #include <xen/rcupdate.h>
 #include <asm/event.h>
+#include <xsm/xsm.h>
 
 #include "mm-locks.h"
 
@@ -1345,11 +1346,19 @@ int mem_sharing_memop(struct domain *d, xen_mem_sharing_op_t *mec)
             if ( !mem_sharing_enabled(d) )
                 return -EINVAL;
 
-            cd = get_mem_event_op_target(mec->u.share.client_domain, &rc);
+            cd = rcu_lock_domain_by_any_id(mec->u.share.client_domain);
             if ( !cd )
+                return -ESRCH;
+
+            rc = xsm_mem_sharing_op(d, cd, mec->op);
+            if ( rc )
+            {
+                rcu_unlock_domain(cd);
                 return rc;
+            }
 
-            if ( !mem_sharing_enabled(cd) )
+            if ( cd == current->domain || cd->is_dying ||
+                 !mem_sharing_enabled(cd) )
             {
                 rcu_unlock_domain(cd);
                 return -EINVAL;
@@ -1401,11 +1410,19 @@ int mem_sharing_memop(struct domain *d, xen_mem_sharing_op_t *mec)
             if ( !mem_sharing_enabled(d) )
                 return -EINVAL;
 
-            cd = get_mem_event_op_target(mec->u.share.client_domain, &rc);
+            cd = rcu_lock_domain_by_any_id(mec->u.share.client_domain);
             if ( !cd )
+                return -ESRCH;
+
+            rc = xsm_mem_sharing_op(d, cd, mec->op);
+            if ( rc )
+            {
+                rcu_unlock_domain(cd);
                 return rc;
+            }
 
-            if ( !mem_sharing_enabled(cd) )
+            if ( cd == current->domain || cd->is_dying ||
+                 !mem_sharing_enabled(cd) )
             {
                 rcu_unlock_domain(cd);
                 return -EINVAL;
diff --git a/xen/include/asm-x86/mem_event.h b/xen/include/asm-x86/mem_event.h
index 23d71c1..448be4f 100644
--- a/xen/include/asm-x86/mem_event.h
+++ b/xen/include/asm-x86/mem_event.h
@@ -62,7 +62,6 @@ void mem_event_put_request(struct domain *d, struct mem_event_domain *med,
 int mem_event_get_response(struct domain *d, struct mem_event_domain *med,
                            mem_event_response_t *rsp);
 
-struct domain *get_mem_event_op_target(uint32_t domain, int *rc);
 int do_mem_event_op(int op, uint32_t domain, void *arg);
 int mem_event_domctl(struct domain *d, xen_domctl_mem_event_op_t *mec,
                      XEN_GUEST_HANDLE(void) u_domctl);
diff --git a/xen/include/xsm/dummy.h b/xen/include/xsm/dummy.h
index a9784f5..1760cd9 100644
--- a/xen/include/xsm/dummy.h
+++ b/xen/include/xsm/dummy.h
@@ -551,16 +551,37 @@ static XSM_DEFAULT(int, hvm_inject_msi) (struct domain *d)
     return 0;
 }
 
-static XSM_DEFAULT(int, mem_event) (struct domain *d)
+static XSM_DEFAULT(int, mem_event_setup) (struct domain *d)
 {
     return 0;
 }
 
+static XSM_DEFAULT(int, mem_event_control) (struct domain *d, int mode, int op)
+{
+    if ( !IS_PRIV(current->domain) )
+        return -EPERM;
+    return 0;
+}
+
+static XSM_DEFAULT(int, mem_event_op) (struct domain *d, int op)
+{
+    if ( !IS_PRIV_FOR(current->domain, d) )
+        return -EPERM;
+    return 0;
+}
+
 static XSM_DEFAULT(int, mem_sharing) (struct domain *d)
 {
     return 0;
 }
 
+static XSM_DEFAULT(int, mem_sharing_op) (struct domain *d, struct domain *cd, int op)
+{
+    if ( !IS_PRIV_FOR(current->domain, cd) )
+        return -EPERM;
+    return 0;
+}
+
 static XSM_DEFAULT(int, apic) (struct domain *d, int cmd)
 {
     if ( !IS_PRIV(d) )
diff --git a/xen/include/xsm/xsm.h b/xen/include/xsm/xsm.h
index ef3329f..c2c1efa 100644
--- a/xen/include/xsm/xsm.h
+++ b/xen/include/xsm/xsm.h
@@ -151,8 +151,11 @@ struct xsm_operations {
     int (*hvm_set_isa_irq_level) (struct domain *d);
     int (*hvm_set_pci_link_route) (struct domain *d);
     int (*hvm_inject_msi) (struct domain *d);
-    int (*mem_event) (struct domain *d);
+    int (*mem_event_setup) (struct domain *d);
+    int (*mem_event_control) (struct domain *d, int mode, int op);
+    int (*mem_event_op) (struct domain *d, int op);
     int (*mem_sharing) (struct domain *d);
+    int (*mem_sharing_op) (struct domain *d, struct domain *cd, int op);
     int (*apic) (struct domain *d, int cmd);
     int (*xen_settime) (void);
     int (*memtype) (uint32_t access);
@@ -663,9 +666,19 @@ static inline int xsm_hvm_inject_msi (struct domain *d)
     return xsm_ops->hvm_inject_msi(d);
 }
 
-static inline int xsm_mem_event (struct domain *d)
+static inline int xsm_mem_event_setup (struct domain *d)
 {
-    return xsm_ops->mem_event(d);
+    return xsm_ops->mem_event_setup(d);
+}
+
+static inline int xsm_mem_event_control (struct domain *d, int mode, int op)
+{
+    return xsm_ops->mem_event_control(d, mode, op);
+}
+
+static inline int xsm_mem_event_op (struct domain *d, int op)
+{
+    return xsm_ops->mem_event_op(d, op);
 }
 
 static inline int xsm_mem_sharing (struct domain *d)
@@ -673,6 +686,11 @@ static inline int xsm_mem_sharing (struct domain *d)
     return xsm_ops->mem_sharing(d);
 }
 
+static inline int xsm_mem_sharing_op (struct domain *d, struct domain *cd, int op)
+{
+    return xsm_ops->mem_sharing_op(d, cd, op);
+}
+
 static inline int xsm_apic (struct domain *d, int cmd)
 {
     return xsm_ops->apic(d, cmd);
diff --git a/xen/xsm/dummy.c b/xen/xsm/dummy.c
index c76212d..c82c464 100644
--- a/xen/xsm/dummy.c
+++ b/xen/xsm/dummy.c
@@ -135,8 +135,11 @@ void xsm_fixup_ops (struct xsm_operations *ops)
     set_to_dummy_if_null(ops, hvm_set_isa_irq_level);
     set_to_dummy_if_null(ops, hvm_set_pci_link_route);
     set_to_dummy_if_null(ops, hvm_inject_msi);
-    set_to_dummy_if_null(ops, mem_event);
+    set_to_dummy_if_null(ops, mem_event_setup);
+    set_to_dummy_if_null(ops, mem_event_control);
+    set_to_dummy_if_null(ops, mem_event_op);
     set_to_dummy_if_null(ops, mem_sharing);
+    set_to_dummy_if_null(ops, mem_sharing_op);
     set_to_dummy_if_null(ops, apic);
     set_to_dummy_if_null(ops, xen_settime);
     set_to_dummy_if_null(ops, memtype);
diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
index 421087f..f993696 100644
--- a/xen/xsm/flask/hooks.c
+++ b/xen/xsm/flask/hooks.c
@@ -1275,7 +1275,17 @@ static int flask_hvm_inject_msi(struct domain *d)
     return current_has_perm(d, SECCLASS_HVM, HVM__SEND_IRQ);
 }
 
-static int flask_mem_event(struct domain *d)
+static int flask_mem_event_setup(struct domain *d)
+{
+    return current_has_perm(d, SECCLASS_HVM, HVM__MEM_EVENT);
+}
+
+static int flask_mem_event_control(struct domain *d, int mode, int op)
+{
+    return current_has_perm(d, SECCLASS_HVM, HVM__MEM_EVENT);
+}
+
+static int flask_mem_event_op(struct domain *d, int op)
 {
     return current_has_perm(d, SECCLASS_HVM, HVM__MEM_EVENT);
 }
@@ -1285,6 +1295,14 @@ static int flask_mem_sharing(struct domain *d)
     return current_has_perm(d, SECCLASS_HVM, HVM__MEM_SHARING);
 }
 
+static int flask_mem_sharing_op(struct domain *d, struct domain *cd, int op)
+{
+    int rc = current_has_perm(cd, SECCLASS_HVM, HVM__MEM_SHARING);
+    if ( rc )
+        return rc;
+    return domain_has_perm(d, cd, SECCLASS_HVM, HVM__SHARE_MEM);
+}
+
 static int flask_apic(struct domain *d, int cmd)
 {
     u32 perm;
@@ -1734,8 +1752,11 @@ static struct xsm_operations flask_ops = {
     .hvm_set_isa_irq_level = flask_hvm_set_isa_irq_level,
     .hvm_set_pci_link_route = flask_hvm_set_pci_link_route,
     .hvm_inject_msi = flask_hvm_inject_msi,
-    .mem_event = flask_mem_event,
+    .mem_event_setup = flask_mem_event_setup,
+    .mem_event_control = flask_mem_event_control,
+    .mem_event_op = flask_mem_event_op,
     .mem_sharing = flask_mem_sharing,
+    .mem_sharing_op = flask_mem_sharing_op,
     .apic = flask_apic,
     .xen_settime = flask_xen_settime,
     .memtype = flask_memtype,
diff --git a/xen/xsm/flask/include/av_perm_to_string.h b/xen/xsm/flask/include/av_perm_to_string.h
index 894910c..186f1fa 100644
--- a/xen/xsm/flask/include/av_perm_to_string.h
+++ b/xen/xsm/flask/include/av_perm_to_string.h
@@ -84,6 +84,7 @@
    S_(SECCLASS_HVM, HVM__MEM_SHARING, "mem_sharing")
    S_(SECCLASS_HVM, HVM__AUDIT_P2M, "audit_p2m")
    S_(SECCLASS_HVM, HVM__SEND_IRQ, "send_irq")
+   S_(SECCLASS_HVM, HVM__SHARE_MEM, "share_mem")
    S_(SECCLASS_EVENT, EVENT__BIND, "bind")
    S_(SECCLASS_EVENT, EVENT__SEND, "send")
    S_(SECCLASS_EVENT, EVENT__STATUS, "status")
diff --git a/xen/xsm/flask/include/av_permissions.h b/xen/xsm/flask/include/av_permissions.h
index 1bdb515..b3831f6 100644
--- a/xen/xsm/flask/include/av_permissions.h
+++ b/xen/xsm/flask/include/av_permissions.h
@@ -87,6 +87,7 @@
 #define HVM__MEM_SHARING                          0x00001000UL
 #define HVM__AUDIT_P2M                            0x00002000UL
 #define HVM__SEND_IRQ                             0x00004000UL
+#define HVM__SHARE_MEM                            0x00008000UL
 
 #define EVENT__BIND                               0x00000001UL
 #define EVENT__SEND                               0x00000002UL
-- 
1.7.11.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 12 16:00:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Sep 2012 16:00:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TBpMF-0005ot-DQ; Wed, 12 Sep 2012 16:00:07 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1TBpMC-0005Oy-GF
	for xen-devel@lists.xen.org; Wed, 12 Sep 2012 16:00:04 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-7.tower-27.messagelabs.com!1347465597!3056364!1
X-Originating-IP: [63.239.67.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4903 invoked from network); 12 Sep 2012 15:59:58 -0000
Received: from emvm-gh1-uea09.nsa.gov (HELO nsa.gov) (63.239.67.10)
	by server-7.tower-27.messagelabs.com with SMTP;
	12 Sep 2012 15:59:58 -0000
X-TM-IMSS-Message-ID: <39e12a5d001083e1@nsa.gov>
Received: from tarius.tycho.ncsc.mil ([144.51.3.1]) by nsa.gov
	([63.239.67.10]) with ESMTP (TREND IMSS SMTP Service 7.1) id
	39e12a5d001083e1 ; Wed, 12 Sep 2012 12:02:04 -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 q8CFxoOW006669; 
	Wed, 12 Sep 2012 11:59:56 -0400
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xen.org
Date: Wed, 12 Sep 2012 11:59:46 -0400
Message-Id: <1347465586-20009-23-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.11.4
In-Reply-To: <1347465586-20009-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1347465586-20009-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: dgdegra@tycho.nsa.gov, Dan Magenheimer <dan.magenheimer@oracle.com>
Subject: [Xen-devel] [PATCH 22/22] tmem: add XSM hooks
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This adds a pair of XSM hooks for tmem operations: xsm_tmem_op which
controls any use of tmem, and xsm_tmem_control which allows use of the
TMEM_CONTROL operations. By default, all domains can use tmem while only
IS_PRIV domains can use control operations.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Cc: Dan Magenheimer <dan.magenheimer@oracle.com>
---
 tools/flask/policy/policy/flask/access_vectors |  2 ++
 xen/common/tmem.c                              |  3 +++
 xen/include/xen/tmem_xen.h                     |  8 +++++++-
 xen/include/xsm/dummy.h                        | 12 ++++++++++++
 xen/include/xsm/xsm.h                          | 12 ++++++++++++
 xen/xsm/dummy.c                                |  2 ++
 xen/xsm/flask/hooks.c                          | 12 ++++++++++++
 xen/xsm/flask/include/av_perm_to_string.h      |  2 ++
 xen/xsm/flask/include/av_permissions.h         |  2 ++
 9 files changed, 54 insertions(+), 1 deletion(-)

diff --git a/tools/flask/policy/policy/flask/access_vectors b/tools/flask/policy/policy/flask/access_vectors
index caf65d2..7a7e253 100644
--- a/tools/flask/policy/policy/flask/access_vectors
+++ b/tools/flask/policy/policy/flask/access_vectors
@@ -35,6 +35,8 @@ class xen
 	lockprof
 	cpupool_op
 	sched_op
+	tmem_op
+	tmem_control
 }
 
 class domain
diff --git a/xen/common/tmem.c b/xen/common/tmem.c
index f4812b9..6d95296 100644
--- a/xen/common/tmem.c
+++ b/xen/common/tmem.c
@@ -2636,6 +2636,9 @@ EXPORT long do_tmem_op(tmem_cli_op_t uops)
     if ( !tmem_initialized )
         return -ENODEV;
 
+    if ( !tmh_current_permitted() )
+        return -EPERM;
+
     total_tmem_ops++;
 
     if ( tmh_lock_all )
diff --git a/xen/include/xen/tmem_xen.h b/xen/include/xen/tmem_xen.h
index 9492810..ae550af 100644
--- a/xen/include/xen/tmem_xen.h
+++ b/xen/include/xen/tmem_xen.h
@@ -16,6 +16,7 @@
 #include <xen/guest_access.h> /* copy_from_guest */
 #include <xen/hash.h> /* hash_long */
 #include <xen/domain_page.h> /* __map_domain_page */
+#include <xsm/xsm.h> /* xsm_tmem_control */
 #include <public/tmem.h>
 #ifdef CONFIG_COMPAT
 #include <compat/tmem.h>
@@ -326,9 +327,14 @@ static inline bool_t tmh_set_client_from_id(
     return rc;
 }
 
+static inline bool_t tmh_current_permitted(void)
+{
+    return !xsm_tmem_op();
+}
+
 static inline bool_t tmh_current_is_privileged(void)
 {
-    return IS_PRIV(current->domain);
+    return !xsm_tmem_control();
 }
 
 static inline uint8_t tmh_get_first_byte(pfp_t *pfp)
diff --git a/xen/include/xsm/dummy.h b/xen/include/xsm/dummy.h
index e5e8020..4ed010a 100644
--- a/xen/include/xsm/dummy.h
+++ b/xen/include/xsm/dummy.h
@@ -443,6 +443,18 @@ static XSM_DEFAULT(int, sched_op) (void)
     return 0;
 }
 
+static XSM_DEFAULT(int, tmem_op) (void)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, tmem_control) (void)
+{
+    if ( !IS_PRIV(current->domain) )
+        return -EPERM;
+    return 0;
+}
+
 static XSM_DEFAULT(long, __do_xsm_op)(XEN_GUEST_HANDLE(xsm_op_t) op)
 {
     return -ENOSYS;
diff --git a/xen/include/xsm/xsm.h b/xen/include/xsm/xsm.h
index 46d5cd6..d7ab92b 100644
--- a/xen/include/xsm/xsm.h
+++ b/xen/include/xsm/xsm.h
@@ -134,6 +134,8 @@ struct xsm_operations {
     int (*lockprof)(void);
     int (*cpupool_op)(void);
     int (*sched_op)(void);
+    int (*tmem_op)(void);
+    int (*tmem_control)(void);
 
     long (*__do_xsm_op) (XEN_GUEST_HANDLE(xsm_op_t) op);
 
@@ -610,6 +612,16 @@ static inline int xsm_sched_op(void)
     return xsm_ops->sched_op();
 }
 
+static inline int xsm_tmem_op(void)
+{
+    return xsm_ops->tmem_op();
+}
+
+static inline int xsm_tmem_control(void)
+{
+    return xsm_ops->tmem_control();
+}
+
 static inline long xsm___do_xsm_op (XEN_GUEST_HANDLE(xsm_op_t) op)
 {
     return xsm_ops->__do_xsm_op(op);
diff --git a/xen/xsm/dummy.c b/xen/xsm/dummy.c
index ddaf40b..e4fdfd7 100644
--- a/xen/xsm/dummy.c
+++ b/xen/xsm/dummy.c
@@ -120,6 +120,8 @@ void xsm_fixup_ops (struct xsm_operations *ops)
     set_to_dummy_if_null(ops, lockprof);
     set_to_dummy_if_null(ops, cpupool_op);
     set_to_dummy_if_null(ops, sched_op);
+    set_to_dummy_if_null(ops, tmem_op);
+    set_to_dummy_if_null(ops, tmem_control);
 
     set_to_dummy_if_null(ops, __do_xsm_op);
 
diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
index 2f33a9f..4553289 100644
--- a/xen/xsm/flask/hooks.c
+++ b/xen/xsm/flask/hooks.c
@@ -1077,6 +1077,16 @@ static inline int flask_sched_op(void)
     return domain_has_xen(current->domain, XEN__SCHED_OP);
 }
 
+static inline int flask_tmem_op(void)
+{
+    return domain_has_xen(current->domain, XEN__TMEM_OP);
+}
+
+static inline int flask_tmem_control(void)
+{
+    return domain_has_xen(current->domain, XEN__TMEM_CONTROL);
+}
+
 static int flask_perfcontrol(void)
 {
     return domain_has_xen(current->domain, XEN__PERFCONTROL);
@@ -1721,6 +1731,8 @@ static struct xsm_operations flask_ops = {
     .lockprof = flask_lockprof,
     .cpupool_op = flask_cpupool_op,
     .sched_op = flask_sched_op,
+    .tmem_op = flask_tmem_op,
+    .tmem_control = flask_tmem_control,
 
     .__do_xsm_op = do_flask_op,
 
diff --git a/xen/xsm/flask/include/av_perm_to_string.h b/xen/xsm/flask/include/av_perm_to_string.h
index 79d5939..c3f2370 100644
--- a/xen/xsm/flask/include/av_perm_to_string.h
+++ b/xen/xsm/flask/include/av_perm_to_string.h
@@ -29,6 +29,8 @@
    S_(SECCLASS_XEN, XEN__LOCKPROF, "lockprof")
    S_(SECCLASS_XEN, XEN__CPUPOOL_OP, "cpupool_op")
    S_(SECCLASS_XEN, XEN__SCHED_OP, "sched_op")
+   S_(SECCLASS_XEN, XEN__TMEM_OP, "tmem_op")
+   S_(SECCLASS_XEN, XEN__TMEM_CONTROL, "tmem_control")
    S_(SECCLASS_DOMAIN, DOMAIN__SETVCPUCONTEXT, "setvcpucontext")
    S_(SECCLASS_DOMAIN, DOMAIN__PAUSE, "pause")
    S_(SECCLASS_DOMAIN, DOMAIN__UNPAUSE, "unpause")
diff --git a/xen/xsm/flask/include/av_permissions.h b/xen/xsm/flask/include/av_permissions.h
index d982328..65302e8 100644
--- a/xen/xsm/flask/include/av_permissions.h
+++ b/xen/xsm/flask/include/av_permissions.h
@@ -29,6 +29,8 @@
 #define XEN__LOCKPROF                             0x08000000UL
 #define XEN__CPUPOOL_OP                           0x10000000UL
 #define XEN__SCHED_OP                             0x20000000UL
+#define XEN__TMEM_OP                              0x40000000UL
+#define XEN__TMEM_CONTROL                         0x80000000UL
 
 #define DOMAIN__SETVCPUCONTEXT                    0x00000001UL
 #define DOMAIN__PAUSE                             0x00000002UL
-- 
1.7.11.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 12 16:00:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Sep 2012 16:00:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TBpME-0005nC-Bq; Wed, 12 Sep 2012 16:00:06 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1TBpMB-0005O0-12
	for xen-devel@lists.xen.org; Wed, 12 Sep 2012 16:00:03 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-11.tower-27.messagelabs.com!1347465595!3815672!1
X-Originating-IP: [63.239.67.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5269 invoked from network); 12 Sep 2012 15:59:56 -0000
Received: from emvm-gh1-uea09.nsa.gov (HELO nsa.gov) (63.239.67.10)
	by server-11.tower-27.messagelabs.com with SMTP;
	12 Sep 2012 15:59:56 -0000
X-TM-IMSS-Message-ID: <39e12001001083d9@nsa.gov>
Received: from tarius.tycho.ncsc.mil ([144.51.3.1]) by nsa.gov
	([63.239.67.10]) with ESMTP (TREND IMSS SMTP Service 7.1) id
	39e12001001083d9 ; Wed, 12 Sep 2012 12:02:01 -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 q8CFxoON006669; 
	Wed, 12 Sep 2012 11:59:54 -0400
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xen.org
Date: Wed, 12 Sep 2012 11:59:37 -0400
Message-Id: <1347465586-20009-14-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.11.4
In-Reply-To: <1347465586-20009-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1347465586-20009-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: dgdegra@tycho.nsa.gov, Keir Fraser <keir@xen.org>,
	Jan Beulich <jbeulich@suse.com>
Subject: [Xen-devel] [PATCH 13/22] xen: lock target domain in do_domctl
	common code
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 almost all domctls need to lock the target domain, do this by
default instead of repeating it in each domctl. This is not currently
extended to the arch-specific domctls, but RCU locks are safe to take
recursively so this only causes duplicate but correct locking.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Cc: Keir Fraser <keir@xen.org>
Cc: Jan Beulich <jbeulich@suse.com>
---
 xen/common/domctl.c | 267 ++++++++++++----------------------------------------
 1 file changed, 58 insertions(+), 209 deletions(-)

diff --git a/xen/common/domctl.c b/xen/common/domctl.c
index d99ba67..76ced4f 100644
--- a/xen/common/domctl.c
+++ b/xen/common/domctl.c
@@ -243,6 +243,7 @@ long do_domctl(XEN_GUEST_HANDLE(xen_domctl_t) u_domctl)
 {
     long ret = 0;
     struct xen_domctl curop, *op = &curop;
+    struct domain *d;
 
     if ( copy_from_guest(op, u_domctl, 1) )
         return -EFAULT;
@@ -252,19 +253,28 @@ long do_domctl(XEN_GUEST_HANDLE(xen_domctl_t) u_domctl)
 
     switch ( op->cmd )
     {
+    case XEN_DOMCTL_createdomain:
+    case XEN_DOMCTL_getdomaininfo:
+        d = NULL;
+        break;
+    default:
+        d = rcu_lock_domain_by_id(op->domain);
+        if ( d == NULL )
+            return -ESRCH;
+    }
+
+    switch ( op->cmd )
+    {
     case XEN_DOMCTL_ioport_mapping:
     case XEN_DOMCTL_memory_mapping:
     case XEN_DOMCTL_bind_pt_irq:
     case XEN_DOMCTL_unbind_pt_irq: {
-        struct domain *d;
-        bool_t is_priv = IS_PRIV(current->domain);
-        if ( !is_priv && ((d = rcu_lock_domain_by_id(op->domain)) != NULL) )
+        bool_t is_priv = IS_PRIV_FOR(current->domain, d);
+        if ( !is_priv )
         {
-            is_priv = IS_PRIV_FOR(current->domain, d);
-            rcu_unlock_domain(d);
+            ret = -EPERM;
+            goto domctl_out_unlock;
         }
-        if ( !is_priv )
-            return -EPERM;
         break;
     }
     case XEN_DOMCTL_getdomaininfo:
@@ -276,15 +286,18 @@ long do_domctl(XEN_GUEST_HANDLE(xen_domctl_t) u_domctl)
     }
 
     if ( !domctl_lock_acquire() )
+    {
+        if ( d )
+            rcu_unlock_domain(d);
         return hypercall_create_continuation(
             __HYPERVISOR_domctl, "h", u_domctl);
+    }
 
     switch ( op->cmd )
     {
 
     case XEN_DOMCTL_setvcpucontext:
     {
-        struct domain *d = rcu_lock_domain_by_id(op->domain);
         vcpu_guest_context_u c = { .nat = NULL };
         unsigned int vcpu = op->u.vcpucontext.vcpu;
         struct vcpu *v;
@@ -338,77 +351,48 @@ long do_domctl(XEN_GUEST_HANDLE(xen_domctl_t) u_domctl)
 
     svc_out:
         free_vcpu_guest_context(c.nat);
-        rcu_unlock_domain(d);
     }
     break;
 
     case XEN_DOMCTL_pausedomain:
     {
-        struct domain *d = rcu_lock_domain_by_id(op->domain);
-        ret = -ESRCH;
-        if ( d != NULL )
-        {
-            ret = xsm_pausedomain(d);
-            if ( ret )
-                goto pausedomain_out;
+        ret = xsm_pausedomain(d);
+        if ( ret )
+            break;
 
-            ret = -EINVAL;
-            if ( d != current->domain )
-            {
-                domain_pause_by_systemcontroller(d);
-                ret = 0;
-            }
-        pausedomain_out:
-            rcu_unlock_domain(d);
+        ret = -EINVAL;
+        if ( d != current->domain )
+        {
+            domain_pause_by_systemcontroller(d);
+            ret = 0;
         }
     }
     break;
 
     case XEN_DOMCTL_unpausedomain:
     {
-        struct domain *d = rcu_lock_domain_by_id(op->domain);
-
-        ret = -ESRCH;
-        if ( d == NULL )
-            break;
-
         ret = xsm_unpausedomain(d);
         if ( ret )
-        {
-            rcu_unlock_domain(d);
             break;
-        }
 
         domain_unpause_by_systemcontroller(d);
-        rcu_unlock_domain(d);
         ret = 0;
     }
     break;
 
     case XEN_DOMCTL_resumedomain:
     {
-        struct domain *d = rcu_lock_domain_by_id(op->domain);
-
-        ret = -ESRCH;
-        if ( d == NULL )
-            break;
-
         ret = xsm_resumedomain(d);
         if ( ret )
-        {
-            rcu_unlock_domain(d);
             break;
-        }
 
         domain_resume(d);
-        rcu_unlock_domain(d);
         ret = 0;
     }
     break;
 
     case XEN_DOMCTL_createdomain:
     {
-        struct domain *d;
         domid_t        dom;
         static domid_t rover = 0;
         unsigned int domcr_flags;
@@ -458,6 +442,7 @@ long do_domctl(XEN_GUEST_HANDLE(xen_domctl_t) u_domctl)
         if ( IS_ERR(d) )
         {
             ret = PTR_ERR(d);
+            d = NULL;
             break;
         }
 
@@ -469,39 +454,28 @@ long do_domctl(XEN_GUEST_HANDLE(xen_domctl_t) u_domctl)
         op->domain = d->domain_id;
         if ( copy_to_guest(u_domctl, op, 1) )
             ret = -EFAULT;
+        d = NULL;
     }
     break;
 
     case XEN_DOMCTL_max_vcpus:
     {
-        struct domain *d;
         unsigned int i, max = op->u.max_vcpus.max, cpu;
         cpumask_t *online;
 
-        ret = -ESRCH;
-        if ( (d = rcu_lock_domain_by_id(op->domain)) == NULL )
-            break;
-
         ret = -EINVAL;
         if ( (d == current->domain) || /* no domain_pause() */
              (max > MAX_VIRT_CPUS) ||
              (is_hvm_domain(d) && (max > MAX_HVM_VCPUS)) )
-        {
-            rcu_unlock_domain(d);
             break;
-        }
 
         ret = xsm_max_vcpus(d);
         if ( ret )
-        {
-            rcu_unlock_domain(d);
             break;
-        }
 
         /* Until Xenoprof can dynamically grow its vcpu-s array... */
         if ( d->xenoprof )
         {
-            rcu_unlock_domain(d);
             ret = -EAGAIN;
             break;
         }
@@ -576,44 +550,31 @@ long do_domctl(XEN_GUEST_HANDLE(xen_domctl_t) u_domctl)
 
     maxvcpu_out_novcpulock:
         domain_unpause(d);
-        rcu_unlock_domain(d);
     }
     break;
 
     case XEN_DOMCTL_destroydomain:
     {
-        struct domain *d = rcu_lock_domain_by_id(op->domain);
-        ret = -ESRCH;
-        if ( d != NULL )
-        {
-            ret = xsm_destroydomain(d) ? : domain_kill(d);
-            rcu_unlock_domain(d);
-        }
+        ret = xsm_destroydomain(d) ? : domain_kill(d);
     }
     break;
 
     case XEN_DOMCTL_setvcpuaffinity:
     case XEN_DOMCTL_getvcpuaffinity:
     {
-        domid_t dom = op->domain;
-        struct domain *d = rcu_lock_domain_by_id(dom);
         struct vcpu *v;
 
-        ret = -ESRCH;
-        if ( d == NULL )
-            break;
-
         ret = xsm_vcpuaffinity(op->cmd, d);
         if ( ret )
-            goto vcpuaffinity_out;
+            break;
 
         ret = -EINVAL;
         if ( op->u.vcpuaffinity.vcpu >= d->max_vcpus )
-            goto vcpuaffinity_out;
+            break;
 
         ret = -ESRCH;
         if ( (v = d->vcpu[op->u.vcpuaffinity.vcpu]) == NULL )
-            goto vcpuaffinity_out;
+            break;
 
         if ( op->cmd == XEN_DOMCTL_setvcpuaffinity )
         {
@@ -632,36 +593,23 @@ long do_domctl(XEN_GUEST_HANDLE(xen_domctl_t) u_domctl)
             ret = cpumask_to_xenctl_cpumap(
                 &op->u.vcpuaffinity.cpumap, v->cpu_affinity);
         }
-
-    vcpuaffinity_out:
-        rcu_unlock_domain(d);
     }
     break;
 
     case XEN_DOMCTL_scheduler_op:
     {
-        struct domain *d;
-
-        ret = -ESRCH;
-        if ( (d = rcu_lock_domain_by_id(op->domain)) == NULL )
-            break;
-
         ret = xsm_scheduler(d);
         if ( ret )
-            goto scheduler_op_out;
+            break;
 
         ret = sched_adjust(d, &op->u.scheduler_op);
         if ( copy_to_guest(u_domctl, op, 1) )
             ret = -EFAULT;
-
-    scheduler_op_out:
-        rcu_unlock_domain(d);
     }
     break;
 
     case XEN_DOMCTL_getdomaininfo:
     { 
-        struct domain *d;
         domid_t dom = op->domain;
 
         rcu_read_lock(&domlist_read_lock);
@@ -689,19 +637,15 @@ long do_domctl(XEN_GUEST_HANDLE(xen_domctl_t) u_domctl)
 
     getdomaininfo_out:
         rcu_read_unlock(&domlist_read_lock);
+        d = NULL;
     }
     break;
 
     case XEN_DOMCTL_getvcpucontext:
     { 
         vcpu_guest_context_u c = { .nat = NULL };
-        struct domain       *d;
         struct vcpu         *v;
 
-        ret = -ESRCH;
-        if ( (d = rcu_lock_domain_by_id(op->domain)) == NULL )
-            break;
-
         ret = xsm_getvcpucontext(d);
         if ( ret )
             goto getvcpucontext_out;
@@ -750,31 +694,25 @@ long do_domctl(XEN_GUEST_HANDLE(xen_domctl_t) u_domctl)
 
     getvcpucontext_out:
         xfree(c.nat);
-        rcu_unlock_domain(d);
     }
     break;
 
     case XEN_DOMCTL_getvcpuinfo:
     { 
-        struct domain *d;
         struct vcpu   *v;
         struct vcpu_runstate_info runstate;
 
-        ret = -ESRCH;
-        if ( (d = rcu_lock_domain_by_id(op->domain)) == NULL )
-            break;
-
         ret = xsm_getvcpuinfo(d);
         if ( ret )
-            goto getvcpuinfo_out;
+            break;
 
         ret = -EINVAL;
         if ( op->u.getvcpuinfo.vcpu >= d->max_vcpus )
-            goto getvcpuinfo_out;
+            break;
 
         ret = -ESRCH;
         if ( (v = d->vcpu[op->u.getvcpuinfo.vcpu]) == NULL )
-            goto getvcpuinfo_out;
+            break;
 
         vcpu_runstate_get(v, &runstate);
 
@@ -787,25 +725,16 @@ long do_domctl(XEN_GUEST_HANDLE(xen_domctl_t) u_domctl)
 
         if ( copy_to_guest(u_domctl, op, 1) )
             ret = -EFAULT;
-
-    getvcpuinfo_out:
-        rcu_unlock_domain(d);
     }
     break;
 
     case XEN_DOMCTL_max_mem:
     {
-        struct domain *d;
         unsigned long new_max;
 
-        ret = -ESRCH;
-        d = rcu_lock_domain_by_id(op->domain);
-        if ( d == NULL )
-            break;
-
         ret = xsm_setdomainmaxmem(d);
         if ( ret )
-            goto max_mem_out;
+            break;
 
         ret = -EINVAL;
         new_max = op->u.max_mem.max_memkb >> (PAGE_SHIFT-10);
@@ -819,77 +748,43 @@ long do_domctl(XEN_GUEST_HANDLE(xen_domctl_t) u_domctl)
         d->max_pages = new_max;
         ret = 0;
         spin_unlock(&d->page_alloc_lock);
-
-    max_mem_out:
-        rcu_unlock_domain(d);
     }
     break;
 
     case XEN_DOMCTL_setdomainhandle:
     {
-        struct domain *d;
-
-        ret = -ESRCH;
-        d = rcu_lock_domain_by_id(op->domain);
-        if ( d == NULL )
-            break;
-
         ret = xsm_setdomainhandle(d);
         if ( ret )
-        {
-            rcu_unlock_domain(d);
             break;
-        }
 
         memcpy(d->handle, op->u.setdomainhandle.handle,
                sizeof(xen_domain_handle_t));
-        rcu_unlock_domain(d);
         ret = 0;
     }
     break;
 
     case XEN_DOMCTL_setdebugging:
     {
-        struct domain *d;
-
-        ret = -ESRCH;
-        d = rcu_lock_domain_by_id(op->domain);
-        if ( d == NULL )
-            break;
-
         ret = -EINVAL;
         if ( d == current->domain ) /* no domain_pause() */
-        {
-            rcu_unlock_domain(d);
             break;
-        }
 
         ret = xsm_setdebugging(d);
         if ( ret )
-        {
-            rcu_unlock_domain(d);
             break;
-        }
 
         domain_pause(d);
         d->debugger_attached = !!op->u.setdebugging.enable;
         domain_unpause(d); /* causes guest to latch new status */
-        rcu_unlock_domain(d);
         ret = 0;
     }
     break;
 
     case XEN_DOMCTL_irq_permission:
     {
-        struct domain *d;
         unsigned int pirq = op->u.irq_permission.pirq;
         int allow = op->u.irq_permission.allow_access;
 
-        ret = -ESRCH;
-        d = rcu_lock_domain_by_id(op->domain);
-        if ( d == NULL )
-            break;
-
         if ( pirq >= d->nr_pirqs )
             ret = -EINVAL;
         else if ( xsm_irq_permission(d, pirq, allow) )
@@ -898,14 +793,11 @@ long do_domctl(XEN_GUEST_HANDLE(xen_domctl_t) u_domctl)
             ret = irq_permit_access(d, pirq);
         else
             ret = irq_deny_access(d, pirq);
-
-        rcu_unlock_domain(d);
     }
     break;
 
     case XEN_DOMCTL_iomem_permission:
     {
-        struct domain *d;
         unsigned long mfn = op->u.iomem_permission.first_mfn;
         unsigned long nr_mfns = op->u.iomem_permission.nr_mfns;
         int allow = op->u.iomem_permission.allow_access;
@@ -914,125 +806,78 @@ long do_domctl(XEN_GUEST_HANDLE(xen_domctl_t) u_domctl)
         if ( (mfn + nr_mfns - 1) < mfn ) /* wrap? */
             break;
 
-        ret = -ESRCH;
-        d = rcu_lock_domain_by_id(op->domain);
-        if ( d == NULL )
-            break;
-
         if ( xsm_iomem_permission(d, mfn, mfn + nr_mfns - 1, allow) )
             ret = -EPERM;
         else if ( allow )
             ret = iomem_permit_access(d, mfn, mfn + nr_mfns - 1);
         else
             ret = iomem_deny_access(d, mfn, mfn + nr_mfns - 1);
-
-        rcu_unlock_domain(d);
     }
     break;
 
     case XEN_DOMCTL_settimeoffset:
     {
-        struct domain *d;
-
-        ret = -ESRCH;
-        d = rcu_lock_domain_by_id(op->domain);
-        if ( d == NULL )
-            break;
-
         ret = xsm_domain_settime(d);
         if ( ret )
-        {
-            rcu_unlock_domain(d);
             break;
-        }
 
         domain_set_time_offset(d, op->u.settimeoffset.time_offset_seconds);
-        rcu_unlock_domain(d);
         ret = 0;
     }
     break;
 
     case XEN_DOMCTL_set_target:
     {
-        struct domain *d, *e;
-
-        ret = -ESRCH;
-        d = rcu_lock_domain_by_id(op->domain);
-        if ( d == NULL )
-            break;
+        struct domain *e;
 
         ret = -ESRCH;
         e = get_domain_by_id(op->u.set_target.target);
         if ( e == NULL )
-            goto set_target_out;
+            break;
 
         ret = -EINVAL;
         if ( (d == e) || (d->target != NULL) )
         {
             put_domain(e);
-            goto set_target_out;
+            break;
         }
 
         ret = xsm_set_target(d, e);
         if ( ret ) {
             put_domain(e);
-            goto set_target_out;            
+            break;
         }
 
         /* Hold reference on @e until we destroy @d. */
         d->target = e;
 
         ret = 0;
-
-    set_target_out:
-        rcu_unlock_domain(d);
     }
     break;
 
     case XEN_DOMCTL_subscribe:
     {
-        struct domain *d;
-
-        ret = -ESRCH;
-        d = rcu_lock_domain_by_id(op->domain);
-        if ( d != NULL )
-        {
-            ret = xsm_domctl(d, op->cmd);
-            if ( !ret )
-                d->suspend_evtchn = op->u.subscribe.port;
-            rcu_unlock_domain(d);
-        }
+        ret = xsm_domctl(d, op->cmd);
+        if ( !ret )
+            d->suspend_evtchn = op->u.subscribe.port;
     }
     break;
 
     case XEN_DOMCTL_disable_migrate:
     {
-        struct domain *d;
-        ret = -ESRCH;
-        if ( (d = rcu_lock_domain_by_id(op->domain)) != NULL )
-        {
-            ret = xsm_domctl(d, op->cmd);
-            if ( !ret )
-                d->disable_migrate = op->u.disable_migrate.disable;
-            rcu_unlock_domain(d);
-        }
+        ret = xsm_domctl(d, op->cmd);
+        if ( !ret )
+            d->disable_migrate = op->u.disable_migrate.disable;
     }
     break;
 
     case XEN_DOMCTL_set_virq_handler:
     {
-        struct domain *d;
         uint32_t virq = op->u.set_virq_handler.virq;
 
-        ret = -ESRCH;
-        d = rcu_lock_domain_by_id(op->domain);
-        if ( d != NULL )
-        {
-            ret = xsm_set_virq_handler(d, virq);
-            if ( !ret )
-                ret = set_global_virq_handler(d, virq);
-            rcu_unlock_domain(d);
-        }
+        ret = xsm_set_virq_handler(d, virq);
+        if ( !ret )
+            ret = set_global_virq_handler(d, virq);
     }
     break;
 
@@ -1043,6 +888,10 @@ long do_domctl(XEN_GUEST_HANDLE(xen_domctl_t) u_domctl)
 
     domctl_lock_release();
 
+ domctl_out_unlock:
+    if ( d )
+        rcu_unlock_domain(d);
+
     return ret;
 }
 
-- 
1.7.11.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 12 16:00:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Sep 2012 16:00:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TBpM9-0005R3-7u; Wed, 12 Sep 2012 16:00:01 +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 1TBpM7-0005My-Kx
	for xen-devel@lists.xen.org; Wed, 12 Sep 2012 15:59:59 +0000
Received: from [85.158.138.51:7163] by server-4.bemta-3.messagelabs.com id
	50/66-24831-E71B0505; Wed, 12 Sep 2012 15:59:58 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-3.tower-174.messagelabs.com!1347465597!22112236!1
X-Originating-IP: [63.239.67.9]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10694 invoked from network); 12 Sep 2012 15:59:57 -0000
Received: from emvm-gh1-uea08.nsa.gov (HELO nsa.gov) (63.239.67.9)
	by server-3.tower-174.messagelabs.com with SMTP;
	12 Sep 2012 15:59:57 -0000
X-TM-IMSS-Message-ID: <39e16a2a0010234d@nsa.gov>
Received: from tarius.tycho.ncsc.mil ([144.51.3.1]) by nsa.gov ([63.239.67.9])
	with ESMTP (TREND IMSS SMTP Service 7.1) id 39e16a2a0010234d ;
	Wed, 12 Sep 2012 11:59:47 -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 q8CFxoOS006669; 
	Wed, 12 Sep 2012 11:59:55 -0400
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xen.org
Date: Wed, 12 Sep 2012 11:59:42 -0400
Message-Id: <1347465586-20009-19-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.11.4
In-Reply-To: <1347465586-20009-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1347465586-20009-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Tim Deegan <tim@xen.org>, dgdegra@tycho.nsa.gov, Keir Fraser <keir@xen.org>,
	Jan Beulich <jbeulich@suse.com>
Subject: [Xen-devel] [PATCH 18/22] arch/x86: Add missing mem_sharing XSM
	hooks
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This patch adds splits up the mem_sharing and mem_event XSM hooks to
better cover what the code is doing. It also completes the support for
arch-specific domctls in FLASK.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Cc: Keir Fraser <keir@xen.org>
Cc: Jan Beulich <jbeulich@suse.com>
Cc: Tim Deegan <tim@xen.org>
---
 tools/flask/policy/policy/flask/access_vectors |  1 +
 xen/arch/x86/domctl.c                          |  8 ++---
 xen/arch/x86/mm/mem_event.c                    | 45 +++++++++-----------------
 xen/arch/x86/mm/mem_sharing.c                  | 25 +++++++++++---
 xen/include/asm-x86/mem_event.h                |  1 -
 xen/include/xsm/dummy.h                        | 23 ++++++++++++-
 xen/include/xsm/xsm.h                          | 24 ++++++++++++--
 xen/xsm/dummy.c                                |  5 ++-
 xen/xsm/flask/hooks.c                          | 25 ++++++++++++--
 xen/xsm/flask/include/av_perm_to_string.h      |  1 +
 xen/xsm/flask/include/av_permissions.h         |  1 +
 11 files changed, 113 insertions(+), 46 deletions(-)

diff --git a/tools/flask/policy/policy/flask/access_vectors b/tools/flask/policy/policy/flask/access_vectors
index ea65e45..45ac437 100644
--- a/tools/flask/policy/policy/flask/access_vectors
+++ b/tools/flask/policy/policy/flask/access_vectors
@@ -102,6 +102,7 @@ class hvm
     mem_sharing
     audit_p2m
     send_irq
+    share_mem
 }
 
 class event
diff --git a/xen/arch/x86/domctl.c b/xen/arch/x86/domctl.c
index a0ecd95..4a188e5 100644
--- a/xen/arch/x86/domctl.c
+++ b/xen/arch/x86/domctl.c
@@ -1449,10 +1449,8 @@ long arch_do_domctl(
         d = rcu_lock_domain_by_id(domctl->domain);
         if ( d != NULL )
         {
-            ret = xsm_mem_event(d);
-            if ( !ret )
-                ret = mem_event_domctl(d, &domctl->u.mem_event_op,
-                                       guest_handle_cast(u_domctl, void));
+            ret = mem_event_domctl(d, &domctl->u.mem_event_op,
+                                   guest_handle_cast(u_domctl, void));
             rcu_unlock_domain(d);
             copy_to_guest(u_domctl, domctl, 1);
         } 
@@ -1508,7 +1506,7 @@ long arch_do_domctl(
         d = rcu_lock_domain_by_id(domctl->domain);
         if ( d != NULL )
         {
-            ret = xsm_mem_event(d);
+            ret = xsm_mem_event_setup(d);
             if ( !ret ) {
                 p2m = p2m_get_hostp2m(d);
                 p2m->access_required = domctl->u.access_required.access_required;
diff --git a/xen/arch/x86/mm/mem_event.c b/xen/arch/x86/mm/mem_event.c
index d728889..d574541 100644
--- a/xen/arch/x86/mm/mem_event.c
+++ b/xen/arch/x86/mm/mem_event.c
@@ -29,6 +29,7 @@
 #include <asm/mem_paging.h>
 #include <asm/mem_access.h>
 #include <asm/mem_sharing.h>
+#include <xsm/xsm.h>
 
 /* for public/io/ring.h macros */
 #define xen_mb()   mb()
@@ -439,34 +440,22 @@ static void mem_sharing_notification(struct vcpu *v, unsigned int port)
         mem_sharing_sharing_resume(v->domain);
 }
 
-struct domain *get_mem_event_op_target(uint32_t domain, int *rc)
-{
-    struct domain *d;
-
-    /* Get the target domain */
-    *rc = rcu_lock_remote_target_domain_by_id(domain, &d);
-    if ( *rc != 0 )
-        return NULL;
-
-    /* Not dying? */
-    if ( d->is_dying )
-    {
-        rcu_unlock_domain(d);
-        *rc = -EINVAL;
-        return NULL;
-    }
-    
-    return d;
-}
-
 int do_mem_event_op(int op, uint32_t domain, void *arg)
 {
     int ret;
     struct domain *d;
 
-    d = get_mem_event_op_target(domain, &ret);
+    d = rcu_lock_domain_by_any_id(domain);
     if ( !d )
-        return ret;
+        return -ESRCH;
+
+    ret = -EINVAL;
+    if ( d->is_dying || d == current->domain )
+        goto out;
+
+    ret = xsm_mem_event_op(d, op);
+    if ( ret )
+        goto out;
 
     switch (op)
     {
@@ -483,6 +472,7 @@ int do_mem_event_op(int op, uint32_t domain, void *arg)
             ret = -ENOSYS;
     }
 
+ out:
     rcu_unlock_domain(d);
     return ret;
 }
@@ -516,6 +506,10 @@ int mem_event_domctl(struct domain *d, xen_domctl_mem_event_op_t *mec,
 {
     int rc;
 
+    rc = xsm_mem_event_control(d, mec->mode, mec->op);
+    if ( rc )
+        return rc;
+
     if ( unlikely(d == current->domain) )
     {
         gdprintk(XENLOG_INFO, "Tried to do a memory event op on itself.\n");
@@ -537,13 +531,6 @@ int mem_event_domctl(struct domain *d, xen_domctl_mem_event_op_t *mec,
         return -EINVAL;
     }
 
-    /* TODO: XSM hook */
-#if 0
-    rc = xsm_mem_event_control(d, mec->op);
-    if ( rc )
-        return rc;
-#endif
-
     rc = -ENOSYS;
 
     switch ( mec->mode )
diff --git a/xen/arch/x86/mm/mem_sharing.c b/xen/arch/x86/mm/mem_sharing.c
index 5103285..eff8ae5 100644
--- a/xen/arch/x86/mm/mem_sharing.c
+++ b/xen/arch/x86/mm/mem_sharing.c
@@ -34,6 +34,7 @@
 #include <asm/atomic.h>
 #include <xen/rcupdate.h>
 #include <asm/event.h>
+#include <xsm/xsm.h>
 
 #include "mm-locks.h"
 
@@ -1345,11 +1346,19 @@ int mem_sharing_memop(struct domain *d, xen_mem_sharing_op_t *mec)
             if ( !mem_sharing_enabled(d) )
                 return -EINVAL;
 
-            cd = get_mem_event_op_target(mec->u.share.client_domain, &rc);
+            cd = rcu_lock_domain_by_any_id(mec->u.share.client_domain);
             if ( !cd )
+                return -ESRCH;
+
+            rc = xsm_mem_sharing_op(d, cd, mec->op);
+            if ( rc )
+            {
+                rcu_unlock_domain(cd);
                 return rc;
+            }
 
-            if ( !mem_sharing_enabled(cd) )
+            if ( cd == current->domain || cd->is_dying ||
+                 !mem_sharing_enabled(cd) )
             {
                 rcu_unlock_domain(cd);
                 return -EINVAL;
@@ -1401,11 +1410,19 @@ int mem_sharing_memop(struct domain *d, xen_mem_sharing_op_t *mec)
             if ( !mem_sharing_enabled(d) )
                 return -EINVAL;
 
-            cd = get_mem_event_op_target(mec->u.share.client_domain, &rc);
+            cd = rcu_lock_domain_by_any_id(mec->u.share.client_domain);
             if ( !cd )
+                return -ESRCH;
+
+            rc = xsm_mem_sharing_op(d, cd, mec->op);
+            if ( rc )
+            {
+                rcu_unlock_domain(cd);
                 return rc;
+            }
 
-            if ( !mem_sharing_enabled(cd) )
+            if ( cd == current->domain || cd->is_dying ||
+                 !mem_sharing_enabled(cd) )
             {
                 rcu_unlock_domain(cd);
                 return -EINVAL;
diff --git a/xen/include/asm-x86/mem_event.h b/xen/include/asm-x86/mem_event.h
index 23d71c1..448be4f 100644
--- a/xen/include/asm-x86/mem_event.h
+++ b/xen/include/asm-x86/mem_event.h
@@ -62,7 +62,6 @@ void mem_event_put_request(struct domain *d, struct mem_event_domain *med,
 int mem_event_get_response(struct domain *d, struct mem_event_domain *med,
                            mem_event_response_t *rsp);
 
-struct domain *get_mem_event_op_target(uint32_t domain, int *rc);
 int do_mem_event_op(int op, uint32_t domain, void *arg);
 int mem_event_domctl(struct domain *d, xen_domctl_mem_event_op_t *mec,
                      XEN_GUEST_HANDLE(void) u_domctl);
diff --git a/xen/include/xsm/dummy.h b/xen/include/xsm/dummy.h
index a9784f5..1760cd9 100644
--- a/xen/include/xsm/dummy.h
+++ b/xen/include/xsm/dummy.h
@@ -551,16 +551,37 @@ static XSM_DEFAULT(int, hvm_inject_msi) (struct domain *d)
     return 0;
 }
 
-static XSM_DEFAULT(int, mem_event) (struct domain *d)
+static XSM_DEFAULT(int, mem_event_setup) (struct domain *d)
 {
     return 0;
 }
 
+static XSM_DEFAULT(int, mem_event_control) (struct domain *d, int mode, int op)
+{
+    if ( !IS_PRIV(current->domain) )
+        return -EPERM;
+    return 0;
+}
+
+static XSM_DEFAULT(int, mem_event_op) (struct domain *d, int op)
+{
+    if ( !IS_PRIV_FOR(current->domain, d) )
+        return -EPERM;
+    return 0;
+}
+
 static XSM_DEFAULT(int, mem_sharing) (struct domain *d)
 {
     return 0;
 }
 
+static XSM_DEFAULT(int, mem_sharing_op) (struct domain *d, struct domain *cd, int op)
+{
+    if ( !IS_PRIV_FOR(current->domain, cd) )
+        return -EPERM;
+    return 0;
+}
+
 static XSM_DEFAULT(int, apic) (struct domain *d, int cmd)
 {
     if ( !IS_PRIV(d) )
diff --git a/xen/include/xsm/xsm.h b/xen/include/xsm/xsm.h
index ef3329f..c2c1efa 100644
--- a/xen/include/xsm/xsm.h
+++ b/xen/include/xsm/xsm.h
@@ -151,8 +151,11 @@ struct xsm_operations {
     int (*hvm_set_isa_irq_level) (struct domain *d);
     int (*hvm_set_pci_link_route) (struct domain *d);
     int (*hvm_inject_msi) (struct domain *d);
-    int (*mem_event) (struct domain *d);
+    int (*mem_event_setup) (struct domain *d);
+    int (*mem_event_control) (struct domain *d, int mode, int op);
+    int (*mem_event_op) (struct domain *d, int op);
     int (*mem_sharing) (struct domain *d);
+    int (*mem_sharing_op) (struct domain *d, struct domain *cd, int op);
     int (*apic) (struct domain *d, int cmd);
     int (*xen_settime) (void);
     int (*memtype) (uint32_t access);
@@ -663,9 +666,19 @@ static inline int xsm_hvm_inject_msi (struct domain *d)
     return xsm_ops->hvm_inject_msi(d);
 }
 
-static inline int xsm_mem_event (struct domain *d)
+static inline int xsm_mem_event_setup (struct domain *d)
 {
-    return xsm_ops->mem_event(d);
+    return xsm_ops->mem_event_setup(d);
+}
+
+static inline int xsm_mem_event_control (struct domain *d, int mode, int op)
+{
+    return xsm_ops->mem_event_control(d, mode, op);
+}
+
+static inline int xsm_mem_event_op (struct domain *d, int op)
+{
+    return xsm_ops->mem_event_op(d, op);
 }
 
 static inline int xsm_mem_sharing (struct domain *d)
@@ -673,6 +686,11 @@ static inline int xsm_mem_sharing (struct domain *d)
     return xsm_ops->mem_sharing(d);
 }
 
+static inline int xsm_mem_sharing_op (struct domain *d, struct domain *cd, int op)
+{
+    return xsm_ops->mem_sharing_op(d, cd, op);
+}
+
 static inline int xsm_apic (struct domain *d, int cmd)
 {
     return xsm_ops->apic(d, cmd);
diff --git a/xen/xsm/dummy.c b/xen/xsm/dummy.c
index c76212d..c82c464 100644
--- a/xen/xsm/dummy.c
+++ b/xen/xsm/dummy.c
@@ -135,8 +135,11 @@ void xsm_fixup_ops (struct xsm_operations *ops)
     set_to_dummy_if_null(ops, hvm_set_isa_irq_level);
     set_to_dummy_if_null(ops, hvm_set_pci_link_route);
     set_to_dummy_if_null(ops, hvm_inject_msi);
-    set_to_dummy_if_null(ops, mem_event);
+    set_to_dummy_if_null(ops, mem_event_setup);
+    set_to_dummy_if_null(ops, mem_event_control);
+    set_to_dummy_if_null(ops, mem_event_op);
     set_to_dummy_if_null(ops, mem_sharing);
+    set_to_dummy_if_null(ops, mem_sharing_op);
     set_to_dummy_if_null(ops, apic);
     set_to_dummy_if_null(ops, xen_settime);
     set_to_dummy_if_null(ops, memtype);
diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
index 421087f..f993696 100644
--- a/xen/xsm/flask/hooks.c
+++ b/xen/xsm/flask/hooks.c
@@ -1275,7 +1275,17 @@ static int flask_hvm_inject_msi(struct domain *d)
     return current_has_perm(d, SECCLASS_HVM, HVM__SEND_IRQ);
 }
 
-static int flask_mem_event(struct domain *d)
+static int flask_mem_event_setup(struct domain *d)
+{
+    return current_has_perm(d, SECCLASS_HVM, HVM__MEM_EVENT);
+}
+
+static int flask_mem_event_control(struct domain *d, int mode, int op)
+{
+    return current_has_perm(d, SECCLASS_HVM, HVM__MEM_EVENT);
+}
+
+static int flask_mem_event_op(struct domain *d, int op)
 {
     return current_has_perm(d, SECCLASS_HVM, HVM__MEM_EVENT);
 }
@@ -1285,6 +1295,14 @@ static int flask_mem_sharing(struct domain *d)
     return current_has_perm(d, SECCLASS_HVM, HVM__MEM_SHARING);
 }
 
+static int flask_mem_sharing_op(struct domain *d, struct domain *cd, int op)
+{
+    int rc = current_has_perm(cd, SECCLASS_HVM, HVM__MEM_SHARING);
+    if ( rc )
+        return rc;
+    return domain_has_perm(d, cd, SECCLASS_HVM, HVM__SHARE_MEM);
+}
+
 static int flask_apic(struct domain *d, int cmd)
 {
     u32 perm;
@@ -1734,8 +1752,11 @@ static struct xsm_operations flask_ops = {
     .hvm_set_isa_irq_level = flask_hvm_set_isa_irq_level,
     .hvm_set_pci_link_route = flask_hvm_set_pci_link_route,
     .hvm_inject_msi = flask_hvm_inject_msi,
-    .mem_event = flask_mem_event,
+    .mem_event_setup = flask_mem_event_setup,
+    .mem_event_control = flask_mem_event_control,
+    .mem_event_op = flask_mem_event_op,
     .mem_sharing = flask_mem_sharing,
+    .mem_sharing_op = flask_mem_sharing_op,
     .apic = flask_apic,
     .xen_settime = flask_xen_settime,
     .memtype = flask_memtype,
diff --git a/xen/xsm/flask/include/av_perm_to_string.h b/xen/xsm/flask/include/av_perm_to_string.h
index 894910c..186f1fa 100644
--- a/xen/xsm/flask/include/av_perm_to_string.h
+++ b/xen/xsm/flask/include/av_perm_to_string.h
@@ -84,6 +84,7 @@
    S_(SECCLASS_HVM, HVM__MEM_SHARING, "mem_sharing")
    S_(SECCLASS_HVM, HVM__AUDIT_P2M, "audit_p2m")
    S_(SECCLASS_HVM, HVM__SEND_IRQ, "send_irq")
+   S_(SECCLASS_HVM, HVM__SHARE_MEM, "share_mem")
    S_(SECCLASS_EVENT, EVENT__BIND, "bind")
    S_(SECCLASS_EVENT, EVENT__SEND, "send")
    S_(SECCLASS_EVENT, EVENT__STATUS, "status")
diff --git a/xen/xsm/flask/include/av_permissions.h b/xen/xsm/flask/include/av_permissions.h
index 1bdb515..b3831f6 100644
--- a/xen/xsm/flask/include/av_permissions.h
+++ b/xen/xsm/flask/include/av_permissions.h
@@ -87,6 +87,7 @@
 #define HVM__MEM_SHARING                          0x00001000UL
 #define HVM__AUDIT_P2M                            0x00002000UL
 #define HVM__SEND_IRQ                             0x00004000UL
+#define HVM__SHARE_MEM                            0x00008000UL
 
 #define EVENT__BIND                               0x00000001UL
 #define EVENT__SEND                               0x00000002UL
-- 
1.7.11.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 12 16:00:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Sep 2012 16:00:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TBpM8-0005Q0-8O; Wed, 12 Sep 2012 16:00:00 +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 1TBpM6-0005My-Vo
	for xen-devel@lists.xen.org; Wed, 12 Sep 2012 15:59:59 +0000
Received: from [85.158.138.51:27062] by server-4.bemta-3.messagelabs.com id
	9E/56-24831-E71B0505; Wed, 12 Sep 2012 15:59:58 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-16.tower-174.messagelabs.com!1347465597!30112715!1
X-Originating-IP: [63.239.67.9]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5369 invoked from network); 12 Sep 2012 15:59:57 -0000
Received: from emvm-gh1-uea08.nsa.gov (HELO nsa.gov) (63.239.67.9)
	by server-16.tower-174.messagelabs.com with SMTP;
	12 Sep 2012 15:59:57 -0000
X-TM-IMSS-Message-ID: <39e16b140010234e@nsa.gov>
Received: from tarius.tycho.ncsc.mil ([144.51.3.1]) by nsa.gov ([63.239.67.9])
	with ESMTP (TREND IMSS SMTP Service 7.1) id 39e16b140010234e ;
	Wed, 12 Sep 2012 11:59:48 -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 q8CFxoOT006669; 
	Wed, 12 Sep 2012 11:59:56 -0400
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xen.org
Date: Wed, 12 Sep 2012 11:59:43 -0400
Message-Id: <1347465586-20009-20-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.11.4
In-Reply-To: <1347465586-20009-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1347465586-20009-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Tim Deegan <tim@xen.org>, dgdegra@tycho.nsa.gov, Keir Fraser <keir@xen.org>,
	Jan Beulich <jbeulich@suse.com>
Subject: [Xen-devel] [PATCH 19/22] arch/x86: check remote MMIO remap
	permissions
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 domain is mapping pages from a different pg_owner domain, the
iomem_access checks are currently only applied to the pg_owner domain,
potentially allowing the current domain to bypass its more restrictive
iomem_access policy using another domain that it has access to.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Cc: Keir Fraser <keir@xen.org>
Cc: Jan Beulich <jbeulich@suse.com>
Cc: Tim Deegan <tim@xen.org>
---
 xen/arch/x86/mm.c | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
index 5c6ea2d..c0c2bf3 100644
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -754,6 +754,18 @@ get_page_from_l1e(
             return -EINVAL;
         }
 
+        if ( pg_owner != curr->domain &&
+             !iomem_access_permitted(curr->domain, mfn, mfn) )
+        {
+            if ( mfn != (PADDR_MASK >> PAGE_SHIFT) ) /* INVALID_MFN? */
+            {
+                MEM_LOG("Domain %u attempted to map I/O space %08lx in domain %u",
+                        curr->domain->domain_id, mfn, pg_owner->domain_id);
+                return -EPERM;
+            }
+            return -EINVAL;
+        }
+
         if ( !(l1f & _PAGE_RW) ||
              !rangeset_contains_singleton(mmio_ro_ranges, mfn) )
             return 0;
-- 
1.7.11.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 12 16:00:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Sep 2012 16:00:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TBpM5-0005OB-U2; Wed, 12 Sep 2012 15:59:57 +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 1TBpM4-0005My-Bq
	for xen-devel@lists.xen.org; Wed, 12 Sep 2012 15:59:56 +0000
Received: from [85.158.138.51:6627] by server-4.bemta-3.messagelabs.com id
	05/46-24831-B71B0505; Wed, 12 Sep 2012 15:59:55 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-5.tower-174.messagelabs.com!1347465592!30279670!1
X-Originating-IP: [63.239.67.9]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11843 invoked from network); 12 Sep 2012 15:59:52 -0000
Received: from emvm-gh1-uea08.nsa.gov (HELO nsa.gov) (63.239.67.9)
	by server-5.tower-174.messagelabs.com with SMTP;
	12 Sep 2012 15:59:52 -0000
X-TM-IMSS-Message-ID: <39e156f80010233c@nsa.gov>
Received: from tarius.tycho.ncsc.mil ([144.51.3.1]) by nsa.gov ([63.239.67.9])
	with ESMTP (TREND IMSS SMTP Service 7.1) id 39e156f80010233c ;
	Wed, 12 Sep 2012 11:59:42 -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 q8CFxoOC006669; 
	Wed, 12 Sep 2012 11:59:50 -0400
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xen.org
Date: Wed, 12 Sep 2012 11:59:26 -0400
Message-Id: <1347465586-20009-3-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.11.4
In-Reply-To: <1347465586-20009-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1347465586-20009-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: dgdegra@tycho.nsa.gov
Subject: [Xen-devel] [PATCH 02/22] xsm/flask: remove unneeded create_sid
	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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This field was only used to populate the ssid of dom0, which can be
handled explicitly in the domain creation hook. This also removes the
unnecessary permission check on the creation of dom0.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 tools/flask/policy/policy/modules/xen/xen.te |  2 --
 xen/xsm/flask/hooks.c                        | 23 ++++++++++-------------
 xen/xsm/flask/include/objsec.h               |  1 -
 3 files changed, 10 insertions(+), 16 deletions(-)

diff --git a/tools/flask/policy/policy/modules/xen/xen.te b/tools/flask/policy/policy/modules/xen/xen.te
index e175d4b..9cc5240 100644
--- a/tools/flask/policy/policy/modules/xen/xen.te
+++ b/tools/flask/policy/policy/modules/xen/xen.te
@@ -52,8 +52,6 @@ type device_t, resource_type;
 # Rules required to boot the hypervisor and dom0
 #
 ################################################################################
-allow xen_t dom0_t:domain { create };
-
 allow dom0_t xen_t:xen { kexec readapic writeapic mtrr_read mtrr_add mtrr_del
 	scheduler physinfo heap quirk readconsole writeconsole settime getcpuinfo
 	microcode cpupool_op sched_op pm_op };
diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
index 8c853de..88fef9c 100644
--- a/xen/xsm/flask/hooks.c
+++ b/xen/xsm/flask/hooks.c
@@ -108,12 +108,10 @@ static int flask_domain_alloc_security(struct domain *d)
 
     memset(dsec, 0, sizeof(struct domain_security_struct));
 
-    dsec->create_sid = SECSID_NULL;
     switch ( d->domain_id )
     {
     case DOMID_IDLE:
         dsec->sid = SECINITSID_XEN;
-        dsec->create_sid = SECINITSID_DOM0;
         break;
     case DOMID_XEN:
         dsec->sid = SECINITSID_DOMXEN;
@@ -489,25 +487,24 @@ static int flask_domain_create(struct domain *d, u32 ssidref)
     int rc;
     struct domain_security_struct *dsec1;
     struct domain_security_struct *dsec2;
+    static int dom0_created = 0;
 
     dsec1 = current->domain->ssid;
+    dsec2 = d->ssid;
 
-    if ( dsec1->create_sid == SECSID_NULL ) 
-        dsec1->create_sid = ssidref;
+    if ( is_idle_domain(current->domain) && !dom0_created )
+    {
+        dsec2->sid = SECINITSID_DOM0;
+        dom0_created = 1;
+        return 0;
+    }
 
-    rc = avc_has_perm(dsec1->sid, dsec1->create_sid, SECCLASS_DOMAIN, 
+    rc = avc_has_perm(dsec1->sid, ssidref, SECCLASS_DOMAIN,
                       DOMAIN__CREATE, NULL);
     if ( rc )
-    {
-        dsec1->create_sid = SECSID_NULL;
         return rc;
-    }
-
-    dsec2 = d->ssid;
-    dsec2->sid = dsec1->create_sid;
 
-    dsec1->create_sid = SECSID_NULL;
-    dsec2->create_sid = SECSID_NULL;
+    dsec2->sid = ssidref;
 
     return rc;
 }
diff --git a/xen/xsm/flask/include/objsec.h b/xen/xsm/flask/include/objsec.h
index df5baee..4ff52be 100644
--- a/xen/xsm/flask/include/objsec.h
+++ b/xen/xsm/flask/include/objsec.h
@@ -19,7 +19,6 @@
 
 struct domain_security_struct {
     u32 sid;               /* current SID */
-    u32 create_sid;
 };
 
 struct evtchn_security_struct {
-- 
1.7.11.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 12 16:00:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Sep 2012 16:00:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TBpMA-0005TS-6u; Wed, 12 Sep 2012 16:00:02 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1TBpM8-0005Mn-AH
	for xen-devel@lists.xen.org; Wed, 12 Sep 2012 16:00:00 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-5.tower-27.messagelabs.com!1347465593!7348020!1
X-Originating-IP: [63.239.67.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12219 invoked from network); 12 Sep 2012 15:59:54 -0000
Received: from emvm-gh1-uea09.nsa.gov (HELO nsa.gov) (63.239.67.10)
	by server-5.tower-27.messagelabs.com with SMTP;
	12 Sep 2012 15:59:54 -0000
X-TM-IMSS-Message-ID: <39e11882001083d1@nsa.gov>
Received: from tarius.tycho.ncsc.mil ([144.51.3.1]) by nsa.gov
	([63.239.67.10]) with ESMTP (TREND IMSS SMTP Service 7.1) id
	39e11882001083d1 ; Wed, 12 Sep 2012 12:01:59 -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 q8CFxoOF006669; 
	Wed, 12 Sep 2012 11:59:52 -0400
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xen.org
Date: Wed, 12 Sep 2012 11:59:29 -0400
Message-Id: <1347465586-20009-6-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.11.4
In-Reply-To: <1347465586-20009-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1347465586-20009-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: dgdegra@tycho.nsa.gov, Ian Jackson <ian.jackson@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH 05/22] libxl: introduce XSM relabel on build
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Allow a domain to be built under one security label and run using a
different label. This can be used to prevent the domain builder or
control domain from having the ability to access a guest domain's memory
via map_foreign_range except during the build process where this is
required.

Note: this does not provide complete protection from a malicious dom0;
mappings created during the build process may persist after the relabel,
and could be used to indirectly access the guest's memory.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: Ian Campbell <ian.campbell@citrix.com>
---
 tools/libxc/xc_flask.c      | 10 ++++++++++
 tools/libxc/xenctrl.h       |  1 +
 tools/libxl/libxl_create.c  |  4 ++++
 tools/libxl/libxl_types.idl |  1 +
 tools/libxl/xl_cmdimpl.c    | 20 +++++++++++++++++++-
 5 files changed, 35 insertions(+), 1 deletion(-)

diff --git a/tools/libxc/xc_flask.c b/tools/libxc/xc_flask.c
index 80c5a2d..face1e0 100644
--- a/tools/libxc/xc_flask.c
+++ b/tools/libxc/xc_flask.c
@@ -422,6 +422,16 @@ int xc_flask_setavc_threshold(xc_interface *xch, int threshold)
     return xc_flask_op(xch, &op);
 }
 
+int xc_flask_relabel_domain(xc_interface *xch, int domid, uint32_t sid)
+{
+    DECLARE_FLASK_OP;
+    op.cmd = FLASK_RELABEL_DOMAIN;
+    op.u.relabel.domid = domid;
+    op.u.relabel.sid = sid;
+
+    return xc_flask_op(xch, &op);
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/tools/libxc/xenctrl.h b/tools/libxc/xenctrl.h
index b7741ca..0d595a0 100644
--- a/tools/libxc/xenctrl.h
+++ b/tools/libxc/xenctrl.h
@@ -2173,6 +2173,7 @@ int xc_flask_policyvers(xc_interface *xc_handle);
 int xc_flask_avc_hashstats(xc_interface *xc_handle, char *buf, int size);
 int xc_flask_getavc_threshold(xc_interface *xc_handle);
 int xc_flask_setavc_threshold(xc_interface *xc_handle, int threshold);
+int xc_flask_relabel_domain(xc_interface *xch, int domid, uint32_t sid);
 
 struct elf_binary;
 void xc_elf_set_logfile(xc_interface *xch, struct elf_binary *elf,
diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index ef17f05..6d7bf4e 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -1126,6 +1126,10 @@ static void domcreate_complete(libxl__egc *egc,
                                int rc)
 {
     STATE_AO_GC(dcs->ao);
+    libxl_domain_config *const d_config = dcs->guest_config;
+
+    if (!rc && d_config->b_info.exec_ssidref)
+        rc = xc_flask_relabel_domain(CTX->xch, dcs->guest_domid, d_config->b_info.exec_ssidref);
 
     if (rc) {
         if (dcs->guest_domid) {
diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
index 6d5c578..bc11591 100644
--- a/tools/libxl/libxl_types.idl
+++ b/tools/libxl/libxl_types.idl
@@ -262,6 +262,7 @@ libxl_domain_build_info = Struct("domain_build_info",[
     ("video_memkb",     MemKB),
     ("shadow_memkb",    MemKB),
     ("rtc_timeoffset",  uint32),
+    ("exec_ssidref",    uint32),
     ("localtime",       libxl_defbool),
     ("disable_migrate", libxl_defbool),
     ("cpuid",           libxl_cpuid_policy_list),
diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index 2d6ab97..9b5f291 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -595,16 +595,34 @@ static void parse_config_data(const char *config_source,
         exit(1);
     }
 
-    if (!xlu_cfg_get_string (config, "seclabel", &buf, 0)) {
+    if (!xlu_cfg_get_string (config, "init_seclabel", &buf, 0)) {
         e = libxl_flask_context_to_sid(ctx, (char *)buf, strlen(buf),
                                     &c_info->ssidref);
         if (e) {
             if (errno == ENOSYS) {
+                fprintf(stderr, "XSM Disabled: init_seclabel not supported\n");
+            } else {
+                fprintf(stderr, "Invalid init_seclabel: %s\n", buf);
+                exit(1);
+            }
+        }
+    }
+
+    if (!xlu_cfg_get_string (config, "seclabel", &buf, 0)) {
+        uint32_t ssidref;
+        e = libxl_flask_context_to_sid(ctx, (char *)buf, strlen(buf),
+                                    &ssidref);
+        if (e) {
+            if (errno == ENOSYS) {
                 fprintf(stderr, "XSM Disabled: seclabel not supported\n");
             } else {
                 fprintf(stderr, "Invalid seclabel: %s\n", buf);
                 exit(1);
             }
+        } else if (c_info->ssidref) {
+            b_info->exec_ssidref = ssidref;
+        } else {
+            c_info->ssidref = ssidref;
         }
     }
 
-- 
1.7.11.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 12 16:00:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Sep 2012 16:00:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TBpMB-0005cj-Mw; Wed, 12 Sep 2012 16:00:03 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1TBpMA-0005Na-Ak
	for xen-devel@lists.xen.org; Wed, 12 Sep 2012 16:00:02 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-10.tower-27.messagelabs.com!1347465595!5579603!1
X-Originating-IP: [63.239.67.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31195 invoked from network); 12 Sep 2012 15:59:55 -0000
Received: from emvm-gh1-uea09.nsa.gov (HELO nsa.gov) (63.239.67.10)
	by server-10.tower-27.messagelabs.com with SMTP;
	12 Sep 2012 15:59:55 -0000
X-TM-IMSS-Message-ID: <39e11d14001083d4@nsa.gov>
Received: from tarius.tycho.ncsc.mil ([144.51.3.1]) by nsa.gov
	([63.239.67.10]) with ESMTP (TREND IMSS SMTP Service 7.1) id
	39e11d14001083d4 ; Wed, 12 Sep 2012 12:02:01 -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 q8CFxoOK006669; 
	Wed, 12 Sep 2012 11:59:53 -0400
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xen.org
Date: Wed, 12 Sep 2012 11:59:34 -0400
Message-Id: <1347465586-20009-11-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.11.4
In-Reply-To: <1347465586-20009-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1347465586-20009-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: dgdegra@tycho.nsa.gov, Keir Fraser <keir@xen.org>,
	Jan Beulich <jbeulich@suse.com>
Subject: [Xen-devel] [PATCH 10/22] xen: use XSM instead of IS_PRIV where
	duplicated
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

The Xen hypervisor has two basic access control function calls: IS_PRIV
and the xsm_* functions. Most privileged operations currently require
that both checks succeed, and many times the checks are at different
locations in the code. This patch eliminates the explicit and implicit
IS_PRIV checks that are duplicated in XSM hooks.

When XSM_ENABLE is not defined or when the dummy XSM module is used,
this patch should not change any functionality. Because the locations of
privilege checks have sometimes moved below argument validation, error
returns of some functions may change from EPERM to EINVAL or ESRCH if
called with invalid arguments and from a domain without permission to
perform the operation.

Some checks are removed due to non-obvious duplicates in their callers:

 * acpi_enter_sleep is checked in XENPF_enter_acpi_sleep
 * map_domain_pirq has IS_PRIV_FOR checked in its callers:
   * physdev_map_pirq checks when acquiring the RCU lock
   * ioapic_guest_write is checked in PHYSDEVOP_apic_write
 * PHYSDEVOP_{manage_pci_add,manage_pci_add_ext,pci_device_add} are
   checked by xsm_resource_plug_pci in pci_add_device
 * PHYSDEVOP_manage_pci_remove is checked by xsm_resource_unplug_pci
   in pci_remove_device
 * PHYSDEVOP_{restore_msi,restore_msi_ext} are checked by
   xsm_resource_setup_pci in pci_restore_msi_state
 * do_console_io has changed to IS_PRIV from an explicit domid==0

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Cc: Keir Fraser <keir@xen.org>
Cc: Jan Beulich <jbeulich@suse.com>
---
 xen/arch/x86/acpi/power.c     |  2 +-
 xen/arch/x86/cpu/mcheck/mce.c |  3 ---
 xen/arch/x86/irq.c            |  3 +--
 xen/arch/x86/mm.c             |  3 ---
 xen/arch/x86/physdev.c        | 54 ++-----------------------------------------
 xen/common/kexec.c            |  3 ---
 xen/common/schedule.c         |  6 -----
 xen/drivers/char/console.c    |  6 -----
 xen/include/xsm/dummy.h       | 28 ++++++++++++++++++++++
 xen/xsm/flask/hooks.c         |  5 ++--
 10 files changed, 35 insertions(+), 78 deletions(-)

diff --git a/xen/arch/x86/acpi/power.c b/xen/arch/x86/acpi/power.c
index 9e1f989..c7b37ef 100644
--- a/xen/arch/x86/acpi/power.c
+++ b/xen/arch/x86/acpi/power.c
@@ -238,7 +238,7 @@ static long enter_state_helper(void *data)
  */
 int acpi_enter_sleep(struct xenpf_enter_acpi_sleep *sleep)
 {
-    if ( !IS_PRIV(current->domain) || !acpi_sinfo.pm1a_cnt_blk.address )
+    if ( !acpi_sinfo.pm1a_cnt_blk.address )
         return -EPERM;
 
     /* Sanity check */
diff --git a/xen/arch/x86/cpu/mcheck/mce.c b/xen/arch/x86/cpu/mcheck/mce.c
index a89df6d..f399054 100644
--- a/xen/arch/x86/cpu/mcheck/mce.c
+++ b/xen/arch/x86/cpu/mcheck/mce.c
@@ -1379,9 +1379,6 @@ long do_mca(XEN_GUEST_HANDLE(xen_mc_t) u_xen_mc)
     struct xen_mc_msrinject *mc_msrinject;
     struct xen_mc_mceinject *mc_mceinject;
 
-    if (!IS_PRIV(v->domain) )
-        return x86_mcerr(NULL, -EPERM);
-
     ret = xsm_do_mca();
     if ( ret )
         return x86_mcerr(NULL, ret);
diff --git a/xen/arch/x86/irq.c b/xen/arch/x86/irq.c
index c87027b..70b0f03 100644
--- a/xen/arch/x86/irq.c
+++ b/xen/arch/x86/irq.c
@@ -1853,8 +1853,7 @@ int map_domain_pirq(
     ASSERT(spin_is_locked(&d->event_lock));
 
     if ( !IS_PRIV(current->domain) &&
-         !(IS_PRIV_FOR(current->domain, d) &&
-           irq_access_permitted(current->domain, pirq)))
+         !irq_access_permitted(current->domain, pirq))
         return -EPERM;
 
     if ( pirq < 0 || pirq >= d->nr_pirqs || irq < 0 || irq >= nr_irqs )
diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
index 4ea5334..b370300 100644
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -4488,9 +4488,6 @@ long arch_memory_op(int op, XEN_GUEST_HANDLE(void) arg)
         XEN_GUEST_HANDLE(e820entry_t) buffer;
         unsigned int i;
 
-        if ( !IS_PRIV(current->domain) )
-            return -EINVAL;
-
         rc = xsm_machine_memory_map();
         if ( rc )
             return rc;
diff --git a/xen/arch/x86/physdev.c b/xen/arch/x86/physdev.c
index 13b85da..515dca3 100644
--- a/xen/arch/x86/physdev.c
+++ b/xen/arch/x86/physdev.c
@@ -109,12 +109,6 @@ int physdev_map_pirq(domid_t domid, int type, int *index, int *pirq_p,
     if ( ret )
         return ret;
 
-    if ( !IS_PRIV_FOR(current->domain, d) )
-    {
-        ret = -EPERM;
-        goto free_domain;
-    }
-
     /* Verify or get irq. */
     switch ( type )
     {
@@ -238,10 +232,6 @@ int physdev_unmap_pirq(domid_t domid, int pirq)
             goto free_domain;
     }
 
-    ret = -EPERM;
-    if ( !IS_PRIV_FOR(current->domain, d) )
-        goto free_domain;
-
     ret = xsm_unmap_domain_pirq(d, domain_pirq_to_irq(d, pirq));
     if ( ret )
         goto free_domain;
@@ -433,9 +423,6 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_HANDLE(void) arg)
         ret = -EFAULT;
         if ( copy_from_guest(&apic, arg, 1) != 0 )
             break;
-        ret = -EPERM;
-        if ( !IS_PRIV(v->domain) )
-            break;
         ret = xsm_apic(v->domain, cmd);
         if ( ret )
             break;
@@ -450,9 +437,6 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_HANDLE(void) arg)
         ret = -EFAULT;
         if ( copy_from_guest(&apic, arg, 1) != 0 )
             break;
-        ret = -EPERM;
-        if ( !IS_PRIV(v->domain) )
-            break;
         ret = xsm_apic(v->domain, cmd);
         if ( ret )
             break;
@@ -467,8 +451,8 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_HANDLE(void) arg)
         if ( copy_from_guest(&irq_op, arg, 1) != 0 )
             break;
 
-        ret = -EPERM;
-        if ( !IS_PRIV(v->domain) )
+        ret = xsm_apic(v->domain, cmd);
+        if ( ret )
             break;
 
         /* Vector is only used by hypervisor, and dom0 shouldn't
@@ -517,9 +501,6 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_HANDLE(void) arg)
 
     case PHYSDEVOP_manage_pci_add: {
         struct physdev_manage_pci manage_pci;
-        ret = -EPERM;
-        if ( !IS_PRIV(v->domain) )
-            break;
         ret = -EFAULT;
         if ( copy_from_guest(&manage_pci, arg, 1) != 0 )
             break;
@@ -530,9 +511,6 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_HANDLE(void) arg)
 
     case PHYSDEVOP_manage_pci_remove: {
         struct physdev_manage_pci manage_pci;
-        ret = -EPERM;
-        if ( !IS_PRIV(v->domain) )
-            break;
         ret = -EFAULT;
         if ( copy_from_guest(&manage_pci, arg, 1) != 0 )
             break;
@@ -545,10 +523,6 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_HANDLE(void) arg)
         struct physdev_manage_pci_ext manage_pci_ext;
         struct pci_dev_info pdev_info;
 
-        ret = -EPERM;
-        if ( !IS_PRIV(current->domain) )
-            break;
-
         ret = -EFAULT;
         if ( copy_from_guest(&manage_pci_ext, arg, 1) != 0 )
             break;
@@ -571,10 +545,6 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_HANDLE(void) arg)
         struct physdev_pci_device_add add;
         struct pci_dev_info pdev_info;
 
-        ret = -EPERM;
-        if ( !IS_PRIV(current->domain) )
-            break;
-
         ret = -EFAULT;
         if ( copy_from_guest(&add, arg, 1) != 0 )
             break;
@@ -595,10 +565,6 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_HANDLE(void) arg)
     case PHYSDEVOP_pci_device_remove: {
         struct physdev_pci_device dev;
 
-        ret = -EPERM;
-        if ( !IS_PRIV(v->domain) )
-            break;
-
         ret = -EFAULT;
         if ( copy_from_guest(&dev, arg, 1) != 0 )
             break;
@@ -610,10 +576,6 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_HANDLE(void) arg)
     case PHYSDEVOP_pci_mmcfg_reserved: {
         struct physdev_pci_mmcfg_reserved info;
 
-        ret = -EPERM;
-        if ( !IS_PRIV(current->domain) )
-            break;
-
         ret = xsm_resource_setup_misc();
         if ( ret )
             break;
@@ -631,10 +593,6 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_HANDLE(void) arg)
         struct physdev_restore_msi restore_msi;
         struct pci_dev *pdev;
 
-        ret = -EPERM;
-        if ( !IS_PRIV(v->domain) )
-            break;
-
         ret = -EFAULT;
         if ( copy_from_guest(&restore_msi, arg, 1) != 0 )
             break;
@@ -650,10 +608,6 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_HANDLE(void) arg)
         struct physdev_pci_device dev;
         struct pci_dev *pdev;
 
-        ret = -EPERM;
-        if ( !IS_PRIV(v->domain) )
-            break;
-
         ret = -EFAULT;
         if ( copy_from_guest(&dev, arg, 1) != 0 )
             break;
@@ -668,10 +622,6 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_HANDLE(void) arg)
     case PHYSDEVOP_setup_gsi: {
         struct physdev_setup_gsi setup_gsi;
 
-        ret = -EPERM;
-        if ( !IS_PRIV(v->domain) )
-            break;
-
         ret = -EFAULT;
         if ( copy_from_guest(&setup_gsi, arg, 1) != 0 )
             break;
diff --git a/xen/common/kexec.c b/xen/common/kexec.c
index 2bc3e33..7dc6f24 100644
--- a/xen/common/kexec.c
+++ b/xen/common/kexec.c
@@ -851,9 +851,6 @@ static int do_kexec_op_internal(unsigned long op, XEN_GUEST_HANDLE(void) uarg,
     unsigned long flags;
     int ret = -EINVAL;
 
-    if ( !IS_PRIV(current->domain) )
-        return -EPERM;
-
     ret = xsm_kexec();
     if ( ret )
         return ret;
diff --git a/xen/common/schedule.c b/xen/common/schedule.c
index eee74be..95142c0 100644
--- a/xen/common/schedule.c
+++ b/xen/common/schedule.c
@@ -919,12 +919,6 @@ ret_t do_sched_op(int cmd, XEN_GUEST_HANDLE(void) arg)
         if ( d == NULL )
             break;
 
-        if ( !IS_PRIV_FOR(current->domain, d) )
-        {
-            rcu_unlock_domain(d);
-            return -EPERM;
-        }
-
         ret = xsm_schedop_shutdown(current->domain, d);
         if ( ret )
         {
diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c
index d97170c..aee3b4b 100644
--- a/xen/drivers/char/console.c
+++ b/xen/drivers/char/console.c
@@ -363,12 +363,6 @@ long do_console_io(int cmd, int count, XEN_GUEST_HANDLE(char) buffer)
     long rc;
     unsigned int idx, len;
 
-#ifndef VERBOSE
-    /* Only domain 0 may access the emergency console. */
-    if ( current->domain->domain_id != 0 )
-        return -EPERM;
-#endif
-
     rc = xsm_console_io(current->domain, cmd);
     if ( rc )
         return rc;
diff --git a/xen/include/xsm/dummy.h b/xen/include/xsm/dummy.h
index 61c6f13..389d9f6 100644
--- a/xen/include/xsm/dummy.h
+++ b/xen/include/xsm/dummy.h
@@ -161,6 +161,8 @@ static XSM_DEFAULT(int, pm_op) (void)
 
 static XSM_DEFAULT(int, do_mca) (void)
 {
+    if ( !IS_PRIV(current->domain) )
+        return -EPERM;
     return 0;
 }
 
@@ -223,6 +225,10 @@ static XSM_DEFAULT(int, memory_stat_reservation) (struct domain *d1, struct doma
 
 static XSM_DEFAULT(int, console_io) (struct domain *d, int cmd)
 {
+#ifndef VERBOSE
+    if ( !IS_PRIV(current->domain) )
+        return -EPERM;
+#endif
     return 0;
 }
 
@@ -233,11 +239,15 @@ static XSM_DEFAULT(int, profile) (struct domain *d, int op)
 
 static XSM_DEFAULT(int, kexec) (void)
 {
+    if ( !IS_PRIV(current->domain) )
+        return -EPERM;
     return 0;
 }
 
 static XSM_DEFAULT(int, schedop_shutdown) (struct domain *d1, struct domain *d2)
 {
+    if ( !IS_PRIV_FOR(d1, d2) )
+        return -EPERM;
     return 0;
 }
 
@@ -336,26 +346,36 @@ static XSM_DEFAULT(int, resource_unplug_core) (void)
 
 static XSM_DEFAULT(int, resource_plug_pci) (uint32_t machine_bdf)
 {
+    if ( !IS_PRIV(current->domain) )
+        return -EPERM;
     return 0;
 }
 
 static XSM_DEFAULT(int, resource_unplug_pci) (uint32_t machine_bdf)
 {
+    if ( !IS_PRIV(current->domain) )
+        return -EPERM;
     return 0;
 }
 
 static XSM_DEFAULT(int, resource_setup_pci) (uint32_t machine_bdf)
 {
+    if ( !IS_PRIV(current->domain) )
+        return -EPERM;
     return 0;
 }
 
 static XSM_DEFAULT(int, resource_setup_gsi) (int gsi)
 {
+    if ( !IS_PRIV(current->domain) )
+        return -EPERM;
     return 0;
 }
 
 static XSM_DEFAULT(int, resource_setup_misc) (void)
 {
+    if ( !IS_PRIV(current->domain) )
+        return -EPERM;
     return 0;
 }
 
@@ -396,6 +416,8 @@ static XSM_DEFAULT(int, map_domain_pirq) (struct domain *d, int irq, void *data)
 
 static XSM_DEFAULT(int, unmap_domain_pirq) (struct domain *d, int irq)
 {
+    if ( !IS_PRIV_FOR(current->domain, d) )
+        return -EPERM;
     return 0;
 }
 
@@ -494,6 +516,8 @@ static XSM_DEFAULT(int, mem_sharing) (struct domain *d)
 
 static XSM_DEFAULT(int, apic) (struct domain *d, int cmd)
 {
+    if ( !IS_PRIV(d) )
+        return -EPERM;
     return 0;
 }
 
@@ -534,6 +558,8 @@ static XSM_DEFAULT(int, efi_call) (void)
 
 static XSM_DEFAULT(int, acpi_sleep) (void)
 {
+    if ( !IS_PRIV(current->domain) )
+        return -EPERM;
     return 0;
 }
 
@@ -549,6 +575,8 @@ static XSM_DEFAULT(int, getidletime) (void)
 
 static XSM_DEFAULT(int, machine_memory_map) (void)
 {
+    if ( !IS_PRIV(current->domain) )
+        return -EPERM;
     return 0;
 }
 
diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
index 6d4b4f0..10c2163 100644
--- a/xen/xsm/flask/hooks.c
+++ b/xen/xsm/flask/hooks.c
@@ -1147,10 +1147,11 @@ static int flask_apic(struct domain *d, int cmd)
 
     switch ( cmd )
     {
-    case PHYSDEVOP_APIC_READ:
+    case PHYSDEVOP_apic_read:
+    case PHYSDEVOP_alloc_irq_vector:
         perm = XEN__READAPIC;
         break;
-    case PHYSDEVOP_APIC_WRITE:
+    case PHYSDEVOP_apic_write:
         perm = XEN__WRITEAPIC;
         break;
     default:
-- 
1.7.11.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 12 16:00:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Sep 2012 16:00:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TBpMD-0005kc-Bg; Wed, 12 Sep 2012 16:00:05 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1TBpMA-0005Nk-Pi
	for xen-devel@lists.xen.org; Wed, 12 Sep 2012 16:00:03 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-9.tower-27.messagelabs.com!1347465595!9477810!1
X-Originating-IP: [63.239.67.10]
X-SpamReason: No, hits=2.5 required=7.0 tests=BODY_RANDOM_LONG,LONGWORDS
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15449 invoked from network); 12 Sep 2012 15:59:56 -0000
Received: from emvm-gh1-uea09.nsa.gov (HELO nsa.gov) (63.239.67.10)
	by server-9.tower-27.messagelabs.com with SMTP;
	12 Sep 2012 15:59:56 -0000
X-TM-IMSS-Message-ID: <39e122de001083db@nsa.gov>
Received: from tarius.tycho.ncsc.mil ([144.51.3.1]) by nsa.gov
	([63.239.67.10]) with ESMTP (TREND IMSS SMTP Service 7.1) id
	39e122de001083db ; Wed, 12 Sep 2012 12:02:02 -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 q8CFxoOQ006669; 
	Wed, 12 Sep 2012 11:59:54 -0400
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xen.org
Date: Wed, 12 Sep 2012 11:59:40 -0400
Message-Id: <1347465586-20009-17-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.11.4
In-Reply-To: <1347465586-20009-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1347465586-20009-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: dgdegra@tycho.nsa.gov
Subject: [Xen-devel] [PATCH 16/22] xsm/flask: add missing hooks
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 FLASK module was missing implementations of some hooks and did not
have access vectors defined for 10 domctls; define these now.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 tools/flask/policy/policy/flask/access_vectors |  5 ++
 tools/flask/policy/policy/modules/xen/xen.if   |  4 +-
 xen/xsm/flask/hooks.c                          | 66 +++++++++++++++++++++-----
 xen/xsm/flask/include/av_perm_to_string.h      |  5 ++
 xen/xsm/flask/include/av_permissions.h         |  5 ++
 5 files changed, 73 insertions(+), 12 deletions(-)

diff --git a/tools/flask/policy/policy/flask/access_vectors b/tools/flask/policy/policy/flask/access_vectors
index 11d02da..ea65e45 100644
--- a/tools/flask/policy/policy/flask/access_vectors
+++ b/tools/flask/policy/policy/flask/access_vectors
@@ -80,6 +80,9 @@ class domain2
 	relabelself
 	make_priv_for
 	set_as_target
+	set_cpuid
+	gettsc
+	settsc
 }
 
 class hvm
@@ -97,6 +100,8 @@ class hvm
     hvmctl
     mem_event
     mem_sharing
+    audit_p2m
+    send_irq
 }
 
 class event
diff --git a/tools/flask/policy/policy/modules/xen/xen.if b/tools/flask/policy/policy/modules/xen/xen.if
index 2ad11b2..59ba171 100644
--- a/tools/flask/policy/policy/modules/xen/xen.if
+++ b/tools/flask/policy/policy/modules/xen/xen.if
@@ -29,6 +29,7 @@ define(`create_domain_common', `
 			getdomaininfo hypercall setvcpucontext setextvcpucontext
 			scheduler getvcpuinfo getvcpuextstate getaddrsize
 			getvcpuaffinity setvcpuaffinity };
+	allow $1 $2:domain2 { set_cpuid settsc };
 	allow $1 $2:security check_context;
 	allow $1 $2:shadow enable;
 	allow $1 $2:mmu {map_read map_write adjust memorymap physmap pinpage};
@@ -67,6 +68,7 @@ define(`migrate_domain_out', `
 	allow $1 $2:hvm { gethvmc getparam irqlevel };
 	allow $1 $2:mmu { stat pageinfo map_read };
 	allow $1 $2:domain { getaddrsize getvcpucontext getextvcpucontext getvcpuextstate pause destroy };
+	allow $1 $2:domain2 gettsc;
 ')
 
 ################################################################################
@@ -112,7 +114,7 @@ define(`device_model', `
 	domain_comms($1, $2)
 	allow $1 $2:domain { set_target shutdown };
 	allow $1 $2:mmu { map_read map_write adjust physmap };
-	allow $1 $2:hvm { getparam setparam trackdirtyvram hvmctl irqlevel pciroute };
+	allow $1 $2:hvm { getparam setparam trackdirtyvram hvmctl irqlevel pciroute cacheattr send_irq };
 ')
 ################################################################################
 #
diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
index 16af92b..3cb814d 100644
--- a/xen/xsm/flask/hooks.c
+++ b/xen/xsm/flask/hooks.c
@@ -650,25 +650,32 @@ static int flask_domctl(struct domain *d, int cmd)
 #endif
         return 0;
 
+    case XEN_DOMCTL_debug_op:
+    case XEN_DOMCTL_gdbsx_guestmemio:
+    case XEN_DOMCTL_gdbsx_pausevcpu:
+    case XEN_DOMCTL_gdbsx_unpausevcpu:
+    case XEN_DOMCTL_gdbsx_domstatus:
+        return domain_has_perm(current->domain, d, SECCLASS_DOMAIN,
+                               DOMAIN__SETDEBUGGING);
+
     case XEN_DOMCTL_subscribe:
     case XEN_DOMCTL_disable_migrate:
+    case XEN_DOMCTL_suppress_spurious_page_faults:
         return domain_has_perm(current->domain, d, SECCLASS_DOMAIN,
                                DOMAIN__SET_MISC_INFO);
 
     case XEN_DOMCTL_set_cpuid:
-    case XEN_DOMCTL_suppress_spurious_page_faults:
-    case XEN_DOMCTL_debug_op:
+        return domain_has_perm(current->domain, d, SECCLASS_DOMAIN2, DOMAIN2__SET_CPUID);
+
     case XEN_DOMCTL_gettscinfo:
+        return domain_has_perm(current->domain, d, SECCLASS_DOMAIN2, DOMAIN2__GETTSC);
+
     case XEN_DOMCTL_settscinfo:
+        return domain_has_perm(current->domain, d, SECCLASS_DOMAIN2, DOMAIN2__SETTSC);
+
     case XEN_DOMCTL_audit_p2m:
-    case XEN_DOMCTL_gdbsx_guestmemio:
-    case XEN_DOMCTL_gdbsx_pausevcpu:
-    case XEN_DOMCTL_gdbsx_unpausevcpu:
-    case XEN_DOMCTL_gdbsx_domstatus:
-        /* TODO add per-subfunction hooks */
-        if ( !IS_PRIV(current->domain) )
-            return -EPERM;
-        return 0;
+        return domain_has_perm(current->domain, d, SECCLASS_HVM, HVM__AUDIT_P2M);
+
     default:
         printk("flask_domctl: Unknown op %d\n", cmd);
         return -EPERM;
@@ -919,6 +926,11 @@ static int flask_iomem_permission(struct domain *d, uint64_t start, uint64_t end
     return security_iterate_iomem_sids(start, end, _iomem_has_perm, &data);
 }
 
+static int flask_iomem_mapping(struct domain *d, uint64_t start, uint64_t end, uint8_t access)
+{
+    return flask_iomem_permission(d, start, end, access);
+}
+
 static int flask_pci_config_permission(struct domain *d, uint32_t machine_bdf, uint16_t start, uint16_t end, uint8_t access)
 {
     u32 rsid;
@@ -1126,7 +1138,6 @@ static int _ioport_has_perm(void *v, u32 sid, unsigned long start, unsigned long
     return avc_has_perm(data->tsec->sid, sid, SECCLASS_RESOURCE, RESOURCE__USE, &ad);
 }
 
-
 static int flask_ioport_permission(struct domain *d, uint32_t start, uint32_t end, uint8_t access)
 {
     int rc;
@@ -1149,6 +1160,11 @@ static int flask_ioport_permission(struct domain *d, uint32_t start, uint32_t en
     return security_iterate_ioport_sids(start, end, _ioport_has_perm, &data);
 }
 
+static int flask_ioport_mapping(struct domain *d, uint32_t start, uint32_t end, uint8_t access)
+{
+    return flask_ioport_permission(d, start, end, access);
+}
+
 static int flask_getpageframeinfo(struct domain *d)
 {
     return domain_has_perm(current->domain, d, SECCLASS_MMU, MMU__PAGEINFO);
@@ -1207,6 +1223,25 @@ static int flask_address_size(struct domain *d, uint32_t cmd)
     return domain_has_perm(current->domain, d, SECCLASS_DOMAIN, perm);
 }
 
+static int flask_machine_address_size(struct domain *d, uint32_t cmd)
+{
+    u32 perm;
+
+    switch ( cmd )
+    {
+    case XEN_DOMCTL_set_machine_address_size:
+        perm = DOMAIN__SETADDRSIZE;
+        break;
+    case XEN_DOMCTL_get_machine_address_size:
+        perm = DOMAIN__GETADDRSIZE;
+        break;
+    default:
+        return -EPERM;
+    }
+
+    return domain_has_perm(current->domain, d, SECCLASS_DOMAIN, perm);
+}
+
 static int flask_hvm_param(struct domain *d, unsigned long op)
 {
     u32 perm;
@@ -1244,6 +1279,11 @@ static int flask_hvm_set_pci_link_route(struct domain *d)
     return domain_has_perm(current->domain, d, SECCLASS_HVM, HVM__PCIROUTE);
 }
 
+static int flask_hvm_inject_msi(struct domain *d)
+{
+    return domain_has_perm(current->domain, d, SECCLASS_HVM, HVM__SEND_IRQ);
+}
+
 static int flask_mem_event(struct domain *d)
 {
     return domain_has_perm(current->domain, d, SECCLASS_HVM, HVM__MEM_EVENT);
@@ -1687,6 +1727,7 @@ static struct xsm_operations flask_ops = {
     .unmap_domain_pirq = flask_unmap_domain_pirq,
     .irq_permission = flask_irq_permission,
     .iomem_permission = flask_iomem_permission,
+    .iomem_mapping = flask_iomem_mapping,
     .pci_config_permission = flask_pci_config_permission,
 
     .resource_plug_core = flask_resource_plug_core,
@@ -1711,10 +1752,12 @@ static struct xsm_operations flask_ops = {
     .hypercall_init = flask_hypercall_init,
     .hvmcontext = flask_hvmcontext,
     .address_size = flask_address_size,
+    .machine_address_size = flask_machine_address_size,
     .hvm_param = flask_hvm_param,
     .hvm_set_pci_intx_level = flask_hvm_set_pci_intx_level,
     .hvm_set_isa_irq_level = flask_hvm_set_isa_irq_level,
     .hvm_set_pci_link_route = flask_hvm_set_pci_link_route,
+    .hvm_inject_msi = flask_hvm_inject_msi,
     .mem_event = flask_mem_event,
     .mem_sharing = flask_mem_sharing,
     .apic = flask_apic,
@@ -1747,6 +1790,7 @@ static struct xsm_operations flask_ops = {
     .ext_vcpucontext = flask_ext_vcpucontext,
     .vcpuextstate = flask_vcpuextstate,
     .ioport_permission = flask_ioport_permission,
+    .ioport_mapping = flask_ioport_mapping,
 #endif
 };
 
diff --git a/xen/xsm/flask/include/av_perm_to_string.h b/xen/xsm/flask/include/av_perm_to_string.h
index 10f8e80..894910c 100644
--- a/xen/xsm/flask/include/av_perm_to_string.h
+++ b/xen/xsm/flask/include/av_perm_to_string.h
@@ -66,6 +66,9 @@
    S_(SECCLASS_DOMAIN2, DOMAIN2__RELABELSELF, "relabelself")
    S_(SECCLASS_DOMAIN2, DOMAIN2__MAKE_PRIV_FOR, "make_priv_for")
    S_(SECCLASS_DOMAIN2, DOMAIN2__SET_AS_TARGET, "set_as_target")
+   S_(SECCLASS_DOMAIN2, DOMAIN2__SET_CPUID, "set_cpuid")
+   S_(SECCLASS_DOMAIN2, DOMAIN2__GETTSC, "gettsc")
+   S_(SECCLASS_DOMAIN2, DOMAIN2__SETTSC, "settsc")
    S_(SECCLASS_HVM, HVM__SETHVMC, "sethvmc")
    S_(SECCLASS_HVM, HVM__GETHVMC, "gethvmc")
    S_(SECCLASS_HVM, HVM__SETPARAM, "setparam")
@@ -79,6 +82,8 @@
    S_(SECCLASS_HVM, HVM__HVMCTL, "hvmctl")
    S_(SECCLASS_HVM, HVM__MEM_EVENT, "mem_event")
    S_(SECCLASS_HVM, HVM__MEM_SHARING, "mem_sharing")
+   S_(SECCLASS_HVM, HVM__AUDIT_P2M, "audit_p2m")
+   S_(SECCLASS_HVM, HVM__SEND_IRQ, "send_irq")
    S_(SECCLASS_EVENT, EVENT__BIND, "bind")
    S_(SECCLASS_EVENT, EVENT__SEND, "send")
    S_(SECCLASS_EVENT, EVENT__STATUS, "status")
diff --git a/xen/xsm/flask/include/av_permissions.h b/xen/xsm/flask/include/av_permissions.h
index f7cfee1..1bdb515 100644
--- a/xen/xsm/flask/include/av_permissions.h
+++ b/xen/xsm/flask/include/av_permissions.h
@@ -68,6 +68,9 @@
 #define DOMAIN2__RELABELSELF                      0x00000004UL
 #define DOMAIN2__MAKE_PRIV_FOR                    0x00000008UL
 #define DOMAIN2__SET_AS_TARGET                    0x00000010UL
+#define DOMAIN2__SET_CPUID                        0x00000020UL
+#define DOMAIN2__GETTSC                           0x00000040UL
+#define DOMAIN2__SETTSC                           0x00000080UL
 
 #define HVM__SETHVMC                              0x00000001UL
 #define HVM__GETHVMC                              0x00000002UL
@@ -82,6 +85,8 @@
 #define HVM__HVMCTL                               0x00000400UL
 #define HVM__MEM_EVENT                            0x00000800UL
 #define HVM__MEM_SHARING                          0x00001000UL
+#define HVM__AUDIT_P2M                            0x00002000UL
+#define HVM__SEND_IRQ                             0x00004000UL
 
 #define EVENT__BIND                               0x00000001UL
 #define EVENT__SEND                               0x00000002UL
-- 
1.7.11.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 12 16:00:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Sep 2012 16:00:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TBpMB-0005cj-Mw; Wed, 12 Sep 2012 16:00:03 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1TBpMA-0005Na-Ak
	for xen-devel@lists.xen.org; Wed, 12 Sep 2012 16:00:02 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-10.tower-27.messagelabs.com!1347465595!5579603!1
X-Originating-IP: [63.239.67.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31195 invoked from network); 12 Sep 2012 15:59:55 -0000
Received: from emvm-gh1-uea09.nsa.gov (HELO nsa.gov) (63.239.67.10)
	by server-10.tower-27.messagelabs.com with SMTP;
	12 Sep 2012 15:59:55 -0000
X-TM-IMSS-Message-ID: <39e11d14001083d4@nsa.gov>
Received: from tarius.tycho.ncsc.mil ([144.51.3.1]) by nsa.gov
	([63.239.67.10]) with ESMTP (TREND IMSS SMTP Service 7.1) id
	39e11d14001083d4 ; Wed, 12 Sep 2012 12:02:01 -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 q8CFxoOK006669; 
	Wed, 12 Sep 2012 11:59:53 -0400
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xen.org
Date: Wed, 12 Sep 2012 11:59:34 -0400
Message-Id: <1347465586-20009-11-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.11.4
In-Reply-To: <1347465586-20009-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1347465586-20009-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: dgdegra@tycho.nsa.gov, Keir Fraser <keir@xen.org>,
	Jan Beulich <jbeulich@suse.com>
Subject: [Xen-devel] [PATCH 10/22] xen: use XSM instead of IS_PRIV where
	duplicated
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

The Xen hypervisor has two basic access control function calls: IS_PRIV
and the xsm_* functions. Most privileged operations currently require
that both checks succeed, and many times the checks are at different
locations in the code. This patch eliminates the explicit and implicit
IS_PRIV checks that are duplicated in XSM hooks.

When XSM_ENABLE is not defined or when the dummy XSM module is used,
this patch should not change any functionality. Because the locations of
privilege checks have sometimes moved below argument validation, error
returns of some functions may change from EPERM to EINVAL or ESRCH if
called with invalid arguments and from a domain without permission to
perform the operation.

Some checks are removed due to non-obvious duplicates in their callers:

 * acpi_enter_sleep is checked in XENPF_enter_acpi_sleep
 * map_domain_pirq has IS_PRIV_FOR checked in its callers:
   * physdev_map_pirq checks when acquiring the RCU lock
   * ioapic_guest_write is checked in PHYSDEVOP_apic_write
 * PHYSDEVOP_{manage_pci_add,manage_pci_add_ext,pci_device_add} are
   checked by xsm_resource_plug_pci in pci_add_device
 * PHYSDEVOP_manage_pci_remove is checked by xsm_resource_unplug_pci
   in pci_remove_device
 * PHYSDEVOP_{restore_msi,restore_msi_ext} are checked by
   xsm_resource_setup_pci in pci_restore_msi_state
 * do_console_io has changed to IS_PRIV from an explicit domid==0

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Cc: Keir Fraser <keir@xen.org>
Cc: Jan Beulich <jbeulich@suse.com>
---
 xen/arch/x86/acpi/power.c     |  2 +-
 xen/arch/x86/cpu/mcheck/mce.c |  3 ---
 xen/arch/x86/irq.c            |  3 +--
 xen/arch/x86/mm.c             |  3 ---
 xen/arch/x86/physdev.c        | 54 ++-----------------------------------------
 xen/common/kexec.c            |  3 ---
 xen/common/schedule.c         |  6 -----
 xen/drivers/char/console.c    |  6 -----
 xen/include/xsm/dummy.h       | 28 ++++++++++++++++++++++
 xen/xsm/flask/hooks.c         |  5 ++--
 10 files changed, 35 insertions(+), 78 deletions(-)

diff --git a/xen/arch/x86/acpi/power.c b/xen/arch/x86/acpi/power.c
index 9e1f989..c7b37ef 100644
--- a/xen/arch/x86/acpi/power.c
+++ b/xen/arch/x86/acpi/power.c
@@ -238,7 +238,7 @@ static long enter_state_helper(void *data)
  */
 int acpi_enter_sleep(struct xenpf_enter_acpi_sleep *sleep)
 {
-    if ( !IS_PRIV(current->domain) || !acpi_sinfo.pm1a_cnt_blk.address )
+    if ( !acpi_sinfo.pm1a_cnt_blk.address )
         return -EPERM;
 
     /* Sanity check */
diff --git a/xen/arch/x86/cpu/mcheck/mce.c b/xen/arch/x86/cpu/mcheck/mce.c
index a89df6d..f399054 100644
--- a/xen/arch/x86/cpu/mcheck/mce.c
+++ b/xen/arch/x86/cpu/mcheck/mce.c
@@ -1379,9 +1379,6 @@ long do_mca(XEN_GUEST_HANDLE(xen_mc_t) u_xen_mc)
     struct xen_mc_msrinject *mc_msrinject;
     struct xen_mc_mceinject *mc_mceinject;
 
-    if (!IS_PRIV(v->domain) )
-        return x86_mcerr(NULL, -EPERM);
-
     ret = xsm_do_mca();
     if ( ret )
         return x86_mcerr(NULL, ret);
diff --git a/xen/arch/x86/irq.c b/xen/arch/x86/irq.c
index c87027b..70b0f03 100644
--- a/xen/arch/x86/irq.c
+++ b/xen/arch/x86/irq.c
@@ -1853,8 +1853,7 @@ int map_domain_pirq(
     ASSERT(spin_is_locked(&d->event_lock));
 
     if ( !IS_PRIV(current->domain) &&
-         !(IS_PRIV_FOR(current->domain, d) &&
-           irq_access_permitted(current->domain, pirq)))
+         !irq_access_permitted(current->domain, pirq))
         return -EPERM;
 
     if ( pirq < 0 || pirq >= d->nr_pirqs || irq < 0 || irq >= nr_irqs )
diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
index 4ea5334..b370300 100644
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -4488,9 +4488,6 @@ long arch_memory_op(int op, XEN_GUEST_HANDLE(void) arg)
         XEN_GUEST_HANDLE(e820entry_t) buffer;
         unsigned int i;
 
-        if ( !IS_PRIV(current->domain) )
-            return -EINVAL;
-
         rc = xsm_machine_memory_map();
         if ( rc )
             return rc;
diff --git a/xen/arch/x86/physdev.c b/xen/arch/x86/physdev.c
index 13b85da..515dca3 100644
--- a/xen/arch/x86/physdev.c
+++ b/xen/arch/x86/physdev.c
@@ -109,12 +109,6 @@ int physdev_map_pirq(domid_t domid, int type, int *index, int *pirq_p,
     if ( ret )
         return ret;
 
-    if ( !IS_PRIV_FOR(current->domain, d) )
-    {
-        ret = -EPERM;
-        goto free_domain;
-    }
-
     /* Verify or get irq. */
     switch ( type )
     {
@@ -238,10 +232,6 @@ int physdev_unmap_pirq(domid_t domid, int pirq)
             goto free_domain;
     }
 
-    ret = -EPERM;
-    if ( !IS_PRIV_FOR(current->domain, d) )
-        goto free_domain;
-
     ret = xsm_unmap_domain_pirq(d, domain_pirq_to_irq(d, pirq));
     if ( ret )
         goto free_domain;
@@ -433,9 +423,6 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_HANDLE(void) arg)
         ret = -EFAULT;
         if ( copy_from_guest(&apic, arg, 1) != 0 )
             break;
-        ret = -EPERM;
-        if ( !IS_PRIV(v->domain) )
-            break;
         ret = xsm_apic(v->domain, cmd);
         if ( ret )
             break;
@@ -450,9 +437,6 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_HANDLE(void) arg)
         ret = -EFAULT;
         if ( copy_from_guest(&apic, arg, 1) != 0 )
             break;
-        ret = -EPERM;
-        if ( !IS_PRIV(v->domain) )
-            break;
         ret = xsm_apic(v->domain, cmd);
         if ( ret )
             break;
@@ -467,8 +451,8 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_HANDLE(void) arg)
         if ( copy_from_guest(&irq_op, arg, 1) != 0 )
             break;
 
-        ret = -EPERM;
-        if ( !IS_PRIV(v->domain) )
+        ret = xsm_apic(v->domain, cmd);
+        if ( ret )
             break;
 
         /* Vector is only used by hypervisor, and dom0 shouldn't
@@ -517,9 +501,6 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_HANDLE(void) arg)
 
     case PHYSDEVOP_manage_pci_add: {
         struct physdev_manage_pci manage_pci;
-        ret = -EPERM;
-        if ( !IS_PRIV(v->domain) )
-            break;
         ret = -EFAULT;
         if ( copy_from_guest(&manage_pci, arg, 1) != 0 )
             break;
@@ -530,9 +511,6 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_HANDLE(void) arg)
 
     case PHYSDEVOP_manage_pci_remove: {
         struct physdev_manage_pci manage_pci;
-        ret = -EPERM;
-        if ( !IS_PRIV(v->domain) )
-            break;
         ret = -EFAULT;
         if ( copy_from_guest(&manage_pci, arg, 1) != 0 )
             break;
@@ -545,10 +523,6 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_HANDLE(void) arg)
         struct physdev_manage_pci_ext manage_pci_ext;
         struct pci_dev_info pdev_info;
 
-        ret = -EPERM;
-        if ( !IS_PRIV(current->domain) )
-            break;
-
         ret = -EFAULT;
         if ( copy_from_guest(&manage_pci_ext, arg, 1) != 0 )
             break;
@@ -571,10 +545,6 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_HANDLE(void) arg)
         struct physdev_pci_device_add add;
         struct pci_dev_info pdev_info;
 
-        ret = -EPERM;
-        if ( !IS_PRIV(current->domain) )
-            break;
-
         ret = -EFAULT;
         if ( copy_from_guest(&add, arg, 1) != 0 )
             break;
@@ -595,10 +565,6 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_HANDLE(void) arg)
     case PHYSDEVOP_pci_device_remove: {
         struct physdev_pci_device dev;
 
-        ret = -EPERM;
-        if ( !IS_PRIV(v->domain) )
-            break;
-
         ret = -EFAULT;
         if ( copy_from_guest(&dev, arg, 1) != 0 )
             break;
@@ -610,10 +576,6 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_HANDLE(void) arg)
     case PHYSDEVOP_pci_mmcfg_reserved: {
         struct physdev_pci_mmcfg_reserved info;
 
-        ret = -EPERM;
-        if ( !IS_PRIV(current->domain) )
-            break;
-
         ret = xsm_resource_setup_misc();
         if ( ret )
             break;
@@ -631,10 +593,6 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_HANDLE(void) arg)
         struct physdev_restore_msi restore_msi;
         struct pci_dev *pdev;
 
-        ret = -EPERM;
-        if ( !IS_PRIV(v->domain) )
-            break;
-
         ret = -EFAULT;
         if ( copy_from_guest(&restore_msi, arg, 1) != 0 )
             break;
@@ -650,10 +608,6 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_HANDLE(void) arg)
         struct physdev_pci_device dev;
         struct pci_dev *pdev;
 
-        ret = -EPERM;
-        if ( !IS_PRIV(v->domain) )
-            break;
-
         ret = -EFAULT;
         if ( copy_from_guest(&dev, arg, 1) != 0 )
             break;
@@ -668,10 +622,6 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_HANDLE(void) arg)
     case PHYSDEVOP_setup_gsi: {
         struct physdev_setup_gsi setup_gsi;
 
-        ret = -EPERM;
-        if ( !IS_PRIV(v->domain) )
-            break;
-
         ret = -EFAULT;
         if ( copy_from_guest(&setup_gsi, arg, 1) != 0 )
             break;
diff --git a/xen/common/kexec.c b/xen/common/kexec.c
index 2bc3e33..7dc6f24 100644
--- a/xen/common/kexec.c
+++ b/xen/common/kexec.c
@@ -851,9 +851,6 @@ static int do_kexec_op_internal(unsigned long op, XEN_GUEST_HANDLE(void) uarg,
     unsigned long flags;
     int ret = -EINVAL;
 
-    if ( !IS_PRIV(current->domain) )
-        return -EPERM;
-
     ret = xsm_kexec();
     if ( ret )
         return ret;
diff --git a/xen/common/schedule.c b/xen/common/schedule.c
index eee74be..95142c0 100644
--- a/xen/common/schedule.c
+++ b/xen/common/schedule.c
@@ -919,12 +919,6 @@ ret_t do_sched_op(int cmd, XEN_GUEST_HANDLE(void) arg)
         if ( d == NULL )
             break;
 
-        if ( !IS_PRIV_FOR(current->domain, d) )
-        {
-            rcu_unlock_domain(d);
-            return -EPERM;
-        }
-
         ret = xsm_schedop_shutdown(current->domain, d);
         if ( ret )
         {
diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c
index d97170c..aee3b4b 100644
--- a/xen/drivers/char/console.c
+++ b/xen/drivers/char/console.c
@@ -363,12 +363,6 @@ long do_console_io(int cmd, int count, XEN_GUEST_HANDLE(char) buffer)
     long rc;
     unsigned int idx, len;
 
-#ifndef VERBOSE
-    /* Only domain 0 may access the emergency console. */
-    if ( current->domain->domain_id != 0 )
-        return -EPERM;
-#endif
-
     rc = xsm_console_io(current->domain, cmd);
     if ( rc )
         return rc;
diff --git a/xen/include/xsm/dummy.h b/xen/include/xsm/dummy.h
index 61c6f13..389d9f6 100644
--- a/xen/include/xsm/dummy.h
+++ b/xen/include/xsm/dummy.h
@@ -161,6 +161,8 @@ static XSM_DEFAULT(int, pm_op) (void)
 
 static XSM_DEFAULT(int, do_mca) (void)
 {
+    if ( !IS_PRIV(current->domain) )
+        return -EPERM;
     return 0;
 }
 
@@ -223,6 +225,10 @@ static XSM_DEFAULT(int, memory_stat_reservation) (struct domain *d1, struct doma
 
 static XSM_DEFAULT(int, console_io) (struct domain *d, int cmd)
 {
+#ifndef VERBOSE
+    if ( !IS_PRIV(current->domain) )
+        return -EPERM;
+#endif
     return 0;
 }
 
@@ -233,11 +239,15 @@ static XSM_DEFAULT(int, profile) (struct domain *d, int op)
 
 static XSM_DEFAULT(int, kexec) (void)
 {
+    if ( !IS_PRIV(current->domain) )
+        return -EPERM;
     return 0;
 }
 
 static XSM_DEFAULT(int, schedop_shutdown) (struct domain *d1, struct domain *d2)
 {
+    if ( !IS_PRIV_FOR(d1, d2) )
+        return -EPERM;
     return 0;
 }
 
@@ -336,26 +346,36 @@ static XSM_DEFAULT(int, resource_unplug_core) (void)
 
 static XSM_DEFAULT(int, resource_plug_pci) (uint32_t machine_bdf)
 {
+    if ( !IS_PRIV(current->domain) )
+        return -EPERM;
     return 0;
 }
 
 static XSM_DEFAULT(int, resource_unplug_pci) (uint32_t machine_bdf)
 {
+    if ( !IS_PRIV(current->domain) )
+        return -EPERM;
     return 0;
 }
 
 static XSM_DEFAULT(int, resource_setup_pci) (uint32_t machine_bdf)
 {
+    if ( !IS_PRIV(current->domain) )
+        return -EPERM;
     return 0;
 }
 
 static XSM_DEFAULT(int, resource_setup_gsi) (int gsi)
 {
+    if ( !IS_PRIV(current->domain) )
+        return -EPERM;
     return 0;
 }
 
 static XSM_DEFAULT(int, resource_setup_misc) (void)
 {
+    if ( !IS_PRIV(current->domain) )
+        return -EPERM;
     return 0;
 }
 
@@ -396,6 +416,8 @@ static XSM_DEFAULT(int, map_domain_pirq) (struct domain *d, int irq, void *data)
 
 static XSM_DEFAULT(int, unmap_domain_pirq) (struct domain *d, int irq)
 {
+    if ( !IS_PRIV_FOR(current->domain, d) )
+        return -EPERM;
     return 0;
 }
 
@@ -494,6 +516,8 @@ static XSM_DEFAULT(int, mem_sharing) (struct domain *d)
 
 static XSM_DEFAULT(int, apic) (struct domain *d, int cmd)
 {
+    if ( !IS_PRIV(d) )
+        return -EPERM;
     return 0;
 }
 
@@ -534,6 +558,8 @@ static XSM_DEFAULT(int, efi_call) (void)
 
 static XSM_DEFAULT(int, acpi_sleep) (void)
 {
+    if ( !IS_PRIV(current->domain) )
+        return -EPERM;
     return 0;
 }
 
@@ -549,6 +575,8 @@ static XSM_DEFAULT(int, getidletime) (void)
 
 static XSM_DEFAULT(int, machine_memory_map) (void)
 {
+    if ( !IS_PRIV(current->domain) )
+        return -EPERM;
     return 0;
 }
 
diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
index 6d4b4f0..10c2163 100644
--- a/xen/xsm/flask/hooks.c
+++ b/xen/xsm/flask/hooks.c
@@ -1147,10 +1147,11 @@ static int flask_apic(struct domain *d, int cmd)
 
     switch ( cmd )
     {
-    case PHYSDEVOP_APIC_READ:
+    case PHYSDEVOP_apic_read:
+    case PHYSDEVOP_alloc_irq_vector:
         perm = XEN__READAPIC;
         break;
-    case PHYSDEVOP_APIC_WRITE:
+    case PHYSDEVOP_apic_write:
         perm = XEN__WRITEAPIC;
         break;
     default:
-- 
1.7.11.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 12 16:00:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Sep 2012 16:00:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TBpM5-0005OB-U2; Wed, 12 Sep 2012 15:59:57 +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 1TBpM4-0005My-Bq
	for xen-devel@lists.xen.org; Wed, 12 Sep 2012 15:59:56 +0000
Received: from [85.158.138.51:6627] by server-4.bemta-3.messagelabs.com id
	05/46-24831-B71B0505; Wed, 12 Sep 2012 15:59:55 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-5.tower-174.messagelabs.com!1347465592!30279670!1
X-Originating-IP: [63.239.67.9]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11843 invoked from network); 12 Sep 2012 15:59:52 -0000
Received: from emvm-gh1-uea08.nsa.gov (HELO nsa.gov) (63.239.67.9)
	by server-5.tower-174.messagelabs.com with SMTP;
	12 Sep 2012 15:59:52 -0000
X-TM-IMSS-Message-ID: <39e156f80010233c@nsa.gov>
Received: from tarius.tycho.ncsc.mil ([144.51.3.1]) by nsa.gov ([63.239.67.9])
	with ESMTP (TREND IMSS SMTP Service 7.1) id 39e156f80010233c ;
	Wed, 12 Sep 2012 11:59:42 -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 q8CFxoOC006669; 
	Wed, 12 Sep 2012 11:59:50 -0400
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xen.org
Date: Wed, 12 Sep 2012 11:59:26 -0400
Message-Id: <1347465586-20009-3-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.11.4
In-Reply-To: <1347465586-20009-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1347465586-20009-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: dgdegra@tycho.nsa.gov
Subject: [Xen-devel] [PATCH 02/22] xsm/flask: remove unneeded create_sid
	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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This field was only used to populate the ssid of dom0, which can be
handled explicitly in the domain creation hook. This also removes the
unnecessary permission check on the creation of dom0.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 tools/flask/policy/policy/modules/xen/xen.te |  2 --
 xen/xsm/flask/hooks.c                        | 23 ++++++++++-------------
 xen/xsm/flask/include/objsec.h               |  1 -
 3 files changed, 10 insertions(+), 16 deletions(-)

diff --git a/tools/flask/policy/policy/modules/xen/xen.te b/tools/flask/policy/policy/modules/xen/xen.te
index e175d4b..9cc5240 100644
--- a/tools/flask/policy/policy/modules/xen/xen.te
+++ b/tools/flask/policy/policy/modules/xen/xen.te
@@ -52,8 +52,6 @@ type device_t, resource_type;
 # Rules required to boot the hypervisor and dom0
 #
 ################################################################################
-allow xen_t dom0_t:domain { create };
-
 allow dom0_t xen_t:xen { kexec readapic writeapic mtrr_read mtrr_add mtrr_del
 	scheduler physinfo heap quirk readconsole writeconsole settime getcpuinfo
 	microcode cpupool_op sched_op pm_op };
diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
index 8c853de..88fef9c 100644
--- a/xen/xsm/flask/hooks.c
+++ b/xen/xsm/flask/hooks.c
@@ -108,12 +108,10 @@ static int flask_domain_alloc_security(struct domain *d)
 
     memset(dsec, 0, sizeof(struct domain_security_struct));
 
-    dsec->create_sid = SECSID_NULL;
     switch ( d->domain_id )
     {
     case DOMID_IDLE:
         dsec->sid = SECINITSID_XEN;
-        dsec->create_sid = SECINITSID_DOM0;
         break;
     case DOMID_XEN:
         dsec->sid = SECINITSID_DOMXEN;
@@ -489,25 +487,24 @@ static int flask_domain_create(struct domain *d, u32 ssidref)
     int rc;
     struct domain_security_struct *dsec1;
     struct domain_security_struct *dsec2;
+    static int dom0_created = 0;
 
     dsec1 = current->domain->ssid;
+    dsec2 = d->ssid;
 
-    if ( dsec1->create_sid == SECSID_NULL ) 
-        dsec1->create_sid = ssidref;
+    if ( is_idle_domain(current->domain) && !dom0_created )
+    {
+        dsec2->sid = SECINITSID_DOM0;
+        dom0_created = 1;
+        return 0;
+    }
 
-    rc = avc_has_perm(dsec1->sid, dsec1->create_sid, SECCLASS_DOMAIN, 
+    rc = avc_has_perm(dsec1->sid, ssidref, SECCLASS_DOMAIN,
                       DOMAIN__CREATE, NULL);
     if ( rc )
-    {
-        dsec1->create_sid = SECSID_NULL;
         return rc;
-    }
-
-    dsec2 = d->ssid;
-    dsec2->sid = dsec1->create_sid;
 
-    dsec1->create_sid = SECSID_NULL;
-    dsec2->create_sid = SECSID_NULL;
+    dsec2->sid = ssidref;
 
     return rc;
 }
diff --git a/xen/xsm/flask/include/objsec.h b/xen/xsm/flask/include/objsec.h
index df5baee..4ff52be 100644
--- a/xen/xsm/flask/include/objsec.h
+++ b/xen/xsm/flask/include/objsec.h
@@ -19,7 +19,6 @@
 
 struct domain_security_struct {
     u32 sid;               /* current SID */
-    u32 create_sid;
 };
 
 struct evtchn_security_struct {
-- 
1.7.11.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 12 16:00:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Sep 2012 16:00:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TBpME-0005nC-Bq; Wed, 12 Sep 2012 16:00:06 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1TBpMB-0005O0-12
	for xen-devel@lists.xen.org; Wed, 12 Sep 2012 16:00:03 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-11.tower-27.messagelabs.com!1347465595!3815672!1
X-Originating-IP: [63.239.67.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5269 invoked from network); 12 Sep 2012 15:59:56 -0000
Received: from emvm-gh1-uea09.nsa.gov (HELO nsa.gov) (63.239.67.10)
	by server-11.tower-27.messagelabs.com with SMTP;
	12 Sep 2012 15:59:56 -0000
X-TM-IMSS-Message-ID: <39e12001001083d9@nsa.gov>
Received: from tarius.tycho.ncsc.mil ([144.51.3.1]) by nsa.gov
	([63.239.67.10]) with ESMTP (TREND IMSS SMTP Service 7.1) id
	39e12001001083d9 ; Wed, 12 Sep 2012 12:02:01 -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 q8CFxoON006669; 
	Wed, 12 Sep 2012 11:59:54 -0400
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xen.org
Date: Wed, 12 Sep 2012 11:59:37 -0400
Message-Id: <1347465586-20009-14-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.11.4
In-Reply-To: <1347465586-20009-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1347465586-20009-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: dgdegra@tycho.nsa.gov, Keir Fraser <keir@xen.org>,
	Jan Beulich <jbeulich@suse.com>
Subject: [Xen-devel] [PATCH 13/22] xen: lock target domain in do_domctl
	common code
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 almost all domctls need to lock the target domain, do this by
default instead of repeating it in each domctl. This is not currently
extended to the arch-specific domctls, but RCU locks are safe to take
recursively so this only causes duplicate but correct locking.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Cc: Keir Fraser <keir@xen.org>
Cc: Jan Beulich <jbeulich@suse.com>
---
 xen/common/domctl.c | 267 ++++++++++++----------------------------------------
 1 file changed, 58 insertions(+), 209 deletions(-)

diff --git a/xen/common/domctl.c b/xen/common/domctl.c
index d99ba67..76ced4f 100644
--- a/xen/common/domctl.c
+++ b/xen/common/domctl.c
@@ -243,6 +243,7 @@ long do_domctl(XEN_GUEST_HANDLE(xen_domctl_t) u_domctl)
 {
     long ret = 0;
     struct xen_domctl curop, *op = &curop;
+    struct domain *d;
 
     if ( copy_from_guest(op, u_domctl, 1) )
         return -EFAULT;
@@ -252,19 +253,28 @@ long do_domctl(XEN_GUEST_HANDLE(xen_domctl_t) u_domctl)
 
     switch ( op->cmd )
     {
+    case XEN_DOMCTL_createdomain:
+    case XEN_DOMCTL_getdomaininfo:
+        d = NULL;
+        break;
+    default:
+        d = rcu_lock_domain_by_id(op->domain);
+        if ( d == NULL )
+            return -ESRCH;
+    }
+
+    switch ( op->cmd )
+    {
     case XEN_DOMCTL_ioport_mapping:
     case XEN_DOMCTL_memory_mapping:
     case XEN_DOMCTL_bind_pt_irq:
     case XEN_DOMCTL_unbind_pt_irq: {
-        struct domain *d;
-        bool_t is_priv = IS_PRIV(current->domain);
-        if ( !is_priv && ((d = rcu_lock_domain_by_id(op->domain)) != NULL) )
+        bool_t is_priv = IS_PRIV_FOR(current->domain, d);
+        if ( !is_priv )
         {
-            is_priv = IS_PRIV_FOR(current->domain, d);
-            rcu_unlock_domain(d);
+            ret = -EPERM;
+            goto domctl_out_unlock;
         }
-        if ( !is_priv )
-            return -EPERM;
         break;
     }
     case XEN_DOMCTL_getdomaininfo:
@@ -276,15 +286,18 @@ long do_domctl(XEN_GUEST_HANDLE(xen_domctl_t) u_domctl)
     }
 
     if ( !domctl_lock_acquire() )
+    {
+        if ( d )
+            rcu_unlock_domain(d);
         return hypercall_create_continuation(
             __HYPERVISOR_domctl, "h", u_domctl);
+    }
 
     switch ( op->cmd )
     {
 
     case XEN_DOMCTL_setvcpucontext:
     {
-        struct domain *d = rcu_lock_domain_by_id(op->domain);
         vcpu_guest_context_u c = { .nat = NULL };
         unsigned int vcpu = op->u.vcpucontext.vcpu;
         struct vcpu *v;
@@ -338,77 +351,48 @@ long do_domctl(XEN_GUEST_HANDLE(xen_domctl_t) u_domctl)
 
     svc_out:
         free_vcpu_guest_context(c.nat);
-        rcu_unlock_domain(d);
     }
     break;
 
     case XEN_DOMCTL_pausedomain:
     {
-        struct domain *d = rcu_lock_domain_by_id(op->domain);
-        ret = -ESRCH;
-        if ( d != NULL )
-        {
-            ret = xsm_pausedomain(d);
-            if ( ret )
-                goto pausedomain_out;
+        ret = xsm_pausedomain(d);
+        if ( ret )
+            break;
 
-            ret = -EINVAL;
-            if ( d != current->domain )
-            {
-                domain_pause_by_systemcontroller(d);
-                ret = 0;
-            }
-        pausedomain_out:
-            rcu_unlock_domain(d);
+        ret = -EINVAL;
+        if ( d != current->domain )
+        {
+            domain_pause_by_systemcontroller(d);
+            ret = 0;
         }
     }
     break;
 
     case XEN_DOMCTL_unpausedomain:
     {
-        struct domain *d = rcu_lock_domain_by_id(op->domain);
-
-        ret = -ESRCH;
-        if ( d == NULL )
-            break;
-
         ret = xsm_unpausedomain(d);
         if ( ret )
-        {
-            rcu_unlock_domain(d);
             break;
-        }
 
         domain_unpause_by_systemcontroller(d);
-        rcu_unlock_domain(d);
         ret = 0;
     }
     break;
 
     case XEN_DOMCTL_resumedomain:
     {
-        struct domain *d = rcu_lock_domain_by_id(op->domain);
-
-        ret = -ESRCH;
-        if ( d == NULL )
-            break;
-
         ret = xsm_resumedomain(d);
         if ( ret )
-        {
-            rcu_unlock_domain(d);
             break;
-        }
 
         domain_resume(d);
-        rcu_unlock_domain(d);
         ret = 0;
     }
     break;
 
     case XEN_DOMCTL_createdomain:
     {
-        struct domain *d;
         domid_t        dom;
         static domid_t rover = 0;
         unsigned int domcr_flags;
@@ -458,6 +442,7 @@ long do_domctl(XEN_GUEST_HANDLE(xen_domctl_t) u_domctl)
         if ( IS_ERR(d) )
         {
             ret = PTR_ERR(d);
+            d = NULL;
             break;
         }
 
@@ -469,39 +454,28 @@ long do_domctl(XEN_GUEST_HANDLE(xen_domctl_t) u_domctl)
         op->domain = d->domain_id;
         if ( copy_to_guest(u_domctl, op, 1) )
             ret = -EFAULT;
+        d = NULL;
     }
     break;
 
     case XEN_DOMCTL_max_vcpus:
     {
-        struct domain *d;
         unsigned int i, max = op->u.max_vcpus.max, cpu;
         cpumask_t *online;
 
-        ret = -ESRCH;
-        if ( (d = rcu_lock_domain_by_id(op->domain)) == NULL )
-            break;
-
         ret = -EINVAL;
         if ( (d == current->domain) || /* no domain_pause() */
              (max > MAX_VIRT_CPUS) ||
              (is_hvm_domain(d) && (max > MAX_HVM_VCPUS)) )
-        {
-            rcu_unlock_domain(d);
             break;
-        }
 
         ret = xsm_max_vcpus(d);
         if ( ret )
-        {
-            rcu_unlock_domain(d);
             break;
-        }
 
         /* Until Xenoprof can dynamically grow its vcpu-s array... */
         if ( d->xenoprof )
         {
-            rcu_unlock_domain(d);
             ret = -EAGAIN;
             break;
         }
@@ -576,44 +550,31 @@ long do_domctl(XEN_GUEST_HANDLE(xen_domctl_t) u_domctl)
 
     maxvcpu_out_novcpulock:
         domain_unpause(d);
-        rcu_unlock_domain(d);
     }
     break;
 
     case XEN_DOMCTL_destroydomain:
     {
-        struct domain *d = rcu_lock_domain_by_id(op->domain);
-        ret = -ESRCH;
-        if ( d != NULL )
-        {
-            ret = xsm_destroydomain(d) ? : domain_kill(d);
-            rcu_unlock_domain(d);
-        }
+        ret = xsm_destroydomain(d) ? : domain_kill(d);
     }
     break;
 
     case XEN_DOMCTL_setvcpuaffinity:
     case XEN_DOMCTL_getvcpuaffinity:
     {
-        domid_t dom = op->domain;
-        struct domain *d = rcu_lock_domain_by_id(dom);
         struct vcpu *v;
 
-        ret = -ESRCH;
-        if ( d == NULL )
-            break;
-
         ret = xsm_vcpuaffinity(op->cmd, d);
         if ( ret )
-            goto vcpuaffinity_out;
+            break;
 
         ret = -EINVAL;
         if ( op->u.vcpuaffinity.vcpu >= d->max_vcpus )
-            goto vcpuaffinity_out;
+            break;
 
         ret = -ESRCH;
         if ( (v = d->vcpu[op->u.vcpuaffinity.vcpu]) == NULL )
-            goto vcpuaffinity_out;
+            break;
 
         if ( op->cmd == XEN_DOMCTL_setvcpuaffinity )
         {
@@ -632,36 +593,23 @@ long do_domctl(XEN_GUEST_HANDLE(xen_domctl_t) u_domctl)
             ret = cpumask_to_xenctl_cpumap(
                 &op->u.vcpuaffinity.cpumap, v->cpu_affinity);
         }
-
-    vcpuaffinity_out:
-        rcu_unlock_domain(d);
     }
     break;
 
     case XEN_DOMCTL_scheduler_op:
     {
-        struct domain *d;
-
-        ret = -ESRCH;
-        if ( (d = rcu_lock_domain_by_id(op->domain)) == NULL )
-            break;
-
         ret = xsm_scheduler(d);
         if ( ret )
-            goto scheduler_op_out;
+            break;
 
         ret = sched_adjust(d, &op->u.scheduler_op);
         if ( copy_to_guest(u_domctl, op, 1) )
             ret = -EFAULT;
-
-    scheduler_op_out:
-        rcu_unlock_domain(d);
     }
     break;
 
     case XEN_DOMCTL_getdomaininfo:
     { 
-        struct domain *d;
         domid_t dom = op->domain;
 
         rcu_read_lock(&domlist_read_lock);
@@ -689,19 +637,15 @@ long do_domctl(XEN_GUEST_HANDLE(xen_domctl_t) u_domctl)
 
     getdomaininfo_out:
         rcu_read_unlock(&domlist_read_lock);
+        d = NULL;
     }
     break;
 
     case XEN_DOMCTL_getvcpucontext:
     { 
         vcpu_guest_context_u c = { .nat = NULL };
-        struct domain       *d;
         struct vcpu         *v;
 
-        ret = -ESRCH;
-        if ( (d = rcu_lock_domain_by_id(op->domain)) == NULL )
-            break;
-
         ret = xsm_getvcpucontext(d);
         if ( ret )
             goto getvcpucontext_out;
@@ -750,31 +694,25 @@ long do_domctl(XEN_GUEST_HANDLE(xen_domctl_t) u_domctl)
 
     getvcpucontext_out:
         xfree(c.nat);
-        rcu_unlock_domain(d);
     }
     break;
 
     case XEN_DOMCTL_getvcpuinfo:
     { 
-        struct domain *d;
         struct vcpu   *v;
         struct vcpu_runstate_info runstate;
 
-        ret = -ESRCH;
-        if ( (d = rcu_lock_domain_by_id(op->domain)) == NULL )
-            break;
-
         ret = xsm_getvcpuinfo(d);
         if ( ret )
-            goto getvcpuinfo_out;
+            break;
 
         ret = -EINVAL;
         if ( op->u.getvcpuinfo.vcpu >= d->max_vcpus )
-            goto getvcpuinfo_out;
+            break;
 
         ret = -ESRCH;
         if ( (v = d->vcpu[op->u.getvcpuinfo.vcpu]) == NULL )
-            goto getvcpuinfo_out;
+            break;
 
         vcpu_runstate_get(v, &runstate);
 
@@ -787,25 +725,16 @@ long do_domctl(XEN_GUEST_HANDLE(xen_domctl_t) u_domctl)
 
         if ( copy_to_guest(u_domctl, op, 1) )
             ret = -EFAULT;
-
-    getvcpuinfo_out:
-        rcu_unlock_domain(d);
     }
     break;
 
     case XEN_DOMCTL_max_mem:
     {
-        struct domain *d;
         unsigned long new_max;
 
-        ret = -ESRCH;
-        d = rcu_lock_domain_by_id(op->domain);
-        if ( d == NULL )
-            break;
-
         ret = xsm_setdomainmaxmem(d);
         if ( ret )
-            goto max_mem_out;
+            break;
 
         ret = -EINVAL;
         new_max = op->u.max_mem.max_memkb >> (PAGE_SHIFT-10);
@@ -819,77 +748,43 @@ long do_domctl(XEN_GUEST_HANDLE(xen_domctl_t) u_domctl)
         d->max_pages = new_max;
         ret = 0;
         spin_unlock(&d->page_alloc_lock);
-
-    max_mem_out:
-        rcu_unlock_domain(d);
     }
     break;
 
     case XEN_DOMCTL_setdomainhandle:
     {
-        struct domain *d;
-
-        ret = -ESRCH;
-        d = rcu_lock_domain_by_id(op->domain);
-        if ( d == NULL )
-            break;
-
         ret = xsm_setdomainhandle(d);
         if ( ret )
-        {
-            rcu_unlock_domain(d);
             break;
-        }
 
         memcpy(d->handle, op->u.setdomainhandle.handle,
                sizeof(xen_domain_handle_t));
-        rcu_unlock_domain(d);
         ret = 0;
     }
     break;
 
     case XEN_DOMCTL_setdebugging:
     {
-        struct domain *d;
-
-        ret = -ESRCH;
-        d = rcu_lock_domain_by_id(op->domain);
-        if ( d == NULL )
-            break;
-
         ret = -EINVAL;
         if ( d == current->domain ) /* no domain_pause() */
-        {
-            rcu_unlock_domain(d);
             break;
-        }
 
         ret = xsm_setdebugging(d);
         if ( ret )
-        {
-            rcu_unlock_domain(d);
             break;
-        }
 
         domain_pause(d);
         d->debugger_attached = !!op->u.setdebugging.enable;
         domain_unpause(d); /* causes guest to latch new status */
-        rcu_unlock_domain(d);
         ret = 0;
     }
     break;
 
     case XEN_DOMCTL_irq_permission:
     {
-        struct domain *d;
         unsigned int pirq = op->u.irq_permission.pirq;
         int allow = op->u.irq_permission.allow_access;
 
-        ret = -ESRCH;
-        d = rcu_lock_domain_by_id(op->domain);
-        if ( d == NULL )
-            break;
-
         if ( pirq >= d->nr_pirqs )
             ret = -EINVAL;
         else if ( xsm_irq_permission(d, pirq, allow) )
@@ -898,14 +793,11 @@ long do_domctl(XEN_GUEST_HANDLE(xen_domctl_t) u_domctl)
             ret = irq_permit_access(d, pirq);
         else
             ret = irq_deny_access(d, pirq);
-
-        rcu_unlock_domain(d);
     }
     break;
 
     case XEN_DOMCTL_iomem_permission:
     {
-        struct domain *d;
         unsigned long mfn = op->u.iomem_permission.first_mfn;
         unsigned long nr_mfns = op->u.iomem_permission.nr_mfns;
         int allow = op->u.iomem_permission.allow_access;
@@ -914,125 +806,78 @@ long do_domctl(XEN_GUEST_HANDLE(xen_domctl_t) u_domctl)
         if ( (mfn + nr_mfns - 1) < mfn ) /* wrap? */
             break;
 
-        ret = -ESRCH;
-        d = rcu_lock_domain_by_id(op->domain);
-        if ( d == NULL )
-            break;
-
         if ( xsm_iomem_permission(d, mfn, mfn + nr_mfns - 1, allow) )
             ret = -EPERM;
         else if ( allow )
             ret = iomem_permit_access(d, mfn, mfn + nr_mfns - 1);
         else
             ret = iomem_deny_access(d, mfn, mfn + nr_mfns - 1);
-
-        rcu_unlock_domain(d);
     }
     break;
 
     case XEN_DOMCTL_settimeoffset:
     {
-        struct domain *d;
-
-        ret = -ESRCH;
-        d = rcu_lock_domain_by_id(op->domain);
-        if ( d == NULL )
-            break;
-
         ret = xsm_domain_settime(d);
         if ( ret )
-        {
-            rcu_unlock_domain(d);
             break;
-        }
 
         domain_set_time_offset(d, op->u.settimeoffset.time_offset_seconds);
-        rcu_unlock_domain(d);
         ret = 0;
     }
     break;
 
     case XEN_DOMCTL_set_target:
     {
-        struct domain *d, *e;
-
-        ret = -ESRCH;
-        d = rcu_lock_domain_by_id(op->domain);
-        if ( d == NULL )
-            break;
+        struct domain *e;
 
         ret = -ESRCH;
         e = get_domain_by_id(op->u.set_target.target);
         if ( e == NULL )
-            goto set_target_out;
+            break;
 
         ret = -EINVAL;
         if ( (d == e) || (d->target != NULL) )
         {
             put_domain(e);
-            goto set_target_out;
+            break;
         }
 
         ret = xsm_set_target(d, e);
         if ( ret ) {
             put_domain(e);
-            goto set_target_out;            
+            break;
         }
 
         /* Hold reference on @e until we destroy @d. */
         d->target = e;
 
         ret = 0;
-
-    set_target_out:
-        rcu_unlock_domain(d);
     }
     break;
 
     case XEN_DOMCTL_subscribe:
     {
-        struct domain *d;
-
-        ret = -ESRCH;
-        d = rcu_lock_domain_by_id(op->domain);
-        if ( d != NULL )
-        {
-            ret = xsm_domctl(d, op->cmd);
-            if ( !ret )
-                d->suspend_evtchn = op->u.subscribe.port;
-            rcu_unlock_domain(d);
-        }
+        ret = xsm_domctl(d, op->cmd);
+        if ( !ret )
+            d->suspend_evtchn = op->u.subscribe.port;
     }
     break;
 
     case XEN_DOMCTL_disable_migrate:
     {
-        struct domain *d;
-        ret = -ESRCH;
-        if ( (d = rcu_lock_domain_by_id(op->domain)) != NULL )
-        {
-            ret = xsm_domctl(d, op->cmd);
-            if ( !ret )
-                d->disable_migrate = op->u.disable_migrate.disable;
-            rcu_unlock_domain(d);
-        }
+        ret = xsm_domctl(d, op->cmd);
+        if ( !ret )
+            d->disable_migrate = op->u.disable_migrate.disable;
     }
     break;
 
     case XEN_DOMCTL_set_virq_handler:
     {
-        struct domain *d;
         uint32_t virq = op->u.set_virq_handler.virq;
 
-        ret = -ESRCH;
-        d = rcu_lock_domain_by_id(op->domain);
-        if ( d != NULL )
-        {
-            ret = xsm_set_virq_handler(d, virq);
-            if ( !ret )
-                ret = set_global_virq_handler(d, virq);
-            rcu_unlock_domain(d);
-        }
+        ret = xsm_set_virq_handler(d, virq);
+        if ( !ret )
+            ret = set_global_virq_handler(d, virq);
     }
     break;
 
@@ -1043,6 +888,10 @@ long do_domctl(XEN_GUEST_HANDLE(xen_domctl_t) u_domctl)
 
     domctl_lock_release();
 
+ domctl_out_unlock:
+    if ( d )
+        rcu_unlock_domain(d);
+
     return ret;
 }
 
-- 
1.7.11.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 12 16:00:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Sep 2012 16:00:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TBpMD-0005kc-Bg; Wed, 12 Sep 2012 16:00:05 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1TBpMA-0005Nk-Pi
	for xen-devel@lists.xen.org; Wed, 12 Sep 2012 16:00:03 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-9.tower-27.messagelabs.com!1347465595!9477810!1
X-Originating-IP: [63.239.67.10]
X-SpamReason: No, hits=2.5 required=7.0 tests=BODY_RANDOM_LONG,LONGWORDS
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15449 invoked from network); 12 Sep 2012 15:59:56 -0000
Received: from emvm-gh1-uea09.nsa.gov (HELO nsa.gov) (63.239.67.10)
	by server-9.tower-27.messagelabs.com with SMTP;
	12 Sep 2012 15:59:56 -0000
X-TM-IMSS-Message-ID: <39e122de001083db@nsa.gov>
Received: from tarius.tycho.ncsc.mil ([144.51.3.1]) by nsa.gov
	([63.239.67.10]) with ESMTP (TREND IMSS SMTP Service 7.1) id
	39e122de001083db ; Wed, 12 Sep 2012 12:02:02 -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 q8CFxoOQ006669; 
	Wed, 12 Sep 2012 11:59:54 -0400
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xen.org
Date: Wed, 12 Sep 2012 11:59:40 -0400
Message-Id: <1347465586-20009-17-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.11.4
In-Reply-To: <1347465586-20009-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1347465586-20009-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: dgdegra@tycho.nsa.gov
Subject: [Xen-devel] [PATCH 16/22] xsm/flask: add missing hooks
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 FLASK module was missing implementations of some hooks and did not
have access vectors defined for 10 domctls; define these now.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 tools/flask/policy/policy/flask/access_vectors |  5 ++
 tools/flask/policy/policy/modules/xen/xen.if   |  4 +-
 xen/xsm/flask/hooks.c                          | 66 +++++++++++++++++++++-----
 xen/xsm/flask/include/av_perm_to_string.h      |  5 ++
 xen/xsm/flask/include/av_permissions.h         |  5 ++
 5 files changed, 73 insertions(+), 12 deletions(-)

diff --git a/tools/flask/policy/policy/flask/access_vectors b/tools/flask/policy/policy/flask/access_vectors
index 11d02da..ea65e45 100644
--- a/tools/flask/policy/policy/flask/access_vectors
+++ b/tools/flask/policy/policy/flask/access_vectors
@@ -80,6 +80,9 @@ class domain2
 	relabelself
 	make_priv_for
 	set_as_target
+	set_cpuid
+	gettsc
+	settsc
 }
 
 class hvm
@@ -97,6 +100,8 @@ class hvm
     hvmctl
     mem_event
     mem_sharing
+    audit_p2m
+    send_irq
 }
 
 class event
diff --git a/tools/flask/policy/policy/modules/xen/xen.if b/tools/flask/policy/policy/modules/xen/xen.if
index 2ad11b2..59ba171 100644
--- a/tools/flask/policy/policy/modules/xen/xen.if
+++ b/tools/flask/policy/policy/modules/xen/xen.if
@@ -29,6 +29,7 @@ define(`create_domain_common', `
 			getdomaininfo hypercall setvcpucontext setextvcpucontext
 			scheduler getvcpuinfo getvcpuextstate getaddrsize
 			getvcpuaffinity setvcpuaffinity };
+	allow $1 $2:domain2 { set_cpuid settsc };
 	allow $1 $2:security check_context;
 	allow $1 $2:shadow enable;
 	allow $1 $2:mmu {map_read map_write adjust memorymap physmap pinpage};
@@ -67,6 +68,7 @@ define(`migrate_domain_out', `
 	allow $1 $2:hvm { gethvmc getparam irqlevel };
 	allow $1 $2:mmu { stat pageinfo map_read };
 	allow $1 $2:domain { getaddrsize getvcpucontext getextvcpucontext getvcpuextstate pause destroy };
+	allow $1 $2:domain2 gettsc;
 ')
 
 ################################################################################
@@ -112,7 +114,7 @@ define(`device_model', `
 	domain_comms($1, $2)
 	allow $1 $2:domain { set_target shutdown };
 	allow $1 $2:mmu { map_read map_write adjust physmap };
-	allow $1 $2:hvm { getparam setparam trackdirtyvram hvmctl irqlevel pciroute };
+	allow $1 $2:hvm { getparam setparam trackdirtyvram hvmctl irqlevel pciroute cacheattr send_irq };
 ')
 ################################################################################
 #
diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
index 16af92b..3cb814d 100644
--- a/xen/xsm/flask/hooks.c
+++ b/xen/xsm/flask/hooks.c
@@ -650,25 +650,32 @@ static int flask_domctl(struct domain *d, int cmd)
 #endif
         return 0;
 
+    case XEN_DOMCTL_debug_op:
+    case XEN_DOMCTL_gdbsx_guestmemio:
+    case XEN_DOMCTL_gdbsx_pausevcpu:
+    case XEN_DOMCTL_gdbsx_unpausevcpu:
+    case XEN_DOMCTL_gdbsx_domstatus:
+        return domain_has_perm(current->domain, d, SECCLASS_DOMAIN,
+                               DOMAIN__SETDEBUGGING);
+
     case XEN_DOMCTL_subscribe:
     case XEN_DOMCTL_disable_migrate:
+    case XEN_DOMCTL_suppress_spurious_page_faults:
         return domain_has_perm(current->domain, d, SECCLASS_DOMAIN,
                                DOMAIN__SET_MISC_INFO);
 
     case XEN_DOMCTL_set_cpuid:
-    case XEN_DOMCTL_suppress_spurious_page_faults:
-    case XEN_DOMCTL_debug_op:
+        return domain_has_perm(current->domain, d, SECCLASS_DOMAIN2, DOMAIN2__SET_CPUID);
+
     case XEN_DOMCTL_gettscinfo:
+        return domain_has_perm(current->domain, d, SECCLASS_DOMAIN2, DOMAIN2__GETTSC);
+
     case XEN_DOMCTL_settscinfo:
+        return domain_has_perm(current->domain, d, SECCLASS_DOMAIN2, DOMAIN2__SETTSC);
+
     case XEN_DOMCTL_audit_p2m:
-    case XEN_DOMCTL_gdbsx_guestmemio:
-    case XEN_DOMCTL_gdbsx_pausevcpu:
-    case XEN_DOMCTL_gdbsx_unpausevcpu:
-    case XEN_DOMCTL_gdbsx_domstatus:
-        /* TODO add per-subfunction hooks */
-        if ( !IS_PRIV(current->domain) )
-            return -EPERM;
-        return 0;
+        return domain_has_perm(current->domain, d, SECCLASS_HVM, HVM__AUDIT_P2M);
+
     default:
         printk("flask_domctl: Unknown op %d\n", cmd);
         return -EPERM;
@@ -919,6 +926,11 @@ static int flask_iomem_permission(struct domain *d, uint64_t start, uint64_t end
     return security_iterate_iomem_sids(start, end, _iomem_has_perm, &data);
 }
 
+static int flask_iomem_mapping(struct domain *d, uint64_t start, uint64_t end, uint8_t access)
+{
+    return flask_iomem_permission(d, start, end, access);
+}
+
 static int flask_pci_config_permission(struct domain *d, uint32_t machine_bdf, uint16_t start, uint16_t end, uint8_t access)
 {
     u32 rsid;
@@ -1126,7 +1138,6 @@ static int _ioport_has_perm(void *v, u32 sid, unsigned long start, unsigned long
     return avc_has_perm(data->tsec->sid, sid, SECCLASS_RESOURCE, RESOURCE__USE, &ad);
 }
 
-
 static int flask_ioport_permission(struct domain *d, uint32_t start, uint32_t end, uint8_t access)
 {
     int rc;
@@ -1149,6 +1160,11 @@ static int flask_ioport_permission(struct domain *d, uint32_t start, uint32_t en
     return security_iterate_ioport_sids(start, end, _ioport_has_perm, &data);
 }
 
+static int flask_ioport_mapping(struct domain *d, uint32_t start, uint32_t end, uint8_t access)
+{
+    return flask_ioport_permission(d, start, end, access);
+}
+
 static int flask_getpageframeinfo(struct domain *d)
 {
     return domain_has_perm(current->domain, d, SECCLASS_MMU, MMU__PAGEINFO);
@@ -1207,6 +1223,25 @@ static int flask_address_size(struct domain *d, uint32_t cmd)
     return domain_has_perm(current->domain, d, SECCLASS_DOMAIN, perm);
 }
 
+static int flask_machine_address_size(struct domain *d, uint32_t cmd)
+{
+    u32 perm;
+
+    switch ( cmd )
+    {
+    case XEN_DOMCTL_set_machine_address_size:
+        perm = DOMAIN__SETADDRSIZE;
+        break;
+    case XEN_DOMCTL_get_machine_address_size:
+        perm = DOMAIN__GETADDRSIZE;
+        break;
+    default:
+        return -EPERM;
+    }
+
+    return domain_has_perm(current->domain, d, SECCLASS_DOMAIN, perm);
+}
+
 static int flask_hvm_param(struct domain *d, unsigned long op)
 {
     u32 perm;
@@ -1244,6 +1279,11 @@ static int flask_hvm_set_pci_link_route(struct domain *d)
     return domain_has_perm(current->domain, d, SECCLASS_HVM, HVM__PCIROUTE);
 }
 
+static int flask_hvm_inject_msi(struct domain *d)
+{
+    return domain_has_perm(current->domain, d, SECCLASS_HVM, HVM__SEND_IRQ);
+}
+
 static int flask_mem_event(struct domain *d)
 {
     return domain_has_perm(current->domain, d, SECCLASS_HVM, HVM__MEM_EVENT);
@@ -1687,6 +1727,7 @@ static struct xsm_operations flask_ops = {
     .unmap_domain_pirq = flask_unmap_domain_pirq,
     .irq_permission = flask_irq_permission,
     .iomem_permission = flask_iomem_permission,
+    .iomem_mapping = flask_iomem_mapping,
     .pci_config_permission = flask_pci_config_permission,
 
     .resource_plug_core = flask_resource_plug_core,
@@ -1711,10 +1752,12 @@ static struct xsm_operations flask_ops = {
     .hypercall_init = flask_hypercall_init,
     .hvmcontext = flask_hvmcontext,
     .address_size = flask_address_size,
+    .machine_address_size = flask_machine_address_size,
     .hvm_param = flask_hvm_param,
     .hvm_set_pci_intx_level = flask_hvm_set_pci_intx_level,
     .hvm_set_isa_irq_level = flask_hvm_set_isa_irq_level,
     .hvm_set_pci_link_route = flask_hvm_set_pci_link_route,
+    .hvm_inject_msi = flask_hvm_inject_msi,
     .mem_event = flask_mem_event,
     .mem_sharing = flask_mem_sharing,
     .apic = flask_apic,
@@ -1747,6 +1790,7 @@ static struct xsm_operations flask_ops = {
     .ext_vcpucontext = flask_ext_vcpucontext,
     .vcpuextstate = flask_vcpuextstate,
     .ioport_permission = flask_ioport_permission,
+    .ioport_mapping = flask_ioport_mapping,
 #endif
 };
 
diff --git a/xen/xsm/flask/include/av_perm_to_string.h b/xen/xsm/flask/include/av_perm_to_string.h
index 10f8e80..894910c 100644
--- a/xen/xsm/flask/include/av_perm_to_string.h
+++ b/xen/xsm/flask/include/av_perm_to_string.h
@@ -66,6 +66,9 @@
    S_(SECCLASS_DOMAIN2, DOMAIN2__RELABELSELF, "relabelself")
    S_(SECCLASS_DOMAIN2, DOMAIN2__MAKE_PRIV_FOR, "make_priv_for")
    S_(SECCLASS_DOMAIN2, DOMAIN2__SET_AS_TARGET, "set_as_target")
+   S_(SECCLASS_DOMAIN2, DOMAIN2__SET_CPUID, "set_cpuid")
+   S_(SECCLASS_DOMAIN2, DOMAIN2__GETTSC, "gettsc")
+   S_(SECCLASS_DOMAIN2, DOMAIN2__SETTSC, "settsc")
    S_(SECCLASS_HVM, HVM__SETHVMC, "sethvmc")
    S_(SECCLASS_HVM, HVM__GETHVMC, "gethvmc")
    S_(SECCLASS_HVM, HVM__SETPARAM, "setparam")
@@ -79,6 +82,8 @@
    S_(SECCLASS_HVM, HVM__HVMCTL, "hvmctl")
    S_(SECCLASS_HVM, HVM__MEM_EVENT, "mem_event")
    S_(SECCLASS_HVM, HVM__MEM_SHARING, "mem_sharing")
+   S_(SECCLASS_HVM, HVM__AUDIT_P2M, "audit_p2m")
+   S_(SECCLASS_HVM, HVM__SEND_IRQ, "send_irq")
    S_(SECCLASS_EVENT, EVENT__BIND, "bind")
    S_(SECCLASS_EVENT, EVENT__SEND, "send")
    S_(SECCLASS_EVENT, EVENT__STATUS, "status")
diff --git a/xen/xsm/flask/include/av_permissions.h b/xen/xsm/flask/include/av_permissions.h
index f7cfee1..1bdb515 100644
--- a/xen/xsm/flask/include/av_permissions.h
+++ b/xen/xsm/flask/include/av_permissions.h
@@ -68,6 +68,9 @@
 #define DOMAIN2__RELABELSELF                      0x00000004UL
 #define DOMAIN2__MAKE_PRIV_FOR                    0x00000008UL
 #define DOMAIN2__SET_AS_TARGET                    0x00000010UL
+#define DOMAIN2__SET_CPUID                        0x00000020UL
+#define DOMAIN2__GETTSC                           0x00000040UL
+#define DOMAIN2__SETTSC                           0x00000080UL
 
 #define HVM__SETHVMC                              0x00000001UL
 #define HVM__GETHVMC                              0x00000002UL
@@ -82,6 +85,8 @@
 #define HVM__HVMCTL                               0x00000400UL
 #define HVM__MEM_EVENT                            0x00000800UL
 #define HVM__MEM_SHARING                          0x00001000UL
+#define HVM__AUDIT_P2M                            0x00002000UL
+#define HVM__SEND_IRQ                             0x00004000UL
 
 #define EVENT__BIND                               0x00000001UL
 #define EVENT__SEND                               0x00000002UL
-- 
1.7.11.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 12 16:00:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Sep 2012 16:00:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TBpM4-0005NH-JZ; Wed, 12 Sep 2012 15:59:56 +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 1TBpM3-0005Mk-6k
	for xen-devel@lists.xen.org; Wed, 12 Sep 2012 15:59:55 +0000
Received: from [85.158.138.51:6711] by server-10.bemta-3.messagelabs.com id
	AE/62-10411-A71B0505; Wed, 12 Sep 2012 15:59:54 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-8.tower-174.messagelabs.com!1347465593!30148384!1
X-Originating-IP: [63.239.67.9]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5574 invoked from network); 12 Sep 2012 15:59:53 -0000
Received: from emvm-gh1-uea08.nsa.gov (HELO nsa.gov) (63.239.67.9)
	by server-8.tower-174.messagelabs.com with SMTP;
	12 Sep 2012 15:59:53 -0000
X-TM-IMSS-Message-ID: <39e159d500102340@nsa.gov>
Received: from tarius.tycho.ncsc.mil ([144.51.3.1]) by nsa.gov ([63.239.67.9])
	with ESMTP (TREND IMSS SMTP Service 7.1) id 39e159d500102340 ;
	Wed, 12 Sep 2012 11:59:43 -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 q8CFxoOD006669; 
	Wed, 12 Sep 2012 11:59:51 -0400
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xen.org
Date: Wed, 12 Sep 2012 11:59:27 -0400
Message-Id: <1347465586-20009-4-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.11.4
In-Reply-To: <1347465586-20009-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1347465586-20009-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: dgdegra@tycho.nsa.gov
Subject: [Xen-devel] [PATCH 03/22] xen: Add versions of rcu_lock_*_domain
	without IS_PRIV checks
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

These functions will be used to avoid duplication of IS_PRIV calls
that will be introduced in XSM hooks.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 xen/common/domain.c     | 21 +++++++++++++++++++++
 xen/include/xen/sched.h | 11 +++++++++++
 2 files changed, 32 insertions(+)

diff --git a/xen/common/domain.c b/xen/common/domain.c
index a1aa05e..52489b3 100644
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -420,6 +420,13 @@ struct domain *rcu_lock_domain_by_id(domid_t dom)
     return d;
 }
 
+struct domain *rcu_lock_domain_by_any_id(domid_t dom)
+{
+    if ( dom == DOMID_SELF )
+        return rcu_lock_current_domain();
+    return rcu_lock_domain_by_id(dom);
+}
+
 int rcu_lock_target_domain_by_id(domid_t dom, struct domain **d)
 {
     if ( dom == DOMID_SELF )
@@ -454,6 +461,20 @@ int rcu_lock_remote_target_domain_by_id(domid_t dom, struct domain **d)
     return 0;
 }
 
+int rcu_lock_remote_domain_by_id(domid_t dom, struct domain **d)
+{
+    if ( (*d = rcu_lock_domain_by_id(dom)) == NULL )
+        return -ESRCH;
+
+    if ( *d == current->domain )
+    {
+        rcu_unlock_domain(*d);
+        return -EPERM;
+    }
+
+    return 0;
+}
+
 int domain_kill(struct domain *d)
 {
     int rc = 0;
diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
index 53804c8..b0def4a 100644
--- a/xen/include/xen/sched.h
+++ b/xen/include/xen/sched.h
@@ -447,6 +447,11 @@ struct domain *domain_create(
 struct domain *rcu_lock_domain_by_id(domid_t dom);
 
 /*
+ * As above function, but resolves DOMID_SELF to current domain
+ */
+struct domain *rcu_lock_domain_by_any_id(domid_t dom);
+
+/*
  * As above function, but accounts for current domain context:
  *  - Translates target DOMID_SELF into caller's domain id; and
  *  - Checks that caller has permission to act on the target domain.
@@ -460,6 +465,12 @@ int rcu_lock_target_domain_by_id(domid_t dom, struct domain **d);
  */
 int rcu_lock_remote_target_domain_by_id(domid_t dom, struct domain **d);
 
+/*
+ * As rcu_lock_domain_by_id(), but will fail EPERM or ESRCH rather than resolve
+ * to local domain.
+ */
+int rcu_lock_remote_domain_by_id(domid_t dom, struct domain **d);
+
 /* Finish a RCU critical region started by rcu_lock_domain_by_id(). */
 static inline void rcu_unlock_domain(struct domain *d)
 {
-- 
1.7.11.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 12 16:00:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Sep 2012 16:00:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TBpM8-0005QI-Jo; Wed, 12 Sep 2012 16:00:00 +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 1TBpM7-0005N3-Do
	for xen-devel@lists.xen.org; Wed, 12 Sep 2012 15:59:59 +0000
Received: from [85.158.138.51:27115] by server-8.bemta-3.messagelabs.com id
	AD/63-24700-F71B0505; Wed, 12 Sep 2012 15:59:59 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-9.tower-174.messagelabs.com!1347465597!28508951!1
X-Originating-IP: [63.239.67.9]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14347 invoked from network); 12 Sep 2012 15:59:57 -0000
Received: from emvm-gh1-uea08.nsa.gov (HELO nsa.gov) (63.239.67.9)
	by server-9.tower-174.messagelabs.com with SMTP;
	12 Sep 2012 15:59:57 -0000
X-TM-IMSS-Message-ID: <39e16bfe0010234f@nsa.gov>
Received: from tarius.tycho.ncsc.mil ([144.51.3.1]) by nsa.gov ([63.239.67.9])
	with ESMTP (TREND IMSS SMTP Service 7.1) id 39e16bfe0010234f ;
	Wed, 12 Sep 2012 11:59:48 -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 q8CFxoOU006669; 
	Wed, 12 Sep 2012 11:59:56 -0400
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xen.org
Date: Wed, 12 Sep 2012 11:59:44 -0400
Message-Id: <1347465586-20009-21-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.11.4
In-Reply-To: <1347465586-20009-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1347465586-20009-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Tim Deegan <tim@xen.org>, dgdegra@tycho.nsa.gov, Keir Fraser <keir@xen.org>,
	Jan Beulich <jbeulich@suse.com>
Subject: [Xen-devel] [PATCH 20/22] arch/x86: use XSM hooks for get_pg_owner
	access checks
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

There are three callers of get_pg_owner:
 * do_mmuext_op, which does not have XSM hooks on all subfunctions
 * do_mmu_update, which has hooks that are inefficient
 * do_update_va_mapping_otherdomain, which has a simple XSM hook

In order to preserve return values for the do_mmuext_op hypercall, an
additional XSM hook is required to check the operation even for those
subfunctions that do not use the pg_owner field. This also covers the
MMUEXT_UNPIN_TABLE operation which did previously have an XSM hook.

The XSM hooks in do_mmu_update were capable of replacing the checks in
get_pg_owner; however, the hooks are buried in the inner loop of the
function - not very good for performance when XSM is enabled and these
turn in to indirect function calls. This patch removes the PTE from the
hooks and replaces it with a bitfield describing what accesses are being
requested. The XSM hook can then be called only when additional bits are
set instead of once per iteration of the loop.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Cc: Keir Fraser <keir@xen.org>
Cc: Jan Beulich <jbeulich@suse.com>
Cc: Tim Deegan <tim@xen.org>
---
 tools/flask/policy/policy/flask/access_vectors |  1 +
 tools/flask/policy/policy/modules/xen/xen.if   |  4 +-
 xen/arch/x86/mm.c                              | 53 +++++++++++--------
 xen/include/xsm/dummy.h                        | 15 ++++--
 xen/include/xsm/xsm.h                          | 25 +++++----
 xen/xsm/dummy.c                                |  4 +-
 xen/xsm/flask/hooks.c                          | 71 +++++++++-----------------
 xen/xsm/flask/include/av_perm_to_string.h      |  1 +
 xen/xsm/flask/include/av_permissions.h         |  1 +
 9 files changed, 88 insertions(+), 87 deletions(-)

diff --git a/tools/flask/policy/policy/flask/access_vectors b/tools/flask/policy/policy/flask/access_vectors
index 45ac437..8324725 100644
--- a/tools/flask/policy/policy/flask/access_vectors
+++ b/tools/flask/policy/policy/flask/access_vectors
@@ -141,6 +141,7 @@ class mmu
     mfnlist
     memorymap
     remote_remap
+	mmuext_op
 }
 
 class shadow
diff --git a/tools/flask/policy/policy/modules/xen/xen.if b/tools/flask/policy/policy/modules/xen/xen.if
index d630f47..725d7a1 100644
--- a/tools/flask/policy/policy/modules/xen/xen.if
+++ b/tools/flask/policy/policy/modules/xen/xen.if
@@ -7,7 +7,7 @@
 ################################################################################
 define(`declare_domain_common', `
 	allow $1 $2:grant { query setup };
-	allow $1 $2:mmu { adjust physmap map_read map_write stat pinpage updatemp };
+	allow $1 $2:mmu { adjust physmap map_read map_write stat pinpage updatemp mmuext_op };
 	allow $1 $2:hvm { getparam setparam };
 ')
 
@@ -51,7 +51,7 @@ define(`create_domain_common', `
 	allow $1 $2:domain2 { set_cpuid settsc };
 	allow $1 $2:security check_context;
 	allow $1 $2:shadow enable;
-	allow $1 $2:mmu {map_read map_write adjust memorymap physmap pinpage};
+	allow $1 $2:mmu { map_read map_write adjust memorymap physmap pinpage mmuext_op };
 	allow $1 $2:grant setup;
 	allow $1 $2:hvm { cacheattr getparam hvmctl irqlevel pciroute sethvmc setparam pcilevel trackdirtyvram };
 ')
diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
index c0c2bf3..04a056f 100644
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -2619,11 +2619,6 @@ static struct domain *get_pg_owner(domid_t domid)
         pg_owner = rcu_lock_domain(dom_io);
         break;
     case DOMID_XEN:
-        if ( !IS_PRIV(curr) )
-        {
-            MEM_LOG("Cannot set foreign dom");
-            break;
-        }
         pg_owner = rcu_lock_domain(dom_xen);
         break;
     default:
@@ -2632,12 +2627,6 @@ static struct domain *get_pg_owner(domid_t domid)
             MEM_LOG("Unknown domain '%u'", domid);
             break;
         }
-        if ( !IS_PRIV_FOR(curr, pg_owner) )
-        {
-            MEM_LOG("Cannot set foreign dom");
-            rcu_unlock_domain(pg_owner);
-            pg_owner = NULL;
-        }
         break;
     }
 
@@ -2725,6 +2714,13 @@ long do_mmuext_op(
         goto out;
     }
 
+    rc = xsm_mmuext_op(d, pg_owner);
+    if ( rc )
+    {
+        rcu_unlock_domain(pg_owner);
+        goto out;
+    }
+
     for ( i = 0; i < count; i++ )
     {
         if ( hypercall_preempt_check() )
@@ -3164,6 +3160,8 @@ long do_mmu_update(
     struct vcpu *v = current;
     struct domain *d = v->domain, *pt_owner = d, *pg_owner;
     struct domain_mmap_cache mapcache;
+    uint32_t xsm_needed = 0;
+    uint32_t xsm_checked = 0;
 
     if ( unlikely(count & MMU_UPDATE_PREEMPTED) )
     {
@@ -3195,11 +3193,6 @@ long do_mmu_update(
             rc = -EINVAL;
             goto out;
         }
-        if ( !IS_PRIV_FOR(d, pt_owner) )
-        {
-            rc = -ESRCH;
-            goto out;
-        }
     }
 
     if ( (pg_owner = get_pg_owner((uint16_t)foreigndom)) == NULL )
@@ -3239,9 +3232,20 @@ long do_mmu_update(
         {
             p2m_type_t p2mt;
 
-            rc = xsm_mmu_normal_update(d, pt_owner, pg_owner, req.val);
-            if ( rc )
-                break;
+            xsm_needed |= XSM_MMU_NORMAL_UPDATE;
+            if ( get_pte_flags(req.val) & _PAGE_PRESENT )
+            {
+                xsm_needed |= XSM_MMU_UPDATE_READ;
+                if ( get_pte_flags(req.val) & _PAGE_RW )
+                    xsm_needed |= XSM_MMU_UPDATE_WRITE;
+            }
+            if ( xsm_needed != xsm_checked )
+            {
+                rc = xsm_mmu_update(d, pt_owner, pg_owner, xsm_needed);
+                if ( rc )
+                    break;
+                xsm_checked = xsm_needed;
+            }
             rc = -EINVAL;
 
             req.ptr -= cmd;
@@ -3353,9 +3357,14 @@ long do_mmu_update(
             mfn = req.ptr >> PAGE_SHIFT;
             gpfn = req.val;
 
-            rc = xsm_mmu_machphys_update(d, pg_owner, mfn);
-            if ( rc )
-                break;
+            xsm_needed |= XSM_MMU_MACHPHYS_UPDATE;
+            if ( xsm_needed != xsm_checked )
+            {
+                rc = xsm_mmu_update(d, pt_owner, pg_owner, xsm_needed);
+                if ( rc )
+                    break;
+                xsm_checked = xsm_needed;
+            }
 
             if ( unlikely(!get_page_from_pagenr(mfn, pg_owner)) )
             {
diff --git a/xen/include/xsm/dummy.h b/xen/include/xsm/dummy.h
index 1760cd9..9c13d5c037 100644
--- a/xen/include/xsm/dummy.h
+++ b/xen/include/xsm/dummy.h
@@ -662,21 +662,28 @@ static XSM_DEFAULT(int, domain_memory_map) (struct domain *d)
     return 0;
 }
 
-static XSM_DEFAULT(int, mmu_normal_update) (struct domain *d, struct domain *t,
-                                            struct domain *f, intpte_t fpte)
+static XSM_DEFAULT(int, mmu_update) (struct domain *d, struct domain *t,
+                                     struct domain *f, uint32_t flags)
 {
+    if ( d != t && !IS_PRIV_FOR(d, t) )
+        return -EPERM;
+    if ( d != f && !IS_PRIV_FOR(d, f) )
+        return -EPERM;
     return 0;
 }
 
-static XSM_DEFAULT(int, mmu_machphys_update) (struct domain *d, struct domain *f,
-                                              unsigned long mfn)
+static XSM_DEFAULT(int, mmuext_op) (struct domain *d, struct domain *f)
 {
+    if ( d != f && !IS_PRIV_FOR(d, f) )
+        return -EPERM;
     return 0;
 }
 
 static XSM_DEFAULT(int, update_va_mapping) (struct domain *d, struct domain *f, 
                                                             l1_pgentry_t pte)
 {
+    if ( d != f && !IS_PRIV_FOR(d, f) )
+        return -EPERM;
     return 0;
 }
 
diff --git a/xen/include/xsm/xsm.h b/xen/include/xsm/xsm.h
index c2c1efa..6d970b1 100644
--- a/xen/include/xsm/xsm.h
+++ b/xen/include/xsm/xsm.h
@@ -27,8 +27,6 @@ typedef u32 xsm_magic_t;
 #define XSM_MAGIC 0x00000000
 #endif
 
-#ifdef XSM_ENABLE
-
 extern char *policy_buffer;
 extern u32 policy_size;
 
@@ -170,9 +168,13 @@ struct xsm_operations {
     int (*getidletime) (void);
     int (*machine_memory_map) (void);
     int (*domain_memory_map) (struct domain *d);
-    int (*mmu_normal_update) (struct domain *d, struct domain *t,
-                              struct domain *f, intpte_t fpte);
-    int (*mmu_machphys_update) (struct domain *d1, struct domain *d2, unsigned long mfn);
+#define XSM_MMU_UPDATE_READ      1
+#define XSM_MMU_UPDATE_WRITE     2
+#define XSM_MMU_NORMAL_UPDATE    4
+#define XSM_MMU_MACHPHYS_UPDATE  8
+    int (*mmu_update) (struct domain *d, struct domain *t,
+                       struct domain *f, uint32_t flags);
+    int (*mmuext_op) (struct domain *d, struct domain *f);
     int (*update_va_mapping) (struct domain *d, struct domain *f, l1_pgentry_t pte);
     int (*add_to_physmap) (struct domain *d1, struct domain *d2);
     int (*sendtrigger) (struct domain *d);
@@ -186,6 +188,8 @@ struct xsm_operations {
 #endif
 };
 
+#ifdef XSM_ENABLE
+
 extern struct xsm_operations *xsm_ops;
 
 static inline void xsm_security_domaininfo (struct domain *d,
@@ -761,16 +765,15 @@ static inline int xsm_domain_memory_map(struct domain *d)
     return xsm_ops->domain_memory_map(d);
 }
 
-static inline int xsm_mmu_normal_update (struct domain *d, struct domain *t,
-                                         struct domain *f, intpte_t fpte)
+static inline int xsm_mmu_update (struct domain *d, struct domain *t,
+                                  struct domain *f, uint32_t flags)
 {
-    return xsm_ops->mmu_normal_update(d, t, f, fpte);
+    return xsm_ops->mmu_update(d, t, f, flags);
 }
 
-static inline int xsm_mmu_machphys_update (struct domain *d1, struct domain *d2,
-                                           unsigned long mfn)
+static inline int xsm_mmuext_op (struct domain *d, struct domain *f)
 {
-    return xsm_ops->mmu_machphys_update(d1, d2, mfn);
+    return xsm_ops->mmuext_op(d, f);
 }
 
 static inline int xsm_update_va_mapping(struct domain *d, struct domain *f, 
diff --git a/xen/xsm/dummy.c b/xen/xsm/dummy.c
index c82c464..9476be6 100644
--- a/xen/xsm/dummy.c
+++ b/xen/xsm/dummy.c
@@ -154,8 +154,8 @@ void xsm_fixup_ops (struct xsm_operations *ops)
     set_to_dummy_if_null(ops, getidletime);
     set_to_dummy_if_null(ops, machine_memory_map);
     set_to_dummy_if_null(ops, domain_memory_map);
-    set_to_dummy_if_null(ops, mmu_normal_update);
-    set_to_dummy_if_null(ops, mmu_machphys_update);
+    set_to_dummy_if_null(ops, mmu_update);
+    set_to_dummy_if_null(ops, mmuext_op);
     set_to_dummy_if_null(ops, update_va_mapping);
     set_to_dummy_if_null(ops, add_to_physmap);
     set_to_dummy_if_null(ops, remove_from_physmap);
diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
index f993696..bd2d792 100644
--- a/xen/xsm/flask/hooks.c
+++ b/xen/xsm/flask/hooks.c
@@ -1432,65 +1432,44 @@ static int flask_domain_memory_map(struct domain *d)
     return current_has_perm(d, SECCLASS_MMU, MMU__MEMORYMAP);
 }
 
-static int domain_memory_perm(struct domain *d, struct domain *f, l1_pgentry_t pte)
+static int flask_mmu_update(struct domain *d, struct domain *t,
+                            struct domain *f, uint32_t flags)
 {
     int rc = 0;
-    u32 map_perms = MMU__MAP_READ;
-    unsigned long fgfn, fmfn;
-    p2m_type_t p2mt;
-
-    if ( !(l1e_get_flags(pte) & _PAGE_PRESENT) )
-        return 0;
-
-    if ( l1e_get_flags(pte) & _PAGE_RW )
-        map_perms |= MMU__MAP_WRITE;
-
-    fgfn = l1e_get_pfn(pte);
-    fmfn = mfn_x(get_gfn_query(f, fgfn, &p2mt));
-    put_gfn(f, fgfn);
+    u32 map_perms = 0;
 
-    if ( f->domain_id == DOMID_IO || !mfn_valid(fmfn) )
-    {
-        struct avc_audit_data ad;
-        u32 dsid, fsid;
-        rc = security_iomem_sid(fmfn, &fsid);
-        if ( rc )
-            return rc;
-        AVC_AUDIT_DATA_INIT(&ad, MEMORY);
-        ad.sdom = d;
-        ad.tdom = f;
-        ad.memory.pte = pte.l1;
-        ad.memory.mfn = fmfn;
-        dsid = domain_sid(d);
-        return avc_has_perm(dsid, fsid, SECCLASS_MMU, map_perms, &ad);
-    }
-
-    return domain_has_perm(d, f, SECCLASS_MMU, map_perms);
-}
-
-static int flask_mmu_normal_update(struct domain *d, struct domain *t,
-                                   struct domain *f, intpte_t fpte)
-{
-    int rc = 0;
-
-    if (d != t)
+    if ( (flags & XSM_MMU_NORMAL_UPDATE) && d != t )
         rc = domain_has_perm(d, t, SECCLASS_MMU, MMU__REMOTE_REMAP);
     if ( rc )
         return rc;
 
-    return domain_memory_perm(d, f, l1e_from_intpte(fpte));
+    if ( flags & XSM_MMU_UPDATE_READ )
+        map_perms |= MMU__MAP_READ;
+    if ( flags & XSM_MMU_UPDATE_WRITE )
+        map_perms |= MMU__MAP_WRITE;
+    if ( flags & XSM_MMU_MACHPHYS_UPDATE )
+        map_perms |= MMU__UPDATEMP;
+
+    if ( map_perms )
+        rc = domain_has_perm(d, f, SECCLASS_MMU, map_perms);
+    return rc;
 }
 
-static int flask_mmu_machphys_update(struct domain *d1, struct domain *d2,
-                                     unsigned long mfn)
+static int flask_mmuext_op(struct domain *d, struct domain *f)
 {
-    return domain_has_perm(d1, d2, SECCLASS_MMU, MMU__UPDATEMP);
+    return domain_has_perm(d, f, SECCLASS_MMU, MMU__MMUEXT_OP);
 }
 
 static int flask_update_va_mapping(struct domain *d, struct domain *f,
                                    l1_pgentry_t pte)
 {
-    return domain_memory_perm(d, f, pte);
+    u32 map_perms = MMU__MAP_READ;
+    if ( !(l1e_get_flags(pte) & _PAGE_PRESENT) )
+        return 0;
+    if ( l1e_get_flags(pte) & _PAGE_RW )
+        map_perms |= MMU__MAP_WRITE;
+
+    return domain_has_perm(d, f, SECCLASS_MMU, map_perms);
 }
 
 static int flask_add_to_physmap(struct domain *d1, struct domain *d2)
@@ -1771,8 +1750,8 @@ static struct xsm_operations flask_ops = {
     .getidletime = flask_getidletime,
     .machine_memory_map = flask_machine_memory_map,
     .domain_memory_map = flask_domain_memory_map,
-    .mmu_normal_update = flask_mmu_normal_update,
-    .mmu_machphys_update = flask_mmu_machphys_update,
+    .mmu_update = flask_mmu_update,
+    .mmuext_op = flask_mmuext_op,
     .update_va_mapping = flask_update_va_mapping,
     .add_to_physmap = flask_add_to_physmap,
     .remove_from_physmap = flask_remove_from_physmap,
diff --git a/xen/xsm/flask/include/av_perm_to_string.h b/xen/xsm/flask/include/av_perm_to_string.h
index 186f1fa..8f65b96 100644
--- a/xen/xsm/flask/include/av_perm_to_string.h
+++ b/xen/xsm/flask/include/av_perm_to_string.h
@@ -111,6 +111,7 @@
    S_(SECCLASS_MMU, MMU__MFNLIST, "mfnlist")
    S_(SECCLASS_MMU, MMU__MEMORYMAP, "memorymap")
    S_(SECCLASS_MMU, MMU__REMOTE_REMAP, "remote_remap")
+   S_(SECCLASS_MMU, MMU__MMUEXT_OP, "mmuext_op")
    S_(SECCLASS_SHADOW, SHADOW__DISABLE, "disable")
    S_(SECCLASS_SHADOW, SHADOW__ENABLE, "enable")
    S_(SECCLASS_SHADOW, SHADOW__LOGDIRTY, "logdirty")
diff --git a/xen/xsm/flask/include/av_permissions.h b/xen/xsm/flask/include/av_permissions.h
index b3831f6..18454fd 100644
--- a/xen/xsm/flask/include/av_permissions.h
+++ b/xen/xsm/flask/include/av_permissions.h
@@ -117,6 +117,7 @@
 #define MMU__MFNLIST                              0x00000400UL
 #define MMU__MEMORYMAP                            0x00000800UL
 #define MMU__REMOTE_REMAP                         0x00001000UL
+#define MMU__MMUEXT_OP                            0x00002000UL
 
 #define SHADOW__DISABLE                           0x00000001UL
 #define SHADOW__ENABLE                            0x00000002UL
-- 
1.7.11.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 12 16:00:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Sep 2012 16:00:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TBpM7-0005Pa-Qf; Wed, 12 Sep 2012 15:59:59 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1TBpM6-0005Me-JP
	for xen-devel@lists.xen.org; Wed, 12 Sep 2012 15:59:58 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-16.tower-27.messagelabs.com!1347465591!9333729!1
X-Originating-IP: [63.239.67.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6656 invoked from network); 12 Sep 2012 15:59:52 -0000
Received: from emvm-gh1-uea09.nsa.gov (HELO nsa.gov) (63.239.67.10)
	by server-16.tower-27.messagelabs.com with SMTP;
	12 Sep 2012 15:59:52 -0000
X-TM-IMSS-Message-ID: <39e11113001083cb@nsa.gov>
Received: from tarius.tycho.ncsc.mil ([144.51.3.1]) by nsa.gov
	([63.239.67.10]) with ESMTP (TREND IMSS SMTP Service 7.1) id
	39e11113001083cb ; Wed, 12 Sep 2012 12:01:58 -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 q8CFxoOA006669; 
	Wed, 12 Sep 2012 11:59:50 -0400
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xen.org
Date: Wed, 12 Sep 2012 11:59:24 -0400
Message-Id: <1347465586-20009-1-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.11.4
Cc: dgdegra@tycho.nsa.gov
Subject: [Xen-devel] [PATCH v3] Merge IS_PRIV checks into XSM hooks
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 v2:
 * Added overall hooks for domctl, sysctl, and platform_hypercall so
   that new sub-operations are protected by IS_PRIV checks
 * Reorganized the IS_PRIV additions to dummy.h so they are added in the
   same patch that removes the IS_PRIV they are replacing
 * Reworked hooks in the MM hotpath to increase efficiency
 * Dropped some unneeded XSM hook additions due to do_domctl hook
 * Dropped the rcu_lock*target_domain_by_id function removal patch
 * Restore IS_PRIV check in PHYSDEVOP_alloc_irq_vector
 * Use the existing hook function structure for tmem

Overall, this series should not change the behavior of Xen when XSM is
not enabled; however, in some cases, the exact errors that are returned
will be different because security checks have been moved below validity
checks.

Background:

The Xen hypervisor has two basic access control function calls: IS_PRIV
and the xsm_* functions. Most privileged operations currently require
that both checks succeed, and many times the checks are at different
locations in the code.

When performing dom0 disaggregation, many of the functions normally
protected with IS_PRIV are handled by domains other than dom0. This
requires either making all such disaggregated domains privileged, or
allowing certain operations to be performed without an IS_PRIV check.
Because the privileged bit also short-circuits the IS_PRIV_FOR check,
and some IS_PRIV calls do not currently have an accompanying XSM call,
this series implements the second option.

Once applied, most IS_PRIV checks are isolated in the newly introduced
xen/include/xsm/dummy.h header. The remaining checks cover a few areas
that that have some reason to remain because they involve hardware
access or workarounds:

1. Overriding the IRQ and IO memory access checks (arch/x86/domctl.c).
   These overrides should not be needed, as dom0 should have access
   without needing the override.
2. Allow MAP_PIRQ_TYPE_GSI to ignore domain_pirq_to_irq negative return
3. The hack for device model framebuffers in get_page_from_l1e
4. Installing maps of non-owned pages in shadow_get_page_from_l1e
5. PCI configuration space (arch/x86/traps.c). Allowing a PV Linux domU
   to access the PCI configuration space is a good way to crash the
   system as it reconfigures PCI devices during boot, so this needs to
   remain to get a working system when FLASK is in permissive mode.
6. Various MSR accesses (arch/x86/traps.c)

The ARM architecture is not touched at all in these patches; however,
none of the changes should affect ARM. XSM hooks will need to be added
for the arch-specific controls in order for FLASK to be useful on ARM,
but those changes are outside the scope of this series.

Miscellaneous updates to FLASK:
    [PATCH 01/22] xsm/flask: remove inherited class attributes
    [PATCH 02/22] xsm/flask: remove unneeded create_sid field
    [PATCH 04/22] xsm/flask: add domain relabel support
    [PATCH 05/22] libxl: introduce XSM relabel on build
    [PATCH 06/22] flask/policy: Add domain relabel example
    [PATCH 08/22] xsm/flask: Add checks on the domain performing the

Preparatory new functions/hooks:
    [PATCH 03/22] xen: Add versions of rcu_lock_*_domain without IS_PRIV
    [PATCH 07/22] arch/x86: add distinct XSM hooks for map/unmap
    [PATCH 13/22] xen: lock target domain in do_domctl common code

IS_PRIV Refactoring:
    [PATCH 09/22] xsm: Use the dummy XSM module if XSM is disabled
    [PATCH 10/22] xen: use XSM instead of IS_PRIV where duplicated
    [PATCH 11/22] xen: avoid calling rcu_lock_*target_domain when an XSM
    [PATCH 12/22] arch/x86: convert platform_hypercall to use XSM
    [PATCH 14/22] xen: convert do_domctl to use XSM
    [PATCH 15/22] xen: convert do_sysctl to use XSM

Additional new/updated hooks:
    [PATCH 16/22] xsm/flask: add missing hooks
    [PATCH 17/22] xsm/flask: add distinct SIDs for self/target access
    [PATCH 18/22] arch/x86: Add missing mem_sharing XSM hooks
    [PATCH 19/22] arch/x86: check remote MMIO remap permissions
    [PATCH 20/22] arch/x86: use XSM hooks for get_pg_owner access checks
    [PATCH 21/22] xen: Add XSM hook for XENMEM_exchange
    [PATCH 22/22] tmem: add XSM hooks

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 12 16:00:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Sep 2012 16:00:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TBpMC-0005eu-6Z; Wed, 12 Sep 2012 16:00:04 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1TBpMA-0005Nh-F8
	for xen-devel@lists.xen.org; Wed, 12 Sep 2012 16:00:02 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-10.tower-27.messagelabs.com!1347465595!5579605!1
X-Originating-IP: [63.239.67.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31226 invoked from network); 12 Sep 2012 15:59:56 -0000
Received: from emvm-gh1-uea09.nsa.gov (HELO nsa.gov) (63.239.67.10)
	by server-10.tower-27.messagelabs.com with SMTP;
	12 Sep 2012 15:59:56 -0000
X-TM-IMSS-Message-ID: <39e12158001083da@nsa.gov>
Received: from tarius.tycho.ncsc.mil ([144.51.3.1]) by nsa.gov
	([63.239.67.10]) with ESMTP (TREND IMSS SMTP Service 7.1) id
	39e12158001083da ; Wed, 12 Sep 2012 12:02:02 -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 q8CFxoOO006669; 
	Wed, 12 Sep 2012 11:59:54 -0400
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xen.org
Date: Wed, 12 Sep 2012 11:59:38 -0400
Message-Id: <1347465586-20009-15-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.11.4
In-Reply-To: <1347465586-20009-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1347465586-20009-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: dgdegra@tycho.nsa.gov
Subject: [Xen-devel] [PATCH 14/22] xen: convert do_domctl to use 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

The xsm_domctl hook now covers every domctl, in addition to the more
fine-grained XSM hooks in most sub-functions. This also removes the need
to special-case XEN_DOMCTL_getdomaininfo.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 xen/arch/x86/domctl.c   |  2 +-
 xen/common/domctl.c     | 32 +++----------------
 xen/include/xsm/dummy.h | 16 ++++++++--
 xen/xsm/flask/hooks.c   | 85 ++++++++++++++++++++++++++++++++++++++++++++++++-
 4 files changed, 104 insertions(+), 31 deletions(-)

diff --git a/xen/arch/x86/domctl.c b/xen/arch/x86/domctl.c
index 9eebd3b..a0ecd95 100644
--- a/xen/arch/x86/domctl.c
+++ b/xen/arch/x86/domctl.c
@@ -1480,7 +1480,7 @@ long arch_do_domctl(
     {
         struct domain *d;
 
-        ret = rcu_lock_remote_target_domain_by_id(domctl->domain, &d);
+        ret = rcu_lock_remote_domain_by_id(domctl->domain, &d);
         if ( ret != 0 )
             break;
 
diff --git a/xen/common/domctl.c b/xen/common/domctl.c
index 76ced4f..48b5f6f 100644
--- a/xen/common/domctl.c
+++ b/xen/common/domctl.c
@@ -263,27 +263,9 @@ long do_domctl(XEN_GUEST_HANDLE(xen_domctl_t) u_domctl)
             return -ESRCH;
     }
 
-    switch ( op->cmd )
-    {
-    case XEN_DOMCTL_ioport_mapping:
-    case XEN_DOMCTL_memory_mapping:
-    case XEN_DOMCTL_bind_pt_irq:
-    case XEN_DOMCTL_unbind_pt_irq: {
-        bool_t is_priv = IS_PRIV_FOR(current->domain, d);
-        if ( !is_priv )
-        {
-            ret = -EPERM;
-            goto domctl_out_unlock;
-        }
-        break;
-    }
-    case XEN_DOMCTL_getdomaininfo:
-        break;
-    default:
-        if ( !IS_PRIV(current->domain) )
-            return -EPERM;
-        break;
-    }
+    ret = xsm_domctl(d, op->cmd);
+    if ( ret )
+        goto domctl_out_unlock;
 
     if ( !domctl_lock_acquire() )
     {
@@ -857,17 +839,13 @@ long do_domctl(XEN_GUEST_HANDLE(xen_domctl_t) u_domctl)
 
     case XEN_DOMCTL_subscribe:
     {
-        ret = xsm_domctl(d, op->cmd);
-        if ( !ret )
-            d->suspend_evtchn = op->u.subscribe.port;
+        d->suspend_evtchn = op->u.subscribe.port;
     }
     break;
 
     case XEN_DOMCTL_disable_migrate:
     {
-        ret = xsm_domctl(d, op->cmd);
-        if ( !ret )
-            d->disable_migrate = op->u.disable_migrate.disable;
+        d->disable_migrate = op->u.disable_migrate.disable;
     }
     break;
 
diff --git a/xen/include/xsm/dummy.h b/xen/include/xsm/dummy.h
index 3f0a6d8..6aa6aea 100644
--- a/xen/include/xsm/dummy.h
+++ b/xen/include/xsm/dummy.h
@@ -64,8 +64,6 @@ static XSM_DEFAULT(int, scheduler) (struct domain *d)
 
 static XSM_DEFAULT(int, getdomaininfo) (struct domain *d)
 {
-    if ( !IS_PRIV(current->domain) )
-        return -EPERM;
     return 0;
 }
 
@@ -91,6 +89,20 @@ static XSM_DEFAULT(int, set_target) (struct domain *d, struct domain *e)
 
 static XSM_DEFAULT(int, domctl)(struct domain *d, int cmd)
 {
+    switch ( cmd )
+    {
+    case XEN_DOMCTL_ioport_mapping:
+    case XEN_DOMCTL_memory_mapping:
+    case XEN_DOMCTL_bind_pt_irq:
+    case XEN_DOMCTL_unbind_pt_irq: {
+        if ( !IS_PRIV_FOR(current->domain, d) )
+            return -EPERM;
+        break;
+    }
+    default:
+        if ( !IS_PRIV(current->domain) )
+            return -EPERM;
+    }
     return 0;
 }
 
diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
index 1cbf2f2..6d03189 100644
--- a/xen/xsm/flask/hooks.c
+++ b/xen/xsm/flask/hooks.c
@@ -589,7 +589,90 @@ static int flask_set_target(struct domain *d, struct domain *e)
 
 static int flask_domctl(struct domain *d, int cmd)
 {
-    return domain_has_perm(current->domain, d, SECCLASS_DOMAIN, DOMAIN__SET_MISC_INFO);
+    switch ( cmd )
+    {
+    /* These have individual XSM hooks (common/domctl.c) */
+    case XEN_DOMCTL_createdomain:
+    case XEN_DOMCTL_destroydomain:
+    case XEN_DOMCTL_pausedomain:
+    case XEN_DOMCTL_unpausedomain:
+    case XEN_DOMCTL_getdomaininfo:
+    case XEN_DOMCTL_setvcpuaffinity:
+    case XEN_DOMCTL_max_mem:
+    case XEN_DOMCTL_setvcpucontext:
+    case XEN_DOMCTL_getvcpucontext:
+    case XEN_DOMCTL_getvcpuinfo:
+    case XEN_DOMCTL_max_vcpus:
+    case XEN_DOMCTL_scheduler_op:
+    case XEN_DOMCTL_setdomainhandle:
+    case XEN_DOMCTL_setdebugging:
+    case XEN_DOMCTL_irq_permission:
+    case XEN_DOMCTL_iomem_permission:
+    case XEN_DOMCTL_settimeoffset:
+    case XEN_DOMCTL_getvcpuaffinity:
+    case XEN_DOMCTL_resumedomain:
+    case XEN_DOMCTL_set_target:
+    case XEN_DOMCTL_set_virq_handler:
+#ifdef CONFIG_X86
+    /* These have individual XSM hooks (arch/x86/domctl.c) */
+    case XEN_DOMCTL_shadow_op:
+    case XEN_DOMCTL_ioport_permission:
+    case XEN_DOMCTL_getpageframeinfo:
+    case XEN_DOMCTL_getpageframeinfo2:
+    case XEN_DOMCTL_getpageframeinfo3:
+    case XEN_DOMCTL_getmemlist:
+    case XEN_DOMCTL_hypercall_init:
+    case XEN_DOMCTL_sethvmcontext:
+    case XEN_DOMCTL_gethvmcontext:
+    case XEN_DOMCTL_gethvmcontext_partial:
+    case XEN_DOMCTL_set_address_size:
+    case XEN_DOMCTL_get_address_size:
+    case XEN_DOMCTL_set_machine_address_size:
+    case XEN_DOMCTL_get_machine_address_size:
+    case XEN_DOMCTL_sendtrigger:
+    case XEN_DOMCTL_bind_pt_irq:
+    case XEN_DOMCTL_unbind_pt_irq:
+    case XEN_DOMCTL_memory_mapping:
+    case XEN_DOMCTL_ioport_mapping:
+    case XEN_DOMCTL_pin_mem_cacheattr:
+    case XEN_DOMCTL_set_ext_vcpucontext:
+    case XEN_DOMCTL_get_ext_vcpucontext:
+    case XEN_DOMCTL_setvcpuextstate:
+    case XEN_DOMCTL_getvcpuextstate:
+    case XEN_DOMCTL_mem_event_op:
+    case XEN_DOMCTL_mem_sharing_op:
+    case XEN_DOMCTL_set_access_required:
+    /* These have individual XSM hooks (drivers/passthrough/iommu.c) */
+    case XEN_DOMCTL_get_device_group:
+    case XEN_DOMCTL_test_assign_device:
+    case XEN_DOMCTL_assign_device:
+    case XEN_DOMCTL_deassign_device:
+#endif
+        return 0;
+
+    case XEN_DOMCTL_subscribe:
+    case XEN_DOMCTL_disable_migrate:
+        return domain_has_perm(current->domain, d, SECCLASS_DOMAIN,
+                               DOMAIN__SET_MISC_INFO);
+
+    case XEN_DOMCTL_set_cpuid:
+    case XEN_DOMCTL_suppress_spurious_page_faults:
+    case XEN_DOMCTL_debug_op:
+    case XEN_DOMCTL_gettscinfo:
+    case XEN_DOMCTL_settscinfo:
+    case XEN_DOMCTL_audit_p2m:
+    case XEN_DOMCTL_gdbsx_guestmemio:
+    case XEN_DOMCTL_gdbsx_pausevcpu:
+    case XEN_DOMCTL_gdbsx_unpausevcpu:
+    case XEN_DOMCTL_gdbsx_domstatus:
+        /* TODO add per-subfunction hooks */
+        if ( !IS_PRIV(current->domain) )
+            return -EPERM;
+        return 0;
+    default:
+        printk("flask_domctl: Unknown op %d\n", cmd);
+        return -EPERM;
+    }
 }
 
 static int flask_set_virq_handler(struct domain *d, uint32_t virq)
-- 
1.7.11.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 12 16:00:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Sep 2012 16:00:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TBpMC-0005ix-W6; Wed, 12 Sep 2012 16:00:04 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1TBpMA-0005Nw-TY
	for xen-devel@lists.xen.org; Wed, 12 Sep 2012 16:00:03 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-12.tower-27.messagelabs.com!1347465595!10765552!1
X-Originating-IP: [63.239.67.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4654 invoked from network); 12 Sep 2012 15:59:55 -0000
Received: from emvm-gh1-uea09.nsa.gov (HELO nsa.gov) (63.239.67.10)
	by server-12.tower-27.messagelabs.com with SMTP;
	12 Sep 2012 15:59:55 -0000
X-TM-IMSS-Message-ID: <39e11f75001083d8@nsa.gov>
Received: from tarius.tycho.ncsc.mil ([144.51.3.1]) by nsa.gov
	([63.239.67.10]) with ESMTP (TREND IMSS SMTP Service 7.1) id
	39e11f75001083d8 ; Wed, 12 Sep 2012 12:02:01 -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 q8CFxoOM006669; 
	Wed, 12 Sep 2012 11:59:53 -0400
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xen.org
Date: Wed, 12 Sep 2012 11:59:36 -0400
Message-Id: <1347465586-20009-13-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.11.4
In-Reply-To: <1347465586-20009-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1347465586-20009-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: dgdegra@tycho.nsa.gov, Keir Fraser <keir@xen.org>,
	Jan Beulich <jbeulich@suse.com>
Subject: [Xen-devel] [PATCH 12/22] arch/x86: convert platform_hypercall to
	use 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

The newly introduced xsm_platform_op hook addresses new sub-ops, while
most ops already have their own XSM hooks.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Cc: Keir Fraser <keir@xen.org>
Cc: Jan Beulich <jbeulich@suse.com>
---
 xen/arch/x86/platform_hypercall.c | 11 ++++++++---
 xen/include/xsm/dummy.h           |  7 +++++++
 xen/include/xsm/xsm.h             |  6 ++++++
 xen/xsm/dummy.c                   |  1 +
 xen/xsm/flask/hooks.c             | 33 +++++++++++++++++++++++++++++++++
 5 files changed, 55 insertions(+), 3 deletions(-)

diff --git a/xen/arch/x86/platform_hypercall.c b/xen/arch/x86/platform_hypercall.c
index 073a2ea..50b5f1d 100644
--- a/xen/arch/x86/platform_hypercall.c
+++ b/xen/arch/x86/platform_hypercall.c
@@ -66,15 +66,16 @@ ret_t do_platform_op(XEN_GUEST_HANDLE(xen_platform_op_t) u_xenpf_op)
     ret_t ret = 0;
     struct xen_platform_op curop, *op = &curop;
 
-    if ( !IS_PRIV(current->domain) )
-        return -EPERM;
-
     if ( copy_from_guest(op, u_xenpf_op, 1) )
         return -EFAULT;
 
     if ( op->interface_version != XENPF_INTERFACE_VERSION )
         return -EACCES;
 
+    ret = xsm_platform_op(op->cmd);
+    if ( ret )
+        return ret;
+
     /*
      * Trylock here avoids deadlock with an existing platform critical section
      * which might (for some current or future reason) want to synchronise
@@ -507,6 +508,10 @@ ret_t do_platform_op(XEN_GUEST_HANDLE(xen_platform_op_t) u_xenpf_op)
     {
         struct xenpf_pcpu_version *ver = &op->u.pcpu_version;
 
+        ret = xsm_getcpuinfo();
+        if ( ret )
+            break;
+
         if ( !get_cpu_maps() )
         {
             ret = -EBUSY;
diff --git a/xen/include/xsm/dummy.h b/xen/include/xsm/dummy.h
index 31f862d..3f0a6d8 100644
--- a/xen/include/xsm/dummy.h
+++ b/xen/include/xsm/dummy.h
@@ -574,6 +574,13 @@ static XSM_DEFAULT(int, platform_quirk) (uint32_t quirk)
     return 0;
 }
 
+static XSM_DEFAULT(int, platform_op) (uint32_t op)
+{
+    if ( !IS_PRIV(current->domain) )
+        return -EPERM;
+    return 0;
+}
+
 static XSM_DEFAULT(int, firmware_info) (void)
 {
     return 0;
diff --git a/xen/include/xsm/xsm.h b/xen/include/xsm/xsm.h
index ba5a89e..171acb2 100644
--- a/xen/include/xsm/xsm.h
+++ b/xen/include/xsm/xsm.h
@@ -158,6 +158,7 @@ struct xsm_operations {
     int (*microcode) (void);
     int (*physinfo) (void);
     int (*platform_quirk) (uint32_t);
+    int (*platform_op) (uint32_t cmd);
     int (*firmware_info) (void);
     int (*efi_call) (void);
     int (*acpi_sleep) (void);
@@ -696,6 +697,11 @@ static inline int xsm_platform_quirk (uint32_t quirk)
     return xsm_ops->platform_quirk(quirk);
 }
 
+static inline int xsm_platform_op (uint32_t op)
+{
+    return xsm_ops->platform_op(op);
+}
+
 static inline int xsm_firmware_info (void)
 {
     return xsm_ops->firmware_info();
diff --git a/xen/xsm/dummy.c b/xen/xsm/dummy.c
index af532b8..7f9c753 100644
--- a/xen/xsm/dummy.c
+++ b/xen/xsm/dummy.c
@@ -142,6 +142,7 @@ void xsm_fixup_ops (struct xsm_operations *ops)
     set_to_dummy_if_null(ops, microcode);
     set_to_dummy_if_null(ops, physinfo);
     set_to_dummy_if_null(ops, platform_quirk);
+    set_to_dummy_if_null(ops, platform_op);
     set_to_dummy_if_null(ops, firmware_info);
     set_to_dummy_if_null(ops, efi_call);
     set_to_dummy_if_null(ops, acpi_sleep);
diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
index 10c2163..1cbf2f2 100644
--- a/xen/xsm/flask/hooks.c
+++ b/xen/xsm/flask/hooks.c
@@ -1207,6 +1207,38 @@ static int flask_platform_quirk(uint32_t quirk)
                         XEN__QUIRK, NULL);
 }
 
+static int flask_platform_op(uint32_t op)
+{
+    switch ( op )
+    {
+    case XENPF_settime:
+    case XENPF_add_memtype:
+    case XENPF_del_memtype:
+    case XENPF_read_memtype:
+    case XENPF_microcode_update:
+    case XENPF_platform_quirk:
+    case XENPF_firmware_info:
+    case XENPF_efi_runtime_call:
+    case XENPF_enter_acpi_sleep:
+    case XENPF_change_freq:
+    case XENPF_getidletime:
+    case XENPF_set_processor_pminfo:
+    case XENPF_get_cpuinfo:
+    case XENPF_get_cpu_version:
+    case XENPF_cpu_online:
+    case XENPF_cpu_offline:
+    case XENPF_cpu_hotadd:
+    case XENPF_mem_hotadd:
+        /* These operations have their own XSM hooks */
+        return 0;
+    case XENPF_core_parking:
+        return domain_has_xen(current->domain, XEN__PM_OP);
+    default:
+        printk("flask_platform_op: Unknown op %d\n", op);
+        return -EPERM;
+    }
+}
+
 static int flask_firmware_info(void)
 {
     return domain_has_xen(current->domain, XEN__FIRMWARE);
@@ -1577,6 +1609,7 @@ static struct xsm_operations flask_ops = {
     .microcode = flask_microcode,
     .physinfo = flask_physinfo,
     .platform_quirk = flask_platform_quirk,
+    .platform_op = flask_platform_op,
     .firmware_info = flask_firmware_info,
     .efi_call = flask_efi_call,
     .acpi_sleep = flask_acpi_sleep,
-- 
1.7.11.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 12 16:00:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Sep 2012 16:00:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TBpM4-0005N5-6p; Wed, 12 Sep 2012 15:59:56 +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 1TBpM2-0005Mj-WB
	for xen-devel@lists.xen.org; Wed, 12 Sep 2012 15:59:55 +0000
Received: from [85.158.138.51:6697] by server-9.bemta-3.messagelabs.com id
	1A/93-15390-A71B0505; Wed, 12 Sep 2012 15:59:54 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-6.tower-174.messagelabs.com!1347465592!22162526!1
X-Originating-IP: [63.239.67.9]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8231 invoked from network); 12 Sep 2012 15:59:52 -0000
Received: from emvm-gh1-uea08.nsa.gov (HELO nsa.gov) (63.239.67.9)
	by server-6.tower-174.messagelabs.com with SMTP;
	12 Sep 2012 15:59:52 -0000
X-TM-IMSS-Message-ID: <39e1561e0010233b@nsa.gov>
Received: from tarius.tycho.ncsc.mil ([144.51.3.1]) by nsa.gov ([63.239.67.9])
	with ESMTP (TREND IMSS SMTP Service 7.1) id 39e1561e0010233b ;
	Wed, 12 Sep 2012 11:59:42 -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 q8CFxoOB006669; 
	Wed, 12 Sep 2012 11:59:50 -0400
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xen.org
Date: Wed, 12 Sep 2012 11:59:25 -0400
Message-Id: <1347465586-20009-2-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.11.4
In-Reply-To: <1347465586-20009-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1347465586-20009-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: dgdegra@tycho.nsa.gov
Subject: [Xen-devel] [PATCH 01/22] xsm/flask: remove inherited class
	attributes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 ability to declare common permission blocks shared across multiple
classes is not currently used in Xen. Currently, support for this
feature is broken in the header generation scripts, and it is not
expected that this feature will be used in the future, so remove the
dead code.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 tools/flask/policy/policy/flask/Makefile           |  2 +-
 tools/flask/policy/policy/flask/access_vectors     | 17 +----
 tools/flask/policy/policy/flask/mkaccess_vector.sh | 89 ----------------------
 xen/xsm/flask/avc.c                                | 39 ----------
 xen/xsm/flask/include/av_inherit.h                 |  1 -
 xen/xsm/flask/include/avc_ss.h                     |  8 --
 xen/xsm/flask/include/common_perm_to_string.h      |  1 -
 xen/xsm/flask/ss/policydb.c                        | 46 +----------
 xen/xsm/flask/ss/services.c                        | 54 +------------
 9 files changed, 8 insertions(+), 249 deletions(-)
 delete mode 100644 xen/xsm/flask/include/av_inherit.h
 delete mode 100644 xen/xsm/flask/include/common_perm_to_string.h

diff --git a/tools/flask/policy/policy/flask/Makefile b/tools/flask/policy/policy/flask/Makefile
index 970b9fe..5f57e88 100644
--- a/tools/flask/policy/policy/flask/Makefile
+++ b/tools/flask/policy/policy/flask/Makefile
@@ -14,7 +14,7 @@ FLASK_H_DEPEND = security_classes initial_sids
 AV_H_DEPEND = access_vectors
 
 FLASK_H_FILES = class_to_string.h flask.h initial_sid_to_string.h
-AV_H_FILES = av_inherit.h common_perm_to_string.h av_perm_to_string.h av_permissions.h
+AV_H_FILES = av_perm_to_string.h av_permissions.h
 ALL_H_FILES = $(FLASK_H_FILES) $(AV_H_FILES)
 
 all:  $(ALL_H_FILES)
diff --git a/tools/flask/policy/policy/flask/access_vectors b/tools/flask/policy/policy/flask/access_vectors
index 5901911..a884312 100644
--- a/tools/flask/policy/policy/flask/access_vectors
+++ b/tools/flask/policy/policy/flask/access_vectors
@@ -1,22 +1,7 @@
 #
-# Define common prefixes for access vectors
-#
-# common common_name { permission_name ... }
-
-#
-# Define a common prefix for file access vectors.
-#
-
-
-#
 # Define the access vectors.
 #
-# class class_name [ inherits common_name ] { permission_name ... }
-
-
-#
-# Define the access vector interpretation for file-related objects.
-#
+# class class_name { permission_name ... }
 
 class xen
 {
diff --git a/tools/flask/policy/policy/flask/mkaccess_vector.sh b/tools/flask/policy/policy/flask/mkaccess_vector.sh
index b5da734..43a60a7 100644
--- a/tools/flask/policy/policy/flask/mkaccess_vector.sh
+++ b/tools/flask/policy/policy/flask/mkaccess_vector.sh
@@ -10,50 +10,21 @@ shift
 
 # output files
 av_permissions="av_permissions.h"
-av_inherit="av_inherit.h"
-common_perm_to_string="common_perm_to_string.h"
 av_perm_to_string="av_perm_to_string.h"
 
 cat $* | $awk "
 BEGIN	{
 		outfile = \"$av_permissions\"
-		inheritfile = \"$av_inherit\"
-		cpermfile = \"$common_perm_to_string\"
 		avpermfile = \"$av_perm_to_string\"
 		"'
 		nextstate = "COMMON_OR_AV";
 		printf("/* This file is automatically generated.  Do not edit. */\n") > outfile;
-		printf("/* This file is automatically generated.  Do not edit. */\n") > inheritfile;
-		printf("/* This file is automatically generated.  Do not edit. */\n") > cpermfile;
 		printf("/* This file is automatically generated.  Do not edit. */\n") > avpermfile;
 ;
 	}
 /^[ \t]*#/	{ 
 			next;
 		}
-$1 == "common"	{ 
-			if (nextstate != "COMMON_OR_AV")
-			{
-				printf("Parse error:  Unexpected COMMON definition on line %d\n", NR);
-				next;	
-			}
-
-			if ($2 in common_defined)
-			{
-				printf("Duplicate COMMON definition for %s on line %d.\n", $2, NR);
-				next;
-			}	
-			common_defined[$2] = 1;
-
-			tclass = $2;
-			common_name = $2; 
-			permission = 1;
-
-			printf("TB_(common_%s_perm_to_string)\n", $2) > cpermfile;
-
-			nextstate = "COMMON-OPENBRACKET";
-			next;
-		}
 $1 == "class"	{
 			if (nextstate != "COMMON_OR_AV" &&
 			    nextstate != "CLASS_OR_CLASS-OPENBRACKET")
@@ -71,62 +42,11 @@ $1 == "class"	{
 			} 
 			av_defined[tclass] = 1;
 
-			inherits = "";
 			permission = 1;
 
 			nextstate = "INHERITS_OR_CLASS-OPENBRACKET";
 			next;
 		}
-$1 == "inherits" {			
-			if (nextstate != "INHERITS_OR_CLASS-OPENBRACKET")
-			{
-				printf("Parse error:  Unexpected INHERITS definition on line %d\n", NR);
-				next;	
-			}
-
-			if (!($2 in common_defined))
-			{
-				printf("COMMON %s is not defined (line %d).\n", $2, NR);
-				next;
-			}
-
-			inherits = $2;
-			permission = common_base[$2];
-
-			for (combined in common_perms)
-			{
-				split(combined,separate, SUBSEP);
-				if (separate[1] == inherits)
-				{
-					inherited_perms[common_perms[combined]] = separate[2];
-				}
-			}
-
-                        j = 1;
-                        for (i in inherited_perms) {
-                            ind[j] = i + 0;
-                            j++;
-                        }
-                        n = asort(ind);
-			for (i = 1; i <= n; i++) {
-				perm = inherited_perms[ind[i]];
-				printf("#define %s__%s", toupper(tclass), toupper(perm)) > outfile; 
-				spaces = 40 - (length(perm) + length(tclass));
-				if (spaces < 1)
-				      spaces = 1;
-				for (j = 0; j < spaces; j++) 
-					printf(" ") > outfile; 
-				printf("0x%08xUL\n", ind[i]) > outfile; 
-			}
-			printf("\n") > outfile;
-                        for (i in ind) delete ind[i];
-                        for (i in inherited_perms) delete inherited_perms[i];
-
-			printf("   S_(SECCLASS_%s, %s, 0x%08xUL)\n", toupper(tclass), inherits, permission) > inheritfile; 
-
-			nextstate = "CLASS_OR_CLASS-OPENBRACKET";
-			next;
-		}
 $1 == "{"	{ 
 			if (nextstate != "INHERITS_OR_CLASS-OPENBRACKET" &&
 			    nextstate != "CLASS_OR_CLASS-OPENBRACKET" &&
@@ -177,15 +97,6 @@ $1 == "{"	{
 
 				av_perms[tclass,$1] = permission;
 		
-				if (inherits != "")
-				{
-					if ((inherits,$1) in common_perms)
-					{
-						printf("Permission %s in %s on line %d conflicts with common permission.\n", $1, tclass, inherits, NR);
-						next;
-					}
-				}
-
 				printf("#define %s__%s", toupper(tclass), toupper($1)) > outfile; 
 
 				printf("   S_(SECCLASS_%s, %s__%s, \"%s\")\n", toupper(tclass), toupper(tclass), toupper($1), $1) > avpermfile; 
diff --git a/xen/xsm/flask/avc.c b/xen/xsm/flask/avc.c
index 44240a9..7fede00 100644
--- a/xen/xsm/flask/avc.c
+++ b/xen/xsm/flask/avc.c
@@ -45,28 +45,11 @@ static const char *class_to_string[] = {
 #undef S_
 };
 
-#define TB_(s) static const char * s [] = {
-#define TE_(s) };
-#define S_(s) s,
-#include "common_perm_to_string.h"
-#undef TB_
-#undef TE_
-#undef S_
-
-static const struct av_inherit av_inherit[] = {
-#define S_(c, i, b) { .tclass = c, .common_pts = common_##i##_perm_to_string, \
-                      .common_base = b },
-#include "av_inherit.h"
-#undef S_
-};
-
 const struct selinux_class_perm selinux_class_perm = {
     .av_perm_to_string = av_perm_to_string,
     .av_pts_len = ARRAY_SIZE(av_perm_to_string),
     .class_to_string = class_to_string,
     .cts_len = ARRAY_SIZE(class_to_string),
-    .av_inherit = av_inherit,
-    .av_inherit_len = ARRAY_SIZE(av_inherit)
 };
 
 #define AVC_CACHE_SLOTS            512
@@ -181,8 +164,6 @@ static void avc_printk(struct avc_dump_buf *buf, const char *fmt, ...)
  */
 static void avc_dump_av(struct avc_dump_buf *buf, u16 tclass, u32 av)
 {
-    const char **common_pts = NULL;
-    u32 common_base = 0;
     int i, i2, perm;
 
     if ( av == 0 )
@@ -191,29 +172,9 @@ static void avc_dump_av(struct avc_dump_buf *buf, u16 tclass, u32 av)
         return;
     }
 
-    for ( i = 0; i < ARRAY_SIZE(av_inherit); i++ )
-    {
-        if (av_inherit[i].tclass == tclass)
-        {
-            common_pts = av_inherit[i].common_pts;
-            common_base = av_inherit[i].common_base;
-            break;
-        }
-    }
-
     avc_printk(buf, " {");
     i = 0;
     perm = 1;
-    while ( perm < common_base )
-    {
-        if (perm & av)
-        {
-            avc_printk(buf, " %s", common_pts[i]);
-            av &= ~perm;
-        }
-        i++;
-        perm <<= 1;
-    }
 
     while ( i < sizeof(av) * 8 )
     {
diff --git a/xen/xsm/flask/include/av_inherit.h b/xen/xsm/flask/include/av_inherit.h
deleted file mode 100644
index 321ffe7..0000000
--- a/xen/xsm/flask/include/av_inherit.h
+++ /dev/null
@@ -1 +0,0 @@
-/* This file is automatically generated.  Do not edit. */
diff --git a/xen/xsm/flask/include/avc_ss.h b/xen/xsm/flask/include/avc_ss.h
index ea4e98c..a3d7d1e 100644
--- a/xen/xsm/flask/include/avc_ss.h
+++ b/xen/xsm/flask/include/avc_ss.h
@@ -16,19 +16,11 @@ struct av_perm_to_string {
     const char *name;
 };
 
-struct av_inherit {
-    const char **common_pts;
-    u32 common_base;
-    u16 tclass;
-};
-
 struct selinux_class_perm {
     const struct av_perm_to_string *av_perm_to_string;
     u32 av_pts_len;
     u32 cts_len;
     const char **class_to_string;
-    const struct av_inherit *av_inherit;
-    u32 av_inherit_len;
 };
 
 extern const struct selinux_class_perm selinux_class_perm;
diff --git a/xen/xsm/flask/include/common_perm_to_string.h b/xen/xsm/flask/include/common_perm_to_string.h
deleted file mode 100644
index 321ffe7..0000000
--- a/xen/xsm/flask/include/common_perm_to_string.h
+++ /dev/null
@@ -1 +0,0 @@
-/* This file is automatically generated.  Do not edit. */
diff --git a/xen/xsm/flask/ss/policydb.c b/xen/xsm/flask/ss/policydb.c
index 26097b9..fefcd59 100644
--- a/xen/xsm/flask/ss/policydb.c
+++ b/xen/xsm/flask/ss/policydb.c
@@ -254,14 +254,6 @@ out_free_symtab:
 
 static int common_index(void *key, void *datum, void *datap)
 {
-    struct policydb *p;
-    struct common_datum *comdatum;
-
-    comdatum = datum;
-    p = datap;
-    if ( !comdatum->value || comdatum->value > p->p_commons.nprim )
-        return -EINVAL;
-    p->p_common_val_to_name[comdatum->value - 1] = key;
     return 0;
 }
 
@@ -382,8 +374,7 @@ static int (*index_f[SYM_NUM]) (void *key, void *datum, void *datap) =
 };
 
 /*
- * Define the common val_to_name array and the class
- * val_to_name and val_to_struct arrays in a policy
+ * Define the class val_to_name and val_to_struct arrays in a policy
  * database structure.
  *
  * Caller must clean up upon failure.
@@ -392,18 +383,6 @@ static int policydb_index_classes(struct policydb *p)
 {
     int rc;
 
-    p->p_common_val_to_name =
-        xmalloc_array(char *, p->p_commons.nprim);
-    if ( !p->p_common_val_to_name )
-    {
-        rc = -ENOMEM;
-        goto out;
-    }
-
-    rc = hashtab_map(p->p_commons.table, common_index, p);
-    if ( rc )
-        goto out;
-
     p->class_val_to_struct =
         xmalloc_array(struct class_datum *, p->p_classes.nprim);
     if ( !p->class_val_to_struct )
@@ -1200,26 +1179,9 @@ static int class_read(struct policydb *p, struct hashtab *h, void *fp)
 
     if ( len2 )
     {
-        cladatum->comkey = xmalloc_array(char, len2 + 1);
-        if ( !cladatum->comkey )
-        {
-            rc = -ENOMEM;
-            goto bad;
-        }
-        rc = next_entry(cladatum->comkey, fp, len2);
-        if ( rc < 0 )
-            goto bad;
-        cladatum->comkey[len2] = 0;
-
-        cladatum->comdatum = hashtab_search(p->p_commons.table,
-                            cladatum->comkey);
-        if ( !cladatum->comdatum )
-        {
-            printk(KERN_ERR "Flask:  unknown common %s\n",
-                   cladatum->comkey);
-            rc = -EINVAL;
-            goto bad;
-        }
+        printk(KERN_ERR "Flask:  classes with common prefixes are not supported\n");
+        rc = -EINVAL;
+        goto bad;
     }
     for ( i = 0; i < nel; i++ )
     {
diff --git a/xen/xsm/flask/ss/services.c b/xen/xsm/flask/ss/services.c
index 363f586..1bf3b0c 100644
--- a/xen/xsm/flask/ss/services.c
+++ b/xen/xsm/flask/ss/services.c
@@ -1167,10 +1167,10 @@ int security_change_sid(u32 ssid, u32 tsid, u16 tclass, u32 *out_sid)
  */
 static int validate_classes(struct policydb *p)
 {
-    int i, j;
+    int i;
     struct class_datum *cladatum;
     struct perm_datum *perdatum;
-    u32 nprim, tmp, common_pts_len, perm_val, pol_val;
+    u32 nprim, perm_val, pol_val;
     u16 class_val;
     const struct selinux_class_perm *kdefs = &selinux_class_perm;
     const char *def_class, *def_perm, *pol_class;
@@ -1233,56 +1233,6 @@ static int validate_classes(struct policydb *p)
             return -EINVAL;
         }
     }
-    for ( i = 0; i < kdefs->av_inherit_len; i++ )
-    {
-        class_val = kdefs->av_inherit[i].tclass;
-        if ( class_val > p->p_classes.nprim )
-            continue;
-        pol_class = p->p_class_val_to_name[class_val-1];
-        cladatum = hashtab_search(p->p_classes.table, pol_class);
-        BUG_ON( !cladatum );
-        if ( !cladatum->comdatum )
-        {
-            printk(KERN_ERR
-            "Flask:  class %s should have an inherits clause but does not\n",
-                   pol_class);
-            return -EINVAL;
-        }
-        tmp = kdefs->av_inherit[i].common_base;
-        common_pts_len = 0;
-        while ( !(tmp & 0x01) )
-        {
-            common_pts_len++;
-            tmp >>= 1;
-        }
-        perms = &cladatum->comdatum->permissions;
-        for ( j = 0; j < common_pts_len; j++ )
-        {
-            def_perm = kdefs->av_inherit[i].common_pts[j];
-            if ( j >= perms->nprim )
-            {
-                printk(KERN_INFO
-                "Flask:  permission %s in class %s not defined in policy\n",
-                       def_perm, pol_class);
-                return -EINVAL;
-            }
-            perdatum = hashtab_search(perms->table, def_perm);
-            if ( perdatum == NULL )
-            {
-                printk(KERN_ERR
-                       "Flask:  permission %s in class %s not found in policy\n",
-                       def_perm, pol_class);
-                return -EINVAL;
-            }
-            if ( perdatum->value != j + 1 )
-            {
-                printk(KERN_ERR
-                      "Flask:  permission %s in class %s has incorrect value\n",
-                       def_perm, pol_class);
-                return -EINVAL;
-            }
-        }
-    }
     return 0;
 }
 
-- 
1.7.11.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 12 16:00:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Sep 2012 16:00:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TBpMC-0005h4-JG; Wed, 12 Sep 2012 16:00:04 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1TBpMA-0005NZ-CW
	for xen-devel@lists.xen.org; Wed, 12 Sep 2012 16:00:02 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-9.tower-27.messagelabs.com!1347465594!9477808!1
X-Originating-IP: [63.239.67.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15430 invoked from network); 12 Sep 2012 15:59:55 -0000
Received: from emvm-gh1-uea09.nsa.gov (HELO nsa.gov) (63.239.67.10)
	by server-9.tower-27.messagelabs.com with SMTP;
	12 Sep 2012 15:59:55 -0000
X-TM-IMSS-Message-ID: <39e11eaa001083d6@nsa.gov>
Received: from tarius.tycho.ncsc.mil ([144.51.3.1]) by nsa.gov
	([63.239.67.10]) with ESMTP (TREND IMSS SMTP Service 7.1) id
	39e11eaa001083d6 ; Wed, 12 Sep 2012 12:02:01 -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 q8CFxoOL006669; 
	Wed, 12 Sep 2012 11:59:53 -0400
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xen.org
Date: Wed, 12 Sep 2012 11:59:35 -0400
Message-Id: <1347465586-20009-12-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.11.4
In-Reply-To: <1347465586-20009-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1347465586-20009-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: dgdegra@tycho.nsa.gov, Keir Fraser <keir@xen.org>,
	Jan Beulich <jbeulich@suse.com>
Subject: [Xen-devel] [PATCH 11/22] xen: avoid calling
	rcu_lock_*target_domain when an XSM hook 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>
MIME-Version: 1.0
Content-Type: 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 rcu_lock_{,remote_}target_domain_by_id functions are wrappers around
an IS_PRIV_FOR check for the current domain. This is now redundant with
XSM hooks, so replace these calls with rcu_lock_domain_by_any_id or
rcu_lock_remote_domain_by_id to remove the duplicate permission checks.

When XSM_ENABLE is not defined or when the dummy XSM module is used,
this patch should not change any functionality. Because the locations of
privilege checks have sometimes moved below argument validation, error
returns of some functions may change from EPERM to EINVAL when called
with invalid arguments and from a domain without permission to perform
the operation.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Cc: Keir Fraser <keir@xen.org>
Cc: Jan Beulich <jbeulich@suse.com>
---
 xen/arch/x86/hvm/hvm.c     | 38 +++++++++++++++----------------
 xen/arch/x86/mm.c          | 22 ++++++++----------
 xen/common/event_channel.c | 18 +++++++--------
 xen/common/grant_table.c   | 57 +++++++++++++++-------------------------------
 xen/common/memory.c        | 15 ++++++------
 xen/include/xsm/dummy.h    | 34 +++++++++++++++++++++++++++
 6 files changed, 97 insertions(+), 87 deletions(-)

diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 2cb08c9..ca06976 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -3335,7 +3335,7 @@ static int hvmop_set_pci_intx_level(
     if ( (op.domain > 0) || (op.bus > 0) || (op.device > 31) || (op.intx > 3) )
         return -EINVAL;
 
-    rc = rcu_lock_remote_target_domain_by_id(op.domid, &d);
+    rc = rcu_lock_remote_domain_by_id(op.domid, &d);
     if ( rc != 0 )
         return rc;
 
@@ -3500,7 +3500,7 @@ static int hvmop_set_isa_irq_level(
     if ( op.isa_irq > 15 )
         return -EINVAL;
 
-    rc = rcu_lock_remote_target_domain_by_id(op.domid, &d);
+    rc = rcu_lock_remote_domain_by_id(op.domid, &d);
     if ( rc != 0 )
         return rc;
 
@@ -3544,7 +3544,7 @@ static int hvmop_set_pci_link_route(
     if ( (op.link > 3) || (op.isa_irq > 15) )
         return -EINVAL;
 
-    rc = rcu_lock_remote_target_domain_by_id(op.domid, &d);
+    rc = rcu_lock_remote_domain_by_id(op.domid, &d);
     if ( rc != 0 )
         return rc;
 
@@ -3574,7 +3574,7 @@ static int hvmop_inject_msi(
     if ( copy_from_guest(&op, uop, 1) )
         return -EFAULT;
 
-    rc = rcu_lock_remote_target_domain_by_id(op.domid, &d);
+    rc = rcu_lock_remote_domain_by_id(op.domid, &d);
     if ( rc != 0 )
         return rc;
 
@@ -3671,9 +3671,9 @@ long do_hvm_op(unsigned long op, XEN_GUEST_HANDLE(void) arg)
         if ( a.index >= HVM_NR_PARAMS )
             return -EINVAL;
 
-        rc = rcu_lock_target_domain_by_id(a.domid, &d);
-        if ( rc != 0 )
-            return rc;
+        d = rcu_lock_domain_by_any_id(a.domid);
+        if ( d == NULL )
+            return -ESRCH;
 
         rc = -EINVAL;
         if ( !is_hvm_domain(d) )
@@ -3917,7 +3917,7 @@ long do_hvm_op(unsigned long op, XEN_GUEST_HANDLE(void) arg)
         if ( copy_from_guest(&a, arg, 1) )
             return -EFAULT;
 
-        rc = rcu_lock_remote_target_domain_by_id(a.domid, &d);
+        rc = rcu_lock_remote_domain_by_id(a.domid, &d);
         if ( rc != 0 )
             return rc;
 
@@ -3956,7 +3956,7 @@ long do_hvm_op(unsigned long op, XEN_GUEST_HANDLE(void) arg)
         if ( copy_from_guest(&a, arg, 1) )
             return -EFAULT;
 
-        rc = rcu_lock_remote_target_domain_by_id(a.domid, &d);
+        rc = rcu_lock_remote_domain_by_id(a.domid, &d);
         if ( rc != 0 )
             return rc;
 
@@ -4006,9 +4006,9 @@ long do_hvm_op(unsigned long op, XEN_GUEST_HANDLE(void) arg)
         if ( copy_from_guest(&a, arg, 1) )
             return -EFAULT;
 
-        rc = rcu_lock_target_domain_by_id(a.domid, &d);
-        if ( rc != 0 )
-            return rc;
+        d = rcu_lock_domain_by_any_id(a.domid);
+        if ( d == NULL )
+            return -ESRCH;
 
         rc = xsm_hvm_param(d, op);
         if ( rc )
@@ -4053,7 +4053,7 @@ long do_hvm_op(unsigned long op, XEN_GUEST_HANDLE(void) arg)
         if ( copy_from_guest(&a, arg, 1) )
             return -EFAULT;
 
-        rc = rcu_lock_remote_target_domain_by_id(a.domid, &d);
+        rc = rcu_lock_remote_domain_by_id(a.domid, &d);
         if ( rc != 0 )
             return rc;
 
@@ -4132,7 +4132,7 @@ long do_hvm_op(unsigned long op, XEN_GUEST_HANDLE(void) arg)
         if ( copy_from_guest(&a, arg, 1) )
             return -EFAULT;
 
-        rc = rcu_lock_remote_target_domain_by_id(a.domid, &d);
+        rc = rcu_lock_remote_domain_by_id(a.domid, &d);
         if ( rc != 0 )
             return rc;
 
@@ -4167,7 +4167,7 @@ long do_hvm_op(unsigned long op, XEN_GUEST_HANDLE(void) arg)
         if ( copy_from_guest(&a, arg, 1) )
             return -EFAULT;
 
-        rc = rcu_lock_remote_target_domain_by_id(a.domid, &d);
+        rc = rcu_lock_remote_domain_by_id(a.domid, &d);
         if ( rc != 0 )
             return rc;
 
@@ -4203,9 +4203,9 @@ long do_hvm_op(unsigned long op, XEN_GUEST_HANDLE(void) arg)
         if ( copy_from_guest(&a, arg, 1) )
             return -EFAULT;
 
-        rc = rcu_lock_target_domain_by_id(a.domid, &d);
-        if ( rc != 0 )
-            return rc;
+        d = rcu_lock_domain_by_any_id(a.domid);
+        if ( d == NULL )
+            return -ESRCH;
 
         rc = -EINVAL;
         if ( !is_hvm_domain(d) || !paging_mode_shadow(d) )
@@ -4257,7 +4257,7 @@ long do_hvm_op(unsigned long op, XEN_GUEST_HANDLE(void) arg)
         if ( copy_from_guest(&tr, arg, 1 ) )
             return -EFAULT;
 
-        rc = rcu_lock_remote_target_domain_by_id(tr.domid, &d);
+        rc = rcu_lock_remote_domain_by_id(tr.domid, &d);
         if ( rc != 0 )
             return rc;
 
diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
index b370300..5c6ea2d 100644
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -4371,9 +4371,9 @@ long arch_memory_op(int op, XEN_GUEST_HANDLE(void) arg)
         if ( copy_from_guest(&xatp, arg, 1) )
             return -EFAULT;
 
-        rc = rcu_lock_target_domain_by_id(xatp.domid, &d);
-        if ( rc != 0 )
-            return rc;
+        d = rcu_lock_domain_by_any_id(xatp.domid);
+        if ( d == NULL )
+            return -ESRCH;
 
         if ( xsm_add_to_physmap(current->domain, d) )
         {
@@ -4410,9 +4410,9 @@ long arch_memory_op(int op, XEN_GUEST_HANDLE(void) arg)
         if ( fmap.map.nr_entries > E820MAX )
             return -EINVAL;
 
-        rc = rcu_lock_target_domain_by_id(fmap.domid, &d);
-        if ( rc != 0 )
-            return rc;
+        d = rcu_lock_domain_by_any_id(fmap.domid);
+        if ( d == NULL )
+            return -ESRCH;
 
         rc = xsm_domain_memory_map(d);
         if ( rc )
@@ -4563,16 +4563,12 @@ long arch_memory_op(int op, XEN_GUEST_HANDLE(void) arg)
         struct domain *d;
         struct p2m_domain *p2m;
 
-        /* Support DOMID_SELF? */
-        if ( !IS_PRIV(current->domain) )
-            return -EPERM;
-
         if ( copy_from_guest(&target, arg, 1) )
             return -EFAULT;
 
-        rc = rcu_lock_target_domain_by_id(target.domid, &d);
-        if ( rc != 0 )
-            return rc;
+        d = rcu_lock_domain_by_any_id(target.domid);
+        if ( d == NULL )
+            return -ESRCH;
 
         if ( op == XENMEM_set_pod_target )
             rc = xsm_set_pod_target(d);
diff --git a/xen/common/event_channel.c b/xen/common/event_channel.c
index 53777f8..70becdd 100644
--- a/xen/common/event_channel.c
+++ b/xen/common/event_channel.c
@@ -165,9 +165,9 @@ static long evtchn_alloc_unbound(evtchn_alloc_unbound_t *alloc)
     domid_t        dom = alloc->dom;
     long           rc;
 
-    rc = rcu_lock_target_domain_by_id(dom, &d);
-    if ( rc )
-        return rc;
+    d = rcu_lock_domain_by_any_id(dom);
+    if ( d == NULL )
+        return -ESRCH;
 
     spin_lock(&d->event_lock);
 
@@ -798,9 +798,9 @@ static long evtchn_status(evtchn_status_t *status)
     struct evtchn   *chn;
     long             rc = 0;
 
-    rc = rcu_lock_target_domain_by_id(dom, &d);
-    if ( rc )
-        return rc;
+    d = rcu_lock_domain_by_any_id(dom);
+    if ( d == NULL )
+        return -ESRCH;
 
     spin_lock(&d->event_lock);
 
@@ -950,9 +950,9 @@ static long evtchn_reset(evtchn_reset_t *r)
     struct domain *d;
     int i, rc;
 
-    rc = rcu_lock_target_domain_by_id(dom, &d);
-    if ( rc )
-        return rc;
+    d = rcu_lock_domain_by_any_id(dom);
+    if ( d == NULL )
+        return -ESRCH;
 
     rc = xsm_evtchn_reset(current->domain, d);
     if ( rc )
diff --git a/xen/common/grant_table.c b/xen/common/grant_table.c
index c23c053..10a34d6 100644
--- a/xen/common/grant_table.c
+++ b/xen/common/grant_table.c
@@ -230,30 +230,6 @@ double_gt_unlock(struct grant_table *lgt, struct grant_table *rgt)
         spin_unlock(&rgt->lock);
 }
 
-static struct domain *gt_lock_target_domain_by_id(domid_t dom)
-{
-    struct domain *d;
-    int rc = GNTST_general_error;
-
-    switch ( rcu_lock_target_domain_by_id(dom, &d) )
-    {
-    case 0:
-        return d;
-
-    case -ESRCH:
-        gdprintk(XENLOG_INFO, "Bad domid %d.\n", dom);
-        rc = GNTST_bad_domain;
-        break;
-
-    case -EPERM:
-        rc = GNTST_permission_denied;
-        break;
-    }
-
-    ASSERT(rc < 0 && -rc <= MAX_ERRNO);
-    return ERR_PTR(rc);
-}
-
 static inline int
 __get_maptrack_handle(
     struct grant_table *t)
@@ -1339,11 +1315,12 @@ gnttab_setup_table(
         goto out1;
     }
 
-    d = gt_lock_target_domain_by_id(op.dom);
-    if ( IS_ERR(d) )
+    d = rcu_lock_domain_by_any_id(op.dom);
+    if ( d == NULL )
     {
-        op.status = PTR_ERR(d);
-        goto out1;
+        gdprintk(XENLOG_INFO, "Bad domid %d.\n", op.dom);
+        op.status = GNTST_bad_domain;
+        goto out2;
     }
 
     if ( xsm_grant_setup(current->domain, d) )
@@ -1407,10 +1384,11 @@ gnttab_query_size(
         return -EFAULT;
     }
 
-    d = gt_lock_target_domain_by_id(op.dom);
-    if ( IS_ERR(d) )
+    d = rcu_lock_domain_by_any_id(op.dom);
+    if ( d == NULL )
     {
-        op.status = PTR_ERR(d);
+        gdprintk(XENLOG_INFO, "Bad domid %d.\n", op.dom);
+        op.status = GNTST_bad_domain;
         goto query_out;
     }
 
@@ -2280,10 +2258,10 @@ gnttab_get_status_frames(XEN_GUEST_HANDLE(gnttab_get_status_frames_t) uop,
         return -EFAULT;
     }
 
-    d = gt_lock_target_domain_by_id(op.dom);
-    if ( IS_ERR(d) )
+    d = rcu_lock_domain_by_any_id(op.dom);
+    if ( d == NULL )
     {
-        op.status = PTR_ERR(d);
+        op.status = GNTST_bad_domain;
         goto out1;
     }
     rc = xsm_grant_setup(current->domain, d);
@@ -2333,14 +2311,15 @@ gnttab_get_version(XEN_GUEST_HANDLE(gnttab_get_version_t uop))
     if ( copy_from_guest(&op, uop, 1) )
         return -EFAULT;
 
-    rc = rcu_lock_target_domain_by_id(op.dom, &d);
-    if ( rc < 0 )
-        return rc;
+    d = rcu_lock_domain_by_any_id(op.dom);
+    if ( d == NULL )
+        return -ESRCH;
 
-    if ( xsm_grant_query_size(current->domain, d) )
+    rc = xsm_grant_query_size(current->domain, d);
+    if ( rc )
     {
         rcu_unlock_domain(d);
-        return -EPERM;
+        return rc;
     }
 
     op.version = d->grant_table->gt_version;
diff --git a/xen/common/memory.c b/xen/common/memory.c
index 8779d6b..cfdd63f 100644
--- a/xen/common/memory.c
+++ b/xen/common/memory.c
@@ -570,7 +570,8 @@ long do_memory_op(unsigned long cmd, XEN_GUEST_HANDLE(void) arg)
              && (reservation.mem_flags & XENMEMF_populate_on_demand) )
             args.memflags |= MEMF_populate_on_demand;
 
-        if ( unlikely(rcu_lock_target_domain_by_id(reservation.domid, &d)) )
+        d = rcu_lock_domain_by_any_id(reservation.domid);
+        if ( d == NULL )
             return start_extent;
         args.domain = d;
 
@@ -619,9 +620,9 @@ long do_memory_op(unsigned long cmd, XEN_GUEST_HANDLE(void) arg)
         if ( copy_from_guest(&domid, arg, 1) )
             return -EFAULT;
 
-        rc = rcu_lock_target_domain_by_id(domid, &d);
-        if ( rc )
-            return rc;
+        d = rcu_lock_domain_by_any_id(domid);
+        if ( d == NULL )
+            return -ESRCH;
 
         rc = xsm_memory_stat_reservation(current->domain, d);
         if ( rc )
@@ -657,9 +658,9 @@ long do_memory_op(unsigned long cmd, XEN_GUEST_HANDLE(void) arg)
         if ( copy_from_guest(&xrfp, arg, 1) )
             return -EFAULT;
 
-        rc = rcu_lock_target_domain_by_id(xrfp.domid, &d);
-        if ( rc != 0 )
-            return rc;
+        d = rcu_lock_domain_by_any_id(xrfp.domid);
+        if ( d == NULL )
+            return -ESRCH;
 
         if ( xsm_remove_from_physmap(current->domain, d) )
         {
diff --git a/xen/include/xsm/dummy.h b/xen/include/xsm/dummy.h
index 389d9f6..31f862d 100644
--- a/xen/include/xsm/dummy.h
+++ b/xen/include/xsm/dummy.h
@@ -194,6 +194,8 @@ static XSM_DEFAULT(int, grant_unmapref) (struct domain *d1, struct domain *d2)
 
 static XSM_DEFAULT(int, grant_setup) (struct domain *d1, struct domain *d2)
 {
+    if ( d1 != d2 && !IS_PRIV_FOR(d1, d2) )
+        return -EPERM;
     return 0;
 }
 
@@ -209,17 +211,23 @@ static XSM_DEFAULT(int, grant_copy) (struct domain *d1, struct domain *d2)
 
 static XSM_DEFAULT(int, grant_query_size) (struct domain *d1, struct domain *d2)
 {
+    if ( d1 != d2 && !IS_PRIV_FOR(d1, d2) )
+        return -EPERM;
     return 0;
 }
 
 static XSM_DEFAULT(int, memory_adjust_reservation) (struct domain *d1,
                                                             struct domain *d2)
 {
+    if ( d1 != d2 && !IS_PRIV_FOR(d1, d2) )
+        return -EPERM;
     return 0;
 }
 
 static XSM_DEFAULT(int, memory_stat_reservation) (struct domain *d1, struct domain *d2)
 {
+    if ( d1 != d2 && !IS_PRIV_FOR(d1, d2) )
+        return -EPERM;
     return 0;
 }
 
@@ -260,6 +268,8 @@ static XSM_DEFAULT(int, memory_pin_page) (struct domain *d1, struct domain *d2,
 static XSM_DEFAULT(int, evtchn_unbound) (struct domain *d, struct evtchn *chn,
                                          domid_t id2)
 {
+    if ( current->domain != d && !IS_PRIV_FOR(current->domain, d) )
+        return -EPERM;
     return 0;
 }
 
@@ -281,11 +291,15 @@ static XSM_DEFAULT(int, evtchn_send) (struct domain *d, struct evtchn *chn)
 
 static XSM_DEFAULT(int, evtchn_status) (struct domain *d, struct evtchn *chn)
 {
+    if ( current->domain != d && !IS_PRIV_FOR(current->domain, d) )
+        return -EPERM;
     return 0;
 }
 
 static XSM_DEFAULT(int, evtchn_reset) (struct domain *d1, struct domain *d2)
 {
+    if ( d1 != d2 && !IS_PRIV_FOR(d1, d2) )
+        return -EPERM;
     return 0;
 }
 
@@ -306,11 +320,15 @@ static XSM_DEFAULT(char *, show_security_evtchn) (struct domain *d, const struct
 
 static XSM_DEFAULT(int, get_pod_target)(struct domain *d)
 {
+    if ( !IS_PRIV(current->domain) )
+        return -EPERM;
     return 0;
 }
 
 static XSM_DEFAULT(int, set_pod_target)(struct domain *d)
 {
+    if ( !IS_PRIV(current->domain) )
+        return -EPERM;
     return 0;
 }
 
@@ -481,26 +499,36 @@ static XSM_DEFAULT(int, machine_address_size) (struct domain *d, uint32_t cmd)
 
 static XSM_DEFAULT(int, hvm_param) (struct domain *d, unsigned long op)
 {
+    if ( current->domain != d && !IS_PRIV_FOR(current->domain, d) )
+        return -EPERM;
     return 0;
 }
 
 static XSM_DEFAULT(int, hvm_set_pci_intx_level) (struct domain *d)
 {
+    if ( !IS_PRIV_FOR(current->domain, d) )
+        return -EPERM;
     return 0;
 }
 
 static XSM_DEFAULT(int, hvm_set_isa_irq_level) (struct domain *d)
 {
+    if ( !IS_PRIV_FOR(current->domain, d) )
+        return -EPERM;
     return 0;
 }
 
 static XSM_DEFAULT(int, hvm_set_pci_link_route) (struct domain *d)
 {
+    if ( !IS_PRIV_FOR(current->domain, d) )
+        return -EPERM;
     return 0;
 }
 
 static XSM_DEFAULT(int, hvm_inject_msi) (struct domain *d)
 {
+    if ( !IS_PRIV_FOR(current->domain, d) )
+        return -EPERM;
     return 0;
 }
 
@@ -582,6 +610,8 @@ static XSM_DEFAULT(int, machine_memory_map) (void)
 
 static XSM_DEFAULT(int, domain_memory_map) (struct domain *d)
 {
+    if ( current->domain != d && !IS_PRIV_FOR(current->domain, d) )
+        return -EPERM;
     return 0;
 }
 
@@ -605,11 +635,15 @@ static XSM_DEFAULT(int, update_va_mapping) (struct domain *d, struct domain *f,
 
 static XSM_DEFAULT(int, add_to_physmap) (struct domain *d1, struct domain *d2)
 {
+    if ( d1 != d2 && !IS_PRIV_FOR(d1, d2) )
+        return -EPERM;
     return 0;
 }
 
 static XSM_DEFAULT(int, remove_from_physmap) (struct domain *d1, struct domain *d2)
 {
+    if ( d1 != d2 && !IS_PRIV_FOR(d1, d2) )
+        return -EPERM;
     return 0;
 }
 
-- 
1.7.11.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 12 16:00:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Sep 2012 16:00:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TBpM4-0005NH-JZ; Wed, 12 Sep 2012 15:59:56 +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 1TBpM3-0005Mk-6k
	for xen-devel@lists.xen.org; Wed, 12 Sep 2012 15:59:55 +0000
Received: from [85.158.138.51:6711] by server-10.bemta-3.messagelabs.com id
	AE/62-10411-A71B0505; Wed, 12 Sep 2012 15:59:54 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-8.tower-174.messagelabs.com!1347465593!30148384!1
X-Originating-IP: [63.239.67.9]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5574 invoked from network); 12 Sep 2012 15:59:53 -0000
Received: from emvm-gh1-uea08.nsa.gov (HELO nsa.gov) (63.239.67.9)
	by server-8.tower-174.messagelabs.com with SMTP;
	12 Sep 2012 15:59:53 -0000
X-TM-IMSS-Message-ID: <39e159d500102340@nsa.gov>
Received: from tarius.tycho.ncsc.mil ([144.51.3.1]) by nsa.gov ([63.239.67.9])
	with ESMTP (TREND IMSS SMTP Service 7.1) id 39e159d500102340 ;
	Wed, 12 Sep 2012 11:59:43 -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 q8CFxoOD006669; 
	Wed, 12 Sep 2012 11:59:51 -0400
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xen.org
Date: Wed, 12 Sep 2012 11:59:27 -0400
Message-Id: <1347465586-20009-4-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.11.4
In-Reply-To: <1347465586-20009-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1347465586-20009-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: dgdegra@tycho.nsa.gov
Subject: [Xen-devel] [PATCH 03/22] xen: Add versions of rcu_lock_*_domain
	without IS_PRIV checks
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

These functions will be used to avoid duplication of IS_PRIV calls
that will be introduced in XSM hooks.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 xen/common/domain.c     | 21 +++++++++++++++++++++
 xen/include/xen/sched.h | 11 +++++++++++
 2 files changed, 32 insertions(+)

diff --git a/xen/common/domain.c b/xen/common/domain.c
index a1aa05e..52489b3 100644
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -420,6 +420,13 @@ struct domain *rcu_lock_domain_by_id(domid_t dom)
     return d;
 }
 
+struct domain *rcu_lock_domain_by_any_id(domid_t dom)
+{
+    if ( dom == DOMID_SELF )
+        return rcu_lock_current_domain();
+    return rcu_lock_domain_by_id(dom);
+}
+
 int rcu_lock_target_domain_by_id(domid_t dom, struct domain **d)
 {
     if ( dom == DOMID_SELF )
@@ -454,6 +461,20 @@ int rcu_lock_remote_target_domain_by_id(domid_t dom, struct domain **d)
     return 0;
 }
 
+int rcu_lock_remote_domain_by_id(domid_t dom, struct domain **d)
+{
+    if ( (*d = rcu_lock_domain_by_id(dom)) == NULL )
+        return -ESRCH;
+
+    if ( *d == current->domain )
+    {
+        rcu_unlock_domain(*d);
+        return -EPERM;
+    }
+
+    return 0;
+}
+
 int domain_kill(struct domain *d)
 {
     int rc = 0;
diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
index 53804c8..b0def4a 100644
--- a/xen/include/xen/sched.h
+++ b/xen/include/xen/sched.h
@@ -447,6 +447,11 @@ struct domain *domain_create(
 struct domain *rcu_lock_domain_by_id(domid_t dom);
 
 /*
+ * As above function, but resolves DOMID_SELF to current domain
+ */
+struct domain *rcu_lock_domain_by_any_id(domid_t dom);
+
+/*
  * As above function, but accounts for current domain context:
  *  - Translates target DOMID_SELF into caller's domain id; and
  *  - Checks that caller has permission to act on the target domain.
@@ -460,6 +465,12 @@ int rcu_lock_target_domain_by_id(domid_t dom, struct domain **d);
  */
 int rcu_lock_remote_target_domain_by_id(domid_t dom, struct domain **d);
 
+/*
+ * As rcu_lock_domain_by_id(), but will fail EPERM or ESRCH rather than resolve
+ * to local domain.
+ */
+int rcu_lock_remote_domain_by_id(domid_t dom, struct domain **d);
+
 /* Finish a RCU critical region started by rcu_lock_domain_by_id(). */
 static inline void rcu_unlock_domain(struct domain *d)
 {
-- 
1.7.11.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 12 16:00:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Sep 2012 16:00:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TBpM8-0005QI-Jo; Wed, 12 Sep 2012 16:00:00 +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 1TBpM7-0005N3-Do
	for xen-devel@lists.xen.org; Wed, 12 Sep 2012 15:59:59 +0000
Received: from [85.158.138.51:27115] by server-8.bemta-3.messagelabs.com id
	AD/63-24700-F71B0505; Wed, 12 Sep 2012 15:59:59 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-9.tower-174.messagelabs.com!1347465597!28508951!1
X-Originating-IP: [63.239.67.9]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14347 invoked from network); 12 Sep 2012 15:59:57 -0000
Received: from emvm-gh1-uea08.nsa.gov (HELO nsa.gov) (63.239.67.9)
	by server-9.tower-174.messagelabs.com with SMTP;
	12 Sep 2012 15:59:57 -0000
X-TM-IMSS-Message-ID: <39e16bfe0010234f@nsa.gov>
Received: from tarius.tycho.ncsc.mil ([144.51.3.1]) by nsa.gov ([63.239.67.9])
	with ESMTP (TREND IMSS SMTP Service 7.1) id 39e16bfe0010234f ;
	Wed, 12 Sep 2012 11:59:48 -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 q8CFxoOU006669; 
	Wed, 12 Sep 2012 11:59:56 -0400
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xen.org
Date: Wed, 12 Sep 2012 11:59:44 -0400
Message-Id: <1347465586-20009-21-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.11.4
In-Reply-To: <1347465586-20009-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1347465586-20009-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Tim Deegan <tim@xen.org>, dgdegra@tycho.nsa.gov, Keir Fraser <keir@xen.org>,
	Jan Beulich <jbeulich@suse.com>
Subject: [Xen-devel] [PATCH 20/22] arch/x86: use XSM hooks for get_pg_owner
	access checks
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

There are three callers of get_pg_owner:
 * do_mmuext_op, which does not have XSM hooks on all subfunctions
 * do_mmu_update, which has hooks that are inefficient
 * do_update_va_mapping_otherdomain, which has a simple XSM hook

In order to preserve return values for the do_mmuext_op hypercall, an
additional XSM hook is required to check the operation even for those
subfunctions that do not use the pg_owner field. This also covers the
MMUEXT_UNPIN_TABLE operation which did previously have an XSM hook.

The XSM hooks in do_mmu_update were capable of replacing the checks in
get_pg_owner; however, the hooks are buried in the inner loop of the
function - not very good for performance when XSM is enabled and these
turn in to indirect function calls. This patch removes the PTE from the
hooks and replaces it with a bitfield describing what accesses are being
requested. The XSM hook can then be called only when additional bits are
set instead of once per iteration of the loop.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Cc: Keir Fraser <keir@xen.org>
Cc: Jan Beulich <jbeulich@suse.com>
Cc: Tim Deegan <tim@xen.org>
---
 tools/flask/policy/policy/flask/access_vectors |  1 +
 tools/flask/policy/policy/modules/xen/xen.if   |  4 +-
 xen/arch/x86/mm.c                              | 53 +++++++++++--------
 xen/include/xsm/dummy.h                        | 15 ++++--
 xen/include/xsm/xsm.h                          | 25 +++++----
 xen/xsm/dummy.c                                |  4 +-
 xen/xsm/flask/hooks.c                          | 71 +++++++++-----------------
 xen/xsm/flask/include/av_perm_to_string.h      |  1 +
 xen/xsm/flask/include/av_permissions.h         |  1 +
 9 files changed, 88 insertions(+), 87 deletions(-)

diff --git a/tools/flask/policy/policy/flask/access_vectors b/tools/flask/policy/policy/flask/access_vectors
index 45ac437..8324725 100644
--- a/tools/flask/policy/policy/flask/access_vectors
+++ b/tools/flask/policy/policy/flask/access_vectors
@@ -141,6 +141,7 @@ class mmu
     mfnlist
     memorymap
     remote_remap
+	mmuext_op
 }
 
 class shadow
diff --git a/tools/flask/policy/policy/modules/xen/xen.if b/tools/flask/policy/policy/modules/xen/xen.if
index d630f47..725d7a1 100644
--- a/tools/flask/policy/policy/modules/xen/xen.if
+++ b/tools/flask/policy/policy/modules/xen/xen.if
@@ -7,7 +7,7 @@
 ################################################################################
 define(`declare_domain_common', `
 	allow $1 $2:grant { query setup };
-	allow $1 $2:mmu { adjust physmap map_read map_write stat pinpage updatemp };
+	allow $1 $2:mmu { adjust physmap map_read map_write stat pinpage updatemp mmuext_op };
 	allow $1 $2:hvm { getparam setparam };
 ')
 
@@ -51,7 +51,7 @@ define(`create_domain_common', `
 	allow $1 $2:domain2 { set_cpuid settsc };
 	allow $1 $2:security check_context;
 	allow $1 $2:shadow enable;
-	allow $1 $2:mmu {map_read map_write adjust memorymap physmap pinpage};
+	allow $1 $2:mmu { map_read map_write adjust memorymap physmap pinpage mmuext_op };
 	allow $1 $2:grant setup;
 	allow $1 $2:hvm { cacheattr getparam hvmctl irqlevel pciroute sethvmc setparam pcilevel trackdirtyvram };
 ')
diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
index c0c2bf3..04a056f 100644
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -2619,11 +2619,6 @@ static struct domain *get_pg_owner(domid_t domid)
         pg_owner = rcu_lock_domain(dom_io);
         break;
     case DOMID_XEN:
-        if ( !IS_PRIV(curr) )
-        {
-            MEM_LOG("Cannot set foreign dom");
-            break;
-        }
         pg_owner = rcu_lock_domain(dom_xen);
         break;
     default:
@@ -2632,12 +2627,6 @@ static struct domain *get_pg_owner(domid_t domid)
             MEM_LOG("Unknown domain '%u'", domid);
             break;
         }
-        if ( !IS_PRIV_FOR(curr, pg_owner) )
-        {
-            MEM_LOG("Cannot set foreign dom");
-            rcu_unlock_domain(pg_owner);
-            pg_owner = NULL;
-        }
         break;
     }
 
@@ -2725,6 +2714,13 @@ long do_mmuext_op(
         goto out;
     }
 
+    rc = xsm_mmuext_op(d, pg_owner);
+    if ( rc )
+    {
+        rcu_unlock_domain(pg_owner);
+        goto out;
+    }
+
     for ( i = 0; i < count; i++ )
     {
         if ( hypercall_preempt_check() )
@@ -3164,6 +3160,8 @@ long do_mmu_update(
     struct vcpu *v = current;
     struct domain *d = v->domain, *pt_owner = d, *pg_owner;
     struct domain_mmap_cache mapcache;
+    uint32_t xsm_needed = 0;
+    uint32_t xsm_checked = 0;
 
     if ( unlikely(count & MMU_UPDATE_PREEMPTED) )
     {
@@ -3195,11 +3193,6 @@ long do_mmu_update(
             rc = -EINVAL;
             goto out;
         }
-        if ( !IS_PRIV_FOR(d, pt_owner) )
-        {
-            rc = -ESRCH;
-            goto out;
-        }
     }
 
     if ( (pg_owner = get_pg_owner((uint16_t)foreigndom)) == NULL )
@@ -3239,9 +3232,20 @@ long do_mmu_update(
         {
             p2m_type_t p2mt;
 
-            rc = xsm_mmu_normal_update(d, pt_owner, pg_owner, req.val);
-            if ( rc )
-                break;
+            xsm_needed |= XSM_MMU_NORMAL_UPDATE;
+            if ( get_pte_flags(req.val) & _PAGE_PRESENT )
+            {
+                xsm_needed |= XSM_MMU_UPDATE_READ;
+                if ( get_pte_flags(req.val) & _PAGE_RW )
+                    xsm_needed |= XSM_MMU_UPDATE_WRITE;
+            }
+            if ( xsm_needed != xsm_checked )
+            {
+                rc = xsm_mmu_update(d, pt_owner, pg_owner, xsm_needed);
+                if ( rc )
+                    break;
+                xsm_checked = xsm_needed;
+            }
             rc = -EINVAL;
 
             req.ptr -= cmd;
@@ -3353,9 +3357,14 @@ long do_mmu_update(
             mfn = req.ptr >> PAGE_SHIFT;
             gpfn = req.val;
 
-            rc = xsm_mmu_machphys_update(d, pg_owner, mfn);
-            if ( rc )
-                break;
+            xsm_needed |= XSM_MMU_MACHPHYS_UPDATE;
+            if ( xsm_needed != xsm_checked )
+            {
+                rc = xsm_mmu_update(d, pt_owner, pg_owner, xsm_needed);
+                if ( rc )
+                    break;
+                xsm_checked = xsm_needed;
+            }
 
             if ( unlikely(!get_page_from_pagenr(mfn, pg_owner)) )
             {
diff --git a/xen/include/xsm/dummy.h b/xen/include/xsm/dummy.h
index 1760cd9..9c13d5c037 100644
--- a/xen/include/xsm/dummy.h
+++ b/xen/include/xsm/dummy.h
@@ -662,21 +662,28 @@ static XSM_DEFAULT(int, domain_memory_map) (struct domain *d)
     return 0;
 }
 
-static XSM_DEFAULT(int, mmu_normal_update) (struct domain *d, struct domain *t,
-                                            struct domain *f, intpte_t fpte)
+static XSM_DEFAULT(int, mmu_update) (struct domain *d, struct domain *t,
+                                     struct domain *f, uint32_t flags)
 {
+    if ( d != t && !IS_PRIV_FOR(d, t) )
+        return -EPERM;
+    if ( d != f && !IS_PRIV_FOR(d, f) )
+        return -EPERM;
     return 0;
 }
 
-static XSM_DEFAULT(int, mmu_machphys_update) (struct domain *d, struct domain *f,
-                                              unsigned long mfn)
+static XSM_DEFAULT(int, mmuext_op) (struct domain *d, struct domain *f)
 {
+    if ( d != f && !IS_PRIV_FOR(d, f) )
+        return -EPERM;
     return 0;
 }
 
 static XSM_DEFAULT(int, update_va_mapping) (struct domain *d, struct domain *f, 
                                                             l1_pgentry_t pte)
 {
+    if ( d != f && !IS_PRIV_FOR(d, f) )
+        return -EPERM;
     return 0;
 }
 
diff --git a/xen/include/xsm/xsm.h b/xen/include/xsm/xsm.h
index c2c1efa..6d970b1 100644
--- a/xen/include/xsm/xsm.h
+++ b/xen/include/xsm/xsm.h
@@ -27,8 +27,6 @@ typedef u32 xsm_magic_t;
 #define XSM_MAGIC 0x00000000
 #endif
 
-#ifdef XSM_ENABLE
-
 extern char *policy_buffer;
 extern u32 policy_size;
 
@@ -170,9 +168,13 @@ struct xsm_operations {
     int (*getidletime) (void);
     int (*machine_memory_map) (void);
     int (*domain_memory_map) (struct domain *d);
-    int (*mmu_normal_update) (struct domain *d, struct domain *t,
-                              struct domain *f, intpte_t fpte);
-    int (*mmu_machphys_update) (struct domain *d1, struct domain *d2, unsigned long mfn);
+#define XSM_MMU_UPDATE_READ      1
+#define XSM_MMU_UPDATE_WRITE     2
+#define XSM_MMU_NORMAL_UPDATE    4
+#define XSM_MMU_MACHPHYS_UPDATE  8
+    int (*mmu_update) (struct domain *d, struct domain *t,
+                       struct domain *f, uint32_t flags);
+    int (*mmuext_op) (struct domain *d, struct domain *f);
     int (*update_va_mapping) (struct domain *d, struct domain *f, l1_pgentry_t pte);
     int (*add_to_physmap) (struct domain *d1, struct domain *d2);
     int (*sendtrigger) (struct domain *d);
@@ -186,6 +188,8 @@ struct xsm_operations {
 #endif
 };
 
+#ifdef XSM_ENABLE
+
 extern struct xsm_operations *xsm_ops;
 
 static inline void xsm_security_domaininfo (struct domain *d,
@@ -761,16 +765,15 @@ static inline int xsm_domain_memory_map(struct domain *d)
     return xsm_ops->domain_memory_map(d);
 }
 
-static inline int xsm_mmu_normal_update (struct domain *d, struct domain *t,
-                                         struct domain *f, intpte_t fpte)
+static inline int xsm_mmu_update (struct domain *d, struct domain *t,
+                                  struct domain *f, uint32_t flags)
 {
-    return xsm_ops->mmu_normal_update(d, t, f, fpte);
+    return xsm_ops->mmu_update(d, t, f, flags);
 }
 
-static inline int xsm_mmu_machphys_update (struct domain *d1, struct domain *d2,
-                                           unsigned long mfn)
+static inline int xsm_mmuext_op (struct domain *d, struct domain *f)
 {
-    return xsm_ops->mmu_machphys_update(d1, d2, mfn);
+    return xsm_ops->mmuext_op(d, f);
 }
 
 static inline int xsm_update_va_mapping(struct domain *d, struct domain *f, 
diff --git a/xen/xsm/dummy.c b/xen/xsm/dummy.c
index c82c464..9476be6 100644
--- a/xen/xsm/dummy.c
+++ b/xen/xsm/dummy.c
@@ -154,8 +154,8 @@ void xsm_fixup_ops (struct xsm_operations *ops)
     set_to_dummy_if_null(ops, getidletime);
     set_to_dummy_if_null(ops, machine_memory_map);
     set_to_dummy_if_null(ops, domain_memory_map);
-    set_to_dummy_if_null(ops, mmu_normal_update);
-    set_to_dummy_if_null(ops, mmu_machphys_update);
+    set_to_dummy_if_null(ops, mmu_update);
+    set_to_dummy_if_null(ops, mmuext_op);
     set_to_dummy_if_null(ops, update_va_mapping);
     set_to_dummy_if_null(ops, add_to_physmap);
     set_to_dummy_if_null(ops, remove_from_physmap);
diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
index f993696..bd2d792 100644
--- a/xen/xsm/flask/hooks.c
+++ b/xen/xsm/flask/hooks.c
@@ -1432,65 +1432,44 @@ static int flask_domain_memory_map(struct domain *d)
     return current_has_perm(d, SECCLASS_MMU, MMU__MEMORYMAP);
 }
 
-static int domain_memory_perm(struct domain *d, struct domain *f, l1_pgentry_t pte)
+static int flask_mmu_update(struct domain *d, struct domain *t,
+                            struct domain *f, uint32_t flags)
 {
     int rc = 0;
-    u32 map_perms = MMU__MAP_READ;
-    unsigned long fgfn, fmfn;
-    p2m_type_t p2mt;
-
-    if ( !(l1e_get_flags(pte) & _PAGE_PRESENT) )
-        return 0;
-
-    if ( l1e_get_flags(pte) & _PAGE_RW )
-        map_perms |= MMU__MAP_WRITE;
-
-    fgfn = l1e_get_pfn(pte);
-    fmfn = mfn_x(get_gfn_query(f, fgfn, &p2mt));
-    put_gfn(f, fgfn);
+    u32 map_perms = 0;
 
-    if ( f->domain_id == DOMID_IO || !mfn_valid(fmfn) )
-    {
-        struct avc_audit_data ad;
-        u32 dsid, fsid;
-        rc = security_iomem_sid(fmfn, &fsid);
-        if ( rc )
-            return rc;
-        AVC_AUDIT_DATA_INIT(&ad, MEMORY);
-        ad.sdom = d;
-        ad.tdom = f;
-        ad.memory.pte = pte.l1;
-        ad.memory.mfn = fmfn;
-        dsid = domain_sid(d);
-        return avc_has_perm(dsid, fsid, SECCLASS_MMU, map_perms, &ad);
-    }
-
-    return domain_has_perm(d, f, SECCLASS_MMU, map_perms);
-}
-
-static int flask_mmu_normal_update(struct domain *d, struct domain *t,
-                                   struct domain *f, intpte_t fpte)
-{
-    int rc = 0;
-
-    if (d != t)
+    if ( (flags & XSM_MMU_NORMAL_UPDATE) && d != t )
         rc = domain_has_perm(d, t, SECCLASS_MMU, MMU__REMOTE_REMAP);
     if ( rc )
         return rc;
 
-    return domain_memory_perm(d, f, l1e_from_intpte(fpte));
+    if ( flags & XSM_MMU_UPDATE_READ )
+        map_perms |= MMU__MAP_READ;
+    if ( flags & XSM_MMU_UPDATE_WRITE )
+        map_perms |= MMU__MAP_WRITE;
+    if ( flags & XSM_MMU_MACHPHYS_UPDATE )
+        map_perms |= MMU__UPDATEMP;
+
+    if ( map_perms )
+        rc = domain_has_perm(d, f, SECCLASS_MMU, map_perms);
+    return rc;
 }
 
-static int flask_mmu_machphys_update(struct domain *d1, struct domain *d2,
-                                     unsigned long mfn)
+static int flask_mmuext_op(struct domain *d, struct domain *f)
 {
-    return domain_has_perm(d1, d2, SECCLASS_MMU, MMU__UPDATEMP);
+    return domain_has_perm(d, f, SECCLASS_MMU, MMU__MMUEXT_OP);
 }
 
 static int flask_update_va_mapping(struct domain *d, struct domain *f,
                                    l1_pgentry_t pte)
 {
-    return domain_memory_perm(d, f, pte);
+    u32 map_perms = MMU__MAP_READ;
+    if ( !(l1e_get_flags(pte) & _PAGE_PRESENT) )
+        return 0;
+    if ( l1e_get_flags(pte) & _PAGE_RW )
+        map_perms |= MMU__MAP_WRITE;
+
+    return domain_has_perm(d, f, SECCLASS_MMU, map_perms);
 }
 
 static int flask_add_to_physmap(struct domain *d1, struct domain *d2)
@@ -1771,8 +1750,8 @@ static struct xsm_operations flask_ops = {
     .getidletime = flask_getidletime,
     .machine_memory_map = flask_machine_memory_map,
     .domain_memory_map = flask_domain_memory_map,
-    .mmu_normal_update = flask_mmu_normal_update,
-    .mmu_machphys_update = flask_mmu_machphys_update,
+    .mmu_update = flask_mmu_update,
+    .mmuext_op = flask_mmuext_op,
     .update_va_mapping = flask_update_va_mapping,
     .add_to_physmap = flask_add_to_physmap,
     .remove_from_physmap = flask_remove_from_physmap,
diff --git a/xen/xsm/flask/include/av_perm_to_string.h b/xen/xsm/flask/include/av_perm_to_string.h
index 186f1fa..8f65b96 100644
--- a/xen/xsm/flask/include/av_perm_to_string.h
+++ b/xen/xsm/flask/include/av_perm_to_string.h
@@ -111,6 +111,7 @@
    S_(SECCLASS_MMU, MMU__MFNLIST, "mfnlist")
    S_(SECCLASS_MMU, MMU__MEMORYMAP, "memorymap")
    S_(SECCLASS_MMU, MMU__REMOTE_REMAP, "remote_remap")
+   S_(SECCLASS_MMU, MMU__MMUEXT_OP, "mmuext_op")
    S_(SECCLASS_SHADOW, SHADOW__DISABLE, "disable")
    S_(SECCLASS_SHADOW, SHADOW__ENABLE, "enable")
    S_(SECCLASS_SHADOW, SHADOW__LOGDIRTY, "logdirty")
diff --git a/xen/xsm/flask/include/av_permissions.h b/xen/xsm/flask/include/av_permissions.h
index b3831f6..18454fd 100644
--- a/xen/xsm/flask/include/av_permissions.h
+++ b/xen/xsm/flask/include/av_permissions.h
@@ -117,6 +117,7 @@
 #define MMU__MFNLIST                              0x00000400UL
 #define MMU__MEMORYMAP                            0x00000800UL
 #define MMU__REMOTE_REMAP                         0x00001000UL
+#define MMU__MMUEXT_OP                            0x00002000UL
 
 #define SHADOW__DISABLE                           0x00000001UL
 #define SHADOW__ENABLE                            0x00000002UL
-- 
1.7.11.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 12 16:00:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Sep 2012 16:00:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TBpM7-0005PI-E7; Wed, 12 Sep 2012 15:59:59 +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 1TBpM5-0005Mj-QS
	for xen-devel@lists.xen.org; Wed, 12 Sep 2012 15:59:58 +0000
Received: from [85.158.138.51:26987] by server-9.bemta-3.messagelabs.com id
	7E/B3-15390-D71B0505; Wed, 12 Sep 2012 15:59:57 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-11.tower-174.messagelabs.com!1347465596!30178142!1
X-Originating-IP: [63.239.67.9]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22667 invoked from network); 12 Sep 2012 15:59:56 -0000
Received: from emvm-gh1-uea08.nsa.gov (HELO nsa.gov) (63.239.67.9)
	by server-11.tower-174.messagelabs.com with SMTP;
	12 Sep 2012 15:59:56 -0000
X-TM-IMSS-Message-ID: <39e1655a0010234a@nsa.gov>
Received: from tarius.tycho.ncsc.mil ([144.51.3.1]) by nsa.gov ([63.239.67.9])
	with ESMTP (TREND IMSS SMTP Service 7.1) id 39e1655a0010234a ;
	Wed, 12 Sep 2012 11:59:46 -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 q8CFxoOP006669; 
	Wed, 12 Sep 2012 11:59:54 -0400
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xen.org
Date: Wed, 12 Sep 2012 11:59:39 -0400
Message-Id: <1347465586-20009-16-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.11.4
In-Reply-To: <1347465586-20009-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1347465586-20009-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: dgdegra@tycho.nsa.gov
Subject: [Xen-devel] [PATCH 15/22] xen: convert do_sysctl to use 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

The xsm_sysctl hook now covers every sysctl, in addition to the more
fine-grained XSM hooks in most sub-functions.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 xen/common/sysctl.c     |  7 ++++---
 xen/include/xsm/dummy.h |  7 +++++++
 xen/include/xsm/xsm.h   |  6 ++++++
 xen/xsm/dummy.c         |  1 +
 xen/xsm/flask/hooks.c   | 31 +++++++++++++++++++++++++++++++
 5 files changed, 49 insertions(+), 3 deletions(-)

diff --git a/xen/common/sysctl.c b/xen/common/sysctl.c
index ea68278..e009baa 100644
--- a/xen/common/sysctl.c
+++ b/xen/common/sysctl.c
@@ -33,15 +33,16 @@ long do_sysctl(XEN_GUEST_HANDLE(xen_sysctl_t) u_sysctl)
     struct xen_sysctl curop, *op = &curop;
     static DEFINE_SPINLOCK(sysctl_lock);
 
-    if ( !IS_PRIV(current->domain) )
-        return -EPERM;
-
     if ( copy_from_guest(op, u_sysctl, 1) )
         return -EFAULT;
 
     if ( op->interface_version != XEN_SYSCTL_INTERFACE_VERSION )
         return -EACCES;
 
+    ret = xsm_sysctl(op->cmd);
+    if ( ret )
+        return ret;
+
     /*
      * Trylock here avoids deadlock with an existing sysctl critical section
      * which might (for some current or future reason) want to synchronise
diff --git a/xen/include/xsm/dummy.h b/xen/include/xsm/dummy.h
index 6aa6aea..a9784f5 100644
--- a/xen/include/xsm/dummy.h
+++ b/xen/include/xsm/dummy.h
@@ -106,6 +106,13 @@ static XSM_DEFAULT(int, domctl)(struct domain *d, int cmd)
     return 0;
 }
 
+static XSM_DEFAULT(int, sysctl)(int cmd)
+{
+    if ( !IS_PRIV(current->domain) )
+        return -EPERM;
+    return 0;
+}
+
 static XSM_DEFAULT(int, set_virq_handler)(struct domain *d, uint32_t virq)
 {
     return 0;
diff --git a/xen/include/xsm/xsm.h b/xen/include/xsm/xsm.h
index 171acb2..ef3329f 100644
--- a/xen/include/xsm/xsm.h
+++ b/xen/include/xsm/xsm.h
@@ -58,6 +58,7 @@ struct xsm_operations {
     int (*domain_settime) (struct domain *d);
     int (*set_target) (struct domain *d, struct domain *e);
     int (*domctl) (struct domain *d, int cmd);
+    int (*sysctl) (int cmd);
     int (*set_virq_handler) (struct domain *d, uint32_t virq);
     int (*tbufcontrol) (void);
     int (*readconsole) (uint32_t clear);
@@ -265,6 +266,11 @@ static inline int xsm_domctl (struct domain *d, int cmd)
     return xsm_ops->domctl(d, cmd);
 }
 
+static inline int xsm_sysctl (int cmd)
+{
+    return xsm_ops->sysctl(cmd);
+}
+
 static inline int xsm_set_virq_handler (struct domain *d, uint32_t virq)
 {
     return xsm_ops->set_virq_handler(d, virq);
diff --git a/xen/xsm/dummy.c b/xen/xsm/dummy.c
index 7f9c753..c76212d 100644
--- a/xen/xsm/dummy.c
+++ b/xen/xsm/dummy.c
@@ -44,6 +44,7 @@ void xsm_fixup_ops (struct xsm_operations *ops)
     set_to_dummy_if_null(ops, domain_settime);
     set_to_dummy_if_null(ops, set_target);
     set_to_dummy_if_null(ops, domctl);
+    set_to_dummy_if_null(ops, sysctl);
     set_to_dummy_if_null(ops, set_virq_handler);
     set_to_dummy_if_null(ops, tbufcontrol);
     set_to_dummy_if_null(ops, readconsole);
diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
index 6d03189..16af92b 100644
--- a/xen/xsm/flask/hooks.c
+++ b/xen/xsm/flask/hooks.c
@@ -675,6 +675,36 @@ static int flask_domctl(struct domain *d, int cmd)
     }
 }
 
+static int flask_sysctl(int cmd)
+{
+    switch ( cmd )
+    {
+    /* These have individual XSM hooks */
+    case XEN_SYSCTL_readconsole:
+    case XEN_SYSCTL_tbuf_op:
+    case XEN_SYSCTL_physinfo:
+    case XEN_SYSCTL_sched_id:
+    case XEN_SYSCTL_perfc_op:
+    case XEN_SYSCTL_getdomaininfolist:
+    case XEN_SYSCTL_debug_keys:
+    case XEN_SYSCTL_getcpuinfo:
+    case XEN_SYSCTL_availheap:
+    case XEN_SYSCTL_get_pmstat:
+    case XEN_SYSCTL_cpu_hotplug:
+    case XEN_SYSCTL_pm_op:
+    case XEN_SYSCTL_page_offline_op:
+    case XEN_SYSCTL_lockprof_op:
+    case XEN_SYSCTL_topologyinfo:
+    case XEN_SYSCTL_numainfo:
+    case XEN_SYSCTL_cpupool_op:
+    case XEN_SYSCTL_scheduler_op:
+        return 0;
+    default:
+        printk("flask_sysctl: Unknown op %d\n", cmd);
+        return -EPERM;
+    }
+}
+
 static int flask_set_virq_handler(struct domain *d, uint32_t virq)
 {
     return domain_has_perm(current->domain, d, SECCLASS_DOMAIN, DOMAIN__SET_VIRQ_HANDLER);
@@ -1601,6 +1631,7 @@ static struct xsm_operations flask_ops = {
     .domain_settime = flask_domain_settime,
     .set_target = flask_set_target,
     .domctl = flask_domctl,
+    .sysctl = flask_sysctl,
     .set_virq_handler = flask_set_virq_handler,
     .tbufcontrol = flask_tbufcontrol,
     .readconsole = flask_readconsole,
-- 
1.7.11.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 12 16:00:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Sep 2012 16:00:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TBpMC-0005eu-6Z; Wed, 12 Sep 2012 16:00:04 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1TBpMA-0005Nh-F8
	for xen-devel@lists.xen.org; Wed, 12 Sep 2012 16:00:02 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-10.tower-27.messagelabs.com!1347465595!5579605!1
X-Originating-IP: [63.239.67.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31226 invoked from network); 12 Sep 2012 15:59:56 -0000
Received: from emvm-gh1-uea09.nsa.gov (HELO nsa.gov) (63.239.67.10)
	by server-10.tower-27.messagelabs.com with SMTP;
	12 Sep 2012 15:59:56 -0000
X-TM-IMSS-Message-ID: <39e12158001083da@nsa.gov>
Received: from tarius.tycho.ncsc.mil ([144.51.3.1]) by nsa.gov
	([63.239.67.10]) with ESMTP (TREND IMSS SMTP Service 7.1) id
	39e12158001083da ; Wed, 12 Sep 2012 12:02:02 -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 q8CFxoOO006669; 
	Wed, 12 Sep 2012 11:59:54 -0400
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xen.org
Date: Wed, 12 Sep 2012 11:59:38 -0400
Message-Id: <1347465586-20009-15-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.11.4
In-Reply-To: <1347465586-20009-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1347465586-20009-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: dgdegra@tycho.nsa.gov
Subject: [Xen-devel] [PATCH 14/22] xen: convert do_domctl to use 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

The xsm_domctl hook now covers every domctl, in addition to the more
fine-grained XSM hooks in most sub-functions. This also removes the need
to special-case XEN_DOMCTL_getdomaininfo.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 xen/arch/x86/domctl.c   |  2 +-
 xen/common/domctl.c     | 32 +++----------------
 xen/include/xsm/dummy.h | 16 ++++++++--
 xen/xsm/flask/hooks.c   | 85 ++++++++++++++++++++++++++++++++++++++++++++++++-
 4 files changed, 104 insertions(+), 31 deletions(-)

diff --git a/xen/arch/x86/domctl.c b/xen/arch/x86/domctl.c
index 9eebd3b..a0ecd95 100644
--- a/xen/arch/x86/domctl.c
+++ b/xen/arch/x86/domctl.c
@@ -1480,7 +1480,7 @@ long arch_do_domctl(
     {
         struct domain *d;
 
-        ret = rcu_lock_remote_target_domain_by_id(domctl->domain, &d);
+        ret = rcu_lock_remote_domain_by_id(domctl->domain, &d);
         if ( ret != 0 )
             break;
 
diff --git a/xen/common/domctl.c b/xen/common/domctl.c
index 76ced4f..48b5f6f 100644
--- a/xen/common/domctl.c
+++ b/xen/common/domctl.c
@@ -263,27 +263,9 @@ long do_domctl(XEN_GUEST_HANDLE(xen_domctl_t) u_domctl)
             return -ESRCH;
     }
 
-    switch ( op->cmd )
-    {
-    case XEN_DOMCTL_ioport_mapping:
-    case XEN_DOMCTL_memory_mapping:
-    case XEN_DOMCTL_bind_pt_irq:
-    case XEN_DOMCTL_unbind_pt_irq: {
-        bool_t is_priv = IS_PRIV_FOR(current->domain, d);
-        if ( !is_priv )
-        {
-            ret = -EPERM;
-            goto domctl_out_unlock;
-        }
-        break;
-    }
-    case XEN_DOMCTL_getdomaininfo:
-        break;
-    default:
-        if ( !IS_PRIV(current->domain) )
-            return -EPERM;
-        break;
-    }
+    ret = xsm_domctl(d, op->cmd);
+    if ( ret )
+        goto domctl_out_unlock;
 
     if ( !domctl_lock_acquire() )
     {
@@ -857,17 +839,13 @@ long do_domctl(XEN_GUEST_HANDLE(xen_domctl_t) u_domctl)
 
     case XEN_DOMCTL_subscribe:
     {
-        ret = xsm_domctl(d, op->cmd);
-        if ( !ret )
-            d->suspend_evtchn = op->u.subscribe.port;
+        d->suspend_evtchn = op->u.subscribe.port;
     }
     break;
 
     case XEN_DOMCTL_disable_migrate:
     {
-        ret = xsm_domctl(d, op->cmd);
-        if ( !ret )
-            d->disable_migrate = op->u.disable_migrate.disable;
+        d->disable_migrate = op->u.disable_migrate.disable;
     }
     break;
 
diff --git a/xen/include/xsm/dummy.h b/xen/include/xsm/dummy.h
index 3f0a6d8..6aa6aea 100644
--- a/xen/include/xsm/dummy.h
+++ b/xen/include/xsm/dummy.h
@@ -64,8 +64,6 @@ static XSM_DEFAULT(int, scheduler) (struct domain *d)
 
 static XSM_DEFAULT(int, getdomaininfo) (struct domain *d)
 {
-    if ( !IS_PRIV(current->domain) )
-        return -EPERM;
     return 0;
 }
 
@@ -91,6 +89,20 @@ static XSM_DEFAULT(int, set_target) (struct domain *d, struct domain *e)
 
 static XSM_DEFAULT(int, domctl)(struct domain *d, int cmd)
 {
+    switch ( cmd )
+    {
+    case XEN_DOMCTL_ioport_mapping:
+    case XEN_DOMCTL_memory_mapping:
+    case XEN_DOMCTL_bind_pt_irq:
+    case XEN_DOMCTL_unbind_pt_irq: {
+        if ( !IS_PRIV_FOR(current->domain, d) )
+            return -EPERM;
+        break;
+    }
+    default:
+        if ( !IS_PRIV(current->domain) )
+            return -EPERM;
+    }
     return 0;
 }
 
diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
index 1cbf2f2..6d03189 100644
--- a/xen/xsm/flask/hooks.c
+++ b/xen/xsm/flask/hooks.c
@@ -589,7 +589,90 @@ static int flask_set_target(struct domain *d, struct domain *e)
 
 static int flask_domctl(struct domain *d, int cmd)
 {
-    return domain_has_perm(current->domain, d, SECCLASS_DOMAIN, DOMAIN__SET_MISC_INFO);
+    switch ( cmd )
+    {
+    /* These have individual XSM hooks (common/domctl.c) */
+    case XEN_DOMCTL_createdomain:
+    case XEN_DOMCTL_destroydomain:
+    case XEN_DOMCTL_pausedomain:
+    case XEN_DOMCTL_unpausedomain:
+    case XEN_DOMCTL_getdomaininfo:
+    case XEN_DOMCTL_setvcpuaffinity:
+    case XEN_DOMCTL_max_mem:
+    case XEN_DOMCTL_setvcpucontext:
+    case XEN_DOMCTL_getvcpucontext:
+    case XEN_DOMCTL_getvcpuinfo:
+    case XEN_DOMCTL_max_vcpus:
+    case XEN_DOMCTL_scheduler_op:
+    case XEN_DOMCTL_setdomainhandle:
+    case XEN_DOMCTL_setdebugging:
+    case XEN_DOMCTL_irq_permission:
+    case XEN_DOMCTL_iomem_permission:
+    case XEN_DOMCTL_settimeoffset:
+    case XEN_DOMCTL_getvcpuaffinity:
+    case XEN_DOMCTL_resumedomain:
+    case XEN_DOMCTL_set_target:
+    case XEN_DOMCTL_set_virq_handler:
+#ifdef CONFIG_X86
+    /* These have individual XSM hooks (arch/x86/domctl.c) */
+    case XEN_DOMCTL_shadow_op:
+    case XEN_DOMCTL_ioport_permission:
+    case XEN_DOMCTL_getpageframeinfo:
+    case XEN_DOMCTL_getpageframeinfo2:
+    case XEN_DOMCTL_getpageframeinfo3:
+    case XEN_DOMCTL_getmemlist:
+    case XEN_DOMCTL_hypercall_init:
+    case XEN_DOMCTL_sethvmcontext:
+    case XEN_DOMCTL_gethvmcontext:
+    case XEN_DOMCTL_gethvmcontext_partial:
+    case XEN_DOMCTL_set_address_size:
+    case XEN_DOMCTL_get_address_size:
+    case XEN_DOMCTL_set_machine_address_size:
+    case XEN_DOMCTL_get_machine_address_size:
+    case XEN_DOMCTL_sendtrigger:
+    case XEN_DOMCTL_bind_pt_irq:
+    case XEN_DOMCTL_unbind_pt_irq:
+    case XEN_DOMCTL_memory_mapping:
+    case XEN_DOMCTL_ioport_mapping:
+    case XEN_DOMCTL_pin_mem_cacheattr:
+    case XEN_DOMCTL_set_ext_vcpucontext:
+    case XEN_DOMCTL_get_ext_vcpucontext:
+    case XEN_DOMCTL_setvcpuextstate:
+    case XEN_DOMCTL_getvcpuextstate:
+    case XEN_DOMCTL_mem_event_op:
+    case XEN_DOMCTL_mem_sharing_op:
+    case XEN_DOMCTL_set_access_required:
+    /* These have individual XSM hooks (drivers/passthrough/iommu.c) */
+    case XEN_DOMCTL_get_device_group:
+    case XEN_DOMCTL_test_assign_device:
+    case XEN_DOMCTL_assign_device:
+    case XEN_DOMCTL_deassign_device:
+#endif
+        return 0;
+
+    case XEN_DOMCTL_subscribe:
+    case XEN_DOMCTL_disable_migrate:
+        return domain_has_perm(current->domain, d, SECCLASS_DOMAIN,
+                               DOMAIN__SET_MISC_INFO);
+
+    case XEN_DOMCTL_set_cpuid:
+    case XEN_DOMCTL_suppress_spurious_page_faults:
+    case XEN_DOMCTL_debug_op:
+    case XEN_DOMCTL_gettscinfo:
+    case XEN_DOMCTL_settscinfo:
+    case XEN_DOMCTL_audit_p2m:
+    case XEN_DOMCTL_gdbsx_guestmemio:
+    case XEN_DOMCTL_gdbsx_pausevcpu:
+    case XEN_DOMCTL_gdbsx_unpausevcpu:
+    case XEN_DOMCTL_gdbsx_domstatus:
+        /* TODO add per-subfunction hooks */
+        if ( !IS_PRIV(current->domain) )
+            return -EPERM;
+        return 0;
+    default:
+        printk("flask_domctl: Unknown op %d\n", cmd);
+        return -EPERM;
+    }
 }
 
 static int flask_set_virq_handler(struct domain *d, uint32_t virq)
-- 
1.7.11.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 12 16:00:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Sep 2012 16:00:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TBpM6-0005OT-BF; Wed, 12 Sep 2012 15:59:58 +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 1TBpM4-0005N3-HO
	for xen-devel@lists.xen.org; Wed, 12 Sep 2012 15:59:56 +0000
Received: from [85.158.138.51:6820] by server-8.bemta-3.messagelabs.com id
	43/53-24700-B71B0505; Wed, 12 Sep 2012 15:59:55 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-6.tower-174.messagelabs.com!1347465594!22162533!1
X-Originating-IP: [63.239.67.9]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8374 invoked from network); 12 Sep 2012 15:59:54 -0000
Received: from emvm-gh1-uea08.nsa.gov (HELO nsa.gov) (63.239.67.9)
	by server-6.tower-174.messagelabs.com with SMTP;
	12 Sep 2012 15:59:54 -0000
X-TM-IMSS-Message-ID: <39e15d9d00102346@nsa.gov>
Received: from tarius.tycho.ncsc.mil ([144.51.3.1]) by nsa.gov ([63.239.67.9])
	with ESMTP (TREND IMSS SMTP Service 7.1) id 39e15d9d00102346 ;
	Wed, 12 Sep 2012 11:59:44 -0400
Received: from moss-nexus.epoch.ncsc.mil (moss-nexus [144.51.25.48])
	by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id q8CFxoOH006669; 
	Wed, 12 Sep 2012 11:59:52 -0400
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xen.org
Date: Wed, 12 Sep 2012 11:59:31 -0400
Message-Id: <1347465586-20009-8-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.11.4
In-Reply-To: <1347465586-20009-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1347465586-20009-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: dgdegra@tycho.nsa.gov, Keir Fraser <keir@xen.org>,
	Jan Beulich <jbeulich@suse.com>
Subject: [Xen-devel] [PATCH 07/22] arch/x86: add distinct XSM hooks for
	map/unmap
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 xsm_iomem_permission and xsm_ioport_permission hooks are intended to
be called by the domain builder, while the calls in arch/x86/domctl.c
which control mapping are also performed by the device model. Because of
this, they should not use the same XSM hooks.

This also adds a missing XSM hook in the unbind IRQ domctl.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Cc: Keir Fraser <keir@xen.org>
Cc: Jan Beulich <jbeulich@suse.com>
---
 xen/arch/x86/domctl.c  |  8 ++++++--
 xen/arch/x86/physdev.c |  2 +-
 xen/include/xsm/xsm.h  | 25 ++++++++++++++++++++++---
 xen/xsm/dummy.c        | 20 +++++++++++++++++++-
 xen/xsm/flask/hooks.c  | 42 ++++++++++++++++++++----------------------
 5 files changed, 68 insertions(+), 29 deletions(-)

diff --git a/xen/arch/x86/domctl.c b/xen/arch/x86/domctl.c
index 7a89040..9eebd3b 100644
--- a/xen/arch/x86/domctl.c
+++ b/xen/arch/x86/domctl.c
@@ -805,6 +805,10 @@ long arch_do_domctl(
              !irq_access_permitted(current->domain, bind->machine_irq) )
             goto unbind_out;
 
+        ret = xsm_unbind_pt_irq(d, bind);
+        if ( ret )
+            goto unbind_out;
+
         if ( iommu_enabled )
         {
             spin_lock(&pcidevs_lock);
@@ -842,7 +846,7 @@ long arch_do_domctl(
         if ( unlikely((d = rcu_lock_domain_by_id(domctl->domain)) == NULL) )
             break;
 
-        ret = xsm_iomem_permission(d, mfn, mfn + nr_mfns - 1, add);
+        ret = xsm_iomem_mapping(d, mfn, mfn + nr_mfns - 1, add);
         if ( ret ) {
             rcu_unlock_domain(d);
             break;
@@ -904,7 +908,7 @@ long arch_do_domctl(
         if ( unlikely((d = rcu_lock_domain_by_id(domctl->domain)) == NULL) )
             break;
 
-        ret = xsm_ioport_permission(d, fmp, fmp + np - 1, add);
+        ret = xsm_ioport_mapping(d, fmp, fmp + np - 1, add);
         if ( ret ) {
             rcu_unlock_domain(d);
             break;
diff --git a/xen/arch/x86/physdev.c b/xen/arch/x86/physdev.c
index 984c813..13b85da 100644
--- a/xen/arch/x86/physdev.c
+++ b/xen/arch/x86/physdev.c
@@ -242,7 +242,7 @@ int physdev_unmap_pirq(domid_t domid, int pirq)
     if ( !IS_PRIV_FOR(current->domain, d) )
         goto free_domain;
 
-    ret = xsm_irq_permission(d, domain_pirq_to_irq(d, pirq), 0);
+    ret = xsm_unmap_domain_pirq(d, domain_pirq_to_irq(d, pirq));
     if ( ret )
         goto free_domain;
 
diff --git a/xen/include/xsm/xsm.h b/xen/include/xsm/xsm.h
index 593cdbd..cbbe673 100644
--- a/xen/include/xsm/xsm.h
+++ b/xen/include/xsm/xsm.h
@@ -117,8 +117,10 @@ struct xsm_operations {
 
     char *(*show_irq_sid) (int irq);
     int (*map_domain_pirq) (struct domain *d, int irq, void *data);
+    int (*unmap_domain_pirq) (struct domain *d, int irq);
     int (*irq_permission) (struct domain *d, int pirq, uint8_t allow);
     int (*iomem_permission) (struct domain *d, uint64_t s, uint64_t e, uint8_t allow);
+    int (*iomem_mapping) (struct domain *d, uint64_t s, uint64_t e, uint8_t allow);
     int (*pci_config_permission) (struct domain *d, uint32_t machine_bdf, uint16_t start, uint16_t end, uint8_t access);
 
     int (*get_device_group) (uint32_t machine_bdf);
@@ -176,11 +178,12 @@ struct xsm_operations {
     int (*add_to_physmap) (struct domain *d1, struct domain *d2);
     int (*sendtrigger) (struct domain *d);
     int (*bind_pt_irq) (struct domain *d, struct xen_domctl_bind_pt_irq *bind);
-    int (*unbind_pt_irq) (struct domain *d);
+    int (*unbind_pt_irq) (struct domain *d, struct xen_domctl_bind_pt_irq *bind);
     int (*pin_mem_cacheattr) (struct domain *d);
     int (*ext_vcpucontext) (struct domain *d, uint32_t cmd);
     int (*vcpuextstate) (struct domain *d, uint32_t cmd);
     int (*ioport_permission) (struct domain *d, uint32_t s, uint32_t e, uint8_t allow);
+    int (*ioport_mapping) (struct domain *d, uint32_t s, uint32_t e, uint8_t allow);
 #endif
 };
 
@@ -495,6 +498,11 @@ static inline int xsm_map_domain_pirq (struct domain *d, int irq, void *data)
     return xsm_call(map_domain_pirq(d, irq, data));
 }
 
+static inline int xsm_unmap_domain_pirq (struct domain *d, int irq)
+{
+    return xsm_call(unmap_domain_pirq(d, irq));
+}
+
 static inline int xsm_irq_permission (struct domain *d, int pirq, uint8_t allow)
 {
     return xsm_call(irq_permission(d, pirq, allow));
@@ -505,6 +513,11 @@ static inline int xsm_iomem_permission (struct domain *d, uint64_t s, uint64_t e
     return xsm_call(iomem_permission(d, s, e, allow));
 }
 
+static inline int xsm_iomem_mapping (struct domain *d, uint64_t s, uint64_t e, uint8_t allow)
+{
+    return xsm_call(iomem_mapping(d, s, e, allow));
+}
+
 static inline int xsm_pci_config_permission (struct domain *d, uint32_t machine_bdf, uint16_t start, uint16_t end, uint8_t access)
 {
     return xsm_call(pci_config_permission(d, machine_bdf, start, end, access));
@@ -781,9 +794,10 @@ static inline int xsm_bind_pt_irq(struct domain *d,
     return xsm_call(bind_pt_irq(d, bind));
 }
 
-static inline int xsm_unbind_pt_irq(struct domain *d)
+static inline int xsm_unbind_pt_irq(struct domain *d,
+                                                struct xen_domctl_bind_pt_irq *bind)
 {
-    return xsm_call(unbind_pt_irq(d));
+    return xsm_call(unbind_pt_irq(d, bind));
 }
 
 static inline int xsm_pin_mem_cacheattr(struct domain *d)
@@ -804,6 +818,11 @@ static inline int xsm_ioport_permission (struct domain *d, uint32_t s, uint32_t
 {
     return xsm_call(ioport_permission(d, s, e, allow));
 }
+
+static inline int xsm_ioport_mapping (struct domain *d, uint32_t s, uint32_t e, uint8_t allow)
+{
+    return xsm_call(ioport_mapping(d, s, e, allow));
+}
 #endif /* CONFIG_X86 */
 
 extern struct xsm_operations dummy_xsm_ops;
diff --git a/xen/xsm/dummy.c b/xen/xsm/dummy.c
index 4836fc0..a5dbfe7 100644
--- a/xen/xsm/dummy.c
+++ b/xen/xsm/dummy.c
@@ -395,6 +395,11 @@ static int dummy_map_domain_pirq (struct domain *d, int irq, void *data)
     return 0;
 }
 
+static int dummy_unmap_domain_pirq (struct domain *d, int irq)
+{
+    return 0;
+}
+
 static int dummy_irq_permission (struct domain *d, int pirq, uint8_t allow)
 {
     return 0;
@@ -405,6 +410,11 @@ static int dummy_iomem_permission (struct domain *d, uint64_t s, uint64_t e, uin
     return 0;
 }
 
+static int dummy_iomem_mapping (struct domain *d, uint64_t s, uint64_t e, uint8_t allow)
+{
+    return 0;
+}
+
 static int dummy_pci_config_permission (struct domain *d, uint32_t machine_bdf,
                                         uint16_t start, uint16_t end,
                                         uint8_t access)
@@ -585,7 +595,7 @@ static int dummy_bind_pt_irq (struct domain *d, struct xen_domctl_bind_pt_irq *b
     return 0;
 }
 
-static int dummy_unbind_pt_irq (struct domain *d)
+static int dummy_unbind_pt_irq (struct domain *d, struct xen_domctl_bind_pt_irq *bind)
 {
     return 0;
 }
@@ -609,6 +619,11 @@ static int dummy_ioport_permission (struct domain *d, uint32_t s, uint32_t e, ui
 {
     return 0;
 }
+
+static int dummy_ioport_mapping (struct domain *d, uint32_t s, uint32_t e, uint8_t allow)
+{
+    return 0;
+}
 #endif
 
 struct xsm_operations dummy_xsm_ops;
@@ -693,8 +708,10 @@ void xsm_fixup_ops (struct xsm_operations *ops)
 
     set_to_dummy_if_null(ops, show_irq_sid);
     set_to_dummy_if_null(ops, map_domain_pirq);
+    set_to_dummy_if_null(ops, unmap_domain_pirq);
     set_to_dummy_if_null(ops, irq_permission);
     set_to_dummy_if_null(ops, iomem_permission);
+    set_to_dummy_if_null(ops, iomem_mapping);
     set_to_dummy_if_null(ops, pci_config_permission);
 
     set_to_dummy_if_null(ops, get_device_group);
@@ -757,5 +774,6 @@ void xsm_fixup_ops (struct xsm_operations *ops)
     set_to_dummy_if_null(ops, ext_vcpucontext);
     set_to_dummy_if_null(ops, vcpuextstate);
     set_to_dummy_if_null(ops, ioport_permission);
+    set_to_dummy_if_null(ops, ioport_mapping);
 #endif
 }
diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
index 88fef9c..74c9271 100644
--- a/xen/xsm/flask/hooks.c
+++ b/xen/xsm/flask/hooks.c
@@ -721,43 +721,40 @@ static int flask_map_domain_pirq (struct domain *d, int irq, void *data)
     return rc;
 }
 
-static int flask_irq_permission (struct domain *d, int irq, uint8_t access)
+static int flask_unmap_domain_pirq (struct domain *d, int irq)
 {
-    u32 perm;
-    u32 rsid;
+    u32 sid;
     int rc = -EPERM;
 
-    struct domain_security_struct *ssec, *tsec;
+    struct domain_security_struct *ssec;
     struct avc_audit_data ad;
 
-    rc = domain_has_perm(current->domain, d, SECCLASS_RESOURCE,
-                         resource_to_perm(access));
-
+    rc = domain_has_perm(current->domain, d, SECCLASS_RESOURCE, RESOURCE__REMOVE);
     if ( rc )
         return rc;
 
-    if ( access )
-        perm = RESOURCE__ADD_IRQ;
-    else
-        perm = RESOURCE__REMOVE_IRQ;
-
     ssec = current->domain->ssid;
-    tsec = d->ssid;
 
-    rc = get_irq_sid(irq, &rsid, &ad);
-    if ( rc )
-        return rc;
-
-    rc = avc_has_perm(ssec->sid, rsid, SECCLASS_RESOURCE, perm, &ad);
+    if ( irq >= nr_irqs_gsi ) {
+        /* TODO support for MSI here */
+        return 0;
+    } else {
+        rc = get_irq_sid(irq, &sid, &ad);
+    }
     if ( rc )
         return rc;
 
-    if ( access )
-        rc = avc_has_perm(tsec->sid, rsid, SECCLASS_RESOURCE, 
-                            RESOURCE__USE, &ad);
+    rc = avc_has_perm(ssec->sid, sid, SECCLASS_RESOURCE, RESOURCE__REMOVE_IRQ, &ad);
     return rc;
 }
 
+static int flask_irq_permission (struct domain *d, int pirq, uint8_t access)
+{
+    /* the PIRQ number is not useful; real IRQ is checked during mapping */
+    return domain_has_perm(current->domain, d, SECCLASS_RESOURCE,
+                           resource_to_perm(access));
+}
+
 struct iomem_has_perm_data {
     struct domain_security_struct *ssec, *tsec;
     u32 perm;
@@ -1413,7 +1410,7 @@ static int flask_bind_pt_irq (struct domain *d, struct xen_domctl_bind_pt_irq *b
     return avc_has_perm(tsec->sid, rsid, SECCLASS_RESOURCE, RESOURCE__USE, &ad);
 }
 
-static int flask_unbind_pt_irq (struct domain *d)
+static int flask_unbind_pt_irq (struct domain *d, struct xen_domctl_bind_pt_irq *bind)
 {
     return domain_has_perm(current->domain, d, SECCLASS_RESOURCE, RESOURCE__REMOVE);
 }
@@ -1533,6 +1530,7 @@ static struct xsm_operations flask_ops = {
     .show_irq_sid = flask_show_irq_sid,
 
     .map_domain_pirq = flask_map_domain_pirq,
+    .unmap_domain_pirq = flask_unmap_domain_pirq,
     .irq_permission = flask_irq_permission,
     .iomem_permission = flask_iomem_permission,
     .pci_config_permission = flask_pci_config_permission,
-- 
1.7.11.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 12 16:00:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Sep 2012 16:00:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TBpM7-0005Pa-Qf; Wed, 12 Sep 2012 15:59:59 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1TBpM6-0005Me-JP
	for xen-devel@lists.xen.org; Wed, 12 Sep 2012 15:59:58 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-16.tower-27.messagelabs.com!1347465591!9333729!1
X-Originating-IP: [63.239.67.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6656 invoked from network); 12 Sep 2012 15:59:52 -0000
Received: from emvm-gh1-uea09.nsa.gov (HELO nsa.gov) (63.239.67.10)
	by server-16.tower-27.messagelabs.com with SMTP;
	12 Sep 2012 15:59:52 -0000
X-TM-IMSS-Message-ID: <39e11113001083cb@nsa.gov>
Received: from tarius.tycho.ncsc.mil ([144.51.3.1]) by nsa.gov
	([63.239.67.10]) with ESMTP (TREND IMSS SMTP Service 7.1) id
	39e11113001083cb ; Wed, 12 Sep 2012 12:01:58 -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 q8CFxoOA006669; 
	Wed, 12 Sep 2012 11:59:50 -0400
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xen.org
Date: Wed, 12 Sep 2012 11:59:24 -0400
Message-Id: <1347465586-20009-1-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.11.4
Cc: dgdegra@tycho.nsa.gov
Subject: [Xen-devel] [PATCH v3] Merge IS_PRIV checks into XSM hooks
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 v2:
 * Added overall hooks for domctl, sysctl, and platform_hypercall so
   that new sub-operations are protected by IS_PRIV checks
 * Reorganized the IS_PRIV additions to dummy.h so they are added in the
   same patch that removes the IS_PRIV they are replacing
 * Reworked hooks in the MM hotpath to increase efficiency
 * Dropped some unneeded XSM hook additions due to do_domctl hook
 * Dropped the rcu_lock*target_domain_by_id function removal patch
 * Restore IS_PRIV check in PHYSDEVOP_alloc_irq_vector
 * Use the existing hook function structure for tmem

Overall, this series should not change the behavior of Xen when XSM is
not enabled; however, in some cases, the exact errors that are returned
will be different because security checks have been moved below validity
checks.

Background:

The Xen hypervisor has two basic access control function calls: IS_PRIV
and the xsm_* functions. Most privileged operations currently require
that both checks succeed, and many times the checks are at different
locations in the code.

When performing dom0 disaggregation, many of the functions normally
protected with IS_PRIV are handled by domains other than dom0. This
requires either making all such disaggregated domains privileged, or
allowing certain operations to be performed without an IS_PRIV check.
Because the privileged bit also short-circuits the IS_PRIV_FOR check,
and some IS_PRIV calls do not currently have an accompanying XSM call,
this series implements the second option.

Once applied, most IS_PRIV checks are isolated in the newly introduced
xen/include/xsm/dummy.h header. The remaining checks cover a few areas
that that have some reason to remain because they involve hardware
access or workarounds:

1. Overriding the IRQ and IO memory access checks (arch/x86/domctl.c).
   These overrides should not be needed, as dom0 should have access
   without needing the override.
2. Allow MAP_PIRQ_TYPE_GSI to ignore domain_pirq_to_irq negative return
3. The hack for device model framebuffers in get_page_from_l1e
4. Installing maps of non-owned pages in shadow_get_page_from_l1e
5. PCI configuration space (arch/x86/traps.c). Allowing a PV Linux domU
   to access the PCI configuration space is a good way to crash the
   system as it reconfigures PCI devices during boot, so this needs to
   remain to get a working system when FLASK is in permissive mode.
6. Various MSR accesses (arch/x86/traps.c)

The ARM architecture is not touched at all in these patches; however,
none of the changes should affect ARM. XSM hooks will need to be added
for the arch-specific controls in order for FLASK to be useful on ARM,
but those changes are outside the scope of this series.

Miscellaneous updates to FLASK:
    [PATCH 01/22] xsm/flask: remove inherited class attributes
    [PATCH 02/22] xsm/flask: remove unneeded create_sid field
    [PATCH 04/22] xsm/flask: add domain relabel support
    [PATCH 05/22] libxl: introduce XSM relabel on build
    [PATCH 06/22] flask/policy: Add domain relabel example
    [PATCH 08/22] xsm/flask: Add checks on the domain performing the

Preparatory new functions/hooks:
    [PATCH 03/22] xen: Add versions of rcu_lock_*_domain without IS_PRIV
    [PATCH 07/22] arch/x86: add distinct XSM hooks for map/unmap
    [PATCH 13/22] xen: lock target domain in do_domctl common code

IS_PRIV Refactoring:
    [PATCH 09/22] xsm: Use the dummy XSM module if XSM is disabled
    [PATCH 10/22] xen: use XSM instead of IS_PRIV where duplicated
    [PATCH 11/22] xen: avoid calling rcu_lock_*target_domain when an XSM
    [PATCH 12/22] arch/x86: convert platform_hypercall to use XSM
    [PATCH 14/22] xen: convert do_domctl to use XSM
    [PATCH 15/22] xen: convert do_sysctl to use XSM

Additional new/updated hooks:
    [PATCH 16/22] xsm/flask: add missing hooks
    [PATCH 17/22] xsm/flask: add distinct SIDs for self/target access
    [PATCH 18/22] arch/x86: Add missing mem_sharing XSM hooks
    [PATCH 19/22] arch/x86: check remote MMIO remap permissions
    [PATCH 20/22] arch/x86: use XSM hooks for get_pg_owner access checks
    [PATCH 21/22] xen: Add XSM hook for XENMEM_exchange
    [PATCH 22/22] tmem: add XSM hooks

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 12 16:00:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Sep 2012 16:00:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TBpMC-0005ix-W6; Wed, 12 Sep 2012 16:00:04 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1TBpMA-0005Nw-TY
	for xen-devel@lists.xen.org; Wed, 12 Sep 2012 16:00:03 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-12.tower-27.messagelabs.com!1347465595!10765552!1
X-Originating-IP: [63.239.67.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4654 invoked from network); 12 Sep 2012 15:59:55 -0000
Received: from emvm-gh1-uea09.nsa.gov (HELO nsa.gov) (63.239.67.10)
	by server-12.tower-27.messagelabs.com with SMTP;
	12 Sep 2012 15:59:55 -0000
X-TM-IMSS-Message-ID: <39e11f75001083d8@nsa.gov>
Received: from tarius.tycho.ncsc.mil ([144.51.3.1]) by nsa.gov
	([63.239.67.10]) with ESMTP (TREND IMSS SMTP Service 7.1) id
	39e11f75001083d8 ; Wed, 12 Sep 2012 12:02:01 -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 q8CFxoOM006669; 
	Wed, 12 Sep 2012 11:59:53 -0400
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xen.org
Date: Wed, 12 Sep 2012 11:59:36 -0400
Message-Id: <1347465586-20009-13-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.11.4
In-Reply-To: <1347465586-20009-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1347465586-20009-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: dgdegra@tycho.nsa.gov, Keir Fraser <keir@xen.org>,
	Jan Beulich <jbeulich@suse.com>
Subject: [Xen-devel] [PATCH 12/22] arch/x86: convert platform_hypercall to
	use 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

The newly introduced xsm_platform_op hook addresses new sub-ops, while
most ops already have their own XSM hooks.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Cc: Keir Fraser <keir@xen.org>
Cc: Jan Beulich <jbeulich@suse.com>
---
 xen/arch/x86/platform_hypercall.c | 11 ++++++++---
 xen/include/xsm/dummy.h           |  7 +++++++
 xen/include/xsm/xsm.h             |  6 ++++++
 xen/xsm/dummy.c                   |  1 +
 xen/xsm/flask/hooks.c             | 33 +++++++++++++++++++++++++++++++++
 5 files changed, 55 insertions(+), 3 deletions(-)

diff --git a/xen/arch/x86/platform_hypercall.c b/xen/arch/x86/platform_hypercall.c
index 073a2ea..50b5f1d 100644
--- a/xen/arch/x86/platform_hypercall.c
+++ b/xen/arch/x86/platform_hypercall.c
@@ -66,15 +66,16 @@ ret_t do_platform_op(XEN_GUEST_HANDLE(xen_platform_op_t) u_xenpf_op)
     ret_t ret = 0;
     struct xen_platform_op curop, *op = &curop;
 
-    if ( !IS_PRIV(current->domain) )
-        return -EPERM;
-
     if ( copy_from_guest(op, u_xenpf_op, 1) )
         return -EFAULT;
 
     if ( op->interface_version != XENPF_INTERFACE_VERSION )
         return -EACCES;
 
+    ret = xsm_platform_op(op->cmd);
+    if ( ret )
+        return ret;
+
     /*
      * Trylock here avoids deadlock with an existing platform critical section
      * which might (for some current or future reason) want to synchronise
@@ -507,6 +508,10 @@ ret_t do_platform_op(XEN_GUEST_HANDLE(xen_platform_op_t) u_xenpf_op)
     {
         struct xenpf_pcpu_version *ver = &op->u.pcpu_version;
 
+        ret = xsm_getcpuinfo();
+        if ( ret )
+            break;
+
         if ( !get_cpu_maps() )
         {
             ret = -EBUSY;
diff --git a/xen/include/xsm/dummy.h b/xen/include/xsm/dummy.h
index 31f862d..3f0a6d8 100644
--- a/xen/include/xsm/dummy.h
+++ b/xen/include/xsm/dummy.h
@@ -574,6 +574,13 @@ static XSM_DEFAULT(int, platform_quirk) (uint32_t quirk)
     return 0;
 }
 
+static XSM_DEFAULT(int, platform_op) (uint32_t op)
+{
+    if ( !IS_PRIV(current->domain) )
+        return -EPERM;
+    return 0;
+}
+
 static XSM_DEFAULT(int, firmware_info) (void)
 {
     return 0;
diff --git a/xen/include/xsm/xsm.h b/xen/include/xsm/xsm.h
index ba5a89e..171acb2 100644
--- a/xen/include/xsm/xsm.h
+++ b/xen/include/xsm/xsm.h
@@ -158,6 +158,7 @@ struct xsm_operations {
     int (*microcode) (void);
     int (*physinfo) (void);
     int (*platform_quirk) (uint32_t);
+    int (*platform_op) (uint32_t cmd);
     int (*firmware_info) (void);
     int (*efi_call) (void);
     int (*acpi_sleep) (void);
@@ -696,6 +697,11 @@ static inline int xsm_platform_quirk (uint32_t quirk)
     return xsm_ops->platform_quirk(quirk);
 }
 
+static inline int xsm_platform_op (uint32_t op)
+{
+    return xsm_ops->platform_op(op);
+}
+
 static inline int xsm_firmware_info (void)
 {
     return xsm_ops->firmware_info();
diff --git a/xen/xsm/dummy.c b/xen/xsm/dummy.c
index af532b8..7f9c753 100644
--- a/xen/xsm/dummy.c
+++ b/xen/xsm/dummy.c
@@ -142,6 +142,7 @@ void xsm_fixup_ops (struct xsm_operations *ops)
     set_to_dummy_if_null(ops, microcode);
     set_to_dummy_if_null(ops, physinfo);
     set_to_dummy_if_null(ops, platform_quirk);
+    set_to_dummy_if_null(ops, platform_op);
     set_to_dummy_if_null(ops, firmware_info);
     set_to_dummy_if_null(ops, efi_call);
     set_to_dummy_if_null(ops, acpi_sleep);
diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
index 10c2163..1cbf2f2 100644
--- a/xen/xsm/flask/hooks.c
+++ b/xen/xsm/flask/hooks.c
@@ -1207,6 +1207,38 @@ static int flask_platform_quirk(uint32_t quirk)
                         XEN__QUIRK, NULL);
 }
 
+static int flask_platform_op(uint32_t op)
+{
+    switch ( op )
+    {
+    case XENPF_settime:
+    case XENPF_add_memtype:
+    case XENPF_del_memtype:
+    case XENPF_read_memtype:
+    case XENPF_microcode_update:
+    case XENPF_platform_quirk:
+    case XENPF_firmware_info:
+    case XENPF_efi_runtime_call:
+    case XENPF_enter_acpi_sleep:
+    case XENPF_change_freq:
+    case XENPF_getidletime:
+    case XENPF_set_processor_pminfo:
+    case XENPF_get_cpuinfo:
+    case XENPF_get_cpu_version:
+    case XENPF_cpu_online:
+    case XENPF_cpu_offline:
+    case XENPF_cpu_hotadd:
+    case XENPF_mem_hotadd:
+        /* These operations have their own XSM hooks */
+        return 0;
+    case XENPF_core_parking:
+        return domain_has_xen(current->domain, XEN__PM_OP);
+    default:
+        printk("flask_platform_op: Unknown op %d\n", op);
+        return -EPERM;
+    }
+}
+
 static int flask_firmware_info(void)
 {
     return domain_has_xen(current->domain, XEN__FIRMWARE);
@@ -1577,6 +1609,7 @@ static struct xsm_operations flask_ops = {
     .microcode = flask_microcode,
     .physinfo = flask_physinfo,
     .platform_quirk = flask_platform_quirk,
+    .platform_op = flask_platform_op,
     .firmware_info = flask_firmware_info,
     .efi_call = flask_efi_call,
     .acpi_sleep = flask_acpi_sleep,
-- 
1.7.11.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 12 16:00:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Sep 2012 16:00:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TBpM4-0005NW-Vy; Wed, 12 Sep 2012 15:59:56 +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 1TBpM3-0005Mm-Du
	for xen-devel@lists.xen.org; Wed, 12 Sep 2012 15:59:55 +0000
Received: from [85.158.138.51:6737] by server-7.bemta-3.messagelabs.com id
	37/07-32000-A71B0505; Wed, 12 Sep 2012 15:59:54 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-14.tower-174.messagelabs.com!1347465593!23852944!1
X-Originating-IP: [63.239.67.9]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9702 invoked from network); 12 Sep 2012 15:59:53 -0000
Received: from emvm-gh1-uea08.nsa.gov (HELO nsa.gov) (63.239.67.9)
	by server-14.tower-174.messagelabs.com with SMTP;
	12 Sep 2012 15:59:53 -0000
X-TM-IMSS-Message-ID: <39e15a9100102341@nsa.gov>
Received: from tarius.tycho.ncsc.mil ([144.51.3.1]) by nsa.gov ([63.239.67.9])
	with ESMTP (TREND IMSS SMTP Service 7.1) id 39e15a9100102341 ;
	Wed, 12 Sep 2012 11:59:43 -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 q8CFxoOE006669; 
	Wed, 12 Sep 2012 11:59:51 -0400
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xen.org
Date: Wed, 12 Sep 2012 11:59:28 -0400
Message-Id: <1347465586-20009-5-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.11.4
In-Reply-To: <1347465586-20009-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1347465586-20009-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: dgdegra@tycho.nsa.gov
Subject: [Xen-devel] [PATCH 04/22] xsm/flask: add domain relabel 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

This adds the ability to change a domain's XSM label after creation.
The new label will be used for all future access checks; however,
existing event channels and memory mappings will remain valid even if
their creation would be denied by the new label.

With appropriate security policy and hooks in the domain builder, this
can be used to create domains that the domain builder does not have
access to after building. It can also be used to allow a domain to drop
privileges - for example, prior to launching a user-supplied kernel
loaded by a pv-grub stubdom.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 tools/flask/policy/policy/flask/access_vectors   |  7 ++++
 tools/flask/policy/policy/flask/security_classes |  1 +
 tools/flask/policy/policy/modules/xen/xen.te     |  2 +-
 xen/include/public/xsm/flask_op.h                |  8 ++++
 xen/xsm/flask/flask_op.c                         | 49 ++++++++++++++++++++++++
 xen/xsm/flask/include/av_perm_to_string.h        |  3 ++
 xen/xsm/flask/include/av_permissions.h           |  4 ++
 xen/xsm/flask/include/class_to_string.h          |  1 +
 xen/xsm/flask/include/flask.h                    | 15 ++++----
 9 files changed, 82 insertions(+), 8 deletions(-)

diff --git a/tools/flask/policy/policy/flask/access_vectors b/tools/flask/policy/policy/flask/access_vectors
index a884312..c7e29ab 100644
--- a/tools/flask/policy/policy/flask/access_vectors
+++ b/tools/flask/policy/policy/flask/access_vectors
@@ -73,6 +73,13 @@ class domain
 	set_virq_handler
 }
 
+class domain2
+{
+	relabelfrom
+	relabelto
+	relabelself
+}
+
 class hvm
 {
     sethvmc
diff --git a/tools/flask/policy/policy/flask/security_classes b/tools/flask/policy/policy/flask/security_classes
index 2ca35d2..ef134a7 100644
--- a/tools/flask/policy/policy/flask/security_classes
+++ b/tools/flask/policy/policy/flask/security_classes
@@ -9,6 +9,7 @@
 
 class xen
 class domain
+class domain2
 class hvm
 class mmu
 class resource
diff --git a/tools/flask/policy/policy/modules/xen/xen.te b/tools/flask/policy/policy/modules/xen/xen.te
index 9cc5240..9550397 100644
--- a/tools/flask/policy/policy/modules/xen/xen.te
+++ b/tools/flask/policy/policy/modules/xen/xen.te
@@ -169,7 +169,7 @@ delegate_devices(dom0_t, domU_t)
 ################################################################################
 
 # Domains must be declared using domain_type
-neverallow * ~domain_type:domain create;
+neverallow * ~domain_type:domain { create transition };
 
 # Resources must be declared using resource_type
 neverallow * ~resource_type:resource use;
diff --git a/xen/include/public/xsm/flask_op.h b/xen/include/public/xsm/flask_op.h
index 1a251c9..233de81 100644
--- a/xen/include/public/xsm/flask_op.h
+++ b/xen/include/public/xsm/flask_op.h
@@ -142,6 +142,12 @@ struct xen_flask_peersid {
     uint32_t sid;
 };
 
+struct xen_flask_relabel {
+    /* IN */
+    uint32_t domid;
+    uint32_t sid;
+};
+
 struct xen_flask_op {
     uint32_t cmd;
 #define FLASK_LOAD              1
@@ -167,6 +173,7 @@ struct xen_flask_op {
 #define FLASK_ADD_OCONTEXT      21
 #define FLASK_DEL_OCONTEXT      22
 #define FLASK_GET_PEER_SID      23
+#define FLASK_RELABEL_DOMAIN    24
     uint32_t interface_version; /* XEN_FLASK_INTERFACE_VERSION */
     union {
         struct xen_flask_load load;
@@ -185,6 +192,7 @@ struct xen_flask_op {
         /* FLASK_ADD_OCONTEXT, FLASK_DEL_OCONTEXT */
         struct xen_flask_ocontext ocontext;
         struct xen_flask_peersid peersid;
+        struct xen_flask_relabel relabel;
     } u;
 };
 typedef struct xen_flask_op xen_flask_op_t;
diff --git a/xen/xsm/flask/flask_op.c b/xen/xsm/flask/flask_op.c
index bd4db37..9c8dfe7 100644
--- a/xen/xsm/flask/flask_op.c
+++ b/xen/xsm/flask/flask_op.c
@@ -573,6 +573,51 @@ static int flask_get_peer_sid(struct xen_flask_peersid *arg)
     return rv;
 }
 
+static int flask_relabel_domain(struct xen_flask_relabel *arg)
+{
+    int rc;
+    struct domain *d;
+    struct domain_security_struct *csec = current->domain->ssid;
+    struct domain_security_struct *dsec;
+    struct avc_audit_data ad;
+    AVC_AUDIT_DATA_INIT(&ad, NONE);
+
+    d = rcu_lock_domain_by_any_id(arg->domid);
+    if ( d == NULL )
+        return -ESRCH;
+
+    ad.sdom = current->domain;
+    ad.tdom = d;
+    dsec = d->ssid;
+
+    if ( arg->domid == DOMID_SELF )
+    {
+        rc = avc_has_perm(dsec->sid, arg->sid, SECCLASS_DOMAIN2, DOMAIN2__RELABELSELF, &ad);
+        if ( rc )
+            goto out;
+    }
+    else
+    {
+        rc = avc_has_perm(csec->sid, dsec->sid, SECCLASS_DOMAIN2, DOMAIN2__RELABELFROM, &ad);
+        if ( rc )
+            goto out;
+
+        rc = avc_has_perm(csec->sid, arg->sid, SECCLASS_DOMAIN2, DOMAIN2__RELABELTO, &ad);
+        if ( rc )
+            goto out;
+    }
+
+    rc = avc_has_perm(dsec->sid, arg->sid, SECCLASS_DOMAIN, DOMAIN__TRANSITION, &ad);
+    if ( rc )
+        goto out;
+
+    dsec->sid = arg->sid;
+
+ out:
+    rcu_unlock_domain(d);
+    return rc;
+}
+
 long do_flask_op(XEN_GUEST_HANDLE(xsm_op_t) u_flask_op)
 {
     xen_flask_op_t op;
@@ -680,6 +725,10 @@ long do_flask_op(XEN_GUEST_HANDLE(xsm_op_t) u_flask_op)
         rv = flask_get_peer_sid(&op.u.peersid);
         break;
 
+    case FLASK_RELABEL_DOMAIN:
+        rv = flask_relabel_domain(&op.u.relabel);
+        break;
+
     default:
         rv = -ENOSYS;
     }
diff --git a/xen/xsm/flask/include/av_perm_to_string.h b/xen/xsm/flask/include/av_perm_to_string.h
index 17a1c36..e7e2058 100644
--- a/xen/xsm/flask/include/av_perm_to_string.h
+++ b/xen/xsm/flask/include/av_perm_to_string.h
@@ -61,6 +61,9 @@
    S_(SECCLASS_DOMAIN, DOMAIN__SETPODTARGET, "setpodtarget")
    S_(SECCLASS_DOMAIN, DOMAIN__SET_MISC_INFO, "set_misc_info")
    S_(SECCLASS_DOMAIN, DOMAIN__SET_VIRQ_HANDLER, "set_virq_handler")
+   S_(SECCLASS_DOMAIN2, DOMAIN2__RELABELFROM, "relabelfrom")
+   S_(SECCLASS_DOMAIN2, DOMAIN2__RELABELTO, "relabelto")
+   S_(SECCLASS_DOMAIN2, DOMAIN2__RELABELSELF, "relabelself")
    S_(SECCLASS_HVM, HVM__SETHVMC, "sethvmc")
    S_(SECCLASS_HVM, HVM__GETHVMC, "gethvmc")
    S_(SECCLASS_HVM, HVM__SETPARAM, "setparam")
diff --git a/xen/xsm/flask/include/av_permissions.h b/xen/xsm/flask/include/av_permissions.h
index 42eaf81..cb1c5dc 100644
--- a/xen/xsm/flask/include/av_permissions.h
+++ b/xen/xsm/flask/include/av_permissions.h
@@ -63,6 +63,10 @@
 #define DOMAIN__SET_MISC_INFO                     0x40000000UL
 #define DOMAIN__SET_VIRQ_HANDLER                  0x80000000UL
 
+#define DOMAIN2__RELABELFROM                      0x00000001UL
+#define DOMAIN2__RELABELTO                        0x00000002UL
+#define DOMAIN2__RELABELSELF                      0x00000004UL
+
 #define HVM__SETHVMC                              0x00000001UL
 #define HVM__GETHVMC                              0x00000002UL
 #define HVM__SETPARAM                             0x00000004UL
diff --git a/xen/xsm/flask/include/class_to_string.h b/xen/xsm/flask/include/class_to_string.h
index ab55700..7716645 100644
--- a/xen/xsm/flask/include/class_to_string.h
+++ b/xen/xsm/flask/include/class_to_string.h
@@ -5,6 +5,7 @@
     S_("null")
     S_("xen")
     S_("domain")
+    S_("domain2")
     S_("hvm")
     S_("mmu")
     S_("resource")
diff --git a/xen/xsm/flask/include/flask.h b/xen/xsm/flask/include/flask.h
index 6d29c5a..3bff998 100644
--- a/xen/xsm/flask/include/flask.h
+++ b/xen/xsm/flask/include/flask.h
@@ -7,13 +7,14 @@
  */
 #define SECCLASS_XEN                                     1
 #define SECCLASS_DOMAIN                                  2
-#define SECCLASS_HVM                                     3
-#define SECCLASS_MMU                                     4
-#define SECCLASS_RESOURCE                                5
-#define SECCLASS_SHADOW                                  6
-#define SECCLASS_EVENT                                   7
-#define SECCLASS_GRANT                                   8
-#define SECCLASS_SECURITY                                9
+#define SECCLASS_DOMAIN2                                 3
+#define SECCLASS_HVM                                     4
+#define SECCLASS_MMU                                     5
+#define SECCLASS_RESOURCE                                6
+#define SECCLASS_SHADOW                                  7
+#define SECCLASS_EVENT                                   8
+#define SECCLASS_GRANT                                   9
+#define SECCLASS_SECURITY                                10
 
 /*
  * Security identifier indices for initial entities
-- 
1.7.11.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 12 16:00:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Sep 2012 16:00:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TBpM4-0005N5-6p; Wed, 12 Sep 2012 15:59:56 +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 1TBpM2-0005Mj-WB
	for xen-devel@lists.xen.org; Wed, 12 Sep 2012 15:59:55 +0000
Received: from [85.158.138.51:6697] by server-9.bemta-3.messagelabs.com id
	1A/93-15390-A71B0505; Wed, 12 Sep 2012 15:59:54 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-6.tower-174.messagelabs.com!1347465592!22162526!1
X-Originating-IP: [63.239.67.9]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8231 invoked from network); 12 Sep 2012 15:59:52 -0000
Received: from emvm-gh1-uea08.nsa.gov (HELO nsa.gov) (63.239.67.9)
	by server-6.tower-174.messagelabs.com with SMTP;
	12 Sep 2012 15:59:52 -0000
X-TM-IMSS-Message-ID: <39e1561e0010233b@nsa.gov>
Received: from tarius.tycho.ncsc.mil ([144.51.3.1]) by nsa.gov ([63.239.67.9])
	with ESMTP (TREND IMSS SMTP Service 7.1) id 39e1561e0010233b ;
	Wed, 12 Sep 2012 11:59:42 -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 q8CFxoOB006669; 
	Wed, 12 Sep 2012 11:59:50 -0400
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xen.org
Date: Wed, 12 Sep 2012 11:59:25 -0400
Message-Id: <1347465586-20009-2-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.11.4
In-Reply-To: <1347465586-20009-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1347465586-20009-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: dgdegra@tycho.nsa.gov
Subject: [Xen-devel] [PATCH 01/22] xsm/flask: remove inherited class
	attributes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 ability to declare common permission blocks shared across multiple
classes is not currently used in Xen. Currently, support for this
feature is broken in the header generation scripts, and it is not
expected that this feature will be used in the future, so remove the
dead code.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 tools/flask/policy/policy/flask/Makefile           |  2 +-
 tools/flask/policy/policy/flask/access_vectors     | 17 +----
 tools/flask/policy/policy/flask/mkaccess_vector.sh | 89 ----------------------
 xen/xsm/flask/avc.c                                | 39 ----------
 xen/xsm/flask/include/av_inherit.h                 |  1 -
 xen/xsm/flask/include/avc_ss.h                     |  8 --
 xen/xsm/flask/include/common_perm_to_string.h      |  1 -
 xen/xsm/flask/ss/policydb.c                        | 46 +----------
 xen/xsm/flask/ss/services.c                        | 54 +------------
 9 files changed, 8 insertions(+), 249 deletions(-)
 delete mode 100644 xen/xsm/flask/include/av_inherit.h
 delete mode 100644 xen/xsm/flask/include/common_perm_to_string.h

diff --git a/tools/flask/policy/policy/flask/Makefile b/tools/flask/policy/policy/flask/Makefile
index 970b9fe..5f57e88 100644
--- a/tools/flask/policy/policy/flask/Makefile
+++ b/tools/flask/policy/policy/flask/Makefile
@@ -14,7 +14,7 @@ FLASK_H_DEPEND = security_classes initial_sids
 AV_H_DEPEND = access_vectors
 
 FLASK_H_FILES = class_to_string.h flask.h initial_sid_to_string.h
-AV_H_FILES = av_inherit.h common_perm_to_string.h av_perm_to_string.h av_permissions.h
+AV_H_FILES = av_perm_to_string.h av_permissions.h
 ALL_H_FILES = $(FLASK_H_FILES) $(AV_H_FILES)
 
 all:  $(ALL_H_FILES)
diff --git a/tools/flask/policy/policy/flask/access_vectors b/tools/flask/policy/policy/flask/access_vectors
index 5901911..a884312 100644
--- a/tools/flask/policy/policy/flask/access_vectors
+++ b/tools/flask/policy/policy/flask/access_vectors
@@ -1,22 +1,7 @@
 #
-# Define common prefixes for access vectors
-#
-# common common_name { permission_name ... }
-
-#
-# Define a common prefix for file access vectors.
-#
-
-
-#
 # Define the access vectors.
 #
-# class class_name [ inherits common_name ] { permission_name ... }
-
-
-#
-# Define the access vector interpretation for file-related objects.
-#
+# class class_name { permission_name ... }
 
 class xen
 {
diff --git a/tools/flask/policy/policy/flask/mkaccess_vector.sh b/tools/flask/policy/policy/flask/mkaccess_vector.sh
index b5da734..43a60a7 100644
--- a/tools/flask/policy/policy/flask/mkaccess_vector.sh
+++ b/tools/flask/policy/policy/flask/mkaccess_vector.sh
@@ -10,50 +10,21 @@ shift
 
 # output files
 av_permissions="av_permissions.h"
-av_inherit="av_inherit.h"
-common_perm_to_string="common_perm_to_string.h"
 av_perm_to_string="av_perm_to_string.h"
 
 cat $* | $awk "
 BEGIN	{
 		outfile = \"$av_permissions\"
-		inheritfile = \"$av_inherit\"
-		cpermfile = \"$common_perm_to_string\"
 		avpermfile = \"$av_perm_to_string\"
 		"'
 		nextstate = "COMMON_OR_AV";
 		printf("/* This file is automatically generated.  Do not edit. */\n") > outfile;
-		printf("/* This file is automatically generated.  Do not edit. */\n") > inheritfile;
-		printf("/* This file is automatically generated.  Do not edit. */\n") > cpermfile;
 		printf("/* This file is automatically generated.  Do not edit. */\n") > avpermfile;
 ;
 	}
 /^[ \t]*#/	{ 
 			next;
 		}
-$1 == "common"	{ 
-			if (nextstate != "COMMON_OR_AV")
-			{
-				printf("Parse error:  Unexpected COMMON definition on line %d\n", NR);
-				next;	
-			}
-
-			if ($2 in common_defined)
-			{
-				printf("Duplicate COMMON definition for %s on line %d.\n", $2, NR);
-				next;
-			}	
-			common_defined[$2] = 1;
-
-			tclass = $2;
-			common_name = $2; 
-			permission = 1;
-
-			printf("TB_(common_%s_perm_to_string)\n", $2) > cpermfile;
-
-			nextstate = "COMMON-OPENBRACKET";
-			next;
-		}
 $1 == "class"	{
 			if (nextstate != "COMMON_OR_AV" &&
 			    nextstate != "CLASS_OR_CLASS-OPENBRACKET")
@@ -71,62 +42,11 @@ $1 == "class"	{
 			} 
 			av_defined[tclass] = 1;
 
-			inherits = "";
 			permission = 1;
 
 			nextstate = "INHERITS_OR_CLASS-OPENBRACKET";
 			next;
 		}
-$1 == "inherits" {			
-			if (nextstate != "INHERITS_OR_CLASS-OPENBRACKET")
-			{
-				printf("Parse error:  Unexpected INHERITS definition on line %d\n", NR);
-				next;	
-			}
-
-			if (!($2 in common_defined))
-			{
-				printf("COMMON %s is not defined (line %d).\n", $2, NR);
-				next;
-			}
-
-			inherits = $2;
-			permission = common_base[$2];
-
-			for (combined in common_perms)
-			{
-				split(combined,separate, SUBSEP);
-				if (separate[1] == inherits)
-				{
-					inherited_perms[common_perms[combined]] = separate[2];
-				}
-			}
-
-                        j = 1;
-                        for (i in inherited_perms) {
-                            ind[j] = i + 0;
-                            j++;
-                        }
-                        n = asort(ind);
-			for (i = 1; i <= n; i++) {
-				perm = inherited_perms[ind[i]];
-				printf("#define %s__%s", toupper(tclass), toupper(perm)) > outfile; 
-				spaces = 40 - (length(perm) + length(tclass));
-				if (spaces < 1)
-				      spaces = 1;
-				for (j = 0; j < spaces; j++) 
-					printf(" ") > outfile; 
-				printf("0x%08xUL\n", ind[i]) > outfile; 
-			}
-			printf("\n") > outfile;
-                        for (i in ind) delete ind[i];
-                        for (i in inherited_perms) delete inherited_perms[i];
-
-			printf("   S_(SECCLASS_%s, %s, 0x%08xUL)\n", toupper(tclass), inherits, permission) > inheritfile; 
-
-			nextstate = "CLASS_OR_CLASS-OPENBRACKET";
-			next;
-		}
 $1 == "{"	{ 
 			if (nextstate != "INHERITS_OR_CLASS-OPENBRACKET" &&
 			    nextstate != "CLASS_OR_CLASS-OPENBRACKET" &&
@@ -177,15 +97,6 @@ $1 == "{"	{
 
 				av_perms[tclass,$1] = permission;
 		
-				if (inherits != "")
-				{
-					if ((inherits,$1) in common_perms)
-					{
-						printf("Permission %s in %s on line %d conflicts with common permission.\n", $1, tclass, inherits, NR);
-						next;
-					}
-				}
-
 				printf("#define %s__%s", toupper(tclass), toupper($1)) > outfile; 
 
 				printf("   S_(SECCLASS_%s, %s__%s, \"%s\")\n", toupper(tclass), toupper(tclass), toupper($1), $1) > avpermfile; 
diff --git a/xen/xsm/flask/avc.c b/xen/xsm/flask/avc.c
index 44240a9..7fede00 100644
--- a/xen/xsm/flask/avc.c
+++ b/xen/xsm/flask/avc.c
@@ -45,28 +45,11 @@ static const char *class_to_string[] = {
 #undef S_
 };
 
-#define TB_(s) static const char * s [] = {
-#define TE_(s) };
-#define S_(s) s,
-#include "common_perm_to_string.h"
-#undef TB_
-#undef TE_
-#undef S_
-
-static const struct av_inherit av_inherit[] = {
-#define S_(c, i, b) { .tclass = c, .common_pts = common_##i##_perm_to_string, \
-                      .common_base = b },
-#include "av_inherit.h"
-#undef S_
-};
-
 const struct selinux_class_perm selinux_class_perm = {
     .av_perm_to_string = av_perm_to_string,
     .av_pts_len = ARRAY_SIZE(av_perm_to_string),
     .class_to_string = class_to_string,
     .cts_len = ARRAY_SIZE(class_to_string),
-    .av_inherit = av_inherit,
-    .av_inherit_len = ARRAY_SIZE(av_inherit)
 };
 
 #define AVC_CACHE_SLOTS            512
@@ -181,8 +164,6 @@ static void avc_printk(struct avc_dump_buf *buf, const char *fmt, ...)
  */
 static void avc_dump_av(struct avc_dump_buf *buf, u16 tclass, u32 av)
 {
-    const char **common_pts = NULL;
-    u32 common_base = 0;
     int i, i2, perm;
 
     if ( av == 0 )
@@ -191,29 +172,9 @@ static void avc_dump_av(struct avc_dump_buf *buf, u16 tclass, u32 av)
         return;
     }
 
-    for ( i = 0; i < ARRAY_SIZE(av_inherit); i++ )
-    {
-        if (av_inherit[i].tclass == tclass)
-        {
-            common_pts = av_inherit[i].common_pts;
-            common_base = av_inherit[i].common_base;
-            break;
-        }
-    }
-
     avc_printk(buf, " {");
     i = 0;
     perm = 1;
-    while ( perm < common_base )
-    {
-        if (perm & av)
-        {
-            avc_printk(buf, " %s", common_pts[i]);
-            av &= ~perm;
-        }
-        i++;
-        perm <<= 1;
-    }
 
     while ( i < sizeof(av) * 8 )
     {
diff --git a/xen/xsm/flask/include/av_inherit.h b/xen/xsm/flask/include/av_inherit.h
deleted file mode 100644
index 321ffe7..0000000
--- a/xen/xsm/flask/include/av_inherit.h
+++ /dev/null
@@ -1 +0,0 @@
-/* This file is automatically generated.  Do not edit. */
diff --git a/xen/xsm/flask/include/avc_ss.h b/xen/xsm/flask/include/avc_ss.h
index ea4e98c..a3d7d1e 100644
--- a/xen/xsm/flask/include/avc_ss.h
+++ b/xen/xsm/flask/include/avc_ss.h
@@ -16,19 +16,11 @@ struct av_perm_to_string {
     const char *name;
 };
 
-struct av_inherit {
-    const char **common_pts;
-    u32 common_base;
-    u16 tclass;
-};
-
 struct selinux_class_perm {
     const struct av_perm_to_string *av_perm_to_string;
     u32 av_pts_len;
     u32 cts_len;
     const char **class_to_string;
-    const struct av_inherit *av_inherit;
-    u32 av_inherit_len;
 };
 
 extern const struct selinux_class_perm selinux_class_perm;
diff --git a/xen/xsm/flask/include/common_perm_to_string.h b/xen/xsm/flask/include/common_perm_to_string.h
deleted file mode 100644
index 321ffe7..0000000
--- a/xen/xsm/flask/include/common_perm_to_string.h
+++ /dev/null
@@ -1 +0,0 @@
-/* This file is automatically generated.  Do not edit. */
diff --git a/xen/xsm/flask/ss/policydb.c b/xen/xsm/flask/ss/policydb.c
index 26097b9..fefcd59 100644
--- a/xen/xsm/flask/ss/policydb.c
+++ b/xen/xsm/flask/ss/policydb.c
@@ -254,14 +254,6 @@ out_free_symtab:
 
 static int common_index(void *key, void *datum, void *datap)
 {
-    struct policydb *p;
-    struct common_datum *comdatum;
-
-    comdatum = datum;
-    p = datap;
-    if ( !comdatum->value || comdatum->value > p->p_commons.nprim )
-        return -EINVAL;
-    p->p_common_val_to_name[comdatum->value - 1] = key;
     return 0;
 }
 
@@ -382,8 +374,7 @@ static int (*index_f[SYM_NUM]) (void *key, void *datum, void *datap) =
 };
 
 /*
- * Define the common val_to_name array and the class
- * val_to_name and val_to_struct arrays in a policy
+ * Define the class val_to_name and val_to_struct arrays in a policy
  * database structure.
  *
  * Caller must clean up upon failure.
@@ -392,18 +383,6 @@ static int policydb_index_classes(struct policydb *p)
 {
     int rc;
 
-    p->p_common_val_to_name =
-        xmalloc_array(char *, p->p_commons.nprim);
-    if ( !p->p_common_val_to_name )
-    {
-        rc = -ENOMEM;
-        goto out;
-    }
-
-    rc = hashtab_map(p->p_commons.table, common_index, p);
-    if ( rc )
-        goto out;
-
     p->class_val_to_struct =
         xmalloc_array(struct class_datum *, p->p_classes.nprim);
     if ( !p->class_val_to_struct )
@@ -1200,26 +1179,9 @@ static int class_read(struct policydb *p, struct hashtab *h, void *fp)
 
     if ( len2 )
     {
-        cladatum->comkey = xmalloc_array(char, len2 + 1);
-        if ( !cladatum->comkey )
-        {
-            rc = -ENOMEM;
-            goto bad;
-        }
-        rc = next_entry(cladatum->comkey, fp, len2);
-        if ( rc < 0 )
-            goto bad;
-        cladatum->comkey[len2] = 0;
-
-        cladatum->comdatum = hashtab_search(p->p_commons.table,
-                            cladatum->comkey);
-        if ( !cladatum->comdatum )
-        {
-            printk(KERN_ERR "Flask:  unknown common %s\n",
-                   cladatum->comkey);
-            rc = -EINVAL;
-            goto bad;
-        }
+        printk(KERN_ERR "Flask:  classes with common prefixes are not supported\n");
+        rc = -EINVAL;
+        goto bad;
     }
     for ( i = 0; i < nel; i++ )
     {
diff --git a/xen/xsm/flask/ss/services.c b/xen/xsm/flask/ss/services.c
index 363f586..1bf3b0c 100644
--- a/xen/xsm/flask/ss/services.c
+++ b/xen/xsm/flask/ss/services.c
@@ -1167,10 +1167,10 @@ int security_change_sid(u32 ssid, u32 tsid, u16 tclass, u32 *out_sid)
  */
 static int validate_classes(struct policydb *p)
 {
-    int i, j;
+    int i;
     struct class_datum *cladatum;
     struct perm_datum *perdatum;
-    u32 nprim, tmp, common_pts_len, perm_val, pol_val;
+    u32 nprim, perm_val, pol_val;
     u16 class_val;
     const struct selinux_class_perm *kdefs = &selinux_class_perm;
     const char *def_class, *def_perm, *pol_class;
@@ -1233,56 +1233,6 @@ static int validate_classes(struct policydb *p)
             return -EINVAL;
         }
     }
-    for ( i = 0; i < kdefs->av_inherit_len; i++ )
-    {
-        class_val = kdefs->av_inherit[i].tclass;
-        if ( class_val > p->p_classes.nprim )
-            continue;
-        pol_class = p->p_class_val_to_name[class_val-1];
-        cladatum = hashtab_search(p->p_classes.table, pol_class);
-        BUG_ON( !cladatum );
-        if ( !cladatum->comdatum )
-        {
-            printk(KERN_ERR
-            "Flask:  class %s should have an inherits clause but does not\n",
-                   pol_class);
-            return -EINVAL;
-        }
-        tmp = kdefs->av_inherit[i].common_base;
-        common_pts_len = 0;
-        while ( !(tmp & 0x01) )
-        {
-            common_pts_len++;
-            tmp >>= 1;
-        }
-        perms = &cladatum->comdatum->permissions;
-        for ( j = 0; j < common_pts_len; j++ )
-        {
-            def_perm = kdefs->av_inherit[i].common_pts[j];
-            if ( j >= perms->nprim )
-            {
-                printk(KERN_INFO
-                "Flask:  permission %s in class %s not defined in policy\n",
-                       def_perm, pol_class);
-                return -EINVAL;
-            }
-            perdatum = hashtab_search(perms->table, def_perm);
-            if ( perdatum == NULL )
-            {
-                printk(KERN_ERR
-                       "Flask:  permission %s in class %s not found in policy\n",
-                       def_perm, pol_class);
-                return -EINVAL;
-            }
-            if ( perdatum->value != j + 1 )
-            {
-                printk(KERN_ERR
-                      "Flask:  permission %s in class %s has incorrect value\n",
-                       def_perm, pol_class);
-                return -EINVAL;
-            }
-        }
-    }
     return 0;
 }
 
-- 
1.7.11.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 12 16:00:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Sep 2012 16:00:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TBpM6-0005Oj-Qp; Wed, 12 Sep 2012 15:59:58 +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 1TBpM4-0005N4-GK
	for xen-devel@lists.xen.org; Wed, 12 Sep 2012 15:59:56 +0000
Received: from [85.158.138.51:6819] by server-3.bemta-3.messagelabs.com id
	66/EC-21322-B71B0505; Wed, 12 Sep 2012 15:59:55 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-3.tower-174.messagelabs.com!1347465594!22112228!1
X-Originating-IP: [63.239.67.9]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10523 invoked from network); 12 Sep 2012 15:59:54 -0000
Received: from emvm-gh1-uea08.nsa.gov (HELO nsa.gov) (63.239.67.9)
	by server-3.tower-174.messagelabs.com with SMTP;
	12 Sep 2012 15:59:54 -0000
X-TM-IMSS-Message-ID: <39e15ca300102345@nsa.gov>
Received: from tarius.tycho.ncsc.mil ([144.51.3.1]) by nsa.gov ([63.239.67.9])
	with ESMTP (TREND IMSS SMTP Service 7.1) id 39e15ca300102345 ;
	Wed, 12 Sep 2012 11:59:44 -0400
Received: from moss-nexus.epoch.ncsc.mil (moss-nexus [144.51.25.48])
	by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id q8CFxoOG006669; 
	Wed, 12 Sep 2012 11:59:52 -0400
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xen.org
Date: Wed, 12 Sep 2012 11:59:30 -0400
Message-Id: <1347465586-20009-7-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.11.4
In-Reply-To: <1347465586-20009-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1347465586-20009-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: dgdegra@tycho.nsa.gov
Subject: [Xen-devel] [PATCH 06/22] flask/policy: Add domain relabel example
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This adds the nomigrate_t type to the example FLASK policy which allows
domains to be created that dom0 cannot access after building.

Example domain configuration snippet:
  seclabel='customer_1:vm_r:nomigrate_t'
  init_seclabel='customer_1:vm_r:nomigrate_t_building'

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 docs/misc/xsm-flask.txt                      |  2 +
 tools/flask/policy/policy/modules/xen/xen.if | 56 +++++++++++++++++++++-------
 tools/flask/policy/policy/modules/xen/xen.te | 10 +++++
 3 files changed, 55 insertions(+), 13 deletions(-)

diff --git a/docs/misc/xsm-flask.txt b/docs/misc/xsm-flask.txt
index 6b0d327..0778a28 100644
--- a/docs/misc/xsm-flask.txt
+++ b/docs/misc/xsm-flask.txt
@@ -60,6 +60,8 @@ that can be used without dom0 disaggregation. The main types for domUs are:
  - domU_t is a domain that can communicate with any other domU_t
  - isolated_domU_t can only communicate with dom0
  - prot_domU_t is a domain type whose creation can be disabled with a boolean
+ - nomigrate_t is a domain that must be created via the nomigrate_t_building
+   type, and whose memory cannot be read by dom0 once created
 
 HVM domains with stubdomain device models use two types (one per domain):
  - domHVM_t is an HVM domain that uses a stubdomain device model
diff --git a/tools/flask/policy/policy/modules/xen/xen.if b/tools/flask/policy/policy/modules/xen/xen.if
index 3f58909..2ad11b2 100644
--- a/tools/flask/policy/policy/modules/xen/xen.if
+++ b/tools/flask/policy/policy/modules/xen/xen.if
@@ -9,24 +9,47 @@
 #   Declare a type as a domain type, and allow basic domain setup
 define(`declare_domain', `
 	type $1, domain_type`'ifelse(`$#', `1', `', `,shift($@)');
+	type $1_channel, event_type;
+	type_transition $1 domain_type:event $1_channel;
 	allow $1 $1:grant { query setup };
 	allow $1 $1:mmu { adjust physmap map_read map_write stat pinpage };
 	allow $1 $1:hvm { getparam setparam };
 ')
 
-# create_domain(priv, target)
-#   Allow a domain to be created
-define(`create_domain', `
+# declare_build_label(type)
+#   Declare a paired _building type for the given domain type
+define(`declare_build_label', `
+	type $1_building, domain_type;
+	type_transition $1_building domain_type:event $1_channel;
+	allow $1_building $1 : domain transition;
+')
+
+define(`create_domain_common', `
 	allow $1 $2:domain { create max_vcpus setdomainmaxmem setaddrsize
-			getdomaininfo hypercall setvcpucontext scheduler
-			unpause getvcpuinfo getvcpuextstate getaddrsize
-			getvcpuaffinity };
+			getdomaininfo hypercall setvcpucontext setextvcpucontext
+			scheduler getvcpuinfo getvcpuextstate getaddrsize
+			getvcpuaffinity setvcpuaffinity };
 	allow $1 $2:security check_context;
 	allow $1 $2:shadow enable;
 	allow $1 $2:mmu {map_read map_write adjust memorymap physmap pinpage};
 	allow $1 $2:grant setup;
-	allow $1 $2:hvm { cacheattr getparam hvmctl irqlevel pciroute setparam pcilevel trackdirtyvram };
-	allow $1 $2_$1_channel:event create;
+	allow $1 $2:hvm { cacheattr getparam hvmctl irqlevel pciroute sethvmc setparam pcilevel trackdirtyvram };
+')
+
+# create_domain(priv, target)
+#   Allow a domain to be created directly
+define(`create_domain', `
+	create_domain_common($1, $2)
+	allow $1 $2_channel:event create;
+')
+
+# create_domain_build_label(priv, target)
+#   Allow a domain to be created via its domain build label
+define(`create_domain_build_label', `
+	create_domain_common($1, $2_building)
+	allow $1 $2_channel:event create;
+	allow $1 $2_building:domain2 relabelfrom;
+	allow $1 $2:domain2 relabelto;
 ')
 
 # manage_domain(priv, target)
@@ -37,6 +60,15 @@ define(`manage_domain', `
 			setvcpuaffinity setdomainmaxmem };
 ')
 
+# migrate_domain_out(priv, target)
+#   Allow creation of a snapshot or migration image from a domain
+#   (inbound migration is the same as domain creation)
+define(`migrate_domain_out', `
+	allow $1 $2:hvm { gethvmc getparam irqlevel };
+	allow $1 $2:mmu { stat pageinfo map_read };
+	allow $1 $2:domain { getaddrsize getvcpucontext getextvcpucontext getvcpuextstate pause destroy };
+')
+
 ################################################################################
 #
 # Inter-domain communication
@@ -47,8 +79,6 @@ define(`manage_domain', `
 #   This allows an event channel to be created from domains with labels
 #   <source> to <dest> and will label it <chan-label>
 define(`create_channel', `
-	type $3, event_type;
-	type_transition $1 $2:event $3;
 	allow $1 $3:event { create send status };
 	allow $3 $2:event { bind };
 ')
@@ -56,8 +86,8 @@ define(`create_channel', `
 # domain_event_comms(dom1, dom2)
 #   Allow two domain types to communicate using event channels
 define(`domain_event_comms', `
-	create_channel($1, $2, $1_$2_channel)
-	create_channel($2, $1, $2_$1_channel)
+	create_channel($1, $2, $1_channel)
+	create_channel($2, $1, $2_channel)
 ')
 
 # domain_comms(dom1, dom2)
@@ -72,7 +102,7 @@ define(`domain_comms', `
 #   Allow a domain types to communicate with others of its type using grants
 #   and event channels (this includes event channels to DOMID_SELF)
 define(`domain_self_comms', `
-	create_channel($1, $1, $1_self_channel)
+	create_channel($1, $1, $1_channel)
 	allow $1 $1:grant { map_read map_write copy unmap };
 ')
 
diff --git a/tools/flask/policy/policy/modules/xen/xen.te b/tools/flask/policy/policy/modules/xen/xen.te
index 9550397..1162153 100644
--- a/tools/flask/policy/policy/modules/xen/xen.te
+++ b/tools/flask/policy/policy/modules/xen/xen.te
@@ -90,6 +90,7 @@ create_domain(dom0_t, isolated_domU_t)
 manage_domain(dom0_t, isolated_domU_t)
 domain_comms(dom0_t, isolated_domU_t)
 
+# Declare a boolean that denies creation of prot_domU_t domains
 gen_bool(prot_doms_locked, false)
 declare_domain(prot_domU_t)
 if (!prot_doms_locked) {
@@ -111,6 +112,15 @@ manage_domain(dom0_t, dm_dom_t)
 domain_comms(dom0_t, dm_dom_t)
 device_model(dm_dom_t, domHVM_t)
 
+# nomigrate_t must be built via the nomigrate_t_building label; once built,
+# dom0 cannot read its memory.
+declare_domain(nomigrate_t)
+declare_build_label(nomigrate_t)
+create_domain_build_label(dom0_t, nomigrate_t)
+manage_domain(dom0_t, nomigrate_t)
+domain_comms(dom0_t, nomigrate_t)
+domain_self_comms(nomigrate_t)
+
 ###############################################################################
 #
 # Device delegation
-- 
1.7.11.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 12 16:00:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Sep 2012 16:00:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TBpMG-0005re-LP; Wed, 12 Sep 2012 16:00:08 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1TBpMD-0005Q4-LS
	for xen-devel@lists.xen.org; Wed, 12 Sep 2012 16:00:06 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-6.tower-27.messagelabs.com!1347465596!5177876!1
X-Originating-IP: [63.239.67.10]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11790 invoked from network); 12 Sep 2012 15:59:57 -0000
Received: from emvm-gh1-uea09.nsa.gov (HELO nsa.gov) (63.239.67.10)
	by server-6.tower-27.messagelabs.com with SMTP;
	12 Sep 2012 15:59:57 -0000
X-TM-IMSS-Message-ID: <39e125fa001083dd@nsa.gov>
Received: from tarius.tycho.ncsc.mil ([144.51.3.1]) by nsa.gov
	([63.239.67.10]) with ESMTP (TREND IMSS SMTP Service 7.1) id
	39e125fa001083dd ; Wed, 12 Sep 2012 12:02:03 -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 q8CFxoOR006669; 
	Wed, 12 Sep 2012 11:59:54 -0400
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xen.org
Date: Wed, 12 Sep 2012 11:59:41 -0400
Message-Id: <1347465586-20009-18-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.11.4
In-Reply-To: <1347465586-20009-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1347465586-20009-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: dgdegra@tycho.nsa.gov
Subject: [Xen-devel] [PATCH 17/22] xsm/flask: add distinct SIDs for
	self/target 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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Because the FLASK XSM module no longer checks IS_PRIV for remote domain
accesses covered by XSM permissions, domains now have the ability to
perform memory management and other functions on all domains that have
the same type. While it is possible to prevent this by only creating one
domain per type, this solution significantly limits the flexibility of
the type system.

This patch introduces a domain type transition to represent a domain
that is operating on itself. In the example policy, this is demonstrated
by creating a type with _self appended when declaring a domain type
which will be used for reflexive operations. AVCs for a domain of type
domU_t will look like the following:

scontext=system_u:system_r:domU_t tcontext=system_u:system_r:domU_t_self

This change also allows policy to distinguish between event channels a
domain creates to itself and event channels created between domains of
the same type.

The IS_PRIV_FOR check used for device model domains is also no longer
checked by FLASK; a similar transition is performed when the target is
set and used when the device model accesses its target domain.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 docs/misc/xsm-flask.txt                      |  43 ++-
 tools/flask/policy/policy/modules/xen/xen.if |  60 +++-
 tools/flask/policy/policy/modules/xen/xen.te |  13 +-
 xen/xsm/flask/flask_op.c                     |   9 +
 xen/xsm/flask/hooks.c                        | 422 +++++++++++++--------------
 xen/xsm/flask/include/objsec.h               |   2 +
 6 files changed, 307 insertions(+), 242 deletions(-)

diff --git a/docs/misc/xsm-flask.txt b/docs/misc/xsm-flask.txt
index 0778a28..ff81b01 100644
--- a/docs/misc/xsm-flask.txt
+++ b/docs/misc/xsm-flask.txt
@@ -68,9 +68,43 @@ HVM domains with stubdomain device models use two types (one per domain):
  - dm_dom_t is the device model for a domain with type domHVM_t
 
 One disadvantage of using type enforcement to enforce isolation is that a new
-type is needed for each group of domains. In addition, it is not possible to
-allow isolated_domU_t cannot to create loopback event channels without allowing
-two domains of type isolated_domU_t to communicate with one another.
+type is needed for each group of domains. The user field can be used to address
+this for the most common case of groups that can communicate internally but not
+externally; see "Users and roles" below.
+
+Type transitions
+----------------
+
+Xen defines a number of operations such as memory mapping that are necessary for
+a domain to perform on itself, but are also undesirable to allow a domain to
+perform on every other domain of the same label. While it is possible to address
+this by only creating one domain per type, this solution significantly limits
+the flexibility of the type system. Another method to address this issue is to
+duplicate the permission names for every operation that can be performed on the
+current domain or on other domains; however, this significantly increases the
+necessary number of permissions and complicates the XSM hooks. Instead, this is
+addressed by allowing a distinct type to be used for a domain's access to
+itself. The same applies for a device model domain's access to its designated
+target, allowing the IS_PRIV_FOR checks used in Xen's DAC model to be
+implemented in FLASK.
+
+Upon domain creation (or relabel), a type transition is computed using the
+domain's label as the source and target. The result of this computation is used
+as the target when the domain accesses itself. In the example policy, this
+computed type is the result of appending _self to a domain's type: domU_t_self
+for domU_t. If no type transition rule exists, the domain will continue to use
+its own label for both the source and target. An AVC message will look like:
+
+    scontext=system_u:system_r:domU_t tcontext=system_u:system_r:domU_t_self
+
+A similar type transition is done when a device model domain is associated with
+its target using the set_target operation. The transition is computed with the
+target domain as the source and the device model domain as the target: this
+ordering was chosen in order to preserve the original label for the target when
+no type transition rule exists. In the example policy, these computed types are
+the result of appending _target to the domain.
+
+Type transitions are also used to compute the labels of event channels.
 
 Users and roles
 ---------------
@@ -84,7 +118,8 @@ the customer_1 user.
 Access control rules involving users and roles are defined in the policy
 constraints file (tools/flask/policy/policy/constraints). The example policy
 provides constraints that prevent different users from communicating using
-grants or event channels, while still allowing communication with dom0.
+grants or event channels, while still allowing communication with the system_u
+user where dom0 resides.
 
 Resource Policy
 ---------------
diff --git a/tools/flask/policy/policy/modules/xen/xen.if b/tools/flask/policy/policy/modules/xen/xen.if
index 59ba171..d630f47 100644
--- a/tools/flask/policy/policy/modules/xen/xen.if
+++ b/tools/flask/policy/policy/modules/xen/xen.if
@@ -5,15 +5,34 @@
 # Domain creation and setup
 #
 ################################################################################
+define(`declare_domain_common', `
+	allow $1 $2:grant { query setup };
+	allow $1 $2:mmu { adjust physmap map_read map_write stat pinpage updatemp };
+	allow $1 $2:hvm { getparam setparam };
+')
+
 # declare_domain(type, attrs...)
-#   Declare a type as a domain type, and allow basic domain setup
+#   Declare a domain type, along with associated _self and _channel types
+#   Allow the domain to perform basic operations on itself
 define(`declare_domain', `
 	type $1, domain_type`'ifelse(`$#', `1', `', `,shift($@)');
+	type $1_self, domain_type, domain_self_type;
+	type_transition $1 $1:domain $1_self;
+	type $1_channel, event_type;
+	type_transition $1 domain_type:event $1_channel;
+	declare_domain_common($1, $1_self)
+')
+
+# declare_singleton_domain(type, attrs...)
+#   Declare a domain type and associated _channel types.
+#   Note: Because the domain can perform basic operations on itself and any
+#   other domain of the same type, this constructor should be used for types
+#   containing at most one domain. This is not enforced by policy.
+define(`declare_singleton_domain', `
+	type $1, domain_type`'ifelse(`$#', `1', `', `,shift($@)');
 	type $1_channel, event_type;
 	type_transition $1 domain_type:event $1_channel;
-	allow $1 $1:grant { query setup };
-	allow $1 $1:mmu { adjust physmap map_read map_write stat pinpage };
-	allow $1 $1:hvm { getparam setparam };
+	declare_domain_common($1, $1)
 ')
 
 # declare_build_label(type)
@@ -51,6 +70,7 @@ define(`create_domain_build_label', `
 	allow $1 $2_channel:event create;
 	allow $1 $2_building:domain2 relabelfrom;
 	allow $1 $2:domain2 relabelto;
+	allow $2_building $2:domain transition;
 ')
 
 # manage_domain(priv, target)
@@ -101,20 +121,36 @@ define(`domain_comms', `
 ')
 
 # domain_self_comms(domain)
-#   Allow a domain types to communicate with others of its type using grants
-#   and event channels (this includes event channels to DOMID_SELF)
+#   Allow a non-singleton domain type to communicate with itself using grants
+#   and event channels
 define(`domain_self_comms', `
-	create_channel($1, $1, $1_channel)
-	allow $1 $1:grant { map_read map_write copy unmap };
+	create_channel($1, $1_self, $1_channel)
+	allow $1 $1_self:grant { map_read map_write copy unmap };
 ')
 
 # device_model(dm_dom, hvm_dom)
 #   Define how a device model domain interacts with its target
 define(`device_model', `
-	domain_comms($1, $2)
-	allow $1 $2:domain { set_target shutdown };
-	allow $1 $2:mmu { map_read map_write adjust physmap };
-	allow $1 $2:hvm { getparam setparam trackdirtyvram hvmctl irqlevel pciroute cacheattr send_irq };
+	type $2_target, domain_type, domain_target_type;
+	type_transition $2 $1:domain $2_target;
+	allow $1 $2:domain set_target;
+
+	type_transition $2_target domain_type:event $2_channel;
+	create_channel($1, $2_target, $1_channel)
+	create_channel($2, $1, $2_channel)
+	allow $1 $2_channel:event create;
+
+	allow $1 $2_target:domain shutdown;
+	allow $1 $2_target:mmu { map_read map_write adjust physmap };
+	allow $1 $2_target:hvm { getparam setparam trackdirtyvram hvmctl irqlevel pciroute cacheattr send_irq };
+')
+
+# make_device_model(priv, dm_dom, hvm_dom)
+#   Allow creation of a device model and HVM domain pair
+define(`make_device_model', `
+	device_model($2, $3)
+	allow $1 $2:domain2 make_priv_for;
+	allow $1 $3:domain2 set_as_target;
 ')
 ################################################################################
 #
diff --git a/tools/flask/policy/policy/modules/xen/xen.te b/tools/flask/policy/policy/modules/xen/xen.te
index 1162153..8d33285 100644
--- a/tools/flask/policy/policy/modules/xen/xen.te
+++ b/tools/flask/policy/policy/modules/xen/xen.te
@@ -8,6 +8,8 @@
 ################################################################################
 attribute xen_type;
 attribute domain_type;
+attribute domain_self_type;
+attribute domain_target_type;
 attribute resource_type;
 attribute event_type;
 attribute mls_priv;
@@ -25,7 +27,7 @@ attribute mls_priv;
 type xen_t, xen_type, mls_priv;
 
 # Domain 0
-declare_domain(dom0_t, mls_priv);
+declare_singleton_domain(dom0_t, mls_priv);
 
 # Untracked I/O memory (pseudo-domain)
 type domio_t, xen_type;
@@ -69,7 +71,7 @@ admin_device(dom0_t, ioport_t)
 admin_device(dom0_t, iomem_t)
 allow dom0_t domio_t:mmu { map_read map_write };
 
-domain_self_comms(dom0_t)
+domain_comms(dom0_t, dom0_t)
 
 auditallow dom0_t security_t:security { load_policy setenforce setbool };
 
@@ -84,11 +86,14 @@ domain_self_comms(domU_t)
 create_domain(dom0_t, domU_t)
 manage_domain(dom0_t, domU_t)
 domain_comms(dom0_t, domU_t)
+domain_comms(domU_t, domU_t)
+domain_self_comms(domU_t)
 
 declare_domain(isolated_domU_t)
 create_domain(dom0_t, isolated_domU_t)
 manage_domain(dom0_t, isolated_domU_t)
 domain_comms(dom0_t, isolated_domU_t)
+domain_self_comms(isolated_domU_t)
 
 # Declare a boolean that denies creation of prot_domU_t domains
 gen_bool(prot_doms_locked, false)
@@ -98,6 +103,8 @@ if (!prot_doms_locked) {
 }
 domain_comms(dom0_t, prot_domU_t)
 domain_comms(domU_t, prot_domU_t)
+domain_comms(prot_domU_t, prot_domU_t)
+domain_self_comms(prot_domU_t)
 
 # domHVM_t is meant to be paired with a qemu-dm stub domain of type dm_dom_t
 declare_domain(domHVM_t)
@@ -110,7 +117,7 @@ declare_domain(dm_dom_t)
 create_domain(dom0_t, dm_dom_t)
 manage_domain(dom0_t, dm_dom_t)
 domain_comms(dom0_t, dm_dom_t)
-device_model(dm_dom_t, domHVM_t)
+make_device_model(dom0_t, dm_dom_t, domHVM_t)
 
 # nomigrate_t must be built via the nomigrate_t_building label; once built,
 # dom0 cannot read its memory.
diff --git a/xen/xsm/flask/flask_op.c b/xen/xsm/flask/flask_op.c
index 9c8dfe7..f8fc108 100644
--- a/xen/xsm/flask/flask_op.c
+++ b/xen/xsm/flask/flask_op.c
@@ -612,6 +612,15 @@ static int flask_relabel_domain(struct xen_flask_relabel *arg)
         goto out;
 
     dsec->sid = arg->sid;
+    dsec->self_sid = arg->sid;
+    security_transition_sid(dsec->sid, dsec->sid, SECCLASS_DOMAIN,
+                            &dsec->self_sid);
+    if ( d->target )
+    {
+        struct domain_security_struct *tsec = d->target->ssid;
+        security_transition_sid(tsec->sid, dsec->sid, SECCLASS_DOMAIN,
+                                &dsec->target_sid);
+    }
 
  out:
     rcu_unlock_domain(d);
diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
index 3cb814d..421087f 100644
--- a/xen/xsm/flask/hooks.c
+++ b/xen/xsm/flask/hooks.c
@@ -33,38 +33,69 @@
 
 struct xsm_operations *original_ops = NULL;
 
+static u32 domain_sid(struct domain *dom)
+{
+    struct domain_security_struct *dsec = dom->ssid;
+    return dsec->sid;
+}
+
+static u32 domain_target_sid(struct domain *src, struct domain *dst)
+{
+    struct domain_security_struct *ssec = src->ssid;
+    struct domain_security_struct *dsec = dst->ssid;
+    if (src == dst)
+        return ssec->self_sid;
+    if (src->target == dst)
+        return ssec->target_sid;
+    return dsec->sid;
+}
+
+static u32 evtchn_sid(const struct evtchn *chn)
+{
+    struct evtchn_security_struct *esec = chn->ssid;
+    return esec->sid;
+}
+
 static int domain_has_perm(struct domain *dom1, struct domain *dom2, 
                            u16 class, u32 perms)
 {
-    struct domain_security_struct *dsec1, *dsec2;
+    u32 ssid, tsid;
     struct avc_audit_data ad;
     AVC_AUDIT_DATA_INIT(&ad, NONE);
     ad.sdom = dom1;
     ad.tdom = dom2;
 
-    dsec1 = dom1->ssid;
-    dsec2 = dom2->ssid;
+    ssid = domain_sid(dom1);
+    tsid = domain_target_sid(dom1, dom2);
 
-    return avc_has_perm(dsec1->sid, dsec2->sid, class, perms, &ad);
+    return avc_has_perm(ssid, tsid, class, perms, &ad);
 }
 
-static int domain_has_evtchn(struct domain *d, struct evtchn *chn, u32 perms)
+static int avc_current_has_perm(u32 tsid, u16 class, u32 perm,
+                                struct avc_audit_data *ad)
 {
-    struct domain_security_struct *dsec;
-    struct evtchn_security_struct *esec;
+    u32 csid = domain_sid(current->domain);
+    return avc_has_perm(csid, tsid, class, perm, ad);
+}
 
-    dsec = d->ssid;
-    esec = chn->ssid;
+static int current_has_perm(struct domain *d, u16 class, u32 perms)
+{
+    return domain_has_perm(current->domain, d, class, perms);
+}
 
-    return avc_has_perm(dsec->sid, esec->sid, SECCLASS_EVENT, perms, NULL);
+static int domain_has_evtchn(struct domain *d, struct evtchn *chn, u32 perms)
+{
+    u32 dsid = domain_sid(d);
+    u32 esid = evtchn_sid(chn);
+
+    return avc_has_perm(dsid, esid, SECCLASS_EVENT, perms, NULL);
 }
 
 static int domain_has_xen(struct domain *d, u32 perms)
 {
-    struct domain_security_struct *dsec;
-    dsec = d->ssid;
+    u32 dsid = domain_sid(d);
 
-    return avc_has_perm(dsec->sid, SECINITSID_XEN, SECCLASS_XEN, perms, NULL);
+    return avc_has_perm(dsid, SECINITSID_XEN, SECCLASS_XEN, perms, NULL);
 }
 
 static int get_irq_sid(int irq, u32 *sid, struct avc_audit_data *ad)
@@ -123,6 +154,7 @@ static int flask_domain_alloc_security(struct domain *d)
         dsec->sid = SECINITSID_UNLABELED;
     }
 
+    dsec->self_sid = dsec->sid;
     d->ssid = dsec;
 
     return 0;
@@ -142,68 +174,55 @@ static void flask_domain_free_security(struct domain *d)
 static int flask_evtchn_unbound(struct domain *d1, struct evtchn *chn, 
                                 domid_t id2)
 {
-    u32 newsid;
+    u32 sid1, sid2, newsid;
     int rc;
-    domid_t id;
     struct domain *d2;
-    struct domain_security_struct *dsec, *dsec1, *dsec2;
     struct evtchn_security_struct *esec;
 
-    dsec = current->domain->ssid;
-    dsec1 = d1->ssid;
-    esec = chn->ssid;
-
-    if ( id2 == DOMID_SELF )
-        id = current->domain->domain_id;
-    else
-        id = id2;
-
-    d2 = get_domain_by_id(id);
+    d2 = rcu_lock_domain_by_any_id(id2);
     if ( d2 == NULL )
         return -EPERM;
 
-    dsec2 = d2->ssid;
-    rc = security_transition_sid(dsec1->sid, dsec2->sid, SECCLASS_EVENT, 
-                                 &newsid);
+    sid1 = domain_sid(d1);
+    sid2 = domain_target_sid(d1, d2);
+    esec = chn->ssid;
+
+    rc = security_transition_sid(sid1, sid2, SECCLASS_EVENT, &newsid);
     if ( rc )
         goto out;
 
-    rc = avc_has_perm(dsec->sid, newsid, SECCLASS_EVENT, EVENT__CREATE, NULL);
+    rc = avc_current_has_perm(newsid, SECCLASS_EVENT, EVENT__CREATE, NULL);
     if ( rc )
         goto out;
 
-    rc = avc_has_perm(newsid, dsec2->sid, SECCLASS_EVENT, EVENT__BIND, NULL);
+    rc = avc_has_perm(newsid, sid2, SECCLASS_EVENT, EVENT__BIND, NULL);
     if ( rc )
         goto out;
-    else
-        esec->sid = newsid;
+
+    esec->sid = newsid;
 
  out:
-    put_domain(d2);
+    rcu_unlock_domain(d2);
     return rc;
 }
 
 static int flask_evtchn_interdomain(struct domain *d1, struct evtchn *chn1, 
                                     struct domain *d2, struct evtchn *chn2)
 {
-    u32 newsid;
+    u32 sid1, sid2, newsid, reverse_sid;
     int rc;
-    struct domain_security_struct *dsec, *dsec1, *dsec2;
-    struct evtchn_security_struct *esec1, *esec2;
+    struct evtchn_security_struct *esec1;
     struct avc_audit_data ad;
     AVC_AUDIT_DATA_INIT(&ad, NONE);
     ad.sdom = d1;
     ad.tdom = d2;
 
-    dsec = current->domain->ssid;
-    dsec1 = d1->ssid;
-    dsec2 = d2->ssid;
+    sid1 = domain_sid(d1);
+    sid2 = domain_target_sid(d1, d2);
 
     esec1 = chn1->ssid;
-    esec2 = chn2->ssid;
 
-    rc = security_transition_sid(dsec1->sid, dsec2->sid, 
-                                 SECCLASS_EVENT, &newsid);
+    rc = security_transition_sid(sid1, sid2, SECCLASS_EVENT, &newsid);
     if ( rc )
     {
         printk("%s: security_transition_sid failed, rc=%d (domain=%d)\n",
@@ -211,15 +230,20 @@ static int flask_evtchn_interdomain(struct domain *d1, struct evtchn *chn1,
         return rc;
     }
 
-    rc = avc_has_perm(dsec->sid, newsid, SECCLASS_EVENT, EVENT__CREATE, &ad);
+    rc = avc_current_has_perm(newsid, SECCLASS_EVENT, EVENT__CREATE, &ad);
     if ( rc )
         return rc;
 
-    rc = avc_has_perm(newsid, dsec2->sid, SECCLASS_EVENT, EVENT__BIND, &ad);
+    rc = avc_has_perm(newsid, sid2, SECCLASS_EVENT, EVENT__BIND, &ad);
     if ( rc )
         return rc;
 
-    rc = avc_has_perm(esec2->sid, dsec1->sid, SECCLASS_EVENT, EVENT__BIND, &ad);
+    /* It's possible the target domain has changed (relabel or destroy/create)
+     * since the unbound part was created; re-validate this binding now.
+     */
+    reverse_sid = evtchn_sid(chn2);
+    sid1 = domain_target_sid(d2, d1);
+    rc = avc_has_perm(reverse_sid, sid1, SECCLASS_EVENT, EVENT__BIND, &ad);
     if ( rc )
         return rc;
 
@@ -302,7 +326,6 @@ static void flask_free_security_evtchn(struct evtchn *chn)
 
 static char *flask_show_security_evtchn(struct domain *d, const struct evtchn *chn)
 {
-    struct evtchn_security_struct *esec;
     int irq;
     u32 sid = 0;
     char *ctx;
@@ -312,9 +335,7 @@ static char *flask_show_security_evtchn(struct domain *d, const struct evtchn *c
     {
     case ECS_UNBOUND:
     case ECS_INTERDOMAIN:
-        esec = chn->ssid;
-        if ( esec )
-            sid = esec->sid;
+        sid = evtchn_sid(chn);
         break;
     case ECS_PIRQ:
         irq = domain_pirq_to_irq(d, chn->u.pirq.irq);
@@ -367,12 +388,12 @@ static int flask_grant_query_size(struct domain *d1, struct domain *d2)
 
 static int flask_get_pod_target(struct domain *d)
 {
-    return domain_has_perm(current->domain, d, SECCLASS_DOMAIN, DOMAIN__GETPODTARGET);
+    return current_has_perm(d, SECCLASS_DOMAIN, DOMAIN__GETPODTARGET);
 }
 
 static int flask_set_pod_target(struct domain *d)
 {
-    return domain_has_perm(current->domain, d, SECCLASS_DOMAIN, DOMAIN__SETPODTARGET);
+    return current_has_perm(d, SECCLASS_DOMAIN, DOMAIN__SETPODTARGET);
 }
 
 static int flask_memory_adjust_reservation(struct domain *d1, struct domain *d2)
@@ -455,70 +476,65 @@ static int flask_schedop_shutdown(struct domain *d1, struct domain *d2)
 static void flask_security_domaininfo(struct domain *d, 
                                       struct xen_domctl_getdomaininfo *info)
 {
-    struct domain_security_struct *dsec;
-
-    dsec = d->ssid;
-    info->ssidref = dsec->sid;
+    info->ssidref = domain_sid(d);
 }
 
 static int flask_setvcpucontext(struct domain *d)
 {
-    return domain_has_perm(current->domain, d, SECCLASS_DOMAIN, 
-                           DOMAIN__SETVCPUCONTEXT);
+    return current_has_perm(d, SECCLASS_DOMAIN, DOMAIN__SETVCPUCONTEXT);
 }
 
 static int flask_pausedomain(struct domain *d)
 {
-    return domain_has_perm(current->domain, d, SECCLASS_DOMAIN, DOMAIN__PAUSE);
+    return current_has_perm(d, SECCLASS_DOMAIN, DOMAIN__PAUSE);
 }
 
 static int flask_unpausedomain(struct domain *d)
 {
-    return domain_has_perm(current->domain, d, SECCLASS_DOMAIN, DOMAIN__UNPAUSE);
+    return current_has_perm(d, SECCLASS_DOMAIN, DOMAIN__UNPAUSE);
 }
 
 static int flask_resumedomain(struct domain *d)
 {
-    return domain_has_perm(current->domain, d, SECCLASS_DOMAIN, DOMAIN__RESUME);
+    return current_has_perm(d, SECCLASS_DOMAIN, DOMAIN__RESUME);
 }
 
 static int flask_domain_create(struct domain *d, u32 ssidref)
 {
     int rc;
-    struct domain_security_struct *dsec1;
-    struct domain_security_struct *dsec2;
+    struct domain_security_struct *dsec = d->ssid;
     static int dom0_created = 0;
 
-    dsec1 = current->domain->ssid;
-    dsec2 = d->ssid;
-
     if ( is_idle_domain(current->domain) && !dom0_created )
     {
-        dsec2->sid = SECINITSID_DOM0;
+        dsec->sid = SECINITSID_DOM0;
         dom0_created = 1;
-        return 0;
     }
+    else
+    {
+        rc = avc_current_has_perm(ssidref, SECCLASS_DOMAIN,
+                          DOMAIN__CREATE, NULL);
+        if ( rc )
+            return rc;
 
-    rc = avc_has_perm(dsec1->sid, ssidref, SECCLASS_DOMAIN,
-                      DOMAIN__CREATE, NULL);
-    if ( rc )
-        return rc;
+        dsec->sid = ssidref;
+    }
+    dsec->self_sid = dsec->sid;
 
-    dsec2->sid = ssidref;
+    rc = security_transition_sid(dsec->sid, dsec->sid, SECCLASS_DOMAIN,
+                                 &dsec->self_sid);
 
     return rc;
 }
 
 static int flask_max_vcpus(struct domain *d)
 {
-    return domain_has_perm(current->domain, d, SECCLASS_DOMAIN, 
-                           DOMAIN__MAX_VCPUS);
+    return current_has_perm(d, SECCLASS_DOMAIN, DOMAIN__MAX_VCPUS);
 }
 
 static int flask_destroydomain(struct domain *d)
 {
-    return domain_has_perm(current->domain, d, SECCLASS_DOMAIN, 
-                           DOMAIN__DESTROY);
+    return current_has_perm(d, SECCLASS_DOMAIN, DOMAIN__DESTROY);
 }
 
 static int flask_vcpuaffinity(int cmd, struct domain *d)
@@ -537,7 +553,7 @@ static int flask_vcpuaffinity(int cmd, struct domain *d)
         return -EPERM;
     }
 
-    return domain_has_perm(current->domain, d, SECCLASS_DOMAIN, perm );
+    return current_has_perm(d, SECCLASS_DOMAIN, perm );
 }
 
 static int flask_scheduler(struct domain *d)
@@ -548,43 +564,51 @@ static int flask_scheduler(struct domain *d)
     if ( rc )
         return rc;
 
-    return domain_has_perm(current->domain, d, SECCLASS_DOMAIN, 
-                           DOMAIN__SCHEDULER);
+    return current_has_perm(d, SECCLASS_DOMAIN, DOMAIN__SCHEDULER);
 }
 
 static int flask_getdomaininfo(struct domain *d)
 {
-    return domain_has_perm(current->domain, d, SECCLASS_DOMAIN,
-                           DOMAIN__GETDOMAININFO);
+    return current_has_perm(d, SECCLASS_DOMAIN, DOMAIN__GETDOMAININFO);
 }
 
 static int flask_getvcpucontext(struct domain *d)
 {
-    return domain_has_perm(current->domain, d, SECCLASS_DOMAIN, 
-                           DOMAIN__GETVCPUCONTEXT);
+    return current_has_perm(d, SECCLASS_DOMAIN, DOMAIN__GETVCPUCONTEXT);
 }
 
 static int flask_getvcpuinfo(struct domain *d)
 {
-    return domain_has_perm(current->domain, d, SECCLASS_DOMAIN,
-                           DOMAIN__GETVCPUINFO);
+    return current_has_perm(d, SECCLASS_DOMAIN, DOMAIN__GETVCPUINFO);
 }
 
 static int flask_domain_settime(struct domain *d)
 {
-    return domain_has_perm(current->domain, d, SECCLASS_DOMAIN, DOMAIN__SETTIME);
+    return current_has_perm(d, SECCLASS_DOMAIN, DOMAIN__SETTIME);
 }
 
-static int flask_set_target(struct domain *d, struct domain *e)
+static int flask_set_target(struct domain *d, struct domain *t)
 {
     int rc;
-    rc = domain_has_perm(current->domain, d, SECCLASS_DOMAIN2, DOMAIN2__MAKE_PRIV_FOR);
+    struct domain_security_struct *dsec, *tsec;
+    dsec = d->ssid;
+    tsec = t->ssid;
+
+    rc = current_has_perm(d, SECCLASS_DOMAIN2, DOMAIN2__MAKE_PRIV_FOR);
     if ( rc )
         return rc;
-    rc = domain_has_perm(current->domain, e, SECCLASS_DOMAIN2, DOMAIN2__SET_AS_TARGET);
+    rc = current_has_perm(t, SECCLASS_DOMAIN2, DOMAIN2__SET_AS_TARGET);
     if ( rc )
         return rc;
-    return domain_has_perm(d, e, SECCLASS_DOMAIN, DOMAIN__SET_TARGET);
+    /* Use avc_has_perm to avoid resolving target/current SID */
+    rc = avc_has_perm(dsec->sid, tsec->sid, SECCLASS_DOMAIN, DOMAIN__SET_TARGET, NULL);
+    if ( rc )
+        return rc;
+
+    /* (tsec, dsec) defaults the label to tsec, as it should here */
+    rc = security_transition_sid(tsec->sid, dsec->sid, SECCLASS_DOMAIN,
+                                 &dsec->target_sid);
+    return rc;
 }
 
 static int flask_domctl(struct domain *d, int cmd)
@@ -655,26 +679,24 @@ static int flask_domctl(struct domain *d, int cmd)
     case XEN_DOMCTL_gdbsx_pausevcpu:
     case XEN_DOMCTL_gdbsx_unpausevcpu:
     case XEN_DOMCTL_gdbsx_domstatus:
-        return domain_has_perm(current->domain, d, SECCLASS_DOMAIN,
-                               DOMAIN__SETDEBUGGING);
+        return current_has_perm(d, SECCLASS_DOMAIN, DOMAIN__SETDEBUGGING);
 
     case XEN_DOMCTL_subscribe:
     case XEN_DOMCTL_disable_migrate:
     case XEN_DOMCTL_suppress_spurious_page_faults:
-        return domain_has_perm(current->domain, d, SECCLASS_DOMAIN,
-                               DOMAIN__SET_MISC_INFO);
+        return current_has_perm(d, SECCLASS_DOMAIN, DOMAIN__SET_MISC_INFO);
 
     case XEN_DOMCTL_set_cpuid:
-        return domain_has_perm(current->domain, d, SECCLASS_DOMAIN2, DOMAIN2__SET_CPUID);
+        return current_has_perm(d, SECCLASS_DOMAIN2, DOMAIN2__SET_CPUID);
 
     case XEN_DOMCTL_gettscinfo:
-        return domain_has_perm(current->domain, d, SECCLASS_DOMAIN2, DOMAIN2__GETTSC);
+        return current_has_perm(d, SECCLASS_DOMAIN2, DOMAIN2__GETTSC);
 
     case XEN_DOMCTL_settscinfo:
-        return domain_has_perm(current->domain, d, SECCLASS_DOMAIN2, DOMAIN2__SETTSC);
+        return current_has_perm(d, SECCLASS_DOMAIN2, DOMAIN2__SETTSC);
 
     case XEN_DOMCTL_audit_p2m:
-        return domain_has_perm(current->domain, d, SECCLASS_HVM, HVM__AUDIT_P2M);
+        return current_has_perm(d, SECCLASS_HVM, HVM__AUDIT_P2M);
 
     default:
         printk("flask_domctl: Unknown op %d\n", cmd);
@@ -714,7 +736,7 @@ static int flask_sysctl(int cmd)
 
 static int flask_set_virq_handler(struct domain *d, uint32_t virq)
 {
-    return domain_has_perm(current->domain, d, SECCLASS_DOMAIN, DOMAIN__SET_VIRQ_HANDLER);
+    return current_has_perm(d, SECCLASS_DOMAIN, DOMAIN__SET_VIRQ_HANDLER);
 }
 
 static int flask_tbufcontrol(void)
@@ -739,20 +761,17 @@ static int flask_sched_id(void)
 
 static int flask_setdomainmaxmem(struct domain *d)
 {
-    return domain_has_perm(current->domain, d, SECCLASS_DOMAIN,
-                           DOMAIN__SETDOMAINMAXMEM);
+    return current_has_perm(d, SECCLASS_DOMAIN, DOMAIN__SETDOMAINMAXMEM);
 }
 
 static int flask_setdomainhandle(struct domain *d)
 {
-    return domain_has_perm(current->domain, d, SECCLASS_DOMAIN,
-                           DOMAIN__SETDOMAINHANDLE);
+    return current_has_perm(d, SECCLASS_DOMAIN, DOMAIN__SETDOMAINHANDLE);
 }
 
 static int flask_setdebugging(struct domain *d)
 {
-    return domain_has_perm(current->domain, d, SECCLASS_DOMAIN,
-                           DOMAIN__SETDEBUGGING);
+    return current_has_perm(d, SECCLASS_DOMAIN, DOMAIN__SETDEBUGGING);
 }
 
 static int flask_debug_keys(void)
@@ -814,14 +833,12 @@ static char *flask_show_irq_sid (int irq)
 
 static int flask_map_domain_pirq (struct domain *d, int irq, void *data)
 {
-    u32 sid;
+    u32 sid, dsid;
     int rc = -EPERM;
     struct msi_info *msi = data;
-
-    struct domain_security_struct *ssec, *tsec;
     struct avc_audit_data ad;
 
-    rc = domain_has_perm(current->domain, d, SECCLASS_RESOURCE, RESOURCE__ADD);
+    rc = current_has_perm(d, SECCLASS_RESOURCE, RESOURCE__ADD);
 
     if ( rc )
         return rc;
@@ -837,14 +854,13 @@ static int flask_map_domain_pirq (struct domain *d, int irq, void *data)
     if ( rc )
         return rc;
 
-    ssec = current->domain->ssid;
-    tsec = d->ssid;
+    dsid = domain_sid(d);
 
-    rc = avc_has_perm(ssec->sid, sid, SECCLASS_RESOURCE, RESOURCE__ADD_IRQ, &ad);
+    rc = avc_current_has_perm(sid, SECCLASS_RESOURCE, RESOURCE__ADD_IRQ, &ad);
     if ( rc )
         return rc;
 
-    rc = avc_has_perm(tsec->sid, sid, SECCLASS_RESOURCE, RESOURCE__USE, &ad);
+    rc = avc_has_perm(dsid, sid, SECCLASS_RESOURCE, RESOURCE__USE, &ad);
     return rc;
 }
 
@@ -852,16 +868,12 @@ static int flask_unmap_domain_pirq (struct domain *d, int irq)
 {
     u32 sid;
     int rc = -EPERM;
-
-    struct domain_security_struct *ssec;
     struct avc_audit_data ad;
 
-    rc = domain_has_perm(current->domain, d, SECCLASS_RESOURCE, RESOURCE__REMOVE);
+    rc = current_has_perm(d, SECCLASS_RESOURCE, RESOURCE__REMOVE);
     if ( rc )
         return rc;
 
-    ssec = current->domain->ssid;
-
     if ( irq >= nr_irqs_gsi ) {
         /* TODO support for MSI here */
         return 0;
@@ -871,19 +883,19 @@ static int flask_unmap_domain_pirq (struct domain *d, int irq)
     if ( rc )
         return rc;
 
-    rc = avc_has_perm(ssec->sid, sid, SECCLASS_RESOURCE, RESOURCE__REMOVE_IRQ, &ad);
+    rc = avc_current_has_perm(sid, SECCLASS_RESOURCE, RESOURCE__REMOVE_IRQ, &ad);
     return rc;
 }
 
 static int flask_irq_permission (struct domain *d, int pirq, uint8_t access)
 {
     /* the PIRQ number is not useful; real IRQ is checked during mapping */
-    return domain_has_perm(current->domain, d, SECCLASS_RESOURCE,
-                           resource_to_perm(access));
+    return current_has_perm(d, SECCLASS_RESOURCE, resource_to_perm(access));
 }
 
 struct iomem_has_perm_data {
-    struct domain_security_struct *ssec, *tsec;
+    u32 ssid;
+    u32 dsid;
     u32 perm;
 };
 
@@ -897,12 +909,12 @@ static int _iomem_has_perm(void *v, u32 sid, unsigned long start, unsigned long
     ad.range.start = start;
     ad.range.end = end;
 
-    rc = avc_has_perm(data->ssec->sid, sid, SECCLASS_RESOURCE, data->perm, &ad);
+    rc = avc_has_perm(data->ssid, sid, SECCLASS_RESOURCE, data->perm, &ad);
 
     if ( rc )
         return rc;
 
-    return avc_has_perm(data->tsec->sid, sid, SECCLASS_RESOURCE, RESOURCE__USE, &ad);
+    return avc_has_perm(data->dsid, sid, SECCLASS_RESOURCE, RESOURCE__USE, &ad);
 }
 
 static int flask_iomem_permission(struct domain *d, uint64_t start, uint64_t end, uint8_t access)
@@ -910,7 +922,7 @@ static int flask_iomem_permission(struct domain *d, uint64_t start, uint64_t end
     struct iomem_has_perm_data data;
     int rc;
 
-    rc = domain_has_perm(current->domain, d, SECCLASS_RESOURCE,
+    rc = current_has_perm(d, SECCLASS_RESOURCE,
                          resource_to_perm(access));
     if ( rc )
         return rc;
@@ -920,8 +932,8 @@ static int flask_iomem_permission(struct domain *d, uint64_t start, uint64_t end
     else
         data.perm = RESOURCE__REMOVE_IOMEM;
 
-    data.ssec = current->domain->ssid;
-    data.tsec = d->ssid;
+    data.ssid = domain_sid(current->domain);
+    data.dsid = domain_sid(d);
 
     return security_iterate_iomem_sids(start, end, _iomem_has_perm, &data);
 }
@@ -933,10 +945,9 @@ static int flask_iomem_mapping(struct domain *d, uint64_t start, uint64_t end, u
 
 static int flask_pci_config_permission(struct domain *d, uint32_t machine_bdf, uint16_t start, uint16_t end, uint8_t access)
 {
-    u32 rsid;
+    u32 dsid, rsid;
     int rc = -EPERM;
     struct avc_audit_data ad;
-    struct domain_security_struct *ssec;
     u32 perm = RESOURCE__USE;
 
     rc = security_device_sid(machine_bdf, &rsid);
@@ -949,33 +960,24 @@ static int flask_pci_config_permission(struct domain *d, uint32_t machine_bdf, u
 
     AVC_AUDIT_DATA_INIT(&ad, DEV);
     ad.device = (unsigned long) machine_bdf;
-    ssec = d->ssid;
-    return avc_has_perm(ssec->sid, rsid, SECCLASS_RESOURCE, perm, &ad);
+    dsid = domain_sid(d);
+    return avc_has_perm(dsid, rsid, SECCLASS_RESOURCE, perm, &ad);
 
 }
 
 static int flask_resource_plug_core(void)
 {
-    struct domain_security_struct *ssec;
-
-    ssec = current->domain->ssid;
-    return avc_has_perm(ssec->sid, SECINITSID_DOMXEN, SECCLASS_RESOURCE, RESOURCE__PLUG, NULL);
+    return avc_current_has_perm(SECINITSID_DOMXEN, SECCLASS_RESOURCE, RESOURCE__PLUG, NULL);
 }
 
 static int flask_resource_unplug_core(void)
 {
-    struct domain_security_struct *ssec;
-
-    ssec = current->domain->ssid;
-    return avc_has_perm(ssec->sid, SECINITSID_DOMXEN, SECCLASS_RESOURCE, RESOURCE__UNPLUG, NULL);
+    return avc_current_has_perm(SECINITSID_DOMXEN, SECCLASS_RESOURCE, RESOURCE__UNPLUG, NULL);
 }
 
 static int flask_resource_use_core(void)
 {
-    struct domain_security_struct *ssec;
-
-    ssec = current->domain->ssid;
-    return avc_has_perm(ssec->sid, SECINITSID_DOMXEN, SECCLASS_RESOURCE, RESOURCE__USE, NULL);
+    return avc_current_has_perm(SECINITSID_DOMXEN, SECCLASS_RESOURCE, RESOURCE__USE, NULL);
 }
 
 static int flask_resource_plug_pci(uint32_t machine_bdf)
@@ -983,7 +985,6 @@ static int flask_resource_plug_pci(uint32_t machine_bdf)
     u32 rsid;
     int rc = -EPERM;
     struct avc_audit_data ad;
-    struct domain_security_struct *ssec;
 
     rc = security_device_sid(machine_bdf, &rsid);
     if ( rc )
@@ -991,8 +992,7 @@ static int flask_resource_plug_pci(uint32_t machine_bdf)
 
     AVC_AUDIT_DATA_INIT(&ad, DEV);
     ad.device = (unsigned long) machine_bdf;
-    ssec = current->domain->ssid;
-    return avc_has_perm(ssec->sid, rsid, SECCLASS_RESOURCE, RESOURCE__PLUG, &ad);
+    return avc_current_has_perm(rsid, SECCLASS_RESOURCE, RESOURCE__PLUG, &ad);
 }
 
 static int flask_resource_unplug_pci(uint32_t machine_bdf)
@@ -1000,7 +1000,6 @@ static int flask_resource_unplug_pci(uint32_t machine_bdf)
     u32 rsid;
     int rc = -EPERM;
     struct avc_audit_data ad;
-    struct domain_security_struct *ssec;
 
     rc = security_device_sid(machine_bdf, &rsid);
     if ( rc )
@@ -1008,8 +1007,7 @@ static int flask_resource_unplug_pci(uint32_t machine_bdf)
 
     AVC_AUDIT_DATA_INIT(&ad, DEV);
     ad.device = (unsigned long) machine_bdf;
-    ssec = current->domain->ssid;
-    return avc_has_perm(ssec->sid, rsid, SECCLASS_RESOURCE, RESOURCE__UNPLUG, &ad);
+    return avc_current_has_perm(rsid, SECCLASS_RESOURCE, RESOURCE__UNPLUG, &ad);
 }
 
 static int flask_resource_setup_pci(uint32_t machine_bdf)
@@ -1017,7 +1015,6 @@ static int flask_resource_setup_pci(uint32_t machine_bdf)
     u32 rsid;
     int rc = -EPERM;
     struct avc_audit_data ad;
-    struct domain_security_struct *ssec;
 
     rc = security_device_sid(machine_bdf, &rsid);
     if ( rc )
@@ -1025,8 +1022,7 @@ static int flask_resource_setup_pci(uint32_t machine_bdf)
 
     AVC_AUDIT_DATA_INIT(&ad, DEV);
     ad.device = (unsigned long) machine_bdf;
-    ssec = current->domain->ssid;
-    return avc_has_perm(ssec->sid, rsid, SECCLASS_RESOURCE, RESOURCE__SETUP, &ad);
+    return avc_current_has_perm(rsid, SECCLASS_RESOURCE, RESOURCE__SETUP, &ad);
 }
 
 static int flask_resource_setup_gsi(int gsi)
@@ -1034,22 +1030,17 @@ static int flask_resource_setup_gsi(int gsi)
     u32 rsid;
     int rc = -EPERM;
     struct avc_audit_data ad;
-    struct domain_security_struct *ssec;
 
     rc = get_irq_sid(gsi, &rsid, &ad);
     if ( rc )
         return rc;
 
-    ssec = current->domain->ssid;
-    return avc_has_perm(ssec->sid, rsid, SECCLASS_RESOURCE, RESOURCE__SETUP, &ad);
+    return avc_current_has_perm(rsid, SECCLASS_RESOURCE, RESOURCE__SETUP, &ad);
 }
 
 static int flask_resource_setup_misc(void)
 {
-    struct domain_security_struct *ssec;
-
-    ssec = current->domain->ssid;
-    return avc_has_perm(ssec->sid, SECINITSID_XEN, SECCLASS_RESOURCE, RESOURCE__SETUP, NULL);
+    return avc_current_has_perm(SECINITSID_XEN, SECCLASS_RESOURCE, RESOURCE__SETUP, NULL);
 }
 
 static inline int flask_page_offline(uint32_t cmd)
@@ -1112,11 +1103,12 @@ static int flask_shadow_control(struct domain *d, uint32_t op)
         return -EPERM;
     }
 
-    return domain_has_perm(current->domain, d, SECCLASS_SHADOW, perm);
+    return current_has_perm(d, SECCLASS_SHADOW, perm);
 }
 
 struct ioport_has_perm_data {
-    struct domain_security_struct *ssec, *tsec;
+    u32 ssid;
+    u32 dsid;
     u32 perm;
 };
 
@@ -1130,12 +1122,12 @@ static int _ioport_has_perm(void *v, u32 sid, unsigned long start, unsigned long
     ad.range.start = start;
     ad.range.end = end;
 
-    rc = avc_has_perm(data->ssec->sid, sid, SECCLASS_RESOURCE, data->perm, &ad);
+    rc = avc_has_perm(data->ssid, sid, SECCLASS_RESOURCE, data->perm, &ad);
 
     if ( rc )
         return rc;
 
-    return avc_has_perm(data->tsec->sid, sid, SECCLASS_RESOURCE, RESOURCE__USE, &ad);
+    return avc_has_perm(data->dsid, sid, SECCLASS_RESOURCE, RESOURCE__USE, &ad);
 }
 
 static int flask_ioport_permission(struct domain *d, uint32_t start, uint32_t end, uint8_t access)
@@ -1143,7 +1135,7 @@ static int flask_ioport_permission(struct domain *d, uint32_t start, uint32_t en
     int rc;
     struct ioport_has_perm_data data;
 
-    rc = domain_has_perm(current->domain, d, SECCLASS_RESOURCE,
+    rc = current_has_perm(d, SECCLASS_RESOURCE,
                          resource_to_perm(access));
 
     if ( rc )
@@ -1154,8 +1146,8 @@ static int flask_ioport_permission(struct domain *d, uint32_t start, uint32_t en
     else
         data.perm = RESOURCE__REMOVE_IOPORT;
 
-    data.ssec = current->domain->ssid;
-    data.tsec = d->ssid;
+    data.ssid = domain_sid(current->domain);
+    data.dsid = domain_sid(d);
 
     return security_iterate_ioport_sids(start, end, _ioport_has_perm, &data);
 }
@@ -1167,18 +1159,17 @@ static int flask_ioport_mapping(struct domain *d, uint32_t start, uint32_t end,
 
 static int flask_getpageframeinfo(struct domain *d)
 {
-    return domain_has_perm(current->domain, d, SECCLASS_MMU, MMU__PAGEINFO);
+    return current_has_perm(d, SECCLASS_MMU, MMU__PAGEINFO);
 }
 
 static int flask_getmemlist(struct domain *d)
 {
-    return domain_has_perm(current->domain, d, SECCLASS_MMU, MMU__PAGELIST);
+    return current_has_perm(d, SECCLASS_MMU, MMU__PAGELIST);
 }
 
 static int flask_hypercall_init(struct domain *d)
 {
-    return domain_has_perm(current->domain, d, SECCLASS_DOMAIN,
-                           DOMAIN__HYPERCALL);
+    return current_has_perm(d, SECCLASS_DOMAIN, DOMAIN__HYPERCALL);
 }
 
 static int flask_hvmcontext(struct domain *d, uint32_t cmd)
@@ -1201,7 +1192,7 @@ static int flask_hvmcontext(struct domain *d, uint32_t cmd)
         return -EPERM;
     }
 
-    return domain_has_perm(current->domain, d, SECCLASS_HVM, perm);
+    return current_has_perm(d, SECCLASS_HVM, perm);
 }
 
 static int flask_address_size(struct domain *d, uint32_t cmd)
@@ -1220,7 +1211,7 @@ static int flask_address_size(struct domain *d, uint32_t cmd)
         return -EPERM;
     }
 
-    return domain_has_perm(current->domain, d, SECCLASS_DOMAIN, perm);
+    return current_has_perm(d, SECCLASS_DOMAIN, perm);
 }
 
 static int flask_machine_address_size(struct domain *d, uint32_t cmd)
@@ -1261,37 +1252,37 @@ static int flask_hvm_param(struct domain *d, unsigned long op)
         perm = HVM__HVMCTL;
     }
 
-    return domain_has_perm(current->domain, d, SECCLASS_HVM, perm);
+    return current_has_perm(d, SECCLASS_HVM, perm);
 }
 
 static int flask_hvm_set_pci_intx_level(struct domain *d)
 {
-    return domain_has_perm(current->domain, d, SECCLASS_HVM, HVM__PCILEVEL);
+    return current_has_perm(d, SECCLASS_HVM, HVM__PCILEVEL);
 }
 
 static int flask_hvm_set_isa_irq_level(struct domain *d)
 {
-    return domain_has_perm(current->domain, d, SECCLASS_HVM, HVM__IRQLEVEL);
+    return current_has_perm(d, SECCLASS_HVM, HVM__IRQLEVEL);
 }
 
 static int flask_hvm_set_pci_link_route(struct domain *d)
 {
-    return domain_has_perm(current->domain, d, SECCLASS_HVM, HVM__PCIROUTE);
+    return current_has_perm(d, SECCLASS_HVM, HVM__PCIROUTE);
 }
 
 static int flask_hvm_inject_msi(struct domain *d)
 {
-    return domain_has_perm(current->domain, d, SECCLASS_HVM, HVM__SEND_IRQ);
+    return current_has_perm(d, SECCLASS_HVM, HVM__SEND_IRQ);
 }
 
 static int flask_mem_event(struct domain *d)
 {
-    return domain_has_perm(current->domain, d, SECCLASS_HVM, HVM__MEM_EVENT);
+    return current_has_perm(d, SECCLASS_HVM, HVM__MEM_EVENT);
 }
 
 static int flask_mem_sharing(struct domain *d)
 {
-    return domain_has_perm(current->domain, d, SECCLASS_HVM, HVM__MEM_SHARING);
+    return current_has_perm(d, SECCLASS_HVM, HVM__MEM_SHARING);
 }
 
 static int flask_apic(struct domain *d, int cmd)
@@ -1353,11 +1344,7 @@ static int flask_physinfo(void)
 
 static int flask_platform_quirk(uint32_t quirk)
 {
-    struct domain_security_struct *dsec;
-    dsec = current->domain->ssid;
-
-    return avc_has_perm(dsec->sid, SECINITSID_XEN, SECCLASS_XEN, 
-                        XEN__QUIRK, NULL);
+    return avc_current_has_perm(SECINITSID_XEN, SECCLASS_XEN, XEN__QUIRK, NULL);
 }
 
 static int flask_platform_op(uint32_t op)
@@ -1419,16 +1406,12 @@ static int flask_getidletime(void)
 
 static int flask_machine_memory_map(void)
 {
-    struct domain_security_struct *dsec;
-    dsec = current->domain->ssid;
-
-    return avc_has_perm(dsec->sid, SECINITSID_XEN, SECCLASS_MMU, 
-                        MMU__MEMORYMAP, NULL);
+    return avc_current_has_perm(SECINITSID_XEN, SECCLASS_MMU, MMU__MEMORYMAP, NULL);
 }
 
 static int flask_domain_memory_map(struct domain *d)
 {
-    return domain_has_perm(current->domain, d, SECCLASS_MMU, MMU__MEMORYMAP);
+    return current_has_perm(d, SECCLASS_MMU, MMU__MEMORYMAP);
 }
 
 static int domain_memory_perm(struct domain *d, struct domain *f, l1_pgentry_t pte)
@@ -1451,17 +1434,17 @@ static int domain_memory_perm(struct domain *d, struct domain *f, l1_pgentry_t p
     if ( f->domain_id == DOMID_IO || !mfn_valid(fmfn) )
     {
         struct avc_audit_data ad;
-        struct domain_security_struct *dsec = d->ssid;
-        u32 fsid;
+        u32 dsid, fsid;
+        rc = security_iomem_sid(fmfn, &fsid);
+        if ( rc )
+            return rc;
         AVC_AUDIT_DATA_INIT(&ad, MEMORY);
         ad.sdom = d;
         ad.tdom = f;
         ad.memory.pte = pte.l1;
         ad.memory.mfn = fmfn;
-        rc = security_iomem_sid(fmfn, &fsid);
-        if ( rc )
-            return rc;
-        return avc_has_perm(dsec->sid, fsid, SECCLASS_MMU, map_perms, &ad);
+        dsid = domain_sid(d);
+        return avc_has_perm(dsid, fsid, SECCLASS_MMU, map_perms, &ad);
     }
 
     return domain_has_perm(d, f, SECCLASS_MMU, map_perms);
@@ -1504,43 +1487,40 @@ static int flask_remove_from_physmap(struct domain *d1, struct domain *d2)
 
 static int flask_sendtrigger(struct domain *d)
 {
-    return domain_has_perm(current->domain, d, SECCLASS_DOMAIN, DOMAIN__TRIGGER);
+    return current_has_perm(d, SECCLASS_DOMAIN, DOMAIN__TRIGGER);
 }
 
 static int flask_get_device_group(uint32_t machine_bdf)
 {
     u32 rsid;
     int rc = -EPERM;
-    struct domain_security_struct *ssec = current->domain->ssid;
 
     rc = security_device_sid(machine_bdf, &rsid);
     if ( rc )
         return rc;
 
-    return avc_has_perm(ssec->sid, rsid, SECCLASS_RESOURCE, RESOURCE__STAT_DEVICE, NULL);
+    return avc_current_has_perm(rsid, SECCLASS_RESOURCE, RESOURCE__STAT_DEVICE, NULL);
 }
 
 static int flask_test_assign_device(uint32_t machine_bdf)
 {
     u32 rsid;
     int rc = -EPERM;
-    struct domain_security_struct *ssec = current->domain->ssid;
 
     rc = security_device_sid(machine_bdf, &rsid);
     if ( rc )
         return rc;
 
-    return rc = avc_has_perm(ssec->sid, rsid, SECCLASS_RESOURCE, RESOURCE__STAT_DEVICE, NULL);
+    return avc_current_has_perm(rsid, SECCLASS_RESOURCE, RESOURCE__STAT_DEVICE, NULL);
 }
 
 static int flask_assign_device(struct domain *d, uint32_t machine_bdf)
 {
-    u32 rsid;
+    u32 dsid, rsid;
     int rc = -EPERM;
-    struct domain_security_struct *ssec, *tsec;
     struct avc_audit_data ad;
 
-    rc = domain_has_perm(current->domain, d, SECCLASS_RESOURCE, RESOURCE__ADD);
+    rc = current_has_perm(d, SECCLASS_RESOURCE, RESOURCE__ADD);
     if ( rc )
         return rc;
 
@@ -1550,22 +1530,20 @@ static int flask_assign_device(struct domain *d, uint32_t machine_bdf)
 
     AVC_AUDIT_DATA_INIT(&ad, DEV);
     ad.device = (unsigned long) machine_bdf;
-    ssec = current->domain->ssid;
-    rc = avc_has_perm(ssec->sid, rsid, SECCLASS_RESOURCE, RESOURCE__ADD_DEVICE, &ad);
+    rc = avc_current_has_perm(rsid, SECCLASS_RESOURCE, RESOURCE__ADD_DEVICE, &ad);
     if ( rc )
         return rc;
 
-    tsec = d->ssid;
-    return avc_has_perm(tsec->sid, rsid, SECCLASS_RESOURCE, RESOURCE__USE, &ad);
+    dsid = domain_sid(d);
+    return avc_has_perm(dsid, rsid, SECCLASS_RESOURCE, RESOURCE__USE, &ad);
 }
 
 static int flask_deassign_device(struct domain *d, uint32_t machine_bdf)
 {
     u32 rsid;
     int rc = -EPERM;
-    struct domain_security_struct *ssec = current->domain->ssid;
 
-    rc = domain_has_perm(current->domain, d, SECCLASS_RESOURCE, RESOURCE__REMOVE);
+    rc = current_has_perm(d, SECCLASS_RESOURCE, RESOURCE__REMOVE);
     if ( rc )
         return rc;
 
@@ -1573,18 +1551,17 @@ static int flask_deassign_device(struct domain *d, uint32_t machine_bdf)
     if ( rc )
         return rc;
 
-    return rc = avc_has_perm(ssec->sid, rsid, SECCLASS_RESOURCE, RESOURCE__REMOVE_DEVICE, NULL);
+    return avc_current_has_perm(rsid, SECCLASS_RESOURCE, RESOURCE__REMOVE_DEVICE, NULL);
 }
 
 static int flask_bind_pt_irq (struct domain *d, struct xen_domctl_bind_pt_irq *bind)
 {
-    u32 rsid;
+    u32 dsid, rsid;
     int rc = -EPERM;
     int irq;
-    struct domain_security_struct *ssec, *tsec;
     struct avc_audit_data ad;
 
-    rc = domain_has_perm(current->domain, d, SECCLASS_RESOURCE, RESOURCE__ADD);
+    rc = current_has_perm(d, SECCLASS_RESOURCE, RESOURCE__ADD);
     if ( rc )
         return rc;
 
@@ -1594,23 +1571,22 @@ static int flask_bind_pt_irq (struct domain *d, struct xen_domctl_bind_pt_irq *b
     if ( rc )
         return rc;
 
-    ssec = current->domain->ssid;
-    rc = avc_has_perm(ssec->sid, rsid, SECCLASS_HVM, HVM__BIND_IRQ, &ad);
+    rc = avc_current_has_perm(rsid, SECCLASS_HVM, HVM__BIND_IRQ, &ad);
     if ( rc )
         return rc;
 
-    tsec = d->ssid;
-    return avc_has_perm(tsec->sid, rsid, SECCLASS_RESOURCE, RESOURCE__USE, &ad);
+    dsid = domain_sid(d);
+    return avc_has_perm(dsid, rsid, SECCLASS_RESOURCE, RESOURCE__USE, &ad);
 }
 
 static int flask_unbind_pt_irq (struct domain *d, struct xen_domctl_bind_pt_irq *bind)
 {
-    return domain_has_perm(current->domain, d, SECCLASS_RESOURCE, RESOURCE__REMOVE);
+    return current_has_perm(d, SECCLASS_RESOURCE, RESOURCE__REMOVE);
 }
 
 static int flask_pin_mem_cacheattr (struct domain *d)
 {
-    return domain_has_perm(current->domain, d, SECCLASS_HVM, HVM__CACHEATTR);
+    return current_has_perm(d, SECCLASS_HVM, HVM__CACHEATTR);
 }
 
 static int flask_ext_vcpucontext (struct domain *d, uint32_t cmd)
@@ -1629,7 +1605,7 @@ static int flask_ext_vcpucontext (struct domain *d, uint32_t cmd)
         return -EPERM;
     }
 
-    return domain_has_perm(current->domain, d, SECCLASS_DOMAIN, perm);
+    return current_has_perm(d, SECCLASS_DOMAIN, perm);
 }
 
 static int flask_vcpuextstate (struct domain *d, uint32_t cmd)
@@ -1648,7 +1624,7 @@ static int flask_vcpuextstate (struct domain *d, uint32_t cmd)
             return -EPERM;
     }
 
-    return domain_has_perm(current->domain, d, SECCLASS_DOMAIN, perm);
+    return current_has_perm(d, SECCLASS_DOMAIN, perm);
 }
 #endif
 
diff --git a/xen/xsm/flask/include/objsec.h b/xen/xsm/flask/include/objsec.h
index 4ff52be..6595dc3 100644
--- a/xen/xsm/flask/include/objsec.h
+++ b/xen/xsm/flask/include/objsec.h
@@ -19,6 +19,8 @@
 
 struct domain_security_struct {
     u32 sid;               /* current SID */
+    u32 self_sid;          /* SID for target when operating on DOMID_SELF */
+    u32 target_sid;        /* SID for device model target domain */
 };
 
 struct evtchn_security_struct {
-- 
1.7.11.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 12 16:00:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Sep 2012 16:00:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TBpMG-0005qY-11; Wed, 12 Sep 2012 16:00:08 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1TBpMC-0005PB-Ks
	for xen-devel@lists.xen.org; Wed, 12 Sep 2012 16:00:04 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-5.tower-27.messagelabs.com!1347465597!7348032!1
X-Originating-IP: [63.239.67.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12354 invoked from network); 12 Sep 2012 15:59:58 -0000
Received: from emvm-gh1-uea09.nsa.gov (HELO nsa.gov) (63.239.67.10)
	by server-5.tower-27.messagelabs.com with SMTP;
	12 Sep 2012 15:59:58 -0000
X-TM-IMSS-Message-ID: <39e12935001083e0@nsa.gov>
Received: from tarius.tycho.ncsc.mil ([144.51.3.1]) by nsa.gov
	([63.239.67.10]) with ESMTP (TREND IMSS SMTP Service 7.1) id
	39e12935001083e0 ; Wed, 12 Sep 2012 12:02:04 -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 q8CFxoOV006669; 
	Wed, 12 Sep 2012 11:59:56 -0400
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xen.org
Date: Wed, 12 Sep 2012 11:59:45 -0400
Message-Id: <1347465586-20009-22-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.11.4
In-Reply-To: <1347465586-20009-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1347465586-20009-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: dgdegra@tycho.nsa.gov, Keir Fraser <keir@xen.org>
Subject: [Xen-devel] [PATCH 21/22] xen: Add XSM hook for XENMEM_exchange
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Cc: Keir Fraser <keir@xen.org>
---
 tools/flask/policy/policy/flask/access_vectors |  1 +
 tools/flask/policy/policy/modules/xen/xen.if   |  2 ++
 xen/common/memory.c                            | 12 +++++++++++-
 xen/include/xsm/dummy.h                        |  7 +++++++
 xen/include/xsm/xsm.h                          |  6 ++++++
 xen/xsm/dummy.c                                |  1 +
 xen/xsm/flask/hooks.c                          |  6 ++++++
 xen/xsm/flask/include/av_perm_to_string.h      |  1 +
 xen/xsm/flask/include/av_permissions.h         |  1 +
 9 files changed, 36 insertions(+), 1 deletion(-)

diff --git a/tools/flask/policy/policy/flask/access_vectors b/tools/flask/policy/policy/flask/access_vectors
index 8324725..caf65d2 100644
--- a/tools/flask/policy/policy/flask/access_vectors
+++ b/tools/flask/policy/policy/flask/access_vectors
@@ -142,6 +142,7 @@ class mmu
     memorymap
     remote_remap
 	mmuext_op
+	exchange
 }
 
 class shadow
diff --git a/tools/flask/policy/policy/modules/xen/xen.if b/tools/flask/policy/policy/modules/xen/xen.if
index 725d7a1..67f5daf 100644
--- a/tools/flask/policy/policy/modules/xen/xen.if
+++ b/tools/flask/policy/policy/modules/xen/xen.if
@@ -30,6 +30,7 @@ define(`declare_domain', `
 #   containing at most one domain. This is not enforced by policy.
 define(`declare_singleton_domain', `
 	type $1, domain_type`'ifelse(`$#', `1', `', `,shift($@)');
+	define(`$1_self', `$1')
 	type $1_channel, event_type;
 	type_transition $1 domain_type:event $1_channel;
 	declare_domain_common($1, $1)
@@ -161,6 +162,7 @@ define(`make_device_model', `
 # use_device(domain, device)
 #   Allow a device to be used by a domain
 define(`use_device', `
+    allow $1 $1_self:mmu exchange;
     allow $1 $2:resource use;
     allow $1 $2:mmu { map_read map_write };
 ')
diff --git a/xen/common/memory.c b/xen/common/memory.c
index cfdd63f..a5b548b 100644
--- a/xen/common/memory.c
+++ b/xen/common/memory.c
@@ -329,9 +329,19 @@ static long memory_exchange(XEN_GUEST_HANDLE(xen_memory_exchange_t) arg)
         out_chunk_order = exch.in.extent_order - exch.out.extent_order;
     }
 
-    rc = rcu_lock_target_domain_by_id(exch.in.domid, &d);
+    d = rcu_lock_domain_by_any_id(exch.in.domid);
+    if ( d == NULL )
+    {
+        rc = -ESRCH;
+        goto fail_early;
+    }
+
+    rc = xsm_memory_exchange(d);
     if ( rc )
+    {
+        rcu_unlock_domain(d);
         goto fail_early;
+    }
 
     memflags |= MEMF_bits(domain_clamp_alloc_bitsize(
         d,
diff --git a/xen/include/xsm/dummy.h b/xen/include/xsm/dummy.h
index 9c13d5c037..e5e8020 100644
--- a/xen/include/xsm/dummy.h
+++ b/xen/include/xsm/dummy.h
@@ -235,6 +235,13 @@ static XSM_DEFAULT(int, grant_query_size) (struct domain *d1, struct domain *d2)
     return 0;
 }
 
+static XSM_DEFAULT(int, memory_exchange) (struct domain *d)
+{
+    if ( d != current->domain && !IS_PRIV_FOR(current->domain, d) )
+        return -EPERM;
+    return 0;
+}
+
 static XSM_DEFAULT(int, memory_adjust_reservation) (struct domain *d1,
                                                             struct domain *d2)
 {
diff --git a/xen/include/xsm/xsm.h b/xen/include/xsm/xsm.h
index 6d970b1..46d5cd6 100644
--- a/xen/include/xsm/xsm.h
+++ b/xen/include/xsm/xsm.h
@@ -96,6 +96,7 @@ struct xsm_operations {
 
     int (*get_pod_target) (struct domain *d);
     int (*set_pod_target) (struct domain *d);
+    int (*memory_exchange) (struct domain *d);
     int (*memory_adjust_reservation) (struct domain *d1, struct domain *d2);
     int (*memory_stat_reservation) (struct domain *d1, struct domain *d2);
     int (*memory_pin_page) (struct domain *d1, struct domain *d2, struct page_info *page);
@@ -451,6 +452,11 @@ static inline int xsm_set_pod_target (struct domain *d)
     return xsm_ops->set_pod_target(d);
 }
 
+static inline int xsm_memory_exchange (struct domain *d)
+{
+    return xsm_ops->memory_exchange(d);
+}
+
 static inline int xsm_memory_adjust_reservation (struct domain *d1, struct
                                                                     domain *d2)
 {
diff --git a/xen/xsm/dummy.c b/xen/xsm/dummy.c
index 9476be6..ddaf40b 100644
--- a/xen/xsm/dummy.c
+++ b/xen/xsm/dummy.c
@@ -83,6 +83,7 @@ void xsm_fixup_ops (struct xsm_operations *ops)
     set_to_dummy_if_null(ops, get_pod_target);
     set_to_dummy_if_null(ops, set_pod_target);
 
+    set_to_dummy_if_null(ops, memory_exchange);
     set_to_dummy_if_null(ops, memory_adjust_reservation);
     set_to_dummy_if_null(ops, memory_stat_reservation);
     set_to_dummy_if_null(ops, memory_pin_page);
diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
index bd2d792..2f33a9f 100644
--- a/xen/xsm/flask/hooks.c
+++ b/xen/xsm/flask/hooks.c
@@ -396,6 +396,11 @@ static int flask_set_pod_target(struct domain *d)
     return current_has_perm(d, SECCLASS_DOMAIN, DOMAIN__SETPODTARGET);
 }
 
+static int flask_memory_exchange(struct domain *d)
+{
+    return current_has_perm(d, SECCLASS_MMU, MMU__EXCHANGE);
+}
+
 static int flask_memory_adjust_reservation(struct domain *d1, struct domain *d2)
 {
     return domain_has_perm(d1, d2, SECCLASS_MMU, MMU__ADJUST);
@@ -1683,6 +1688,7 @@ static struct xsm_operations flask_ops = {
 
     .get_pod_target = flask_get_pod_target,
     .set_pod_target = flask_set_pod_target,
+    .memory_exchange = flask_memory_exchange,
     .memory_adjust_reservation = flask_memory_adjust_reservation,
     .memory_stat_reservation = flask_memory_stat_reservation,
     .memory_pin_page = flask_memory_pin_page,
diff --git a/xen/xsm/flask/include/av_perm_to_string.h b/xen/xsm/flask/include/av_perm_to_string.h
index 8f65b96..79d5939 100644
--- a/xen/xsm/flask/include/av_perm_to_string.h
+++ b/xen/xsm/flask/include/av_perm_to_string.h
@@ -112,6 +112,7 @@
    S_(SECCLASS_MMU, MMU__MEMORYMAP, "memorymap")
    S_(SECCLASS_MMU, MMU__REMOTE_REMAP, "remote_remap")
    S_(SECCLASS_MMU, MMU__MMUEXT_OP, "mmuext_op")
+   S_(SECCLASS_MMU, MMU__EXCHANGE, "exchange")
    S_(SECCLASS_SHADOW, SHADOW__DISABLE, "disable")
    S_(SECCLASS_SHADOW, SHADOW__ENABLE, "enable")
    S_(SECCLASS_SHADOW, SHADOW__LOGDIRTY, "logdirty")
diff --git a/xen/xsm/flask/include/av_permissions.h b/xen/xsm/flask/include/av_permissions.h
index 18454fd..d982328 100644
--- a/xen/xsm/flask/include/av_permissions.h
+++ b/xen/xsm/flask/include/av_permissions.h
@@ -118,6 +118,7 @@
 #define MMU__MEMORYMAP                            0x00000800UL
 #define MMU__REMOTE_REMAP                         0x00001000UL
 #define MMU__MMUEXT_OP                            0x00002000UL
+#define MMU__EXCHANGE                             0x00004000UL
 
 #define SHADOW__DISABLE                           0x00000001UL
 #define SHADOW__ENABLE                            0x00000002UL
-- 
1.7.11.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 12 16:00:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Sep 2012 16:00:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TBpM7-0005PI-E7; Wed, 12 Sep 2012 15:59:59 +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 1TBpM5-0005Mj-QS
	for xen-devel@lists.xen.org; Wed, 12 Sep 2012 15:59:58 +0000
Received: from [85.158.138.51:26987] by server-9.bemta-3.messagelabs.com id
	7E/B3-15390-D71B0505; Wed, 12 Sep 2012 15:59:57 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-11.tower-174.messagelabs.com!1347465596!30178142!1
X-Originating-IP: [63.239.67.9]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22667 invoked from network); 12 Sep 2012 15:59:56 -0000
Received: from emvm-gh1-uea08.nsa.gov (HELO nsa.gov) (63.239.67.9)
	by server-11.tower-174.messagelabs.com with SMTP;
	12 Sep 2012 15:59:56 -0000
X-TM-IMSS-Message-ID: <39e1655a0010234a@nsa.gov>
Received: from tarius.tycho.ncsc.mil ([144.51.3.1]) by nsa.gov ([63.239.67.9])
	with ESMTP (TREND IMSS SMTP Service 7.1) id 39e1655a0010234a ;
	Wed, 12 Sep 2012 11:59:46 -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 q8CFxoOP006669; 
	Wed, 12 Sep 2012 11:59:54 -0400
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xen.org
Date: Wed, 12 Sep 2012 11:59:39 -0400
Message-Id: <1347465586-20009-16-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.11.4
In-Reply-To: <1347465586-20009-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1347465586-20009-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: dgdegra@tycho.nsa.gov
Subject: [Xen-devel] [PATCH 15/22] xen: convert do_sysctl to use 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

The xsm_sysctl hook now covers every sysctl, in addition to the more
fine-grained XSM hooks in most sub-functions.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 xen/common/sysctl.c     |  7 ++++---
 xen/include/xsm/dummy.h |  7 +++++++
 xen/include/xsm/xsm.h   |  6 ++++++
 xen/xsm/dummy.c         |  1 +
 xen/xsm/flask/hooks.c   | 31 +++++++++++++++++++++++++++++++
 5 files changed, 49 insertions(+), 3 deletions(-)

diff --git a/xen/common/sysctl.c b/xen/common/sysctl.c
index ea68278..e009baa 100644
--- a/xen/common/sysctl.c
+++ b/xen/common/sysctl.c
@@ -33,15 +33,16 @@ long do_sysctl(XEN_GUEST_HANDLE(xen_sysctl_t) u_sysctl)
     struct xen_sysctl curop, *op = &curop;
     static DEFINE_SPINLOCK(sysctl_lock);
 
-    if ( !IS_PRIV(current->domain) )
-        return -EPERM;
-
     if ( copy_from_guest(op, u_sysctl, 1) )
         return -EFAULT;
 
     if ( op->interface_version != XEN_SYSCTL_INTERFACE_VERSION )
         return -EACCES;
 
+    ret = xsm_sysctl(op->cmd);
+    if ( ret )
+        return ret;
+
     /*
      * Trylock here avoids deadlock with an existing sysctl critical section
      * which might (for some current or future reason) want to synchronise
diff --git a/xen/include/xsm/dummy.h b/xen/include/xsm/dummy.h
index 6aa6aea..a9784f5 100644
--- a/xen/include/xsm/dummy.h
+++ b/xen/include/xsm/dummy.h
@@ -106,6 +106,13 @@ static XSM_DEFAULT(int, domctl)(struct domain *d, int cmd)
     return 0;
 }
 
+static XSM_DEFAULT(int, sysctl)(int cmd)
+{
+    if ( !IS_PRIV(current->domain) )
+        return -EPERM;
+    return 0;
+}
+
 static XSM_DEFAULT(int, set_virq_handler)(struct domain *d, uint32_t virq)
 {
     return 0;
diff --git a/xen/include/xsm/xsm.h b/xen/include/xsm/xsm.h
index 171acb2..ef3329f 100644
--- a/xen/include/xsm/xsm.h
+++ b/xen/include/xsm/xsm.h
@@ -58,6 +58,7 @@ struct xsm_operations {
     int (*domain_settime) (struct domain *d);
     int (*set_target) (struct domain *d, struct domain *e);
     int (*domctl) (struct domain *d, int cmd);
+    int (*sysctl) (int cmd);
     int (*set_virq_handler) (struct domain *d, uint32_t virq);
     int (*tbufcontrol) (void);
     int (*readconsole) (uint32_t clear);
@@ -265,6 +266,11 @@ static inline int xsm_domctl (struct domain *d, int cmd)
     return xsm_ops->domctl(d, cmd);
 }
 
+static inline int xsm_sysctl (int cmd)
+{
+    return xsm_ops->sysctl(cmd);
+}
+
 static inline int xsm_set_virq_handler (struct domain *d, uint32_t virq)
 {
     return xsm_ops->set_virq_handler(d, virq);
diff --git a/xen/xsm/dummy.c b/xen/xsm/dummy.c
index 7f9c753..c76212d 100644
--- a/xen/xsm/dummy.c
+++ b/xen/xsm/dummy.c
@@ -44,6 +44,7 @@ void xsm_fixup_ops (struct xsm_operations *ops)
     set_to_dummy_if_null(ops, domain_settime);
     set_to_dummy_if_null(ops, set_target);
     set_to_dummy_if_null(ops, domctl);
+    set_to_dummy_if_null(ops, sysctl);
     set_to_dummy_if_null(ops, set_virq_handler);
     set_to_dummy_if_null(ops, tbufcontrol);
     set_to_dummy_if_null(ops, readconsole);
diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
index 6d03189..16af92b 100644
--- a/xen/xsm/flask/hooks.c
+++ b/xen/xsm/flask/hooks.c
@@ -675,6 +675,36 @@ static int flask_domctl(struct domain *d, int cmd)
     }
 }
 
+static int flask_sysctl(int cmd)
+{
+    switch ( cmd )
+    {
+    /* These have individual XSM hooks */
+    case XEN_SYSCTL_readconsole:
+    case XEN_SYSCTL_tbuf_op:
+    case XEN_SYSCTL_physinfo:
+    case XEN_SYSCTL_sched_id:
+    case XEN_SYSCTL_perfc_op:
+    case XEN_SYSCTL_getdomaininfolist:
+    case XEN_SYSCTL_debug_keys:
+    case XEN_SYSCTL_getcpuinfo:
+    case XEN_SYSCTL_availheap:
+    case XEN_SYSCTL_get_pmstat:
+    case XEN_SYSCTL_cpu_hotplug:
+    case XEN_SYSCTL_pm_op:
+    case XEN_SYSCTL_page_offline_op:
+    case XEN_SYSCTL_lockprof_op:
+    case XEN_SYSCTL_topologyinfo:
+    case XEN_SYSCTL_numainfo:
+    case XEN_SYSCTL_cpupool_op:
+    case XEN_SYSCTL_scheduler_op:
+        return 0;
+    default:
+        printk("flask_sysctl: Unknown op %d\n", cmd);
+        return -EPERM;
+    }
+}
+
 static int flask_set_virq_handler(struct domain *d, uint32_t virq)
 {
     return domain_has_perm(current->domain, d, SECCLASS_DOMAIN, DOMAIN__SET_VIRQ_HANDLER);
@@ -1601,6 +1631,7 @@ static struct xsm_operations flask_ops = {
     .domain_settime = flask_domain_settime,
     .set_target = flask_set_target,
     .domctl = flask_domctl,
+    .sysctl = flask_sysctl,
     .set_virq_handler = flask_set_virq_handler,
     .tbufcontrol = flask_tbufcontrol,
     .readconsole = flask_readconsole,
-- 
1.7.11.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 12 16:00:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Sep 2012 16:00:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TBpM6-0005Oj-Qp; Wed, 12 Sep 2012 15:59:58 +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 1TBpM4-0005N4-GK
	for xen-devel@lists.xen.org; Wed, 12 Sep 2012 15:59:56 +0000
Received: from [85.158.138.51:6819] by server-3.bemta-3.messagelabs.com id
	66/EC-21322-B71B0505; Wed, 12 Sep 2012 15:59:55 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-3.tower-174.messagelabs.com!1347465594!22112228!1
X-Originating-IP: [63.239.67.9]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10523 invoked from network); 12 Sep 2012 15:59:54 -0000
Received: from emvm-gh1-uea08.nsa.gov (HELO nsa.gov) (63.239.67.9)
	by server-3.tower-174.messagelabs.com with SMTP;
	12 Sep 2012 15:59:54 -0000
X-TM-IMSS-Message-ID: <39e15ca300102345@nsa.gov>
Received: from tarius.tycho.ncsc.mil ([144.51.3.1]) by nsa.gov ([63.239.67.9])
	with ESMTP (TREND IMSS SMTP Service 7.1) id 39e15ca300102345 ;
	Wed, 12 Sep 2012 11:59:44 -0400
Received: from moss-nexus.epoch.ncsc.mil (moss-nexus [144.51.25.48])
	by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id q8CFxoOG006669; 
	Wed, 12 Sep 2012 11:59:52 -0400
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xen.org
Date: Wed, 12 Sep 2012 11:59:30 -0400
Message-Id: <1347465586-20009-7-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.11.4
In-Reply-To: <1347465586-20009-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1347465586-20009-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: dgdegra@tycho.nsa.gov
Subject: [Xen-devel] [PATCH 06/22] flask/policy: Add domain relabel example
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This adds the nomigrate_t type to the example FLASK policy which allows
domains to be created that dom0 cannot access after building.

Example domain configuration snippet:
  seclabel='customer_1:vm_r:nomigrate_t'
  init_seclabel='customer_1:vm_r:nomigrate_t_building'

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 docs/misc/xsm-flask.txt                      |  2 +
 tools/flask/policy/policy/modules/xen/xen.if | 56 +++++++++++++++++++++-------
 tools/flask/policy/policy/modules/xen/xen.te | 10 +++++
 3 files changed, 55 insertions(+), 13 deletions(-)

diff --git a/docs/misc/xsm-flask.txt b/docs/misc/xsm-flask.txt
index 6b0d327..0778a28 100644
--- a/docs/misc/xsm-flask.txt
+++ b/docs/misc/xsm-flask.txt
@@ -60,6 +60,8 @@ that can be used without dom0 disaggregation. The main types for domUs are:
  - domU_t is a domain that can communicate with any other domU_t
  - isolated_domU_t can only communicate with dom0
  - prot_domU_t is a domain type whose creation can be disabled with a boolean
+ - nomigrate_t is a domain that must be created via the nomigrate_t_building
+   type, and whose memory cannot be read by dom0 once created
 
 HVM domains with stubdomain device models use two types (one per domain):
  - domHVM_t is an HVM domain that uses a stubdomain device model
diff --git a/tools/flask/policy/policy/modules/xen/xen.if b/tools/flask/policy/policy/modules/xen/xen.if
index 3f58909..2ad11b2 100644
--- a/tools/flask/policy/policy/modules/xen/xen.if
+++ b/tools/flask/policy/policy/modules/xen/xen.if
@@ -9,24 +9,47 @@
 #   Declare a type as a domain type, and allow basic domain setup
 define(`declare_domain', `
 	type $1, domain_type`'ifelse(`$#', `1', `', `,shift($@)');
+	type $1_channel, event_type;
+	type_transition $1 domain_type:event $1_channel;
 	allow $1 $1:grant { query setup };
 	allow $1 $1:mmu { adjust physmap map_read map_write stat pinpage };
 	allow $1 $1:hvm { getparam setparam };
 ')
 
-# create_domain(priv, target)
-#   Allow a domain to be created
-define(`create_domain', `
+# declare_build_label(type)
+#   Declare a paired _building type for the given domain type
+define(`declare_build_label', `
+	type $1_building, domain_type;
+	type_transition $1_building domain_type:event $1_channel;
+	allow $1_building $1 : domain transition;
+')
+
+define(`create_domain_common', `
 	allow $1 $2:domain { create max_vcpus setdomainmaxmem setaddrsize
-			getdomaininfo hypercall setvcpucontext scheduler
-			unpause getvcpuinfo getvcpuextstate getaddrsize
-			getvcpuaffinity };
+			getdomaininfo hypercall setvcpucontext setextvcpucontext
+			scheduler getvcpuinfo getvcpuextstate getaddrsize
+			getvcpuaffinity setvcpuaffinity };
 	allow $1 $2:security check_context;
 	allow $1 $2:shadow enable;
 	allow $1 $2:mmu {map_read map_write adjust memorymap physmap pinpage};
 	allow $1 $2:grant setup;
-	allow $1 $2:hvm { cacheattr getparam hvmctl irqlevel pciroute setparam pcilevel trackdirtyvram };
-	allow $1 $2_$1_channel:event create;
+	allow $1 $2:hvm { cacheattr getparam hvmctl irqlevel pciroute sethvmc setparam pcilevel trackdirtyvram };
+')
+
+# create_domain(priv, target)
+#   Allow a domain to be created directly
+define(`create_domain', `
+	create_domain_common($1, $2)
+	allow $1 $2_channel:event create;
+')
+
+# create_domain_build_label(priv, target)
+#   Allow a domain to be created via its domain build label
+define(`create_domain_build_label', `
+	create_domain_common($1, $2_building)
+	allow $1 $2_channel:event create;
+	allow $1 $2_building:domain2 relabelfrom;
+	allow $1 $2:domain2 relabelto;
 ')
 
 # manage_domain(priv, target)
@@ -37,6 +60,15 @@ define(`manage_domain', `
 			setvcpuaffinity setdomainmaxmem };
 ')
 
+# migrate_domain_out(priv, target)
+#   Allow creation of a snapshot or migration image from a domain
+#   (inbound migration is the same as domain creation)
+define(`migrate_domain_out', `
+	allow $1 $2:hvm { gethvmc getparam irqlevel };
+	allow $1 $2:mmu { stat pageinfo map_read };
+	allow $1 $2:domain { getaddrsize getvcpucontext getextvcpucontext getvcpuextstate pause destroy };
+')
+
 ################################################################################
 #
 # Inter-domain communication
@@ -47,8 +79,6 @@ define(`manage_domain', `
 #   This allows an event channel to be created from domains with labels
 #   <source> to <dest> and will label it <chan-label>
 define(`create_channel', `
-	type $3, event_type;
-	type_transition $1 $2:event $3;
 	allow $1 $3:event { create send status };
 	allow $3 $2:event { bind };
 ')
@@ -56,8 +86,8 @@ define(`create_channel', `
 # domain_event_comms(dom1, dom2)
 #   Allow two domain types to communicate using event channels
 define(`domain_event_comms', `
-	create_channel($1, $2, $1_$2_channel)
-	create_channel($2, $1, $2_$1_channel)
+	create_channel($1, $2, $1_channel)
+	create_channel($2, $1, $2_channel)
 ')
 
 # domain_comms(dom1, dom2)
@@ -72,7 +102,7 @@ define(`domain_comms', `
 #   Allow a domain types to communicate with others of its type using grants
 #   and event channels (this includes event channels to DOMID_SELF)
 define(`domain_self_comms', `
-	create_channel($1, $1, $1_self_channel)
+	create_channel($1, $1, $1_channel)
 	allow $1 $1:grant { map_read map_write copy unmap };
 ')
 
diff --git a/tools/flask/policy/policy/modules/xen/xen.te b/tools/flask/policy/policy/modules/xen/xen.te
index 9550397..1162153 100644
--- a/tools/flask/policy/policy/modules/xen/xen.te
+++ b/tools/flask/policy/policy/modules/xen/xen.te
@@ -90,6 +90,7 @@ create_domain(dom0_t, isolated_domU_t)
 manage_domain(dom0_t, isolated_domU_t)
 domain_comms(dom0_t, isolated_domU_t)
 
+# Declare a boolean that denies creation of prot_domU_t domains
 gen_bool(prot_doms_locked, false)
 declare_domain(prot_domU_t)
 if (!prot_doms_locked) {
@@ -111,6 +112,15 @@ manage_domain(dom0_t, dm_dom_t)
 domain_comms(dom0_t, dm_dom_t)
 device_model(dm_dom_t, domHVM_t)
 
+# nomigrate_t must be built via the nomigrate_t_building label; once built,
+# dom0 cannot read its memory.
+declare_domain(nomigrate_t)
+declare_build_label(nomigrate_t)
+create_domain_build_label(dom0_t, nomigrate_t)
+manage_domain(dom0_t, nomigrate_t)
+domain_comms(dom0_t, nomigrate_t)
+domain_self_comms(nomigrate_t)
+
 ###############################################################################
 #
 # Device delegation
-- 
1.7.11.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 12 16:00:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Sep 2012 16:00:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TBpM6-0005OT-BF; Wed, 12 Sep 2012 15:59:58 +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 1TBpM4-0005N3-HO
	for xen-devel@lists.xen.org; Wed, 12 Sep 2012 15:59:56 +0000
Received: from [85.158.138.51:6820] by server-8.bemta-3.messagelabs.com id
	43/53-24700-B71B0505; Wed, 12 Sep 2012 15:59:55 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-6.tower-174.messagelabs.com!1347465594!22162533!1
X-Originating-IP: [63.239.67.9]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8374 invoked from network); 12 Sep 2012 15:59:54 -0000
Received: from emvm-gh1-uea08.nsa.gov (HELO nsa.gov) (63.239.67.9)
	by server-6.tower-174.messagelabs.com with SMTP;
	12 Sep 2012 15:59:54 -0000
X-TM-IMSS-Message-ID: <39e15d9d00102346@nsa.gov>
Received: from tarius.tycho.ncsc.mil ([144.51.3.1]) by nsa.gov ([63.239.67.9])
	with ESMTP (TREND IMSS SMTP Service 7.1) id 39e15d9d00102346 ;
	Wed, 12 Sep 2012 11:59:44 -0400
Received: from moss-nexus.epoch.ncsc.mil (moss-nexus [144.51.25.48])
	by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id q8CFxoOH006669; 
	Wed, 12 Sep 2012 11:59:52 -0400
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xen.org
Date: Wed, 12 Sep 2012 11:59:31 -0400
Message-Id: <1347465586-20009-8-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.11.4
In-Reply-To: <1347465586-20009-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1347465586-20009-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: dgdegra@tycho.nsa.gov, Keir Fraser <keir@xen.org>,
	Jan Beulich <jbeulich@suse.com>
Subject: [Xen-devel] [PATCH 07/22] arch/x86: add distinct XSM hooks for
	map/unmap
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 xsm_iomem_permission and xsm_ioport_permission hooks are intended to
be called by the domain builder, while the calls in arch/x86/domctl.c
which control mapping are also performed by the device model. Because of
this, they should not use the same XSM hooks.

This also adds a missing XSM hook in the unbind IRQ domctl.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Cc: Keir Fraser <keir@xen.org>
Cc: Jan Beulich <jbeulich@suse.com>
---
 xen/arch/x86/domctl.c  |  8 ++++++--
 xen/arch/x86/physdev.c |  2 +-
 xen/include/xsm/xsm.h  | 25 ++++++++++++++++++++++---
 xen/xsm/dummy.c        | 20 +++++++++++++++++++-
 xen/xsm/flask/hooks.c  | 42 ++++++++++++++++++++----------------------
 5 files changed, 68 insertions(+), 29 deletions(-)

diff --git a/xen/arch/x86/domctl.c b/xen/arch/x86/domctl.c
index 7a89040..9eebd3b 100644
--- a/xen/arch/x86/domctl.c
+++ b/xen/arch/x86/domctl.c
@@ -805,6 +805,10 @@ long arch_do_domctl(
              !irq_access_permitted(current->domain, bind->machine_irq) )
             goto unbind_out;
 
+        ret = xsm_unbind_pt_irq(d, bind);
+        if ( ret )
+            goto unbind_out;
+
         if ( iommu_enabled )
         {
             spin_lock(&pcidevs_lock);
@@ -842,7 +846,7 @@ long arch_do_domctl(
         if ( unlikely((d = rcu_lock_domain_by_id(domctl->domain)) == NULL) )
             break;
 
-        ret = xsm_iomem_permission(d, mfn, mfn + nr_mfns - 1, add);
+        ret = xsm_iomem_mapping(d, mfn, mfn + nr_mfns - 1, add);
         if ( ret ) {
             rcu_unlock_domain(d);
             break;
@@ -904,7 +908,7 @@ long arch_do_domctl(
         if ( unlikely((d = rcu_lock_domain_by_id(domctl->domain)) == NULL) )
             break;
 
-        ret = xsm_ioport_permission(d, fmp, fmp + np - 1, add);
+        ret = xsm_ioport_mapping(d, fmp, fmp + np - 1, add);
         if ( ret ) {
             rcu_unlock_domain(d);
             break;
diff --git a/xen/arch/x86/physdev.c b/xen/arch/x86/physdev.c
index 984c813..13b85da 100644
--- a/xen/arch/x86/physdev.c
+++ b/xen/arch/x86/physdev.c
@@ -242,7 +242,7 @@ int physdev_unmap_pirq(domid_t domid, int pirq)
     if ( !IS_PRIV_FOR(current->domain, d) )
         goto free_domain;
 
-    ret = xsm_irq_permission(d, domain_pirq_to_irq(d, pirq), 0);
+    ret = xsm_unmap_domain_pirq(d, domain_pirq_to_irq(d, pirq));
     if ( ret )
         goto free_domain;
 
diff --git a/xen/include/xsm/xsm.h b/xen/include/xsm/xsm.h
index 593cdbd..cbbe673 100644
--- a/xen/include/xsm/xsm.h
+++ b/xen/include/xsm/xsm.h
@@ -117,8 +117,10 @@ struct xsm_operations {
 
     char *(*show_irq_sid) (int irq);
     int (*map_domain_pirq) (struct domain *d, int irq, void *data);
+    int (*unmap_domain_pirq) (struct domain *d, int irq);
     int (*irq_permission) (struct domain *d, int pirq, uint8_t allow);
     int (*iomem_permission) (struct domain *d, uint64_t s, uint64_t e, uint8_t allow);
+    int (*iomem_mapping) (struct domain *d, uint64_t s, uint64_t e, uint8_t allow);
     int (*pci_config_permission) (struct domain *d, uint32_t machine_bdf, uint16_t start, uint16_t end, uint8_t access);
 
     int (*get_device_group) (uint32_t machine_bdf);
@@ -176,11 +178,12 @@ struct xsm_operations {
     int (*add_to_physmap) (struct domain *d1, struct domain *d2);
     int (*sendtrigger) (struct domain *d);
     int (*bind_pt_irq) (struct domain *d, struct xen_domctl_bind_pt_irq *bind);
-    int (*unbind_pt_irq) (struct domain *d);
+    int (*unbind_pt_irq) (struct domain *d, struct xen_domctl_bind_pt_irq *bind);
     int (*pin_mem_cacheattr) (struct domain *d);
     int (*ext_vcpucontext) (struct domain *d, uint32_t cmd);
     int (*vcpuextstate) (struct domain *d, uint32_t cmd);
     int (*ioport_permission) (struct domain *d, uint32_t s, uint32_t e, uint8_t allow);
+    int (*ioport_mapping) (struct domain *d, uint32_t s, uint32_t e, uint8_t allow);
 #endif
 };
 
@@ -495,6 +498,11 @@ static inline int xsm_map_domain_pirq (struct domain *d, int irq, void *data)
     return xsm_call(map_domain_pirq(d, irq, data));
 }
 
+static inline int xsm_unmap_domain_pirq (struct domain *d, int irq)
+{
+    return xsm_call(unmap_domain_pirq(d, irq));
+}
+
 static inline int xsm_irq_permission (struct domain *d, int pirq, uint8_t allow)
 {
     return xsm_call(irq_permission(d, pirq, allow));
@@ -505,6 +513,11 @@ static inline int xsm_iomem_permission (struct domain *d, uint64_t s, uint64_t e
     return xsm_call(iomem_permission(d, s, e, allow));
 }
 
+static inline int xsm_iomem_mapping (struct domain *d, uint64_t s, uint64_t e, uint8_t allow)
+{
+    return xsm_call(iomem_mapping(d, s, e, allow));
+}
+
 static inline int xsm_pci_config_permission (struct domain *d, uint32_t machine_bdf, uint16_t start, uint16_t end, uint8_t access)
 {
     return xsm_call(pci_config_permission(d, machine_bdf, start, end, access));
@@ -781,9 +794,10 @@ static inline int xsm_bind_pt_irq(struct domain *d,
     return xsm_call(bind_pt_irq(d, bind));
 }
 
-static inline int xsm_unbind_pt_irq(struct domain *d)
+static inline int xsm_unbind_pt_irq(struct domain *d,
+                                                struct xen_domctl_bind_pt_irq *bind)
 {
-    return xsm_call(unbind_pt_irq(d));
+    return xsm_call(unbind_pt_irq(d, bind));
 }
 
 static inline int xsm_pin_mem_cacheattr(struct domain *d)
@@ -804,6 +818,11 @@ static inline int xsm_ioport_permission (struct domain *d, uint32_t s, uint32_t
 {
     return xsm_call(ioport_permission(d, s, e, allow));
 }
+
+static inline int xsm_ioport_mapping (struct domain *d, uint32_t s, uint32_t e, uint8_t allow)
+{
+    return xsm_call(ioport_mapping(d, s, e, allow));
+}
 #endif /* CONFIG_X86 */
 
 extern struct xsm_operations dummy_xsm_ops;
diff --git a/xen/xsm/dummy.c b/xen/xsm/dummy.c
index 4836fc0..a5dbfe7 100644
--- a/xen/xsm/dummy.c
+++ b/xen/xsm/dummy.c
@@ -395,6 +395,11 @@ static int dummy_map_domain_pirq (struct domain *d, int irq, void *data)
     return 0;
 }
 
+static int dummy_unmap_domain_pirq (struct domain *d, int irq)
+{
+    return 0;
+}
+
 static int dummy_irq_permission (struct domain *d, int pirq, uint8_t allow)
 {
     return 0;
@@ -405,6 +410,11 @@ static int dummy_iomem_permission (struct domain *d, uint64_t s, uint64_t e, uin
     return 0;
 }
 
+static int dummy_iomem_mapping (struct domain *d, uint64_t s, uint64_t e, uint8_t allow)
+{
+    return 0;
+}
+
 static int dummy_pci_config_permission (struct domain *d, uint32_t machine_bdf,
                                         uint16_t start, uint16_t end,
                                         uint8_t access)
@@ -585,7 +595,7 @@ static int dummy_bind_pt_irq (struct domain *d, struct xen_domctl_bind_pt_irq *b
     return 0;
 }
 
-static int dummy_unbind_pt_irq (struct domain *d)
+static int dummy_unbind_pt_irq (struct domain *d, struct xen_domctl_bind_pt_irq *bind)
 {
     return 0;
 }
@@ -609,6 +619,11 @@ static int dummy_ioport_permission (struct domain *d, uint32_t s, uint32_t e, ui
 {
     return 0;
 }
+
+static int dummy_ioport_mapping (struct domain *d, uint32_t s, uint32_t e, uint8_t allow)
+{
+    return 0;
+}
 #endif
 
 struct xsm_operations dummy_xsm_ops;
@@ -693,8 +708,10 @@ void xsm_fixup_ops (struct xsm_operations *ops)
 
     set_to_dummy_if_null(ops, show_irq_sid);
     set_to_dummy_if_null(ops, map_domain_pirq);
+    set_to_dummy_if_null(ops, unmap_domain_pirq);
     set_to_dummy_if_null(ops, irq_permission);
     set_to_dummy_if_null(ops, iomem_permission);
+    set_to_dummy_if_null(ops, iomem_mapping);
     set_to_dummy_if_null(ops, pci_config_permission);
 
     set_to_dummy_if_null(ops, get_device_group);
@@ -757,5 +774,6 @@ void xsm_fixup_ops (struct xsm_operations *ops)
     set_to_dummy_if_null(ops, ext_vcpucontext);
     set_to_dummy_if_null(ops, vcpuextstate);
     set_to_dummy_if_null(ops, ioport_permission);
+    set_to_dummy_if_null(ops, ioport_mapping);
 #endif
 }
diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
index 88fef9c..74c9271 100644
--- a/xen/xsm/flask/hooks.c
+++ b/xen/xsm/flask/hooks.c
@@ -721,43 +721,40 @@ static int flask_map_domain_pirq (struct domain *d, int irq, void *data)
     return rc;
 }
 
-static int flask_irq_permission (struct domain *d, int irq, uint8_t access)
+static int flask_unmap_domain_pirq (struct domain *d, int irq)
 {
-    u32 perm;
-    u32 rsid;
+    u32 sid;
     int rc = -EPERM;
 
-    struct domain_security_struct *ssec, *tsec;
+    struct domain_security_struct *ssec;
     struct avc_audit_data ad;
 
-    rc = domain_has_perm(current->domain, d, SECCLASS_RESOURCE,
-                         resource_to_perm(access));
-
+    rc = domain_has_perm(current->domain, d, SECCLASS_RESOURCE, RESOURCE__REMOVE);
     if ( rc )
         return rc;
 
-    if ( access )
-        perm = RESOURCE__ADD_IRQ;
-    else
-        perm = RESOURCE__REMOVE_IRQ;
-
     ssec = current->domain->ssid;
-    tsec = d->ssid;
 
-    rc = get_irq_sid(irq, &rsid, &ad);
-    if ( rc )
-        return rc;
-
-    rc = avc_has_perm(ssec->sid, rsid, SECCLASS_RESOURCE, perm, &ad);
+    if ( irq >= nr_irqs_gsi ) {
+        /* TODO support for MSI here */
+        return 0;
+    } else {
+        rc = get_irq_sid(irq, &sid, &ad);
+    }
     if ( rc )
         return rc;
 
-    if ( access )
-        rc = avc_has_perm(tsec->sid, rsid, SECCLASS_RESOURCE, 
-                            RESOURCE__USE, &ad);
+    rc = avc_has_perm(ssec->sid, sid, SECCLASS_RESOURCE, RESOURCE__REMOVE_IRQ, &ad);
     return rc;
 }
 
+static int flask_irq_permission (struct domain *d, int pirq, uint8_t access)
+{
+    /* the PIRQ number is not useful; real IRQ is checked during mapping */
+    return domain_has_perm(current->domain, d, SECCLASS_RESOURCE,
+                           resource_to_perm(access));
+}
+
 struct iomem_has_perm_data {
     struct domain_security_struct *ssec, *tsec;
     u32 perm;
@@ -1413,7 +1410,7 @@ static int flask_bind_pt_irq (struct domain *d, struct xen_domctl_bind_pt_irq *b
     return avc_has_perm(tsec->sid, rsid, SECCLASS_RESOURCE, RESOURCE__USE, &ad);
 }
 
-static int flask_unbind_pt_irq (struct domain *d)
+static int flask_unbind_pt_irq (struct domain *d, struct xen_domctl_bind_pt_irq *bind)
 {
     return domain_has_perm(current->domain, d, SECCLASS_RESOURCE, RESOURCE__REMOVE);
 }
@@ -1533,6 +1530,7 @@ static struct xsm_operations flask_ops = {
     .show_irq_sid = flask_show_irq_sid,
 
     .map_domain_pirq = flask_map_domain_pirq,
+    .unmap_domain_pirq = flask_unmap_domain_pirq,
     .irq_permission = flask_irq_permission,
     .iomem_permission = flask_iomem_permission,
     .pci_config_permission = flask_pci_config_permission,
-- 
1.7.11.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 12 16:00:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Sep 2012 16:00:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TBpM4-0005NW-Vy; Wed, 12 Sep 2012 15:59:56 +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 1TBpM3-0005Mm-Du
	for xen-devel@lists.xen.org; Wed, 12 Sep 2012 15:59:55 +0000
Received: from [85.158.138.51:6737] by server-7.bemta-3.messagelabs.com id
	37/07-32000-A71B0505; Wed, 12 Sep 2012 15:59:54 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-14.tower-174.messagelabs.com!1347465593!23852944!1
X-Originating-IP: [63.239.67.9]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9702 invoked from network); 12 Sep 2012 15:59:53 -0000
Received: from emvm-gh1-uea08.nsa.gov (HELO nsa.gov) (63.239.67.9)
	by server-14.tower-174.messagelabs.com with SMTP;
	12 Sep 2012 15:59:53 -0000
X-TM-IMSS-Message-ID: <39e15a9100102341@nsa.gov>
Received: from tarius.tycho.ncsc.mil ([144.51.3.1]) by nsa.gov ([63.239.67.9])
	with ESMTP (TREND IMSS SMTP Service 7.1) id 39e15a9100102341 ;
	Wed, 12 Sep 2012 11:59:43 -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 q8CFxoOE006669; 
	Wed, 12 Sep 2012 11:59:51 -0400
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xen.org
Date: Wed, 12 Sep 2012 11:59:28 -0400
Message-Id: <1347465586-20009-5-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.11.4
In-Reply-To: <1347465586-20009-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1347465586-20009-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: dgdegra@tycho.nsa.gov
Subject: [Xen-devel] [PATCH 04/22] xsm/flask: add domain relabel 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

This adds the ability to change a domain's XSM label after creation.
The new label will be used for all future access checks; however,
existing event channels and memory mappings will remain valid even if
their creation would be denied by the new label.

With appropriate security policy and hooks in the domain builder, this
can be used to create domains that the domain builder does not have
access to after building. It can also be used to allow a domain to drop
privileges - for example, prior to launching a user-supplied kernel
loaded by a pv-grub stubdom.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 tools/flask/policy/policy/flask/access_vectors   |  7 ++++
 tools/flask/policy/policy/flask/security_classes |  1 +
 tools/flask/policy/policy/modules/xen/xen.te     |  2 +-
 xen/include/public/xsm/flask_op.h                |  8 ++++
 xen/xsm/flask/flask_op.c                         | 49 ++++++++++++++++++++++++
 xen/xsm/flask/include/av_perm_to_string.h        |  3 ++
 xen/xsm/flask/include/av_permissions.h           |  4 ++
 xen/xsm/flask/include/class_to_string.h          |  1 +
 xen/xsm/flask/include/flask.h                    | 15 ++++----
 9 files changed, 82 insertions(+), 8 deletions(-)

diff --git a/tools/flask/policy/policy/flask/access_vectors b/tools/flask/policy/policy/flask/access_vectors
index a884312..c7e29ab 100644
--- a/tools/flask/policy/policy/flask/access_vectors
+++ b/tools/flask/policy/policy/flask/access_vectors
@@ -73,6 +73,13 @@ class domain
 	set_virq_handler
 }
 
+class domain2
+{
+	relabelfrom
+	relabelto
+	relabelself
+}
+
 class hvm
 {
     sethvmc
diff --git a/tools/flask/policy/policy/flask/security_classes b/tools/flask/policy/policy/flask/security_classes
index 2ca35d2..ef134a7 100644
--- a/tools/flask/policy/policy/flask/security_classes
+++ b/tools/flask/policy/policy/flask/security_classes
@@ -9,6 +9,7 @@
 
 class xen
 class domain
+class domain2
 class hvm
 class mmu
 class resource
diff --git a/tools/flask/policy/policy/modules/xen/xen.te b/tools/flask/policy/policy/modules/xen/xen.te
index 9cc5240..9550397 100644
--- a/tools/flask/policy/policy/modules/xen/xen.te
+++ b/tools/flask/policy/policy/modules/xen/xen.te
@@ -169,7 +169,7 @@ delegate_devices(dom0_t, domU_t)
 ################################################################################
 
 # Domains must be declared using domain_type
-neverallow * ~domain_type:domain create;
+neverallow * ~domain_type:domain { create transition };
 
 # Resources must be declared using resource_type
 neverallow * ~resource_type:resource use;
diff --git a/xen/include/public/xsm/flask_op.h b/xen/include/public/xsm/flask_op.h
index 1a251c9..233de81 100644
--- a/xen/include/public/xsm/flask_op.h
+++ b/xen/include/public/xsm/flask_op.h
@@ -142,6 +142,12 @@ struct xen_flask_peersid {
     uint32_t sid;
 };
 
+struct xen_flask_relabel {
+    /* IN */
+    uint32_t domid;
+    uint32_t sid;
+};
+
 struct xen_flask_op {
     uint32_t cmd;
 #define FLASK_LOAD              1
@@ -167,6 +173,7 @@ struct xen_flask_op {
 #define FLASK_ADD_OCONTEXT      21
 #define FLASK_DEL_OCONTEXT      22
 #define FLASK_GET_PEER_SID      23
+#define FLASK_RELABEL_DOMAIN    24
     uint32_t interface_version; /* XEN_FLASK_INTERFACE_VERSION */
     union {
         struct xen_flask_load load;
@@ -185,6 +192,7 @@ struct xen_flask_op {
         /* FLASK_ADD_OCONTEXT, FLASK_DEL_OCONTEXT */
         struct xen_flask_ocontext ocontext;
         struct xen_flask_peersid peersid;
+        struct xen_flask_relabel relabel;
     } u;
 };
 typedef struct xen_flask_op xen_flask_op_t;
diff --git a/xen/xsm/flask/flask_op.c b/xen/xsm/flask/flask_op.c
index bd4db37..9c8dfe7 100644
--- a/xen/xsm/flask/flask_op.c
+++ b/xen/xsm/flask/flask_op.c
@@ -573,6 +573,51 @@ static int flask_get_peer_sid(struct xen_flask_peersid *arg)
     return rv;
 }
 
+static int flask_relabel_domain(struct xen_flask_relabel *arg)
+{
+    int rc;
+    struct domain *d;
+    struct domain_security_struct *csec = current->domain->ssid;
+    struct domain_security_struct *dsec;
+    struct avc_audit_data ad;
+    AVC_AUDIT_DATA_INIT(&ad, NONE);
+
+    d = rcu_lock_domain_by_any_id(arg->domid);
+    if ( d == NULL )
+        return -ESRCH;
+
+    ad.sdom = current->domain;
+    ad.tdom = d;
+    dsec = d->ssid;
+
+    if ( arg->domid == DOMID_SELF )
+    {
+        rc = avc_has_perm(dsec->sid, arg->sid, SECCLASS_DOMAIN2, DOMAIN2__RELABELSELF, &ad);
+        if ( rc )
+            goto out;
+    }
+    else
+    {
+        rc = avc_has_perm(csec->sid, dsec->sid, SECCLASS_DOMAIN2, DOMAIN2__RELABELFROM, &ad);
+        if ( rc )
+            goto out;
+
+        rc = avc_has_perm(csec->sid, arg->sid, SECCLASS_DOMAIN2, DOMAIN2__RELABELTO, &ad);
+        if ( rc )
+            goto out;
+    }
+
+    rc = avc_has_perm(dsec->sid, arg->sid, SECCLASS_DOMAIN, DOMAIN__TRANSITION, &ad);
+    if ( rc )
+        goto out;
+
+    dsec->sid = arg->sid;
+
+ out:
+    rcu_unlock_domain(d);
+    return rc;
+}
+
 long do_flask_op(XEN_GUEST_HANDLE(xsm_op_t) u_flask_op)
 {
     xen_flask_op_t op;
@@ -680,6 +725,10 @@ long do_flask_op(XEN_GUEST_HANDLE(xsm_op_t) u_flask_op)
         rv = flask_get_peer_sid(&op.u.peersid);
         break;
 
+    case FLASK_RELABEL_DOMAIN:
+        rv = flask_relabel_domain(&op.u.relabel);
+        break;
+
     default:
         rv = -ENOSYS;
     }
diff --git a/xen/xsm/flask/include/av_perm_to_string.h b/xen/xsm/flask/include/av_perm_to_string.h
index 17a1c36..e7e2058 100644
--- a/xen/xsm/flask/include/av_perm_to_string.h
+++ b/xen/xsm/flask/include/av_perm_to_string.h
@@ -61,6 +61,9 @@
    S_(SECCLASS_DOMAIN, DOMAIN__SETPODTARGET, "setpodtarget")
    S_(SECCLASS_DOMAIN, DOMAIN__SET_MISC_INFO, "set_misc_info")
    S_(SECCLASS_DOMAIN, DOMAIN__SET_VIRQ_HANDLER, "set_virq_handler")
+   S_(SECCLASS_DOMAIN2, DOMAIN2__RELABELFROM, "relabelfrom")
+   S_(SECCLASS_DOMAIN2, DOMAIN2__RELABELTO, "relabelto")
+   S_(SECCLASS_DOMAIN2, DOMAIN2__RELABELSELF, "relabelself")
    S_(SECCLASS_HVM, HVM__SETHVMC, "sethvmc")
    S_(SECCLASS_HVM, HVM__GETHVMC, "gethvmc")
    S_(SECCLASS_HVM, HVM__SETPARAM, "setparam")
diff --git a/xen/xsm/flask/include/av_permissions.h b/xen/xsm/flask/include/av_permissions.h
index 42eaf81..cb1c5dc 100644
--- a/xen/xsm/flask/include/av_permissions.h
+++ b/xen/xsm/flask/include/av_permissions.h
@@ -63,6 +63,10 @@
 #define DOMAIN__SET_MISC_INFO                     0x40000000UL
 #define DOMAIN__SET_VIRQ_HANDLER                  0x80000000UL
 
+#define DOMAIN2__RELABELFROM                      0x00000001UL
+#define DOMAIN2__RELABELTO                        0x00000002UL
+#define DOMAIN2__RELABELSELF                      0x00000004UL
+
 #define HVM__SETHVMC                              0x00000001UL
 #define HVM__GETHVMC                              0x00000002UL
 #define HVM__SETPARAM                             0x00000004UL
diff --git a/xen/xsm/flask/include/class_to_string.h b/xen/xsm/flask/include/class_to_string.h
index ab55700..7716645 100644
--- a/xen/xsm/flask/include/class_to_string.h
+++ b/xen/xsm/flask/include/class_to_string.h
@@ -5,6 +5,7 @@
     S_("null")
     S_("xen")
     S_("domain")
+    S_("domain2")
     S_("hvm")
     S_("mmu")
     S_("resource")
diff --git a/xen/xsm/flask/include/flask.h b/xen/xsm/flask/include/flask.h
index 6d29c5a..3bff998 100644
--- a/xen/xsm/flask/include/flask.h
+++ b/xen/xsm/flask/include/flask.h
@@ -7,13 +7,14 @@
  */
 #define SECCLASS_XEN                                     1
 #define SECCLASS_DOMAIN                                  2
-#define SECCLASS_HVM                                     3
-#define SECCLASS_MMU                                     4
-#define SECCLASS_RESOURCE                                5
-#define SECCLASS_SHADOW                                  6
-#define SECCLASS_EVENT                                   7
-#define SECCLASS_GRANT                                   8
-#define SECCLASS_SECURITY                                9
+#define SECCLASS_DOMAIN2                                 3
+#define SECCLASS_HVM                                     4
+#define SECCLASS_MMU                                     5
+#define SECCLASS_RESOURCE                                6
+#define SECCLASS_SHADOW                                  7
+#define SECCLASS_EVENT                                   8
+#define SECCLASS_GRANT                                   9
+#define SECCLASS_SECURITY                                10
 
 /*
  * Security identifier indices for initial entities
-- 
1.7.11.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 12 16:00:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Sep 2012 16:00:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TBpMC-0005h4-JG; Wed, 12 Sep 2012 16:00:04 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1TBpMA-0005NZ-CW
	for xen-devel@lists.xen.org; Wed, 12 Sep 2012 16:00:02 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-9.tower-27.messagelabs.com!1347465594!9477808!1
X-Originating-IP: [63.239.67.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15430 invoked from network); 12 Sep 2012 15:59:55 -0000
Received: from emvm-gh1-uea09.nsa.gov (HELO nsa.gov) (63.239.67.10)
	by server-9.tower-27.messagelabs.com with SMTP;
	12 Sep 2012 15:59:55 -0000
X-TM-IMSS-Message-ID: <39e11eaa001083d6@nsa.gov>
Received: from tarius.tycho.ncsc.mil ([144.51.3.1]) by nsa.gov
	([63.239.67.10]) with ESMTP (TREND IMSS SMTP Service 7.1) id
	39e11eaa001083d6 ; Wed, 12 Sep 2012 12:02:01 -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 q8CFxoOL006669; 
	Wed, 12 Sep 2012 11:59:53 -0400
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xen.org
Date: Wed, 12 Sep 2012 11:59:35 -0400
Message-Id: <1347465586-20009-12-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.11.4
In-Reply-To: <1347465586-20009-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1347465586-20009-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: dgdegra@tycho.nsa.gov, Keir Fraser <keir@xen.org>,
	Jan Beulich <jbeulich@suse.com>
Subject: [Xen-devel] [PATCH 11/22] xen: avoid calling
	rcu_lock_*target_domain when an XSM hook 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>
MIME-Version: 1.0
Content-Type: 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 rcu_lock_{,remote_}target_domain_by_id functions are wrappers around
an IS_PRIV_FOR check for the current domain. This is now redundant with
XSM hooks, so replace these calls with rcu_lock_domain_by_any_id or
rcu_lock_remote_domain_by_id to remove the duplicate permission checks.

When XSM_ENABLE is not defined or when the dummy XSM module is used,
this patch should not change any functionality. Because the locations of
privilege checks have sometimes moved below argument validation, error
returns of some functions may change from EPERM to EINVAL when called
with invalid arguments and from a domain without permission to perform
the operation.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Cc: Keir Fraser <keir@xen.org>
Cc: Jan Beulich <jbeulich@suse.com>
---
 xen/arch/x86/hvm/hvm.c     | 38 +++++++++++++++----------------
 xen/arch/x86/mm.c          | 22 ++++++++----------
 xen/common/event_channel.c | 18 +++++++--------
 xen/common/grant_table.c   | 57 +++++++++++++++-------------------------------
 xen/common/memory.c        | 15 ++++++------
 xen/include/xsm/dummy.h    | 34 +++++++++++++++++++++++++++
 6 files changed, 97 insertions(+), 87 deletions(-)

diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 2cb08c9..ca06976 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -3335,7 +3335,7 @@ static int hvmop_set_pci_intx_level(
     if ( (op.domain > 0) || (op.bus > 0) || (op.device > 31) || (op.intx > 3) )
         return -EINVAL;
 
-    rc = rcu_lock_remote_target_domain_by_id(op.domid, &d);
+    rc = rcu_lock_remote_domain_by_id(op.domid, &d);
     if ( rc != 0 )
         return rc;
 
@@ -3500,7 +3500,7 @@ static int hvmop_set_isa_irq_level(
     if ( op.isa_irq > 15 )
         return -EINVAL;
 
-    rc = rcu_lock_remote_target_domain_by_id(op.domid, &d);
+    rc = rcu_lock_remote_domain_by_id(op.domid, &d);
     if ( rc != 0 )
         return rc;
 
@@ -3544,7 +3544,7 @@ static int hvmop_set_pci_link_route(
     if ( (op.link > 3) || (op.isa_irq > 15) )
         return -EINVAL;
 
-    rc = rcu_lock_remote_target_domain_by_id(op.domid, &d);
+    rc = rcu_lock_remote_domain_by_id(op.domid, &d);
     if ( rc != 0 )
         return rc;
 
@@ -3574,7 +3574,7 @@ static int hvmop_inject_msi(
     if ( copy_from_guest(&op, uop, 1) )
         return -EFAULT;
 
-    rc = rcu_lock_remote_target_domain_by_id(op.domid, &d);
+    rc = rcu_lock_remote_domain_by_id(op.domid, &d);
     if ( rc != 0 )
         return rc;
 
@@ -3671,9 +3671,9 @@ long do_hvm_op(unsigned long op, XEN_GUEST_HANDLE(void) arg)
         if ( a.index >= HVM_NR_PARAMS )
             return -EINVAL;
 
-        rc = rcu_lock_target_domain_by_id(a.domid, &d);
-        if ( rc != 0 )
-            return rc;
+        d = rcu_lock_domain_by_any_id(a.domid);
+        if ( d == NULL )
+            return -ESRCH;
 
         rc = -EINVAL;
         if ( !is_hvm_domain(d) )
@@ -3917,7 +3917,7 @@ long do_hvm_op(unsigned long op, XEN_GUEST_HANDLE(void) arg)
         if ( copy_from_guest(&a, arg, 1) )
             return -EFAULT;
 
-        rc = rcu_lock_remote_target_domain_by_id(a.domid, &d);
+        rc = rcu_lock_remote_domain_by_id(a.domid, &d);
         if ( rc != 0 )
             return rc;
 
@@ -3956,7 +3956,7 @@ long do_hvm_op(unsigned long op, XEN_GUEST_HANDLE(void) arg)
         if ( copy_from_guest(&a, arg, 1) )
             return -EFAULT;
 
-        rc = rcu_lock_remote_target_domain_by_id(a.domid, &d);
+        rc = rcu_lock_remote_domain_by_id(a.domid, &d);
         if ( rc != 0 )
             return rc;
 
@@ -4006,9 +4006,9 @@ long do_hvm_op(unsigned long op, XEN_GUEST_HANDLE(void) arg)
         if ( copy_from_guest(&a, arg, 1) )
             return -EFAULT;
 
-        rc = rcu_lock_target_domain_by_id(a.domid, &d);
-        if ( rc != 0 )
-            return rc;
+        d = rcu_lock_domain_by_any_id(a.domid);
+        if ( d == NULL )
+            return -ESRCH;
 
         rc = xsm_hvm_param(d, op);
         if ( rc )
@@ -4053,7 +4053,7 @@ long do_hvm_op(unsigned long op, XEN_GUEST_HANDLE(void) arg)
         if ( copy_from_guest(&a, arg, 1) )
             return -EFAULT;
 
-        rc = rcu_lock_remote_target_domain_by_id(a.domid, &d);
+        rc = rcu_lock_remote_domain_by_id(a.domid, &d);
         if ( rc != 0 )
             return rc;
 
@@ -4132,7 +4132,7 @@ long do_hvm_op(unsigned long op, XEN_GUEST_HANDLE(void) arg)
         if ( copy_from_guest(&a, arg, 1) )
             return -EFAULT;
 
-        rc = rcu_lock_remote_target_domain_by_id(a.domid, &d);
+        rc = rcu_lock_remote_domain_by_id(a.domid, &d);
         if ( rc != 0 )
             return rc;
 
@@ -4167,7 +4167,7 @@ long do_hvm_op(unsigned long op, XEN_GUEST_HANDLE(void) arg)
         if ( copy_from_guest(&a, arg, 1) )
             return -EFAULT;
 
-        rc = rcu_lock_remote_target_domain_by_id(a.domid, &d);
+        rc = rcu_lock_remote_domain_by_id(a.domid, &d);
         if ( rc != 0 )
             return rc;
 
@@ -4203,9 +4203,9 @@ long do_hvm_op(unsigned long op, XEN_GUEST_HANDLE(void) arg)
         if ( copy_from_guest(&a, arg, 1) )
             return -EFAULT;
 
-        rc = rcu_lock_target_domain_by_id(a.domid, &d);
-        if ( rc != 0 )
-            return rc;
+        d = rcu_lock_domain_by_any_id(a.domid);
+        if ( d == NULL )
+            return -ESRCH;
 
         rc = -EINVAL;
         if ( !is_hvm_domain(d) || !paging_mode_shadow(d) )
@@ -4257,7 +4257,7 @@ long do_hvm_op(unsigned long op, XEN_GUEST_HANDLE(void) arg)
         if ( copy_from_guest(&tr, arg, 1 ) )
             return -EFAULT;
 
-        rc = rcu_lock_remote_target_domain_by_id(tr.domid, &d);
+        rc = rcu_lock_remote_domain_by_id(tr.domid, &d);
         if ( rc != 0 )
             return rc;
 
diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
index b370300..5c6ea2d 100644
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -4371,9 +4371,9 @@ long arch_memory_op(int op, XEN_GUEST_HANDLE(void) arg)
         if ( copy_from_guest(&xatp, arg, 1) )
             return -EFAULT;
 
-        rc = rcu_lock_target_domain_by_id(xatp.domid, &d);
-        if ( rc != 0 )
-            return rc;
+        d = rcu_lock_domain_by_any_id(xatp.domid);
+        if ( d == NULL )
+            return -ESRCH;
 
         if ( xsm_add_to_physmap(current->domain, d) )
         {
@@ -4410,9 +4410,9 @@ long arch_memory_op(int op, XEN_GUEST_HANDLE(void) arg)
         if ( fmap.map.nr_entries > E820MAX )
             return -EINVAL;
 
-        rc = rcu_lock_target_domain_by_id(fmap.domid, &d);
-        if ( rc != 0 )
-            return rc;
+        d = rcu_lock_domain_by_any_id(fmap.domid);
+        if ( d == NULL )
+            return -ESRCH;
 
         rc = xsm_domain_memory_map(d);
         if ( rc )
@@ -4563,16 +4563,12 @@ long arch_memory_op(int op, XEN_GUEST_HANDLE(void) arg)
         struct domain *d;
         struct p2m_domain *p2m;
 
-        /* Support DOMID_SELF? */
-        if ( !IS_PRIV(current->domain) )
-            return -EPERM;
-
         if ( copy_from_guest(&target, arg, 1) )
             return -EFAULT;
 
-        rc = rcu_lock_target_domain_by_id(target.domid, &d);
-        if ( rc != 0 )
-            return rc;
+        d = rcu_lock_domain_by_any_id(target.domid);
+        if ( d == NULL )
+            return -ESRCH;
 
         if ( op == XENMEM_set_pod_target )
             rc = xsm_set_pod_target(d);
diff --git a/xen/common/event_channel.c b/xen/common/event_channel.c
index 53777f8..70becdd 100644
--- a/xen/common/event_channel.c
+++ b/xen/common/event_channel.c
@@ -165,9 +165,9 @@ static long evtchn_alloc_unbound(evtchn_alloc_unbound_t *alloc)
     domid_t        dom = alloc->dom;
     long           rc;
 
-    rc = rcu_lock_target_domain_by_id(dom, &d);
-    if ( rc )
-        return rc;
+    d = rcu_lock_domain_by_any_id(dom);
+    if ( d == NULL )
+        return -ESRCH;
 
     spin_lock(&d->event_lock);
 
@@ -798,9 +798,9 @@ static long evtchn_status(evtchn_status_t *status)
     struct evtchn   *chn;
     long             rc = 0;
 
-    rc = rcu_lock_target_domain_by_id(dom, &d);
-    if ( rc )
-        return rc;
+    d = rcu_lock_domain_by_any_id(dom);
+    if ( d == NULL )
+        return -ESRCH;
 
     spin_lock(&d->event_lock);
 
@@ -950,9 +950,9 @@ static long evtchn_reset(evtchn_reset_t *r)
     struct domain *d;
     int i, rc;
 
-    rc = rcu_lock_target_domain_by_id(dom, &d);
-    if ( rc )
-        return rc;
+    d = rcu_lock_domain_by_any_id(dom);
+    if ( d == NULL )
+        return -ESRCH;
 
     rc = xsm_evtchn_reset(current->domain, d);
     if ( rc )
diff --git a/xen/common/grant_table.c b/xen/common/grant_table.c
index c23c053..10a34d6 100644
--- a/xen/common/grant_table.c
+++ b/xen/common/grant_table.c
@@ -230,30 +230,6 @@ double_gt_unlock(struct grant_table *lgt, struct grant_table *rgt)
         spin_unlock(&rgt->lock);
 }
 
-static struct domain *gt_lock_target_domain_by_id(domid_t dom)
-{
-    struct domain *d;
-    int rc = GNTST_general_error;
-
-    switch ( rcu_lock_target_domain_by_id(dom, &d) )
-    {
-    case 0:
-        return d;
-
-    case -ESRCH:
-        gdprintk(XENLOG_INFO, "Bad domid %d.\n", dom);
-        rc = GNTST_bad_domain;
-        break;
-
-    case -EPERM:
-        rc = GNTST_permission_denied;
-        break;
-    }
-
-    ASSERT(rc < 0 && -rc <= MAX_ERRNO);
-    return ERR_PTR(rc);
-}
-
 static inline int
 __get_maptrack_handle(
     struct grant_table *t)
@@ -1339,11 +1315,12 @@ gnttab_setup_table(
         goto out1;
     }
 
-    d = gt_lock_target_domain_by_id(op.dom);
-    if ( IS_ERR(d) )
+    d = rcu_lock_domain_by_any_id(op.dom);
+    if ( d == NULL )
     {
-        op.status = PTR_ERR(d);
-        goto out1;
+        gdprintk(XENLOG_INFO, "Bad domid %d.\n", op.dom);
+        op.status = GNTST_bad_domain;
+        goto out2;
     }
 
     if ( xsm_grant_setup(current->domain, d) )
@@ -1407,10 +1384,11 @@ gnttab_query_size(
         return -EFAULT;
     }
 
-    d = gt_lock_target_domain_by_id(op.dom);
-    if ( IS_ERR(d) )
+    d = rcu_lock_domain_by_any_id(op.dom);
+    if ( d == NULL )
     {
-        op.status = PTR_ERR(d);
+        gdprintk(XENLOG_INFO, "Bad domid %d.\n", op.dom);
+        op.status = GNTST_bad_domain;
         goto query_out;
     }
 
@@ -2280,10 +2258,10 @@ gnttab_get_status_frames(XEN_GUEST_HANDLE(gnttab_get_status_frames_t) uop,
         return -EFAULT;
     }
 
-    d = gt_lock_target_domain_by_id(op.dom);
-    if ( IS_ERR(d) )
+    d = rcu_lock_domain_by_any_id(op.dom);
+    if ( d == NULL )
     {
-        op.status = PTR_ERR(d);
+        op.status = GNTST_bad_domain;
         goto out1;
     }
     rc = xsm_grant_setup(current->domain, d);
@@ -2333,14 +2311,15 @@ gnttab_get_version(XEN_GUEST_HANDLE(gnttab_get_version_t uop))
     if ( copy_from_guest(&op, uop, 1) )
         return -EFAULT;
 
-    rc = rcu_lock_target_domain_by_id(op.dom, &d);
-    if ( rc < 0 )
-        return rc;
+    d = rcu_lock_domain_by_any_id(op.dom);
+    if ( d == NULL )
+        return -ESRCH;
 
-    if ( xsm_grant_query_size(current->domain, d) )
+    rc = xsm_grant_query_size(current->domain, d);
+    if ( rc )
     {
         rcu_unlock_domain(d);
-        return -EPERM;
+        return rc;
     }
 
     op.version = d->grant_table->gt_version;
diff --git a/xen/common/memory.c b/xen/common/memory.c
index 8779d6b..cfdd63f 100644
--- a/xen/common/memory.c
+++ b/xen/common/memory.c
@@ -570,7 +570,8 @@ long do_memory_op(unsigned long cmd, XEN_GUEST_HANDLE(void) arg)
              && (reservation.mem_flags & XENMEMF_populate_on_demand) )
             args.memflags |= MEMF_populate_on_demand;
 
-        if ( unlikely(rcu_lock_target_domain_by_id(reservation.domid, &d)) )
+        d = rcu_lock_domain_by_any_id(reservation.domid);
+        if ( d == NULL )
             return start_extent;
         args.domain = d;
 
@@ -619,9 +620,9 @@ long do_memory_op(unsigned long cmd, XEN_GUEST_HANDLE(void) arg)
         if ( copy_from_guest(&domid, arg, 1) )
             return -EFAULT;
 
-        rc = rcu_lock_target_domain_by_id(domid, &d);
-        if ( rc )
-            return rc;
+        d = rcu_lock_domain_by_any_id(domid);
+        if ( d == NULL )
+            return -ESRCH;
 
         rc = xsm_memory_stat_reservation(current->domain, d);
         if ( rc )
@@ -657,9 +658,9 @@ long do_memory_op(unsigned long cmd, XEN_GUEST_HANDLE(void) arg)
         if ( copy_from_guest(&xrfp, arg, 1) )
             return -EFAULT;
 
-        rc = rcu_lock_target_domain_by_id(xrfp.domid, &d);
-        if ( rc != 0 )
-            return rc;
+        d = rcu_lock_domain_by_any_id(xrfp.domid);
+        if ( d == NULL )
+            return -ESRCH;
 
         if ( xsm_remove_from_physmap(current->domain, d) )
         {
diff --git a/xen/include/xsm/dummy.h b/xen/include/xsm/dummy.h
index 389d9f6..31f862d 100644
--- a/xen/include/xsm/dummy.h
+++ b/xen/include/xsm/dummy.h
@@ -194,6 +194,8 @@ static XSM_DEFAULT(int, grant_unmapref) (struct domain *d1, struct domain *d2)
 
 static XSM_DEFAULT(int, grant_setup) (struct domain *d1, struct domain *d2)
 {
+    if ( d1 != d2 && !IS_PRIV_FOR(d1, d2) )
+        return -EPERM;
     return 0;
 }
 
@@ -209,17 +211,23 @@ static XSM_DEFAULT(int, grant_copy) (struct domain *d1, struct domain *d2)
 
 static XSM_DEFAULT(int, grant_query_size) (struct domain *d1, struct domain *d2)
 {
+    if ( d1 != d2 && !IS_PRIV_FOR(d1, d2) )
+        return -EPERM;
     return 0;
 }
 
 static XSM_DEFAULT(int, memory_adjust_reservation) (struct domain *d1,
                                                             struct domain *d2)
 {
+    if ( d1 != d2 && !IS_PRIV_FOR(d1, d2) )
+        return -EPERM;
     return 0;
 }
 
 static XSM_DEFAULT(int, memory_stat_reservation) (struct domain *d1, struct domain *d2)
 {
+    if ( d1 != d2 && !IS_PRIV_FOR(d1, d2) )
+        return -EPERM;
     return 0;
 }
 
@@ -260,6 +268,8 @@ static XSM_DEFAULT(int, memory_pin_page) (struct domain *d1, struct domain *d2,
 static XSM_DEFAULT(int, evtchn_unbound) (struct domain *d, struct evtchn *chn,
                                          domid_t id2)
 {
+    if ( current->domain != d && !IS_PRIV_FOR(current->domain, d) )
+        return -EPERM;
     return 0;
 }
 
@@ -281,11 +291,15 @@ static XSM_DEFAULT(int, evtchn_send) (struct domain *d, struct evtchn *chn)
 
 static XSM_DEFAULT(int, evtchn_status) (struct domain *d, struct evtchn *chn)
 {
+    if ( current->domain != d && !IS_PRIV_FOR(current->domain, d) )
+        return -EPERM;
     return 0;
 }
 
 static XSM_DEFAULT(int, evtchn_reset) (struct domain *d1, struct domain *d2)
 {
+    if ( d1 != d2 && !IS_PRIV_FOR(d1, d2) )
+        return -EPERM;
     return 0;
 }
 
@@ -306,11 +320,15 @@ static XSM_DEFAULT(char *, show_security_evtchn) (struct domain *d, const struct
 
 static XSM_DEFAULT(int, get_pod_target)(struct domain *d)
 {
+    if ( !IS_PRIV(current->domain) )
+        return -EPERM;
     return 0;
 }
 
 static XSM_DEFAULT(int, set_pod_target)(struct domain *d)
 {
+    if ( !IS_PRIV(current->domain) )
+        return -EPERM;
     return 0;
 }
 
@@ -481,26 +499,36 @@ static XSM_DEFAULT(int, machine_address_size) (struct domain *d, uint32_t cmd)
 
 static XSM_DEFAULT(int, hvm_param) (struct domain *d, unsigned long op)
 {
+    if ( current->domain != d && !IS_PRIV_FOR(current->domain, d) )
+        return -EPERM;
     return 0;
 }
 
 static XSM_DEFAULT(int, hvm_set_pci_intx_level) (struct domain *d)
 {
+    if ( !IS_PRIV_FOR(current->domain, d) )
+        return -EPERM;
     return 0;
 }
 
 static XSM_DEFAULT(int, hvm_set_isa_irq_level) (struct domain *d)
 {
+    if ( !IS_PRIV_FOR(current->domain, d) )
+        return -EPERM;
     return 0;
 }
 
 static XSM_DEFAULT(int, hvm_set_pci_link_route) (struct domain *d)
 {
+    if ( !IS_PRIV_FOR(current->domain, d) )
+        return -EPERM;
     return 0;
 }
 
 static XSM_DEFAULT(int, hvm_inject_msi) (struct domain *d)
 {
+    if ( !IS_PRIV_FOR(current->domain, d) )
+        return -EPERM;
     return 0;
 }
 
@@ -582,6 +610,8 @@ static XSM_DEFAULT(int, machine_memory_map) (void)
 
 static XSM_DEFAULT(int, domain_memory_map) (struct domain *d)
 {
+    if ( current->domain != d && !IS_PRIV_FOR(current->domain, d) )
+        return -EPERM;
     return 0;
 }
 
@@ -605,11 +635,15 @@ static XSM_DEFAULT(int, update_va_mapping) (struct domain *d, struct domain *f,
 
 static XSM_DEFAULT(int, add_to_physmap) (struct domain *d1, struct domain *d2)
 {
+    if ( d1 != d2 && !IS_PRIV_FOR(d1, d2) )
+        return -EPERM;
     return 0;
 }
 
 static XSM_DEFAULT(int, remove_from_physmap) (struct domain *d1, struct domain *d2)
 {
+    if ( d1 != d2 && !IS_PRIV_FOR(d1, d2) )
+        return -EPERM;
     return 0;
 }
 
-- 
1.7.11.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 12 16:00:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Sep 2012 16:00:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TBpMG-0005re-LP; Wed, 12 Sep 2012 16:00:08 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1TBpMD-0005Q4-LS
	for xen-devel@lists.xen.org; Wed, 12 Sep 2012 16:00:06 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-6.tower-27.messagelabs.com!1347465596!5177876!1
X-Originating-IP: [63.239.67.10]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11790 invoked from network); 12 Sep 2012 15:59:57 -0000
Received: from emvm-gh1-uea09.nsa.gov (HELO nsa.gov) (63.239.67.10)
	by server-6.tower-27.messagelabs.com with SMTP;
	12 Sep 2012 15:59:57 -0000
X-TM-IMSS-Message-ID: <39e125fa001083dd@nsa.gov>
Received: from tarius.tycho.ncsc.mil ([144.51.3.1]) by nsa.gov
	([63.239.67.10]) with ESMTP (TREND IMSS SMTP Service 7.1) id
	39e125fa001083dd ; Wed, 12 Sep 2012 12:02:03 -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 q8CFxoOR006669; 
	Wed, 12 Sep 2012 11:59:54 -0400
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xen.org
Date: Wed, 12 Sep 2012 11:59:41 -0400
Message-Id: <1347465586-20009-18-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.11.4
In-Reply-To: <1347465586-20009-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1347465586-20009-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: dgdegra@tycho.nsa.gov
Subject: [Xen-devel] [PATCH 17/22] xsm/flask: add distinct SIDs for
	self/target 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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Because the FLASK XSM module no longer checks IS_PRIV for remote domain
accesses covered by XSM permissions, domains now have the ability to
perform memory management and other functions on all domains that have
the same type. While it is possible to prevent this by only creating one
domain per type, this solution significantly limits the flexibility of
the type system.

This patch introduces a domain type transition to represent a domain
that is operating on itself. In the example policy, this is demonstrated
by creating a type with _self appended when declaring a domain type
which will be used for reflexive operations. AVCs for a domain of type
domU_t will look like the following:

scontext=system_u:system_r:domU_t tcontext=system_u:system_r:domU_t_self

This change also allows policy to distinguish between event channels a
domain creates to itself and event channels created between domains of
the same type.

The IS_PRIV_FOR check used for device model domains is also no longer
checked by FLASK; a similar transition is performed when the target is
set and used when the device model accesses its target domain.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 docs/misc/xsm-flask.txt                      |  43 ++-
 tools/flask/policy/policy/modules/xen/xen.if |  60 +++-
 tools/flask/policy/policy/modules/xen/xen.te |  13 +-
 xen/xsm/flask/flask_op.c                     |   9 +
 xen/xsm/flask/hooks.c                        | 422 +++++++++++++--------------
 xen/xsm/flask/include/objsec.h               |   2 +
 6 files changed, 307 insertions(+), 242 deletions(-)

diff --git a/docs/misc/xsm-flask.txt b/docs/misc/xsm-flask.txt
index 0778a28..ff81b01 100644
--- a/docs/misc/xsm-flask.txt
+++ b/docs/misc/xsm-flask.txt
@@ -68,9 +68,43 @@ HVM domains with stubdomain device models use two types (one per domain):
  - dm_dom_t is the device model for a domain with type domHVM_t
 
 One disadvantage of using type enforcement to enforce isolation is that a new
-type is needed for each group of domains. In addition, it is not possible to
-allow isolated_domU_t cannot to create loopback event channels without allowing
-two domains of type isolated_domU_t to communicate with one another.
+type is needed for each group of domains. The user field can be used to address
+this for the most common case of groups that can communicate internally but not
+externally; see "Users and roles" below.
+
+Type transitions
+----------------
+
+Xen defines a number of operations such as memory mapping that are necessary for
+a domain to perform on itself, but are also undesirable to allow a domain to
+perform on every other domain of the same label. While it is possible to address
+this by only creating one domain per type, this solution significantly limits
+the flexibility of the type system. Another method to address this issue is to
+duplicate the permission names for every operation that can be performed on the
+current domain or on other domains; however, this significantly increases the
+necessary number of permissions and complicates the XSM hooks. Instead, this is
+addressed by allowing a distinct type to be used for a domain's access to
+itself. The same applies for a device model domain's access to its designated
+target, allowing the IS_PRIV_FOR checks used in Xen's DAC model to be
+implemented in FLASK.
+
+Upon domain creation (or relabel), a type transition is computed using the
+domain's label as the source and target. The result of this computation is used
+as the target when the domain accesses itself. In the example policy, this
+computed type is the result of appending _self to a domain's type: domU_t_self
+for domU_t. If no type transition rule exists, the domain will continue to use
+its own label for both the source and target. An AVC message will look like:
+
+    scontext=system_u:system_r:domU_t tcontext=system_u:system_r:domU_t_self
+
+A similar type transition is done when a device model domain is associated with
+its target using the set_target operation. The transition is computed with the
+target domain as the source and the device model domain as the target: this
+ordering was chosen in order to preserve the original label for the target when
+no type transition rule exists. In the example policy, these computed types are
+the result of appending _target to the domain.
+
+Type transitions are also used to compute the labels of event channels.
 
 Users and roles
 ---------------
@@ -84,7 +118,8 @@ the customer_1 user.
 Access control rules involving users and roles are defined in the policy
 constraints file (tools/flask/policy/policy/constraints). The example policy
 provides constraints that prevent different users from communicating using
-grants or event channels, while still allowing communication with dom0.
+grants or event channels, while still allowing communication with the system_u
+user where dom0 resides.
 
 Resource Policy
 ---------------
diff --git a/tools/flask/policy/policy/modules/xen/xen.if b/tools/flask/policy/policy/modules/xen/xen.if
index 59ba171..d630f47 100644
--- a/tools/flask/policy/policy/modules/xen/xen.if
+++ b/tools/flask/policy/policy/modules/xen/xen.if
@@ -5,15 +5,34 @@
 # Domain creation and setup
 #
 ################################################################################
+define(`declare_domain_common', `
+	allow $1 $2:grant { query setup };
+	allow $1 $2:mmu { adjust physmap map_read map_write stat pinpage updatemp };
+	allow $1 $2:hvm { getparam setparam };
+')
+
 # declare_domain(type, attrs...)
-#   Declare a type as a domain type, and allow basic domain setup
+#   Declare a domain type, along with associated _self and _channel types
+#   Allow the domain to perform basic operations on itself
 define(`declare_domain', `
 	type $1, domain_type`'ifelse(`$#', `1', `', `,shift($@)');
+	type $1_self, domain_type, domain_self_type;
+	type_transition $1 $1:domain $1_self;
+	type $1_channel, event_type;
+	type_transition $1 domain_type:event $1_channel;
+	declare_domain_common($1, $1_self)
+')
+
+# declare_singleton_domain(type, attrs...)
+#   Declare a domain type and associated _channel types.
+#   Note: Because the domain can perform basic operations on itself and any
+#   other domain of the same type, this constructor should be used for types
+#   containing at most one domain. This is not enforced by policy.
+define(`declare_singleton_domain', `
+	type $1, domain_type`'ifelse(`$#', `1', `', `,shift($@)');
 	type $1_channel, event_type;
 	type_transition $1 domain_type:event $1_channel;
-	allow $1 $1:grant { query setup };
-	allow $1 $1:mmu { adjust physmap map_read map_write stat pinpage };
-	allow $1 $1:hvm { getparam setparam };
+	declare_domain_common($1, $1)
 ')
 
 # declare_build_label(type)
@@ -51,6 +70,7 @@ define(`create_domain_build_label', `
 	allow $1 $2_channel:event create;
 	allow $1 $2_building:domain2 relabelfrom;
 	allow $1 $2:domain2 relabelto;
+	allow $2_building $2:domain transition;
 ')
 
 # manage_domain(priv, target)
@@ -101,20 +121,36 @@ define(`domain_comms', `
 ')
 
 # domain_self_comms(domain)
-#   Allow a domain types to communicate with others of its type using grants
-#   and event channels (this includes event channels to DOMID_SELF)
+#   Allow a non-singleton domain type to communicate with itself using grants
+#   and event channels
 define(`domain_self_comms', `
-	create_channel($1, $1, $1_channel)
-	allow $1 $1:grant { map_read map_write copy unmap };
+	create_channel($1, $1_self, $1_channel)
+	allow $1 $1_self:grant { map_read map_write copy unmap };
 ')
 
 # device_model(dm_dom, hvm_dom)
 #   Define how a device model domain interacts with its target
 define(`device_model', `
-	domain_comms($1, $2)
-	allow $1 $2:domain { set_target shutdown };
-	allow $1 $2:mmu { map_read map_write adjust physmap };
-	allow $1 $2:hvm { getparam setparam trackdirtyvram hvmctl irqlevel pciroute cacheattr send_irq };
+	type $2_target, domain_type, domain_target_type;
+	type_transition $2 $1:domain $2_target;
+	allow $1 $2:domain set_target;
+
+	type_transition $2_target domain_type:event $2_channel;
+	create_channel($1, $2_target, $1_channel)
+	create_channel($2, $1, $2_channel)
+	allow $1 $2_channel:event create;
+
+	allow $1 $2_target:domain shutdown;
+	allow $1 $2_target:mmu { map_read map_write adjust physmap };
+	allow $1 $2_target:hvm { getparam setparam trackdirtyvram hvmctl irqlevel pciroute cacheattr send_irq };
+')
+
+# make_device_model(priv, dm_dom, hvm_dom)
+#   Allow creation of a device model and HVM domain pair
+define(`make_device_model', `
+	device_model($2, $3)
+	allow $1 $2:domain2 make_priv_for;
+	allow $1 $3:domain2 set_as_target;
 ')
 ################################################################################
 #
diff --git a/tools/flask/policy/policy/modules/xen/xen.te b/tools/flask/policy/policy/modules/xen/xen.te
index 1162153..8d33285 100644
--- a/tools/flask/policy/policy/modules/xen/xen.te
+++ b/tools/flask/policy/policy/modules/xen/xen.te
@@ -8,6 +8,8 @@
 ################################################################################
 attribute xen_type;
 attribute domain_type;
+attribute domain_self_type;
+attribute domain_target_type;
 attribute resource_type;
 attribute event_type;
 attribute mls_priv;
@@ -25,7 +27,7 @@ attribute mls_priv;
 type xen_t, xen_type, mls_priv;
 
 # Domain 0
-declare_domain(dom0_t, mls_priv);
+declare_singleton_domain(dom0_t, mls_priv);
 
 # Untracked I/O memory (pseudo-domain)
 type domio_t, xen_type;
@@ -69,7 +71,7 @@ admin_device(dom0_t, ioport_t)
 admin_device(dom0_t, iomem_t)
 allow dom0_t domio_t:mmu { map_read map_write };
 
-domain_self_comms(dom0_t)
+domain_comms(dom0_t, dom0_t)
 
 auditallow dom0_t security_t:security { load_policy setenforce setbool };
 
@@ -84,11 +86,14 @@ domain_self_comms(domU_t)
 create_domain(dom0_t, domU_t)
 manage_domain(dom0_t, domU_t)
 domain_comms(dom0_t, domU_t)
+domain_comms(domU_t, domU_t)
+domain_self_comms(domU_t)
 
 declare_domain(isolated_domU_t)
 create_domain(dom0_t, isolated_domU_t)
 manage_domain(dom0_t, isolated_domU_t)
 domain_comms(dom0_t, isolated_domU_t)
+domain_self_comms(isolated_domU_t)
 
 # Declare a boolean that denies creation of prot_domU_t domains
 gen_bool(prot_doms_locked, false)
@@ -98,6 +103,8 @@ if (!prot_doms_locked) {
 }
 domain_comms(dom0_t, prot_domU_t)
 domain_comms(domU_t, prot_domU_t)
+domain_comms(prot_domU_t, prot_domU_t)
+domain_self_comms(prot_domU_t)
 
 # domHVM_t is meant to be paired with a qemu-dm stub domain of type dm_dom_t
 declare_domain(domHVM_t)
@@ -110,7 +117,7 @@ declare_domain(dm_dom_t)
 create_domain(dom0_t, dm_dom_t)
 manage_domain(dom0_t, dm_dom_t)
 domain_comms(dom0_t, dm_dom_t)
-device_model(dm_dom_t, domHVM_t)
+make_device_model(dom0_t, dm_dom_t, domHVM_t)
 
 # nomigrate_t must be built via the nomigrate_t_building label; once built,
 # dom0 cannot read its memory.
diff --git a/xen/xsm/flask/flask_op.c b/xen/xsm/flask/flask_op.c
index 9c8dfe7..f8fc108 100644
--- a/xen/xsm/flask/flask_op.c
+++ b/xen/xsm/flask/flask_op.c
@@ -612,6 +612,15 @@ static int flask_relabel_domain(struct xen_flask_relabel *arg)
         goto out;
 
     dsec->sid = arg->sid;
+    dsec->self_sid = arg->sid;
+    security_transition_sid(dsec->sid, dsec->sid, SECCLASS_DOMAIN,
+                            &dsec->self_sid);
+    if ( d->target )
+    {
+        struct domain_security_struct *tsec = d->target->ssid;
+        security_transition_sid(tsec->sid, dsec->sid, SECCLASS_DOMAIN,
+                                &dsec->target_sid);
+    }
 
  out:
     rcu_unlock_domain(d);
diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
index 3cb814d..421087f 100644
--- a/xen/xsm/flask/hooks.c
+++ b/xen/xsm/flask/hooks.c
@@ -33,38 +33,69 @@
 
 struct xsm_operations *original_ops = NULL;
 
+static u32 domain_sid(struct domain *dom)
+{
+    struct domain_security_struct *dsec = dom->ssid;
+    return dsec->sid;
+}
+
+static u32 domain_target_sid(struct domain *src, struct domain *dst)
+{
+    struct domain_security_struct *ssec = src->ssid;
+    struct domain_security_struct *dsec = dst->ssid;
+    if (src == dst)
+        return ssec->self_sid;
+    if (src->target == dst)
+        return ssec->target_sid;
+    return dsec->sid;
+}
+
+static u32 evtchn_sid(const struct evtchn *chn)
+{
+    struct evtchn_security_struct *esec = chn->ssid;
+    return esec->sid;
+}
+
 static int domain_has_perm(struct domain *dom1, struct domain *dom2, 
                            u16 class, u32 perms)
 {
-    struct domain_security_struct *dsec1, *dsec2;
+    u32 ssid, tsid;
     struct avc_audit_data ad;
     AVC_AUDIT_DATA_INIT(&ad, NONE);
     ad.sdom = dom1;
     ad.tdom = dom2;
 
-    dsec1 = dom1->ssid;
-    dsec2 = dom2->ssid;
+    ssid = domain_sid(dom1);
+    tsid = domain_target_sid(dom1, dom2);
 
-    return avc_has_perm(dsec1->sid, dsec2->sid, class, perms, &ad);
+    return avc_has_perm(ssid, tsid, class, perms, &ad);
 }
 
-static int domain_has_evtchn(struct domain *d, struct evtchn *chn, u32 perms)
+static int avc_current_has_perm(u32 tsid, u16 class, u32 perm,
+                                struct avc_audit_data *ad)
 {
-    struct domain_security_struct *dsec;
-    struct evtchn_security_struct *esec;
+    u32 csid = domain_sid(current->domain);
+    return avc_has_perm(csid, tsid, class, perm, ad);
+}
 
-    dsec = d->ssid;
-    esec = chn->ssid;
+static int current_has_perm(struct domain *d, u16 class, u32 perms)
+{
+    return domain_has_perm(current->domain, d, class, perms);
+}
 
-    return avc_has_perm(dsec->sid, esec->sid, SECCLASS_EVENT, perms, NULL);
+static int domain_has_evtchn(struct domain *d, struct evtchn *chn, u32 perms)
+{
+    u32 dsid = domain_sid(d);
+    u32 esid = evtchn_sid(chn);
+
+    return avc_has_perm(dsid, esid, SECCLASS_EVENT, perms, NULL);
 }
 
 static int domain_has_xen(struct domain *d, u32 perms)
 {
-    struct domain_security_struct *dsec;
-    dsec = d->ssid;
+    u32 dsid = domain_sid(d);
 
-    return avc_has_perm(dsec->sid, SECINITSID_XEN, SECCLASS_XEN, perms, NULL);
+    return avc_has_perm(dsid, SECINITSID_XEN, SECCLASS_XEN, perms, NULL);
 }
 
 static int get_irq_sid(int irq, u32 *sid, struct avc_audit_data *ad)
@@ -123,6 +154,7 @@ static int flask_domain_alloc_security(struct domain *d)
         dsec->sid = SECINITSID_UNLABELED;
     }
 
+    dsec->self_sid = dsec->sid;
     d->ssid = dsec;
 
     return 0;
@@ -142,68 +174,55 @@ static void flask_domain_free_security(struct domain *d)
 static int flask_evtchn_unbound(struct domain *d1, struct evtchn *chn, 
                                 domid_t id2)
 {
-    u32 newsid;
+    u32 sid1, sid2, newsid;
     int rc;
-    domid_t id;
     struct domain *d2;
-    struct domain_security_struct *dsec, *dsec1, *dsec2;
     struct evtchn_security_struct *esec;
 
-    dsec = current->domain->ssid;
-    dsec1 = d1->ssid;
-    esec = chn->ssid;
-
-    if ( id2 == DOMID_SELF )
-        id = current->domain->domain_id;
-    else
-        id = id2;
-
-    d2 = get_domain_by_id(id);
+    d2 = rcu_lock_domain_by_any_id(id2);
     if ( d2 == NULL )
         return -EPERM;
 
-    dsec2 = d2->ssid;
-    rc = security_transition_sid(dsec1->sid, dsec2->sid, SECCLASS_EVENT, 
-                                 &newsid);
+    sid1 = domain_sid(d1);
+    sid2 = domain_target_sid(d1, d2);
+    esec = chn->ssid;
+
+    rc = security_transition_sid(sid1, sid2, SECCLASS_EVENT, &newsid);
     if ( rc )
         goto out;
 
-    rc = avc_has_perm(dsec->sid, newsid, SECCLASS_EVENT, EVENT__CREATE, NULL);
+    rc = avc_current_has_perm(newsid, SECCLASS_EVENT, EVENT__CREATE, NULL);
     if ( rc )
         goto out;
 
-    rc = avc_has_perm(newsid, dsec2->sid, SECCLASS_EVENT, EVENT__BIND, NULL);
+    rc = avc_has_perm(newsid, sid2, SECCLASS_EVENT, EVENT__BIND, NULL);
     if ( rc )
         goto out;
-    else
-        esec->sid = newsid;
+
+    esec->sid = newsid;
 
  out:
-    put_domain(d2);
+    rcu_unlock_domain(d2);
     return rc;
 }
 
 static int flask_evtchn_interdomain(struct domain *d1, struct evtchn *chn1, 
                                     struct domain *d2, struct evtchn *chn2)
 {
-    u32 newsid;
+    u32 sid1, sid2, newsid, reverse_sid;
     int rc;
-    struct domain_security_struct *dsec, *dsec1, *dsec2;
-    struct evtchn_security_struct *esec1, *esec2;
+    struct evtchn_security_struct *esec1;
     struct avc_audit_data ad;
     AVC_AUDIT_DATA_INIT(&ad, NONE);
     ad.sdom = d1;
     ad.tdom = d2;
 
-    dsec = current->domain->ssid;
-    dsec1 = d1->ssid;
-    dsec2 = d2->ssid;
+    sid1 = domain_sid(d1);
+    sid2 = domain_target_sid(d1, d2);
 
     esec1 = chn1->ssid;
-    esec2 = chn2->ssid;
 
-    rc = security_transition_sid(dsec1->sid, dsec2->sid, 
-                                 SECCLASS_EVENT, &newsid);
+    rc = security_transition_sid(sid1, sid2, SECCLASS_EVENT, &newsid);
     if ( rc )
     {
         printk("%s: security_transition_sid failed, rc=%d (domain=%d)\n",
@@ -211,15 +230,20 @@ static int flask_evtchn_interdomain(struct domain *d1, struct evtchn *chn1,
         return rc;
     }
 
-    rc = avc_has_perm(dsec->sid, newsid, SECCLASS_EVENT, EVENT__CREATE, &ad);
+    rc = avc_current_has_perm(newsid, SECCLASS_EVENT, EVENT__CREATE, &ad);
     if ( rc )
         return rc;
 
-    rc = avc_has_perm(newsid, dsec2->sid, SECCLASS_EVENT, EVENT__BIND, &ad);
+    rc = avc_has_perm(newsid, sid2, SECCLASS_EVENT, EVENT__BIND, &ad);
     if ( rc )
         return rc;
 
-    rc = avc_has_perm(esec2->sid, dsec1->sid, SECCLASS_EVENT, EVENT__BIND, &ad);
+    /* It's possible the target domain has changed (relabel or destroy/create)
+     * since the unbound part was created; re-validate this binding now.
+     */
+    reverse_sid = evtchn_sid(chn2);
+    sid1 = domain_target_sid(d2, d1);
+    rc = avc_has_perm(reverse_sid, sid1, SECCLASS_EVENT, EVENT__BIND, &ad);
     if ( rc )
         return rc;
 
@@ -302,7 +326,6 @@ static void flask_free_security_evtchn(struct evtchn *chn)
 
 static char *flask_show_security_evtchn(struct domain *d, const struct evtchn *chn)
 {
-    struct evtchn_security_struct *esec;
     int irq;
     u32 sid = 0;
     char *ctx;
@@ -312,9 +335,7 @@ static char *flask_show_security_evtchn(struct domain *d, const struct evtchn *c
     {
     case ECS_UNBOUND:
     case ECS_INTERDOMAIN:
-        esec = chn->ssid;
-        if ( esec )
-            sid = esec->sid;
+        sid = evtchn_sid(chn);
         break;
     case ECS_PIRQ:
         irq = domain_pirq_to_irq(d, chn->u.pirq.irq);
@@ -367,12 +388,12 @@ static int flask_grant_query_size(struct domain *d1, struct domain *d2)
 
 static int flask_get_pod_target(struct domain *d)
 {
-    return domain_has_perm(current->domain, d, SECCLASS_DOMAIN, DOMAIN__GETPODTARGET);
+    return current_has_perm(d, SECCLASS_DOMAIN, DOMAIN__GETPODTARGET);
 }
 
 static int flask_set_pod_target(struct domain *d)
 {
-    return domain_has_perm(current->domain, d, SECCLASS_DOMAIN, DOMAIN__SETPODTARGET);
+    return current_has_perm(d, SECCLASS_DOMAIN, DOMAIN__SETPODTARGET);
 }
 
 static int flask_memory_adjust_reservation(struct domain *d1, struct domain *d2)
@@ -455,70 +476,65 @@ static int flask_schedop_shutdown(struct domain *d1, struct domain *d2)
 static void flask_security_domaininfo(struct domain *d, 
                                       struct xen_domctl_getdomaininfo *info)
 {
-    struct domain_security_struct *dsec;
-
-    dsec = d->ssid;
-    info->ssidref = dsec->sid;
+    info->ssidref = domain_sid(d);
 }
 
 static int flask_setvcpucontext(struct domain *d)
 {
-    return domain_has_perm(current->domain, d, SECCLASS_DOMAIN, 
-                           DOMAIN__SETVCPUCONTEXT);
+    return current_has_perm(d, SECCLASS_DOMAIN, DOMAIN__SETVCPUCONTEXT);
 }
 
 static int flask_pausedomain(struct domain *d)
 {
-    return domain_has_perm(current->domain, d, SECCLASS_DOMAIN, DOMAIN__PAUSE);
+    return current_has_perm(d, SECCLASS_DOMAIN, DOMAIN__PAUSE);
 }
 
 static int flask_unpausedomain(struct domain *d)
 {
-    return domain_has_perm(current->domain, d, SECCLASS_DOMAIN, DOMAIN__UNPAUSE);
+    return current_has_perm(d, SECCLASS_DOMAIN, DOMAIN__UNPAUSE);
 }
 
 static int flask_resumedomain(struct domain *d)
 {
-    return domain_has_perm(current->domain, d, SECCLASS_DOMAIN, DOMAIN__RESUME);
+    return current_has_perm(d, SECCLASS_DOMAIN, DOMAIN__RESUME);
 }
 
 static int flask_domain_create(struct domain *d, u32 ssidref)
 {
     int rc;
-    struct domain_security_struct *dsec1;
-    struct domain_security_struct *dsec2;
+    struct domain_security_struct *dsec = d->ssid;
     static int dom0_created = 0;
 
-    dsec1 = current->domain->ssid;
-    dsec2 = d->ssid;
-
     if ( is_idle_domain(current->domain) && !dom0_created )
     {
-        dsec2->sid = SECINITSID_DOM0;
+        dsec->sid = SECINITSID_DOM0;
         dom0_created = 1;
-        return 0;
     }
+    else
+    {
+        rc = avc_current_has_perm(ssidref, SECCLASS_DOMAIN,
+                          DOMAIN__CREATE, NULL);
+        if ( rc )
+            return rc;
 
-    rc = avc_has_perm(dsec1->sid, ssidref, SECCLASS_DOMAIN,
-                      DOMAIN__CREATE, NULL);
-    if ( rc )
-        return rc;
+        dsec->sid = ssidref;
+    }
+    dsec->self_sid = dsec->sid;
 
-    dsec2->sid = ssidref;
+    rc = security_transition_sid(dsec->sid, dsec->sid, SECCLASS_DOMAIN,
+                                 &dsec->self_sid);
 
     return rc;
 }
 
 static int flask_max_vcpus(struct domain *d)
 {
-    return domain_has_perm(current->domain, d, SECCLASS_DOMAIN, 
-                           DOMAIN__MAX_VCPUS);
+    return current_has_perm(d, SECCLASS_DOMAIN, DOMAIN__MAX_VCPUS);
 }
 
 static int flask_destroydomain(struct domain *d)
 {
-    return domain_has_perm(current->domain, d, SECCLASS_DOMAIN, 
-                           DOMAIN__DESTROY);
+    return current_has_perm(d, SECCLASS_DOMAIN, DOMAIN__DESTROY);
 }
 
 static int flask_vcpuaffinity(int cmd, struct domain *d)
@@ -537,7 +553,7 @@ static int flask_vcpuaffinity(int cmd, struct domain *d)
         return -EPERM;
     }
 
-    return domain_has_perm(current->domain, d, SECCLASS_DOMAIN, perm );
+    return current_has_perm(d, SECCLASS_DOMAIN, perm );
 }
 
 static int flask_scheduler(struct domain *d)
@@ -548,43 +564,51 @@ static int flask_scheduler(struct domain *d)
     if ( rc )
         return rc;
 
-    return domain_has_perm(current->domain, d, SECCLASS_DOMAIN, 
-                           DOMAIN__SCHEDULER);
+    return current_has_perm(d, SECCLASS_DOMAIN, DOMAIN__SCHEDULER);
 }
 
 static int flask_getdomaininfo(struct domain *d)
 {
-    return domain_has_perm(current->domain, d, SECCLASS_DOMAIN,
-                           DOMAIN__GETDOMAININFO);
+    return current_has_perm(d, SECCLASS_DOMAIN, DOMAIN__GETDOMAININFO);
 }
 
 static int flask_getvcpucontext(struct domain *d)
 {
-    return domain_has_perm(current->domain, d, SECCLASS_DOMAIN, 
-                           DOMAIN__GETVCPUCONTEXT);
+    return current_has_perm(d, SECCLASS_DOMAIN, DOMAIN__GETVCPUCONTEXT);
 }
 
 static int flask_getvcpuinfo(struct domain *d)
 {
-    return domain_has_perm(current->domain, d, SECCLASS_DOMAIN,
-                           DOMAIN__GETVCPUINFO);
+    return current_has_perm(d, SECCLASS_DOMAIN, DOMAIN__GETVCPUINFO);
 }
 
 static int flask_domain_settime(struct domain *d)
 {
-    return domain_has_perm(current->domain, d, SECCLASS_DOMAIN, DOMAIN__SETTIME);
+    return current_has_perm(d, SECCLASS_DOMAIN, DOMAIN__SETTIME);
 }
 
-static int flask_set_target(struct domain *d, struct domain *e)
+static int flask_set_target(struct domain *d, struct domain *t)
 {
     int rc;
-    rc = domain_has_perm(current->domain, d, SECCLASS_DOMAIN2, DOMAIN2__MAKE_PRIV_FOR);
+    struct domain_security_struct *dsec, *tsec;
+    dsec = d->ssid;
+    tsec = t->ssid;
+
+    rc = current_has_perm(d, SECCLASS_DOMAIN2, DOMAIN2__MAKE_PRIV_FOR);
     if ( rc )
         return rc;
-    rc = domain_has_perm(current->domain, e, SECCLASS_DOMAIN2, DOMAIN2__SET_AS_TARGET);
+    rc = current_has_perm(t, SECCLASS_DOMAIN2, DOMAIN2__SET_AS_TARGET);
     if ( rc )
         return rc;
-    return domain_has_perm(d, e, SECCLASS_DOMAIN, DOMAIN__SET_TARGET);
+    /* Use avc_has_perm to avoid resolving target/current SID */
+    rc = avc_has_perm(dsec->sid, tsec->sid, SECCLASS_DOMAIN, DOMAIN__SET_TARGET, NULL);
+    if ( rc )
+        return rc;
+
+    /* (tsec, dsec) defaults the label to tsec, as it should here */
+    rc = security_transition_sid(tsec->sid, dsec->sid, SECCLASS_DOMAIN,
+                                 &dsec->target_sid);
+    return rc;
 }
 
 static int flask_domctl(struct domain *d, int cmd)
@@ -655,26 +679,24 @@ static int flask_domctl(struct domain *d, int cmd)
     case XEN_DOMCTL_gdbsx_pausevcpu:
     case XEN_DOMCTL_gdbsx_unpausevcpu:
     case XEN_DOMCTL_gdbsx_domstatus:
-        return domain_has_perm(current->domain, d, SECCLASS_DOMAIN,
-                               DOMAIN__SETDEBUGGING);
+        return current_has_perm(d, SECCLASS_DOMAIN, DOMAIN__SETDEBUGGING);
 
     case XEN_DOMCTL_subscribe:
     case XEN_DOMCTL_disable_migrate:
     case XEN_DOMCTL_suppress_spurious_page_faults:
-        return domain_has_perm(current->domain, d, SECCLASS_DOMAIN,
-                               DOMAIN__SET_MISC_INFO);
+        return current_has_perm(d, SECCLASS_DOMAIN, DOMAIN__SET_MISC_INFO);
 
     case XEN_DOMCTL_set_cpuid:
-        return domain_has_perm(current->domain, d, SECCLASS_DOMAIN2, DOMAIN2__SET_CPUID);
+        return current_has_perm(d, SECCLASS_DOMAIN2, DOMAIN2__SET_CPUID);
 
     case XEN_DOMCTL_gettscinfo:
-        return domain_has_perm(current->domain, d, SECCLASS_DOMAIN2, DOMAIN2__GETTSC);
+        return current_has_perm(d, SECCLASS_DOMAIN2, DOMAIN2__GETTSC);
 
     case XEN_DOMCTL_settscinfo:
-        return domain_has_perm(current->domain, d, SECCLASS_DOMAIN2, DOMAIN2__SETTSC);
+        return current_has_perm(d, SECCLASS_DOMAIN2, DOMAIN2__SETTSC);
 
     case XEN_DOMCTL_audit_p2m:
-        return domain_has_perm(current->domain, d, SECCLASS_HVM, HVM__AUDIT_P2M);
+        return current_has_perm(d, SECCLASS_HVM, HVM__AUDIT_P2M);
 
     default:
         printk("flask_domctl: Unknown op %d\n", cmd);
@@ -714,7 +736,7 @@ static int flask_sysctl(int cmd)
 
 static int flask_set_virq_handler(struct domain *d, uint32_t virq)
 {
-    return domain_has_perm(current->domain, d, SECCLASS_DOMAIN, DOMAIN__SET_VIRQ_HANDLER);
+    return current_has_perm(d, SECCLASS_DOMAIN, DOMAIN__SET_VIRQ_HANDLER);
 }
 
 static int flask_tbufcontrol(void)
@@ -739,20 +761,17 @@ static int flask_sched_id(void)
 
 static int flask_setdomainmaxmem(struct domain *d)
 {
-    return domain_has_perm(current->domain, d, SECCLASS_DOMAIN,
-                           DOMAIN__SETDOMAINMAXMEM);
+    return current_has_perm(d, SECCLASS_DOMAIN, DOMAIN__SETDOMAINMAXMEM);
 }
 
 static int flask_setdomainhandle(struct domain *d)
 {
-    return domain_has_perm(current->domain, d, SECCLASS_DOMAIN,
-                           DOMAIN__SETDOMAINHANDLE);
+    return current_has_perm(d, SECCLASS_DOMAIN, DOMAIN__SETDOMAINHANDLE);
 }
 
 static int flask_setdebugging(struct domain *d)
 {
-    return domain_has_perm(current->domain, d, SECCLASS_DOMAIN,
-                           DOMAIN__SETDEBUGGING);
+    return current_has_perm(d, SECCLASS_DOMAIN, DOMAIN__SETDEBUGGING);
 }
 
 static int flask_debug_keys(void)
@@ -814,14 +833,12 @@ static char *flask_show_irq_sid (int irq)
 
 static int flask_map_domain_pirq (struct domain *d, int irq, void *data)
 {
-    u32 sid;
+    u32 sid, dsid;
     int rc = -EPERM;
     struct msi_info *msi = data;
-
-    struct domain_security_struct *ssec, *tsec;
     struct avc_audit_data ad;
 
-    rc = domain_has_perm(current->domain, d, SECCLASS_RESOURCE, RESOURCE__ADD);
+    rc = current_has_perm(d, SECCLASS_RESOURCE, RESOURCE__ADD);
 
     if ( rc )
         return rc;
@@ -837,14 +854,13 @@ static int flask_map_domain_pirq (struct domain *d, int irq, void *data)
     if ( rc )
         return rc;
 
-    ssec = current->domain->ssid;
-    tsec = d->ssid;
+    dsid = domain_sid(d);
 
-    rc = avc_has_perm(ssec->sid, sid, SECCLASS_RESOURCE, RESOURCE__ADD_IRQ, &ad);
+    rc = avc_current_has_perm(sid, SECCLASS_RESOURCE, RESOURCE__ADD_IRQ, &ad);
     if ( rc )
         return rc;
 
-    rc = avc_has_perm(tsec->sid, sid, SECCLASS_RESOURCE, RESOURCE__USE, &ad);
+    rc = avc_has_perm(dsid, sid, SECCLASS_RESOURCE, RESOURCE__USE, &ad);
     return rc;
 }
 
@@ -852,16 +868,12 @@ static int flask_unmap_domain_pirq (struct domain *d, int irq)
 {
     u32 sid;
     int rc = -EPERM;
-
-    struct domain_security_struct *ssec;
     struct avc_audit_data ad;
 
-    rc = domain_has_perm(current->domain, d, SECCLASS_RESOURCE, RESOURCE__REMOVE);
+    rc = current_has_perm(d, SECCLASS_RESOURCE, RESOURCE__REMOVE);
     if ( rc )
         return rc;
 
-    ssec = current->domain->ssid;
-
     if ( irq >= nr_irqs_gsi ) {
         /* TODO support for MSI here */
         return 0;
@@ -871,19 +883,19 @@ static int flask_unmap_domain_pirq (struct domain *d, int irq)
     if ( rc )
         return rc;
 
-    rc = avc_has_perm(ssec->sid, sid, SECCLASS_RESOURCE, RESOURCE__REMOVE_IRQ, &ad);
+    rc = avc_current_has_perm(sid, SECCLASS_RESOURCE, RESOURCE__REMOVE_IRQ, &ad);
     return rc;
 }
 
 static int flask_irq_permission (struct domain *d, int pirq, uint8_t access)
 {
     /* the PIRQ number is not useful; real IRQ is checked during mapping */
-    return domain_has_perm(current->domain, d, SECCLASS_RESOURCE,
-                           resource_to_perm(access));
+    return current_has_perm(d, SECCLASS_RESOURCE, resource_to_perm(access));
 }
 
 struct iomem_has_perm_data {
-    struct domain_security_struct *ssec, *tsec;
+    u32 ssid;
+    u32 dsid;
     u32 perm;
 };
 
@@ -897,12 +909,12 @@ static int _iomem_has_perm(void *v, u32 sid, unsigned long start, unsigned long
     ad.range.start = start;
     ad.range.end = end;
 
-    rc = avc_has_perm(data->ssec->sid, sid, SECCLASS_RESOURCE, data->perm, &ad);
+    rc = avc_has_perm(data->ssid, sid, SECCLASS_RESOURCE, data->perm, &ad);
 
     if ( rc )
         return rc;
 
-    return avc_has_perm(data->tsec->sid, sid, SECCLASS_RESOURCE, RESOURCE__USE, &ad);
+    return avc_has_perm(data->dsid, sid, SECCLASS_RESOURCE, RESOURCE__USE, &ad);
 }
 
 static int flask_iomem_permission(struct domain *d, uint64_t start, uint64_t end, uint8_t access)
@@ -910,7 +922,7 @@ static int flask_iomem_permission(struct domain *d, uint64_t start, uint64_t end
     struct iomem_has_perm_data data;
     int rc;
 
-    rc = domain_has_perm(current->domain, d, SECCLASS_RESOURCE,
+    rc = current_has_perm(d, SECCLASS_RESOURCE,
                          resource_to_perm(access));
     if ( rc )
         return rc;
@@ -920,8 +932,8 @@ static int flask_iomem_permission(struct domain *d, uint64_t start, uint64_t end
     else
         data.perm = RESOURCE__REMOVE_IOMEM;
 
-    data.ssec = current->domain->ssid;
-    data.tsec = d->ssid;
+    data.ssid = domain_sid(current->domain);
+    data.dsid = domain_sid(d);
 
     return security_iterate_iomem_sids(start, end, _iomem_has_perm, &data);
 }
@@ -933,10 +945,9 @@ static int flask_iomem_mapping(struct domain *d, uint64_t start, uint64_t end, u
 
 static int flask_pci_config_permission(struct domain *d, uint32_t machine_bdf, uint16_t start, uint16_t end, uint8_t access)
 {
-    u32 rsid;
+    u32 dsid, rsid;
     int rc = -EPERM;
     struct avc_audit_data ad;
-    struct domain_security_struct *ssec;
     u32 perm = RESOURCE__USE;
 
     rc = security_device_sid(machine_bdf, &rsid);
@@ -949,33 +960,24 @@ static int flask_pci_config_permission(struct domain *d, uint32_t machine_bdf, u
 
     AVC_AUDIT_DATA_INIT(&ad, DEV);
     ad.device = (unsigned long) machine_bdf;
-    ssec = d->ssid;
-    return avc_has_perm(ssec->sid, rsid, SECCLASS_RESOURCE, perm, &ad);
+    dsid = domain_sid(d);
+    return avc_has_perm(dsid, rsid, SECCLASS_RESOURCE, perm, &ad);
 
 }
 
 static int flask_resource_plug_core(void)
 {
-    struct domain_security_struct *ssec;
-
-    ssec = current->domain->ssid;
-    return avc_has_perm(ssec->sid, SECINITSID_DOMXEN, SECCLASS_RESOURCE, RESOURCE__PLUG, NULL);
+    return avc_current_has_perm(SECINITSID_DOMXEN, SECCLASS_RESOURCE, RESOURCE__PLUG, NULL);
 }
 
 static int flask_resource_unplug_core(void)
 {
-    struct domain_security_struct *ssec;
-
-    ssec = current->domain->ssid;
-    return avc_has_perm(ssec->sid, SECINITSID_DOMXEN, SECCLASS_RESOURCE, RESOURCE__UNPLUG, NULL);
+    return avc_current_has_perm(SECINITSID_DOMXEN, SECCLASS_RESOURCE, RESOURCE__UNPLUG, NULL);
 }
 
 static int flask_resource_use_core(void)
 {
-    struct domain_security_struct *ssec;
-
-    ssec = current->domain->ssid;
-    return avc_has_perm(ssec->sid, SECINITSID_DOMXEN, SECCLASS_RESOURCE, RESOURCE__USE, NULL);
+    return avc_current_has_perm(SECINITSID_DOMXEN, SECCLASS_RESOURCE, RESOURCE__USE, NULL);
 }
 
 static int flask_resource_plug_pci(uint32_t machine_bdf)
@@ -983,7 +985,6 @@ static int flask_resource_plug_pci(uint32_t machine_bdf)
     u32 rsid;
     int rc = -EPERM;
     struct avc_audit_data ad;
-    struct domain_security_struct *ssec;
 
     rc = security_device_sid(machine_bdf, &rsid);
     if ( rc )
@@ -991,8 +992,7 @@ static int flask_resource_plug_pci(uint32_t machine_bdf)
 
     AVC_AUDIT_DATA_INIT(&ad, DEV);
     ad.device = (unsigned long) machine_bdf;
-    ssec = current->domain->ssid;
-    return avc_has_perm(ssec->sid, rsid, SECCLASS_RESOURCE, RESOURCE__PLUG, &ad);
+    return avc_current_has_perm(rsid, SECCLASS_RESOURCE, RESOURCE__PLUG, &ad);
 }
 
 static int flask_resource_unplug_pci(uint32_t machine_bdf)
@@ -1000,7 +1000,6 @@ static int flask_resource_unplug_pci(uint32_t machine_bdf)
     u32 rsid;
     int rc = -EPERM;
     struct avc_audit_data ad;
-    struct domain_security_struct *ssec;
 
     rc = security_device_sid(machine_bdf, &rsid);
     if ( rc )
@@ -1008,8 +1007,7 @@ static int flask_resource_unplug_pci(uint32_t machine_bdf)
 
     AVC_AUDIT_DATA_INIT(&ad, DEV);
     ad.device = (unsigned long) machine_bdf;
-    ssec = current->domain->ssid;
-    return avc_has_perm(ssec->sid, rsid, SECCLASS_RESOURCE, RESOURCE__UNPLUG, &ad);
+    return avc_current_has_perm(rsid, SECCLASS_RESOURCE, RESOURCE__UNPLUG, &ad);
 }
 
 static int flask_resource_setup_pci(uint32_t machine_bdf)
@@ -1017,7 +1015,6 @@ static int flask_resource_setup_pci(uint32_t machine_bdf)
     u32 rsid;
     int rc = -EPERM;
     struct avc_audit_data ad;
-    struct domain_security_struct *ssec;
 
     rc = security_device_sid(machine_bdf, &rsid);
     if ( rc )
@@ -1025,8 +1022,7 @@ static int flask_resource_setup_pci(uint32_t machine_bdf)
 
     AVC_AUDIT_DATA_INIT(&ad, DEV);
     ad.device = (unsigned long) machine_bdf;
-    ssec = current->domain->ssid;
-    return avc_has_perm(ssec->sid, rsid, SECCLASS_RESOURCE, RESOURCE__SETUP, &ad);
+    return avc_current_has_perm(rsid, SECCLASS_RESOURCE, RESOURCE__SETUP, &ad);
 }
 
 static int flask_resource_setup_gsi(int gsi)
@@ -1034,22 +1030,17 @@ static int flask_resource_setup_gsi(int gsi)
     u32 rsid;
     int rc = -EPERM;
     struct avc_audit_data ad;
-    struct domain_security_struct *ssec;
 
     rc = get_irq_sid(gsi, &rsid, &ad);
     if ( rc )
         return rc;
 
-    ssec = current->domain->ssid;
-    return avc_has_perm(ssec->sid, rsid, SECCLASS_RESOURCE, RESOURCE__SETUP, &ad);
+    return avc_current_has_perm(rsid, SECCLASS_RESOURCE, RESOURCE__SETUP, &ad);
 }
 
 static int flask_resource_setup_misc(void)
 {
-    struct domain_security_struct *ssec;
-
-    ssec = current->domain->ssid;
-    return avc_has_perm(ssec->sid, SECINITSID_XEN, SECCLASS_RESOURCE, RESOURCE__SETUP, NULL);
+    return avc_current_has_perm(SECINITSID_XEN, SECCLASS_RESOURCE, RESOURCE__SETUP, NULL);
 }
 
 static inline int flask_page_offline(uint32_t cmd)
@@ -1112,11 +1103,12 @@ static int flask_shadow_control(struct domain *d, uint32_t op)
         return -EPERM;
     }
 
-    return domain_has_perm(current->domain, d, SECCLASS_SHADOW, perm);
+    return current_has_perm(d, SECCLASS_SHADOW, perm);
 }
 
 struct ioport_has_perm_data {
-    struct domain_security_struct *ssec, *tsec;
+    u32 ssid;
+    u32 dsid;
     u32 perm;
 };
 
@@ -1130,12 +1122,12 @@ static int _ioport_has_perm(void *v, u32 sid, unsigned long start, unsigned long
     ad.range.start = start;
     ad.range.end = end;
 
-    rc = avc_has_perm(data->ssec->sid, sid, SECCLASS_RESOURCE, data->perm, &ad);
+    rc = avc_has_perm(data->ssid, sid, SECCLASS_RESOURCE, data->perm, &ad);
 
     if ( rc )
         return rc;
 
-    return avc_has_perm(data->tsec->sid, sid, SECCLASS_RESOURCE, RESOURCE__USE, &ad);
+    return avc_has_perm(data->dsid, sid, SECCLASS_RESOURCE, RESOURCE__USE, &ad);
 }
 
 static int flask_ioport_permission(struct domain *d, uint32_t start, uint32_t end, uint8_t access)
@@ -1143,7 +1135,7 @@ static int flask_ioport_permission(struct domain *d, uint32_t start, uint32_t en
     int rc;
     struct ioport_has_perm_data data;
 
-    rc = domain_has_perm(current->domain, d, SECCLASS_RESOURCE,
+    rc = current_has_perm(d, SECCLASS_RESOURCE,
                          resource_to_perm(access));
 
     if ( rc )
@@ -1154,8 +1146,8 @@ static int flask_ioport_permission(struct domain *d, uint32_t start, uint32_t en
     else
         data.perm = RESOURCE__REMOVE_IOPORT;
 
-    data.ssec = current->domain->ssid;
-    data.tsec = d->ssid;
+    data.ssid = domain_sid(current->domain);
+    data.dsid = domain_sid(d);
 
     return security_iterate_ioport_sids(start, end, _ioport_has_perm, &data);
 }
@@ -1167,18 +1159,17 @@ static int flask_ioport_mapping(struct domain *d, uint32_t start, uint32_t end,
 
 static int flask_getpageframeinfo(struct domain *d)
 {
-    return domain_has_perm(current->domain, d, SECCLASS_MMU, MMU__PAGEINFO);
+    return current_has_perm(d, SECCLASS_MMU, MMU__PAGEINFO);
 }
 
 static int flask_getmemlist(struct domain *d)
 {
-    return domain_has_perm(current->domain, d, SECCLASS_MMU, MMU__PAGELIST);
+    return current_has_perm(d, SECCLASS_MMU, MMU__PAGELIST);
 }
 
 static int flask_hypercall_init(struct domain *d)
 {
-    return domain_has_perm(current->domain, d, SECCLASS_DOMAIN,
-                           DOMAIN__HYPERCALL);
+    return current_has_perm(d, SECCLASS_DOMAIN, DOMAIN__HYPERCALL);
 }
 
 static int flask_hvmcontext(struct domain *d, uint32_t cmd)
@@ -1201,7 +1192,7 @@ static int flask_hvmcontext(struct domain *d, uint32_t cmd)
         return -EPERM;
     }
 
-    return domain_has_perm(current->domain, d, SECCLASS_HVM, perm);
+    return current_has_perm(d, SECCLASS_HVM, perm);
 }
 
 static int flask_address_size(struct domain *d, uint32_t cmd)
@@ -1220,7 +1211,7 @@ static int flask_address_size(struct domain *d, uint32_t cmd)
         return -EPERM;
     }
 
-    return domain_has_perm(current->domain, d, SECCLASS_DOMAIN, perm);
+    return current_has_perm(d, SECCLASS_DOMAIN, perm);
 }
 
 static int flask_machine_address_size(struct domain *d, uint32_t cmd)
@@ -1261,37 +1252,37 @@ static int flask_hvm_param(struct domain *d, unsigned long op)
         perm = HVM__HVMCTL;
     }
 
-    return domain_has_perm(current->domain, d, SECCLASS_HVM, perm);
+    return current_has_perm(d, SECCLASS_HVM, perm);
 }
 
 static int flask_hvm_set_pci_intx_level(struct domain *d)
 {
-    return domain_has_perm(current->domain, d, SECCLASS_HVM, HVM__PCILEVEL);
+    return current_has_perm(d, SECCLASS_HVM, HVM__PCILEVEL);
 }
 
 static int flask_hvm_set_isa_irq_level(struct domain *d)
 {
-    return domain_has_perm(current->domain, d, SECCLASS_HVM, HVM__IRQLEVEL);
+    return current_has_perm(d, SECCLASS_HVM, HVM__IRQLEVEL);
 }
 
 static int flask_hvm_set_pci_link_route(struct domain *d)
 {
-    return domain_has_perm(current->domain, d, SECCLASS_HVM, HVM__PCIROUTE);
+    return current_has_perm(d, SECCLASS_HVM, HVM__PCIROUTE);
 }
 
 static int flask_hvm_inject_msi(struct domain *d)
 {
-    return domain_has_perm(current->domain, d, SECCLASS_HVM, HVM__SEND_IRQ);
+    return current_has_perm(d, SECCLASS_HVM, HVM__SEND_IRQ);
 }
 
 static int flask_mem_event(struct domain *d)
 {
-    return domain_has_perm(current->domain, d, SECCLASS_HVM, HVM__MEM_EVENT);
+    return current_has_perm(d, SECCLASS_HVM, HVM__MEM_EVENT);
 }
 
 static int flask_mem_sharing(struct domain *d)
 {
-    return domain_has_perm(current->domain, d, SECCLASS_HVM, HVM__MEM_SHARING);
+    return current_has_perm(d, SECCLASS_HVM, HVM__MEM_SHARING);
 }
 
 static int flask_apic(struct domain *d, int cmd)
@@ -1353,11 +1344,7 @@ static int flask_physinfo(void)
 
 static int flask_platform_quirk(uint32_t quirk)
 {
-    struct domain_security_struct *dsec;
-    dsec = current->domain->ssid;
-
-    return avc_has_perm(dsec->sid, SECINITSID_XEN, SECCLASS_XEN, 
-                        XEN__QUIRK, NULL);
+    return avc_current_has_perm(SECINITSID_XEN, SECCLASS_XEN, XEN__QUIRK, NULL);
 }
 
 static int flask_platform_op(uint32_t op)
@@ -1419,16 +1406,12 @@ static int flask_getidletime(void)
 
 static int flask_machine_memory_map(void)
 {
-    struct domain_security_struct *dsec;
-    dsec = current->domain->ssid;
-
-    return avc_has_perm(dsec->sid, SECINITSID_XEN, SECCLASS_MMU, 
-                        MMU__MEMORYMAP, NULL);
+    return avc_current_has_perm(SECINITSID_XEN, SECCLASS_MMU, MMU__MEMORYMAP, NULL);
 }
 
 static int flask_domain_memory_map(struct domain *d)
 {
-    return domain_has_perm(current->domain, d, SECCLASS_MMU, MMU__MEMORYMAP);
+    return current_has_perm(d, SECCLASS_MMU, MMU__MEMORYMAP);
 }
 
 static int domain_memory_perm(struct domain *d, struct domain *f, l1_pgentry_t pte)
@@ -1451,17 +1434,17 @@ static int domain_memory_perm(struct domain *d, struct domain *f, l1_pgentry_t p
     if ( f->domain_id == DOMID_IO || !mfn_valid(fmfn) )
     {
         struct avc_audit_data ad;
-        struct domain_security_struct *dsec = d->ssid;
-        u32 fsid;
+        u32 dsid, fsid;
+        rc = security_iomem_sid(fmfn, &fsid);
+        if ( rc )
+            return rc;
         AVC_AUDIT_DATA_INIT(&ad, MEMORY);
         ad.sdom = d;
         ad.tdom = f;
         ad.memory.pte = pte.l1;
         ad.memory.mfn = fmfn;
-        rc = security_iomem_sid(fmfn, &fsid);
-        if ( rc )
-            return rc;
-        return avc_has_perm(dsec->sid, fsid, SECCLASS_MMU, map_perms, &ad);
+        dsid = domain_sid(d);
+        return avc_has_perm(dsid, fsid, SECCLASS_MMU, map_perms, &ad);
     }
 
     return domain_has_perm(d, f, SECCLASS_MMU, map_perms);
@@ -1504,43 +1487,40 @@ static int flask_remove_from_physmap(struct domain *d1, struct domain *d2)
 
 static int flask_sendtrigger(struct domain *d)
 {
-    return domain_has_perm(current->domain, d, SECCLASS_DOMAIN, DOMAIN__TRIGGER);
+    return current_has_perm(d, SECCLASS_DOMAIN, DOMAIN__TRIGGER);
 }
 
 static int flask_get_device_group(uint32_t machine_bdf)
 {
     u32 rsid;
     int rc = -EPERM;
-    struct domain_security_struct *ssec = current->domain->ssid;
 
     rc = security_device_sid(machine_bdf, &rsid);
     if ( rc )
         return rc;
 
-    return avc_has_perm(ssec->sid, rsid, SECCLASS_RESOURCE, RESOURCE__STAT_DEVICE, NULL);
+    return avc_current_has_perm(rsid, SECCLASS_RESOURCE, RESOURCE__STAT_DEVICE, NULL);
 }
 
 static int flask_test_assign_device(uint32_t machine_bdf)
 {
     u32 rsid;
     int rc = -EPERM;
-    struct domain_security_struct *ssec = current->domain->ssid;
 
     rc = security_device_sid(machine_bdf, &rsid);
     if ( rc )
         return rc;
 
-    return rc = avc_has_perm(ssec->sid, rsid, SECCLASS_RESOURCE, RESOURCE__STAT_DEVICE, NULL);
+    return avc_current_has_perm(rsid, SECCLASS_RESOURCE, RESOURCE__STAT_DEVICE, NULL);
 }
 
 static int flask_assign_device(struct domain *d, uint32_t machine_bdf)
 {
-    u32 rsid;
+    u32 dsid, rsid;
     int rc = -EPERM;
-    struct domain_security_struct *ssec, *tsec;
     struct avc_audit_data ad;
 
-    rc = domain_has_perm(current->domain, d, SECCLASS_RESOURCE, RESOURCE__ADD);
+    rc = current_has_perm(d, SECCLASS_RESOURCE, RESOURCE__ADD);
     if ( rc )
         return rc;
 
@@ -1550,22 +1530,20 @@ static int flask_assign_device(struct domain *d, uint32_t machine_bdf)
 
     AVC_AUDIT_DATA_INIT(&ad, DEV);
     ad.device = (unsigned long) machine_bdf;
-    ssec = current->domain->ssid;
-    rc = avc_has_perm(ssec->sid, rsid, SECCLASS_RESOURCE, RESOURCE__ADD_DEVICE, &ad);
+    rc = avc_current_has_perm(rsid, SECCLASS_RESOURCE, RESOURCE__ADD_DEVICE, &ad);
     if ( rc )
         return rc;
 
-    tsec = d->ssid;
-    return avc_has_perm(tsec->sid, rsid, SECCLASS_RESOURCE, RESOURCE__USE, &ad);
+    dsid = domain_sid(d);
+    return avc_has_perm(dsid, rsid, SECCLASS_RESOURCE, RESOURCE__USE, &ad);
 }
 
 static int flask_deassign_device(struct domain *d, uint32_t machine_bdf)
 {
     u32 rsid;
     int rc = -EPERM;
-    struct domain_security_struct *ssec = current->domain->ssid;
 
-    rc = domain_has_perm(current->domain, d, SECCLASS_RESOURCE, RESOURCE__REMOVE);
+    rc = current_has_perm(d, SECCLASS_RESOURCE, RESOURCE__REMOVE);
     if ( rc )
         return rc;
 
@@ -1573,18 +1551,17 @@ static int flask_deassign_device(struct domain *d, uint32_t machine_bdf)
     if ( rc )
         return rc;
 
-    return rc = avc_has_perm(ssec->sid, rsid, SECCLASS_RESOURCE, RESOURCE__REMOVE_DEVICE, NULL);
+    return avc_current_has_perm(rsid, SECCLASS_RESOURCE, RESOURCE__REMOVE_DEVICE, NULL);
 }
 
 static int flask_bind_pt_irq (struct domain *d, struct xen_domctl_bind_pt_irq *bind)
 {
-    u32 rsid;
+    u32 dsid, rsid;
     int rc = -EPERM;
     int irq;
-    struct domain_security_struct *ssec, *tsec;
     struct avc_audit_data ad;
 
-    rc = domain_has_perm(current->domain, d, SECCLASS_RESOURCE, RESOURCE__ADD);
+    rc = current_has_perm(d, SECCLASS_RESOURCE, RESOURCE__ADD);
     if ( rc )
         return rc;
 
@@ -1594,23 +1571,22 @@ static int flask_bind_pt_irq (struct domain *d, struct xen_domctl_bind_pt_irq *b
     if ( rc )
         return rc;
 
-    ssec = current->domain->ssid;
-    rc = avc_has_perm(ssec->sid, rsid, SECCLASS_HVM, HVM__BIND_IRQ, &ad);
+    rc = avc_current_has_perm(rsid, SECCLASS_HVM, HVM__BIND_IRQ, &ad);
     if ( rc )
         return rc;
 
-    tsec = d->ssid;
-    return avc_has_perm(tsec->sid, rsid, SECCLASS_RESOURCE, RESOURCE__USE, &ad);
+    dsid = domain_sid(d);
+    return avc_has_perm(dsid, rsid, SECCLASS_RESOURCE, RESOURCE__USE, &ad);
 }
 
 static int flask_unbind_pt_irq (struct domain *d, struct xen_domctl_bind_pt_irq *bind)
 {
-    return domain_has_perm(current->domain, d, SECCLASS_RESOURCE, RESOURCE__REMOVE);
+    return current_has_perm(d, SECCLASS_RESOURCE, RESOURCE__REMOVE);
 }
 
 static int flask_pin_mem_cacheattr (struct domain *d)
 {
-    return domain_has_perm(current->domain, d, SECCLASS_HVM, HVM__CACHEATTR);
+    return current_has_perm(d, SECCLASS_HVM, HVM__CACHEATTR);
 }
 
 static int flask_ext_vcpucontext (struct domain *d, uint32_t cmd)
@@ -1629,7 +1605,7 @@ static int flask_ext_vcpucontext (struct domain *d, uint32_t cmd)
         return -EPERM;
     }
 
-    return domain_has_perm(current->domain, d, SECCLASS_DOMAIN, perm);
+    return current_has_perm(d, SECCLASS_DOMAIN, perm);
 }
 
 static int flask_vcpuextstate (struct domain *d, uint32_t cmd)
@@ -1648,7 +1624,7 @@ static int flask_vcpuextstate (struct domain *d, uint32_t cmd)
             return -EPERM;
     }
 
-    return domain_has_perm(current->domain, d, SECCLASS_DOMAIN, perm);
+    return current_has_perm(d, SECCLASS_DOMAIN, perm);
 }
 #endif
 
diff --git a/xen/xsm/flask/include/objsec.h b/xen/xsm/flask/include/objsec.h
index 4ff52be..6595dc3 100644
--- a/xen/xsm/flask/include/objsec.h
+++ b/xen/xsm/flask/include/objsec.h
@@ -19,6 +19,8 @@
 
 struct domain_security_struct {
     u32 sid;               /* current SID */
+    u32 self_sid;          /* SID for target when operating on DOMID_SELF */
+    u32 target_sid;        /* SID for device model target domain */
 };
 
 struct evtchn_security_struct {
-- 
1.7.11.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 12 16:00:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Sep 2012 16:00:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TBpMG-0005qY-11; Wed, 12 Sep 2012 16:00:08 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1TBpMC-0005PB-Ks
	for xen-devel@lists.xen.org; Wed, 12 Sep 2012 16:00:04 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-5.tower-27.messagelabs.com!1347465597!7348032!1
X-Originating-IP: [63.239.67.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12354 invoked from network); 12 Sep 2012 15:59:58 -0000
Received: from emvm-gh1-uea09.nsa.gov (HELO nsa.gov) (63.239.67.10)
	by server-5.tower-27.messagelabs.com with SMTP;
	12 Sep 2012 15:59:58 -0000
X-TM-IMSS-Message-ID: <39e12935001083e0@nsa.gov>
Received: from tarius.tycho.ncsc.mil ([144.51.3.1]) by nsa.gov
	([63.239.67.10]) with ESMTP (TREND IMSS SMTP Service 7.1) id
	39e12935001083e0 ; Wed, 12 Sep 2012 12:02:04 -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 q8CFxoOV006669; 
	Wed, 12 Sep 2012 11:59:56 -0400
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xen.org
Date: Wed, 12 Sep 2012 11:59:45 -0400
Message-Id: <1347465586-20009-22-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.11.4
In-Reply-To: <1347465586-20009-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1347465586-20009-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: dgdegra@tycho.nsa.gov, Keir Fraser <keir@xen.org>
Subject: [Xen-devel] [PATCH 21/22] xen: Add XSM hook for XENMEM_exchange
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Cc: Keir Fraser <keir@xen.org>
---
 tools/flask/policy/policy/flask/access_vectors |  1 +
 tools/flask/policy/policy/modules/xen/xen.if   |  2 ++
 xen/common/memory.c                            | 12 +++++++++++-
 xen/include/xsm/dummy.h                        |  7 +++++++
 xen/include/xsm/xsm.h                          |  6 ++++++
 xen/xsm/dummy.c                                |  1 +
 xen/xsm/flask/hooks.c                          |  6 ++++++
 xen/xsm/flask/include/av_perm_to_string.h      |  1 +
 xen/xsm/flask/include/av_permissions.h         |  1 +
 9 files changed, 36 insertions(+), 1 deletion(-)

diff --git a/tools/flask/policy/policy/flask/access_vectors b/tools/flask/policy/policy/flask/access_vectors
index 8324725..caf65d2 100644
--- a/tools/flask/policy/policy/flask/access_vectors
+++ b/tools/flask/policy/policy/flask/access_vectors
@@ -142,6 +142,7 @@ class mmu
     memorymap
     remote_remap
 	mmuext_op
+	exchange
 }
 
 class shadow
diff --git a/tools/flask/policy/policy/modules/xen/xen.if b/tools/flask/policy/policy/modules/xen/xen.if
index 725d7a1..67f5daf 100644
--- a/tools/flask/policy/policy/modules/xen/xen.if
+++ b/tools/flask/policy/policy/modules/xen/xen.if
@@ -30,6 +30,7 @@ define(`declare_domain', `
 #   containing at most one domain. This is not enforced by policy.
 define(`declare_singleton_domain', `
 	type $1, domain_type`'ifelse(`$#', `1', `', `,shift($@)');
+	define(`$1_self', `$1')
 	type $1_channel, event_type;
 	type_transition $1 domain_type:event $1_channel;
 	declare_domain_common($1, $1)
@@ -161,6 +162,7 @@ define(`make_device_model', `
 # use_device(domain, device)
 #   Allow a device to be used by a domain
 define(`use_device', `
+    allow $1 $1_self:mmu exchange;
     allow $1 $2:resource use;
     allow $1 $2:mmu { map_read map_write };
 ')
diff --git a/xen/common/memory.c b/xen/common/memory.c
index cfdd63f..a5b548b 100644
--- a/xen/common/memory.c
+++ b/xen/common/memory.c
@@ -329,9 +329,19 @@ static long memory_exchange(XEN_GUEST_HANDLE(xen_memory_exchange_t) arg)
         out_chunk_order = exch.in.extent_order - exch.out.extent_order;
     }
 
-    rc = rcu_lock_target_domain_by_id(exch.in.domid, &d);
+    d = rcu_lock_domain_by_any_id(exch.in.domid);
+    if ( d == NULL )
+    {
+        rc = -ESRCH;
+        goto fail_early;
+    }
+
+    rc = xsm_memory_exchange(d);
     if ( rc )
+    {
+        rcu_unlock_domain(d);
         goto fail_early;
+    }
 
     memflags |= MEMF_bits(domain_clamp_alloc_bitsize(
         d,
diff --git a/xen/include/xsm/dummy.h b/xen/include/xsm/dummy.h
index 9c13d5c037..e5e8020 100644
--- a/xen/include/xsm/dummy.h
+++ b/xen/include/xsm/dummy.h
@@ -235,6 +235,13 @@ static XSM_DEFAULT(int, grant_query_size) (struct domain *d1, struct domain *d2)
     return 0;
 }
 
+static XSM_DEFAULT(int, memory_exchange) (struct domain *d)
+{
+    if ( d != current->domain && !IS_PRIV_FOR(current->domain, d) )
+        return -EPERM;
+    return 0;
+}
+
 static XSM_DEFAULT(int, memory_adjust_reservation) (struct domain *d1,
                                                             struct domain *d2)
 {
diff --git a/xen/include/xsm/xsm.h b/xen/include/xsm/xsm.h
index 6d970b1..46d5cd6 100644
--- a/xen/include/xsm/xsm.h
+++ b/xen/include/xsm/xsm.h
@@ -96,6 +96,7 @@ struct xsm_operations {
 
     int (*get_pod_target) (struct domain *d);
     int (*set_pod_target) (struct domain *d);
+    int (*memory_exchange) (struct domain *d);
     int (*memory_adjust_reservation) (struct domain *d1, struct domain *d2);
     int (*memory_stat_reservation) (struct domain *d1, struct domain *d2);
     int (*memory_pin_page) (struct domain *d1, struct domain *d2, struct page_info *page);
@@ -451,6 +452,11 @@ static inline int xsm_set_pod_target (struct domain *d)
     return xsm_ops->set_pod_target(d);
 }
 
+static inline int xsm_memory_exchange (struct domain *d)
+{
+    return xsm_ops->memory_exchange(d);
+}
+
 static inline int xsm_memory_adjust_reservation (struct domain *d1, struct
                                                                     domain *d2)
 {
diff --git a/xen/xsm/dummy.c b/xen/xsm/dummy.c
index 9476be6..ddaf40b 100644
--- a/xen/xsm/dummy.c
+++ b/xen/xsm/dummy.c
@@ -83,6 +83,7 @@ void xsm_fixup_ops (struct xsm_operations *ops)
     set_to_dummy_if_null(ops, get_pod_target);
     set_to_dummy_if_null(ops, set_pod_target);
 
+    set_to_dummy_if_null(ops, memory_exchange);
     set_to_dummy_if_null(ops, memory_adjust_reservation);
     set_to_dummy_if_null(ops, memory_stat_reservation);
     set_to_dummy_if_null(ops, memory_pin_page);
diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
index bd2d792..2f33a9f 100644
--- a/xen/xsm/flask/hooks.c
+++ b/xen/xsm/flask/hooks.c
@@ -396,6 +396,11 @@ static int flask_set_pod_target(struct domain *d)
     return current_has_perm(d, SECCLASS_DOMAIN, DOMAIN__SETPODTARGET);
 }
 
+static int flask_memory_exchange(struct domain *d)
+{
+    return current_has_perm(d, SECCLASS_MMU, MMU__EXCHANGE);
+}
+
 static int flask_memory_adjust_reservation(struct domain *d1, struct domain *d2)
 {
     return domain_has_perm(d1, d2, SECCLASS_MMU, MMU__ADJUST);
@@ -1683,6 +1688,7 @@ static struct xsm_operations flask_ops = {
 
     .get_pod_target = flask_get_pod_target,
     .set_pod_target = flask_set_pod_target,
+    .memory_exchange = flask_memory_exchange,
     .memory_adjust_reservation = flask_memory_adjust_reservation,
     .memory_stat_reservation = flask_memory_stat_reservation,
     .memory_pin_page = flask_memory_pin_page,
diff --git a/xen/xsm/flask/include/av_perm_to_string.h b/xen/xsm/flask/include/av_perm_to_string.h
index 8f65b96..79d5939 100644
--- a/xen/xsm/flask/include/av_perm_to_string.h
+++ b/xen/xsm/flask/include/av_perm_to_string.h
@@ -112,6 +112,7 @@
    S_(SECCLASS_MMU, MMU__MEMORYMAP, "memorymap")
    S_(SECCLASS_MMU, MMU__REMOTE_REMAP, "remote_remap")
    S_(SECCLASS_MMU, MMU__MMUEXT_OP, "mmuext_op")
+   S_(SECCLASS_MMU, MMU__EXCHANGE, "exchange")
    S_(SECCLASS_SHADOW, SHADOW__DISABLE, "disable")
    S_(SECCLASS_SHADOW, SHADOW__ENABLE, "enable")
    S_(SECCLASS_SHADOW, SHADOW__LOGDIRTY, "logdirty")
diff --git a/xen/xsm/flask/include/av_permissions.h b/xen/xsm/flask/include/av_permissions.h
index 18454fd..d982328 100644
--- a/xen/xsm/flask/include/av_permissions.h
+++ b/xen/xsm/flask/include/av_permissions.h
@@ -118,6 +118,7 @@
 #define MMU__MEMORYMAP                            0x00000800UL
 #define MMU__REMOTE_REMAP                         0x00001000UL
 #define MMU__MMUEXT_OP                            0x00002000UL
+#define MMU__EXCHANGE                             0x00004000UL
 
 #define SHADOW__DISABLE                           0x00000001UL
 #define SHADOW__ENABLE                            0x00000002UL
-- 
1.7.11.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 12 16:00:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Sep 2012 16:00: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 1TBpM5-0005Nu-Hu; Wed, 12 Sep 2012 15:59:57 +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 1TBpM4-0005Mm-6Q
	for xen-devel@lists.xen.org; Wed, 12 Sep 2012 15:59:56 +0000
Received: from [85.158.138.51:26808] by server-7.bemta-3.messagelabs.com id
	BB/07-32000-B71B0505; Wed, 12 Sep 2012 15:59:55 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-4.tower-174.messagelabs.com!1347465594!29693437!1
X-Originating-IP: [63.239.67.9]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31507 invoked from network); 12 Sep 2012 15:59:54 -0000
Received: from emvm-gh1-uea08.nsa.gov (HELO nsa.gov) (63.239.67.9)
	by server-4.tower-174.messagelabs.com with SMTP;
	12 Sep 2012 15:59:54 -0000
X-TM-IMSS-Message-ID: <39e15e5800102347@nsa.gov>
Received: from tarius.tycho.ncsc.mil ([144.51.3.1]) by nsa.gov ([63.239.67.9])
	with ESMTP (TREND IMSS SMTP Service 7.1) id 39e15e5800102347 ;
	Wed, 12 Sep 2012 11:59:44 -0400
Received: from moss-nexus.epoch.ncsc.mil (moss-nexus [144.51.25.48])
	by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id q8CFxoOI006669; 
	Wed, 12 Sep 2012 11:59:52 -0400
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xen.org
Date: Wed, 12 Sep 2012 11:59:32 -0400
Message-Id: <1347465586-20009-9-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.11.4
In-Reply-To: <1347465586-20009-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1347465586-20009-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: dgdegra@tycho.nsa.gov
Subject: [Xen-devel] [PATCH 08/22] xsm/flask: Add checks on the domain
	performing the set_target 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>
MIME-Version: 1.0
Content-Type: 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 existing domain__set_target check only verifies that the source and
target domains can be associated. We also need to check that the
privileged domain making this association is allowed to do so.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 tools/flask/policy/policy/flask/access_vectors | 2 ++
 xen/xsm/flask/hooks.c                          | 7 +++++++
 xen/xsm/flask/include/av_perm_to_string.h      | 2 ++
 xen/xsm/flask/include/av_permissions.h         | 2 ++
 4 files changed, 13 insertions(+)

diff --git a/tools/flask/policy/policy/flask/access_vectors b/tools/flask/policy/policy/flask/access_vectors
index c7e29ab..11d02da 100644
--- a/tools/flask/policy/policy/flask/access_vectors
+++ b/tools/flask/policy/policy/flask/access_vectors
@@ -78,6 +78,8 @@ class domain2
 	relabelfrom
 	relabelto
 	relabelself
+	make_priv_for
+	set_as_target
 }
 
 class hvm
diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
index 74c9271..6d4b4f0 100644
--- a/xen/xsm/flask/hooks.c
+++ b/xen/xsm/flask/hooks.c
@@ -577,6 +577,13 @@ static int flask_domain_settime(struct domain *d)
 
 static int flask_set_target(struct domain *d, struct domain *e)
 {
+    int rc;
+    rc = domain_has_perm(current->domain, d, SECCLASS_DOMAIN2, DOMAIN2__MAKE_PRIV_FOR);
+    if ( rc )
+        return rc;
+    rc = domain_has_perm(current->domain, e, SECCLASS_DOMAIN2, DOMAIN2__SET_AS_TARGET);
+    if ( rc )
+        return rc;
     return domain_has_perm(d, e, SECCLASS_DOMAIN, DOMAIN__SET_TARGET);
 }
 
diff --git a/xen/xsm/flask/include/av_perm_to_string.h b/xen/xsm/flask/include/av_perm_to_string.h
index e7e2058..10f8e80 100644
--- a/xen/xsm/flask/include/av_perm_to_string.h
+++ b/xen/xsm/flask/include/av_perm_to_string.h
@@ -64,6 +64,8 @@
    S_(SECCLASS_DOMAIN2, DOMAIN2__RELABELFROM, "relabelfrom")
    S_(SECCLASS_DOMAIN2, DOMAIN2__RELABELTO, "relabelto")
    S_(SECCLASS_DOMAIN2, DOMAIN2__RELABELSELF, "relabelself")
+   S_(SECCLASS_DOMAIN2, DOMAIN2__MAKE_PRIV_FOR, "make_priv_for")
+   S_(SECCLASS_DOMAIN2, DOMAIN2__SET_AS_TARGET, "set_as_target")
    S_(SECCLASS_HVM, HVM__SETHVMC, "sethvmc")
    S_(SECCLASS_HVM, HVM__GETHVMC, "gethvmc")
    S_(SECCLASS_HVM, HVM__SETPARAM, "setparam")
diff --git a/xen/xsm/flask/include/av_permissions.h b/xen/xsm/flask/include/av_permissions.h
index cb1c5dc..f7cfee1 100644
--- a/xen/xsm/flask/include/av_permissions.h
+++ b/xen/xsm/flask/include/av_permissions.h
@@ -66,6 +66,8 @@
 #define DOMAIN2__RELABELFROM                      0x00000001UL
 #define DOMAIN2__RELABELTO                        0x00000002UL
 #define DOMAIN2__RELABELSELF                      0x00000004UL
+#define DOMAIN2__MAKE_PRIV_FOR                    0x00000008UL
+#define DOMAIN2__SET_AS_TARGET                    0x00000010UL
 
 #define HVM__SETHVMC                              0x00000001UL
 #define HVM__GETHVMC                              0x00000002UL
-- 
1.7.11.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 12 16:00:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Sep 2012 16:00: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 1TBpME-0005nx-RR; Wed, 12 Sep 2012 16:00:06 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1TBpMB-0005OV-Nl
	for xen-devel@lists.xen.org; Wed, 12 Sep 2012 16:00:04 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-16.tower-27.messagelabs.com!1347465594!9333739!1
X-Originating-IP: [63.239.67.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6788 invoked from network); 12 Sep 2012 15:59:55 -0000
Received: from emvm-gh1-uea09.nsa.gov (HELO nsa.gov) (63.239.67.10)
	by server-16.tower-27.messagelabs.com with SMTP;
	12 Sep 2012 15:59:55 -0000
X-TM-IMSS-Message-ID: <39e11bcd001083d2@nsa.gov>
Received: from tarius.tycho.ncsc.mil ([144.51.3.1]) by nsa.gov
	([63.239.67.10]) with ESMTP (TREND IMSS SMTP Service 7.1) id
	39e11bcd001083d2 ; Wed, 12 Sep 2012 12:02:00 -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 q8CFxoOJ006669; 
	Wed, 12 Sep 2012 11:59:53 -0400
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xen.org
Date: Wed, 12 Sep 2012 11:59:33 -0400
Message-Id: <1347465586-20009-10-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.11.4
In-Reply-To: <1347465586-20009-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1347465586-20009-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: dgdegra@tycho.nsa.gov, Keir Fraser <keir@xen.org>,
	Jan Beulich <jbeulich@suse.com>
Subject: [Xen-devel] [PATCH 09/22] xsm: Use the dummy XSM module if XSM is
	disabled
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/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 moves the implementation of the dummy XSM module to a header
file that provides inline functions when XSM_ENABLE is not defined. This
reduces duplication between the dummy module and callers when the
implementation of the dummy return is not just "return 0", and also
provides better compile-time checking for completeness of the XSM
implementations in the dummy module.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Cc: Keir Fraser <keir@xen.org>
Cc: Jan Beulich <jbeulich@suse.com>
---
 xen/common/domctl.c     |   2 -
 xen/include/xsm/dummy.h | 628 ++++++++++++++++++++++++++++++++++++++++++++++++
 xen/include/xsm/xsm.h   | 290 +++++++++++-----------
 xen/xsm/dummy.c         | 617 +----------------------------------------------
 xen/xsm/xsm_core.c      |   2 +-
 5 files changed, 772 insertions(+), 767 deletions(-)
 create mode 100644 xen/include/xsm/dummy.h

diff --git a/xen/common/domctl.c b/xen/common/domctl.c
index 2b1f182..d99ba67 100644
--- a/xen/common/domctl.c
+++ b/xen/common/domctl.c
@@ -267,10 +267,8 @@ long do_domctl(XEN_GUEST_HANDLE(xen_domctl_t) u_domctl)
             return -EPERM;
         break;
     }
-#ifdef XSM_ENABLE
     case XEN_DOMCTL_getdomaininfo:
         break;
-#endif
     default:
         if ( !IS_PRIV(current->domain) )
             return -EPERM;
diff --git a/xen/include/xsm/dummy.h b/xen/include/xsm/dummy.h
new file mode 100644
index 0000000..61c6f13
--- /dev/null
+++ b/xen/include/xsm/dummy.h
@@ -0,0 +1,628 @@
+/*
+ *  Default XSM hooks - IS_PRIV and IS_PRIV_FOR checks
+ *
+ *  Author: Daniel De Graaf <dgdegra@tyhco.nsa.gov>
+ *
+ *  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.
+ */
+
+#include <xen/sched.h>
+#include <xsm/xsm.h>
+
+static XSM_DEFAULT(void, security_domaininfo)(struct domain *d,
+                                    struct xen_domctl_getdomaininfo *info)
+{
+    return;
+}
+
+static XSM_DEFAULT(int, setvcpucontext)(struct domain *d)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, pausedomain) (struct domain *d)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, unpausedomain) (struct domain *d)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, resumedomain) (struct domain *d)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, domain_create)(struct domain *d, u32 ssidref)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, max_vcpus)(struct domain *d)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, destroydomain) (struct domain *d)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, vcpuaffinity) (int cmd, struct domain *d)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, scheduler) (struct domain *d)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, getdomaininfo) (struct domain *d)
+{
+    if ( !IS_PRIV(current->domain) )
+        return -EPERM;
+    return 0;
+}
+
+static XSM_DEFAULT(int, getvcpucontext) (struct domain *d)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, getvcpuinfo) (struct domain *d)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, domain_settime) (struct domain *d)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, set_target) (struct domain *d, struct domain *e)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, domctl)(struct domain *d, int cmd)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, set_virq_handler)(struct domain *d, uint32_t virq)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, tbufcontrol) (void)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, readconsole) (uint32_t clear)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, sched_id) (void)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, setdomainmaxmem) (struct domain *d)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, setdomainhandle) (struct domain *d)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, setdebugging) (struct domain *d)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, perfcontrol) (void)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, debug_keys) (void)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, getcpuinfo) (void)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, get_pmstat) (void)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, setpminfo) (void)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, pm_op) (void)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, do_mca) (void)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, availheap) (void)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, alloc_security_domain) (struct domain *d)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(void, free_security_domain) (struct domain *d)
+{
+    return;
+}
+
+static XSM_DEFAULT(int, grant_mapref) (struct domain *d1, struct domain *d2,
+                                                                uint32_t flags)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, grant_unmapref) (struct domain *d1, struct domain *d2)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, grant_setup) (struct domain *d1, struct domain *d2)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, grant_transfer) (struct domain *d1, struct domain *d2)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, grant_copy) (struct domain *d1, struct domain *d2)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, grant_query_size) (struct domain *d1, struct domain *d2)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, memory_adjust_reservation) (struct domain *d1,
+                                                            struct domain *d2)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, memory_stat_reservation) (struct domain *d1, struct domain *d2)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, console_io) (struct domain *d, int cmd)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, profile) (struct domain *d, int op)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, kexec) (void)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, schedop_shutdown) (struct domain *d1, struct domain *d2)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, memory_pin_page) (struct domain *d1, struct domain *d2,
+                                          struct page_info *page)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, evtchn_unbound) (struct domain *d, struct evtchn *chn,
+                                         domid_t id2)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, evtchn_interdomain) (struct domain *d1, struct evtchn
+                                *chan1, struct domain *d2, struct evtchn *chan2)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(void, evtchn_close_post) (struct evtchn *chn)
+{
+    return;
+}
+
+static XSM_DEFAULT(int, evtchn_send) (struct domain *d, struct evtchn *chn)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, evtchn_status) (struct domain *d, struct evtchn *chn)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, evtchn_reset) (struct domain *d1, struct domain *d2)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, alloc_security_evtchn) (struct evtchn *chn)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(void, free_security_evtchn) (struct evtchn *chn)
+{
+    return;
+}
+
+static XSM_DEFAULT(char *, show_security_evtchn) (struct domain *d, const struct evtchn *chn)
+{
+    return NULL;
+}
+
+static XSM_DEFAULT(int, get_pod_target)(struct domain *d)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, set_pod_target)(struct domain *d)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, get_device_group) (uint32_t machine_bdf)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, test_assign_device) (uint32_t machine_bdf)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, assign_device) (struct domain *d, uint32_t machine_bdf)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, deassign_device) (struct domain *d, uint32_t machine_bdf)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, resource_plug_core) (void)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, resource_unplug_core) (void)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, resource_plug_pci) (uint32_t machine_bdf)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, resource_unplug_pci) (uint32_t machine_bdf)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, resource_setup_pci) (uint32_t machine_bdf)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, resource_setup_gsi) (int gsi)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, resource_setup_misc) (void)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, page_offline) (uint32_t cmd)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, lockprof) (void)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, cpupool_op) (void)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, sched_op) (void)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(long, __do_xsm_op)(XEN_GUEST_HANDLE(xsm_op_t) op)
+{
+    return -ENOSYS;
+}
+
+static XSM_DEFAULT(char *, show_irq_sid) (int irq)
+{
+    return NULL;
+}
+
+static XSM_DEFAULT(int, map_domain_pirq) (struct domain *d, int irq, void *data)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, unmap_domain_pirq) (struct domain *d, int irq)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, irq_permission) (struct domain *d, int pirq, uint8_t allow)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, iomem_permission) (struct domain *d, uint64_t s, uint64_t e, uint8_t allow)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, iomem_mapping) (struct domain *d, uint64_t s, uint64_t e, uint8_t allow)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, pci_config_permission) (struct domain *d, uint32_t machine_bdf,
+                                        uint16_t start, uint16_t end,
+                                        uint8_t access)
+{
+    return 0;
+}
+
+#ifdef CONFIG_X86
+static XSM_DEFAULT(int, shadow_control) (struct domain *d, uint32_t op)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, getpageframeinfo) (struct domain *d)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, getmemlist) (struct domain *d)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, hypercall_init) (struct domain *d)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, hvmcontext) (struct domain *d, uint32_t cmd)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, address_size) (struct domain *d, uint32_t cmd)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, machine_address_size) (struct domain *d, uint32_t cmd)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, hvm_param) (struct domain *d, unsigned long op)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, hvm_set_pci_intx_level) (struct domain *d)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, hvm_set_isa_irq_level) (struct domain *d)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, hvm_set_pci_link_route) (struct domain *d)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, hvm_inject_msi) (struct domain *d)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, mem_event) (struct domain *d)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, mem_sharing) (struct domain *d)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, apic) (struct domain *d, int cmd)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, xen_settime) (void)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, memtype) (uint32_t access)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, microcode) (void)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, physinfo) (void)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, platform_quirk) (uint32_t quirk)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, firmware_info) (void)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, efi_call) (void)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, acpi_sleep) (void)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, change_freq) (void)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, getidletime) (void)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, machine_memory_map) (void)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, domain_memory_map) (struct domain *d)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, mmu_normal_update) (struct domain *d, struct domain *t,
+                                            struct domain *f, intpte_t fpte)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, mmu_machphys_update) (struct domain *d, struct domain *f,
+                                              unsigned long mfn)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, update_va_mapping) (struct domain *d, struct domain *f, 
+                                                            l1_pgentry_t pte)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, add_to_physmap) (struct domain *d1, struct domain *d2)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, remove_from_physmap) (struct domain *d1, struct domain *d2)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, sendtrigger) (struct domain *d)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, bind_pt_irq) (struct domain *d, struct xen_domctl_bind_pt_irq *bind)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, unbind_pt_irq) (struct domain *d, struct xen_domctl_bind_pt_irq *bind)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, pin_mem_cacheattr) (struct domain *d)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, ext_vcpucontext) (struct domain *d, uint32_t cmd)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, vcpuextstate) (struct domain *d, uint32_t cmd)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, ioport_permission) (struct domain *d, uint32_t s, uint32_t e, uint8_t allow)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, ioport_mapping) (struct domain *d, uint32_t s, uint32_t e, uint8_t allow)
+{
+    return 0;
+}
+
+#endif
diff --git a/xen/include/xsm/xsm.h b/xen/include/xsm/xsm.h
index cbbe673..ba5a89e 100644
--- a/xen/include/xsm/xsm.h
+++ b/xen/include/xsm/xsm.h
@@ -21,12 +21,6 @@
 typedef void xsm_op_t;
 DEFINE_XEN_GUEST_HANDLE(xsm_op_t);
 
-#ifdef XSM_ENABLE
-    #define xsm_call(fn) xsm_ops->fn
-#else
-    #define xsm_call(fn) 0
-#endif
-
 /* policy magic number (defined by XSM_MAGIC) */
 typedef u32 xsm_magic_t;
 #ifndef XSM_MAGIC
@@ -187,645 +181,643 @@ struct xsm_operations {
 #endif
 };
 
-#endif
-
 extern struct xsm_operations *xsm_ops;
 
 static inline void xsm_security_domaininfo (struct domain *d,
                                         struct xen_domctl_getdomaininfo *info)
 {
-    (void)xsm_call(security_domaininfo(d, info));
+    xsm_ops->security_domaininfo(d, info);
 }
 
 static inline int xsm_setvcpucontext(struct domain *d)
 {
-    return xsm_call(setvcpucontext(d));
+    return xsm_ops->setvcpucontext(d);
 }
 
 static inline int xsm_pausedomain (struct domain *d)
 {
-    return xsm_call(pausedomain(d));
+    return xsm_ops->pausedomain(d);
 }
 
 static inline int xsm_unpausedomain (struct domain *d)
 {
-    return xsm_call(unpausedomain(d));
+    return xsm_ops->unpausedomain(d);
 }
 
 static inline int xsm_resumedomain (struct domain *d)
 {
-    return xsm_call(resumedomain(d));
+    return xsm_ops->resumedomain(d);
 }
 
 static inline int xsm_domain_create (struct domain *d, u32 ssidref)
 {
-    return xsm_call(domain_create(d, ssidref));
+    return xsm_ops->domain_create(d, ssidref);
 }
 
 static inline int xsm_max_vcpus(struct domain *d)
 {
-    return xsm_call(max_vcpus(d));
+    return xsm_ops->max_vcpus(d);
 }
 
 static inline int xsm_destroydomain (struct domain *d)
 {
-    return xsm_call(destroydomain(d));
+    return xsm_ops->destroydomain(d);
 }
 
 static inline int xsm_vcpuaffinity (int cmd, struct domain *d)
 {
-    return xsm_call(vcpuaffinity(cmd, d));
+    return xsm_ops->vcpuaffinity(cmd, d);
 }
 
 static inline int xsm_scheduler (struct domain *d)
 {
-    return xsm_call(scheduler(d));
+    return xsm_ops->scheduler(d);
 }
 
 static inline int xsm_getdomaininfo (struct domain *d)
 {
-    return xsm_call(getdomaininfo(d));
+    return xsm_ops->getdomaininfo(d);
 }
 
 static inline int xsm_getvcpucontext (struct domain *d)
 {
-    return xsm_call(getvcpucontext(d));
+    return xsm_ops->getvcpucontext(d);
 }
 
 static inline int xsm_getvcpuinfo (struct domain *d)
 {
-    return xsm_call(getvcpuinfo(d));
+    return xsm_ops->getvcpuinfo(d);
 }
 
 static inline int xsm_domain_settime (struct domain *d)
 {
-    return xsm_call(domain_settime(d));
+    return xsm_ops->domain_settime(d);
 }
 
 static inline int xsm_set_target (struct domain *d, struct domain *e)
 {
-    return xsm_call(set_target(d, e));
+    return xsm_ops->set_target(d, e);
 }
 
 static inline int xsm_domctl (struct domain *d, int cmd)
 {
-    return xsm_call(domctl(d, cmd));
+    return xsm_ops->domctl(d, cmd);
 }
 
 static inline int xsm_set_virq_handler (struct domain *d, uint32_t virq)
 {
-    return xsm_call(set_virq_handler(d, virq));
+    return xsm_ops->set_virq_handler(d, virq);
 }
 
 static inline int xsm_tbufcontrol (void)
 {
-    return xsm_call(tbufcontrol());
+    return xsm_ops->tbufcontrol();
 }
 
 static inline int xsm_readconsole (uint32_t clear)
 {
-    return xsm_call(readconsole(clear));
+    return xsm_ops->readconsole(clear);
 }
 
 static inline int xsm_sched_id (void)
 {
-    return xsm_call(sched_id());
+    return xsm_ops->sched_id();
 }
 
 static inline int xsm_setdomainmaxmem (struct domain *d)
 {
-    return xsm_call(setdomainmaxmem(d));
+    return xsm_ops->setdomainmaxmem(d);
 }
 
 static inline int xsm_setdomainhandle (struct domain *d)
 {
-    return xsm_call(setdomainhandle(d));
+    return xsm_ops->setdomainhandle(d);
 }
 
 static inline int xsm_setdebugging (struct domain *d)
 {
-    return xsm_call(setdebugging(d));
+    return xsm_ops->setdebugging(d);
 }
 
 static inline int xsm_perfcontrol (void)
 {
-    return xsm_call(perfcontrol());
+    return xsm_ops->perfcontrol();
 }
 
 static inline int xsm_debug_keys (void)
 {
-    return xsm_call(debug_keys());
+    return xsm_ops->debug_keys();
 }
 
 static inline int xsm_availheap (void)
 {
-    return xsm_call(availheap());
+    return xsm_ops->availheap();
 }
 
 static inline int xsm_getcpuinfo (void)
 {
-    return xsm_call(getcpuinfo());
+    return xsm_ops->getcpuinfo();
 }
 
 static inline int xsm_get_pmstat(void)
 {
-    return xsm_call(get_pmstat());
+    return xsm_ops->get_pmstat();
 }
 
 static inline int xsm_setpminfo(void)
 {
-	return xsm_call(setpminfo());
+    return xsm_ops->setpminfo();
 }
 
 static inline int xsm_pm_op(void)
 {
-    return xsm_call(pm_op());
+    return xsm_ops->pm_op();
 }
 
 static inline int xsm_do_mca(void)
 {
-    return xsm_call(do_mca());
+    return xsm_ops->do_mca();
 }
 
 static inline int xsm_evtchn_unbound (struct domain *d1, struct evtchn *chn,
                                                                     domid_t id2)
 {
-    return xsm_call(evtchn_unbound(d1, chn, id2));
+    return xsm_ops->evtchn_unbound(d1, chn, id2);
 }
 
 static inline int xsm_evtchn_interdomain (struct domain *d1, 
                 struct evtchn *chan1, struct domain *d2, struct evtchn *chan2)
 {
-    return xsm_call(evtchn_interdomain(d1, chan1, d2, chan2));
+    return xsm_ops->evtchn_interdomain(d1, chan1, d2, chan2);
 }
 
 static inline void xsm_evtchn_close_post (struct evtchn *chn)
 {
-    (void)xsm_call(evtchn_close_post(chn));
+    xsm_ops->evtchn_close_post(chn);
 }
 
 static inline int xsm_evtchn_send (struct domain *d, struct evtchn *chn)
 {
-    return xsm_call(evtchn_send(d, chn));
+    return xsm_ops->evtchn_send(d, chn);
 }
 
 static inline int xsm_evtchn_status (struct domain *d, struct evtchn *chn)
 {
-    return xsm_call(evtchn_status(d, chn));
+    return xsm_ops->evtchn_status(d, chn);
 }
 
 static inline int xsm_evtchn_reset (struct domain *d1, struct domain *d2)
 {
-    return xsm_call(evtchn_reset(d1, d2));
+    return xsm_ops->evtchn_reset(d1, d2);
 }
 
 static inline int xsm_grant_mapref (struct domain *d1, struct domain *d2,
                                                                 uint32_t flags)
 {
-    return xsm_call(grant_mapref(d1, d2, flags));
+    return xsm_ops->grant_mapref(d1, d2, flags);
 }
 
 static inline int xsm_grant_unmapref (struct domain *d1, struct domain *d2)
 {
-    return xsm_call(grant_unmapref(d1, d2));
+    return xsm_ops->grant_unmapref(d1, d2);
 }
 
 static inline int xsm_grant_setup (struct domain *d1, struct domain *d2)
 {
-    return xsm_call(grant_setup(d1, d2));
+    return xsm_ops->grant_setup(d1, d2);
 }
 
 static inline int xsm_grant_transfer (struct domain *d1, struct domain *d2)
 {
-    return xsm_call(grant_transfer(d1, d2));
+    return xsm_ops->grant_transfer(d1, d2);
 }
 
 static inline int xsm_grant_copy (struct domain *d1, struct domain *d2)
 {
-    return xsm_call(grant_copy(d1, d2));
+    return xsm_ops->grant_copy(d1, d2);
 }
 
 static inline int xsm_grant_query_size (struct domain *d1, struct domain *d2)
 {
-    return xsm_call(grant_query_size(d1, d2));
+    return xsm_ops->grant_query_size(d1, d2);
 }
 
 static inline int xsm_alloc_security_domain (struct domain *d)
 {
-    return xsm_call(alloc_security_domain(d));
+    return xsm_ops->alloc_security_domain(d);
 }
 
 static inline void xsm_free_security_domain (struct domain *d)
 {
-    (void)xsm_call(free_security_domain(d));
+    xsm_ops->free_security_domain(d);
 }
 
 static inline int xsm_alloc_security_evtchn (struct evtchn *chn)
 {
-    return xsm_call(alloc_security_evtchn(chn));
+    return xsm_ops->alloc_security_evtchn(chn);
 }
 
 static inline void xsm_free_security_evtchn (struct evtchn *chn)
 {
-    (void)xsm_call(free_security_evtchn(chn));
+    (void)xsm_ops->free_security_evtchn(chn);
 }
 
 static inline char *xsm_show_security_evtchn (struct domain *d, const struct evtchn *chn)
 {
-    return xsm_call(show_security_evtchn(d, chn));
+    return xsm_ops->show_security_evtchn(d, chn);
 }
 
 static inline int xsm_get_pod_target (struct domain *d)
 {
-    return xsm_call(get_pod_target(d));
+    return xsm_ops->get_pod_target(d);
 }
 
 static inline int xsm_set_pod_target (struct domain *d)
 {
-    return xsm_call(set_pod_target(d));
+    return xsm_ops->set_pod_target(d);
 }
 
 static inline int xsm_memory_adjust_reservation (struct domain *d1, struct
                                                                     domain *d2)
 {
-    return xsm_call(memory_adjust_reservation(d1, d2));
+    return xsm_ops->memory_adjust_reservation(d1, d2);
 }
 
 static inline int xsm_memory_stat_reservation (struct domain *d1,
                                                             struct domain *d2)
 {
-    return xsm_call(memory_stat_reservation(d1, d2));
+    return xsm_ops->memory_stat_reservation(d1, d2);
 }
 
 static inline int xsm_memory_pin_page(struct domain *d1, struct domain *d2,
                                       struct page_info *page)
 {
-    return xsm_call(memory_pin_page(d1, d2, page));
+    return xsm_ops->memory_pin_page(d1, d2, page);
 }
 
 static inline int xsm_remove_from_physmap(struct domain *d1, struct domain *d2)
 {
-    return xsm_call(remove_from_physmap(d1, d2));
+    return xsm_ops->remove_from_physmap(d1, d2);
 }
 
 static inline int xsm_console_io (struct domain *d, int cmd)
 {
-    return xsm_call(console_io(d, cmd));
+    return xsm_ops->console_io(d, cmd);
 }
 
 static inline int xsm_profile (struct domain *d, int op)
 {
-    return xsm_call(profile(d, op));
+    return xsm_ops->profile(d, op);
 }
 
 static inline int xsm_kexec (void)
 {
-    return xsm_call(kexec());
+    return xsm_ops->kexec();
 }
 
 static inline int xsm_schedop_shutdown (struct domain *d1, struct domain *d2)
 {
-    return xsm_call(schedop_shutdown(d1, d2));
+    return xsm_ops->schedop_shutdown(d1, d2);
 }
 
 static inline char *xsm_show_irq_sid (int irq)
 {
-    return xsm_call(show_irq_sid(irq));
+    return xsm_ops->show_irq_sid(irq);
 }
 
 static inline int xsm_map_domain_pirq (struct domain *d, int irq, void *data)
 {
-    return xsm_call(map_domain_pirq(d, irq, data));
+    return xsm_ops->map_domain_pirq(d, irq, data);
 }
 
 static inline int xsm_unmap_domain_pirq (struct domain *d, int irq)
 {
-    return xsm_call(unmap_domain_pirq(d, irq));
+    return xsm_ops->unmap_domain_pirq(d, irq);
 }
 
 static inline int xsm_irq_permission (struct domain *d, int pirq, uint8_t allow)
 {
-    return xsm_call(irq_permission(d, pirq, allow));
+    return xsm_ops->irq_permission(d, pirq, allow);
 }
 
 static inline int xsm_iomem_permission (struct domain *d, uint64_t s, uint64_t e, uint8_t allow)
 {
-    return xsm_call(iomem_permission(d, s, e, allow));
+    return xsm_ops->iomem_permission(d, s, e, allow);
 }
 
 static inline int xsm_iomem_mapping (struct domain *d, uint64_t s, uint64_t e, uint8_t allow)
 {
-    return xsm_call(iomem_mapping(d, s, e, allow));
+    return xsm_ops->iomem_mapping(d, s, e, allow);
 }
 
 static inline int xsm_pci_config_permission (struct domain *d, uint32_t machine_bdf, uint16_t start, uint16_t end, uint8_t access)
 {
-    return xsm_call(pci_config_permission(d, machine_bdf, start, end, access));
+    return xsm_ops->pci_config_permission(d, machine_bdf, start, end, access);
 }
 
 static inline int xsm_get_device_group(uint32_t machine_bdf)
 {
-    return xsm_call(get_device_group(machine_bdf));
+    return xsm_ops->get_device_group(machine_bdf);
 }
 
 static inline int xsm_test_assign_device(uint32_t machine_bdf)
 {
-    return xsm_call(test_assign_device(machine_bdf));
+    return xsm_ops->test_assign_device(machine_bdf);
 }
 
 static inline int xsm_assign_device(struct domain *d, uint32_t machine_bdf)
 {
-    return xsm_call(assign_device(d, machine_bdf));
+    return xsm_ops->assign_device(d, machine_bdf);
 }
 
 static inline int xsm_deassign_device(struct domain *d, uint32_t machine_bdf)
 {
-    return xsm_call(deassign_device(d, machine_bdf));
+    return xsm_ops->deassign_device(d, machine_bdf);
 }
 
 static inline int xsm_resource_plug_pci (uint32_t machine_bdf)
 {
-    return xsm_call(resource_plug_pci(machine_bdf));
+    return xsm_ops->resource_plug_pci(machine_bdf);
 }
 
 static inline int xsm_resource_unplug_pci (uint32_t machine_bdf)
 {
-    return xsm_call(resource_unplug_pci(machine_bdf));
+    return xsm_ops->resource_unplug_pci(machine_bdf);
 }
 
 static inline int xsm_resource_plug_core (void)
 {
-    return xsm_call(resource_plug_core());
+    return xsm_ops->resource_plug_core();
 }
 
 static inline int xsm_resource_unplug_core (void)
 {
-    return xsm_call(resource_unplug_core());
+    return xsm_ops->resource_unplug_core();
 }
 
 static inline int xsm_resource_setup_pci (uint32_t machine_bdf)
 {
-    return xsm_call(resource_setup_pci(machine_bdf));
+    return xsm_ops->resource_setup_pci(machine_bdf);
 }
 
 static inline int xsm_resource_setup_gsi (int gsi)
 {
-    return xsm_call(resource_setup_gsi(gsi));
+    return xsm_ops->resource_setup_gsi(gsi);
 }
 
 static inline int xsm_resource_setup_misc (void)
 {
-    return xsm_call(resource_setup_misc());
+    return xsm_ops->resource_setup_misc();
 }
 
 static inline int xsm_page_offline(uint32_t cmd)
 {
-    return xsm_call(page_offline(cmd));
+    return xsm_ops->page_offline(cmd);
 }
 
 static inline int xsm_lockprof(void)
 {
-    return xsm_call(lockprof());
+    return xsm_ops->lockprof();
 }
 
 static inline int xsm_cpupool_op(void)
 {
-    return xsm_call(cpupool_op());
+    return xsm_ops->cpupool_op();
 }
 
 static inline int xsm_sched_op(void)
 {
-    return xsm_call(sched_op());
+    return xsm_ops->sched_op();
 }
 
-static inline long __do_xsm_op (XEN_GUEST_HANDLE(xsm_op_t) op)
+static inline long xsm___do_xsm_op (XEN_GUEST_HANDLE(xsm_op_t) op)
 {
-#ifdef XSM_ENABLE
     return xsm_ops->__do_xsm_op(op);
-#else
-    return -ENOSYS;
-#endif
-}
-
-#ifdef XSM_ENABLE
-extern int xsm_init(unsigned long *module_map, const multiboot_info_t *mbi,
-                    void *(*bootstrap_map)(const module_t *));
-extern int xsm_policy_init(unsigned long *module_map,
-                           const multiboot_info_t *mbi,
-                           void *(*bootstrap_map)(const module_t *));
-extern int register_xsm(struct xsm_operations *ops);
-extern int unregister_xsm(struct xsm_operations *ops);
-#else
-static inline int xsm_init (unsigned long *module_map,
-                            const multiboot_info_t *mbi,
-                            void *(*bootstrap_map)(const module_t *))
-{
-    return 0;
 }
-#endif
 
 #ifdef CONFIG_X86
 static inline int xsm_shadow_control (struct domain *d, uint32_t op)
 {
-    return xsm_call(shadow_control(d, op));
+    return xsm_ops->shadow_control(d, op);
 }
 
 static inline int xsm_getpageframeinfo (struct domain *d)
 {
-    return xsm_call(getpageframeinfo(d));
+    return xsm_ops->getpageframeinfo(d);
 }
 
 static inline int xsm_getmemlist (struct domain *d)
 {
-    return xsm_call(getmemlist(d));
+    return xsm_ops->getmemlist(d);
 }
 
 static inline int xsm_hypercall_init (struct domain *d)
 {
-    return xsm_call(hypercall_init(d));
+    return xsm_ops->hypercall_init(d);
 }
 
 static inline int xsm_hvmcontext (struct domain *d, uint32_t cmd)
 {
-    return xsm_call(hvmcontext(d, cmd));
+    return xsm_ops->hvmcontext(d, cmd);
 }
 
 static inline int xsm_address_size (struct domain *d, uint32_t cmd)
 {
-    return xsm_call(address_size(d, cmd));
+    return xsm_ops->address_size(d, cmd);
 }
 
 static inline int xsm_machine_address_size (struct domain *d, uint32_t cmd)
 {
-    return xsm_call(machine_address_size(d, cmd));
+    return xsm_ops->machine_address_size(d, cmd);
 }
 
 static inline int xsm_hvm_param (struct domain *d, unsigned long op)
 {
-    return xsm_call(hvm_param(d, op));
+    return xsm_ops->hvm_param(d, op);
 }
 
 static inline int xsm_hvm_set_pci_intx_level (struct domain *d)
 {
-    return xsm_call(hvm_set_pci_intx_level(d));
+    return xsm_ops->hvm_set_pci_intx_level(d);
 }
 
 static inline int xsm_hvm_set_isa_irq_level (struct domain *d)
 {
-    return xsm_call(hvm_set_isa_irq_level(d));
+    return xsm_ops->hvm_set_isa_irq_level(d);
 }
 
 static inline int xsm_hvm_set_pci_link_route (struct domain *d)
 {
-    return xsm_call(hvm_set_pci_link_route(d));
+    return xsm_ops->hvm_set_pci_link_route(d);
 }
 
 static inline int xsm_hvm_inject_msi (struct domain *d)
 {
-    return xsm_call(hvm_inject_msi(d));
+    return xsm_ops->hvm_inject_msi(d);
 }
 
 static inline int xsm_mem_event (struct domain *d)
 {
-    return xsm_call(mem_event(d));
+    return xsm_ops->mem_event(d);
 }
 
 static inline int xsm_mem_sharing (struct domain *d)
 {
-    return xsm_call(mem_sharing(d));
+    return xsm_ops->mem_sharing(d);
 }
 
 static inline int xsm_apic (struct domain *d, int cmd)
 {
-    return xsm_call(apic(d, cmd));
+    return xsm_ops->apic(d, cmd);
 }
 
 static inline int xsm_xen_settime (void)
 {
-    return xsm_call(xen_settime());
+    return xsm_ops->xen_settime();
 }
 
 static inline int xsm_memtype (uint32_t access)
 {
-    return xsm_call(memtype(access));
+    return xsm_ops->memtype(access);
 }
 
 static inline int xsm_microcode (void)
 {
-    return xsm_call(microcode());
+    return xsm_ops->microcode();
 }
 
 static inline int xsm_physinfo (void)
 {
-    return xsm_call(physinfo());
+    return xsm_ops->physinfo();
 }
 
 static inline int xsm_platform_quirk (uint32_t quirk)
 {
-    return xsm_call(platform_quirk(quirk));
+    return xsm_ops->platform_quirk(quirk);
 }
 
 static inline int xsm_firmware_info (void)
 {
-    return xsm_call(firmware_info());
+    return xsm_ops->firmware_info();
 }
 
 static inline int xsm_efi_call (void)
 {
-    return xsm_call(efi_call());
+    return xsm_ops->efi_call();
 }
 
 static inline int xsm_acpi_sleep (void)
 {
-    return xsm_call(acpi_sleep());
+    return xsm_ops->acpi_sleep();
 }
 
 static inline int xsm_change_freq (void)
 {
-    return xsm_call(change_freq());
+    return xsm_ops->change_freq();
 }
 
 static inline int xsm_getidletime (void)
 {
-    return xsm_call(getidletime());
+    return xsm_ops->getidletime();
 }
 
 static inline int xsm_machine_memory_map(void)
 {
-    return xsm_call(machine_memory_map());
+    return xsm_ops->machine_memory_map();
 }
 
 static inline int xsm_domain_memory_map(struct domain *d)
 {
-    return xsm_call(domain_memory_map(d));
+    return xsm_ops->domain_memory_map(d);
 }
 
 static inline int xsm_mmu_normal_update (struct domain *d, struct domain *t,
                                          struct domain *f, intpte_t fpte)
 {
-    return xsm_call(mmu_normal_update(d, t, f, fpte));
+    return xsm_ops->mmu_normal_update(d, t, f, fpte);
 }
 
 static inline int xsm_mmu_machphys_update (struct domain *d1, struct domain *d2,
                                            unsigned long mfn)
 {
-    return xsm_call(mmu_machphys_update(d1, d2, mfn));
+    return xsm_ops->mmu_machphys_update(d1, d2, mfn);
 }
 
 static inline int xsm_update_va_mapping(struct domain *d, struct domain *f, 
                                                             l1_pgentry_t pte)
 {
-    return xsm_call(update_va_mapping(d, f, pte));
+    return xsm_ops->update_va_mapping(d, f, pte);
 }
 
 static inline int xsm_add_to_physmap(struct domain *d1, struct domain *d2)
 {
-    return xsm_call(add_to_physmap(d1, d2));
+    return xsm_ops->add_to_physmap(d1, d2);
 }
 
 static inline int xsm_sendtrigger(struct domain *d)
 {
-    return xsm_call(sendtrigger(d));
+    return xsm_ops->sendtrigger(d);
 }
 
 static inline int xsm_bind_pt_irq(struct domain *d, 
                                                 struct xen_domctl_bind_pt_irq *bind)
 {
-    return xsm_call(bind_pt_irq(d, bind));
+    return xsm_ops->bind_pt_irq(d, bind);
 }
 
 static inline int xsm_unbind_pt_irq(struct domain *d,
                                                 struct xen_domctl_bind_pt_irq *bind)
 {
-    return xsm_call(unbind_pt_irq(d, bind));
+    return xsm_ops->unbind_pt_irq(d, bind);
 }
 
 static inline int xsm_pin_mem_cacheattr(struct domain *d)
 {
-    return xsm_call(pin_mem_cacheattr(d));
+    return xsm_ops->pin_mem_cacheattr(d);
 }
 
 static inline int xsm_ext_vcpucontext(struct domain *d, uint32_t cmd)
 {
-    return xsm_call(ext_vcpucontext(d, cmd));
+    return xsm_ops->ext_vcpucontext(d, cmd);
 }
 static inline int xsm_vcpuextstate(struct domain *d, uint32_t cmd)
 {
-    return xsm_call(vcpuextstate(d, cmd));
+    return xsm_ops->vcpuextstate(d, cmd);
 }
 
 static inline int xsm_ioport_permission (struct domain *d, uint32_t s, uint32_t e, uint8_t allow)
 {
-    return xsm_call(ioport_permission(d, s, e, allow));
+    return xsm_ops->ioport_permission(d, s, e, allow);
 }
 
 static inline int xsm_ioport_mapping (struct domain *d, uint32_t s, uint32_t e, uint8_t allow)
 {
-    return xsm_call(ioport_mapping(d, s, e, allow));
+    return xsm_ops->ioport_mapping(d, s, e, allow);
 }
 #endif /* CONFIG_X86 */
 
+extern int xsm_init(unsigned long *module_map, const multiboot_info_t *mbi,
+                    void *(*bootstrap_map)(const module_t *));
+extern int xsm_policy_init(unsigned long *module_map,
+                           const multiboot_info_t *mbi,
+                           void *(*bootstrap_map)(const module_t *));
+extern int register_xsm(struct xsm_operations *ops);
+extern int unregister_xsm(struct xsm_operations *ops);
+
 extern struct xsm_operations dummy_xsm_ops;
 extern void xsm_fixup_ops(struct xsm_operations *ops);
 
+#else /* XSM_ENABLE */
+
+#define XSM_DEFAULT(type, name) inline type xsm_ ## name
+#include <xsm/dummy.h>
+
+static inline int xsm_init (unsigned long *module_map,
+                            const multiboot_info_t *mbi,
+                            void *(*bootstrap_map)(const module_t *))
+{
+    return 0;
+}
+#endif /* XSM_ENABLE */
+
 #endif /* __XSM_H */
diff --git a/xen/xsm/dummy.c b/xen/xsm/dummy.c
index a5dbfe7..af532b8 100644
--- a/xen/xsm/dummy.c
+++ b/xen/xsm/dummy.c
@@ -10,621 +10,8 @@
  *  as published by the Free Software Foundation.
  */
 
-#include <xen/sched.h>
-#include <xsm/xsm.h>
-
-static void dummy_security_domaininfo(struct domain *d,
-                                    struct xen_domctl_getdomaininfo *info)
-{
-    return;
-}
-
-static int dummy_setvcpucontext(struct domain *d)
-{
-    return 0;
-}
-
-static int dummy_pausedomain (struct domain *d)
-{
-    return 0;
-}
-
-static int dummy_unpausedomain (struct domain *d)
-{
-    return 0;
-}
-
-static int dummy_resumedomain (struct domain *d)
-{
-    return 0;
-}
-
-static int dummy_domain_create(struct domain *d, u32 ssidref)
-{
-    return 0;
-}
-
-static int dummy_max_vcpus(struct domain *d)
-{
-    return 0;
-}
-
-static int dummy_destroydomain (struct domain *d)
-{
-    return 0;
-}
-
-static int dummy_vcpuaffinity (int cmd, struct domain *d)
-{
-    return 0;
-}
-
-static int dummy_scheduler (struct domain *d)
-{
-    return 0;
-}
-
-static int dummy_getdomaininfo (struct domain *d)
-{
-    if ( !IS_PRIV(current->domain) )
-        return -EPERM;
-    return 0;
-}
-
-static int dummy_getvcpucontext (struct domain *d)
-{
-    return 0;
-}
-
-static int dummy_getvcpuinfo (struct domain *d)
-{
-    return 0;
-}
-
-static int dummy_domain_settime (struct domain *d)
-{
-    return 0;
-}
-
-static int dummy_set_target (struct domain *d, struct domain *e)
-{
-    return 0;
-}
-
-static int dummy_domctl(struct domain *d, int cmd)
-{
-    return 0;
-}
-
-static int dummy_set_virq_handler(struct domain *d, uint32_t virq)
-{
-    return 0;
-}
-
-static int dummy_tbufcontrol (void)
-{
-    return 0;
-}
-
-static int dummy_readconsole (uint32_t clear)
-{
-    return 0;
-}
-
-static int dummy_sched_id (void)
-{
-    return 0;
-}
-
-static int dummy_setdomainmaxmem (struct domain *d)
-{
-    return 0;
-}
-
-static int dummy_setdomainhandle (struct domain *d)
-{
-    return 0;
-}
-
-static int dummy_setdebugging (struct domain *d)
-{
-    return 0;
-}
-
-static int dummy_perfcontrol (void)
-{
-    return 0;
-}
-
-static int dummy_debug_keys (void)
-{
-    return 0;
-}
-
-static int dummy_getcpuinfo (void)
-{
-    return 0;
-}
-
-static int dummy_get_pmstat (void)
-{
-    return 0;
-}
-
-static int dummy_setpminfo (void)
-{
-    return 0;
-}
-
-static int dummy_pm_op (void)
-{
-    return 0;
-}
-
-static int dummy_do_mca (void)
-{
-    return 0;
-}
-
-static int dummy_availheap (void)
-{
-    return 0;
-}
-
-static int dummy_alloc_security_domain (struct domain *d)
-{
-    return 0;
-}
-
-static void dummy_free_security_domain (struct domain *d)
-{
-    return;
-}
-
-static int dummy_grant_mapref (struct domain *d1, struct domain *d2,
-                                                                uint32_t flags)
-{
-    return 0;
-}
-
-static int dummy_grant_unmapref (struct domain *d1, struct domain *d2)
-{
-    return 0;
-}
-
-static int dummy_grant_setup (struct domain *d1, struct domain *d2)
-{
-    return 0;
-}
-
-static int dummy_grant_transfer (struct domain *d1, struct domain *d2)
-{
-    return 0;
-}
-
-static int dummy_grant_copy (struct domain *d1, struct domain *d2)
-{
-    return 0;
-}
-
-static int dummy_grant_query_size (struct domain *d1, struct domain *d2)
-{
-    return 0;
-}
-
-static int dummy_memory_adjust_reservation (struct domain *d1,
-                                                            struct domain *d2)
-{
-    return 0;
-}
-
-static int dummy_memory_stat_reservation (struct domain *d1, struct domain *d2)
-{
-    return 0;
-}
-
-static int dummy_console_io (struct domain *d, int cmd)
-{
-    return 0;
-}
-
-static int dummy_profile (struct domain *d, int op)
-{
-    return 0;
-}
-
-static int dummy_kexec (void)
-{
-    return 0;
-}
-
-static int dummy_schedop_shutdown (struct domain *d1, struct domain *d2)
-{
-    return 0;
-}
-
-static int dummy_memory_pin_page(struct domain *d1, struct domain *d2, struct page_info *page)
-{
-    return 0;
-}
-
-static int dummy_evtchn_unbound (struct domain *d, struct evtchn *chn,
-                                                                    domid_t id2)
-{
-    return 0;
-}
-
-static int dummy_evtchn_interdomain (struct domain *d1, struct evtchn
-                                *chan1, struct domain *d2, struct evtchn *chan2)
-{
-    return 0;
-}
-
-static void dummy_evtchn_close_post (struct evtchn *chn)
-{
-    return;
-}
-
-static int dummy_evtchn_send (struct domain *d, struct evtchn *chn)
-{
-    return 0;
-}
-
-static int dummy_evtchn_status (struct domain *d, struct evtchn *chn)
-{
-    return 0;
-}
-
-static int dummy_evtchn_reset (struct domain *d1, struct domain *d2)
-{
-    return 0;
-}
-
-static int dummy_alloc_security_evtchn (struct evtchn *chn)
-{
-    return 0;
-}
-
-static void dummy_free_security_evtchn (struct evtchn *chn)
-{
-    return;
-}
-
-static char *dummy_show_security_evtchn (struct domain *d, const struct evtchn *chn)
-{
-    return NULL;
-}
-
-static int dummy_get_pod_target(struct domain *d)
-{
-    return 0;
-}
-
-static int dummy_set_pod_target(struct domain *d)
-{
-    return 0;
-}
-
-static int dummy_get_device_group (uint32_t machine_bdf)
-{
-    return 0;
-}
-
-static int dummy_test_assign_device (uint32_t machine_bdf)
-{
-    return 0;
-}
-
-static int dummy_assign_device (struct domain *d, uint32_t machine_bdf)
-{
-    return 0;
-}
-
-static int dummy_deassign_device (struct domain *d, uint32_t machine_bdf)
-{
-    return 0;
-}
-
-static int dummy_resource_plug_core (void)
-{
-    return 0;
-}
-
-static int dummy_resource_unplug_core (void)
-{
-    return 0;
-}
-
-static int dummy_resource_plug_pci (uint32_t machine_bdf)
-{
-    return 0;
-}
-
-static int dummy_resource_unplug_pci (uint32_t machine_bdf)
-{
-    return 0;
-}
-
-static int dummy_resource_setup_pci (uint32_t machine_bdf)
-{
-    return 0;
-}
-
-static int dummy_resource_setup_gsi (int gsi)
-{
-    return 0;
-}
-
-static int dummy_resource_setup_misc (void)
-{
-    return 0;
-}
-
-static int dummy_page_offline (uint32_t cmd)
-{
-    return 0;
-}
-
-static int dummy_lockprof (void)
-{
-    return 0;
-}
-
-static int dummy_cpupool_op (void)
-{
-    return 0;
-}
-
-static int dummy_sched_op (void)
-{
-    return 0;
-}
-
-static long dummy___do_xsm_op(XEN_GUEST_HANDLE(xsm_op_t) op)
-{
-    return -ENOSYS;
-}
-
-static char *dummy_show_irq_sid (int irq)
-{
-    return NULL;
-}
-
-static int dummy_map_domain_pirq (struct domain *d, int irq, void *data)
-{
-    return 0;
-}
-
-static int dummy_unmap_domain_pirq (struct domain *d, int irq)
-{
-    return 0;
-}
-
-static int dummy_irq_permission (struct domain *d, int pirq, uint8_t allow)
-{
-    return 0;
-}
-
-static int dummy_iomem_permission (struct domain *d, uint64_t s, uint64_t e, uint8_t allow)
-{
-    return 0;
-}
-
-static int dummy_iomem_mapping (struct domain *d, uint64_t s, uint64_t e, uint8_t allow)
-{
-    return 0;
-}
-
-static int dummy_pci_config_permission (struct domain *d, uint32_t machine_bdf,
-                                        uint16_t start, uint16_t end,
-                                        uint8_t access)
-{
-    return 0;
-}
-
-#ifdef CONFIG_X86
-static int dummy_shadow_control (struct domain *d, uint32_t op)
-{
-    return 0;
-}
-
-static int dummy_getpageframeinfo (struct domain *d)
-{
-    return 0;
-}
-
-static int dummy_getmemlist (struct domain *d)
-{
-    return 0;
-}
-
-static int dummy_hypercall_init (struct domain *d)
-{
-    return 0;
-}
-
-static int dummy_hvmcontext (struct domain *d, uint32_t cmd)
-{
-    return 0;
-}
-
-static int dummy_address_size (struct domain *d, uint32_t cmd)
-{
-    return 0;
-}
-
-static int dummy_machine_address_size (struct domain *d, uint32_t cmd)
-{
-    return 0;
-}
-
-static int dummy_hvm_param (struct domain *d, unsigned long op)
-{
-    return 0;
-}
-
-static int dummy_hvm_set_pci_intx_level (struct domain *d)
-{
-    return 0;
-}
-
-static int dummy_hvm_set_isa_irq_level (struct domain *d)
-{
-    return 0;
-}
-
-static int dummy_hvm_set_pci_link_route (struct domain *d)
-{
-    return 0;
-}
-
-static int dummy_hvm_inject_msi (struct domain *d)
-{
-    return 0;
-}
-
-static int dummy_mem_event (struct domain *d)
-{
-    return 0;
-}
-
-static int dummy_mem_sharing (struct domain *d)
-{
-    return 0;
-}
-
-static int dummy_apic (struct domain *d, int cmd)
-{
-    return 0;
-}
-
-static int dummy_xen_settime (void)
-{
-    return 0;
-}
-
-static int dummy_memtype (uint32_t access)
-{
-    return 0;
-}
-
-static int dummy_microcode (void)
-{
-    return 0;
-}
-
-static int dummy_physinfo (void)
-{
-    return 0;
-}
-
-static int dummy_platform_quirk (uint32_t quirk)
-{
-    return 0;
-}
-
-static int dummy_firmware_info (void)
-{
-    return 0;
-}
-
-static int dummy_efi_call(void)
-{
-    return 0;
-}
-
-static int dummy_acpi_sleep (void)
-{
-    return 0;
-}
-
-static int dummy_change_freq (void)
-{
-    return 0;
-}
-
-static int dummy_getidletime (void)
-{
-    return 0;
-}
-
-static int dummy_machine_memory_map (void)
-{
-    return 0;
-}
-
-static int dummy_domain_memory_map (struct domain *d)
-{
-    return 0;
-}
-
-static int dummy_mmu_normal_update (struct domain *d, struct domain *t,
-                                    struct domain *f, intpte_t fpte)
-{
-    return 0;
-}
-
-static int dummy_mmu_machphys_update (struct domain *d, struct domain *f, unsigned long mfn)
-{
-    return 0;
-}
-
-static int dummy_update_va_mapping (struct domain *d, struct domain *f, 
-                                                            l1_pgentry_t pte)
-{
-    return 0;
-}
-
-static int dummy_add_to_physmap (struct domain *d1, struct domain *d2)
-{
-    return 0;
-}
-
-static int dummy_remove_from_physmap (struct domain *d1, struct domain *d2)
-{
-    return 0;
-}
-
-static int dummy_sendtrigger (struct domain *d)
-{
-    return 0;
-}
-
-static int dummy_bind_pt_irq (struct domain *d, struct xen_domctl_bind_pt_irq *bind)
-{
-    return 0;
-}
-
-static int dummy_unbind_pt_irq (struct domain *d, struct xen_domctl_bind_pt_irq *bind)
-{
-    return 0;
-}
-
-static int dummy_pin_mem_cacheattr (struct domain *d)
-{
-    return 0;
-}
-
-static int dummy_ext_vcpucontext (struct domain *d, uint32_t cmd)
-{
-    return 0;
-}
-
-static int dummy_vcpuextstate (struct domain *d, uint32_t cmd)
-{
-    return 0;
-}
-
-static int dummy_ioport_permission (struct domain *d, uint32_t s, uint32_t e, uint8_t allow)
-{
-    return 0;
-}
-
-static int dummy_ioport_mapping (struct domain *d, uint32_t s, uint32_t e, uint8_t allow)
-{
-    return 0;
-}
-#endif
+#define XSM_DEFAULT(type, name) type dummy_ ## name
+#include <xsm/dummy.h>
 
 struct xsm_operations dummy_xsm_ops;
 
diff --git a/xen/xsm/xsm_core.c b/xen/xsm/xsm_core.c
index 96c8669..c4c85c0 100644
--- a/xen/xsm/xsm_core.c
+++ b/xen/xsm/xsm_core.c
@@ -113,7 +113,7 @@ int unregister_xsm(struct xsm_operations *ops)
 
 long do_xsm_op (XEN_GUEST_HANDLE(xsm_op_t) op)
 {
-    return __do_xsm_op(op);
+    return xsm___do_xsm_op(op);
 }
 
 
-- 
1.7.11.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 12 16:00:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Sep 2012 16:00: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 1TBpM5-0005Nu-Hu; Wed, 12 Sep 2012 15:59:57 +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 1TBpM4-0005Mm-6Q
	for xen-devel@lists.xen.org; Wed, 12 Sep 2012 15:59:56 +0000
Received: from [85.158.138.51:26808] by server-7.bemta-3.messagelabs.com id
	BB/07-32000-B71B0505; Wed, 12 Sep 2012 15:59:55 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-4.tower-174.messagelabs.com!1347465594!29693437!1
X-Originating-IP: [63.239.67.9]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31507 invoked from network); 12 Sep 2012 15:59:54 -0000
Received: from emvm-gh1-uea08.nsa.gov (HELO nsa.gov) (63.239.67.9)
	by server-4.tower-174.messagelabs.com with SMTP;
	12 Sep 2012 15:59:54 -0000
X-TM-IMSS-Message-ID: <39e15e5800102347@nsa.gov>
Received: from tarius.tycho.ncsc.mil ([144.51.3.1]) by nsa.gov ([63.239.67.9])
	with ESMTP (TREND IMSS SMTP Service 7.1) id 39e15e5800102347 ;
	Wed, 12 Sep 2012 11:59:44 -0400
Received: from moss-nexus.epoch.ncsc.mil (moss-nexus [144.51.25.48])
	by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id q8CFxoOI006669; 
	Wed, 12 Sep 2012 11:59:52 -0400
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xen.org
Date: Wed, 12 Sep 2012 11:59:32 -0400
Message-Id: <1347465586-20009-9-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.11.4
In-Reply-To: <1347465586-20009-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1347465586-20009-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: dgdegra@tycho.nsa.gov
Subject: [Xen-devel] [PATCH 08/22] xsm/flask: Add checks on the domain
	performing the set_target 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>
MIME-Version: 1.0
Content-Type: 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 existing domain__set_target check only verifies that the source and
target domains can be associated. We also need to check that the
privileged domain making this association is allowed to do so.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 tools/flask/policy/policy/flask/access_vectors | 2 ++
 xen/xsm/flask/hooks.c                          | 7 +++++++
 xen/xsm/flask/include/av_perm_to_string.h      | 2 ++
 xen/xsm/flask/include/av_permissions.h         | 2 ++
 4 files changed, 13 insertions(+)

diff --git a/tools/flask/policy/policy/flask/access_vectors b/tools/flask/policy/policy/flask/access_vectors
index c7e29ab..11d02da 100644
--- a/tools/flask/policy/policy/flask/access_vectors
+++ b/tools/flask/policy/policy/flask/access_vectors
@@ -78,6 +78,8 @@ class domain2
 	relabelfrom
 	relabelto
 	relabelself
+	make_priv_for
+	set_as_target
 }
 
 class hvm
diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
index 74c9271..6d4b4f0 100644
--- a/xen/xsm/flask/hooks.c
+++ b/xen/xsm/flask/hooks.c
@@ -577,6 +577,13 @@ static int flask_domain_settime(struct domain *d)
 
 static int flask_set_target(struct domain *d, struct domain *e)
 {
+    int rc;
+    rc = domain_has_perm(current->domain, d, SECCLASS_DOMAIN2, DOMAIN2__MAKE_PRIV_FOR);
+    if ( rc )
+        return rc;
+    rc = domain_has_perm(current->domain, e, SECCLASS_DOMAIN2, DOMAIN2__SET_AS_TARGET);
+    if ( rc )
+        return rc;
     return domain_has_perm(d, e, SECCLASS_DOMAIN, DOMAIN__SET_TARGET);
 }
 
diff --git a/xen/xsm/flask/include/av_perm_to_string.h b/xen/xsm/flask/include/av_perm_to_string.h
index e7e2058..10f8e80 100644
--- a/xen/xsm/flask/include/av_perm_to_string.h
+++ b/xen/xsm/flask/include/av_perm_to_string.h
@@ -64,6 +64,8 @@
    S_(SECCLASS_DOMAIN2, DOMAIN2__RELABELFROM, "relabelfrom")
    S_(SECCLASS_DOMAIN2, DOMAIN2__RELABELTO, "relabelto")
    S_(SECCLASS_DOMAIN2, DOMAIN2__RELABELSELF, "relabelself")
+   S_(SECCLASS_DOMAIN2, DOMAIN2__MAKE_PRIV_FOR, "make_priv_for")
+   S_(SECCLASS_DOMAIN2, DOMAIN2__SET_AS_TARGET, "set_as_target")
    S_(SECCLASS_HVM, HVM__SETHVMC, "sethvmc")
    S_(SECCLASS_HVM, HVM__GETHVMC, "gethvmc")
    S_(SECCLASS_HVM, HVM__SETPARAM, "setparam")
diff --git a/xen/xsm/flask/include/av_permissions.h b/xen/xsm/flask/include/av_permissions.h
index cb1c5dc..f7cfee1 100644
--- a/xen/xsm/flask/include/av_permissions.h
+++ b/xen/xsm/flask/include/av_permissions.h
@@ -66,6 +66,8 @@
 #define DOMAIN2__RELABELFROM                      0x00000001UL
 #define DOMAIN2__RELABELTO                        0x00000002UL
 #define DOMAIN2__RELABELSELF                      0x00000004UL
+#define DOMAIN2__MAKE_PRIV_FOR                    0x00000008UL
+#define DOMAIN2__SET_AS_TARGET                    0x00000010UL
 
 #define HVM__SETHVMC                              0x00000001UL
 #define HVM__GETHVMC                              0x00000002UL
-- 
1.7.11.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 12 16:00:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Sep 2012 16:00: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 1TBpME-0005nx-RR; Wed, 12 Sep 2012 16:00:06 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1TBpMB-0005OV-Nl
	for xen-devel@lists.xen.org; Wed, 12 Sep 2012 16:00:04 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-16.tower-27.messagelabs.com!1347465594!9333739!1
X-Originating-IP: [63.239.67.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6788 invoked from network); 12 Sep 2012 15:59:55 -0000
Received: from emvm-gh1-uea09.nsa.gov (HELO nsa.gov) (63.239.67.10)
	by server-16.tower-27.messagelabs.com with SMTP;
	12 Sep 2012 15:59:55 -0000
X-TM-IMSS-Message-ID: <39e11bcd001083d2@nsa.gov>
Received: from tarius.tycho.ncsc.mil ([144.51.3.1]) by nsa.gov
	([63.239.67.10]) with ESMTP (TREND IMSS SMTP Service 7.1) id
	39e11bcd001083d2 ; Wed, 12 Sep 2012 12:02:00 -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 q8CFxoOJ006669; 
	Wed, 12 Sep 2012 11:59:53 -0400
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xen.org
Date: Wed, 12 Sep 2012 11:59:33 -0400
Message-Id: <1347465586-20009-10-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.11.4
In-Reply-To: <1347465586-20009-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1347465586-20009-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: dgdegra@tycho.nsa.gov, Keir Fraser <keir@xen.org>,
	Jan Beulich <jbeulich@suse.com>
Subject: [Xen-devel] [PATCH 09/22] xsm: Use the dummy XSM module if XSM is
	disabled
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/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 moves the implementation of the dummy XSM module to a header
file that provides inline functions when XSM_ENABLE is not defined. This
reduces duplication between the dummy module and callers when the
implementation of the dummy return is not just "return 0", and also
provides better compile-time checking for completeness of the XSM
implementations in the dummy module.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Cc: Keir Fraser <keir@xen.org>
Cc: Jan Beulich <jbeulich@suse.com>
---
 xen/common/domctl.c     |   2 -
 xen/include/xsm/dummy.h | 628 ++++++++++++++++++++++++++++++++++++++++++++++++
 xen/include/xsm/xsm.h   | 290 +++++++++++-----------
 xen/xsm/dummy.c         | 617 +----------------------------------------------
 xen/xsm/xsm_core.c      |   2 +-
 5 files changed, 772 insertions(+), 767 deletions(-)
 create mode 100644 xen/include/xsm/dummy.h

diff --git a/xen/common/domctl.c b/xen/common/domctl.c
index 2b1f182..d99ba67 100644
--- a/xen/common/domctl.c
+++ b/xen/common/domctl.c
@@ -267,10 +267,8 @@ long do_domctl(XEN_GUEST_HANDLE(xen_domctl_t) u_domctl)
             return -EPERM;
         break;
     }
-#ifdef XSM_ENABLE
     case XEN_DOMCTL_getdomaininfo:
         break;
-#endif
     default:
         if ( !IS_PRIV(current->domain) )
             return -EPERM;
diff --git a/xen/include/xsm/dummy.h b/xen/include/xsm/dummy.h
new file mode 100644
index 0000000..61c6f13
--- /dev/null
+++ b/xen/include/xsm/dummy.h
@@ -0,0 +1,628 @@
+/*
+ *  Default XSM hooks - IS_PRIV and IS_PRIV_FOR checks
+ *
+ *  Author: Daniel De Graaf <dgdegra@tyhco.nsa.gov>
+ *
+ *  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.
+ */
+
+#include <xen/sched.h>
+#include <xsm/xsm.h>
+
+static XSM_DEFAULT(void, security_domaininfo)(struct domain *d,
+                                    struct xen_domctl_getdomaininfo *info)
+{
+    return;
+}
+
+static XSM_DEFAULT(int, setvcpucontext)(struct domain *d)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, pausedomain) (struct domain *d)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, unpausedomain) (struct domain *d)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, resumedomain) (struct domain *d)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, domain_create)(struct domain *d, u32 ssidref)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, max_vcpus)(struct domain *d)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, destroydomain) (struct domain *d)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, vcpuaffinity) (int cmd, struct domain *d)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, scheduler) (struct domain *d)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, getdomaininfo) (struct domain *d)
+{
+    if ( !IS_PRIV(current->domain) )
+        return -EPERM;
+    return 0;
+}
+
+static XSM_DEFAULT(int, getvcpucontext) (struct domain *d)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, getvcpuinfo) (struct domain *d)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, domain_settime) (struct domain *d)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, set_target) (struct domain *d, struct domain *e)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, domctl)(struct domain *d, int cmd)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, set_virq_handler)(struct domain *d, uint32_t virq)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, tbufcontrol) (void)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, readconsole) (uint32_t clear)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, sched_id) (void)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, setdomainmaxmem) (struct domain *d)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, setdomainhandle) (struct domain *d)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, setdebugging) (struct domain *d)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, perfcontrol) (void)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, debug_keys) (void)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, getcpuinfo) (void)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, get_pmstat) (void)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, setpminfo) (void)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, pm_op) (void)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, do_mca) (void)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, availheap) (void)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, alloc_security_domain) (struct domain *d)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(void, free_security_domain) (struct domain *d)
+{
+    return;
+}
+
+static XSM_DEFAULT(int, grant_mapref) (struct domain *d1, struct domain *d2,
+                                                                uint32_t flags)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, grant_unmapref) (struct domain *d1, struct domain *d2)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, grant_setup) (struct domain *d1, struct domain *d2)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, grant_transfer) (struct domain *d1, struct domain *d2)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, grant_copy) (struct domain *d1, struct domain *d2)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, grant_query_size) (struct domain *d1, struct domain *d2)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, memory_adjust_reservation) (struct domain *d1,
+                                                            struct domain *d2)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, memory_stat_reservation) (struct domain *d1, struct domain *d2)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, console_io) (struct domain *d, int cmd)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, profile) (struct domain *d, int op)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, kexec) (void)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, schedop_shutdown) (struct domain *d1, struct domain *d2)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, memory_pin_page) (struct domain *d1, struct domain *d2,
+                                          struct page_info *page)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, evtchn_unbound) (struct domain *d, struct evtchn *chn,
+                                         domid_t id2)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, evtchn_interdomain) (struct domain *d1, struct evtchn
+                                *chan1, struct domain *d2, struct evtchn *chan2)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(void, evtchn_close_post) (struct evtchn *chn)
+{
+    return;
+}
+
+static XSM_DEFAULT(int, evtchn_send) (struct domain *d, struct evtchn *chn)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, evtchn_status) (struct domain *d, struct evtchn *chn)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, evtchn_reset) (struct domain *d1, struct domain *d2)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, alloc_security_evtchn) (struct evtchn *chn)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(void, free_security_evtchn) (struct evtchn *chn)
+{
+    return;
+}
+
+static XSM_DEFAULT(char *, show_security_evtchn) (struct domain *d, const struct evtchn *chn)
+{
+    return NULL;
+}
+
+static XSM_DEFAULT(int, get_pod_target)(struct domain *d)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, set_pod_target)(struct domain *d)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, get_device_group) (uint32_t machine_bdf)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, test_assign_device) (uint32_t machine_bdf)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, assign_device) (struct domain *d, uint32_t machine_bdf)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, deassign_device) (struct domain *d, uint32_t machine_bdf)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, resource_plug_core) (void)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, resource_unplug_core) (void)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, resource_plug_pci) (uint32_t machine_bdf)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, resource_unplug_pci) (uint32_t machine_bdf)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, resource_setup_pci) (uint32_t machine_bdf)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, resource_setup_gsi) (int gsi)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, resource_setup_misc) (void)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, page_offline) (uint32_t cmd)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, lockprof) (void)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, cpupool_op) (void)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, sched_op) (void)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(long, __do_xsm_op)(XEN_GUEST_HANDLE(xsm_op_t) op)
+{
+    return -ENOSYS;
+}
+
+static XSM_DEFAULT(char *, show_irq_sid) (int irq)
+{
+    return NULL;
+}
+
+static XSM_DEFAULT(int, map_domain_pirq) (struct domain *d, int irq, void *data)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, unmap_domain_pirq) (struct domain *d, int irq)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, irq_permission) (struct domain *d, int pirq, uint8_t allow)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, iomem_permission) (struct domain *d, uint64_t s, uint64_t e, uint8_t allow)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, iomem_mapping) (struct domain *d, uint64_t s, uint64_t e, uint8_t allow)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, pci_config_permission) (struct domain *d, uint32_t machine_bdf,
+                                        uint16_t start, uint16_t end,
+                                        uint8_t access)
+{
+    return 0;
+}
+
+#ifdef CONFIG_X86
+static XSM_DEFAULT(int, shadow_control) (struct domain *d, uint32_t op)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, getpageframeinfo) (struct domain *d)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, getmemlist) (struct domain *d)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, hypercall_init) (struct domain *d)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, hvmcontext) (struct domain *d, uint32_t cmd)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, address_size) (struct domain *d, uint32_t cmd)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, machine_address_size) (struct domain *d, uint32_t cmd)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, hvm_param) (struct domain *d, unsigned long op)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, hvm_set_pci_intx_level) (struct domain *d)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, hvm_set_isa_irq_level) (struct domain *d)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, hvm_set_pci_link_route) (struct domain *d)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, hvm_inject_msi) (struct domain *d)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, mem_event) (struct domain *d)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, mem_sharing) (struct domain *d)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, apic) (struct domain *d, int cmd)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, xen_settime) (void)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, memtype) (uint32_t access)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, microcode) (void)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, physinfo) (void)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, platform_quirk) (uint32_t quirk)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, firmware_info) (void)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, efi_call) (void)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, acpi_sleep) (void)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, change_freq) (void)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, getidletime) (void)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, machine_memory_map) (void)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, domain_memory_map) (struct domain *d)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, mmu_normal_update) (struct domain *d, struct domain *t,
+                                            struct domain *f, intpte_t fpte)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, mmu_machphys_update) (struct domain *d, struct domain *f,
+                                              unsigned long mfn)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, update_va_mapping) (struct domain *d, struct domain *f, 
+                                                            l1_pgentry_t pte)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, add_to_physmap) (struct domain *d1, struct domain *d2)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, remove_from_physmap) (struct domain *d1, struct domain *d2)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, sendtrigger) (struct domain *d)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, bind_pt_irq) (struct domain *d, struct xen_domctl_bind_pt_irq *bind)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, unbind_pt_irq) (struct domain *d, struct xen_domctl_bind_pt_irq *bind)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, pin_mem_cacheattr) (struct domain *d)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, ext_vcpucontext) (struct domain *d, uint32_t cmd)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, vcpuextstate) (struct domain *d, uint32_t cmd)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, ioport_permission) (struct domain *d, uint32_t s, uint32_t e, uint8_t allow)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, ioport_mapping) (struct domain *d, uint32_t s, uint32_t e, uint8_t allow)
+{
+    return 0;
+}
+
+#endif
diff --git a/xen/include/xsm/xsm.h b/xen/include/xsm/xsm.h
index cbbe673..ba5a89e 100644
--- a/xen/include/xsm/xsm.h
+++ b/xen/include/xsm/xsm.h
@@ -21,12 +21,6 @@
 typedef void xsm_op_t;
 DEFINE_XEN_GUEST_HANDLE(xsm_op_t);
 
-#ifdef XSM_ENABLE
-    #define xsm_call(fn) xsm_ops->fn
-#else
-    #define xsm_call(fn) 0
-#endif
-
 /* policy magic number (defined by XSM_MAGIC) */
 typedef u32 xsm_magic_t;
 #ifndef XSM_MAGIC
@@ -187,645 +181,643 @@ struct xsm_operations {
 #endif
 };
 
-#endif
-
 extern struct xsm_operations *xsm_ops;
 
 static inline void xsm_security_domaininfo (struct domain *d,
                                         struct xen_domctl_getdomaininfo *info)
 {
-    (void)xsm_call(security_domaininfo(d, info));
+    xsm_ops->security_domaininfo(d, info);
 }
 
 static inline int xsm_setvcpucontext(struct domain *d)
 {
-    return xsm_call(setvcpucontext(d));
+    return xsm_ops->setvcpucontext(d);
 }
 
 static inline int xsm_pausedomain (struct domain *d)
 {
-    return xsm_call(pausedomain(d));
+    return xsm_ops->pausedomain(d);
 }
 
 static inline int xsm_unpausedomain (struct domain *d)
 {
-    return xsm_call(unpausedomain(d));
+    return xsm_ops->unpausedomain(d);
 }
 
 static inline int xsm_resumedomain (struct domain *d)
 {
-    return xsm_call(resumedomain(d));
+    return xsm_ops->resumedomain(d);
 }
 
 static inline int xsm_domain_create (struct domain *d, u32 ssidref)
 {
-    return xsm_call(domain_create(d, ssidref));
+    return xsm_ops->domain_create(d, ssidref);
 }
 
 static inline int xsm_max_vcpus(struct domain *d)
 {
-    return xsm_call(max_vcpus(d));
+    return xsm_ops->max_vcpus(d);
 }
 
 static inline int xsm_destroydomain (struct domain *d)
 {
-    return xsm_call(destroydomain(d));
+    return xsm_ops->destroydomain(d);
 }
 
 static inline int xsm_vcpuaffinity (int cmd, struct domain *d)
 {
-    return xsm_call(vcpuaffinity(cmd, d));
+    return xsm_ops->vcpuaffinity(cmd, d);
 }
 
 static inline int xsm_scheduler (struct domain *d)
 {
-    return xsm_call(scheduler(d));
+    return xsm_ops->scheduler(d);
 }
 
 static inline int xsm_getdomaininfo (struct domain *d)
 {
-    return xsm_call(getdomaininfo(d));
+    return xsm_ops->getdomaininfo(d);
 }
 
 static inline int xsm_getvcpucontext (struct domain *d)
 {
-    return xsm_call(getvcpucontext(d));
+    return xsm_ops->getvcpucontext(d);
 }
 
 static inline int xsm_getvcpuinfo (struct domain *d)
 {
-    return xsm_call(getvcpuinfo(d));
+    return xsm_ops->getvcpuinfo(d);
 }
 
 static inline int xsm_domain_settime (struct domain *d)
 {
-    return xsm_call(domain_settime(d));
+    return xsm_ops->domain_settime(d);
 }
 
 static inline int xsm_set_target (struct domain *d, struct domain *e)
 {
-    return xsm_call(set_target(d, e));
+    return xsm_ops->set_target(d, e);
 }
 
 static inline int xsm_domctl (struct domain *d, int cmd)
 {
-    return xsm_call(domctl(d, cmd));
+    return xsm_ops->domctl(d, cmd);
 }
 
 static inline int xsm_set_virq_handler (struct domain *d, uint32_t virq)
 {
-    return xsm_call(set_virq_handler(d, virq));
+    return xsm_ops->set_virq_handler(d, virq);
 }
 
 static inline int xsm_tbufcontrol (void)
 {
-    return xsm_call(tbufcontrol());
+    return xsm_ops->tbufcontrol();
 }
 
 static inline int xsm_readconsole (uint32_t clear)
 {
-    return xsm_call(readconsole(clear));
+    return xsm_ops->readconsole(clear);
 }
 
 static inline int xsm_sched_id (void)
 {
-    return xsm_call(sched_id());
+    return xsm_ops->sched_id();
 }
 
 static inline int xsm_setdomainmaxmem (struct domain *d)
 {
-    return xsm_call(setdomainmaxmem(d));
+    return xsm_ops->setdomainmaxmem(d);
 }
 
 static inline int xsm_setdomainhandle (struct domain *d)
 {
-    return xsm_call(setdomainhandle(d));
+    return xsm_ops->setdomainhandle(d);
 }
 
 static inline int xsm_setdebugging (struct domain *d)
 {
-    return xsm_call(setdebugging(d));
+    return xsm_ops->setdebugging(d);
 }
 
 static inline int xsm_perfcontrol (void)
 {
-    return xsm_call(perfcontrol());
+    return xsm_ops->perfcontrol();
 }
 
 static inline int xsm_debug_keys (void)
 {
-    return xsm_call(debug_keys());
+    return xsm_ops->debug_keys();
 }
 
 static inline int xsm_availheap (void)
 {
-    return xsm_call(availheap());
+    return xsm_ops->availheap();
 }
 
 static inline int xsm_getcpuinfo (void)
 {
-    return xsm_call(getcpuinfo());
+    return xsm_ops->getcpuinfo();
 }
 
 static inline int xsm_get_pmstat(void)
 {
-    return xsm_call(get_pmstat());
+    return xsm_ops->get_pmstat();
 }
 
 static inline int xsm_setpminfo(void)
 {
-	return xsm_call(setpminfo());
+    return xsm_ops->setpminfo();
 }
 
 static inline int xsm_pm_op(void)
 {
-    return xsm_call(pm_op());
+    return xsm_ops->pm_op();
 }
 
 static inline int xsm_do_mca(void)
 {
-    return xsm_call(do_mca());
+    return xsm_ops->do_mca();
 }
 
 static inline int xsm_evtchn_unbound (struct domain *d1, struct evtchn *chn,
                                                                     domid_t id2)
 {
-    return xsm_call(evtchn_unbound(d1, chn, id2));
+    return xsm_ops->evtchn_unbound(d1, chn, id2);
 }
 
 static inline int xsm_evtchn_interdomain (struct domain *d1, 
                 struct evtchn *chan1, struct domain *d2, struct evtchn *chan2)
 {
-    return xsm_call(evtchn_interdomain(d1, chan1, d2, chan2));
+    return xsm_ops->evtchn_interdomain(d1, chan1, d2, chan2);
 }
 
 static inline void xsm_evtchn_close_post (struct evtchn *chn)
 {
-    (void)xsm_call(evtchn_close_post(chn));
+    xsm_ops->evtchn_close_post(chn);
 }
 
 static inline int xsm_evtchn_send (struct domain *d, struct evtchn *chn)
 {
-    return xsm_call(evtchn_send(d, chn));
+    return xsm_ops->evtchn_send(d, chn);
 }
 
 static inline int xsm_evtchn_status (struct domain *d, struct evtchn *chn)
 {
-    return xsm_call(evtchn_status(d, chn));
+    return xsm_ops->evtchn_status(d, chn);
 }
 
 static inline int xsm_evtchn_reset (struct domain *d1, struct domain *d2)
 {
-    return xsm_call(evtchn_reset(d1, d2));
+    return xsm_ops->evtchn_reset(d1, d2);
 }
 
 static inline int xsm_grant_mapref (struct domain *d1, struct domain *d2,
                                                                 uint32_t flags)
 {
-    return xsm_call(grant_mapref(d1, d2, flags));
+    return xsm_ops->grant_mapref(d1, d2, flags);
 }
 
 static inline int xsm_grant_unmapref (struct domain *d1, struct domain *d2)
 {
-    return xsm_call(grant_unmapref(d1, d2));
+    return xsm_ops->grant_unmapref(d1, d2);
 }
 
 static inline int xsm_grant_setup (struct domain *d1, struct domain *d2)
 {
-    return xsm_call(grant_setup(d1, d2));
+    return xsm_ops->grant_setup(d1, d2);
 }
 
 static inline int xsm_grant_transfer (struct domain *d1, struct domain *d2)
 {
-    return xsm_call(grant_transfer(d1, d2));
+    return xsm_ops->grant_transfer(d1, d2);
 }
 
 static inline int xsm_grant_copy (struct domain *d1, struct domain *d2)
 {
-    return xsm_call(grant_copy(d1, d2));
+    return xsm_ops->grant_copy(d1, d2);
 }
 
 static inline int xsm_grant_query_size (struct domain *d1, struct domain *d2)
 {
-    return xsm_call(grant_query_size(d1, d2));
+    return xsm_ops->grant_query_size(d1, d2);
 }
 
 static inline int xsm_alloc_security_domain (struct domain *d)
 {
-    return xsm_call(alloc_security_domain(d));
+    return xsm_ops->alloc_security_domain(d);
 }
 
 static inline void xsm_free_security_domain (struct domain *d)
 {
-    (void)xsm_call(free_security_domain(d));
+    xsm_ops->free_security_domain(d);
 }
 
 static inline int xsm_alloc_security_evtchn (struct evtchn *chn)
 {
-    return xsm_call(alloc_security_evtchn(chn));
+    return xsm_ops->alloc_security_evtchn(chn);
 }
 
 static inline void xsm_free_security_evtchn (struct evtchn *chn)
 {
-    (void)xsm_call(free_security_evtchn(chn));
+    (void)xsm_ops->free_security_evtchn(chn);
 }
 
 static inline char *xsm_show_security_evtchn (struct domain *d, const struct evtchn *chn)
 {
-    return xsm_call(show_security_evtchn(d, chn));
+    return xsm_ops->show_security_evtchn(d, chn);
 }
 
 static inline int xsm_get_pod_target (struct domain *d)
 {
-    return xsm_call(get_pod_target(d));
+    return xsm_ops->get_pod_target(d);
 }
 
 static inline int xsm_set_pod_target (struct domain *d)
 {
-    return xsm_call(set_pod_target(d));
+    return xsm_ops->set_pod_target(d);
 }
 
 static inline int xsm_memory_adjust_reservation (struct domain *d1, struct
                                                                     domain *d2)
 {
-    return xsm_call(memory_adjust_reservation(d1, d2));
+    return xsm_ops->memory_adjust_reservation(d1, d2);
 }
 
 static inline int xsm_memory_stat_reservation (struct domain *d1,
                                                             struct domain *d2)
 {
-    return xsm_call(memory_stat_reservation(d1, d2));
+    return xsm_ops->memory_stat_reservation(d1, d2);
 }
 
 static inline int xsm_memory_pin_page(struct domain *d1, struct domain *d2,
                                       struct page_info *page)
 {
-    return xsm_call(memory_pin_page(d1, d2, page));
+    return xsm_ops->memory_pin_page(d1, d2, page);
 }
 
 static inline int xsm_remove_from_physmap(struct domain *d1, struct domain *d2)
 {
-    return xsm_call(remove_from_physmap(d1, d2));
+    return xsm_ops->remove_from_physmap(d1, d2);
 }
 
 static inline int xsm_console_io (struct domain *d, int cmd)
 {
-    return xsm_call(console_io(d, cmd));
+    return xsm_ops->console_io(d, cmd);
 }
 
 static inline int xsm_profile (struct domain *d, int op)
 {
-    return xsm_call(profile(d, op));
+    return xsm_ops->profile(d, op);
 }
 
 static inline int xsm_kexec (void)
 {
-    return xsm_call(kexec());
+    return xsm_ops->kexec();
 }
 
 static inline int xsm_schedop_shutdown (struct domain *d1, struct domain *d2)
 {
-    return xsm_call(schedop_shutdown(d1, d2));
+    return xsm_ops->schedop_shutdown(d1, d2);
 }
 
 static inline char *xsm_show_irq_sid (int irq)
 {
-    return xsm_call(show_irq_sid(irq));
+    return xsm_ops->show_irq_sid(irq);
 }
 
 static inline int xsm_map_domain_pirq (struct domain *d, int irq, void *data)
 {
-    return xsm_call(map_domain_pirq(d, irq, data));
+    return xsm_ops->map_domain_pirq(d, irq, data);
 }
 
 static inline int xsm_unmap_domain_pirq (struct domain *d, int irq)
 {
-    return xsm_call(unmap_domain_pirq(d, irq));
+    return xsm_ops->unmap_domain_pirq(d, irq);
 }
 
 static inline int xsm_irq_permission (struct domain *d, int pirq, uint8_t allow)
 {
-    return xsm_call(irq_permission(d, pirq, allow));
+    return xsm_ops->irq_permission(d, pirq, allow);
 }
 
 static inline int xsm_iomem_permission (struct domain *d, uint64_t s, uint64_t e, uint8_t allow)
 {
-    return xsm_call(iomem_permission(d, s, e, allow));
+    return xsm_ops->iomem_permission(d, s, e, allow);
 }
 
 static inline int xsm_iomem_mapping (struct domain *d, uint64_t s, uint64_t e, uint8_t allow)
 {
-    return xsm_call(iomem_mapping(d, s, e, allow));
+    return xsm_ops->iomem_mapping(d, s, e, allow);
 }
 
 static inline int xsm_pci_config_permission (struct domain *d, uint32_t machine_bdf, uint16_t start, uint16_t end, uint8_t access)
 {
-    return xsm_call(pci_config_permission(d, machine_bdf, start, end, access));
+    return xsm_ops->pci_config_permission(d, machine_bdf, start, end, access);
 }
 
 static inline int xsm_get_device_group(uint32_t machine_bdf)
 {
-    return xsm_call(get_device_group(machine_bdf));
+    return xsm_ops->get_device_group(machine_bdf);
 }
 
 static inline int xsm_test_assign_device(uint32_t machine_bdf)
 {
-    return xsm_call(test_assign_device(machine_bdf));
+    return xsm_ops->test_assign_device(machine_bdf);
 }
 
 static inline int xsm_assign_device(struct domain *d, uint32_t machine_bdf)
 {
-    return xsm_call(assign_device(d, machine_bdf));
+    return xsm_ops->assign_device(d, machine_bdf);
 }
 
 static inline int xsm_deassign_device(struct domain *d, uint32_t machine_bdf)
 {
-    return xsm_call(deassign_device(d, machine_bdf));
+    return xsm_ops->deassign_device(d, machine_bdf);
 }
 
 static inline int xsm_resource_plug_pci (uint32_t machine_bdf)
 {
-    return xsm_call(resource_plug_pci(machine_bdf));
+    return xsm_ops->resource_plug_pci(machine_bdf);
 }
 
 static inline int xsm_resource_unplug_pci (uint32_t machine_bdf)
 {
-    return xsm_call(resource_unplug_pci(machine_bdf));
+    return xsm_ops->resource_unplug_pci(machine_bdf);
 }
 
 static inline int xsm_resource_plug_core (void)
 {
-    return xsm_call(resource_plug_core());
+    return xsm_ops->resource_plug_core();
 }
 
 static inline int xsm_resource_unplug_core (void)
 {
-    return xsm_call(resource_unplug_core());
+    return xsm_ops->resource_unplug_core();
 }
 
 static inline int xsm_resource_setup_pci (uint32_t machine_bdf)
 {
-    return xsm_call(resource_setup_pci(machine_bdf));
+    return xsm_ops->resource_setup_pci(machine_bdf);
 }
 
 static inline int xsm_resource_setup_gsi (int gsi)
 {
-    return xsm_call(resource_setup_gsi(gsi));
+    return xsm_ops->resource_setup_gsi(gsi);
 }
 
 static inline int xsm_resource_setup_misc (void)
 {
-    return xsm_call(resource_setup_misc());
+    return xsm_ops->resource_setup_misc();
 }
 
 static inline int xsm_page_offline(uint32_t cmd)
 {
-    return xsm_call(page_offline(cmd));
+    return xsm_ops->page_offline(cmd);
 }
 
 static inline int xsm_lockprof(void)
 {
-    return xsm_call(lockprof());
+    return xsm_ops->lockprof();
 }
 
 static inline int xsm_cpupool_op(void)
 {
-    return xsm_call(cpupool_op());
+    return xsm_ops->cpupool_op();
 }
 
 static inline int xsm_sched_op(void)
 {
-    return xsm_call(sched_op());
+    return xsm_ops->sched_op();
 }
 
-static inline long __do_xsm_op (XEN_GUEST_HANDLE(xsm_op_t) op)
+static inline long xsm___do_xsm_op (XEN_GUEST_HANDLE(xsm_op_t) op)
 {
-#ifdef XSM_ENABLE
     return xsm_ops->__do_xsm_op(op);
-#else
-    return -ENOSYS;
-#endif
-}
-
-#ifdef XSM_ENABLE
-extern int xsm_init(unsigned long *module_map, const multiboot_info_t *mbi,
-                    void *(*bootstrap_map)(const module_t *));
-extern int xsm_policy_init(unsigned long *module_map,
-                           const multiboot_info_t *mbi,
-                           void *(*bootstrap_map)(const module_t *));
-extern int register_xsm(struct xsm_operations *ops);
-extern int unregister_xsm(struct xsm_operations *ops);
-#else
-static inline int xsm_init (unsigned long *module_map,
-                            const multiboot_info_t *mbi,
-                            void *(*bootstrap_map)(const module_t *))
-{
-    return 0;
 }
-#endif
 
 #ifdef CONFIG_X86
 static inline int xsm_shadow_control (struct domain *d, uint32_t op)
 {
-    return xsm_call(shadow_control(d, op));
+    return xsm_ops->shadow_control(d, op);
 }
 
 static inline int xsm_getpageframeinfo (struct domain *d)
 {
-    return xsm_call(getpageframeinfo(d));
+    return xsm_ops->getpageframeinfo(d);
 }
 
 static inline int xsm_getmemlist (struct domain *d)
 {
-    return xsm_call(getmemlist(d));
+    return xsm_ops->getmemlist(d);
 }
 
 static inline int xsm_hypercall_init (struct domain *d)
 {
-    return xsm_call(hypercall_init(d));
+    return xsm_ops->hypercall_init(d);
 }
 
 static inline int xsm_hvmcontext (struct domain *d, uint32_t cmd)
 {
-    return xsm_call(hvmcontext(d, cmd));
+    return xsm_ops->hvmcontext(d, cmd);
 }
 
 static inline int xsm_address_size (struct domain *d, uint32_t cmd)
 {
-    return xsm_call(address_size(d, cmd));
+    return xsm_ops->address_size(d, cmd);
 }
 
 static inline int xsm_machine_address_size (struct domain *d, uint32_t cmd)
 {
-    return xsm_call(machine_address_size(d, cmd));
+    return xsm_ops->machine_address_size(d, cmd);
 }
 
 static inline int xsm_hvm_param (struct domain *d, unsigned long op)
 {
-    return xsm_call(hvm_param(d, op));
+    return xsm_ops->hvm_param(d, op);
 }
 
 static inline int xsm_hvm_set_pci_intx_level (struct domain *d)
 {
-    return xsm_call(hvm_set_pci_intx_level(d));
+    return xsm_ops->hvm_set_pci_intx_level(d);
 }
 
 static inline int xsm_hvm_set_isa_irq_level (struct domain *d)
 {
-    return xsm_call(hvm_set_isa_irq_level(d));
+    return xsm_ops->hvm_set_isa_irq_level(d);
 }
 
 static inline int xsm_hvm_set_pci_link_route (struct domain *d)
 {
-    return xsm_call(hvm_set_pci_link_route(d));
+    return xsm_ops->hvm_set_pci_link_route(d);
 }
 
 static inline int xsm_hvm_inject_msi (struct domain *d)
 {
-    return xsm_call(hvm_inject_msi(d));
+    return xsm_ops->hvm_inject_msi(d);
 }
 
 static inline int xsm_mem_event (struct domain *d)
 {
-    return xsm_call(mem_event(d));
+    return xsm_ops->mem_event(d);
 }
 
 static inline int xsm_mem_sharing (struct domain *d)
 {
-    return xsm_call(mem_sharing(d));
+    return xsm_ops->mem_sharing(d);
 }
 
 static inline int xsm_apic (struct domain *d, int cmd)
 {
-    return xsm_call(apic(d, cmd));
+    return xsm_ops->apic(d, cmd);
 }
 
 static inline int xsm_xen_settime (void)
 {
-    return xsm_call(xen_settime());
+    return xsm_ops->xen_settime();
 }
 
 static inline int xsm_memtype (uint32_t access)
 {
-    return xsm_call(memtype(access));
+    return xsm_ops->memtype(access);
 }
 
 static inline int xsm_microcode (void)
 {
-    return xsm_call(microcode());
+    return xsm_ops->microcode();
 }
 
 static inline int xsm_physinfo (void)
 {
-    return xsm_call(physinfo());
+    return xsm_ops->physinfo();
 }
 
 static inline int xsm_platform_quirk (uint32_t quirk)
 {
-    return xsm_call(platform_quirk(quirk));
+    return xsm_ops->platform_quirk(quirk);
 }
 
 static inline int xsm_firmware_info (void)
 {
-    return xsm_call(firmware_info());
+    return xsm_ops->firmware_info();
 }
 
 static inline int xsm_efi_call (void)
 {
-    return xsm_call(efi_call());
+    return xsm_ops->efi_call();
 }
 
 static inline int xsm_acpi_sleep (void)
 {
-    return xsm_call(acpi_sleep());
+    return xsm_ops->acpi_sleep();
 }
 
 static inline int xsm_change_freq (void)
 {
-    return xsm_call(change_freq());
+    return xsm_ops->change_freq();
 }
 
 static inline int xsm_getidletime (void)
 {
-    return xsm_call(getidletime());
+    return xsm_ops->getidletime();
 }
 
 static inline int xsm_machine_memory_map(void)
 {
-    return xsm_call(machine_memory_map());
+    return xsm_ops->machine_memory_map();
 }
 
 static inline int xsm_domain_memory_map(struct domain *d)
 {
-    return xsm_call(domain_memory_map(d));
+    return xsm_ops->domain_memory_map(d);
 }
 
 static inline int xsm_mmu_normal_update (struct domain *d, struct domain *t,
                                          struct domain *f, intpte_t fpte)
 {
-    return xsm_call(mmu_normal_update(d, t, f, fpte));
+    return xsm_ops->mmu_normal_update(d, t, f, fpte);
 }
 
 static inline int xsm_mmu_machphys_update (struct domain *d1, struct domain *d2,
                                            unsigned long mfn)
 {
-    return xsm_call(mmu_machphys_update(d1, d2, mfn));
+    return xsm_ops->mmu_machphys_update(d1, d2, mfn);
 }
 
 static inline int xsm_update_va_mapping(struct domain *d, struct domain *f, 
                                                             l1_pgentry_t pte)
 {
-    return xsm_call(update_va_mapping(d, f, pte));
+    return xsm_ops->update_va_mapping(d, f, pte);
 }
 
 static inline int xsm_add_to_physmap(struct domain *d1, struct domain *d2)
 {
-    return xsm_call(add_to_physmap(d1, d2));
+    return xsm_ops->add_to_physmap(d1, d2);
 }
 
 static inline int xsm_sendtrigger(struct domain *d)
 {
-    return xsm_call(sendtrigger(d));
+    return xsm_ops->sendtrigger(d);
 }
 
 static inline int xsm_bind_pt_irq(struct domain *d, 
                                                 struct xen_domctl_bind_pt_irq *bind)
 {
-    return xsm_call(bind_pt_irq(d, bind));
+    return xsm_ops->bind_pt_irq(d, bind);
 }
 
 static inline int xsm_unbind_pt_irq(struct domain *d,
                                                 struct xen_domctl_bind_pt_irq *bind)
 {
-    return xsm_call(unbind_pt_irq(d, bind));
+    return xsm_ops->unbind_pt_irq(d, bind);
 }
 
 static inline int xsm_pin_mem_cacheattr(struct domain *d)
 {
-    return xsm_call(pin_mem_cacheattr(d));
+    return xsm_ops->pin_mem_cacheattr(d);
 }
 
 static inline int xsm_ext_vcpucontext(struct domain *d, uint32_t cmd)
 {
-    return xsm_call(ext_vcpucontext(d, cmd));
+    return xsm_ops->ext_vcpucontext(d, cmd);
 }
 static inline int xsm_vcpuextstate(struct domain *d, uint32_t cmd)
 {
-    return xsm_call(vcpuextstate(d, cmd));
+    return xsm_ops->vcpuextstate(d, cmd);
 }
 
 static inline int xsm_ioport_permission (struct domain *d, uint32_t s, uint32_t e, uint8_t allow)
 {
-    return xsm_call(ioport_permission(d, s, e, allow));
+    return xsm_ops->ioport_permission(d, s, e, allow);
 }
 
 static inline int xsm_ioport_mapping (struct domain *d, uint32_t s, uint32_t e, uint8_t allow)
 {
-    return xsm_call(ioport_mapping(d, s, e, allow));
+    return xsm_ops->ioport_mapping(d, s, e, allow);
 }
 #endif /* CONFIG_X86 */
 
+extern int xsm_init(unsigned long *module_map, const multiboot_info_t *mbi,
+                    void *(*bootstrap_map)(const module_t *));
+extern int xsm_policy_init(unsigned long *module_map,
+                           const multiboot_info_t *mbi,
+                           void *(*bootstrap_map)(const module_t *));
+extern int register_xsm(struct xsm_operations *ops);
+extern int unregister_xsm(struct xsm_operations *ops);
+
 extern struct xsm_operations dummy_xsm_ops;
 extern void xsm_fixup_ops(struct xsm_operations *ops);
 
+#else /* XSM_ENABLE */
+
+#define XSM_DEFAULT(type, name) inline type xsm_ ## name
+#include <xsm/dummy.h>
+
+static inline int xsm_init (unsigned long *module_map,
+                            const multiboot_info_t *mbi,
+                            void *(*bootstrap_map)(const module_t *))
+{
+    return 0;
+}
+#endif /* XSM_ENABLE */
+
 #endif /* __XSM_H */
diff --git a/xen/xsm/dummy.c b/xen/xsm/dummy.c
index a5dbfe7..af532b8 100644
--- a/xen/xsm/dummy.c
+++ b/xen/xsm/dummy.c
@@ -10,621 +10,8 @@
  *  as published by the Free Software Foundation.
  */
 
-#include <xen/sched.h>
-#include <xsm/xsm.h>
-
-static void dummy_security_domaininfo(struct domain *d,
-                                    struct xen_domctl_getdomaininfo *info)
-{
-    return;
-}
-
-static int dummy_setvcpucontext(struct domain *d)
-{
-    return 0;
-}
-
-static int dummy_pausedomain (struct domain *d)
-{
-    return 0;
-}
-
-static int dummy_unpausedomain (struct domain *d)
-{
-    return 0;
-}
-
-static int dummy_resumedomain (struct domain *d)
-{
-    return 0;
-}
-
-static int dummy_domain_create(struct domain *d, u32 ssidref)
-{
-    return 0;
-}
-
-static int dummy_max_vcpus(struct domain *d)
-{
-    return 0;
-}
-
-static int dummy_destroydomain (struct domain *d)
-{
-    return 0;
-}
-
-static int dummy_vcpuaffinity (int cmd, struct domain *d)
-{
-    return 0;
-}
-
-static int dummy_scheduler (struct domain *d)
-{
-    return 0;
-}
-
-static int dummy_getdomaininfo (struct domain *d)
-{
-    if ( !IS_PRIV(current->domain) )
-        return -EPERM;
-    return 0;
-}
-
-static int dummy_getvcpucontext (struct domain *d)
-{
-    return 0;
-}
-
-static int dummy_getvcpuinfo (struct domain *d)
-{
-    return 0;
-}
-
-static int dummy_domain_settime (struct domain *d)
-{
-    return 0;
-}
-
-static int dummy_set_target (struct domain *d, struct domain *e)
-{
-    return 0;
-}
-
-static int dummy_domctl(struct domain *d, int cmd)
-{
-    return 0;
-}
-
-static int dummy_set_virq_handler(struct domain *d, uint32_t virq)
-{
-    return 0;
-}
-
-static int dummy_tbufcontrol (void)
-{
-    return 0;
-}
-
-static int dummy_readconsole (uint32_t clear)
-{
-    return 0;
-}
-
-static int dummy_sched_id (void)
-{
-    return 0;
-}
-
-static int dummy_setdomainmaxmem (struct domain *d)
-{
-    return 0;
-}
-
-static int dummy_setdomainhandle (struct domain *d)
-{
-    return 0;
-}
-
-static int dummy_setdebugging (struct domain *d)
-{
-    return 0;
-}
-
-static int dummy_perfcontrol (void)
-{
-    return 0;
-}
-
-static int dummy_debug_keys (void)
-{
-    return 0;
-}
-
-static int dummy_getcpuinfo (void)
-{
-    return 0;
-}
-
-static int dummy_get_pmstat (void)
-{
-    return 0;
-}
-
-static int dummy_setpminfo (void)
-{
-    return 0;
-}
-
-static int dummy_pm_op (void)
-{
-    return 0;
-}
-
-static int dummy_do_mca (void)
-{
-    return 0;
-}
-
-static int dummy_availheap (void)
-{
-    return 0;
-}
-
-static int dummy_alloc_security_domain (struct domain *d)
-{
-    return 0;
-}
-
-static void dummy_free_security_domain (struct domain *d)
-{
-    return;
-}
-
-static int dummy_grant_mapref (struct domain *d1, struct domain *d2,
-                                                                uint32_t flags)
-{
-    return 0;
-}
-
-static int dummy_grant_unmapref (struct domain *d1, struct domain *d2)
-{
-    return 0;
-}
-
-static int dummy_grant_setup (struct domain *d1, struct domain *d2)
-{
-    return 0;
-}
-
-static int dummy_grant_transfer (struct domain *d1, struct domain *d2)
-{
-    return 0;
-}
-
-static int dummy_grant_copy (struct domain *d1, struct domain *d2)
-{
-    return 0;
-}
-
-static int dummy_grant_query_size (struct domain *d1, struct domain *d2)
-{
-    return 0;
-}
-
-static int dummy_memory_adjust_reservation (struct domain *d1,
-                                                            struct domain *d2)
-{
-    return 0;
-}
-
-static int dummy_memory_stat_reservation (struct domain *d1, struct domain *d2)
-{
-    return 0;
-}
-
-static int dummy_console_io (struct domain *d, int cmd)
-{
-    return 0;
-}
-
-static int dummy_profile (struct domain *d, int op)
-{
-    return 0;
-}
-
-static int dummy_kexec (void)
-{
-    return 0;
-}
-
-static int dummy_schedop_shutdown (struct domain *d1, struct domain *d2)
-{
-    return 0;
-}
-
-static int dummy_memory_pin_page(struct domain *d1, struct domain *d2, struct page_info *page)
-{
-    return 0;
-}
-
-static int dummy_evtchn_unbound (struct domain *d, struct evtchn *chn,
-                                                                    domid_t id2)
-{
-    return 0;
-}
-
-static int dummy_evtchn_interdomain (struct domain *d1, struct evtchn
-                                *chan1, struct domain *d2, struct evtchn *chan2)
-{
-    return 0;
-}
-
-static void dummy_evtchn_close_post (struct evtchn *chn)
-{
-    return;
-}
-
-static int dummy_evtchn_send (struct domain *d, struct evtchn *chn)
-{
-    return 0;
-}
-
-static int dummy_evtchn_status (struct domain *d, struct evtchn *chn)
-{
-    return 0;
-}
-
-static int dummy_evtchn_reset (struct domain *d1, struct domain *d2)
-{
-    return 0;
-}
-
-static int dummy_alloc_security_evtchn (struct evtchn *chn)
-{
-    return 0;
-}
-
-static void dummy_free_security_evtchn (struct evtchn *chn)
-{
-    return;
-}
-
-static char *dummy_show_security_evtchn (struct domain *d, const struct evtchn *chn)
-{
-    return NULL;
-}
-
-static int dummy_get_pod_target(struct domain *d)
-{
-    return 0;
-}
-
-static int dummy_set_pod_target(struct domain *d)
-{
-    return 0;
-}
-
-static int dummy_get_device_group (uint32_t machine_bdf)
-{
-    return 0;
-}
-
-static int dummy_test_assign_device (uint32_t machine_bdf)
-{
-    return 0;
-}
-
-static int dummy_assign_device (struct domain *d, uint32_t machine_bdf)
-{
-    return 0;
-}
-
-static int dummy_deassign_device (struct domain *d, uint32_t machine_bdf)
-{
-    return 0;
-}
-
-static int dummy_resource_plug_core (void)
-{
-    return 0;
-}
-
-static int dummy_resource_unplug_core (void)
-{
-    return 0;
-}
-
-static int dummy_resource_plug_pci (uint32_t machine_bdf)
-{
-    return 0;
-}
-
-static int dummy_resource_unplug_pci (uint32_t machine_bdf)
-{
-    return 0;
-}
-
-static int dummy_resource_setup_pci (uint32_t machine_bdf)
-{
-    return 0;
-}
-
-static int dummy_resource_setup_gsi (int gsi)
-{
-    return 0;
-}
-
-static int dummy_resource_setup_misc (void)
-{
-    return 0;
-}
-
-static int dummy_page_offline (uint32_t cmd)
-{
-    return 0;
-}
-
-static int dummy_lockprof (void)
-{
-    return 0;
-}
-
-static int dummy_cpupool_op (void)
-{
-    return 0;
-}
-
-static int dummy_sched_op (void)
-{
-    return 0;
-}
-
-static long dummy___do_xsm_op(XEN_GUEST_HANDLE(xsm_op_t) op)
-{
-    return -ENOSYS;
-}
-
-static char *dummy_show_irq_sid (int irq)
-{
-    return NULL;
-}
-
-static int dummy_map_domain_pirq (struct domain *d, int irq, void *data)
-{
-    return 0;
-}
-
-static int dummy_unmap_domain_pirq (struct domain *d, int irq)
-{
-    return 0;
-}
-
-static int dummy_irq_permission (struct domain *d, int pirq, uint8_t allow)
-{
-    return 0;
-}
-
-static int dummy_iomem_permission (struct domain *d, uint64_t s, uint64_t e, uint8_t allow)
-{
-    return 0;
-}
-
-static int dummy_iomem_mapping (struct domain *d, uint64_t s, uint64_t e, uint8_t allow)
-{
-    return 0;
-}
-
-static int dummy_pci_config_permission (struct domain *d, uint32_t machine_bdf,
-                                        uint16_t start, uint16_t end,
-                                        uint8_t access)
-{
-    return 0;
-}
-
-#ifdef CONFIG_X86
-static int dummy_shadow_control (struct domain *d, uint32_t op)
-{
-    return 0;
-}
-
-static int dummy_getpageframeinfo (struct domain *d)
-{
-    return 0;
-}
-
-static int dummy_getmemlist (struct domain *d)
-{
-    return 0;
-}
-
-static int dummy_hypercall_init (struct domain *d)
-{
-    return 0;
-}
-
-static int dummy_hvmcontext (struct domain *d, uint32_t cmd)
-{
-    return 0;
-}
-
-static int dummy_address_size (struct domain *d, uint32_t cmd)
-{
-    return 0;
-}
-
-static int dummy_machine_address_size (struct domain *d, uint32_t cmd)
-{
-    return 0;
-}
-
-static int dummy_hvm_param (struct domain *d, unsigned long op)
-{
-    return 0;
-}
-
-static int dummy_hvm_set_pci_intx_level (struct domain *d)
-{
-    return 0;
-}
-
-static int dummy_hvm_set_isa_irq_level (struct domain *d)
-{
-    return 0;
-}
-
-static int dummy_hvm_set_pci_link_route (struct domain *d)
-{
-    return 0;
-}
-
-static int dummy_hvm_inject_msi (struct domain *d)
-{
-    return 0;
-}
-
-static int dummy_mem_event (struct domain *d)
-{
-    return 0;
-}
-
-static int dummy_mem_sharing (struct domain *d)
-{
-    return 0;
-}
-
-static int dummy_apic (struct domain *d, int cmd)
-{
-    return 0;
-}
-
-static int dummy_xen_settime (void)
-{
-    return 0;
-}
-
-static int dummy_memtype (uint32_t access)
-{
-    return 0;
-}
-
-static int dummy_microcode (void)
-{
-    return 0;
-}
-
-static int dummy_physinfo (void)
-{
-    return 0;
-}
-
-static int dummy_platform_quirk (uint32_t quirk)
-{
-    return 0;
-}
-
-static int dummy_firmware_info (void)
-{
-    return 0;
-}
-
-static int dummy_efi_call(void)
-{
-    return 0;
-}
-
-static int dummy_acpi_sleep (void)
-{
-    return 0;
-}
-
-static int dummy_change_freq (void)
-{
-    return 0;
-}
-
-static int dummy_getidletime (void)
-{
-    return 0;
-}
-
-static int dummy_machine_memory_map (void)
-{
-    return 0;
-}
-
-static int dummy_domain_memory_map (struct domain *d)
-{
-    return 0;
-}
-
-static int dummy_mmu_normal_update (struct domain *d, struct domain *t,
-                                    struct domain *f, intpte_t fpte)
-{
-    return 0;
-}
-
-static int dummy_mmu_machphys_update (struct domain *d, struct domain *f, unsigned long mfn)
-{
-    return 0;
-}
-
-static int dummy_update_va_mapping (struct domain *d, struct domain *f, 
-                                                            l1_pgentry_t pte)
-{
-    return 0;
-}
-
-static int dummy_add_to_physmap (struct domain *d1, struct domain *d2)
-{
-    return 0;
-}
-
-static int dummy_remove_from_physmap (struct domain *d1, struct domain *d2)
-{
-    return 0;
-}
-
-static int dummy_sendtrigger (struct domain *d)
-{
-    return 0;
-}
-
-static int dummy_bind_pt_irq (struct domain *d, struct xen_domctl_bind_pt_irq *bind)
-{
-    return 0;
-}
-
-static int dummy_unbind_pt_irq (struct domain *d, struct xen_domctl_bind_pt_irq *bind)
-{
-    return 0;
-}
-
-static int dummy_pin_mem_cacheattr (struct domain *d)
-{
-    return 0;
-}
-
-static int dummy_ext_vcpucontext (struct domain *d, uint32_t cmd)
-{
-    return 0;
-}
-
-static int dummy_vcpuextstate (struct domain *d, uint32_t cmd)
-{
-    return 0;
-}
-
-static int dummy_ioport_permission (struct domain *d, uint32_t s, uint32_t e, uint8_t allow)
-{
-    return 0;
-}
-
-static int dummy_ioport_mapping (struct domain *d, uint32_t s, uint32_t e, uint8_t allow)
-{
-    return 0;
-}
-#endif
+#define XSM_DEFAULT(type, name) type dummy_ ## name
+#include <xsm/dummy.h>
 
 struct xsm_operations dummy_xsm_ops;
 
diff --git a/xen/xsm/xsm_core.c b/xen/xsm/xsm_core.c
index 96c8669..c4c85c0 100644
--- a/xen/xsm/xsm_core.c
+++ b/xen/xsm/xsm_core.c
@@ -113,7 +113,7 @@ int unregister_xsm(struct xsm_operations *ops)
 
 long do_xsm_op (XEN_GUEST_HANDLE(xsm_op_t) op)
 {
-    return __do_xsm_op(op);
+    return xsm___do_xsm_op(op);
 }
 
 
-- 
1.7.11.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 12 16:21:48 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Sep 2012 16:21:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TBph3-0000tq-7P; Wed, 12 Sep 2012 16:21:37 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andres.lagarcavilla@gmail.com>) id 1TBph0-0000tl-II
	for xen-devel@lists.xen.org; Wed, 12 Sep 2012 16:21:35 +0000
X-Env-Sender: andres.lagarcavilla@gmail.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1347466858!9480483!1
X-Originating-IP: [209.85.161.173]
X-SpamReason: No, hits=2.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,SUBJ_HAS_SPACES,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22393 invoked from network); 12 Sep 2012 16:21:02 -0000
Received: from mail-gg0-f173.google.com (HELO mail-gg0-f173.google.com)
	(209.85.161.173)
	by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Sep 2012 16:21:02 -0000
Received: by ggna5 with SMTP id a5so473589ggn.32
	for <xen-devel@lists.xen.org>; Wed, 12 Sep 2012 09:20:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=subject:mime-version:content-type:from:in-reply-to:date:cc
	:content-transfer-encoding:message-id:references:to:x-mailer;
	bh=rDS0FVJXNO923I1g425JypNKNOkP+Pvp8nUxQ0CDe5Q=;
	b=nGSisBKksjVoYFYosex/3CI8uG3gcTJOYRdU5LIE/3L7GuxBiD/TpK+tKljCZ7HiWj
	8DiHVyo7ScRVngqHFwRZJ3/0OGo9wGaTSSma5OnGG90CQJmPAWrl0rwT9lEH9tI/cc2V
	9qvH89lQ8QVQMdOl/TgH4m5TbaFjFFiMPEm4OkmhXlIyq8rMjvgK42Uk81qBAnxqntrn
	e7xRDFNYteKNNRwXsXfMlN9YLv2PRi/ZovHgSp44ex228LsjdLFGYw6OaSUXNNV72GzO
	TJhxvlOd+qae8yiB1STOV0RI70WJxwJCKm7aPKNgWrpiSqALIBJFaaRa4Ap8XiqdRihA
	zFCA==
Received: by 10.236.197.42 with SMTP id s30mr20662985yhn.64.1347466855113;
	Wed, 12 Sep 2012 09:20:55 -0700 (PDT)
Received: from [192.168.7.212] ([206.223.182.18])
	by mx.google.com with ESMTPS id x4sm36756802yhh.2.2012.09.12.09.20.51
	(version=TLSv1/SSLv3 cipher=OTHER);
	Wed, 12 Sep 2012 09:20:54 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1278)
From: Andres Lagar-Cavilla <andres.lagarcavilla@gmail.com>
In-Reply-To: <mailman.12419.1347465603.1399.xen-devel@lists.xen.org>
Date: Wed, 12 Sep 2012 12:20:52 -0400
Message-Id: <DEEFE8BA-3638-4195-8FFE-057B67A2D2B7@gmail.com>
References: <mailman.12419.1347465603.1399.xen-devel@lists.xen.org>
To: xen-devel@lists.xen.org
X-Mailer: Apple Mail (2.1278)
Cc: Keir Fraser <keir@xen.org>, Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	"Tim \(Xen.org\)" <tim@xen.org>, Jan Beulich <jbeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH 18/22] arch/x86: Add missing mem_sharing
	XSM	 hooks
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> This patch adds splits up the mem_sharing and mem_event XSM hooks to
> better cover what the code is doing. It also completes the support for
> arch-specific domctls in FLASK.
> 
> Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
> Cc: Keir Fraser <keir@xen.org>
> Cc: Jan Beulich <jbeulich@suse.com>
> Cc: Tim Deegan <tim@xen.org>
> ---
> tools/flask/policy/policy/flask/access_vectors |  1 +
> xen/arch/x86/domctl.c                          |  8 ++---
> xen/arch/x86/mm/mem_event.c                    | 45 +++++++++-----------------
> xen/arch/x86/mm/mem_sharing.c                  | 25 +++++++++++---
> xen/include/asm-x86/mem_event.h                |  1 -
> xen/include/xsm/dummy.h                        | 23 ++++++++++++-
> xen/include/xsm/xsm.h                          | 24 ++++++++++++--
> xen/xsm/dummy.c                                |  5 ++-
> xen/xsm/flask/hooks.c                          | 25 ++++++++++++--
> xen/xsm/flask/include/av_perm_to_string.h      |  1 +
> xen/xsm/flask/include/av_permissions.h         |  1 +
> 11 files changed, 113 insertions(+), 46 deletions(-)
> 
> diff --git a/tools/flask/policy/policy/flask/access_vectors b/tools/flask/policy/policy/flask/access_vectors
> index ea65e45..45ac437 100644
> --- a/tools/flask/policy/policy/flask/access_vectors
> +++ b/tools/flask/policy/policy/flask/access_vectors
> @@ -102,6 +102,7 @@ class hvm
>     mem_sharing
>     audit_p2m
>     send_irq
> +    share_mem
> }
> 
> class event
> diff --git a/xen/arch/x86/domctl.c b/xen/arch/x86/domctl.c
> index a0ecd95..4a188e5 100644
> --- a/xen/arch/x86/domctl.c
> +++ b/xen/arch/x86/domctl.c
> @@ -1449,10 +1449,8 @@ long arch_do_domctl(
>         d = rcu_lock_domain_by_id(domctl->domain);
>         if ( d != NULL )
>         {
> -            ret = xsm_mem_event(d);
> -            if ( !ret )
> -                ret = mem_event_domctl(d, &domctl->u.mem_event_op,
> -                                       guest_handle_cast(u_domctl, void));
> +            ret = mem_event_domctl(d, &domctl->u.mem_event_op,
> +                                   guest_handle_cast(u_domctl, void));
>             rcu_unlock_domain(d);
>             copy_to_guest(u_domctl, domctl, 1);
>         } 
> @@ -1508,7 +1506,7 @@ long arch_do_domctl(
>         d = rcu_lock_domain_by_id(domctl->domain);
>         if ( d != NULL )
>         {
> -            ret = xsm_mem_event(d);
> +            ret = xsm_mem_event_setup(d);
>             if ( !ret ) {
>                 p2m = p2m_get_hostp2m(d);
>                 p2m->access_required = domctl->u.access_required.access_required;
> diff --git a/xen/arch/x86/mm/mem_event.c b/xen/arch/x86/mm/mem_event.c
> index d728889..d574541 100644
> --- a/xen/arch/x86/mm/mem_event.c
> +++ b/xen/arch/x86/mm/mem_event.c
> @@ -29,6 +29,7 @@
> #include <asm/mem_paging.h>
> #include <asm/mem_access.h>
> #include <asm/mem_sharing.h>
> +#include <xsm/xsm.h>
> 
> /* for public/io/ring.h macros */
> #define xen_mb()   mb()
> @@ -439,34 +440,22 @@ static void mem_sharing_notification(struct vcpu *v, unsigned int port)
>         mem_sharing_sharing_resume(v->domain);
> }
> 
> -struct domain *get_mem_event_op_target(uint32_t domain, int *rc)
> -{
> -    struct domain *d;
> -
> -    /* Get the target domain */
> -    *rc = rcu_lock_remote_target_domain_by_id(domain, &d);
> -    if ( *rc != 0 )
> -        return NULL;
> -
> -    /* Not dying? */
> -    if ( d->is_dying )
> -    {
> -        rcu_unlock_domain(d);
> -        *rc = -EINVAL;
> -        return NULL;
> -    }
> -    
> -    return d;
> -}
> -
> int do_mem_event_op(int op, uint32_t domain, void *arg)
> {
>     int ret;
>     struct domain *d;
> 
This hunk and the two hunks below in men_sharing share a lot of common code. Can we refactor a bit? Proposal (I don't really care about the exact function naming or prototype but I do care about duplicate code):

static inline int struct domain *get_mem_event_op_target(uint32_t domain, int *rc)
{
    struct domain *d = rcu_lock_domain_by_any_id(domain);
    if ( !d ) {
          *rc = -ESRCH;
           return d;
    }

    *rc = -EINVAL;
    if ( d->is_dying || d == current->domain ) {
          rcu_unlock_domain(d);
          return NULL;
     }

    *rc = 0;
    return d;
}

Then in do_mem_event_op
       d = get_mem_event_op_target(domain, &ret)
       if (!d) return ret;

       ret = xsm_mem_event_op(d, op);

And then in men_sharing_c.

static inline struct domain * get_mem_sharing_target(uint32_t domain, int *rc)
{
    struct domain *d = get_mem_event_op_target(domain, rc)
    if (!d) return NULL;

    if (!mem_sharing_enabled(d))
    {
         *rc = -EINVAL;
          rcu_unlock_domain(d);
          return NULL;
    }

    *rc = xsm_mem_sharing_op(d, op)
    if (*rc)
    {
          rcu_unlock_domain(d);
          return NULL;
    }

    return d;
}

And you can call get_mem_sharing_target in the two spots where you have code duplication.

> -    d = get_mem_event_op_target(domain, &ret);
> +    d = rcu_lock_domain_by_any_id(domain);
>     if ( !d )
> -        return ret;
> +        return -ESRCH;
> +
> +    ret = -EINVAL;
> +    if ( d->is_dying || d == current->domain )
> +        goto out;
> +
> +    ret = xsm_mem_event_op(d, op);
> +    if ( ret )
> +        goto out;
> 
>     switch (op)
>     {
> @@ -483,6 +472,7 @@ int do_mem_event_op(int op, uint32_t domain, void *arg)
>             ret = -ENOSYS;
>     }
> 
> + out:
>     rcu_unlock_domain(d);
>     return ret;
> }
> @@ -516,6 +506,10 @@ int mem_event_domctl(struct domain *d, xen_domctl_mem_event_op_t *mec,
> {
>     int rc;
> 
> +    rc = xsm_mem_event_control(d, mec->mode, mec->op);
> +    if ( rc )
> +        return rc;
> +
>     if ( unlikely(d == current->domain) )
>     {
>         gdprintk(XENLOG_INFO, "Tried to do a memory event op on itself.\n");
> @@ -537,13 +531,6 @@ int mem_event_domctl(struct domain *d, xen_domctl_mem_event_op_t *mec,
>         return -EINVAL;
>     }
> 
> -    /* TODO: XSM hook */
> -#if 0
> -    rc = xsm_mem_event_control(d, mec->op);
> -    if ( rc )
> -        return rc;
> -#endif
> -
>     rc = -ENOSYS;
> 
>     switch ( mec->mode )
> diff --git a/xen/arch/x86/mm/mem_sharing.c b/xen/arch/x86/mm/mem_sharing.c
> index 5103285..eff8ae5 100644
> --- a/xen/arch/x86/mm/mem_sharing.c
> +++ b/xen/arch/x86/mm/mem_sharing.c
> @@ -34,6 +34,7 @@
> #include <asm/atomic.h>
> #include <xen/rcupdate.h>
> #include <asm/event.h>
> +#include <xsm/xsm.h>
> 
> #include "mm-locks.h"
> 
> @@ -1345,11 +1346,19 @@ int mem_sharing_memop(struct domain *d, xen_mem_sharing_op_t *mec)
>             if ( !mem_sharing_enabled(d) )
>                 return -EINVAL;
> 
Even if there is a good reason to not go for my suggestion above, there is an obvious chance to refactor the code duplication below.

Thanks!
Andres

> -            cd = get_mem_event_op_target(mec->u.share.client_domain, &rc);
> +            cd = rcu_lock_domain_by_any_id(mec->u.share.client_domain);
>             if ( !cd )
> +                return -ESRCH;
> +
> +            rc = xsm_mem_sharing_op(d, cd, mec->op);
> +            if ( rc )
> +            {
> +                rcu_unlock_domain(cd);
>                 return rc;
> +            }
> 
> -            if ( !mem_sharing_enabled(cd) )
> +            if ( cd == current->domain || cd->is_dying ||
> +                 !mem_sharing_enabled(cd) )
>             {
>                 rcu_unlock_domain(cd);
>                 return -EINVAL;
> @@ -1401,11 +1410,19 @@ int mem_sharing_memop(struct domain *d, xen_mem_sharing_op_t *mec)
>             if ( !mem_sharing_enabled(d) )
>                 return -EINVAL;
> 
> -            cd = get_mem_event_op_target(mec->u.share.client_domain, &rc);
> +            cd = rcu_lock_domain_by_any_id(mec->u.share.client_domain);
>             if ( !cd )
> +                return -ESRCH;
> +
> +            rc = xsm_mem_sharing_op(d, cd, mec->op);
> +            if ( rc )
> +            {
> +                rcu_unlock_domain(cd);
>                 return rc;
> +            }
> 
> -            if ( !mem_sharing_enabled(cd) )
> +            if ( cd == current->domain || cd->is_dying ||
> +                 !mem_sharing_enabled(cd) )
>             {
>                 rcu_unlock_domain(cd);
>                 return -EINVAL;
> diff --git a/xen/include/asm-x86/mem_event.h b/xen/include/asm-x86/mem_event.h
> index 23d71c1..448be4f 100644
> --- a/xen/include/asm-x86/mem_event.h
> +++ b/xen/include/asm-x86/mem_event.h
> @@ -62,7 +62,6 @@ void mem_event_put_request(struct domain *d, struct mem_event_domain *med,
> int mem_event_get_response(struct domain *d, struct mem_event_domain *med,
>                            mem_event_response_t *rsp);
> 
> -struct domain *get_mem_event_op_target(uint32_t domain, int *rc);
> int do_mem_event_op(int op, uint32_t domain, void *arg);
> int mem_event_domctl(struct domain *d, xen_domctl_mem_event_op_t *mec,
>                      XEN_GUEST_HANDLE(void) u_domctl);
> diff --git a/xen/include/xsm/dummy.h b/xen/include/xsm/dummy.h
> index a9784f5..1760cd9 100644
> --- a/xen/include/xsm/dummy.h
> +++ b/xen/include/xsm/dummy.h
> @@ -551,16 +551,37 @@ static XSM_DEFAULT(int, hvm_inject_msi) (struct domain *d)
>     return 0;
> }
> 
> -static XSM_DEFAULT(int, mem_event) (struct domain *d)
> +static XSM_DEFAULT(int, mem_event_setup) (struct domain *d)
> {
>     return 0;
> }
> 
> +static XSM_DEFAULT(int, mem_event_control) (struct domain *d, int mode, int op)
> +{
> +    if ( !IS_PRIV(current->domain) )
> +        return -EPERM;
> +    return 0;
> +}
> +
> +static XSM_DEFAULT(int, mem_event_op) (struct domain *d, int op)
> +{
> +    if ( !IS_PRIV_FOR(current->domain, d) )
> +        return -EPERM;
> +    return 0;
> +}
> +
> static XSM_DEFAULT(int, mem_sharing) (struct domain *d)
> {
>     return 0;
> }
> 
> +static XSM_DEFAULT(int, mem_sharing_op) (struct domain *d, struct domain *cd, int op)
> +{
> +    if ( !IS_PRIV_FOR(current->domain, cd) )
> +        return -EPERM;
> +    return 0;
> +}
> +
> static XSM_DEFAULT(int, apic) (struct domain *d, int cmd)
> {
>     if ( !IS_PRIV(d) )
> diff --git a/xen/include/xsm/xsm.h b/xen/include/xsm/xsm.h
> index ef3329f..c2c1efa 100644
> --- a/xen/include/xsm/xsm.h
> +++ b/xen/include/xsm/xsm.h
> @@ -151,8 +151,11 @@ struct xsm_operations {
>     int (*hvm_set_isa_irq_level) (struct domain *d);
>     int (*hvm_set_pci_link_route) (struct domain *d);
>     int (*hvm_inject_msi) (struct domain *d);
> -    int (*mem_event) (struct domain *d);
> +    int (*mem_event_setup) (struct domain *d);
> +    int (*mem_event_control) (struct domain *d, int mode, int op);
> +    int (*mem_event_op) (struct domain *d, int op);
>     int (*mem_sharing) (struct domain *d);
> +    int (*mem_sharing_op) (struct domain *d, struct domain *cd, int op);
>     int (*apic) (struct domain *d, int cmd);
>     int (*xen_settime) (void);
>     int (*memtype) (uint32_t access);
> @@ -663,9 +666,19 @@ static inline int xsm_hvm_inject_msi (struct domain *d)
>     return xsm_ops->hvm_inject_msi(d);
> }
> 
> -static inline int xsm_mem_event (struct domain *d)
> +static inline int xsm_mem_event_setup (struct domain *d)
> {
> -    return xsm_ops->mem_event(d);
> +    return xsm_ops->mem_event_setup(d);
> +}
> +
> +static inline int xsm_mem_event_control (struct domain *d, int mode, int op)
> +{
> +    return xsm_ops->mem_event_control(d, mode, op);
> +}
> +
> +static inline int xsm_mem_event_op (struct domain *d, int op)
> +{
> +    return xsm_ops->mem_event_op(d, op);
> }
> 
> static inline int xsm_mem_sharing (struct domain *d)
> @@ -673,6 +686,11 @@ static inline int xsm_mem_sharing (struct domain *d)
>     return xsm_ops->mem_sharing(d);
> }
> 
> +static inline int xsm_mem_sharing_op (struct domain *d, struct domain *cd, int op)
> +{
> +    return xsm_ops->mem_sharing_op(d, cd, op);
> +}
> +
> static inline int xsm_apic (struct domain *d, int cmd)
> {
>     return xsm_ops->apic(d, cmd);
> diff --git a/xen/xsm/dummy.c b/xen/xsm/dummy.c
> index c76212d..c82c464 100644
> --- a/xen/xsm/dummy.c
> +++ b/xen/xsm/dummy.c
> @@ -135,8 +135,11 @@ void xsm_fixup_ops (struct xsm_operations *ops)
>     set_to_dummy_if_null(ops, hvm_set_isa_irq_level);
>     set_to_dummy_if_null(ops, hvm_set_pci_link_route);
>     set_to_dummy_if_null(ops, hvm_inject_msi);
> -    set_to_dummy_if_null(ops, mem_event);
> +    set_to_dummy_if_null(ops, mem_event_setup);
> +    set_to_dummy_if_null(ops, mem_event_control);
> +    set_to_dummy_if_null(ops, mem_event_op);
>     set_to_dummy_if_null(ops, mem_sharing);
> +    set_to_dummy_if_null(ops, mem_sharing_op);
>     set_to_dummy_if_null(ops, apic);
>     set_to_dummy_if_null(ops, xen_settime);
>     set_to_dummy_if_null(ops, memtype);
> diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
> index 421087f..f993696 100644
> --- a/xen/xsm/flask/hooks.c
> +++ b/xen/xsm/flask/hooks.c
> @@ -1275,7 +1275,17 @@ static int flask_hvm_inject_msi(struct domain *d)
>     return current_has_perm(d, SECCLASS_HVM, HVM__SEND_IRQ);
> }
> 
> -static int flask_mem_event(struct domain *d)
> +static int flask_mem_event_setup(struct domain *d)
> +{
> +    return current_has_perm(d, SECCLASS_HVM, HVM__MEM_EVENT);
> +}
> +
> +static int flask_mem_event_control(struct domain *d, int mode, int op)
> +{
> +    return current_has_perm(d, SECCLASS_HVM, HVM__MEM_EVENT);
> +}
> +
> +static int flask_mem_event_op(struct domain *d, int op)
> {
>     return current_has_perm(d, SECCLASS_HVM, HVM__MEM_EVENT);
> }
> @@ -1285,6 +1295,14 @@ static int flask_mem_sharing(struct domain *d)
>     return current_has_perm(d, SECCLASS_HVM, HVM__MEM_SHARING);
> }
> 
> +static int flask_mem_sharing_op(struct domain *d, struct domain *cd, int op)
> +{
> +    int rc = current_has_perm(cd, SECCLASS_HVM, HVM__MEM_SHARING);
> +    if ( rc )
> +        return rc;
> +    return domain_has_perm(d, cd, SECCLASS_HVM, HVM__SHARE_MEM);
> +}
> +
> static int flask_apic(struct domain *d, int cmd)
> {
>     u32 perm;
> @@ -1734,8 +1752,11 @@ static struct xsm_operations flask_ops = {
>     .hvm_set_isa_irq_level = flask_hvm_set_isa_irq_level,
>     .hvm_set_pci_link_route = flask_hvm_set_pci_link_route,
>     .hvm_inject_msi = flask_hvm_inject_msi,
> -    .mem_event = flask_mem_event,
> +    .mem_event_setup = flask_mem_event_setup,
> +    .mem_event_control = flask_mem_event_control,
> +    .mem_event_op = flask_mem_event_op,
>     .mem_sharing = flask_mem_sharing,
> +    .mem_sharing_op = flask_mem_sharing_op,
>     .apic = flask_apic,
>     .xen_settime = flask_xen_settime,
>     .memtype = flask_memtype,
> diff --git a/xen/xsm/flask/include/av_perm_to_string.h b/xen/xsm/flask/include/av_perm_to_string.h
> index 894910c..186f1fa 100644
> --- a/xen/xsm/flask/include/av_perm_to_string.h
> +++ b/xen/xsm/flask/include/av_perm_to_string.h
> @@ -84,6 +84,7 @@
>    S_(SECCLASS_HVM, HVM__MEM_SHARING, "mem_sharing")
>    S_(SECCLASS_HVM, HVM__AUDIT_P2M, "audit_p2m")
>    S_(SECCLASS_HVM, HVM__SEND_IRQ, "send_irq")
> +   S_(SECCLASS_HVM, HVM__SHARE_MEM, "share_mem")
>    S_(SECCLASS_EVENT, EVENT__BIND, "bind")
>    S_(SECCLASS_EVENT, EVENT__SEND, "send")
>    S_(SECCLASS_EVENT, EVENT__STATUS, "status")
> diff --git a/xen/xsm/flask/include/av_permissions.h b/xen/xsm/flask/include/av_permissions.h
> index 1bdb515..b3831f6 100644
> --- a/xen/xsm/flask/include/av_permissions.h
> +++ b/xen/xsm/flask/include/av_permissions.h
> @@ -87,6 +87,7 @@
> #define HVM__MEM_SHARING                          0x00001000UL
> #define HVM__AUDIT_P2M                            0x00002000UL
> #define HVM__SEND_IRQ                             0x00004000UL
> +#define HVM__SHARE_MEM                            0x00008000UL
> 
> #define EVENT__BIND                               0x00000001UL
> #define EVENT__SEND                               0x00000002UL
> -- 
> 1.7.11.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 12 16:21:48 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Sep 2012 16:21:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TBph3-0000tq-7P; Wed, 12 Sep 2012 16:21:37 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andres.lagarcavilla@gmail.com>) id 1TBph0-0000tl-II
	for xen-devel@lists.xen.org; Wed, 12 Sep 2012 16:21:35 +0000
X-Env-Sender: andres.lagarcavilla@gmail.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1347466858!9480483!1
X-Originating-IP: [209.85.161.173]
X-SpamReason: No, hits=2.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,SUBJ_HAS_SPACES,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22393 invoked from network); 12 Sep 2012 16:21:02 -0000
Received: from mail-gg0-f173.google.com (HELO mail-gg0-f173.google.com)
	(209.85.161.173)
	by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Sep 2012 16:21:02 -0000
Received: by ggna5 with SMTP id a5so473589ggn.32
	for <xen-devel@lists.xen.org>; Wed, 12 Sep 2012 09:20:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=subject:mime-version:content-type:from:in-reply-to:date:cc
	:content-transfer-encoding:message-id:references:to:x-mailer;
	bh=rDS0FVJXNO923I1g425JypNKNOkP+Pvp8nUxQ0CDe5Q=;
	b=nGSisBKksjVoYFYosex/3CI8uG3gcTJOYRdU5LIE/3L7GuxBiD/TpK+tKljCZ7HiWj
	8DiHVyo7ScRVngqHFwRZJ3/0OGo9wGaTSSma5OnGG90CQJmPAWrl0rwT9lEH9tI/cc2V
	9qvH89lQ8QVQMdOl/TgH4m5TbaFjFFiMPEm4OkmhXlIyq8rMjvgK42Uk81qBAnxqntrn
	e7xRDFNYteKNNRwXsXfMlN9YLv2PRi/ZovHgSp44ex228LsjdLFGYw6OaSUXNNV72GzO
	TJhxvlOd+qae8yiB1STOV0RI70WJxwJCKm7aPKNgWrpiSqALIBJFaaRa4Ap8XiqdRihA
	zFCA==
Received: by 10.236.197.42 with SMTP id s30mr20662985yhn.64.1347466855113;
	Wed, 12 Sep 2012 09:20:55 -0700 (PDT)
Received: from [192.168.7.212] ([206.223.182.18])
	by mx.google.com with ESMTPS id x4sm36756802yhh.2.2012.09.12.09.20.51
	(version=TLSv1/SSLv3 cipher=OTHER);
	Wed, 12 Sep 2012 09:20:54 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1278)
From: Andres Lagar-Cavilla <andres.lagarcavilla@gmail.com>
In-Reply-To: <mailman.12419.1347465603.1399.xen-devel@lists.xen.org>
Date: Wed, 12 Sep 2012 12:20:52 -0400
Message-Id: <DEEFE8BA-3638-4195-8FFE-057B67A2D2B7@gmail.com>
References: <mailman.12419.1347465603.1399.xen-devel@lists.xen.org>
To: xen-devel@lists.xen.org
X-Mailer: Apple Mail (2.1278)
Cc: Keir Fraser <keir@xen.org>, Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	"Tim \(Xen.org\)" <tim@xen.org>, Jan Beulich <jbeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH 18/22] arch/x86: Add missing mem_sharing
	XSM	 hooks
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> This patch adds splits up the mem_sharing and mem_event XSM hooks to
> better cover what the code is doing. It also completes the support for
> arch-specific domctls in FLASK.
> 
> Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
> Cc: Keir Fraser <keir@xen.org>
> Cc: Jan Beulich <jbeulich@suse.com>
> Cc: Tim Deegan <tim@xen.org>
> ---
> tools/flask/policy/policy/flask/access_vectors |  1 +
> xen/arch/x86/domctl.c                          |  8 ++---
> xen/arch/x86/mm/mem_event.c                    | 45 +++++++++-----------------
> xen/arch/x86/mm/mem_sharing.c                  | 25 +++++++++++---
> xen/include/asm-x86/mem_event.h                |  1 -
> xen/include/xsm/dummy.h                        | 23 ++++++++++++-
> xen/include/xsm/xsm.h                          | 24 ++++++++++++--
> xen/xsm/dummy.c                                |  5 ++-
> xen/xsm/flask/hooks.c                          | 25 ++++++++++++--
> xen/xsm/flask/include/av_perm_to_string.h      |  1 +
> xen/xsm/flask/include/av_permissions.h         |  1 +
> 11 files changed, 113 insertions(+), 46 deletions(-)
> 
> diff --git a/tools/flask/policy/policy/flask/access_vectors b/tools/flask/policy/policy/flask/access_vectors
> index ea65e45..45ac437 100644
> --- a/tools/flask/policy/policy/flask/access_vectors
> +++ b/tools/flask/policy/policy/flask/access_vectors
> @@ -102,6 +102,7 @@ class hvm
>     mem_sharing
>     audit_p2m
>     send_irq
> +    share_mem
> }
> 
> class event
> diff --git a/xen/arch/x86/domctl.c b/xen/arch/x86/domctl.c
> index a0ecd95..4a188e5 100644
> --- a/xen/arch/x86/domctl.c
> +++ b/xen/arch/x86/domctl.c
> @@ -1449,10 +1449,8 @@ long arch_do_domctl(
>         d = rcu_lock_domain_by_id(domctl->domain);
>         if ( d != NULL )
>         {
> -            ret = xsm_mem_event(d);
> -            if ( !ret )
> -                ret = mem_event_domctl(d, &domctl->u.mem_event_op,
> -                                       guest_handle_cast(u_domctl, void));
> +            ret = mem_event_domctl(d, &domctl->u.mem_event_op,
> +                                   guest_handle_cast(u_domctl, void));
>             rcu_unlock_domain(d);
>             copy_to_guest(u_domctl, domctl, 1);
>         } 
> @@ -1508,7 +1506,7 @@ long arch_do_domctl(
>         d = rcu_lock_domain_by_id(domctl->domain);
>         if ( d != NULL )
>         {
> -            ret = xsm_mem_event(d);
> +            ret = xsm_mem_event_setup(d);
>             if ( !ret ) {
>                 p2m = p2m_get_hostp2m(d);
>                 p2m->access_required = domctl->u.access_required.access_required;
> diff --git a/xen/arch/x86/mm/mem_event.c b/xen/arch/x86/mm/mem_event.c
> index d728889..d574541 100644
> --- a/xen/arch/x86/mm/mem_event.c
> +++ b/xen/arch/x86/mm/mem_event.c
> @@ -29,6 +29,7 @@
> #include <asm/mem_paging.h>
> #include <asm/mem_access.h>
> #include <asm/mem_sharing.h>
> +#include <xsm/xsm.h>
> 
> /* for public/io/ring.h macros */
> #define xen_mb()   mb()
> @@ -439,34 +440,22 @@ static void mem_sharing_notification(struct vcpu *v, unsigned int port)
>         mem_sharing_sharing_resume(v->domain);
> }
> 
> -struct domain *get_mem_event_op_target(uint32_t domain, int *rc)
> -{
> -    struct domain *d;
> -
> -    /* Get the target domain */
> -    *rc = rcu_lock_remote_target_domain_by_id(domain, &d);
> -    if ( *rc != 0 )
> -        return NULL;
> -
> -    /* Not dying? */
> -    if ( d->is_dying )
> -    {
> -        rcu_unlock_domain(d);
> -        *rc = -EINVAL;
> -        return NULL;
> -    }
> -    
> -    return d;
> -}
> -
> int do_mem_event_op(int op, uint32_t domain, void *arg)
> {
>     int ret;
>     struct domain *d;
> 
This hunk and the two hunks below in men_sharing share a lot of common code. Can we refactor a bit? Proposal (I don't really care about the exact function naming or prototype but I do care about duplicate code):

static inline int struct domain *get_mem_event_op_target(uint32_t domain, int *rc)
{
    struct domain *d = rcu_lock_domain_by_any_id(domain);
    if ( !d ) {
          *rc = -ESRCH;
           return d;
    }

    *rc = -EINVAL;
    if ( d->is_dying || d == current->domain ) {
          rcu_unlock_domain(d);
          return NULL;
     }

    *rc = 0;
    return d;
}

Then in do_mem_event_op
       d = get_mem_event_op_target(domain, &ret)
       if (!d) return ret;

       ret = xsm_mem_event_op(d, op);

And then in men_sharing_c.

static inline struct domain * get_mem_sharing_target(uint32_t domain, int *rc)
{
    struct domain *d = get_mem_event_op_target(domain, rc)
    if (!d) return NULL;

    if (!mem_sharing_enabled(d))
    {
         *rc = -EINVAL;
          rcu_unlock_domain(d);
          return NULL;
    }

    *rc = xsm_mem_sharing_op(d, op)
    if (*rc)
    {
          rcu_unlock_domain(d);
          return NULL;
    }

    return d;
}

And you can call get_mem_sharing_target in the two spots where you have code duplication.

> -    d = get_mem_event_op_target(domain, &ret);
> +    d = rcu_lock_domain_by_any_id(domain);
>     if ( !d )
> -        return ret;
> +        return -ESRCH;
> +
> +    ret = -EINVAL;
> +    if ( d->is_dying || d == current->domain )
> +        goto out;
> +
> +    ret = xsm_mem_event_op(d, op);
> +    if ( ret )
> +        goto out;
> 
>     switch (op)
>     {
> @@ -483,6 +472,7 @@ int do_mem_event_op(int op, uint32_t domain, void *arg)
>             ret = -ENOSYS;
>     }
> 
> + out:
>     rcu_unlock_domain(d);
>     return ret;
> }
> @@ -516,6 +506,10 @@ int mem_event_domctl(struct domain *d, xen_domctl_mem_event_op_t *mec,
> {
>     int rc;
> 
> +    rc = xsm_mem_event_control(d, mec->mode, mec->op);
> +    if ( rc )
> +        return rc;
> +
>     if ( unlikely(d == current->domain) )
>     {
>         gdprintk(XENLOG_INFO, "Tried to do a memory event op on itself.\n");
> @@ -537,13 +531,6 @@ int mem_event_domctl(struct domain *d, xen_domctl_mem_event_op_t *mec,
>         return -EINVAL;
>     }
> 
> -    /* TODO: XSM hook */
> -#if 0
> -    rc = xsm_mem_event_control(d, mec->op);
> -    if ( rc )
> -        return rc;
> -#endif
> -
>     rc = -ENOSYS;
> 
>     switch ( mec->mode )
> diff --git a/xen/arch/x86/mm/mem_sharing.c b/xen/arch/x86/mm/mem_sharing.c
> index 5103285..eff8ae5 100644
> --- a/xen/arch/x86/mm/mem_sharing.c
> +++ b/xen/arch/x86/mm/mem_sharing.c
> @@ -34,6 +34,7 @@
> #include <asm/atomic.h>
> #include <xen/rcupdate.h>
> #include <asm/event.h>
> +#include <xsm/xsm.h>
> 
> #include "mm-locks.h"
> 
> @@ -1345,11 +1346,19 @@ int mem_sharing_memop(struct domain *d, xen_mem_sharing_op_t *mec)
>             if ( !mem_sharing_enabled(d) )
>                 return -EINVAL;
> 
Even if there is a good reason to not go for my suggestion above, there is an obvious chance to refactor the code duplication below.

Thanks!
Andres

> -            cd = get_mem_event_op_target(mec->u.share.client_domain, &rc);
> +            cd = rcu_lock_domain_by_any_id(mec->u.share.client_domain);
>             if ( !cd )
> +                return -ESRCH;
> +
> +            rc = xsm_mem_sharing_op(d, cd, mec->op);
> +            if ( rc )
> +            {
> +                rcu_unlock_domain(cd);
>                 return rc;
> +            }
> 
> -            if ( !mem_sharing_enabled(cd) )
> +            if ( cd == current->domain || cd->is_dying ||
> +                 !mem_sharing_enabled(cd) )
>             {
>                 rcu_unlock_domain(cd);
>                 return -EINVAL;
> @@ -1401,11 +1410,19 @@ int mem_sharing_memop(struct domain *d, xen_mem_sharing_op_t *mec)
>             if ( !mem_sharing_enabled(d) )
>                 return -EINVAL;
> 
> -            cd = get_mem_event_op_target(mec->u.share.client_domain, &rc);
> +            cd = rcu_lock_domain_by_any_id(mec->u.share.client_domain);
>             if ( !cd )
> +                return -ESRCH;
> +
> +            rc = xsm_mem_sharing_op(d, cd, mec->op);
> +            if ( rc )
> +            {
> +                rcu_unlock_domain(cd);
>                 return rc;
> +            }
> 
> -            if ( !mem_sharing_enabled(cd) )
> +            if ( cd == current->domain || cd->is_dying ||
> +                 !mem_sharing_enabled(cd) )
>             {
>                 rcu_unlock_domain(cd);
>                 return -EINVAL;
> diff --git a/xen/include/asm-x86/mem_event.h b/xen/include/asm-x86/mem_event.h
> index 23d71c1..448be4f 100644
> --- a/xen/include/asm-x86/mem_event.h
> +++ b/xen/include/asm-x86/mem_event.h
> @@ -62,7 +62,6 @@ void mem_event_put_request(struct domain *d, struct mem_event_domain *med,
> int mem_event_get_response(struct domain *d, struct mem_event_domain *med,
>                            mem_event_response_t *rsp);
> 
> -struct domain *get_mem_event_op_target(uint32_t domain, int *rc);
> int do_mem_event_op(int op, uint32_t domain, void *arg);
> int mem_event_domctl(struct domain *d, xen_domctl_mem_event_op_t *mec,
>                      XEN_GUEST_HANDLE(void) u_domctl);
> diff --git a/xen/include/xsm/dummy.h b/xen/include/xsm/dummy.h
> index a9784f5..1760cd9 100644
> --- a/xen/include/xsm/dummy.h
> +++ b/xen/include/xsm/dummy.h
> @@ -551,16 +551,37 @@ static XSM_DEFAULT(int, hvm_inject_msi) (struct domain *d)
>     return 0;
> }
> 
> -static XSM_DEFAULT(int, mem_event) (struct domain *d)
> +static XSM_DEFAULT(int, mem_event_setup) (struct domain *d)
> {
>     return 0;
> }
> 
> +static XSM_DEFAULT(int, mem_event_control) (struct domain *d, int mode, int op)
> +{
> +    if ( !IS_PRIV(current->domain) )
> +        return -EPERM;
> +    return 0;
> +}
> +
> +static XSM_DEFAULT(int, mem_event_op) (struct domain *d, int op)
> +{
> +    if ( !IS_PRIV_FOR(current->domain, d) )
> +        return -EPERM;
> +    return 0;
> +}
> +
> static XSM_DEFAULT(int, mem_sharing) (struct domain *d)
> {
>     return 0;
> }
> 
> +static XSM_DEFAULT(int, mem_sharing_op) (struct domain *d, struct domain *cd, int op)
> +{
> +    if ( !IS_PRIV_FOR(current->domain, cd) )
> +        return -EPERM;
> +    return 0;
> +}
> +
> static XSM_DEFAULT(int, apic) (struct domain *d, int cmd)
> {
>     if ( !IS_PRIV(d) )
> diff --git a/xen/include/xsm/xsm.h b/xen/include/xsm/xsm.h
> index ef3329f..c2c1efa 100644
> --- a/xen/include/xsm/xsm.h
> +++ b/xen/include/xsm/xsm.h
> @@ -151,8 +151,11 @@ struct xsm_operations {
>     int (*hvm_set_isa_irq_level) (struct domain *d);
>     int (*hvm_set_pci_link_route) (struct domain *d);
>     int (*hvm_inject_msi) (struct domain *d);
> -    int (*mem_event) (struct domain *d);
> +    int (*mem_event_setup) (struct domain *d);
> +    int (*mem_event_control) (struct domain *d, int mode, int op);
> +    int (*mem_event_op) (struct domain *d, int op);
>     int (*mem_sharing) (struct domain *d);
> +    int (*mem_sharing_op) (struct domain *d, struct domain *cd, int op);
>     int (*apic) (struct domain *d, int cmd);
>     int (*xen_settime) (void);
>     int (*memtype) (uint32_t access);
> @@ -663,9 +666,19 @@ static inline int xsm_hvm_inject_msi (struct domain *d)
>     return xsm_ops->hvm_inject_msi(d);
> }
> 
> -static inline int xsm_mem_event (struct domain *d)
> +static inline int xsm_mem_event_setup (struct domain *d)
> {
> -    return xsm_ops->mem_event(d);
> +    return xsm_ops->mem_event_setup(d);
> +}
> +
> +static inline int xsm_mem_event_control (struct domain *d, int mode, int op)
> +{
> +    return xsm_ops->mem_event_control(d, mode, op);
> +}
> +
> +static inline int xsm_mem_event_op (struct domain *d, int op)
> +{
> +    return xsm_ops->mem_event_op(d, op);
> }
> 
> static inline int xsm_mem_sharing (struct domain *d)
> @@ -673,6 +686,11 @@ static inline int xsm_mem_sharing (struct domain *d)
>     return xsm_ops->mem_sharing(d);
> }
> 
> +static inline int xsm_mem_sharing_op (struct domain *d, struct domain *cd, int op)
> +{
> +    return xsm_ops->mem_sharing_op(d, cd, op);
> +}
> +
> static inline int xsm_apic (struct domain *d, int cmd)
> {
>     return xsm_ops->apic(d, cmd);
> diff --git a/xen/xsm/dummy.c b/xen/xsm/dummy.c
> index c76212d..c82c464 100644
> --- a/xen/xsm/dummy.c
> +++ b/xen/xsm/dummy.c
> @@ -135,8 +135,11 @@ void xsm_fixup_ops (struct xsm_operations *ops)
>     set_to_dummy_if_null(ops, hvm_set_isa_irq_level);
>     set_to_dummy_if_null(ops, hvm_set_pci_link_route);
>     set_to_dummy_if_null(ops, hvm_inject_msi);
> -    set_to_dummy_if_null(ops, mem_event);
> +    set_to_dummy_if_null(ops, mem_event_setup);
> +    set_to_dummy_if_null(ops, mem_event_control);
> +    set_to_dummy_if_null(ops, mem_event_op);
>     set_to_dummy_if_null(ops, mem_sharing);
> +    set_to_dummy_if_null(ops, mem_sharing_op);
>     set_to_dummy_if_null(ops, apic);
>     set_to_dummy_if_null(ops, xen_settime);
>     set_to_dummy_if_null(ops, memtype);
> diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
> index 421087f..f993696 100644
> --- a/xen/xsm/flask/hooks.c
> +++ b/xen/xsm/flask/hooks.c
> @@ -1275,7 +1275,17 @@ static int flask_hvm_inject_msi(struct domain *d)
>     return current_has_perm(d, SECCLASS_HVM, HVM__SEND_IRQ);
> }
> 
> -static int flask_mem_event(struct domain *d)
> +static int flask_mem_event_setup(struct domain *d)
> +{
> +    return current_has_perm(d, SECCLASS_HVM, HVM__MEM_EVENT);
> +}
> +
> +static int flask_mem_event_control(struct domain *d, int mode, int op)
> +{
> +    return current_has_perm(d, SECCLASS_HVM, HVM__MEM_EVENT);
> +}
> +
> +static int flask_mem_event_op(struct domain *d, int op)
> {
>     return current_has_perm(d, SECCLASS_HVM, HVM__MEM_EVENT);
> }
> @@ -1285,6 +1295,14 @@ static int flask_mem_sharing(struct domain *d)
>     return current_has_perm(d, SECCLASS_HVM, HVM__MEM_SHARING);
> }
> 
> +static int flask_mem_sharing_op(struct domain *d, struct domain *cd, int op)
> +{
> +    int rc = current_has_perm(cd, SECCLASS_HVM, HVM__MEM_SHARING);
> +    if ( rc )
> +        return rc;
> +    return domain_has_perm(d, cd, SECCLASS_HVM, HVM__SHARE_MEM);
> +}
> +
> static int flask_apic(struct domain *d, int cmd)
> {
>     u32 perm;
> @@ -1734,8 +1752,11 @@ static struct xsm_operations flask_ops = {
>     .hvm_set_isa_irq_level = flask_hvm_set_isa_irq_level,
>     .hvm_set_pci_link_route = flask_hvm_set_pci_link_route,
>     .hvm_inject_msi = flask_hvm_inject_msi,
> -    .mem_event = flask_mem_event,
> +    .mem_event_setup = flask_mem_event_setup,
> +    .mem_event_control = flask_mem_event_control,
> +    .mem_event_op = flask_mem_event_op,
>     .mem_sharing = flask_mem_sharing,
> +    .mem_sharing_op = flask_mem_sharing_op,
>     .apic = flask_apic,
>     .xen_settime = flask_xen_settime,
>     .memtype = flask_memtype,
> diff --git a/xen/xsm/flask/include/av_perm_to_string.h b/xen/xsm/flask/include/av_perm_to_string.h
> index 894910c..186f1fa 100644
> --- a/xen/xsm/flask/include/av_perm_to_string.h
> +++ b/xen/xsm/flask/include/av_perm_to_string.h
> @@ -84,6 +84,7 @@
>    S_(SECCLASS_HVM, HVM__MEM_SHARING, "mem_sharing")
>    S_(SECCLASS_HVM, HVM__AUDIT_P2M, "audit_p2m")
>    S_(SECCLASS_HVM, HVM__SEND_IRQ, "send_irq")
> +   S_(SECCLASS_HVM, HVM__SHARE_MEM, "share_mem")
>    S_(SECCLASS_EVENT, EVENT__BIND, "bind")
>    S_(SECCLASS_EVENT, EVENT__SEND, "send")
>    S_(SECCLASS_EVENT, EVENT__STATUS, "status")
> diff --git a/xen/xsm/flask/include/av_permissions.h b/xen/xsm/flask/include/av_permissions.h
> index 1bdb515..b3831f6 100644
> --- a/xen/xsm/flask/include/av_permissions.h
> +++ b/xen/xsm/flask/include/av_permissions.h
> @@ -87,6 +87,7 @@
> #define HVM__MEM_SHARING                          0x00001000UL
> #define HVM__AUDIT_P2M                            0x00002000UL
> #define HVM__SEND_IRQ                             0x00004000UL
> +#define HVM__SHARE_MEM                            0x00008000UL
> 
> #define EVENT__BIND                               0x00000001UL
> #define EVENT__SEND                               0x00000002UL
> -- 
> 1.7.11.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 12 17:03:42 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Sep 2012 17: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 1TBqLN-0001So-4J; Wed, 12 Sep 2012 17:03:17 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1TBqLL-0001Sj-7z
	for xen-devel@lists.xensource.com; Wed, 12 Sep 2012 17:03:15 +0000
Received: from [85.158.138.51:24419] by server-12.bemta-3.messagelabs.com id
	24/93-10384-250C0505; Wed, 12 Sep 2012 17:03:14 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1347469393!30290224!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDg4MjM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21310 invoked from network); 12 Sep 2012 17:03:13 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Sep 2012 17:03:13 -0000
X-IronPort-AV: E=Sophos;i="4.80,410,1344211200"; d="scan'208";a="14502401"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Sep 2012 17:03:13 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Wed, 12 Sep 2012 18:03: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 1TBqLI-0001ET-Sx;
	Wed, 12 Sep 2012 17:03:12 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1TBqLI-0005aA-Ra;
	Wed, 12 Sep 2012 18:03:12 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-13700-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 12 Sep 2012 18:03:12 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.2-testing test] 13700: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 13700 xen-4.2-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13700/

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. 13678
 build-amd64-pvops             4 kernel-build              fail REGR. vs. 13678

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-sedf-pin  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-credit2    1 xen-build-check(1)           blocked  n/a
 test-i386-i386-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-pcipt-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf      1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-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-multivcpu  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl           1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pv           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-amd  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 xen-build-check(1)         blocked n/a
 test-i386-i386-xl             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-i386-i386-xl-qemuu-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 xen-build-check(1)         blocked n/a
 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-amd64-pair         1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xend-winxpsp3  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-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-winxpsp3-vcpus1  1 xen-build-check(1)           blocked n/a
 test-amd64-i386-xl-win-vcpus1  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-qemuu-winxpsp3  1 xen-build-check(1)           blocked n/a
 test-amd64-amd64-xl-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-win          1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win       1 xen-build-check(1)           blocked  n/a

version targeted for testing:
 xen                  7f993b289dc4
baseline version:
 xen                  8c67e5358efa

------------------------------------------------------------
People who touched revisions under test:
  Ian Campbell <ian.campbell@citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Olaf Hering <olaf@aepfle.de>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           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.

------------------------------------------------------------
changeset:   25835:7f993b289dc4
tag:         tip
user:        Olaf Hering <olaf@aepfle.de>
date:        Wed Sep 12 14:48:04 2012 +0100
    
    unmodified_drivers: handle IRQF_SAMPLE_RANDOM
    
    The flag IRQF_SAMPLE_RANDOM was removed in 3.6-rc1. Add it only if it
    is
    defined. An additional call to add_interrupt_randomness is appearently
    not needed because its now called unconditionally in
    handle_irq_event_percpu().
    
    Signed-off-by: Olaf Hering <olaf@aepfle.de>
    Committed-by: Jan Beulich <jbeulich@suse.com>
    xen-unstable changeset:   25837:87cb4b6f53d3
    xen-unstable date:        Mon Sep 10 10:54:13 2012 +0200
    
    
changeset:   25834:8c67e5358efa
user:        Jan Beulich <jbeulich@suse.com>
date:        Tue Sep 11 12:34:07 2012 +0200
    
    docs: document "ucode=" hypervisor command line option
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Ian Campbell <ian.campbell@citrix.com>
    xen-unstable changeset: 25841:7d770de90b7f
    xen-unstable date: Mon Sep 10 10:13:56 UTC 2012
    
    
(qemu changes not included)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 12 17:03:42 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Sep 2012 17: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 1TBqLN-0001So-4J; Wed, 12 Sep 2012 17:03:17 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1TBqLL-0001Sj-7z
	for xen-devel@lists.xensource.com; Wed, 12 Sep 2012 17:03:15 +0000
Received: from [85.158.138.51:24419] by server-12.bemta-3.messagelabs.com id
	24/93-10384-250C0505; Wed, 12 Sep 2012 17:03:14 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1347469393!30290224!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDg4MjM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21310 invoked from network); 12 Sep 2012 17:03:13 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Sep 2012 17:03:13 -0000
X-IronPort-AV: E=Sophos;i="4.80,410,1344211200"; d="scan'208";a="14502401"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Sep 2012 17:03:13 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Wed, 12 Sep 2012 18:03: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 1TBqLI-0001ET-Sx;
	Wed, 12 Sep 2012 17:03:12 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1TBqLI-0005aA-Ra;
	Wed, 12 Sep 2012 18:03:12 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-13700-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 12 Sep 2012 18:03:12 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.2-testing test] 13700: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 13700 xen-4.2-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13700/

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. 13678
 build-amd64-pvops             4 kernel-build              fail REGR. vs. 13678

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-sedf-pin  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-credit2    1 xen-build-check(1)           blocked  n/a
 test-i386-i386-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-pcipt-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf      1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-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-multivcpu  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl           1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pv           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-amd  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 xen-build-check(1)         blocked n/a
 test-i386-i386-xl             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-i386-i386-xl-qemuu-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 xen-build-check(1)         blocked n/a
 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-amd64-pair         1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xend-winxpsp3  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-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-winxpsp3-vcpus1  1 xen-build-check(1)           blocked n/a
 test-amd64-i386-xl-win-vcpus1  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-qemuu-winxpsp3  1 xen-build-check(1)           blocked n/a
 test-amd64-amd64-xl-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-win          1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win       1 xen-build-check(1)           blocked  n/a

version targeted for testing:
 xen                  7f993b289dc4
baseline version:
 xen                  8c67e5358efa

------------------------------------------------------------
People who touched revisions under test:
  Ian Campbell <ian.campbell@citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Olaf Hering <olaf@aepfle.de>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           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.

------------------------------------------------------------
changeset:   25835:7f993b289dc4
tag:         tip
user:        Olaf Hering <olaf@aepfle.de>
date:        Wed Sep 12 14:48:04 2012 +0100
    
    unmodified_drivers: handle IRQF_SAMPLE_RANDOM
    
    The flag IRQF_SAMPLE_RANDOM was removed in 3.6-rc1. Add it only if it
    is
    defined. An additional call to add_interrupt_randomness is appearently
    not needed because its now called unconditionally in
    handle_irq_event_percpu().
    
    Signed-off-by: Olaf Hering <olaf@aepfle.de>
    Committed-by: Jan Beulich <jbeulich@suse.com>
    xen-unstable changeset:   25837:87cb4b6f53d3
    xen-unstable date:        Mon Sep 10 10:54:13 2012 +0200
    
    
changeset:   25834:8c67e5358efa
user:        Jan Beulich <jbeulich@suse.com>
date:        Tue Sep 11 12:34:07 2012 +0200
    
    docs: document "ucode=" hypervisor command line option
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Ian Campbell <ian.campbell@citrix.com>
    xen-unstable changeset: 25841:7d770de90b7f
    xen-unstable date: Mon Sep 10 10:13:56 UTC 2012
    
    
(qemu changes not included)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 12 17:08:24 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Sep 2012 17:08: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 1TBqPw-0001aO-R2; Wed, 12 Sep 2012 17:08:00 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1TBqPv-0001aJ-LZ
	for xen-devel@lists.xensource.com; Wed, 12 Sep 2012 17:07:59 +0000
Received: from [85.158.139.83:8511] by server-7.bemta-5.messagelabs.com id
	10/09-19703-E61C0505; Wed, 12 Sep 2012 17:07:58 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1347469678!18846333!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDg4MjM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12450 invoked from network); 12 Sep 2012 17:07:58 -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;
	12 Sep 2012 17:07:58 -0000
X-IronPort-AV: E=Sophos;i="4.80,410,1344211200"; d="scan'208";a="14502526"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Sep 2012 17:07: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.279.1; Wed, 12 Sep 2012 18:07:57 +0100
Date: Wed, 12 Sep 2012 18:07:16 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Rob Herring <robherring2@gmail.com>
In-Reply-To: <503BFCD8.5090804@gmail.com>
Message-ID: <alpine.DEB.2.02.1208281823270.15568@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1208161618550.4850@kaball.uk.xensource.com>
	<1345131377-14713-6-git-send-email-stefano.stabellini@eu.citrix.com>
	<503BFCD8.5090804@gmail.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>,
	"linaro-dev@lists.linaro.org" <linaro-dev@lists.linaro.org>,
	Ian Campbell <Ian.Campbell@citrix.com>, "arnd@arndb.de" <arnd@arndb.de>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"catalin.marinas@arm.com" <catalin.marinas@arm.com>,
	"devicetree-discuss@lists.ozlabs.org"
	<devicetree-discuss@lists.ozlabs.org>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
	"Tim \(Xen.org\)" <tim@xen.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	David Vrabel <david.vrabel@citrix.com>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Xen-devel] [PATCH v3 06/25] docs: Xen ARM DT bindings
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 28 Aug 2012, Rob Herring wrote:
> On 08/16/2012 10:35 AM, Stefano Stabellini wrote:
> > Add a doc to describe the Xen ARM device tree bindings
> > 
> > Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> > CC: devicetree-discuss@lists.ozlabs.org
> > CC: David Vrabel <david.vrabel@citrix.com>
> > ---
> >  Documentation/devicetree/bindings/arm/xen.txt |   22 ++++++++++++++++++++++
> >  1 files changed, 22 insertions(+), 0 deletions(-)
> >  create mode 100644 Documentation/devicetree/bindings/arm/xen.txt
> > 
> > diff --git a/Documentation/devicetree/bindings/arm/xen.txt b/Documentation/devicetree/bindings/arm/xen.txt
> > new file mode 100644
> > index 0000000..ec6d884
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/arm/xen.txt
> > @@ -0,0 +1,22 @@
> > +* Xen hypervisor device tree bindings
> > +
> > +Xen ARM virtual platforms shall have the following properties:
> > +
> > +- compatible:
> > +	compatible = "xen,xen", "xen,xen-<version>";
> > +  where <version> is the version of the Xen ABI of the platform.
> > +
> > +- reg: specifies the base physical address and size of a region in
> > +  memory where the grant table should be mapped to, using an
> > +  HYPERVISOR_memory_op hypercall. 
> > +
> > +- interrupts: the interrupt used by Xen to inject event notifications.
> 
> You should look at ePAPR 1.1 which defines hypervisor related bindings.
> While it is a PPC doc, we should reuse or extend what makes sense.
> 
> See section 7.5:
> 
> https://www.power.org/resources/downloads/Power_ePAPR_APPROVED_v1.1.pdf

Thanks for the link, I wasn't aware of ePAPR.

The hypervisor node defined by ePAPR is not very different from what I
am proposing. Should I try to be compatible with the hypervisor
specification above (as in compatible = "epapr,hypervisor-1.1")?
Or should I just use it as a reference for my own specification?

Personally I would rather avoid full compatibility with ePAPR.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 12 17:08:24 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Sep 2012 17:08: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 1TBqPw-0001aO-R2; Wed, 12 Sep 2012 17:08:00 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1TBqPv-0001aJ-LZ
	for xen-devel@lists.xensource.com; Wed, 12 Sep 2012 17:07:59 +0000
Received: from [85.158.139.83:8511] by server-7.bemta-5.messagelabs.com id
	10/09-19703-E61C0505; Wed, 12 Sep 2012 17:07:58 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1347469678!18846333!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDg4MjM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12450 invoked from network); 12 Sep 2012 17:07:58 -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;
	12 Sep 2012 17:07:58 -0000
X-IronPort-AV: E=Sophos;i="4.80,410,1344211200"; d="scan'208";a="14502526"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Sep 2012 17:07: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.279.1; Wed, 12 Sep 2012 18:07:57 +0100
Date: Wed, 12 Sep 2012 18:07:16 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Rob Herring <robherring2@gmail.com>
In-Reply-To: <503BFCD8.5090804@gmail.com>
Message-ID: <alpine.DEB.2.02.1208281823270.15568@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1208161618550.4850@kaball.uk.xensource.com>
	<1345131377-14713-6-git-send-email-stefano.stabellini@eu.citrix.com>
	<503BFCD8.5090804@gmail.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>,
	"linaro-dev@lists.linaro.org" <linaro-dev@lists.linaro.org>,
	Ian Campbell <Ian.Campbell@citrix.com>, "arnd@arndb.de" <arnd@arndb.de>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"catalin.marinas@arm.com" <catalin.marinas@arm.com>,
	"devicetree-discuss@lists.ozlabs.org"
	<devicetree-discuss@lists.ozlabs.org>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
	"Tim \(Xen.org\)" <tim@xen.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	David Vrabel <david.vrabel@citrix.com>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Xen-devel] [PATCH v3 06/25] docs: Xen ARM DT bindings
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 28 Aug 2012, Rob Herring wrote:
> On 08/16/2012 10:35 AM, Stefano Stabellini wrote:
> > Add a doc to describe the Xen ARM device tree bindings
> > 
> > Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> > CC: devicetree-discuss@lists.ozlabs.org
> > CC: David Vrabel <david.vrabel@citrix.com>
> > ---
> >  Documentation/devicetree/bindings/arm/xen.txt |   22 ++++++++++++++++++++++
> >  1 files changed, 22 insertions(+), 0 deletions(-)
> >  create mode 100644 Documentation/devicetree/bindings/arm/xen.txt
> > 
> > diff --git a/Documentation/devicetree/bindings/arm/xen.txt b/Documentation/devicetree/bindings/arm/xen.txt
> > new file mode 100644
> > index 0000000..ec6d884
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/arm/xen.txt
> > @@ -0,0 +1,22 @@
> > +* Xen hypervisor device tree bindings
> > +
> > +Xen ARM virtual platforms shall have the following properties:
> > +
> > +- compatible:
> > +	compatible = "xen,xen", "xen,xen-<version>";
> > +  where <version> is the version of the Xen ABI of the platform.
> > +
> > +- reg: specifies the base physical address and size of a region in
> > +  memory where the grant table should be mapped to, using an
> > +  HYPERVISOR_memory_op hypercall. 
> > +
> > +- interrupts: the interrupt used by Xen to inject event notifications.
> 
> You should look at ePAPR 1.1 which defines hypervisor related bindings.
> While it is a PPC doc, we should reuse or extend what makes sense.
> 
> See section 7.5:
> 
> https://www.power.org/resources/downloads/Power_ePAPR_APPROVED_v1.1.pdf

Thanks for the link, I wasn't aware of ePAPR.

The hypervisor node defined by ePAPR is not very different from what I
am proposing. Should I try to be compatible with the hypervisor
specification above (as in compatible = "epapr,hypervisor-1.1")?
Or should I just use it as a reference for my own specification?

Personally I would rather avoid full compatibility with ePAPR.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 12 17:19:45 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Sep 2012 17:19:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TBqb0-0001qs-9W; Wed, 12 Sep 2012 17:19:26 +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 1TBqay-0001ql-Go
	for xen-devel@lists.xen.org; Wed, 12 Sep 2012 17:19:24 +0000
Received: from [85.158.138.51:54930] by server-7.bemta-3.messagelabs.com id
	04/C8-32000-B14C0505; Wed, 12 Sep 2012 17:19:23 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-5.tower-174.messagelabs.com!1347470362!30292350!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA0OTgwOTc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32225 invoked from network); 12 Sep 2012 17:19:22 -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; 12 Sep 2012 17:19:22 -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 A69E72FE4;
	Wed, 12 Sep 2012 20:19:21 +0300 (EEST)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id 48A732005D; Wed, 12 Sep 2012 20:19:21 +0300 (EEST)
Date: Wed, 12 Sep 2012 20:19:21 +0300
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120912171921.GT8912@reaktio.net>
References: <20120902053549.GF8912@reaktio.net>
	<1346667053.25864.21.camel@zakaz.uk.xensource.com>
	<20120904191229.GH8912@reaktio.net>
	<1346834000.17325.4.camel@zakaz.uk.xensource.com>
	<20120905200858.GP8912@reaktio.net>
	<1347272111.5305.52.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1347272111.5305.52.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: Jan Beulich <JBeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v2] xl.cfg: gfx_passthru documentation
	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 Mon, Sep 10, 2012 at 11:15:11AM +0100, Ian Campbell wrote:
> On Wed, 2012-09-05 at 21:08 +0100, Pasi K=E4rkk=E4inen wrote:
> > Hello,
> > =

> > v2: address review comments.
> > =

> > xl.cfg.pod.5 documentation improvements:
> > =

> > - gfx_passthru: Document gfx_passthru makes the GPU become primary in t=
he guest
> >   and other generic info about gfx_passthru.
> > =

> > Signed-off-by: Pasi K=E4rkk=E4inen <pasik@iki.fi>
> =

> Acked + applied, thanks.
> =


Thanks!

> Jan, I think this docs only change can be a candidate for 4.2.0, but if
> not then 4.2.1 would be good. =

> =


Yes please, it would be nice to get this into 4.2.0 if possible.. it's a do=
cs only patch.

-- Pasi

> Ian.
> =

> > =

> > =

> > --- xen-unstable.hg/docs/man/xl.cfg.pod.5.orig  2012-09-05 22:51:39.745=
137076 +0300
> > +++ xen-unstable.hg/docs/man/xl.cfg.pod.5       2012-09-05 23:02:29.746=
203364 +0300
> > @@ -992,7 +992,44 @@
> > =

> >  =3Ditem B<gfx_passthru=3DBOOLEAN>
> > =

> > -Enable graphics device PCI passthrough. XXX which device is passed thr=
ough ?
> > +Enable graphics device PCI passthrough. This option makes the passthru
> > +graphics card become primary graphics card in the VM, so the Qemu emul=
ated
> > +graphics adapter is disabled, and the VNC console for the VM won't have
> > +any graphics output. All graphics output, including boot time Qemu BIOS
> > +messages from the VM, will go to the physical outputs of the passed th=
ru
> > +physical graphics card.
> > +
> > +Graphics card PCI device to passthru is chosen with B<pci> option,
> > +exactly in the same way as normal Xen PCI device passthru/assignment i=
s done.
> > +Note that gfx_passthru doesn't do any kind of sharing
> > +of the GPU, so you can only assign the GPU to one single VM at a time.
> > +
> > +gfx_passthru also enables various legacy VGA memory ranges, BARs, MMIO=
s,
> > +and ioports to be passed thru to the VM, since those are required
> > +for correct operation of things like VGA BIOS, text mode, VBE, etc.
> > +
> > +Enabling gfx_passthru option also copies the physical graphics card
> > +video BIOS to the guest memory, and executes the VBIOS in the guest
> > +to get the graphics card initialized.
> > +
> > +Most graphics adapters require vendor specific tweaks for properly
> > +working graphics passthru. See the XenVGAPassthroughTestedAdapters
> > +L<http://wiki.xen.org/wiki/XenVGAPassthroughTestedAdapters>
> > +wiki page for currently supported graphics cards for gfx_passthru.
> > +
> > +gfx_passthru is currently only supported with the qemu-xen-traditional
> > +device-model. Upstream qemu-xen device-model currently doesn't have
> > +support for gfx_passthru.
> > +
> > +Note that some graphics adapters (AMD/ATI cards, for example) don't
> > +necessarily require gfx_passthru option, so you can use the normal
> > +Xen PCI passthru to assign the graphics card as a secondary graphics c=
ard
> > +to the VM. Qemu emulated graphics card stays as the primary graphics c=
ard,
> > +and you get VNC output from the Qemu-emulated primary adapter.
> > +
> > +More information about Xen gfx_passthru feature is available
> > +on the XenVGAPassthrough L<http://wiki.xen.org/wiki/XenVGAPassthrough>
> > +wiki page.
> > =

> >  =3Ditem B<nomigrate=3DBOOLEAN>
> > =

> =

> =


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 12 17:19:45 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Sep 2012 17:19:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TBqb0-0001qs-9W; Wed, 12 Sep 2012 17:19:26 +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 1TBqay-0001ql-Go
	for xen-devel@lists.xen.org; Wed, 12 Sep 2012 17:19:24 +0000
Received: from [85.158.138.51:54930] by server-7.bemta-3.messagelabs.com id
	04/C8-32000-B14C0505; Wed, 12 Sep 2012 17:19:23 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-5.tower-174.messagelabs.com!1347470362!30292350!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA0OTgwOTc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32225 invoked from network); 12 Sep 2012 17:19:22 -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; 12 Sep 2012 17:19:22 -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 A69E72FE4;
	Wed, 12 Sep 2012 20:19:21 +0300 (EEST)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id 48A732005D; Wed, 12 Sep 2012 20:19:21 +0300 (EEST)
Date: Wed, 12 Sep 2012 20:19:21 +0300
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120912171921.GT8912@reaktio.net>
References: <20120902053549.GF8912@reaktio.net>
	<1346667053.25864.21.camel@zakaz.uk.xensource.com>
	<20120904191229.GH8912@reaktio.net>
	<1346834000.17325.4.camel@zakaz.uk.xensource.com>
	<20120905200858.GP8912@reaktio.net>
	<1347272111.5305.52.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1347272111.5305.52.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: Jan Beulich <JBeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v2] xl.cfg: gfx_passthru documentation
	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 Mon, Sep 10, 2012 at 11:15:11AM +0100, Ian Campbell wrote:
> On Wed, 2012-09-05 at 21:08 +0100, Pasi K=E4rkk=E4inen wrote:
> > Hello,
> > =

> > v2: address review comments.
> > =

> > xl.cfg.pod.5 documentation improvements:
> > =

> > - gfx_passthru: Document gfx_passthru makes the GPU become primary in t=
he guest
> >   and other generic info about gfx_passthru.
> > =

> > Signed-off-by: Pasi K=E4rkk=E4inen <pasik@iki.fi>
> =

> Acked + applied, thanks.
> =


Thanks!

> Jan, I think this docs only change can be a candidate for 4.2.0, but if
> not then 4.2.1 would be good. =

> =


Yes please, it would be nice to get this into 4.2.0 if possible.. it's a do=
cs only patch.

-- Pasi

> Ian.
> =

> > =

> > =

> > --- xen-unstable.hg/docs/man/xl.cfg.pod.5.orig  2012-09-05 22:51:39.745=
137076 +0300
> > +++ xen-unstable.hg/docs/man/xl.cfg.pod.5       2012-09-05 23:02:29.746=
203364 +0300
> > @@ -992,7 +992,44 @@
> > =

> >  =3Ditem B<gfx_passthru=3DBOOLEAN>
> > =

> > -Enable graphics device PCI passthrough. XXX which device is passed thr=
ough ?
> > +Enable graphics device PCI passthrough. This option makes the passthru
> > +graphics card become primary graphics card in the VM, so the Qemu emul=
ated
> > +graphics adapter is disabled, and the VNC console for the VM won't have
> > +any graphics output. All graphics output, including boot time Qemu BIOS
> > +messages from the VM, will go to the physical outputs of the passed th=
ru
> > +physical graphics card.
> > +
> > +Graphics card PCI device to passthru is chosen with B<pci> option,
> > +exactly in the same way as normal Xen PCI device passthru/assignment i=
s done.
> > +Note that gfx_passthru doesn't do any kind of sharing
> > +of the GPU, so you can only assign the GPU to one single VM at a time.
> > +
> > +gfx_passthru also enables various legacy VGA memory ranges, BARs, MMIO=
s,
> > +and ioports to be passed thru to the VM, since those are required
> > +for correct operation of things like VGA BIOS, text mode, VBE, etc.
> > +
> > +Enabling gfx_passthru option also copies the physical graphics card
> > +video BIOS to the guest memory, and executes the VBIOS in the guest
> > +to get the graphics card initialized.
> > +
> > +Most graphics adapters require vendor specific tweaks for properly
> > +working graphics passthru. See the XenVGAPassthroughTestedAdapters
> > +L<http://wiki.xen.org/wiki/XenVGAPassthroughTestedAdapters>
> > +wiki page for currently supported graphics cards for gfx_passthru.
> > +
> > +gfx_passthru is currently only supported with the qemu-xen-traditional
> > +device-model. Upstream qemu-xen device-model currently doesn't have
> > +support for gfx_passthru.
> > +
> > +Note that some graphics adapters (AMD/ATI cards, for example) don't
> > +necessarily require gfx_passthru option, so you can use the normal
> > +Xen PCI passthru to assign the graphics card as a secondary graphics c=
ard
> > +to the VM. Qemu emulated graphics card stays as the primary graphics c=
ard,
> > +and you get VNC output from the Qemu-emulated primary adapter.
> > +
> > +More information about Xen gfx_passthru feature is available
> > +on the XenVGAPassthrough L<http://wiki.xen.org/wiki/XenVGAPassthrough>
> > +wiki page.
> > =

> >  =3Ditem B<nomigrate=3DBOOLEAN>
> > =

> =

> =


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 12 17:40:36 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Sep 2012 17:40:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TBqvA-00027n-B8; Wed, 12 Sep 2012 17:40: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 1TBqv8-00027f-Ju
	for xen-devel@lists.xensource.com; Wed, 12 Sep 2012 17:40:14 +0000
Received: from [85.158.143.99:7269] by server-3.bemta-4.messagelabs.com id
	B6/07-08232-DF8C0505; Wed, 12 Sep 2012 17:40:13 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1347471611!29683163!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDg4MjM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20553 invoked from network); 12 Sep 2012 17:40:11 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Sep 2012 17:40:11 -0000
X-IronPort-AV: E=Sophos;i="4.80,410,1344211200"; d="scan'208";a="14503085"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Sep 2012 17:40: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.279.1; Wed, 12 Sep 2012 18:40:10 +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 1TBqv3-0001dK-Ps;
	Wed, 12 Sep 2012 17:40:09 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1TBqv3-0006fj-JM;
	Wed, 12 Sep 2012 18:40:09 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-13701-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 12 Sep 2012 18:40:09 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13701: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 13701 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13701/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64                   4 xen-build                 fail REGR. vs. 13668
 build-amd64-oldkern           4 xen-build                 fail REGR. vs. 13668
 build-i386-oldkern            4 xen-build                 fail REGR. vs. 13668
 build-i386                    4 xen-build                 fail REGR. vs. 13668
 build-amd64-pvops             4 kernel-build              fail REGR. vs. 13668

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-sedf-pin  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-amd  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 xen-build-check(1)           blocked n/a
 test-i386-i386-xl-qemuu-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-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-xend-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win           1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-qemuu-winxpsp3  1 xen-build-check(1)           blocked n/a
 test-amd64-amd64-xl-sedf      1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pv           1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-credit2    1 xen-build-check(1)           blocked  n/a
 test-amd64-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-win          1 xen-build-check(1)           blocked  n/a
 test-i386-i386-pv             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-i386-qemuu-rhel6hvm-intel  1 xen-build-check(1)         blocked n/a
 test-amd64-amd64-xl-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pv            1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-pcipt-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win-vcpus1    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-winxpsp3-vcpus1  1 xen-build-check(1)           blocked n/a
 test-amd64-i386-xl            1 xen-build-check(1)           blocked  n/a
 test-i386-i386-win            1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-win         1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-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-amd64-amd64-pair         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

version targeted for testing:
 xen                  7b658d31b5e1
baseline version:
 xen                  7d770de90b7f

------------------------------------------------------------
People who touched revisions under test:
  Boris Ostrovsky <boris.ostrovsky@amd.com>
  Christoph Egger <Christoph.Egger@amd.com>
  Dan Magenheimer <dan.magenheimer@oracle.com>
  David Vrabel <david.vrabel@citrix.com>
  Ian Campbell <ian.campbell@citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Keir Fraser <keir@xen.org>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Wei Wang <wei.wang2@amd.com>
  Zhenzhong Duan <zhenzhong.duan@oracle.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  fail    
 build-i386                                                   fail    
 build-amd64-oldkern                                          fail    
 build-i386-oldkern                                           fail    
 build-amd64-pvops                                            fail    
 build-i386-pvops                                             pass    
 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.

(No revision log; it would be 593 lines long.)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 12 17:40:36 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Sep 2012 17:40:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TBqvA-00027n-B8; Wed, 12 Sep 2012 17:40: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 1TBqv8-00027f-Ju
	for xen-devel@lists.xensource.com; Wed, 12 Sep 2012 17:40:14 +0000
Received: from [85.158.143.99:7269] by server-3.bemta-4.messagelabs.com id
	B6/07-08232-DF8C0505; Wed, 12 Sep 2012 17:40:13 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1347471611!29683163!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDg4MjM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20553 invoked from network); 12 Sep 2012 17:40:11 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Sep 2012 17:40:11 -0000
X-IronPort-AV: E=Sophos;i="4.80,410,1344211200"; d="scan'208";a="14503085"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Sep 2012 17:40: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.279.1; Wed, 12 Sep 2012 18:40:10 +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 1TBqv3-0001dK-Ps;
	Wed, 12 Sep 2012 17:40:09 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1TBqv3-0006fj-JM;
	Wed, 12 Sep 2012 18:40:09 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-13701-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 12 Sep 2012 18:40:09 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13701: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 13701 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13701/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64                   4 xen-build                 fail REGR. vs. 13668
 build-amd64-oldkern           4 xen-build                 fail REGR. vs. 13668
 build-i386-oldkern            4 xen-build                 fail REGR. vs. 13668
 build-i386                    4 xen-build                 fail REGR. vs. 13668
 build-amd64-pvops             4 kernel-build              fail REGR. vs. 13668

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-sedf-pin  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-amd  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 xen-build-check(1)           blocked n/a
 test-i386-i386-xl-qemuu-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-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-xend-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win           1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-qemuu-winxpsp3  1 xen-build-check(1)           blocked n/a
 test-amd64-amd64-xl-sedf      1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pv           1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-credit2    1 xen-build-check(1)           blocked  n/a
 test-amd64-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-win          1 xen-build-check(1)           blocked  n/a
 test-i386-i386-pv             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-i386-qemuu-rhel6hvm-intel  1 xen-build-check(1)         blocked n/a
 test-amd64-amd64-xl-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pv            1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-pcipt-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win-vcpus1    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-winxpsp3-vcpus1  1 xen-build-check(1)           blocked n/a
 test-amd64-i386-xl            1 xen-build-check(1)           blocked  n/a
 test-i386-i386-win            1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-win         1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-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-amd64-amd64-pair         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

version targeted for testing:
 xen                  7b658d31b5e1
baseline version:
 xen                  7d770de90b7f

------------------------------------------------------------
People who touched revisions under test:
  Boris Ostrovsky <boris.ostrovsky@amd.com>
  Christoph Egger <Christoph.Egger@amd.com>
  Dan Magenheimer <dan.magenheimer@oracle.com>
  David Vrabel <david.vrabel@citrix.com>
  Ian Campbell <ian.campbell@citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Keir Fraser <keir@xen.org>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Wei Wang <wei.wang2@amd.com>
  Zhenzhong Duan <zhenzhong.duan@oracle.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  fail    
 build-i386                                                   fail    
 build-amd64-oldkern                                          fail    
 build-i386-oldkern                                           fail    
 build-amd64-pvops                                            fail    
 build-i386-pvops                                             pass    
 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.

(No revision log; it would be 593 lines long.)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 12 18:00:53 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Sep 2012 18: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 1TBrEY-0002NA-5d; Wed, 12 Sep 2012 18:00:18 +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 1TBrEW-0002N5-MN
	for Xen-devel@lists.xensource.com; Wed, 12 Sep 2012 18:00:16 +0000
Received: from [85.158.143.99:18989] by server-2.bemta-4.messagelabs.com id
	6B/40-21239-FADC0505; Wed, 12 Sep 2012 18:00:15 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1347472813!24739074!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDc0NjAyNA==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23864 invoked from network); 12 Sep 2012 18:00:14 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-4.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 12 Sep 2012 18:00:14 -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 q8CI08vC005838
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 12 Sep 2012 18:00:09 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q8CI07hs009614
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 12 Sep 2012 18:00:08 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
	q8CI05rh030879; Wed, 12 Sep 2012 13:00:07 -0500
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 12 Sep 2012 11:00:04 -0700
Date: Wed, 12 Sep 2012 11:00:03 -0700
From: Mukesh Rathor <mukesh.rathor@oracle.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120912110003.4d694761@mantra.us.oracle.com>
In-Reply-To: <1347435419.10570.107.camel@dagon.hellion.org.uk>
References: <20120815180716.0049bffe@mantra.us.oracle.com>
	<1347372623.5305.170.camel@zakaz.uk.xensource.com>
	<20120911183210.5c43f428@mantra.us.oracle.com>
	<1347435419.10570.107.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: ucsinet22.oracle.com [156.151.31.94]
Cc: "Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [RFC PATCH 8/8]: PVH: privcmd changes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 12 Sep 2012 08:36:59 +0100
Ian Campbell <Ian.Campbell@citrix.com> wrote:

> On Wed, 2012-09-12 at 02:32 +0100, Mukesh Rathor wrote:
> > On Tue, 11 Sep 2012 15:10:23 +0100
> > Ian Campbell <Ian.Campbell@citrix.com> wrote:
> > 
> > > On Thu, 2012-08-16 at 02:07 +0100, Mukesh Rathor wrote:
> > > > ---
> > > >  drivers/xen/privcmd.c |   68
> > > > +	if (rc != 0) {
> > > > +		pr_warn("%s Could not alloc %d pfns rc:%d\n",
> > > > __FUNCTION__,
> > > > +			numpgs, rc);
> > > > +		kfree(savp->sp_paga);
> > > > +		kfree(savp);
> > > > +		return -ENOMEM;
> > > > +	}
> > > 
> > > I've just been building on this patch to make proper mmap foreign
> > > support on ARM and I was looking for the place which freed this,
> > > both the pages back to the balloon and then the array itself.
> > > There is code in privcmd_close which unmaps the P2M, but I can't
> > > find the code which frees things back to the balloon. Have I
> > > missed something?
> > 
> > You are right, I missed the free. Let me revisit it and make some
> > changes.
> 
> Thanks.
> 
> Any comments on the rest of my mail? We need to agree what the
> interface between the generic and the per-arch code is going to look
> like here.
> 
> Ian.

Right, I am paging it all in the brain right now, as I made the changes
a while ago :). I will attempt to change the code according to
your email, to come up with generic interface. Also I am going to come
up with xen_unmap_domain_mfn_range. Mostly agree with your email. More
soon.

thanks,
Mukesh

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 12 18:00:53 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Sep 2012 18: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 1TBrEY-0002NA-5d; Wed, 12 Sep 2012 18:00:18 +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 1TBrEW-0002N5-MN
	for Xen-devel@lists.xensource.com; Wed, 12 Sep 2012 18:00:16 +0000
Received: from [85.158.143.99:18989] by server-2.bemta-4.messagelabs.com id
	6B/40-21239-FADC0505; Wed, 12 Sep 2012 18:00:15 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1347472813!24739074!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDc0NjAyNA==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23864 invoked from network); 12 Sep 2012 18:00:14 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-4.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 12 Sep 2012 18:00:14 -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 q8CI08vC005838
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 12 Sep 2012 18:00:09 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q8CI07hs009614
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 12 Sep 2012 18:00:08 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
	q8CI05rh030879; Wed, 12 Sep 2012 13:00:07 -0500
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 12 Sep 2012 11:00:04 -0700
Date: Wed, 12 Sep 2012 11:00:03 -0700
From: Mukesh Rathor <mukesh.rathor@oracle.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120912110003.4d694761@mantra.us.oracle.com>
In-Reply-To: <1347435419.10570.107.camel@dagon.hellion.org.uk>
References: <20120815180716.0049bffe@mantra.us.oracle.com>
	<1347372623.5305.170.camel@zakaz.uk.xensource.com>
	<20120911183210.5c43f428@mantra.us.oracle.com>
	<1347435419.10570.107.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: ucsinet22.oracle.com [156.151.31.94]
Cc: "Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [RFC PATCH 8/8]: PVH: privcmd changes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 12 Sep 2012 08:36:59 +0100
Ian Campbell <Ian.Campbell@citrix.com> wrote:

> On Wed, 2012-09-12 at 02:32 +0100, Mukesh Rathor wrote:
> > On Tue, 11 Sep 2012 15:10:23 +0100
> > Ian Campbell <Ian.Campbell@citrix.com> wrote:
> > 
> > > On Thu, 2012-08-16 at 02:07 +0100, Mukesh Rathor wrote:
> > > > ---
> > > >  drivers/xen/privcmd.c |   68
> > > > +	if (rc != 0) {
> > > > +		pr_warn("%s Could not alloc %d pfns rc:%d\n",
> > > > __FUNCTION__,
> > > > +			numpgs, rc);
> > > > +		kfree(savp->sp_paga);
> > > > +		kfree(savp);
> > > > +		return -ENOMEM;
> > > > +	}
> > > 
> > > I've just been building on this patch to make proper mmap foreign
> > > support on ARM and I was looking for the place which freed this,
> > > both the pages back to the balloon and then the array itself.
> > > There is code in privcmd_close which unmaps the P2M, but I can't
> > > find the code which frees things back to the balloon. Have I
> > > missed something?
> > 
> > You are right, I missed the free. Let me revisit it and make some
> > changes.
> 
> Thanks.
> 
> Any comments on the rest of my mail? We need to agree what the
> interface between the generic and the per-arch code is going to look
> like here.
> 
> Ian.

Right, I am paging it all in the brain right now, as I made the changes
a while ago :). I will attempt to change the code according to
your email, to come up with generic interface. Also I am going to come
up with xen_unmap_domain_mfn_range. Mostly agree with your email. More
soon.

thanks,
Mukesh

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 12 18:00:54 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Sep 2012 18:00:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TBrEr-0002Nv-II; Wed, 12 Sep 2012 18:00:37 +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 1TBrEq-0002Nk-Fx
	for xen-devel@lists.xen.org; Wed, 12 Sep 2012 18:00:36 +0000
Received: from [85.158.138.51:17661] by server-3.bemta-3.messagelabs.com id
	1E/FB-21322-3CDC0505; Wed, 12 Sep 2012 18:00:35 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1347472830!30297239!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNzM5MTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15608 invoked from network); 12 Sep 2012 18:00:34 -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;
	12 Sep 2012 18:00:34 -0000
X-IronPort-AV: E=Sophos;i="4.80,410,1344211200"; d="scan'208";a="207894730"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Sep 2012 18:00:28 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 12 Sep 2012 14:00:28 -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 1TBrEh-00012i-V4;
	Wed, 12 Sep 2012 19:00:27 +0100
Message-ID: <5050CDBB.6070309@citrix.com>
Date: Wed, 12 Sep 2012 19:00:27 +0100
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:14.0) Gecko/20120714 Thunderbird/14.0
MIME-Version: 1.0
To: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>, Keir Fraser
	<keir@xen.org>, Jan Beulich <jbeulich@suse.com>
X-Enigmail-Version: 1.4.4
Content-Type: multipart/mixed; boundary="------------040201050205030604030708"
Subject: [Xen-devel] x86/passthrough: Fix corruption caused by race
 conditions between device allocation and deallocation to a 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>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--------------040201050205030604030708
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit

This issue certainly affects unstable, 4.2 and 4.1, and probably affects
previous releases as well.

It has been tested by using 40 VMs with 8 devices passed through to
each, in a reboot loop.  Before the fix, the host would reliably crash
before the end of the first reboot cycle, whereas with the fix, the VMs
are on their 20th reboot cycle with no issue.

-- 
Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
T: +44 (0)1223 225 900, http://www.citrix.com


--------------040201050205030604030708
Content-Type: text/x-patch; name="passthrough-fix-corruption.patch"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="passthrough-fix-corruption.patch"

# HG changeset patch
# Parent 7d770de90b7f92bb197bd54d8ac0941e2e5ae96a
x86/passthrough: Fix corruption caused by race conditions between device allocation and deallocation to a domain.

A toolstack, when dealing with a domain using PCIPassthrough, could
reasonably be expected to issue DOMCTL_deassign_device hypercalls to
remove all passed through devices before issuing a DOMCTL_destroydomain
hypercall to kill the domain.  In the case where a toolstack is perhaps
less sensible in this regard, the hypervisor should not fall over.

In domain_kill(), pci_release_devices() searches the alldevs_list list
looking for PCI devices still assigned to the domain.  If the toolstack
has correctly deassigned all devices before killing the domain, this
loop does nothing.

However, if there are still devices attached to the domain, the loop
will call pci_cleanup_msi() without unbinding the pirq from the domain.
This eventually calls destroy_irq() which xfree()'s the action.

However, as the irq_desc->action pointer is abused in an unsafe matter,
without unbinding first (which at least correctly cleans up), the action
is actually an irq_guest_action_t* rather than an irqaction*, meaning
that the cpu_eoi_map is leaked, and eoi_timer is free()'d while still
being on a pcpu's inactive_timer list.  As a result, when this free()'d
memory gets reused, the inactive_timer list becomes corrupt, and
list_*** operations will corrupt hypervisor memory.

If the above were not bad enough, the loop in pci_release_devices()
still leaves references to the irq it destroyed in domain->arch.pirq_irq
and irq_pirq, meaning that a later loop, free_domain_pirqs(), which
happens as a result of complete_domain_destroy() will unbind and destroy
all irqs which were still bound to the domain, resulting in a double
destroy of any irq which was still bound to the domain at the point at
which the DOMCTL_destroydomain hypercall happened.

Because of the allocation of irqs from find_unassigned_irq(), the lowest
free irq number is going to be handed back from create_irq().

There is a further race condition between the original (incorrect) call
to destroy_irq() from pci_release_devices(), and the later call to
free_domain_pirqs() (which happens in a softirq context at some point
after the domain has officially died) during which the same irq number
(which is still referenced in a stale way in domain->arch.pirq_irq and
irq_pirq) has been allocated to a new domain via a PHYSDEVOP_map_pirq
hypercall (Say perhaps in the case of rebooting a domain).

In this case, the cleanup for the dead domain will free the recently
bound irq under the feet of the new domain.  Furthermore, after the irq
has been incorrectly destroyed, the same domain with another
PHYSDEVOP_map_pirq hypercall can be allocated the same irq number as
before, leading to an error along the lines of:

../physdev.c:188: dom54: -1:-1 already mapped to 74

In this case, the pirq_irq and irq_pirq mappings get updated to the new
PCI device from the latter PHYSDEVOP_map_pirq hypercall, and the IOMMU
interrupt remapping registers get updated, leading to IOMMU Primary
Pending Fault due to source-id verification failure for incoming
interrupts from the passed through device.


The easy fix is to simply deassign the device in pci_release_devices()
and leave all the real cleanup to the free_domain_pirqs() which
correctly unbinds and destroys the irq without leaving stale references
around.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>

diff -r 7d770de90b7f xen/drivers/passthrough/pci.c
--- a/xen/drivers/passthrough/pci.c
+++ b/xen/drivers/passthrough/pci.c
@@ -551,7 +551,6 @@ void pci_release_devices(struct domain *
     pci_clean_dpci_irqs(d);
     while ( (pdev = pci_get_pdev_by_domain(d, -1, -1, -1)) )
     {
-        pci_cleanup_msi(pdev);
         bus = pdev->bus;
         devfn = pdev->devfn;
         if ( deassign_device(d, pdev->seg, bus, devfn) )

--------------040201050205030604030708
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--------------040201050205030604030708--


From xen-devel-bounces@lists.xen.org Wed Sep 12 18:00:54 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Sep 2012 18:00:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TBrEr-0002Nv-II; Wed, 12 Sep 2012 18:00:37 +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 1TBrEq-0002Nk-Fx
	for xen-devel@lists.xen.org; Wed, 12 Sep 2012 18:00:36 +0000
Received: from [85.158.138.51:17661] by server-3.bemta-3.messagelabs.com id
	1E/FB-21322-3CDC0505; Wed, 12 Sep 2012 18:00:35 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1347472830!30297239!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNzM5MTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15608 invoked from network); 12 Sep 2012 18:00:34 -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;
	12 Sep 2012 18:00:34 -0000
X-IronPort-AV: E=Sophos;i="4.80,410,1344211200"; d="scan'208";a="207894730"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Sep 2012 18:00:28 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 12 Sep 2012 14:00:28 -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 1TBrEh-00012i-V4;
	Wed, 12 Sep 2012 19:00:27 +0100
Message-ID: <5050CDBB.6070309@citrix.com>
Date: Wed, 12 Sep 2012 19:00:27 +0100
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:14.0) Gecko/20120714 Thunderbird/14.0
MIME-Version: 1.0
To: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>, Keir Fraser
	<keir@xen.org>, Jan Beulich <jbeulich@suse.com>
X-Enigmail-Version: 1.4.4
Content-Type: multipart/mixed; boundary="------------040201050205030604030708"
Subject: [Xen-devel] x86/passthrough: Fix corruption caused by race
 conditions between device allocation and deallocation to a 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>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--------------040201050205030604030708
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit

This issue certainly affects unstable, 4.2 and 4.1, and probably affects
previous releases as well.

It has been tested by using 40 VMs with 8 devices passed through to
each, in a reboot loop.  Before the fix, the host would reliably crash
before the end of the first reboot cycle, whereas with the fix, the VMs
are on their 20th reboot cycle with no issue.

-- 
Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
T: +44 (0)1223 225 900, http://www.citrix.com


--------------040201050205030604030708
Content-Type: text/x-patch; name="passthrough-fix-corruption.patch"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="passthrough-fix-corruption.patch"

# HG changeset patch
# Parent 7d770de90b7f92bb197bd54d8ac0941e2e5ae96a
x86/passthrough: Fix corruption caused by race conditions between device allocation and deallocation to a domain.

A toolstack, when dealing with a domain using PCIPassthrough, could
reasonably be expected to issue DOMCTL_deassign_device hypercalls to
remove all passed through devices before issuing a DOMCTL_destroydomain
hypercall to kill the domain.  In the case where a toolstack is perhaps
less sensible in this regard, the hypervisor should not fall over.

In domain_kill(), pci_release_devices() searches the alldevs_list list
looking for PCI devices still assigned to the domain.  If the toolstack
has correctly deassigned all devices before killing the domain, this
loop does nothing.

However, if there are still devices attached to the domain, the loop
will call pci_cleanup_msi() without unbinding the pirq from the domain.
This eventually calls destroy_irq() which xfree()'s the action.

However, as the irq_desc->action pointer is abused in an unsafe matter,
without unbinding first (which at least correctly cleans up), the action
is actually an irq_guest_action_t* rather than an irqaction*, meaning
that the cpu_eoi_map is leaked, and eoi_timer is free()'d while still
being on a pcpu's inactive_timer list.  As a result, when this free()'d
memory gets reused, the inactive_timer list becomes corrupt, and
list_*** operations will corrupt hypervisor memory.

If the above were not bad enough, the loop in pci_release_devices()
still leaves references to the irq it destroyed in domain->arch.pirq_irq
and irq_pirq, meaning that a later loop, free_domain_pirqs(), which
happens as a result of complete_domain_destroy() will unbind and destroy
all irqs which were still bound to the domain, resulting in a double
destroy of any irq which was still bound to the domain at the point at
which the DOMCTL_destroydomain hypercall happened.

Because of the allocation of irqs from find_unassigned_irq(), the lowest
free irq number is going to be handed back from create_irq().

There is a further race condition between the original (incorrect) call
to destroy_irq() from pci_release_devices(), and the later call to
free_domain_pirqs() (which happens in a softirq context at some point
after the domain has officially died) during which the same irq number
(which is still referenced in a stale way in domain->arch.pirq_irq and
irq_pirq) has been allocated to a new domain via a PHYSDEVOP_map_pirq
hypercall (Say perhaps in the case of rebooting a domain).

In this case, the cleanup for the dead domain will free the recently
bound irq under the feet of the new domain.  Furthermore, after the irq
has been incorrectly destroyed, the same domain with another
PHYSDEVOP_map_pirq hypercall can be allocated the same irq number as
before, leading to an error along the lines of:

../physdev.c:188: dom54: -1:-1 already mapped to 74

In this case, the pirq_irq and irq_pirq mappings get updated to the new
PCI device from the latter PHYSDEVOP_map_pirq hypercall, and the IOMMU
interrupt remapping registers get updated, leading to IOMMU Primary
Pending Fault due to source-id verification failure for incoming
interrupts from the passed through device.


The easy fix is to simply deassign the device in pci_release_devices()
and leave all the real cleanup to the free_domain_pirqs() which
correctly unbinds and destroys the irq without leaving stale references
around.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>

diff -r 7d770de90b7f xen/drivers/passthrough/pci.c
--- a/xen/drivers/passthrough/pci.c
+++ b/xen/drivers/passthrough/pci.c
@@ -551,7 +551,6 @@ void pci_release_devices(struct domain *
     pci_clean_dpci_irqs(d);
     while ( (pdev = pci_get_pdev_by_domain(d, -1, -1, -1)) )
     {
-        pci_cleanup_msi(pdev);
         bus = pdev->bus;
         devfn = pdev->devfn;
         if ( deassign_device(d, pdev->seg, bus, devfn) )

--------------040201050205030604030708
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--------------040201050205030604030708--


From xen-devel-bounces@lists.xen.org Wed Sep 12 18:16:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Sep 2012 18:16:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TBrTT-0002kr-3Q; Wed, 12 Sep 2012 18:15: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 1TBrTR-0002km-LW
	for xen-devel@lists.xensource.com; Wed, 12 Sep 2012 18:15:41 +0000
Received: from [85.158.143.99:57409] by server-1.bemta-4.messagelabs.com id
	FD/2D-12504-C41D0505; Wed, 12 Sep 2012 18:15:40 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1347473740!18800308!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDg4MjM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12542 invoked from network); 12 Sep 2012 18:15:40 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Sep 2012 18:15:40 -0000
X-IronPort-AV: E=Sophos;i="4.80,410,1344211200"; d="scan'208";a="14503477"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Sep 2012 18:15:39 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Wed, 12 Sep 2012 19:15:39 +0100
Date: Wed, 12 Sep 2012 19:14:58 +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.1208281823270.15568@kaball.uk.xensource.com>
Message-ID: <alpine.DEB.2.02.1209121849200.15568@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1208161618550.4850@kaball.uk.xensource.com>
	<1345131377-14713-6-git-send-email-stefano.stabellini@eu.citrix.com>
	<503BFCD8.5090804@gmail.com>
	<alpine.DEB.2.02.1208281823270.15568@kaball.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>,
	"linaro-dev@lists.linaro.org" <linaro-dev@lists.linaro.org>,
	Ian Campbell <Ian.Campbell@citrix.com>, "arnd@arndb.de" <arnd@arndb.de>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
	"catalin.marinas@arm.com" <catalin.marinas@arm.com>,
	"devicetree-discuss@lists.ozlabs.org"
	<devicetree-discuss@lists.ozlabs.org>, "Tim \(Xen.org\)" <tim@xen.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Rob Herring <robherring2@gmail.com>,
	David Vrabel <david.vrabel@citrix.com>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Xen-devel] [PATCH v3 06/25] docs: Xen ARM DT bindings
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 12 Sep 2012, Stefano Stabellini wrote:
> On Tue, 28 Aug 2012, Rob Herring wrote:
> > You should look at ePAPR 1.1 which defines hypervisor related bindings.
> > While it is a PPC doc, we should reuse or extend what makes sense.
> > 
> > See section 7.5:
> > 
> > https://www.power.org/resources/downloads/Power_ePAPR_APPROVED_v1.1.pdf
> 
> Thanks for the link, I wasn't aware of ePAPR.
> 
> The hypervisor node defined by ePAPR is not very different from what I
> am proposing. Should I try to be compatible with the hypervisor
> specification above (as in compatible = "epapr,hypervisor-1.1")?
> Or should I just use it as a reference for my own specification?
> 
> Personally I would rather avoid full compatibility with ePAPR.

In particular reading section 7.5, these are the required properties of
the ePAPR hypervisor node:

- compatible = "epapr,hypervisor-1.1"
compared to what I am proposing, it is laking information about what
hypervisor we are talking about (xen, kvm, vmware, etc) and the version
of the ABI (xen-4.2).

- hcall-instructions
potentially interesting, but given that for Xen we are quite happy with
HVC, we are not going to add any secondary hypercall mechanisms,
therefore at the moment it would just result in a BUG if the specified
hcall instruction is != HVC. Besides if somebody else wanted to
implemented the Xen hypercall interface in a different way they could
just reimplement the hypercall wrappers, that would be easier than
trying to do it with this property.

- guest-id
we usually make a point in trying not to tell the guest its own domid
because if the VM gets migrated to a different host it acquires a new
domid, therefore it should not rely on it.

- guest-name
we could pass the guest name here, but I don't see how it could be
of any use.



On the other hand, thinking more about what Xen needs in the device
tree, I think we could improve the current spec by clarifying the
meaning of the memory region and interrupt properties we currently
require. I thought about moving them to two separate children node with
an explicit name:

---

* Xen hypervisor device tree bindings

Xen ARM virtual platforms shall have the following properties and
children nodes:

- compatible property:
	compatible = "xen,xen", "xen,xen-<version>";
  where <version> is the version of the Xen ABI of the platform.

- grant_table child with the following properties:
    - name:
	    name = "grant_table";
	- reg: specifies the base physical address and size of a region in
	    memory where the grant table should be mapped to, using an
        HYPERVISOR_memory_op hypercall. 

- events child with the following properties:
    - name:
        name = "events";
	- interrupts: the interrupt used by Xen to inject event notifications.


Example:
hypervisor {
		compatible = "xen,xen", "xen,xen-4.2";
		#address-cells = <1>;
		#size-cells = <1>;
		#interrupt-cells = <3>;
		ranges = <0xb0000000 0xb0000000 0x20000>;

		grant_table {
			name = "grant_table";
			reg = <0xb0000000 0x20000>;
		};

		events {
			name = "events";
			interrupts = <1 15 0xf08>;
		};
	};

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 12 18:16:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Sep 2012 18:16:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TBrTT-0002kr-3Q; Wed, 12 Sep 2012 18:15: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 1TBrTR-0002km-LW
	for xen-devel@lists.xensource.com; Wed, 12 Sep 2012 18:15:41 +0000
Received: from [85.158.143.99:57409] by server-1.bemta-4.messagelabs.com id
	FD/2D-12504-C41D0505; Wed, 12 Sep 2012 18:15:40 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1347473740!18800308!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDg4MjM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12542 invoked from network); 12 Sep 2012 18:15:40 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Sep 2012 18:15:40 -0000
X-IronPort-AV: E=Sophos;i="4.80,410,1344211200"; d="scan'208";a="14503477"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Sep 2012 18:15:39 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Wed, 12 Sep 2012 19:15:39 +0100
Date: Wed, 12 Sep 2012 19:14:58 +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.1208281823270.15568@kaball.uk.xensource.com>
Message-ID: <alpine.DEB.2.02.1209121849200.15568@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1208161618550.4850@kaball.uk.xensource.com>
	<1345131377-14713-6-git-send-email-stefano.stabellini@eu.citrix.com>
	<503BFCD8.5090804@gmail.com>
	<alpine.DEB.2.02.1208281823270.15568@kaball.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>,
	"linaro-dev@lists.linaro.org" <linaro-dev@lists.linaro.org>,
	Ian Campbell <Ian.Campbell@citrix.com>, "arnd@arndb.de" <arnd@arndb.de>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
	"catalin.marinas@arm.com" <catalin.marinas@arm.com>,
	"devicetree-discuss@lists.ozlabs.org"
	<devicetree-discuss@lists.ozlabs.org>, "Tim \(Xen.org\)" <tim@xen.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Rob Herring <robherring2@gmail.com>,
	David Vrabel <david.vrabel@citrix.com>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Xen-devel] [PATCH v3 06/25] docs: Xen ARM DT bindings
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 12 Sep 2012, Stefano Stabellini wrote:
> On Tue, 28 Aug 2012, Rob Herring wrote:
> > You should look at ePAPR 1.1 which defines hypervisor related bindings.
> > While it is a PPC doc, we should reuse or extend what makes sense.
> > 
> > See section 7.5:
> > 
> > https://www.power.org/resources/downloads/Power_ePAPR_APPROVED_v1.1.pdf
> 
> Thanks for the link, I wasn't aware of ePAPR.
> 
> The hypervisor node defined by ePAPR is not very different from what I
> am proposing. Should I try to be compatible with the hypervisor
> specification above (as in compatible = "epapr,hypervisor-1.1")?
> Or should I just use it as a reference for my own specification?
> 
> Personally I would rather avoid full compatibility with ePAPR.

In particular reading section 7.5, these are the required properties of
the ePAPR hypervisor node:

- compatible = "epapr,hypervisor-1.1"
compared to what I am proposing, it is laking information about what
hypervisor we are talking about (xen, kvm, vmware, etc) and the version
of the ABI (xen-4.2).

- hcall-instructions
potentially interesting, but given that for Xen we are quite happy with
HVC, we are not going to add any secondary hypercall mechanisms,
therefore at the moment it would just result in a BUG if the specified
hcall instruction is != HVC. Besides if somebody else wanted to
implemented the Xen hypercall interface in a different way they could
just reimplement the hypercall wrappers, that would be easier than
trying to do it with this property.

- guest-id
we usually make a point in trying not to tell the guest its own domid
because if the VM gets migrated to a different host it acquires a new
domid, therefore it should not rely on it.

- guest-name
we could pass the guest name here, but I don't see how it could be
of any use.



On the other hand, thinking more about what Xen needs in the device
tree, I think we could improve the current spec by clarifying the
meaning of the memory region and interrupt properties we currently
require. I thought about moving them to two separate children node with
an explicit name:

---

* Xen hypervisor device tree bindings

Xen ARM virtual platforms shall have the following properties and
children nodes:

- compatible property:
	compatible = "xen,xen", "xen,xen-<version>";
  where <version> is the version of the Xen ABI of the platform.

- grant_table child with the following properties:
    - name:
	    name = "grant_table";
	- reg: specifies the base physical address and size of a region in
	    memory where the grant table should be mapped to, using an
        HYPERVISOR_memory_op hypercall. 

- events child with the following properties:
    - name:
        name = "events";
	- interrupts: the interrupt used by Xen to inject event notifications.


Example:
hypervisor {
		compatible = "xen,xen", "xen,xen-4.2";
		#address-cells = <1>;
		#size-cells = <1>;
		#interrupt-cells = <3>;
		ranges = <0xb0000000 0xb0000000 0x20000>;

		grant_table {
			name = "grant_table";
			reg = <0xb0000000 0x20000>;
		};

		events {
			name = "events";
			interrupts = <1 15 0xf08>;
		};
	};

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 12 18:41:50 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Sep 2012 18:41:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TBrsQ-000331-K9; Wed, 12 Sep 2012 18:41:30 +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 1TBrsP-00032w-N1
	for xen-devel@lists.xen.org; Wed, 12 Sep 2012 18:41:29 +0000
Received: from [85.158.143.35:20927] by server-2.bemta-4.messagelabs.com id
	77/3B-21239-957D0505; Wed, 12 Sep 2012 18:41:29 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1347475287!17969263!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzM1ODI3\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19173 invoked from network); 12 Sep 2012 18:41:28 -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; 12 Sep 2012 18:41:28 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q8CIfMHO029430
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 12 Sep 2012 18:41:23 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
	q8CIfKXC027879
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 12 Sep 2012 18:41:21 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
	q8CIfJV8028358; Wed, 12 Sep 2012 13:41:19 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 12 Sep 2012 11:41:19 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id DB73F402EF; Wed, 12 Sep 2012 14:30:42 -0400 (EDT)
Date: Wed, 12 Sep 2012 14:30:42 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Andres Lagar-Cavilla <andreslc@gridcentric.ca>
Message-ID: <20120912183042.GA17321@phenom.dumpdata.com>
References: <1346086287-17674-1-git-send-email-andres@lagarcavilla.org>
	<5040CAEA.7000600@citrix.com>
	<160CC375-2682-4CBF-B1EC-06A9F3E49A40@gridcentric.ca>
	<A976B10C-58BE-4660-89E9-A8F85CAB5F19@gmail.com>
	<5040E210.2060702@citrix.com>
	<20120905162731.GD11949@phenom.dumpdata.com>
	<4FAD394B-6A6C-44F1-AF1C-DC2F935639EE@gmail.com>
	<6F1AF3C5-6A5B-4C60-BC7E-F4ED8DD954C4@gridcentric.ca>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <6F1AF3C5-6A5B-4C60-BC7E-F4ED8DD954C4@gridcentric.ca>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: xen-devel <xen-devel@lists.xen.org>, Ian Campbell <ian.campbell@citrix.com>,
	Andres Lagar-Cavilla <andres@lagarcavilla.org>,
	David Vrabel <david.vrabel@citrix.com>
Subject: Re: [Xen-devel] [PATCH] Xen backend support for paged out grant
 targets.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Sep 12, 2012 at 09:20:24AM -0400, Andres Lagar-Cavilla wrote:
> On Sep 5, 2012, at 1:21 PM, Andres Lagar-Cavilla wrote:
> 
> > 
> > On Sep 5, 2012, at 12:27 PM, Konrad Rzeszutek Wilk wrote:
> > 
> >> On Fri, Aug 31, 2012 at 05:10:56PM +0100, David Vrabel wrote:
> >>> On 31/08/12 16:42, Andres Lagar-Cavilla wrote:
> >>>> Actually acted upon your feedback ipso facto:
> >>>> 
> >>>> commit d5fab912caa1f0cf6be0a6773f502d3417a207b6
> >>>> Author: Andres Lagar-Cavilla <andres@lagarcavilla.org>
> >>>> Date:   Sun Aug 26 09:45:57 2012 -0400
> >>>> 
> >>>>   Xen backend support for paged out grant targets.
> >>> 
> >>> This looks mostly fine expect for the #define instead of inline functions.
> >>> 
> >>>> +#define gnttab_map_grant_no_eagain(_gop)                                    \
> >>> 
> >>> This name tripped me up previously. As I read this as:
> >>> 
> >>> gnttab_map_grant_no_[retries_for]_eagain().
> >>> 
> >>> Perhaps gnttab_map_grant_with_retries() ? Or similar?
> >> 
> >> gnttab_map_grant_retry ?
> >> 
> >> Besides that, it looks good to me. Ian Campbell needs to Ack so that
> >> David Miller (the network maintainer) can pick it up. Please CC them
> >> both and also LKML
> Konrad, Ian, can I get some insight on the question I pose below. I have otherwise cleaned up the patch for 3.7.

Can you re-send a cleanup patch and CC the relevant folks pls.

> 
> Thanks
> Andres
> >> .
> > 
> > Sure will do. However, I need to bring attention to the following hunk:
> > diff --git a/drivers/net/xen-netback/netback.c b/drivers/net/xen-netback/netback.c
> > index 682633b..5610fd8 100644
> > --- a/drivers/net/xen-netback/netback.c
> > +++ b/drivers/net/xen-netback/netback.c
> > @@ -635,9 +635,7 @@ static void xen_netbk_rx_action(struct xen_netbk *netbk)
> > 		return;
> > 
> > 	BUG_ON(npo.copy_prod > ARRAY_SIZE(netbk->grant_copy_op));
> > -	ret = HYPERVISOR_grant_table_op(GNTTABOP_copy, &netbk->grant_copy_op,
> > -					npo.copy_prod);
> > -	BUG_ON(ret != 0);
> > +	gnttab_batch_copy_no_eagain(netbk->grant_copy_op, npo.copy_prod);
> > 
> > It seems like the (extant) code passes a struct gnttab_copy ** to the grant table hypercall (&netbk->grant_copy_op, defined as struct gnttab_copy [])
> > 
> > I "fixed" it to pass a struct gnttab_copy * (netbk->grant_copy_op, no '&'). This matches the other invocation of the grant copy hyper call (in netbk_tx_action). Did I fix it, though? I am confused as to how this could have ever worked.
> > 
> > (cc'ing Ian Campbell for more insight) 
> > Andres
> >>> 
> >>> David
> > 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 12 18:41:50 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Sep 2012 18:41:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TBrsQ-000331-K9; Wed, 12 Sep 2012 18:41:30 +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 1TBrsP-00032w-N1
	for xen-devel@lists.xen.org; Wed, 12 Sep 2012 18:41:29 +0000
Received: from [85.158.143.35:20927] by server-2.bemta-4.messagelabs.com id
	77/3B-21239-957D0505; Wed, 12 Sep 2012 18:41:29 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1347475287!17969263!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzM1ODI3\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19173 invoked from network); 12 Sep 2012 18:41:28 -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; 12 Sep 2012 18:41:28 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q8CIfMHO029430
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 12 Sep 2012 18:41:23 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
	q8CIfKXC027879
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 12 Sep 2012 18:41:21 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
	q8CIfJV8028358; Wed, 12 Sep 2012 13:41:19 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 12 Sep 2012 11:41:19 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id DB73F402EF; Wed, 12 Sep 2012 14:30:42 -0400 (EDT)
Date: Wed, 12 Sep 2012 14:30:42 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Andres Lagar-Cavilla <andreslc@gridcentric.ca>
Message-ID: <20120912183042.GA17321@phenom.dumpdata.com>
References: <1346086287-17674-1-git-send-email-andres@lagarcavilla.org>
	<5040CAEA.7000600@citrix.com>
	<160CC375-2682-4CBF-B1EC-06A9F3E49A40@gridcentric.ca>
	<A976B10C-58BE-4660-89E9-A8F85CAB5F19@gmail.com>
	<5040E210.2060702@citrix.com>
	<20120905162731.GD11949@phenom.dumpdata.com>
	<4FAD394B-6A6C-44F1-AF1C-DC2F935639EE@gmail.com>
	<6F1AF3C5-6A5B-4C60-BC7E-F4ED8DD954C4@gridcentric.ca>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <6F1AF3C5-6A5B-4C60-BC7E-F4ED8DD954C4@gridcentric.ca>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: xen-devel <xen-devel@lists.xen.org>, Ian Campbell <ian.campbell@citrix.com>,
	Andres Lagar-Cavilla <andres@lagarcavilla.org>,
	David Vrabel <david.vrabel@citrix.com>
Subject: Re: [Xen-devel] [PATCH] Xen backend support for paged out grant
 targets.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Sep 12, 2012 at 09:20:24AM -0400, Andres Lagar-Cavilla wrote:
> On Sep 5, 2012, at 1:21 PM, Andres Lagar-Cavilla wrote:
> 
> > 
> > On Sep 5, 2012, at 12:27 PM, Konrad Rzeszutek Wilk wrote:
> > 
> >> On Fri, Aug 31, 2012 at 05:10:56PM +0100, David Vrabel wrote:
> >>> On 31/08/12 16:42, Andres Lagar-Cavilla wrote:
> >>>> Actually acted upon your feedback ipso facto:
> >>>> 
> >>>> commit d5fab912caa1f0cf6be0a6773f502d3417a207b6
> >>>> Author: Andres Lagar-Cavilla <andres@lagarcavilla.org>
> >>>> Date:   Sun Aug 26 09:45:57 2012 -0400
> >>>> 
> >>>>   Xen backend support for paged out grant targets.
> >>> 
> >>> This looks mostly fine expect for the #define instead of inline functions.
> >>> 
> >>>> +#define gnttab_map_grant_no_eagain(_gop)                                    \
> >>> 
> >>> This name tripped me up previously. As I read this as:
> >>> 
> >>> gnttab_map_grant_no_[retries_for]_eagain().
> >>> 
> >>> Perhaps gnttab_map_grant_with_retries() ? Or similar?
> >> 
> >> gnttab_map_grant_retry ?
> >> 
> >> Besides that, it looks good to me. Ian Campbell needs to Ack so that
> >> David Miller (the network maintainer) can pick it up. Please CC them
> >> both and also LKML
> Konrad, Ian, can I get some insight on the question I pose below. I have otherwise cleaned up the patch for 3.7.

Can you re-send a cleanup patch and CC the relevant folks pls.

> 
> Thanks
> Andres
> >> .
> > 
> > Sure will do. However, I need to bring attention to the following hunk:
> > diff --git a/drivers/net/xen-netback/netback.c b/drivers/net/xen-netback/netback.c
> > index 682633b..5610fd8 100644
> > --- a/drivers/net/xen-netback/netback.c
> > +++ b/drivers/net/xen-netback/netback.c
> > @@ -635,9 +635,7 @@ static void xen_netbk_rx_action(struct xen_netbk *netbk)
> > 		return;
> > 
> > 	BUG_ON(npo.copy_prod > ARRAY_SIZE(netbk->grant_copy_op));
> > -	ret = HYPERVISOR_grant_table_op(GNTTABOP_copy, &netbk->grant_copy_op,
> > -					npo.copy_prod);
> > -	BUG_ON(ret != 0);
> > +	gnttab_batch_copy_no_eagain(netbk->grant_copy_op, npo.copy_prod);
> > 
> > It seems like the (extant) code passes a struct gnttab_copy ** to the grant table hypercall (&netbk->grant_copy_op, defined as struct gnttab_copy [])
> > 
> > I "fixed" it to pass a struct gnttab_copy * (netbk->grant_copy_op, no '&'). This matches the other invocation of the grant copy hyper call (in netbk_tx_action). Did I fix it, though? I am confused as to how this could have ever worked.
> > 
> > (cc'ing Ian Campbell for more insight) 
> > Andres
> >>> 
> >>> David
> > 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 12 19:33:21 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Sep 2012 19: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 1TBsgA-0003PH-1L; Wed, 12 Sep 2012 19:32:54 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mukesh.rathor@oracle.com>) id 1TBsg8-0003PC-Ft
	for Xen-devel@lists.xensource.com; Wed, 12 Sep 2012 19:32:52 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1347478362!5599124!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzM1ODI3\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26969 invoked from network); 12 Sep 2012 19:32:44 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-10.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 12 Sep 2012 19:32:44 -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 q8CJWea6018044
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 12 Sep 2012 19:32:40 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
	q8CJWdXb023670
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 12 Sep 2012 19:32:40 GMT
Received: from abhmt102.oracle.com (abhmt102.oracle.com [141.146.116.54])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q8CJWdJi023888; Wed, 12 Sep 2012 14:32:39 -0500
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 12 Sep 2012 12:32:39 -0700
Date: Wed, 12 Sep 2012 12:32:38 -0700
From: Mukesh Rathor <mukesh.rathor@oracle.com>
To: Ian Campbell <Ian.Campbell@citrix.com>, "Xen-devel@lists.xensource.com"
	<Xen-devel@lists.xensource.com>
Message-ID: <20120912123238.7057c51a@mantra.us.oracle.com>
In-Reply-To: <1347474380.25803.21.camel@dagon.hellion.org.uk>
References: <20120815175724.3405043a@mantra.us.oracle.com>
	<1347285352.5305.86.camel@zakaz.uk.xensource.com>
	<20120911145751.599b8292@mantra.us.oracle.com>
	<1347437545.25803.16.camel@dagon.hellion.org.uk>
	<20120912110254.10bde333@mantra.us.oracle.com>
	<1347474380.25803.21.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: acsinet22.oracle.com [141.146.126.238]
Subject: Re: [Xen-devel] [RFC PATCH 1/8]: PVH: Basic and preparatory changes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 12 Sep 2012 19:26:20 +0100
Ian Campbell <Ian.Campbell@citrix.com> wrote:

> On Wed, 2012-09-12 at 19:02 +0100, Mukesh Rathor wrote:
> > On Wed, 12 Sep 2012 09:12:25 +0100
> > Ian Campbell <Ian.Campbell@citrix.com> wrote:
> > 
> > > On Tue, 2012-09-11 at 22:57 +0100, Mukesh Rathor wrote:
> > > > On Mon, 10 Sep 2012 14:55:52 +0100
> > > > Ian Campbell <Ian.Campbell@citrix.com> wrote:
> > > It would likely be sufficient to just ifdef the bit which tells
> > > the builder that this kernel image supports PVH, which I guess is
> > > one or more XENFEATs in arch/x86/xen/xen-head.S?
> > > 
> > Nop, I've not added any new bits. Just using existing bits:
> > 
> > XENFEAT_writable_page_tables
> > XENFEAT_auto_translated_physmap
> > XENFEAT_supervisor_mode_kernel
> 
> Currently we declare:
>         ELFNOTE(Xen, XEN_ELFNOTE_FEATURES,       .asciz
> "!writable_page_tables|pae_pgdir_above_4gb")
> 
> It might be a mistake for writable_page_tables to be there already but
> in any case when you add the other two you should gate them on this
> new option.
> 
> (nb: "!foo" means "foo is required" rather than "not foo". I chose a
> very confusing character for this!)
> 
> It may also be worth having a XENFEAT_pvh for us in communicating
> support for this feature from the kernel to the tools (like
> XENFEAT_dom0). That's the opposite of case we wanted to avoid
> (enabling behaviour in the kernel).

Well, the way I have it is, it's the PV binary. To boot in PVH mode, you
put pvh=1 in vm.cfg file. The tool stacks read it and tell xen via
new flag XEN_DOMCTL_CDF_hybrid_guest. Err, make that _pvh_guest.
xen sets the new is_pvh bit in struct domain. The PVH guest upon boot
does xen_setup_features() first thing. xen sends it:

> XENFEAT_writable_page_tables
> XENFEAT_auto_translated_physmap
> XENFEAT_supervisor_mode_kernel
 
that with callback vector makes it a PVH guest. 

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 Sep 12 19:33:21 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Sep 2012 19: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 1TBsgA-0003PH-1L; Wed, 12 Sep 2012 19:32:54 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mukesh.rathor@oracle.com>) id 1TBsg8-0003PC-Ft
	for Xen-devel@lists.xensource.com; Wed, 12 Sep 2012 19:32:52 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1347478362!5599124!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzM1ODI3\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26969 invoked from network); 12 Sep 2012 19:32:44 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-10.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 12 Sep 2012 19:32:44 -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 q8CJWea6018044
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 12 Sep 2012 19:32:40 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
	q8CJWdXb023670
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 12 Sep 2012 19:32:40 GMT
Received: from abhmt102.oracle.com (abhmt102.oracle.com [141.146.116.54])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q8CJWdJi023888; Wed, 12 Sep 2012 14:32:39 -0500
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 12 Sep 2012 12:32:39 -0700
Date: Wed, 12 Sep 2012 12:32:38 -0700
From: Mukesh Rathor <mukesh.rathor@oracle.com>
To: Ian Campbell <Ian.Campbell@citrix.com>, "Xen-devel@lists.xensource.com"
	<Xen-devel@lists.xensource.com>
Message-ID: <20120912123238.7057c51a@mantra.us.oracle.com>
In-Reply-To: <1347474380.25803.21.camel@dagon.hellion.org.uk>
References: <20120815175724.3405043a@mantra.us.oracle.com>
	<1347285352.5305.86.camel@zakaz.uk.xensource.com>
	<20120911145751.599b8292@mantra.us.oracle.com>
	<1347437545.25803.16.camel@dagon.hellion.org.uk>
	<20120912110254.10bde333@mantra.us.oracle.com>
	<1347474380.25803.21.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: acsinet22.oracle.com [141.146.126.238]
Subject: Re: [Xen-devel] [RFC PATCH 1/8]: PVH: Basic and preparatory changes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 12 Sep 2012 19:26:20 +0100
Ian Campbell <Ian.Campbell@citrix.com> wrote:

> On Wed, 2012-09-12 at 19:02 +0100, Mukesh Rathor wrote:
> > On Wed, 12 Sep 2012 09:12:25 +0100
> > Ian Campbell <Ian.Campbell@citrix.com> wrote:
> > 
> > > On Tue, 2012-09-11 at 22:57 +0100, Mukesh Rathor wrote:
> > > > On Mon, 10 Sep 2012 14:55:52 +0100
> > > > Ian Campbell <Ian.Campbell@citrix.com> wrote:
> > > It would likely be sufficient to just ifdef the bit which tells
> > > the builder that this kernel image supports PVH, which I guess is
> > > one or more XENFEATs in arch/x86/xen/xen-head.S?
> > > 
> > Nop, I've not added any new bits. Just using existing bits:
> > 
> > XENFEAT_writable_page_tables
> > XENFEAT_auto_translated_physmap
> > XENFEAT_supervisor_mode_kernel
> 
> Currently we declare:
>         ELFNOTE(Xen, XEN_ELFNOTE_FEATURES,       .asciz
> "!writable_page_tables|pae_pgdir_above_4gb")
> 
> It might be a mistake for writable_page_tables to be there already but
> in any case when you add the other two you should gate them on this
> new option.
> 
> (nb: "!foo" means "foo is required" rather than "not foo". I chose a
> very confusing character for this!)
> 
> It may also be worth having a XENFEAT_pvh for us in communicating
> support for this feature from the kernel to the tools (like
> XENFEAT_dom0). That's the opposite of case we wanted to avoid
> (enabling behaviour in the kernel).

Well, the way I have it is, it's the PV binary. To boot in PVH mode, you
put pvh=1 in vm.cfg file. The tool stacks read it and tell xen via
new flag XEN_DOMCTL_CDF_hybrid_guest. Err, make that _pvh_guest.
xen sets the new is_pvh bit in struct domain. The PVH guest upon boot
does xen_setup_features() first thing. xen sends it:

> XENFEAT_writable_page_tables
> XENFEAT_auto_translated_physmap
> XENFEAT_supervisor_mode_kernel
 
that with callback vector makes it a PVH guest. 

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 Sep 12 23:03:48 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Sep 2012 23:03:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TBvxl-0005uL-NQ; Wed, 12 Sep 2012 23:03:17 +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 1TBvxk-0005uG-5Q
	for xen-devel@lists.xensource.com; Wed, 12 Sep 2012 23:03:16 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1347490990!10803442!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDg4Njg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31748 invoked from network); 12 Sep 2012 23:03:10 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Sep 2012 23:03:10 -0000
X-IronPort-AV: E=Sophos;i="4.80,413,1344211200"; d="scan'208";a="14506725"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Sep 2012 23:02: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.279.1; Thu, 13 Sep 2012 00:02: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 1TBvxP-0004vn-So;
	Wed, 12 Sep 2012 23:02:55 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1TBvxP-0008Uo-Li;
	Thu, 13 Sep 2012 00:02:55 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-13698-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 13 Sep 2012 00:02:55 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.0-testing test] 13698: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 13698 xen-4.0-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13698/

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. 13650

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-xl-credit2    5 xen-boot                     fail   like 13650

Tests which did not succeed, but are not blocking:
 test-amd64-i386-xl-multivcpu 15 guest-stop                   fail   never pass
 test-amd64-amd64-xl-pcipt-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl           15 guest-stop                   fail   never pass
 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-pv           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  7 redhat-install           fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  7 redhat-install         fail never pass
 test-amd64-amd64-xl-sedf      1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-win7-amd64  8 guest-saverestore            fail  never pass
 test-amd64-amd64-pair         1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 xen-build-check(1)         blocked n/a
 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-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-rhel6hvm-intel  7 redhat-install               fail never pass
 test-amd64-i386-rhel6hvm-amd  7 redhat-install               fail   never pass
 test-i386-i386-xl            15 guest-stop                   fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-win          1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-winxpsp3-vcpus1  7 windows-install          fail never pass
 test-amd64-amd64-xl-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-win-vcpus1  7 windows-install              fail  never pass
 test-amd64-amd64-xl-win       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         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

version targeted for testing:
 xen                  1d1538beeada
baseline version:
 xen                  79444af3258c

------------------------------------------------------------
People who touched revisions under test:
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            fail    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          blocked 
 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                         blocked 
 test-amd64-amd64-xl-win7-amd64                               blocked 
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   fail    
 test-amd64-amd64-xl-pcipt-intel                              blocked 
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 fail    
 test-amd64-amd64-pair                                        blocked 
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 blocked 
 test-amd64-amd64-pv                                          blocked 
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     blocked 
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         blocked 
 test-amd64-i386-win                                          fail    
 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                                fail    
 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.

------------------------------------------------------------
changeset:   21617:1d1538beeada
tag:         tip
user:        Ian Jackson <Ian.Jackson@eu.citrix.com>
date:        Wed Sep 12 11:18:03 2012 +0100
    
    QEMU_TAG fix to refer to correct tree
    
    
changeset:   21616:512168f88df9
user:        Ian Jackson <Ian.Jackson@eu.citrix.com>
date:        Tue Sep 11 14:35:26 2012 +0100
    
    QEMU_TAG update
    
    
changeset:   21615:79444af3258c
user:        Ian Jackson <Ian.Jackson@eu.citrix.com>
date:        Wed Sep 05 12:40:12 2012 +0100
    
    QEMU_TAG update (XSA-17 / CVE-2012-3515)
    
    
(qemu changes not included)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 12 23:03:48 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 12 Sep 2012 23:03:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TBvxl-0005uL-NQ; Wed, 12 Sep 2012 23:03:17 +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 1TBvxk-0005uG-5Q
	for xen-devel@lists.xensource.com; Wed, 12 Sep 2012 23:03:16 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1347490990!10803442!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDg4Njg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31748 invoked from network); 12 Sep 2012 23:03:10 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Sep 2012 23:03:10 -0000
X-IronPort-AV: E=Sophos;i="4.80,413,1344211200"; d="scan'208";a="14506725"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Sep 2012 23:02: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.279.1; Thu, 13 Sep 2012 00:02: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 1TBvxP-0004vn-So;
	Wed, 12 Sep 2012 23:02:55 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1TBvxP-0008Uo-Li;
	Thu, 13 Sep 2012 00:02:55 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-13698-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 13 Sep 2012 00:02:55 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.0-testing test] 13698: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 13698 xen-4.0-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13698/

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. 13650

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-xl-credit2    5 xen-boot                     fail   like 13650

Tests which did not succeed, but are not blocking:
 test-amd64-i386-xl-multivcpu 15 guest-stop                   fail   never pass
 test-amd64-amd64-xl-pcipt-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl           15 guest-stop                   fail   never pass
 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-pv           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  7 redhat-install           fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  7 redhat-install         fail never pass
 test-amd64-amd64-xl-sedf      1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-win7-amd64  8 guest-saverestore            fail  never pass
 test-amd64-amd64-pair         1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 xen-build-check(1)         blocked n/a
 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-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-rhel6hvm-intel  7 redhat-install               fail never pass
 test-amd64-i386-rhel6hvm-amd  7 redhat-install               fail   never pass
 test-i386-i386-xl            15 guest-stop                   fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-win          1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-winxpsp3-vcpus1  7 windows-install          fail never pass
 test-amd64-amd64-xl-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-win-vcpus1  7 windows-install              fail  never pass
 test-amd64-amd64-xl-win       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         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

version targeted for testing:
 xen                  1d1538beeada
baseline version:
 xen                  79444af3258c

------------------------------------------------------------
People who touched revisions under test:
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            fail    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          blocked 
 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                         blocked 
 test-amd64-amd64-xl-win7-amd64                               blocked 
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   fail    
 test-amd64-amd64-xl-pcipt-intel                              blocked 
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 fail    
 test-amd64-amd64-pair                                        blocked 
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 blocked 
 test-amd64-amd64-pv                                          blocked 
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     blocked 
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         blocked 
 test-amd64-i386-win                                          fail    
 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                                fail    
 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.

------------------------------------------------------------
changeset:   21617:1d1538beeada
tag:         tip
user:        Ian Jackson <Ian.Jackson@eu.citrix.com>
date:        Wed Sep 12 11:18:03 2012 +0100
    
    QEMU_TAG fix to refer to correct tree
    
    
changeset:   21616:512168f88df9
user:        Ian Jackson <Ian.Jackson@eu.citrix.com>
date:        Tue Sep 11 14:35:26 2012 +0100
    
    QEMU_TAG update
    
    
changeset:   21615:79444af3258c
user:        Ian Jackson <Ian.Jackson@eu.citrix.com>
date:        Wed Sep 05 12:40:12 2012 +0100
    
    QEMU_TAG update (XSA-17 / CVE-2012-3515)
    
    
(qemu changes not included)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 13 01:19:51 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Sep 2012 01:19:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TBy5T-0002Sm-8i; Thu, 13 Sep 2012 01:19: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 1TBy5Q-0002Sh-MU
	for Xen-devel@lists.xensource.com; Thu, 13 Sep 2012 01:19:21 +0000
Received: from [85.158.143.99:31556] by server-1.bemta-4.messagelabs.com id
	96/DD-12504-79431505; Thu, 13 Sep 2012 01:19:19 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1347499157!30052064!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzM3MjU3\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31406 invoked from network); 13 Sep 2012 01:19:18 -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; 13 Sep 2012 01:19:18 -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 q8D1JEEW028339
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 13 Sep 2012 01:19: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
	q8D1JDp7004476
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 13 Sep 2012 01:19:14 GMT
Received: from abhmt104.oracle.com (abhmt104.oracle.com [141.146.116.56])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q8D1JDus032643; Wed, 12 Sep 2012 20:19:13 -0500
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 12 Sep 2012 18:19:12 -0700
Date: Wed, 12 Sep 2012 18:19:10 -0700
From: Mukesh Rathor <mukesh.rathor@oracle.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120912181910.6b0b9d2b@mantra.us.oracle.com>
In-Reply-To: <1347372623.5305.170.camel@zakaz.uk.xensource.com>
References: <20120815180716.0049bffe@mantra.us.oracle.com>
	<1347372623.5305.170.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_/VbujuzxBRJmnncQgGTu8kEI"
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: "Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [RFC PATCH 8/8]: PVH: privcmd 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>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--MP_/VbujuzxBRJmnncQgGTu8kEI
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

On Tue, 11 Sep 2012 15:10:23 +0100
Ian Campbell <Ian.Campbell@citrix.com> wrote:

> I think you can't rely on the implicit teardown here since you need to
> unmap before you hand the page back to the balloon. The reason this
> doesn't look necessary now is that you don't give the page back.
> Also not ordering the stage 1 and stage 2 teardown correctly is
> dangerous, depending on the eventual ordering you potentially turn an
> erroneous access to a virtual address, which should result in a guest
> OS level page fault (and e.g. a seg fault to the offending process)
> into a hypervisor shoots the guest due to an unexpected stage 2 fault
> type failure, which is somewhat undesirable ;-)
> 
> With that in mind I think you do in the end need to add
> xen_unmap_domain_mfn_range which does the unmap from both stage 1 and
> stage 2 -- that balances out the interface (making pvh_rem_xen_p2m
> internal) too, which is nice. This function may turn out to be a nop
> on !pvh, but that's ok (although maybe there would be no harm in doing
> explicit unmaps, for consistency?).
 
Ok, I added xen_unmap_domain_mfn_range(). Take a look. It appears that
by the time privcmd_close() is called, the kernel has already freed 
process resources and lookup_address() returns NULL. Now I am wondering
if the kernel/mmu does anything to the page while shooting the pte
entry. Well the page was orig from balloon, so the cleanup hopefully
leaves it alone.

I had looked for other hooks initially when I did this, but 
vm_operations_struct->close was the only one to pan out.

I can't really move pvh_privcmd_resv_pfns to mmu.c because the 
xen_remap_domain_mfn_range is called one page at a time, and I need
to allocate the array first. I'd have to change it to linked list, worth
it? Or I'd have to move and export it.


> WRT passing data between interfaces in vma->vm_private, which is
> pretty subtle, can we push that whole thing down into
> xen_{remap,unmap}_domain_mfn_range too? This would make the
> requirement on the caller be simple "never use vm_private", as
> opposed to now where the requirement is "sometimes you might have to
> allocate some stuff and stick it in here". The downside is that it
> pushes code which could be generic down into per-arch stuff, although
> with suitable generic helper functions this isn't so bad (whatever
> happened to {alloc,free}_empty_pages_and_pagevec from the classic
> kernels? Those did exactly what we want here, I think)

Well, it has to hang off of vma->vm_private. The alternative would be to
have a hash table by process id or something, again not sure if worth it. 

Take a look at my latest files attached. Now the alloc_balloon and free
are split between privcmd and mmu.c. The alternative would be to call 
xen_unmap_domain_mfn_range one pfn at a time and have it call 
pvh_rem_xen_p2m(), and move free_xenballooned_pages to privcmd. But
that would be same as just changing the name of pvh_rem_xen_p2m to
xen_unmap_domain_mfn_range(). Also, remap and unmap won't be much
symmetric then.

Not sure if there's a lot we could do here to be honest. LMK what you 
think.

thanks,
Mukesh


--MP_/VbujuzxBRJmnncQgGTu8kEI
Content-Type: text/x-c++src
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename=privcmd.c

/******************************************************************************
 * privcmd.c
 *
 * Interface to privileged domain-0 commands.
 *
 * Copyright (c) 2002-2004, K A Fraser, B Dragovic
 */

#include <linux/kernel.h>
#include <linux/module.h>
#include <linux/sched.h>
#include <linux/slab.h>
#include <linux/string.h>
#include <linux/errno.h>
#include <linux/mm.h>
#include <linux/mman.h>
#include <linux/uaccess.h>
#include <linux/swap.h>
#include <linux/highmem.h>
#include <linux/pagemap.h>
#include <linux/seq_file.h>
#include <linux/miscdevice.h>

#include <asm/pgalloc.h>
#include <asm/pgtable.h>
#include <asm/tlb.h>
#include <asm/xen/hypervisor.h>
#include <asm/xen/hypercall.h>

#include <xen/xen.h>
#include <xen/privcmd.h>
#include <xen/interface/xen.h>
#include <xen/features.h>
#include <xen/page.h>
#include <xen/xen-ops.h>
#include <xen/balloon.h>

#include "privcmd.h"

MODULE_LICENSE("GPL");

#ifndef HAVE_ARCH_PRIVCMD_MMAP
static int privcmd_enforce_singleshot_mapping(struct vm_area_struct *vma);
#endif

static long privcmd_ioctl_hypercall(void __user *udata)
{
	struct privcmd_hypercall hypercall;
	long ret;

	if (copy_from_user(&hypercall, udata, sizeof(hypercall)))
		return -EFAULT;

	ret = privcmd_call(hypercall.op,
			   hypercall.arg[0], hypercall.arg[1],
			   hypercall.arg[2], hypercall.arg[3],
			   hypercall.arg[4]);

	return ret;
}

static void free_page_list(struct list_head *pages)
{
	struct page *p, *n;

	list_for_each_entry_safe(p, n, pages, lru)
		__free_page(p);

	INIT_LIST_HEAD(pages);
}

/*
 * Given an array of items in userspace, return a list of pages
 * containing the data.  If copying fails, either because of memory
 * allocation failure or a problem reading user memory, return an
 * error code; its up to the caller to dispose of any partial list.
 */
static int gather_array(struct list_head *pagelist,
			unsigned nelem, size_t size,
			void __user *data)
{
	unsigned pageidx;
	void *pagedata;
	int ret;

	if (size > PAGE_SIZE)
		return 0;

	pageidx = PAGE_SIZE;
	pagedata = NULL;	/* quiet, gcc */
	while (nelem--) {
		if (pageidx > PAGE_SIZE-size) {
			struct page *page = alloc_page(GFP_KERNEL);

			ret = -ENOMEM;
			if (page == NULL)
				goto fail;

			pagedata = page_address(page);

			list_add_tail(&page->lru, pagelist);
			pageidx = 0;
		}

		ret = -EFAULT;
		if (copy_from_user(pagedata + pageidx, data, size))
			goto fail;

		data += size;
		pageidx += size;
	}

	ret = 0;

fail:
	return ret;
}

/*
 * Call function "fn" on each element of the array fragmented
 * over a list of pages.
 */
static int traverse_pages(unsigned nelem, size_t size,
			  struct list_head *pos,
			  int (*fn)(void *data, void *state),
			  void *state)
{
	void *pagedata;
	unsigned pageidx;
	int ret = 0;

	BUG_ON(size > PAGE_SIZE);

	pageidx = PAGE_SIZE;
	pagedata = NULL;	/* hush, gcc */

	while (nelem--) {
		if (pageidx > PAGE_SIZE-size) {
			struct page *page;
			pos = pos->next;
			page = list_entry(pos, struct page, lru);
			pagedata = page_address(page);
			pageidx = 0;
		}

		ret = (*fn)(pagedata + pageidx, state);
		if (ret)
			break;
		pageidx += size;
	}

	return ret;
}

struct mmap_mfn_state {
	unsigned long va;
	struct vm_area_struct *vma;
	domid_t domain;
};

static int mmap_mfn_range(void *data, void *state)
{
	struct privcmd_mmap_entry *msg = data;
	struct mmap_mfn_state *st = state;
	struct vm_area_struct *vma = st->vma;
	int rc;

	/* Do not allow range to wrap the address space. */
	if ((msg->npages > (LONG_MAX >> PAGE_SHIFT)) ||
	    ((unsigned long)(msg->npages << PAGE_SHIFT) >= -st->va))
		return -EINVAL;

	/* Range chunks must be contiguous in va space. */
	if ((msg->va != st->va) ||
	    ((msg->va+(msg->npages<<PAGE_SHIFT)) > vma->vm_end))
		return -EINVAL;

	rc = xen_remap_domain_mfn_range(vma,
					msg->va & PAGE_MASK,
					msg->mfn, msg->npages,
					vma->vm_page_prot,
					st->domain);
	if (rc < 0)
		return rc;

	st->va += msg->npages << PAGE_SHIFT;

	return 0;
}

static long privcmd_ioctl_mmap(void __user *udata)
{
	struct privcmd_mmap mmapcmd;
	struct mm_struct *mm = current->mm;
	struct vm_area_struct *vma;
	int rc;
	LIST_HEAD(pagelist);
	struct mmap_mfn_state state;

	if (!xen_initial_domain())
		return -EPERM;

	/* PVH: TBD/FIXME. For now we only support privcmd_ioctl_mmap_batch */
	if (xen_pv_domain() && xen_feature(XENFEAT_auto_translated_physmap))
		return -ENOSYS;

	if (copy_from_user(&mmapcmd, udata, sizeof(mmapcmd)))
		return -EFAULT;

	rc = gather_array(&pagelist,
			  mmapcmd.num, sizeof(struct privcmd_mmap_entry),
			  mmapcmd.entry);

	if (rc || list_empty(&pagelist))
		goto out;

	down_write(&mm->mmap_sem);

	{
		struct page *page = list_first_entry(&pagelist,
						     struct page, lru);
		struct privcmd_mmap_entry *msg = page_address(page);

		vma = find_vma(mm, msg->va);
		rc = -EINVAL;

		if (!vma || (msg->va != vma->vm_start) ||
		    !privcmd_enforce_singleshot_mapping(vma))
			goto out_up;
	}

	state.va = vma->vm_start;
	state.vma = vma;
	state.domain = mmapcmd.dom;

	rc = traverse_pages(mmapcmd.num, sizeof(struct privcmd_mmap_entry),
			    &pagelist,
			    mmap_mfn_range, &state);


out_up:
	up_write(&mm->mmap_sem);

out:
	free_page_list(&pagelist);

	return rc;
}

struct mmap_batch_state {
	domid_t domain;
	unsigned long va;
	struct vm_area_struct *vma;
	int err;

	xen_pfn_t __user *user;
};

/* PVH dom0 fyi: if domU being created is PV, then mfn is mfn(addr on bus). If 
 * it's PVH then mfn is pfn (input to HAP). */
static int mmap_batch_fn(void *data, void *state)
{
	xen_pfn_t *mfnp = data;
	struct mmap_batch_state *st = state;

	if (xen_remap_domain_mfn_range(st->vma, st->va & PAGE_MASK, *mfnp, 1,
				       st->vma->vm_page_prot, st->domain) < 0) {
		*mfnp |= 0xf0000000U;
		st->err++;
	}
	st->va += PAGE_SIZE;

	return 0;
}

static int mmap_return_errors(void *data, void *state)
{
	xen_pfn_t *mfnp = data;
	struct mmap_batch_state *st = state;

	return put_user(*mfnp, st->user++);
}

/* Allocate pfns that are then mapped with gmfns from foreign domid. Update
 * the vma with the page info to use later.
 * Returns: 0 if success, otherwise -errno
 */ 
static int pvh_privcmd_resv_pfns(struct vm_area_struct *vma, int numpgs)
{
	int rc;
	struct xen_pvh_sav_pfn_info *savp;

	savp = kzalloc(sizeof(struct xen_pvh_sav_pfn_info), GFP_KERNEL);
	if (savp == NULL)
		return -ENOMEM;

	savp->sp_paga = kcalloc(numpgs, sizeof(savp->sp_paga[0]), GFP_KERNEL);
	if (savp->sp_paga == NULL) {
		kfree(savp);
		return -ENOMEM;
	}

	rc = alloc_xenballooned_pages(numpgs, savp->sp_paga, 0);
	if (rc != 0) {
		pr_warn("%s Could not alloc %d pfns rc:%d\n", __FUNCTION__, 
			numpgs, rc);
		kfree(savp->sp_paga);
		kfree(savp);
		return -ENOMEM;
	}
	savp->sp_num_pgs = numpgs;
	BUG_ON(vma->vm_private_data);
	vma->vm_private_data = savp;

	return 0;
}

static struct vm_operations_struct privcmd_vm_ops;

static long privcmd_ioctl_mmap_batch(void __user *udata)
{
	int ret;
	struct privcmd_mmapbatch m;
	struct mm_struct *mm = current->mm;
	struct vm_area_struct *vma;
	unsigned long nr_pages;
	LIST_HEAD(pagelist);
	struct mmap_batch_state state;

	if (!xen_initial_domain())
		return -EPERM;

	if (copy_from_user(&m, udata, sizeof(m)))
		return -EFAULT;

	nr_pages = m.num;
	if ((m.num <= 0) || (nr_pages > (LONG_MAX >> PAGE_SHIFT)))
		return -EINVAL;

	ret = gather_array(&pagelist, m.num, sizeof(xen_pfn_t),
			   m.arr);

	if (ret || list_empty(&pagelist))
		goto out;

	down_write(&mm->mmap_sem);

	vma = find_vma(mm, m.addr);
	ret = -EINVAL;
	if (!vma ||
	    vma->vm_ops != &privcmd_vm_ops ||
	    (m.addr != vma->vm_start) ||
	    ((m.addr + (nr_pages << PAGE_SHIFT)) != vma->vm_end) ||
	    !privcmd_enforce_singleshot_mapping(vma)) {
		up_write(&mm->mmap_sem);
		goto out;
	}

	if (xen_pv_domain() && xen_feature(XENFEAT_auto_translated_physmap)) {
		if ((ret=pvh_privcmd_resv_pfns(vma, m.num))) {
			up_write(&mm->mmap_sem);
			goto out;
		}
	}
	state.domain = m.dom;
	state.vma = vma;
	state.va = m.addr;
	state.err = 0;

	ret = traverse_pages(m.num, sizeof(xen_pfn_t),
			     &pagelist, mmap_batch_fn, &state);

	up_write(&mm->mmap_sem);

	if (state.err > 0) {
		state.user = m.arr;
		ret = traverse_pages(m.num, sizeof(xen_pfn_t),
			       &pagelist,
			       mmap_return_errors, &state);
	}

out:
	free_page_list(&pagelist);

	return ret;
}

static long privcmd_ioctl(struct file *file,
			  unsigned int cmd, unsigned long data)
{
	int ret = -ENOSYS;
	void __user *udata = (void __user *) data;

	switch (cmd) {
	case IOCTL_PRIVCMD_HYPERCALL:
		ret = privcmd_ioctl_hypercall(udata);
		break;

	case IOCTL_PRIVCMD_MMAP:
		ret = privcmd_ioctl_mmap(udata);
		break;

	case IOCTL_PRIVCMD_MMAPBATCH:
		ret = privcmd_ioctl_mmap_batch(udata);
		break;

	default:
		ret = -EINVAL;
		break;
	}

	return ret;
}

static void privcmd_close(struct vm_area_struct *vma)
{
	struct xen_pvh_sav_pfn_info *savp = vma->vm_private_data;

	if (!xen_pv_domain()  || 
	    !xen_feature(XENFEAT_auto_translated_physmap)  ||
	    !vma->vm_private_data)
		return;

	xen_unmap_domain_mfn_range(vma);
	kfree(savp->sp_paga);
	kfree(savp);
}

static int privcmd_fault(struct vm_area_struct *vma, struct vm_fault *vmf)
{
	printk(KERN_DEBUG "privcmd_fault: vma=%p %lx-%lx, pgoff=%lx, uv=%p\n",
	       vma, vma->vm_start, vma->vm_end,
	       vmf->pgoff, vmf->virtual_address);

	return VM_FAULT_SIGBUS;
}

static struct vm_operations_struct privcmd_vm_ops = {
	.close = privcmd_close,
	.fault = privcmd_fault
};

static int privcmd_mmap(struct file *file, struct vm_area_struct *vma)
{
	/* DONTCOPY is essential for Xen because copy_page_range doesn't know
	 * how to recreate these mappings */
	vma->vm_flags |= VM_RESERVED | VM_IO | VM_DONTCOPY | VM_PFNMAP;
	vma->vm_ops = &privcmd_vm_ops;
	vma->vm_private_data = NULL;

	return 0;
}

static int privcmd_enforce_singleshot_mapping(struct vm_area_struct *vma)
{
	if (xen_pv_domain() && xen_feature(XENFEAT_auto_translated_physmap))
		/* NOTE : make this atomic ********************** */
		return (vma->vm_private_data == NULL);

	return (xchg(&vma->vm_private_data, (void *)1) == NULL);
}

const struct file_operations xen_privcmd_fops = {
	.owner = THIS_MODULE,
	.unlocked_ioctl = privcmd_ioctl,
	.mmap = privcmd_mmap,
};
EXPORT_SYMBOL_GPL(xen_privcmd_fops);

static struct miscdevice privcmd_dev = {
	.minor = MISC_DYNAMIC_MINOR,
	.name = "xen/privcmd",
	.fops = &xen_privcmd_fops,
};

static int __init privcmd_init(void)
{
	int err;

	if (!xen_domain())
		return -ENODEV;

	err = misc_register(&privcmd_dev);
	if (err != 0) {
		printk(KERN_ERR "Could not register Xen privcmd device\n");
		return err;
	}
	return 0;
}

static void __exit privcmd_exit(void)
{
	misc_deregister(&privcmd_dev);
}

module_init(privcmd_init);
module_exit(privcmd_exit);

--MP_/VbujuzxBRJmnncQgGTu8kEI
Content-Type: text/x-c++src
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename=mmu.c

/*
 * Xen mmu operations
 *
 * This file contains the various mmu fetch and update operations.
 * The most important job they must perform is the mapping between the
 * domain's pfn and the overall machine mfns.
 *
 * Xen allows guests to directly update the pagetable, in a controlled
 * fashion.  In other words, the guest modifies the same pagetable
 * that the CPU actually uses, which eliminates the overhead of having
 * a separate shadow pagetable.
 *
 * In order to allow this, it falls on the guest domain to map its
 * notion of a "physical" pfn - which is just a domain-local linear
 * address - into a real "machine address" which the CPU's MMU can
 * use.
 *
 * A pgd_t/pmd_t/pte_t will typically contain an mfn, and so can be
 * inserted directly into the pagetable.  When creating a new
 * pte/pmd/pgd, it converts the passed pfn into an mfn.  Conversely,
 * when reading the content back with __(pgd|pmd|pte)_val, it converts
 * the mfn back into a pfn.
 *
 * The other constraint is that all pages which make up a pagetable
 * must be mapped read-only in the guest.  This prevents uncontrolled
 * guest updates to the pagetable.  Xen strictly enforces this, and
 * will disallow any pagetable update which will end up mapping a
 * pagetable page RW, and will disallow using any writable page as a
 * pagetable.
 *
 * Naively, when loading %cr3 with the base of a new pagetable, Xen
 * would need to validate the whole pagetable before going on.
 * Naturally, this is quite slow.  The solution is to "pin" a
 * pagetable, which enforces all the constraints on the pagetable even
 * when it is not actively in use.  This menas that Xen can be assured
 * that it is still valid when you do load it into %cr3, and doesn't
 * need to revalidate it.
 *
 * Jeremy Fitzhardinge <jeremy@xensource.com>, XenSource Inc, 2007
 */
#include <linux/sched.h>
#include <linux/highmem.h>
#include <linux/debugfs.h>
#include <linux/bug.h>
#include <linux/vmalloc.h>
#include <linux/module.h>
#include <linux/gfp.h>
#include <linux/memblock.h>
#include <linux/seq_file.h>

#include <trace/events/xen.h>

#include <asm/pgtable.h>
#include <asm/tlbflush.h>
#include <asm/fixmap.h>
#include <asm/mmu_context.h>
#include <asm/setup.h>
#include <asm/paravirt.h>
#include <asm/e820.h>
#include <asm/linkage.h>
#include <asm/page.h>
#include <asm/init.h>
#include <asm/pat.h>
#include <asm/smp.h>

#include <asm/xen/hypercall.h>
#include <asm/xen/hypervisor.h>

#include <xen/xen.h>
#include <xen/page.h>
#include <xen/interface/xen.h>
#include <xen/interface/hvm/hvm_op.h>
#include <xen/interface/version.h>
#include <xen/interface/memory.h>
#include <xen/hvc-console.h>
#include <xen/balloon.h>

#include "multicalls.h"
#include "mmu.h"
#include "debugfs.h"

/*
 * Protects atomic reservation decrease/increase against concurrent increases.
 * Also protects non-atomic updates of current_pages and balloon lists.
 */
DEFINE_SPINLOCK(xen_reservation_lock);

/*
 * Identity map, in addition to plain kernel map.  This needs to be
 * large enough to allocate page table pages to allocate the rest.
 * Each page can map 2MB.
 */
#define LEVEL1_IDENT_ENTRIES	(PTRS_PER_PTE * 4)
static RESERVE_BRK_ARRAY(pte_t, level1_ident_pgt, LEVEL1_IDENT_ENTRIES);

#ifdef CONFIG_X86_64
/* l3 pud for userspace vsyscall mapping */
static pud_t level3_user_vsyscall[PTRS_PER_PUD] __page_aligned_bss;
#endif /* CONFIG_X86_64 */

/*
 * Note about cr3 (pagetable base) values:
 *
 * xen_cr3 contains the current logical cr3 value; it contains the
 * last set cr3.  This may not be the current effective cr3, because
 * its update may be being lazily deferred.  However, a vcpu looking
 * at its own cr3 can use this value knowing that it everything will
 * be self-consistent.
 *
 * xen_current_cr3 contains the actual vcpu cr3; it is set once the
 * hypercall to set the vcpu cr3 is complete (so it may be a little
 * out of date, but it will never be set early).  If one vcpu is
 * looking at another vcpu's cr3 value, it should use this variable.
 */
DEFINE_PER_CPU(unsigned long, xen_cr3);	 /* cr3 stored as physaddr */
DEFINE_PER_CPU(unsigned long, xen_current_cr3);	 /* actual vcpu cr3 */


/*
 * Just beyond the highest usermode address.  STACK_TOP_MAX has a
 * redzone above it, so round it up to a PGD boundary.
 */
#define USER_LIMIT	((STACK_TOP_MAX + PGDIR_SIZE - 1) & PGDIR_MASK)

unsigned long arbitrary_virt_to_mfn(void *vaddr)
{
	xmaddr_t maddr = arbitrary_virt_to_machine(vaddr);

	return PFN_DOWN(maddr.maddr);
}

xmaddr_t arbitrary_virt_to_machine(void *vaddr)
{
	unsigned long address = (unsigned long)vaddr;
	unsigned int level;
	pte_t *pte;
	unsigned offset;

	/*
	 * if the PFN is in the linear mapped vaddr range, we can just use
	 * the (quick) virt_to_machine() p2m lookup
	 */
	if (virt_addr_valid(vaddr))
		return virt_to_machine(vaddr);

	/* otherwise we have to do a (slower) full page-table walk */

	pte = lookup_address(address, &level);
	BUG_ON(pte == NULL);
	offset = address & ~PAGE_MASK;
	return XMADDR(((phys_addr_t)pte_mfn(*pte) << PAGE_SHIFT) + offset);
}
EXPORT_SYMBOL_GPL(arbitrary_virt_to_machine);

void make_lowmem_page_readonly(void *vaddr)
{
	pte_t *pte, ptev;
	unsigned long address = (unsigned long)vaddr;
	unsigned int level;

	pte = lookup_address(address, &level);
	if (pte == NULL)
		return;		/* vaddr missing */

	ptev = pte_wrprotect(*pte);

	if (HYPERVISOR_update_va_mapping(address, ptev, 0))
		BUG();
}

void make_lowmem_page_readwrite(void *vaddr)
{
	pte_t *pte, ptev;
	unsigned long address = (unsigned long)vaddr;
	unsigned int level;

	pte = lookup_address(address, &level);
	if (pte == NULL)
		return;		/* vaddr missing */

	ptev = pte_mkwrite(*pte);

	if (HYPERVISOR_update_va_mapping(address, ptev, 0))
		BUG();
}


static bool xen_page_pinned(void *ptr)
{
	struct page *page = virt_to_page(ptr);

	return PagePinned(page);
}

void xen_set_domain_pte(pte_t *ptep, pte_t pteval, unsigned domid)
{
	struct multicall_space mcs;
	struct mmu_update *u;

	trace_xen_mmu_set_domain_pte(ptep, pteval, domid);

	mcs = xen_mc_entry(sizeof(*u));
	u = mcs.args;

	/* ptep might be kmapped when using 32-bit HIGHPTE */
	u->ptr = virt_to_machine(ptep).maddr;
	u->val = pte_val_ma(pteval);

	MULTI_mmu_update(mcs.mc, mcs.args, 1, NULL, domid);

	xen_mc_issue(PARAVIRT_LAZY_MMU);
}
EXPORT_SYMBOL_GPL(xen_set_domain_pte);

static void xen_extend_mmu_update(const struct mmu_update *update)
{
	struct multicall_space mcs;
	struct mmu_update *u;

	mcs = xen_mc_extend_args(__HYPERVISOR_mmu_update, sizeof(*u));

	if (mcs.mc != NULL) {
		mcs.mc->args[1]++;
	} else {
		mcs = __xen_mc_entry(sizeof(*u));
		MULTI_mmu_update(mcs.mc, mcs.args, 1, NULL, DOMID_SELF);
	}

	u = mcs.args;
	*u = *update;
}

static void xen_extend_mmuext_op(const struct mmuext_op *op)
{
	struct multicall_space mcs;
	struct mmuext_op *u;

	mcs = xen_mc_extend_args(__HYPERVISOR_mmuext_op, sizeof(*u));

	if (mcs.mc != NULL) {
		mcs.mc->args[1]++;
	} else {
		mcs = __xen_mc_entry(sizeof(*u));
		MULTI_mmuext_op(mcs.mc, mcs.args, 1, NULL, DOMID_SELF);
	}

	u = mcs.args;
	*u = *op;
}

static void xen_set_pmd_hyper(pmd_t *ptr, pmd_t val)
{
	struct mmu_update u;

	preempt_disable();

	xen_mc_batch();

	/* ptr may be ioremapped for 64-bit pagetable setup */
	u.ptr = arbitrary_virt_to_machine(ptr).maddr;
	u.val = pmd_val_ma(val);
	xen_extend_mmu_update(&u);

	xen_mc_issue(PARAVIRT_LAZY_MMU);

	preempt_enable();
}

static void xen_set_pmd(pmd_t *ptr, pmd_t val)
{
	trace_xen_mmu_set_pmd(ptr, val);

	/* If page is not pinned, we can just update the entry
	   directly */
	if (!xen_page_pinned(ptr)) {
		*ptr = val;
		return;
	}

	xen_set_pmd_hyper(ptr, val);
}

/*
 * Associate a virtual page frame with a given physical page frame
 * and protection flags for that frame.
 */
void set_pte_mfn(unsigned long vaddr, unsigned long mfn, pgprot_t flags)
{
	set_pte_vaddr(vaddr, mfn_pte(mfn, flags));
}

static bool xen_batched_set_pte(pte_t *ptep, pte_t pteval)
{
	struct mmu_update u;

	if (paravirt_get_lazy_mode() != PARAVIRT_LAZY_MMU)
		return false;

	xen_mc_batch();

	u.ptr = virt_to_machine(ptep).maddr | MMU_NORMAL_PT_UPDATE;
	u.val = pte_val_ma(pteval);
	xen_extend_mmu_update(&u);

	xen_mc_issue(PARAVIRT_LAZY_MMU);

	return true;
}

static inline void __xen_set_pte(pte_t *ptep, pte_t 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)
{
	trace_xen_mmu_set_pte(ptep, pteval);
	__xen_set_pte(ptep, pteval);
}

void xen_set_clr_mmio_pvh_pte(unsigned long pfn, unsigned long mfn, 
			      int nr_mfns, int add_mapping)
{
	struct physdev_map_iomem iomem;

	iomem.first_gfn = pfn;
	iomem.first_mfn = mfn;
	iomem.nr_mfns = nr_mfns;
	iomem.add_mapping = add_mapping;

	if (HYPERVISOR_physdev_op(PHYSDEVOP_pvh_map_iomem, &iomem))
		BUG();
}

static void xen_dom0pvh_set_pte_at(struct mm_struct *mm, unsigned long addr,
		    		   pte_t *ptep, pte_t pteval)
{
	native_set_pte(ptep, pteval);
}

static void xen_set_pte_at(struct mm_struct *mm, unsigned long addr,
		    pte_t *ptep, pte_t pteval)
{
	trace_xen_mmu_set_pte_at(mm, addr, ptep, pteval);
	__xen_set_pte(ptep, pteval);
}

pte_t xen_ptep_modify_prot_start(struct mm_struct *mm,
				 unsigned long addr, pte_t *ptep)
{
	/* Just return the pte as-is.  We preserve the bits on commit */
	trace_xen_mmu_ptep_modify_prot_start(mm, addr, ptep, *ptep);
	return *ptep;
}

void xen_ptep_modify_prot_commit(struct mm_struct *mm, unsigned long addr,
				 pte_t *ptep, pte_t pte)
{
	struct mmu_update u;

	trace_xen_mmu_ptep_modify_prot_commit(mm, addr, ptep, pte);
	xen_mc_batch();

	u.ptr = virt_to_machine(ptep).maddr | MMU_PT_UPDATE_PRESERVE_AD;
	u.val = pte_val_ma(pte);
	xen_extend_mmu_update(&u);

	xen_mc_issue(PARAVIRT_LAZY_MMU);
}

/* Assume pteval_t is equivalent to all the other *val_t types. */
static pteval_t pte_mfn_to_pfn(pteval_t val)
{
	if (val & _PAGE_PRESENT) {
		unsigned long mfn = (val & PTE_PFN_MASK) >> PAGE_SHIFT;
		unsigned long pfn = mfn_to_pfn(mfn);

		pteval_t flags = val & PTE_FLAGS_MASK;
		if (unlikely(pfn == ~0))
			val = flags & ~_PAGE_PRESENT;
		else
			val = ((pteval_t)pfn << PAGE_SHIFT) | flags;
	}

	return val;
}

static pteval_t pte_pfn_to_mfn(pteval_t val)
{
	if (val & _PAGE_PRESENT) {
		unsigned long pfn = (val & PTE_PFN_MASK) >> PAGE_SHIFT;
		pteval_t flags = val & PTE_FLAGS_MASK;
		unsigned long mfn;

		if (!xen_feature(XENFEAT_auto_translated_physmap))
			mfn = get_phys_to_machine(pfn);
		else
			mfn = pfn;
		/*
		 * If there's no mfn for the pfn, then just create an
		 * empty non-present pte.  Unfortunately this loses
		 * information about the original pfn, so
		 * pte_mfn_to_pfn is asymmetric.
		 */
		if (unlikely(mfn == INVALID_P2M_ENTRY)) {
			mfn = 0;
			flags = 0;
		} else {
			/*
			 * Paramount to do this test _after_ the
			 * INVALID_P2M_ENTRY as INVALID_P2M_ENTRY &
			 * IDENTITY_FRAME_BIT resolves to true.
			 */
			mfn &= ~FOREIGN_FRAME_BIT;
			if (mfn & IDENTITY_FRAME_BIT) {
				mfn &= ~IDENTITY_FRAME_BIT;
				flags |= _PAGE_IOMAP;
			}
		}
		val = ((pteval_t)mfn << PAGE_SHIFT) | flags;
	}

	return val;
}

static pteval_t iomap_pte(pteval_t val)
{
	if (val & _PAGE_PRESENT) {
		unsigned long pfn = (val & PTE_PFN_MASK) >> PAGE_SHIFT;
		pteval_t flags = val & PTE_FLAGS_MASK;

		/* We assume the pte frame number is a MFN, so
		   just use it as-is. */
		val = ((pteval_t)pfn << PAGE_SHIFT) | flags;
	}

	return val;
}

static pteval_t xen_pte_val(pte_t pte)
{
	pteval_t pteval = pte.pte;
#if 0
	/* If this is a WC pte, convert back from Xen WC to Linux WC */
	if ((pteval & (_PAGE_PAT | _PAGE_PCD | _PAGE_PWT)) == _PAGE_PAT) {
		WARN_ON(!pat_enabled);
		pteval = (pteval & ~_PAGE_PAT) | _PAGE_PWT;
	}
#endif
	if (xen_initial_domain() && (pteval & _PAGE_IOMAP))
		return pteval;

	return pte_mfn_to_pfn(pteval);
}
PV_CALLEE_SAVE_REGS_THUNK(xen_pte_val);

static pgdval_t xen_pgd_val(pgd_t pgd)
{
	return pte_mfn_to_pfn(pgd.pgd);
}
PV_CALLEE_SAVE_REGS_THUNK(xen_pgd_val);

/*
 * Xen's PAT setup is part of its ABI, though I assume entries 6 & 7
 * are reserved for now, to correspond to the Intel-reserved PAT
 * types.
 *
 * We expect Linux's PAT set as follows:
 *
 * Idx  PTE flags        Linux    Xen    Default
 * 0                     WB       WB     WB
 * 1            PWT      WC       WT     WT
 * 2        PCD          UC-      UC-    UC-
 * 3        PCD PWT      UC       UC     UC
 * 4    PAT              WB       WC     WB
 * 5    PAT     PWT      WC       WP     WT
 * 6    PAT PCD          UC-      UC     UC-
 * 7    PAT PCD PWT      UC       UC     UC
 */

void xen_set_pat(u64 pat)
{
	/* We expect Linux to use a PAT setting of
	 * UC UC- WC WB (ignoring the PAT flag) */
	WARN_ON(pat != 0x0007010600070106ull);
}

static pte_t xen_make_pte(pteval_t pte)
{
	phys_addr_t addr = (pte & PTE_PFN_MASK);
#if 0
	/* If Linux is trying to set a WC pte, then map to the Xen WC.
	 * If _PAGE_PAT is set, then it probably means it is really
	 * _PAGE_PSE, so avoid fiddling with the PAT mapping and hope
	 * things work out OK...
	 *
	 * (We should never see kernel mappings with _PAGE_PSE set,
	 * but we could see hugetlbfs mappings, I think.).
	 */
	if (pat_enabled && !WARN_ON(pte & _PAGE_PAT)) {
		if ((pte & (_PAGE_PCD | _PAGE_PWT)) == _PAGE_PWT)
			pte = (pte & ~(_PAGE_PCD | _PAGE_PWT)) | _PAGE_PAT;
	}
#endif
	/*
	 * Unprivileged domains are allowed to do IOMAPpings for
	 * PCI passthrough, but not map ISA space.  The ISA
	 * mappings are just dummy local mappings to keep other
	 * parts of the kernel happy.
	 */
	if (unlikely(pte & _PAGE_IOMAP) &&
	    (xen_initial_domain() || addr >= ISA_END_ADDRESS)) {
		pte = iomap_pte(pte);
	} else {
		pte &= ~_PAGE_IOMAP;
		pte = pte_pfn_to_mfn(pte);
	}

	return native_make_pte(pte);
}
PV_CALLEE_SAVE_REGS_THUNK(xen_make_pte);

static pgd_t xen_make_pgd(pgdval_t pgd)
{
	pgd = pte_pfn_to_mfn(pgd);
	return native_make_pgd(pgd);
}
PV_CALLEE_SAVE_REGS_THUNK(xen_make_pgd);

static pmdval_t xen_pmd_val(pmd_t pmd)
{
	return pte_mfn_to_pfn(pmd.pmd);
}
PV_CALLEE_SAVE_REGS_THUNK(xen_pmd_val);

static void xen_set_pud_hyper(pud_t *ptr, pud_t val)
{
	struct mmu_update u;

	preempt_disable();

	xen_mc_batch();

	/* ptr may be ioremapped for 64-bit pagetable setup */
	u.ptr = arbitrary_virt_to_machine(ptr).maddr;
	u.val = pud_val_ma(val);
	xen_extend_mmu_update(&u);

	xen_mc_issue(PARAVIRT_LAZY_MMU);

	preempt_enable();
}

static void xen_set_pud(pud_t *ptr, pud_t val)
{
	trace_xen_mmu_set_pud(ptr, val);

	/* If page is not pinned, we can just update the entry
	   directly */
	if (!xen_page_pinned(ptr)) {
		*ptr = val;
		return;
	}

	xen_set_pud_hyper(ptr, val);
}

#ifdef CONFIG_X86_PAE
static void xen_set_pte_atomic(pte_t *ptep, pte_t pte)
{
	trace_xen_mmu_set_pte_atomic(ptep, pte);
	set_64bit((u64 *)ptep, native_pte_val(pte));
}

static void xen_pte_clear(struct mm_struct *mm, unsigned long addr, pte_t *ptep)
{
	trace_xen_mmu_pte_clear(mm, addr, ptep);
	if (!xen_batched_set_pte(ptep, native_make_pte(0)))
		native_pte_clear(mm, addr, ptep);
}

static void xen_pmd_clear(pmd_t *pmdp)
{
	trace_xen_mmu_pmd_clear(pmdp);
	set_pmd(pmdp, __pmd(0));
}
#endif	/* CONFIG_X86_PAE */

static pmd_t xen_make_pmd(pmdval_t pmd)
{
	pmd = pte_pfn_to_mfn(pmd);
	return native_make_pmd(pmd);
}
PV_CALLEE_SAVE_REGS_THUNK(xen_make_pmd);

#if PAGETABLE_LEVELS == 4
static pudval_t xen_pud_val(pud_t pud)
{
	return pte_mfn_to_pfn(pud.pud);
}
PV_CALLEE_SAVE_REGS_THUNK(xen_pud_val);

static pud_t xen_make_pud(pudval_t pud)
{
	pud = pte_pfn_to_mfn(pud);

	return native_make_pud(pud);
}
PV_CALLEE_SAVE_REGS_THUNK(xen_make_pud);

static pgd_t *xen_get_user_pgd(pgd_t *pgd)
{
	pgd_t *pgd_page = (pgd_t *)(((unsigned long)pgd) & PAGE_MASK);
	unsigned offset = pgd - pgd_page;
	pgd_t *user_ptr = NULL;

	if (offset < pgd_index(USER_LIMIT)) {
		struct page *page = virt_to_page(pgd_page);
		user_ptr = (pgd_t *)page->private;
		if (user_ptr)
			user_ptr += offset;
	}

	return user_ptr;
}

static void __xen_set_pgd_hyper(pgd_t *ptr, pgd_t val)
{
	struct mmu_update u;

	u.ptr = virt_to_machine(ptr).maddr;
	u.val = pgd_val_ma(val);
	xen_extend_mmu_update(&u);
}

/*
 * Raw hypercall-based set_pgd, intended for in early boot before
 * there's a page structure.  This implies:
 *  1. The only existing pagetable is the kernel's
 *  2. It is always pinned
 *  3. It has no user pagetable attached to it
 */
static void __init xen_set_pgd_hyper(pgd_t *ptr, pgd_t val)
{
	preempt_disable();

	xen_mc_batch();

	__xen_set_pgd_hyper(ptr, val);

	xen_mc_issue(PARAVIRT_LAZY_MMU);

	preempt_enable();
}

static void xen_set_pgd(pgd_t *ptr, pgd_t val)
{
	pgd_t *user_ptr = xen_get_user_pgd(ptr);

	trace_xen_mmu_set_pgd(ptr, user_ptr, val);

	/* If page is not pinned, we can just update the entry
	   directly */
	if (!xen_page_pinned(ptr)) {
		*ptr = val;
		if (user_ptr) {
			WARN_ON(xen_page_pinned(user_ptr));
			*user_ptr = val;
		}
		return;
	}

	/* If it's pinned, then we can at least batch the kernel and
	   user updates together. */
	xen_mc_batch();

	__xen_set_pgd_hyper(ptr, val);
	if (user_ptr)
		__xen_set_pgd_hyper(user_ptr, val);

	xen_mc_issue(PARAVIRT_LAZY_MMU);
}
#endif	/* PAGETABLE_LEVELS == 4 */

/*
 * (Yet another) pagetable walker.  This one is intended for pinning a
 * pagetable.  This means that it walks a pagetable and calls the
 * callback function on each page it finds making up the page table,
 * at every level.  It walks the entire pagetable, but it only bothers
 * pinning pte pages which are below limit.  In the normal case this
 * will be STACK_TOP_MAX, but at boot we need to pin up to
 * FIXADDR_TOP.
 *
 * For 32-bit the important bit is that we don't pin beyond there,
 * because then we start getting into Xen's ptes.
 *
 * For 64-bit, we must skip the Xen hole in the middle of the address
 * space, just after the big x86-64 virtual hole.
 */
static int __xen_pgd_walk(struct mm_struct *mm, pgd_t *pgd,
			  int (*func)(struct mm_struct *mm, struct page *,
				      enum pt_level),
			  unsigned long limit)
{
	int flush = 0;
	unsigned hole_low, hole_high;
	unsigned pgdidx_limit, pudidx_limit, pmdidx_limit;
	unsigned pgdidx, pudidx, pmdidx;

	/* The limit is the last byte to be touched */
	limit--;
	BUG_ON(limit >= FIXADDR_TOP);

	if (xen_feature(XENFEAT_auto_translated_physmap))
		return 0;

	/*
	 * 64-bit has a great big hole in the middle of the address
	 * space, which contains the Xen mappings.  On 32-bit these
	 * will end up making a zero-sized hole and so is a no-op.
	 */
	hole_low = pgd_index(USER_LIMIT);
	hole_high = pgd_index(PAGE_OFFSET);

	pgdidx_limit = pgd_index(limit);
#if PTRS_PER_PUD > 1
	pudidx_limit = pud_index(limit);
#else
	pudidx_limit = 0;
#endif
#if PTRS_PER_PMD > 1
	pmdidx_limit = pmd_index(limit);
#else
	pmdidx_limit = 0;
#endif

	for (pgdidx = 0; pgdidx <= pgdidx_limit; pgdidx++) {
		pud_t *pud;

		if (pgdidx >= hole_low && pgdidx < hole_high)
			continue;

		if (!pgd_val(pgd[pgdidx]))
			continue;

		pud = pud_offset(&pgd[pgdidx], 0);

		if (PTRS_PER_PUD > 1) /* not folded */
			flush |= (*func)(mm, virt_to_page(pud), PT_PUD);

		for (pudidx = 0; pudidx < PTRS_PER_PUD; pudidx++) {
			pmd_t *pmd;

			if (pgdidx == pgdidx_limit &&
			    pudidx > pudidx_limit)
				goto out;

			if (pud_none(pud[pudidx]))
				continue;

			pmd = pmd_offset(&pud[pudidx], 0);

			if (PTRS_PER_PMD > 1) /* not folded */
				flush |= (*func)(mm, virt_to_page(pmd), PT_PMD);

			for (pmdidx = 0; pmdidx < PTRS_PER_PMD; pmdidx++) {
				struct page *pte;

				if (pgdidx == pgdidx_limit &&
				    pudidx == pudidx_limit &&
				    pmdidx > pmdidx_limit)
					goto out;

				if (pmd_none(pmd[pmdidx]))
					continue;

				pte = pmd_page(pmd[pmdidx]);
				flush |= (*func)(mm, pte, PT_PTE);
			}
		}
	}

out:
	/* Do the top level last, so that the callbacks can use it as
	   a cue to do final things like tlb flushes. */
	flush |= (*func)(mm, virt_to_page(pgd), PT_PGD);

	return flush;
}

static int xen_pgd_walk(struct mm_struct *mm,
			int (*func)(struct mm_struct *mm, struct page *,
				    enum pt_level),
			unsigned long limit)
{
	return __xen_pgd_walk(mm, mm->pgd, func, limit);
}

/* If we're using split pte locks, then take the page's lock and
   return a pointer to it.  Otherwise return NULL. */
static spinlock_t *xen_pte_lock(struct page *page, struct mm_struct *mm)
{
	spinlock_t *ptl = NULL;

#if USE_SPLIT_PTLOCKS
	ptl = __pte_lockptr(page);
	spin_lock_nest_lock(ptl, &mm->page_table_lock);
#endif

	return ptl;
}

static void xen_pte_unlock(void *v)
{
	spinlock_t *ptl = v;
	spin_unlock(ptl);
}

static void xen_do_pin(unsigned level, unsigned long pfn)
{
	struct mmuext_op op;

	op.cmd = level;
	op.arg1.mfn = pfn_to_mfn(pfn);

	xen_extend_mmuext_op(&op);
}

static int xen_pin_page(struct mm_struct *mm, struct page *page,
			enum pt_level level)
{
	unsigned pgfl = TestSetPagePinned(page);
	int flush;

	if (pgfl)
		flush = 0;		/* already pinned */
	else if (PageHighMem(page))
		/* kmaps need flushing if we found an unpinned
		   highpage */
		flush = 1;
	else {
		void *pt = lowmem_page_address(page);
		unsigned long pfn = page_to_pfn(page);
		struct multicall_space mcs = __xen_mc_entry(0);
		spinlock_t *ptl;

		flush = 0;

		/*
		 * We need to hold the pagetable lock between the time
		 * we make the pagetable RO and when we actually pin
		 * it.  If we don't, then other users may come in and
		 * attempt to update the pagetable by writing it,
		 * which will fail because the memory is RO but not
		 * pinned, so Xen won't do the trap'n'emulate.
		 *
		 * If we're using split pte locks, we can't hold the
		 * entire pagetable's worth of locks during the
		 * traverse, because we may wrap the preempt count (8
		 * bits).  The solution is to mark RO and pin each PTE
		 * page while holding the lock.  This means the number
		 * of locks we end up holding is never more than a
		 * batch size (~32 entries, at present).
		 *
		 * If we're not using split pte locks, we needn't pin
		 * the PTE pages independently, because we're
		 * protected by the overall pagetable lock.
		 */
		ptl = NULL;
		if (level == PT_PTE)
			ptl = xen_pte_lock(page, mm);

		MULTI_update_va_mapping(mcs.mc, (unsigned long)pt,
					pfn_pte(pfn, PAGE_KERNEL_RO),
					level == PT_PGD ? UVMF_TLB_FLUSH : 0);

		if (ptl) {
			xen_do_pin(MMUEXT_PIN_L1_TABLE, pfn);

			/* Queue a deferred unlock for when this batch
			   is completed. */
			xen_mc_callback(xen_pte_unlock, ptl);
		}
	}

	return flush;
}

/* This is called just after a mm has been created, but it has not
   been used yet.  We need to make sure that its pagetable is all
   read-only, and can be pinned. */
static void __xen_pgd_pin(struct mm_struct *mm, pgd_t *pgd)
{
	trace_xen_mmu_pgd_pin(mm, pgd);

	xen_mc_batch();

	if (__xen_pgd_walk(mm, pgd, xen_pin_page, USER_LIMIT)) {
		/* re-enable interrupts for flushing */
		xen_mc_issue(0);

		kmap_flush_unused();

		xen_mc_batch();
	}

#ifdef CONFIG_X86_64
	{
		pgd_t *user_pgd = xen_get_user_pgd(pgd);

		xen_do_pin(MMUEXT_PIN_L4_TABLE, PFN_DOWN(__pa(pgd)));

		if (user_pgd) {
			xen_pin_page(mm, virt_to_page(user_pgd), PT_PGD);
			xen_do_pin(MMUEXT_PIN_L4_TABLE,
				   PFN_DOWN(__pa(user_pgd)));
		}
	}
#else /* CONFIG_X86_32 */
#ifdef CONFIG_X86_PAE
	/* Need to make sure unshared kernel PMD is pinnable */
	xen_pin_page(mm, pgd_page(pgd[pgd_index(TASK_SIZE)]),
		     PT_PMD);
#endif
	xen_do_pin(MMUEXT_PIN_L3_TABLE, PFN_DOWN(__pa(pgd)));
#endif /* CONFIG_X86_64 */
	xen_mc_issue(0);
}

static void xen_pgd_pin(struct mm_struct *mm)
{
	__xen_pgd_pin(mm, mm->pgd);
}

/*
 * On save, we need to pin all pagetables to make sure they get their
 * mfns turned into pfns.  Search the list for any unpinned pgds and pin
 * them (unpinned pgds are not currently in use, probably because the
 * process is under construction or destruction).
 *
 * Expected to be called in stop_machine() ("equivalent to taking
 * every spinlock in the system"), so the locking doesn't really
 * matter all that much.
 */
void xen_mm_pin_all(void)
{
	struct page *page;

	spin_lock(&pgd_lock);

	list_for_each_entry(page, &pgd_list, lru) {
		if (!PagePinned(page)) {
			__xen_pgd_pin(&init_mm, (pgd_t *)page_address(page));
			SetPageSavePinned(page);
		}
	}

	spin_unlock(&pgd_lock);
}

/*
 * The init_mm pagetable is really pinned as soon as its created, but
 * that's before we have page structures to store the bits.  So do all
 * the book-keeping now.
 */
static int __init xen_mark_pinned(struct mm_struct *mm, struct page *page,
				  enum pt_level level)
{
	SetPagePinned(page);
	return 0;
}

static void __init xen_mark_init_mm_pinned(void)
{
	xen_pgd_walk(&init_mm, xen_mark_pinned, FIXADDR_TOP);
}

static int xen_unpin_page(struct mm_struct *mm, struct page *page,
			  enum pt_level level)
{
	unsigned pgfl = TestClearPagePinned(page);

	if (pgfl && !PageHighMem(page)) {
		void *pt = lowmem_page_address(page);
		unsigned long pfn = page_to_pfn(page);
		spinlock_t *ptl = NULL;
		struct multicall_space mcs;

		/*
		 * Do the converse to pin_page.  If we're using split
		 * pte locks, we must be holding the lock for while
		 * the pte page is unpinned but still RO to prevent
		 * concurrent updates from seeing it in this
		 * partially-pinned state.
		 */
		if (level == PT_PTE) {
			ptl = xen_pte_lock(page, mm);

			if (ptl)
				xen_do_pin(MMUEXT_UNPIN_TABLE, pfn);
		}

		mcs = __xen_mc_entry(0);

		MULTI_update_va_mapping(mcs.mc, (unsigned long)pt,
					pfn_pte(pfn, PAGE_KERNEL),
					level == PT_PGD ? UVMF_TLB_FLUSH : 0);

		if (ptl) {
			/* unlock when batch completed */
			xen_mc_callback(xen_pte_unlock, ptl);
		}
	}

	return 0;		/* never need to flush on unpin */
}

/* Release a pagetables pages back as normal RW */
static void __xen_pgd_unpin(struct mm_struct *mm, pgd_t *pgd)
{
	trace_xen_mmu_pgd_unpin(mm, pgd);

	xen_mc_batch();

	xen_do_pin(MMUEXT_UNPIN_TABLE, PFN_DOWN(__pa(pgd)));

#ifdef CONFIG_X86_64
	{
		pgd_t *user_pgd = xen_get_user_pgd(pgd);

		if (user_pgd) {
			xen_do_pin(MMUEXT_UNPIN_TABLE,
				   PFN_DOWN(__pa(user_pgd)));
			xen_unpin_page(mm, virt_to_page(user_pgd), PT_PGD);
		}
	}
#endif

#ifdef CONFIG_X86_PAE
	/* Need to make sure unshared kernel PMD is unpinned */
	xen_unpin_page(mm, pgd_page(pgd[pgd_index(TASK_SIZE)]),
		       PT_PMD);
#endif

	__xen_pgd_walk(mm, pgd, xen_unpin_page, USER_LIMIT);

	xen_mc_issue(0);
}

static void xen_pgd_unpin(struct mm_struct *mm)
{
	__xen_pgd_unpin(mm, mm->pgd);
}

/*
 * On resume, undo any pinning done at save, so that the rest of the
 * kernel doesn't see any unexpected pinned pagetables.
 */
void xen_mm_unpin_all(void)
{
	struct page *page;

	spin_lock(&pgd_lock);

	list_for_each_entry(page, &pgd_list, lru) {
		if (PageSavePinned(page)) {
			BUG_ON(!PagePinned(page));
			__xen_pgd_unpin(&init_mm, (pgd_t *)page_address(page));
			ClearPageSavePinned(page);
		}
	}

	spin_unlock(&pgd_lock);
}

static void xen_activate_mm(struct mm_struct *prev, struct mm_struct *next)
{
	spin_lock(&next->page_table_lock);
	xen_pgd_pin(next);
	spin_unlock(&next->page_table_lock);
}

static void xen_dup_mmap(struct mm_struct *oldmm, struct mm_struct *mm)
{
	spin_lock(&mm->page_table_lock);
	xen_pgd_pin(mm);
	spin_unlock(&mm->page_table_lock);
}


#ifdef CONFIG_SMP
/* Another cpu may still have their %cr3 pointing at the pagetable, so
   we need to repoint it somewhere else before we can unpin it. */
static void drop_other_mm_ref(void *info)
{
	struct mm_struct *mm = info;
	struct mm_struct *active_mm;

	active_mm = this_cpu_read(cpu_tlbstate.active_mm);

	if (active_mm == mm && this_cpu_read(cpu_tlbstate.state) != TLBSTATE_OK)
		leave_mm(smp_processor_id());

	/* If this cpu still has a stale cr3 reference, then make sure
	   it has been flushed. */
	if (this_cpu_read(xen_current_cr3) == __pa(mm->pgd))
		load_cr3(swapper_pg_dir);
}

static void xen_drop_mm_ref(struct mm_struct *mm)
{
	cpumask_var_t mask;
	unsigned cpu;

	if (current->active_mm == mm) {
		if (current->mm == mm)
			load_cr3(swapper_pg_dir);
		else
			leave_mm(smp_processor_id());
	}

	/* Get the "official" set of cpus referring to our pagetable. */
	if (!alloc_cpumask_var(&mask, GFP_ATOMIC)) {
		for_each_online_cpu(cpu) {
			if (!cpumask_test_cpu(cpu, mm_cpumask(mm))
			    && per_cpu(xen_current_cr3, cpu) != __pa(mm->pgd))
				continue;
			smp_call_function_single(cpu, drop_other_mm_ref, mm, 1);
		}
		return;
	}
	cpumask_copy(mask, mm_cpumask(mm));

	/* It's possible that a vcpu may have a stale reference to our
	   cr3, because its in lazy mode, and it hasn't yet flushed
	   its set of pending hypercalls yet.  In this case, we can
	   look at its actual current cr3 value, and force it to flush
	   if needed. */
	for_each_online_cpu(cpu) {
		if (per_cpu(xen_current_cr3, cpu) == __pa(mm->pgd))
			cpumask_set_cpu(cpu, mask);
	}

	if (!cpumask_empty(mask))
		smp_call_function_many(mask, drop_other_mm_ref, mm, 1);
	free_cpumask_var(mask);
}
#else
static void xen_drop_mm_ref(struct mm_struct *mm)
{
	if (current->active_mm == mm)
		load_cr3(swapper_pg_dir);
}
#endif

/*
 * While a process runs, Xen pins its pagetables, which means that the
 * hypervisor forces it to be read-only, and it controls all updates
 * to it.  This means that all pagetable updates have to go via the
 * hypervisor, which is moderately expensive.
 *
 * Since we're pulling the pagetable down, we switch to use init_mm,
 * unpin old process pagetable and mark it all read-write, which
 * allows further operations on it to be simple memory accesses.
 *
 * The only subtle point is that another CPU may be still using the
 * pagetable because of lazy tlb flushing.  This means we need need to
 * switch all CPUs off this pagetable before we can unpin it.
 */
static void xen_exit_mmap(struct mm_struct *mm)
{
	get_cpu();		/* make sure we don't move around */
	xen_drop_mm_ref(mm);
	put_cpu();

	spin_lock(&mm->page_table_lock);

	/* pgd may not be pinned in the error exit path of execve */
	if (xen_page_pinned(mm->pgd))
		xen_pgd_unpin(mm);

	spin_unlock(&mm->page_table_lock);
}

static void __init xen_pagetable_setup_start(pgd_t *base)
{
}

static __init void xen_mapping_pagetable_reserve(u64 start, u64 end)
{
	/* reserve the range used */
	native_pagetable_reserve(start, end);

	/* set as RW the rest */
	printk(KERN_DEBUG "xen: setting RW the range %llx - %llx\n", end,
			PFN_PHYS(pgt_buf_top));
	while (end < PFN_PHYS(pgt_buf_top)) {
		make_lowmem_page_readwrite(__va(end));
		end += PAGE_SIZE;
	}
}

static void xen_post_allocator_init(void);

static void __init xen_pagetable_setup_done(pgd_t *base)
{
	xen_setup_shared_info();

	if (xen_feature(XENFEAT_auto_translated_physmap))
		return;

	xen_post_allocator_init();
}

static void xen_write_cr2(unsigned long cr2)
{
	this_cpu_read(xen_vcpu)->arch.cr2 = cr2;
}

static unsigned long xen_read_cr2(void)
{
	return this_cpu_read(xen_vcpu)->arch.cr2;
}

unsigned long xen_read_cr2_direct(void)
{
	return this_cpu_read(xen_vcpu_info.arch.cr2);
}

static void xen_flush_tlb(void)
{
	struct mmuext_op *op;
	struct multicall_space mcs;

	trace_xen_mmu_flush_tlb(0);

	preempt_disable();

	mcs = xen_mc_entry(sizeof(*op));

	op = mcs.args;
	op->cmd = MMUEXT_TLB_FLUSH_LOCAL;
	MULTI_mmuext_op(mcs.mc, op, 1, NULL, DOMID_SELF);

	xen_mc_issue(PARAVIRT_LAZY_MMU);

	preempt_enable();
}

static void xen_flush_tlb_single(unsigned long addr)
{
	struct mmuext_op *op;
	struct multicall_space mcs;

	trace_xen_mmu_flush_tlb_single(addr);

	preempt_disable();

	mcs = xen_mc_entry(sizeof(*op));
	op = mcs.args;
	op->cmd = MMUEXT_INVLPG_LOCAL;
	op->arg1.linear_addr = addr & PAGE_MASK;
	MULTI_mmuext_op(mcs.mc, op, 1, NULL, DOMID_SELF);

	xen_mc_issue(PARAVIRT_LAZY_MMU);

	preempt_enable();
}

static void xen_flush_tlb_others(const struct cpumask *cpus,
				 struct mm_struct *mm, unsigned long start,
				 unsigned long end)
{
	struct {
		struct mmuext_op op;
#ifdef CONFIG_SMP
		DECLARE_BITMAP(mask, num_processors);
#else
		DECLARE_BITMAP(mask, NR_CPUS);
#endif
	} *args;
	struct multicall_space mcs;

	trace_xen_mmu_flush_tlb_others(cpus, mm, start, end);

	if (cpumask_empty(cpus))
		return;		/* nothing to do */

	mcs = xen_mc_entry(sizeof(*args));
	args = mcs.args;
	args->op.arg2.vcpumask = to_cpumask(args->mask);

	/* Remove us, and any offline CPUS. */
	cpumask_and(to_cpumask(args->mask), cpus, cpu_online_mask);
	cpumask_clear_cpu(smp_processor_id(), to_cpumask(args->mask));

	args->op.cmd = MMUEXT_TLB_FLUSH_MULTI;
	if (start != TLB_FLUSH_ALL && (end - start) <= PAGE_SIZE) {
		args->op.cmd = MMUEXT_INVLPG_MULTI;
		args->op.arg1.linear_addr = start;
	}

	MULTI_mmuext_op(mcs.mc, &args->op, 1, NULL, DOMID_SELF);

	xen_mc_issue(PARAVIRT_LAZY_MMU);
}

static unsigned long xen_read_cr3(void)
{
	return this_cpu_read(xen_cr3);
}

static void set_current_cr3(void *v)
{
	this_cpu_write(xen_current_cr3, (unsigned long)v);
}

static void __xen_write_cr3(bool kernel, unsigned long cr3)
{
	struct mmuext_op op;
	unsigned long mfn;

	trace_xen_mmu_write_cr3(kernel, cr3);

	if (cr3)
		mfn = pfn_to_mfn(PFN_DOWN(cr3));
	else
		mfn = 0;

	WARN_ON(mfn == 0 && kernel);

	op.cmd = kernel ? MMUEXT_NEW_BASEPTR : MMUEXT_NEW_USER_BASEPTR;
	op.arg1.mfn = mfn;

	xen_extend_mmuext_op(&op);

	if (kernel) {
		this_cpu_write(xen_cr3, cr3);

		/* Update xen_current_cr3 once the batch has actually
		   been submitted. */
		xen_mc_callback(set_current_cr3, (void *)cr3);
	}
}

static void xen_write_cr3(unsigned long cr3)
{
	BUG_ON(preemptible());

	xen_mc_batch();  /* disables interrupts */

	/* Update while interrupts are disabled, so its atomic with
	   respect to ipis */
	this_cpu_write(xen_cr3, cr3);

	__xen_write_cr3(true, cr3);

#ifdef CONFIG_X86_64
	{
		pgd_t *user_pgd = xen_get_user_pgd(__va(cr3));
		if (user_pgd)
			__xen_write_cr3(false, __pa(user_pgd));
		else
			__xen_write_cr3(false, 0);
	}
#endif

	xen_mc_issue(PARAVIRT_LAZY_CPU);  /* interrupts restored */
}

static int xen_pgd_alloc(struct mm_struct *mm)
{
	pgd_t *pgd = mm->pgd;
	int ret = 0;

	BUG_ON(PagePinned(virt_to_page(pgd)));

#ifdef CONFIG_X86_64
	{
		struct page *page = virt_to_page(pgd);
		pgd_t *user_pgd;

		BUG_ON(page->private != 0);

		ret = -ENOMEM;

		user_pgd = (pgd_t *)__get_free_page(GFP_KERNEL | __GFP_ZERO);
		page->private = (unsigned long)user_pgd;

		if (user_pgd != NULL) {
			user_pgd[pgd_index(VSYSCALL_START)] =
				__pgd(__pa(level3_user_vsyscall) | _PAGE_TABLE);
			ret = 0;
		}

		BUG_ON(PagePinned(virt_to_page(xen_get_user_pgd(pgd))));
	}
#endif

	return ret;
}

static void xen_pgd_free(struct mm_struct *mm, pgd_t *pgd)
{
#ifdef CONFIG_X86_64
	pgd_t *user_pgd = xen_get_user_pgd(pgd);

	if (user_pgd)
		free_page((unsigned long)user_pgd);
#endif
}

#ifdef CONFIG_X86_32
static pte_t __init mask_rw_pte(pte_t *ptep, pte_t pte)
{
	/* If there's an existing pte, then don't allow _PAGE_RW to be set */
	if (pte_val_ma(*ptep) & _PAGE_PRESENT)
		pte = __pte_ma(((pte_val_ma(*ptep) & _PAGE_RW) | ~_PAGE_RW) &
			       pte_val_ma(pte));

	return pte;
}
#else /* CONFIG_X86_64 */
static pte_t __init mask_rw_pte(pte_t *ptep, pte_t pte)
{
	unsigned long pfn = pte_pfn(pte);

	/*
	 * If the new pfn is within the range of the newly allocated
	 * kernel pagetable, and it isn't being mapped into an
	 * early_ioremap fixmap slot as a freshly allocated page, make sure
	 * it is RO.
	 */
	if (((!is_early_ioremap_ptep(ptep) &&
			pfn >= pgt_buf_start && pfn < pgt_buf_top)) ||
			(is_early_ioremap_ptep(ptep) && pfn != (pgt_buf_end - 1)))
		pte = pte_wrprotect(pte);

	return pte;
}
#endif /* CONFIG_X86_64 */

/*
 * Init-time set_pte while constructing initial pagetables, which
 * doesn't allow RO page table pages to be remapped RW.
 *
 * If there is no MFN for this PFN then this page is initially
 * ballooned out so clear the PTE (as in decrease_reservation() in
 * drivers/xen/balloon.c).
 *
 * Many of these PTE updates are done on unpinned and writable pages
 * and doing a hypercall for these is unnecessary and expensive.  At
 * this point it is not possible to tell if a page is pinned or not,
 * so always write the PTE directly and rely on Xen trapping and
 * emulating any updates as necessary.
 */
static void __init xen_set_pte_init(pte_t *ptep, pte_t pte)
{
	if (pte_mfn(pte) != INVALID_P2M_ENTRY)
		pte = mask_rw_pte(ptep, pte);
	else
		pte = __pte_ma(0);

	native_set_pte(ptep, pte);
}

static noinline void pin_pagetable_pfn(unsigned cmd, unsigned long pfn)
{
	struct mmuext_op op;

	if (xen_feature(XENFEAT_writable_page_tables))
		return;

	op.cmd = cmd;
	op.arg1.mfn = pfn_to_mfn(pfn);
	if (HYPERVISOR_mmuext_op(&op, 1, NULL, DOMID_SELF))
		BUG();
}

/* Early in boot, while setting up the initial pagetable, assume
   everything is pinned. */
static void __init xen_alloc_pte_init(struct mm_struct *mm, unsigned long pfn)
{
#ifdef CONFIG_FLATMEM
	BUG_ON(mem_map);	/* should only be used early */
#endif
	make_lowmem_page_readonly(__va(PFN_PHYS(pfn)));
	pin_pagetable_pfn(MMUEXT_PIN_L1_TABLE, pfn);
}

/* Used for pmd and pud */
static void __init xen_alloc_pmd_init(struct mm_struct *mm, unsigned long pfn)
{
#ifdef CONFIG_FLATMEM
	BUG_ON(mem_map);	/* should only be used early */
#endif
	make_lowmem_page_readonly(__va(PFN_PHYS(pfn)));
}

/* Early release_pte assumes that all pts are pinned, since there's
   only init_mm and anything attached to that is pinned. */
static void __init xen_release_pte_init(unsigned long pfn)
{
	pin_pagetable_pfn(MMUEXT_UNPIN_TABLE, pfn);
	make_lowmem_page_readwrite(__va(PFN_PHYS(pfn)));
}

static void __init xen_release_pmd_init(unsigned long pfn)
{
	make_lowmem_page_readwrite(__va(PFN_PHYS(pfn)));
}

static inline void __pin_pagetable_pfn(unsigned cmd, unsigned long pfn)
{
	struct multicall_space mcs;
	struct mmuext_op *op;

	mcs = __xen_mc_entry(sizeof(*op));
	op = mcs.args;
	op->cmd = cmd;
	op->arg1.mfn = pfn_to_mfn(pfn);

	MULTI_mmuext_op(mcs.mc, mcs.args, 1, NULL, DOMID_SELF);
}

static inline void __set_pfn_prot(unsigned long pfn, pgprot_t prot)
{
	struct multicall_space mcs;
	unsigned long addr = (unsigned long)__va(pfn << PAGE_SHIFT);

	mcs = __xen_mc_entry(0);
	MULTI_update_va_mapping(mcs.mc, (unsigned long)addr,
				pfn_pte(pfn, prot), 0);
}

/* This needs to make sure the new pte page is pinned iff its being
   attached to a pinned pagetable. */
static inline void xen_alloc_ptpage(struct mm_struct *mm, unsigned long pfn,
				    unsigned level)
{
	bool pinned = PagePinned(virt_to_page(mm->pgd));

	trace_xen_mmu_alloc_ptpage(mm, pfn, level, pinned);

	if (pinned) {
		struct page *page = pfn_to_page(pfn);

		SetPagePinned(page);

		if (!PageHighMem(page)) {
			xen_mc_batch();

			__set_pfn_prot(pfn, PAGE_KERNEL_RO);

			if (level == PT_PTE && USE_SPLIT_PTLOCKS)
				__pin_pagetable_pfn(MMUEXT_PIN_L1_TABLE, pfn);

			xen_mc_issue(PARAVIRT_LAZY_MMU);
		} else {
			/* make sure there are no stray mappings of
			   this page */
			kmap_flush_unused();
		}
	}
}

static void xen_alloc_pte(struct mm_struct *mm, unsigned long pfn)
{
	xen_alloc_ptpage(mm, pfn, PT_PTE);
}

static void xen_alloc_pmd(struct mm_struct *mm, unsigned long pfn)
{
	xen_alloc_ptpage(mm, pfn, PT_PMD);
}

/* This should never happen until we're OK to use struct page */
static inline void xen_release_ptpage(unsigned long pfn, unsigned level)
{
	struct page *page = pfn_to_page(pfn);
	bool pinned = PagePinned(page);

	trace_xen_mmu_release_ptpage(pfn, level, pinned);

	if (pinned) {
		if (!PageHighMem(page)) {
			xen_mc_batch();

			if (level == PT_PTE && USE_SPLIT_PTLOCKS)
				__pin_pagetable_pfn(MMUEXT_UNPIN_TABLE, pfn);

			__set_pfn_prot(pfn, PAGE_KERNEL);

			xen_mc_issue(PARAVIRT_LAZY_MMU);
		}
		ClearPagePinned(page);
	}
}

static void xen_release_pte(unsigned long pfn)
{
	xen_release_ptpage(pfn, PT_PTE);
}

static void xen_release_pmd(unsigned long pfn)
{
	xen_release_ptpage(pfn, PT_PMD);
}

#if PAGETABLE_LEVELS == 4
static void xen_alloc_pud(struct mm_struct *mm, unsigned long pfn)
{
	xen_alloc_ptpage(mm, pfn, PT_PUD);
}

static void xen_release_pud(unsigned long pfn)
{
	xen_release_ptpage(pfn, PT_PUD);
}
#endif

void __init xen_reserve_top(void)
{
#ifdef CONFIG_X86_32
	unsigned long top = HYPERVISOR_VIRT_START;
	struct xen_platform_parameters pp;

	if (HYPERVISOR_xen_version(XENVER_platform_parameters, &pp) == 0)
		top = pp.virt_start;

	reserve_top_address(-top);
#endif	/* CONFIG_X86_32 */
}

/*
 * Like __va(), but returns address in the kernel mapping (which is
 * all we have until the physical memory mapping has been set up.
 */
static void *__ka(phys_addr_t paddr)
{
#ifdef CONFIG_X86_64
	return (void *)(paddr + __START_KERNEL_map);
#else
	return __va(paddr);
#endif
}

/* Convert a machine address to physical address */
static unsigned long m2p(phys_addr_t maddr)
{
	phys_addr_t paddr;

	maddr &= PTE_PFN_MASK;
	paddr = mfn_to_pfn(maddr >> PAGE_SHIFT) << PAGE_SHIFT;

	return paddr;
}

/* Convert a machine address to kernel virtual */
static void *m2v(phys_addr_t maddr)
{
	return __ka(m2p(maddr));
}

/* Set the page permissions on an identity-mapped pages */
static void set_page_prot(void *addr, pgprot_t prot)
{
	unsigned long pfn = __pa(addr) >> PAGE_SHIFT;
	pte_t pte = pfn_pte(pfn, prot);

	/* recall for PVH, page tables are native. */
	if (xen_feature(XENFEAT_auto_translated_physmap))
		return;

	if (HYPERVISOR_update_va_mapping((unsigned long)addr, pte, 0))
		BUG();
}

static void __init xen_map_identity_early(pmd_t *pmd, unsigned long max_pfn)
{
	unsigned pmdidx, pteidx;
	unsigned ident_pte;
	unsigned long pfn;

	level1_ident_pgt = extend_brk(sizeof(pte_t) * LEVEL1_IDENT_ENTRIES,
				      PAGE_SIZE);

	ident_pte = 0;
	pfn = 0;
	for (pmdidx = 0; pmdidx < PTRS_PER_PMD && pfn < max_pfn; pmdidx++) {
		pte_t *pte_page;

		/* Reuse or allocate a page of ptes */
		if (pmd_present(pmd[pmdidx]))
			pte_page = m2v(pmd[pmdidx].pmd);
		else {
			/* Check for free pte pages */
			if (ident_pte == LEVEL1_IDENT_ENTRIES)
				break;

			pte_page = &level1_ident_pgt[ident_pte];
			ident_pte += PTRS_PER_PTE;

			pmd[pmdidx] = __pmd(__pa(pte_page) | _PAGE_TABLE);
		}

		/* Install mappings */
		for (pteidx = 0; pteidx < PTRS_PER_PTE; pteidx++, pfn++) {
			pte_t pte;

#ifdef CONFIG_X86_32
			if (pfn > max_pfn_mapped)
				max_pfn_mapped = pfn;
#endif

			if (!pte_none(pte_page[pteidx]))
				continue;

			pte = pfn_pte(pfn, PAGE_KERNEL_EXEC);
			pte_page[pteidx] = pte;
		}
	}

	for (pteidx = 0; pteidx < ident_pte; pteidx += PTRS_PER_PTE)
		set_page_prot(&level1_ident_pgt[pteidx], PAGE_KERNEL_RO);

	set_page_prot(pmd, PAGE_KERNEL_RO);
}

void __init xen_setup_machphys_mapping(void)
{
	struct xen_machphys_mapping mapping;

	if (HYPERVISOR_memory_op(XENMEM_machphys_mapping, &mapping) == 0) {
		machine_to_phys_mapping = (unsigned long *)mapping.v_start;
		machine_to_phys_nr = mapping.max_mfn + 1;
	} else {
		machine_to_phys_nr = MACH2PHYS_NR_ENTRIES;
	}
#ifdef CONFIG_X86_32
	WARN_ON((machine_to_phys_mapping + (machine_to_phys_nr - 1))
		< machine_to_phys_mapping);
#endif
}

#ifdef CONFIG_X86_64
static void convert_pfn_mfn(void *v)
{
	pte_t *pte = v;
	int i;

	if (xen_feature(XENFEAT_auto_translated_physmap))
		return;

	/* All levels are converted the same way, so just treat them
	   as ptes. */
	for (i = 0; i < PTRS_PER_PTE; i++)
		pte[i] = xen_make_pte(pte[i].pte);
}

/*
 * Set up the initial kernel pagetable.
 *
 * We can construct this by grafting the Xen provided pagetable into
 * head_64.S's preconstructed pagetables.  We copy the Xen L2's into
 * level2_ident_pgt, level2_kernel_pgt and level2_fixmap_pgt.  This
 * means that only the kernel has a physical mapping to start with -
 * but that's enough to get __va working.  We need to fill in the rest
 * of the physical mapping once some sort of allocator has been set
 * up.
 * NOTE: for PVH, the page tables are native.
 */
pgd_t * __init xen_setup_kernel_pagetable(pgd_t *pgd,
					 unsigned long max_pfn)
{
	pud_t *l3;
	pmd_t *l2;

	/* max_pfn_mapped is the last pfn mapped in the initial memory
	 * mappings. Considering that on Xen after the kernel mappings we
	 * have the mappings of some pages that don't exist in pfn space, we
	 * set max_pfn_mapped to the last real pfn mapped. */
	max_pfn_mapped = PFN_DOWN(__pa(xen_start_info->mfn_list));

	/* Zap identity mapping */
	init_level4_pgt[0] = __pgd(0);

	/* Pre-constructed entries are in pfn, so convert to mfn */
	convert_pfn_mfn(init_level4_pgt);
	convert_pfn_mfn(level3_ident_pgt);
	convert_pfn_mfn(level3_kernel_pgt);

	l3 = m2v(pgd[pgd_index(__START_KERNEL_map)].pgd);
	l2 = m2v(l3[pud_index(__START_KERNEL_map)].pud);

	memcpy(level2_ident_pgt, l2, sizeof(pmd_t) * PTRS_PER_PMD);
	memcpy(level2_kernel_pgt, l2, sizeof(pmd_t) * PTRS_PER_PMD);

	l3 = m2v(pgd[pgd_index(__START_KERNEL_map + PMD_SIZE)].pgd);
	l2 = m2v(l3[pud_index(__START_KERNEL_map + PMD_SIZE)].pud);
	memcpy(level2_fixmap_pgt, l2, sizeof(pmd_t) * PTRS_PER_PMD);

	/* Set up identity map */
	xen_map_identity_early(level2_ident_pgt, max_pfn);

	/* Make pagetable pieces RO */
	set_page_prot(init_level4_pgt, PAGE_KERNEL_RO);
	set_page_prot(level3_ident_pgt, PAGE_KERNEL_RO);
	set_page_prot(level3_kernel_pgt, PAGE_KERNEL_RO);
	set_page_prot(level3_user_vsyscall, PAGE_KERNEL_RO);
	set_page_prot(level2_kernel_pgt, PAGE_KERNEL_RO);
	set_page_prot(level2_fixmap_pgt, PAGE_KERNEL_RO);

	/* Pin down new L4 */
	pin_pagetable_pfn(MMUEXT_PIN_L4_TABLE,
		  	PFN_DOWN(__pa_symbol(init_level4_pgt)));

	/* Unpin Xen-provided one */
	pin_pagetable_pfn(MMUEXT_UNPIN_TABLE, PFN_DOWN(__pa(pgd)));

	/* Switch over */
	pgd = init_level4_pgt;

	/*
	 * At this stage there can be no user pgd, and no page
	 * structure to attach it to, so make sure we just set kernel
	 * pgd.
	 */
	if (xen_feature(XENFEAT_writable_page_tables)) {
		native_write_cr3(__pa(pgd));
	} else {
		xen_mc_batch();
		__xen_write_cr3(true, __pa(pgd));
		xen_mc_issue(PARAVIRT_LAZY_CPU);
	}

	memblock_reserve(__pa(xen_start_info->pt_base),
			 xen_start_info->nr_pt_frames * PAGE_SIZE);

	return pgd;
}
#else	/* !CONFIG_X86_64 */
static RESERVE_BRK_ARRAY(pmd_t, initial_kernel_pmd, PTRS_PER_PMD);
static RESERVE_BRK_ARRAY(pmd_t, swapper_kernel_pmd, PTRS_PER_PMD);

static void __init xen_write_cr3_init(unsigned long cr3)
{
	unsigned long pfn = PFN_DOWN(__pa(swapper_pg_dir));

	BUG_ON(read_cr3() != __pa(initial_page_table));
	BUG_ON(cr3 != __pa(swapper_pg_dir));

	/*
	 * We are switching to swapper_pg_dir for the first time (from
	 * initial_page_table) and therefore need to mark that page
	 * read-only and then pin it.
	 *
	 * Xen disallows sharing of kernel PMDs for PAE
	 * guests. Therefore we must copy the kernel PMD from
	 * initial_page_table into a new kernel PMD to be used in
	 * swapper_pg_dir.
	 */
	swapper_kernel_pmd =
		extend_brk(sizeof(pmd_t) * PTRS_PER_PMD, PAGE_SIZE);
	memcpy(swapper_kernel_pmd, initial_kernel_pmd,
	       sizeof(pmd_t) * PTRS_PER_PMD);
	swapper_pg_dir[KERNEL_PGD_BOUNDARY] =
		__pgd(__pa(swapper_kernel_pmd) | _PAGE_PRESENT);
	set_page_prot(swapper_kernel_pmd, PAGE_KERNEL_RO);

	set_page_prot(swapper_pg_dir, PAGE_KERNEL_RO);
	xen_write_cr3(cr3);
	pin_pagetable_pfn(MMUEXT_PIN_L3_TABLE, pfn);

	pin_pagetable_pfn(MMUEXT_UNPIN_TABLE,
			  PFN_DOWN(__pa(initial_page_table)));
	set_page_prot(initial_page_table, PAGE_KERNEL);
	set_page_prot(initial_kernel_pmd, PAGE_KERNEL);

	pv_mmu_ops.write_cr3 = &xen_write_cr3;
}

pgd_t * __init xen_setup_kernel_pagetable(pgd_t *pgd,
					 unsigned long max_pfn)
{
	pmd_t *kernel_pmd;

	initial_kernel_pmd =
		extend_brk(sizeof(pmd_t) * PTRS_PER_PMD, PAGE_SIZE);

	max_pfn_mapped = PFN_DOWN(__pa(xen_start_info->pt_base) +
				  xen_start_info->nr_pt_frames * PAGE_SIZE +
				  512*1024);

	kernel_pmd = m2v(pgd[KERNEL_PGD_BOUNDARY].pgd);
	memcpy(initial_kernel_pmd, kernel_pmd, sizeof(pmd_t) * PTRS_PER_PMD);

	xen_map_identity_early(initial_kernel_pmd, max_pfn);

	memcpy(initial_page_table, pgd, sizeof(pgd_t) * PTRS_PER_PGD);
	initial_page_table[KERNEL_PGD_BOUNDARY] =
		__pgd(__pa(initial_kernel_pmd) | _PAGE_PRESENT);

	set_page_prot(initial_kernel_pmd, PAGE_KERNEL_RO);
	set_page_prot(initial_page_table, PAGE_KERNEL_RO);
	set_page_prot(empty_zero_page, PAGE_KERNEL_RO);

	pin_pagetable_pfn(MMUEXT_UNPIN_TABLE, PFN_DOWN(__pa(pgd)));

	pin_pagetable_pfn(MMUEXT_PIN_L3_TABLE,
			  PFN_DOWN(__pa(initial_page_table)));
	xen_write_cr3(__pa(initial_page_table));

	memblock_reserve(__pa(xen_start_info->pt_base),
			 xen_start_info->nr_pt_frames * PAGE_SIZE);

	return initial_page_table;
}
#endif	/* CONFIG_X86_64 */

static unsigned char dummy_mapping[PAGE_SIZE] __page_aligned_bss;

static void xen_set_fixmap(unsigned idx, phys_addr_t phys, pgprot_t prot)
{
	pte_t pte;

	phys >>= PAGE_SHIFT;

	switch (idx) {
	case FIX_BTMAP_END ... FIX_BTMAP_BEGIN:
#ifdef CONFIG_X86_F00F_BUG
	case FIX_F00F_IDT:
#endif
#ifdef CONFIG_X86_32
	case FIX_WP_TEST:
	case FIX_VDSO:
# ifdef CONFIG_HIGHMEM
	case FIX_KMAP_BEGIN ... FIX_KMAP_END:
# endif
#else
	case VSYSCALL_LAST_PAGE ... VSYSCALL_FIRST_PAGE:
	case VVAR_PAGE:
#endif
	case FIX_TEXT_POKE0:
	case FIX_TEXT_POKE1:
		/* All local page mappings */
		pte = pfn_pte(phys, prot);
		break;

#ifdef CONFIG_X86_LOCAL_APIC
	case FIX_APIC_BASE:	/* maps dummy local APIC */
		pte = pfn_pte(PFN_DOWN(__pa(dummy_mapping)), PAGE_KERNEL);
		break;
#endif

#ifdef CONFIG_X86_IO_APIC
	case FIX_IO_APIC_BASE_0 ... FIX_IO_APIC_BASE_END:
		/*
		 * We just don't map the IO APIC - all access is via
		 * hypercalls.  Keep the address in the pte for reference.
		 */
		pte = pfn_pte(PFN_DOWN(__pa(dummy_mapping)), PAGE_KERNEL);
		break;
#endif

	case FIX_PARAVIRT_BOOTMAP:
		/* This is an MFN, but it isn't an IO mapping from the
		   IO domain */
		pte = mfn_pte(phys, prot);
		break;

	default:
		/* By default, set_fixmap is used for hardware mappings */
		pte = mfn_pte(phys, __pgprot(pgprot_val(prot) | _PAGE_IOMAP));
		break;
	}

	__native_set_fixmap(idx, pte);

#ifdef CONFIG_X86_64
	/* Replicate changes to map the vsyscall page into the user
	   pagetable vsyscall mapping. */
	if ((idx >= VSYSCALL_LAST_PAGE && idx <= VSYSCALL_FIRST_PAGE) ||
	    idx == VVAR_PAGE) {
		unsigned long vaddr = __fix_to_virt(idx);
		set_pte_vaddr_pud(level3_user_vsyscall, vaddr, pte);
	}
#endif
}

static void __init xen_post_allocator_init(void)
{
	pv_mmu_ops.set_pte = xen_set_pte;
	pv_mmu_ops.set_pmd = xen_set_pmd;
	pv_mmu_ops.set_pud = xen_set_pud;
#if PAGETABLE_LEVELS == 4
	pv_mmu_ops.set_pgd = xen_set_pgd;
#endif

	/* This will work as long as patching hasn't happened yet
	   (which it hasn't) */
	pv_mmu_ops.alloc_pte = xen_alloc_pte;
	pv_mmu_ops.alloc_pmd = xen_alloc_pmd;
	pv_mmu_ops.release_pte = xen_release_pte;
	pv_mmu_ops.release_pmd = xen_release_pmd;
#if PAGETABLE_LEVELS == 4
	pv_mmu_ops.alloc_pud = xen_alloc_pud;
	pv_mmu_ops.release_pud = xen_release_pud;
#endif

#ifdef CONFIG_X86_64
	SetPagePinned(virt_to_page(level3_user_vsyscall));
#endif
	xen_mark_init_mm_pinned();
}

static void xen_leave_lazy_mmu(void)
{
	preempt_disable();
	xen_mc_flush();
	paravirt_leave_lazy_mmu();
	preempt_enable();
}

static const struct pv_mmu_ops xen_mmu_ops __initconst = {
	.read_cr2 = xen_read_cr2,
	.write_cr2 = xen_write_cr2,

	.read_cr3 = xen_read_cr3,
#ifdef CONFIG_X86_32
	.write_cr3 = xen_write_cr3_init,
#else
	.write_cr3 = xen_write_cr3,
#endif

	.flush_tlb_user = xen_flush_tlb,
	.flush_tlb_kernel = xen_flush_tlb,
	.flush_tlb_single = xen_flush_tlb_single,
	.flush_tlb_others = xen_flush_tlb_others,

	.pte_update = paravirt_nop,
	.pte_update_defer = paravirt_nop,

	.pgd_alloc = xen_pgd_alloc,
	.pgd_free = xen_pgd_free,

	.alloc_pte = xen_alloc_pte_init,
	.release_pte = xen_release_pte_init,
	.alloc_pmd = xen_alloc_pmd_init,
	.release_pmd = xen_release_pmd_init,

	.set_pte = xen_set_pte_init,
	.set_pte_at = xen_set_pte_at,
	.set_pmd = xen_set_pmd_hyper,

	.ptep_modify_prot_start = __ptep_modify_prot_start,
	.ptep_modify_prot_commit = __ptep_modify_prot_commit,

	.pte_val = PV_CALLEE_SAVE(xen_pte_val),
	.pgd_val = PV_CALLEE_SAVE(xen_pgd_val),

	.make_pte = PV_CALLEE_SAVE(xen_make_pte),
	.make_pgd = PV_CALLEE_SAVE(xen_make_pgd),

#ifdef CONFIG_X86_PAE
	.set_pte_atomic = xen_set_pte_atomic,
	.pte_clear = xen_pte_clear,
	.pmd_clear = xen_pmd_clear,
#endif	/* CONFIG_X86_PAE */
	.set_pud = xen_set_pud_hyper,

	.make_pmd = PV_CALLEE_SAVE(xen_make_pmd),
	.pmd_val = PV_CALLEE_SAVE(xen_pmd_val),

#if PAGETABLE_LEVELS == 4
	.pud_val = PV_CALLEE_SAVE(xen_pud_val),
	.make_pud = PV_CALLEE_SAVE(xen_make_pud),
	.set_pgd = xen_set_pgd_hyper,

	.alloc_pud = xen_alloc_pmd_init,
	.release_pud = xen_release_pmd_init,
#endif	/* PAGETABLE_LEVELS == 4 */

	.activate_mm = xen_activate_mm,
	.dup_mmap = xen_dup_mmap,
	.exit_mmap = xen_exit_mmap,

	.lazy_mode = {
		.enter = paravirt_enter_lazy_mmu,
		.leave = xen_leave_lazy_mmu,
	},

	.set_fixmap = xen_set_fixmap,
};

void __init xen_init_mmu_ops(void)
{
	x86_init.paging.pagetable_setup_done = xen_pagetable_setup_done;

	if (xen_feature(XENFEAT_auto_translated_physmap)) {
		pv_mmu_ops.flush_tlb_others = xen_flush_tlb_others;

		/* set_pte* for PCI devices to map iomem. */
		if (xen_initial_domain()) {
			pv_mmu_ops.set_pte = native_set_pte;
			pv_mmu_ops.set_pte_at = xen_dom0pvh_set_pte_at;
		}
		return;
	}

	x86_init.mapping.pagetable_reserve = xen_mapping_pagetable_reserve;
	x86_init.paging.pagetable_setup_start = xen_pagetable_setup_start;
	pv_mmu_ops = xen_mmu_ops;

	memset(dummy_mapping, 0xff, PAGE_SIZE);
}

/* Protected by xen_reservation_lock. */
#define MAX_CONTIG_ORDER 9 /* 2MB */
static unsigned long discontig_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,
				unsigned long *in_frames,
				unsigned long *out_frames)
{
	int i;
	struct multicall_space mcs;

	xen_mc_batch();
	for (i = 0; i < (1UL<<order); i++, vaddr += PAGE_SIZE) {
		mcs = __xen_mc_entry(0);

		if (in_frames)
			in_frames[i] = virt_to_mfn(vaddr);

		MULTI_update_va_mapping(mcs.mc, vaddr, VOID_PTE, 0);
		__set_phys_to_machine(virt_to_pfn(vaddr), INVALID_P2M_ENTRY);

		if (out_frames)
			out_frames[i] = virt_to_pfn(vaddr);
	}
	xen_mc_issue(0);
}

/*
 * Update the pfn-to-mfn mappings for a virtual address range, either to
 * point to an array of mfns, or contiguously from a single starting
 * mfn.
 */
static void xen_remap_exchanged_ptes(unsigned long vaddr, int order,
				     unsigned long *mfns,
				     unsigned long first_mfn)
{
	unsigned i, limit;
	unsigned long mfn;

	xen_mc_batch();

	limit = 1u << order;
	for (i = 0; i < limit; i++, vaddr += PAGE_SIZE) {
		struct multicall_space mcs;
		unsigned flags;

		mcs = __xen_mc_entry(0);
		if (mfns)
			mfn = mfns[i];
		else
			mfn = first_mfn + i;

		if (i < (limit - 1))
			flags = 0;
		else {
			if (order == 0)
				flags = UVMF_INVLPG | UVMF_ALL;
			else
				flags = UVMF_TLB_FLUSH | UVMF_ALL;
		}

		MULTI_update_va_mapping(mcs.mc, vaddr,
				mfn_pte(mfn, PAGE_KERNEL), flags);

		set_phys_to_machine(virt_to_pfn(vaddr), mfn);
	}

	xen_mc_issue(0);
}

/*
 * Perform the hypercall to exchange a region of our pfns to point to
 * memory with the required contiguous alignment.  Takes the pfns as
 * input, and populates mfns as output.
 *
 * Returns a success code indicating whether the hypervisor was able to
 * satisfy the request or not.
 */
static int xen_exchange_memory(unsigned long extents_in, unsigned int order_in,
			       unsigned long *pfns_in,
			       unsigned long extents_out,
			       unsigned int order_out,
			       unsigned long *mfns_out,
			       unsigned int address_bits)
{
	long rc;
	int success;

	struct xen_memory_exchange exchange = {
		.in = {
			.nr_extents   = extents_in,
			.extent_order = order_in,
			.extent_start = pfns_in,
			.domid        = DOMID_SELF
		},
		.out = {
			.nr_extents   = extents_out,
			.extent_order = order_out,
			.extent_start = mfns_out,
			.address_bits = address_bits,
			.domid        = DOMID_SELF
		}
	};

	BUG_ON(extents_in << order_in != extents_out << order_out);

	rc = HYPERVISOR_memory_op(XENMEM_exchange, &exchange);
	success = (exchange.nr_exchanged == extents_in);

	BUG_ON(!success && ((exchange.nr_exchanged != 0) || (rc == 0)));
	BUG_ON(success && (rc != 0));

	return success;
}

int xen_create_contiguous_region(unsigned long vstart, unsigned int order,
				 unsigned int address_bits)
{
	unsigned long *in_frames = discontig_frames, out_frame;
	unsigned long  flags;
	int            success;

	/*
	 * Currently an auto-translated guest will not perform I/O, nor will
	 * it require PAE page directories below 4GB. Therefore any calls to
	 * this function are redundant and can be ignored.
	 */

	if (xen_feature(XENFEAT_auto_translated_physmap))
		return 0;

	if (unlikely(order > MAX_CONTIG_ORDER))
		return -ENOMEM;

	memset((void *) vstart, 0, PAGE_SIZE << order);

	spin_lock_irqsave(&xen_reservation_lock, flags);

	/* 1. Zap current PTEs, remembering MFNs. */
	xen_zap_pfn_range(vstart, order, in_frames, NULL);

	/* 2. Get a new contiguous memory extent. */
	out_frame = virt_to_pfn(vstart);
	success = xen_exchange_memory(1UL << order, 0, in_frames,
				      1, order, &out_frame,
				      address_bits);

	/* 3. Map the new extent in place of old pages. */
	if (success)
		xen_remap_exchanged_ptes(vstart, order, NULL, out_frame);
	else
		xen_remap_exchanged_ptes(vstart, order, in_frames, 0);

	spin_unlock_irqrestore(&xen_reservation_lock, flags);

	return success ? 0 : -ENOMEM;
}
EXPORT_SYMBOL_GPL(xen_create_contiguous_region);

void xen_destroy_contiguous_region(unsigned long vstart, unsigned int order)
{
	unsigned long *out_frames = discontig_frames, in_frame;
	unsigned long  flags;
	int success;

	if (xen_feature(XENFEAT_auto_translated_physmap))
		return;

	if (unlikely(order > MAX_CONTIG_ORDER))
		return;

	memset((void *) vstart, 0, PAGE_SIZE << order);

	spin_lock_irqsave(&xen_reservation_lock, flags);

	/* 1. Find start MFN of contiguous extent. */
	in_frame = virt_to_mfn(vstart);

	/* 2. Zap current PTEs. */
	xen_zap_pfn_range(vstart, order, NULL, out_frames);

	/* 3. Do the exchange for non-contiguous MFNs. */
	success = xen_exchange_memory(1, order, &in_frame, 1UL << order,
					0, out_frames, 0);

	/* 4. Map new pages in place of old pages. */
	if (success)
		xen_remap_exchanged_ptes(vstart, order, out_frames, 0);
	else
		xen_remap_exchanged_ptes(vstart, order, NULL, in_frame);

	spin_unlock_irqrestore(&xen_reservation_lock, flags);
}
EXPORT_SYMBOL_GPL(xen_destroy_contiguous_region);

#ifdef CONFIG_XEN_PVHVM
static void xen_hvm_exit_mmap(struct mm_struct *mm)
{
	struct xen_hvm_pagetable_dying a;
	int rc;

	a.domid = DOMID_SELF;
	a.gpa = __pa(mm->pgd);
	rc = HYPERVISOR_hvm_op(HVMOP_pagetable_dying, &a);
	WARN_ON_ONCE(rc < 0);
}

static int is_pagetable_dying_supported(void)
{
	struct xen_hvm_pagetable_dying a;
	int rc = 0;

	a.domid = DOMID_SELF;
	a.gpa = 0x00;
	rc = HYPERVISOR_hvm_op(HVMOP_pagetable_dying, &a);
	if (rc < 0) {
		printk(KERN_DEBUG "HVMOP_pagetable_dying not supported\n");
		return 0;
	}
	return 1;
}

void __init xen_hvm_init_mmu_ops(void)
{
	if (is_pagetable_dying_supported())
		pv_mmu_ops.exit_mmap = xen_hvm_exit_mmap;
}
#endif

/* Map foreign gmfn, fgmfn, to local pfn, lpfn. This for the user space 
 * creating new guest on PVH dom0 and needs to map domU pages. Called from
 * exported function, so no need to export this.
 */
static noinline int pvh_add_to_xen_p2m(unsigned long lpfn, unsigned long fgmfn,
			      unsigned int domid)
{
	int rc;
	struct xen_add_to_physmap xatp = { .foreign_domid = domid };

	xatp.gpfn = lpfn;
	xatp.idx = fgmfn;
	xatp.space = XENMAPSPACE_gmfn_foreign;
	rc = HYPERVISOR_memory_op(XENMEM_add_to_physmap, &xatp);
	if (rc)
		pr_warn("d0: Failed to map pfn to mfn rc:%d pfn:%lx mfn:%lx\n", 
			rc, lpfn, fgmfn); 
	return rc;
}

int pvh_rem_xen_p2m(unsigned long spfn, int count)
{
	struct xen_remove_from_physmap xrp;
	int i, rc;

	for (i=0; i < count; i++) {
		xrp.domid = DOMID_SELF;
		xrp.gpfn = spfn+i;
		rc = HYPERVISOR_memory_op(XENMEM_remove_from_physmap, &xrp);
		if (rc) {
			pr_warn("Failed to unmap pfn:%lx rc:%d done:%d\n",
				spfn+i, rc, i);
			return 1;
		}
	}
	return 0;
}
EXPORT_SYMBOL_GPL(pvh_rem_xen_p2m);

struct pvh_remap_data {
	unsigned long fgmfn;		/* foreign domain's gmfn */
	pgprot_t prot;
	domid_t  domid;
	struct vm_area_struct *vma;
};

static noinline int pvh_map_pte_fn(pte_t *ptep, pgtable_t token, unsigned long addr, 
			void *data)
{
	int rc;
	struct pvh_remap_data *pvhp = data;
	struct xen_pvh_sav_pfn_info *savp = pvhp->vma->vm_private_data;
	unsigned long pfn = page_to_pfn(savp->sp_paga[savp->sp_next_todo++]);
	pte_t pteval = pte_mkspecial(pfn_pte(pfn, pvhp->prot));

	if ((rc=pvh_add_to_xen_p2m(pfn, pvhp->fgmfn, pvhp->domid)))
		return rc;
	native_set_pte(ptep, pteval);
	savp->sp_addr = addr;

	return 0;
}

/* The only caller at moment passes one gmfn at a time.
 * PVH TBD/FIXME: expand this in future to honor batch requests.
 */
static noinline int pvh_remap_gmfn_range(struct vm_area_struct *vma,
				unsigned long addr, unsigned long mfn, int nr,
				pgprot_t prot, unsigned domid)
{
	int err;
	struct pvh_remap_data pvhdata;

	if (nr > 1)
		return -EINVAL;

	pvhdata.fgmfn = mfn;
	pvhdata.prot = prot;
	pvhdata.domid = domid;
	pvhdata.vma = vma;
	err = apply_to_page_range(vma->vm_mm, addr, nr << PAGE_SHIFT,
				  pvh_map_pte_fn, &pvhdata);
	flush_tlb_all();
	return err;
}

#define REMAP_BATCH_SIZE 16

struct remap_data {
	unsigned long mfn;
	pgprot_t prot;
	struct mmu_update *mmu_update;
};

static int remap_area_mfn_pte_fn(pte_t *ptep, pgtable_t token,
				 unsigned long addr, void *data)
{
	struct remap_data *rmd = data;
	pte_t pte = pte_mkspecial(pfn_pte(rmd->mfn++, rmd->prot));

	rmd->mmu_update->ptr = virt_to_machine(ptep).maddr;
	rmd->mmu_update->val = pte_val_ma(pte);
	rmd->mmu_update++;

	return 0;
}

int xen_remap_domain_mfn_range(struct vm_area_struct *vma,
			       unsigned long addr,
			       unsigned long mfn, int nr,
			       pgprot_t prot, unsigned domid)
{
	struct remap_data rmd;
	struct mmu_update mmu_update[REMAP_BATCH_SIZE];
	int batch;
	unsigned long range;
	int err = 0;

	prot = __pgprot(pgprot_val(prot) | _PAGE_IOMAP);

	BUG_ON(!((vma->vm_flags & (VM_PFNMAP | VM_RESERVED | VM_IO)) ==
				(VM_PFNMAP | VM_RESERVED | VM_IO)));

	if (xen_feature(XENFEAT_auto_translated_physmap)) {
		/* We need to update the local page tables and the xen HAP */
		return pvh_remap_gmfn_range(vma, addr, mfn, nr, prot, domid);
	}

	rmd.mfn = mfn;
	rmd.prot = prot;

	while (nr) {
		batch = min(REMAP_BATCH_SIZE, nr);
		range = (unsigned long)batch << PAGE_SHIFT;

		rmd.mmu_update = mmu_update;
		err = apply_to_page_range(vma->vm_mm, addr, range,
					  remap_area_mfn_pte_fn, &rmd);
		if (err)
			goto out;

		err = -EFAULT;
		if (HYPERVISOR_mmu_update(mmu_update, batch, NULL, domid) < 0)
			goto out;

		nr -= batch;
		addr += range;
	}

	err = 0;
out:

	flush_tlb_all();

	return err;
}
EXPORT_SYMBOL_GPL(xen_remap_domain_mfn_range);

int xen_unmap_domain_mfn_range(struct vm_area_struct *vma)
{
	struct xen_pvh_sav_pfn_info *savp = vma ? vma->vm_private_data : NULL;

	if (!savp || !xen_feature(XENFEAT_auto_translated_physmap))
		return 0;

	while (savp->sp_next_todo--) {
		unsigned long pfn;
#if 0
		unsigned int level;
		pte_t *ptep = lookup_address(savp->sp_addr, &level);

		set_pte(ptep, __pte(0));
#endif
		pfn = page_to_pfn(savp->sp_paga[savp->sp_next_todo]);
		pvh_rem_xen_p2m(pfn, 1);

		free_xenballooned_pages(1, &savp->sp_paga[savp->sp_next_todo]);
	}

	flush_tlb_all();
	return 0;
}
EXPORT_SYMBOL_GPL(xen_unmap_domain_mfn_range);

--MP_/VbujuzxBRJmnncQgGTu8kEI
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 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_/VbujuzxBRJmnncQgGTu8kEI--


From xen-devel-bounces@lists.xen.org Thu Sep 13 01:19:51 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Sep 2012 01:19:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TBy5T-0002Sm-8i; Thu, 13 Sep 2012 01:19: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 1TBy5Q-0002Sh-MU
	for Xen-devel@lists.xensource.com; Thu, 13 Sep 2012 01:19:21 +0000
Received: from [85.158.143.99:31556] by server-1.bemta-4.messagelabs.com id
	96/DD-12504-79431505; Thu, 13 Sep 2012 01:19:19 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1347499157!30052064!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzM3MjU3\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31406 invoked from network); 13 Sep 2012 01:19:18 -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; 13 Sep 2012 01:19:18 -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 q8D1JEEW028339
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 13 Sep 2012 01:19: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
	q8D1JDp7004476
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 13 Sep 2012 01:19:14 GMT
Received: from abhmt104.oracle.com (abhmt104.oracle.com [141.146.116.56])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q8D1JDus032643; Wed, 12 Sep 2012 20:19:13 -0500
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 12 Sep 2012 18:19:12 -0700
Date: Wed, 12 Sep 2012 18:19:10 -0700
From: Mukesh Rathor <mukesh.rathor@oracle.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120912181910.6b0b9d2b@mantra.us.oracle.com>
In-Reply-To: <1347372623.5305.170.camel@zakaz.uk.xensource.com>
References: <20120815180716.0049bffe@mantra.us.oracle.com>
	<1347372623.5305.170.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_/VbujuzxBRJmnncQgGTu8kEI"
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: "Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [RFC PATCH 8/8]: PVH: privcmd 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>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--MP_/VbujuzxBRJmnncQgGTu8kEI
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

On Tue, 11 Sep 2012 15:10:23 +0100
Ian Campbell <Ian.Campbell@citrix.com> wrote:

> I think you can't rely on the implicit teardown here since you need to
> unmap before you hand the page back to the balloon. The reason this
> doesn't look necessary now is that you don't give the page back.
> Also not ordering the stage 1 and stage 2 teardown correctly is
> dangerous, depending on the eventual ordering you potentially turn an
> erroneous access to a virtual address, which should result in a guest
> OS level page fault (and e.g. a seg fault to the offending process)
> into a hypervisor shoots the guest due to an unexpected stage 2 fault
> type failure, which is somewhat undesirable ;-)
> 
> With that in mind I think you do in the end need to add
> xen_unmap_domain_mfn_range which does the unmap from both stage 1 and
> stage 2 -- that balances out the interface (making pvh_rem_xen_p2m
> internal) too, which is nice. This function may turn out to be a nop
> on !pvh, but that's ok (although maybe there would be no harm in doing
> explicit unmaps, for consistency?).
 
Ok, I added xen_unmap_domain_mfn_range(). Take a look. It appears that
by the time privcmd_close() is called, the kernel has already freed 
process resources and lookup_address() returns NULL. Now I am wondering
if the kernel/mmu does anything to the page while shooting the pte
entry. Well the page was orig from balloon, so the cleanup hopefully
leaves it alone.

I had looked for other hooks initially when I did this, but 
vm_operations_struct->close was the only one to pan out.

I can't really move pvh_privcmd_resv_pfns to mmu.c because the 
xen_remap_domain_mfn_range is called one page at a time, and I need
to allocate the array first. I'd have to change it to linked list, worth
it? Or I'd have to move and export it.


> WRT passing data between interfaces in vma->vm_private, which is
> pretty subtle, can we push that whole thing down into
> xen_{remap,unmap}_domain_mfn_range too? This would make the
> requirement on the caller be simple "never use vm_private", as
> opposed to now where the requirement is "sometimes you might have to
> allocate some stuff and stick it in here". The downside is that it
> pushes code which could be generic down into per-arch stuff, although
> with suitable generic helper functions this isn't so bad (whatever
> happened to {alloc,free}_empty_pages_and_pagevec from the classic
> kernels? Those did exactly what we want here, I think)

Well, it has to hang off of vma->vm_private. The alternative would be to
have a hash table by process id or something, again not sure if worth it. 

Take a look at my latest files attached. Now the alloc_balloon and free
are split between privcmd and mmu.c. The alternative would be to call 
xen_unmap_domain_mfn_range one pfn at a time and have it call 
pvh_rem_xen_p2m(), and move free_xenballooned_pages to privcmd. But
that would be same as just changing the name of pvh_rem_xen_p2m to
xen_unmap_domain_mfn_range(). Also, remap and unmap won't be much
symmetric then.

Not sure if there's a lot we could do here to be honest. LMK what you 
think.

thanks,
Mukesh


--MP_/VbujuzxBRJmnncQgGTu8kEI
Content-Type: text/x-c++src
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename=privcmd.c

/******************************************************************************
 * privcmd.c
 *
 * Interface to privileged domain-0 commands.
 *
 * Copyright (c) 2002-2004, K A Fraser, B Dragovic
 */

#include <linux/kernel.h>
#include <linux/module.h>
#include <linux/sched.h>
#include <linux/slab.h>
#include <linux/string.h>
#include <linux/errno.h>
#include <linux/mm.h>
#include <linux/mman.h>
#include <linux/uaccess.h>
#include <linux/swap.h>
#include <linux/highmem.h>
#include <linux/pagemap.h>
#include <linux/seq_file.h>
#include <linux/miscdevice.h>

#include <asm/pgalloc.h>
#include <asm/pgtable.h>
#include <asm/tlb.h>
#include <asm/xen/hypervisor.h>
#include <asm/xen/hypercall.h>

#include <xen/xen.h>
#include <xen/privcmd.h>
#include <xen/interface/xen.h>
#include <xen/features.h>
#include <xen/page.h>
#include <xen/xen-ops.h>
#include <xen/balloon.h>

#include "privcmd.h"

MODULE_LICENSE("GPL");

#ifndef HAVE_ARCH_PRIVCMD_MMAP
static int privcmd_enforce_singleshot_mapping(struct vm_area_struct *vma);
#endif

static long privcmd_ioctl_hypercall(void __user *udata)
{
	struct privcmd_hypercall hypercall;
	long ret;

	if (copy_from_user(&hypercall, udata, sizeof(hypercall)))
		return -EFAULT;

	ret = privcmd_call(hypercall.op,
			   hypercall.arg[0], hypercall.arg[1],
			   hypercall.arg[2], hypercall.arg[3],
			   hypercall.arg[4]);

	return ret;
}

static void free_page_list(struct list_head *pages)
{
	struct page *p, *n;

	list_for_each_entry_safe(p, n, pages, lru)
		__free_page(p);

	INIT_LIST_HEAD(pages);
}

/*
 * Given an array of items in userspace, return a list of pages
 * containing the data.  If copying fails, either because of memory
 * allocation failure or a problem reading user memory, return an
 * error code; its up to the caller to dispose of any partial list.
 */
static int gather_array(struct list_head *pagelist,
			unsigned nelem, size_t size,
			void __user *data)
{
	unsigned pageidx;
	void *pagedata;
	int ret;

	if (size > PAGE_SIZE)
		return 0;

	pageidx = PAGE_SIZE;
	pagedata = NULL;	/* quiet, gcc */
	while (nelem--) {
		if (pageidx > PAGE_SIZE-size) {
			struct page *page = alloc_page(GFP_KERNEL);

			ret = -ENOMEM;
			if (page == NULL)
				goto fail;

			pagedata = page_address(page);

			list_add_tail(&page->lru, pagelist);
			pageidx = 0;
		}

		ret = -EFAULT;
		if (copy_from_user(pagedata + pageidx, data, size))
			goto fail;

		data += size;
		pageidx += size;
	}

	ret = 0;

fail:
	return ret;
}

/*
 * Call function "fn" on each element of the array fragmented
 * over a list of pages.
 */
static int traverse_pages(unsigned nelem, size_t size,
			  struct list_head *pos,
			  int (*fn)(void *data, void *state),
			  void *state)
{
	void *pagedata;
	unsigned pageidx;
	int ret = 0;

	BUG_ON(size > PAGE_SIZE);

	pageidx = PAGE_SIZE;
	pagedata = NULL;	/* hush, gcc */

	while (nelem--) {
		if (pageidx > PAGE_SIZE-size) {
			struct page *page;
			pos = pos->next;
			page = list_entry(pos, struct page, lru);
			pagedata = page_address(page);
			pageidx = 0;
		}

		ret = (*fn)(pagedata + pageidx, state);
		if (ret)
			break;
		pageidx += size;
	}

	return ret;
}

struct mmap_mfn_state {
	unsigned long va;
	struct vm_area_struct *vma;
	domid_t domain;
};

static int mmap_mfn_range(void *data, void *state)
{
	struct privcmd_mmap_entry *msg = data;
	struct mmap_mfn_state *st = state;
	struct vm_area_struct *vma = st->vma;
	int rc;

	/* Do not allow range to wrap the address space. */
	if ((msg->npages > (LONG_MAX >> PAGE_SHIFT)) ||
	    ((unsigned long)(msg->npages << PAGE_SHIFT) >= -st->va))
		return -EINVAL;

	/* Range chunks must be contiguous in va space. */
	if ((msg->va != st->va) ||
	    ((msg->va+(msg->npages<<PAGE_SHIFT)) > vma->vm_end))
		return -EINVAL;

	rc = xen_remap_domain_mfn_range(vma,
					msg->va & PAGE_MASK,
					msg->mfn, msg->npages,
					vma->vm_page_prot,
					st->domain);
	if (rc < 0)
		return rc;

	st->va += msg->npages << PAGE_SHIFT;

	return 0;
}

static long privcmd_ioctl_mmap(void __user *udata)
{
	struct privcmd_mmap mmapcmd;
	struct mm_struct *mm = current->mm;
	struct vm_area_struct *vma;
	int rc;
	LIST_HEAD(pagelist);
	struct mmap_mfn_state state;

	if (!xen_initial_domain())
		return -EPERM;

	/* PVH: TBD/FIXME. For now we only support privcmd_ioctl_mmap_batch */
	if (xen_pv_domain() && xen_feature(XENFEAT_auto_translated_physmap))
		return -ENOSYS;

	if (copy_from_user(&mmapcmd, udata, sizeof(mmapcmd)))
		return -EFAULT;

	rc = gather_array(&pagelist,
			  mmapcmd.num, sizeof(struct privcmd_mmap_entry),
			  mmapcmd.entry);

	if (rc || list_empty(&pagelist))
		goto out;

	down_write(&mm->mmap_sem);

	{
		struct page *page = list_first_entry(&pagelist,
						     struct page, lru);
		struct privcmd_mmap_entry *msg = page_address(page);

		vma = find_vma(mm, msg->va);
		rc = -EINVAL;

		if (!vma || (msg->va != vma->vm_start) ||
		    !privcmd_enforce_singleshot_mapping(vma))
			goto out_up;
	}

	state.va = vma->vm_start;
	state.vma = vma;
	state.domain = mmapcmd.dom;

	rc = traverse_pages(mmapcmd.num, sizeof(struct privcmd_mmap_entry),
			    &pagelist,
			    mmap_mfn_range, &state);


out_up:
	up_write(&mm->mmap_sem);

out:
	free_page_list(&pagelist);

	return rc;
}

struct mmap_batch_state {
	domid_t domain;
	unsigned long va;
	struct vm_area_struct *vma;
	int err;

	xen_pfn_t __user *user;
};

/* PVH dom0 fyi: if domU being created is PV, then mfn is mfn(addr on bus). If 
 * it's PVH then mfn is pfn (input to HAP). */
static int mmap_batch_fn(void *data, void *state)
{
	xen_pfn_t *mfnp = data;
	struct mmap_batch_state *st = state;

	if (xen_remap_domain_mfn_range(st->vma, st->va & PAGE_MASK, *mfnp, 1,
				       st->vma->vm_page_prot, st->domain) < 0) {
		*mfnp |= 0xf0000000U;
		st->err++;
	}
	st->va += PAGE_SIZE;

	return 0;
}

static int mmap_return_errors(void *data, void *state)
{
	xen_pfn_t *mfnp = data;
	struct mmap_batch_state *st = state;

	return put_user(*mfnp, st->user++);
}

/* Allocate pfns that are then mapped with gmfns from foreign domid. Update
 * the vma with the page info to use later.
 * Returns: 0 if success, otherwise -errno
 */ 
static int pvh_privcmd_resv_pfns(struct vm_area_struct *vma, int numpgs)
{
	int rc;
	struct xen_pvh_sav_pfn_info *savp;

	savp = kzalloc(sizeof(struct xen_pvh_sav_pfn_info), GFP_KERNEL);
	if (savp == NULL)
		return -ENOMEM;

	savp->sp_paga = kcalloc(numpgs, sizeof(savp->sp_paga[0]), GFP_KERNEL);
	if (savp->sp_paga == NULL) {
		kfree(savp);
		return -ENOMEM;
	}

	rc = alloc_xenballooned_pages(numpgs, savp->sp_paga, 0);
	if (rc != 0) {
		pr_warn("%s Could not alloc %d pfns rc:%d\n", __FUNCTION__, 
			numpgs, rc);
		kfree(savp->sp_paga);
		kfree(savp);
		return -ENOMEM;
	}
	savp->sp_num_pgs = numpgs;
	BUG_ON(vma->vm_private_data);
	vma->vm_private_data = savp;

	return 0;
}

static struct vm_operations_struct privcmd_vm_ops;

static long privcmd_ioctl_mmap_batch(void __user *udata)
{
	int ret;
	struct privcmd_mmapbatch m;
	struct mm_struct *mm = current->mm;
	struct vm_area_struct *vma;
	unsigned long nr_pages;
	LIST_HEAD(pagelist);
	struct mmap_batch_state state;

	if (!xen_initial_domain())
		return -EPERM;

	if (copy_from_user(&m, udata, sizeof(m)))
		return -EFAULT;

	nr_pages = m.num;
	if ((m.num <= 0) || (nr_pages > (LONG_MAX >> PAGE_SHIFT)))
		return -EINVAL;

	ret = gather_array(&pagelist, m.num, sizeof(xen_pfn_t),
			   m.arr);

	if (ret || list_empty(&pagelist))
		goto out;

	down_write(&mm->mmap_sem);

	vma = find_vma(mm, m.addr);
	ret = -EINVAL;
	if (!vma ||
	    vma->vm_ops != &privcmd_vm_ops ||
	    (m.addr != vma->vm_start) ||
	    ((m.addr + (nr_pages << PAGE_SHIFT)) != vma->vm_end) ||
	    !privcmd_enforce_singleshot_mapping(vma)) {
		up_write(&mm->mmap_sem);
		goto out;
	}

	if (xen_pv_domain() && xen_feature(XENFEAT_auto_translated_physmap)) {
		if ((ret=pvh_privcmd_resv_pfns(vma, m.num))) {
			up_write(&mm->mmap_sem);
			goto out;
		}
	}
	state.domain = m.dom;
	state.vma = vma;
	state.va = m.addr;
	state.err = 0;

	ret = traverse_pages(m.num, sizeof(xen_pfn_t),
			     &pagelist, mmap_batch_fn, &state);

	up_write(&mm->mmap_sem);

	if (state.err > 0) {
		state.user = m.arr;
		ret = traverse_pages(m.num, sizeof(xen_pfn_t),
			       &pagelist,
			       mmap_return_errors, &state);
	}

out:
	free_page_list(&pagelist);

	return ret;
}

static long privcmd_ioctl(struct file *file,
			  unsigned int cmd, unsigned long data)
{
	int ret = -ENOSYS;
	void __user *udata = (void __user *) data;

	switch (cmd) {
	case IOCTL_PRIVCMD_HYPERCALL:
		ret = privcmd_ioctl_hypercall(udata);
		break;

	case IOCTL_PRIVCMD_MMAP:
		ret = privcmd_ioctl_mmap(udata);
		break;

	case IOCTL_PRIVCMD_MMAPBATCH:
		ret = privcmd_ioctl_mmap_batch(udata);
		break;

	default:
		ret = -EINVAL;
		break;
	}

	return ret;
}

static void privcmd_close(struct vm_area_struct *vma)
{
	struct xen_pvh_sav_pfn_info *savp = vma->vm_private_data;

	if (!xen_pv_domain()  || 
	    !xen_feature(XENFEAT_auto_translated_physmap)  ||
	    !vma->vm_private_data)
		return;

	xen_unmap_domain_mfn_range(vma);
	kfree(savp->sp_paga);
	kfree(savp);
}

static int privcmd_fault(struct vm_area_struct *vma, struct vm_fault *vmf)
{
	printk(KERN_DEBUG "privcmd_fault: vma=%p %lx-%lx, pgoff=%lx, uv=%p\n",
	       vma, vma->vm_start, vma->vm_end,
	       vmf->pgoff, vmf->virtual_address);

	return VM_FAULT_SIGBUS;
}

static struct vm_operations_struct privcmd_vm_ops = {
	.close = privcmd_close,
	.fault = privcmd_fault
};

static int privcmd_mmap(struct file *file, struct vm_area_struct *vma)
{
	/* DONTCOPY is essential for Xen because copy_page_range doesn't know
	 * how to recreate these mappings */
	vma->vm_flags |= VM_RESERVED | VM_IO | VM_DONTCOPY | VM_PFNMAP;
	vma->vm_ops = &privcmd_vm_ops;
	vma->vm_private_data = NULL;

	return 0;
}

static int privcmd_enforce_singleshot_mapping(struct vm_area_struct *vma)
{
	if (xen_pv_domain() && xen_feature(XENFEAT_auto_translated_physmap))
		/* NOTE : make this atomic ********************** */
		return (vma->vm_private_data == NULL);

	return (xchg(&vma->vm_private_data, (void *)1) == NULL);
}

const struct file_operations xen_privcmd_fops = {
	.owner = THIS_MODULE,
	.unlocked_ioctl = privcmd_ioctl,
	.mmap = privcmd_mmap,
};
EXPORT_SYMBOL_GPL(xen_privcmd_fops);

static struct miscdevice privcmd_dev = {
	.minor = MISC_DYNAMIC_MINOR,
	.name = "xen/privcmd",
	.fops = &xen_privcmd_fops,
};

static int __init privcmd_init(void)
{
	int err;

	if (!xen_domain())
		return -ENODEV;

	err = misc_register(&privcmd_dev);
	if (err != 0) {
		printk(KERN_ERR "Could not register Xen privcmd device\n");
		return err;
	}
	return 0;
}

static void __exit privcmd_exit(void)
{
	misc_deregister(&privcmd_dev);
}

module_init(privcmd_init);
module_exit(privcmd_exit);

--MP_/VbujuzxBRJmnncQgGTu8kEI
Content-Type: text/x-c++src
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename=mmu.c

/*
 * Xen mmu operations
 *
 * This file contains the various mmu fetch and update operations.
 * The most important job they must perform is the mapping between the
 * domain's pfn and the overall machine mfns.
 *
 * Xen allows guests to directly update the pagetable, in a controlled
 * fashion.  In other words, the guest modifies the same pagetable
 * that the CPU actually uses, which eliminates the overhead of having
 * a separate shadow pagetable.
 *
 * In order to allow this, it falls on the guest domain to map its
 * notion of a "physical" pfn - which is just a domain-local linear
 * address - into a real "machine address" which the CPU's MMU can
 * use.
 *
 * A pgd_t/pmd_t/pte_t will typically contain an mfn, and so can be
 * inserted directly into the pagetable.  When creating a new
 * pte/pmd/pgd, it converts the passed pfn into an mfn.  Conversely,
 * when reading the content back with __(pgd|pmd|pte)_val, it converts
 * the mfn back into a pfn.
 *
 * The other constraint is that all pages which make up a pagetable
 * must be mapped read-only in the guest.  This prevents uncontrolled
 * guest updates to the pagetable.  Xen strictly enforces this, and
 * will disallow any pagetable update which will end up mapping a
 * pagetable page RW, and will disallow using any writable page as a
 * pagetable.
 *
 * Naively, when loading %cr3 with the base of a new pagetable, Xen
 * would need to validate the whole pagetable before going on.
 * Naturally, this is quite slow.  The solution is to "pin" a
 * pagetable, which enforces all the constraints on the pagetable even
 * when it is not actively in use.  This menas that Xen can be assured
 * that it is still valid when you do load it into %cr3, and doesn't
 * need to revalidate it.
 *
 * Jeremy Fitzhardinge <jeremy@xensource.com>, XenSource Inc, 2007
 */
#include <linux/sched.h>
#include <linux/highmem.h>
#include <linux/debugfs.h>
#include <linux/bug.h>
#include <linux/vmalloc.h>
#include <linux/module.h>
#include <linux/gfp.h>
#include <linux/memblock.h>
#include <linux/seq_file.h>

#include <trace/events/xen.h>

#include <asm/pgtable.h>
#include <asm/tlbflush.h>
#include <asm/fixmap.h>
#include <asm/mmu_context.h>
#include <asm/setup.h>
#include <asm/paravirt.h>
#include <asm/e820.h>
#include <asm/linkage.h>
#include <asm/page.h>
#include <asm/init.h>
#include <asm/pat.h>
#include <asm/smp.h>

#include <asm/xen/hypercall.h>
#include <asm/xen/hypervisor.h>

#include <xen/xen.h>
#include <xen/page.h>
#include <xen/interface/xen.h>
#include <xen/interface/hvm/hvm_op.h>
#include <xen/interface/version.h>
#include <xen/interface/memory.h>
#include <xen/hvc-console.h>
#include <xen/balloon.h>

#include "multicalls.h"
#include "mmu.h"
#include "debugfs.h"

/*
 * Protects atomic reservation decrease/increase against concurrent increases.
 * Also protects non-atomic updates of current_pages and balloon lists.
 */
DEFINE_SPINLOCK(xen_reservation_lock);

/*
 * Identity map, in addition to plain kernel map.  This needs to be
 * large enough to allocate page table pages to allocate the rest.
 * Each page can map 2MB.
 */
#define LEVEL1_IDENT_ENTRIES	(PTRS_PER_PTE * 4)
static RESERVE_BRK_ARRAY(pte_t, level1_ident_pgt, LEVEL1_IDENT_ENTRIES);

#ifdef CONFIG_X86_64
/* l3 pud for userspace vsyscall mapping */
static pud_t level3_user_vsyscall[PTRS_PER_PUD] __page_aligned_bss;
#endif /* CONFIG_X86_64 */

/*
 * Note about cr3 (pagetable base) values:
 *
 * xen_cr3 contains the current logical cr3 value; it contains the
 * last set cr3.  This may not be the current effective cr3, because
 * its update may be being lazily deferred.  However, a vcpu looking
 * at its own cr3 can use this value knowing that it everything will
 * be self-consistent.
 *
 * xen_current_cr3 contains the actual vcpu cr3; it is set once the
 * hypercall to set the vcpu cr3 is complete (so it may be a little
 * out of date, but it will never be set early).  If one vcpu is
 * looking at another vcpu's cr3 value, it should use this variable.
 */
DEFINE_PER_CPU(unsigned long, xen_cr3);	 /* cr3 stored as physaddr */
DEFINE_PER_CPU(unsigned long, xen_current_cr3);	 /* actual vcpu cr3 */


/*
 * Just beyond the highest usermode address.  STACK_TOP_MAX has a
 * redzone above it, so round it up to a PGD boundary.
 */
#define USER_LIMIT	((STACK_TOP_MAX + PGDIR_SIZE - 1) & PGDIR_MASK)

unsigned long arbitrary_virt_to_mfn(void *vaddr)
{
	xmaddr_t maddr = arbitrary_virt_to_machine(vaddr);

	return PFN_DOWN(maddr.maddr);
}

xmaddr_t arbitrary_virt_to_machine(void *vaddr)
{
	unsigned long address = (unsigned long)vaddr;
	unsigned int level;
	pte_t *pte;
	unsigned offset;

	/*
	 * if the PFN is in the linear mapped vaddr range, we can just use
	 * the (quick) virt_to_machine() p2m lookup
	 */
	if (virt_addr_valid(vaddr))
		return virt_to_machine(vaddr);

	/* otherwise we have to do a (slower) full page-table walk */

	pte = lookup_address(address, &level);
	BUG_ON(pte == NULL);
	offset = address & ~PAGE_MASK;
	return XMADDR(((phys_addr_t)pte_mfn(*pte) << PAGE_SHIFT) + offset);
}
EXPORT_SYMBOL_GPL(arbitrary_virt_to_machine);

void make_lowmem_page_readonly(void *vaddr)
{
	pte_t *pte, ptev;
	unsigned long address = (unsigned long)vaddr;
	unsigned int level;

	pte = lookup_address(address, &level);
	if (pte == NULL)
		return;		/* vaddr missing */

	ptev = pte_wrprotect(*pte);

	if (HYPERVISOR_update_va_mapping(address, ptev, 0))
		BUG();
}

void make_lowmem_page_readwrite(void *vaddr)
{
	pte_t *pte, ptev;
	unsigned long address = (unsigned long)vaddr;
	unsigned int level;

	pte = lookup_address(address, &level);
	if (pte == NULL)
		return;		/* vaddr missing */

	ptev = pte_mkwrite(*pte);

	if (HYPERVISOR_update_va_mapping(address, ptev, 0))
		BUG();
}


static bool xen_page_pinned(void *ptr)
{
	struct page *page = virt_to_page(ptr);

	return PagePinned(page);
}

void xen_set_domain_pte(pte_t *ptep, pte_t pteval, unsigned domid)
{
	struct multicall_space mcs;
	struct mmu_update *u;

	trace_xen_mmu_set_domain_pte(ptep, pteval, domid);

	mcs = xen_mc_entry(sizeof(*u));
	u = mcs.args;

	/* ptep might be kmapped when using 32-bit HIGHPTE */
	u->ptr = virt_to_machine(ptep).maddr;
	u->val = pte_val_ma(pteval);

	MULTI_mmu_update(mcs.mc, mcs.args, 1, NULL, domid);

	xen_mc_issue(PARAVIRT_LAZY_MMU);
}
EXPORT_SYMBOL_GPL(xen_set_domain_pte);

static void xen_extend_mmu_update(const struct mmu_update *update)
{
	struct multicall_space mcs;
	struct mmu_update *u;

	mcs = xen_mc_extend_args(__HYPERVISOR_mmu_update, sizeof(*u));

	if (mcs.mc != NULL) {
		mcs.mc->args[1]++;
	} else {
		mcs = __xen_mc_entry(sizeof(*u));
		MULTI_mmu_update(mcs.mc, mcs.args, 1, NULL, DOMID_SELF);
	}

	u = mcs.args;
	*u = *update;
}

static void xen_extend_mmuext_op(const struct mmuext_op *op)
{
	struct multicall_space mcs;
	struct mmuext_op *u;

	mcs = xen_mc_extend_args(__HYPERVISOR_mmuext_op, sizeof(*u));

	if (mcs.mc != NULL) {
		mcs.mc->args[1]++;
	} else {
		mcs = __xen_mc_entry(sizeof(*u));
		MULTI_mmuext_op(mcs.mc, mcs.args, 1, NULL, DOMID_SELF);
	}

	u = mcs.args;
	*u = *op;
}

static void xen_set_pmd_hyper(pmd_t *ptr, pmd_t val)
{
	struct mmu_update u;

	preempt_disable();

	xen_mc_batch();

	/* ptr may be ioremapped for 64-bit pagetable setup */
	u.ptr = arbitrary_virt_to_machine(ptr).maddr;
	u.val = pmd_val_ma(val);
	xen_extend_mmu_update(&u);

	xen_mc_issue(PARAVIRT_LAZY_MMU);

	preempt_enable();
}

static void xen_set_pmd(pmd_t *ptr, pmd_t val)
{
	trace_xen_mmu_set_pmd(ptr, val);

	/* If page is not pinned, we can just update the entry
	   directly */
	if (!xen_page_pinned(ptr)) {
		*ptr = val;
		return;
	}

	xen_set_pmd_hyper(ptr, val);
}

/*
 * Associate a virtual page frame with a given physical page frame
 * and protection flags for that frame.
 */
void set_pte_mfn(unsigned long vaddr, unsigned long mfn, pgprot_t flags)
{
	set_pte_vaddr(vaddr, mfn_pte(mfn, flags));
}

static bool xen_batched_set_pte(pte_t *ptep, pte_t pteval)
{
	struct mmu_update u;

	if (paravirt_get_lazy_mode() != PARAVIRT_LAZY_MMU)
		return false;

	xen_mc_batch();

	u.ptr = virt_to_machine(ptep).maddr | MMU_NORMAL_PT_UPDATE;
	u.val = pte_val_ma(pteval);
	xen_extend_mmu_update(&u);

	xen_mc_issue(PARAVIRT_LAZY_MMU);

	return true;
}

static inline void __xen_set_pte(pte_t *ptep, pte_t 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)
{
	trace_xen_mmu_set_pte(ptep, pteval);
	__xen_set_pte(ptep, pteval);
}

void xen_set_clr_mmio_pvh_pte(unsigned long pfn, unsigned long mfn, 
			      int nr_mfns, int add_mapping)
{
	struct physdev_map_iomem iomem;

	iomem.first_gfn = pfn;
	iomem.first_mfn = mfn;
	iomem.nr_mfns = nr_mfns;
	iomem.add_mapping = add_mapping;

	if (HYPERVISOR_physdev_op(PHYSDEVOP_pvh_map_iomem, &iomem))
		BUG();
}

static void xen_dom0pvh_set_pte_at(struct mm_struct *mm, unsigned long addr,
		    		   pte_t *ptep, pte_t pteval)
{
	native_set_pte(ptep, pteval);
}

static void xen_set_pte_at(struct mm_struct *mm, unsigned long addr,
		    pte_t *ptep, pte_t pteval)
{
	trace_xen_mmu_set_pte_at(mm, addr, ptep, pteval);
	__xen_set_pte(ptep, pteval);
}

pte_t xen_ptep_modify_prot_start(struct mm_struct *mm,
				 unsigned long addr, pte_t *ptep)
{
	/* Just return the pte as-is.  We preserve the bits on commit */
	trace_xen_mmu_ptep_modify_prot_start(mm, addr, ptep, *ptep);
	return *ptep;
}

void xen_ptep_modify_prot_commit(struct mm_struct *mm, unsigned long addr,
				 pte_t *ptep, pte_t pte)
{
	struct mmu_update u;

	trace_xen_mmu_ptep_modify_prot_commit(mm, addr, ptep, pte);
	xen_mc_batch();

	u.ptr = virt_to_machine(ptep).maddr | MMU_PT_UPDATE_PRESERVE_AD;
	u.val = pte_val_ma(pte);
	xen_extend_mmu_update(&u);

	xen_mc_issue(PARAVIRT_LAZY_MMU);
}

/* Assume pteval_t is equivalent to all the other *val_t types. */
static pteval_t pte_mfn_to_pfn(pteval_t val)
{
	if (val & _PAGE_PRESENT) {
		unsigned long mfn = (val & PTE_PFN_MASK) >> PAGE_SHIFT;
		unsigned long pfn = mfn_to_pfn(mfn);

		pteval_t flags = val & PTE_FLAGS_MASK;
		if (unlikely(pfn == ~0))
			val = flags & ~_PAGE_PRESENT;
		else
			val = ((pteval_t)pfn << PAGE_SHIFT) | flags;
	}

	return val;
}

static pteval_t pte_pfn_to_mfn(pteval_t val)
{
	if (val & _PAGE_PRESENT) {
		unsigned long pfn = (val & PTE_PFN_MASK) >> PAGE_SHIFT;
		pteval_t flags = val & PTE_FLAGS_MASK;
		unsigned long mfn;

		if (!xen_feature(XENFEAT_auto_translated_physmap))
			mfn = get_phys_to_machine(pfn);
		else
			mfn = pfn;
		/*
		 * If there's no mfn for the pfn, then just create an
		 * empty non-present pte.  Unfortunately this loses
		 * information about the original pfn, so
		 * pte_mfn_to_pfn is asymmetric.
		 */
		if (unlikely(mfn == INVALID_P2M_ENTRY)) {
			mfn = 0;
			flags = 0;
		} else {
			/*
			 * Paramount to do this test _after_ the
			 * INVALID_P2M_ENTRY as INVALID_P2M_ENTRY &
			 * IDENTITY_FRAME_BIT resolves to true.
			 */
			mfn &= ~FOREIGN_FRAME_BIT;
			if (mfn & IDENTITY_FRAME_BIT) {
				mfn &= ~IDENTITY_FRAME_BIT;
				flags |= _PAGE_IOMAP;
			}
		}
		val = ((pteval_t)mfn << PAGE_SHIFT) | flags;
	}

	return val;
}

static pteval_t iomap_pte(pteval_t val)
{
	if (val & _PAGE_PRESENT) {
		unsigned long pfn = (val & PTE_PFN_MASK) >> PAGE_SHIFT;
		pteval_t flags = val & PTE_FLAGS_MASK;

		/* We assume the pte frame number is a MFN, so
		   just use it as-is. */
		val = ((pteval_t)pfn << PAGE_SHIFT) | flags;
	}

	return val;
}

static pteval_t xen_pte_val(pte_t pte)
{
	pteval_t pteval = pte.pte;
#if 0
	/* If this is a WC pte, convert back from Xen WC to Linux WC */
	if ((pteval & (_PAGE_PAT | _PAGE_PCD | _PAGE_PWT)) == _PAGE_PAT) {
		WARN_ON(!pat_enabled);
		pteval = (pteval & ~_PAGE_PAT) | _PAGE_PWT;
	}
#endif
	if (xen_initial_domain() && (pteval & _PAGE_IOMAP))
		return pteval;

	return pte_mfn_to_pfn(pteval);
}
PV_CALLEE_SAVE_REGS_THUNK(xen_pte_val);

static pgdval_t xen_pgd_val(pgd_t pgd)
{
	return pte_mfn_to_pfn(pgd.pgd);
}
PV_CALLEE_SAVE_REGS_THUNK(xen_pgd_val);

/*
 * Xen's PAT setup is part of its ABI, though I assume entries 6 & 7
 * are reserved for now, to correspond to the Intel-reserved PAT
 * types.
 *
 * We expect Linux's PAT set as follows:
 *
 * Idx  PTE flags        Linux    Xen    Default
 * 0                     WB       WB     WB
 * 1            PWT      WC       WT     WT
 * 2        PCD          UC-      UC-    UC-
 * 3        PCD PWT      UC       UC     UC
 * 4    PAT              WB       WC     WB
 * 5    PAT     PWT      WC       WP     WT
 * 6    PAT PCD          UC-      UC     UC-
 * 7    PAT PCD PWT      UC       UC     UC
 */

void xen_set_pat(u64 pat)
{
	/* We expect Linux to use a PAT setting of
	 * UC UC- WC WB (ignoring the PAT flag) */
	WARN_ON(pat != 0x0007010600070106ull);
}

static pte_t xen_make_pte(pteval_t pte)
{
	phys_addr_t addr = (pte & PTE_PFN_MASK);
#if 0
	/* If Linux is trying to set a WC pte, then map to the Xen WC.
	 * If _PAGE_PAT is set, then it probably means it is really
	 * _PAGE_PSE, so avoid fiddling with the PAT mapping and hope
	 * things work out OK...
	 *
	 * (We should never see kernel mappings with _PAGE_PSE set,
	 * but we could see hugetlbfs mappings, I think.).
	 */
	if (pat_enabled && !WARN_ON(pte & _PAGE_PAT)) {
		if ((pte & (_PAGE_PCD | _PAGE_PWT)) == _PAGE_PWT)
			pte = (pte & ~(_PAGE_PCD | _PAGE_PWT)) | _PAGE_PAT;
	}
#endif
	/*
	 * Unprivileged domains are allowed to do IOMAPpings for
	 * PCI passthrough, but not map ISA space.  The ISA
	 * mappings are just dummy local mappings to keep other
	 * parts of the kernel happy.
	 */
	if (unlikely(pte & _PAGE_IOMAP) &&
	    (xen_initial_domain() || addr >= ISA_END_ADDRESS)) {
		pte = iomap_pte(pte);
	} else {
		pte &= ~_PAGE_IOMAP;
		pte = pte_pfn_to_mfn(pte);
	}

	return native_make_pte(pte);
}
PV_CALLEE_SAVE_REGS_THUNK(xen_make_pte);

static pgd_t xen_make_pgd(pgdval_t pgd)
{
	pgd = pte_pfn_to_mfn(pgd);
	return native_make_pgd(pgd);
}
PV_CALLEE_SAVE_REGS_THUNK(xen_make_pgd);

static pmdval_t xen_pmd_val(pmd_t pmd)
{
	return pte_mfn_to_pfn(pmd.pmd);
}
PV_CALLEE_SAVE_REGS_THUNK(xen_pmd_val);

static void xen_set_pud_hyper(pud_t *ptr, pud_t val)
{
	struct mmu_update u;

	preempt_disable();

	xen_mc_batch();

	/* ptr may be ioremapped for 64-bit pagetable setup */
	u.ptr = arbitrary_virt_to_machine(ptr).maddr;
	u.val = pud_val_ma(val);
	xen_extend_mmu_update(&u);

	xen_mc_issue(PARAVIRT_LAZY_MMU);

	preempt_enable();
}

static void xen_set_pud(pud_t *ptr, pud_t val)
{
	trace_xen_mmu_set_pud(ptr, val);

	/* If page is not pinned, we can just update the entry
	   directly */
	if (!xen_page_pinned(ptr)) {
		*ptr = val;
		return;
	}

	xen_set_pud_hyper(ptr, val);
}

#ifdef CONFIG_X86_PAE
static void xen_set_pte_atomic(pte_t *ptep, pte_t pte)
{
	trace_xen_mmu_set_pte_atomic(ptep, pte);
	set_64bit((u64 *)ptep, native_pte_val(pte));
}

static void xen_pte_clear(struct mm_struct *mm, unsigned long addr, pte_t *ptep)
{
	trace_xen_mmu_pte_clear(mm, addr, ptep);
	if (!xen_batched_set_pte(ptep, native_make_pte(0)))
		native_pte_clear(mm, addr, ptep);
}

static void xen_pmd_clear(pmd_t *pmdp)
{
	trace_xen_mmu_pmd_clear(pmdp);
	set_pmd(pmdp, __pmd(0));
}
#endif	/* CONFIG_X86_PAE */

static pmd_t xen_make_pmd(pmdval_t pmd)
{
	pmd = pte_pfn_to_mfn(pmd);
	return native_make_pmd(pmd);
}
PV_CALLEE_SAVE_REGS_THUNK(xen_make_pmd);

#if PAGETABLE_LEVELS == 4
static pudval_t xen_pud_val(pud_t pud)
{
	return pte_mfn_to_pfn(pud.pud);
}
PV_CALLEE_SAVE_REGS_THUNK(xen_pud_val);

static pud_t xen_make_pud(pudval_t pud)
{
	pud = pte_pfn_to_mfn(pud);

	return native_make_pud(pud);
}
PV_CALLEE_SAVE_REGS_THUNK(xen_make_pud);

static pgd_t *xen_get_user_pgd(pgd_t *pgd)
{
	pgd_t *pgd_page = (pgd_t *)(((unsigned long)pgd) & PAGE_MASK);
	unsigned offset = pgd - pgd_page;
	pgd_t *user_ptr = NULL;

	if (offset < pgd_index(USER_LIMIT)) {
		struct page *page = virt_to_page(pgd_page);
		user_ptr = (pgd_t *)page->private;
		if (user_ptr)
			user_ptr += offset;
	}

	return user_ptr;
}

static void __xen_set_pgd_hyper(pgd_t *ptr, pgd_t val)
{
	struct mmu_update u;

	u.ptr = virt_to_machine(ptr).maddr;
	u.val = pgd_val_ma(val);
	xen_extend_mmu_update(&u);
}

/*
 * Raw hypercall-based set_pgd, intended for in early boot before
 * there's a page structure.  This implies:
 *  1. The only existing pagetable is the kernel's
 *  2. It is always pinned
 *  3. It has no user pagetable attached to it
 */
static void __init xen_set_pgd_hyper(pgd_t *ptr, pgd_t val)
{
	preempt_disable();

	xen_mc_batch();

	__xen_set_pgd_hyper(ptr, val);

	xen_mc_issue(PARAVIRT_LAZY_MMU);

	preempt_enable();
}

static void xen_set_pgd(pgd_t *ptr, pgd_t val)
{
	pgd_t *user_ptr = xen_get_user_pgd(ptr);

	trace_xen_mmu_set_pgd(ptr, user_ptr, val);

	/* If page is not pinned, we can just update the entry
	   directly */
	if (!xen_page_pinned(ptr)) {
		*ptr = val;
		if (user_ptr) {
			WARN_ON(xen_page_pinned(user_ptr));
			*user_ptr = val;
		}
		return;
	}

	/* If it's pinned, then we can at least batch the kernel and
	   user updates together. */
	xen_mc_batch();

	__xen_set_pgd_hyper(ptr, val);
	if (user_ptr)
		__xen_set_pgd_hyper(user_ptr, val);

	xen_mc_issue(PARAVIRT_LAZY_MMU);
}
#endif	/* PAGETABLE_LEVELS == 4 */

/*
 * (Yet another) pagetable walker.  This one is intended for pinning a
 * pagetable.  This means that it walks a pagetable and calls the
 * callback function on each page it finds making up the page table,
 * at every level.  It walks the entire pagetable, but it only bothers
 * pinning pte pages which are below limit.  In the normal case this
 * will be STACK_TOP_MAX, but at boot we need to pin up to
 * FIXADDR_TOP.
 *
 * For 32-bit the important bit is that we don't pin beyond there,
 * because then we start getting into Xen's ptes.
 *
 * For 64-bit, we must skip the Xen hole in the middle of the address
 * space, just after the big x86-64 virtual hole.
 */
static int __xen_pgd_walk(struct mm_struct *mm, pgd_t *pgd,
			  int (*func)(struct mm_struct *mm, struct page *,
				      enum pt_level),
			  unsigned long limit)
{
	int flush = 0;
	unsigned hole_low, hole_high;
	unsigned pgdidx_limit, pudidx_limit, pmdidx_limit;
	unsigned pgdidx, pudidx, pmdidx;

	/* The limit is the last byte to be touched */
	limit--;
	BUG_ON(limit >= FIXADDR_TOP);

	if (xen_feature(XENFEAT_auto_translated_physmap))
		return 0;

	/*
	 * 64-bit has a great big hole in the middle of the address
	 * space, which contains the Xen mappings.  On 32-bit these
	 * will end up making a zero-sized hole and so is a no-op.
	 */
	hole_low = pgd_index(USER_LIMIT);
	hole_high = pgd_index(PAGE_OFFSET);

	pgdidx_limit = pgd_index(limit);
#if PTRS_PER_PUD > 1
	pudidx_limit = pud_index(limit);
#else
	pudidx_limit = 0;
#endif
#if PTRS_PER_PMD > 1
	pmdidx_limit = pmd_index(limit);
#else
	pmdidx_limit = 0;
#endif

	for (pgdidx = 0; pgdidx <= pgdidx_limit; pgdidx++) {
		pud_t *pud;

		if (pgdidx >= hole_low && pgdidx < hole_high)
			continue;

		if (!pgd_val(pgd[pgdidx]))
			continue;

		pud = pud_offset(&pgd[pgdidx], 0);

		if (PTRS_PER_PUD > 1) /* not folded */
			flush |= (*func)(mm, virt_to_page(pud), PT_PUD);

		for (pudidx = 0; pudidx < PTRS_PER_PUD; pudidx++) {
			pmd_t *pmd;

			if (pgdidx == pgdidx_limit &&
			    pudidx > pudidx_limit)
				goto out;

			if (pud_none(pud[pudidx]))
				continue;

			pmd = pmd_offset(&pud[pudidx], 0);

			if (PTRS_PER_PMD > 1) /* not folded */
				flush |= (*func)(mm, virt_to_page(pmd), PT_PMD);

			for (pmdidx = 0; pmdidx < PTRS_PER_PMD; pmdidx++) {
				struct page *pte;

				if (pgdidx == pgdidx_limit &&
				    pudidx == pudidx_limit &&
				    pmdidx > pmdidx_limit)
					goto out;

				if (pmd_none(pmd[pmdidx]))
					continue;

				pte = pmd_page(pmd[pmdidx]);
				flush |= (*func)(mm, pte, PT_PTE);
			}
		}
	}

out:
	/* Do the top level last, so that the callbacks can use it as
	   a cue to do final things like tlb flushes. */
	flush |= (*func)(mm, virt_to_page(pgd), PT_PGD);

	return flush;
}

static int xen_pgd_walk(struct mm_struct *mm,
			int (*func)(struct mm_struct *mm, struct page *,
				    enum pt_level),
			unsigned long limit)
{
	return __xen_pgd_walk(mm, mm->pgd, func, limit);
}

/* If we're using split pte locks, then take the page's lock and
   return a pointer to it.  Otherwise return NULL. */
static spinlock_t *xen_pte_lock(struct page *page, struct mm_struct *mm)
{
	spinlock_t *ptl = NULL;

#if USE_SPLIT_PTLOCKS
	ptl = __pte_lockptr(page);
	spin_lock_nest_lock(ptl, &mm->page_table_lock);
#endif

	return ptl;
}

static void xen_pte_unlock(void *v)
{
	spinlock_t *ptl = v;
	spin_unlock(ptl);
}

static void xen_do_pin(unsigned level, unsigned long pfn)
{
	struct mmuext_op op;

	op.cmd = level;
	op.arg1.mfn = pfn_to_mfn(pfn);

	xen_extend_mmuext_op(&op);
}

static int xen_pin_page(struct mm_struct *mm, struct page *page,
			enum pt_level level)
{
	unsigned pgfl = TestSetPagePinned(page);
	int flush;

	if (pgfl)
		flush = 0;		/* already pinned */
	else if (PageHighMem(page))
		/* kmaps need flushing if we found an unpinned
		   highpage */
		flush = 1;
	else {
		void *pt = lowmem_page_address(page);
		unsigned long pfn = page_to_pfn(page);
		struct multicall_space mcs = __xen_mc_entry(0);
		spinlock_t *ptl;

		flush = 0;

		/*
		 * We need to hold the pagetable lock between the time
		 * we make the pagetable RO and when we actually pin
		 * it.  If we don't, then other users may come in and
		 * attempt to update the pagetable by writing it,
		 * which will fail because the memory is RO but not
		 * pinned, so Xen won't do the trap'n'emulate.
		 *
		 * If we're using split pte locks, we can't hold the
		 * entire pagetable's worth of locks during the
		 * traverse, because we may wrap the preempt count (8
		 * bits).  The solution is to mark RO and pin each PTE
		 * page while holding the lock.  This means the number
		 * of locks we end up holding is never more than a
		 * batch size (~32 entries, at present).
		 *
		 * If we're not using split pte locks, we needn't pin
		 * the PTE pages independently, because we're
		 * protected by the overall pagetable lock.
		 */
		ptl = NULL;
		if (level == PT_PTE)
			ptl = xen_pte_lock(page, mm);

		MULTI_update_va_mapping(mcs.mc, (unsigned long)pt,
					pfn_pte(pfn, PAGE_KERNEL_RO),
					level == PT_PGD ? UVMF_TLB_FLUSH : 0);

		if (ptl) {
			xen_do_pin(MMUEXT_PIN_L1_TABLE, pfn);

			/* Queue a deferred unlock for when this batch
			   is completed. */
			xen_mc_callback(xen_pte_unlock, ptl);
		}
	}

	return flush;
}

/* This is called just after a mm has been created, but it has not
   been used yet.  We need to make sure that its pagetable is all
   read-only, and can be pinned. */
static void __xen_pgd_pin(struct mm_struct *mm, pgd_t *pgd)
{
	trace_xen_mmu_pgd_pin(mm, pgd);

	xen_mc_batch();

	if (__xen_pgd_walk(mm, pgd, xen_pin_page, USER_LIMIT)) {
		/* re-enable interrupts for flushing */
		xen_mc_issue(0);

		kmap_flush_unused();

		xen_mc_batch();
	}

#ifdef CONFIG_X86_64
	{
		pgd_t *user_pgd = xen_get_user_pgd(pgd);

		xen_do_pin(MMUEXT_PIN_L4_TABLE, PFN_DOWN(__pa(pgd)));

		if (user_pgd) {
			xen_pin_page(mm, virt_to_page(user_pgd), PT_PGD);
			xen_do_pin(MMUEXT_PIN_L4_TABLE,
				   PFN_DOWN(__pa(user_pgd)));
		}
	}
#else /* CONFIG_X86_32 */
#ifdef CONFIG_X86_PAE
	/* Need to make sure unshared kernel PMD is pinnable */
	xen_pin_page(mm, pgd_page(pgd[pgd_index(TASK_SIZE)]),
		     PT_PMD);
#endif
	xen_do_pin(MMUEXT_PIN_L3_TABLE, PFN_DOWN(__pa(pgd)));
#endif /* CONFIG_X86_64 */
	xen_mc_issue(0);
}

static void xen_pgd_pin(struct mm_struct *mm)
{
	__xen_pgd_pin(mm, mm->pgd);
}

/*
 * On save, we need to pin all pagetables to make sure they get their
 * mfns turned into pfns.  Search the list for any unpinned pgds and pin
 * them (unpinned pgds are not currently in use, probably because the
 * process is under construction or destruction).
 *
 * Expected to be called in stop_machine() ("equivalent to taking
 * every spinlock in the system"), so the locking doesn't really
 * matter all that much.
 */
void xen_mm_pin_all(void)
{
	struct page *page;

	spin_lock(&pgd_lock);

	list_for_each_entry(page, &pgd_list, lru) {
		if (!PagePinned(page)) {
			__xen_pgd_pin(&init_mm, (pgd_t *)page_address(page));
			SetPageSavePinned(page);
		}
	}

	spin_unlock(&pgd_lock);
}

/*
 * The init_mm pagetable is really pinned as soon as its created, but
 * that's before we have page structures to store the bits.  So do all
 * the book-keeping now.
 */
static int __init xen_mark_pinned(struct mm_struct *mm, struct page *page,
				  enum pt_level level)
{
	SetPagePinned(page);
	return 0;
}

static void __init xen_mark_init_mm_pinned(void)
{
	xen_pgd_walk(&init_mm, xen_mark_pinned, FIXADDR_TOP);
}

static int xen_unpin_page(struct mm_struct *mm, struct page *page,
			  enum pt_level level)
{
	unsigned pgfl = TestClearPagePinned(page);

	if (pgfl && !PageHighMem(page)) {
		void *pt = lowmem_page_address(page);
		unsigned long pfn = page_to_pfn(page);
		spinlock_t *ptl = NULL;
		struct multicall_space mcs;

		/*
		 * Do the converse to pin_page.  If we're using split
		 * pte locks, we must be holding the lock for while
		 * the pte page is unpinned but still RO to prevent
		 * concurrent updates from seeing it in this
		 * partially-pinned state.
		 */
		if (level == PT_PTE) {
			ptl = xen_pte_lock(page, mm);

			if (ptl)
				xen_do_pin(MMUEXT_UNPIN_TABLE, pfn);
		}

		mcs = __xen_mc_entry(0);

		MULTI_update_va_mapping(mcs.mc, (unsigned long)pt,
					pfn_pte(pfn, PAGE_KERNEL),
					level == PT_PGD ? UVMF_TLB_FLUSH : 0);

		if (ptl) {
			/* unlock when batch completed */
			xen_mc_callback(xen_pte_unlock, ptl);
		}
	}

	return 0;		/* never need to flush on unpin */
}

/* Release a pagetables pages back as normal RW */
static void __xen_pgd_unpin(struct mm_struct *mm, pgd_t *pgd)
{
	trace_xen_mmu_pgd_unpin(mm, pgd);

	xen_mc_batch();

	xen_do_pin(MMUEXT_UNPIN_TABLE, PFN_DOWN(__pa(pgd)));

#ifdef CONFIG_X86_64
	{
		pgd_t *user_pgd = xen_get_user_pgd(pgd);

		if (user_pgd) {
			xen_do_pin(MMUEXT_UNPIN_TABLE,
				   PFN_DOWN(__pa(user_pgd)));
			xen_unpin_page(mm, virt_to_page(user_pgd), PT_PGD);
		}
	}
#endif

#ifdef CONFIG_X86_PAE
	/* Need to make sure unshared kernel PMD is unpinned */
	xen_unpin_page(mm, pgd_page(pgd[pgd_index(TASK_SIZE)]),
		       PT_PMD);
#endif

	__xen_pgd_walk(mm, pgd, xen_unpin_page, USER_LIMIT);

	xen_mc_issue(0);
}

static void xen_pgd_unpin(struct mm_struct *mm)
{
	__xen_pgd_unpin(mm, mm->pgd);
}

/*
 * On resume, undo any pinning done at save, so that the rest of the
 * kernel doesn't see any unexpected pinned pagetables.
 */
void xen_mm_unpin_all(void)
{
	struct page *page;

	spin_lock(&pgd_lock);

	list_for_each_entry(page, &pgd_list, lru) {
		if (PageSavePinned(page)) {
			BUG_ON(!PagePinned(page));
			__xen_pgd_unpin(&init_mm, (pgd_t *)page_address(page));
			ClearPageSavePinned(page);
		}
	}

	spin_unlock(&pgd_lock);
}

static void xen_activate_mm(struct mm_struct *prev, struct mm_struct *next)
{
	spin_lock(&next->page_table_lock);
	xen_pgd_pin(next);
	spin_unlock(&next->page_table_lock);
}

static void xen_dup_mmap(struct mm_struct *oldmm, struct mm_struct *mm)
{
	spin_lock(&mm->page_table_lock);
	xen_pgd_pin(mm);
	spin_unlock(&mm->page_table_lock);
}


#ifdef CONFIG_SMP
/* Another cpu may still have their %cr3 pointing at the pagetable, so
   we need to repoint it somewhere else before we can unpin it. */
static void drop_other_mm_ref(void *info)
{
	struct mm_struct *mm = info;
	struct mm_struct *active_mm;

	active_mm = this_cpu_read(cpu_tlbstate.active_mm);

	if (active_mm == mm && this_cpu_read(cpu_tlbstate.state) != TLBSTATE_OK)
		leave_mm(smp_processor_id());

	/* If this cpu still has a stale cr3 reference, then make sure
	   it has been flushed. */
	if (this_cpu_read(xen_current_cr3) == __pa(mm->pgd))
		load_cr3(swapper_pg_dir);
}

static void xen_drop_mm_ref(struct mm_struct *mm)
{
	cpumask_var_t mask;
	unsigned cpu;

	if (current->active_mm == mm) {
		if (current->mm == mm)
			load_cr3(swapper_pg_dir);
		else
			leave_mm(smp_processor_id());
	}

	/* Get the "official" set of cpus referring to our pagetable. */
	if (!alloc_cpumask_var(&mask, GFP_ATOMIC)) {
		for_each_online_cpu(cpu) {
			if (!cpumask_test_cpu(cpu, mm_cpumask(mm))
			    && per_cpu(xen_current_cr3, cpu) != __pa(mm->pgd))
				continue;
			smp_call_function_single(cpu, drop_other_mm_ref, mm, 1);
		}
		return;
	}
	cpumask_copy(mask, mm_cpumask(mm));

	/* It's possible that a vcpu may have a stale reference to our
	   cr3, because its in lazy mode, and it hasn't yet flushed
	   its set of pending hypercalls yet.  In this case, we can
	   look at its actual current cr3 value, and force it to flush
	   if needed. */
	for_each_online_cpu(cpu) {
		if (per_cpu(xen_current_cr3, cpu) == __pa(mm->pgd))
			cpumask_set_cpu(cpu, mask);
	}

	if (!cpumask_empty(mask))
		smp_call_function_many(mask, drop_other_mm_ref, mm, 1);
	free_cpumask_var(mask);
}
#else
static void xen_drop_mm_ref(struct mm_struct *mm)
{
	if (current->active_mm == mm)
		load_cr3(swapper_pg_dir);
}
#endif

/*
 * While a process runs, Xen pins its pagetables, which means that the
 * hypervisor forces it to be read-only, and it controls all updates
 * to it.  This means that all pagetable updates have to go via the
 * hypervisor, which is moderately expensive.
 *
 * Since we're pulling the pagetable down, we switch to use init_mm,
 * unpin old process pagetable and mark it all read-write, which
 * allows further operations on it to be simple memory accesses.
 *
 * The only subtle point is that another CPU may be still using the
 * pagetable because of lazy tlb flushing.  This means we need need to
 * switch all CPUs off this pagetable before we can unpin it.
 */
static void xen_exit_mmap(struct mm_struct *mm)
{
	get_cpu();		/* make sure we don't move around */
	xen_drop_mm_ref(mm);
	put_cpu();

	spin_lock(&mm->page_table_lock);

	/* pgd may not be pinned in the error exit path of execve */
	if (xen_page_pinned(mm->pgd))
		xen_pgd_unpin(mm);

	spin_unlock(&mm->page_table_lock);
}

static void __init xen_pagetable_setup_start(pgd_t *base)
{
}

static __init void xen_mapping_pagetable_reserve(u64 start, u64 end)
{
	/* reserve the range used */
	native_pagetable_reserve(start, end);

	/* set as RW the rest */
	printk(KERN_DEBUG "xen: setting RW the range %llx - %llx\n", end,
			PFN_PHYS(pgt_buf_top));
	while (end < PFN_PHYS(pgt_buf_top)) {
		make_lowmem_page_readwrite(__va(end));
		end += PAGE_SIZE;
	}
}

static void xen_post_allocator_init(void);

static void __init xen_pagetable_setup_done(pgd_t *base)
{
	xen_setup_shared_info();

	if (xen_feature(XENFEAT_auto_translated_physmap))
		return;

	xen_post_allocator_init();
}

static void xen_write_cr2(unsigned long cr2)
{
	this_cpu_read(xen_vcpu)->arch.cr2 = cr2;
}

static unsigned long xen_read_cr2(void)
{
	return this_cpu_read(xen_vcpu)->arch.cr2;
}

unsigned long xen_read_cr2_direct(void)
{
	return this_cpu_read(xen_vcpu_info.arch.cr2);
}

static void xen_flush_tlb(void)
{
	struct mmuext_op *op;
	struct multicall_space mcs;

	trace_xen_mmu_flush_tlb(0);

	preempt_disable();

	mcs = xen_mc_entry(sizeof(*op));

	op = mcs.args;
	op->cmd = MMUEXT_TLB_FLUSH_LOCAL;
	MULTI_mmuext_op(mcs.mc, op, 1, NULL, DOMID_SELF);

	xen_mc_issue(PARAVIRT_LAZY_MMU);

	preempt_enable();
}

static void xen_flush_tlb_single(unsigned long addr)
{
	struct mmuext_op *op;
	struct multicall_space mcs;

	trace_xen_mmu_flush_tlb_single(addr);

	preempt_disable();

	mcs = xen_mc_entry(sizeof(*op));
	op = mcs.args;
	op->cmd = MMUEXT_INVLPG_LOCAL;
	op->arg1.linear_addr = addr & PAGE_MASK;
	MULTI_mmuext_op(mcs.mc, op, 1, NULL, DOMID_SELF);

	xen_mc_issue(PARAVIRT_LAZY_MMU);

	preempt_enable();
}

static void xen_flush_tlb_others(const struct cpumask *cpus,
				 struct mm_struct *mm, unsigned long start,
				 unsigned long end)
{
	struct {
		struct mmuext_op op;
#ifdef CONFIG_SMP
		DECLARE_BITMAP(mask, num_processors);
#else
		DECLARE_BITMAP(mask, NR_CPUS);
#endif
	} *args;
	struct multicall_space mcs;

	trace_xen_mmu_flush_tlb_others(cpus, mm, start, end);

	if (cpumask_empty(cpus))
		return;		/* nothing to do */

	mcs = xen_mc_entry(sizeof(*args));
	args = mcs.args;
	args->op.arg2.vcpumask = to_cpumask(args->mask);

	/* Remove us, and any offline CPUS. */
	cpumask_and(to_cpumask(args->mask), cpus, cpu_online_mask);
	cpumask_clear_cpu(smp_processor_id(), to_cpumask(args->mask));

	args->op.cmd = MMUEXT_TLB_FLUSH_MULTI;
	if (start != TLB_FLUSH_ALL && (end - start) <= PAGE_SIZE) {
		args->op.cmd = MMUEXT_INVLPG_MULTI;
		args->op.arg1.linear_addr = start;
	}

	MULTI_mmuext_op(mcs.mc, &args->op, 1, NULL, DOMID_SELF);

	xen_mc_issue(PARAVIRT_LAZY_MMU);
}

static unsigned long xen_read_cr3(void)
{
	return this_cpu_read(xen_cr3);
}

static void set_current_cr3(void *v)
{
	this_cpu_write(xen_current_cr3, (unsigned long)v);
}

static void __xen_write_cr3(bool kernel, unsigned long cr3)
{
	struct mmuext_op op;
	unsigned long mfn;

	trace_xen_mmu_write_cr3(kernel, cr3);

	if (cr3)
		mfn = pfn_to_mfn(PFN_DOWN(cr3));
	else
		mfn = 0;

	WARN_ON(mfn == 0 && kernel);

	op.cmd = kernel ? MMUEXT_NEW_BASEPTR : MMUEXT_NEW_USER_BASEPTR;
	op.arg1.mfn = mfn;

	xen_extend_mmuext_op(&op);

	if (kernel) {
		this_cpu_write(xen_cr3, cr3);

		/* Update xen_current_cr3 once the batch has actually
		   been submitted. */
		xen_mc_callback(set_current_cr3, (void *)cr3);
	}
}

static void xen_write_cr3(unsigned long cr3)
{
	BUG_ON(preemptible());

	xen_mc_batch();  /* disables interrupts */

	/* Update while interrupts are disabled, so its atomic with
	   respect to ipis */
	this_cpu_write(xen_cr3, cr3);

	__xen_write_cr3(true, cr3);

#ifdef CONFIG_X86_64
	{
		pgd_t *user_pgd = xen_get_user_pgd(__va(cr3));
		if (user_pgd)
			__xen_write_cr3(false, __pa(user_pgd));
		else
			__xen_write_cr3(false, 0);
	}
#endif

	xen_mc_issue(PARAVIRT_LAZY_CPU);  /* interrupts restored */
}

static int xen_pgd_alloc(struct mm_struct *mm)
{
	pgd_t *pgd = mm->pgd;
	int ret = 0;

	BUG_ON(PagePinned(virt_to_page(pgd)));

#ifdef CONFIG_X86_64
	{
		struct page *page = virt_to_page(pgd);
		pgd_t *user_pgd;

		BUG_ON(page->private != 0);

		ret = -ENOMEM;

		user_pgd = (pgd_t *)__get_free_page(GFP_KERNEL | __GFP_ZERO);
		page->private = (unsigned long)user_pgd;

		if (user_pgd != NULL) {
			user_pgd[pgd_index(VSYSCALL_START)] =
				__pgd(__pa(level3_user_vsyscall) | _PAGE_TABLE);
			ret = 0;
		}

		BUG_ON(PagePinned(virt_to_page(xen_get_user_pgd(pgd))));
	}
#endif

	return ret;
}

static void xen_pgd_free(struct mm_struct *mm, pgd_t *pgd)
{
#ifdef CONFIG_X86_64
	pgd_t *user_pgd = xen_get_user_pgd(pgd);

	if (user_pgd)
		free_page((unsigned long)user_pgd);
#endif
}

#ifdef CONFIG_X86_32
static pte_t __init mask_rw_pte(pte_t *ptep, pte_t pte)
{
	/* If there's an existing pte, then don't allow _PAGE_RW to be set */
	if (pte_val_ma(*ptep) & _PAGE_PRESENT)
		pte = __pte_ma(((pte_val_ma(*ptep) & _PAGE_RW) | ~_PAGE_RW) &
			       pte_val_ma(pte));

	return pte;
}
#else /* CONFIG_X86_64 */
static pte_t __init mask_rw_pte(pte_t *ptep, pte_t pte)
{
	unsigned long pfn = pte_pfn(pte);

	/*
	 * If the new pfn is within the range of the newly allocated
	 * kernel pagetable, and it isn't being mapped into an
	 * early_ioremap fixmap slot as a freshly allocated page, make sure
	 * it is RO.
	 */
	if (((!is_early_ioremap_ptep(ptep) &&
			pfn >= pgt_buf_start && pfn < pgt_buf_top)) ||
			(is_early_ioremap_ptep(ptep) && pfn != (pgt_buf_end - 1)))
		pte = pte_wrprotect(pte);

	return pte;
}
#endif /* CONFIG_X86_64 */

/*
 * Init-time set_pte while constructing initial pagetables, which
 * doesn't allow RO page table pages to be remapped RW.
 *
 * If there is no MFN for this PFN then this page is initially
 * ballooned out so clear the PTE (as in decrease_reservation() in
 * drivers/xen/balloon.c).
 *
 * Many of these PTE updates are done on unpinned and writable pages
 * and doing a hypercall for these is unnecessary and expensive.  At
 * this point it is not possible to tell if a page is pinned or not,
 * so always write the PTE directly and rely on Xen trapping and
 * emulating any updates as necessary.
 */
static void __init xen_set_pte_init(pte_t *ptep, pte_t pte)
{
	if (pte_mfn(pte) != INVALID_P2M_ENTRY)
		pte = mask_rw_pte(ptep, pte);
	else
		pte = __pte_ma(0);

	native_set_pte(ptep, pte);
}

static noinline void pin_pagetable_pfn(unsigned cmd, unsigned long pfn)
{
	struct mmuext_op op;

	if (xen_feature(XENFEAT_writable_page_tables))
		return;

	op.cmd = cmd;
	op.arg1.mfn = pfn_to_mfn(pfn);
	if (HYPERVISOR_mmuext_op(&op, 1, NULL, DOMID_SELF))
		BUG();
}

/* Early in boot, while setting up the initial pagetable, assume
   everything is pinned. */
static void __init xen_alloc_pte_init(struct mm_struct *mm, unsigned long pfn)
{
#ifdef CONFIG_FLATMEM
	BUG_ON(mem_map);	/* should only be used early */
#endif
	make_lowmem_page_readonly(__va(PFN_PHYS(pfn)));
	pin_pagetable_pfn(MMUEXT_PIN_L1_TABLE, pfn);
}

/* Used for pmd and pud */
static void __init xen_alloc_pmd_init(struct mm_struct *mm, unsigned long pfn)
{
#ifdef CONFIG_FLATMEM
	BUG_ON(mem_map);	/* should only be used early */
#endif
	make_lowmem_page_readonly(__va(PFN_PHYS(pfn)));
}

/* Early release_pte assumes that all pts are pinned, since there's
   only init_mm and anything attached to that is pinned. */
static void __init xen_release_pte_init(unsigned long pfn)
{
	pin_pagetable_pfn(MMUEXT_UNPIN_TABLE, pfn);
	make_lowmem_page_readwrite(__va(PFN_PHYS(pfn)));
}

static void __init xen_release_pmd_init(unsigned long pfn)
{
	make_lowmem_page_readwrite(__va(PFN_PHYS(pfn)));
}

static inline void __pin_pagetable_pfn(unsigned cmd, unsigned long pfn)
{
	struct multicall_space mcs;
	struct mmuext_op *op;

	mcs = __xen_mc_entry(sizeof(*op));
	op = mcs.args;
	op->cmd = cmd;
	op->arg1.mfn = pfn_to_mfn(pfn);

	MULTI_mmuext_op(mcs.mc, mcs.args, 1, NULL, DOMID_SELF);
}

static inline void __set_pfn_prot(unsigned long pfn, pgprot_t prot)
{
	struct multicall_space mcs;
	unsigned long addr = (unsigned long)__va(pfn << PAGE_SHIFT);

	mcs = __xen_mc_entry(0);
	MULTI_update_va_mapping(mcs.mc, (unsigned long)addr,
				pfn_pte(pfn, prot), 0);
}

/* This needs to make sure the new pte page is pinned iff its being
   attached to a pinned pagetable. */
static inline void xen_alloc_ptpage(struct mm_struct *mm, unsigned long pfn,
				    unsigned level)
{
	bool pinned = PagePinned(virt_to_page(mm->pgd));

	trace_xen_mmu_alloc_ptpage(mm, pfn, level, pinned);

	if (pinned) {
		struct page *page = pfn_to_page(pfn);

		SetPagePinned(page);

		if (!PageHighMem(page)) {
			xen_mc_batch();

			__set_pfn_prot(pfn, PAGE_KERNEL_RO);

			if (level == PT_PTE && USE_SPLIT_PTLOCKS)
				__pin_pagetable_pfn(MMUEXT_PIN_L1_TABLE, pfn);

			xen_mc_issue(PARAVIRT_LAZY_MMU);
		} else {
			/* make sure there are no stray mappings of
			   this page */
			kmap_flush_unused();
		}
	}
}

static void xen_alloc_pte(struct mm_struct *mm, unsigned long pfn)
{
	xen_alloc_ptpage(mm, pfn, PT_PTE);
}

static void xen_alloc_pmd(struct mm_struct *mm, unsigned long pfn)
{
	xen_alloc_ptpage(mm, pfn, PT_PMD);
}

/* This should never happen until we're OK to use struct page */
static inline void xen_release_ptpage(unsigned long pfn, unsigned level)
{
	struct page *page = pfn_to_page(pfn);
	bool pinned = PagePinned(page);

	trace_xen_mmu_release_ptpage(pfn, level, pinned);

	if (pinned) {
		if (!PageHighMem(page)) {
			xen_mc_batch();

			if (level == PT_PTE && USE_SPLIT_PTLOCKS)
				__pin_pagetable_pfn(MMUEXT_UNPIN_TABLE, pfn);

			__set_pfn_prot(pfn, PAGE_KERNEL);

			xen_mc_issue(PARAVIRT_LAZY_MMU);
		}
		ClearPagePinned(page);
	}
}

static void xen_release_pte(unsigned long pfn)
{
	xen_release_ptpage(pfn, PT_PTE);
}

static void xen_release_pmd(unsigned long pfn)
{
	xen_release_ptpage(pfn, PT_PMD);
}

#if PAGETABLE_LEVELS == 4
static void xen_alloc_pud(struct mm_struct *mm, unsigned long pfn)
{
	xen_alloc_ptpage(mm, pfn, PT_PUD);
}

static void xen_release_pud(unsigned long pfn)
{
	xen_release_ptpage(pfn, PT_PUD);
}
#endif

void __init xen_reserve_top(void)
{
#ifdef CONFIG_X86_32
	unsigned long top = HYPERVISOR_VIRT_START;
	struct xen_platform_parameters pp;

	if (HYPERVISOR_xen_version(XENVER_platform_parameters, &pp) == 0)
		top = pp.virt_start;

	reserve_top_address(-top);
#endif	/* CONFIG_X86_32 */
}

/*
 * Like __va(), but returns address in the kernel mapping (which is
 * all we have until the physical memory mapping has been set up.
 */
static void *__ka(phys_addr_t paddr)
{
#ifdef CONFIG_X86_64
	return (void *)(paddr + __START_KERNEL_map);
#else
	return __va(paddr);
#endif
}

/* Convert a machine address to physical address */
static unsigned long m2p(phys_addr_t maddr)
{
	phys_addr_t paddr;

	maddr &= PTE_PFN_MASK;
	paddr = mfn_to_pfn(maddr >> PAGE_SHIFT) << PAGE_SHIFT;

	return paddr;
}

/* Convert a machine address to kernel virtual */
static void *m2v(phys_addr_t maddr)
{
	return __ka(m2p(maddr));
}

/* Set the page permissions on an identity-mapped pages */
static void set_page_prot(void *addr, pgprot_t prot)
{
	unsigned long pfn = __pa(addr) >> PAGE_SHIFT;
	pte_t pte = pfn_pte(pfn, prot);

	/* recall for PVH, page tables are native. */
	if (xen_feature(XENFEAT_auto_translated_physmap))
		return;

	if (HYPERVISOR_update_va_mapping((unsigned long)addr, pte, 0))
		BUG();
}

static void __init xen_map_identity_early(pmd_t *pmd, unsigned long max_pfn)
{
	unsigned pmdidx, pteidx;
	unsigned ident_pte;
	unsigned long pfn;

	level1_ident_pgt = extend_brk(sizeof(pte_t) * LEVEL1_IDENT_ENTRIES,
				      PAGE_SIZE);

	ident_pte = 0;
	pfn = 0;
	for (pmdidx = 0; pmdidx < PTRS_PER_PMD && pfn < max_pfn; pmdidx++) {
		pte_t *pte_page;

		/* Reuse or allocate a page of ptes */
		if (pmd_present(pmd[pmdidx]))
			pte_page = m2v(pmd[pmdidx].pmd);
		else {
			/* Check for free pte pages */
			if (ident_pte == LEVEL1_IDENT_ENTRIES)
				break;

			pte_page = &level1_ident_pgt[ident_pte];
			ident_pte += PTRS_PER_PTE;

			pmd[pmdidx] = __pmd(__pa(pte_page) | _PAGE_TABLE);
		}

		/* Install mappings */
		for (pteidx = 0; pteidx < PTRS_PER_PTE; pteidx++, pfn++) {
			pte_t pte;

#ifdef CONFIG_X86_32
			if (pfn > max_pfn_mapped)
				max_pfn_mapped = pfn;
#endif

			if (!pte_none(pte_page[pteidx]))
				continue;

			pte = pfn_pte(pfn, PAGE_KERNEL_EXEC);
			pte_page[pteidx] = pte;
		}
	}

	for (pteidx = 0; pteidx < ident_pte; pteidx += PTRS_PER_PTE)
		set_page_prot(&level1_ident_pgt[pteidx], PAGE_KERNEL_RO);

	set_page_prot(pmd, PAGE_KERNEL_RO);
}

void __init xen_setup_machphys_mapping(void)
{
	struct xen_machphys_mapping mapping;

	if (HYPERVISOR_memory_op(XENMEM_machphys_mapping, &mapping) == 0) {
		machine_to_phys_mapping = (unsigned long *)mapping.v_start;
		machine_to_phys_nr = mapping.max_mfn + 1;
	} else {
		machine_to_phys_nr = MACH2PHYS_NR_ENTRIES;
	}
#ifdef CONFIG_X86_32
	WARN_ON((machine_to_phys_mapping + (machine_to_phys_nr - 1))
		< machine_to_phys_mapping);
#endif
}

#ifdef CONFIG_X86_64
static void convert_pfn_mfn(void *v)
{
	pte_t *pte = v;
	int i;

	if (xen_feature(XENFEAT_auto_translated_physmap))
		return;

	/* All levels are converted the same way, so just treat them
	   as ptes. */
	for (i = 0; i < PTRS_PER_PTE; i++)
		pte[i] = xen_make_pte(pte[i].pte);
}

/*
 * Set up the initial kernel pagetable.
 *
 * We can construct this by grafting the Xen provided pagetable into
 * head_64.S's preconstructed pagetables.  We copy the Xen L2's into
 * level2_ident_pgt, level2_kernel_pgt and level2_fixmap_pgt.  This
 * means that only the kernel has a physical mapping to start with -
 * but that's enough to get __va working.  We need to fill in the rest
 * of the physical mapping once some sort of allocator has been set
 * up.
 * NOTE: for PVH, the page tables are native.
 */
pgd_t * __init xen_setup_kernel_pagetable(pgd_t *pgd,
					 unsigned long max_pfn)
{
	pud_t *l3;
	pmd_t *l2;

	/* max_pfn_mapped is the last pfn mapped in the initial memory
	 * mappings. Considering that on Xen after the kernel mappings we
	 * have the mappings of some pages that don't exist in pfn space, we
	 * set max_pfn_mapped to the last real pfn mapped. */
	max_pfn_mapped = PFN_DOWN(__pa(xen_start_info->mfn_list));

	/* Zap identity mapping */
	init_level4_pgt[0] = __pgd(0);

	/* Pre-constructed entries are in pfn, so convert to mfn */
	convert_pfn_mfn(init_level4_pgt);
	convert_pfn_mfn(level3_ident_pgt);
	convert_pfn_mfn(level3_kernel_pgt);

	l3 = m2v(pgd[pgd_index(__START_KERNEL_map)].pgd);
	l2 = m2v(l3[pud_index(__START_KERNEL_map)].pud);

	memcpy(level2_ident_pgt, l2, sizeof(pmd_t) * PTRS_PER_PMD);
	memcpy(level2_kernel_pgt, l2, sizeof(pmd_t) * PTRS_PER_PMD);

	l3 = m2v(pgd[pgd_index(__START_KERNEL_map + PMD_SIZE)].pgd);
	l2 = m2v(l3[pud_index(__START_KERNEL_map + PMD_SIZE)].pud);
	memcpy(level2_fixmap_pgt, l2, sizeof(pmd_t) * PTRS_PER_PMD);

	/* Set up identity map */
	xen_map_identity_early(level2_ident_pgt, max_pfn);

	/* Make pagetable pieces RO */
	set_page_prot(init_level4_pgt, PAGE_KERNEL_RO);
	set_page_prot(level3_ident_pgt, PAGE_KERNEL_RO);
	set_page_prot(level3_kernel_pgt, PAGE_KERNEL_RO);
	set_page_prot(level3_user_vsyscall, PAGE_KERNEL_RO);
	set_page_prot(level2_kernel_pgt, PAGE_KERNEL_RO);
	set_page_prot(level2_fixmap_pgt, PAGE_KERNEL_RO);

	/* Pin down new L4 */
	pin_pagetable_pfn(MMUEXT_PIN_L4_TABLE,
		  	PFN_DOWN(__pa_symbol(init_level4_pgt)));

	/* Unpin Xen-provided one */
	pin_pagetable_pfn(MMUEXT_UNPIN_TABLE, PFN_DOWN(__pa(pgd)));

	/* Switch over */
	pgd = init_level4_pgt;

	/*
	 * At this stage there can be no user pgd, and no page
	 * structure to attach it to, so make sure we just set kernel
	 * pgd.
	 */
	if (xen_feature(XENFEAT_writable_page_tables)) {
		native_write_cr3(__pa(pgd));
	} else {
		xen_mc_batch();
		__xen_write_cr3(true, __pa(pgd));
		xen_mc_issue(PARAVIRT_LAZY_CPU);
	}

	memblock_reserve(__pa(xen_start_info->pt_base),
			 xen_start_info->nr_pt_frames * PAGE_SIZE);

	return pgd;
}
#else	/* !CONFIG_X86_64 */
static RESERVE_BRK_ARRAY(pmd_t, initial_kernel_pmd, PTRS_PER_PMD);
static RESERVE_BRK_ARRAY(pmd_t, swapper_kernel_pmd, PTRS_PER_PMD);

static void __init xen_write_cr3_init(unsigned long cr3)
{
	unsigned long pfn = PFN_DOWN(__pa(swapper_pg_dir));

	BUG_ON(read_cr3() != __pa(initial_page_table));
	BUG_ON(cr3 != __pa(swapper_pg_dir));

	/*
	 * We are switching to swapper_pg_dir for the first time (from
	 * initial_page_table) and therefore need to mark that page
	 * read-only and then pin it.
	 *
	 * Xen disallows sharing of kernel PMDs for PAE
	 * guests. Therefore we must copy the kernel PMD from
	 * initial_page_table into a new kernel PMD to be used in
	 * swapper_pg_dir.
	 */
	swapper_kernel_pmd =
		extend_brk(sizeof(pmd_t) * PTRS_PER_PMD, PAGE_SIZE);
	memcpy(swapper_kernel_pmd, initial_kernel_pmd,
	       sizeof(pmd_t) * PTRS_PER_PMD);
	swapper_pg_dir[KERNEL_PGD_BOUNDARY] =
		__pgd(__pa(swapper_kernel_pmd) | _PAGE_PRESENT);
	set_page_prot(swapper_kernel_pmd, PAGE_KERNEL_RO);

	set_page_prot(swapper_pg_dir, PAGE_KERNEL_RO);
	xen_write_cr3(cr3);
	pin_pagetable_pfn(MMUEXT_PIN_L3_TABLE, pfn);

	pin_pagetable_pfn(MMUEXT_UNPIN_TABLE,
			  PFN_DOWN(__pa(initial_page_table)));
	set_page_prot(initial_page_table, PAGE_KERNEL);
	set_page_prot(initial_kernel_pmd, PAGE_KERNEL);

	pv_mmu_ops.write_cr3 = &xen_write_cr3;
}

pgd_t * __init xen_setup_kernel_pagetable(pgd_t *pgd,
					 unsigned long max_pfn)
{
	pmd_t *kernel_pmd;

	initial_kernel_pmd =
		extend_brk(sizeof(pmd_t) * PTRS_PER_PMD, PAGE_SIZE);

	max_pfn_mapped = PFN_DOWN(__pa(xen_start_info->pt_base) +
				  xen_start_info->nr_pt_frames * PAGE_SIZE +
				  512*1024);

	kernel_pmd = m2v(pgd[KERNEL_PGD_BOUNDARY].pgd);
	memcpy(initial_kernel_pmd, kernel_pmd, sizeof(pmd_t) * PTRS_PER_PMD);

	xen_map_identity_early(initial_kernel_pmd, max_pfn);

	memcpy(initial_page_table, pgd, sizeof(pgd_t) * PTRS_PER_PGD);
	initial_page_table[KERNEL_PGD_BOUNDARY] =
		__pgd(__pa(initial_kernel_pmd) | _PAGE_PRESENT);

	set_page_prot(initial_kernel_pmd, PAGE_KERNEL_RO);
	set_page_prot(initial_page_table, PAGE_KERNEL_RO);
	set_page_prot(empty_zero_page, PAGE_KERNEL_RO);

	pin_pagetable_pfn(MMUEXT_UNPIN_TABLE, PFN_DOWN(__pa(pgd)));

	pin_pagetable_pfn(MMUEXT_PIN_L3_TABLE,
			  PFN_DOWN(__pa(initial_page_table)));
	xen_write_cr3(__pa(initial_page_table));

	memblock_reserve(__pa(xen_start_info->pt_base),
			 xen_start_info->nr_pt_frames * PAGE_SIZE);

	return initial_page_table;
}
#endif	/* CONFIG_X86_64 */

static unsigned char dummy_mapping[PAGE_SIZE] __page_aligned_bss;

static void xen_set_fixmap(unsigned idx, phys_addr_t phys, pgprot_t prot)
{
	pte_t pte;

	phys >>= PAGE_SHIFT;

	switch (idx) {
	case FIX_BTMAP_END ... FIX_BTMAP_BEGIN:
#ifdef CONFIG_X86_F00F_BUG
	case FIX_F00F_IDT:
#endif
#ifdef CONFIG_X86_32
	case FIX_WP_TEST:
	case FIX_VDSO:
# ifdef CONFIG_HIGHMEM
	case FIX_KMAP_BEGIN ... FIX_KMAP_END:
# endif
#else
	case VSYSCALL_LAST_PAGE ... VSYSCALL_FIRST_PAGE:
	case VVAR_PAGE:
#endif
	case FIX_TEXT_POKE0:
	case FIX_TEXT_POKE1:
		/* All local page mappings */
		pte = pfn_pte(phys, prot);
		break;

#ifdef CONFIG_X86_LOCAL_APIC
	case FIX_APIC_BASE:	/* maps dummy local APIC */
		pte = pfn_pte(PFN_DOWN(__pa(dummy_mapping)), PAGE_KERNEL);
		break;
#endif

#ifdef CONFIG_X86_IO_APIC
	case FIX_IO_APIC_BASE_0 ... FIX_IO_APIC_BASE_END:
		/*
		 * We just don't map the IO APIC - all access is via
		 * hypercalls.  Keep the address in the pte for reference.
		 */
		pte = pfn_pte(PFN_DOWN(__pa(dummy_mapping)), PAGE_KERNEL);
		break;
#endif

	case FIX_PARAVIRT_BOOTMAP:
		/* This is an MFN, but it isn't an IO mapping from the
		   IO domain */
		pte = mfn_pte(phys, prot);
		break;

	default:
		/* By default, set_fixmap is used for hardware mappings */
		pte = mfn_pte(phys, __pgprot(pgprot_val(prot) | _PAGE_IOMAP));
		break;
	}

	__native_set_fixmap(idx, pte);

#ifdef CONFIG_X86_64
	/* Replicate changes to map the vsyscall page into the user
	   pagetable vsyscall mapping. */
	if ((idx >= VSYSCALL_LAST_PAGE && idx <= VSYSCALL_FIRST_PAGE) ||
	    idx == VVAR_PAGE) {
		unsigned long vaddr = __fix_to_virt(idx);
		set_pte_vaddr_pud(level3_user_vsyscall, vaddr, pte);
	}
#endif
}

static void __init xen_post_allocator_init(void)
{
	pv_mmu_ops.set_pte = xen_set_pte;
	pv_mmu_ops.set_pmd = xen_set_pmd;
	pv_mmu_ops.set_pud = xen_set_pud;
#if PAGETABLE_LEVELS == 4
	pv_mmu_ops.set_pgd = xen_set_pgd;
#endif

	/* This will work as long as patching hasn't happened yet
	   (which it hasn't) */
	pv_mmu_ops.alloc_pte = xen_alloc_pte;
	pv_mmu_ops.alloc_pmd = xen_alloc_pmd;
	pv_mmu_ops.release_pte = xen_release_pte;
	pv_mmu_ops.release_pmd = xen_release_pmd;
#if PAGETABLE_LEVELS == 4
	pv_mmu_ops.alloc_pud = xen_alloc_pud;
	pv_mmu_ops.release_pud = xen_release_pud;
#endif

#ifdef CONFIG_X86_64
	SetPagePinned(virt_to_page(level3_user_vsyscall));
#endif
	xen_mark_init_mm_pinned();
}

static void xen_leave_lazy_mmu(void)
{
	preempt_disable();
	xen_mc_flush();
	paravirt_leave_lazy_mmu();
	preempt_enable();
}

static const struct pv_mmu_ops xen_mmu_ops __initconst = {
	.read_cr2 = xen_read_cr2,
	.write_cr2 = xen_write_cr2,

	.read_cr3 = xen_read_cr3,
#ifdef CONFIG_X86_32
	.write_cr3 = xen_write_cr3_init,
#else
	.write_cr3 = xen_write_cr3,
#endif

	.flush_tlb_user = xen_flush_tlb,
	.flush_tlb_kernel = xen_flush_tlb,
	.flush_tlb_single = xen_flush_tlb_single,
	.flush_tlb_others = xen_flush_tlb_others,

	.pte_update = paravirt_nop,
	.pte_update_defer = paravirt_nop,

	.pgd_alloc = xen_pgd_alloc,
	.pgd_free = xen_pgd_free,

	.alloc_pte = xen_alloc_pte_init,
	.release_pte = xen_release_pte_init,
	.alloc_pmd = xen_alloc_pmd_init,
	.release_pmd = xen_release_pmd_init,

	.set_pte = xen_set_pte_init,
	.set_pte_at = xen_set_pte_at,
	.set_pmd = xen_set_pmd_hyper,

	.ptep_modify_prot_start = __ptep_modify_prot_start,
	.ptep_modify_prot_commit = __ptep_modify_prot_commit,

	.pte_val = PV_CALLEE_SAVE(xen_pte_val),
	.pgd_val = PV_CALLEE_SAVE(xen_pgd_val),

	.make_pte = PV_CALLEE_SAVE(xen_make_pte),
	.make_pgd = PV_CALLEE_SAVE(xen_make_pgd),

#ifdef CONFIG_X86_PAE
	.set_pte_atomic = xen_set_pte_atomic,
	.pte_clear = xen_pte_clear,
	.pmd_clear = xen_pmd_clear,
#endif	/* CONFIG_X86_PAE */
	.set_pud = xen_set_pud_hyper,

	.make_pmd = PV_CALLEE_SAVE(xen_make_pmd),
	.pmd_val = PV_CALLEE_SAVE(xen_pmd_val),

#if PAGETABLE_LEVELS == 4
	.pud_val = PV_CALLEE_SAVE(xen_pud_val),
	.make_pud = PV_CALLEE_SAVE(xen_make_pud),
	.set_pgd = xen_set_pgd_hyper,

	.alloc_pud = xen_alloc_pmd_init,
	.release_pud = xen_release_pmd_init,
#endif	/* PAGETABLE_LEVELS == 4 */

	.activate_mm = xen_activate_mm,
	.dup_mmap = xen_dup_mmap,
	.exit_mmap = xen_exit_mmap,

	.lazy_mode = {
		.enter = paravirt_enter_lazy_mmu,
		.leave = xen_leave_lazy_mmu,
	},

	.set_fixmap = xen_set_fixmap,
};

void __init xen_init_mmu_ops(void)
{
	x86_init.paging.pagetable_setup_done = xen_pagetable_setup_done;

	if (xen_feature(XENFEAT_auto_translated_physmap)) {
		pv_mmu_ops.flush_tlb_others = xen_flush_tlb_others;

		/* set_pte* for PCI devices to map iomem. */
		if (xen_initial_domain()) {
			pv_mmu_ops.set_pte = native_set_pte;
			pv_mmu_ops.set_pte_at = xen_dom0pvh_set_pte_at;
		}
		return;
	}

	x86_init.mapping.pagetable_reserve = xen_mapping_pagetable_reserve;
	x86_init.paging.pagetable_setup_start = xen_pagetable_setup_start;
	pv_mmu_ops = xen_mmu_ops;

	memset(dummy_mapping, 0xff, PAGE_SIZE);
}

/* Protected by xen_reservation_lock. */
#define MAX_CONTIG_ORDER 9 /* 2MB */
static unsigned long discontig_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,
				unsigned long *in_frames,
				unsigned long *out_frames)
{
	int i;
	struct multicall_space mcs;

	xen_mc_batch();
	for (i = 0; i < (1UL<<order); i++, vaddr += PAGE_SIZE) {
		mcs = __xen_mc_entry(0);

		if (in_frames)
			in_frames[i] = virt_to_mfn(vaddr);

		MULTI_update_va_mapping(mcs.mc, vaddr, VOID_PTE, 0);
		__set_phys_to_machine(virt_to_pfn(vaddr), INVALID_P2M_ENTRY);

		if (out_frames)
			out_frames[i] = virt_to_pfn(vaddr);
	}
	xen_mc_issue(0);
}

/*
 * Update the pfn-to-mfn mappings for a virtual address range, either to
 * point to an array of mfns, or contiguously from a single starting
 * mfn.
 */
static void xen_remap_exchanged_ptes(unsigned long vaddr, int order,
				     unsigned long *mfns,
				     unsigned long first_mfn)
{
	unsigned i, limit;
	unsigned long mfn;

	xen_mc_batch();

	limit = 1u << order;
	for (i = 0; i < limit; i++, vaddr += PAGE_SIZE) {
		struct multicall_space mcs;
		unsigned flags;

		mcs = __xen_mc_entry(0);
		if (mfns)
			mfn = mfns[i];
		else
			mfn = first_mfn + i;

		if (i < (limit - 1))
			flags = 0;
		else {
			if (order == 0)
				flags = UVMF_INVLPG | UVMF_ALL;
			else
				flags = UVMF_TLB_FLUSH | UVMF_ALL;
		}

		MULTI_update_va_mapping(mcs.mc, vaddr,
				mfn_pte(mfn, PAGE_KERNEL), flags);

		set_phys_to_machine(virt_to_pfn(vaddr), mfn);
	}

	xen_mc_issue(0);
}

/*
 * Perform the hypercall to exchange a region of our pfns to point to
 * memory with the required contiguous alignment.  Takes the pfns as
 * input, and populates mfns as output.
 *
 * Returns a success code indicating whether the hypervisor was able to
 * satisfy the request or not.
 */
static int xen_exchange_memory(unsigned long extents_in, unsigned int order_in,
			       unsigned long *pfns_in,
			       unsigned long extents_out,
			       unsigned int order_out,
			       unsigned long *mfns_out,
			       unsigned int address_bits)
{
	long rc;
	int success;

	struct xen_memory_exchange exchange = {
		.in = {
			.nr_extents   = extents_in,
			.extent_order = order_in,
			.extent_start = pfns_in,
			.domid        = DOMID_SELF
		},
		.out = {
			.nr_extents   = extents_out,
			.extent_order = order_out,
			.extent_start = mfns_out,
			.address_bits = address_bits,
			.domid        = DOMID_SELF
		}
	};

	BUG_ON(extents_in << order_in != extents_out << order_out);

	rc = HYPERVISOR_memory_op(XENMEM_exchange, &exchange);
	success = (exchange.nr_exchanged == extents_in);

	BUG_ON(!success && ((exchange.nr_exchanged != 0) || (rc == 0)));
	BUG_ON(success && (rc != 0));

	return success;
}

int xen_create_contiguous_region(unsigned long vstart, unsigned int order,
				 unsigned int address_bits)
{
	unsigned long *in_frames = discontig_frames, out_frame;
	unsigned long  flags;
	int            success;

	/*
	 * Currently an auto-translated guest will not perform I/O, nor will
	 * it require PAE page directories below 4GB. Therefore any calls to
	 * this function are redundant and can be ignored.
	 */

	if (xen_feature(XENFEAT_auto_translated_physmap))
		return 0;

	if (unlikely(order > MAX_CONTIG_ORDER))
		return -ENOMEM;

	memset((void *) vstart, 0, PAGE_SIZE << order);

	spin_lock_irqsave(&xen_reservation_lock, flags);

	/* 1. Zap current PTEs, remembering MFNs. */
	xen_zap_pfn_range(vstart, order, in_frames, NULL);

	/* 2. Get a new contiguous memory extent. */
	out_frame = virt_to_pfn(vstart);
	success = xen_exchange_memory(1UL << order, 0, in_frames,
				      1, order, &out_frame,
				      address_bits);

	/* 3. Map the new extent in place of old pages. */
	if (success)
		xen_remap_exchanged_ptes(vstart, order, NULL, out_frame);
	else
		xen_remap_exchanged_ptes(vstart, order, in_frames, 0);

	spin_unlock_irqrestore(&xen_reservation_lock, flags);

	return success ? 0 : -ENOMEM;
}
EXPORT_SYMBOL_GPL(xen_create_contiguous_region);

void xen_destroy_contiguous_region(unsigned long vstart, unsigned int order)
{
	unsigned long *out_frames = discontig_frames, in_frame;
	unsigned long  flags;
	int success;

	if (xen_feature(XENFEAT_auto_translated_physmap))
		return;

	if (unlikely(order > MAX_CONTIG_ORDER))
		return;

	memset((void *) vstart, 0, PAGE_SIZE << order);

	spin_lock_irqsave(&xen_reservation_lock, flags);

	/* 1. Find start MFN of contiguous extent. */
	in_frame = virt_to_mfn(vstart);

	/* 2. Zap current PTEs. */
	xen_zap_pfn_range(vstart, order, NULL, out_frames);

	/* 3. Do the exchange for non-contiguous MFNs. */
	success = xen_exchange_memory(1, order, &in_frame, 1UL << order,
					0, out_frames, 0);

	/* 4. Map new pages in place of old pages. */
	if (success)
		xen_remap_exchanged_ptes(vstart, order, out_frames, 0);
	else
		xen_remap_exchanged_ptes(vstart, order, NULL, in_frame);

	spin_unlock_irqrestore(&xen_reservation_lock, flags);
}
EXPORT_SYMBOL_GPL(xen_destroy_contiguous_region);

#ifdef CONFIG_XEN_PVHVM
static void xen_hvm_exit_mmap(struct mm_struct *mm)
{
	struct xen_hvm_pagetable_dying a;
	int rc;

	a.domid = DOMID_SELF;
	a.gpa = __pa(mm->pgd);
	rc = HYPERVISOR_hvm_op(HVMOP_pagetable_dying, &a);
	WARN_ON_ONCE(rc < 0);
}

static int is_pagetable_dying_supported(void)
{
	struct xen_hvm_pagetable_dying a;
	int rc = 0;

	a.domid = DOMID_SELF;
	a.gpa = 0x00;
	rc = HYPERVISOR_hvm_op(HVMOP_pagetable_dying, &a);
	if (rc < 0) {
		printk(KERN_DEBUG "HVMOP_pagetable_dying not supported\n");
		return 0;
	}
	return 1;
}

void __init xen_hvm_init_mmu_ops(void)
{
	if (is_pagetable_dying_supported())
		pv_mmu_ops.exit_mmap = xen_hvm_exit_mmap;
}
#endif

/* Map foreign gmfn, fgmfn, to local pfn, lpfn. This for the user space 
 * creating new guest on PVH dom0 and needs to map domU pages. Called from
 * exported function, so no need to export this.
 */
static noinline int pvh_add_to_xen_p2m(unsigned long lpfn, unsigned long fgmfn,
			      unsigned int domid)
{
	int rc;
	struct xen_add_to_physmap xatp = { .foreign_domid = domid };

	xatp.gpfn = lpfn;
	xatp.idx = fgmfn;
	xatp.space = XENMAPSPACE_gmfn_foreign;
	rc = HYPERVISOR_memory_op(XENMEM_add_to_physmap, &xatp);
	if (rc)
		pr_warn("d0: Failed to map pfn to mfn rc:%d pfn:%lx mfn:%lx\n", 
			rc, lpfn, fgmfn); 
	return rc;
}

int pvh_rem_xen_p2m(unsigned long spfn, int count)
{
	struct xen_remove_from_physmap xrp;
	int i, rc;

	for (i=0; i < count; i++) {
		xrp.domid = DOMID_SELF;
		xrp.gpfn = spfn+i;
		rc = HYPERVISOR_memory_op(XENMEM_remove_from_physmap, &xrp);
		if (rc) {
			pr_warn("Failed to unmap pfn:%lx rc:%d done:%d\n",
				spfn+i, rc, i);
			return 1;
		}
	}
	return 0;
}
EXPORT_SYMBOL_GPL(pvh_rem_xen_p2m);

struct pvh_remap_data {
	unsigned long fgmfn;		/* foreign domain's gmfn */
	pgprot_t prot;
	domid_t  domid;
	struct vm_area_struct *vma;
};

static noinline int pvh_map_pte_fn(pte_t *ptep, pgtable_t token, unsigned long addr, 
			void *data)
{
	int rc;
	struct pvh_remap_data *pvhp = data;
	struct xen_pvh_sav_pfn_info *savp = pvhp->vma->vm_private_data;
	unsigned long pfn = page_to_pfn(savp->sp_paga[savp->sp_next_todo++]);
	pte_t pteval = pte_mkspecial(pfn_pte(pfn, pvhp->prot));

	if ((rc=pvh_add_to_xen_p2m(pfn, pvhp->fgmfn, pvhp->domid)))
		return rc;
	native_set_pte(ptep, pteval);
	savp->sp_addr = addr;

	return 0;
}

/* The only caller at moment passes one gmfn at a time.
 * PVH TBD/FIXME: expand this in future to honor batch requests.
 */
static noinline int pvh_remap_gmfn_range(struct vm_area_struct *vma,
				unsigned long addr, unsigned long mfn, int nr,
				pgprot_t prot, unsigned domid)
{
	int err;
	struct pvh_remap_data pvhdata;

	if (nr > 1)
		return -EINVAL;

	pvhdata.fgmfn = mfn;
	pvhdata.prot = prot;
	pvhdata.domid = domid;
	pvhdata.vma = vma;
	err = apply_to_page_range(vma->vm_mm, addr, nr << PAGE_SHIFT,
				  pvh_map_pte_fn, &pvhdata);
	flush_tlb_all();
	return err;
}

#define REMAP_BATCH_SIZE 16

struct remap_data {
	unsigned long mfn;
	pgprot_t prot;
	struct mmu_update *mmu_update;
};

static int remap_area_mfn_pte_fn(pte_t *ptep, pgtable_t token,
				 unsigned long addr, void *data)
{
	struct remap_data *rmd = data;
	pte_t pte = pte_mkspecial(pfn_pte(rmd->mfn++, rmd->prot));

	rmd->mmu_update->ptr = virt_to_machine(ptep).maddr;
	rmd->mmu_update->val = pte_val_ma(pte);
	rmd->mmu_update++;

	return 0;
}

int xen_remap_domain_mfn_range(struct vm_area_struct *vma,
			       unsigned long addr,
			       unsigned long mfn, int nr,
			       pgprot_t prot, unsigned domid)
{
	struct remap_data rmd;
	struct mmu_update mmu_update[REMAP_BATCH_SIZE];
	int batch;
	unsigned long range;
	int err = 0;

	prot = __pgprot(pgprot_val(prot) | _PAGE_IOMAP);

	BUG_ON(!((vma->vm_flags & (VM_PFNMAP | VM_RESERVED | VM_IO)) ==
				(VM_PFNMAP | VM_RESERVED | VM_IO)));

	if (xen_feature(XENFEAT_auto_translated_physmap)) {
		/* We need to update the local page tables and the xen HAP */
		return pvh_remap_gmfn_range(vma, addr, mfn, nr, prot, domid);
	}

	rmd.mfn = mfn;
	rmd.prot = prot;

	while (nr) {
		batch = min(REMAP_BATCH_SIZE, nr);
		range = (unsigned long)batch << PAGE_SHIFT;

		rmd.mmu_update = mmu_update;
		err = apply_to_page_range(vma->vm_mm, addr, range,
					  remap_area_mfn_pte_fn, &rmd);
		if (err)
			goto out;

		err = -EFAULT;
		if (HYPERVISOR_mmu_update(mmu_update, batch, NULL, domid) < 0)
			goto out;

		nr -= batch;
		addr += range;
	}

	err = 0;
out:

	flush_tlb_all();

	return err;
}
EXPORT_SYMBOL_GPL(xen_remap_domain_mfn_range);

int xen_unmap_domain_mfn_range(struct vm_area_struct *vma)
{
	struct xen_pvh_sav_pfn_info *savp = vma ? vma->vm_private_data : NULL;

	if (!savp || !xen_feature(XENFEAT_auto_translated_physmap))
		return 0;

	while (savp->sp_next_todo--) {
		unsigned long pfn;
#if 0
		unsigned int level;
		pte_t *ptep = lookup_address(savp->sp_addr, &level);

		set_pte(ptep, __pte(0));
#endif
		pfn = page_to_pfn(savp->sp_paga[savp->sp_next_todo]);
		pvh_rem_xen_p2m(pfn, 1);

		free_xenballooned_pages(1, &savp->sp_paga[savp->sp_next_todo]);
	}

	flush_tlb_all();
	return 0;
}
EXPORT_SYMBOL_GPL(xen_unmap_domain_mfn_range);

--MP_/VbujuzxBRJmnncQgGTu8kEI
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 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_/VbujuzxBRJmnncQgGTu8kEI--


From xen-devel-bounces@lists.xen.org Thu Sep 13 02:01:20 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Sep 2012 02: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 1TByjV-00036a-0B; Thu, 13 Sep 2012 02:00:45 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1TByjT-00036V-43
	for xen-devel@lists.xensource.com; Thu, 13 Sep 2012 02:00:43 +0000
Received: from [85.158.138.51:45031] by server-12.bemta-3.messagelabs.com id
	9E/1F-10384-94E31505; Thu, 13 Sep 2012 02:00:41 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1347501640!28475317!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDg4Njg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7668 invoked from network); 13 Sep 2012 02:00:41 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Sep 2012 02:00:41 -0000
X-IronPort-AV: E=Sophos;i="4.80,413,1344211200"; d="scan'208";a="14507775"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Sep 2012 02:00: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.279.1; Thu, 13 Sep 2012 03:00: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 1TByjP-0006pT-Ax;
	Thu, 13 Sep 2012 02:00:39 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1TByjP-0007eb-8F;
	Thu, 13 Sep 2012 03:00:39 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-13704-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 13 Sep 2012 03:00:39 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.1-testing test] 13704: FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 13704 xen-4.1-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13704/

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64-pvops            2 host-install(2) broken in 13690 REGR. vs. 13657

Tests which are failing intermittently (not blocking):
 test-i386-i386-xl-win         7 windows-install             fail pass in 13690

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-pcipt-intel  8 debian-fixup                fail like 13657
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 13657

Tests which did not succeed, but are not blocking:
 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-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-win         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-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 13 guest-stop               fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel 11 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-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-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-i386-i386-xl-qemuu-winxpsp3 13 guest-stop                 fail never pass
 test-amd64-amd64-xl-pcipt-intel  1 xen-build-check(1)     blocked in 13690 n/a
 test-amd64-amd64-pv           1 xen-build-check(1)        blocked in 13690 n/a
 test-amd64-amd64-xl           1 xen-build-check(1)        blocked in 13690 n/a
 test-amd64-amd64-xl-sedf-pin  1 xen-build-check(1)        blocked in 13690 n/a
 test-amd64-amd64-xl-sedf      1 xen-build-check(1)        blocked in 13690 n/a
 test-amd64-amd64-pair         1 xen-build-check(1)        blocked in 13690 n/a
 test-amd64-amd64-win          1 xen-build-check(1)        blocked in 13690 n/a
 test-i386-i386-xl-win        13 guest-stop            fail in 13690 never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  1 xen-build-check(1)  blocked in 13690 n/a
 test-amd64-amd64-xl-qemuu-win7-amd64 1 xen-build-check(1) blocked in 13690 n/a
 test-amd64-amd64-xl-win7-amd64  1 xen-build-check(1)      blocked in 13690 n/a
 test-amd64-amd64-xl-win       1 xen-build-check(1)        blocked in 13690 n/a
 test-amd64-amd64-xl-winxpsp3  1 xen-build-check(1)        blocked in 13690 n/a

version targeted for testing:
 xen                  9be1175d2ac3
baseline version:
 xen                  3e4782f17f5c

------------------------------------------------------------
People who touched revisions under test:
  Ian Jackson <ian.jackson@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                                     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.

------------------------------------------------------------
changeset:   23354:9be1175d2ac3
tag:         tip
user:        Ian Jackson <Ian.Jackson@eu.citrix.com>
date:        Tue Sep 11 14:31:12 2012 +0100
    
    QEMU_TAG update
    
    
changeset:   23353:3e4782f17f5c
user:        Ian Jackson <Ian.Jackson@eu.citrix.com>
date:        Wed Sep 05 12:40:10 2012 +0100
    
    QEMU_TAG update (XSA-17 / CVE-2012-3515)
    
    
========================================
commit d7d453f51459b591faa96d1c123b5bfff7c5b6b6
Author: Ian Jackson <ian.jackson@eu.citrix.com>
Date:   Thu Sep 6 17:05:30 2012 +0100

    Disable qemu monitor by default.  The qemu monitor is an overly
    powerful feature which must be protected from untrusted (guest)
    administrators.
    
    Neither xl nor xend expect qemu to produce this monitor unless it is
    explicitly requested.
    
    This is a security problem, XSA-19.  Previously it was CVE-2007-0998
    in Red Hat but we haven't dealt with it in upstream.  We hope to have
    a new CVE for it here but we don't have one yet.
    
    Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
    (cherry picked from commit bacc0d302445c75f18f4c826750fb5853b60e7ca)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 13 02:01:20 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Sep 2012 02: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 1TByjV-00036a-0B; Thu, 13 Sep 2012 02:00:45 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1TByjT-00036V-43
	for xen-devel@lists.xensource.com; Thu, 13 Sep 2012 02:00:43 +0000
Received: from [85.158.138.51:45031] by server-12.bemta-3.messagelabs.com id
	9E/1F-10384-94E31505; Thu, 13 Sep 2012 02:00:41 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1347501640!28475317!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDg4Njg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7668 invoked from network); 13 Sep 2012 02:00:41 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Sep 2012 02:00:41 -0000
X-IronPort-AV: E=Sophos;i="4.80,413,1344211200"; d="scan'208";a="14507775"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Sep 2012 02:00: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.279.1; Thu, 13 Sep 2012 03:00: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 1TByjP-0006pT-Ax;
	Thu, 13 Sep 2012 02:00:39 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1TByjP-0007eb-8F;
	Thu, 13 Sep 2012 03:00:39 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-13704-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 13 Sep 2012 03:00:39 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.1-testing test] 13704: FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 13704 xen-4.1-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13704/

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64-pvops            2 host-install(2) broken in 13690 REGR. vs. 13657

Tests which are failing intermittently (not blocking):
 test-i386-i386-xl-win         7 windows-install             fail pass in 13690

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-pcipt-intel  8 debian-fixup                fail like 13657
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 13657

Tests which did not succeed, but are not blocking:
 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-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-win         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-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 13 guest-stop               fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel 11 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-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-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-i386-i386-xl-qemuu-winxpsp3 13 guest-stop                 fail never pass
 test-amd64-amd64-xl-pcipt-intel  1 xen-build-check(1)     blocked in 13690 n/a
 test-amd64-amd64-pv           1 xen-build-check(1)        blocked in 13690 n/a
 test-amd64-amd64-xl           1 xen-build-check(1)        blocked in 13690 n/a
 test-amd64-amd64-xl-sedf-pin  1 xen-build-check(1)        blocked in 13690 n/a
 test-amd64-amd64-xl-sedf      1 xen-build-check(1)        blocked in 13690 n/a
 test-amd64-amd64-pair         1 xen-build-check(1)        blocked in 13690 n/a
 test-amd64-amd64-win          1 xen-build-check(1)        blocked in 13690 n/a
 test-i386-i386-xl-win        13 guest-stop            fail in 13690 never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  1 xen-build-check(1)  blocked in 13690 n/a
 test-amd64-amd64-xl-qemuu-win7-amd64 1 xen-build-check(1) blocked in 13690 n/a
 test-amd64-amd64-xl-win7-amd64  1 xen-build-check(1)      blocked in 13690 n/a
 test-amd64-amd64-xl-win       1 xen-build-check(1)        blocked in 13690 n/a
 test-amd64-amd64-xl-winxpsp3  1 xen-build-check(1)        blocked in 13690 n/a

version targeted for testing:
 xen                  9be1175d2ac3
baseline version:
 xen                  3e4782f17f5c

------------------------------------------------------------
People who touched revisions under test:
  Ian Jackson <ian.jackson@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                                     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.

------------------------------------------------------------
changeset:   23354:9be1175d2ac3
tag:         tip
user:        Ian Jackson <Ian.Jackson@eu.citrix.com>
date:        Tue Sep 11 14:31:12 2012 +0100
    
    QEMU_TAG update
    
    
changeset:   23353:3e4782f17f5c
user:        Ian Jackson <Ian.Jackson@eu.citrix.com>
date:        Wed Sep 05 12:40:10 2012 +0100
    
    QEMU_TAG update (XSA-17 / CVE-2012-3515)
    
    
========================================
commit d7d453f51459b591faa96d1c123b5bfff7c5b6b6
Author: Ian Jackson <ian.jackson@eu.citrix.com>
Date:   Thu Sep 6 17:05:30 2012 +0100

    Disable qemu monitor by default.  The qemu monitor is an overly
    powerful feature which must be protected from untrusted (guest)
    administrators.
    
    Neither xl nor xend expect qemu to produce this monitor unless it is
    explicitly requested.
    
    This is a security problem, XSA-19.  Previously it was CVE-2007-0998
    in Red Hat but we haven't dealt with it in upstream.  We hope to have
    a new CVE for it here but we don't have one yet.
    
    Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
    (cherry picked from commit bacc0d302445c75f18f4c826750fb5853b60e7ca)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 13 02:28:49 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Sep 2012 02:28:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TBzAE-0003Mn-FK; Thu, 13 Sep 2012 02:28:22 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <ronghui.duan@intel.com>) id 1TBzAD-0003Mh-2d
	for xen-devel@lists.xen.org; Thu, 13 Sep 2012 02:28:21 +0000
X-Env-Sender: ronghui.duan@intel.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1347503294!10814429!1
X-Originating-IP: [192.55.52.93]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjkzID0+IDM0NjA3NQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6890 invoked from network); 13 Sep 2012 02:28:15 -0000
Received: from mga11.intel.com (HELO mga11.intel.com) (192.55.52.93)
	by server-12.tower-27.messagelabs.com with SMTP;
	13 Sep 2012 02:28:15 -0000
Received: from fmsmga002.fm.intel.com ([10.253.24.26])
	by fmsmga102.fm.intel.com with ESMTP; 12 Sep 2012 19:28:13 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.80,413,1344236400"; d="scan'208";a="221339195"
Received: from fmsmsx105.amr.corp.intel.com ([10.19.9.36])
	by fmsmga002.fm.intel.com with ESMTP; 12 Sep 2012 19:28:13 -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; Wed, 12 Sep 2012 19:28:13 -0700
Received: from shsmsx102.ccr.corp.intel.com ([169.254.2.92]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.175]) with mapi id
	14.01.0355.002; Thu, 13 Sep 2012 10:28:12 +0800
From: "Duan, Ronghui" <ronghui.duan@intel.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Thread-Topic: [Xen-devel] [RFC v1 0/5] VBD: enlarge max segment per request
	in blkfront
Thread-Index: Ac17mRnxOUx7HczFSN2/QYn7Hm+BlQRRPS0AAR4vKmA=
Date: Thu, 13 Sep 2012 02:28:12 +0000
Message-ID: <A21691DE07B84740B5F0B81466D5148A23BF6833@SHSMSX102.ccr.corp.intel.com>
References: <A21691DE07B84740B5F0B81466D5148A23BCF1DF@SHSMSX102.ccr.corp.intel.com>
	<20120907174922.GA13040@phenom.dumpdata.com>
In-Reply-To: <20120907174922.GA13040@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: "Stefano.Stabellini@eu.citrix.com" <Stefano.Stabellini@eu.citrix.com>,
	"Ian.Jackson@eu.citrix.com" <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [RFC v1 0/5] VBD: enlarge max segment per request
 in blkfront
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> form xentop.
> > Read 1K random	IOPS	   Dom0 CPU	DomU CPU%
> > 		W	52005.9	86.6	71
> > 		W/O	52123.1	85.8	66.9
> 
> So I am getting some different numbers. I tried a simple 4K read:
> 
> [/dev/xvda1]
> bssplit=4K
> rw=read
> direct=1
> size=4g
> ioengine=libaio
> iodepth=64
> 
> And with your patch got:
>   read : io=4096.0MB, bw=92606KB/s, iops=23151 , runt= 45292msec
> 
> without:
>   read : io=4096.0MB, bw=145187KB/s, iops=36296 , runt= 28889msec
> 
What type of backend file you are using? In order to remove the influence of cache in Dom0, I use a physical partition as backend.
In code level, although there is some overhead in my patch compared to original, but it should not to be so big. :)

-ronghui

> -----Original Message-----
> From: Konrad Rzeszutek Wilk [mailto:konrad.wilk@oracle.com]
> Sent: Saturday, September 08, 2012 1:49 AM
> To: Duan, Ronghui
> Cc: xen-devel@lists.xen.org; Ian.Jackson@eu.citrix.com;
> Stefano.Stabellini@eu.citrix.com
> Subject: Re: [Xen-devel] [RFC v1 0/5] VBD: enlarge max segment per request in
> blkfront
> 
> On Thu, Aug 16, 2012 at 10:22:56AM +0000, Duan, Ronghui wrote:
> > Hi, list.
> > The max segments for request in VBD queue is 11, while for Linux OS/ other
> VMM, the parameter is set to 128 in default. This may be caused by the limited
> size of ring between Front/Back. So I guess whether we can put segment data
> into another ring and dynamic use them for the single request's need. Here is
> prototype which don't do much test, but it can work on Linux 64 bits 3.4.6
> kernel. I can see the CPU% can be reduced to 1/3 compared to original in
> sequential test. But it bring some overhead which will make random IO's cpu
> utilization increase a little.
> >
> > Here is a short version data use only 1K random read and 64K sequential read
> in direct mode. Testing a physical SSD disk as blkback in backend. CPU% is got
> form xentop.
> > Read 1K random	IOPS	   Dom0 CPU	DomU CPU%
> > 		W	52005.9	86.6	71
> > 		W/O	52123.1	85.8	66.9
> 
> So I am getting some different numbers. I tried a simple 4K read:
> 
> [/dev/xvda1]
> bssplit=4K
> rw=read
> direct=1
> size=4g
> ioengine=libaio
> iodepth=64
> 
> And with your patch got:
>   read : io=4096.0MB, bw=92606KB/s, iops=23151 , runt= 45292msec
> 
> without:
>   read : io=4096.0MB, bw=145187KB/s, iops=36296 , runt= 28889msec
> 
> 
> >
> > Read 64K seq	BW MB/s	Dom0 CPU	DomU CPU%
> > 	W	250		27.1	       10.6
> > 	W/O	250		62.6	       31.1
> 
> Hadn't tried that yet.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 13 02:28:49 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Sep 2012 02:28:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TBzAE-0003Mn-FK; Thu, 13 Sep 2012 02:28:22 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <ronghui.duan@intel.com>) id 1TBzAD-0003Mh-2d
	for xen-devel@lists.xen.org; Thu, 13 Sep 2012 02:28:21 +0000
X-Env-Sender: ronghui.duan@intel.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1347503294!10814429!1
X-Originating-IP: [192.55.52.93]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjkzID0+IDM0NjA3NQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6890 invoked from network); 13 Sep 2012 02:28:15 -0000
Received: from mga11.intel.com (HELO mga11.intel.com) (192.55.52.93)
	by server-12.tower-27.messagelabs.com with SMTP;
	13 Sep 2012 02:28:15 -0000
Received: from fmsmga002.fm.intel.com ([10.253.24.26])
	by fmsmga102.fm.intel.com with ESMTP; 12 Sep 2012 19:28:13 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.80,413,1344236400"; d="scan'208";a="221339195"
Received: from fmsmsx105.amr.corp.intel.com ([10.19.9.36])
	by fmsmga002.fm.intel.com with ESMTP; 12 Sep 2012 19:28:13 -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; Wed, 12 Sep 2012 19:28:13 -0700
Received: from shsmsx102.ccr.corp.intel.com ([169.254.2.92]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.175]) with mapi id
	14.01.0355.002; Thu, 13 Sep 2012 10:28:12 +0800
From: "Duan, Ronghui" <ronghui.duan@intel.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Thread-Topic: [Xen-devel] [RFC v1 0/5] VBD: enlarge max segment per request
	in blkfront
Thread-Index: Ac17mRnxOUx7HczFSN2/QYn7Hm+BlQRRPS0AAR4vKmA=
Date: Thu, 13 Sep 2012 02:28:12 +0000
Message-ID: <A21691DE07B84740B5F0B81466D5148A23BF6833@SHSMSX102.ccr.corp.intel.com>
References: <A21691DE07B84740B5F0B81466D5148A23BCF1DF@SHSMSX102.ccr.corp.intel.com>
	<20120907174922.GA13040@phenom.dumpdata.com>
In-Reply-To: <20120907174922.GA13040@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: "Stefano.Stabellini@eu.citrix.com" <Stefano.Stabellini@eu.citrix.com>,
	"Ian.Jackson@eu.citrix.com" <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [RFC v1 0/5] VBD: enlarge max segment per request
 in blkfront
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> form xentop.
> > Read 1K random	IOPS	   Dom0 CPU	DomU CPU%
> > 		W	52005.9	86.6	71
> > 		W/O	52123.1	85.8	66.9
> 
> So I am getting some different numbers. I tried a simple 4K read:
> 
> [/dev/xvda1]
> bssplit=4K
> rw=read
> direct=1
> size=4g
> ioengine=libaio
> iodepth=64
> 
> And with your patch got:
>   read : io=4096.0MB, bw=92606KB/s, iops=23151 , runt= 45292msec
> 
> without:
>   read : io=4096.0MB, bw=145187KB/s, iops=36296 , runt= 28889msec
> 
What type of backend file you are using? In order to remove the influence of cache in Dom0, I use a physical partition as backend.
In code level, although there is some overhead in my patch compared to original, but it should not to be so big. :)

-ronghui

> -----Original Message-----
> From: Konrad Rzeszutek Wilk [mailto:konrad.wilk@oracle.com]
> Sent: Saturday, September 08, 2012 1:49 AM
> To: Duan, Ronghui
> Cc: xen-devel@lists.xen.org; Ian.Jackson@eu.citrix.com;
> Stefano.Stabellini@eu.citrix.com
> Subject: Re: [Xen-devel] [RFC v1 0/5] VBD: enlarge max segment per request in
> blkfront
> 
> On Thu, Aug 16, 2012 at 10:22:56AM +0000, Duan, Ronghui wrote:
> > Hi, list.
> > The max segments for request in VBD queue is 11, while for Linux OS/ other
> VMM, the parameter is set to 128 in default. This may be caused by the limited
> size of ring between Front/Back. So I guess whether we can put segment data
> into another ring and dynamic use them for the single request's need. Here is
> prototype which don't do much test, but it can work on Linux 64 bits 3.4.6
> kernel. I can see the CPU% can be reduced to 1/3 compared to original in
> sequential test. But it bring some overhead which will make random IO's cpu
> utilization increase a little.
> >
> > Here is a short version data use only 1K random read and 64K sequential read
> in direct mode. Testing a physical SSD disk as blkback in backend. CPU% is got
> form xentop.
> > Read 1K random	IOPS	   Dom0 CPU	DomU CPU%
> > 		W	52005.9	86.6	71
> > 		W/O	52123.1	85.8	66.9
> 
> So I am getting some different numbers. I tried a simple 4K read:
> 
> [/dev/xvda1]
> bssplit=4K
> rw=read
> direct=1
> size=4g
> ioengine=libaio
> iodepth=64
> 
> And with your patch got:
>   read : io=4096.0MB, bw=92606KB/s, iops=23151 , runt= 45292msec
> 
> without:
>   read : io=4096.0MB, bw=145187KB/s, iops=36296 , runt= 28889msec
> 
> 
> >
> > Read 64K seq	BW MB/s	Dom0 CPU	DomU CPU%
> > 	W	250		27.1	       10.6
> > 	W/O	250		62.6	       31.1
> 
> Hadn't tried that yet.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 13 05:05:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Sep 2012 05:05:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TC1cE-0004Z3-UE; Thu, 13 Sep 2012 05:05:26 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <robherring2@gmail.com>) id 1TBzGI-0003a6-8O
	for xen-devel@lists.xensource.com; Thu, 13 Sep 2012 02:34:38 +0000
Received: from [85.158.143.99:28819] by server-1.bemta-4.messagelabs.com id
	FF/9C-12504-D3641505; Thu, 13 Sep 2012 02:34:37 +0000
X-Env-Sender: robherring2@gmail.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1347503675!22544727!1
X-Originating-IP: [209.85.214.171]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26825 invoked from network); 13 Sep 2012 02:34:36 -0000
Received: from mail-ob0-f171.google.com (HELO mail-ob0-f171.google.com)
	(209.85.214.171)
	by server-11.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Sep 2012 02:34:36 -0000
Received: by obqv19 with SMTP id v19so5043090obq.30
	for <xen-devel@lists.xensource.com>;
	Wed, 12 Sep 2012 19:34:32 -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=ubHOevVYuAHChx0XFnJ56wdkRWFTfteg8zCsYbtCiDM=;
	b=pctoa+/V0jw/ekN3Yoo0R6hiDyk6pBLnPnhVQoOX8qoxosrrFeT5Ns39dUIscUAkZu
	5zojxUPtcCMwErKcAPnbDk75fbapsKffueshNHRUJwyB1XYQ2tDlTjpuTVtYxLtE82WI
	5t3RTG94YOml1mBx10pbFri5gRGNmqa/ngZrcTg7P/SFGtzeV+aA5egfhT5l5umdFlCr
	R5HVDtEC8BPjt9Kygqonyjw7kQQFxAGX4Kug7p43QrmRHJeKgPlAf6hr1uCWXnKg9kKv
	tVDUKml1/ncHIqGq+WfMIU8r0TyGK8POTUB+aFvsFq5O1EvU1LDhSk/+Sop0Cxe0PI/O
	RwWQ==
Received: by 10.60.169.8 with SMTP id aa8mr348415oec.109.1347503672033;
	Wed, 12 Sep 2012 19:34:32 -0700 (PDT)
Received: from [192.168.1.103] (65-36-73-129.dyn.grandenetworks.net.
	[65.36.73.129])
	by mx.google.com with ESMTPS id jl8sm22289607obb.18.2012.09.12.19.34.29
	(version=SSLv3 cipher=OTHER); Wed, 12 Sep 2012 19:34:31 -0700 (PDT)
Message-ID: <50514634.3080303@gmail.com>
Date: Wed, 12 Sep 2012 21:34:28 -0500
From: Rob Herring <robherring2@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:14.0) Gecko/20120714 Thunderbird/14.0
MIME-Version: 1.0
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.02.1208161618550.4850@kaball.uk.xensource.com>
	<1345131377-14713-6-git-send-email-stefano.stabellini@eu.citrix.com>
	<503BFCD8.5090804@gmail.com>
	<alpine.DEB.2.02.1208281823270.15568@kaball.uk.xensource.com>
	<alpine.DEB.2.02.1209121849200.15568@kaball.uk.xensource.com>
In-Reply-To: <alpine.DEB.2.02.1209121849200.15568@kaball.uk.xensource.com>
X-Mailman-Approved-At: Thu, 13 Sep 2012 05:05:26 +0000
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linaro-dev@lists.linaro.org" <linaro-dev@lists.linaro.org>,
	Ian Campbell <Ian.Campbell@citrix.com>, "arnd@arndb.de" <arnd@arndb.de>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
	Marc Zyngier <marc.zyngier@arm.com>,
	"catalin.marinas@arm.com" <catalin.marinas@arm.com>,
	"devicetree-discuss@lists.ozlabs.org"
	<devicetree-discuss@lists.ozlabs.org>, "Tim \(Xen.org\)" <tim@xen.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	David Vrabel <david.vrabel@citrix.com>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Xen-devel] [PATCH v3 06/25] docs: Xen ARM DT bindings
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 09/12/2012 01:14 PM, Stefano Stabellini wrote:
> On Wed, 12 Sep 2012, Stefano Stabellini wrote:
>> On Tue, 28 Aug 2012, Rob Herring wrote:
>>> You should look at ePAPR 1.1 which defines hypervisor related bindings.
>>> While it is a PPC doc, we should reuse or extend what makes sense.
>>>
>>> See section 7.5:
>>>
>>> https://www.power.org/resources/downloads/Power_ePAPR_APPROVED_v1.1.pdf
>>
>> Thanks for the link, I wasn't aware of ePAPR.
>>
>> The hypervisor node defined by ePAPR is not very different from what I
>> am proposing. Should I try to be compatible with the hypervisor
>> specification above (as in compatible = "epapr,hypervisor-1.1")?
>> Or should I just use it as a reference for my own specification?
>>
>> Personally I would rather avoid full compatibility with ePAPR.
> 
> In particular reading section 7.5, these are the required properties of
> the ePAPR hypervisor node:
> 
> - compatible = "epapr,hypervisor-1.1"
> compared to what I am proposing, it is laking information about what
> hypervisor we are talking about (xen, kvm, vmware, etc) and the version
> of the ABI (xen-4.2).

compatible properties are often changed. If we do deviate on the rest of
the binding, then it needs to be different.

Turns out that powerpc KVM guests use "linux,kvm" and "epapr,hypervisor"
doesn't even appear in the kernel.

We also perhaps have to consider the possibility of Xen on PowerPC. Then
alignment is more important.

> - hcall-instructions
> potentially interesting, but given that for Xen we are quite happy with
> HVC, we are not going to add any secondary hypercall mechanisms,
> therefore at the moment it would just result in a BUG if the specified
> hcall instruction is != HVC. Besides if somebody else wanted to
> implemented the Xen hypercall interface in a different way they could
> just reimplement the hypercall wrappers, that would be easier than
> trying to do it with this property.

It's really about the parameters passed with the HVC. The ePAPR may be a
good model for defining this. Just grepping "hypervisor" under
arch/powerpc, it's pretty clear hypervisor support happened first and
the ePAPR came second. Hopefully we can avoid that for ARM.

> - guest-id
> we usually make a point in trying not to tell the guest its own domid
> because if the VM gets migrated to a different host it acquires a new
> domid, therefore it should not rely on it.
> 
> - guest-name
> we could pass the guest name here, but I don't see how it could be
> of any use.
> 

I have no issue with these being optional.

> 
> On the other hand, thinking more about what Xen needs in the device
> tree, I think we could improve the current spec by clarifying the
> meaning of the memory region and interrupt properties we currently
> require. I thought about moving them to two separate children node with
> an explicit name:
> 
> ---
> 
> * Xen hypervisor device tree bindings
> 

I really think we need to define ARM hypervisor device tree bindings
first, then Xen specific bindings as an addition to that. I worry that
the KVM folks aren't paying attention and then want something different
later on.

> Xen ARM virtual platforms shall have the following properties and
> children nodes:
> 
> - compatible property:
> 	compatible = "xen,xen", "xen,xen-<version>";

"xen,xen" should be last as it is less specific.

>   where <version> is the version of the Xen ABI of the platform.
> 
> - grant_table child with the following properties:
>     - name:
> 	    name = "grant_table";

What's a grant table?

> 	- reg: specifies the base physical address and size of a region in
> 	    memory where the grant table should be mapped to, using an
>         HYPERVISOR_memory_op hypercall. 
> 
> - events child with the following properties:
>     - name:
>         name = "events";
> 	- interrupts: the interrupt used by Xen to inject event notifications.

Why a child node? Just an interrupts property alone should be fine. If
you have cases with different number of interrupts, the compatible
property can distinguish that.

Rob

> 
> 
> Example:
> hypervisor {
> 		compatible = "xen,xen", "xen,xen-4.2";
> 		#address-cells = <1>;
> 		#size-cells = <1>;
> 		#interrupt-cells = <3>;
> 		ranges = <0xb0000000 0xb0000000 0x20000>;
> 
> 		grant_table {
> 			name = "grant_table";
> 			reg = <0xb0000000 0x20000>;
> 		};
> 
> 		events {
> 			name = "events";
> 			interrupts = <1 15 0xf08>;
> 		};
> 	};
> 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 13 05:05:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Sep 2012 05:05:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TC1cE-0004Z3-UE; Thu, 13 Sep 2012 05:05:26 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <robherring2@gmail.com>) id 1TBzGI-0003a6-8O
	for xen-devel@lists.xensource.com; Thu, 13 Sep 2012 02:34:38 +0000
Received: from [85.158.143.99:28819] by server-1.bemta-4.messagelabs.com id
	FF/9C-12504-D3641505; Thu, 13 Sep 2012 02:34:37 +0000
X-Env-Sender: robherring2@gmail.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1347503675!22544727!1
X-Originating-IP: [209.85.214.171]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26825 invoked from network); 13 Sep 2012 02:34:36 -0000
Received: from mail-ob0-f171.google.com (HELO mail-ob0-f171.google.com)
	(209.85.214.171)
	by server-11.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Sep 2012 02:34:36 -0000
Received: by obqv19 with SMTP id v19so5043090obq.30
	for <xen-devel@lists.xensource.com>;
	Wed, 12 Sep 2012 19:34:32 -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=ubHOevVYuAHChx0XFnJ56wdkRWFTfteg8zCsYbtCiDM=;
	b=pctoa+/V0jw/ekN3Yoo0R6hiDyk6pBLnPnhVQoOX8qoxosrrFeT5Ns39dUIscUAkZu
	5zojxUPtcCMwErKcAPnbDk75fbapsKffueshNHRUJwyB1XYQ2tDlTjpuTVtYxLtE82WI
	5t3RTG94YOml1mBx10pbFri5gRGNmqa/ngZrcTg7P/SFGtzeV+aA5egfhT5l5umdFlCr
	R5HVDtEC8BPjt9Kygqonyjw7kQQFxAGX4Kug7p43QrmRHJeKgPlAf6hr1uCWXnKg9kKv
	tVDUKml1/ncHIqGq+WfMIU8r0TyGK8POTUB+aFvsFq5O1EvU1LDhSk/+Sop0Cxe0PI/O
	RwWQ==
Received: by 10.60.169.8 with SMTP id aa8mr348415oec.109.1347503672033;
	Wed, 12 Sep 2012 19:34:32 -0700 (PDT)
Received: from [192.168.1.103] (65-36-73-129.dyn.grandenetworks.net.
	[65.36.73.129])
	by mx.google.com with ESMTPS id jl8sm22289607obb.18.2012.09.12.19.34.29
	(version=SSLv3 cipher=OTHER); Wed, 12 Sep 2012 19:34:31 -0700 (PDT)
Message-ID: <50514634.3080303@gmail.com>
Date: Wed, 12 Sep 2012 21:34:28 -0500
From: Rob Herring <robherring2@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:14.0) Gecko/20120714 Thunderbird/14.0
MIME-Version: 1.0
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.02.1208161618550.4850@kaball.uk.xensource.com>
	<1345131377-14713-6-git-send-email-stefano.stabellini@eu.citrix.com>
	<503BFCD8.5090804@gmail.com>
	<alpine.DEB.2.02.1208281823270.15568@kaball.uk.xensource.com>
	<alpine.DEB.2.02.1209121849200.15568@kaball.uk.xensource.com>
In-Reply-To: <alpine.DEB.2.02.1209121849200.15568@kaball.uk.xensource.com>
X-Mailman-Approved-At: Thu, 13 Sep 2012 05:05:26 +0000
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linaro-dev@lists.linaro.org" <linaro-dev@lists.linaro.org>,
	Ian Campbell <Ian.Campbell@citrix.com>, "arnd@arndb.de" <arnd@arndb.de>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
	Marc Zyngier <marc.zyngier@arm.com>,
	"catalin.marinas@arm.com" <catalin.marinas@arm.com>,
	"devicetree-discuss@lists.ozlabs.org"
	<devicetree-discuss@lists.ozlabs.org>, "Tim \(Xen.org\)" <tim@xen.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	David Vrabel <david.vrabel@citrix.com>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Xen-devel] [PATCH v3 06/25] docs: Xen ARM DT bindings
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 09/12/2012 01:14 PM, Stefano Stabellini wrote:
> On Wed, 12 Sep 2012, Stefano Stabellini wrote:
>> On Tue, 28 Aug 2012, Rob Herring wrote:
>>> You should look at ePAPR 1.1 which defines hypervisor related bindings.
>>> While it is a PPC doc, we should reuse or extend what makes sense.
>>>
>>> See section 7.5:
>>>
>>> https://www.power.org/resources/downloads/Power_ePAPR_APPROVED_v1.1.pdf
>>
>> Thanks for the link, I wasn't aware of ePAPR.
>>
>> The hypervisor node defined by ePAPR is not very different from what I
>> am proposing. Should I try to be compatible with the hypervisor
>> specification above (as in compatible = "epapr,hypervisor-1.1")?
>> Or should I just use it as a reference for my own specification?
>>
>> Personally I would rather avoid full compatibility with ePAPR.
> 
> In particular reading section 7.5, these are the required properties of
> the ePAPR hypervisor node:
> 
> - compatible = "epapr,hypervisor-1.1"
> compared to what I am proposing, it is laking information about what
> hypervisor we are talking about (xen, kvm, vmware, etc) and the version
> of the ABI (xen-4.2).

compatible properties are often changed. If we do deviate on the rest of
the binding, then it needs to be different.

Turns out that powerpc KVM guests use "linux,kvm" and "epapr,hypervisor"
doesn't even appear in the kernel.

We also perhaps have to consider the possibility of Xen on PowerPC. Then
alignment is more important.

> - hcall-instructions
> potentially interesting, but given that for Xen we are quite happy with
> HVC, we are not going to add any secondary hypercall mechanisms,
> therefore at the moment it would just result in a BUG if the specified
> hcall instruction is != HVC. Besides if somebody else wanted to
> implemented the Xen hypercall interface in a different way they could
> just reimplement the hypercall wrappers, that would be easier than
> trying to do it with this property.

It's really about the parameters passed with the HVC. The ePAPR may be a
good model for defining this. Just grepping "hypervisor" under
arch/powerpc, it's pretty clear hypervisor support happened first and
the ePAPR came second. Hopefully we can avoid that for ARM.

> - guest-id
> we usually make a point in trying not to tell the guest its own domid
> because if the VM gets migrated to a different host it acquires a new
> domid, therefore it should not rely on it.
> 
> - guest-name
> we could pass the guest name here, but I don't see how it could be
> of any use.
> 

I have no issue with these being optional.

> 
> On the other hand, thinking more about what Xen needs in the device
> tree, I think we could improve the current spec by clarifying the
> meaning of the memory region and interrupt properties we currently
> require. I thought about moving them to two separate children node with
> an explicit name:
> 
> ---
> 
> * Xen hypervisor device tree bindings
> 

I really think we need to define ARM hypervisor device tree bindings
first, then Xen specific bindings as an addition to that. I worry that
the KVM folks aren't paying attention and then want something different
later on.

> Xen ARM virtual platforms shall have the following properties and
> children nodes:
> 
> - compatible property:
> 	compatible = "xen,xen", "xen,xen-<version>";

"xen,xen" should be last as it is less specific.

>   where <version> is the version of the Xen ABI of the platform.
> 
> - grant_table child with the following properties:
>     - name:
> 	    name = "grant_table";

What's a grant table?

> 	- reg: specifies the base physical address and size of a region in
> 	    memory where the grant table should be mapped to, using an
>         HYPERVISOR_memory_op hypercall. 
> 
> - events child with the following properties:
>     - name:
>         name = "events";
> 	- interrupts: the interrupt used by Xen to inject event notifications.

Why a child node? Just an interrupts property alone should be fine. If
you have cases with different number of interrupts, the compatible
property can distinguish that.

Rob

> 
> 
> Example:
> hypervisor {
> 		compatible = "xen,xen", "xen,xen-4.2";
> 		#address-cells = <1>;
> 		#size-cells = <1>;
> 		#interrupt-cells = <3>;
> 		ranges = <0xb0000000 0xb0000000 0x20000>;
> 
> 		grant_table {
> 			name = "grant_table";
> 			reg = <0xb0000000 0x20000>;
> 		};
> 
> 		events {
> 			name = "events";
> 			interrupts = <1 15 0xf08>;
> 		};
> 	};
> 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 13 06:00:33 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Sep 2012 06:00:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TC2TE-0005dx-AC; Thu, 13 Sep 2012 06:00:12 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1TC2TC-0005dl-3x
	for Xen-devel@lists.xensource.com; Thu, 13 Sep 2012 06:00:10 +0000
Received: from [85.158.139.83:64742] by server-5.bemta-5.messagelabs.com id
	46/99-30514-96671505; Thu, 13 Sep 2012 06:00:09 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1347516008!16136921!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDg4MjM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10107 invoked from network); 13 Sep 2012 06:00:08 -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;
	13 Sep 2012 06:00:08 -0000
X-IronPort-AV: E=Sophos;i="4.80,415,1344211200"; d="scan'208";a="14509552"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Sep 2012 06:00:08 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Thu, 13 Sep 2012 07:00:08 +0100
Message-ID: <1347516007.25803.44.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Mukesh Rathor <mukesh.rathor@oracle.com>
Date: Thu, 13 Sep 2012 07:00:07 +0100
In-Reply-To: <20120912123238.7057c51a@mantra.us.oracle.com>
References: <20120815175724.3405043a@mantra.us.oracle.com>
	<1347285352.5305.86.camel@zakaz.uk.xensource.com>
	<20120911145751.599b8292@mantra.us.oracle.com>
	<1347437545.25803.16.camel@dagon.hellion.org.uk>
	<20120912110254.10bde333@mantra.us.oracle.com>
	<1347474380.25803.21.camel@dagon.hellion.org.uk>
	<20120912123238.7057c51a@mantra.us.oracle.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [RFC PATCH 1/8]: PVH: Basic and preparatory changes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-09-12 at 20:32 +0100, Mukesh Rathor wrote:
> On Wed, 12 Sep 2012 19:26:20 +0100
> Ian Campbell <Ian.Campbell@citrix.com> wrote:
> 
> > On Wed, 2012-09-12 at 19:02 +0100, Mukesh Rathor wrote:
> > > On Wed, 12 Sep 2012 09:12:25 +0100
> > > Ian Campbell <Ian.Campbell@citrix.com> wrote:
> > > 
> > > > On Tue, 2012-09-11 at 22:57 +0100, Mukesh Rathor wrote:
> > > > > On Mon, 10 Sep 2012 14:55:52 +0100
> > > > > Ian Campbell <Ian.Campbell@citrix.com> wrote:
> > > > It would likely be sufficient to just ifdef the bit which tells
> > > > the builder that this kernel image supports PVH, which I guess is
> > > > one or more XENFEATs in arch/x86/xen/xen-head.S?
> > > > 
> > > Nop, I've not added any new bits. Just using existing bits:
> > > 
> > > XENFEAT_writable_page_tables
> > > XENFEAT_auto_translated_physmap
> > > XENFEAT_supervisor_mode_kernel
> > 
> > Currently we declare:
> >         ELFNOTE(Xen, XEN_ELFNOTE_FEATURES,       .asciz
> > "!writable_page_tables|pae_pgdir_above_4gb")
> > 
> > It might be a mistake for writable_page_tables to be there already but
> > in any case when you add the other two you should gate them on this
> > new option.
> > 
> > (nb: "!foo" means "foo is required" rather than "not foo". I chose a
> > very confusing character for this!)
> > 
> > It may also be worth having a XENFEAT_pvh for us in communicating
> > support for this feature from the kernel to the tools (like
> > XENFEAT_dom0). That's the opposite of case we wanted to avoid
> > (enabling behaviour in the kernel).
> 
> Well, the way I have it is, it's the PV binary. To boot in PVH mode, you
> put pvh=1 in vm.cfg file. The tool stacks read it and tell xen via
> new flag XEN_DOMCTL_CDF_hybrid_guest. Err, make that _pvh_guest.
> xen sets the new is_pvh bit in struct domain. The PVH guest upon boot
> does xen_setup_features() first thing. xen sends it:
> 
> > XENFEAT_writable_page_tables
> > XENFEAT_auto_translated_physmap
> > XENFEAT_supervisor_mode_kernel
>  
> that with callback vector makes it a PVH guest. 

Callback vector is XENFEAT_hvm_callback_vector, I think.

A PV kernel is required to announce the features which it supports via
the elf notes (defined in xen-head.S).

It would be a bug for the toolstack to enable PVH mode for a kernel
which did not claim to support the required featureset.

The aim should be that the user should not normally need to specify pvh
one way or the other, imagine a use case where pygrub is used to boot
both old and new kernels using it.

The toolstack (or the dom0 builder) can make the determination whether
to enable this mode itself itself based on the notes (although it is
always handy to have an override to force things for debug).

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 13 06:00:33 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Sep 2012 06:00:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TC2TE-0005dx-AC; Thu, 13 Sep 2012 06:00:12 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1TC2TC-0005dl-3x
	for Xen-devel@lists.xensource.com; Thu, 13 Sep 2012 06:00:10 +0000
Received: from [85.158.139.83:64742] by server-5.bemta-5.messagelabs.com id
	46/99-30514-96671505; Thu, 13 Sep 2012 06:00:09 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1347516008!16136921!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDg4MjM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10107 invoked from network); 13 Sep 2012 06:00:08 -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;
	13 Sep 2012 06:00:08 -0000
X-IronPort-AV: E=Sophos;i="4.80,415,1344211200"; d="scan'208";a="14509552"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Sep 2012 06:00:08 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Thu, 13 Sep 2012 07:00:08 +0100
Message-ID: <1347516007.25803.44.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Mukesh Rathor <mukesh.rathor@oracle.com>
Date: Thu, 13 Sep 2012 07:00:07 +0100
In-Reply-To: <20120912123238.7057c51a@mantra.us.oracle.com>
References: <20120815175724.3405043a@mantra.us.oracle.com>
	<1347285352.5305.86.camel@zakaz.uk.xensource.com>
	<20120911145751.599b8292@mantra.us.oracle.com>
	<1347437545.25803.16.camel@dagon.hellion.org.uk>
	<20120912110254.10bde333@mantra.us.oracle.com>
	<1347474380.25803.21.camel@dagon.hellion.org.uk>
	<20120912123238.7057c51a@mantra.us.oracle.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [RFC PATCH 1/8]: PVH: Basic and preparatory changes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-09-12 at 20:32 +0100, Mukesh Rathor wrote:
> On Wed, 12 Sep 2012 19:26:20 +0100
> Ian Campbell <Ian.Campbell@citrix.com> wrote:
> 
> > On Wed, 2012-09-12 at 19:02 +0100, Mukesh Rathor wrote:
> > > On Wed, 12 Sep 2012 09:12:25 +0100
> > > Ian Campbell <Ian.Campbell@citrix.com> wrote:
> > > 
> > > > On Tue, 2012-09-11 at 22:57 +0100, Mukesh Rathor wrote:
> > > > > On Mon, 10 Sep 2012 14:55:52 +0100
> > > > > Ian Campbell <Ian.Campbell@citrix.com> wrote:
> > > > It would likely be sufficient to just ifdef the bit which tells
> > > > the builder that this kernel image supports PVH, which I guess is
> > > > one or more XENFEATs in arch/x86/xen/xen-head.S?
> > > > 
> > > Nop, I've not added any new bits. Just using existing bits:
> > > 
> > > XENFEAT_writable_page_tables
> > > XENFEAT_auto_translated_physmap
> > > XENFEAT_supervisor_mode_kernel
> > 
> > Currently we declare:
> >         ELFNOTE(Xen, XEN_ELFNOTE_FEATURES,       .asciz
> > "!writable_page_tables|pae_pgdir_above_4gb")
> > 
> > It might be a mistake for writable_page_tables to be there already but
> > in any case when you add the other two you should gate them on this
> > new option.
> > 
> > (nb: "!foo" means "foo is required" rather than "not foo". I chose a
> > very confusing character for this!)
> > 
> > It may also be worth having a XENFEAT_pvh for us in communicating
> > support for this feature from the kernel to the tools (like
> > XENFEAT_dom0). That's the opposite of case we wanted to avoid
> > (enabling behaviour in the kernel).
> 
> Well, the way I have it is, it's the PV binary. To boot in PVH mode, you
> put pvh=1 in vm.cfg file. The tool stacks read it and tell xen via
> new flag XEN_DOMCTL_CDF_hybrid_guest. Err, make that _pvh_guest.
> xen sets the new is_pvh bit in struct domain. The PVH guest upon boot
> does xen_setup_features() first thing. xen sends it:
> 
> > XENFEAT_writable_page_tables
> > XENFEAT_auto_translated_physmap
> > XENFEAT_supervisor_mode_kernel
>  
> that with callback vector makes it a PVH guest. 

Callback vector is XENFEAT_hvm_callback_vector, I think.

A PV kernel is required to announce the features which it supports via
the elf notes (defined in xen-head.S).

It would be a bug for the toolstack to enable PVH mode for a kernel
which did not claim to support the required featureset.

The aim should be that the user should not normally need to specify pvh
one way or the other, imagine a use case where pygrub is used to boot
both old and new kernels using it.

The toolstack (or the dom0 builder) can make the determination whether
to enable this mode itself itself based on the notes (although it is
always handy to have an override to force things for debug).

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 13 07:05:17 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Sep 2012 07: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 1TC3Tm-0006GS-ID; Thu, 13 Sep 2012 07:04:50 +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 1TC3Tl-0006GN-2M
	for xen-devel@lists.xen.org; Thu, 13 Sep 2012 07:04:49 +0000
Received: from [85.158.138.51:28813] by server-11.bemta-3.messagelabs.com id
	E5/D3-30250-09581505; Thu, 13 Sep 2012 07:04:48 +0000
X-Env-Sender: yongjie.ren@intel.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1347519886!21412367!1
X-Originating-IP: [192.55.52.88]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjg4ID0+IDMyMDM5MA==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13259 invoked from network); 13 Sep 2012 07:04:47 -0000
Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88)
	by server-7.tower-174.messagelabs.com with SMTP;
	13 Sep 2012 07:04:47 -0000
Received: from fmsmga002.fm.intel.com ([10.253.24.26])
	by fmsmga101.fm.intel.com with ESMTP; 13 Sep 2012 00:03:43 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.80,415,1344236400"; d="scan'208";a="221417260"
Received: from fmsmsx108.amr.corp.intel.com ([10.19.9.228])
	by fmsmga002.fm.intel.com with ESMTP; 13 Sep 2012 00:03:25 -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; Thu, 13 Sep 2012 00:03:25 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.239]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.175]) with mapi id
	14.01.0355.002; Thu, 13 Sep 2012 15:02:41 +0800
From: "Ren, Yongjie" <yongjie.ren@intel.com>
To: 'xen-devel' <xen-devel@lists.xen.org>
Thread-Topic: Xen4.2-rc4 test result
Thread-Index: Ac2RfcEB3+BI8Rv+Rju0UbhyhoT7xg==
Date: Thu, 13 Sep 2012 07:02:40 +0000
Message-ID: <1B4B44D9196EFF41AE41FDA404FC0A1019BF79@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: 'Keir Fraser' <keir@xen.org>, 'Ian Campbell' <Ian.Campbell@citrix.com>,
	'Jan Beulich' <JBeulich@suse.com>,
	'Konrad Rzeszutek Wilk' <konrad.wilk@oracle.com>
Subject: [Xen-devel] Xen4.2-rc4 test result
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi All,
We did a round testing for RC4 (CS# 25834) in xen-4.2-testing tree with Linux 3.5.3 dom0.
We found 1 new issue (which is a Dom0 issue and has nothing to do with Xen4.2), and no fixed issue.

New bug (1):
1. XenU PV guest with vif network can't boot up with Linux3.6 dom0
  http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1832
  --A regression from Linux 3.5 to 3.6.

The following are some of the old issues which we guess are something important.
Some of the old issues:
1. Fail to probe NIC driver to HVM domU (with 3.5/3.6 Linux as Dom0)
  http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1824
  -- We already know the corrupt commit in Linux tree. Konrad will try to fix it.
2. Poor performance when do guest save/restore and migration with linux 3.x dom0
  http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1784
3. after detaching a VF from a guest, shutdown the guest is very slow (related to stdvga setting)
  http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1812
4. Dom0 cannot be shut down before PCI device detachment from a running guest
  http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1826
5. Guest hang after resuming from S3
  http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1828
6. Dom0 S3 resume fails
  http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1707

Best Regards,
     Yongjie (Jay)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 13 07:05:17 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Sep 2012 07: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 1TC3Tm-0006GS-ID; Thu, 13 Sep 2012 07:04:50 +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 1TC3Tl-0006GN-2M
	for xen-devel@lists.xen.org; Thu, 13 Sep 2012 07:04:49 +0000
Received: from [85.158.138.51:28813] by server-11.bemta-3.messagelabs.com id
	E5/D3-30250-09581505; Thu, 13 Sep 2012 07:04:48 +0000
X-Env-Sender: yongjie.ren@intel.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1347519886!21412367!1
X-Originating-IP: [192.55.52.88]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjg4ID0+IDMyMDM5MA==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13259 invoked from network); 13 Sep 2012 07:04:47 -0000
Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88)
	by server-7.tower-174.messagelabs.com with SMTP;
	13 Sep 2012 07:04:47 -0000
Received: from fmsmga002.fm.intel.com ([10.253.24.26])
	by fmsmga101.fm.intel.com with ESMTP; 13 Sep 2012 00:03:43 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.80,415,1344236400"; d="scan'208";a="221417260"
Received: from fmsmsx108.amr.corp.intel.com ([10.19.9.228])
	by fmsmga002.fm.intel.com with ESMTP; 13 Sep 2012 00:03:25 -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; Thu, 13 Sep 2012 00:03:25 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.239]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.175]) with mapi id
	14.01.0355.002; Thu, 13 Sep 2012 15:02:41 +0800
From: "Ren, Yongjie" <yongjie.ren@intel.com>
To: 'xen-devel' <xen-devel@lists.xen.org>
Thread-Topic: Xen4.2-rc4 test result
Thread-Index: Ac2RfcEB3+BI8Rv+Rju0UbhyhoT7xg==
Date: Thu, 13 Sep 2012 07:02:40 +0000
Message-ID: <1B4B44D9196EFF41AE41FDA404FC0A1019BF79@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: 'Keir Fraser' <keir@xen.org>, 'Ian Campbell' <Ian.Campbell@citrix.com>,
	'Jan Beulich' <JBeulich@suse.com>,
	'Konrad Rzeszutek Wilk' <konrad.wilk@oracle.com>
Subject: [Xen-devel] Xen4.2-rc4 test result
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi All,
We did a round testing for RC4 (CS# 25834) in xen-4.2-testing tree with Linux 3.5.3 dom0.
We found 1 new issue (which is a Dom0 issue and has nothing to do with Xen4.2), and no fixed issue.

New bug (1):
1. XenU PV guest with vif network can't boot up with Linux3.6 dom0
  http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1832
  --A regression from Linux 3.5 to 3.6.

The following are some of the old issues which we guess are something important.
Some of the old issues:
1. Fail to probe NIC driver to HVM domU (with 3.5/3.6 Linux as Dom0)
  http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1824
  -- We already know the corrupt commit in Linux tree. Konrad will try to fix it.
2. Poor performance when do guest save/restore and migration with linux 3.x dom0
  http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1784
3. after detaching a VF from a guest, shutdown the guest is very slow (related to stdvga setting)
  http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1812
4. Dom0 cannot be shut down before PCI device detachment from a running guest
  http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1826
5. Guest hang after resuming from S3
  http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1828
6. Dom0 S3 resume fails
  http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1707

Best Regards,
     Yongjie (Jay)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 13 07:06:58 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Sep 2012 07: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 1TC3VT-0006MT-85; Thu, 13 Sep 2012 07:06:35 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1TC3VR-0006M9-Gw
	for xen-devel@lists.xen.org; Thu, 13 Sep 2012 07:06:33 +0000
Received: from [85.158.139.83:7003] by server-7.bemta-5.messagelabs.com id
	4B/59-19703-8F581505; Thu, 13 Sep 2012 07:06:32 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1347519988!26347111!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQwNjM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18985 invoked from network); 13 Sep 2012 07:06:28 -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;
	13 Sep 2012 07:06:28 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 13 Sep 2012 08:06:27 +0100
Message-Id: <5051A24A020000780009AF77@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 13 Sep 2012 08:07:22 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Wei Wang" <wei.wang2@amd.com>
References: <504F4C24020000780009A968@nat28.tlf.novell.com>
	<50508466.20309@amd.com>
In-Reply-To: <50508466.20309@amd.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 2/3] amd iommu: use base platform MSI
 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 12.09.12 at 14:47, Wei Wang <wei.wang2@amd.com> wrote:
> I found this patch triggered a xen BUG

Indeed - my default builds don't use high enough a CPU count to
see this. I'm sorry for that. Below a drop-in replacement for the
patch (it would unlikely apply cleanly to the tip of staging unstable
due to Keir's cleanup after the removal of x86-32 support.

Jan

--- 2012-09-11.orig/xen/arch/x86/msi.c	2012-09-13 08:40:47.000000000 +0200
+++ 2012-09-11/xen/arch/x86/msi.c	2012-09-13 08:43:21.000000000 +0200
@@ -13,6 +13,7 @@
 #include <xen/delay.h>
 #include <xen/sched.h>
 #include <xen/acpi.h>
+#include <xen/cpu.h>
 #include <xen/errno.h>
 #include <xen/pci.h>
 #include <xen/pci_regs.h>
@@ -32,8 +33,9 @@
 #include <xsm/xsm.h>
 
 /* bitmap indicate which fixed map is free */
-DEFINE_SPINLOCK(msix_fixmap_lock);
-DECLARE_BITMAP(msix_fixmap_pages, FIX_MSIX_MAX_PAGES);
+static DEFINE_SPINLOCK(msix_fixmap_lock);
+static DECLARE_BITMAP(msix_fixmap_pages, FIX_MSIX_MAX_PAGES);
+static DEFINE_PER_CPU(cpumask_var_t, scratch_mask);
 
 static int msix_fixmap_alloc(void)
 {
@@ -126,13 +128,17 @@ void msi_compose_msg(struct irq_desc *de
     unsigned dest;
     int vector = desc->arch.vector;
 
-    if ( cpumask_empty(desc->arch.cpu_mask) ) {
+    memset(msg, 0, sizeof(*msg));
+    if ( !cpumask_intersects(desc->arch.cpu_mask, &cpu_online_map) ) {
         dprintk(XENLOG_ERR,"%s, compose msi message error!!\n", __func__);
         return;
     }
 
     if ( vector ) {
-        dest = cpu_mask_to_apicid(desc->arch.cpu_mask);
+        cpumask_t *mask = this_cpu(scratch_mask);
+
+        cpumask_and(mask, desc->arch.cpu_mask, &cpu_online_map);
+        dest = cpu_mask_to_apicid(mask);
 
         msg->address_hi = MSI_ADDR_BASE_HI;
         msg->address_lo =
@@ -281,23 +287,27 @@ static void set_msi_affinity(struct irq_
     write_msi_msg(msi_desc, &msg);
 }
 
+void __msi_set_enable(u16 seg, u8 bus, u8 slot, u8 func, int pos, int enable)
+{
+    u16 control = pci_conf_read16(seg, bus, slot, func, pos + PCI_MSI_FLAGS);
+
+    control &= ~PCI_MSI_FLAGS_ENABLE;
+    if ( enable )
+        control |= PCI_MSI_FLAGS_ENABLE;
+    pci_conf_write16(seg, bus, slot, func, pos + PCI_MSI_FLAGS, control);
+}
+
 static void msi_set_enable(struct pci_dev *dev, int enable)
 {
     int pos;
-    u16 control, seg = dev->seg;
+    u16 seg = dev->seg;
     u8 bus = dev->bus;
     u8 slot = PCI_SLOT(dev->devfn);
     u8 func = PCI_FUNC(dev->devfn);
 
     pos = pci_find_cap_offset(seg, bus, slot, func, PCI_CAP_ID_MSI);
     if ( pos )
-    {
-        control = pci_conf_read16(seg, bus, slot, func, pos + PCI_MSI_FLAGS);
-        control &= ~PCI_MSI_FLAGS_ENABLE;
-        if ( enable )
-            control |= PCI_MSI_FLAGS_ENABLE;
-        pci_conf_write16(seg, bus, slot, func, pos + PCI_MSI_FLAGS, control);
-    }
+        __msi_set_enable(seg, bus, slot, func, pos, enable);
 }
 
 static void msix_set_enable(struct pci_dev *dev, int enable)
@@ -379,12 +389,12 @@ static int msi_get_mask_bit(const struct
     return -1;
 }
 
-static void mask_msi_irq(struct irq_desc *desc)
+void mask_msi_irq(struct irq_desc *desc)
 {
     msi_set_mask_bit(desc, 1);
 }
 
-static void unmask_msi_irq(struct irq_desc *desc)
+void unmask_msi_irq(struct irq_desc *desc)
 {
     msi_set_mask_bit(desc, 0);
 }
@@ -395,7 +405,7 @@ static unsigned int startup_msi_irq(stru
     return 0;
 }
 
-static void ack_nonmaskable_msi_irq(struct irq_desc *desc)
+void ack_nonmaskable_msi_irq(struct irq_desc *desc)
 {
     irq_complete_move(desc);
     move_native_irq(desc);
@@ -407,7 +417,7 @@ static void ack_maskable_msi_irq(struct 
     ack_APIC_irq(); /* ACKTYPE_NONE */
 }
 
-static void end_nonmaskable_msi_irq(struct irq_desc *desc, u8 vector)
+void end_nonmaskable_msi_irq(struct irq_desc *desc, u8 vector)
 {
     ack_APIC_irq(); /* ACKTYPE_EOI */
 }
@@ -1071,6 +1081,39 @@ unsigned int pci_msix_get_table_len(stru
     return len;
 }
 
+static int msi_cpu_callback(
+    struct notifier_block *nfb, unsigned long action, void *hcpu)
+{
+    unsigned int cpu = (unsigned long)hcpu;
+    int rc = 0;
+
+    switch ( action )
+    {
+    case CPU_UP_PREPARE:
+        if ( !alloc_cpumask_var(&per_cpu(scratch_mask, cpu)) )
+            rc = -ENOMEM;
+        break;
+    case CPU_UP_CANCELED:
+    case CPU_DEAD:
+        free_cpumask_var(per_cpu(scratch_mask, cpu));
+        break;
+    default:
+        break;
+    }
+
+    return notifier_from_errno(rc);
+}
+
+static struct notifier_block msi_cpu_nfb = {
+    .notifier_call = msi_cpu_callback
+};
+
+void __init early_msi_init(void)
+{
+    register_cpu_notifier(&msi_cpu_nfb);
+    msi_cpu_callback(&msi_cpu_nfb, CPU_UP_PREPARE, NULL);
+}
+
 static void dump_msi(unsigned char key)
 {
     unsigned int irq;
--- 2012-09-11.orig/xen/arch/x86/setup.c	2012-09-03 08:25:31.000000000 +0200
+++ 2012-09-11/xen/arch/x86/setup.c	2012-09-13 08:44:49.000000000 +0200
@@ -35,6 +35,7 @@
 #include <asm/processor.h>
 #include <asm/mpspec.h>
 #include <asm/apic.h>
+#include <asm/msi.h>
 #include <asm/desc.h>
 #include <asm/paging.h>
 #include <asm/e820.h>
@@ -1274,6 +1275,8 @@ void __init __start_xen(unsigned long mb
     acpi_mmcfg_init();
 #endif
 
+    early_msi_init();
+
     iommu_setup();    /* setup iommu if available */
 
     smp_prepare_cpus(max_cpus);
--- 2012-09-11.orig/xen/drivers/passthrough/amd/iommu_detect.c	2012-09-13 08:40:47.000000000 +0200
+++ 2012-09-11/xen/drivers/passthrough/amd/iommu_detect.c	2012-06-20 17:33:15.000000000 +0200
@@ -31,7 +31,6 @@ static int __init get_iommu_msi_capabili
     u16 seg, u8 bus, u8 dev, u8 func, struct amd_iommu *iommu)
 {
     int pos;
-    u16 control;
 
     pos = pci_find_cap_offset(seg, bus, dev, func, PCI_CAP_ID_MSI);
 
@@ -41,9 +40,6 @@ static int __init get_iommu_msi_capabili
     AMD_IOMMU_DEBUG("Found MSI capability block at %#x\n", pos);
 
     iommu->msi_cap = pos;
-    control = pci_conf_read16(seg, bus, dev, func,
-                              iommu->msi_cap + PCI_MSI_FLAGS);
-    iommu->maskbit = control & PCI_MSI_FLAGS_MASKBIT;
     return 0;
 }
 
--- 2012-09-11.orig/xen/drivers/passthrough/amd/iommu_init.c	2012-06-13 08:39:38.000000000 +0200
+++ 2012-09-11/xen/drivers/passthrough/amd/iommu_init.c	2012-09-11 11:26:28.000000000 +0200
@@ -467,20 +467,9 @@ static void iommu_msi_set_affinity(struc
         return;
     }
 
-    memset(&msg, 0, sizeof(msg)); 
-    msg.data = MSI_DATA_VECTOR(desc->arch.vector) & 0xff;
-    msg.data |= 1 << 14;
-    msg.data |= (INT_DELIVERY_MODE != dest_LowestPrio) ?
-        MSI_DATA_DELIVERY_FIXED:
-        MSI_DATA_DELIVERY_LOWPRI;
-
-    msg.address_hi =0;
-    msg.address_lo = (MSI_ADDRESS_HEADER << (MSI_ADDRESS_HEADER_SHIFT + 8)); 
-    msg.address_lo |= INT_DEST_MODE ? MSI_ADDR_DESTMODE_LOGIC:
-                    MSI_ADDR_DESTMODE_PHYS;
-    msg.address_lo |= (INT_DELIVERY_MODE != dest_LowestPrio) ?
-                    MSI_ADDR_REDIRECTION_CPU:
-                    MSI_ADDR_REDIRECTION_LOWPRI;
+    msi_compose_msg(desc, &msg);
+    /* Is this override really needed? */
+    msg.address_lo &= ~MSI_ADDR_DEST_ID_MASK;
     msg.address_lo |= MSI_ADDR_DEST_ID(dest & 0xff);
 
     pci_conf_write32(seg, bus, dev, func,
@@ -494,18 +483,8 @@ static void iommu_msi_set_affinity(struc
 
 static void amd_iommu_msi_enable(struct amd_iommu *iommu, int flag)
 {
-    u16 control;
-    int bus = PCI_BUS(iommu->bdf);
-    int dev = PCI_SLOT(iommu->bdf);
-    int func = PCI_FUNC(iommu->bdf);
-
-    control = pci_conf_read16(iommu->seg, bus, dev, func,
-        iommu->msi_cap + PCI_MSI_FLAGS);
-    control &= ~PCI_MSI_FLAGS_ENABLE;
-    if ( flag )
-        control |= flag;
-    pci_conf_write16(iommu->seg, bus, dev, func,
-        iommu->msi_cap + PCI_MSI_FLAGS, control);
+    __msi_set_enable(iommu->seg, PCI_BUS(iommu->bdf), PCI_SLOT(iommu->bdf),
+                     PCI_FUNC(iommu->bdf), iommu->msi_cap, flag);
 }
 
 static void iommu_msi_unmask(struct irq_desc *desc)
@@ -513,10 +492,6 @@ static void iommu_msi_unmask(struct irq_
     unsigned long flags;
     struct amd_iommu *iommu = desc->action->dev_id;
 
-    /* FIXME: do not support mask bits at the moment */
-    if ( iommu->maskbit )
-        return;
-
     spin_lock_irqsave(&iommu->lock, flags);
     amd_iommu_msi_enable(iommu, IOMMU_CONTROL_ENABLED);
     spin_unlock_irqrestore(&iommu->lock, flags);
@@ -529,10 +504,6 @@ static void iommu_msi_mask(struct irq_de
 
     irq_complete_move(desc);
 
-    /* FIXME: do not support mask bits at the moment */
-    if ( iommu->maskbit )
-        return;
-
     spin_lock_irqsave(&iommu->lock, flags);
     amd_iommu_msi_enable(iommu, IOMMU_CONTROL_DISABLED);
     spin_unlock_irqrestore(&iommu->lock, flags);
@@ -562,6 +533,37 @@ static hw_irq_controller iommu_msi_type 
     .set_affinity = iommu_msi_set_affinity,
 };
 
+static unsigned int iommu_maskable_msi_startup(struct irq_desc *desc)
+{
+    iommu_msi_unmask(desc);
+    unmask_msi_irq(desc);
+    return 0;
+}
+
+static void iommu_maskable_msi_shutdown(struct irq_desc *desc)
+{
+    mask_msi_irq(desc);
+    iommu_msi_mask(desc);
+}
+
+/*
+ * While the names may appear mismatched, we indeed want to use the non-
+ * maskable flavors here, as we want the ACK to be issued in ->end().
+ */
+#define iommu_maskable_msi_ack ack_nonmaskable_msi_irq
+#define iommu_maskable_msi_end end_nonmaskable_msi_irq
+
+static hw_irq_controller iommu_maskable_msi_type = {
+    .typename = "IOMMU-M-MSI",
+    .startup = iommu_maskable_msi_startup,
+    .shutdown = iommu_maskable_msi_shutdown,
+    .enable = unmask_msi_irq,
+    .disable = mask_msi_irq,
+    .ack = iommu_maskable_msi_ack,
+    .end = iommu_maskable_msi_end,
+    .set_affinity = iommu_msi_set_affinity,
+};
+
 static void parse_event_log_entry(struct amd_iommu *iommu, u32 entry[])
 {
     u16 domain_id, device_id, bdf, cword, flags;
@@ -784,6 +786,7 @@ static void iommu_interrupt_handler(int 
 static int __init set_iommu_interrupt_handler(struct amd_iommu *iommu)
 {
     int irq, ret;
+    u16 control;
 
     irq = create_irq(NUMA_NO_NODE);
     if ( irq <= 0 )
@@ -792,7 +795,11 @@ static int __init set_iommu_interrupt_ha
         return 0;
     }
     
-    irq_desc[irq].handler = &iommu_msi_type;
+    control = pci_conf_read16(iommu->seg, PCI_BUS(iommu->bdf),
+                              PCI_SLOT(iommu->bdf), PCI_FUNC(iommu->bdf),
+                              iommu->msi_cap + PCI_MSI_FLAGS);
+    irq_desc[irq].handler = control & PCI_MSI_FLAGS_MASKBIT ?
+                            &iommu_maskable_msi_type : &iommu_msi_type;
     ret = request_irq(irq, iommu_interrupt_handler, 0, "amd_iommu", iommu);
     if ( ret )
     {
--- 2012-09-11.orig/xen/include/asm-x86/amd-iommu.h	2012-09-13 08:40:47.000000000 +0200
+++ 2012-09-11/xen/include/asm-x86/amd-iommu.h	2012-06-13 10:23:45.000000000 +0200
@@ -83,6 +83,7 @@ struct amd_iommu {
     u16 seg;
     u16 bdf;
     u16 cap_offset;
+    u8 msi_cap;
     iommu_cap_t cap;
 
     u8 ht_flags;
@@ -101,9 +102,6 @@ struct amd_iommu {
     uint64_t exclusion_base;
     uint64_t exclusion_limit;
 
-    int msi_cap;
-    int maskbit;
-
     int enabled;
     int irq;
 };
--- 2012-09-11.orig/xen/include/asm-x86/msi.h	2012-09-13 08:40:47.000000000 +0200
+++ 2012-09-11/xen/include/asm-x86/msi.h	2012-09-13 08:45:14.000000000 +0200
@@ -153,18 +153,6 @@ int msi_free_irq(struct msi_desc *entry)
 /*
  * MSI Defined Data Structures
  */
-#define MSI_ADDRESS_HEADER		0xfee
-#define MSI_ADDRESS_HEADER_SHIFT	12
-#define MSI_ADDRESS_HEADER_MASK		0xfff000
-#define MSI_ADDRESS_DEST_ID_MASK	0xfff0000f
-#define MSI_TARGET_CPU_MASK		0xff
-#define MSI_TARGET_CPU_SHIFT		12
-#define MSI_DELIVERY_MODE		0
-#define MSI_LEVEL_MODE			1	/* Edge always assert */
-#define MSI_TRIGGER_MODE		0	/* MSI is edge sensitive */
-#define MSI_PHYSICAL_MODE		0
-#define MSI_LOGICAL_MODE		1
-#define MSI_REDIRECTION_HINT_MODE	0
 
 struct msg_data {
 #if defined(__LITTLE_ENDIAN_BITFIELD)
@@ -212,6 +200,12 @@ struct msg_address {
 	__u32 	hi_address;
 } __attribute__ ((packed));
 
+void early_msi_init(void);
 void msi_compose_msg(struct irq_desc *, struct msi_msg *);
+void __msi_set_enable(u16 seg, u8 bus, u8 slot, u8 func, int pos, int enable);
+void mask_msi_irq(struct irq_desc *);
+void unmask_msi_irq(struct irq_desc *);
+void ack_nonmaskable_msi_irq(struct irq_desc *);
+void end_nonmaskable_msi_irq(struct irq_desc *, u8 vector);
 
 #endif /* __ASM_MSI_H */


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 13 07:06:58 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Sep 2012 07: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 1TC3VT-0006MT-85; Thu, 13 Sep 2012 07:06:35 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1TC3VR-0006M9-Gw
	for xen-devel@lists.xen.org; Thu, 13 Sep 2012 07:06:33 +0000
Received: from [85.158.139.83:7003] by server-7.bemta-5.messagelabs.com id
	4B/59-19703-8F581505; Thu, 13 Sep 2012 07:06:32 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1347519988!26347111!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQwNjM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18985 invoked from network); 13 Sep 2012 07:06:28 -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;
	13 Sep 2012 07:06:28 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 13 Sep 2012 08:06:27 +0100
Message-Id: <5051A24A020000780009AF77@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 13 Sep 2012 08:07:22 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Wei Wang" <wei.wang2@amd.com>
References: <504F4C24020000780009A968@nat28.tlf.novell.com>
	<50508466.20309@amd.com>
In-Reply-To: <50508466.20309@amd.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 2/3] amd iommu: use base platform MSI
 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 12.09.12 at 14:47, Wei Wang <wei.wang2@amd.com> wrote:
> I found this patch triggered a xen BUG

Indeed - my default builds don't use high enough a CPU count to
see this. I'm sorry for that. Below a drop-in replacement for the
patch (it would unlikely apply cleanly to the tip of staging unstable
due to Keir's cleanup after the removal of x86-32 support.

Jan

--- 2012-09-11.orig/xen/arch/x86/msi.c	2012-09-13 08:40:47.000000000 +0200
+++ 2012-09-11/xen/arch/x86/msi.c	2012-09-13 08:43:21.000000000 +0200
@@ -13,6 +13,7 @@
 #include <xen/delay.h>
 #include <xen/sched.h>
 #include <xen/acpi.h>
+#include <xen/cpu.h>
 #include <xen/errno.h>
 #include <xen/pci.h>
 #include <xen/pci_regs.h>
@@ -32,8 +33,9 @@
 #include <xsm/xsm.h>
 
 /* bitmap indicate which fixed map is free */
-DEFINE_SPINLOCK(msix_fixmap_lock);
-DECLARE_BITMAP(msix_fixmap_pages, FIX_MSIX_MAX_PAGES);
+static DEFINE_SPINLOCK(msix_fixmap_lock);
+static DECLARE_BITMAP(msix_fixmap_pages, FIX_MSIX_MAX_PAGES);
+static DEFINE_PER_CPU(cpumask_var_t, scratch_mask);
 
 static int msix_fixmap_alloc(void)
 {
@@ -126,13 +128,17 @@ void msi_compose_msg(struct irq_desc *de
     unsigned dest;
     int vector = desc->arch.vector;
 
-    if ( cpumask_empty(desc->arch.cpu_mask) ) {
+    memset(msg, 0, sizeof(*msg));
+    if ( !cpumask_intersects(desc->arch.cpu_mask, &cpu_online_map) ) {
         dprintk(XENLOG_ERR,"%s, compose msi message error!!\n", __func__);
         return;
     }
 
     if ( vector ) {
-        dest = cpu_mask_to_apicid(desc->arch.cpu_mask);
+        cpumask_t *mask = this_cpu(scratch_mask);
+
+        cpumask_and(mask, desc->arch.cpu_mask, &cpu_online_map);
+        dest = cpu_mask_to_apicid(mask);
 
         msg->address_hi = MSI_ADDR_BASE_HI;
         msg->address_lo =
@@ -281,23 +287,27 @@ static void set_msi_affinity(struct irq_
     write_msi_msg(msi_desc, &msg);
 }
 
+void __msi_set_enable(u16 seg, u8 bus, u8 slot, u8 func, int pos, int enable)
+{
+    u16 control = pci_conf_read16(seg, bus, slot, func, pos + PCI_MSI_FLAGS);
+
+    control &= ~PCI_MSI_FLAGS_ENABLE;
+    if ( enable )
+        control |= PCI_MSI_FLAGS_ENABLE;
+    pci_conf_write16(seg, bus, slot, func, pos + PCI_MSI_FLAGS, control);
+}
+
 static void msi_set_enable(struct pci_dev *dev, int enable)
 {
     int pos;
-    u16 control, seg = dev->seg;
+    u16 seg = dev->seg;
     u8 bus = dev->bus;
     u8 slot = PCI_SLOT(dev->devfn);
     u8 func = PCI_FUNC(dev->devfn);
 
     pos = pci_find_cap_offset(seg, bus, slot, func, PCI_CAP_ID_MSI);
     if ( pos )
-    {
-        control = pci_conf_read16(seg, bus, slot, func, pos + PCI_MSI_FLAGS);
-        control &= ~PCI_MSI_FLAGS_ENABLE;
-        if ( enable )
-            control |= PCI_MSI_FLAGS_ENABLE;
-        pci_conf_write16(seg, bus, slot, func, pos + PCI_MSI_FLAGS, control);
-    }
+        __msi_set_enable(seg, bus, slot, func, pos, enable);
 }
 
 static void msix_set_enable(struct pci_dev *dev, int enable)
@@ -379,12 +389,12 @@ static int msi_get_mask_bit(const struct
     return -1;
 }
 
-static void mask_msi_irq(struct irq_desc *desc)
+void mask_msi_irq(struct irq_desc *desc)
 {
     msi_set_mask_bit(desc, 1);
 }
 
-static void unmask_msi_irq(struct irq_desc *desc)
+void unmask_msi_irq(struct irq_desc *desc)
 {
     msi_set_mask_bit(desc, 0);
 }
@@ -395,7 +405,7 @@ static unsigned int startup_msi_irq(stru
     return 0;
 }
 
-static void ack_nonmaskable_msi_irq(struct irq_desc *desc)
+void ack_nonmaskable_msi_irq(struct irq_desc *desc)
 {
     irq_complete_move(desc);
     move_native_irq(desc);
@@ -407,7 +417,7 @@ static void ack_maskable_msi_irq(struct 
     ack_APIC_irq(); /* ACKTYPE_NONE */
 }
 
-static void end_nonmaskable_msi_irq(struct irq_desc *desc, u8 vector)
+void end_nonmaskable_msi_irq(struct irq_desc *desc, u8 vector)
 {
     ack_APIC_irq(); /* ACKTYPE_EOI */
 }
@@ -1071,6 +1081,39 @@ unsigned int pci_msix_get_table_len(stru
     return len;
 }
 
+static int msi_cpu_callback(
+    struct notifier_block *nfb, unsigned long action, void *hcpu)
+{
+    unsigned int cpu = (unsigned long)hcpu;
+    int rc = 0;
+
+    switch ( action )
+    {
+    case CPU_UP_PREPARE:
+        if ( !alloc_cpumask_var(&per_cpu(scratch_mask, cpu)) )
+            rc = -ENOMEM;
+        break;
+    case CPU_UP_CANCELED:
+    case CPU_DEAD:
+        free_cpumask_var(per_cpu(scratch_mask, cpu));
+        break;
+    default:
+        break;
+    }
+
+    return notifier_from_errno(rc);
+}
+
+static struct notifier_block msi_cpu_nfb = {
+    .notifier_call = msi_cpu_callback
+};
+
+void __init early_msi_init(void)
+{
+    register_cpu_notifier(&msi_cpu_nfb);
+    msi_cpu_callback(&msi_cpu_nfb, CPU_UP_PREPARE, NULL);
+}
+
 static void dump_msi(unsigned char key)
 {
     unsigned int irq;
--- 2012-09-11.orig/xen/arch/x86/setup.c	2012-09-03 08:25:31.000000000 +0200
+++ 2012-09-11/xen/arch/x86/setup.c	2012-09-13 08:44:49.000000000 +0200
@@ -35,6 +35,7 @@
 #include <asm/processor.h>
 #include <asm/mpspec.h>
 #include <asm/apic.h>
+#include <asm/msi.h>
 #include <asm/desc.h>
 #include <asm/paging.h>
 #include <asm/e820.h>
@@ -1274,6 +1275,8 @@ void __init __start_xen(unsigned long mb
     acpi_mmcfg_init();
 #endif
 
+    early_msi_init();
+
     iommu_setup();    /* setup iommu if available */
 
     smp_prepare_cpus(max_cpus);
--- 2012-09-11.orig/xen/drivers/passthrough/amd/iommu_detect.c	2012-09-13 08:40:47.000000000 +0200
+++ 2012-09-11/xen/drivers/passthrough/amd/iommu_detect.c	2012-06-20 17:33:15.000000000 +0200
@@ -31,7 +31,6 @@ static int __init get_iommu_msi_capabili
     u16 seg, u8 bus, u8 dev, u8 func, struct amd_iommu *iommu)
 {
     int pos;
-    u16 control;
 
     pos = pci_find_cap_offset(seg, bus, dev, func, PCI_CAP_ID_MSI);
 
@@ -41,9 +40,6 @@ static int __init get_iommu_msi_capabili
     AMD_IOMMU_DEBUG("Found MSI capability block at %#x\n", pos);
 
     iommu->msi_cap = pos;
-    control = pci_conf_read16(seg, bus, dev, func,
-                              iommu->msi_cap + PCI_MSI_FLAGS);
-    iommu->maskbit = control & PCI_MSI_FLAGS_MASKBIT;
     return 0;
 }
 
--- 2012-09-11.orig/xen/drivers/passthrough/amd/iommu_init.c	2012-06-13 08:39:38.000000000 +0200
+++ 2012-09-11/xen/drivers/passthrough/amd/iommu_init.c	2012-09-11 11:26:28.000000000 +0200
@@ -467,20 +467,9 @@ static void iommu_msi_set_affinity(struc
         return;
     }
 
-    memset(&msg, 0, sizeof(msg)); 
-    msg.data = MSI_DATA_VECTOR(desc->arch.vector) & 0xff;
-    msg.data |= 1 << 14;
-    msg.data |= (INT_DELIVERY_MODE != dest_LowestPrio) ?
-        MSI_DATA_DELIVERY_FIXED:
-        MSI_DATA_DELIVERY_LOWPRI;
-
-    msg.address_hi =0;
-    msg.address_lo = (MSI_ADDRESS_HEADER << (MSI_ADDRESS_HEADER_SHIFT + 8)); 
-    msg.address_lo |= INT_DEST_MODE ? MSI_ADDR_DESTMODE_LOGIC:
-                    MSI_ADDR_DESTMODE_PHYS;
-    msg.address_lo |= (INT_DELIVERY_MODE != dest_LowestPrio) ?
-                    MSI_ADDR_REDIRECTION_CPU:
-                    MSI_ADDR_REDIRECTION_LOWPRI;
+    msi_compose_msg(desc, &msg);
+    /* Is this override really needed? */
+    msg.address_lo &= ~MSI_ADDR_DEST_ID_MASK;
     msg.address_lo |= MSI_ADDR_DEST_ID(dest & 0xff);
 
     pci_conf_write32(seg, bus, dev, func,
@@ -494,18 +483,8 @@ static void iommu_msi_set_affinity(struc
 
 static void amd_iommu_msi_enable(struct amd_iommu *iommu, int flag)
 {
-    u16 control;
-    int bus = PCI_BUS(iommu->bdf);
-    int dev = PCI_SLOT(iommu->bdf);
-    int func = PCI_FUNC(iommu->bdf);
-
-    control = pci_conf_read16(iommu->seg, bus, dev, func,
-        iommu->msi_cap + PCI_MSI_FLAGS);
-    control &= ~PCI_MSI_FLAGS_ENABLE;
-    if ( flag )
-        control |= flag;
-    pci_conf_write16(iommu->seg, bus, dev, func,
-        iommu->msi_cap + PCI_MSI_FLAGS, control);
+    __msi_set_enable(iommu->seg, PCI_BUS(iommu->bdf), PCI_SLOT(iommu->bdf),
+                     PCI_FUNC(iommu->bdf), iommu->msi_cap, flag);
 }
 
 static void iommu_msi_unmask(struct irq_desc *desc)
@@ -513,10 +492,6 @@ static void iommu_msi_unmask(struct irq_
     unsigned long flags;
     struct amd_iommu *iommu = desc->action->dev_id;
 
-    /* FIXME: do not support mask bits at the moment */
-    if ( iommu->maskbit )
-        return;
-
     spin_lock_irqsave(&iommu->lock, flags);
     amd_iommu_msi_enable(iommu, IOMMU_CONTROL_ENABLED);
     spin_unlock_irqrestore(&iommu->lock, flags);
@@ -529,10 +504,6 @@ static void iommu_msi_mask(struct irq_de
 
     irq_complete_move(desc);
 
-    /* FIXME: do not support mask bits at the moment */
-    if ( iommu->maskbit )
-        return;
-
     spin_lock_irqsave(&iommu->lock, flags);
     amd_iommu_msi_enable(iommu, IOMMU_CONTROL_DISABLED);
     spin_unlock_irqrestore(&iommu->lock, flags);
@@ -562,6 +533,37 @@ static hw_irq_controller iommu_msi_type 
     .set_affinity = iommu_msi_set_affinity,
 };
 
+static unsigned int iommu_maskable_msi_startup(struct irq_desc *desc)
+{
+    iommu_msi_unmask(desc);
+    unmask_msi_irq(desc);
+    return 0;
+}
+
+static void iommu_maskable_msi_shutdown(struct irq_desc *desc)
+{
+    mask_msi_irq(desc);
+    iommu_msi_mask(desc);
+}
+
+/*
+ * While the names may appear mismatched, we indeed want to use the non-
+ * maskable flavors here, as we want the ACK to be issued in ->end().
+ */
+#define iommu_maskable_msi_ack ack_nonmaskable_msi_irq
+#define iommu_maskable_msi_end end_nonmaskable_msi_irq
+
+static hw_irq_controller iommu_maskable_msi_type = {
+    .typename = "IOMMU-M-MSI",
+    .startup = iommu_maskable_msi_startup,
+    .shutdown = iommu_maskable_msi_shutdown,
+    .enable = unmask_msi_irq,
+    .disable = mask_msi_irq,
+    .ack = iommu_maskable_msi_ack,
+    .end = iommu_maskable_msi_end,
+    .set_affinity = iommu_msi_set_affinity,
+};
+
 static void parse_event_log_entry(struct amd_iommu *iommu, u32 entry[])
 {
     u16 domain_id, device_id, bdf, cword, flags;
@@ -784,6 +786,7 @@ static void iommu_interrupt_handler(int 
 static int __init set_iommu_interrupt_handler(struct amd_iommu *iommu)
 {
     int irq, ret;
+    u16 control;
 
     irq = create_irq(NUMA_NO_NODE);
     if ( irq <= 0 )
@@ -792,7 +795,11 @@ static int __init set_iommu_interrupt_ha
         return 0;
     }
     
-    irq_desc[irq].handler = &iommu_msi_type;
+    control = pci_conf_read16(iommu->seg, PCI_BUS(iommu->bdf),
+                              PCI_SLOT(iommu->bdf), PCI_FUNC(iommu->bdf),
+                              iommu->msi_cap + PCI_MSI_FLAGS);
+    irq_desc[irq].handler = control & PCI_MSI_FLAGS_MASKBIT ?
+                            &iommu_maskable_msi_type : &iommu_msi_type;
     ret = request_irq(irq, iommu_interrupt_handler, 0, "amd_iommu", iommu);
     if ( ret )
     {
--- 2012-09-11.orig/xen/include/asm-x86/amd-iommu.h	2012-09-13 08:40:47.000000000 +0200
+++ 2012-09-11/xen/include/asm-x86/amd-iommu.h	2012-06-13 10:23:45.000000000 +0200
@@ -83,6 +83,7 @@ struct amd_iommu {
     u16 seg;
     u16 bdf;
     u16 cap_offset;
+    u8 msi_cap;
     iommu_cap_t cap;
 
     u8 ht_flags;
@@ -101,9 +102,6 @@ struct amd_iommu {
     uint64_t exclusion_base;
     uint64_t exclusion_limit;
 
-    int msi_cap;
-    int maskbit;
-
     int enabled;
     int irq;
 };
--- 2012-09-11.orig/xen/include/asm-x86/msi.h	2012-09-13 08:40:47.000000000 +0200
+++ 2012-09-11/xen/include/asm-x86/msi.h	2012-09-13 08:45:14.000000000 +0200
@@ -153,18 +153,6 @@ int msi_free_irq(struct msi_desc *entry)
 /*
  * MSI Defined Data Structures
  */
-#define MSI_ADDRESS_HEADER		0xfee
-#define MSI_ADDRESS_HEADER_SHIFT	12
-#define MSI_ADDRESS_HEADER_MASK		0xfff000
-#define MSI_ADDRESS_DEST_ID_MASK	0xfff0000f
-#define MSI_TARGET_CPU_MASK		0xff
-#define MSI_TARGET_CPU_SHIFT		12
-#define MSI_DELIVERY_MODE		0
-#define MSI_LEVEL_MODE			1	/* Edge always assert */
-#define MSI_TRIGGER_MODE		0	/* MSI is edge sensitive */
-#define MSI_PHYSICAL_MODE		0
-#define MSI_LOGICAL_MODE		1
-#define MSI_REDIRECTION_HINT_MODE	0
 
 struct msg_data {
 #if defined(__LITTLE_ENDIAN_BITFIELD)
@@ -212,6 +200,12 @@ struct msg_address {
 	__u32 	hi_address;
 } __attribute__ ((packed));
 
+void early_msi_init(void);
 void msi_compose_msg(struct irq_desc *, struct msi_msg *);
+void __msi_set_enable(u16 seg, u8 bus, u8 slot, u8 func, int pos, int enable);
+void mask_msi_irq(struct irq_desc *);
+void unmask_msi_irq(struct irq_desc *);
+void ack_nonmaskable_msi_irq(struct irq_desc *);
+void end_nonmaskable_msi_irq(struct irq_desc *, u8 vector);
 
 #endif /* __ASM_MSI_H */


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 13 07:16:18 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Sep 2012 07:16:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TC3eW-0006aF-9z; Thu, 13 Sep 2012 07:15:56 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <aware.why@gmail.com>) id 1TC3eU-0006aA-S1
	for xen-devel@lists.xensource.com; Thu, 13 Sep 2012 07:15:55 +0000
Received: from [85.158.143.35:38136] by server-2.bemta-4.messagelabs.com id
	0A/CC-21239-A2881505; Thu, 13 Sep 2012 07:15:54 +0000
X-Env-Sender: aware.why@gmail.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1347520552!11266711!1
X-Originating-IP: [74.125.83.43]
X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,UPPERCASE_25_50,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1122 invoked from network); 13 Sep 2012 07:15:52 -0000
Received: from mail-ee0-f43.google.com (HELO mail-ee0-f43.google.com)
	(74.125.83.43)
	by server-11.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Sep 2012 07:15:52 -0000
Received: by eekd4 with SMTP id d4so1803796eek.30
	for <xen-devel@lists.xensource.com>;
	Thu, 13 Sep 2012 00:15:52 -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=nc2OCz5bwwq43DvNAM+bHDzLG0U2upi3nUsX9/Nv0cE=;
	b=xczjUjTM2j22BZVxsGyBTRIep76wy9HSJBw77FfeU8mmsGTj5Vl41bwfPZ8Nv1IOaz
	1OMK1N7Y1PVerTOHta+Hnj/5Yt7ucJ9rRCmhIwvQr3II08lC0Z4A4tdFIRbEoKvWBcZW
	K5c5KX1eCZc5aL+WRkq1RdQEH+GNVm4HuDbEI4aqyYT02F7B1nr5QbpmuLAe/Sibvmii
	cy2o2Ah8v4POhqYzSJaKcX+iLPTczIz6iNhaSocB+QIMgmTCdriG435cbkqP/6r5yNiX
	/W3qheG8oz4T8PqLpLWJrMy0u8lqqUKXzfqAEVoXrF/h8sjgZ3zsWC41LC9QdM8betIk
	jQUw==
MIME-Version: 1.0
Received: by 10.14.209.129 with SMTP id s1mr1264826eeo.24.1347520552042; Thu,
	13 Sep 2012 00:15:52 -0700 (PDT)
Received: by 10.14.100.71 with HTTP; Thu, 13 Sep 2012 00:15:51 -0700 (PDT)
Date: Thu, 13 Sep 2012 15:15:51 +0800
Message-ID: <CA+ePHTBU50_t=29G8Ph9KiSRCuKsOn4kL5U==QV8M8SJy4JB_A@mail.gmail.com>
From: =?UTF-8?B?6ams56OK?= <aware.why@gmail.com>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] =?utf-8?q?=E3=80=90problem=E3=80=91what_does_these_ma?=
	=?utf-8?q?cro_used_by_xc=5Fdomain=5Fsave_mean_IN_xen-4=2E1=2E2=3F?=
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============4895920368504980413=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============4895920368504980413==
Content-Type: multipart/alternative; boundary=047d7b603a78d4fec504c990133f

--047d7b603a78d4fec504c990133f
Content-Type: text/plain; charset=ISO-8859-1

Hi all,

    The macros list here,  and what does each mean? Waht's the principle
for saving a dom state and the algorithm for memory dump?

129#define XEN_DOMCTL_getpageframeinfo   7
130
131#define XEN_DOMCTL_PFINFO_LTAB_SHIFT 28
132#define XEN_DOMCTL_PFINFO_NOTAB   (0x0U<<28)
133#define XEN_DOMCTL_PFINFO_L1TAB   (0x1U<<28)
134#define XEN_DOMCTL_PFINFO_L2TAB   (0x2U<<28)
135#define XEN_DOMCTL_PFINFO_L3TAB   (0x3U<<28)
136#define XEN_DOMCTL_PFINFO_L4TAB   (0x4U<<28)
137#define XEN_DOMCTL_PFINFO_LTABTYPE_MASK (0x7U<<28)
138#define XEN_DOMCTL_PFINFO_LPINTAB (0x1U<<31)
139#define XEN_DOMCTL_PFINFO_XTAB    (0xfU<<28) /* invalid page */
140#define XEN_DOMCTL_PFINFO_LTAB_MASK (0xfU<<28)


Thanks

--047d7b603a78d4fec504c990133f
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div><br></div><div>Hi all,</div><div><br></div><div>=A0 =A0 The macros lis=
t here, =A0and what does each mean? Waht&#39;s the principle for saving a d=
om state and the algorithm for <font color=3D"#ff0000">memory dump</font>?<=
/div>
<div><br></div><div>129#define XEN_DOMCTL_getpageframeinfo =A0 7</div><div>=
130</div><div>131#define XEN_DOMCTL_PFINFO_LTAB_SHIFT 28</div><div>132#defi=
ne XEN_DOMCTL_PFINFO_NOTAB =A0 (0x0U&lt;&lt;28)</div>
<div>133#define XEN_DOMCTL_PFINFO_L1TAB =A0 (0x1U&lt;&lt;28)</div><div>134#=
define XEN_DOMCTL_PFINFO_L2TAB =A0 (0x2U&lt;&lt;28)</div><div>135#define XE=
N_DOMCTL_PFINFO_L3TAB =A0 (0x3U&lt;&lt;28)</div><div>136#define XEN_DOMCTL_=
PFINFO_L4TAB =A0 (0x4U&lt;&lt;28)</div>

<div>137#define XEN_DOMCTL_PFINFO_LTABTYPE_MASK (0x7U&lt;&lt;28)</div><div>=
138#define XEN_DOMCTL_PFINFO_LPINTAB (0x1U&lt;&lt;31)</div><div>139#define =
XEN_DOMCTL_PFINFO_XTAB =A0 =A0(0xfU&lt;&lt;28) /* invalid page */</div><div=
>

140#define XEN_DOMCTL_PFINFO_LTAB_MASK (0xfU&lt;&lt;28) =A0=A0</div><div><b=
r></div><div><br></div><div>Thanks</div>

--047d7b603a78d4fec504c990133f--


--===============4895920368504980413==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============4895920368504980413==--


From xen-devel-bounces@lists.xen.org Thu Sep 13 07:16:18 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Sep 2012 07:16:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TC3eW-0006aF-9z; Thu, 13 Sep 2012 07:15:56 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <aware.why@gmail.com>) id 1TC3eU-0006aA-S1
	for xen-devel@lists.xensource.com; Thu, 13 Sep 2012 07:15:55 +0000
Received: from [85.158.143.35:38136] by server-2.bemta-4.messagelabs.com id
	0A/CC-21239-A2881505; Thu, 13 Sep 2012 07:15:54 +0000
X-Env-Sender: aware.why@gmail.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1347520552!11266711!1
X-Originating-IP: [74.125.83.43]
X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,UPPERCASE_25_50,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1122 invoked from network); 13 Sep 2012 07:15:52 -0000
Received: from mail-ee0-f43.google.com (HELO mail-ee0-f43.google.com)
	(74.125.83.43)
	by server-11.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Sep 2012 07:15:52 -0000
Received: by eekd4 with SMTP id d4so1803796eek.30
	for <xen-devel@lists.xensource.com>;
	Thu, 13 Sep 2012 00:15:52 -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=nc2OCz5bwwq43DvNAM+bHDzLG0U2upi3nUsX9/Nv0cE=;
	b=xczjUjTM2j22BZVxsGyBTRIep76wy9HSJBw77FfeU8mmsGTj5Vl41bwfPZ8Nv1IOaz
	1OMK1N7Y1PVerTOHta+Hnj/5Yt7ucJ9rRCmhIwvQr3II08lC0Z4A4tdFIRbEoKvWBcZW
	K5c5KX1eCZc5aL+WRkq1RdQEH+GNVm4HuDbEI4aqyYT02F7B1nr5QbpmuLAe/Sibvmii
	cy2o2Ah8v4POhqYzSJaKcX+iLPTczIz6iNhaSocB+QIMgmTCdriG435cbkqP/6r5yNiX
	/W3qheG8oz4T8PqLpLWJrMy0u8lqqUKXzfqAEVoXrF/h8sjgZ3zsWC41LC9QdM8betIk
	jQUw==
MIME-Version: 1.0
Received: by 10.14.209.129 with SMTP id s1mr1264826eeo.24.1347520552042; Thu,
	13 Sep 2012 00:15:52 -0700 (PDT)
Received: by 10.14.100.71 with HTTP; Thu, 13 Sep 2012 00:15:51 -0700 (PDT)
Date: Thu, 13 Sep 2012 15:15:51 +0800
Message-ID: <CA+ePHTBU50_t=29G8Ph9KiSRCuKsOn4kL5U==QV8M8SJy4JB_A@mail.gmail.com>
From: =?UTF-8?B?6ams56OK?= <aware.why@gmail.com>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] =?utf-8?q?=E3=80=90problem=E3=80=91what_does_these_ma?=
	=?utf-8?q?cro_used_by_xc=5Fdomain=5Fsave_mean_IN_xen-4=2E1=2E2=3F?=
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============4895920368504980413=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============4895920368504980413==
Content-Type: multipart/alternative; boundary=047d7b603a78d4fec504c990133f

--047d7b603a78d4fec504c990133f
Content-Type: text/plain; charset=ISO-8859-1

Hi all,

    The macros list here,  and what does each mean? Waht's the principle
for saving a dom state and the algorithm for memory dump?

129#define XEN_DOMCTL_getpageframeinfo   7
130
131#define XEN_DOMCTL_PFINFO_LTAB_SHIFT 28
132#define XEN_DOMCTL_PFINFO_NOTAB   (0x0U<<28)
133#define XEN_DOMCTL_PFINFO_L1TAB   (0x1U<<28)
134#define XEN_DOMCTL_PFINFO_L2TAB   (0x2U<<28)
135#define XEN_DOMCTL_PFINFO_L3TAB   (0x3U<<28)
136#define XEN_DOMCTL_PFINFO_L4TAB   (0x4U<<28)
137#define XEN_DOMCTL_PFINFO_LTABTYPE_MASK (0x7U<<28)
138#define XEN_DOMCTL_PFINFO_LPINTAB (0x1U<<31)
139#define XEN_DOMCTL_PFINFO_XTAB    (0xfU<<28) /* invalid page */
140#define XEN_DOMCTL_PFINFO_LTAB_MASK (0xfU<<28)


Thanks

--047d7b603a78d4fec504c990133f
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div><br></div><div>Hi all,</div><div><br></div><div>=A0 =A0 The macros lis=
t here, =A0and what does each mean? Waht&#39;s the principle for saving a d=
om state and the algorithm for <font color=3D"#ff0000">memory dump</font>?<=
/div>
<div><br></div><div>129#define XEN_DOMCTL_getpageframeinfo =A0 7</div><div>=
130</div><div>131#define XEN_DOMCTL_PFINFO_LTAB_SHIFT 28</div><div>132#defi=
ne XEN_DOMCTL_PFINFO_NOTAB =A0 (0x0U&lt;&lt;28)</div>
<div>133#define XEN_DOMCTL_PFINFO_L1TAB =A0 (0x1U&lt;&lt;28)</div><div>134#=
define XEN_DOMCTL_PFINFO_L2TAB =A0 (0x2U&lt;&lt;28)</div><div>135#define XE=
N_DOMCTL_PFINFO_L3TAB =A0 (0x3U&lt;&lt;28)</div><div>136#define XEN_DOMCTL_=
PFINFO_L4TAB =A0 (0x4U&lt;&lt;28)</div>

<div>137#define XEN_DOMCTL_PFINFO_LTABTYPE_MASK (0x7U&lt;&lt;28)</div><div>=
138#define XEN_DOMCTL_PFINFO_LPINTAB (0x1U&lt;&lt;31)</div><div>139#define =
XEN_DOMCTL_PFINFO_XTAB =A0 =A0(0xfU&lt;&lt;28) /* invalid page */</div><div=
>

140#define XEN_DOMCTL_PFINFO_LTAB_MASK (0xfU&lt;&lt;28) =A0=A0</div><div><b=
r></div><div><br></div><div>Thanks</div>

--047d7b603a78d4fec504c990133f--


--===============4895920368504980413==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============4895920368504980413==--


From xen-devel-bounces@lists.xen.org Thu Sep 13 07:32:16 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Sep 2012 07:32:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TC3tw-0006kE-QE; Thu, 13 Sep 2012 07:31: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 1TC3tw-0006k9-9V
	for xen-devel@lists.xen.org; Thu, 13 Sep 2012 07:31:52 +0000
Received: from [85.158.138.51:29428] by server-12.bemta-3.messagelabs.com id
	99/F5-10384-7EB81505; Thu, 13 Sep 2012 07:31:51 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1347521510!22358630!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQwNjM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24483 invoked from network); 13 Sep 2012 07:31:50 -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;
	13 Sep 2012 07:31:50 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 13 Sep 2012 08:31:49 +0100
Message-Id: <5051A83B020000780009AF93@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 13 Sep 2012 08:32:43 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ronghui Duan" <ronghui.duan@intel.com>
References: <A21691DE07B84740B5F0B81466D5148A23BCF1DF@SHSMSX102.ccr.corp.intel.com>
	<20120907174922.GA13040@phenom.dumpdata.com>
	<A21691DE07B84740B5F0B81466D5148A23BF6833@SHSMSX102.ccr.corp.intel.com>
In-Reply-To: <A21691DE07B84740B5F0B81466D5148A23BF6833@SHSMSX102.ccr.corp.intel.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	"Ian.Jackson@eu.citrix.com" <Ian.Jackson@eu.citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"Stefano.Stabellini@eu.citrix.com" <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [RFC v1 0/5] VBD: enlarge max segment per request
 in blkfront
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.09.12 at 04:28, "Duan, Ronghui" <ronghui.duan@intel.com> wrote:
>> And with your patch got:
>>   read : io=4096.0MB, bw=92606KB/s, iops=23151 , runt= 45292msec
>> 
>> without:
>>   read : io=4096.0MB, bw=145187KB/s, iops=36296 , runt= 28889msec
>> 
> What type of backend file you are using? In order to remove the influence of 
> cache in Dom0, I use a physical partition as backend.

But you certainly shouldn't be proposing features getting used
unconditionally or by default that benefit one class of backing
devices and severely penalize others.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 13 07:32:16 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Sep 2012 07:32:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TC3tw-0006kE-QE; Thu, 13 Sep 2012 07:31: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 1TC3tw-0006k9-9V
	for xen-devel@lists.xen.org; Thu, 13 Sep 2012 07:31:52 +0000
Received: from [85.158.138.51:29428] by server-12.bemta-3.messagelabs.com id
	99/F5-10384-7EB81505; Thu, 13 Sep 2012 07:31:51 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1347521510!22358630!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQwNjM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24483 invoked from network); 13 Sep 2012 07:31:50 -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;
	13 Sep 2012 07:31:50 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 13 Sep 2012 08:31:49 +0100
Message-Id: <5051A83B020000780009AF93@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 13 Sep 2012 08:32:43 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ronghui Duan" <ronghui.duan@intel.com>
References: <A21691DE07B84740B5F0B81466D5148A23BCF1DF@SHSMSX102.ccr.corp.intel.com>
	<20120907174922.GA13040@phenom.dumpdata.com>
	<A21691DE07B84740B5F0B81466D5148A23BF6833@SHSMSX102.ccr.corp.intel.com>
In-Reply-To: <A21691DE07B84740B5F0B81466D5148A23BF6833@SHSMSX102.ccr.corp.intel.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	"Ian.Jackson@eu.citrix.com" <Ian.Jackson@eu.citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"Stefano.Stabellini@eu.citrix.com" <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [RFC v1 0/5] VBD: enlarge max segment per request
 in blkfront
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.09.12 at 04:28, "Duan, Ronghui" <ronghui.duan@intel.com> wrote:
>> And with your patch got:
>>   read : io=4096.0MB, bw=92606KB/s, iops=23151 , runt= 45292msec
>> 
>> without:
>>   read : io=4096.0MB, bw=145187KB/s, iops=36296 , runt= 28889msec
>> 
> What type of backend file you are using? In order to remove the influence of 
> cache in Dom0, I use a physical partition as backend.

But you certainly shouldn't be proposing features getting used
unconditionally or by default that benefit one class of backing
devices and severely penalize others.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 13 07:44:01 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Sep 2012 07:44:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TC45K-0006uW-0x; Thu, 13 Sep 2012 07:43: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 1TC45I-0006uR-61
	for xen-devel@lists.xensource.com; Thu, 13 Sep 2012 07:43:36 +0000
Received: from [85.158.139.83:37744] by server-1.bemta-5.messagelabs.com id
	1D/9F-32692-7AE81505; Thu, 13 Sep 2012 07:43:35 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1347522213!25973718!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDg4Njg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29906 invoked from network); 13 Sep 2012 07:43:34 -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;
	13 Sep 2012 07:43:34 -0000
X-IronPort-AV: E=Sophos;i="4.80,416,1344211200"; d="scan'208";a="14511441"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Sep 2012 07:42:34 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Thu, 13 Sep 2012 08:42:34 +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 1TC44H-0000nl-Vj;
	Thu, 13 Sep 2012 07:42:34 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1TC44H-0002aS-Qa;
	Thu, 13 Sep 2012 08:42:33 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-13708-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 13 Sep 2012 08:42:33 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.2-testing test] 13708: 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 13708 xen-4.2-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13708/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore            fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-i386-i386-xl-qemuu-winxpsp3  9 guest-localmigrate         fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  7f993b289dc4
baseline version:
 xen                  8c67e5358efa

------------------------------------------------------------
People who touched revisions under test:
  Ian Campbell <ian.campbell@citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Olaf Hering <olaf@aepfle.de>
------------------------------------------------------------

jobs:
 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                                 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                                     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-4.2-testing
+ revision=7f993b289dc4
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push xen-4.2-testing 7f993b289dc4
+ branch=xen-4.2-testing
+ revision=7f993b289dc4
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-4.2-testing
+ '[' xxen = xlinux ']'
+ linuxbranch=linux
+ : master
+ : tested/2.6.39.x
+ . ap-common
++ : xen@xenbits.xensource.com
++ : http://xenbits.xen.org/hg/staging/xen-4.2-testing.hg
++ : git://xenbits.xen.org/staging/qemu-xen-4.2-testing.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : xen@xenbits.xensource.com:git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.xen-4.2-testing
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-4.2-testing.git
++ : daily-cron.xen-4.2-testing
+ TREE_LINUX=xen@xenbits.xensource.com:git/linux-pvops.git
+ TREE_QEMU_UPSTREAM=xen@xenbits.xensource.com:git/qemu-upstream-4.2-testing.git
+ info_linux_tree xen-4.2-testing
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/xen-4.2-testing.hg
+ hg push -r 7f993b289dc4 ssh://xen@xenbits.xensource.com/HG/xen-4.2-testing.hg
pushing to ssh://xen@xenbits.xensource.com/HG/xen-4.2-testing.hg
searching for changes
remote: adding changesets
remote: adding manifests
remote: adding file changes
remote: added 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 Sep 13 07:44:01 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Sep 2012 07:44:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TC45K-0006uW-0x; Thu, 13 Sep 2012 07:43: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 1TC45I-0006uR-61
	for xen-devel@lists.xensource.com; Thu, 13 Sep 2012 07:43:36 +0000
Received: from [85.158.139.83:37744] by server-1.bemta-5.messagelabs.com id
	1D/9F-32692-7AE81505; Thu, 13 Sep 2012 07:43:35 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1347522213!25973718!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDg4Njg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29906 invoked from network); 13 Sep 2012 07:43:34 -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;
	13 Sep 2012 07:43:34 -0000
X-IronPort-AV: E=Sophos;i="4.80,416,1344211200"; d="scan'208";a="14511441"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Sep 2012 07:42:34 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Thu, 13 Sep 2012 08:42:34 +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 1TC44H-0000nl-Vj;
	Thu, 13 Sep 2012 07:42:34 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1TC44H-0002aS-Qa;
	Thu, 13 Sep 2012 08:42:33 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-13708-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 13 Sep 2012 08:42:33 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.2-testing test] 13708: 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 13708 xen-4.2-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13708/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore            fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-i386-i386-xl-qemuu-winxpsp3  9 guest-localmigrate         fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  7f993b289dc4
baseline version:
 xen                  8c67e5358efa

------------------------------------------------------------
People who touched revisions under test:
  Ian Campbell <ian.campbell@citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Olaf Hering <olaf@aepfle.de>
------------------------------------------------------------

jobs:
 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                                 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                                     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-4.2-testing
+ revision=7f993b289dc4
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push xen-4.2-testing 7f993b289dc4
+ branch=xen-4.2-testing
+ revision=7f993b289dc4
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-4.2-testing
+ '[' xxen = xlinux ']'
+ linuxbranch=linux
+ : master
+ : tested/2.6.39.x
+ . ap-common
++ : xen@xenbits.xensource.com
++ : http://xenbits.xen.org/hg/staging/xen-4.2-testing.hg
++ : git://xenbits.xen.org/staging/qemu-xen-4.2-testing.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : xen@xenbits.xensource.com:git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.xen-4.2-testing
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-4.2-testing.git
++ : daily-cron.xen-4.2-testing
+ TREE_LINUX=xen@xenbits.xensource.com:git/linux-pvops.git
+ TREE_QEMU_UPSTREAM=xen@xenbits.xensource.com:git/qemu-upstream-4.2-testing.git
+ info_linux_tree xen-4.2-testing
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/xen-4.2-testing.hg
+ hg push -r 7f993b289dc4 ssh://xen@xenbits.xensource.com/HG/xen-4.2-testing.hg
pushing to ssh://xen@xenbits.xensource.com/HG/xen-4.2-testing.hg
searching for changes
remote: adding changesets
remote: adding manifests
remote: adding file changes
remote: added 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 Sep 13 07:45:41 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Sep 2012 07:45:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TC471-00072t-PJ; Thu, 13 Sep 2012 07:45: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 1TC470-00072l-IW
	for xen-devel@lists.xen.org; Thu, 13 Sep 2012 07:45:22 +0000
Received: from [85.158.139.83:18787] by server-4.bemta-5.messagelabs.com id
	49/58-23042-11F81505; Thu, 13 Sep 2012 07:45:21 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1347522320!26290851!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQwNjM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30737 invoked from network); 13 Sep 2012 07:45:21 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-7.tower-182.messagelabs.com with SMTP;
	13 Sep 2012 07:45:21 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 13 Sep 2012 08:45:20 +0100
Message-Id: <5051AB66020000780009AFAC@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 13 Sep 2012 08:46:14 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Daniel De Graaf" <dgdegra@tycho.nsa.gov>
References: <1347465586-20009-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1347465586-20009-10-git-send-email-dgdegra@tycho.nsa.gov>
In-Reply-To: <1347465586-20009-10-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 09/22] xsm: Use the dummy XSM module if XSM
 is disabled
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.09.12 at 17:59, Daniel De Graaf <dgdegra@tycho.nsa.gov> wrote:
> This patch moves the implementation of the dummy XSM module to a header
> file that provides inline functions when XSM_ENABLE is not defined. This
> reduces duplication between the dummy module and callers when the
> implementation of the dummy return is not just "return 0", and also
> provides better compile-time checking for completeness of the XSM
> implementations in the dummy module.

This looks good to me, with one minor comment:

> --- a/xen/xsm/xsm_core.c
> +++ b/xen/xsm/xsm_core.c
> @@ -113,7 +113,7 @@ int unregister_xsm(struct xsm_operations *ops)
>  
>  long do_xsm_op (XEN_GUEST_HANDLE(xsm_op_t) op)
>  {
> -    return __do_xsm_op(op);
> +    return xsm___do_xsm_op(op);

The three immediately successive underscores look really odd
now - any reason a single one doesn't do?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 13 07:45:41 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Sep 2012 07:45:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TC471-00072t-PJ; Thu, 13 Sep 2012 07:45: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 1TC470-00072l-IW
	for xen-devel@lists.xen.org; Thu, 13 Sep 2012 07:45:22 +0000
Received: from [85.158.139.83:18787] by server-4.bemta-5.messagelabs.com id
	49/58-23042-11F81505; Thu, 13 Sep 2012 07:45:21 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1347522320!26290851!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQwNjM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30737 invoked from network); 13 Sep 2012 07:45:21 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-7.tower-182.messagelabs.com with SMTP;
	13 Sep 2012 07:45:21 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 13 Sep 2012 08:45:20 +0100
Message-Id: <5051AB66020000780009AFAC@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 13 Sep 2012 08:46:14 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Daniel De Graaf" <dgdegra@tycho.nsa.gov>
References: <1347465586-20009-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1347465586-20009-10-git-send-email-dgdegra@tycho.nsa.gov>
In-Reply-To: <1347465586-20009-10-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 09/22] xsm: Use the dummy XSM module if XSM
 is disabled
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.09.12 at 17:59, Daniel De Graaf <dgdegra@tycho.nsa.gov> wrote:
> This patch moves the implementation of the dummy XSM module to a header
> file that provides inline functions when XSM_ENABLE is not defined. This
> reduces duplication between the dummy module and callers when the
> implementation of the dummy return is not just "return 0", and also
> provides better compile-time checking for completeness of the XSM
> implementations in the dummy module.

This looks good to me, with one minor comment:

> --- a/xen/xsm/xsm_core.c
> +++ b/xen/xsm/xsm_core.c
> @@ -113,7 +113,7 @@ int unregister_xsm(struct xsm_operations *ops)
>  
>  long do_xsm_op (XEN_GUEST_HANDLE(xsm_op_t) op)
>  {
> -    return __do_xsm_op(op);
> +    return xsm___do_xsm_op(op);

The three immediately successive underscores look really odd
now - any reason a single one doesn't do?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 13 08:00:23 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Sep 2012 08:00:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TC4LD-0007Tu-QL; Thu, 13 Sep 2012 08:00: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 1TC4LB-0007Gb-OX
	for xen-devel@lists.xen.org; Thu, 13 Sep 2012 08:00:02 +0000
Received: from [85.158.139.83:3233] by server-11.bemta-5.messagelabs.com id
	C5/02-24658-18291505; Thu, 13 Sep 2012 08:00:01 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1347523200!30075701!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQwNjM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18844 invoked from network); 13 Sep 2012 08:00:00 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-12.tower-182.messagelabs.com with SMTP;
	13 Sep 2012 08:00:00 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 13 Sep 2012 09:00:00 +0100
Message-Id: <5051AED7020000780009AFC3@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 13 Sep 2012 09:00:55 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Daniel De Graaf" <dgdegra@tycho.nsa.gov>
References: <1347465586-20009-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1347465586-20009-20-git-send-email-dgdegra@tycho.nsa.gov>
In-Reply-To: <1347465586-20009-20-git-send-email-dgdegra@tycho.nsa.gov>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Tim Deegan <tim@xen.org>, Keir Fraser <keir@xen.org>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 19/22] arch/x86: check remote MMIO remap
 permissions
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.09.12 at 17:59, Daniel De Graaf <dgdegra@tycho.nsa.gov> wrote:
> When a domain is mapping pages from a different pg_owner domain, the
> iomem_access checks are currently only applied to the pg_owner domain,
> potentially allowing the current domain to bypass its more restrictive
> iomem_access policy using another domain that it has access to.

Are you sure about this? I ask because ...

> --- a/xen/arch/x86/mm.c
> +++ b/xen/arch/x86/mm.c
> @@ -754,6 +754,18 @@ get_page_from_l1e(
>              return -EINVAL;
>          }
>  
> +        if ( pg_owner != curr->domain &&
> +             !iomem_access_permitted(curr->domain, mfn, mfn) )
> +        {
> +            if ( mfn != (PADDR_MASK >> PAGE_SHIFT) ) /* INVALID_MFN? */
> +            {
> +                MEM_LOG("Domain %u attempted to map I/O space %08lx in domain %u",
> +                        curr->domain->domain_id, mfn, pg_owner->domain_id);
> +                return -EPERM;
> +            }
> +            return -EINVAL;
> +        }
> +

... the place you insert this is after non-RAM pages got filtered
out already, so you're applying an IOMEM permission check to a
RAM page.

Jan

>          if ( !(l1f & _PAGE_RW) ||
>               !rangeset_contains_singleton(mmio_ro_ranges, mfn) )
>              return 0;



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 13 08:00:23 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Sep 2012 08:00:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TC4LD-0007Tu-QL; Thu, 13 Sep 2012 08:00: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 1TC4LB-0007Gb-OX
	for xen-devel@lists.xen.org; Thu, 13 Sep 2012 08:00:02 +0000
Received: from [85.158.139.83:3233] by server-11.bemta-5.messagelabs.com id
	C5/02-24658-18291505; Thu, 13 Sep 2012 08:00:01 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1347523200!30075701!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQwNjM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18844 invoked from network); 13 Sep 2012 08:00:00 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-12.tower-182.messagelabs.com with SMTP;
	13 Sep 2012 08:00:00 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 13 Sep 2012 09:00:00 +0100
Message-Id: <5051AED7020000780009AFC3@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 13 Sep 2012 09:00:55 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Daniel De Graaf" <dgdegra@tycho.nsa.gov>
References: <1347465586-20009-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1347465586-20009-20-git-send-email-dgdegra@tycho.nsa.gov>
In-Reply-To: <1347465586-20009-20-git-send-email-dgdegra@tycho.nsa.gov>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Tim Deegan <tim@xen.org>, Keir Fraser <keir@xen.org>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 19/22] arch/x86: check remote MMIO remap
 permissions
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.09.12 at 17:59, Daniel De Graaf <dgdegra@tycho.nsa.gov> wrote:
> When a domain is mapping pages from a different pg_owner domain, the
> iomem_access checks are currently only applied to the pg_owner domain,
> potentially allowing the current domain to bypass its more restrictive
> iomem_access policy using another domain that it has access to.

Are you sure about this? I ask because ...

> --- a/xen/arch/x86/mm.c
> +++ b/xen/arch/x86/mm.c
> @@ -754,6 +754,18 @@ get_page_from_l1e(
>              return -EINVAL;
>          }
>  
> +        if ( pg_owner != curr->domain &&
> +             !iomem_access_permitted(curr->domain, mfn, mfn) )
> +        {
> +            if ( mfn != (PADDR_MASK >> PAGE_SHIFT) ) /* INVALID_MFN? */
> +            {
> +                MEM_LOG("Domain %u attempted to map I/O space %08lx in domain %u",
> +                        curr->domain->domain_id, mfn, pg_owner->domain_id);
> +                return -EPERM;
> +            }
> +            return -EINVAL;
> +        }
> +

... the place you insert this is after non-RAM pages got filtered
out already, so you're applying an IOMEM permission check to a
RAM page.

Jan

>          if ( !(l1f & _PAGE_RW) ||
>               !rangeset_contains_singleton(mmio_ro_ranges, mfn) )
>              return 0;



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 13 08:13:00 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Sep 2012 08:13:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TC4XQ-0007tX-85; Thu, 13 Sep 2012 08:12: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 1TC4XP-0007tS-NN
	for xen-devel@lists.xen.org; Thu, 13 Sep 2012 08:12:39 +0000
Received: from [85.158.143.99:45719] by server-1.bemta-4.messagelabs.com id
	A6/30-12504-67591505; Thu, 13 Sep 2012 08:12:38 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1347523958!24785868!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQwNjM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7183 invoked from network); 13 Sep 2012 08:12:38 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-2.tower-216.messagelabs.com with SMTP;
	13 Sep 2012 08:12:38 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 13 Sep 2012 09:12:38 +0100
Message-Id: <5051B1CC020000780009AFCE@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 13 Sep 2012 09:13:32 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Daniel De Graaf" <dgdegra@tycho.nsa.gov>
References: <1347465586-20009-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1347465586-20009-21-git-send-email-dgdegra@tycho.nsa.gov>
In-Reply-To: <1347465586-20009-21-git-send-email-dgdegra@tycho.nsa.gov>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Tim Deegan <tim@xen.org>, Keir Fraser <keir@xen.org>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 20/22] arch/x86: use XSM hooks for
 get_pg_owner access checks
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 12.09.12 at 17:59, Daniel De Graaf <dgdegra@tycho.nsa.gov> wrote:
> @@ -3353,9 +3357,14 @@ long do_mmu_update(
>              mfn = req.ptr >> PAGE_SHIFT;
>              gpfn = req.val;
>  
> -            rc = xsm_mmu_machphys_update(d, pg_owner, mfn);
> -            if ( rc )
> -                break;
> +            xsm_needed |= XSM_MMU_MACHPHYS_UPDATE;
> +            if ( xsm_needed != xsm_checked )
> +            {
> +                rc = xsm_mmu_update(d, pt_owner, pg_owner, xsm_needed);

If you're already updating it this way, it would seem appropriate
to remove the over-checking here: pt_owner is meaningless for
this operation (there are no page tables involved), and hence
you could/should pass d instead.

Jan

> +                if ( rc )
> +                    break;
> +                xsm_checked = xsm_needed;
> +            }
>  
>              if ( unlikely(!get_page_from_pagenr(mfn, pg_owner)) )
>              {



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 13 08:13:00 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Sep 2012 08:13:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TC4XQ-0007tX-85; Thu, 13 Sep 2012 08:12: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 1TC4XP-0007tS-NN
	for xen-devel@lists.xen.org; Thu, 13 Sep 2012 08:12:39 +0000
Received: from [85.158.143.99:45719] by server-1.bemta-4.messagelabs.com id
	A6/30-12504-67591505; Thu, 13 Sep 2012 08:12:38 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1347523958!24785868!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQwNjM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7183 invoked from network); 13 Sep 2012 08:12:38 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-2.tower-216.messagelabs.com with SMTP;
	13 Sep 2012 08:12:38 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 13 Sep 2012 09:12:38 +0100
Message-Id: <5051B1CC020000780009AFCE@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 13 Sep 2012 09:13:32 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Daniel De Graaf" <dgdegra@tycho.nsa.gov>
References: <1347465586-20009-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1347465586-20009-21-git-send-email-dgdegra@tycho.nsa.gov>
In-Reply-To: <1347465586-20009-21-git-send-email-dgdegra@tycho.nsa.gov>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Tim Deegan <tim@xen.org>, Keir Fraser <keir@xen.org>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 20/22] arch/x86: use XSM hooks for
 get_pg_owner access checks
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 12.09.12 at 17:59, Daniel De Graaf <dgdegra@tycho.nsa.gov> wrote:
> @@ -3353,9 +3357,14 @@ long do_mmu_update(
>              mfn = req.ptr >> PAGE_SHIFT;
>              gpfn = req.val;
>  
> -            rc = xsm_mmu_machphys_update(d, pg_owner, mfn);
> -            if ( rc )
> -                break;
> +            xsm_needed |= XSM_MMU_MACHPHYS_UPDATE;
> +            if ( xsm_needed != xsm_checked )
> +            {
> +                rc = xsm_mmu_update(d, pt_owner, pg_owner, xsm_needed);

If you're already updating it this way, it would seem appropriate
to remove the over-checking here: pt_owner is meaningless for
this operation (there are no page tables involved), and hence
you could/should pass d instead.

Jan

> +                if ( rc )
> +                    break;
> +                xsm_checked = xsm_needed;
> +            }
>  
>              if ( unlikely(!get_page_from_pagenr(mfn, pg_owner)) )
>              {



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 13 08:34:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Sep 2012 08:34:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TC4rn-00088q-Bc; Thu, 13 Sep 2012 08:33:43 +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 1TC4rl-00088l-P5
	for xen-devel@lists.xen.org; Thu, 13 Sep 2012 08:33:41 +0000
Received: from [85.158.143.35:8738] by server-2.bemta-4.messagelabs.com id
	2D/1C-21239-56A91505; Thu, 13 Sep 2012 08:33:41 +0000
X-Env-Sender: waldi@debian.org
X-Msg-Ref: server-11.tower-21.messagelabs.com!1347525185!11281097!1
X-Originating-IP: [82.139.201.20]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4344 invoked from network); 13 Sep 2012 08:33:05 -0000
Received: from wavehammer.waldi.eu.org (HELO wavehammer.waldi.eu.org)
	(82.139.201.20)
	by server-11.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 13 Sep 2012 08:33:05 -0000
Received: by wavehammer.waldi.eu.org (Postfix, from userid 1000)
	id D575C5424E; Thu, 13 Sep 2012 10:33:02 +0200 (CEST)
Date: Thu, 13 Sep 2012 10:33:02 +0200
From: Bastian Blank <waldi@debian.org>
To: xen-devel@lists.xen.org
Message-ID: <20120913083302.GA27147@wavehammer.waldi.eu.org>
Mail-Followup-To: Bastian Blank <waldi@debian.org>, xen-devel@lists.xen.org
MIME-Version: 1.0
Content-Disposition: inline
User-Agent: Mutt/1.5.21 (2010-09-15)
Subject: [Xen-devel] [RFC] openvswitch support 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

Hi

I wrote a vif script to support openvswitch. I use it on some of my
machines, so it works for non-qemu domains.

Ian asked me to send it here, maybe someone wants to take a look.

Bastian

#!/bin/bash
#============================================================================
# ${XEN_SCRIPT_DIR}/vif-openvswitch
#
# Script for configuring a vif in openvswitch mode.
# The hotplugging system will call this script if it is specified either in
# the device configuration given to Xend, or the default Xend configuration
# in ${XEN_CONFIG_DIR}/xend-config.sxp.  If the script is specified in
# neither of those places, then this script is the default.
#
# Usage:
# vif-openvswitch (add|remove|online|offline)
#
# Environment vars:
# vif         vif interface name (required).
# XENBUS_PATH path to this device's details in the XenStore (required).
#
# Read from the store:
# bridge  openvswitch to add the vif to (required).
# ip      list of IP networks for the vif, space-separated (optional).
#
# up:
# Enslaves the vif interface to the bridge and adds iptables rules
# for its ip addresses (if any).
#
# down:
# Removes the vif interface from the bridge and removes the iptables
# rules for its ip addresses (if any).
#============================================================================

dir=$(dirname "$0")
. "$dir/vif-common.sh"

openvswitch_external_id() {
    local dev=$1
    local key=$2
    local value=$3

    echo "-- set interface $dev external-ids:\"$key\"=\"$value\""
}

openvswitch_external_id_all() {
    local dev=$1
    local frontend_id=$(xenstore_read "$XENBUS_PATH/frontend-id")
    local vm_path=$(xenstore_read "/local/domain/${frontend_id}/vm")
    local name=$(xenstore_read "${vm_path}/name")
    openvswitch_external_id $dev "xen-vm-name" "$name"
    local uuid=$(xenstore_read "${vm_path}/uuid")
    openvswitch_external_id $dev "xen-vm-uuid" "$uuid"
    local mac=$(xenstore_read "$XENBUS_PATH/mac")
    openvswitch_external_id $dev "attached-mac" "$mac"
}

add_to_openvswitch () {
    local dev=$1
    local bridge="$(xenstore_read_default "$XENBUS_PATH/bridge" "$bridge")"
    local tag trunk

    if [[ $bridge =~ ^([^.:]+)(\.([[:digit:]]+))?(:([[:digit:]]+(:[[:digit:]]+)*))?$ ]]; then
        bridge="${BASH_REMATCH[1]}"
        tag="${BASH_REMATCH[3]}"
        trunk="${BASH_REMATCH[5]//:/,}"
    else
        fatal "No valid brdige was specified"
    fi

    if [ $trunk ]; then
        local trunk_arg="trunk=$trunk"
    fi

    if [ $tag ]; then
        local tag_arg="tag=$tag"
    fi

    local vif_details="$(openvswitch_external_id_all $dev)"

    ovs-vsctl --timeout=30 -- --if-exists del-port $dev -- add-port "$bridge" $dev $tag_arg $trunk_arg $vif_details
    ip link set $dev up
}

case "$command" in
    add|online)
        setup_virtual_bridge_port $dev
        add_to_openvswitch $dev
        ;;

    offline)
        ovs-vsctl --timeout=30 -- --if-exists del-port $dev
        ;;
esac

if [ "$type_if" = vif ]; then
    handle_iptable
fi

log debug "Successful vif-openvswitch $command for $dev."
if [ "$type_if" = vif -a "$command" = "online" ]; then
    success
fi
-- 
Is truth not truth for all?
		-- Natira, "For the World is Hollow and I have Touched
		   the Sky", stardate 5476.4.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 13 08:34:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Sep 2012 08:34:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TC4rn-00088q-Bc; Thu, 13 Sep 2012 08:33:43 +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 1TC4rl-00088l-P5
	for xen-devel@lists.xen.org; Thu, 13 Sep 2012 08:33:41 +0000
Received: from [85.158.143.35:8738] by server-2.bemta-4.messagelabs.com id
	2D/1C-21239-56A91505; Thu, 13 Sep 2012 08:33:41 +0000
X-Env-Sender: waldi@debian.org
X-Msg-Ref: server-11.tower-21.messagelabs.com!1347525185!11281097!1
X-Originating-IP: [82.139.201.20]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4344 invoked from network); 13 Sep 2012 08:33:05 -0000
Received: from wavehammer.waldi.eu.org (HELO wavehammer.waldi.eu.org)
	(82.139.201.20)
	by server-11.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 13 Sep 2012 08:33:05 -0000
Received: by wavehammer.waldi.eu.org (Postfix, from userid 1000)
	id D575C5424E; Thu, 13 Sep 2012 10:33:02 +0200 (CEST)
Date: Thu, 13 Sep 2012 10:33:02 +0200
From: Bastian Blank <waldi@debian.org>
To: xen-devel@lists.xen.org
Message-ID: <20120913083302.GA27147@wavehammer.waldi.eu.org>
Mail-Followup-To: Bastian Blank <waldi@debian.org>, xen-devel@lists.xen.org
MIME-Version: 1.0
Content-Disposition: inline
User-Agent: Mutt/1.5.21 (2010-09-15)
Subject: [Xen-devel] [RFC] openvswitch support 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

Hi

I wrote a vif script to support openvswitch. I use it on some of my
machines, so it works for non-qemu domains.

Ian asked me to send it here, maybe someone wants to take a look.

Bastian

#!/bin/bash
#============================================================================
# ${XEN_SCRIPT_DIR}/vif-openvswitch
#
# Script for configuring a vif in openvswitch mode.
# The hotplugging system will call this script if it is specified either in
# the device configuration given to Xend, or the default Xend configuration
# in ${XEN_CONFIG_DIR}/xend-config.sxp.  If the script is specified in
# neither of those places, then this script is the default.
#
# Usage:
# vif-openvswitch (add|remove|online|offline)
#
# Environment vars:
# vif         vif interface name (required).
# XENBUS_PATH path to this device's details in the XenStore (required).
#
# Read from the store:
# bridge  openvswitch to add the vif to (required).
# ip      list of IP networks for the vif, space-separated (optional).
#
# up:
# Enslaves the vif interface to the bridge and adds iptables rules
# for its ip addresses (if any).
#
# down:
# Removes the vif interface from the bridge and removes the iptables
# rules for its ip addresses (if any).
#============================================================================

dir=$(dirname "$0")
. "$dir/vif-common.sh"

openvswitch_external_id() {
    local dev=$1
    local key=$2
    local value=$3

    echo "-- set interface $dev external-ids:\"$key\"=\"$value\""
}

openvswitch_external_id_all() {
    local dev=$1
    local frontend_id=$(xenstore_read "$XENBUS_PATH/frontend-id")
    local vm_path=$(xenstore_read "/local/domain/${frontend_id}/vm")
    local name=$(xenstore_read "${vm_path}/name")
    openvswitch_external_id $dev "xen-vm-name" "$name"
    local uuid=$(xenstore_read "${vm_path}/uuid")
    openvswitch_external_id $dev "xen-vm-uuid" "$uuid"
    local mac=$(xenstore_read "$XENBUS_PATH/mac")
    openvswitch_external_id $dev "attached-mac" "$mac"
}

add_to_openvswitch () {
    local dev=$1
    local bridge="$(xenstore_read_default "$XENBUS_PATH/bridge" "$bridge")"
    local tag trunk

    if [[ $bridge =~ ^([^.:]+)(\.([[:digit:]]+))?(:([[:digit:]]+(:[[:digit:]]+)*))?$ ]]; then
        bridge="${BASH_REMATCH[1]}"
        tag="${BASH_REMATCH[3]}"
        trunk="${BASH_REMATCH[5]//:/,}"
    else
        fatal "No valid brdige was specified"
    fi

    if [ $trunk ]; then
        local trunk_arg="trunk=$trunk"
    fi

    if [ $tag ]; then
        local tag_arg="tag=$tag"
    fi

    local vif_details="$(openvswitch_external_id_all $dev)"

    ovs-vsctl --timeout=30 -- --if-exists del-port $dev -- add-port "$bridge" $dev $tag_arg $trunk_arg $vif_details
    ip link set $dev up
}

case "$command" in
    add|online)
        setup_virtual_bridge_port $dev
        add_to_openvswitch $dev
        ;;

    offline)
        ovs-vsctl --timeout=30 -- --if-exists del-port $dev
        ;;
esac

if [ "$type_if" = vif ]; then
    handle_iptable
fi

log debug "Successful vif-openvswitch $command for $dev."
if [ "$type_if" = vif -a "$command" = "online" ]; then
    success
fi
-- 
Is truth not truth for all?
		-- Natira, "For the World is Hollow and I have Touched
		   the Sky", stardate 5476.4.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 13 09:41:19 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Sep 2012 09: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 1TC5ur-0001Zs-Po; Thu, 13 Sep 2012 09:40: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 1TC5uq-0001Zl-67
	for xen-devel@lists.xensource.com; Thu, 13 Sep 2012 09:40:56 +0000
Received: from [85.158.138.51:23799] by server-3.bemta-3.messagelabs.com id
	00/A4-21322-72AA1505; Thu, 13 Sep 2012 09:40:55 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1347529253!26280459!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDkwMjg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13804 invoked from network); 13 Sep 2012 09:40:54 -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;
	13 Sep 2012 09:40:54 -0000
X-IronPort-AV: E=Sophos;i="4.80,416,1344211200"; d="scan'208";a="14514877"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Sep 2012 09:40: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.279.1; Thu, 13 Sep 2012 10:40: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 1TC5un-000241-CL;
	Thu, 13 Sep 2012 09:40:53 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1TC5un-0007qT-6E;
	Thu, 13 Sep 2012 10:40:53 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-13710-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 13 Sep 2012 10:40:53 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13710: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 13710 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13710/

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. 13668
 build-i386                    4 xen-build                 fail REGR. vs. 13668

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore            fail   like 13668
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail like 13668
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail like 13668

Tests which did not succeed, but are not blocking:
 test-amd64-i386-rhel6hvm-amd  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 xen-build-check(1)           blocked n/a
 test-i386-i386-xl-qemuu-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-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-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-xl-credit2    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-amd64-win         16 leak-check/check             fail   never pass
 test-i386-i386-pv             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-qemuu-rhel6hvm-intel  1 xen-build-check(1)         blocked n/a
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-pv            1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-win-vcpus1    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-winxpsp3-vcpus1  1 xen-build-check(1)           blocked n/a
 test-amd64-i386-xl            1 xen-build-check(1)           blocked  n/a
 test-i386-i386-win            1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-win         1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-i386-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-i386-pair          1 xen-build-check(1)           blocked  n/a

version targeted for testing:
 xen                  485e6db28b93
baseline version:
 xen                  7d770de90b7f

------------------------------------------------------------
People who touched revisions under test:
  Boris Ostrovsky <boris.ostrovsky@amd.com>
  Christoph Egger <Christoph.Egger@amd.com>
  Dan Magenheimer <dan.magenheimer@oracle.com>
  David Vrabel <david.vrabel@citrix.com>
  Ian Campbell <ian.campbell@citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Keir Fraser <keir@xen.org>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Wei Wang <wei.wang2@amd.com>
  Zhenzhong Duan <zhenzhong.duan@oracle.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   fail    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           fail    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           blocked 
 test-i386-i386-xl                                            blocked 
 test-amd64-i386-rhel6hvm-amd                                 blocked 
 test-amd64-i386-qemuu-rhel6hvm-amd                           blocked 
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                blocked 
 test-amd64-i386-xl-credit2                                   blocked 
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               blocked 
 test-amd64-i386-qemuu-rhel6hvm-intel                         blocked 
 test-amd64-i386-xl-multivcpu                                 blocked 
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         blocked 
 test-i386-i386-pair                                          blocked 
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           blocked 
 test-i386-i386-pv                                            blocked 
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   blocked 
 test-amd64-i386-xl-win-vcpus1                                blocked 
 test-amd64-i386-xl-winxpsp3-vcpus1                           blocked 
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          blocked 
 test-i386-i386-win                                           blocked 
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        blocked 
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             blocked 
 test-amd64-i386-xend-winxpsp3                                blocked 
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   blocked 


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

(No revision log; it would be 633 lines long.)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 13 09:41:19 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Sep 2012 09: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 1TC5ur-0001Zs-Po; Thu, 13 Sep 2012 09:40: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 1TC5uq-0001Zl-67
	for xen-devel@lists.xensource.com; Thu, 13 Sep 2012 09:40:56 +0000
Received: from [85.158.138.51:23799] by server-3.bemta-3.messagelabs.com id
	00/A4-21322-72AA1505; Thu, 13 Sep 2012 09:40:55 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1347529253!26280459!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDkwMjg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13804 invoked from network); 13 Sep 2012 09:40:54 -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;
	13 Sep 2012 09:40:54 -0000
X-IronPort-AV: E=Sophos;i="4.80,416,1344211200"; d="scan'208";a="14514877"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Sep 2012 09:40: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.279.1; Thu, 13 Sep 2012 10:40: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 1TC5un-000241-CL;
	Thu, 13 Sep 2012 09:40:53 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1TC5un-0007qT-6E;
	Thu, 13 Sep 2012 10:40:53 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-13710-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 13 Sep 2012 10:40:53 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13710: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 13710 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13710/

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. 13668
 build-i386                    4 xen-build                 fail REGR. vs. 13668

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore            fail   like 13668
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail like 13668
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail like 13668

Tests which did not succeed, but are not blocking:
 test-amd64-i386-rhel6hvm-amd  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 xen-build-check(1)           blocked n/a
 test-i386-i386-xl-qemuu-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-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-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-xl-credit2    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-amd64-win         16 leak-check/check             fail   never pass
 test-i386-i386-pv             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-qemuu-rhel6hvm-intel  1 xen-build-check(1)         blocked n/a
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-pv            1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-win-vcpus1    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-winxpsp3-vcpus1  1 xen-build-check(1)           blocked n/a
 test-amd64-i386-xl            1 xen-build-check(1)           blocked  n/a
 test-i386-i386-win            1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-win         1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-i386-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-i386-pair          1 xen-build-check(1)           blocked  n/a

version targeted for testing:
 xen                  485e6db28b93
baseline version:
 xen                  7d770de90b7f

------------------------------------------------------------
People who touched revisions under test:
  Boris Ostrovsky <boris.ostrovsky@amd.com>
  Christoph Egger <Christoph.Egger@amd.com>
  Dan Magenheimer <dan.magenheimer@oracle.com>
  David Vrabel <david.vrabel@citrix.com>
  Ian Campbell <ian.campbell@citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Keir Fraser <keir@xen.org>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Wei Wang <wei.wang2@amd.com>
  Zhenzhong Duan <zhenzhong.duan@oracle.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   fail    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           fail    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           blocked 
 test-i386-i386-xl                                            blocked 
 test-amd64-i386-rhel6hvm-amd                                 blocked 
 test-amd64-i386-qemuu-rhel6hvm-amd                           blocked 
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                blocked 
 test-amd64-i386-xl-credit2                                   blocked 
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               blocked 
 test-amd64-i386-qemuu-rhel6hvm-intel                         blocked 
 test-amd64-i386-xl-multivcpu                                 blocked 
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         blocked 
 test-i386-i386-pair                                          blocked 
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           blocked 
 test-i386-i386-pv                                            blocked 
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   blocked 
 test-amd64-i386-xl-win-vcpus1                                blocked 
 test-amd64-i386-xl-winxpsp3-vcpus1                           blocked 
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          blocked 
 test-i386-i386-win                                           blocked 
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        blocked 
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             blocked 
 test-amd64-i386-xend-winxpsp3                                blocked 
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   blocked 


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

(No revision log; it would be 633 lines long.)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 13 10:11:49 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Sep 2012 10:11:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TC6OK-0002WH-VV; Thu, 13 Sep 2012 10:11: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 1TC6OK-0002WC-97
	for xen-devel@lists.xen.org; Thu, 13 Sep 2012 10:11:24 +0000
Received: from [85.158.143.35:20908] by server-2.bemta-4.messagelabs.com id
	99/B0-21239-B41B1505; Thu, 13 Sep 2012 10:11:23 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-13.tower-21.messagelabs.com!1347531081!16701434!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7052 invoked from network); 13 Sep 2012 10:11:21 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-13.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 13 Sep 2012 10:11:21 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1TC6OG-0003Wk-CT; Thu, 13 Sep 2012 10:11:20 +0000
Date: Thu, 13 Sep 2012 11:11:20 +0100
From: Tim Deegan <tim@xen.org>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20120913101120.GA12881@ocelot.phlegethon.org>
References: <CAFw--Dd0k7L+T_UJc0yHAkUGrY_-GDHaQjK3OM-1UdOp=J-wAQ@mail.gmail.com>
	<20120907085036.GA71093@ocelot.phlegethon.org>
	<5049E2C70200007800099B21@nat28.tlf.novell.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <5049E2C70200007800099B21@nat28.tlf.novell.com>
User-Agent: Mutt/1.4.2.1i
Cc: Jeffrey Karrels <karrelsj@gmail.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Clang/LLVM version requirements
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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:04 +0100 on 07 Sep (1347015863), Jan Beulich wrote:
> >>> On 07.09.12 at 10:50, Tim Deegan <tim@xen.org> wrote:
> > Jan, would you object to some other way of checking for .bss in reloc.c?
> 
> No, if you have a better idea.
> 
> > Could we just objcopy it out so any BSS symbols make it fail at link
> > time?
> 
> Would that reliably fail with all linker versions?
> 
> > In any case we probably ought to check for stray .data symbols too.
> 
> Not really, no. Those would still be present in reloc.bin, and
> hence make it into reloc.S.

But they would break the test, because the magic alignment happens in
.text, right?  Anyway, compile-time failure seems more useful.  How
about this, based on the similar checks for init-only files?


# HG changeset patch
# Parent 5691e4cc17da7fe8664a67f1d07c3755c0ca34ed
x86: check for BSS in reloc code at compile time.

This is a more helpful failure mode than hanging at boot time, and
incidentally fixes the clang/LLVM build by removing a .subsection rune.

Signed-off-by: Tim Deegan <tim@xen.org>

diff -r 5691e4cc17da xen/arch/x86/boot/build32.mk
--- a/xen/arch/x86/boot/build32.mk	Thu Sep 13 10:23:17 2012 +0200
+++ b/xen/arch/x86/boot/build32.mk	Thu Sep 13 11:04:29 2012 +0100
@@ -20,6 +20,15 @@ CFLAGS := $(filter-out -flto,$(CFLAGS))
 
 %.o: %.c
 	$(CC) $(CFLAGS) -c -fpic $< -o $@
+	$(OBJDUMP) -h $@ | sed -n '/[0-9]/{s,00*,0,g;p}' |\
+		while read idx name sz rest; do \
+			case "$$name" in \
+			.bss|.bss.*) \
+				test $$sz != 0 || continue; \
+				echo "Error: non-empty BSS: 0x$$sz" >&2; \
+				exit $$(expr $$idx + 1);; \
+			esac; \
+		done
 
 reloc.o: $(BASEDIR)/include/asm-x86/config.h
 .PRECIOUS: %.bin %.lnk
diff -r 5691e4cc17da xen/arch/x86/boot/reloc.c
--- a/xen/arch/x86/boot/reloc.c	Thu Sep 13 10:23:17 2012 +0200
+++ b/xen/arch/x86/boot/reloc.c	Thu Sep 13 11:04:29 2012 +0100
@@ -18,10 +18,7 @@ asm (
     "    call 1f                       \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"
+    "    jmp  reloc                    \n"
     );
 
 /* This is our data.  Because the code must be relocatable, no BSS is
@@ -30,9 +27,6 @@ asm (
 asm (
     "alloc:                            \n"
     "    .long 0                       \n"
-    "    .subsection 1                 \n"
-    "    .p2align 4, 0xcc              \n"
-    "    .subsection 0                 \n"
     );
 
 typedef unsigned int u32;

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 13 10:11:49 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Sep 2012 10:11:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TC6OK-0002WH-VV; Thu, 13 Sep 2012 10:11: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 1TC6OK-0002WC-97
	for xen-devel@lists.xen.org; Thu, 13 Sep 2012 10:11:24 +0000
Received: from [85.158.143.35:20908] by server-2.bemta-4.messagelabs.com id
	99/B0-21239-B41B1505; Thu, 13 Sep 2012 10:11:23 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-13.tower-21.messagelabs.com!1347531081!16701434!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7052 invoked from network); 13 Sep 2012 10:11:21 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-13.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 13 Sep 2012 10:11:21 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1TC6OG-0003Wk-CT; Thu, 13 Sep 2012 10:11:20 +0000
Date: Thu, 13 Sep 2012 11:11:20 +0100
From: Tim Deegan <tim@xen.org>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20120913101120.GA12881@ocelot.phlegethon.org>
References: <CAFw--Dd0k7L+T_UJc0yHAkUGrY_-GDHaQjK3OM-1UdOp=J-wAQ@mail.gmail.com>
	<20120907085036.GA71093@ocelot.phlegethon.org>
	<5049E2C70200007800099B21@nat28.tlf.novell.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <5049E2C70200007800099B21@nat28.tlf.novell.com>
User-Agent: Mutt/1.4.2.1i
Cc: Jeffrey Karrels <karrelsj@gmail.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Clang/LLVM version requirements
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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:04 +0100 on 07 Sep (1347015863), Jan Beulich wrote:
> >>> On 07.09.12 at 10:50, Tim Deegan <tim@xen.org> wrote:
> > Jan, would you object to some other way of checking for .bss in reloc.c?
> 
> No, if you have a better idea.
> 
> > Could we just objcopy it out so any BSS symbols make it fail at link
> > time?
> 
> Would that reliably fail with all linker versions?
> 
> > In any case we probably ought to check for stray .data symbols too.
> 
> Not really, no. Those would still be present in reloc.bin, and
> hence make it into reloc.S.

But they would break the test, because the magic alignment happens in
.text, right?  Anyway, compile-time failure seems more useful.  How
about this, based on the similar checks for init-only files?


# HG changeset patch
# Parent 5691e4cc17da7fe8664a67f1d07c3755c0ca34ed
x86: check for BSS in reloc code at compile time.

This is a more helpful failure mode than hanging at boot time, and
incidentally fixes the clang/LLVM build by removing a .subsection rune.

Signed-off-by: Tim Deegan <tim@xen.org>

diff -r 5691e4cc17da xen/arch/x86/boot/build32.mk
--- a/xen/arch/x86/boot/build32.mk	Thu Sep 13 10:23:17 2012 +0200
+++ b/xen/arch/x86/boot/build32.mk	Thu Sep 13 11:04:29 2012 +0100
@@ -20,6 +20,15 @@ CFLAGS := $(filter-out -flto,$(CFLAGS))
 
 %.o: %.c
 	$(CC) $(CFLAGS) -c -fpic $< -o $@
+	$(OBJDUMP) -h $@ | sed -n '/[0-9]/{s,00*,0,g;p}' |\
+		while read idx name sz rest; do \
+			case "$$name" in \
+			.bss|.bss.*) \
+				test $$sz != 0 || continue; \
+				echo "Error: non-empty BSS: 0x$$sz" >&2; \
+				exit $$(expr $$idx + 1);; \
+			esac; \
+		done
 
 reloc.o: $(BASEDIR)/include/asm-x86/config.h
 .PRECIOUS: %.bin %.lnk
diff -r 5691e4cc17da xen/arch/x86/boot/reloc.c
--- a/xen/arch/x86/boot/reloc.c	Thu Sep 13 10:23:17 2012 +0200
+++ b/xen/arch/x86/boot/reloc.c	Thu Sep 13 11:04:29 2012 +0100
@@ -18,10 +18,7 @@ asm (
     "    call 1f                       \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"
+    "    jmp  reloc                    \n"
     );
 
 /* This is our data.  Because the code must be relocatable, no BSS is
@@ -30,9 +27,6 @@ asm (
 asm (
     "alloc:                            \n"
     "    .long 0                       \n"
-    "    .subsection 1                 \n"
-    "    .p2align 4, 0xcc              \n"
-    "    .subsection 0                 \n"
     );
 
 typedef unsigned int u32;

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 13 10:13:30 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Sep 2012 10:13:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TC6Pt-0002af-FR; Thu, 13 Sep 2012 10:13:01 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <jiongxi.li@intel.com>) id 1TC6Ps-0002aP-6X
	for xen-devel@lists.xen.org; Thu, 13 Sep 2012 10:13:00 +0000
X-Env-Sender: jiongxi.li@intel.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1347531173!3886573!1
X-Originating-IP: [134.134.136.24]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjQgPT4gMzQxNTMy\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28036 invoked from network); 13 Sep 2012 10:12:53 -0000
Received: from mga09.intel.com (HELO mga09.intel.com) (134.134.136.24)
	by server-15.tower-27.messagelabs.com with SMTP;
	13 Sep 2012 10:12:53 -0000
Received: from orsmga001.jf.intel.com ([10.7.209.18])
	by orsmga102.jf.intel.com with ESMTP; 13 Sep 2012 03:12:44 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.80,416,1344236400"; d="scan'208";a="192472099"
Received: from fmsmsx105.amr.corp.intel.com ([10.19.9.36])
	by orsmga001.jf.intel.com with ESMTP; 13 Sep 2012 03:12:52 -0700
Received: from fmsmsx152.amr.corp.intel.com (10.19.17.221) by
	FMSMSX105.amr.corp.intel.com (10.19.9.36) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Thu, 13 Sep 2012 03:12:52 -0700
Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by
	fmsmsx152.amr.corp.intel.com (10.19.17.221) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Thu, 13 Sep 2012 03:12:52 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.239]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.175]) with mapi id
	14.01.0355.002; Thu, 13 Sep 2012 18:12:50 +0800
From: "Li, Jiongxi" <jiongxi.li@intel.com>
To: Keir Fraser <keir@xen.org>, "xen-devel@lists.xen.org"
	<xen-devel@lists.xen.org>
Thread-Topic: [Xen-devel] [ PATCH 2/2] xen: enable Virtual-interrupt delivery
Thread-Index: Ac2HWp7G2HqBx++QQP2kPrY5SPXyLgABHshJAPpQGPAANScdiAFexalA
Date: Thu, 13 Sep 2012 10:12:49 +0000
Message-ID: <D9137FCD9CFF644B965863BCFBEDABB8780441@SHSMSX101.ccr.corp.intel.com>
References: <D9137FCD9CFF644B965863BCFBEDABB877CBB8@SHSMSX101.ccr.corp.intel.com>
	<CC6E3DBD.4ADE4%keir@xen.org>
In-Reply-To: <CC6E3DBD.4ADE4%keir@xen.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Subject: Re: [Xen-devel] [ PATCH 2/2] xen: enable Virtual-interrupt 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



> -----Original Message-----
> From: xen-devel-bounces@lists.xen.org
> [mailto:xen-devel-bounces@lists.xen.org] On Behalf Of Keir Fraser
> Sent: Thursday, September 06, 2012 6:47 PM
> To: Li, Jiongxi; xen-devel@lists.xen.org
> Subject: Re: [Xen-devel] [ PATCH 2/2] xen: enable Virtual-interrupt delivery
> 
> On 06/09/2012 11:00, "Li, Jiongxi" <jiongxi.li@intel.com> wrote:
> 
> >>>  int hvm_local_events_need_delivery(struct vcpu *v) {
> >>> -    struct hvm_intack intack = hvm_vcpu_has_pending_irq(v);
> >>> +    struct hvm_intack intack;
> >>> +
> >>> +    pt_update_irq(v);
> >>
> >> Why would this change be needed for vAPIC?
> > When vcpu is scheduled out, there will be periodic timer interrupt
> > pending for injection. Every VMExit is a chance to inject the pending
> > periodic timer interrupt on vmx_intr_assist. In no virtual interrupt
> > delivery case, although injected timer interrupt is edge trigger, EOI
> > always induces VMExit, pending periodic timer can be kept injected
> > till there is no pending left. But in virtual interrupt delivery case,
> > only level trigger interrupt can induce VMExit, there is much less
> > chance for injecting pending timer interrupt through VMExit.
> > Adding pt_update_irq here is another code path to inject pending
> > periodic timer, but it can't guarantee every pending timer interrupt can be
> injected.
> > Another way is to make every EOI of pending timer interrupt induce
> > VMExit, but it may obey the spirit of virtual interrupt delivery - reducing
> VMExit.
> > We have been evaluating that.
> 
> Should cause EOI to induce VMExit only when there is more periodic timer work
> to be done? That would be better than this hack.
> 
Yes, in our new patch, we set eoi_exit_bitmap for periodic timer interrup to cause EOI-induced VM exit.
Please refer to patch v2
>  -- Keir
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 13 10:13:30 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Sep 2012 10:13:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TC6Pt-0002af-FR; Thu, 13 Sep 2012 10:13:01 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <jiongxi.li@intel.com>) id 1TC6Ps-0002aP-6X
	for xen-devel@lists.xen.org; Thu, 13 Sep 2012 10:13:00 +0000
X-Env-Sender: jiongxi.li@intel.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1347531173!3886573!1
X-Originating-IP: [134.134.136.24]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjQgPT4gMzQxNTMy\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28036 invoked from network); 13 Sep 2012 10:12:53 -0000
Received: from mga09.intel.com (HELO mga09.intel.com) (134.134.136.24)
	by server-15.tower-27.messagelabs.com with SMTP;
	13 Sep 2012 10:12:53 -0000
Received: from orsmga001.jf.intel.com ([10.7.209.18])
	by orsmga102.jf.intel.com with ESMTP; 13 Sep 2012 03:12:44 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.80,416,1344236400"; d="scan'208";a="192472099"
Received: from fmsmsx105.amr.corp.intel.com ([10.19.9.36])
	by orsmga001.jf.intel.com with ESMTP; 13 Sep 2012 03:12:52 -0700
Received: from fmsmsx152.amr.corp.intel.com (10.19.17.221) by
	FMSMSX105.amr.corp.intel.com (10.19.9.36) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Thu, 13 Sep 2012 03:12:52 -0700
Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by
	fmsmsx152.amr.corp.intel.com (10.19.17.221) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Thu, 13 Sep 2012 03:12:52 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.239]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.175]) with mapi id
	14.01.0355.002; Thu, 13 Sep 2012 18:12:50 +0800
From: "Li, Jiongxi" <jiongxi.li@intel.com>
To: Keir Fraser <keir@xen.org>, "xen-devel@lists.xen.org"
	<xen-devel@lists.xen.org>
Thread-Topic: [Xen-devel] [ PATCH 2/2] xen: enable Virtual-interrupt delivery
Thread-Index: Ac2HWp7G2HqBx++QQP2kPrY5SPXyLgABHshJAPpQGPAANScdiAFexalA
Date: Thu, 13 Sep 2012 10:12:49 +0000
Message-ID: <D9137FCD9CFF644B965863BCFBEDABB8780441@SHSMSX101.ccr.corp.intel.com>
References: <D9137FCD9CFF644B965863BCFBEDABB877CBB8@SHSMSX101.ccr.corp.intel.com>
	<CC6E3DBD.4ADE4%keir@xen.org>
In-Reply-To: <CC6E3DBD.4ADE4%keir@xen.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Subject: Re: [Xen-devel] [ PATCH 2/2] xen: enable Virtual-interrupt 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



> -----Original Message-----
> From: xen-devel-bounces@lists.xen.org
> [mailto:xen-devel-bounces@lists.xen.org] On Behalf Of Keir Fraser
> Sent: Thursday, September 06, 2012 6:47 PM
> To: Li, Jiongxi; xen-devel@lists.xen.org
> Subject: Re: [Xen-devel] [ PATCH 2/2] xen: enable Virtual-interrupt delivery
> 
> On 06/09/2012 11:00, "Li, Jiongxi" <jiongxi.li@intel.com> wrote:
> 
> >>>  int hvm_local_events_need_delivery(struct vcpu *v) {
> >>> -    struct hvm_intack intack = hvm_vcpu_has_pending_irq(v);
> >>> +    struct hvm_intack intack;
> >>> +
> >>> +    pt_update_irq(v);
> >>
> >> Why would this change be needed for vAPIC?
> > When vcpu is scheduled out, there will be periodic timer interrupt
> > pending for injection. Every VMExit is a chance to inject the pending
> > periodic timer interrupt on vmx_intr_assist. In no virtual interrupt
> > delivery case, although injected timer interrupt is edge trigger, EOI
> > always induces VMExit, pending periodic timer can be kept injected
> > till there is no pending left. But in virtual interrupt delivery case,
> > only level trigger interrupt can induce VMExit, there is much less
> > chance for injecting pending timer interrupt through VMExit.
> > Adding pt_update_irq here is another code path to inject pending
> > periodic timer, but it can't guarantee every pending timer interrupt can be
> injected.
> > Another way is to make every EOI of pending timer interrupt induce
> > VMExit, but it may obey the spirit of virtual interrupt delivery - reducing
> VMExit.
> > We have been evaluating that.
> 
> Should cause EOI to induce VMExit only when there is more periodic timer work
> to be done? That would be better than this hack.
> 
Yes, in our new patch, we set eoi_exit_bitmap for periodic timer interrup to cause EOI-induced VM exit.
Please refer to patch v2
>  -- Keir
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 13 10:13:33 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Sep 2012 10:13: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 1TC6Q6-0002by-7L; Thu, 13 Sep 2012 10:13:14 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jiongxi.li@intel.com>) id 1TC6Q5-0002bq-8u
	for xen-devel@lists.xen.org; Thu, 13 Sep 2012 10:13:13 +0000
Received: from [85.158.139.83:9941] by server-5.bemta-5.messagelabs.com id
	42/C5-30514-8B1B1505; Thu, 13 Sep 2012 10:13:12 +0000
X-Env-Sender: jiongxi.li@intel.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1347531188!30115340!1
X-Originating-IP: [192.55.52.93]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjkzID0+IDM0NjI4NQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22223 invoked from network); 13 Sep 2012 10:13:09 -0000
Received: from mga11.intel.com (HELO mga11.intel.com) (192.55.52.93)
	by server-12.tower-182.messagelabs.com with SMTP;
	13 Sep 2012 10:13:09 -0000
Received: from fmsmga002.fm.intel.com ([10.253.24.26])
	by fmsmga102.fm.intel.com with ESMTP; 13 Sep 2012 03:13:07 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.80,416,1344236400"; d="scan'208";a="221491385"
Received: from fmsmsx106.amr.corp.intel.com ([10.19.9.37])
	by fmsmga002.fm.intel.com with ESMTP; 13 Sep 2012 03:13:07 -0700
Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by
	FMSMSX106.amr.corp.intel.com (10.19.9.37) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Thu, 13 Sep 2012 03:13:06 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.239]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.175]) with mapi id
	14.01.0355.002; Thu, 13 Sep 2012 18:13:05 +0800
From: "Li, Jiongxi" <jiongxi.li@intel.com>
To: "Zhang, Yang Z" <yang.z.zhang@intel.com>, Jan Beulich <JBeulich@suse.com>
Thread-Topic: [Xen-devel] [ PATCH 2/2] xen: enable Virtual-interrupt delivery
Thread-Index: Ac2HWp7GP5TL6y3yYk23uPXy04inPgABHshJAPpQGPAAJCkEAAAwBV9wAT8M+SA=
Date: Thu, 13 Sep 2012 10:13:04 +0000
Message-ID: <D9137FCD9CFF644B965863BCFBEDABB8780447@SHSMSX101.ccr.corp.intel.com>
References: <D9137FCD9CFF644B965863BCFBEDABB8779942@SHSMSX101.ccr.corp.intel.com>
	<CC664937.3D6DA%keir.xen@gmail.com>
	<D9137FCD9CFF644B965863BCFBEDABB877CBB8@SHSMSX101.ccr.corp.intel.com>
	<504899C40200007800099435@nat28.tlf.novell.com>
	<A9667DDFB95DB7438FA9D7D576C3D87E24D3B1@SHSMSX101.ccr.corp.intel.com>
In-Reply-To: <A9667DDFB95DB7438FA9D7D576C3D87E24D3B1@SHSMSX101.ccr.corp.intel.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: Keir Fraser <keir.xen@gmail.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [ PATCH 2/2] xen: enable Virtual-interrupt 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



> -----Original Message-----
> From: Zhang, Yang Z
> Sent: Friday, September 07, 2012 10:08 AM
> To: Jan Beulich; Li, Jiongxi
> Cc: Keir Fraser; xen-devel@lists.xen.org
> Subject: RE: [Xen-devel] [ PATCH 2/2] xen: enable Virtual-interrupt delivery
> 
> Jan Beulich wrote on 2012-09-06:
> >>>> On 06.09.12 at 12:00, "Li, Jiongxi" <jiongxi.li@intel.com> wrote:
> >>> From: Keir Fraser [mailto:keir.xen@gmail.com] On 31/08/2012 10:30,
> >>> "Li, Jiongxi" <jiongxi.li@intel.com> wrote:
> >>>> --- a/xen/arch/x86/hvm/irq.c  Fri Aug 31 09:30:38 2012 +0800
> >>>> +++ b/xen/arch/x86/hvm/irq.c         Fri Aug 31 09:49:39 2012 +0800
> >>>> @@ -452,7 +452,11 @@ struct hvm_intack hvm_vcpu_ack_pending_i
> >>>>
> >>>>  int hvm_local_events_need_delivery(struct vcpu *v) {
> >>>> -    struct hvm_intack intack = hvm_vcpu_has_pending_irq(v);
> >>>> +    struct hvm_intack intack;
> >>>> +
> >>>> +    pt_update_irq(v);
> >>>
> >>> Why would this change be needed for vAPIC?
> >> When vcpu is scheduled out, there will be periodic timer interrupt
> >> pending
> >
> > Probably rather "may"?
> 
> yes, there may have pending timer interrupt.
> 
> >> for injection. Every VMExit is a chance to inject the pending
> >> periodic timer interrupt on vmx_intr_assist. In no virtual interrupt
> >> delivery case, although injected timer interrupt is edge trigger, EOI
> >> always induces VMExit, pending periodic timer can be kept injected
> >> till there is no pending left. But in virtual interrupt delivery
> >> case, only level trigger interrupt can induce VMExit, there is much
> >> less chance for injecting pending timer interrupt through VMExit.
> >
> > And it's not possible to set the respective VIRR[] bit, and let the
> > hardware take care of injecting at the right time?
> 
> Right, we can use this way to inject the interrupt.
> But it still need a watchdog to aware when the bit in VIRR is cleared by guest,
> and the cost is same with forcing VM exit when writing EOI for timer interrupt.
> 
> >> Adding pt_update_irq here is another code path to inject pending
> >> periodic timer, but it can't guarantee every pending timer interrupt can be
> injected.
> >> Another way is to make every EOI of pending timer interrupt induce
> >> VMExit, but it may obey the spirit of virtual interrupt delivery - reducing
> VMExit.
> >> We have been evaluating that.
> >
> > With which result?
> 
> We are doing it now. Will let you know the result when get it.
> 
In our new patch, we set eoi_exit_bitmap for periodic timer interrup to cause EOI-induced VM exit, then pending periodic time interrups have the chance to be injected for compensation
Please refer to patch v2

> > Jan
> >
> >
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xen.org
> > http://lists.xen.org/xen-devel
> 
> 
> 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 Thu Sep 13 10:13:33 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Sep 2012 10:13: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 1TC6Q6-0002by-7L; Thu, 13 Sep 2012 10:13:14 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jiongxi.li@intel.com>) id 1TC6Q5-0002bq-8u
	for xen-devel@lists.xen.org; Thu, 13 Sep 2012 10:13:13 +0000
Received: from [85.158.139.83:9941] by server-5.bemta-5.messagelabs.com id
	42/C5-30514-8B1B1505; Thu, 13 Sep 2012 10:13:12 +0000
X-Env-Sender: jiongxi.li@intel.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1347531188!30115340!1
X-Originating-IP: [192.55.52.93]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjkzID0+IDM0NjI4NQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22223 invoked from network); 13 Sep 2012 10:13:09 -0000
Received: from mga11.intel.com (HELO mga11.intel.com) (192.55.52.93)
	by server-12.tower-182.messagelabs.com with SMTP;
	13 Sep 2012 10:13:09 -0000
Received: from fmsmga002.fm.intel.com ([10.253.24.26])
	by fmsmga102.fm.intel.com with ESMTP; 13 Sep 2012 03:13:07 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.80,416,1344236400"; d="scan'208";a="221491385"
Received: from fmsmsx106.amr.corp.intel.com ([10.19.9.37])
	by fmsmga002.fm.intel.com with ESMTP; 13 Sep 2012 03:13:07 -0700
Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by
	FMSMSX106.amr.corp.intel.com (10.19.9.37) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Thu, 13 Sep 2012 03:13:06 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.239]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.175]) with mapi id
	14.01.0355.002; Thu, 13 Sep 2012 18:13:05 +0800
From: "Li, Jiongxi" <jiongxi.li@intel.com>
To: "Zhang, Yang Z" <yang.z.zhang@intel.com>, Jan Beulich <JBeulich@suse.com>
Thread-Topic: [Xen-devel] [ PATCH 2/2] xen: enable Virtual-interrupt delivery
Thread-Index: Ac2HWp7GP5TL6y3yYk23uPXy04inPgABHshJAPpQGPAAJCkEAAAwBV9wAT8M+SA=
Date: Thu, 13 Sep 2012 10:13:04 +0000
Message-ID: <D9137FCD9CFF644B965863BCFBEDABB8780447@SHSMSX101.ccr.corp.intel.com>
References: <D9137FCD9CFF644B965863BCFBEDABB8779942@SHSMSX101.ccr.corp.intel.com>
	<CC664937.3D6DA%keir.xen@gmail.com>
	<D9137FCD9CFF644B965863BCFBEDABB877CBB8@SHSMSX101.ccr.corp.intel.com>
	<504899C40200007800099435@nat28.tlf.novell.com>
	<A9667DDFB95DB7438FA9D7D576C3D87E24D3B1@SHSMSX101.ccr.corp.intel.com>
In-Reply-To: <A9667DDFB95DB7438FA9D7D576C3D87E24D3B1@SHSMSX101.ccr.corp.intel.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: Keir Fraser <keir.xen@gmail.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [ PATCH 2/2] xen: enable Virtual-interrupt 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



> -----Original Message-----
> From: Zhang, Yang Z
> Sent: Friday, September 07, 2012 10:08 AM
> To: Jan Beulich; Li, Jiongxi
> Cc: Keir Fraser; xen-devel@lists.xen.org
> Subject: RE: [Xen-devel] [ PATCH 2/2] xen: enable Virtual-interrupt delivery
> 
> Jan Beulich wrote on 2012-09-06:
> >>>> On 06.09.12 at 12:00, "Li, Jiongxi" <jiongxi.li@intel.com> wrote:
> >>> From: Keir Fraser [mailto:keir.xen@gmail.com] On 31/08/2012 10:30,
> >>> "Li, Jiongxi" <jiongxi.li@intel.com> wrote:
> >>>> --- a/xen/arch/x86/hvm/irq.c  Fri Aug 31 09:30:38 2012 +0800
> >>>> +++ b/xen/arch/x86/hvm/irq.c         Fri Aug 31 09:49:39 2012 +0800
> >>>> @@ -452,7 +452,11 @@ struct hvm_intack hvm_vcpu_ack_pending_i
> >>>>
> >>>>  int hvm_local_events_need_delivery(struct vcpu *v) {
> >>>> -    struct hvm_intack intack = hvm_vcpu_has_pending_irq(v);
> >>>> +    struct hvm_intack intack;
> >>>> +
> >>>> +    pt_update_irq(v);
> >>>
> >>> Why would this change be needed for vAPIC?
> >> When vcpu is scheduled out, there will be periodic timer interrupt
> >> pending
> >
> > Probably rather "may"?
> 
> yes, there may have pending timer interrupt.
> 
> >> for injection. Every VMExit is a chance to inject the pending
> >> periodic timer interrupt on vmx_intr_assist. In no virtual interrupt
> >> delivery case, although injected timer interrupt is edge trigger, EOI
> >> always induces VMExit, pending periodic timer can be kept injected
> >> till there is no pending left. But in virtual interrupt delivery
> >> case, only level trigger interrupt can induce VMExit, there is much
> >> less chance for injecting pending timer interrupt through VMExit.
> >
> > And it's not possible to set the respective VIRR[] bit, and let the
> > hardware take care of injecting at the right time?
> 
> Right, we can use this way to inject the interrupt.
> But it still need a watchdog to aware when the bit in VIRR is cleared by guest,
> and the cost is same with forcing VM exit when writing EOI for timer interrupt.
> 
> >> Adding pt_update_irq here is another code path to inject pending
> >> periodic timer, but it can't guarantee every pending timer interrupt can be
> injected.
> >> Another way is to make every EOI of pending timer interrupt induce
> >> VMExit, but it may obey the spirit of virtual interrupt delivery - reducing
> VMExit.
> >> We have been evaluating that.
> >
> > With which result?
> 
> We are doing it now. Will let you know the result when get it.
> 
In our new patch, we set eoi_exit_bitmap for periodic timer interrup to cause EOI-induced VM exit, then pending periodic time interrups have the chance to be injected for compensation
Please refer to patch v2

> > Jan
> >
> >
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xen.org
> > http://lists.xen.org/xen-devel
> 
> 
> 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 Thu Sep 13 10:13:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Sep 2012 10:13:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TC6QL-0002eD-MV; Thu, 13 Sep 2012 10:13:29 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jiongxi.li@intel.com>) id 1TC6QJ-0002dq-PO
	for xen-devel@lists.xen.org; Thu, 13 Sep 2012 10:13:28 +0000
Received: from [85.158.138.51:45905] by server-10.bemta-3.messagelabs.com id
	E6/9E-10411-7C1B1505; Thu, 13 Sep 2012 10:13:27 +0000
X-Env-Sender: jiongxi.li@intel.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1347531204!28655865!1
X-Originating-IP: [143.182.124.37]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMzcgPT4gMjAxNjM2\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20299 invoked from network); 13 Sep 2012 10:13:25 -0000
Received: from mga14.intel.com (HELO mga14.intel.com) (143.182.124.37)
	by server-9.tower-174.messagelabs.com with SMTP;
	13 Sep 2012 10:13:25 -0000
Received: from azsmga001.ch.intel.com ([10.2.17.19])
	by azsmga102.ch.intel.com with ESMTP; 13 Sep 2012 03:13:23 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.80,416,1344236400"; d="scan'208";a="192246701"
Received: from fmsmsx103.amr.corp.intel.com ([10.19.9.34])
	by azsmga001.ch.intel.com with ESMTP; 13 Sep 2012 03:13:23 -0700
Received: from fmsmsx101.amr.corp.intel.com (10.19.9.52) by
	FMSMSX103.amr.corp.intel.com (10.19.9.34) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Thu, 13 Sep 2012 03:13:23 -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; Thu, 13 Sep 2012 03:13:22 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.239]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.175]) with mapi id
	14.01.0355.002; Thu, 13 Sep 2012 18:13:21 +0800
From: "Li, Jiongxi" <jiongxi.li@intel.com>
To: Jan Beulich <JBeulich@suse.com>
Thread-Topic: [Xen-devel] [ PATCH 2/2] xen: enable Virtual-interrupt delivery
Thread-Index: AQHNjBs0nmuHFTegw0a4yZ6YMxWq9ZeIE82Q
Date: Thu, 13 Sep 2012 10:13:20 +0000
Message-ID: <D9137FCD9CFF644B965863BCFBEDABB878044D@SHSMSX101.ccr.corp.intel.com>
References: <D9137FCD9CFF644B965863BCFBEDABB8779942@SHSMSX101.ccr.corp.intel.com>
	<5040CAB30200007800097D73@nat28.tlf.novell.com>
	<D9137FCD9CFF644B965863BCFBEDABB877CBBD@SHSMSX101.ccr.corp.intel.com>
	<504898870200007800099427@nat28.tlf.novell.com>
In-Reply-To: <504898870200007800099427@nat28.tlf.novell.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [ PATCH 2/2] xen: enable Virtual-interrupt 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

A new patch is sent out according to review comment.
Also please see my comment interlaced

> -----Original Message-----
> From: Jan Beulich [mailto:JBeulich@suse.com]
> Sent: Thursday, September 06, 2012 6:35 PM
> To: Li, Jiongxi
> Cc: xen-devel@lists.xen.org
> Subject: RE: [Xen-devel] [ PATCH 2/2] xen: enable Virtual-interrupt delivery
> 
> >>> On 06.09.12 at 12:00, "Li, Jiongxi" <jiongxi.li@intel.com> wrote:
> >> > +/*
> >> > + * When "Virtual Interrupt Delivery" is enabled, this function is
> >> > +used
> >> > + * to handle EOI-induced VM exit
> >> > + */
> >> > +void vlapic_handle_EOI_induced_exit(struct vlapic *vlapic, int
> >> > +vector) {
> >> > +    ASSERT(cpu_has_vmx_virtual_intr_delivery);
> >> > +
> >> > +    if ( vlapic_test_and_clear_vector(vector,
> >> > + &vlapic->regs->data[APIC_TMR]) )
> >>
> >> Why test_and_clear rather than just test?
> > While virtual interrupt delivery is enabled, 'vlapic_EOI_set' function
> > won't be called( 'vlapic_EOI_set' also has the test and clear call). '
> 
> Ah, okay.
> 
> >> > --- a/xen/arch/x86/hvm/vmx/intr.c Fri Aug 31 09:30:38 2012 +0800
> >> > +++ b/xen/arch/x86/hvm/vmx/intr.c       Fri Aug 31 09:49:39 2012
> +0800
> >> > @@ -227,19 +227,43 @@ void vmx_intr_assist(void)
> >> >              goto out;
> >> >
> >> >          intblk = hvm_interrupt_blocked(v, intack);
> >> > -        if ( intblk == hvm_intblk_tpr )
> >> > +        if ( cpu_has_vmx_virtual_intr_delivery )
> >> >          {
> >> > -            ASSERT(vlapic_enabled(vcpu_vlapic(v)));
> >> > -            ASSERT(intack.source == hvm_intsrc_lapic);
> >> > -            tpr_threshold = intack.vector >> 4;
> >> > -            goto out;
> >> > +            /* Set "Interrupt-window exiting" for ExtINT */
> >> > +            if ( (intblk != hvm_intblk_none) &&
> >> > +                 ( (intack.source == hvm_intsrc_pic) ||
> >> > +                 ( intack.source == hvm_intsrc_vector) ) )
> >> > +            {
> >> > +                enable_intr_window(v, intack);
> >> > +                goto out;
> >> > +            }
> >> > +
> >> > +            if ( __vmread(VM_ENTRY_INTR_INFO) &
> >> INTR_INFO_VALID_MASK )
> >> > +            {
> >> > +                if ( (intack.source == hvm_intsrc_pic) ||
> >> > +                     (intack.source == hvm_intsrc_nmi) ||
> >> > +                     (intack.source == hvm_intsrc_mce) )
> >> > +                    enable_intr_window(v, intack);
> >> > +
> >> > +                goto out;
> >> > +            }
> >> >          }
> >> > +        else
> >> > +        {
> >> > +            if ( intblk == hvm_intblk_tpr )
> >> > +            {
> >> > +                ASSERT(vlapic_enabled(vcpu_vlapic(v)));
> >> > +                ASSERT(intack.source == hvm_intsrc_lapic);
> >> > +                tpr_threshold = intack.vector >> 4;
> >> > +                goto out;
> >> > +            }
> >> >
> >> > -        if ( (intblk != hvm_intblk_none) ||
> >> > -             (__vmread(VM_ENTRY_INTR_INFO) &
> >> INTR_INFO_VALID_MASK) )
> >> > -        {
> >> > -            enable_intr_window(v, intack);
> >> > -            goto out;
> >> > +            if ( (intblk != hvm_intblk_none) ||
> >> > +                 (__vmread(VM_ENTRY_INTR_INFO) &
> >> INTR_INFO_VALID_MASK) )
> >> > +            {
> >> > +                enable_intr_window(v, intack);
> >> > +                goto out;
> >> > +            }
> >> >          }
> >>
> >> If you made the above and if()/else if() series, some of the
> >> differences
> > would go
> >> away, making the changes easier to review.
> > I can't quite understand you here.
> > The original code looked like:
> > if (a)
> > {}
> > if (b)
> > {}
> > And my change as follow:
> > if ( cpu_has_vmx_virtual_intr_delivery ) { } else {
> >   if (a)
> >   {}
> >   if (b)
> >   {}
> > }
> > How should I adjust the code?
> 
> Considering that the original could already have been written with if/else-if, I
> was suggesting to expand this to your addition:
> 
> if ( cpu_has_vmx_virtual_intr_delivery ) { } else if (a)
>   {}
> else if (b)
>   {}
> 
> which will avoid any (indentation only) changes past the first of the two else-if-s.
> Plus it would make the logic of the code more clear, at once likely making
> apparent that there'll now be quite a few "goto out"-s that ought to be check
> for being replaceable by fewer instances of them placed slightly differently.
It is a good suggestion. But the original code is two parallel if() case, not the if/else-if case, and can't be changed to if/else-if case, so I just keep the original code here. :)

> 
> >> > +#define UPDATE_EOI_EXITMAP(v, e)
> {                             \
> >> > +        if (test_and_clear_bit(e, &(v).eoi_exitmap_changed)) {      \
> >>
> >> Here and elsewhere - do you really need locked accesses?
> > Do you mean using the '__test_and_set_bit' ?
> 
> Yes, if suitable.
Since the parameter may also be changed in 'vlapic_set_irq' function, and that function may be called asynchronously, so a lock is needed here.

> >> Furthermore, here and in other places you fail to write the upper
> >> halves for 32-bit, yet you also don't disable the code for 32-bit afaics.
> > OK, __vmwrite(EOI_EXIT_BITMAP##e, (v).eoi_exit_bitmap[e]) ;would be
> >   __vmwrite(EOI_EXIT_BITMAP##e, (v).eoi_exit_bitmap[e]) #ifdef
> > __i386__
> >   __vmwrite(EOI_EXIT_BITMAP##e##_HIGH, (v).eoi_exit_bitmap[e] >> 32)
> > #endif
> 
> Something along those lines, yes.
> 
> Jan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 13 10:13:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Sep 2012 10:13:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TC6QL-0002eD-MV; Thu, 13 Sep 2012 10:13:29 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jiongxi.li@intel.com>) id 1TC6QJ-0002dq-PO
	for xen-devel@lists.xen.org; Thu, 13 Sep 2012 10:13:28 +0000
Received: from [85.158.138.51:45905] by server-10.bemta-3.messagelabs.com id
	E6/9E-10411-7C1B1505; Thu, 13 Sep 2012 10:13:27 +0000
X-Env-Sender: jiongxi.li@intel.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1347531204!28655865!1
X-Originating-IP: [143.182.124.37]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMzcgPT4gMjAxNjM2\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20299 invoked from network); 13 Sep 2012 10:13:25 -0000
Received: from mga14.intel.com (HELO mga14.intel.com) (143.182.124.37)
	by server-9.tower-174.messagelabs.com with SMTP;
	13 Sep 2012 10:13:25 -0000
Received: from azsmga001.ch.intel.com ([10.2.17.19])
	by azsmga102.ch.intel.com with ESMTP; 13 Sep 2012 03:13:23 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.80,416,1344236400"; d="scan'208";a="192246701"
Received: from fmsmsx103.amr.corp.intel.com ([10.19.9.34])
	by azsmga001.ch.intel.com with ESMTP; 13 Sep 2012 03:13:23 -0700
Received: from fmsmsx101.amr.corp.intel.com (10.19.9.52) by
	FMSMSX103.amr.corp.intel.com (10.19.9.34) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Thu, 13 Sep 2012 03:13:23 -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; Thu, 13 Sep 2012 03:13:22 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.239]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.175]) with mapi id
	14.01.0355.002; Thu, 13 Sep 2012 18:13:21 +0800
From: "Li, Jiongxi" <jiongxi.li@intel.com>
To: Jan Beulich <JBeulich@suse.com>
Thread-Topic: [Xen-devel] [ PATCH 2/2] xen: enable Virtual-interrupt delivery
Thread-Index: AQHNjBs0nmuHFTegw0a4yZ6YMxWq9ZeIE82Q
Date: Thu, 13 Sep 2012 10:13:20 +0000
Message-ID: <D9137FCD9CFF644B965863BCFBEDABB878044D@SHSMSX101.ccr.corp.intel.com>
References: <D9137FCD9CFF644B965863BCFBEDABB8779942@SHSMSX101.ccr.corp.intel.com>
	<5040CAB30200007800097D73@nat28.tlf.novell.com>
	<D9137FCD9CFF644B965863BCFBEDABB877CBBD@SHSMSX101.ccr.corp.intel.com>
	<504898870200007800099427@nat28.tlf.novell.com>
In-Reply-To: <504898870200007800099427@nat28.tlf.novell.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [ PATCH 2/2] xen: enable Virtual-interrupt 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

A new patch is sent out according to review comment.
Also please see my comment interlaced

> -----Original Message-----
> From: Jan Beulich [mailto:JBeulich@suse.com]
> Sent: Thursday, September 06, 2012 6:35 PM
> To: Li, Jiongxi
> Cc: xen-devel@lists.xen.org
> Subject: RE: [Xen-devel] [ PATCH 2/2] xen: enable Virtual-interrupt delivery
> 
> >>> On 06.09.12 at 12:00, "Li, Jiongxi" <jiongxi.li@intel.com> wrote:
> >> > +/*
> >> > + * When "Virtual Interrupt Delivery" is enabled, this function is
> >> > +used
> >> > + * to handle EOI-induced VM exit
> >> > + */
> >> > +void vlapic_handle_EOI_induced_exit(struct vlapic *vlapic, int
> >> > +vector) {
> >> > +    ASSERT(cpu_has_vmx_virtual_intr_delivery);
> >> > +
> >> > +    if ( vlapic_test_and_clear_vector(vector,
> >> > + &vlapic->regs->data[APIC_TMR]) )
> >>
> >> Why test_and_clear rather than just test?
> > While virtual interrupt delivery is enabled, 'vlapic_EOI_set' function
> > won't be called( 'vlapic_EOI_set' also has the test and clear call). '
> 
> Ah, okay.
> 
> >> > --- a/xen/arch/x86/hvm/vmx/intr.c Fri Aug 31 09:30:38 2012 +0800
> >> > +++ b/xen/arch/x86/hvm/vmx/intr.c       Fri Aug 31 09:49:39 2012
> +0800
> >> > @@ -227,19 +227,43 @@ void vmx_intr_assist(void)
> >> >              goto out;
> >> >
> >> >          intblk = hvm_interrupt_blocked(v, intack);
> >> > -        if ( intblk == hvm_intblk_tpr )
> >> > +        if ( cpu_has_vmx_virtual_intr_delivery )
> >> >          {
> >> > -            ASSERT(vlapic_enabled(vcpu_vlapic(v)));
> >> > -            ASSERT(intack.source == hvm_intsrc_lapic);
> >> > -            tpr_threshold = intack.vector >> 4;
> >> > -            goto out;
> >> > +            /* Set "Interrupt-window exiting" for ExtINT */
> >> > +            if ( (intblk != hvm_intblk_none) &&
> >> > +                 ( (intack.source == hvm_intsrc_pic) ||
> >> > +                 ( intack.source == hvm_intsrc_vector) ) )
> >> > +            {
> >> > +                enable_intr_window(v, intack);
> >> > +                goto out;
> >> > +            }
> >> > +
> >> > +            if ( __vmread(VM_ENTRY_INTR_INFO) &
> >> INTR_INFO_VALID_MASK )
> >> > +            {
> >> > +                if ( (intack.source == hvm_intsrc_pic) ||
> >> > +                     (intack.source == hvm_intsrc_nmi) ||
> >> > +                     (intack.source == hvm_intsrc_mce) )
> >> > +                    enable_intr_window(v, intack);
> >> > +
> >> > +                goto out;
> >> > +            }
> >> >          }
> >> > +        else
> >> > +        {
> >> > +            if ( intblk == hvm_intblk_tpr )
> >> > +            {
> >> > +                ASSERT(vlapic_enabled(vcpu_vlapic(v)));
> >> > +                ASSERT(intack.source == hvm_intsrc_lapic);
> >> > +                tpr_threshold = intack.vector >> 4;
> >> > +                goto out;
> >> > +            }
> >> >
> >> > -        if ( (intblk != hvm_intblk_none) ||
> >> > -             (__vmread(VM_ENTRY_INTR_INFO) &
> >> INTR_INFO_VALID_MASK) )
> >> > -        {
> >> > -            enable_intr_window(v, intack);
> >> > -            goto out;
> >> > +            if ( (intblk != hvm_intblk_none) ||
> >> > +                 (__vmread(VM_ENTRY_INTR_INFO) &
> >> INTR_INFO_VALID_MASK) )
> >> > +            {
> >> > +                enable_intr_window(v, intack);
> >> > +                goto out;
> >> > +            }
> >> >          }
> >>
> >> If you made the above and if()/else if() series, some of the
> >> differences
> > would go
> >> away, making the changes easier to review.
> > I can't quite understand you here.
> > The original code looked like:
> > if (a)
> > {}
> > if (b)
> > {}
> > And my change as follow:
> > if ( cpu_has_vmx_virtual_intr_delivery ) { } else {
> >   if (a)
> >   {}
> >   if (b)
> >   {}
> > }
> > How should I adjust the code?
> 
> Considering that the original could already have been written with if/else-if, I
> was suggesting to expand this to your addition:
> 
> if ( cpu_has_vmx_virtual_intr_delivery ) { } else if (a)
>   {}
> else if (b)
>   {}
> 
> which will avoid any (indentation only) changes past the first of the two else-if-s.
> Plus it would make the logic of the code more clear, at once likely making
> apparent that there'll now be quite a few "goto out"-s that ought to be check
> for being replaceable by fewer instances of them placed slightly differently.
It is a good suggestion. But the original code is two parallel if() case, not the if/else-if case, and can't be changed to if/else-if case, so I just keep the original code here. :)

> 
> >> > +#define UPDATE_EOI_EXITMAP(v, e)
> {                             \
> >> > +        if (test_and_clear_bit(e, &(v).eoi_exitmap_changed)) {      \
> >>
> >> Here and elsewhere - do you really need locked accesses?
> > Do you mean using the '__test_and_set_bit' ?
> 
> Yes, if suitable.
Since the parameter may also be changed in 'vlapic_set_irq' function, and that function may be called asynchronously, so a lock is needed here.

> >> Furthermore, here and in other places you fail to write the upper
> >> halves for 32-bit, yet you also don't disable the code for 32-bit afaics.
> > OK, __vmwrite(EOI_EXIT_BITMAP##e, (v).eoi_exit_bitmap[e]) ;would be
> >   __vmwrite(EOI_EXIT_BITMAP##e, (v).eoi_exit_bitmap[e]) #ifdef
> > __i386__
> >   __vmwrite(EOI_EXIT_BITMAP##e##_HIGH, (v).eoi_exit_bitmap[e] >> 32)
> > #endif
> 
> Something along those lines, yes.
> 
> Jan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 13 10:14:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Sep 2012 10: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 1TC6Qa-0002is-I0; Thu, 13 Sep 2012 10:13:44 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jiongxi.li@intel.com>) id 1TC6QZ-0002iM-N6
	for xen-devel@lists.xen.org; Thu, 13 Sep 2012 10:13:43 +0000
Received: from [85.158.143.35:7241] by server-2.bemta-4.messagelabs.com id
	9F/C5-21239-7D1B1505; Thu, 13 Sep 2012 10:13:43 +0000
X-Env-Sender: jiongxi.li@intel.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1347531221!12256467!1
X-Originating-IP: [192.55.52.88]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjg4ID0+IDMyMDYxNQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14064 invoked from network); 13 Sep 2012 10:13:41 -0000
Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88)
	by server-7.tower-21.messagelabs.com with SMTP;
	13 Sep 2012 10:13:41 -0000
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
	by fmsmga101.fm.intel.com with ESMTP; 13 Sep 2012 03:13:40 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.80,416,1344236400"; d="scan'208";a="221609398"
Received: from fmsmsx108.amr.corp.intel.com ([10.19.9.228])
	by fmsmga001.fm.intel.com with ESMTP; 13 Sep 2012 03:13:40 -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; Thu, 13 Sep 2012 03:13:40 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.239]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.175]) with mapi id
	14.01.0355.002; Thu, 13 Sep 2012 18:13:38 +0800
From: "Li, Jiongxi" <jiongxi.li@intel.com>
To: "'xen-devel@lists.xen.org'" <xen-devel@lists.xen.org>
Thread-Topic: [ PATCH v2 1/3] xen: enable APIC-Register Virtualization
Thread-Index: Ac2RkdNUAItEv8skTMGgIPKOBOd7Cg==
Date: Thu, 13 Sep 2012 10:13:37 +0000
Message-ID: <D9137FCD9CFF644B965863BCFBEDABB8780466@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: "Zhang, Yang Z" <yang.z.zhang@intel.com>, Keir Fraser <keir@xen.org>,
	"Zhang, 
	Xiantao" <xiantao.zhang@intel.com>, Jan Beulich <JBeulich@suse.com>
Subject: [Xen-devel] [ PATCH v2 1/3] xen: enable APIC-Register Virtualization
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

QWRkIEFQSUMgcmVnaXN0ZXIgdmlydHVhbGl6YXRpb24gc3VwcG9ydA0KoaGhoS0gQVBJQyByZWFk
IGRvZXNuJ3QgY2F1c2UgVk0tRXhpdA0KoaGhoS0gQVBJQyB3cml0ZSBiZWNvbWVzIHRyYXAtbGlr
ZQ0KDQpTaWduZWQtb2ZmLWJ5OiBHYW5nIFdlaSA8Z2FuZy53ZWlAaW50ZWwuY29tPg0KU2lnbmVk
LW9mZi1ieTogWWFuZyBaaGFuZyA8eWFuZy56LnpoYW5nQGludGVsLmNvbT4NClNpZ25lZC1vZmYt
Ynk6IEppb25neGkgTGkgPGppb25neGkubGlAaW50ZWwuY29tPg0KDQoNCmRpZmYgLXIgN2Q3NzBk
ZTkwYjdmIC1yIDdjNjg0NGRkNGEwZCB4ZW4vYXJjaC94ODYvaHZtL3ZsYXBpYy5jDQotLS0gYS94
ZW4vYXJjaC94ODYvaHZtL3ZsYXBpYy5jCU1vbiBTZXAgMTAgMTE6MTM6NTYgMjAxMiArMDEwMA0K
KysrIGIveGVuL2FyY2gveDg2L2h2bS92bGFwaWMuYwlUdWUgU2VwIDExIDE1OjM0OjM2IDIwMTIg
KzA4MDANCkBAIC04MjMsNiArODIzLDE0IEBAIHN0YXRpYyBpbnQgdmxhcGljX3dyaXRlKHN0cnVj
dCB2Y3B1ICp2LCANCiAgICAgcmV0dXJuIHJjOw0KIH0NCiANCitpbnQgdmxhcGljX2FwaWN2X3dy
aXRlKHN0cnVjdCB2Y3B1ICp2LCB1bnNpZ25lZCBpbnQgb2Zmc2V0KQ0KK3sNCisgICAgdWludDMy
X3QgdmFsID0gdmxhcGljX2dldF9yZWcodmNwdV92bGFwaWModiksIG9mZnNldCk7DQorDQorICAg
IHZsYXBpY19yZWdfd3JpdGUodiwgb2Zmc2V0LCB2YWwpOw0KKyAgICByZXR1cm4gMDsNCit9DQor
DQogaW50IGh2bV94MmFwaWNfbXNyX3dyaXRlKHN0cnVjdCB2Y3B1ICp2LCB1bnNpZ25lZCBpbnQg
bXNyLCB1aW50NjRfdCBtc3JfY29udGVudCkNCiB7DQogICAgIHN0cnVjdCB2bGFwaWMgKnZsYXBp
YyA9IHZjcHVfdmxhcGljKHYpOw0KZGlmZiAtciA3ZDc3MGRlOTBiN2YgLXIgN2M2ODQ0ZGQ0YTBk
IHhlbi9hcmNoL3g4Ni9odm0vdm14L3ZtY3MuYw0KLS0tIGEveGVuL2FyY2gveDg2L2h2bS92bXgv
dm1jcy5jCU1vbiBTZXAgMTAgMTE6MTM6NTYgMjAxMiArMDEwMA0KKysrIGIveGVuL2FyY2gveDg2
L2h2bS92bXgvdm1jcy5jCVR1ZSBTZXAgMTEgMTU6MzQ6MzYgMjAxMiArMDgwMA0KQEAgLTg5LDYg
Kzg5LDcgQEAgc3RhdGljIHZvaWQgX19pbml0IHZteF9kaXNwbGF5X2ZlYXR1cmVzKA0KICAgICBQ
KGNwdV9oYXNfdm14X3ZubWksICJWaXJ0dWFsIE5NSSIpOw0KICAgICBQKGNwdV9oYXNfdm14X21z
cl9iaXRtYXAsICJNU1IgZGlyZWN0LWFjY2VzcyBiaXRtYXAiKTsNCiAgICAgUChjcHVfaGFzX3Zt
eF91bnJlc3RyaWN0ZWRfZ3Vlc3QsICJVbnJlc3RyaWN0ZWQgR3Vlc3QiKTsNCisgICAgUChjcHVf
aGFzX3ZteF9hcGljX3JlZ192aXJ0LCAiQVBJQyBSZWdpc3RlciBWaXJ0dWFsaXphdGlvbiIpOw0K
ICN1bmRlZiBQDQogDQogICAgIGlmICggIXByaW50ZWQgKQ0KQEAgLTE4Niw2ICsxODcsMTQgQEAg
c3RhdGljIGludCB2bXhfaW5pdF92bWNzX2NvbmZpZyh2b2lkKQ0KICAgICAgICAgaWYgKCBvcHRf
dW5yZXN0cmljdGVkX2d1ZXN0X2VuYWJsZWQgKQ0KICAgICAgICAgICAgIG9wdCB8PSBTRUNPTkRB
UllfRVhFQ19VTlJFU1RSSUNURURfR1VFU1Q7DQogDQorICAgICAgICAvKg0KKyAgICAgICAgICog
IkFQSUMgUmVnaXN0ZXIgVmlydHVhbGl6YXRpb24iDQorICAgICAgICAgKiBjYW4gYmUgc2V0IG9u
bHkgd2hlbiAidXNlIFRQUiBzaGFkb3ciIGlzIHNldA0KKyAgICAgICAgICovDQorICAgICAgICBp
ZiAoIF92bXhfY3B1X2Jhc2VkX2V4ZWNfY29udHJvbCAmIENQVV9CQVNFRF9UUFJfU0hBRE9XICkN
CisgICAgICAgICAgICBvcHQgfD0gU0VDT05EQVJZX0VYRUNfQVBJQ19SRUdJU1RFUl9WSVJUOw0K
Kw0KKw0KICAgICAgICAgX3ZteF9zZWNvbmRhcnlfZXhlY19jb250cm9sID0gYWRqdXN0X3ZteF9j
b250cm9scygNCiAgICAgICAgICAgICAiU2Vjb25kYXJ5IEV4ZWMgQ29udHJvbCIsIG1pbiwgb3B0
LA0KICAgICAgICAgICAgIE1TUl9JQTMyX1ZNWF9QUk9DQkFTRURfQ1RMUzIsICZtaXNtYXRjaCk7
DQpkaWZmIC1yIDdkNzcwZGU5MGI3ZiAtciA3YzY4NDRkZDRhMGQgeGVuL2FyY2gveDg2L2h2bS92
bXgvdm14LmMNCi0tLSBhL3hlbi9hcmNoL3g4Ni9odm0vdm14L3ZteC5jCU1vbiBTZXAgMTAgMTE6
MTM6NTYgMjAxMiArMDEwMA0KKysrIGIveGVuL2FyY2gveDg2L2h2bS92bXgvdm14LmMJVHVlIFNl
cCAxMSAxNTozNDozNiAyMDEyICswODAwDQpAQCAtMjI3NCw2ICsyMjc0LDE2IEBAIHN0YXRpYyB2
b2lkIHZteF9pZHR2X3JlaW5qZWN0KHVuc2lnbmVkIGwNCiAgICAgfQ0KIH0NCiANCitzdGF0aWMg
aW50IHZteF9oYW5kbGVfYXBpY193cml0ZSh2b2lkKQ0KK3sNCisgICAgdW5zaWduZWQgbG9uZyBl
eGl0X3F1YWxpZmljYXRpb24gPSBfX3ZtcmVhZChFWElUX1FVQUxJRklDQVRJT04pOw0KKyAgICB1
bnNpZ25lZCBpbnQgb2Zmc2V0ID0gZXhpdF9xdWFsaWZpY2F0aW9uICYgMHhmZmY7DQorDQorICAg
IEFTU0VSVChjcHVfaGFzX3ZteF9hcGljX3JlZ192aXJ0KTsNCisNCisgICAgcmV0dXJuIHZsYXBp
Y19hcGljdl93cml0ZShjdXJyZW50LCBvZmZzZXQpOw0KK30NCisNCiB2b2lkIHZteF92bWV4aXRf
aGFuZGxlcihzdHJ1Y3QgY3B1X3VzZXJfcmVncyAqcmVncykNCiB7DQogICAgIHVuc2lnbmVkIGlu
dCBleGl0X3JlYXNvbiwgaWR0dl9pbmZvLCBpbnRyX2luZm8gPSAwLCB2ZWN0b3IgPSAwOw0KQEAg
LTI3MjksNiArMjczOSwxMSBAQCB2b2lkIHZteF92bWV4aXRfaGFuZGxlcihzdHJ1Y3QgY3B1X3Vz
ZXJfDQogICAgICAgICBicmVhazsNCiAgICAgfQ0KIA0KKyAgICBjYXNlIEVYSVRfUkVBU09OX0FQ
SUNfV1JJVEU6DQorICAgICAgICBpZiAoIHZteF9oYW5kbGVfYXBpY193cml0ZSgpICkNCisgICAg
ICAgICAgICBodm1faW5qZWN0X2h3X2V4Y2VwdGlvbihUUkFQX2dwX2ZhdWx0LCAwKTsNCisgICAg
ICAgIGJyZWFrOw0KKw0KICAgICBjYXNlIEVYSVRfUkVBU09OX0FDQ0VTU19HRFRSX09SX0lEVFI6
DQogICAgIGNhc2UgRVhJVF9SRUFTT05fQUNDRVNTX0xEVFJfT1JfVFI6DQogICAgIGNhc2UgRVhJ
VF9SRUFTT05fVk1YX1BSRUVNUFRJT05fVElNRVJfRVhQSVJFRDoNCmRpZmYgLXIgN2Q3NzBkZTkw
YjdmIC1yIDdjNjg0NGRkNGEwZCB4ZW4vaW5jbHVkZS9hc20teDg2L2h2bS92bGFwaWMuaA0KLS0t
IGEveGVuL2luY2x1ZGUvYXNtLXg4Ni9odm0vdmxhcGljLmgJTW9uIFNlcCAxMCAxMToxMzo1NiAy
MDEyICswMTAwDQorKysgYi94ZW4vaW5jbHVkZS9hc20teDg2L2h2bS92bGFwaWMuaAlUdWUgU2Vw
IDExIDE1OjM0OjM2IDIwMTIgKzA4MDANCkBAIC0xMDMsNiArMTAzLDggQEAgdm9pZCB2bGFwaWNf
RU9JX3NldChzdHJ1Y3QgdmxhcGljICp2bGFwaQ0KIA0KIGludCB2bGFwaWNfaXBpKHN0cnVjdCB2
bGFwaWMgKnZsYXBpYywgdWludDMyX3QgaWNyX2xvdywgdWludDMyX3QgaWNyX2hpZ2gpOw0KIA0K
K2ludCB2bGFwaWNfYXBpY3Zfd3JpdGUoc3RydWN0IHZjcHUgKnYsIHVuc2lnbmVkIGludCBvZmZz
ZXQpOw0KKw0KIHN0cnVjdCB2bGFwaWMgKnZsYXBpY19sb3dlc3RfcHJpbygNCiAgICAgc3RydWN0
IGRvbWFpbiAqZCwgc3RydWN0IHZsYXBpYyAqc291cmNlLA0KICAgICBpbnQgc2hvcnRfaGFuZCwg
dWludDhfdCBkZXN0LCB1aW50OF90IGRlc3RfbW9kZSk7DQpkaWZmIC1yIDdkNzcwZGU5MGI3ZiAt
ciA3YzY4NDRkZDRhMGQgeGVuL2luY2x1ZGUvYXNtLXg4Ni9odm0vdm14L3ZtY3MuaA0KLS0tIGEv
eGVuL2luY2x1ZGUvYXNtLXg4Ni9odm0vdm14L3ZtY3MuaAlNb24gU2VwIDEwIDExOjEzOjU2IDIw
MTIgKzAxMDANCisrKyBiL3hlbi9pbmNsdWRlL2FzbS14ODYvaHZtL3ZteC92bWNzLmgJVHVlIFNl
cCAxMSAxNTozNDozNiAyMDEyICswODAwDQpAQCAtMTgyLDYgKzE4Miw3IEBAIGV4dGVybiB1MzIg
dm14X3ZtZW50cnlfY29udHJvbDsNCiAjZGVmaW5lIFNFQ09OREFSWV9FWEVDX0VOQUJMRV9WUElE
ICAgICAgICAgICAgICAweDAwMDAwMDIwDQogI2RlZmluZSBTRUNPTkRBUllfRVhFQ19XQklOVkRf
RVhJVElORyAgICAgICAgICAgMHgwMDAwMDA0MA0KICNkZWZpbmUgU0VDT05EQVJZX0VYRUNfVU5S
RVNUUklDVEVEX0dVRVNUICAgICAgIDB4MDAwMDAwODANCisjZGVmaW5lIFNFQ09OREFSWV9FWEVD
X0FQSUNfUkVHSVNURVJfVklSVCAgICAgICAweDAwMDAwMTAwDQogI2RlZmluZSBTRUNPTkRBUllf
RVhFQ19QQVVTRV9MT09QX0VYSVRJTkcgICAgICAgMHgwMDAwMDQwMA0KICNkZWZpbmUgU0VDT05E
QVJZX0VYRUNfRU5BQkxFX0lOVlBDSUQgICAgICAgICAgIDB4MDAwMDEwMDANCiBleHRlcm4gdTMy
IHZteF9zZWNvbmRhcnlfZXhlY19jb250cm9sOw0KQEAgLTIzMCw2ICsyMzEsOCBAQCBleHRlcm4g
Ym9vbF90IGNwdV9oYXNfdm14X2luc19vdXRzX2luc3RyDQogICAgICBTRUNPTkRBUllfRVhFQ19V
TlJFU1RSSUNURURfR1VFU1QpDQogI2RlZmluZSBjcHVfaGFzX3ZteF9wbGUgXA0KICAgICAodm14
X3NlY29uZGFyeV9leGVjX2NvbnRyb2wgJiBTRUNPTkRBUllfRVhFQ19QQVVTRV9MT09QX0VYSVRJ
TkcpDQorI2RlZmluZSBjcHVfaGFzX3ZteF9hcGljX3JlZ192aXJ0IFwNCisgICAgKHZteF9zZWNv
bmRhcnlfZXhlY19jb250cm9sICYgU0VDT05EQVJZX0VYRUNfQVBJQ19SRUdJU1RFUl9WSVJUKQ0K
IA0KIC8qIEdVRVNUX0lOVEVSUlVQVElCSUxJVFlfSU5GTyBmbGFncy4gKi8NCiAjZGVmaW5lIFZN
WF9JTlRSX1NIQURPV19TVEkgICAgICAgICAgICAgMHgwMDAwMDAwMQ0KZGlmZiAtciA3ZDc3MGRl
OTBiN2YgLXIgN2M2ODQ0ZGQ0YTBkIHhlbi9pbmNsdWRlL2FzbS14ODYvaHZtL3ZteC92bXguaA0K
LS0tIGEveGVuL2luY2x1ZGUvYXNtLXg4Ni9odm0vdm14L3ZteC5oCU1vbiBTZXAgMTAgMTE6MTM6
NTYgMjAxMiArMDEwMA0KKysrIGIveGVuL2luY2x1ZGUvYXNtLXg4Ni9odm0vdm14L3ZteC5oCVR1
ZSBTZXAgMTEgMTU6MzQ6MzYgMjAxMiArMDgwMA0KQEAgLTEyOSw2ICsxMjksNyBAQCB2b2lkIHZt
eF91cGRhdGVfY3B1X2V4ZWNfY29udHJvbChzdHJ1Y3QgDQogI2RlZmluZSBFWElUX1JFQVNPTl9J
TlZWUElEICAgICAgICAgICAgIDUzDQogI2RlZmluZSBFWElUX1JFQVNPTl9XQklOVkQgICAgICAg
ICAgICAgIDU0DQogI2RlZmluZSBFWElUX1JFQVNPTl9YU0VUQlYgICAgICAgICAgICAgIDU1DQor
I2RlZmluZSBFWElUX1JFQVNPTl9BUElDX1dSSVRFICAgICAgICAgIDU2DQogI2RlZmluZSBFWElU
X1JFQVNPTl9JTlZQQ0lEICAgICAgICAgICAgIDU4DQogDQogLyoNCl9fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVu
LWRldmVsQGxpc3RzLnhlbi5vcmcKaHR0cDovL2xpc3RzLnhlbi5vcmcveGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Thu Sep 13 10:14:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Sep 2012 10: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 1TC6Qa-0002is-I0; Thu, 13 Sep 2012 10:13:44 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jiongxi.li@intel.com>) id 1TC6QZ-0002iM-N6
	for xen-devel@lists.xen.org; Thu, 13 Sep 2012 10:13:43 +0000
Received: from [85.158.143.35:7241] by server-2.bemta-4.messagelabs.com id
	9F/C5-21239-7D1B1505; Thu, 13 Sep 2012 10:13:43 +0000
X-Env-Sender: jiongxi.li@intel.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1347531221!12256467!1
X-Originating-IP: [192.55.52.88]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjg4ID0+IDMyMDYxNQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14064 invoked from network); 13 Sep 2012 10:13:41 -0000
Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88)
	by server-7.tower-21.messagelabs.com with SMTP;
	13 Sep 2012 10:13:41 -0000
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
	by fmsmga101.fm.intel.com with ESMTP; 13 Sep 2012 03:13:40 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.80,416,1344236400"; d="scan'208";a="221609398"
Received: from fmsmsx108.amr.corp.intel.com ([10.19.9.228])
	by fmsmga001.fm.intel.com with ESMTP; 13 Sep 2012 03:13:40 -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; Thu, 13 Sep 2012 03:13:40 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.239]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.175]) with mapi id
	14.01.0355.002; Thu, 13 Sep 2012 18:13:38 +0800
From: "Li, Jiongxi" <jiongxi.li@intel.com>
To: "'xen-devel@lists.xen.org'" <xen-devel@lists.xen.org>
Thread-Topic: [ PATCH v2 1/3] xen: enable APIC-Register Virtualization
Thread-Index: Ac2RkdNUAItEv8skTMGgIPKOBOd7Cg==
Date: Thu, 13 Sep 2012 10:13:37 +0000
Message-ID: <D9137FCD9CFF644B965863BCFBEDABB8780466@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: "Zhang, Yang Z" <yang.z.zhang@intel.com>, Keir Fraser <keir@xen.org>,
	"Zhang, 
	Xiantao" <xiantao.zhang@intel.com>, Jan Beulich <JBeulich@suse.com>
Subject: [Xen-devel] [ PATCH v2 1/3] xen: enable APIC-Register Virtualization
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

QWRkIEFQSUMgcmVnaXN0ZXIgdmlydHVhbGl6YXRpb24gc3VwcG9ydA0KoaGhoS0gQVBJQyByZWFk
IGRvZXNuJ3QgY2F1c2UgVk0tRXhpdA0KoaGhoS0gQVBJQyB3cml0ZSBiZWNvbWVzIHRyYXAtbGlr
ZQ0KDQpTaWduZWQtb2ZmLWJ5OiBHYW5nIFdlaSA8Z2FuZy53ZWlAaW50ZWwuY29tPg0KU2lnbmVk
LW9mZi1ieTogWWFuZyBaaGFuZyA8eWFuZy56LnpoYW5nQGludGVsLmNvbT4NClNpZ25lZC1vZmYt
Ynk6IEppb25neGkgTGkgPGppb25neGkubGlAaW50ZWwuY29tPg0KDQoNCmRpZmYgLXIgN2Q3NzBk
ZTkwYjdmIC1yIDdjNjg0NGRkNGEwZCB4ZW4vYXJjaC94ODYvaHZtL3ZsYXBpYy5jDQotLS0gYS94
ZW4vYXJjaC94ODYvaHZtL3ZsYXBpYy5jCU1vbiBTZXAgMTAgMTE6MTM6NTYgMjAxMiArMDEwMA0K
KysrIGIveGVuL2FyY2gveDg2L2h2bS92bGFwaWMuYwlUdWUgU2VwIDExIDE1OjM0OjM2IDIwMTIg
KzA4MDANCkBAIC04MjMsNiArODIzLDE0IEBAIHN0YXRpYyBpbnQgdmxhcGljX3dyaXRlKHN0cnVj
dCB2Y3B1ICp2LCANCiAgICAgcmV0dXJuIHJjOw0KIH0NCiANCitpbnQgdmxhcGljX2FwaWN2X3dy
aXRlKHN0cnVjdCB2Y3B1ICp2LCB1bnNpZ25lZCBpbnQgb2Zmc2V0KQ0KK3sNCisgICAgdWludDMy
X3QgdmFsID0gdmxhcGljX2dldF9yZWcodmNwdV92bGFwaWModiksIG9mZnNldCk7DQorDQorICAg
IHZsYXBpY19yZWdfd3JpdGUodiwgb2Zmc2V0LCB2YWwpOw0KKyAgICByZXR1cm4gMDsNCit9DQor
DQogaW50IGh2bV94MmFwaWNfbXNyX3dyaXRlKHN0cnVjdCB2Y3B1ICp2LCB1bnNpZ25lZCBpbnQg
bXNyLCB1aW50NjRfdCBtc3JfY29udGVudCkNCiB7DQogICAgIHN0cnVjdCB2bGFwaWMgKnZsYXBp
YyA9IHZjcHVfdmxhcGljKHYpOw0KZGlmZiAtciA3ZDc3MGRlOTBiN2YgLXIgN2M2ODQ0ZGQ0YTBk
IHhlbi9hcmNoL3g4Ni9odm0vdm14L3ZtY3MuYw0KLS0tIGEveGVuL2FyY2gveDg2L2h2bS92bXgv
dm1jcy5jCU1vbiBTZXAgMTAgMTE6MTM6NTYgMjAxMiArMDEwMA0KKysrIGIveGVuL2FyY2gveDg2
L2h2bS92bXgvdm1jcy5jCVR1ZSBTZXAgMTEgMTU6MzQ6MzYgMjAxMiArMDgwMA0KQEAgLTg5LDYg
Kzg5LDcgQEAgc3RhdGljIHZvaWQgX19pbml0IHZteF9kaXNwbGF5X2ZlYXR1cmVzKA0KICAgICBQ
KGNwdV9oYXNfdm14X3ZubWksICJWaXJ0dWFsIE5NSSIpOw0KICAgICBQKGNwdV9oYXNfdm14X21z
cl9iaXRtYXAsICJNU1IgZGlyZWN0LWFjY2VzcyBiaXRtYXAiKTsNCiAgICAgUChjcHVfaGFzX3Zt
eF91bnJlc3RyaWN0ZWRfZ3Vlc3QsICJVbnJlc3RyaWN0ZWQgR3Vlc3QiKTsNCisgICAgUChjcHVf
aGFzX3ZteF9hcGljX3JlZ192aXJ0LCAiQVBJQyBSZWdpc3RlciBWaXJ0dWFsaXphdGlvbiIpOw0K
ICN1bmRlZiBQDQogDQogICAgIGlmICggIXByaW50ZWQgKQ0KQEAgLTE4Niw2ICsxODcsMTQgQEAg
c3RhdGljIGludCB2bXhfaW5pdF92bWNzX2NvbmZpZyh2b2lkKQ0KICAgICAgICAgaWYgKCBvcHRf
dW5yZXN0cmljdGVkX2d1ZXN0X2VuYWJsZWQgKQ0KICAgICAgICAgICAgIG9wdCB8PSBTRUNPTkRB
UllfRVhFQ19VTlJFU1RSSUNURURfR1VFU1Q7DQogDQorICAgICAgICAvKg0KKyAgICAgICAgICog
IkFQSUMgUmVnaXN0ZXIgVmlydHVhbGl6YXRpb24iDQorICAgICAgICAgKiBjYW4gYmUgc2V0IG9u
bHkgd2hlbiAidXNlIFRQUiBzaGFkb3ciIGlzIHNldA0KKyAgICAgICAgICovDQorICAgICAgICBp
ZiAoIF92bXhfY3B1X2Jhc2VkX2V4ZWNfY29udHJvbCAmIENQVV9CQVNFRF9UUFJfU0hBRE9XICkN
CisgICAgICAgICAgICBvcHQgfD0gU0VDT05EQVJZX0VYRUNfQVBJQ19SRUdJU1RFUl9WSVJUOw0K
Kw0KKw0KICAgICAgICAgX3ZteF9zZWNvbmRhcnlfZXhlY19jb250cm9sID0gYWRqdXN0X3ZteF9j
b250cm9scygNCiAgICAgICAgICAgICAiU2Vjb25kYXJ5IEV4ZWMgQ29udHJvbCIsIG1pbiwgb3B0
LA0KICAgICAgICAgICAgIE1TUl9JQTMyX1ZNWF9QUk9DQkFTRURfQ1RMUzIsICZtaXNtYXRjaCk7
DQpkaWZmIC1yIDdkNzcwZGU5MGI3ZiAtciA3YzY4NDRkZDRhMGQgeGVuL2FyY2gveDg2L2h2bS92
bXgvdm14LmMNCi0tLSBhL3hlbi9hcmNoL3g4Ni9odm0vdm14L3ZteC5jCU1vbiBTZXAgMTAgMTE6
MTM6NTYgMjAxMiArMDEwMA0KKysrIGIveGVuL2FyY2gveDg2L2h2bS92bXgvdm14LmMJVHVlIFNl
cCAxMSAxNTozNDozNiAyMDEyICswODAwDQpAQCAtMjI3NCw2ICsyMjc0LDE2IEBAIHN0YXRpYyB2
b2lkIHZteF9pZHR2X3JlaW5qZWN0KHVuc2lnbmVkIGwNCiAgICAgfQ0KIH0NCiANCitzdGF0aWMg
aW50IHZteF9oYW5kbGVfYXBpY193cml0ZSh2b2lkKQ0KK3sNCisgICAgdW5zaWduZWQgbG9uZyBl
eGl0X3F1YWxpZmljYXRpb24gPSBfX3ZtcmVhZChFWElUX1FVQUxJRklDQVRJT04pOw0KKyAgICB1
bnNpZ25lZCBpbnQgb2Zmc2V0ID0gZXhpdF9xdWFsaWZpY2F0aW9uICYgMHhmZmY7DQorDQorICAg
IEFTU0VSVChjcHVfaGFzX3ZteF9hcGljX3JlZ192aXJ0KTsNCisNCisgICAgcmV0dXJuIHZsYXBp
Y19hcGljdl93cml0ZShjdXJyZW50LCBvZmZzZXQpOw0KK30NCisNCiB2b2lkIHZteF92bWV4aXRf
aGFuZGxlcihzdHJ1Y3QgY3B1X3VzZXJfcmVncyAqcmVncykNCiB7DQogICAgIHVuc2lnbmVkIGlu
dCBleGl0X3JlYXNvbiwgaWR0dl9pbmZvLCBpbnRyX2luZm8gPSAwLCB2ZWN0b3IgPSAwOw0KQEAg
LTI3MjksNiArMjczOSwxMSBAQCB2b2lkIHZteF92bWV4aXRfaGFuZGxlcihzdHJ1Y3QgY3B1X3Vz
ZXJfDQogICAgICAgICBicmVhazsNCiAgICAgfQ0KIA0KKyAgICBjYXNlIEVYSVRfUkVBU09OX0FQ
SUNfV1JJVEU6DQorICAgICAgICBpZiAoIHZteF9oYW5kbGVfYXBpY193cml0ZSgpICkNCisgICAg
ICAgICAgICBodm1faW5qZWN0X2h3X2V4Y2VwdGlvbihUUkFQX2dwX2ZhdWx0LCAwKTsNCisgICAg
ICAgIGJyZWFrOw0KKw0KICAgICBjYXNlIEVYSVRfUkVBU09OX0FDQ0VTU19HRFRSX09SX0lEVFI6
DQogICAgIGNhc2UgRVhJVF9SRUFTT05fQUNDRVNTX0xEVFJfT1JfVFI6DQogICAgIGNhc2UgRVhJ
VF9SRUFTT05fVk1YX1BSRUVNUFRJT05fVElNRVJfRVhQSVJFRDoNCmRpZmYgLXIgN2Q3NzBkZTkw
YjdmIC1yIDdjNjg0NGRkNGEwZCB4ZW4vaW5jbHVkZS9hc20teDg2L2h2bS92bGFwaWMuaA0KLS0t
IGEveGVuL2luY2x1ZGUvYXNtLXg4Ni9odm0vdmxhcGljLmgJTW9uIFNlcCAxMCAxMToxMzo1NiAy
MDEyICswMTAwDQorKysgYi94ZW4vaW5jbHVkZS9hc20teDg2L2h2bS92bGFwaWMuaAlUdWUgU2Vw
IDExIDE1OjM0OjM2IDIwMTIgKzA4MDANCkBAIC0xMDMsNiArMTAzLDggQEAgdm9pZCB2bGFwaWNf
RU9JX3NldChzdHJ1Y3QgdmxhcGljICp2bGFwaQ0KIA0KIGludCB2bGFwaWNfaXBpKHN0cnVjdCB2
bGFwaWMgKnZsYXBpYywgdWludDMyX3QgaWNyX2xvdywgdWludDMyX3QgaWNyX2hpZ2gpOw0KIA0K
K2ludCB2bGFwaWNfYXBpY3Zfd3JpdGUoc3RydWN0IHZjcHUgKnYsIHVuc2lnbmVkIGludCBvZmZz
ZXQpOw0KKw0KIHN0cnVjdCB2bGFwaWMgKnZsYXBpY19sb3dlc3RfcHJpbygNCiAgICAgc3RydWN0
IGRvbWFpbiAqZCwgc3RydWN0IHZsYXBpYyAqc291cmNlLA0KICAgICBpbnQgc2hvcnRfaGFuZCwg
dWludDhfdCBkZXN0LCB1aW50OF90IGRlc3RfbW9kZSk7DQpkaWZmIC1yIDdkNzcwZGU5MGI3ZiAt
ciA3YzY4NDRkZDRhMGQgeGVuL2luY2x1ZGUvYXNtLXg4Ni9odm0vdm14L3ZtY3MuaA0KLS0tIGEv
eGVuL2luY2x1ZGUvYXNtLXg4Ni9odm0vdm14L3ZtY3MuaAlNb24gU2VwIDEwIDExOjEzOjU2IDIw
MTIgKzAxMDANCisrKyBiL3hlbi9pbmNsdWRlL2FzbS14ODYvaHZtL3ZteC92bWNzLmgJVHVlIFNl
cCAxMSAxNTozNDozNiAyMDEyICswODAwDQpAQCAtMTgyLDYgKzE4Miw3IEBAIGV4dGVybiB1MzIg
dm14X3ZtZW50cnlfY29udHJvbDsNCiAjZGVmaW5lIFNFQ09OREFSWV9FWEVDX0VOQUJMRV9WUElE
ICAgICAgICAgICAgICAweDAwMDAwMDIwDQogI2RlZmluZSBTRUNPTkRBUllfRVhFQ19XQklOVkRf
RVhJVElORyAgICAgICAgICAgMHgwMDAwMDA0MA0KICNkZWZpbmUgU0VDT05EQVJZX0VYRUNfVU5S
RVNUUklDVEVEX0dVRVNUICAgICAgIDB4MDAwMDAwODANCisjZGVmaW5lIFNFQ09OREFSWV9FWEVD
X0FQSUNfUkVHSVNURVJfVklSVCAgICAgICAweDAwMDAwMTAwDQogI2RlZmluZSBTRUNPTkRBUllf
RVhFQ19QQVVTRV9MT09QX0VYSVRJTkcgICAgICAgMHgwMDAwMDQwMA0KICNkZWZpbmUgU0VDT05E
QVJZX0VYRUNfRU5BQkxFX0lOVlBDSUQgICAgICAgICAgIDB4MDAwMDEwMDANCiBleHRlcm4gdTMy
IHZteF9zZWNvbmRhcnlfZXhlY19jb250cm9sOw0KQEAgLTIzMCw2ICsyMzEsOCBAQCBleHRlcm4g
Ym9vbF90IGNwdV9oYXNfdm14X2luc19vdXRzX2luc3RyDQogICAgICBTRUNPTkRBUllfRVhFQ19V
TlJFU1RSSUNURURfR1VFU1QpDQogI2RlZmluZSBjcHVfaGFzX3ZteF9wbGUgXA0KICAgICAodm14
X3NlY29uZGFyeV9leGVjX2NvbnRyb2wgJiBTRUNPTkRBUllfRVhFQ19QQVVTRV9MT09QX0VYSVRJ
TkcpDQorI2RlZmluZSBjcHVfaGFzX3ZteF9hcGljX3JlZ192aXJ0IFwNCisgICAgKHZteF9zZWNv
bmRhcnlfZXhlY19jb250cm9sICYgU0VDT05EQVJZX0VYRUNfQVBJQ19SRUdJU1RFUl9WSVJUKQ0K
IA0KIC8qIEdVRVNUX0lOVEVSUlVQVElCSUxJVFlfSU5GTyBmbGFncy4gKi8NCiAjZGVmaW5lIFZN
WF9JTlRSX1NIQURPV19TVEkgICAgICAgICAgICAgMHgwMDAwMDAwMQ0KZGlmZiAtciA3ZDc3MGRl
OTBiN2YgLXIgN2M2ODQ0ZGQ0YTBkIHhlbi9pbmNsdWRlL2FzbS14ODYvaHZtL3ZteC92bXguaA0K
LS0tIGEveGVuL2luY2x1ZGUvYXNtLXg4Ni9odm0vdm14L3ZteC5oCU1vbiBTZXAgMTAgMTE6MTM6
NTYgMjAxMiArMDEwMA0KKysrIGIveGVuL2luY2x1ZGUvYXNtLXg4Ni9odm0vdm14L3ZteC5oCVR1
ZSBTZXAgMTEgMTU6MzQ6MzYgMjAxMiArMDgwMA0KQEAgLTEyOSw2ICsxMjksNyBAQCB2b2lkIHZt
eF91cGRhdGVfY3B1X2V4ZWNfY29udHJvbChzdHJ1Y3QgDQogI2RlZmluZSBFWElUX1JFQVNPTl9J
TlZWUElEICAgICAgICAgICAgIDUzDQogI2RlZmluZSBFWElUX1JFQVNPTl9XQklOVkQgICAgICAg
ICAgICAgIDU0DQogI2RlZmluZSBFWElUX1JFQVNPTl9YU0VUQlYgICAgICAgICAgICAgIDU1DQor
I2RlZmluZSBFWElUX1JFQVNPTl9BUElDX1dSSVRFICAgICAgICAgIDU2DQogI2RlZmluZSBFWElU
X1JFQVNPTl9JTlZQQ0lEICAgICAgICAgICAgIDU4DQogDQogLyoNCl9fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVu
LWRldmVsQGxpc3RzLnhlbi5vcmcKaHR0cDovL2xpc3RzLnhlbi5vcmcveGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Thu Sep 13 10:14:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Sep 2012 10: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 1TC6Ql-0002nL-Pr; Thu, 13 Sep 2012 10:13:55 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jiongxi.li@intel.com>) id 1TC6Qk-0002kr-TG
	for xen-devel@lists.xen.org; Thu, 13 Sep 2012 10:13:55 +0000
Received: from [85.158.138.51:49120] by server-3.bemta-3.messagelabs.com id
	05/BF-21322-2E1B1505; Thu, 13 Sep 2012 10:13:54 +0000
X-Env-Sender: jiongxi.li@intel.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1347531226!26289670!2
X-Originating-IP: [134.134.136.24]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjQgPT4gMzQxNTMy\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15824 invoked from network); 13 Sep 2012 10:13:53 -0000
Received: from mga09.intel.com (HELO mga09.intel.com) (134.134.136.24)
	by server-10.tower-174.messagelabs.com with SMTP;
	13 Sep 2012 10:13:53 -0000
Received: from orsmga001.jf.intel.com ([10.7.209.18])
	by orsmga102.jf.intel.com with ESMTP; 13 Sep 2012 03:13:44 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.80,416,1344236400"; d="scan'208";a="192472330"
Received: from fmsmsx105.amr.corp.intel.com ([10.19.9.36])
	by orsmga001.jf.intel.com with ESMTP; 13 Sep 2012 03:13:52 -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; Thu, 13 Sep 2012 03:13:52 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.239]) by
	SHSMSX102.ccr.corp.intel.com ([169.254.2.92]) with mapi id
	14.01.0355.002; Thu, 13 Sep 2012 18:13:50 +0800
From: "Li, Jiongxi" <jiongxi.li@intel.com>
To: "'xen-devel@lists.xen.org'" <xen-devel@lists.xen.org>
Thread-Topic: [ PATCH v2 3/3] xen: add virtual x2apic support fro apicv
Thread-Index: Ac2RlDWb/BmGF9t6ShOGOr7Nx4TjHw==
Date: Thu, 13 Sep 2012 10:13:49 +0000
Message-ID: <D9137FCD9CFF644B965863BCFBEDABB8780470@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: "Zhang, Yang Z" <yang.z.zhang@intel.com>, Keir Fraser <keir@xen.org>,
	"Zhang, 
	Xiantao" <xiantao.zhang@intel.com>, Jan Beulich <JBeulich@suse.com>
Subject: [Xen-devel] [ PATCH v2 3/3] xen: add virtual x2apic support fro
	apicv
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Add virtual x2apic support for apicv
    basically to benefit from apicv, we need clear MSR bitmap for
    corresponding x2apic MSRs:
    	0x800 - 0x8ff: no read intercept for apicv register virtualization
    	TPR,EOI,SELF-IPI: no write intercept for virtual interrupt delivery

Signed-off-by: Jiongxi Li <jiongxi.li@intel.com>


diff -r ad93baf90deb xen/arch/x86/hvm/vmx/vmcs.c
--- a/xen/arch/x86/hvm/vmx/vmcs.c	Wed Sep 12 14:53:06 2012 +0800
+++ b/xen/arch/x86/hvm/vmx/vmcs.c	Wed Sep 12 18:40:34 2012 +0800
@@ -658,7 +658,7 @@ static void vmx_set_host_env(struct vcpu
               (unsigned long)&get_cpu_info()->guest_cpu_user_regs.error_code);
 }
 
-void vmx_disable_intercept_for_msr(struct vcpu *v, u32 msr)
+void vmx_disable_intercept_for_msr(struct vcpu *v, u32 msr, int type)
 {
     unsigned long *msr_bitmap = v->arch.hvm_vmx.msr_bitmap;
 
@@ -673,14 +673,18 @@ void vmx_disable_intercept_for_msr(struc
      */
     if ( msr <= 0x1fff )
     {
-        __clear_bit(msr, msr_bitmap + 0x000/BYTES_PER_LONG); /* read-low */
-        __clear_bit(msr, msr_bitmap + 0x800/BYTES_PER_LONG); /* write-low */
+        if (type & MSR_TYPE_R)
+            __clear_bit(msr, msr_bitmap + 0x000/BYTES_PER_LONG); /* read-low */
+        if (type & MSR_TYPE_W)
+            __clear_bit(msr, msr_bitmap + 0x800/BYTES_PER_LONG); /* write-low */
     }
     else if ( (msr >= 0xc0000000) && (msr <= 0xc0001fff) )
     {
         msr &= 0x1fff;
-        __clear_bit(msr, msr_bitmap + 0x400/BYTES_PER_LONG); /* read-high */
-        __clear_bit(msr, msr_bitmap + 0xc00/BYTES_PER_LONG); /* write-high */
+        if (type & MSR_TYPE_R)
+            __clear_bit(msr, msr_bitmap + 0x400/BYTES_PER_LONG); /* read-high */
+        if (type & MSR_TYPE_W)
+            __clear_bit(msr, msr_bitmap + 0xc00/BYTES_PER_LONG); /* write-high */
     }
 }
 
@@ -776,13 +780,25 @@ static int construct_vmcs(struct vcpu *v
         v->arch.hvm_vmx.msr_bitmap = msr_bitmap;
         __vmwrite(MSR_BITMAP, virt_to_maddr(msr_bitmap));
 
-        vmx_disable_intercept_for_msr(v, MSR_FS_BASE);
-        vmx_disable_intercept_for_msr(v, MSR_GS_BASE);
-        vmx_disable_intercept_for_msr(v, MSR_IA32_SYSENTER_CS);
-        vmx_disable_intercept_for_msr(v, MSR_IA32_SYSENTER_ESP);
-        vmx_disable_intercept_for_msr(v, MSR_IA32_SYSENTER_EIP);
+        vmx_disable_intercept_for_msr(v, MSR_FS_BASE, MSR_TYPE_R | MSR_TYPE_W);
+        vmx_disable_intercept_for_msr(v, MSR_GS_BASE, MSR_TYPE_R | MSR_TYPE_W);
+        vmx_disable_intercept_for_msr(v, MSR_IA32_SYSENTER_CS, MSR_TYPE_R | MSR_TYPE_W);
+        vmx_disable_intercept_for_msr(v, MSR_IA32_SYSENTER_ESP, MSR_TYPE_R | MSR_TYPE_W);
+        vmx_disable_intercept_for_msr(v, MSR_IA32_SYSENTER_EIP, MSR_TYPE_R | MSR_TYPE_W);
         if ( cpu_has_vmx_pat && paging_mode_hap(d) )
-            vmx_disable_intercept_for_msr(v, MSR_IA32_CR_PAT);
+            vmx_disable_intercept_for_msr(v, MSR_IA32_CR_PAT, MSR_TYPE_R | MSR_TYPE_W);
+        if ( cpu_has_vmx_apic_reg_virt )
+        {
+            int msr;
+            for (msr = MSR_IA32_APICBASE_MSR; msr <= MSR_IA32_APICBASE_MSR + 0xff; msr++)
+                vmx_disable_intercept_for_msr(v, msr, MSR_TYPE_R);
+        }
+        if ( cpu_has_vmx_virtual_intr_delivery )
+        {
+            vmx_disable_intercept_for_msr(v, MSR_IA32_APICTPR_MSR, MSR_TYPE_W);
+            vmx_disable_intercept_for_msr(v, MSR_IA32_APICEOI_MSR, MSR_TYPE_W);
+            vmx_disable_intercept_for_msr(v, MSR_IA32_APICSELF_MSR, MSR_TYPE_W);
+        }
     }
 
     /* I/O access bitmap. */
diff -r ad93baf90deb xen/arch/x86/hvm/vmx/vmx.c
--- a/xen/arch/x86/hvm/vmx/vmx.c	Wed Sep 12 14:53:06 2012 +0800
+++ b/xen/arch/x86/hvm/vmx/vmx.c	Wed Sep 12 18:40:34 2012 +0800
@@ -2036,7 +2036,7 @@ static int vmx_msr_write_intercept(unsig
             for ( ; (rc == 0) && lbr->count; lbr++ )
                 for ( i = 0; (rc == 0) && (i < lbr->count); i++ )
                     if ( (rc = vmx_add_guest_msr(lbr->base + i)) == 0 )
-                        vmx_disable_intercept_for_msr(v, lbr->base + i);
+                        vmx_disable_intercept_for_msr(v, lbr->base + i, MSR_TYPE_R | MSR_TYPE_W);
         }
 
         if ( (rc < 0) ||
diff -r ad93baf90deb xen/include/asm-x86/hvm/vmx/vmcs.h
--- a/xen/include/asm-x86/hvm/vmx/vmcs.h	Wed Sep 12 14:53:06 2012 +0800
+++ b/xen/include/asm-x86/hvm/vmx/vmcs.h	Wed Sep 12 18:40:34 2012 +0800
@@ -407,7 +407,9 @@ enum vmcs_field {
 
 #define VMCS_VPID_WIDTH 16
 
-void vmx_disable_intercept_for_msr(struct vcpu *v, u32 msr);
+#define MSR_TYPE_R 1
+#define MSR_TYPE_W 2
+void vmx_disable_intercept_for_msr(struct vcpu *v, u32 msr, int type);
 int vmx_read_guest_msr(u32 msr, u64 *val);
 int vmx_write_guest_msr(u32 msr, u64 val);
 int vmx_add_guest_msr(u32 msr);
diff -r ad93baf90deb xen/include/asm-x86/msr-index.h
--- a/xen/include/asm-x86/msr-index.h	Wed Sep 12 14:53:06 2012 +0800
+++ b/xen/include/asm-x86/msr-index.h	Wed Sep 12 18:40:34 2012 +0800
@@ -291,6 +291,9 @@
 #define MSR_IA32_APICBASE_ENABLE	(1<<11)
 #define MSR_IA32_APICBASE_BASE		(0xfffff<<12)
 #define MSR_IA32_APICBASE_MSR           0x800
+#define MSR_IA32_APICTPR_MSR            0x808
+#define MSR_IA32_APICEOI_MSR            0x80b
+#define MSR_IA32_APICSELF_MSR           0x83f
 
 #define MSR_IA32_UCODE_WRITE		0x00000079
 #define MSR_IA32_UCODE_REV		0x0000008b

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 13 10:14:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Sep 2012 10: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 1TC6Ql-0002nL-Pr; Thu, 13 Sep 2012 10:13:55 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jiongxi.li@intel.com>) id 1TC6Qk-0002kr-TG
	for xen-devel@lists.xen.org; Thu, 13 Sep 2012 10:13:55 +0000
Received: from [85.158.138.51:49120] by server-3.bemta-3.messagelabs.com id
	05/BF-21322-2E1B1505; Thu, 13 Sep 2012 10:13:54 +0000
X-Env-Sender: jiongxi.li@intel.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1347531226!26289670!2
X-Originating-IP: [134.134.136.24]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjQgPT4gMzQxNTMy\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15824 invoked from network); 13 Sep 2012 10:13:53 -0000
Received: from mga09.intel.com (HELO mga09.intel.com) (134.134.136.24)
	by server-10.tower-174.messagelabs.com with SMTP;
	13 Sep 2012 10:13:53 -0000
Received: from orsmga001.jf.intel.com ([10.7.209.18])
	by orsmga102.jf.intel.com with ESMTP; 13 Sep 2012 03:13:44 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.80,416,1344236400"; d="scan'208";a="192472330"
Received: from fmsmsx105.amr.corp.intel.com ([10.19.9.36])
	by orsmga001.jf.intel.com with ESMTP; 13 Sep 2012 03:13:52 -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; Thu, 13 Sep 2012 03:13:52 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.239]) by
	SHSMSX102.ccr.corp.intel.com ([169.254.2.92]) with mapi id
	14.01.0355.002; Thu, 13 Sep 2012 18:13:50 +0800
From: "Li, Jiongxi" <jiongxi.li@intel.com>
To: "'xen-devel@lists.xen.org'" <xen-devel@lists.xen.org>
Thread-Topic: [ PATCH v2 3/3] xen: add virtual x2apic support fro apicv
Thread-Index: Ac2RlDWb/BmGF9t6ShOGOr7Nx4TjHw==
Date: Thu, 13 Sep 2012 10:13:49 +0000
Message-ID: <D9137FCD9CFF644B965863BCFBEDABB8780470@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: "Zhang, Yang Z" <yang.z.zhang@intel.com>, Keir Fraser <keir@xen.org>,
	"Zhang, 
	Xiantao" <xiantao.zhang@intel.com>, Jan Beulich <JBeulich@suse.com>
Subject: [Xen-devel] [ PATCH v2 3/3] xen: add virtual x2apic support fro
	apicv
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Add virtual x2apic support for apicv
    basically to benefit from apicv, we need clear MSR bitmap for
    corresponding x2apic MSRs:
    	0x800 - 0x8ff: no read intercept for apicv register virtualization
    	TPR,EOI,SELF-IPI: no write intercept for virtual interrupt delivery

Signed-off-by: Jiongxi Li <jiongxi.li@intel.com>


diff -r ad93baf90deb xen/arch/x86/hvm/vmx/vmcs.c
--- a/xen/arch/x86/hvm/vmx/vmcs.c	Wed Sep 12 14:53:06 2012 +0800
+++ b/xen/arch/x86/hvm/vmx/vmcs.c	Wed Sep 12 18:40:34 2012 +0800
@@ -658,7 +658,7 @@ static void vmx_set_host_env(struct vcpu
               (unsigned long)&get_cpu_info()->guest_cpu_user_regs.error_code);
 }
 
-void vmx_disable_intercept_for_msr(struct vcpu *v, u32 msr)
+void vmx_disable_intercept_for_msr(struct vcpu *v, u32 msr, int type)
 {
     unsigned long *msr_bitmap = v->arch.hvm_vmx.msr_bitmap;
 
@@ -673,14 +673,18 @@ void vmx_disable_intercept_for_msr(struc
      */
     if ( msr <= 0x1fff )
     {
-        __clear_bit(msr, msr_bitmap + 0x000/BYTES_PER_LONG); /* read-low */
-        __clear_bit(msr, msr_bitmap + 0x800/BYTES_PER_LONG); /* write-low */
+        if (type & MSR_TYPE_R)
+            __clear_bit(msr, msr_bitmap + 0x000/BYTES_PER_LONG); /* read-low */
+        if (type & MSR_TYPE_W)
+            __clear_bit(msr, msr_bitmap + 0x800/BYTES_PER_LONG); /* write-low */
     }
     else if ( (msr >= 0xc0000000) && (msr <= 0xc0001fff) )
     {
         msr &= 0x1fff;
-        __clear_bit(msr, msr_bitmap + 0x400/BYTES_PER_LONG); /* read-high */
-        __clear_bit(msr, msr_bitmap + 0xc00/BYTES_PER_LONG); /* write-high */
+        if (type & MSR_TYPE_R)
+            __clear_bit(msr, msr_bitmap + 0x400/BYTES_PER_LONG); /* read-high */
+        if (type & MSR_TYPE_W)
+            __clear_bit(msr, msr_bitmap + 0xc00/BYTES_PER_LONG); /* write-high */
     }
 }
 
@@ -776,13 +780,25 @@ static int construct_vmcs(struct vcpu *v
         v->arch.hvm_vmx.msr_bitmap = msr_bitmap;
         __vmwrite(MSR_BITMAP, virt_to_maddr(msr_bitmap));
 
-        vmx_disable_intercept_for_msr(v, MSR_FS_BASE);
-        vmx_disable_intercept_for_msr(v, MSR_GS_BASE);
-        vmx_disable_intercept_for_msr(v, MSR_IA32_SYSENTER_CS);
-        vmx_disable_intercept_for_msr(v, MSR_IA32_SYSENTER_ESP);
-        vmx_disable_intercept_for_msr(v, MSR_IA32_SYSENTER_EIP);
+        vmx_disable_intercept_for_msr(v, MSR_FS_BASE, MSR_TYPE_R | MSR_TYPE_W);
+        vmx_disable_intercept_for_msr(v, MSR_GS_BASE, MSR_TYPE_R | MSR_TYPE_W);
+        vmx_disable_intercept_for_msr(v, MSR_IA32_SYSENTER_CS, MSR_TYPE_R | MSR_TYPE_W);
+        vmx_disable_intercept_for_msr(v, MSR_IA32_SYSENTER_ESP, MSR_TYPE_R | MSR_TYPE_W);
+        vmx_disable_intercept_for_msr(v, MSR_IA32_SYSENTER_EIP, MSR_TYPE_R | MSR_TYPE_W);
         if ( cpu_has_vmx_pat && paging_mode_hap(d) )
-            vmx_disable_intercept_for_msr(v, MSR_IA32_CR_PAT);
+            vmx_disable_intercept_for_msr(v, MSR_IA32_CR_PAT, MSR_TYPE_R | MSR_TYPE_W);
+        if ( cpu_has_vmx_apic_reg_virt )
+        {
+            int msr;
+            for (msr = MSR_IA32_APICBASE_MSR; msr <= MSR_IA32_APICBASE_MSR + 0xff; msr++)
+                vmx_disable_intercept_for_msr(v, msr, MSR_TYPE_R);
+        }
+        if ( cpu_has_vmx_virtual_intr_delivery )
+        {
+            vmx_disable_intercept_for_msr(v, MSR_IA32_APICTPR_MSR, MSR_TYPE_W);
+            vmx_disable_intercept_for_msr(v, MSR_IA32_APICEOI_MSR, MSR_TYPE_W);
+            vmx_disable_intercept_for_msr(v, MSR_IA32_APICSELF_MSR, MSR_TYPE_W);
+        }
     }
 
     /* I/O access bitmap. */
diff -r ad93baf90deb xen/arch/x86/hvm/vmx/vmx.c
--- a/xen/arch/x86/hvm/vmx/vmx.c	Wed Sep 12 14:53:06 2012 +0800
+++ b/xen/arch/x86/hvm/vmx/vmx.c	Wed Sep 12 18:40:34 2012 +0800
@@ -2036,7 +2036,7 @@ static int vmx_msr_write_intercept(unsig
             for ( ; (rc == 0) && lbr->count; lbr++ )
                 for ( i = 0; (rc == 0) && (i < lbr->count); i++ )
                     if ( (rc = vmx_add_guest_msr(lbr->base + i)) == 0 )
-                        vmx_disable_intercept_for_msr(v, lbr->base + i);
+                        vmx_disable_intercept_for_msr(v, lbr->base + i, MSR_TYPE_R | MSR_TYPE_W);
         }
 
         if ( (rc < 0) ||
diff -r ad93baf90deb xen/include/asm-x86/hvm/vmx/vmcs.h
--- a/xen/include/asm-x86/hvm/vmx/vmcs.h	Wed Sep 12 14:53:06 2012 +0800
+++ b/xen/include/asm-x86/hvm/vmx/vmcs.h	Wed Sep 12 18:40:34 2012 +0800
@@ -407,7 +407,9 @@ enum vmcs_field {
 
 #define VMCS_VPID_WIDTH 16
 
-void vmx_disable_intercept_for_msr(struct vcpu *v, u32 msr);
+#define MSR_TYPE_R 1
+#define MSR_TYPE_W 2
+void vmx_disable_intercept_for_msr(struct vcpu *v, u32 msr, int type);
 int vmx_read_guest_msr(u32 msr, u64 *val);
 int vmx_write_guest_msr(u32 msr, u64 val);
 int vmx_add_guest_msr(u32 msr);
diff -r ad93baf90deb xen/include/asm-x86/msr-index.h
--- a/xen/include/asm-x86/msr-index.h	Wed Sep 12 14:53:06 2012 +0800
+++ b/xen/include/asm-x86/msr-index.h	Wed Sep 12 18:40:34 2012 +0800
@@ -291,6 +291,9 @@
 #define MSR_IA32_APICBASE_ENABLE	(1<<11)
 #define MSR_IA32_APICBASE_BASE		(0xfffff<<12)
 #define MSR_IA32_APICBASE_MSR           0x800
+#define MSR_IA32_APICTPR_MSR            0x808
+#define MSR_IA32_APICEOI_MSR            0x80b
+#define MSR_IA32_APICSELF_MSR           0x83f
 
 #define MSR_IA32_UCODE_WRITE		0x00000079
 #define MSR_IA32_UCODE_REV		0x0000008b

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 13 10:14:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Sep 2012 10: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 1TC6Qi-0002lj-7P; Thu, 13 Sep 2012 10:13:52 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jiongxi.li@intel.com>) id 1TC6Qg-0002kr-1M
	for xen-devel@lists.xen.org; Thu, 13 Sep 2012 10:13:50 +0000
Received: from [85.158.138.51:48512] by server-3.bemta-3.messagelabs.com id
	16/9F-21322-DD1B1505; Thu, 13 Sep 2012 10:13:49 +0000
X-Env-Sender: jiongxi.li@intel.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1347531226!26289670!1
X-Originating-IP: [134.134.136.24]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjQgPT4gMzQxNTMy\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15420 invoked from network); 13 Sep 2012 10:13:47 -0000
Received: from mga09.intel.com (HELO mga09.intel.com) (134.134.136.24)
	by server-10.tower-174.messagelabs.com with SMTP;
	13 Sep 2012 10:13:47 -0000
Received: from orsmga001.jf.intel.com ([10.7.209.18])
	by orsmga102.jf.intel.com with ESMTP; 13 Sep 2012 03:13:37 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.80,416,1344236400"; d="scan'208";a="192472307"
Received: from fmsmsx105.amr.corp.intel.com ([10.19.9.36])
	by orsmga001.jf.intel.com with ESMTP; 13 Sep 2012 03:13:45 -0700
Received: from FMSMSX109.amr.corp.intel.com (10.19.9.28) by
	FMSMSX105.amr.corp.intel.com (10.19.9.36) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Thu, 13 Sep 2012 03:13:45 -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; Thu, 13 Sep 2012 03:13:45 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.239]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.175]) with mapi id
	14.01.0355.002; Thu, 13 Sep 2012 18:13:43 +0800
From: "Li, Jiongxi" <jiongxi.li@intel.com>
To: "'xen-devel@lists.xen.org'" <xen-devel@lists.xen.org>
Thread-Topic: [ PATCH v2 2/3] xen: enable  Virtual-interrupt delivery
Thread-Index: Ac2Rk1QVEWKiD4UjQZmJzXGkJDDseA==
Date: Thu, 13 Sep 2012 10:13:42 +0000
Message-ID: <D9137FCD9CFF644B965863BCFBEDABB878046B@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: "Zhang, Yang Z" <yang.z.zhang@intel.com>, Keir Fraser <keir@xen.org>,
	"Zhang, 
	Xiantao" <xiantao.zhang@intel.com>, Jan Beulich <JBeulich@suse.com>
Subject: [Xen-devel] [ PATCH v2 2/3] xen: enable Virtual-interrupt 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

Virtual interrupt delivery avoids Xen to inject vAPIC interrupts manually, which is fully taken care of by the hardware. This needs some special awareness into existing interrupr injection path:
For pending interrupt from vLAPIC, instead of direct injection, we may need update architecture specific indicators before resuming to guest.
Before returning to guest, RVI should be updated if any pending IRRs EOI exit bitmap controls whether an EOI write should cause VM-Exit. If set, a trap-like induced EOI VM-Exit is triggered. The approach here is to manipulate EOI exit bitmap based on value of TMR. Level triggered irq requires a hook in vLAPIC EOI write, so that vIOAPIC EOI is triggered and emulated

Signed-off-by: Gang Wei <gang.wei@intel.com>
Signed-off-by: Yang Zhang <yang.z.zhang@intel.com>
Signed-off-by: Jiongxi Li <jiongxi.li@intel.com>


diff -r 7c6844dd4a0d -r e3724bdf9403 xen/arch/x86/hvm/vlapic.c
--- a/xen/arch/x86/hvm/vlapic.c	Tue Sep 11 15:34:36 2012 +0800
+++ b/xen/arch/x86/hvm/vlapic.c	Thu Sep 13 12:22:54 2012 +0800
@@ -145,6 +145,9 @@ int vlapic_set_irq(struct vlapic *vlapic
     if ( trig )
         vlapic_set_vector(vec, &vlapic->regs->data[APIC_TMR]);
 
+    if ( hvm_funcs.update_eoi_exit_bitmap )
+        hvm_funcs.update_eoi_exit_bitmap(vlapic_vcpu(vlapic), vec ,trig);
+
     /* We may need to wake up target vcpu, besides set pending bit here */
     return !vlapic_test_and_set_irr(vec, vlapic);
 }
@@ -410,6 +413,14 @@ void vlapic_EOI_set(struct vlapic *vlapi
     hvm_dpci_msi_eoi(current->domain, vector);
 }
 
+void vlapic_handle_EOI_induced_exit(struct vlapic *vlapic, int vector)
+{
+    if ( vlapic_test_and_clear_vector(vector, &vlapic->regs->data[APIC_TMR]) )
+        vioapic_update_EOI(vlapic_domain(vlapic), vector);
+
+    hvm_dpci_msi_eoi(current->domain, vector);
+}
+
 int vlapic_ipi(
     struct vlapic *vlapic, uint32_t icr_low, uint32_t icr_high)
 {
@@ -1000,6 +1011,14 @@ void vlapic_adjust_i8259_target(struct d
     pt_adjust_global_vcpu_target(v);
 }
 
+int vlapic_virtual_intr_delivery_enabled(void)
+{
+    if ( hvm_funcs.virtual_intr_delivery_enabled )
+        return hvm_funcs.virtual_intr_delivery_enabled();
+    else
+        return 0;
+}
+
 int vlapic_has_pending_irq(struct vcpu *v)
 {
     struct vlapic *vlapic = vcpu_vlapic(v);
@@ -1012,6 +1031,9 @@ int vlapic_has_pending_irq(struct vcpu *
     if ( irr == -1 )
         return -1;
 
+    if ( vlapic_virtual_intr_delivery_enabled() )
+        return irr;
+
     isr = vlapic_find_highest_isr(vlapic);
     isr = (isr != -1) ? isr : 0;
     if ( (isr & 0xf0) >= (irr & 0xf0) )
@@ -1024,6 +1046,9 @@ int vlapic_ack_pending_irq(struct vcpu *
 {
     struct vlapic *vlapic = vcpu_vlapic(v);
 
+    if ( vlapic_virtual_intr_delivery_enabled() )
+        return 1;
+
     vlapic_set_vector(vector, &vlapic->regs->data[APIC_ISR]);
     vlapic_clear_irr(vector, vlapic);
 
diff -r 7c6844dd4a0d -r e3724bdf9403 xen/arch/x86/hvm/vmx/intr.c
--- a/xen/arch/x86/hvm/vmx/intr.c	Tue Sep 11 15:34:36 2012 +0800
+++ b/xen/arch/x86/hvm/vmx/intr.c	Thu Sep 13 12:22:54 2012 +0800
@@ -206,6 +206,7 @@ void vmx_intr_assist(void)
     struct vcpu *v = current;
     unsigned int tpr_threshold = 0;
     enum hvm_intblk intblk;
+    int pt_vector = -1;
 
     /* Block event injection when single step with MTF. */
     if ( unlikely(v->arch.hvm_vcpu.single_step) )
@@ -216,7 +217,7 @@ void vmx_intr_assist(void)
     }
 
     /* Crank the handle on interrupt state. */
-    pt_update_irq(v);
+    pt_vector = pt_update_irq(v);
 
     do {
         intack = hvm_vcpu_has_pending_irq(v);
@@ -227,19 +228,43 @@ void vmx_intr_assist(void)
             goto out;
 
         intblk = hvm_interrupt_blocked(v, intack);
-        if ( intblk == hvm_intblk_tpr )
+        if ( cpu_has_vmx_virtual_intr_delivery )
         {
-            ASSERT(vlapic_enabled(vcpu_vlapic(v)));
-            ASSERT(intack.source == hvm_intsrc_lapic);
-            tpr_threshold = intack.vector >> 4;
-            goto out;
+            /* Set "Interrupt-window exiting" for ExtINT */
+            if ( (intblk != hvm_intblk_none) &&
+                 ( (intack.source == hvm_intsrc_pic) ||
+                 ( intack.source == hvm_intsrc_vector) ) )
+            {
+                enable_intr_window(v, intack);
+                goto out;
+            }
+
+            if ( __vmread(VM_ENTRY_INTR_INFO) & INTR_INFO_VALID_MASK )
+            {
+                if ( (intack.source == hvm_intsrc_pic) ||
+                     (intack.source == hvm_intsrc_nmi) ||
+                     (intack.source == hvm_intsrc_mce) )
+                    enable_intr_window(v, intack);
+
+                goto out;
+            }
         }
+        else
+        {
+            if ( intblk == hvm_intblk_tpr )
+            {
+                ASSERT(vlapic_enabled(vcpu_vlapic(v)));
+                ASSERT(intack.source == hvm_intsrc_lapic);
+                tpr_threshold = intack.vector >> 4;
+                goto out;
+            }
 
-        if ( (intblk != hvm_intblk_none) ||
-             (__vmread(VM_ENTRY_INTR_INFO) & INTR_INFO_VALID_MASK) )
-        {
-            enable_intr_window(v, intack);
-            goto out;
+            if ( (intblk != hvm_intblk_none) ||
+                 (__vmread(VM_ENTRY_INTR_INFO) & INTR_INFO_VALID_MASK) )
+            {
+                enable_intr_window(v, intack);
+                goto out;
+            }
         }
 
         intack = hvm_vcpu_ack_pending_irq(v, intack);
@@ -253,6 +278,44 @@ void vmx_intr_assist(void)
     {
         hvm_inject_hw_exception(TRAP_machine_check, HVM_DELIVER_NO_ERROR_CODE);
     }
+    else if ( cpu_has_vmx_virtual_intr_delivery &&
+              intack.source != hvm_intsrc_pic &&
+              intack.source != hvm_intsrc_vector )
+    {
+        unsigned long status = __vmread(GUEST_INTR_STATUS);
+
+       /*
+        * Set eoi_exit_bitmap for periodic timer interrup to cause EOI-induced VM
+        * exit, then pending periodic time interrups have the chance to be injected
+        * for compensation
+        */
+        if (pt_vector != -1)
+            vmx_set_eoi_exit_bitmap(v, pt_vector);
+
+        /* we need update the RVI field */
+        status &= ~(unsigned long)0x0FF;
+        status |= (unsigned long)0x0FF & 
+                    intack.vector;
+        __vmwrite(GUEST_INTR_STATUS, status);
+        if (v->arch.hvm_vmx.eoi_exitmap_changed) {
+#ifdef __i386__
+#define UPDATE_EOI_EXITMAP(v, e) {                             \
+        if (test_and_clear_bit(e, &v->arch.hvm_vmx.eoi_exitmap_changed)) {      \
+                __vmwrite(EOI_EXIT_BITMAP##e, v->arch.hvm_vmx.eoi_exit_bitmap[e]);    \
+                __vmwrite(EOI_EXIT_BITMAP##e##_HIGH, v.arch.hvm_vmx.eoi_exit_bitmap[e] >> 32);}}
+#else
+#define UPDATE_EOI_EXITMAP(v, e) {                             \
+        if (test_and_clear_bit(e, &v->arch.hvm_vmx.eoi_exitmap_changed)) {      \
+                __vmwrite(EOI_EXIT_BITMAP##e, v->arch.hvm_vmx.eoi_exit_bitmap[e]);}}
+#endif
+                UPDATE_EOI_EXITMAP(v, 0);
+                UPDATE_EOI_EXITMAP(v, 1);
+                UPDATE_EOI_EXITMAP(v, 2);
+                UPDATE_EOI_EXITMAP(v, 3);
+        }
+
+        pt_intr_post(v, intack);
+    }
     else
     {
         HVMTRACE_2D(INJ_VIRQ, intack.vector, /*fake=*/ 0);
@@ -262,11 +325,16 @@ void vmx_intr_assist(void)
 
     /* Is there another IRQ to queue up behind this one? */
     intack = hvm_vcpu_has_pending_irq(v);
-    if ( unlikely(intack.source != hvm_intsrc_none) )
-        enable_intr_window(v, intack);
+    if ( !cpu_has_vmx_virtual_intr_delivery ||
+         intack.source == hvm_intsrc_pic ||
+         intack.source == hvm_intsrc_vector )
+    {
+        if ( unlikely(intack.source != hvm_intsrc_none) )
+            enable_intr_window(v, intack);
+    }
 
  out:
-    if ( cpu_has_vmx_tpr_shadow )
+    if ( !cpu_has_vmx_virtual_intr_delivery && cpu_has_vmx_tpr_shadow )
         __vmwrite(TPR_THRESHOLD, tpr_threshold);
 }
 
diff -r 7c6844dd4a0d -r e3724bdf9403 xen/arch/x86/hvm/vmx/vmcs.c
--- a/xen/arch/x86/hvm/vmx/vmcs.c	Tue Sep 11 15:34:36 2012 +0800
+++ b/xen/arch/x86/hvm/vmx/vmcs.c	Thu Sep 13 12:22:54 2012 +0800
@@ -90,6 +90,7 @@ static void __init vmx_display_features(
     P(cpu_has_vmx_msr_bitmap, "MSR direct-access bitmap");
     P(cpu_has_vmx_unrestricted_guest, "Unrestricted Guest");
     P(cpu_has_vmx_apic_reg_virt, "APIC Register Virtualization");
+    P(cpu_has_vmx_virtual_intr_delivery, "Virtual Interrupt Delivery");
 #undef P
 
     if ( !printed )
@@ -188,11 +189,12 @@ static int vmx_init_vmcs_config(void)
             opt |= SECONDARY_EXEC_UNRESTRICTED_GUEST;
 
         /*
-         * "APIC Register Virtualization"
+         * "APIC Register Virtualization" and "Virtual Interrupt Delivery"
          * can be set only when "use TPR shadow" is set
          */
         if ( _vmx_cpu_based_exec_control & CPU_BASED_TPR_SHADOW )
-            opt |= SECONDARY_EXEC_APIC_REGISTER_VIRT;
+            opt |= SECONDARY_EXEC_APIC_REGISTER_VIRT |
+                   SECONDARY_EXEC_VIRTUAL_INTR_DELIVERY;
 
 
         _vmx_secondary_exec_control = adjust_vmx_controls(
@@ -787,6 +789,22 @@ static int construct_vmcs(struct vcpu *v
     __vmwrite(IO_BITMAP_A, virt_to_maddr((char *)hvm_io_bitmap + 0));
     __vmwrite(IO_BITMAP_B, virt_to_maddr((char *)hvm_io_bitmap + PAGE_SIZE));
 
+    if ( cpu_has_vmx_virtual_intr_delivery )
+    {
+        /* EOI-exit bitmap */
+        v->arch.hvm_vmx.eoi_exit_bitmap[0] = (uint64_t)0;
+        __vmwrite(EOI_EXIT_BITMAP0, v->arch.hvm_vmx.eoi_exit_bitmap[0]);
+        v->arch.hvm_vmx.eoi_exit_bitmap[1] = (uint64_t)0;
+        __vmwrite(EOI_EXIT_BITMAP1, v->arch.hvm_vmx.eoi_exit_bitmap[1]);
+        v->arch.hvm_vmx.eoi_exit_bitmap[2] = (uint64_t)0;
+        __vmwrite(EOI_EXIT_BITMAP2, v->arch.hvm_vmx.eoi_exit_bitmap[2]);
+        v->arch.hvm_vmx.eoi_exit_bitmap[3] = (uint64_t)0;
+        __vmwrite(EOI_EXIT_BITMAP3, v->arch.hvm_vmx.eoi_exit_bitmap[3]);
+
+        /* Initialise Guest Interrupt Status (RVI and SVI) to 0 */
+        __vmwrite(GUEST_INTR_STATUS, 0);
+    }
+
     /* Host data selectors. */
     __vmwrite(HOST_SS_SELECTOR, __HYPERVISOR_DS);
     __vmwrite(HOST_DS_SELECTOR, __HYPERVISOR_DS);
@@ -1028,6 +1046,30 @@ int vmx_add_host_load_msr(u32 msr)
     return 0;
 }
 
+void vmx_set_eoi_exit_bitmap(struct vcpu *v, u8 vector)
+{
+    int index, offset, changed;
+
+    index = vector >> 6; 
+    offset = vector & 63;
+    changed = !test_and_set_bit(offset,
+                  (uint64_t *)&v->arch.hvm_vmx.eoi_exit_bitmap[index]);
+    if (changed)
+        set_bit(index, &v->arch.hvm_vmx.eoi_exitmap_changed);
+}
+
+void vmx_clear_eoi_exit_bitmap(struct vcpu *v, u8 vector)
+{
+    int index, offset, changed;
+
+    index = vector >> 6; 
+    offset = vector & 63;
+    changed = test_and_clear_bit(offset,
+                  (uint64_t *)&v->arch.hvm_vmx.eoi_exit_bitmap[index]);
+    if (changed)
+        set_bit(index, &v->arch.hvm_vmx.eoi_exitmap_changed);
+}
+
 int vmx_create_vmcs(struct vcpu *v)
 {
     struct arch_vmx_struct *arch_vmx = &v->arch.hvm_vmx;
diff -r 7c6844dd4a0d -r e3724bdf9403 xen/arch/x86/hvm/vmx/vmx.c
--- a/xen/arch/x86/hvm/vmx/vmx.c	Tue Sep 11 15:34:36 2012 +0800
+++ b/xen/arch/x86/hvm/vmx/vmx.c	Thu Sep 13 12:22:54 2012 +0800
@@ -1502,6 +1502,22 @@ static void vmx_set_info_guest(struct vc
     vmx_vmcs_exit(v);
 }
 
+static void vmx_update_eoi_exit_bitmap(struct vcpu *v, u8 vector, u8 trig)
+{
+    if ( cpu_has_vmx_virtual_intr_delivery )
+    {
+        if (trig)
+            vmx_set_eoi_exit_bitmap(v, vector);
+        else
+            vmx_clear_eoi_exit_bitmap(v, vector);
+    }
+}
+
+static int vmx_virtual_intr_delivery_enabled(void)
+{
+    return cpu_has_vmx_virtual_intr_delivery;
+}
+
 static struct hvm_function_table __read_mostly vmx_function_table = {
     .name                 = "VMX",
     .cpu_up_prepare       = vmx_cpu_up_prepare,
@@ -1548,7 +1564,9 @@ static struct hvm_function_table __read_
     .nhvm_vmcx_guest_intercepts_trap = nvmx_intercepts_exception,
     .nhvm_vcpu_vmexit_trap = nvmx_vmexit_trap,
     .nhvm_intr_blocked    = nvmx_intr_blocked,
-    .nhvm_domain_relinquish_resources = nvmx_domain_relinquish_resources
+    .nhvm_domain_relinquish_resources = nvmx_domain_relinquish_resources,
+    .update_eoi_exit_bitmap = vmx_update_eoi_exit_bitmap,
+    .virtual_intr_delivery_enabled = vmx_virtual_intr_delivery_enabled
 };
 
 struct hvm_function_table * __init start_vmx(void)
@@ -2284,6 +2302,17 @@ static int vmx_handle_apic_write(void)
     return vlapic_apicv_write(current, offset);
 }
 
+/*
+ * When "Virtual Interrupt Delivery" is enabled, this function is used
+ * to handle EOI-induced VM exit
+ */
+void vmx_handle_EOI_induced_exit(struct vlapic *vlapic, int vector)
+{
+    ASSERT(cpu_has_vmx_virtual_intr_delivery);
+
+    vlapic_handle_EOI_induced_exit(vlapic, vector);
+}
+
 void vmx_vmexit_handler(struct cpu_user_regs *regs)
 {
     unsigned int exit_reason, idtv_info, intr_info = 0, vector = 0;
@@ -2677,6 +2706,16 @@ void vmx_vmexit_handler(struct cpu_user_
             hvm_inject_hw_exception(TRAP_gp_fault, 0);
         break;
 
+    case EXIT_REASON_EOI_INDUCED:
+    {
+        int vector;
+        exit_qualification = __vmread(EXIT_QUALIFICATION);
+        vector = exit_qualification & 0xff;
+
+        vmx_handle_EOI_induced_exit(vcpu_vlapic(current), vector);
+        break;
+    }
+
     case EXIT_REASON_IO_INSTRUCTION:
         exit_qualification = __vmread(EXIT_QUALIFICATION);
         if ( exit_qualification & 0x10 )
diff -r 7c6844dd4a0d -r e3724bdf9403 xen/arch/x86/hvm/vpt.c
--- a/xen/arch/x86/hvm/vpt.c	Tue Sep 11 15:34:36 2012 +0800
+++ b/xen/arch/x86/hvm/vpt.c	Thu Sep 13 12:22:54 2012 +0800
@@ -212,7 +212,7 @@ static void pt_timer_fn(void *data)
     pt_unlock(pt);
 }
 
-void pt_update_irq(struct vcpu *v)
+int pt_update_irq(struct vcpu *v)
 {
     struct list_head *head = &v->arch.hvm_vcpu.tm_list;
     struct periodic_time *pt, *temp, *earliest_pt = NULL;
@@ -245,7 +245,7 @@ void pt_update_irq(struct vcpu *v)
     if ( earliest_pt == NULL )
     {
         spin_unlock(&v->arch.hvm_vcpu.tm_lock);
-        return;
+        return -1;
     }
 
     earliest_pt->irq_issued = 1;
@@ -263,6 +263,17 @@ void pt_update_irq(struct vcpu *v)
         hvm_isa_irq_deassert(v->domain, irq);
         hvm_isa_irq_assert(v->domain, irq);
     }
+
+    /*
+     * If periodic timer interrut is handled by lapic, its vector in
+     * IRR is returned and used to set eoi_exit_bitmap for virtual
+     * interrupt delivery case. Otherwise return -1 to do nothing.  
+     */ 
+    if ( vlapic_accept_pic_intr(v) &&
+         (&v->domain->arch.hvm_domain)->vpic[0].int_output )
+        return -1;
+    else 
+        return pt_irq_vector(earliest_pt, hvm_intsrc_lapic);
 }
 
 static struct periodic_time *is_pt_irq(
diff -r 7c6844dd4a0d -r e3724bdf9403 xen/include/asm-x86/hvm/hvm.h
--- a/xen/include/asm-x86/hvm/hvm.h	Tue Sep 11 15:34:36 2012 +0800
+++ b/xen/include/asm-x86/hvm/hvm.h	Thu Sep 13 12:22:54 2012 +0800
@@ -180,6 +180,10 @@ struct hvm_function_table {
 
     enum hvm_intblk (*nhvm_intr_blocked)(struct vcpu *v);
     void (*nhvm_domain_relinquish_resources)(struct domain *d);
+
+    /* Virtual interrupt delivery */
+    void (*update_eoi_exit_bitmap)(struct vcpu *v, u8 vector, u8 trig);
+    int (*virtual_intr_delivery_enabled)(void);
 };
 
 extern struct hvm_function_table hvm_funcs;
diff -r 7c6844dd4a0d -r e3724bdf9403 xen/include/asm-x86/hvm/vlapic.h
--- a/xen/include/asm-x86/hvm/vlapic.h	Tue Sep 11 15:34:36 2012 +0800
+++ b/xen/include/asm-x86/hvm/vlapic.h	Thu Sep 13 12:22:54 2012 +0800
@@ -100,6 +100,7 @@ int vlapic_accept_pic_intr(struct vcpu *
 void vlapic_adjust_i8259_target(struct domain *d);
 
 void vlapic_EOI_set(struct vlapic *vlapic);
+void vlapic_handle_EOI_induced_exit(struct vlapic *vlapic, int vector);
 
 int vlapic_ipi(struct vlapic *vlapic, uint32_t icr_low, uint32_t icr_high);
 
diff -r 7c6844dd4a0d -r e3724bdf9403 xen/include/asm-x86/hvm/vmx/vmcs.h
--- a/xen/include/asm-x86/hvm/vmx/vmcs.h	Tue Sep 11 15:34:36 2012 +0800
+++ b/xen/include/asm-x86/hvm/vmx/vmcs.h	Thu Sep 13 12:22:54 2012 +0800
@@ -110,6 +110,9 @@ struct arch_vmx_struct {
     unsigned int         host_msr_count;
     struct vmx_msr_entry *host_msr_area;
 
+    uint32_t             eoi_exitmap_changed;
+    uint64_t             eoi_exit_bitmap[4];
+
     unsigned long        host_cr0;
 
     /* Is the guest in real mode? */
@@ -183,6 +186,7 @@ extern u32 vmx_vmentry_control;
 #define SECONDARY_EXEC_WBINVD_EXITING           0x00000040
 #define SECONDARY_EXEC_UNRESTRICTED_GUEST       0x00000080
 #define SECONDARY_EXEC_APIC_REGISTER_VIRT       0x00000100
+#define SECONDARY_EXEC_VIRTUAL_INTR_DELIVERY    0x00000200
 #define SECONDARY_EXEC_PAUSE_LOOP_EXITING       0x00000400
 #define SECONDARY_EXEC_ENABLE_INVPCID           0x00001000
 extern u32 vmx_secondary_exec_control;
@@ -233,6 +237,8 @@ extern bool_t cpu_has_vmx_ins_outs_instr
     (vmx_secondary_exec_control & SECONDARY_EXEC_PAUSE_LOOP_EXITING)
 #define cpu_has_vmx_apic_reg_virt \
     (vmx_secondary_exec_control & SECONDARY_EXEC_APIC_REGISTER_VIRT)
+#define cpu_has_vmx_virtual_intr_delivery \
+    (vmx_secondary_exec_control & SECONDARY_EXEC_VIRTUAL_INTR_DELIVERY)
 
 /* GUEST_INTERRUPTIBILITY_INFO flags. */
 #define VMX_INTR_SHADOW_STI             0x00000001
@@ -251,6 +257,7 @@ enum vmcs_field {
     GUEST_GS_SELECTOR               = 0x0000080a,
     GUEST_LDTR_SELECTOR             = 0x0000080c,
     GUEST_TR_SELECTOR               = 0x0000080e,
+    GUEST_INTR_STATUS               = 0x00000810,
     HOST_ES_SELECTOR                = 0x00000c00,
     HOST_CS_SELECTOR                = 0x00000c02,
     HOST_SS_SELECTOR                = 0x00000c04,
@@ -278,6 +285,14 @@ enum vmcs_field {
     APIC_ACCESS_ADDR_HIGH           = 0x00002015,
     EPT_POINTER                     = 0x0000201a,
     EPT_POINTER_HIGH                = 0x0000201b,
+    EOI_EXIT_BITMAP0                = 0x0000201c,
+    EOI_EXIT_BITMAP0_HIGH           = 0x0000201d,
+    EOI_EXIT_BITMAP1                = 0x0000201e,
+    EOI_EXIT_BITMAP1_HIGH           = 0x0000201f,
+    EOI_EXIT_BITMAP2                = 0x00002020,
+    EOI_EXIT_BITMAP2_HIGH           = 0x00002021,
+    EOI_EXIT_BITMAP3                = 0x00002022,
+    EOI_EXIT_BITMAP3_HIGH           = 0x00002023,
     GUEST_PHYSICAL_ADDRESS          = 0x00002400,
     GUEST_PHYSICAL_ADDRESS_HIGH     = 0x00002401,
     VMCS_LINK_POINTER               = 0x00002800,
@@ -398,6 +413,8 @@ int vmx_write_guest_msr(u32 msr, u64 val
 int vmx_add_guest_msr(u32 msr);
 int vmx_add_host_load_msr(u32 msr);
 void vmx_vmcs_switch(struct vmcs_struct *from, struct vmcs_struct *to);
+void vmx_set_eoi_exit_bitmap(struct vcpu *v, u8 vector);
+void vmx_clear_eoi_exit_bitmap(struct vcpu *v, u8 vector);
 
 #endif /* ASM_X86_HVM_VMX_VMCS_H__ */
 
diff -r 7c6844dd4a0d -r e3724bdf9403 xen/include/asm-x86/hvm/vmx/vmx.h
--- a/xen/include/asm-x86/hvm/vmx/vmx.h	Tue Sep 11 15:34:36 2012 +0800
+++ b/xen/include/asm-x86/hvm/vmx/vmx.h	Thu Sep 13 12:22:54 2012 +0800
@@ -119,6 +119,7 @@ void vmx_update_cpu_exec_control(struct 
 #define EXIT_REASON_MCE_DURING_VMENTRY  41
 #define EXIT_REASON_TPR_BELOW_THRESHOLD 43
 #define EXIT_REASON_APIC_ACCESS         44
+#define EXIT_REASON_EOI_INDUCED         45
 #define EXIT_REASON_ACCESS_GDTR_OR_IDTR 46
 #define EXIT_REASON_ACCESS_LDTR_OR_TR   47
 #define EXIT_REASON_EPT_VIOLATION       48
diff -r 7c6844dd4a0d -r e3724bdf9403 xen/include/asm-x86/hvm/vpt.h
--- a/xen/include/asm-x86/hvm/vpt.h	Tue Sep 11 15:34:36 2012 +0800
+++ b/xen/include/asm-x86/hvm/vpt.h	Thu Sep 13 12:22:54 2012 +0800
@@ -141,7 +141,7 @@ struct pl_time {    /* platform time */
 
 void pt_save_timer(struct vcpu *v);
 void pt_restore_timer(struct vcpu *v);
-void pt_update_irq(struct vcpu *v);
+int pt_update_irq(struct vcpu *v);
 void pt_intr_post(struct vcpu *v, struct hvm_intack intack);
 void pt_migrate(struct vcpu *v);
 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 13 10:14:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Sep 2012 10: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 1TC6Qi-0002lj-7P; Thu, 13 Sep 2012 10:13:52 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jiongxi.li@intel.com>) id 1TC6Qg-0002kr-1M
	for xen-devel@lists.xen.org; Thu, 13 Sep 2012 10:13:50 +0000
Received: from [85.158.138.51:48512] by server-3.bemta-3.messagelabs.com id
	16/9F-21322-DD1B1505; Thu, 13 Sep 2012 10:13:49 +0000
X-Env-Sender: jiongxi.li@intel.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1347531226!26289670!1
X-Originating-IP: [134.134.136.24]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjQgPT4gMzQxNTMy\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15420 invoked from network); 13 Sep 2012 10:13:47 -0000
Received: from mga09.intel.com (HELO mga09.intel.com) (134.134.136.24)
	by server-10.tower-174.messagelabs.com with SMTP;
	13 Sep 2012 10:13:47 -0000
Received: from orsmga001.jf.intel.com ([10.7.209.18])
	by orsmga102.jf.intel.com with ESMTP; 13 Sep 2012 03:13:37 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.80,416,1344236400"; d="scan'208";a="192472307"
Received: from fmsmsx105.amr.corp.intel.com ([10.19.9.36])
	by orsmga001.jf.intel.com with ESMTP; 13 Sep 2012 03:13:45 -0700
Received: from FMSMSX109.amr.corp.intel.com (10.19.9.28) by
	FMSMSX105.amr.corp.intel.com (10.19.9.36) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Thu, 13 Sep 2012 03:13:45 -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; Thu, 13 Sep 2012 03:13:45 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.239]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.175]) with mapi id
	14.01.0355.002; Thu, 13 Sep 2012 18:13:43 +0800
From: "Li, Jiongxi" <jiongxi.li@intel.com>
To: "'xen-devel@lists.xen.org'" <xen-devel@lists.xen.org>
Thread-Topic: [ PATCH v2 2/3] xen: enable  Virtual-interrupt delivery
Thread-Index: Ac2Rk1QVEWKiD4UjQZmJzXGkJDDseA==
Date: Thu, 13 Sep 2012 10:13:42 +0000
Message-ID: <D9137FCD9CFF644B965863BCFBEDABB878046B@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: "Zhang, Yang Z" <yang.z.zhang@intel.com>, Keir Fraser <keir@xen.org>,
	"Zhang, 
	Xiantao" <xiantao.zhang@intel.com>, Jan Beulich <JBeulich@suse.com>
Subject: [Xen-devel] [ PATCH v2 2/3] xen: enable Virtual-interrupt 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

Virtual interrupt delivery avoids Xen to inject vAPIC interrupts manually, which is fully taken care of by the hardware. This needs some special awareness into existing interrupr injection path:
For pending interrupt from vLAPIC, instead of direct injection, we may need update architecture specific indicators before resuming to guest.
Before returning to guest, RVI should be updated if any pending IRRs EOI exit bitmap controls whether an EOI write should cause VM-Exit. If set, a trap-like induced EOI VM-Exit is triggered. The approach here is to manipulate EOI exit bitmap based on value of TMR. Level triggered irq requires a hook in vLAPIC EOI write, so that vIOAPIC EOI is triggered and emulated

Signed-off-by: Gang Wei <gang.wei@intel.com>
Signed-off-by: Yang Zhang <yang.z.zhang@intel.com>
Signed-off-by: Jiongxi Li <jiongxi.li@intel.com>


diff -r 7c6844dd4a0d -r e3724bdf9403 xen/arch/x86/hvm/vlapic.c
--- a/xen/arch/x86/hvm/vlapic.c	Tue Sep 11 15:34:36 2012 +0800
+++ b/xen/arch/x86/hvm/vlapic.c	Thu Sep 13 12:22:54 2012 +0800
@@ -145,6 +145,9 @@ int vlapic_set_irq(struct vlapic *vlapic
     if ( trig )
         vlapic_set_vector(vec, &vlapic->regs->data[APIC_TMR]);
 
+    if ( hvm_funcs.update_eoi_exit_bitmap )
+        hvm_funcs.update_eoi_exit_bitmap(vlapic_vcpu(vlapic), vec ,trig);
+
     /* We may need to wake up target vcpu, besides set pending bit here */
     return !vlapic_test_and_set_irr(vec, vlapic);
 }
@@ -410,6 +413,14 @@ void vlapic_EOI_set(struct vlapic *vlapi
     hvm_dpci_msi_eoi(current->domain, vector);
 }
 
+void vlapic_handle_EOI_induced_exit(struct vlapic *vlapic, int vector)
+{
+    if ( vlapic_test_and_clear_vector(vector, &vlapic->regs->data[APIC_TMR]) )
+        vioapic_update_EOI(vlapic_domain(vlapic), vector);
+
+    hvm_dpci_msi_eoi(current->domain, vector);
+}
+
 int vlapic_ipi(
     struct vlapic *vlapic, uint32_t icr_low, uint32_t icr_high)
 {
@@ -1000,6 +1011,14 @@ void vlapic_adjust_i8259_target(struct d
     pt_adjust_global_vcpu_target(v);
 }
 
+int vlapic_virtual_intr_delivery_enabled(void)
+{
+    if ( hvm_funcs.virtual_intr_delivery_enabled )
+        return hvm_funcs.virtual_intr_delivery_enabled();
+    else
+        return 0;
+}
+
 int vlapic_has_pending_irq(struct vcpu *v)
 {
     struct vlapic *vlapic = vcpu_vlapic(v);
@@ -1012,6 +1031,9 @@ int vlapic_has_pending_irq(struct vcpu *
     if ( irr == -1 )
         return -1;
 
+    if ( vlapic_virtual_intr_delivery_enabled() )
+        return irr;
+
     isr = vlapic_find_highest_isr(vlapic);
     isr = (isr != -1) ? isr : 0;
     if ( (isr & 0xf0) >= (irr & 0xf0) )
@@ -1024,6 +1046,9 @@ int vlapic_ack_pending_irq(struct vcpu *
 {
     struct vlapic *vlapic = vcpu_vlapic(v);
 
+    if ( vlapic_virtual_intr_delivery_enabled() )
+        return 1;
+
     vlapic_set_vector(vector, &vlapic->regs->data[APIC_ISR]);
     vlapic_clear_irr(vector, vlapic);
 
diff -r 7c6844dd4a0d -r e3724bdf9403 xen/arch/x86/hvm/vmx/intr.c
--- a/xen/arch/x86/hvm/vmx/intr.c	Tue Sep 11 15:34:36 2012 +0800
+++ b/xen/arch/x86/hvm/vmx/intr.c	Thu Sep 13 12:22:54 2012 +0800
@@ -206,6 +206,7 @@ void vmx_intr_assist(void)
     struct vcpu *v = current;
     unsigned int tpr_threshold = 0;
     enum hvm_intblk intblk;
+    int pt_vector = -1;
 
     /* Block event injection when single step with MTF. */
     if ( unlikely(v->arch.hvm_vcpu.single_step) )
@@ -216,7 +217,7 @@ void vmx_intr_assist(void)
     }
 
     /* Crank the handle on interrupt state. */
-    pt_update_irq(v);
+    pt_vector = pt_update_irq(v);
 
     do {
         intack = hvm_vcpu_has_pending_irq(v);
@@ -227,19 +228,43 @@ void vmx_intr_assist(void)
             goto out;
 
         intblk = hvm_interrupt_blocked(v, intack);
-        if ( intblk == hvm_intblk_tpr )
+        if ( cpu_has_vmx_virtual_intr_delivery )
         {
-            ASSERT(vlapic_enabled(vcpu_vlapic(v)));
-            ASSERT(intack.source == hvm_intsrc_lapic);
-            tpr_threshold = intack.vector >> 4;
-            goto out;
+            /* Set "Interrupt-window exiting" for ExtINT */
+            if ( (intblk != hvm_intblk_none) &&
+                 ( (intack.source == hvm_intsrc_pic) ||
+                 ( intack.source == hvm_intsrc_vector) ) )
+            {
+                enable_intr_window(v, intack);
+                goto out;
+            }
+
+            if ( __vmread(VM_ENTRY_INTR_INFO) & INTR_INFO_VALID_MASK )
+            {
+                if ( (intack.source == hvm_intsrc_pic) ||
+                     (intack.source == hvm_intsrc_nmi) ||
+                     (intack.source == hvm_intsrc_mce) )
+                    enable_intr_window(v, intack);
+
+                goto out;
+            }
         }
+        else
+        {
+            if ( intblk == hvm_intblk_tpr )
+            {
+                ASSERT(vlapic_enabled(vcpu_vlapic(v)));
+                ASSERT(intack.source == hvm_intsrc_lapic);
+                tpr_threshold = intack.vector >> 4;
+                goto out;
+            }
 
-        if ( (intblk != hvm_intblk_none) ||
-             (__vmread(VM_ENTRY_INTR_INFO) & INTR_INFO_VALID_MASK) )
-        {
-            enable_intr_window(v, intack);
-            goto out;
+            if ( (intblk != hvm_intblk_none) ||
+                 (__vmread(VM_ENTRY_INTR_INFO) & INTR_INFO_VALID_MASK) )
+            {
+                enable_intr_window(v, intack);
+                goto out;
+            }
         }
 
         intack = hvm_vcpu_ack_pending_irq(v, intack);
@@ -253,6 +278,44 @@ void vmx_intr_assist(void)
     {
         hvm_inject_hw_exception(TRAP_machine_check, HVM_DELIVER_NO_ERROR_CODE);
     }
+    else if ( cpu_has_vmx_virtual_intr_delivery &&
+              intack.source != hvm_intsrc_pic &&
+              intack.source != hvm_intsrc_vector )
+    {
+        unsigned long status = __vmread(GUEST_INTR_STATUS);
+
+       /*
+        * Set eoi_exit_bitmap for periodic timer interrup to cause EOI-induced VM
+        * exit, then pending periodic time interrups have the chance to be injected
+        * for compensation
+        */
+        if (pt_vector != -1)
+            vmx_set_eoi_exit_bitmap(v, pt_vector);
+
+        /* we need update the RVI field */
+        status &= ~(unsigned long)0x0FF;
+        status |= (unsigned long)0x0FF & 
+                    intack.vector;
+        __vmwrite(GUEST_INTR_STATUS, status);
+        if (v->arch.hvm_vmx.eoi_exitmap_changed) {
+#ifdef __i386__
+#define UPDATE_EOI_EXITMAP(v, e) {                             \
+        if (test_and_clear_bit(e, &v->arch.hvm_vmx.eoi_exitmap_changed)) {      \
+                __vmwrite(EOI_EXIT_BITMAP##e, v->arch.hvm_vmx.eoi_exit_bitmap[e]);    \
+                __vmwrite(EOI_EXIT_BITMAP##e##_HIGH, v.arch.hvm_vmx.eoi_exit_bitmap[e] >> 32);}}
+#else
+#define UPDATE_EOI_EXITMAP(v, e) {                             \
+        if (test_and_clear_bit(e, &v->arch.hvm_vmx.eoi_exitmap_changed)) {      \
+                __vmwrite(EOI_EXIT_BITMAP##e, v->arch.hvm_vmx.eoi_exit_bitmap[e]);}}
+#endif
+                UPDATE_EOI_EXITMAP(v, 0);
+                UPDATE_EOI_EXITMAP(v, 1);
+                UPDATE_EOI_EXITMAP(v, 2);
+                UPDATE_EOI_EXITMAP(v, 3);
+        }
+
+        pt_intr_post(v, intack);
+    }
     else
     {
         HVMTRACE_2D(INJ_VIRQ, intack.vector, /*fake=*/ 0);
@@ -262,11 +325,16 @@ void vmx_intr_assist(void)
 
     /* Is there another IRQ to queue up behind this one? */
     intack = hvm_vcpu_has_pending_irq(v);
-    if ( unlikely(intack.source != hvm_intsrc_none) )
-        enable_intr_window(v, intack);
+    if ( !cpu_has_vmx_virtual_intr_delivery ||
+         intack.source == hvm_intsrc_pic ||
+         intack.source == hvm_intsrc_vector )
+    {
+        if ( unlikely(intack.source != hvm_intsrc_none) )
+            enable_intr_window(v, intack);
+    }
 
  out:
-    if ( cpu_has_vmx_tpr_shadow )
+    if ( !cpu_has_vmx_virtual_intr_delivery && cpu_has_vmx_tpr_shadow )
         __vmwrite(TPR_THRESHOLD, tpr_threshold);
 }
 
diff -r 7c6844dd4a0d -r e3724bdf9403 xen/arch/x86/hvm/vmx/vmcs.c
--- a/xen/arch/x86/hvm/vmx/vmcs.c	Tue Sep 11 15:34:36 2012 +0800
+++ b/xen/arch/x86/hvm/vmx/vmcs.c	Thu Sep 13 12:22:54 2012 +0800
@@ -90,6 +90,7 @@ static void __init vmx_display_features(
     P(cpu_has_vmx_msr_bitmap, "MSR direct-access bitmap");
     P(cpu_has_vmx_unrestricted_guest, "Unrestricted Guest");
     P(cpu_has_vmx_apic_reg_virt, "APIC Register Virtualization");
+    P(cpu_has_vmx_virtual_intr_delivery, "Virtual Interrupt Delivery");
 #undef P
 
     if ( !printed )
@@ -188,11 +189,12 @@ static int vmx_init_vmcs_config(void)
             opt |= SECONDARY_EXEC_UNRESTRICTED_GUEST;
 
         /*
-         * "APIC Register Virtualization"
+         * "APIC Register Virtualization" and "Virtual Interrupt Delivery"
          * can be set only when "use TPR shadow" is set
          */
         if ( _vmx_cpu_based_exec_control & CPU_BASED_TPR_SHADOW )
-            opt |= SECONDARY_EXEC_APIC_REGISTER_VIRT;
+            opt |= SECONDARY_EXEC_APIC_REGISTER_VIRT |
+                   SECONDARY_EXEC_VIRTUAL_INTR_DELIVERY;
 
 
         _vmx_secondary_exec_control = adjust_vmx_controls(
@@ -787,6 +789,22 @@ static int construct_vmcs(struct vcpu *v
     __vmwrite(IO_BITMAP_A, virt_to_maddr((char *)hvm_io_bitmap + 0));
     __vmwrite(IO_BITMAP_B, virt_to_maddr((char *)hvm_io_bitmap + PAGE_SIZE));
 
+    if ( cpu_has_vmx_virtual_intr_delivery )
+    {
+        /* EOI-exit bitmap */
+        v->arch.hvm_vmx.eoi_exit_bitmap[0] = (uint64_t)0;
+        __vmwrite(EOI_EXIT_BITMAP0, v->arch.hvm_vmx.eoi_exit_bitmap[0]);
+        v->arch.hvm_vmx.eoi_exit_bitmap[1] = (uint64_t)0;
+        __vmwrite(EOI_EXIT_BITMAP1, v->arch.hvm_vmx.eoi_exit_bitmap[1]);
+        v->arch.hvm_vmx.eoi_exit_bitmap[2] = (uint64_t)0;
+        __vmwrite(EOI_EXIT_BITMAP2, v->arch.hvm_vmx.eoi_exit_bitmap[2]);
+        v->arch.hvm_vmx.eoi_exit_bitmap[3] = (uint64_t)0;
+        __vmwrite(EOI_EXIT_BITMAP3, v->arch.hvm_vmx.eoi_exit_bitmap[3]);
+
+        /* Initialise Guest Interrupt Status (RVI and SVI) to 0 */
+        __vmwrite(GUEST_INTR_STATUS, 0);
+    }
+
     /* Host data selectors. */
     __vmwrite(HOST_SS_SELECTOR, __HYPERVISOR_DS);
     __vmwrite(HOST_DS_SELECTOR, __HYPERVISOR_DS);
@@ -1028,6 +1046,30 @@ int vmx_add_host_load_msr(u32 msr)
     return 0;
 }
 
+void vmx_set_eoi_exit_bitmap(struct vcpu *v, u8 vector)
+{
+    int index, offset, changed;
+
+    index = vector >> 6; 
+    offset = vector & 63;
+    changed = !test_and_set_bit(offset,
+                  (uint64_t *)&v->arch.hvm_vmx.eoi_exit_bitmap[index]);
+    if (changed)
+        set_bit(index, &v->arch.hvm_vmx.eoi_exitmap_changed);
+}
+
+void vmx_clear_eoi_exit_bitmap(struct vcpu *v, u8 vector)
+{
+    int index, offset, changed;
+
+    index = vector >> 6; 
+    offset = vector & 63;
+    changed = test_and_clear_bit(offset,
+                  (uint64_t *)&v->arch.hvm_vmx.eoi_exit_bitmap[index]);
+    if (changed)
+        set_bit(index, &v->arch.hvm_vmx.eoi_exitmap_changed);
+}
+
 int vmx_create_vmcs(struct vcpu *v)
 {
     struct arch_vmx_struct *arch_vmx = &v->arch.hvm_vmx;
diff -r 7c6844dd4a0d -r e3724bdf9403 xen/arch/x86/hvm/vmx/vmx.c
--- a/xen/arch/x86/hvm/vmx/vmx.c	Tue Sep 11 15:34:36 2012 +0800
+++ b/xen/arch/x86/hvm/vmx/vmx.c	Thu Sep 13 12:22:54 2012 +0800
@@ -1502,6 +1502,22 @@ static void vmx_set_info_guest(struct vc
     vmx_vmcs_exit(v);
 }
 
+static void vmx_update_eoi_exit_bitmap(struct vcpu *v, u8 vector, u8 trig)
+{
+    if ( cpu_has_vmx_virtual_intr_delivery )
+    {
+        if (trig)
+            vmx_set_eoi_exit_bitmap(v, vector);
+        else
+            vmx_clear_eoi_exit_bitmap(v, vector);
+    }
+}
+
+static int vmx_virtual_intr_delivery_enabled(void)
+{
+    return cpu_has_vmx_virtual_intr_delivery;
+}
+
 static struct hvm_function_table __read_mostly vmx_function_table = {
     .name                 = "VMX",
     .cpu_up_prepare       = vmx_cpu_up_prepare,
@@ -1548,7 +1564,9 @@ static struct hvm_function_table __read_
     .nhvm_vmcx_guest_intercepts_trap = nvmx_intercepts_exception,
     .nhvm_vcpu_vmexit_trap = nvmx_vmexit_trap,
     .nhvm_intr_blocked    = nvmx_intr_blocked,
-    .nhvm_domain_relinquish_resources = nvmx_domain_relinquish_resources
+    .nhvm_domain_relinquish_resources = nvmx_domain_relinquish_resources,
+    .update_eoi_exit_bitmap = vmx_update_eoi_exit_bitmap,
+    .virtual_intr_delivery_enabled = vmx_virtual_intr_delivery_enabled
 };
 
 struct hvm_function_table * __init start_vmx(void)
@@ -2284,6 +2302,17 @@ static int vmx_handle_apic_write(void)
     return vlapic_apicv_write(current, offset);
 }
 
+/*
+ * When "Virtual Interrupt Delivery" is enabled, this function is used
+ * to handle EOI-induced VM exit
+ */
+void vmx_handle_EOI_induced_exit(struct vlapic *vlapic, int vector)
+{
+    ASSERT(cpu_has_vmx_virtual_intr_delivery);
+
+    vlapic_handle_EOI_induced_exit(vlapic, vector);
+}
+
 void vmx_vmexit_handler(struct cpu_user_regs *regs)
 {
     unsigned int exit_reason, idtv_info, intr_info = 0, vector = 0;
@@ -2677,6 +2706,16 @@ void vmx_vmexit_handler(struct cpu_user_
             hvm_inject_hw_exception(TRAP_gp_fault, 0);
         break;
 
+    case EXIT_REASON_EOI_INDUCED:
+    {
+        int vector;
+        exit_qualification = __vmread(EXIT_QUALIFICATION);
+        vector = exit_qualification & 0xff;
+
+        vmx_handle_EOI_induced_exit(vcpu_vlapic(current), vector);
+        break;
+    }
+
     case EXIT_REASON_IO_INSTRUCTION:
         exit_qualification = __vmread(EXIT_QUALIFICATION);
         if ( exit_qualification & 0x10 )
diff -r 7c6844dd4a0d -r e3724bdf9403 xen/arch/x86/hvm/vpt.c
--- a/xen/arch/x86/hvm/vpt.c	Tue Sep 11 15:34:36 2012 +0800
+++ b/xen/arch/x86/hvm/vpt.c	Thu Sep 13 12:22:54 2012 +0800
@@ -212,7 +212,7 @@ static void pt_timer_fn(void *data)
     pt_unlock(pt);
 }
 
-void pt_update_irq(struct vcpu *v)
+int pt_update_irq(struct vcpu *v)
 {
     struct list_head *head = &v->arch.hvm_vcpu.tm_list;
     struct periodic_time *pt, *temp, *earliest_pt = NULL;
@@ -245,7 +245,7 @@ void pt_update_irq(struct vcpu *v)
     if ( earliest_pt == NULL )
     {
         spin_unlock(&v->arch.hvm_vcpu.tm_lock);
-        return;
+        return -1;
     }
 
     earliest_pt->irq_issued = 1;
@@ -263,6 +263,17 @@ void pt_update_irq(struct vcpu *v)
         hvm_isa_irq_deassert(v->domain, irq);
         hvm_isa_irq_assert(v->domain, irq);
     }
+
+    /*
+     * If periodic timer interrut is handled by lapic, its vector in
+     * IRR is returned and used to set eoi_exit_bitmap for virtual
+     * interrupt delivery case. Otherwise return -1 to do nothing.  
+     */ 
+    if ( vlapic_accept_pic_intr(v) &&
+         (&v->domain->arch.hvm_domain)->vpic[0].int_output )
+        return -1;
+    else 
+        return pt_irq_vector(earliest_pt, hvm_intsrc_lapic);
 }
 
 static struct periodic_time *is_pt_irq(
diff -r 7c6844dd4a0d -r e3724bdf9403 xen/include/asm-x86/hvm/hvm.h
--- a/xen/include/asm-x86/hvm/hvm.h	Tue Sep 11 15:34:36 2012 +0800
+++ b/xen/include/asm-x86/hvm/hvm.h	Thu Sep 13 12:22:54 2012 +0800
@@ -180,6 +180,10 @@ struct hvm_function_table {
 
     enum hvm_intblk (*nhvm_intr_blocked)(struct vcpu *v);
     void (*nhvm_domain_relinquish_resources)(struct domain *d);
+
+    /* Virtual interrupt delivery */
+    void (*update_eoi_exit_bitmap)(struct vcpu *v, u8 vector, u8 trig);
+    int (*virtual_intr_delivery_enabled)(void);
 };
 
 extern struct hvm_function_table hvm_funcs;
diff -r 7c6844dd4a0d -r e3724bdf9403 xen/include/asm-x86/hvm/vlapic.h
--- a/xen/include/asm-x86/hvm/vlapic.h	Tue Sep 11 15:34:36 2012 +0800
+++ b/xen/include/asm-x86/hvm/vlapic.h	Thu Sep 13 12:22:54 2012 +0800
@@ -100,6 +100,7 @@ int vlapic_accept_pic_intr(struct vcpu *
 void vlapic_adjust_i8259_target(struct domain *d);
 
 void vlapic_EOI_set(struct vlapic *vlapic);
+void vlapic_handle_EOI_induced_exit(struct vlapic *vlapic, int vector);
 
 int vlapic_ipi(struct vlapic *vlapic, uint32_t icr_low, uint32_t icr_high);
 
diff -r 7c6844dd4a0d -r e3724bdf9403 xen/include/asm-x86/hvm/vmx/vmcs.h
--- a/xen/include/asm-x86/hvm/vmx/vmcs.h	Tue Sep 11 15:34:36 2012 +0800
+++ b/xen/include/asm-x86/hvm/vmx/vmcs.h	Thu Sep 13 12:22:54 2012 +0800
@@ -110,6 +110,9 @@ struct arch_vmx_struct {
     unsigned int         host_msr_count;
     struct vmx_msr_entry *host_msr_area;
 
+    uint32_t             eoi_exitmap_changed;
+    uint64_t             eoi_exit_bitmap[4];
+
     unsigned long        host_cr0;
 
     /* Is the guest in real mode? */
@@ -183,6 +186,7 @@ extern u32 vmx_vmentry_control;
 #define SECONDARY_EXEC_WBINVD_EXITING           0x00000040
 #define SECONDARY_EXEC_UNRESTRICTED_GUEST       0x00000080
 #define SECONDARY_EXEC_APIC_REGISTER_VIRT       0x00000100
+#define SECONDARY_EXEC_VIRTUAL_INTR_DELIVERY    0x00000200
 #define SECONDARY_EXEC_PAUSE_LOOP_EXITING       0x00000400
 #define SECONDARY_EXEC_ENABLE_INVPCID           0x00001000
 extern u32 vmx_secondary_exec_control;
@@ -233,6 +237,8 @@ extern bool_t cpu_has_vmx_ins_outs_instr
     (vmx_secondary_exec_control & SECONDARY_EXEC_PAUSE_LOOP_EXITING)
 #define cpu_has_vmx_apic_reg_virt \
     (vmx_secondary_exec_control & SECONDARY_EXEC_APIC_REGISTER_VIRT)
+#define cpu_has_vmx_virtual_intr_delivery \
+    (vmx_secondary_exec_control & SECONDARY_EXEC_VIRTUAL_INTR_DELIVERY)
 
 /* GUEST_INTERRUPTIBILITY_INFO flags. */
 #define VMX_INTR_SHADOW_STI             0x00000001
@@ -251,6 +257,7 @@ enum vmcs_field {
     GUEST_GS_SELECTOR               = 0x0000080a,
     GUEST_LDTR_SELECTOR             = 0x0000080c,
     GUEST_TR_SELECTOR               = 0x0000080e,
+    GUEST_INTR_STATUS               = 0x00000810,
     HOST_ES_SELECTOR                = 0x00000c00,
     HOST_CS_SELECTOR                = 0x00000c02,
     HOST_SS_SELECTOR                = 0x00000c04,
@@ -278,6 +285,14 @@ enum vmcs_field {
     APIC_ACCESS_ADDR_HIGH           = 0x00002015,
     EPT_POINTER                     = 0x0000201a,
     EPT_POINTER_HIGH                = 0x0000201b,
+    EOI_EXIT_BITMAP0                = 0x0000201c,
+    EOI_EXIT_BITMAP0_HIGH           = 0x0000201d,
+    EOI_EXIT_BITMAP1                = 0x0000201e,
+    EOI_EXIT_BITMAP1_HIGH           = 0x0000201f,
+    EOI_EXIT_BITMAP2                = 0x00002020,
+    EOI_EXIT_BITMAP2_HIGH           = 0x00002021,
+    EOI_EXIT_BITMAP3                = 0x00002022,
+    EOI_EXIT_BITMAP3_HIGH           = 0x00002023,
     GUEST_PHYSICAL_ADDRESS          = 0x00002400,
     GUEST_PHYSICAL_ADDRESS_HIGH     = 0x00002401,
     VMCS_LINK_POINTER               = 0x00002800,
@@ -398,6 +413,8 @@ int vmx_write_guest_msr(u32 msr, u64 val
 int vmx_add_guest_msr(u32 msr);
 int vmx_add_host_load_msr(u32 msr);
 void vmx_vmcs_switch(struct vmcs_struct *from, struct vmcs_struct *to);
+void vmx_set_eoi_exit_bitmap(struct vcpu *v, u8 vector);
+void vmx_clear_eoi_exit_bitmap(struct vcpu *v, u8 vector);
 
 #endif /* ASM_X86_HVM_VMX_VMCS_H__ */
 
diff -r 7c6844dd4a0d -r e3724bdf9403 xen/include/asm-x86/hvm/vmx/vmx.h
--- a/xen/include/asm-x86/hvm/vmx/vmx.h	Tue Sep 11 15:34:36 2012 +0800
+++ b/xen/include/asm-x86/hvm/vmx/vmx.h	Thu Sep 13 12:22:54 2012 +0800
@@ -119,6 +119,7 @@ void vmx_update_cpu_exec_control(struct 
 #define EXIT_REASON_MCE_DURING_VMENTRY  41
 #define EXIT_REASON_TPR_BELOW_THRESHOLD 43
 #define EXIT_REASON_APIC_ACCESS         44
+#define EXIT_REASON_EOI_INDUCED         45
 #define EXIT_REASON_ACCESS_GDTR_OR_IDTR 46
 #define EXIT_REASON_ACCESS_LDTR_OR_TR   47
 #define EXIT_REASON_EPT_VIOLATION       48
diff -r 7c6844dd4a0d -r e3724bdf9403 xen/include/asm-x86/hvm/vpt.h
--- a/xen/include/asm-x86/hvm/vpt.h	Tue Sep 11 15:34:36 2012 +0800
+++ b/xen/include/asm-x86/hvm/vpt.h	Thu Sep 13 12:22:54 2012 +0800
@@ -141,7 +141,7 @@ struct pl_time {    /* platform time */
 
 void pt_save_timer(struct vcpu *v);
 void pt_restore_timer(struct vcpu *v);
-void pt_update_irq(struct vcpu *v);
+int pt_update_irq(struct vcpu *v);
 void pt_intr_post(struct vcpu *v, struct hvm_intack intack);
 void pt_migrate(struct vcpu *v);
 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 13 10:14:07 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Sep 2012 10:14:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TC6QS-0002gF-4M; Thu, 13 Sep 2012 10:13:36 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jiongxi.li@intel.com>) id 1TC6QO-0002dq-0f
	for xen-devel@lists.xen.org; Thu, 13 Sep 2012 10:13:34 +0000
Received: from [85.158.138.51:46430] by server-10.bemta-3.messagelabs.com id
	81/DE-10411-BC1B1505; Thu, 13 Sep 2012 10:13:31 +0000
X-Env-Sender: jiongxi.li@intel.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1347531204!28655865!2
X-Originating-IP: [143.182.124.37]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMzcgPT4gMjAxNjM2\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20584 invoked from network); 13 Sep 2012 10:13:31 -0000
Received: from mga14.intel.com (HELO mga14.intel.com) (143.182.124.37)
	by server-9.tower-174.messagelabs.com with SMTP;
	13 Sep 2012 10:13:31 -0000
Received: from azsmga002.ch.intel.com ([10.2.17.35])
	by azsmga102.ch.intel.com with ESMTP; 13 Sep 2012 03:13:30 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.80,416,1344236400"; d="scan'208";a="144601483"
Received: from fmsmsx107.amr.corp.intel.com ([10.19.9.54])
	by AZSMGA002.ch.intel.com with ESMTP; 13 Sep 2012 03:13:30 -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; Thu, 13 Sep 2012 03:13:29 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.239]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.175]) with mapi id
	14.01.0355.002; Thu, 13 Sep 2012 18:13:28 +0800
From: "Li, Jiongxi" <jiongxi.li@intel.com>
To: "'xen-devel@lists.xen.org'" <xen-devel@lists.xen.org>
Thread-Topic: [ PATCH v2 0/3] xen: enable APIC-Register Virtualization,
	Virtual-interrupt delivery and add virtual x2apic support
Thread-Index: Ac2RkYwcGctp5410TmmYGfclsA3yng==
Date: Thu, 13 Sep 2012 10:13:27 +0000
Message-ID: <D9137FCD9CFF644B965863BCFBEDABB8780453@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: "Zhang, Yang Z" <yang.z.zhang@intel.com>, "Shan,
	Haitao" <haitao.shan@intel.com>, Keir Fraser <keir@xen.org>, "Zhang, 
	Xiantao" <xiantao.zhang@intel.com>, Jan Beulich <JBeulich@suse.com>
Subject: [Xen-devel] [ PATCH v2 0/3] xen: enable APIC-Register
 Virtualization, Virtual-interrupt delivery and add virtual x2apic 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

The VMCS includes controls that enable the virtualization of interrupts and the Advanced Programmable Interrupt Controller (APIC).
When these controls are used, the processor will emulate many accesses to the APIC, track the state of the virtual APIC, and deliver virtual interrupts - all in VMX non-root operation without a VM exit.
You can refer to Chapter 29 of the latest SDM.
This series of patches enable APIC-Register Virtualization and Virtual-interrupt delivery.

PATCH 1/3: Enable APIC-Register Virtualization.

PATCH 2/3: Enable Virtual-interrupt delivery.

PATCH 3/3: Add virtual x2apic support

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 13 10:14:07 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Sep 2012 10:14:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TC6QS-0002gF-4M; Thu, 13 Sep 2012 10:13:36 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jiongxi.li@intel.com>) id 1TC6QO-0002dq-0f
	for xen-devel@lists.xen.org; Thu, 13 Sep 2012 10:13:34 +0000
Received: from [85.158.138.51:46430] by server-10.bemta-3.messagelabs.com id
	81/DE-10411-BC1B1505; Thu, 13 Sep 2012 10:13:31 +0000
X-Env-Sender: jiongxi.li@intel.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1347531204!28655865!2
X-Originating-IP: [143.182.124.37]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMzcgPT4gMjAxNjM2\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20584 invoked from network); 13 Sep 2012 10:13:31 -0000
Received: from mga14.intel.com (HELO mga14.intel.com) (143.182.124.37)
	by server-9.tower-174.messagelabs.com with SMTP;
	13 Sep 2012 10:13:31 -0000
Received: from azsmga002.ch.intel.com ([10.2.17.35])
	by azsmga102.ch.intel.com with ESMTP; 13 Sep 2012 03:13:30 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.80,416,1344236400"; d="scan'208";a="144601483"
Received: from fmsmsx107.amr.corp.intel.com ([10.19.9.54])
	by AZSMGA002.ch.intel.com with ESMTP; 13 Sep 2012 03:13:30 -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; Thu, 13 Sep 2012 03:13:29 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.239]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.175]) with mapi id
	14.01.0355.002; Thu, 13 Sep 2012 18:13:28 +0800
From: "Li, Jiongxi" <jiongxi.li@intel.com>
To: "'xen-devel@lists.xen.org'" <xen-devel@lists.xen.org>
Thread-Topic: [ PATCH v2 0/3] xen: enable APIC-Register Virtualization,
	Virtual-interrupt delivery and add virtual x2apic support
Thread-Index: Ac2RkYwcGctp5410TmmYGfclsA3yng==
Date: Thu, 13 Sep 2012 10:13:27 +0000
Message-ID: <D9137FCD9CFF644B965863BCFBEDABB8780453@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: "Zhang, Yang Z" <yang.z.zhang@intel.com>, "Shan,
	Haitao" <haitao.shan@intel.com>, Keir Fraser <keir@xen.org>, "Zhang, 
	Xiantao" <xiantao.zhang@intel.com>, Jan Beulich <JBeulich@suse.com>
Subject: [Xen-devel] [ PATCH v2 0/3] xen: enable APIC-Register
 Virtualization, Virtual-interrupt delivery and add virtual x2apic 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

The VMCS includes controls that enable the virtualization of interrupts and the Advanced Programmable Interrupt Controller (APIC).
When these controls are used, the processor will emulate many accesses to the APIC, track the state of the virtual APIC, and deliver virtual interrupts - all in VMX non-root operation without a VM exit.
You can refer to Chapter 29 of the latest SDM.
This series of patches enable APIC-Register Virtualization and Virtual-interrupt delivery.

PATCH 1/3: Enable APIC-Register Virtualization.

PATCH 2/3: Enable Virtual-interrupt delivery.

PATCH 3/3: Add virtual x2apic support

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 13 10:27:00 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Sep 2012 10:27: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 1TC6d8-0003ha-7h; Thu, 13 Sep 2012 10:26:42 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dave.martin@linaro.org>) id 1TC6d7-0003hV-8C
	for xen-devel@lists.xensource.com; Thu, 13 Sep 2012 10:26:41 +0000
X-Env-Sender: dave.martin@linaro.org
X-Msg-Ref: server-5.tower-27.messagelabs.com!1347531985!7456674!1
X-Originating-IP: [74.125.83.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1140 invoked from network); 13 Sep 2012 10:26:25 -0000
Received: from mail-ee0-f43.google.com (HELO mail-ee0-f43.google.com)
	(74.125.83.43)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Sep 2012 10:26:25 -0000
Received: by eekd4 with SMTP id d4so1905694eek.30
	for <xen-devel@lists.xensource.com>;
	Thu, 13 Sep 2012 03:26:25 -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=c3ery4G91MYeumM+yrHg35rOe3wBqsxXM+auTIfzecc=;
	b=gh4KyIuM54XMUcZz66/UaWlaakLxTb2nWIxun6pnKf1YCg5K05Uf/TIzirIjMyrPxs
	s98HZV/wdLYS6WDQ56JyUlyDHcA8QmhR/xWsYnDidXs3GNvTo30RDE6mk6ynR7Vc4x0Z
	j/ZpKBbvJJy578a8AModfPgp0VPPEne2ZN2HQFh/QCM9rW8Gj4v8rOaz10kcAiVTHPuI
	9a4Nj1DhX3hzvYOs79MNlKP92Bl24dAqV8fn7/27x1m4BGihgjtnISzyXzQuav8/nN3c
	eY38tVd+04x7ykdq7O8hu2ZaxEDRruhDZ/ZF5RwNL/boexUiR6B6D+OzuF3uvYOl1KDG
	ejpA==
Received: by 10.14.209.129 with SMTP id s1mr1950393eeo.24.1347531984983;
	Thu, 13 Sep 2012 03:26:24 -0700 (PDT)
Received: from linaro.org (fw-lnat.cambridge.arm.com. [217.140.96.63])
	by mx.google.com with ESMTPS id u8sm63858368eel.11.2012.09.13.03.26.22
	(version=SSLv3 cipher=OTHER); Thu, 13 Sep 2012 03:26:23 -0700 (PDT)
Date: Thu, 13 Sep 2012 11:26:16 +0100
From: Dave Martin <dave.martin@linaro.org>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20120913102616.GA2470@linaro.org>
References: <alpine.DEB.2.02.1208161618550.4850@kaball.uk.xensource.com>
	<1345131377-14713-6-git-send-email-stefano.stabellini@eu.citrix.com>
	<503BFCD8.5090804@gmail.com>
	<alpine.DEB.2.02.1208281823270.15568@kaball.uk.xensource.com>
	<alpine.DEB.2.02.1209121849200.15568@kaball.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <alpine.DEB.2.02.1209121849200.15568@kaball.uk.xensource.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Gm-Message-State: ALoCoQmvH4emuS/6Zrv4qjih69S/mcKt06jq1PZYdScbxwT2U/5u6Xd0olsriy/J1q+RsXnFWMe2
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linaro-dev@lists.linaro.org" <linaro-dev@lists.linaro.org>,
	Ian Campbell <Ian.Campbell@citrix.com>, "arnd@arndb.de" <arnd@arndb.de>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
	Marc Zyngier <Marc.Zyngier@arm.com>,
	"catalin.marinas@arm.com" <catalin.marinas@arm.com>,
	"devicetree-discuss@lists.ozlabs.org"
	<devicetree-discuss@lists.ozlabs.org>, "Tim \(Xen.org\)" <tim@xen.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	David Vrabel <david.vrabel@citrix.com>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Xen-devel] [PATCH v3 06/25] docs: Xen ARM DT bindings
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Sep 12, 2012 at 07:14:58PM +0100, Stefano Stabellini wrote:
> On Wed, 12 Sep 2012, Stefano Stabellini wrote:
> > On Tue, 28 Aug 2012, Rob Herring wrote:
> > > You should look at ePAPR 1.1 which defines hypervisor related bindings.
> > > While it is a PPC doc, we should reuse or extend what makes sense.
> > > 
> > > See section 7.5:
> > > 
> > > https://www.power.org/resources/downloads/Power_ePAPR_APPROVED_v1.1.pdf
> > 
> > Thanks for the link, I wasn't aware of ePAPR.
> > 
> > The hypervisor node defined by ePAPR is not very different from what I
> > am proposing. Should I try to be compatible with the hypervisor
> > specification above (as in compatible = "epapr,hypervisor-1.1")?
> > Or should I just use it as a reference for my own specification?
> > 
> > Personally I would rather avoid full compatibility with ePAPR.
> 
> In particular reading section 7.5, these are the required properties of
> the ePAPR hypervisor node:
> 
> - compatible = "epapr,hypervisor-1.1"
> compared to what I am proposing, it is laking information about what
> hypervisor we are talking about (xen, kvm, vmware, etc) and the version
> of the ABI (xen-4.2).
> 
> - hcall-instructions
> potentially interesting, but given that for Xen we are quite happy with
> HVC, we are not going to add any secondary hypercall mechanisms,
> therefore at the moment it would just result in a BUG if the specified
> hcall instruction is != HVC. Besides if somebody else wanted to
> implemented the Xen hypercall interface in a different way they could
> just reimplement the hypercall wrappers, that would be easier than
> trying to do it with this property.

Some thoughts on this:

We decided that embedding machine instructions into the DT is a fairly
awful idea when discussing how to describe low-level debug UARTs in the
DT.  I don't think it's a lot better in this case (never mind issues
like ARM versus Thumb, endianness etc.)

If we are going to attempt to describe the call interface, we should
do it symbolically, allowing the hypervisor interface code in the kernel
to choose (or, if necessary, generate) the right call wrappers.

We will have this issue for descrbing power firmware interfaces for
example: we already know that this functionality might require an SMC
or HVC instruction to call it, depending on the platform.

A hypervisor with only one call ABI could leave this to be implicit,
providing there is a version number property of similar to allow future
changes to be accommodated.


Cheers
---Dave

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 13 10:27:00 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Sep 2012 10:27: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 1TC6d8-0003ha-7h; Thu, 13 Sep 2012 10:26:42 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dave.martin@linaro.org>) id 1TC6d7-0003hV-8C
	for xen-devel@lists.xensource.com; Thu, 13 Sep 2012 10:26:41 +0000
X-Env-Sender: dave.martin@linaro.org
X-Msg-Ref: server-5.tower-27.messagelabs.com!1347531985!7456674!1
X-Originating-IP: [74.125.83.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1140 invoked from network); 13 Sep 2012 10:26:25 -0000
Received: from mail-ee0-f43.google.com (HELO mail-ee0-f43.google.com)
	(74.125.83.43)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Sep 2012 10:26:25 -0000
Received: by eekd4 with SMTP id d4so1905694eek.30
	for <xen-devel@lists.xensource.com>;
	Thu, 13 Sep 2012 03:26:25 -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=c3ery4G91MYeumM+yrHg35rOe3wBqsxXM+auTIfzecc=;
	b=gh4KyIuM54XMUcZz66/UaWlaakLxTb2nWIxun6pnKf1YCg5K05Uf/TIzirIjMyrPxs
	s98HZV/wdLYS6WDQ56JyUlyDHcA8QmhR/xWsYnDidXs3GNvTo30RDE6mk6ynR7Vc4x0Z
	j/ZpKBbvJJy578a8AModfPgp0VPPEne2ZN2HQFh/QCM9rW8Gj4v8rOaz10kcAiVTHPuI
	9a4Nj1DhX3hzvYOs79MNlKP92Bl24dAqV8fn7/27x1m4BGihgjtnISzyXzQuav8/nN3c
	eY38tVd+04x7ykdq7O8hu2ZaxEDRruhDZ/ZF5RwNL/boexUiR6B6D+OzuF3uvYOl1KDG
	ejpA==
Received: by 10.14.209.129 with SMTP id s1mr1950393eeo.24.1347531984983;
	Thu, 13 Sep 2012 03:26:24 -0700 (PDT)
Received: from linaro.org (fw-lnat.cambridge.arm.com. [217.140.96.63])
	by mx.google.com with ESMTPS id u8sm63858368eel.11.2012.09.13.03.26.22
	(version=SSLv3 cipher=OTHER); Thu, 13 Sep 2012 03:26:23 -0700 (PDT)
Date: Thu, 13 Sep 2012 11:26:16 +0100
From: Dave Martin <dave.martin@linaro.org>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20120913102616.GA2470@linaro.org>
References: <alpine.DEB.2.02.1208161618550.4850@kaball.uk.xensource.com>
	<1345131377-14713-6-git-send-email-stefano.stabellini@eu.citrix.com>
	<503BFCD8.5090804@gmail.com>
	<alpine.DEB.2.02.1208281823270.15568@kaball.uk.xensource.com>
	<alpine.DEB.2.02.1209121849200.15568@kaball.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <alpine.DEB.2.02.1209121849200.15568@kaball.uk.xensource.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Gm-Message-State: ALoCoQmvH4emuS/6Zrv4qjih69S/mcKt06jq1PZYdScbxwT2U/5u6Xd0olsriy/J1q+RsXnFWMe2
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linaro-dev@lists.linaro.org" <linaro-dev@lists.linaro.org>,
	Ian Campbell <Ian.Campbell@citrix.com>, "arnd@arndb.de" <arnd@arndb.de>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
	Marc Zyngier <Marc.Zyngier@arm.com>,
	"catalin.marinas@arm.com" <catalin.marinas@arm.com>,
	"devicetree-discuss@lists.ozlabs.org"
	<devicetree-discuss@lists.ozlabs.org>, "Tim \(Xen.org\)" <tim@xen.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	David Vrabel <david.vrabel@citrix.com>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Xen-devel] [PATCH v3 06/25] docs: Xen ARM DT bindings
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Sep 12, 2012 at 07:14:58PM +0100, Stefano Stabellini wrote:
> On Wed, 12 Sep 2012, Stefano Stabellini wrote:
> > On Tue, 28 Aug 2012, Rob Herring wrote:
> > > You should look at ePAPR 1.1 which defines hypervisor related bindings.
> > > While it is a PPC doc, we should reuse or extend what makes sense.
> > > 
> > > See section 7.5:
> > > 
> > > https://www.power.org/resources/downloads/Power_ePAPR_APPROVED_v1.1.pdf
> > 
> > Thanks for the link, I wasn't aware of ePAPR.
> > 
> > The hypervisor node defined by ePAPR is not very different from what I
> > am proposing. Should I try to be compatible with the hypervisor
> > specification above (as in compatible = "epapr,hypervisor-1.1")?
> > Or should I just use it as a reference for my own specification?
> > 
> > Personally I would rather avoid full compatibility with ePAPR.
> 
> In particular reading section 7.5, these are the required properties of
> the ePAPR hypervisor node:
> 
> - compatible = "epapr,hypervisor-1.1"
> compared to what I am proposing, it is laking information about what
> hypervisor we are talking about (xen, kvm, vmware, etc) and the version
> of the ABI (xen-4.2).
> 
> - hcall-instructions
> potentially interesting, but given that for Xen we are quite happy with
> HVC, we are not going to add any secondary hypercall mechanisms,
> therefore at the moment it would just result in a BUG if the specified
> hcall instruction is != HVC. Besides if somebody else wanted to
> implemented the Xen hypercall interface in a different way they could
> just reimplement the hypercall wrappers, that would be easier than
> trying to do it with this property.

Some thoughts on this:

We decided that embedding machine instructions into the DT is a fairly
awful idea when discussing how to describe low-level debug UARTs in the
DT.  I don't think it's a lot better in this case (never mind issues
like ARM versus Thumb, endianness etc.)

If we are going to attempt to describe the call interface, we should
do it symbolically, allowing the hypervisor interface code in the kernel
to choose (or, if necessary, generate) the right call wrappers.

We will have this issue for descrbing power firmware interfaces for
example: we already know that this functionality might require an SMC
or HVC instruction to call it, depending on the platform.

A hypervisor with only one call ABI could leave this to be implicit,
providing there is a version number property of similar to allow future
changes to be accommodated.


Cheers
---Dave

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 13 10:30:00 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Sep 2012 10:30:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TC6g6-0003no-Sz; Thu, 13 Sep 2012 10:29:46 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dave.martin@linaro.org>) id 1TC6g4-0003ng-WD
	for xen-devel@lists.xensource.com; Thu, 13 Sep 2012 10:29:45 +0000
Received: from [85.158.139.83:34462] by server-5.bemta-5.messagelabs.com id
	0B/FB-30514-895B1505; Thu, 13 Sep 2012 10:29:44 +0000
X-Env-Sender: dave.martin@linaro.org
X-Msg-Ref: server-12.tower-182.messagelabs.com!1347532183!30119682!1
X-Originating-IP: [74.125.83.43]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
  RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28467 invoked from network); 13 Sep 2012 10:29:43 -0000
Received: from mail-ee0-f43.google.com (HELO mail-ee0-f43.google.com)
	(74.125.83.43)
	by server-12.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Sep 2012 10:29:43 -0000
Received: by eekd4 with SMTP id d4so1907546eek.30
	for <xen-devel@lists.xensource.com>;
	Thu, 13 Sep 2012 03:29:43 -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=0Kmcr0WepNlbKv1G40mys8wlKIL/5R9Xq6cvivaEmcA=;
	b=T8ywytrhMlY1IM094DZfgBku5He3j7/0etY6MoBLbNBa2HBcF/5AVUviZ/Rn9lw/Rb
	VWb2kwiYGvfGMmQdu5kYxVU8/emK6XGfTfrP6sAX0btdODdhzv3dwTJnePv4RpXlI0cd
	KSiNrbrBPIK8ca1CBTGVbH75ciFUzVYbKJjOgGza6uBgOc6ZAj+XYIU5mIeSVIgvMtfh
	IjK9PvFokYwy8NsejkuHfvuDRzfzEYP99jxUnXzeaSHfbOvI76iPswX6L9PwZaQbtZbC
	5i2NU8qTaHQ7IaBceK0eAmN0qUf9olkj3Pw9wZ1Jkk5byLzubNHwtp+h4Ks9igTDHcoK
	ugrA==
Received: by 10.14.4.198 with SMTP id 46mr2005911eej.11.1347532183326;
	Thu, 13 Sep 2012 03:29:43 -0700 (PDT)
Received: from linaro.org (fw-lnat.cambridge.arm.com. [217.140.96.63])
	by mx.google.com with ESMTPS id y1sm63915037eel.0.2012.09.13.03.29.40
	(version=SSLv3 cipher=OTHER); Thu, 13 Sep 2012 03:29:42 -0700 (PDT)
Date: Thu, 13 Sep 2012 11:29:38 +0100
From: Dave Martin <dave.martin@linaro.org>
To: Rob Herring <robherring2@gmail.com>
Message-ID: <20120913102938.GB2470@linaro.org>
References: <alpine.DEB.2.02.1208161618550.4850@kaball.uk.xensource.com>
	<1345131377-14713-6-git-send-email-stefano.stabellini@eu.citrix.com>
	<503BFCD8.5090804@gmail.com>
	<alpine.DEB.2.02.1208281823270.15568@kaball.uk.xensource.com>
	<alpine.DEB.2.02.1209121849200.15568@kaball.uk.xensource.com>
	<50514634.3080303@gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <50514634.3080303@gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Gm-Message-State: ALoCoQmSzBVViKQLQ6amL674kiWyaBxhSZVS0XHQDiF0TveGQY+TcHA8Gcu7+Kjf92as3RdAx9oz
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linaro-dev@lists.linaro.org" <linaro-dev@lists.linaro.org>,
	Ian Campbell <Ian.Campbell@citrix.com>, "arnd@arndb.de" <arnd@arndb.de>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
	Marc Zyngier <marc.zyngier@arm.com>,
	"catalin.marinas@arm.com" <catalin.marinas@arm.com>,
	"devicetree-discuss@lists.ozlabs.org"
	<devicetree-discuss@lists.ozlabs.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	"Tim \(Xen.org\)" <tim@xen.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	David Vrabel <david.vrabel@citrix.com>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Xen-devel] [PATCH v3 06/25] docs: Xen ARM DT bindings
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Sep 12, 2012 at 09:34:28PM -0500, Rob Herring wrote:
> On 09/12/2012 01:14 PM, Stefano Stabellini wrote:
> > On Wed, 12 Sep 2012, Stefano Stabellini wrote:
> >> On Tue, 28 Aug 2012, Rob Herring wrote:
> >>> You should look at ePAPR 1.1 which defines hypervisor related bindings.
> >>> While it is a PPC doc, we should reuse or extend what makes sense.
> >>>
> >>> See section 7.5:
> >>>
> >>> https://www.power.org/resources/downloads/Power_ePAPR_APPROVED_v1.1.pdf
> >>
> >> Thanks for the link, I wasn't aware of ePAPR.
> >>
> >> The hypervisor node defined by ePAPR is not very different from what I
> >> am proposing. Should I try to be compatible with the hypervisor
> >> specification above (as in compatible = "epapr,hypervisor-1.1")?
> >> Or should I just use it as a reference for my own specification?
> >>
> >> Personally I would rather avoid full compatibility with ePAPR.
> > 
> > In particular reading section 7.5, these are the required properties of
> > the ePAPR hypervisor node:
> > 
> > - compatible = "epapr,hypervisor-1.1"
> > compared to what I am proposing, it is laking information about what
> > hypervisor we are talking about (xen, kvm, vmware, etc) and the version
> > of the ABI (xen-4.2).
> 
> compatible properties are often changed. If we do deviate on the rest of
> the binding, then it needs to be different.
> 
> Turns out that powerpc KVM guests use "linux,kvm" and "epapr,hypervisor"
> doesn't even appear in the kernel.
> 
> We also perhaps have to consider the possibility of Xen on PowerPC. Then
> alignment is more important.
> 
> > - hcall-instructions
> > potentially interesting, but given that for Xen we are quite happy with
> > HVC, we are not going to add any secondary hypercall mechanisms,
> > therefore at the moment it would just result in a BUG if the specified
> > hcall instruction is != HVC. Besides if somebody else wanted to
> > implemented the Xen hypercall interface in a different way they could
> > just reimplement the hypercall wrappers, that would be easier than
> > trying to do it with this property.
> 
> It's really about the parameters passed with the HVC. The ePAPR may be a
> good model for defining this. Just grepping "hypervisor" under
> arch/powerpc, it's pretty clear hypervisor support happened first and
> the ePAPR came second. Hopefully we can avoid that for ARM.

Do you think it's feasible to standardise on some interoperable ABI for
kvm and Xen?  This sounds pretty optimistic, but I'm not aware of all
the technicalities, or what possible third-party hypervisors are out
there.

If we could do it, it would be good.  But I have my doubts about the
feasibility and the benefits.  If different hypervisors are significantly
imcompatible, then having a common low-level ABI doesn't help all that
much.

Cheers
---Dave

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 13 10:30:00 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Sep 2012 10:30:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TC6g6-0003no-Sz; Thu, 13 Sep 2012 10:29:46 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dave.martin@linaro.org>) id 1TC6g4-0003ng-WD
	for xen-devel@lists.xensource.com; Thu, 13 Sep 2012 10:29:45 +0000
Received: from [85.158.139.83:34462] by server-5.bemta-5.messagelabs.com id
	0B/FB-30514-895B1505; Thu, 13 Sep 2012 10:29:44 +0000
X-Env-Sender: dave.martin@linaro.org
X-Msg-Ref: server-12.tower-182.messagelabs.com!1347532183!30119682!1
X-Originating-IP: [74.125.83.43]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
  RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28467 invoked from network); 13 Sep 2012 10:29:43 -0000
Received: from mail-ee0-f43.google.com (HELO mail-ee0-f43.google.com)
	(74.125.83.43)
	by server-12.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Sep 2012 10:29:43 -0000
Received: by eekd4 with SMTP id d4so1907546eek.30
	for <xen-devel@lists.xensource.com>;
	Thu, 13 Sep 2012 03:29:43 -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=0Kmcr0WepNlbKv1G40mys8wlKIL/5R9Xq6cvivaEmcA=;
	b=T8ywytrhMlY1IM094DZfgBku5He3j7/0etY6MoBLbNBa2HBcF/5AVUviZ/Rn9lw/Rb
	VWb2kwiYGvfGMmQdu5kYxVU8/emK6XGfTfrP6sAX0btdODdhzv3dwTJnePv4RpXlI0cd
	KSiNrbrBPIK8ca1CBTGVbH75ciFUzVYbKJjOgGza6uBgOc6ZAj+XYIU5mIeSVIgvMtfh
	IjK9PvFokYwy8NsejkuHfvuDRzfzEYP99jxUnXzeaSHfbOvI76iPswX6L9PwZaQbtZbC
	5i2NU8qTaHQ7IaBceK0eAmN0qUf9olkj3Pw9wZ1Jkk5byLzubNHwtp+h4Ks9igTDHcoK
	ugrA==
Received: by 10.14.4.198 with SMTP id 46mr2005911eej.11.1347532183326;
	Thu, 13 Sep 2012 03:29:43 -0700 (PDT)
Received: from linaro.org (fw-lnat.cambridge.arm.com. [217.140.96.63])
	by mx.google.com with ESMTPS id y1sm63915037eel.0.2012.09.13.03.29.40
	(version=SSLv3 cipher=OTHER); Thu, 13 Sep 2012 03:29:42 -0700 (PDT)
Date: Thu, 13 Sep 2012 11:29:38 +0100
From: Dave Martin <dave.martin@linaro.org>
To: Rob Herring <robherring2@gmail.com>
Message-ID: <20120913102938.GB2470@linaro.org>
References: <alpine.DEB.2.02.1208161618550.4850@kaball.uk.xensource.com>
	<1345131377-14713-6-git-send-email-stefano.stabellini@eu.citrix.com>
	<503BFCD8.5090804@gmail.com>
	<alpine.DEB.2.02.1208281823270.15568@kaball.uk.xensource.com>
	<alpine.DEB.2.02.1209121849200.15568@kaball.uk.xensource.com>
	<50514634.3080303@gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <50514634.3080303@gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Gm-Message-State: ALoCoQmSzBVViKQLQ6amL674kiWyaBxhSZVS0XHQDiF0TveGQY+TcHA8Gcu7+Kjf92as3RdAx9oz
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linaro-dev@lists.linaro.org" <linaro-dev@lists.linaro.org>,
	Ian Campbell <Ian.Campbell@citrix.com>, "arnd@arndb.de" <arnd@arndb.de>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
	Marc Zyngier <marc.zyngier@arm.com>,
	"catalin.marinas@arm.com" <catalin.marinas@arm.com>,
	"devicetree-discuss@lists.ozlabs.org"
	<devicetree-discuss@lists.ozlabs.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	"Tim \(Xen.org\)" <tim@xen.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	David Vrabel <david.vrabel@citrix.com>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Xen-devel] [PATCH v3 06/25] docs: Xen ARM DT bindings
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Sep 12, 2012 at 09:34:28PM -0500, Rob Herring wrote:
> On 09/12/2012 01:14 PM, Stefano Stabellini wrote:
> > On Wed, 12 Sep 2012, Stefano Stabellini wrote:
> >> On Tue, 28 Aug 2012, Rob Herring wrote:
> >>> You should look at ePAPR 1.1 which defines hypervisor related bindings.
> >>> While it is a PPC doc, we should reuse or extend what makes sense.
> >>>
> >>> See section 7.5:
> >>>
> >>> https://www.power.org/resources/downloads/Power_ePAPR_APPROVED_v1.1.pdf
> >>
> >> Thanks for the link, I wasn't aware of ePAPR.
> >>
> >> The hypervisor node defined by ePAPR is not very different from what I
> >> am proposing. Should I try to be compatible with the hypervisor
> >> specification above (as in compatible = "epapr,hypervisor-1.1")?
> >> Or should I just use it as a reference for my own specification?
> >>
> >> Personally I would rather avoid full compatibility with ePAPR.
> > 
> > In particular reading section 7.5, these are the required properties of
> > the ePAPR hypervisor node:
> > 
> > - compatible = "epapr,hypervisor-1.1"
> > compared to what I am proposing, it is laking information about what
> > hypervisor we are talking about (xen, kvm, vmware, etc) and the version
> > of the ABI (xen-4.2).
> 
> compatible properties are often changed. If we do deviate on the rest of
> the binding, then it needs to be different.
> 
> Turns out that powerpc KVM guests use "linux,kvm" and "epapr,hypervisor"
> doesn't even appear in the kernel.
> 
> We also perhaps have to consider the possibility of Xen on PowerPC. Then
> alignment is more important.
> 
> > - hcall-instructions
> > potentially interesting, but given that for Xen we are quite happy with
> > HVC, we are not going to add any secondary hypercall mechanisms,
> > therefore at the moment it would just result in a BUG if the specified
> > hcall instruction is != HVC. Besides if somebody else wanted to
> > implemented the Xen hypercall interface in a different way they could
> > just reimplement the hypercall wrappers, that would be easier than
> > trying to do it with this property.
> 
> It's really about the parameters passed with the HVC. The ePAPR may be a
> good model for defining this. Just grepping "hypervisor" under
> arch/powerpc, it's pretty clear hypervisor support happened first and
> the ePAPR came second. Hopefully we can avoid that for ARM.

Do you think it's feasible to standardise on some interoperable ABI for
kvm and Xen?  This sounds pretty optimistic, but I'm not aware of all
the technicalities, or what possible third-party hypervisors are out
there.

If we could do it, it would be good.  But I have my doubts about the
feasibility and the benefits.  If different hypervisors are significantly
imcompatible, then having a common low-level ABI doesn't help all that
much.

Cheers
---Dave

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 13 11:07:24 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Sep 2012 11: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 1TC7G5-00047f-1A; Thu, 13 Sep 2012 11:06:57 +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 1TC7G3-00047a-SF
	for xen-devel@lists.xen.org; Thu, 13 Sep 2012 11:06:56 +0000
Received: from [85.158.139.83:53778] by server-9.bemta-5.messagelabs.com id
	DA/A7-20529-F4EB1505; Thu, 13 Sep 2012 11:06:55 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1347534413!30278471!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDkwMjg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1500 invoked from network); 13 Sep 2012 11:06:54 -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;
	13 Sep 2012 11:06:54 -0000
X-IronPort-AV: E=Sophos;i="4.80,416,1344211200"; d="scan'208";a="14517431"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Sep 2012 11:06: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.279.1; Thu, 13 Sep 2012 12:06:16 +0100
Date: Thu, 13 Sep 2012 12:05:35 +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: <5051A83B020000780009AF93@nat28.tlf.novell.com>
Message-ID: <alpine.DEB.2.02.1209131203270.15568@kaball.uk.xensource.com>
References: <A21691DE07B84740B5F0B81466D5148A23BCF1DF@SHSMSX102.ccr.corp.intel.com>
	<20120907174922.GA13040@phenom.dumpdata.com>
	<A21691DE07B84740B5F0B81466D5148A23BF6833@SHSMSX102.ccr.corp.intel.com>
	<5051A83B020000780009AF93@nat28.tlf.novell.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>,
	Ronghui Duan <ronghui.duan@intel.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [RFC v1 0/5] VBD: enlarge max segment per request
 in blkfront
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 13 Sep 2012, Jan Beulich wrote:
> >>> On 13.09.12 at 04:28, "Duan, Ronghui" <ronghui.duan@intel.com> wrote:
> >> And with your patch got:
> >>   read : io=4096.0MB, bw=92606KB/s, iops=23151 , runt= 45292msec
> >> 
> >> without:
> >>   read : io=4096.0MB, bw=145187KB/s, iops=36296 , runt= 28889msec
> >> 
> > What type of backend file you are using? In order to remove the influence of 
> > cache in Dom0, I use a physical partition as backend.
> 
> But you certainly shouldn't be proposing features getting used
> unconditionally or by default that benefit one class of backing
> devices and severely penalize others.

Right.
I am wondering.. Considering that the in-kernel blkback is mainly used
with physical partitions, is it possible that your patches cause a
regression with unmodified backends that don't support the new protocol,
like QEMU for example?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 13 11:07:24 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Sep 2012 11: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 1TC7G5-00047f-1A; Thu, 13 Sep 2012 11:06:57 +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 1TC7G3-00047a-SF
	for xen-devel@lists.xen.org; Thu, 13 Sep 2012 11:06:56 +0000
Received: from [85.158.139.83:53778] by server-9.bemta-5.messagelabs.com id
	DA/A7-20529-F4EB1505; Thu, 13 Sep 2012 11:06:55 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1347534413!30278471!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDkwMjg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1500 invoked from network); 13 Sep 2012 11:06:54 -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;
	13 Sep 2012 11:06:54 -0000
X-IronPort-AV: E=Sophos;i="4.80,416,1344211200"; d="scan'208";a="14517431"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Sep 2012 11:06: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.279.1; Thu, 13 Sep 2012 12:06:16 +0100
Date: Thu, 13 Sep 2012 12:05:35 +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: <5051A83B020000780009AF93@nat28.tlf.novell.com>
Message-ID: <alpine.DEB.2.02.1209131203270.15568@kaball.uk.xensource.com>
References: <A21691DE07B84740B5F0B81466D5148A23BCF1DF@SHSMSX102.ccr.corp.intel.com>
	<20120907174922.GA13040@phenom.dumpdata.com>
	<A21691DE07B84740B5F0B81466D5148A23BF6833@SHSMSX102.ccr.corp.intel.com>
	<5051A83B020000780009AF93@nat28.tlf.novell.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>,
	Ronghui Duan <ronghui.duan@intel.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [RFC v1 0/5] VBD: enlarge max segment per request
 in blkfront
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 13 Sep 2012, Jan Beulich wrote:
> >>> On 13.09.12 at 04:28, "Duan, Ronghui" <ronghui.duan@intel.com> wrote:
> >> And with your patch got:
> >>   read : io=4096.0MB, bw=92606KB/s, iops=23151 , runt= 45292msec
> >> 
> >> without:
> >>   read : io=4096.0MB, bw=145187KB/s, iops=36296 , runt= 28889msec
> >> 
> > What type of backend file you are using? In order to remove the influence of 
> > cache in Dom0, I use a physical partition as backend.
> 
> But you certainly shouldn't be proposing features getting used
> unconditionally or by default that benefit one class of backing
> devices and severely penalize others.

Right.
I am wondering.. Considering that the in-kernel blkback is mainly used
with physical partitions, is it possible that your patches cause a
regression with unmodified backends that don't support the new protocol,
like QEMU for example?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 13 11:14:06 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Sep 2012 11:14:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TC7Ma-0004Gu-Sy; Thu, 13 Sep 2012 11:13:40 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1TC7MZ-0004Go-3u
	for xen-devel@lists.xensource.com; Thu, 13 Sep 2012 11:13:39 +0000
Received: from [85.158.143.99:47996] by server-3.bemta-4.messagelabs.com id
	BF/9D-08232-2EFB1505; Thu, 13 Sep 2012 11:13:38 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1347534817!18936522!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDkwMjg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29593 invoked from network); 13 Sep 2012 11:13:37 -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;
	13 Sep 2012 11:13:37 -0000
X-IronPort-AV: E=Sophos;i="4.80,416,1344211200"; d="scan'208";a="14517655"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Sep 2012 11:13:37 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Thu, 13 Sep 2012 12:13:36 +0100
Date: Thu, 13 Sep 2012 12:12:54 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Dave Martin <dave.martin@linaro.org>
In-Reply-To: <20120913102616.GA2470@linaro.org>
Message-ID: <alpine.DEB.2.02.1209131206510.15568@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1208161618550.4850@kaball.uk.xensource.com>
	<1345131377-14713-6-git-send-email-stefano.stabellini@eu.citrix.com>
	<503BFCD8.5090804@gmail.com>
	<alpine.DEB.2.02.1208281823270.15568@kaball.uk.xensource.com>
	<alpine.DEB.2.02.1209121849200.15568@kaball.uk.xensource.com>
	<20120913102616.GA2470@linaro.org>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linaro-dev@lists.linaro.org" <linaro-dev@lists.linaro.org>,
	Ian Campbell <Ian.Campbell@citrix.com>, "arnd@arndb.de" <arnd@arndb.de>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
	Marc Zyngier <Marc.Zyngier@arm.com>,
	"catalin.marinas@arm.com" <catalin.marinas@arm.com>,
	"devicetree-discuss@lists.ozlabs.org"
	<devicetree-discuss@lists.ozlabs.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"Tim \(Xen.org\)" <tim@xen.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	David Vrabel <david.vrabel@citrix.com>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Xen-devel] [PATCH v3 06/25] docs: Xen ARM DT bindings
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 13 Sep 2012, Dave Martin wrote:
> On Wed, Sep 12, 2012 at 07:14:58PM +0100, Stefano Stabellini wrote:
> > On Wed, 12 Sep 2012, Stefano Stabellini wrote:
> > - hcall-instructions
> > potentially interesting, but given that for Xen we are quite happy with
> > HVC, we are not going to add any secondary hypercall mechanisms,
> > therefore at the moment it would just result in a BUG if the specified
> > hcall instruction is != HVC. Besides if somebody else wanted to
> > implemented the Xen hypercall interface in a different way they could
> > just reimplement the hypercall wrappers, that would be easier than
> > trying to do it with this property.
> 
> Some thoughts on this:
> 
> We decided that embedding machine instructions into the DT is a fairly
> awful idea when discussing how to describe low-level debug UARTs in the
> DT.  I don't think it's a lot better in this case (never mind issues
> like ARM versus Thumb, endianness etc.)
> 
> If we are going to attempt to describe the call interface, we should
> do it symbolically, allowing the hypervisor interface code in the kernel
> to choose (or, if necessary, generate) the right call wrappers.
> 
> We will have this issue for descrbing power firmware interfaces for
> example: we already know that this functionality might require an SMC
> or HVC instruction to call it, depending on the platform.
> 
> A hypervisor with only one call ABI could leave this to be implicit,
> providing there is a version number property of similar to allow future
> changes to be accommodated.

I completely agree with Dave.
I have no problems adding a symbolic property to say "we are using hvc
with parameters on registers". I just want to avoid having actual
machine instructions (and potentially dealing with executing them) into
the DT.

Maybe we could have a "calling-convention" property that can be "xen"
or something else. When a new hypervisor vendor comes along it can
change the value of "calling-convention" to "foo".

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 13 11:14:06 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Sep 2012 11:14:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TC7Ma-0004Gu-Sy; Thu, 13 Sep 2012 11:13:40 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1TC7MZ-0004Go-3u
	for xen-devel@lists.xensource.com; Thu, 13 Sep 2012 11:13:39 +0000
Received: from [85.158.143.99:47996] by server-3.bemta-4.messagelabs.com id
	BF/9D-08232-2EFB1505; Thu, 13 Sep 2012 11:13:38 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1347534817!18936522!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDkwMjg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29593 invoked from network); 13 Sep 2012 11:13:37 -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;
	13 Sep 2012 11:13:37 -0000
X-IronPort-AV: E=Sophos;i="4.80,416,1344211200"; d="scan'208";a="14517655"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Sep 2012 11:13:37 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Thu, 13 Sep 2012 12:13:36 +0100
Date: Thu, 13 Sep 2012 12:12:54 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Dave Martin <dave.martin@linaro.org>
In-Reply-To: <20120913102616.GA2470@linaro.org>
Message-ID: <alpine.DEB.2.02.1209131206510.15568@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1208161618550.4850@kaball.uk.xensource.com>
	<1345131377-14713-6-git-send-email-stefano.stabellini@eu.citrix.com>
	<503BFCD8.5090804@gmail.com>
	<alpine.DEB.2.02.1208281823270.15568@kaball.uk.xensource.com>
	<alpine.DEB.2.02.1209121849200.15568@kaball.uk.xensource.com>
	<20120913102616.GA2470@linaro.org>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linaro-dev@lists.linaro.org" <linaro-dev@lists.linaro.org>,
	Ian Campbell <Ian.Campbell@citrix.com>, "arnd@arndb.de" <arnd@arndb.de>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
	Marc Zyngier <Marc.Zyngier@arm.com>,
	"catalin.marinas@arm.com" <catalin.marinas@arm.com>,
	"devicetree-discuss@lists.ozlabs.org"
	<devicetree-discuss@lists.ozlabs.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"Tim \(Xen.org\)" <tim@xen.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	David Vrabel <david.vrabel@citrix.com>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Xen-devel] [PATCH v3 06/25] docs: Xen ARM DT bindings
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 13 Sep 2012, Dave Martin wrote:
> On Wed, Sep 12, 2012 at 07:14:58PM +0100, Stefano Stabellini wrote:
> > On Wed, 12 Sep 2012, Stefano Stabellini wrote:
> > - hcall-instructions
> > potentially interesting, but given that for Xen we are quite happy with
> > HVC, we are not going to add any secondary hypercall mechanisms,
> > therefore at the moment it would just result in a BUG if the specified
> > hcall instruction is != HVC. Besides if somebody else wanted to
> > implemented the Xen hypercall interface in a different way they could
> > just reimplement the hypercall wrappers, that would be easier than
> > trying to do it with this property.
> 
> Some thoughts on this:
> 
> We decided that embedding machine instructions into the DT is a fairly
> awful idea when discussing how to describe low-level debug UARTs in the
> DT.  I don't think it's a lot better in this case (never mind issues
> like ARM versus Thumb, endianness etc.)
> 
> If we are going to attempt to describe the call interface, we should
> do it symbolically, allowing the hypervisor interface code in the kernel
> to choose (or, if necessary, generate) the right call wrappers.
> 
> We will have this issue for descrbing power firmware interfaces for
> example: we already know that this functionality might require an SMC
> or HVC instruction to call it, depending on the platform.
> 
> A hypervisor with only one call ABI could leave this to be implicit,
> providing there is a version number property of similar to allow future
> changes to be accommodated.

I completely agree with Dave.
I have no problems adding a symbolic property to say "we are using hvc
with parameters on registers". I just want to avoid having actual
machine instructions (and potentially dealing with executing them) into
the DT.

Maybe we could have a "calling-convention" property that can be "xen"
or something else. When a new hypervisor vendor comes along it can
change the value of "calling-convention" to "foo".

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 13 11:21:11 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Sep 2012 11:21:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TC7TP-0004Ri-Tg; Thu, 13 Sep 2012 11:20: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 1TC7TO-0004Rc-P5
	for xen-devel@lists.xensource.com; Thu, 13 Sep 2012 11:20:42 +0000
Received: from [85.158.143.35:12093] by server-3.bemta-4.messagelabs.com id
	57/8C-08232-A81C1505; Thu, 13 Sep 2012 11:20:42 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1347535189!11313112!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDkwMjg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20415 invoked from network); 13 Sep 2012 11:19:50 -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;
	13 Sep 2012 11:19:50 -0000
X-IronPort-AV: E=Sophos;i="4.80,416,1344211200"; d="scan'208";a="14517836"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Sep 2012 11:19: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.279.1; Thu, 13 Sep 2012 12:19:48 +0100
Date: Thu, 13 Sep 2012 12:19:06 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Dave Martin <dave.martin@linaro.org>
In-Reply-To: <20120913102938.GB2470@linaro.org>
Message-ID: <alpine.DEB.2.02.1209131215360.15568@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1208161618550.4850@kaball.uk.xensource.com>
	<1345131377-14713-6-git-send-email-stefano.stabellini@eu.citrix.com>
	<503BFCD8.5090804@gmail.com>
	<alpine.DEB.2.02.1208281823270.15568@kaball.uk.xensource.com>
	<alpine.DEB.2.02.1209121849200.15568@kaball.uk.xensource.com>
	<50514634.3080303@gmail.com> <20120913102938.GB2470@linaro.org>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linaro-dev@lists.linaro.org" <linaro-dev@lists.linaro.org>,
	Ian Campbell <Ian.Campbell@citrix.com>, "arnd@arndb.de" <arnd@arndb.de>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Marc Zyngier <marc.zyngier@arm.com>,
	"catalin.marinas@arm.com" <catalin.marinas@arm.com>,
	"devicetree-discuss@lists.ozlabs.org"
	<devicetree-discuss@lists.ozlabs.org>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
	"Tim \(Xen.org\)" <tim@xen.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Rob Herring <robherring2@gmail.com>,
	David Vrabel <david.vrabel@citrix.com>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Xen-devel] [PATCH v3 06/25] docs: Xen ARM DT bindings
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 13 Sep 2012, Dave Martin wrote:
> Do you think it's feasible to standardise on some interoperable ABI for
> kvm and Xen?  This sounds pretty optimistic, but I'm not aware of all
> the technicalities, or what possible third-party hypervisors are out
> there.
> 
> If we could do it, it would be good.  But I have my doubts about the
> feasibility and the benefits.  If different hypervisors are significantly
> imcompatible, then having a common low-level ABI doesn't help all that
> much.

It is not really possible because each hypervisor offers a different set
of hypercalls and has a different calling convention, so there is very
little we can do to unify them.

For example many of the current Xen hypercalls are to deal with the grant
table and event channels, that are Xen specific concepts completely
missing in KVM.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 13 11:21:11 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Sep 2012 11:21:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TC7TP-0004Ri-Tg; Thu, 13 Sep 2012 11:20: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 1TC7TO-0004Rc-P5
	for xen-devel@lists.xensource.com; Thu, 13 Sep 2012 11:20:42 +0000
Received: from [85.158.143.35:12093] by server-3.bemta-4.messagelabs.com id
	57/8C-08232-A81C1505; Thu, 13 Sep 2012 11:20:42 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1347535189!11313112!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDkwMjg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20415 invoked from network); 13 Sep 2012 11:19:50 -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;
	13 Sep 2012 11:19:50 -0000
X-IronPort-AV: E=Sophos;i="4.80,416,1344211200"; d="scan'208";a="14517836"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Sep 2012 11:19: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.279.1; Thu, 13 Sep 2012 12:19:48 +0100
Date: Thu, 13 Sep 2012 12:19:06 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Dave Martin <dave.martin@linaro.org>
In-Reply-To: <20120913102938.GB2470@linaro.org>
Message-ID: <alpine.DEB.2.02.1209131215360.15568@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1208161618550.4850@kaball.uk.xensource.com>
	<1345131377-14713-6-git-send-email-stefano.stabellini@eu.citrix.com>
	<503BFCD8.5090804@gmail.com>
	<alpine.DEB.2.02.1208281823270.15568@kaball.uk.xensource.com>
	<alpine.DEB.2.02.1209121849200.15568@kaball.uk.xensource.com>
	<50514634.3080303@gmail.com> <20120913102938.GB2470@linaro.org>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linaro-dev@lists.linaro.org" <linaro-dev@lists.linaro.org>,
	Ian Campbell <Ian.Campbell@citrix.com>, "arnd@arndb.de" <arnd@arndb.de>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Marc Zyngier <marc.zyngier@arm.com>,
	"catalin.marinas@arm.com" <catalin.marinas@arm.com>,
	"devicetree-discuss@lists.ozlabs.org"
	<devicetree-discuss@lists.ozlabs.org>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
	"Tim \(Xen.org\)" <tim@xen.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Rob Herring <robherring2@gmail.com>,
	David Vrabel <david.vrabel@citrix.com>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Xen-devel] [PATCH v3 06/25] docs: Xen ARM DT bindings
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 13 Sep 2012, Dave Martin wrote:
> Do you think it's feasible to standardise on some interoperable ABI for
> kvm and Xen?  This sounds pretty optimistic, but I'm not aware of all
> the technicalities, or what possible third-party hypervisors are out
> there.
> 
> If we could do it, it would be good.  But I have my doubts about the
> feasibility and the benefits.  If different hypervisors are significantly
> imcompatible, then having a common low-level ABI doesn't help all that
> much.

It is not really possible because each hypervisor offers a different set
of hypercalls and has a different calling convention, so there is very
little we can do to unify them.

For example many of the current Xen hypercalls are to deal with the grant
table and event channels, that are Xen specific concepts completely
missing in KVM.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 13 11:35:09 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Sep 2012 11: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 1TC7h4-0004dm-Q7; Thu, 13 Sep 2012 11:34: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 1TC7h3-0004dd-CW
	for xen-devel@lists.xensource.com; Thu, 13 Sep 2012 11:34:49 +0000
Received: from [85.158.143.35:14239] by server-1.bemta-4.messagelabs.com id
	1B/42-12504-8D4C1505; Thu, 13 Sep 2012 11:34:48 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1347536087!16717741!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDkwMjg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25782 invoked from network); 13 Sep 2012 11:34:47 -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 Sep 2012 11:34:47 -0000
X-IronPort-AV: E=Sophos;i="4.80,416,1344211200"; d="scan'208";a="14518187"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Sep 2012 11:34: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.279.1; Thu, 13 Sep 2012 12:34:29 +0100
Date: Thu, 13 Sep 2012 12:33:47 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Rob Herring <robherring2@gmail.com>
In-Reply-To: <50514634.3080303@gmail.com>
Message-ID: <alpine.DEB.2.02.1209131213260.15568@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1208161618550.4850@kaball.uk.xensource.com>
	<1345131377-14713-6-git-send-email-stefano.stabellini@eu.citrix.com>
	<503BFCD8.5090804@gmail.com>
	<alpine.DEB.2.02.1208281823270.15568@kaball.uk.xensource.com>
	<alpine.DEB.2.02.1209121849200.15568@kaball.uk.xensource.com>
	<50514634.3080303@gmail.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>,
	"linaro-dev@lists.linaro.org" <linaro-dev@lists.linaro.org>,
	Ian Campbell <Ian.Campbell@citrix.com>, "arnd@arndb.de" <arnd@arndb.de>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Marc Zyngier <marc.zyngier@arm.com>,
	"catalin.marinas@arm.com" <catalin.marinas@arm.com>,
	"devicetree-discuss@lists.ozlabs.org"
	<devicetree-discuss@lists.ozlabs.org>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
	"Tim \(Xen.org\)" <tim@xen.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	David Vrabel <david.vrabel@citrix.com>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Xen-devel] [PATCH v3 06/25] docs: Xen ARM DT bindings
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 13 Sep 2012, Rob Herring wrote:
> On 09/12/2012 01:14 PM, Stefano Stabellini wrote:
> > On Wed, 12 Sep 2012, Stefano Stabellini wrote:
> >> On Tue, 28 Aug 2012, Rob Herring wrote:
> >>> You should look at ePAPR 1.1 which defines hypervisor related bindings.
> >>> While it is a PPC doc, we should reuse or extend what makes sense.
> >>>
> >>> See section 7.5:
> >>>
> >>> https://www.power.org/resources/downloads/Power_ePAPR_APPROVED_v1.1.pdf
> >>
> >> Thanks for the link, I wasn't aware of ePAPR.
> >>
> >> The hypervisor node defined by ePAPR is not very different from what I
> >> am proposing. Should I try to be compatible with the hypervisor
> >> specification above (as in compatible = "epapr,hypervisor-1.1")?
> >> Or should I just use it as a reference for my own specification?
> >>
> >> Personally I would rather avoid full compatibility with ePAPR.
> > 
> > In particular reading section 7.5, these are the required properties of
> > the ePAPR hypervisor node:
> > 
> > - compatible = "epapr,hypervisor-1.1"
> > compared to what I am proposing, it is laking information about what
> > hypervisor we are talking about (xen, kvm, vmware, etc) and the version
> > of the ABI (xen-4.2).
> 
> compatible properties are often changed. If we do deviate on the rest of
> the binding, then it needs to be different.
> 
> Turns out that powerpc KVM guests use "linux,kvm" and "epapr,hypervisor"
> doesn't even appear in the kernel.
> 
> We also perhaps have to consider the possibility of Xen on PowerPC. Then
> alignment is more important.

OK. In that case I think that we can just use "xen,xen-4.2".


> > - hcall-instructions
> > potentially interesting, but given that for Xen we are quite happy with
> > HVC, we are not going to add any secondary hypercall mechanisms,
> > therefore at the moment it would just result in a BUG if the specified
> > hcall instruction is != HVC. Besides if somebody else wanted to
> > implemented the Xen hypercall interface in a different way they could
> > just reimplement the hypercall wrappers, that would be easier than
> > trying to do it with this property.
> 
> It's really about the parameters passed with the HVC. The ePAPR may be a
> good model for defining this. Just grepping "hypervisor" under
> arch/powerpc, it's pretty clear hypervisor support happened first and
> the ePAPR came second. Hopefully we can avoid that for ARM.

Right. As I wrote in the other email, we could have a new property to
select the calling convention (and therefore the hypercall wrappers) to
be used with the hypervisor.


> > - guest-id
> > we usually make a point in trying not to tell the guest its own domid
> > because if the VM gets migrated to a different host it acquires a new
> > domid, therefore it should not rely on it.
> > 
> > - guest-name
> > we could pass the guest name here, but I don't see how it could be
> > of any use.
> > 
> 
> I have no issue with these being optional.

OK, good.


> > On the other hand, thinking more about what Xen needs in the device
> > tree, I think we could improve the current spec by clarifying the
> > meaning of the memory region and interrupt properties we currently
> > require. I thought about moving them to two separate children node with
> > an explicit name:
> > 
> > ---
> > 
> > * Xen hypervisor device tree bindings
> > 
> 
> I really think we need to define ARM hypervisor device tree bindings
> first, then Xen specific bindings as an addition to that. I worry that
> the KVM folks aren't paying attention and then want something different
> later on.

The problem is that there isn't much in common between Xen and KVM at
least from the DT point of view. I am not sure what would go into this
common hypervisor node.
The three key pieces of information that we are currently passing in the
DT (xen-4.2, a memory region, a PPI) are Xen specific.

If one day KVM (or another hypervisor vendor) decides to support the Xen
interface, can't they just have the Xen specific binding with a slightly
different compatible node?
For example:

compatible = "linux,kvm", "xen,xen-4.2"

wouldn't that mean "I am KVM but I can support the Xen interface"?


> > Xen ARM virtual platforms shall have the following properties and
> > children nodes:
> > 
> > - compatible property:
> > 	compatible = "xen,xen", "xen,xen-<version>";
> 
> "xen,xen" should be last as it is less specific.

Ah OK, thanks.


> >   where <version> is the version of the Xen ABI of the platform.
> > 
> > - grant_table child with the following properties:
> >     - name:
> > 	    name = "grant_table";
> 
> What's a grant table?

A Xen specific mechanism to share pages between guests.


> > 	- reg: specifies the base physical address and size of a region in
> > 	    memory where the grant table should be mapped to, using an
> >         HYPERVISOR_memory_op hypercall. 
> > 
> > - events child with the following properties:
> >     - name:
> >         name = "events";
> > 	- interrupts: the interrupt used by Xen to inject event notifications.
> 
> Why a child node? Just an interrupts property alone should be fine. If
> you have cases with different number of interrupts, the compatible
> property can distinguish that.

I see, that's a good point. In that case maybe it doesn't make sense to
move the memory region and the interrupt into two different children
nodes after all. I should probably leave the spec as it was.
 

> > 
> > 
> > Example:
> > hypervisor {
> > 		compatible = "xen,xen", "xen,xen-4.2";
> > 		#address-cells = <1>;
> > 		#size-cells = <1>;
> > 		#interrupt-cells = <3>;
> > 		ranges = <0xb0000000 0xb0000000 0x20000>;
> > 
> > 		grant_table {
> > 			name = "grant_table";
> > 			reg = <0xb0000000 0x20000>;
> > 		};
> > 
> > 		events {
> > 			name = "events";
> > 			interrupts = <1 15 0xf08>;
> > 		};
> > 	};
> > 
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 13 11:35:09 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Sep 2012 11: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 1TC7h4-0004dm-Q7; Thu, 13 Sep 2012 11:34: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 1TC7h3-0004dd-CW
	for xen-devel@lists.xensource.com; Thu, 13 Sep 2012 11:34:49 +0000
Received: from [85.158.143.35:14239] by server-1.bemta-4.messagelabs.com id
	1B/42-12504-8D4C1505; Thu, 13 Sep 2012 11:34:48 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1347536087!16717741!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDkwMjg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25782 invoked from network); 13 Sep 2012 11:34:47 -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 Sep 2012 11:34:47 -0000
X-IronPort-AV: E=Sophos;i="4.80,416,1344211200"; d="scan'208";a="14518187"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Sep 2012 11:34: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.279.1; Thu, 13 Sep 2012 12:34:29 +0100
Date: Thu, 13 Sep 2012 12:33:47 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Rob Herring <robherring2@gmail.com>
In-Reply-To: <50514634.3080303@gmail.com>
Message-ID: <alpine.DEB.2.02.1209131213260.15568@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1208161618550.4850@kaball.uk.xensource.com>
	<1345131377-14713-6-git-send-email-stefano.stabellini@eu.citrix.com>
	<503BFCD8.5090804@gmail.com>
	<alpine.DEB.2.02.1208281823270.15568@kaball.uk.xensource.com>
	<alpine.DEB.2.02.1209121849200.15568@kaball.uk.xensource.com>
	<50514634.3080303@gmail.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>,
	"linaro-dev@lists.linaro.org" <linaro-dev@lists.linaro.org>,
	Ian Campbell <Ian.Campbell@citrix.com>, "arnd@arndb.de" <arnd@arndb.de>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Marc Zyngier <marc.zyngier@arm.com>,
	"catalin.marinas@arm.com" <catalin.marinas@arm.com>,
	"devicetree-discuss@lists.ozlabs.org"
	<devicetree-discuss@lists.ozlabs.org>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
	"Tim \(Xen.org\)" <tim@xen.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	David Vrabel <david.vrabel@citrix.com>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Xen-devel] [PATCH v3 06/25] docs: Xen ARM DT bindings
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 13 Sep 2012, Rob Herring wrote:
> On 09/12/2012 01:14 PM, Stefano Stabellini wrote:
> > On Wed, 12 Sep 2012, Stefano Stabellini wrote:
> >> On Tue, 28 Aug 2012, Rob Herring wrote:
> >>> You should look at ePAPR 1.1 which defines hypervisor related bindings.
> >>> While it is a PPC doc, we should reuse or extend what makes sense.
> >>>
> >>> See section 7.5:
> >>>
> >>> https://www.power.org/resources/downloads/Power_ePAPR_APPROVED_v1.1.pdf
> >>
> >> Thanks for the link, I wasn't aware of ePAPR.
> >>
> >> The hypervisor node defined by ePAPR is not very different from what I
> >> am proposing. Should I try to be compatible with the hypervisor
> >> specification above (as in compatible = "epapr,hypervisor-1.1")?
> >> Or should I just use it as a reference for my own specification?
> >>
> >> Personally I would rather avoid full compatibility with ePAPR.
> > 
> > In particular reading section 7.5, these are the required properties of
> > the ePAPR hypervisor node:
> > 
> > - compatible = "epapr,hypervisor-1.1"
> > compared to what I am proposing, it is laking information about what
> > hypervisor we are talking about (xen, kvm, vmware, etc) and the version
> > of the ABI (xen-4.2).
> 
> compatible properties are often changed. If we do deviate on the rest of
> the binding, then it needs to be different.
> 
> Turns out that powerpc KVM guests use "linux,kvm" and "epapr,hypervisor"
> doesn't even appear in the kernel.
> 
> We also perhaps have to consider the possibility of Xen on PowerPC. Then
> alignment is more important.

OK. In that case I think that we can just use "xen,xen-4.2".


> > - hcall-instructions
> > potentially interesting, but given that for Xen we are quite happy with
> > HVC, we are not going to add any secondary hypercall mechanisms,
> > therefore at the moment it would just result in a BUG if the specified
> > hcall instruction is != HVC. Besides if somebody else wanted to
> > implemented the Xen hypercall interface in a different way they could
> > just reimplement the hypercall wrappers, that would be easier than
> > trying to do it with this property.
> 
> It's really about the parameters passed with the HVC. The ePAPR may be a
> good model for defining this. Just grepping "hypervisor" under
> arch/powerpc, it's pretty clear hypervisor support happened first and
> the ePAPR came second. Hopefully we can avoid that for ARM.

Right. As I wrote in the other email, we could have a new property to
select the calling convention (and therefore the hypercall wrappers) to
be used with the hypervisor.


> > - guest-id
> > we usually make a point in trying not to tell the guest its own domid
> > because if the VM gets migrated to a different host it acquires a new
> > domid, therefore it should not rely on it.
> > 
> > - guest-name
> > we could pass the guest name here, but I don't see how it could be
> > of any use.
> > 
> 
> I have no issue with these being optional.

OK, good.


> > On the other hand, thinking more about what Xen needs in the device
> > tree, I think we could improve the current spec by clarifying the
> > meaning of the memory region and interrupt properties we currently
> > require. I thought about moving them to two separate children node with
> > an explicit name:
> > 
> > ---
> > 
> > * Xen hypervisor device tree bindings
> > 
> 
> I really think we need to define ARM hypervisor device tree bindings
> first, then Xen specific bindings as an addition to that. I worry that
> the KVM folks aren't paying attention and then want something different
> later on.

The problem is that there isn't much in common between Xen and KVM at
least from the DT point of view. I am not sure what would go into this
common hypervisor node.
The three key pieces of information that we are currently passing in the
DT (xen-4.2, a memory region, a PPI) are Xen specific.

If one day KVM (or another hypervisor vendor) decides to support the Xen
interface, can't they just have the Xen specific binding with a slightly
different compatible node?
For example:

compatible = "linux,kvm", "xen,xen-4.2"

wouldn't that mean "I am KVM but I can support the Xen interface"?


> > Xen ARM virtual platforms shall have the following properties and
> > children nodes:
> > 
> > - compatible property:
> > 	compatible = "xen,xen", "xen,xen-<version>";
> 
> "xen,xen" should be last as it is less specific.

Ah OK, thanks.


> >   where <version> is the version of the Xen ABI of the platform.
> > 
> > - grant_table child with the following properties:
> >     - name:
> > 	    name = "grant_table";
> 
> What's a grant table?

A Xen specific mechanism to share pages between guests.


> > 	- reg: specifies the base physical address and size of a region in
> > 	    memory where the grant table should be mapped to, using an
> >         HYPERVISOR_memory_op hypercall. 
> > 
> > - events child with the following properties:
> >     - name:
> >         name = "events";
> > 	- interrupts: the interrupt used by Xen to inject event notifications.
> 
> Why a child node? Just an interrupts property alone should be fine. If
> you have cases with different number of interrupts, the compatible
> property can distinguish that.

I see, that's a good point. In that case maybe it doesn't make sense to
move the memory region and the interrupt into two different children
nodes after all. I should probably leave the spec as it was.
 

> > 
> > 
> > Example:
> > hypervisor {
> > 		compatible = "xen,xen", "xen,xen-4.2";
> > 		#address-cells = <1>;
> > 		#size-cells = <1>;
> > 		#interrupt-cells = <3>;
> > 		ranges = <0xb0000000 0xb0000000 0x20000>;
> > 
> > 		grant_table {
> > 			name = "grant_table";
> > 			reg = <0xb0000000 0x20000>;
> > 		};
> > 
> > 		events {
> > 			name = "events";
> > 			interrupts = <1 15 0xf08>;
> > 		};
> > 	};
> > 
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 13 11:35:10 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Sep 2012 11: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 1TC7gz-0004dP-Dn; Thu, 13 Sep 2012 11:34:45 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1TC7gx-0004dK-O1
	for xen-devel@lists.xen.org; Thu, 13 Sep 2012 11:34:43 +0000
Received: from [85.158.143.35:13974] by server-2.bemta-4.messagelabs.com id
	AC/08-21239-3D4C1505; Thu, 13 Sep 2012 11:34:43 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1347536082!7104694!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-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9389 invoked from network); 13 Sep 2012 11:34:42 -0000
Received: from mail-ey0-f173.google.com (HELO mail-ey0-f173.google.com)
	(209.85.215.173)
	by server-2.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Sep 2012 11:34:42 -0000
Received: by eaac13 with SMTP id c13so1284760eaa.32
	for <xen-devel@lists.xen.org>; Thu, 13 Sep 2012 04:34: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:message-id:thread-topic
	:thread-index:mime-version:content-type:content-transfer-encoding;
	bh=HEJKoa/7ou004ysz8kMWqrcXIg8ejg30+cUQ56mpT60=;
	b=kFMOpsenOD7j0Z3gGKCKm6v9r13cc5I9NC7/3oGezbbBwJUqQOaqAL+7kksnmnvMXM
	J0RuULBEvazfvWqWvIRIciphVx0S6/CjTS1XaT9DM+JwpbxX20xQtmcAQJERc0jwxWnh
	lBZf2Y6zAv4AjAAI42HIDJkgk7BXGu3uXw5/GBRsNK2DlxiDDC3xWk+kI4haUE7TOeFv
	xLId9/p0grosHCzFM8yhiy25BljN1Lk0a6MJ/ifFhMDRzA5RMgacVGJzKKMmRZ+qQJ2V
	XoqEo4vN5GMZ5vl25gi2lVC4br68oWKfKmVdVEo8Gw409M2vjrG+YHXy5RIDm3tsyS9R
	oUQA==
Received: by 10.14.173.131 with SMTP id v3mr2181934eel.15.1347536082198;
	Thu, 13 Sep 2012 04:34:42 -0700 (PDT)
Received: from [192.168.1.69] (host86-184-74-117.range86-184.btcentralplus.com.
	[86.184.74.117])
	by mx.google.com with ESMTPS id a7sm64357649eep.14.2012.09.13.04.34.40
	(version=SSLv3 cipher=OTHER); Thu, 13 Sep 2012 04:34:40 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Thu, 13 Sep 2012 12:34:37 +0100
From: Keir Fraser <keir.xen@gmail.com>
To: <xen-devel@lists.xen.org>
Message-ID: <CC77835D.3EA28%keir.xen@gmail.com>
Thread-Topic: [ANNOUNCE] Final release candidate for Xen 4.2.0
Thread-Index: Ac2Ro8EpmJsn7Z184kS2eHd7qexviw==
Mime-version: 1.0
Subject: [Xen-devel] [ANNOUNCE] Final release candidate for Xen 4.2.0
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Folks,

A final RC has been tagged in the xen-4.2 branch:
http://xenbits.xen.org/hg/staging/xen-4.2-testing.hg (tag '4.2.0-rc5')

We plan to call the 4.2.0 release on Monday, with no further modifications.
So please test this "GA preview"!

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 13 11:35:10 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Sep 2012 11: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 1TC7gz-0004dP-Dn; Thu, 13 Sep 2012 11:34:45 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1TC7gx-0004dK-O1
	for xen-devel@lists.xen.org; Thu, 13 Sep 2012 11:34:43 +0000
Received: from [85.158.143.35:13974] by server-2.bemta-4.messagelabs.com id
	AC/08-21239-3D4C1505; Thu, 13 Sep 2012 11:34:43 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1347536082!7104694!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-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9389 invoked from network); 13 Sep 2012 11:34:42 -0000
Received: from mail-ey0-f173.google.com (HELO mail-ey0-f173.google.com)
	(209.85.215.173)
	by server-2.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Sep 2012 11:34:42 -0000
Received: by eaac13 with SMTP id c13so1284760eaa.32
	for <xen-devel@lists.xen.org>; Thu, 13 Sep 2012 04:34: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:message-id:thread-topic
	:thread-index:mime-version:content-type:content-transfer-encoding;
	bh=HEJKoa/7ou004ysz8kMWqrcXIg8ejg30+cUQ56mpT60=;
	b=kFMOpsenOD7j0Z3gGKCKm6v9r13cc5I9NC7/3oGezbbBwJUqQOaqAL+7kksnmnvMXM
	J0RuULBEvazfvWqWvIRIciphVx0S6/CjTS1XaT9DM+JwpbxX20xQtmcAQJERc0jwxWnh
	lBZf2Y6zAv4AjAAI42HIDJkgk7BXGu3uXw5/GBRsNK2DlxiDDC3xWk+kI4haUE7TOeFv
	xLId9/p0grosHCzFM8yhiy25BljN1Lk0a6MJ/ifFhMDRzA5RMgacVGJzKKMmRZ+qQJ2V
	XoqEo4vN5GMZ5vl25gi2lVC4br68oWKfKmVdVEo8Gw409M2vjrG+YHXy5RIDm3tsyS9R
	oUQA==
Received: by 10.14.173.131 with SMTP id v3mr2181934eel.15.1347536082198;
	Thu, 13 Sep 2012 04:34:42 -0700 (PDT)
Received: from [192.168.1.69] (host86-184-74-117.range86-184.btcentralplus.com.
	[86.184.74.117])
	by mx.google.com with ESMTPS id a7sm64357649eep.14.2012.09.13.04.34.40
	(version=SSLv3 cipher=OTHER); Thu, 13 Sep 2012 04:34:40 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Thu, 13 Sep 2012 12:34:37 +0100
From: Keir Fraser <keir.xen@gmail.com>
To: <xen-devel@lists.xen.org>
Message-ID: <CC77835D.3EA28%keir.xen@gmail.com>
Thread-Topic: [ANNOUNCE] Final release candidate for Xen 4.2.0
Thread-Index: Ac2Ro8EpmJsn7Z184kS2eHd7qexviw==
Mime-version: 1.0
Subject: [Xen-devel] [ANNOUNCE] Final release candidate for Xen 4.2.0
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Folks,

A final RC has been tagged in the xen-4.2 branch:
http://xenbits.xen.org/hg/staging/xen-4.2-testing.hg (tag '4.2.0-rc5')

We plan to call the 4.2.0 release on Monday, with no further modifications.
So please test this "GA preview"!

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 13 11:38:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Sep 2012 11:38: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 1TC7jz-0004pj-D2; Thu, 13 Sep 2012 11:37:51 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1TC7jy-0004pa-AC
	for Xen-devel@lists.xensource.com; Thu, 13 Sep 2012 11:37:50 +0000
Received: from [85.158.143.35:35530] by server-3.bemta-4.messagelabs.com id
	2E/5D-08232-D85C1505; Thu, 13 Sep 2012 11:37:49 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1347536268!10387870!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDkwMjg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8408 invoked from network); 13 Sep 2012 11:37:48 -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;
	13 Sep 2012 11:37:48 -0000
X-IronPort-AV: E=Sophos;i="4.80,416,1344211200"; d="scan'208";a="14518270"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Sep 2012 11:37: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.279.1;
	Thu, 13 Sep 2012 12:37:47 +0100
Message-ID: <1347536266.24226.97.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Mukesh Rathor <mukesh.rathor@oracle.com>
Date: Thu, 13 Sep 2012 12:37:46 +0100
In-Reply-To: <20120912181910.6b0b9d2b@mantra.us.oracle.com>
References: <20120815180716.0049bffe@mantra.us.oracle.com>
	<1347372623.5305.170.camel@zakaz.uk.xensource.com>
	<20120912181910.6b0b9d2b@mantra.us.oracle.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [RFC PATCH 8/8]: PVH: privcmd changes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-09-13 at 02:19 +0100, Mukesh Rathor wrote:
> On Tue, 11 Sep 2012 15:10:23 +0100
> Ian Campbell <Ian.Campbell@citrix.com> wrote:
> 
> > I think you can't rely on the implicit teardown here since you need to
> > unmap before you hand the page back to the balloon. The reason this
> > doesn't look necessary now is that you don't give the page back.
> > Also not ordering the stage 1 and stage 2 teardown correctly is
> > dangerous, depending on the eventual ordering you potentially turn an
> > erroneous access to a virtual address, which should result in a guest
> > OS level page fault (and e.g. a seg fault to the offending process)
> > into a hypervisor shoots the guest due to an unexpected stage 2 fault
> > type failure, which is somewhat undesirable ;-)
> > 
> > With that in mind I think you do in the end need to add
> > xen_unmap_domain_mfn_range which does the unmap from both stage 1 and
> > stage 2 -- that balances out the interface (making pvh_rem_xen_p2m
> > internal) too, which is nice. This function may turn out to be a nop
> > on !pvh, but that's ok (although maybe there would be no harm in doing
> > explicit unmaps, for consistency?).
>  
> Ok, I added xen_unmap_domain_mfn_range(). Take a look.

Thanks, I'll take a gander once I get ballooning working on ARM.

>  It appears that
> by the time privcmd_close() is called, the kernel has already freed 
> process resources and lookup_address() returns NULL. Now I am wondering
> if the kernel/mmu does anything to the page while shooting the pte
> entry. Well the page was orig from balloon, so the cleanup hopefully
> leaves it alone.

I suppose it depends on whether the core "takes over" the reference
which you hold. I think it doesn't, so this is just a leak, rather than
putting a ballooned page back into the general allocation pool (things
would be crashing left & right if it was doing this I reckon)

> 
> I had looked for other hooks initially when I did this, but 
> vm_operations_struct->close was the only one to pan out.
> 
> I can't really move pvh_privcmd_resv_pfns to mmu.c because the 
> xen_remap_domain_mfn_range is called one page at a time, and I need
> to allocate the array first. I'd have to change it to linked list, worth
> it? Or I'd have to move and export it.

Another alternative would be to add the page array as a parameter to the
map/unmap function, rather than relying on it propagating via
vma_private.

The other option I can see is for privcmd to use traverse_pages to hook
all the struct pages in at the right virtual address and then have
remap_mfn_range do a walk for each page. That's O(N) walks for each
mapping though, unless perhaps apply_to_page_range gives the callback
something which can be turned back into a struct pag or a pfn?

> > WRT passing data between interfaces in vma->vm_private, which is
> > pretty subtle, can we push that whole thing down into
> > xen_{remap,unmap}_domain_mfn_range too? This would make the
> > requirement on the caller be simple "never use vm_private", as
> > opposed to now where the requirement is "sometimes you might have to
> > allocate some stuff and stick it in here". The downside is that it
> > pushes code which could be generic down into per-arch stuff, although
> > with suitable generic helper functions this isn't so bad (whatever
> > happened to {alloc,free}_empty_pages_and_pagevec from the classic
> > kernels? Those did exactly what we want here, I think)
> 
> Well, it has to hang off of vma->vm_private. The alternative would be to
> have a hash table by process id or something, again not sure if worth it. 

I think using vm_private within a subsystem/layer is ok, what I think we
should avoid is having layers pass data back and forth in that field.

> 
> Take a look at my latest files attached. Now the alloc_balloon and free
> are split between privcmd and mmu.c. The alternative would be to call 
> xen_unmap_domain_mfn_range one pfn at a time and have it call 
> pvh_rem_xen_p2m(), and move free_xenballooned_pages to privcmd. But
> that would be same as just changing the name of pvh_rem_xen_p2m to
> xen_unmap_domain_mfn_range(). Also, remap and unmap won't be much
> symmetric then.
> 
> Not sure if there's a lot we could do here to be honest. LMK what you 
> think.
> 
> 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 Sep 13 11:38:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Sep 2012 11:38: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 1TC7jz-0004pj-D2; Thu, 13 Sep 2012 11:37:51 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1TC7jy-0004pa-AC
	for Xen-devel@lists.xensource.com; Thu, 13 Sep 2012 11:37:50 +0000
Received: from [85.158.143.35:35530] by server-3.bemta-4.messagelabs.com id
	2E/5D-08232-D85C1505; Thu, 13 Sep 2012 11:37:49 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1347536268!10387870!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDkwMjg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8408 invoked from network); 13 Sep 2012 11:37:48 -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;
	13 Sep 2012 11:37:48 -0000
X-IronPort-AV: E=Sophos;i="4.80,416,1344211200"; d="scan'208";a="14518270"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Sep 2012 11:37: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.279.1;
	Thu, 13 Sep 2012 12:37:47 +0100
Message-ID: <1347536266.24226.97.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Mukesh Rathor <mukesh.rathor@oracle.com>
Date: Thu, 13 Sep 2012 12:37:46 +0100
In-Reply-To: <20120912181910.6b0b9d2b@mantra.us.oracle.com>
References: <20120815180716.0049bffe@mantra.us.oracle.com>
	<1347372623.5305.170.camel@zakaz.uk.xensource.com>
	<20120912181910.6b0b9d2b@mantra.us.oracle.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [RFC PATCH 8/8]: PVH: privcmd changes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-09-13 at 02:19 +0100, Mukesh Rathor wrote:
> On Tue, 11 Sep 2012 15:10:23 +0100
> Ian Campbell <Ian.Campbell@citrix.com> wrote:
> 
> > I think you can't rely on the implicit teardown here since you need to
> > unmap before you hand the page back to the balloon. The reason this
> > doesn't look necessary now is that you don't give the page back.
> > Also not ordering the stage 1 and stage 2 teardown correctly is
> > dangerous, depending on the eventual ordering you potentially turn an
> > erroneous access to a virtual address, which should result in a guest
> > OS level page fault (and e.g. a seg fault to the offending process)
> > into a hypervisor shoots the guest due to an unexpected stage 2 fault
> > type failure, which is somewhat undesirable ;-)
> > 
> > With that in mind I think you do in the end need to add
> > xen_unmap_domain_mfn_range which does the unmap from both stage 1 and
> > stage 2 -- that balances out the interface (making pvh_rem_xen_p2m
> > internal) too, which is nice. This function may turn out to be a nop
> > on !pvh, but that's ok (although maybe there would be no harm in doing
> > explicit unmaps, for consistency?).
>  
> Ok, I added xen_unmap_domain_mfn_range(). Take a look.

Thanks, I'll take a gander once I get ballooning working on ARM.

>  It appears that
> by the time privcmd_close() is called, the kernel has already freed 
> process resources and lookup_address() returns NULL. Now I am wondering
> if the kernel/mmu does anything to the page while shooting the pte
> entry. Well the page was orig from balloon, so the cleanup hopefully
> leaves it alone.

I suppose it depends on whether the core "takes over" the reference
which you hold. I think it doesn't, so this is just a leak, rather than
putting a ballooned page back into the general allocation pool (things
would be crashing left & right if it was doing this I reckon)

> 
> I had looked for other hooks initially when I did this, but 
> vm_operations_struct->close was the only one to pan out.
> 
> I can't really move pvh_privcmd_resv_pfns to mmu.c because the 
> xen_remap_domain_mfn_range is called one page at a time, and I need
> to allocate the array first. I'd have to change it to linked list, worth
> it? Or I'd have to move and export it.

Another alternative would be to add the page array as a parameter to the
map/unmap function, rather than relying on it propagating via
vma_private.

The other option I can see is for privcmd to use traverse_pages to hook
all the struct pages in at the right virtual address and then have
remap_mfn_range do a walk for each page. That's O(N) walks for each
mapping though, unless perhaps apply_to_page_range gives the callback
something which can be turned back into a struct pag or a pfn?

> > WRT passing data between interfaces in vma->vm_private, which is
> > pretty subtle, can we push that whole thing down into
> > xen_{remap,unmap}_domain_mfn_range too? This would make the
> > requirement on the caller be simple "never use vm_private", as
> > opposed to now where the requirement is "sometimes you might have to
> > allocate some stuff and stick it in here". The downside is that it
> > pushes code which could be generic down into per-arch stuff, although
> > with suitable generic helper functions this isn't so bad (whatever
> > happened to {alloc,free}_empty_pages_and_pagevec from the classic
> > kernels? Those did exactly what we want here, I think)
> 
> Well, it has to hang off of vma->vm_private. The alternative would be to
> have a hash table by process id or something, again not sure if worth it. 

I think using vm_private within a subsystem/layer is ok, what I think we
should avoid is having layers pass data back and forth in that field.

> 
> Take a look at my latest files attached. Now the alloc_balloon and free
> are split between privcmd and mmu.c. The alternative would be to call 
> xen_unmap_domain_mfn_range one pfn at a time and have it call 
> pvh_rem_xen_p2m(), and move free_xenballooned_pages to privcmd. But
> that would be same as just changing the name of pvh_rem_xen_p2m to
> xen_unmap_domain_mfn_range(). Also, remap and unmap won't be much
> symmetric then.
> 
> Not sure if there's a lot we could do here to be honest. LMK what you 
> think.
> 
> 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 Sep 13 11:46:28 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Sep 2012 11:46:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TC7s1-000543-D9; Thu, 13 Sep 2012 11:46: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 1TC7rz-00053y-OA
	for xen-devel@lists.xensource.com; Thu, 13 Sep 2012 11:46:08 +0000
Received: from [85.158.138.51:26763] by server-2.bemta-3.messagelabs.com id
	1D/C9-04862-E77C1505; Thu, 13 Sep 2012 11:46:06 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1347536761!30450049!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDkwMjg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10291 invoked from network); 13 Sep 2012 11:46:01 -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;
	13 Sep 2012 11:46:01 -0000
X-IronPort-AV: E=Sophos;i="4.80,416,1344211200"; d="scan'208";a="14518548"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Sep 2012 11:46: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.279.1; Thu, 13 Sep 2012 12:46:01 +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 1TC7rt-0004QV-35;
	Thu, 13 Sep 2012 11:46:01 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1TC7rs-0006Tx-TM;
	Thu, 13 Sep 2012 12:46:00 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-13735-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 13 Sep 2012 12:46:00 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.2-testing test] 13735: trouble:
	preparing/queued/running
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 13735 xen-4.2-testing running [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13735/

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-sedf-pin    <none executed>              queued
 test-amd64-i386-xl-credit2      <none executed>              queued
 test-amd64-i386-pv              <none executed>              queued
 test-amd64-i386-xl              <none executed>              queued
 test-amd64-amd64-xl-pcipt-intel    <none executed>              queued
 test-amd64-amd64-xl-sedf        <none executed>              queued
 test-amd64-i386-rhel6hvm-intel    <none executed>              queued
 test-amd64-i386-qemuu-rhel6hvm-amd    <none executed>              queued
 test-amd64-i386-xl-multivcpu    <none executed>              queued
 test-amd64-amd64-xl             <none executed>              queued
 test-amd64-amd64-pv             <none executed>              queued
 test-amd64-i386-rhel6hvm-amd    <none executed>              queued
 test-amd64-i386-qemuu-rhel6hvm-intel    <none executed>              queued
 test-i386-i386-xl               <none executed>              queued
 test-i386-i386-pair             <none executed>              queued
 test-amd64-i386-pair            <none executed>              queued
 test-i386-i386-xl-qemuu-winxpsp3    <none executed>              queued
 test-amd64-amd64-xl-qemuu-win7-amd64    <none executed>              queued
 test-amd64-amd64-xl-win7-amd64    <none executed>              queued
 test-i386-i386-xl-win           <none executed>              queued
 test-amd64-amd64-pair           <none executed>              queued
 test-amd64-i386-xend-winxpsp3    <none executed>              queued
 test-i386-i386-win              <none executed>              queued
 test-amd64-i386-xl-win7-amd64    <none executed>              queued
 test-i386-i386-xl-winxpsp3      <none executed>              queued
 test-amd64-i386-win-vcpus1      <none executed>              queued
 test-i386-i386-pv               <none executed>              queued
 test-amd64-i386-win             <none executed>              queued
 test-amd64-i386-xl-winxpsp3-vcpus1    <none executed>              queued
 build-amd64                   4 xen-build                running [st=running!]
 build-i386                    1 hosts-allocate           running [st=running!]
 test-amd64-i386-xl-win-vcpus1    <none executed>              queued
 build-i386-pvops              1 hosts-allocate           running [st=running!]
 build-amd64-pvops             4 kernel-build             running [st=running!]
 build-i386-oldkern            1 hosts-allocate           running [st=running!]
 test-amd64-amd64-xl-qemuu-winxpsp3    <none executed>              queued
 build-amd64-oldkern           4 xen-build                running [st=running!]
 test-amd64-amd64-xl-winxpsp3    <none executed>              queued
 test-amd64-amd64-win            <none executed>              queued
 test-amd64-amd64-xl-win         <none executed>              queued

version targeted for testing:
 xen                  9cec8d14a1ea
baseline version:
 xen                  7f993b289dc4

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@citrix.com>
  Ian Campbell <ian.campbell@citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Keir Fraser <keir@xen.org>
  Olaf Hering <olaf@aepfle.de>
  Pasi K?rkk?inen <pasik@iki.fi>
------------------------------------------------------------

jobs:
 build-amd64                                                  running 
 build-i386                                                   preparing
 build-amd64-oldkern                                          running 
 build-i386-oldkern                                           preparing
 build-amd64-pvops                                            running 
 build-i386-pvops                                             preparing
 test-amd64-amd64-xl                                          queued  
 test-amd64-i386-xl                                           queued  
 test-i386-i386-xl                                            queued  
 test-amd64-i386-rhel6hvm-amd                                 queued  
 test-amd64-i386-qemuu-rhel6hvm-amd                           queued  
 test-amd64-amd64-xl-qemuu-win7-amd64                         queued  
 test-amd64-amd64-xl-win7-amd64                               queued  
 test-amd64-i386-xl-win7-amd64                                queued  
 test-amd64-i386-xl-credit2                                   queued  
 test-amd64-amd64-xl-pcipt-intel                              queued  
 test-amd64-i386-rhel6hvm-intel                               queued  
 test-amd64-i386-qemuu-rhel6hvm-intel                         queued  
 test-amd64-i386-xl-multivcpu                                 queued  
 test-amd64-amd64-pair                                        queued  
 test-amd64-i386-pair                                         queued  
 test-i386-i386-pair                                          queued  
 test-amd64-amd64-xl-sedf-pin                                 queued  
 test-amd64-amd64-pv                                          queued  
 test-amd64-i386-pv                                           queued  
 test-i386-i386-pv                                            queued  
 test-amd64-amd64-xl-sedf                                     queued  
 test-amd64-i386-win-vcpus1                                   queued  
 test-amd64-i386-xl-win-vcpus1                                queued  
 test-amd64-i386-xl-winxpsp3-vcpus1                           queued  
 test-amd64-amd64-win                                         queued  
 test-amd64-i386-win                                          queued  
 test-i386-i386-win                                           queued  
 test-amd64-amd64-xl-win                                      queued  
 test-i386-i386-xl-win                                        queued  
 test-amd64-amd64-xl-qemuu-winxpsp3                           queued  
 test-i386-i386-xl-qemuu-winxpsp3                             queued  
 test-amd64-i386-xend-winxpsp3                                queued  
 test-amd64-amd64-xl-winxpsp3                                 queued  
 test-i386-i386-xl-winxpsp3                                   queued  


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.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:   25837:9cec8d14a1ea
tag:         tip
user:        Andrew Cooper <andrew.cooper3@citrix.com>
date:        Wed Sep 12 19:33:18 2012 +0100
    
    x86/passthrough: Fix corruption caused by race conditions between
    device allocation and deallocation to a domain.
    
    A toolstack, when dealing with a domain using PCIPassthrough, could
    reasonably be expected to issue DOMCTL_deassign_device hypercalls to
    remove all passed through devices before issuing a
    DOMCTL_destroydomain hypercall to kill the domain.  In the case where
    a toolstack is perhaps less sensible in this regard, the hypervisor
    should not fall over.
    
    In domain_kill(), pci_release_devices() searches the alldevs_list list
    looking for PCI devices still assigned to the domain.  If the
    toolstack has correctly deassigned all devices before killing the
    domain, this loop does nothing.
    
    However, if there are still devices attached to the domain, the loop
    will call pci_cleanup_msi() without unbinding the pirq from the
    domain.  This eventually calls destroy_irq() which xfree()'s the
    action.
    
    However, as the irq_desc->action pointer is abused in an unsafe
    matter, without unbinding first (which at least correctly cleans up),
    the action is actually an irq_guest_action_t* rather than an
    irqaction*, meaning that the cpu_eoi_map is leaked, and eoi_timer is
    free()'d while still being on a pcpu's inactive_timer list.  As a
    result, when this free()'d memory gets reused, the inactive_timer list
    becomes corrupt, and list_*** operations will corrupt hypervisor
    memory.
    
    If the above were not bad enough, the loop in pci_release_devices()
    still leaves references to the irq it destroyed in
    domain->arch.pirq_irq and irq_pirq, meaning that a later loop,
    free_domain_pirqs(), which happens as a result of
    complete_domain_destroy() will unbind and destroy all irqs which were
    still bound to the domain, resulting in a double destroy of any irq
    which was still bound to the domain at the point at which the
    DOMCTL_destroydomain hypercall happened.
    
    Because of the allocation of irqs from find_unassigned_irq(), the
    lowest free irq number is going to be handed back from create_irq().
    
    There is a further race condition between the original (incorrect)
    call to destroy_irq() from pci_release_devices(), and the later call
    to free_domain_pirqs() (which happens in a softirq context at some
    point after the domain has officially died) during which the same irq
    number (which is still referenced in a stale way in
    domain->arch.pirq_irq and irq_pirq) has been allocated to a new domain
    via a PHYSDEVOP_map_pirq hypercall (Say perhaps in the case of
    rebooting a domain).
    
    In this case, the cleanup for the dead domain will free the recently
    bound irq under the feet of the new domain.  Furthermore, after the
    irq has been incorrectly destroyed, the same domain with another
    PHYSDEVOP_map_pirq hypercall can be allocated the same irq number as
    before, leading to an error along the lines of:
    
    ../physdev.c:188: dom54: -1:-1 already mapped to 74
    
    In this case, the pirq_irq and irq_pirq mappings get updated to the
    new PCI device from the latter PHYSDEVOP_map_pirq hypercall, and the
    IOMMU interrupt remapping registers get updated, leading to IOMMU
    Primary Pending Fault due to source-id verification failure for
    incoming interrupts from the passed through device.
    
    
    The easy fix is to simply deassign the device in pci_release_devices()
    and leave all the real cleanup to the free_domain_pirqs() which
    correctly unbinds and destroys the irq without leaving stale
    references around.
    
    Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    xen-unstable changeset:   25883:4fdaebea82d7
    xen-unstable date:        Wed Sep 12 19:31:16 2012 +0100
    
    
changeset:   25836:7550c9b55af2
user:        Pasi K?rkk?inen <pasik@iki.fi>
date:        Wed Sep 12 19:03:50 2012 +0100
    
    xl.cfg: gfx_passthru documentation improvements
    
    gfx_passthru: Document gfx_passthru makes the GPU become primary in
    the guest
    and other generic info about gfx_passthru.
    
    Signed-off-by: Pasi K?rkk?inen <pasik@iki.fi>
    Acked-by: Ian Campbell <ian.campbell@citrix.com>
    Committed-by: Ian Campbell <ian.campbell@citrix.com>
    xen-unstable changeset:   25839:2dfea3dff550
    xen-unstable date:        Mon Sep 10 11:13:54 2012 +0100
    
    
changeset:   25835:7f993b289dc4
user:        Olaf Hering <olaf@aepfle.de>
date:        Wed Sep 12 14:48:04 2012 +0100
    
    unmodified_drivers: handle IRQF_SAMPLE_RANDOM
    
    The flag IRQF_SAMPLE_RANDOM was removed in 3.6-rc1. Add it only if it
    is
    defined. An additional call to add_interrupt_randomness is appearently
    not needed because its now called unconditionally in
    handle_irq_event_percpu().
    
    Signed-off-by: Olaf Hering <olaf@aepfle.de>
    Committed-by: Jan Beulich <jbeulich@suse.com>
    xen-unstable changeset:   25837:87cb4b6f53d3
    xen-unstable date:        Mon Sep 10 10:54:13 2012 +0200
    
    
(qemu changes not included)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 13 11:46:28 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Sep 2012 11:46:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TC7s1-000543-D9; Thu, 13 Sep 2012 11:46: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 1TC7rz-00053y-OA
	for xen-devel@lists.xensource.com; Thu, 13 Sep 2012 11:46:08 +0000
Received: from [85.158.138.51:26763] by server-2.bemta-3.messagelabs.com id
	1D/C9-04862-E77C1505; Thu, 13 Sep 2012 11:46:06 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1347536761!30450049!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDkwMjg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10291 invoked from network); 13 Sep 2012 11:46:01 -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;
	13 Sep 2012 11:46:01 -0000
X-IronPort-AV: E=Sophos;i="4.80,416,1344211200"; d="scan'208";a="14518548"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Sep 2012 11:46: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.279.1; Thu, 13 Sep 2012 12:46:01 +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 1TC7rt-0004QV-35;
	Thu, 13 Sep 2012 11:46:01 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1TC7rs-0006Tx-TM;
	Thu, 13 Sep 2012 12:46:00 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-13735-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 13 Sep 2012 12:46:00 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.2-testing test] 13735: trouble:
	preparing/queued/running
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 13735 xen-4.2-testing running [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13735/

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-sedf-pin    <none executed>              queued
 test-amd64-i386-xl-credit2      <none executed>              queued
 test-amd64-i386-pv              <none executed>              queued
 test-amd64-i386-xl              <none executed>              queued
 test-amd64-amd64-xl-pcipt-intel    <none executed>              queued
 test-amd64-amd64-xl-sedf        <none executed>              queued
 test-amd64-i386-rhel6hvm-intel    <none executed>              queued
 test-amd64-i386-qemuu-rhel6hvm-amd    <none executed>              queued
 test-amd64-i386-xl-multivcpu    <none executed>              queued
 test-amd64-amd64-xl             <none executed>              queued
 test-amd64-amd64-pv             <none executed>              queued
 test-amd64-i386-rhel6hvm-amd    <none executed>              queued
 test-amd64-i386-qemuu-rhel6hvm-intel    <none executed>              queued
 test-i386-i386-xl               <none executed>              queued
 test-i386-i386-pair             <none executed>              queued
 test-amd64-i386-pair            <none executed>              queued
 test-i386-i386-xl-qemuu-winxpsp3    <none executed>              queued
 test-amd64-amd64-xl-qemuu-win7-amd64    <none executed>              queued
 test-amd64-amd64-xl-win7-amd64    <none executed>              queued
 test-i386-i386-xl-win           <none executed>              queued
 test-amd64-amd64-pair           <none executed>              queued
 test-amd64-i386-xend-winxpsp3    <none executed>              queued
 test-i386-i386-win              <none executed>              queued
 test-amd64-i386-xl-win7-amd64    <none executed>              queued
 test-i386-i386-xl-winxpsp3      <none executed>              queued
 test-amd64-i386-win-vcpus1      <none executed>              queued
 test-i386-i386-pv               <none executed>              queued
 test-amd64-i386-win             <none executed>              queued
 test-amd64-i386-xl-winxpsp3-vcpus1    <none executed>              queued
 build-amd64                   4 xen-build                running [st=running!]
 build-i386                    1 hosts-allocate           running [st=running!]
 test-amd64-i386-xl-win-vcpus1    <none executed>              queued
 build-i386-pvops              1 hosts-allocate           running [st=running!]
 build-amd64-pvops             4 kernel-build             running [st=running!]
 build-i386-oldkern            1 hosts-allocate           running [st=running!]
 test-amd64-amd64-xl-qemuu-winxpsp3    <none executed>              queued
 build-amd64-oldkern           4 xen-build                running [st=running!]
 test-amd64-amd64-xl-winxpsp3    <none executed>              queued
 test-amd64-amd64-win            <none executed>              queued
 test-amd64-amd64-xl-win         <none executed>              queued

version targeted for testing:
 xen                  9cec8d14a1ea
baseline version:
 xen                  7f993b289dc4

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@citrix.com>
  Ian Campbell <ian.campbell@citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Keir Fraser <keir@xen.org>
  Olaf Hering <olaf@aepfle.de>
  Pasi K?rkk?inen <pasik@iki.fi>
------------------------------------------------------------

jobs:
 build-amd64                                                  running 
 build-i386                                                   preparing
 build-amd64-oldkern                                          running 
 build-i386-oldkern                                           preparing
 build-amd64-pvops                                            running 
 build-i386-pvops                                             preparing
 test-amd64-amd64-xl                                          queued  
 test-amd64-i386-xl                                           queued  
 test-i386-i386-xl                                            queued  
 test-amd64-i386-rhel6hvm-amd                                 queued  
 test-amd64-i386-qemuu-rhel6hvm-amd                           queued  
 test-amd64-amd64-xl-qemuu-win7-amd64                         queued  
 test-amd64-amd64-xl-win7-amd64                               queued  
 test-amd64-i386-xl-win7-amd64                                queued  
 test-amd64-i386-xl-credit2                                   queued  
 test-amd64-amd64-xl-pcipt-intel                              queued  
 test-amd64-i386-rhel6hvm-intel                               queued  
 test-amd64-i386-qemuu-rhel6hvm-intel                         queued  
 test-amd64-i386-xl-multivcpu                                 queued  
 test-amd64-amd64-pair                                        queued  
 test-amd64-i386-pair                                         queued  
 test-i386-i386-pair                                          queued  
 test-amd64-amd64-xl-sedf-pin                                 queued  
 test-amd64-amd64-pv                                          queued  
 test-amd64-i386-pv                                           queued  
 test-i386-i386-pv                                            queued  
 test-amd64-amd64-xl-sedf                                     queued  
 test-amd64-i386-win-vcpus1                                   queued  
 test-amd64-i386-xl-win-vcpus1                                queued  
 test-amd64-i386-xl-winxpsp3-vcpus1                           queued  
 test-amd64-amd64-win                                         queued  
 test-amd64-i386-win                                          queued  
 test-i386-i386-win                                           queued  
 test-amd64-amd64-xl-win                                      queued  
 test-i386-i386-xl-win                                        queued  
 test-amd64-amd64-xl-qemuu-winxpsp3                           queued  
 test-i386-i386-xl-qemuu-winxpsp3                             queued  
 test-amd64-i386-xend-winxpsp3                                queued  
 test-amd64-amd64-xl-winxpsp3                                 queued  
 test-i386-i386-xl-winxpsp3                                   queued  


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.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:   25837:9cec8d14a1ea
tag:         tip
user:        Andrew Cooper <andrew.cooper3@citrix.com>
date:        Wed Sep 12 19:33:18 2012 +0100
    
    x86/passthrough: Fix corruption caused by race conditions between
    device allocation and deallocation to a domain.
    
    A toolstack, when dealing with a domain using PCIPassthrough, could
    reasonably be expected to issue DOMCTL_deassign_device hypercalls to
    remove all passed through devices before issuing a
    DOMCTL_destroydomain hypercall to kill the domain.  In the case where
    a toolstack is perhaps less sensible in this regard, the hypervisor
    should not fall over.
    
    In domain_kill(), pci_release_devices() searches the alldevs_list list
    looking for PCI devices still assigned to the domain.  If the
    toolstack has correctly deassigned all devices before killing the
    domain, this loop does nothing.
    
    However, if there are still devices attached to the domain, the loop
    will call pci_cleanup_msi() without unbinding the pirq from the
    domain.  This eventually calls destroy_irq() which xfree()'s the
    action.
    
    However, as the irq_desc->action pointer is abused in an unsafe
    matter, without unbinding first (which at least correctly cleans up),
    the action is actually an irq_guest_action_t* rather than an
    irqaction*, meaning that the cpu_eoi_map is leaked, and eoi_timer is
    free()'d while still being on a pcpu's inactive_timer list.  As a
    result, when this free()'d memory gets reused, the inactive_timer list
    becomes corrupt, and list_*** operations will corrupt hypervisor
    memory.
    
    If the above were not bad enough, the loop in pci_release_devices()
    still leaves references to the irq it destroyed in
    domain->arch.pirq_irq and irq_pirq, meaning that a later loop,
    free_domain_pirqs(), which happens as a result of
    complete_domain_destroy() will unbind and destroy all irqs which were
    still bound to the domain, resulting in a double destroy of any irq
    which was still bound to the domain at the point at which the
    DOMCTL_destroydomain hypercall happened.
    
    Because of the allocation of irqs from find_unassigned_irq(), the
    lowest free irq number is going to be handed back from create_irq().
    
    There is a further race condition between the original (incorrect)
    call to destroy_irq() from pci_release_devices(), and the later call
    to free_domain_pirqs() (which happens in a softirq context at some
    point after the domain has officially died) during which the same irq
    number (which is still referenced in a stale way in
    domain->arch.pirq_irq and irq_pirq) has been allocated to a new domain
    via a PHYSDEVOP_map_pirq hypercall (Say perhaps in the case of
    rebooting a domain).
    
    In this case, the cleanup for the dead domain will free the recently
    bound irq under the feet of the new domain.  Furthermore, after the
    irq has been incorrectly destroyed, the same domain with another
    PHYSDEVOP_map_pirq hypercall can be allocated the same irq number as
    before, leading to an error along the lines of:
    
    ../physdev.c:188: dom54: -1:-1 already mapped to 74
    
    In this case, the pirq_irq and irq_pirq mappings get updated to the
    new PCI device from the latter PHYSDEVOP_map_pirq hypercall, and the
    IOMMU interrupt remapping registers get updated, leading to IOMMU
    Primary Pending Fault due to source-id verification failure for
    incoming interrupts from the passed through device.
    
    
    The easy fix is to simply deassign the device in pci_release_devices()
    and leave all the real cleanup to the free_domain_pirqs() which
    correctly unbinds and destroys the irq without leaving stale
    references around.
    
    Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    xen-unstable changeset:   25883:4fdaebea82d7
    xen-unstable date:        Wed Sep 12 19:31:16 2012 +0100
    
    
changeset:   25836:7550c9b55af2
user:        Pasi K?rkk?inen <pasik@iki.fi>
date:        Wed Sep 12 19:03:50 2012 +0100
    
    xl.cfg: gfx_passthru documentation improvements
    
    gfx_passthru: Document gfx_passthru makes the GPU become primary in
    the guest
    and other generic info about gfx_passthru.
    
    Signed-off-by: Pasi K?rkk?inen <pasik@iki.fi>
    Acked-by: Ian Campbell <ian.campbell@citrix.com>
    Committed-by: Ian Campbell <ian.campbell@citrix.com>
    xen-unstable changeset:   25839:2dfea3dff550
    xen-unstable date:        Mon Sep 10 11:13:54 2012 +0100
    
    
changeset:   25835:7f993b289dc4
user:        Olaf Hering <olaf@aepfle.de>
date:        Wed Sep 12 14:48:04 2012 +0100
    
    unmodified_drivers: handle IRQF_SAMPLE_RANDOM
    
    The flag IRQF_SAMPLE_RANDOM was removed in 3.6-rc1. Add it only if it
    is
    defined. An additional call to add_interrupt_randomness is appearently
    not needed because its now called unconditionally in
    handle_irq_event_percpu().
    
    Signed-off-by: Olaf Hering <olaf@aepfle.de>
    Committed-by: Jan Beulich <jbeulich@suse.com>
    xen-unstable changeset:   25837:87cb4b6f53d3
    xen-unstable date:        Mon Sep 10 10:54:13 2012 +0200
    
    
(qemu changes not included)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 13 11:52:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Sep 2012 11: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 1TC7xf-0005F6-DL; Thu, 13 Sep 2012 11:51:59 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1TC7xe-0005F0-0w
	for xen-devel@lists.xen.org; Thu, 13 Sep 2012 11:51:58 +0000
Received: from [85.158.139.83:31292] by server-4.bemta-5.messagelabs.com id
	FA/CD-23042-DD8C1505; Thu, 13 Sep 2012 11:51:57 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1347537116!29641876!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQxMjE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18478 invoked from network); 13 Sep 2012 11:51:56 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-9.tower-182.messagelabs.com with SMTP;
	13 Sep 2012 11:51:56 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 13 Sep 2012 12:51:56 +0100
Message-Id: <5051E531020000780009B083@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 13 Sep 2012 12:52:49 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Tim Deegan" <tim@xen.org>
References: <CAFw--Dd0k7L+T_UJc0yHAkUGrY_-GDHaQjK3OM-1UdOp=J-wAQ@mail.gmail.com>
	<20120907085036.GA71093@ocelot.phlegethon.org>
	<5049E2C70200007800099B21@nat28.tlf.novell.com>
	<20120913101120.GA12881@ocelot.phlegethon.org>
In-Reply-To: <20120913101120.GA12881@ocelot.phlegethon.org>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Paolo Bonzini <pbonzini@redhat.com>, Jeffrey Karrels <karrelsj@gmail.com>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Clang/LLVM version requirements
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.09.12 at 12:11, Tim Deegan <tim@xen.org> wrote:
> At 11:04 +0100 on 07 Sep (1347015863), Jan Beulich wrote:
>> >>> On 07.09.12 at 10:50, Tim Deegan <tim@xen.org> wrote:
>> > In any case we probably ought to check for stray .data symbols too.
>> 
>> Not really, no. Those would still be present in reloc.bin, and
>> hence make it into reloc.S.
> 
> But they would break the test, because the magic alignment happens in
> .text, right?  Anyway, compile-time failure seems more useful.  How
> about this, based on the similar checks for init-only files?

Yes, it's happening in .text currently. The problem, iirc, really was
that _end and __bss_start didn't always match (depending on
compiler version), apparently because at the linking stage _end
got aligned more strictly than __bss_start.

So the patch is fine by me if it covers that misalignment case.
But it seems a little heavy handed - I'd think that instead of the
sub-section, we could just create an arbitrary other section, or
even allow uninitialized variable (it's unclear to me why Paolo
wrote the comment - in c/s 25479:61dfb3da56b - regarding BSS
the way it is now) - after all we only need to make sure that
- the space gets properly allocated in trampoline.S, i.e. also in
  reloc.bin
- all accesses are PC-relative
Neither has anything to do with use of uninitialized variables.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 13 11:52:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Sep 2012 11: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 1TC7xf-0005F6-DL; Thu, 13 Sep 2012 11:51:59 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1TC7xe-0005F0-0w
	for xen-devel@lists.xen.org; Thu, 13 Sep 2012 11:51:58 +0000
Received: from [85.158.139.83:31292] by server-4.bemta-5.messagelabs.com id
	FA/CD-23042-DD8C1505; Thu, 13 Sep 2012 11:51:57 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1347537116!29641876!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQxMjE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18478 invoked from network); 13 Sep 2012 11:51:56 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-9.tower-182.messagelabs.com with SMTP;
	13 Sep 2012 11:51:56 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 13 Sep 2012 12:51:56 +0100
Message-Id: <5051E531020000780009B083@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 13 Sep 2012 12:52:49 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Tim Deegan" <tim@xen.org>
References: <CAFw--Dd0k7L+T_UJc0yHAkUGrY_-GDHaQjK3OM-1UdOp=J-wAQ@mail.gmail.com>
	<20120907085036.GA71093@ocelot.phlegethon.org>
	<5049E2C70200007800099B21@nat28.tlf.novell.com>
	<20120913101120.GA12881@ocelot.phlegethon.org>
In-Reply-To: <20120913101120.GA12881@ocelot.phlegethon.org>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Paolo Bonzini <pbonzini@redhat.com>, Jeffrey Karrels <karrelsj@gmail.com>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Clang/LLVM version requirements
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.09.12 at 12:11, Tim Deegan <tim@xen.org> wrote:
> At 11:04 +0100 on 07 Sep (1347015863), Jan Beulich wrote:
>> >>> On 07.09.12 at 10:50, Tim Deegan <tim@xen.org> wrote:
>> > In any case we probably ought to check for stray .data symbols too.
>> 
>> Not really, no. Those would still be present in reloc.bin, and
>> hence make it into reloc.S.
> 
> But they would break the test, because the magic alignment happens in
> .text, right?  Anyway, compile-time failure seems more useful.  How
> about this, based on the similar checks for init-only files?

Yes, it's happening in .text currently. The problem, iirc, really was
that _end and __bss_start didn't always match (depending on
compiler version), apparently because at the linking stage _end
got aligned more strictly than __bss_start.

So the patch is fine by me if it covers that misalignment case.
But it seems a little heavy handed - I'd think that instead of the
sub-section, we could just create an arbitrary other section, or
even allow uninitialized variable (it's unclear to me why Paolo
wrote the comment - in c/s 25479:61dfb3da56b - regarding BSS
the way it is now) - after all we only need to make sure that
- the space gets properly allocated in trampoline.S, i.e. also in
  reloc.bin
- all accesses are PC-relative
Neither has anything to do with use of uninitialized variables.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 13 12:00:55 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Sep 2012 12: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 1TC860-0005TQ-Pn; Thu, 13 Sep 2012 12:00: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 1TC85z-0005TF-QN
	for xen-devel@lists.xen.org; Thu, 13 Sep 2012 12:00:36 +0000
Received: from [85.158.138.51:38486] by server-11.bemta-3.messagelabs.com id
	8C/F7-30250-2EAC1505; Thu, 13 Sep 2012 12:00:34 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1347537631!29866086!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQxMjE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5053 invoked from network); 13 Sep 2012 12:00:31 -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;
	13 Sep 2012 12:00:31 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 13 Sep 2012 13:00:31 +0100
Message-Id: <5051E734020000780009B090@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 13 Sep 2012 13:01:24 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Jiongxi Li" <jiongxi.li@intel.com>
References: <D9137FCD9CFF644B965863BCFBEDABB8779942@SHSMSX101.ccr.corp.intel.com>
	<5040CAB30200007800097D73@nat28.tlf.novell.com>
	<D9137FCD9CFF644B965863BCFBEDABB877CBBD@SHSMSX101.ccr.corp.intel.com>
	<504898870200007800099427@nat28.tlf.novell.com>
	<D9137FCD9CFF644B965863BCFBEDABB878044D@SHSMSX101.ccr.corp.intel.com>
In-Reply-To: <D9137FCD9CFF644B965863BCFBEDABB878044D@SHSMSX101.ccr.corp.intel.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [ PATCH 2/2] xen: enable Virtual-interrupt 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

>>> On 13.09.12 at 12:13, "Li, Jiongxi" <jiongxi.li@intel.com> wrote:
>> Considering that the original could already have been written with 
> if/else-if, I
>> was suggesting to expand this to your addition:
>> 
>> if ( cpu_has_vmx_virtual_intr_delivery ) { } else if (a)
>>   {}
>> else if (b)
>>   {}
>> 
>> which will avoid any (indentation only) changes past the first of the two 
> else-if-s.
>> Plus it would make the logic of the code more clear, at once likely making
>> apparent that there'll now be quite a few "goto out"-s that ought to be check
>> for being replaceable by fewer instances of them placed slightly 
> differently.
> It is a good suggestion. But the original code is two parallel if() case, 
> not the if/else-if case, and can't be changed to if/else-if case, so I just 
> keep the original code here. :)

That's simply not true. The code before your patch is

        if ( intblk == hvm_intblk_tpr )
        {
            ...
            goto out;
        }

        if ( (intblk != hvm_intblk_none) || ... )
        {
            ...
            goto out;
        }

which can easily be re-written into and if()/else if() (due to the
goto at the first if() body's end). All you want in your patch is
then to prepend another if() and convert the initial if() into an
else if() too.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 13 12:00:55 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Sep 2012 12: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 1TC860-0005TQ-Pn; Thu, 13 Sep 2012 12:00: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 1TC85z-0005TF-QN
	for xen-devel@lists.xen.org; Thu, 13 Sep 2012 12:00:36 +0000
Received: from [85.158.138.51:38486] by server-11.bemta-3.messagelabs.com id
	8C/F7-30250-2EAC1505; Thu, 13 Sep 2012 12:00:34 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1347537631!29866086!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQxMjE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5053 invoked from network); 13 Sep 2012 12:00:31 -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;
	13 Sep 2012 12:00:31 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 13 Sep 2012 13:00:31 +0100
Message-Id: <5051E734020000780009B090@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 13 Sep 2012 13:01:24 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Jiongxi Li" <jiongxi.li@intel.com>
References: <D9137FCD9CFF644B965863BCFBEDABB8779942@SHSMSX101.ccr.corp.intel.com>
	<5040CAB30200007800097D73@nat28.tlf.novell.com>
	<D9137FCD9CFF644B965863BCFBEDABB877CBBD@SHSMSX101.ccr.corp.intel.com>
	<504898870200007800099427@nat28.tlf.novell.com>
	<D9137FCD9CFF644B965863BCFBEDABB878044D@SHSMSX101.ccr.corp.intel.com>
In-Reply-To: <D9137FCD9CFF644B965863BCFBEDABB878044D@SHSMSX101.ccr.corp.intel.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [ PATCH 2/2] xen: enable Virtual-interrupt 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

>>> On 13.09.12 at 12:13, "Li, Jiongxi" <jiongxi.li@intel.com> wrote:
>> Considering that the original could already have been written with 
> if/else-if, I
>> was suggesting to expand this to your addition:
>> 
>> if ( cpu_has_vmx_virtual_intr_delivery ) { } else if (a)
>>   {}
>> else if (b)
>>   {}
>> 
>> which will avoid any (indentation only) changes past the first of the two 
> else-if-s.
>> Plus it would make the logic of the code more clear, at once likely making
>> apparent that there'll now be quite a few "goto out"-s that ought to be check
>> for being replaceable by fewer instances of them placed slightly 
> differently.
> It is a good suggestion. But the original code is two parallel if() case, 
> not the if/else-if case, and can't be changed to if/else-if case, so I just 
> keep the original code here. :)

That's simply not true. The code before your patch is

        if ( intblk == hvm_intblk_tpr )
        {
            ...
            goto out;
        }

        if ( (intblk != hvm_intblk_none) || ... )
        {
            ...
            goto out;
        }

which can easily be re-written into and if()/else if() (due to the
goto at the first if() body's end). All you want in your patch is
then to prepend another if() and convert the initial if() into an
else if() too.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 13 12:02:31 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Sep 2012 12:02: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 1TC87I-0005bX-8g; Thu, 13 Sep 2012 12:01:56 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jmarcet@gmail.com>) id 1TC87G-0005bN-I7
	for xen-devel@lists.xen.org; Thu, 13 Sep 2012 12:01:54 +0000
Received: from [85.158.143.99:12646] by server-3.bemta-4.messagelabs.com id
	95/16-08232-13BC1505; Thu, 13 Sep 2012 12:01:53 +0000
X-Env-Sender: jmarcet@gmail.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1347537711!30160858!1
X-Originating-IP: [209.85.214.173]
X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14645 invoked from network); 13 Sep 2012 12:01:52 -0000
Received: from mail-ob0-f173.google.com (HELO mail-ob0-f173.google.com)
	(209.85.214.173)
	by server-15.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Sep 2012 12:01:52 -0000
Received: by obbta14 with SMTP id ta14so5409456obb.32
	for <xen-devel@lists.xen.org>; Thu, 13 Sep 2012 05:01:51 -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:cc:content-type;
	bh=kv76ye215iZqKeG8eCBh5E07SCmobOCHuUwR5Ate5E4=;
	b=rU7Bxignp/N9TO84zL1f23KL8OXSXwbVyGGtuNGkIkebojTrEnoUZstpHBtZ6tOjW8
	6+1Q5nSHbK5+bclZ6HZYoj63jx/F8gzLZf0OfLm/9NVryCcnymNHRLxsyw7Leu/BnAau
	msPI8hOFCJSfwIV34vNmQvbH5Dgm4Pyd+UlR6H0AlkpM3GENaOStDU0I7N5nDQse5YX8
	FkUd2VIh2opHXTWGZE7xMuiO4n6wFmPjnQ88/X1XbmHCwtH1n0K9J8nNa7l8oHwoY0tT
	/JWbosArfeB+nJqCExHJZEp25n0ewVsEuCFD6ltrTjnh5Ve1aqHVXUGcK14eq9C9dnqf
	fybQ==
Received: by 10.182.174.68 with SMTP id bq4mr1796912obc.53.1347537711084; Thu,
	13 Sep 2012 05:01:51 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.60.138.225 with HTTP; Thu, 13 Sep 2012 05:01:30 -0700 (PDT)
From: Javier Marcet <jmarcet@gmail.com>
Date: Thu, 13 Sep 2012 14:01:30 +0200
Message-ID: <CAAnFQG9TZj=SxYK_jxqN=M6L40vL=AZu9EM2tbEffPhkL1s8FA@mail.gmail.com>
To: Konrad Rzeszutek Wilk <konrad@kernel.org>
Cc: Xen Devel Mailing list <xen-devel@lists.xen.org>
Subject: [Xen-devel]  Xen 4.2.0-rc4 issues with DVB tuner
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============6499824421439869495=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============6499824421439869495==
Content-Type: multipart/alternative; boundary=e89a8f50311a97362c04c99412b4

--e89a8f50311a97362c04c99412b4
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Thu, Aug 30, 2012 at 6:33 PM, Konrad Rzeszutek Wilk <konrad@kernel.org>w=
rote:

Hi,


> > I've just upgraded a server of mine from a Core i3 2100T to an i7 3770,
> in order
> > to do full virtualization with VTd.
> >
> > I'm using kernel 3.5.2 and Xen from git://xenbits.xen.org/xen.git @
> commit
> > 37d7ccdc2f50d659f1eb8ec11ee4bf8a8376926d (Fri Aug 24).
> >
> > Since there are various issues I'm gonna comment on them all. I'd
> appreciate
> > if you help me deciding which bug reports to file, and where to file
> them.
>
> Its easier if there are seperate emails and then we can track them
> step-by-step.
> >
> > Upon booting under the xen virtualizer everything works fine but I cann=
ot
> > suspend the machine and I have reception problems on the DVB-T tuners
>
> Right. The suspend (well, the resume part) is not yet working.
> > installed on the system.
>
> That sounds familiar - but without more details its a bit unclear.
>

I replaced the problematic (due to BIOS bugs) GigaByte motherboard with
an ASRock Z77M-Pro4 and the difference is awesome. All the issues I had
with the IOMMU, ACPI and ASPM are gone.

I still have to pass the intel_iommu=3Digfx_off kernel parameter or I conti=
nue
to see lots of DMAR errors for the first couple of seconds after booting
and I can=C2=B4t use the DVB tuners either.

This last point is a showstopper for me and I don=C2=B4t know where the
problem might come from. The cx23885 module (which my tuners use)
loads fine, as do the devices under /dev/dvb. Upon tuning a channel,
however, there is not data received.

Does anyone have the slightest idea what might be causing this?

I wonder whether it would work within a DomU with the PCIe tuner
passed through.


--=20
Javier Marcet <jmarcet@gmail.com>

--e89a8f50311a97362c04c99412b4
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div class=3D"gmail_quote">On Thu, Aug 30, 2012 at 6:33 PM, Konrad Rzeszute=
k Wilk <span dir=3D"ltr">&lt;<a href=3D"mailto:konrad@kernel.org" target=3D=
"_blank">konrad@kernel.org</a>&gt;</span> wrote:<br><div><br></div><div>Hi,=
</div>

<div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8=
ex;border-left:1px #ccc solid;padding-left:1ex"><div class=3D"im">&gt; I&#3=
9;ve just upgraded a server of mine from a Core i3 2100T to an i7 3770, in =
order<br>


&gt; to do full virtualization with VTd.<br>
&gt;<br>
&gt; I&#39;m using kernel 3.5.2 and Xen from git://<a href=3D"http://xenbit=
s.xen.org/xen.git" target=3D"_blank">xenbits.xen.org/xen.git</a> @ commit<b=
r>
&gt; 37d7ccdc2f50d659f1eb8ec11ee4bf8a8376926d (Fri Aug 24).<br>
&gt;<br>
&gt; Since there are various issues I&#39;m gonna comment on them all. I&#3=
9;d appreciate<br>
&gt; if you help me deciding which bug reports to file, and where to file t=
hem.<br>
<br>
</div>Its easier if there are seperate emails and then we can track them<br=
>
step-by-step.<br>
<div class=3D"im">&gt;<br>
&gt; Upon booting under the xen virtualizer everything works fine but I can=
not<br>
&gt; suspend the machine and I have reception problems on the DVB-T tuners<=
br>
<br>
</div>Right. The suspend (well, the resume part) is not yet working.<br>
&gt; installed on the system.<br>
<br>
That sounds familiar - but without more details its a bit unclear.<br></blo=
ckquote><div><br></div><div>I replaced the problematic (due to BIOS bugs) G=
igaByte motherboard with</div><div>an ASRock Z77M-Pro4 and the difference i=
s awesome. All the issues I had</div>

<div>with the IOMMU, ACPI and ASPM are gone.</div><div><br></div><div>I sti=
ll have to pass the=C2=A0intel_iommu=3Digfx_off kernel parameter or I conti=
nue</div><div>to see lots of DMAR errors for the first couple of seconds af=
ter booting</div>

<div>and I can=C2=B4t use the DVB tuners either.</div><div><br></div><div>T=
his last point is a showstopper for me and I don=C2=B4t know where the</div=
><div>problem might come from. The cx23885 module (which my tuners use)</di=
v><div>

loads fine, as do the devices under /dev/dvb. Upon tuning a channel,</div><=
div>however, there is not data received.</div><div><br></div><div>Does anyo=
ne have the slightest idea what might be causing this?</div><div><br></div>

<div>I wonder whether it would work within a DomU with the PCIe tuner</div>=
<div>passed through.</div><div><br></div></div><div><br></div>-- <br>Javier=
 Marcet &lt;<a href=3D"mailto:jmarcet@gmail.com" target=3D"_blank">jmarcet@=
gmail.com</a>&gt;<br>

<br>

--e89a8f50311a97362c04c99412b4--


--===============6499824421439869495==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============6499824421439869495==--


From xen-devel-bounces@lists.xen.org Thu Sep 13 12:02:31 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Sep 2012 12:02: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 1TC87I-0005bX-8g; Thu, 13 Sep 2012 12:01:56 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jmarcet@gmail.com>) id 1TC87G-0005bN-I7
	for xen-devel@lists.xen.org; Thu, 13 Sep 2012 12:01:54 +0000
Received: from [85.158.143.99:12646] by server-3.bemta-4.messagelabs.com id
	95/16-08232-13BC1505; Thu, 13 Sep 2012 12:01:53 +0000
X-Env-Sender: jmarcet@gmail.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1347537711!30160858!1
X-Originating-IP: [209.85.214.173]
X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14645 invoked from network); 13 Sep 2012 12:01:52 -0000
Received: from mail-ob0-f173.google.com (HELO mail-ob0-f173.google.com)
	(209.85.214.173)
	by server-15.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Sep 2012 12:01:52 -0000
Received: by obbta14 with SMTP id ta14so5409456obb.32
	for <xen-devel@lists.xen.org>; Thu, 13 Sep 2012 05:01:51 -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:cc:content-type;
	bh=kv76ye215iZqKeG8eCBh5E07SCmobOCHuUwR5Ate5E4=;
	b=rU7Bxignp/N9TO84zL1f23KL8OXSXwbVyGGtuNGkIkebojTrEnoUZstpHBtZ6tOjW8
	6+1Q5nSHbK5+bclZ6HZYoj63jx/F8gzLZf0OfLm/9NVryCcnymNHRLxsyw7Leu/BnAau
	msPI8hOFCJSfwIV34vNmQvbH5Dgm4Pyd+UlR6H0AlkpM3GENaOStDU0I7N5nDQse5YX8
	FkUd2VIh2opHXTWGZE7xMuiO4n6wFmPjnQ88/X1XbmHCwtH1n0K9J8nNa7l8oHwoY0tT
	/JWbosArfeB+nJqCExHJZEp25n0ewVsEuCFD6ltrTjnh5Ve1aqHVXUGcK14eq9C9dnqf
	fybQ==
Received: by 10.182.174.68 with SMTP id bq4mr1796912obc.53.1347537711084; Thu,
	13 Sep 2012 05:01:51 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.60.138.225 with HTTP; Thu, 13 Sep 2012 05:01:30 -0700 (PDT)
From: Javier Marcet <jmarcet@gmail.com>
Date: Thu, 13 Sep 2012 14:01:30 +0200
Message-ID: <CAAnFQG9TZj=SxYK_jxqN=M6L40vL=AZu9EM2tbEffPhkL1s8FA@mail.gmail.com>
To: Konrad Rzeszutek Wilk <konrad@kernel.org>
Cc: Xen Devel Mailing list <xen-devel@lists.xen.org>
Subject: [Xen-devel]  Xen 4.2.0-rc4 issues with DVB tuner
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============6499824421439869495=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============6499824421439869495==
Content-Type: multipart/alternative; boundary=e89a8f50311a97362c04c99412b4

--e89a8f50311a97362c04c99412b4
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Thu, Aug 30, 2012 at 6:33 PM, Konrad Rzeszutek Wilk <konrad@kernel.org>w=
rote:

Hi,


> > I've just upgraded a server of mine from a Core i3 2100T to an i7 3770,
> in order
> > to do full virtualization with VTd.
> >
> > I'm using kernel 3.5.2 and Xen from git://xenbits.xen.org/xen.git @
> commit
> > 37d7ccdc2f50d659f1eb8ec11ee4bf8a8376926d (Fri Aug 24).
> >
> > Since there are various issues I'm gonna comment on them all. I'd
> appreciate
> > if you help me deciding which bug reports to file, and where to file
> them.
>
> Its easier if there are seperate emails and then we can track them
> step-by-step.
> >
> > Upon booting under the xen virtualizer everything works fine but I cann=
ot
> > suspend the machine and I have reception problems on the DVB-T tuners
>
> Right. The suspend (well, the resume part) is not yet working.
> > installed on the system.
>
> That sounds familiar - but without more details its a bit unclear.
>

I replaced the problematic (due to BIOS bugs) GigaByte motherboard with
an ASRock Z77M-Pro4 and the difference is awesome. All the issues I had
with the IOMMU, ACPI and ASPM are gone.

I still have to pass the intel_iommu=3Digfx_off kernel parameter or I conti=
nue
to see lots of DMAR errors for the first couple of seconds after booting
and I can=C2=B4t use the DVB tuners either.

This last point is a showstopper for me and I don=C2=B4t know where the
problem might come from. The cx23885 module (which my tuners use)
loads fine, as do the devices under /dev/dvb. Upon tuning a channel,
however, there is not data received.

Does anyone have the slightest idea what might be causing this?

I wonder whether it would work within a DomU with the PCIe tuner
passed through.


--=20
Javier Marcet <jmarcet@gmail.com>

--e89a8f50311a97362c04c99412b4
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div class=3D"gmail_quote">On Thu, Aug 30, 2012 at 6:33 PM, Konrad Rzeszute=
k Wilk <span dir=3D"ltr">&lt;<a href=3D"mailto:konrad@kernel.org" target=3D=
"_blank">konrad@kernel.org</a>&gt;</span> wrote:<br><div><br></div><div>Hi,=
</div>

<div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8=
ex;border-left:1px #ccc solid;padding-left:1ex"><div class=3D"im">&gt; I&#3=
9;ve just upgraded a server of mine from a Core i3 2100T to an i7 3770, in =
order<br>


&gt; to do full virtualization with VTd.<br>
&gt;<br>
&gt; I&#39;m using kernel 3.5.2 and Xen from git://<a href=3D"http://xenbit=
s.xen.org/xen.git" target=3D"_blank">xenbits.xen.org/xen.git</a> @ commit<b=
r>
&gt; 37d7ccdc2f50d659f1eb8ec11ee4bf8a8376926d (Fri Aug 24).<br>
&gt;<br>
&gt; Since there are various issues I&#39;m gonna comment on them all. I&#3=
9;d appreciate<br>
&gt; if you help me deciding which bug reports to file, and where to file t=
hem.<br>
<br>
</div>Its easier if there are seperate emails and then we can track them<br=
>
step-by-step.<br>
<div class=3D"im">&gt;<br>
&gt; Upon booting under the xen virtualizer everything works fine but I can=
not<br>
&gt; suspend the machine and I have reception problems on the DVB-T tuners<=
br>
<br>
</div>Right. The suspend (well, the resume part) is not yet working.<br>
&gt; installed on the system.<br>
<br>
That sounds familiar - but without more details its a bit unclear.<br></blo=
ckquote><div><br></div><div>I replaced the problematic (due to BIOS bugs) G=
igaByte motherboard with</div><div>an ASRock Z77M-Pro4 and the difference i=
s awesome. All the issues I had</div>

<div>with the IOMMU, ACPI and ASPM are gone.</div><div><br></div><div>I sti=
ll have to pass the=C2=A0intel_iommu=3Digfx_off kernel parameter or I conti=
nue</div><div>to see lots of DMAR errors for the first couple of seconds af=
ter booting</div>

<div>and I can=C2=B4t use the DVB tuners either.</div><div><br></div><div>T=
his last point is a showstopper for me and I don=C2=B4t know where the</div=
><div>problem might come from. The cx23885 module (which my tuners use)</di=
v><div>

loads fine, as do the devices under /dev/dvb. Upon tuning a channel,</div><=
div>however, there is not data received.</div><div><br></div><div>Does anyo=
ne have the slightest idea what might be causing this?</div><div><br></div>

<div>I wonder whether it would work within a DomU with the PCIe tuner</div>=
<div>passed through.</div><div><br></div></div><div><br></div>-- <br>Javier=
 Marcet &lt;<a href=3D"mailto:jmarcet@gmail.com" target=3D"_blank">jmarcet@=
gmail.com</a>&gt;<br>

<br>

--e89a8f50311a97362c04c99412b4--


--===============6499824421439869495==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============6499824421439869495==--


From xen-devel-bounces@lists.xen.org Thu Sep 13 12:22:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Sep 2012 12:22:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TC8QK-0005uh-8c; Thu, 13 Sep 2012 12:21:36 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1TC8QI-0005uc-QX
	for xen-devel@lists.xen.org; Thu, 13 Sep 2012 12:21:35 +0000
Received: from [85.158.139.83:7483] by server-3.bemta-5.messagelabs.com id
	8C/48-21836-ECFC1505; Thu, 13 Sep 2012 12:21:34 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-2.tower-182.messagelabs.com!1347538893!27470380!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6538 invoked from network); 13 Sep 2012 12:21:33 -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; 13 Sep 2012 12:21:33 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1TC8QE-0003qP-Ub; Thu, 13 Sep 2012 12:21:30 +0000
Date: Thu, 13 Sep 2012 13:21:30 +0100
From: Tim Deegan <tim@xen.org>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20120913122130.GB12881@ocelot.phlegethon.org>
References: <CAFw--Dd0k7L+T_UJc0yHAkUGrY_-GDHaQjK3OM-1UdOp=J-wAQ@mail.gmail.com>
	<20120907085036.GA71093@ocelot.phlegethon.org>
	<5049E2C70200007800099B21@nat28.tlf.novell.com>
	<20120913101120.GA12881@ocelot.phlegethon.org>
	<5051E531020000780009B083@nat28.tlf.novell.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <5051E531020000780009B083@nat28.tlf.novell.com>
User-Agent: Mutt/1.4.2.1i
Cc: Paolo Bonzini <pbonzini@redhat.com>, Jeffrey Karrels <karrelsj@gmail.com>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Clang/LLVM version requirements
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At 12:52 +0100 on 13 Sep (1347540769), Jan Beulich wrote:
> >>> On 13.09.12 at 12:11, Tim Deegan <tim@xen.org> wrote:
> > At 11:04 +0100 on 07 Sep (1347015863), Jan Beulich wrote:
> >> >>> On 07.09.12 at 10:50, Tim Deegan <tim@xen.org> wrote:
> >> > In any case we probably ought to check for stray .data symbols too.
> >> 
> >> Not really, no. Those would still be present in reloc.bin, and
> >> hence make it into reloc.S.
> > 
> > But they would break the test, because the magic alignment happens in
> > .text, right?  Anyway, compile-time failure seems more useful.  How
> > about this, based on the similar checks for init-only files?
> 
> Yes, it's happening in .text currently. The problem, iirc, really was
> that _end and __bss_start didn't always match (depending on
> compiler version), apparently because at the linking stage _end
> got aligned more strictly than __bss_start.
> 
> So the patch is fine by me if it covers that misalignment case.
> But it seems a little heavy handed - I'd think that instead of the
> sub-section, we could just create an arbitrary other section, or
> even allow uninitialized variable (it's unclear to me why Paolo
> wrote the comment - in c/s 25479:61dfb3da56b - regarding BSS
> the way it is now) - after all we only need to make sure that
> - the space gets properly allocated in trampoline.S, i.e. also in
>   reloc.bin
> - all accesses are PC-relative
> Neither has anything to do with use of uninitialized variables.

Allowing BSS would just need a few extra runes (AFAICS,
"--set-section-flags .bss=alloc,load,contents") in the objcopy that
makes reloc.bin.  But I'm not sure how to make sure everything is
rip-relative, do if that's the real concern I'm inclined to go with
this compile-time check and exclude .[ro]data[.*] as well.
We can always fix it up to allow bss and data sections if we ever
actually need them.

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 13 12:22:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Sep 2012 12:22:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TC8QK-0005uh-8c; Thu, 13 Sep 2012 12:21:36 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1TC8QI-0005uc-QX
	for xen-devel@lists.xen.org; Thu, 13 Sep 2012 12:21:35 +0000
Received: from [85.158.139.83:7483] by server-3.bemta-5.messagelabs.com id
	8C/48-21836-ECFC1505; Thu, 13 Sep 2012 12:21:34 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-2.tower-182.messagelabs.com!1347538893!27470380!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6538 invoked from network); 13 Sep 2012 12:21:33 -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; 13 Sep 2012 12:21:33 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1TC8QE-0003qP-Ub; Thu, 13 Sep 2012 12:21:30 +0000
Date: Thu, 13 Sep 2012 13:21:30 +0100
From: Tim Deegan <tim@xen.org>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20120913122130.GB12881@ocelot.phlegethon.org>
References: <CAFw--Dd0k7L+T_UJc0yHAkUGrY_-GDHaQjK3OM-1UdOp=J-wAQ@mail.gmail.com>
	<20120907085036.GA71093@ocelot.phlegethon.org>
	<5049E2C70200007800099B21@nat28.tlf.novell.com>
	<20120913101120.GA12881@ocelot.phlegethon.org>
	<5051E531020000780009B083@nat28.tlf.novell.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <5051E531020000780009B083@nat28.tlf.novell.com>
User-Agent: Mutt/1.4.2.1i
Cc: Paolo Bonzini <pbonzini@redhat.com>, Jeffrey Karrels <karrelsj@gmail.com>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Clang/LLVM version requirements
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At 12:52 +0100 on 13 Sep (1347540769), Jan Beulich wrote:
> >>> On 13.09.12 at 12:11, Tim Deegan <tim@xen.org> wrote:
> > At 11:04 +0100 on 07 Sep (1347015863), Jan Beulich wrote:
> >> >>> On 07.09.12 at 10:50, Tim Deegan <tim@xen.org> wrote:
> >> > In any case we probably ought to check for stray .data symbols too.
> >> 
> >> Not really, no. Those would still be present in reloc.bin, and
> >> hence make it into reloc.S.
> > 
> > But they would break the test, because the magic alignment happens in
> > .text, right?  Anyway, compile-time failure seems more useful.  How
> > about this, based on the similar checks for init-only files?
> 
> Yes, it's happening in .text currently. The problem, iirc, really was
> that _end and __bss_start didn't always match (depending on
> compiler version), apparently because at the linking stage _end
> got aligned more strictly than __bss_start.
> 
> So the patch is fine by me if it covers that misalignment case.
> But it seems a little heavy handed - I'd think that instead of the
> sub-section, we could just create an arbitrary other section, or
> even allow uninitialized variable (it's unclear to me why Paolo
> wrote the comment - in c/s 25479:61dfb3da56b - regarding BSS
> the way it is now) - after all we only need to make sure that
> - the space gets properly allocated in trampoline.S, i.e. also in
>   reloc.bin
> - all accesses are PC-relative
> Neither has anything to do with use of uninitialized variables.

Allowing BSS would just need a few extra runes (AFAICS,
"--set-section-flags .bss=alloc,load,contents") in the objcopy that
makes reloc.bin.  But I'm not sure how to make sure everything is
rip-relative, do if that's the real concern I'm inclined to go with
this compile-time check and exclude .[ro]data[.*] as well.
We can always fix it up to allow bss and data sections if we ever
actually need them.

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 13 12:41:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Sep 2012 12:41: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 1TC8j8-0006Ok-P5; Thu, 13 Sep 2012 12:41:02 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <paolo.bonzini@gmail.com>) id 1TC8j7-0006Of-2h
	for xen-devel@lists.xen.org; Thu, 13 Sep 2012 12:41:01 +0000
Received: from [85.158.138.51:34971] by server-6.bemta-3.messagelabs.com id
	09/54-29694-C54D1505; Thu, 13 Sep 2012 12:41:00 +0000
X-Env-Sender: paolo.bonzini@gmail.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1347540057!11697672!1
X-Originating-IP: [209.85.160.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16400 invoked from network); 13 Sep 2012 12:40:59 -0000
Received: from mail-pb0-f45.google.com (HELO mail-pb0-f45.google.com)
	(209.85.160.45)
	by server-13.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Sep 2012 12:40:59 -0000
Received: by pbbrp12 with SMTP id rp12so4007142pbb.32
	for <xen-devel@lists.xen.org>; Thu, 13 Sep 2012 05:40:57 -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=hnrVIyt6tya7LXXPw/N0wIBin5DwKomqJhn+K8Bq0kw=;
	b=HCIXrZY18VKHvCKx/HUmrAqsZAjvEpKiAeq6hPjgCGqVpsargFmoSPN/rY062Zkfmm
	62n/WaosQKAYrESyBAi4JQFmWGZRr0Fha7Rm/kO0NF517WcaBU1iCeM6ay3oKcMrIlWZ
	m2smRWG2zzEWCUskTngic8kEffYdaz0cu3SpZBNkL4aFeAed6zwPnagq+ctS7+/5+k0P
	cCJsShPas1FCs2a+ZdON/9squSCXBcyGYNzAFAsQvFraMW5bdMFw6pczpIQ+yPlv6/+t
	/dpeZsITZYYTlS7V0Ho5lwX2818o6DyKwng7tWr3Mkc1RUOIrhxe0DkMszUeeWZcEst9
	v2aA==
Received: by 10.68.226.167 with SMTP id rt7mr4455291pbc.146.1347540056887;
	Thu, 13 Sep 2012 05:40:56 -0700 (PDT)
Received: from yakj.usersys.redhat.com (93-34-169-1.ip50.fastwebnet.it.
	[93.34.169.1])
	by mx.google.com with ESMTPS id rm6sm6852084pbc.54.2012.09.13.05.40.51
	(version=TLSv1/SSLv3 cipher=OTHER);
	Thu, 13 Sep 2012 05:40:53 -0700 (PDT)
Message-ID: <5051D440.4000007@redhat.com>
Date: Thu, 13 Sep 2012 14:40:32 +0200
From: Paolo Bonzini <pbonzini@redhat.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120828 Thunderbird/15.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <CAFw--Dd0k7L+T_UJc0yHAkUGrY_-GDHaQjK3OM-1UdOp=J-wAQ@mail.gmail.com>
	<20120907085036.GA71093@ocelot.phlegethon.org>
	<5049E2C70200007800099B21@nat28.tlf.novell.com>
	<20120913101120.GA12881@ocelot.phlegethon.org>
	<5051E531020000780009B083@nat28.tlf.novell.com>
In-Reply-To: <5051E531020000780009B083@nat28.tlf.novell.com>
Cc: Tim Deegan <tim@xen.org>, Jeffrey Karrels <karrelsj@gmail.com>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Clang/LLVM version requirements
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Il 13/09/2012 13:52, Jan Beulich ha scritto:
> 
> So the patch is fine by me if it covers that misalignment case.
> But it seems a little heavy handed - I'd think that instead of the
> sub-section, we could just create an arbitrary other section, or
> even allow uninitialized variable (it's unclear to me why Paolo
> wrote the comment - in c/s 25479:61dfb3da56b - regarding BSS
> the way it is now) - after all we only need to make sure that
> - the space gets properly allocated in trampoline.S, i.e. also in
>   reloc.bin
> - all accesses are PC-relative
> Neither has anything to do with use of uninitialized variables.

We cannot use BSS because it doesn't appear in reloc.S.

Apart from BSS, there would be no benefit for reloc to move itself to
BOOT_TRAMPOLINE, because BOOT_TRAMPOLINE is not a known location
anymore.  So it was easier to just run it in place from where we put it,
in the middle of head.S, but this means BSS disappears after extracting
reloc.bin.

So it's not really because the code must be relocatable, but more
because of the way we extract the binary data and put it in the middle
of head.S.

Initialized data works as long as you pass -fno-zero-initialized-in-bss
to the compiler or it is eaten.  I used assembly to declare the alloc
variable, because I wasn't sure of which GCC versions need the option,
and whether older versions are supported for compiling Xen.

Paolo

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 13 12:41:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Sep 2012 12:41: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 1TC8j8-0006Ok-P5; Thu, 13 Sep 2012 12:41:02 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <paolo.bonzini@gmail.com>) id 1TC8j7-0006Of-2h
	for xen-devel@lists.xen.org; Thu, 13 Sep 2012 12:41:01 +0000
Received: from [85.158.138.51:34971] by server-6.bemta-3.messagelabs.com id
	09/54-29694-C54D1505; Thu, 13 Sep 2012 12:41:00 +0000
X-Env-Sender: paolo.bonzini@gmail.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1347540057!11697672!1
X-Originating-IP: [209.85.160.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16400 invoked from network); 13 Sep 2012 12:40:59 -0000
Received: from mail-pb0-f45.google.com (HELO mail-pb0-f45.google.com)
	(209.85.160.45)
	by server-13.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Sep 2012 12:40:59 -0000
Received: by pbbrp12 with SMTP id rp12so4007142pbb.32
	for <xen-devel@lists.xen.org>; Thu, 13 Sep 2012 05:40:57 -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=hnrVIyt6tya7LXXPw/N0wIBin5DwKomqJhn+K8Bq0kw=;
	b=HCIXrZY18VKHvCKx/HUmrAqsZAjvEpKiAeq6hPjgCGqVpsargFmoSPN/rY062Zkfmm
	62n/WaosQKAYrESyBAi4JQFmWGZRr0Fha7Rm/kO0NF517WcaBU1iCeM6ay3oKcMrIlWZ
	m2smRWG2zzEWCUskTngic8kEffYdaz0cu3SpZBNkL4aFeAed6zwPnagq+ctS7+/5+k0P
	cCJsShPas1FCs2a+ZdON/9squSCXBcyGYNzAFAsQvFraMW5bdMFw6pczpIQ+yPlv6/+t
	/dpeZsITZYYTlS7V0Ho5lwX2818o6DyKwng7tWr3Mkc1RUOIrhxe0DkMszUeeWZcEst9
	v2aA==
Received: by 10.68.226.167 with SMTP id rt7mr4455291pbc.146.1347540056887;
	Thu, 13 Sep 2012 05:40:56 -0700 (PDT)
Received: from yakj.usersys.redhat.com (93-34-169-1.ip50.fastwebnet.it.
	[93.34.169.1])
	by mx.google.com with ESMTPS id rm6sm6852084pbc.54.2012.09.13.05.40.51
	(version=TLSv1/SSLv3 cipher=OTHER);
	Thu, 13 Sep 2012 05:40:53 -0700 (PDT)
Message-ID: <5051D440.4000007@redhat.com>
Date: Thu, 13 Sep 2012 14:40:32 +0200
From: Paolo Bonzini <pbonzini@redhat.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120828 Thunderbird/15.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <CAFw--Dd0k7L+T_UJc0yHAkUGrY_-GDHaQjK3OM-1UdOp=J-wAQ@mail.gmail.com>
	<20120907085036.GA71093@ocelot.phlegethon.org>
	<5049E2C70200007800099B21@nat28.tlf.novell.com>
	<20120913101120.GA12881@ocelot.phlegethon.org>
	<5051E531020000780009B083@nat28.tlf.novell.com>
In-Reply-To: <5051E531020000780009B083@nat28.tlf.novell.com>
Cc: Tim Deegan <tim@xen.org>, Jeffrey Karrels <karrelsj@gmail.com>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Clang/LLVM version requirements
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Il 13/09/2012 13:52, Jan Beulich ha scritto:
> 
> So the patch is fine by me if it covers that misalignment case.
> But it seems a little heavy handed - I'd think that instead of the
> sub-section, we could just create an arbitrary other section, or
> even allow uninitialized variable (it's unclear to me why Paolo
> wrote the comment - in c/s 25479:61dfb3da56b - regarding BSS
> the way it is now) - after all we only need to make sure that
> - the space gets properly allocated in trampoline.S, i.e. also in
>   reloc.bin
> - all accesses are PC-relative
> Neither has anything to do with use of uninitialized variables.

We cannot use BSS because it doesn't appear in reloc.S.

Apart from BSS, there would be no benefit for reloc to move itself to
BOOT_TRAMPOLINE, because BOOT_TRAMPOLINE is not a known location
anymore.  So it was easier to just run it in place from where we put it,
in the middle of head.S, but this means BSS disappears after extracting
reloc.bin.

So it's not really because the code must be relocatable, but more
because of the way we extract the binary data and put it in the middle
of head.S.

Initialized data works as long as you pass -fno-zero-initialized-in-bss
to the compiler or it is eaten.  I used assembly to declare the alloc
variable, because I wasn't sure of which GCC versions need the option,
and whether older versions are supported for compiling Xen.

Paolo

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 13 13:17:18 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Sep 2012 13:17:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TC9Ht-00077d-CV; Thu, 13 Sep 2012 13:16: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 1TC9Hs-00077T-CL
	for xen-devel@lists.xen.org; Thu, 13 Sep 2012 13:16:56 +0000
Received: from [85.158.137.99:61575] by server-3.bemta-3.messagelabs.com id
	08/67-21322-7CCD1505; Thu, 13 Sep 2012 13:16:55 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-8.tower-217.messagelabs.com!1347542212!12141843!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDc0ODk3Mg==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23710 invoked from network); 13 Sep 2012 13:16:54 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-8.tower-217.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 13 Sep 2012 13:16:54 -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 q8DDGlUI006798
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 13 Sep 2012 13:16:48 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
	q8DDGlAb020585
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 13 Sep 2012 13:16:47 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
	q8DDGlkD026382; Thu, 13 Sep 2012 08:16:47 -0500
Received: from localhost.localdomain (/208.54.36.250)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 13 Sep 2012 06:16:43 -0700
Date: Thu, 13 Sep 2012 09:16:26 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: "Ren, Yongjie" <yongjie.ren@intel.com>
Message-ID: <20120913131623.GA16635@localhost.localdomain>
References: <1B4B44D9196EFF41AE41FDA404FC0A1019BF79@SHSMSX101.ccr.corp.intel.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1B4B44D9196EFF41AE41FDA404FC0A1019BF79@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: 'Keir Fraser' <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] Xen4.2-rc4 test result
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Sep 13, 2012 at 07:02:40AM +0000, Ren, Yongjie wrote:
> Hi All,
> We did a round testing for RC4 (CS# 25834) in xen-4.2-testing tree with Linux 3.5.3 dom0.
> We found 1 new issue (which is a Dom0 issue and has nothing to do with Xen4.2), and no fixed issue.
> 
> New bug (1):
> 1. XenU PV guest with vif network can't boot up with Linux3.6 dom0
>   http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1832
>   --A regression from Linux 3.5 to 3.6.

Oh, that is the xennet_poll one?That is fixed in v3.6-rc5. That is a
domU problem - not domU. This git commit fixes it:

commit 3683243b2c551e58082b179fd153c7d43ddc503b
Author: Ian Campbell <Ian.Campbell@citrix.com>
Date:   Wed Aug 22 00:26:47 2012 +0000

    xen-netfront: use __pskb_pull_tail to ensure linear area is big
enough on RX
    

> 
> The following are some of the old issues which we guess are something important.
> Some of the old issues:
> 1. Fail to probe NIC driver to HVM domU (with 3.5/3.6 Linux as Dom0)
>   http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1824
>   -- We already know the corrupt commit in Linux tree. Konrad will try to fix it.
> 2. Poor performance when do guest save/restore and migration with linux 3.x dom0
>   http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1784
> 3. after detaching a VF from a guest, shutdown the guest is very slow (related to stdvga setting)
>   http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1812
> 4. Dom0 cannot be shut down before PCI device detachment from a running guest
>   http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1826
> 5. Guest hang after resuming from S3
>   http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1828
> 6. Dom0 S3 resume fails
>   http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1707
> 
> Best Regards,
>      Yongjie (Jay)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 13 13:17:18 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Sep 2012 13:17:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TC9Ht-00077d-CV; Thu, 13 Sep 2012 13:16: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 1TC9Hs-00077T-CL
	for xen-devel@lists.xen.org; Thu, 13 Sep 2012 13:16:56 +0000
Received: from [85.158.137.99:61575] by server-3.bemta-3.messagelabs.com id
	08/67-21322-7CCD1505; Thu, 13 Sep 2012 13:16:55 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-8.tower-217.messagelabs.com!1347542212!12141843!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDc0ODk3Mg==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23710 invoked from network); 13 Sep 2012 13:16:54 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-8.tower-217.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 13 Sep 2012 13:16:54 -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 q8DDGlUI006798
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 13 Sep 2012 13:16:48 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
	q8DDGlAb020585
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 13 Sep 2012 13:16:47 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
	q8DDGlkD026382; Thu, 13 Sep 2012 08:16:47 -0500
Received: from localhost.localdomain (/208.54.36.250)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 13 Sep 2012 06:16:43 -0700
Date: Thu, 13 Sep 2012 09:16:26 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: "Ren, Yongjie" <yongjie.ren@intel.com>
Message-ID: <20120913131623.GA16635@localhost.localdomain>
References: <1B4B44D9196EFF41AE41FDA404FC0A1019BF79@SHSMSX101.ccr.corp.intel.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1B4B44D9196EFF41AE41FDA404FC0A1019BF79@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: 'Keir Fraser' <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] Xen4.2-rc4 test result
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Sep 13, 2012 at 07:02:40AM +0000, Ren, Yongjie wrote:
> Hi All,
> We did a round testing for RC4 (CS# 25834) in xen-4.2-testing tree with Linux 3.5.3 dom0.
> We found 1 new issue (which is a Dom0 issue and has nothing to do with Xen4.2), and no fixed issue.
> 
> New bug (1):
> 1. XenU PV guest with vif network can't boot up with Linux3.6 dom0
>   http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1832
>   --A regression from Linux 3.5 to 3.6.

Oh, that is the xennet_poll one?That is fixed in v3.6-rc5. That is a
domU problem - not domU. This git commit fixes it:

commit 3683243b2c551e58082b179fd153c7d43ddc503b
Author: Ian Campbell <Ian.Campbell@citrix.com>
Date:   Wed Aug 22 00:26:47 2012 +0000

    xen-netfront: use __pskb_pull_tail to ensure linear area is big
enough on RX
    

> 
> The following are some of the old issues which we guess are something important.
> Some of the old issues:
> 1. Fail to probe NIC driver to HVM domU (with 3.5/3.6 Linux as Dom0)
>   http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1824
>   -- We already know the corrupt commit in Linux tree. Konrad will try to fix it.
> 2. Poor performance when do guest save/restore and migration with linux 3.x dom0
>   http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1784
> 3. after detaching a VF from a guest, shutdown the guest is very slow (related to stdvga setting)
>   http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1812
> 4. Dom0 cannot be shut down before PCI device detachment from a running guest
>   http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1826
> 5. Guest hang after resuming from S3
>   http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1828
> 6. Dom0 S3 resume fails
>   http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1707
> 
> Best Regards,
>      Yongjie (Jay)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 13 13:22:39 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Sep 2012 13:22:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TC9N6-0007Me-45; Thu, 13 Sep 2012 13:22:20 +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 1TC9N4-0007MP-0l
	for xen-devel@lists.xen.org; Thu, 13 Sep 2012 13:22:18 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1347542526!10318767!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzM4ODI0\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3384 invoked from network); 13 Sep 2012 13:22:07 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-4.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 13 Sep 2012 13:22:07 -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 q8DDM0Gb022382
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 13 Sep 2012 13:22:01 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
	q8DDLxhc000728
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 13 Sep 2012 13:22:00 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
	q8DDLxWe023359; Thu, 13 Sep 2012 08:21:59 -0500
Received: from localhost.localdomain (/208.54.36.250)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 13 Sep 2012 06:21:58 -0700
Date: Thu, 13 Sep 2012 09:21:55 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: "Duan, Ronghui" <ronghui.duan@intel.com>
Message-ID: <20120913132153.GC16635@localhost.localdomain>
References: <A21691DE07B84740B5F0B81466D5148A23BCF1DF@SHSMSX102.ccr.corp.intel.com>
	<20120907174922.GA13040@phenom.dumpdata.com>
	<A21691DE07B84740B5F0B81466D5148A23BF6833@SHSMSX102.ccr.corp.intel.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <A21691DE07B84740B5F0B81466D5148A23BF6833@SHSMSX102.ccr.corp.intel.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: "Stefano.Stabellini@eu.citrix.com" <Stefano.Stabellini@eu.citrix.com>,
	"Ian.Jackson@eu.citrix.com" <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [RFC v1 0/5] VBD: enlarge max segment per request
 in blkfront
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Sep 13, 2012 at 02:28:12AM +0000, Duan, Ronghui wrote:
> > form xentop.
> > > Read 1K random	IOPS	   Dom0 CPU	DomU CPU%
> > > 		W	52005.9	86.6	71
> > > 		W/O	52123.1	85.8	66.9
> > 
> > So I am getting some different numbers. I tried a simple 4K read:
> > 
> > [/dev/xvda1]
> > bssplit=4K
> > rw=read
> > direct=1
> > size=4g
> > ioengine=libaio
> > iodepth=64
> > 
> > And with your patch got:
> >   read : io=4096.0MB, bw=92606KB/s, iops=23151 , runt= 45292msec
> > 
> > without:
> >   read : io=4096.0MB, bw=145187KB/s, iops=36296 , runt= 28889msec
> > 
> What type of backend file you are using? In order to remove the influence of cache in Dom0, I use a physical partition as backend.
> In code level, although there is some overhead in my patch compared to original, but it should not to be so big. :)

Right :-)

phy:/dev/sda,xvda,w

The sda is a Corsair SSD.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 13 13:22:39 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Sep 2012 13:22:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TC9N6-0007Me-45; Thu, 13 Sep 2012 13:22:20 +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 1TC9N4-0007MP-0l
	for xen-devel@lists.xen.org; Thu, 13 Sep 2012 13:22:18 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1347542526!10318767!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzM4ODI0\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3384 invoked from network); 13 Sep 2012 13:22:07 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-4.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 13 Sep 2012 13:22:07 -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 q8DDM0Gb022382
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 13 Sep 2012 13:22:01 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
	q8DDLxhc000728
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 13 Sep 2012 13:22:00 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
	q8DDLxWe023359; Thu, 13 Sep 2012 08:21:59 -0500
Received: from localhost.localdomain (/208.54.36.250)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 13 Sep 2012 06:21:58 -0700
Date: Thu, 13 Sep 2012 09:21:55 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: "Duan, Ronghui" <ronghui.duan@intel.com>
Message-ID: <20120913132153.GC16635@localhost.localdomain>
References: <A21691DE07B84740B5F0B81466D5148A23BCF1DF@SHSMSX102.ccr.corp.intel.com>
	<20120907174922.GA13040@phenom.dumpdata.com>
	<A21691DE07B84740B5F0B81466D5148A23BF6833@SHSMSX102.ccr.corp.intel.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <A21691DE07B84740B5F0B81466D5148A23BF6833@SHSMSX102.ccr.corp.intel.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: "Stefano.Stabellini@eu.citrix.com" <Stefano.Stabellini@eu.citrix.com>,
	"Ian.Jackson@eu.citrix.com" <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [RFC v1 0/5] VBD: enlarge max segment per request
 in blkfront
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Sep 13, 2012 at 02:28:12AM +0000, Duan, Ronghui wrote:
> > form xentop.
> > > Read 1K random	IOPS	   Dom0 CPU	DomU CPU%
> > > 		W	52005.9	86.6	71
> > > 		W/O	52123.1	85.8	66.9
> > 
> > So I am getting some different numbers. I tried a simple 4K read:
> > 
> > [/dev/xvda1]
> > bssplit=4K
> > rw=read
> > direct=1
> > size=4g
> > ioengine=libaio
> > iodepth=64
> > 
> > And with your patch got:
> >   read : io=4096.0MB, bw=92606KB/s, iops=23151 , runt= 45292msec
> > 
> > without:
> >   read : io=4096.0MB, bw=145187KB/s, iops=36296 , runt= 28889msec
> > 
> What type of backend file you are using? In order to remove the influence of cache in Dom0, I use a physical partition as backend.
> In code level, although there is some overhead in my patch compared to original, but it should not to be so big. :)

Right :-)

phy:/dev/sda,xvda,w

The sda is a Corsair SSD.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 13 13:24:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Sep 2012 13:24:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TC9Ob-0007TF-JQ; Thu, 13 Sep 2012 13:23:53 +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 1TC9Oa-0007T8-Vb
	for xen-devel@lists.xen.org; Thu, 13 Sep 2012 13:23:53 +0000
Received: from [85.158.143.35:50746] by server-2.bemta-4.messagelabs.com id
	49/11-21239-86ED1505; Thu, 13 Sep 2012 13:23:52 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1347542630!18174826!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDc0ODk3Mg==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14382 invoked from network); 13 Sep 2012 13:23:51 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-14.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 13 Sep 2012 13:23:51 -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 q8DDNh3W014694
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 13 Sep 2012 13:23:44 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
	q8DDNfDp005884
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 13 Sep 2012 13:23:42 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
	q8DDNfDj031258; Thu, 13 Sep 2012 08:23:41 -0500
Received: from localhost.localdomain (/208.54.36.250)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 13 Sep 2012 06:23:41 -0700
Date: Thu, 13 Sep 2012 09:23:37 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20120913132335.GD16635@localhost.localdomain>
References: <A21691DE07B84740B5F0B81466D5148A23BCF1DF@SHSMSX102.ccr.corp.intel.com>
	<20120907174922.GA13040@phenom.dumpdata.com>
	<A21691DE07B84740B5F0B81466D5148A23BF6833@SHSMSX102.ccr.corp.intel.com>
	<5051A83B020000780009AF93@nat28.tlf.novell.com>
	<alpine.DEB.2.02.1209131203270.15568@kaball.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <alpine.DEB.2.02.1209131203270.15568@kaball.uk.xensource.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: Ronghui Duan <ronghui.duan@intel.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] [RFC v1 0/5] VBD: enlarge max segment per request
 in blkfront
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Sep 13, 2012 at 12:05:35PM +0100, Stefano Stabellini wrote:
> On Thu, 13 Sep 2012, Jan Beulich wrote:
> > >>> On 13.09.12 at 04:28, "Duan, Ronghui" <ronghui.duan@intel.com> wrote:
> > >> And with your patch got:
> > >>   read : io=4096.0MB, bw=92606KB/s, iops=23151 , runt= 45292msec
> > >> 
> > >> without:
> > >>   read : io=4096.0MB, bw=145187KB/s, iops=36296 , runt= 28889msec
> > >> 
> > > What type of backend file you are using? In order to remove the influence of 
> > > cache in Dom0, I use a physical partition as backend.
> > 
> > But you certainly shouldn't be proposing features getting used
> > unconditionally or by default that benefit one class of backing
> > devices and severely penalize others.
> 
> Right.
> I am wondering.. Considering that the in-kernel blkback is mainly used
> with physical partitions, is it possible that your patches cause a
> regression with unmodified backends that don't support the new protocol,
> like QEMU for example?

Well for right now I am just using the most simple configuration to
eliminate any extra variables (stacking of components). So my
"testing" has been just on phy:/dev/sda,xvda,w with the sda being
a Corsair SSD.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 13 13:24:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Sep 2012 13:24:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TC9Ob-0007TF-JQ; Thu, 13 Sep 2012 13:23:53 +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 1TC9Oa-0007T8-Vb
	for xen-devel@lists.xen.org; Thu, 13 Sep 2012 13:23:53 +0000
Received: from [85.158.143.35:50746] by server-2.bemta-4.messagelabs.com id
	49/11-21239-86ED1505; Thu, 13 Sep 2012 13:23:52 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1347542630!18174826!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDc0ODk3Mg==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14382 invoked from network); 13 Sep 2012 13:23:51 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-14.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 13 Sep 2012 13:23:51 -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 q8DDNh3W014694
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 13 Sep 2012 13:23:44 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
	q8DDNfDp005884
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 13 Sep 2012 13:23:42 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
	q8DDNfDj031258; Thu, 13 Sep 2012 08:23:41 -0500
Received: from localhost.localdomain (/208.54.36.250)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 13 Sep 2012 06:23:41 -0700
Date: Thu, 13 Sep 2012 09:23:37 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20120913132335.GD16635@localhost.localdomain>
References: <A21691DE07B84740B5F0B81466D5148A23BCF1DF@SHSMSX102.ccr.corp.intel.com>
	<20120907174922.GA13040@phenom.dumpdata.com>
	<A21691DE07B84740B5F0B81466D5148A23BF6833@SHSMSX102.ccr.corp.intel.com>
	<5051A83B020000780009AF93@nat28.tlf.novell.com>
	<alpine.DEB.2.02.1209131203270.15568@kaball.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <alpine.DEB.2.02.1209131203270.15568@kaball.uk.xensource.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: Ronghui Duan <ronghui.duan@intel.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] [RFC v1 0/5] VBD: enlarge max segment per request
 in blkfront
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Sep 13, 2012 at 12:05:35PM +0100, Stefano Stabellini wrote:
> On Thu, 13 Sep 2012, Jan Beulich wrote:
> > >>> On 13.09.12 at 04:28, "Duan, Ronghui" <ronghui.duan@intel.com> wrote:
> > >> And with your patch got:
> > >>   read : io=4096.0MB, bw=92606KB/s, iops=23151 , runt= 45292msec
> > >> 
> > >> without:
> > >>   read : io=4096.0MB, bw=145187KB/s, iops=36296 , runt= 28889msec
> > >> 
> > > What type of backend file you are using? In order to remove the influence of 
> > > cache in Dom0, I use a physical partition as backend.
> > 
> > But you certainly shouldn't be proposing features getting used
> > unconditionally or by default that benefit one class of backing
> > devices and severely penalize others.
> 
> Right.
> I am wondering.. Considering that the in-kernel blkback is mainly used
> with physical partitions, is it possible that your patches cause a
> regression with unmodified backends that don't support the new protocol,
> like QEMU for example?

Well for right now I am just using the most simple configuration to
eliminate any extra variables (stacking of components). So my
"testing" has been just on phy:/dev/sda,xvda,w with the sda being
a Corsair SSD.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 13 13:32:40 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Sep 2012 13:32: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 1TC9Wo-0007mf-Oe; Thu, 13 Sep 2012 13:32:22 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ketuzsezr@gmail.com>) id 1TC9Wn-0007ma-6T
	for xen-devel@lists.xen.org; Thu, 13 Sep 2012 13:32:21 +0000
Received: from [85.158.143.99:23750] by server-3.bemta-4.messagelabs.com id
	F7/29-08232-460E1505; Thu, 13 Sep 2012 13:32:20 +0000
X-Env-Sender: ketuzsezr@gmail.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1347543138!29853247!1
X-Originating-IP: [209.85.216.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20848 invoked from network); 13 Sep 2012 13:32:19 -0000
Received: from mail-qc0-f173.google.com (HELO mail-qc0-f173.google.com)
	(209.85.216.173)
	by server-5.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Sep 2012 13:32:19 -0000
Received: by qcab12 with SMTP id b12so2556747qca.32
	for <xen-devel@lists.xen.org>; Thu, 13 Sep 2012 06:32:18 -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=zF0VzTSazzxUrUPKCnd+jTPrC4Gbe+V21J3pLkil7CI=;
	b=AAq4se4M4X8CWZCzSzWBjmcttkENQx/p2oZ7eV9Bz2Vh0QRJWnhe6cquCS5NlZptyw
	+A1PFr4kzEnN/6X5NStqKst7aPQVK2gI8x+cKctyoDtIrLrR24GKwIfW5a6E1HMKxNmg
	n9daVRj1zqFycqlntC6wAV+39E7wh0O39f1dLjvvzGTtfbh97t4A3l0zNuzT15vO+YRr
	VHpB5kL4IwQpJbxj6K+IMEsRLvITV+g1jsr3bRcdttrQJghwMYB8aK/Qlsi8R0uhWz/Y
	YKfUWC2IVpaK4Jswb72ui/t2MIVJ75rA5YWlrLSbPgQadlsyZv5qVyi51uVs9Rpeya3U
	Bv3Q==
Received: by 10.229.136.84 with SMTP id q20mr1187274qct.80.1347543138270;
	Thu, 13 Sep 2012 06:32:18 -0700 (PDT)
Received: from localhost.localdomain (mfa2436d0.tmodns.net. [208.54.36.250])
	by mx.google.com with ESMTPS id l3sm14050855qan.19.2012.09.13.06.32.16
	(version=TLSv1/SSLv3 cipher=OTHER);
	Thu, 13 Sep 2012 06:32:17 -0700 (PDT)
Date: Thu, 13 Sep 2012 09:32:14 -0400
From: Konrad Rzeszutek Wilk <konrad@kernel.org>
To: Sander Eikelenboom <linux@eikelenboom.it>
Message-ID: <20120913133211.GB17060@localhost.localdomain>
References: <1136369816.20120904183757@eikelenboom.it>
	<20120904163347.GH23361@phenom.dumpdata.com>
	<143844933.20120904191941@eikelenboom.it>
	<CAOvdn6U_yHgtZwv9MWazdLbd3NLq3pwGXnZY5sL2UVBhV_FUoQ@mail.gmail.com>
	<1813712325.20120904213459@eikelenboom.it>
	<048EAD622912254A9DEA24C1734613C18C864C3C5D@FTLPMAILBOX02.citrite.net>
	<20120905140600.GA5844@phenom.dumpdata.com>
	<alpine.DEB.2.02.1209111652590.15568@kaball.uk.xensource.com>
	<1901811929.20120912122848@eikelenboom.it>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1901811929.20120912122848@eikelenboom.it>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: Robert Phillips <robert.phillips@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Ben Guthro <ben@guthro.net>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] dom0 linux 3.6.0-rc4,
 crash due to ballooning althoug dom0_mem=X, max:X 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

> > Sander, could you please let me know if it fixes the problem for you?
> 
> It does !
> 
> Tested-By: Sander Eikelenboom <linux@eikelenboom.it>

Excellent. Applied. Thx for reporting and testing.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 13 13:32:40 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Sep 2012 13:32: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 1TC9Wo-0007mf-Oe; Thu, 13 Sep 2012 13:32:22 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ketuzsezr@gmail.com>) id 1TC9Wn-0007ma-6T
	for xen-devel@lists.xen.org; Thu, 13 Sep 2012 13:32:21 +0000
Received: from [85.158.143.99:23750] by server-3.bemta-4.messagelabs.com id
	F7/29-08232-460E1505; Thu, 13 Sep 2012 13:32:20 +0000
X-Env-Sender: ketuzsezr@gmail.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1347543138!29853247!1
X-Originating-IP: [209.85.216.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20848 invoked from network); 13 Sep 2012 13:32:19 -0000
Received: from mail-qc0-f173.google.com (HELO mail-qc0-f173.google.com)
	(209.85.216.173)
	by server-5.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Sep 2012 13:32:19 -0000
Received: by qcab12 with SMTP id b12so2556747qca.32
	for <xen-devel@lists.xen.org>; Thu, 13 Sep 2012 06:32:18 -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=zF0VzTSazzxUrUPKCnd+jTPrC4Gbe+V21J3pLkil7CI=;
	b=AAq4se4M4X8CWZCzSzWBjmcttkENQx/p2oZ7eV9Bz2Vh0QRJWnhe6cquCS5NlZptyw
	+A1PFr4kzEnN/6X5NStqKst7aPQVK2gI8x+cKctyoDtIrLrR24GKwIfW5a6E1HMKxNmg
	n9daVRj1zqFycqlntC6wAV+39E7wh0O39f1dLjvvzGTtfbh97t4A3l0zNuzT15vO+YRr
	VHpB5kL4IwQpJbxj6K+IMEsRLvITV+g1jsr3bRcdttrQJghwMYB8aK/Qlsi8R0uhWz/Y
	YKfUWC2IVpaK4Jswb72ui/t2MIVJ75rA5YWlrLSbPgQadlsyZv5qVyi51uVs9Rpeya3U
	Bv3Q==
Received: by 10.229.136.84 with SMTP id q20mr1187274qct.80.1347543138270;
	Thu, 13 Sep 2012 06:32:18 -0700 (PDT)
Received: from localhost.localdomain (mfa2436d0.tmodns.net. [208.54.36.250])
	by mx.google.com with ESMTPS id l3sm14050855qan.19.2012.09.13.06.32.16
	(version=TLSv1/SSLv3 cipher=OTHER);
	Thu, 13 Sep 2012 06:32:17 -0700 (PDT)
Date: Thu, 13 Sep 2012 09:32:14 -0400
From: Konrad Rzeszutek Wilk <konrad@kernel.org>
To: Sander Eikelenboom <linux@eikelenboom.it>
Message-ID: <20120913133211.GB17060@localhost.localdomain>
References: <1136369816.20120904183757@eikelenboom.it>
	<20120904163347.GH23361@phenom.dumpdata.com>
	<143844933.20120904191941@eikelenboom.it>
	<CAOvdn6U_yHgtZwv9MWazdLbd3NLq3pwGXnZY5sL2UVBhV_FUoQ@mail.gmail.com>
	<1813712325.20120904213459@eikelenboom.it>
	<048EAD622912254A9DEA24C1734613C18C864C3C5D@FTLPMAILBOX02.citrite.net>
	<20120905140600.GA5844@phenom.dumpdata.com>
	<alpine.DEB.2.02.1209111652590.15568@kaball.uk.xensource.com>
	<1901811929.20120912122848@eikelenboom.it>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1901811929.20120912122848@eikelenboom.it>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: Robert Phillips <robert.phillips@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Ben Guthro <ben@guthro.net>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] dom0 linux 3.6.0-rc4,
 crash due to ballooning althoug dom0_mem=X, max:X 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

> > Sander, could you please let me know if it fixes the problem for you?
> 
> It does !
> 
> Tested-By: Sander Eikelenboom <linux@eikelenboom.it>

Excellent. Applied. Thx for reporting and testing.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 13 13:41:11 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Sep 2012 13:41:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TC9ew-0007x7-R3; Thu, 13 Sep 2012 13:40:46 +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 1TC9ev-0007x2-KW
	for xen-devel@lists.xen.org; Thu, 13 Sep 2012 13:40:45 +0000
Received: from [85.158.143.35:13509] by server-3.bemta-4.messagelabs.com id
	38/69-08232-D52E1505; Thu, 13 Sep 2012 13:40:45 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-2.tower-21.messagelabs.com!1347543642!7127399!1
X-Originating-IP: [63.239.67.9]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11934 invoked from network); 13 Sep 2012 13:40:43 -0000
Received: from emvm-gh1-uea08.nsa.gov (HELO nsa.gov) (63.239.67.9)
	by server-2.tower-21.messagelabs.com with SMTP;
	13 Sep 2012 13:40:43 -0000
X-TM-IMSS-Message-ID: <3e8839720010cb98@nsa.gov>
Received: from tarius.tycho.ncsc.mil ([144.51.3.1]) by nsa.gov ([63.239.67.9])
	with ESMTP (TREND IMSS SMTP Service 7.1) id 3e8839720010cb98 ;
	Thu, 13 Sep 2012 09:40:28 -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 q8DDebdC001605; 
	Thu, 13 Sep 2012 09:40:38 -0400
Message-ID: <5051E255.8020900@tycho.nsa.gov>
Date: Thu, 13 Sep 2012 09:40:37 -0400
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Organization: National Security Agency
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120828 Thunderbird/15.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <1347465586-20009-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1347465586-20009-10-git-send-email-dgdegra@tycho.nsa.gov>
	<5051AB66020000780009AFAC@nat28.tlf.novell.com>
In-Reply-To: <5051AB66020000780009AFAC@nat28.tlf.novell.com>
Cc: Keir Fraser <keir@xen.org>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 09/22] xsm: Use the dummy XSM module if XSM
	is disabled
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 09/13/2012 03:46 AM, Jan Beulich wrote:
>>>> On 12.09.12 at 17:59, Daniel De Graaf <dgdegra@tycho.nsa.gov> wrote:
>> This patch moves the implementation of the dummy XSM module to a header
>> file that provides inline functions when XSM_ENABLE is not defined. This
>> reduces duplication between the dummy module and callers when the
>> implementation of the dummy return is not just "return 0", and also
>> provides better compile-time checking for completeness of the XSM
>> implementations in the dummy module.
> 
> This looks good to me, with one minor comment:
> 
>> --- a/xen/xsm/xsm_core.c
>> +++ b/xen/xsm/xsm_core.c
>> @@ -113,7 +113,7 @@ int unregister_xsm(struct xsm_operations *ops)
>>  
>>  long do_xsm_op (XEN_GUEST_HANDLE(xsm_op_t) op)
>>  {
>> -    return __do_xsm_op(op);
>> +    return xsm___do_xsm_op(op);
> 
> The three immediately successive underscores look really odd
> now - any reason a single one doesn't do?
> 
> Jan

No reason other than not renaming the __do_xsm_op field that this calls.
That also doesn't have a good reason to need underscores, so I'll rename
it instead.

-- 
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 Sep 13 13:41:11 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Sep 2012 13:41:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TC9ew-0007x7-R3; Thu, 13 Sep 2012 13:40:46 +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 1TC9ev-0007x2-KW
	for xen-devel@lists.xen.org; Thu, 13 Sep 2012 13:40:45 +0000
Received: from [85.158.143.35:13509] by server-3.bemta-4.messagelabs.com id
	38/69-08232-D52E1505; Thu, 13 Sep 2012 13:40:45 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-2.tower-21.messagelabs.com!1347543642!7127399!1
X-Originating-IP: [63.239.67.9]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11934 invoked from network); 13 Sep 2012 13:40:43 -0000
Received: from emvm-gh1-uea08.nsa.gov (HELO nsa.gov) (63.239.67.9)
	by server-2.tower-21.messagelabs.com with SMTP;
	13 Sep 2012 13:40:43 -0000
X-TM-IMSS-Message-ID: <3e8839720010cb98@nsa.gov>
Received: from tarius.tycho.ncsc.mil ([144.51.3.1]) by nsa.gov ([63.239.67.9])
	with ESMTP (TREND IMSS SMTP Service 7.1) id 3e8839720010cb98 ;
	Thu, 13 Sep 2012 09:40:28 -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 q8DDebdC001605; 
	Thu, 13 Sep 2012 09:40:38 -0400
Message-ID: <5051E255.8020900@tycho.nsa.gov>
Date: Thu, 13 Sep 2012 09:40:37 -0400
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Organization: National Security Agency
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120828 Thunderbird/15.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <1347465586-20009-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1347465586-20009-10-git-send-email-dgdegra@tycho.nsa.gov>
	<5051AB66020000780009AFAC@nat28.tlf.novell.com>
In-Reply-To: <5051AB66020000780009AFAC@nat28.tlf.novell.com>
Cc: Keir Fraser <keir@xen.org>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 09/22] xsm: Use the dummy XSM module if XSM
	is disabled
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 09/13/2012 03:46 AM, Jan Beulich wrote:
>>>> On 12.09.12 at 17:59, Daniel De Graaf <dgdegra@tycho.nsa.gov> wrote:
>> This patch moves the implementation of the dummy XSM module to a header
>> file that provides inline functions when XSM_ENABLE is not defined. This
>> reduces duplication between the dummy module and callers when the
>> implementation of the dummy return is not just "return 0", and also
>> provides better compile-time checking for completeness of the XSM
>> implementations in the dummy module.
> 
> This looks good to me, with one minor comment:
> 
>> --- a/xen/xsm/xsm_core.c
>> +++ b/xen/xsm/xsm_core.c
>> @@ -113,7 +113,7 @@ int unregister_xsm(struct xsm_operations *ops)
>>  
>>  long do_xsm_op (XEN_GUEST_HANDLE(xsm_op_t) op)
>>  {
>> -    return __do_xsm_op(op);
>> +    return xsm___do_xsm_op(op);
> 
> The three immediately successive underscores look really odd
> now - any reason a single one doesn't do?
> 
> Jan

No reason other than not renaming the __do_xsm_op field that this calls.
That also doesn't have a good reason to need underscores, so I'll rename
it instead.

-- 
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 Sep 13 13:42:30 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Sep 2012 13: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 1TC9gM-00081Y-97; Thu, 13 Sep 2012 13:42:14 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <robert.phillips@citrix.com>) id 1TC9gL-00081O-AX
	for xen-devel@lists.xen.org; Thu, 13 Sep 2012 13:42:13 +0000
Received: from [85.158.139.83:57040] by server-6.bemta-5.messagelabs.com id
	42/09-21336-4B2E1505; Thu, 13 Sep 2012 13:42:12 +0000
X-Env-Sender: robert.phillips@citrix.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1347543729!29668093!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNjkyOTk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18827 invoked from network); 13 Sep 2012 13:42:11 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-9.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Sep 2012 13:42:11 -0000
X-IronPort-AV: E=Sophos;i="4.80,417,1344211200"; d="scan'208";a="37745850"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Sep 2012 13:42:07 +0000
Received: from FTLPMAILBOX02.citrite.net ([10.13.98.210]) by
	FTLPMAILMX01.citrite.net ([10.13.107.65]) with mapi; Thu, 13 Sep 2012
	09:42:06 -0400
From: Robert Phillips <robert.phillips@citrix.com>
To: Konrad Rzeszutek Wilk <konrad@kernel.org>, Sander Eikelenboom
	<linux@eikelenboom.it>
Date: Thu, 13 Sep 2012 09:42:05 -0400
Thread-Topic: [Xen-devel] dom0 linux 3.6.0-rc4, crash due to ballooning
	althoug dom0_mem=X, max:X set
Thread-Index: Ac2RtDJqV1DAtas6RQSWHqdmAKuKCwAAQ1TA
Message-ID: <048EAD622912254A9DEA24C1734613C18C864C448B@FTLPMAILBOX02.citrite.net>
References: <1136369816.20120904183757@eikelenboom.it>
	<20120904163347.GH23361@phenom.dumpdata.com>
	<143844933.20120904191941@eikelenboom.it>
	<CAOvdn6U_yHgtZwv9MWazdLbd3NLq3pwGXnZY5sL2UVBhV_FUoQ@mail.gmail.com>
	<1813712325.20120904213459@eikelenboom.it>
	<048EAD622912254A9DEA24C1734613C18C864C3C5D@FTLPMAILBOX02.citrite.net>
	<20120905140600.GA5844@phenom.dumpdata.com>
	<alpine.DEB.2.02.1209111652590.15568@kaball.uk.xensource.com>
	<1901811929.20120912122848@eikelenboom.it>
	<20120913133211.GB17060@localhost.localdomain>
In-Reply-To: <20120913133211.GB17060@localhost.localdomain>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Ben Guthro <ben@guthro.net>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] dom0 linux 3.6.0-rc4,
 crash due to ballooning althoug dom0_mem=X, max:X 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

In our tree, I have tested Stefano's patch (replacing the "gnttab_old_mfn" patch which Ben previously provided).
It seems to work just fine.
Thanks, Stefano.

-- rsp

-----Original Message-----
From: Konrad Rzeszutek [mailto:ketuzsezr@gmail.com] On Behalf Of Konrad Rzeszutek Wilk
Sent: Thursday, September 13, 2012 9:32 AM
To: Sander Eikelenboom
Cc: Stefano Stabellini; Robert Phillips; xen-devel@lists.xen.org; Ben Guthro; Konrad Rzeszutek Wilk
Subject: Re: [Xen-devel] dom0 linux 3.6.0-rc4, crash due to ballooning althoug dom0_mem=X, max:X set

> > Sander, could you please let me know if it fixes the problem for you?
> 
> It does !
> 
> Tested-By: Sander Eikelenboom <linux@eikelenboom.it>

Excellent. Applied. Thx for reporting and testing.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 13 13:42:30 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Sep 2012 13: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 1TC9gM-00081Y-97; Thu, 13 Sep 2012 13:42:14 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <robert.phillips@citrix.com>) id 1TC9gL-00081O-AX
	for xen-devel@lists.xen.org; Thu, 13 Sep 2012 13:42:13 +0000
Received: from [85.158.139.83:57040] by server-6.bemta-5.messagelabs.com id
	42/09-21336-4B2E1505; Thu, 13 Sep 2012 13:42:12 +0000
X-Env-Sender: robert.phillips@citrix.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1347543729!29668093!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNjkyOTk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18827 invoked from network); 13 Sep 2012 13:42:11 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-9.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Sep 2012 13:42:11 -0000
X-IronPort-AV: E=Sophos;i="4.80,417,1344211200"; d="scan'208";a="37745850"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Sep 2012 13:42:07 +0000
Received: from FTLPMAILBOX02.citrite.net ([10.13.98.210]) by
	FTLPMAILMX01.citrite.net ([10.13.107.65]) with mapi; Thu, 13 Sep 2012
	09:42:06 -0400
From: Robert Phillips <robert.phillips@citrix.com>
To: Konrad Rzeszutek Wilk <konrad@kernel.org>, Sander Eikelenboom
	<linux@eikelenboom.it>
Date: Thu, 13 Sep 2012 09:42:05 -0400
Thread-Topic: [Xen-devel] dom0 linux 3.6.0-rc4, crash due to ballooning
	althoug dom0_mem=X, max:X set
Thread-Index: Ac2RtDJqV1DAtas6RQSWHqdmAKuKCwAAQ1TA
Message-ID: <048EAD622912254A9DEA24C1734613C18C864C448B@FTLPMAILBOX02.citrite.net>
References: <1136369816.20120904183757@eikelenboom.it>
	<20120904163347.GH23361@phenom.dumpdata.com>
	<143844933.20120904191941@eikelenboom.it>
	<CAOvdn6U_yHgtZwv9MWazdLbd3NLq3pwGXnZY5sL2UVBhV_FUoQ@mail.gmail.com>
	<1813712325.20120904213459@eikelenboom.it>
	<048EAD622912254A9DEA24C1734613C18C864C3C5D@FTLPMAILBOX02.citrite.net>
	<20120905140600.GA5844@phenom.dumpdata.com>
	<alpine.DEB.2.02.1209111652590.15568@kaball.uk.xensource.com>
	<1901811929.20120912122848@eikelenboom.it>
	<20120913133211.GB17060@localhost.localdomain>
In-Reply-To: <20120913133211.GB17060@localhost.localdomain>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Ben Guthro <ben@guthro.net>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] dom0 linux 3.6.0-rc4,
 crash due to ballooning althoug dom0_mem=X, max:X 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

In our tree, I have tested Stefano's patch (replacing the "gnttab_old_mfn" patch which Ben previously provided).
It seems to work just fine.
Thanks, Stefano.

-- rsp

-----Original Message-----
From: Konrad Rzeszutek [mailto:ketuzsezr@gmail.com] On Behalf Of Konrad Rzeszutek Wilk
Sent: Thursday, September 13, 2012 9:32 AM
To: Sander Eikelenboom
Cc: Stefano Stabellini; Robert Phillips; xen-devel@lists.xen.org; Ben Guthro; Konrad Rzeszutek Wilk
Subject: Re: [Xen-devel] dom0 linux 3.6.0-rc4, crash due to ballooning althoug dom0_mem=X, max:X set

> > Sander, could you please let me know if it fixes the problem for you?
> 
> It does !
> 
> Tested-By: Sander Eikelenboom <linux@eikelenboom.it>

Excellent. Applied. Thx for reporting and testing.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 13 13:46:46 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Sep 2012 13: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 1TC9kU-0008DM-VB; Thu, 13 Sep 2012 13:46:30 +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 1TC9kT-0008DH-Ow
	for xen-devel@lists.xen.org; Thu, 13 Sep 2012 13:46:29 +0000
Received: from [85.158.143.35:43421] by server-1.bemta-4.messagelabs.com id
	E1/F4-12504-5B3E1505; Thu, 13 Sep 2012 13:46:29 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-9.tower-21.messagelabs.com!1347543987!7076567!1
X-Originating-IP: [63.239.67.9]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6325 invoked from network); 13 Sep 2012 13:46:27 -0000
Received: from emvm-gh1-uea08.nsa.gov (HELO nsa.gov) (63.239.67.9)
	by server-9.tower-21.messagelabs.com with SMTP;
	13 Sep 2012 13:46:27 -0000
X-TM-IMSS-Message-ID: <3e8d78370010ccc7@nsa.gov>
Received: from tarius.tycho.ncsc.mil ([144.51.3.1]) by nsa.gov ([63.239.67.9])
	with ESMTP (TREND IMSS SMTP Service 7.1) id 3e8d78370010ccc7 ;
	Thu, 13 Sep 2012 09:46:12 -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 q8DDkKO6001854; 
	Thu, 13 Sep 2012 09:46:21 -0400
Message-ID: <5051E3AC.2060700@tycho.nsa.gov>
Date: Thu, 13 Sep 2012 09:46:20 -0400
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Organization: National Security Agency
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120828 Thunderbird/15.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <1347465586-20009-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1347465586-20009-20-git-send-email-dgdegra@tycho.nsa.gov>
	<5051AED7020000780009AFC3@nat28.tlf.novell.com>
In-Reply-To: <5051AED7020000780009AFC3@nat28.tlf.novell.com>
Cc: Tim Deegan <tim@xen.org>, Keir Fraser <keir@xen.org>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 19/22] arch/x86: check remote MMIO remap
	permissions
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 09/13/2012 04:00 AM, Jan Beulich wrote:
>>>> On 12.09.12 at 17:59, Daniel De Graaf <dgdegra@tycho.nsa.gov> wrote:
>> When a domain is mapping pages from a different pg_owner domain, the
>> iomem_access checks are currently only applied to the pg_owner domain,
>> potentially allowing the current domain to bypass its more restrictive
>> iomem_access policy using another domain that it has access to.
> 
> Are you sure about this? I ask because ...
> 
>> --- a/xen/arch/x86/mm.c
>> +++ b/xen/arch/x86/mm.c
>> @@ -754,6 +754,18 @@ get_page_from_l1e(
>>              return -EINVAL;
>>          }
>>  
>> +        if ( pg_owner != curr->domain &&
>> +             !iomem_access_permitted(curr->domain, mfn, mfn) )
>> +        {
>> +            if ( mfn != (PADDR_MASK >> PAGE_SHIFT) ) /* INVALID_MFN? */
>> +            {
>> +                MEM_LOG("Domain %u attempted to map I/O space %08lx in domain %u",
>> +                        curr->domain->domain_id, mfn, pg_owner->domain_id);
>> +                return -EPERM;
>> +            }
>> +            return -EINVAL;
>> +        }
>> +
> 
> ... the place you insert this is after non-RAM pages got filtered
> out already, so you're applying an IOMEM permission check to a
> RAM page.
> 
> Jan
> 
>>          if ( !(l1f & _PAGE_RW) ||
>>               !rangeset_contains_singleton(mmio_ro_ranges, mfn) )
>>              return 0;

If that's true, then the check a few lines above is also applying IOMEM
checks to RAM pages. I can see non-privileged attempts being filtered
above, but successful mappings will continue to the check I added.

-- 
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 Sep 13 13:46:46 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Sep 2012 13: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 1TC9kU-0008DM-VB; Thu, 13 Sep 2012 13:46:30 +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 1TC9kT-0008DH-Ow
	for xen-devel@lists.xen.org; Thu, 13 Sep 2012 13:46:29 +0000
Received: from [85.158.143.35:43421] by server-1.bemta-4.messagelabs.com id
	E1/F4-12504-5B3E1505; Thu, 13 Sep 2012 13:46:29 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-9.tower-21.messagelabs.com!1347543987!7076567!1
X-Originating-IP: [63.239.67.9]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6325 invoked from network); 13 Sep 2012 13:46:27 -0000
Received: from emvm-gh1-uea08.nsa.gov (HELO nsa.gov) (63.239.67.9)
	by server-9.tower-21.messagelabs.com with SMTP;
	13 Sep 2012 13:46:27 -0000
X-TM-IMSS-Message-ID: <3e8d78370010ccc7@nsa.gov>
Received: from tarius.tycho.ncsc.mil ([144.51.3.1]) by nsa.gov ([63.239.67.9])
	with ESMTP (TREND IMSS SMTP Service 7.1) id 3e8d78370010ccc7 ;
	Thu, 13 Sep 2012 09:46:12 -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 q8DDkKO6001854; 
	Thu, 13 Sep 2012 09:46:21 -0400
Message-ID: <5051E3AC.2060700@tycho.nsa.gov>
Date: Thu, 13 Sep 2012 09:46:20 -0400
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Organization: National Security Agency
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120828 Thunderbird/15.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <1347465586-20009-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1347465586-20009-20-git-send-email-dgdegra@tycho.nsa.gov>
	<5051AED7020000780009AFC3@nat28.tlf.novell.com>
In-Reply-To: <5051AED7020000780009AFC3@nat28.tlf.novell.com>
Cc: Tim Deegan <tim@xen.org>, Keir Fraser <keir@xen.org>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 19/22] arch/x86: check remote MMIO remap
	permissions
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 09/13/2012 04:00 AM, Jan Beulich wrote:
>>>> On 12.09.12 at 17:59, Daniel De Graaf <dgdegra@tycho.nsa.gov> wrote:
>> When a domain is mapping pages from a different pg_owner domain, the
>> iomem_access checks are currently only applied to the pg_owner domain,
>> potentially allowing the current domain to bypass its more restrictive
>> iomem_access policy using another domain that it has access to.
> 
> Are you sure about this? I ask because ...
> 
>> --- a/xen/arch/x86/mm.c
>> +++ b/xen/arch/x86/mm.c
>> @@ -754,6 +754,18 @@ get_page_from_l1e(
>>              return -EINVAL;
>>          }
>>  
>> +        if ( pg_owner != curr->domain &&
>> +             !iomem_access_permitted(curr->domain, mfn, mfn) )
>> +        {
>> +            if ( mfn != (PADDR_MASK >> PAGE_SHIFT) ) /* INVALID_MFN? */
>> +            {
>> +                MEM_LOG("Domain %u attempted to map I/O space %08lx in domain %u",
>> +                        curr->domain->domain_id, mfn, pg_owner->domain_id);
>> +                return -EPERM;
>> +            }
>> +            return -EINVAL;
>> +        }
>> +
> 
> ... the place you insert this is after non-RAM pages got filtered
> out already, so you're applying an IOMEM permission check to a
> RAM page.
> 
> Jan
> 
>>          if ( !(l1f & _PAGE_RW) ||
>>               !rangeset_contains_singleton(mmio_ro_ranges, mfn) )
>>              return 0;

If that's true, then the check a few lines above is also applying IOMEM
checks to RAM pages. I can see non-privileged attempts being filtered
above, but successful mappings will continue to the check I added.

-- 
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 Sep 13 13:50:09 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Sep 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 1TC9no-0008M8-JD; Thu, 13 Sep 2012 13:49:56 +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 1TC9nn-0008Ly-0E
	for xen-devel@lists.xen.org; Thu, 13 Sep 2012 13:49:55 +0000
Received: from [85.158.143.99:31788] by server-2.bemta-4.messagelabs.com id
	04/81-21239-284E1505; Thu, 13 Sep 2012 13:49:54 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1347544191!22067917!1
X-Originating-IP: [216.32.180.184]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25558 invoked from network); 13 Sep 2012 13:49:53 -0000
Received: from co1ehsobe001.messaging.microsoft.com (HELO
	co1outboundpool.messaging.microsoft.com) (216.32.180.184)
	by server-12.tower-216.messagelabs.com with AES128-SHA encrypted SMTP;
	13 Sep 2012 13:49:53 -0000
Received: from mail174-co1-R.bigfish.com (10.243.78.231) by
	CO1EHSOBE016.bigfish.com (10.243.66.79) with Microsoft SMTP Server id
	14.1.225.23; Thu, 13 Sep 2012 13:49:51 +0000
Received: from mail174-co1 (localhost [127.0.0.1])	by
	mail174-co1-R.bigfish.com (Postfix) with ESMTP id E7A22100172;
	Thu, 13 Sep 2012 13:49:50 +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(zzbb2dI98dI9371I936eI1432I4015Id6f1izz1202h1d1ah1d2ahzz8275bhz2dh668h839hd25he5bhf0ah107ah1288h12a5h12bdh1155h)
Received: from mail174-co1 (localhost.localdomain [127.0.0.1]) by mail174-co1
	(MessageSwitch) id 1347544189614386_19691;
	Thu, 13 Sep 2012 13:49:49 +0000 (UTC)
Received: from CO1EHSMHS031.bigfish.com (unknown [10.243.78.228])	by
	mail174-co1.bigfish.com (Postfix) with ESMTP id 9426A5C00F3;
	Thu, 13 Sep 2012 13:49:49 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	CO1EHSMHS031.bigfish.com (10.243.66.41) with Microsoft SMTP Server id
	14.1.225.23; Thu, 13 Sep 2012 13:49:47 +0000
X-WSS-ID: 0MAAJQS-02-7BL-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 2C2BCC80D2;	Thu, 13 Sep 2012 08:49:39 -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, 13 Sep 2012 09:03:33 -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, 13 Sep 2012 08:49:43 -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, 13 Sep 2012
	09:49:41 -0400
Received: from [165.204.15.57] (gran.osrc.amd.com [165.204.15.57])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id 2798B49C121; Thu, 13 Sep 2012
	14:49:41 +0100 (BST)
Message-ID: <5051E4D1.1060207@amd.com>
Date: Thu, 13 Sep 2012 15:51:13 +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: <504F4C24020000780009A968@nat28.tlf.novell.com>
	<50508466.20309@amd.com>
	<5051A24A020000780009AF77@nat28.tlf.novell.com>
In-Reply-To: <5051A24A020000780009AF77@nat28.tlf.novell.com>
X-OriginatorOrg: amd.com
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 2/3] amd iommu: use base platform MSI
	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-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This version works well. Acked.
Thanks,
Wei

On 09/13/2012 09:07 AM, Jan Beulich wrote:
>>>> On 12.09.12 at 14:47, Wei Wang<wei.wang2@amd.com>  wrote:
>> I found this patch triggered a xen BUG
>
> Indeed - my default builds don't use high enough a CPU count to
> see this. I'm sorry for that. Below a drop-in replacement for the
> patch (it would unlikely apply cleanly to the tip of staging unstable
> due to Keir's cleanup after the removal of x86-32 support.
>
> Jan
>
> --- 2012-09-11.orig/xen/arch/x86/msi.c	2012-09-13 08:40:47.000000000 +0200
> +++ 2012-09-11/xen/arch/x86/msi.c	2012-09-13 08:43:21.000000000 +0200
> @@ -13,6 +13,7 @@
>   #include<xen/delay.h>
>   #include<xen/sched.h>
>   #include<xen/acpi.h>
> +#include<xen/cpu.h>
>   #include<xen/errno.h>
>   #include<xen/pci.h>
>   #include<xen/pci_regs.h>
> @@ -32,8 +33,9 @@
>   #include<xsm/xsm.h>
>
>   /* bitmap indicate which fixed map is free */
> -DEFINE_SPINLOCK(msix_fixmap_lock);
> -DECLARE_BITMAP(msix_fixmap_pages, FIX_MSIX_MAX_PAGES);
> +static DEFINE_SPINLOCK(msix_fixmap_lock);
> +static DECLARE_BITMAP(msix_fixmap_pages, FIX_MSIX_MAX_PAGES);
> +static DEFINE_PER_CPU(cpumask_var_t, scratch_mask);
>
>   static int msix_fixmap_alloc(void)
>   {
> @@ -126,13 +128,17 @@ void msi_compose_msg(struct irq_desc *de
>       unsigned dest;
>       int vector = desc->arch.vector;
>
> -    if ( cpumask_empty(desc->arch.cpu_mask) ) {
> +    memset(msg, 0, sizeof(*msg));
> +    if ( !cpumask_intersects(desc->arch.cpu_mask,&cpu_online_map) ) {
>           dprintk(XENLOG_ERR,"%s, compose msi message error!!\n", __func__);
>           return;
>       }
>
>       if ( vector ) {
> -        dest = cpu_mask_to_apicid(desc->arch.cpu_mask);
> +        cpumask_t *mask = this_cpu(scratch_mask);
> +
> +        cpumask_and(mask, desc->arch.cpu_mask,&cpu_online_map);
> +        dest = cpu_mask_to_apicid(mask);
>
>           msg->address_hi = MSI_ADDR_BASE_HI;
>           msg->address_lo =
> @@ -281,23 +287,27 @@ static void set_msi_affinity(struct irq_
>       write_msi_msg(msi_desc,&msg);
>   }
>
> +void __msi_set_enable(u16 seg, u8 bus, u8 slot, u8 func, int pos, int enable)
> +{
> +    u16 control = pci_conf_read16(seg, bus, slot, func, pos + PCI_MSI_FLAGS);
> +
> +    control&= ~PCI_MSI_FLAGS_ENABLE;
> +    if ( enable )
> +        control |= PCI_MSI_FLAGS_ENABLE;
> +    pci_conf_write16(seg, bus, slot, func, pos + PCI_MSI_FLAGS, control);
> +}
> +
>   static void msi_set_enable(struct pci_dev *dev, int enable)
>   {
>       int pos;
> -    u16 control, seg = dev->seg;
> +    u16 seg = dev->seg;
>       u8 bus = dev->bus;
>       u8 slot = PCI_SLOT(dev->devfn);
>       u8 func = PCI_FUNC(dev->devfn);
>
>       pos = pci_find_cap_offset(seg, bus, slot, func, PCI_CAP_ID_MSI);
>       if ( pos )
> -    {
> -        control = pci_conf_read16(seg, bus, slot, func, pos + PCI_MSI_FLAGS);
> -        control&= ~PCI_MSI_FLAGS_ENABLE;
> -        if ( enable )
> -            control |= PCI_MSI_FLAGS_ENABLE;
> -        pci_conf_write16(seg, bus, slot, func, pos + PCI_MSI_FLAGS, control);
> -    }
> +        __msi_set_enable(seg, bus, slot, func, pos, enable);
>   }
>
>   static void msix_set_enable(struct pci_dev *dev, int enable)
> @@ -379,12 +389,12 @@ static int msi_get_mask_bit(const struct
>       return -1;
>   }
>
> -static void mask_msi_irq(struct irq_desc *desc)
> +void mask_msi_irq(struct irq_desc *desc)
>   {
>       msi_set_mask_bit(desc, 1);
>   }
>
> -static void unmask_msi_irq(struct irq_desc *desc)
> +void unmask_msi_irq(struct irq_desc *desc)
>   {
>       msi_set_mask_bit(desc, 0);
>   }
> @@ -395,7 +405,7 @@ static unsigned int startup_msi_irq(stru
>       return 0;
>   }
>
> -static void ack_nonmaskable_msi_irq(struct irq_desc *desc)
> +void ack_nonmaskable_msi_irq(struct irq_desc *desc)
>   {
>       irq_complete_move(desc);
>       move_native_irq(desc);
> @@ -407,7 +417,7 @@ static void ack_maskable_msi_irq(struct
>       ack_APIC_irq(); /* ACKTYPE_NONE */
>   }
>
> -static void end_nonmaskable_msi_irq(struct irq_desc *desc, u8 vector)
> +void end_nonmaskable_msi_irq(struct irq_desc *desc, u8 vector)
>   {
>       ack_APIC_irq(); /* ACKTYPE_EOI */
>   }
> @@ -1071,6 +1081,39 @@ unsigned int pci_msix_get_table_len(stru
>       return len;
>   }
>
> +static int msi_cpu_callback(
> +    struct notifier_block *nfb, unsigned long action, void *hcpu)
> +{
> +    unsigned int cpu = (unsigned long)hcpu;
> +    int rc = 0;
> +
> +    switch ( action )
> +    {
> +    case CPU_UP_PREPARE:
> +        if ( !alloc_cpumask_var(&per_cpu(scratch_mask, cpu)) )
> +            rc = -ENOMEM;
> +        break;
> +    case CPU_UP_CANCELED:
> +    case CPU_DEAD:
> +        free_cpumask_var(per_cpu(scratch_mask, cpu));
> +        break;
> +    default:
> +        break;
> +    }
> +
> +    return notifier_from_errno(rc);
> +}
> +
> +static struct notifier_block msi_cpu_nfb = {
> +    .notifier_call = msi_cpu_callback
> +};
> +
> +void __init early_msi_init(void)
> +{
> +    register_cpu_notifier(&msi_cpu_nfb);
> +    msi_cpu_callback(&msi_cpu_nfb, CPU_UP_PREPARE, NULL);
> +}
> +
>   static void dump_msi(unsigned char key)
>   {
>       unsigned int irq;
> --- 2012-09-11.orig/xen/arch/x86/setup.c	2012-09-03 08:25:31.000000000 +0200
> +++ 2012-09-11/xen/arch/x86/setup.c	2012-09-13 08:44:49.000000000 +0200
> @@ -35,6 +35,7 @@
>   #include<asm/processor.h>
>   #include<asm/mpspec.h>
>   #include<asm/apic.h>
> +#include<asm/msi.h>
>   #include<asm/desc.h>
>   #include<asm/paging.h>
>   #include<asm/e820.h>
> @@ -1274,6 +1275,8 @@ void __init __start_xen(unsigned long mb
>       acpi_mmcfg_init();
>   #endif
>
> +    early_msi_init();
> +
>       iommu_setup();    /* setup iommu if available */
>
>       smp_prepare_cpus(max_cpus);
> --- 2012-09-11.orig/xen/drivers/passthrough/amd/iommu_detect.c	2012-09-13 08:40:47.000000000 +0200
> +++ 2012-09-11/xen/drivers/passthrough/amd/iommu_detect.c	2012-06-20 17:33:15.000000000 +0200
> @@ -31,7 +31,6 @@ static int __init get_iommu_msi_capabili
>       u16 seg, u8 bus, u8 dev, u8 func, struct amd_iommu *iommu)
>   {
>       int pos;
> -    u16 control;
>
>       pos = pci_find_cap_offset(seg, bus, dev, func, PCI_CAP_ID_MSI);
>
> @@ -41,9 +40,6 @@ static int __init get_iommu_msi_capabili
>       AMD_IOMMU_DEBUG("Found MSI capability block at %#x\n", pos);
>
>       iommu->msi_cap = pos;
> -    control = pci_conf_read16(seg, bus, dev, func,
> -                              iommu->msi_cap + PCI_MSI_FLAGS);
> -    iommu->maskbit = control&  PCI_MSI_FLAGS_MASKBIT;
>       return 0;
>   }
>
> --- 2012-09-11.orig/xen/drivers/passthrough/amd/iommu_init.c	2012-06-13 08:39:38.000000000 +0200
> +++ 2012-09-11/xen/drivers/passthrough/amd/iommu_init.c	2012-09-11 11:26:28.000000000 +0200
> @@ -467,20 +467,9 @@ static void iommu_msi_set_affinity(struc
>           return;
>       }
>
> -    memset(&msg, 0, sizeof(msg));
> -    msg.data = MSI_DATA_VECTOR(desc->arch.vector)&  0xff;
> -    msg.data |= 1<<  14;
> -    msg.data |= (INT_DELIVERY_MODE != dest_LowestPrio) ?
> -        MSI_DATA_DELIVERY_FIXED:
> -        MSI_DATA_DELIVERY_LOWPRI;
> -
> -    msg.address_hi =0;
> -    msg.address_lo = (MSI_ADDRESS_HEADER<<  (MSI_ADDRESS_HEADER_SHIFT + 8));
> -    msg.address_lo |= INT_DEST_MODE ? MSI_ADDR_DESTMODE_LOGIC:
> -                    MSI_ADDR_DESTMODE_PHYS;
> -    msg.address_lo |= (INT_DELIVERY_MODE != dest_LowestPrio) ?
> -                    MSI_ADDR_REDIRECTION_CPU:
> -                    MSI_ADDR_REDIRECTION_LOWPRI;
> +    msi_compose_msg(desc,&msg);
> +    /* Is this override really needed? */
> +    msg.address_lo&= ~MSI_ADDR_DEST_ID_MASK;
>       msg.address_lo |= MSI_ADDR_DEST_ID(dest&  0xff);
>
>       pci_conf_write32(seg, bus, dev, func,
> @@ -494,18 +483,8 @@ static void iommu_msi_set_affinity(struc
>
>   static void amd_iommu_msi_enable(struct amd_iommu *iommu, int flag)
>   {
> -    u16 control;
> -    int bus = PCI_BUS(iommu->bdf);
> -    int dev = PCI_SLOT(iommu->bdf);
> -    int func = PCI_FUNC(iommu->bdf);
> -
> -    control = pci_conf_read16(iommu->seg, bus, dev, func,
> -        iommu->msi_cap + PCI_MSI_FLAGS);
> -    control&= ~PCI_MSI_FLAGS_ENABLE;
> -    if ( flag )
> -        control |= flag;
> -    pci_conf_write16(iommu->seg, bus, dev, func,
> -        iommu->msi_cap + PCI_MSI_FLAGS, control);
> +    __msi_set_enable(iommu->seg, PCI_BUS(iommu->bdf), PCI_SLOT(iommu->bdf),
> +                     PCI_FUNC(iommu->bdf), iommu->msi_cap, flag);
>   }
>
>   static void iommu_msi_unmask(struct irq_desc *desc)
> @@ -513,10 +492,6 @@ static void iommu_msi_unmask(struct irq_
>       unsigned long flags;
>       struct amd_iommu *iommu = desc->action->dev_id;
>
> -    /* FIXME: do not support mask bits at the moment */
> -    if ( iommu->maskbit )
> -        return;
> -
>       spin_lock_irqsave(&iommu->lock, flags);
>       amd_iommu_msi_enable(iommu, IOMMU_CONTROL_ENABLED);
>       spin_unlock_irqrestore(&iommu->lock, flags);
> @@ -529,10 +504,6 @@ static void iommu_msi_mask(struct irq_de
>
>       irq_complete_move(desc);
>
> -    /* FIXME: do not support mask bits at the moment */
> -    if ( iommu->maskbit )
> -        return;
> -
>       spin_lock_irqsave(&iommu->lock, flags);
>       amd_iommu_msi_enable(iommu, IOMMU_CONTROL_DISABLED);
>       spin_unlock_irqrestore(&iommu->lock, flags);
> @@ -562,6 +533,37 @@ static hw_irq_controller iommu_msi_type
>       .set_affinity = iommu_msi_set_affinity,
>   };
>
> +static unsigned int iommu_maskable_msi_startup(struct irq_desc *desc)
> +{
> +    iommu_msi_unmask(desc);
> +    unmask_msi_irq(desc);
> +    return 0;
> +}
> +
> +static void iommu_maskable_msi_shutdown(struct irq_desc *desc)
> +{
> +    mask_msi_irq(desc);
> +    iommu_msi_mask(desc);
> +}
> +
> +/*
> + * While the names may appear mismatched, we indeed want to use the non-
> + * maskable flavors here, as we want the ACK to be issued in ->end().
> + */
> +#define iommu_maskable_msi_ack ack_nonmaskable_msi_irq
> +#define iommu_maskable_msi_end end_nonmaskable_msi_irq
> +
> +static hw_irq_controller iommu_maskable_msi_type = {
> +    .typename = "IOMMU-M-MSI",
> +    .startup = iommu_maskable_msi_startup,
> +    .shutdown = iommu_maskable_msi_shutdown,
> +    .enable = unmask_msi_irq,
> +    .disable = mask_msi_irq,
> +    .ack = iommu_maskable_msi_ack,
> +    .end = iommu_maskable_msi_end,
> +    .set_affinity = iommu_msi_set_affinity,
> +};
> +
>   static void parse_event_log_entry(struct amd_iommu *iommu, u32 entry[])
>   {
>       u16 domain_id, device_id, bdf, cword, flags;
> @@ -784,6 +786,7 @@ static void iommu_interrupt_handler(int
>   static int __init set_iommu_interrupt_handler(struct amd_iommu *iommu)
>   {
>       int irq, ret;
> +    u16 control;
>
>       irq = create_irq(NUMA_NO_NODE);
>       if ( irq<= 0 )
> @@ -792,7 +795,11 @@ static int __init set_iommu_interrupt_ha
>           return 0;
>       }
>
> -    irq_desc[irq].handler =&iommu_msi_type;
> +    control = pci_conf_read16(iommu->seg, PCI_BUS(iommu->bdf),
> +                              PCI_SLOT(iommu->bdf), PCI_FUNC(iommu->bdf),
> +                              iommu->msi_cap + PCI_MSI_FLAGS);
> +    irq_desc[irq].handler = control&  PCI_MSI_FLAGS_MASKBIT ?
> +&iommu_maskable_msi_type :&iommu_msi_type;
>       ret = request_irq(irq, iommu_interrupt_handler, 0, "amd_iommu", iommu);
>       if ( ret )
>       {
> --- 2012-09-11.orig/xen/include/asm-x86/amd-iommu.h	2012-09-13 08:40:47.000000000 +0200
> +++ 2012-09-11/xen/include/asm-x86/amd-iommu.h	2012-06-13 10:23:45.000000000 +0200
> @@ -83,6 +83,7 @@ struct amd_iommu {
>       u16 seg;
>       u16 bdf;
>       u16 cap_offset;
> +    u8 msi_cap;
>       iommu_cap_t cap;
>
>       u8 ht_flags;
> @@ -101,9 +102,6 @@ struct amd_iommu {
>       uint64_t exclusion_base;
>       uint64_t exclusion_limit;
>
> -    int msi_cap;
> -    int maskbit;
> -
>       int enabled;
>       int irq;
>   };
> --- 2012-09-11.orig/xen/include/asm-x86/msi.h	2012-09-13 08:40:47.000000000 +0200
> +++ 2012-09-11/xen/include/asm-x86/msi.h	2012-09-13 08:45:14.000000000 +0200
> @@ -153,18 +153,6 @@ int msi_free_irq(struct msi_desc *entry)
>   /*
>    * MSI Defined Data Structures
>    */
> -#define MSI_ADDRESS_HEADER		0xfee
> -#define MSI_ADDRESS_HEADER_SHIFT	12
> -#define MSI_ADDRESS_HEADER_MASK		0xfff000
> -#define MSI_ADDRESS_DEST_ID_MASK	0xfff0000f
> -#define MSI_TARGET_CPU_MASK		0xff
> -#define MSI_TARGET_CPU_SHIFT		12
> -#define MSI_DELIVERY_MODE		0
> -#define MSI_LEVEL_MODE			1	/* Edge always assert */
> -#define MSI_TRIGGER_MODE		0	/* MSI is edge sensitive */
> -#define MSI_PHYSICAL_MODE		0
> -#define MSI_LOGICAL_MODE		1
> -#define MSI_REDIRECTION_HINT_MODE	0
>
>   struct msg_data {
>   #if defined(__LITTLE_ENDIAN_BITFIELD)
> @@ -212,6 +200,12 @@ struct msg_address {
>   	__u32 	hi_address;
>   } __attribute__ ((packed));
>
> +void early_msi_init(void);
>   void msi_compose_msg(struct irq_desc *, struct msi_msg *);
> +void __msi_set_enable(u16 seg, u8 bus, u8 slot, u8 func, int pos, int enable);
> +void mask_msi_irq(struct irq_desc *);
> +void unmask_msi_irq(struct irq_desc *);
> +void ack_nonmaskable_msi_irq(struct irq_desc *);
> +void end_nonmaskable_msi_irq(struct irq_desc *, u8 vector);
>
>   #endif /* __ASM_MSI_H */
>
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 13 13:50:09 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Sep 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 1TC9no-0008M8-JD; Thu, 13 Sep 2012 13:49:56 +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 1TC9nn-0008Ly-0E
	for xen-devel@lists.xen.org; Thu, 13 Sep 2012 13:49:55 +0000
Received: from [85.158.143.99:31788] by server-2.bemta-4.messagelabs.com id
	04/81-21239-284E1505; Thu, 13 Sep 2012 13:49:54 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1347544191!22067917!1
X-Originating-IP: [216.32.180.184]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25558 invoked from network); 13 Sep 2012 13:49:53 -0000
Received: from co1ehsobe001.messaging.microsoft.com (HELO
	co1outboundpool.messaging.microsoft.com) (216.32.180.184)
	by server-12.tower-216.messagelabs.com with AES128-SHA encrypted SMTP;
	13 Sep 2012 13:49:53 -0000
Received: from mail174-co1-R.bigfish.com (10.243.78.231) by
	CO1EHSOBE016.bigfish.com (10.243.66.79) with Microsoft SMTP Server id
	14.1.225.23; Thu, 13 Sep 2012 13:49:51 +0000
Received: from mail174-co1 (localhost [127.0.0.1])	by
	mail174-co1-R.bigfish.com (Postfix) with ESMTP id E7A22100172;
	Thu, 13 Sep 2012 13:49:50 +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(zzbb2dI98dI9371I936eI1432I4015Id6f1izz1202h1d1ah1d2ahzz8275bhz2dh668h839hd25he5bhf0ah107ah1288h12a5h12bdh1155h)
Received: from mail174-co1 (localhost.localdomain [127.0.0.1]) by mail174-co1
	(MessageSwitch) id 1347544189614386_19691;
	Thu, 13 Sep 2012 13:49:49 +0000 (UTC)
Received: from CO1EHSMHS031.bigfish.com (unknown [10.243.78.228])	by
	mail174-co1.bigfish.com (Postfix) with ESMTP id 9426A5C00F3;
	Thu, 13 Sep 2012 13:49:49 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	CO1EHSMHS031.bigfish.com (10.243.66.41) with Microsoft SMTP Server id
	14.1.225.23; Thu, 13 Sep 2012 13:49:47 +0000
X-WSS-ID: 0MAAJQS-02-7BL-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 2C2BCC80D2;	Thu, 13 Sep 2012 08:49:39 -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, 13 Sep 2012 09:03:33 -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, 13 Sep 2012 08:49:43 -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, 13 Sep 2012
	09:49:41 -0400
Received: from [165.204.15.57] (gran.osrc.amd.com [165.204.15.57])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id 2798B49C121; Thu, 13 Sep 2012
	14:49:41 +0100 (BST)
Message-ID: <5051E4D1.1060207@amd.com>
Date: Thu, 13 Sep 2012 15:51:13 +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: <504F4C24020000780009A968@nat28.tlf.novell.com>
	<50508466.20309@amd.com>
	<5051A24A020000780009AF77@nat28.tlf.novell.com>
In-Reply-To: <5051A24A020000780009AF77@nat28.tlf.novell.com>
X-OriginatorOrg: amd.com
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 2/3] amd iommu: use base platform MSI
	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-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This version works well. Acked.
Thanks,
Wei

On 09/13/2012 09:07 AM, Jan Beulich wrote:
>>>> On 12.09.12 at 14:47, Wei Wang<wei.wang2@amd.com>  wrote:
>> I found this patch triggered a xen BUG
>
> Indeed - my default builds don't use high enough a CPU count to
> see this. I'm sorry for that. Below a drop-in replacement for the
> patch (it would unlikely apply cleanly to the tip of staging unstable
> due to Keir's cleanup after the removal of x86-32 support.
>
> Jan
>
> --- 2012-09-11.orig/xen/arch/x86/msi.c	2012-09-13 08:40:47.000000000 +0200
> +++ 2012-09-11/xen/arch/x86/msi.c	2012-09-13 08:43:21.000000000 +0200
> @@ -13,6 +13,7 @@
>   #include<xen/delay.h>
>   #include<xen/sched.h>
>   #include<xen/acpi.h>
> +#include<xen/cpu.h>
>   #include<xen/errno.h>
>   #include<xen/pci.h>
>   #include<xen/pci_regs.h>
> @@ -32,8 +33,9 @@
>   #include<xsm/xsm.h>
>
>   /* bitmap indicate which fixed map is free */
> -DEFINE_SPINLOCK(msix_fixmap_lock);
> -DECLARE_BITMAP(msix_fixmap_pages, FIX_MSIX_MAX_PAGES);
> +static DEFINE_SPINLOCK(msix_fixmap_lock);
> +static DECLARE_BITMAP(msix_fixmap_pages, FIX_MSIX_MAX_PAGES);
> +static DEFINE_PER_CPU(cpumask_var_t, scratch_mask);
>
>   static int msix_fixmap_alloc(void)
>   {
> @@ -126,13 +128,17 @@ void msi_compose_msg(struct irq_desc *de
>       unsigned dest;
>       int vector = desc->arch.vector;
>
> -    if ( cpumask_empty(desc->arch.cpu_mask) ) {
> +    memset(msg, 0, sizeof(*msg));
> +    if ( !cpumask_intersects(desc->arch.cpu_mask,&cpu_online_map) ) {
>           dprintk(XENLOG_ERR,"%s, compose msi message error!!\n", __func__);
>           return;
>       }
>
>       if ( vector ) {
> -        dest = cpu_mask_to_apicid(desc->arch.cpu_mask);
> +        cpumask_t *mask = this_cpu(scratch_mask);
> +
> +        cpumask_and(mask, desc->arch.cpu_mask,&cpu_online_map);
> +        dest = cpu_mask_to_apicid(mask);
>
>           msg->address_hi = MSI_ADDR_BASE_HI;
>           msg->address_lo =
> @@ -281,23 +287,27 @@ static void set_msi_affinity(struct irq_
>       write_msi_msg(msi_desc,&msg);
>   }
>
> +void __msi_set_enable(u16 seg, u8 bus, u8 slot, u8 func, int pos, int enable)
> +{
> +    u16 control = pci_conf_read16(seg, bus, slot, func, pos + PCI_MSI_FLAGS);
> +
> +    control&= ~PCI_MSI_FLAGS_ENABLE;
> +    if ( enable )
> +        control |= PCI_MSI_FLAGS_ENABLE;
> +    pci_conf_write16(seg, bus, slot, func, pos + PCI_MSI_FLAGS, control);
> +}
> +
>   static void msi_set_enable(struct pci_dev *dev, int enable)
>   {
>       int pos;
> -    u16 control, seg = dev->seg;
> +    u16 seg = dev->seg;
>       u8 bus = dev->bus;
>       u8 slot = PCI_SLOT(dev->devfn);
>       u8 func = PCI_FUNC(dev->devfn);
>
>       pos = pci_find_cap_offset(seg, bus, slot, func, PCI_CAP_ID_MSI);
>       if ( pos )
> -    {
> -        control = pci_conf_read16(seg, bus, slot, func, pos + PCI_MSI_FLAGS);
> -        control&= ~PCI_MSI_FLAGS_ENABLE;
> -        if ( enable )
> -            control |= PCI_MSI_FLAGS_ENABLE;
> -        pci_conf_write16(seg, bus, slot, func, pos + PCI_MSI_FLAGS, control);
> -    }
> +        __msi_set_enable(seg, bus, slot, func, pos, enable);
>   }
>
>   static void msix_set_enable(struct pci_dev *dev, int enable)
> @@ -379,12 +389,12 @@ static int msi_get_mask_bit(const struct
>       return -1;
>   }
>
> -static void mask_msi_irq(struct irq_desc *desc)
> +void mask_msi_irq(struct irq_desc *desc)
>   {
>       msi_set_mask_bit(desc, 1);
>   }
>
> -static void unmask_msi_irq(struct irq_desc *desc)
> +void unmask_msi_irq(struct irq_desc *desc)
>   {
>       msi_set_mask_bit(desc, 0);
>   }
> @@ -395,7 +405,7 @@ static unsigned int startup_msi_irq(stru
>       return 0;
>   }
>
> -static void ack_nonmaskable_msi_irq(struct irq_desc *desc)
> +void ack_nonmaskable_msi_irq(struct irq_desc *desc)
>   {
>       irq_complete_move(desc);
>       move_native_irq(desc);
> @@ -407,7 +417,7 @@ static void ack_maskable_msi_irq(struct
>       ack_APIC_irq(); /* ACKTYPE_NONE */
>   }
>
> -static void end_nonmaskable_msi_irq(struct irq_desc *desc, u8 vector)
> +void end_nonmaskable_msi_irq(struct irq_desc *desc, u8 vector)
>   {
>       ack_APIC_irq(); /* ACKTYPE_EOI */
>   }
> @@ -1071,6 +1081,39 @@ unsigned int pci_msix_get_table_len(stru
>       return len;
>   }
>
> +static int msi_cpu_callback(
> +    struct notifier_block *nfb, unsigned long action, void *hcpu)
> +{
> +    unsigned int cpu = (unsigned long)hcpu;
> +    int rc = 0;
> +
> +    switch ( action )
> +    {
> +    case CPU_UP_PREPARE:
> +        if ( !alloc_cpumask_var(&per_cpu(scratch_mask, cpu)) )
> +            rc = -ENOMEM;
> +        break;
> +    case CPU_UP_CANCELED:
> +    case CPU_DEAD:
> +        free_cpumask_var(per_cpu(scratch_mask, cpu));
> +        break;
> +    default:
> +        break;
> +    }
> +
> +    return notifier_from_errno(rc);
> +}
> +
> +static struct notifier_block msi_cpu_nfb = {
> +    .notifier_call = msi_cpu_callback
> +};
> +
> +void __init early_msi_init(void)
> +{
> +    register_cpu_notifier(&msi_cpu_nfb);
> +    msi_cpu_callback(&msi_cpu_nfb, CPU_UP_PREPARE, NULL);
> +}
> +
>   static void dump_msi(unsigned char key)
>   {
>       unsigned int irq;
> --- 2012-09-11.orig/xen/arch/x86/setup.c	2012-09-03 08:25:31.000000000 +0200
> +++ 2012-09-11/xen/arch/x86/setup.c	2012-09-13 08:44:49.000000000 +0200
> @@ -35,6 +35,7 @@
>   #include<asm/processor.h>
>   #include<asm/mpspec.h>
>   #include<asm/apic.h>
> +#include<asm/msi.h>
>   #include<asm/desc.h>
>   #include<asm/paging.h>
>   #include<asm/e820.h>
> @@ -1274,6 +1275,8 @@ void __init __start_xen(unsigned long mb
>       acpi_mmcfg_init();
>   #endif
>
> +    early_msi_init();
> +
>       iommu_setup();    /* setup iommu if available */
>
>       smp_prepare_cpus(max_cpus);
> --- 2012-09-11.orig/xen/drivers/passthrough/amd/iommu_detect.c	2012-09-13 08:40:47.000000000 +0200
> +++ 2012-09-11/xen/drivers/passthrough/amd/iommu_detect.c	2012-06-20 17:33:15.000000000 +0200
> @@ -31,7 +31,6 @@ static int __init get_iommu_msi_capabili
>       u16 seg, u8 bus, u8 dev, u8 func, struct amd_iommu *iommu)
>   {
>       int pos;
> -    u16 control;
>
>       pos = pci_find_cap_offset(seg, bus, dev, func, PCI_CAP_ID_MSI);
>
> @@ -41,9 +40,6 @@ static int __init get_iommu_msi_capabili
>       AMD_IOMMU_DEBUG("Found MSI capability block at %#x\n", pos);
>
>       iommu->msi_cap = pos;
> -    control = pci_conf_read16(seg, bus, dev, func,
> -                              iommu->msi_cap + PCI_MSI_FLAGS);
> -    iommu->maskbit = control&  PCI_MSI_FLAGS_MASKBIT;
>       return 0;
>   }
>
> --- 2012-09-11.orig/xen/drivers/passthrough/amd/iommu_init.c	2012-06-13 08:39:38.000000000 +0200
> +++ 2012-09-11/xen/drivers/passthrough/amd/iommu_init.c	2012-09-11 11:26:28.000000000 +0200
> @@ -467,20 +467,9 @@ static void iommu_msi_set_affinity(struc
>           return;
>       }
>
> -    memset(&msg, 0, sizeof(msg));
> -    msg.data = MSI_DATA_VECTOR(desc->arch.vector)&  0xff;
> -    msg.data |= 1<<  14;
> -    msg.data |= (INT_DELIVERY_MODE != dest_LowestPrio) ?
> -        MSI_DATA_DELIVERY_FIXED:
> -        MSI_DATA_DELIVERY_LOWPRI;
> -
> -    msg.address_hi =0;
> -    msg.address_lo = (MSI_ADDRESS_HEADER<<  (MSI_ADDRESS_HEADER_SHIFT + 8));
> -    msg.address_lo |= INT_DEST_MODE ? MSI_ADDR_DESTMODE_LOGIC:
> -                    MSI_ADDR_DESTMODE_PHYS;
> -    msg.address_lo |= (INT_DELIVERY_MODE != dest_LowestPrio) ?
> -                    MSI_ADDR_REDIRECTION_CPU:
> -                    MSI_ADDR_REDIRECTION_LOWPRI;
> +    msi_compose_msg(desc,&msg);
> +    /* Is this override really needed? */
> +    msg.address_lo&= ~MSI_ADDR_DEST_ID_MASK;
>       msg.address_lo |= MSI_ADDR_DEST_ID(dest&  0xff);
>
>       pci_conf_write32(seg, bus, dev, func,
> @@ -494,18 +483,8 @@ static void iommu_msi_set_affinity(struc
>
>   static void amd_iommu_msi_enable(struct amd_iommu *iommu, int flag)
>   {
> -    u16 control;
> -    int bus = PCI_BUS(iommu->bdf);
> -    int dev = PCI_SLOT(iommu->bdf);
> -    int func = PCI_FUNC(iommu->bdf);
> -
> -    control = pci_conf_read16(iommu->seg, bus, dev, func,
> -        iommu->msi_cap + PCI_MSI_FLAGS);
> -    control&= ~PCI_MSI_FLAGS_ENABLE;
> -    if ( flag )
> -        control |= flag;
> -    pci_conf_write16(iommu->seg, bus, dev, func,
> -        iommu->msi_cap + PCI_MSI_FLAGS, control);
> +    __msi_set_enable(iommu->seg, PCI_BUS(iommu->bdf), PCI_SLOT(iommu->bdf),
> +                     PCI_FUNC(iommu->bdf), iommu->msi_cap, flag);
>   }
>
>   static void iommu_msi_unmask(struct irq_desc *desc)
> @@ -513,10 +492,6 @@ static void iommu_msi_unmask(struct irq_
>       unsigned long flags;
>       struct amd_iommu *iommu = desc->action->dev_id;
>
> -    /* FIXME: do not support mask bits at the moment */
> -    if ( iommu->maskbit )
> -        return;
> -
>       spin_lock_irqsave(&iommu->lock, flags);
>       amd_iommu_msi_enable(iommu, IOMMU_CONTROL_ENABLED);
>       spin_unlock_irqrestore(&iommu->lock, flags);
> @@ -529,10 +504,6 @@ static void iommu_msi_mask(struct irq_de
>
>       irq_complete_move(desc);
>
> -    /* FIXME: do not support mask bits at the moment */
> -    if ( iommu->maskbit )
> -        return;
> -
>       spin_lock_irqsave(&iommu->lock, flags);
>       amd_iommu_msi_enable(iommu, IOMMU_CONTROL_DISABLED);
>       spin_unlock_irqrestore(&iommu->lock, flags);
> @@ -562,6 +533,37 @@ static hw_irq_controller iommu_msi_type
>       .set_affinity = iommu_msi_set_affinity,
>   };
>
> +static unsigned int iommu_maskable_msi_startup(struct irq_desc *desc)
> +{
> +    iommu_msi_unmask(desc);
> +    unmask_msi_irq(desc);
> +    return 0;
> +}
> +
> +static void iommu_maskable_msi_shutdown(struct irq_desc *desc)
> +{
> +    mask_msi_irq(desc);
> +    iommu_msi_mask(desc);
> +}
> +
> +/*
> + * While the names may appear mismatched, we indeed want to use the non-
> + * maskable flavors here, as we want the ACK to be issued in ->end().
> + */
> +#define iommu_maskable_msi_ack ack_nonmaskable_msi_irq
> +#define iommu_maskable_msi_end end_nonmaskable_msi_irq
> +
> +static hw_irq_controller iommu_maskable_msi_type = {
> +    .typename = "IOMMU-M-MSI",
> +    .startup = iommu_maskable_msi_startup,
> +    .shutdown = iommu_maskable_msi_shutdown,
> +    .enable = unmask_msi_irq,
> +    .disable = mask_msi_irq,
> +    .ack = iommu_maskable_msi_ack,
> +    .end = iommu_maskable_msi_end,
> +    .set_affinity = iommu_msi_set_affinity,
> +};
> +
>   static void parse_event_log_entry(struct amd_iommu *iommu, u32 entry[])
>   {
>       u16 domain_id, device_id, bdf, cword, flags;
> @@ -784,6 +786,7 @@ static void iommu_interrupt_handler(int
>   static int __init set_iommu_interrupt_handler(struct amd_iommu *iommu)
>   {
>       int irq, ret;
> +    u16 control;
>
>       irq = create_irq(NUMA_NO_NODE);
>       if ( irq<= 0 )
> @@ -792,7 +795,11 @@ static int __init set_iommu_interrupt_ha
>           return 0;
>       }
>
> -    irq_desc[irq].handler =&iommu_msi_type;
> +    control = pci_conf_read16(iommu->seg, PCI_BUS(iommu->bdf),
> +                              PCI_SLOT(iommu->bdf), PCI_FUNC(iommu->bdf),
> +                              iommu->msi_cap + PCI_MSI_FLAGS);
> +    irq_desc[irq].handler = control&  PCI_MSI_FLAGS_MASKBIT ?
> +&iommu_maskable_msi_type :&iommu_msi_type;
>       ret = request_irq(irq, iommu_interrupt_handler, 0, "amd_iommu", iommu);
>       if ( ret )
>       {
> --- 2012-09-11.orig/xen/include/asm-x86/amd-iommu.h	2012-09-13 08:40:47.000000000 +0200
> +++ 2012-09-11/xen/include/asm-x86/amd-iommu.h	2012-06-13 10:23:45.000000000 +0200
> @@ -83,6 +83,7 @@ struct amd_iommu {
>       u16 seg;
>       u16 bdf;
>       u16 cap_offset;
> +    u8 msi_cap;
>       iommu_cap_t cap;
>
>       u8 ht_flags;
> @@ -101,9 +102,6 @@ struct amd_iommu {
>       uint64_t exclusion_base;
>       uint64_t exclusion_limit;
>
> -    int msi_cap;
> -    int maskbit;
> -
>       int enabled;
>       int irq;
>   };
> --- 2012-09-11.orig/xen/include/asm-x86/msi.h	2012-09-13 08:40:47.000000000 +0200
> +++ 2012-09-11/xen/include/asm-x86/msi.h	2012-09-13 08:45:14.000000000 +0200
> @@ -153,18 +153,6 @@ int msi_free_irq(struct msi_desc *entry)
>   /*
>    * MSI Defined Data Structures
>    */
> -#define MSI_ADDRESS_HEADER		0xfee
> -#define MSI_ADDRESS_HEADER_SHIFT	12
> -#define MSI_ADDRESS_HEADER_MASK		0xfff000
> -#define MSI_ADDRESS_DEST_ID_MASK	0xfff0000f
> -#define MSI_TARGET_CPU_MASK		0xff
> -#define MSI_TARGET_CPU_SHIFT		12
> -#define MSI_DELIVERY_MODE		0
> -#define MSI_LEVEL_MODE			1	/* Edge always assert */
> -#define MSI_TRIGGER_MODE		0	/* MSI is edge sensitive */
> -#define MSI_PHYSICAL_MODE		0
> -#define MSI_LOGICAL_MODE		1
> -#define MSI_REDIRECTION_HINT_MODE	0
>
>   struct msg_data {
>   #if defined(__LITTLE_ENDIAN_BITFIELD)
> @@ -212,6 +200,12 @@ struct msg_address {
>   	__u32 	hi_address;
>   } __attribute__ ((packed));
>
> +void early_msi_init(void);
>   void msi_compose_msg(struct irq_desc *, struct msi_msg *);
> +void __msi_set_enable(u16 seg, u8 bus, u8 slot, u8 func, int pos, int enable);
> +void mask_msi_irq(struct irq_desc *);
> +void unmask_msi_irq(struct irq_desc *);
> +void ack_nonmaskable_msi_irq(struct irq_desc *);
> +void end_nonmaskable_msi_irq(struct irq_desc *, u8 vector);
>
>   #endif /* __ASM_MSI_H */
>
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 13 13:56:20 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Sep 2012 13:56:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TC9ti-000079-JF; Thu, 13 Sep 2012 13:56:02 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1TC9tg-000070-Aq
	for xen-devel@lists.xen.org; Thu, 13 Sep 2012 13:56:00 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-16.tower-27.messagelabs.com!1347544552!9478895!1
X-Originating-IP: [63.239.67.9]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9246 invoked from network); 13 Sep 2012 13:55:53 -0000
Received: from emvm-gh1-uea08.nsa.gov (HELO nsa.gov) (63.239.67.9)
	by server-16.tower-27.messagelabs.com with SMTP;
	13 Sep 2012 13:55:53 -0000
X-TM-IMSS-Message-ID: <3e961c610010cf61@nsa.gov>
Received: from tarius.tycho.ncsc.mil ([144.51.3.1]) by nsa.gov ([63.239.67.9])
	with ESMTP (TREND IMSS SMTP Service 7.1) id 3e961c610010cf61 ;
	Thu, 13 Sep 2012 09:55:38 -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 q8DDtk9E002505; 
	Thu, 13 Sep 2012 09:55:47 -0400
Message-ID: <5051E5E2.50801@tycho.nsa.gov>
Date: Thu, 13 Sep 2012 09:55:46 -0400
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Organization: National Security Agency
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120828 Thunderbird/15.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <1347465586-20009-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1347465586-20009-21-git-send-email-dgdegra@tycho.nsa.gov>
	<5051B1CC020000780009AFCE@nat28.tlf.novell.com>
In-Reply-To: <5051B1CC020000780009AFCE@nat28.tlf.novell.com>
Cc: Tim Deegan <tim@xen.org>, Keir Fraser <keir@xen.org>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 20/22] arch/x86: use XSM hooks for
 get_pg_owner access checks
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 09/13/2012 04:13 AM, Jan Beulich wrote:
>>>> On 12.09.12 at 17:59, Daniel De Graaf <dgdegra@tycho.nsa.gov> wrote:
>> @@ -3353,9 +3357,14 @@ long do_mmu_update(
>>              mfn = req.ptr >> PAGE_SHIFT;
>>              gpfn = req.val;
>>  
>> -            rc = xsm_mmu_machphys_update(d, pg_owner, mfn);
>> -            if ( rc )
>> -                break;
>> +            xsm_needed |= XSM_MMU_MACHPHYS_UPDATE;
>> +            if ( xsm_needed != xsm_checked )
>> +            {
>> +                rc = xsm_mmu_update(d, pt_owner, pg_owner, xsm_needed);
> 
> If you're already updating it this way, it would seem appropriate
> to remove the over-checking here: pt_owner is meaningless for
> this operation (there are no page tables involved), and hence
> you could/should pass d instead.
> 
> Jan
> 

While this is safe, it makes thinking about the arguments to the XSM hook
harder: the second argument would be defined as "pt_owner if called with
XSM_MMU_NORMAL_UPDATE set and either XSM_MMU_MACHPHYS_UPDATE unset or
XSM_MMU_MACHPHYS_UPDATE set in the previous call; otherwise, d." I would
prefer the simpler method of passing pt_owner every time, and only checking
it if XSM_MMU_NORMAL_UPDATE is set (which I now notice that the default
XSM hook does not do, although the FLASK hook does; I'll fix that).

-- 
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 Sep 13 13:56:20 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Sep 2012 13:56:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TC9ti-000079-JF; Thu, 13 Sep 2012 13:56:02 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1TC9tg-000070-Aq
	for xen-devel@lists.xen.org; Thu, 13 Sep 2012 13:56:00 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-16.tower-27.messagelabs.com!1347544552!9478895!1
X-Originating-IP: [63.239.67.9]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9246 invoked from network); 13 Sep 2012 13:55:53 -0000
Received: from emvm-gh1-uea08.nsa.gov (HELO nsa.gov) (63.239.67.9)
	by server-16.tower-27.messagelabs.com with SMTP;
	13 Sep 2012 13:55:53 -0000
X-TM-IMSS-Message-ID: <3e961c610010cf61@nsa.gov>
Received: from tarius.tycho.ncsc.mil ([144.51.3.1]) by nsa.gov ([63.239.67.9])
	with ESMTP (TREND IMSS SMTP Service 7.1) id 3e961c610010cf61 ;
	Thu, 13 Sep 2012 09:55:38 -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 q8DDtk9E002505; 
	Thu, 13 Sep 2012 09:55:47 -0400
Message-ID: <5051E5E2.50801@tycho.nsa.gov>
Date: Thu, 13 Sep 2012 09:55:46 -0400
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Organization: National Security Agency
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120828 Thunderbird/15.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <1347465586-20009-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1347465586-20009-21-git-send-email-dgdegra@tycho.nsa.gov>
	<5051B1CC020000780009AFCE@nat28.tlf.novell.com>
In-Reply-To: <5051B1CC020000780009AFCE@nat28.tlf.novell.com>
Cc: Tim Deegan <tim@xen.org>, Keir Fraser <keir@xen.org>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 20/22] arch/x86: use XSM hooks for
 get_pg_owner access checks
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 09/13/2012 04:13 AM, Jan Beulich wrote:
>>>> On 12.09.12 at 17:59, Daniel De Graaf <dgdegra@tycho.nsa.gov> wrote:
>> @@ -3353,9 +3357,14 @@ long do_mmu_update(
>>              mfn = req.ptr >> PAGE_SHIFT;
>>              gpfn = req.val;
>>  
>> -            rc = xsm_mmu_machphys_update(d, pg_owner, mfn);
>> -            if ( rc )
>> -                break;
>> +            xsm_needed |= XSM_MMU_MACHPHYS_UPDATE;
>> +            if ( xsm_needed != xsm_checked )
>> +            {
>> +                rc = xsm_mmu_update(d, pt_owner, pg_owner, xsm_needed);
> 
> If you're already updating it this way, it would seem appropriate
> to remove the over-checking here: pt_owner is meaningless for
> this operation (there are no page tables involved), and hence
> you could/should pass d instead.
> 
> Jan
> 

While this is safe, it makes thinking about the arguments to the XSM hook
harder: the second argument would be defined as "pt_owner if called with
XSM_MMU_NORMAL_UPDATE set and either XSM_MMU_MACHPHYS_UPDATE unset or
XSM_MMU_MACHPHYS_UPDATE set in the previous call; otherwise, d." I would
prefer the simpler method of passing pt_owner every time, and only checking
it if XSM_MMU_NORMAL_UPDATE is set (which I now notice that the default
XSM hook does not do, although the FLASK hook does; I'll fix that).

-- 
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 Sep 13 14:00:00 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Sep 2012 14: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 1TC9xK-0000Ed-7z; Thu, 13 Sep 2012 13:59:46 +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 1TC9xJ-0000ET-0i
	for xen-devel@lists.xensource.com; Thu, 13 Sep 2012 13:59:45 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1347544778!10914979!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDkwMjg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 980 invoked from network); 13 Sep 2012 13:59:38 -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;
	13 Sep 2012 13:59:38 -0000
X-IronPort-AV: E=Sophos;i="4.80,417,1344211200"; d="scan'208";a="14522850"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Sep 2012 13:59: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.279.1; Thu, 13 Sep 2012 14:59: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 1TC9xB-0006C1-QJ;
	Thu, 13 Sep 2012 13:59:37 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1TC9xB-0004MO-El;
	Thu, 13 Sep 2012 14:59:37 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-13719-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 13 Sep 2012 14:59:37 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.0-testing test] 13719: 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 13719 xen-4.0-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13719/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 13650
 test-amd64-i386-xl-credit2    5 xen-boot                     fail   like 13650

Tests which did not succeed, but are not blocking:
 test-amd64-i386-xl-multivcpu 15 guest-stop                   fail   never pass
 test-amd64-amd64-xl-pcipt-intel  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-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-win-vcpus1   16 leak-check/check             fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  7 redhat-install         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-qemuu-rhel6hvm-amd  7 redhat-install           fail never pass
 test-amd64-i386-rhel6hvm-amd  7 redhat-install               fail   never pass
 test-i386-i386-xl            15 guest-stop                   fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1  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-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
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-i386-i386-xl-winxpsp3    7 windows-install              fail   never pass

version targeted for testing:
 xen                  1d1538beeada
baseline version:
 xen                  79444af3258c

------------------------------------------------------------
People who touched revisions under test:
------------------------------------------------------------

jobs:
 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=1d1538beeada
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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 1d1538beeada
+ branch=xen-4.0-testing
+ revision=1d1538beeada
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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/hg/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 1d1538beeada 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 2 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 Sep 13 14:00:00 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Sep 2012 14: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 1TC9xK-0000Ed-7z; Thu, 13 Sep 2012 13:59:46 +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 1TC9xJ-0000ET-0i
	for xen-devel@lists.xensource.com; Thu, 13 Sep 2012 13:59:45 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1347544778!10914979!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDkwMjg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 980 invoked from network); 13 Sep 2012 13:59:38 -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;
	13 Sep 2012 13:59:38 -0000
X-IronPort-AV: E=Sophos;i="4.80,417,1344211200"; d="scan'208";a="14522850"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Sep 2012 13:59: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.279.1; Thu, 13 Sep 2012 14:59: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 1TC9xB-0006C1-QJ;
	Thu, 13 Sep 2012 13:59:37 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1TC9xB-0004MO-El;
	Thu, 13 Sep 2012 14:59:37 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-13719-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 13 Sep 2012 14:59:37 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.0-testing test] 13719: 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 13719 xen-4.0-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13719/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 13650
 test-amd64-i386-xl-credit2    5 xen-boot                     fail   like 13650

Tests which did not succeed, but are not blocking:
 test-amd64-i386-xl-multivcpu 15 guest-stop                   fail   never pass
 test-amd64-amd64-xl-pcipt-intel  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-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-win-vcpus1   16 leak-check/check             fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  7 redhat-install         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-qemuu-rhel6hvm-amd  7 redhat-install           fail never pass
 test-amd64-i386-rhel6hvm-amd  7 redhat-install               fail   never pass
 test-i386-i386-xl            15 guest-stop                   fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1  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-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
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass
 test-i386-i386-xl-winxpsp3    7 windows-install              fail   never pass

version targeted for testing:
 xen                  1d1538beeada
baseline version:
 xen                  79444af3258c

------------------------------------------------------------
People who touched revisions under test:
------------------------------------------------------------

jobs:
 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=1d1538beeada
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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 1d1538beeada
+ branch=xen-4.0-testing
+ revision=1d1538beeada
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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/hg/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 1d1538beeada 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 2 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 Sep 13 14:01:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Sep 2012 14:01:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TC9yU-0000NZ-MX; Thu, 13 Sep 2012 14:00:58 +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 1TC9yT-0000NF-9m
	for xen-devel@lists.xen.org; Thu, 13 Sep 2012 14:00:57 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1347544850!8920038!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQxMjE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26005 invoked from network); 13 Sep 2012 14:00:50 -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;
	13 Sep 2012 14:00:50 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 13 Sep 2012 15:00:50 +0100
Message-Id: <50520368020000780009B128@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 13 Sep 2012 15:01:44 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Tim Deegan" <tim@xen.org>
References: <CAFw--Dd0k7L+T_UJc0yHAkUGrY_-GDHaQjK3OM-1UdOp=J-wAQ@mail.gmail.com>
	<20120907085036.GA71093@ocelot.phlegethon.org>
	<5049E2C70200007800099B21@nat28.tlf.novell.com>
	<20120913101120.GA12881@ocelot.phlegethon.org>
	<5051E531020000780009B083@nat28.tlf.novell.com>
	<20120913122130.GB12881@ocelot.phlegethon.org>
In-Reply-To: <20120913122130.GB12881@ocelot.phlegethon.org>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Paolo Bonzini <pbonzini@redhat.com>, Jeffrey Karrels <karrelsj@gmail.com>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Clang/LLVM version requirements
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.09.12 at 14:21, Tim Deegan <tim@xen.org> wrote:
> At 12:52 +0100 on 13 Sep (1347540769), Jan Beulich wrote:
>> >>> On 13.09.12 at 12:11, Tim Deegan <tim@xen.org> wrote:
>> > At 11:04 +0100 on 07 Sep (1347015863), Jan Beulich wrote:
>> >> >>> On 07.09.12 at 10:50, Tim Deegan <tim@xen.org> wrote:
>> >> > In any case we probably ought to check for stray .data symbols too.
>> >> 
>> >> Not really, no. Those would still be present in reloc.bin, and
>> >> hence make it into reloc.S.
>> > 
>> > But they would break the test, because the magic alignment happens in
>> > .text, right?  Anyway, compile-time failure seems more useful.  How
>> > about this, based on the similar checks for init-only files?
>> 
>> Yes, it's happening in .text currently. The problem, iirc, really was
>> that _end and __bss_start didn't always match (depending on
>> compiler version), apparently because at the linking stage _end
>> got aligned more strictly than __bss_start.
>> 
>> So the patch is fine by me if it covers that misalignment case.
>> But it seems a little heavy handed - I'd think that instead of the
>> sub-section, we could just create an arbitrary other section, or
>> even allow uninitialized variable (it's unclear to me why Paolo
>> wrote the comment - in c/s 25479:61dfb3da56b - regarding BSS
>> the way it is now) - after all we only need to make sure that
>> - the space gets properly allocated in trampoline.S, i.e. also in
>>   reloc.bin
>> - all accesses are PC-relative
>> Neither has anything to do with use of uninitialized variables.
> 
> Allowing BSS would just need a few extra runes (AFAICS,
> "--set-section-flags .bss=alloc,load,contents") in the objcopy that
> makes reloc.bin.
>  But I'm not sure how to make sure everything is
> rip-relative, do if that's the real concern I'm inclined to go with
> this compile-time check and exclude .[ro]data[.*] as well.
> We can always fix it up to allow bss and data sections if we ever
> actually need them.

As said, I'm fine with any approach as long as it works with all
supported tool chains. So feel free to go the route you're
proposing.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 13 14:01:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Sep 2012 14:01:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TC9yU-0000NZ-MX; Thu, 13 Sep 2012 14:00:58 +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 1TC9yT-0000NF-9m
	for xen-devel@lists.xen.org; Thu, 13 Sep 2012 14:00:57 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1347544850!8920038!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQxMjE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26005 invoked from network); 13 Sep 2012 14:00:50 -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;
	13 Sep 2012 14:00:50 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 13 Sep 2012 15:00:50 +0100
Message-Id: <50520368020000780009B128@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 13 Sep 2012 15:01:44 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Tim Deegan" <tim@xen.org>
References: <CAFw--Dd0k7L+T_UJc0yHAkUGrY_-GDHaQjK3OM-1UdOp=J-wAQ@mail.gmail.com>
	<20120907085036.GA71093@ocelot.phlegethon.org>
	<5049E2C70200007800099B21@nat28.tlf.novell.com>
	<20120913101120.GA12881@ocelot.phlegethon.org>
	<5051E531020000780009B083@nat28.tlf.novell.com>
	<20120913122130.GB12881@ocelot.phlegethon.org>
In-Reply-To: <20120913122130.GB12881@ocelot.phlegethon.org>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Paolo Bonzini <pbonzini@redhat.com>, Jeffrey Karrels <karrelsj@gmail.com>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Clang/LLVM version requirements
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.09.12 at 14:21, Tim Deegan <tim@xen.org> wrote:
> At 12:52 +0100 on 13 Sep (1347540769), Jan Beulich wrote:
>> >>> On 13.09.12 at 12:11, Tim Deegan <tim@xen.org> wrote:
>> > At 11:04 +0100 on 07 Sep (1347015863), Jan Beulich wrote:
>> >> >>> On 07.09.12 at 10:50, Tim Deegan <tim@xen.org> wrote:
>> >> > In any case we probably ought to check for stray .data symbols too.
>> >> 
>> >> Not really, no. Those would still be present in reloc.bin, and
>> >> hence make it into reloc.S.
>> > 
>> > But they would break the test, because the magic alignment happens in
>> > .text, right?  Anyway, compile-time failure seems more useful.  How
>> > about this, based on the similar checks for init-only files?
>> 
>> Yes, it's happening in .text currently. The problem, iirc, really was
>> that _end and __bss_start didn't always match (depending on
>> compiler version), apparently because at the linking stage _end
>> got aligned more strictly than __bss_start.
>> 
>> So the patch is fine by me if it covers that misalignment case.
>> But it seems a little heavy handed - I'd think that instead of the
>> sub-section, we could just create an arbitrary other section, or
>> even allow uninitialized variable (it's unclear to me why Paolo
>> wrote the comment - in c/s 25479:61dfb3da56b - regarding BSS
>> the way it is now) - after all we only need to make sure that
>> - the space gets properly allocated in trampoline.S, i.e. also in
>>   reloc.bin
>> - all accesses are PC-relative
>> Neither has anything to do with use of uninitialized variables.
> 
> Allowing BSS would just need a few extra runes (AFAICS,
> "--set-section-flags .bss=alloc,load,contents") in the objcopy that
> makes reloc.bin.
>  But I'm not sure how to make sure everything is
> rip-relative, do if that's the real concern I'm inclined to go with
> this compile-time check and exclude .[ro]data[.*] as well.
> We can always fix it up to allow bss and data sections if we ever
> actually need them.

As said, I'm fine with any approach as long as it works with all
supported tool chains. So feel free to go the route you're
proposing.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 13 14:02:21 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Sep 2012 14: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 1TC9zc-0000WE-Az; Thu, 13 Sep 2012 14:02:08 +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 1TC9za-0000Vz-DQ
	for xen-devel@lists.xen.org; Thu, 13 Sep 2012 14:02:06 +0000
Received: from [85.158.138.51:28175] by server-7.bemta-3.messagelabs.com id
	29/7A-32000-D57E1505; Thu, 13 Sep 2012 14:02:05 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-2.tower-174.messagelabs.com!1347544922!30371919!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNzQyODc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26727 invoked from network); 13 Sep 2012 14:02:04 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-2.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Sep 2012 14:02:04 -0000
X-IronPort-AV: E=Sophos;i="4.80,417,1344211200"; d="scan'208";a="207987718"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Sep 2012 14:02:01 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1;
	Thu, 13 Sep 2012 10:02:01 -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 1TC9zR-00030F-Ts	for xen-devel@lists.xen.org;
	Thu, 13 Sep 2012 15:01:57 +0100
Received: from tdeegan by whitby.uk.xensource.com with local (Exim 4.76)
	(envelope-from <tim@xen.org>)	id 1TC9zR-0006or-M2	for
	xen-devel@lists.xen.org; Thu, 13 Sep 2012 15:01:57 +0100
MIME-Version: 1.0
X-Mercurial-Node: a770d1c8448d73ccf2ec36a5322532c2e3c14641
Message-ID: <a770d1c8448d73ccf2ec.1347544917@whitby.uk.xensource.com>
User-Agent: Mercurial-patchbomb/2.0.1
Date: Thu, 13 Sep 2012 15:01:57 +0100
From: Tim Deegan <tim@xen.org>
To: xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH] x86/mm: remove the linear mapping of the p2m
	tables
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

# HG changeset patch
# User Tim Deegan <tim@xen.org>
# Date 1347544824 -3600
# Node ID a770d1c8448d73ccf2ec36a5322532c2e3c14641
# Parent  5691e4cc17da7fe8664a67f1d07c3755c0ca34ed
x86/mm: remove the linear mapping of the p2m tables.

Mapping the p2m into the monitor tables was an important optimization
on 32-bit builds, where it avoided mapping and unmapping p2m pages
during a walk.  On 64-bit it makes no difference -- see
http://old-list-archives.xen.org/archives/html/xen-devel/2010-04/msg00981.html
Get rid of it, and use the explicit walk for all lookups.

Signed-off-by: Tim Deegan <tim@xen.org>

diff -r 5691e4cc17da -r a770d1c8448d xen/arch/x86/mm/hap/hap.c
--- a/xen/arch/x86/mm/hap/hap.c	Thu Sep 13 10:23:17 2012 +0200
+++ b/xen/arch/x86/mm/hap/hap.c	Thu Sep 13 15:00:24 2012 +0100
@@ -405,11 +405,6 @@ static void hap_install_xen_entries_in_l
     l4e[l4_table_offset(LINEAR_PT_VIRT_START)] =
         l4e_from_pfn(mfn_x(l4mfn), __PAGE_HYPERVISOR);
 
-    /* Install the domain-specific P2M table */
-    l4e[l4_table_offset(RO_MPT_VIRT_START)] =
-        l4e_from_pfn(mfn_x(pagetable_get_mfn(p2m_get_pagetable(p2m_get_hostp2m(d)))),
-                     __PAGE_HYPERVISOR);
-
     hap_unmap_domain_page(l4e);
 }
 
diff -r 5691e4cc17da -r a770d1c8448d xen/arch/x86/mm/p2m-pt.c
--- a/xen/arch/x86/mm/p2m-pt.c	Thu Sep 13 10:23:17 2012 +0200
+++ b/xen/arch/x86/mm/p2m-pt.c	Thu Sep 13 15:00:24 2012 +0100
@@ -460,186 +460,6 @@ out:
     return rv;
 }
 
-
-/* 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,
-                                    unsigned int *page_order)
-{
-    mfn_t mfn = _mfn(INVALID_MFN);
-    p2m_type_t p2mt = p2m_mmio_dm;
-    paddr_t addr = ((paddr_t)gfn) << PAGE_SHIFT;
-    /* XXX This is for compatibility with the old model, where anything not 
-     * XXX marked as RAM was considered to be emulated MMIO space.
-     * XXX Once we start explicitly registering MMIO regions in the p2m 
-     * XXX we will return p2m_invalid for unmapped gfns */
-
-    l1_pgentry_t l1e = l1e_empty(), *p2m_entry;
-    l2_pgentry_t l2e = l2e_empty();
-    l3_pgentry_t l3e = l3e_empty();
-    int ret;
-
-    ASSERT(gfn < (RO_MPT_VIRT_END - RO_MPT_VIRT_START) 
-           / sizeof(l1_pgentry_t));
-
-    /*
-     * Read & process L3
-     */
-    p2m_entry = (l1_pgentry_t *)
-        &__linear_l2_table[l2_linear_offset(RO_MPT_VIRT_START)
-                           + l3_linear_offset(addr)];
-pod_retry_l3:
-    ret = __copy_from_user(&l3e, p2m_entry, sizeof(l3e));
-
-    if ( ret != 0 || !(l3e_get_flags(l3e) & _PAGE_PRESENT) )
-    {
-        if ( (l3e_get_flags(l3e) & _PAGE_PSE) &&
-             (p2m_flags_to_type(l3e_get_flags(l3e)) == p2m_populate_on_demand) )
-        {
-            /* The read has succeeded, so we know that mapping exists */
-            if ( q & P2M_ALLOC )
-            {
-                if ( !p2m_pod_demand_populate(p2m, gfn, PAGE_ORDER_1G, q) )
-                    goto pod_retry_l3;
-                p2mt = p2m_invalid;
-                gdprintk(XENLOG_ERR, "%s: Allocate 1GB failed!\n", __func__);
-                goto out;
-            }
-            else
-            {
-                p2mt = p2m_populate_on_demand;
-                goto out;
-            }
-        }
-        goto pod_retry_l2;
-    }
-
-    if ( l3e_get_flags(l3e) & _PAGE_PSE )
-    {
-        p2mt = p2m_flags_to_type(l3e_get_flags(l3e));
-        ASSERT(l3e_get_pfn(l3e) != INVALID_MFN || !p2m_is_ram(p2mt));
-        if (p2m_is_valid(p2mt) )
-            mfn = _mfn(l3e_get_pfn(l3e) + 
-                       l2_table_offset(addr) * L1_PAGETABLE_ENTRIES + 
-                       l1_table_offset(addr));
-        else
-            p2mt = p2m_mmio_dm;
-            
-        if ( page_order )
-            *page_order = PAGE_ORDER_1G;
-        goto out;
-    }
-
-    /*
-     * Read & process L2
-     */
-    p2m_entry = &__linear_l1_table[l1_linear_offset(RO_MPT_VIRT_START)
-                                   + l2_linear_offset(addr)];
-
-pod_retry_l2:
-    ret = __copy_from_user(&l2e,
-                           p2m_entry,
-                           sizeof(l2e));
-    if ( ret != 0
-         || !(l2e_get_flags(l2e) & _PAGE_PRESENT) )
-    {
-        if( (l2e_get_flags(l2e) & _PAGE_PSE)
-            && ( p2m_flags_to_type(l2e_get_flags(l2e))
-                 == p2m_populate_on_demand ) )
-        {
-            /* The read has succeeded, so we know that the mapping
-             * exits at this point.  */
-            if ( q & P2M_ALLOC )
-            {
-                if ( !p2m_pod_demand_populate(p2m, gfn, 
-                                                PAGE_ORDER_2M, q) )
-                    goto pod_retry_l2;
-
-                /* Allocate failed. */
-                p2mt = p2m_invalid;
-                printk("%s: Allocate failed!\n", __func__);
-                goto out;
-            }
-            else
-            {
-                p2mt = p2m_populate_on_demand;
-                goto out;
-            }
-        }
-
-        goto pod_retry_l1;
-    }
-        
-    if (l2e_get_flags(l2e) & _PAGE_PSE)
-    {
-        p2mt = p2m_flags_to_type(l2e_get_flags(l2e));
-        ASSERT(l2e_get_pfn(l2e) != INVALID_MFN || !p2m_is_ram(p2mt));
-
-        if ( p2m_is_valid(p2mt) )
-            mfn = _mfn(l2e_get_pfn(l2e) + l1_table_offset(addr));
-        else
-            p2mt = p2m_mmio_dm;
-
-        if ( page_order )
-            *page_order = PAGE_ORDER_2M;
-        goto out;
-    }
-
-    /*
-     * Read and process L1
-     */
-
-    /* Need to __copy_from_user because the p2m is sparse and this
-     * part might not exist */
-pod_retry_l1:
-    p2m_entry = &phys_to_machine_mapping[gfn];
-
-    ret = __copy_from_user(&l1e,
-                           p2m_entry,
-                           sizeof(l1e));
-            
-    if ( ret == 0 ) {
-        unsigned long l1e_mfn = l1e_get_pfn(l1e);
-        p2mt = p2m_flags_to_type(l1e_get_flags(l1e));
-        ASSERT( mfn_valid(_mfn(l1e_mfn)) || !p2m_is_ram(p2mt) ||
-                p2m_is_paging(p2mt) );
-
-        if ( p2mt == p2m_populate_on_demand )
-        {
-            /* The read has succeeded, so we know that the mapping
-             * exits at this point.  */
-            if ( q & P2M_ALLOC )
-            {
-                if ( !p2m_pod_demand_populate(p2m, gfn, 
-                                                PAGE_ORDER_4K, q) )
-                    goto pod_retry_l1;
-
-                /* Allocate failed. */
-                p2mt = p2m_invalid;
-                goto out;
-            }
-            else
-            {
-                p2mt = p2m_populate_on_demand;
-                goto out;
-            }
-        }
-
-        if ( p2m_is_valid(p2mt) || p2m_is_grant(p2mt) )
-            mfn = _mfn(l1e_mfn);
-        else 
-            /* XXX see above */
-            p2mt = p2m_mmio_dm;
-    }
-    
-    if ( page_order )
-        *page_order = PAGE_ORDER_4K;
-out:
-    *t = p2mt;
-    return mfn;
-}
-
 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,
@@ -666,10 +486,6 @@ 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);
 
-    /* Use the fast path with the linear mapping if we can */
-    if ( p2m == p2m_get_hostp2m(current->domain) )
-        return p2m_gfn_to_mfn_current(p2m, gfn, t, a, q, page_order);
-
     mfn = pagetable_get_mfn(p2m_get_pagetable(p2m));
 
     {
@@ -904,17 +720,10 @@ long p2m_pt_audit_p2m(struct p2m_domain 
 {
     unsigned long entry_count = 0, pmbad = 0;
     unsigned long mfn, gfn, m2pfn;
-    int test_linear;
-    struct domain *d = p2m->domain;
 
     ASSERT(p2m_locked_by_me(p2m));
     ASSERT(pod_locked_by_me(p2m));
 
-    test_linear = ( (d == current->domain)
-                    && !pagetable_is_null(current->arch.monitor_table) );
-    if ( test_linear )
-        flush_tlb_local();
-
     /* Audit part one: walk the domain's p2m table, checking the entries. */
     if ( pagetable_get_pfn(p2m_get_pagetable(p2m)) != 0 )
     {
diff -r 5691e4cc17da -r a770d1c8448d xen/arch/x86/mm/shadow/multi.c
--- a/xen/arch/x86/mm/shadow/multi.c	Thu Sep 13 10:23:17 2012 +0200
+++ b/xen/arch/x86/mm/shadow/multi.c	Thu Sep 13 15:00:24 2012 +0100
@@ -1472,14 +1472,6 @@ void sh_install_xen_entries_in_l4(struct
             shadow_l4e_from_mfn(gl4mfn, __PAGE_HYPERVISOR);
     }
 
-    if ( shadow_mode_translate(v->domain) )
-    {
-        /* install domain-specific P2M table */
-        sl4e[shadow_l4_table_offset(RO_MPT_VIRT_START)] =
-            shadow_l4e_from_mfn(pagetable_get_mfn(p2m_get_pagetable(p2m_get_hostp2m(d))),
-                                __PAGE_HYPERVISOR);
-    }
-
     sh_unmap_domain_page(sl4e);    
 }
 #endif
diff -r 5691e4cc17da -r a770d1c8448d xen/include/asm-x86/p2m.h
--- a/xen/include/asm-x86/p2m.h	Thu Sep 13 10:23:17 2012 +0200
+++ b/xen/include/asm-x86/p2m.h	Thu Sep 13 15:00:24 2012 +0100
@@ -35,22 +35,6 @@
 extern bool_t opt_hap_1gb, opt_hap_2mb;
 
 /*
- * The phys_to_machine_mapping maps guest physical frame numbers 
- * to machine frame numbers.  It only exists for paging_mode_translate 
- * guests. It is organised in page-table format, which:
- *
- * (1) allows us to use it directly as the second pagetable in hardware-
- *     assisted paging and (hopefully) iommu support; and 
- * (2) lets us map it directly into the guest vcpus' virtual address space 
- *     as a linear pagetable, so we can read and write it easily.
- *
- * For (2) we steal the address space that would have normally been used
- * by the read-only MPT map in a non-translated guest.  (For 
- * paging_mode_external() guests this mapping is in the monitor table.)
- */
-#define phys_to_machine_mapping ((l1_pgentry_t *)RO_MPT_VIRT_START)
-
-/*
  * The upper levels of the p2m pagetable always contain full rights; all 
  * variation in the access control bits is made in the level-1 PTEs.
  * 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 13 14:02:21 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Sep 2012 14: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 1TC9zc-0000WE-Az; Thu, 13 Sep 2012 14:02:08 +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 1TC9za-0000Vz-DQ
	for xen-devel@lists.xen.org; Thu, 13 Sep 2012 14:02:06 +0000
Received: from [85.158.138.51:28175] by server-7.bemta-3.messagelabs.com id
	29/7A-32000-D57E1505; Thu, 13 Sep 2012 14:02:05 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-2.tower-174.messagelabs.com!1347544922!30371919!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNzQyODc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26727 invoked from network); 13 Sep 2012 14:02:04 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-2.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Sep 2012 14:02:04 -0000
X-IronPort-AV: E=Sophos;i="4.80,417,1344211200"; d="scan'208";a="207987718"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Sep 2012 14:02:01 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1;
	Thu, 13 Sep 2012 10:02:01 -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 1TC9zR-00030F-Ts	for xen-devel@lists.xen.org;
	Thu, 13 Sep 2012 15:01:57 +0100
Received: from tdeegan by whitby.uk.xensource.com with local (Exim 4.76)
	(envelope-from <tim@xen.org>)	id 1TC9zR-0006or-M2	for
	xen-devel@lists.xen.org; Thu, 13 Sep 2012 15:01:57 +0100
MIME-Version: 1.0
X-Mercurial-Node: a770d1c8448d73ccf2ec36a5322532c2e3c14641
Message-ID: <a770d1c8448d73ccf2ec.1347544917@whitby.uk.xensource.com>
User-Agent: Mercurial-patchbomb/2.0.1
Date: Thu, 13 Sep 2012 15:01:57 +0100
From: Tim Deegan <tim@xen.org>
To: xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH] x86/mm: remove the linear mapping of the p2m
	tables
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

# HG changeset patch
# User Tim Deegan <tim@xen.org>
# Date 1347544824 -3600
# Node ID a770d1c8448d73ccf2ec36a5322532c2e3c14641
# Parent  5691e4cc17da7fe8664a67f1d07c3755c0ca34ed
x86/mm: remove the linear mapping of the p2m tables.

Mapping the p2m into the monitor tables was an important optimization
on 32-bit builds, where it avoided mapping and unmapping p2m pages
during a walk.  On 64-bit it makes no difference -- see
http://old-list-archives.xen.org/archives/html/xen-devel/2010-04/msg00981.html
Get rid of it, and use the explicit walk for all lookups.

Signed-off-by: Tim Deegan <tim@xen.org>

diff -r 5691e4cc17da -r a770d1c8448d xen/arch/x86/mm/hap/hap.c
--- a/xen/arch/x86/mm/hap/hap.c	Thu Sep 13 10:23:17 2012 +0200
+++ b/xen/arch/x86/mm/hap/hap.c	Thu Sep 13 15:00:24 2012 +0100
@@ -405,11 +405,6 @@ static void hap_install_xen_entries_in_l
     l4e[l4_table_offset(LINEAR_PT_VIRT_START)] =
         l4e_from_pfn(mfn_x(l4mfn), __PAGE_HYPERVISOR);
 
-    /* Install the domain-specific P2M table */
-    l4e[l4_table_offset(RO_MPT_VIRT_START)] =
-        l4e_from_pfn(mfn_x(pagetable_get_mfn(p2m_get_pagetable(p2m_get_hostp2m(d)))),
-                     __PAGE_HYPERVISOR);
-
     hap_unmap_domain_page(l4e);
 }
 
diff -r 5691e4cc17da -r a770d1c8448d xen/arch/x86/mm/p2m-pt.c
--- a/xen/arch/x86/mm/p2m-pt.c	Thu Sep 13 10:23:17 2012 +0200
+++ b/xen/arch/x86/mm/p2m-pt.c	Thu Sep 13 15:00:24 2012 +0100
@@ -460,186 +460,6 @@ out:
     return rv;
 }
 
-
-/* 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,
-                                    unsigned int *page_order)
-{
-    mfn_t mfn = _mfn(INVALID_MFN);
-    p2m_type_t p2mt = p2m_mmio_dm;
-    paddr_t addr = ((paddr_t)gfn) << PAGE_SHIFT;
-    /* XXX This is for compatibility with the old model, where anything not 
-     * XXX marked as RAM was considered to be emulated MMIO space.
-     * XXX Once we start explicitly registering MMIO regions in the p2m 
-     * XXX we will return p2m_invalid for unmapped gfns */
-
-    l1_pgentry_t l1e = l1e_empty(), *p2m_entry;
-    l2_pgentry_t l2e = l2e_empty();
-    l3_pgentry_t l3e = l3e_empty();
-    int ret;
-
-    ASSERT(gfn < (RO_MPT_VIRT_END - RO_MPT_VIRT_START) 
-           / sizeof(l1_pgentry_t));
-
-    /*
-     * Read & process L3
-     */
-    p2m_entry = (l1_pgentry_t *)
-        &__linear_l2_table[l2_linear_offset(RO_MPT_VIRT_START)
-                           + l3_linear_offset(addr)];
-pod_retry_l3:
-    ret = __copy_from_user(&l3e, p2m_entry, sizeof(l3e));
-
-    if ( ret != 0 || !(l3e_get_flags(l3e) & _PAGE_PRESENT) )
-    {
-        if ( (l3e_get_flags(l3e) & _PAGE_PSE) &&
-             (p2m_flags_to_type(l3e_get_flags(l3e)) == p2m_populate_on_demand) )
-        {
-            /* The read has succeeded, so we know that mapping exists */
-            if ( q & P2M_ALLOC )
-            {
-                if ( !p2m_pod_demand_populate(p2m, gfn, PAGE_ORDER_1G, q) )
-                    goto pod_retry_l3;
-                p2mt = p2m_invalid;
-                gdprintk(XENLOG_ERR, "%s: Allocate 1GB failed!\n", __func__);
-                goto out;
-            }
-            else
-            {
-                p2mt = p2m_populate_on_demand;
-                goto out;
-            }
-        }
-        goto pod_retry_l2;
-    }
-
-    if ( l3e_get_flags(l3e) & _PAGE_PSE )
-    {
-        p2mt = p2m_flags_to_type(l3e_get_flags(l3e));
-        ASSERT(l3e_get_pfn(l3e) != INVALID_MFN || !p2m_is_ram(p2mt));
-        if (p2m_is_valid(p2mt) )
-            mfn = _mfn(l3e_get_pfn(l3e) + 
-                       l2_table_offset(addr) * L1_PAGETABLE_ENTRIES + 
-                       l1_table_offset(addr));
-        else
-            p2mt = p2m_mmio_dm;
-            
-        if ( page_order )
-            *page_order = PAGE_ORDER_1G;
-        goto out;
-    }
-
-    /*
-     * Read & process L2
-     */
-    p2m_entry = &__linear_l1_table[l1_linear_offset(RO_MPT_VIRT_START)
-                                   + l2_linear_offset(addr)];
-
-pod_retry_l2:
-    ret = __copy_from_user(&l2e,
-                           p2m_entry,
-                           sizeof(l2e));
-    if ( ret != 0
-         || !(l2e_get_flags(l2e) & _PAGE_PRESENT) )
-    {
-        if( (l2e_get_flags(l2e) & _PAGE_PSE)
-            && ( p2m_flags_to_type(l2e_get_flags(l2e))
-                 == p2m_populate_on_demand ) )
-        {
-            /* The read has succeeded, so we know that the mapping
-             * exits at this point.  */
-            if ( q & P2M_ALLOC )
-            {
-                if ( !p2m_pod_demand_populate(p2m, gfn, 
-                                                PAGE_ORDER_2M, q) )
-                    goto pod_retry_l2;
-
-                /* Allocate failed. */
-                p2mt = p2m_invalid;
-                printk("%s: Allocate failed!\n", __func__);
-                goto out;
-            }
-            else
-            {
-                p2mt = p2m_populate_on_demand;
-                goto out;
-            }
-        }
-
-        goto pod_retry_l1;
-    }
-        
-    if (l2e_get_flags(l2e) & _PAGE_PSE)
-    {
-        p2mt = p2m_flags_to_type(l2e_get_flags(l2e));
-        ASSERT(l2e_get_pfn(l2e) != INVALID_MFN || !p2m_is_ram(p2mt));
-
-        if ( p2m_is_valid(p2mt) )
-            mfn = _mfn(l2e_get_pfn(l2e) + l1_table_offset(addr));
-        else
-            p2mt = p2m_mmio_dm;
-
-        if ( page_order )
-            *page_order = PAGE_ORDER_2M;
-        goto out;
-    }
-
-    /*
-     * Read and process L1
-     */
-
-    /* Need to __copy_from_user because the p2m is sparse and this
-     * part might not exist */
-pod_retry_l1:
-    p2m_entry = &phys_to_machine_mapping[gfn];
-
-    ret = __copy_from_user(&l1e,
-                           p2m_entry,
-                           sizeof(l1e));
-            
-    if ( ret == 0 ) {
-        unsigned long l1e_mfn = l1e_get_pfn(l1e);
-        p2mt = p2m_flags_to_type(l1e_get_flags(l1e));
-        ASSERT( mfn_valid(_mfn(l1e_mfn)) || !p2m_is_ram(p2mt) ||
-                p2m_is_paging(p2mt) );
-
-        if ( p2mt == p2m_populate_on_demand )
-        {
-            /* The read has succeeded, so we know that the mapping
-             * exits at this point.  */
-            if ( q & P2M_ALLOC )
-            {
-                if ( !p2m_pod_demand_populate(p2m, gfn, 
-                                                PAGE_ORDER_4K, q) )
-                    goto pod_retry_l1;
-
-                /* Allocate failed. */
-                p2mt = p2m_invalid;
-                goto out;
-            }
-            else
-            {
-                p2mt = p2m_populate_on_demand;
-                goto out;
-            }
-        }
-
-        if ( p2m_is_valid(p2mt) || p2m_is_grant(p2mt) )
-            mfn = _mfn(l1e_mfn);
-        else 
-            /* XXX see above */
-            p2mt = p2m_mmio_dm;
-    }
-    
-    if ( page_order )
-        *page_order = PAGE_ORDER_4K;
-out:
-    *t = p2mt;
-    return mfn;
-}
-
 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,
@@ -666,10 +486,6 @@ 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);
 
-    /* Use the fast path with the linear mapping if we can */
-    if ( p2m == p2m_get_hostp2m(current->domain) )
-        return p2m_gfn_to_mfn_current(p2m, gfn, t, a, q, page_order);
-
     mfn = pagetable_get_mfn(p2m_get_pagetable(p2m));
 
     {
@@ -904,17 +720,10 @@ long p2m_pt_audit_p2m(struct p2m_domain 
 {
     unsigned long entry_count = 0, pmbad = 0;
     unsigned long mfn, gfn, m2pfn;
-    int test_linear;
-    struct domain *d = p2m->domain;
 
     ASSERT(p2m_locked_by_me(p2m));
     ASSERT(pod_locked_by_me(p2m));
 
-    test_linear = ( (d == current->domain)
-                    && !pagetable_is_null(current->arch.monitor_table) );
-    if ( test_linear )
-        flush_tlb_local();
-
     /* Audit part one: walk the domain's p2m table, checking the entries. */
     if ( pagetable_get_pfn(p2m_get_pagetable(p2m)) != 0 )
     {
diff -r 5691e4cc17da -r a770d1c8448d xen/arch/x86/mm/shadow/multi.c
--- a/xen/arch/x86/mm/shadow/multi.c	Thu Sep 13 10:23:17 2012 +0200
+++ b/xen/arch/x86/mm/shadow/multi.c	Thu Sep 13 15:00:24 2012 +0100
@@ -1472,14 +1472,6 @@ void sh_install_xen_entries_in_l4(struct
             shadow_l4e_from_mfn(gl4mfn, __PAGE_HYPERVISOR);
     }
 
-    if ( shadow_mode_translate(v->domain) )
-    {
-        /* install domain-specific P2M table */
-        sl4e[shadow_l4_table_offset(RO_MPT_VIRT_START)] =
-            shadow_l4e_from_mfn(pagetable_get_mfn(p2m_get_pagetable(p2m_get_hostp2m(d))),
-                                __PAGE_HYPERVISOR);
-    }
-
     sh_unmap_domain_page(sl4e);    
 }
 #endif
diff -r 5691e4cc17da -r a770d1c8448d xen/include/asm-x86/p2m.h
--- a/xen/include/asm-x86/p2m.h	Thu Sep 13 10:23:17 2012 +0200
+++ b/xen/include/asm-x86/p2m.h	Thu Sep 13 15:00:24 2012 +0100
@@ -35,22 +35,6 @@
 extern bool_t opt_hap_1gb, opt_hap_2mb;
 
 /*
- * The phys_to_machine_mapping maps guest physical frame numbers 
- * to machine frame numbers.  It only exists for paging_mode_translate 
- * guests. It is organised in page-table format, which:
- *
- * (1) allows us to use it directly as the second pagetable in hardware-
- *     assisted paging and (hopefully) iommu support; and 
- * (2) lets us map it directly into the guest vcpus' virtual address space 
- *     as a linear pagetable, so we can read and write it easily.
- *
- * For (2) we steal the address space that would have normally been used
- * by the read-only MPT map in a non-translated guest.  (For 
- * paging_mode_external() guests this mapping is in the monitor table.)
- */
-#define phys_to_machine_mapping ((l1_pgentry_t *)RO_MPT_VIRT_START)
-
-/*
  * The upper levels of the p2m pagetable always contain full rights; all 
  * variation in the access control bits is made in the level-1 PTEs.
  * 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 13 14:03:22 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Sep 2012 14:03:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TCA0b-0000dZ-Um; Thu, 13 Sep 2012 14:03: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 1TCA0a-0000dI-Qo
	for xen-devel@lists.xen.org; Thu, 13 Sep 2012 14:03:09 +0000
Received: from [85.158.138.51:37627] by server-4.bemta-3.messagelabs.com id
	83/B8-24831-B97E1505; Thu, 13 Sep 2012 14:03:07 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1347544987!11716012!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQxMjE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31902 invoked from network); 13 Sep 2012 14:03:07 -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;
	13 Sep 2012 14:03:07 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 13 Sep 2012 15:03:07 +0100
Message-Id: <505203F0020000780009B12B@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 13 Sep 2012 15:04:00 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Paolo Bonzini" <pbonzini@redhat.com>
References: <CAFw--Dd0k7L+T_UJc0yHAkUGrY_-GDHaQjK3OM-1UdOp=J-wAQ@mail.gmail.com>
	<20120907085036.GA71093@ocelot.phlegethon.org>
	<5049E2C70200007800099B21@nat28.tlf.novell.com>
	<20120913101120.GA12881@ocelot.phlegethon.org>
	<5051E531020000780009B083@nat28.tlf.novell.com>
	<5051D440.4000007@redhat.com>
In-Reply-To: <5051D440.4000007@redhat.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Tim Deegan <tim@xen.org>, Jeffrey Karrels <karrelsj@gmail.com>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Clang/LLVM version requirements
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.09.12 at 14:40, Paolo Bonzini <pbonzini@redhat.com> wrote:
> Il 13/09/2012 13:52, Jan Beulich ha scritto:
>> 
>> So the patch is fine by me if it covers that misalignment case.
>> But it seems a little heavy handed - I'd think that instead of the
>> sub-section, we could just create an arbitrary other section, or
>> even allow uninitialized variable (it's unclear to me why Paolo
>> wrote the comment - in c/s 25479:61dfb3da56b - regarding BSS
>> the way it is now) - after all we only need to make sure that
>> - the space gets properly allocated in trampoline.S, i.e. also in
>>   reloc.bin
>> - all accesses are PC-relative
>> Neither has anything to do with use of uninitialized variables.
> 
> We cannot use BSS because it doesn't appear in reloc.S.

That, imo, would be a binutils bug.

Jan

> Apart from BSS, there would be no benefit for reloc to move itself to
> BOOT_TRAMPOLINE, because BOOT_TRAMPOLINE is not a known location
> anymore.  So it was easier to just run it in place from where we put it,
> in the middle of head.S, but this means BSS disappears after extracting
> reloc.bin.
> 
> So it's not really because the code must be relocatable, but more
> because of the way we extract the binary data and put it in the middle
> of head.S.
> 
> Initialized data works as long as you pass -fno-zero-initialized-in-bss
> to the compiler or it is eaten.  I used assembly to declare the alloc
> variable, because I wasn't sure of which GCC versions need the option,
> and whether older versions are supported for compiling Xen.
> 
> Paolo




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 13 14:03:22 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Sep 2012 14:03:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TCA0b-0000dZ-Um; Thu, 13 Sep 2012 14:03: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 1TCA0a-0000dI-Qo
	for xen-devel@lists.xen.org; Thu, 13 Sep 2012 14:03:09 +0000
Received: from [85.158.138.51:37627] by server-4.bemta-3.messagelabs.com id
	83/B8-24831-B97E1505; Thu, 13 Sep 2012 14:03:07 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1347544987!11716012!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQxMjE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31902 invoked from network); 13 Sep 2012 14:03:07 -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;
	13 Sep 2012 14:03:07 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 13 Sep 2012 15:03:07 +0100
Message-Id: <505203F0020000780009B12B@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 13 Sep 2012 15:04:00 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Paolo Bonzini" <pbonzini@redhat.com>
References: <CAFw--Dd0k7L+T_UJc0yHAkUGrY_-GDHaQjK3OM-1UdOp=J-wAQ@mail.gmail.com>
	<20120907085036.GA71093@ocelot.phlegethon.org>
	<5049E2C70200007800099B21@nat28.tlf.novell.com>
	<20120913101120.GA12881@ocelot.phlegethon.org>
	<5051E531020000780009B083@nat28.tlf.novell.com>
	<5051D440.4000007@redhat.com>
In-Reply-To: <5051D440.4000007@redhat.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Tim Deegan <tim@xen.org>, Jeffrey Karrels <karrelsj@gmail.com>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Clang/LLVM version requirements
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.09.12 at 14:40, Paolo Bonzini <pbonzini@redhat.com> wrote:
> Il 13/09/2012 13:52, Jan Beulich ha scritto:
>> 
>> So the patch is fine by me if it covers that misalignment case.
>> But it seems a little heavy handed - I'd think that instead of the
>> sub-section, we could just create an arbitrary other section, or
>> even allow uninitialized variable (it's unclear to me why Paolo
>> wrote the comment - in c/s 25479:61dfb3da56b - regarding BSS
>> the way it is now) - after all we only need to make sure that
>> - the space gets properly allocated in trampoline.S, i.e. also in
>>   reloc.bin
>> - all accesses are PC-relative
>> Neither has anything to do with use of uninitialized variables.
> 
> We cannot use BSS because it doesn't appear in reloc.S.

That, imo, would be a binutils bug.

Jan

> Apart from BSS, there would be no benefit for reloc to move itself to
> BOOT_TRAMPOLINE, because BOOT_TRAMPOLINE is not a known location
> anymore.  So it was easier to just run it in place from where we put it,
> in the middle of head.S, but this means BSS disappears after extracting
> reloc.bin.
> 
> So it's not really because the code must be relocatable, but more
> because of the way we extract the binary data and put it in the middle
> of head.S.
> 
> Initialized data works as long as you pass -fno-zero-initialized-in-bss
> to the compiler or it is eaten.  I used assembly to declare the alloc
> variable, because I wasn't sure of which GCC versions need the option,
> and whether older versions are supported for compiling Xen.
> 
> Paolo




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 13 14:04:02 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Sep 2012 14: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 1TCA1K-0000ki-CE; Thu, 13 Sep 2012 14:03:54 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1TCA1J-0000jp-5g
	for xen-devel@lists.xen.org; Thu, 13 Sep 2012 14:03:53 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-9.tower-27.messagelabs.com!1347544915!9621769!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNjkyOTk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29516 invoked from network); 13 Sep 2012 14:01:57 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Sep 2012 14:01:57 -0000
X-IronPort-AV: E=Sophos;i="4.80,417,1344211200"; d="scan'208";a="37748439"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Sep 2012 14:01:52 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1;
	Thu, 13 Sep 2012 10:01:52 -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 1TC9zL-00030C-Jj	for xen-devel@lists.xen.org;
	Thu, 13 Sep 2012 15:01:51 +0100
Received: from tdeegan by whitby.uk.xensource.com with local (Exim 4.76)
	(envelope-from <tim@xen.org>)	id 1TC9zL-0006om-AV	for
	xen-devel@lists.xen.org; Thu, 13 Sep 2012 15:01:51 +0100
MIME-Version: 1.0
X-Mercurial-Node: 9e46d90d0182979a7220314ca19d2525e338aa5d
Message-ID: <9e46d90d0182979a7220.1347544910@whitby.uk.xensource.com>
User-Agent: Mercurial-patchbomb/2.0.1
Date: Thu, 13 Sep 2012 15:01:50 +0100
From: Tim Deegan <tim@xen.org>
To: xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH] x86/mm: Update comments now that Xen is always
	64-bit
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

# HG changeset patch
# User Tim Deegan <tim@xen.org>
# Date 1347544826 -3600
# Node ID 9e46d90d0182979a7220314ca19d2525e338aa5d
# Parent  a770d1c8448d73ccf2ec36a5322532c2e3c14641
x86/mm: Update comments now that Xen is always 64-bit.

Signed-off-by: Tim Deegan <tim@xen.org>

diff -r a770d1c8448d -r 9e46d90d0182 xen/arch/x86/mm/shadow/common.c
--- a/xen/arch/x86/mm/shadow/common.c	Thu Sep 13 15:00:24 2012 +0100
+++ b/xen/arch/x86/mm/shadow/common.c	Thu Sep 13 15:00:26 2012 +0100
@@ -1178,19 +1178,19 @@ int shadow_cmpxchg_guest_entry(struct vc
  *    
  * This table shows the allocation behaviour of the different modes:
  *
- * Xen paging      pae  pae  64b  64b  64b
- * Guest paging    32b  pae  32b  pae  64b
- * PV or HVM       HVM   *   HVM  HVM   * 
- * Shadow paging   pae  pae  pae  pae  64b
+ * Xen paging      64b  64b  64b
+ * Guest paging    32b  pae  64b
+ * PV or HVM       HVM  HVM   * 
+ * Shadow paging   pae  pae  64b
  *
- * sl1 size         8k   4k   8k   4k   4k
- * sl2 size        16k   4k  16k   4k   4k
- * sl3 size         -    -    -    -    4k
- * sl4 size         -    -    -    -    4k
+ * sl1 size         8k   4k   4k
+ * sl2 size        16k   4k   4k
+ * sl3 size         -    -    4k
+ * sl4 size         -    -    4k
  *
  * In HVM guests, the p2m table is built out of shadow pages, and we provide 
  * a function for the p2m management to steal pages, in max-order chunks, from 
- * the free pool.  We don't provide for giving them back, yet.
+ * the free pool.
  */
 
 /* Figure out the least acceptable quantity of shadow memory.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 13 14:04:02 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Sep 2012 14: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 1TCA1K-0000ki-CE; Thu, 13 Sep 2012 14:03:54 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1TCA1J-0000jp-5g
	for xen-devel@lists.xen.org; Thu, 13 Sep 2012 14:03:53 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-9.tower-27.messagelabs.com!1347544915!9621769!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNjkyOTk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29516 invoked from network); 13 Sep 2012 14:01:57 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Sep 2012 14:01:57 -0000
X-IronPort-AV: E=Sophos;i="4.80,417,1344211200"; d="scan'208";a="37748439"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Sep 2012 14:01:52 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1;
	Thu, 13 Sep 2012 10:01:52 -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 1TC9zL-00030C-Jj	for xen-devel@lists.xen.org;
	Thu, 13 Sep 2012 15:01:51 +0100
Received: from tdeegan by whitby.uk.xensource.com with local (Exim 4.76)
	(envelope-from <tim@xen.org>)	id 1TC9zL-0006om-AV	for
	xen-devel@lists.xen.org; Thu, 13 Sep 2012 15:01:51 +0100
MIME-Version: 1.0
X-Mercurial-Node: 9e46d90d0182979a7220314ca19d2525e338aa5d
Message-ID: <9e46d90d0182979a7220.1347544910@whitby.uk.xensource.com>
User-Agent: Mercurial-patchbomb/2.0.1
Date: Thu, 13 Sep 2012 15:01:50 +0100
From: Tim Deegan <tim@xen.org>
To: xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH] x86/mm: Update comments now that Xen is always
	64-bit
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

# HG changeset patch
# User Tim Deegan <tim@xen.org>
# Date 1347544826 -3600
# Node ID 9e46d90d0182979a7220314ca19d2525e338aa5d
# Parent  a770d1c8448d73ccf2ec36a5322532c2e3c14641
x86/mm: Update comments now that Xen is always 64-bit.

Signed-off-by: Tim Deegan <tim@xen.org>

diff -r a770d1c8448d -r 9e46d90d0182 xen/arch/x86/mm/shadow/common.c
--- a/xen/arch/x86/mm/shadow/common.c	Thu Sep 13 15:00:24 2012 +0100
+++ b/xen/arch/x86/mm/shadow/common.c	Thu Sep 13 15:00:26 2012 +0100
@@ -1178,19 +1178,19 @@ int shadow_cmpxchg_guest_entry(struct vc
  *    
  * This table shows the allocation behaviour of the different modes:
  *
- * Xen paging      pae  pae  64b  64b  64b
- * Guest paging    32b  pae  32b  pae  64b
- * PV or HVM       HVM   *   HVM  HVM   * 
- * Shadow paging   pae  pae  pae  pae  64b
+ * Xen paging      64b  64b  64b
+ * Guest paging    32b  pae  64b
+ * PV or HVM       HVM  HVM   * 
+ * Shadow paging   pae  pae  64b
  *
- * sl1 size         8k   4k   8k   4k   4k
- * sl2 size        16k   4k  16k   4k   4k
- * sl3 size         -    -    -    -    4k
- * sl4 size         -    -    -    -    4k
+ * sl1 size         8k   4k   4k
+ * sl2 size        16k   4k   4k
+ * sl3 size         -    -    4k
+ * sl4 size         -    -    4k
  *
  * In HVM guests, the p2m table is built out of shadow pages, and we provide 
  * a function for the p2m management to steal pages, in max-order chunks, from 
- * the free pool.  We don't provide for giving them back, yet.
+ * the free pool.
  */
 
 /* Figure out the least acceptable quantity of shadow memory.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 13 14:05:52 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Sep 2012 14: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 1TCA34-0000yh-Sk; Thu, 13 Sep 2012 14:05:42 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ronghui.duan@intel.com>) id 1TCA33-0000yT-5Q
	for xen-devel@lists.xen.org; Thu, 13 Sep 2012 14:05:41 +0000
Received: from [85.158.143.99:28420] by server-1.bemta-4.messagelabs.com id
	88/96-12504-438E1505; Thu, 13 Sep 2012 14:05:40 +0000
X-Env-Sender: ronghui.duan@intel.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1347545137!22071280!1
X-Originating-IP: [192.55.52.93]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjkzID0+IDM0NjI4NQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8915 invoked from network); 13 Sep 2012 14:05:38 -0000
Received: from mga11.intel.com (HELO mga11.intel.com) (192.55.52.93)
	by server-12.tower-216.messagelabs.com with SMTP;
	13 Sep 2012 14:05:38 -0000
Received: from fmsmga002.fm.intel.com ([10.253.24.26])
	by fmsmga102.fm.intel.com with ESMTP; 13 Sep 2012 07:05:36 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.80,417,1344236400"; d="scan'208";a="221577628"
Received: from fmsmsx104.amr.corp.intel.com ([10.19.9.35])
	by fmsmga002.fm.intel.com with ESMTP; 13 Sep 2012 07:05:36 -0700
Received: from fmsmsx151.amr.corp.intel.com (10.19.17.220) by
	FMSMSX104.amr.corp.intel.com (10.19.9.35) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Thu, 13 Sep 2012 07:05:36 -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, 13 Sep 2012 07:05:35 -0700
Received: from shsmsx102.ccr.corp.intel.com ([169.254.2.92]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.175]) with mapi id
	14.01.0355.002; Thu, 13 Sep 2012 22:05:34 +0800
From: "Duan, Ronghui" <ronghui.duan@intel.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>, Stefano Stabellini
	<stefano.stabellini@eu.citrix.com>
Thread-Topic: [Xen-devel] [RFC v1 0/5] VBD: enlarge max segment per request
	in blkfront
Thread-Index: Ac17mRnxOUx7HczFSN2/QYn7Hm+BlQRRPS0AAR4vKmD//9A5gIAAO3mAgAAmkYD//2/KAA==
Date: Thu, 13 Sep 2012 14:05:34 +0000
Message-ID: <A21691DE07B84740B5F0B81466D5148A23BF6C1D@SHSMSX102.ccr.corp.intel.com>
References: <A21691DE07B84740B5F0B81466D5148A23BCF1DF@SHSMSX102.ccr.corp.intel.com>
	<20120907174922.GA13040@phenom.dumpdata.com>
	<A21691DE07B84740B5F0B81466D5148A23BF6833@SHSMSX102.ccr.corp.intel.com>
	<5051A83B020000780009AF93@nat28.tlf.novell.com>
	<alpine.DEB.2.02.1209131203270.15568@kaball.uk.xensource.com>
	<20120913132335.GD16635@localhost.localdomain>
In-Reply-To: <20120913132335.GD16635@localhost.localdomain>
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 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] [RFC v1 0/5] VBD: enlarge max segment per request
 in blkfront
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> > > But you certainly shouldn't be proposing features getting used
> > > unconditionally or by default that benefit one class of backing
> > > devices and severely penalize others.
> >
> > Right.
> > I am wondering.. Considering that the in-kernel blkback is mainly used
> > with physical partitions, is it possible that your patches cause a
> > regression with unmodified backends that don't support the new
> > protocol, like QEMU for example?
> 
> Well for right now I am just using the most simple configuration to eliminate any
> extra variables (stacking of components). So my "testing" has been just on
> phy:/dev/sda,xvda,w with the sda being a Corsair SSD.

I totally agree that we should not break others when enable what we want. 
But just from my mind, the patch only have a little overhead in the front/backend code path. It will induce pure random IO with a little overhead.
I tried the 4K read case, I just got 50MB/s w/o the patch. I need a more powerful disk to verified it.

Ronghui


> -----Original Message-----
> From: Konrad Rzeszutek Wilk [mailto:konrad.wilk@oracle.com]
> Sent: Thursday, September 13, 2012 9:24 PM
> To: Stefano Stabellini
> Cc: Jan Beulich; Duan, Ronghui; Ian Jackson; xen-devel@lists.xen.org
> Subject: Re: [Xen-devel] [RFC v1 0/5] VBD: enlarge max segment per request in
> blkfront
> 
> On Thu, Sep 13, 2012 at 12:05:35PM +0100, Stefano Stabellini wrote:
> > On Thu, 13 Sep 2012, Jan Beulich wrote:
> > > >>> On 13.09.12 at 04:28, "Duan, Ronghui" <ronghui.duan@intel.com> wrote:
> > > >> And with your patch got:
> > > >>   read : io=4096.0MB, bw=92606KB/s, iops=23151 , runt= 45292msec
> > > >>
> > > >> without:
> > > >>   read : io=4096.0MB, bw=145187KB/s, iops=36296 , runt= 28889msec
> > > >>
> > > > What type of backend file you are using? In order to remove the
> > > > influence of cache in Dom0, I use a physical partition as backend.
> > >
> > > But you certainly shouldn't be proposing features getting used
> > > unconditionally or by default that benefit one class of backing
> > > devices and severely penalize others.
> >
> > Right.
> > I am wondering.. Considering that the in-kernel blkback is mainly used
> > with physical partitions, is it possible that your patches cause a
> > regression with unmodified backends that don't support the new
> > protocol, like QEMU for example?
> 
> Well for right now I am just using the most simple configuration to eliminate any
> extra variables (stacking of components). So my "testing" has been just on
> phy:/dev/sda,xvda,w with the sda being a Corsair SSD.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 13 14:05:52 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Sep 2012 14: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 1TCA34-0000yh-Sk; Thu, 13 Sep 2012 14:05:42 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ronghui.duan@intel.com>) id 1TCA33-0000yT-5Q
	for xen-devel@lists.xen.org; Thu, 13 Sep 2012 14:05:41 +0000
Received: from [85.158.143.99:28420] by server-1.bemta-4.messagelabs.com id
	88/96-12504-438E1505; Thu, 13 Sep 2012 14:05:40 +0000
X-Env-Sender: ronghui.duan@intel.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1347545137!22071280!1
X-Originating-IP: [192.55.52.93]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjkzID0+IDM0NjI4NQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8915 invoked from network); 13 Sep 2012 14:05:38 -0000
Received: from mga11.intel.com (HELO mga11.intel.com) (192.55.52.93)
	by server-12.tower-216.messagelabs.com with SMTP;
	13 Sep 2012 14:05:38 -0000
Received: from fmsmga002.fm.intel.com ([10.253.24.26])
	by fmsmga102.fm.intel.com with ESMTP; 13 Sep 2012 07:05:36 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.80,417,1344236400"; d="scan'208";a="221577628"
Received: from fmsmsx104.amr.corp.intel.com ([10.19.9.35])
	by fmsmga002.fm.intel.com with ESMTP; 13 Sep 2012 07:05:36 -0700
Received: from fmsmsx151.amr.corp.intel.com (10.19.17.220) by
	FMSMSX104.amr.corp.intel.com (10.19.9.35) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Thu, 13 Sep 2012 07:05:36 -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, 13 Sep 2012 07:05:35 -0700
Received: from shsmsx102.ccr.corp.intel.com ([169.254.2.92]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.175]) with mapi id
	14.01.0355.002; Thu, 13 Sep 2012 22:05:34 +0800
From: "Duan, Ronghui" <ronghui.duan@intel.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>, Stefano Stabellini
	<stefano.stabellini@eu.citrix.com>
Thread-Topic: [Xen-devel] [RFC v1 0/5] VBD: enlarge max segment per request
	in blkfront
Thread-Index: Ac17mRnxOUx7HczFSN2/QYn7Hm+BlQRRPS0AAR4vKmD//9A5gIAAO3mAgAAmkYD//2/KAA==
Date: Thu, 13 Sep 2012 14:05:34 +0000
Message-ID: <A21691DE07B84740B5F0B81466D5148A23BF6C1D@SHSMSX102.ccr.corp.intel.com>
References: <A21691DE07B84740B5F0B81466D5148A23BCF1DF@SHSMSX102.ccr.corp.intel.com>
	<20120907174922.GA13040@phenom.dumpdata.com>
	<A21691DE07B84740B5F0B81466D5148A23BF6833@SHSMSX102.ccr.corp.intel.com>
	<5051A83B020000780009AF93@nat28.tlf.novell.com>
	<alpine.DEB.2.02.1209131203270.15568@kaball.uk.xensource.com>
	<20120913132335.GD16635@localhost.localdomain>
In-Reply-To: <20120913132335.GD16635@localhost.localdomain>
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 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] [RFC v1 0/5] VBD: enlarge max segment per request
 in blkfront
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> > > But you certainly shouldn't be proposing features getting used
> > > unconditionally or by default that benefit one class of backing
> > > devices and severely penalize others.
> >
> > Right.
> > I am wondering.. Considering that the in-kernel blkback is mainly used
> > with physical partitions, is it possible that your patches cause a
> > regression with unmodified backends that don't support the new
> > protocol, like QEMU for example?
> 
> Well for right now I am just using the most simple configuration to eliminate any
> extra variables (stacking of components). So my "testing" has been just on
> phy:/dev/sda,xvda,w with the sda being a Corsair SSD.

I totally agree that we should not break others when enable what we want. 
But just from my mind, the patch only have a little overhead in the front/backend code path. It will induce pure random IO with a little overhead.
I tried the 4K read case, I just got 50MB/s w/o the patch. I need a more powerful disk to verified it.

Ronghui


> -----Original Message-----
> From: Konrad Rzeszutek Wilk [mailto:konrad.wilk@oracle.com]
> Sent: Thursday, September 13, 2012 9:24 PM
> To: Stefano Stabellini
> Cc: Jan Beulich; Duan, Ronghui; Ian Jackson; xen-devel@lists.xen.org
> Subject: Re: [Xen-devel] [RFC v1 0/5] VBD: enlarge max segment per request in
> blkfront
> 
> On Thu, Sep 13, 2012 at 12:05:35PM +0100, Stefano Stabellini wrote:
> > On Thu, 13 Sep 2012, Jan Beulich wrote:
> > > >>> On 13.09.12 at 04:28, "Duan, Ronghui" <ronghui.duan@intel.com> wrote:
> > > >> And with your patch got:
> > > >>   read : io=4096.0MB, bw=92606KB/s, iops=23151 , runt= 45292msec
> > > >>
> > > >> without:
> > > >>   read : io=4096.0MB, bw=145187KB/s, iops=36296 , runt= 28889msec
> > > >>
> > > > What type of backend file you are using? In order to remove the
> > > > influence of cache in Dom0, I use a physical partition as backend.
> > >
> > > But you certainly shouldn't be proposing features getting used
> > > unconditionally or by default that benefit one class of backing
> > > devices and severely penalize others.
> >
> > Right.
> > I am wondering.. Considering that the in-kernel blkback is mainly used
> > with physical partitions, is it possible that your patches cause a
> > regression with unmodified backends that don't support the new
> > protocol, like QEMU for example?
> 
> Well for right now I am just using the most simple configuration to eliminate any
> extra variables (stacking of components). So my "testing" has been just on
> phy:/dev/sda,xvda,w with the sda being a Corsair SSD.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 13 14:13:27 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Sep 2012 14:13:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TCAAO-0001HU-R2; Thu, 13 Sep 2012 14:13:16 +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 1TCAAO-0001HM-3S
	for xen-devel@lists.xen.org; Thu, 13 Sep 2012 14:13:16 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1347545567!9794809!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQxMjE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14336 invoked from network); 13 Sep 2012 14:12:47 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-13.tower-27.messagelabs.com with SMTP;
	13 Sep 2012 14:12:47 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 13 Sep 2012 15:12:47 +0100
Message-Id: <50520634020000780009B162@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 13 Sep 2012 15:13:40 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Daniel De Graaf" <dgdegra@tycho.nsa.gov>
References: <1347465586-20009-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1347465586-20009-20-git-send-email-dgdegra@tycho.nsa.gov>
	<5051AED7020000780009AFC3@nat28.tlf.novell.com>
	<5051E3AC.2060700@tycho.nsa.gov>
In-Reply-To: <5051E3AC.2060700@tycho.nsa.gov>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Tim Deegan <tim@xen.org>, Keir Fraser <keir@xen.org>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 19/22] arch/x86: check remote MMIO remap
 permissions
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.09.12 at 15:46, Daniel De Graaf <dgdegra@tycho.nsa.gov> wrote:
> On 09/13/2012 04:00 AM, Jan Beulich wrote:
>>>>> On 12.09.12 at 17:59, Daniel De Graaf <dgdegra@tycho.nsa.gov> wrote:
>>> When a domain is mapping pages from a different pg_owner domain, the
>>> iomem_access checks are currently only applied to the pg_owner domain,
>>> potentially allowing the current domain to bypass its more restrictive
>>> iomem_access policy using another domain that it has access to.
>> 
>> Are you sure about this? I ask because ...
>> 
>>> --- a/xen/arch/x86/mm.c
>>> +++ b/xen/arch/x86/mm.c
>>> @@ -754,6 +754,18 @@ get_page_from_l1e(
>>>              return -EINVAL;
>>>          }
>>>  
>>> +        if ( pg_owner != curr->domain &&
>>> +             !iomem_access_permitted(curr->domain, mfn, mfn) )
>>> +        {
>>> +            if ( mfn != (PADDR_MASK >> PAGE_SHIFT) ) /* INVALID_MFN? */
>>> +            {
>>> +                MEM_LOG("Domain %u attempted to map I/O space %08lx in 
> domain %u",
>>> +                        curr->domain->domain_id, mfn, pg_owner->domain_id);
>>> +                return -EPERM;
>>> +            }
>>> +            return -EINVAL;
>>> +        }
>>> +
>> 
>> ... the place you insert this is after non-RAM pages got filtered
>> out already, so you're applying an IOMEM permission check to a
>> RAM page.
>> 
>> Jan
>> 
>>>          if ( !(l1f & _PAGE_RW) ||
>>>               !rangeset_contains_singleton(mmio_ro_ranges, mfn) )
>>>              return 0;
> 
> If that's true, then the check a few lines above is also applying IOMEM
> checks to RAM pages. I can see non-privileged attempts being filtered
> above,

I can't see how that would happen given this primary conditional

    if ( !mfn_valid(mfn) ||
         (real_pg_owner = page_get_owner_and_reference(page)) == dom_io )

Please clarify what you're observing.

> but successful mappings will continue to the check I added.

Of course. I would think that if anything, you would want to add
a second call to iomem_access_permitted() with "curr->domain"
right at the place where the current one is (in particular inside
the above quoted conditional).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 13 14:13:27 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Sep 2012 14:13:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TCAAO-0001HU-R2; Thu, 13 Sep 2012 14:13:16 +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 1TCAAO-0001HM-3S
	for xen-devel@lists.xen.org; Thu, 13 Sep 2012 14:13:16 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1347545567!9794809!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQxMjE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14336 invoked from network); 13 Sep 2012 14:12:47 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-13.tower-27.messagelabs.com with SMTP;
	13 Sep 2012 14:12:47 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 13 Sep 2012 15:12:47 +0100
Message-Id: <50520634020000780009B162@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 13 Sep 2012 15:13:40 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Daniel De Graaf" <dgdegra@tycho.nsa.gov>
References: <1347465586-20009-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1347465586-20009-20-git-send-email-dgdegra@tycho.nsa.gov>
	<5051AED7020000780009AFC3@nat28.tlf.novell.com>
	<5051E3AC.2060700@tycho.nsa.gov>
In-Reply-To: <5051E3AC.2060700@tycho.nsa.gov>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Tim Deegan <tim@xen.org>, Keir Fraser <keir@xen.org>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 19/22] arch/x86: check remote MMIO remap
 permissions
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.09.12 at 15:46, Daniel De Graaf <dgdegra@tycho.nsa.gov> wrote:
> On 09/13/2012 04:00 AM, Jan Beulich wrote:
>>>>> On 12.09.12 at 17:59, Daniel De Graaf <dgdegra@tycho.nsa.gov> wrote:
>>> When a domain is mapping pages from a different pg_owner domain, the
>>> iomem_access checks are currently only applied to the pg_owner domain,
>>> potentially allowing the current domain to bypass its more restrictive
>>> iomem_access policy using another domain that it has access to.
>> 
>> Are you sure about this? I ask because ...
>> 
>>> --- a/xen/arch/x86/mm.c
>>> +++ b/xen/arch/x86/mm.c
>>> @@ -754,6 +754,18 @@ get_page_from_l1e(
>>>              return -EINVAL;
>>>          }
>>>  
>>> +        if ( pg_owner != curr->domain &&
>>> +             !iomem_access_permitted(curr->domain, mfn, mfn) )
>>> +        {
>>> +            if ( mfn != (PADDR_MASK >> PAGE_SHIFT) ) /* INVALID_MFN? */
>>> +            {
>>> +                MEM_LOG("Domain %u attempted to map I/O space %08lx in 
> domain %u",
>>> +                        curr->domain->domain_id, mfn, pg_owner->domain_id);
>>> +                return -EPERM;
>>> +            }
>>> +            return -EINVAL;
>>> +        }
>>> +
>> 
>> ... the place you insert this is after non-RAM pages got filtered
>> out already, so you're applying an IOMEM permission check to a
>> RAM page.
>> 
>> Jan
>> 
>>>          if ( !(l1f & _PAGE_RW) ||
>>>               !rangeset_contains_singleton(mmio_ro_ranges, mfn) )
>>>              return 0;
> 
> If that's true, then the check a few lines above is also applying IOMEM
> checks to RAM pages. I can see non-privileged attempts being filtered
> above,

I can't see how that would happen given this primary conditional

    if ( !mfn_valid(mfn) ||
         (real_pg_owner = page_get_owner_and_reference(page)) == dom_io )

Please clarify what you're observing.

> but successful mappings will continue to the check I added.

Of course. I would think that if anything, you would want to add
a second call to iomem_access_permitted() with "curr->domain"
right at the place where the current one is (in particular inside
the above quoted conditional).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 13 14:13:59 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Sep 2012 14: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 1TCAAs-0001Ja-88; Thu, 13 Sep 2012 14:13:46 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <pbonzini@redhat.com>) id 1TCAAr-0001JQ-3G
	for xen-devel@lists.xen.org; Thu, 13 Sep 2012 14:13:45 +0000
Received: from [85.158.143.35:55159] by server-3.bemta-4.messagelabs.com id
	53/D6-08232-81AE1505; Thu, 13 Sep 2012 14:13:44 +0000
X-Env-Sender: pbonzini@redhat.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1347545623!18183506!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTY3MDI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22975 invoked from network); 13 Sep 2012 14:13:43 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-14.tower-21.messagelabs.com with SMTP;
	13 Sep 2012 14:13:43 -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 q8DEDeLP029225
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 13 Sep 2012 10:13:40 -0400
Received: from yakj.usersys.redhat.com (ovpn-112-23.ams2.redhat.com
	[10.36.112.23])
	by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id q8DEDc7k002882; Thu, 13 Sep 2012 10:13:38 -0400
Message-ID: <5051EA11.4080907@redhat.com>
Date: Thu, 13 Sep 2012 16:13:37 +0200
From: Paolo Bonzini <pbonzini@redhat.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120828 Thunderbird/15.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <CAFw--Dd0k7L+T_UJc0yHAkUGrY_-GDHaQjK3OM-1UdOp=J-wAQ@mail.gmail.com>
	<20120907085036.GA71093@ocelot.phlegethon.org>
	<5049E2C70200007800099B21@nat28.tlf.novell.com>
	<20120913101120.GA12881@ocelot.phlegethon.org>
	<5051E531020000780009B083@nat28.tlf.novell.com>
	<5051D440.4000007@redhat.com>
	<505203F0020000780009B12B@nat28.tlf.novell.com>
In-Reply-To: <505203F0020000780009B12B@nat28.tlf.novell.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23
Cc: Tim Deegan <tim@xen.org>, Jeffrey Karrels <karrelsj@gmail.com>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Clang/LLVM version requirements
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Il 13/09/2012 16:04, Jan Beulich ha scritto:
>>> >> So the patch is fine by me if it covers that misalignment case.
>>> >> But it seems a little heavy handed - I'd think that instead of the
>>> >> sub-section, we could just create an arbitrary other section, or
>>> >> even allow uninitialized variable (it's unclear to me why Paolo
>>> >> wrote the comment - in c/s 25479:61dfb3da56b - regarding BSS
>>> >> the way it is now) - after all we only need to make sure that
>>> >> - the space gets properly allocated in trampoline.S, i.e. also in
>>> >>   reloc.bin
>>> >> - all accesses are PC-relative
>>> >> Neither has anything to do with use of uninitialized variables.
>> > 
>> > We cannot use BSS because it doesn't appear in reloc.S.
> That, imo, would be a binutils bug.

It's just because the flags say so.  Tim's flag magic should do it (my
reply crossed with his).

Paolo

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 13 14:13:59 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Sep 2012 14: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 1TCAAs-0001Ja-88; Thu, 13 Sep 2012 14:13:46 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <pbonzini@redhat.com>) id 1TCAAr-0001JQ-3G
	for xen-devel@lists.xen.org; Thu, 13 Sep 2012 14:13:45 +0000
Received: from [85.158.143.35:55159] by server-3.bemta-4.messagelabs.com id
	53/D6-08232-81AE1505; Thu, 13 Sep 2012 14:13:44 +0000
X-Env-Sender: pbonzini@redhat.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1347545623!18183506!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTY3MDI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22975 invoked from network); 13 Sep 2012 14:13:43 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-14.tower-21.messagelabs.com with SMTP;
	13 Sep 2012 14:13:43 -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 q8DEDeLP029225
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 13 Sep 2012 10:13:40 -0400
Received: from yakj.usersys.redhat.com (ovpn-112-23.ams2.redhat.com
	[10.36.112.23])
	by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id q8DEDc7k002882; Thu, 13 Sep 2012 10:13:38 -0400
Message-ID: <5051EA11.4080907@redhat.com>
Date: Thu, 13 Sep 2012 16:13:37 +0200
From: Paolo Bonzini <pbonzini@redhat.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120828 Thunderbird/15.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <CAFw--Dd0k7L+T_UJc0yHAkUGrY_-GDHaQjK3OM-1UdOp=J-wAQ@mail.gmail.com>
	<20120907085036.GA71093@ocelot.phlegethon.org>
	<5049E2C70200007800099B21@nat28.tlf.novell.com>
	<20120913101120.GA12881@ocelot.phlegethon.org>
	<5051E531020000780009B083@nat28.tlf.novell.com>
	<5051D440.4000007@redhat.com>
	<505203F0020000780009B12B@nat28.tlf.novell.com>
In-Reply-To: <505203F0020000780009B12B@nat28.tlf.novell.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23
Cc: Tim Deegan <tim@xen.org>, Jeffrey Karrels <karrelsj@gmail.com>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Clang/LLVM version requirements
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Il 13/09/2012 16:04, Jan Beulich ha scritto:
>>> >> So the patch is fine by me if it covers that misalignment case.
>>> >> But it seems a little heavy handed - I'd think that instead of the
>>> >> sub-section, we could just create an arbitrary other section, or
>>> >> even allow uninitialized variable (it's unclear to me why Paolo
>>> >> wrote the comment - in c/s 25479:61dfb3da56b - regarding BSS
>>> >> the way it is now) - after all we only need to make sure that
>>> >> - the space gets properly allocated in trampoline.S, i.e. also in
>>> >>   reloc.bin
>>> >> - all accesses are PC-relative
>>> >> Neither has anything to do with use of uninitialized variables.
>> > 
>> > We cannot use BSS because it doesn't appear in reloc.S.
> That, imo, would be a binutils bug.

It's just because the flags say so.  Tim's flag magic should do it (my
reply crossed with his).

Paolo

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 13 14:14:58 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Sep 2012 14:14:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TCABn-0001QB-Nm; Thu, 13 Sep 2012 14:14:43 +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 1TCABl-0001PT-Kr
	for xen-devel@lists.xen.org; Thu, 13 Sep 2012 14:14:41 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1347545675!10911831!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQxMjE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30343 invoked from network); 13 Sep 2012 14:14:35 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-12.tower-27.messagelabs.com with SMTP;
	13 Sep 2012 14:14:35 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 13 Sep 2012 15:14:35 +0100
Message-Id: <505206A0020000780009B165@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 13 Sep 2012 15:15:28 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Daniel De Graaf" <dgdegra@tycho.nsa.gov>
References: <1347465586-20009-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1347465586-20009-21-git-send-email-dgdegra@tycho.nsa.gov>
	<5051B1CC020000780009AFCE@nat28.tlf.novell.com>
	<5051E5E2.50801@tycho.nsa.gov>
In-Reply-To: <5051E5E2.50801@tycho.nsa.gov>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Tim Deegan <tim@xen.org>, Keir Fraser <keir@xen.org>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 20/22] arch/x86: use XSM hooks for
 get_pg_owner access checks
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 13.09.12 at 15:55, Daniel De Graaf <dgdegra@tycho.nsa.gov> wrote:
> On 09/13/2012 04:13 AM, Jan Beulich wrote:
>>>>> On 12.09.12 at 17:59, Daniel De Graaf <dgdegra@tycho.nsa.gov> wrote:
>>> @@ -3353,9 +3357,14 @@ long do_mmu_update(
>>>              mfn = req.ptr >> PAGE_SHIFT;
>>>              gpfn = req.val;
>>>  
>>> -            rc = xsm_mmu_machphys_update(d, pg_owner, mfn);
>>> -            if ( rc )
>>> -                break;
>>> +            xsm_needed |= XSM_MMU_MACHPHYS_UPDATE;
>>> +            if ( xsm_needed != xsm_checked )
>>> +            {
>>> +                rc = xsm_mmu_update(d, pt_owner, pg_owner, xsm_needed);
>> 
>> If you're already updating it this way, it would seem appropriate
>> to remove the over-checking here: pt_owner is meaningless for
>> this operation (there are no page tables involved), and hence
>> you could/should pass d instead.
> 
> While this is safe, it makes thinking about the arguments to the XSM hook
> harder: the second argument would be defined as "pt_owner if called with
> XSM_MMU_NORMAL_UPDATE set and either XSM_MMU_MACHPHYS_UPDATE unset or
> XSM_MMU_MACHPHYS_UPDATE set in the previous call; otherwise, d." I would
> prefer the simpler method of passing pt_owner every time, and only checking
> it if XSM_MMU_NORMAL_UPDATE is set (which I now notice that the default
> XSM hook does not do, although the FLASK hook does; I'll fix that).

If that's a concern, then rather pass NULL here (and deal with it
in the XSM code), indicating that there are no page tables being
updated.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 13 14:14:58 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Sep 2012 14:14:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TCABn-0001QB-Nm; Thu, 13 Sep 2012 14:14:43 +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 1TCABl-0001PT-Kr
	for xen-devel@lists.xen.org; Thu, 13 Sep 2012 14:14:41 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1347545675!10911831!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQxMjE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30343 invoked from network); 13 Sep 2012 14:14:35 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-12.tower-27.messagelabs.com with SMTP;
	13 Sep 2012 14:14:35 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 13 Sep 2012 15:14:35 +0100
Message-Id: <505206A0020000780009B165@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 13 Sep 2012 15:15:28 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Daniel De Graaf" <dgdegra@tycho.nsa.gov>
References: <1347465586-20009-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1347465586-20009-21-git-send-email-dgdegra@tycho.nsa.gov>
	<5051B1CC020000780009AFCE@nat28.tlf.novell.com>
	<5051E5E2.50801@tycho.nsa.gov>
In-Reply-To: <5051E5E2.50801@tycho.nsa.gov>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Tim Deegan <tim@xen.org>, Keir Fraser <keir@xen.org>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 20/22] arch/x86: use XSM hooks for
 get_pg_owner access checks
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 13.09.12 at 15:55, Daniel De Graaf <dgdegra@tycho.nsa.gov> wrote:
> On 09/13/2012 04:13 AM, Jan Beulich wrote:
>>>>> On 12.09.12 at 17:59, Daniel De Graaf <dgdegra@tycho.nsa.gov> wrote:
>>> @@ -3353,9 +3357,14 @@ long do_mmu_update(
>>>              mfn = req.ptr >> PAGE_SHIFT;
>>>              gpfn = req.val;
>>>  
>>> -            rc = xsm_mmu_machphys_update(d, pg_owner, mfn);
>>> -            if ( rc )
>>> -                break;
>>> +            xsm_needed |= XSM_MMU_MACHPHYS_UPDATE;
>>> +            if ( xsm_needed != xsm_checked )
>>> +            {
>>> +                rc = xsm_mmu_update(d, pt_owner, pg_owner, xsm_needed);
>> 
>> If you're already updating it this way, it would seem appropriate
>> to remove the over-checking here: pt_owner is meaningless for
>> this operation (there are no page tables involved), and hence
>> you could/should pass d instead.
> 
> While this is safe, it makes thinking about the arguments to the XSM hook
> harder: the second argument would be defined as "pt_owner if called with
> XSM_MMU_NORMAL_UPDATE set and either XSM_MMU_MACHPHYS_UPDATE unset or
> XSM_MMU_MACHPHYS_UPDATE set in the previous call; otherwise, d." I would
> prefer the simpler method of passing pt_owner every time, and only checking
> it if XSM_MMU_NORMAL_UPDATE is set (which I now notice that the default
> XSM hook does not do, although the FLASK hook does; I'll fix that).

If that's a concern, then rather pass NULL here (and deal with it
in the XSM code), indicating that there are no page tables being
updated.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 13 14:18:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Sep 2012 14:18:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TCAF1-0001ef-Bq; Thu, 13 Sep 2012 14:18: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 1TCAEz-0001eT-Oi
	for xen-devel@lists.xen.org; Thu, 13 Sep 2012 14:18:02 +0000
Received: from [85.158.143.35:61808] by server-2.bemta-4.messagelabs.com id
	90/E2-21239-91BE1505; Thu, 13 Sep 2012 14:18:01 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1347545880!12302728!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQxMjE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4248 invoked from network); 13 Sep 2012 14:18:00 -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;
	13 Sep 2012 14:18:00 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 13 Sep 2012 15:18:00 +0100
Message-Id: <5052076E020000780009B177@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 13 Sep 2012 15:18:54 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Paolo Bonzini" <pbonzini@redhat.com>
References: <CAFw--Dd0k7L+T_UJc0yHAkUGrY_-GDHaQjK3OM-1UdOp=J-wAQ@mail.gmail.com>
	<20120907085036.GA71093@ocelot.phlegethon.org>
	<5049E2C70200007800099B21@nat28.tlf.novell.com>
	<20120913101120.GA12881@ocelot.phlegethon.org>
	<5051E531020000780009B083@nat28.tlf.novell.com>
	<5051D440.4000007@redhat.com>
	<505203F0020000780009B12B@nat28.tlf.novell.com>
	<5051EA11.4080907@redhat.com>
In-Reply-To: <5051EA11.4080907@redhat.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Tim Deegan <tim@xen.org>, Jeffrey Karrels <karrelsj@gmail.com>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Clang/LLVM version requirements
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.09.12 at 16:13, Paolo Bonzini <pbonzini@redhat.com> wrote:
> Il 13/09/2012 16:04, Jan Beulich ha scritto:
>>>> >> So the patch is fine by me if it covers that misalignment case.
>>>> >> But it seems a little heavy handed - I'd think that instead of the
>>>> >> sub-section, we could just create an arbitrary other section, or
>>>> >> even allow uninitialized variable (it's unclear to me why Paolo
>>>> >> wrote the comment - in c/s 25479:61dfb3da56b - regarding BSS
>>>> >> the way it is now) - after all we only need to make sure that
>>>> >> - the space gets properly allocated in trampoline.S, i.e. also in
>>>> >>   reloc.bin
>>>> >> - all accesses are PC-relative
>>>> >> Neither has anything to do with use of uninitialized variables.
>>> > 
>>> > We cannot use BSS because it doesn't appear in reloc.S.
>> That, imo, would be a binutils bug.
> 
> It's just because the flags say so.  Tim's flag magic should do it (my
> reply crossed with his).

Flags magic shouldn't be required either, since I don't think you'll
find a .o with a .bss section with the alloc flag clear. The alloc flag
set, however, means it ought to be present in the output.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 13 14:18:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Sep 2012 14:18:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TCAF1-0001ef-Bq; Thu, 13 Sep 2012 14:18: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 1TCAEz-0001eT-Oi
	for xen-devel@lists.xen.org; Thu, 13 Sep 2012 14:18:02 +0000
Received: from [85.158.143.35:61808] by server-2.bemta-4.messagelabs.com id
	90/E2-21239-91BE1505; Thu, 13 Sep 2012 14:18:01 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1347545880!12302728!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQxMjE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4248 invoked from network); 13 Sep 2012 14:18:00 -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;
	13 Sep 2012 14:18:00 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 13 Sep 2012 15:18:00 +0100
Message-Id: <5052076E020000780009B177@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 13 Sep 2012 15:18:54 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Paolo Bonzini" <pbonzini@redhat.com>
References: <CAFw--Dd0k7L+T_UJc0yHAkUGrY_-GDHaQjK3OM-1UdOp=J-wAQ@mail.gmail.com>
	<20120907085036.GA71093@ocelot.phlegethon.org>
	<5049E2C70200007800099B21@nat28.tlf.novell.com>
	<20120913101120.GA12881@ocelot.phlegethon.org>
	<5051E531020000780009B083@nat28.tlf.novell.com>
	<5051D440.4000007@redhat.com>
	<505203F0020000780009B12B@nat28.tlf.novell.com>
	<5051EA11.4080907@redhat.com>
In-Reply-To: <5051EA11.4080907@redhat.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Tim Deegan <tim@xen.org>, Jeffrey Karrels <karrelsj@gmail.com>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Clang/LLVM version requirements
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.09.12 at 16:13, Paolo Bonzini <pbonzini@redhat.com> wrote:
> Il 13/09/2012 16:04, Jan Beulich ha scritto:
>>>> >> So the patch is fine by me if it covers that misalignment case.
>>>> >> But it seems a little heavy handed - I'd think that instead of the
>>>> >> sub-section, we could just create an arbitrary other section, or
>>>> >> even allow uninitialized variable (it's unclear to me why Paolo
>>>> >> wrote the comment - in c/s 25479:61dfb3da56b - regarding BSS
>>>> >> the way it is now) - after all we only need to make sure that
>>>> >> - the space gets properly allocated in trampoline.S, i.e. also in
>>>> >>   reloc.bin
>>>> >> - all accesses are PC-relative
>>>> >> Neither has anything to do with use of uninitialized variables.
>>> > 
>>> > We cannot use BSS because it doesn't appear in reloc.S.
>> That, imo, would be a binutils bug.
> 
> It's just because the flags say so.  Tim's flag magic should do it (my
> reply crossed with his).

Flags magic shouldn't be required either, since I don't think you'll
find a .o with a .bss section with the alloc flag clear. The alloc flag
set, however, means it ought to be present in the output.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 13 14:22:34 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Sep 2012 14:22:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TCAJB-0001qR-2o; Thu, 13 Sep 2012 14:22: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 1TCAJA-0001qL-44
	for xen-devel@lists.xen.org; Thu, 13 Sep 2012 14:22:20 +0000
Received: from [85.158.143.35:39923] by server-1.bemta-4.messagelabs.com id
	C1/F2-12504-B1CE1505; Thu, 13 Sep 2012 14:22:19 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1347546138!14869242!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQxMjE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6532 invoked from network); 13 Sep 2012 14:22:18 -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;
	13 Sep 2012 14:22:18 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 13 Sep 2012 15:22:18 +0100
Message-Id: <5052086E020000780009B18D@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 13 Sep 2012 15:23:10 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Tim Deegan" <tim@xen.org>
References: <a770d1c8448d73ccf2ec.1347544917@whitby.uk.xensource.com>
In-Reply-To: <a770d1c8448d73ccf2ec.1347544917@whitby.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] x86/mm: remove the linear mapping of the
 p2m tables
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 13.09.12 at 16:01, Tim Deegan <tim@xen.org> wrote:
> # HG changeset patch
> # User Tim Deegan <tim@xen.org>
> # Date 1347544824 -3600
> # Node ID a770d1c8448d73ccf2ec36a5322532c2e3c14641
> # Parent  5691e4cc17da7fe8664a67f1d07c3755c0ca34ed
> x86/mm: remove the linear mapping of the p2m tables.
> 
> Mapping the p2m into the monitor tables was an important optimization
> on 32-bit builds, where it avoided mapping and unmapping p2m pages
> during a walk.  On 64-bit it makes no difference -- see
> http://old-list-archives.xen.org/archives/html/xen-devel/2010-04/msg00981.html 

Is that also going to remain true when we won't be able to 1:1-
map all of the memory anymore once we break the current 5Tb
barrier? If not, it would probably be worthwhile keeping that
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 Sep 13 14:22:34 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Sep 2012 14:22:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TCAJB-0001qR-2o; Thu, 13 Sep 2012 14:22: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 1TCAJA-0001qL-44
	for xen-devel@lists.xen.org; Thu, 13 Sep 2012 14:22:20 +0000
Received: from [85.158.143.35:39923] by server-1.bemta-4.messagelabs.com id
	C1/F2-12504-B1CE1505; Thu, 13 Sep 2012 14:22:19 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1347546138!14869242!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQxMjE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6532 invoked from network); 13 Sep 2012 14:22:18 -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;
	13 Sep 2012 14:22:18 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 13 Sep 2012 15:22:18 +0100
Message-Id: <5052086E020000780009B18D@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 13 Sep 2012 15:23:10 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Tim Deegan" <tim@xen.org>
References: <a770d1c8448d73ccf2ec.1347544917@whitby.uk.xensource.com>
In-Reply-To: <a770d1c8448d73ccf2ec.1347544917@whitby.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] x86/mm: remove the linear mapping of the
 p2m tables
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 13.09.12 at 16:01, Tim Deegan <tim@xen.org> wrote:
> # HG changeset patch
> # User Tim Deegan <tim@xen.org>
> # Date 1347544824 -3600
> # Node ID a770d1c8448d73ccf2ec36a5322532c2e3c14641
> # Parent  5691e4cc17da7fe8664a67f1d07c3755c0ca34ed
> x86/mm: remove the linear mapping of the p2m tables.
> 
> Mapping the p2m into the monitor tables was an important optimization
> on 32-bit builds, where it avoided mapping and unmapping p2m pages
> during a walk.  On 64-bit it makes no difference -- see
> http://old-list-archives.xen.org/archives/html/xen-devel/2010-04/msg00981.html 

Is that also going to remain true when we won't be able to 1:1-
map all of the memory anymore once we break the current 5Tb
barrier? If not, it would probably be worthwhile keeping that
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 Sep 13 14:25:39 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Sep 2012 14: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 1TCAM8-0001zs-Rg; Thu, 13 Sep 2012 14:25:24 +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 1TCAM6-0001zh-OM
	for xen-devel@lists.xen.org; Thu, 13 Sep 2012 14:25:23 +0000
Received: from [85.158.137.99:61115] by server-7.bemta-3.messagelabs.com id
	FB/B3-32000-1DCE1505; Thu, 13 Sep 2012 14:25:21 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-8.tower-217.messagelabs.com!1347546320!12157318!1
X-Originating-IP: [63.239.67.9]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16300 invoked from network); 13 Sep 2012 14:25:20 -0000
Received: from emvm-gh1-uea08.nsa.gov (HELO nsa.gov) (63.239.67.9)
	by server-8.tower-217.messagelabs.com with SMTP;
	13 Sep 2012 14:25:20 -0000
X-TM-IMSS-Message-ID: <3eb102da0010dce3@nsa.gov>
Received: from tarius.tycho.ncsc.mil ([144.51.3.1]) by nsa.gov ([63.239.67.9])
	with ESMTP (TREND IMSS SMTP Service 7.1) id 3eb102da0010dce3 ;
	Thu, 13 Sep 2012 10:25:01 -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 q8DEPBwH004876; 
	Thu, 13 Sep 2012 10:25:11 -0400
Message-ID: <5051ECC7.7050901@tycho.nsa.gov>
Date: Thu, 13 Sep 2012 10:25:11 -0400
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Organization: National Security Agency
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120828 Thunderbird/15.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <1347465586-20009-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1347465586-20009-20-git-send-email-dgdegra@tycho.nsa.gov>
	<5051AED7020000780009AFC3@nat28.tlf.novell.com>
	<5051E3AC.2060700@tycho.nsa.gov>
	<50520634020000780009B162@nat28.tlf.novell.com>
In-Reply-To: <50520634020000780009B162@nat28.tlf.novell.com>
Cc: Tim Deegan <tim@xen.org>, Keir Fraser <keir@xen.org>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 19/22] arch/x86: check remote MMIO remap
	permissions
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 09/13/2012 10:13 AM, Jan Beulich wrote:
>>>> On 13.09.12 at 15:46, Daniel De Graaf <dgdegra@tycho.nsa.gov> wrote:
>> On 09/13/2012 04:00 AM, Jan Beulich wrote:
>>>>>> On 12.09.12 at 17:59, Daniel De Graaf <dgdegra@tycho.nsa.gov> wrote:
>>>> When a domain is mapping pages from a different pg_owner domain, the
>>>> iomem_access checks are currently only applied to the pg_owner domain,
>>>> potentially allowing the current domain to bypass its more restrictive
>>>> iomem_access policy using another domain that it has access to.
>>>
>>> Are you sure about this? I ask because ...
>>>
>>>> --- a/xen/arch/x86/mm.c
>>>> +++ b/xen/arch/x86/mm.c
>>>> @@ -754,6 +754,18 @@ get_page_from_l1e(
>>>>              return -EINVAL;
>>>>          }
>>>>  
>>>> +        if ( pg_owner != curr->domain &&
>>>> +             !iomem_access_permitted(curr->domain, mfn, mfn) )
>>>> +        {
>>>> +            if ( mfn != (PADDR_MASK >> PAGE_SHIFT) ) /* INVALID_MFN? */
>>>> +            {
>>>> +                MEM_LOG("Domain %u attempted to map I/O space %08lx in 
>> domain %u",
>>>> +                        curr->domain->domain_id, mfn, pg_owner->domain_id);
>>>> +                return -EPERM;
>>>> +            }
>>>> +            return -EINVAL;
>>>> +        }
>>>> +
>>>
>>> ... the place you insert this is after non-RAM pages got filtered
>>> out already, so you're applying an IOMEM permission check to a
>>> RAM page.
>>>
>>> Jan
>>>
>>>>          if ( !(l1f & _PAGE_RW) ||
>>>>               !rangeset_contains_singleton(mmio_ro_ranges, mfn) )
>>>>              return 0;
>>
>> If that's true, then the check a few lines above is also applying IOMEM
>> checks to RAM pages. I can see non-privileged attempts being filtered
>> above,

"above" refers to "if ( !iomem_access_permitted(pg_owner, mfn, mfn) )"
 
> I can't see how that would happen given this primary conditional
> 
>     if ( !mfn_valid(mfn) ||
>          (real_pg_owner = page_get_owner_and_reference(page)) == dom_io )
> 
> Please clarify what you're observing.

As I understand it, the contents of this block will be executed if the MFN is
invalid (interpreted as MMIO space) or if the page's owner is DOMID_IO, which
is how MMIO space is marked.

>> but successful mappings will continue to the check I added.
> 
> Of course. I would think that if anything, you would want to add
> a second call to iomem_access_permitted() with "curr->domain"
> right at the place where the current one is (in particular inside
> the above quoted conditional).
> 
> Jan

I was emulating the existing iomem_access_permitted check being run on pg_owner;
moving the curr->domain check up into this first conditional would end up
treating the MMIO mapping as a regular RAM mapping if the iomem_access_permitted
fails. Unless you're talking about a different quoted conditional?

-- 
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 Sep 13 14:25:39 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Sep 2012 14: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 1TCAM8-0001zs-Rg; Thu, 13 Sep 2012 14:25:24 +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 1TCAM6-0001zh-OM
	for xen-devel@lists.xen.org; Thu, 13 Sep 2012 14:25:23 +0000
Received: from [85.158.137.99:61115] by server-7.bemta-3.messagelabs.com id
	FB/B3-32000-1DCE1505; Thu, 13 Sep 2012 14:25:21 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-8.tower-217.messagelabs.com!1347546320!12157318!1
X-Originating-IP: [63.239.67.9]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16300 invoked from network); 13 Sep 2012 14:25:20 -0000
Received: from emvm-gh1-uea08.nsa.gov (HELO nsa.gov) (63.239.67.9)
	by server-8.tower-217.messagelabs.com with SMTP;
	13 Sep 2012 14:25:20 -0000
X-TM-IMSS-Message-ID: <3eb102da0010dce3@nsa.gov>
Received: from tarius.tycho.ncsc.mil ([144.51.3.1]) by nsa.gov ([63.239.67.9])
	with ESMTP (TREND IMSS SMTP Service 7.1) id 3eb102da0010dce3 ;
	Thu, 13 Sep 2012 10:25:01 -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 q8DEPBwH004876; 
	Thu, 13 Sep 2012 10:25:11 -0400
Message-ID: <5051ECC7.7050901@tycho.nsa.gov>
Date: Thu, 13 Sep 2012 10:25:11 -0400
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Organization: National Security Agency
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120828 Thunderbird/15.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <1347465586-20009-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1347465586-20009-20-git-send-email-dgdegra@tycho.nsa.gov>
	<5051AED7020000780009AFC3@nat28.tlf.novell.com>
	<5051E3AC.2060700@tycho.nsa.gov>
	<50520634020000780009B162@nat28.tlf.novell.com>
In-Reply-To: <50520634020000780009B162@nat28.tlf.novell.com>
Cc: Tim Deegan <tim@xen.org>, Keir Fraser <keir@xen.org>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 19/22] arch/x86: check remote MMIO remap
	permissions
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 09/13/2012 10:13 AM, Jan Beulich wrote:
>>>> On 13.09.12 at 15:46, Daniel De Graaf <dgdegra@tycho.nsa.gov> wrote:
>> On 09/13/2012 04:00 AM, Jan Beulich wrote:
>>>>>> On 12.09.12 at 17:59, Daniel De Graaf <dgdegra@tycho.nsa.gov> wrote:
>>>> When a domain is mapping pages from a different pg_owner domain, the
>>>> iomem_access checks are currently only applied to the pg_owner domain,
>>>> potentially allowing the current domain to bypass its more restrictive
>>>> iomem_access policy using another domain that it has access to.
>>>
>>> Are you sure about this? I ask because ...
>>>
>>>> --- a/xen/arch/x86/mm.c
>>>> +++ b/xen/arch/x86/mm.c
>>>> @@ -754,6 +754,18 @@ get_page_from_l1e(
>>>>              return -EINVAL;
>>>>          }
>>>>  
>>>> +        if ( pg_owner != curr->domain &&
>>>> +             !iomem_access_permitted(curr->domain, mfn, mfn) )
>>>> +        {
>>>> +            if ( mfn != (PADDR_MASK >> PAGE_SHIFT) ) /* INVALID_MFN? */
>>>> +            {
>>>> +                MEM_LOG("Domain %u attempted to map I/O space %08lx in 
>> domain %u",
>>>> +                        curr->domain->domain_id, mfn, pg_owner->domain_id);
>>>> +                return -EPERM;
>>>> +            }
>>>> +            return -EINVAL;
>>>> +        }
>>>> +
>>>
>>> ... the place you insert this is after non-RAM pages got filtered
>>> out already, so you're applying an IOMEM permission check to a
>>> RAM page.
>>>
>>> Jan
>>>
>>>>          if ( !(l1f & _PAGE_RW) ||
>>>>               !rangeset_contains_singleton(mmio_ro_ranges, mfn) )
>>>>              return 0;
>>
>> If that's true, then the check a few lines above is also applying IOMEM
>> checks to RAM pages. I can see non-privileged attempts being filtered
>> above,

"above" refers to "if ( !iomem_access_permitted(pg_owner, mfn, mfn) )"
 
> I can't see how that would happen given this primary conditional
> 
>     if ( !mfn_valid(mfn) ||
>          (real_pg_owner = page_get_owner_and_reference(page)) == dom_io )
> 
> Please clarify what you're observing.

As I understand it, the contents of this block will be executed if the MFN is
invalid (interpreted as MMIO space) or if the page's owner is DOMID_IO, which
is how MMIO space is marked.

>> but successful mappings will continue to the check I added.
> 
> Of course. I would think that if anything, you would want to add
> a second call to iomem_access_permitted() with "curr->domain"
> right at the place where the current one is (in particular inside
> the above quoted conditional).
> 
> Jan

I was emulating the existing iomem_access_permitted check being run on pg_owner;
moving the curr->domain check up into this first conditional would end up
treating the MMIO mapping as a regular RAM mapping if the iomem_access_permitted
fails. Unless you're talking about a different quoted conditional?

-- 
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 Sep 13 14:33:50 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Sep 2012 14: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 1TCAU2-0002DB-QJ; Thu, 13 Sep 2012 14:33:34 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1TCAU1-0002D4-IW
	for xen-devel@lists.xen.org; Thu, 13 Sep 2012 14:33:33 +0000
Received: from [85.158.138.51:17667] by server-10.bemta-3.messagelabs.com id
	F7/92-10411-CBEE1505; Thu, 13 Sep 2012 14:33:32 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1347546811!28715529!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDkwMjg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6402 invoked from network); 13 Sep 2012 14:33:32 -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 Sep 2012 14:33:32 -0000
X-IronPort-AV: E=Sophos;i="4.80,417,1344211200"; d="scan'208";a="14523977"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Sep 2012 14:33: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.279.1; Thu, 13 Sep 2012 15:33: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
	1TCATq-0006Rl-Sz; Thu, 13 Sep 2012 14:33:22 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1TCATq-0005ob-JL;
	Thu, 13 Sep 2012 15:33:22 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20561.61106.420950.555517@mariner.uk.xensource.com>
Date: Thu, 13 Sep 2012 15:33:22 +0100
To: Ian Campbell <Ian.Campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1347465388.24226.60.camel@zakaz.uk.xensource.com>
References: <B5B91DB6-BC9C-4E0A-BCF3-243671577A40@gridcentric.ca>
	<1347461790.24226.56.camel@zakaz.uk.xensource.com>
	<5050A457.7070201@citrix.com>
	<3F05442F-4DA8-463A-A9B7-596B9853CFFD@gridcentric.ca>
	<1347465388.24226.60.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Andres Lagar-Cavilla <andreslc@gridcentric.ca>,
	Roger Pau Monne <roger.pau@citrix.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Libxenstore memory leak on static compile
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="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] Libxenstore memory leak on static compile"):
> If you do this then you may as well nuke the !USE_PTHREAD case
> altogether, since this makes it pointless.
> 
> I'd prefer not to do that though.

I agree.

I think it would be better to just fix the leak.  This should go into
unstable and after that into 4.2.1.

Also I think we should rename (in unstable only) the .a to make it
clear that it's not just a .a version of the .so.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 13 14:33:50 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Sep 2012 14: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 1TCAU2-0002DB-QJ; Thu, 13 Sep 2012 14:33:34 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1TCAU1-0002D4-IW
	for xen-devel@lists.xen.org; Thu, 13 Sep 2012 14:33:33 +0000
Received: from [85.158.138.51:17667] by server-10.bemta-3.messagelabs.com id
	F7/92-10411-CBEE1505; Thu, 13 Sep 2012 14:33:32 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1347546811!28715529!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDkwMjg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6402 invoked from network); 13 Sep 2012 14:33:32 -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 Sep 2012 14:33:32 -0000
X-IronPort-AV: E=Sophos;i="4.80,417,1344211200"; d="scan'208";a="14523977"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Sep 2012 14:33: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.279.1; Thu, 13 Sep 2012 15:33: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
	1TCATq-0006Rl-Sz; Thu, 13 Sep 2012 14:33:22 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1TCATq-0005ob-JL;
	Thu, 13 Sep 2012 15:33:22 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20561.61106.420950.555517@mariner.uk.xensource.com>
Date: Thu, 13 Sep 2012 15:33:22 +0100
To: Ian Campbell <Ian.Campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1347465388.24226.60.camel@zakaz.uk.xensource.com>
References: <B5B91DB6-BC9C-4E0A-BCF3-243671577A40@gridcentric.ca>
	<1347461790.24226.56.camel@zakaz.uk.xensource.com>
	<5050A457.7070201@citrix.com>
	<3F05442F-4DA8-463A-A9B7-596B9853CFFD@gridcentric.ca>
	<1347465388.24226.60.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Andres Lagar-Cavilla <andreslc@gridcentric.ca>,
	Roger Pau Monne <roger.pau@citrix.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Libxenstore memory leak on static compile
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="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] Libxenstore memory leak on static compile"):
> If you do this then you may as well nuke the !USE_PTHREAD case
> altogether, since this makes it pointless.
> 
> I'd prefer not to do that though.

I agree.

I think it would be better to just fix the leak.  This should go into
unstable and after that into 4.2.1.

Also I think we should rename (in unstable only) the .a to make it
clear that it's not just a .a version of the .so.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 13 14:37:32 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Sep 2012 14:37:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TCAXf-0002Ka-EW; Thu, 13 Sep 2012 14:37:19 +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 1TCAXe-0002KO-AE
	for xen-devel@lists.xen.org; Thu, 13 Sep 2012 14:37:18 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1347547032!9485252!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDkwMjg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7431 invoked from network); 13 Sep 2012 14:37:12 -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;
	13 Sep 2012 14:37:12 -0000
X-IronPort-AV: E=Sophos;i="4.80,417,1344211200"; d="scan'208";a="14524099"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Sep 2012 14:37: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.279.1; Thu, 13 Sep 2012 15:37: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
	1TCAXX-0006UY-Qp; Thu, 13 Sep 2012 14:37:11 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1TCAXX-0005p1-Lj;
	Thu, 13 Sep 2012 15:37:11 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20561.61335.548996.644196@mariner.uk.xensource.com>
Date: Thu, 13 Sep 2012 15:37:11 +0100
To: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1347465586-20009-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1347465586-20009-1-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH v3] Merge IS_PRIV checks into XSM hooks
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Daniel De Graaf writes ("[Xen-devel] [PATCH v3] Merge IS_PRIV checks into XSM hooks"):
> The ARM architecture is not touched at all in these patches; however,
> none of the changes should affect ARM. XSM hooks will need to be added
> for the arch-specific controls in order for FLASK to be useful on ARM,
> but those changes are outside the scope of this series.

By "not useful" I guess you mean that it wouldn't have the desired
security property.  Is there already something that will prevent
attempts to use xsm on arm ?  The code which enforces this should
ideally have a comment listing everything that was done to x86 but not
to arm, so that we have a useful todo list and don't miss anything
before enabling xsm on arm.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 13 14:37:32 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Sep 2012 14:37:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TCAXf-0002Ka-EW; Thu, 13 Sep 2012 14:37:19 +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 1TCAXe-0002KO-AE
	for xen-devel@lists.xen.org; Thu, 13 Sep 2012 14:37:18 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1347547032!9485252!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDkwMjg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7431 invoked from network); 13 Sep 2012 14:37:12 -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;
	13 Sep 2012 14:37:12 -0000
X-IronPort-AV: E=Sophos;i="4.80,417,1344211200"; d="scan'208";a="14524099"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Sep 2012 14:37: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.279.1; Thu, 13 Sep 2012 15:37: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
	1TCAXX-0006UY-Qp; Thu, 13 Sep 2012 14:37:11 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1TCAXX-0005p1-Lj;
	Thu, 13 Sep 2012 15:37:11 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20561.61335.548996.644196@mariner.uk.xensource.com>
Date: Thu, 13 Sep 2012 15:37:11 +0100
To: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1347465586-20009-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1347465586-20009-1-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH v3] Merge IS_PRIV checks into XSM hooks
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Daniel De Graaf writes ("[Xen-devel] [PATCH v3] Merge IS_PRIV checks into XSM hooks"):
> The ARM architecture is not touched at all in these patches; however,
> none of the changes should affect ARM. XSM hooks will need to be added
> for the arch-specific controls in order for FLASK to be useful on ARM,
> but those changes are outside the scope of this series.

By "not useful" I guess you mean that it wouldn't have the desired
security property.  Is there already something that will prevent
attempts to use xsm on arm ?  The code which enforces this should
ideally have a comment listing everything that was done to x86 but not
to arm, so that we have a useful todo list and don't miss anything
before enabling xsm on arm.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 13 14:43:16 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Sep 2012 14: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 1TCAdB-0002VR-7Q; Thu, 13 Sep 2012 14:43:01 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1TCAd9-0002VJ-8q
	for xen-devel@lists.xen.org; Thu, 13 Sep 2012 14:42:59 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-6.tower-27.messagelabs.com!1347547372!5330396!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16203 invoked from network); 13 Sep 2012 14:42: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; 13 Sep 2012 14:42:53 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1TCAd1-0004OD-R2; Thu, 13 Sep 2012 14:42:51 +0000
Date: Thu, 13 Sep 2012 15:42:51 +0100
From: Tim Deegan <tim@xen.org>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20120913144251.GC12881@ocelot.phlegethon.org>
References: <a770d1c8448d73ccf2ec.1347544917@whitby.uk.xensource.com>
	<5052086E020000780009B18D@nat28.tlf.novell.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <5052086E020000780009B18D@nat28.tlf.novell.com>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] x86/mm: remove the linear mapping of the
	p2m tables
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At 15:23 +0100 on 13 Sep (1347549790), Jan Beulich wrote:
> >>> On 13.09.12 at 16:01, Tim Deegan <tim@xen.org> wrote:
> > # HG changeset patch
> > # User Tim Deegan <tim@xen.org>
> > # Date 1347544824 -3600
> > # Node ID a770d1c8448d73ccf2ec36a5322532c2e3c14641
> > # Parent  5691e4cc17da7fe8664a67f1d07c3755c0ca34ed
> > x86/mm: remove the linear mapping of the p2m tables.
> > 
> > Mapping the p2m into the monitor tables was an important optimization
> > on 32-bit builds, where it avoided mapping and unmapping p2m pages
> > during a walk.  On 64-bit it makes no difference -- see
> > http://old-list-archives.xen.org/archives/html/xen-devel/2010-04/msg00981.html 
> 
> Is that also going to remain true when we won't be able to 1:1-
> map all of the memory anymore once we break the current 5Tb
> barrier? If not, it would probably be worthwhile keeping that
> code.

Ah, 5TB is a smaller limit than I thought we had.  Yes, better leave it
alone, so.  Though TBH finding some way to use a bit more virtual
address space for Xen seems like a good idea anyway, since this won't be
the only place we'll want to avoid TLB flushes.

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 13 14:43:16 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Sep 2012 14: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 1TCAdB-0002VR-7Q; Thu, 13 Sep 2012 14:43:01 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1TCAd9-0002VJ-8q
	for xen-devel@lists.xen.org; Thu, 13 Sep 2012 14:42:59 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-6.tower-27.messagelabs.com!1347547372!5330396!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16203 invoked from network); 13 Sep 2012 14:42: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; 13 Sep 2012 14:42:53 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1TCAd1-0004OD-R2; Thu, 13 Sep 2012 14:42:51 +0000
Date: Thu, 13 Sep 2012 15:42:51 +0100
From: Tim Deegan <tim@xen.org>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20120913144251.GC12881@ocelot.phlegethon.org>
References: <a770d1c8448d73ccf2ec.1347544917@whitby.uk.xensource.com>
	<5052086E020000780009B18D@nat28.tlf.novell.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <5052086E020000780009B18D@nat28.tlf.novell.com>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] x86/mm: remove the linear mapping of the
	p2m tables
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At 15:23 +0100 on 13 Sep (1347549790), Jan Beulich wrote:
> >>> On 13.09.12 at 16:01, Tim Deegan <tim@xen.org> wrote:
> > # HG changeset patch
> > # User Tim Deegan <tim@xen.org>
> > # Date 1347544824 -3600
> > # Node ID a770d1c8448d73ccf2ec36a5322532c2e3c14641
> > # Parent  5691e4cc17da7fe8664a67f1d07c3755c0ca34ed
> > x86/mm: remove the linear mapping of the p2m tables.
> > 
> > Mapping the p2m into the monitor tables was an important optimization
> > on 32-bit builds, where it avoided mapping and unmapping p2m pages
> > during a walk.  On 64-bit it makes no difference -- see
> > http://old-list-archives.xen.org/archives/html/xen-devel/2010-04/msg00981.html 
> 
> Is that also going to remain true when we won't be able to 1:1-
> map all of the memory anymore once we break the current 5Tb
> barrier? If not, it would probably be worthwhile keeping that
> code.

Ah, 5TB is a smaller limit than I thought we had.  Yes, better leave it
alone, so.  Though TBH finding some way to use a bit more virtual
address space for Xen seems like a good idea anyway, since this won't be
the only place we'll want to avoid TLB flushes.

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 13 14:53:51 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Sep 2012 14:53: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 1TCAnM-0002g0-F4; Thu, 13 Sep 2012 14:53: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 1TCAnK-0002fv-Bk
	for xen-devel@lists.xen.org; Thu, 13 Sep 2012 14:53:30 +0000
Received: from [85.158.143.99:36096] by server-3.bemta-4.messagelabs.com id
	E2/AC-08232-963F1505; Thu, 13 Sep 2012 14:53:29 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1347548009!30239030!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDkwMjg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8143 invoked from network); 13 Sep 2012 14:53:29 -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;
	13 Sep 2012 14:53:29 -0000
X-IronPort-AV: E=Sophos;i="4.80,417,1344211200"; d="scan'208";a="14524470"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Sep 2012 14:53: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.279.1; Thu, 13 Sep 2012 15:53: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
	1TCAnI-0006Zp-OW; Thu, 13 Sep 2012 14:53:28 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1TCAnI-0005qG-EM;
	Thu, 13 Sep 2012 15:53:28 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20561.62312.319383.462890@mariner.uk.xensource.com>
Date: Thu, 13 Sep 2012 15:53:28 +0100
To: Keir Fraser <keir.xen@gmail.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <CC77835D.3EA28%keir.xen@gmail.com>
References: <CC77835D.3EA28%keir.xen@gmail.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [ANNOUNCE] Final release candidate for Xen 4.2.0
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Keir Fraser writes ("[Xen-devel] [ANNOUNCE] Final release candidate for Xen 4.2.0"):
> A final RC has been tagged in the xen-4.2 branch:
> http://xenbits.xen.org/hg/staging/xen-4.2-testing.hg (tag '4.2.0-rc5')

I have made a tarball in the traditional style, with included copies
of both relevant versions of qemu.  (In 4.3 we should arrange to be
able to make a tarball version which doesn't download anything, and
the machinery for doing this should be in-tree.)

The tarball is here:
  http://bits.xensource.com/oss-xen/release/4.2.0-rc5/xen-4.2.0-rc5.tar.gz
  http://bits.xensource.com/oss-xen/release/4.2.0-rc5/xen-4.2.0-rc5.tar.gz.sig
Comments welcome (particularly about how the tarball version is
constructed).

> We plan to call the 4.2.0 release on Monday, with no further modifications.
> So please test this "GA preview"!

As Keir says.  If all goes well the 4.2.0 release will have a
functionally identical tarball.

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 Sep 13 14:53:51 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Sep 2012 14:53: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 1TCAnM-0002g0-F4; Thu, 13 Sep 2012 14:53: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 1TCAnK-0002fv-Bk
	for xen-devel@lists.xen.org; Thu, 13 Sep 2012 14:53:30 +0000
Received: from [85.158.143.99:36096] by server-3.bemta-4.messagelabs.com id
	E2/AC-08232-963F1505; Thu, 13 Sep 2012 14:53:29 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1347548009!30239030!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDkwMjg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8143 invoked from network); 13 Sep 2012 14:53:29 -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;
	13 Sep 2012 14:53:29 -0000
X-IronPort-AV: E=Sophos;i="4.80,417,1344211200"; d="scan'208";a="14524470"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Sep 2012 14:53: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.279.1; Thu, 13 Sep 2012 15:53: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
	1TCAnI-0006Zp-OW; Thu, 13 Sep 2012 14:53:28 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1TCAnI-0005qG-EM;
	Thu, 13 Sep 2012 15:53:28 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20561.62312.319383.462890@mariner.uk.xensource.com>
Date: Thu, 13 Sep 2012 15:53:28 +0100
To: Keir Fraser <keir.xen@gmail.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <CC77835D.3EA28%keir.xen@gmail.com>
References: <CC77835D.3EA28%keir.xen@gmail.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [ANNOUNCE] Final release candidate for Xen 4.2.0
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Keir Fraser writes ("[Xen-devel] [ANNOUNCE] Final release candidate for Xen 4.2.0"):
> A final RC has been tagged in the xen-4.2 branch:
> http://xenbits.xen.org/hg/staging/xen-4.2-testing.hg (tag '4.2.0-rc5')

I have made a tarball in the traditional style, with included copies
of both relevant versions of qemu.  (In 4.3 we should arrange to be
able to make a tarball version which doesn't download anything, and
the machinery for doing this should be in-tree.)

The tarball is here:
  http://bits.xensource.com/oss-xen/release/4.2.0-rc5/xen-4.2.0-rc5.tar.gz
  http://bits.xensource.com/oss-xen/release/4.2.0-rc5/xen-4.2.0-rc5.tar.gz.sig
Comments welcome (particularly about how the tarball version is
constructed).

> We plan to call the 4.2.0 release on Monday, with no further modifications.
> So please test this "GA preview"!

As Keir says.  If all goes well the 4.2.0 release will have a
functionally identical tarball.

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 Sep 13 14:55:43 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Sep 2012 14:55:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TCApE-0002lC-Vq; Thu, 13 Sep 2012 14:55:28 +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 1TCApD-0002l3-SQ
	for xen-devel@lists.xen.org; Thu, 13 Sep 2012 14:55:28 +0000
Received: from [85.158.139.83:20152] by server-2.bemta-5.messagelabs.com id
	EA/46-11456-ED3F1505; Thu, 13 Sep 2012 14:55:26 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-16.tower-182.messagelabs.com!1347548125!23006779!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20561 invoked from network); 13 Sep 2012 14:55:26 -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; 13 Sep 2012 14:55:26 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1TCApA-0004Qr-Gi; Thu, 13 Sep 2012 14:55:24 +0000
Date: Thu, 13 Sep 2012 15:55:24 +0100
From: Tim Deegan <tim@xen.org>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20120913145524.GD12881@ocelot.phlegethon.org>
References: <CAFw--Dd0k7L+T_UJc0yHAkUGrY_-GDHaQjK3OM-1UdOp=J-wAQ@mail.gmail.com>
	<20120907085036.GA71093@ocelot.phlegethon.org>
	<5049E2C70200007800099B21@nat28.tlf.novell.com>
	<20120913101120.GA12881@ocelot.phlegethon.org>
	<5051E531020000780009B083@nat28.tlf.novell.com>
	<20120913122130.GB12881@ocelot.phlegethon.org>
	<50520368020000780009B128@nat28.tlf.novell.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <50520368020000780009B128@nat28.tlf.novell.com>
User-Agent: Mutt/1.4.2.1i
Cc: Paolo Bonzini <pbonzini@redhat.com>, Jeffrey Karrels <karrelsj@gmail.com>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Clang/LLVM version requirements
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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:01 +0100 on 13 Sep (1347548504), Jan Beulich wrote:
> >>> On 13.09.12 at 14:21, Tim Deegan <tim@xen.org> wrote:
> > Allowing BSS would just need a few extra runes (AFAICS,
> > "--set-section-flags .bss=alloc,load,contents") in the objcopy that
> > makes reloc.bin.
> >  But I'm not sure how to make sure everything is
> > rip-relative, do if that's the real concern I'm inclined to go with
> > this compile-time check and exclude .[ro]data[.*] as well.
> > We can always fix it up to allow bss and data sections if we ever
> > actually need them.
> 
> As said, I'm fine with any approach as long as it works with all
> supported tool chains. So feel free to go the route you're
> proposing.

OK.  The patch below works for me on gccs 4.1 to 4.7 and clang 3.0.
I tries gcc 3.4 but the build already fails in a few other places.
Do we really still support gcc 3.4 like the README says?

Can I have an Ack, or would you like to apply it yourself?

Tim.

# HG changeset patch
# Parent 9e46d90d0182979a7220314ca19d2525e338aa5d
x86: check for data and BSS in reloc code at compile time.

This is a more useful failure mode than hanging at boot time, and
incidentally fixes the clang/LLVM build by removing a .subsection rune.

Signed-off-by: Tim Deegan <tim@xen.org>

diff -r 9e46d90d0182 xen/arch/x86/boot/build32.mk
--- a/xen/arch/x86/boot/build32.mk	Thu Sep 13 15:00:26 2012 +0100
+++ b/xen/arch/x86/boot/build32.mk	Thu Sep 13 15:04:32 2012 +0100
@@ -20,6 +20,15 @@ CFLAGS := $(filter-out -flto,$(CFLAGS))
 
 %.o: %.c
 	$(CC) $(CFLAGS) -c -fpic $< -o $@
+	$(OBJDUMP) -h $@ | sed -n '/[0-9]/{s,00*,0,g;p}' |\
+		while read idx name sz rest; do \
+			case "$$name" in \
+			.data|.data.*|.rodata|.rodata.*|.bss|.bss.*) \
+				test $$sz != 0 || continue; \
+				echo "Error: non-empty $$name: 0x$$sz" >&2; \
+				exit $$(expr $$idx + 1);; \
+			esac; \
+		done
 
 reloc.o: $(BASEDIR)/include/asm-x86/config.h
 .PRECIOUS: %.bin %.lnk
diff -r 9e46d90d0182 xen/arch/x86/boot/reloc.c
--- a/xen/arch/x86/boot/reloc.c	Thu Sep 13 15:00:26 2012 +0100
+++ b/xen/arch/x86/boot/reloc.c	Thu Sep 13 15:04:32 2012 +0100
@@ -18,10 +18,7 @@ asm (
     "    call 1f                       \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"
+    "    jmp  reloc                    \n"
     );
 
 /* This is our data.  Because the code must be relocatable, no BSS is
@@ -30,9 +27,6 @@ asm (
 asm (
     "alloc:                            \n"
     "    .long 0                       \n"
-    "    .subsection 1                 \n"
-    "    .p2align 4, 0xcc              \n"
-    "    .subsection 0                 \n"
     );
 
 typedef unsigned int u32;

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 13 14:55:43 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Sep 2012 14:55:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TCApE-0002lC-Vq; Thu, 13 Sep 2012 14:55:28 +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 1TCApD-0002l3-SQ
	for xen-devel@lists.xen.org; Thu, 13 Sep 2012 14:55:28 +0000
Received: from [85.158.139.83:20152] by server-2.bemta-5.messagelabs.com id
	EA/46-11456-ED3F1505; Thu, 13 Sep 2012 14:55:26 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-16.tower-182.messagelabs.com!1347548125!23006779!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20561 invoked from network); 13 Sep 2012 14:55:26 -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; 13 Sep 2012 14:55:26 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1TCApA-0004Qr-Gi; Thu, 13 Sep 2012 14:55:24 +0000
Date: Thu, 13 Sep 2012 15:55:24 +0100
From: Tim Deegan <tim@xen.org>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20120913145524.GD12881@ocelot.phlegethon.org>
References: <CAFw--Dd0k7L+T_UJc0yHAkUGrY_-GDHaQjK3OM-1UdOp=J-wAQ@mail.gmail.com>
	<20120907085036.GA71093@ocelot.phlegethon.org>
	<5049E2C70200007800099B21@nat28.tlf.novell.com>
	<20120913101120.GA12881@ocelot.phlegethon.org>
	<5051E531020000780009B083@nat28.tlf.novell.com>
	<20120913122130.GB12881@ocelot.phlegethon.org>
	<50520368020000780009B128@nat28.tlf.novell.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <50520368020000780009B128@nat28.tlf.novell.com>
User-Agent: Mutt/1.4.2.1i
Cc: Paolo Bonzini <pbonzini@redhat.com>, Jeffrey Karrels <karrelsj@gmail.com>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Clang/LLVM version requirements
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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:01 +0100 on 13 Sep (1347548504), Jan Beulich wrote:
> >>> On 13.09.12 at 14:21, Tim Deegan <tim@xen.org> wrote:
> > Allowing BSS would just need a few extra runes (AFAICS,
> > "--set-section-flags .bss=alloc,load,contents") in the objcopy that
> > makes reloc.bin.
> >  But I'm not sure how to make sure everything is
> > rip-relative, do if that's the real concern I'm inclined to go with
> > this compile-time check and exclude .[ro]data[.*] as well.
> > We can always fix it up to allow bss and data sections if we ever
> > actually need them.
> 
> As said, I'm fine with any approach as long as it works with all
> supported tool chains. So feel free to go the route you're
> proposing.

OK.  The patch below works for me on gccs 4.1 to 4.7 and clang 3.0.
I tries gcc 3.4 but the build already fails in a few other places.
Do we really still support gcc 3.4 like the README says?

Can I have an Ack, or would you like to apply it yourself?

Tim.

# HG changeset patch
# Parent 9e46d90d0182979a7220314ca19d2525e338aa5d
x86: check for data and BSS in reloc code at compile time.

This is a more useful failure mode than hanging at boot time, and
incidentally fixes the clang/LLVM build by removing a .subsection rune.

Signed-off-by: Tim Deegan <tim@xen.org>

diff -r 9e46d90d0182 xen/arch/x86/boot/build32.mk
--- a/xen/arch/x86/boot/build32.mk	Thu Sep 13 15:00:26 2012 +0100
+++ b/xen/arch/x86/boot/build32.mk	Thu Sep 13 15:04:32 2012 +0100
@@ -20,6 +20,15 @@ CFLAGS := $(filter-out -flto,$(CFLAGS))
 
 %.o: %.c
 	$(CC) $(CFLAGS) -c -fpic $< -o $@
+	$(OBJDUMP) -h $@ | sed -n '/[0-9]/{s,00*,0,g;p}' |\
+		while read idx name sz rest; do \
+			case "$$name" in \
+			.data|.data.*|.rodata|.rodata.*|.bss|.bss.*) \
+				test $$sz != 0 || continue; \
+				echo "Error: non-empty $$name: 0x$$sz" >&2; \
+				exit $$(expr $$idx + 1);; \
+			esac; \
+		done
 
 reloc.o: $(BASEDIR)/include/asm-x86/config.h
 .PRECIOUS: %.bin %.lnk
diff -r 9e46d90d0182 xen/arch/x86/boot/reloc.c
--- a/xen/arch/x86/boot/reloc.c	Thu Sep 13 15:00:26 2012 +0100
+++ b/xen/arch/x86/boot/reloc.c	Thu Sep 13 15:04:32 2012 +0100
@@ -18,10 +18,7 @@ asm (
     "    call 1f                       \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"
+    "    jmp  reloc                    \n"
     );
 
 /* This is our data.  Because the code must be relocatable, no BSS is
@@ -30,9 +27,6 @@ asm (
 asm (
     "alloc:                            \n"
     "    .long 0                       \n"
-    "    .subsection 1                 \n"
-    "    .p2align 4, 0xcc              \n"
-    "    .subsection 0                 \n"
     );
 
 typedef unsigned int u32;

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 13 14:58:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Sep 2012 14: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 1TCAsN-0002vR-JR; Thu, 13 Sep 2012 14:58:43 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1TCAsM-0002vG-71
	for xen-devel@lists.xen.org; Thu, 13 Sep 2012 14:58:42 +0000
Received: from [85.158.143.35:63352] by server-3.bemta-4.messagelabs.com id
	D4/94-08232-1A4F1505; Thu, 13 Sep 2012 14:58:41 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1347548320!13542516!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-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2198 invoked from network); 13 Sep 2012 14:58:41 -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;
	13 Sep 2012 14:58:41 -0000
Received: by eeke53 with SMTP id e53so2097981eek.32
	for <xen-devel@lists.xen.org>; Thu, 13 Sep 2012 07:58:40 -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=3mlt6b1Q1oWeSXTF6t2EK/zFYkJMQaIKO9qgU9me/qo=;
	b=jOepq+dn0NTvvv7KtITmkF7D1R8JO0C6NYRZr1PgeBOq67y+S1PvnPDYTb3XDySmIu
	00Jb1N4OsDr0m3bNILgIJdirqDaGotDNBP6gxEqpIjozRNlU+KeG4vOOHxeMhTFFWsy2
	z1KV3joEK97YtcAaVuHdDIxlXEgs/4jTwRHo5g7O8NrM3TpAoYXMe0OFkOC+1rwKGE3G
	chtanQV9rRwuZMHWqFjaRVnO1kd/bw6hcpwXBXkyJqa1YkovlvbSY0DsD+7NQogHZA/3
	6p+v87+kPcQQr3AWWHMLcNIVJrizYthHMQtAEWjYybp8XcBmEa7Ej9w057dcYzqPQ2cT
	keiQ==
Received: by 10.14.224.4 with SMTP id w4mr3205883eep.21.1347548320687;
	Thu, 13 Sep 2012 07:58:40 -0700 (PDT)
Received: from [192.168.1.69] (host86-184-74-117.range86-184.btcentralplus.com.
	[86.184.74.117])
	by mx.google.com with ESMTPS id z3sm65844659eel.15.2012.09.13.07.58.37
	(version=SSLv3 cipher=OTHER); Thu, 13 Sep 2012 07:58:38 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Thu, 13 Sep 2012 15:58:34 +0100
From: Keir Fraser <keir.xen@gmail.com>
To: Tim Deegan <tim@xen.org>,
	Jan Beulich <JBeulich@suse.com>
Message-ID: <CC77B32A.3EA62%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [PATCH] x86/mm: remove the linear mapping of the p2m
	tables
Thread-Index: Ac2RwD77/wB1F8tQAEyJiZ6LSSiQCA==
In-Reply-To: <20120913144251.GC12881@ocelot.phlegethon.org>
Mime-version: 1.0
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] x86/mm: remove the linear mapping of the
 p2m tables
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 13/09/2012 15:42, "Tim Deegan" <tim@xen.org> wrote:

>> Is that also going to remain true when we won't be able to 1:1-
>> map all of the memory anymore once we break the current 5Tb
>> barrier? If not, it would probably be worthwhile keeping that
>> code.
> 
> Ah, 5TB is a smaller limit than I thought we had.  Yes, better leave it
> alone, so.  Though TBH finding some way to use a bit more virtual
> address space for Xen seems like a good idea anyway, since this won't be
> the only place we'll want to avoid TLB flushes.

For HVM or PVH guests, where this HAP code would be used, clearly Xen can
use all the virtual address space it wants. It will almost certainly make
sense for Xen to have a 1:1 physical mapping of all memory when running such
a guest, and only do mapcache type tricks when running legacy PV guests.

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 13 14:58:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Sep 2012 14: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 1TCAsN-0002vR-JR; Thu, 13 Sep 2012 14:58:43 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1TCAsM-0002vG-71
	for xen-devel@lists.xen.org; Thu, 13 Sep 2012 14:58:42 +0000
Received: from [85.158.143.35:63352] by server-3.bemta-4.messagelabs.com id
	D4/94-08232-1A4F1505; Thu, 13 Sep 2012 14:58:41 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1347548320!13542516!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-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2198 invoked from network); 13 Sep 2012 14:58:41 -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;
	13 Sep 2012 14:58:41 -0000
Received: by eeke53 with SMTP id e53so2097981eek.32
	for <xen-devel@lists.xen.org>; Thu, 13 Sep 2012 07:58:40 -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=3mlt6b1Q1oWeSXTF6t2EK/zFYkJMQaIKO9qgU9me/qo=;
	b=jOepq+dn0NTvvv7KtITmkF7D1R8JO0C6NYRZr1PgeBOq67y+S1PvnPDYTb3XDySmIu
	00Jb1N4OsDr0m3bNILgIJdirqDaGotDNBP6gxEqpIjozRNlU+KeG4vOOHxeMhTFFWsy2
	z1KV3joEK97YtcAaVuHdDIxlXEgs/4jTwRHo5g7O8NrM3TpAoYXMe0OFkOC+1rwKGE3G
	chtanQV9rRwuZMHWqFjaRVnO1kd/bw6hcpwXBXkyJqa1YkovlvbSY0DsD+7NQogHZA/3
	6p+v87+kPcQQr3AWWHMLcNIVJrizYthHMQtAEWjYybp8XcBmEa7Ej9w057dcYzqPQ2cT
	keiQ==
Received: by 10.14.224.4 with SMTP id w4mr3205883eep.21.1347548320687;
	Thu, 13 Sep 2012 07:58:40 -0700 (PDT)
Received: from [192.168.1.69] (host86-184-74-117.range86-184.btcentralplus.com.
	[86.184.74.117])
	by mx.google.com with ESMTPS id z3sm65844659eel.15.2012.09.13.07.58.37
	(version=SSLv3 cipher=OTHER); Thu, 13 Sep 2012 07:58:38 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Thu, 13 Sep 2012 15:58:34 +0100
From: Keir Fraser <keir.xen@gmail.com>
To: Tim Deegan <tim@xen.org>,
	Jan Beulich <JBeulich@suse.com>
Message-ID: <CC77B32A.3EA62%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [PATCH] x86/mm: remove the linear mapping of the p2m
	tables
Thread-Index: Ac2RwD77/wB1F8tQAEyJiZ6LSSiQCA==
In-Reply-To: <20120913144251.GC12881@ocelot.phlegethon.org>
Mime-version: 1.0
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] x86/mm: remove the linear mapping of the
 p2m tables
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 13/09/2012 15:42, "Tim Deegan" <tim@xen.org> wrote:

>> Is that also going to remain true when we won't be able to 1:1-
>> map all of the memory anymore once we break the current 5Tb
>> barrier? If not, it would probably be worthwhile keeping that
>> code.
> 
> Ah, 5TB is a smaller limit than I thought we had.  Yes, better leave it
> alone, so.  Though TBH finding some way to use a bit more virtual
> address space for Xen seems like a good idea anyway, since this won't be
> the only place we'll want to avoid TLB flushes.

For HVM or PVH guests, where this HAP code would be used, clearly Xen can
use all the virtual address space it wants. It will almost certainly make
sense for Xen to have a 1:1 physical mapping of all memory when running such
a guest, and only do mapcache type tricks when running legacy PV guests.

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 13 15:00:38 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Sep 2012 15: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 1TCAu3-00034C-2v; Thu, 13 Sep 2012 15:00:27 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1TCAu1-000343-Mg
	for xen-devel@lists.xen.org; Thu, 13 Sep 2012 15:00:25 +0000
Received: from [85.158.139.83:32258] by server-11.bemta-5.messagelabs.com id
	A1/B3-24658-905F1505; Thu, 13 Sep 2012 15:00:25 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1347548424!30631913!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDkwMjg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23160 invoked from network); 13 Sep 2012 15:00:24 -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;
	13 Sep 2012 15:00:24 -0000
X-IronPort-AV: E=Sophos;i="4.80,417,1344211200"; d="scan'208";a="14524731"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Sep 2012 15:00: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.279.1; Thu, 13 Sep 2012 16:00: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
	1TCAtc-0006gr-6V; Thu, 13 Sep 2012 15:00:00 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1TCAtc-0005qs-1r;
	Thu, 13 Sep 2012 16:00:00 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20561.62703.748906.832987@mariner.uk.xensource.com>
Date: Thu, 13 Sep 2012 15:59:59 +0100
To: "Jan Beulich" <JBeulich@suse.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <504F3E69020000780009A8DB@nat28.tlf.novell.com>
References: <504F3E69020000780009A8DB@nat28.tlf.novell.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 1/2] x86: construct static parts of 1:1
 mapping at build 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

Jan Beulich writes ("[Xen-devel] [PATCH 1/2] x86: construct static parts of 1:1 mapping at build time"):
> ... rather than at boot time, removing unnecessary redundancy between
> EFI and legacy boot code.

Do you think you could get your patchbomb software to link the
multiple messages in a single patch series via the References
headers ?

That would make navigating and handling your series much easier for
me.

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 Sep 13 15:00:38 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Sep 2012 15: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 1TCAu3-00034C-2v; Thu, 13 Sep 2012 15:00:27 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1TCAu1-000343-Mg
	for xen-devel@lists.xen.org; Thu, 13 Sep 2012 15:00:25 +0000
Received: from [85.158.139.83:32258] by server-11.bemta-5.messagelabs.com id
	A1/B3-24658-905F1505; Thu, 13 Sep 2012 15:00:25 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1347548424!30631913!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDkwMjg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23160 invoked from network); 13 Sep 2012 15:00:24 -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;
	13 Sep 2012 15:00:24 -0000
X-IronPort-AV: E=Sophos;i="4.80,417,1344211200"; d="scan'208";a="14524731"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Sep 2012 15:00: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.279.1; Thu, 13 Sep 2012 16:00: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
	1TCAtc-0006gr-6V; Thu, 13 Sep 2012 15:00:00 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1TCAtc-0005qs-1r;
	Thu, 13 Sep 2012 16:00:00 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20561.62703.748906.832987@mariner.uk.xensource.com>
Date: Thu, 13 Sep 2012 15:59:59 +0100
To: "Jan Beulich" <JBeulich@suse.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <504F3E69020000780009A8DB@nat28.tlf.novell.com>
References: <504F3E69020000780009A8DB@nat28.tlf.novell.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 1/2] x86: construct static parts of 1:1
 mapping at build 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

Jan Beulich writes ("[Xen-devel] [PATCH 1/2] x86: construct static parts of 1:1 mapping at build time"):
> ... rather than at boot time, removing unnecessary redundancy between
> EFI and legacy boot code.

Do you think you could get your patchbomb software to link the
multiple messages in a single patch series via the References
headers ?

That would make navigating and handling your series much easier for
me.

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 Sep 13 15:03:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Sep 2012 15: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 1TCAxB-0003Gp-SJ; Thu, 13 Sep 2012 15:03:41 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1TCAxA-0003Gf-DH
	for xen-devel@lists.xen.org; Thu, 13 Sep 2012 15:03:40 +0000
Received: from [85.158.137.99:47266] by server-11.bemta-3.messagelabs.com id
	B4/57-30250-BC5F1505; Thu, 13 Sep 2012 15:03:39 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-12.tower-217.messagelabs.com!1347548618!14391387!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQxMjE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6548 invoked from network); 13 Sep 2012 15:03:39 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-12.tower-217.messagelabs.com with SMTP;
	13 Sep 2012 15:03:39 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 13 Sep 2012 16:03:37 +0100
Message-Id: <5052121F020000780009B1E9@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 13 Sep 2012 16:04:31 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Daniel De Graaf" <dgdegra@tycho.nsa.gov>
References: <1347465586-20009-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1347465586-20009-20-git-send-email-dgdegra@tycho.nsa.gov>
	<5051AED7020000780009AFC3@nat28.tlf.novell.com>
	<5051E3AC.2060700@tycho.nsa.gov>
	<50520634020000780009B162@nat28.tlf.novell.com>
	<5051ECC7.7050901@tycho.nsa.gov>
In-Reply-To: <5051ECC7.7050901@tycho.nsa.gov>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Tim Deegan <tim@xen.org>, Keir Fraser <keir@xen.org>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 19/22] arch/x86: check remote MMIO remap
 permissions
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.09.12 at 16:25, Daniel De Graaf <dgdegra@tycho.nsa.gov> wrote:
> On 09/13/2012 10:13 AM, Jan Beulich wrote:
>>>>> On 13.09.12 at 15:46, Daniel De Graaf <dgdegra@tycho.nsa.gov> wrote:
>>> On 09/13/2012 04:00 AM, Jan Beulich wrote:
>>>>>>> On 12.09.12 at 17:59, Daniel De Graaf <dgdegra@tycho.nsa.gov> wrote:
>>>>> When a domain is mapping pages from a different pg_owner domain, the
>>>>> iomem_access checks are currently only applied to the pg_owner domain,
>>>>> potentially allowing the current domain to bypass its more restrictive
>>>>> iomem_access policy using another domain that it has access to.
>>>>
>>>> Are you sure about this? I ask because ...
>>>>
>>>>> --- a/xen/arch/x86/mm.c
>>>>> +++ b/xen/arch/x86/mm.c
>>>>> @@ -754,6 +754,18 @@ get_page_from_l1e(
>>>>>              return -EINVAL;
>>>>>          }
>>>>>  
>>>>> +        if ( pg_owner != curr->domain &&
>>>>> +             !iomem_access_permitted(curr->domain, mfn, mfn) )
>>>>> +        {
>>>>> +            if ( mfn != (PADDR_MASK >> PAGE_SHIFT) ) /* INVALID_MFN? */
>>>>> +            {
>>>>> +                MEM_LOG("Domain %u attempted to map I/O space %08lx in 
>>> domain %u",
>>>>> +                        curr->domain->domain_id, mfn, pg_owner->domain_id);
>>>>> +                return -EPERM;
>>>>> +            }
>>>>> +            return -EINVAL;
>>>>> +        }
>>>>> +
>>>>
>>>> ... the place you insert this is after non-RAM pages got filtered
>>>> out already, so you're applying an IOMEM permission check to a
>>>> RAM page.
>>>>
>>>> Jan
>>>>
>>>>>          if ( !(l1f & _PAGE_RW) ||
>>>>>               !rangeset_contains_singleton(mmio_ro_ranges, mfn) )
>>>>>              return 0;
>>>
>>> If that's true, then the check a few lines above is also applying IOMEM
>>> checks to RAM pages. I can see non-privileged attempts being filtered
>>> above,
> 
> "above" refers to "if ( !iomem_access_permitted(pg_owner, mfn, mfn) )"
>  
>> I can't see how that would happen given this primary conditional
>> 
>>     if ( !mfn_valid(mfn) ||
>>          (real_pg_owner = page_get_owner_and_reference(page)) == dom_io )
>> 
>> Please clarify what you're observing.
> 
> As I understand it, the contents of this block will be executed if the MFN 
> is
> invalid (interpreted as MMIO space) or if the page's owner is DOMID_IO, 
> which
> is how MMIO space is marked.
> 
>>> but successful mappings will continue to the check I added.
>> 
>> Of course. I would think that if anything, you would want to add
>> a second call to iomem_access_permitted() with "curr->domain"
>> right at the place where the current one is (in particular inside
>> the above quoted conditional).
>> 
>> Jan
> 
> I was emulating the existing iomem_access_permitted check being run on 
> pg_owner;
> moving the curr->domain check up into this first conditional would end up
> treating the MMIO mapping as a regular RAM mapping if the 
> iomem_access_permitted
> fails. Unless you're talking about a different quoted conditional?

I'm sorry, each of your replies get me more confused. Can you,
with the current code (i.e. without your patches or any emulation
you might be doing) explain (perhaps with an example) what
specific case you see needing more checking than there is
currently? That would probably allow us to start talking about the
same thing.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 13 15:03:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Sep 2012 15: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 1TCAxB-0003Gp-SJ; Thu, 13 Sep 2012 15:03:41 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1TCAxA-0003Gf-DH
	for xen-devel@lists.xen.org; Thu, 13 Sep 2012 15:03:40 +0000
Received: from [85.158.137.99:47266] by server-11.bemta-3.messagelabs.com id
	B4/57-30250-BC5F1505; Thu, 13 Sep 2012 15:03:39 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-12.tower-217.messagelabs.com!1347548618!14391387!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQxMjE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6548 invoked from network); 13 Sep 2012 15:03:39 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-12.tower-217.messagelabs.com with SMTP;
	13 Sep 2012 15:03:39 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 13 Sep 2012 16:03:37 +0100
Message-Id: <5052121F020000780009B1E9@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 13 Sep 2012 16:04:31 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Daniel De Graaf" <dgdegra@tycho.nsa.gov>
References: <1347465586-20009-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1347465586-20009-20-git-send-email-dgdegra@tycho.nsa.gov>
	<5051AED7020000780009AFC3@nat28.tlf.novell.com>
	<5051E3AC.2060700@tycho.nsa.gov>
	<50520634020000780009B162@nat28.tlf.novell.com>
	<5051ECC7.7050901@tycho.nsa.gov>
In-Reply-To: <5051ECC7.7050901@tycho.nsa.gov>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Tim Deegan <tim@xen.org>, Keir Fraser <keir@xen.org>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 19/22] arch/x86: check remote MMIO remap
 permissions
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.09.12 at 16:25, Daniel De Graaf <dgdegra@tycho.nsa.gov> wrote:
> On 09/13/2012 10:13 AM, Jan Beulich wrote:
>>>>> On 13.09.12 at 15:46, Daniel De Graaf <dgdegra@tycho.nsa.gov> wrote:
>>> On 09/13/2012 04:00 AM, Jan Beulich wrote:
>>>>>>> On 12.09.12 at 17:59, Daniel De Graaf <dgdegra@tycho.nsa.gov> wrote:
>>>>> When a domain is mapping pages from a different pg_owner domain, the
>>>>> iomem_access checks are currently only applied to the pg_owner domain,
>>>>> potentially allowing the current domain to bypass its more restrictive
>>>>> iomem_access policy using another domain that it has access to.
>>>>
>>>> Are you sure about this? I ask because ...
>>>>
>>>>> --- a/xen/arch/x86/mm.c
>>>>> +++ b/xen/arch/x86/mm.c
>>>>> @@ -754,6 +754,18 @@ get_page_from_l1e(
>>>>>              return -EINVAL;
>>>>>          }
>>>>>  
>>>>> +        if ( pg_owner != curr->domain &&
>>>>> +             !iomem_access_permitted(curr->domain, mfn, mfn) )
>>>>> +        {
>>>>> +            if ( mfn != (PADDR_MASK >> PAGE_SHIFT) ) /* INVALID_MFN? */
>>>>> +            {
>>>>> +                MEM_LOG("Domain %u attempted to map I/O space %08lx in 
>>> domain %u",
>>>>> +                        curr->domain->domain_id, mfn, pg_owner->domain_id);
>>>>> +                return -EPERM;
>>>>> +            }
>>>>> +            return -EINVAL;
>>>>> +        }
>>>>> +
>>>>
>>>> ... the place you insert this is after non-RAM pages got filtered
>>>> out already, so you're applying an IOMEM permission check to a
>>>> RAM page.
>>>>
>>>> Jan
>>>>
>>>>>          if ( !(l1f & _PAGE_RW) ||
>>>>>               !rangeset_contains_singleton(mmio_ro_ranges, mfn) )
>>>>>              return 0;
>>>
>>> If that's true, then the check a few lines above is also applying IOMEM
>>> checks to RAM pages. I can see non-privileged attempts being filtered
>>> above,
> 
> "above" refers to "if ( !iomem_access_permitted(pg_owner, mfn, mfn) )"
>  
>> I can't see how that would happen given this primary conditional
>> 
>>     if ( !mfn_valid(mfn) ||
>>          (real_pg_owner = page_get_owner_and_reference(page)) == dom_io )
>> 
>> Please clarify what you're observing.
> 
> As I understand it, the contents of this block will be executed if the MFN 
> is
> invalid (interpreted as MMIO space) or if the page's owner is DOMID_IO, 
> which
> is how MMIO space is marked.
> 
>>> but successful mappings will continue to the check I added.
>> 
>> Of course. I would think that if anything, you would want to add
>> a second call to iomem_access_permitted() with "curr->domain"
>> right at the place where the current one is (in particular inside
>> the above quoted conditional).
>> 
>> Jan
> 
> I was emulating the existing iomem_access_permitted check being run on 
> pg_owner;
> moving the curr->domain check up into this first conditional would end up
> treating the MMIO mapping as a regular RAM mapping if the 
> iomem_access_permitted
> fails. Unless you're talking about a different quoted conditional?

I'm sorry, each of your replies get me more confused. Can you,
with the current code (i.e. without your patches or any emulation
you might be doing) explain (perhaps with an example) what
specific case you see needing more checking than there is
currently? That would probably allow us to start talking about the
same thing.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 13 15:05:29 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Sep 2012 15:05:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TCAyg-0003NO-BY; Thu, 13 Sep 2012 15:05:14 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1TCAye-0003ND-Bp
	for xen-devel@lists.xen.org; Thu, 13 Sep 2012 15:05:12 +0000
Received: from [85.158.137.99:23103] by server-8.bemta-3.messagelabs.com id
	81/38-24700-726F1505; Thu, 13 Sep 2012 15:05:11 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-217.messagelabs.com!1347548710!17531827!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQxMjE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32607 invoked from network); 13 Sep 2012 15:05:10 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-10.tower-217.messagelabs.com with SMTP;
	13 Sep 2012 15:05:10 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 13 Sep 2012 16:05:10 +0100
Message-Id: <5052127C020000780009B1EC@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 13 Sep 2012 16:06:04 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Tim Deegan" <tim@xen.org>
References: <CAFw--Dd0k7L+T_UJc0yHAkUGrY_-GDHaQjK3OM-1UdOp=J-wAQ@mail.gmail.com>
	<20120907085036.GA71093@ocelot.phlegethon.org>
	<5049E2C70200007800099B21@nat28.tlf.novell.com>
	<20120913101120.GA12881@ocelot.phlegethon.org>
	<5051E531020000780009B083@nat28.tlf.novell.com>
	<20120913122130.GB12881@ocelot.phlegethon.org>
	<50520368020000780009B128@nat28.tlf.novell.com>
	<20120913145524.GD12881@ocelot.phlegethon.org>
In-Reply-To: <20120913145524.GD12881@ocelot.phlegethon.org>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Paolo Bonzini <pbonzini@redhat.com>, Jeffrey Karrels <karrelsj@gmail.com>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Clang/LLVM version requirements
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.09.12 at 16:55, Tim Deegan <tim@xen.org> wrote:
> At 15:01 +0100 on 13 Sep (1347548504), Jan Beulich wrote:
>> >>> On 13.09.12 at 14:21, Tim Deegan <tim@xen.org> wrote:
>> > Allowing BSS would just need a few extra runes (AFAICS,
>> > "--set-section-flags .bss=alloc,load,contents") in the objcopy that
>> > makes reloc.bin.
>> >  But I'm not sure how to make sure everything is
>> > rip-relative, do if that's the real concern I'm inclined to go with
>> > this compile-time check and exclude .[ro]data[.*] as well.
>> > We can always fix it up to allow bss and data sections if we ever
>> > actually need them.
>> 
>> As said, I'm fine with any approach as long as it works with all
>> supported tool chains. So feel free to go the route you're
>> proposing.
> 
> OK.  The patch below works for me on gccs 4.1 to 4.7 and clang 3.0.
> I tries gcc 3.4 but the build already fails in a few other places.
> Do we really still support gcc 3.4 like the README says?
> 
> Can I have an Ack, or would you like to apply it yourself?

Acked-by: Jan Beulich <jbeulich@suse.com>

> # HG changeset patch
> # Parent 9e46d90d0182979a7220314ca19d2525e338aa5d
> x86: check for data and BSS in reloc code at compile time.
> 
> This is a more useful failure mode than hanging at boot time, and
> incidentally fixes the clang/LLVM build by removing a .subsection rune.
> 
> Signed-off-by: Tim Deegan <tim@xen.org>
> 
> diff -r 9e46d90d0182 xen/arch/x86/boot/build32.mk
> --- a/xen/arch/x86/boot/build32.mk	Thu Sep 13 15:00:26 2012 +0100
> +++ b/xen/arch/x86/boot/build32.mk	Thu Sep 13 15:04:32 2012 +0100
> @@ -20,6 +20,15 @@ CFLAGS := $(filter-out -flto,$(CFLAGS))
>  
>  %.o: %.c
>  	$(CC) $(CFLAGS) -c -fpic $< -o $@
> +	$(OBJDUMP) -h $@ | sed -n '/[0-9]/{s,00*,0,g;p}' |\
> +		while read idx name sz rest; do \
> +			case "$$name" in \
> +			.data|.data.*|.rodata|.rodata.*|.bss|.bss.*) \
> +				test $$sz != 0 || continue; \
> +				echo "Error: non-empty $$name: 0x$$sz" >&2; \
> +				exit $$(expr $$idx + 1);; \
> +			esac; \
> +		done
>  
>  reloc.o: $(BASEDIR)/include/asm-x86/config.h
>  .PRECIOUS: %.bin %.lnk
> diff -r 9e46d90d0182 xen/arch/x86/boot/reloc.c
> --- a/xen/arch/x86/boot/reloc.c	Thu Sep 13 15:00:26 2012 +0100
> +++ b/xen/arch/x86/boot/reloc.c	Thu Sep 13 15:04:32 2012 +0100
> @@ -18,10 +18,7 @@ asm (
>      "    call 1f                       \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"
> +    "    jmp  reloc                    \n"
>      );
>  
>  /* This is our data.  Because the code must be relocatable, no BSS is
> @@ -30,9 +27,6 @@ asm (
>  asm (
>      "alloc:                            \n"
>      "    .long 0                       \n"
> -    "    .subsection 1                 \n"
> -    "    .p2align 4, 0xcc              \n"
> -    "    .subsection 0                 \n"
>      );
>  
>  typedef unsigned int u32;




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 13 15:05:29 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Sep 2012 15:05:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TCAyg-0003NO-BY; Thu, 13 Sep 2012 15:05:14 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1TCAye-0003ND-Bp
	for xen-devel@lists.xen.org; Thu, 13 Sep 2012 15:05:12 +0000
Received: from [85.158.137.99:23103] by server-8.bemta-3.messagelabs.com id
	81/38-24700-726F1505; Thu, 13 Sep 2012 15:05:11 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-217.messagelabs.com!1347548710!17531827!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQxMjE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32607 invoked from network); 13 Sep 2012 15:05:10 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-10.tower-217.messagelabs.com with SMTP;
	13 Sep 2012 15:05:10 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 13 Sep 2012 16:05:10 +0100
Message-Id: <5052127C020000780009B1EC@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 13 Sep 2012 16:06:04 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Tim Deegan" <tim@xen.org>
References: <CAFw--Dd0k7L+T_UJc0yHAkUGrY_-GDHaQjK3OM-1UdOp=J-wAQ@mail.gmail.com>
	<20120907085036.GA71093@ocelot.phlegethon.org>
	<5049E2C70200007800099B21@nat28.tlf.novell.com>
	<20120913101120.GA12881@ocelot.phlegethon.org>
	<5051E531020000780009B083@nat28.tlf.novell.com>
	<20120913122130.GB12881@ocelot.phlegethon.org>
	<50520368020000780009B128@nat28.tlf.novell.com>
	<20120913145524.GD12881@ocelot.phlegethon.org>
In-Reply-To: <20120913145524.GD12881@ocelot.phlegethon.org>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Paolo Bonzini <pbonzini@redhat.com>, Jeffrey Karrels <karrelsj@gmail.com>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Clang/LLVM version requirements
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.09.12 at 16:55, Tim Deegan <tim@xen.org> wrote:
> At 15:01 +0100 on 13 Sep (1347548504), Jan Beulich wrote:
>> >>> On 13.09.12 at 14:21, Tim Deegan <tim@xen.org> wrote:
>> > Allowing BSS would just need a few extra runes (AFAICS,
>> > "--set-section-flags .bss=alloc,load,contents") in the objcopy that
>> > makes reloc.bin.
>> >  But I'm not sure how to make sure everything is
>> > rip-relative, do if that's the real concern I'm inclined to go with
>> > this compile-time check and exclude .[ro]data[.*] as well.
>> > We can always fix it up to allow bss and data sections if we ever
>> > actually need them.
>> 
>> As said, I'm fine with any approach as long as it works with all
>> supported tool chains. So feel free to go the route you're
>> proposing.
> 
> OK.  The patch below works for me on gccs 4.1 to 4.7 and clang 3.0.
> I tries gcc 3.4 but the build already fails in a few other places.
> Do we really still support gcc 3.4 like the README says?
> 
> Can I have an Ack, or would you like to apply it yourself?

Acked-by: Jan Beulich <jbeulich@suse.com>

> # HG changeset patch
> # Parent 9e46d90d0182979a7220314ca19d2525e338aa5d
> x86: check for data and BSS in reloc code at compile time.
> 
> This is a more useful failure mode than hanging at boot time, and
> incidentally fixes the clang/LLVM build by removing a .subsection rune.
> 
> Signed-off-by: Tim Deegan <tim@xen.org>
> 
> diff -r 9e46d90d0182 xen/arch/x86/boot/build32.mk
> --- a/xen/arch/x86/boot/build32.mk	Thu Sep 13 15:00:26 2012 +0100
> +++ b/xen/arch/x86/boot/build32.mk	Thu Sep 13 15:04:32 2012 +0100
> @@ -20,6 +20,15 @@ CFLAGS := $(filter-out -flto,$(CFLAGS))
>  
>  %.o: %.c
>  	$(CC) $(CFLAGS) -c -fpic $< -o $@
> +	$(OBJDUMP) -h $@ | sed -n '/[0-9]/{s,00*,0,g;p}' |\
> +		while read idx name sz rest; do \
> +			case "$$name" in \
> +			.data|.data.*|.rodata|.rodata.*|.bss|.bss.*) \
> +				test $$sz != 0 || continue; \
> +				echo "Error: non-empty $$name: 0x$$sz" >&2; \
> +				exit $$(expr $$idx + 1);; \
> +			esac; \
> +		done
>  
>  reloc.o: $(BASEDIR)/include/asm-x86/config.h
>  .PRECIOUS: %.bin %.lnk
> diff -r 9e46d90d0182 xen/arch/x86/boot/reloc.c
> --- a/xen/arch/x86/boot/reloc.c	Thu Sep 13 15:00:26 2012 +0100
> +++ b/xen/arch/x86/boot/reloc.c	Thu Sep 13 15:04:32 2012 +0100
> @@ -18,10 +18,7 @@ asm (
>      "    call 1f                       \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"
> +    "    jmp  reloc                    \n"
>      );
>  
>  /* This is our data.  Because the code must be relocatable, no BSS is
> @@ -30,9 +27,6 @@ asm (
>  asm (
>      "alloc:                            \n"
>      "    .long 0                       \n"
> -    "    .subsection 1                 \n"
> -    "    .p2align 4, 0xcc              \n"
> -    "    .subsection 0                 \n"
>      );
>  
>  typedef unsigned int u32;




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 13 15:06:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Sep 2012 15:06:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TCAzT-0003Rt-Q4; Thu, 13 Sep 2012 15:06:03 +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 1TCAzS-0003Rk-6L
	for xen-devel@lists.xen.org; Thu, 13 Sep 2012 15:06:02 +0000
Received: from [85.158.143.35:57232] by server-2.bemta-4.messagelabs.com id
	37/E1-21239-956F1505; Thu, 13 Sep 2012 15:06:01 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1347548760!12311718!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-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15831 invoked from network); 13 Sep 2012 15:06:00 -0000
Received: from mail-ey0-f173.google.com (HELO mail-ey0-f173.google.com)
	(209.85.215.173)
	by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Sep 2012 15:06:00 -0000
Received: by eaac13 with SMTP id c13so1369332eaa.32
	for <xen-devel@lists.xen.org>; Thu, 13 Sep 2012 08:06:00 -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=Bbyz7HAcSftw8ZGIcEjtqMsbTnBNbT8gcwzHrtByd/w=;
	b=Lm/pkz83uO2PWsosteXI7ReXn/mPCDxA3688m/9YheXwHPatJpuH7fgeV9jRa+TTLw
	WFKNM/rEw9Cyv5IC3hzNzDpo8IFRPTYOtw3b7DLJ11fA0BcTuCdBPBhtlJ7nPCPBNW2b
	aPhH8Nu4GQN5cwWcKAZzkSvo0c2ybGi77OgDL5IB6CClH9TRlALIRHrhvtFWYchhpqxU
	HaXTiNGa+FdSClpQ3Gz7HI7YZYURN28LjIWXdl+/SmL78TX1iZdeLdpaSQQ94LyTzhr1
	TCwp6EzX2d0CW3xqn8UpnIitAiqsEZvLQzlEhubq6xvS9VuuwfII5TeY1xoi6/wdcfFP
	+fhA==
Received: by 10.14.179.136 with SMTP id h8mr3233246eem.6.1347548760129;
	Thu, 13 Sep 2012 08:06:00 -0700 (PDT)
Received: from [192.168.1.69] (host86-184-74-117.range86-184.btcentralplus.com.
	[86.184.74.117])
	by mx.google.com with ESMTPS id h2sm65928448eeo.3.2012.09.13.08.05.53
	(version=SSLv3 cipher=OTHER); Thu, 13 Sep 2012 08:05:56 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Thu, 13 Sep 2012 16:05:47 +0100
From: Keir Fraser <keir.xen@gmail.com>
To: Tim Deegan <tim@xen.org>,
	Jan Beulich <JBeulich@suse.com>
Message-ID: <CC77B4DB.3EA68%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] Clang/LLVM version requirements
Thread-Index: Ac2RwUERuong/q0I1Ei8LFkh8loI5w==
In-Reply-To: <20120913145524.GD12881@ocelot.phlegethon.org>
Mime-version: 1.0
Cc: Paolo Bonzini <pbonzini@redhat.com>, Jeffrey Karrels <karrelsj@gmail.com>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Clang/LLVM version requirements
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/09/2012 15:55, "Tim Deegan" <tim@xen.org> wrote:

> At 15:01 +0100 on 13 Sep (1347548504), Jan Beulich wrote:
>>>>> On 13.09.12 at 14:21, Tim Deegan <tim@xen.org> wrote:
>>> Allowing BSS would just need a few extra runes (AFAICS,
>>> "--set-section-flags .bss=alloc,load,contents") in the objcopy that
>>> makes reloc.bin.
>>>  But I'm not sure how to make sure everything is
>>> rip-relative, do if that's the real concern I'm inclined to go with
>>> this compile-time check and exclude .[ro]data[.*] as well.
>>> We can always fix it up to allow bss and data sections if we ever
>>> actually need them.
>> 
>> As said, I'm fine with any approach as long as it works with all
>> supported tool chains. So feel free to go the route you're
>> proposing.
> 
> OK.  The patch below works for me on gccs 4.1 to 4.7 and clang 3.0.
> I tries gcc 3.4 but the build already fails in a few other places.
> Do we really still support gcc 3.4 like the README says?

It's been a long while since we updated our compiler support. In general
I've been happy to say we support each gcc release only for 2-3 years. In
this case that would mean we could *even* update our support to be only gcc
4.2 and later.

What do people think about us forcing this? It might even let us get rid of
GCC_HAS_VISIBILITY_ATTRIBUTE?

 -- Keir

> Can I have an Ack, or would you like to apply it yourself?
> 
> Tim.
> 
> # HG changeset patch
> # Parent 9e46d90d0182979a7220314ca19d2525e338aa5d
> x86: check for data and BSS in reloc code at compile time.
> 
> This is a more useful failure mode than hanging at boot time, and
> incidentally fixes the clang/LLVM build by removing a .subsection rune.
> 
> Signed-off-by: Tim Deegan <tim@xen.org>
> 
> diff -r 9e46d90d0182 xen/arch/x86/boot/build32.mk
> --- a/xen/arch/x86/boot/build32.mk Thu Sep 13 15:00:26 2012 +0100
> +++ b/xen/arch/x86/boot/build32.mk Thu Sep 13 15:04:32 2012 +0100
> @@ -20,6 +20,15 @@ CFLAGS := $(filter-out -flto,$(CFLAGS))
>  
>  %.o: %.c
> $(CC) $(CFLAGS) -c -fpic $< -o $@
> + $(OBJDUMP) -h $@ | sed -n '/[0-9]/{s,00*,0,g;p}' |\
> +  while read idx name sz rest; do \
> +   case "$$name" in \
> +   .data|.data.*|.rodata|.rodata.*|.bss|.bss.*) \
> +    test $$sz != 0 || continue; \
> +    echo "Error: non-empty $$name: 0x$$sz" >&2; \
> +    exit $$(expr $$idx + 1);; \
> +   esac; \
> +  done
>  
>  reloc.o: $(BASEDIR)/include/asm-x86/config.h
>  .PRECIOUS: %.bin %.lnk
> diff -r 9e46d90d0182 xen/arch/x86/boot/reloc.c
> --- a/xen/arch/x86/boot/reloc.c Thu Sep 13 15:00:26 2012 +0100
> +++ b/xen/arch/x86/boot/reloc.c Thu Sep 13 15:04:32 2012 +0100
> @@ -18,10 +18,7 @@ asm (
>      "    call 1f                       \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"
> +    "    jmp  reloc                    \n"
>      );
>  
>  /* This is our data.  Because the code must be relocatable, no BSS is
> @@ -30,9 +27,6 @@ asm (
>  asm (
>      "alloc:                            \n"
>      "    .long 0                       \n"
> -    "    .subsection 1                 \n"
> -    "    .p2align 4, 0xcc              \n"
> -    "    .subsection 0                 \n"
>      );
>  
>  typedef unsigned int u32;
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Sep 13 15:06:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Sep 2012 15:06:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TCAzT-0003Rt-Q4; Thu, 13 Sep 2012 15:06:03 +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 1TCAzS-0003Rk-6L
	for xen-devel@lists.xen.org; Thu, 13 Sep 2012 15:06:02 +0000
Received: from [85.158.143.35:57232] by server-2.bemta-4.messagelabs.com id
	37/E1-21239-956F1505; Thu, 13 Sep 2012 15:06:01 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1347548760!12311718!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-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15831 invoked from network); 13 Sep 2012 15:06:00 -0000
Received: from mail-ey0-f173.google.com (HELO mail-ey0-f173.google.com)
	(209.85.215.173)
	by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Sep 2012 15:06:00 -0000
Received: by eaac13 with SMTP id c13so1369332eaa.32
	for <xen-devel@lists.xen.org>; Thu, 13 Sep 2012 08:06:00 -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=Bbyz7HAcSftw8ZGIcEjtqMsbTnBNbT8gcwzHrtByd/w=;
	b=Lm/pkz83uO2PWsosteXI7ReXn/mPCDxA3688m/9YheXwHPatJpuH7fgeV9jRa+TTLw
	WFKNM/rEw9Cyv5IC3hzNzDpo8IFRPTYOtw3b7DLJ11fA0BcTuCdBPBhtlJ7nPCPBNW2b
	aPhH8Nu4GQN5cwWcKAZzkSvo0c2ybGi77OgDL5IB6CClH9TRlALIRHrhvtFWYchhpqxU
	HaXTiNGa+FdSClpQ3Gz7HI7YZYURN28LjIWXdl+/SmL78TX1iZdeLdpaSQQ94LyTzhr1
	TCwp6EzX2d0CW3xqn8UpnIitAiqsEZvLQzlEhubq6xvS9VuuwfII5TeY1xoi6/wdcfFP
	+fhA==
Received: by 10.14.179.136 with SMTP id h8mr3233246eem.6.1347548760129;
	Thu, 13 Sep 2012 08:06:00 -0700 (PDT)
Received: from [192.168.1.69] (host86-184-74-117.range86-184.btcentralplus.com.
	[86.184.74.117])
	by mx.google.com with ESMTPS id h2sm65928448eeo.3.2012.09.13.08.05.53
	(version=SSLv3 cipher=OTHER); Thu, 13 Sep 2012 08:05:56 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Thu, 13 Sep 2012 16:05:47 +0100
From: Keir Fraser <keir.xen@gmail.com>
To: Tim Deegan <tim@xen.org>,
	Jan Beulich <JBeulich@suse.com>
Message-ID: <CC77B4DB.3EA68%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] Clang/LLVM version requirements
Thread-Index: Ac2RwUERuong/q0I1Ei8LFkh8loI5w==
In-Reply-To: <20120913145524.GD12881@ocelot.phlegethon.org>
Mime-version: 1.0
Cc: Paolo Bonzini <pbonzini@redhat.com>, Jeffrey Karrels <karrelsj@gmail.com>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Clang/LLVM version requirements
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/09/2012 15:55, "Tim Deegan" <tim@xen.org> wrote:

> At 15:01 +0100 on 13 Sep (1347548504), Jan Beulich wrote:
>>>>> On 13.09.12 at 14:21, Tim Deegan <tim@xen.org> wrote:
>>> Allowing BSS would just need a few extra runes (AFAICS,
>>> "--set-section-flags .bss=alloc,load,contents") in the objcopy that
>>> makes reloc.bin.
>>>  But I'm not sure how to make sure everything is
>>> rip-relative, do if that's the real concern I'm inclined to go with
>>> this compile-time check and exclude .[ro]data[.*] as well.
>>> We can always fix it up to allow bss and data sections if we ever
>>> actually need them.
>> 
>> As said, I'm fine with any approach as long as it works with all
>> supported tool chains. So feel free to go the route you're
>> proposing.
> 
> OK.  The patch below works for me on gccs 4.1 to 4.7 and clang 3.0.
> I tries gcc 3.4 but the build already fails in a few other places.
> Do we really still support gcc 3.4 like the README says?

It's been a long while since we updated our compiler support. In general
I've been happy to say we support each gcc release only for 2-3 years. In
this case that would mean we could *even* update our support to be only gcc
4.2 and later.

What do people think about us forcing this? It might even let us get rid of
GCC_HAS_VISIBILITY_ATTRIBUTE?

 -- Keir

> Can I have an Ack, or would you like to apply it yourself?
> 
> Tim.
> 
> # HG changeset patch
> # Parent 9e46d90d0182979a7220314ca19d2525e338aa5d
> x86: check for data and BSS in reloc code at compile time.
> 
> This is a more useful failure mode than hanging at boot time, and
> incidentally fixes the clang/LLVM build by removing a .subsection rune.
> 
> Signed-off-by: Tim Deegan <tim@xen.org>
> 
> diff -r 9e46d90d0182 xen/arch/x86/boot/build32.mk
> --- a/xen/arch/x86/boot/build32.mk Thu Sep 13 15:00:26 2012 +0100
> +++ b/xen/arch/x86/boot/build32.mk Thu Sep 13 15:04:32 2012 +0100
> @@ -20,6 +20,15 @@ CFLAGS := $(filter-out -flto,$(CFLAGS))
>  
>  %.o: %.c
> $(CC) $(CFLAGS) -c -fpic $< -o $@
> + $(OBJDUMP) -h $@ | sed -n '/[0-9]/{s,00*,0,g;p}' |\
> +  while read idx name sz rest; do \
> +   case "$$name" in \
> +   .data|.data.*|.rodata|.rodata.*|.bss|.bss.*) \
> +    test $$sz != 0 || continue; \
> +    echo "Error: non-empty $$name: 0x$$sz" >&2; \
> +    exit $$(expr $$idx + 1);; \
> +   esac; \
> +  done
>  
>  reloc.o: $(BASEDIR)/include/asm-x86/config.h
>  .PRECIOUS: %.bin %.lnk
> diff -r 9e46d90d0182 xen/arch/x86/boot/reloc.c
> --- a/xen/arch/x86/boot/reloc.c Thu Sep 13 15:00:26 2012 +0100
> +++ b/xen/arch/x86/boot/reloc.c Thu Sep 13 15:04:32 2012 +0100
> @@ -18,10 +18,7 @@ asm (
>      "    call 1f                       \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"
> +    "    jmp  reloc                    \n"
>      );
>  
>  /* This is our data.  Because the code must be relocatable, no BSS is
> @@ -30,9 +27,6 @@ asm (
>  asm (
>      "alloc:                            \n"
>      "    .long 0                       \n"
> -    "    .subsection 1                 \n"
> -    "    .p2align 4, 0xcc              \n"
> -    "    .subsection 0                 \n"
>      );
>  
>  typedef unsigned int u32;
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Sep 13 15:07:41 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Sep 2012 15:07:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TCB0s-0003ZD-9H; Thu, 13 Sep 2012 15:07: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 1TCB0r-0003Z1-3d
	for xen-devel@lists.xen.org; Thu, 13 Sep 2012 15:07:29 +0000
Received: from [85.158.137.99:46834] by server-11.bemta-3.messagelabs.com id
	7C/95-30250-0B6F1505; Thu, 13 Sep 2012 15:07:28 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-217.messagelabs.com!1347548847!16324385!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQxMjE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26391 invoked from network); 13 Sep 2012 15:07:27 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-11.tower-217.messagelabs.com with SMTP;
	13 Sep 2012 15:07:27 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 13 Sep 2012 16:07:27 +0100
Message-Id: <50521304020000780009B208@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 13 Sep 2012 16:08:20 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Keir Fraser" <keir.xen@gmail.com>,"Tim Deegan" <tim@xen.org>
References: <20120913144251.GC12881@ocelot.phlegethon.org>
	<CC77B32A.3EA62%keir.xen@gmail.com>
In-Reply-To: <CC77B32A.3EA62%keir.xen@gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] x86/mm: remove the linear mapping of the
 p2m tables
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 13.09.12 at 16:58, Keir Fraser <keir.xen@gmail.com> wrote:
> On 13/09/2012 15:42, "Tim Deegan" <tim@xen.org> wrote:
> 
>>> Is that also going to remain true when we won't be able to 1:1-
>>> map all of the memory anymore once we break the current 5Tb
>>> barrier? If not, it would probably be worthwhile keeping that
>>> code.
>> 
>> Ah, 5TB is a smaller limit than I thought we had.  Yes, better leave it
>> alone, so.  Though TBH finding some way to use a bit more virtual
>> address space for Xen seems like a good idea anyway, since this won't be
>> the only place we'll want to avoid TLB flushes.
> 
> For HVM or PVH guests, where this HAP code would be used, clearly Xen can
> use all the virtual address space it wants. It will almost certainly make
> sense for Xen to have a 1:1 physical mapping of all memory when running such
> a guest, and only do mapcache type tricks when running legacy PV guests.

Yes, that's the mode I indeed wanted to get to. Just that it's
not really clear to me (without having started at least the
work of bumping the boundary) how intrusive those changes
are going to be.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 13 15:07:41 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Sep 2012 15:07:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TCB0s-0003ZD-9H; Thu, 13 Sep 2012 15:07: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 1TCB0r-0003Z1-3d
	for xen-devel@lists.xen.org; Thu, 13 Sep 2012 15:07:29 +0000
Received: from [85.158.137.99:46834] by server-11.bemta-3.messagelabs.com id
	7C/95-30250-0B6F1505; Thu, 13 Sep 2012 15:07:28 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-217.messagelabs.com!1347548847!16324385!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQxMjE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26391 invoked from network); 13 Sep 2012 15:07:27 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-11.tower-217.messagelabs.com with SMTP;
	13 Sep 2012 15:07:27 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 13 Sep 2012 16:07:27 +0100
Message-Id: <50521304020000780009B208@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 13 Sep 2012 16:08:20 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Keir Fraser" <keir.xen@gmail.com>,"Tim Deegan" <tim@xen.org>
References: <20120913144251.GC12881@ocelot.phlegethon.org>
	<CC77B32A.3EA62%keir.xen@gmail.com>
In-Reply-To: <CC77B32A.3EA62%keir.xen@gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] x86/mm: remove the linear mapping of the
 p2m tables
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 13.09.12 at 16:58, Keir Fraser <keir.xen@gmail.com> wrote:
> On 13/09/2012 15:42, "Tim Deegan" <tim@xen.org> wrote:
> 
>>> Is that also going to remain true when we won't be able to 1:1-
>>> map all of the memory anymore once we break the current 5Tb
>>> barrier? If not, it would probably be worthwhile keeping that
>>> code.
>> 
>> Ah, 5TB is a smaller limit than I thought we had.  Yes, better leave it
>> alone, so.  Though TBH finding some way to use a bit more virtual
>> address space for Xen seems like a good idea anyway, since this won't be
>> the only place we'll want to avoid TLB flushes.
> 
> For HVM or PVH guests, where this HAP code would be used, clearly Xen can
> use all the virtual address space it wants. It will almost certainly make
> sense for Xen to have a 1:1 physical mapping of all memory when running such
> a guest, and only do mapcache type tricks when running legacy PV guests.

Yes, that's the mode I indeed wanted to get to. Just that it's
not really clear to me (without having started at least the
work of bumping the boundary) how intrusive those changes
are going to be.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 13 15:09:10 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Sep 2012 15: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 1TCB2F-0003jV-P7; Thu, 13 Sep 2012 15:08:55 +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 1TCB2D-0003jI-Sz
	for xen-devel@lists.xen.org; Thu, 13 Sep 2012 15:08:54 +0000
Received: from [85.158.137.99:14199] by server-5.bemta-3.messagelabs.com id
	1C/9B-13133-407F1505; Thu, 13 Sep 2012 15:08:52 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-7.tower-217.messagelabs.com!1347548931!12727316!1
X-Originating-IP: [63.239.67.9]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16082 invoked from network); 13 Sep 2012 15:08:52 -0000
Received: from emvm-gh1-uea08.nsa.gov (HELO nsa.gov) (63.239.67.9)
	by server-7.tower-217.messagelabs.com with SMTP;
	13 Sep 2012 15:08:52 -0000
X-TM-IMSS-Message-ID: <3ed8ef3b0010edd1@nsa.gov>
Received: from tarius.tycho.ncsc.mil ([144.51.3.1]) by nsa.gov ([63.239.67.9])
	with ESMTP (TREND IMSS SMTP Service 7.1) id 3ed8ef3b0010edd1 ;
	Thu, 13 Sep 2012 11:08:37 -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 q8DF8mUg008082; 
	Thu, 13 Sep 2012 11:08:48 -0400
Message-ID: <5051F700.9060900@tycho.nsa.gov>
Date: Thu, 13 Sep 2012 11:08:48 -0400
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Organization: National Security Agency
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120828 Thunderbird/15.0
MIME-Version: 1.0
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
References: <1347465586-20009-1-git-send-email-dgdegra@tycho.nsa.gov>
	<20561.61335.548996.644196@mariner.uk.xensource.com>
In-Reply-To: <20561.61335.548996.644196@mariner.uk.xensource.com>
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH v3] Merge IS_PRIV checks into XSM hooks
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 09/13/2012 10:37 AM, Ian Jackson wrote:
> Daniel De Graaf writes ("[Xen-devel] [PATCH v3] Merge IS_PRIV checks into XSM hooks"):
>> The ARM architecture is not touched at all in these patches; however,
>> none of the changes should affect ARM. XSM hooks will need to be added
>> for the arch-specific controls in order for FLASK to be useful on ARM,
>> but those changes are outside the scope of this series.
> 
> By "not useful" I guess you mean that it wouldn't have the desired
> security property.  Is there already something that will prevent
> attempts to use xsm on arm ?  The code which enforces this should
> ideally have a comment listing everything that was done to x86 but not
> to arm, so that we have a useful todo list and don't miss anything
> before enabling xsm on arm.
> 
> Ian.
> 

Correct, XSM itself should work (i.e. boot and not crash) on ARM, 
assuming there is support for loading a policy and the xsm_op hypercall
is wired up. The reason I noted that FLASK is not currently useful is
the lack of XSM hooks in various arch-specific functions (do_hvm_op and
arch_memory_op are the ones I have looked at). Adding these hooks
requires moving some of the definitions out of the #ifdef CONFIG_X86
blocks in the XSM code.

The ARM support in xen-unstable.h doesn't currently have any domctls or
sysctls defined; when it does, they will need to be added to the list of
hooks in flask_domctl/flask_sysctl with either an access check or a
pass-through due to the use of another hook. If not, they will trigger a
printk and be denied, so it's fairly easy to catch this.

Beyond the places where IS_PRIV is checked, FLASK hooks to control
access to hardware need to be added where there are ARM-specific
functions. For x86, this involved I/O ports, IRQ<->PIRQ mapping, and PCI
device access; some of these will apply to ARM if device passthrough is
supported there.

-- 
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 Sep 13 15:09:10 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Sep 2012 15: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 1TCB2F-0003jV-P7; Thu, 13 Sep 2012 15:08:55 +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 1TCB2D-0003jI-Sz
	for xen-devel@lists.xen.org; Thu, 13 Sep 2012 15:08:54 +0000
Received: from [85.158.137.99:14199] by server-5.bemta-3.messagelabs.com id
	1C/9B-13133-407F1505; Thu, 13 Sep 2012 15:08:52 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-7.tower-217.messagelabs.com!1347548931!12727316!1
X-Originating-IP: [63.239.67.9]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16082 invoked from network); 13 Sep 2012 15:08:52 -0000
Received: from emvm-gh1-uea08.nsa.gov (HELO nsa.gov) (63.239.67.9)
	by server-7.tower-217.messagelabs.com with SMTP;
	13 Sep 2012 15:08:52 -0000
X-TM-IMSS-Message-ID: <3ed8ef3b0010edd1@nsa.gov>
Received: from tarius.tycho.ncsc.mil ([144.51.3.1]) by nsa.gov ([63.239.67.9])
	with ESMTP (TREND IMSS SMTP Service 7.1) id 3ed8ef3b0010edd1 ;
	Thu, 13 Sep 2012 11:08:37 -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 q8DF8mUg008082; 
	Thu, 13 Sep 2012 11:08:48 -0400
Message-ID: <5051F700.9060900@tycho.nsa.gov>
Date: Thu, 13 Sep 2012 11:08:48 -0400
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Organization: National Security Agency
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120828 Thunderbird/15.0
MIME-Version: 1.0
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
References: <1347465586-20009-1-git-send-email-dgdegra@tycho.nsa.gov>
	<20561.61335.548996.644196@mariner.uk.xensource.com>
In-Reply-To: <20561.61335.548996.644196@mariner.uk.xensource.com>
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH v3] Merge IS_PRIV checks into XSM hooks
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 09/13/2012 10:37 AM, Ian Jackson wrote:
> Daniel De Graaf writes ("[Xen-devel] [PATCH v3] Merge IS_PRIV checks into XSM hooks"):
>> The ARM architecture is not touched at all in these patches; however,
>> none of the changes should affect ARM. XSM hooks will need to be added
>> for the arch-specific controls in order for FLASK to be useful on ARM,
>> but those changes are outside the scope of this series.
> 
> By "not useful" I guess you mean that it wouldn't have the desired
> security property.  Is there already something that will prevent
> attempts to use xsm on arm ?  The code which enforces this should
> ideally have a comment listing everything that was done to x86 but not
> to arm, so that we have a useful todo list and don't miss anything
> before enabling xsm on arm.
> 
> Ian.
> 

Correct, XSM itself should work (i.e. boot and not crash) on ARM, 
assuming there is support for loading a policy and the xsm_op hypercall
is wired up. The reason I noted that FLASK is not currently useful is
the lack of XSM hooks in various arch-specific functions (do_hvm_op and
arch_memory_op are the ones I have looked at). Adding these hooks
requires moving some of the definitions out of the #ifdef CONFIG_X86
blocks in the XSM code.

The ARM support in xen-unstable.h doesn't currently have any domctls or
sysctls defined; when it does, they will need to be added to the list of
hooks in flask_domctl/flask_sysctl with either an access check or a
pass-through due to the use of another hook. If not, they will trigger a
printk and be denied, so it's fairly easy to catch this.

Beyond the places where IS_PRIV is checked, FLASK hooks to control
access to hardware need to be added where there are ARM-specific
functions. For x86, this involved I/O ports, IRQ<->PIRQ mapping, and PCI
device access; some of these will apply to ARM if device passthrough is
supported there.

-- 
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 Sep 13 15:09:30 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Sep 2012 15:09:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TCB2b-0003mr-5S; Thu, 13 Sep 2012 15:09:17 +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 1TCB2Z-0003mV-2U
	for xen-devel@lists.xen.org; Thu, 13 Sep 2012 15:09:15 +0000
Received: from [85.158.139.83:43903] by server-10.bemta-5.messagelabs.com id
	87/3C-10969-A17F1505; Thu, 13 Sep 2012 15:09:14 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1347548951!30026706!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-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17407 invoked from network); 13 Sep 2012 15:09:11 -0000
Received: from mail-ey0-f173.google.com (HELO mail-ey0-f173.google.com)
	(209.85.215.173)
	by server-5.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Sep 2012 15:09:11 -0000
Received: by eaac13 with SMTP id c13so1370618eaa.32
	for <xen-devel@lists.xen.org>; Thu, 13 Sep 2012 08:09:11 -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=hkeMs/YPHOIupazqPutUunTRu/tIU4VVuo9uX9QuHMc=;
	b=gaWBCyU6AWrI95RgXTcR/5T746DFihEbJY7g40hso84rSLDxL4e+Y1B+HXnd7SAkmr
	/hBwVtGviW9f/Ba665E/5VmNVsZ15XWmV+8QDXkTDVyQqAs0dz/ZP2zcrWT0x8OuuYC7
	Wqk6f8vAwqCHzOS3GHz5lZff5njuXaAWxZxxifysKvUyogWUobQhmV/znwXeVZw5RdlX
	ih4tHaNC3RUxwIPAQQCdrQtjXSuGQ/nSvTSiRj0hv0BM9ebsdAY97G5rbozMt2XINFE4
	nGqd5GbN0TKf8fHZWD5/PzUi13pWr94/NvUyecCZk7lXv26DeZ9YydL06QXLmVd5RJjl
	cR8A==
Received: by 10.14.184.133 with SMTP id s5mr3235355eem.31.1347548951079;
	Thu, 13 Sep 2012 08:09:11 -0700 (PDT)
Received: from [192.168.1.69] (host86-184-74-117.range86-184.btcentralplus.com.
	[86.184.74.117])
	by mx.google.com with ESMTPS id z3sm65922336eel.15.2012.09.13.08.09.08
	(version=SSLv3 cipher=OTHER); Thu, 13 Sep 2012 08:09:09 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Thu, 13 Sep 2012 16:09:07 +0100
From: Keir Fraser <keir.xen@gmail.com>
To: Tim Deegan <tim@xen.org>,
	Jan Beulich <JBeulich@suse.com>
Message-ID: <CC77B5A3.3EA85%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] Clang/LLVM version requirements
Thread-Index: Ac2RwUERuong/q0I1Ei8LFkh8loI5wAAHc2y
In-Reply-To: <CC77B4DB.3EA68%keir.xen@gmail.com>
Mime-version: 1.0
Cc: Paolo Bonzini <pbonzini@redhat.com>, Jeffrey Karrels <karrelsj@gmail.com>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Clang/LLVM version requirements
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/09/2012 16:05, "Keir Fraser" <keir.xen@gmail.com> wrote:

> On 13/09/2012 15:55, "Tim Deegan" <tim@xen.org> wrote:
> 
>> At 15:01 +0100 on 13 Sep (1347548504), Jan Beulich wrote:
>>>>>> On 13.09.12 at 14:21, Tim Deegan <tim@xen.org> wrote:
>>>> Allowing BSS would just need a few extra runes (AFAICS,
>>>> "--set-section-flags .bss=alloc,load,contents") in the objcopy that
>>>> makes reloc.bin.
>>>>  But I'm not sure how to make sure everything is
>>>> rip-relative, do if that's the real concern I'm inclined to go with
>>>> this compile-time check and exclude .[ro]data[.*] as well.
>>>> We can always fix it up to allow bss and data sections if we ever
>>>> actually need them.
>>> 
>>> As said, I'm fine with any approach as long as it works with all
>>> supported tool chains. So feel free to go the route you're
>>> proposing.
>> 
>> OK.  The patch below works for me on gccs 4.1 to 4.7 and clang 3.0.
>> I tries gcc 3.4 but the build already fails in a few other places.
>> Do we really still support gcc 3.4 like the README says?
> 
> It's been a long while since we updated our compiler support. In general
> I've been happy to say we support each gcc release only for 2-3 years. In
> this case that would mean we could *even* update our support to be only gcc
> 4.2 and later.
> 
> What do people think about us forcing this? It might even let us get rid of
> GCC_HAS_VISIBILITY_ATTRIBUTE?

I should add, this is mainly a question of how aggressive we should be. I'm
quite happy to retire gcc-3.4 support if it happens it is now broken. In
that case, x86/Rules.mk should have its gcc version check updated. And
perhaps arch/arm may as well do the same? I would be happy to Ack a patch to
that effect.

 -- Keir

>  -- Keir
> 
>> Can I have an Ack, or would you like to apply it yourself?
>> 
>> Tim.
>> 
>> # HG changeset patch
>> # Parent 9e46d90d0182979a7220314ca19d2525e338aa5d
>> x86: check for data and BSS in reloc code at compile time.
>> 
>> This is a more useful failure mode than hanging at boot time, and
>> incidentally fixes the clang/LLVM build by removing a .subsection rune.
>> 
>> Signed-off-by: Tim Deegan <tim@xen.org>
>> 
>> diff -r 9e46d90d0182 xen/arch/x86/boot/build32.mk
>> --- a/xen/arch/x86/boot/build32.mk Thu Sep 13 15:00:26 2012 +0100
>> +++ b/xen/arch/x86/boot/build32.mk Thu Sep 13 15:04:32 2012 +0100
>> @@ -20,6 +20,15 @@ CFLAGS := $(filter-out -flto,$(CFLAGS))
>>  
>>  %.o: %.c
>> $(CC) $(CFLAGS) -c -fpic $< -o $@
>> + $(OBJDUMP) -h $@ | sed -n '/[0-9]/{s,00*,0,g;p}' |\
>> +  while read idx name sz rest; do \
>> +   case "$$name" in \
>> +   .data|.data.*|.rodata|.rodata.*|.bss|.bss.*) \
>> +    test $$sz != 0 || continue; \
>> +    echo "Error: non-empty $$name: 0x$$sz" >&2; \
>> +    exit $$(expr $$idx + 1);; \
>> +   esac; \
>> +  done
>>  
>>  reloc.o: $(BASEDIR)/include/asm-x86/config.h
>>  .PRECIOUS: %.bin %.lnk
>> diff -r 9e46d90d0182 xen/arch/x86/boot/reloc.c
>> --- a/xen/arch/x86/boot/reloc.c Thu Sep 13 15:00:26 2012 +0100
>> +++ b/xen/arch/x86/boot/reloc.c Thu Sep 13 15:04:32 2012 +0100
>> @@ -18,10 +18,7 @@ asm (
>>      "    call 1f                       \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"
>> +    "    jmp  reloc                    \n"
>>      );
>>  
>>  /* This is our data.  Because the code must be relocatable, no BSS is
>> @@ -30,9 +27,6 @@ asm (
>>  asm (
>>      "alloc:                            \n"
>>      "    .long 0                       \n"
>> -    "    .subsection 1                 \n"
>> -    "    .p2align 4, 0xcc              \n"
>> -    "    .subsection 0                 \n"
>>      );
>>  
>>  typedef unsigned int u32;
>> 
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xen.org
>> http://lists.xen.org/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 Sep 13 15:09:30 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Sep 2012 15:09:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TCB2b-0003mr-5S; Thu, 13 Sep 2012 15:09:17 +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 1TCB2Z-0003mV-2U
	for xen-devel@lists.xen.org; Thu, 13 Sep 2012 15:09:15 +0000
Received: from [85.158.139.83:43903] by server-10.bemta-5.messagelabs.com id
	87/3C-10969-A17F1505; Thu, 13 Sep 2012 15:09:14 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1347548951!30026706!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-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17407 invoked from network); 13 Sep 2012 15:09:11 -0000
Received: from mail-ey0-f173.google.com (HELO mail-ey0-f173.google.com)
	(209.85.215.173)
	by server-5.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Sep 2012 15:09:11 -0000
Received: by eaac13 with SMTP id c13so1370618eaa.32
	for <xen-devel@lists.xen.org>; Thu, 13 Sep 2012 08:09:11 -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=hkeMs/YPHOIupazqPutUunTRu/tIU4VVuo9uX9QuHMc=;
	b=gaWBCyU6AWrI95RgXTcR/5T746DFihEbJY7g40hso84rSLDxL4e+Y1B+HXnd7SAkmr
	/hBwVtGviW9f/Ba665E/5VmNVsZ15XWmV+8QDXkTDVyQqAs0dz/ZP2zcrWT0x8OuuYC7
	Wqk6f8vAwqCHzOS3GHz5lZff5njuXaAWxZxxifysKvUyogWUobQhmV/znwXeVZw5RdlX
	ih4tHaNC3RUxwIPAQQCdrQtjXSuGQ/nSvTSiRj0hv0BM9ebsdAY97G5rbozMt2XINFE4
	nGqd5GbN0TKf8fHZWD5/PzUi13pWr94/NvUyecCZk7lXv26DeZ9YydL06QXLmVd5RJjl
	cR8A==
Received: by 10.14.184.133 with SMTP id s5mr3235355eem.31.1347548951079;
	Thu, 13 Sep 2012 08:09:11 -0700 (PDT)
Received: from [192.168.1.69] (host86-184-74-117.range86-184.btcentralplus.com.
	[86.184.74.117])
	by mx.google.com with ESMTPS id z3sm65922336eel.15.2012.09.13.08.09.08
	(version=SSLv3 cipher=OTHER); Thu, 13 Sep 2012 08:09:09 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Thu, 13 Sep 2012 16:09:07 +0100
From: Keir Fraser <keir.xen@gmail.com>
To: Tim Deegan <tim@xen.org>,
	Jan Beulich <JBeulich@suse.com>
Message-ID: <CC77B5A3.3EA85%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] Clang/LLVM version requirements
Thread-Index: Ac2RwUERuong/q0I1Ei8LFkh8loI5wAAHc2y
In-Reply-To: <CC77B4DB.3EA68%keir.xen@gmail.com>
Mime-version: 1.0
Cc: Paolo Bonzini <pbonzini@redhat.com>, Jeffrey Karrels <karrelsj@gmail.com>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Clang/LLVM version requirements
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/09/2012 16:05, "Keir Fraser" <keir.xen@gmail.com> wrote:

> On 13/09/2012 15:55, "Tim Deegan" <tim@xen.org> wrote:
> 
>> At 15:01 +0100 on 13 Sep (1347548504), Jan Beulich wrote:
>>>>>> On 13.09.12 at 14:21, Tim Deegan <tim@xen.org> wrote:
>>>> Allowing BSS would just need a few extra runes (AFAICS,
>>>> "--set-section-flags .bss=alloc,load,contents") in the objcopy that
>>>> makes reloc.bin.
>>>>  But I'm not sure how to make sure everything is
>>>> rip-relative, do if that's the real concern I'm inclined to go with
>>>> this compile-time check and exclude .[ro]data[.*] as well.
>>>> We can always fix it up to allow bss and data sections if we ever
>>>> actually need them.
>>> 
>>> As said, I'm fine with any approach as long as it works with all
>>> supported tool chains. So feel free to go the route you're
>>> proposing.
>> 
>> OK.  The patch below works for me on gccs 4.1 to 4.7 and clang 3.0.
>> I tries gcc 3.4 but the build already fails in a few other places.
>> Do we really still support gcc 3.4 like the README says?
> 
> It's been a long while since we updated our compiler support. In general
> I've been happy to say we support each gcc release only for 2-3 years. In
> this case that would mean we could *even* update our support to be only gcc
> 4.2 and later.
> 
> What do people think about us forcing this? It might even let us get rid of
> GCC_HAS_VISIBILITY_ATTRIBUTE?

I should add, this is mainly a question of how aggressive we should be. I'm
quite happy to retire gcc-3.4 support if it happens it is now broken. In
that case, x86/Rules.mk should have its gcc version check updated. And
perhaps arch/arm may as well do the same? I would be happy to Ack a patch to
that effect.

 -- Keir

>  -- Keir
> 
>> Can I have an Ack, or would you like to apply it yourself?
>> 
>> Tim.
>> 
>> # HG changeset patch
>> # Parent 9e46d90d0182979a7220314ca19d2525e338aa5d
>> x86: check for data and BSS in reloc code at compile time.
>> 
>> This is a more useful failure mode than hanging at boot time, and
>> incidentally fixes the clang/LLVM build by removing a .subsection rune.
>> 
>> Signed-off-by: Tim Deegan <tim@xen.org>
>> 
>> diff -r 9e46d90d0182 xen/arch/x86/boot/build32.mk
>> --- a/xen/arch/x86/boot/build32.mk Thu Sep 13 15:00:26 2012 +0100
>> +++ b/xen/arch/x86/boot/build32.mk Thu Sep 13 15:04:32 2012 +0100
>> @@ -20,6 +20,15 @@ CFLAGS := $(filter-out -flto,$(CFLAGS))
>>  
>>  %.o: %.c
>> $(CC) $(CFLAGS) -c -fpic $< -o $@
>> + $(OBJDUMP) -h $@ | sed -n '/[0-9]/{s,00*,0,g;p}' |\
>> +  while read idx name sz rest; do \
>> +   case "$$name" in \
>> +   .data|.data.*|.rodata|.rodata.*|.bss|.bss.*) \
>> +    test $$sz != 0 || continue; \
>> +    echo "Error: non-empty $$name: 0x$$sz" >&2; \
>> +    exit $$(expr $$idx + 1);; \
>> +   esac; \
>> +  done
>>  
>>  reloc.o: $(BASEDIR)/include/asm-x86/config.h
>>  .PRECIOUS: %.bin %.lnk
>> diff -r 9e46d90d0182 xen/arch/x86/boot/reloc.c
>> --- a/xen/arch/x86/boot/reloc.c Thu Sep 13 15:00:26 2012 +0100
>> +++ b/xen/arch/x86/boot/reloc.c Thu Sep 13 15:04:32 2012 +0100
>> @@ -18,10 +18,7 @@ asm (
>>      "    call 1f                       \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"
>> +    "    jmp  reloc                    \n"
>>      );
>>  
>>  /* This is our data.  Because the code must be relocatable, no BSS is
>> @@ -30,9 +27,6 @@ asm (
>>  asm (
>>      "alloc:                            \n"
>>      "    .long 0                       \n"
>> -    "    .subsection 1                 \n"
>> -    "    .p2align 4, 0xcc              \n"
>> -    "    .subsection 0                 \n"
>>      );
>>  
>>  typedef unsigned int u32;
>> 
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xen.org
>> http://lists.xen.org/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 Sep 13 15:11:19 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Sep 2012 15:11:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TCB4M-00042D-Rx; Thu, 13 Sep 2012 15:11:06 +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 1TCB4I-00041k-Vj
	for xen-devel@lists.xen.org; Thu, 13 Sep 2012 15:11:05 +0000
Received: from [85.158.137.99:42793] by server-2.bemta-3.messagelabs.com id
	08/9E-04862-687F1505; Thu, 13 Sep 2012 15:11:02 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-9.tower-217.messagelabs.com!1347549058!14359904!1
X-Originating-IP: [208.97.132.207]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4yMDcgPT4gMzM2MDI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6723 invoked from network); 13 Sep 2012 15:10:59 -0000
Received: from caiajhbdccah.dreamhost.com (HELO homiemail-a20.g.dreamhost.com)
	(208.97.132.207) by server-9.tower-217.messagelabs.com with SMTP;
	13 Sep 2012 15:10:59 -0000
Received: from homiemail-a20.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a20.g.dreamhost.com (Postfix) with ESMTP id 32A1F7EC072;
	Thu, 13 Sep 2012 08:10:58 -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=D6gFBXe0/BcvRzzLPOVCNS
	g3XNa7TvJkBcYlqdzjzS9vsqY1wRdvzqAfdtu4wcUmTSj3LPhADGZCJIWNWttQjh
	aDzkOb7AIaqq4tTUaHA2fZzX0e04N+/u6vWYEmwhowayuvlurM3X6/OOKRCv2fz0
	K3Y5RZiyrBkt6KGSlWHfI=
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=5Q6uCS3l0R+u
	NEf0xGvhfYRhlUw=; b=iMf/qGxbm3xGhxIjGwzR7y2yGrX/32WSOF8snIkC/1VH
	qHKNYnWhBP5A1nfgnrL0EWPLtA0CQx2PLHbE2PI4a/UQpahTMv2hsbqDuFshB+go
	yeokmooK+WGdbBNQoLx0dO0ZEmKfXV+i8jd7DDALPHGgnyiwGJqrC6JMUI7KbTA=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a20.g.dreamhost.com (Postfix) with ESMTPSA id A97A17EC069; 
	Thu, 13 Sep 2012 08:10:57 -0700 (PDT)
MIME-Version: 1.0
X-Mercurial-Node: bccad6d1fc5fcdb0fa03d1a1572b633f4365135a
Message-Id: <bccad6d1fc5fcdb0fa03.1347549387@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Thu, 13 Sep 2012 11:16:27 -0400
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xen.org
Cc: ian.jackson@citrix.com, andres@gridcentric.ca, ian.campbell@citrix.com
Subject: [Xen-devel] [PATCH] Fix libxenstore memory leak when USE_PTHREAD is
	not defined
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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/xenstore/xs.c |  22 ++++++----------------
 1 files changed, 6 insertions(+), 16 deletions(-)


Remove usage of pthread_cleanup_push and _pop, and explicitly call free for
heap objects in error paths. Also remove cleanup_p* for a mutex unlock path. By
the way, set a suitable errno value for an error path that had none.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r 093d148b092f -r bccad6d1fc5f tools/xenstore/xs.c
--- a/tools/xenstore/xs.c
+++ b/tools/xenstore/xs.c
@@ -99,14 +99,6 @@ struct xs_handle {
 #define mutex_unlock(m)		pthread_mutex_unlock(m)
 #define condvar_signal(c)	pthread_cond_signal(c)
 #define condvar_wait(c,m)	pthread_cond_wait(c,m)
-#define cleanup_push(f, a)	\
-    pthread_cleanup_push((void (*)(void *))(f), (void *)(a))
-/*
- * Some definitions of pthread_cleanup_pop() are a macro starting with an
- * end-brace. GCC then complains if we immediately precede that with a label.
- * Hence we insert a dummy statement to appease the compiler in this situation.
- */
-#define cleanup_pop(run)        ((void)0); pthread_cleanup_pop(run)
 
 #define read_thread_exists(h)	(h->read_thr_exists)
 
@@ -126,8 +118,6 @@ struct xs_handle {
 #define mutex_unlock(m)		((void)0)
 #define condvar_signal(c)	((void)0)
 #define condvar_wait(c,m)	((void)0)
-#define cleanup_push(f, a)	((void)0)
-#define cleanup_pop(run)	((void)0)
 #define read_thread_exists(h)	(0)
 
 #endif
@@ -1059,7 +1049,6 @@ static int read_message(struct xs_handle
 	msg = malloc(sizeof(*msg));
 	if (msg == NULL)
 		goto error;
-	cleanup_push(free, msg);
 	if (!read_all(h->fd, &msg->hdr, sizeof(msg->hdr), nonblocking)) { /* Cancellation point */
 		saved_errno = errno;
 		goto error_freemsg;
@@ -1069,7 +1058,6 @@ static int read_message(struct xs_handle
 	body = msg->body = malloc(msg->hdr.len + 1);
 	if (body == NULL)
 		goto error_freemsg;
-	cleanup_push(free, body);
 	if (!read_all(h->fd, body, msg->hdr.len, 0)) { /* Cancellation point */
 		saved_errno = errno;
 		goto error_freebody;
@@ -1079,7 +1067,6 @@ static int read_message(struct xs_handle
 
 	if (msg->hdr.type == XS_WATCH_EVENT) {
 		mutex_lock(&h->watch_mutex);
-		cleanup_push(pthread_mutex_unlock, &h->watch_mutex);
 
 		/* Kick users out of their select() loop. */
 		if (list_empty(&h->watch_list) &&
@@ -1091,13 +1078,14 @@ static int read_message(struct xs_handle
 
 		condvar_signal(&h->watch_condvar);
 
-		cleanup_pop(1);
+		pthread_mutex_unlock(&h->watch_mutex);
 	} else {
 		mutex_lock(&h->reply_mutex);
 
 		/* There should only ever be one response pending! */
 		if (!list_empty(&h->reply_list)) {
 			mutex_unlock(&h->reply_mutex);
+			saved_errno = EEXIST; 
 			goto error_freebody;
 		}
 
@@ -1110,9 +1098,11 @@ static int read_message(struct xs_handle
 	ret = 0;
 
 error_freebody:
-	cleanup_pop(ret == -1);
+	if (ret)
+		free(body);
 error_freemsg:
-	cleanup_pop(ret == -1);
+	if (ret)
+		free(msg);
 error:
 	errno = saved_errno;
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 13 15:11:19 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Sep 2012 15:11:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TCB4M-00042D-Rx; Thu, 13 Sep 2012 15:11:06 +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 1TCB4I-00041k-Vj
	for xen-devel@lists.xen.org; Thu, 13 Sep 2012 15:11:05 +0000
Received: from [85.158.137.99:42793] by server-2.bemta-3.messagelabs.com id
	08/9E-04862-687F1505; Thu, 13 Sep 2012 15:11:02 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-9.tower-217.messagelabs.com!1347549058!14359904!1
X-Originating-IP: [208.97.132.207]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4yMDcgPT4gMzM2MDI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6723 invoked from network); 13 Sep 2012 15:10:59 -0000
Received: from caiajhbdccah.dreamhost.com (HELO homiemail-a20.g.dreamhost.com)
	(208.97.132.207) by server-9.tower-217.messagelabs.com with SMTP;
	13 Sep 2012 15:10:59 -0000
Received: from homiemail-a20.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a20.g.dreamhost.com (Postfix) with ESMTP id 32A1F7EC072;
	Thu, 13 Sep 2012 08:10:58 -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=D6gFBXe0/BcvRzzLPOVCNS
	g3XNa7TvJkBcYlqdzjzS9vsqY1wRdvzqAfdtu4wcUmTSj3LPhADGZCJIWNWttQjh
	aDzkOb7AIaqq4tTUaHA2fZzX0e04N+/u6vWYEmwhowayuvlurM3X6/OOKRCv2fz0
	K3Y5RZiyrBkt6KGSlWHfI=
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=5Q6uCS3l0R+u
	NEf0xGvhfYRhlUw=; b=iMf/qGxbm3xGhxIjGwzR7y2yGrX/32WSOF8snIkC/1VH
	qHKNYnWhBP5A1nfgnrL0EWPLtA0CQx2PLHbE2PI4a/UQpahTMv2hsbqDuFshB+go
	yeokmooK+WGdbBNQoLx0dO0ZEmKfXV+i8jd7DDALPHGgnyiwGJqrC6JMUI7KbTA=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a20.g.dreamhost.com (Postfix) with ESMTPSA id A97A17EC069; 
	Thu, 13 Sep 2012 08:10:57 -0700 (PDT)
MIME-Version: 1.0
X-Mercurial-Node: bccad6d1fc5fcdb0fa03d1a1572b633f4365135a
Message-Id: <bccad6d1fc5fcdb0fa03.1347549387@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Thu, 13 Sep 2012 11:16:27 -0400
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xen.org
Cc: ian.jackson@citrix.com, andres@gridcentric.ca, ian.campbell@citrix.com
Subject: [Xen-devel] [PATCH] Fix libxenstore memory leak when USE_PTHREAD is
	not defined
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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/xenstore/xs.c |  22 ++++++----------------
 1 files changed, 6 insertions(+), 16 deletions(-)


Remove usage of pthread_cleanup_push and _pop, and explicitly call free for
heap objects in error paths. Also remove cleanup_p* for a mutex unlock path. By
the way, set a suitable errno value for an error path that had none.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r 093d148b092f -r bccad6d1fc5f tools/xenstore/xs.c
--- a/tools/xenstore/xs.c
+++ b/tools/xenstore/xs.c
@@ -99,14 +99,6 @@ struct xs_handle {
 #define mutex_unlock(m)		pthread_mutex_unlock(m)
 #define condvar_signal(c)	pthread_cond_signal(c)
 #define condvar_wait(c,m)	pthread_cond_wait(c,m)
-#define cleanup_push(f, a)	\
-    pthread_cleanup_push((void (*)(void *))(f), (void *)(a))
-/*
- * Some definitions of pthread_cleanup_pop() are a macro starting with an
- * end-brace. GCC then complains if we immediately precede that with a label.
- * Hence we insert a dummy statement to appease the compiler in this situation.
- */
-#define cleanup_pop(run)        ((void)0); pthread_cleanup_pop(run)
 
 #define read_thread_exists(h)	(h->read_thr_exists)
 
@@ -126,8 +118,6 @@ struct xs_handle {
 #define mutex_unlock(m)		((void)0)
 #define condvar_signal(c)	((void)0)
 #define condvar_wait(c,m)	((void)0)
-#define cleanup_push(f, a)	((void)0)
-#define cleanup_pop(run)	((void)0)
 #define read_thread_exists(h)	(0)
 
 #endif
@@ -1059,7 +1049,6 @@ static int read_message(struct xs_handle
 	msg = malloc(sizeof(*msg));
 	if (msg == NULL)
 		goto error;
-	cleanup_push(free, msg);
 	if (!read_all(h->fd, &msg->hdr, sizeof(msg->hdr), nonblocking)) { /* Cancellation point */
 		saved_errno = errno;
 		goto error_freemsg;
@@ -1069,7 +1058,6 @@ static int read_message(struct xs_handle
 	body = msg->body = malloc(msg->hdr.len + 1);
 	if (body == NULL)
 		goto error_freemsg;
-	cleanup_push(free, body);
 	if (!read_all(h->fd, body, msg->hdr.len, 0)) { /* Cancellation point */
 		saved_errno = errno;
 		goto error_freebody;
@@ -1079,7 +1067,6 @@ static int read_message(struct xs_handle
 
 	if (msg->hdr.type == XS_WATCH_EVENT) {
 		mutex_lock(&h->watch_mutex);
-		cleanup_push(pthread_mutex_unlock, &h->watch_mutex);
 
 		/* Kick users out of their select() loop. */
 		if (list_empty(&h->watch_list) &&
@@ -1091,13 +1078,14 @@ static int read_message(struct xs_handle
 
 		condvar_signal(&h->watch_condvar);
 
-		cleanup_pop(1);
+		pthread_mutex_unlock(&h->watch_mutex);
 	} else {
 		mutex_lock(&h->reply_mutex);
 
 		/* There should only ever be one response pending! */
 		if (!list_empty(&h->reply_list)) {
 			mutex_unlock(&h->reply_mutex);
+			saved_errno = EEXIST; 
 			goto error_freebody;
 		}
 
@@ -1110,9 +1098,11 @@ static int read_message(struct xs_handle
 	ret = 0;
 
 error_freebody:
-	cleanup_pop(ret == -1);
+	if (ret)
+		free(body);
 error_freemsg:
-	cleanup_pop(ret == -1);
+	if (ret)
+		free(msg);
 error:
 	errno = saved_errno;
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 13 15:11:33 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Sep 2012 15:11: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 1TCB4Y-00044H-8C; Thu, 13 Sep 2012 15:11: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 1TCB4X-00043t-0B
	for xen-devel@lists.xen.org; Thu, 13 Sep 2012 15:11:17 +0000
Received: from [85.158.137.99:39714] by server-7.bemta-3.messagelabs.com id
	B9/13-32000-497F1505; Thu, 13 Sep 2012 15:11:16 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-14.tower-217.messagelabs.com!1347549075!17503623!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3654 invoked from network); 13 Sep 2012 15:11:15 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-14.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 13 Sep 2012 15:11:15 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1TCB4U-0004V2-R0; Thu, 13 Sep 2012 15:11:14 +0000
Date: Thu, 13 Sep 2012 16:11:14 +0100
From: Tim Deegan <tim@xen.org>
To: Keir Fraser <keir.xen@gmail.com>
Message-ID: <20120913151114.GE12881@ocelot.phlegethon.org>
References: <20120913144251.GC12881@ocelot.phlegethon.org>
	<CC77B32A.3EA62%keir.xen@gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CC77B32A.3EA62%keir.xen@gmail.com>
User-Agent: Mutt/1.4.2.1i
Cc: Jan Beulich <JBeulich@suse.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] x86/mm: remove the linear mapping of the
	p2m tables
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At 15:58 +0100 on 13 Sep (1347551914), Keir Fraser wrote:
> On 13/09/2012 15:42, "Tim Deegan" <tim@xen.org> wrote:
> 
> >> Is that also going to remain true when we won't be able to 1:1-
> >> map all of the memory anymore once we break the current 5Tb
> >> barrier? If not, it would probably be worthwhile keeping that
> >> code.
> > 
> > Ah, 5TB is a smaller limit than I thought we had.  Yes, better leave it
> > alone, so.  Though TBH finding some way to use a bit more virtual
> > address space for Xen seems like a good idea anyway, since this won't be
> > the only place we'll want to avoid TLB flushes.
> 
> For HVM or PVH guests, where this HAP code would be used, clearly Xen can
> use all the virtual address space it wants. It will almost certainly make
> sense for Xen to have a 1:1 physical mapping of all memory when running such
> a guest, and only do mapcache type tricks when running legacy PV guests.

This is also used for shadowed guests, including autotranslated PV
guests, if anyone cares about them any more.  I got the impression that
they're superseded by the pvh stuff; is that right?

If that's the case, then let's commit to having a bigger 1-1 map on HVM
guetst when the time comes to extend past 5TB, and remove this linear
map after all. 

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 13 15:11:33 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Sep 2012 15:11: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 1TCB4Y-00044H-8C; Thu, 13 Sep 2012 15:11: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 1TCB4X-00043t-0B
	for xen-devel@lists.xen.org; Thu, 13 Sep 2012 15:11:17 +0000
Received: from [85.158.137.99:39714] by server-7.bemta-3.messagelabs.com id
	B9/13-32000-497F1505; Thu, 13 Sep 2012 15:11:16 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-14.tower-217.messagelabs.com!1347549075!17503623!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3654 invoked from network); 13 Sep 2012 15:11:15 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-14.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 13 Sep 2012 15:11:15 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1TCB4U-0004V2-R0; Thu, 13 Sep 2012 15:11:14 +0000
Date: Thu, 13 Sep 2012 16:11:14 +0100
From: Tim Deegan <tim@xen.org>
To: Keir Fraser <keir.xen@gmail.com>
Message-ID: <20120913151114.GE12881@ocelot.phlegethon.org>
References: <20120913144251.GC12881@ocelot.phlegethon.org>
	<CC77B32A.3EA62%keir.xen@gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CC77B32A.3EA62%keir.xen@gmail.com>
User-Agent: Mutt/1.4.2.1i
Cc: Jan Beulich <JBeulich@suse.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] x86/mm: remove the linear mapping of the
	p2m tables
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At 15:58 +0100 on 13 Sep (1347551914), Keir Fraser wrote:
> On 13/09/2012 15:42, "Tim Deegan" <tim@xen.org> wrote:
> 
> >> Is that also going to remain true when we won't be able to 1:1-
> >> map all of the memory anymore once we break the current 5Tb
> >> barrier? If not, it would probably be worthwhile keeping that
> >> code.
> > 
> > Ah, 5TB is a smaller limit than I thought we had.  Yes, better leave it
> > alone, so.  Though TBH finding some way to use a bit more virtual
> > address space for Xen seems like a good idea anyway, since this won't be
> > the only place we'll want to avoid TLB flushes.
> 
> For HVM or PVH guests, where this HAP code would be used, clearly Xen can
> use all the virtual address space it wants. It will almost certainly make
> sense for Xen to have a 1:1 physical mapping of all memory when running such
> a guest, and only do mapcache type tricks when running legacy PV guests.

This is also used for shadowed guests, including autotranslated PV
guests, if anyone cares about them any more.  I got the impression that
they're superseded by the pvh stuff; is that right?

If that's the case, then let's commit to having a bigger 1-1 map on HVM
guetst when the time comes to extend past 5TB, and remove this linear
map after all. 

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 13 15:15:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Sep 2012 15:15: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 1TCB87-0004Pv-Ta; Thu, 13 Sep 2012 15:14: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 1TCB85-0004Po-S1
	for xen-devel@lists.xen.org; Thu, 13 Sep 2012 15:14:57 +0000
Received: from [85.158.143.99:53001] by server-3.bemta-4.messagelabs.com id
	39/0F-08232-178F1505; Thu, 13 Sep 2012 15:14:57 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1347549296!29874922!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQxMjE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16735 invoked from network); 13 Sep 2012 15:14:56 -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;
	13 Sep 2012 15:14:56 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 13 Sep 2012 16:14:56 +0100
Message-Id: <505214C6020000780009B224@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 13 Sep 2012 16:15:50 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Jackson" <Ian.Jackson@eu.citrix.com>
References: <504F3E69020000780009A8DB@nat28.tlf.novell.com>
	<20561.62703.748906.832987@mariner.uk.xensource.com>
In-Reply-To: <20561.62703.748906.832987@mariner.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 1/2] x86: construct static parts of 1:1
 mapping at build 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 13.09.12 at 16:59, Ian Jackson <Ian.Jackson@eu.citrix.com> wrote:
> Jan Beulich writes ("[Xen-devel] [PATCH 1/2] x86: construct static parts of 
> 1:1 mapping at build time"):
>> ... rather than at boot time, removing unnecessary redundancy between
>> EFI and legacy boot code.
> 
> Do you think you could get your patchbomb software to link the
> multiple messages in a single patch series via the References
> headers ?
>
> That would make navigating and handling your series much easier for
> me.

I'll see if I can find out (but I'm not using any patchbomb software
at all, and I don't currently see how I could tell my mail client).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 13 15:15:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Sep 2012 15:15: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 1TCB87-0004Pv-Ta; Thu, 13 Sep 2012 15:14: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 1TCB85-0004Po-S1
	for xen-devel@lists.xen.org; Thu, 13 Sep 2012 15:14:57 +0000
Received: from [85.158.143.99:53001] by server-3.bemta-4.messagelabs.com id
	39/0F-08232-178F1505; Thu, 13 Sep 2012 15:14:57 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1347549296!29874922!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQxMjE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16735 invoked from network); 13 Sep 2012 15:14:56 -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;
	13 Sep 2012 15:14:56 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 13 Sep 2012 16:14:56 +0100
Message-Id: <505214C6020000780009B224@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 13 Sep 2012 16:15:50 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Jackson" <Ian.Jackson@eu.citrix.com>
References: <504F3E69020000780009A8DB@nat28.tlf.novell.com>
	<20561.62703.748906.832987@mariner.uk.xensource.com>
In-Reply-To: <20561.62703.748906.832987@mariner.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 1/2] x86: construct static parts of 1:1
 mapping at build 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 13.09.12 at 16:59, Ian Jackson <Ian.Jackson@eu.citrix.com> wrote:
> Jan Beulich writes ("[Xen-devel] [PATCH 1/2] x86: construct static parts of 
> 1:1 mapping at build time"):
>> ... rather than at boot time, removing unnecessary redundancy between
>> EFI and legacy boot code.
> 
> Do you think you could get your patchbomb software to link the
> multiple messages in a single patch series via the References
> headers ?
>
> That would make navigating and handling your series much easier for
> me.

I'll see if I can find out (but I'm not using any patchbomb software
at all, and I don't currently see how I could tell my mail client).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 13 15:17:35 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Sep 2012 15:17: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 1TCBAU-0004Y5-GD; Thu, 13 Sep 2012 15:17:26 +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 1TCBAT-0004Xw-N6
	for xen-devel@lists.xen.org; Thu, 13 Sep 2012 15:17:25 +0000
Received: from [85.158.138.51:30737] by server-4.bemta-3.messagelabs.com id
	F3/D1-24831-409F1505; Thu, 13 Sep 2012 15:17:24 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1347549444!30389981!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-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26990 invoked from network); 13 Sep 2012 15:17:24 -0000
Received: from mail-ey0-f173.google.com (HELO mail-ey0-f173.google.com)
	(209.85.215.173)
	by server-11.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Sep 2012 15:17:24 -0000
Received: by eaac13 with SMTP id c13so1373854eaa.32
	for <xen-devel@lists.xen.org>; Thu, 13 Sep 2012 08:17:24 -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=Z4IAISolxrdnwG0t6e0OjLcJF2lm21Gw9Dmw19KeWpc=;
	b=a/BWloTSLaOgejtJUJz+Kgk3eg3fHqQBW+tyR7Ga9cnK0g1Hqr/E6qvCv0bVwNVNFr
	hqk0wZTR2+Q3NzRrjuwxfgd7HRwCpK8K3+lMROfNiK0xbJTvkylKwB2YKDXlnNACUqsP
	RbiL4VSqzxVM/+spN4XU5mz5+Z8XcjoYpkArt6VrQnN28iT08MDIEIeeK2q2caWK7wwD
	Fgg4blkAW4s9wBIQFWl6PehZUEVqk3ZstrHnFPD2617B3a1be7Ccyor5nfuxLnuvP+NE
	1we+oEK2OVJZxG4d6h8X8+oU9UlqrVpXrpcjghXvpawS6KXr64sQrLWNLl5JdNeIDuit
	6JSQ==
Received: by 10.14.224.73 with SMTP id w49mr3277643eep.37.1347549444034;
	Thu, 13 Sep 2012 08:17:24 -0700 (PDT)
Received: from [192.168.1.69] (host86-184-74-117.range86-184.btcentralplus.com.
	[86.184.74.117])
	by mx.google.com with ESMTPS id u47sm65990039eeo.9.2012.09.13.08.17.19
	(version=SSLv3 cipher=OTHER); Thu, 13 Sep 2012 08:17:22 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Thu, 13 Sep 2012 16:17:18 +0100
From: Keir Fraser <keir.xen@gmail.com>
To: Jan Beulich <JBeulich@suse.com>,
	Tim Deegan <tim@xen.org>
Message-ID: <CC77B78E.3EAFE%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [PATCH] x86/mm: remove the linear mapping of the p2m
	tables
Thread-Index: Ac2RwtzvLWWdQC7UkECfFQwGV7T5uw==
In-Reply-To: <50521304020000780009B208@nat28.tlf.novell.com>
Mime-version: 1.0
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] x86/mm: remove the linear mapping of the
 p2m tables
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 13/09/2012 16:08, "Jan Beulich" <JBeulich@suse.com> wrote:

>>>> On 13.09.12 at 16:58, Keir Fraser <keir.xen@gmail.com> wrote:
>> On 13/09/2012 15:42, "Tim Deegan" <tim@xen.org> wrote:
>> 
>>>> Is that also going to remain true when we won't be able to 1:1-
>>>> map all of the memory anymore once we break the current 5Tb
>>>> barrier? If not, it would probably be worthwhile keeping that
>>>> code.
>>> 
>>> Ah, 5TB is a smaller limit than I thought we had.  Yes, better leave it
>>> alone, so.  Though TBH finding some way to use a bit more virtual
>>> address space for Xen seems like a good idea anyway, since this won't be
>>> the only place we'll want to avoid TLB flushes.
>> 
>> For HVM or PVH guests, where this HAP code would be used, clearly Xen can
>> use all the virtual address space it wants. It will almost certainly make
>> sense for Xen to have a 1:1 physical mapping of all memory when running such
>> a guest, and only do mapcache type tricks when running legacy PV guests.
> 
> Yes, that's the mode I indeed wanted to get to. Just that it's
> not really clear to me (without having started at least the
> work of bumping the boundary) how intrusive those changes
> are going to be.

Well, this is true. But almost regardless of the complexity, this is how
we're going to want to do it, and it does mean we won't need the linear map.
:)

 -- Keir

> Jan
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 13 15:17:35 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Sep 2012 15:17: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 1TCBAU-0004Y5-GD; Thu, 13 Sep 2012 15:17:26 +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 1TCBAT-0004Xw-N6
	for xen-devel@lists.xen.org; Thu, 13 Sep 2012 15:17:25 +0000
Received: from [85.158.138.51:30737] by server-4.bemta-3.messagelabs.com id
	F3/D1-24831-409F1505; Thu, 13 Sep 2012 15:17:24 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1347549444!30389981!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-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26990 invoked from network); 13 Sep 2012 15:17:24 -0000
Received: from mail-ey0-f173.google.com (HELO mail-ey0-f173.google.com)
	(209.85.215.173)
	by server-11.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Sep 2012 15:17:24 -0000
Received: by eaac13 with SMTP id c13so1373854eaa.32
	for <xen-devel@lists.xen.org>; Thu, 13 Sep 2012 08:17:24 -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=Z4IAISolxrdnwG0t6e0OjLcJF2lm21Gw9Dmw19KeWpc=;
	b=a/BWloTSLaOgejtJUJz+Kgk3eg3fHqQBW+tyR7Ga9cnK0g1Hqr/E6qvCv0bVwNVNFr
	hqk0wZTR2+Q3NzRrjuwxfgd7HRwCpK8K3+lMROfNiK0xbJTvkylKwB2YKDXlnNACUqsP
	RbiL4VSqzxVM/+spN4XU5mz5+Z8XcjoYpkArt6VrQnN28iT08MDIEIeeK2q2caWK7wwD
	Fgg4blkAW4s9wBIQFWl6PehZUEVqk3ZstrHnFPD2617B3a1be7Ccyor5nfuxLnuvP+NE
	1we+oEK2OVJZxG4d6h8X8+oU9UlqrVpXrpcjghXvpawS6KXr64sQrLWNLl5JdNeIDuit
	6JSQ==
Received: by 10.14.224.73 with SMTP id w49mr3277643eep.37.1347549444034;
	Thu, 13 Sep 2012 08:17:24 -0700 (PDT)
Received: from [192.168.1.69] (host86-184-74-117.range86-184.btcentralplus.com.
	[86.184.74.117])
	by mx.google.com with ESMTPS id u47sm65990039eeo.9.2012.09.13.08.17.19
	(version=SSLv3 cipher=OTHER); Thu, 13 Sep 2012 08:17:22 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Thu, 13 Sep 2012 16:17:18 +0100
From: Keir Fraser <keir.xen@gmail.com>
To: Jan Beulich <JBeulich@suse.com>,
	Tim Deegan <tim@xen.org>
Message-ID: <CC77B78E.3EAFE%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [PATCH] x86/mm: remove the linear mapping of the p2m
	tables
Thread-Index: Ac2RwtzvLWWdQC7UkECfFQwGV7T5uw==
In-Reply-To: <50521304020000780009B208@nat28.tlf.novell.com>
Mime-version: 1.0
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] x86/mm: remove the linear mapping of the
 p2m tables
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 13/09/2012 16:08, "Jan Beulich" <JBeulich@suse.com> wrote:

>>>> On 13.09.12 at 16:58, Keir Fraser <keir.xen@gmail.com> wrote:
>> On 13/09/2012 15:42, "Tim Deegan" <tim@xen.org> wrote:
>> 
>>>> Is that also going to remain true when we won't be able to 1:1-
>>>> map all of the memory anymore once we break the current 5Tb
>>>> barrier? If not, it would probably be worthwhile keeping that
>>>> code.
>>> 
>>> Ah, 5TB is a smaller limit than I thought we had.  Yes, better leave it
>>> alone, so.  Though TBH finding some way to use a bit more virtual
>>> address space for Xen seems like a good idea anyway, since this won't be
>>> the only place we'll want to avoid TLB flushes.
>> 
>> For HVM or PVH guests, where this HAP code would be used, clearly Xen can
>> use all the virtual address space it wants. It will almost certainly make
>> sense for Xen to have a 1:1 physical mapping of all memory when running such
>> a guest, and only do mapcache type tricks when running legacy PV guests.
> 
> Yes, that's the mode I indeed wanted to get to. Just that it's
> not really clear to me (without having started at least the
> work of bumping the boundary) how intrusive those changes
> are going to be.

Well, this is true. But almost regardless of the complexity, this is how
we're going to want to do it, and it does mean we won't need the linear map.
:)

 -- Keir

> Jan
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 13 15:19:06 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Sep 2012 15:19:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TCBBz-0004em-0a; Thu, 13 Sep 2012 15:18:59 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1TCBBx-0004eY-8O
	for xen-devel@lists.xen.org; Thu, 13 Sep 2012 15:18:57 +0000
Received: from [85.158.143.35:21104] by server-3.bemta-4.messagelabs.com id
	DB/85-08232-069F1505; Thu, 13 Sep 2012 15:18:56 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1347549535!10426681!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-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 326 invoked from network); 13 Sep 2012 15:18:55 -0000
Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com)
	(74.125.83.45)
	by server-10.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Sep 2012 15:18:55 -0000
Received: by eeke53 with SMTP id e53so2111519eek.32
	for <xen-devel@lists.xen.org>; Thu, 13 Sep 2012 08:18:55 -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=aYwhqDvZBFoU2O6jZElSTooUdqt5xr2vlfT+BXsSsoA=;
	b=yCihjRy1jF/+BtZdN+zcXKFm4MXgRGs5nPOqJlL81mr3+/5536BM9vM3D6Tjiakvs3
	4cUJq9jNaPV9F+UiJrYEJZ/oQIjue2z+5vaC9GlCvRWBalooZgKKI6kODpfpe4MK+TTT
	OaO59oArvViDwiQWjjQZ+MYf+8UwSwR3tnSXmTKdOz1ewcU6uDtC9kWHKd7SniwQ52mS
	bJF3sXqBT0erh6GsTc6EisISrhhefovfxfFWpf4bd0X963YvuJ4qC8gae14H4dq9xmK4
	mDwePsPtVL7BLOFl+isyeKHg5QHGBqHNZWtafRXznjC32L4n73/R+S2nWUF99rQ2OMd/
	6iGQ==
Received: by 10.14.218.134 with SMTP id k6mr3343778eep.14.1347549535542;
	Thu, 13 Sep 2012 08:18:55 -0700 (PDT)
Received: from [192.168.1.69] (host86-184-74-117.range86-184.btcentralplus.com.
	[86.184.74.117])
	by mx.google.com with ESMTPS id l42sm66031671eep.1.2012.09.13.08.18.49
	(version=SSLv3 cipher=OTHER); Thu, 13 Sep 2012 08:18:51 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Thu, 13 Sep 2012 16:18:48 +0100
From: Keir Fraser <keir.xen@gmail.com>
To: Tim Deegan <tim@xen.org>
Message-ID: <CC77B7E8.3EB00%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [PATCH] x86/mm: remove the linear mapping of the p2m
	tables
Thread-Index: Ac2RwxKUL0u7sLb2wEW/mo8v7nt0gw==
In-Reply-To: <20120913151114.GE12881@ocelot.phlegethon.org>
Mime-version: 1.0
Cc: Jan Beulich <JBeulich@suse.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] x86/mm: remove the linear mapping of the
 p2m tables
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 13/09/2012 16:11, "Tim Deegan" <tim@xen.org> wrote:

> At 15:58 +0100 on 13 Sep (1347551914), Keir Fraser wrote:
>> On 13/09/2012 15:42, "Tim Deegan" <tim@xen.org> wrote:
>> 
>>>> Is that also going to remain true when we won't be able to 1:1-
>>>> map all of the memory anymore once we break the current 5Tb
>>>> barrier? If not, it would probably be worthwhile keeping that
>>>> code.
>>> 
>>> Ah, 5TB is a smaller limit than I thought we had.  Yes, better leave it
>>> alone, so.  Though TBH finding some way to use a bit more virtual
>>> address space for Xen seems like a good idea anyway, since this won't be
>>> the only place we'll want to avoid TLB flushes.
>> 
>> For HVM or PVH guests, where this HAP code would be used, clearly Xen can
>> use all the virtual address space it wants. It will almost certainly make
>> sense for Xen to have a 1:1 physical mapping of all memory when running such
>> a guest, and only do mapcache type tricks when running legacy PV guests.
> 
> This is also used for shadowed guests, including autotranslated PV
> guests, if anyone cares about them any more.  I got the impression that
> they're superseded by the pvh stuff; is that right?

Auto-translated PV seems to be one of those unsupported things that never
quite dies. With PVH just round the corner, let's definitively call it dead.
:)

> If that's the case, then let's commit to having a bigger 1-1 map on HVM
> guetst when the time comes to extend past 5TB, and remove this linear
> map after all. 

I agree.

 -- Keir

> Tim.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 13 15:19:06 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Sep 2012 15:19:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TCBBz-0004em-0a; Thu, 13 Sep 2012 15:18:59 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1TCBBx-0004eY-8O
	for xen-devel@lists.xen.org; Thu, 13 Sep 2012 15:18:57 +0000
Received: from [85.158.143.35:21104] by server-3.bemta-4.messagelabs.com id
	DB/85-08232-069F1505; Thu, 13 Sep 2012 15:18:56 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1347549535!10426681!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-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 326 invoked from network); 13 Sep 2012 15:18:55 -0000
Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com)
	(74.125.83.45)
	by server-10.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Sep 2012 15:18:55 -0000
Received: by eeke53 with SMTP id e53so2111519eek.32
	for <xen-devel@lists.xen.org>; Thu, 13 Sep 2012 08:18:55 -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=aYwhqDvZBFoU2O6jZElSTooUdqt5xr2vlfT+BXsSsoA=;
	b=yCihjRy1jF/+BtZdN+zcXKFm4MXgRGs5nPOqJlL81mr3+/5536BM9vM3D6Tjiakvs3
	4cUJq9jNaPV9F+UiJrYEJZ/oQIjue2z+5vaC9GlCvRWBalooZgKKI6kODpfpe4MK+TTT
	OaO59oArvViDwiQWjjQZ+MYf+8UwSwR3tnSXmTKdOz1ewcU6uDtC9kWHKd7SniwQ52mS
	bJF3sXqBT0erh6GsTc6EisISrhhefovfxfFWpf4bd0X963YvuJ4qC8gae14H4dq9xmK4
	mDwePsPtVL7BLOFl+isyeKHg5QHGBqHNZWtafRXznjC32L4n73/R+S2nWUF99rQ2OMd/
	6iGQ==
Received: by 10.14.218.134 with SMTP id k6mr3343778eep.14.1347549535542;
	Thu, 13 Sep 2012 08:18:55 -0700 (PDT)
Received: from [192.168.1.69] (host86-184-74-117.range86-184.btcentralplus.com.
	[86.184.74.117])
	by mx.google.com with ESMTPS id l42sm66031671eep.1.2012.09.13.08.18.49
	(version=SSLv3 cipher=OTHER); Thu, 13 Sep 2012 08:18:51 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Thu, 13 Sep 2012 16:18:48 +0100
From: Keir Fraser <keir.xen@gmail.com>
To: Tim Deegan <tim@xen.org>
Message-ID: <CC77B7E8.3EB00%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [PATCH] x86/mm: remove the linear mapping of the p2m
	tables
Thread-Index: Ac2RwxKUL0u7sLb2wEW/mo8v7nt0gw==
In-Reply-To: <20120913151114.GE12881@ocelot.phlegethon.org>
Mime-version: 1.0
Cc: Jan Beulich <JBeulich@suse.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] x86/mm: remove the linear mapping of the
 p2m tables
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 13/09/2012 16:11, "Tim Deegan" <tim@xen.org> wrote:

> At 15:58 +0100 on 13 Sep (1347551914), Keir Fraser wrote:
>> On 13/09/2012 15:42, "Tim Deegan" <tim@xen.org> wrote:
>> 
>>>> Is that also going to remain true when we won't be able to 1:1-
>>>> map all of the memory anymore once we break the current 5Tb
>>>> barrier? If not, it would probably be worthwhile keeping that
>>>> code.
>>> 
>>> Ah, 5TB is a smaller limit than I thought we had.  Yes, better leave it
>>> alone, so.  Though TBH finding some way to use a bit more virtual
>>> address space for Xen seems like a good idea anyway, since this won't be
>>> the only place we'll want to avoid TLB flushes.
>> 
>> For HVM or PVH guests, where this HAP code would be used, clearly Xen can
>> use all the virtual address space it wants. It will almost certainly make
>> sense for Xen to have a 1:1 physical mapping of all memory when running such
>> a guest, and only do mapcache type tricks when running legacy PV guests.
> 
> This is also used for shadowed guests, including autotranslated PV
> guests, if anyone cares about them any more.  I got the impression that
> they're superseded by the pvh stuff; is that right?

Auto-translated PV seems to be one of those unsupported things that never
quite dies. With PVH just round the corner, let's definitively call it dead.
:)

> If that's the case, then let's commit to having a bigger 1-1 map on HVM
> guetst when the time comes to extend past 5TB, and remove this linear
> map after all. 

I agree.

 -- Keir

> Tim.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 13 15:21:27 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Sep 2012 15:21: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 1TCBED-0004oK-IG; Thu, 13 Sep 2012 15:21: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 1TCBEC-0004oA-AH
	for xen-devel@lists.xen.org; Thu, 13 Sep 2012 15:21:16 +0000
Received: from [85.158.138.51:20880] by server-11.bemta-3.messagelabs.com id
	58/E5-30250-BE9F1505; Thu, 13 Sep 2012 15:21:15 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1347549674!30325119!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQxMjE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6710 invoked from network); 13 Sep 2012 15:21:15 -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;
	13 Sep 2012 15:21:15 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 13 Sep 2012 16:21:14 +0100
Message-Id: <5052163F020000780009B241@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 13 Sep 2012 16:22:07 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Keir Fraser" <keir.xen@gmail.com>,"Tim Deegan" <tim@xen.org>
References: <20120913145524.GD12881@ocelot.phlegethon.org>
	<CC77B4DB.3EA68%keir.xen@gmail.com>
In-Reply-To: <CC77B4DB.3EA68%keir.xen@gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Paolo Bonzini <pbonzini@redhat.com>, Jeffrey Karrels <karrelsj@gmail.com>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Clang/LLVM version requirements
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.09.12 at 17:05, Keir Fraser <keir.xen@gmail.com> wrote:
> On 13/09/2012 15:55, "Tim Deegan" <tim@xen.org> wrote:
> 
>> At 15:01 +0100 on 13 Sep (1347548504), Jan Beulich wrote:
>>>>>> On 13.09.12 at 14:21, Tim Deegan <tim@xen.org> wrote:
>>>> Allowing BSS would just need a few extra runes (AFAICS,
>>>> "--set-section-flags .bss=alloc,load,contents") in the objcopy that
>>>> makes reloc.bin.
>>>>  But I'm not sure how to make sure everything is
>>>> rip-relative, do if that's the real concern I'm inclined to go with
>>>> this compile-time check and exclude .[ro]data[.*] as well.
>>>> We can always fix it up to allow bss and data sections if we ever
>>>> actually need them.
>>> 
>>> As said, I'm fine with any approach as long as it works with all
>>> supported tool chains. So feel free to go the route you're
>>> proposing.
>> 
>> OK.  The patch below works for me on gccs 4.1 to 4.7 and clang 3.0.
>> I tries gcc 3.4 but the build already fails in a few other places.
>> Do we really still support gcc 3.4 like the README says?
> 
> It's been a long while since we updated our compiler support. In general
> I've been happy to say we support each gcc release only for 2-3 years. In
> this case that would mean we could *even* update our support to be only gcc
> 4.2 and later.

For the purpose of being able to build on SLE10 without overrides,
I'd like to ask to consider keeping this at 4.1.x for the next while.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 13 15:21:27 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Sep 2012 15:21: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 1TCBED-0004oK-IG; Thu, 13 Sep 2012 15:21: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 1TCBEC-0004oA-AH
	for xen-devel@lists.xen.org; Thu, 13 Sep 2012 15:21:16 +0000
Received: from [85.158.138.51:20880] by server-11.bemta-3.messagelabs.com id
	58/E5-30250-BE9F1505; Thu, 13 Sep 2012 15:21:15 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1347549674!30325119!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQxMjE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6710 invoked from network); 13 Sep 2012 15:21:15 -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;
	13 Sep 2012 15:21:15 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 13 Sep 2012 16:21:14 +0100
Message-Id: <5052163F020000780009B241@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 13 Sep 2012 16:22:07 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Keir Fraser" <keir.xen@gmail.com>,"Tim Deegan" <tim@xen.org>
References: <20120913145524.GD12881@ocelot.phlegethon.org>
	<CC77B4DB.3EA68%keir.xen@gmail.com>
In-Reply-To: <CC77B4DB.3EA68%keir.xen@gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Paolo Bonzini <pbonzini@redhat.com>, Jeffrey Karrels <karrelsj@gmail.com>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Clang/LLVM version requirements
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.09.12 at 17:05, Keir Fraser <keir.xen@gmail.com> wrote:
> On 13/09/2012 15:55, "Tim Deegan" <tim@xen.org> wrote:
> 
>> At 15:01 +0100 on 13 Sep (1347548504), Jan Beulich wrote:
>>>>>> On 13.09.12 at 14:21, Tim Deegan <tim@xen.org> wrote:
>>>> Allowing BSS would just need a few extra runes (AFAICS,
>>>> "--set-section-flags .bss=alloc,load,contents") in the objcopy that
>>>> makes reloc.bin.
>>>>  But I'm not sure how to make sure everything is
>>>> rip-relative, do if that's the real concern I'm inclined to go with
>>>> this compile-time check and exclude .[ro]data[.*] as well.
>>>> We can always fix it up to allow bss and data sections if we ever
>>>> actually need them.
>>> 
>>> As said, I'm fine with any approach as long as it works with all
>>> supported tool chains. So feel free to go the route you're
>>> proposing.
>> 
>> OK.  The patch below works for me on gccs 4.1 to 4.7 and clang 3.0.
>> I tries gcc 3.4 but the build already fails in a few other places.
>> Do we really still support gcc 3.4 like the README says?
> 
> It's been a long while since we updated our compiler support. In general
> I've been happy to say we support each gcc release only for 2-3 years. In
> this case that would mean we could *even* update our support to be only gcc
> 4.2 and later.

For the purpose of being able to build on SLE10 without overrides,
I'd like to ask to consider keeping this at 4.1.x for the next while.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 13 15:21:50 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Sep 2012 15: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 1TCBEa-0004r5-0F; Thu, 13 Sep 2012 15:21:40 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1TCBEY-0004qs-SU
	for xen-devel@lists.xen.org; Thu, 13 Sep 2012 15:21:39 +0000
Received: from [85.158.143.99:34620] by server-2.bemta-4.messagelabs.com id
	31/49-21239-20AF1505; Thu, 13 Sep 2012 15:21:38 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-3.tower-216.messagelabs.com!1347549697!29622185!1
X-Originating-IP: [208.97.132.5]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi41ID0+IDMwNTA1\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20630 invoked from network); 13 Sep 2012 15:21:37 -0000
Received: from mailbigip.dreamhost.com (HELO homiemail-a21.g.dreamhost.com)
	(208.97.132.5) by server-3.tower-216.messagelabs.com with SMTP;
	13 Sep 2012 15:21:37 -0000
Received: from homiemail-a21.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a21.g.dreamhost.com (Postfix) with ESMTP id C22B0300072;
	Thu, 13 Sep 2012 08:21:36 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id:date
	:from:to:cc; q=dns; s=lagarcavilla.org; b=f2Rkpdut0/vKuu1png+i53
	Ji6lk+6y4C9ZPVodzN1NLrmWIE1bY/jfsArtD1mPKJiUQ7ZTsxe4+BUeiq6JT3MV
	ADXsLM3NY6OBjjFF4QWTSGOvwtVAF6e3dUugnErdX/4npLXuyJdhC/jUUnbwA4gi
	VUjdINIuSFyWNM3YytuaU=
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=lfDumy5+kniE
	96JioieuNA6hePw=; b=Jq1X+kwQMxiFos1gpa0uWYtQT2bW6BnIgO1tFASUXJfU
	YG8dtahOkBQQvBCXOLMkMzGLCAstZeXtKxOwdoYi3KwG2tcFg3uCzTi+nT2AwbLx
	3GADZvpxFLrr5HeZkSDGuA3kfLl3gV4ibd31H4z8S9ZqujqS5F+NfJqZw0oqGPk=
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 2C2AB300061; 
	Thu, 13 Sep 2012 08:21:36 -0700 (PDT)
MIME-Version: 1.0
X-Mercurial-Node: 40b91bed1275b13e191fa01233ffbcbaacfc70e5
Message-Id: <40b91bed1275b13e191f.1347550068@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Thu, 13 Sep 2012 11:27:48 -0400
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xen.org
Cc: keir@xen.org, andres@gridcentric.ca, tim@xen.org, JBeulich@suse.com
Subject: [Xen-devel] [PATCH] Extra check in grant table code for mapping of
	shared frame
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

 xen/common/grant_table.c |  9 ++++++---
 1 files changed, 6 insertions(+), 3 deletions(-)


Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r 5ce5b53ea68f -r 40b91bed1275 xen/common/grant_table.c
--- a/xen/common/grant_table.c
+++ b/xen/common/grant_table.c
@@ -649,9 +649,12 @@ __gnttab_map_grant_ref(
     }
     else if ( owner == rd || owner == dom_cow )
     {
-        if ( gnttab_host_mapping_get_page_type(op, ld, rd) &&
-             !get_page_type(pg, PGT_writable_page) )
-            goto could_not_pin;
+        if ( gnttab_host_mapping_get_page_type(op, ld, rd) )
+        {
+            if ( (owner == dom_cow) ||
+                 !get_page_type(pg, PGT_writable_page) )
+                goto could_not_pin;
+        }
 
         nr_gets++;
         if ( op->flags & GNTMAP_host_map )

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 13 15:21:50 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Sep 2012 15: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 1TCBEa-0004r5-0F; Thu, 13 Sep 2012 15:21:40 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1TCBEY-0004qs-SU
	for xen-devel@lists.xen.org; Thu, 13 Sep 2012 15:21:39 +0000
Received: from [85.158.143.99:34620] by server-2.bemta-4.messagelabs.com id
	31/49-21239-20AF1505; Thu, 13 Sep 2012 15:21:38 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-3.tower-216.messagelabs.com!1347549697!29622185!1
X-Originating-IP: [208.97.132.5]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi41ID0+IDMwNTA1\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20630 invoked from network); 13 Sep 2012 15:21:37 -0000
Received: from mailbigip.dreamhost.com (HELO homiemail-a21.g.dreamhost.com)
	(208.97.132.5) by server-3.tower-216.messagelabs.com with SMTP;
	13 Sep 2012 15:21:37 -0000
Received: from homiemail-a21.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a21.g.dreamhost.com (Postfix) with ESMTP id C22B0300072;
	Thu, 13 Sep 2012 08:21:36 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id:date
	:from:to:cc; q=dns; s=lagarcavilla.org; b=f2Rkpdut0/vKuu1png+i53
	Ji6lk+6y4C9ZPVodzN1NLrmWIE1bY/jfsArtD1mPKJiUQ7ZTsxe4+BUeiq6JT3MV
	ADXsLM3NY6OBjjFF4QWTSGOvwtVAF6e3dUugnErdX/4npLXuyJdhC/jUUnbwA4gi
	VUjdINIuSFyWNM3YytuaU=
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=lfDumy5+kniE
	96JioieuNA6hePw=; b=Jq1X+kwQMxiFos1gpa0uWYtQT2bW6BnIgO1tFASUXJfU
	YG8dtahOkBQQvBCXOLMkMzGLCAstZeXtKxOwdoYi3KwG2tcFg3uCzTi+nT2AwbLx
	3GADZvpxFLrr5HeZkSDGuA3kfLl3gV4ibd31H4z8S9ZqujqS5F+NfJqZw0oqGPk=
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 2C2AB300061; 
	Thu, 13 Sep 2012 08:21:36 -0700 (PDT)
MIME-Version: 1.0
X-Mercurial-Node: 40b91bed1275b13e191fa01233ffbcbaacfc70e5
Message-Id: <40b91bed1275b13e191f.1347550068@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Thu, 13 Sep 2012 11:27:48 -0400
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xen.org
Cc: keir@xen.org, andres@gridcentric.ca, tim@xen.org, JBeulich@suse.com
Subject: [Xen-devel] [PATCH] Extra check in grant table code for mapping of
	shared frame
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

 xen/common/grant_table.c |  9 ++++++---
 1 files changed, 6 insertions(+), 3 deletions(-)


Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r 5ce5b53ea68f -r 40b91bed1275 xen/common/grant_table.c
--- a/xen/common/grant_table.c
+++ b/xen/common/grant_table.c
@@ -649,9 +649,12 @@ __gnttab_map_grant_ref(
     }
     else if ( owner == rd || owner == dom_cow )
     {
-        if ( gnttab_host_mapping_get_page_type(op, ld, rd) &&
-             !get_page_type(pg, PGT_writable_page) )
-            goto could_not_pin;
+        if ( gnttab_host_mapping_get_page_type(op, ld, rd) )
+        {
+            if ( (owner == dom_cow) ||
+                 !get_page_type(pg, PGT_writable_page) )
+                goto could_not_pin;
+        }
 
         nr_gets++;
         if ( op->flags & GNTMAP_host_map )

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 13 15:28:11 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Sep 2012 15:28: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 1TCBKj-0005TE-6M; Thu, 13 Sep 2012 15:28:01 +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 1TCBKi-0005Sr-BP
	for xen-devel@lists.xen.org; Thu, 13 Sep 2012 15:28:00 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1347550074!7504869!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDkwMjg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23957 invoked from network); 13 Sep 2012 15:27: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;
	13 Sep 2012 15:27:54 -0000
X-IronPort-AV: E=Sophos;i="4.80,417,1344211200"; d="scan'208";a="14525517"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Sep 2012 15:27: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.279.1;
	Thu, 13 Sep 2012 16:27:53 +0100
Message-ID: <1347550071.24226.128.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Keir Fraser <keir.xen@gmail.com>
Date: Thu, 13 Sep 2012 16:27:51 +0100
In-Reply-To: <CC77B5A3.3EA85%keir.xen@gmail.com>
References: <CC77B5A3.3EA85%keir.xen@gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Paolo Bonzini <pbonzini@redhat.com>, "Tim \(Xen.org\)" <tim@xen.org>,
	Jeffrey Karrels <karrelsj@gmail.com>, Jan Beulich <JBeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Clang/LLVM version requirements
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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-09-13 at 16:09 +0100, Keir Fraser wrote:
> On 13/09/2012 16:05, "Keir Fraser" <keir.xen@gmail.com> wrote:
> 
> > On 13/09/2012 15:55, "Tim Deegan" <tim@xen.org> wrote:
> > 
> >> At 15:01 +0100 on 13 Sep (1347548504), Jan Beulich wrote:
> >>>>>> On 13.09.12 at 14:21, Tim Deegan <tim@xen.org> wrote:
> >>>> Allowing BSS would just need a few extra runes (AFAICS,
> >>>> "--set-section-flags .bss=alloc,load,contents") in the objcopy that
> >>>> makes reloc.bin.
> >>>>  But I'm not sure how to make sure everything is
> >>>> rip-relative, do if that's the real concern I'm inclined to go with
> >>>> this compile-time check and exclude .[ro]data[.*] as well.
> >>>> We can always fix it up to allow bss and data sections if we ever
> >>>> actually need them.
> >>> 
> >>> As said, I'm fine with any approach as long as it works with all
> >>> supported tool chains. So feel free to go the route you're
> >>> proposing.
> >> 
> >> OK.  The patch below works for me on gccs 4.1 to 4.7 and clang 3.0.
> >> I tries gcc 3.4 but the build already fails in a few other places.
> >> Do we really still support gcc 3.4 like the README says?
> > 
> > It's been a long while since we updated our compiler support. In general
> > I've been happy to say we support each gcc release only for 2-3 years. In
> > this case that would mean we could *even* update our support to be only gcc
> > 4.2 and later.
> > 
> > What do people think about us forcing this? It might even let us get rid of
> > GCC_HAS_VISIBILITY_ATTRIBUTE?
> 
> I should add, this is mainly a question of how aggressive we should be. I'm
> quite happy to retire gcc-3.4 support if it happens it is now broken. In
> that case, x86/Rules.mk should have its gcc version check updated. And
> perhaps arch/arm may as well do the same? I would be happy to Ack a patch to
> that effect.

Some data points: Debian Squeeze (current stable) has gcc 4.4 as the
default (but ships a bunch of others) and Lenny (previous stable) had
4.3. AFAICT RHEL5 and SLES10 both shipped 4.1, SLES11 shipped 4.3 and
RHEL 6 4.4.

Do we really want/need to support host OSes older than RHEL5/SLES10? We
are talking 2006/7 vintage there.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 13 15:28:11 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Sep 2012 15:28: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 1TCBKj-0005TE-6M; Thu, 13 Sep 2012 15:28:01 +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 1TCBKi-0005Sr-BP
	for xen-devel@lists.xen.org; Thu, 13 Sep 2012 15:28:00 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1347550074!7504869!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDkwMjg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23957 invoked from network); 13 Sep 2012 15:27: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;
	13 Sep 2012 15:27:54 -0000
X-IronPort-AV: E=Sophos;i="4.80,417,1344211200"; d="scan'208";a="14525517"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Sep 2012 15:27: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.279.1;
	Thu, 13 Sep 2012 16:27:53 +0100
Message-ID: <1347550071.24226.128.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Keir Fraser <keir.xen@gmail.com>
Date: Thu, 13 Sep 2012 16:27:51 +0100
In-Reply-To: <CC77B5A3.3EA85%keir.xen@gmail.com>
References: <CC77B5A3.3EA85%keir.xen@gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Paolo Bonzini <pbonzini@redhat.com>, "Tim \(Xen.org\)" <tim@xen.org>,
	Jeffrey Karrels <karrelsj@gmail.com>, Jan Beulich <JBeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Clang/LLVM version requirements
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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-09-13 at 16:09 +0100, Keir Fraser wrote:
> On 13/09/2012 16:05, "Keir Fraser" <keir.xen@gmail.com> wrote:
> 
> > On 13/09/2012 15:55, "Tim Deegan" <tim@xen.org> wrote:
> > 
> >> At 15:01 +0100 on 13 Sep (1347548504), Jan Beulich wrote:
> >>>>>> On 13.09.12 at 14:21, Tim Deegan <tim@xen.org> wrote:
> >>>> Allowing BSS would just need a few extra runes (AFAICS,
> >>>> "--set-section-flags .bss=alloc,load,contents") in the objcopy that
> >>>> makes reloc.bin.
> >>>>  But I'm not sure how to make sure everything is
> >>>> rip-relative, do if that's the real concern I'm inclined to go with
> >>>> this compile-time check and exclude .[ro]data[.*] as well.
> >>>> We can always fix it up to allow bss and data sections if we ever
> >>>> actually need them.
> >>> 
> >>> As said, I'm fine with any approach as long as it works with all
> >>> supported tool chains. So feel free to go the route you're
> >>> proposing.
> >> 
> >> OK.  The patch below works for me on gccs 4.1 to 4.7 and clang 3.0.
> >> I tries gcc 3.4 but the build already fails in a few other places.
> >> Do we really still support gcc 3.4 like the README says?
> > 
> > It's been a long while since we updated our compiler support. In general
> > I've been happy to say we support each gcc release only for 2-3 years. In
> > this case that would mean we could *even* update our support to be only gcc
> > 4.2 and later.
> > 
> > What do people think about us forcing this? It might even let us get rid of
> > GCC_HAS_VISIBILITY_ATTRIBUTE?
> 
> I should add, this is mainly a question of how aggressive we should be. I'm
> quite happy to retire gcc-3.4 support if it happens it is now broken. In
> that case, x86/Rules.mk should have its gcc version check updated. And
> perhaps arch/arm may as well do the same? I would be happy to Ack a patch to
> that effect.

Some data points: Debian Squeeze (current stable) has gcc 4.4 as the
default (but ships a bunch of others) and Lenny (previous stable) had
4.3. AFAICT RHEL5 and SLES10 both shipped 4.1, SLES11 shipped 4.3 and
RHEL 6 4.4.

Do we really want/need to support host OSes older than RHEL5/SLES10? We
are talking 2006/7 vintage there.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 13 15:29:58 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Sep 2012 15:29:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TCBMS-0005gR-RR; Thu, 13 Sep 2012 15:29: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 1TCBMR-0005gK-EX
	for xen-devel@lists.xen.org; Thu, 13 Sep 2012 15:29:47 +0000
Received: from [85.158.143.99:50859] by server-2.bemta-4.messagelabs.com id
	4C/A5-21239-AEBF1505; Thu, 13 Sep 2012 15:29:46 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1347550186!20597488!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDkwMjg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29873 invoked from network); 13 Sep 2012 15:29:46 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Sep 2012 15:29:46 -0000
X-IronPort-AV: E=Sophos;i="4.80,417,1344211200"; d="scan'208";a="14525559"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Sep 2012 15:29:46 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Thu, 13 Sep 2012 16:29: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
	1TCBMP-00071O-NG; Thu, 13 Sep 2012 15:29:45 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1TCBMP-0005sU-JO;
	Thu, 13 Sep 2012 16:29:45 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20561.64489.500854.398884@mariner.uk.xensource.com>
Date: Thu, 13 Sep 2012 16:29:45 +0100
To: Daniel De Graaf <dgdegra@tycho.nsa.gov>
In-Reply-To: <5051F700.9060900@tycho.nsa.gov>
References: <1347465586-20009-1-git-send-email-dgdegra@tycho.nsa.gov>
	<20561.61335.548996.644196@mariner.uk.xensource.com>
	<5051F700.9060900@tycho.nsa.gov>
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] Merge IS_PRIV checks into XSM hooks
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Daniel De Graaf writes ("Re: [Xen-devel] [PATCH v3] Merge IS_PRIV checks into XSM hooks"):
> On 09/13/2012 10:37 AM, Ian Jackson wrote:
> The ARM support in xen-unstable.h doesn't currently have any domctls or
> sysctls defined; when it does, they will need to be added to the list of
> hooks in flask_domctl/flask_sysctl with either an access check or a
> pass-through due to the use of another hook. If not, they will trigger a
> printk and be denied, so it's fairly easy to catch this.

That last sentence is very reassuring to me.  I was just wanting to
check that users weren't liable to try to use xsm and not notice that
it wasn't complete - and that when we did try to complete xsm on arm
we would avoid accidentally missing anything.

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 Sep 13 15:29:58 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Sep 2012 15:29:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TCBMS-0005gR-RR; Thu, 13 Sep 2012 15:29: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 1TCBMR-0005gK-EX
	for xen-devel@lists.xen.org; Thu, 13 Sep 2012 15:29:47 +0000
Received: from [85.158.143.99:50859] by server-2.bemta-4.messagelabs.com id
	4C/A5-21239-AEBF1505; Thu, 13 Sep 2012 15:29:46 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1347550186!20597488!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDkwMjg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29873 invoked from network); 13 Sep 2012 15:29:46 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Sep 2012 15:29:46 -0000
X-IronPort-AV: E=Sophos;i="4.80,417,1344211200"; d="scan'208";a="14525559"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Sep 2012 15:29:46 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Thu, 13 Sep 2012 16:29: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
	1TCBMP-00071O-NG; Thu, 13 Sep 2012 15:29:45 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1TCBMP-0005sU-JO;
	Thu, 13 Sep 2012 16:29:45 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20561.64489.500854.398884@mariner.uk.xensource.com>
Date: Thu, 13 Sep 2012 16:29:45 +0100
To: Daniel De Graaf <dgdegra@tycho.nsa.gov>
In-Reply-To: <5051F700.9060900@tycho.nsa.gov>
References: <1347465586-20009-1-git-send-email-dgdegra@tycho.nsa.gov>
	<20561.61335.548996.644196@mariner.uk.xensource.com>
	<5051F700.9060900@tycho.nsa.gov>
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] Merge IS_PRIV checks into XSM hooks
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Daniel De Graaf writes ("Re: [Xen-devel] [PATCH v3] Merge IS_PRIV checks into XSM hooks"):
> On 09/13/2012 10:37 AM, Ian Jackson wrote:
> The ARM support in xen-unstable.h doesn't currently have any domctls or
> sysctls defined; when it does, they will need to be added to the list of
> hooks in flask_domctl/flask_sysctl with either an access check or a
> pass-through due to the use of another hook. If not, they will trigger a
> printk and be denied, so it's fairly easy to catch this.

That last sentence is very reassuring to me.  I was just wanting to
check that users weren't liable to try to use xsm and not notice that
it wasn't complete - and that when we did try to complete xsm on arm
we would avoid accidentally missing anything.

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 Sep 13 15:32:21 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Sep 2012 15:32:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TCBOn-0005sX-DU; Thu, 13 Sep 2012 15:32: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 1TCBOl-0005sK-Vz
	for xen-devel@lists.xen.org; Thu, 13 Sep 2012 15:32:12 +0000
Received: from [85.158.143.99:37660] by server-3.bemta-4.messagelabs.com id
	35/29-08232-B7CF1505; Thu, 13 Sep 2012 15:32:11 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1347550330!22087912!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDkwMjg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6290 invoked from network); 13 Sep 2012 15:32:10 -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 Sep 2012 15:32:10 -0000
X-IronPort-AV: E=Sophos;i="4.80,417,1344211200"; d="scan'208";a="14525643"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Sep 2012 15:32: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.279.1; Thu, 13 Sep 2012 16:32: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
	1TCBOj-000725-TX; Thu, 13 Sep 2012 15:32:09 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1TCBOj-0005sj-Pw;
	Thu, 13 Sep 2012 16:32:09 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20561.64633.704870.629500@mariner.uk.xensource.com>
Date: Thu, 13 Sep 2012 16:32:09 +0100
To: Jan Beulich <JBeulich@suse.com>
In-Reply-To: <505214C6020000780009B224@nat28.tlf.novell.com>
References: <504F3E69020000780009A8DB@nat28.tlf.novell.com>
	<20561.62703.748906.832987@mariner.uk.xensource.com>
	<505214C6020000780009B224@nat28.tlf.novell.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 1/2] x86: construct static parts of 1:1
 mapping at build 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

Jan Beulich writes ("Re: [Xen-devel] [PATCH 1/2] x86: construct static parts of 1:1 mapping at build time"):
> > That would make navigating and handling your series much easier for
> > me.
> 
> I'll see if I can find out (but I'm not using any patchbomb software
> at all, and I don't currently see how I could tell my mail client).

Uh, you manually write the Subject lines and so on ?  Surely you're
using some kind of script.

If you can't do anything else, and are using a conventional mail
client rather than some kind of scripted email sending, you can make
all your messages turn up in the same thread by writing each message
apart from 0/n as a reply to your copy of the 0/n.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 13 15:32:21 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Sep 2012 15:32:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TCBOn-0005sX-DU; Thu, 13 Sep 2012 15:32: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 1TCBOl-0005sK-Vz
	for xen-devel@lists.xen.org; Thu, 13 Sep 2012 15:32:12 +0000
Received: from [85.158.143.99:37660] by server-3.bemta-4.messagelabs.com id
	35/29-08232-B7CF1505; Thu, 13 Sep 2012 15:32:11 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1347550330!22087912!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDkwMjg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6290 invoked from network); 13 Sep 2012 15:32:10 -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 Sep 2012 15:32:10 -0000
X-IronPort-AV: E=Sophos;i="4.80,417,1344211200"; d="scan'208";a="14525643"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Sep 2012 15:32: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.279.1; Thu, 13 Sep 2012 16:32: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
	1TCBOj-000725-TX; Thu, 13 Sep 2012 15:32:09 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1TCBOj-0005sj-Pw;
	Thu, 13 Sep 2012 16:32:09 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20561.64633.704870.629500@mariner.uk.xensource.com>
Date: Thu, 13 Sep 2012 16:32:09 +0100
To: Jan Beulich <JBeulich@suse.com>
In-Reply-To: <505214C6020000780009B224@nat28.tlf.novell.com>
References: <504F3E69020000780009A8DB@nat28.tlf.novell.com>
	<20561.62703.748906.832987@mariner.uk.xensource.com>
	<505214C6020000780009B224@nat28.tlf.novell.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 1/2] x86: construct static parts of 1:1
 mapping at build 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

Jan Beulich writes ("Re: [Xen-devel] [PATCH 1/2] x86: construct static parts of 1:1 mapping at build time"):
> > That would make navigating and handling your series much easier for
> > me.
> 
> I'll see if I can find out (but I'm not using any patchbomb software
> at all, and I don't currently see how I could tell my mail client).

Uh, you manually write the Subject lines and so on ?  Surely you're
using some kind of script.

If you can't do anything else, and are using a conventional mail
client rather than some kind of scripted email sending, you can make
all your messages turn up in the same thread by writing each message
apart from 0/n as a reply to your copy of the 0/n.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 13 15:34:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Sep 2012 15:34:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TCBQn-00067x-VE; Thu, 13 Sep 2012 15:34:17 +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 1TCBQm-00067f-Az
	for xen-devel@lists.xen.org; Thu, 13 Sep 2012 15:34:16 +0000
Received: from [85.158.139.83:53742] by server-10.bemta-5.messagelabs.com id
	7F/17-10969-5FCF1505; Thu, 13 Sep 2012 15:34:13 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1347550452!28166841!1
X-Originating-IP: [74.125.83.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32588 invoked from network); 13 Sep 2012 15:34:12 -0000
Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com)
	(74.125.83.45)
	by server-15.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Sep 2012 15:34:12 -0000
Received: by eeke53 with SMTP id e53so2121144eek.32
	for <xen-devel@lists.xen.org>; Thu, 13 Sep 2012 08:34:11 -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=9bfdoD8/lZQNSqmcqcv+NXuLotke8I8Qb4l7zPhldF4=;
	b=L2NfXmueJ6iYk01fRMVUXkcB4TbUFulCQOPrGitE8gVZ1ANBtZdaoxLS+0zTfH21oN
	zzJ/JgXkIYiNRMIryaYsrD2RN/hCG71ZDOQCT6TMh2cgGdTKnAOKzdto/GkUL5t0MDBl
	naAKFidKLGxnkuw7f7LRYdnmNunoEMqwDpzlnTy1mDITVLG12oIip9JX2wHJiJuKStxJ
	/rLP79XrZC4XpOEI2ozmQ57u1wTvhvxmZVO8NaMBv9GXSeLCE2/IVsumqJ4aobgoWfv7
	tBdojQN4Wcdw8zZjwVKdxYF1SUPLWyuY3cgxz5ZQo4sJ1aSDN8KoX4zsxtn1NtWiGqJ+
	oPaw==
Received: by 10.14.219.198 with SMTP id m46mr3394053eep.18.1347550451859;
	Thu, 13 Sep 2012 08:34:11 -0700 (PDT)
Received: from [192.168.1.3] (host86-184-74-117.range86-184.btcentralplus.com.
	[86.184.74.117])
	by mx.google.com with ESMTPS id z3sm66102775eel.15.2012.09.13.08.34.09
	(version=SSLv3 cipher=OTHER); Thu, 13 Sep 2012 08:34:11 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.33.0.120411
Date: Thu, 13 Sep 2012 16:34:06 +0100
From: Keir Fraser <keir@xen.org>
To: Jan Beulich <JBeulich@suse.com>,
	Tim Deegan <tim@xen.org>
Message-ID: <CC77BB7E.4BA78%keir@xen.org>
Thread-Topic: [Xen-devel] Clang/LLVM version requirements
Thread-Index: Ac2RxTXAn3DyXhVQm0mNu2ZQitvXZQ==
In-Reply-To: <5052163F020000780009B241@nat28.tlf.novell.com>
Mime-version: 1.0
Cc: Paolo Bonzini <pbonzini@redhat.com>, Jeffrey Karrels <karrelsj@gmail.com>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Clang/LLVM version requirements
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/09/2012 16:22, "Jan Beulich" <JBeulich@suse.com> wrote:

>>> OK.  The patch below works for me on gccs 4.1 to 4.7 and clang 3.0.
>>> I tries gcc 3.4 but the build already fails in a few other places.
>>> Do we really still support gcc 3.4 like the README says?
>> 
>> It's been a long while since we updated our compiler support. In general
>> I've been happy to say we support each gcc release only for 2-3 years. In
>> this case that would mean we could *even* update our support to be only gcc
>> 4.2 and later.
> 
> For the purpose of being able to build on SLE10 without overrides,
> I'd like to ask to consider keeping this at 4.1.x for the next while.

Fine. Unless I hear otherwise I will update the check to gcc-4.1 and later,
tomorrow.

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 13 15:34:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Sep 2012 15:34:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TCBQn-00067x-VE; Thu, 13 Sep 2012 15:34:17 +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 1TCBQm-00067f-Az
	for xen-devel@lists.xen.org; Thu, 13 Sep 2012 15:34:16 +0000
Received: from [85.158.139.83:53742] by server-10.bemta-5.messagelabs.com id
	7F/17-10969-5FCF1505; Thu, 13 Sep 2012 15:34:13 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1347550452!28166841!1
X-Originating-IP: [74.125.83.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32588 invoked from network); 13 Sep 2012 15:34:12 -0000
Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com)
	(74.125.83.45)
	by server-15.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Sep 2012 15:34:12 -0000
Received: by eeke53 with SMTP id e53so2121144eek.32
	for <xen-devel@lists.xen.org>; Thu, 13 Sep 2012 08:34:11 -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=9bfdoD8/lZQNSqmcqcv+NXuLotke8I8Qb4l7zPhldF4=;
	b=L2NfXmueJ6iYk01fRMVUXkcB4TbUFulCQOPrGitE8gVZ1ANBtZdaoxLS+0zTfH21oN
	zzJ/JgXkIYiNRMIryaYsrD2RN/hCG71ZDOQCT6TMh2cgGdTKnAOKzdto/GkUL5t0MDBl
	naAKFidKLGxnkuw7f7LRYdnmNunoEMqwDpzlnTy1mDITVLG12oIip9JX2wHJiJuKStxJ
	/rLP79XrZC4XpOEI2ozmQ57u1wTvhvxmZVO8NaMBv9GXSeLCE2/IVsumqJ4aobgoWfv7
	tBdojQN4Wcdw8zZjwVKdxYF1SUPLWyuY3cgxz5ZQo4sJ1aSDN8KoX4zsxtn1NtWiGqJ+
	oPaw==
Received: by 10.14.219.198 with SMTP id m46mr3394053eep.18.1347550451859;
	Thu, 13 Sep 2012 08:34:11 -0700 (PDT)
Received: from [192.168.1.3] (host86-184-74-117.range86-184.btcentralplus.com.
	[86.184.74.117])
	by mx.google.com with ESMTPS id z3sm66102775eel.15.2012.09.13.08.34.09
	(version=SSLv3 cipher=OTHER); Thu, 13 Sep 2012 08:34:11 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.33.0.120411
Date: Thu, 13 Sep 2012 16:34:06 +0100
From: Keir Fraser <keir@xen.org>
To: Jan Beulich <JBeulich@suse.com>,
	Tim Deegan <tim@xen.org>
Message-ID: <CC77BB7E.4BA78%keir@xen.org>
Thread-Topic: [Xen-devel] Clang/LLVM version requirements
Thread-Index: Ac2RxTXAn3DyXhVQm0mNu2ZQitvXZQ==
In-Reply-To: <5052163F020000780009B241@nat28.tlf.novell.com>
Mime-version: 1.0
Cc: Paolo Bonzini <pbonzini@redhat.com>, Jeffrey Karrels <karrelsj@gmail.com>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Clang/LLVM version requirements
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/09/2012 16:22, "Jan Beulich" <JBeulich@suse.com> wrote:

>>> OK.  The patch below works for me on gccs 4.1 to 4.7 and clang 3.0.
>>> I tries gcc 3.4 but the build already fails in a few other places.
>>> Do we really still support gcc 3.4 like the README says?
>> 
>> It's been a long while since we updated our compiler support. In general
>> I've been happy to say we support each gcc release only for 2-3 years. In
>> this case that would mean we could *even* update our support to be only gcc
>> 4.2 and later.
> 
> For the purpose of being able to build on SLE10 without overrides,
> I'd like to ask to consider keeping this at 4.1.x for the next while.

Fine. Unless I hear otherwise I will update the check to gcc-4.1 and later,
tomorrow.

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 13 15:36:06 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Sep 2012 15:36:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TCBSR-0006HR-Ef; Thu, 13 Sep 2012 15:35:59 +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 1TCBSP-0006Gl-H6
	for xen-devel@lists.xen.org; Thu, 13 Sep 2012 15:35:57 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1347550551!9635885!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQxMjE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16367 invoked from network); 13 Sep 2012 15:35:51 -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;
	13 Sep 2012 15:35:51 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 13 Sep 2012 16:35:51 +0100
Message-Id: <505219AE020000780009B262@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 13 Sep 2012 16:36:46 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Keir Fraser" <keir.xen@gmail.com>,"Tim Deegan" <tim@xen.org>
References: <50521304020000780009B208@nat28.tlf.novell.com>
	<CC77B78E.3EAFE%keir.xen@gmail.com>
In-Reply-To: <CC77B78E.3EAFE%keir.xen@gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] x86/mm: remove the linear mapping of the
 p2m tables
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 13.09.12 at 17:17, Keir Fraser <keir.xen@gmail.com> wrote:
> On 13/09/2012 16:08, "Jan Beulich" <JBeulich@suse.com> wrote:
> 
>>>>> On 13.09.12 at 16:58, Keir Fraser <keir.xen@gmail.com> wrote:
>>> On 13/09/2012 15:42, "Tim Deegan" <tim@xen.org> wrote:
>>> 
>>>>> Is that also going to remain true when we won't be able to 1:1-
>>>>> map all of the memory anymore once we break the current 5Tb
>>>>> barrier? If not, it would probably be worthwhile keeping that
>>>>> code.
>>>> 
>>>> Ah, 5TB is a smaller limit than I thought we had.  Yes, better leave it
>>>> alone, so.  Though TBH finding some way to use a bit more virtual
>>>> address space for Xen seems like a good idea anyway, since this won't be
>>>> the only place we'll want to avoid TLB flushes.
>>> 
>>> For HVM or PVH guests, where this HAP code would be used, clearly Xen can
>>> use all the virtual address space it wants. It will almost certainly make
>>> sense for Xen to have a 1:1 physical mapping of all memory when running such
>>> a guest, and only do mapcache type tricks when running legacy PV guests.
>> 
>> Yes, that's the mode I indeed wanted to get to. Just that it's
>> not really clear to me (without having started at least the
>> work of bumping the boundary) how intrusive those changes
>> are going to be.
> 
> Well, this is true. But almost regardless of the complexity, this is how
> we're going to want to do it, and it does mean we won't need the linear map.
> :)

Agreed.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 13 15:36:06 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Sep 2012 15:36:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TCBSR-0006HR-Ef; Thu, 13 Sep 2012 15:35:59 +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 1TCBSP-0006Gl-H6
	for xen-devel@lists.xen.org; Thu, 13 Sep 2012 15:35:57 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1347550551!9635885!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQxMjE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16367 invoked from network); 13 Sep 2012 15:35:51 -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;
	13 Sep 2012 15:35:51 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 13 Sep 2012 16:35:51 +0100
Message-Id: <505219AE020000780009B262@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 13 Sep 2012 16:36:46 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Keir Fraser" <keir.xen@gmail.com>,"Tim Deegan" <tim@xen.org>
References: <50521304020000780009B208@nat28.tlf.novell.com>
	<CC77B78E.3EAFE%keir.xen@gmail.com>
In-Reply-To: <CC77B78E.3EAFE%keir.xen@gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] x86/mm: remove the linear mapping of the
 p2m tables
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 13.09.12 at 17:17, Keir Fraser <keir.xen@gmail.com> wrote:
> On 13/09/2012 16:08, "Jan Beulich" <JBeulich@suse.com> wrote:
> 
>>>>> On 13.09.12 at 16:58, Keir Fraser <keir.xen@gmail.com> wrote:
>>> On 13/09/2012 15:42, "Tim Deegan" <tim@xen.org> wrote:
>>> 
>>>>> Is that also going to remain true when we won't be able to 1:1-
>>>>> map all of the memory anymore once we break the current 5Tb
>>>>> barrier? If not, it would probably be worthwhile keeping that
>>>>> code.
>>>> 
>>>> Ah, 5TB is a smaller limit than I thought we had.  Yes, better leave it
>>>> alone, so.  Though TBH finding some way to use a bit more virtual
>>>> address space for Xen seems like a good idea anyway, since this won't be
>>>> the only place we'll want to avoid TLB flushes.
>>> 
>>> For HVM or PVH guests, where this HAP code would be used, clearly Xen can
>>> use all the virtual address space it wants. It will almost certainly make
>>> sense for Xen to have a 1:1 physical mapping of all memory when running such
>>> a guest, and only do mapcache type tricks when running legacy PV guests.
>> 
>> Yes, that's the mode I indeed wanted to get to. Just that it's
>> not really clear to me (without having started at least the
>> work of bumping the boundary) how intrusive those changes
>> are going to be.
> 
> Well, this is true. But almost regardless of the complexity, this is how
> we're going to want to do it, and it does mean we won't need the linear map.
> :)

Agreed.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 13 15:42:40 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Sep 2012 15:42: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 1TCBYj-0006Ys-9r; Thu, 13 Sep 2012 15:42:29 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1TCBYh-0006Yn-Mf
	for xen-devel@lists.xensource.com; Thu, 13 Sep 2012 15:42:27 +0000
Received: from [85.158.138.51:47027] by server-7.bemta-3.messagelabs.com id
	B9/1A-32000-2EEF1505; Thu, 13 Sep 2012 15:42:26 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1347550946!22332771!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDkwMjg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12477 invoked from network); 13 Sep 2012 15:42:26 -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;
	13 Sep 2012 15:42:26 -0000
X-IronPort-AV: E=Sophos;i="4.80,417,1344211200"; d="scan'208";a="14525879"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Sep 2012 15:42: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.279.1; Thu, 13 Sep 2012 16:42: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
	1TCBYH-00075d-2l; Thu, 13 Sep 2012 15:42:01 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1TCBYG-0005tx-Uy;
	Thu, 13 Sep 2012 16:42:00 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20561.65224.676845.832212@mariner.uk.xensource.com>
Date: Thu, 13 Sep 2012 16:42:00 +0100
To: fantonifabio@tiscali.it
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <504DB6D0.3050900@tiscali.it>
References: <504DB6D0.3050900@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] Openvswitch error on shutdown/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

Fabio Fantoni writes ("[Xen-devel] Openvswitch error on shutdown/destroy"):
> I retried openvswitch on Wheezy 64 bit dom0 with xen 4.2.0-rc4 from source
> 
> vif script taken from here:
> http://xen.1045712.n5.nabble.com/openvswitch-on-xen-4-x-td4662995.html
> 
> Network works on dom0 and domU hvm windows 7 but on shutdown/destroy 
> shows this error:
> 
> xl destroy W7
> libxl: error: libxl_exec.c:118:libxl_report_child_exitstatus: 
> /etc/xen/scripts/vif-bridgeovs offline [4266] exited with error status 1
> libxl: error: libxl_device.c:978:device_hotplug_child_death_cb: script: 
> /etc/xen/scripts/vif-bridgeovs failed; error detected.

Can you please look in the various logfiles to see if you can see the
error message from the script ?  Hopefully that will make it clear
what's wrong.  It may be that there is some accidental incompatibility
introduced in 4.2, so can you please let us know what you find.

Thanks,
Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 13 15:42:40 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Sep 2012 15:42: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 1TCBYj-0006Ys-9r; Thu, 13 Sep 2012 15:42:29 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1TCBYh-0006Yn-Mf
	for xen-devel@lists.xensource.com; Thu, 13 Sep 2012 15:42:27 +0000
Received: from [85.158.138.51:47027] by server-7.bemta-3.messagelabs.com id
	B9/1A-32000-2EEF1505; Thu, 13 Sep 2012 15:42:26 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1347550946!22332771!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDkwMjg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12477 invoked from network); 13 Sep 2012 15:42:26 -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;
	13 Sep 2012 15:42:26 -0000
X-IronPort-AV: E=Sophos;i="4.80,417,1344211200"; d="scan'208";a="14525879"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Sep 2012 15:42: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.279.1; Thu, 13 Sep 2012 16:42: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
	1TCBYH-00075d-2l; Thu, 13 Sep 2012 15:42:01 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1TCBYG-0005tx-Uy;
	Thu, 13 Sep 2012 16:42:00 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20561.65224.676845.832212@mariner.uk.xensource.com>
Date: Thu, 13 Sep 2012 16:42:00 +0100
To: fantonifabio@tiscali.it
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <504DB6D0.3050900@tiscali.it>
References: <504DB6D0.3050900@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] Openvswitch error on shutdown/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

Fabio Fantoni writes ("[Xen-devel] Openvswitch error on shutdown/destroy"):
> I retried openvswitch on Wheezy 64 bit dom0 with xen 4.2.0-rc4 from source
> 
> vif script taken from here:
> http://xen.1045712.n5.nabble.com/openvswitch-on-xen-4-x-td4662995.html
> 
> Network works on dom0 and domU hvm windows 7 but on shutdown/destroy 
> shows this error:
> 
> xl destroy W7
> libxl: error: libxl_exec.c:118:libxl_report_child_exitstatus: 
> /etc/xen/scripts/vif-bridgeovs offline [4266] exited with error status 1
> libxl: error: libxl_device.c:978:device_hotplug_child_death_cb: script: 
> /etc/xen/scripts/vif-bridgeovs failed; error detected.

Can you please look in the various logfiles to see if you can see the
error message from the script ?  Hopefully that will make it clear
what's wrong.  It may be that there is some accidental incompatibility
introduced in 4.2, so can you please let us know what you find.

Thanks,
Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 13 15:49:50 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Sep 2012 15: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 1TCBfc-0006kA-7s; Thu, 13 Sep 2012 15:49: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 1TCBfa-0006k5-Hl
	for xen-devel@lists.xen.org; Thu, 13 Sep 2012 15:49:34 +0000
Received: from [85.158.143.99:18826] by server-3.bemta-4.messagelabs.com id
	F7/43-08232-D8002505; Thu, 13 Sep 2012 15:49:33 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1347551372!30208826!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDkwMjg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20124 invoked from network); 13 Sep 2012 15:49:33 -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 Sep 2012 15:49:33 -0000
X-IronPort-AV: E=Sophos;i="4.80,417,1344211200"; d="scan'208";a="14526042"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Sep 2012 15:49: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.279.1; Thu, 13 Sep 2012 16:49: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
	1TCBfY-0007Ab-Lb; Thu, 13 Sep 2012 15:49:32 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1TCBfY-0005uT-Hr;
	Thu, 13 Sep 2012 16:49:32 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20562.140.449219.771492@mariner.uk.xensource.com>
Date: Thu, 13 Sep 2012 16:49:32 +0100
To: Matt Wilson <msw@amazon.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <22452f41545c1786e887.1347295130@u002268147cd4502c336d.ant.amazon.com>
References: <22452f41545c1786e887.1347295130@u002268147cd4502c336d.ant.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 v2] docs: flesh out xl.cfg documentation,
 correct typos, reorganize
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 v2] docs: flesh out xl.cfg documentation, correct typos, reorganize"):
> Some highlights:
>  * Correct some markup errors:
>        Around line 663:
>            '=item' outside of any '=over'
>        Around line 671:
>            You forgot a '=back' before '=head3'
>  * Add documentation for msitranslate, power_mgnt, acpi_s3, aspi_s4,
>    gfx_passthru, nomigrate, etc.
>  * Reorganize items in "unclassified" sections like cpuid,
>    gfx_passthru to where they belong
>  * Correct link L<> references so they can be resolved within the
>    document
>  * Remove placeholders for deprecated options device_model and vif2
>  * Remove placeholder for "sched" and "node", as these are options for
>    cpupool configuration. Perhaps cpupool configuration deserves
>    a section in this document.
>  * Rename "global" options to "general"
>  * Add section headers to group general VM options.
> 
> Signed-off-by: Matt Wilson <msw@amazon.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 Sep 13 15:49:50 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Sep 2012 15: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 1TCBfc-0006kA-7s; Thu, 13 Sep 2012 15:49: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 1TCBfa-0006k5-Hl
	for xen-devel@lists.xen.org; Thu, 13 Sep 2012 15:49:34 +0000
Received: from [85.158.143.99:18826] by server-3.bemta-4.messagelabs.com id
	F7/43-08232-D8002505; Thu, 13 Sep 2012 15:49:33 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1347551372!30208826!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDkwMjg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20124 invoked from network); 13 Sep 2012 15:49:33 -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 Sep 2012 15:49:33 -0000
X-IronPort-AV: E=Sophos;i="4.80,417,1344211200"; d="scan'208";a="14526042"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Sep 2012 15:49: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.279.1; Thu, 13 Sep 2012 16:49: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
	1TCBfY-0007Ab-Lb; Thu, 13 Sep 2012 15:49:32 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1TCBfY-0005uT-Hr;
	Thu, 13 Sep 2012 16:49:32 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20562.140.449219.771492@mariner.uk.xensource.com>
Date: Thu, 13 Sep 2012 16:49:32 +0100
To: Matt Wilson <msw@amazon.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <22452f41545c1786e887.1347295130@u002268147cd4502c336d.ant.amazon.com>
References: <22452f41545c1786e887.1347295130@u002268147cd4502c336d.ant.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 v2] docs: flesh out xl.cfg documentation,
 correct typos, reorganize
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 v2] docs: flesh out xl.cfg documentation, correct typos, reorganize"):
> Some highlights:
>  * Correct some markup errors:
>        Around line 663:
>            '=item' outside of any '=over'
>        Around line 671:
>            You forgot a '=back' before '=head3'
>  * Add documentation for msitranslate, power_mgnt, acpi_s3, aspi_s4,
>    gfx_passthru, nomigrate, etc.
>  * Reorganize items in "unclassified" sections like cpuid,
>    gfx_passthru to where they belong
>  * Correct link L<> references so they can be resolved within the
>    document
>  * Remove placeholders for deprecated options device_model and vif2
>  * Remove placeholder for "sched" and "node", as these are options for
>    cpupool configuration. Perhaps cpupool configuration deserves
>    a section in this document.
>  * Rename "global" options to "general"
>  * Add section headers to group general VM options.
> 
> Signed-off-by: Matt Wilson <msw@amazon.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 Sep 13 15:51:25 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Sep 2012 15: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 1TCBhA-0006qr-No; Thu, 13 Sep 2012 15:51:12 +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 1TCBh8-0006qk-Ui
	for xen-devel@lists.xen.org; Thu, 13 Sep 2012 15:51:11 +0000
Received: from [85.158.139.83:55884] by server-11.bemta-5.messagelabs.com id
	C1/41-24658-EE002505; Thu, 13 Sep 2012 15:51:10 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1347551469!29823374!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-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19860 invoked from network); 13 Sep 2012 15:51:09 -0000
Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com)
	(74.125.83.45)
	by server-13.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Sep 2012 15:51:09 -0000
Received: by eeke53 with SMTP id e53so2132439eek.32
	for <xen-devel@lists.xen.org>; Thu, 13 Sep 2012 08:51:09 -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=2enJnVCvvz48Bl0smzo0I3UKKOLxHorgAOZt4VmwW4s=;
	b=B9dcHjZSqrugKHwGLulcrh44KrdZ45P5Te0UDiDQcSGTyjJzgGM4v1BxjPjtRQcLqF
	uPpI7BzCYplOHSQtR5Yy76wkNKg8syhl+oyO17rtGWVIl/h8BKxodWZvXNn/czdp7C5h
	mDut+j8IVDspi8CjTr8PWSOAq9OYD0fdOgjo1+kVqKfT5L/fRon1x7jpO6ac3HY5/Usm
	2AJZ3Ktj99MW6ST3yzWQyHxfQ31fne130BANCMZHJBaMxmtBnJmyJy3ypjgqImkfTd0i
	xWl0HTfLru89KsAb2e7YPe7H1WlhU6ugiLhnEUd1+BHIhxWl/HETTaoj20IqxGSUO3dL
	jUDQ==
Received: by 10.14.225.200 with SMTP id z48mr3453366eep.39.1347551469438;
	Thu, 13 Sep 2012 08:51:09 -0700 (PDT)
Received: from [192.168.1.69] (host86-184-74-117.range86-184.btcentralplus.com.
	[86.184.74.117])
	by mx.google.com with ESMTPS id r45sm66244509eem.6.2012.09.13.08.51.06
	(version=SSLv3 cipher=OTHER); Thu, 13 Sep 2012 08:51:08 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Thu, 13 Sep 2012 16:51:03 +0100
From: Keir Fraser <keir.xen@gmail.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <CC77BF77.3EB11%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] Clang/LLVM version requirements
Thread-Index: Ac2Rx5PuITbnkVs6qk+2mmoDSJTnTw==
In-Reply-To: <1347550071.24226.128.camel@zakaz.uk.xensource.com>
Mime-version: 1.0
Cc: Paolo Bonzini <pbonzini@redhat.com>, "Tim \(Xen.org\)" <tim@xen.org>,
	Jeffrey Karrels <karrelsj@gmail.com>, Jan Beulich <JBeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Clang/LLVM version requirements
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/09/2012 16:27, "Ian Campbell" <Ian.Campbell@citrix.com> wrote:

>> I should add, this is mainly a question of how aggressive we should be. I'm
>> quite happy to retire gcc-3.4 support if it happens it is now broken. In
>> that case, x86/Rules.mk should have its gcc version check updated. And
>> perhaps arch/arm may as well do the same? I would be happy to Ack a patch to
>> that effect.
> 
> Some data points: Debian Squeeze (current stable) has gcc 4.4 as the
> default (but ships a bunch of others) and Lenny (previous stable) had
> 4.3. AFAICT RHEL5 and SLES10 both shipped 4.1, SLES11 shipped 4.3 and
> RHEL 6 4.4.
> 
> Do we really want/need to support host OSes older than RHEL5/SLES10? We
> are talking 2006/7 vintage there.

Yes, I think that is where we are going to draw the line. Thanks.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 13 15:51:25 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Sep 2012 15: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 1TCBhA-0006qr-No; Thu, 13 Sep 2012 15:51:12 +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 1TCBh8-0006qk-Ui
	for xen-devel@lists.xen.org; Thu, 13 Sep 2012 15:51:11 +0000
Received: from [85.158.139.83:55884] by server-11.bemta-5.messagelabs.com id
	C1/41-24658-EE002505; Thu, 13 Sep 2012 15:51:10 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1347551469!29823374!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-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19860 invoked from network); 13 Sep 2012 15:51:09 -0000
Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com)
	(74.125.83.45)
	by server-13.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Sep 2012 15:51:09 -0000
Received: by eeke53 with SMTP id e53so2132439eek.32
	for <xen-devel@lists.xen.org>; Thu, 13 Sep 2012 08:51:09 -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=2enJnVCvvz48Bl0smzo0I3UKKOLxHorgAOZt4VmwW4s=;
	b=B9dcHjZSqrugKHwGLulcrh44KrdZ45P5Te0UDiDQcSGTyjJzgGM4v1BxjPjtRQcLqF
	uPpI7BzCYplOHSQtR5Yy76wkNKg8syhl+oyO17rtGWVIl/h8BKxodWZvXNn/czdp7C5h
	mDut+j8IVDspi8CjTr8PWSOAq9OYD0fdOgjo1+kVqKfT5L/fRon1x7jpO6ac3HY5/Usm
	2AJZ3Ktj99MW6ST3yzWQyHxfQ31fne130BANCMZHJBaMxmtBnJmyJy3ypjgqImkfTd0i
	xWl0HTfLru89KsAb2e7YPe7H1WlhU6ugiLhnEUd1+BHIhxWl/HETTaoj20IqxGSUO3dL
	jUDQ==
Received: by 10.14.225.200 with SMTP id z48mr3453366eep.39.1347551469438;
	Thu, 13 Sep 2012 08:51:09 -0700 (PDT)
Received: from [192.168.1.69] (host86-184-74-117.range86-184.btcentralplus.com.
	[86.184.74.117])
	by mx.google.com with ESMTPS id r45sm66244509eem.6.2012.09.13.08.51.06
	(version=SSLv3 cipher=OTHER); Thu, 13 Sep 2012 08:51:08 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Thu, 13 Sep 2012 16:51:03 +0100
From: Keir Fraser <keir.xen@gmail.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <CC77BF77.3EB11%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] Clang/LLVM version requirements
Thread-Index: Ac2Rx5PuITbnkVs6qk+2mmoDSJTnTw==
In-Reply-To: <1347550071.24226.128.camel@zakaz.uk.xensource.com>
Mime-version: 1.0
Cc: Paolo Bonzini <pbonzini@redhat.com>, "Tim \(Xen.org\)" <tim@xen.org>,
	Jeffrey Karrels <karrelsj@gmail.com>, Jan Beulich <JBeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Clang/LLVM version requirements
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/09/2012 16:27, "Ian Campbell" <Ian.Campbell@citrix.com> wrote:

>> I should add, this is mainly a question of how aggressive we should be. I'm
>> quite happy to retire gcc-3.4 support if it happens it is now broken. In
>> that case, x86/Rules.mk should have its gcc version check updated. And
>> perhaps arch/arm may as well do the same? I would be happy to Ack a patch to
>> that effect.
> 
> Some data points: Debian Squeeze (current stable) has gcc 4.4 as the
> default (but ships a bunch of others) and Lenny (previous stable) had
> 4.3. AFAICT RHEL5 and SLES10 both shipped 4.1, SLES11 shipped 4.3 and
> RHEL 6 4.4.
> 
> Do we really want/need to support host OSes older than RHEL5/SLES10? We
> are talking 2006/7 vintage there.

Yes, I think that is where we are going to draw the line. Thanks.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 13 15:54:17 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Sep 2012 15:54:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TCBju-00070Y-B8; Thu, 13 Sep 2012 15:54:02 +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 1TCBjs-00070B-9T
	for xen-devel@lists.xensource.com; Thu, 13 Sep 2012 15:54:00 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1347551634!3909885!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDkwMjg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11841 invoked from network); 13 Sep 2012 15:53:54 -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;
	13 Sep 2012 15:53:54 -0000
X-IronPort-AV: E=Sophos;i="4.80,417,1344211200"; d="scan'208";a="14526131"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Sep 2012 15:53: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.279.1; Thu, 13 Sep 2012 16:53: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
	1TCBjl-0007IA-TL; Thu, 13 Sep 2012 15:53:53 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1TCBjl-0005uv-PG;
	Thu, 13 Sep 2012 16:53:53 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20562.397.264907.380798@mariner.uk.xensource.com>
Date: Thu, 13 Sep 2012 16:53:49 +0100
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <m2n.s.1TBAAE-152299@chiark.greenend.org.uk>
References: <1347306367-28669-1-git-send-email-konrad.wilk@oracle.com>
	<m2n.s.1TBAAE-152299@chiark.greenend.org.uk>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org,
	stefano.stabellini@eu.citrix.com
Subject: Re: [Xen-devel] [PATCH 09/10] xen/swiotlb: Fix compile warnings
	when	using plain integer instead of NULL pointer.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Konrad Rzeszutek Wilk writes ("[Xen-devel] [PATCH 09/10] xen/swiotlb: Fix compile warnings when using plain integer instead of NULL pointer."):
> arch/x86/xen/pci-swiotlb-xen.c:96:1: warning: Using plain integer as NULL pointer
> arch/x86/xen/pci-swiotlb-xen.c:96:1: warning: Using plain integer as NULL pointer

This warning is simply wrong for this code:

>  IOMMU_INIT_FINISH(pci_xen_swiotlb_detect,
> -		  0,
> +		  NULL,

There is (according to the C language specifications) nothing wrong
with writing 0 for a null pointer.

Nor does CODING_STYLE say that it is forbidden to just write 0.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 13 15:54:17 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Sep 2012 15:54:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TCBju-00070Y-B8; Thu, 13 Sep 2012 15:54:02 +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 1TCBjs-00070B-9T
	for xen-devel@lists.xensource.com; Thu, 13 Sep 2012 15:54:00 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1347551634!3909885!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDkwMjg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11841 invoked from network); 13 Sep 2012 15:53:54 -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;
	13 Sep 2012 15:53:54 -0000
X-IronPort-AV: E=Sophos;i="4.80,417,1344211200"; d="scan'208";a="14526131"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Sep 2012 15:53: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.279.1; Thu, 13 Sep 2012 16:53: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
	1TCBjl-0007IA-TL; Thu, 13 Sep 2012 15:53:53 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1TCBjl-0005uv-PG;
	Thu, 13 Sep 2012 16:53:53 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20562.397.264907.380798@mariner.uk.xensource.com>
Date: Thu, 13 Sep 2012 16:53:49 +0100
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <m2n.s.1TBAAE-152299@chiark.greenend.org.uk>
References: <1347306367-28669-1-git-send-email-konrad.wilk@oracle.com>
	<m2n.s.1TBAAE-152299@chiark.greenend.org.uk>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org,
	stefano.stabellini@eu.citrix.com
Subject: Re: [Xen-devel] [PATCH 09/10] xen/swiotlb: Fix compile warnings
	when	using plain integer instead of NULL pointer.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Konrad Rzeszutek Wilk writes ("[Xen-devel] [PATCH 09/10] xen/swiotlb: Fix compile warnings when using plain integer instead of NULL pointer."):
> arch/x86/xen/pci-swiotlb-xen.c:96:1: warning: Using plain integer as NULL pointer
> arch/x86/xen/pci-swiotlb-xen.c:96:1: warning: Using plain integer as NULL pointer

This warning is simply wrong for this code:

>  IOMMU_INIT_FINISH(pci_xen_swiotlb_detect,
> -		  0,
> +		  NULL,

There is (according to the C language specifications) nothing wrong
with writing 0 for a null pointer.

Nor does CODING_STYLE say that it is forbidden to just write 0.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 13 15:56:27 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Sep 2012 15:56: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 1TCBm3-0007Bk-0w; Thu, 13 Sep 2012 15:56: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 1TCBm1-0007BM-Uo
	for xen-devel@lists.xensource.com; Thu, 13 Sep 2012 15:56:14 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1347551764!3910149!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDkwMjg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25281 invoked from network); 13 Sep 2012 15:56:05 -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 Sep 2012 15:56:05 -0000
X-IronPort-AV: E=Sophos;i="4.80,417,1344211200"; d="scan'208";a="14526196"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Sep 2012 15:56: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.279.1; Thu, 13 Sep 2012 16:56: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
	1TCBls-0007J2-8V; Thu, 13 Sep 2012 15:56:04 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1TCBls-0005vU-4z;
	Thu, 13 Sep 2012 16:56:04 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20562.532.48940.555794@mariner.uk.xensource.com>
Date: Thu, 13 Sep 2012 16:56:04 +0100
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	<linux-kernel@vger.kernel.org>, <xen-devel@lists.xensource.com>,
	<stefano.stabellini@eu.citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <20562.397.264907.380798@mariner.uk.xensource.com>
References: <1347306367-28669-1-git-send-email-konrad.wilk@oracle.com>
	<m2n.s.1TBAAE-152299@chiark.greenend.org.uk>
	<20562.397.264907.380798@mariner.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Subject: Re: [Xen-devel] [PATCH 09/10] xen/swiotlb: Fix compile warnings
	when	using plain integer instead of NULL pointer.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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 09/10] xen/swiotlb: Fix compile warnings when using plain integer instead of NULL pointer."):
> Konrad Rzeszutek Wilk writes ("[Xen-devel] [PATCH 09/10] xen/swiotlb: Fix compile warnings when using plain integer instead of NULL pointer."):
> > arch/x86/xen/pci-swiotlb-xen.c:96:1: warning: Using plain integer as NULL pointer
> > arch/x86/xen/pci-swiotlb-xen.c:96:1: warning: Using plain integer as NULL pointer
> 
> This warning is simply wrong for this code:
> 
> >  IOMMU_INIT_FINISH(pci_xen_swiotlb_detect,
> > -		  0,
> > +		  NULL,
> 
> There is (according to the C language specifications) nothing wrong
> with writing 0 for a null pointer.
> 
> Nor does CODING_STYLE say that it is forbidden to just write 0.

Oh wait this is Linux kernel code, not in Xen?  Still,
Documentation/CodingStyle doesn't say that NULL is required.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 13 15:56:27 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Sep 2012 15:56: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 1TCBm3-0007Bk-0w; Thu, 13 Sep 2012 15:56: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 1TCBm1-0007BM-Uo
	for xen-devel@lists.xensource.com; Thu, 13 Sep 2012 15:56:14 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1347551764!3910149!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDkwMjg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25281 invoked from network); 13 Sep 2012 15:56:05 -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 Sep 2012 15:56:05 -0000
X-IronPort-AV: E=Sophos;i="4.80,417,1344211200"; d="scan'208";a="14526196"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Sep 2012 15:56: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.279.1; Thu, 13 Sep 2012 16:56: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
	1TCBls-0007J2-8V; Thu, 13 Sep 2012 15:56:04 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1TCBls-0005vU-4z;
	Thu, 13 Sep 2012 16:56:04 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20562.532.48940.555794@mariner.uk.xensource.com>
Date: Thu, 13 Sep 2012 16:56:04 +0100
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	<linux-kernel@vger.kernel.org>, <xen-devel@lists.xensource.com>,
	<stefano.stabellini@eu.citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <20562.397.264907.380798@mariner.uk.xensource.com>
References: <1347306367-28669-1-git-send-email-konrad.wilk@oracle.com>
	<m2n.s.1TBAAE-152299@chiark.greenend.org.uk>
	<20562.397.264907.380798@mariner.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Subject: Re: [Xen-devel] [PATCH 09/10] xen/swiotlb: Fix compile warnings
	when	using plain integer instead of NULL pointer.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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 09/10] xen/swiotlb: Fix compile warnings when using plain integer instead of NULL pointer."):
> Konrad Rzeszutek Wilk writes ("[Xen-devel] [PATCH 09/10] xen/swiotlb: Fix compile warnings when using plain integer instead of NULL pointer."):
> > arch/x86/xen/pci-swiotlb-xen.c:96:1: warning: Using plain integer as NULL pointer
> > arch/x86/xen/pci-swiotlb-xen.c:96:1: warning: Using plain integer as NULL pointer
> 
> This warning is simply wrong for this code:
> 
> >  IOMMU_INIT_FINISH(pci_xen_swiotlb_detect,
> > -		  0,
> > +		  NULL,
> 
> There is (according to the C language specifications) nothing wrong
> with writing 0 for a null pointer.
> 
> Nor does CODING_STYLE say that it is forbidden to just write 0.

Oh wait this is Linux kernel code, not in Xen?  Still,
Documentation/CodingStyle doesn't say that NULL is required.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 13 16:00:48 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Sep 2012 16:00:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TCBqH-0007y7-B9; Thu, 13 Sep 2012 16:00:37 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1TCBqF-0007xy-C1
	for xen-devel@lists.xensource.com; Thu, 13 Sep 2012 16:00:35 +0000
Received: from [85.158.139.83:51199] by server-9.bemta-5.messagelabs.com id
	A1/EC-20529-22302505; Thu, 13 Sep 2012 16:00:34 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1347552033!23142059!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDkwMjg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22673 invoked from network); 13 Sep 2012 16:00:34 -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 Sep 2012 16:00:34 -0000
X-IronPort-AV: E=Sophos;i="4.80,417,1344211200"; d="scan'208";a="14526314"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Sep 2012 16:00:33 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Thu, 13 Sep 2012 17:00: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
	1TCBqC-0007Wq-WF; Thu, 13 Sep 2012 16:00:33 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1TCBqC-0005vh-S5;
	Thu, 13 Sep 2012 17:00:32 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20562.800.744932.439629@mariner.uk.xensource.com>
Date: Thu, 13 Sep 2012 17:00:32 +0100
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	linux-kernel@vger.kernel.org, xen-devel@lists.xensource.com,
	stefano.stabellini@eu.citrix.com
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <20562.532.48940.555794@mariner.uk.xensource.com>
References: <1347306367-28669-1-git-send-email-konrad.wilk@oracle.com>
	<m2n.s.1TBAAE-152299@chiark.greenend.org.uk>
	<20562.397.264907.380798@mariner.uk.xensource.com>
	<20562.532.48940.555794@mariner.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Subject: Re: [Xen-devel] [PATCH 09/10] xen/swiotlb: Fix compile warnings
	when	using plain integer instead of NULL pointer.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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 09/10] xen/swiotlb: Fix compile warnings when using plain integer instead of NULL pointer."):
> Oh wait this is Linux kernel code, not in Xen?  Still,
> Documentation/CodingStyle doesn't say that NULL is required.

Someone on irc found me this rant from Linus:
  https://lkml.org/lkml/2004/7/8/7
That suggests that perhaps someone should patch CodingStyle to
document this style requirement.

That someone shouldn't be me because I don't agree with the
requirement and a rationale I'd write for it would come out sounding
sarcastic.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 13 16:00:48 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Sep 2012 16:00:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TCBqH-0007y7-B9; Thu, 13 Sep 2012 16:00:37 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1TCBqF-0007xy-C1
	for xen-devel@lists.xensource.com; Thu, 13 Sep 2012 16:00:35 +0000
Received: from [85.158.139.83:51199] by server-9.bemta-5.messagelabs.com id
	A1/EC-20529-22302505; Thu, 13 Sep 2012 16:00:34 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1347552033!23142059!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDkwMjg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22673 invoked from network); 13 Sep 2012 16:00:34 -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 Sep 2012 16:00:34 -0000
X-IronPort-AV: E=Sophos;i="4.80,417,1344211200"; d="scan'208";a="14526314"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Sep 2012 16:00:33 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Thu, 13 Sep 2012 17:00: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
	1TCBqC-0007Wq-WF; Thu, 13 Sep 2012 16:00:33 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1TCBqC-0005vh-S5;
	Thu, 13 Sep 2012 17:00:32 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20562.800.744932.439629@mariner.uk.xensource.com>
Date: Thu, 13 Sep 2012 17:00:32 +0100
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	linux-kernel@vger.kernel.org, xen-devel@lists.xensource.com,
	stefano.stabellini@eu.citrix.com
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <20562.532.48940.555794@mariner.uk.xensource.com>
References: <1347306367-28669-1-git-send-email-konrad.wilk@oracle.com>
	<m2n.s.1TBAAE-152299@chiark.greenend.org.uk>
	<20562.397.264907.380798@mariner.uk.xensource.com>
	<20562.532.48940.555794@mariner.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Subject: Re: [Xen-devel] [PATCH 09/10] xen/swiotlb: Fix compile warnings
	when	using plain integer instead of NULL pointer.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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 09/10] xen/swiotlb: Fix compile warnings when using plain integer instead of NULL pointer."):
> Oh wait this is Linux kernel code, not in Xen?  Still,
> Documentation/CodingStyle doesn't say that NULL is required.

Someone on irc found me this rant from Linus:
  https://lkml.org/lkml/2004/7/8/7
That suggests that perhaps someone should patch CodingStyle to
document this style requirement.

That someone shouldn't be me because I don't agree with the
requirement and a rationale I'd write for it would come out sounding
sarcastic.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 13 16:03:34 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Sep 2012 16:03: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 1TCBsv-00088i-3Z; Thu, 13 Sep 2012 16:03:21 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1TCBsq-00088X-Uw
	for xen-devel@lists.xen.org; Thu, 13 Sep 2012 16:03:20 +0000
Received: from [85.158.143.99:51280] by server-2.bemta-4.messagelabs.com id
	F2/D3-21239-4C302505; Thu, 13 Sep 2012 16:03:16 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-14.tower-216.messagelabs.com!1347552195!20603868!1
X-Originating-IP: [208.97.132.202]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4yMDIgPT4gMzEwNjM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7340 invoked from network); 13 Sep 2012 16:03:15 -0000
Received: from caiajhbdccac.dreamhost.com (HELO homiemail-a76.g.dreamhost.com)
	(208.97.132.202) by server-14.tower-216.messagelabs.com with SMTP;
	13 Sep 2012 16:03:15 -0000
Received: from homiemail-a76.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a76.g.dreamhost.com (Postfix) with ESMTP id 8BD85458081;
	Thu, 13 Sep 2012 09:03:14 -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=nHD7EDkVJ+16vILlul3trz
	/uiOvW0jD3ilbAVpvKfynX37egAK5THWo+tscsfLci0OONGJ7BtZwHurRTfnX74S
	wi3R/U79cjAWAitpJ+T29sT8I54wQ517kPNv7entV7ZVlKGkYNSmwv+I3zFd7aQP
	Ok2BfEgApAgObNl6+9WSA=
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=yV7Aoee7srtX
	1sf78W6WvoIx8C0=; b=WWnRPDd/lj99DFGBtd1gekUa8VDKvXsXcxzNaCx7vl9c
	F9rLqDvu4+OPEJTxY3dXRCy/P9avUmSo1ZFRIKnNMEvboNQlCfjBgldlm/yW50Lo
	qvQSwQgmQKsYzQOVretLWkYmM4f/SQYfpG6tX3nNfF0mIP+HG3nIQa8aqLuWVOo=
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-a76.g.dreamhost.com (Postfix) with ESMTPSA id D9373458080; 
	Thu, 13 Sep 2012 09:03:13 -0700 (PDT)
MIME-Version: 1.0
X-Mercurial-Node: 9bfaf86e061f433c65aed860ac4fa28f594368d4
Message-Id: <9bfaf86e061f433c65ae.1347552545@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Thu, 13 Sep 2012 12:09:05 -0400
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xen.org
Cc: ian.jackson@citrix.com, andres@gridcentric.ca, ian.campbell@citrix.com
Subject: [Xen-devel] [PATCH] Fix libxenstore memory leak when USE_PTHREAD is
	not defined
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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/xenstore/xs.c |  22 ++++++----------------
 1 files changed, 6 insertions(+), 16 deletions(-)


Remove usage of pthread_cleanup_push and _pop, and explicitly call free for
heap objects in error paths. Also remove cleanup_p* for a mutex unlock path. By
the way, set a suitable errno value for an error path that had none.

Resend due to small fix spotted, please ignore previous one.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r 588d0dc298a4 -r 9bfaf86e061f tools/xenstore/xs.c
--- a/tools/xenstore/xs.c
+++ b/tools/xenstore/xs.c
@@ -99,14 +99,6 @@ struct xs_handle {
 #define mutex_unlock(m)		pthread_mutex_unlock(m)
 #define condvar_signal(c)	pthread_cond_signal(c)
 #define condvar_wait(c,m)	pthread_cond_wait(c,m)
-#define cleanup_push(f, a)	\
-    pthread_cleanup_push((void (*)(void *))(f), (void *)(a))
-/*
- * Some definitions of pthread_cleanup_pop() are a macro starting with an
- * end-brace. GCC then complains if we immediately precede that with a label.
- * Hence we insert a dummy statement to appease the compiler in this situation.
- */
-#define cleanup_pop(run)        ((void)0); pthread_cleanup_pop(run)
 
 #define read_thread_exists(h)	(h->read_thr_exists)
 
@@ -126,8 +118,6 @@ struct xs_handle {
 #define mutex_unlock(m)		((void)0)
 #define condvar_signal(c)	((void)0)
 #define condvar_wait(c,m)	((void)0)
-#define cleanup_push(f, a)	((void)0)
-#define cleanup_pop(run)	((void)0)
 #define read_thread_exists(h)	(0)
 
 #endif
@@ -1059,7 +1049,6 @@ static int read_message(struct xs_handle
 	msg = malloc(sizeof(*msg));
 	if (msg == NULL)
 		goto error;
-	cleanup_push(free, msg);
 	if (!read_all(h->fd, &msg->hdr, sizeof(msg->hdr), nonblocking)) { /* Cancellation point */
 		saved_errno = errno;
 		goto error_freemsg;
@@ -1069,7 +1058,6 @@ static int read_message(struct xs_handle
 	body = msg->body = malloc(msg->hdr.len + 1);
 	if (body == NULL)
 		goto error_freemsg;
-	cleanup_push(free, body);
 	if (!read_all(h->fd, body, msg->hdr.len, 0)) { /* Cancellation point */
 		saved_errno = errno;
 		goto error_freebody;
@@ -1079,7 +1067,6 @@ static int read_message(struct xs_handle
 
 	if (msg->hdr.type == XS_WATCH_EVENT) {
 		mutex_lock(&h->watch_mutex);
-		cleanup_push(pthread_mutex_unlock, &h->watch_mutex);
 
 		/* Kick users out of their select() loop. */
 		if (list_empty(&h->watch_list) &&
@@ -1091,13 +1078,14 @@ static int read_message(struct xs_handle
 
 		condvar_signal(&h->watch_condvar);
 
-		cleanup_pop(1);
+		mutex_unlock(&h->watch_mutex);
 	} else {
 		mutex_lock(&h->reply_mutex);
 
 		/* There should only ever be one response pending! */
 		if (!list_empty(&h->reply_list)) {
 			mutex_unlock(&h->reply_mutex);
+			saved_errno = EEXIST; 
 			goto error_freebody;
 		}
 
@@ -1110,9 +1098,11 @@ static int read_message(struct xs_handle
 	ret = 0;
 
 error_freebody:
-	cleanup_pop(ret == -1);
+	if (ret)
+		free(body);
 error_freemsg:
-	cleanup_pop(ret == -1);
+	if (ret)
+		free(msg);
 error:
 	errno = saved_errno;
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 13 16:03:34 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Sep 2012 16:03: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 1TCBsv-00088i-3Z; Thu, 13 Sep 2012 16:03:21 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1TCBsq-00088X-Uw
	for xen-devel@lists.xen.org; Thu, 13 Sep 2012 16:03:20 +0000
Received: from [85.158.143.99:51280] by server-2.bemta-4.messagelabs.com id
	F2/D3-21239-4C302505; Thu, 13 Sep 2012 16:03:16 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-14.tower-216.messagelabs.com!1347552195!20603868!1
X-Originating-IP: [208.97.132.202]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4yMDIgPT4gMzEwNjM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7340 invoked from network); 13 Sep 2012 16:03:15 -0000
Received: from caiajhbdccac.dreamhost.com (HELO homiemail-a76.g.dreamhost.com)
	(208.97.132.202) by server-14.tower-216.messagelabs.com with SMTP;
	13 Sep 2012 16:03:15 -0000
Received: from homiemail-a76.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a76.g.dreamhost.com (Postfix) with ESMTP id 8BD85458081;
	Thu, 13 Sep 2012 09:03:14 -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=nHD7EDkVJ+16vILlul3trz
	/uiOvW0jD3ilbAVpvKfynX37egAK5THWo+tscsfLci0OONGJ7BtZwHurRTfnX74S
	wi3R/U79cjAWAitpJ+T29sT8I54wQ517kPNv7entV7ZVlKGkYNSmwv+I3zFd7aQP
	Ok2BfEgApAgObNl6+9WSA=
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=yV7Aoee7srtX
	1sf78W6WvoIx8C0=; b=WWnRPDd/lj99DFGBtd1gekUa8VDKvXsXcxzNaCx7vl9c
	F9rLqDvu4+OPEJTxY3dXRCy/P9avUmSo1ZFRIKnNMEvboNQlCfjBgldlm/yW50Lo
	qvQSwQgmQKsYzQOVretLWkYmM4f/SQYfpG6tX3nNfF0mIP+HG3nIQa8aqLuWVOo=
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-a76.g.dreamhost.com (Postfix) with ESMTPSA id D9373458080; 
	Thu, 13 Sep 2012 09:03:13 -0700 (PDT)
MIME-Version: 1.0
X-Mercurial-Node: 9bfaf86e061f433c65aed860ac4fa28f594368d4
Message-Id: <9bfaf86e061f433c65ae.1347552545@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Thu, 13 Sep 2012 12:09:05 -0400
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xen.org
Cc: ian.jackson@citrix.com, andres@gridcentric.ca, ian.campbell@citrix.com
Subject: [Xen-devel] [PATCH] Fix libxenstore memory leak when USE_PTHREAD is
	not defined
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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/xenstore/xs.c |  22 ++++++----------------
 1 files changed, 6 insertions(+), 16 deletions(-)


Remove usage of pthread_cleanup_push and _pop, and explicitly call free for
heap objects in error paths. Also remove cleanup_p* for a mutex unlock path. By
the way, set a suitable errno value for an error path that had none.

Resend due to small fix spotted, please ignore previous one.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r 588d0dc298a4 -r 9bfaf86e061f tools/xenstore/xs.c
--- a/tools/xenstore/xs.c
+++ b/tools/xenstore/xs.c
@@ -99,14 +99,6 @@ struct xs_handle {
 #define mutex_unlock(m)		pthread_mutex_unlock(m)
 #define condvar_signal(c)	pthread_cond_signal(c)
 #define condvar_wait(c,m)	pthread_cond_wait(c,m)
-#define cleanup_push(f, a)	\
-    pthread_cleanup_push((void (*)(void *))(f), (void *)(a))
-/*
- * Some definitions of pthread_cleanup_pop() are a macro starting with an
- * end-brace. GCC then complains if we immediately precede that with a label.
- * Hence we insert a dummy statement to appease the compiler in this situation.
- */
-#define cleanup_pop(run)        ((void)0); pthread_cleanup_pop(run)
 
 #define read_thread_exists(h)	(h->read_thr_exists)
 
@@ -126,8 +118,6 @@ struct xs_handle {
 #define mutex_unlock(m)		((void)0)
 #define condvar_signal(c)	((void)0)
 #define condvar_wait(c,m)	((void)0)
-#define cleanup_push(f, a)	((void)0)
-#define cleanup_pop(run)	((void)0)
 #define read_thread_exists(h)	(0)
 
 #endif
@@ -1059,7 +1049,6 @@ static int read_message(struct xs_handle
 	msg = malloc(sizeof(*msg));
 	if (msg == NULL)
 		goto error;
-	cleanup_push(free, msg);
 	if (!read_all(h->fd, &msg->hdr, sizeof(msg->hdr), nonblocking)) { /* Cancellation point */
 		saved_errno = errno;
 		goto error_freemsg;
@@ -1069,7 +1058,6 @@ static int read_message(struct xs_handle
 	body = msg->body = malloc(msg->hdr.len + 1);
 	if (body == NULL)
 		goto error_freemsg;
-	cleanup_push(free, body);
 	if (!read_all(h->fd, body, msg->hdr.len, 0)) { /* Cancellation point */
 		saved_errno = errno;
 		goto error_freebody;
@@ -1079,7 +1067,6 @@ static int read_message(struct xs_handle
 
 	if (msg->hdr.type == XS_WATCH_EVENT) {
 		mutex_lock(&h->watch_mutex);
-		cleanup_push(pthread_mutex_unlock, &h->watch_mutex);
 
 		/* Kick users out of their select() loop. */
 		if (list_empty(&h->watch_list) &&
@@ -1091,13 +1078,14 @@ static int read_message(struct xs_handle
 
 		condvar_signal(&h->watch_condvar);
 
-		cleanup_pop(1);
+		mutex_unlock(&h->watch_mutex);
 	} else {
 		mutex_lock(&h->reply_mutex);
 
 		/* There should only ever be one response pending! */
 		if (!list_empty(&h->reply_list)) {
 			mutex_unlock(&h->reply_mutex);
+			saved_errno = EEXIST; 
 			goto error_freebody;
 		}
 
@@ -1110,9 +1098,11 @@ static int read_message(struct xs_handle
 	ret = 0;
 
 error_freebody:
-	cleanup_pop(ret == -1);
+	if (ret)
+		free(body);
 error_freemsg:
-	cleanup_pop(ret == -1);
+	if (ret)
+		free(msg);
 error:
 	errno = saved_errno;
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 13 16:06:34 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Sep 2012 16:06:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TCBvn-0008HT-Q4; Thu, 13 Sep 2012 16:06:19 +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 1TCBvm-0008HG-4a
	for xen-devel@lists.xensource.com; Thu, 13 Sep 2012 16:06:18 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1347552371!5341908!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDkwMjg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23793 invoked from network); 13 Sep 2012 16:06:11 -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 Sep 2012 16:06:11 -0000
X-IronPort-AV: E=Sophos;i="4.80,417,1344211200"; d="scan'208";a="14526466"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Sep 2012 16:06: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.279.1; Thu, 13 Sep 2012 17:06: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
	1TCBvd-0007a8-0Y; Thu, 13 Sep 2012 16:06:09 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1TCBvc-0005wH-Sh;
	Thu, 13 Sep 2012 17:06:08 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20562.1136.780934.319751@mariner.uk.xensource.com>
Date: Thu, 13 Sep 2012 17:06:08 +0100
To: Sander Eikelenboom <linux@eikelenboom.it>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <4c3d49787cea5e1dffc5.1346960487@xentest.example.org>
References: <patchbomb.1346960486@xentest.example.org>
	<4c3d49787cea5e1dffc5.1346960487@xentest.example.org>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com, Ian.Campbell@citrix.com
Subject: Re: [Xen-devel] [PATCH 1 of 3] xl: Introduce shutdown xm
	compatibility	option -a
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Sander Eikelenboom writes ("[Xen-devel] [PATCH 1 of 3] xl: Introduce shutdown xm compatibility option -a"):
>   * Add missing option -a to shutdown all guest domains

> +        for (i = 0; i<nb_domain; i++) {
> +            if (dominfo[i].domid == 0)
> +                continue;
> +
> +            shutdown_domain(dominfo[i].domid, wait, fallback_trigger);
> +        }

This isn't quite right, I think.  Surely it should initiate the
shutdown for all the domains right away, and then wait for them all to
finish ?

That's going to make the patch more complicated of course...

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 13 16:06:34 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Sep 2012 16:06:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TCBvn-0008HT-Q4; Thu, 13 Sep 2012 16:06:19 +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 1TCBvm-0008HG-4a
	for xen-devel@lists.xensource.com; Thu, 13 Sep 2012 16:06:18 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1347552371!5341908!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDkwMjg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23793 invoked from network); 13 Sep 2012 16:06:11 -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 Sep 2012 16:06:11 -0000
X-IronPort-AV: E=Sophos;i="4.80,417,1344211200"; d="scan'208";a="14526466"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Sep 2012 16:06: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.279.1; Thu, 13 Sep 2012 17:06: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
	1TCBvd-0007a8-0Y; Thu, 13 Sep 2012 16:06:09 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1TCBvc-0005wH-Sh;
	Thu, 13 Sep 2012 17:06:08 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20562.1136.780934.319751@mariner.uk.xensource.com>
Date: Thu, 13 Sep 2012 17:06:08 +0100
To: Sander Eikelenboom <linux@eikelenboom.it>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <4c3d49787cea5e1dffc5.1346960487@xentest.example.org>
References: <patchbomb.1346960486@xentest.example.org>
	<4c3d49787cea5e1dffc5.1346960487@xentest.example.org>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com, Ian.Campbell@citrix.com
Subject: Re: [Xen-devel] [PATCH 1 of 3] xl: Introduce shutdown xm
	compatibility	option -a
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Sander Eikelenboom writes ("[Xen-devel] [PATCH 1 of 3] xl: Introduce shutdown xm compatibility option -a"):
>   * Add missing option -a to shutdown all guest domains

> +        for (i = 0; i<nb_domain; i++) {
> +            if (dominfo[i].domid == 0)
> +                continue;
> +
> +            shutdown_domain(dominfo[i].domid, wait, fallback_trigger);
> +        }

This isn't quite right, I think.  Surely it should initiate the
shutdown for all the domains right away, and then wait for them all to
finish ?

That's going to make the patch more complicated of course...

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 13 16:07:32 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Sep 2012 16: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 1TCBwh-0008M7-80; Thu, 13 Sep 2012 16:07: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 1TCBwg-0008Lv-5S
	for xen-devel@lists.xensource.com; Thu, 13 Sep 2012 16:07:14 +0000
Received: from [85.158.143.35:12273] by server-2.bemta-4.messagelabs.com id
	F0/C8-21239-1B402505; Thu, 13 Sep 2012 16:07:13 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1347552432!10433775!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDkwMjg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15656 invoked from network); 13 Sep 2012 16:07:13 -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;
	13 Sep 2012 16:07:13 -0000
X-IronPort-AV: E=Sophos;i="4.80,417,1344211200"; d="scan'208";a="14526484"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Sep 2012 16:07:12 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Thu, 13 Sep 2012 17:07: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
	1TCBwe-0007c1-Fl; Thu, 13 Sep 2012 16:07:12 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1TCBwe-0005wW-B9;
	Thu, 13 Sep 2012 17:07:12 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20562.1196.424904.928439@mariner.uk.xensource.com>
Date: Thu, 13 Sep 2012 17:07:08 +0100
To: Sander Eikelenboom <linux@eikelenboom.it>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <261ce3cdaee8d5c30f12.1346960489@xentest.example.org>
References: <patchbomb.1346960486@xentest.example.org>
	<261ce3cdaee8d5c30f12.1346960489@xentest.example.org>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com, Ian.Campbell@citrix.com
Subject: Re: [Xen-devel] [PATCH 3 of 3] hotplug: Change options used for
 shutdown command in xendomains script to be compatible with both xm and 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

Sander Eikelenboom writes ("[Xen-devel] [PATCH 3 of 3] hotplug: Change options used for shutdown command in xendomains script to be compatible with both xm and xl"):
>   * Use short options for shutdown command in xendomains script to be compatible with both xm and xl
>   * Drop using the --halt: Linux in a guest treats "halt" and "poweroff" identically, so the --halt is pointless and not implemented in xl

I think we should fix xl to support the long options too.

xl is supposed to be a command-line compatible replacement.

Both this and your support for shutting down all domains are IMO 4.2.1
material.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 13 16:07:32 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Sep 2012 16: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 1TCBwh-0008M7-80; Thu, 13 Sep 2012 16:07: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 1TCBwg-0008Lv-5S
	for xen-devel@lists.xensource.com; Thu, 13 Sep 2012 16:07:14 +0000
Received: from [85.158.143.35:12273] by server-2.bemta-4.messagelabs.com id
	F0/C8-21239-1B402505; Thu, 13 Sep 2012 16:07:13 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1347552432!10433775!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDkwMjg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15656 invoked from network); 13 Sep 2012 16:07:13 -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;
	13 Sep 2012 16:07:13 -0000
X-IronPort-AV: E=Sophos;i="4.80,417,1344211200"; d="scan'208";a="14526484"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Sep 2012 16:07:12 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Thu, 13 Sep 2012 17:07: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
	1TCBwe-0007c1-Fl; Thu, 13 Sep 2012 16:07:12 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1TCBwe-0005wW-B9;
	Thu, 13 Sep 2012 17:07:12 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20562.1196.424904.928439@mariner.uk.xensource.com>
Date: Thu, 13 Sep 2012 17:07:08 +0100
To: Sander Eikelenboom <linux@eikelenboom.it>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <261ce3cdaee8d5c30f12.1346960489@xentest.example.org>
References: <patchbomb.1346960486@xentest.example.org>
	<261ce3cdaee8d5c30f12.1346960489@xentest.example.org>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com, Ian.Campbell@citrix.com
Subject: Re: [Xen-devel] [PATCH 3 of 3] hotplug: Change options used for
 shutdown command in xendomains script to be compatible with both xm and 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

Sander Eikelenboom writes ("[Xen-devel] [PATCH 3 of 3] hotplug: Change options used for shutdown command in xendomains script to be compatible with both xm and xl"):
>   * Use short options for shutdown command in xendomains script to be compatible with both xm and xl
>   * Drop using the --halt: Linux in a guest treats "halt" and "poweroff" identically, so the --halt is pointless and not implemented in xl

I think we should fix xl to support the long options too.

xl is supposed to be a command-line compatible replacement.

Both this and your support for shutting down all domains are IMO 4.2.1
material.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 13 16:16:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Sep 2012 16: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 1TCC56-0000I1-7f; Thu, 13 Sep 2012 16:15: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 1TCC54-0000Hw-Vm
	for xen-devel@lists.xen.org; Thu, 13 Sep 2012 16:15:55 +0000
Received: from [85.158.143.35:14704] by server-2.bemta-4.messagelabs.com id
	04/92-21239-AB602505; Thu, 13 Sep 2012 16:15:54 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1347552953!14522382!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDkwMjg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8973 invoked from network); 13 Sep 2012 16:15:53 -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 Sep 2012 16:15:53 -0000
X-IronPort-AV: E=Sophos;i="4.80,417,1344211200"; d="scan'208";a="14526729"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Sep 2012 16:15:53 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Thu, 13 Sep 2012 17:15:53 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1TCC52-0007jQ-Qs; Thu, 13 Sep 2012 16:15:52 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1TCC52-0005wt-ND;
	Thu, 13 Sep 2012 17:15:52 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20562.1720.617032.513944@mariner.uk.xensource.com>
Date: Thu, 13 Sep 2012 17:15:52 +0100
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <alpine.DEB.2.02.1209121123480.15568@kaball.uk.xensource.com>
References: <CAFw--Dd0k7L+T_UJc0yHAkUGrY_-GDHaQjK3OM-1UdOp=J-wAQ@mail.gmail.com>
	<20120907085036.GA71093@ocelot.phlegethon.org>
	<CAFw--DdYkAo79TeZKDFZ5ZdaN4KiLmW2qcceY+cTxuLMdE3QGA@mail.gmail.com>
	<CAFw--Dche2NB0jjBdMyAYC=S92XkW9UpsaBsTRBcX4ZP_oOcxA@mail.gmail.com>
	<alpine.DEB.2.02.1209121123480.15568@kaball.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "Tim \(Xen.org\)" <tim@xen.org>, Jeffrey Karrels <karrelsj@gmail.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Clang/LLVM version requirements
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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] Clang/LLVM version requirements"):
> On Tue, 11 Sep 2012, Jeffrey Karrels wrote:
> > [builder@xenbuild1 xen-unstable]$ /usr/local/bin/clang -v
> > clang version 3.2 (trunk 163631)
> > Target: x86_64-unknown-linux-gnu
> > Thread model: posix
> > 
> > After that I applied the patch that Tim previously posted and tried
> > another make. The xen build succeeded.
> 
> time to add a clang build target to the test system?

This should be fairly straightforward.

What do I need to do on an amd64 Debian squeeze system to build with
clang ?

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 13 16:16:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Sep 2012 16: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 1TCC56-0000I1-7f; Thu, 13 Sep 2012 16:15: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 1TCC54-0000Hw-Vm
	for xen-devel@lists.xen.org; Thu, 13 Sep 2012 16:15:55 +0000
Received: from [85.158.143.35:14704] by server-2.bemta-4.messagelabs.com id
	04/92-21239-AB602505; Thu, 13 Sep 2012 16:15:54 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1347552953!14522382!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDkwMjg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8973 invoked from network); 13 Sep 2012 16:15:53 -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 Sep 2012 16:15:53 -0000
X-IronPort-AV: E=Sophos;i="4.80,417,1344211200"; d="scan'208";a="14526729"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Sep 2012 16:15:53 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Thu, 13 Sep 2012 17:15:53 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1TCC52-0007jQ-Qs; Thu, 13 Sep 2012 16:15:52 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1TCC52-0005wt-ND;
	Thu, 13 Sep 2012 17:15:52 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20562.1720.617032.513944@mariner.uk.xensource.com>
Date: Thu, 13 Sep 2012 17:15:52 +0100
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <alpine.DEB.2.02.1209121123480.15568@kaball.uk.xensource.com>
References: <CAFw--Dd0k7L+T_UJc0yHAkUGrY_-GDHaQjK3OM-1UdOp=J-wAQ@mail.gmail.com>
	<20120907085036.GA71093@ocelot.phlegethon.org>
	<CAFw--DdYkAo79TeZKDFZ5ZdaN4KiLmW2qcceY+cTxuLMdE3QGA@mail.gmail.com>
	<CAFw--Dche2NB0jjBdMyAYC=S92XkW9UpsaBsTRBcX4ZP_oOcxA@mail.gmail.com>
	<alpine.DEB.2.02.1209121123480.15568@kaball.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "Tim \(Xen.org\)" <tim@xen.org>, Jeffrey Karrels <karrelsj@gmail.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Clang/LLVM version requirements
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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] Clang/LLVM version requirements"):
> On Tue, 11 Sep 2012, Jeffrey Karrels wrote:
> > [builder@xenbuild1 xen-unstable]$ /usr/local/bin/clang -v
> > clang version 3.2 (trunk 163631)
> > Target: x86_64-unknown-linux-gnu
> > Thread model: posix
> > 
> > After that I applied the patch that Tim previously posted and tried
> > another make. The xen build succeeded.
> 
> time to add a clang build target to the test system?

This should be fairly straightforward.

What do I need to do on an amd64 Debian squeeze system to build with
clang ?

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 13 16:26:21 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Sep 2012 16:26:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TCCEw-0000SW-CB; Thu, 13 Sep 2012 16:26:06 +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 1TCCEu-0000SR-Rq
	for xen-devel@lists.xen.org; Thu, 13 Sep 2012 16:26:05 +0000
Received: from [85.158.139.83:25117] by server-4.bemta-5.messagelabs.com id
	29/DC-23042-C1902505; Thu, 13 Sep 2012 16:26:04 +0000
X-Env-Sender: msw@amazon.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1347553562!25837030!1
X-Originating-IP: [72.21.198.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNzIuMjEuMTk4LjI1ID0+IDE3NTc2Mg==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20644 invoked from network); 13 Sep 2012 16:26:03 -0000
Received: from smtp-fw-4101.amazon.com (HELO smtp-fw-4101.amazon.com)
	(72.21.198.25)
	by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Sep 2012 16:26:03 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=amazon.com; i=msw@amazon.com; q=dns/txt; s=rte02;
	t=1347553563; x=1379089563;
	h=date:from:to:cc:subject:message-id:references:
	mime-version:in-reply-to;
	bh=cbrJYQiYIhL4HWPcQ+IxFtliIVQTVzMGTiRWqoEjFzE=;
	b=Re4MRTNwolRYYU1dCPkrCFN2tusY50RPRH5/egRdyqcX+w64mZaDFECc
	RwAw9Yn3aYicZm1NUH1UfmQo0Glqbw==;
X-IronPort-AV: E=Sophos;i="4.80,417,1344211200"; d="scan'208";a="795876138"
Received: from smtp-in-0105.sea3.amazon.com ([10.224.19.45])
	by smtp-border-fw-out-4101.iad4.amazon.com with
	ESMTP/TLS/DHE-RSA-AES256-SHA; 13 Sep 2012 16:26:00 +0000
Received: from ex10-hub-9001.ant.amazon.com (ex10-hub-9001.ant.amazon.com
	[10.185.137.58])
	by smtp-in-0105.sea3.amazon.com (8.13.8/8.13.8) with ESMTP id
	q8DGPxB7012791
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL);
	Thu, 13 Sep 2012 16:25:59 GMT
Received: from u002268147cd4502c336d.ant.amazon.com (10.224.80.34) by
	ex10-hub-9001.ant.amazon.com (10.185.137.58) with Microsoft SMTP Server
	id 14.2.247.3; Thu, 13 Sep 2012 09:25:52 -0700
Received: by u002268147cd4502c336d.ant.amazon.com (sSMTP sendmail emulation); 
	Thu, 13 Sep 2012 09:25:52 -0700
Date: Thu, 13 Sep 2012 09:25:52 -0700
From: Matt Wilson <msw@amazon.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Message-ID: <20120913092503.GA15042@u002268147cd4502c336d.ant.amazon.com>
References: <CC77835D.3EA28%keir.xen@gmail.com>
	<20561.62312.319383.462890@mariner.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20561.62312.319383.462890@mariner.uk.xensource.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: Keir Fraser <keir.xen@gmail.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [ANNOUNCE] Final release candidate for Xen 4.2.0
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Sep 13, 2012 at 03:53:28PM +0100, Ian Jackson wrote:
> > We plan to call the 4.2.0 release on Monday, with no further modifications.
> > So please test this "GA preview"!
> 
> As Keir says.  If all goes well the 4.2.0 release will have a
> functionally identical tarball.

Any chance my man page fixes will make it in to the final tarball?
"Functionally identical" seems to leave some wiggle room.

xmdomain.cfg.5 has POD errors (displayed when you run "man xmdomain.cfg":
POD ERRORS
       Hey! The above document had some coding errors, which are
       explained
       below:

       Around line 301:
           You can't have =items (as at line 305) unless the first
	   thing after
           the =over is an =item

       Around line 311:
           '=item' outside of any '=over'

xl.cfg.5 has POD errors:
POD ERRORS
       Hey! The above document had some coding errors, which are
       explained
       below:

       Around line 405:
           '=item' outside of any '=over'

       Around line 429:
           You forgot a '=back' before '=head2'

       Around line 687:
           '=item' outside of any '=over'

       Around line 695:
           You forgot a '=back' before '=head3'

Matt

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 13 16:26:21 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Sep 2012 16:26:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TCCEw-0000SW-CB; Thu, 13 Sep 2012 16:26:06 +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 1TCCEu-0000SR-Rq
	for xen-devel@lists.xen.org; Thu, 13 Sep 2012 16:26:05 +0000
Received: from [85.158.139.83:25117] by server-4.bemta-5.messagelabs.com id
	29/DC-23042-C1902505; Thu, 13 Sep 2012 16:26:04 +0000
X-Env-Sender: msw@amazon.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1347553562!25837030!1
X-Originating-IP: [72.21.198.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNzIuMjEuMTk4LjI1ID0+IDE3NTc2Mg==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20644 invoked from network); 13 Sep 2012 16:26:03 -0000
Received: from smtp-fw-4101.amazon.com (HELO smtp-fw-4101.amazon.com)
	(72.21.198.25)
	by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Sep 2012 16:26:03 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=amazon.com; i=msw@amazon.com; q=dns/txt; s=rte02;
	t=1347553563; x=1379089563;
	h=date:from:to:cc:subject:message-id:references:
	mime-version:in-reply-to;
	bh=cbrJYQiYIhL4HWPcQ+IxFtliIVQTVzMGTiRWqoEjFzE=;
	b=Re4MRTNwolRYYU1dCPkrCFN2tusY50RPRH5/egRdyqcX+w64mZaDFECc
	RwAw9Yn3aYicZm1NUH1UfmQo0Glqbw==;
X-IronPort-AV: E=Sophos;i="4.80,417,1344211200"; d="scan'208";a="795876138"
Received: from smtp-in-0105.sea3.amazon.com ([10.224.19.45])
	by smtp-border-fw-out-4101.iad4.amazon.com with
	ESMTP/TLS/DHE-RSA-AES256-SHA; 13 Sep 2012 16:26:00 +0000
Received: from ex10-hub-9001.ant.amazon.com (ex10-hub-9001.ant.amazon.com
	[10.185.137.58])
	by smtp-in-0105.sea3.amazon.com (8.13.8/8.13.8) with ESMTP id
	q8DGPxB7012791
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL);
	Thu, 13 Sep 2012 16:25:59 GMT
Received: from u002268147cd4502c336d.ant.amazon.com (10.224.80.34) by
	ex10-hub-9001.ant.amazon.com (10.185.137.58) with Microsoft SMTP Server
	id 14.2.247.3; Thu, 13 Sep 2012 09:25:52 -0700
Received: by u002268147cd4502c336d.ant.amazon.com (sSMTP sendmail emulation); 
	Thu, 13 Sep 2012 09:25:52 -0700
Date: Thu, 13 Sep 2012 09:25:52 -0700
From: Matt Wilson <msw@amazon.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Message-ID: <20120913092503.GA15042@u002268147cd4502c336d.ant.amazon.com>
References: <CC77835D.3EA28%keir.xen@gmail.com>
	<20561.62312.319383.462890@mariner.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20561.62312.319383.462890@mariner.uk.xensource.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: Keir Fraser <keir.xen@gmail.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [ANNOUNCE] Final release candidate for Xen 4.2.0
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Sep 13, 2012 at 03:53:28PM +0100, Ian Jackson wrote:
> > We plan to call the 4.2.0 release on Monday, with no further modifications.
> > So please test this "GA preview"!
> 
> As Keir says.  If all goes well the 4.2.0 release will have a
> functionally identical tarball.

Any chance my man page fixes will make it in to the final tarball?
"Functionally identical" seems to leave some wiggle room.

xmdomain.cfg.5 has POD errors (displayed when you run "man xmdomain.cfg":
POD ERRORS
       Hey! The above document had some coding errors, which are
       explained
       below:

       Around line 301:
           You can't have =items (as at line 305) unless the first
	   thing after
           the =over is an =item

       Around line 311:
           '=item' outside of any '=over'

xl.cfg.5 has POD errors:
POD ERRORS
       Hey! The above document had some coding errors, which are
       explained
       below:

       Around line 405:
           '=item' outside of any '=over'

       Around line 429:
           You forgot a '=back' before '=head2'

       Around line 687:
           '=item' outside of any '=over'

       Around line 695:
           You forgot a '=back' before '=head3'

Matt

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 13 16:34:00 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Sep 2012 16: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 1TCCLy-0000dB-8o; Thu, 13 Sep 2012 16:33:22 +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 1TCCLw-0000d6-RI
	for Xen-devel@lists.xensource.com; Thu, 13 Sep 2012 16:33:21 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1347553994!3914459!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDkwMjg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27373 invoked from network); 13 Sep 2012 16:33:15 -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;
	13 Sep 2012 16:33:15 -0000
X-IronPort-AV: E=Sophos;i="4.80,417,1344211200"; d="scan'208";a="14527135"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Sep 2012 16: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.279.1;
	Thu, 13 Sep 2012 17:33:15 +0100
Message-ID: <1347553993.24226.137.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Mukesh Rathor <mukesh.rathor@oracle.com>
Date: Thu, 13 Sep 2012 17:33:13 +0100
In-Reply-To: <20120815180541.2fddead9@mantra.us.oracle.com>
References: <20120815180541.2fddead9@mantra.us.oracle.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [RFC PATCH 6/8]: Ballooning changes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-08-16 at 02:05 +0100, Mukesh Rathor wrote:
> ---
>  drivers/xen/balloon.c |   26 +++++++++++++++++++++-----
>  1 files changed, 21 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/xen/balloon.c b/drivers/xen/balloon.c
> index 31ab82f..57960a1 100644
> --- a/drivers/xen/balloon.c
> +++ b/drivers/xen/balloon.c
> @@ -358,10 +358,18 @@ static enum bp_state increase_reservation(unsigned long nr_pages)
>  		BUG_ON(!xen_feature(XENFEAT_auto_translated_physmap) &&
>  		       phys_to_machine_mapping_valid(pfn));
>  
> -		set_phys_to_machine(pfn, frame_list[i]);
> -
> +		if (!xen_pvh_domain()) {
> +			set_phys_to_machine(pfn, frame_list[i]);
> +		} else {
> +			pte_t *ptep;
> +			unsigned int level;
> +			void *addr = __va(pfn << PAGE_SHIFT);
> +			ptep = lookup_address((unsigned long)addr, &level);
> +			set_pte(ptep, pfn_pte(pfn, PAGE_KERNEL));

Another thing I just tripped over on ARM which might be pertinent on x86
PVH too is that lowmem mappings on ARM are super 2M mappings, so trying
to clear the PTE here fails.

I was a bit wary of leaving stage 1 mappings in place for pfn's with no
backing mfn but this 2M mapping issue has caused me to revise that
opinion -- there's no need to worry about the stage 1 mapping still
being present as long as you guarantee you never touch the associated
virtual address, which the balloon driver should be able to do. The
other option is to shatter such mappings which is just too much pain to
contemplate.

Long story short I reckon you can drop this hunk (and associated similar
changes) and rely on the XENFEAT_auto_translated_physmap check inside
set_phys_to_machine to do the right thing.

I guess PVH currently suppresses superpage mappings on x86 (probably
inherited from PV) but undoing that might be something to investigate
for the future? It'll help perf I expect.

Ian.

> +		}
>  		/* Link back into the page tables if not highmem. */
> -		if (xen_pv_domain() && !PageHighMem(page)) {
> +		if (xen_pv_domain() && !PageHighMem(page) &&
> +		    !xen_pvh_domain()) {
>  			int ret;
>  			ret = HYPERVISOR_update_va_mapping(
>  				(unsigned long)__va(pfn << PAGE_SHIFT),
> @@ -417,7 +425,14 @@ static enum bp_state decrease_reservation(unsigned long nr_pages, gfp_t gfp)
>  
>  		scrub_page(page);
>  
> -		if (xen_pv_domain() && !PageHighMem(page)) {
> +		if (xen_pvh_domain() && !PageHighMem(page)) {
> +			unsigned int level;
> +			pte_t *ptep;
> +			void *addr = __va(pfn << PAGE_SHIFT);
> +			ptep = lookup_address((unsigned long)addr, &level);
> +			set_pte(ptep, __pte(0));
> +
> +		} else if (xen_pv_domain() && !PageHighMem(page)) {
>  			ret = HYPERVISOR_update_va_mapping(
>  				(unsigned long)__va(pfn << PAGE_SHIFT),
>  				__pte_ma(0), 0);
> @@ -433,7 +448,8 @@ static enum bp_state decrease_reservation(unsigned long nr_pages, gfp_t gfp)
>  	/* No more mappings: invalidate P2M and add to balloon. */
>  	for (i = 0; i < nr_pages; i++) {
>  		pfn = mfn_to_pfn(frame_list[i]);
> -		__set_phys_to_machine(pfn, INVALID_P2M_ENTRY);
> +		if (!xen_pvh_domain())
> +			__set_phys_to_machine(pfn, INVALID_P2M_ENTRY);
>  		balloon_append(pfn_to_page(pfn));
>  	}
>  



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 13 16:34:00 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Sep 2012 16: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 1TCCLy-0000dB-8o; Thu, 13 Sep 2012 16:33:22 +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 1TCCLw-0000d6-RI
	for Xen-devel@lists.xensource.com; Thu, 13 Sep 2012 16:33:21 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1347553994!3914459!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDkwMjg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27373 invoked from network); 13 Sep 2012 16:33:15 -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;
	13 Sep 2012 16:33:15 -0000
X-IronPort-AV: E=Sophos;i="4.80,417,1344211200"; d="scan'208";a="14527135"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Sep 2012 16: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.279.1;
	Thu, 13 Sep 2012 17:33:15 +0100
Message-ID: <1347553993.24226.137.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Mukesh Rathor <mukesh.rathor@oracle.com>
Date: Thu, 13 Sep 2012 17:33:13 +0100
In-Reply-To: <20120815180541.2fddead9@mantra.us.oracle.com>
References: <20120815180541.2fddead9@mantra.us.oracle.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [RFC PATCH 6/8]: Ballooning changes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-08-16 at 02:05 +0100, Mukesh Rathor wrote:
> ---
>  drivers/xen/balloon.c |   26 +++++++++++++++++++++-----
>  1 files changed, 21 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/xen/balloon.c b/drivers/xen/balloon.c
> index 31ab82f..57960a1 100644
> --- a/drivers/xen/balloon.c
> +++ b/drivers/xen/balloon.c
> @@ -358,10 +358,18 @@ static enum bp_state increase_reservation(unsigned long nr_pages)
>  		BUG_ON(!xen_feature(XENFEAT_auto_translated_physmap) &&
>  		       phys_to_machine_mapping_valid(pfn));
>  
> -		set_phys_to_machine(pfn, frame_list[i]);
> -
> +		if (!xen_pvh_domain()) {
> +			set_phys_to_machine(pfn, frame_list[i]);
> +		} else {
> +			pte_t *ptep;
> +			unsigned int level;
> +			void *addr = __va(pfn << PAGE_SHIFT);
> +			ptep = lookup_address((unsigned long)addr, &level);
> +			set_pte(ptep, pfn_pte(pfn, PAGE_KERNEL));

Another thing I just tripped over on ARM which might be pertinent on x86
PVH too is that lowmem mappings on ARM are super 2M mappings, so trying
to clear the PTE here fails.

I was a bit wary of leaving stage 1 mappings in place for pfn's with no
backing mfn but this 2M mapping issue has caused me to revise that
opinion -- there's no need to worry about the stage 1 mapping still
being present as long as you guarantee you never touch the associated
virtual address, which the balloon driver should be able to do. The
other option is to shatter such mappings which is just too much pain to
contemplate.

Long story short I reckon you can drop this hunk (and associated similar
changes) and rely on the XENFEAT_auto_translated_physmap check inside
set_phys_to_machine to do the right thing.

I guess PVH currently suppresses superpage mappings on x86 (probably
inherited from PV) but undoing that might be something to investigate
for the future? It'll help perf I expect.

Ian.

> +		}
>  		/* Link back into the page tables if not highmem. */
> -		if (xen_pv_domain() && !PageHighMem(page)) {
> +		if (xen_pv_domain() && !PageHighMem(page) &&
> +		    !xen_pvh_domain()) {
>  			int ret;
>  			ret = HYPERVISOR_update_va_mapping(
>  				(unsigned long)__va(pfn << PAGE_SHIFT),
> @@ -417,7 +425,14 @@ static enum bp_state decrease_reservation(unsigned long nr_pages, gfp_t gfp)
>  
>  		scrub_page(page);
>  
> -		if (xen_pv_domain() && !PageHighMem(page)) {
> +		if (xen_pvh_domain() && !PageHighMem(page)) {
> +			unsigned int level;
> +			pte_t *ptep;
> +			void *addr = __va(pfn << PAGE_SHIFT);
> +			ptep = lookup_address((unsigned long)addr, &level);
> +			set_pte(ptep, __pte(0));
> +
> +		} else if (xen_pv_domain() && !PageHighMem(page)) {
>  			ret = HYPERVISOR_update_va_mapping(
>  				(unsigned long)__va(pfn << PAGE_SHIFT),
>  				__pte_ma(0), 0);
> @@ -433,7 +448,8 @@ static enum bp_state decrease_reservation(unsigned long nr_pages, gfp_t gfp)
>  	/* No more mappings: invalidate P2M and add to balloon. */
>  	for (i = 0; i < nr_pages; i++) {
>  		pfn = mfn_to_pfn(frame_list[i]);
> -		__set_phys_to_machine(pfn, INVALID_P2M_ENTRY);
> +		if (!xen_pvh_domain())
> +			__set_phys_to_machine(pfn, INVALID_P2M_ENTRY);
>  		balloon_append(pfn_to_page(pfn));
>  	}
>  



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 13 16:41:23 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Sep 2012 16:41:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TCCTS-0000po-CV; Thu, 13 Sep 2012 16:41:06 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1TCCTQ-0000pj-Jr
	for xen-devel@lists.xen.org; Thu, 13 Sep 2012 16:41:04 +0000
Received: from [85.158.143.99:32418] by server-2.bemta-4.messagelabs.com id
	94/AC-21239-0AC02505; Thu, 13 Sep 2012 16:41:04 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-11.tower-216.messagelabs.com!1347554463!22701148!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31713 invoked from network); 13 Sep 2012 16:41:03 -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; 13 Sep 2012 16:41:03 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1TCCTM-0004kI-Bo; Thu, 13 Sep 2012 16:41:00 +0000
Date: Thu, 13 Sep 2012 17:41:00 +0100
From: Tim Deegan <tim@xen.org>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Message-ID: <20120913164100.GF12881@ocelot.phlegethon.org>
References: <CAFw--Dd0k7L+T_UJc0yHAkUGrY_-GDHaQjK3OM-1UdOp=J-wAQ@mail.gmail.com>
	<20120907085036.GA71093@ocelot.phlegethon.org>
	<CAFw--DdYkAo79TeZKDFZ5ZdaN4KiLmW2qcceY+cTxuLMdE3QGA@mail.gmail.com>
	<CAFw--Dche2NB0jjBdMyAYC=S92XkW9UpsaBsTRBcX4ZP_oOcxA@mail.gmail.com>
	<alpine.DEB.2.02.1209121123480.15568@kaball.uk.xensource.com>
	<20562.1720.617032.513944@mariner.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20562.1720.617032.513944@mariner.uk.xensource.com>
User-Agent: Mutt/1.4.2.1i
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Jeffrey Karrels <karrelsj@gmail.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Clang/LLVM version requirements
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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:15 +0100 on 13 Sep (1347556552), Ian Jackson wrote:
> Stefano Stabellini writes ("Re: [Xen-devel] Clang/LLVM version requirements"):
> > On Tue, 11 Sep 2012, Jeffrey Karrels wrote:
> > > [builder@xenbuild1 xen-unstable]$ /usr/local/bin/clang -v
> > > clang version 3.2 (trunk 163631)
> > > Target: x86_64-unknown-linux-gnu
> > > Thread model: posix
> > > 
> > > After that I applied the patch that Tim previously posted and tried
> > > another make. The xen build succeeded.
> > 
> > time to add a clang build target to the test system?
> 
> This should be fairly straightforward.
> 
> What do I need to do on an amd64 Debian squeeze system to build with
> clang ?

You need clang 3.0-6, which is in wheezy but not squeeze.  Then just
"make dist-xen clang=y".

The tools don't build with clang, only Xen.
I presume that if we want to build the tools with clang in future it
would be done with autofoo rather than clang=y.

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 Sep 13 16:41:23 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Sep 2012 16:41:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TCCTS-0000po-CV; Thu, 13 Sep 2012 16:41:06 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1TCCTQ-0000pj-Jr
	for xen-devel@lists.xen.org; Thu, 13 Sep 2012 16:41:04 +0000
Received: from [85.158.143.99:32418] by server-2.bemta-4.messagelabs.com id
	94/AC-21239-0AC02505; Thu, 13 Sep 2012 16:41:04 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-11.tower-216.messagelabs.com!1347554463!22701148!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31713 invoked from network); 13 Sep 2012 16:41:03 -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; 13 Sep 2012 16:41:03 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1TCCTM-0004kI-Bo; Thu, 13 Sep 2012 16:41:00 +0000
Date: Thu, 13 Sep 2012 17:41:00 +0100
From: Tim Deegan <tim@xen.org>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Message-ID: <20120913164100.GF12881@ocelot.phlegethon.org>
References: <CAFw--Dd0k7L+T_UJc0yHAkUGrY_-GDHaQjK3OM-1UdOp=J-wAQ@mail.gmail.com>
	<20120907085036.GA71093@ocelot.phlegethon.org>
	<CAFw--DdYkAo79TeZKDFZ5ZdaN4KiLmW2qcceY+cTxuLMdE3QGA@mail.gmail.com>
	<CAFw--Dche2NB0jjBdMyAYC=S92XkW9UpsaBsTRBcX4ZP_oOcxA@mail.gmail.com>
	<alpine.DEB.2.02.1209121123480.15568@kaball.uk.xensource.com>
	<20562.1720.617032.513944@mariner.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20562.1720.617032.513944@mariner.uk.xensource.com>
User-Agent: Mutt/1.4.2.1i
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Jeffrey Karrels <karrelsj@gmail.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Clang/LLVM version requirements
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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:15 +0100 on 13 Sep (1347556552), Ian Jackson wrote:
> Stefano Stabellini writes ("Re: [Xen-devel] Clang/LLVM version requirements"):
> > On Tue, 11 Sep 2012, Jeffrey Karrels wrote:
> > > [builder@xenbuild1 xen-unstable]$ /usr/local/bin/clang -v
> > > clang version 3.2 (trunk 163631)
> > > Target: x86_64-unknown-linux-gnu
> > > Thread model: posix
> > > 
> > > After that I applied the patch that Tim previously posted and tried
> > > another make. The xen build succeeded.
> > 
> > time to add a clang build target to the test system?
> 
> This should be fairly straightforward.
> 
> What do I need to do on an amd64 Debian squeeze system to build with
> clang ?

You need clang 3.0-6, which is in wheezy but not squeeze.  Then just
"make dist-xen clang=y".

The tools don't build with clang, only Xen.
I presume that if we want to build the tools with clang in future it
would be done with autofoo rather than clang=y.

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 Sep 13 16:47:31 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Sep 2012 16: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 1TCCZM-0000yA-62; Thu, 13 Sep 2012 16:47: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 1TCCZL-0000y5-4i
	for xen-devel@lists.xen.org; Thu, 13 Sep 2012 16:47:11 +0000
Received: from [85.158.143.35:4056] by server-2.bemta-4.messagelabs.com id
	E2/42-21239-E0E02505; Thu, 13 Sep 2012 16:47:10 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-8.tower-21.messagelabs.com!1347554828!14890431!1
X-Originating-IP: [63.239.67.9]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21802 invoked from network); 13 Sep 2012 16:47:09 -0000
Received: from emvm-gh1-uea08.nsa.gov (HELO nsa.gov) (63.239.67.9)
	by server-8.tower-21.messagelabs.com with SMTP;
	13 Sep 2012 16:47:09 -0000
X-TM-IMSS-Message-ID: <3f32c4b400110d1c@nsa.gov>
Received: from tarius.tycho.ncsc.mil ([144.51.3.1]) by nsa.gov ([63.239.67.9])
	with ESMTP (TREND IMSS SMTP Service 7.1) id 3f32c4b400110d1c ;
	Thu, 13 Sep 2012 12:46:45 -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 q8DGktuQ014386; 
	Thu, 13 Sep 2012 12:46:55 -0400
Message-ID: <50520DFF.4030505@tycho.nsa.gov>
Date: Thu, 13 Sep 2012 12:46:55 -0400
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Organization: National Security Agency
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120828 Thunderbird/15.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <1347465586-20009-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1347465586-20009-20-git-send-email-dgdegra@tycho.nsa.gov>
	<5051AED7020000780009AFC3@nat28.tlf.novell.com>
	<5051E3AC.2060700@tycho.nsa.gov>
	<50520634020000780009B162@nat28.tlf.novell.com>
	<5051ECC7.7050901@tycho.nsa.gov>
	<5052121F020000780009B1E9@nat28.tlf.novell.com>
In-Reply-To: <5052121F020000780009B1E9@nat28.tlf.novell.com>
Cc: Tim Deegan <tim@xen.org>, Keir Fraser <keir@xen.org>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 19/22] arch/x86: check remote MMIO remap
	permissions
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 09/13/2012 11:04 AM, Jan Beulich wrote:
>>>> On 13.09.12 at 16:25, Daniel De Graaf <dgdegra@tycho.nsa.gov> wrote:
>> On 09/13/2012 10:13 AM, Jan Beulich wrote:
>>>>>> On 13.09.12 at 15:46, Daniel De Graaf <dgdegra@tycho.nsa.gov> wrote:
>>>> On 09/13/2012 04:00 AM, Jan Beulich wrote:
>>>>>>>> On 12.09.12 at 17:59, Daniel De Graaf <dgdegra@tycho.nsa.gov> wrote:
>>>>>> When a domain is mapping pages from a different pg_owner domain, the
>>>>>> iomem_access checks are currently only applied to the pg_owner domain,
>>>>>> potentially allowing the current domain to bypass its more restrictive
>>>>>> iomem_access policy using another domain that it has access to.
>>>>>
>>>>> Are you sure about this? I ask because ...
>>>>>
>>>>>> --- a/xen/arch/x86/mm.c
>>>>>> +++ b/xen/arch/x86/mm.c
>>>>>> @@ -754,6 +754,18 @@ get_page_from_l1e(
>>>>>>              return -EINVAL;
>>>>>>          }
>>>>>>  
>>>>>> +        if ( pg_owner != curr->domain &&
>>>>>> +             !iomem_access_permitted(curr->domain, mfn, mfn) )
>>>>>> +        {
>>>>>> +            if ( mfn != (PADDR_MASK >> PAGE_SHIFT) ) /* INVALID_MFN? */
>>>>>> +            {
>>>>>> +                MEM_LOG("Domain %u attempted to map I/O space %08lx in 
>>>> domain %u",
>>>>>> +                        curr->domain->domain_id, mfn, pg_owner->domain_id);
>>>>>> +                return -EPERM;
>>>>>> +            }
>>>>>> +            return -EINVAL;
>>>>>> +        }
>>>>>> +
>>>>>
>>>>> ... the place you insert this is after non-RAM pages got filtered
>>>>> out already, so you're applying an IOMEM permission check to a
>>>>> RAM page.
>>>>>
>>>>> Jan
>>>>>
>>>>>>          if ( !(l1f & _PAGE_RW) ||
>>>>>>               !rangeset_contains_singleton(mmio_ro_ranges, mfn) )
>>>>>>              return 0;
>>>>
>>>> If that's true, then the check a few lines above is also applying IOMEM
>>>> checks to RAM pages. I can see non-privileged attempts being filtered
>>>> above,
>>
>> "above" refers to "if ( !iomem_access_permitted(pg_owner, mfn, mfn) )"
>>  
>>> I can't see how that would happen given this primary conditional
>>>
>>>     if ( !mfn_valid(mfn) ||
>>>          (real_pg_owner = page_get_owner_and_reference(page)) == dom_io )
>>>
>>> Please clarify what you're observing.
>>
>> As I understand it, the contents of this block will be executed if the MFN 
>> is
>> invalid (interpreted as MMIO space) or if the page's owner is DOMID_IO, 
>> which
>> is how MMIO space is marked.
>>
>>>> but successful mappings will continue to the check I added.
>>>
>>> Of course. I would think that if anything, you would want to add
>>> a second call to iomem_access_permitted() with "curr->domain"
>>> right at the place where the current one is (in particular inside
>>> the above quoted conditional).
>>>
>>> Jan
>>
>> I was emulating the existing iomem_access_permitted check being run on 
>> pg_owner;
>> moving the curr->domain check up into this first conditional would end up
>> treating the MMIO mapping as a regular RAM mapping if the 
>> iomem_access_permitted
>> fails. Unless you're talking about a different quoted conditional?
> 
> I'm sorry, each of your replies get me more confused. Can you,
> with the current code (i.e. without your patches or any emulation
> you might be doing) explain (perhaps with an example) what
> specific case you see needing more checking than there is
> currently? That would probably allow us to start talking about the
> same thing.
> 
> Jan
> 

For this example, assume domain A has access to map domain B's memory
read-only. Domain B has access to a device with MMIO where reads to the
device's memory cause state changes - an example of such as device is a
TPM, where replies are read by repeated reads to a single 4-byte 
address. Domain A does not have access to this device, and would like to
maliciously interfere with the device.

If domain A maps the MMIO page from domain B using pg_owner == domB, the
iomem_access_permitted check will be done from domain B's perspective. 
While this is needed when domain A is mapping pages on behalf of domB, 
it is not sufficient when attempting to constrain domain A's access. 

These checks only apply to MMIO, so the condition on line 735 will
evaluate to true (!mfn_valid || real_pg_owner == dom_io).

The (existing) check on domain B's MMIO access is:
        if ( !iomem_access_permitted(pg_owner, mfn, mfn) )

This patch adds a check on domain A:
        if ( !iomem_access_permitted(curr->domain, mfn, mfn) )
            
This extra checking has not been required without XSM because only FLASK
implements the ability to grant one domain read-only access to another 
domain. With read-write access, this extra access check is simple to get
around: domain A can modify some part of the executable code in domain B
to act as a proxy for its accesses. Additionally, domain A is usually
dom0 or the device model, which have equal or greater MMIO access.

-- 
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 Sep 13 16:47:31 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Sep 2012 16: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 1TCCZM-0000yA-62; Thu, 13 Sep 2012 16:47: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 1TCCZL-0000y5-4i
	for xen-devel@lists.xen.org; Thu, 13 Sep 2012 16:47:11 +0000
Received: from [85.158.143.35:4056] by server-2.bemta-4.messagelabs.com id
	E2/42-21239-E0E02505; Thu, 13 Sep 2012 16:47:10 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-8.tower-21.messagelabs.com!1347554828!14890431!1
X-Originating-IP: [63.239.67.9]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21802 invoked from network); 13 Sep 2012 16:47:09 -0000
Received: from emvm-gh1-uea08.nsa.gov (HELO nsa.gov) (63.239.67.9)
	by server-8.tower-21.messagelabs.com with SMTP;
	13 Sep 2012 16:47:09 -0000
X-TM-IMSS-Message-ID: <3f32c4b400110d1c@nsa.gov>
Received: from tarius.tycho.ncsc.mil ([144.51.3.1]) by nsa.gov ([63.239.67.9])
	with ESMTP (TREND IMSS SMTP Service 7.1) id 3f32c4b400110d1c ;
	Thu, 13 Sep 2012 12:46:45 -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 q8DGktuQ014386; 
	Thu, 13 Sep 2012 12:46:55 -0400
Message-ID: <50520DFF.4030505@tycho.nsa.gov>
Date: Thu, 13 Sep 2012 12:46:55 -0400
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Organization: National Security Agency
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120828 Thunderbird/15.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <1347465586-20009-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1347465586-20009-20-git-send-email-dgdegra@tycho.nsa.gov>
	<5051AED7020000780009AFC3@nat28.tlf.novell.com>
	<5051E3AC.2060700@tycho.nsa.gov>
	<50520634020000780009B162@nat28.tlf.novell.com>
	<5051ECC7.7050901@tycho.nsa.gov>
	<5052121F020000780009B1E9@nat28.tlf.novell.com>
In-Reply-To: <5052121F020000780009B1E9@nat28.tlf.novell.com>
Cc: Tim Deegan <tim@xen.org>, Keir Fraser <keir@xen.org>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 19/22] arch/x86: check remote MMIO remap
	permissions
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 09/13/2012 11:04 AM, Jan Beulich wrote:
>>>> On 13.09.12 at 16:25, Daniel De Graaf <dgdegra@tycho.nsa.gov> wrote:
>> On 09/13/2012 10:13 AM, Jan Beulich wrote:
>>>>>> On 13.09.12 at 15:46, Daniel De Graaf <dgdegra@tycho.nsa.gov> wrote:
>>>> On 09/13/2012 04:00 AM, Jan Beulich wrote:
>>>>>>>> On 12.09.12 at 17:59, Daniel De Graaf <dgdegra@tycho.nsa.gov> wrote:
>>>>>> When a domain is mapping pages from a different pg_owner domain, the
>>>>>> iomem_access checks are currently only applied to the pg_owner domain,
>>>>>> potentially allowing the current domain to bypass its more restrictive
>>>>>> iomem_access policy using another domain that it has access to.
>>>>>
>>>>> Are you sure about this? I ask because ...
>>>>>
>>>>>> --- a/xen/arch/x86/mm.c
>>>>>> +++ b/xen/arch/x86/mm.c
>>>>>> @@ -754,6 +754,18 @@ get_page_from_l1e(
>>>>>>              return -EINVAL;
>>>>>>          }
>>>>>>  
>>>>>> +        if ( pg_owner != curr->domain &&
>>>>>> +             !iomem_access_permitted(curr->domain, mfn, mfn) )
>>>>>> +        {
>>>>>> +            if ( mfn != (PADDR_MASK >> PAGE_SHIFT) ) /* INVALID_MFN? */
>>>>>> +            {
>>>>>> +                MEM_LOG("Domain %u attempted to map I/O space %08lx in 
>>>> domain %u",
>>>>>> +                        curr->domain->domain_id, mfn, pg_owner->domain_id);
>>>>>> +                return -EPERM;
>>>>>> +            }
>>>>>> +            return -EINVAL;
>>>>>> +        }
>>>>>> +
>>>>>
>>>>> ... the place you insert this is after non-RAM pages got filtered
>>>>> out already, so you're applying an IOMEM permission check to a
>>>>> RAM page.
>>>>>
>>>>> Jan
>>>>>
>>>>>>          if ( !(l1f & _PAGE_RW) ||
>>>>>>               !rangeset_contains_singleton(mmio_ro_ranges, mfn) )
>>>>>>              return 0;
>>>>
>>>> If that's true, then the check a few lines above is also applying IOMEM
>>>> checks to RAM pages. I can see non-privileged attempts being filtered
>>>> above,
>>
>> "above" refers to "if ( !iomem_access_permitted(pg_owner, mfn, mfn) )"
>>  
>>> I can't see how that would happen given this primary conditional
>>>
>>>     if ( !mfn_valid(mfn) ||
>>>          (real_pg_owner = page_get_owner_and_reference(page)) == dom_io )
>>>
>>> Please clarify what you're observing.
>>
>> As I understand it, the contents of this block will be executed if the MFN 
>> is
>> invalid (interpreted as MMIO space) or if the page's owner is DOMID_IO, 
>> which
>> is how MMIO space is marked.
>>
>>>> but successful mappings will continue to the check I added.
>>>
>>> Of course. I would think that if anything, you would want to add
>>> a second call to iomem_access_permitted() with "curr->domain"
>>> right at the place where the current one is (in particular inside
>>> the above quoted conditional).
>>>
>>> Jan
>>
>> I was emulating the existing iomem_access_permitted check being run on 
>> pg_owner;
>> moving the curr->domain check up into this first conditional would end up
>> treating the MMIO mapping as a regular RAM mapping if the 
>> iomem_access_permitted
>> fails. Unless you're talking about a different quoted conditional?
> 
> I'm sorry, each of your replies get me more confused. Can you,
> with the current code (i.e. without your patches or any emulation
> you might be doing) explain (perhaps with an example) what
> specific case you see needing more checking than there is
> currently? That would probably allow us to start talking about the
> same thing.
> 
> Jan
> 

For this example, assume domain A has access to map domain B's memory
read-only. Domain B has access to a device with MMIO where reads to the
device's memory cause state changes - an example of such as device is a
TPM, where replies are read by repeated reads to a single 4-byte 
address. Domain A does not have access to this device, and would like to
maliciously interfere with the device.

If domain A maps the MMIO page from domain B using pg_owner == domB, the
iomem_access_permitted check will be done from domain B's perspective. 
While this is needed when domain A is mapping pages on behalf of domB, 
it is not sufficient when attempting to constrain domain A's access. 

These checks only apply to MMIO, so the condition on line 735 will
evaluate to true (!mfn_valid || real_pg_owner == dom_io).

The (existing) check on domain B's MMIO access is:
        if ( !iomem_access_permitted(pg_owner, mfn, mfn) )

This patch adds a check on domain A:
        if ( !iomem_access_permitted(curr->domain, mfn, mfn) )
            
This extra checking has not been required without XSM because only FLASK
implements the ability to grant one domain read-only access to another 
domain. With read-write access, this extra access check is simple to get
around: domain A can modify some part of the executable code in domain B
to act as a proxy for its accesses. Additionally, domain A is usually
dom0 or the device model, which have equal or greater MMIO access.

-- 
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 Sep 13 16:53:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Sep 2012 16:53:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TCCem-00017l-Uj; Thu, 13 Sep 2012 16:52:48 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1TCCel-00017f-En
	for xen-devel@lists.xen.org; Thu, 13 Sep 2012 16:52:47 +0000
Received: from [85.158.143.35:32415] by server-3.bemta-4.messagelabs.com id
	51/89-08232-E5F02505; Thu, 13 Sep 2012 16:52:46 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1347555166!14526372!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-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1461 invoked from network); 13 Sep 2012 16:52:46 -0000
Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com)
	(74.125.83.45)
	by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Sep 2012 16:52:46 -0000
Received: by eeke53 with SMTP id e53so2167223eek.32
	for <xen-devel@lists.xen.org>; Thu, 13 Sep 2012 09:52:46 -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=Ha9L6ydw8D70Yu3CmOHLWN+s3zMenTyqGHlN2ObZWBo=;
	b=YaJmKUT2EfYHJl+YkYBpoR0Hxys+zLZmi7aSSzgox+gZxTb+G1ug+hsScasDABiQDd
	MLhRf+v8ZjAcWDShnlm0PndSYFh5mpRYZNzHm9F+KymyaQSOQuRtsoCur1ONqfU1TMaU
	Kvq7b294BJqaXgPTmxD+4e3CO97aSQ3PPsHGZt+JI4uHcegvA9LLp4cyeNz1uiojr/A0
	eOQy7AWCJj/Q5mYShMKssxeS2feRoo85cEkGn/ZoSmNXoeFQf9xHhx54liU3MR0Z0kiY
	8VFKvX5RuKpXdL8Cl20szqlGepfEnPMzuqmzW1XG9BgsR/T8WgjDkd0J3x3cvc62LjTH
	pCfQ==
Received: by 10.14.218.134 with SMTP id k6mr3899871eep.14.1347555166015;
	Thu, 13 Sep 2012 09:52:46 -0700 (PDT)
Received: from [192.168.1.69] (host86-184-74-117.range86-184.btcentralplus.com.
	[86.184.74.117])
	by mx.google.com with ESMTPS id k49sm66688314een.4.2012.09.13.09.52.44
	(version=SSLv3 cipher=OTHER); Thu, 13 Sep 2012 09:52:45 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Thu, 13 Sep 2012 17:52:42 +0100
From: Keir Fraser <keir.xen@gmail.com>
To: Matt Wilson <msw@amazon.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Message-ID: <CC77CDEA.3EB45%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [ANNOUNCE] Final release candidate for Xen 4.2.0
Thread-Index: Ac2R0DC0rVesNfjlOkCZdOyvsfiUFw==
In-Reply-To: <20120913092503.GA15042@u002268147cd4502c336d.ant.amazon.com>
Mime-version: 1.0
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [ANNOUNCE] Final release candidate for Xen 4.2.0
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 13/09/2012 17:25, "Matt Wilson" <msw@amazon.com> wrote:

> On Thu, Sep 13, 2012 at 03:53:28PM +0100, Ian Jackson wrote:
>>> We plan to call the 4.2.0 release on Monday, with no further modifications.
>>> So please test this "GA preview"!
>> 
>> As Keir says.  If all goes well the 4.2.0 release will have a
>> functionally identical tarball.
> 
> Any chance my man page fixes will make it in to the final tarball?
> "Functionally identical" seems to leave some wiggle room.

I think these are low priority enough they can wait for 4.2.1, which will be
6-8 weeks.

 -- Keir

> xmdomain.cfg.5 has POD errors (displayed when you run "man xmdomain.cfg":
> POD ERRORS
>        Hey! The above document had some coding errors, which are
>        explained
>        below:
> 
>        Around line 301:
>            You can't have =items (as at line 305) unless the first
>   thing after
>            the =over is an =item
> 
>        Around line 311:
>            '=item' outside of any '=over'
> 
> xl.cfg.5 has POD errors:
> POD ERRORS
>        Hey! The above document had some coding errors, which are
>        explained
>        below:
> 
>        Around line 405:
>            '=item' outside of any '=over'
> 
>        Around line 429:
>            You forgot a '=back' before '=head2'
> 
>        Around line 687:
>            '=item' outside of any '=over'
> 
>        Around line 695:
>            You forgot a '=back' before '=head3'
> 
> Matt



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 13 16:53:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Sep 2012 16:53:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TCCem-00017l-Uj; Thu, 13 Sep 2012 16:52:48 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1TCCel-00017f-En
	for xen-devel@lists.xen.org; Thu, 13 Sep 2012 16:52:47 +0000
Received: from [85.158.143.35:32415] by server-3.bemta-4.messagelabs.com id
	51/89-08232-E5F02505; Thu, 13 Sep 2012 16:52:46 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1347555166!14526372!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-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1461 invoked from network); 13 Sep 2012 16:52:46 -0000
Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com)
	(74.125.83.45)
	by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Sep 2012 16:52:46 -0000
Received: by eeke53 with SMTP id e53so2167223eek.32
	for <xen-devel@lists.xen.org>; Thu, 13 Sep 2012 09:52:46 -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=Ha9L6ydw8D70Yu3CmOHLWN+s3zMenTyqGHlN2ObZWBo=;
	b=YaJmKUT2EfYHJl+YkYBpoR0Hxys+zLZmi7aSSzgox+gZxTb+G1ug+hsScasDABiQDd
	MLhRf+v8ZjAcWDShnlm0PndSYFh5mpRYZNzHm9F+KymyaQSOQuRtsoCur1ONqfU1TMaU
	Kvq7b294BJqaXgPTmxD+4e3CO97aSQ3PPsHGZt+JI4uHcegvA9LLp4cyeNz1uiojr/A0
	eOQy7AWCJj/Q5mYShMKssxeS2feRoo85cEkGn/ZoSmNXoeFQf9xHhx54liU3MR0Z0kiY
	8VFKvX5RuKpXdL8Cl20szqlGepfEnPMzuqmzW1XG9BgsR/T8WgjDkd0J3x3cvc62LjTH
	pCfQ==
Received: by 10.14.218.134 with SMTP id k6mr3899871eep.14.1347555166015;
	Thu, 13 Sep 2012 09:52:46 -0700 (PDT)
Received: from [192.168.1.69] (host86-184-74-117.range86-184.btcentralplus.com.
	[86.184.74.117])
	by mx.google.com with ESMTPS id k49sm66688314een.4.2012.09.13.09.52.44
	(version=SSLv3 cipher=OTHER); Thu, 13 Sep 2012 09:52:45 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Thu, 13 Sep 2012 17:52:42 +0100
From: Keir Fraser <keir.xen@gmail.com>
To: Matt Wilson <msw@amazon.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Message-ID: <CC77CDEA.3EB45%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [ANNOUNCE] Final release candidate for Xen 4.2.0
Thread-Index: Ac2R0DC0rVesNfjlOkCZdOyvsfiUFw==
In-Reply-To: <20120913092503.GA15042@u002268147cd4502c336d.ant.amazon.com>
Mime-version: 1.0
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [ANNOUNCE] Final release candidate for Xen 4.2.0
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 13/09/2012 17:25, "Matt Wilson" <msw@amazon.com> wrote:

> On Thu, Sep 13, 2012 at 03:53:28PM +0100, Ian Jackson wrote:
>>> We plan to call the 4.2.0 release on Monday, with no further modifications.
>>> So please test this "GA preview"!
>> 
>> As Keir says.  If all goes well the 4.2.0 release will have a
>> functionally identical tarball.
> 
> Any chance my man page fixes will make it in to the final tarball?
> "Functionally identical" seems to leave some wiggle room.

I think these are low priority enough they can wait for 4.2.1, which will be
6-8 weeks.

 -- Keir

> xmdomain.cfg.5 has POD errors (displayed when you run "man xmdomain.cfg":
> POD ERRORS
>        Hey! The above document had some coding errors, which are
>        explained
>        below:
> 
>        Around line 301:
>            You can't have =items (as at line 305) unless the first
>   thing after
>            the =over is an =item
> 
>        Around line 311:
>            '=item' outside of any '=over'
> 
> xl.cfg.5 has POD errors:
> POD ERRORS
>        Hey! The above document had some coding errors, which are
>        explained
>        below:
> 
>        Around line 405:
>            '=item' outside of any '=over'
> 
>        Around line 429:
>            You forgot a '=back' before '=head2'
> 
>        Around line 687:
>            '=item' outside of any '=over'
> 
>        Around line 695:
>            You forgot a '=back' before '=head3'
> 
> Matt



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 13 17:06:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Sep 2012 17:06:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TCCrw-0001Om-Dj; Thu, 13 Sep 2012 17:06: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 1TCCru-0001Oh-Qq
	for xen-devel@lists.xen.org; Thu, 13 Sep 2012 17:06:23 +0000
Received: from [85.158.138.51:9057] by server-3.bemta-3.messagelabs.com id
	35/91-21322-D8212505; Thu, 13 Sep 2012 17:06:21 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1347555981!30378233!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDkwMjg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9515 invoked from network); 13 Sep 2012 17:06:21 -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;
	13 Sep 2012 17:06:21 -0000
X-IronPort-AV: E=Sophos;i="4.80,417,1344211200"; d="scan'208";a="14527753"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Sep 2012 17:04: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.279.1; Thu, 13 Sep 2012 18:04: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
	1TCCqX-0008GI-4z; Thu, 13 Sep 2012 17:04:57 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1TCCqX-0005zm-1M;
	Thu, 13 Sep 2012 18:04:57 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20562.4664.778258.29924@mariner.uk.xensource.com>
Date: Thu, 13 Sep 2012 18:04:56 +0100
To: Tim Deegan <tim@xen.org>
In-Reply-To: <20120913164100.GF12881@ocelot.phlegethon.org>
References: <CAFw--Dd0k7L+T_UJc0yHAkUGrY_-GDHaQjK3OM-1UdOp=J-wAQ@mail.gmail.com>
	<20120907085036.GA71093@ocelot.phlegethon.org>
	<CAFw--DdYkAo79TeZKDFZ5ZdaN4KiLmW2qcceY+cTxuLMdE3QGA@mail.gmail.com>
	<CAFw--Dche2NB0jjBdMyAYC=S92XkW9UpsaBsTRBcX4ZP_oOcxA@mail.gmail.com>
	<alpine.DEB.2.02.1209121123480.15568@kaball.uk.xensource.com>
	<20562.1720.617032.513944@mariner.uk.xensource.com>
	<20120913164100.GF12881@ocelot.phlegethon.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>,
	Jeffrey Karrels <karrelsj@gmail.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Clang/LLVM version requirements
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Tim Deegan writes ("Re: [Xen-devel] Clang/LLVM version requirements"):
> At 17:15 +0100 on 13 Sep (1347556552), Ian Jackson wrote:
> > What do I need to do on an amd64 Debian squeeze system to build with
> > clang ?
> 
> You need clang 3.0-6, which is in wheezy but not squeeze.  Then just
> "make dist-xen clang=y".

Ah.  Well I guess I could install wheezy but I would prefer not to
make the test system depend on wheezy until wheezy is released.  So
this should wait.

> The tools don't build with clang, only Xen.
> I presume that if we want to build the tools with clang in future it
> would be done with autofoo rather than clang=y.

Probably, yes.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 13 17:06:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Sep 2012 17:06:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TCCrw-0001Om-Dj; Thu, 13 Sep 2012 17:06: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 1TCCru-0001Oh-Qq
	for xen-devel@lists.xen.org; Thu, 13 Sep 2012 17:06:23 +0000
Received: from [85.158.138.51:9057] by server-3.bemta-3.messagelabs.com id
	35/91-21322-D8212505; Thu, 13 Sep 2012 17:06:21 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1347555981!30378233!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDkwMjg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9515 invoked from network); 13 Sep 2012 17:06:21 -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;
	13 Sep 2012 17:06:21 -0000
X-IronPort-AV: E=Sophos;i="4.80,417,1344211200"; d="scan'208";a="14527753"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Sep 2012 17:04: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.279.1; Thu, 13 Sep 2012 18:04: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
	1TCCqX-0008GI-4z; Thu, 13 Sep 2012 17:04:57 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1TCCqX-0005zm-1M;
	Thu, 13 Sep 2012 18:04:57 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20562.4664.778258.29924@mariner.uk.xensource.com>
Date: Thu, 13 Sep 2012 18:04:56 +0100
To: Tim Deegan <tim@xen.org>
In-Reply-To: <20120913164100.GF12881@ocelot.phlegethon.org>
References: <CAFw--Dd0k7L+T_UJc0yHAkUGrY_-GDHaQjK3OM-1UdOp=J-wAQ@mail.gmail.com>
	<20120907085036.GA71093@ocelot.phlegethon.org>
	<CAFw--DdYkAo79TeZKDFZ5ZdaN4KiLmW2qcceY+cTxuLMdE3QGA@mail.gmail.com>
	<CAFw--Dche2NB0jjBdMyAYC=S92XkW9UpsaBsTRBcX4ZP_oOcxA@mail.gmail.com>
	<alpine.DEB.2.02.1209121123480.15568@kaball.uk.xensource.com>
	<20562.1720.617032.513944@mariner.uk.xensource.com>
	<20120913164100.GF12881@ocelot.phlegethon.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>,
	Jeffrey Karrels <karrelsj@gmail.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Clang/LLVM version requirements
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Tim Deegan writes ("Re: [Xen-devel] Clang/LLVM version requirements"):
> At 17:15 +0100 on 13 Sep (1347556552), Ian Jackson wrote:
> > What do I need to do on an amd64 Debian squeeze system to build with
> > clang ?
> 
> You need clang 3.0-6, which is in wheezy but not squeeze.  Then just
> "make dist-xen clang=y".

Ah.  Well I guess I could install wheezy but I would prefer not to
make the test system depend on wheezy until wheezy is released.  So
this should wait.

> The tools don't build with clang, only Xen.
> I presume that if we want to build the tools with clang in future it
> would be done with autofoo rather than clang=y.

Probably, yes.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 13 17:15:11 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Sep 2012 17: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 1TCD08-0001ZW-Cl; Thu, 13 Sep 2012 17:14:52 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mukesh.rathor@oracle.com>) id 1TCD06-0001ZO-VS
	for Xen-devel@lists.xensource.com; Thu, 13 Sep 2012 17:14:51 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1347556483!3222972!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzM4ODI0\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7217 invoked from network); 13 Sep 2012 17:14:44 -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; 13 Sep 2012 17:14:44 -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 q8DHEfvK028168
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 13 Sep 2012 17:14:42 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q8DHEeEt024263
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 13 Sep 2012 17:14:41 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
	q8DHEeWR016272; Thu, 13 Sep 2012 12:14:40 -0500
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 13 Sep 2012 10:14:40 -0700
Date: Thu, 13 Sep 2012 10:14:39 -0700
From: Mukesh Rathor <mukesh.rathor@oracle.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120913101439.6bd363a9@mantra.us.oracle.com>
In-Reply-To: <1347516007.25803.44.camel@dagon.hellion.org.uk>
References: <20120815175724.3405043a@mantra.us.oracle.com>
	<1347285352.5305.86.camel@zakaz.uk.xensource.com>
	<20120911145751.599b8292@mantra.us.oracle.com>
	<1347437545.25803.16.camel@dagon.hellion.org.uk>
	<20120912110254.10bde333@mantra.us.oracle.com>
	<1347474380.25803.21.camel@dagon.hellion.org.uk>
	<20120912123238.7057c51a@mantra.us.oracle.com>
	<1347516007.25803.44.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: ucsinet22.oracle.com [156.151.31.94]
Cc: "Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [RFC PATCH 1/8]: PVH: Basic and preparatory changes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 13 Sep 2012 07:00:07 +0100
Ian Campbell <Ian.Campbell@citrix.com> wrote:

> On Wed, 2012-09-12 at 20:32 +0100, Mukesh Rathor wrote:
> > On Wed, 12 Sep 2012 19:26:20 +0100
> > Ian Campbell <Ian.Campbell@citrix.com> wrote:
> > 
> > > On Wed, 2012-09-12 at 19:02 +0100, Mukesh Rathor wrote:
> Callback vector is XENFEAT_hvm_callback_vector, I think.
> 
> A PV kernel is required to announce the features which it supports via
> the elf notes (defined in xen-head.S).
> 
> It would be a bug for the toolstack to enable PVH mode for a kernel
> which did not claim to support the required featureset.
> 
> The aim should be that the user should not normally need to specify
> pvh one way or the other, imagine a use case where pygrub is used to
> boot both old and new kernels using it.
> 
> The toolstack (or the dom0 builder) can make the determination whether
> to enable this mode itself itself based on the notes (although it is
> always handy to have an override to force things for debug).

Hmmm... So you are suggesting that if hardware and xen supports it, then
PV should just boot in PVH mode and user has no way to override it. I
don't know if that's a good idea in the short term, perhaps in the long
term. Let me discuss with folks here a bit.

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 Sep 13 17:15:11 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Sep 2012 17: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 1TCD08-0001ZW-Cl; Thu, 13 Sep 2012 17:14:52 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mukesh.rathor@oracle.com>) id 1TCD06-0001ZO-VS
	for Xen-devel@lists.xensource.com; Thu, 13 Sep 2012 17:14:51 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1347556483!3222972!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzM4ODI0\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7217 invoked from network); 13 Sep 2012 17:14:44 -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; 13 Sep 2012 17:14:44 -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 q8DHEfvK028168
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 13 Sep 2012 17:14:42 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q8DHEeEt024263
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 13 Sep 2012 17:14:41 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
	q8DHEeWR016272; Thu, 13 Sep 2012 12:14:40 -0500
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 13 Sep 2012 10:14:40 -0700
Date: Thu, 13 Sep 2012 10:14:39 -0700
From: Mukesh Rathor <mukesh.rathor@oracle.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120913101439.6bd363a9@mantra.us.oracle.com>
In-Reply-To: <1347516007.25803.44.camel@dagon.hellion.org.uk>
References: <20120815175724.3405043a@mantra.us.oracle.com>
	<1347285352.5305.86.camel@zakaz.uk.xensource.com>
	<20120911145751.599b8292@mantra.us.oracle.com>
	<1347437545.25803.16.camel@dagon.hellion.org.uk>
	<20120912110254.10bde333@mantra.us.oracle.com>
	<1347474380.25803.21.camel@dagon.hellion.org.uk>
	<20120912123238.7057c51a@mantra.us.oracle.com>
	<1347516007.25803.44.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: ucsinet22.oracle.com [156.151.31.94]
Cc: "Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [RFC PATCH 1/8]: PVH: Basic and preparatory changes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 13 Sep 2012 07:00:07 +0100
Ian Campbell <Ian.Campbell@citrix.com> wrote:

> On Wed, 2012-09-12 at 20:32 +0100, Mukesh Rathor wrote:
> > On Wed, 12 Sep 2012 19:26:20 +0100
> > Ian Campbell <Ian.Campbell@citrix.com> wrote:
> > 
> > > On Wed, 2012-09-12 at 19:02 +0100, Mukesh Rathor wrote:
> Callback vector is XENFEAT_hvm_callback_vector, I think.
> 
> A PV kernel is required to announce the features which it supports via
> the elf notes (defined in xen-head.S).
> 
> It would be a bug for the toolstack to enable PVH mode for a kernel
> which did not claim to support the required featureset.
> 
> The aim should be that the user should not normally need to specify
> pvh one way or the other, imagine a use case where pygrub is used to
> boot both old and new kernels using it.
> 
> The toolstack (or the dom0 builder) can make the determination whether
> to enable this mode itself itself based on the notes (although it is
> always handy to have an override to force things for debug).

Hmmm... So you are suggesting that if hardware and xen supports it, then
PV should just boot in PVH mode and user has no way to override it. I
don't know if that's a good idea in the short term, perhaps in the long
term. Let me discuss with folks here a bit.

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 Sep 13 17:16:55 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Sep 2012 17:16:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TCD1r-0001eN-29; Thu, 13 Sep 2012 17:16:39 +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 1TCD1p-0001eF-GK
	for xen-devel@lists.xensource.com; Thu, 13 Sep 2012 17:16:37 +0000
Received: from [85.158.139.83:50527] by server-12.bemta-5.messagelabs.com id
	9E/F0-19338-4F412505; Thu, 13 Sep 2012 17:16:36 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1347556595!23153541!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDkwMjg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11011 invoked from network); 13 Sep 2012 17:16: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;
	13 Sep 2012 17:16:36 -0000
X-IronPort-AV: E=Sophos;i="4.80,417,1344211200"; d="scan'208";a="14527936"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Sep 2012 17:16: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.279.1; Thu, 13 Sep 2012 18:16:35 +0100
Date: Thu, 13 Sep 2012 18:15:53 +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.1208161618550.4850@kaball.uk.xensource.com>
Message-ID: <alpine.DEB.2.02.1209131809290.15568@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1208161618550.4850@kaball.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>,
	"linaro-dev@lists.linaro.org" <linaro-dev@lists.linaro.org>,
	Ian Campbell <Ian.Campbell@citrix.com>, "arnd@arndb.de" <arnd@arndb.de>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"catalin.marinas@arm.com" <catalin.marinas@arm.com>,
	"Tim \(Xen.org\)" <tim@xen.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Russell King - ARM Linux <linux@arm.linux.org.uk>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Xen-devel] [PATCH v3 00/23] Introduce Xen support on ARM
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Russell,
sorry for not CC'ing you on the entire patch series in the past, I'll do
it in the next iteration of the series (that TBH is nearly identical to
this one apart from being 3.6-rc5 based).

Are you happy with it? Given that the changes are entirely contained
within arch/arm/xen and arch/arm/include/asm/xen (apart from patch #21
that is a generic ARM fix), should this patch series go through you or
Arnd?

Thanks,

Stefano




On Thu, 16 Aug 2012, Stefano Stabellini wrote:
> Hi all,
> this patch series implements Xen support for ARMv7 with virtualization
> extensions.  It allows a Linux guest to boot as dom0 and
> as domU on Xen on ARM. PV console, disk and network frontends and
> backends are all working correctly.
> 
> It has been tested on a Versatile Express Cortex A15 emulator, using the
> latest Xen ARM developement branch
> (git://xenbits.xen.org/people/ianc/xen-unstable.git arm-for-4.3) plus
> the "ARM hypercall ABI: 64 bit ready" patch series
> (http://marc.info/?l=xen-devel&m=134426267205408), and a simple ad-hoc
> tool to build guest domains (marc.info/?l=xen-devel&m=134089788016546).
> 
> The patch marked with [HACK] shouldn't be applied and is part of the
> series only because it is needed to create domUs.
> 
> I am also attaching to this email the dts'es that I am currently using
> for dom0 and domU: vexpress-v2p-ca15-tc1.dts (that includes
> vexpress-v2m-rs1-rtsm.dtsi) is the dts used for dom0 and it is passed to
> Linux by Xen, while vexpress-virt.dts is the dts used for other domUs
> and it is appended in binary form to the guest kernel image. I am not
> sure where they are supposed to live yet, so I am just attaching them
> here so that people can actually try out this series if they want to.
> 
> Comments are very welcome!
> 
> 
> Changes in v3:
> - move patches that have been picked up by Konrad at the end of the
>   series;
> - improve comments;
> - add a doc to describe the Xen Device Tree format;
> - do not use xen_ulong_t for multicalls and apic_physbase;
> - add a patch at the end of the series to use the new __HVC macro;
> - add missing pvclock-abi.h include to ia64 header files;
> - do not use an anonymous union in struct xen_add_to_physmap.
> 
> 
> Changes in v2:
> - fix up many comments and commit messages;
> - remove the early_printk patches: rely on the emulated serial for now;
> - remove the xen_guest_init patch: without any PV early_printk, we don't
>   need any early call to xen_guest_init, we can rely on core_initcall
>   alone;
> - define an HYPERCALL macro for 5 arguments hypercall wrappers, even if
>   at the moment is unused;
> - use ldm instead of pop in the hypercall wrappers;
> - return -ENOSYS rather than -1 from the unimplemented grant_table
>   functions;
> - remove the pvclock ifdef in the Xen headers;
> - remove include linux/types.h from xen/interface/xen.h;
> - replace pr_info with pr_debug in xen_guest_init;
> - add a new patch to introduce xen_ulong_t and use it top replace all
>   the occurences of unsigned long in the public Xen interface;
> - explicitely size all the pointers to 64 bit on ARM, so that the
>   hypercall ABI is "64 bit ready";
> - clean up xenbus_init;
> - make pci.o depend on CONFIG_PCI and acpi.o depend on CONFIG_ACPI;
> - mark Xen guest support on ARM as EXPERIMENTAL;
> - introduce GRANT_TABLE_PHYSADDR;
> - remove unneeded initialization of boot_max_nr_grant_frames;
> - add a new patch to clear IRQ_NOAUTOEN and IRQ_NOREQUEST in events.c;
> - return -EINVAL from xen_remap_domain_mfn_range if
>   auto_translated_physmap;
> - retain binary compatibility in xen_add_to_physmap: use a union to
>   introduce foreign_domid.
> 
> 
> Ian Campbell (1):
>       [HACK] xen/arm: implement xen_remap_domain_mfn_range
> 
> Stefano Stabellini (24):
>       arm: initial Xen support
>       xen/arm: hypercalls
>       xen/arm: page.h definitions
>       xen/arm: sync_bitops
>       xen/arm: empty implementation of grant_table arch specific functions
>       docs: Xen ARM DT bindings
>       xen/arm: Xen detection and shared_info page mapping
>       xen/arm: Introduce xen_pfn_t for pfn and mfn types
>       xen/arm: Introduce xen_ulong_t for unsigned long
>       xen/arm: compile and run xenbus
>       xen: do not compile manage, balloon, pci, acpi and cpu_hotplug on ARM
>       xen/arm: introduce CONFIG_XEN on ARM
>       xen/arm: get privilege status
>       xen/arm: initialize grant_table on ARM
>       xen/arm: receive Xen events on ARM
>       xen: clear IRQ_NOAUTOEN and IRQ_NOREQUEST
>       xen/arm: implement alloc/free_xenballooned_pages with alloc_pages/kfree
>       xen: allow privcmd for HVM guests
>       xen/arm: compile blkfront and blkback
>       xen/arm: compile netback
>       arm/v2m: initialize arch_timers even if v2m_timer is not present
>       xen/arm: use the __HVC macro
>       xen: missing includes
>       xen: update xen_add_to_physmap interface
> 
>  Documentation/devicetree/bindings/arm/xen.txt |   22 +++
>  arch/arm/Kconfig                              |   10 +
>  arch/arm/Makefile                             |    1 +
>  arch/arm/include/asm/hypervisor.h             |    6 +
>  arch/arm/include/asm/sync_bitops.h            |   27 +++
>  arch/arm/include/asm/xen/events.h             |   18 ++
>  arch/arm/include/asm/xen/hypercall.h          |   69 +++++++
>  arch/arm/include/asm/xen/hypervisor.h         |   19 ++
>  arch/arm/include/asm/xen/interface.h          |   73 ++++++++
>  arch/arm/include/asm/xen/page.h               |   82 ++++++++
>  arch/arm/mach-vexpress/v2m.c                  |   11 +-
>  arch/arm/xen/Makefile                         |    1 +
>  arch/arm/xen/enlighten.c                      |  245 +++++++++++++++++++++++++
>  arch/arm/xen/grant-table.c                    |   53 ++++++
>  arch/arm/xen/hypercall.S                      |  102 ++++++++++
>  arch/ia64/include/asm/xen/interface.h         |    8 +-
>  arch/x86/include/asm/xen/interface.h          |    8 +
>  arch/x86/xen/enlighten.c                      |    1 +
>  arch/x86/xen/irq.c                            |    1 +
>  arch/x86/xen/mmu.c                            |    3 +
>  arch/x86/xen/xen-ops.h                        |    1 -
>  drivers/block/xen-blkback/blkback.c           |    1 +
>  drivers/net/xen-netback/netback.c             |    1 +
>  drivers/net/xen-netfront.c                    |    1 +
>  drivers/tty/hvc/hvc_xen.c                     |    2 +
>  drivers/xen/Makefile                          |   11 +-
>  drivers/xen/events.c                          |   18 ++-
>  drivers/xen/grant-table.c                     |    1 +
>  drivers/xen/privcmd.c                         |   20 +-
>  drivers/xen/xenbus/xenbus_comms.c             |    2 +-
>  drivers/xen/xenbus/xenbus_probe.c             |   62 +++++--
>  drivers/xen/xenbus/xenbus_probe_frontend.c    |    1 +
>  drivers/xen/xenbus/xenbus_xs.c                |    1 +
>  drivers/xen/xenfs/super.c                     |    7 +
>  include/xen/events.h                          |    2 +
>  include/xen/interface/features.h              |    3 +
>  include/xen/interface/grant_table.h           |    4 +-
>  include/xen/interface/io/protocols.h          |    3 +
>  include/xen/interface/memory.h                |   32 ++-
>  include/xen/interface/physdev.h               |    2 +-
>  include/xen/interface/platform.h              |    4 +-
>  include/xen/interface/version.h               |    2 +-
>  include/xen/interface/xen.h                   |    7 +-
>  include/xen/privcmd.h                         |    3 +-
>  include/xen/xen.h                             |    2 +-
>  45 files changed, 885 insertions(+), 68 deletions(-)
> 
> 
> A branch based on 3.5-rc7 is available here (the __HVC patch is missing
> from this branch because it depends on "ARM: opcodes: Facilitate custom
> opcode injection" http://marc.info/?l=linux-arm-kernel&m=134442896128124):
> 
> git://xenbits.xen.org/people/sstabellini/linux-pvhvm.git 3.5-rc7-arm-3
> 
> Cheers,
> 
> Stefano

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 13 17:16:55 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Sep 2012 17:16:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TCD1r-0001eN-29; Thu, 13 Sep 2012 17:16:39 +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 1TCD1p-0001eF-GK
	for xen-devel@lists.xensource.com; Thu, 13 Sep 2012 17:16:37 +0000
Received: from [85.158.139.83:50527] by server-12.bemta-5.messagelabs.com id
	9E/F0-19338-4F412505; Thu, 13 Sep 2012 17:16:36 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1347556595!23153541!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDkwMjg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11011 invoked from network); 13 Sep 2012 17:16: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;
	13 Sep 2012 17:16:36 -0000
X-IronPort-AV: E=Sophos;i="4.80,417,1344211200"; d="scan'208";a="14527936"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Sep 2012 17:16: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.279.1; Thu, 13 Sep 2012 18:16:35 +0100
Date: Thu, 13 Sep 2012 18:15:53 +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.1208161618550.4850@kaball.uk.xensource.com>
Message-ID: <alpine.DEB.2.02.1209131809290.15568@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1208161618550.4850@kaball.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>,
	"linaro-dev@lists.linaro.org" <linaro-dev@lists.linaro.org>,
	Ian Campbell <Ian.Campbell@citrix.com>, "arnd@arndb.de" <arnd@arndb.de>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"catalin.marinas@arm.com" <catalin.marinas@arm.com>,
	"Tim \(Xen.org\)" <tim@xen.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Russell King - ARM Linux <linux@arm.linux.org.uk>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Xen-devel] [PATCH v3 00/23] Introduce Xen support on ARM
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Russell,
sorry for not CC'ing you on the entire patch series in the past, I'll do
it in the next iteration of the series (that TBH is nearly identical to
this one apart from being 3.6-rc5 based).

Are you happy with it? Given that the changes are entirely contained
within arch/arm/xen and arch/arm/include/asm/xen (apart from patch #21
that is a generic ARM fix), should this patch series go through you or
Arnd?

Thanks,

Stefano




On Thu, 16 Aug 2012, Stefano Stabellini wrote:
> Hi all,
> this patch series implements Xen support for ARMv7 with virtualization
> extensions.  It allows a Linux guest to boot as dom0 and
> as domU on Xen on ARM. PV console, disk and network frontends and
> backends are all working correctly.
> 
> It has been tested on a Versatile Express Cortex A15 emulator, using the
> latest Xen ARM developement branch
> (git://xenbits.xen.org/people/ianc/xen-unstable.git arm-for-4.3) plus
> the "ARM hypercall ABI: 64 bit ready" patch series
> (http://marc.info/?l=xen-devel&m=134426267205408), and a simple ad-hoc
> tool to build guest domains (marc.info/?l=xen-devel&m=134089788016546).
> 
> The patch marked with [HACK] shouldn't be applied and is part of the
> series only because it is needed to create domUs.
> 
> I am also attaching to this email the dts'es that I am currently using
> for dom0 and domU: vexpress-v2p-ca15-tc1.dts (that includes
> vexpress-v2m-rs1-rtsm.dtsi) is the dts used for dom0 and it is passed to
> Linux by Xen, while vexpress-virt.dts is the dts used for other domUs
> and it is appended in binary form to the guest kernel image. I am not
> sure where they are supposed to live yet, so I am just attaching them
> here so that people can actually try out this series if they want to.
> 
> Comments are very welcome!
> 
> 
> Changes in v3:
> - move patches that have been picked up by Konrad at the end of the
>   series;
> - improve comments;
> - add a doc to describe the Xen Device Tree format;
> - do not use xen_ulong_t for multicalls and apic_physbase;
> - add a patch at the end of the series to use the new __HVC macro;
> - add missing pvclock-abi.h include to ia64 header files;
> - do not use an anonymous union in struct xen_add_to_physmap.
> 
> 
> Changes in v2:
> - fix up many comments and commit messages;
> - remove the early_printk patches: rely on the emulated serial for now;
> - remove the xen_guest_init patch: without any PV early_printk, we don't
>   need any early call to xen_guest_init, we can rely on core_initcall
>   alone;
> - define an HYPERCALL macro for 5 arguments hypercall wrappers, even if
>   at the moment is unused;
> - use ldm instead of pop in the hypercall wrappers;
> - return -ENOSYS rather than -1 from the unimplemented grant_table
>   functions;
> - remove the pvclock ifdef in the Xen headers;
> - remove include linux/types.h from xen/interface/xen.h;
> - replace pr_info with pr_debug in xen_guest_init;
> - add a new patch to introduce xen_ulong_t and use it top replace all
>   the occurences of unsigned long in the public Xen interface;
> - explicitely size all the pointers to 64 bit on ARM, so that the
>   hypercall ABI is "64 bit ready";
> - clean up xenbus_init;
> - make pci.o depend on CONFIG_PCI and acpi.o depend on CONFIG_ACPI;
> - mark Xen guest support on ARM as EXPERIMENTAL;
> - introduce GRANT_TABLE_PHYSADDR;
> - remove unneeded initialization of boot_max_nr_grant_frames;
> - add a new patch to clear IRQ_NOAUTOEN and IRQ_NOREQUEST in events.c;
> - return -EINVAL from xen_remap_domain_mfn_range if
>   auto_translated_physmap;
> - retain binary compatibility in xen_add_to_physmap: use a union to
>   introduce foreign_domid.
> 
> 
> Ian Campbell (1):
>       [HACK] xen/arm: implement xen_remap_domain_mfn_range
> 
> Stefano Stabellini (24):
>       arm: initial Xen support
>       xen/arm: hypercalls
>       xen/arm: page.h definitions
>       xen/arm: sync_bitops
>       xen/arm: empty implementation of grant_table arch specific functions
>       docs: Xen ARM DT bindings
>       xen/arm: Xen detection and shared_info page mapping
>       xen/arm: Introduce xen_pfn_t for pfn and mfn types
>       xen/arm: Introduce xen_ulong_t for unsigned long
>       xen/arm: compile and run xenbus
>       xen: do not compile manage, balloon, pci, acpi and cpu_hotplug on ARM
>       xen/arm: introduce CONFIG_XEN on ARM
>       xen/arm: get privilege status
>       xen/arm: initialize grant_table on ARM
>       xen/arm: receive Xen events on ARM
>       xen: clear IRQ_NOAUTOEN and IRQ_NOREQUEST
>       xen/arm: implement alloc/free_xenballooned_pages with alloc_pages/kfree
>       xen: allow privcmd for HVM guests
>       xen/arm: compile blkfront and blkback
>       xen/arm: compile netback
>       arm/v2m: initialize arch_timers even if v2m_timer is not present
>       xen/arm: use the __HVC macro
>       xen: missing includes
>       xen: update xen_add_to_physmap interface
> 
>  Documentation/devicetree/bindings/arm/xen.txt |   22 +++
>  arch/arm/Kconfig                              |   10 +
>  arch/arm/Makefile                             |    1 +
>  arch/arm/include/asm/hypervisor.h             |    6 +
>  arch/arm/include/asm/sync_bitops.h            |   27 +++
>  arch/arm/include/asm/xen/events.h             |   18 ++
>  arch/arm/include/asm/xen/hypercall.h          |   69 +++++++
>  arch/arm/include/asm/xen/hypervisor.h         |   19 ++
>  arch/arm/include/asm/xen/interface.h          |   73 ++++++++
>  arch/arm/include/asm/xen/page.h               |   82 ++++++++
>  arch/arm/mach-vexpress/v2m.c                  |   11 +-
>  arch/arm/xen/Makefile                         |    1 +
>  arch/arm/xen/enlighten.c                      |  245 +++++++++++++++++++++++++
>  arch/arm/xen/grant-table.c                    |   53 ++++++
>  arch/arm/xen/hypercall.S                      |  102 ++++++++++
>  arch/ia64/include/asm/xen/interface.h         |    8 +-
>  arch/x86/include/asm/xen/interface.h          |    8 +
>  arch/x86/xen/enlighten.c                      |    1 +
>  arch/x86/xen/irq.c                            |    1 +
>  arch/x86/xen/mmu.c                            |    3 +
>  arch/x86/xen/xen-ops.h                        |    1 -
>  drivers/block/xen-blkback/blkback.c           |    1 +
>  drivers/net/xen-netback/netback.c             |    1 +
>  drivers/net/xen-netfront.c                    |    1 +
>  drivers/tty/hvc/hvc_xen.c                     |    2 +
>  drivers/xen/Makefile                          |   11 +-
>  drivers/xen/events.c                          |   18 ++-
>  drivers/xen/grant-table.c                     |    1 +
>  drivers/xen/privcmd.c                         |   20 +-
>  drivers/xen/xenbus/xenbus_comms.c             |    2 +-
>  drivers/xen/xenbus/xenbus_probe.c             |   62 +++++--
>  drivers/xen/xenbus/xenbus_probe_frontend.c    |    1 +
>  drivers/xen/xenbus/xenbus_xs.c                |    1 +
>  drivers/xen/xenfs/super.c                     |    7 +
>  include/xen/events.h                          |    2 +
>  include/xen/interface/features.h              |    3 +
>  include/xen/interface/grant_table.h           |    4 +-
>  include/xen/interface/io/protocols.h          |    3 +
>  include/xen/interface/memory.h                |   32 ++-
>  include/xen/interface/physdev.h               |    2 +-
>  include/xen/interface/platform.h              |    4 +-
>  include/xen/interface/version.h               |    2 +-
>  include/xen/interface/xen.h                   |    7 +-
>  include/xen/privcmd.h                         |    3 +-
>  include/xen/xen.h                             |    2 +-
>  45 files changed, 885 insertions(+), 68 deletions(-)
> 
> 
> A branch based on 3.5-rc7 is available here (the __HVC patch is missing
> from this branch because it depends on "ARM: opcodes: Facilitate custom
> opcode injection" http://marc.info/?l=linux-arm-kernel&m=134442896128124):
> 
> git://xenbits.xen.org/people/sstabellini/linux-pvhvm.git 3.5-rc7-arm-3
> 
> Cheers,
> 
> Stefano

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 13 17:32:17 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Sep 2012 17:32:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TCDGj-0002A9-ES; Thu, 13 Sep 2012 17:32:01 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1TCDGi-0002A4-8v
	for xen-devel@lists.xensource.com; Thu, 13 Sep 2012 17:32:00 +0000
Received: from [85.158.139.83:16434] by server-1.bemta-5.messagelabs.com id
	B1/41-32692-F8812505; Thu, 13 Sep 2012 17:31:59 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1347557518!30657768!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDkwMjg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14945 invoked from network); 13 Sep 2012 17:31:58 -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;
	13 Sep 2012 17:31:58 -0000
X-IronPort-AV: E=Sophos;i="4.80,417,1344211200"; d="scan'208";a="14528216"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Sep 2012 17:31: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.279.1; Thu, 13 Sep 2012 18:31: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
	1TCDGf-000084-Tx; Thu, 13 Sep 2012 17:31:57 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1TCDGf-00061A-QH;
	Thu, 13 Sep 2012 18:31:57 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20562.6285.724880.885473@mariner.uk.xensource.com>
Date: Thu, 13 Sep 2012 18:31:57 +0100
To: Thanos Makatos <thanos.makatos@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <f32959a0c14799617f7f.1346862971@makatos-desktop>
References: <f32959a0c14799617f7f.1346862971@makatos-desktop>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] use spaces instead of tabs in vim
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Thanos Makatos writes ("[Xen-devel] [PATCH] use spaces instead of tabs in vim"):
> Tell vim to use spaces instead of tabs for all files residing under
> xen-unstable.hg. Must open files from the top-level directory, otherwise it
> doesn't work.

This is fine by me and looks plausible but I'd like to see a second
opinion from someone who uses vim.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 13 17:32:17 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Sep 2012 17:32:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TCDGj-0002A9-ES; Thu, 13 Sep 2012 17:32:01 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1TCDGi-0002A4-8v
	for xen-devel@lists.xensource.com; Thu, 13 Sep 2012 17:32:00 +0000
Received: from [85.158.139.83:16434] by server-1.bemta-5.messagelabs.com id
	B1/41-32692-F8812505; Thu, 13 Sep 2012 17:31:59 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1347557518!30657768!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDkwMjg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14945 invoked from network); 13 Sep 2012 17:31:58 -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;
	13 Sep 2012 17:31:58 -0000
X-IronPort-AV: E=Sophos;i="4.80,417,1344211200"; d="scan'208";a="14528216"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Sep 2012 17:31: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.279.1; Thu, 13 Sep 2012 18:31: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
	1TCDGf-000084-Tx; Thu, 13 Sep 2012 17:31:57 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1TCDGf-00061A-QH;
	Thu, 13 Sep 2012 18:31:57 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20562.6285.724880.885473@mariner.uk.xensource.com>
Date: Thu, 13 Sep 2012 18:31:57 +0100
To: Thanos Makatos <thanos.makatos@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <f32959a0c14799617f7f.1346862971@makatos-desktop>
References: <f32959a0c14799617f7f.1346862971@makatos-desktop>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] use spaces instead of tabs in vim
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Thanos Makatos writes ("[Xen-devel] [PATCH] use spaces instead of tabs in vim"):
> Tell vim to use spaces instead of tabs for all files residing under
> xen-unstable.hg. Must open files from the top-level directory, otherwise it
> doesn't work.

This is fine by me and looks plausible but I'd like to see a second
opinion from someone who uses vim.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 13 17:36:19 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Sep 2012 17:36:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TCDKX-0002Q4-Kt; Thu, 13 Sep 2012 17:35: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 1TCDKV-0002Pt-SK
	for xen-devel@lists.xensource.com; Thu, 13 Sep 2012 17:35:56 +0000
Received: from [85.158.138.51:44570] by server-6.bemta-3.messagelabs.com id
	29/23-29694-B7912505; Thu, 13 Sep 2012 17:35:55 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1347557753!22348686!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDkwMjg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18900 invoked from network); 13 Sep 2012 17:35:54 -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;
	13 Sep 2012 17:35:54 -0000
X-IronPort-AV: E=Sophos;i="4.80,417,1344211200"; d="scan'208";a="14528257"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Sep 2012 17:35: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.279.1; Thu, 13 Sep 2012 18:35:33 +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 1TCDK8-00009K-JT;
	Thu, 13 Sep 2012 17:35:32 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1TCDK8-0007t1-CE;
	Thu, 13 Sep 2012 18:35:32 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-13725-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 13 Sep 2012 18:35:32 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.1-testing test] 13725: 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 13725 xen-4.1-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13725/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-pcipt-intel  8 debian-fixup                fail like 13657
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 13657

Tests which did not succeed, but are not blocking:
 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-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-win         16 leak-check/check             fail   never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 13 guest-stop               fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel 11 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-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-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-i386-i386-xl-qemuu-winxpsp3 13 guest-stop                 fail never pass

version targeted for testing:
 xen                  c52e7afc96a9
baseline version:
 xen                  3e4782f17f5c

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Keir Fraser <keir@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                                     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=c52e7afc96a9
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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 c52e7afc96a9
+ branch=xen-4.1-testing
+ revision=c52e7afc96a9
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-4.1-testing
+ '[' xxen = xlinux ']'
+ linuxbranch=linux
+ : master
+ : tested/2.6.39.x
+ . ap-common
++ : xen@xenbits.xensource.com
++ : http://xenbits.xen.org/hg/staging/xen-4.1-testing.hg
++ : git://xenbits.xen.org/staging/qemu-xen-4.1-testing.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : xen@xenbits.xensource.com:git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.xen-4.1-testing
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-4.1-testing.git
++ : daily-cron.xen-4.1-testing
+ TREE_LINUX=xen@xenbits.xensource.com:git/linux-pvops.git
+ TREE_QEMU_UPSTREAM=xen@xenbits.xensource.com:git/qemu-upstream-4.1-testing.git
+ info_linux_tree xen-4.1-testing
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/xen-4.1-testing.hg
+ hg push -r c52e7afc96a9 ssh://xen@xenbits.xensource.com/HG/xen-4.1-testing.hg
pushing to ssh://xen@xenbits.xensource.com/HG/xen-4.1-testing.hg
searching for changes
remote: adding changesets
remote: adding manifests
remote: adding file changes
remote: added 2 changesets with 2 changes to 2 files

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 13 17:36:19 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Sep 2012 17:36:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TCDKX-0002Q4-Kt; Thu, 13 Sep 2012 17:35: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 1TCDKV-0002Pt-SK
	for xen-devel@lists.xensource.com; Thu, 13 Sep 2012 17:35:56 +0000
Received: from [85.158.138.51:44570] by server-6.bemta-3.messagelabs.com id
	29/23-29694-B7912505; Thu, 13 Sep 2012 17:35:55 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1347557753!22348686!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDkwMjg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18900 invoked from network); 13 Sep 2012 17:35:54 -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;
	13 Sep 2012 17:35:54 -0000
X-IronPort-AV: E=Sophos;i="4.80,417,1344211200"; d="scan'208";a="14528257"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Sep 2012 17:35: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.279.1; Thu, 13 Sep 2012 18:35:33 +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 1TCDK8-00009K-JT;
	Thu, 13 Sep 2012 17:35:32 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1TCDK8-0007t1-CE;
	Thu, 13 Sep 2012 18:35:32 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-13725-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 13 Sep 2012 18:35:32 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.1-testing test] 13725: 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 13725 xen-4.1-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13725/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-pcipt-intel  8 debian-fixup                fail like 13657
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 13657

Tests which did not succeed, but are not blocking:
 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-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-win         16 leak-check/check             fail   never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 13 guest-stop               fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel 11 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-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-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-i386-i386-xl-qemuu-winxpsp3 13 guest-stop                 fail never pass

version targeted for testing:
 xen                  c52e7afc96a9
baseline version:
 xen                  3e4782f17f5c

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Keir Fraser <keir@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                                     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=c52e7afc96a9
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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 c52e7afc96a9
+ branch=xen-4.1-testing
+ revision=c52e7afc96a9
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-4.1-testing
+ '[' xxen = xlinux ']'
+ linuxbranch=linux
+ : master
+ : tested/2.6.39.x
+ . ap-common
++ : xen@xenbits.xensource.com
++ : http://xenbits.xen.org/hg/staging/xen-4.1-testing.hg
++ : git://xenbits.xen.org/staging/qemu-xen-4.1-testing.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : xen@xenbits.xensource.com:git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.xen-4.1-testing
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-4.1-testing.git
++ : daily-cron.xen-4.1-testing
+ TREE_LINUX=xen@xenbits.xensource.com:git/linux-pvops.git
+ TREE_QEMU_UPSTREAM=xen@xenbits.xensource.com:git/qemu-upstream-4.1-testing.git
+ info_linux_tree xen-4.1-testing
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/xen-4.1-testing.hg
+ hg push -r c52e7afc96a9 ssh://xen@xenbits.xensource.com/HG/xen-4.1-testing.hg
pushing to ssh://xen@xenbits.xensource.com/HG/xen-4.1-testing.hg
searching for changes
remote: adding changesets
remote: adding manifests
remote: adding file changes
remote: added 2 changesets with 2 changes to 2 files

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 13 17:37:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Sep 2012 17: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 1TCDLI-0002UH-2r; Thu, 13 Sep 2012 17:36:44 +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 1TCDLG-0002Tx-GN
	for Xen-devel@lists.xensource.com; Thu, 13 Sep 2012 17:36:42 +0000
Received: from [85.158.139.83:36497] by server-5.bemta-5.messagelabs.com id
	FC/B8-30514-9A912505; Thu, 13 Sep 2012 17:36:41 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-5.tower-182.messagelabs.com!1347557800!30050183!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA0OTk5NTM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26168 invoked from network); 13 Sep 2012 17:36:41 -0000
Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25)
	by server-5.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 13 Sep 2012 17:36:41 -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 BEDFD2EE6;
	Thu, 13 Sep 2012 20:36:39 +0300 (EEST)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id 5BBB02005D; Thu, 13 Sep 2012 20:36:39 +0300 (EEST)
Date: Thu, 13 Sep 2012 20:36:39 +0300
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: Mukesh Rathor <mukesh.rathor@oracle.com>
Message-ID: <20120913173639.GY8912@reaktio.net>
References: <20120815175724.3405043a@mantra.us.oracle.com>
	<1347285352.5305.86.camel@zakaz.uk.xensource.com>
	<20120911145751.599b8292@mantra.us.oracle.com>
	<1347437545.25803.16.camel@dagon.hellion.org.uk>
	<20120912110254.10bde333@mantra.us.oracle.com>
	<1347474380.25803.21.camel@dagon.hellion.org.uk>
	<20120912123238.7057c51a@mantra.us.oracle.com>
	<1347516007.25803.44.camel@dagon.hellion.org.uk>
	<20120913101439.6bd363a9@mantra.us.oracle.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120913101439.6bd363a9@mantra.us.oracle.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: "Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [RFC PATCH 1/8]: PVH: Basic and preparatory changes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Sep 13, 2012 at 10:14:39AM -0700, Mukesh Rathor wrote:
> On Thu, 13 Sep 2012 07:00:07 +0100
> Ian Campbell <Ian.Campbell@citrix.com> wrote:
> 
> > On Wed, 2012-09-12 at 20:32 +0100, Mukesh Rathor wrote:
> > > On Wed, 12 Sep 2012 19:26:20 +0100
> > > Ian Campbell <Ian.Campbell@citrix.com> wrote:
> > > 
> > > > On Wed, 2012-09-12 at 19:02 +0100, Mukesh Rathor wrote:
> > Callback vector is XENFEAT_hvm_callback_vector, I think.
> > 
> > A PV kernel is required to announce the features which it supports via
> > the elf notes (defined in xen-head.S).
> > 
> > It would be a bug for the toolstack to enable PVH mode for a kernel
> > which did not claim to support the required featureset.
> > 
> > The aim should be that the user should not normally need to specify
> > pvh one way or the other, imagine a use case where pygrub is used to
> > boot both old and new kernels using it.
> > 
> > The toolstack (or the dom0 builder) can make the determination whether
> > to enable this mode itself itself based on the notes (although it is
> > always handy to have an override to force things for debug).
> 
> Hmmm... So you are suggesting that if hardware and xen supports it, then
> PV should just boot in PVH mode and user has no way to override it. I
> don't know if that's a good idea in the short term, perhaps in the long
> term. Let me discuss with folks here a bit.
> 

I read that as "if hardware, xen and kernel supports PVH, enable it as a default,
but still allow the user to force enable/disable it in the domain cfgfile for easier debugging".

-- Pasi


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 13 17:37:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Sep 2012 17: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 1TCDLI-0002UH-2r; Thu, 13 Sep 2012 17:36:44 +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 1TCDLG-0002Tx-GN
	for Xen-devel@lists.xensource.com; Thu, 13 Sep 2012 17:36:42 +0000
Received: from [85.158.139.83:36497] by server-5.bemta-5.messagelabs.com id
	FC/B8-30514-9A912505; Thu, 13 Sep 2012 17:36:41 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-5.tower-182.messagelabs.com!1347557800!30050183!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA0OTk5NTM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26168 invoked from network); 13 Sep 2012 17:36:41 -0000
Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25)
	by server-5.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 13 Sep 2012 17:36:41 -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 BEDFD2EE6;
	Thu, 13 Sep 2012 20:36:39 +0300 (EEST)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id 5BBB02005D; Thu, 13 Sep 2012 20:36:39 +0300 (EEST)
Date: Thu, 13 Sep 2012 20:36:39 +0300
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: Mukesh Rathor <mukesh.rathor@oracle.com>
Message-ID: <20120913173639.GY8912@reaktio.net>
References: <20120815175724.3405043a@mantra.us.oracle.com>
	<1347285352.5305.86.camel@zakaz.uk.xensource.com>
	<20120911145751.599b8292@mantra.us.oracle.com>
	<1347437545.25803.16.camel@dagon.hellion.org.uk>
	<20120912110254.10bde333@mantra.us.oracle.com>
	<1347474380.25803.21.camel@dagon.hellion.org.uk>
	<20120912123238.7057c51a@mantra.us.oracle.com>
	<1347516007.25803.44.camel@dagon.hellion.org.uk>
	<20120913101439.6bd363a9@mantra.us.oracle.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120913101439.6bd363a9@mantra.us.oracle.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: "Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [RFC PATCH 1/8]: PVH: Basic and preparatory changes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Sep 13, 2012 at 10:14:39AM -0700, Mukesh Rathor wrote:
> On Thu, 13 Sep 2012 07:00:07 +0100
> Ian Campbell <Ian.Campbell@citrix.com> wrote:
> 
> > On Wed, 2012-09-12 at 20:32 +0100, Mukesh Rathor wrote:
> > > On Wed, 12 Sep 2012 19:26:20 +0100
> > > Ian Campbell <Ian.Campbell@citrix.com> wrote:
> > > 
> > > > On Wed, 2012-09-12 at 19:02 +0100, Mukesh Rathor wrote:
> > Callback vector is XENFEAT_hvm_callback_vector, I think.
> > 
> > A PV kernel is required to announce the features which it supports via
> > the elf notes (defined in xen-head.S).
> > 
> > It would be a bug for the toolstack to enable PVH mode for a kernel
> > which did not claim to support the required featureset.
> > 
> > The aim should be that the user should not normally need to specify
> > pvh one way or the other, imagine a use case where pygrub is used to
> > boot both old and new kernels using it.
> > 
> > The toolstack (or the dom0 builder) can make the determination whether
> > to enable this mode itself itself based on the notes (although it is
> > always handy to have an override to force things for debug).
> 
> Hmmm... So you are suggesting that if hardware and xen supports it, then
> PV should just boot in PVH mode and user has no way to override it. I
> don't know if that's a good idea in the short term, perhaps in the long
> term. Let me discuss with folks here a bit.
> 

I read that as "if hardware, xen and kernel supports PVH, enable it as a default,
but still allow the user to force enable/disable it in the domain cfgfile for easier debugging".

-- Pasi


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 13 17:58:58 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Sep 2012 17: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 1TCDgW-0002nK-2l; Thu, 13 Sep 2012 17:58:40 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1TCDgU-0002nF-Eb
	for xen-devel@lists.xensource.com; Thu, 13 Sep 2012 17:58:38 +0000
Received: from [85.158.143.35:47811] by server-3.bemta-4.messagelabs.com id
	47/A8-08232-DCE12505; Thu, 13 Sep 2012 17:58:37 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1347559117!14897611!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDkwMjg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2577 invoked from network); 13 Sep 2012 17:58:37 -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 Sep 2012 17:58:37 -0000
X-IronPort-AV: E=Sophos;i="4.80,417,1344211200"; d="scan'208";a="14528746"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Sep 2012 17:58: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.279.1; Thu, 13 Sep 2012 18:58:37 +0100
Date: Thu, 13 Sep 2012 18:58:05 +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: <20562.6285.724880.885473@mariner.uk.xensource.com>
Message-ID: <alpine.DEB.2.02.1209131857520.29232@kaball.uk.xensource.com>
References: <f32959a0c14799617f7f.1346862971@makatos-desktop>
	<20562.6285.724880.885473@mariner.uk.xensource.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: Thanos Makatos <thanos.makatos@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] use spaces instead of tabs in vim
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 13 Sep 2012, Ian Jackson wrote:
> Thanos Makatos writes ("[Xen-devel] [PATCH] use spaces instead of tabs in vim"):
> > Tell vim to use spaces instead of tabs for all files residing under
> > xen-unstable.hg. Must open files from the top-level directory, otherwise it
> > doesn't work.
> 
> This is fine by me and looks plausible but I'd like to see a second
> opinion from someone who uses vim.
> 

Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 13 17:58:58 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Sep 2012 17: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 1TCDgW-0002nK-2l; Thu, 13 Sep 2012 17:58:40 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1TCDgU-0002nF-Eb
	for xen-devel@lists.xensource.com; Thu, 13 Sep 2012 17:58:38 +0000
Received: from [85.158.143.35:47811] by server-3.bemta-4.messagelabs.com id
	47/A8-08232-DCE12505; Thu, 13 Sep 2012 17:58:37 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1347559117!14897611!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDkwMjg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2577 invoked from network); 13 Sep 2012 17:58:37 -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 Sep 2012 17:58:37 -0000
X-IronPort-AV: E=Sophos;i="4.80,417,1344211200"; d="scan'208";a="14528746"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Sep 2012 17:58: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.279.1; Thu, 13 Sep 2012 18:58:37 +0100
Date: Thu, 13 Sep 2012 18:58:05 +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: <20562.6285.724880.885473@mariner.uk.xensource.com>
Message-ID: <alpine.DEB.2.02.1209131857520.29232@kaball.uk.xensource.com>
References: <f32959a0c14799617f7f.1346862971@makatos-desktop>
	<20562.6285.724880.885473@mariner.uk.xensource.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: Thanos Makatos <thanos.makatos@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] use spaces instead of tabs in vim
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 13 Sep 2012, Ian Jackson wrote:
> Thanos Makatos writes ("[Xen-devel] [PATCH] use spaces instead of tabs in vim"):
> > Tell vim to use spaces instead of tabs for all files residing under
> > xen-unstable.hg. Must open files from the top-level directory, otherwise it
> > doesn't work.
> 
> This is fine by me and looks plausible but I'd like to see a second
> opinion from someone who uses vim.
> 

Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 13 18:08:24 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Sep 2012 18:08: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 1TCDpf-00034a-Q5; Thu, 13 Sep 2012 18:08: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 1TCDpd-00033e-OB
	for xen-devel@lists.xen.org; Thu, 13 Sep 2012 18:08:06 +0000
Received: from [85.158.143.99:21433] by server-3.bemta-4.messagelabs.com id
	E7/3F-08232-50122505; Thu, 13 Sep 2012 18:08:05 +0000
X-Env-Sender: jean.guyader@citrix.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1347559683!19009430!5
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDkwMjg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13987 invoked from network); 13 Sep 2012 18:08:04 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Sep 2012 18:08:04 -0000
X-IronPort-AV: E=Sophos;i="4.80,417,1344211200"; d="scan'208";a="14528899"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Sep 2012 18:07:24 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Thu, 13 Sep 2012 19:07: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 1TCDoy-0000Jp-Er;
	Thu, 13 Sep 2012 18:07:24 +0000
Received: by spongy (Postfix, from userid 2023)	id 67876340C6D; Thu, 13 Sep
	2012 19:09:34 +0100 (BST)
From: Jean Guyader <jean.guyader@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Thu, 13 Sep 2012 19:09:32 +0100
Message-ID: <1347559772-21817-5-git-send-email-jean.guyader@citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <1347559772-21817-1-git-send-email-jean.guyader@citrix.com>
References: <1347559772-21817-1-git-send-email-jean.guyader@citrix.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="------------true"
Cc: tim@xen.org, Jean Guyader <jean.guyader@citrix.com>, JBeulich@suse.com
Subject: [Xen-devel] [PATCH 4/4] 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                |   13 +-
 xen/common/v4v.c                   | 1907 ++++++++++++++++++++++++++++++=
++++++
 xen/include/public/v4v.h           |  305 ++++++
 xen/include/public/xen.h           |    2 +-
 xen/include/xen/sched.h            |    4 +
 xen/include/xen/v4v.h              |  133 +++
 11 files changed, 2375 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 0576a24..62c636a 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -3134,7 +3134,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__) */
@@ -3219,7 +3220,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)                                        \
@@ -3236,7 +3238,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..5b1f55b 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 5 /* 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..6b838d3 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 5 /* 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 997bc94..e6a7fdd 100644
--- a/xen/arch/x86/x86_64/entry.S
+++ b/xen/arch/x86/x86_64/entry.S
@@ -707,6 +707,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
@@ -755,6 +756,7 @@ ENTRY(hypercall_args_table)
         .byte 1 /* do_domctl            */
         .byte 2 /* do_kexec             */
         .byte 1 /* do_tmem_op           */
+        .byte 5 /* 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 a1aa05e..94283e3 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 err, init_status =3D 0;
     int poolid =3D CPUPOOLID_NONE;
=20
@@ -307,6 +308,13 @@ struct domain *domain_create(
         spin_unlock(&domlist_update_lock);
     }
=20
+    if ( !is_idle_domain(d) )
+    {
+        if ( v4v_init(d) !=3D 0 )
+            goto fail;
+        init_status |=3D INIT_v4v;
+    }
+
     return d;
=20
  fail:
@@ -315,6 +323,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 )
@@ -468,6 +478,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..a6a2648
--- /dev/null
+++ b/xen/common/v4v.c
@@ -0,0 +1,1907 @@
+/***********************************************************************=
*******
+ * 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 <asm/types.h>
+
+#ifdef V4V_DEBUG
+#define v4v_dprintk(format, args...)            \
+    do {                                        \
+        printk("%s:%d " format,                 \
+               __FILE__, __LINE__, ## args );   \
+    } while ( 1 =3D=3D 0 )
+#else
+#define v4v_dprintk(format, ... ) (void)0
+#endif
+
+/*
+ * 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
+ */
+#define V4V_ROUNDUP(a) (((a) +0xf ) & ~0xf)
+
+DEFINE_XEN_GUEST_HANDLE(uint8_t);
+static struct v4v_ring_info *v4v_ring_find_info(struct domain *d,
+                                                v4v_ring_id_t *id);
+
+static struct v4v_ring_info *v4v_ring_find_info_by_addr(struct domain *d=
,
+                                                        struct v4v_addr =
*a,
+                                                        domid_t p);
+
+typedef struct internal_v4v_iov
+{
+    XEN_GUEST_HANDLE(v4v_iov_t) guest_iov;
+    v4v_iov_t                   *xen_iov;
+} internal_v4v_iov_t;
+
+struct list_head viprules =3D LIST_HEAD_INIT(viprules);
+
+/*
+ * 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
+ */
+
+/*
+ * lock to protect the filtering rules list: viprules
+ *
+ * The write lock is held for viptables_del and viptables_add
+ * The read lock is held for viptable_list
+ */
+static DEFINE_RWLOCK(viprules_lock);
+
+
+/*
+ * Debugs
+ */
+
+#ifdef V4V_DEBUG
+static void __attribute__((unused))
+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);
+
+    evtchn_send(d, d->v4v->evtchn_port);
+}
+
+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
+ */
+
+static void
+v4v_ring_unmap(struct v4v_ring_info *ring_info)
+{
+    int i;
+
+    ASSERT(spin_is_locked(&ring_info->lock));
+
+    for ( i =3D 0; i < ring_info->npage; ++i )
+    {
+        if ( !ring_info->mfn_mapping[i] )
+            continue;
+        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;
+    }
+}
+
+static uint8_t *
+v4v_ring_map_page(struct v4v_ring_info *ring_info, int i)
+{
+    ASSERT(spin_is_locked(&ring_info->lock));
+
+    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->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];
+}
+
+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;
+
+    ASSERT(spin_is_locked(&ring_info->lock));
+
+    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;
+}
+
+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);
+    uint32_t *p =3D (uint32_t *)(dst + offsetof(v4v_ring_t, tx_ptr));
+
+    ASSERT(spin_is_locked(&ring_info->lock));
+
+    if ( !dst )
+        return -EFAULT;
+    write_atomic(p, tx_ptr);
+    mb();
+    return 0;
+}
+
+static int
+v4v_copy_from_guest_maybe(void *dst, void *src,
+                          XEN_GUEST_HANDLE(uint8_t) src_hnd,
+                          uint32_t len)
+{
+    int rc =3D 0;
+
+    if ( src )
+        memcpy(dst, src, len);
+    else
+        rc =3D copy_from_guest(dst, src_hnd, len);
+    return rc;
+}
+
+static int
+v4v_memcpy_to_guest_ring(struct v4v_ring_info *ring_info,
+                         uint32_t offset,
+                         void *src,
+                         XEN_GUEST_HANDLE(uint8_t) src_hnd,
+                         uint32_t len)
+{
+    int page =3D offset >> PAGE_SHIFT;
+    uint8_t *dst;
+
+    ASSERT(spin_is_locked(&ring_info->lock));
+
+    offset &=3D PAGE_SIZE - 1;
+
+    while ( (offset + len) > PAGE_SIZE )
+    {
+        dst =3D v4v_ring_map_page(ring_info, page);
+        if ( !dst )
+            return -EFAULT;
+
+        if ( v4v_copy_from_guest_maybe(dst + offset, src, src_hnd,
+                                       PAGE_SIZE - offset) )
+            return -EFAULT;
+
+        page++;
+        len -=3D PAGE_SIZE - offset;
+        if ( src )
+            src +=3D (PAGE_SIZE - offset);
+        else
+            guest_handle_add_offset(src_hnd, PAGE_SIZE - offset);
+        offset =3D 0;
+    }
+
+    dst =3D v4v_ring_map_page(ring_info, page);
+    if ( !dst )
+        return -EFAULT;
+
+    if ( v4v_copy_from_guest_maybe(dst + offset, src, src_hnd, len) )
+        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 =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;
+
+    write_atomic(rx_ptr, ringp->rx_ptr);
+    mb();
+
+    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 =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;
+}
+
+static unsigned long
+v4v_iov_copy(v4v_iov_t *iov, internal_v4v_iov_t *iovs)
+{
+    if (iovs->xen_iov =3D=3D NULL)
+    {
+        return copy_from_guest(iov, iovs->guest_iov, 1);
+    }
+    else
+    {
+        *iov =3D *(iovs->xen_iov);
+        return 0;
+    }
+}
+
+static void
+v4v_iov_add_offset(internal_v4v_iov_t *iovs, int offset)
+{
+    if (iovs->xen_iov =3D=3D NULL)
+        guest_handle_add_offset(iovs->guest_iov, offset);
+    else
+        iovs->xen_iov +=3D offset;
+}
+
+static long
+v4v_iov_count(internal_v4v_iov_t iovs, int niov)
+{
+    v4v_iov_t iov;
+    size_t ret =3D 0;
+
+    while ( niov-- )
+    {
+        if ( v4v_iov_copy(&iov, &iovs) )
+            return -EFAULT;
+
+        /* message bigger than 2G can't be sent */
+        if (ret > 2L * 1024 * 1024 * 1024)
+            return -EMSGSIZE;
+
+        ret +=3D iov.iov_len;
+        v4v_iov_add_offset(&iovs, 1);
+    }
+
+    return ret;
+}
+
+static long
+v4v_ringbuf_insertv(struct domain *d,
+                    struct v4v_ring_info *ring_info,
+                    v4v_ring_id_t *src_id, uint32_t proto,
+                    internal_v4v_iov_t iovs, uint32_t niov,
+                    size_t len)
+{
+    v4v_ring_t ring;
+    struct v4v_ring_message_header mh =3D { 0 };
+    int32_t sp;
+    long happy_ret;
+    int32_t ret =3D 0;
+    XEN_GUEST_HANDLE(uint8_t) empty_hnd =3D { 0 };
+
+    ASSERT(spin_is_locked(&ring_info->lock));
+
+    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.message_type =3D proto;
+
+        if ( (ret =3D v4v_memcpy_to_guest_ring(ring_info,
+                                             ring.tx_ptr + sizeof (v4v_r=
ing_t),
+                                             &mh, empty_hnd,
+                                             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 ( v4v_iov_copy(&iov, &iovs) )
+            {
+                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 )
+            {
+                ret =3D v4v_memcpy_to_guest_ring(ring_info,
+                        ring.tx_ptr + sizeof (v4v_ring_t),
+                        NULL, buf_hnd, sp);
+                if ( ret )
+                    break;
+
+                ring.tx_ptr =3D 0;
+                len -=3D sp;
+                guest_handle_add_offset(buf_hnd, sp);
+            }
+
+            ret =3D v4v_memcpy_to_guest_ring(ring_info,
+                    ring.tx_ptr + sizeof (v4v_ring_t),
+                    NULL, buf_hnd, len);
+            if ( ret )
+                break;
+
+            ring.tx_ptr +=3D len;
+
+            if ( ring.tx_ptr =3D=3D ring_info->len )
+                ring.tx_ptr =3D 0;
+
+            v4v_iov_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);
+}
+
+static void
+v4v_pending_remove_all(struct v4v_ring_info *info)
+{
+    struct hlist_node *node, *next;
+    struct v4v_pending_ent *pending_ent;
+
+    ASSERT(spin_is_locked(&info->lock));
+    hlist_for_each_entry_safe(pending_ent, node, next, &info->pending,
+            node) v4v_pending_remove_ent(pending_ent);
+}
+
+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;
+
+    ASSERT(rw_is_locked(&v4v_lock));
+
+    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);
+    }
+
+}
+
+static void
+v4v_pending_find(struct domain *d, 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;
+
+    ASSERT(rw_is_locked(&d->v4v->lock));
+
+    spin_lock(&ring_info->lock);
+    hlist_for_each_entry_safe(ent, node, next, &ring_info->pending, node=
)
+    {
+        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 l=
en)
+{
+    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, int=
 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, node=
)
+    {
+        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(xen_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);
+    }
+    return ret;
+}
+
+
+static struct v4v_ring_info *
+v4v_ring_find_info(struct domain *d, v4v_ring_id_t *id)
+{
+    uint16_t hash;
+    struct hlist_node *node;
+    struct v4v_ring_info *ring_info;
+
+    ASSERT(rw_is_locked(&d->v4v->lock));
+
+    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], node=
)
+    {
+        v4v_ring_id_t *cmpid =3D &ring_info->id;
+
+        if ( cmpid->addr.port =3D=3D id->addr.port &&
+             cmpid->addr.domain =3D=3D id->addr.domain &&
+             cmpid->partner =3D=3D id->partner)
+        {
+            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;
+}
+
+static struct v4v_ring_info *
+v4v_ring_find_info_by_addr(struct domain *d, struct v4v_addr *a, domid_t=
 p)
+{
+    v4v_ring_id_t id;
+    struct v4v_ring_info *ret;
+
+    ASSERT(rw_is_locked(&d->v4v->lock));
+
+    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_ANY;
+
+    return v4v_ring_find_info(d, &id);
+}
+
+static void v4v_ring_remove_mfns(struct domain *d, struct v4v_ring_info =
*ring_info)
+{
+    int i;
+
+    ASSERT(rw_is_write_locked(&d->v4v->lock));
+
+    if ( ring_info->mfns )
+    {
+        for ( i =3D 0; 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);
+    }
+    if ( ring_info->mfn_mapping )
+        xfree(ring_info->mfn_mapping);
+    ring_info->mfns =3D NULL;
+
+}
+
+static void
+v4v_ring_remove_info(struct domain *d, struct v4v_ring_info *ring_info)
+{
+    ASSERT(rw_is_write_locked(&d->v4v->lock));
+
+    spin_lock(&ring_info->lock);
+
+    v4v_pending_remove_all(ring_info);
+    hlist_del(&ring_info->node);
+    v4v_ring_remove_mfns(d, ring_info);
+
+    spin_unlock(&ring_info->lock);
+
+    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 =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(d, 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(xen_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 rin=
g.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 ring already registered\n",
+                    current->domain->domain_id);
+            ret =3D -EEXIST;
+            break;
+        }
+
+        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
+ */
+
+static void
+v4v_notify_ring(struct domain *d, struct v4v_ring_info *ring_info,
+                struct hlist_head *to_notify)
+{
+    uint32_t space;
+
+    ASSERT(rw_is_locked(&v4v_lock));
+    ASSERT(rw_is_locked(&d->v4v->lock));
+
+    spin_lock(&ring_info->lock);
+    space =3D v4v_ringbuf_payload_space(d, ring_info);
+    spin_unlock(&ring_info->lock);
+
+    v4v_pending_find(d, 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, data[0]);
+                ret =3D v4v_fill_ring_datas(d, ring_data.nent, ring_data=
_ent_hnd);
+            }
+        }
+    }
+    while ( 0 );
+
+    read_unlock(&v4v_lock);
+
+    return ret;
+}
+
+#ifdef V4V_DEBUG
+void
+v4v_viptables_print_rule(struct v4v_viptables_rule_node *node)
+{
+    v4v_viptables_rule_t *rule;
+
+    if ( node =3D=3D NULL )
+    {
+        printk("(null)\n");
+        return;
+    }
+
+    rule =3D &node->rule;
+
+    if ( rule->accept =3D=3D 1 )
+        printk("ACCEPT");
+    else
+        printk("REJECT");
+
+    printk(" ");
+
+    if ( rule->src.domain =3D=3D V4V_DOMID_ANY )
+        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 V4V_DOMID_ANY )
+        printk("*");
+    else
+        printk("%i", rule->dst.domain);
+
+    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 =3D NULL;
+    struct list_head* tmp;
+
+    ASSERT(rw_is_write_locked(&viprules_lock));
+
+    /* First rule is n.1 */
+    position--;
+
+    new =3D xmalloc(struct v4v_viptables_rule_node);
+    if ( new =3D=3D NULL )
+        return -ENOMEM;
+
+    if ( copy_from_guest(&new->rule, rule, 1) )
+    {
+        xfree(new);
+        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_hnd,
+                  int32_t position)
+{
+    struct list_head *tmp =3D NULL;
+    struct list_head *next =3D NULL;
+    struct v4v_viptables_rule_node *node;
+
+    ASSERT(rw_is_write_locked(&viprules_lock));
+
+    v4v_dprintk("v4v_viptables_del position:%d\n", position);
+
+    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_hnd) )
+    {
+        struct v4v_viptables_rule r;
+
+        if ( copy_from_guest(&r, rule_hnd, 1) )
+            return -EFAULT;
+
+        list_for_each(tmp, &viprules)
+        {
+            node =3D list_entry(tmp, struct v4v_viptables_rule_node, lis=
t);
+
+            if ( (node->rule.src.domain =3D=3D r.src.domain) &&
+                 (node->rule.src.port   =3D=3D r.src.port)   &&
+                 (node->rule.dst.domain =3D=3D r.dst.domain) &&
+                 (node->rule.dst.port   =3D=3D r.dst.port))
+            {
+                position =3D 0;
+                break;
+            }
+        }
+    }
+    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, lis=
t);
+            list_del(tmp);
+            xfree(node);
+        }
+    }
+
+    if ( position =3D=3D 0 && tmp !=3D &viprules )
+    {
+        node =3D list_entry(tmp, struct v4v_viptables_rule_node, list);
+#ifdef V4V_DEBUG
+        printk(KERN_ERR "VIPTables: deleting rule: ");
+        v4v_viptables_print_rule(node);
+#endif /* V4V_DEBUG */
+        list_del(tmp);
+        xfree(node);
+    }
+
+    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;
+    XEN_GUEST_HANDLE(v4v_viptables_rule_t) guest_rules;
+
+    ASSERT(rw_is_locked(&viprules_lock));
+
+    memset(&rules_list, 0, sizeof (rules_list));
+    if ( copy_from_guest(&rules_list, list_hnd, 1) )
+        return -EFAULT;
+
+    ptr =3D viprules.next;
+    while ( rules_list.start_rule !=3D 0 && ptr->next !=3D &viprules )
+    {
+        ptr =3D ptr->next;
+        rules_list.start_rule--;
+    }
+
+    if ( rules_list.nb_rules =3D=3D 0 )
+        return -EINVAL;
+
+    guest_rules =3D guest_handle_for_field(list_hnd, v4v_viptables_rule_=
t, rules[0]);
+
+    nbrules =3D 0;
+    while ( nbrules < rules_list.nb_rules && ptr !=3D &viprules )
+    {
+        node =3D list_entry(ptr, struct v4v_viptables_rule_node, list);
+
+        if ( !guest_handle_okay(guest_rules, 1) )
+            break;
+
+        if ( copy_to_guest(guest_rules, &node->rule, 1) )
+            break;
+
+        guest_handle_add_offset(guest_rules, 1);
+
+        nbrules++;
+        ptr =3D ptr->next;
+    }
+
+    rules_list.nb_rules =3D nbrules;
+    if ( copy_field_to_guest(list_hnd, &rules_list, nb_rules) )
+        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;
+    size_t ret =3D 0; /* Defaulting to ACCEPT */
+
+    read_lock(&viprules_lock);
+
+    list_for_each(ptr, &viprules)
+    {
+        node =3D list_entry(ptr, struct v4v_viptables_rule_node, list);
+
+        if ( (node->rule.src.domain =3D=3D V4V_DOMID_ANY ||
+              node->rule.src.domain =3D=3D src->domain) &&
+             (node->rule.src.port =3D=3D V4V_PORT_ANY ||
+              node->rule.src.port =3D=3D src->port) &&
+             (node->rule.dst.domain =3D=3D V4V_DOMID_ANY ||
+              node->rule.dst.domain =3D=3D dst->domain) &&
+             (node->rule.dst.port =3D=3D V4V_PORT_ANY ||
+              node->rule.dst.port =3D=3D dst->port) )
+        {
+            ret =3D !node->rule.accept;
+            break;
+        }
+    }
+
+    read_unlock(&viprules_lock);
+    return ret;
+}
+
+/*
+ * Hypercall to do the send
+ */
+static long
+v4v_sendv(struct domain *src_d, v4v_addr_t * src_addr,
+          v4v_addr_t * dst_addr, uint32_t proto,
+          internal_v4v_iov_t iovs, size_t niov)
+{
+    struct domain *dst_d;
+    v4v_ring_id_t 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;
+    }
+
+    if ( v4v_viptables_check(src_addr, dst_addr) !=3D 0 )
+    {
+        read_unlock(&v4v_lock);
+        gdprintk(XENLOG_WARNING,
+                 "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 )
+        {
+            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->domain=
);
+
+        if ( !ring_info )
+        {
+            ret =3D -ECONNREFUSED;
+            v4v_dprintk(" !ring_info, ECONNREFUSED\n");
+        }
+        else
+        {
+            long 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, io=
vs,
+                        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;
+}
+
+static void
+v4v_info(struct domain *d, v4v_info_t *info)
+{
+    read_lock(&d->v4v->lock);
+    info->ring_magic =3D V4V_RING_MAGIC;
+    info->data_magic =3D V4V_RING_DATA_MAGIC;
+    info->evtchn =3D d->v4v->evtchn_port;
+    read_unlock(&d->v4v->lock);
+}
+
+/*
+ * hypercall glue
+ */
+long
+do_v4v_op(int cmd, XEN_GUEST_HANDLE(void) arg1,
+          XEN_GUEST_HANDLE(void) arg2,
+          uint32_t arg3, uint32_t arg4)
+{
+    struct domain *d =3D current->domain;
+    long rc =3D -EFAULT;
+
+    v4v_dprintk("->do_v4v_op(%d,%p,%p,%d,%d)\n", cmd,
+                (void *)arg1.p, (void *)arg2.p, (int) arg3, (int) arg4);
+
+    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(xen_pfn_t) pfn_hnd =3D
+                    guest_handle_cast(arg2, xen_pfn_t);
+                uint32_t npage =3D arg3;
+                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:
+            {
+                uint32_t len =3D arg3;
+                uint32_t message_type =3D arg4;
+                v4v_iov_t iov;
+                internal_v4v_iov_t iovs;
+                XEN_GUEST_HANDLE(v4v_send_addr_t) addr_hnd =3D
+                    guest_handle_cast(arg1, v4v_send_addr_t);
+                v4v_send_addr_t addr;
+
+                if ( unlikely(!guest_handle_okay(addr_hnd, 1)) )
+                    goto out;
+                if ( copy_from_guest(&addr, addr_hnd, 1) )
+                    goto out;
+
+                iov.iov_base =3D (uint64_t)arg2.p; // FIXME
+                iov.iov_len =3D len;
+                iovs.xen_iov =3D &iov;
+                rc =3D v4v_sendv(d, &addr.src, &addr.dst, message_type, =
iovs, 1);
+                break;
+            }
+        case V4VOP_sendv:
+            {
+                internal_v4v_iov_t iovs;
+                uint32_t niov =3D arg3;
+                uint32_t message_type =3D arg4;
+                XEN_GUEST_HANDLE(v4v_send_addr_t) addr_hnd =3D
+                    guest_handle_cast(arg1, v4v_send_addr_t);
+                v4v_send_addr_t addr;
+
+                memset(&iovs, 0, sizeof (iovs));
+                iovs.guest_iov =3D guest_handle_cast(arg2, v4v_iov_t);
+
+                if ( unlikely(!guest_handle_okay(addr_hnd, 1)) )
+                    goto out;
+                if ( copy_from_guest(&addr, addr_hnd, 1) )
+                    goto out;
+
+                if ( unlikely(!guest_handle_okay(iovs.guest_iov, niov)) =
)
+                    goto out;
+
+                rc =3D v4v_sendv(d, &addr.src, &addr.dst, message_type, =
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;
+            }
+        case V4VOP_viptables_add:
+            {
+                uint32_t position =3D arg3;
+                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;
+
+                write_lock(&viprules_lock);
+                rc =3D v4v_viptables_add(d, rule_hnd, position);
+                write_unlock(&viprules_lock);
+                break;
+            }
+        case V4VOP_viptables_del:
+            {
+                uint32_t position =3D arg3;
+                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;
+
+                write_lock(&viprules_lock);
+                rc =3D v4v_viptables_del(d, rule_hnd, position);
+                write_unlock(&viprules_lock);
+                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 -EFAULT;
+                if ( unlikely(!guest_handle_okay(rules_list_hnd, 1)) )
+                    goto out;
+
+                read_lock(&viprules_lock);
+                rc =3D v4v_viptables_list(d, rules_list_hnd);
+                read_unlock(&viprules_lock);
+                break;
+            }
+        case V4VOP_info:
+            {
+                XEN_GUEST_HANDLE(v4v_info_t) info_hnd =3D
+                    guest_handle_cast(arg1, v4v_info_t);
+                v4v_info_t info;
+
+                if ( unlikely(!guest_handle_okay(info_hnd, 1)) )
+                    goto out;
+                v4v_info(d, &info);
+                if ( copy_to_guest(info_hnd, &info, 1) )
+                    goto out;
+                rc =3D 0;
+                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(d, ring_info);
+            }
+        }
+    }
+
+    d->v4v =3D NULL;
+    write_unlock(&v4v_lock);
+}
+
+int
+v4v_init(struct domain *d)
+{
+    struct v4v_domain *v4v;
+    evtchn_port_t port;
+    int i;
+    int rc;
+
+    v4v =3D xmalloc(struct v4v_domain);
+    if ( !v4v )
+        return -ENOMEM;
+
+    rc =3D evtchn_alloc_unbound_domain(d, &port, d->domain_id);
+    if ( rc )
+        return rc;
+
+    rwlock_init(&v4v->lock);
+
+    v4v->evtchn_port =3D port;
+    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 npage=
=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(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], nod=
e)
+            dump_domain_ring(d, ring_info);
+    }
+
+    printk(KERN_ERR "  event channel: %d\n",  d->v4v->evtchn_port);
+    read_unlock(&d->v4v->lock);
+
+    printk(KERN_ERR "\n");
+    v4v_signal_domain(d);
+}
+
+static void
+dump_state(unsigned char key)
+{
+    struct domain *d;
+
+    printk(KERN_ERR "\n\nV4V:\n");
+    read_lock(&v4v_lock);
+
+    rcu_read_lock(&domlist_read_lock);
+
+    for_each_domain(d)
+        dump_domain(d);
+
+    rcu_read_unlock(&domlist_read_lock);
+
+    read_unlock(&v4v_lock);
+}
+
+struct keyhandler v4v_info_keyhandler =3D
+{
+    .diagnostic =3D 1,
+    .u.fn =3D dump_state,
+    .desc =3D "dump v4v states and interupt"
+};
+
+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..ad8bb0e
--- /dev/null
+++ b/xen/include/public/v4v.h
@@ -0,0 +1,305 @@
+/***********************************************************************=
*******
+ * 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"
+#include "event_channel.h"
+
+/*
+ * Structure definitions
+ */
+
+#define V4V_RING_MAGIC          0xA822f72bb0b9d8ccULL
+#define V4V_RING_DATA_MAGIC	0x45fe852220b801d4ULL
+
+#define V4V_MESSAGE_DGRAM       0x3c2c1db8
+#define V4V_MESSAGE_STREAM 	0x70f6a8e5
+
+#define V4V_DOMID_ANY           DOMID_INVALID
+#define V4V_PORT_ANY            0
+
+typedef struct v4v_iov
+{
+    uint64_t iov_base;
+    uint32_t iov_len;
+} v4v_iov_t;
+
+typedef struct v4v_addr
+{
+    uint32_t port;
+    domid_t domain;
+    uint16_t pad;
+} v4v_addr_t;
+
+typedef struct v4v_ring_id
+{
+    v4v_addr_t addr;
+    domid_t partner;
+    uint16_t pad;
+} v4v_ring_id_t;
+
+typedef struct
+{
+    v4v_addr_t src;
+    v4v_addr_t dst;
+} v4v_send_addr_t;
+
+/*
+ * v4v_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
+ *
+ */
+struct v4v_ring
+{
+    uint64_t magic;
+    v4v_ring_id_t id;
+    uint32_t len;
+    uint32_t rx_ptr;
+    uint32_t tx_ptr;
+    uint8_t reserved[32];
+    uint8_t ring[0];
+};
+typedef struct v4v_ring v4v_ring_t;
+
+#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 exist=
s - do not
+                                               * rely on this field - fo=
r
+                                               * profiling only */
+#define V4V_RING_DATA_F_SUFFICIENT  (1U << 3) /* Sufficient space to que=
ue
+                                               * space_required bytes ex=
ists */
+
+typedef struct v4v_ring_data_ent
+{
+    v4v_addr_t ring;
+    uint16_t flags;
+    uint16_t pad;
+    uint32_t space_required;
+    uint32_t max_message_size;
+} v4v_ring_data_ent_t;
+
+typedef struct v4v_ring_data
+{
+    uint64_t magic;
+    uint32_t nent;
+    uint32_t pad;
+    uint64_t reserved[4];
+    v4v_ring_data_ent_t data[0];
+} v4v_ring_data_t;
+
+struct v4v_info
+{
+    uint64_t ring_magic;
+    uint64_t data_magic;
+    evtchn_port_t evtchn;
+    uint32_t pad;
+};
+typedef struct v4v_info v4v_info_t;
+
+#define V4V_SHF_SYN		(1 << 0)
+#define V4V_SHF_ACK		(1 << 1)
+#define V4V_SHF_RST		(1 << 2)
+
+#define V4V_SHF_PING		(1 << 8)
+#define V4V_SHF_PONG		(1 << 9)
+
+struct v4v_stream_header
+{
+    uint32_t flags;
+    uint32_t conid;
+};
+
+struct v4v_ring_message_header
+{
+    uint32_t len;
+    uint32_t pad0;
+    v4v_addr_t source;
+    uint32_t message_type;
+    uint32_t pad1;
+    uint8_t data[0];
+};
+
+typedef struct v4v_viptables_rule
+{
+    v4v_addr_t src;
+    v4v_addr_t dst;
+    uint32_t accept;
+    uint32_t pad;
+} v4v_viptables_rule_t;
+
+typedef struct v4v_viptables_list
+{
+    uint32_t start_rule;
+    uint32_t nb_rules;
+    struct v4v_viptables_rule rules[0];
+} v4v_viptables_list_t;
+
+/*
+ * HYPERCALLS
+ */
+
+/*
+ * V4VOP_register_ring
+ *
+ * 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(xen_pfn_t),
+ *           npage, 0)
+ */
+#define V4VOP_register_ring 	1
+
+
+/*
+ * V4VOP_unregister_ring
+ *
+ * Unregister a ring.
+ *
+ * do_v4v_op(V4VOP_send, v4v_ring, NULL, 0, 0)
+ */
+#define V4VOP_unregister_ring 	2
+
+/*
+ * V4VOP_send
+ *
+ * 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.
+ * message_type is the 32 bit number used from the message
+ * most likely V4V_MESSAGE_DGRAM or V4V_MESSAGE_STREAM. If insufficient =
space exists
+ * it will return -EAGAIN and xen will twing the V4V_INTERRUPT when
+ * sufficient space becomes available
+ *
+ * do_v4v_op(V4VOP_send,
+ *           v4v_send_addr_t addr,
+ *           void* buf,
+ *           uint32_t len,
+ *           uint32_t message_type)
+ */
+#define V4VOP_send 		3
+
+
+/*
+ * V4VOP_notify
+ *
+ * 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
+ *
+ * do_v4v_op(V4VOP_notify,
+ *           XEN_GUEST_HANDLE(v4v_ring_data_ent) ent,
+ *           NULL, nent, 0)
+ */
+#define V4VOP_notify 		4
+
+/*
+ * V4VOP_sendv
+ *
+ * Identical to V4VOP_send except rather than buf and len it takes
+ * an array of v4v_iov and a length of the array.
+ *
+ * do_v4v_op(V4VOP_sendv,
+ *           v4v_send_addr_t addr,
+ *           v4v_iov iov,
+ *           uint32_t niov,
+ *           uint32_t message_type)
+ */
+#define V4VOP_sendv		5
+
+/*
+ * V4VOP_viptables_add
+ *
+ * Insert a filtering rules after a given position.
+ *
+ * do_v4v_op(V4VOP_viptables_add,
+ *           v4v_viptables_rule_t rule,
+ *           NULL,
+ *           uint32_t position, 0)
+ */
+#define V4VOP_viptables_add     6
+
+/*
+ * V4VOP_viptables_del
+ *
+ * Delete a filtering rules at a position or the rule
+ * that matches "rule".
+ *
+ * do_v4v_op(V4VOP_viptables_del,
+ *           v4v_viptables_rule_t rule,
+ *           NULL,
+ *           uint32_t position, 0)
+ */
+#define V4VOP_viptables_del     7
+
+/*
+ * V4VOP_viptables_list
+ *
+ * Delete a filtering rules at a position or the rule
+ * that matches "rule".
+ *
+ * do_v4v_op(V4VOP_viptables_list,
+ *               v4v_vitpables_list_t list,
+ *               NULL, 0, 0)
+ */
+#define V4VOP_viptables_list    8
+
+/*
+ * V4VOP_info
+ *
+ * Returns v4v info for the current domain (domain that issued the hyper=
call).
+ *      - V4V magic number
+ *      - event channel port (for current domain)
+ *
+ * do_v4v_op(V4VOP_info,
+ *           XEN_GUEST_HANDLE(v4v_info_t) info,
+ *           NULL, 0, 0)
+ */
+#define V4VOP_info              9
+
+#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 b19425b..868d119 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..296de52 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,9 @@ struct domain
     nodemask_t node_affinity;
     unsigned int last_alloc_node;
     spinlock_t node_affinity_lock;
+
+    /* v4v */
+    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..05d20b5
--- /dev/null
+++ b/xen/include/xen/v4v.h
@@ -0,0 +1,133 @@
+/***********************************************************************=
*******
+ * 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
+
+/*
+ * Handlers
+ */
+
+DEFINE_XEN_GUEST_HANDLE (v4v_iov_t);
+DEFINE_XEN_GUEST_HANDLE (v4v_addr_t);
+DEFINE_XEN_GUEST_HANDLE (v4v_send_addr_t);
+DEFINE_XEN_GUEST_HANDLE (v4v_ring_t);
+DEFINE_XEN_GUEST_HANDLE (v4v_ring_data_ent_t);
+DEFINE_XEN_GUEST_HANDLE (v4v_ring_data_t);
+DEFINE_XEN_GUEST_HANDLE (v4v_info_t);
+
+DEFINE_XEN_GUEST_HANDLE (v4v_viptables_rule_t);
+DEFINE_XEN_GUEST_HANDLE (v4v_viptables_list_t);
+
+/*
+ * Helper functions
+ */
+
+static inline uint16_t
+v4v_hash_fn (v4v_ring_id_t *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;
+};
+
+
+struct v4v_ring_info
+{
+    /* next node in the hash, protected by L2  */
+    struct hlist_node node;
+    /* this ring's id, protected by L2 */
+    v4v_ring_id_t 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;
+    /* event channel */
+    evtchn_port_t evtchn_port;
+    /* protected by L2 */
+    struct hlist_head ring_hash[V4V_HTABLE_SIZE];
+};
+
+typedef struct v4v_viptables_rule_node
+{
+    struct list_head list;
+    v4v_viptables_rule_t rule;
+} v4v_viptables_rule_node_t;
+
+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,
+                uint32_t arg3,
+                uint32_t arg4);
+
+#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 Sep 13 18:08:24 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Sep 2012 18:08: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 1TCDpf-00034a-Q5; Thu, 13 Sep 2012 18:08: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 1TCDpd-00033e-OB
	for xen-devel@lists.xen.org; Thu, 13 Sep 2012 18:08:06 +0000
Received: from [85.158.143.99:21433] by server-3.bemta-4.messagelabs.com id
	E7/3F-08232-50122505; Thu, 13 Sep 2012 18:08:05 +0000
X-Env-Sender: jean.guyader@citrix.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1347559683!19009430!5
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDkwMjg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13987 invoked from network); 13 Sep 2012 18:08:04 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Sep 2012 18:08:04 -0000
X-IronPort-AV: E=Sophos;i="4.80,417,1344211200"; d="scan'208";a="14528899"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Sep 2012 18:07:24 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Thu, 13 Sep 2012 19:07: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 1TCDoy-0000Jp-Er;
	Thu, 13 Sep 2012 18:07:24 +0000
Received: by spongy (Postfix, from userid 2023)	id 67876340C6D; Thu, 13 Sep
	2012 19:09:34 +0100 (BST)
From: Jean Guyader <jean.guyader@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Thu, 13 Sep 2012 19:09:32 +0100
Message-ID: <1347559772-21817-5-git-send-email-jean.guyader@citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <1347559772-21817-1-git-send-email-jean.guyader@citrix.com>
References: <1347559772-21817-1-git-send-email-jean.guyader@citrix.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="------------true"
Cc: tim@xen.org, Jean Guyader <jean.guyader@citrix.com>, JBeulich@suse.com
Subject: [Xen-devel] [PATCH 4/4] 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                |   13 +-
 xen/common/v4v.c                   | 1907 ++++++++++++++++++++++++++++++=
++++++
 xen/include/public/v4v.h           |  305 ++++++
 xen/include/public/xen.h           |    2 +-
 xen/include/xen/sched.h            |    4 +
 xen/include/xen/v4v.h              |  133 +++
 11 files changed, 2375 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 0576a24..62c636a 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -3134,7 +3134,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__) */
@@ -3219,7 +3220,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)                                        \
@@ -3236,7 +3238,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..5b1f55b 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 5 /* 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..6b838d3 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 5 /* 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 997bc94..e6a7fdd 100644
--- a/xen/arch/x86/x86_64/entry.S
+++ b/xen/arch/x86/x86_64/entry.S
@@ -707,6 +707,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
@@ -755,6 +756,7 @@ ENTRY(hypercall_args_table)
         .byte 1 /* do_domctl            */
         .byte 2 /* do_kexec             */
         .byte 1 /* do_tmem_op           */
+        .byte 5 /* 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 a1aa05e..94283e3 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 err, init_status =3D 0;
     int poolid =3D CPUPOOLID_NONE;
=20
@@ -307,6 +308,13 @@ struct domain *domain_create(
         spin_unlock(&domlist_update_lock);
     }
=20
+    if ( !is_idle_domain(d) )
+    {
+        if ( v4v_init(d) !=3D 0 )
+            goto fail;
+        init_status |=3D INIT_v4v;
+    }
+
     return d;
=20
  fail:
@@ -315,6 +323,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 )
@@ -468,6 +478,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..a6a2648
--- /dev/null
+++ b/xen/common/v4v.c
@@ -0,0 +1,1907 @@
+/***********************************************************************=
*******
+ * 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 <asm/types.h>
+
+#ifdef V4V_DEBUG
+#define v4v_dprintk(format, args...)            \
+    do {                                        \
+        printk("%s:%d " format,                 \
+               __FILE__, __LINE__, ## args );   \
+    } while ( 1 =3D=3D 0 )
+#else
+#define v4v_dprintk(format, ... ) (void)0
+#endif
+
+/*
+ * 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
+ */
+#define V4V_ROUNDUP(a) (((a) +0xf ) & ~0xf)
+
+DEFINE_XEN_GUEST_HANDLE(uint8_t);
+static struct v4v_ring_info *v4v_ring_find_info(struct domain *d,
+                                                v4v_ring_id_t *id);
+
+static struct v4v_ring_info *v4v_ring_find_info_by_addr(struct domain *d=
,
+                                                        struct v4v_addr =
*a,
+                                                        domid_t p);
+
+typedef struct internal_v4v_iov
+{
+    XEN_GUEST_HANDLE(v4v_iov_t) guest_iov;
+    v4v_iov_t                   *xen_iov;
+} internal_v4v_iov_t;
+
+struct list_head viprules =3D LIST_HEAD_INIT(viprules);
+
+/*
+ * 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
+ */
+
+/*
+ * lock to protect the filtering rules list: viprules
+ *
+ * The write lock is held for viptables_del and viptables_add
+ * The read lock is held for viptable_list
+ */
+static DEFINE_RWLOCK(viprules_lock);
+
+
+/*
+ * Debugs
+ */
+
+#ifdef V4V_DEBUG
+static void __attribute__((unused))
+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);
+
+    evtchn_send(d, d->v4v->evtchn_port);
+}
+
+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
+ */
+
+static void
+v4v_ring_unmap(struct v4v_ring_info *ring_info)
+{
+    int i;
+
+    ASSERT(spin_is_locked(&ring_info->lock));
+
+    for ( i =3D 0; i < ring_info->npage; ++i )
+    {
+        if ( !ring_info->mfn_mapping[i] )
+            continue;
+        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;
+    }
+}
+
+static uint8_t *
+v4v_ring_map_page(struct v4v_ring_info *ring_info, int i)
+{
+    ASSERT(spin_is_locked(&ring_info->lock));
+
+    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->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];
+}
+
+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;
+
+    ASSERT(spin_is_locked(&ring_info->lock));
+
+    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;
+}
+
+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);
+    uint32_t *p =3D (uint32_t *)(dst + offsetof(v4v_ring_t, tx_ptr));
+
+    ASSERT(spin_is_locked(&ring_info->lock));
+
+    if ( !dst )
+        return -EFAULT;
+    write_atomic(p, tx_ptr);
+    mb();
+    return 0;
+}
+
+static int
+v4v_copy_from_guest_maybe(void *dst, void *src,
+                          XEN_GUEST_HANDLE(uint8_t) src_hnd,
+                          uint32_t len)
+{
+    int rc =3D 0;
+
+    if ( src )
+        memcpy(dst, src, len);
+    else
+        rc =3D copy_from_guest(dst, src_hnd, len);
+    return rc;
+}
+
+static int
+v4v_memcpy_to_guest_ring(struct v4v_ring_info *ring_info,
+                         uint32_t offset,
+                         void *src,
+                         XEN_GUEST_HANDLE(uint8_t) src_hnd,
+                         uint32_t len)
+{
+    int page =3D offset >> PAGE_SHIFT;
+    uint8_t *dst;
+
+    ASSERT(spin_is_locked(&ring_info->lock));
+
+    offset &=3D PAGE_SIZE - 1;
+
+    while ( (offset + len) > PAGE_SIZE )
+    {
+        dst =3D v4v_ring_map_page(ring_info, page);
+        if ( !dst )
+            return -EFAULT;
+
+        if ( v4v_copy_from_guest_maybe(dst + offset, src, src_hnd,
+                                       PAGE_SIZE - offset) )
+            return -EFAULT;
+
+        page++;
+        len -=3D PAGE_SIZE - offset;
+        if ( src )
+            src +=3D (PAGE_SIZE - offset);
+        else
+            guest_handle_add_offset(src_hnd, PAGE_SIZE - offset);
+        offset =3D 0;
+    }
+
+    dst =3D v4v_ring_map_page(ring_info, page);
+    if ( !dst )
+        return -EFAULT;
+
+    if ( v4v_copy_from_guest_maybe(dst + offset, src, src_hnd, len) )
+        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 =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;
+
+    write_atomic(rx_ptr, ringp->rx_ptr);
+    mb();
+
+    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 =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;
+}
+
+static unsigned long
+v4v_iov_copy(v4v_iov_t *iov, internal_v4v_iov_t *iovs)
+{
+    if (iovs->xen_iov =3D=3D NULL)
+    {
+        return copy_from_guest(iov, iovs->guest_iov, 1);
+    }
+    else
+    {
+        *iov =3D *(iovs->xen_iov);
+        return 0;
+    }
+}
+
+static void
+v4v_iov_add_offset(internal_v4v_iov_t *iovs, int offset)
+{
+    if (iovs->xen_iov =3D=3D NULL)
+        guest_handle_add_offset(iovs->guest_iov, offset);
+    else
+        iovs->xen_iov +=3D offset;
+}
+
+static long
+v4v_iov_count(internal_v4v_iov_t iovs, int niov)
+{
+    v4v_iov_t iov;
+    size_t ret =3D 0;
+
+    while ( niov-- )
+    {
+        if ( v4v_iov_copy(&iov, &iovs) )
+            return -EFAULT;
+
+        /* message bigger than 2G can't be sent */
+        if (ret > 2L * 1024 * 1024 * 1024)
+            return -EMSGSIZE;
+
+        ret +=3D iov.iov_len;
+        v4v_iov_add_offset(&iovs, 1);
+    }
+
+    return ret;
+}
+
+static long
+v4v_ringbuf_insertv(struct domain *d,
+                    struct v4v_ring_info *ring_info,
+                    v4v_ring_id_t *src_id, uint32_t proto,
+                    internal_v4v_iov_t iovs, uint32_t niov,
+                    size_t len)
+{
+    v4v_ring_t ring;
+    struct v4v_ring_message_header mh =3D { 0 };
+    int32_t sp;
+    long happy_ret;
+    int32_t ret =3D 0;
+    XEN_GUEST_HANDLE(uint8_t) empty_hnd =3D { 0 };
+
+    ASSERT(spin_is_locked(&ring_info->lock));
+
+    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.message_type =3D proto;
+
+        if ( (ret =3D v4v_memcpy_to_guest_ring(ring_info,
+                                             ring.tx_ptr + sizeof (v4v_r=
ing_t),
+                                             &mh, empty_hnd,
+                                             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 ( v4v_iov_copy(&iov, &iovs) )
+            {
+                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 )
+            {
+                ret =3D v4v_memcpy_to_guest_ring(ring_info,
+                        ring.tx_ptr + sizeof (v4v_ring_t),
+                        NULL, buf_hnd, sp);
+                if ( ret )
+                    break;
+
+                ring.tx_ptr =3D 0;
+                len -=3D sp;
+                guest_handle_add_offset(buf_hnd, sp);
+            }
+
+            ret =3D v4v_memcpy_to_guest_ring(ring_info,
+                    ring.tx_ptr + sizeof (v4v_ring_t),
+                    NULL, buf_hnd, len);
+            if ( ret )
+                break;
+
+            ring.tx_ptr +=3D len;
+
+            if ( ring.tx_ptr =3D=3D ring_info->len )
+                ring.tx_ptr =3D 0;
+
+            v4v_iov_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);
+}
+
+static void
+v4v_pending_remove_all(struct v4v_ring_info *info)
+{
+    struct hlist_node *node, *next;
+    struct v4v_pending_ent *pending_ent;
+
+    ASSERT(spin_is_locked(&info->lock));
+    hlist_for_each_entry_safe(pending_ent, node, next, &info->pending,
+            node) v4v_pending_remove_ent(pending_ent);
+}
+
+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;
+
+    ASSERT(rw_is_locked(&v4v_lock));
+
+    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);
+    }
+
+}
+
+static void
+v4v_pending_find(struct domain *d, 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;
+
+    ASSERT(rw_is_locked(&d->v4v->lock));
+
+    spin_lock(&ring_info->lock);
+    hlist_for_each_entry_safe(ent, node, next, &ring_info->pending, node=
)
+    {
+        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 l=
en)
+{
+    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, int=
 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, node=
)
+    {
+        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(xen_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);
+    }
+    return ret;
+}
+
+
+static struct v4v_ring_info *
+v4v_ring_find_info(struct domain *d, v4v_ring_id_t *id)
+{
+    uint16_t hash;
+    struct hlist_node *node;
+    struct v4v_ring_info *ring_info;
+
+    ASSERT(rw_is_locked(&d->v4v->lock));
+
+    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], node=
)
+    {
+        v4v_ring_id_t *cmpid =3D &ring_info->id;
+
+        if ( cmpid->addr.port =3D=3D id->addr.port &&
+             cmpid->addr.domain =3D=3D id->addr.domain &&
+             cmpid->partner =3D=3D id->partner)
+        {
+            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;
+}
+
+static struct v4v_ring_info *
+v4v_ring_find_info_by_addr(struct domain *d, struct v4v_addr *a, domid_t=
 p)
+{
+    v4v_ring_id_t id;
+    struct v4v_ring_info *ret;
+
+    ASSERT(rw_is_locked(&d->v4v->lock));
+
+    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_ANY;
+
+    return v4v_ring_find_info(d, &id);
+}
+
+static void v4v_ring_remove_mfns(struct domain *d, struct v4v_ring_info =
*ring_info)
+{
+    int i;
+
+    ASSERT(rw_is_write_locked(&d->v4v->lock));
+
+    if ( ring_info->mfns )
+    {
+        for ( i =3D 0; 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);
+    }
+    if ( ring_info->mfn_mapping )
+        xfree(ring_info->mfn_mapping);
+    ring_info->mfns =3D NULL;
+
+}
+
+static void
+v4v_ring_remove_info(struct domain *d, struct v4v_ring_info *ring_info)
+{
+    ASSERT(rw_is_write_locked(&d->v4v->lock));
+
+    spin_lock(&ring_info->lock);
+
+    v4v_pending_remove_all(ring_info);
+    hlist_del(&ring_info->node);
+    v4v_ring_remove_mfns(d, ring_info);
+
+    spin_unlock(&ring_info->lock);
+
+    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 =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(d, 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(xen_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 rin=
g.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 ring already registered\n",
+                    current->domain->domain_id);
+            ret =3D -EEXIST;
+            break;
+        }
+
+        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
+ */
+
+static void
+v4v_notify_ring(struct domain *d, struct v4v_ring_info *ring_info,
+                struct hlist_head *to_notify)
+{
+    uint32_t space;
+
+    ASSERT(rw_is_locked(&v4v_lock));
+    ASSERT(rw_is_locked(&d->v4v->lock));
+
+    spin_lock(&ring_info->lock);
+    space =3D v4v_ringbuf_payload_space(d, ring_info);
+    spin_unlock(&ring_info->lock);
+
+    v4v_pending_find(d, 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, data[0]);
+                ret =3D v4v_fill_ring_datas(d, ring_data.nent, ring_data=
_ent_hnd);
+            }
+        }
+    }
+    while ( 0 );
+
+    read_unlock(&v4v_lock);
+
+    return ret;
+}
+
+#ifdef V4V_DEBUG
+void
+v4v_viptables_print_rule(struct v4v_viptables_rule_node *node)
+{
+    v4v_viptables_rule_t *rule;
+
+    if ( node =3D=3D NULL )
+    {
+        printk("(null)\n");
+        return;
+    }
+
+    rule =3D &node->rule;
+
+    if ( rule->accept =3D=3D 1 )
+        printk("ACCEPT");
+    else
+        printk("REJECT");
+
+    printk(" ");
+
+    if ( rule->src.domain =3D=3D V4V_DOMID_ANY )
+        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 V4V_DOMID_ANY )
+        printk("*");
+    else
+        printk("%i", rule->dst.domain);
+
+    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 =3D NULL;
+    struct list_head* tmp;
+
+    ASSERT(rw_is_write_locked(&viprules_lock));
+
+    /* First rule is n.1 */
+    position--;
+
+    new =3D xmalloc(struct v4v_viptables_rule_node);
+    if ( new =3D=3D NULL )
+        return -ENOMEM;
+
+    if ( copy_from_guest(&new->rule, rule, 1) )
+    {
+        xfree(new);
+        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_hnd,
+                  int32_t position)
+{
+    struct list_head *tmp =3D NULL;
+    struct list_head *next =3D NULL;
+    struct v4v_viptables_rule_node *node;
+
+    ASSERT(rw_is_write_locked(&viprules_lock));
+
+    v4v_dprintk("v4v_viptables_del position:%d\n", position);
+
+    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_hnd) )
+    {
+        struct v4v_viptables_rule r;
+
+        if ( copy_from_guest(&r, rule_hnd, 1) )
+            return -EFAULT;
+
+        list_for_each(tmp, &viprules)
+        {
+            node =3D list_entry(tmp, struct v4v_viptables_rule_node, lis=
t);
+
+            if ( (node->rule.src.domain =3D=3D r.src.domain) &&
+                 (node->rule.src.port   =3D=3D r.src.port)   &&
+                 (node->rule.dst.domain =3D=3D r.dst.domain) &&
+                 (node->rule.dst.port   =3D=3D r.dst.port))
+            {
+                position =3D 0;
+                break;
+            }
+        }
+    }
+    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, lis=
t);
+            list_del(tmp);
+            xfree(node);
+        }
+    }
+
+    if ( position =3D=3D 0 && tmp !=3D &viprules )
+    {
+        node =3D list_entry(tmp, struct v4v_viptables_rule_node, list);
+#ifdef V4V_DEBUG
+        printk(KERN_ERR "VIPTables: deleting rule: ");
+        v4v_viptables_print_rule(node);
+#endif /* V4V_DEBUG */
+        list_del(tmp);
+        xfree(node);
+    }
+
+    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;
+    XEN_GUEST_HANDLE(v4v_viptables_rule_t) guest_rules;
+
+    ASSERT(rw_is_locked(&viprules_lock));
+
+    memset(&rules_list, 0, sizeof (rules_list));
+    if ( copy_from_guest(&rules_list, list_hnd, 1) )
+        return -EFAULT;
+
+    ptr =3D viprules.next;
+    while ( rules_list.start_rule !=3D 0 && ptr->next !=3D &viprules )
+    {
+        ptr =3D ptr->next;
+        rules_list.start_rule--;
+    }
+
+    if ( rules_list.nb_rules =3D=3D 0 )
+        return -EINVAL;
+
+    guest_rules =3D guest_handle_for_field(list_hnd, v4v_viptables_rule_=
t, rules[0]);
+
+    nbrules =3D 0;
+    while ( nbrules < rules_list.nb_rules && ptr !=3D &viprules )
+    {
+        node =3D list_entry(ptr, struct v4v_viptables_rule_node, list);
+
+        if ( !guest_handle_okay(guest_rules, 1) )
+            break;
+
+        if ( copy_to_guest(guest_rules, &node->rule, 1) )
+            break;
+
+        guest_handle_add_offset(guest_rules, 1);
+
+        nbrules++;
+        ptr =3D ptr->next;
+    }
+
+    rules_list.nb_rules =3D nbrules;
+    if ( copy_field_to_guest(list_hnd, &rules_list, nb_rules) )
+        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;
+    size_t ret =3D 0; /* Defaulting to ACCEPT */
+
+    read_lock(&viprules_lock);
+
+    list_for_each(ptr, &viprules)
+    {
+        node =3D list_entry(ptr, struct v4v_viptables_rule_node, list);
+
+        if ( (node->rule.src.domain =3D=3D V4V_DOMID_ANY ||
+              node->rule.src.domain =3D=3D src->domain) &&
+             (node->rule.src.port =3D=3D V4V_PORT_ANY ||
+              node->rule.src.port =3D=3D src->port) &&
+             (node->rule.dst.domain =3D=3D V4V_DOMID_ANY ||
+              node->rule.dst.domain =3D=3D dst->domain) &&
+             (node->rule.dst.port =3D=3D V4V_PORT_ANY ||
+              node->rule.dst.port =3D=3D dst->port) )
+        {
+            ret =3D !node->rule.accept;
+            break;
+        }
+    }
+
+    read_unlock(&viprules_lock);
+    return ret;
+}
+
+/*
+ * Hypercall to do the send
+ */
+static long
+v4v_sendv(struct domain *src_d, v4v_addr_t * src_addr,
+          v4v_addr_t * dst_addr, uint32_t proto,
+          internal_v4v_iov_t iovs, size_t niov)
+{
+    struct domain *dst_d;
+    v4v_ring_id_t 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;
+    }
+
+    if ( v4v_viptables_check(src_addr, dst_addr) !=3D 0 )
+    {
+        read_unlock(&v4v_lock);
+        gdprintk(XENLOG_WARNING,
+                 "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 )
+        {
+            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->domain=
);
+
+        if ( !ring_info )
+        {
+            ret =3D -ECONNREFUSED;
+            v4v_dprintk(" !ring_info, ECONNREFUSED\n");
+        }
+        else
+        {
+            long 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, io=
vs,
+                        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;
+}
+
+static void
+v4v_info(struct domain *d, v4v_info_t *info)
+{
+    read_lock(&d->v4v->lock);
+    info->ring_magic =3D V4V_RING_MAGIC;
+    info->data_magic =3D V4V_RING_DATA_MAGIC;
+    info->evtchn =3D d->v4v->evtchn_port;
+    read_unlock(&d->v4v->lock);
+}
+
+/*
+ * hypercall glue
+ */
+long
+do_v4v_op(int cmd, XEN_GUEST_HANDLE(void) arg1,
+          XEN_GUEST_HANDLE(void) arg2,
+          uint32_t arg3, uint32_t arg4)
+{
+    struct domain *d =3D current->domain;
+    long rc =3D -EFAULT;
+
+    v4v_dprintk("->do_v4v_op(%d,%p,%p,%d,%d)\n", cmd,
+                (void *)arg1.p, (void *)arg2.p, (int) arg3, (int) arg4);
+
+    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(xen_pfn_t) pfn_hnd =3D
+                    guest_handle_cast(arg2, xen_pfn_t);
+                uint32_t npage =3D arg3;
+                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:
+            {
+                uint32_t len =3D arg3;
+                uint32_t message_type =3D arg4;
+                v4v_iov_t iov;
+                internal_v4v_iov_t iovs;
+                XEN_GUEST_HANDLE(v4v_send_addr_t) addr_hnd =3D
+                    guest_handle_cast(arg1, v4v_send_addr_t);
+                v4v_send_addr_t addr;
+
+                if ( unlikely(!guest_handle_okay(addr_hnd, 1)) )
+                    goto out;
+                if ( copy_from_guest(&addr, addr_hnd, 1) )
+                    goto out;
+
+                iov.iov_base =3D (uint64_t)arg2.p; // FIXME
+                iov.iov_len =3D len;
+                iovs.xen_iov =3D &iov;
+                rc =3D v4v_sendv(d, &addr.src, &addr.dst, message_type, =
iovs, 1);
+                break;
+            }
+        case V4VOP_sendv:
+            {
+                internal_v4v_iov_t iovs;
+                uint32_t niov =3D arg3;
+                uint32_t message_type =3D arg4;
+                XEN_GUEST_HANDLE(v4v_send_addr_t) addr_hnd =3D
+                    guest_handle_cast(arg1, v4v_send_addr_t);
+                v4v_send_addr_t addr;
+
+                memset(&iovs, 0, sizeof (iovs));
+                iovs.guest_iov =3D guest_handle_cast(arg2, v4v_iov_t);
+
+                if ( unlikely(!guest_handle_okay(addr_hnd, 1)) )
+                    goto out;
+                if ( copy_from_guest(&addr, addr_hnd, 1) )
+                    goto out;
+
+                if ( unlikely(!guest_handle_okay(iovs.guest_iov, niov)) =
)
+                    goto out;
+
+                rc =3D v4v_sendv(d, &addr.src, &addr.dst, message_type, =
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;
+            }
+        case V4VOP_viptables_add:
+            {
+                uint32_t position =3D arg3;
+                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;
+
+                write_lock(&viprules_lock);
+                rc =3D v4v_viptables_add(d, rule_hnd, position);
+                write_unlock(&viprules_lock);
+                break;
+            }
+        case V4VOP_viptables_del:
+            {
+                uint32_t position =3D arg3;
+                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;
+
+                write_lock(&viprules_lock);
+                rc =3D v4v_viptables_del(d, rule_hnd, position);
+                write_unlock(&viprules_lock);
+                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 -EFAULT;
+                if ( unlikely(!guest_handle_okay(rules_list_hnd, 1)) )
+                    goto out;
+
+                read_lock(&viprules_lock);
+                rc =3D v4v_viptables_list(d, rules_list_hnd);
+                read_unlock(&viprules_lock);
+                break;
+            }
+        case V4VOP_info:
+            {
+                XEN_GUEST_HANDLE(v4v_info_t) info_hnd =3D
+                    guest_handle_cast(arg1, v4v_info_t);
+                v4v_info_t info;
+
+                if ( unlikely(!guest_handle_okay(info_hnd, 1)) )
+                    goto out;
+                v4v_info(d, &info);
+                if ( copy_to_guest(info_hnd, &info, 1) )
+                    goto out;
+                rc =3D 0;
+                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(d, ring_info);
+            }
+        }
+    }
+
+    d->v4v =3D NULL;
+    write_unlock(&v4v_lock);
+}
+
+int
+v4v_init(struct domain *d)
+{
+    struct v4v_domain *v4v;
+    evtchn_port_t port;
+    int i;
+    int rc;
+
+    v4v =3D xmalloc(struct v4v_domain);
+    if ( !v4v )
+        return -ENOMEM;
+
+    rc =3D evtchn_alloc_unbound_domain(d, &port, d->domain_id);
+    if ( rc )
+        return rc;
+
+    rwlock_init(&v4v->lock);
+
+    v4v->evtchn_port =3D port;
+    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 npage=
=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(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], nod=
e)
+            dump_domain_ring(d, ring_info);
+    }
+
+    printk(KERN_ERR "  event channel: %d\n",  d->v4v->evtchn_port);
+    read_unlock(&d->v4v->lock);
+
+    printk(KERN_ERR "\n");
+    v4v_signal_domain(d);
+}
+
+static void
+dump_state(unsigned char key)
+{
+    struct domain *d;
+
+    printk(KERN_ERR "\n\nV4V:\n");
+    read_lock(&v4v_lock);
+
+    rcu_read_lock(&domlist_read_lock);
+
+    for_each_domain(d)
+        dump_domain(d);
+
+    rcu_read_unlock(&domlist_read_lock);
+
+    read_unlock(&v4v_lock);
+}
+
+struct keyhandler v4v_info_keyhandler =3D
+{
+    .diagnostic =3D 1,
+    .u.fn =3D dump_state,
+    .desc =3D "dump v4v states and interupt"
+};
+
+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..ad8bb0e
--- /dev/null
+++ b/xen/include/public/v4v.h
@@ -0,0 +1,305 @@
+/***********************************************************************=
*******
+ * 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"
+#include "event_channel.h"
+
+/*
+ * Structure definitions
+ */
+
+#define V4V_RING_MAGIC          0xA822f72bb0b9d8ccULL
+#define V4V_RING_DATA_MAGIC	0x45fe852220b801d4ULL
+
+#define V4V_MESSAGE_DGRAM       0x3c2c1db8
+#define V4V_MESSAGE_STREAM 	0x70f6a8e5
+
+#define V4V_DOMID_ANY           DOMID_INVALID
+#define V4V_PORT_ANY            0
+
+typedef struct v4v_iov
+{
+    uint64_t iov_base;
+    uint32_t iov_len;
+} v4v_iov_t;
+
+typedef struct v4v_addr
+{
+    uint32_t port;
+    domid_t domain;
+    uint16_t pad;
+} v4v_addr_t;
+
+typedef struct v4v_ring_id
+{
+    v4v_addr_t addr;
+    domid_t partner;
+    uint16_t pad;
+} v4v_ring_id_t;
+
+typedef struct
+{
+    v4v_addr_t src;
+    v4v_addr_t dst;
+} v4v_send_addr_t;
+
+/*
+ * v4v_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
+ *
+ */
+struct v4v_ring
+{
+    uint64_t magic;
+    v4v_ring_id_t id;
+    uint32_t len;
+    uint32_t rx_ptr;
+    uint32_t tx_ptr;
+    uint8_t reserved[32];
+    uint8_t ring[0];
+};
+typedef struct v4v_ring v4v_ring_t;
+
+#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 exist=
s - do not
+                                               * rely on this field - fo=
r
+                                               * profiling only */
+#define V4V_RING_DATA_F_SUFFICIENT  (1U << 3) /* Sufficient space to que=
ue
+                                               * space_required bytes ex=
ists */
+
+typedef struct v4v_ring_data_ent
+{
+    v4v_addr_t ring;
+    uint16_t flags;
+    uint16_t pad;
+    uint32_t space_required;
+    uint32_t max_message_size;
+} v4v_ring_data_ent_t;
+
+typedef struct v4v_ring_data
+{
+    uint64_t magic;
+    uint32_t nent;
+    uint32_t pad;
+    uint64_t reserved[4];
+    v4v_ring_data_ent_t data[0];
+} v4v_ring_data_t;
+
+struct v4v_info
+{
+    uint64_t ring_magic;
+    uint64_t data_magic;
+    evtchn_port_t evtchn;
+    uint32_t pad;
+};
+typedef struct v4v_info v4v_info_t;
+
+#define V4V_SHF_SYN		(1 << 0)
+#define V4V_SHF_ACK		(1 << 1)
+#define V4V_SHF_RST		(1 << 2)
+
+#define V4V_SHF_PING		(1 << 8)
+#define V4V_SHF_PONG		(1 << 9)
+
+struct v4v_stream_header
+{
+    uint32_t flags;
+    uint32_t conid;
+};
+
+struct v4v_ring_message_header
+{
+    uint32_t len;
+    uint32_t pad0;
+    v4v_addr_t source;
+    uint32_t message_type;
+    uint32_t pad1;
+    uint8_t data[0];
+};
+
+typedef struct v4v_viptables_rule
+{
+    v4v_addr_t src;
+    v4v_addr_t dst;
+    uint32_t accept;
+    uint32_t pad;
+} v4v_viptables_rule_t;
+
+typedef struct v4v_viptables_list
+{
+    uint32_t start_rule;
+    uint32_t nb_rules;
+    struct v4v_viptables_rule rules[0];
+} v4v_viptables_list_t;
+
+/*
+ * HYPERCALLS
+ */
+
+/*
+ * V4VOP_register_ring
+ *
+ * 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(xen_pfn_t),
+ *           npage, 0)
+ */
+#define V4VOP_register_ring 	1
+
+
+/*
+ * V4VOP_unregister_ring
+ *
+ * Unregister a ring.
+ *
+ * do_v4v_op(V4VOP_send, v4v_ring, NULL, 0, 0)
+ */
+#define V4VOP_unregister_ring 	2
+
+/*
+ * V4VOP_send
+ *
+ * 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.
+ * message_type is the 32 bit number used from the message
+ * most likely V4V_MESSAGE_DGRAM or V4V_MESSAGE_STREAM. If insufficient =
space exists
+ * it will return -EAGAIN and xen will twing the V4V_INTERRUPT when
+ * sufficient space becomes available
+ *
+ * do_v4v_op(V4VOP_send,
+ *           v4v_send_addr_t addr,
+ *           void* buf,
+ *           uint32_t len,
+ *           uint32_t message_type)
+ */
+#define V4VOP_send 		3
+
+
+/*
+ * V4VOP_notify
+ *
+ * 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
+ *
+ * do_v4v_op(V4VOP_notify,
+ *           XEN_GUEST_HANDLE(v4v_ring_data_ent) ent,
+ *           NULL, nent, 0)
+ */
+#define V4VOP_notify 		4
+
+/*
+ * V4VOP_sendv
+ *
+ * Identical to V4VOP_send except rather than buf and len it takes
+ * an array of v4v_iov and a length of the array.
+ *
+ * do_v4v_op(V4VOP_sendv,
+ *           v4v_send_addr_t addr,
+ *           v4v_iov iov,
+ *           uint32_t niov,
+ *           uint32_t message_type)
+ */
+#define V4VOP_sendv		5
+
+/*
+ * V4VOP_viptables_add
+ *
+ * Insert a filtering rules after a given position.
+ *
+ * do_v4v_op(V4VOP_viptables_add,
+ *           v4v_viptables_rule_t rule,
+ *           NULL,
+ *           uint32_t position, 0)
+ */
+#define V4VOP_viptables_add     6
+
+/*
+ * V4VOP_viptables_del
+ *
+ * Delete a filtering rules at a position or the rule
+ * that matches "rule".
+ *
+ * do_v4v_op(V4VOP_viptables_del,
+ *           v4v_viptables_rule_t rule,
+ *           NULL,
+ *           uint32_t position, 0)
+ */
+#define V4VOP_viptables_del     7
+
+/*
+ * V4VOP_viptables_list
+ *
+ * Delete a filtering rules at a position or the rule
+ * that matches "rule".
+ *
+ * do_v4v_op(V4VOP_viptables_list,
+ *               v4v_vitpables_list_t list,
+ *               NULL, 0, 0)
+ */
+#define V4VOP_viptables_list    8
+
+/*
+ * V4VOP_info
+ *
+ * Returns v4v info for the current domain (domain that issued the hyper=
call).
+ *      - V4V magic number
+ *      - event channel port (for current domain)
+ *
+ * do_v4v_op(V4VOP_info,
+ *           XEN_GUEST_HANDLE(v4v_info_t) info,
+ *           NULL, 0, 0)
+ */
+#define V4VOP_info              9
+
+#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 b19425b..868d119 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..296de52 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,9 @@ struct domain
     nodemask_t node_affinity;
     unsigned int last_alloc_node;
     spinlock_t node_affinity_lock;
+
+    /* v4v */
+    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..05d20b5
--- /dev/null
+++ b/xen/include/xen/v4v.h
@@ -0,0 +1,133 @@
+/***********************************************************************=
*******
+ * 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
+
+/*
+ * Handlers
+ */
+
+DEFINE_XEN_GUEST_HANDLE (v4v_iov_t);
+DEFINE_XEN_GUEST_HANDLE (v4v_addr_t);
+DEFINE_XEN_GUEST_HANDLE (v4v_send_addr_t);
+DEFINE_XEN_GUEST_HANDLE (v4v_ring_t);
+DEFINE_XEN_GUEST_HANDLE (v4v_ring_data_ent_t);
+DEFINE_XEN_GUEST_HANDLE (v4v_ring_data_t);
+DEFINE_XEN_GUEST_HANDLE (v4v_info_t);
+
+DEFINE_XEN_GUEST_HANDLE (v4v_viptables_rule_t);
+DEFINE_XEN_GUEST_HANDLE (v4v_viptables_list_t);
+
+/*
+ * Helper functions
+ */
+
+static inline uint16_t
+v4v_hash_fn (v4v_ring_id_t *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;
+};
+
+
+struct v4v_ring_info
+{
+    /* next node in the hash, protected by L2  */
+    struct hlist_node node;
+    /* this ring's id, protected by L2 */
+    v4v_ring_id_t 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;
+    /* event channel */
+    evtchn_port_t evtchn_port;
+    /* protected by L2 */
+    struct hlist_head ring_hash[V4V_HTABLE_SIZE];
+};
+
+typedef struct v4v_viptables_rule_node
+{
+    struct list_head list;
+    v4v_viptables_rule_t rule;
+} v4v_viptables_rule_node_t;
+
+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,
+                uint32_t arg3,
+                uint32_t arg4);
+
+#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 Sep 13 18:08:25 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Sep 2012 18: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 1TCDpe-00034E-Sz; Thu, 13 Sep 2012 18:08:06 +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 1TCDpd-00033e-CM
	for xen-devel@lists.xen.org; Thu, 13 Sep 2012 18:08:05 +0000
Received: from [85.158.143.99:28559] by server-3.bemta-4.messagelabs.com id
	F6/3F-08232-40122505; Thu, 13 Sep 2012 18:08:04 +0000
X-Env-Sender: jean.guyader@citrix.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1347559683!19009430!3
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDkwMjg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13925 invoked from network); 13 Sep 2012 18:08:04 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Sep 2012 18:08:04 -0000
X-IronPort-AV: E=Sophos;i="4.80,417,1344211200"; d="scan'208";a="14528897"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Sep 2012 18:07:24 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Thu, 13 Sep 2012 19:07:24 +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 1TCDoy-0000Jl-AS;
	Thu, 13 Sep 2012 18:07:24 +0000
Received: by spongy (Postfix, from userid 2023)	id 3BF8D340C6D; Thu, 13 Sep
	2012 19:09:34 +0100 (BST)
From: Jean Guyader <jean.guyader@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Thu, 13 Sep 2012 19:09:30 +0100
Message-ID: <1347559772-21817-3-git-send-email-jean.guyader@citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <1347559772-21817-1-git-send-email-jean.guyader@citrix.com>
References: <1347559772-21817-1-git-send-email-jean.guyader@citrix.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="------------true"
Cc: tim@xen.org, Jean Guyader <jean.guyader@citrix.com>, JBeulich@suse.com
Subject: [Xen-devel] [PATCH 2/4] xen: virq, remove VIRQ_XC_RESERVED
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<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


VIRQ_XC_RESERVED was reserved for V4V but we have switched
to event channels so this place holder is no longer required.

Signed-off-by: Jean Guyader <jean.guyader@citrix.com>
---
 xen/include/public/xen.h |    1 -
 1 file changed, 1 deletion(-)


--------------true
Content-Type: text/x-patch;
	name="0002-xen-virq-remove-VIRQ_XC_RESERVED.patch"
Content-Disposition: attachment;
	filename="0002-xen-virq-remove-VIRQ_XC_RESERVED.patch"
Content-Transfer-Encoding: quoted-printable

diff --git a/xen/include/public/xen.h b/xen/include/public/xen.h
index b2f6c50..b19425b 100644
--- a/xen/include/public/xen.h
+++ b/xen/include/public/xen.h
@@ -157,7 +157,6 @@ 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_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 Sep 13 18:08:25 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Sep 2012 18: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 1TCDpe-00034E-Sz; Thu, 13 Sep 2012 18:08:06 +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 1TCDpd-00033e-CM
	for xen-devel@lists.xen.org; Thu, 13 Sep 2012 18:08:05 +0000
Received: from [85.158.143.99:28559] by server-3.bemta-4.messagelabs.com id
	F6/3F-08232-40122505; Thu, 13 Sep 2012 18:08:04 +0000
X-Env-Sender: jean.guyader@citrix.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1347559683!19009430!3
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDkwMjg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13925 invoked from network); 13 Sep 2012 18:08:04 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Sep 2012 18:08:04 -0000
X-IronPort-AV: E=Sophos;i="4.80,417,1344211200"; d="scan'208";a="14528897"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Sep 2012 18:07:24 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Thu, 13 Sep 2012 19:07:24 +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 1TCDoy-0000Jl-AS;
	Thu, 13 Sep 2012 18:07:24 +0000
Received: by spongy (Postfix, from userid 2023)	id 3BF8D340C6D; Thu, 13 Sep
	2012 19:09:34 +0100 (BST)
From: Jean Guyader <jean.guyader@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Thu, 13 Sep 2012 19:09:30 +0100
Message-ID: <1347559772-21817-3-git-send-email-jean.guyader@citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <1347559772-21817-1-git-send-email-jean.guyader@citrix.com>
References: <1347559772-21817-1-git-send-email-jean.guyader@citrix.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="------------true"
Cc: tim@xen.org, Jean Guyader <jean.guyader@citrix.com>, JBeulich@suse.com
Subject: [Xen-devel] [PATCH 2/4] xen: virq, remove VIRQ_XC_RESERVED
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<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


VIRQ_XC_RESERVED was reserved for V4V but we have switched
to event channels so this place holder is no longer required.

Signed-off-by: Jean Guyader <jean.guyader@citrix.com>
---
 xen/include/public/xen.h |    1 -
 1 file changed, 1 deletion(-)


--------------true
Content-Type: text/x-patch;
	name="0002-xen-virq-remove-VIRQ_XC_RESERVED.patch"
Content-Disposition: attachment;
	filename="0002-xen-virq-remove-VIRQ_XC_RESERVED.patch"
Content-Transfer-Encoding: quoted-printable

diff --git a/xen/include/public/xen.h b/xen/include/public/xen.h
index b2f6c50..b19425b 100644
--- a/xen/include/public/xen.h
+++ b/xen/include/public/xen.h
@@ -157,7 +157,6 @@ 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_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 Sep 13 18:08:25 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Sep 2012 18: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 1TCDpe-00033w-5Z; Thu, 13 Sep 2012 18:08:06 +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 1TCDpc-00033e-Tq
	for xen-devel@lists.xen.org; Thu, 13 Sep 2012 18:08:05 +0000
Received: from [85.158.143.99:28540] by server-3.bemta-4.messagelabs.com id
	65/3F-08232-40122505; Thu, 13 Sep 2012 18:08:04 +0000
X-Env-Sender: jean.guyader@citrix.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1347559683!19009430!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDkwMjg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13871 invoked from network); 13 Sep 2012 18:08:03 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Sep 2012 18:08:03 -0000
X-IronPort-AV: E=Sophos;i="4.80,417,1344211200"; d="scan'208";a="14528895"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Sep 2012 18:07:24 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Thu, 13 Sep 2012 19:07:24 +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 1TCDoy-0000Ji-6w;
	Thu, 13 Sep 2012 18:07:24 +0000
Received: by spongy (Postfix, from userid 2023)	id 235AF34194A; Thu, 13 Sep
	2012 19:09:33 +0100 (BST)
From: Jean Guyader <jean.guyader@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Thu, 13 Sep 2012 19:09:29 +0100
Message-ID: <1347559772-21817-2-git-send-email-jean.guyader@citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <1347559772-21817-1-git-send-email-jean.guyader@citrix.com>
References: <1347559772-21817-1-git-send-email-jean.guyader@citrix.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="------------true"
Cc: tim@xen.org, Jean Guyader <jean.guyader@citrix.com>, JBeulich@suse.com
Subject: [Xen-devel] [PATCH 1/4] xen: 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="0001-xen-Introduce-guest_handle_for_field.patch"
Content-Disposition: attachment;
	filename="0001-xen-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 Sep 13 18:08:25 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Sep 2012 18: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 1TCDpe-00033w-5Z; Thu, 13 Sep 2012 18:08:06 +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 1TCDpc-00033e-Tq
	for xen-devel@lists.xen.org; Thu, 13 Sep 2012 18:08:05 +0000
Received: from [85.158.143.99:28540] by server-3.bemta-4.messagelabs.com id
	65/3F-08232-40122505; Thu, 13 Sep 2012 18:08:04 +0000
X-Env-Sender: jean.guyader@citrix.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1347559683!19009430!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDkwMjg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13871 invoked from network); 13 Sep 2012 18:08:03 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Sep 2012 18:08:03 -0000
X-IronPort-AV: E=Sophos;i="4.80,417,1344211200"; d="scan'208";a="14528895"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Sep 2012 18:07:24 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Thu, 13 Sep 2012 19:07:24 +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 1TCDoy-0000Ji-6w;
	Thu, 13 Sep 2012 18:07:24 +0000
Received: by spongy (Postfix, from userid 2023)	id 235AF34194A; Thu, 13 Sep
	2012 19:09:33 +0100 (BST)
From: Jean Guyader <jean.guyader@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Thu, 13 Sep 2012 19:09:29 +0100
Message-ID: <1347559772-21817-2-git-send-email-jean.guyader@citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <1347559772-21817-1-git-send-email-jean.guyader@citrix.com>
References: <1347559772-21817-1-git-send-email-jean.guyader@citrix.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="------------true"
Cc: tim@xen.org, Jean Guyader <jean.guyader@citrix.com>, JBeulich@suse.com
Subject: [Xen-devel] [PATCH 1/4] xen: 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="0001-xen-Introduce-guest_handle_for_field.patch"
Content-Disposition: attachment;
	filename="0001-xen-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 Sep 13 18:08:25 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Sep 2012 18: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 1TCDpf-00034L-8g; Thu, 13 Sep 2012 18:08: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 1TCDpd-00033f-He
	for xen-devel@lists.xen.org; Thu, 13 Sep 2012 18:08:05 +0000
Received: from [85.158.143.99:21430] by server-2.bemta-4.messagelabs.com id
	AD/AA-21239-40122505; Thu, 13 Sep 2012 18:08:04 +0000
X-Env-Sender: jean.guyader@citrix.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1347559683!19009430!4
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDkwMjg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13972 invoked from network); 13 Sep 2012 18:08:04 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Sep 2012 18:08:04 -0000
X-IronPort-AV: E=Sophos;i="4.80,417,1344211200"; d="scan'208";a="14528898"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Sep 2012 18:07:24 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Thu, 13 Sep 2012 19:07: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 1TCDoy-0000Jn-Cg;
	Thu, 13 Sep 2012 18:07:24 +0000
Received: by spongy (Postfix, from userid 2023)	id 5713B34194A; Thu, 13 Sep
	2012 19:09:34 +0100 (BST)
From: Jean Guyader <jean.guyader@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Thu, 13 Sep 2012 19:09:31 +0100
Message-ID: <1347559772-21817-4-git-send-email-jean.guyader@citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <1347559772-21817-1-git-send-email-jean.guyader@citrix.com>
References: <1347559772-21817-1-git-send-email-jean.guyader@citrix.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="------------true"
Cc: tim@xen.org, Jean Guyader <jean.guyader@citrix.com>, JBeulich@suse.com
Subject: [Xen-devel] [PATCH 3/4] xen: events,
	exposes evtchn_alloc_unbound_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>
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


Exposes evtchn_alloc_unbound_domain to the rest of
Xen so we can create allocated unbound evtchn within Xen.

Signed-off-by: Jean Guyader <jean.guyader@citrix.com>
---
 xen/common/event_channel.c |   39 +++++++++++++++++++++++++++-----------=
-
 xen/include/xen/event.h    |    3 +++
 2 files changed, 30 insertions(+), 12 deletions(-)


--------------true
Content-Type: text/x-patch;
	name="0003-xen-events-exposes-evtchn_alloc_unbound_domain.patch"
Content-Disposition: attachment;
	filename="0003-xen-events-exposes-evtchn_alloc_unbound_domain.patch"
Content-Transfer-Encoding: quoted-printable

diff --git a/xen/common/event_channel.c b/xen/common/event_channel.c
index 53777f8..6a0e342 100644
--- a/xen/common/event_channel.c
+++ b/xen/common/event_channel.c
@@ -159,36 +159,51 @@ static int get_free_port(struct domain *d)
=20
 static long evtchn_alloc_unbound(evtchn_alloc_unbound_t *alloc)
 {
-    struct evtchn *chn;
     struct domain *d;
-    int            port;
-    domid_t        dom =3D alloc->dom;
     long           rc;
=20
-    rc =3D rcu_lock_target_domain_by_id(dom, &d);
+    rc =3D rcu_lock_target_domain_by_id(alloc->dom, &d);
     if ( rc )
         return rc;
=20
+    rc =3D evtchn_alloc_unbound_domain(d, &alloc->port, alloc->remote_do=
m);
+    if ( rc )
+        ERROR_EXIT_DOM((int)rc, d);
+
+ out:
+    rcu_unlock_domain(d);
+
+    return rc;
+}
+
+int evtchn_alloc_unbound_domain(struct domain *d, evtchn_port_t *port,
+                                domid_t remote_domid)
+{
+    struct evtchn *chn;
+    int           rc;
+    int           free_port;
+
     spin_lock(&d->event_lock);
=20
-    if ( (port =3D get_free_port(d)) < 0 )
-        ERROR_EXIT_DOM(port, d);
-    chn =3D evtchn_from_port(d, port);
+    rc =3D free_port =3D get_free_port(d);
+    if ( free_port < 0 )
+        goto out;
=20
-    rc =3D xsm_evtchn_unbound(d, chn, alloc->remote_dom);
+    chn =3D evtchn_from_port(d, free_port);
+    rc =3D xsm_evtchn_unbound(d, chn, remote_domid);
     if ( rc )
         goto out;
=20
     chn->state =3D ECS_UNBOUND;
-    if ( (chn->u.unbound.remote_domid =3D alloc->remote_dom) =3D=3D DOMI=
D_SELF )
+    if ( (chn->u.unbound.remote_domid =3D remote_domid) =3D=3D DOMID_SEL=
F )
         chn->u.unbound.remote_domid =3D current->domain->domain_id;
=20
-    alloc->port =3D port;
+    *port =3D free_port;
+    /* Everything is fine, returns 0 */
+    rc =3D 0;
=20
  out:
     spin_unlock(&d->event_lock);
-    rcu_unlock_domain(d);
-
     return rc;
 }
=20
diff --git a/xen/include/xen/event.h b/xen/include/xen/event.h
index 71c3e92..1a0c832 100644
--- a/xen/include/xen/event.h
+++ b/xen/include/xen/event.h
@@ -69,6 +69,9 @@ int guest_enabled_event(struct vcpu *v, uint32_t virq);
 /* Notify remote end of a Xen-attached event channel.*/
 void notify_via_xen_event_channel(struct domain *ld, int lport);
=20
+int evtchn_alloc_unbound_domain(struct domain *d, evtchn_port_t *port,
+                                domid_t remote_domid);
+
 /* Internal event channel object accessors */
 #define bucket_from_port(d,p) \
     ((d)->evtchn[(p)/EVTCHNS_PER_BUCKET])

--------------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 Sep 13 18:08:25 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Sep 2012 18: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 1TCDpf-00034L-8g; Thu, 13 Sep 2012 18:08: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 1TCDpd-00033f-He
	for xen-devel@lists.xen.org; Thu, 13 Sep 2012 18:08:05 +0000
Received: from [85.158.143.99:21430] by server-2.bemta-4.messagelabs.com id
	AD/AA-21239-40122505; Thu, 13 Sep 2012 18:08:04 +0000
X-Env-Sender: jean.guyader@citrix.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1347559683!19009430!4
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDkwMjg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13972 invoked from network); 13 Sep 2012 18:08:04 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Sep 2012 18:08:04 -0000
X-IronPort-AV: E=Sophos;i="4.80,417,1344211200"; d="scan'208";a="14528898"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Sep 2012 18:07:24 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Thu, 13 Sep 2012 19:07: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 1TCDoy-0000Jn-Cg;
	Thu, 13 Sep 2012 18:07:24 +0000
Received: by spongy (Postfix, from userid 2023)	id 5713B34194A; Thu, 13 Sep
	2012 19:09:34 +0100 (BST)
From: Jean Guyader <jean.guyader@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Thu, 13 Sep 2012 19:09:31 +0100
Message-ID: <1347559772-21817-4-git-send-email-jean.guyader@citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <1347559772-21817-1-git-send-email-jean.guyader@citrix.com>
References: <1347559772-21817-1-git-send-email-jean.guyader@citrix.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="------------true"
Cc: tim@xen.org, Jean Guyader <jean.guyader@citrix.com>, JBeulich@suse.com
Subject: [Xen-devel] [PATCH 3/4] xen: events,
	exposes evtchn_alloc_unbound_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>
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


Exposes evtchn_alloc_unbound_domain to the rest of
Xen so we can create allocated unbound evtchn within Xen.

Signed-off-by: Jean Guyader <jean.guyader@citrix.com>
---
 xen/common/event_channel.c |   39 +++++++++++++++++++++++++++-----------=
-
 xen/include/xen/event.h    |    3 +++
 2 files changed, 30 insertions(+), 12 deletions(-)


--------------true
Content-Type: text/x-patch;
	name="0003-xen-events-exposes-evtchn_alloc_unbound_domain.patch"
Content-Disposition: attachment;
	filename="0003-xen-events-exposes-evtchn_alloc_unbound_domain.patch"
Content-Transfer-Encoding: quoted-printable

diff --git a/xen/common/event_channel.c b/xen/common/event_channel.c
index 53777f8..6a0e342 100644
--- a/xen/common/event_channel.c
+++ b/xen/common/event_channel.c
@@ -159,36 +159,51 @@ static int get_free_port(struct domain *d)
=20
 static long evtchn_alloc_unbound(evtchn_alloc_unbound_t *alloc)
 {
-    struct evtchn *chn;
     struct domain *d;
-    int            port;
-    domid_t        dom =3D alloc->dom;
     long           rc;
=20
-    rc =3D rcu_lock_target_domain_by_id(dom, &d);
+    rc =3D rcu_lock_target_domain_by_id(alloc->dom, &d);
     if ( rc )
         return rc;
=20
+    rc =3D evtchn_alloc_unbound_domain(d, &alloc->port, alloc->remote_do=
m);
+    if ( rc )
+        ERROR_EXIT_DOM((int)rc, d);
+
+ out:
+    rcu_unlock_domain(d);
+
+    return rc;
+}
+
+int evtchn_alloc_unbound_domain(struct domain *d, evtchn_port_t *port,
+                                domid_t remote_domid)
+{
+    struct evtchn *chn;
+    int           rc;
+    int           free_port;
+
     spin_lock(&d->event_lock);
=20
-    if ( (port =3D get_free_port(d)) < 0 )
-        ERROR_EXIT_DOM(port, d);
-    chn =3D evtchn_from_port(d, port);
+    rc =3D free_port =3D get_free_port(d);
+    if ( free_port < 0 )
+        goto out;
=20
-    rc =3D xsm_evtchn_unbound(d, chn, alloc->remote_dom);
+    chn =3D evtchn_from_port(d, free_port);
+    rc =3D xsm_evtchn_unbound(d, chn, remote_domid);
     if ( rc )
         goto out;
=20
     chn->state =3D ECS_UNBOUND;
-    if ( (chn->u.unbound.remote_domid =3D alloc->remote_dom) =3D=3D DOMI=
D_SELF )
+    if ( (chn->u.unbound.remote_domid =3D remote_domid) =3D=3D DOMID_SEL=
F )
         chn->u.unbound.remote_domid =3D current->domain->domain_id;
=20
-    alloc->port =3D port;
+    *port =3D free_port;
+    /* Everything is fine, returns 0 */
+    rc =3D 0;
=20
  out:
     spin_unlock(&d->event_lock);
-    rcu_unlock_domain(d);
-
     return rc;
 }
=20
diff --git a/xen/include/xen/event.h b/xen/include/xen/event.h
index 71c3e92..1a0c832 100644
--- a/xen/include/xen/event.h
+++ b/xen/include/xen/event.h
@@ -69,6 +69,9 @@ int guest_enabled_event(struct vcpu *v, uint32_t virq);
 /* Notify remote end of a Xen-attached event channel.*/
 void notify_via_xen_event_channel(struct domain *ld, int lport);
=20
+int evtchn_alloc_unbound_domain(struct domain *d, evtchn_port_t *port,
+                                domid_t remote_domid);
+
 /* Internal event channel object accessors */
 #define bucket_from_port(d,p) \
     ((d)->evtchn[(p)/EVTCHNS_PER_BUCKET])

--------------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 Sep 13 18:08:25 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Sep 2012 18: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 1TCDpe-000347-HI; Thu, 13 Sep 2012 18:08:06 +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 1TCDpd-00033f-1A
	for xen-devel@lists.xen.org; Thu, 13 Sep 2012 18:08:05 +0000
Received: from [85.158.143.99:28542] by server-2.bemta-4.messagelabs.com id
	AB/AA-21239-40122505; Thu, 13 Sep 2012 18:08:04 +0000
X-Env-Sender: jean.guyader@citrix.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1347559683!19009430!2
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDkwMjg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13902 invoked from network); 13 Sep 2012 18:08:03 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Sep 2012 18:08:03 -0000
X-IronPort-AV: E=Sophos;i="4.80,417,1344211200"; d="scan'208";a="14528896"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Sep 2012 18:07:24 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Thu, 13 Sep 2012 19:07:24 +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 1TCDoy-0000Jf-3v;
	Thu, 13 Sep 2012 18:07:24 +0000
Received: by spongy (Postfix, from userid 2023)	id EF612340C6D; Thu, 13 Sep
	2012 19:09:33 +0100 (BST)
From: Jean Guyader <jean.guyader@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Thu, 13 Sep 2012 19:09:28 +0100
Message-ID: <1347559772-21817-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: tim@xen.org, Jean Guyader <jean.guyader@citrix.com>, JBeulich@suse.com
Subject: [Xen-devel] [RFC][PATCH 0/4] 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: quoted-printable

v4 changes:
        - Stop using ssize_t, use long instead
        - Return -MSGSIZE for message bigger than 2GB
        - Fixup size handling
        - Rename protocol with message_type to avoid the
          confusion with the IP protocol flag
        - Replaced V4V_DOMID_ANY value with DOMID_INVALID
        - Replaced v4v_pfn_t with xen_pfn_t
        - Add padding to struct v4v_info
        - Fixup hypercall documentation
        - Move V4V_ROUNDUP to v4v.c
        - Remove v4v_utils.h (we could potentially add it later).

v3 changes:
        - Switch to event channel
                - Allocated a unbound event channel
                  per domain.
                - Add a new v4v call to share the
                  event channel port.
        - Public headers with actual type definition
        - Align all the v4v type to 64 bits
        - Modify v4v MAGIC numbers because we won't
          but backward compatible anymore
        - Merge insert and insertv
        - Merge send and sendv
        - Turn all the lock prerequisite from comment
          to ASSERT()
        - Make use or write_atomic instead of volatile pointers
        - Merge v4v_memcpy_to_guest_ring and
          v4v_memcpy_to_guest_ring_from_guest
                - Introduce copy_from_guest_maybe that can take
                  a void * and a handle as src address.
        - Replace 6 arguments hypercalls with 5 arguments hypercalls.

v2 changes:
        - Cleanup plugin header
        - Include basic access control
        - Use guest_handle_for_field

Jan Beulich (1):
  xen: Introduce guest_handle_for_field

Jean Guyader (3):
  xen: virq, remove VIRQ_XC_RESERVED
  xen: events, exposes evtchn_alloc_unbound_domain
  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                |   13 +-
 xen/common/event_channel.c         |   39 +-
 xen/common/v4v.c                   | 1907 ++++++++++++++++++++++++++++++=
++++++
 xen/include/asm-x86/guest_access.h |    3 +
 xen/include/public/v4v.h           |  305 ++++++
 xen/include/public/xen.h           |    3 +-
 xen/include/xen/event.h            |    3 +
 xen/include/xen/sched.h            |    4 +
 xen/include/xen/v4v.h              |  133 +++
 14 files changed, 2408 insertions(+), 18 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 Sep 13 18:08:25 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Sep 2012 18: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 1TCDpe-000347-HI; Thu, 13 Sep 2012 18:08:06 +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 1TCDpd-00033f-1A
	for xen-devel@lists.xen.org; Thu, 13 Sep 2012 18:08:05 +0000
Received: from [85.158.143.99:28542] by server-2.bemta-4.messagelabs.com id
	AB/AA-21239-40122505; Thu, 13 Sep 2012 18:08:04 +0000
X-Env-Sender: jean.guyader@citrix.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1347559683!19009430!2
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDkwMjg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13902 invoked from network); 13 Sep 2012 18:08:03 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Sep 2012 18:08:03 -0000
X-IronPort-AV: E=Sophos;i="4.80,417,1344211200"; d="scan'208";a="14528896"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Sep 2012 18:07:24 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Thu, 13 Sep 2012 19:07:24 +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 1TCDoy-0000Jf-3v;
	Thu, 13 Sep 2012 18:07:24 +0000
Received: by spongy (Postfix, from userid 2023)	id EF612340C6D; Thu, 13 Sep
	2012 19:09:33 +0100 (BST)
From: Jean Guyader <jean.guyader@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Thu, 13 Sep 2012 19:09:28 +0100
Message-ID: <1347559772-21817-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: tim@xen.org, Jean Guyader <jean.guyader@citrix.com>, JBeulich@suse.com
Subject: [Xen-devel] [RFC][PATCH 0/4] 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: quoted-printable

v4 changes:
        - Stop using ssize_t, use long instead
        - Return -MSGSIZE for message bigger than 2GB
        - Fixup size handling
        - Rename protocol with message_type to avoid the
          confusion with the IP protocol flag
        - Replaced V4V_DOMID_ANY value with DOMID_INVALID
        - Replaced v4v_pfn_t with xen_pfn_t
        - Add padding to struct v4v_info
        - Fixup hypercall documentation
        - Move V4V_ROUNDUP to v4v.c
        - Remove v4v_utils.h (we could potentially add it later).

v3 changes:
        - Switch to event channel
                - Allocated a unbound event channel
                  per domain.
                - Add a new v4v call to share the
                  event channel port.
        - Public headers with actual type definition
        - Align all the v4v type to 64 bits
        - Modify v4v MAGIC numbers because we won't
          but backward compatible anymore
        - Merge insert and insertv
        - Merge send and sendv
        - Turn all the lock prerequisite from comment
          to ASSERT()
        - Make use or write_atomic instead of volatile pointers
        - Merge v4v_memcpy_to_guest_ring and
          v4v_memcpy_to_guest_ring_from_guest
                - Introduce copy_from_guest_maybe that can take
                  a void * and a handle as src address.
        - Replace 6 arguments hypercalls with 5 arguments hypercalls.

v2 changes:
        - Cleanup plugin header
        - Include basic access control
        - Use guest_handle_for_field

Jan Beulich (1):
  xen: Introduce guest_handle_for_field

Jean Guyader (3):
  xen: virq, remove VIRQ_XC_RESERVED
  xen: events, exposes evtchn_alloc_unbound_domain
  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                |   13 +-
 xen/common/event_channel.c         |   39 +-
 xen/common/v4v.c                   | 1907 ++++++++++++++++++++++++++++++=
++++++
 xen/include/asm-x86/guest_access.h |    3 +
 xen/include/public/v4v.h           |  305 ++++++
 xen/include/public/xen.h           |    3 +-
 xen/include/xen/event.h            |    3 +
 xen/include/xen/sched.h            |    4 +
 xen/include/xen/v4v.h              |  133 +++
 14 files changed, 2408 insertions(+), 18 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 Sep 13 18:08:46 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Sep 2012 18: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 1TCDq9-0003Ca-GC; Thu, 13 Sep 2012 18:08:37 +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 1TCDq7-0003AJ-6E
	for Xen-devel@lists.xensource.com; Thu, 13 Sep 2012 18:08:35 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1347559709!5353895!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDkwMjg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27918 invoked from network); 13 Sep 2012 18:08:29 -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 Sep 2012 18:08:29 -0000
X-IronPort-AV: E=Sophos;i="4.80,417,1344211200"; d="scan'208";a="14528919"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Sep 2012 18:08:29 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Thu, 13 Sep 2012 19:08:29 +0100
Message-ID: <1347559708.25803.61.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Pasi =?ISO-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
Date: Thu, 13 Sep 2012 19:08:28 +0100
In-Reply-To: <20120913173639.GY8912@reaktio.net>
References: <20120815175724.3405043a@mantra.us.oracle.com>
	<1347285352.5305.86.camel@zakaz.uk.xensource.com>
	<20120911145751.599b8292@mantra.us.oracle.com>
	<1347437545.25803.16.camel@dagon.hellion.org.uk>
	<20120912110254.10bde333@mantra.us.oracle.com>
	<1347474380.25803.21.camel@dagon.hellion.org.uk>
	<20120912123238.7057c51a@mantra.us.oracle.com>
	<1347516007.25803.44.camel@dagon.hellion.org.uk>
	<20120913101439.6bd363a9@mantra.us.oracle.com>
	<20120913173639.GY8912@reaktio.net>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [RFC PATCH 1/8]: PVH: Basic and preparatory 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="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, 2012-09-13 at 18:36 +0100, Pasi K=E4rkk=E4inen wrote:
> On Thu, Sep 13, 2012 at 10:14:39AM -0700, Mukesh Rathor wrote:
> > On Thu, 13 Sep 2012 07:00:07 +0100
> > Ian Campbell <Ian.Campbell@citrix.com> wrote:
> > > The toolstack (or the dom0 builder) can make the determination whether
> > > to enable this mode itself itself based on the notes (although it is
> > > always handy to have an override to force things for debug).
> > =

> > Hmmm... So you are suggesting that if hardware and xen supports it, then
> > PV should just boot in PVH mode and user has no way to override it. I
> > don't know if that's a good idea in the short term, perhaps in the long
> > term. Let me discuss with folks here a bit.
> > =

> =

> I read that as "if hardware, xen and kernel supports PVH, enable it as a =
default,
> but still allow the user to force enable/disable it in the domain cfgfile=
 for easier debugging".

That's right. I have no objection to an override, in fact I think it's a
requirement to be able to force this sort of feature on/off (to aid for
debugging, account for differing workload requirements and allowing the
test system to test both configurations etc).

Long term the aim should be for the default to be on whenever possible.
Maybe the default should remain off for the time being, or maybe we want
to get as much exposure of PVH as possible ASAP, which would argue for
it being on by default in unstable, perhaps with a decision being made
around freeze time as to the default in 4.3.

The feature declarations in the ELF note also allow the toolstack to
sanity check what the user asked for and report an error if it isn't
possible, rather than booting a kernel in a mode which cannot possibly
work.

Ian.

> =

> -- Pasi
> =




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 13 18:08:46 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Sep 2012 18: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 1TCDq9-0003Ca-GC; Thu, 13 Sep 2012 18:08:37 +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 1TCDq7-0003AJ-6E
	for Xen-devel@lists.xensource.com; Thu, 13 Sep 2012 18:08:35 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1347559709!5353895!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDkwMjg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27918 invoked from network); 13 Sep 2012 18:08:29 -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 Sep 2012 18:08:29 -0000
X-IronPort-AV: E=Sophos;i="4.80,417,1344211200"; d="scan'208";a="14528919"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Sep 2012 18:08:29 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Thu, 13 Sep 2012 19:08:29 +0100
Message-ID: <1347559708.25803.61.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Pasi =?ISO-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
Date: Thu, 13 Sep 2012 19:08:28 +0100
In-Reply-To: <20120913173639.GY8912@reaktio.net>
References: <20120815175724.3405043a@mantra.us.oracle.com>
	<1347285352.5305.86.camel@zakaz.uk.xensource.com>
	<20120911145751.599b8292@mantra.us.oracle.com>
	<1347437545.25803.16.camel@dagon.hellion.org.uk>
	<20120912110254.10bde333@mantra.us.oracle.com>
	<1347474380.25803.21.camel@dagon.hellion.org.uk>
	<20120912123238.7057c51a@mantra.us.oracle.com>
	<1347516007.25803.44.camel@dagon.hellion.org.uk>
	<20120913101439.6bd363a9@mantra.us.oracle.com>
	<20120913173639.GY8912@reaktio.net>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [RFC PATCH 1/8]: PVH: Basic and preparatory 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="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, 2012-09-13 at 18:36 +0100, Pasi K=E4rkk=E4inen wrote:
> On Thu, Sep 13, 2012 at 10:14:39AM -0700, Mukesh Rathor wrote:
> > On Thu, 13 Sep 2012 07:00:07 +0100
> > Ian Campbell <Ian.Campbell@citrix.com> wrote:
> > > The toolstack (or the dom0 builder) can make the determination whether
> > > to enable this mode itself itself based on the notes (although it is
> > > always handy to have an override to force things for debug).
> > =

> > Hmmm... So you are suggesting that if hardware and xen supports it, then
> > PV should just boot in PVH mode and user has no way to override it. I
> > don't know if that's a good idea in the short term, perhaps in the long
> > term. Let me discuss with folks here a bit.
> > =

> =

> I read that as "if hardware, xen and kernel supports PVH, enable it as a =
default,
> but still allow the user to force enable/disable it in the domain cfgfile=
 for easier debugging".

That's right. I have no objection to an override, in fact I think it's a
requirement to be able to force this sort of feature on/off (to aid for
debugging, account for differing workload requirements and allowing the
test system to test both configurations etc).

Long term the aim should be for the default to be on whenever possible.
Maybe the default should remain off for the time being, or maybe we want
to get as much exposure of PVH as possible ASAP, which would argue for
it being on by default in unstable, perhaps with a decision being made
around freeze time as to the default in 4.3.

The feature declarations in the ELF note also allow the toolstack to
sanity check what the user asked for and report an error if it isn't
possible, rather than booting a kernel in a mode which cannot possibly
work.

Ian.

> =

> -- Pasi
> =




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 13 18:13:17 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Sep 2012 18:13:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TCDuU-0003tT-CB; Thu, 13 Sep 2012 18:13:06 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jean.guyader@gmail.com>) id 1TCDuS-0003t5-T6
	for xen-devel@lists.xen.org; Thu, 13 Sep 2012 18:13:05 +0000
Received: from [85.158.139.83:9068] by server-10.bemta-5.messagelabs.com id
	7B/AE-10969-03222505; Thu, 13 Sep 2012 18:13:04 +0000
X-Env-Sender: jean.guyader@gmail.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1347559982!26428234!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-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19531 invoked from network); 13 Sep 2012 18:13:03 -0000
Received: from mail-vc0-f173.google.com (HELO mail-vc0-f173.google.com)
	(209.85.220.173)
	by server-7.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Sep 2012 18:13:03 -0000
Received: by vcbfl15 with SMTP id fl15so4755296vcb.32
	for <xen-devel@lists.xen.org>; Thu, 13 Sep 2012 11:13: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
	:cc:content-type;
	bh=NY5OC4hZkbgl5wYhKgV7iipVghjqxwuhIXXVo80Dobs=;
	b=RxuNgWJy6IbJOqExvJNnPn5bSP/r11Lkj+NPuxvmP/6YsqNlJPkKM/fY7uZwFR/MN/
	PYjYb7VqaU2+XOecmh8c/dG5HMU76nuOeStjcoqJCwDSOGklFnUpIPUu3ppsXyHjoCGn
	7q6HEp4+gGAvx/VgCcJ6Sngok5OOS597Bm6uXmRPCHXsCtkveatGgkGRkls20V2wPZpE
	dMLlYUDeLIffr+rJj4FHy3y5ZSFRFxAI8xgmGf/KKMfdyDBSflXt/pscsAfUoegMIS3k
	yp+VaCbchi1drTWjSV/pcMe+78llkNAx0PLOsom2u1qQOQXNV42M3WTQxYE9z19oFH7r
	MGCA==
Received: by 10.52.92.11 with SMTP id ci11mr81051vdb.7.1347559982049; Thu, 13
	Sep 2012 11:13:02 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.58.91.72 with HTTP; Thu, 13 Sep 2012 11:12:41 -0700 (PDT)
In-Reply-To: <1347559772-21817-2-git-send-email-jean.guyader@citrix.com>
References: <1347559772-21817-1-git-send-email-jean.guyader@citrix.com>
	<1347559772-21817-2-git-send-email-jean.guyader@citrix.com>
From: Jean Guyader <jean.guyader@gmail.com>
Date: Thu, 13 Sep 2012 19:12:41 +0100
Message-ID: <CAEBdQ90+3nJGLnAHroxWkYMh=98QywRnjrS+EHhabVXHvm5cog@mail.gmail.com>
To: Jean Guyader <jean.guyader@citrix.com>
Cc: tim@xen.org, JBeulich@suse.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 1/4] xen: 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 13 September 2012 19:09, 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>

This patch is from Jan, sorry about that.

Signed-off-by: Jan Beulich <JBeulich@suse.com>

Jean

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 13 18:13:17 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Sep 2012 18:13:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TCDuU-0003tT-CB; Thu, 13 Sep 2012 18:13:06 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jean.guyader@gmail.com>) id 1TCDuS-0003t5-T6
	for xen-devel@lists.xen.org; Thu, 13 Sep 2012 18:13:05 +0000
Received: from [85.158.139.83:9068] by server-10.bemta-5.messagelabs.com id
	7B/AE-10969-03222505; Thu, 13 Sep 2012 18:13:04 +0000
X-Env-Sender: jean.guyader@gmail.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1347559982!26428234!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-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19531 invoked from network); 13 Sep 2012 18:13:03 -0000
Received: from mail-vc0-f173.google.com (HELO mail-vc0-f173.google.com)
	(209.85.220.173)
	by server-7.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Sep 2012 18:13:03 -0000
Received: by vcbfl15 with SMTP id fl15so4755296vcb.32
	for <xen-devel@lists.xen.org>; Thu, 13 Sep 2012 11:13: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
	:cc:content-type;
	bh=NY5OC4hZkbgl5wYhKgV7iipVghjqxwuhIXXVo80Dobs=;
	b=RxuNgWJy6IbJOqExvJNnPn5bSP/r11Lkj+NPuxvmP/6YsqNlJPkKM/fY7uZwFR/MN/
	PYjYb7VqaU2+XOecmh8c/dG5HMU76nuOeStjcoqJCwDSOGklFnUpIPUu3ppsXyHjoCGn
	7q6HEp4+gGAvx/VgCcJ6Sngok5OOS597Bm6uXmRPCHXsCtkveatGgkGRkls20V2wPZpE
	dMLlYUDeLIffr+rJj4FHy3y5ZSFRFxAI8xgmGf/KKMfdyDBSflXt/pscsAfUoegMIS3k
	yp+VaCbchi1drTWjSV/pcMe+78llkNAx0PLOsom2u1qQOQXNV42M3WTQxYE9z19oFH7r
	MGCA==
Received: by 10.52.92.11 with SMTP id ci11mr81051vdb.7.1347559982049; Thu, 13
	Sep 2012 11:13:02 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.58.91.72 with HTTP; Thu, 13 Sep 2012 11:12:41 -0700 (PDT)
In-Reply-To: <1347559772-21817-2-git-send-email-jean.guyader@citrix.com>
References: <1347559772-21817-1-git-send-email-jean.guyader@citrix.com>
	<1347559772-21817-2-git-send-email-jean.guyader@citrix.com>
From: Jean Guyader <jean.guyader@gmail.com>
Date: Thu, 13 Sep 2012 19:12:41 +0100
Message-ID: <CAEBdQ90+3nJGLnAHroxWkYMh=98QywRnjrS+EHhabVXHvm5cog@mail.gmail.com>
To: Jean Guyader <jean.guyader@citrix.com>
Cc: tim@xen.org, JBeulich@suse.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 1/4] xen: 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 13 September 2012 19:09, 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>

This patch is from Jan, sorry about that.

Signed-off-by: Jan Beulich <JBeulich@suse.com>

Jean

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 13 18:28:16 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Sep 2012 18:28:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TCE8y-000486-0Y; Thu, 13 Sep 2012 18:28:04 +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 1TCE8v-000481-UV
	for Xen-devel@lists.xensource.com; Thu, 13 Sep 2012 18:28:02 +0000
Received: from [85.158.137.99:21288] by server-10.bemta-3.messagelabs.com id
	CE/7E-10411-1B522505; Thu, 13 Sep 2012 18:28:01 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-14.tower-217.messagelabs.com!1347560878!17530095!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzM4ODI0\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9319 invoked from network); 13 Sep 2012 18:28:00 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-14.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 13 Sep 2012 18:28:00 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q8DIRuN1018384
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 13 Sep 2012 18:27: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
	q8DIRt96003592
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 13 Sep 2012 18:27:56 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
	q8DIRtWt010077; Thu, 13 Sep 2012 13:27:55 -0500
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 13 Sep 2012 11:27:55 -0700
Date: Thu, 13 Sep 2012 11:27:53 -0700
From: Mukesh Rathor <mukesh.rathor@oracle.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120913112753.3fa731ec@mantra.us.oracle.com>
In-Reply-To: <1347536266.24226.97.camel@zakaz.uk.xensource.com>
References: <20120815180716.0049bffe@mantra.us.oracle.com>
	<1347372623.5305.170.camel@zakaz.uk.xensource.com>
	<20120912181910.6b0b9d2b@mantra.us.oracle.com>
	<1347536266.24226.97.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>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [RFC PATCH 8/8]: PVH: privcmd 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

> I suppose it depends on whether the core "takes over" the reference
> which you hold. I think it doesn't, so this is just a leak, rather
> than putting a ballooned page back into the general allocation pool
> (things would be crashing left & right if it was doing this I reckon)
> 
> > 
> > I had looked for other hooks initially when I did this, but 
> > vm_operations_struct->close was the only one to pan out.
> > 
> > I can't really move pvh_privcmd_resv_pfns to mmu.c because the 
> > xen_remap_domain_mfn_range is called one page at a time, and I need
> > to allocate the array first. I'd have to change it to linked list,
> > worth it? Or I'd have to move and export it.
> 
> Another alternative would be to add the page array as a parameter to
> the map/unmap function, rather than relying on it propagating via
> vma_private.

I thought it was a no-no to change an exported API. Konrad, is it OK
to change an exported API like xen_remap_domain_mfn_range, I mean, are
there any guidelines?

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 Sep 13 18:28:16 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Sep 2012 18:28:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TCE8y-000486-0Y; Thu, 13 Sep 2012 18:28:04 +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 1TCE8v-000481-UV
	for Xen-devel@lists.xensource.com; Thu, 13 Sep 2012 18:28:02 +0000
Received: from [85.158.137.99:21288] by server-10.bemta-3.messagelabs.com id
	CE/7E-10411-1B522505; Thu, 13 Sep 2012 18:28:01 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-14.tower-217.messagelabs.com!1347560878!17530095!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzM4ODI0\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9319 invoked from network); 13 Sep 2012 18:28:00 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-14.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 13 Sep 2012 18:28:00 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q8DIRuN1018384
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 13 Sep 2012 18:27: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
	q8DIRt96003592
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 13 Sep 2012 18:27:56 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
	q8DIRtWt010077; Thu, 13 Sep 2012 13:27:55 -0500
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 13 Sep 2012 11:27:55 -0700
Date: Thu, 13 Sep 2012 11:27:53 -0700
From: Mukesh Rathor <mukesh.rathor@oracle.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120913112753.3fa731ec@mantra.us.oracle.com>
In-Reply-To: <1347536266.24226.97.camel@zakaz.uk.xensource.com>
References: <20120815180716.0049bffe@mantra.us.oracle.com>
	<1347372623.5305.170.camel@zakaz.uk.xensource.com>
	<20120912181910.6b0b9d2b@mantra.us.oracle.com>
	<1347536266.24226.97.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>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [RFC PATCH 8/8]: PVH: privcmd 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

> I suppose it depends on whether the core "takes over" the reference
> which you hold. I think it doesn't, so this is just a leak, rather
> than putting a ballooned page back into the general allocation pool
> (things would be crashing left & right if it was doing this I reckon)
> 
> > 
> > I had looked for other hooks initially when I did this, but 
> > vm_operations_struct->close was the only one to pan out.
> > 
> > I can't really move pvh_privcmd_resv_pfns to mmu.c because the 
> > xen_remap_domain_mfn_range is called one page at a time, and I need
> > to allocate the array first. I'd have to change it to linked list,
> > worth it? Or I'd have to move and export it.
> 
> Another alternative would be to add the page array as a parameter to
> the map/unmap function, rather than relying on it propagating via
> vma_private.

I thought it was a no-no to change an exported API. Konrad, is it OK
to change an exported API like xen_remap_domain_mfn_range, I mean, are
there any guidelines?

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 Sep 13 18:36:32 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Sep 2012 18:36: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 1TCEGw-0004JM-2H; Thu, 13 Sep 2012 18:36:18 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1TCEGu-0004JH-Bo
	for xen-devel@lists.xensource.com; Thu, 13 Sep 2012 18:36:16 +0000
Received: from [85.158.138.51:35118] by server-12.bemta-3.messagelabs.com id
	31/A7-10384-F9722505; Thu, 13 Sep 2012 18:36:15 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1347561373!30387096!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDkwMjg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10220 invoked from network); 13 Sep 2012 18:36:13 -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;
	13 Sep 2012 18:36:13 -0000
X-IronPort-AV: E=Sophos;i="4.80,417,1344211200"; d="scan'208";a="14529492"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Sep 2012 18:36: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.279.1; Thu, 13 Sep 2012 19:36: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 1TCEGq-0000aW-FD;
	Thu, 13 Sep 2012 18:36:12 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1TCEGq-0003qe-Ep;
	Thu, 13 Sep 2012 19:36:12 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-13737-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 13 Sep 2012 19:36:12 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13737: regressions - trouble:
	blocked/broken/fail/pass
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 13737 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13737/

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. 13668
 build-i386                    4 xen-build                 fail REGR. vs. 13668
 test-amd64-amd64-xl-win       2 hosts-allocate          broken REGR. vs. 13668

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore            fail   like 13668
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail like 13668
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail like 13668

Tests which did not succeed, but are not blocking:
 test-amd64-i386-rhel6hvm-amd  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 xen-build-check(1)           blocked n/a
 test-amd64-i386-rhel6hvm-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   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-xl-credit2    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-multivcpu  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 xen-build-check(1)         blocked n/a
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-pv            1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-win-vcpus1    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-winxpsp3-vcpus1  1 xen-build-check(1)           blocked n/a
 test-amd64-i386-xl            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pair          1 xen-build-check(1)           blocked  n/a

version targeted for testing:
 xen                  5691e4cc17da
baseline version:
 xen                  7d770de90b7f

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@citrix.com>
  Boris Ostrovsky <boris.ostrovsky@amd.com>
  Christoph Egger <Christoph.Egger@amd.com>
  Dan Magenheimer <dan.magenheimer@oracle.com>
  David Vrabel <david.vrabel@citrix.com>
  Ian Campbell <ian.campbell@citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Keir Fraser <keir@xen.org>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Wei Wang <wei.wang2@amd.com>
  Zhenzhong Duan <zhenzhong.duan@oracle.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   fail    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           fail    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           blocked 
 test-amd64-i386-rhel6hvm-amd                                 blocked 
 test-amd64-i386-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-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-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-amd64-amd64-xl-win                                      broken  
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                blocked 
 test-amd64-amd64-xl-winxpsp3                                 fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

(No revision log; it would be 775 lines long.)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 13 18:36:32 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Sep 2012 18:36: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 1TCEGw-0004JM-2H; Thu, 13 Sep 2012 18:36:18 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1TCEGu-0004JH-Bo
	for xen-devel@lists.xensource.com; Thu, 13 Sep 2012 18:36:16 +0000
Received: from [85.158.138.51:35118] by server-12.bemta-3.messagelabs.com id
	31/A7-10384-F9722505; Thu, 13 Sep 2012 18:36:15 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1347561373!30387096!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDkwMjg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10220 invoked from network); 13 Sep 2012 18:36:13 -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;
	13 Sep 2012 18:36:13 -0000
X-IronPort-AV: E=Sophos;i="4.80,417,1344211200"; d="scan'208";a="14529492"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Sep 2012 18:36: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.279.1; Thu, 13 Sep 2012 19:36: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 1TCEGq-0000aW-FD;
	Thu, 13 Sep 2012 18:36:12 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1TCEGq-0003qe-Ep;
	Thu, 13 Sep 2012 19:36:12 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-13737-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 13 Sep 2012 19:36:12 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13737: regressions - trouble:
	blocked/broken/fail/pass
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 13737 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13737/

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. 13668
 build-i386                    4 xen-build                 fail REGR. vs. 13668
 test-amd64-amd64-xl-win       2 hosts-allocate          broken REGR. vs. 13668

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore            fail   like 13668
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail like 13668
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail like 13668

Tests which did not succeed, but are not blocking:
 test-amd64-i386-rhel6hvm-amd  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 xen-build-check(1)           blocked n/a
 test-amd64-i386-rhel6hvm-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   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-xl-credit2    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-multivcpu  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 xen-build-check(1)         blocked n/a
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-pv            1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-win-vcpus1    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-winxpsp3-vcpus1  1 xen-build-check(1)           blocked n/a
 test-amd64-i386-xl            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pair          1 xen-build-check(1)           blocked  n/a

version targeted for testing:
 xen                  5691e4cc17da
baseline version:
 xen                  7d770de90b7f

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@citrix.com>
  Boris Ostrovsky <boris.ostrovsky@amd.com>
  Christoph Egger <Christoph.Egger@amd.com>
  Dan Magenheimer <dan.magenheimer@oracle.com>
  David Vrabel <david.vrabel@citrix.com>
  Ian Campbell <ian.campbell@citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Keir Fraser <keir@xen.org>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Wei Wang <wei.wang2@amd.com>
  Zhenzhong Duan <zhenzhong.duan@oracle.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   fail    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           fail    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           blocked 
 test-amd64-i386-rhel6hvm-amd                                 blocked 
 test-amd64-i386-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-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-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-amd64-amd64-xl-win                                      broken  
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                blocked 
 test-amd64-amd64-xl-winxpsp3                                 fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

(No revision log; it would be 775 lines long.)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 13 19:02:49 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Sep 2012 19: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 1TCEgH-0004qx-5U; Thu, 13 Sep 2012 19:02: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 1TCEgE-0004qr-TS
	for Xen-devel@lists.xensource.com; Thu, 13 Sep 2012 19:02:27 +0000
Received: from [85.158.139.83:18952] by server-4.bemta-5.messagelabs.com id
	AC/80-23042-2CD22505; Thu, 13 Sep 2012 19:02:26 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1347562945!23164521!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDkwMjg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29875 invoked from network); 13 Sep 2012 19:02:25 -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 Sep 2012 19:02:25 -0000
X-IronPort-AV: E=Sophos;i="4.80,418,1344211200"; d="scan'208";a="14530444"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Sep 2012 19:01:33 +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.279.1;
	Thu, 13 Sep 2012 20:01:33 +0100
Message-ID: <1347562892.25803.66.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Mukesh Rathor <mukesh.rathor@oracle.com>
Date: Thu, 13 Sep 2012 20:01:32 +0100
In-Reply-To: <20120913112753.3fa731ec@mantra.us.oracle.com>
References: <20120815180716.0049bffe@mantra.us.oracle.com>
	<1347372623.5305.170.camel@zakaz.uk.xensource.com>
	<20120912181910.6b0b9d2b@mantra.us.oracle.com>
	<1347536266.24226.97.camel@zakaz.uk.xensource.com>
	<20120913112753.3fa731ec@mantra.us.oracle.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [RFC PATCH 8/8]: PVH: privcmd changes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-09-13 at 19:27 +0100, Mukesh Rathor wrote:
> > I suppose it depends on whether the core "takes over" the reference
> > which you hold. I think it doesn't, so this is just a leak, rather
> > than putting a ballooned page back into the general allocation pool
> > (things would be crashing left & right if it was doing this I reckon)
> > 
> > > 
> > > I had looked for other hooks initially when I did this, but 
> > > vm_operations_struct->close was the only one to pan out.
> > > 
> > > I can't really move pvh_privcmd_resv_pfns to mmu.c because the 
> > > xen_remap_domain_mfn_range is called one page at a time, and I need
> > > to allocate the array first. I'd have to change it to linked list,
> > > worth it? Or I'd have to move and export it.
> > 
> > Another alternative would be to add the page array as a parameter to
> > the map/unmap function, rather than relying on it propagating via
> > vma_private.
> 
> I thought it was a no-no to change an exported API. Konrad, is it OK
> to change an exported API like xen_remap_domain_mfn_range, I mean, are
> there any guidelines?

You are thinking of system calls, which cannot be changed.

Kernel internal APIs, including those exported to modules are fair game
to change. See Documentation/stable_api_nonsense.txt.

Ian.

> 
> 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 Sep 13 19:02:49 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Sep 2012 19: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 1TCEgH-0004qx-5U; Thu, 13 Sep 2012 19:02: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 1TCEgE-0004qr-TS
	for Xen-devel@lists.xensource.com; Thu, 13 Sep 2012 19:02:27 +0000
Received: from [85.158.139.83:18952] by server-4.bemta-5.messagelabs.com id
	AC/80-23042-2CD22505; Thu, 13 Sep 2012 19:02:26 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1347562945!23164521!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDkwMjg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29875 invoked from network); 13 Sep 2012 19:02:25 -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 Sep 2012 19:02:25 -0000
X-IronPort-AV: E=Sophos;i="4.80,418,1344211200"; d="scan'208";a="14530444"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Sep 2012 19:01:33 +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.279.1;
	Thu, 13 Sep 2012 20:01:33 +0100
Message-ID: <1347562892.25803.66.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Mukesh Rathor <mukesh.rathor@oracle.com>
Date: Thu, 13 Sep 2012 20:01:32 +0100
In-Reply-To: <20120913112753.3fa731ec@mantra.us.oracle.com>
References: <20120815180716.0049bffe@mantra.us.oracle.com>
	<1347372623.5305.170.camel@zakaz.uk.xensource.com>
	<20120912181910.6b0b9d2b@mantra.us.oracle.com>
	<1347536266.24226.97.camel@zakaz.uk.xensource.com>
	<20120913112753.3fa731ec@mantra.us.oracle.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [RFC PATCH 8/8]: PVH: privcmd changes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-09-13 at 19:27 +0100, Mukesh Rathor wrote:
> > I suppose it depends on whether the core "takes over" the reference
> > which you hold. I think it doesn't, so this is just a leak, rather
> > than putting a ballooned page back into the general allocation pool
> > (things would be crashing left & right if it was doing this I reckon)
> > 
> > > 
> > > I had looked for other hooks initially when I did this, but 
> > > vm_operations_struct->close was the only one to pan out.
> > > 
> > > I can't really move pvh_privcmd_resv_pfns to mmu.c because the 
> > > xen_remap_domain_mfn_range is called one page at a time, and I need
> > > to allocate the array first. I'd have to change it to linked list,
> > > worth it? Or I'd have to move and export it.
> > 
> > Another alternative would be to add the page array as a parameter to
> > the map/unmap function, rather than relying on it propagating via
> > vma_private.
> 
> I thought it was a no-no to change an exported API. Konrad, is it OK
> to change an exported API like xen_remap_domain_mfn_range, I mean, are
> there any guidelines?

You are thinking of system calls, which cannot be changed.

Kernel internal APIs, including those exported to modules are fair game
to change. See Documentation/stable_api_nonsense.txt.

Ian.

> 
> 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 Sep 13 19:06:00 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Sep 2012 19:06:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TCEjL-0004ym-P4; Thu, 13 Sep 2012 19:05:39 +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 1TCEjK-0004yW-Jg
	for Xen-devel@lists.xensource.com; Thu, 13 Sep 2012 19:05:38 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1347563130!9826701!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzM4ODI0\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27662 invoked from network); 13 Sep 2012 19:05:32 -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; 13 Sep 2012 19:05:32 -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 q8DJ5Oit026076
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 13 Sep 2012 19:05:24 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q8DJ5Nek028590
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 13 Sep 2012 19:05:24 GMT
Received: from abhmt104.oracle.com (abhmt104.oracle.com [141.146.116.56])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q8DJ5Nus003744; Thu, 13 Sep 2012 14:05:23 -0500
Received: from konrad-lan.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 13 Sep 2012 12:05:23 -0700
Date: Thu, 13 Sep 2012 15:05:27 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Mukesh Rathor <mukesh.rathor@oracle.com>
Message-ID: <20120913190527.GA5861@konrad-lan.dumpdata.com>
References: <20120815180716.0049bffe@mantra.us.oracle.com>
	<1347372623.5305.170.camel@zakaz.uk.xensource.com>
	<20120912181910.6b0b9d2b@mantra.us.oracle.com>
	<1347536266.24226.97.camel@zakaz.uk.xensource.com>
	<20120913112753.3fa731ec@mantra.us.oracle.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120913112753.3fa731ec@mantra.us.oracle.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] [RFC PATCH 8/8]: PVH: privcmd changes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Sep 13, 2012 at 11:27:53AM -0700, Mukesh Rathor wrote:
> > I suppose it depends on whether the core "takes over" the reference
> > which you hold. I think it doesn't, so this is just a leak, rather
> > than putting a ballooned page back into the general allocation pool
> > (things would be crashing left & right if it was doing this I reckon)
> > 
> > > 
> > > I had looked for other hooks initially when I did this, but 
> > > vm_operations_struct->close was the only one to pan out.
> > > 
> > > I can't really move pvh_privcmd_resv_pfns to mmu.c because the 
> > > xen_remap_domain_mfn_range is called one page at a time, and I need
> > > to allocate the array first. I'd have to change it to linked list,
> > > worth it? Or I'd have to move and export it.
> > 
> > Another alternative would be to add the page array as a parameter to
> > the map/unmap function, rather than relying on it propagating via
> > vma_private.
> 
> I thought it was a no-no to change an exported API. Konrad, is it OK
> to change an exported API like xen_remap_domain_mfn_range, I mean, are
> there any guidelines?

Make it work right. We (upstream) don't care about APIs stability. Only
distros need to do it.
> 
> thanks,
> Mukesh
> 
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 13 19:06:00 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Sep 2012 19:06:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TCEjL-0004ym-P4; Thu, 13 Sep 2012 19:05:39 +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 1TCEjK-0004yW-Jg
	for Xen-devel@lists.xensource.com; Thu, 13 Sep 2012 19:05:38 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1347563130!9826701!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzM4ODI0\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27662 invoked from network); 13 Sep 2012 19:05:32 -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; 13 Sep 2012 19:05:32 -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 q8DJ5Oit026076
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 13 Sep 2012 19:05:24 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q8DJ5Nek028590
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 13 Sep 2012 19:05:24 GMT
Received: from abhmt104.oracle.com (abhmt104.oracle.com [141.146.116.56])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q8DJ5Nus003744; Thu, 13 Sep 2012 14:05:23 -0500
Received: from konrad-lan.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 13 Sep 2012 12:05:23 -0700
Date: Thu, 13 Sep 2012 15:05:27 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Mukesh Rathor <mukesh.rathor@oracle.com>
Message-ID: <20120913190527.GA5861@konrad-lan.dumpdata.com>
References: <20120815180716.0049bffe@mantra.us.oracle.com>
	<1347372623.5305.170.camel@zakaz.uk.xensource.com>
	<20120912181910.6b0b9d2b@mantra.us.oracle.com>
	<1347536266.24226.97.camel@zakaz.uk.xensource.com>
	<20120913112753.3fa731ec@mantra.us.oracle.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120913112753.3fa731ec@mantra.us.oracle.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] [RFC PATCH 8/8]: PVH: privcmd changes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Sep 13, 2012 at 11:27:53AM -0700, Mukesh Rathor wrote:
> > I suppose it depends on whether the core "takes over" the reference
> > which you hold. I think it doesn't, so this is just a leak, rather
> > than putting a ballooned page back into the general allocation pool
> > (things would be crashing left & right if it was doing this I reckon)
> > 
> > > 
> > > I had looked for other hooks initially when I did this, but 
> > > vm_operations_struct->close was the only one to pan out.
> > > 
> > > I can't really move pvh_privcmd_resv_pfns to mmu.c because the 
> > > xen_remap_domain_mfn_range is called one page at a time, and I need
> > > to allocate the array first. I'd have to change it to linked list,
> > > worth it? Or I'd have to move and export it.
> > 
> > Another alternative would be to add the page array as a parameter to
> > the map/unmap function, rather than relying on it propagating via
> > vma_private.
> 
> I thought it was a no-no to change an exported API. Konrad, is it OK
> to change an exported API like xen_remap_domain_mfn_range, I mean, are
> there any guidelines?

Make it work right. We (upstream) don't care about APIs stability. Only
distros need to do it.
> 
> thanks,
> Mukesh
> 
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 13 20:43:38 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Sep 2012 20:43: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 1TCGFk-0005lk-0H; Thu, 13 Sep 2012 20:43:12 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ketuzsezr@gmail.com>) id 1TCGFi-0005lf-H3
	for xen-devel@lists.xen.org; Thu, 13 Sep 2012 20:43:10 +0000
Received: from [85.158.139.83:54989] by server-1.bemta-5.messagelabs.com id
	CF/7C-32692-D5542505; Thu, 13 Sep 2012 20:43:09 +0000
X-Env-Sender: ketuzsezr@gmail.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1347568986!26127234!1
X-Originating-IP: [209.85.210.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28775 invoked from network); 13 Sep 2012 20:43:08 -0000
Received: from mail-pz0-f45.google.com (HELO mail-pz0-f45.google.com)
	(209.85.210.45)
	by server-14.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Sep 2012 20:43:08 -0000
Received: by dadn15 with SMTP id n15so2001272dad.32
	for <xen-devel@lists.xen.org>; Thu, 13 Sep 2012 13:43:06 -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=41/6+x08L22X8YfVSUwoyM6Y8O+ki5tQVvlL1CnyhQA=;
	b=Gw2pzRWirw7OH9oXErUI1+DYg3zxVZKhMfiaRzpjrM/e9TxrLPlwY6UC0HNyxdmpkE
	1yVkP7Dgw5aSwTOMdoOr0pKh7z3o5O04/59/PXQa6BHXq3v3K7m9obijjAvkKkfStRdB
	SxzR8ZShH4Na58nMap+rfmxwwiVFq/BJiI+p2bLZkeontJUSHdw+EECRa2S/zExrHnFs
	enq/g/YsFQ+XfwM178LkX6zKxlIIAKMNr/3N7TlqPWd3zrK4gmz4+VYD0NNhZoNjcspF
	NAg/YPTg8f2CD30FHOoTSo2VORkTOQHSGSCbLzSQALWK8RwfF/a0C6sI6sJTYjrtF3I2
	XdTA==
MIME-Version: 1.0
Received: by 10.68.228.132 with SMTP id si4mr1185927pbc.57.1347568986376; Thu,
	13 Sep 2012 13:43:06 -0700 (PDT)
Received: by 10.66.193.9 with HTTP; Thu, 13 Sep 2012 13:43:06 -0700 (PDT)
In-Reply-To: <CC77B7E8.3EB00%keir.xen@gmail.com>
References: <20120913151114.GE12881@ocelot.phlegethon.org>
	<CC77B7E8.3EB00%keir.xen@gmail.com>
Date: Thu, 13 Sep 2012 16:43:06 -0400
X-Google-Sender-Auth: 8PyXhQb-_V50nFS_I-PSDcbpO4E
Message-ID: <CACJDEmo7EbT+e0oSvnYGntX=ZKg65U2EGhhDpUKURF6xjw=Fpg@mail.gmail.com>
From: Konrad Rzeszutek Wilk <konrad@kernel.org>
To: Keir Fraser <keir.xen@gmail.com>, mukesh.rathor@oracle.com
Cc: Tim Deegan <tim@xen.org>, Jan Beulich <JBeulich@suse.com>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] x86/mm: remove the linear mapping of the
	p2m tables
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Sep 13, 2012 at 11:18 AM, Keir Fraser <keir.xen@gmail.com> wrote:
> On 13/09/2012 16:11, "Tim Deegan" <tim@xen.org> wrote:
>
>> At 15:58 +0100 on 13 Sep (1347551914), Keir Fraser wrote:
>>> On 13/09/2012 15:42, "Tim Deegan" <tim@xen.org> wrote:
>>>
>>>>> Is that also going to remain true when we won't be able to 1:1-
>>>>> map all of the memory anymore once we break the current 5Tb
>>>>> barrier? If not, it would probably be worthwhile keeping that
>>>>> code.
>>>>
>>>> Ah, 5TB is a smaller limit than I thought we had.  Yes, better leave it
>>>> alone, so.  Though TBH finding some way to use a bit more virtual
>>>> address space for Xen seems like a good idea anyway, since this won't be
>>>> the only place we'll want to avoid TLB flushes.
>>>
>>> For HVM or PVH guests, where this HAP code would be used, clearly Xen can
>>> use all the virtual address space it wants. It will almost certainly make
>>> sense for Xen to have a 1:1 physical mapping of all memory when running such
>>> a guest, and only do mapcache type tricks when running legacy PV guests.
>>
>> This is also used for shadowed guests, including autotranslated PV
>> guests, if anyone cares about them any more.  I got the impression that
>> they're superseded by the pvh stuff; is that right?
>
> Auto-translated PV seems to be one of those unsupported things that never
> quite dies. With PVH just round the corner, let's definitively call it dead.
> :)

I thought we discussed that we need this as backup for running older guests?
BTW, the auto-xlat is what PVH is advertising to the PV guest.

CC-ing Mukesh here

>
>> If that's the case, then let's commit to having a bigger 1-1 map on HVM
>> guetst when the time comes to extend past 5TB, and remove this linear
>> map after all.
>
> I agree.


>
>  -- Keir
>
>> Tim.
>
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 13 20:43:38 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Sep 2012 20:43: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 1TCGFk-0005lk-0H; Thu, 13 Sep 2012 20:43:12 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ketuzsezr@gmail.com>) id 1TCGFi-0005lf-H3
	for xen-devel@lists.xen.org; Thu, 13 Sep 2012 20:43:10 +0000
Received: from [85.158.139.83:54989] by server-1.bemta-5.messagelabs.com id
	CF/7C-32692-D5542505; Thu, 13 Sep 2012 20:43:09 +0000
X-Env-Sender: ketuzsezr@gmail.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1347568986!26127234!1
X-Originating-IP: [209.85.210.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28775 invoked from network); 13 Sep 2012 20:43:08 -0000
Received: from mail-pz0-f45.google.com (HELO mail-pz0-f45.google.com)
	(209.85.210.45)
	by server-14.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Sep 2012 20:43:08 -0000
Received: by dadn15 with SMTP id n15so2001272dad.32
	for <xen-devel@lists.xen.org>; Thu, 13 Sep 2012 13:43:06 -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=41/6+x08L22X8YfVSUwoyM6Y8O+ki5tQVvlL1CnyhQA=;
	b=Gw2pzRWirw7OH9oXErUI1+DYg3zxVZKhMfiaRzpjrM/e9TxrLPlwY6UC0HNyxdmpkE
	1yVkP7Dgw5aSwTOMdoOr0pKh7z3o5O04/59/PXQa6BHXq3v3K7m9obijjAvkKkfStRdB
	SxzR8ZShH4Na58nMap+rfmxwwiVFq/BJiI+p2bLZkeontJUSHdw+EECRa2S/zExrHnFs
	enq/g/YsFQ+XfwM178LkX6zKxlIIAKMNr/3N7TlqPWd3zrK4gmz4+VYD0NNhZoNjcspF
	NAg/YPTg8f2CD30FHOoTSo2VORkTOQHSGSCbLzSQALWK8RwfF/a0C6sI6sJTYjrtF3I2
	XdTA==
MIME-Version: 1.0
Received: by 10.68.228.132 with SMTP id si4mr1185927pbc.57.1347568986376; Thu,
	13 Sep 2012 13:43:06 -0700 (PDT)
Received: by 10.66.193.9 with HTTP; Thu, 13 Sep 2012 13:43:06 -0700 (PDT)
In-Reply-To: <CC77B7E8.3EB00%keir.xen@gmail.com>
References: <20120913151114.GE12881@ocelot.phlegethon.org>
	<CC77B7E8.3EB00%keir.xen@gmail.com>
Date: Thu, 13 Sep 2012 16:43:06 -0400
X-Google-Sender-Auth: 8PyXhQb-_V50nFS_I-PSDcbpO4E
Message-ID: <CACJDEmo7EbT+e0oSvnYGntX=ZKg65U2EGhhDpUKURF6xjw=Fpg@mail.gmail.com>
From: Konrad Rzeszutek Wilk <konrad@kernel.org>
To: Keir Fraser <keir.xen@gmail.com>, mukesh.rathor@oracle.com
Cc: Tim Deegan <tim@xen.org>, Jan Beulich <JBeulich@suse.com>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] x86/mm: remove the linear mapping of the
	p2m tables
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Sep 13, 2012 at 11:18 AM, Keir Fraser <keir.xen@gmail.com> wrote:
> On 13/09/2012 16:11, "Tim Deegan" <tim@xen.org> wrote:
>
>> At 15:58 +0100 on 13 Sep (1347551914), Keir Fraser wrote:
>>> On 13/09/2012 15:42, "Tim Deegan" <tim@xen.org> wrote:
>>>
>>>>> Is that also going to remain true when we won't be able to 1:1-
>>>>> map all of the memory anymore once we break the current 5Tb
>>>>> barrier? If not, it would probably be worthwhile keeping that
>>>>> code.
>>>>
>>>> Ah, 5TB is a smaller limit than I thought we had.  Yes, better leave it
>>>> alone, so.  Though TBH finding some way to use a bit more virtual
>>>> address space for Xen seems like a good idea anyway, since this won't be
>>>> the only place we'll want to avoid TLB flushes.
>>>
>>> For HVM or PVH guests, where this HAP code would be used, clearly Xen can
>>> use all the virtual address space it wants. It will almost certainly make
>>> sense for Xen to have a 1:1 physical mapping of all memory when running such
>>> a guest, and only do mapcache type tricks when running legacy PV guests.
>>
>> This is also used for shadowed guests, including autotranslated PV
>> guests, if anyone cares about them any more.  I got the impression that
>> they're superseded by the pvh stuff; is that right?
>
> Auto-translated PV seems to be one of those unsupported things that never
> quite dies. With PVH just round the corner, let's definitively call it dead.
> :)

I thought we discussed that we need this as backup for running older guests?
BTW, the auto-xlat is what PVH is advertising to the PV guest.

CC-ing Mukesh here

>
>> If that's the case, then let's commit to having a bigger 1-1 map on HVM
>> guetst when the time comes to extend past 5TB, and remove this linear
>> map after all.
>
> I agree.


>
>  -- Keir
>
>> Tim.
>
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 13 20:46:23 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Sep 2012 20: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 1TCGIV-0005t4-RL; Thu, 13 Sep 2012 20:46:03 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ketuzsezr@gmail.com>) id 1TCGIT-0005ss-Oa
	for Xen-devel@lists.xensource.com; Thu, 13 Sep 2012 20:46:02 +0000
X-Env-Sender: ketuzsezr@gmail.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1347569151!3935029!1
X-Originating-IP: [209.85.160.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14781 invoked from network); 13 Sep 2012 20:45:53 -0000
Received: from mail-pb0-f43.google.com (HELO mail-pb0-f43.google.com)
	(209.85.160.43)
	by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Sep 2012 20:45:53 -0000
Received: by pbbrq2 with SMTP id rq2so5452279pbb.30
	for <Xen-devel@lists.xensource.com>;
	Thu, 13 Sep 2012 13:45:51 -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=v/iNU8BrSLo04bcWVyzESE0QnVekfT6CLqMx6upaaPc=;
	b=J0rlHXaiv0XwBph1bsqMyWOmSJ3YWpk5doQ/y9BZkaxjK7Zsjy99r/hTCpAy9e61gW
	D92mDIG2fJQKNrPqjUZm9bJPGWz/gWhDOZRCk95WVF9JctVKwoIuSowqfYMiCkb+4S67
	OqpjQqsZmI+Ovrwoi3rwlGUAPtzeIer1sPTQFCsPdEbnnvw+x8T4V5F2sjP25mPysMMP
	2P9GiV0Xlk3Q4nVoCzvo5QuCUlRczfww+qIQHYlrtb64U5swTRotJImgUPM8Xiu6mwF7
	i9ymQyQQe2IJlnn5VqE7e0BP5rplSMCGGwJgDq2vt/vYrN3FBXHeJcORw+Iw0zwF0anP
	8OSA==
MIME-Version: 1.0
Received: by 10.68.218.196 with SMTP id pi4mr1074376pbc.128.1347569151176;
	Thu, 13 Sep 2012 13:45:51 -0700 (PDT)
Received: by 10.66.193.9 with HTTP; Thu, 13 Sep 2012 13:45:51 -0700 (PDT)
In-Reply-To: <1347559708.25803.61.camel@dagon.hellion.org.uk>
References: <20120815175724.3405043a@mantra.us.oracle.com>
	<1347285352.5305.86.camel@zakaz.uk.xensource.com>
	<20120911145751.599b8292@mantra.us.oracle.com>
	<1347437545.25803.16.camel@dagon.hellion.org.uk>
	<20120912110254.10bde333@mantra.us.oracle.com>
	<1347474380.25803.21.camel@dagon.hellion.org.uk>
	<20120912123238.7057c51a@mantra.us.oracle.com>
	<1347516007.25803.44.camel@dagon.hellion.org.uk>
	<20120913101439.6bd363a9@mantra.us.oracle.com>
	<20120913173639.GY8912@reaktio.net>
	<1347559708.25803.61.camel@dagon.hellion.org.uk>
Date: Thu, 13 Sep 2012 16:45:51 -0400
X-Google-Sender-Auth: cnyVeE0UjMzr31H9aLBpR5XCco4
Message-ID: <CACJDEmoJrcThdmyWLGTWXCbv-GBvYwa8OZohbbZDykMb=n8o_w@mail.gmail.com>
From: Konrad Rzeszutek Wilk <konrad@kernel.org>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: "Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [RFC PATCH 1/8]: PVH: Basic and preparatory 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="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, Sep 13, 2012 at 2:08 PM, Ian Campbell <Ian.Campbell@citrix.com> wro=
te:
> On Thu, 2012-09-13 at 18:36 +0100, Pasi K=E4rkk=E4inen wrote:
>> On Thu, Sep 13, 2012 at 10:14:39AM -0700, Mukesh Rathor wrote:
>> > On Thu, 13 Sep 2012 07:00:07 +0100
>> > Ian Campbell <Ian.Campbell@citrix.com> wrote:
>> > > The toolstack (or the dom0 builder) can make the determination wheth=
er
>> > > to enable this mode itself itself based on the notes (although it is
>> > > always handy to have an override to force things for debug).
>> >
>> > Hmmm... So you are suggesting that if hardware and xen supports it, th=
en
>> > PV should just boot in PVH mode and user has no way to override it. I
>> > don't know if that's a good idea in the short term, perhaps in the long
>> > term. Let me discuss with folks here a bit.
>> >
>>
>> I read that as "if hardware, xen and kernel supports PVH, enable it as a=
 default,
>> but still allow the user to force enable/disable it in the domain cfgfil=
e for easier debugging".
>
> That's right. I have no objection to an override, in fact I think it's a
> requirement to be able to force this sort of feature on/off (to aid for
> debugging, account for differing workload requirements and allowing the
> test system to test both configurations etc).
>
> Long term the aim should be for the default to be on whenever possible.
> Maybe the default should remain off for the time being, or maybe we want
> to get as much exposure of PVH as possible ASAP, which would argue for
> it being on by default in unstable, perhaps with a decision being made
> around freeze time as to the default in 4.3.
>
> The feature declarations in the ELF note also allow the toolstack to
> sanity check what the user asked for and report an error if it isn't
> possible, rather than booting a kernel in a mode which cannot possibly
> work.

We can also punt the decision to the guest. Meaning it can have one of
those features flags saying: "I_WANT_PVH"

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 13 20:46:23 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Sep 2012 20: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 1TCGIV-0005t4-RL; Thu, 13 Sep 2012 20:46:03 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ketuzsezr@gmail.com>) id 1TCGIT-0005ss-Oa
	for Xen-devel@lists.xensource.com; Thu, 13 Sep 2012 20:46:02 +0000
X-Env-Sender: ketuzsezr@gmail.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1347569151!3935029!1
X-Originating-IP: [209.85.160.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14781 invoked from network); 13 Sep 2012 20:45:53 -0000
Received: from mail-pb0-f43.google.com (HELO mail-pb0-f43.google.com)
	(209.85.160.43)
	by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Sep 2012 20:45:53 -0000
Received: by pbbrq2 with SMTP id rq2so5452279pbb.30
	for <Xen-devel@lists.xensource.com>;
	Thu, 13 Sep 2012 13:45:51 -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=v/iNU8BrSLo04bcWVyzESE0QnVekfT6CLqMx6upaaPc=;
	b=J0rlHXaiv0XwBph1bsqMyWOmSJ3YWpk5doQ/y9BZkaxjK7Zsjy99r/hTCpAy9e61gW
	D92mDIG2fJQKNrPqjUZm9bJPGWz/gWhDOZRCk95WVF9JctVKwoIuSowqfYMiCkb+4S67
	OqpjQqsZmI+Ovrwoi3rwlGUAPtzeIer1sPTQFCsPdEbnnvw+x8T4V5F2sjP25mPysMMP
	2P9GiV0Xlk3Q4nVoCzvo5QuCUlRczfww+qIQHYlrtb64U5swTRotJImgUPM8Xiu6mwF7
	i9ymQyQQe2IJlnn5VqE7e0BP5rplSMCGGwJgDq2vt/vYrN3FBXHeJcORw+Iw0zwF0anP
	8OSA==
MIME-Version: 1.0
Received: by 10.68.218.196 with SMTP id pi4mr1074376pbc.128.1347569151176;
	Thu, 13 Sep 2012 13:45:51 -0700 (PDT)
Received: by 10.66.193.9 with HTTP; Thu, 13 Sep 2012 13:45:51 -0700 (PDT)
In-Reply-To: <1347559708.25803.61.camel@dagon.hellion.org.uk>
References: <20120815175724.3405043a@mantra.us.oracle.com>
	<1347285352.5305.86.camel@zakaz.uk.xensource.com>
	<20120911145751.599b8292@mantra.us.oracle.com>
	<1347437545.25803.16.camel@dagon.hellion.org.uk>
	<20120912110254.10bde333@mantra.us.oracle.com>
	<1347474380.25803.21.camel@dagon.hellion.org.uk>
	<20120912123238.7057c51a@mantra.us.oracle.com>
	<1347516007.25803.44.camel@dagon.hellion.org.uk>
	<20120913101439.6bd363a9@mantra.us.oracle.com>
	<20120913173639.GY8912@reaktio.net>
	<1347559708.25803.61.camel@dagon.hellion.org.uk>
Date: Thu, 13 Sep 2012 16:45:51 -0400
X-Google-Sender-Auth: cnyVeE0UjMzr31H9aLBpR5XCco4
Message-ID: <CACJDEmoJrcThdmyWLGTWXCbv-GBvYwa8OZohbbZDykMb=n8o_w@mail.gmail.com>
From: Konrad Rzeszutek Wilk <konrad@kernel.org>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: "Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [RFC PATCH 1/8]: PVH: Basic and preparatory 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="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, Sep 13, 2012 at 2:08 PM, Ian Campbell <Ian.Campbell@citrix.com> wro=
te:
> On Thu, 2012-09-13 at 18:36 +0100, Pasi K=E4rkk=E4inen wrote:
>> On Thu, Sep 13, 2012 at 10:14:39AM -0700, Mukesh Rathor wrote:
>> > On Thu, 13 Sep 2012 07:00:07 +0100
>> > Ian Campbell <Ian.Campbell@citrix.com> wrote:
>> > > The toolstack (or the dom0 builder) can make the determination wheth=
er
>> > > to enable this mode itself itself based on the notes (although it is
>> > > always handy to have an override to force things for debug).
>> >
>> > Hmmm... So you are suggesting that if hardware and xen supports it, th=
en
>> > PV should just boot in PVH mode and user has no way to override it. I
>> > don't know if that's a good idea in the short term, perhaps in the long
>> > term. Let me discuss with folks here a bit.
>> >
>>
>> I read that as "if hardware, xen and kernel supports PVH, enable it as a=
 default,
>> but still allow the user to force enable/disable it in the domain cfgfil=
e for easier debugging".
>
> That's right. I have no objection to an override, in fact I think it's a
> requirement to be able to force this sort of feature on/off (to aid for
> debugging, account for differing workload requirements and allowing the
> test system to test both configurations etc).
>
> Long term the aim should be for the default to be on whenever possible.
> Maybe the default should remain off for the time being, or maybe we want
> to get as much exposure of PVH as possible ASAP, which would argue for
> it being on by default in unstable, perhaps with a decision being made
> around freeze time as to the default in 4.3.
>
> The feature declarations in the ELF note also allow the toolstack to
> sanity check what the user asked for and report an error if it isn't
> possible, rather than booting a kernel in a mode which cannot possibly
> work.

We can also punt the decision to the guest. Meaning it can have one of
those features flags saying: "I_WANT_PVH"

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 13 21:09:45 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Sep 2012 21: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 1TCGf1-0006AE-1D; Thu, 13 Sep 2012 21: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 1TCGez-0006A9-Q1
	for Xen-devel@lists.xensource.com; Thu, 13 Sep 2012 21:09:17 +0000
Received: from [85.158.143.35:30147] by server-1.bemta-4.messagelabs.com id
	E9/8D-12504-D7B42505; Thu, 13 Sep 2012 21:09:17 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1347570556!16792376!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDkwMjg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21607 invoked from network); 13 Sep 2012 21:09:16 -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 Sep 2012 21:09:16 -0000
X-IronPort-AV: E=Sophos;i="4.80,419,1344211200"; d="scan'208";a="14532115"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Sep 2012 21:09:16 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Thu, 13 Sep 2012 22:09:15 +0100
Message-ID: <1347570554.25803.67.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Konrad Rzeszutek Wilk <konrad@kernel.org>
Date: Thu, 13 Sep 2012 22:09:14 +0100
In-Reply-To: <CACJDEmoJrcThdmyWLGTWXCbv-GBvYwa8OZohbbZDykMb=n8o_w@mail.gmail.com>
References: <20120815175724.3405043a@mantra.us.oracle.com>
	<1347285352.5305.86.camel@zakaz.uk.xensource.com>
	<20120911145751.599b8292@mantra.us.oracle.com>
	<1347437545.25803.16.camel@dagon.hellion.org.uk>
	<20120912110254.10bde333@mantra.us.oracle.com>
	<1347474380.25803.21.camel@dagon.hellion.org.uk>
	<20120912123238.7057c51a@mantra.us.oracle.com>
	<1347516007.25803.44.camel@dagon.hellion.org.uk>
	<20120913101439.6bd363a9@mantra.us.oracle.com>
	<20120913173639.GY8912@reaktio.net>
	<1347559708.25803.61.camel@dagon.hellion.org.uk>
	<CACJDEmoJrcThdmyWLGTWXCbv-GBvYwa8OZohbbZDykMb=n8o_w@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [RFC PATCH 1/8]: PVH: Basic and preparatory changes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-09-13 at 21:45 +0100, Konrad Rzeszutek Wilk wrote:
> We can also punt the decision to the guest. Meaning it can have one of
> those features flags saying: "I_WANT_PVH"

Right. The ELF notes allow the kernel to specify both optionally
supported and required features.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 13 21:09:45 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Sep 2012 21: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 1TCGf1-0006AE-1D; Thu, 13 Sep 2012 21: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 1TCGez-0006A9-Q1
	for Xen-devel@lists.xensource.com; Thu, 13 Sep 2012 21:09:17 +0000
Received: from [85.158.143.35:30147] by server-1.bemta-4.messagelabs.com id
	E9/8D-12504-D7B42505; Thu, 13 Sep 2012 21:09:17 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1347570556!16792376!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDkwMjg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21607 invoked from network); 13 Sep 2012 21:09:16 -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 Sep 2012 21:09:16 -0000
X-IronPort-AV: E=Sophos;i="4.80,419,1344211200"; d="scan'208";a="14532115"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Sep 2012 21:09:16 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Thu, 13 Sep 2012 22:09:15 +0100
Message-ID: <1347570554.25803.67.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Konrad Rzeszutek Wilk <konrad@kernel.org>
Date: Thu, 13 Sep 2012 22:09:14 +0100
In-Reply-To: <CACJDEmoJrcThdmyWLGTWXCbv-GBvYwa8OZohbbZDykMb=n8o_w@mail.gmail.com>
References: <20120815175724.3405043a@mantra.us.oracle.com>
	<1347285352.5305.86.camel@zakaz.uk.xensource.com>
	<20120911145751.599b8292@mantra.us.oracle.com>
	<1347437545.25803.16.camel@dagon.hellion.org.uk>
	<20120912110254.10bde333@mantra.us.oracle.com>
	<1347474380.25803.21.camel@dagon.hellion.org.uk>
	<20120912123238.7057c51a@mantra.us.oracle.com>
	<1347516007.25803.44.camel@dagon.hellion.org.uk>
	<20120913101439.6bd363a9@mantra.us.oracle.com>
	<20120913173639.GY8912@reaktio.net>
	<1347559708.25803.61.camel@dagon.hellion.org.uk>
	<CACJDEmoJrcThdmyWLGTWXCbv-GBvYwa8OZohbbZDykMb=n8o_w@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [RFC PATCH 1/8]: PVH: Basic and preparatory changes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-09-13 at 21:45 +0100, Konrad Rzeszutek Wilk wrote:
> We can also punt the decision to the guest. Meaning it can have one of
> those features flags saying: "I_WANT_PVH"

Right. The ELF notes allow the kernel to specify both optionally
supported and required features.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 13 21:14:48 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Sep 2012 21:14:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TCGjx-0006Id-O7; Thu, 13 Sep 2012 21:14:25 +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 1TCGjv-0006IW-WE
	for xen-devel@lists.xen.org; Thu, 13 Sep 2012 21:14:24 +0000
Received: from [85.158.139.83:29467] by server-10.bemta-5.messagelabs.com id
	58/AE-10969-EAC42505; Thu, 13 Sep 2012 21:14:22 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1347570862!29859199!1
X-Originating-IP: [209.85.212.179]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11333 invoked from network); 13 Sep 2012 21:14:22 -0000
Received: from mail-wi0-f179.google.com (HELO mail-wi0-f179.google.com)
	(209.85.212.179)
	by server-13.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Sep 2012 21:14:22 -0000
Received: by wibhq4 with SMTP id hq4so3241050wib.14
	for <xen-devel@lists.xen.org>; Thu, 13 Sep 2012 14:14:22 -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=YcqKzxhTKiwYl9+ERfSqEozXmVpnI95pu0JXkE+wRZE=;
	b=LWPdjcQAlYqOz9YEyjyPbhLULxTncYuzeqaa3b5EEfW7zxcbZBXsaCl9/EXnO3WSHP
	xLUhvPAjTOxlGWIO01ap7IcEeE3AdeEHaIOq0bjNBjuuNmcXgBjSWH/AJE3j2ICZnu+3
	mepw4pvgsi5EnxMDsnJMdEdW46ROvHMkAmLut9wGtwNd33BWYFpmoxqE1TBURVneNmjb
	zWo8loTO0yoOqrEyiIvmt5DPocHbAMANpW8qWAlFJ4GB79ZbwEf++AlGzje5h810twX6
	6VbtHOnKRDrvCVP2SPcthzwd2x+cnF7s0tCipn0w25hF7LXDFSJemgVRcT3B6UBn3TRY
	CCnw==
Received: by 10.216.194.18 with SMTP id l18mr245777wen.132.1347570862100;
	Thu, 13 Sep 2012 14:14:22 -0700 (PDT)
Received: from [192.168.1.3] (host86-184-74-117.range86-184.btcentralplus.com.
	[86.184.74.117])
	by mx.google.com with ESMTPS id fb20sm23145403wid.1.2012.09.13.14.14.19
	(version=SSLv3 cipher=OTHER); Thu, 13 Sep 2012 14:14:20 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.33.0.120411
Date: Thu, 13 Sep 2012 22:14:16 +0100
From: Keir Fraser <keir@xen.org>
To: Konrad Rzeszutek Wilk <konrad@kernel.org>,
	Keir Fraser <keir.xen@gmail.com>, <mukesh.rathor@oracle.com>
Message-ID: <CC780B38.4BAEB%keir@xen.org>
Thread-Topic: [Xen-devel] [PATCH] x86/mm: remove the linear mapping of the p2m
	tables
Thread-Index: Ac2R9LsPFzy22w49C0+DnjBtl1Yleg==
In-Reply-To: <CACJDEmo7EbT+e0oSvnYGntX=ZKg65U2EGhhDpUKURF6xjw=Fpg@mail.gmail.com>
Mime-version: 1.0
Cc: Tim Deegan <tim@xen.org>, Jan Beulich <JBeulich@suse.com>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] x86/mm: remove the linear mapping of the
 p2m tables
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 13/09/2012 21:43, "Konrad Rzeszutek Wilk" <konrad@kernel.org> wrote:

>> Auto-translated PV seems to be one of those unsupported things that never
>> quite dies. With PVH just round the corner, let's definitively call it dead.
>> :)
> 
> I thought we discussed that we need this as backup for running older guests?

Don't think so, since we'll continue to run old guests as pure PV.

There was a backup for running on older CPUs, and that was to allow PVH
guests to run on shadow page tables. That's a totally separate compatibility
concern however.

> BTW, the auto-xlat is what PVH is advertising to the PV guest.

Yes, but it's auto-xlat in an HVM container. Pure PV auto-xlat is what we're
looking to kill here.

 -- Keir

> CC-ing Mukesh here



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 13 21:14:48 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Sep 2012 21:14:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TCGjx-0006Id-O7; Thu, 13 Sep 2012 21:14:25 +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 1TCGjv-0006IW-WE
	for xen-devel@lists.xen.org; Thu, 13 Sep 2012 21:14:24 +0000
Received: from [85.158.139.83:29467] by server-10.bemta-5.messagelabs.com id
	58/AE-10969-EAC42505; Thu, 13 Sep 2012 21:14:22 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1347570862!29859199!1
X-Originating-IP: [209.85.212.179]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11333 invoked from network); 13 Sep 2012 21:14:22 -0000
Received: from mail-wi0-f179.google.com (HELO mail-wi0-f179.google.com)
	(209.85.212.179)
	by server-13.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Sep 2012 21:14:22 -0000
Received: by wibhq4 with SMTP id hq4so3241050wib.14
	for <xen-devel@lists.xen.org>; Thu, 13 Sep 2012 14:14:22 -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=YcqKzxhTKiwYl9+ERfSqEozXmVpnI95pu0JXkE+wRZE=;
	b=LWPdjcQAlYqOz9YEyjyPbhLULxTncYuzeqaa3b5EEfW7zxcbZBXsaCl9/EXnO3WSHP
	xLUhvPAjTOxlGWIO01ap7IcEeE3AdeEHaIOq0bjNBjuuNmcXgBjSWH/AJE3j2ICZnu+3
	mepw4pvgsi5EnxMDsnJMdEdW46ROvHMkAmLut9wGtwNd33BWYFpmoxqE1TBURVneNmjb
	zWo8loTO0yoOqrEyiIvmt5DPocHbAMANpW8qWAlFJ4GB79ZbwEf++AlGzje5h810twX6
	6VbtHOnKRDrvCVP2SPcthzwd2x+cnF7s0tCipn0w25hF7LXDFSJemgVRcT3B6UBn3TRY
	CCnw==
Received: by 10.216.194.18 with SMTP id l18mr245777wen.132.1347570862100;
	Thu, 13 Sep 2012 14:14:22 -0700 (PDT)
Received: from [192.168.1.3] (host86-184-74-117.range86-184.btcentralplus.com.
	[86.184.74.117])
	by mx.google.com with ESMTPS id fb20sm23145403wid.1.2012.09.13.14.14.19
	(version=SSLv3 cipher=OTHER); Thu, 13 Sep 2012 14:14:20 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.33.0.120411
Date: Thu, 13 Sep 2012 22:14:16 +0100
From: Keir Fraser <keir@xen.org>
To: Konrad Rzeszutek Wilk <konrad@kernel.org>,
	Keir Fraser <keir.xen@gmail.com>, <mukesh.rathor@oracle.com>
Message-ID: <CC780B38.4BAEB%keir@xen.org>
Thread-Topic: [Xen-devel] [PATCH] x86/mm: remove the linear mapping of the p2m
	tables
Thread-Index: Ac2R9LsPFzy22w49C0+DnjBtl1Yleg==
In-Reply-To: <CACJDEmo7EbT+e0oSvnYGntX=ZKg65U2EGhhDpUKURF6xjw=Fpg@mail.gmail.com>
Mime-version: 1.0
Cc: Tim Deegan <tim@xen.org>, Jan Beulich <JBeulich@suse.com>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] x86/mm: remove the linear mapping of the
 p2m tables
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 13/09/2012 21:43, "Konrad Rzeszutek Wilk" <konrad@kernel.org> wrote:

>> Auto-translated PV seems to be one of those unsupported things that never
>> quite dies. With PVH just round the corner, let's definitively call it dead.
>> :)
> 
> I thought we discussed that we need this as backup for running older guests?

Don't think so, since we'll continue to run old guests as pure PV.

There was a backup for running on older CPUs, and that was to allow PVH
guests to run on shadow page tables. That's a totally separate compatibility
concern however.

> BTW, the auto-xlat is what PVH is advertising to the PV guest.

Yes, but it's auto-xlat in an HVM container. Pure PV auto-xlat is what we're
looking to kill here.

 -- Keir

> CC-ing Mukesh here



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 13 23:20:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Sep 2012 23:20:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TCIh2-00075U-Rc; Thu, 13 Sep 2012 23:19: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 1TCIh1-00075P-23
	for xen-devel@lists.xensource.com; Thu, 13 Sep 2012 23:19:31 +0000
Received: from [85.158.143.99:15495] by server-1.bemta-4.messagelabs.com id
	36/F9-12504-20A62505; Thu, 13 Sep 2012 23:19:30 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1347578369!23247378!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDkxNTg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11399 invoked from network); 13 Sep 2012 23:19:29 -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;
	13 Sep 2012 23:19:29 -0000
X-IronPort-AV: E=Sophos;i="4.80,419,1344211200"; d="scan'208";a="14533361"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Sep 2012 23:19: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.279.1; Fri, 14 Sep 2012 00:19: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 1TCIgy-0002RW-Ic;
	Thu, 13 Sep 2012 23:19:28 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1TCIgy-0003YT-DN;
	Fri, 14 Sep 2012 00:19:28 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-13739-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 14 Sep 2012 00:19:28 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.2-testing test] 13739: 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 13739 xen-4.2-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13739/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore            fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-i386-i386-xl-qemuu-winxpsp3  9 guest-localmigrate         fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             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-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  4027d31caeb0
baseline version:
 xen                  7f993b289dc4

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@citrix.com>
  Ian Campbell <ian.campbell@citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Keir Fraser <keir@xen.org>
  Olaf Hering <olaf@aepfle.de>
  Pasi K?rkk?inen <pasik@iki.fi>
------------------------------------------------------------

jobs:
 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                                 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                                     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-4.2-testing
+ revision=4027d31caeb0
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push xen-4.2-testing 4027d31caeb0
+ branch=xen-4.2-testing
+ revision=4027d31caeb0
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-4.2-testing
+ '[' xxen = xlinux ']'
+ linuxbranch=linux
+ : master
+ : tested/2.6.39.x
+ . ap-common
++ : xen@xenbits.xensource.com
++ : http://xenbits.xen.org/hg/staging/xen-4.2-testing.hg
++ : git://xenbits.xen.org/staging/qemu-xen-4.2-testing.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : xen@xenbits.xensource.com:git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.xen-4.2-testing
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-4.2-testing.git
++ : daily-cron.xen-4.2-testing
+ TREE_LINUX=xen@xenbits.xensource.com:git/linux-pvops.git
+ TREE_QEMU_UPSTREAM=xen@xenbits.xensource.com:git/qemu-upstream-4.2-testing.git
+ info_linux_tree xen-4.2-testing
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/xen-4.2-testing.hg
+ hg push -r 4027d31caeb0 ssh://xen@xenbits.xensource.com/HG/xen-4.2-testing.hg
pushing to ssh://xen@xenbits.xensource.com/HG/xen-4.2-testing.hg
searching for changes
remote: adding changesets
remote: adding manifests
remote: adding file changes
remote: added 6 changesets with 6 changes to 6 files

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 13 23:20:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 13 Sep 2012 23:20:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TCIh2-00075U-Rc; Thu, 13 Sep 2012 23:19: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 1TCIh1-00075P-23
	for xen-devel@lists.xensource.com; Thu, 13 Sep 2012 23:19:31 +0000
Received: from [85.158.143.99:15495] by server-1.bemta-4.messagelabs.com id
	36/F9-12504-20A62505; Thu, 13 Sep 2012 23:19:30 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1347578369!23247378!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDkxNTg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11399 invoked from network); 13 Sep 2012 23:19:29 -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;
	13 Sep 2012 23:19:29 -0000
X-IronPort-AV: E=Sophos;i="4.80,419,1344211200"; d="scan'208";a="14533361"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Sep 2012 23:19: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.279.1; Fri, 14 Sep 2012 00:19: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 1TCIgy-0002RW-Ic;
	Thu, 13 Sep 2012 23:19:28 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1TCIgy-0003YT-DN;
	Fri, 14 Sep 2012 00:19:28 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-13739-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 14 Sep 2012 00:19:28 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.2-testing test] 13739: 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 13739 xen-4.2-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13739/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore            fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-i386-i386-xl-qemuu-winxpsp3  9 guest-localmigrate         fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             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-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  4027d31caeb0
baseline version:
 xen                  7f993b289dc4

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@citrix.com>
  Ian Campbell <ian.campbell@citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Keir Fraser <keir@xen.org>
  Olaf Hering <olaf@aepfle.de>
  Pasi K?rkk?inen <pasik@iki.fi>
------------------------------------------------------------

jobs:
 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                                 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                                     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-4.2-testing
+ revision=4027d31caeb0
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push xen-4.2-testing 4027d31caeb0
+ branch=xen-4.2-testing
+ revision=4027d31caeb0
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-4.2-testing
+ '[' xxen = xlinux ']'
+ linuxbranch=linux
+ : master
+ : tested/2.6.39.x
+ . ap-common
++ : xen@xenbits.xensource.com
++ : http://xenbits.xen.org/hg/staging/xen-4.2-testing.hg
++ : git://xenbits.xen.org/staging/qemu-xen-4.2-testing.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : xen@xenbits.xensource.com:git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.xen-4.2-testing
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-4.2-testing.git
++ : daily-cron.xen-4.2-testing
+ TREE_LINUX=xen@xenbits.xensource.com:git/linux-pvops.git
+ TREE_QEMU_UPSTREAM=xen@xenbits.xensource.com:git/qemu-upstream-4.2-testing.git
+ info_linux_tree xen-4.2-testing
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/xen-4.2-testing.hg
+ hg push -r 4027d31caeb0 ssh://xen@xenbits.xensource.com/HG/xen-4.2-testing.hg
pushing to ssh://xen@xenbits.xensource.com/HG/xen-4.2-testing.hg
searching for changes
remote: adding changesets
remote: adding manifests
remote: adding file changes
remote: added 6 changesets with 6 changes to 6 files

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 14 00:35:24 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 00:35:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TCJra-00080i-GG; Fri, 14 Sep 2012 00:34:30 +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 1TCJrY-00080d-SO
	for Xen-devel@lists.xensource.com; Fri, 14 Sep 2012 00:34:29 +0000
Received: from [85.158.138.51:4129] by server-8.bemta-3.messagelabs.com id
	54/BB-24700-49B72505; Fri, 14 Sep 2012 00:34:28 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1347582865!24123845!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDc0ODk3Mg==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30061 invoked from network); 14 Sep 2012 00:34:27 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-14.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 14 Sep 2012 00:34: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 q8E0YMGO025186
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 14 Sep 2012 00:34:23 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q8E0YMMx029690
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 14 Sep 2012 00:34:22 GMT
Received: from abhmt120.oracle.com (abhmt120.oracle.com [141.146.116.72])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q8E0YLtq009182; Thu, 13 Sep 2012 19:34:21 -0500
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 13 Sep 2012 17:34:21 -0700
Date: Thu, 13 Sep 2012 17:34:20 -0700
From: Mukesh Rathor <mukesh.rathor@oracle.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120913173420.22b09c90@mantra.us.oracle.com>
In-Reply-To: <1347536266.24226.97.camel@zakaz.uk.xensource.com>
References: <20120815180716.0049bffe@mantra.us.oracle.com>
	<1347372623.5305.170.camel@zakaz.uk.xensource.com>
	<20120912181910.6b0b9d2b@mantra.us.oracle.com>
	<1347536266.24226.97.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>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [RFC PATCH 8/8]: PVH: privcmd changes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 13 Sep 2012 12:37:46 +0100
Ian Campbell <Ian.Campbell@citrix.com> wrote:

> On Thu, 2012-09-13 at 02:19 +0100, Mukesh Rathor wrote:
> > On Tue, 11 Sep 2012 15:10:23 +0100
> > Ian Campbell <Ian.Campbell@citrix.com> wrote:
> > 
> > 
> > Well, it has to hang off of vma->vm_private. The alternative would
> > be to have a hash table by process id or something, again not sure
> > if worth it. 
> 
> I think using vm_private within a subsystem/layer is ok, what I think
> we should avoid is having layers pass data back and forth in that
> field.

Ah I see your point. Ok, let me play around a bit see what I can do.

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 Sep 14 00:35:24 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 00:35:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TCJra-00080i-GG; Fri, 14 Sep 2012 00:34:30 +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 1TCJrY-00080d-SO
	for Xen-devel@lists.xensource.com; Fri, 14 Sep 2012 00:34:29 +0000
Received: from [85.158.138.51:4129] by server-8.bemta-3.messagelabs.com id
	54/BB-24700-49B72505; Fri, 14 Sep 2012 00:34:28 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1347582865!24123845!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDc0ODk3Mg==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30061 invoked from network); 14 Sep 2012 00:34:27 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-14.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 14 Sep 2012 00:34: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 q8E0YMGO025186
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 14 Sep 2012 00:34:23 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q8E0YMMx029690
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 14 Sep 2012 00:34:22 GMT
Received: from abhmt120.oracle.com (abhmt120.oracle.com [141.146.116.72])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q8E0YLtq009182; Thu, 13 Sep 2012 19:34:21 -0500
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 13 Sep 2012 17:34:21 -0700
Date: Thu, 13 Sep 2012 17:34:20 -0700
From: Mukesh Rathor <mukesh.rathor@oracle.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120913173420.22b09c90@mantra.us.oracle.com>
In-Reply-To: <1347536266.24226.97.camel@zakaz.uk.xensource.com>
References: <20120815180716.0049bffe@mantra.us.oracle.com>
	<1347372623.5305.170.camel@zakaz.uk.xensource.com>
	<20120912181910.6b0b9d2b@mantra.us.oracle.com>
	<1347536266.24226.97.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>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [RFC PATCH 8/8]: PVH: privcmd changes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 13 Sep 2012 12:37:46 +0100
Ian Campbell <Ian.Campbell@citrix.com> wrote:

> On Thu, 2012-09-13 at 02:19 +0100, Mukesh Rathor wrote:
> > On Tue, 11 Sep 2012 15:10:23 +0100
> > Ian Campbell <Ian.Campbell@citrix.com> wrote:
> > 
> > 
> > Well, it has to hang off of vma->vm_private. The alternative would
> > be to have a hash table by process id or something, again not sure
> > if worth it. 
> 
> I think using vm_private within a subsystem/layer is ok, what I think
> we should avoid is having layers pass data back and forth in that
> field.

Ah I see your point. Ok, let me play around a bit see what I can do.

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 Sep 14 01:20:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 01: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 1TCKZr-0003bo-Kk; Fri, 14 Sep 2012 01:20:15 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1TCKZq-0003bj-0B
	for xen-devel@lists.xensource.com; Fri, 14 Sep 2012 01:20:14 +0000
Received: from [85.158.139.83:46833] by server-7.bemta-5.messagelabs.com id
	8E/CC-19703-D4682505; Fri, 14 Sep 2012 01:20:13 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1347585611!29878013!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDkxNTg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6666 invoked from network); 14 Sep 2012 01:20:12 -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 Sep 2012 01:20:12 -0000
X-IronPort-AV: E=Sophos;i="4.80,420,1344211200"; d="scan'208";a="14534206"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Sep 2012 01:20: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.279.1; Fri, 14 Sep 2012 02:20: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 1TCKZn-00037s-4x;
	Fri, 14 Sep 2012 01:20:11 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1TCKZm-0000bE-Or;
	Fri, 14 Sep 2012 02:20:11 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-13745-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 14 Sep 2012 02:20:10 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13745: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 13745 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13745/

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. 13668
 build-i386                    4 xen-build                 fail REGR. vs. 13668

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore            fail   like 13668
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail like 13668
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail like 13668

Tests which did not succeed, but are not blocking:
 test-amd64-i386-rhel6hvm-amd  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 xen-build-check(1)           blocked n/a
 test-amd64-i386-rhel6hvm-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   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-xl-credit2    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-multivcpu  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 xen-build-check(1)         blocked n/a
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-pv            1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-win-vcpus1    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-winxpsp3-vcpus1  1 xen-build-check(1)           blocked n/a
 test-amd64-i386-xl            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-win      13 guest-stop                   fail   never pass
 test-amd64-i386-pair          1 xen-build-check(1)           blocked  n/a

version targeted for testing:
 xen                  4aa37a8fb32a
baseline version:
 xen                  7d770de90b7f

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@citrix.com>
  Boris Ostrovsky <boris.ostrovsky@amd.com>
  Christoph Egger <Christoph.Egger@amd.com>
  Dan Magenheimer <dan.magenheimer@oracle.com>
  David Vrabel <david.vrabel@citrix.com>
  Ian Campbell <ian.campbell@citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Keir Fraser <keir@xen.org>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
  Wei Wang <wei.wang2@amd.com>
  Zhenzhong Duan <zhenzhong.duan@oracle.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   fail    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           fail    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           blocked 
 test-amd64-i386-rhel6hvm-amd                                 blocked 
 test-amd64-i386-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-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-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-amd64-amd64-xl-win                                      fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                blocked 
 test-amd64-amd64-xl-winxpsp3                                 fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

(No revision log; it would be 815 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 Sep 14 01:20:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 01: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 1TCKZr-0003bo-Kk; Fri, 14 Sep 2012 01:20:15 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1TCKZq-0003bj-0B
	for xen-devel@lists.xensource.com; Fri, 14 Sep 2012 01:20:14 +0000
Received: from [85.158.139.83:46833] by server-7.bemta-5.messagelabs.com id
	8E/CC-19703-D4682505; Fri, 14 Sep 2012 01:20:13 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1347585611!29878013!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDkxNTg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6666 invoked from network); 14 Sep 2012 01:20:12 -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 Sep 2012 01:20:12 -0000
X-IronPort-AV: E=Sophos;i="4.80,420,1344211200"; d="scan'208";a="14534206"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Sep 2012 01:20: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.279.1; Fri, 14 Sep 2012 02:20: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 1TCKZn-00037s-4x;
	Fri, 14 Sep 2012 01:20:11 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1TCKZm-0000bE-Or;
	Fri, 14 Sep 2012 02:20:11 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-13745-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 14 Sep 2012 02:20:10 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13745: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 13745 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13745/

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. 13668
 build-i386                    4 xen-build                 fail REGR. vs. 13668

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore            fail   like 13668
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail like 13668
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail like 13668

Tests which did not succeed, but are not blocking:
 test-amd64-i386-rhel6hvm-amd  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 xen-build-check(1)           blocked n/a
 test-amd64-i386-rhel6hvm-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   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-xl-credit2    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-multivcpu  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 xen-build-check(1)         blocked n/a
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-pv            1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-win-vcpus1    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-winxpsp3-vcpus1  1 xen-build-check(1)           blocked n/a
 test-amd64-i386-xl            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-win      13 guest-stop                   fail   never pass
 test-amd64-i386-pair          1 xen-build-check(1)           blocked  n/a

version targeted for testing:
 xen                  4aa37a8fb32a
baseline version:
 xen                  7d770de90b7f

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@citrix.com>
  Boris Ostrovsky <boris.ostrovsky@amd.com>
  Christoph Egger <Christoph.Egger@amd.com>
  Dan Magenheimer <dan.magenheimer@oracle.com>
  David Vrabel <david.vrabel@citrix.com>
  Ian Campbell <ian.campbell@citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Keir Fraser <keir@xen.org>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
  Wei Wang <wei.wang2@amd.com>
  Zhenzhong Duan <zhenzhong.duan@oracle.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   fail    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           fail    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           blocked 
 test-amd64-i386-rhel6hvm-amd                                 blocked 
 test-amd64-i386-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-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-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-amd64-amd64-xl-win                                      fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                blocked 
 test-amd64-amd64-xl-winxpsp3                                 fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

(No revision log; it would be 815 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 Sep 14 01:27:30 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 01:27: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 1TCKgL-0003mC-Mw; Fri, 14 Sep 2012 01:26:57 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <adrian.adams00@gmail.com>) id 1TCKgK-0003m3-Sk
	for xen-devel@lists.xen.org; Fri, 14 Sep 2012 01:26:57 +0000
X-Env-Sender: adrian.adams00@gmail.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1347586009!10927431!1
X-Originating-IP: [209.85.219.45]
X-SpamReason: No, hits=0.6 required=7.0 tests=HTML_60_70,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31581 invoked from network); 14 Sep 2012 01:26:50 -0000
Received: from mail-oa0-f45.google.com (HELO mail-oa0-f45.google.com)
	(209.85.219.45)
	by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Sep 2012 01:26:50 -0000
Received: by oagn12 with SMTP id n12so2994760oag.32
	for <xen-devel@lists.xen.org>; Thu, 13 Sep 2012 18:26:49 -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=AQGzjfo3C0dQwuye6qQGLqqGhP2Clo6uosAIWLKaDPs=;
	b=wkTlWBiSryhSoHEYJ7RwSyEV+K8iwgERjdzQV5eDUOx75XmgjHMwCmuachaWGbFP8W
	0twMJbPk7TUZcex3OfCSaW3faJ6V8BLTPEpuSN6Q9nJSXMmtQUCZuwjRNxf6MFDtegl9
	cfJFOpquBE49GTUxzMh0tggv6kiJS9VVSm/W55ozFYibjevpivXdj3omVFPjKz7d1Hw+
	TOJbDY1OwKTSMIxUdMDBmfnrQVLWdPmUypQIGpzZ+MihbkdZMb7qtsWONrq5WqwEUdDQ
	ff2+yZN7DkKpoSmmcFV8N7gtpRT2VEdJZiKNp6SWWFrVk8wBeQg3PLM5CSdiJedvIZY5
	UU4A==
MIME-Version: 1.0
Received: by 10.182.139.99 with SMTP id qx3mr969962obb.102.1347586009147; Thu,
	13 Sep 2012 18:26:49 -0700 (PDT)
Received: by 10.76.11.70 with HTTP; Thu, 13 Sep 2012 18:26:49 -0700 (PDT)
Date: Thu, 13 Sep 2012 17:26:49 -0800
Message-ID: <CAMJZU375dEqgWtSGWsRn7o_UG1QChgVZRp7fQFLatkg96c_uzQ@mail.gmail.com>
From: adrian adams <adrian.adams00@gmail.com>
To: xen-devel@lists.xen.org
Subject: [Xen-devel] System reboots while installing a guest Windows
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0500881441271403683=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============0500881441271403683==
Content-Type: multipart/alternative; boundary=e89a8f839adb61299f04c99f514f

--e89a8f839adb61299f04c99f514f
Content-Type: text/plain; charset=ISO-8859-1

Hi,

For doing a project, I am using xen (version 3.1.0) from source code. When
I want to install the guest system (using i.e. xm create w2k3.hvm), my
whole system reboots and nothing else happens. I do not know how to find
out what is wrong with my xen installation.

I will appreciate if some one helps me to solve this problem.

Thank you,
-Adrian

--e89a8f839adb61299f04c99f514f
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi,<div><br></div><div style=3D"text-align:justify">For doing a project, I =
am using xen <font face=3D"TrebuchetMS, Arial, sans-serif"><span style=3D"l=
ine-height:16px">(version 3.1.0) from source code. When I want to install t=
he guest system (using i.e.=A0xm create w2k3.hvm</span></font><span style=
=3D"line-height:16px;font-family:TrebuchetMS,Arial,sans-serif">), my whole =
system reboots and nothing else happens. I do not know how to find out what=
 is wrong with my xen installation.</span></div>
<div style=3D"text-align:justify"><span style=3D"line-height:16px;font-fami=
ly:TrebuchetMS,Arial,sans-serif"><br></span></div><div style=3D"text-align:=
justify"><span style=3D"line-height:16px;font-family:TrebuchetMS,Arial,sans=
-serif">I will appreciate if some one helps me to solve this problem.</span=
></div>
<div style=3D"text-align:justify"><span style=3D"line-height:16px;font-fami=
ly:TrebuchetMS,Arial,sans-serif"><br></span></div><div style=3D"text-align:=
justify"><span style=3D"line-height:16px;font-family:TrebuchetMS,Arial,sans=
-serif">Thank you,</span></div>
<div style=3D"text-align:justify"><font face=3D"TrebuchetMS, Arial, sans-se=
rif"><span style=3D"line-height:16px">-Adrian</span></font></div>

--e89a8f839adb61299f04c99f514f--


--===============0500881441271403683==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============0500881441271403683==--


From xen-devel-bounces@lists.xen.org Fri Sep 14 01:27:30 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 01:27: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 1TCKgL-0003mC-Mw; Fri, 14 Sep 2012 01:26:57 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <adrian.adams00@gmail.com>) id 1TCKgK-0003m3-Sk
	for xen-devel@lists.xen.org; Fri, 14 Sep 2012 01:26:57 +0000
X-Env-Sender: adrian.adams00@gmail.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1347586009!10927431!1
X-Originating-IP: [209.85.219.45]
X-SpamReason: No, hits=0.6 required=7.0 tests=HTML_60_70,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31581 invoked from network); 14 Sep 2012 01:26:50 -0000
Received: from mail-oa0-f45.google.com (HELO mail-oa0-f45.google.com)
	(209.85.219.45)
	by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Sep 2012 01:26:50 -0000
Received: by oagn12 with SMTP id n12so2994760oag.32
	for <xen-devel@lists.xen.org>; Thu, 13 Sep 2012 18:26:49 -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=AQGzjfo3C0dQwuye6qQGLqqGhP2Clo6uosAIWLKaDPs=;
	b=wkTlWBiSryhSoHEYJ7RwSyEV+K8iwgERjdzQV5eDUOx75XmgjHMwCmuachaWGbFP8W
	0twMJbPk7TUZcex3OfCSaW3faJ6V8BLTPEpuSN6Q9nJSXMmtQUCZuwjRNxf6MFDtegl9
	cfJFOpquBE49GTUxzMh0tggv6kiJS9VVSm/W55ozFYibjevpivXdj3omVFPjKz7d1Hw+
	TOJbDY1OwKTSMIxUdMDBmfnrQVLWdPmUypQIGpzZ+MihbkdZMb7qtsWONrq5WqwEUdDQ
	ff2+yZN7DkKpoSmmcFV8N7gtpRT2VEdJZiKNp6SWWFrVk8wBeQg3PLM5CSdiJedvIZY5
	UU4A==
MIME-Version: 1.0
Received: by 10.182.139.99 with SMTP id qx3mr969962obb.102.1347586009147; Thu,
	13 Sep 2012 18:26:49 -0700 (PDT)
Received: by 10.76.11.70 with HTTP; Thu, 13 Sep 2012 18:26:49 -0700 (PDT)
Date: Thu, 13 Sep 2012 17:26:49 -0800
Message-ID: <CAMJZU375dEqgWtSGWsRn7o_UG1QChgVZRp7fQFLatkg96c_uzQ@mail.gmail.com>
From: adrian adams <adrian.adams00@gmail.com>
To: xen-devel@lists.xen.org
Subject: [Xen-devel] System reboots while installing a guest Windows
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0500881441271403683=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============0500881441271403683==
Content-Type: multipart/alternative; boundary=e89a8f839adb61299f04c99f514f

--e89a8f839adb61299f04c99f514f
Content-Type: text/plain; charset=ISO-8859-1

Hi,

For doing a project, I am using xen (version 3.1.0) from source code. When
I want to install the guest system (using i.e. xm create w2k3.hvm), my
whole system reboots and nothing else happens. I do not know how to find
out what is wrong with my xen installation.

I will appreciate if some one helps me to solve this problem.

Thank you,
-Adrian

--e89a8f839adb61299f04c99f514f
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi,<div><br></div><div style=3D"text-align:justify">For doing a project, I =
am using xen <font face=3D"TrebuchetMS, Arial, sans-serif"><span style=3D"l=
ine-height:16px">(version 3.1.0) from source code. When I want to install t=
he guest system (using i.e.=A0xm create w2k3.hvm</span></font><span style=
=3D"line-height:16px;font-family:TrebuchetMS,Arial,sans-serif">), my whole =
system reboots and nothing else happens. I do not know how to find out what=
 is wrong with my xen installation.</span></div>
<div style=3D"text-align:justify"><span style=3D"line-height:16px;font-fami=
ly:TrebuchetMS,Arial,sans-serif"><br></span></div><div style=3D"text-align:=
justify"><span style=3D"line-height:16px;font-family:TrebuchetMS,Arial,sans=
-serif">I will appreciate if some one helps me to solve this problem.</span=
></div>
<div style=3D"text-align:justify"><span style=3D"line-height:16px;font-fami=
ly:TrebuchetMS,Arial,sans-serif"><br></span></div><div style=3D"text-align:=
justify"><span style=3D"line-height:16px;font-family:TrebuchetMS,Arial,sans=
-serif">Thank you,</span></div>
<div style=3D"text-align:justify"><font face=3D"TrebuchetMS, Arial, sans-se=
rif"><span style=3D"line-height:16px">-Adrian</span></font></div>

--e89a8f839adb61299f04c99f514f--


--===============0500881441271403683==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============0500881441271403683==--


From xen-devel-bounces@lists.xen.org Fri Sep 14 02:32:20 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 02:32: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 1TCLhD-0004Nr-Gi; Fri, 14 Sep 2012 02:31:55 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jiongxi.li@intel.com>) id 1TCLhB-0004Ni-HO
	for xen-devel@lists.xen.org; Fri, 14 Sep 2012 02:31:53 +0000
Received: from [85.158.143.35:3463] by server-1.bemta-4.messagelabs.com id
	6E/A6-12504-81792505; Fri, 14 Sep 2012 02:31:52 +0000
X-Env-Sender: jiongxi.li@intel.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1347589898!7203708!1
X-Originating-IP: [192.55.52.88]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjg4ID0+IDMyMDg3NA==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7196 invoked from network); 14 Sep 2012 02:31:39 -0000
Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88)
	by server-2.tower-21.messagelabs.com with SMTP;
	14 Sep 2012 02:31:39 -0000
Received: from fmsmga002.fm.intel.com ([10.253.24.26])
	by fmsmga101.fm.intel.com with ESMTP; 13 Sep 2012 19:31:38 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.80,420,1344236400"; d="scan'208";a="221857671"
Received: from fmsmsx104.amr.corp.intel.com ([10.19.9.35])
	by fmsmga002.fm.intel.com with ESMTP; 13 Sep 2012 19:31:37 -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, 13 Sep 2012 19:31:37 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.239]) by
	SHSMSX102.ccr.corp.intel.com ([169.254.2.92]) with mapi id
	14.01.0355.002; Fri, 14 Sep 2012 10:31:35 +0800
From: "Li, Jiongxi" <jiongxi.li@intel.com>
To: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Thread-Topic: [ PATCH v3 2/3] xen: enable  Virtual-interrupt delivery
Thread-Index: Ac2SHHhsNFtzjHc1Q2ewaD99bgVYgw==
Date: Fri, 14 Sep 2012 02:31:35 +0000
Message-ID: <D9137FCD9CFF644B965863BCFBEDABB87814FE@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: Jan Beulich <JBeulich@suse.com>
Subject: [Xen-devel] [ PATCH v3 2/3] xen: enable Virtual-interrupt 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

Change from v2:
re-written code in 'vmx_intr_assist' into if()/else if() sequence to make code change easy to review.


Virtual interrupt delivery avoids Xen to inject vAPIC interrupts manually, which is fully taken care of by the hardware. This needs some special awareness into existing interrupr injection path:
For pending interrupt from vLAPIC, instead of direct injection, we may need update architecture specific indicators before resuming to guest.
Before returning to guest, RVI should be updated if any pending IRRs EOI exit bitmap controls whether an EOI write should cause VM-Exit. If set, a trap-like induced EOI VM-Exit is triggered. The approach here is to manipulate EOI exit bitmap based on value of TMR. Level triggered irq requires a hook in vLAPIC EOI write, so that vIOAPIC EOI is triggered and emulated

Signed-off-by: Gang Wei <gang.wei@intel.com>
Signed-off-by: Yang Zhang <yang.z.zhang@intel.com>
Signed-off-by: Jiongxi Li <jiongxi.li@intel.com>


diff -r 7c6844dd4a0d xen/arch/x86/hvm/vlapic.c
--- a/xen/arch/x86/hvm/vlapic.c	Tue Sep 11 15:34:36 2012 +0800
+++ b/xen/arch/x86/hvm/vlapic.c	Fri Sep 14 09:16:35 2012 +0800
@@ -145,6 +145,9 @@ int vlapic_set_irq(struct vlapic *vlapic
     if ( trig )
         vlapic_set_vector(vec, &vlapic->regs->data[APIC_TMR]);
 
+    if ( hvm_funcs.update_eoi_exit_bitmap )
+        hvm_funcs.update_eoi_exit_bitmap(vlapic_vcpu(vlapic), vec ,trig);
+
     /* We may need to wake up target vcpu, besides set pending bit here */
     return !vlapic_test_and_set_irr(vec, vlapic);
 }
@@ -410,6 +413,14 @@ void vlapic_EOI_set(struct vlapic *vlapi
     hvm_dpci_msi_eoi(current->domain, vector);
 }
 
+void vlapic_handle_EOI_induced_exit(struct vlapic *vlapic, int vector)
+{
+    if ( vlapic_test_and_clear_vector(vector, &vlapic->regs->data[APIC_TMR]) )
+        vioapic_update_EOI(vlapic_domain(vlapic), vector);
+
+    hvm_dpci_msi_eoi(current->domain, vector);
+}
+
 int vlapic_ipi(
     struct vlapic *vlapic, uint32_t icr_low, uint32_t icr_high)
 {
@@ -1000,6 +1011,14 @@ void vlapic_adjust_i8259_target(struct d
     pt_adjust_global_vcpu_target(v);
 }
 
+int vlapic_virtual_intr_delivery_enabled(void)
+{
+    if ( hvm_funcs.virtual_intr_delivery_enabled )
+        return hvm_funcs.virtual_intr_delivery_enabled();
+    else
+        return 0;
+}
+
 int vlapic_has_pending_irq(struct vcpu *v)
 {
     struct vlapic *vlapic = vcpu_vlapic(v);
@@ -1012,6 +1031,9 @@ int vlapic_has_pending_irq(struct vcpu *
     if ( irr == -1 )
         return -1;
 
+    if ( vlapic_virtual_intr_delivery_enabled() )
+        return irr;
+
     isr = vlapic_find_highest_isr(vlapic);
     isr = (isr != -1) ? isr : 0;
     if ( (isr & 0xf0) >= (irr & 0xf0) )
@@ -1024,6 +1046,9 @@ int vlapic_ack_pending_irq(struct vcpu *
 {
     struct vlapic *vlapic = vcpu_vlapic(v);
 
+    if ( vlapic_virtual_intr_delivery_enabled() )
+        return 1;
+
     vlapic_set_vector(vector, &vlapic->regs->data[APIC_ISR]);
     vlapic_clear_irr(vector, vlapic);
 
diff -r 7c6844dd4a0d xen/arch/x86/hvm/vmx/intr.c
--- a/xen/arch/x86/hvm/vmx/intr.c	Tue Sep 11 15:34:36 2012 +0800
+++ b/xen/arch/x86/hvm/vmx/intr.c	Fri Sep 14 09:16:35 2012 +0800
@@ -206,6 +206,7 @@ void vmx_intr_assist(void)
     struct vcpu *v = current;
     unsigned int tpr_threshold = 0;
     enum hvm_intblk intblk;
+    int pt_vector = -1;
 
     /* Block event injection when single step with MTF. */
     if ( unlikely(v->arch.hvm_vcpu.single_step) )
@@ -216,7 +217,7 @@ void vmx_intr_assist(void)
     }
 
     /* Crank the handle on interrupt state. */
-    pt_update_irq(v);
+    pt_vector = pt_update_irq(v);
 
     do {
         intack = hvm_vcpu_has_pending_irq(v);
@@ -227,16 +228,34 @@ void vmx_intr_assist(void)
             goto out;
 
         intblk = hvm_interrupt_blocked(v, intack);
-        if ( intblk == hvm_intblk_tpr )
+        if ( cpu_has_vmx_virtual_intr_delivery )
+        {
+            /* Set "Interrupt-window exiting" for ExtINT */
+            if ( (intblk != hvm_intblk_none) &&
+                 ( (intack.source == hvm_intsrc_pic) ||
+                 ( intack.source == hvm_intsrc_vector) ) )
+            {
+                enable_intr_window(v, intack);
+                goto out;
+            }
+
+            if ( __vmread(VM_ENTRY_INTR_INFO) & INTR_INFO_VALID_MASK )
+            {
+                if ( (intack.source == hvm_intsrc_pic) ||
+                     (intack.source == hvm_intsrc_nmi) ||
+                     (intack.source == hvm_intsrc_mce) )
+                    enable_intr_window(v, intack);
+
+                goto out;
+            }
+        } else if ( intblk == hvm_intblk_tpr )
         {
             ASSERT(vlapic_enabled(vcpu_vlapic(v)));
             ASSERT(intack.source == hvm_intsrc_lapic);
             tpr_threshold = intack.vector >> 4;
             goto out;
-        }
-
-        if ( (intblk != hvm_intblk_none) ||
-             (__vmread(VM_ENTRY_INTR_INFO) & INTR_INFO_VALID_MASK) )
+        } else if ( (intblk != hvm_intblk_none) ||
+                    (__vmread(VM_ENTRY_INTR_INFO) & INTR_INFO_VALID_MASK) )
         {
             enable_intr_window(v, intack);
             goto out;
@@ -253,6 +272,44 @@ void vmx_intr_assist(void)
     {
         hvm_inject_hw_exception(TRAP_machine_check, HVM_DELIVER_NO_ERROR_CODE);
     }
+    else if ( cpu_has_vmx_virtual_intr_delivery &&
+              intack.source != hvm_intsrc_pic &&
+              intack.source != hvm_intsrc_vector )
+    {
+        unsigned long status = __vmread(GUEST_INTR_STATUS);
+
+       /*
+        * Set eoi_exit_bitmap for periodic timer interrup to cause EOI-induced VM
+        * exit, then pending periodic time interrups have the chance to be injected
+        * for compensation
+        */
+        if (pt_vector != -1)
+            vmx_set_eoi_exit_bitmap(v, pt_vector);
+
+        /* we need update the RVI field */
+        status &= ~(unsigned long)0x0FF;
+        status |= (unsigned long)0x0FF & 
+                    intack.vector;
+        __vmwrite(GUEST_INTR_STATUS, status);
+        if (v->arch.hvm_vmx.eoi_exitmap_changed) {
+#ifdef __i386__
+#define UPDATE_EOI_EXITMAP(v, e) {                             \
+        if (test_and_clear_bit(e, &v->arch.hvm_vmx.eoi_exitmap_changed)) {      \
+                __vmwrite(EOI_EXIT_BITMAP##e, v->arch.hvm_vmx.eoi_exit_bitmap[e]);    \
+                __vmwrite(EOI_EXIT_BITMAP##e##_HIGH, v.arch.hvm_vmx.eoi_exit_bitmap[e] >> 32);}}
+#else
+#define UPDATE_EOI_EXITMAP(v, e) {                             \
+        if (test_and_clear_bit(e, &v->arch.hvm_vmx.eoi_exitmap_changed)) {      \
+                __vmwrite(EOI_EXIT_BITMAP##e, v->arch.hvm_vmx.eoi_exit_bitmap[e]);}}
+#endif
+                UPDATE_EOI_EXITMAP(v, 0);
+                UPDATE_EOI_EXITMAP(v, 1);
+                UPDATE_EOI_EXITMAP(v, 2);
+                UPDATE_EOI_EXITMAP(v, 3);
+        }
+
+        pt_intr_post(v, intack);
+    }
     else
     {
         HVMTRACE_2D(INJ_VIRQ, intack.vector, /*fake=*/ 0);
@@ -262,11 +319,16 @@ void vmx_intr_assist(void)
 
     /* Is there another IRQ to queue up behind this one? */
     intack = hvm_vcpu_has_pending_irq(v);
-    if ( unlikely(intack.source != hvm_intsrc_none) )
-        enable_intr_window(v, intack);
+    if ( !cpu_has_vmx_virtual_intr_delivery ||
+         intack.source == hvm_intsrc_pic ||
+         intack.source == hvm_intsrc_vector )
+    {
+        if ( unlikely(intack.source != hvm_intsrc_none) )
+            enable_intr_window(v, intack);
+    }
 
  out:
-    if ( cpu_has_vmx_tpr_shadow )
+    if ( !cpu_has_vmx_virtual_intr_delivery && cpu_has_vmx_tpr_shadow )
         __vmwrite(TPR_THRESHOLD, tpr_threshold);
 }
 
diff -r 7c6844dd4a0d xen/arch/x86/hvm/vmx/vmcs.c
--- a/xen/arch/x86/hvm/vmx/vmcs.c	Tue Sep 11 15:34:36 2012 +0800
+++ b/xen/arch/x86/hvm/vmx/vmcs.c	Fri Sep 14 09:16:35 2012 +0800
@@ -90,6 +90,7 @@ static void __init vmx_display_features(
     P(cpu_has_vmx_msr_bitmap, "MSR direct-access bitmap");
     P(cpu_has_vmx_unrestricted_guest, "Unrestricted Guest");
     P(cpu_has_vmx_apic_reg_virt, "APIC Register Virtualization");
+    P(cpu_has_vmx_virtual_intr_delivery, "Virtual Interrupt Delivery");
 #undef P
 
     if ( !printed )
@@ -188,11 +189,12 @@ static int vmx_init_vmcs_config(void)
             opt |= SECONDARY_EXEC_UNRESTRICTED_GUEST;
 
         /*
-         * "APIC Register Virtualization"
+         * "APIC Register Virtualization" and "Virtual Interrupt Delivery"
          * can be set only when "use TPR shadow" is set
          */
         if ( _vmx_cpu_based_exec_control & CPU_BASED_TPR_SHADOW )
-            opt |= SECONDARY_EXEC_APIC_REGISTER_VIRT;
+            opt |= SECONDARY_EXEC_APIC_REGISTER_VIRT |
+                   SECONDARY_EXEC_VIRTUAL_INTR_DELIVERY;
 
 
         _vmx_secondary_exec_control = adjust_vmx_controls(
@@ -787,6 +789,22 @@ static int construct_vmcs(struct vcpu *v
     __vmwrite(IO_BITMAP_A, virt_to_maddr((char *)hvm_io_bitmap + 0));
     __vmwrite(IO_BITMAP_B, virt_to_maddr((char *)hvm_io_bitmap + PAGE_SIZE));
 
+    if ( cpu_has_vmx_virtual_intr_delivery )
+    {
+        /* EOI-exit bitmap */
+        v->arch.hvm_vmx.eoi_exit_bitmap[0] = (uint64_t)0;
+        __vmwrite(EOI_EXIT_BITMAP0, v->arch.hvm_vmx.eoi_exit_bitmap[0]);
+        v->arch.hvm_vmx.eoi_exit_bitmap[1] = (uint64_t)0;
+        __vmwrite(EOI_EXIT_BITMAP1, v->arch.hvm_vmx.eoi_exit_bitmap[1]);
+        v->arch.hvm_vmx.eoi_exit_bitmap[2] = (uint64_t)0;
+        __vmwrite(EOI_EXIT_BITMAP2, v->arch.hvm_vmx.eoi_exit_bitmap[2]);
+        v->arch.hvm_vmx.eoi_exit_bitmap[3] = (uint64_t)0;
+        __vmwrite(EOI_EXIT_BITMAP3, v->arch.hvm_vmx.eoi_exit_bitmap[3]);
+
+        /* Initialise Guest Interrupt Status (RVI and SVI) to 0 */
+        __vmwrite(GUEST_INTR_STATUS, 0);
+    }
+
     /* Host data selectors. */
     __vmwrite(HOST_SS_SELECTOR, __HYPERVISOR_DS);
     __vmwrite(HOST_DS_SELECTOR, __HYPERVISOR_DS);
@@ -1028,6 +1046,30 @@ int vmx_add_host_load_msr(u32 msr)
     return 0;
 }
 
+void vmx_set_eoi_exit_bitmap(struct vcpu *v, u8 vector)
+{
+    int index, offset, changed;
+
+    index = vector >> 6; 
+    offset = vector & 63;
+    changed = !test_and_set_bit(offset,
+                  (uint64_t *)&v->arch.hvm_vmx.eoi_exit_bitmap[index]);
+    if (changed)
+        set_bit(index, &v->arch.hvm_vmx.eoi_exitmap_changed);
+}
+
+void vmx_clear_eoi_exit_bitmap(struct vcpu *v, u8 vector)
+{
+    int index, offset, changed;
+
+    index = vector >> 6; 
+    offset = vector & 63;
+    changed = test_and_clear_bit(offset,
+                  (uint64_t *)&v->arch.hvm_vmx.eoi_exit_bitmap[index]);
+    if (changed)
+        set_bit(index, &v->arch.hvm_vmx.eoi_exitmap_changed);
+}
+
 int vmx_create_vmcs(struct vcpu *v)
 {
     struct arch_vmx_struct *arch_vmx = &v->arch.hvm_vmx;
diff -r 7c6844dd4a0d xen/arch/x86/hvm/vmx/vmx.c
--- a/xen/arch/x86/hvm/vmx/vmx.c	Tue Sep 11 15:34:36 2012 +0800
+++ b/xen/arch/x86/hvm/vmx/vmx.c	Fri Sep 14 09:16:35 2012 +0800
@@ -1502,6 +1502,22 @@ static void vmx_set_info_guest(struct vc
     vmx_vmcs_exit(v);
 }
 
+static void vmx_update_eoi_exit_bitmap(struct vcpu *v, u8 vector, u8 trig)
+{
+    if ( cpu_has_vmx_virtual_intr_delivery )
+    {
+        if (trig)
+            vmx_set_eoi_exit_bitmap(v, vector);
+        else
+            vmx_clear_eoi_exit_bitmap(v, vector);
+    }
+}
+
+static int vmx_virtual_intr_delivery_enabled(void)
+{
+    return cpu_has_vmx_virtual_intr_delivery;
+}
+
 static struct hvm_function_table __read_mostly vmx_function_table = {
     .name                 = "VMX",
     .cpu_up_prepare       = vmx_cpu_up_prepare,
@@ -1548,7 +1564,9 @@ static struct hvm_function_table __read_
     .nhvm_vmcx_guest_intercepts_trap = nvmx_intercepts_exception,
     .nhvm_vcpu_vmexit_trap = nvmx_vmexit_trap,
     .nhvm_intr_blocked    = nvmx_intr_blocked,
-    .nhvm_domain_relinquish_resources = nvmx_domain_relinquish_resources
+    .nhvm_domain_relinquish_resources = nvmx_domain_relinquish_resources,
+    .update_eoi_exit_bitmap = vmx_update_eoi_exit_bitmap,
+    .virtual_intr_delivery_enabled = vmx_virtual_intr_delivery_enabled
 };
 
 struct hvm_function_table * __init start_vmx(void)
@@ -2284,6 +2302,17 @@ static int vmx_handle_apic_write(void)
     return vlapic_apicv_write(current, offset);
 }
 
+/*
+ * When "Virtual Interrupt Delivery" is enabled, this function is used
+ * to handle EOI-induced VM exit
+ */
+void vmx_handle_EOI_induced_exit(struct vlapic *vlapic, int vector)
+{
+    ASSERT(cpu_has_vmx_virtual_intr_delivery);
+
+    vlapic_handle_EOI_induced_exit(vlapic, vector);
+}
+
 void vmx_vmexit_handler(struct cpu_user_regs *regs)
 {
     unsigned int exit_reason, idtv_info, intr_info = 0, vector = 0;
@@ -2677,6 +2706,16 @@ void vmx_vmexit_handler(struct cpu_user_
             hvm_inject_hw_exception(TRAP_gp_fault, 0);
         break;
 
+    case EXIT_REASON_EOI_INDUCED:
+    {
+        int vector;
+        exit_qualification = __vmread(EXIT_QUALIFICATION);
+        vector = exit_qualification & 0xff;
+
+        vmx_handle_EOI_induced_exit(vcpu_vlapic(current), vector);
+        break;
+    }
+
     case EXIT_REASON_IO_INSTRUCTION:
         exit_qualification = __vmread(EXIT_QUALIFICATION);
         if ( exit_qualification & 0x10 )
diff -r 7c6844dd4a0d xen/arch/x86/hvm/vpt.c
--- a/xen/arch/x86/hvm/vpt.c	Tue Sep 11 15:34:36 2012 +0800
+++ b/xen/arch/x86/hvm/vpt.c	Fri Sep 14 09:16:35 2012 +0800
@@ -212,7 +212,7 @@ static void pt_timer_fn(void *data)
     pt_unlock(pt);
 }
 
-void pt_update_irq(struct vcpu *v)
+int pt_update_irq(struct vcpu *v)
 {
     struct list_head *head = &v->arch.hvm_vcpu.tm_list;
     struct periodic_time *pt, *temp, *earliest_pt = NULL;
@@ -245,7 +245,7 @@ void pt_update_irq(struct vcpu *v)
     if ( earliest_pt == NULL )
     {
         spin_unlock(&v->arch.hvm_vcpu.tm_lock);
-        return;
+        return -1;
     }
 
     earliest_pt->irq_issued = 1;
@@ -263,6 +263,17 @@ void pt_update_irq(struct vcpu *v)
         hvm_isa_irq_deassert(v->domain, irq);
         hvm_isa_irq_assert(v->domain, irq);
     }
+
+    /*
+     * If periodic timer interrut is handled by lapic, its vector in
+     * IRR is returned and used to set eoi_exit_bitmap for virtual
+     * interrupt delivery case. Otherwise return -1 to do nothing.  
+     */ 
+    if ( vlapic_accept_pic_intr(v) &&
+         (&v->domain->arch.hvm_domain)->vpic[0].int_output )
+        return -1;
+    else 
+        return pt_irq_vector(earliest_pt, hvm_intsrc_lapic);
 }
 
 static struct periodic_time *is_pt_irq(
diff -r 7c6844dd4a0d xen/include/asm-x86/hvm/hvm.h
--- a/xen/include/asm-x86/hvm/hvm.h	Tue Sep 11 15:34:36 2012 +0800
+++ b/xen/include/asm-x86/hvm/hvm.h	Fri Sep 14 09:16:35 2012 +0800
@@ -180,6 +180,10 @@ struct hvm_function_table {
 
     enum hvm_intblk (*nhvm_intr_blocked)(struct vcpu *v);
     void (*nhvm_domain_relinquish_resources)(struct domain *d);
+
+    /* Virtual interrupt delivery */
+    void (*update_eoi_exit_bitmap)(struct vcpu *v, u8 vector, u8 trig);
+    int (*virtual_intr_delivery_enabled)(void);
 };
 
 extern struct hvm_function_table hvm_funcs;
diff -r 7c6844dd4a0d xen/include/asm-x86/hvm/vlapic.h
--- a/xen/include/asm-x86/hvm/vlapic.h	Tue Sep 11 15:34:36 2012 +0800
+++ b/xen/include/asm-x86/hvm/vlapic.h	Fri Sep 14 09:16:35 2012 +0800
@@ -100,6 +100,7 @@ int vlapic_accept_pic_intr(struct vcpu *
 void vlapic_adjust_i8259_target(struct domain *d);
 
 void vlapic_EOI_set(struct vlapic *vlapic);
+void vlapic_handle_EOI_induced_exit(struct vlapic *vlapic, int vector);
 
 int vlapic_ipi(struct vlapic *vlapic, uint32_t icr_low, uint32_t icr_high);
 
diff -r 7c6844dd4a0d xen/include/asm-x86/hvm/vmx/vmcs.h
--- a/xen/include/asm-x86/hvm/vmx/vmcs.h	Tue Sep 11 15:34:36 2012 +0800
+++ b/xen/include/asm-x86/hvm/vmx/vmcs.h	Fri Sep 14 09:16:35 2012 +0800
@@ -110,6 +110,9 @@ struct arch_vmx_struct {
     unsigned int         host_msr_count;
     struct vmx_msr_entry *host_msr_area;
 
+    uint32_t             eoi_exitmap_changed;
+    uint64_t             eoi_exit_bitmap[4];
+
     unsigned long        host_cr0;
 
     /* Is the guest in real mode? */
@@ -183,6 +186,7 @@ extern u32 vmx_vmentry_control;
 #define SECONDARY_EXEC_WBINVD_EXITING           0x00000040
 #define SECONDARY_EXEC_UNRESTRICTED_GUEST       0x00000080
 #define SECONDARY_EXEC_APIC_REGISTER_VIRT       0x00000100
+#define SECONDARY_EXEC_VIRTUAL_INTR_DELIVERY    0x00000200
 #define SECONDARY_EXEC_PAUSE_LOOP_EXITING       0x00000400
 #define SECONDARY_EXEC_ENABLE_INVPCID           0x00001000
 extern u32 vmx_secondary_exec_control;
@@ -233,6 +237,8 @@ extern bool_t cpu_has_vmx_ins_outs_instr
     (vmx_secondary_exec_control & SECONDARY_EXEC_PAUSE_LOOP_EXITING)
 #define cpu_has_vmx_apic_reg_virt \
     (vmx_secondary_exec_control & SECONDARY_EXEC_APIC_REGISTER_VIRT)
+#define cpu_has_vmx_virtual_intr_delivery \
+    (vmx_secondary_exec_control & SECONDARY_EXEC_VIRTUAL_INTR_DELIVERY)
 
 /* GUEST_INTERRUPTIBILITY_INFO flags. */
 #define VMX_INTR_SHADOW_STI             0x00000001
@@ -251,6 +257,7 @@ enum vmcs_field {
     GUEST_GS_SELECTOR               = 0x0000080a,
     GUEST_LDTR_SELECTOR             = 0x0000080c,
     GUEST_TR_SELECTOR               = 0x0000080e,
+    GUEST_INTR_STATUS               = 0x00000810,
     HOST_ES_SELECTOR                = 0x00000c00,
     HOST_CS_SELECTOR                = 0x00000c02,
     HOST_SS_SELECTOR                = 0x00000c04,
@@ -278,6 +285,14 @@ enum vmcs_field {
     APIC_ACCESS_ADDR_HIGH           = 0x00002015,
     EPT_POINTER                     = 0x0000201a,
     EPT_POINTER_HIGH                = 0x0000201b,
+    EOI_EXIT_BITMAP0                = 0x0000201c,
+    EOI_EXIT_BITMAP0_HIGH           = 0x0000201d,
+    EOI_EXIT_BITMAP1                = 0x0000201e,
+    EOI_EXIT_BITMAP1_HIGH           = 0x0000201f,
+    EOI_EXIT_BITMAP2                = 0x00002020,
+    EOI_EXIT_BITMAP2_HIGH           = 0x00002021,
+    EOI_EXIT_BITMAP3                = 0x00002022,
+    EOI_EXIT_BITMAP3_HIGH           = 0x00002023,
     GUEST_PHYSICAL_ADDRESS          = 0x00002400,
     GUEST_PHYSICAL_ADDRESS_HIGH     = 0x00002401,
     VMCS_LINK_POINTER               = 0x00002800,
@@ -398,6 +413,8 @@ int vmx_write_guest_msr(u32 msr, u64 val
 int vmx_add_guest_msr(u32 msr);
 int vmx_add_host_load_msr(u32 msr);
 void vmx_vmcs_switch(struct vmcs_struct *from, struct vmcs_struct *to);
+void vmx_set_eoi_exit_bitmap(struct vcpu *v, u8 vector);
+void vmx_clear_eoi_exit_bitmap(struct vcpu *v, u8 vector);
 
 #endif /* ASM_X86_HVM_VMX_VMCS_H__ */
 
diff -r 7c6844dd4a0d xen/include/asm-x86/hvm/vmx/vmx.h
--- a/xen/include/asm-x86/hvm/vmx/vmx.h	Tue Sep 11 15:34:36 2012 +0800
+++ b/xen/include/asm-x86/hvm/vmx/vmx.h	Fri Sep 14 09:16:35 2012 +0800
@@ -119,6 +119,7 @@ void vmx_update_cpu_exec_control(struct 
 #define EXIT_REASON_MCE_DURING_VMENTRY  41
 #define EXIT_REASON_TPR_BELOW_THRESHOLD 43
 #define EXIT_REASON_APIC_ACCESS         44
+#define EXIT_REASON_EOI_INDUCED         45
 #define EXIT_REASON_ACCESS_GDTR_OR_IDTR 46
 #define EXIT_REASON_ACCESS_LDTR_OR_TR   47
 #define EXIT_REASON_EPT_VIOLATION       48
diff -r 7c6844dd4a0d xen/include/asm-x86/hvm/vpt.h
--- a/xen/include/asm-x86/hvm/vpt.h	Tue Sep 11 15:34:36 2012 +0800
+++ b/xen/include/asm-x86/hvm/vpt.h	Fri Sep 14 09:16:35 2012 +0800
@@ -141,7 +141,7 @@ struct pl_time {    /* platform time */
 
 void pt_save_timer(struct vcpu *v);
 void pt_restore_timer(struct vcpu *v);
-void pt_update_irq(struct vcpu *v);
+int pt_update_irq(struct vcpu *v);
 void pt_intr_post(struct vcpu *v, struct hvm_intack intack);
 void pt_migrate(struct vcpu *v);


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 14 02:32:20 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 02:32: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 1TCLhD-0004Nr-Gi; Fri, 14 Sep 2012 02:31:55 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jiongxi.li@intel.com>) id 1TCLhB-0004Ni-HO
	for xen-devel@lists.xen.org; Fri, 14 Sep 2012 02:31:53 +0000
Received: from [85.158.143.35:3463] by server-1.bemta-4.messagelabs.com id
	6E/A6-12504-81792505; Fri, 14 Sep 2012 02:31:52 +0000
X-Env-Sender: jiongxi.li@intel.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1347589898!7203708!1
X-Originating-IP: [192.55.52.88]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjg4ID0+IDMyMDg3NA==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7196 invoked from network); 14 Sep 2012 02:31:39 -0000
Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88)
	by server-2.tower-21.messagelabs.com with SMTP;
	14 Sep 2012 02:31:39 -0000
Received: from fmsmga002.fm.intel.com ([10.253.24.26])
	by fmsmga101.fm.intel.com with ESMTP; 13 Sep 2012 19:31:38 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.80,420,1344236400"; d="scan'208";a="221857671"
Received: from fmsmsx104.amr.corp.intel.com ([10.19.9.35])
	by fmsmga002.fm.intel.com with ESMTP; 13 Sep 2012 19:31:37 -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, 13 Sep 2012 19:31:37 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.239]) by
	SHSMSX102.ccr.corp.intel.com ([169.254.2.92]) with mapi id
	14.01.0355.002; Fri, 14 Sep 2012 10:31:35 +0800
From: "Li, Jiongxi" <jiongxi.li@intel.com>
To: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Thread-Topic: [ PATCH v3 2/3] xen: enable  Virtual-interrupt delivery
Thread-Index: Ac2SHHhsNFtzjHc1Q2ewaD99bgVYgw==
Date: Fri, 14 Sep 2012 02:31:35 +0000
Message-ID: <D9137FCD9CFF644B965863BCFBEDABB87814FE@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: Jan Beulich <JBeulich@suse.com>
Subject: [Xen-devel] [ PATCH v3 2/3] xen: enable Virtual-interrupt 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

Change from v2:
re-written code in 'vmx_intr_assist' into if()/else if() sequence to make code change easy to review.


Virtual interrupt delivery avoids Xen to inject vAPIC interrupts manually, which is fully taken care of by the hardware. This needs some special awareness into existing interrupr injection path:
For pending interrupt from vLAPIC, instead of direct injection, we may need update architecture specific indicators before resuming to guest.
Before returning to guest, RVI should be updated if any pending IRRs EOI exit bitmap controls whether an EOI write should cause VM-Exit. If set, a trap-like induced EOI VM-Exit is triggered. The approach here is to manipulate EOI exit bitmap based on value of TMR. Level triggered irq requires a hook in vLAPIC EOI write, so that vIOAPIC EOI is triggered and emulated

Signed-off-by: Gang Wei <gang.wei@intel.com>
Signed-off-by: Yang Zhang <yang.z.zhang@intel.com>
Signed-off-by: Jiongxi Li <jiongxi.li@intel.com>


diff -r 7c6844dd4a0d xen/arch/x86/hvm/vlapic.c
--- a/xen/arch/x86/hvm/vlapic.c	Tue Sep 11 15:34:36 2012 +0800
+++ b/xen/arch/x86/hvm/vlapic.c	Fri Sep 14 09:16:35 2012 +0800
@@ -145,6 +145,9 @@ int vlapic_set_irq(struct vlapic *vlapic
     if ( trig )
         vlapic_set_vector(vec, &vlapic->regs->data[APIC_TMR]);
 
+    if ( hvm_funcs.update_eoi_exit_bitmap )
+        hvm_funcs.update_eoi_exit_bitmap(vlapic_vcpu(vlapic), vec ,trig);
+
     /* We may need to wake up target vcpu, besides set pending bit here */
     return !vlapic_test_and_set_irr(vec, vlapic);
 }
@@ -410,6 +413,14 @@ void vlapic_EOI_set(struct vlapic *vlapi
     hvm_dpci_msi_eoi(current->domain, vector);
 }
 
+void vlapic_handle_EOI_induced_exit(struct vlapic *vlapic, int vector)
+{
+    if ( vlapic_test_and_clear_vector(vector, &vlapic->regs->data[APIC_TMR]) )
+        vioapic_update_EOI(vlapic_domain(vlapic), vector);
+
+    hvm_dpci_msi_eoi(current->domain, vector);
+}
+
 int vlapic_ipi(
     struct vlapic *vlapic, uint32_t icr_low, uint32_t icr_high)
 {
@@ -1000,6 +1011,14 @@ void vlapic_adjust_i8259_target(struct d
     pt_adjust_global_vcpu_target(v);
 }
 
+int vlapic_virtual_intr_delivery_enabled(void)
+{
+    if ( hvm_funcs.virtual_intr_delivery_enabled )
+        return hvm_funcs.virtual_intr_delivery_enabled();
+    else
+        return 0;
+}
+
 int vlapic_has_pending_irq(struct vcpu *v)
 {
     struct vlapic *vlapic = vcpu_vlapic(v);
@@ -1012,6 +1031,9 @@ int vlapic_has_pending_irq(struct vcpu *
     if ( irr == -1 )
         return -1;
 
+    if ( vlapic_virtual_intr_delivery_enabled() )
+        return irr;
+
     isr = vlapic_find_highest_isr(vlapic);
     isr = (isr != -1) ? isr : 0;
     if ( (isr & 0xf0) >= (irr & 0xf0) )
@@ -1024,6 +1046,9 @@ int vlapic_ack_pending_irq(struct vcpu *
 {
     struct vlapic *vlapic = vcpu_vlapic(v);
 
+    if ( vlapic_virtual_intr_delivery_enabled() )
+        return 1;
+
     vlapic_set_vector(vector, &vlapic->regs->data[APIC_ISR]);
     vlapic_clear_irr(vector, vlapic);
 
diff -r 7c6844dd4a0d xen/arch/x86/hvm/vmx/intr.c
--- a/xen/arch/x86/hvm/vmx/intr.c	Tue Sep 11 15:34:36 2012 +0800
+++ b/xen/arch/x86/hvm/vmx/intr.c	Fri Sep 14 09:16:35 2012 +0800
@@ -206,6 +206,7 @@ void vmx_intr_assist(void)
     struct vcpu *v = current;
     unsigned int tpr_threshold = 0;
     enum hvm_intblk intblk;
+    int pt_vector = -1;
 
     /* Block event injection when single step with MTF. */
     if ( unlikely(v->arch.hvm_vcpu.single_step) )
@@ -216,7 +217,7 @@ void vmx_intr_assist(void)
     }
 
     /* Crank the handle on interrupt state. */
-    pt_update_irq(v);
+    pt_vector = pt_update_irq(v);
 
     do {
         intack = hvm_vcpu_has_pending_irq(v);
@@ -227,16 +228,34 @@ void vmx_intr_assist(void)
             goto out;
 
         intblk = hvm_interrupt_blocked(v, intack);
-        if ( intblk == hvm_intblk_tpr )
+        if ( cpu_has_vmx_virtual_intr_delivery )
+        {
+            /* Set "Interrupt-window exiting" for ExtINT */
+            if ( (intblk != hvm_intblk_none) &&
+                 ( (intack.source == hvm_intsrc_pic) ||
+                 ( intack.source == hvm_intsrc_vector) ) )
+            {
+                enable_intr_window(v, intack);
+                goto out;
+            }
+
+            if ( __vmread(VM_ENTRY_INTR_INFO) & INTR_INFO_VALID_MASK )
+            {
+                if ( (intack.source == hvm_intsrc_pic) ||
+                     (intack.source == hvm_intsrc_nmi) ||
+                     (intack.source == hvm_intsrc_mce) )
+                    enable_intr_window(v, intack);
+
+                goto out;
+            }
+        } else if ( intblk == hvm_intblk_tpr )
         {
             ASSERT(vlapic_enabled(vcpu_vlapic(v)));
             ASSERT(intack.source == hvm_intsrc_lapic);
             tpr_threshold = intack.vector >> 4;
             goto out;
-        }
-
-        if ( (intblk != hvm_intblk_none) ||
-             (__vmread(VM_ENTRY_INTR_INFO) & INTR_INFO_VALID_MASK) )
+        } else if ( (intblk != hvm_intblk_none) ||
+                    (__vmread(VM_ENTRY_INTR_INFO) & INTR_INFO_VALID_MASK) )
         {
             enable_intr_window(v, intack);
             goto out;
@@ -253,6 +272,44 @@ void vmx_intr_assist(void)
     {
         hvm_inject_hw_exception(TRAP_machine_check, HVM_DELIVER_NO_ERROR_CODE);
     }
+    else if ( cpu_has_vmx_virtual_intr_delivery &&
+              intack.source != hvm_intsrc_pic &&
+              intack.source != hvm_intsrc_vector )
+    {
+        unsigned long status = __vmread(GUEST_INTR_STATUS);
+
+       /*
+        * Set eoi_exit_bitmap for periodic timer interrup to cause EOI-induced VM
+        * exit, then pending periodic time interrups have the chance to be injected
+        * for compensation
+        */
+        if (pt_vector != -1)
+            vmx_set_eoi_exit_bitmap(v, pt_vector);
+
+        /* we need update the RVI field */
+        status &= ~(unsigned long)0x0FF;
+        status |= (unsigned long)0x0FF & 
+                    intack.vector;
+        __vmwrite(GUEST_INTR_STATUS, status);
+        if (v->arch.hvm_vmx.eoi_exitmap_changed) {
+#ifdef __i386__
+#define UPDATE_EOI_EXITMAP(v, e) {                             \
+        if (test_and_clear_bit(e, &v->arch.hvm_vmx.eoi_exitmap_changed)) {      \
+                __vmwrite(EOI_EXIT_BITMAP##e, v->arch.hvm_vmx.eoi_exit_bitmap[e]);    \
+                __vmwrite(EOI_EXIT_BITMAP##e##_HIGH, v.arch.hvm_vmx.eoi_exit_bitmap[e] >> 32);}}
+#else
+#define UPDATE_EOI_EXITMAP(v, e) {                             \
+        if (test_and_clear_bit(e, &v->arch.hvm_vmx.eoi_exitmap_changed)) {      \
+                __vmwrite(EOI_EXIT_BITMAP##e, v->arch.hvm_vmx.eoi_exit_bitmap[e]);}}
+#endif
+                UPDATE_EOI_EXITMAP(v, 0);
+                UPDATE_EOI_EXITMAP(v, 1);
+                UPDATE_EOI_EXITMAP(v, 2);
+                UPDATE_EOI_EXITMAP(v, 3);
+        }
+
+        pt_intr_post(v, intack);
+    }
     else
     {
         HVMTRACE_2D(INJ_VIRQ, intack.vector, /*fake=*/ 0);
@@ -262,11 +319,16 @@ void vmx_intr_assist(void)
 
     /* Is there another IRQ to queue up behind this one? */
     intack = hvm_vcpu_has_pending_irq(v);
-    if ( unlikely(intack.source != hvm_intsrc_none) )
-        enable_intr_window(v, intack);
+    if ( !cpu_has_vmx_virtual_intr_delivery ||
+         intack.source == hvm_intsrc_pic ||
+         intack.source == hvm_intsrc_vector )
+    {
+        if ( unlikely(intack.source != hvm_intsrc_none) )
+            enable_intr_window(v, intack);
+    }
 
  out:
-    if ( cpu_has_vmx_tpr_shadow )
+    if ( !cpu_has_vmx_virtual_intr_delivery && cpu_has_vmx_tpr_shadow )
         __vmwrite(TPR_THRESHOLD, tpr_threshold);
 }
 
diff -r 7c6844dd4a0d xen/arch/x86/hvm/vmx/vmcs.c
--- a/xen/arch/x86/hvm/vmx/vmcs.c	Tue Sep 11 15:34:36 2012 +0800
+++ b/xen/arch/x86/hvm/vmx/vmcs.c	Fri Sep 14 09:16:35 2012 +0800
@@ -90,6 +90,7 @@ static void __init vmx_display_features(
     P(cpu_has_vmx_msr_bitmap, "MSR direct-access bitmap");
     P(cpu_has_vmx_unrestricted_guest, "Unrestricted Guest");
     P(cpu_has_vmx_apic_reg_virt, "APIC Register Virtualization");
+    P(cpu_has_vmx_virtual_intr_delivery, "Virtual Interrupt Delivery");
 #undef P
 
     if ( !printed )
@@ -188,11 +189,12 @@ static int vmx_init_vmcs_config(void)
             opt |= SECONDARY_EXEC_UNRESTRICTED_GUEST;
 
         /*
-         * "APIC Register Virtualization"
+         * "APIC Register Virtualization" and "Virtual Interrupt Delivery"
          * can be set only when "use TPR shadow" is set
          */
         if ( _vmx_cpu_based_exec_control & CPU_BASED_TPR_SHADOW )
-            opt |= SECONDARY_EXEC_APIC_REGISTER_VIRT;
+            opt |= SECONDARY_EXEC_APIC_REGISTER_VIRT |
+                   SECONDARY_EXEC_VIRTUAL_INTR_DELIVERY;
 
 
         _vmx_secondary_exec_control = adjust_vmx_controls(
@@ -787,6 +789,22 @@ static int construct_vmcs(struct vcpu *v
     __vmwrite(IO_BITMAP_A, virt_to_maddr((char *)hvm_io_bitmap + 0));
     __vmwrite(IO_BITMAP_B, virt_to_maddr((char *)hvm_io_bitmap + PAGE_SIZE));
 
+    if ( cpu_has_vmx_virtual_intr_delivery )
+    {
+        /* EOI-exit bitmap */
+        v->arch.hvm_vmx.eoi_exit_bitmap[0] = (uint64_t)0;
+        __vmwrite(EOI_EXIT_BITMAP0, v->arch.hvm_vmx.eoi_exit_bitmap[0]);
+        v->arch.hvm_vmx.eoi_exit_bitmap[1] = (uint64_t)0;
+        __vmwrite(EOI_EXIT_BITMAP1, v->arch.hvm_vmx.eoi_exit_bitmap[1]);
+        v->arch.hvm_vmx.eoi_exit_bitmap[2] = (uint64_t)0;
+        __vmwrite(EOI_EXIT_BITMAP2, v->arch.hvm_vmx.eoi_exit_bitmap[2]);
+        v->arch.hvm_vmx.eoi_exit_bitmap[3] = (uint64_t)0;
+        __vmwrite(EOI_EXIT_BITMAP3, v->arch.hvm_vmx.eoi_exit_bitmap[3]);
+
+        /* Initialise Guest Interrupt Status (RVI and SVI) to 0 */
+        __vmwrite(GUEST_INTR_STATUS, 0);
+    }
+
     /* Host data selectors. */
     __vmwrite(HOST_SS_SELECTOR, __HYPERVISOR_DS);
     __vmwrite(HOST_DS_SELECTOR, __HYPERVISOR_DS);
@@ -1028,6 +1046,30 @@ int vmx_add_host_load_msr(u32 msr)
     return 0;
 }
 
+void vmx_set_eoi_exit_bitmap(struct vcpu *v, u8 vector)
+{
+    int index, offset, changed;
+
+    index = vector >> 6; 
+    offset = vector & 63;
+    changed = !test_and_set_bit(offset,
+                  (uint64_t *)&v->arch.hvm_vmx.eoi_exit_bitmap[index]);
+    if (changed)
+        set_bit(index, &v->arch.hvm_vmx.eoi_exitmap_changed);
+}
+
+void vmx_clear_eoi_exit_bitmap(struct vcpu *v, u8 vector)
+{
+    int index, offset, changed;
+
+    index = vector >> 6; 
+    offset = vector & 63;
+    changed = test_and_clear_bit(offset,
+                  (uint64_t *)&v->arch.hvm_vmx.eoi_exit_bitmap[index]);
+    if (changed)
+        set_bit(index, &v->arch.hvm_vmx.eoi_exitmap_changed);
+}
+
 int vmx_create_vmcs(struct vcpu *v)
 {
     struct arch_vmx_struct *arch_vmx = &v->arch.hvm_vmx;
diff -r 7c6844dd4a0d xen/arch/x86/hvm/vmx/vmx.c
--- a/xen/arch/x86/hvm/vmx/vmx.c	Tue Sep 11 15:34:36 2012 +0800
+++ b/xen/arch/x86/hvm/vmx/vmx.c	Fri Sep 14 09:16:35 2012 +0800
@@ -1502,6 +1502,22 @@ static void vmx_set_info_guest(struct vc
     vmx_vmcs_exit(v);
 }
 
+static void vmx_update_eoi_exit_bitmap(struct vcpu *v, u8 vector, u8 trig)
+{
+    if ( cpu_has_vmx_virtual_intr_delivery )
+    {
+        if (trig)
+            vmx_set_eoi_exit_bitmap(v, vector);
+        else
+            vmx_clear_eoi_exit_bitmap(v, vector);
+    }
+}
+
+static int vmx_virtual_intr_delivery_enabled(void)
+{
+    return cpu_has_vmx_virtual_intr_delivery;
+}
+
 static struct hvm_function_table __read_mostly vmx_function_table = {
     .name                 = "VMX",
     .cpu_up_prepare       = vmx_cpu_up_prepare,
@@ -1548,7 +1564,9 @@ static struct hvm_function_table __read_
     .nhvm_vmcx_guest_intercepts_trap = nvmx_intercepts_exception,
     .nhvm_vcpu_vmexit_trap = nvmx_vmexit_trap,
     .nhvm_intr_blocked    = nvmx_intr_blocked,
-    .nhvm_domain_relinquish_resources = nvmx_domain_relinquish_resources
+    .nhvm_domain_relinquish_resources = nvmx_domain_relinquish_resources,
+    .update_eoi_exit_bitmap = vmx_update_eoi_exit_bitmap,
+    .virtual_intr_delivery_enabled = vmx_virtual_intr_delivery_enabled
 };
 
 struct hvm_function_table * __init start_vmx(void)
@@ -2284,6 +2302,17 @@ static int vmx_handle_apic_write(void)
     return vlapic_apicv_write(current, offset);
 }
 
+/*
+ * When "Virtual Interrupt Delivery" is enabled, this function is used
+ * to handle EOI-induced VM exit
+ */
+void vmx_handle_EOI_induced_exit(struct vlapic *vlapic, int vector)
+{
+    ASSERT(cpu_has_vmx_virtual_intr_delivery);
+
+    vlapic_handle_EOI_induced_exit(vlapic, vector);
+}
+
 void vmx_vmexit_handler(struct cpu_user_regs *regs)
 {
     unsigned int exit_reason, idtv_info, intr_info = 0, vector = 0;
@@ -2677,6 +2706,16 @@ void vmx_vmexit_handler(struct cpu_user_
             hvm_inject_hw_exception(TRAP_gp_fault, 0);
         break;
 
+    case EXIT_REASON_EOI_INDUCED:
+    {
+        int vector;
+        exit_qualification = __vmread(EXIT_QUALIFICATION);
+        vector = exit_qualification & 0xff;
+
+        vmx_handle_EOI_induced_exit(vcpu_vlapic(current), vector);
+        break;
+    }
+
     case EXIT_REASON_IO_INSTRUCTION:
         exit_qualification = __vmread(EXIT_QUALIFICATION);
         if ( exit_qualification & 0x10 )
diff -r 7c6844dd4a0d xen/arch/x86/hvm/vpt.c
--- a/xen/arch/x86/hvm/vpt.c	Tue Sep 11 15:34:36 2012 +0800
+++ b/xen/arch/x86/hvm/vpt.c	Fri Sep 14 09:16:35 2012 +0800
@@ -212,7 +212,7 @@ static void pt_timer_fn(void *data)
     pt_unlock(pt);
 }
 
-void pt_update_irq(struct vcpu *v)
+int pt_update_irq(struct vcpu *v)
 {
     struct list_head *head = &v->arch.hvm_vcpu.tm_list;
     struct periodic_time *pt, *temp, *earliest_pt = NULL;
@@ -245,7 +245,7 @@ void pt_update_irq(struct vcpu *v)
     if ( earliest_pt == NULL )
     {
         spin_unlock(&v->arch.hvm_vcpu.tm_lock);
-        return;
+        return -1;
     }
 
     earliest_pt->irq_issued = 1;
@@ -263,6 +263,17 @@ void pt_update_irq(struct vcpu *v)
         hvm_isa_irq_deassert(v->domain, irq);
         hvm_isa_irq_assert(v->domain, irq);
     }
+
+    /*
+     * If periodic timer interrut is handled by lapic, its vector in
+     * IRR is returned and used to set eoi_exit_bitmap for virtual
+     * interrupt delivery case. Otherwise return -1 to do nothing.  
+     */ 
+    if ( vlapic_accept_pic_intr(v) &&
+         (&v->domain->arch.hvm_domain)->vpic[0].int_output )
+        return -1;
+    else 
+        return pt_irq_vector(earliest_pt, hvm_intsrc_lapic);
 }
 
 static struct periodic_time *is_pt_irq(
diff -r 7c6844dd4a0d xen/include/asm-x86/hvm/hvm.h
--- a/xen/include/asm-x86/hvm/hvm.h	Tue Sep 11 15:34:36 2012 +0800
+++ b/xen/include/asm-x86/hvm/hvm.h	Fri Sep 14 09:16:35 2012 +0800
@@ -180,6 +180,10 @@ struct hvm_function_table {
 
     enum hvm_intblk (*nhvm_intr_blocked)(struct vcpu *v);
     void (*nhvm_domain_relinquish_resources)(struct domain *d);
+
+    /* Virtual interrupt delivery */
+    void (*update_eoi_exit_bitmap)(struct vcpu *v, u8 vector, u8 trig);
+    int (*virtual_intr_delivery_enabled)(void);
 };
 
 extern struct hvm_function_table hvm_funcs;
diff -r 7c6844dd4a0d xen/include/asm-x86/hvm/vlapic.h
--- a/xen/include/asm-x86/hvm/vlapic.h	Tue Sep 11 15:34:36 2012 +0800
+++ b/xen/include/asm-x86/hvm/vlapic.h	Fri Sep 14 09:16:35 2012 +0800
@@ -100,6 +100,7 @@ int vlapic_accept_pic_intr(struct vcpu *
 void vlapic_adjust_i8259_target(struct domain *d);
 
 void vlapic_EOI_set(struct vlapic *vlapic);
+void vlapic_handle_EOI_induced_exit(struct vlapic *vlapic, int vector);
 
 int vlapic_ipi(struct vlapic *vlapic, uint32_t icr_low, uint32_t icr_high);
 
diff -r 7c6844dd4a0d xen/include/asm-x86/hvm/vmx/vmcs.h
--- a/xen/include/asm-x86/hvm/vmx/vmcs.h	Tue Sep 11 15:34:36 2012 +0800
+++ b/xen/include/asm-x86/hvm/vmx/vmcs.h	Fri Sep 14 09:16:35 2012 +0800
@@ -110,6 +110,9 @@ struct arch_vmx_struct {
     unsigned int         host_msr_count;
     struct vmx_msr_entry *host_msr_area;
 
+    uint32_t             eoi_exitmap_changed;
+    uint64_t             eoi_exit_bitmap[4];
+
     unsigned long        host_cr0;
 
     /* Is the guest in real mode? */
@@ -183,6 +186,7 @@ extern u32 vmx_vmentry_control;
 #define SECONDARY_EXEC_WBINVD_EXITING           0x00000040
 #define SECONDARY_EXEC_UNRESTRICTED_GUEST       0x00000080
 #define SECONDARY_EXEC_APIC_REGISTER_VIRT       0x00000100
+#define SECONDARY_EXEC_VIRTUAL_INTR_DELIVERY    0x00000200
 #define SECONDARY_EXEC_PAUSE_LOOP_EXITING       0x00000400
 #define SECONDARY_EXEC_ENABLE_INVPCID           0x00001000
 extern u32 vmx_secondary_exec_control;
@@ -233,6 +237,8 @@ extern bool_t cpu_has_vmx_ins_outs_instr
     (vmx_secondary_exec_control & SECONDARY_EXEC_PAUSE_LOOP_EXITING)
 #define cpu_has_vmx_apic_reg_virt \
     (vmx_secondary_exec_control & SECONDARY_EXEC_APIC_REGISTER_VIRT)
+#define cpu_has_vmx_virtual_intr_delivery \
+    (vmx_secondary_exec_control & SECONDARY_EXEC_VIRTUAL_INTR_DELIVERY)
 
 /* GUEST_INTERRUPTIBILITY_INFO flags. */
 #define VMX_INTR_SHADOW_STI             0x00000001
@@ -251,6 +257,7 @@ enum vmcs_field {
     GUEST_GS_SELECTOR               = 0x0000080a,
     GUEST_LDTR_SELECTOR             = 0x0000080c,
     GUEST_TR_SELECTOR               = 0x0000080e,
+    GUEST_INTR_STATUS               = 0x00000810,
     HOST_ES_SELECTOR                = 0x00000c00,
     HOST_CS_SELECTOR                = 0x00000c02,
     HOST_SS_SELECTOR                = 0x00000c04,
@@ -278,6 +285,14 @@ enum vmcs_field {
     APIC_ACCESS_ADDR_HIGH           = 0x00002015,
     EPT_POINTER                     = 0x0000201a,
     EPT_POINTER_HIGH                = 0x0000201b,
+    EOI_EXIT_BITMAP0                = 0x0000201c,
+    EOI_EXIT_BITMAP0_HIGH           = 0x0000201d,
+    EOI_EXIT_BITMAP1                = 0x0000201e,
+    EOI_EXIT_BITMAP1_HIGH           = 0x0000201f,
+    EOI_EXIT_BITMAP2                = 0x00002020,
+    EOI_EXIT_BITMAP2_HIGH           = 0x00002021,
+    EOI_EXIT_BITMAP3                = 0x00002022,
+    EOI_EXIT_BITMAP3_HIGH           = 0x00002023,
     GUEST_PHYSICAL_ADDRESS          = 0x00002400,
     GUEST_PHYSICAL_ADDRESS_HIGH     = 0x00002401,
     VMCS_LINK_POINTER               = 0x00002800,
@@ -398,6 +413,8 @@ int vmx_write_guest_msr(u32 msr, u64 val
 int vmx_add_guest_msr(u32 msr);
 int vmx_add_host_load_msr(u32 msr);
 void vmx_vmcs_switch(struct vmcs_struct *from, struct vmcs_struct *to);
+void vmx_set_eoi_exit_bitmap(struct vcpu *v, u8 vector);
+void vmx_clear_eoi_exit_bitmap(struct vcpu *v, u8 vector);
 
 #endif /* ASM_X86_HVM_VMX_VMCS_H__ */
 
diff -r 7c6844dd4a0d xen/include/asm-x86/hvm/vmx/vmx.h
--- a/xen/include/asm-x86/hvm/vmx/vmx.h	Tue Sep 11 15:34:36 2012 +0800
+++ b/xen/include/asm-x86/hvm/vmx/vmx.h	Fri Sep 14 09:16:35 2012 +0800
@@ -119,6 +119,7 @@ void vmx_update_cpu_exec_control(struct 
 #define EXIT_REASON_MCE_DURING_VMENTRY  41
 #define EXIT_REASON_TPR_BELOW_THRESHOLD 43
 #define EXIT_REASON_APIC_ACCESS         44
+#define EXIT_REASON_EOI_INDUCED         45
 #define EXIT_REASON_ACCESS_GDTR_OR_IDTR 46
 #define EXIT_REASON_ACCESS_LDTR_OR_TR   47
 #define EXIT_REASON_EPT_VIOLATION       48
diff -r 7c6844dd4a0d xen/include/asm-x86/hvm/vpt.h
--- a/xen/include/asm-x86/hvm/vpt.h	Tue Sep 11 15:34:36 2012 +0800
+++ b/xen/include/asm-x86/hvm/vpt.h	Fri Sep 14 09:16:35 2012 +0800
@@ -141,7 +141,7 @@ struct pl_time {    /* platform time */
 
 void pt_save_timer(struct vcpu *v);
 void pt_restore_timer(struct vcpu *v);
-void pt_update_irq(struct vcpu *v);
+int pt_update_irq(struct vcpu *v);
 void pt_intr_post(struct vcpu *v, struct hvm_intack intack);
 void pt_migrate(struct vcpu *v);


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 14 02:32:22 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 02:32:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TCLh9-0004Nb-3z; Fri, 14 Sep 2012 02:31:51 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jiongxi.li@intel.com>) id 1TCLh7-0004NW-Us
	for xen-devel@lists.xen.org; Fri, 14 Sep 2012 02:31:50 +0000
Received: from [85.158.143.35:41988] by server-2.bemta-4.messagelabs.com id
	58/1D-21239-51792505; Fri, 14 Sep 2012 02:31:49 +0000
X-Env-Sender: jiongxi.li@intel.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1347589895!12371843!1
X-Originating-IP: [134.134.136.20]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjAgPT4gMjk3ODA1\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32449 invoked from network); 14 Sep 2012 02:31:35 -0000
Received: from mga02.intel.com (HELO mga02.intel.com) (134.134.136.20)
	by server-7.tower-21.messagelabs.com with SMTP;
	14 Sep 2012 02:31:35 -0000
Received: from orsmga001.jf.intel.com ([10.7.209.18])
	by orsmga101.jf.intel.com with ESMTP; 13 Sep 2012 19:31:33 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.80,420,1344236400"; d="scan'208";a="192864204"
Received: from fmsmsx103.amr.corp.intel.com ([10.19.9.34])
	by orsmga001.jf.intel.com with ESMTP; 13 Sep 2012 19:31:32 -0700
Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by
	FMSMSX103.amr.corp.intel.com (10.19.9.34) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Thu, 13 Sep 2012 19:31:32 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.239]) by
	SHSMSX102.ccr.corp.intel.com ([169.254.2.92]) with mapi id
	14.01.0355.002; Fri, 14 Sep 2012 10:31:30 +0800
From: "Li, Jiongxi" <jiongxi.li@intel.com>
To: Jan Beulich <JBeulich@suse.com>
Thread-Topic: [Xen-devel] [ PATCH 2/2] xen: enable Virtual-interrupt delivery
Thread-Index: AQHNkadmVtF+66B2HEqeBgsCFNgP8peJEh5w
Date: Fri, 14 Sep 2012 02:31:30 +0000
Message-ID: <D9137FCD9CFF644B965863BCFBEDABB87814F8@SHSMSX101.ccr.corp.intel.com>
References: <D9137FCD9CFF644B965863BCFBEDABB8779942@SHSMSX101.ccr.corp.intel.com>
	<5040CAB30200007800097D73@nat28.tlf.novell.com>
	<D9137FCD9CFF644B965863BCFBEDABB877CBBD@SHSMSX101.ccr.corp.intel.com>
	<504898870200007800099427@nat28.tlf.novell.com>
	<D9137FCD9CFF644B965863BCFBEDABB878044D@SHSMSX101.ccr.corp.intel.com>
	<5051E734020000780009B090@nat28.tlf.novell.com>
In-Reply-To: <5051E734020000780009B090@nat28.tlf.novell.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [ PATCH 2/2] xen: enable Virtual-interrupt 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



> -----Original Message-----
> From: Jan Beulich [mailto:JBeulich@suse.com]
> Sent: Thursday, September 13, 2012 8:01 PM
> To: Li, Jiongxi
> Cc: xen-devel@lists.xen.org
> Subject: RE: [Xen-devel] [ PATCH 2/2] xen: enable Virtual-interrupt delivery
> 
> >>> On 13.09.12 at 12:13, "Li, Jiongxi" <jiongxi.li@intel.com> wrote:
> >> Considering that the original could already have been written with
> > if/else-if, I
> >> was suggesting to expand this to your addition:
> >>
> >> if ( cpu_has_vmx_virtual_intr_delivery ) { } else if (a)
> >>   {}
> >> else if (b)
> >>   {}
> >>
> >> which will avoid any (indentation only) changes past the first of the
> >> two
> > else-if-s.
> >> Plus it would make the logic of the code more clear, at once likely
> >> making apparent that there'll now be quite a few "goto out"-s that
> >> ought to be check for being replaceable by fewer instances of them
> >> placed slightly
> > differently.
> > It is a good suggestion. But the original code is two parallel if()
> > case, not the if/else-if case, and can't be changed to if/else-if
> > case, so I just keep the original code here. :)
> 
> That's simply not true. The code before your patch is
> 
>         if ( intblk == hvm_intblk_tpr )
>         {
>             ...
>             goto out;
>         }
> 
>         if ( (intblk != hvm_intblk_none) || ... )
>         {
>             ...
>             goto out;
>         }
> 
> which can easily be re-written into and if()/else if() (due to the goto at the first
> if() body's end). All you want in your patch is then to prepend another if() and
> convert the initial if() into an else if() too.
> 
I get your idea now, sorry for the misunderstanding before. A new patch for this will be sent out
> Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 14 02:32:22 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 02:32:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TCLh9-0004Nb-3z; Fri, 14 Sep 2012 02:31:51 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jiongxi.li@intel.com>) id 1TCLh7-0004NW-Us
	for xen-devel@lists.xen.org; Fri, 14 Sep 2012 02:31:50 +0000
Received: from [85.158.143.35:41988] by server-2.bemta-4.messagelabs.com id
	58/1D-21239-51792505; Fri, 14 Sep 2012 02:31:49 +0000
X-Env-Sender: jiongxi.li@intel.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1347589895!12371843!1
X-Originating-IP: [134.134.136.20]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjAgPT4gMjk3ODA1\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32449 invoked from network); 14 Sep 2012 02:31:35 -0000
Received: from mga02.intel.com (HELO mga02.intel.com) (134.134.136.20)
	by server-7.tower-21.messagelabs.com with SMTP;
	14 Sep 2012 02:31:35 -0000
Received: from orsmga001.jf.intel.com ([10.7.209.18])
	by orsmga101.jf.intel.com with ESMTP; 13 Sep 2012 19:31:33 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.80,420,1344236400"; d="scan'208";a="192864204"
Received: from fmsmsx103.amr.corp.intel.com ([10.19.9.34])
	by orsmga001.jf.intel.com with ESMTP; 13 Sep 2012 19:31:32 -0700
Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by
	FMSMSX103.amr.corp.intel.com (10.19.9.34) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Thu, 13 Sep 2012 19:31:32 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.239]) by
	SHSMSX102.ccr.corp.intel.com ([169.254.2.92]) with mapi id
	14.01.0355.002; Fri, 14 Sep 2012 10:31:30 +0800
From: "Li, Jiongxi" <jiongxi.li@intel.com>
To: Jan Beulich <JBeulich@suse.com>
Thread-Topic: [Xen-devel] [ PATCH 2/2] xen: enable Virtual-interrupt delivery
Thread-Index: AQHNkadmVtF+66B2HEqeBgsCFNgP8peJEh5w
Date: Fri, 14 Sep 2012 02:31:30 +0000
Message-ID: <D9137FCD9CFF644B965863BCFBEDABB87814F8@SHSMSX101.ccr.corp.intel.com>
References: <D9137FCD9CFF644B965863BCFBEDABB8779942@SHSMSX101.ccr.corp.intel.com>
	<5040CAB30200007800097D73@nat28.tlf.novell.com>
	<D9137FCD9CFF644B965863BCFBEDABB877CBBD@SHSMSX101.ccr.corp.intel.com>
	<504898870200007800099427@nat28.tlf.novell.com>
	<D9137FCD9CFF644B965863BCFBEDABB878044D@SHSMSX101.ccr.corp.intel.com>
	<5051E734020000780009B090@nat28.tlf.novell.com>
In-Reply-To: <5051E734020000780009B090@nat28.tlf.novell.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [ PATCH 2/2] xen: enable Virtual-interrupt 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



> -----Original Message-----
> From: Jan Beulich [mailto:JBeulich@suse.com]
> Sent: Thursday, September 13, 2012 8:01 PM
> To: Li, Jiongxi
> Cc: xen-devel@lists.xen.org
> Subject: RE: [Xen-devel] [ PATCH 2/2] xen: enable Virtual-interrupt delivery
> 
> >>> On 13.09.12 at 12:13, "Li, Jiongxi" <jiongxi.li@intel.com> wrote:
> >> Considering that the original could already have been written with
> > if/else-if, I
> >> was suggesting to expand this to your addition:
> >>
> >> if ( cpu_has_vmx_virtual_intr_delivery ) { } else if (a)
> >>   {}
> >> else if (b)
> >>   {}
> >>
> >> which will avoid any (indentation only) changes past the first of the
> >> two
> > else-if-s.
> >> Plus it would make the logic of the code more clear, at once likely
> >> making apparent that there'll now be quite a few "goto out"-s that
> >> ought to be check for being replaceable by fewer instances of them
> >> placed slightly
> > differently.
> > It is a good suggestion. But the original code is two parallel if()
> > case, not the if/else-if case, and can't be changed to if/else-if
> > case, so I just keep the original code here. :)
> 
> That's simply not true. The code before your patch is
> 
>         if ( intblk == hvm_intblk_tpr )
>         {
>             ...
>             goto out;
>         }
> 
>         if ( (intblk != hvm_intblk_none) || ... )
>         {
>             ...
>             goto out;
>         }
> 
> which can easily be re-written into and if()/else if() (due to the goto at the first
> if() body's end). All you want in your patch is then to prepend another if() and
> convert the initial if() into an else if() too.
> 
I get your idea now, sorry for the misunderstanding before. A new patch for this will be sent out
> Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 14 03:31:36 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 03:31:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TCMcV-0004p2-9O; Fri, 14 Sep 2012 03:31:07 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <horms@verge.net.au>) id 1TCMcU-0004ox-LX
	for xen-devel@lists.xensource.com; Fri, 14 Sep 2012 03:31:06 +0000
Received: from [85.158.137.99:39838] by server-5.bemta-3.messagelabs.com id
	99/12-13133-9F4A2505; Fri, 14 Sep 2012 03:31:05 +0000
X-Env-Sender: horms@verge.net.au
X-Msg-Ref: server-7.tower-217.messagelabs.com!1347593463!12799243!1
X-Originating-IP: [202.4.237.240]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11179 invoked from network); 14 Sep 2012 03:31:03 -0000
Received: from kirsty.vergenet.net (HELO kirsty.vergenet.net) (202.4.237.240)
	by server-7.tower-217.messagelabs.com with SMTP;
	14 Sep 2012 03:31:03 -0000
Received: from ayumi.akashicho.tokyo.vergenet.net
	(p6117-ipbfp1901kobeminato.hyogo.ocn.ne.jp [114.172.117.117])
	by kirsty.vergenet.net (Postfix) with ESMTP id 67A4325BEF5;
	Fri, 14 Sep 2012 13:31:01 +1000 (EST)
Received: by ayumi.akashicho.tokyo.vergenet.net (Postfix, from userid 7100)
	id 06CF9EDE60F; Fri, 14 Sep 2012 12:30:59 +0900 (JST)
Date: Fri, 14 Sep 2012 12:30:59 +0900
From: Simon Horman <horms@verge.net.au>
To: Daniel Kiper <daniel.kiper@oracle.com>
Message-ID: <20120914033059.GF17943@verge.net.au>
References: <1347278271-5211-1-git-send-email-daniel.kiper@oracle.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1347278271-5211-1-git-send-email-daniel.kiper@oracle.com>
Organisation: Horms Solutions Ltd.
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: olaf@aepfle.de, xen-devel@lists.xensource.com, konrad.wilk@oracle.com,
	andrew.cooper3@citrix.com, ptesarik@suse.cz, jbeulich@suse.com,
	kexec@lists.infradead.org
Subject: Re: [Xen-devel] [PATCH 0/7] kdump: Xen fixes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Sep 10, 2012 at 01:57:44PM +0200, Daniel Kiper wrote:
> Hi,
> 
> Here I am sending Xen kdump fixes.

Hi Daniel,

do these relate to the changes that you were discussing
with Petr Tesarik in July?


> Daniel Kiper (7):
>       kexec: Define some constants and structures conditionally
>       xen: Rename e820_to_kexec_type() to xen_e820_to_kexec_type() and export it
>       kexec: Move crash kernel area placement and size detection to is_crashkernel_mem_reserved()
>       kexec: Add segregate_lowmem_region()
>       kexec: Get backup area start address and size directly from mem_range
>       kexec: Move crash memory ranges logging
>       xen: Fix Xen kdump support
> 
>  include/x86/x86-linux.h            |    7 +-
>  kexec/arch/i386/crashdump-x86.c    |  322 +++++++++++++++++++++++++++--------
>  kexec/arch/i386/kexec-x86-common.c |    6 +-
>  kexec/arch/i386/kexec-x86.h        |    2 +
>  4 files changed, 259 insertions(+), 78 deletions(-)
> 
> _______________________________________________
> kexec mailing list
> kexec@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/kexec
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 14 03:31:36 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 03:31:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TCMcV-0004p2-9O; Fri, 14 Sep 2012 03:31:07 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <horms@verge.net.au>) id 1TCMcU-0004ox-LX
	for xen-devel@lists.xensource.com; Fri, 14 Sep 2012 03:31:06 +0000
Received: from [85.158.137.99:39838] by server-5.bemta-3.messagelabs.com id
	99/12-13133-9F4A2505; Fri, 14 Sep 2012 03:31:05 +0000
X-Env-Sender: horms@verge.net.au
X-Msg-Ref: server-7.tower-217.messagelabs.com!1347593463!12799243!1
X-Originating-IP: [202.4.237.240]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11179 invoked from network); 14 Sep 2012 03:31:03 -0000
Received: from kirsty.vergenet.net (HELO kirsty.vergenet.net) (202.4.237.240)
	by server-7.tower-217.messagelabs.com with SMTP;
	14 Sep 2012 03:31:03 -0000
Received: from ayumi.akashicho.tokyo.vergenet.net
	(p6117-ipbfp1901kobeminato.hyogo.ocn.ne.jp [114.172.117.117])
	by kirsty.vergenet.net (Postfix) with ESMTP id 67A4325BEF5;
	Fri, 14 Sep 2012 13:31:01 +1000 (EST)
Received: by ayumi.akashicho.tokyo.vergenet.net (Postfix, from userid 7100)
	id 06CF9EDE60F; Fri, 14 Sep 2012 12:30:59 +0900 (JST)
Date: Fri, 14 Sep 2012 12:30:59 +0900
From: Simon Horman <horms@verge.net.au>
To: Daniel Kiper <daniel.kiper@oracle.com>
Message-ID: <20120914033059.GF17943@verge.net.au>
References: <1347278271-5211-1-git-send-email-daniel.kiper@oracle.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1347278271-5211-1-git-send-email-daniel.kiper@oracle.com>
Organisation: Horms Solutions Ltd.
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: olaf@aepfle.de, xen-devel@lists.xensource.com, konrad.wilk@oracle.com,
	andrew.cooper3@citrix.com, ptesarik@suse.cz, jbeulich@suse.com,
	kexec@lists.infradead.org
Subject: Re: [Xen-devel] [PATCH 0/7] kdump: Xen fixes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Sep 10, 2012 at 01:57:44PM +0200, Daniel Kiper wrote:
> Hi,
> 
> Here I am sending Xen kdump fixes.

Hi Daniel,

do these relate to the changes that you were discussing
with Petr Tesarik in July?


> Daniel Kiper (7):
>       kexec: Define some constants and structures conditionally
>       xen: Rename e820_to_kexec_type() to xen_e820_to_kexec_type() and export it
>       kexec: Move crash kernel area placement and size detection to is_crashkernel_mem_reserved()
>       kexec: Add segregate_lowmem_region()
>       kexec: Get backup area start address and size directly from mem_range
>       kexec: Move crash memory ranges logging
>       xen: Fix Xen kdump support
> 
>  include/x86/x86-linux.h            |    7 +-
>  kexec/arch/i386/crashdump-x86.c    |  322 +++++++++++++++++++++++++++--------
>  kexec/arch/i386/kexec-x86-common.c |    6 +-
>  kexec/arch/i386/kexec-x86.h        |    2 +
>  4 files changed, 259 insertions(+), 78 deletions(-)
> 
> _______________________________________________
> kexec mailing list
> kexec@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/kexec
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 14 04:22:32 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 04:22: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 1TCNPm-00057a-Gh; Fri, 14 Sep 2012 04:22: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 1TCNPk-00057V-Mt
	for xen-devel@lists.xensource.com; Fri, 14 Sep 2012 04:22:00 +0000
Received: from [85.158.143.99:33050] by server-2.bemta-4.messagelabs.com id
	7F/5F-21239-8E0B2505; Fri, 14 Sep 2012 04:22:00 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1347596519!29379251!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDkxNTg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4556 invoked from network); 14 Sep 2012 04:21:59 -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;
	14 Sep 2012 04:21:59 -0000
X-IronPort-AV: E=Sophos;i="4.80,421,1344211200"; d="scan'208";a="14535487"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Sep 2012 04:21: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.279.1; Fri, 14 Sep 2012 05:21: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 1TCNPi-0004Cz-9P;
	Fri, 14 Sep 2012 04:21:58 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1TCNPh-0005IU-KR;
	Fri, 14 Sep 2012 05:21:57 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <E1TCNPh-0005IU-KR@woking.cam.xci-test.com>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 14 Sep 2012 05:21: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 build-i386-oldkern
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

branch xen-unstable
xen branch xen-unstable
job build-i386-oldkern
test xen-build

Tree: linux http://xenbits.xen.org/linux-2.6.18-xen.hg
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:  bc8cb4778702
  Bug not present: 05d82fb18335


  changeset:   25878:bc8cb4778702
  user:        Keir Fraser <keir@xen.org>
  date:        Wed Sep 12 13:29:30 2012 +0100
      
      xen: Remove x86_32 build target.
      
      Signed-off-by: Keir Fraser <keir@xen.org>
      
      


For bisection revision-tuple graph see:
   http://www.chiark.greenend.org.uk/~xensrcts/results/bisect.xen-unstable.build-i386-oldkern.xen-build.html
Revision IDs in each graph node refer, respectively, to the Trees above.

----------------------------------------
Searching for failure / basis pass:
 13745 fail [host=itch-mite] / 13677 [host=moss-bug] 13675 [host=moss-bug] 13668 ok.
Failure / basis pass flights: 13745 / 13668
Tree: linux http://xenbits.xen.org/linux-2.6.18-xen.hg
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 341104e962db bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 4aa37a8fb32a
Basis pass 341104e962db bacc0d302445c75f18f4c826750fb5853b60e7ca 87650d262dea07c955a683dcac75db86477c7ee3 7d770de90b7f
Generating revisions with ./adhoc-revtuple-generator  http://xenbits.xen.org/linux-2.6.18-xen.hg#341104e962db-341104e962db git://xenbits.xen.org/staging/qemu-xen-unstable.git#bacc0d302445c75f18f4c826750fb5853b60e7ca-bacc0d302445c75f18f4c826750fb5853b60e7ca git://xenbits.xen.org/staging/qemu-upstream-unstable.git#87650d262dea07c955a683dcac75db86477c7ee3-cdf4d2bb4006805f209712fbb8ed1f83127e9984 http://xenbits.xen.org/staging/xen-unstable.hg#7d770de90b7f-4aa37a8fb32a
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 1071 nodes in revision graph
Searching for test results:
 13668 pass 341104e962db bacc0d302445c75f18f4c826750fb5853b60e7ca 87650d262dea07c955a683dcac75db86477c7ee3 7d770de90b7f
 13675 [host=moss-bug]
 13677 [host=moss-bug]
 13750 pass 341104e962db bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 05d82fb18335
 13752 pass 341104e962db bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 05d82fb18335
 13701 fail 341104e962db bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 7b658d31b5e1
 13738 pass 341104e962db bacc0d302445c75f18f4c826750fb5853b60e7ca 87650d262dea07c955a683dcac75db86477c7ee3 7d770de90b7f
 13740 fail 341104e962db bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 485e6db28b93
 13741 pass 341104e962db bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 16e0392c6594
 13710 fail 341104e962db bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 485e6db28b93
 13744 pass 341104e962db bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 35fa512c60b2
 13742 pass 341104e962db bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 59b3663316db
 13743 pass 341104e962db bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 8c0aa97d529a
 13751 fail 341104e962db bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 bc8cb4778702
 13748 pass 341104e962db bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 05d82fb18335
 13755 pass 341104e962db bacc0d302445c75f18f4c826750fb5853b60e7ca 87650d262dea07c955a683dcac75db86477c7ee3 7d770de90b7f
 13757 fail 341104e962db bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 bc8cb4778702
 13749 fail 341104e962db bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 bc8cb4778702
 13745 fail 341104e962db bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 4aa37a8fb32a
 13756 fail 341104e962db bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 4aa37a8fb32a
Searching for interesting versions
 Result found: flight 13668 (pass), for basis pass
 Result found: flight 13745 (fail), for basis failure
 Repro found: flight 13755 (pass), for basis pass
 Repro found: flight 13756 (fail), for basis failure
 0 revisions at 341104e962db bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 05d82fb18335
No revisions left to test, checking graph state.
 Result found: flight 13748 (pass), for last pass
 Result found: flight 13749 (fail), for first failure
 Repro found: flight 13750 (pass), for last pass
 Repro found: flight 13751 (fail), for first failure
 Repro found: flight 13752 (pass), for last pass
 Repro found: flight 13757 (fail), for first failure

*** Found and reproduced problem changeset ***

  Bug is in tree:  xen http://xenbits.xen.org/staging/xen-unstable.hg
  Bug introduced:  bc8cb4778702
  Bug not present: 05d82fb18335

pulling from ssh://xen@xenbits.xen.org/HG/staging/xen-unstable.hg
searching for changes
no changes found

  changeset:   25878:bc8cb4778702
  user:        Keir Fraser <keir@xen.org>
  date:        Wed Sep 12 13:29:30 2012 +0100
      
      xen: Remove x86_32 build target.
      
      Signed-off-by: Keir Fraser <keir@xen.org>
      
      

Revision graph left in /home/xc_osstest/results/bisect.xen-unstable.build-i386-oldkern.xen-build.{dot,ps,png,html}.
----------------------------------------
13757: tolerable ALL FAIL

flight 13757 xen-unstable real-bisect [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13757/

Failures :-/ but no regressions.

Tests which did not succeed,
including tests which could not be run:
 build-i386-oldkern            4 xen-build               fail baseline untested


jobs:
 build-i386-oldkern                                           fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://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 Fri Sep 14 04:22:32 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 04:22: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 1TCNPm-00057a-Gh; Fri, 14 Sep 2012 04:22: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 1TCNPk-00057V-Mt
	for xen-devel@lists.xensource.com; Fri, 14 Sep 2012 04:22:00 +0000
Received: from [85.158.143.99:33050] by server-2.bemta-4.messagelabs.com id
	7F/5F-21239-8E0B2505; Fri, 14 Sep 2012 04:22:00 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1347596519!29379251!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDkxNTg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4556 invoked from network); 14 Sep 2012 04:21:59 -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;
	14 Sep 2012 04:21:59 -0000
X-IronPort-AV: E=Sophos;i="4.80,421,1344211200"; d="scan'208";a="14535487"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Sep 2012 04:21: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.279.1; Fri, 14 Sep 2012 05:21: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 1TCNPi-0004Cz-9P;
	Fri, 14 Sep 2012 04:21:58 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1TCNPh-0005IU-KR;
	Fri, 14 Sep 2012 05:21:57 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <E1TCNPh-0005IU-KR@woking.cam.xci-test.com>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 14 Sep 2012 05:21: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 build-i386-oldkern
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

branch xen-unstable
xen branch xen-unstable
job build-i386-oldkern
test xen-build

Tree: linux http://xenbits.xen.org/linux-2.6.18-xen.hg
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:  bc8cb4778702
  Bug not present: 05d82fb18335


  changeset:   25878:bc8cb4778702
  user:        Keir Fraser <keir@xen.org>
  date:        Wed Sep 12 13:29:30 2012 +0100
      
      xen: Remove x86_32 build target.
      
      Signed-off-by: Keir Fraser <keir@xen.org>
      
      


For bisection revision-tuple graph see:
   http://www.chiark.greenend.org.uk/~xensrcts/results/bisect.xen-unstable.build-i386-oldkern.xen-build.html
Revision IDs in each graph node refer, respectively, to the Trees above.

----------------------------------------
Searching for failure / basis pass:
 13745 fail [host=itch-mite] / 13677 [host=moss-bug] 13675 [host=moss-bug] 13668 ok.
Failure / basis pass flights: 13745 / 13668
Tree: linux http://xenbits.xen.org/linux-2.6.18-xen.hg
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 341104e962db bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 4aa37a8fb32a
Basis pass 341104e962db bacc0d302445c75f18f4c826750fb5853b60e7ca 87650d262dea07c955a683dcac75db86477c7ee3 7d770de90b7f
Generating revisions with ./adhoc-revtuple-generator  http://xenbits.xen.org/linux-2.6.18-xen.hg#341104e962db-341104e962db git://xenbits.xen.org/staging/qemu-xen-unstable.git#bacc0d302445c75f18f4c826750fb5853b60e7ca-bacc0d302445c75f18f4c826750fb5853b60e7ca git://xenbits.xen.org/staging/qemu-upstream-unstable.git#87650d262dea07c955a683dcac75db86477c7ee3-cdf4d2bb4006805f209712fbb8ed1f83127e9984 http://xenbits.xen.org/staging/xen-unstable.hg#7d770de90b7f-4aa37a8fb32a
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 1071 nodes in revision graph
Searching for test results:
 13668 pass 341104e962db bacc0d302445c75f18f4c826750fb5853b60e7ca 87650d262dea07c955a683dcac75db86477c7ee3 7d770de90b7f
 13675 [host=moss-bug]
 13677 [host=moss-bug]
 13750 pass 341104e962db bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 05d82fb18335
 13752 pass 341104e962db bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 05d82fb18335
 13701 fail 341104e962db bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 7b658d31b5e1
 13738 pass 341104e962db bacc0d302445c75f18f4c826750fb5853b60e7ca 87650d262dea07c955a683dcac75db86477c7ee3 7d770de90b7f
 13740 fail 341104e962db bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 485e6db28b93
 13741 pass 341104e962db bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 16e0392c6594
 13710 fail 341104e962db bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 485e6db28b93
 13744 pass 341104e962db bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 35fa512c60b2
 13742 pass 341104e962db bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 59b3663316db
 13743 pass 341104e962db bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 8c0aa97d529a
 13751 fail 341104e962db bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 bc8cb4778702
 13748 pass 341104e962db bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 05d82fb18335
 13755 pass 341104e962db bacc0d302445c75f18f4c826750fb5853b60e7ca 87650d262dea07c955a683dcac75db86477c7ee3 7d770de90b7f
 13757 fail 341104e962db bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 bc8cb4778702
 13749 fail 341104e962db bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 bc8cb4778702
 13745 fail 341104e962db bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 4aa37a8fb32a
 13756 fail 341104e962db bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 4aa37a8fb32a
Searching for interesting versions
 Result found: flight 13668 (pass), for basis pass
 Result found: flight 13745 (fail), for basis failure
 Repro found: flight 13755 (pass), for basis pass
 Repro found: flight 13756 (fail), for basis failure
 0 revisions at 341104e962db bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 05d82fb18335
No revisions left to test, checking graph state.
 Result found: flight 13748 (pass), for last pass
 Result found: flight 13749 (fail), for first failure
 Repro found: flight 13750 (pass), for last pass
 Repro found: flight 13751 (fail), for first failure
 Repro found: flight 13752 (pass), for last pass
 Repro found: flight 13757 (fail), for first failure

*** Found and reproduced problem changeset ***

  Bug is in tree:  xen http://xenbits.xen.org/staging/xen-unstable.hg
  Bug introduced:  bc8cb4778702
  Bug not present: 05d82fb18335

pulling from ssh://xen@xenbits.xen.org/HG/staging/xen-unstable.hg
searching for changes
no changes found

  changeset:   25878:bc8cb4778702
  user:        Keir Fraser <keir@xen.org>
  date:        Wed Sep 12 13:29:30 2012 +0100
      
      xen: Remove x86_32 build target.
      
      Signed-off-by: Keir Fraser <keir@xen.org>
      
      

Revision graph left in /home/xc_osstest/results/bisect.xen-unstable.build-i386-oldkern.xen-build.{dot,ps,png,html}.
----------------------------------------
13757: tolerable ALL FAIL

flight 13757 xen-unstable real-bisect [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13757/

Failures :-/ but no regressions.

Tests which did not succeed,
including tests which could not be run:
 build-i386-oldkern            4 xen-build               fail baseline untested


jobs:
 build-i386-oldkern                                           fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://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 Fri Sep 14 05:14:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 05:14:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TCODv-0005YC-PQ; Fri, 14 Sep 2012 05:13: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 1TCODu-0005Y7-4L
	for xen-devel@lists.xensource.com; Fri, 14 Sep 2012 05:13:50 +0000
Received: from [85.158.138.51:49440] by server-12.bemta-3.messagelabs.com id
	3D/A6-10384-D0DB2505; Fri, 14 Sep 2012 05:13:49 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1347599628!22548585!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDkxNTg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13322 invoked from network); 14 Sep 2012 05:13:48 -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;
	14 Sep 2012 05:13:48 -0000
X-IronPort-AV: E=Sophos;i="4.80,421,1344211200"; d="scan'208";a="14535981"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Sep 2012 05:13: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.279.1; Fri, 14 Sep 2012 06:13: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 1TCODg-0004Ud-SW;
	Fri, 14 Sep 2012 05:13:36 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1TCODg-0004g9-PS;
	Fri, 14 Sep 2012 06:13:36 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-13753-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 14 Sep 2012 06:13:36 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [qemu-upstream-4.2-testing baseline test] 13753:
	tolerable FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

"Old" tested version had not actually been tested; therefore in this
flight we test it, rather than a new candidate.  The baseline, if
any, is the most recent actually tested revision.

flight 13753 qemu-upstream-4.2-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13753/

Failures :-/ but no regressions.

Tests which did not succeed,
including tests which could not be run:
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  9 guest-localmigrate fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail never pass
 test-i386-i386-xl-qemuu-win   9 guest-localmigrate           fail   never pass
 test-amd64-i386-xl-qemuu-win-vcpus1  9 guest-localmigrate      fail never pass
 test-amd64-amd64-qemuu-win   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-qemuu-win7-amd64  9 guest-localmigrate      fail never pass
 test-amd64-i386-xend-qemuu-winxpsp3 16 leak-check/check        fail never pass
 test-i386-i386-qemuu-win     16 leak-check/check             fail   never pass
 test-amd64-i386-qemuu-win-vcpus1 16 leak-check/check           fail never pass
 test-amd64-amd64-xl-qemuu-win  9 guest-localmigrate           fail  never pass
 test-amd64-i386-qemuu-win    16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail never pass
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass


jobs:
 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                           pass    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-win-vcpus1                             fail    
 test-amd64-i386-xl-qemuu-win-vcpus1                          fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-amd64-qemuu-win                                   fail    
 test-amd64-i386-qemuu-win                                    fail    
 test-i386-i386-qemuu-win                                     fail    
 test-amd64-amd64-xl-qemuu-win                                fail    
 test-i386-i386-xl-qemuu-win                                  fail    
 test-amd64-i386-xend-qemuu-winxpsp3                          fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


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 Sep 14 05:14:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 05:14:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TCODv-0005YC-PQ; Fri, 14 Sep 2012 05:13: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 1TCODu-0005Y7-4L
	for xen-devel@lists.xensource.com; Fri, 14 Sep 2012 05:13:50 +0000
Received: from [85.158.138.51:49440] by server-12.bemta-3.messagelabs.com id
	3D/A6-10384-D0DB2505; Fri, 14 Sep 2012 05:13:49 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1347599628!22548585!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDkxNTg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13322 invoked from network); 14 Sep 2012 05:13:48 -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;
	14 Sep 2012 05:13:48 -0000
X-IronPort-AV: E=Sophos;i="4.80,421,1344211200"; d="scan'208";a="14535981"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Sep 2012 05:13: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.279.1; Fri, 14 Sep 2012 06:13: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 1TCODg-0004Ud-SW;
	Fri, 14 Sep 2012 05:13:36 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1TCODg-0004g9-PS;
	Fri, 14 Sep 2012 06:13:36 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-13753-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 14 Sep 2012 06:13:36 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [qemu-upstream-4.2-testing baseline test] 13753:
	tolerable FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

"Old" tested version had not actually been tested; therefore in this
flight we test it, rather than a new candidate.  The baseline, if
any, is the most recent actually tested revision.

flight 13753 qemu-upstream-4.2-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13753/

Failures :-/ but no regressions.

Tests which did not succeed,
including tests which could not be run:
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  9 guest-localmigrate fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail never pass
 test-i386-i386-xl-qemuu-win   9 guest-localmigrate           fail   never pass
 test-amd64-i386-xl-qemuu-win-vcpus1  9 guest-localmigrate      fail never pass
 test-amd64-amd64-qemuu-win   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-qemuu-win7-amd64  9 guest-localmigrate      fail never pass
 test-amd64-i386-xend-qemuu-winxpsp3 16 leak-check/check        fail never pass
 test-i386-i386-qemuu-win     16 leak-check/check             fail   never pass
 test-amd64-i386-qemuu-win-vcpus1 16 leak-check/check           fail never pass
 test-amd64-amd64-xl-qemuu-win  9 guest-localmigrate           fail  never pass
 test-amd64-i386-qemuu-win    16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail never pass
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass


jobs:
 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                           pass    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-win-vcpus1                             fail    
 test-amd64-i386-xl-qemuu-win-vcpus1                          fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-amd64-qemuu-win                                   fail    
 test-amd64-i386-qemuu-win                                    fail    
 test-i386-i386-qemuu-win                                     fail    
 test-amd64-amd64-xl-qemuu-win                                fail    
 test-i386-i386-xl-qemuu-win                                  fail    
 test-amd64-i386-xend-qemuu-winxpsp3                          fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


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 Sep 14 06:07:42 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 06:07: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 1TCP3W-0005qY-VK; Fri, 14 Sep 2012 06:07:10 +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 1TCP3U-0005qT-Mp
	for xen-devel@lists.xen.org; Fri, 14 Sep 2012 06:07:08 +0000
Received: from [85.158.138.51:13395] by server-6.bemta-3.messagelabs.com id
	85/50-29694-B89C2505; Fri, 14 Sep 2012 06:07:07 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-12.tower-174.messagelabs.com!1347602826!22553815!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA1MDEwNTk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5375 invoked from network); 14 Sep 2012 06:07:07 -0000
Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25)
	by server-12.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 14 Sep 2012 06:07:07 -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 10E712CF8;
	Fri, 14 Sep 2012 09:07:06 +0300 (EEST)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id D98D52005D; Fri, 14 Sep 2012 09:07:05 +0300 (EEST)
Date: Fri, 14 Sep 2012 09:07:05 +0300
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: adrian adams <adrian.adams00@gmail.com>
Message-ID: <20120914060705.GZ8912@reaktio.net>
References: <CAMJZU375dEqgWtSGWsRn7o_UG1QChgVZRp7fQFLatkg96c_uzQ@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAMJZU375dEqgWtSGWsRn7o_UG1QChgVZRp7fQFLatkg96c_uzQ@mail.gmail.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] System reboots while installing a guest Windows
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Sep 13, 2012 at 05:26:49PM -0800, adrian adams wrote:
>    Hi,

Hello,

>    For doing a project, I am using xen (version 3.1.0) from source code. 
>

Why such an old version of Xen? Even if you needed Xen 3.1.x, 
why not use the latest release in 3.1.x branch? 
3.1.0 is the initial release, not the latest in 3.1.x branch.

Consider using Xen 4.1.3, or the soon to be released 4.2.0.

>    When I want to  install the guest  system (using i.e.  xm create w2k3.hvm),  my
>    whole system reboots and nothing else happens.  I do not know how to  find
>    out what is wrong with my xen installation.
>    I will appreciate if some one helps me to solve this problem.
>

Which dom0 kernel are you using? 

You need to set up a serial console, so you can capture and log the full
boot time messages for troubleshooting..

-- Pasi


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 14 06:07:42 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 06:07: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 1TCP3W-0005qY-VK; Fri, 14 Sep 2012 06:07:10 +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 1TCP3U-0005qT-Mp
	for xen-devel@lists.xen.org; Fri, 14 Sep 2012 06:07:08 +0000
Received: from [85.158.138.51:13395] by server-6.bemta-3.messagelabs.com id
	85/50-29694-B89C2505; Fri, 14 Sep 2012 06:07:07 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-12.tower-174.messagelabs.com!1347602826!22553815!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA1MDEwNTk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5375 invoked from network); 14 Sep 2012 06:07:07 -0000
Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25)
	by server-12.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 14 Sep 2012 06:07:07 -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 10E712CF8;
	Fri, 14 Sep 2012 09:07:06 +0300 (EEST)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id D98D52005D; Fri, 14 Sep 2012 09:07:05 +0300 (EEST)
Date: Fri, 14 Sep 2012 09:07:05 +0300
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: adrian adams <adrian.adams00@gmail.com>
Message-ID: <20120914060705.GZ8912@reaktio.net>
References: <CAMJZU375dEqgWtSGWsRn7o_UG1QChgVZRp7fQFLatkg96c_uzQ@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAMJZU375dEqgWtSGWsRn7o_UG1QChgVZRp7fQFLatkg96c_uzQ@mail.gmail.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] System reboots while installing a guest Windows
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Sep 13, 2012 at 05:26:49PM -0800, adrian adams wrote:
>    Hi,

Hello,

>    For doing a project, I am using xen (version 3.1.0) from source code. 
>

Why such an old version of Xen? Even if you needed Xen 3.1.x, 
why not use the latest release in 3.1.x branch? 
3.1.0 is the initial release, not the latest in 3.1.x branch.

Consider using Xen 4.1.3, or the soon to be released 4.2.0.

>    When I want to  install the guest  system (using i.e.  xm create w2k3.hvm),  my
>    whole system reboots and nothing else happens.  I do not know how to  find
>    out what is wrong with my xen installation.
>    I will appreciate if some one helps me to solve this problem.
>

Which dom0 kernel are you using? 

You need to set up a serial console, so you can capture and log the full
boot time messages for troubleshooting..

-- Pasi


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 14 06:20:01 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 06: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 1TCPFW-00060X-7s; Fri, 14 Sep 2012 06: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.Jackson@eu.citrix.com>) id 1TCPFV-00060S-8X
	for xen-devel@lists.xensource.com; Fri, 14 Sep 2012 06:19:33 +0000
Received: from [85.158.143.35:32080] by server-1.bemta-4.messagelabs.com id
	FA/55-12504-47CC2505; Fri, 14 Sep 2012 06:19:32 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1347603571!6482574!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDkxNTg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22733 invoked from network); 14 Sep 2012 06:19: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;
	14 Sep 2012 06:19:31 -0000
X-IronPort-AV: E=Sophos;i="4.80,421,1344211200"; d="scan'208";a="14536815"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Sep 2012 06:19:25 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Fri, 14 Sep 2012 07:19: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 1TCPFN-0004q5-1L;
	Fri, 14 Sep 2012 06:19:25 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1TCPFN-0006l5-1E;
	Fri, 14 Sep 2012 07:19:25 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-13754-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 14 Sep 2012 07:19:25 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13754: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 13754 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13754/

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. 13668
 build-i386                    4 xen-build                 fail REGR. vs. 13668

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore            fail   like 13668
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail like 13668
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail like 13668

Tests which did not succeed, but are not blocking:
 test-amd64-i386-rhel6hvm-amd  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 xen-build-check(1)           blocked n/a
 test-amd64-i386-rhel6hvm-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   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-xl-credit2    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-multivcpu  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 xen-build-check(1)         blocked n/a
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-pv            1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-win-vcpus1    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-winxpsp3-vcpus1  1 xen-build-check(1)           blocked n/a
 test-amd64-i386-xl            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-win      13 guest-stop                   fail   never pass
 test-amd64-i386-pair          1 xen-build-check(1)           blocked  n/a

version targeted for testing:
 xen                  5613018f93b1
baseline version:
 xen                  7d770de90b7f

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@citrix.com>
  Boris Ostrovsky <boris.ostrovsky@amd.com>
  Christoph Egger <Christoph.Egger@amd.com>
  Dan Magenheimer <dan.magenheimer@oracle.com>
  David Vrabel <david.vrabel@citrix.com>
  Ian Campbell <ian.campbell@citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Keir Fraser <keir@xen.org>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
  Wei Wang <wei.wang2@amd.com>
  Zhenzhong Duan <zhenzhong.duan@oracle.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   fail    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           fail    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           blocked 
 test-amd64-i386-rhel6hvm-amd                                 blocked 
 test-amd64-i386-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-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-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-amd64-amd64-xl-win                                      fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                blocked 
 test-amd64-amd64-xl-winxpsp3                                 fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

(No revision log; it would be 827 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 Sep 14 06:20:01 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 06: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 1TCPFW-00060X-7s; Fri, 14 Sep 2012 06: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.Jackson@eu.citrix.com>) id 1TCPFV-00060S-8X
	for xen-devel@lists.xensource.com; Fri, 14 Sep 2012 06:19:33 +0000
Received: from [85.158.143.35:32080] by server-1.bemta-4.messagelabs.com id
	FA/55-12504-47CC2505; Fri, 14 Sep 2012 06:19:32 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1347603571!6482574!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDkxNTg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22733 invoked from network); 14 Sep 2012 06:19: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;
	14 Sep 2012 06:19:31 -0000
X-IronPort-AV: E=Sophos;i="4.80,421,1344211200"; d="scan'208";a="14536815"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Sep 2012 06:19:25 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Fri, 14 Sep 2012 07:19: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 1TCPFN-0004q5-1L;
	Fri, 14 Sep 2012 06:19:25 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1TCPFN-0006l5-1E;
	Fri, 14 Sep 2012 07:19:25 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-13754-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 14 Sep 2012 07:19:25 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13754: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 13754 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13754/

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. 13668
 build-i386                    4 xen-build                 fail REGR. vs. 13668

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore            fail   like 13668
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail like 13668
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail like 13668

Tests which did not succeed, but are not blocking:
 test-amd64-i386-rhel6hvm-amd  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 xen-build-check(1)           blocked n/a
 test-amd64-i386-rhel6hvm-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   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-xl-credit2    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-multivcpu  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 xen-build-check(1)         blocked n/a
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-pv            1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-win-vcpus1    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-winxpsp3-vcpus1  1 xen-build-check(1)           blocked n/a
 test-amd64-i386-xl            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-win      13 guest-stop                   fail   never pass
 test-amd64-i386-pair          1 xen-build-check(1)           blocked  n/a

version targeted for testing:
 xen                  5613018f93b1
baseline version:
 xen                  7d770de90b7f

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@citrix.com>
  Boris Ostrovsky <boris.ostrovsky@amd.com>
  Christoph Egger <Christoph.Egger@amd.com>
  Dan Magenheimer <dan.magenheimer@oracle.com>
  David Vrabel <david.vrabel@citrix.com>
  Ian Campbell <ian.campbell@citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Keir Fraser <keir@xen.org>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
  Wei Wang <wei.wang2@amd.com>
  Zhenzhong Duan <zhenzhong.duan@oracle.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   fail    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           fail    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           blocked 
 test-amd64-i386-rhel6hvm-amd                                 blocked 
 test-amd64-i386-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-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-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-amd64-amd64-xl-win                                      fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                blocked 
 test-amd64-amd64-xl-winxpsp3                                 fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

(No revision log; it would be 827 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 Sep 14 06:29:50 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 06: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 1TCPP4-0006Bo-I1; Fri, 14 Sep 2012 06:29:26 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1TCPP3-0006Bj-4Y
	for xen-devel@lists.xen.org; Fri, 14 Sep 2012 06:29:25 +0000
Received: from [85.158.139.83:40119] by server-10.bemta-5.messagelabs.com id
	EC/4C-10969-4CEC2505; Fri, 14 Sep 2012 06:29:24 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1347604162!16353860!1
X-Originating-IP: [74.125.82.51]
X-SpamReason: No, hits=0.6 required=7.0 tests=HTML_50_60,HTML_MESSAGE,
	MIME_QP_LONG_LINE,ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21622 invoked from network); 14 Sep 2012 06:29:22 -0000
Received: from mail-wg0-f51.google.com (HELO mail-wg0-f51.google.com)
	(74.125.82.51)
	by server-8.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Sep 2012 06:29:22 -0000
Received: by wgbed3 with SMTP id ed3so2234160wgb.32
	for <xen-devel@lists.xen.org>; Thu, 13 Sep 2012 23:29:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=user-agent:date:subject:from:to:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type;
	bh=Ag4TLgFn8m58p+SYFIe0uuyWjN6Wapaqk6V94258o+s=;
	b=Sx/Rs0UceF/lCsa4ojcEobzkzTrHJ72xVeoOm0TroqYfP++2hooZ4/TLtFS0m/sP5E
	QLOuU5/sKdXGJn64ljf6zCkA3QJbF4jO+3idEcvbCermeCSuwSEZ7s9nXTBF0PTw7eKj
	CGVLyDR1TsLLnVWW2HUB5yq4ml5PQNk4u48X7a66Su+d/A+yXcOS0CcDYsCJuWquEnOi
	GuRxZRZC/zNXc+zciwWnxK2aTSp0BL6mFDeffXw/pCpxQpygMMVaKBZcpcpGehMI6ybH
	z9f4FJ3YgJ6kA/5A1AWPxi4zrY855g4I+IkTuSbknoShvuiZsRljzKN7ORmObvnkC2C7
	uLWw==
Received: by 10.181.13.208 with SMTP id fa16mr3623968wid.11.1347603822894;
	Thu, 13 Sep 2012 23:23:42 -0700 (PDT)
Received: from [192.168.1.69] (host86-184-74-117.range86-184.btcentralplus.com.
	[86.184.74.117])
	by mx.google.com with ESMTPS id v3sm17329450wiw.7.2012.09.13.23.23.38
	(version=SSLv3 cipher=OTHER); Thu, 13 Sep 2012 23:23:41 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Fri, 14 Sep 2012 07:23:35 +0100
From: Keir Fraser <keir.xen@gmail.com>
To: adrian adams <adrian.adams00@gmail.com>,
	<xen-devel@lists.xen.org>
Message-ID: <CC788BF7.3EBE7%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] System reboots while installing a guest Windows
Thread-Index: Ac2SQXgnWwG1PxW4MUK/NtshAUWteA==
In-Reply-To: <CAMJZU375dEqgWtSGWsRn7o_UG1QChgVZRp7fQFLatkg96c_uzQ@mail.gmail.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] System reboots while installing a guest Windows
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0454105756355906941=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--===============0454105756355906941==
Content-type: multipart/alternative;
	boundary="B_3430452219_51824515"

> This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--B_3430452219_51824515
Content-type: text/plain;
	charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable

Are you really using Xen 3.1.0. You should upgrade to a newer version if so=
.


On 14/09/2012 02:26, "adrian adams" <adrian.adams00@gmail.com> wrote:

> Hi,
>=20
> For doing a project, I am using xen (version 3.1.0) from source code. Whe=
n I
> want to install the guest system (using i.e.=A0xm create w2k3.hvm), my whol=
e
> system reboots and nothing else happens. I do not know how to find out wh=
at is
> wrong with my xen installation.
>=20
> I will appreciate if some one helps me to solve this problem.
>=20
> Thank you,
> -Adrian
>=20
>=20
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel


--B_3430452219_51824515
Content-type: text/html;
	charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable

<HTML>
<HEAD>
<TITLE>Re: [Xen-devel] System reboots while installing a guest Windows</TIT=
LE>
</HEAD>
<BODY>
<FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN STYLE=3D'font-size:11pt=
'>Are you really using Xen 3.1.0. You should upgrade to a newer version if s=
o.<BR>
<BR>
<BR>
On 14/09/2012 02:26, &quot;adrian adams&quot; &lt;<a href=3D"adrian.adams00@g=
mail.com">adrian.adams00@gmail.com</a>&gt; wrote:<BR>
<BR>
</SPAN></FONT><BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><=
SPAN STYLE=3D'font-size:11pt'>Hi,<BR>
<BR>
For doing a project, I am using xen </SPAN></FONT><SPAN STYLE=3D'font-size:11=
pt'><FONT FACE=3D"Arial">(version 3.1.0) from source code. When I want to inst=
all the guest system (using i.e.=A0xm create w2k3.hvm), my whole system reboot=
s and nothing else happens. I do not know how to find out what is wrong with=
 my xen installation.<BR>
<BR>
I will appreciate if some one helps me to solve this problem.<BR>
<BR>
Thank you,<BR>
-Adrian<BR>
</FONT><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><BR>
<HR ALIGN=3DCENTER SIZE=3D"3" WIDTH=3D"95%"></FONT></SPAN><FONT SIZE=3D"2"><FONT FA=
CE=3D"Consolas, Courier New, Courier"><SPAN STYLE=3D'font-size:10pt'>___________=
____________________________________<BR>
Xen-devel mailing list<BR>
<a href=3D"Xen-devel@lists.xen.org">Xen-devel@lists.xen.org</a><BR>
<a href=3D"http://lists.xen.org/xen-devel">http://lists.xen.org/xen-devel</a>=
<BR>
</SPAN></FONT></FONT></BLOCKQUOTE>
</BODY>
</HTML>


--B_3430452219_51824515--




--===============0454105756355906941==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============0454105756355906941==--




From xen-devel-bounces@lists.xen.org Fri Sep 14 06:29:50 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 06: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 1TCPP4-0006Bo-I1; Fri, 14 Sep 2012 06:29:26 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1TCPP3-0006Bj-4Y
	for xen-devel@lists.xen.org; Fri, 14 Sep 2012 06:29:25 +0000
Received: from [85.158.139.83:40119] by server-10.bemta-5.messagelabs.com id
	EC/4C-10969-4CEC2505; Fri, 14 Sep 2012 06:29:24 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1347604162!16353860!1
X-Originating-IP: [74.125.82.51]
X-SpamReason: No, hits=0.6 required=7.0 tests=HTML_50_60,HTML_MESSAGE,
	MIME_QP_LONG_LINE,ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21622 invoked from network); 14 Sep 2012 06:29:22 -0000
Received: from mail-wg0-f51.google.com (HELO mail-wg0-f51.google.com)
	(74.125.82.51)
	by server-8.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Sep 2012 06:29:22 -0000
Received: by wgbed3 with SMTP id ed3so2234160wgb.32
	for <xen-devel@lists.xen.org>; Thu, 13 Sep 2012 23:29:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=user-agent:date:subject:from:to:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type;
	bh=Ag4TLgFn8m58p+SYFIe0uuyWjN6Wapaqk6V94258o+s=;
	b=Sx/Rs0UceF/lCsa4ojcEobzkzTrHJ72xVeoOm0TroqYfP++2hooZ4/TLtFS0m/sP5E
	QLOuU5/sKdXGJn64ljf6zCkA3QJbF4jO+3idEcvbCermeCSuwSEZ7s9nXTBF0PTw7eKj
	CGVLyDR1TsLLnVWW2HUB5yq4ml5PQNk4u48X7a66Su+d/A+yXcOS0CcDYsCJuWquEnOi
	GuRxZRZC/zNXc+zciwWnxK2aTSp0BL6mFDeffXw/pCpxQpygMMVaKBZcpcpGehMI6ybH
	z9f4FJ3YgJ6kA/5A1AWPxi4zrY855g4I+IkTuSbknoShvuiZsRljzKN7ORmObvnkC2C7
	uLWw==
Received: by 10.181.13.208 with SMTP id fa16mr3623968wid.11.1347603822894;
	Thu, 13 Sep 2012 23:23:42 -0700 (PDT)
Received: from [192.168.1.69] (host86-184-74-117.range86-184.btcentralplus.com.
	[86.184.74.117])
	by mx.google.com with ESMTPS id v3sm17329450wiw.7.2012.09.13.23.23.38
	(version=SSLv3 cipher=OTHER); Thu, 13 Sep 2012 23:23:41 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Fri, 14 Sep 2012 07:23:35 +0100
From: Keir Fraser <keir.xen@gmail.com>
To: adrian adams <adrian.adams00@gmail.com>,
	<xen-devel@lists.xen.org>
Message-ID: <CC788BF7.3EBE7%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] System reboots while installing a guest Windows
Thread-Index: Ac2SQXgnWwG1PxW4MUK/NtshAUWteA==
In-Reply-To: <CAMJZU375dEqgWtSGWsRn7o_UG1QChgVZRp7fQFLatkg96c_uzQ@mail.gmail.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] System reboots while installing a guest Windows
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0454105756355906941=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--===============0454105756355906941==
Content-type: multipart/alternative;
	boundary="B_3430452219_51824515"

> This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--B_3430452219_51824515
Content-type: text/plain;
	charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable

Are you really using Xen 3.1.0. You should upgrade to a newer version if so=
.


On 14/09/2012 02:26, "adrian adams" <adrian.adams00@gmail.com> wrote:

> Hi,
>=20
> For doing a project, I am using xen (version 3.1.0) from source code. Whe=
n I
> want to install the guest system (using i.e.=A0xm create w2k3.hvm), my whol=
e
> system reboots and nothing else happens. I do not know how to find out wh=
at is
> wrong with my xen installation.
>=20
> I will appreciate if some one helps me to solve this problem.
>=20
> Thank you,
> -Adrian
>=20
>=20
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel


--B_3430452219_51824515
Content-type: text/html;
	charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable

<HTML>
<HEAD>
<TITLE>Re: [Xen-devel] System reboots while installing a guest Windows</TIT=
LE>
</HEAD>
<BODY>
<FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN STYLE=3D'font-size:11pt=
'>Are you really using Xen 3.1.0. You should upgrade to a newer version if s=
o.<BR>
<BR>
<BR>
On 14/09/2012 02:26, &quot;adrian adams&quot; &lt;<a href=3D"adrian.adams00@g=
mail.com">adrian.adams00@gmail.com</a>&gt; wrote:<BR>
<BR>
</SPAN></FONT><BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><=
SPAN STYLE=3D'font-size:11pt'>Hi,<BR>
<BR>
For doing a project, I am using xen </SPAN></FONT><SPAN STYLE=3D'font-size:11=
pt'><FONT FACE=3D"Arial">(version 3.1.0) from source code. When I want to inst=
all the guest system (using i.e.=A0xm create w2k3.hvm), my whole system reboot=
s and nothing else happens. I do not know how to find out what is wrong with=
 my xen installation.<BR>
<BR>
I will appreciate if some one helps me to solve this problem.<BR>
<BR>
Thank you,<BR>
-Adrian<BR>
</FONT><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><BR>
<HR ALIGN=3DCENTER SIZE=3D"3" WIDTH=3D"95%"></FONT></SPAN><FONT SIZE=3D"2"><FONT FA=
CE=3D"Consolas, Courier New, Courier"><SPAN STYLE=3D'font-size:10pt'>___________=
____________________________________<BR>
Xen-devel mailing list<BR>
<a href=3D"Xen-devel@lists.xen.org">Xen-devel@lists.xen.org</a><BR>
<a href=3D"http://lists.xen.org/xen-devel">http://lists.xen.org/xen-devel</a>=
<BR>
</SPAN></FONT></FONT></BLOCKQUOTE>
</BODY>
</HTML>


--B_3430452219_51824515--




--===============0454105756355906941==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============0454105756355906941==--




From xen-devel-bounces@lists.xen.org Fri Sep 14 08:06:00 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 08:06:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TCQu9-0007QQ-0W; Fri, 14 Sep 2012 08:05: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 1TCQu7-0007QD-N4
	for xen-devel@lists.xensource.com; Fri, 14 Sep 2012 08:05:35 +0000
Received: from [85.158.143.99:31947] by server-1.bemta-4.messagelabs.com id
	B8/FE-12504-F45E2505; Fri, 14 Sep 2012 08:05:35 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1347609933!19083891!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDkxNTg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31561 invoked from network); 14 Sep 2012 08:05:34 -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;
	14 Sep 2012 08:05:34 -0000
X-IronPort-AV: E=Sophos;i="4.80,422,1344211200"; d="scan'208";a="14538598"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Sep 2012 08:05: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.279.1;
	Fri, 14 Sep 2012 09:05:33 +0100
Message-ID: <1347609931.24226.149.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Fri, 14 Sep 2012 09:05:31 +0100
In-Reply-To: <alpine.DEB.2.02.1209131857520.29232@kaball.uk.xensource.com>
References: <f32959a0c14799617f7f.1346862971@makatos-desktop>
	<20562.6285.724880.885473@mariner.uk.xensource.com>
	<alpine.DEB.2.02.1209131857520.29232@kaball.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Thanos Makatos <thanos.makatos@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] use spaces instead of tabs in vim
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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-09-13 at 18:58 +0100, Stefano Stabellini wrote:
> On Thu, 13 Sep 2012, Ian Jackson wrote:
> > Thanos Makatos writes ("[Xen-devel] [PATCH] use spaces instead of tabs in vim"):
> > > Tell vim to use spaces instead of tabs for all files residing under
> > > xen-unstable.hg. Must open files from the top-level directory, otherwise it
> > > doesn't work.
> > 
> > This is fine by me and looks plausible but I'd like to see a second
> > opinion from someone who uses vim.
> > 
> 
> Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

http://vim.wikia.com/wiki/Modeline_magic suggests you can do it on a
per-file basis. Given the number of different coding styles throughout
the tree wouldn't that be a better option? This set of options is wrong
e.g. for tools/libxl and anything imported from Linux.

It's be a bigger initial patch but once it is done it's done.

People typically copy the magic block from an existing file so as long
as you put the vim one next to the emacs one it should get propagated as
necessary to new files.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 14 08:06:00 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 08:06:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TCQu9-0007QQ-0W; Fri, 14 Sep 2012 08:05: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 1TCQu7-0007QD-N4
	for xen-devel@lists.xensource.com; Fri, 14 Sep 2012 08:05:35 +0000
Received: from [85.158.143.99:31947] by server-1.bemta-4.messagelabs.com id
	B8/FE-12504-F45E2505; Fri, 14 Sep 2012 08:05:35 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1347609933!19083891!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDkxNTg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31561 invoked from network); 14 Sep 2012 08:05:34 -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;
	14 Sep 2012 08:05:34 -0000
X-IronPort-AV: E=Sophos;i="4.80,422,1344211200"; d="scan'208";a="14538598"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Sep 2012 08:05: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.279.1;
	Fri, 14 Sep 2012 09:05:33 +0100
Message-ID: <1347609931.24226.149.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Fri, 14 Sep 2012 09:05:31 +0100
In-Reply-To: <alpine.DEB.2.02.1209131857520.29232@kaball.uk.xensource.com>
References: <f32959a0c14799617f7f.1346862971@makatos-desktop>
	<20562.6285.724880.885473@mariner.uk.xensource.com>
	<alpine.DEB.2.02.1209131857520.29232@kaball.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Thanos Makatos <thanos.makatos@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] use spaces instead of tabs in vim
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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-09-13 at 18:58 +0100, Stefano Stabellini wrote:
> On Thu, 13 Sep 2012, Ian Jackson wrote:
> > Thanos Makatos writes ("[Xen-devel] [PATCH] use spaces instead of tabs in vim"):
> > > Tell vim to use spaces instead of tabs for all files residing under
> > > xen-unstable.hg. Must open files from the top-level directory, otherwise it
> > > doesn't work.
> > 
> > This is fine by me and looks plausible but I'd like to see a second
> > opinion from someone who uses vim.
> > 
> 
> Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

http://vim.wikia.com/wiki/Modeline_magic suggests you can do it on a
per-file basis. Given the number of different coding styles throughout
the tree wouldn't that be a better option? This set of options is wrong
e.g. for tools/libxl and anything imported from Linux.

It's be a bigger initial patch but once it is done it's done.

People typically copy the magic block from an existing file so as long
as you put the vim one next to the emacs one it should get propagated as
necessary to new files.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 14 08:54:11 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 08:54:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TCRel-00082P-2q; Fri, 14 Sep 2012 08:53: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 1TCRek-00082J-3K
	for xen-devel@lists.xen.org; Fri, 14 Sep 2012 08:53:46 +0000
Received: from [85.158.143.99:32609] by server-1.bemta-4.messagelabs.com id
	AF/0C-12504-990F2505; Fri, 14 Sep 2012 08:53:45 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1347612825!29415234!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM5NDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14221 invoked from network); 14 Sep 2012 08:53:45 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-13.tower-216.messagelabs.com with SMTP;
	14 Sep 2012 08:53:45 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 14 Sep 2012 09:53:44 +0100
Message-Id: <50530CF0020000780009B49B@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 14 Sep 2012 09:54:40 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Daniel De Graaf" <dgdegra@tycho.nsa.gov>
References: <1347465586-20009-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1347465586-20009-20-git-send-email-dgdegra@tycho.nsa.gov>
	<5051AED7020000780009AFC3@nat28.tlf.novell.com>
	<5051E3AC.2060700@tycho.nsa.gov>
	<50520634020000780009B162@nat28.tlf.novell.com>
	<5051ECC7.7050901@tycho.nsa.gov>
	<5052121F020000780009B1E9@nat28.tlf.novell.com>
	<50520DFF.4030505@tycho.nsa.gov>
In-Reply-To: <50520DFF.4030505@tycho.nsa.gov>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Tim Deegan <tim@xen.org>, Keir Fraser <keir@xen.org>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 19/22] arch/x86: check remote MMIO remap
 permissions
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.09.12 at 18:46, Daniel De Graaf <dgdegra@tycho.nsa.gov> wrote:
> For this example, assume domain A has access to map domain B's memory
> read-only. Domain B has access to a device with MMIO where reads to the
> device's memory cause state changes - an example of such as device is a
> TPM, where replies are read by repeated reads to a single 4-byte 
> address. Domain A does not have access to this device, and would like to
> maliciously interfere with the device.
> 
> If domain A maps the MMIO page from domain B using pg_owner == domB, the
> iomem_access_permitted check will be done from domain B's perspective. 
> While this is needed when domain A is mapping pages on behalf of domB, 
> it is not sufficient when attempting to constrain domain A's access. 
> 
> These checks only apply to MMIO, so the condition on line 735 will
> evaluate to true (!mfn_valid || real_pg_owner == dom_io).
> 
> The (existing) check on domain B's MMIO access is:
>         if ( !iomem_access_permitted(pg_owner, mfn, mfn) )
> 
> This patch adds a check on domain A:
>         if ( !iomem_access_permitted(curr->domain, mfn, mfn) )

So then I think I was right suggesting that the second check
should be done at the same place where the first one is, not
outside/after the MMIO conditional.

> This extra checking has not been required without XSM because only FLASK
> implements the ability to grant one domain read-only access to another 
> domain. With read-write access, this extra access check is simple to get
> around: domain A can modify some part of the executable code in domain B
> to act as a proxy for its accesses. Additionally, domain A is usually
> dom0 or the device model, which have equal or greater MMIO access.

Understood.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 14 08:54:11 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 08:54:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TCRel-00082P-2q; Fri, 14 Sep 2012 08:53: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 1TCRek-00082J-3K
	for xen-devel@lists.xen.org; Fri, 14 Sep 2012 08:53:46 +0000
Received: from [85.158.143.99:32609] by server-1.bemta-4.messagelabs.com id
	AF/0C-12504-990F2505; Fri, 14 Sep 2012 08:53:45 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1347612825!29415234!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDM5NDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14221 invoked from network); 14 Sep 2012 08:53:45 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-13.tower-216.messagelabs.com with SMTP;
	14 Sep 2012 08:53:45 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 14 Sep 2012 09:53:44 +0100
Message-Id: <50530CF0020000780009B49B@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 14 Sep 2012 09:54:40 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Daniel De Graaf" <dgdegra@tycho.nsa.gov>
References: <1347465586-20009-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1347465586-20009-20-git-send-email-dgdegra@tycho.nsa.gov>
	<5051AED7020000780009AFC3@nat28.tlf.novell.com>
	<5051E3AC.2060700@tycho.nsa.gov>
	<50520634020000780009B162@nat28.tlf.novell.com>
	<5051ECC7.7050901@tycho.nsa.gov>
	<5052121F020000780009B1E9@nat28.tlf.novell.com>
	<50520DFF.4030505@tycho.nsa.gov>
In-Reply-To: <50520DFF.4030505@tycho.nsa.gov>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Tim Deegan <tim@xen.org>, Keir Fraser <keir@xen.org>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 19/22] arch/x86: check remote MMIO remap
 permissions
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.09.12 at 18:46, Daniel De Graaf <dgdegra@tycho.nsa.gov> wrote:
> For this example, assume domain A has access to map domain B's memory
> read-only. Domain B has access to a device with MMIO where reads to the
> device's memory cause state changes - an example of such as device is a
> TPM, where replies are read by repeated reads to a single 4-byte 
> address. Domain A does not have access to this device, and would like to
> maliciously interfere with the device.
> 
> If domain A maps the MMIO page from domain B using pg_owner == domB, the
> iomem_access_permitted check will be done from domain B's perspective. 
> While this is needed when domain A is mapping pages on behalf of domB, 
> it is not sufficient when attempting to constrain domain A's access. 
> 
> These checks only apply to MMIO, so the condition on line 735 will
> evaluate to true (!mfn_valid || real_pg_owner == dom_io).
> 
> The (existing) check on domain B's MMIO access is:
>         if ( !iomem_access_permitted(pg_owner, mfn, mfn) )
> 
> This patch adds a check on domain A:
>         if ( !iomem_access_permitted(curr->domain, mfn, mfn) )

So then I think I was right suggesting that the second check
should be done at the same place where the first one is, not
outside/after the MMIO conditional.

> This extra checking has not been required without XSM because only FLASK
> implements the ability to grant one domain read-only access to another 
> domain. With read-write access, this extra access check is simple to get
> around: domain A can modify some part of the executable code in domain B
> to act as a proxy for its accesses. Additionally, domain A is usually
> dom0 or the device model, which have equal or greater MMIO access.

Understood.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 14 09:02:11 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 09:02:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TCRmL-0008E9-3m; Fri, 14 Sep 2012 09:01:37 +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 1TCRmJ-0008E4-4i
	for xen-devel@lists.xen.org; Fri, 14 Sep 2012 09:01:35 +0000
Received: from [85.158.139.83:25725] by server-9.bemta-5.messagelabs.com id
	3B/37-20529-E62F2505; Fri, 14 Sep 2012 09:01:34 +0000
X-Env-Sender: yongjie.ren@intel.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1347613292!26583215!1
X-Originating-IP: [134.134.136.20]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjAgPT4gMjk3ODA1\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11033 invoked from network); 14 Sep 2012 09:01:33 -0000
Received: from mga02.intel.com (HELO mga02.intel.com) (134.134.136.20)
	by server-6.tower-182.messagelabs.com with SMTP;
	14 Sep 2012 09:01:33 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga101.jf.intel.com with ESMTP; 14 Sep 2012 02:01:31 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.80,422,1344236400"; d="scan'208";a="203745678"
Received: from fmsmsx103.amr.corp.intel.com ([10.19.9.34])
	by orsmga002.jf.intel.com with ESMTP; 14 Sep 2012 02:01:31 -0700
Received: from FMSMSX110.amr.corp.intel.com (10.19.9.29) by
	FMSMSX103.amr.corp.intel.com (10.19.9.34) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Fri, 14 Sep 2012 02:01:30 -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, 14 Sep 2012 02:01:30 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.239]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.175]) with mapi id
	14.01.0355.002; Fri, 14 Sep 2012 17:01:29 +0800
From: "Ren, Yongjie" <yongjie.ren@intel.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Thread-Topic: Xen4.2-rc4 test result
Thread-Index: Ac2RfcEB3+BI8Rv+Rju0UbhyhoT7xv//4lYA//4vGsA=
Date: Fri, 14 Sep 2012 09:01:28 +0000
Message-ID: <1B4B44D9196EFF41AE41FDA404FC0A1019DE3E@SHSMSX101.ccr.corp.intel.com>
References: <1B4B44D9196EFF41AE41FDA404FC0A1019BF79@SHSMSX101.ccr.corp.intel.com>
	<20120913131623.GA16635@localhost.localdomain>
In-Reply-To: <20120913131623.GA16635@localhost.localdomain>
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: 'Keir Fraser' <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] Xen4.2-rc4 test result
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> -----Original Message-----
> From: Konrad Rzeszutek Wilk [mailto:konrad.wilk@oracle.com]
> Sent: Thursday, September 13, 2012 9:16 PM
> To: Ren, Yongjie
> Cc: 'xen-devel'; 'Keir Fraser'; 'Ian Campbell'; 'Jan Beulich'
> Subject: Re: Xen4.2-rc4 test result
> 
> On Thu, Sep 13, 2012 at 07:02:40AM +0000, Ren, Yongjie wrote:
> > Hi All,
> > We did a round testing for RC4 (CS# 25834) in xen-4.2-testing tree with
> Linux 3.5.3 dom0.
> > We found 1 new issue (which is a Dom0 issue and has nothing to do with
> Xen4.2), and no fixed issue.
> >
> > New bug (1):
> > 1. XenU PV guest with vif network can't boot up with Linux3.6 dom0
> >   http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1832
> >   --A regression from Linux 3.5 to 3.6.
> 
> Oh, that is the xennet_poll one?That is fixed in v3.6-rc5. That is a
> domU problem - not domU. This git commit fixes it:
> 
Yes, right. That commit already fixed it. I also did a testing.

> commit 3683243b2c551e58082b179fd153c7d43ddc503b
> Author: Ian Campbell <Ian.Campbell@citrix.com>
> Date:   Wed Aug 22 00:26:47 2012 +0000
> 
>     xen-netfront: use __pskb_pull_tail to ensure linear area is big
> enough on RX
> 
> 
> >
> > The following are some of the old issues which we guess are something
> important.
> > Some of the old issues:
> > 1. Fail to probe NIC driver to HVM domU (with 3.5/3.6 Linux as Dom0)
> >   http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1824
> >   -- We already know the corrupt commit in Linux tree. Konrad will try to
> fix it.
> > 2. Poor performance when do guest save/restore and migration with
> linux 3.x dom0
> >   http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1784
> > 3. after detaching a VF from a guest, shutdown the guest is very slow
> (related to stdvga setting)
> >   http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1812
> > 4. Dom0 cannot be shut down before PCI device detachment from a
> running guest
> >   http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1826
> > 5. Guest hang after resuming from S3
> >   http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1828
> > 6. Dom0 S3 resume fails
> >   http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1707
> >
> > Best Regards,
> >      Yongjie (Jay)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 14 09:02:11 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 09:02:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TCRmL-0008E9-3m; Fri, 14 Sep 2012 09:01:37 +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 1TCRmJ-0008E4-4i
	for xen-devel@lists.xen.org; Fri, 14 Sep 2012 09:01:35 +0000
Received: from [85.158.139.83:25725] by server-9.bemta-5.messagelabs.com id
	3B/37-20529-E62F2505; Fri, 14 Sep 2012 09:01:34 +0000
X-Env-Sender: yongjie.ren@intel.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1347613292!26583215!1
X-Originating-IP: [134.134.136.20]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjAgPT4gMjk3ODA1\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11033 invoked from network); 14 Sep 2012 09:01:33 -0000
Received: from mga02.intel.com (HELO mga02.intel.com) (134.134.136.20)
	by server-6.tower-182.messagelabs.com with SMTP;
	14 Sep 2012 09:01:33 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga101.jf.intel.com with ESMTP; 14 Sep 2012 02:01:31 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.80,422,1344236400"; d="scan'208";a="203745678"
Received: from fmsmsx103.amr.corp.intel.com ([10.19.9.34])
	by orsmga002.jf.intel.com with ESMTP; 14 Sep 2012 02:01:31 -0700
Received: from FMSMSX110.amr.corp.intel.com (10.19.9.29) by
	FMSMSX103.amr.corp.intel.com (10.19.9.34) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Fri, 14 Sep 2012 02:01:30 -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, 14 Sep 2012 02:01:30 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.239]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.175]) with mapi id
	14.01.0355.002; Fri, 14 Sep 2012 17:01:29 +0800
From: "Ren, Yongjie" <yongjie.ren@intel.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Thread-Topic: Xen4.2-rc4 test result
Thread-Index: Ac2RfcEB3+BI8Rv+Rju0UbhyhoT7xv//4lYA//4vGsA=
Date: Fri, 14 Sep 2012 09:01:28 +0000
Message-ID: <1B4B44D9196EFF41AE41FDA404FC0A1019DE3E@SHSMSX101.ccr.corp.intel.com>
References: <1B4B44D9196EFF41AE41FDA404FC0A1019BF79@SHSMSX101.ccr.corp.intel.com>
	<20120913131623.GA16635@localhost.localdomain>
In-Reply-To: <20120913131623.GA16635@localhost.localdomain>
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: 'Keir Fraser' <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] Xen4.2-rc4 test result
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> -----Original Message-----
> From: Konrad Rzeszutek Wilk [mailto:konrad.wilk@oracle.com]
> Sent: Thursday, September 13, 2012 9:16 PM
> To: Ren, Yongjie
> Cc: 'xen-devel'; 'Keir Fraser'; 'Ian Campbell'; 'Jan Beulich'
> Subject: Re: Xen4.2-rc4 test result
> 
> On Thu, Sep 13, 2012 at 07:02:40AM +0000, Ren, Yongjie wrote:
> > Hi All,
> > We did a round testing for RC4 (CS# 25834) in xen-4.2-testing tree with
> Linux 3.5.3 dom0.
> > We found 1 new issue (which is a Dom0 issue and has nothing to do with
> Xen4.2), and no fixed issue.
> >
> > New bug (1):
> > 1. XenU PV guest with vif network can't boot up with Linux3.6 dom0
> >   http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1832
> >   --A regression from Linux 3.5 to 3.6.
> 
> Oh, that is the xennet_poll one?That is fixed in v3.6-rc5. That is a
> domU problem - not domU. This git commit fixes it:
> 
Yes, right. That commit already fixed it. I also did a testing.

> commit 3683243b2c551e58082b179fd153c7d43ddc503b
> Author: Ian Campbell <Ian.Campbell@citrix.com>
> Date:   Wed Aug 22 00:26:47 2012 +0000
> 
>     xen-netfront: use __pskb_pull_tail to ensure linear area is big
> enough on RX
> 
> 
> >
> > The following are some of the old issues which we guess are something
> important.
> > Some of the old issues:
> > 1. Fail to probe NIC driver to HVM domU (with 3.5/3.6 Linux as Dom0)
> >   http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1824
> >   -- We already know the corrupt commit in Linux tree. Konrad will try to
> fix it.
> > 2. Poor performance when do guest save/restore and migration with
> linux 3.x dom0
> >   http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1784
> > 3. after detaching a VF from a guest, shutdown the guest is very slow
> (related to stdvga setting)
> >   http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1812
> > 4. Dom0 cannot be shut down before PCI device detachment from a
> running guest
> >   http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1826
> > 5. Guest hang after resuming from S3
> >   http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1828
> > 6. Dom0 S3 resume fails
> >   http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1707
> >
> > Best Regards,
> >      Yongjie (Jay)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 14 09:02:40 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 09:02:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TCRn1-0008GS-Hj; Fri, 14 Sep 2012 09:02: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 1TCRmz-0008GC-AO
	for xen-devel@lists.xen.org; Fri, 14 Sep 2012 09:02:17 +0000
Received: from [85.158.139.83:35375] by server-8.bemta-5.messagelabs.com id
	D8/17-15219-892F2505; Fri, 14 Sep 2012 09:02:16 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1347613335!25937487!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDkxNTg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28504 invoked from network); 14 Sep 2012 09:02:15 -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;
	14 Sep 2012 09:02:15 -0000
X-IronPort-AV: E=Sophos;i="4.80,422,1344211200"; d="scan'208";a="14540018"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Sep 2012 09:02: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.279.1;
	Fri, 14 Sep 2012 10:02:15 +0100
Message-ID: <1347613333.24226.165.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Date: Fri, 14 Sep 2012 10:02:13 +0100
In-Reply-To: <9bfaf86e061f433c65ae.1347552545@xdev.gridcentric.ca>
References: <9bfaf86e061f433c65ae.1347552545@xdev.gridcentric.ca>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "andres@gridcentric.ca" <andres@gridcentric.ca>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] Fix libxenstore memory leak when
 USE_PTHREAD is not defined
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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-09-13 at 17:09 +0100, Andres Lagar-Cavilla wrote:
> tools/xenstore/xs.c |  22 ++++++----------------
>  1 files changed, 6 insertions(+), 16 deletions(-)
> 
> 
> Remove usage of pthread_cleanup_push and _pop, and explicitly call free for
> heap objects in error paths. Also remove cleanup_p* for a mutex unlock path. By
> the way, set a suitable errno value for an error path that had none.
> 
> Resend due to small fix spotted, please ignore previous one.
> 
> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

Does this reintroduce the same issue as 21353:2dd3141b3e3e was supposed
to solve (i.e. leaks memory or mutexes if you pthread_cancel the thread
in the midst of things operation)?

Can we keep cleanup_push/pop for use with the mutexes and for the
malloc/free do:

#ifdef USE_PTHREAD
#define cleanup_push... as currently
#define cleanup_pop... as currently
#define cleanup_malloc(x) cleanup_push(free, x)
#define cleanup_free(doit, x)  cleanup_pop(doit)
#else
#define cleanup_push... nop as now
#define cleanup_pop... nop as now
#define cleanup_malloc... NOP
#define cleanup_free(doit, x) if (doit) free(x)
#endif

Does that work?
> 
> diff -r 588d0dc298a4 -r 9bfaf86e061f tools/xenstore/xs.c
> --- a/tools/xenstore/xs.c
> +++ b/tools/xenstore/xs.c
> @@ -99,14 +99,6 @@ struct xs_handle {
>  #define mutex_unlock(m)		pthread_mutex_unlock(m)
>  #define condvar_signal(c)	pthread_cond_signal(c)
>  #define condvar_wait(c,m)	pthread_cond_wait(c,m)
> -#define cleanup_push(f, a)	\
> -    pthread_cleanup_push((void (*)(void *))(f), (void *)(a))
> -/*
> - * Some definitions of pthread_cleanup_pop() are a macro starting with an
> - * end-brace. GCC then complains if we immediately precede that with a label.
> - * Hence we insert a dummy statement to appease the compiler in this situation.
> - */
> -#define cleanup_pop(run)        ((void)0); pthread_cleanup_pop(run)
>  
>  #define read_thread_exists(h)	(h->read_thr_exists)
>  
> @@ -126,8 +118,6 @@ struct xs_handle {
>  #define mutex_unlock(m)		((void)0)
>  #define condvar_signal(c)	((void)0)
>  #define condvar_wait(c,m)	((void)0)
> -#define cleanup_push(f, a)	((void)0)
> -#define cleanup_pop(run)	((void)0)
>  #define read_thread_exists(h)	(0)
>  
>  #endif
> @@ -1059,7 +1049,6 @@ static int read_message(struct xs_handle
>  	msg = malloc(sizeof(*msg));
>  	if (msg == NULL)
>  		goto error;
> -	cleanup_push(free, msg);
>  	if (!read_all(h->fd, &msg->hdr, sizeof(msg->hdr), nonblocking)) { /* Cancellation point */
>  		saved_errno = errno;
>  		goto error_freemsg;
> @@ -1069,7 +1058,6 @@ static int read_message(struct xs_handle
>  	body = msg->body = malloc(msg->hdr.len + 1);
>  	if (body == NULL)
>  		goto error_freemsg;
> -	cleanup_push(free, body);
>  	if (!read_all(h->fd, body, msg->hdr.len, 0)) { /* Cancellation point */
>  		saved_errno = errno;
>  		goto error_freebody;
> @@ -1079,7 +1067,6 @@ static int read_message(struct xs_handle
>  
>  	if (msg->hdr.type == XS_WATCH_EVENT) {
>  		mutex_lock(&h->watch_mutex);
> -		cleanup_push(pthread_mutex_unlock, &h->watch_mutex);
>  
>  		/* Kick users out of their select() loop. */
>  		if (list_empty(&h->watch_list) &&
> @@ -1091,13 +1078,14 @@ static int read_message(struct xs_handle
>  
>  		condvar_signal(&h->watch_condvar);
>  
> -		cleanup_pop(1);
> +		mutex_unlock(&h->watch_mutex);
>  	} else {
>  		mutex_lock(&h->reply_mutex);
>  
>  		/* There should only ever be one response pending! */
>  		if (!list_empty(&h->reply_list)) {
>  			mutex_unlock(&h->reply_mutex);
> +			saved_errno = EEXIST; 
>  			goto error_freebody;
>  		}
>  
> @@ -1110,9 +1098,11 @@ static int read_message(struct xs_handle
>  	ret = 0;
>  
>  error_freebody:
> -	cleanup_pop(ret == -1);
> +	if (ret)
> +		free(body);
>  error_freemsg:
> -	cleanup_pop(ret == -1);
> +	if (ret)
> +		free(msg);
>  error:
>  	errno = saved_errno;
>  



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 14 09:02:40 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 09:02:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TCRn1-0008GS-Hj; Fri, 14 Sep 2012 09:02: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 1TCRmz-0008GC-AO
	for xen-devel@lists.xen.org; Fri, 14 Sep 2012 09:02:17 +0000
Received: from [85.158.139.83:35375] by server-8.bemta-5.messagelabs.com id
	D8/17-15219-892F2505; Fri, 14 Sep 2012 09:02:16 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1347613335!25937487!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDkxNTg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28504 invoked from network); 14 Sep 2012 09:02:15 -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;
	14 Sep 2012 09:02:15 -0000
X-IronPort-AV: E=Sophos;i="4.80,422,1344211200"; d="scan'208";a="14540018"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Sep 2012 09:02: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.279.1;
	Fri, 14 Sep 2012 10:02:15 +0100
Message-ID: <1347613333.24226.165.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Date: Fri, 14 Sep 2012 10:02:13 +0100
In-Reply-To: <9bfaf86e061f433c65ae.1347552545@xdev.gridcentric.ca>
References: <9bfaf86e061f433c65ae.1347552545@xdev.gridcentric.ca>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "andres@gridcentric.ca" <andres@gridcentric.ca>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] Fix libxenstore memory leak when
 USE_PTHREAD is not defined
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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-09-13 at 17:09 +0100, Andres Lagar-Cavilla wrote:
> tools/xenstore/xs.c |  22 ++++++----------------
>  1 files changed, 6 insertions(+), 16 deletions(-)
> 
> 
> Remove usage of pthread_cleanup_push and _pop, and explicitly call free for
> heap objects in error paths. Also remove cleanup_p* for a mutex unlock path. By
> the way, set a suitable errno value for an error path that had none.
> 
> Resend due to small fix spotted, please ignore previous one.
> 
> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

Does this reintroduce the same issue as 21353:2dd3141b3e3e was supposed
to solve (i.e. leaks memory or mutexes if you pthread_cancel the thread
in the midst of things operation)?

Can we keep cleanup_push/pop for use with the mutexes and for the
malloc/free do:

#ifdef USE_PTHREAD
#define cleanup_push... as currently
#define cleanup_pop... as currently
#define cleanup_malloc(x) cleanup_push(free, x)
#define cleanup_free(doit, x)  cleanup_pop(doit)
#else
#define cleanup_push... nop as now
#define cleanup_pop... nop as now
#define cleanup_malloc... NOP
#define cleanup_free(doit, x) if (doit) free(x)
#endif

Does that work?
> 
> diff -r 588d0dc298a4 -r 9bfaf86e061f tools/xenstore/xs.c
> --- a/tools/xenstore/xs.c
> +++ b/tools/xenstore/xs.c
> @@ -99,14 +99,6 @@ struct xs_handle {
>  #define mutex_unlock(m)		pthread_mutex_unlock(m)
>  #define condvar_signal(c)	pthread_cond_signal(c)
>  #define condvar_wait(c,m)	pthread_cond_wait(c,m)
> -#define cleanup_push(f, a)	\
> -    pthread_cleanup_push((void (*)(void *))(f), (void *)(a))
> -/*
> - * Some definitions of pthread_cleanup_pop() are a macro starting with an
> - * end-brace. GCC then complains if we immediately precede that with a label.
> - * Hence we insert a dummy statement to appease the compiler in this situation.
> - */
> -#define cleanup_pop(run)        ((void)0); pthread_cleanup_pop(run)
>  
>  #define read_thread_exists(h)	(h->read_thr_exists)
>  
> @@ -126,8 +118,6 @@ struct xs_handle {
>  #define mutex_unlock(m)		((void)0)
>  #define condvar_signal(c)	((void)0)
>  #define condvar_wait(c,m)	((void)0)
> -#define cleanup_push(f, a)	((void)0)
> -#define cleanup_pop(run)	((void)0)
>  #define read_thread_exists(h)	(0)
>  
>  #endif
> @@ -1059,7 +1049,6 @@ static int read_message(struct xs_handle
>  	msg = malloc(sizeof(*msg));
>  	if (msg == NULL)
>  		goto error;
> -	cleanup_push(free, msg);
>  	if (!read_all(h->fd, &msg->hdr, sizeof(msg->hdr), nonblocking)) { /* Cancellation point */
>  		saved_errno = errno;
>  		goto error_freemsg;
> @@ -1069,7 +1058,6 @@ static int read_message(struct xs_handle
>  	body = msg->body = malloc(msg->hdr.len + 1);
>  	if (body == NULL)
>  		goto error_freemsg;
> -	cleanup_push(free, body);
>  	if (!read_all(h->fd, body, msg->hdr.len, 0)) { /* Cancellation point */
>  		saved_errno = errno;
>  		goto error_freebody;
> @@ -1079,7 +1067,6 @@ static int read_message(struct xs_handle
>  
>  	if (msg->hdr.type == XS_WATCH_EVENT) {
>  		mutex_lock(&h->watch_mutex);
> -		cleanup_push(pthread_mutex_unlock, &h->watch_mutex);
>  
>  		/* Kick users out of their select() loop. */
>  		if (list_empty(&h->watch_list) &&
> @@ -1091,13 +1078,14 @@ static int read_message(struct xs_handle
>  
>  		condvar_signal(&h->watch_condvar);
>  
> -		cleanup_pop(1);
> +		mutex_unlock(&h->watch_mutex);
>  	} else {
>  		mutex_lock(&h->reply_mutex);
>  
>  		/* There should only ever be one response pending! */
>  		if (!list_empty(&h->reply_list)) {
>  			mutex_unlock(&h->reply_mutex);
> +			saved_errno = EEXIST; 
>  			goto error_freebody;
>  		}
>  
> @@ -1110,9 +1098,11 @@ static int read_message(struct xs_handle
>  	ret = 0;
>  
>  error_freebody:
> -	cleanup_pop(ret == -1);
> +	if (ret)
> +		free(body);
>  error_freemsg:
> -	cleanup_pop(ret == -1);
> +	if (ret)
> +		free(msg);
>  error:
>  	errno = saved_errno;
>  



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 14 09:05:29 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 09:05:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TCRph-0008Qn-4E; Fri, 14 Sep 2012 09:05: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 1TCRpf-0008Qa-Rp
	for xen-devel@lists.xen.org; Fri, 14 Sep 2012 09:05:03 +0000
Received: from [85.158.139.83:64675] by server-9.bemta-5.messagelabs.com id
	3F/F2-20529-F33F2505; Fri, 14 Sep 2012 09:05:03 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1347613502!30305185!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDkxNTg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15083 invoked from network); 14 Sep 2012 09:05:02 -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;
	14 Sep 2012 09:05:02 -0000
X-IronPort-AV: E=Sophos;i="4.80,422,1344211200"; d="scan'208";a="14540086"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Sep 2012 09:05: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.279.1;
	Fri, 14 Sep 2012 10:05:02 +0100
Message-ID: <1347613500.24226.166.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Fri, 14 Sep 2012 10:05:00 +0100
In-Reply-To: <1347294370.5305.116.camel@zakaz.uk.xensource.com>
References: <99b7a5af9b3059bac273.1346676538@cosworth.uk.xensource.com>
	<20551.26024.217179.594711@mariner.uk.xensource.com>
	<1346856750.17325.110.camel@zakaz.uk.xensource.com>
	<1347294370.5305.116.camel@zakaz.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Andres Lagar-Cavilla <andreslc@gridcentric.ca>,
	"Tim \(Xen.org\)" <tim@xen.org>,
	Stefano Panella <stefano.panella@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] libxl: handle errors from xc_sharing_* info
 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 Mon, 2012-09-10 at 17:26 +0100, Ian Campbell wrote:
> libxl: handle errors from xc_sharing_* info functions
> 
> On a 32 bit hypervisor xl info currently reports:
> sharing_freed_memory   : 72057594037927935
> sharing_used_memory    : 72057594037927935
> 
> Eat the ENOSYS and turn it into 0. Log and propagate other errors.
> 
> I don't have a 32 bit system handy, so tested on x86_64 with a libxc
> hacked to return -ENOSYS and -EINVAL.
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
> Acked-by: Andres Lagar-Cavilla <andres@lagarcavilla.org> 

Applied, thanks.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 14 09:05:29 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 09:05:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TCRph-0008Qn-4E; Fri, 14 Sep 2012 09:05: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 1TCRpf-0008Qa-Rp
	for xen-devel@lists.xen.org; Fri, 14 Sep 2012 09:05:03 +0000
Received: from [85.158.139.83:64675] by server-9.bemta-5.messagelabs.com id
	3F/F2-20529-F33F2505; Fri, 14 Sep 2012 09:05:03 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1347613502!30305185!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDkxNTg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15083 invoked from network); 14 Sep 2012 09:05:02 -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;
	14 Sep 2012 09:05:02 -0000
X-IronPort-AV: E=Sophos;i="4.80,422,1344211200"; d="scan'208";a="14540086"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Sep 2012 09:05: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.279.1;
	Fri, 14 Sep 2012 10:05:02 +0100
Message-ID: <1347613500.24226.166.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Fri, 14 Sep 2012 10:05:00 +0100
In-Reply-To: <1347294370.5305.116.camel@zakaz.uk.xensource.com>
References: <99b7a5af9b3059bac273.1346676538@cosworth.uk.xensource.com>
	<20551.26024.217179.594711@mariner.uk.xensource.com>
	<1346856750.17325.110.camel@zakaz.uk.xensource.com>
	<1347294370.5305.116.camel@zakaz.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Andres Lagar-Cavilla <andreslc@gridcentric.ca>,
	"Tim \(Xen.org\)" <tim@xen.org>,
	Stefano Panella <stefano.panella@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] libxl: handle errors from xc_sharing_* info
 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 Mon, 2012-09-10 at 17:26 +0100, Ian Campbell wrote:
> libxl: handle errors from xc_sharing_* info functions
> 
> On a 32 bit hypervisor xl info currently reports:
> sharing_freed_memory   : 72057594037927935
> sharing_used_memory    : 72057594037927935
> 
> Eat the ENOSYS and turn it into 0. Log and propagate other errors.
> 
> I don't have a 32 bit system handy, so tested on x86_64 with a libxc
> hacked to return -ENOSYS and -EINVAL.
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
> Acked-by: Andres Lagar-Cavilla <andres@lagarcavilla.org> 

Applied, thanks.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 14 09:06:02 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 09: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 1TCRqK-0008VM-Hf; Fri, 14 Sep 2012 09:05:44 +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 1TCRqI-0008Uj-Rf
	for xen-devel@lists.xen.org; Fri, 14 Sep 2012 09:05:43 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1347613536!3296005!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDkyOTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9230 invoked from network); 14 Sep 2012 09:05:36 -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;
	14 Sep 2012 09:05:36 -0000
X-IronPort-AV: E=Sophos;i="4.80,422,1344211200"; d="scan'208";a="14540105"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Sep 2012 09: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.279.1;
	Fri, 14 Sep 2012 10:05:36 +0100
Message-ID: <1347613534.24226.167.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Roger Pau Monne <roger.pau@citrix.com>
Date: Fri, 14 Sep 2012 10:05:34 +0100
In-Reply-To: <1346846602-1109-1-git-send-email-roger.pau@citrix.com>
References: <20120905030239.GJ8912@reaktio.net>
	<1346846602-1109-1-git-send-email-roger.pau@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] libfsimage: add ext4 support for CentOS 5.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 Wed, 2012-09-05 at 13:03 +0100, Roger Pau Monne wrote:
> CentOS 5.x forked e2fs ext4 support into a different package called
> e4fs, and so headers and library names changed from ext2fs to ext4fs.
> Check if ext4fs/ext2fs.h and -lext4fs work, and use that instead of
> ext2fs to build libfsimage. This patch assumes that if the ext4fs
> library is present it should always be used instead of ext2fs.
> 
> This patch includes a rework of the ext2fs check, a new ext4fs check
> and a minor modification in libfsimage to use the correct library.
> 
> Signed-off-by: Roger Pau Monne <roger.pau@citrix.com>
> ---
> Please re-run autogen.sh after applying

Done & acked + applied. Thanks.

> diff --git a/tools/libfsimage/ext2fs-lib/Makefile b/tools/libfsimage/ext2fs-lib/Makefile
> index 142207f..671fbff 100644
> --- a/tools/libfsimage/ext2fs-lib/Makefile
> +++ b/tools/libfsimage/ext2fs-lib/Makefile
> @@ -4,7 +4,10 @@ LIB_SRCS-y = ext2fs-lib.c
>  
>  FS = ext2fs-lib
>  
> -FS_LIBDEPS = -lext2fs
> +FS_LIBDEPS = $(EXTFS_LIBS)
> +
> +# Include configure output (config.h) to headers search path
> +CFLAGS += -I$(XEN_ROOT)/tools

Is there any way to move config.h from tools to under tools/include
somewhere? 

>  
>  .PHONY: all
>  all: fs-all
> diff --git a/tools/libfsimage/ext2fs-lib/ext2fs-lib.c b/tools/libfsimage/ext2fs-lib/ext2fs-lib.c
> index 36a27dc..ed47146 100644
> --- a/tools/libfsimage/ext2fs-lib/ext2fs-lib.c
> +++ b/tools/libfsimage/ext2fs-lib/ext2fs-lib.c
> @@ -21,8 +21,11 @@
>   * Use is subject to license terms.
>   */
>  
> +/* Include output from configure */
> +#include <config.h>
> +
>  #include <fsimage_plugin.h>
> -#include <ext2fs/ext2fs.h>
> +#include INCLUDE_EXTFS_H
>  #include <errno.h>
>  #include <inttypes.h>
>  
> diff --git a/tools/m4/extfs.m4 b/tools/m4/extfs.m4
> new file mode 100644
> index 0000000..7309da9
> --- /dev/null
> +++ b/tools/m4/extfs.m4
> @@ -0,0 +1,20 @@
> +AC_DEFUN([AX_CHECK_EXTFS], [
> +AC_CHECK_HEADER([ext2fs/ext2fs.h], [
> +AC_CHECK_LIB([ext2fs], [ext2fs_open2], [
> +    AC_DEFINE([INCLUDE_EXTFS_H], [<ext2fs/ext2fs.h>],
> +              [Define extfs header to use])
> +    EXTFS_LIBS="-lext2fs"
> +])
> +])
> +dnl This is a temporary hack for CentOS 5.x, which split the ext4 support
> +dnl of ext2fs in a different package. Once CentOS 5.x is no longer supported
> +dnl we can remove this.
> +AC_CHECK_HEADER([ext4fs/ext2fs.h], [
> +AC_CHECK_LIB([ext4fs], [ext2fs_open2], [
> +    AC_DEFINE([INCLUDE_EXTFS_H], [<ext4fs/ext2fs.h>],
> +              [Define extfs header to use])
> +    EXTFS_LIBS="-lext4fs"
> +])
> +])
> +AC_SUBST(EXTFS_LIBS)
> +])



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 14 09:06:02 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 09: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 1TCRqK-0008VM-Hf; Fri, 14 Sep 2012 09:05:44 +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 1TCRqI-0008Uj-Rf
	for xen-devel@lists.xen.org; Fri, 14 Sep 2012 09:05:43 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1347613536!3296005!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDkyOTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9230 invoked from network); 14 Sep 2012 09:05:36 -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;
	14 Sep 2012 09:05:36 -0000
X-IronPort-AV: E=Sophos;i="4.80,422,1344211200"; d="scan'208";a="14540105"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Sep 2012 09: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.279.1;
	Fri, 14 Sep 2012 10:05:36 +0100
Message-ID: <1347613534.24226.167.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Roger Pau Monne <roger.pau@citrix.com>
Date: Fri, 14 Sep 2012 10:05:34 +0100
In-Reply-To: <1346846602-1109-1-git-send-email-roger.pau@citrix.com>
References: <20120905030239.GJ8912@reaktio.net>
	<1346846602-1109-1-git-send-email-roger.pau@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] libfsimage: add ext4 support for CentOS 5.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 Wed, 2012-09-05 at 13:03 +0100, Roger Pau Monne wrote:
> CentOS 5.x forked e2fs ext4 support into a different package called
> e4fs, and so headers and library names changed from ext2fs to ext4fs.
> Check if ext4fs/ext2fs.h and -lext4fs work, and use that instead of
> ext2fs to build libfsimage. This patch assumes that if the ext4fs
> library is present it should always be used instead of ext2fs.
> 
> This patch includes a rework of the ext2fs check, a new ext4fs check
> and a minor modification in libfsimage to use the correct library.
> 
> Signed-off-by: Roger Pau Monne <roger.pau@citrix.com>
> ---
> Please re-run autogen.sh after applying

Done & acked + applied. Thanks.

> diff --git a/tools/libfsimage/ext2fs-lib/Makefile b/tools/libfsimage/ext2fs-lib/Makefile
> index 142207f..671fbff 100644
> --- a/tools/libfsimage/ext2fs-lib/Makefile
> +++ b/tools/libfsimage/ext2fs-lib/Makefile
> @@ -4,7 +4,10 @@ LIB_SRCS-y = ext2fs-lib.c
>  
>  FS = ext2fs-lib
>  
> -FS_LIBDEPS = -lext2fs
> +FS_LIBDEPS = $(EXTFS_LIBS)
> +
> +# Include configure output (config.h) to headers search path
> +CFLAGS += -I$(XEN_ROOT)/tools

Is there any way to move config.h from tools to under tools/include
somewhere? 

>  
>  .PHONY: all
>  all: fs-all
> diff --git a/tools/libfsimage/ext2fs-lib/ext2fs-lib.c b/tools/libfsimage/ext2fs-lib/ext2fs-lib.c
> index 36a27dc..ed47146 100644
> --- a/tools/libfsimage/ext2fs-lib/ext2fs-lib.c
> +++ b/tools/libfsimage/ext2fs-lib/ext2fs-lib.c
> @@ -21,8 +21,11 @@
>   * Use is subject to license terms.
>   */
>  
> +/* Include output from configure */
> +#include <config.h>
> +
>  #include <fsimage_plugin.h>
> -#include <ext2fs/ext2fs.h>
> +#include INCLUDE_EXTFS_H
>  #include <errno.h>
>  #include <inttypes.h>
>  
> diff --git a/tools/m4/extfs.m4 b/tools/m4/extfs.m4
> new file mode 100644
> index 0000000..7309da9
> --- /dev/null
> +++ b/tools/m4/extfs.m4
> @@ -0,0 +1,20 @@
> +AC_DEFUN([AX_CHECK_EXTFS], [
> +AC_CHECK_HEADER([ext2fs/ext2fs.h], [
> +AC_CHECK_LIB([ext2fs], [ext2fs_open2], [
> +    AC_DEFINE([INCLUDE_EXTFS_H], [<ext2fs/ext2fs.h>],
> +              [Define extfs header to use])
> +    EXTFS_LIBS="-lext2fs"
> +])
> +])
> +dnl This is a temporary hack for CentOS 5.x, which split the ext4 support
> +dnl of ext2fs in a different package. Once CentOS 5.x is no longer supported
> +dnl we can remove this.
> +AC_CHECK_HEADER([ext4fs/ext2fs.h], [
> +AC_CHECK_LIB([ext4fs], [ext2fs_open2], [
> +    AC_DEFINE([INCLUDE_EXTFS_H], [<ext4fs/ext2fs.h>],
> +              [Define extfs header to use])
> +    EXTFS_LIBS="-lext4fs"
> +])
> +])
> +AC_SUBST(EXTFS_LIBS)
> +])



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 14 09:06:24 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 09: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 1TCRqm-00008H-3T; Fri, 14 Sep 2012 09:06: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 1TCRqk-00007m-Ea
	for xen-devel@lists.xen.org; Fri, 14 Sep 2012 09:06:10 +0000
Received: from [85.158.138.51:3253] by server-10.bemta-3.messagelabs.com id
	59/97-10411-183F2505; Fri, 14 Sep 2012 09:06:09 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1347613568!28833861!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDkxNTg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10024 invoked from network); 14 Sep 2012 09:06: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;
	14 Sep 2012 09:06:08 -0000
X-IronPort-AV: E=Sophos;i="4.80,422,1344211200"; d="scan'208";a="14540122"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Sep 2012 09:06: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.279.1;
	Fri, 14 Sep 2012 10:06:08 +0100
Message-ID: <1347613567.24226.168.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Roger Pau Monne <roger.pau@citrix.com>
Date: Fri, 14 Sep 2012 10:06:07 +0100
In-Reply-To: <1346771812-98690-1-git-send-email-roger.pau@citrix.com>
References: <1346771812-98690-1-git-send-email-roger.pau@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v2 1/2] libxl: fix usage of backend
 parameter and run_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

On Tue, 2012-09-04 at 16:16 +0100, Roger Pau Monne wrote:
> vif interfaces allows the user to specify the domain that should run
> the backend (also known as driver domain) using the 'backend'
> parameter. This is not compatible with run_hotplug_scripts=1, since
> libxl can only run the hotplug scripts from the Domain 0.
> 
> Signed-off-by: Roger Pau Monne <roger.pau@citrix.com>

Acked + applied, thanks.

> ---
> Changes since v1:
> 
>  * Remove references to xl.conf, since it's a layering violation.
> 
>  * Move the docs update to next patch (that includes xl changes).
> ---
>  tools/libxl/libxl.c |   14 ++++++++++++++
>  1 files changed, 14 insertions(+), 0 deletions(-)
> 
> diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
> index 8ea3478..47b1fb9 100644
> --- a/tools/libxl/libxl.c
> +++ b/tools/libxl/libxl.c
> @@ -2474,6 +2474,8 @@ out:
>  int libxl__device_nic_setdefault(libxl__gc *gc, libxl_device_nic *nic,
>                                   uint32_t domid)
>  {
> +    int run_hotplug_scripts;
> +
>      if (!nic->mtu)
>          nic->mtu = 1492;
>      if (!nic->model) {
> @@ -2503,6 +2505,18 @@ int libxl__device_nic_setdefault(libxl__gc *gc, libxl_device_nic *nic,
>                                    libxl__xen_script_dir_path()) < 0 )
>          return ERROR_FAIL;
>  
> +    run_hotplug_scripts = libxl__hotplug_settings(gc, XBT_NULL);
> +    if (run_hotplug_scripts < 0) {
> +        LOG(ERROR, "unable to get current hotplug scripts execution setting");
> +        return run_hotplug_scripts;
> +    }
> +    if (nic->backend_domid != LIBXL_TOOLSTACK_DOMID && run_hotplug_scripts) {
> +        LOG(ERROR, "cannot use a backend domain different than %d if"
> +                   "hotplug scripts are executed from libxl",
> +                   LIBXL_TOOLSTACK_DOMID);
> +        return ERROR_FAIL;
> +    }
> +
>      switch (libxl__domain_type(gc, domid)) {
>      case LIBXL_DOMAIN_TYPE_HVM:
>          if (!nic->nictype)



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 14 09:06:24 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 09: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 1TCRqm-00008H-3T; Fri, 14 Sep 2012 09:06: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 1TCRqk-00007m-Ea
	for xen-devel@lists.xen.org; Fri, 14 Sep 2012 09:06:10 +0000
Received: from [85.158.138.51:3253] by server-10.bemta-3.messagelabs.com id
	59/97-10411-183F2505; Fri, 14 Sep 2012 09:06:09 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1347613568!28833861!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDkxNTg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10024 invoked from network); 14 Sep 2012 09:06: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;
	14 Sep 2012 09:06:08 -0000
X-IronPort-AV: E=Sophos;i="4.80,422,1344211200"; d="scan'208";a="14540122"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Sep 2012 09:06: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.279.1;
	Fri, 14 Sep 2012 10:06:08 +0100
Message-ID: <1347613567.24226.168.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Roger Pau Monne <roger.pau@citrix.com>
Date: Fri, 14 Sep 2012 10:06:07 +0100
In-Reply-To: <1346771812-98690-1-git-send-email-roger.pau@citrix.com>
References: <1346771812-98690-1-git-send-email-roger.pau@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v2 1/2] libxl: fix usage of backend
 parameter and run_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

On Tue, 2012-09-04 at 16:16 +0100, Roger Pau Monne wrote:
> vif interfaces allows the user to specify the domain that should run
> the backend (also known as driver domain) using the 'backend'
> parameter. This is not compatible with run_hotplug_scripts=1, since
> libxl can only run the hotplug scripts from the Domain 0.
> 
> Signed-off-by: Roger Pau Monne <roger.pau@citrix.com>

Acked + applied, thanks.

> ---
> Changes since v1:
> 
>  * Remove references to xl.conf, since it's a layering violation.
> 
>  * Move the docs update to next patch (that includes xl changes).
> ---
>  tools/libxl/libxl.c |   14 ++++++++++++++
>  1 files changed, 14 insertions(+), 0 deletions(-)
> 
> diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
> index 8ea3478..47b1fb9 100644
> --- a/tools/libxl/libxl.c
> +++ b/tools/libxl/libxl.c
> @@ -2474,6 +2474,8 @@ out:
>  int libxl__device_nic_setdefault(libxl__gc *gc, libxl_device_nic *nic,
>                                   uint32_t domid)
>  {
> +    int run_hotplug_scripts;
> +
>      if (!nic->mtu)
>          nic->mtu = 1492;
>      if (!nic->model) {
> @@ -2503,6 +2505,18 @@ int libxl__device_nic_setdefault(libxl__gc *gc, libxl_device_nic *nic,
>                                    libxl__xen_script_dir_path()) < 0 )
>          return ERROR_FAIL;
>  
> +    run_hotplug_scripts = libxl__hotplug_settings(gc, XBT_NULL);
> +    if (run_hotplug_scripts < 0) {
> +        LOG(ERROR, "unable to get current hotplug scripts execution setting");
> +        return run_hotplug_scripts;
> +    }
> +    if (nic->backend_domid != LIBXL_TOOLSTACK_DOMID && run_hotplug_scripts) {
> +        LOG(ERROR, "cannot use a backend domain different than %d if"
> +                   "hotplug scripts are executed from libxl",
> +                   LIBXL_TOOLSTACK_DOMID);
> +        return ERROR_FAIL;
> +    }
> +
>      switch (libxl__domain_type(gc, domid)) {
>      case LIBXL_DOMAIN_TYPE_HVM:
>          if (!nic->nictype)



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 14 09:06:40 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 09:06:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TCRqz-0000B4-GC; Fri, 14 Sep 2012 09:06:25 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1TCRqy-0000AR-9p
	for xen-devel@lists.xen.org; Fri, 14 Sep 2012 09:06:24 +0000
Received: from [85.158.138.51:4556] by server-7.bemta-3.messagelabs.com id
	20/A1-32000-F83F2505; Fri, 14 Sep 2012 09:06:23 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1347613582!21640499!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDkxNTg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13423 invoked from network); 14 Sep 2012 09:06:22 -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 Sep 2012 09:06:22 -0000
X-IronPort-AV: E=Sophos;i="4.80,422,1344211200"; d="scan'208";a="14540132"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Sep 2012 09:06:21 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Fri, 14 Sep 2012 10:06:21 +0100
Message-ID: <1347613580.24226.169.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Roger Pau Monne <roger.pau@citrix.com>
Date: Fri, 14 Sep 2012 10:06:20 +0100
In-Reply-To: <1346771812-98690-2-git-send-email-roger.pau@citrix.com>
References: <1346771812-98690-1-git-send-email-roger.pau@citrix.com>
	<1346771812-98690-2-git-send-email-roger.pau@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v2 2/2] xl: error if vif backend!=0 is used
 with run_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

On Tue, 2012-09-04 at 16:16 +0100, Roger Pau Monne wrote:
> Print an error and exit if backend!=0 is used in conjunction with
> run_hotplug_scripts. Currently libxl can only execute hotplug scripts
> from the toolstack domain (the same domain xl is running from).
> 
> Added a description and workaround of this issue on
> xl-network-configuration.
> 
> Signed-off-by: Roger Pau Monne <roger.pau@citrix.com>

Acked + applied, thanks.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 14 09:06:40 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 09:06:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TCRqz-0000B4-GC; Fri, 14 Sep 2012 09:06:25 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1TCRqy-0000AR-9p
	for xen-devel@lists.xen.org; Fri, 14 Sep 2012 09:06:24 +0000
Received: from [85.158.138.51:4556] by server-7.bemta-3.messagelabs.com id
	20/A1-32000-F83F2505; Fri, 14 Sep 2012 09:06:23 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1347613582!21640499!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDkxNTg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13423 invoked from network); 14 Sep 2012 09:06:22 -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 Sep 2012 09:06:22 -0000
X-IronPort-AV: E=Sophos;i="4.80,422,1344211200"; d="scan'208";a="14540132"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Sep 2012 09:06:21 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Fri, 14 Sep 2012 10:06:21 +0100
Message-ID: <1347613580.24226.169.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Roger Pau Monne <roger.pau@citrix.com>
Date: Fri, 14 Sep 2012 10:06:20 +0100
In-Reply-To: <1346771812-98690-2-git-send-email-roger.pau@citrix.com>
References: <1346771812-98690-1-git-send-email-roger.pau@citrix.com>
	<1346771812-98690-2-git-send-email-roger.pau@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v2 2/2] xl: error if vif backend!=0 is used
 with run_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

On Tue, 2012-09-04 at 16:16 +0100, Roger Pau Monne wrote:
> Print an error and exit if backend!=0 is used in conjunction with
> run_hotplug_scripts. Currently libxl can only execute hotplug scripts
> from the toolstack domain (the same domain xl is running from).
> 
> Added a description and workaround of this issue on
> xl-network-configuration.
> 
> Signed-off-by: Roger Pau Monne <roger.pau@citrix.com>

Acked + applied, thanks.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 14 09:07:16 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 09: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 1TCRrb-0000KU-UT; Fri, 14 Sep 2012 09:07: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 1TCRra-0000K8-N1
	for xen-devel@lists.xensource.com; Fri, 14 Sep 2012 09:07:02 +0000
Received: from [85.158.143.35:37931] by server-1.bemta-4.messagelabs.com id
	07/44-12504-6B3F2505; Fri, 14 Sep 2012 09:07:02 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1347613620!10128965!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDkyOTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24651 invoked from network); 14 Sep 2012 09:07:00 -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;
	14 Sep 2012 09:07:00 -0000
X-IronPort-AV: E=Sophos;i="4.80,422,1344211200"; d="scan'208";a="14540157"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Sep 2012 09:07:00 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Fri, 14 Sep 2012 10:07:00 +0100
Message-ID: <1347613618.24226.171.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Fri, 14 Sep 2012 10:06:58 +0100
In-Reply-To: <20486.37922.472920.327875@mariner.uk.xensource.com>
References: <b1bf5533d56589845169.1341428145@salem.ambrosia>
	<20485.26502.956176.263396@mariner.uk.xensource.com>
	<20120717183908.b6711e60207c3e94444a0961@parasite.cc>
	<20486.37922.472920.327875@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	slam <slam@parasite.cc>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] xentop.c: Change curses painting behavior
 to avoid flicker
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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-07-18 at 11:46 +0100, Ian Jackson wrote:
> slam writes ("Re: [PATCH] xentop.c: Change curses painting behavior to avoid flicker"):
> > I apologize in advance for the newb questions.  Is there anything I need
> > to do to help this patch make it into 4.3?  Will I need to re-post it
> > to the list again at a later date, or is my first post of this
> > sufficient assuming the patch remains unchanged?
> 
> No need to apologise.  In theory I'd hope we remember this but in
> practice we don't have any formal tracking.
> 
> So if you can, please do repost this after 4.2 is released.

I've applied this to unstable (aka 4.3-pre) 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 Sep 14 09:07:16 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 09: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 1TCRrb-0000KU-UT; Fri, 14 Sep 2012 09:07: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 1TCRra-0000K8-N1
	for xen-devel@lists.xensource.com; Fri, 14 Sep 2012 09:07:02 +0000
Received: from [85.158.143.35:37931] by server-1.bemta-4.messagelabs.com id
	07/44-12504-6B3F2505; Fri, 14 Sep 2012 09:07:02 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1347613620!10128965!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDkyOTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24651 invoked from network); 14 Sep 2012 09:07:00 -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;
	14 Sep 2012 09:07:00 -0000
X-IronPort-AV: E=Sophos;i="4.80,422,1344211200"; d="scan'208";a="14540157"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Sep 2012 09:07:00 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Fri, 14 Sep 2012 10:07:00 +0100
Message-ID: <1347613618.24226.171.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Fri, 14 Sep 2012 10:06:58 +0100
In-Reply-To: <20486.37922.472920.327875@mariner.uk.xensource.com>
References: <b1bf5533d56589845169.1341428145@salem.ambrosia>
	<20485.26502.956176.263396@mariner.uk.xensource.com>
	<20120717183908.b6711e60207c3e94444a0961@parasite.cc>
	<20486.37922.472920.327875@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	slam <slam@parasite.cc>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] xentop.c: Change curses painting behavior
 to avoid flicker
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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-07-18 at 11:46 +0100, Ian Jackson wrote:
> slam writes ("Re: [PATCH] xentop.c: Change curses painting behavior to avoid flicker"):
> > I apologize in advance for the newb questions.  Is there anything I need
> > to do to help this patch make it into 4.3?  Will I need to re-post it
> > to the list again at a later date, or is my first post of this
> > sufficient assuming the patch remains unchanged?
> 
> No need to apologise.  In theory I'd hope we remember this but in
> practice we don't have any formal tracking.
> 
> So if you can, please do repost this after 4.2 is released.

I've applied this to unstable (aka 4.3-pre) 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 Sep 14 09:07:44 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 09:07:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TCRs4-0000Ru-Cq; Fri, 14 Sep 2012 09:07:32 +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 1TCRs2-0000Qa-Md
	for xen-devel@lists.xen.org; Fri, 14 Sep 2012 09:07:30 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1347613635!3296308!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDkyOTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15418 invoked from network); 14 Sep 2012 09:07:16 -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;
	14 Sep 2012 09:07:16 -0000
X-IronPort-AV: E=Sophos;i="4.80,422,1344211200"; d="scan'208";a="14540163"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Sep 2012 09:07: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.279.1;
	Fri, 14 Sep 2012 10:07:15 +0100
Message-ID: <1347613634.24226.172.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Fri, 14 Sep 2012 10:07:14 +0100
In-Reply-To: <20562.140.449219.771492@mariner.uk.xensource.com>
References: <22452f41545c1786e887.1347295130@u002268147cd4502c336d.ant.amazon.com>
	<20562.140.449219.771492@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-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 v2] docs: flesh out xl.cfg documentation,
 correct typos, reorganize
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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-09-13 at 16:49 +0100, Ian Jackson wrote:
> Matt Wilson writes ("[Xen-devel] [PATCH v2] docs: flesh out xl.cfg documentation, correct typos, reorganize"):
> > Some highlights:
> >  * Correct some markup errors:
> >        Around line 663:
> >            '=item' outside of any '=over'
> >        Around line 671:
> >            You forgot a '=back' before '=head3'
> >  * Add documentation for msitranslate, power_mgnt, acpi_s3, aspi_s4,
> >    gfx_passthru, nomigrate, etc.
> >  * Reorganize items in "unclassified" sections like cpuid,
> >    gfx_passthru to where they belong
> >  * Correct link L<> references so they can be resolved within the
> >    document
> >  * Remove placeholders for deprecated options device_model and vif2
> >  * Remove placeholder for "sched" and "node", as these are options for
> >    cpupool configuration. Perhaps cpupool configuration deserves
> >    a section in this document.
> >  * Rename "global" options to "general"
> >  * Add section headers to group general VM options.
> > 
> > Signed-off-by: Matt Wilson <msw@amazon.com>
> 
> Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

Applied, thanks.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 14 09:07:44 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 09:07:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TCRs4-0000Ru-Cq; Fri, 14 Sep 2012 09:07:32 +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 1TCRs2-0000Qa-Md
	for xen-devel@lists.xen.org; Fri, 14 Sep 2012 09:07:30 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1347613635!3296308!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDkyOTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15418 invoked from network); 14 Sep 2012 09:07:16 -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;
	14 Sep 2012 09:07:16 -0000
X-IronPort-AV: E=Sophos;i="4.80,422,1344211200"; d="scan'208";a="14540163"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Sep 2012 09:07: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.279.1;
	Fri, 14 Sep 2012 10:07:15 +0100
Message-ID: <1347613634.24226.172.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Fri, 14 Sep 2012 10:07:14 +0100
In-Reply-To: <20562.140.449219.771492@mariner.uk.xensource.com>
References: <22452f41545c1786e887.1347295130@u002268147cd4502c336d.ant.amazon.com>
	<20562.140.449219.771492@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-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 v2] docs: flesh out xl.cfg documentation,
 correct typos, reorganize
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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-09-13 at 16:49 +0100, Ian Jackson wrote:
> Matt Wilson writes ("[Xen-devel] [PATCH v2] docs: flesh out xl.cfg documentation, correct typos, reorganize"):
> > Some highlights:
> >  * Correct some markup errors:
> >        Around line 663:
> >            '=item' outside of any '=over'
> >        Around line 671:
> >            You forgot a '=back' before '=head3'
> >  * Add documentation for msitranslate, power_mgnt, acpi_s3, aspi_s4,
> >    gfx_passthru, nomigrate, etc.
> >  * Reorganize items in "unclassified" sections like cpuid,
> >    gfx_passthru to where they belong
> >  * Correct link L<> references so they can be resolved within the
> >    document
> >  * Remove placeholders for deprecated options device_model and vif2
> >  * Remove placeholder for "sched" and "node", as these are options for
> >    cpupool configuration. Perhaps cpupool configuration deserves
> >    a section in this document.
> >  * Rename "global" options to "general"
> >  * Add section headers to group general VM options.
> > 
> > Signed-off-by: Matt Wilson <msw@amazon.com>
> 
> Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

Applied, thanks.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 14 09:07:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 09:07:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TCRs9-0000TK-Qp; Fri, 14 Sep 2012 09:07: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 1TCRs9-0000T2-0E
	for xen-devel@lists.xen.org; Fri, 14 Sep 2012 09:07:37 +0000
Received: from [85.158.143.35:43930] by server-2.bemta-4.messagelabs.com id
	2C/BB-21239-8D3F2505; Fri, 14 Sep 2012 09:07:36 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1347613602!16856264!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDkyOTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20118 invoked from network); 14 Sep 2012 09:06: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;
	14 Sep 2012 09:06:42 -0000
X-IronPort-AV: E=Sophos;i="4.80,422,1344211200"; d="scan'208";a="14540148"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Sep 2012 09:06: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.279.1;
	Fri, 14 Sep 2012 10:06:42 +0100
Message-ID: <1347613600.24226.170.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Juergen Gross <juergen.gross@ts.fujitsu.com>
Date: Fri, 14 Sep 2012 10:06:40 +0100
In-Reply-To: <5048A869.6060002@ts.fujitsu.com>
References: <d4d7031eb68bf0ce9bc8.1346932006@cosworth.uk.xensource.com>
	<5048A869.6060002@ts.fujitsu.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-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] xl: do not leak cpupool names
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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-09-06 at 14:43 +0100, Juergen Gross wrote:
> Am 06.09.2012 13:46, schrieb Ian Campbell:
> > # HG changeset patch
> > # User Ian Campbell<ian.campbell@citrix.com>
> > # Date 1346931944 -3600
> > # Node ID d4d7031eb68bf0ce9bc83901b699cf13a2c73c95
> > # Parent  1db796c3c0b97bba222f20db543c227e313ec1be
> > xl: do not leak cpupool names.
> >
> > Valgrind reports:
> > ==3076== 7 bytes in 1 blocks are definitely lost in loss record 1 of 1
> > ==3076==    at 0x402458C: malloc (vg_replace_malloc.c:270)
> > ==3076==    by 0x406F86D: libxl_cpupoolid_to_name (libxl_utils.c:102)
> > ==3076==    by 0x8058742: parse_config_data (xl_cmdimpl.c:639)
> > ==3076==    by 0x805BD56: create_domain (xl_cmdimpl.c:1838)
> > ==3076==    by 0x805DAED: main_create (xl_cmdimpl.c:3903)
> > ==3076==    by 0x804D39D: main (xl.c:285)
> >
> > And indeed there are several places where xl uses
> > libxl_cpupoolid_to_name as a boolean to test if the pool name is
> > valid and leaks the name if it is. Introduce an is_valid helper and
> > use that instead.
> >
> > Signed-off-by: Ian Campbell<ian.campbell@citrix.com>
> 
> Acked-by: Juergen Gross<juergen.gross@ts.fujitsu.com>

Applied, thanks.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 14 09:07:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 09:07:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TCRs9-0000TK-Qp; Fri, 14 Sep 2012 09:07: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 1TCRs9-0000T2-0E
	for xen-devel@lists.xen.org; Fri, 14 Sep 2012 09:07:37 +0000
Received: from [85.158.143.35:43930] by server-2.bemta-4.messagelabs.com id
	2C/BB-21239-8D3F2505; Fri, 14 Sep 2012 09:07:36 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1347613602!16856264!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDkyOTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20118 invoked from network); 14 Sep 2012 09:06: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;
	14 Sep 2012 09:06:42 -0000
X-IronPort-AV: E=Sophos;i="4.80,422,1344211200"; d="scan'208";a="14540148"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Sep 2012 09:06: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.279.1;
	Fri, 14 Sep 2012 10:06:42 +0100
Message-ID: <1347613600.24226.170.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Juergen Gross <juergen.gross@ts.fujitsu.com>
Date: Fri, 14 Sep 2012 10:06:40 +0100
In-Reply-To: <5048A869.6060002@ts.fujitsu.com>
References: <d4d7031eb68bf0ce9bc8.1346932006@cosworth.uk.xensource.com>
	<5048A869.6060002@ts.fujitsu.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-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] xl: do not leak cpupool names
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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-09-06 at 14:43 +0100, Juergen Gross wrote:
> Am 06.09.2012 13:46, schrieb Ian Campbell:
> > # HG changeset patch
> > # User Ian Campbell<ian.campbell@citrix.com>
> > # Date 1346931944 -3600
> > # Node ID d4d7031eb68bf0ce9bc83901b699cf13a2c73c95
> > # Parent  1db796c3c0b97bba222f20db543c227e313ec1be
> > xl: do not leak cpupool names.
> >
> > Valgrind reports:
> > ==3076== 7 bytes in 1 blocks are definitely lost in loss record 1 of 1
> > ==3076==    at 0x402458C: malloc (vg_replace_malloc.c:270)
> > ==3076==    by 0x406F86D: libxl_cpupoolid_to_name (libxl_utils.c:102)
> > ==3076==    by 0x8058742: parse_config_data (xl_cmdimpl.c:639)
> > ==3076==    by 0x805BD56: create_domain (xl_cmdimpl.c:1838)
> > ==3076==    by 0x805DAED: main_create (xl_cmdimpl.c:3903)
> > ==3076==    by 0x804D39D: main (xl.c:285)
> >
> > And indeed there are several places where xl uses
> > libxl_cpupoolid_to_name as a boolean to test if the pool name is
> > valid and leaks the name if it is. Introduce an is_valid helper and
> > use that instead.
> >
> > Signed-off-by: Ian Campbell<ian.campbell@citrix.com>
> 
> Acked-by: Juergen Gross<juergen.gross@ts.fujitsu.com>

Applied, thanks.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 14 09:07:51 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 09:07:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TCRsE-0000Ua-8H; Fri, 14 Sep 2012 09:07:42 +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 1TCRsC-0000Sk-Sm
	for xen-devel@lists.xen.org; Fri, 14 Sep 2012 09:07:41 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1347613654!10424712!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDkyOTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30992 invoked from network); 14 Sep 2012 09:07:34 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Sep 2012 09:07:34 -0000
X-IronPort-AV: E=Sophos;i="4.80,422,1344211200"; d="scan'208";a="14540176"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Sep 2012 09:07: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.279.1;
	Fri, 14 Sep 2012 10:07:34 +0100
Message-ID: <1347613653.24226.173.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Fri, 14 Sep 2012 10:07:33 +0100
In-Reply-To: <20559.28978.688776.985508@mariner.uk.xensource.com>
References: <20559.28978.688776.985508@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Olaf Hering <olaf@aepfle.de>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v2] libxl: Fix missing dependency in api
	check rule
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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-09-11 at 18:13 +0100, Ian Jackson wrote:
> Without this, the api check cpp run might happen before the various
> autogenerated files which are #include by libxl.h are ready.
> 
> We need to remove the api-ok file from AUTOINCS to avoid a circular
> dependency.  Instead, we list it explicitly as a dependency of the
> object files.  The result is that the api check is the last thing to
> be done before make considers the preparation done and can start work
> on compiling .c files into .o's.
> 
> Reported-by: Olaf Hering <olaf@aepfle.de>
> Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>

Acked + Tested by Olaf + applied.

Thanks.

> 
> ---
> v2: Remove .api-ok from AUTOINCS instead of using $(filter-out...)
> 
>  tools/libxl/Makefile |    8 ++++----
>  1 files changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
> index a9d9ec6..0986901 100644
> --- a/tools/libxl/Makefile
> +++ b/tools/libxl/Makefile
> @@ -74,8 +74,7 @@ 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.api-ok
> +	_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 \
> @@ -102,7 +101,8 @@ testidl.c: libxl_types.idl gentest.py libxl.h $(AUTOINCS)
>  all: $(CLIENTS) libxenlight.so libxenlight.a libxlutil.so libxlutil.a \
>  	$(AUTOSRCS) $(AUTOINCS)
>  
> -$(LIBXL_OBJS) $(LIBXLU_OBJS) $(XL_OBJS) $(SAVE_HELPER_OBJS): $(AUTOINCS)
> +$(LIBXL_OBJS) $(LIBXLU_OBJS) $(XL_OBJS) $(SAVE_HELPER_OBJS): \
> +	$(AUTOINCS) libxl.api-ok
>  
>  %.c %.h:: %.y
>  	@rm -f $*.[ch]
> @@ -119,7 +119,7 @@ libxl.api-ok: check-libxl-api-rules _libxl.api-for-check
>  	$(PERL) $^
>  	touch $@
>  
> -_%.api-for-check: %.h
> +_%.api-for-check: %.h $(AUTOINCS)
>  	$(CC) $(CPPFLAGS) $(CFLAGS) $(CFLAGS_$*.o) -c -E $< $(APPEND_CFLAGS) \
>  		-DLIBXL_EXTERNAL_CALLERS_ONLY=LIBXL_EXTERNAL_CALLERS_ONLY \
>  		>$@.new



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 14 09:07:51 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 09:07:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TCRsE-0000Ua-8H; Fri, 14 Sep 2012 09:07:42 +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 1TCRsC-0000Sk-Sm
	for xen-devel@lists.xen.org; Fri, 14 Sep 2012 09:07:41 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1347613654!10424712!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDkyOTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30992 invoked from network); 14 Sep 2012 09:07:34 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Sep 2012 09:07:34 -0000
X-IronPort-AV: E=Sophos;i="4.80,422,1344211200"; d="scan'208";a="14540176"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Sep 2012 09:07: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.279.1;
	Fri, 14 Sep 2012 10:07:34 +0100
Message-ID: <1347613653.24226.173.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Fri, 14 Sep 2012 10:07:33 +0100
In-Reply-To: <20559.28978.688776.985508@mariner.uk.xensource.com>
References: <20559.28978.688776.985508@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Olaf Hering <olaf@aepfle.de>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v2] libxl: Fix missing dependency in api
	check rule
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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-09-11 at 18:13 +0100, Ian Jackson wrote:
> Without this, the api check cpp run might happen before the various
> autogenerated files which are #include by libxl.h are ready.
> 
> We need to remove the api-ok file from AUTOINCS to avoid a circular
> dependency.  Instead, we list it explicitly as a dependency of the
> object files.  The result is that the api check is the last thing to
> be done before make considers the preparation done and can start work
> on compiling .c files into .o's.
> 
> Reported-by: Olaf Hering <olaf@aepfle.de>
> Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>

Acked + Tested by Olaf + applied.

Thanks.

> 
> ---
> v2: Remove .api-ok from AUTOINCS instead of using $(filter-out...)
> 
>  tools/libxl/Makefile |    8 ++++----
>  1 files changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
> index a9d9ec6..0986901 100644
> --- a/tools/libxl/Makefile
> +++ b/tools/libxl/Makefile
> @@ -74,8 +74,7 @@ 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.api-ok
> +	_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 \
> @@ -102,7 +101,8 @@ testidl.c: libxl_types.idl gentest.py libxl.h $(AUTOINCS)
>  all: $(CLIENTS) libxenlight.so libxenlight.a libxlutil.so libxlutil.a \
>  	$(AUTOSRCS) $(AUTOINCS)
>  
> -$(LIBXL_OBJS) $(LIBXLU_OBJS) $(XL_OBJS) $(SAVE_HELPER_OBJS): $(AUTOINCS)
> +$(LIBXL_OBJS) $(LIBXLU_OBJS) $(XL_OBJS) $(SAVE_HELPER_OBJS): \
> +	$(AUTOINCS) libxl.api-ok
>  
>  %.c %.h:: %.y
>  	@rm -f $*.[ch]
> @@ -119,7 +119,7 @@ libxl.api-ok: check-libxl-api-rules _libxl.api-for-check
>  	$(PERL) $^
>  	touch $@
>  
> -_%.api-for-check: %.h
> +_%.api-for-check: %.h $(AUTOINCS)
>  	$(CC) $(CPPFLAGS) $(CFLAGS) $(CFLAGS_$*.o) -c -E $< $(APPEND_CFLAGS) \
>  		-DLIBXL_EXTERNAL_CALLERS_ONLY=LIBXL_EXTERNAL_CALLERS_ONLY \
>  		>$@.new



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 14 09:13:01 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 09:13:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TCRxC-0001Gz-9L; Fri, 14 Sep 2012 09:12:50 +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 1TCRxA-0001Gt-N4
	for xen-devel@lists.xen.org; Fri, 14 Sep 2012 09:12:48 +0000
Received: from [85.158.139.83:49863] by server-7.bemta-5.messagelabs.com id
	5C/A0-19703-F05F2505; Fri, 14 Sep 2012 09:12:47 +0000
X-Env-Sender: Christoph.Egger@amd.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1347613965!26518667!1
X-Originating-IP: [65.55.88.13]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3810 invoked from network); 14 Sep 2012 09:12:47 -0000
Received: from tx2ehsobe003.messaging.microsoft.com (HELO
	tx2outboundpool.messaging.microsoft.com) (65.55.88.13)
	by server-7.tower-182.messagelabs.com with AES128-SHA encrypted SMTP;
	14 Sep 2012 09:12:47 -0000
Received: from mail167-tx2-R.bigfish.com (10.9.14.244) by
	TX2EHSOBE004.bigfish.com (10.9.40.24) with Microsoft SMTP Server id
	14.1.225.23; Fri, 14 Sep 2012 09:12:45 +0000
Received: from mail167-tx2 (localhost [127.0.0.1])	by
	mail167-tx2-R.bigfish.com (Postfix) with ESMTP id 52C57160109;
	Fri, 14 Sep 2012 09:12:45 +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(zzbb2dI98dI1432Izz1202h1d1ah1d2ahzzz2dh668h839hd25he5bhf0ah107ah1288h12a5h12a9h12bdh1315h1155h)
Received: from mail167-tx2 (localhost.localdomain [127.0.0.1]) by mail167-tx2
	(MessageSwitch) id 134761396395014_4467;
	Fri, 14 Sep 2012 09:12:43 +0000 (UTC)
Received: from TX2EHSMHS041.bigfish.com (unknown [10.9.14.236])	by
	mail167-tx2.bigfish.com (Postfix) with ESMTP id 1287EA0069;
	Fri, 14 Sep 2012 09:12:43 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	TX2EHSMHS041.bigfish.com (10.9.99.141) with Microsoft SMTP Server id
	14.1.225.23; Fri, 14 Sep 2012 09:12:37 +0000
X-WSS-ID: 0MAC1KW-02-3W2-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 20BD9C80D4;	Fri, 14 Sep 2012 04:12:32 -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, 14 Sep 2012 04:26:28 -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, 14 Sep 2012 04:12:35 -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, 14 Sep 2012
	05:12:34 -0400
Message-ID: <5052F500.2090803@amd.com>
Date: Fri, 14 Sep 2012 11:12:32 +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: Keir Fraser <keir.xen@gmail.com>
References: <CC72390B.3E2D0%keir.xen@gmail.com>
In-Reply-To: <CC72390B.3E2D0%keir.xen@gmail.com>
X-OriginatorOrg: amd.com
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [ANNOUNCE] Switching to git for primary Xen
	repositories
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 those who want to continue using mercurial there is an hg-git
extension that allows you to clone/pull/push from/to git repositories.
hg-git 0.3.3 works with mercurial 2.3.

Christoph


On 09/09/12 13:16, Keir Fraser wrote:

> Folks,
> 
> The Xen project has used mercurial for the primary repositories for many
> years. However, with external projects (including Linux and qemu) using git,
> this has led to us using and supporting two revision-control systems. Our
> plan therefore, with the 4.2.0 release soon out of the way, is to switch to
> git for all of our primary repositories. We will plan to mirror development
> activity into the old mercurial repositories at least in the short term.
> 
> We will make a further announcement nearer to the time of the switchover.
> 
>  Regards,
>  Keir & The Xen Team



-- 
---to satisfy European Law for business letters:
Advanced Micro Devices GmbH
Einsteinring 24, 85689 Dornach b. Muenchen
Geschaeftsfuehrer: Alberto Bozzo
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 Sep 14 09:13:01 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 09:13:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TCRxC-0001Gz-9L; Fri, 14 Sep 2012 09:12:50 +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 1TCRxA-0001Gt-N4
	for xen-devel@lists.xen.org; Fri, 14 Sep 2012 09:12:48 +0000
Received: from [85.158.139.83:49863] by server-7.bemta-5.messagelabs.com id
	5C/A0-19703-F05F2505; Fri, 14 Sep 2012 09:12:47 +0000
X-Env-Sender: Christoph.Egger@amd.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1347613965!26518667!1
X-Originating-IP: [65.55.88.13]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3810 invoked from network); 14 Sep 2012 09:12:47 -0000
Received: from tx2ehsobe003.messaging.microsoft.com (HELO
	tx2outboundpool.messaging.microsoft.com) (65.55.88.13)
	by server-7.tower-182.messagelabs.com with AES128-SHA encrypted SMTP;
	14 Sep 2012 09:12:47 -0000
Received: from mail167-tx2-R.bigfish.com (10.9.14.244) by
	TX2EHSOBE004.bigfish.com (10.9.40.24) with Microsoft SMTP Server id
	14.1.225.23; Fri, 14 Sep 2012 09:12:45 +0000
Received: from mail167-tx2 (localhost [127.0.0.1])	by
	mail167-tx2-R.bigfish.com (Postfix) with ESMTP id 52C57160109;
	Fri, 14 Sep 2012 09:12:45 +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(zzbb2dI98dI1432Izz1202h1d1ah1d2ahzzz2dh668h839hd25he5bhf0ah107ah1288h12a5h12a9h12bdh1315h1155h)
Received: from mail167-tx2 (localhost.localdomain [127.0.0.1]) by mail167-tx2
	(MessageSwitch) id 134761396395014_4467;
	Fri, 14 Sep 2012 09:12:43 +0000 (UTC)
Received: from TX2EHSMHS041.bigfish.com (unknown [10.9.14.236])	by
	mail167-tx2.bigfish.com (Postfix) with ESMTP id 1287EA0069;
	Fri, 14 Sep 2012 09:12:43 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	TX2EHSMHS041.bigfish.com (10.9.99.141) with Microsoft SMTP Server id
	14.1.225.23; Fri, 14 Sep 2012 09:12:37 +0000
X-WSS-ID: 0MAC1KW-02-3W2-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 20BD9C80D4;	Fri, 14 Sep 2012 04:12:32 -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, 14 Sep 2012 04:26:28 -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, 14 Sep 2012 04:12:35 -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, 14 Sep 2012
	05:12:34 -0400
Message-ID: <5052F500.2090803@amd.com>
Date: Fri, 14 Sep 2012 11:12:32 +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: Keir Fraser <keir.xen@gmail.com>
References: <CC72390B.3E2D0%keir.xen@gmail.com>
In-Reply-To: <CC72390B.3E2D0%keir.xen@gmail.com>
X-OriginatorOrg: amd.com
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [ANNOUNCE] Switching to git for primary Xen
	repositories
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 those who want to continue using mercurial there is an hg-git
extension that allows you to clone/pull/push from/to git repositories.
hg-git 0.3.3 works with mercurial 2.3.

Christoph


On 09/09/12 13:16, Keir Fraser wrote:

> Folks,
> 
> The Xen project has used mercurial for the primary repositories for many
> years. However, with external projects (including Linux and qemu) using git,
> this has led to us using and supporting two revision-control systems. Our
> plan therefore, with the 4.2.0 release soon out of the way, is to switch to
> git for all of our primary repositories. We will plan to mirror development
> activity into the old mercurial repositories at least in the short term.
> 
> We will make a further announcement nearer to the time of the switchover.
> 
>  Regards,
>  Keir & The Xen Team



-- 
---to satisfy European Law for business letters:
Advanced Micro Devices GmbH
Einsteinring 24, 85689 Dornach b. Muenchen
Geschaeftsfuehrer: Alberto Bozzo
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 Sep 14 09:25:52 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 09: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 1TCS9c-0001R8-Js; Fri, 14 Sep 2012 09:25:40 +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 1TCS9b-0001R3-DF
	for xen-devel@lists.xen.org; Fri, 14 Sep 2012 09:25:39 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1347614733!3996168!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDkyOTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29759 invoked from network); 14 Sep 2012 09:25:33 -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;
	14 Sep 2012 09:25:33 -0000
X-IronPort-AV: E=Sophos;i="4.80,422,1344211200"; d="scan'208";a="14540637"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Sep 2012 09:25: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.279.1;
	Fri, 14 Sep 2012 10:25:32 +0100
Message-ID: <1347614731.24226.175.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Fri, 14 Sep 2012 10:25:31 +0100
In-Reply-To: <20559.18783.257111.373451@mariner.uk.xensource.com>
References: <20559.18783.257111.373451@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Jan Beulich <JBeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] libxl: Tolerate xl config files missing
	trailing newline
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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-09-11 at 15:23 +0100, Ian Jackson wrote:
> I wrote:
> > Also I wrote:
> > > However, xl fails on config files which are missing the final
> > > newline.  This should be fixed for 4.2.
> > 
> > My patch for this didn't make it into 4.2 RC4.
> 
> Should this go into 4.2.0 or be held for 4.2.1 (or is it not 4.2.x
> material at all) ?
> 
> Ian.
> 
> From: Ian Jackson <ian.jackson@eu.citrix.com>
> Subject: [PATCH] libxl: Tolerate xl config files missing trailing newline
> 
> Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>

Acked + applied, thanks.

Time to start building a test suite for these files?

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 14 09:25:52 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 09: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 1TCS9c-0001R8-Js; Fri, 14 Sep 2012 09:25:40 +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 1TCS9b-0001R3-DF
	for xen-devel@lists.xen.org; Fri, 14 Sep 2012 09:25:39 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1347614733!3996168!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDkyOTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29759 invoked from network); 14 Sep 2012 09:25:33 -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;
	14 Sep 2012 09:25:33 -0000
X-IronPort-AV: E=Sophos;i="4.80,422,1344211200"; d="scan'208";a="14540637"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Sep 2012 09:25: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.279.1;
	Fri, 14 Sep 2012 10:25:32 +0100
Message-ID: <1347614731.24226.175.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Fri, 14 Sep 2012 10:25:31 +0100
In-Reply-To: <20559.18783.257111.373451@mariner.uk.xensource.com>
References: <20559.18783.257111.373451@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Jan Beulich <JBeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] libxl: Tolerate xl config files missing
	trailing newline
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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-09-11 at 15:23 +0100, Ian Jackson wrote:
> I wrote:
> > Also I wrote:
> > > However, xl fails on config files which are missing the final
> > > newline.  This should be fixed for 4.2.
> > 
> > My patch for this didn't make it into 4.2 RC4.
> 
> Should this go into 4.2.0 or be held for 4.2.1 (or is it not 4.2.x
> material at all) ?
> 
> Ian.
> 
> From: Ian Jackson <ian.jackson@eu.citrix.com>
> Subject: [PATCH] libxl: Tolerate xl config files missing trailing newline
> 
> Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>

Acked + applied, thanks.

Time to start building a test suite for these files?

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 14 09:54:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 09: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 1TCSb7-0001iM-Am; Fri, 14 Sep 2012 09:54: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 1TCSb5-0001iH-B9
	for xen-devel@lists.xen.org; Fri, 14 Sep 2012 09:54:03 +0000
Received: from [85.158.139.83:46383] by server-8.bemta-5.messagelabs.com id
	D9/FB-15219-ABEF2505; Fri, 14 Sep 2012 09:54:02 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1347616441!27633330!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22454 invoked from network); 14 Sep 2012 09:54:02 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-2.tower-182.messagelabs.com with SMTP;
	14 Sep 2012 09:54:02 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 14 Sep 2012 10:54:01 +0100
Message-Id: <50531B10020000780009B526@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 14 Sep 2012 10:54:56 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Jean Guyader" <jean.guyader@citrix.com>
References: <1347559772-21817-1-git-send-email-jean.guyader@citrix.com>
	<1347559772-21817-5-git-send-email-jean.guyader@citrix.com>
In-Reply-To: <1347559772-21817-5-git-send-email-jean.guyader@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: tim@xen.org, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 4/4] 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 13.09.12 at 20:09, Jean Guyader <jean.guyader@citrix.com> wrote:
>+typedef struct v4v_iov
>+{
>+    uint64_t iov_base;
>+    uint32_t iov_len;
>+} v4v_iov_t;

Lost padding here?

>+struct v4v_ring
>+{
>+    uint64_t magic;
>+    v4v_ring_id_t id;
>+    uint32_t len;
>+    uint32_t rx_ptr;
>+    uint32_t tx_ptr;
>+    uint8_t reserved[32];
>+    uint8_t ring[0];
>+};

Zero-sized arrays are not standard C (not even C11 iirc), this is
purely a GNU extension. This appears again elsewhere in this file.

>+typedef struct v4v_ring_data_ent
>+{
>+    v4v_addr_t ring;
>+    uint16_t flags;
>+    uint16_t pad;
>+    uint32_t space_required;
>+    uint32_t max_message_size;
>+} v4v_ring_data_ent_t;

For me, this sums up to 20 bytes.

>+typedef struct v4v_ring_data
>+{
>+    uint64_t magic;
>+    uint32_t nent;
>+    uint32_t pad;
>+    uint64_t reserved[4];
>+    v4v_ring_data_ent_t data[0];
>+} v4v_ring_data_t;

Consequently, sizeof(v4v_ring_data_t) will differ for 32- and
64-bit x86 guests. I can't tell whether that would matter
though (due to the intended, but again wrongly done,
trailing variable size array).

>+ * V4VOP_register_ring

This conflicts with ...

>+ *
>+ * 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,

... this.

>+ *           v4v_ring, XEN_GUEST_HANDLE(xen_pfn_t),

Missing indirection here? I doubt you want a structure passed
by value... (Again reoccurs further down.)

>+ * V4VOP_unregister_ring

Again conflicting with ...

>+ *
>+ * Unregister a ring.
>+ *
>+ * do_v4v_op(V4VOP_send, v4v_ring, NULL, 0, 0)

... this.

>+ * do_v4v_op(V4VOP_send,
>+ *           v4v_send_addr_t addr,
>+ *           void* buf,

XEN_GUEST_HANDLE(void) or, given this is a send, probably rather
XEN_GUEST_HANDLE(const_void). But then again this would
conflict with the real do_v4v_op() declaration.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 14 09:54:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 09: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 1TCSb7-0001iM-Am; Fri, 14 Sep 2012 09:54: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 1TCSb5-0001iH-B9
	for xen-devel@lists.xen.org; Fri, 14 Sep 2012 09:54:03 +0000
Received: from [85.158.139.83:46383] by server-8.bemta-5.messagelabs.com id
	D9/FB-15219-ABEF2505; Fri, 14 Sep 2012 09:54:02 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1347616441!27633330!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22454 invoked from network); 14 Sep 2012 09:54:02 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-2.tower-182.messagelabs.com with SMTP;
	14 Sep 2012 09:54:02 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 14 Sep 2012 10:54:01 +0100
Message-Id: <50531B10020000780009B526@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 14 Sep 2012 10:54:56 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Jean Guyader" <jean.guyader@citrix.com>
References: <1347559772-21817-1-git-send-email-jean.guyader@citrix.com>
	<1347559772-21817-5-git-send-email-jean.guyader@citrix.com>
In-Reply-To: <1347559772-21817-5-git-send-email-jean.guyader@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: tim@xen.org, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 4/4] 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 13.09.12 at 20:09, Jean Guyader <jean.guyader@citrix.com> wrote:
>+typedef struct v4v_iov
>+{
>+    uint64_t iov_base;
>+    uint32_t iov_len;
>+} v4v_iov_t;

Lost padding here?

>+struct v4v_ring
>+{
>+    uint64_t magic;
>+    v4v_ring_id_t id;
>+    uint32_t len;
>+    uint32_t rx_ptr;
>+    uint32_t tx_ptr;
>+    uint8_t reserved[32];
>+    uint8_t ring[0];
>+};

Zero-sized arrays are not standard C (not even C11 iirc), this is
purely a GNU extension. This appears again elsewhere in this file.

>+typedef struct v4v_ring_data_ent
>+{
>+    v4v_addr_t ring;
>+    uint16_t flags;
>+    uint16_t pad;
>+    uint32_t space_required;
>+    uint32_t max_message_size;
>+} v4v_ring_data_ent_t;

For me, this sums up to 20 bytes.

>+typedef struct v4v_ring_data
>+{
>+    uint64_t magic;
>+    uint32_t nent;
>+    uint32_t pad;
>+    uint64_t reserved[4];
>+    v4v_ring_data_ent_t data[0];
>+} v4v_ring_data_t;

Consequently, sizeof(v4v_ring_data_t) will differ for 32- and
64-bit x86 guests. I can't tell whether that would matter
though (due to the intended, but again wrongly done,
trailing variable size array).

>+ * V4VOP_register_ring

This conflicts with ...

>+ *
>+ * 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,

... this.

>+ *           v4v_ring, XEN_GUEST_HANDLE(xen_pfn_t),

Missing indirection here? I doubt you want a structure passed
by value... (Again reoccurs further down.)

>+ * V4VOP_unregister_ring

Again conflicting with ...

>+ *
>+ * Unregister a ring.
>+ *
>+ * do_v4v_op(V4VOP_send, v4v_ring, NULL, 0, 0)

... this.

>+ * do_v4v_op(V4VOP_send,
>+ *           v4v_send_addr_t addr,
>+ *           void* buf,

XEN_GUEST_HANDLE(void) or, given this is a send, probably rather
XEN_GUEST_HANDLE(const_void). But then again this would
conflict with the real do_v4v_op() declaration.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 14 10:00:55 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 10: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 1TCShW-0001vp-6Z; Fri, 14 Sep 2012 10:00: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 1TCShU-0001vj-Lk
	for xen-devel@lists.xen.org; Fri, 14 Sep 2012 10:00:40 +0000
Received: from [85.158.143.99:60978] by server-1.bemta-4.messagelabs.com id
	99/2F-12504-84003505; Fri, 14 Sep 2012 10:00:40 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1347616837!20554462!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNzQ1Njg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27269 invoked from network); 14 Sep 2012 10:00:39 -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;
	14 Sep 2012 10:00:39 -0000
X-IronPort-AV: E=Sophos;i="4.80,422,1344211200"; d="scan'208";a="208096466"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Sep 2012 10:00:37 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Fri, 14 Sep 2012 06:00:36 -0400
Received: from cosworth.uk.xensource.com ([10.80.16.52] ident=ianc)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1TCShQ-0004jB-G9;
	Fri, 14 Sep 2012 11:00:36 +0100
MIME-Version: 1.0
X-Mercurial-Node: 640a0b0b44e67c8434735c5129400b3a56a43683
Message-ID: <640a0b0b44e67c843473.1347616836@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Fri, 14 Sep 2012 11:00:36 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Cc: Jan Beulich <JBeulich@suse.com>
Subject: [Xen-devel] [PATCH] tools: drop ia64 only foreign structs from
	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

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1347616748 -3600
# Node ID 640a0b0b44e67c8434735c5129400b3a56a43683
# Parent  aabf685cd613b11e9b9709ae2a43f23f56d4d7ff
tools: drop ia64 only foreign structs from headers

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r aabf685cd613 -r 640a0b0b44e6 tools/include/xen-foreign/reference.size
--- a/tools/include/xen-foreign/reference.size	Fri Sep 14 10:39:09 2012 +0100
+++ b/tools/include/xen-foreign/reference.size	Fri Sep 14 10:59:08 2012 +0100
@@ -3,12 +3,7 @@ structs                   |  x86_32  x86
 
 start_info                |    1112    1168
 trap_info                 |       8      16
-pt_fpreg                  |       -       -
 cpu_user_regs             |      68     200
-xen_ia64_boot_param       |       -       -
-ia64_tr_entry             |       -       -
-vcpu_tr_regs              |       -       -
-vcpu_guest_context_regs   |       -       -
 vcpu_guest_context        |    2800    5168
 arch_vcpu_info            |      24      16
 vcpu_time_info            |      32      32
diff -r aabf685cd613 -r 640a0b0b44e6 tools/include/xen-foreign/structs.py
--- a/tools/include/xen-foreign/structs.py	Fri Sep 14 10:39:09 2012 +0100
+++ b/tools/include/xen-foreign/structs.py	Fri Sep 14 10:59:08 2012 +0100
@@ -5,12 +5,7 @@ unions  = [ "vcpu_cr_regs",
 
 structs = [ "start_info",
             "trap_info",
-            "pt_fpreg",
             "cpu_user_regs",
-            "xen_ia64_boot_param",
-            "ia64_tr_entry",
-            "vcpu_tr_regs",
-            "vcpu_guest_context_regs",
             "vcpu_guest_context",
             "arch_vcpu_info",
             "vcpu_time_info",
@@ -48,9 +43,6 @@ defines = [ "__i386__",
             "_VGCF_online",
             "VGCF_online",
 
-            # ia64
-            "VGCF_EXTRA_REGS",
-
             # all archs
             "xen_pfn_to_cr3",
             "xen_cr3_to_pfn",

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 14 10:00:55 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 10: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 1TCShW-0001vp-6Z; Fri, 14 Sep 2012 10:00: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 1TCShU-0001vj-Lk
	for xen-devel@lists.xen.org; Fri, 14 Sep 2012 10:00:40 +0000
Received: from [85.158.143.99:60978] by server-1.bemta-4.messagelabs.com id
	99/2F-12504-84003505; Fri, 14 Sep 2012 10:00:40 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1347616837!20554462!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNzQ1Njg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27269 invoked from network); 14 Sep 2012 10:00:39 -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;
	14 Sep 2012 10:00:39 -0000
X-IronPort-AV: E=Sophos;i="4.80,422,1344211200"; d="scan'208";a="208096466"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Sep 2012 10:00:37 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Fri, 14 Sep 2012 06:00:36 -0400
Received: from cosworth.uk.xensource.com ([10.80.16.52] ident=ianc)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<ian.campbell@citrix.com>)	id 1TCShQ-0004jB-G9;
	Fri, 14 Sep 2012 11:00:36 +0100
MIME-Version: 1.0
X-Mercurial-Node: 640a0b0b44e67c8434735c5129400b3a56a43683
Message-ID: <640a0b0b44e67c843473.1347616836@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Fri, 14 Sep 2012 11:00:36 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Cc: Jan Beulich <JBeulich@suse.com>
Subject: [Xen-devel] [PATCH] tools: drop ia64 only foreign structs from
	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

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1347616748 -3600
# Node ID 640a0b0b44e67c8434735c5129400b3a56a43683
# Parent  aabf685cd613b11e9b9709ae2a43f23f56d4d7ff
tools: drop ia64 only foreign structs from headers

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r aabf685cd613 -r 640a0b0b44e6 tools/include/xen-foreign/reference.size
--- a/tools/include/xen-foreign/reference.size	Fri Sep 14 10:39:09 2012 +0100
+++ b/tools/include/xen-foreign/reference.size	Fri Sep 14 10:59:08 2012 +0100
@@ -3,12 +3,7 @@ structs                   |  x86_32  x86
 
 start_info                |    1112    1168
 trap_info                 |       8      16
-pt_fpreg                  |       -       -
 cpu_user_regs             |      68     200
-xen_ia64_boot_param       |       -       -
-ia64_tr_entry             |       -       -
-vcpu_tr_regs              |       -       -
-vcpu_guest_context_regs   |       -       -
 vcpu_guest_context        |    2800    5168
 arch_vcpu_info            |      24      16
 vcpu_time_info            |      32      32
diff -r aabf685cd613 -r 640a0b0b44e6 tools/include/xen-foreign/structs.py
--- a/tools/include/xen-foreign/structs.py	Fri Sep 14 10:39:09 2012 +0100
+++ b/tools/include/xen-foreign/structs.py	Fri Sep 14 10:59:08 2012 +0100
@@ -5,12 +5,7 @@ unions  = [ "vcpu_cr_regs",
 
 structs = [ "start_info",
             "trap_info",
-            "pt_fpreg",
             "cpu_user_regs",
-            "xen_ia64_boot_param",
-            "ia64_tr_entry",
-            "vcpu_tr_regs",
-            "vcpu_guest_context_regs",
             "vcpu_guest_context",
             "arch_vcpu_info",
             "vcpu_time_info",
@@ -48,9 +43,6 @@ defines = [ "__i386__",
             "_VGCF_online",
             "VGCF_online",
 
-            # ia64
-            "VGCF_EXTRA_REGS",
-
             # all archs
             "xen_pfn_to_cr3",
             "xen_cr3_to_pfn",

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 14 10:01:17 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 10:01: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 1TCSho-0001xZ-Ju; Fri, 14 Sep 2012 10:01: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 1TCShm-0001xF-R0
	for xen-devel@lists.xen.org; Fri, 14 Sep 2012 10:00:59 +0000
Received: from [85.158.138.51:51995] by server-10.bemta-3.messagelabs.com id
	E0/99-10411-A5003505; Fri, 14 Sep 2012 10:00:58 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1347616856!21652785!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNjk2MTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23501 invoked from network); 14 Sep 2012 10:00:57 -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;
	14 Sep 2012 10:00:57 -0000
X-IronPort-AV: E=Sophos;i="4.80,422,1344211200"; d="scan'208";a="37867109"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Sep 2012 10:00:55 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Fri, 14 Sep 2012 06:00:54 -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 1TCShj-0004jH-4h;
	Fri, 14 Sep 2012 11:00:55 +0100
MIME-Version: 1.0
X-Mercurial-Node: 0547430886c507989dd9091ef5f1e2d089a50351
Message-ID: <0547430886c507989dd9.1347616854@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Fri, 14 Sep 2012 11:00:54 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH] .*ignore: drop ia64 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

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1347616840 -3600
# Node ID 0547430886c507989dd9091ef5f1e2d089a50351
# Parent  640a0b0b44e67c8434735c5129400b3a56a43683
.*ignore: drop ia64 entries

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r 640a0b0b44e6 -r 0547430886c5 .gitignore
--- a/.gitignore	Fri Sep 14 10:59:08 2012 +0100
+++ b/.gitignore	Fri Sep 14 11:00:40 2012 +0100
@@ -64,10 +64,7 @@ docs/xen-api/xenapi.dvi
 docs/xen-api/xenapi.pdf
 docs/xen-api/xenapi.ps
 docs/xen-api/xenapi.toc
-extras/mini-os/arch/ia64/gen_off.s
 extras/mini-os/include/mini-os
-extras/mini-os/include/ia64/mini-os
-extras/mini-os/include/ia64/offsets.h
 extras/mini-os/include/x86/mini-os
 extras/mini-os/include/xen
 extras/mini-os/include/list.h
@@ -174,13 +171,6 @@ tools/hotplug/common/hotplugpath.sh
 tools/include/xen/*
 tools/include/xen-foreign/*.(c|h|size)
 tools/include/xen-foreign/checker
-tools/libxc/ia64/asm/*.h
-tools/libxc/ia64/acpi/*.h
-tools/libxc/ia64/acpi/platform/*.h
-tools/libxc/ia64/dom_fw_asm.S
-tools/libxc/ia64/dom_fw_common.c
-tools/libxc/ia64/dom_fw_domu.c
-tools/libxc/ia64/xen/*.h
 tools/libxen/libxenapi-
 tools/libxen/test/test_bindings
 tools/libxen/test/test_event_handling
@@ -309,9 +299,6 @@ xen/ddb/*
 xen/include/headers.chk
 xen/include/asm
 xen/include/asm-*/asm-offsets.h
-xen/include/asm-ia64/asm-xsi-offsets.h
-xen/include/asm-ia64/.offsets.h.stamp
-xen/include/asm-ia64/xen
 xen/include/compat/*
 xen/include/hypervisor-ifs/arch
 xen/include/linux
@@ -325,10 +312,6 @@ xen/tools/symbols
 xen/xen
 xen/xen-syms
 xen/xen.*
-xen/arch/ia64/asm-offsets.s
-xen/arch/ia64/asm-xsi-offsets.s
-xen/arch/ia64/map.out
-xen/arch/ia64/xen.lds.s
 unmodified_drivers/linux-2.6/.tmp_versions
 unmodified_drivers/linux-2.6/*.cmd
 unmodified_drivers/linux-2.6/*.ko
@@ -348,7 +331,6 @@ tools/firmware/rombios/_rombios_.c
 tools/firmware/rombios/rombios.s
 tools/firmware/rombios/rombios.sym
 tools/include/xen-foreign/checker.c
-tools/include/xen-foreign/ia64.h
 tools/include/xen-foreign/structs.pyc
 tools/include/xen-foreign/x86_32.h
 tools/include/xen-foreign/x86_64.h
diff -r 640a0b0b44e6 -r 0547430886c5 .hgignore
--- a/.hgignore	Fri Sep 14 10:59:08 2012 +0100
+++ b/.hgignore	Fri Sep 14 11:00:40 2012 +0100
@@ -64,11 +64,8 @@
 ^docs/xen-api/vm_lifecycle.eps$
 ^docs/xen-api/xenapi-datamodel-graph.eps$
 ^docs/xen-api/xenapi.out$
-^extras/mini-os/arch/ia64/gen_off.s$
 ^extras/mini-os/include/list\.h$
 ^extras/mini-os/include/mini-os$
-^extras/mini-os/include/ia64/mini-os$
-^extras/mini-os/include/ia64/offsets.h$
 ^extras/mini-os/include/x86/mini-os$
 ^extras/mini-os/include/xen$
 ^extras/mini-os/mini-os.*$
@@ -168,13 +165,6 @@
 ^tools/include/xen/.*$
 ^tools/include/xen-foreign/.*\.(c|h|size)$
 ^tools/include/xen-foreign/checker$
-^tools/libxc/ia64/asm/.*\.h$
-^tools/libxc/ia64/acpi/.*\.h$
-^tools/libxc/ia64/acpi/platform/.*\.h$
-^tools/libxc/ia64/dom_fw_asm.S$
-^tools/libxc/ia64/dom_fw_common\.c$
-^tools/libxc/ia64/dom_fw_domu\.c$
-^tools/libxc/ia64/xen/.*\.h$
 ^tools/libxen/libxenapi-
 ^tools/libxen/test/test_bindings$
 ^tools/libxen/test/test_event_handling$
@@ -338,9 +328,6 @@
 ^xen/include/headers\.chk$
 ^xen/include/asm$
 ^xen/include/asm-.*/asm-offsets\.h$
-^xen/include/asm-ia64/asm-xsi-offsets\.h$
-^xen/include/asm-ia64/.offsets.h.stamp$
-^xen/include/asm-ia64/xen$
 ^xen/include/compat/.*$
 ^xen/include/hypervisor-ifs/arch$
 ^xen/include/linux$
@@ -354,10 +341,6 @@
 ^xen/xen$
 ^xen/xen-syms$
 ^xen/xen\..*$
-^xen/arch/ia64/asm-offsets\.s$
-^xen/arch/ia64/asm-xsi-offsets\.s$
-^xen/arch/ia64/map\.out$
-^xen/arch/ia64/xen\.lds\.s$
 ^unmodified_drivers/linux-2.6/\.tmp_versions
 ^unmodified_drivers/linux-2.6/.*\.cmd$
 ^unmodified_drivers/linux-2.6/.*\.ko$

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 14 10:01:17 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 10:01: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 1TCSho-0001xZ-Ju; Fri, 14 Sep 2012 10:01: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 1TCShm-0001xF-R0
	for xen-devel@lists.xen.org; Fri, 14 Sep 2012 10:00:59 +0000
Received: from [85.158.138.51:51995] by server-10.bemta-3.messagelabs.com id
	E0/99-10411-A5003505; Fri, 14 Sep 2012 10:00:58 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1347616856!21652785!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNjk2MTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23501 invoked from network); 14 Sep 2012 10:00:57 -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;
	14 Sep 2012 10:00:57 -0000
X-IronPort-AV: E=Sophos;i="4.80,422,1344211200"; d="scan'208";a="37867109"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Sep 2012 10:00:55 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Fri, 14 Sep 2012 06:00:54 -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 1TCShj-0004jH-4h;
	Fri, 14 Sep 2012 11:00:55 +0100
MIME-Version: 1.0
X-Mercurial-Node: 0547430886c507989dd9091ef5f1e2d089a50351
Message-ID: <0547430886c507989dd9.1347616854@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Fri, 14 Sep 2012 11:00:54 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH] .*ignore: drop ia64 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

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1347616840 -3600
# Node ID 0547430886c507989dd9091ef5f1e2d089a50351
# Parent  640a0b0b44e67c8434735c5129400b3a56a43683
.*ignore: drop ia64 entries

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r 640a0b0b44e6 -r 0547430886c5 .gitignore
--- a/.gitignore	Fri Sep 14 10:59:08 2012 +0100
+++ b/.gitignore	Fri Sep 14 11:00:40 2012 +0100
@@ -64,10 +64,7 @@ docs/xen-api/xenapi.dvi
 docs/xen-api/xenapi.pdf
 docs/xen-api/xenapi.ps
 docs/xen-api/xenapi.toc
-extras/mini-os/arch/ia64/gen_off.s
 extras/mini-os/include/mini-os
-extras/mini-os/include/ia64/mini-os
-extras/mini-os/include/ia64/offsets.h
 extras/mini-os/include/x86/mini-os
 extras/mini-os/include/xen
 extras/mini-os/include/list.h
@@ -174,13 +171,6 @@ tools/hotplug/common/hotplugpath.sh
 tools/include/xen/*
 tools/include/xen-foreign/*.(c|h|size)
 tools/include/xen-foreign/checker
-tools/libxc/ia64/asm/*.h
-tools/libxc/ia64/acpi/*.h
-tools/libxc/ia64/acpi/platform/*.h
-tools/libxc/ia64/dom_fw_asm.S
-tools/libxc/ia64/dom_fw_common.c
-tools/libxc/ia64/dom_fw_domu.c
-tools/libxc/ia64/xen/*.h
 tools/libxen/libxenapi-
 tools/libxen/test/test_bindings
 tools/libxen/test/test_event_handling
@@ -309,9 +299,6 @@ xen/ddb/*
 xen/include/headers.chk
 xen/include/asm
 xen/include/asm-*/asm-offsets.h
-xen/include/asm-ia64/asm-xsi-offsets.h
-xen/include/asm-ia64/.offsets.h.stamp
-xen/include/asm-ia64/xen
 xen/include/compat/*
 xen/include/hypervisor-ifs/arch
 xen/include/linux
@@ -325,10 +312,6 @@ xen/tools/symbols
 xen/xen
 xen/xen-syms
 xen/xen.*
-xen/arch/ia64/asm-offsets.s
-xen/arch/ia64/asm-xsi-offsets.s
-xen/arch/ia64/map.out
-xen/arch/ia64/xen.lds.s
 unmodified_drivers/linux-2.6/.tmp_versions
 unmodified_drivers/linux-2.6/*.cmd
 unmodified_drivers/linux-2.6/*.ko
@@ -348,7 +331,6 @@ tools/firmware/rombios/_rombios_.c
 tools/firmware/rombios/rombios.s
 tools/firmware/rombios/rombios.sym
 tools/include/xen-foreign/checker.c
-tools/include/xen-foreign/ia64.h
 tools/include/xen-foreign/structs.pyc
 tools/include/xen-foreign/x86_32.h
 tools/include/xen-foreign/x86_64.h
diff -r 640a0b0b44e6 -r 0547430886c5 .hgignore
--- a/.hgignore	Fri Sep 14 10:59:08 2012 +0100
+++ b/.hgignore	Fri Sep 14 11:00:40 2012 +0100
@@ -64,11 +64,8 @@
 ^docs/xen-api/vm_lifecycle.eps$
 ^docs/xen-api/xenapi-datamodel-graph.eps$
 ^docs/xen-api/xenapi.out$
-^extras/mini-os/arch/ia64/gen_off.s$
 ^extras/mini-os/include/list\.h$
 ^extras/mini-os/include/mini-os$
-^extras/mini-os/include/ia64/mini-os$
-^extras/mini-os/include/ia64/offsets.h$
 ^extras/mini-os/include/x86/mini-os$
 ^extras/mini-os/include/xen$
 ^extras/mini-os/mini-os.*$
@@ -168,13 +165,6 @@
 ^tools/include/xen/.*$
 ^tools/include/xen-foreign/.*\.(c|h|size)$
 ^tools/include/xen-foreign/checker$
-^tools/libxc/ia64/asm/.*\.h$
-^tools/libxc/ia64/acpi/.*\.h$
-^tools/libxc/ia64/acpi/platform/.*\.h$
-^tools/libxc/ia64/dom_fw_asm.S$
-^tools/libxc/ia64/dom_fw_common\.c$
-^tools/libxc/ia64/dom_fw_domu\.c$
-^tools/libxc/ia64/xen/.*\.h$
 ^tools/libxen/libxenapi-
 ^tools/libxen/test/test_bindings$
 ^tools/libxen/test/test_event_handling$
@@ -338,9 +328,6 @@
 ^xen/include/headers\.chk$
 ^xen/include/asm$
 ^xen/include/asm-.*/asm-offsets\.h$
-^xen/include/asm-ia64/asm-xsi-offsets\.h$
-^xen/include/asm-ia64/.offsets.h.stamp$
-^xen/include/asm-ia64/xen$
 ^xen/include/compat/.*$
 ^xen/include/hypervisor-ifs/arch$
 ^xen/include/linux$
@@ -354,10 +341,6 @@
 ^xen/xen$
 ^xen/xen-syms$
 ^xen/xen\..*$
-^xen/arch/ia64/asm-offsets\.s$
-^xen/arch/ia64/asm-xsi-offsets\.s$
-^xen/arch/ia64/map\.out$
-^xen/arch/ia64/xen\.lds\.s$
 ^unmodified_drivers/linux-2.6/\.tmp_versions
 ^unmodified_drivers/linux-2.6/.*\.cmd$
 ^unmodified_drivers/linux-2.6/.*\.ko$

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 14 10:05:07 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 10: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 1TCSla-0002Cq-8x; Fri, 14 Sep 2012 10:04:54 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1TCSlY-0002Ci-C0
	for xen-devel@lists.xen.org; Fri, 14 Sep 2012 10:04:52 +0000
Received: from [85.158.138.51:28686] by server-11.bemta-3.messagelabs.com id
	2D/14-30250-34103505; Fri, 14 Sep 2012 10:04:51 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1347617090!22493777!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19023 invoked from network); 14 Sep 2012 10:04:51 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-6.tower-174.messagelabs.com with SMTP;
	14 Sep 2012 10:04:51 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 14 Sep 2012 11:04:50 +0100
Message-Id: <50531D98020000780009B54D@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 14 Sep 2012 11:05:44 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Campbell" <ian.campbell@citrix.com>
References: <640a0b0b44e67c843473.1347616836@cosworth.uk.xensource.com>
In-Reply-To: <640a0b0b44e67c843473.1347616836@cosworth.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] tools: drop ia64 only foreign structs from
	headers
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 14.09.12 at 12:00, Ian Campbell <ian.campbell@citrix.com> wrote:
> # HG changeset patch
> # User Ian Campbell <ian.campbell@citrix.com>
> # Date 1347616748 -3600
> # Node ID 640a0b0b44e67c8434735c5129400b3a56a43683
> # Parent  aabf685cd613b11e9b9709ae2a43f23f56d4d7ff
> tools: drop ia64 only foreign structs from headers

Not sure why they got put there in the first place.

> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

Acked-by: Jan Beulich <jbeulich@suse.com>

> diff -r aabf685cd613 -r 640a0b0b44e6 tools/include/xen-foreign/reference.size
> --- a/tools/include/xen-foreign/reference.size	Fri Sep 14 10:39:09 2012 +0100
> +++ b/tools/include/xen-foreign/reference.size	Fri Sep 14 10:59:08 2012 +0100
> @@ -3,12 +3,7 @@ structs                   |  x86_32  x86
>  
>  start_info                |    1112    1168
>  trap_info                 |       8      16
> -pt_fpreg                  |       -       -
>  cpu_user_regs             |      68     200
> -xen_ia64_boot_param       |       -       -
> -ia64_tr_entry             |       -       -
> -vcpu_tr_regs              |       -       -
> -vcpu_guest_context_regs   |       -       -
>  vcpu_guest_context        |    2800    5168
>  arch_vcpu_info            |      24      16
>  vcpu_time_info            |      32      32
> diff -r aabf685cd613 -r 640a0b0b44e6 tools/include/xen-foreign/structs.py
> --- a/tools/include/xen-foreign/structs.py	Fri Sep 14 10:39:09 2012 +0100
> +++ b/tools/include/xen-foreign/structs.py	Fri Sep 14 10:59:08 2012 +0100
> @@ -5,12 +5,7 @@ unions  = [ "vcpu_cr_regs",
>  
>  structs = [ "start_info",
>              "trap_info",
> -            "pt_fpreg",
>              "cpu_user_regs",
> -            "xen_ia64_boot_param",
> -            "ia64_tr_entry",
> -            "vcpu_tr_regs",
> -            "vcpu_guest_context_regs",
>              "vcpu_guest_context",
>              "arch_vcpu_info",
>              "vcpu_time_info",
> @@ -48,9 +43,6 @@ defines = [ "__i386__",
>              "_VGCF_online",
>              "VGCF_online",
>  
> -            # ia64
> -            "VGCF_EXTRA_REGS",
> -
>              # all archs
>              "xen_pfn_to_cr3",
>              "xen_cr3_to_pfn",




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 14 10:05:07 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 10: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 1TCSla-0002Cq-8x; Fri, 14 Sep 2012 10:04:54 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1TCSlY-0002Ci-C0
	for xen-devel@lists.xen.org; Fri, 14 Sep 2012 10:04:52 +0000
Received: from [85.158.138.51:28686] by server-11.bemta-3.messagelabs.com id
	2D/14-30250-34103505; Fri, 14 Sep 2012 10:04:51 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1347617090!22493777!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19023 invoked from network); 14 Sep 2012 10:04:51 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-6.tower-174.messagelabs.com with SMTP;
	14 Sep 2012 10:04:51 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 14 Sep 2012 11:04:50 +0100
Message-Id: <50531D98020000780009B54D@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 14 Sep 2012 11:05:44 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Campbell" <ian.campbell@citrix.com>
References: <640a0b0b44e67c843473.1347616836@cosworth.uk.xensource.com>
In-Reply-To: <640a0b0b44e67c843473.1347616836@cosworth.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] tools: drop ia64 only foreign structs from
	headers
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 14.09.12 at 12:00, Ian Campbell <ian.campbell@citrix.com> wrote:
> # HG changeset patch
> # User Ian Campbell <ian.campbell@citrix.com>
> # Date 1347616748 -3600
> # Node ID 640a0b0b44e67c8434735c5129400b3a56a43683
> # Parent  aabf685cd613b11e9b9709ae2a43f23f56d4d7ff
> tools: drop ia64 only foreign structs from headers

Not sure why they got put there in the first place.

> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

Acked-by: Jan Beulich <jbeulich@suse.com>

> diff -r aabf685cd613 -r 640a0b0b44e6 tools/include/xen-foreign/reference.size
> --- a/tools/include/xen-foreign/reference.size	Fri Sep 14 10:39:09 2012 +0100
> +++ b/tools/include/xen-foreign/reference.size	Fri Sep 14 10:59:08 2012 +0100
> @@ -3,12 +3,7 @@ structs                   |  x86_32  x86
>  
>  start_info                |    1112    1168
>  trap_info                 |       8      16
> -pt_fpreg                  |       -       -
>  cpu_user_regs             |      68     200
> -xen_ia64_boot_param       |       -       -
> -ia64_tr_entry             |       -       -
> -vcpu_tr_regs              |       -       -
> -vcpu_guest_context_regs   |       -       -
>  vcpu_guest_context        |    2800    5168
>  arch_vcpu_info            |      24      16
>  vcpu_time_info            |      32      32
> diff -r aabf685cd613 -r 640a0b0b44e6 tools/include/xen-foreign/structs.py
> --- a/tools/include/xen-foreign/structs.py	Fri Sep 14 10:39:09 2012 +0100
> +++ b/tools/include/xen-foreign/structs.py	Fri Sep 14 10:59:08 2012 +0100
> @@ -5,12 +5,7 @@ unions  = [ "vcpu_cr_regs",
>  
>  structs = [ "start_info",
>              "trap_info",
> -            "pt_fpreg",
>              "cpu_user_regs",
> -            "xen_ia64_boot_param",
> -            "ia64_tr_entry",
> -            "vcpu_tr_regs",
> -            "vcpu_guest_context_regs",
>              "vcpu_guest_context",
>              "arch_vcpu_info",
>              "vcpu_time_info",
> @@ -48,9 +43,6 @@ defines = [ "__i386__",
>              "_VGCF_online",
>              "VGCF_online",
>  
> -            # ia64
> -            "VGCF_EXTRA_REGS",
> -
>              # all archs
>              "xen_pfn_to_cr3",
>              "xen_cr3_to_pfn",




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 14 10:08:44 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 10:08:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TCSox-0002N5-S7; Fri, 14 Sep 2012 10:08:23 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1TCSow-0002Mv-Kz
	for xen-devel@lists.xensource.com; Fri, 14 Sep 2012 10:08:22 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1347617278!10976981!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDkyOTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30502 invoked from network); 14 Sep 2012 10:07:58 -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;
	14 Sep 2012 10:07:58 -0000
X-IronPort-AV: E=Sophos;i="4.80,422,1344211200"; d="scan'208";a="14541772"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Sep 2012 10:07:53 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Fri, 14 Sep 2012 11:07:53 +0100
Date: Fri, 14 Sep 2012 11:07:20 +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: <1347609931.24226.149.camel@zakaz.uk.xensource.com>
Message-ID: <alpine.DEB.2.02.1209141057280.29232@kaball.uk.xensource.com>
References: <f32959a0c14799617f7f.1346862971@makatos-desktop>
	<20562.6285.724880.885473@mariner.uk.xensource.com>
	<alpine.DEB.2.02.1209131857520.29232@kaball.uk.xensource.com>
	<1347609931.24226.149.camel@zakaz.uk.xensource.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: Thanos Makatos <thanos.makatos@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] [PATCH] use spaces instead of tabs in vim
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 14 Sep 2012, Ian Campbell wrote:
> On Thu, 2012-09-13 at 18:58 +0100, Stefano Stabellini wrote:
> > On Thu, 13 Sep 2012, Ian Jackson wrote:
> > > Thanos Makatos writes ("[Xen-devel] [PATCH] use spaces instead of tabs in vim"):
> > > > Tell vim to use spaces instead of tabs for all files residing under
> > > > xen-unstable.hg. Must open files from the top-level directory, otherwise it
> > > > doesn't work.
> > > 
> > > This is fine by me and looks plausible but I'd like to see a second
> > > opinion from someone who uses vim.
> > > 
> > 
> > Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> 
> http://vim.wikia.com/wiki/Modeline_magic suggests you can do it on a
> per-file basis. Given the number of different coding styles throughout
> the tree wouldn't that be a better option?

I agree that would be a better option.


> This set of options is wrong
> e.g. for tools/libxl and anything imported from Linux.

That's right, it would be wrong for Linux, but I think it is correct for
libxl and QEMU (both use 4 whitespaces for indentation), so in practice it
should be correct for anything under xen-unstable except Makefiles and
stuff imported as-is from Linux (xen/arch/arm/lib/* for example). Better
than nothing :)


> It's be a bigger initial patch but once it is done it's done.
> 
> People typically copy the magic block from an existing file so as long
> as you put the vim one next to the emacs one it should get propagated as
> necessary to new files.
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 14 10:08:44 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 10:08:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TCSox-0002N5-S7; Fri, 14 Sep 2012 10:08:23 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1TCSow-0002Mv-Kz
	for xen-devel@lists.xensource.com; Fri, 14 Sep 2012 10:08:22 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1347617278!10976981!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDkyOTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30502 invoked from network); 14 Sep 2012 10:07:58 -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;
	14 Sep 2012 10:07:58 -0000
X-IronPort-AV: E=Sophos;i="4.80,422,1344211200"; d="scan'208";a="14541772"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Sep 2012 10:07:53 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Fri, 14 Sep 2012 11:07:53 +0100
Date: Fri, 14 Sep 2012 11:07:20 +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: <1347609931.24226.149.camel@zakaz.uk.xensource.com>
Message-ID: <alpine.DEB.2.02.1209141057280.29232@kaball.uk.xensource.com>
References: <f32959a0c14799617f7f.1346862971@makatos-desktop>
	<20562.6285.724880.885473@mariner.uk.xensource.com>
	<alpine.DEB.2.02.1209131857520.29232@kaball.uk.xensource.com>
	<1347609931.24226.149.camel@zakaz.uk.xensource.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: Thanos Makatos <thanos.makatos@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] [PATCH] use spaces instead of tabs in vim
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 14 Sep 2012, Ian Campbell wrote:
> On Thu, 2012-09-13 at 18:58 +0100, Stefano Stabellini wrote:
> > On Thu, 13 Sep 2012, Ian Jackson wrote:
> > > Thanos Makatos writes ("[Xen-devel] [PATCH] use spaces instead of tabs in vim"):
> > > > Tell vim to use spaces instead of tabs for all files residing under
> > > > xen-unstable.hg. Must open files from the top-level directory, otherwise it
> > > > doesn't work.
> > > 
> > > This is fine by me and looks plausible but I'd like to see a second
> > > opinion from someone who uses vim.
> > > 
> > 
> > Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> 
> http://vim.wikia.com/wiki/Modeline_magic suggests you can do it on a
> per-file basis. Given the number of different coding styles throughout
> the tree wouldn't that be a better option?

I agree that would be a better option.


> This set of options is wrong
> e.g. for tools/libxl and anything imported from Linux.

That's right, it would be wrong for Linux, but I think it is correct for
libxl and QEMU (both use 4 whitespaces for indentation), so in practice it
should be correct for anything under xen-unstable except Makefiles and
stuff imported as-is from Linux (xen/arch/arm/lib/* for example). Better
than nothing :)


> It's be a bigger initial patch but once it is done it's done.
> 
> People typically copy the magic block from an existing file so as long
> as you put the vim one next to the emacs one it should get propagated as
> necessary to new files.
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 14 10:19:41 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 10:19:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TCSzX-0002Yj-1S; Fri, 14 Sep 2012 10:19:19 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <roger.pau@citrix.com>) id 1TCSzV-0002Ye-DW
	for xen-devel@lists.xen.org; Fri, 14 Sep 2012 10:19:17 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1347617951!1696003!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDkyOTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18449 invoked from network); 14 Sep 2012 10:19:11 -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;
	14 Sep 2012 10:19:11 -0000
X-IronPort-AV: E=Sophos;i="4.80,422,1344211200"; d="scan'208";a="14542088"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Sep 2012 10:19:11 +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.279.1; Fri, 14 Sep 2012 11:19:11 +0100
Message-ID: <505304A2.7020901@citrix.com>
Date: Fri, 14 Sep 2012 11:19:14 +0100
From: Roger Pau Monne <roger.pau@citrix.com>
User-Agent: Postbox 3.0.5 (Macintosh/20120826)
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <20120905030239.GJ8912@reaktio.net>
	<1346846602-1109-1-git-send-email-roger.pau@citrix.com>
	<1347613534.24226.167.camel@zakaz.uk.xensource.com>
In-Reply-To: <1347613534.24226.167.camel@zakaz.uk.xensource.com>
X-Enigmail-Version: 1.2.2
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] libfsimage: add ext4 support for CentOS 5.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

Ian Campbell wrote:
> On Wed, 2012-09-05 at 13:03 +0100, Roger Pau Monne wrote:
>> CentOS 5.x forked e2fs ext4 support into a different package called
>> e4fs, and so headers and library names changed from ext2fs to ext4fs.
>> Check if ext4fs/ext2fs.h and -lext4fs work, and use that instead of
>> ext2fs to build libfsimage. This patch assumes that if the ext4fs
>> library is present it should always be used instead of ext2fs.
>>
>> This patch includes a rework of the ext2fs check, a new ext4fs check
>> and a minor modification in libfsimage to use the correct library.
>>
>> Signed-off-by: Roger Pau Monne <roger.pau@citrix.com>
>> ---
>> Please re-run autogen.sh after applying
> 
> Done & acked + applied. Thanks.
> 
>> diff --git a/tools/libfsimage/ext2fs-lib/Makefile b/tools/libfsimage/ext2fs-lib/Makefile
>> index 142207f..671fbff 100644
>> --- a/tools/libfsimage/ext2fs-lib/Makefile
>> +++ b/tools/libfsimage/ext2fs-lib/Makefile
>> @@ -4,7 +4,10 @@ LIB_SRCS-y = ext2fs-lib.c
>>  
>>  FS = ext2fs-lib
>>  
>> -FS_LIBDEPS = -lext2fs
>> +FS_LIBDEPS = $(EXTFS_LIBS)
>> +
>> +# Include configure output (config.h) to headers search path
>> +CFLAGS += -I$(XEN_ROOT)/tools
> 
> Is there any way to move config.h from tools to under tools/include
> somewhere? 

Yes, but config.h should then be renamed to xen_config.h or something
different from config.h, since a lot of utilities we pack with Xen
include their own config.h and also include the tools/include folder, so
we might have a collision there.

If renaming it to xen_config.h is fine I will send a patch.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 14 10:19:41 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 10:19:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TCSzX-0002Yj-1S; Fri, 14 Sep 2012 10:19:19 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <roger.pau@citrix.com>) id 1TCSzV-0002Ye-DW
	for xen-devel@lists.xen.org; Fri, 14 Sep 2012 10:19:17 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1347617951!1696003!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDkyOTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18449 invoked from network); 14 Sep 2012 10:19:11 -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;
	14 Sep 2012 10:19:11 -0000
X-IronPort-AV: E=Sophos;i="4.80,422,1344211200"; d="scan'208";a="14542088"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Sep 2012 10:19:11 +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.279.1; Fri, 14 Sep 2012 11:19:11 +0100
Message-ID: <505304A2.7020901@citrix.com>
Date: Fri, 14 Sep 2012 11:19:14 +0100
From: Roger Pau Monne <roger.pau@citrix.com>
User-Agent: Postbox 3.0.5 (Macintosh/20120826)
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <20120905030239.GJ8912@reaktio.net>
	<1346846602-1109-1-git-send-email-roger.pau@citrix.com>
	<1347613534.24226.167.camel@zakaz.uk.xensource.com>
In-Reply-To: <1347613534.24226.167.camel@zakaz.uk.xensource.com>
X-Enigmail-Version: 1.2.2
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] libfsimage: add ext4 support for CentOS 5.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

Ian Campbell wrote:
> On Wed, 2012-09-05 at 13:03 +0100, Roger Pau Monne wrote:
>> CentOS 5.x forked e2fs ext4 support into a different package called
>> e4fs, and so headers and library names changed from ext2fs to ext4fs.
>> Check if ext4fs/ext2fs.h and -lext4fs work, and use that instead of
>> ext2fs to build libfsimage. This patch assumes that if the ext4fs
>> library is present it should always be used instead of ext2fs.
>>
>> This patch includes a rework of the ext2fs check, a new ext4fs check
>> and a minor modification in libfsimage to use the correct library.
>>
>> Signed-off-by: Roger Pau Monne <roger.pau@citrix.com>
>> ---
>> Please re-run autogen.sh after applying
> 
> Done & acked + applied. Thanks.
> 
>> diff --git a/tools/libfsimage/ext2fs-lib/Makefile b/tools/libfsimage/ext2fs-lib/Makefile
>> index 142207f..671fbff 100644
>> --- a/tools/libfsimage/ext2fs-lib/Makefile
>> +++ b/tools/libfsimage/ext2fs-lib/Makefile
>> @@ -4,7 +4,10 @@ LIB_SRCS-y = ext2fs-lib.c
>>  
>>  FS = ext2fs-lib
>>  
>> -FS_LIBDEPS = -lext2fs
>> +FS_LIBDEPS = $(EXTFS_LIBS)
>> +
>> +# Include configure output (config.h) to headers search path
>> +CFLAGS += -I$(XEN_ROOT)/tools
> 
> Is there any way to move config.h from tools to under tools/include
> somewhere? 

Yes, but config.h should then be renamed to xen_config.h or something
different from config.h, since a lot of utilities we pack with Xen
include their own config.h and also include the tools/include folder, so
we might have a collision there.

If renaming it to xen_config.h is fine I will send a patch.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 14 10:22:50 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 10: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 1TCT2a-0002ez-KX; Fri, 14 Sep 2012 10:22: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 1TCT2Z-0002es-8e
	for xen-devel@lists.xen.org; Fri, 14 Sep 2012 10:22:27 +0000
Received: from [85.158.143.99:13350] by server-1.bemta-4.messagelabs.com id
	4C/84-12504-26503505; Fri, 14 Sep 2012 10:22:26 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1347618121!30003121!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDkyOTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32715 invoked from network); 14 Sep 2012 10:22:04 -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;
	14 Sep 2012 10:22:04 -0000
X-IronPort-AV: E=Sophos;i="4.80,422,1344211200"; d="scan'208";a="14542146"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Sep 2012 10:21:37 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Fri, 14 Sep 2012 11:21:37 +0100
Message-ID: <1347618095.24226.176.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Roger Pau Monne <roger.pau@citrix.com>
Date: Fri, 14 Sep 2012 11:21:35 +0100
In-Reply-To: <505304A2.7020901@citrix.com>
References: <20120905030239.GJ8912@reaktio.net>
	<1346846602-1109-1-git-send-email-roger.pau@citrix.com>
	<1347613534.24226.167.camel@zakaz.uk.xensource.com>
	<505304A2.7020901@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] libfsimage: add ext4 support for CentOS 5.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 Fri, 2012-09-14 at 11:19 +0100, Roger Pau Monne wrote:
> Ian Campbell wrote:
> > On Wed, 2012-09-05 at 13:03 +0100, Roger Pau Monne wrote:
> >> CentOS 5.x forked e2fs ext4 support into a different package called
> >> e4fs, and so headers and library names changed from ext2fs to ext4fs.
> >> Check if ext4fs/ext2fs.h and -lext4fs work, and use that instead of
> >> ext2fs to build libfsimage. This patch assumes that if the ext4fs
> >> library is present it should always be used instead of ext2fs.
> >>
> >> This patch includes a rework of the ext2fs check, a new ext4fs check
> >> and a minor modification in libfsimage to use the correct library.
> >>
> >> Signed-off-by: Roger Pau Monne <roger.pau@citrix.com>
> >> ---
> >> Please re-run autogen.sh after applying
> > 
> > Done & acked + applied. Thanks.
> > 
> >> diff --git a/tools/libfsimage/ext2fs-lib/Makefile b/tools/libfsimage/ext2fs-lib/Makefile
> >> index 142207f..671fbff 100644
> >> --- a/tools/libfsimage/ext2fs-lib/Makefile
> >> +++ b/tools/libfsimage/ext2fs-lib/Makefile
> >> @@ -4,7 +4,10 @@ LIB_SRCS-y = ext2fs-lib.c
> >>  
> >>  FS = ext2fs-lib
> >>  
> >> -FS_LIBDEPS = -lext2fs
> >> +FS_LIBDEPS = $(EXTFS_LIBS)
> >> +
> >> +# Include configure output (config.h) to headers search path
> >> +CFLAGS += -I$(XEN_ROOT)/tools
> > 
> > Is there any way to move config.h from tools to under tools/include
> > somewhere? 
> 
> Yes, but config.h should then be renamed to xen_config.h or something
> different from config.h, since a lot of utilities we pack with Xen
> include their own config.h and also include the tools/include folder, so
> we might have a collision there.
> 
> If renaming it to xen_config.h is fine I will send a patch.

I was imagining it would go in one of the subdirs but none of them
really look suitable, so xen_config.h is fine IMHO.

Might want to see what Ian J thinks first?

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 14 10:22:50 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 10: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 1TCT2a-0002ez-KX; Fri, 14 Sep 2012 10:22: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 1TCT2Z-0002es-8e
	for xen-devel@lists.xen.org; Fri, 14 Sep 2012 10:22:27 +0000
Received: from [85.158.143.99:13350] by server-1.bemta-4.messagelabs.com id
	4C/84-12504-26503505; Fri, 14 Sep 2012 10:22:26 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1347618121!30003121!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDkyOTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32715 invoked from network); 14 Sep 2012 10:22:04 -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;
	14 Sep 2012 10:22:04 -0000
X-IronPort-AV: E=Sophos;i="4.80,422,1344211200"; d="scan'208";a="14542146"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Sep 2012 10:21:37 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Fri, 14 Sep 2012 11:21:37 +0100
Message-ID: <1347618095.24226.176.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Roger Pau Monne <roger.pau@citrix.com>
Date: Fri, 14 Sep 2012 11:21:35 +0100
In-Reply-To: <505304A2.7020901@citrix.com>
References: <20120905030239.GJ8912@reaktio.net>
	<1346846602-1109-1-git-send-email-roger.pau@citrix.com>
	<1347613534.24226.167.camel@zakaz.uk.xensource.com>
	<505304A2.7020901@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] libfsimage: add ext4 support for CentOS 5.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 Fri, 2012-09-14 at 11:19 +0100, Roger Pau Monne wrote:
> Ian Campbell wrote:
> > On Wed, 2012-09-05 at 13:03 +0100, Roger Pau Monne wrote:
> >> CentOS 5.x forked e2fs ext4 support into a different package called
> >> e4fs, and so headers and library names changed from ext2fs to ext4fs.
> >> Check if ext4fs/ext2fs.h and -lext4fs work, and use that instead of
> >> ext2fs to build libfsimage. This patch assumes that if the ext4fs
> >> library is present it should always be used instead of ext2fs.
> >>
> >> This patch includes a rework of the ext2fs check, a new ext4fs check
> >> and a minor modification in libfsimage to use the correct library.
> >>
> >> Signed-off-by: Roger Pau Monne <roger.pau@citrix.com>
> >> ---
> >> Please re-run autogen.sh after applying
> > 
> > Done & acked + applied. Thanks.
> > 
> >> diff --git a/tools/libfsimage/ext2fs-lib/Makefile b/tools/libfsimage/ext2fs-lib/Makefile
> >> index 142207f..671fbff 100644
> >> --- a/tools/libfsimage/ext2fs-lib/Makefile
> >> +++ b/tools/libfsimage/ext2fs-lib/Makefile
> >> @@ -4,7 +4,10 @@ LIB_SRCS-y = ext2fs-lib.c
> >>  
> >>  FS = ext2fs-lib
> >>  
> >> -FS_LIBDEPS = -lext2fs
> >> +FS_LIBDEPS = $(EXTFS_LIBS)
> >> +
> >> +# Include configure output (config.h) to headers search path
> >> +CFLAGS += -I$(XEN_ROOT)/tools
> > 
> > Is there any way to move config.h from tools to under tools/include
> > somewhere? 
> 
> Yes, but config.h should then be renamed to xen_config.h or something
> different from config.h, since a lot of utilities we pack with Xen
> include their own config.h and also include the tools/include folder, so
> we might have a collision there.
> 
> If renaming it to xen_config.h is fine I will send a patch.

I was imagining it would go in one of the subdirs but none of them
really look suitable, so xen_config.h is fine IMHO.

Might want to see what Ian J thinks first?

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 14 10:45:34 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 10:45: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 1TCTOe-0002wl-Qb; Fri, 14 Sep 2012 10:45: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 1TCTOa-0002wg-Nr
	for xen-devel@lists.xen.org; Fri, 14 Sep 2012 10:45:15 +0000
Received: from [85.158.139.83:49653] by server-12.bemta-5.messagelabs.com id
	D6/6D-19338-7BA03505; Fri, 14 Sep 2012 10:45:11 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1347619511!16405109!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDkyOTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29528 invoked from network); 14 Sep 2012 10:45:11 -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;
	14 Sep 2012 10:45:11 -0000
X-IronPort-AV: E=Sophos;i="4.80,422,1344211200"; d="scan'208";a="14542715"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Sep 2012 10:45: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.279.1;
	Fri, 14 Sep 2012 11:45:10 +0100
Message-ID: <1347619509.24226.178.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Fri, 14 Sep 2012 11:45:09 +0100
In-Reply-To: <50531D98020000780009B54D@nat28.tlf.novell.com>
References: <640a0b0b44e67c843473.1347616836@cosworth.uk.xensource.com>
	<50531D98020000780009B54D@nat28.tlf.novell.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] tools: drop ia64 only foreign structs from
	headers
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-09-14 at 11:05 +0100, Jan Beulich wrote:
> >>> On 14.09.12 at 12:00, Ian Campbell <ian.campbell@citrix.com> wrote:
> > # HG changeset patch
> > # User Ian Campbell <ian.campbell@citrix.com>
> > # Date 1347616748 -3600
> > # Node ID 640a0b0b44e67c8434735c5129400b3a56a43683
> > # Parent  aabf685cd613b11e9b9709ae2a43f23f56d4d7ff
> > tools: drop ia64 only foreign structs from headers
> 
> Not sure why they got put there in the first place.

What are the criteria to be listed here? I was surprised how short the
list was...

> 
> > Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> 
> Acked-by: Jan Beulich <jbeulich@suse.com>

Thanks.
> 
> > diff -r aabf685cd613 -r 640a0b0b44e6 tools/include/xen-foreign/reference.size
> > --- a/tools/include/xen-foreign/reference.size	Fri Sep 14 10:39:09 2012 +0100
> > +++ b/tools/include/xen-foreign/reference.size	Fri Sep 14 10:59:08 2012 +0100
> > @@ -3,12 +3,7 @@ structs                   |  x86_32  x86
> >  
> >  start_info                |    1112    1168
> >  trap_info                 |       8      16
> > -pt_fpreg                  |       -       -
> >  cpu_user_regs             |      68     200
> > -xen_ia64_boot_param       |       -       -
> > -ia64_tr_entry             |       -       -
> > -vcpu_tr_regs              |       -       -
> > -vcpu_guest_context_regs   |       -       -
> >  vcpu_guest_context        |    2800    5168
> >  arch_vcpu_info            |      24      16
> >  vcpu_time_info            |      32      32
> > diff -r aabf685cd613 -r 640a0b0b44e6 tools/include/xen-foreign/structs.py
> > --- a/tools/include/xen-foreign/structs.py	Fri Sep 14 10:39:09 2012 +0100
> > +++ b/tools/include/xen-foreign/structs.py	Fri Sep 14 10:59:08 2012 +0100
> > @@ -5,12 +5,7 @@ unions  = [ "vcpu_cr_regs",
> >  
> >  structs = [ "start_info",
> >              "trap_info",
> > -            "pt_fpreg",
> >              "cpu_user_regs",
> > -            "xen_ia64_boot_param",
> > -            "ia64_tr_entry",
> > -            "vcpu_tr_regs",
> > -            "vcpu_guest_context_regs",
> >              "vcpu_guest_context",
> >              "arch_vcpu_info",
> >              "vcpu_time_info",
> > @@ -48,9 +43,6 @@ defines = [ "__i386__",
> >              "_VGCF_online",
> >              "VGCF_online",
> >  
> > -            # ia64
> > -            "VGCF_EXTRA_REGS",
> > -
> >              # all archs
> >              "xen_pfn_to_cr3",
> >              "xen_cr3_to_pfn",
> 
> 
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 14 10:45:34 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 10:45: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 1TCTOe-0002wl-Qb; Fri, 14 Sep 2012 10:45: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 1TCTOa-0002wg-Nr
	for xen-devel@lists.xen.org; Fri, 14 Sep 2012 10:45:15 +0000
Received: from [85.158.139.83:49653] by server-12.bemta-5.messagelabs.com id
	D6/6D-19338-7BA03505; Fri, 14 Sep 2012 10:45:11 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1347619511!16405109!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDkyOTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29528 invoked from network); 14 Sep 2012 10:45:11 -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;
	14 Sep 2012 10:45:11 -0000
X-IronPort-AV: E=Sophos;i="4.80,422,1344211200"; d="scan'208";a="14542715"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Sep 2012 10:45: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.279.1;
	Fri, 14 Sep 2012 11:45:10 +0100
Message-ID: <1347619509.24226.178.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Fri, 14 Sep 2012 11:45:09 +0100
In-Reply-To: <50531D98020000780009B54D@nat28.tlf.novell.com>
References: <640a0b0b44e67c843473.1347616836@cosworth.uk.xensource.com>
	<50531D98020000780009B54D@nat28.tlf.novell.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] tools: drop ia64 only foreign structs from
	headers
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-09-14 at 11:05 +0100, Jan Beulich wrote:
> >>> On 14.09.12 at 12:00, Ian Campbell <ian.campbell@citrix.com> wrote:
> > # HG changeset patch
> > # User Ian Campbell <ian.campbell@citrix.com>
> > # Date 1347616748 -3600
> > # Node ID 640a0b0b44e67c8434735c5129400b3a56a43683
> > # Parent  aabf685cd613b11e9b9709ae2a43f23f56d4d7ff
> > tools: drop ia64 only foreign structs from headers
> 
> Not sure why they got put there in the first place.

What are the criteria to be listed here? I was surprised how short the
list was...

> 
> > Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> 
> Acked-by: Jan Beulich <jbeulich@suse.com>

Thanks.
> 
> > diff -r aabf685cd613 -r 640a0b0b44e6 tools/include/xen-foreign/reference.size
> > --- a/tools/include/xen-foreign/reference.size	Fri Sep 14 10:39:09 2012 +0100
> > +++ b/tools/include/xen-foreign/reference.size	Fri Sep 14 10:59:08 2012 +0100
> > @@ -3,12 +3,7 @@ structs                   |  x86_32  x86
> >  
> >  start_info                |    1112    1168
> >  trap_info                 |       8      16
> > -pt_fpreg                  |       -       -
> >  cpu_user_regs             |      68     200
> > -xen_ia64_boot_param       |       -       -
> > -ia64_tr_entry             |       -       -
> > -vcpu_tr_regs              |       -       -
> > -vcpu_guest_context_regs   |       -       -
> >  vcpu_guest_context        |    2800    5168
> >  arch_vcpu_info            |      24      16
> >  vcpu_time_info            |      32      32
> > diff -r aabf685cd613 -r 640a0b0b44e6 tools/include/xen-foreign/structs.py
> > --- a/tools/include/xen-foreign/structs.py	Fri Sep 14 10:39:09 2012 +0100
> > +++ b/tools/include/xen-foreign/structs.py	Fri Sep 14 10:59:08 2012 +0100
> > @@ -5,12 +5,7 @@ unions  = [ "vcpu_cr_regs",
> >  
> >  structs = [ "start_info",
> >              "trap_info",
> > -            "pt_fpreg",
> >              "cpu_user_regs",
> > -            "xen_ia64_boot_param",
> > -            "ia64_tr_entry",
> > -            "vcpu_tr_regs",
> > -            "vcpu_guest_context_regs",
> >              "vcpu_guest_context",
> >              "arch_vcpu_info",
> >              "vcpu_time_info",
> > @@ -48,9 +43,6 @@ defines = [ "__i386__",
> >              "_VGCF_online",
> >              "VGCF_online",
> >  
> > -            # ia64
> > -            "VGCF_EXTRA_REGS",
> > -
> >              # all archs
> >              "xen_pfn_to_cr3",
> >              "xen_cr3_to_pfn",
> 
> 
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 14 10:48:31 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 10: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 1TCTRC-00032j-CX; Fri, 14 Sep 2012 10: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.Jackson@eu.citrix.com>) id 1TCTRB-00032c-2W
	for xen-devel@lists.xensource.com; Fri, 14 Sep 2012 10:47:53 +0000
Received: from [85.158.143.99:43898] by server-2.bemta-4.messagelabs.com id
	30/A2-21239-85B03505; Fri, 14 Sep 2012 10:47:52 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1347619671!22815648!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDkyOTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9871 invoked from network); 14 Sep 2012 10:47:51 -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;
	14 Sep 2012 10:47:51 -0000
X-IronPort-AV: E=Sophos;i="4.80,422,1344211200"; d="scan'208";a="14542750"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Sep 2012 10:46: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.279.1; Fri, 14 Sep 2012 11:46: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 1TCTQI-0006i0-A1;
	Fri, 14 Sep 2012 10:46:58 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1TCTQI-00081T-0f;
	Fri, 14 Sep 2012 11:46:58 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-13760-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 14 Sep 2012 11:46:58 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13760: 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 13760 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13760/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore            fail   like 13668
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail like 13668
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail like 13668

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  5613018f93b1
baseline version:
 xen                  7d770de90b7f

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@citrix.com>
  Boris Ostrovsky <boris.ostrovsky@amd.com>
  Christoph Egger <Christoph.Egger@amd.com>
  Dan Magenheimer <dan.magenheimer@oracle.com>
  David Vrabel <david.vrabel@citrix.com>
  Ian Campbell <ian.campbell@citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Keir Fraser <keir@xen.org>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
  Wei Wang <wei.wang2@amd.com>
  Zhenzhong Duan <zhenzhong.duan@oracle.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-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-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-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-amd64-amd64-xl-win                                      fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=xen-unstable
+ revision=5613018f93b1
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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 5613018f93b1
+ branch=xen-unstable
+ revision=5613018f93b1
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-unstable
+ '[' xxen = xlinux ']'
+ linuxbranch=linux
+ : master
+ : tested/2.6.39.x
+ . ap-common
++ : xen@xenbits.xensource.com
++ : http://xenbits.xen.org/hg/staging/xen-unstable.hg
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : xen@xenbits.xensource.com:git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.xen-unstable
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-unstable.git
++ : daily-cron.xen-unstable
+ TREE_LINUX=xen@xenbits.xensource.com:git/linux-pvops.git
+ TREE_QEMU_UPSTREAM=xen@xenbits.xensource.com:git/qemu-upstream-unstable.git
+ info_linux_tree xen-unstable
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/xen-unstable.hg
+ hg push -r 5613018f93b1 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 52 changesets with 321 changes to 203 files

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 14 10:48:31 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 10: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 1TCTRC-00032j-CX; Fri, 14 Sep 2012 10: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.Jackson@eu.citrix.com>) id 1TCTRB-00032c-2W
	for xen-devel@lists.xensource.com; Fri, 14 Sep 2012 10:47:53 +0000
Received: from [85.158.143.99:43898] by server-2.bemta-4.messagelabs.com id
	30/A2-21239-85B03505; Fri, 14 Sep 2012 10:47:52 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1347619671!22815648!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDkyOTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9871 invoked from network); 14 Sep 2012 10:47:51 -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;
	14 Sep 2012 10:47:51 -0000
X-IronPort-AV: E=Sophos;i="4.80,422,1344211200"; d="scan'208";a="14542750"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Sep 2012 10:46: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.279.1; Fri, 14 Sep 2012 11:46: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 1TCTQI-0006i0-A1;
	Fri, 14 Sep 2012 10:46:58 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1TCTQI-00081T-0f;
	Fri, 14 Sep 2012 11:46:58 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-13760-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 14 Sep 2012 11:46:58 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13760: 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 13760 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13760/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore            fail   like 13668
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail like 13668
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail like 13668

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  5613018f93b1
baseline version:
 xen                  7d770de90b7f

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@citrix.com>
  Boris Ostrovsky <boris.ostrovsky@amd.com>
  Christoph Egger <Christoph.Egger@amd.com>
  Dan Magenheimer <dan.magenheimer@oracle.com>
  David Vrabel <david.vrabel@citrix.com>
  Ian Campbell <ian.campbell@citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Keir Fraser <keir@xen.org>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
  Wei Wang <wei.wang2@amd.com>
  Zhenzhong Duan <zhenzhong.duan@oracle.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-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-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-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-amd64-amd64-xl-win                                      fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=xen-unstable
+ revision=5613018f93b1
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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 5613018f93b1
+ branch=xen-unstable
+ revision=5613018f93b1
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-unstable
+ '[' xxen = xlinux ']'
+ linuxbranch=linux
+ : master
+ : tested/2.6.39.x
+ . ap-common
++ : xen@xenbits.xensource.com
++ : http://xenbits.xen.org/hg/staging/xen-unstable.hg
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : xen@xenbits.xensource.com:git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.xen-unstable
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-unstable.git
++ : daily-cron.xen-unstable
+ TREE_LINUX=xen@xenbits.xensource.com:git/linux-pvops.git
+ TREE_QEMU_UPSTREAM=xen@xenbits.xensource.com:git/qemu-upstream-unstable.git
+ info_linux_tree xen-unstable
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/xen-unstable.hg
+ hg push -r 5613018f93b1 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 52 changesets with 321 changes to 203 files

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 14 11:10:50 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 11:10: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 1TCTmf-00056K-EL; Fri, 14 Sep 2012 11:10: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 1TCTmd-00056F-HJ
	for xen-devel@lists.xen.org; Fri, 14 Sep 2012 11:10:04 +0000
Received: from [85.158.137.99:17419] by server-2.bemta-3.messagelabs.com id
	AE/AA-04862-A8013505; Fri, 14 Sep 2012 11:10:02 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-217.messagelabs.com!1347620999!12529585!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNjk2MTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1375 invoked from network); 14 Sep 2012 11:10:01 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-6.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Sep 2012 11:10:01 -0000
X-IronPort-AV: E=Sophos;i="4.80,422,1344211200"; d="scan'208";a="37872783"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Sep 2012 11:09:59 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Fri, 14 Sep 2012 07:09:58 -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 1TCTmY-0005rf-Ap;
	Fri, 14 Sep 2012 12:09:58 +0100
MIME-Version: 1.0
X-Mercurial-Node: 58ab3fb73d13e250f334a38599b749640deac190
Message-ID: <58ab3fb73d13e250f334.1347620998@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Fri, 14 Sep 2012 12:09:58 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH] libxl: Enable -Wshadow
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 1347620983 -3600
# Node ID 58ab3fb73d13e250f334a38599b749640deac190
# Parent  0547430886c507989dd9091ef5f1e2d089a50351
libxl: Enable -Wshadow.

It was convenient to invent $(CFLAGS_LIBXL) to do this.

Various renamings to avoid shadowing standard functions:
  - index(3)
  - listen(2)
  - link(2)
  - abort(3)
  - abs(3)

Reduced the scope of some variables to avoid conflicts.

Change to libxc is due to the nested hypercall buf macros in
set_xen_guest_handle (used in libxl) using the same local private vars.

Build tested only.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r 0547430886c5 -r 58ab3fb73d13 tools/libxc/xenctrl.h
--- a/tools/libxc/xenctrl.h	Fri Sep 14 11:00:40 2012 +0100
+++ b/tools/libxc/xenctrl.h	Fri Sep 14 12:09:43 2012 +0100
@@ -236,10 +236,10 @@ typedef struct xc_hypercall_buffer xc_hy
  * Returns the hypercall_buffer associated with a variable.
  */
 #define HYPERCALL_BUFFER(_name)                                                              \
-    ({  xc_hypercall_buffer_t _val1;                                                         \
-        typeof(XC__HYPERCALL_BUFFER_NAME(_name)) *_val2 = &XC__HYPERCALL_BUFFER_NAME(_name); \
-        (void)(&_val1 == _val2);                                                             \
-        (_val2)->param_shadow ? (_val2)->param_shadow : (_val2);                             \
+    ({  xc_hypercall_buffer_t _buf1;                                                         \
+        typeof(XC__HYPERCALL_BUFFER_NAME(_name)) *_buf2 = &XC__HYPERCALL_BUFFER_NAME(_name); \
+        (void)(&_buf1 == _buf2);                                                             \
+        (_buf2)->param_shadow ? (_buf2)->param_shadow : (_buf2);                             \
      })
 
 #define HYPERCALL_BUFFER_INIT_NO_BOUNCE .dir = 0, .sz = 0, .ubuf = (void *)-1
@@ -274,10 +274,10 @@ typedef struct xc_hypercall_buffer xc_hy
  * directly as a hypercall argument.
  */
 #define HYPERCALL_BUFFER_AS_ARG(_name)                                             \
-    ({  xc_hypercall_buffer_t _val1;                                               \
-        typeof(XC__HYPERCALL_BUFFER_NAME(_name)) *_val2 = HYPERCALL_BUFFER(_name); \
-        (void)(&_val1 == _val2);                                                   \
-        (unsigned long)(_val2)->hbuf;                                              \
+    ({  xc_hypercall_buffer_t _bufarg1;                                               \
+        typeof(XC__HYPERCALL_BUFFER_NAME(_name)) *_bufarg2 = HYPERCALL_BUFFER(_name); \
+        (void)(&_bufarg1 == _bufarg2);                                                   \
+        (unsigned long)(_bufarg2)->hbuf;                                              \
      })
 
 /*
@@ -287,10 +287,10 @@ typedef struct xc_hypercall_buffer xc_hy
 #undef set_xen_guest_handle
 #define set_xen_guest_handle(_hnd, _val)                                         \
     do {                                                                         \
-        xc_hypercall_buffer_t _val1;                                             \
-        typeof(XC__HYPERCALL_BUFFER_NAME(_val)) *_val2 = HYPERCALL_BUFFER(_val); \
-        (void) (&_val1 == _val2);                                                 \
-        set_xen_guest_handle_raw(_hnd, (_val2)->hbuf);                           \
+        xc_hypercall_buffer_t _bufhnd1;                                             \
+        typeof(XC__HYPERCALL_BUFFER_NAME(_val)) *_bufhnd2 = HYPERCALL_BUFFER(_val); \
+        (void) (&_bufhnd1 == _bufhnd2);                                                 \
+        set_xen_guest_handle_raw(_hnd, (_bufhnd2)->hbuf);                           \
     } while (0)
 
 /* Use with set_xen_guest_handle in place of NULL */
diff -r 0547430886c5 -r 58ab3fb73d13 tools/libxl/Makefile
--- a/tools/libxl/Makefile	Fri Sep 14 11:00:40 2012 +0100
+++ b/tools/libxl/Makefile	Fri Sep 14 12:09:43 2012 +0100
@@ -22,6 +22,12 @@ endif
 LIBXL_LIBS =
 LIBXL_LIBS = $(LDLIBS_libxenctrl) $(LDLIBS_libxenguest) $(LDLIBS_libxenstore) $(LDLIBS_libblktapctl) $(PTYFUNCS_LIBS) $(LIBUUID_LIBS)
 
+CFLAGS_LIBXL += $(CFLAGS_libxenctrl)
+CFLAGS_LIBXL += $(CFLAGS_libxenguest)
+CFLAGS_LIBXL += $(CFLAGS_libxenstore)
+CFLAGS_LIBXL += $(CFLAGS_libblktapctl) 
+CFLAGS_LIBXL += -Wshadow
+
 CFLAGS += $(PTHREAD_CFLAGS)
 LDFLAGS += $(PTHREAD_LDFLAGS)
 LIBXL_LIBS += $(PTHREAD_LIBS)
@@ -71,7 +77,7 @@ LIBXL_OBJS = flexarray.o libxl.o libxl_c
 			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
+$(LIBXL_OBJS): CFLAGS += $(CFLAGS_LIBXL) -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
diff -r 0547430886c5 -r 58ab3fb73d13 tools/libxl/flexarray.c
--- a/tools/libxl/flexarray.c	Fri Sep 14 11:00:40 2012 +0100
+++ b/tools/libxl/flexarray.c	Fri Sep 14 12:09:43 2012 +0100
@@ -48,19 +48,19 @@ int flexarray_grow(flexarray_t *array, i
     return 0;
 }
 
-int flexarray_set(flexarray_t *array, unsigned int index, void *ptr)
+int flexarray_set(flexarray_t *array, unsigned int idx, void *ptr)
 {
-    if (index >= array->size) {
+    if (idx >= array->size) {
         int newsize;
         if (!array->autogrow)
             return 1;
-        newsize = (array->size * 2 < index) ? index + 1 : array->size * 2;
+        newsize = (array->size * 2 < idx) ? idx + 1 : array->size * 2;
         if (flexarray_grow(array, newsize - array->size))
             return 2;
     }
-    if ( index + 1 > array->count )
-        array->count = index + 1;
-    array->data[index] = ptr;
+    if ( idx + 1 > array->count )
+        array->count = idx + 1;
+    array->data[idx] = ptr;
     return 0;
 }
 
@@ -92,11 +92,11 @@ int flexarray_vappend(flexarray_t *array
     return ret;
 }
 
-int flexarray_get(flexarray_t *array, int index, void **ptr)
+int flexarray_get(flexarray_t *array, int idx, void **ptr)
 {
-    if (index >= array->size)
+    if (idx >= array->size)
         return 1;
-    *ptr = array->data[index];
+    *ptr = array->data[idx];
     return 0;
 }
 
diff -r 0547430886c5 -r 58ab3fb73d13 tools/libxl/libxl.c
--- a/tools/libxl/libxl.c	Fri Sep 14 11:00:40 2012 +0100
+++ b/tools/libxl/libxl.c	Fri Sep 14 12:09:43 2012 +0100
@@ -665,7 +665,7 @@ out:
 libxl_vminfo * libxl_list_vm(libxl_ctx *ctx, int *nb_vm_out)
 {
     libxl_vminfo *ptr;
-    int index, i, ret;
+    int idx, i, ret;
     xc_domaininfo_t info[1024];
     int size = 1024;
 
@@ -678,15 +678,15 @@ libxl_vminfo * libxl_list_vm(libxl_ctx *
         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "geting domain info list");
         return NULL;
     }
-    for (index = i = 0; i < ret; i++) {
+    for (idx = i = 0; i < ret; i++) {
         if (libxl_is_stubdom(ctx, info[i].domain, NULL))
             continue;
-        memcpy(&(ptr[index].uuid), info[i].handle, sizeof(xen_domain_handle_t));
-        ptr[index].domid = info[i].domain;
-
-        index++;
-    }
-    *nb_vm_out = index;
+        memcpy(&(ptr[idx].uuid), info[i].handle, sizeof(xen_domain_handle_t));
+        ptr[idx].domid = info[i].domain;
+
+        idx++;
+    }
+    *nb_vm_out = idx;
     return ptr;
 }
 
@@ -3354,7 +3354,7 @@ int libxl_set_memory_target(libxl_ctx *c
         int32_t target_memkb, int relative, int enforce)
 {
     GC_INIT(ctx);
-    int rc = 1, abort = 0;
+    int rc = 1, abort_transaction = 0;
     uint32_t memorykb = 0, videoram = 0;
     uint32_t current_target_memkb = 0, new_target_memkb = 0;
     char *memmax, *endptr, *videoram_s = NULL, *target = NULL;
@@ -3373,7 +3373,7 @@ retry_transaction:
         xs_transaction_end(ctx->xsh, t, 1);
         rc = libxl__fill_dom0_memory_info(gc, &current_target_memkb);
         if (rc < 0) {
-            abort = 1;
+            abort_transaction = 1;
             goto out;
         }
         goto retry_transaction;
@@ -3381,7 +3381,7 @@ retry_transaction:
         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR,
                 "cannot get target memory info from %s/memory/target\n",
                 dompath);
-        abort = 1;
+        abort_transaction = 1;
         goto out;
     } else {
         current_target_memkb = strtoul(target, &endptr, 10);
@@ -3389,7 +3389,7 @@ retry_transaction:
             LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR,
                     "invalid memory target %s from %s/memory/target\n",
                     target, dompath);
-            abort = 1;
+            abort_transaction = 1;
             goto out;
         }
     }
@@ -3399,7 +3399,7 @@ retry_transaction:
         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR,
                 "cannot get memory info from %s/memory/static-max\n",
                 dompath);
-        abort = 1;
+        abort_transaction = 1;
         goto out;
     }
     memorykb = strtoul(memmax, &endptr, 10);
@@ -3407,7 +3407,7 @@ retry_transaction:
         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR,
                 "invalid max memory %s from %s/memory/static-max\n",
                 memmax, dompath);
-        abort = 1;
+        abort_transaction = 1;
         goto out;
     }
 
@@ -3422,7 +3422,7 @@ retry_transaction:
         LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
                 "memory_dynamic_max must be less than or equal to"
                 " memory_static_max\n");
-        abort = 1;
+        abort_transaction = 1;
         goto out;
     }
 
@@ -3430,7 +3430,7 @@ retry_transaction:
         LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
                 "new target %d for dom0 is below the minimum threshold\n",
                  new_target_memkb);
-        abort = 1;
+        abort_transaction = 1;
         goto out;
     }
     videoram_s = libxl__xs_read(gc, t, libxl__sprintf(gc,
@@ -3445,7 +3445,7 @@ retry_transaction:
             LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR,
                     "xc_domain_setmaxmem domid=%d memkb=%d failed "
                     "rc=%d\n", domid, memorykb + LIBXL_MAXMEM_CONSTANT, rc);
-            abort = 1;
+            abort_transaction = 1;
             goto out;
         }
     }
@@ -3458,7 +3458,7 @@ retry_transaction:
                 "xc_domain_set_pod_target domid=%d, memkb=%d "
                 "failed rc=%d\n", domid, new_target_memkb / 4,
                 rc);
-        abort = 1;
+        abort_transaction = 1;
         goto out;
     }
 
@@ -3466,7 +3466,7 @@ retry_transaction:
                 dompath), "%"PRIu32, new_target_memkb);
     rc = xc_domain_getinfolist(ctx->xch, domid, 1, &info);
     if (rc != 1 || info.domain != domid) {
-        abort = 1;
+        abort_transaction = 1;
         goto out;
     }
     xcinfo2xlinfo(&info, &ptr);
@@ -3475,7 +3475,8 @@ retry_transaction:
             "%"PRIu32, new_target_memkb / 1024);
 
 out:
-    if (!xs_transaction_end(ctx->xsh, t, abort) && !abort)
+    if (!xs_transaction_end(ctx->xsh, t, abort_transaction)
+        && !abort_transaction)
         if (errno == EAGAIN)
             goto retry_transaction;
 
diff -r 0547430886c5 -r 58ab3fb73d13 tools/libxl/libxl_dm.c
--- a/tools/libxl/libxl_dm.c	Fri Sep 14 11:00:40 2012 +0100
+++ b/tools/libxl/libxl_dm.c	Fri Sep 14 12:09:43 2012 +0100
@@ -379,7 +379,7 @@ static char ** libxl__build_device_model
     }
     if (vnc) {
         int display = 0;
-        const char *listen = "127.0.0.1";
+        const char *addr = "127.0.0.1";
         char *vncarg = NULL;
 
         flexarray_append(dm_args, "-vnc");
@@ -387,16 +387,16 @@ static char ** libxl__build_device_model
         if (vnc->display) {
             display = vnc->display;
             if (vnc->listen && strchr(vnc->listen, ':') == NULL) {
-                listen = vnc->listen;
+                addr = vnc->listen;
             }
         } else if (vnc->listen) {
-            listen = vnc->listen;
+            addr = vnc->listen;
         }
 
-        if (strchr(listen, ':') != NULL)
-            vncarg = libxl__sprintf(gc, "%s", listen);
+        if (strchr(addr, ':') != NULL)
+            vncarg = libxl__sprintf(gc, "%s", addr);
         else
-            vncarg = libxl__sprintf(gc, "%s:%d", listen, display);
+            vncarg = libxl__sprintf(gc, "%s:%d", addr, display);
         if (vnc->passwd && vnc->passwd[0]) {
             vncarg = libxl__sprintf(gc, "%s,password", vncarg);
         }
diff -r 0547430886c5 -r 58ab3fb73d13 tools/libxl/libxl_event.c
--- a/tools/libxl/libxl_event.c	Fri Sep 14 11:00:40 2012 +0100
+++ b/tools/libxl/libxl_event.c	Fri Sep 14 12:09:43 2012 +0100
@@ -167,15 +167,15 @@ static void time_insert_finite(libxl__gc
 }
 
 static int time_register_finite(libxl__gc *gc, libxl__ev_time *ev,
-                                struct timeval abs)
+                                struct timeval absolute)
 {
     int rc;
 
-    rc = OSEVENT_HOOK(timeout_register, &ev->for_app_reg, abs, ev);
+    rc = OSEVENT_HOOK(timeout_register, &ev->for_app_reg, absolute, ev);
     if (rc) return rc;
 
     ev->infinite = 0;
-    ev->abs = abs;
+    ev->abs = absolute;
     time_insert_finite(gc, ev);
 
     return 0;
@@ -202,16 +202,16 @@ static void time_done_debug(libxl__gc *g
 
 int libxl__ev_time_register_abs(libxl__gc *gc, libxl__ev_time *ev,
                                 libxl__ev_time_callback *func,
-                                struct timeval abs)
+                                struct timeval absolute)
 {
     int rc;
 
     CTX_LOCK;
 
     DBG("ev_time=%p register abs=%lu.%06lu",
-        ev, (unsigned long)abs.tv_sec, (unsigned long)abs.tv_usec);
+        ev, (unsigned long)absolute.tv_sec, (unsigned long)absolute.tv_usec);
 
-    rc = time_register_finite(gc, ev, abs);
+    rc = time_register_finite(gc, ev, absolute);
     if (rc) goto out;
 
     ev->func = func;
@@ -228,7 +228,7 @@ int libxl__ev_time_register_rel(libxl__g
                                 libxl__ev_time_callback *func,
                                 int milliseconds /* as for poll(2) */)
 {
-    struct timeval abs;
+    struct timeval absolute;
     int rc;
 
     CTX_LOCK;
@@ -238,10 +238,10 @@ int libxl__ev_time_register_rel(libxl__g
     if (milliseconds < 0) {
         ev->infinite = 1;
     } else {
-        rc = time_rel_to_abs(gc, milliseconds, &abs);
+        rc = time_rel_to_abs(gc, milliseconds, &absolute);
         if (rc) goto out;
 
-        rc = time_register_finite(gc, ev, abs);
+        rc = time_register_finite(gc, ev, absolute);
         if (rc) goto out;
     }
 
@@ -255,26 +255,26 @@ int libxl__ev_time_register_rel(libxl__g
 }
 
 int libxl__ev_time_modify_abs(libxl__gc *gc, libxl__ev_time *ev,
-                              struct timeval abs)
+                              struct timeval absolute)
 {
     int rc;
 
     CTX_LOCK;
 
     DBG("ev_time=%p modify abs==%lu.%06lu",
-        ev, (unsigned long)abs.tv_sec, (unsigned long)abs.tv_usec);
+        ev, (unsigned long)absolute.tv_sec, (unsigned long)absolute.tv_usec);
 
     assert(libxl__ev_time_isregistered(ev));
 
     if (ev->infinite) {
-        rc = time_register_finite(gc, ev, abs);
+        rc = time_register_finite(gc, ev, absolute);
         if (rc) goto out;
     } else {
-        rc = OSEVENT_HOOK(timeout_modify, &ev->for_app_reg, abs);
+        rc = OSEVENT_HOOK(timeout_modify, &ev->for_app_reg, absolute);
         if (rc) goto out;
 
         LIBXL_TAILQ_REMOVE(&CTX->etimes, ev, entry);
-        ev->abs = abs;
+        ev->abs = absolute;
         time_insert_finite(gc, ev);
     }
 
@@ -288,7 +288,7 @@ int libxl__ev_time_modify_abs(libxl__gc 
 int libxl__ev_time_modify_rel(libxl__gc *gc, libxl__ev_time *ev,
                               int milliseconds)
 {
-    struct timeval abs;
+    struct timeval absolute;
     int rc;
 
     CTX_LOCK;
@@ -304,10 +304,10 @@ int libxl__ev_time_modify_rel(libxl__gc 
         goto out;
     }
 
-    rc = time_rel_to_abs(gc, milliseconds, &abs);
+    rc = time_rel_to_abs(gc, milliseconds, &absolute);
     if (rc) goto out;
 
-    rc = libxl__ev_time_modify_abs(gc, ev, abs);
+    rc = libxl__ev_time_modify_abs(gc, ev, absolute);
     if (rc) goto out;
 
     rc = 0;
diff -r 0547430886c5 -r 58ab3fb73d13 tools/libxl/libxl_exec.c
--- a/tools/libxl/libxl_exec.c	Fri Sep 14 11:00:40 2012 +0100
+++ b/tools/libxl/libxl_exec.c	Fri Sep 14 12:09:43 2012 +0100
@@ -35,7 +35,7 @@ static void check_open_fds(const char *w
 #ifdef __linux__
         size_t len;
         char path[PATH_MAX];
-        char link[PATH_MAX+1];
+        char linkpath[PATH_MAX+1];
 #endif
         flags = fcntl(i, F_GETFD);
         if ( flags == -1 ) {
@@ -52,11 +52,11 @@ static void check_open_fds(const char *w
 
 #ifdef __linux__
         snprintf(path, PATH_MAX, "/proc/%d/fd/%d", getpid(), i);
-        len = readlink(path, link, PATH_MAX);
+        len = readlink(path, linkpath, PATH_MAX);
         if (len > 0) {
-            link[len] = '\0';
+            linkpath[len] = '\0';
             fprintf(stderr, "libxl: execing %s: fd %d is open to %s with flags %#x\n",
-                    what, i, link, flags);
+                    what, i, linkpath, flags);
         } else
 #endif
             fprintf(stderr, "libxl: execing %s: fd %d is open with flags %#x\n",
diff -r 0547430886c5 -r 58ab3fb73d13 tools/libxl/libxl_json.c
--- a/tools/libxl/libxl_json.c	Fri Sep 14 11:00:40 2012 +0100
+++ b/tools/libxl/libxl_json.c	Fri Sep 14 12:09:43 2012 +0100
@@ -275,7 +275,7 @@ static int json_object_append_to(libxl__
 
 void libxl__json_object_free(libxl__gc *gc, libxl__json_object *obj)
 {
-    int index = 0;
+    int idx = 0;
 
     if (obj == NULL)
         return;
@@ -287,8 +287,8 @@ void libxl__json_object_free(libxl__gc *
     case JSON_MAP: {
         libxl__json_map_node *node = NULL;
 
-        for (index = 0; index < obj->u.map->count; index++) {
-            if (flexarray_get(obj->u.map, index, (void**)&node) != 0)
+        for (idx = 0; idx < obj->u.map->count; idx++) {
+            if (flexarray_get(obj->u.map, idx, (void**)&node) != 0)
                 break;
             libxl__json_object_free(gc, node->obj);
             free(node->map_key);
@@ -302,8 +302,8 @@ void libxl__json_object_free(libxl__gc *
         libxl__json_object *node = NULL;
         break;
 
-        for (index = 0; index < obj->u.array->count; index++) {
-            if (flexarray_get(obj->u.array, index, (void**)&node) != 0)
+        for (idx = 0; idx < obj->u.array->count; idx++) {
+            if (flexarray_get(obj->u.array, idx, (void**)&node) != 0)
                 break;
             libxl__json_object_free(gc, node);
             node = NULL;
@@ -359,14 +359,14 @@ const libxl__json_object *libxl__json_ma
                                           libxl__json_node_type expected_type)
 {
     flexarray_t *maps = NULL;
-    int index = 0;
+    int idx = 0;
 
     if (libxl__json_object_is_map(o)) {
         libxl__json_map_node *node = NULL;
 
         maps = o->u.map;
-        for (index = 0; index < maps->count; index++) {
-            if (flexarray_get(maps, index, (void**)&node) != 0)
+        for (idx = 0; idx < maps->count; idx++) {
+            if (flexarray_get(maps, idx, (void**)&node) != 0)
                 return NULL;
             if (strcmp(key, node->map_key) == 0) {
                 if (expected_type == JSON_ANY
diff -r 0547430886c5 -r 58ab3fb73d13 tools/libxl/libxl_pci.c
--- a/tools/libxl/libxl_pci.c	Fri Sep 14 11:00:40 2012 +0100
+++ b/tools/libxl/libxl_pci.c	Fri Sep 14 12:09:43 2012 +0100
@@ -167,7 +167,6 @@ static int libxl__device_pci_remove_xens
     char *be_path, *num_devs_path, *num_devs, *xsdev, *tmp, *tmppath;
     int num, i, j;
     xs_transaction_t t;
-    unsigned int domain = 0, bus = 0, dev = 0, func = 0;
 
     be_path = libxl__sprintf(gc, "%s/backend/pci/%d/0", libxl__xs_get_dompath(gc, 0), domid);
     num_devs_path = libxl__sprintf(gc, "%s/num_devs", be_path);
@@ -188,6 +187,7 @@ static int libxl__device_pci_remove_xens
     }
 
     for (i = 0; i < num; i++) {
+        unsigned int domain = 0, bus = 0, dev = 0, func = 0;
         xsdev = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/dev-%d", be_path, i));
         sscanf(xsdev, PCI_BDF, &domain, &bus, &dev, &func);
         if (domain == pcidev->domain && bus == pcidev->bus &&
diff -r 0547430886c5 -r 58ab3fb73d13 tools/libxl/libxl_qmp.c
--- a/tools/libxl/libxl_qmp.c	Fri Sep 14 11:00:40 2012 +0100
+++ b/tools/libxl/libxl_qmp.c	Fri Sep 14 12:09:43 2012 +0100
@@ -171,7 +171,7 @@ static int qmp_register_vnc_callback(lib
 {
     GC_INIT(qmp->ctx);
     const libxl__json_object *obj;
-    const char *listen, *port;
+    const char *addr, *port;
     int rc = -1;
 
     if (!libxl__json_object_is_map(o)) {
@@ -184,17 +184,17 @@ static int qmp_register_vnc_callback(lib
     }
 
     obj = libxl__json_map_get("host", o, JSON_STRING);
-    listen = libxl__json_object_get_string(obj);
+    addr = libxl__json_object_get_string(obj);
     obj = libxl__json_map_get("service", o, JSON_STRING);
     port = libxl__json_object_get_string(obj);
 
-    if (!listen || !port) {
+    if (!addr || !port) {
         LIBXL__LOG(qmp->ctx, LIBXL__LOG_ERROR,
                    "Failed to retreive VNC connect information.");
         goto out;
     }
 
-    rc = qmp_write_domain_console_item(gc, qmp->domid, "vnc-listen", listen);
+    rc = qmp_write_domain_console_item(gc, qmp->domid, "vnc-listen", addr);
     if (!rc)
         rc = qmp_write_domain_console_item(gc, qmp->domid, "vnc-port", port);
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 14 11:10:50 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 11:10: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 1TCTmf-00056K-EL; Fri, 14 Sep 2012 11:10: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 1TCTmd-00056F-HJ
	for xen-devel@lists.xen.org; Fri, 14 Sep 2012 11:10:04 +0000
Received: from [85.158.137.99:17419] by server-2.bemta-3.messagelabs.com id
	AE/AA-04862-A8013505; Fri, 14 Sep 2012 11:10:02 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-217.messagelabs.com!1347620999!12529585!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNjk2MTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1375 invoked from network); 14 Sep 2012 11:10:01 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-6.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Sep 2012 11:10:01 -0000
X-IronPort-AV: E=Sophos;i="4.80,422,1344211200"; d="scan'208";a="37872783"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Sep 2012 11:09:59 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Fri, 14 Sep 2012 07:09:58 -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 1TCTmY-0005rf-Ap;
	Fri, 14 Sep 2012 12:09:58 +0100
MIME-Version: 1.0
X-Mercurial-Node: 58ab3fb73d13e250f334a38599b749640deac190
Message-ID: <58ab3fb73d13e250f334.1347620998@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Fri, 14 Sep 2012 12:09:58 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH] libxl: Enable -Wshadow
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 1347620983 -3600
# Node ID 58ab3fb73d13e250f334a38599b749640deac190
# Parent  0547430886c507989dd9091ef5f1e2d089a50351
libxl: Enable -Wshadow.

It was convenient to invent $(CFLAGS_LIBXL) to do this.

Various renamings to avoid shadowing standard functions:
  - index(3)
  - listen(2)
  - link(2)
  - abort(3)
  - abs(3)

Reduced the scope of some variables to avoid conflicts.

Change to libxc is due to the nested hypercall buf macros in
set_xen_guest_handle (used in libxl) using the same local private vars.

Build tested only.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r 0547430886c5 -r 58ab3fb73d13 tools/libxc/xenctrl.h
--- a/tools/libxc/xenctrl.h	Fri Sep 14 11:00:40 2012 +0100
+++ b/tools/libxc/xenctrl.h	Fri Sep 14 12:09:43 2012 +0100
@@ -236,10 +236,10 @@ typedef struct xc_hypercall_buffer xc_hy
  * Returns the hypercall_buffer associated with a variable.
  */
 #define HYPERCALL_BUFFER(_name)                                                              \
-    ({  xc_hypercall_buffer_t _val1;                                                         \
-        typeof(XC__HYPERCALL_BUFFER_NAME(_name)) *_val2 = &XC__HYPERCALL_BUFFER_NAME(_name); \
-        (void)(&_val1 == _val2);                                                             \
-        (_val2)->param_shadow ? (_val2)->param_shadow : (_val2);                             \
+    ({  xc_hypercall_buffer_t _buf1;                                                         \
+        typeof(XC__HYPERCALL_BUFFER_NAME(_name)) *_buf2 = &XC__HYPERCALL_BUFFER_NAME(_name); \
+        (void)(&_buf1 == _buf2);                                                             \
+        (_buf2)->param_shadow ? (_buf2)->param_shadow : (_buf2);                             \
      })
 
 #define HYPERCALL_BUFFER_INIT_NO_BOUNCE .dir = 0, .sz = 0, .ubuf = (void *)-1
@@ -274,10 +274,10 @@ typedef struct xc_hypercall_buffer xc_hy
  * directly as a hypercall argument.
  */
 #define HYPERCALL_BUFFER_AS_ARG(_name)                                             \
-    ({  xc_hypercall_buffer_t _val1;                                               \
-        typeof(XC__HYPERCALL_BUFFER_NAME(_name)) *_val2 = HYPERCALL_BUFFER(_name); \
-        (void)(&_val1 == _val2);                                                   \
-        (unsigned long)(_val2)->hbuf;                                              \
+    ({  xc_hypercall_buffer_t _bufarg1;                                               \
+        typeof(XC__HYPERCALL_BUFFER_NAME(_name)) *_bufarg2 = HYPERCALL_BUFFER(_name); \
+        (void)(&_bufarg1 == _bufarg2);                                                   \
+        (unsigned long)(_bufarg2)->hbuf;                                              \
      })
 
 /*
@@ -287,10 +287,10 @@ typedef struct xc_hypercall_buffer xc_hy
 #undef set_xen_guest_handle
 #define set_xen_guest_handle(_hnd, _val)                                         \
     do {                                                                         \
-        xc_hypercall_buffer_t _val1;                                             \
-        typeof(XC__HYPERCALL_BUFFER_NAME(_val)) *_val2 = HYPERCALL_BUFFER(_val); \
-        (void) (&_val1 == _val2);                                                 \
-        set_xen_guest_handle_raw(_hnd, (_val2)->hbuf);                           \
+        xc_hypercall_buffer_t _bufhnd1;                                             \
+        typeof(XC__HYPERCALL_BUFFER_NAME(_val)) *_bufhnd2 = HYPERCALL_BUFFER(_val); \
+        (void) (&_bufhnd1 == _bufhnd2);                                                 \
+        set_xen_guest_handle_raw(_hnd, (_bufhnd2)->hbuf);                           \
     } while (0)
 
 /* Use with set_xen_guest_handle in place of NULL */
diff -r 0547430886c5 -r 58ab3fb73d13 tools/libxl/Makefile
--- a/tools/libxl/Makefile	Fri Sep 14 11:00:40 2012 +0100
+++ b/tools/libxl/Makefile	Fri Sep 14 12:09:43 2012 +0100
@@ -22,6 +22,12 @@ endif
 LIBXL_LIBS =
 LIBXL_LIBS = $(LDLIBS_libxenctrl) $(LDLIBS_libxenguest) $(LDLIBS_libxenstore) $(LDLIBS_libblktapctl) $(PTYFUNCS_LIBS) $(LIBUUID_LIBS)
 
+CFLAGS_LIBXL += $(CFLAGS_libxenctrl)
+CFLAGS_LIBXL += $(CFLAGS_libxenguest)
+CFLAGS_LIBXL += $(CFLAGS_libxenstore)
+CFLAGS_LIBXL += $(CFLAGS_libblktapctl) 
+CFLAGS_LIBXL += -Wshadow
+
 CFLAGS += $(PTHREAD_CFLAGS)
 LDFLAGS += $(PTHREAD_LDFLAGS)
 LIBXL_LIBS += $(PTHREAD_LIBS)
@@ -71,7 +77,7 @@ LIBXL_OBJS = flexarray.o libxl.o libxl_c
 			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
+$(LIBXL_OBJS): CFLAGS += $(CFLAGS_LIBXL) -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
diff -r 0547430886c5 -r 58ab3fb73d13 tools/libxl/flexarray.c
--- a/tools/libxl/flexarray.c	Fri Sep 14 11:00:40 2012 +0100
+++ b/tools/libxl/flexarray.c	Fri Sep 14 12:09:43 2012 +0100
@@ -48,19 +48,19 @@ int flexarray_grow(flexarray_t *array, i
     return 0;
 }
 
-int flexarray_set(flexarray_t *array, unsigned int index, void *ptr)
+int flexarray_set(flexarray_t *array, unsigned int idx, void *ptr)
 {
-    if (index >= array->size) {
+    if (idx >= array->size) {
         int newsize;
         if (!array->autogrow)
             return 1;
-        newsize = (array->size * 2 < index) ? index + 1 : array->size * 2;
+        newsize = (array->size * 2 < idx) ? idx + 1 : array->size * 2;
         if (flexarray_grow(array, newsize - array->size))
             return 2;
     }
-    if ( index + 1 > array->count )
-        array->count = index + 1;
-    array->data[index] = ptr;
+    if ( idx + 1 > array->count )
+        array->count = idx + 1;
+    array->data[idx] = ptr;
     return 0;
 }
 
@@ -92,11 +92,11 @@ int flexarray_vappend(flexarray_t *array
     return ret;
 }
 
-int flexarray_get(flexarray_t *array, int index, void **ptr)
+int flexarray_get(flexarray_t *array, int idx, void **ptr)
 {
-    if (index >= array->size)
+    if (idx >= array->size)
         return 1;
-    *ptr = array->data[index];
+    *ptr = array->data[idx];
     return 0;
 }
 
diff -r 0547430886c5 -r 58ab3fb73d13 tools/libxl/libxl.c
--- a/tools/libxl/libxl.c	Fri Sep 14 11:00:40 2012 +0100
+++ b/tools/libxl/libxl.c	Fri Sep 14 12:09:43 2012 +0100
@@ -665,7 +665,7 @@ out:
 libxl_vminfo * libxl_list_vm(libxl_ctx *ctx, int *nb_vm_out)
 {
     libxl_vminfo *ptr;
-    int index, i, ret;
+    int idx, i, ret;
     xc_domaininfo_t info[1024];
     int size = 1024;
 
@@ -678,15 +678,15 @@ libxl_vminfo * libxl_list_vm(libxl_ctx *
         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "geting domain info list");
         return NULL;
     }
-    for (index = i = 0; i < ret; i++) {
+    for (idx = i = 0; i < ret; i++) {
         if (libxl_is_stubdom(ctx, info[i].domain, NULL))
             continue;
-        memcpy(&(ptr[index].uuid), info[i].handle, sizeof(xen_domain_handle_t));
-        ptr[index].domid = info[i].domain;
-
-        index++;
-    }
-    *nb_vm_out = index;
+        memcpy(&(ptr[idx].uuid), info[i].handle, sizeof(xen_domain_handle_t));
+        ptr[idx].domid = info[i].domain;
+
+        idx++;
+    }
+    *nb_vm_out = idx;
     return ptr;
 }
 
@@ -3354,7 +3354,7 @@ int libxl_set_memory_target(libxl_ctx *c
         int32_t target_memkb, int relative, int enforce)
 {
     GC_INIT(ctx);
-    int rc = 1, abort = 0;
+    int rc = 1, abort_transaction = 0;
     uint32_t memorykb = 0, videoram = 0;
     uint32_t current_target_memkb = 0, new_target_memkb = 0;
     char *memmax, *endptr, *videoram_s = NULL, *target = NULL;
@@ -3373,7 +3373,7 @@ retry_transaction:
         xs_transaction_end(ctx->xsh, t, 1);
         rc = libxl__fill_dom0_memory_info(gc, &current_target_memkb);
         if (rc < 0) {
-            abort = 1;
+            abort_transaction = 1;
             goto out;
         }
         goto retry_transaction;
@@ -3381,7 +3381,7 @@ retry_transaction:
         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR,
                 "cannot get target memory info from %s/memory/target\n",
                 dompath);
-        abort = 1;
+        abort_transaction = 1;
         goto out;
     } else {
         current_target_memkb = strtoul(target, &endptr, 10);
@@ -3389,7 +3389,7 @@ retry_transaction:
             LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR,
                     "invalid memory target %s from %s/memory/target\n",
                     target, dompath);
-            abort = 1;
+            abort_transaction = 1;
             goto out;
         }
     }
@@ -3399,7 +3399,7 @@ retry_transaction:
         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR,
                 "cannot get memory info from %s/memory/static-max\n",
                 dompath);
-        abort = 1;
+        abort_transaction = 1;
         goto out;
     }
     memorykb = strtoul(memmax, &endptr, 10);
@@ -3407,7 +3407,7 @@ retry_transaction:
         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR,
                 "invalid max memory %s from %s/memory/static-max\n",
                 memmax, dompath);
-        abort = 1;
+        abort_transaction = 1;
         goto out;
     }
 
@@ -3422,7 +3422,7 @@ retry_transaction:
         LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
                 "memory_dynamic_max must be less than or equal to"
                 " memory_static_max\n");
-        abort = 1;
+        abort_transaction = 1;
         goto out;
     }
 
@@ -3430,7 +3430,7 @@ retry_transaction:
         LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
                 "new target %d for dom0 is below the minimum threshold\n",
                  new_target_memkb);
-        abort = 1;
+        abort_transaction = 1;
         goto out;
     }
     videoram_s = libxl__xs_read(gc, t, libxl__sprintf(gc,
@@ -3445,7 +3445,7 @@ retry_transaction:
             LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR,
                     "xc_domain_setmaxmem domid=%d memkb=%d failed "
                     "rc=%d\n", domid, memorykb + LIBXL_MAXMEM_CONSTANT, rc);
-            abort = 1;
+            abort_transaction = 1;
             goto out;
         }
     }
@@ -3458,7 +3458,7 @@ retry_transaction:
                 "xc_domain_set_pod_target domid=%d, memkb=%d "
                 "failed rc=%d\n", domid, new_target_memkb / 4,
                 rc);
-        abort = 1;
+        abort_transaction = 1;
         goto out;
     }
 
@@ -3466,7 +3466,7 @@ retry_transaction:
                 dompath), "%"PRIu32, new_target_memkb);
     rc = xc_domain_getinfolist(ctx->xch, domid, 1, &info);
     if (rc != 1 || info.domain != domid) {
-        abort = 1;
+        abort_transaction = 1;
         goto out;
     }
     xcinfo2xlinfo(&info, &ptr);
@@ -3475,7 +3475,8 @@ retry_transaction:
             "%"PRIu32, new_target_memkb / 1024);
 
 out:
-    if (!xs_transaction_end(ctx->xsh, t, abort) && !abort)
+    if (!xs_transaction_end(ctx->xsh, t, abort_transaction)
+        && !abort_transaction)
         if (errno == EAGAIN)
             goto retry_transaction;
 
diff -r 0547430886c5 -r 58ab3fb73d13 tools/libxl/libxl_dm.c
--- a/tools/libxl/libxl_dm.c	Fri Sep 14 11:00:40 2012 +0100
+++ b/tools/libxl/libxl_dm.c	Fri Sep 14 12:09:43 2012 +0100
@@ -379,7 +379,7 @@ static char ** libxl__build_device_model
     }
     if (vnc) {
         int display = 0;
-        const char *listen = "127.0.0.1";
+        const char *addr = "127.0.0.1";
         char *vncarg = NULL;
 
         flexarray_append(dm_args, "-vnc");
@@ -387,16 +387,16 @@ static char ** libxl__build_device_model
         if (vnc->display) {
             display = vnc->display;
             if (vnc->listen && strchr(vnc->listen, ':') == NULL) {
-                listen = vnc->listen;
+                addr = vnc->listen;
             }
         } else if (vnc->listen) {
-            listen = vnc->listen;
+            addr = vnc->listen;
         }
 
-        if (strchr(listen, ':') != NULL)
-            vncarg = libxl__sprintf(gc, "%s", listen);
+        if (strchr(addr, ':') != NULL)
+            vncarg = libxl__sprintf(gc, "%s", addr);
         else
-            vncarg = libxl__sprintf(gc, "%s:%d", listen, display);
+            vncarg = libxl__sprintf(gc, "%s:%d", addr, display);
         if (vnc->passwd && vnc->passwd[0]) {
             vncarg = libxl__sprintf(gc, "%s,password", vncarg);
         }
diff -r 0547430886c5 -r 58ab3fb73d13 tools/libxl/libxl_event.c
--- a/tools/libxl/libxl_event.c	Fri Sep 14 11:00:40 2012 +0100
+++ b/tools/libxl/libxl_event.c	Fri Sep 14 12:09:43 2012 +0100
@@ -167,15 +167,15 @@ static void time_insert_finite(libxl__gc
 }
 
 static int time_register_finite(libxl__gc *gc, libxl__ev_time *ev,
-                                struct timeval abs)
+                                struct timeval absolute)
 {
     int rc;
 
-    rc = OSEVENT_HOOK(timeout_register, &ev->for_app_reg, abs, ev);
+    rc = OSEVENT_HOOK(timeout_register, &ev->for_app_reg, absolute, ev);
     if (rc) return rc;
 
     ev->infinite = 0;
-    ev->abs = abs;
+    ev->abs = absolute;
     time_insert_finite(gc, ev);
 
     return 0;
@@ -202,16 +202,16 @@ static void time_done_debug(libxl__gc *g
 
 int libxl__ev_time_register_abs(libxl__gc *gc, libxl__ev_time *ev,
                                 libxl__ev_time_callback *func,
-                                struct timeval abs)
+                                struct timeval absolute)
 {
     int rc;
 
     CTX_LOCK;
 
     DBG("ev_time=%p register abs=%lu.%06lu",
-        ev, (unsigned long)abs.tv_sec, (unsigned long)abs.tv_usec);
+        ev, (unsigned long)absolute.tv_sec, (unsigned long)absolute.tv_usec);
 
-    rc = time_register_finite(gc, ev, abs);
+    rc = time_register_finite(gc, ev, absolute);
     if (rc) goto out;
 
     ev->func = func;
@@ -228,7 +228,7 @@ int libxl__ev_time_register_rel(libxl__g
                                 libxl__ev_time_callback *func,
                                 int milliseconds /* as for poll(2) */)
 {
-    struct timeval abs;
+    struct timeval absolute;
     int rc;
 
     CTX_LOCK;
@@ -238,10 +238,10 @@ int libxl__ev_time_register_rel(libxl__g
     if (milliseconds < 0) {
         ev->infinite = 1;
     } else {
-        rc = time_rel_to_abs(gc, milliseconds, &abs);
+        rc = time_rel_to_abs(gc, milliseconds, &absolute);
         if (rc) goto out;
 
-        rc = time_register_finite(gc, ev, abs);
+        rc = time_register_finite(gc, ev, absolute);
         if (rc) goto out;
     }
 
@@ -255,26 +255,26 @@ int libxl__ev_time_register_rel(libxl__g
 }
 
 int libxl__ev_time_modify_abs(libxl__gc *gc, libxl__ev_time *ev,
-                              struct timeval abs)
+                              struct timeval absolute)
 {
     int rc;
 
     CTX_LOCK;
 
     DBG("ev_time=%p modify abs==%lu.%06lu",
-        ev, (unsigned long)abs.tv_sec, (unsigned long)abs.tv_usec);
+        ev, (unsigned long)absolute.tv_sec, (unsigned long)absolute.tv_usec);
 
     assert(libxl__ev_time_isregistered(ev));
 
     if (ev->infinite) {
-        rc = time_register_finite(gc, ev, abs);
+        rc = time_register_finite(gc, ev, absolute);
         if (rc) goto out;
     } else {
-        rc = OSEVENT_HOOK(timeout_modify, &ev->for_app_reg, abs);
+        rc = OSEVENT_HOOK(timeout_modify, &ev->for_app_reg, absolute);
         if (rc) goto out;
 
         LIBXL_TAILQ_REMOVE(&CTX->etimes, ev, entry);
-        ev->abs = abs;
+        ev->abs = absolute;
         time_insert_finite(gc, ev);
     }
 
@@ -288,7 +288,7 @@ int libxl__ev_time_modify_abs(libxl__gc 
 int libxl__ev_time_modify_rel(libxl__gc *gc, libxl__ev_time *ev,
                               int milliseconds)
 {
-    struct timeval abs;
+    struct timeval absolute;
     int rc;
 
     CTX_LOCK;
@@ -304,10 +304,10 @@ int libxl__ev_time_modify_rel(libxl__gc 
         goto out;
     }
 
-    rc = time_rel_to_abs(gc, milliseconds, &abs);
+    rc = time_rel_to_abs(gc, milliseconds, &absolute);
     if (rc) goto out;
 
-    rc = libxl__ev_time_modify_abs(gc, ev, abs);
+    rc = libxl__ev_time_modify_abs(gc, ev, absolute);
     if (rc) goto out;
 
     rc = 0;
diff -r 0547430886c5 -r 58ab3fb73d13 tools/libxl/libxl_exec.c
--- a/tools/libxl/libxl_exec.c	Fri Sep 14 11:00:40 2012 +0100
+++ b/tools/libxl/libxl_exec.c	Fri Sep 14 12:09:43 2012 +0100
@@ -35,7 +35,7 @@ static void check_open_fds(const char *w
 #ifdef __linux__
         size_t len;
         char path[PATH_MAX];
-        char link[PATH_MAX+1];
+        char linkpath[PATH_MAX+1];
 #endif
         flags = fcntl(i, F_GETFD);
         if ( flags == -1 ) {
@@ -52,11 +52,11 @@ static void check_open_fds(const char *w
 
 #ifdef __linux__
         snprintf(path, PATH_MAX, "/proc/%d/fd/%d", getpid(), i);
-        len = readlink(path, link, PATH_MAX);
+        len = readlink(path, linkpath, PATH_MAX);
         if (len > 0) {
-            link[len] = '\0';
+            linkpath[len] = '\0';
             fprintf(stderr, "libxl: execing %s: fd %d is open to %s with flags %#x\n",
-                    what, i, link, flags);
+                    what, i, linkpath, flags);
         } else
 #endif
             fprintf(stderr, "libxl: execing %s: fd %d is open with flags %#x\n",
diff -r 0547430886c5 -r 58ab3fb73d13 tools/libxl/libxl_json.c
--- a/tools/libxl/libxl_json.c	Fri Sep 14 11:00:40 2012 +0100
+++ b/tools/libxl/libxl_json.c	Fri Sep 14 12:09:43 2012 +0100
@@ -275,7 +275,7 @@ static int json_object_append_to(libxl__
 
 void libxl__json_object_free(libxl__gc *gc, libxl__json_object *obj)
 {
-    int index = 0;
+    int idx = 0;
 
     if (obj == NULL)
         return;
@@ -287,8 +287,8 @@ void libxl__json_object_free(libxl__gc *
     case JSON_MAP: {
         libxl__json_map_node *node = NULL;
 
-        for (index = 0; index < obj->u.map->count; index++) {
-            if (flexarray_get(obj->u.map, index, (void**)&node) != 0)
+        for (idx = 0; idx < obj->u.map->count; idx++) {
+            if (flexarray_get(obj->u.map, idx, (void**)&node) != 0)
                 break;
             libxl__json_object_free(gc, node->obj);
             free(node->map_key);
@@ -302,8 +302,8 @@ void libxl__json_object_free(libxl__gc *
         libxl__json_object *node = NULL;
         break;
 
-        for (index = 0; index < obj->u.array->count; index++) {
-            if (flexarray_get(obj->u.array, index, (void**)&node) != 0)
+        for (idx = 0; idx < obj->u.array->count; idx++) {
+            if (flexarray_get(obj->u.array, idx, (void**)&node) != 0)
                 break;
             libxl__json_object_free(gc, node);
             node = NULL;
@@ -359,14 +359,14 @@ const libxl__json_object *libxl__json_ma
                                           libxl__json_node_type expected_type)
 {
     flexarray_t *maps = NULL;
-    int index = 0;
+    int idx = 0;
 
     if (libxl__json_object_is_map(o)) {
         libxl__json_map_node *node = NULL;
 
         maps = o->u.map;
-        for (index = 0; index < maps->count; index++) {
-            if (flexarray_get(maps, index, (void**)&node) != 0)
+        for (idx = 0; idx < maps->count; idx++) {
+            if (flexarray_get(maps, idx, (void**)&node) != 0)
                 return NULL;
             if (strcmp(key, node->map_key) == 0) {
                 if (expected_type == JSON_ANY
diff -r 0547430886c5 -r 58ab3fb73d13 tools/libxl/libxl_pci.c
--- a/tools/libxl/libxl_pci.c	Fri Sep 14 11:00:40 2012 +0100
+++ b/tools/libxl/libxl_pci.c	Fri Sep 14 12:09:43 2012 +0100
@@ -167,7 +167,6 @@ static int libxl__device_pci_remove_xens
     char *be_path, *num_devs_path, *num_devs, *xsdev, *tmp, *tmppath;
     int num, i, j;
     xs_transaction_t t;
-    unsigned int domain = 0, bus = 0, dev = 0, func = 0;
 
     be_path = libxl__sprintf(gc, "%s/backend/pci/%d/0", libxl__xs_get_dompath(gc, 0), domid);
     num_devs_path = libxl__sprintf(gc, "%s/num_devs", be_path);
@@ -188,6 +187,7 @@ static int libxl__device_pci_remove_xens
     }
 
     for (i = 0; i < num; i++) {
+        unsigned int domain = 0, bus = 0, dev = 0, func = 0;
         xsdev = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/dev-%d", be_path, i));
         sscanf(xsdev, PCI_BDF, &domain, &bus, &dev, &func);
         if (domain == pcidev->domain && bus == pcidev->bus &&
diff -r 0547430886c5 -r 58ab3fb73d13 tools/libxl/libxl_qmp.c
--- a/tools/libxl/libxl_qmp.c	Fri Sep 14 11:00:40 2012 +0100
+++ b/tools/libxl/libxl_qmp.c	Fri Sep 14 12:09:43 2012 +0100
@@ -171,7 +171,7 @@ static int qmp_register_vnc_callback(lib
 {
     GC_INIT(qmp->ctx);
     const libxl__json_object *obj;
-    const char *listen, *port;
+    const char *addr, *port;
     int rc = -1;
 
     if (!libxl__json_object_is_map(o)) {
@@ -184,17 +184,17 @@ static int qmp_register_vnc_callback(lib
     }
 
     obj = libxl__json_map_get("host", o, JSON_STRING);
-    listen = libxl__json_object_get_string(obj);
+    addr = libxl__json_object_get_string(obj);
     obj = libxl__json_map_get("service", o, JSON_STRING);
     port = libxl__json_object_get_string(obj);
 
-    if (!listen || !port) {
+    if (!addr || !port) {
         LIBXL__LOG(qmp->ctx, LIBXL__LOG_ERROR,
                    "Failed to retreive VNC connect information.");
         goto out;
     }
 
-    rc = qmp_write_domain_console_item(gc, qmp->domid, "vnc-listen", listen);
+    rc = qmp_write_domain_console_item(gc, qmp->domid, "vnc-listen", addr);
     if (!rc)
         rc = qmp_write_domain_console_item(gc, qmp->domid, "vnc-port", port);
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 14 11:14:19 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 11:14:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TCTqZ-0005Jw-9e; Fri, 14 Sep 2012 11:14:07 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1TCTqX-0005J1-PH
	for xen-devel@lists.xensource.com; Fri, 14 Sep 2012 11:14:06 +0000
Received: from [85.158.139.83:30469] by server-2.bemta-5.messagelabs.com id
	43/68-11456-C7113505; Fri, 14 Sep 2012 11:14:04 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1347621241!30333207!3
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNjk2MTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10773 invoked from network); 14 Sep 2012 11:14:04 -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 Sep 2012 11:14:04 -0000
X-IronPort-AV: E=Sophos;i="4.80,422,1344211200"; d="scan'208";a="37873000"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Sep 2012 11:14:01 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Fri, 14 Sep 2012 07:13:59 -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 1TCTqN-0005wt-4E;
	Fri, 14 Sep 2012 12:13:55 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: <arnd@arndb.de>
Date: Fri, 14 Sep 2012 12:13:03 +0100
Message-ID: <1347621207-11294-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.1209141145150.29232@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1209141145150.29232@kaball.uk.xensource.com>
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com, linaro-dev@lists.linaro.org,
	Ian.Campbell@citrix.com, konrad.wilk@oracle.com, catalin.marinas@arm.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	tim@xen.org, linux-kernel@vger.kernel.org,
	linux@arm.linux.org.uk, linux-arm-kernel@lists.infradead.org
Subject: [Xen-devel] [PATCH v4 01/24] arm: initial Xen 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

- Basic hypervisor.h and interface.h definitions.
- Skeleton enlighten.c, set xen_start_info to an empty struct.
- Make xen_initial_domain dependent on the SIF_PRIVILIGED_BIT.

The new code only compiles when CONFIG_XEN is set, that is going to be
added to arch/arm/Kconfig in patch #11 "xen/arm: introduce CONFIG_XEN on
ARM".

Changes in v3:

- improve comments.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 arch/arm/Makefile                     |    1 +
 arch/arm/include/asm/hypervisor.h     |    6 +++
 arch/arm/include/asm/xen/hypervisor.h |   19 ++++++++++
 arch/arm/include/asm/xen/interface.h  |   65 +++++++++++++++++++++++++++++++++
 arch/arm/xen/Makefile                 |    1 +
 arch/arm/xen/enlighten.c              |   35 ++++++++++++++++++
 include/xen/xen.h                     |    2 +-
 7 files changed, 128 insertions(+), 1 deletions(-)
 create mode 100644 arch/arm/include/asm/hypervisor.h
 create mode 100644 arch/arm/include/asm/xen/hypervisor.h
 create mode 100644 arch/arm/include/asm/xen/interface.h
 create mode 100644 arch/arm/xen/Makefile
 create mode 100644 arch/arm/xen/enlighten.c

diff --git a/arch/arm/Makefile b/arch/arm/Makefile
index 30eae87..f42968a 100644
--- a/arch/arm/Makefile
+++ b/arch/arm/Makefile
@@ -251,6 +251,7 @@ endif
 core-$(CONFIG_FPE_NWFPE)	+= arch/arm/nwfpe/
 core-$(CONFIG_FPE_FASTFPE)	+= $(FASTFPE_OBJ)
 core-$(CONFIG_VFP)		+= arch/arm/vfp/
+core-$(CONFIG_XEN)		+= arch/arm/xen/
 
 # If we have a machine-specific directory, then include it in the build.
 core-y				+= arch/arm/kernel/ arch/arm/mm/ arch/arm/common/
diff --git a/arch/arm/include/asm/hypervisor.h b/arch/arm/include/asm/hypervisor.h
new file mode 100644
index 0000000..b90d9e5
--- /dev/null
+++ b/arch/arm/include/asm/hypervisor.h
@@ -0,0 +1,6 @@
+#ifndef _ASM_ARM_HYPERVISOR_H
+#define _ASM_ARM_HYPERVISOR_H
+
+#include <asm/xen/hypervisor.h>
+
+#endif
diff --git a/arch/arm/include/asm/xen/hypervisor.h b/arch/arm/include/asm/xen/hypervisor.h
new file mode 100644
index 0000000..d7ab99a
--- /dev/null
+++ b/arch/arm/include/asm/xen/hypervisor.h
@@ -0,0 +1,19 @@
+#ifndef _ASM_ARM_XEN_HYPERVISOR_H
+#define _ASM_ARM_XEN_HYPERVISOR_H
+
+extern struct shared_info *HYPERVISOR_shared_info;
+extern struct start_info *xen_start_info;
+
+/* Lazy mode for batching updates / context switch */
+enum paravirt_lazy_mode {
+	PARAVIRT_LAZY_NONE,
+	PARAVIRT_LAZY_MMU,
+	PARAVIRT_LAZY_CPU,
+};
+
+static inline enum paravirt_lazy_mode paravirt_get_lazy_mode(void)
+{
+	return PARAVIRT_LAZY_NONE;
+}
+
+#endif /* _ASM_ARM_XEN_HYPERVISOR_H */
diff --git a/arch/arm/include/asm/xen/interface.h b/arch/arm/include/asm/xen/interface.h
new file mode 100644
index 0000000..9e0ec5a
--- /dev/null
+++ b/arch/arm/include/asm/xen/interface.h
@@ -0,0 +1,65 @@
+/******************************************************************************
+ * Guest OS interface to ARM Xen.
+ *
+ * Stefano Stabellini <stefano.stabellini@eu.citrix.com>, Citrix, 2012
+ */
+
+#ifndef _ASM_ARM_XEN_INTERFACE_H
+#define _ASM_ARM_XEN_INTERFACE_H
+
+#include <linux/types.h>
+
+#define __DEFINE_GUEST_HANDLE(name, type) \
+	typedef type * __guest_handle_ ## name
+
+#define DEFINE_GUEST_HANDLE_STRUCT(name) \
+	__DEFINE_GUEST_HANDLE(name, struct name)
+#define DEFINE_GUEST_HANDLE(name) __DEFINE_GUEST_HANDLE(name, name)
+#define GUEST_HANDLE(name)        __guest_handle_ ## name
+
+#define set_xen_guest_handle(hnd, val)			\
+	do {						\
+		if (sizeof(hnd) == 8)			\
+			*(uint64_t *)&(hnd) = 0;	\
+		(hnd) = val;				\
+	} while (0)
+
+#ifndef __ASSEMBLY__
+/* Guest handles for primitive C types. */
+__DEFINE_GUEST_HANDLE(uchar, unsigned char);
+__DEFINE_GUEST_HANDLE(uint,  unsigned int);
+__DEFINE_GUEST_HANDLE(ulong, unsigned long);
+DEFINE_GUEST_HANDLE(char);
+DEFINE_GUEST_HANDLE(int);
+DEFINE_GUEST_HANDLE(long);
+DEFINE_GUEST_HANDLE(void);
+DEFINE_GUEST_HANDLE(uint64_t);
+DEFINE_GUEST_HANDLE(uint32_t);
+
+/* Maximum number of virtual CPUs in multi-processor guests. */
+#define MAX_VIRT_CPUS 1
+
+struct arch_vcpu_info { };
+struct arch_shared_info { };
+
+/* TODO: Move pvclock definitions some place arch independent */
+struct pvclock_vcpu_time_info {
+	u32   version;
+	u32   pad0;
+	u64   tsc_timestamp;
+	u64   system_time;
+	u32   tsc_to_system_mul;
+	s8    tsc_shift;
+	u8    flags;
+	u8    pad[2];
+} __attribute__((__packed__)); /* 32 bytes */
+
+/* It is OK to have a 12 bytes struct with no padding because it is packed */
+struct pvclock_wall_clock {
+	u32   version;
+	u32   sec;
+	u32   nsec;
+} __attribute__((__packed__));
+#endif
+
+#endif /* _ASM_ARM_XEN_INTERFACE_H */
diff --git a/arch/arm/xen/Makefile b/arch/arm/xen/Makefile
new file mode 100644
index 0000000..0bad594
--- /dev/null
+++ b/arch/arm/xen/Makefile
@@ -0,0 +1 @@
+obj-y		:= enlighten.o
diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
new file mode 100644
index 0000000..c535540
--- /dev/null
+++ b/arch/arm/xen/enlighten.c
@@ -0,0 +1,35 @@
+#include <xen/xen.h>
+#include <xen/interface/xen.h>
+#include <xen/interface/memory.h>
+#include <xen/platform_pci.h>
+#include <asm/xen/hypervisor.h>
+#include <asm/xen/hypercall.h>
+#include <linux/module.h>
+
+struct start_info _xen_start_info;
+struct start_info *xen_start_info = &_xen_start_info;
+EXPORT_SYMBOL_GPL(xen_start_info);
+
+enum xen_domain_type xen_domain_type = XEN_NATIVE;
+EXPORT_SYMBOL_GPL(xen_domain_type);
+
+struct shared_info xen_dummy_shared_info;
+struct shared_info *HYPERVISOR_shared_info = (void *)&xen_dummy_shared_info;
+
+DEFINE_PER_CPU(struct vcpu_info *, xen_vcpu);
+
+/* TODO: to be removed */
+__read_mostly int xen_have_vector_callback;
+EXPORT_SYMBOL_GPL(xen_have_vector_callback);
+
+int xen_platform_pci_unplug = XEN_UNPLUG_ALL;
+EXPORT_SYMBOL_GPL(xen_platform_pci_unplug);
+
+int xen_remap_domain_mfn_range(struct vm_area_struct *vma,
+			       unsigned long addr,
+			       unsigned long mfn, int nr,
+			       pgprot_t prot, unsigned domid)
+{
+	return -ENOSYS;
+}
+EXPORT_SYMBOL_GPL(xen_remap_domain_mfn_range);
diff --git a/include/xen/xen.h b/include/xen/xen.h
index a164024..2c0d3a5 100644
--- a/include/xen/xen.h
+++ b/include/xen/xen.h
@@ -23,7 +23,7 @@ extern enum xen_domain_type xen_domain_type;
 #include <xen/interface/xen.h>
 #include <asm/xen/hypervisor.h>
 
-#define xen_initial_domain()	(xen_pv_domain() && \
+#define xen_initial_domain()	(xen_domain() && \
 				 xen_start_info->flags & SIF_INITDOMAIN)
 #else  /* !CONFIG_XEN_DOM0 */
 #define xen_initial_domain()	(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 Sep 14 11:14:19 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 11:14:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TCTqZ-0005Jw-9e; Fri, 14 Sep 2012 11:14:07 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1TCTqX-0005J1-PH
	for xen-devel@lists.xensource.com; Fri, 14 Sep 2012 11:14:06 +0000
Received: from [85.158.139.83:30469] by server-2.bemta-5.messagelabs.com id
	43/68-11456-C7113505; Fri, 14 Sep 2012 11:14:04 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1347621241!30333207!3
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNjk2MTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10773 invoked from network); 14 Sep 2012 11:14:04 -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 Sep 2012 11:14:04 -0000
X-IronPort-AV: E=Sophos;i="4.80,422,1344211200"; d="scan'208";a="37873000"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Sep 2012 11:14:01 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Fri, 14 Sep 2012 07:13:59 -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 1TCTqN-0005wt-4E;
	Fri, 14 Sep 2012 12:13:55 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: <arnd@arndb.de>
Date: Fri, 14 Sep 2012 12:13:03 +0100
Message-ID: <1347621207-11294-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.1209141145150.29232@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1209141145150.29232@kaball.uk.xensource.com>
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com, linaro-dev@lists.linaro.org,
	Ian.Campbell@citrix.com, konrad.wilk@oracle.com, catalin.marinas@arm.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	tim@xen.org, linux-kernel@vger.kernel.org,
	linux@arm.linux.org.uk, linux-arm-kernel@lists.infradead.org
Subject: [Xen-devel] [PATCH v4 01/24] arm: initial Xen 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

- Basic hypervisor.h and interface.h definitions.
- Skeleton enlighten.c, set xen_start_info to an empty struct.
- Make xen_initial_domain dependent on the SIF_PRIVILIGED_BIT.

The new code only compiles when CONFIG_XEN is set, that is going to be
added to arch/arm/Kconfig in patch #11 "xen/arm: introduce CONFIG_XEN on
ARM".

Changes in v3:

- improve comments.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 arch/arm/Makefile                     |    1 +
 arch/arm/include/asm/hypervisor.h     |    6 +++
 arch/arm/include/asm/xen/hypervisor.h |   19 ++++++++++
 arch/arm/include/asm/xen/interface.h  |   65 +++++++++++++++++++++++++++++++++
 arch/arm/xen/Makefile                 |    1 +
 arch/arm/xen/enlighten.c              |   35 ++++++++++++++++++
 include/xen/xen.h                     |    2 +-
 7 files changed, 128 insertions(+), 1 deletions(-)
 create mode 100644 arch/arm/include/asm/hypervisor.h
 create mode 100644 arch/arm/include/asm/xen/hypervisor.h
 create mode 100644 arch/arm/include/asm/xen/interface.h
 create mode 100644 arch/arm/xen/Makefile
 create mode 100644 arch/arm/xen/enlighten.c

diff --git a/arch/arm/Makefile b/arch/arm/Makefile
index 30eae87..f42968a 100644
--- a/arch/arm/Makefile
+++ b/arch/arm/Makefile
@@ -251,6 +251,7 @@ endif
 core-$(CONFIG_FPE_NWFPE)	+= arch/arm/nwfpe/
 core-$(CONFIG_FPE_FASTFPE)	+= $(FASTFPE_OBJ)
 core-$(CONFIG_VFP)		+= arch/arm/vfp/
+core-$(CONFIG_XEN)		+= arch/arm/xen/
 
 # If we have a machine-specific directory, then include it in the build.
 core-y				+= arch/arm/kernel/ arch/arm/mm/ arch/arm/common/
diff --git a/arch/arm/include/asm/hypervisor.h b/arch/arm/include/asm/hypervisor.h
new file mode 100644
index 0000000..b90d9e5
--- /dev/null
+++ b/arch/arm/include/asm/hypervisor.h
@@ -0,0 +1,6 @@
+#ifndef _ASM_ARM_HYPERVISOR_H
+#define _ASM_ARM_HYPERVISOR_H
+
+#include <asm/xen/hypervisor.h>
+
+#endif
diff --git a/arch/arm/include/asm/xen/hypervisor.h b/arch/arm/include/asm/xen/hypervisor.h
new file mode 100644
index 0000000..d7ab99a
--- /dev/null
+++ b/arch/arm/include/asm/xen/hypervisor.h
@@ -0,0 +1,19 @@
+#ifndef _ASM_ARM_XEN_HYPERVISOR_H
+#define _ASM_ARM_XEN_HYPERVISOR_H
+
+extern struct shared_info *HYPERVISOR_shared_info;
+extern struct start_info *xen_start_info;
+
+/* Lazy mode for batching updates / context switch */
+enum paravirt_lazy_mode {
+	PARAVIRT_LAZY_NONE,
+	PARAVIRT_LAZY_MMU,
+	PARAVIRT_LAZY_CPU,
+};
+
+static inline enum paravirt_lazy_mode paravirt_get_lazy_mode(void)
+{
+	return PARAVIRT_LAZY_NONE;
+}
+
+#endif /* _ASM_ARM_XEN_HYPERVISOR_H */
diff --git a/arch/arm/include/asm/xen/interface.h b/arch/arm/include/asm/xen/interface.h
new file mode 100644
index 0000000..9e0ec5a
--- /dev/null
+++ b/arch/arm/include/asm/xen/interface.h
@@ -0,0 +1,65 @@
+/******************************************************************************
+ * Guest OS interface to ARM Xen.
+ *
+ * Stefano Stabellini <stefano.stabellini@eu.citrix.com>, Citrix, 2012
+ */
+
+#ifndef _ASM_ARM_XEN_INTERFACE_H
+#define _ASM_ARM_XEN_INTERFACE_H
+
+#include <linux/types.h>
+
+#define __DEFINE_GUEST_HANDLE(name, type) \
+	typedef type * __guest_handle_ ## name
+
+#define DEFINE_GUEST_HANDLE_STRUCT(name) \
+	__DEFINE_GUEST_HANDLE(name, struct name)
+#define DEFINE_GUEST_HANDLE(name) __DEFINE_GUEST_HANDLE(name, name)
+#define GUEST_HANDLE(name)        __guest_handle_ ## name
+
+#define set_xen_guest_handle(hnd, val)			\
+	do {						\
+		if (sizeof(hnd) == 8)			\
+			*(uint64_t *)&(hnd) = 0;	\
+		(hnd) = val;				\
+	} while (0)
+
+#ifndef __ASSEMBLY__
+/* Guest handles for primitive C types. */
+__DEFINE_GUEST_HANDLE(uchar, unsigned char);
+__DEFINE_GUEST_HANDLE(uint,  unsigned int);
+__DEFINE_GUEST_HANDLE(ulong, unsigned long);
+DEFINE_GUEST_HANDLE(char);
+DEFINE_GUEST_HANDLE(int);
+DEFINE_GUEST_HANDLE(long);
+DEFINE_GUEST_HANDLE(void);
+DEFINE_GUEST_HANDLE(uint64_t);
+DEFINE_GUEST_HANDLE(uint32_t);
+
+/* Maximum number of virtual CPUs in multi-processor guests. */
+#define MAX_VIRT_CPUS 1
+
+struct arch_vcpu_info { };
+struct arch_shared_info { };
+
+/* TODO: Move pvclock definitions some place arch independent */
+struct pvclock_vcpu_time_info {
+	u32   version;
+	u32   pad0;
+	u64   tsc_timestamp;
+	u64   system_time;
+	u32   tsc_to_system_mul;
+	s8    tsc_shift;
+	u8    flags;
+	u8    pad[2];
+} __attribute__((__packed__)); /* 32 bytes */
+
+/* It is OK to have a 12 bytes struct with no padding because it is packed */
+struct pvclock_wall_clock {
+	u32   version;
+	u32   sec;
+	u32   nsec;
+} __attribute__((__packed__));
+#endif
+
+#endif /* _ASM_ARM_XEN_INTERFACE_H */
diff --git a/arch/arm/xen/Makefile b/arch/arm/xen/Makefile
new file mode 100644
index 0000000..0bad594
--- /dev/null
+++ b/arch/arm/xen/Makefile
@@ -0,0 +1 @@
+obj-y		:= enlighten.o
diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
new file mode 100644
index 0000000..c535540
--- /dev/null
+++ b/arch/arm/xen/enlighten.c
@@ -0,0 +1,35 @@
+#include <xen/xen.h>
+#include <xen/interface/xen.h>
+#include <xen/interface/memory.h>
+#include <xen/platform_pci.h>
+#include <asm/xen/hypervisor.h>
+#include <asm/xen/hypercall.h>
+#include <linux/module.h>
+
+struct start_info _xen_start_info;
+struct start_info *xen_start_info = &_xen_start_info;
+EXPORT_SYMBOL_GPL(xen_start_info);
+
+enum xen_domain_type xen_domain_type = XEN_NATIVE;
+EXPORT_SYMBOL_GPL(xen_domain_type);
+
+struct shared_info xen_dummy_shared_info;
+struct shared_info *HYPERVISOR_shared_info = (void *)&xen_dummy_shared_info;
+
+DEFINE_PER_CPU(struct vcpu_info *, xen_vcpu);
+
+/* TODO: to be removed */
+__read_mostly int xen_have_vector_callback;
+EXPORT_SYMBOL_GPL(xen_have_vector_callback);
+
+int xen_platform_pci_unplug = XEN_UNPLUG_ALL;
+EXPORT_SYMBOL_GPL(xen_platform_pci_unplug);
+
+int xen_remap_domain_mfn_range(struct vm_area_struct *vma,
+			       unsigned long addr,
+			       unsigned long mfn, int nr,
+			       pgprot_t prot, unsigned domid)
+{
+	return -ENOSYS;
+}
+EXPORT_SYMBOL_GPL(xen_remap_domain_mfn_range);
diff --git a/include/xen/xen.h b/include/xen/xen.h
index a164024..2c0d3a5 100644
--- a/include/xen/xen.h
+++ b/include/xen/xen.h
@@ -23,7 +23,7 @@ extern enum xen_domain_type xen_domain_type;
 #include <xen/interface/xen.h>
 #include <asm/xen/hypervisor.h>
 
-#define xen_initial_domain()	(xen_pv_domain() && \
+#define xen_initial_domain()	(xen_domain() && \
 				 xen_start_info->flags & SIF_INITDOMAIN)
 #else  /* !CONFIG_XEN_DOM0 */
 #define xen_initial_domain()	(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 Sep 14 11:14:20 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 11:14:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TCTqc-0005Lo-Fp; Fri, 14 Sep 2012 11:14:10 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1TCTqb-0005Jd-79
	for xen-devel@lists.xensource.com; Fri, 14 Sep 2012 11:14:09 +0000
Received: from [85.158.143.99:55920] by server-2.bemta-4.messagelabs.com id
	BF/8E-21239-08113505; Fri, 14 Sep 2012 11:14:08 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1347621246!20568152!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNjk2MTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24524 invoked from network); 14 Sep 2012 11:14:07 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-8.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Sep 2012 11:14:07 -0000
X-IronPort-AV: E=Sophos;i="4.80,422,1344211200"; d="scan'208";a="37873007"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Sep 2012 11:14:06 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Fri, 14 Sep 2012 07:14:05 -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 1TCTqN-0005wt-Ez;
	Fri, 14 Sep 2012 12:13:55 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: <arnd@arndb.de>
Date: Fri, 14 Sep 2012 12:13:12 +0100
Message-ID: <1347621207-11294-10-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <alpine.DEB.2.02.1209141145150.29232@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1209141145150.29232@kaball.uk.xensource.com>
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com, linaro-dev@lists.linaro.org,
	Ian.Campbell@citrix.com, konrad.wilk@oracle.com, catalin.marinas@arm.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	tim@xen.org, linux-kernel@vger.kernel.org,
	linux@arm.linux.org.uk, linux-arm-kernel@lists.infradead.org
Subject: [Xen-devel] [PATCH v4 10/24] xen/arm: compile and run xenbus
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

bind_evtchn_to_irqhandler can legitimately return 0 (irq 0): it is not
an error.

If Linux is running as an HVM domain and is running as Dom0, use
xenstored_local_init to initialize the xenstore page and event channel.


Changes in v4:

- do not xs_reset_watches on dom0.


Changes in v2:

- refactor xenbus_init.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 drivers/xen/xenbus/xenbus_comms.c |    2 +-
 drivers/xen/xenbus/xenbus_probe.c |   62 +++++++++++++++++++++++++-----------
 drivers/xen/xenbus/xenbus_xs.c    |    3 +-
 3 files changed, 46 insertions(+), 21 deletions(-)

diff --git a/drivers/xen/xenbus/xenbus_comms.c b/drivers/xen/xenbus/xenbus_comms.c
index 52fe7ad..c5aa55c 100644
--- a/drivers/xen/xenbus/xenbus_comms.c
+++ b/drivers/xen/xenbus/xenbus_comms.c
@@ -224,7 +224,7 @@ int xb_init_comms(void)
 		int err;
 		err = bind_evtchn_to_irqhandler(xen_store_evtchn, wake_waiting,
 						0, "xenbus", &xb_waitq);
-		if (err <= 0) {
+		if (err < 0) {
 			printk(KERN_ERR "XENBUS request irq failed %i\n", err);
 			return err;
 		}
diff --git a/drivers/xen/xenbus/xenbus_probe.c b/drivers/xen/xenbus/xenbus_probe.c
index b793723..a67ccc0 100644
--- a/drivers/xen/xenbus/xenbus_probe.c
+++ b/drivers/xen/xenbus/xenbus_probe.c
@@ -719,37 +719,61 @@ static int __init xenstored_local_init(void)
 	return err;
 }
 
+enum xenstore_init {
+	UNKNOWN,
+	PV,
+	HVM,
+	LOCAL,
+};
 static int __init xenbus_init(void)
 {
 	int err = 0;
+	enum xenstore_init usage = UNKNOWN;
+	uint64_t v = 0;
 
 	if (!xen_domain())
 		return -ENODEV;
 
 	xenbus_ring_ops_init();
 
-	if (xen_hvm_domain()) {
-		uint64_t v = 0;
-		err = hvm_get_parameter(HVM_PARAM_STORE_EVTCHN, &v);
-		if (err)
-			goto out_error;
-		xen_store_evtchn = (int)v;
-		err = hvm_get_parameter(HVM_PARAM_STORE_PFN, &v);
-		if (err)
-			goto out_error;
-		xen_store_mfn = (unsigned long)v;
-		xen_store_interface = ioremap(xen_store_mfn << PAGE_SHIFT, PAGE_SIZE);
-	} else {
-		xen_store_evtchn = xen_start_info->store_evtchn;
-		xen_store_mfn = xen_start_info->store_mfn;
-		if (xen_store_evtchn)
-			xenstored_ready = 1;
-		else {
+	if (xen_pv_domain())
+		usage = PV;
+	if (xen_hvm_domain())
+		usage = HVM;
+	if (xen_hvm_domain() && xen_initial_domain())
+		usage = LOCAL;
+	if (xen_pv_domain() && !xen_start_info->store_evtchn)
+		usage = LOCAL;
+	if (xen_pv_domain() && xen_start_info->store_evtchn)
+		xenstored_ready = 1;
+
+	switch (usage) {
+		case LOCAL:
 			err = xenstored_local_init();
 			if (err)
 				goto out_error;
-		}
-		xen_store_interface = mfn_to_virt(xen_store_mfn);
+			xen_store_interface = mfn_to_virt(xen_store_mfn);
+			break;
+		case PV:
+			xen_store_evtchn = xen_start_info->store_evtchn;
+			xen_store_mfn = xen_start_info->store_mfn;
+			xen_store_interface = mfn_to_virt(xen_store_mfn);
+			break;
+		case HVM:
+			err = hvm_get_parameter(HVM_PARAM_STORE_EVTCHN, &v);
+			if (err)
+				goto out_error;
+			xen_store_evtchn = (int)v;
+			err = hvm_get_parameter(HVM_PARAM_STORE_PFN, &v);
+			if (err)
+				goto out_error;
+			xen_store_mfn = (unsigned long)v;
+			xen_store_interface =
+				ioremap(xen_store_mfn << PAGE_SHIFT, PAGE_SIZE);
+			break;
+		default:
+			pr_warn("Xenstore state unknown\n");
+			break;
 	}
 
 	/* Initialize the interface to xenstore. */
diff --git a/drivers/xen/xenbus/xenbus_xs.c b/drivers/xen/xenbus/xenbus_xs.c
index bce15cf..131dec0 100644
--- a/drivers/xen/xenbus/xenbus_xs.c
+++ b/drivers/xen/xenbus/xenbus_xs.c
@@ -44,6 +44,7 @@
 #include <linux/rwsem.h>
 #include <linux/module.h>
 #include <linux/mutex.h>
+#include <asm/xen/hypervisor.h>
 #include <xen/xenbus.h>
 #include <xen/xen.h>
 #include "xenbus_comms.h"
@@ -622,7 +623,7 @@ static void xs_reset_watches(void)
 {
 	int err, supported = 0;
 
-	if (!xen_hvm_domain())
+	if (!xen_hvm_domain() || xen_initial_domain())
 		return;
 
 	err = xenbus_scanf(XBT_NIL, "control",
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 14 11:14:20 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 11:14:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TCTqc-0005Lo-Fp; Fri, 14 Sep 2012 11:14:10 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1TCTqb-0005Jd-79
	for xen-devel@lists.xensource.com; Fri, 14 Sep 2012 11:14:09 +0000
Received: from [85.158.143.99:55920] by server-2.bemta-4.messagelabs.com id
	BF/8E-21239-08113505; Fri, 14 Sep 2012 11:14:08 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1347621246!20568152!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNjk2MTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24524 invoked from network); 14 Sep 2012 11:14:07 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-8.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Sep 2012 11:14:07 -0000
X-IronPort-AV: E=Sophos;i="4.80,422,1344211200"; d="scan'208";a="37873007"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Sep 2012 11:14:06 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Fri, 14 Sep 2012 07:14:05 -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 1TCTqN-0005wt-Ez;
	Fri, 14 Sep 2012 12:13:55 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: <arnd@arndb.de>
Date: Fri, 14 Sep 2012 12:13:12 +0100
Message-ID: <1347621207-11294-10-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <alpine.DEB.2.02.1209141145150.29232@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1209141145150.29232@kaball.uk.xensource.com>
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com, linaro-dev@lists.linaro.org,
	Ian.Campbell@citrix.com, konrad.wilk@oracle.com, catalin.marinas@arm.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	tim@xen.org, linux-kernel@vger.kernel.org,
	linux@arm.linux.org.uk, linux-arm-kernel@lists.infradead.org
Subject: [Xen-devel] [PATCH v4 10/24] xen/arm: compile and run xenbus
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

bind_evtchn_to_irqhandler can legitimately return 0 (irq 0): it is not
an error.

If Linux is running as an HVM domain and is running as Dom0, use
xenstored_local_init to initialize the xenstore page and event channel.


Changes in v4:

- do not xs_reset_watches on dom0.


Changes in v2:

- refactor xenbus_init.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 drivers/xen/xenbus/xenbus_comms.c |    2 +-
 drivers/xen/xenbus/xenbus_probe.c |   62 +++++++++++++++++++++++++-----------
 drivers/xen/xenbus/xenbus_xs.c    |    3 +-
 3 files changed, 46 insertions(+), 21 deletions(-)

diff --git a/drivers/xen/xenbus/xenbus_comms.c b/drivers/xen/xenbus/xenbus_comms.c
index 52fe7ad..c5aa55c 100644
--- a/drivers/xen/xenbus/xenbus_comms.c
+++ b/drivers/xen/xenbus/xenbus_comms.c
@@ -224,7 +224,7 @@ int xb_init_comms(void)
 		int err;
 		err = bind_evtchn_to_irqhandler(xen_store_evtchn, wake_waiting,
 						0, "xenbus", &xb_waitq);
-		if (err <= 0) {
+		if (err < 0) {
 			printk(KERN_ERR "XENBUS request irq failed %i\n", err);
 			return err;
 		}
diff --git a/drivers/xen/xenbus/xenbus_probe.c b/drivers/xen/xenbus/xenbus_probe.c
index b793723..a67ccc0 100644
--- a/drivers/xen/xenbus/xenbus_probe.c
+++ b/drivers/xen/xenbus/xenbus_probe.c
@@ -719,37 +719,61 @@ static int __init xenstored_local_init(void)
 	return err;
 }
 
+enum xenstore_init {
+	UNKNOWN,
+	PV,
+	HVM,
+	LOCAL,
+};
 static int __init xenbus_init(void)
 {
 	int err = 0;
+	enum xenstore_init usage = UNKNOWN;
+	uint64_t v = 0;
 
 	if (!xen_domain())
 		return -ENODEV;
 
 	xenbus_ring_ops_init();
 
-	if (xen_hvm_domain()) {
-		uint64_t v = 0;
-		err = hvm_get_parameter(HVM_PARAM_STORE_EVTCHN, &v);
-		if (err)
-			goto out_error;
-		xen_store_evtchn = (int)v;
-		err = hvm_get_parameter(HVM_PARAM_STORE_PFN, &v);
-		if (err)
-			goto out_error;
-		xen_store_mfn = (unsigned long)v;
-		xen_store_interface = ioremap(xen_store_mfn << PAGE_SHIFT, PAGE_SIZE);
-	} else {
-		xen_store_evtchn = xen_start_info->store_evtchn;
-		xen_store_mfn = xen_start_info->store_mfn;
-		if (xen_store_evtchn)
-			xenstored_ready = 1;
-		else {
+	if (xen_pv_domain())
+		usage = PV;
+	if (xen_hvm_domain())
+		usage = HVM;
+	if (xen_hvm_domain() && xen_initial_domain())
+		usage = LOCAL;
+	if (xen_pv_domain() && !xen_start_info->store_evtchn)
+		usage = LOCAL;
+	if (xen_pv_domain() && xen_start_info->store_evtchn)
+		xenstored_ready = 1;
+
+	switch (usage) {
+		case LOCAL:
 			err = xenstored_local_init();
 			if (err)
 				goto out_error;
-		}
-		xen_store_interface = mfn_to_virt(xen_store_mfn);
+			xen_store_interface = mfn_to_virt(xen_store_mfn);
+			break;
+		case PV:
+			xen_store_evtchn = xen_start_info->store_evtchn;
+			xen_store_mfn = xen_start_info->store_mfn;
+			xen_store_interface = mfn_to_virt(xen_store_mfn);
+			break;
+		case HVM:
+			err = hvm_get_parameter(HVM_PARAM_STORE_EVTCHN, &v);
+			if (err)
+				goto out_error;
+			xen_store_evtchn = (int)v;
+			err = hvm_get_parameter(HVM_PARAM_STORE_PFN, &v);
+			if (err)
+				goto out_error;
+			xen_store_mfn = (unsigned long)v;
+			xen_store_interface =
+				ioremap(xen_store_mfn << PAGE_SHIFT, PAGE_SIZE);
+			break;
+		default:
+			pr_warn("Xenstore state unknown\n");
+			break;
 	}
 
 	/* Initialize the interface to xenstore. */
diff --git a/drivers/xen/xenbus/xenbus_xs.c b/drivers/xen/xenbus/xenbus_xs.c
index bce15cf..131dec0 100644
--- a/drivers/xen/xenbus/xenbus_xs.c
+++ b/drivers/xen/xenbus/xenbus_xs.c
@@ -44,6 +44,7 @@
 #include <linux/rwsem.h>
 #include <linux/module.h>
 #include <linux/mutex.h>
+#include <asm/xen/hypervisor.h>
 #include <xen/xenbus.h>
 #include <xen/xen.h>
 #include "xenbus_comms.h"
@@ -622,7 +623,7 @@ static void xs_reset_watches(void)
 {
 	int err, supported = 0;
 
-	if (!xen_hvm_domain())
+	if (!xen_hvm_domain() || xen_initial_domain())
 		return;
 
 	err = xenbus_scanf(XBT_NIL, "control",
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 14 11:14:20 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 11:14:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TCTqa-0005Ka-Fx; Fri, 14 Sep 2012 11:14:08 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1TCTqZ-0005Jd-1K
	for xen-devel@lists.xensource.com; Fri, 14 Sep 2012 11:14:07 +0000
Received: from [85.158.143.99:19343] by server-2.bemta-4.messagelabs.com id
	71/8E-21239-E7113505; Fri, 14 Sep 2012 11:14:06 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1347621243!30013120!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNjk2MTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15812 invoked from network); 14 Sep 2012 11:14:05 -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;
	14 Sep 2012 11:14:05 -0000
X-IronPort-AV: E=Sophos;i="4.80,422,1344211200"; d="scan'208";a="37873003"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Sep 2012 11:14:01 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Fri, 14 Sep 2012 07:14:00 -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 1TCTqN-0005wt-A1;
	Fri, 14 Sep 2012 12:13:55 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: <arnd@arndb.de>
Date: Fri, 14 Sep 2012 12:13:08 +0100
Message-ID: <1347621207-11294-6-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <alpine.DEB.2.02.1209141145150.29232@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1209141145150.29232@kaball.uk.xensource.com>
MIME-Version: 1.0
Cc: Dave Martin <dave.martin@linaro.org>, xen-devel@lists.xensource.com,
	linaro-dev@lists.linaro.org, Ian.Campbell@citrix.com,
	konrad.wilk@oracle.com, catalin.marinas@arm.com,
	devicetree-discuss@lists.ozlabs.org,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	tim@xen.org, linux-kernel@vger.kernel.org,
	Rob Herring <robherring2@gmail.com>,
	David Vrabel <david.vrabel@citrix.com>, linux@arm.linux.org.uk,
	linux-arm-kernel@lists.infradead.org
Subject: [Xen-devel] [PATCH v4 06/24] docs: Xen ARM DT bindings
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Add a doc to describe the Xen ARM device tree bindings


Changes in v4:

- "xen,xen" should be last as it is less specific;
- update reg property using 2 address-cells and 2 size-cells.


Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
CC: devicetree-discuss@lists.ozlabs.org
CC: David Vrabel <david.vrabel@citrix.com>
CC: Rob Herring <robherring2@gmail.com>
CC: Dave Martin <dave.martin@linaro.org>
---
 Documentation/devicetree/bindings/arm/xen.txt |   22 ++++++++++++++++++++++
 1 files changed, 22 insertions(+), 0 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/arm/xen.txt

diff --git a/Documentation/devicetree/bindings/arm/xen.txt b/Documentation/devicetree/bindings/arm/xen.txt
new file mode 100644
index 0000000..1f8f7d4
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/xen.txt
@@ -0,0 +1,22 @@
+* Xen hypervisor device tree bindings
+
+Xen ARM virtual platforms shall have the following properties:
+
+- compatible:
+	compatible = "xen,xen-<version>", "xen,xen";
+  where <version> is the version of the Xen ABI of the platform.
+
+- reg: specifies the base physical address and size of a region in
+  memory where the grant table should be mapped to, using an
+  HYPERVISOR_memory_op hypercall. 
+
+- interrupts: the interrupt used by Xen to inject event notifications.
+
+
+Example:
+
+hypervisor {
+	compatible = "xen,xen-4.3", "xen,xen";
+	reg = <0 0xb0000000 0 0x20000>;
+	interrupts = <1 15 0xf08>;
+};
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 14 11:14:20 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 11:14:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TCTqa-0005Ka-Fx; Fri, 14 Sep 2012 11:14:08 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1TCTqZ-0005Jd-1K
	for xen-devel@lists.xensource.com; Fri, 14 Sep 2012 11:14:07 +0000
Received: from [85.158.143.99:19343] by server-2.bemta-4.messagelabs.com id
	71/8E-21239-E7113505; Fri, 14 Sep 2012 11:14:06 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1347621243!30013120!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNjk2MTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15812 invoked from network); 14 Sep 2012 11:14:05 -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;
	14 Sep 2012 11:14:05 -0000
X-IronPort-AV: E=Sophos;i="4.80,422,1344211200"; d="scan'208";a="37873003"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Sep 2012 11:14:01 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Fri, 14 Sep 2012 07:14:00 -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 1TCTqN-0005wt-A1;
	Fri, 14 Sep 2012 12:13:55 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: <arnd@arndb.de>
Date: Fri, 14 Sep 2012 12:13:08 +0100
Message-ID: <1347621207-11294-6-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <alpine.DEB.2.02.1209141145150.29232@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1209141145150.29232@kaball.uk.xensource.com>
MIME-Version: 1.0
Cc: Dave Martin <dave.martin@linaro.org>, xen-devel@lists.xensource.com,
	linaro-dev@lists.linaro.org, Ian.Campbell@citrix.com,
	konrad.wilk@oracle.com, catalin.marinas@arm.com,
	devicetree-discuss@lists.ozlabs.org,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	tim@xen.org, linux-kernel@vger.kernel.org,
	Rob Herring <robherring2@gmail.com>,
	David Vrabel <david.vrabel@citrix.com>, linux@arm.linux.org.uk,
	linux-arm-kernel@lists.infradead.org
Subject: [Xen-devel] [PATCH v4 06/24] docs: Xen ARM DT bindings
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Add a doc to describe the Xen ARM device tree bindings


Changes in v4:

- "xen,xen" should be last as it is less specific;
- update reg property using 2 address-cells and 2 size-cells.


Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
CC: devicetree-discuss@lists.ozlabs.org
CC: David Vrabel <david.vrabel@citrix.com>
CC: Rob Herring <robherring2@gmail.com>
CC: Dave Martin <dave.martin@linaro.org>
---
 Documentation/devicetree/bindings/arm/xen.txt |   22 ++++++++++++++++++++++
 1 files changed, 22 insertions(+), 0 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/arm/xen.txt

diff --git a/Documentation/devicetree/bindings/arm/xen.txt b/Documentation/devicetree/bindings/arm/xen.txt
new file mode 100644
index 0000000..1f8f7d4
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/xen.txt
@@ -0,0 +1,22 @@
+* Xen hypervisor device tree bindings
+
+Xen ARM virtual platforms shall have the following properties:
+
+- compatible:
+	compatible = "xen,xen-<version>", "xen,xen";
+  where <version> is the version of the Xen ABI of the platform.
+
+- reg: specifies the base physical address and size of a region in
+  memory where the grant table should be mapped to, using an
+  HYPERVISOR_memory_op hypercall. 
+
+- interrupts: the interrupt used by Xen to inject event notifications.
+
+
+Example:
+
+hypervisor {
+	compatible = "xen,xen-4.3", "xen,xen";
+	reg = <0 0xb0000000 0 0x20000>;
+	interrupts = <1 15 0xf08>;
+};
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 14 11:14:20 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 11:14:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TCTqa-0005KM-3q; Fri, 14 Sep 2012 11:14:08 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1TCTqY-0005J1-Do
	for xen-devel@lists.xensource.com; Fri, 14 Sep 2012 11:14:06 +0000
Received: from [85.158.139.83:9067] by server-2.bemta-5.messagelabs.com id
	B9/68-11456-D7113505; Fri, 14 Sep 2012 11:14:05 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1347621241!30333207!4
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNjk2MTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10824 invoked from network); 14 Sep 2012 11:14:04 -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 Sep 2012 11:14:04 -0000
X-IronPort-AV: E=Sophos;i="4.80,422,1344211200"; d="scan'208";a="37873002"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Sep 2012 11:14:01 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Fri, 14 Sep 2012 07:13:59 -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 1TCTqN-0005wt-4t;
	Fri, 14 Sep 2012 12:13:55 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: <arnd@arndb.de>
Date: Fri, 14 Sep 2012 12:13:04 +0100
Message-ID: <1347621207-11294-2-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <alpine.DEB.2.02.1209141145150.29232@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1209141145150.29232@kaball.uk.xensource.com>
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com, linaro-dev@lists.linaro.org,
	Ian.Campbell@citrix.com, konrad.wilk@oracle.com, catalin.marinas@arm.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	tim@xen.org, linux-kernel@vger.kernel.org,
	linux@arm.linux.org.uk, linux-arm-kernel@lists.infradead.org
Subject: [Xen-devel] [PATCH v4 02/24] xen/arm: hypercalls
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Use r12 to pass the hypercall number to the hypervisor.

We need a register to pass the hypercall number because we might not
know it at compile time and HVC only takes an immediate argument.

Among the available registers r12 seems to be the best choice because it
is defined as "intra-procedure call scratch register".

Use the ISS to pass an hypervisor specific tag.


Changes in v2:
- define an HYPERCALL macro for 5 arguments hypercall wrappers, even if
at the moment is unused;
- use ldm instead of pop;
- fix up comments.


Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 arch/arm/include/asm/xen/hypercall.h |   50 ++++++++++++++++
 arch/arm/xen/Makefile                |    2 +-
 arch/arm/xen/hypercall.S             |  106 ++++++++++++++++++++++++++++++++++
 3 files changed, 157 insertions(+), 1 deletions(-)
 create mode 100644 arch/arm/include/asm/xen/hypercall.h
 create mode 100644 arch/arm/xen/hypercall.S

diff --git a/arch/arm/include/asm/xen/hypercall.h b/arch/arm/include/asm/xen/hypercall.h
new file mode 100644
index 0000000..4ac0624
--- /dev/null
+++ b/arch/arm/include/asm/xen/hypercall.h
@@ -0,0 +1,50 @@
+/******************************************************************************
+ * hypercall.h
+ *
+ * Linux-specific hypervisor handling.
+ *
+ * Stefano Stabellini <stefano.stabellini@eu.citrix.com>, Citrix, 2012
+ *
+ * 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.
+ */
+
+#ifndef _ASM_ARM_XEN_HYPERCALL_H
+#define _ASM_ARM_XEN_HYPERCALL_H
+
+#include <xen/interface/xen.h>
+
+long privcmd_call(unsigned call, unsigned long a1,
+		unsigned long a2, unsigned long a3,
+		unsigned long a4, unsigned long a5);
+int HYPERVISOR_xen_version(int cmd, void *arg);
+int HYPERVISOR_console_io(int cmd, int count, char *str);
+int HYPERVISOR_grant_table_op(unsigned int cmd, void *uop, unsigned int count);
+int HYPERVISOR_sched_op(int cmd, void *arg);
+int HYPERVISOR_event_channel_op(int cmd, void *arg);
+unsigned long HYPERVISOR_hvm_op(int op, void *arg);
+int HYPERVISOR_memory_op(unsigned int cmd, void *arg);
+int HYPERVISOR_physdev_op(int cmd, void *arg);
+
+#endif /* _ASM_ARM_XEN_HYPERCALL_H */
diff --git a/arch/arm/xen/Makefile b/arch/arm/xen/Makefile
index 0bad594..b9d6acc 100644
--- a/arch/arm/xen/Makefile
+++ b/arch/arm/xen/Makefile
@@ -1 +1 @@
-obj-y		:= enlighten.o
+obj-y		:= enlighten.o hypercall.o
diff --git a/arch/arm/xen/hypercall.S b/arch/arm/xen/hypercall.S
new file mode 100644
index 0000000..074f5ed
--- /dev/null
+++ b/arch/arm/xen/hypercall.S
@@ -0,0 +1,106 @@
+/******************************************************************************
+ * hypercall.S
+ *
+ * Xen hypercall wrappers
+ *
+ * Stefano Stabellini <stefano.stabellini@eu.citrix.com>, Citrix, 2012
+ *
+ * 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.
+ */
+
+/*
+ * The Xen hypercall calling convention is very similar to the ARM
+ * procedure calling convention: the first paramter is passed in r0, the
+ * second in r1, the third in r2 and the fourth in r3. Considering that
+ * Xen hypercalls have 5 arguments at most, the fifth paramter is passed
+ * in r4, differently from the procedure calling convention of using the
+ * stack for that case.
+ *
+ * The hypercall number is passed in r12.
+ *
+ * The return value is in r0.
+ *
+ * The hvc ISS is required to be 0xEA1, that is the Xen specific ARM
+ * hypercall tag.
+ */
+
+#include <linux/linkage.h>
+#include <asm/assembler.h>
+#include <xen/interface/xen.h>
+
+
+/* HVC 0xEA1 */
+#ifdef CONFIG_THUMB2_KERNEL
+#define xen_hvc .word 0xf7e08ea1
+#else
+#define xen_hvc .word 0xe140ea71
+#endif
+
+#define HYPERCALL_SIMPLE(hypercall)		\
+ENTRY(HYPERVISOR_##hypercall)			\
+	mov r12, #__HYPERVISOR_##hypercall;	\
+	xen_hvc;							\
+	mov pc, lr;							\
+ENDPROC(HYPERVISOR_##hypercall)
+
+#define HYPERCALL0 HYPERCALL_SIMPLE
+#define HYPERCALL1 HYPERCALL_SIMPLE
+#define HYPERCALL2 HYPERCALL_SIMPLE
+#define HYPERCALL3 HYPERCALL_SIMPLE
+#define HYPERCALL4 HYPERCALL_SIMPLE
+
+#define HYPERCALL5(hypercall)			\
+ENTRY(HYPERVISOR_##hypercall)			\
+	stmdb sp!, {r4}						\
+	ldr r4, [sp, #4]					\
+	mov r12, #__HYPERVISOR_##hypercall;	\
+	xen_hvc								\
+	ldm sp!, {r4}						\
+	mov pc, lr							\
+ENDPROC(HYPERVISOR_##hypercall)
+
+                .text
+
+HYPERCALL2(xen_version);
+HYPERCALL3(console_io);
+HYPERCALL3(grant_table_op);
+HYPERCALL2(sched_op);
+HYPERCALL2(event_channel_op);
+HYPERCALL2(hvm_op);
+HYPERCALL2(memory_op);
+HYPERCALL2(physdev_op);
+
+ENTRY(privcmd_call)
+	stmdb sp!, {r4}
+	mov r12, r0
+	mov r0, r1
+	mov r1, r2
+	mov r2, r3
+	ldr r3, [sp, #8]
+	ldr r4, [sp, #4]
+	xen_hvc
+	ldm sp!, {r4}
+	mov pc, lr
+ENDPROC(privcmd_call);
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 14 11:14:20 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 11:14:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TCTqa-0005KM-3q; Fri, 14 Sep 2012 11:14:08 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1TCTqY-0005J1-Do
	for xen-devel@lists.xensource.com; Fri, 14 Sep 2012 11:14:06 +0000
Received: from [85.158.139.83:9067] by server-2.bemta-5.messagelabs.com id
	B9/68-11456-D7113505; Fri, 14 Sep 2012 11:14:05 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1347621241!30333207!4
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNjk2MTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10824 invoked from network); 14 Sep 2012 11:14:04 -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 Sep 2012 11:14:04 -0000
X-IronPort-AV: E=Sophos;i="4.80,422,1344211200"; d="scan'208";a="37873002"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Sep 2012 11:14:01 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Fri, 14 Sep 2012 07:13:59 -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 1TCTqN-0005wt-4t;
	Fri, 14 Sep 2012 12:13:55 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: <arnd@arndb.de>
Date: Fri, 14 Sep 2012 12:13:04 +0100
Message-ID: <1347621207-11294-2-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <alpine.DEB.2.02.1209141145150.29232@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1209141145150.29232@kaball.uk.xensource.com>
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com, linaro-dev@lists.linaro.org,
	Ian.Campbell@citrix.com, konrad.wilk@oracle.com, catalin.marinas@arm.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	tim@xen.org, linux-kernel@vger.kernel.org,
	linux@arm.linux.org.uk, linux-arm-kernel@lists.infradead.org
Subject: [Xen-devel] [PATCH v4 02/24] xen/arm: hypercalls
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Use r12 to pass the hypercall number to the hypervisor.

We need a register to pass the hypercall number because we might not
know it at compile time and HVC only takes an immediate argument.

Among the available registers r12 seems to be the best choice because it
is defined as "intra-procedure call scratch register".

Use the ISS to pass an hypervisor specific tag.


Changes in v2:
- define an HYPERCALL macro for 5 arguments hypercall wrappers, even if
at the moment is unused;
- use ldm instead of pop;
- fix up comments.


Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 arch/arm/include/asm/xen/hypercall.h |   50 ++++++++++++++++
 arch/arm/xen/Makefile                |    2 +-
 arch/arm/xen/hypercall.S             |  106 ++++++++++++++++++++++++++++++++++
 3 files changed, 157 insertions(+), 1 deletions(-)
 create mode 100644 arch/arm/include/asm/xen/hypercall.h
 create mode 100644 arch/arm/xen/hypercall.S

diff --git a/arch/arm/include/asm/xen/hypercall.h b/arch/arm/include/asm/xen/hypercall.h
new file mode 100644
index 0000000..4ac0624
--- /dev/null
+++ b/arch/arm/include/asm/xen/hypercall.h
@@ -0,0 +1,50 @@
+/******************************************************************************
+ * hypercall.h
+ *
+ * Linux-specific hypervisor handling.
+ *
+ * Stefano Stabellini <stefano.stabellini@eu.citrix.com>, Citrix, 2012
+ *
+ * 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.
+ */
+
+#ifndef _ASM_ARM_XEN_HYPERCALL_H
+#define _ASM_ARM_XEN_HYPERCALL_H
+
+#include <xen/interface/xen.h>
+
+long privcmd_call(unsigned call, unsigned long a1,
+		unsigned long a2, unsigned long a3,
+		unsigned long a4, unsigned long a5);
+int HYPERVISOR_xen_version(int cmd, void *arg);
+int HYPERVISOR_console_io(int cmd, int count, char *str);
+int HYPERVISOR_grant_table_op(unsigned int cmd, void *uop, unsigned int count);
+int HYPERVISOR_sched_op(int cmd, void *arg);
+int HYPERVISOR_event_channel_op(int cmd, void *arg);
+unsigned long HYPERVISOR_hvm_op(int op, void *arg);
+int HYPERVISOR_memory_op(unsigned int cmd, void *arg);
+int HYPERVISOR_physdev_op(int cmd, void *arg);
+
+#endif /* _ASM_ARM_XEN_HYPERCALL_H */
diff --git a/arch/arm/xen/Makefile b/arch/arm/xen/Makefile
index 0bad594..b9d6acc 100644
--- a/arch/arm/xen/Makefile
+++ b/arch/arm/xen/Makefile
@@ -1 +1 @@
-obj-y		:= enlighten.o
+obj-y		:= enlighten.o hypercall.o
diff --git a/arch/arm/xen/hypercall.S b/arch/arm/xen/hypercall.S
new file mode 100644
index 0000000..074f5ed
--- /dev/null
+++ b/arch/arm/xen/hypercall.S
@@ -0,0 +1,106 @@
+/******************************************************************************
+ * hypercall.S
+ *
+ * Xen hypercall wrappers
+ *
+ * Stefano Stabellini <stefano.stabellini@eu.citrix.com>, Citrix, 2012
+ *
+ * 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.
+ */
+
+/*
+ * The Xen hypercall calling convention is very similar to the ARM
+ * procedure calling convention: the first paramter is passed in r0, the
+ * second in r1, the third in r2 and the fourth in r3. Considering that
+ * Xen hypercalls have 5 arguments at most, the fifth paramter is passed
+ * in r4, differently from the procedure calling convention of using the
+ * stack for that case.
+ *
+ * The hypercall number is passed in r12.
+ *
+ * The return value is in r0.
+ *
+ * The hvc ISS is required to be 0xEA1, that is the Xen specific ARM
+ * hypercall tag.
+ */
+
+#include <linux/linkage.h>
+#include <asm/assembler.h>
+#include <xen/interface/xen.h>
+
+
+/* HVC 0xEA1 */
+#ifdef CONFIG_THUMB2_KERNEL
+#define xen_hvc .word 0xf7e08ea1
+#else
+#define xen_hvc .word 0xe140ea71
+#endif
+
+#define HYPERCALL_SIMPLE(hypercall)		\
+ENTRY(HYPERVISOR_##hypercall)			\
+	mov r12, #__HYPERVISOR_##hypercall;	\
+	xen_hvc;							\
+	mov pc, lr;							\
+ENDPROC(HYPERVISOR_##hypercall)
+
+#define HYPERCALL0 HYPERCALL_SIMPLE
+#define HYPERCALL1 HYPERCALL_SIMPLE
+#define HYPERCALL2 HYPERCALL_SIMPLE
+#define HYPERCALL3 HYPERCALL_SIMPLE
+#define HYPERCALL4 HYPERCALL_SIMPLE
+
+#define HYPERCALL5(hypercall)			\
+ENTRY(HYPERVISOR_##hypercall)			\
+	stmdb sp!, {r4}						\
+	ldr r4, [sp, #4]					\
+	mov r12, #__HYPERVISOR_##hypercall;	\
+	xen_hvc								\
+	ldm sp!, {r4}						\
+	mov pc, lr							\
+ENDPROC(HYPERVISOR_##hypercall)
+
+                .text
+
+HYPERCALL2(xen_version);
+HYPERCALL3(console_io);
+HYPERCALL3(grant_table_op);
+HYPERCALL2(sched_op);
+HYPERCALL2(event_channel_op);
+HYPERCALL2(hvm_op);
+HYPERCALL2(memory_op);
+HYPERCALL2(physdev_op);
+
+ENTRY(privcmd_call)
+	stmdb sp!, {r4}
+	mov r12, r0
+	mov r0, r1
+	mov r1, r2
+	mov r2, r3
+	ldr r3, [sp, #8]
+	ldr r4, [sp, #4]
+	xen_hvc
+	ldm sp!, {r4}
+	mov pc, lr
+ENDPROC(privcmd_call);
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 14 11:14:20 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 11:14:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TCTqa-0005Kn-Tp; Fri, 14 Sep 2012 11:14:08 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1TCTqZ-0005Iu-15
	for xen-devel@lists.xensource.com; Fri, 14 Sep 2012 11:14:07 +0000
Received: from [85.158.139.83:8991] by server-4.bemta-5.messagelabs.com id
	B8/73-23042-C7113505; Fri, 14 Sep 2012 11:14:04 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1347621241!30333207!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNjk2MTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10742 invoked from network); 14 Sep 2012 11:14:03 -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 Sep 2012 11:14:03 -0000
X-IronPort-AV: E=Sophos;i="4.80,422,1344211200"; d="scan'208";a="37872999"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Sep 2012 11:14:00 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Fri, 14 Sep 2012 07:13:59 -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 1TCTqN-0005wt-7N;
	Fri, 14 Sep 2012 12:13:55 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: <arnd@arndb.de>
Date: Fri, 14 Sep 2012 12:13:06 +0100
Message-ID: <1347621207-11294-4-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <alpine.DEB.2.02.1209141145150.29232@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1209141145150.29232@kaball.uk.xensource.com>
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com, linaro-dev@lists.linaro.org,
	Ian.Campbell@citrix.com, konrad.wilk@oracle.com, catalin.marinas@arm.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	tim@xen.org, linux-kernel@vger.kernel.org,
	linux@arm.linux.org.uk, linux-arm-kernel@lists.infradead.org
Subject: [Xen-devel] [PATCH v4 04/24] xen/arm: sync_bitops
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

sync_bitops functions are equivalent to the SMP implementation of the
original functions, independently from CONFIG_SMP being defined.

We need them because _set_bit etc are not SMP safe if !CONFIG_SMP. But
under Xen you might be communicating with a completely external entity
who might be on another CPU (e.g. two uniprocessor guests communicating
via event channels and grant tables). So we need a variant of the bit
ops which are SMP safe even on a UP kernel.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 arch/arm/include/asm/sync_bitops.h |   27 +++++++++++++++++++++++++++
 1 files changed, 27 insertions(+), 0 deletions(-)
 create mode 100644 arch/arm/include/asm/sync_bitops.h

diff --git a/arch/arm/include/asm/sync_bitops.h b/arch/arm/include/asm/sync_bitops.h
new file mode 100644
index 0000000..63479ee
--- /dev/null
+++ b/arch/arm/include/asm/sync_bitops.h
@@ -0,0 +1,27 @@
+#ifndef __ASM_SYNC_BITOPS_H__
+#define __ASM_SYNC_BITOPS_H__
+
+#include <asm/bitops.h>
+#include <asm/system.h>
+
+/* sync_bitops functions are equivalent to the SMP implementation of the
+ * original functions, independently from CONFIG_SMP being defined.
+ *
+ * We need them because _set_bit etc are not SMP safe if !CONFIG_SMP. But
+ * under Xen you might be communicating with a completely external entity
+ * who might be on another CPU (e.g. two uniprocessor guests communicating
+ * via event channels and grant tables). So we need a variant of the bit
+ * ops which are SMP safe even on a UP kernel.
+ */
+
+#define sync_set_bit(nr, p)		_set_bit(nr, p)
+#define sync_clear_bit(nr, p)		_clear_bit(nr, p)
+#define sync_change_bit(nr, p)		_change_bit(nr, p)
+#define sync_test_and_set_bit(nr, p)	_test_and_set_bit(nr, p)
+#define sync_test_and_clear_bit(nr, p)	_test_and_clear_bit(nr, p)
+#define sync_test_and_change_bit(nr, p)	_test_and_change_bit(nr, p)
+#define sync_test_bit(nr, addr)		test_bit(nr, addr)
+#define sync_cmpxchg			cmpxchg
+
+
+#endif
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 14 11:14:20 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 11:14:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TCTqa-0005Kn-Tp; Fri, 14 Sep 2012 11:14:08 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1TCTqZ-0005Iu-15
	for xen-devel@lists.xensource.com; Fri, 14 Sep 2012 11:14:07 +0000
Received: from [85.158.139.83:8991] by server-4.bemta-5.messagelabs.com id
	B8/73-23042-C7113505; Fri, 14 Sep 2012 11:14:04 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1347621241!30333207!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNjk2MTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10742 invoked from network); 14 Sep 2012 11:14:03 -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 Sep 2012 11:14:03 -0000
X-IronPort-AV: E=Sophos;i="4.80,422,1344211200"; d="scan'208";a="37872999"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Sep 2012 11:14:00 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Fri, 14 Sep 2012 07:13:59 -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 1TCTqN-0005wt-7N;
	Fri, 14 Sep 2012 12:13:55 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: <arnd@arndb.de>
Date: Fri, 14 Sep 2012 12:13:06 +0100
Message-ID: <1347621207-11294-4-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <alpine.DEB.2.02.1209141145150.29232@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1209141145150.29232@kaball.uk.xensource.com>
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com, linaro-dev@lists.linaro.org,
	Ian.Campbell@citrix.com, konrad.wilk@oracle.com, catalin.marinas@arm.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	tim@xen.org, linux-kernel@vger.kernel.org,
	linux@arm.linux.org.uk, linux-arm-kernel@lists.infradead.org
Subject: [Xen-devel] [PATCH v4 04/24] xen/arm: sync_bitops
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

sync_bitops functions are equivalent to the SMP implementation of the
original functions, independently from CONFIG_SMP being defined.

We need them because _set_bit etc are not SMP safe if !CONFIG_SMP. But
under Xen you might be communicating with a completely external entity
who might be on another CPU (e.g. two uniprocessor guests communicating
via event channels and grant tables). So we need a variant of the bit
ops which are SMP safe even on a UP kernel.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 arch/arm/include/asm/sync_bitops.h |   27 +++++++++++++++++++++++++++
 1 files changed, 27 insertions(+), 0 deletions(-)
 create mode 100644 arch/arm/include/asm/sync_bitops.h

diff --git a/arch/arm/include/asm/sync_bitops.h b/arch/arm/include/asm/sync_bitops.h
new file mode 100644
index 0000000..63479ee
--- /dev/null
+++ b/arch/arm/include/asm/sync_bitops.h
@@ -0,0 +1,27 @@
+#ifndef __ASM_SYNC_BITOPS_H__
+#define __ASM_SYNC_BITOPS_H__
+
+#include <asm/bitops.h>
+#include <asm/system.h>
+
+/* sync_bitops functions are equivalent to the SMP implementation of the
+ * original functions, independently from CONFIG_SMP being defined.
+ *
+ * We need them because _set_bit etc are not SMP safe if !CONFIG_SMP. But
+ * under Xen you might be communicating with a completely external entity
+ * who might be on another CPU (e.g. two uniprocessor guests communicating
+ * via event channels and grant tables). So we need a variant of the bit
+ * ops which are SMP safe even on a UP kernel.
+ */
+
+#define sync_set_bit(nr, p)		_set_bit(nr, p)
+#define sync_clear_bit(nr, p)		_clear_bit(nr, p)
+#define sync_change_bit(nr, p)		_change_bit(nr, p)
+#define sync_test_and_set_bit(nr, p)	_test_and_set_bit(nr, p)
+#define sync_test_and_clear_bit(nr, p)	_test_and_clear_bit(nr, p)
+#define sync_test_and_change_bit(nr, p)	_test_and_change_bit(nr, p)
+#define sync_test_bit(nr, addr)		test_bit(nr, addr)
+#define sync_cmpxchg			cmpxchg
+
+
+#endif
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 14 11:14:21 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 11: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 1TCTqX-0005J8-N5; Fri, 14 Sep 2012 11:14:05 +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 1TCTqW-0005Iq-BX
	for xen-devel@lists.xensource.com; Fri, 14 Sep 2012 11:14:04 +0000
Received: from [85.158.139.83:30374] by server-6.bemta-5.messagelabs.com id
	7C/8B-21336-B7113505; Fri, 14 Sep 2012 11:14:03 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1347621241!30333207!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNjk2MTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10656 invoked from network); 14 Sep 2012 11:14:02 -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 Sep 2012 11:14:02 -0000
X-IronPort-AV: E=Sophos;i="4.80,422,1344211200"; d="scan'208";a="37872998"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Sep 2012 11:14:00 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Fri, 14 Sep 2012 07:13:59 -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 1TCTqN-0005wt-5Z;
	Fri, 14 Sep 2012 12:13:55 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: <arnd@arndb.de>
Date: Fri, 14 Sep 2012 12:13:05 +0100
Message-ID: <1347621207-11294-3-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <alpine.DEB.2.02.1209141145150.29232@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1209141145150.29232@kaball.uk.xensource.com>
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com, linaro-dev@lists.linaro.org,
	Ian.Campbell@citrix.com, konrad.wilk@oracle.com, catalin.marinas@arm.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	tim@xen.org, linux-kernel@vger.kernel.org,
	linux@arm.linux.org.uk, linux-arm-kernel@lists.infradead.org
Subject: [Xen-devel] [PATCH v4 03/24] xen/arm: page.h 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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

ARM Xen guests always use paging in hardware, like PV on HVM guests in
the X86 world.

Changes in v3:

- improve comments.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 arch/arm/include/asm/xen/page.h |   82 +++++++++++++++++++++++++++++++++++++++
 1 files changed, 82 insertions(+), 0 deletions(-)
 create mode 100644 arch/arm/include/asm/xen/page.h

diff --git a/arch/arm/include/asm/xen/page.h b/arch/arm/include/asm/xen/page.h
new file mode 100644
index 0000000..1742023
--- /dev/null
+++ b/arch/arm/include/asm/xen/page.h
@@ -0,0 +1,82 @@
+#ifndef _ASM_ARM_XEN_PAGE_H
+#define _ASM_ARM_XEN_PAGE_H
+
+#include <asm/page.h>
+#include <asm/pgtable.h>
+
+#include <linux/pfn.h>
+#include <linux/types.h>
+
+#include <xen/interface/grant_table.h>
+
+#define pfn_to_mfn(pfn)			(pfn)
+#define phys_to_machine_mapping_valid	(1)
+#define mfn_to_pfn(mfn)			(mfn)
+#define mfn_to_virt(m)			(__va(mfn_to_pfn(m) << PAGE_SHIFT))
+
+#define pte_mfn	    pte_pfn
+#define mfn_pte	    pfn_pte
+
+/* Xen machine address */
+typedef struct xmaddr {
+	phys_addr_t maddr;
+} xmaddr_t;
+
+/* Xen pseudo-physical address */
+typedef struct xpaddr {
+	phys_addr_t paddr;
+} xpaddr_t;
+
+#define XMADDR(x)	((xmaddr_t) { .maddr = (x) })
+#define XPADDR(x)	((xpaddr_t) { .paddr = (x) })
+
+static inline xmaddr_t phys_to_machine(xpaddr_t phys)
+{
+	unsigned offset = phys.paddr & ~PAGE_MASK;
+	return XMADDR(PFN_PHYS(pfn_to_mfn(PFN_DOWN(phys.paddr))) | offset);
+}
+
+static inline xpaddr_t machine_to_phys(xmaddr_t machine)
+{
+	unsigned offset = machine.maddr & ~PAGE_MASK;
+	return XPADDR(PFN_PHYS(mfn_to_pfn(PFN_DOWN(machine.maddr))) | offset);
+}
+/* VIRT <-> MACHINE conversion */
+#define virt_to_machine(v)	(phys_to_machine(XPADDR(__pa(v))))
+#define virt_to_pfn(v)          (PFN_DOWN(__pa(v)))
+#define virt_to_mfn(v)		(pfn_to_mfn(virt_to_pfn(v)))
+#define mfn_to_virt(m)		(__va(mfn_to_pfn(m) << PAGE_SHIFT))
+
+static inline xmaddr_t arbitrary_virt_to_machine(void *vaddr)
+{
+	/* TODO: assuming it is mapped in the kernel 1:1 */
+	return virt_to_machine(vaddr);
+}
+
+/* TODO: this shouldn't be here but it is because the frontend drivers
+ * are using it (its rolled in headers) even though we won't hit the code path.
+ * So for right now just punt with this.
+ */
+static inline pte_t *lookup_address(unsigned long address, unsigned int *level)
+{
+	BUG();
+	return NULL;
+}
+
+static inline int m2p_add_override(unsigned long mfn, struct page *page,
+		struct gnttab_map_grant_ref *kmap_op)
+{
+	return 0;
+}
+
+static inline int m2p_remove_override(struct page *page, bool clear_pte)
+{
+	return 0;
+}
+
+static inline bool set_phys_to_machine(unsigned long pfn, unsigned long mfn)
+{
+	BUG();
+	return false;
+}
+#endif /* _ASM_ARM_XEN_PAGE_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 Sep 14 11:14:21 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 11: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 1TCTqX-0005J8-N5; Fri, 14 Sep 2012 11:14:05 +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 1TCTqW-0005Iq-BX
	for xen-devel@lists.xensource.com; Fri, 14 Sep 2012 11:14:04 +0000
Received: from [85.158.139.83:30374] by server-6.bemta-5.messagelabs.com id
	7C/8B-21336-B7113505; Fri, 14 Sep 2012 11:14:03 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1347621241!30333207!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNjk2MTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10656 invoked from network); 14 Sep 2012 11:14:02 -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 Sep 2012 11:14:02 -0000
X-IronPort-AV: E=Sophos;i="4.80,422,1344211200"; d="scan'208";a="37872998"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Sep 2012 11:14:00 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Fri, 14 Sep 2012 07:13:59 -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 1TCTqN-0005wt-5Z;
	Fri, 14 Sep 2012 12:13:55 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: <arnd@arndb.de>
Date: Fri, 14 Sep 2012 12:13:05 +0100
Message-ID: <1347621207-11294-3-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <alpine.DEB.2.02.1209141145150.29232@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1209141145150.29232@kaball.uk.xensource.com>
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com, linaro-dev@lists.linaro.org,
	Ian.Campbell@citrix.com, konrad.wilk@oracle.com, catalin.marinas@arm.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	tim@xen.org, linux-kernel@vger.kernel.org,
	linux@arm.linux.org.uk, linux-arm-kernel@lists.infradead.org
Subject: [Xen-devel] [PATCH v4 03/24] xen/arm: page.h 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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

ARM Xen guests always use paging in hardware, like PV on HVM guests in
the X86 world.

Changes in v3:

- improve comments.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 arch/arm/include/asm/xen/page.h |   82 +++++++++++++++++++++++++++++++++++++++
 1 files changed, 82 insertions(+), 0 deletions(-)
 create mode 100644 arch/arm/include/asm/xen/page.h

diff --git a/arch/arm/include/asm/xen/page.h b/arch/arm/include/asm/xen/page.h
new file mode 100644
index 0000000..1742023
--- /dev/null
+++ b/arch/arm/include/asm/xen/page.h
@@ -0,0 +1,82 @@
+#ifndef _ASM_ARM_XEN_PAGE_H
+#define _ASM_ARM_XEN_PAGE_H
+
+#include <asm/page.h>
+#include <asm/pgtable.h>
+
+#include <linux/pfn.h>
+#include <linux/types.h>
+
+#include <xen/interface/grant_table.h>
+
+#define pfn_to_mfn(pfn)			(pfn)
+#define phys_to_machine_mapping_valid	(1)
+#define mfn_to_pfn(mfn)			(mfn)
+#define mfn_to_virt(m)			(__va(mfn_to_pfn(m) << PAGE_SHIFT))
+
+#define pte_mfn	    pte_pfn
+#define mfn_pte	    pfn_pte
+
+/* Xen machine address */
+typedef struct xmaddr {
+	phys_addr_t maddr;
+} xmaddr_t;
+
+/* Xen pseudo-physical address */
+typedef struct xpaddr {
+	phys_addr_t paddr;
+} xpaddr_t;
+
+#define XMADDR(x)	((xmaddr_t) { .maddr = (x) })
+#define XPADDR(x)	((xpaddr_t) { .paddr = (x) })
+
+static inline xmaddr_t phys_to_machine(xpaddr_t phys)
+{
+	unsigned offset = phys.paddr & ~PAGE_MASK;
+	return XMADDR(PFN_PHYS(pfn_to_mfn(PFN_DOWN(phys.paddr))) | offset);
+}
+
+static inline xpaddr_t machine_to_phys(xmaddr_t machine)
+{
+	unsigned offset = machine.maddr & ~PAGE_MASK;
+	return XPADDR(PFN_PHYS(mfn_to_pfn(PFN_DOWN(machine.maddr))) | offset);
+}
+/* VIRT <-> MACHINE conversion */
+#define virt_to_machine(v)	(phys_to_machine(XPADDR(__pa(v))))
+#define virt_to_pfn(v)          (PFN_DOWN(__pa(v)))
+#define virt_to_mfn(v)		(pfn_to_mfn(virt_to_pfn(v)))
+#define mfn_to_virt(m)		(__va(mfn_to_pfn(m) << PAGE_SHIFT))
+
+static inline xmaddr_t arbitrary_virt_to_machine(void *vaddr)
+{
+	/* TODO: assuming it is mapped in the kernel 1:1 */
+	return virt_to_machine(vaddr);
+}
+
+/* TODO: this shouldn't be here but it is because the frontend drivers
+ * are using it (its rolled in headers) even though we won't hit the code path.
+ * So for right now just punt with this.
+ */
+static inline pte_t *lookup_address(unsigned long address, unsigned int *level)
+{
+	BUG();
+	return NULL;
+}
+
+static inline int m2p_add_override(unsigned long mfn, struct page *page,
+		struct gnttab_map_grant_ref *kmap_op)
+{
+	return 0;
+}
+
+static inline int m2p_remove_override(struct page *page, bool clear_pte)
+{
+	return 0;
+}
+
+static inline bool set_phys_to_machine(unsigned long pfn, unsigned long mfn)
+{
+	BUG();
+	return false;
+}
+#endif /* _ASM_ARM_XEN_PAGE_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 Sep 14 11:14:22 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 11: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 1TCTqZ-0005K8-Ls; Fri, 14 Sep 2012 11:14: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 1TCTqY-0005J6-0Q
	for xen-devel@lists.xensource.com; Fri, 14 Sep 2012 11:14:06 +0000
Received: from [85.158.143.99:19267] by server-1.bemta-4.messagelabs.com id
	FC/77-12504-D7113505; Fri, 14 Sep 2012 11:14:05 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1347621243!30013120!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNjk2MTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15718 invoked from network); 14 Sep 2012 11:14:04 -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;
	14 Sep 2012 11:14:04 -0000
X-IronPort-AV: E=Sophos;i="4.80,422,1344211200"; d="scan'208";a="37873001"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Sep 2012 11:14:01 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Fri, 14 Sep 2012 07:14:00 -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 1TCTqN-0005wt-82;
	Fri, 14 Sep 2012 12:13:55 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: <arnd@arndb.de>
Date: Fri, 14 Sep 2012 12:13:07 +0100
Message-ID: <1347621207-11294-5-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <alpine.DEB.2.02.1209141145150.29232@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1209141145150.29232@kaball.uk.xensource.com>
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com, linaro-dev@lists.linaro.org,
	Ian.Campbell@citrix.com, konrad.wilk@oracle.com, catalin.marinas@arm.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	tim@xen.org, linux-kernel@vger.kernel.org,
	linux@arm.linux.org.uk, linux-arm-kernel@lists.infradead.org
Subject: [Xen-devel] [PATCH v4 05/24] xen/arm: empty implementation of
	grant_table arch specific 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

Changes in v2:

- return -ENOSYS rather than -1.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 arch/arm/xen/Makefile      |    2 +-
 arch/arm/xen/grant-table.c |   53 ++++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 54 insertions(+), 1 deletions(-)
 create mode 100644 arch/arm/xen/grant-table.c

diff --git a/arch/arm/xen/Makefile b/arch/arm/xen/Makefile
index b9d6acc..4384103 100644
--- a/arch/arm/xen/Makefile
+++ b/arch/arm/xen/Makefile
@@ -1 +1 @@
-obj-y		:= enlighten.o hypercall.o
+obj-y		:= enlighten.o hypercall.o grant-table.o
diff --git a/arch/arm/xen/grant-table.c b/arch/arm/xen/grant-table.c
new file mode 100644
index 0000000..dbd1330
--- /dev/null
+++ b/arch/arm/xen/grant-table.c
@@ -0,0 +1,53 @@
+/******************************************************************************
+ * grant_table.c
+ * ARM specific part
+ *
+ * Granting foreign access to our memory reservation.
+ *
+ * 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 <xen/interface/xen.h>
+#include <xen/page.h>
+#include <xen/grant_table.h>
+
+int arch_gnttab_map_shared(unsigned long *frames, unsigned long nr_gframes,
+			   unsigned long max_nr_gframes,
+			   void **__shared)
+{
+	return -ENOSYS;
+}
+
+void arch_gnttab_unmap(void *shared, unsigned long nr_gframes)
+{
+	return;
+}
+
+int arch_gnttab_map_status(uint64_t *frames, unsigned long nr_gframes,
+			   unsigned long max_nr_gframes,
+			   grant_status_t **__shared)
+{
+	return -ENOSYS;
+}
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 14 11:14:22 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 11: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 1TCTqZ-0005K8-Ls; Fri, 14 Sep 2012 11:14: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 1TCTqY-0005J6-0Q
	for xen-devel@lists.xensource.com; Fri, 14 Sep 2012 11:14:06 +0000
Received: from [85.158.143.99:19267] by server-1.bemta-4.messagelabs.com id
	FC/77-12504-D7113505; Fri, 14 Sep 2012 11:14:05 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1347621243!30013120!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNjk2MTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15718 invoked from network); 14 Sep 2012 11:14:04 -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;
	14 Sep 2012 11:14:04 -0000
X-IronPort-AV: E=Sophos;i="4.80,422,1344211200"; d="scan'208";a="37873001"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Sep 2012 11:14:01 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Fri, 14 Sep 2012 07:14:00 -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 1TCTqN-0005wt-82;
	Fri, 14 Sep 2012 12:13:55 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: <arnd@arndb.de>
Date: Fri, 14 Sep 2012 12:13:07 +0100
Message-ID: <1347621207-11294-5-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <alpine.DEB.2.02.1209141145150.29232@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1209141145150.29232@kaball.uk.xensource.com>
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com, linaro-dev@lists.linaro.org,
	Ian.Campbell@citrix.com, konrad.wilk@oracle.com, catalin.marinas@arm.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	tim@xen.org, linux-kernel@vger.kernel.org,
	linux@arm.linux.org.uk, linux-arm-kernel@lists.infradead.org
Subject: [Xen-devel] [PATCH v4 05/24] xen/arm: empty implementation of
	grant_table arch specific 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

Changes in v2:

- return -ENOSYS rather than -1.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 arch/arm/xen/Makefile      |    2 +-
 arch/arm/xen/grant-table.c |   53 ++++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 54 insertions(+), 1 deletions(-)
 create mode 100644 arch/arm/xen/grant-table.c

diff --git a/arch/arm/xen/Makefile b/arch/arm/xen/Makefile
index b9d6acc..4384103 100644
--- a/arch/arm/xen/Makefile
+++ b/arch/arm/xen/Makefile
@@ -1 +1 @@
-obj-y		:= enlighten.o hypercall.o
+obj-y		:= enlighten.o hypercall.o grant-table.o
diff --git a/arch/arm/xen/grant-table.c b/arch/arm/xen/grant-table.c
new file mode 100644
index 0000000..dbd1330
--- /dev/null
+++ b/arch/arm/xen/grant-table.c
@@ -0,0 +1,53 @@
+/******************************************************************************
+ * grant_table.c
+ * ARM specific part
+ *
+ * Granting foreign access to our memory reservation.
+ *
+ * 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 <xen/interface/xen.h>
+#include <xen/page.h>
+#include <xen/grant_table.h>
+
+int arch_gnttab_map_shared(unsigned long *frames, unsigned long nr_gframes,
+			   unsigned long max_nr_gframes,
+			   void **__shared)
+{
+	return -ENOSYS;
+}
+
+void arch_gnttab_unmap(void *shared, unsigned long nr_gframes)
+{
+	return;
+}
+
+int arch_gnttab_map_status(uint64_t *frames, unsigned long nr_gframes,
+			   unsigned long max_nr_gframes,
+			   grant_status_t **__shared)
+{
+	return -ENOSYS;
+}
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 14 11:14:25 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 11: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 1TCTqE-0005Hf-A7; Fri, 14 Sep 2012 11:13:46 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1TCTqC-0005HV-LL
	for xen-devel@lists.xensource.com; Fri, 14 Sep 2012 11:13:45 +0000
Received: from [85.158.143.99:17860] by server-2.bemta-4.messagelabs.com id
	44/FD-21239-76113505; Fri, 14 Sep 2012 11:13:43 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1347621222!20568062!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDkyOTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22801 invoked from network); 14 Sep 2012 11:13:42 -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;
	14 Sep 2012 11:13:42 -0000
X-IronPort-AV: E=Sophos;i="4.80,422,1344211200"; 
	d="dts'?dtsi'?scan'208";a="14543401"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Sep 2012 11:13: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.279.1; Fri, 14 Sep 2012 12:13:42 +0100
Date: Fri, 14 Sep 2012 12:12:59 +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>
Message-ID: <alpine.DEB.2.02.1209141145150.29232@kaball.uk.xensource.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Content-Type: multipart/mixed;
	boundary="_004_alpineDEB20212081616185504850kaballukxensourcecom_"
Content-ID: <alpine.DEB.2.02.1209141145151.29232@kaball.uk.xensource.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linaro-dev@lists.linaro.org" <linaro-dev@lists.linaro.org>,
	Ian Campbell <Ian.Campbell@citrix.com>, "arnd@arndb.de" <arnd@arndb.de>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"catalin.marinas@arm.com" <catalin.marinas@arm.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>, "Tim
	\(Xen.org\)" <tim@xen.org>,
	Russell King - ARM Linux <linux@arm.linux.org.uk>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: [Xen-devel] [PATCH v4 00/24] Introduce Xen support on ARM (based on
	3.6-rc5)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--_004_alpineDEB20212081616185504850kaballukxensourcecom_
Content-Type: text/plain; charset="US-ASCII"
Content-ID: <alpine.DEB.2.02.1209141145152.29232@kaball.uk.xensource.com>

Hi all,
this patch series implements Xen support for ARMv7 with virtualization
extensions.  It allows a Linux guest to boot as dom0 and
as domU on Xen on ARM. PV console, disk and network frontends and
backends are all working correctly.

It has been tested on a Versatile Express Cortex A15 emulator, using the
latest Xen ARM developement branch
(git://xenbits.xen.org/people/ianc/xen-unstable.git arm-for-4.3) plus
the "ARM hypercall ABI: 64 bit ready" patch series
(http://marc.info/?l=xen-devel&m=134426267205408), and a simple ad-hoc
tool to build guest domains (marc.info/?l=xen-devel&m=134089788016546).

The patch marked with [HACK] has been dropped from this series, however
you can find it here:
http://marc.info/?l=linux-kernel&m=134513277823527&w=2.

I am also attaching to this email the dts'es that I am currently using
for dom0 and domU: vexpress-v2p-ca15-tc1.dts (that includes
vexpress-v2m-rs1-rtsm.dtsi) is the dts used for dom0 and it is passed to
Linux by Xen, while vexpress-virt.dts is the dts used for other domUs
and it is appended in binary form to the guest kernel image. I am not
sure where they are supposed to live yet, so I am just attaching them
here so that people can actually try out this series if they want to.

Comments are very welcome!



Patch #21 "arm/v2m: initialize arch_timers even if v2m_timer is not
present" touches generic ARM code and still needs to be acked/reviewed.

Arnd, Russell, what do you think about this series? If you are OK with
it, to whom should I submit it?



Changes in v4:
- rebase on 3.6-rc5;
- devicetree: "xen,xen" should be last as it is less specific;
- devicetree: use 2 address-cells and 2 size-cells in the reg property;
- do not xs_reset_watches on dom0;
- compile drivers/xen/pcpu.c only on x86;
- use "+=" instead of ":=" for dom0- targets;
- add a patch to update the MAINTAINERS file.


Changes in v3:
- move patches that have been picked up by Konrad at the end of the
  series;
- improve comments;
- add a doc to describe the Xen Device Tree format;
- do not use xen_ulong_t for multicalls and apic_physbase;
- add a patch at the end of the series to use the new __HVC macro;
- add missing pvclock-abi.h include to ia64 header files;
- do not use an anonymous union in struct xen_add_to_physmap.


Changes in v2:
- fix up many comments and commit messages;
- remove the early_printk patches: rely on the emulated serial for now;
- remove the xen_guest_init patch: without any PV early_printk, we don't
  need any early call to xen_guest_init, we can rely on core_initcall
  alone;
- define an HYPERCALL macro for 5 arguments hypercall wrappers, even if
  at the moment is unused;
- use ldm instead of pop in the hypercall wrappers;
- return -ENOSYS rather than -1 from the unimplemented grant_table
  functions;
- remove the pvclock ifdef in the Xen headers;
- remove include linux/types.h from xen/interface/xen.h;
- replace pr_info with pr_debug in xen_guest_init;
- add a new patch to introduce xen_ulong_t and use it top replace all
  the occurences of unsigned long in the public Xen interface;
- explicitely size all the pointers to 64 bit on ARM, so that the
  hypercall ABI is "64 bit ready";
- clean up xenbus_init;
- make pci.o depend on CONFIG_PCI and acpi.o depend on CONFIG_ACPI;
- mark Xen guest support on ARM as EXPERIMENTAL;
- introduce GRANT_TABLE_PHYSADDR;
- remove unneeded initialization of boot_max_nr_grant_frames;
- add a new patch to clear IRQ_NOAUTOEN and IRQ_NOREQUEST in events.c;
- return -EINVAL from xen_remap_domain_mfn_range if
  auto_translated_physmap;
- retain binary compatibility in xen_add_to_physmap: use a union to
  introduce foreign_domid.


Shortlog and diffstat:

Stefano Stabellini (24):
      arm: initial Xen support
      xen/arm: hypercalls
      xen/arm: page.h definitions
      xen/arm: sync_bitops
      xen/arm: empty implementation of grant_table arch specific functions
      docs: Xen ARM DT bindings
      xen/arm: Xen detection and shared_info page mapping
      xen/arm: Introduce xen_pfn_t for pfn and mfn types
      xen/arm: Introduce xen_ulong_t for unsigned long
      xen/arm: compile and run xenbus
      xen: do not compile manage, balloon, pci, acpi, pcpu and cpu_hotplug on ARM
      xen/arm: introduce CONFIG_XEN on ARM
      xen/arm: get privilege status
      xen/arm: initialize grant_table on ARM
      xen/arm: receive Xen events on ARM
      xen: clear IRQ_NOAUTOEN and IRQ_NOREQUEST
      xen/arm: implement alloc/free_xenballooned_pages with alloc_pages/kfree
      xen: allow privcmd for HVM guests
      xen/arm: compile blkfront and blkback
      xen/arm: compile netback
      arm/v2m: initialize arch_timers even if v2m_timer is not present
      xen: missing includes
      xen: update xen_add_to_physmap interface
      MAINTAINERS: add myself as Xen ARM maintainer

 Documentation/devicetree/bindings/arm/xen.txt |   22 ++++
 MAINTAINERS                                   |    7 +
 arch/arm/Kconfig                              |   10 ++
 arch/arm/Makefile                             |    1 +
 arch/arm/include/asm/hypervisor.h             |    6 +
 arch/arm/include/asm/sync_bitops.h            |   27 ++++
 arch/arm/include/asm/xen/events.h             |   18 +++
 arch/arm/include/asm/xen/hypercall.h          |   69 ++++++++++
 arch/arm/include/asm/xen/hypervisor.h         |   19 +++
 arch/arm/include/asm/xen/interface.h          |   73 +++++++++++
 arch/arm/include/asm/xen/page.h               |   82 ++++++++++++
 arch/arm/mach-vexpress/v2m.c                  |   11 +-
 arch/arm/xen/Makefile                         |    1 +
 arch/arm/xen/enlighten.c                      |  168 +++++++++++++++++++++++++
 arch/arm/xen/grant-table.c                    |   53 ++++++++
 arch/arm/xen/hypercall.S                      |  106 ++++++++++++++++
 arch/ia64/include/asm/xen/interface.h         |    8 +-
 arch/x86/include/asm/xen/interface.h          |    8 ++
 arch/x86/xen/enlighten.c                      |    1 +
 arch/x86/xen/irq.c                            |    1 +
 arch/x86/xen/mmu.c                            |    3 +
 arch/x86/xen/xen-ops.h                        |    1 -
 drivers/block/xen-blkback/blkback.c           |    1 +
 drivers/net/xen-netback/netback.c             |    1 +
 drivers/net/xen-netfront.c                    |    1 +
 drivers/tty/hvc/hvc_xen.c                     |    2 +
 drivers/xen/Makefile                          |   13 ++-
 drivers/xen/events.c                          |   18 +++-
 drivers/xen/grant-table.c                     |    1 +
 drivers/xen/privcmd.c                         |    4 -
 drivers/xen/xenbus/xenbus_comms.c             |    2 +-
 drivers/xen/xenbus/xenbus_probe.c             |   62 +++++++---
 drivers/xen/xenbus/xenbus_probe_frontend.c    |    1 +
 drivers/xen/xenbus/xenbus_xs.c                |    3 +-
 include/xen/events.h                          |    2 +
 include/xen/interface/features.h              |    3 +
 include/xen/interface/grant_table.h           |    4 +-
 include/xen/interface/io/protocols.h          |    3 +
 include/xen/interface/memory.h                |   21 ++--
 include/xen/interface/physdev.h               |    2 +-
 include/xen/interface/platform.h              |    4 +-
 include/xen/interface/version.h               |    2 +-
 include/xen/interface/xen.h                   |    7 +-
 include/xen/privcmd.h                         |    3 +-
 include/xen/xen.h                             |    2 +-
 45 files changed, 796 insertions(+), 61 deletions(-)



A branch based on 3.6-rc5 is available here:

git://xenbits.xen.org/people/sstabellini/linux-pvhvm.git 3.6-rc5-arm-4


Cheers,

Stefano
--_004_alpineDEB20212081616185504850kaballukxensourcecom_
Content-Type: text/plain; charset="US-ASCII"; name="vexpress-v2m-rs1.dtsi"
Content-Transfer-Encoding: BASE64
Content-ID: <alpine.DEB.2.02.1209141210430.29232@kaball.uk.xensource.com>
Content-Description: 
Content-Disposition: attachment; filename="vexpress-v2m-rs1.dtsi"

LyoNCiAqIEFSTSBMdGQuIFZlcnNhdGlsZSBFeHByZXNzDQogKg0KICogTW90
aGVyYm9hcmQgRXhwcmVzcyB1QVRYDQogKiBWMk0tUDENCiAqDQogKiBIQkkt
MDE5MEQNCiAqDQogKiBSUzEgbWVtb3J5IG1hcCAoIkFSTSBDb3J0ZXgtQSBT
ZXJpZXMgbWVtb3J5IG1hcCIgaW4gdGhlIGJvYXJkJ3MNCiAqIFRlY2huaWNh
bCBSZWZlcmVuY2UgTWFudWFsKQ0KICoNCiAqIFdBUk5JTkchIFRoZSBoYXJk
d2FyZSBkZXNjcmliZWQgaW4gdGhpcyBmaWxlIGlzIGluZGVwZW5kZW50IGZy
b20gdGhlDQogKiBvcmlnaW5hbCB2YXJpYW50ICh2ZXhwcmVzcy12Mm0uZHRz
aSksIGJ1dCB0aGVyZSBpcyBhIHN0cm9uZw0KICogY29ycmVzcG9uZGVuY2Ug
YmV0d2VlbiB0aGUgdHdvIGNvbmZpZ3VyYXRpb25zLg0KICoNCiAqIFRBS0Ug
Q0FSRSBXSEVOIE1BSU5UQUlOSU5HIFRISVMgRklMRSBUTyBQUk9QQUdBVEUg
QU5ZIFJFTEVWQU5UDQogKiBDSEFOR0VTIFRPIHZleHByZXNzLXYybS5kdHNp
IQ0KICovDQoNCi8gew0KCWFsaWFzZXMgew0KCQlhcm0sdjJtX3RpbWVyID0g
JnYybV90aW1lcjAxOw0KCX07DQoNCgltb3RoZXJib2FyZCB7DQoJCWNvbXBh
dGlibGUgPSAic2ltcGxlLWJ1cyI7DQoJCWFybSx2Mm0tbWVtb3J5LW1hcCA9
ICJyczEiOw0KCQkjYWRkcmVzcy1jZWxscyA9IDwyPjsgLyogU01CIGNoaXBz
ZWxlY3QgbnVtYmVyIGFuZCBvZmZzZXQgKi8NCgkJI3NpemUtY2VsbHMgPSA8
MT47DQoJCSNpbnRlcnJ1cHQtY2VsbHMgPSA8MT47DQoNCgkJZmxhc2hAMCww
MDAwMDAwMCB7DQoJCQljb21wYXRpYmxlID0gImFybSx2ZXhwcmVzcy1mbGFz
aCIsICJjZmktZmxhc2giOw0KCQkJcmVnID0gPDAgMHgwMDAwMDAwMCAweDA0
MDAwMDAwPiwNCgkJCSAgICAgIDw0IDB4MDAwMDAwMDAgMHgwNDAwMDAwMD47
DQoJCQliYW5rLXdpZHRoID0gPDQ+Ow0KCQl9Ow0KDQoJCXBzcmFtQDEsMDAw
MDAwMDAgew0KCQkJY29tcGF0aWJsZSA9ICJhcm0sdmV4cHJlc3MtcHNyYW0i
LCAibXRkLXJhbSI7DQoJCQlyZWcgPSA8MSAweDAwMDAwMDAwIDB4MDIwMDAw
MDA+Ow0KCQkJYmFuay13aWR0aCA9IDw0PjsNCgkJfTsNCg0KCQl2cmFtQDIs
MDAwMDAwMDAgew0KCQkJY29tcGF0aWJsZSA9ICJhcm0sdmV4cHJlc3MtdnJh
bSI7DQoJCQlyZWcgPSA8MiAweDAwMDAwMDAwIDB4MDA4MDAwMDA+Ow0KCQl9
Ow0KDQoJCWV0aGVybmV0QDIsMDIwMDAwMDAgew0KCQkJY29tcGF0aWJsZSA9
ICJzbXNjLGxhbjkxYzExMSI7DQoJCQlyZWcgPSA8MiAweDAyMDAwMDAwIDB4
MTAwMDA+Ow0KCQkJaW50ZXJydXB0cyA9IDwxNT47DQoJCX07DQoNCgkJdXNi
QDIsMDMwMDAwMDAgew0KCQkJY29tcGF0aWJsZSA9ICJueHAsdXNiLWlzcDE3
NjEiOw0KCQkJcmVnID0gPDIgMHgwMzAwMDAwMCAweDIwMDAwPjsNCgkJCWlu
dGVycnVwdHMgPSA8MTY+Ow0KCQkJcG9ydDEtb3RnOw0KCQl9Ow0KDQoJCWlv
ZnBnYUAzLDAwMDAwMDAwIHsNCgkJCWNvbXBhdGlibGUgPSAiYXJtLGFtYmEt
YnVzIiwgInNpbXBsZS1idXMiOw0KCQkJI2FkZHJlc3MtY2VsbHMgPSA8MT47
DQoJCQkjc2l6ZS1jZWxscyA9IDwxPjsNCgkJCXJhbmdlcyA9IDwwIDMgMCAw
eDIwMDAwMD47DQoNCgkJCXN5c3JlZ0AwMTAwMDAgew0KCQkJCWNvbXBhdGli
bGUgPSAiYXJtLHZleHByZXNzLXN5c3JlZyI7DQoJCQkJcmVnID0gPDB4MDEw
MDAwIDB4MTAwMD47DQoJCQl9Ow0KDQoJCQlzeXNjdGxAMDIwMDAwIHsNCgkJ
CQljb21wYXRpYmxlID0gImFybSxzcDgxMCIsICJhcm0scHJpbWVjZWxsIjsN
CgkJCQlyZWcgPSA8MHgwMjAwMDAgMHgxMDAwPjsNCgkJCX07DQoNCgkJCS8q
IFBDSS1FIEkyQyBidXMgKi8NCgkJCXYybV9pMmNfcGNpZTogaTJjQDAzMDAw
MCB7DQoJCQkJY29tcGF0aWJsZSA9ICJhcm0sdmVyc2F0aWxlLWkyYyI7DQoJ
CQkJcmVnID0gPDB4MDMwMDAwIDB4MTAwMD47DQoNCgkJCQkjYWRkcmVzcy1j
ZWxscyA9IDwxPjsNCgkJCQkjc2l6ZS1jZWxscyA9IDwwPjsNCg0KCQkJCXBj
aWUtc3dpdGNoQDYwIHsNCgkJCQkJY29tcGF0aWJsZSA9ICJpZHQsODlocGVz
MzJoOCI7DQoJCQkJCXJlZyA9IDwweDYwPjsNCgkJCQl9Ow0KCQkJfTsNCg0K
CQkJYWFjaUAwNDAwMDAgew0KCQkJCWNvbXBhdGlibGUgPSAiYXJtLHBsMDQx
IiwgImFybSxwcmltZWNlbGwiOw0KCQkJCXJlZyA9IDwweDA0MDAwMCAweDEw
MDA+Ow0KCQkJCWludGVycnVwdHMgPSA8MTE+Ow0KCQkJfTsNCg0KCQkJbW1j
aUAwNTAwMDAgew0KCQkJCWNvbXBhdGlibGUgPSAiYXJtLHBsMTgwIiwgImFy
bSxwcmltZWNlbGwiOw0KCQkJCXJlZyA9IDwweDA1MDAwMCAweDEwMDA+Ow0K
CQkJCWludGVycnVwdHMgPSA8OSAxMD47DQoJCQl9Ow0KDQoJCQlrbWlAMDYw
MDAwIHsNCgkJCQljb21wYXRpYmxlID0gImFybSxwbDA1MCIsICJhcm0scHJp
bWVjZWxsIjsNCgkJCQlyZWcgPSA8MHgwNjAwMDAgMHgxMDAwPjsNCgkJCQlp
bnRlcnJ1cHRzID0gPDEyPjsNCgkJCX07DQoNCgkJCWttaUAwNzAwMDAgew0K
CQkJCWNvbXBhdGlibGUgPSAiYXJtLHBsMDUwIiwgImFybSxwcmltZWNlbGwi
Ow0KCQkJCXJlZyA9IDwweDA3MDAwMCAweDEwMDA+Ow0KCQkJCWludGVycnVw
dHMgPSA8MTM+Ow0KCQkJfTsNCg0KCQkJdjJtX3NlcmlhbDA6IHVhcnRAMDkw
MDAwIHsNCgkJCQljb21wYXRpYmxlID0gImFybSxwbDAxMSIsICJhcm0scHJp
bWVjZWxsIjsNCgkJCQlyZWcgPSA8MHgwOTAwMDAgMHgxMDAwPjsNCgkJCQlp
bnRlcnJ1cHRzID0gPDU+Ow0KCQkJfTsNCg0KCQkJdjJtX3NlcmlhbDE6IHVh
cnRAMGEwMDAwIHsNCgkJCQljb21wYXRpYmxlID0gImFybSxwbDAxMSIsICJh
cm0scHJpbWVjZWxsIjsNCgkJCQlyZWcgPSA8MHgwYTAwMDAgMHgxMDAwPjsN
CgkJCQlpbnRlcnJ1cHRzID0gPDY+Ow0KCQkJfTsNCg0KCQkJdjJtX3Nlcmlh
bDI6IHVhcnRAMGIwMDAwIHsNCgkJCQljb21wYXRpYmxlID0gImFybSxwbDAx
MSIsICJhcm0scHJpbWVjZWxsIjsNCgkJCQlyZWcgPSA8MHgwYjAwMDAgMHgx
MDAwPjsNCgkJCQlpbnRlcnJ1cHRzID0gPDc+Ow0KCQkJfTsNCg0KCQkJdjJt
X3NlcmlhbDM6IHVhcnRAMGMwMDAwIHsNCgkJCQljb21wYXRpYmxlID0gImFy
bSxwbDAxMSIsICJhcm0scHJpbWVjZWxsIjsNCgkJCQlyZWcgPSA8MHgwYzAw
MDAgMHgxMDAwPjsNCgkJCQlpbnRlcnJ1cHRzID0gPDg+Ow0KCQkJfTsNCg0K
CQkJd2R0QDBmMDAwMCB7DQoJCQkJY29tcGF0aWJsZSA9ICJhcm0sc3A4MDUi
LCAiYXJtLHByaW1lY2VsbCI7DQoJCQkJcmVnID0gPDB4MGYwMDAwIDB4MTAw
MD47DQoJCQkJaW50ZXJydXB0cyA9IDwwPjsNCgkJCX07DQoNCgkJCXYybV90
aW1lcjAxOiB0aW1lckAxMTAwMDAgew0KCQkJCWNvbXBhdGlibGUgPSAiYXJt
LHNwODA0IiwgImFybSxwcmltZWNlbGwiOw0KCQkJCXJlZyA9IDwweDExMDAw
MCAweDEwMDA+Ow0KCQkJCWludGVycnVwdHMgPSA8Mj47DQoJCQl9Ow0KDQoJ
CQl2Mm1fdGltZXIyMzogdGltZXJAMTIwMDAwIHsNCgkJCQljb21wYXRpYmxl
ID0gImFybSxzcDgwNCIsICJhcm0scHJpbWVjZWxsIjsNCgkJCQlyZWcgPSA8
MHgxMjAwMDAgMHgxMDAwPjsNCgkJCQlpbnRlcnJ1cHRzID0gPDM+Ow0KCQkJ
fTsNCg0KCQkJLyogRFZJIEkyQyBidXMgKi8NCgkJCXYybV9pMmNfZHZpOiBp
MmNAMTYwMDAwIHsNCgkJCQljb21wYXRpYmxlID0gImFybSx2ZXJzYXRpbGUt
aTJjIjsNCgkJCQlyZWcgPSA8MHgxNjAwMDAgMHgxMDAwPjsNCg0KCQkJCSNh
ZGRyZXNzLWNlbGxzID0gPDE+Ow0KCQkJCSNzaXplLWNlbGxzID0gPDA+Ow0K
DQoJCQkJZHZpLXRyYW5zbWl0dGVyQDM5IHsNCgkJCQkJY29tcGF0aWJsZSA9
ICJzaWwsc2lpOTAyMi10cGkiLCAic2lsLHNpaTkwMjIiOw0KCQkJCQlyZWcg
PSA8MHgzOT47DQoJCQkJfTsNCg0KCQkJCWR2aS10cmFuc21pdHRlckA2MCB7
DQoJCQkJCWNvbXBhdGlibGUgPSAic2lsLHNpaTkwMjItY3BpIiwgInNpbCxz
aWk5MDIyIjsNCgkJCQkJcmVnID0gPDB4NjA+Ow0KCQkJCX07DQoJCQl9Ow0K
DQoJCQlydGNAMTcwMDAwIHsNCgkJCQljb21wYXRpYmxlID0gImFybSxwbDAz
MSIsICJhcm0scHJpbWVjZWxsIjsNCgkJCQlyZWcgPSA8MHgxNzAwMDAgMHgx
MDAwPjsNCgkJCQlpbnRlcnJ1cHRzID0gPDQ+Ow0KCQkJfTsNCg0KCQkJY29t
cGFjdC1mbGFzaEAxYTAwMDAgew0KCQkJCWNvbXBhdGlibGUgPSAiYXJtLHZl
eHByZXNzLWNmIiwgImF0YS1nZW5lcmljIjsNCgkJCQlyZWcgPSA8MHgxYTAw
MDAgMHgxMDANCgkJCQkgICAgICAgMHgxYTAxMDAgMHhmMDA+Ow0KCQkJCXJl
Zy1zaGlmdCA9IDwyPjsNCgkJCX07DQoNCgkJCWNsY2RAMWYwMDAwIHsNCgkJ
CQljb21wYXRpYmxlID0gImFybSxwbDExMSIsICJhcm0scHJpbWVjZWxsIjsN
CgkJCQlyZWcgPSA8MHgxZjAwMDAgMHgxMDAwPjsNCgkJCQlpbnRlcnJ1cHRz
ID0gPDE0PjsNCgkJCX07DQoJCX07DQoNCgkJdjJtX2ZpeGVkXzN2MzogZml4
ZWRyZWd1bGF0b3JAMCB7DQoJCQljb21wYXRpYmxlID0gInJlZ3VsYXRvci1m
aXhlZCI7DQoJCQlyZWd1bGF0b3ItbmFtZSA9ICIzVjMiOw0KCQkJcmVndWxh
dG9yLW1pbi1taWNyb3ZvbHQgPSA8MzMwMDAwMD47DQoJCQlyZWd1bGF0b3It
bWF4LW1pY3Jvdm9sdCA9IDwzMzAwMDAwPjsNCgkJCXJlZ3VsYXRvci1hbHdh
eXMtb247DQoJCX07DQoJfTsNCn07DQo=

--_004_alpineDEB20212081616185504850kaballukxensourcecom_
Content-Type: text/plain; charset="US-ASCII"; name="vexpress-v2p-ca15-tc1.dts"
Content-Transfer-Encoding: BASE64
Content-ID: <alpine.DEB.2.02.1209141210431.29232@kaball.uk.xensource.com>
Content-Description: 
Content-Disposition: attachment; filename="vexpress-v2p-ca15-tc1.dts"

LyoNCiAqIEFSTSBMdGQuIFZlcnNhdGlsZSBFeHByZXNzDQogKg0KICogQ29y
ZVRpbGUgRXhwcmVzcyBBMTV4MiAodmVyc2lvbiB3aXRoIFRlc3QgQ2hpcCAx
KQ0KICogQ29ydGV4LUExNSBNUENvcmUgKFYyUC1DQTE1KQ0KICoNCiAqIEhC
SS0wMjM3QQ0KICovDQoNCi9kdHMtdjEvOw0KDQovIHsNCgltb2RlbCA9ICJW
MlAtQ0ExNSI7DQoJYXJtLGhiaSA9IDwweDIzNz47DQoJY29tcGF0aWJsZSA9
ICJhcm0sdmV4cHJlc3MsdjJwLWNhMTUsdGMxIiwgImFybSx2ZXhwcmVzcyx2
MnAtY2ExNSIsICJhcm0sdmV4cHJlc3MiOw0KCWludGVycnVwdC1wYXJlbnQg
PSA8JmdpYz47DQoJI2FkZHJlc3MtY2VsbHMgPSA8Mj47DQoJI3NpemUtY2Vs
bHMgPSA8Mj47DQoNCgljaG9zZW4gew0KICAgICAgICAgICAgICAgICBib290
YXJncyA9ICJkb20wX21lbT0xMjhNIjsNCiAgICAgICAgICAgICAgICAgeGVu
LGRvbTAtYm9vdGFyZ3MgPSAiZWFybHlwcmludGsgY29uc29sZT10dHlBTUEx
IHJvb3Q9L2Rldi9tbWNibGswIGRlYnVnIHJ3IjsNCgl9Ow0KDQoJYWxpYXNl
cyB7DQoJCXNlcmlhbDAgPSAmdjJtX3NlcmlhbDA7DQoJCXNlcmlhbDEgPSAm
djJtX3NlcmlhbDE7DQoJCXNlcmlhbDIgPSAmdjJtX3NlcmlhbDI7DQoJCXNl
cmlhbDMgPSAmdjJtX3NlcmlhbDM7DQoJCWkyYzAgPSAmdjJtX2kyY19kdmk7
DQoJCWkyYzEgPSAmdjJtX2kyY19wY2llOw0KCX07DQoNCgljcHVzIHsNCgkJ
I2FkZHJlc3MtY2VsbHMgPSA8MT47DQoJCSNzaXplLWNlbGxzID0gPDA+Ow0K
DQoJCWNwdUAwIHsNCgkJCWRldmljZV90eXBlID0gImNwdSI7DQoJCQljb21w
YXRpYmxlID0gImFybSxjb3J0ZXgtYTE1IjsNCgkJCXJlZyA9IDwwPjsNCgkJ
fTsNCgl9Ow0KDQoJbWVtb3J5QDgwMDAwMDAwIHsNCgkJZGV2aWNlX3R5cGUg
PSAibWVtb3J5IjsNCgkJcmVnID0gPDAgMHg4MDAwMDAwMCAwIDB4ODAwMDAw
MDA+Ow0KCX07DQoNCglnaWM6IGludGVycnVwdC1jb250cm9sbGVyQDJjMDAx
MDAwIHsNCgkJY29tcGF0aWJsZSA9ICJhcm0sY29ydGV4LWExNS1naWMiLCAi
YXJtLGNvcnRleC1hOS1naWMiOw0KCQkjaW50ZXJydXB0LWNlbGxzID0gPDM+
Ow0KCQkjYWRkcmVzcy1jZWxscyA9IDwwPjsNCgkJaW50ZXJydXB0LWNvbnRy
b2xsZXI7DQoJCXJlZyA9IDwwIDB4MmMwMDEwMDAgMCAweDEwMDA+LA0KCQkg
ICAgICA8MCAweDJjMDAyMDAwIDAgMHgxMDAwPiwNCgkJICAgICAgPDAgMHgy
YzAwNDAwMCAwIDB4MjAwMD4sDQoJCSAgICAgIDwwIDB4MmMwMDYwMDAgMCAw
eDIwMDA+Ow0KCQlpbnRlcnJ1cHRzID0gPDEgOSAweGYwND47DQoJfTsNCg0K
CXRpbWVyIHsNCgkJY29tcGF0aWJsZSA9ICJhcm0sYXJtdjctdGltZXIiOw0K
CQlpbnRlcnJ1cHRzID0gPDEgMTMgMHhmMDg+LA0KCQkJICAgICA8MSAxNCAw
eGYwOD4sDQoJCQkgICAgIDwxIDExIDB4ZjA4PiwNCgkJCSAgICAgPDEgMTAg
MHhmMDg+Ow0KCX07DQoNCglwbXUgew0KCQljb21wYXRpYmxlID0gImFybSxj
b3J0ZXgtYTE1LXBtdSIsICJhcm0sY29ydGV4LWE5LXBtdSI7DQoJCWludGVy
cnVwdHMgPSA8MCA2OCA0PiwNCgkJCSAgICAgPDAgNjkgND47DQoJfTsNCg0K
CWh5cGVydmlzb3Igew0KCQljb21wYXRpYmxlID0gInhlbix4ZW4tNC4yIiwg
Inhlbix4ZW4iOw0KCQlyZWcgPSA8MCAweGIwMDAwMDAwIDAgMHgyMDAwMD47
DQoJCWludGVycnVwdHMgPSA8MSAxNSAweGYwOD47DQoJfTsNCg0KCW1vdGhl
cmJvYXJkIHsNCgkJcmFuZ2VzID0gPDAgMCAwIDB4MDgwMDAwMDAgMHgwNDAw
MDAwMD4sDQoJCQkgPDEgMCAwIDB4MTQwMDAwMDAgMHgwNDAwMDAwMD4sDQoJ
CQkgPDIgMCAwIDB4MTgwMDAwMDAgMHgwNDAwMDAwMD4sDQoJCQkgPDMgMCAw
IDB4MWMwMDAwMDAgMHgwNDAwMDAwMD4sDQoJCQkgPDQgMCAwIDB4MGMwMDAw
MDAgMHgwNDAwMDAwMD4sDQoJCQkgPDUgMCAwIDB4MTAwMDAwMDAgMHgwNDAw
MDAwMD47DQoNCgkJaW50ZXJydXB0LW1hcC1tYXNrID0gPDAgMCA2Mz47DQoJ
CWludGVycnVwdC1tYXAgPSA8MCAwICAwICZnaWMgMCAgMCA0PiwNCgkJCQk8
MCAwICAxICZnaWMgMCAgMSA0PiwNCgkJCQk8MCAwICAyICZnaWMgMCAgMiA0
PiwNCgkJCQk8MCAwICAzICZnaWMgMCAgMyA0PiwNCgkJCQk8MCAwICA0ICZn
aWMgMCAgNCA0PiwNCgkJCQk8MCAwICA1ICZnaWMgMCAgNSA0PiwNCgkJCQk8
MCAwICA2ICZnaWMgMCAgNiA0PiwNCgkJCQk8MCAwICA3ICZnaWMgMCAgNyA0
PiwNCgkJCQk8MCAwICA4ICZnaWMgMCAgOCA0PiwNCgkJCQk8MCAwICA5ICZn
aWMgMCAgOSA0PiwNCgkJCQk8MCAwIDEwICZnaWMgMCAxMCA0PiwNCgkJCQk8
MCAwIDExICZnaWMgMCAxMSA0PiwNCgkJCQk8MCAwIDEyICZnaWMgMCAxMiA0
PiwNCgkJCQk8MCAwIDEzICZnaWMgMCAxMyA0PiwNCgkJCQk8MCAwIDE0ICZn
aWMgMCAxNCA0PiwNCgkJCQk8MCAwIDE1ICZnaWMgMCAxNSA0PiwNCgkJCQk8
MCAwIDE2ICZnaWMgMCAxNiA0PiwNCgkJCQk8MCAwIDE3ICZnaWMgMCAxNyA0
PiwNCgkJCQk8MCAwIDE4ICZnaWMgMCAxOCA0PiwNCgkJCQk8MCAwIDE5ICZn
aWMgMCAxOSA0PiwNCgkJCQk8MCAwIDIwICZnaWMgMCAyMCA0PiwNCgkJCQk8
MCAwIDIxICZnaWMgMCAyMSA0PiwNCgkJCQk8MCAwIDIyICZnaWMgMCAyMiA0
PiwNCgkJCQk8MCAwIDIzICZnaWMgMCAyMyA0PiwNCgkJCQk8MCAwIDI0ICZn
aWMgMCAyNCA0PiwNCgkJCQk8MCAwIDI1ICZnaWMgMCAyNSA0PiwNCgkJCQk8
MCAwIDI2ICZnaWMgMCAyNiA0PiwNCgkJCQk8MCAwIDI3ICZnaWMgMCAyNyA0
PiwNCgkJCQk8MCAwIDI4ICZnaWMgMCAyOCA0PiwNCgkJCQk8MCAwIDI5ICZn
aWMgMCAyOSA0PiwNCgkJCQk8MCAwIDMwICZnaWMgMCAzMCA0PiwNCgkJCQk8
MCAwIDMxICZnaWMgMCAzMSA0PiwNCgkJCQk8MCAwIDMyICZnaWMgMCAzMiA0
PiwNCgkJCQk8MCAwIDMzICZnaWMgMCAzMyA0PiwNCgkJCQk8MCAwIDM0ICZn
aWMgMCAzNCA0PiwNCgkJCQk8MCAwIDM1ICZnaWMgMCAzNSA0PiwNCgkJCQk8
MCAwIDM2ICZnaWMgMCAzNiA0PiwNCgkJCQk8MCAwIDM3ICZnaWMgMCAzNyA0
PiwNCgkJCQk8MCAwIDM4ICZnaWMgMCAzOCA0PiwNCgkJCQk8MCAwIDM5ICZn
aWMgMCAzOSA0PiwNCgkJCQk8MCAwIDQwICZnaWMgMCA0MCA0PiwNCgkJCQk8
MCAwIDQxICZnaWMgMCA0MSA0PiwNCgkJCQk8MCAwIDQyICZnaWMgMCA0MiA0
PjsNCgl9Ow0KfTsNCg0KL2luY2x1ZGUvICJ2ZXhwcmVzcy12Mm0tcnMxLmR0
c2kiDQo=

--_004_alpineDEB20212081616185504850kaballukxensourcecom_
Content-Type: text/plain; charset="US-ASCII"; name="vexpress-virt.dts"
Content-Transfer-Encoding: BASE64
Content-ID: <alpine.DEB.2.02.1209141210432.29232@kaball.uk.xensource.com>
Content-Description: 
Content-Disposition: attachment; filename="vexpress-virt.dts"

LyoNCiAqIEFSTSBMdGQuIFZlcnNhdGlsZSBFeHByZXNzDQogKg0KICogQVJN
IEVudmVsb3BlIE1vZGVsIHY3QSAoc2luZ2xlIENQVSkuDQogKi8NCg0KL2R0
cy12MS87DQoNCi9pbmNsdWRlLyAic2tlbGV0b24uZHRzaSINCg0KLyB7DQoJ
bW9kZWwgPSAiVjJQLUFFTXY3QSI7DQoJY29tcGF0aWJsZSA9ICJhcm0sdmV4
cHJlc3MsdjJwLWFlbSx2N2EiLCAiYXJtLHZleHByZXNzLHYycC1hZW0iLCAi
YXJtLHZleHByZXNzIjsNCglpbnRlcnJ1cHQtcGFyZW50ID0gPCZnaWM+Ow0K
DQogICAgICAgIGNob3NlbiB7DQogICAgICAgICAgICAgICAgYm9vdGFyZ3Mg
PSAiZWFybHlwcmludGsgZGVidWcgbG9nbGV2ZWw9OSBjb25zb2xlPWh2YzAg
cm9vdD0vZGV2L3h2ZGEgaW5pdD0vc2Jpbi9pbml0IjsNCiAgICAgICAgfTsN
Cg0KCWNwdXMgew0KCQkjYWRkcmVzcy1jZWxscyA9IDwxPjsNCgkJI3NpemUt
Y2VsbHMgPSA8MD47DQoNCgkJY3B1QDAgew0KCQkJZGV2aWNlX3R5cGUgPSAi
Y3B1IjsNCgkJCWNvbXBhdGlibGUgPSAiYXJtLGNvcnRleC1hMTUiOw0KCQkJ
cmVnID0gPDA+Ow0KCQl9Ow0KCX07DQoNCgltZW1vcnkgew0KCQlkZXZpY2Vf
dHlwZSA9ICJtZW1vcnkiOw0KCQlyZWcgPSA8MHg4MDAwMDAwMCAweDA4MDAw
MDAwPjsNCgl9Ow0KDQoJZ2ljOiBpbnRlcnJ1cHQtY29udHJvbGxlckAyYzAw
MTAwMCB7DQoJCWNvbXBhdGlibGUgPSAiYXJtLGNvcnRleC1hOS1naWMiOw0K
CQkjaW50ZXJydXB0LWNlbGxzID0gPDM+Ow0KCQkjYWRkcmVzcy1jZWxscyA9
IDwwPjsNCgkJaW50ZXJydXB0LWNvbnRyb2xsZXI7DQoJCXJlZyA9IDwweDJj
MDAxMDAwIDB4MTAwMD4sDQoJCSAgICAgIDwweDJjMDAyMDAwIDB4MTAwPjsN
Cgl9Ow0KDQoJdGltZXIgew0KCQljb21wYXRpYmxlID0gImFybSxhcm12Ny10
aW1lciI7DQoJCWludGVycnVwdHMgPSA8MSAxMyAweGYwOD4sDQoJCQkgICAg
IDwxIDE0IDB4ZjA4PiwNCgkJCSAgICAgPDEgMTEgMHhmMDg+LA0KCQkJICAg
ICA8MSAxMCAweGYwOD47DQoJfTsNCg0KCWh5cGVydmlzb3Igew0KCQljb21w
YXRpYmxlID0gInhlbix4ZW4tNC4yIiwgInhlbix4ZW4iOw0KCQlyZWcgPSA8
MHhiMDAwMDAwMCAweDIwMDAwPjsNCgkJaW50ZXJydXB0cyA9IDwxIDE1IDB4
ZjA4PjsNCgl9Ow0KDQoJbW90aGVyYm9hcmQgew0KCQlhcm0sdjJtLW1lbW9y
eS1tYXAgPSAicnMxIjsNCgkJcmFuZ2VzID0gPDAgMCAweDA4MDAwMDAwIDB4
MDQwMDAwMDA+LA0KCQkJIDwxIDAgMHgxNDAwMDAwMCAweDA0MDAwMDAwPiwN
CgkJCSA8MiAwIDB4MTgwMDAwMDAgMHgwNDAwMDAwMD4sDQoJCQkgPDMgMCAw
eDFjMDAwMDAwIDB4MDQwMDAwMDA+LA0KCQkJIDw0IDAgMHgwYzAwMDAwMCAw
eDA0MDAwMDAwPiwNCgkJCSA8NSAwIDB4MTAwMDAwMDAgMHgwNDAwMDAwMD47
DQoNCgkJaW50ZXJydXB0LW1hcC1tYXNrID0gPDAgMCA2Mz47DQoJCWludGVy
cnVwdC1tYXAgPSA8MCAwICAwICZnaWMgMCAgMCA0PiwNCgkJCQk8MCAwICAx
ICZnaWMgMCAgMSA0PiwNCgkJCQk8MCAwICAyICZnaWMgMCAgMiA0PiwNCgkJ
CQk8MCAwICAzICZnaWMgMCAgMyA0PiwNCgkJCQk8MCAwICA0ICZnaWMgMCAg
NCA0PiwNCgkJCQk8MCAwICA1ICZnaWMgMCAgNSA0PiwNCgkJCQk8MCAwICA2
ICZnaWMgMCAgNiA0PiwNCgkJCQk8MCAwICA3ICZnaWMgMCAgNyA0PiwNCgkJ
CQk8MCAwICA4ICZnaWMgMCAgOCA0PiwNCgkJCQk8MCAwICA5ICZnaWMgMCAg
OSA0PiwNCgkJCQk8MCAwIDEwICZnaWMgMCAxMCA0PiwNCgkJCQk8MCAwIDEx
ICZnaWMgMCAxMSA0PiwNCgkJCQk8MCAwIDEyICZnaWMgMCAxMiA0PiwNCgkJ
CQk8MCAwIDEzICZnaWMgMCAxMyA0PiwNCgkJCQk8MCAwIDE0ICZnaWMgMCAx
NCA0PiwNCgkJCQk8MCAwIDE1ICZnaWMgMCAxNSA0PiwNCgkJCQk8MCAwIDE2
ICZnaWMgMCAxNiA0PiwNCgkJCQk8MCAwIDE3ICZnaWMgMCAxNyA0PiwNCgkJ
CQk8MCAwIDE4ICZnaWMgMCAxOCA0PiwNCgkJCQk8MCAwIDE5ICZnaWMgMCAx
OSA0PiwNCgkJCQk8MCAwIDIwICZnaWMgMCAyMCA0PiwNCgkJCQk8MCAwIDIx
ICZnaWMgMCAyMSA0PiwNCgkJCQk8MCAwIDIyICZnaWMgMCAyMiA0PiwNCgkJ
CQk8MCAwIDIzICZnaWMgMCAyMyA0PiwNCgkJCQk8MCAwIDI0ICZnaWMgMCAy
NCA0PiwNCgkJCQk8MCAwIDI1ICZnaWMgMCAyNSA0PiwNCgkJCQk8MCAwIDI2
ICZnaWMgMCAyNiA0PiwNCgkJCQk8MCAwIDI3ICZnaWMgMCAyNyA0PiwNCgkJ
CQk8MCAwIDI4ICZnaWMgMCAyOCA0PiwNCgkJCQk8MCAwIDI5ICZnaWMgMCAy
OSA0PiwNCgkJCQk8MCAwIDMwICZnaWMgMCAzMCA0PiwNCgkJCQk8MCAwIDMx
ICZnaWMgMCAzMSA0PiwNCgkJCQk8MCAwIDMyICZnaWMgMCAzMiA0PiwNCgkJ
CQk8MCAwIDMzICZnaWMgMCAzMyA0PiwNCgkJCQk8MCAwIDM0ICZnaWMgMCAz
NCA0PiwNCgkJCQk8MCAwIDM1ICZnaWMgMCAzNSA0PiwNCgkJCQk8MCAwIDM2
ICZnaWMgMCAzNiA0PiwNCgkJCQk8MCAwIDM3ICZnaWMgMCAzNyA0PiwNCgkJ
CQk8MCAwIDM4ICZnaWMgMCAzOCA0PiwNCgkJCQk8MCAwIDM5ICZnaWMgMCAz
OSA0PiwNCgkJCQk8MCAwIDQwICZnaWMgMCA0MCA0PiwNCgkJCQk8MCAwIDQx
ICZnaWMgMCA0MSA0PiwNCgkJCQk8MCAwIDQyICZnaWMgMCA0MiA0PjsNCgl9
Ow0KfTsNCg0KLyogL2luY2x1ZGUvICJ2ZXhwcmVzcy12Mm0tcnMxLXJ0c20u
ZHRzaSIgKi8NCg==

--_004_alpineDEB20212081616185504850kaballukxensourcecom_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--_004_alpineDEB20212081616185504850kaballukxensourcecom_--


From xen-devel-bounces@lists.xen.org Fri Sep 14 11:14:25 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 11: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 1TCTqE-0005Hf-A7; Fri, 14 Sep 2012 11:13:46 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1TCTqC-0005HV-LL
	for xen-devel@lists.xensource.com; Fri, 14 Sep 2012 11:13:45 +0000
Received: from [85.158.143.99:17860] by server-2.bemta-4.messagelabs.com id
	44/FD-21239-76113505; Fri, 14 Sep 2012 11:13:43 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1347621222!20568062!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDkyOTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22801 invoked from network); 14 Sep 2012 11:13:42 -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;
	14 Sep 2012 11:13:42 -0000
X-IronPort-AV: E=Sophos;i="4.80,422,1344211200"; 
	d="dts'?dtsi'?scan'208";a="14543401"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Sep 2012 11:13: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.279.1; Fri, 14 Sep 2012 12:13:42 +0100
Date: Fri, 14 Sep 2012 12:12:59 +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>
Message-ID: <alpine.DEB.2.02.1209141145150.29232@kaball.uk.xensource.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Content-Type: multipart/mixed;
	boundary="_004_alpineDEB20212081616185504850kaballukxensourcecom_"
Content-ID: <alpine.DEB.2.02.1209141145151.29232@kaball.uk.xensource.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linaro-dev@lists.linaro.org" <linaro-dev@lists.linaro.org>,
	Ian Campbell <Ian.Campbell@citrix.com>, "arnd@arndb.de" <arnd@arndb.de>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"catalin.marinas@arm.com" <catalin.marinas@arm.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>, "Tim
	\(Xen.org\)" <tim@xen.org>,
	Russell King - ARM Linux <linux@arm.linux.org.uk>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: [Xen-devel] [PATCH v4 00/24] Introduce Xen support on ARM (based on
	3.6-rc5)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--_004_alpineDEB20212081616185504850kaballukxensourcecom_
Content-Type: text/plain; charset="US-ASCII"
Content-ID: <alpine.DEB.2.02.1209141145152.29232@kaball.uk.xensource.com>

Hi all,
this patch series implements Xen support for ARMv7 with virtualization
extensions.  It allows a Linux guest to boot as dom0 and
as domU on Xen on ARM. PV console, disk and network frontends and
backends are all working correctly.

It has been tested on a Versatile Express Cortex A15 emulator, using the
latest Xen ARM developement branch
(git://xenbits.xen.org/people/ianc/xen-unstable.git arm-for-4.3) plus
the "ARM hypercall ABI: 64 bit ready" patch series
(http://marc.info/?l=xen-devel&m=134426267205408), and a simple ad-hoc
tool to build guest domains (marc.info/?l=xen-devel&m=134089788016546).

The patch marked with [HACK] has been dropped from this series, however
you can find it here:
http://marc.info/?l=linux-kernel&m=134513277823527&w=2.

I am also attaching to this email the dts'es that I am currently using
for dom0 and domU: vexpress-v2p-ca15-tc1.dts (that includes
vexpress-v2m-rs1-rtsm.dtsi) is the dts used for dom0 and it is passed to
Linux by Xen, while vexpress-virt.dts is the dts used for other domUs
and it is appended in binary form to the guest kernel image. I am not
sure where they are supposed to live yet, so I am just attaching them
here so that people can actually try out this series if they want to.

Comments are very welcome!



Patch #21 "arm/v2m: initialize arch_timers even if v2m_timer is not
present" touches generic ARM code and still needs to be acked/reviewed.

Arnd, Russell, what do you think about this series? If you are OK with
it, to whom should I submit it?



Changes in v4:
- rebase on 3.6-rc5;
- devicetree: "xen,xen" should be last as it is less specific;
- devicetree: use 2 address-cells and 2 size-cells in the reg property;
- do not xs_reset_watches on dom0;
- compile drivers/xen/pcpu.c only on x86;
- use "+=" instead of ":=" for dom0- targets;
- add a patch to update the MAINTAINERS file.


Changes in v3:
- move patches that have been picked up by Konrad at the end of the
  series;
- improve comments;
- add a doc to describe the Xen Device Tree format;
- do not use xen_ulong_t for multicalls and apic_physbase;
- add a patch at the end of the series to use the new __HVC macro;
- add missing pvclock-abi.h include to ia64 header files;
- do not use an anonymous union in struct xen_add_to_physmap.


Changes in v2:
- fix up many comments and commit messages;
- remove the early_printk patches: rely on the emulated serial for now;
- remove the xen_guest_init patch: without any PV early_printk, we don't
  need any early call to xen_guest_init, we can rely on core_initcall
  alone;
- define an HYPERCALL macro for 5 arguments hypercall wrappers, even if
  at the moment is unused;
- use ldm instead of pop in the hypercall wrappers;
- return -ENOSYS rather than -1 from the unimplemented grant_table
  functions;
- remove the pvclock ifdef in the Xen headers;
- remove include linux/types.h from xen/interface/xen.h;
- replace pr_info with pr_debug in xen_guest_init;
- add a new patch to introduce xen_ulong_t and use it top replace all
  the occurences of unsigned long in the public Xen interface;
- explicitely size all the pointers to 64 bit on ARM, so that the
  hypercall ABI is "64 bit ready";
- clean up xenbus_init;
- make pci.o depend on CONFIG_PCI and acpi.o depend on CONFIG_ACPI;
- mark Xen guest support on ARM as EXPERIMENTAL;
- introduce GRANT_TABLE_PHYSADDR;
- remove unneeded initialization of boot_max_nr_grant_frames;
- add a new patch to clear IRQ_NOAUTOEN and IRQ_NOREQUEST in events.c;
- return -EINVAL from xen_remap_domain_mfn_range if
  auto_translated_physmap;
- retain binary compatibility in xen_add_to_physmap: use a union to
  introduce foreign_domid.


Shortlog and diffstat:

Stefano Stabellini (24):
      arm: initial Xen support
      xen/arm: hypercalls
      xen/arm: page.h definitions
      xen/arm: sync_bitops
      xen/arm: empty implementation of grant_table arch specific functions
      docs: Xen ARM DT bindings
      xen/arm: Xen detection and shared_info page mapping
      xen/arm: Introduce xen_pfn_t for pfn and mfn types
      xen/arm: Introduce xen_ulong_t for unsigned long
      xen/arm: compile and run xenbus
      xen: do not compile manage, balloon, pci, acpi, pcpu and cpu_hotplug on ARM
      xen/arm: introduce CONFIG_XEN on ARM
      xen/arm: get privilege status
      xen/arm: initialize grant_table on ARM
      xen/arm: receive Xen events on ARM
      xen: clear IRQ_NOAUTOEN and IRQ_NOREQUEST
      xen/arm: implement alloc/free_xenballooned_pages with alloc_pages/kfree
      xen: allow privcmd for HVM guests
      xen/arm: compile blkfront and blkback
      xen/arm: compile netback
      arm/v2m: initialize arch_timers even if v2m_timer is not present
      xen: missing includes
      xen: update xen_add_to_physmap interface
      MAINTAINERS: add myself as Xen ARM maintainer

 Documentation/devicetree/bindings/arm/xen.txt |   22 ++++
 MAINTAINERS                                   |    7 +
 arch/arm/Kconfig                              |   10 ++
 arch/arm/Makefile                             |    1 +
 arch/arm/include/asm/hypervisor.h             |    6 +
 arch/arm/include/asm/sync_bitops.h            |   27 ++++
 arch/arm/include/asm/xen/events.h             |   18 +++
 arch/arm/include/asm/xen/hypercall.h          |   69 ++++++++++
 arch/arm/include/asm/xen/hypervisor.h         |   19 +++
 arch/arm/include/asm/xen/interface.h          |   73 +++++++++++
 arch/arm/include/asm/xen/page.h               |   82 ++++++++++++
 arch/arm/mach-vexpress/v2m.c                  |   11 +-
 arch/arm/xen/Makefile                         |    1 +
 arch/arm/xen/enlighten.c                      |  168 +++++++++++++++++++++++++
 arch/arm/xen/grant-table.c                    |   53 ++++++++
 arch/arm/xen/hypercall.S                      |  106 ++++++++++++++++
 arch/ia64/include/asm/xen/interface.h         |    8 +-
 arch/x86/include/asm/xen/interface.h          |    8 ++
 arch/x86/xen/enlighten.c                      |    1 +
 arch/x86/xen/irq.c                            |    1 +
 arch/x86/xen/mmu.c                            |    3 +
 arch/x86/xen/xen-ops.h                        |    1 -
 drivers/block/xen-blkback/blkback.c           |    1 +
 drivers/net/xen-netback/netback.c             |    1 +
 drivers/net/xen-netfront.c                    |    1 +
 drivers/tty/hvc/hvc_xen.c                     |    2 +
 drivers/xen/Makefile                          |   13 ++-
 drivers/xen/events.c                          |   18 +++-
 drivers/xen/grant-table.c                     |    1 +
 drivers/xen/privcmd.c                         |    4 -
 drivers/xen/xenbus/xenbus_comms.c             |    2 +-
 drivers/xen/xenbus/xenbus_probe.c             |   62 +++++++---
 drivers/xen/xenbus/xenbus_probe_frontend.c    |    1 +
 drivers/xen/xenbus/xenbus_xs.c                |    3 +-
 include/xen/events.h                          |    2 +
 include/xen/interface/features.h              |    3 +
 include/xen/interface/grant_table.h           |    4 +-
 include/xen/interface/io/protocols.h          |    3 +
 include/xen/interface/memory.h                |   21 ++--
 include/xen/interface/physdev.h               |    2 +-
 include/xen/interface/platform.h              |    4 +-
 include/xen/interface/version.h               |    2 +-
 include/xen/interface/xen.h                   |    7 +-
 include/xen/privcmd.h                         |    3 +-
 include/xen/xen.h                             |    2 +-
 45 files changed, 796 insertions(+), 61 deletions(-)



A branch based on 3.6-rc5 is available here:

git://xenbits.xen.org/people/sstabellini/linux-pvhvm.git 3.6-rc5-arm-4


Cheers,

Stefano
--_004_alpineDEB20212081616185504850kaballukxensourcecom_
Content-Type: text/plain; charset="US-ASCII"; name="vexpress-v2m-rs1.dtsi"
Content-Transfer-Encoding: BASE64
Content-ID: <alpine.DEB.2.02.1209141210430.29232@kaball.uk.xensource.com>
Content-Description: 
Content-Disposition: attachment; filename="vexpress-v2m-rs1.dtsi"

LyoNCiAqIEFSTSBMdGQuIFZlcnNhdGlsZSBFeHByZXNzDQogKg0KICogTW90
aGVyYm9hcmQgRXhwcmVzcyB1QVRYDQogKiBWMk0tUDENCiAqDQogKiBIQkkt
MDE5MEQNCiAqDQogKiBSUzEgbWVtb3J5IG1hcCAoIkFSTSBDb3J0ZXgtQSBT
ZXJpZXMgbWVtb3J5IG1hcCIgaW4gdGhlIGJvYXJkJ3MNCiAqIFRlY2huaWNh
bCBSZWZlcmVuY2UgTWFudWFsKQ0KICoNCiAqIFdBUk5JTkchIFRoZSBoYXJk
d2FyZSBkZXNjcmliZWQgaW4gdGhpcyBmaWxlIGlzIGluZGVwZW5kZW50IGZy
b20gdGhlDQogKiBvcmlnaW5hbCB2YXJpYW50ICh2ZXhwcmVzcy12Mm0uZHRz
aSksIGJ1dCB0aGVyZSBpcyBhIHN0cm9uZw0KICogY29ycmVzcG9uZGVuY2Ug
YmV0d2VlbiB0aGUgdHdvIGNvbmZpZ3VyYXRpb25zLg0KICoNCiAqIFRBS0Ug
Q0FSRSBXSEVOIE1BSU5UQUlOSU5HIFRISVMgRklMRSBUTyBQUk9QQUdBVEUg
QU5ZIFJFTEVWQU5UDQogKiBDSEFOR0VTIFRPIHZleHByZXNzLXYybS5kdHNp
IQ0KICovDQoNCi8gew0KCWFsaWFzZXMgew0KCQlhcm0sdjJtX3RpbWVyID0g
JnYybV90aW1lcjAxOw0KCX07DQoNCgltb3RoZXJib2FyZCB7DQoJCWNvbXBh
dGlibGUgPSAic2ltcGxlLWJ1cyI7DQoJCWFybSx2Mm0tbWVtb3J5LW1hcCA9
ICJyczEiOw0KCQkjYWRkcmVzcy1jZWxscyA9IDwyPjsgLyogU01CIGNoaXBz
ZWxlY3QgbnVtYmVyIGFuZCBvZmZzZXQgKi8NCgkJI3NpemUtY2VsbHMgPSA8
MT47DQoJCSNpbnRlcnJ1cHQtY2VsbHMgPSA8MT47DQoNCgkJZmxhc2hAMCww
MDAwMDAwMCB7DQoJCQljb21wYXRpYmxlID0gImFybSx2ZXhwcmVzcy1mbGFz
aCIsICJjZmktZmxhc2giOw0KCQkJcmVnID0gPDAgMHgwMDAwMDAwMCAweDA0
MDAwMDAwPiwNCgkJCSAgICAgIDw0IDB4MDAwMDAwMDAgMHgwNDAwMDAwMD47
DQoJCQliYW5rLXdpZHRoID0gPDQ+Ow0KCQl9Ow0KDQoJCXBzcmFtQDEsMDAw
MDAwMDAgew0KCQkJY29tcGF0aWJsZSA9ICJhcm0sdmV4cHJlc3MtcHNyYW0i
LCAibXRkLXJhbSI7DQoJCQlyZWcgPSA8MSAweDAwMDAwMDAwIDB4MDIwMDAw
MDA+Ow0KCQkJYmFuay13aWR0aCA9IDw0PjsNCgkJfTsNCg0KCQl2cmFtQDIs
MDAwMDAwMDAgew0KCQkJY29tcGF0aWJsZSA9ICJhcm0sdmV4cHJlc3MtdnJh
bSI7DQoJCQlyZWcgPSA8MiAweDAwMDAwMDAwIDB4MDA4MDAwMDA+Ow0KCQl9
Ow0KDQoJCWV0aGVybmV0QDIsMDIwMDAwMDAgew0KCQkJY29tcGF0aWJsZSA9
ICJzbXNjLGxhbjkxYzExMSI7DQoJCQlyZWcgPSA8MiAweDAyMDAwMDAwIDB4
MTAwMDA+Ow0KCQkJaW50ZXJydXB0cyA9IDwxNT47DQoJCX07DQoNCgkJdXNi
QDIsMDMwMDAwMDAgew0KCQkJY29tcGF0aWJsZSA9ICJueHAsdXNiLWlzcDE3
NjEiOw0KCQkJcmVnID0gPDIgMHgwMzAwMDAwMCAweDIwMDAwPjsNCgkJCWlu
dGVycnVwdHMgPSA8MTY+Ow0KCQkJcG9ydDEtb3RnOw0KCQl9Ow0KDQoJCWlv
ZnBnYUAzLDAwMDAwMDAwIHsNCgkJCWNvbXBhdGlibGUgPSAiYXJtLGFtYmEt
YnVzIiwgInNpbXBsZS1idXMiOw0KCQkJI2FkZHJlc3MtY2VsbHMgPSA8MT47
DQoJCQkjc2l6ZS1jZWxscyA9IDwxPjsNCgkJCXJhbmdlcyA9IDwwIDMgMCAw
eDIwMDAwMD47DQoNCgkJCXN5c3JlZ0AwMTAwMDAgew0KCQkJCWNvbXBhdGli
bGUgPSAiYXJtLHZleHByZXNzLXN5c3JlZyI7DQoJCQkJcmVnID0gPDB4MDEw
MDAwIDB4MTAwMD47DQoJCQl9Ow0KDQoJCQlzeXNjdGxAMDIwMDAwIHsNCgkJ
CQljb21wYXRpYmxlID0gImFybSxzcDgxMCIsICJhcm0scHJpbWVjZWxsIjsN
CgkJCQlyZWcgPSA8MHgwMjAwMDAgMHgxMDAwPjsNCgkJCX07DQoNCgkJCS8q
IFBDSS1FIEkyQyBidXMgKi8NCgkJCXYybV9pMmNfcGNpZTogaTJjQDAzMDAw
MCB7DQoJCQkJY29tcGF0aWJsZSA9ICJhcm0sdmVyc2F0aWxlLWkyYyI7DQoJ
CQkJcmVnID0gPDB4MDMwMDAwIDB4MTAwMD47DQoNCgkJCQkjYWRkcmVzcy1j
ZWxscyA9IDwxPjsNCgkJCQkjc2l6ZS1jZWxscyA9IDwwPjsNCg0KCQkJCXBj
aWUtc3dpdGNoQDYwIHsNCgkJCQkJY29tcGF0aWJsZSA9ICJpZHQsODlocGVz
MzJoOCI7DQoJCQkJCXJlZyA9IDwweDYwPjsNCgkJCQl9Ow0KCQkJfTsNCg0K
CQkJYWFjaUAwNDAwMDAgew0KCQkJCWNvbXBhdGlibGUgPSAiYXJtLHBsMDQx
IiwgImFybSxwcmltZWNlbGwiOw0KCQkJCXJlZyA9IDwweDA0MDAwMCAweDEw
MDA+Ow0KCQkJCWludGVycnVwdHMgPSA8MTE+Ow0KCQkJfTsNCg0KCQkJbW1j
aUAwNTAwMDAgew0KCQkJCWNvbXBhdGlibGUgPSAiYXJtLHBsMTgwIiwgImFy
bSxwcmltZWNlbGwiOw0KCQkJCXJlZyA9IDwweDA1MDAwMCAweDEwMDA+Ow0K
CQkJCWludGVycnVwdHMgPSA8OSAxMD47DQoJCQl9Ow0KDQoJCQlrbWlAMDYw
MDAwIHsNCgkJCQljb21wYXRpYmxlID0gImFybSxwbDA1MCIsICJhcm0scHJp
bWVjZWxsIjsNCgkJCQlyZWcgPSA8MHgwNjAwMDAgMHgxMDAwPjsNCgkJCQlp
bnRlcnJ1cHRzID0gPDEyPjsNCgkJCX07DQoNCgkJCWttaUAwNzAwMDAgew0K
CQkJCWNvbXBhdGlibGUgPSAiYXJtLHBsMDUwIiwgImFybSxwcmltZWNlbGwi
Ow0KCQkJCXJlZyA9IDwweDA3MDAwMCAweDEwMDA+Ow0KCQkJCWludGVycnVw
dHMgPSA8MTM+Ow0KCQkJfTsNCg0KCQkJdjJtX3NlcmlhbDA6IHVhcnRAMDkw
MDAwIHsNCgkJCQljb21wYXRpYmxlID0gImFybSxwbDAxMSIsICJhcm0scHJp
bWVjZWxsIjsNCgkJCQlyZWcgPSA8MHgwOTAwMDAgMHgxMDAwPjsNCgkJCQlp
bnRlcnJ1cHRzID0gPDU+Ow0KCQkJfTsNCg0KCQkJdjJtX3NlcmlhbDE6IHVh
cnRAMGEwMDAwIHsNCgkJCQljb21wYXRpYmxlID0gImFybSxwbDAxMSIsICJh
cm0scHJpbWVjZWxsIjsNCgkJCQlyZWcgPSA8MHgwYTAwMDAgMHgxMDAwPjsN
CgkJCQlpbnRlcnJ1cHRzID0gPDY+Ow0KCQkJfTsNCg0KCQkJdjJtX3Nlcmlh
bDI6IHVhcnRAMGIwMDAwIHsNCgkJCQljb21wYXRpYmxlID0gImFybSxwbDAx
MSIsICJhcm0scHJpbWVjZWxsIjsNCgkJCQlyZWcgPSA8MHgwYjAwMDAgMHgx
MDAwPjsNCgkJCQlpbnRlcnJ1cHRzID0gPDc+Ow0KCQkJfTsNCg0KCQkJdjJt
X3NlcmlhbDM6IHVhcnRAMGMwMDAwIHsNCgkJCQljb21wYXRpYmxlID0gImFy
bSxwbDAxMSIsICJhcm0scHJpbWVjZWxsIjsNCgkJCQlyZWcgPSA8MHgwYzAw
MDAgMHgxMDAwPjsNCgkJCQlpbnRlcnJ1cHRzID0gPDg+Ow0KCQkJfTsNCg0K
CQkJd2R0QDBmMDAwMCB7DQoJCQkJY29tcGF0aWJsZSA9ICJhcm0sc3A4MDUi
LCAiYXJtLHByaW1lY2VsbCI7DQoJCQkJcmVnID0gPDB4MGYwMDAwIDB4MTAw
MD47DQoJCQkJaW50ZXJydXB0cyA9IDwwPjsNCgkJCX07DQoNCgkJCXYybV90
aW1lcjAxOiB0aW1lckAxMTAwMDAgew0KCQkJCWNvbXBhdGlibGUgPSAiYXJt
LHNwODA0IiwgImFybSxwcmltZWNlbGwiOw0KCQkJCXJlZyA9IDwweDExMDAw
MCAweDEwMDA+Ow0KCQkJCWludGVycnVwdHMgPSA8Mj47DQoJCQl9Ow0KDQoJ
CQl2Mm1fdGltZXIyMzogdGltZXJAMTIwMDAwIHsNCgkJCQljb21wYXRpYmxl
ID0gImFybSxzcDgwNCIsICJhcm0scHJpbWVjZWxsIjsNCgkJCQlyZWcgPSA8
MHgxMjAwMDAgMHgxMDAwPjsNCgkJCQlpbnRlcnJ1cHRzID0gPDM+Ow0KCQkJ
fTsNCg0KCQkJLyogRFZJIEkyQyBidXMgKi8NCgkJCXYybV9pMmNfZHZpOiBp
MmNAMTYwMDAwIHsNCgkJCQljb21wYXRpYmxlID0gImFybSx2ZXJzYXRpbGUt
aTJjIjsNCgkJCQlyZWcgPSA8MHgxNjAwMDAgMHgxMDAwPjsNCg0KCQkJCSNh
ZGRyZXNzLWNlbGxzID0gPDE+Ow0KCQkJCSNzaXplLWNlbGxzID0gPDA+Ow0K
DQoJCQkJZHZpLXRyYW5zbWl0dGVyQDM5IHsNCgkJCQkJY29tcGF0aWJsZSA9
ICJzaWwsc2lpOTAyMi10cGkiLCAic2lsLHNpaTkwMjIiOw0KCQkJCQlyZWcg
PSA8MHgzOT47DQoJCQkJfTsNCg0KCQkJCWR2aS10cmFuc21pdHRlckA2MCB7
DQoJCQkJCWNvbXBhdGlibGUgPSAic2lsLHNpaTkwMjItY3BpIiwgInNpbCxz
aWk5MDIyIjsNCgkJCQkJcmVnID0gPDB4NjA+Ow0KCQkJCX07DQoJCQl9Ow0K
DQoJCQlydGNAMTcwMDAwIHsNCgkJCQljb21wYXRpYmxlID0gImFybSxwbDAz
MSIsICJhcm0scHJpbWVjZWxsIjsNCgkJCQlyZWcgPSA8MHgxNzAwMDAgMHgx
MDAwPjsNCgkJCQlpbnRlcnJ1cHRzID0gPDQ+Ow0KCQkJfTsNCg0KCQkJY29t
cGFjdC1mbGFzaEAxYTAwMDAgew0KCQkJCWNvbXBhdGlibGUgPSAiYXJtLHZl
eHByZXNzLWNmIiwgImF0YS1nZW5lcmljIjsNCgkJCQlyZWcgPSA8MHgxYTAw
MDAgMHgxMDANCgkJCQkgICAgICAgMHgxYTAxMDAgMHhmMDA+Ow0KCQkJCXJl
Zy1zaGlmdCA9IDwyPjsNCgkJCX07DQoNCgkJCWNsY2RAMWYwMDAwIHsNCgkJ
CQljb21wYXRpYmxlID0gImFybSxwbDExMSIsICJhcm0scHJpbWVjZWxsIjsN
CgkJCQlyZWcgPSA8MHgxZjAwMDAgMHgxMDAwPjsNCgkJCQlpbnRlcnJ1cHRz
ID0gPDE0PjsNCgkJCX07DQoJCX07DQoNCgkJdjJtX2ZpeGVkXzN2MzogZml4
ZWRyZWd1bGF0b3JAMCB7DQoJCQljb21wYXRpYmxlID0gInJlZ3VsYXRvci1m
aXhlZCI7DQoJCQlyZWd1bGF0b3ItbmFtZSA9ICIzVjMiOw0KCQkJcmVndWxh
dG9yLW1pbi1taWNyb3ZvbHQgPSA8MzMwMDAwMD47DQoJCQlyZWd1bGF0b3It
bWF4LW1pY3Jvdm9sdCA9IDwzMzAwMDAwPjsNCgkJCXJlZ3VsYXRvci1hbHdh
eXMtb247DQoJCX07DQoJfTsNCn07DQo=

--_004_alpineDEB20212081616185504850kaballukxensourcecom_
Content-Type: text/plain; charset="US-ASCII"; name="vexpress-v2p-ca15-tc1.dts"
Content-Transfer-Encoding: BASE64
Content-ID: <alpine.DEB.2.02.1209141210431.29232@kaball.uk.xensource.com>
Content-Description: 
Content-Disposition: attachment; filename="vexpress-v2p-ca15-tc1.dts"

LyoNCiAqIEFSTSBMdGQuIFZlcnNhdGlsZSBFeHByZXNzDQogKg0KICogQ29y
ZVRpbGUgRXhwcmVzcyBBMTV4MiAodmVyc2lvbiB3aXRoIFRlc3QgQ2hpcCAx
KQ0KICogQ29ydGV4LUExNSBNUENvcmUgKFYyUC1DQTE1KQ0KICoNCiAqIEhC
SS0wMjM3QQ0KICovDQoNCi9kdHMtdjEvOw0KDQovIHsNCgltb2RlbCA9ICJW
MlAtQ0ExNSI7DQoJYXJtLGhiaSA9IDwweDIzNz47DQoJY29tcGF0aWJsZSA9
ICJhcm0sdmV4cHJlc3MsdjJwLWNhMTUsdGMxIiwgImFybSx2ZXhwcmVzcyx2
MnAtY2ExNSIsICJhcm0sdmV4cHJlc3MiOw0KCWludGVycnVwdC1wYXJlbnQg
PSA8JmdpYz47DQoJI2FkZHJlc3MtY2VsbHMgPSA8Mj47DQoJI3NpemUtY2Vs
bHMgPSA8Mj47DQoNCgljaG9zZW4gew0KICAgICAgICAgICAgICAgICBib290
YXJncyA9ICJkb20wX21lbT0xMjhNIjsNCiAgICAgICAgICAgICAgICAgeGVu
LGRvbTAtYm9vdGFyZ3MgPSAiZWFybHlwcmludGsgY29uc29sZT10dHlBTUEx
IHJvb3Q9L2Rldi9tbWNibGswIGRlYnVnIHJ3IjsNCgl9Ow0KDQoJYWxpYXNl
cyB7DQoJCXNlcmlhbDAgPSAmdjJtX3NlcmlhbDA7DQoJCXNlcmlhbDEgPSAm
djJtX3NlcmlhbDE7DQoJCXNlcmlhbDIgPSAmdjJtX3NlcmlhbDI7DQoJCXNl
cmlhbDMgPSAmdjJtX3NlcmlhbDM7DQoJCWkyYzAgPSAmdjJtX2kyY19kdmk7
DQoJCWkyYzEgPSAmdjJtX2kyY19wY2llOw0KCX07DQoNCgljcHVzIHsNCgkJ
I2FkZHJlc3MtY2VsbHMgPSA8MT47DQoJCSNzaXplLWNlbGxzID0gPDA+Ow0K
DQoJCWNwdUAwIHsNCgkJCWRldmljZV90eXBlID0gImNwdSI7DQoJCQljb21w
YXRpYmxlID0gImFybSxjb3J0ZXgtYTE1IjsNCgkJCXJlZyA9IDwwPjsNCgkJ
fTsNCgl9Ow0KDQoJbWVtb3J5QDgwMDAwMDAwIHsNCgkJZGV2aWNlX3R5cGUg
PSAibWVtb3J5IjsNCgkJcmVnID0gPDAgMHg4MDAwMDAwMCAwIDB4ODAwMDAw
MDA+Ow0KCX07DQoNCglnaWM6IGludGVycnVwdC1jb250cm9sbGVyQDJjMDAx
MDAwIHsNCgkJY29tcGF0aWJsZSA9ICJhcm0sY29ydGV4LWExNS1naWMiLCAi
YXJtLGNvcnRleC1hOS1naWMiOw0KCQkjaW50ZXJydXB0LWNlbGxzID0gPDM+
Ow0KCQkjYWRkcmVzcy1jZWxscyA9IDwwPjsNCgkJaW50ZXJydXB0LWNvbnRy
b2xsZXI7DQoJCXJlZyA9IDwwIDB4MmMwMDEwMDAgMCAweDEwMDA+LA0KCQkg
ICAgICA8MCAweDJjMDAyMDAwIDAgMHgxMDAwPiwNCgkJICAgICAgPDAgMHgy
YzAwNDAwMCAwIDB4MjAwMD4sDQoJCSAgICAgIDwwIDB4MmMwMDYwMDAgMCAw
eDIwMDA+Ow0KCQlpbnRlcnJ1cHRzID0gPDEgOSAweGYwND47DQoJfTsNCg0K
CXRpbWVyIHsNCgkJY29tcGF0aWJsZSA9ICJhcm0sYXJtdjctdGltZXIiOw0K
CQlpbnRlcnJ1cHRzID0gPDEgMTMgMHhmMDg+LA0KCQkJICAgICA8MSAxNCAw
eGYwOD4sDQoJCQkgICAgIDwxIDExIDB4ZjA4PiwNCgkJCSAgICAgPDEgMTAg
MHhmMDg+Ow0KCX07DQoNCglwbXUgew0KCQljb21wYXRpYmxlID0gImFybSxj
b3J0ZXgtYTE1LXBtdSIsICJhcm0sY29ydGV4LWE5LXBtdSI7DQoJCWludGVy
cnVwdHMgPSA8MCA2OCA0PiwNCgkJCSAgICAgPDAgNjkgND47DQoJfTsNCg0K
CWh5cGVydmlzb3Igew0KCQljb21wYXRpYmxlID0gInhlbix4ZW4tNC4yIiwg
Inhlbix4ZW4iOw0KCQlyZWcgPSA8MCAweGIwMDAwMDAwIDAgMHgyMDAwMD47
DQoJCWludGVycnVwdHMgPSA8MSAxNSAweGYwOD47DQoJfTsNCg0KCW1vdGhl
cmJvYXJkIHsNCgkJcmFuZ2VzID0gPDAgMCAwIDB4MDgwMDAwMDAgMHgwNDAw
MDAwMD4sDQoJCQkgPDEgMCAwIDB4MTQwMDAwMDAgMHgwNDAwMDAwMD4sDQoJ
CQkgPDIgMCAwIDB4MTgwMDAwMDAgMHgwNDAwMDAwMD4sDQoJCQkgPDMgMCAw
IDB4MWMwMDAwMDAgMHgwNDAwMDAwMD4sDQoJCQkgPDQgMCAwIDB4MGMwMDAw
MDAgMHgwNDAwMDAwMD4sDQoJCQkgPDUgMCAwIDB4MTAwMDAwMDAgMHgwNDAw
MDAwMD47DQoNCgkJaW50ZXJydXB0LW1hcC1tYXNrID0gPDAgMCA2Mz47DQoJ
CWludGVycnVwdC1tYXAgPSA8MCAwICAwICZnaWMgMCAgMCA0PiwNCgkJCQk8
MCAwICAxICZnaWMgMCAgMSA0PiwNCgkJCQk8MCAwICAyICZnaWMgMCAgMiA0
PiwNCgkJCQk8MCAwICAzICZnaWMgMCAgMyA0PiwNCgkJCQk8MCAwICA0ICZn
aWMgMCAgNCA0PiwNCgkJCQk8MCAwICA1ICZnaWMgMCAgNSA0PiwNCgkJCQk8
MCAwICA2ICZnaWMgMCAgNiA0PiwNCgkJCQk8MCAwICA3ICZnaWMgMCAgNyA0
PiwNCgkJCQk8MCAwICA4ICZnaWMgMCAgOCA0PiwNCgkJCQk8MCAwICA5ICZn
aWMgMCAgOSA0PiwNCgkJCQk8MCAwIDEwICZnaWMgMCAxMCA0PiwNCgkJCQk8
MCAwIDExICZnaWMgMCAxMSA0PiwNCgkJCQk8MCAwIDEyICZnaWMgMCAxMiA0
PiwNCgkJCQk8MCAwIDEzICZnaWMgMCAxMyA0PiwNCgkJCQk8MCAwIDE0ICZn
aWMgMCAxNCA0PiwNCgkJCQk8MCAwIDE1ICZnaWMgMCAxNSA0PiwNCgkJCQk8
MCAwIDE2ICZnaWMgMCAxNiA0PiwNCgkJCQk8MCAwIDE3ICZnaWMgMCAxNyA0
PiwNCgkJCQk8MCAwIDE4ICZnaWMgMCAxOCA0PiwNCgkJCQk8MCAwIDE5ICZn
aWMgMCAxOSA0PiwNCgkJCQk8MCAwIDIwICZnaWMgMCAyMCA0PiwNCgkJCQk8
MCAwIDIxICZnaWMgMCAyMSA0PiwNCgkJCQk8MCAwIDIyICZnaWMgMCAyMiA0
PiwNCgkJCQk8MCAwIDIzICZnaWMgMCAyMyA0PiwNCgkJCQk8MCAwIDI0ICZn
aWMgMCAyNCA0PiwNCgkJCQk8MCAwIDI1ICZnaWMgMCAyNSA0PiwNCgkJCQk8
MCAwIDI2ICZnaWMgMCAyNiA0PiwNCgkJCQk8MCAwIDI3ICZnaWMgMCAyNyA0
PiwNCgkJCQk8MCAwIDI4ICZnaWMgMCAyOCA0PiwNCgkJCQk8MCAwIDI5ICZn
aWMgMCAyOSA0PiwNCgkJCQk8MCAwIDMwICZnaWMgMCAzMCA0PiwNCgkJCQk8
MCAwIDMxICZnaWMgMCAzMSA0PiwNCgkJCQk8MCAwIDMyICZnaWMgMCAzMiA0
PiwNCgkJCQk8MCAwIDMzICZnaWMgMCAzMyA0PiwNCgkJCQk8MCAwIDM0ICZn
aWMgMCAzNCA0PiwNCgkJCQk8MCAwIDM1ICZnaWMgMCAzNSA0PiwNCgkJCQk8
MCAwIDM2ICZnaWMgMCAzNiA0PiwNCgkJCQk8MCAwIDM3ICZnaWMgMCAzNyA0
PiwNCgkJCQk8MCAwIDM4ICZnaWMgMCAzOCA0PiwNCgkJCQk8MCAwIDM5ICZn
aWMgMCAzOSA0PiwNCgkJCQk8MCAwIDQwICZnaWMgMCA0MCA0PiwNCgkJCQk8
MCAwIDQxICZnaWMgMCA0MSA0PiwNCgkJCQk8MCAwIDQyICZnaWMgMCA0MiA0
PjsNCgl9Ow0KfTsNCg0KL2luY2x1ZGUvICJ2ZXhwcmVzcy12Mm0tcnMxLmR0
c2kiDQo=

--_004_alpineDEB20212081616185504850kaballukxensourcecom_
Content-Type: text/plain; charset="US-ASCII"; name="vexpress-virt.dts"
Content-Transfer-Encoding: BASE64
Content-ID: <alpine.DEB.2.02.1209141210432.29232@kaball.uk.xensource.com>
Content-Description: 
Content-Disposition: attachment; filename="vexpress-virt.dts"

LyoNCiAqIEFSTSBMdGQuIFZlcnNhdGlsZSBFeHByZXNzDQogKg0KICogQVJN
IEVudmVsb3BlIE1vZGVsIHY3QSAoc2luZ2xlIENQVSkuDQogKi8NCg0KL2R0
cy12MS87DQoNCi9pbmNsdWRlLyAic2tlbGV0b24uZHRzaSINCg0KLyB7DQoJ
bW9kZWwgPSAiVjJQLUFFTXY3QSI7DQoJY29tcGF0aWJsZSA9ICJhcm0sdmV4
cHJlc3MsdjJwLWFlbSx2N2EiLCAiYXJtLHZleHByZXNzLHYycC1hZW0iLCAi
YXJtLHZleHByZXNzIjsNCglpbnRlcnJ1cHQtcGFyZW50ID0gPCZnaWM+Ow0K
DQogICAgICAgIGNob3NlbiB7DQogICAgICAgICAgICAgICAgYm9vdGFyZ3Mg
PSAiZWFybHlwcmludGsgZGVidWcgbG9nbGV2ZWw9OSBjb25zb2xlPWh2YzAg
cm9vdD0vZGV2L3h2ZGEgaW5pdD0vc2Jpbi9pbml0IjsNCiAgICAgICAgfTsN
Cg0KCWNwdXMgew0KCQkjYWRkcmVzcy1jZWxscyA9IDwxPjsNCgkJI3NpemUt
Y2VsbHMgPSA8MD47DQoNCgkJY3B1QDAgew0KCQkJZGV2aWNlX3R5cGUgPSAi
Y3B1IjsNCgkJCWNvbXBhdGlibGUgPSAiYXJtLGNvcnRleC1hMTUiOw0KCQkJ
cmVnID0gPDA+Ow0KCQl9Ow0KCX07DQoNCgltZW1vcnkgew0KCQlkZXZpY2Vf
dHlwZSA9ICJtZW1vcnkiOw0KCQlyZWcgPSA8MHg4MDAwMDAwMCAweDA4MDAw
MDAwPjsNCgl9Ow0KDQoJZ2ljOiBpbnRlcnJ1cHQtY29udHJvbGxlckAyYzAw
MTAwMCB7DQoJCWNvbXBhdGlibGUgPSAiYXJtLGNvcnRleC1hOS1naWMiOw0K
CQkjaW50ZXJydXB0LWNlbGxzID0gPDM+Ow0KCQkjYWRkcmVzcy1jZWxscyA9
IDwwPjsNCgkJaW50ZXJydXB0LWNvbnRyb2xsZXI7DQoJCXJlZyA9IDwweDJj
MDAxMDAwIDB4MTAwMD4sDQoJCSAgICAgIDwweDJjMDAyMDAwIDB4MTAwPjsN
Cgl9Ow0KDQoJdGltZXIgew0KCQljb21wYXRpYmxlID0gImFybSxhcm12Ny10
aW1lciI7DQoJCWludGVycnVwdHMgPSA8MSAxMyAweGYwOD4sDQoJCQkgICAg
IDwxIDE0IDB4ZjA4PiwNCgkJCSAgICAgPDEgMTEgMHhmMDg+LA0KCQkJICAg
ICA8MSAxMCAweGYwOD47DQoJfTsNCg0KCWh5cGVydmlzb3Igew0KCQljb21w
YXRpYmxlID0gInhlbix4ZW4tNC4yIiwgInhlbix4ZW4iOw0KCQlyZWcgPSA8
MHhiMDAwMDAwMCAweDIwMDAwPjsNCgkJaW50ZXJydXB0cyA9IDwxIDE1IDB4
ZjA4PjsNCgl9Ow0KDQoJbW90aGVyYm9hcmQgew0KCQlhcm0sdjJtLW1lbW9y
eS1tYXAgPSAicnMxIjsNCgkJcmFuZ2VzID0gPDAgMCAweDA4MDAwMDAwIDB4
MDQwMDAwMDA+LA0KCQkJIDwxIDAgMHgxNDAwMDAwMCAweDA0MDAwMDAwPiwN
CgkJCSA8MiAwIDB4MTgwMDAwMDAgMHgwNDAwMDAwMD4sDQoJCQkgPDMgMCAw
eDFjMDAwMDAwIDB4MDQwMDAwMDA+LA0KCQkJIDw0IDAgMHgwYzAwMDAwMCAw
eDA0MDAwMDAwPiwNCgkJCSA8NSAwIDB4MTAwMDAwMDAgMHgwNDAwMDAwMD47
DQoNCgkJaW50ZXJydXB0LW1hcC1tYXNrID0gPDAgMCA2Mz47DQoJCWludGVy
cnVwdC1tYXAgPSA8MCAwICAwICZnaWMgMCAgMCA0PiwNCgkJCQk8MCAwICAx
ICZnaWMgMCAgMSA0PiwNCgkJCQk8MCAwICAyICZnaWMgMCAgMiA0PiwNCgkJ
CQk8MCAwICAzICZnaWMgMCAgMyA0PiwNCgkJCQk8MCAwICA0ICZnaWMgMCAg
NCA0PiwNCgkJCQk8MCAwICA1ICZnaWMgMCAgNSA0PiwNCgkJCQk8MCAwICA2
ICZnaWMgMCAgNiA0PiwNCgkJCQk8MCAwICA3ICZnaWMgMCAgNyA0PiwNCgkJ
CQk8MCAwICA4ICZnaWMgMCAgOCA0PiwNCgkJCQk8MCAwICA5ICZnaWMgMCAg
OSA0PiwNCgkJCQk8MCAwIDEwICZnaWMgMCAxMCA0PiwNCgkJCQk8MCAwIDEx
ICZnaWMgMCAxMSA0PiwNCgkJCQk8MCAwIDEyICZnaWMgMCAxMiA0PiwNCgkJ
CQk8MCAwIDEzICZnaWMgMCAxMyA0PiwNCgkJCQk8MCAwIDE0ICZnaWMgMCAx
NCA0PiwNCgkJCQk8MCAwIDE1ICZnaWMgMCAxNSA0PiwNCgkJCQk8MCAwIDE2
ICZnaWMgMCAxNiA0PiwNCgkJCQk8MCAwIDE3ICZnaWMgMCAxNyA0PiwNCgkJ
CQk8MCAwIDE4ICZnaWMgMCAxOCA0PiwNCgkJCQk8MCAwIDE5ICZnaWMgMCAx
OSA0PiwNCgkJCQk8MCAwIDIwICZnaWMgMCAyMCA0PiwNCgkJCQk8MCAwIDIx
ICZnaWMgMCAyMSA0PiwNCgkJCQk8MCAwIDIyICZnaWMgMCAyMiA0PiwNCgkJ
CQk8MCAwIDIzICZnaWMgMCAyMyA0PiwNCgkJCQk8MCAwIDI0ICZnaWMgMCAy
NCA0PiwNCgkJCQk8MCAwIDI1ICZnaWMgMCAyNSA0PiwNCgkJCQk8MCAwIDI2
ICZnaWMgMCAyNiA0PiwNCgkJCQk8MCAwIDI3ICZnaWMgMCAyNyA0PiwNCgkJ
CQk8MCAwIDI4ICZnaWMgMCAyOCA0PiwNCgkJCQk8MCAwIDI5ICZnaWMgMCAy
OSA0PiwNCgkJCQk8MCAwIDMwICZnaWMgMCAzMCA0PiwNCgkJCQk8MCAwIDMx
ICZnaWMgMCAzMSA0PiwNCgkJCQk8MCAwIDMyICZnaWMgMCAzMiA0PiwNCgkJ
CQk8MCAwIDMzICZnaWMgMCAzMyA0PiwNCgkJCQk8MCAwIDM0ICZnaWMgMCAz
NCA0PiwNCgkJCQk8MCAwIDM1ICZnaWMgMCAzNSA0PiwNCgkJCQk8MCAwIDM2
ICZnaWMgMCAzNiA0PiwNCgkJCQk8MCAwIDM3ICZnaWMgMCAzNyA0PiwNCgkJ
CQk8MCAwIDM4ICZnaWMgMCAzOCA0PiwNCgkJCQk8MCAwIDM5ICZnaWMgMCAz
OSA0PiwNCgkJCQk8MCAwIDQwICZnaWMgMCA0MCA0PiwNCgkJCQk8MCAwIDQx
ICZnaWMgMCA0MSA0PiwNCgkJCQk8MCAwIDQyICZnaWMgMCA0MiA0PjsNCgl9
Ow0KfTsNCg0KLyogL2luY2x1ZGUvICJ2ZXhwcmVzcy12Mm0tcnMxLXJ0c20u
ZHRzaSIgKi8NCg==

--_004_alpineDEB20212081616185504850kaballukxensourcecom_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--_004_alpineDEB20212081616185504850kaballukxensourcecom_--


From xen-devel-bounces@lists.xen.org Fri Sep 14 11:14:30 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 11:14:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TCTqr-0005WH-BU; Fri, 14 Sep 2012 11:14:25 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1TCTqq-0005V8-EW
	for xen-devel@lists.xensource.com; Fri, 14 Sep 2012 11:14:24 +0000
Received: from [85.158.137.99:6272] by server-8.bemta-3.messagelabs.com id
	75/1B-24700-F8113505; Fri, 14 Sep 2012 11:14:23 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-7.tower-217.messagelabs.com!1347621260!12870564!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNzQ1Njg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2538 invoked from network); 14 Sep 2012 11:14:22 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-7.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Sep 2012 11:14:22 -0000
X-IronPort-AV: E=Sophos;i="4.80,422,1344211200"; d="scan'208";a="208101221"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Sep 2012 11:14:06 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Fri, 14 Sep 2012 07:14:05 -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 1TCTqN-0005wt-D9;
	Fri, 14 Sep 2012 12:13:55 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: <arnd@arndb.de>
Date: Fri, 14 Sep 2012 12:13:11 +0100
Message-ID: <1347621207-11294-9-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <alpine.DEB.2.02.1209141145150.29232@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1209141145150.29232@kaball.uk.xensource.com>
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com, linaro-dev@lists.linaro.org,
	Ian.Campbell@citrix.com, konrad.wilk@oracle.com, catalin.marinas@arm.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	tim@xen.org, linux-kernel@vger.kernel.org,
	linux@arm.linux.org.uk, linux-arm-kernel@lists.infradead.org
Subject: [Xen-devel] [PATCH v4 09/24] xen/arm: Introduce xen_ulong_t for
	unsigned long
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

All the original Xen headers have xen_ulong_t as unsigned long type, however
when they have been imported in Linux, xen_ulong_t has been replaced with
unsigned long. That might work for x86 and ia64 but it does not for arm.
Bring back xen_ulong_t and let each architecture define xen_ulong_t as they
see fit.

Also explicitly size pointers (__DEFINE_GUEST_HANDLE) to 64 bit.


Changes in v3:

- remove the incorrect changes to multicall_entry;
- remove the change to apic_physbase.


Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 arch/arm/include/asm/xen/interface.h  |    8 ++++++--
 arch/ia64/include/asm/xen/interface.h |    1 +
 arch/x86/include/asm/xen/interface.h  |    1 +
 include/xen/interface/memory.h        |   12 ++++++------
 include/xen/interface/physdev.h       |    2 +-
 include/xen/interface/version.h       |    2 +-
 6 files changed, 16 insertions(+), 10 deletions(-)

diff --git a/arch/arm/include/asm/xen/interface.h b/arch/arm/include/asm/xen/interface.h
index 74c72b5..ae05e56 100644
--- a/arch/arm/include/asm/xen/interface.h
+++ b/arch/arm/include/asm/xen/interface.h
@@ -9,8 +9,11 @@
 
 #include <linux/types.h>
 
+#define uint64_aligned_t uint64_t __attribute__((aligned(8)))
+
 #define __DEFINE_GUEST_HANDLE(name, type) \
-	typedef type * __guest_handle_ ## name
+	typedef struct { union { type *p; uint64_aligned_t q; }; }  \
+        __guest_handle_ ## name
 
 #define DEFINE_GUEST_HANDLE_STRUCT(name) \
 	__DEFINE_GUEST_HANDLE(name, struct name)
@@ -21,13 +24,14 @@
 	do {						\
 		if (sizeof(hnd) == 8)			\
 			*(uint64_t *)&(hnd) = 0;	\
-		(hnd) = val;				\
+		(hnd).p = val;				\
 	} while (0)
 
 #ifndef __ASSEMBLY__
 /* Explicitly size integers that represent pfns in the interface with
  * Xen so that we can have one ABI that works for 32 and 64 bit guests. */
 typedef uint64_t xen_pfn_t;
+typedef uint64_t xen_ulong_t;
 /* Guest handles for primitive C types. */
 __DEFINE_GUEST_HANDLE(uchar, unsigned char);
 __DEFINE_GUEST_HANDLE(uint,  unsigned int);
diff --git a/arch/ia64/include/asm/xen/interface.h b/arch/ia64/include/asm/xen/interface.h
index 686464e..7c83445 100644
--- a/arch/ia64/include/asm/xen/interface.h
+++ b/arch/ia64/include/asm/xen/interface.h
@@ -71,6 +71,7 @@
  * with Xen so that we could have one ABI that works for 32 and 64 bit
  * guests. */
 typedef unsigned long xen_pfn_t;
+typedef unsigned long xen_ulong_t;
 /* Guest handles for primitive C types. */
 __DEFINE_GUEST_HANDLE(uchar, unsigned char);
 __DEFINE_GUEST_HANDLE(uint, unsigned int);
diff --git a/arch/x86/include/asm/xen/interface.h b/arch/x86/include/asm/xen/interface.h
index 2289075..25cc8df 100644
--- a/arch/x86/include/asm/xen/interface.h
+++ b/arch/x86/include/asm/xen/interface.h
@@ -51,6 +51,7 @@
  * with Xen so that on ARM we can have one ABI that works for 32 and 64
  * bit guests. */
 typedef unsigned long xen_pfn_t;
+typedef unsigned long xen_ulong_t;
 /* Guest handles for primitive C types. */
 __DEFINE_GUEST_HANDLE(uchar, unsigned char);
 __DEFINE_GUEST_HANDLE(uint,  unsigned int);
diff --git a/include/xen/interface/memory.h b/include/xen/interface/memory.h
index abbbff0..b5c3098 100644
--- a/include/xen/interface/memory.h
+++ b/include/xen/interface/memory.h
@@ -34,7 +34,7 @@ struct xen_memory_reservation {
     GUEST_HANDLE(xen_pfn_t) extent_start;
 
     /* Number of extents, and size/alignment of each (2^extent_order pages). */
-    unsigned long  nr_extents;
+    xen_ulong_t  nr_extents;
     unsigned int   extent_order;
 
     /*
@@ -92,7 +92,7 @@ struct xen_memory_exchange {
      *     command will be non-zero.
      *  5. THIS FIELD MUST BE INITIALISED TO ZERO BY THE CALLER!
      */
-    unsigned long nr_exchanged;
+    xen_ulong_t nr_exchanged;
 };
 
 DEFINE_GUEST_HANDLE_STRUCT(xen_memory_exchange);
@@ -148,8 +148,8 @@ DEFINE_GUEST_HANDLE_STRUCT(xen_machphys_mfn_list);
  */
 #define XENMEM_machphys_mapping     12
 struct xen_machphys_mapping {
-    unsigned long v_start, v_end; /* Start and end virtual addresses.   */
-    unsigned long max_mfn;        /* Maximum MFN that can be looked up. */
+    xen_ulong_t v_start, v_end; /* Start and end virtual addresses.   */
+    xen_ulong_t max_mfn;        /* Maximum MFN that can be looked up. */
 };
 DEFINE_GUEST_HANDLE_STRUCT(xen_machphys_mapping_t);
 
@@ -169,7 +169,7 @@ struct xen_add_to_physmap {
     unsigned int space;
 
     /* Index into source mapping space. */
-    unsigned long idx;
+    xen_ulong_t idx;
 
     /* GPFN where the source mapping page should appear. */
     xen_pfn_t gpfn;
@@ -186,7 +186,7 @@ struct xen_translate_gpfn_list {
     domid_t domid;
 
     /* Length of list. */
-    unsigned long nr_gpfns;
+    xen_ulong_t nr_gpfns;
 
     /* List of GPFNs to translate. */
     GUEST_HANDLE(ulong) gpfn_list;
diff --git a/include/xen/interface/physdev.h b/include/xen/interface/physdev.h
index 9ce788d..f616514 100644
--- a/include/xen/interface/physdev.h
+++ b/include/xen/interface/physdev.h
@@ -56,7 +56,7 @@ struct physdev_eoi {
 #define PHYSDEVOP_pirq_eoi_gmfn_v2       28
 struct physdev_pirq_eoi_gmfn {
     /* IN */
-    unsigned long gmfn;
+    xen_ulong_t gmfn;
 };
 
 /*
diff --git a/include/xen/interface/version.h b/include/xen/interface/version.h
index e8b6519..30280c9 100644
--- a/include/xen/interface/version.h
+++ b/include/xen/interface/version.h
@@ -45,7 +45,7 @@ struct xen_changeset_info {
 
 #define XENVER_platform_parameters 5
 struct xen_platform_parameters {
-    unsigned long virt_start;
+    xen_ulong_t virt_start;
 };
 
 #define XENVER_get_features 6
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 14 11:14:30 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 11:14:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TCTqr-0005WH-BU; Fri, 14 Sep 2012 11:14:25 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1TCTqq-0005V8-EW
	for xen-devel@lists.xensource.com; Fri, 14 Sep 2012 11:14:24 +0000
Received: from [85.158.137.99:6272] by server-8.bemta-3.messagelabs.com id
	75/1B-24700-F8113505; Fri, 14 Sep 2012 11:14:23 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-7.tower-217.messagelabs.com!1347621260!12870564!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNzQ1Njg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2538 invoked from network); 14 Sep 2012 11:14:22 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-7.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Sep 2012 11:14:22 -0000
X-IronPort-AV: E=Sophos;i="4.80,422,1344211200"; d="scan'208";a="208101221"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Sep 2012 11:14:06 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Fri, 14 Sep 2012 07:14:05 -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 1TCTqN-0005wt-D9;
	Fri, 14 Sep 2012 12:13:55 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: <arnd@arndb.de>
Date: Fri, 14 Sep 2012 12:13:11 +0100
Message-ID: <1347621207-11294-9-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <alpine.DEB.2.02.1209141145150.29232@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1209141145150.29232@kaball.uk.xensource.com>
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com, linaro-dev@lists.linaro.org,
	Ian.Campbell@citrix.com, konrad.wilk@oracle.com, catalin.marinas@arm.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	tim@xen.org, linux-kernel@vger.kernel.org,
	linux@arm.linux.org.uk, linux-arm-kernel@lists.infradead.org
Subject: [Xen-devel] [PATCH v4 09/24] xen/arm: Introduce xen_ulong_t for
	unsigned long
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

All the original Xen headers have xen_ulong_t as unsigned long type, however
when they have been imported in Linux, xen_ulong_t has been replaced with
unsigned long. That might work for x86 and ia64 but it does not for arm.
Bring back xen_ulong_t and let each architecture define xen_ulong_t as they
see fit.

Also explicitly size pointers (__DEFINE_GUEST_HANDLE) to 64 bit.


Changes in v3:

- remove the incorrect changes to multicall_entry;
- remove the change to apic_physbase.


Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 arch/arm/include/asm/xen/interface.h  |    8 ++++++--
 arch/ia64/include/asm/xen/interface.h |    1 +
 arch/x86/include/asm/xen/interface.h  |    1 +
 include/xen/interface/memory.h        |   12 ++++++------
 include/xen/interface/physdev.h       |    2 +-
 include/xen/interface/version.h       |    2 +-
 6 files changed, 16 insertions(+), 10 deletions(-)

diff --git a/arch/arm/include/asm/xen/interface.h b/arch/arm/include/asm/xen/interface.h
index 74c72b5..ae05e56 100644
--- a/arch/arm/include/asm/xen/interface.h
+++ b/arch/arm/include/asm/xen/interface.h
@@ -9,8 +9,11 @@
 
 #include <linux/types.h>
 
+#define uint64_aligned_t uint64_t __attribute__((aligned(8)))
+
 #define __DEFINE_GUEST_HANDLE(name, type) \
-	typedef type * __guest_handle_ ## name
+	typedef struct { union { type *p; uint64_aligned_t q; }; }  \
+        __guest_handle_ ## name
 
 #define DEFINE_GUEST_HANDLE_STRUCT(name) \
 	__DEFINE_GUEST_HANDLE(name, struct name)
@@ -21,13 +24,14 @@
 	do {						\
 		if (sizeof(hnd) == 8)			\
 			*(uint64_t *)&(hnd) = 0;	\
-		(hnd) = val;				\
+		(hnd).p = val;				\
 	} while (0)
 
 #ifndef __ASSEMBLY__
 /* Explicitly size integers that represent pfns in the interface with
  * Xen so that we can have one ABI that works for 32 and 64 bit guests. */
 typedef uint64_t xen_pfn_t;
+typedef uint64_t xen_ulong_t;
 /* Guest handles for primitive C types. */
 __DEFINE_GUEST_HANDLE(uchar, unsigned char);
 __DEFINE_GUEST_HANDLE(uint,  unsigned int);
diff --git a/arch/ia64/include/asm/xen/interface.h b/arch/ia64/include/asm/xen/interface.h
index 686464e..7c83445 100644
--- a/arch/ia64/include/asm/xen/interface.h
+++ b/arch/ia64/include/asm/xen/interface.h
@@ -71,6 +71,7 @@
  * with Xen so that we could have one ABI that works for 32 and 64 bit
  * guests. */
 typedef unsigned long xen_pfn_t;
+typedef unsigned long xen_ulong_t;
 /* Guest handles for primitive C types. */
 __DEFINE_GUEST_HANDLE(uchar, unsigned char);
 __DEFINE_GUEST_HANDLE(uint, unsigned int);
diff --git a/arch/x86/include/asm/xen/interface.h b/arch/x86/include/asm/xen/interface.h
index 2289075..25cc8df 100644
--- a/arch/x86/include/asm/xen/interface.h
+++ b/arch/x86/include/asm/xen/interface.h
@@ -51,6 +51,7 @@
  * with Xen so that on ARM we can have one ABI that works for 32 and 64
  * bit guests. */
 typedef unsigned long xen_pfn_t;
+typedef unsigned long xen_ulong_t;
 /* Guest handles for primitive C types. */
 __DEFINE_GUEST_HANDLE(uchar, unsigned char);
 __DEFINE_GUEST_HANDLE(uint,  unsigned int);
diff --git a/include/xen/interface/memory.h b/include/xen/interface/memory.h
index abbbff0..b5c3098 100644
--- a/include/xen/interface/memory.h
+++ b/include/xen/interface/memory.h
@@ -34,7 +34,7 @@ struct xen_memory_reservation {
     GUEST_HANDLE(xen_pfn_t) extent_start;
 
     /* Number of extents, and size/alignment of each (2^extent_order pages). */
-    unsigned long  nr_extents;
+    xen_ulong_t  nr_extents;
     unsigned int   extent_order;
 
     /*
@@ -92,7 +92,7 @@ struct xen_memory_exchange {
      *     command will be non-zero.
      *  5. THIS FIELD MUST BE INITIALISED TO ZERO BY THE CALLER!
      */
-    unsigned long nr_exchanged;
+    xen_ulong_t nr_exchanged;
 };
 
 DEFINE_GUEST_HANDLE_STRUCT(xen_memory_exchange);
@@ -148,8 +148,8 @@ DEFINE_GUEST_HANDLE_STRUCT(xen_machphys_mfn_list);
  */
 #define XENMEM_machphys_mapping     12
 struct xen_machphys_mapping {
-    unsigned long v_start, v_end; /* Start and end virtual addresses.   */
-    unsigned long max_mfn;        /* Maximum MFN that can be looked up. */
+    xen_ulong_t v_start, v_end; /* Start and end virtual addresses.   */
+    xen_ulong_t max_mfn;        /* Maximum MFN that can be looked up. */
 };
 DEFINE_GUEST_HANDLE_STRUCT(xen_machphys_mapping_t);
 
@@ -169,7 +169,7 @@ struct xen_add_to_physmap {
     unsigned int space;
 
     /* Index into source mapping space. */
-    unsigned long idx;
+    xen_ulong_t idx;
 
     /* GPFN where the source mapping page should appear. */
     xen_pfn_t gpfn;
@@ -186,7 +186,7 @@ struct xen_translate_gpfn_list {
     domid_t domid;
 
     /* Length of list. */
-    unsigned long nr_gpfns;
+    xen_ulong_t nr_gpfns;
 
     /* List of GPFNs to translate. */
     GUEST_HANDLE(ulong) gpfn_list;
diff --git a/include/xen/interface/physdev.h b/include/xen/interface/physdev.h
index 9ce788d..f616514 100644
--- a/include/xen/interface/physdev.h
+++ b/include/xen/interface/physdev.h
@@ -56,7 +56,7 @@ struct physdev_eoi {
 #define PHYSDEVOP_pirq_eoi_gmfn_v2       28
 struct physdev_pirq_eoi_gmfn {
     /* IN */
-    unsigned long gmfn;
+    xen_ulong_t gmfn;
 };
 
 /*
diff --git a/include/xen/interface/version.h b/include/xen/interface/version.h
index e8b6519..30280c9 100644
--- a/include/xen/interface/version.h
+++ b/include/xen/interface/version.h
@@ -45,7 +45,7 @@ struct xen_changeset_info {
 
 #define XENVER_platform_parameters 5
 struct xen_platform_parameters {
-    unsigned long virt_start;
+    xen_ulong_t virt_start;
 };
 
 #define XENVER_get_features 6
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 14 11:14:37 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 11:14:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TCTqq-0005Vt-UK; Fri, 14 Sep 2012 11:14:24 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1TCTqp-0005UX-Fb
	for xen-devel@lists.xensource.com; Fri, 14 Sep 2012 11:14:23 +0000
Received: from [85.158.137.99:8582] by server-7.bemta-3.messagelabs.com id
	89/93-32000-E8113505; Fri, 14 Sep 2012 11:14:22 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-7.tower-217.messagelabs.com!1347621260!12870564!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNzQ1Njg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2506 invoked from network); 14 Sep 2012 11:14:22 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-7.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Sep 2012 11:14:22 -0000
X-IronPort-AV: E=Sophos;i="4.80,422,1344211200"; d="scan'208";a="208101220"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Sep 2012 11:14:06 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Fri, 14 Sep 2012 07:14:05 -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 1TCTqN-0005wt-Ah;
	Fri, 14 Sep 2012 12:13:55 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: <arnd@arndb.de>
Date: Fri, 14 Sep 2012 12:13:09 +0100
Message-ID: <1347621207-11294-7-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <alpine.DEB.2.02.1209141145150.29232@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1209141145150.29232@kaball.uk.xensource.com>
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com, linaro-dev@lists.linaro.org,
	Ian.Campbell@citrix.com, konrad.wilk@oracle.com, catalin.marinas@arm.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	tim@xen.org, linux-kernel@vger.kernel.org,
	linux@arm.linux.org.uk, linux-arm-kernel@lists.infradead.org
Subject: [Xen-devel] [PATCH v4 07/24] xen/arm: Xen detection and shared_info
	page mapping
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Check for a node in the device tree compatible with "xen,xen", if it is
present set xen_domain_type to XEN_HVM_DOMAIN and continue
initialization.

Map the real shared info page using XENMEM_add_to_physmap with
XENMAPSPACE_shared_info.

Changes in v4:

- simpler parsing of Xen version in the compatible DT node.

Changes in v3:

- use the "xen,xen" notation rather than "arm,xen";
- add an additional check on the presence of the Xen version.

Changes in v2:

- replace pr_info with pr_debug.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 arch/arm/xen/enlighten.c |   61 ++++++++++++++++++++++++++++++++++++++++++++++
 1 files changed, 61 insertions(+), 0 deletions(-)

diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
index c535540..6a0217d 100644
--- a/arch/arm/xen/enlighten.c
+++ b/arch/arm/xen/enlighten.c
@@ -5,6 +5,9 @@
 #include <asm/xen/hypervisor.h>
 #include <asm/xen/hypercall.h>
 #include <linux/module.h>
+#include <linux/of.h>
+#include <linux/of_irq.h>
+#include <linux/of_address.h>
 
 struct start_info _xen_start_info;
 struct start_info *xen_start_info = &_xen_start_info;
@@ -33,3 +36,61 @@ int xen_remap_domain_mfn_range(struct vm_area_struct *vma,
 	return -ENOSYS;
 }
 EXPORT_SYMBOL_GPL(xen_remap_domain_mfn_range);
+
+/*
+ * see Documentation/devicetree/bindings/arm/xen.txt for the
+ * documentation of the Xen Device Tree format.
+ */
+static int __init xen_guest_init(void)
+{
+	struct xen_add_to_physmap xatp;
+	static struct shared_info *shared_info_page = 0;
+	struct device_node *node;
+	int len;
+	const char *s = NULL;
+	const char *version = NULL;
+	const char *xen_prefix = "xen,xen-";
+
+	node = of_find_compatible_node(NULL, NULL, "xen,xen");
+	if (!node) {
+		pr_debug("No Xen support\n");
+		return 0;
+	}
+	s = of_get_property(node, "compatible", &len);
+	if (strlen(xen_prefix) + 3  < len &&
+			!strncmp(xen_prefix, s, strlen(xen_prefix)))
+		version = s + strlen(xen_prefix);
+	if (version == NULL) {
+		pr_debug("Xen version not found\n");
+		return 0;
+	}
+	xen_domain_type = XEN_HVM_DOMAIN;
+
+	if (!shared_info_page)
+		shared_info_page = (struct shared_info *)
+			get_zeroed_page(GFP_KERNEL);
+	if (!shared_info_page) {
+		pr_err("not enough memory\n");
+		return -ENOMEM;
+	}
+	xatp.domid = DOMID_SELF;
+	xatp.idx = 0;
+	xatp.space = XENMAPSPACE_shared_info;
+	xatp.gpfn = __pa(shared_info_page) >> PAGE_SHIFT;
+	if (HYPERVISOR_memory_op(XENMEM_add_to_physmap, &xatp))
+		BUG();
+
+	HYPERVISOR_shared_info = (struct shared_info *)shared_info_page;
+
+	/* xen_vcpu is a pointer to the vcpu_info struct in the shared_info
+	 * page, we use it in the event channel upcall and in some pvclock
+	 * related functions. We don't need the vcpu_info placement
+	 * optimizations because we don't use any pv_mmu or pv_irq op on
+	 * HVM.
+	 * The shared info contains exactly 1 CPU (the boot CPU). The guest
+	 * is required to use VCPUOP_register_vcpu_info to place vcpu info
+	 * for secondary CPUs as they are brought up. */
+	per_cpu(xen_vcpu, 0) = &HYPERVISOR_shared_info->vcpu_info[0];
+	return 0;
+}
+core_initcall(xen_guest_init);
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 14 11:14:37 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 11:14:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TCTqq-0005Vt-UK; Fri, 14 Sep 2012 11:14:24 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1TCTqp-0005UX-Fb
	for xen-devel@lists.xensource.com; Fri, 14 Sep 2012 11:14:23 +0000
Received: from [85.158.137.99:8582] by server-7.bemta-3.messagelabs.com id
	89/93-32000-E8113505; Fri, 14 Sep 2012 11:14:22 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-7.tower-217.messagelabs.com!1347621260!12870564!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNzQ1Njg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2506 invoked from network); 14 Sep 2012 11:14:22 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-7.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Sep 2012 11:14:22 -0000
X-IronPort-AV: E=Sophos;i="4.80,422,1344211200"; d="scan'208";a="208101220"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Sep 2012 11:14:06 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Fri, 14 Sep 2012 07:14:05 -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 1TCTqN-0005wt-Ah;
	Fri, 14 Sep 2012 12:13:55 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: <arnd@arndb.de>
Date: Fri, 14 Sep 2012 12:13:09 +0100
Message-ID: <1347621207-11294-7-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <alpine.DEB.2.02.1209141145150.29232@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1209141145150.29232@kaball.uk.xensource.com>
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com, linaro-dev@lists.linaro.org,
	Ian.Campbell@citrix.com, konrad.wilk@oracle.com, catalin.marinas@arm.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	tim@xen.org, linux-kernel@vger.kernel.org,
	linux@arm.linux.org.uk, linux-arm-kernel@lists.infradead.org
Subject: [Xen-devel] [PATCH v4 07/24] xen/arm: Xen detection and shared_info
	page mapping
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Check for a node in the device tree compatible with "xen,xen", if it is
present set xen_domain_type to XEN_HVM_DOMAIN and continue
initialization.

Map the real shared info page using XENMEM_add_to_physmap with
XENMAPSPACE_shared_info.

Changes in v4:

- simpler parsing of Xen version in the compatible DT node.

Changes in v3:

- use the "xen,xen" notation rather than "arm,xen";
- add an additional check on the presence of the Xen version.

Changes in v2:

- replace pr_info with pr_debug.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 arch/arm/xen/enlighten.c |   61 ++++++++++++++++++++++++++++++++++++++++++++++
 1 files changed, 61 insertions(+), 0 deletions(-)

diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
index c535540..6a0217d 100644
--- a/arch/arm/xen/enlighten.c
+++ b/arch/arm/xen/enlighten.c
@@ -5,6 +5,9 @@
 #include <asm/xen/hypervisor.h>
 #include <asm/xen/hypercall.h>
 #include <linux/module.h>
+#include <linux/of.h>
+#include <linux/of_irq.h>
+#include <linux/of_address.h>
 
 struct start_info _xen_start_info;
 struct start_info *xen_start_info = &_xen_start_info;
@@ -33,3 +36,61 @@ int xen_remap_domain_mfn_range(struct vm_area_struct *vma,
 	return -ENOSYS;
 }
 EXPORT_SYMBOL_GPL(xen_remap_domain_mfn_range);
+
+/*
+ * see Documentation/devicetree/bindings/arm/xen.txt for the
+ * documentation of the Xen Device Tree format.
+ */
+static int __init xen_guest_init(void)
+{
+	struct xen_add_to_physmap xatp;
+	static struct shared_info *shared_info_page = 0;
+	struct device_node *node;
+	int len;
+	const char *s = NULL;
+	const char *version = NULL;
+	const char *xen_prefix = "xen,xen-";
+
+	node = of_find_compatible_node(NULL, NULL, "xen,xen");
+	if (!node) {
+		pr_debug("No Xen support\n");
+		return 0;
+	}
+	s = of_get_property(node, "compatible", &len);
+	if (strlen(xen_prefix) + 3  < len &&
+			!strncmp(xen_prefix, s, strlen(xen_prefix)))
+		version = s + strlen(xen_prefix);
+	if (version == NULL) {
+		pr_debug("Xen version not found\n");
+		return 0;
+	}
+	xen_domain_type = XEN_HVM_DOMAIN;
+
+	if (!shared_info_page)
+		shared_info_page = (struct shared_info *)
+			get_zeroed_page(GFP_KERNEL);
+	if (!shared_info_page) {
+		pr_err("not enough memory\n");
+		return -ENOMEM;
+	}
+	xatp.domid = DOMID_SELF;
+	xatp.idx = 0;
+	xatp.space = XENMAPSPACE_shared_info;
+	xatp.gpfn = __pa(shared_info_page) >> PAGE_SHIFT;
+	if (HYPERVISOR_memory_op(XENMEM_add_to_physmap, &xatp))
+		BUG();
+
+	HYPERVISOR_shared_info = (struct shared_info *)shared_info_page;
+
+	/* xen_vcpu is a pointer to the vcpu_info struct in the shared_info
+	 * page, we use it in the event channel upcall and in some pvclock
+	 * related functions. We don't need the vcpu_info placement
+	 * optimizations because we don't use any pv_mmu or pv_irq op on
+	 * HVM.
+	 * The shared info contains exactly 1 CPU (the boot CPU). The guest
+	 * is required to use VCPUOP_register_vcpu_info to place vcpu info
+	 * for secondary CPUs as they are brought up. */
+	per_cpu(xen_vcpu, 0) = &HYPERVISOR_shared_info->vcpu_info[0];
+	return 0;
+}
+core_initcall(xen_guest_init);
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 14 11:14:37 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 11:14:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TCTqr-0005Wn-OC; Fri, 14 Sep 2012 11:14:25 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1TCTqq-0005UX-MI
	for xen-devel@lists.xensource.com; Fri, 14 Sep 2012 11:14:24 +0000
Received: from [85.158.137.99:6363] by server-7.bemta-3.messagelabs.com id
	59/A3-32000-09113505; Fri, 14 Sep 2012 11:14:24 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-7.tower-217.messagelabs.com!1347621260!12870564!3
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNzQ1Njg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2613 invoked from network); 14 Sep 2012 11:14:23 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-7.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Sep 2012 11:14:23 -0000
X-IronPort-AV: E=Sophos;i="4.80,422,1344211200"; d="scan'208";a="208101222"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Sep 2012 11:14:06 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Fri, 14 Sep 2012 07:14:05 -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 1TCTqN-0005wt-CW;
	Fri, 14 Sep 2012 12:13:55 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: <arnd@arndb.de>
Date: Fri, 14 Sep 2012 12:13:10 +0100
Message-ID: <1347621207-11294-8-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <alpine.DEB.2.02.1209141145150.29232@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1209141145150.29232@kaball.uk.xensource.com>
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com, linaro-dev@lists.linaro.org,
	Ian.Campbell@citrix.com, konrad.wilk@oracle.com, catalin.marinas@arm.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	tim@xen.org, linux-kernel@vger.kernel.org,
	linux@arm.linux.org.uk, linux-arm-kernel@lists.infradead.org
Subject: [Xen-devel] [PATCH v4 08/24] xen/arm: Introduce xen_pfn_t for pfn
	and mfn types
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 the original Xen headers have xen_pfn_t as mfn and pfn type, however
when they have been imported in Linux, xen_pfn_t has been replaced with
unsigned long. That might work for x86 and ia64 but it does not for arm.
Bring back xen_pfn_t and let each architecture define xen_pfn_t as they
see fit.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 arch/arm/include/asm/xen/interface.h  |    4 ++++
 arch/ia64/include/asm/xen/interface.h |    5 ++++-
 arch/x86/include/asm/xen/interface.h  |    5 +++++
 include/xen/interface/grant_table.h   |    4 ++--
 include/xen/interface/memory.h        |    6 +++---
 include/xen/interface/platform.h      |    4 ++--
 include/xen/interface/xen.h           |    6 +++---
 include/xen/privcmd.h                 |    2 --
 8 files changed, 23 insertions(+), 13 deletions(-)

diff --git a/arch/arm/include/asm/xen/interface.h b/arch/arm/include/asm/xen/interface.h
index 9e0ec5a..74c72b5 100644
--- a/arch/arm/include/asm/xen/interface.h
+++ b/arch/arm/include/asm/xen/interface.h
@@ -25,6 +25,9 @@
 	} while (0)
 
 #ifndef __ASSEMBLY__
+/* Explicitly size integers that represent pfns in the interface with
+ * Xen so that we can have one ABI that works for 32 and 64 bit guests. */
+typedef uint64_t xen_pfn_t;
 /* Guest handles for primitive C types. */
 __DEFINE_GUEST_HANDLE(uchar, unsigned char);
 __DEFINE_GUEST_HANDLE(uint,  unsigned int);
@@ -35,6 +38,7 @@ DEFINE_GUEST_HANDLE(long);
 DEFINE_GUEST_HANDLE(void);
 DEFINE_GUEST_HANDLE(uint64_t);
 DEFINE_GUEST_HANDLE(uint32_t);
+DEFINE_GUEST_HANDLE(xen_pfn_t);
 
 /* Maximum number of virtual CPUs in multi-processor guests. */
 #define MAX_VIRT_CPUS 1
diff --git a/arch/ia64/include/asm/xen/interface.h b/arch/ia64/include/asm/xen/interface.h
index 09d5f7f..686464e 100644
--- a/arch/ia64/include/asm/xen/interface.h
+++ b/arch/ia64/include/asm/xen/interface.h
@@ -67,6 +67,10 @@
 #define set_xen_guest_handle(hnd, val)	do { (hnd).p = val; } while (0)
 
 #ifndef __ASSEMBLY__
+/* Explicitly size integers that represent pfns in the public interface
+ * with Xen so that we could have one ABI that works for 32 and 64 bit
+ * guests. */
+typedef unsigned long xen_pfn_t;
 /* Guest handles for primitive C types. */
 __DEFINE_GUEST_HANDLE(uchar, unsigned char);
 __DEFINE_GUEST_HANDLE(uint, unsigned int);
@@ -79,7 +83,6 @@ DEFINE_GUEST_HANDLE(void);
 DEFINE_GUEST_HANDLE(uint64_t);
 DEFINE_GUEST_HANDLE(uint32_t);
 
-typedef unsigned long xen_pfn_t;
 DEFINE_GUEST_HANDLE(xen_pfn_t);
 #define PRI_xen_pfn	"lx"
 #endif
diff --git a/arch/x86/include/asm/xen/interface.h b/arch/x86/include/asm/xen/interface.h
index cbf0c9d..2289075 100644
--- a/arch/x86/include/asm/xen/interface.h
+++ b/arch/x86/include/asm/xen/interface.h
@@ -47,6 +47,10 @@
 #endif
 
 #ifndef __ASSEMBLY__
+/* Explicitly size integers that represent pfns in the public interface
+ * with Xen so that on ARM we can have one ABI that works for 32 and 64
+ * bit guests. */
+typedef unsigned long xen_pfn_t;
 /* Guest handles for primitive C types. */
 __DEFINE_GUEST_HANDLE(uchar, unsigned char);
 __DEFINE_GUEST_HANDLE(uint,  unsigned int);
@@ -57,6 +61,7 @@ DEFINE_GUEST_HANDLE(long);
 DEFINE_GUEST_HANDLE(void);
 DEFINE_GUEST_HANDLE(uint64_t);
 DEFINE_GUEST_HANDLE(uint32_t);
+DEFINE_GUEST_HANDLE(xen_pfn_t);
 #endif
 
 #ifndef HYPERVISOR_VIRT_START
diff --git a/include/xen/interface/grant_table.h b/include/xen/interface/grant_table.h
index a17d844..7da811b 100644
--- a/include/xen/interface/grant_table.h
+++ b/include/xen/interface/grant_table.h
@@ -338,7 +338,7 @@ DEFINE_GUEST_HANDLE_STRUCT(gnttab_dump_table);
 #define GNTTABOP_transfer                4
 struct gnttab_transfer {
     /* IN parameters. */
-    unsigned long mfn;
+    xen_pfn_t mfn;
     domid_t       domid;
     grant_ref_t   ref;
     /* OUT parameters. */
@@ -375,7 +375,7 @@ struct gnttab_copy {
 	struct {
 		union {
 			grant_ref_t ref;
-			unsigned long   gmfn;
+			xen_pfn_t   gmfn;
 		} u;
 		domid_t  domid;
 		uint16_t offset;
diff --git a/include/xen/interface/memory.h b/include/xen/interface/memory.h
index eac3ce1..abbbff0 100644
--- a/include/xen/interface/memory.h
+++ b/include/xen/interface/memory.h
@@ -31,7 +31,7 @@ struct xen_memory_reservation {
      *   OUT: GMFN bases of extents that were allocated
      *   (NB. This command also updates the mach_to_phys translation table)
      */
-    GUEST_HANDLE(ulong) extent_start;
+    GUEST_HANDLE(xen_pfn_t) extent_start;
 
     /* Number of extents, and size/alignment of each (2^extent_order pages). */
     unsigned long  nr_extents;
@@ -130,7 +130,7 @@ struct xen_machphys_mfn_list {
      * any large discontiguities in the machine address space, 2MB gaps in
      * the machphys table will be represented by an MFN base of zero.
      */
-    GUEST_HANDLE(ulong) extent_start;
+    GUEST_HANDLE(xen_pfn_t) extent_start;
 
     /*
      * Number of extents written to the above array. This will be smaller
@@ -172,7 +172,7 @@ struct xen_add_to_physmap {
     unsigned long idx;
 
     /* GPFN where the source mapping page should appear. */
-    unsigned long gpfn;
+    xen_pfn_t gpfn;
 };
 DEFINE_GUEST_HANDLE_STRUCT(xen_add_to_physmap);
 
diff --git a/include/xen/interface/platform.h b/include/xen/interface/platform.h
index 61fa661..a3275a8 100644
--- a/include/xen/interface/platform.h
+++ b/include/xen/interface/platform.h
@@ -54,7 +54,7 @@ DEFINE_GUEST_HANDLE_STRUCT(xenpf_settime_t);
 #define XENPF_add_memtype         31
 struct xenpf_add_memtype {
 	/* IN variables. */
-	unsigned long mfn;
+	xen_pfn_t mfn;
 	uint64_t nr_mfns;
 	uint32_t type;
 	/* OUT variables. */
@@ -84,7 +84,7 @@ struct xenpf_read_memtype {
 	/* IN variables. */
 	uint32_t reg;
 	/* OUT variables. */
-	unsigned long mfn;
+	xen_pfn_t mfn;
 	uint64_t nr_mfns;
 	uint32_t type;
 };
diff --git a/include/xen/interface/xen.h b/include/xen/interface/xen.h
index 0801468..0054db1 100644
--- a/include/xen/interface/xen.h
+++ b/include/xen/interface/xen.h
@@ -190,7 +190,7 @@ struct mmuext_op {
 	unsigned int cmd;
 	union {
 		/* [UN]PIN_TABLE, NEW_BASEPTR, NEW_USER_BASEPTR */
-		unsigned long mfn;
+		xen_pfn_t mfn;
 		/* INVLPG_LOCAL, INVLPG_ALL, SET_LDT */
 		unsigned long linear_addr;
 	} arg1;
@@ -430,11 +430,11 @@ struct start_info {
 	unsigned long nr_pages;     /* Total pages allocated to this domain.  */
 	unsigned long shared_info;  /* MACHINE address of shared info struct. */
 	uint32_t flags;             /* SIF_xxx flags.                         */
-	unsigned long store_mfn;    /* MACHINE page number of shared page.    */
+	xen_pfn_t store_mfn;        /* MACHINE page number of shared page.    */
 	uint32_t store_evtchn;      /* Event channel for store communication. */
 	union {
 		struct {
-			unsigned long mfn;  /* MACHINE page number of console page.   */
+			xen_pfn_t mfn;      /* MACHINE page number of console page.   */
 			uint32_t  evtchn;   /* Event channel for console page.        */
 		} domU;
 		struct {
diff --git a/include/xen/privcmd.h b/include/xen/privcmd.h
index 17857fb..59f1bd8 100644
--- a/include/xen/privcmd.h
+++ b/include/xen/privcmd.h
@@ -36,8 +36,6 @@
 #include <linux/types.h>
 #include <linux/compiler.h>
 
-typedef unsigned long xen_pfn_t;
-
 struct privcmd_hypercall {
 	__u64 op;
 	__u64 arg[5];
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 14 11:14:37 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 11:14:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TCTqr-0005Wn-OC; Fri, 14 Sep 2012 11:14:25 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1TCTqq-0005UX-MI
	for xen-devel@lists.xensource.com; Fri, 14 Sep 2012 11:14:24 +0000
Received: from [85.158.137.99:6363] by server-7.bemta-3.messagelabs.com id
	59/A3-32000-09113505; Fri, 14 Sep 2012 11:14:24 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-7.tower-217.messagelabs.com!1347621260!12870564!3
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNzQ1Njg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2613 invoked from network); 14 Sep 2012 11:14:23 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-7.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Sep 2012 11:14:23 -0000
X-IronPort-AV: E=Sophos;i="4.80,422,1344211200"; d="scan'208";a="208101222"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Sep 2012 11:14:06 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Fri, 14 Sep 2012 07:14:05 -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 1TCTqN-0005wt-CW;
	Fri, 14 Sep 2012 12:13:55 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: <arnd@arndb.de>
Date: Fri, 14 Sep 2012 12:13:10 +0100
Message-ID: <1347621207-11294-8-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <alpine.DEB.2.02.1209141145150.29232@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1209141145150.29232@kaball.uk.xensource.com>
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com, linaro-dev@lists.linaro.org,
	Ian.Campbell@citrix.com, konrad.wilk@oracle.com, catalin.marinas@arm.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	tim@xen.org, linux-kernel@vger.kernel.org,
	linux@arm.linux.org.uk, linux-arm-kernel@lists.infradead.org
Subject: [Xen-devel] [PATCH v4 08/24] xen/arm: Introduce xen_pfn_t for pfn
	and mfn types
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 the original Xen headers have xen_pfn_t as mfn and pfn type, however
when they have been imported in Linux, xen_pfn_t has been replaced with
unsigned long. That might work for x86 and ia64 but it does not for arm.
Bring back xen_pfn_t and let each architecture define xen_pfn_t as they
see fit.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 arch/arm/include/asm/xen/interface.h  |    4 ++++
 arch/ia64/include/asm/xen/interface.h |    5 ++++-
 arch/x86/include/asm/xen/interface.h  |    5 +++++
 include/xen/interface/grant_table.h   |    4 ++--
 include/xen/interface/memory.h        |    6 +++---
 include/xen/interface/platform.h      |    4 ++--
 include/xen/interface/xen.h           |    6 +++---
 include/xen/privcmd.h                 |    2 --
 8 files changed, 23 insertions(+), 13 deletions(-)

diff --git a/arch/arm/include/asm/xen/interface.h b/arch/arm/include/asm/xen/interface.h
index 9e0ec5a..74c72b5 100644
--- a/arch/arm/include/asm/xen/interface.h
+++ b/arch/arm/include/asm/xen/interface.h
@@ -25,6 +25,9 @@
 	} while (0)
 
 #ifndef __ASSEMBLY__
+/* Explicitly size integers that represent pfns in the interface with
+ * Xen so that we can have one ABI that works for 32 and 64 bit guests. */
+typedef uint64_t xen_pfn_t;
 /* Guest handles for primitive C types. */
 __DEFINE_GUEST_HANDLE(uchar, unsigned char);
 __DEFINE_GUEST_HANDLE(uint,  unsigned int);
@@ -35,6 +38,7 @@ DEFINE_GUEST_HANDLE(long);
 DEFINE_GUEST_HANDLE(void);
 DEFINE_GUEST_HANDLE(uint64_t);
 DEFINE_GUEST_HANDLE(uint32_t);
+DEFINE_GUEST_HANDLE(xen_pfn_t);
 
 /* Maximum number of virtual CPUs in multi-processor guests. */
 #define MAX_VIRT_CPUS 1
diff --git a/arch/ia64/include/asm/xen/interface.h b/arch/ia64/include/asm/xen/interface.h
index 09d5f7f..686464e 100644
--- a/arch/ia64/include/asm/xen/interface.h
+++ b/arch/ia64/include/asm/xen/interface.h
@@ -67,6 +67,10 @@
 #define set_xen_guest_handle(hnd, val)	do { (hnd).p = val; } while (0)
 
 #ifndef __ASSEMBLY__
+/* Explicitly size integers that represent pfns in the public interface
+ * with Xen so that we could have one ABI that works for 32 and 64 bit
+ * guests. */
+typedef unsigned long xen_pfn_t;
 /* Guest handles for primitive C types. */
 __DEFINE_GUEST_HANDLE(uchar, unsigned char);
 __DEFINE_GUEST_HANDLE(uint, unsigned int);
@@ -79,7 +83,6 @@ DEFINE_GUEST_HANDLE(void);
 DEFINE_GUEST_HANDLE(uint64_t);
 DEFINE_GUEST_HANDLE(uint32_t);
 
-typedef unsigned long xen_pfn_t;
 DEFINE_GUEST_HANDLE(xen_pfn_t);
 #define PRI_xen_pfn	"lx"
 #endif
diff --git a/arch/x86/include/asm/xen/interface.h b/arch/x86/include/asm/xen/interface.h
index cbf0c9d..2289075 100644
--- a/arch/x86/include/asm/xen/interface.h
+++ b/arch/x86/include/asm/xen/interface.h
@@ -47,6 +47,10 @@
 #endif
 
 #ifndef __ASSEMBLY__
+/* Explicitly size integers that represent pfns in the public interface
+ * with Xen so that on ARM we can have one ABI that works for 32 and 64
+ * bit guests. */
+typedef unsigned long xen_pfn_t;
 /* Guest handles for primitive C types. */
 __DEFINE_GUEST_HANDLE(uchar, unsigned char);
 __DEFINE_GUEST_HANDLE(uint,  unsigned int);
@@ -57,6 +61,7 @@ DEFINE_GUEST_HANDLE(long);
 DEFINE_GUEST_HANDLE(void);
 DEFINE_GUEST_HANDLE(uint64_t);
 DEFINE_GUEST_HANDLE(uint32_t);
+DEFINE_GUEST_HANDLE(xen_pfn_t);
 #endif
 
 #ifndef HYPERVISOR_VIRT_START
diff --git a/include/xen/interface/grant_table.h b/include/xen/interface/grant_table.h
index a17d844..7da811b 100644
--- a/include/xen/interface/grant_table.h
+++ b/include/xen/interface/grant_table.h
@@ -338,7 +338,7 @@ DEFINE_GUEST_HANDLE_STRUCT(gnttab_dump_table);
 #define GNTTABOP_transfer                4
 struct gnttab_transfer {
     /* IN parameters. */
-    unsigned long mfn;
+    xen_pfn_t mfn;
     domid_t       domid;
     grant_ref_t   ref;
     /* OUT parameters. */
@@ -375,7 +375,7 @@ struct gnttab_copy {
 	struct {
 		union {
 			grant_ref_t ref;
-			unsigned long   gmfn;
+			xen_pfn_t   gmfn;
 		} u;
 		domid_t  domid;
 		uint16_t offset;
diff --git a/include/xen/interface/memory.h b/include/xen/interface/memory.h
index eac3ce1..abbbff0 100644
--- a/include/xen/interface/memory.h
+++ b/include/xen/interface/memory.h
@@ -31,7 +31,7 @@ struct xen_memory_reservation {
      *   OUT: GMFN bases of extents that were allocated
      *   (NB. This command also updates the mach_to_phys translation table)
      */
-    GUEST_HANDLE(ulong) extent_start;
+    GUEST_HANDLE(xen_pfn_t) extent_start;
 
     /* Number of extents, and size/alignment of each (2^extent_order pages). */
     unsigned long  nr_extents;
@@ -130,7 +130,7 @@ struct xen_machphys_mfn_list {
      * any large discontiguities in the machine address space, 2MB gaps in
      * the machphys table will be represented by an MFN base of zero.
      */
-    GUEST_HANDLE(ulong) extent_start;
+    GUEST_HANDLE(xen_pfn_t) extent_start;
 
     /*
      * Number of extents written to the above array. This will be smaller
@@ -172,7 +172,7 @@ struct xen_add_to_physmap {
     unsigned long idx;
 
     /* GPFN where the source mapping page should appear. */
-    unsigned long gpfn;
+    xen_pfn_t gpfn;
 };
 DEFINE_GUEST_HANDLE_STRUCT(xen_add_to_physmap);
 
diff --git a/include/xen/interface/platform.h b/include/xen/interface/platform.h
index 61fa661..a3275a8 100644
--- a/include/xen/interface/platform.h
+++ b/include/xen/interface/platform.h
@@ -54,7 +54,7 @@ DEFINE_GUEST_HANDLE_STRUCT(xenpf_settime_t);
 #define XENPF_add_memtype         31
 struct xenpf_add_memtype {
 	/* IN variables. */
-	unsigned long mfn;
+	xen_pfn_t mfn;
 	uint64_t nr_mfns;
 	uint32_t type;
 	/* OUT variables. */
@@ -84,7 +84,7 @@ struct xenpf_read_memtype {
 	/* IN variables. */
 	uint32_t reg;
 	/* OUT variables. */
-	unsigned long mfn;
+	xen_pfn_t mfn;
 	uint64_t nr_mfns;
 	uint32_t type;
 };
diff --git a/include/xen/interface/xen.h b/include/xen/interface/xen.h
index 0801468..0054db1 100644
--- a/include/xen/interface/xen.h
+++ b/include/xen/interface/xen.h
@@ -190,7 +190,7 @@ struct mmuext_op {
 	unsigned int cmd;
 	union {
 		/* [UN]PIN_TABLE, NEW_BASEPTR, NEW_USER_BASEPTR */
-		unsigned long mfn;
+		xen_pfn_t mfn;
 		/* INVLPG_LOCAL, INVLPG_ALL, SET_LDT */
 		unsigned long linear_addr;
 	} arg1;
@@ -430,11 +430,11 @@ struct start_info {
 	unsigned long nr_pages;     /* Total pages allocated to this domain.  */
 	unsigned long shared_info;  /* MACHINE address of shared info struct. */
 	uint32_t flags;             /* SIF_xxx flags.                         */
-	unsigned long store_mfn;    /* MACHINE page number of shared page.    */
+	xen_pfn_t store_mfn;        /* MACHINE page number of shared page.    */
 	uint32_t store_evtchn;      /* Event channel for store communication. */
 	union {
 		struct {
-			unsigned long mfn;  /* MACHINE page number of console page.   */
+			xen_pfn_t mfn;      /* MACHINE page number of console page.   */
 			uint32_t  evtchn;   /* Event channel for console page.        */
 		} domU;
 		struct {
diff --git a/include/xen/privcmd.h b/include/xen/privcmd.h
index 17857fb..59f1bd8 100644
--- a/include/xen/privcmd.h
+++ b/include/xen/privcmd.h
@@ -36,8 +36,6 @@
 #include <linux/types.h>
 #include <linux/compiler.h>
 
-typedef unsigned long xen_pfn_t;
-
 struct privcmd_hypercall {
 	__u64 op;
 	__u64 arg[5];
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 14 11:36:01 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 11: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 1TCUBY-00072C-1T; Fri, 14 Sep 2012 11:35:48 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1TCUBW-000724-Ti
	for xen-devel@lists.xen.org; Fri, 14 Sep 2012 11:35:47 +0000
Received: from [85.158.137.99:45228] by server-4.bemta-3.messagelabs.com id
	B0/44-24831-19613505; Fri, 14 Sep 2012 11:35:45 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-217.messagelabs.com!1347622545!17677211!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10932 invoked from network); 14 Sep 2012 11:35:45 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-10.tower-217.messagelabs.com with SMTP;
	14 Sep 2012 11:35:45 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 14 Sep 2012 12:35:44 +0100
Message-Id: <505332E8020000780009B60C@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 14 Sep 2012 12:36:40 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Campbell" <Ian.Campbell@citrix.com>
References: <640a0b0b44e67c843473.1347616836@cosworth.uk.xensource.com>
	<50531D98020000780009B54D@nat28.tlf.novell.com>
	<1347619509.24226.178.camel@zakaz.uk.xensource.com>
In-Reply-To: <1347619509.24226.178.camel@zakaz.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] tools: drop ia64 only foreign structs from
	headers
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 14.09.12 at 12:45, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> On Fri, 2012-09-14 at 11:05 +0100, Jan Beulich wrote:
>> >>> On 14.09.12 at 12:00, Ian Campbell <ian.campbell@citrix.com> wrote:
>> > # HG changeset patch
>> > # User Ian Campbell <ian.campbell@citrix.com>
>> > # Date 1347616748 -3600
>> > # Node ID 640a0b0b44e67c8434735c5129400b3a56a43683
>> > # Parent  aabf685cd613b11e9b9709ae2a43f23f56d4d7ff
>> > tools: drop ia64 only foreign structs from headers
>> 
>> Not sure why they got put there in the first place.
> 
> What are the criteria to be listed here? I was surprised how short the
> list was...

Don't know, this got introduced by Gerd Hoffmann, who I think
hasn't been working on Xen anymore for years. I believe this is
on an as-needed-by-the-tools basis.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 14 11:36:01 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 11: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 1TCUBY-00072C-1T; Fri, 14 Sep 2012 11:35:48 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1TCUBW-000724-Ti
	for xen-devel@lists.xen.org; Fri, 14 Sep 2012 11:35:47 +0000
Received: from [85.158.137.99:45228] by server-4.bemta-3.messagelabs.com id
	B0/44-24831-19613505; Fri, 14 Sep 2012 11:35:45 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-217.messagelabs.com!1347622545!17677211!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10932 invoked from network); 14 Sep 2012 11:35:45 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-10.tower-217.messagelabs.com with SMTP;
	14 Sep 2012 11:35:45 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 14 Sep 2012 12:35:44 +0100
Message-Id: <505332E8020000780009B60C@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 14 Sep 2012 12:36:40 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Campbell" <Ian.Campbell@citrix.com>
References: <640a0b0b44e67c843473.1347616836@cosworth.uk.xensource.com>
	<50531D98020000780009B54D@nat28.tlf.novell.com>
	<1347619509.24226.178.camel@zakaz.uk.xensource.com>
In-Reply-To: <1347619509.24226.178.camel@zakaz.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] tools: drop ia64 only foreign structs from
	headers
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 14.09.12 at 12:45, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> On Fri, 2012-09-14 at 11:05 +0100, Jan Beulich wrote:
>> >>> On 14.09.12 at 12:00, Ian Campbell <ian.campbell@citrix.com> wrote:
>> > # HG changeset patch
>> > # User Ian Campbell <ian.campbell@citrix.com>
>> > # Date 1347616748 -3600
>> > # Node ID 640a0b0b44e67c8434735c5129400b3a56a43683
>> > # Parent  aabf685cd613b11e9b9709ae2a43f23f56d4d7ff
>> > tools: drop ia64 only foreign structs from headers
>> 
>> Not sure why they got put there in the first place.
> 
> What are the criteria to be listed here? I was surprised how short the
> list was...

Don't know, this got introduced by Gerd Hoffmann, who I think
hasn't been working on Xen anymore for years. I believe this is
on an as-needed-by-the-tools basis.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 14 11:41:10 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 11:41:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TCUGX-0007DP-PL; Fri, 14 Sep 2012 11:40:57 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1TCUGW-0007DI-AY
	for xen-devel@lists.xensource.com; Fri, 14 Sep 2012 11:40:56 +0000
Received: from [85.158.138.51:49941] by server-11.bemta-3.messagelabs.com id
	69/84-30250-7C713505; Fri, 14 Sep 2012 11:40:55 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1347622853!30530797!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNzQ1Njg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1845 invoked from network); 14 Sep 2012 11:40:54 -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;
	14 Sep 2012 11:40:54 -0000
X-IronPort-AV: E=Sophos;i="4.80,422,1344211200"; d="scan'208";a="208102925"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Sep 2012 11:40:52 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Fri, 14 Sep 2012 07:40:52 -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 1TCTqN-0005wt-Fc;
	Fri, 14 Sep 2012 12:13:55 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: <arnd@arndb.de>
Date: Fri, 14 Sep 2012 12:13:13 +0100
Message-ID: <1347621207-11294-11-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <alpine.DEB.2.02.1209141145150.29232@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1209141145150.29232@kaball.uk.xensource.com>
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com, linaro-dev@lists.linaro.org,
	Ian.Campbell@citrix.com, konrad.wilk@oracle.com, catalin.marinas@arm.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	tim@xen.org, linux-kernel@vger.kernel.org,
	linux@arm.linux.org.uk, linux-arm-kernel@lists.infradead.org
Subject: [Xen-devel] [PATCH v4 11/24] xen: do not compile manage, balloon,
	pci, acpi, pcpu and cpu_hotplug on ARM
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Changes in v4:
- compile pcpu only on x86;
- use "+=" instead of ":=" for dom0- targets.

Changes in v2:

- make pci.o depend on CONFIG_PCI and acpi.o depend on CONFIG_ACPI.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 drivers/xen/Makefile |   13 +++++++++----
 1 files changed, 9 insertions(+), 4 deletions(-)

diff --git a/drivers/xen/Makefile b/drivers/xen/Makefile
index d80bea5..cd28aae 100644
--- a/drivers/xen/Makefile
+++ b/drivers/xen/Makefile
@@ -1,11 +1,18 @@
-obj-y	+= grant-table.o features.o events.o manage.o balloon.o
+ifneq ($(CONFIG_ARM),y)
+obj-y	+= manage.o balloon.o
+obj-$(CONFIG_HOTPLUG_CPU)		+= cpu_hotplug.o
+endif
+obj-y	+= grant-table.o features.o events.o
 obj-y	+= xenbus/
 
 nostackp := $(call cc-option, -fno-stack-protector)
 CFLAGS_features.o			:= $(nostackp)
 
+obj-$(CONFIG_XEN_DOM0)			+= $(dom0-y)
+dom0-$(CONFIG_PCI) += pci.o
+dom0-$(CONFIG_ACPI) += acpi.o
+dom0-$(CONFIG_X86) += pcpu.o
 obj-$(CONFIG_BLOCK)			+= biomerge.o
-obj-$(CONFIG_HOTPLUG_CPU)		+= cpu_hotplug.o
 obj-$(CONFIG_XEN_XENCOMM)		+= xencomm.o
 obj-$(CONFIG_XEN_BALLOON)		+= xen-balloon.o
 obj-$(CONFIG_XEN_SELFBALLOONING)	+= xen-selfballoon.o
@@ -17,8 +24,6 @@ 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/
 obj-$(CONFIG_XEN_PRIVCMD)		+= xen-privcmd.o
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 14 11:41:10 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 11:41:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TCUGX-0007DP-PL; Fri, 14 Sep 2012 11:40:57 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1TCUGW-0007DI-AY
	for xen-devel@lists.xensource.com; Fri, 14 Sep 2012 11:40:56 +0000
Received: from [85.158.138.51:49941] by server-11.bemta-3.messagelabs.com id
	69/84-30250-7C713505; Fri, 14 Sep 2012 11:40:55 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1347622853!30530797!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNzQ1Njg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1845 invoked from network); 14 Sep 2012 11:40:54 -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;
	14 Sep 2012 11:40:54 -0000
X-IronPort-AV: E=Sophos;i="4.80,422,1344211200"; d="scan'208";a="208102925"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Sep 2012 11:40:52 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Fri, 14 Sep 2012 07:40:52 -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 1TCTqN-0005wt-Fc;
	Fri, 14 Sep 2012 12:13:55 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: <arnd@arndb.de>
Date: Fri, 14 Sep 2012 12:13:13 +0100
Message-ID: <1347621207-11294-11-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <alpine.DEB.2.02.1209141145150.29232@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1209141145150.29232@kaball.uk.xensource.com>
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com, linaro-dev@lists.linaro.org,
	Ian.Campbell@citrix.com, konrad.wilk@oracle.com, catalin.marinas@arm.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	tim@xen.org, linux-kernel@vger.kernel.org,
	linux@arm.linux.org.uk, linux-arm-kernel@lists.infradead.org
Subject: [Xen-devel] [PATCH v4 11/24] xen: do not compile manage, balloon,
	pci, acpi, pcpu and cpu_hotplug on ARM
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Changes in v4:
- compile pcpu only on x86;
- use "+=" instead of ":=" for dom0- targets.

Changes in v2:

- make pci.o depend on CONFIG_PCI and acpi.o depend on CONFIG_ACPI.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 drivers/xen/Makefile |   13 +++++++++----
 1 files changed, 9 insertions(+), 4 deletions(-)

diff --git a/drivers/xen/Makefile b/drivers/xen/Makefile
index d80bea5..cd28aae 100644
--- a/drivers/xen/Makefile
+++ b/drivers/xen/Makefile
@@ -1,11 +1,18 @@
-obj-y	+= grant-table.o features.o events.o manage.o balloon.o
+ifneq ($(CONFIG_ARM),y)
+obj-y	+= manage.o balloon.o
+obj-$(CONFIG_HOTPLUG_CPU)		+= cpu_hotplug.o
+endif
+obj-y	+= grant-table.o features.o events.o
 obj-y	+= xenbus/
 
 nostackp := $(call cc-option, -fno-stack-protector)
 CFLAGS_features.o			:= $(nostackp)
 
+obj-$(CONFIG_XEN_DOM0)			+= $(dom0-y)
+dom0-$(CONFIG_PCI) += pci.o
+dom0-$(CONFIG_ACPI) += acpi.o
+dom0-$(CONFIG_X86) += pcpu.o
 obj-$(CONFIG_BLOCK)			+= biomerge.o
-obj-$(CONFIG_HOTPLUG_CPU)		+= cpu_hotplug.o
 obj-$(CONFIG_XEN_XENCOMM)		+= xencomm.o
 obj-$(CONFIG_XEN_BALLOON)		+= xen-balloon.o
 obj-$(CONFIG_XEN_SELFBALLOONING)	+= xen-selfballoon.o
@@ -17,8 +24,6 @@ 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/
 obj-$(CONFIG_XEN_PRIVCMD)		+= xen-privcmd.o
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 14 11:41:21 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 11: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 1TCUGn-0007FN-U8; Fri, 14 Sep 2012 11:41: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 1TCUGm-0007El-45
	for xen-devel@lists.xensource.com; Fri, 14 Sep 2012 11:41:12 +0000
Received: from [85.158.138.51:12326] by server-11.bemta-3.messagelabs.com id
	65/45-30250-7D713505; Fri, 14 Sep 2012 11:41:11 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1347622853!30048854!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNjk2MTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18653 invoked from network); 14 Sep 2012 11:40: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;
	14 Sep 2012 11:40:56 -0000
X-IronPort-AV: E=Sophos;i="4.80,422,1344211200"; d="scan'208";a="37874915"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Sep 2012 11:40:46 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Fri, 14 Sep 2012 07:40: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 1TCTqN-0005wt-OK;
	Fri, 14 Sep 2012 12:13:55 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: <arnd@arndb.de>
Date: Fri, 14 Sep 2012 12:13:26 +0100
Message-ID: <1347621207-11294-24-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <alpine.DEB.2.02.1209141145150.29232@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1209141145150.29232@kaball.uk.xensource.com>
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com, linaro-dev@lists.linaro.org,
	Ian.Campbell@citrix.com, konrad.wilk@oracle.com, catalin.marinas@arm.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	tim@xen.org, linux-kernel@vger.kernel.org,
	linux@arm.linux.org.uk, linux-arm-kernel@lists.infradead.org
Subject: [Xen-devel] [PATCH v4 24/24] MAINTAINERS: add myself as Xen ARM
	maintainer
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="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>
CC: Arnd Bergmann <arnd@arndb.de>
CC: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 MAINTAINERS |    7 +++++++
 1 files changed, 7 insertions(+), 0 deletions(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index fdc0119..3d38291 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -7752,6 +7752,13 @@ F:	drivers/xen/
 F:	arch/x86/include/asm/xen/
 F:	include/xen/
 
+XEN HYPERVISOR ARM
+M:	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
+L:	xen-devel@lists.xensource.com (moderated for non-subscribers)
+S:	Supported
+F:	arch/arm/xen/
+F:	arch/arm/include/asm/xen/
+
 XEN NETWORK BACKEND DRIVER
 M:	Ian Campbell <ian.campbell@citrix.com>
 L:	xen-devel@lists.xensource.com (moderated for non-subscribers)
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 14 11:41:21 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 11: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 1TCUGn-0007FN-U8; Fri, 14 Sep 2012 11:41: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 1TCUGm-0007El-45
	for xen-devel@lists.xensource.com; Fri, 14 Sep 2012 11:41:12 +0000
Received: from [85.158.138.51:12326] by server-11.bemta-3.messagelabs.com id
	65/45-30250-7D713505; Fri, 14 Sep 2012 11:41:11 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1347622853!30048854!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNjk2MTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18653 invoked from network); 14 Sep 2012 11:40: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;
	14 Sep 2012 11:40:56 -0000
X-IronPort-AV: E=Sophos;i="4.80,422,1344211200"; d="scan'208";a="37874915"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Sep 2012 11:40:46 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Fri, 14 Sep 2012 07:40: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 1TCTqN-0005wt-OK;
	Fri, 14 Sep 2012 12:13:55 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: <arnd@arndb.de>
Date: Fri, 14 Sep 2012 12:13:26 +0100
Message-ID: <1347621207-11294-24-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <alpine.DEB.2.02.1209141145150.29232@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1209141145150.29232@kaball.uk.xensource.com>
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com, linaro-dev@lists.linaro.org,
	Ian.Campbell@citrix.com, konrad.wilk@oracle.com, catalin.marinas@arm.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	tim@xen.org, linux-kernel@vger.kernel.org,
	linux@arm.linux.org.uk, linux-arm-kernel@lists.infradead.org
Subject: [Xen-devel] [PATCH v4 24/24] MAINTAINERS: add myself as Xen ARM
	maintainer
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="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>
CC: Arnd Bergmann <arnd@arndb.de>
CC: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 MAINTAINERS |    7 +++++++
 1 files changed, 7 insertions(+), 0 deletions(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index fdc0119..3d38291 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -7752,6 +7752,13 @@ F:	drivers/xen/
 F:	arch/x86/include/asm/xen/
 F:	include/xen/
 
+XEN HYPERVISOR ARM
+M:	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
+L:	xen-devel@lists.xensource.com (moderated for non-subscribers)
+S:	Supported
+F:	arch/arm/xen/
+F:	arch/arm/include/asm/xen/
+
 XEN NETWORK BACKEND DRIVER
 M:	Ian Campbell <ian.campbell@citrix.com>
 L:	xen-devel@lists.xensource.com (moderated for non-subscribers)
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 14 11:41:21 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 11: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 1TCUGn-0007FC-Iw; Fri, 14 Sep 2012 11:41: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 1TCUGl-0007E5-PM
	for xen-devel@lists.xensource.com; Fri, 14 Sep 2012 11:41:12 +0000
Received: from [85.158.138.51:12347] by server-9.bemta-3.messagelabs.com id
	98/85-15390-7D713505; Fri, 14 Sep 2012 11:41:11 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1347622853!30048854!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNjk2MTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18792 invoked from network); 14 Sep 2012 11:40:59 -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;
	14 Sep 2012 11:40:59 -0000
X-IronPort-AV: E=Sophos;i="4.80,422,1344211200"; d="scan'208";a="37874944"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Sep 2012 11:40:58 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Fri, 14 Sep 2012 07:40: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 1TCTqN-0005wt-NB;
	Fri, 14 Sep 2012 12:13:55 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: <arnd@arndb.de>
Date: Fri, 14 Sep 2012 12:13:24 +0100
Message-ID: <1347621207-11294-22-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <alpine.DEB.2.02.1209141145150.29232@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1209141145150.29232@kaball.uk.xensource.com>
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com, linaro-dev@lists.linaro.org,
	Ian.Campbell@citrix.com, konrad.wilk@oracle.com, catalin.marinas@arm.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	tim@xen.org, linux-kernel@vger.kernel.org,
	linux@arm.linux.org.uk, linux-arm-kernel@lists.infradead.org
Subject: [Xen-devel] [PATCH v4 22/24] xen: missing includes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Note: this patch should be already in Konrad's tree, it is here just for
convenience.

Changes in v3:
- add missing pvclock-abi.h include to ia64 header files.

Changes in v2:
- remove pvclock hack;
- remove include linux/types.h from xen/interface/xen.h.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 arch/ia64/include/asm/xen/interface.h      |    2 ++
 arch/x86/include/asm/xen/interface.h       |    2 ++
 drivers/tty/hvc/hvc_xen.c                  |    2 ++
 drivers/xen/grant-table.c                  |    1 +
 drivers/xen/xenbus/xenbus_probe_frontend.c |    1 +
 include/xen/interface/xen.h                |    1 -
 include/xen/privcmd.h                      |    1 +
 7 files changed, 9 insertions(+), 1 deletions(-)

diff --git a/arch/ia64/include/asm/xen/interface.h b/arch/ia64/include/asm/xen/interface.h
index 7c83445..e88c5de 100644
--- a/arch/ia64/include/asm/xen/interface.h
+++ b/arch/ia64/include/asm/xen/interface.h
@@ -269,6 +269,8 @@ typedef struct xen_callback xen_callback_t;
 
 #endif /* !__ASSEMBLY__ */
 
+#include <asm/pvclock-abi.h>
+
 /* Size of the shared_info area (this is not related to page size).  */
 #define XSI_SHIFT			14
 #define XSI_SIZE			(1 << XSI_SHIFT)
diff --git a/arch/x86/include/asm/xen/interface.h b/arch/x86/include/asm/xen/interface.h
index 25cc8df..28fc621 100644
--- a/arch/x86/include/asm/xen/interface.h
+++ b/arch/x86/include/asm/xen/interface.h
@@ -127,6 +127,8 @@ struct arch_shared_info {
 #include "interface_64.h"
 #endif
 
+#include <asm/pvclock-abi.h>
+
 #ifndef __ASSEMBLY__
 /*
  * The following is all CPU context. Note that the fpu_ctxt block is filled
diff --git a/drivers/tty/hvc/hvc_xen.c b/drivers/tty/hvc/hvc_xen.c
index 1e456dc..2944ff8 100644
--- a/drivers/tty/hvc/hvc_xen.c
+++ b/drivers/tty/hvc/hvc_xen.c
@@ -21,6 +21,7 @@
 #include <linux/console.h>
 #include <linux/delay.h>
 #include <linux/err.h>
+#include <linux/irq.h>
 #include <linux/init.h>
 #include <linux/types.h>
 #include <linux/list.h>
@@ -35,6 +36,7 @@
 #include <xen/page.h>
 #include <xen/events.h>
 #include <xen/interface/io/console.h>
+#include <xen/interface/sched.h>
 #include <xen/hvc-console.h>
 #include <xen/xenbus.h>
 
diff --git a/drivers/xen/grant-table.c b/drivers/xen/grant-table.c
index 0bfc1ef..1d0d95e 100644
--- a/drivers/xen/grant-table.c
+++ b/drivers/xen/grant-table.c
@@ -47,6 +47,7 @@
 #include <xen/interface/memory.h>
 #include <xen/hvc-console.h>
 #include <asm/xen/hypercall.h>
+#include <asm/xen/interface.h>
 
 #include <asm/pgtable.h>
 #include <asm/sync_bitops.h>
diff --git a/drivers/xen/xenbus/xenbus_probe_frontend.c b/drivers/xen/xenbus/xenbus_probe_frontend.c
index a31b54d..3159a37 100644
--- a/drivers/xen/xenbus/xenbus_probe_frontend.c
+++ b/drivers/xen/xenbus/xenbus_probe_frontend.c
@@ -21,6 +21,7 @@
 #include <xen/xenbus.h>
 #include <xen/events.h>
 #include <xen/page.h>
+#include <xen/xen.h>
 
 #include <xen/platform_pci.h>
 
diff --git a/include/xen/interface/xen.h b/include/xen/interface/xen.h
index 0054db1..1e0df6b 100644
--- a/include/xen/interface/xen.h
+++ b/include/xen/interface/xen.h
@@ -10,7 +10,6 @@
 #define __XEN_PUBLIC_XEN_H__
 
 #include <asm/xen/interface.h>
-#include <asm/pvclock-abi.h>
 
 /*
  * XEN "SYSTEM CALLS" (a.k.a. HYPERCALLS).
diff --git a/include/xen/privcmd.h b/include/xen/privcmd.h
index 59f1bd8..45c1aa1 100644
--- a/include/xen/privcmd.h
+++ b/include/xen/privcmd.h
@@ -35,6 +35,7 @@
 
 #include <linux/types.h>
 #include <linux/compiler.h>
+#include <xen/interface/xen.h>
 
 struct privcmd_hypercall {
 	__u64 op;
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 14 11:41:21 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 11: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 1TCUGn-0007FC-Iw; Fri, 14 Sep 2012 11:41: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 1TCUGl-0007E5-PM
	for xen-devel@lists.xensource.com; Fri, 14 Sep 2012 11:41:12 +0000
Received: from [85.158.138.51:12347] by server-9.bemta-3.messagelabs.com id
	98/85-15390-7D713505; Fri, 14 Sep 2012 11:41:11 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1347622853!30048854!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNjk2MTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18792 invoked from network); 14 Sep 2012 11:40:59 -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;
	14 Sep 2012 11:40:59 -0000
X-IronPort-AV: E=Sophos;i="4.80,422,1344211200"; d="scan'208";a="37874944"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Sep 2012 11:40:58 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Fri, 14 Sep 2012 07:40: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 1TCTqN-0005wt-NB;
	Fri, 14 Sep 2012 12:13:55 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: <arnd@arndb.de>
Date: Fri, 14 Sep 2012 12:13:24 +0100
Message-ID: <1347621207-11294-22-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <alpine.DEB.2.02.1209141145150.29232@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1209141145150.29232@kaball.uk.xensource.com>
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com, linaro-dev@lists.linaro.org,
	Ian.Campbell@citrix.com, konrad.wilk@oracle.com, catalin.marinas@arm.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	tim@xen.org, linux-kernel@vger.kernel.org,
	linux@arm.linux.org.uk, linux-arm-kernel@lists.infradead.org
Subject: [Xen-devel] [PATCH v4 22/24] xen: missing includes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Note: this patch should be already in Konrad's tree, it is here just for
convenience.

Changes in v3:
- add missing pvclock-abi.h include to ia64 header files.

Changes in v2:
- remove pvclock hack;
- remove include linux/types.h from xen/interface/xen.h.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 arch/ia64/include/asm/xen/interface.h      |    2 ++
 arch/x86/include/asm/xen/interface.h       |    2 ++
 drivers/tty/hvc/hvc_xen.c                  |    2 ++
 drivers/xen/grant-table.c                  |    1 +
 drivers/xen/xenbus/xenbus_probe_frontend.c |    1 +
 include/xen/interface/xen.h                |    1 -
 include/xen/privcmd.h                      |    1 +
 7 files changed, 9 insertions(+), 1 deletions(-)

diff --git a/arch/ia64/include/asm/xen/interface.h b/arch/ia64/include/asm/xen/interface.h
index 7c83445..e88c5de 100644
--- a/arch/ia64/include/asm/xen/interface.h
+++ b/arch/ia64/include/asm/xen/interface.h
@@ -269,6 +269,8 @@ typedef struct xen_callback xen_callback_t;
 
 #endif /* !__ASSEMBLY__ */
 
+#include <asm/pvclock-abi.h>
+
 /* Size of the shared_info area (this is not related to page size).  */
 #define XSI_SHIFT			14
 #define XSI_SIZE			(1 << XSI_SHIFT)
diff --git a/arch/x86/include/asm/xen/interface.h b/arch/x86/include/asm/xen/interface.h
index 25cc8df..28fc621 100644
--- a/arch/x86/include/asm/xen/interface.h
+++ b/arch/x86/include/asm/xen/interface.h
@@ -127,6 +127,8 @@ struct arch_shared_info {
 #include "interface_64.h"
 #endif
 
+#include <asm/pvclock-abi.h>
+
 #ifndef __ASSEMBLY__
 /*
  * The following is all CPU context. Note that the fpu_ctxt block is filled
diff --git a/drivers/tty/hvc/hvc_xen.c b/drivers/tty/hvc/hvc_xen.c
index 1e456dc..2944ff8 100644
--- a/drivers/tty/hvc/hvc_xen.c
+++ b/drivers/tty/hvc/hvc_xen.c
@@ -21,6 +21,7 @@
 #include <linux/console.h>
 #include <linux/delay.h>
 #include <linux/err.h>
+#include <linux/irq.h>
 #include <linux/init.h>
 #include <linux/types.h>
 #include <linux/list.h>
@@ -35,6 +36,7 @@
 #include <xen/page.h>
 #include <xen/events.h>
 #include <xen/interface/io/console.h>
+#include <xen/interface/sched.h>
 #include <xen/hvc-console.h>
 #include <xen/xenbus.h>
 
diff --git a/drivers/xen/grant-table.c b/drivers/xen/grant-table.c
index 0bfc1ef..1d0d95e 100644
--- a/drivers/xen/grant-table.c
+++ b/drivers/xen/grant-table.c
@@ -47,6 +47,7 @@
 #include <xen/interface/memory.h>
 #include <xen/hvc-console.h>
 #include <asm/xen/hypercall.h>
+#include <asm/xen/interface.h>
 
 #include <asm/pgtable.h>
 #include <asm/sync_bitops.h>
diff --git a/drivers/xen/xenbus/xenbus_probe_frontend.c b/drivers/xen/xenbus/xenbus_probe_frontend.c
index a31b54d..3159a37 100644
--- a/drivers/xen/xenbus/xenbus_probe_frontend.c
+++ b/drivers/xen/xenbus/xenbus_probe_frontend.c
@@ -21,6 +21,7 @@
 #include <xen/xenbus.h>
 #include <xen/events.h>
 #include <xen/page.h>
+#include <xen/xen.h>
 
 #include <xen/platform_pci.h>
 
diff --git a/include/xen/interface/xen.h b/include/xen/interface/xen.h
index 0054db1..1e0df6b 100644
--- a/include/xen/interface/xen.h
+++ b/include/xen/interface/xen.h
@@ -10,7 +10,6 @@
 #define __XEN_PUBLIC_XEN_H__
 
 #include <asm/xen/interface.h>
-#include <asm/pvclock-abi.h>
 
 /*
  * XEN "SYSTEM CALLS" (a.k.a. HYPERCALLS).
diff --git a/include/xen/privcmd.h b/include/xen/privcmd.h
index 59f1bd8..45c1aa1 100644
--- a/include/xen/privcmd.h
+++ b/include/xen/privcmd.h
@@ -35,6 +35,7 @@
 
 #include <linux/types.h>
 #include <linux/compiler.h>
+#include <xen/interface/xen.h>
 
 struct privcmd_hypercall {
 	__u64 op;
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 14 11:41:23 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 11:41:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TCUGk-0007EN-5N; Fri, 14 Sep 2012 11:41:10 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1TCUGi-0007E5-TQ
	for xen-devel@lists.xensource.com; Fri, 14 Sep 2012 11:41:09 +0000
Received: from [85.158.137.99:42617] by server-9.bemta-3.messagelabs.com id
	DB/55-15390-4D713505; Fri, 14 Sep 2012 11:41:08 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-14.tower-217.messagelabs.com!1347622865!17648378!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNzQ1Njg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28189 invoked from network); 14 Sep 2012 11:41:06 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-14.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Sep 2012 11:41:06 -0000
X-IronPort-AV: E=Sophos;i="4.80,422,1344211200"; d="scan'208";a="208102944"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Sep 2012 11:41:04 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Fri, 14 Sep 2012 07:41:04 -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 1TCTqN-0005wt-HR;
	Fri, 14 Sep 2012 12:13:55 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: <arnd@arndb.de>
Date: Fri, 14 Sep 2012 12:13:16 +0100
Message-ID: <1347621207-11294-14-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <alpine.DEB.2.02.1209141145150.29232@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1209141145150.29232@kaball.uk.xensource.com>
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com, linaro-dev@lists.linaro.org,
	Ian.Campbell@citrix.com, konrad.wilk@oracle.com, catalin.marinas@arm.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	tim@xen.org, linux-kernel@vger.kernel.org,
	linux@arm.linux.org.uk, linux-arm-kernel@lists.infradead.org
Subject: [Xen-devel] [PATCH v4 14/24] xen/arm: initialize grant_table on ARM
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Initialize the grant table mapping at the address specified at index 0
in the DT under the /xen node.
After the grant table is initialized, call xenbus_probe (if not dom0).

Changes in v2:

- introduce GRANT_TABLE_PHYSADDR;
- remove unneeded initialization of boot_max_nr_grant_frames.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 arch/arm/xen/enlighten.c |   14 ++++++++++++++
 1 files changed, 14 insertions(+), 0 deletions(-)

diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
index c2a47a7..036a4d8 100644
--- a/arch/arm/xen/enlighten.c
+++ b/arch/arm/xen/enlighten.c
@@ -1,8 +1,12 @@
 #include <xen/xen.h>
+#include <xen/grant_table.h>
+#include <xen/hvm.h>
 #include <xen/interface/xen.h>
 #include <xen/interface/memory.h>
+#include <xen/interface/hvm/params.h>
 #include <xen/features.h>
 #include <xen/platform_pci.h>
+#include <xen/xenbus.h>
 #include <asm/xen/hypervisor.h>
 #include <asm/xen/hypercall.h>
 #include <linux/module.h>
@@ -42,6 +46,7 @@ EXPORT_SYMBOL_GPL(xen_remap_domain_mfn_range);
  * see Documentation/devicetree/bindings/arm/xen.txt for the
  * documentation of the Xen Device Tree format.
  */
+#define GRANT_TABLE_PHYSADDR 0
 static int __init xen_guest_init(void)
 {
 	struct xen_add_to_physmap xatp;
@@ -51,6 +56,7 @@ static int __init xen_guest_init(void)
 	const char *s = NULL;
 	const char *version = NULL;
 	const char *xen_prefix = "xen,xen-";
+	struct resource res;
 
 	node = of_find_compatible_node(NULL, NULL, "xen,xen");
 	if (!node) {
@@ -65,6 +71,9 @@ static int __init xen_guest_init(void)
 		pr_debug("Xen version not found\n");
 		return 0;
 	}
+	if (of_address_to_resource(node, GRANT_TABLE_PHYSADDR, &res))
+		return 0;
+	xen_hvm_resume_frames = res.start >> PAGE_SHIFT;
 	xen_domain_type = XEN_HVM_DOMAIN;
 
 	xen_setup_features();
@@ -98,6 +107,11 @@ static int __init xen_guest_init(void)
 	 * is required to use VCPUOP_register_vcpu_info to place vcpu info
 	 * for secondary CPUs as they are brought up. */
 	per_cpu(xen_vcpu, 0) = &HYPERVISOR_shared_info->vcpu_info[0];
+
+	gnttab_init();
+	if (!xen_initial_domain())
+		xenbus_probe(NULL);
+
 	return 0;
 }
 core_initcall(xen_guest_init);
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 14 11:41:23 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 11:41:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TCUGk-0007EN-5N; Fri, 14 Sep 2012 11:41:10 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1TCUGi-0007E5-TQ
	for xen-devel@lists.xensource.com; Fri, 14 Sep 2012 11:41:09 +0000
Received: from [85.158.137.99:42617] by server-9.bemta-3.messagelabs.com id
	DB/55-15390-4D713505; Fri, 14 Sep 2012 11:41:08 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-14.tower-217.messagelabs.com!1347622865!17648378!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNzQ1Njg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28189 invoked from network); 14 Sep 2012 11:41:06 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-14.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Sep 2012 11:41:06 -0000
X-IronPort-AV: E=Sophos;i="4.80,422,1344211200"; d="scan'208";a="208102944"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Sep 2012 11:41:04 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Fri, 14 Sep 2012 07:41:04 -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 1TCTqN-0005wt-HR;
	Fri, 14 Sep 2012 12:13:55 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: <arnd@arndb.de>
Date: Fri, 14 Sep 2012 12:13:16 +0100
Message-ID: <1347621207-11294-14-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <alpine.DEB.2.02.1209141145150.29232@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1209141145150.29232@kaball.uk.xensource.com>
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com, linaro-dev@lists.linaro.org,
	Ian.Campbell@citrix.com, konrad.wilk@oracle.com, catalin.marinas@arm.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	tim@xen.org, linux-kernel@vger.kernel.org,
	linux@arm.linux.org.uk, linux-arm-kernel@lists.infradead.org
Subject: [Xen-devel] [PATCH v4 14/24] xen/arm: initialize grant_table on ARM
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Initialize the grant table mapping at the address specified at index 0
in the DT under the /xen node.
After the grant table is initialized, call xenbus_probe (if not dom0).

Changes in v2:

- introduce GRANT_TABLE_PHYSADDR;
- remove unneeded initialization of boot_max_nr_grant_frames.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 arch/arm/xen/enlighten.c |   14 ++++++++++++++
 1 files changed, 14 insertions(+), 0 deletions(-)

diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
index c2a47a7..036a4d8 100644
--- a/arch/arm/xen/enlighten.c
+++ b/arch/arm/xen/enlighten.c
@@ -1,8 +1,12 @@
 #include <xen/xen.h>
+#include <xen/grant_table.h>
+#include <xen/hvm.h>
 #include <xen/interface/xen.h>
 #include <xen/interface/memory.h>
+#include <xen/interface/hvm/params.h>
 #include <xen/features.h>
 #include <xen/platform_pci.h>
+#include <xen/xenbus.h>
 #include <asm/xen/hypervisor.h>
 #include <asm/xen/hypercall.h>
 #include <linux/module.h>
@@ -42,6 +46,7 @@ EXPORT_SYMBOL_GPL(xen_remap_domain_mfn_range);
  * see Documentation/devicetree/bindings/arm/xen.txt for the
  * documentation of the Xen Device Tree format.
  */
+#define GRANT_TABLE_PHYSADDR 0
 static int __init xen_guest_init(void)
 {
 	struct xen_add_to_physmap xatp;
@@ -51,6 +56,7 @@ static int __init xen_guest_init(void)
 	const char *s = NULL;
 	const char *version = NULL;
 	const char *xen_prefix = "xen,xen-";
+	struct resource res;
 
 	node = of_find_compatible_node(NULL, NULL, "xen,xen");
 	if (!node) {
@@ -65,6 +71,9 @@ static int __init xen_guest_init(void)
 		pr_debug("Xen version not found\n");
 		return 0;
 	}
+	if (of_address_to_resource(node, GRANT_TABLE_PHYSADDR, &res))
+		return 0;
+	xen_hvm_resume_frames = res.start >> PAGE_SHIFT;
 	xen_domain_type = XEN_HVM_DOMAIN;
 
 	xen_setup_features();
@@ -98,6 +107,11 @@ static int __init xen_guest_init(void)
 	 * is required to use VCPUOP_register_vcpu_info to place vcpu info
 	 * for secondary CPUs as they are brought up. */
 	per_cpu(xen_vcpu, 0) = &HYPERVISOR_shared_info->vcpu_info[0];
+
+	gnttab_init();
+	if (!xen_initial_domain())
+		xenbus_probe(NULL);
+
 	return 0;
 }
 core_initcall(xen_guest_init);
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 14 11:41:28 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 11:41:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TCUGw-0007Ip-Of; Fri, 14 Sep 2012 11:41: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 1TCUGu-0007HN-ST
	for xen-devel@lists.xensource.com; Fri, 14 Sep 2012 11:41:21 +0000
Received: from [85.158.143.99:36877] by server-2.bemta-4.messagelabs.com id
	B1/E3-21239-0E713505; Fri, 14 Sep 2012 11:41:20 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1347622878!22825233!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNjk2MTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1155 invoked from network); 14 Sep 2012 11:41:19 -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;
	14 Sep 2012 11:41:19 -0000
X-IronPort-AV: E=Sophos;i="4.80,422,1344211200"; d="scan'208";a="37874972"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Sep 2012 11:41:18 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Fri, 14 Sep 2012 07:41:17 -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 1TCTqN-0005wt-LT;
	Fri, 14 Sep 2012 12:13:55 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: <arnd@arndb.de>
Date: Fri, 14 Sep 2012 12:13:21 +0100
Message-ID: <1347621207-11294-19-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <alpine.DEB.2.02.1209141145150.29232@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1209141145150.29232@kaball.uk.xensource.com>
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com, linaro-dev@lists.linaro.org,
	Ian.Campbell@citrix.com, konrad.wilk@oracle.com, catalin.marinas@arm.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	tim@xen.org, linux-kernel@vger.kernel.org,
	linux@arm.linux.org.uk, linux-arm-kernel@lists.infradead.org
Subject: [Xen-devel] [PATCH v4 19/24] xen/arm: compile blkfront and blkback
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="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>
Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 drivers/block/xen-blkback/blkback.c  |    1 +
 include/xen/interface/io/protocols.h |    3 +++
 2 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/drivers/block/xen-blkback/blkback.c b/drivers/block/xen-blkback/blkback.c
index 73f196c..63dd5b9 100644
--- a/drivers/block/xen-blkback/blkback.c
+++ b/drivers/block/xen-blkback/blkback.c
@@ -42,6 +42,7 @@
 
 #include <xen/events.h>
 #include <xen/page.h>
+#include <xen/xen.h>
 #include <asm/xen/hypervisor.h>
 #include <asm/xen/hypercall.h>
 #include "common.h"
diff --git a/include/xen/interface/io/protocols.h b/include/xen/interface/io/protocols.h
index 01fc8ae..0eafaf2 100644
--- a/include/xen/interface/io/protocols.h
+++ b/include/xen/interface/io/protocols.h
@@ -5,6 +5,7 @@
 #define XEN_IO_PROTO_ABI_X86_64     "x86_64-abi"
 #define XEN_IO_PROTO_ABI_IA64       "ia64-abi"
 #define XEN_IO_PROTO_ABI_POWERPC64  "powerpc64-abi"
+#define XEN_IO_PROTO_ABI_ARM        "arm-abi"
 
 #if defined(__i386__)
 # define XEN_IO_PROTO_ABI_NATIVE XEN_IO_PROTO_ABI_X86_32
@@ -14,6 +15,8 @@
 # define XEN_IO_PROTO_ABI_NATIVE XEN_IO_PROTO_ABI_IA64
 #elif defined(__powerpc64__)
 # define XEN_IO_PROTO_ABI_NATIVE XEN_IO_PROTO_ABI_POWERPC64
+#elif defined(__arm__)
+# define XEN_IO_PROTO_ABI_NATIVE XEN_IO_PROTO_ABI_ARM
 #else
 # error arch fixup needed here
 #endif
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 14 11:41:28 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 11:41:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TCUGw-0007Ip-Of; Fri, 14 Sep 2012 11:41: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 1TCUGu-0007HN-ST
	for xen-devel@lists.xensource.com; Fri, 14 Sep 2012 11:41:21 +0000
Received: from [85.158.143.99:36877] by server-2.bemta-4.messagelabs.com id
	B1/E3-21239-0E713505; Fri, 14 Sep 2012 11:41:20 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1347622878!22825233!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNjk2MTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1155 invoked from network); 14 Sep 2012 11:41:19 -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;
	14 Sep 2012 11:41:19 -0000
X-IronPort-AV: E=Sophos;i="4.80,422,1344211200"; d="scan'208";a="37874972"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Sep 2012 11:41:18 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Fri, 14 Sep 2012 07:41:17 -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 1TCTqN-0005wt-LT;
	Fri, 14 Sep 2012 12:13:55 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: <arnd@arndb.de>
Date: Fri, 14 Sep 2012 12:13:21 +0100
Message-ID: <1347621207-11294-19-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <alpine.DEB.2.02.1209141145150.29232@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1209141145150.29232@kaball.uk.xensource.com>
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com, linaro-dev@lists.linaro.org,
	Ian.Campbell@citrix.com, konrad.wilk@oracle.com, catalin.marinas@arm.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	tim@xen.org, linux-kernel@vger.kernel.org,
	linux@arm.linux.org.uk, linux-arm-kernel@lists.infradead.org
Subject: [Xen-devel] [PATCH v4 19/24] xen/arm: compile blkfront and blkback
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="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>
Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 drivers/block/xen-blkback/blkback.c  |    1 +
 include/xen/interface/io/protocols.h |    3 +++
 2 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/drivers/block/xen-blkback/blkback.c b/drivers/block/xen-blkback/blkback.c
index 73f196c..63dd5b9 100644
--- a/drivers/block/xen-blkback/blkback.c
+++ b/drivers/block/xen-blkback/blkback.c
@@ -42,6 +42,7 @@
 
 #include <xen/events.h>
 #include <xen/page.h>
+#include <xen/xen.h>
 #include <asm/xen/hypervisor.h>
 #include <asm/xen/hypercall.h>
 #include "common.h"
diff --git a/include/xen/interface/io/protocols.h b/include/xen/interface/io/protocols.h
index 01fc8ae..0eafaf2 100644
--- a/include/xen/interface/io/protocols.h
+++ b/include/xen/interface/io/protocols.h
@@ -5,6 +5,7 @@
 #define XEN_IO_PROTO_ABI_X86_64     "x86_64-abi"
 #define XEN_IO_PROTO_ABI_IA64       "ia64-abi"
 #define XEN_IO_PROTO_ABI_POWERPC64  "powerpc64-abi"
+#define XEN_IO_PROTO_ABI_ARM        "arm-abi"
 
 #if defined(__i386__)
 # define XEN_IO_PROTO_ABI_NATIVE XEN_IO_PROTO_ABI_X86_32
@@ -14,6 +15,8 @@
 # define XEN_IO_PROTO_ABI_NATIVE XEN_IO_PROTO_ABI_IA64
 #elif defined(__powerpc64__)
 # define XEN_IO_PROTO_ABI_NATIVE XEN_IO_PROTO_ABI_POWERPC64
+#elif defined(__arm__)
+# define XEN_IO_PROTO_ABI_NATIVE XEN_IO_PROTO_ABI_ARM
 #else
 # error arch fixup needed here
 #endif
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 14 11:41:29 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 11:41: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 1TCUGu-0007HH-As; Fri, 14 Sep 2012 11:41: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 1TCUGt-0007Gd-2Z
	for xen-devel@lists.xensource.com; Fri, 14 Sep 2012 11:41:19 +0000
Received: from [85.158.139.211:13124] by server-4.bemta-5.messagelabs.com id
	20/6C-23042-ED713505; Fri, 14 Sep 2012 11:41:18 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-10.tower-206.messagelabs.com!1347622872!18528854!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNzQ1Njg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17470 invoked from network); 14 Sep 2012 11:41:13 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-10.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Sep 2012 11:41:13 -0000
X-IronPort-AV: E=Sophos;i="4.80,422,1344211200"; d="scan'208";a="208102949"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Sep 2012 11:41:12 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Fri, 14 Sep 2012 07:41:10 -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 1TCTqN-0005wt-Jm;
	Fri, 14 Sep 2012 12:13:55 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: <arnd@arndb.de>
Date: Fri, 14 Sep 2012 12:13:18 +0100
Message-ID: <1347621207-11294-16-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <alpine.DEB.2.02.1209141145150.29232@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1209141145150.29232@kaball.uk.xensource.com>
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com, linaro-dev@lists.linaro.org,
	Ian.Campbell@citrix.com, konrad.wilk@oracle.com, catalin.marinas@arm.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	tim@xen.org, linux-kernel@vger.kernel.org,
	linux@arm.linux.org.uk, linux-arm-kernel@lists.infradead.org
Subject: [Xen-devel] [PATCH v4 16/24] xen: clear IRQ_NOAUTOEN and
	IRQ_NOREQUEST
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Reset the IRQ_NOAUTOEN and IRQ_NOREQUEST flags that are enabled by
default on ARM. If IRQ_NOAUTOEN is set, __setup_irq doesn't call
irq_startup, that is responsible for calling irq_unmask at startup time.
As a result event channels remain masked.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 drivers/xen/events.c |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/drivers/xen/events.c b/drivers/xen/events.c
index 5ecb596..8ffb7b7 100644
--- a/drivers/xen/events.c
+++ b/drivers/xen/events.c
@@ -836,6 +836,7 @@ int bind_evtchn_to_irq(unsigned int evtchn)
 		struct irq_info *info = info_for_irq(irq);
 		WARN_ON(info == NULL || info->type != IRQT_EVTCHN);
 	}
+	irq_clear_status_flags(irq, IRQ_NOREQUEST|IRQ_NOAUTOEN);
 
 out:
 	mutex_unlock(&irq_mapping_update_lock);
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 14 11:41:29 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 11:41: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 1TCUGu-0007HH-As; Fri, 14 Sep 2012 11:41: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 1TCUGt-0007Gd-2Z
	for xen-devel@lists.xensource.com; Fri, 14 Sep 2012 11:41:19 +0000
Received: from [85.158.139.211:13124] by server-4.bemta-5.messagelabs.com id
	20/6C-23042-ED713505; Fri, 14 Sep 2012 11:41:18 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-10.tower-206.messagelabs.com!1347622872!18528854!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNzQ1Njg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17470 invoked from network); 14 Sep 2012 11:41:13 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-10.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Sep 2012 11:41:13 -0000
X-IronPort-AV: E=Sophos;i="4.80,422,1344211200"; d="scan'208";a="208102949"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Sep 2012 11:41:12 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Fri, 14 Sep 2012 07:41:10 -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 1TCTqN-0005wt-Jm;
	Fri, 14 Sep 2012 12:13:55 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: <arnd@arndb.de>
Date: Fri, 14 Sep 2012 12:13:18 +0100
Message-ID: <1347621207-11294-16-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <alpine.DEB.2.02.1209141145150.29232@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1209141145150.29232@kaball.uk.xensource.com>
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com, linaro-dev@lists.linaro.org,
	Ian.Campbell@citrix.com, konrad.wilk@oracle.com, catalin.marinas@arm.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	tim@xen.org, linux-kernel@vger.kernel.org,
	linux@arm.linux.org.uk, linux-arm-kernel@lists.infradead.org
Subject: [Xen-devel] [PATCH v4 16/24] xen: clear IRQ_NOAUTOEN and
	IRQ_NOREQUEST
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Reset the IRQ_NOAUTOEN and IRQ_NOREQUEST flags that are enabled by
default on ARM. If IRQ_NOAUTOEN is set, __setup_irq doesn't call
irq_startup, that is responsible for calling irq_unmask at startup time.
As a result event channels remain masked.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 drivers/xen/events.c |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/drivers/xen/events.c b/drivers/xen/events.c
index 5ecb596..8ffb7b7 100644
--- a/drivers/xen/events.c
+++ b/drivers/xen/events.c
@@ -836,6 +836,7 @@ int bind_evtchn_to_irq(unsigned int evtchn)
 		struct irq_info *info = info_for_irq(irq);
 		WARN_ON(info == NULL || info->type != IRQT_EVTCHN);
 	}
+	irq_clear_status_flags(irq, IRQ_NOREQUEST|IRQ_NOAUTOEN);
 
 out:
 	mutex_unlock(&irq_mapping_update_lock);
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 14 11:41:35 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 11:41: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 1TCUH2-0007MP-BW; Fri, 14 Sep 2012 11:41:28 +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 1TCUH1-0007LI-4D
	for xen-devel@lists.xensource.com; Fri, 14 Sep 2012 11:41:27 +0000
Received: from [85.158.139.211:13975] by server-1.bemta-5.messagelabs.com id
	96/E6-32692-6E713505; Fri, 14 Sep 2012 11:41:26 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-14.tower-206.messagelabs.com!1347622884!18506454!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNzQ1Njg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15920 invoked from network); 14 Sep 2012 11:41:25 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-14.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Sep 2012 11:41:25 -0000
X-IronPort-AV: E=Sophos;i="4.80,422,1344211200"; d="scan'208";a="208102957"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Sep 2012 11:41:24 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Fri, 14 Sep 2012 07:41:23 -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 1TCTqN-0005wt-Nl;
	Fri, 14 Sep 2012 12:13:55 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: <arnd@arndb.de>
Date: Fri, 14 Sep 2012 12:13:25 +0100
Message-ID: <1347621207-11294-23-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <alpine.DEB.2.02.1209141145150.29232@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1209141145150.29232@kaball.uk.xensource.com>
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com, linaro-dev@lists.linaro.org,
	Ian.Campbell@citrix.com, konrad.wilk@oracle.com, catalin.marinas@arm.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	tim@xen.org, linux-kernel@vger.kernel.org,
	linux@arm.linux.org.uk, linux-arm-kernel@lists.infradead.org
Subject: [Xen-devel] [PATCH v4 23/24] xen: update xen_add_to_physmap
	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

Update struct xen_add_to_physmap to be in sync with Xen's version of the
structure.
The size field was introduced by:

changeset:   24164:707d27fe03e7
user:        Jean Guyader <jean.guyader@eu.citrix.com>
date:        Fri Nov 18 13:42:08 2011 +0000
summary:     mm: New XENMEM space, XENMAPSPACE_gmfn_range

According to the comment:

"This new field .size is located in the 16 bits padding between .domid
and .space in struct xen_add_to_physmap to stay compatible with older
versions."

Note: this patch should be already in Konrad's tree, it is here just for
convenience.

Changes in v2:

- remove erroneous comment in the commit message.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 include/xen/interface/memory.h |    3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/include/xen/interface/memory.h b/include/xen/interface/memory.h
index b5c3098..b66d04c 100644
--- a/include/xen/interface/memory.h
+++ b/include/xen/interface/memory.h
@@ -163,6 +163,9 @@ struct xen_add_to_physmap {
     /* Which domain to change the mapping for. */
     domid_t domid;
 
+    /* Number of pages to go through for gmfn_range */
+    uint16_t    size;
+
     /* Source mapping space. */
 #define XENMAPSPACE_shared_info 0 /* shared info page */
 #define XENMAPSPACE_grant_table 1 /* grant table page */
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 14 11:41:35 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 11:41: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 1TCUH2-0007MP-BW; Fri, 14 Sep 2012 11:41:28 +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 1TCUH1-0007LI-4D
	for xen-devel@lists.xensource.com; Fri, 14 Sep 2012 11:41:27 +0000
Received: from [85.158.139.211:13975] by server-1.bemta-5.messagelabs.com id
	96/E6-32692-6E713505; Fri, 14 Sep 2012 11:41:26 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-14.tower-206.messagelabs.com!1347622884!18506454!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNzQ1Njg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15920 invoked from network); 14 Sep 2012 11:41:25 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-14.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Sep 2012 11:41:25 -0000
X-IronPort-AV: E=Sophos;i="4.80,422,1344211200"; d="scan'208";a="208102957"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Sep 2012 11:41:24 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Fri, 14 Sep 2012 07:41:23 -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 1TCTqN-0005wt-Nl;
	Fri, 14 Sep 2012 12:13:55 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: <arnd@arndb.de>
Date: Fri, 14 Sep 2012 12:13:25 +0100
Message-ID: <1347621207-11294-23-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <alpine.DEB.2.02.1209141145150.29232@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1209141145150.29232@kaball.uk.xensource.com>
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com, linaro-dev@lists.linaro.org,
	Ian.Campbell@citrix.com, konrad.wilk@oracle.com, catalin.marinas@arm.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	tim@xen.org, linux-kernel@vger.kernel.org,
	linux@arm.linux.org.uk, linux-arm-kernel@lists.infradead.org
Subject: [Xen-devel] [PATCH v4 23/24] xen: update xen_add_to_physmap
	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

Update struct xen_add_to_physmap to be in sync with Xen's version of the
structure.
The size field was introduced by:

changeset:   24164:707d27fe03e7
user:        Jean Guyader <jean.guyader@eu.citrix.com>
date:        Fri Nov 18 13:42:08 2011 +0000
summary:     mm: New XENMEM space, XENMAPSPACE_gmfn_range

According to the comment:

"This new field .size is located in the 16 bits padding between .domid
and .space in struct xen_add_to_physmap to stay compatible with older
versions."

Note: this patch should be already in Konrad's tree, it is here just for
convenience.

Changes in v2:

- remove erroneous comment in the commit message.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 include/xen/interface/memory.h |    3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/include/xen/interface/memory.h b/include/xen/interface/memory.h
index b5c3098..b66d04c 100644
--- a/include/xen/interface/memory.h
+++ b/include/xen/interface/memory.h
@@ -163,6 +163,9 @@ struct xen_add_to_physmap {
     /* Which domain to change the mapping for. */
     domid_t domid;
 
+    /* Number of pages to go through for gmfn_range */
+    uint16_t    size;
+
     /* Source mapping space. */
 #define XENMAPSPACE_shared_info 0 /* shared info page */
 #define XENMAPSPACE_grant_table 1 /* grant table page */
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 14 11:41:37 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 11:41:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TCUH7-0007QH-Od; Fri, 14 Sep 2012 11:41: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 1TCUH6-0007Oi-2i
	for xen-devel@lists.xensource.com; Fri, 14 Sep 2012 11:41:32 +0000
Received: from [85.158.139.211:39363] by server-3.bemta-5.messagelabs.com id
	8E/80-21836-BE713505; Fri, 14 Sep 2012 11:41:31 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-14.tower-206.messagelabs.com!1347622884!18506454!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNzQ1Njg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16135 invoked from network); 14 Sep 2012 11:41:30 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-14.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Sep 2012 11:41:30 -0000
X-IronPort-AV: E=Sophos;i="4.80,422,1344211200"; d="scan'208";a="208102967"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Sep 2012 11:41:30 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Fri, 14 Sep 2012 07:41:29 -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 1TCTqN-0005wt-Gr;
	Fri, 14 Sep 2012 12:13:55 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: <arnd@arndb.de>
Date: Fri, 14 Sep 2012 12:13:15 +0100
Message-ID: <1347621207-11294-13-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <alpine.DEB.2.02.1209141145150.29232@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1209141145150.29232@kaball.uk.xensource.com>
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com, linaro-dev@lists.linaro.org,
	Ian.Campbell@citrix.com, konrad.wilk@oracle.com, catalin.marinas@arm.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	tim@xen.org, linux-kernel@vger.kernel.org,
	linux@arm.linux.org.uk, linux-arm-kernel@lists.infradead.org
Subject: [Xen-devel] [PATCH v4 13/24] 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.

XENFEAT_dom0 was introduced by 23735 in xen-unstable.hg.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 arch/arm/xen/enlighten.c         |    7 +++++++
 include/xen/interface/features.h |    3 +++
 2 files changed, 10 insertions(+), 0 deletions(-)

diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
index 6a0217d..c2a47a7 100644
--- a/arch/arm/xen/enlighten.c
+++ b/arch/arm/xen/enlighten.c
@@ -1,6 +1,7 @@
 #include <xen/xen.h>
 #include <xen/interface/xen.h>
 #include <xen/interface/memory.h>
+#include <xen/features.h>
 #include <xen/platform_pci.h>
 #include <asm/xen/hypervisor.h>
 #include <asm/xen/hypercall.h>
@@ -66,6 +67,12 @@ static int __init xen_guest_init(void)
 	}
 	xen_domain_type = XEN_HVM_DOMAIN;
 
+	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);
+
 	if (!shared_info_page)
 		shared_info_page = (struct shared_info *)
 			get_zeroed_page(GFP_KERNEL);
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 Sep 14 11:41:37 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 11:41:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TCUH7-0007QH-Od; Fri, 14 Sep 2012 11:41: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 1TCUH6-0007Oi-2i
	for xen-devel@lists.xensource.com; Fri, 14 Sep 2012 11:41:32 +0000
Received: from [85.158.139.211:39363] by server-3.bemta-5.messagelabs.com id
	8E/80-21836-BE713505; Fri, 14 Sep 2012 11:41:31 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-14.tower-206.messagelabs.com!1347622884!18506454!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNzQ1Njg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16135 invoked from network); 14 Sep 2012 11:41:30 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-14.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Sep 2012 11:41:30 -0000
X-IronPort-AV: E=Sophos;i="4.80,422,1344211200"; d="scan'208";a="208102967"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Sep 2012 11:41:30 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Fri, 14 Sep 2012 07:41:29 -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 1TCTqN-0005wt-Gr;
	Fri, 14 Sep 2012 12:13:55 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: <arnd@arndb.de>
Date: Fri, 14 Sep 2012 12:13:15 +0100
Message-ID: <1347621207-11294-13-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <alpine.DEB.2.02.1209141145150.29232@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1209141145150.29232@kaball.uk.xensource.com>
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com, linaro-dev@lists.linaro.org,
	Ian.Campbell@citrix.com, konrad.wilk@oracle.com, catalin.marinas@arm.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	tim@xen.org, linux-kernel@vger.kernel.org,
	linux@arm.linux.org.uk, linux-arm-kernel@lists.infradead.org
Subject: [Xen-devel] [PATCH v4 13/24] 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.

XENFEAT_dom0 was introduced by 23735 in xen-unstable.hg.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 arch/arm/xen/enlighten.c         |    7 +++++++
 include/xen/interface/features.h |    3 +++
 2 files changed, 10 insertions(+), 0 deletions(-)

diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
index 6a0217d..c2a47a7 100644
--- a/arch/arm/xen/enlighten.c
+++ b/arch/arm/xen/enlighten.c
@@ -1,6 +1,7 @@
 #include <xen/xen.h>
 #include <xen/interface/xen.h>
 #include <xen/interface/memory.h>
+#include <xen/features.h>
 #include <xen/platform_pci.h>
 #include <asm/xen/hypervisor.h>
 #include <asm/xen/hypercall.h>
@@ -66,6 +67,12 @@ static int __init xen_guest_init(void)
 	}
 	xen_domain_type = XEN_HVM_DOMAIN;
 
+	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);
+
 	if (!shared_info_page)
 		shared_info_page = (struct shared_info *)
 			get_zeroed_page(GFP_KERNEL);
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 Sep 14 11:41:49 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 11:41:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TCUHK-0007YL-K4; Fri, 14 Sep 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 1TCUHJ-0007X4-2R
	for xen-devel@lists.xensource.com; Fri, 14 Sep 2012 11:41:45 +0000
Received: from [85.158.139.211:40426] by server-12.bemta-5.messagelabs.com id
	DE/E9-19338-8F713505; Fri, 14 Sep 2012 11:41:44 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-14.tower-206.messagelabs.com!1347622902!18506507!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNzQ1Njg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16922 invoked from network); 14 Sep 2012 11:41:43 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-14.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Sep 2012 11:41:43 -0000
X-IronPort-AV: E=Sophos;i="4.80,422,1344211200"; d="scan'208";a="208102975"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Sep 2012 11:41:42 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Fri, 14 Sep 2012 07:41:41 -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 1TCTqN-0005wt-KM;
	Fri, 14 Sep 2012 12:13:55 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: <arnd@arndb.de>
Date: Fri, 14 Sep 2012 12:13:19 +0100
Message-ID: <1347621207-11294-17-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <alpine.DEB.2.02.1209141145150.29232@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1209141145150.29232@kaball.uk.xensource.com>
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com, linaro-dev@lists.linaro.org,
	Ian.Campbell@citrix.com, konrad.wilk@oracle.com, catalin.marinas@arm.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	tim@xen.org, linux-kernel@vger.kernel.org,
	linux@arm.linux.org.uk, linux-arm-kernel@lists.infradead.org
Subject: [Xen-devel] [PATCH v4 17/24] xen/arm: implement
	alloc/free_xenballooned_pages with alloc_pages/kfree
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Only until we get the balloon driver to work.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 arch/arm/xen/enlighten.c |   18 ++++++++++++++++++
 1 files changed, 18 insertions(+), 0 deletions(-)

diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
index bad67ad..59bcb96 100644
--- a/arch/arm/xen/enlighten.c
+++ b/arch/arm/xen/enlighten.c
@@ -148,3 +148,21 @@ static int __init xen_init_events(void)
 	return 0;
 }
 postcore_initcall(xen_init_events);
+
+/* XXX: only until balloon is properly working */
+int alloc_xenballooned_pages(int nr_pages, struct page **pages, bool highmem)
+{
+	*pages = alloc_pages(highmem ? GFP_HIGHUSER : GFP_KERNEL,
+			get_order(nr_pages));
+	if (*pages == NULL)
+		return -ENOMEM;
+	return 0;
+}
+EXPORT_SYMBOL_GPL(alloc_xenballooned_pages);
+
+void free_xenballooned_pages(int nr_pages, struct page **pages)
+{
+	kfree(*pages);
+	*pages = NULL;
+}
+EXPORT_SYMBOL_GPL(free_xenballooned_pages);
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 14 11:41:49 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 11:41:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TCUHK-0007YL-K4; Fri, 14 Sep 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 1TCUHJ-0007X4-2R
	for xen-devel@lists.xensource.com; Fri, 14 Sep 2012 11:41:45 +0000
Received: from [85.158.139.211:40426] by server-12.bemta-5.messagelabs.com id
	DE/E9-19338-8F713505; Fri, 14 Sep 2012 11:41:44 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-14.tower-206.messagelabs.com!1347622902!18506507!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNzQ1Njg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16922 invoked from network); 14 Sep 2012 11:41:43 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-14.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Sep 2012 11:41:43 -0000
X-IronPort-AV: E=Sophos;i="4.80,422,1344211200"; d="scan'208";a="208102975"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Sep 2012 11:41:42 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Fri, 14 Sep 2012 07:41:41 -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 1TCTqN-0005wt-KM;
	Fri, 14 Sep 2012 12:13:55 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: <arnd@arndb.de>
Date: Fri, 14 Sep 2012 12:13:19 +0100
Message-ID: <1347621207-11294-17-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <alpine.DEB.2.02.1209141145150.29232@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1209141145150.29232@kaball.uk.xensource.com>
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com, linaro-dev@lists.linaro.org,
	Ian.Campbell@citrix.com, konrad.wilk@oracle.com, catalin.marinas@arm.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	tim@xen.org, linux-kernel@vger.kernel.org,
	linux@arm.linux.org.uk, linux-arm-kernel@lists.infradead.org
Subject: [Xen-devel] [PATCH v4 17/24] xen/arm: implement
	alloc/free_xenballooned_pages with alloc_pages/kfree
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Only until we get the balloon driver to work.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 arch/arm/xen/enlighten.c |   18 ++++++++++++++++++
 1 files changed, 18 insertions(+), 0 deletions(-)

diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
index bad67ad..59bcb96 100644
--- a/arch/arm/xen/enlighten.c
+++ b/arch/arm/xen/enlighten.c
@@ -148,3 +148,21 @@ static int __init xen_init_events(void)
 	return 0;
 }
 postcore_initcall(xen_init_events);
+
+/* XXX: only until balloon is properly working */
+int alloc_xenballooned_pages(int nr_pages, struct page **pages, bool highmem)
+{
+	*pages = alloc_pages(highmem ? GFP_HIGHUSER : GFP_KERNEL,
+			get_order(nr_pages));
+	if (*pages == NULL)
+		return -ENOMEM;
+	return 0;
+}
+EXPORT_SYMBOL_GPL(alloc_xenballooned_pages);
+
+void free_xenballooned_pages(int nr_pages, struct page **pages)
+{
+	kfree(*pages);
+	*pages = NULL;
+}
+EXPORT_SYMBOL_GPL(free_xenballooned_pages);
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 14 11:41:49 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 11:41:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TCUHG-0007Vi-6y; Fri, 14 Sep 2012 11:41:42 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1TCUHD-0007Tn-N9
	for xen-devel@lists.xensource.com; Fri, 14 Sep 2012 11:41:40 +0000
Received: from [85.158.137.99:50721] by server-3.bemta-3.messagelabs.com id
	44/6B-21322-2F713505; Fri, 14 Sep 2012 11:41:38 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-13.tower-217.messagelabs.com!1347622896!17689735!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNjk2MTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9741 invoked from network); 14 Sep 2012 11:41:37 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-13.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Sep 2012 11:41:37 -0000
X-IronPort-AV: E=Sophos;i="4.80,422,1344211200"; d="scan'208";a="37874992"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Sep 2012 11:41:36 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Fri, 14 Sep 2012 07:41:35 -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 1TCTqN-0005wt-JC;
	Fri, 14 Sep 2012 12:13:55 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: <arnd@arndb.de>
Date: Fri, 14 Sep 2012 12:13:17 +0100
Message-ID: <1347621207-11294-15-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <alpine.DEB.2.02.1209141145150.29232@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1209141145150.29232@kaball.uk.xensource.com>
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com, linaro-dev@lists.linaro.org,
	Ian.Campbell@citrix.com, konrad.wilk@oracle.com, catalin.marinas@arm.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	tim@xen.org, linux-kernel@vger.kernel.org,
	linux@arm.linux.org.uk, linux-arm-kernel@lists.infradead.org
Subject: [Xen-devel] [PATCH v4 15/24] xen/arm: receive Xen events on ARM
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Compile events.c on ARM.
Parse, map and enable the IRQ to get event notifications from the device
tree (node "/xen").

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 arch/arm/include/asm/xen/events.h |   18 ++++++++++++++++++
 arch/arm/xen/enlighten.c          |   33 +++++++++++++++++++++++++++++++++
 arch/x86/xen/enlighten.c          |    1 +
 arch/x86/xen/irq.c                |    1 +
 arch/x86/xen/xen-ops.h            |    1 -
 drivers/xen/events.c              |   17 ++++++++++++++---
 include/xen/events.h              |    2 ++
 7 files changed, 69 insertions(+), 4 deletions(-)
 create mode 100644 arch/arm/include/asm/xen/events.h

diff --git a/arch/arm/include/asm/xen/events.h b/arch/arm/include/asm/xen/events.h
new file mode 100644
index 0000000..94b4e90
--- /dev/null
+++ b/arch/arm/include/asm/xen/events.h
@@ -0,0 +1,18 @@
+#ifndef _ASM_ARM_XEN_EVENTS_H
+#define _ASM_ARM_XEN_EVENTS_H
+
+#include <asm/ptrace.h>
+
+enum ipi_vector {
+	XEN_PLACEHOLDER_VECTOR,
+
+	/* Xen IPIs go here */
+	XEN_NR_IPIS,
+};
+
+static inline int xen_irqs_disabled(struct pt_regs *regs)
+{
+	return raw_irqs_disabled_flags(regs->ARM_cpsr);
+}
+
+#endif /* _ASM_ARM_XEN_EVENTS_H */
diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
index 036a4d8..bad67ad 100644
--- a/arch/arm/xen/enlighten.c
+++ b/arch/arm/xen/enlighten.c
@@ -1,4 +1,5 @@
 #include <xen/xen.h>
+#include <xen/events.h>
 #include <xen/grant_table.h>
 #include <xen/hvm.h>
 #include <xen/interface/xen.h>
@@ -9,6 +10,8 @@
 #include <xen/xenbus.h>
 #include <asm/xen/hypervisor.h>
 #include <asm/xen/hypercall.h>
+#include <linux/interrupt.h>
+#include <linux/irqreturn.h>
 #include <linux/module.h>
 #include <linux/of.h>
 #include <linux/of_irq.h>
@@ -33,6 +36,8 @@ EXPORT_SYMBOL_GPL(xen_have_vector_callback);
 int xen_platform_pci_unplug = XEN_UNPLUG_ALL;
 EXPORT_SYMBOL_GPL(xen_platform_pci_unplug);
 
+static __read_mostly int xen_events_irq = -1;
+
 int xen_remap_domain_mfn_range(struct vm_area_struct *vma,
 			       unsigned long addr,
 			       unsigned long mfn, int nr,
@@ -74,6 +79,9 @@ static int __init xen_guest_init(void)
 	if (of_address_to_resource(node, GRANT_TABLE_PHYSADDR, &res))
 		return 0;
 	xen_hvm_resume_frames = res.start >> PAGE_SHIFT;
+	xen_events_irq = irq_of_parse_and_map(node, 0);
+	pr_info("Xen %s support found, events_irq=%d gnttab_frame_pfn=%lx\n",
+			version, xen_events_irq, xen_hvm_resume_frames);
 	xen_domain_type = XEN_HVM_DOMAIN;
 
 	xen_setup_features();
@@ -115,3 +123,28 @@ static int __init xen_guest_init(void)
 	return 0;
 }
 core_initcall(xen_guest_init);
+
+static irqreturn_t xen_arm_callback(int irq, void *arg)
+{
+	xen_hvm_evtchn_do_upcall();
+	return IRQ_HANDLED;
+}
+
+static int __init xen_init_events(void)
+{
+	if (!xen_domain() || xen_events_irq < 0)
+		return -ENODEV;
+
+	xen_init_IRQ();
+
+	if (request_percpu_irq(xen_events_irq, xen_arm_callback,
+			"events", xen_vcpu)) {
+		pr_err("Error requesting IRQ %d\n", xen_events_irq);
+		return -EINVAL;
+	}
+
+	enable_percpu_irq(xen_events_irq, 0);
+
+	return 0;
+}
+postcore_initcall(xen_init_events);
diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
index 9642d4a..3f8263e 100644
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -33,6 +33,7 @@
 #include <linux/memblock.h>
 
 #include <xen/xen.h>
+#include <xen/events.h>
 #include <xen/interface/xen.h>
 #include <xen/interface/version.h>
 #include <xen/interface/physdev.h>
diff --git a/arch/x86/xen/irq.c b/arch/x86/xen/irq.c
index 1573376..01a4dc0 100644
--- a/arch/x86/xen/irq.c
+++ b/arch/x86/xen/irq.c
@@ -5,6 +5,7 @@
 #include <xen/interface/xen.h>
 #include <xen/interface/sched.h>
 #include <xen/interface/vcpu.h>
+#include <xen/events.h>
 
 #include <asm/xen/hypercall.h>
 #include <asm/xen/hypervisor.h>
diff --git a/arch/x86/xen/xen-ops.h b/arch/x86/xen/xen-ops.h
index 202d4c1..2368295 100644
--- a/arch/x86/xen/xen-ops.h
+++ b/arch/x86/xen/xen-ops.h
@@ -35,7 +35,6 @@ void xen_set_pat(u64);
 
 char * __init xen_memory_setup(void);
 void __init xen_arch_setup(void);
-void __init xen_init_IRQ(void);
 void xen_enable_sysenter(void);
 void xen_enable_syscall(void);
 void xen_vcpu_restore(void);
diff --git a/drivers/xen/events.c b/drivers/xen/events.c
index 7595581..5ecb596 100644
--- a/drivers/xen/events.c
+++ b/drivers/xen/events.c
@@ -31,14 +31,16 @@
 #include <linux/irqnr.h>
 #include <linux/pci.h>
 
+#ifdef CONFIG_X86
 #include <asm/desc.h>
 #include <asm/ptrace.h>
 #include <asm/irq.h>
 #include <asm/idle.h>
 #include <asm/io_apic.h>
-#include <asm/sync_bitops.h>
 #include <asm/xen/page.h>
 #include <asm/xen/pci.h>
+#endif
+#include <asm/sync_bitops.h>
 #include <asm/xen/hypercall.h>
 #include <asm/xen/hypervisor.h>
 
@@ -50,6 +52,9 @@
 #include <xen/interface/event_channel.h>
 #include <xen/interface/hvm/hvm_op.h>
 #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
@@ -1374,7 +1379,9 @@ void xen_evtchn_do_upcall(struct pt_regs *regs)
 {
 	struct pt_regs *old_regs = set_irq_regs(regs);
 
+#ifdef CONFIG_X86
 	exit_idle();
+#endif
 	irq_enter();
 
 	__xen_evtchn_do_upcall();
@@ -1783,9 +1790,9 @@ void xen_callback_vector(void)
 void xen_callback_vector(void) {}
 #endif
 
-void __init xen_init_IRQ(void)
+void xen_init_IRQ(void)
 {
-	int i, rc;
+	int i;
 
 	evtchn_to_irq = kcalloc(NR_EVENT_CHANNELS, sizeof(*evtchn_to_irq),
 				    GFP_KERNEL);
@@ -1801,6 +1808,7 @@ void __init xen_init_IRQ(void)
 
 	pirq_needs_eoi = pirq_needs_eoi_flag;
 
+#ifdef CONFIG_X86
 	if (xen_hvm_domain()) {
 		xen_callback_vector();
 		native_init_IRQ();
@@ -1808,6 +1816,7 @@ void __init xen_init_IRQ(void)
 		 * __acpi_register_gsi can point at the right function */
 		pci_xen_hvm_init();
 	} else {
+		int rc;
 		struct physdev_pirq_eoi_gmfn eoi_gmfn;
 
 		irq_ctx_init(smp_processor_id());
@@ -1823,4 +1832,6 @@ void __init xen_init_IRQ(void)
 		} else
 			pirq_needs_eoi = pirq_check_eoi_map;
 	}
+#endif
 }
+EXPORT_SYMBOL_GPL(xen_init_IRQ);
diff --git a/include/xen/events.h b/include/xen/events.h
index 04399b2..c6bfe01 100644
--- a/include/xen/events.h
+++ b/include/xen/events.h
@@ -109,4 +109,6 @@ int xen_irq_from_gsi(unsigned gsi);
 /* Determine whether to ignore this IRQ if it is passed to a guest. */
 int xen_test_irq_shared(int irq);
 
+/* initialize Xen IRQ subsystem */
+void xen_init_IRQ(void);
 #endif	/* _XEN_EVENTS_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 Sep 14 11:41:49 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 11:41:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TCUHG-0007Vi-6y; Fri, 14 Sep 2012 11:41:42 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1TCUHD-0007Tn-N9
	for xen-devel@lists.xensource.com; Fri, 14 Sep 2012 11:41:40 +0000
Received: from [85.158.137.99:50721] by server-3.bemta-3.messagelabs.com id
	44/6B-21322-2F713505; Fri, 14 Sep 2012 11:41:38 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-13.tower-217.messagelabs.com!1347622896!17689735!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNjk2MTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9741 invoked from network); 14 Sep 2012 11:41:37 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-13.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Sep 2012 11:41:37 -0000
X-IronPort-AV: E=Sophos;i="4.80,422,1344211200"; d="scan'208";a="37874992"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Sep 2012 11:41:36 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Fri, 14 Sep 2012 07:41:35 -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 1TCTqN-0005wt-JC;
	Fri, 14 Sep 2012 12:13:55 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: <arnd@arndb.de>
Date: Fri, 14 Sep 2012 12:13:17 +0100
Message-ID: <1347621207-11294-15-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <alpine.DEB.2.02.1209141145150.29232@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1209141145150.29232@kaball.uk.xensource.com>
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com, linaro-dev@lists.linaro.org,
	Ian.Campbell@citrix.com, konrad.wilk@oracle.com, catalin.marinas@arm.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	tim@xen.org, linux-kernel@vger.kernel.org,
	linux@arm.linux.org.uk, linux-arm-kernel@lists.infradead.org
Subject: [Xen-devel] [PATCH v4 15/24] xen/arm: receive Xen events on ARM
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Compile events.c on ARM.
Parse, map and enable the IRQ to get event notifications from the device
tree (node "/xen").

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 arch/arm/include/asm/xen/events.h |   18 ++++++++++++++++++
 arch/arm/xen/enlighten.c          |   33 +++++++++++++++++++++++++++++++++
 arch/x86/xen/enlighten.c          |    1 +
 arch/x86/xen/irq.c                |    1 +
 arch/x86/xen/xen-ops.h            |    1 -
 drivers/xen/events.c              |   17 ++++++++++++++---
 include/xen/events.h              |    2 ++
 7 files changed, 69 insertions(+), 4 deletions(-)
 create mode 100644 arch/arm/include/asm/xen/events.h

diff --git a/arch/arm/include/asm/xen/events.h b/arch/arm/include/asm/xen/events.h
new file mode 100644
index 0000000..94b4e90
--- /dev/null
+++ b/arch/arm/include/asm/xen/events.h
@@ -0,0 +1,18 @@
+#ifndef _ASM_ARM_XEN_EVENTS_H
+#define _ASM_ARM_XEN_EVENTS_H
+
+#include <asm/ptrace.h>
+
+enum ipi_vector {
+	XEN_PLACEHOLDER_VECTOR,
+
+	/* Xen IPIs go here */
+	XEN_NR_IPIS,
+};
+
+static inline int xen_irqs_disabled(struct pt_regs *regs)
+{
+	return raw_irqs_disabled_flags(regs->ARM_cpsr);
+}
+
+#endif /* _ASM_ARM_XEN_EVENTS_H */
diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
index 036a4d8..bad67ad 100644
--- a/arch/arm/xen/enlighten.c
+++ b/arch/arm/xen/enlighten.c
@@ -1,4 +1,5 @@
 #include <xen/xen.h>
+#include <xen/events.h>
 #include <xen/grant_table.h>
 #include <xen/hvm.h>
 #include <xen/interface/xen.h>
@@ -9,6 +10,8 @@
 #include <xen/xenbus.h>
 #include <asm/xen/hypervisor.h>
 #include <asm/xen/hypercall.h>
+#include <linux/interrupt.h>
+#include <linux/irqreturn.h>
 #include <linux/module.h>
 #include <linux/of.h>
 #include <linux/of_irq.h>
@@ -33,6 +36,8 @@ EXPORT_SYMBOL_GPL(xen_have_vector_callback);
 int xen_platform_pci_unplug = XEN_UNPLUG_ALL;
 EXPORT_SYMBOL_GPL(xen_platform_pci_unplug);
 
+static __read_mostly int xen_events_irq = -1;
+
 int xen_remap_domain_mfn_range(struct vm_area_struct *vma,
 			       unsigned long addr,
 			       unsigned long mfn, int nr,
@@ -74,6 +79,9 @@ static int __init xen_guest_init(void)
 	if (of_address_to_resource(node, GRANT_TABLE_PHYSADDR, &res))
 		return 0;
 	xen_hvm_resume_frames = res.start >> PAGE_SHIFT;
+	xen_events_irq = irq_of_parse_and_map(node, 0);
+	pr_info("Xen %s support found, events_irq=%d gnttab_frame_pfn=%lx\n",
+			version, xen_events_irq, xen_hvm_resume_frames);
 	xen_domain_type = XEN_HVM_DOMAIN;
 
 	xen_setup_features();
@@ -115,3 +123,28 @@ static int __init xen_guest_init(void)
 	return 0;
 }
 core_initcall(xen_guest_init);
+
+static irqreturn_t xen_arm_callback(int irq, void *arg)
+{
+	xen_hvm_evtchn_do_upcall();
+	return IRQ_HANDLED;
+}
+
+static int __init xen_init_events(void)
+{
+	if (!xen_domain() || xen_events_irq < 0)
+		return -ENODEV;
+
+	xen_init_IRQ();
+
+	if (request_percpu_irq(xen_events_irq, xen_arm_callback,
+			"events", xen_vcpu)) {
+		pr_err("Error requesting IRQ %d\n", xen_events_irq);
+		return -EINVAL;
+	}
+
+	enable_percpu_irq(xen_events_irq, 0);
+
+	return 0;
+}
+postcore_initcall(xen_init_events);
diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
index 9642d4a..3f8263e 100644
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -33,6 +33,7 @@
 #include <linux/memblock.h>
 
 #include <xen/xen.h>
+#include <xen/events.h>
 #include <xen/interface/xen.h>
 #include <xen/interface/version.h>
 #include <xen/interface/physdev.h>
diff --git a/arch/x86/xen/irq.c b/arch/x86/xen/irq.c
index 1573376..01a4dc0 100644
--- a/arch/x86/xen/irq.c
+++ b/arch/x86/xen/irq.c
@@ -5,6 +5,7 @@
 #include <xen/interface/xen.h>
 #include <xen/interface/sched.h>
 #include <xen/interface/vcpu.h>
+#include <xen/events.h>
 
 #include <asm/xen/hypercall.h>
 #include <asm/xen/hypervisor.h>
diff --git a/arch/x86/xen/xen-ops.h b/arch/x86/xen/xen-ops.h
index 202d4c1..2368295 100644
--- a/arch/x86/xen/xen-ops.h
+++ b/arch/x86/xen/xen-ops.h
@@ -35,7 +35,6 @@ void xen_set_pat(u64);
 
 char * __init xen_memory_setup(void);
 void __init xen_arch_setup(void);
-void __init xen_init_IRQ(void);
 void xen_enable_sysenter(void);
 void xen_enable_syscall(void);
 void xen_vcpu_restore(void);
diff --git a/drivers/xen/events.c b/drivers/xen/events.c
index 7595581..5ecb596 100644
--- a/drivers/xen/events.c
+++ b/drivers/xen/events.c
@@ -31,14 +31,16 @@
 #include <linux/irqnr.h>
 #include <linux/pci.h>
 
+#ifdef CONFIG_X86
 #include <asm/desc.h>
 #include <asm/ptrace.h>
 #include <asm/irq.h>
 #include <asm/idle.h>
 #include <asm/io_apic.h>
-#include <asm/sync_bitops.h>
 #include <asm/xen/page.h>
 #include <asm/xen/pci.h>
+#endif
+#include <asm/sync_bitops.h>
 #include <asm/xen/hypercall.h>
 #include <asm/xen/hypervisor.h>
 
@@ -50,6 +52,9 @@
 #include <xen/interface/event_channel.h>
 #include <xen/interface/hvm/hvm_op.h>
 #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
@@ -1374,7 +1379,9 @@ void xen_evtchn_do_upcall(struct pt_regs *regs)
 {
 	struct pt_regs *old_regs = set_irq_regs(regs);
 
+#ifdef CONFIG_X86
 	exit_idle();
+#endif
 	irq_enter();
 
 	__xen_evtchn_do_upcall();
@@ -1783,9 +1790,9 @@ void xen_callback_vector(void)
 void xen_callback_vector(void) {}
 #endif
 
-void __init xen_init_IRQ(void)
+void xen_init_IRQ(void)
 {
-	int i, rc;
+	int i;
 
 	evtchn_to_irq = kcalloc(NR_EVENT_CHANNELS, sizeof(*evtchn_to_irq),
 				    GFP_KERNEL);
@@ -1801,6 +1808,7 @@ void __init xen_init_IRQ(void)
 
 	pirq_needs_eoi = pirq_needs_eoi_flag;
 
+#ifdef CONFIG_X86
 	if (xen_hvm_domain()) {
 		xen_callback_vector();
 		native_init_IRQ();
@@ -1808,6 +1816,7 @@ void __init xen_init_IRQ(void)
 		 * __acpi_register_gsi can point at the right function */
 		pci_xen_hvm_init();
 	} else {
+		int rc;
 		struct physdev_pirq_eoi_gmfn eoi_gmfn;
 
 		irq_ctx_init(smp_processor_id());
@@ -1823,4 +1832,6 @@ void __init xen_init_IRQ(void)
 		} else
 			pirq_needs_eoi = pirq_check_eoi_map;
 	}
+#endif
 }
+EXPORT_SYMBOL_GPL(xen_init_IRQ);
diff --git a/include/xen/events.h b/include/xen/events.h
index 04399b2..c6bfe01 100644
--- a/include/xen/events.h
+++ b/include/xen/events.h
@@ -109,4 +109,6 @@ int xen_irq_from_gsi(unsigned gsi);
 /* Determine whether to ignore this IRQ if it is passed to a guest. */
 int xen_test_irq_shared(int irq);
 
+/* initialize Xen IRQ subsystem */
+void xen_init_IRQ(void);
 #endif	/* _XEN_EVENTS_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 Sep 14 11:41:52 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 11: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 1TCUHP-0007c5-03; Fri, 14 Sep 2012 11:41:51 +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 1TCUHN-0007aH-VH
	for xen-devel@lists.xensource.com; Fri, 14 Sep 2012 11:41:50 +0000
Received: from [85.158.139.211:15624] by server-3.bemta-5.messagelabs.com id
	AC/11-21836-DF713505; Fri, 14 Sep 2012 11:41:49 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-14.tower-206.messagelabs.com!1347622902!18506507!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNzQ1Njg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17076 invoked from network); 14 Sep 2012 11:41:48 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-14.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Sep 2012 11:41:48 -0000
X-IronPort-AV: E=Sophos;i="4.80,422,1344211200"; d="scan'208";a="208102978"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Sep 2012 11:41:48 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Fri, 14 Sep 2012 07:41:47 -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 1TCTqN-0005wt-Md;
	Fri, 14 Sep 2012 12:13:55 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: <arnd@arndb.de>
Date: Fri, 14 Sep 2012 12:13:23 +0100
Message-ID: <1347621207-11294-21-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <alpine.DEB.2.02.1209141145150.29232@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1209141145150.29232@kaball.uk.xensource.com>
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com, linaro-dev@lists.linaro.org,
	Ian.Campbell@citrix.com, Pawel Moll <pawel.moll@arm.com>,
	konrad.wilk@oracle.com, Marc Zyngier <marc.zyngier@arm.com>,
	catalin.marinas@arm.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	tim@xen.org, linux-kernel@vger.kernel.org,
	linux@arm.linux.org.uk, linux-arm-kernel@lists.infradead.org
Subject: [Xen-devel] [PATCH v4 21/24] arm/v2m: initialize arch_timers even
	if v2m_timer is not present
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="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>
CC: Russell King <linux@arm.linux.org.uk>
CC: Pawel Moll <pawel.moll@arm.com>
CC: Marc Zyngier <marc.zyngier@arm.com>
---
 arch/arm/mach-vexpress/v2m.c |   11 ++++++-----
 1 files changed, 6 insertions(+), 5 deletions(-)

diff --git a/arch/arm/mach-vexpress/v2m.c b/arch/arm/mach-vexpress/v2m.c
index 37608f2..4e567f7 100644
--- a/arch/arm/mach-vexpress/v2m.c
+++ b/arch/arm/mach-vexpress/v2m.c
@@ -621,16 +621,17 @@ static void __init v2m_dt_timer_init(void)
 
 	v2m_clk_init();
 
-	err = of_property_read_string(of_aliases, "arm,v2m_timer", &path);
-	if (WARN_ON(err))
-		return;
-	node = of_find_node_by_path(path);
-	v2m_sp804_init(of_iomap(node, 0), irq_of_parse_and_map(node, 0));
 	if (arch_timer_of_register() != 0)
 		twd_local_timer_of_register();
 
 	if (arch_timer_sched_clock_init() != 0)
 		versatile_sched_clock_init(v2m_sysreg_base + V2M_SYS_24MHZ, 24000000);
+
+	err = of_property_read_string(of_aliases, "arm,v2m_timer", &path);
+	if (WARN_ON(err))
+		return;
+	node = of_find_node_by_path(path);
+	v2m_sp804_init(of_iomap(node, 0), irq_of_parse_and_map(node, 0));
 }
 
 static struct sys_timer v2m_dt_timer = {
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 14 11:41:52 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 11: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 1TCUHP-0007c5-03; Fri, 14 Sep 2012 11:41:51 +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 1TCUHN-0007aH-VH
	for xen-devel@lists.xensource.com; Fri, 14 Sep 2012 11:41:50 +0000
Received: from [85.158.139.211:15624] by server-3.bemta-5.messagelabs.com id
	AC/11-21836-DF713505; Fri, 14 Sep 2012 11:41:49 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-14.tower-206.messagelabs.com!1347622902!18506507!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNzQ1Njg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17076 invoked from network); 14 Sep 2012 11:41:48 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-14.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Sep 2012 11:41:48 -0000
X-IronPort-AV: E=Sophos;i="4.80,422,1344211200"; d="scan'208";a="208102978"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Sep 2012 11:41:48 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Fri, 14 Sep 2012 07:41:47 -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 1TCTqN-0005wt-Md;
	Fri, 14 Sep 2012 12:13:55 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: <arnd@arndb.de>
Date: Fri, 14 Sep 2012 12:13:23 +0100
Message-ID: <1347621207-11294-21-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <alpine.DEB.2.02.1209141145150.29232@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1209141145150.29232@kaball.uk.xensource.com>
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com, linaro-dev@lists.linaro.org,
	Ian.Campbell@citrix.com, Pawel Moll <pawel.moll@arm.com>,
	konrad.wilk@oracle.com, Marc Zyngier <marc.zyngier@arm.com>,
	catalin.marinas@arm.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	tim@xen.org, linux-kernel@vger.kernel.org,
	linux@arm.linux.org.uk, linux-arm-kernel@lists.infradead.org
Subject: [Xen-devel] [PATCH v4 21/24] arm/v2m: initialize arch_timers even
	if v2m_timer is not present
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="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>
CC: Russell King <linux@arm.linux.org.uk>
CC: Pawel Moll <pawel.moll@arm.com>
CC: Marc Zyngier <marc.zyngier@arm.com>
---
 arch/arm/mach-vexpress/v2m.c |   11 ++++++-----
 1 files changed, 6 insertions(+), 5 deletions(-)

diff --git a/arch/arm/mach-vexpress/v2m.c b/arch/arm/mach-vexpress/v2m.c
index 37608f2..4e567f7 100644
--- a/arch/arm/mach-vexpress/v2m.c
+++ b/arch/arm/mach-vexpress/v2m.c
@@ -621,16 +621,17 @@ static void __init v2m_dt_timer_init(void)
 
 	v2m_clk_init();
 
-	err = of_property_read_string(of_aliases, "arm,v2m_timer", &path);
-	if (WARN_ON(err))
-		return;
-	node = of_find_node_by_path(path);
-	v2m_sp804_init(of_iomap(node, 0), irq_of_parse_and_map(node, 0));
 	if (arch_timer_of_register() != 0)
 		twd_local_timer_of_register();
 
 	if (arch_timer_sched_clock_init() != 0)
 		versatile_sched_clock_init(v2m_sysreg_base + V2M_SYS_24MHZ, 24000000);
+
+	err = of_property_read_string(of_aliases, "arm,v2m_timer", &path);
+	if (WARN_ON(err))
+		return;
+	node = of_find_node_by_path(path);
+	v2m_sp804_init(of_iomap(node, 0), irq_of_parse_and_map(node, 0));
 }
 
 static struct sys_timer v2m_dt_timer = {
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 14 11:42:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 11: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 1TCUHX-0007jc-EO; Fri, 14 Sep 2012 11:41:59 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1TCUHV-0007hd-7T
	for xen-devel@lists.xensource.com; Fri, 14 Sep 2012 11:41:57 +0000
Received: from [85.158.137.99:52740] by server-10.bemta-3.messagelabs.com id
	CC/C4-10411-40813505; Fri, 14 Sep 2012 11:41:56 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-13.tower-217.messagelabs.com!1347622914!17689783!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNzQ1Njg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10347 invoked from network); 14 Sep 2012 11:41:55 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-13.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Sep 2012 11:41:55 -0000
X-IronPort-AV: E=Sophos;i="4.80,422,1344211200"; d="scan'208";a="208102992"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Sep 2012 11:41:54 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Fri, 14 Sep 2012 07:41:53 -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 1TCTqN-0005wt-Ku;
	Fri, 14 Sep 2012 12:13:55 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: <arnd@arndb.de>
Date: Fri, 14 Sep 2012 12:13:20 +0100
Message-ID: <1347621207-11294-18-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <alpine.DEB.2.02.1209141145150.29232@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1209141145150.29232@kaball.uk.xensource.com>
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com, linaro-dev@lists.linaro.org,
	Ian.Campbell@citrix.com, konrad.wilk@oracle.com, catalin.marinas@arm.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	tim@xen.org, linux-kernel@vger.kernel.org,
	linux@arm.linux.org.uk, linux-arm-kernel@lists.infradead.org
Subject: [Xen-devel] [PATCH v4 18/24] xen: allow privcmd 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

This patch removes the "return -ENOSYS" for auto_translated_physmap
guests from privcmd_mmap, thus it allows ARM guests to issue privcmd
mmap calls. However privcmd mmap calls are still going to fail for HVM
and hybrid guests on x86 because the xen_remap_domain_mfn_range
implementation is currently PV only.

Changes in v2:

- better commit message;
- return -EINVAL from xen_remap_domain_mfn_range if
  auto_translated_physmap.


Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 arch/x86/xen/mmu.c    |    3 +++
 drivers/xen/privcmd.c |    4 ----
 2 files changed, 3 insertions(+), 4 deletions(-)

diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c
index 5141d80..984cf66 100644
--- a/arch/x86/xen/mmu.c
+++ b/arch/x86/xen/mmu.c
@@ -2337,6 +2337,9 @@ int xen_remap_domain_mfn_range(struct vm_area_struct *vma,
 	unsigned long range;
 	int err = 0;
 
+	if (xen_feature(XENFEAT_auto_translated_physmap))
+		return -EINVAL;
+
 	prot = __pgprot(pgprot_val(prot) | _PAGE_IOMAP);
 
 	BUG_ON(!((vma->vm_flags & (VM_PFNMAP | VM_RESERVED | VM_IO)) ==
diff --git a/drivers/xen/privcmd.c b/drivers/xen/privcmd.c
index ccee0f1..85226cb 100644
--- a/drivers/xen/privcmd.c
+++ b/drivers/xen/privcmd.c
@@ -380,10 +380,6 @@ static struct vm_operations_struct privcmd_vm_ops = {
 
 static int privcmd_mmap(struct file *file, struct vm_area_struct *vma)
 {
-	/* Unsupported for auto-translate guests. */
-	if (xen_feature(XENFEAT_auto_translated_physmap))
-		return -ENOSYS;
-
 	/* DONTCOPY is essential for Xen because copy_page_range doesn't know
 	 * how to recreate these mappings */
 	vma->vm_flags |= VM_RESERVED | VM_IO | VM_DONTCOPY | VM_PFNMAP;
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 14 11:42:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 11: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 1TCUHX-0007jc-EO; Fri, 14 Sep 2012 11:41:59 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1TCUHV-0007hd-7T
	for xen-devel@lists.xensource.com; Fri, 14 Sep 2012 11:41:57 +0000
Received: from [85.158.137.99:52740] by server-10.bemta-3.messagelabs.com id
	CC/C4-10411-40813505; Fri, 14 Sep 2012 11:41:56 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-13.tower-217.messagelabs.com!1347622914!17689783!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNzQ1Njg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10347 invoked from network); 14 Sep 2012 11:41:55 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-13.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Sep 2012 11:41:55 -0000
X-IronPort-AV: E=Sophos;i="4.80,422,1344211200"; d="scan'208";a="208102992"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Sep 2012 11:41:54 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Fri, 14 Sep 2012 07:41:53 -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 1TCTqN-0005wt-Ku;
	Fri, 14 Sep 2012 12:13:55 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: <arnd@arndb.de>
Date: Fri, 14 Sep 2012 12:13:20 +0100
Message-ID: <1347621207-11294-18-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <alpine.DEB.2.02.1209141145150.29232@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1209141145150.29232@kaball.uk.xensource.com>
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com, linaro-dev@lists.linaro.org,
	Ian.Campbell@citrix.com, konrad.wilk@oracle.com, catalin.marinas@arm.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	tim@xen.org, linux-kernel@vger.kernel.org,
	linux@arm.linux.org.uk, linux-arm-kernel@lists.infradead.org
Subject: [Xen-devel] [PATCH v4 18/24] xen: allow privcmd 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

This patch removes the "return -ENOSYS" for auto_translated_physmap
guests from privcmd_mmap, thus it allows ARM guests to issue privcmd
mmap calls. However privcmd mmap calls are still going to fail for HVM
and hybrid guests on x86 because the xen_remap_domain_mfn_range
implementation is currently PV only.

Changes in v2:

- better commit message;
- return -EINVAL from xen_remap_domain_mfn_range if
  auto_translated_physmap.


Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 arch/x86/xen/mmu.c    |    3 +++
 drivers/xen/privcmd.c |    4 ----
 2 files changed, 3 insertions(+), 4 deletions(-)

diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c
index 5141d80..984cf66 100644
--- a/arch/x86/xen/mmu.c
+++ b/arch/x86/xen/mmu.c
@@ -2337,6 +2337,9 @@ int xen_remap_domain_mfn_range(struct vm_area_struct *vma,
 	unsigned long range;
 	int err = 0;
 
+	if (xen_feature(XENFEAT_auto_translated_physmap))
+		return -EINVAL;
+
 	prot = __pgprot(pgprot_val(prot) | _PAGE_IOMAP);
 
 	BUG_ON(!((vma->vm_flags & (VM_PFNMAP | VM_RESERVED | VM_IO)) ==
diff --git a/drivers/xen/privcmd.c b/drivers/xen/privcmd.c
index ccee0f1..85226cb 100644
--- a/drivers/xen/privcmd.c
+++ b/drivers/xen/privcmd.c
@@ -380,10 +380,6 @@ static struct vm_operations_struct privcmd_vm_ops = {
 
 static int privcmd_mmap(struct file *file, struct vm_area_struct *vma)
 {
-	/* Unsupported for auto-translate guests. */
-	if (xen_feature(XENFEAT_auto_translated_physmap))
-		return -ENOSYS;
-
 	/* DONTCOPY is essential for Xen because copy_page_range doesn't know
 	 * how to recreate these mappings */
 	vma->vm_flags |= VM_RESERVED | VM_IO | VM_DONTCOPY | VM_PFNMAP;
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 14 11:42:07 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 11: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 1TCUHc-0007nQ-1J; Fri, 14 Sep 2012 11:42:04 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1TCUHa-0007lh-JP
	for xen-devel@lists.xensource.com; Fri, 14 Sep 2012 11:42:02 +0000
Received: from [85.158.137.99:53096] by server-11.bemta-3.messagelabs.com id
	9A/F7-30250-90813505; Fri, 14 Sep 2012 11:42:01 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-13.tower-217.messagelabs.com!1347622914!17689783!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNzQ1Njg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10501 invoked from network); 14 Sep 2012 11:42:00 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-13.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Sep 2012 11:42:00 -0000
X-IronPort-AV: E=Sophos;i="4.80,422,1344211200"; d="scan'208";a="208103004"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Sep 2012 11:41:59 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Fri, 14 Sep 2012 07:41:59 -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 1TCTqN-0005wt-M1;
	Fri, 14 Sep 2012 12:13:55 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: <arnd@arndb.de>
Date: Fri, 14 Sep 2012 12:13:22 +0100
Message-ID: <1347621207-11294-20-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <alpine.DEB.2.02.1209141145150.29232@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1209141145150.29232@kaball.uk.xensource.com>
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com, linaro-dev@lists.linaro.org,
	Ian.Campbell@citrix.com, konrad.wilk@oracle.com, catalin.marinas@arm.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	tim@xen.org, linux-kernel@vger.kernel.org,
	linux@arm.linux.org.uk, linux-arm-kernel@lists.infradead.org
Subject: [Xen-devel] [PATCH v4 20/24] xen/arm: compile netback
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="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>
Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 arch/arm/include/asm/xen/hypercall.h |   19 +++++++++++++++++++
 drivers/net/xen-netback/netback.c    |    1 +
 drivers/net/xen-netfront.c           |    1 +
 3 files changed, 21 insertions(+), 0 deletions(-)

diff --git a/arch/arm/include/asm/xen/hypercall.h b/arch/arm/include/asm/xen/hypercall.h
index 4ac0624..8a82325 100644
--- a/arch/arm/include/asm/xen/hypercall.h
+++ b/arch/arm/include/asm/xen/hypercall.h
@@ -47,4 +47,23 @@ unsigned long HYPERVISOR_hvm_op(int op, void *arg);
 int HYPERVISOR_memory_op(unsigned int cmd, void *arg);
 int HYPERVISOR_physdev_op(int cmd, void *arg);
 
+static inline void
+MULTI_update_va_mapping(struct multicall_entry *mcl, unsigned long va,
+			unsigned int new_val, unsigned long flags)
+{
+	BUG();
+}
+
+static inline void
+MULTI_mmu_update(struct multicall_entry *mcl, struct mmu_update *req,
+		 int count, int *success_count, domid_t domid)
+{
+	BUG();
+}
+
+static inline int
+HYPERVISOR_multicall(void *call_list, int nr_calls)
+{
+	BUG();
+}
 #endif /* _ASM_ARM_XEN_HYPERCALL_H */
diff --git a/drivers/net/xen-netback/netback.c b/drivers/net/xen-netback/netback.c
index 682633b..1c0a302 100644
--- a/drivers/net/xen-netback/netback.c
+++ b/drivers/net/xen-netback/netback.c
@@ -40,6 +40,7 @@
 
 #include <net/tcp.h>
 
+#include <xen/xen.h>
 #include <xen/events.h>
 #include <xen/interface/memory.h>
 
diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c
index 650f79a..24d968d 100644
--- a/drivers/net/xen-netfront.c
+++ b/drivers/net/xen-netfront.c
@@ -43,6 +43,7 @@
 #include <linux/slab.h>
 #include <net/ip.h>
 
+#include <asm/xen/page.h>
 #include <xen/xen.h>
 #include <xen/xenbus.h>
 #include <xen/events.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 Sep 14 11:42:07 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 11: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 1TCUHc-0007nQ-1J; Fri, 14 Sep 2012 11:42:04 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1TCUHa-0007lh-JP
	for xen-devel@lists.xensource.com; Fri, 14 Sep 2012 11:42:02 +0000
Received: from [85.158.137.99:53096] by server-11.bemta-3.messagelabs.com id
	9A/F7-30250-90813505; Fri, 14 Sep 2012 11:42:01 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-13.tower-217.messagelabs.com!1347622914!17689783!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNzQ1Njg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10501 invoked from network); 14 Sep 2012 11:42:00 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-13.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Sep 2012 11:42:00 -0000
X-IronPort-AV: E=Sophos;i="4.80,422,1344211200"; d="scan'208";a="208103004"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Sep 2012 11:41:59 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Fri, 14 Sep 2012 07:41:59 -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 1TCTqN-0005wt-M1;
	Fri, 14 Sep 2012 12:13:55 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: <arnd@arndb.de>
Date: Fri, 14 Sep 2012 12:13:22 +0100
Message-ID: <1347621207-11294-20-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <alpine.DEB.2.02.1209141145150.29232@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1209141145150.29232@kaball.uk.xensource.com>
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com, linaro-dev@lists.linaro.org,
	Ian.Campbell@citrix.com, konrad.wilk@oracle.com, catalin.marinas@arm.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	tim@xen.org, linux-kernel@vger.kernel.org,
	linux@arm.linux.org.uk, linux-arm-kernel@lists.infradead.org
Subject: [Xen-devel] [PATCH v4 20/24] xen/arm: compile netback
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="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>
Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 arch/arm/include/asm/xen/hypercall.h |   19 +++++++++++++++++++
 drivers/net/xen-netback/netback.c    |    1 +
 drivers/net/xen-netfront.c           |    1 +
 3 files changed, 21 insertions(+), 0 deletions(-)

diff --git a/arch/arm/include/asm/xen/hypercall.h b/arch/arm/include/asm/xen/hypercall.h
index 4ac0624..8a82325 100644
--- a/arch/arm/include/asm/xen/hypercall.h
+++ b/arch/arm/include/asm/xen/hypercall.h
@@ -47,4 +47,23 @@ unsigned long HYPERVISOR_hvm_op(int op, void *arg);
 int HYPERVISOR_memory_op(unsigned int cmd, void *arg);
 int HYPERVISOR_physdev_op(int cmd, void *arg);
 
+static inline void
+MULTI_update_va_mapping(struct multicall_entry *mcl, unsigned long va,
+			unsigned int new_val, unsigned long flags)
+{
+	BUG();
+}
+
+static inline void
+MULTI_mmu_update(struct multicall_entry *mcl, struct mmu_update *req,
+		 int count, int *success_count, domid_t domid)
+{
+	BUG();
+}
+
+static inline int
+HYPERVISOR_multicall(void *call_list, int nr_calls)
+{
+	BUG();
+}
 #endif /* _ASM_ARM_XEN_HYPERCALL_H */
diff --git a/drivers/net/xen-netback/netback.c b/drivers/net/xen-netback/netback.c
index 682633b..1c0a302 100644
--- a/drivers/net/xen-netback/netback.c
+++ b/drivers/net/xen-netback/netback.c
@@ -40,6 +40,7 @@
 
 #include <net/tcp.h>
 
+#include <xen/xen.h>
 #include <xen/events.h>
 #include <xen/interface/memory.h>
 
diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c
index 650f79a..24d968d 100644
--- a/drivers/net/xen-netfront.c
+++ b/drivers/net/xen-netfront.c
@@ -43,6 +43,7 @@
 #include <linux/slab.h>
 #include <net/ip.h>
 
+#include <asm/xen/page.h>
 #include <xen/xen.h>
 #include <xen/xenbus.h>
 #include <xen/events.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 Sep 14 11:42:23 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 11: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 1TCUHs-00081Q-Es; Fri, 14 Sep 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 1TCUHq-0007zh-IC
	for xen-devel@lists.xensource.com; Fri, 14 Sep 2012 11:42:18 +0000
Received: from [85.158.139.83:38183] by server-9.bemta-5.messagelabs.com id
	05/5C-20529-91813505; Fri, 14 Sep 2012 11:42:17 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1347622935!23158460!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNjk2MTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13429 invoked from network); 14 Sep 2012 11:42:17 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-16.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Sep 2012 11:42:17 -0000
X-IronPort-AV: E=Sophos;i="4.80,422,1344211200"; d="scan'208";a="37875022"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Sep 2012 11:42:05 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Fri, 14 Sep 2012 07:42:05 -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 1TCTqN-0005wt-GG;
	Fri, 14 Sep 2012 12:13:55 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: <arnd@arndb.de>
Date: Fri, 14 Sep 2012 12:13:14 +0100
Message-ID: <1347621207-11294-12-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <alpine.DEB.2.02.1209141145150.29232@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1209141145150.29232@kaball.uk.xensource.com>
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com, linaro-dev@lists.linaro.org,
	Ian.Campbell@citrix.com, konrad.wilk@oracle.com, catalin.marinas@arm.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	tim@xen.org, linux-kernel@vger.kernel.org,
	linux@arm.linux.org.uk, linux-arm-kernel@lists.infradead.org
Subject: [Xen-devel] [PATCH v4 12/24] xen/arm: introduce CONFIG_XEN on ARM
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Changes in v2:

- mark Xen guest support on ARM as EXPERIMENTAL.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 arch/arm/Kconfig |   10 ++++++++++
 1 files changed, 10 insertions(+), 0 deletions(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 2f88d8d..e92518d 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1897,6 +1897,16 @@ config DEPRECATED_PARAM_STRUCT
 	  This was deprecated in 2001 and announced to live on for 5 years.
 	  Some old boot loaders still use this way.
 
+config XEN_DOM0
+	def_bool y
+
+config XEN
+	bool "Xen guest support on ARM (EXPERIMENTAL)"
+	depends on EXPERIMENTAL && ARM && OF
+	select XEN_DOM0
+	help
+	  Say Y if you want to run Linux in a Virtual Machine on Xen on ARM.
+
 endmenu
 
 menu "Boot options"
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 14 11:42:23 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 11: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 1TCUHs-00081Q-Es; Fri, 14 Sep 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 1TCUHq-0007zh-IC
	for xen-devel@lists.xensource.com; Fri, 14 Sep 2012 11:42:18 +0000
Received: from [85.158.139.83:38183] by server-9.bemta-5.messagelabs.com id
	05/5C-20529-91813505; Fri, 14 Sep 2012 11:42:17 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1347622935!23158460!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNjk2MTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13429 invoked from network); 14 Sep 2012 11:42:17 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-16.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Sep 2012 11:42:17 -0000
X-IronPort-AV: E=Sophos;i="4.80,422,1344211200"; d="scan'208";a="37875022"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Sep 2012 11:42:05 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Fri, 14 Sep 2012 07:42:05 -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 1TCTqN-0005wt-GG;
	Fri, 14 Sep 2012 12:13:55 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: <arnd@arndb.de>
Date: Fri, 14 Sep 2012 12:13:14 +0100
Message-ID: <1347621207-11294-12-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <alpine.DEB.2.02.1209141145150.29232@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1209141145150.29232@kaball.uk.xensource.com>
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com, linaro-dev@lists.linaro.org,
	Ian.Campbell@citrix.com, konrad.wilk@oracle.com, catalin.marinas@arm.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	tim@xen.org, linux-kernel@vger.kernel.org,
	linux@arm.linux.org.uk, linux-arm-kernel@lists.infradead.org
Subject: [Xen-devel] [PATCH v4 12/24] xen/arm: introduce CONFIG_XEN on ARM
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Changes in v2:

- mark Xen guest support on ARM as EXPERIMENTAL.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 arch/arm/Kconfig |   10 ++++++++++
 1 files changed, 10 insertions(+), 0 deletions(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 2f88d8d..e92518d 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1897,6 +1897,16 @@ config DEPRECATED_PARAM_STRUCT
 	  This was deprecated in 2001 and announced to live on for 5 years.
 	  Some old boot loaders still use this way.
 
+config XEN_DOM0
+	def_bool y
+
+config XEN
+	bool "Xen guest support on ARM (EXPERIMENTAL)"
+	depends on EXPERIMENTAL && ARM && OF
+	select XEN_DOM0
+	help
+	  Say Y if you want to run Linux in a Virtual Machine on Xen on ARM.
+
 endmenu
 
 menu "Boot options"
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 14 12:24:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 12:24:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TCUvq-0001FL-Mq; Fri, 14 Sep 2012 12:23:38 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1TCUvp-0001FG-Bf
	for xen-devel@lists.xen.org; Fri, 14 Sep 2012 12:23:37 +0000
Received: from [85.158.139.83:39029] by server-3.bemta-5.messagelabs.com id
	05/87-21836-8C123505; Fri, 14 Sep 2012 12:23:36 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1347625415!16423695!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-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15461 invoked from network); 14 Sep 2012 12:23:36 -0000
Received: from mail-ey0-f173.google.com (HELO mail-ey0-f173.google.com)
	(209.85.215.173)
	by server-8.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Sep 2012 12:23:36 -0000
Received: by eaac13 with SMTP id c13so1706415eaa.32
	for <xen-devel@lists.xen.org>; Fri, 14 Sep 2012 05:23:35 -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=EVUGCHcNlEP0HI/W/ZLIwX9gR8cHrjdF4fZ0Pp97H2k=;
	b=YCVL5hYsh3YraOey7BiFZ6JWBViUeO19YIi7JTQt4XmDSAZxrLlgwZFrodcDkuHP6S
	h89+2fc+esGge2VJzp3QRI77NGCDs+7WHmNlTwEHu4AqrxxymNX6h8DssRxZWcMZL2Wc
	xCvtLNRIQz+yKDxTNsDDwzsmjokwqqYQEHjiol5C+lXUNn0Y/2/U4e6QVvEH3hLC+cb6
	z5joemrH0lz4GRPoV0ulFPvZS5waSVslEWHxWtTzJEJJNOrJz3cEl4oE3n1XlXZbRYpl
	Cct1z+pCApuDvhWdQgyhYH28eEOnQzGDCWktgC0fPdPXpv1i3BrFFxn12EenuE+usKes
	A+vA==
Received: by 10.14.184.134 with SMTP id s6mr3151584eem.46.1347625415734;
	Fri, 14 Sep 2012 05:23:35 -0700 (PDT)
Received: from [192.168.1.69] (host86-184-74-117.range86-184.btcentralplus.com.
	[86.184.74.117])
	by mx.google.com with ESMTPS id e7sm4042422eep.2.2012.09.14.05.23.33
	(version=SSLv3 cipher=OTHER); Fri, 14 Sep 2012 05:23:35 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Fri, 14 Sep 2012 13:23:32 +0100
From: Keir Fraser <keir.xen@gmail.com>
To: Ian Campbell <ian.campbell@citrix.com>,
	<xen-devel@lists.xen.org>
Message-ID: <CC78E054.3EC48%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [PATCH] tools: drop ia64 only foreign structs from
	headers
Thread-Index: Ac2Sc8D4EL+zPbevUkmxypjTkd3taw==
In-Reply-To: <640a0b0b44e67c843473.1347616836@cosworth.uk.xensource.com>
Mime-version: 1.0
Cc: Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH] tools: drop ia64 only foreign structs from
 headers
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 14/09/2012 11:00, "Ian Campbell" <ian.campbell@citrix.com> wrote:

> # HG changeset patch
> # User Ian Campbell <ian.campbell@citrix.com>
> # Date 1347616748 -3600
> # Node ID 640a0b0b44e67c8434735c5129400b3a56a43683
> # Parent  aabf685cd613b11e9b9709ae2a43f23f56d4d7ff
> tools: drop ia64 only foreign structs from headers
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

Acked-by: Keir Fraser <keir@xen.org>

> diff -r aabf685cd613 -r 640a0b0b44e6 tools/include/xen-foreign/reference.size
> --- a/tools/include/xen-foreign/reference.size Fri Sep 14 10:39:09 2012 +0100
> +++ b/tools/include/xen-foreign/reference.size Fri Sep 14 10:59:08 2012 +0100
> @@ -3,12 +3,7 @@ structs                   |  x86_32  x86
>  
>  start_info                |    1112    1168
>  trap_info                 |       8      16
> -pt_fpreg                  |       -       -
>  cpu_user_regs             |      68     200
> -xen_ia64_boot_param       |       -       -
> -ia64_tr_entry             |       -       -
> -vcpu_tr_regs              |       -       -
> -vcpu_guest_context_regs   |       -       -
>  vcpu_guest_context        |    2800    5168
>  arch_vcpu_info            |      24      16
>  vcpu_time_info            |      32      32
> diff -r aabf685cd613 -r 640a0b0b44e6 tools/include/xen-foreign/structs.py
> --- a/tools/include/xen-foreign/structs.py Fri Sep 14 10:39:09 2012 +0100
> +++ b/tools/include/xen-foreign/structs.py Fri Sep 14 10:59:08 2012 +0100
> @@ -5,12 +5,7 @@ unions  = [ "vcpu_cr_regs",
>  
>  structs = [ "start_info",
>              "trap_info",
> -            "pt_fpreg",
>              "cpu_user_regs",
> -            "xen_ia64_boot_param",
> -            "ia64_tr_entry",
> -            "vcpu_tr_regs",
> -            "vcpu_guest_context_regs",
>              "vcpu_guest_context",
>              "arch_vcpu_info",
>              "vcpu_time_info",
> @@ -48,9 +43,6 @@ defines = [ "__i386__",
>              "_VGCF_online",
>              "VGCF_online",
>  
> -            # ia64
> -            "VGCF_EXTRA_REGS",
> -
>              # all archs
>              "xen_pfn_to_cr3",
>              "xen_cr3_to_pfn",
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Sep 14 12:24:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 12:24:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TCUvq-0001FL-Mq; Fri, 14 Sep 2012 12:23:38 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1TCUvp-0001FG-Bf
	for xen-devel@lists.xen.org; Fri, 14 Sep 2012 12:23:37 +0000
Received: from [85.158.139.83:39029] by server-3.bemta-5.messagelabs.com id
	05/87-21836-8C123505; Fri, 14 Sep 2012 12:23:36 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1347625415!16423695!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-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15461 invoked from network); 14 Sep 2012 12:23:36 -0000
Received: from mail-ey0-f173.google.com (HELO mail-ey0-f173.google.com)
	(209.85.215.173)
	by server-8.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Sep 2012 12:23:36 -0000
Received: by eaac13 with SMTP id c13so1706415eaa.32
	for <xen-devel@lists.xen.org>; Fri, 14 Sep 2012 05:23:35 -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=EVUGCHcNlEP0HI/W/ZLIwX9gR8cHrjdF4fZ0Pp97H2k=;
	b=YCVL5hYsh3YraOey7BiFZ6JWBViUeO19YIi7JTQt4XmDSAZxrLlgwZFrodcDkuHP6S
	h89+2fc+esGge2VJzp3QRI77NGCDs+7WHmNlTwEHu4AqrxxymNX6h8DssRxZWcMZL2Wc
	xCvtLNRIQz+yKDxTNsDDwzsmjokwqqYQEHjiol5C+lXUNn0Y/2/U4e6QVvEH3hLC+cb6
	z5joemrH0lz4GRPoV0ulFPvZS5waSVslEWHxWtTzJEJJNOrJz3cEl4oE3n1XlXZbRYpl
	Cct1z+pCApuDvhWdQgyhYH28eEOnQzGDCWktgC0fPdPXpv1i3BrFFxn12EenuE+usKes
	A+vA==
Received: by 10.14.184.134 with SMTP id s6mr3151584eem.46.1347625415734;
	Fri, 14 Sep 2012 05:23:35 -0700 (PDT)
Received: from [192.168.1.69] (host86-184-74-117.range86-184.btcentralplus.com.
	[86.184.74.117])
	by mx.google.com with ESMTPS id e7sm4042422eep.2.2012.09.14.05.23.33
	(version=SSLv3 cipher=OTHER); Fri, 14 Sep 2012 05:23:35 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Fri, 14 Sep 2012 13:23:32 +0100
From: Keir Fraser <keir.xen@gmail.com>
To: Ian Campbell <ian.campbell@citrix.com>,
	<xen-devel@lists.xen.org>
Message-ID: <CC78E054.3EC48%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [PATCH] tools: drop ia64 only foreign structs from
	headers
Thread-Index: Ac2Sc8D4EL+zPbevUkmxypjTkd3taw==
In-Reply-To: <640a0b0b44e67c843473.1347616836@cosworth.uk.xensource.com>
Mime-version: 1.0
Cc: Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH] tools: drop ia64 only foreign structs from
 headers
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 14/09/2012 11:00, "Ian Campbell" <ian.campbell@citrix.com> wrote:

> # HG changeset patch
> # User Ian Campbell <ian.campbell@citrix.com>
> # Date 1347616748 -3600
> # Node ID 640a0b0b44e67c8434735c5129400b3a56a43683
> # Parent  aabf685cd613b11e9b9709ae2a43f23f56d4d7ff
> tools: drop ia64 only foreign structs from headers
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

Acked-by: Keir Fraser <keir@xen.org>

> diff -r aabf685cd613 -r 640a0b0b44e6 tools/include/xen-foreign/reference.size
> --- a/tools/include/xen-foreign/reference.size Fri Sep 14 10:39:09 2012 +0100
> +++ b/tools/include/xen-foreign/reference.size Fri Sep 14 10:59:08 2012 +0100
> @@ -3,12 +3,7 @@ structs                   |  x86_32  x86
>  
>  start_info                |    1112    1168
>  trap_info                 |       8      16
> -pt_fpreg                  |       -       -
>  cpu_user_regs             |      68     200
> -xen_ia64_boot_param       |       -       -
> -ia64_tr_entry             |       -       -
> -vcpu_tr_regs              |       -       -
> -vcpu_guest_context_regs   |       -       -
>  vcpu_guest_context        |    2800    5168
>  arch_vcpu_info            |      24      16
>  vcpu_time_info            |      32      32
> diff -r aabf685cd613 -r 640a0b0b44e6 tools/include/xen-foreign/structs.py
> --- a/tools/include/xen-foreign/structs.py Fri Sep 14 10:39:09 2012 +0100
> +++ b/tools/include/xen-foreign/structs.py Fri Sep 14 10:59:08 2012 +0100
> @@ -5,12 +5,7 @@ unions  = [ "vcpu_cr_regs",
>  
>  structs = [ "start_info",
>              "trap_info",
> -            "pt_fpreg",
>              "cpu_user_regs",
> -            "xen_ia64_boot_param",
> -            "ia64_tr_entry",
> -            "vcpu_tr_regs",
> -            "vcpu_guest_context_regs",
>              "vcpu_guest_context",
>              "arch_vcpu_info",
>              "vcpu_time_info",
> @@ -48,9 +43,6 @@ defines = [ "__i386__",
>              "_VGCF_online",
>              "VGCF_online",
>  
> -            # ia64
> -            "VGCF_EXTRA_REGS",
> -
>              # all archs
>              "xen_pfn_to_cr3",
>              "xen_cr3_to_pfn",
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Sep 14 12:24:28 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 12:24:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TCUwJ-0001Gu-3o; Fri, 14 Sep 2012 12:24:07 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1TCUwH-0001GV-3z
	for xen-devel@lists.xen.org; Fri, 14 Sep 2012 12:24:05 +0000
Received: from [85.158.139.83:7533] by server-2.bemta-5.messagelabs.com id
	9A/BA-11456-4E123505; Fri, 14 Sep 2012 12:24:04 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1347625415!16423695!2
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-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17256 invoked from network); 14 Sep 2012 12:24:03 -0000
Received: from mail-ey0-f173.google.com (HELO mail-ey0-f173.google.com)
	(209.85.215.173)
	by server-8.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Sep 2012 12:24:03 -0000
Received: by mail-ey0-f173.google.com with SMTP id c13so1706415eaa.32
	for <xen-devel@lists.xen.org>; Fri, 14 Sep 2012 05:24:03 -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=RXL/wOvJbrrkZxUm/RKSFEwMSR7X7ZNm3z53JZOurpg=;
	b=TQ5C2eOAt0RF8OvsaLyEox7MZX8G0l4tbjpEq5nVAUQW2QsQwmK1ALaiBKRqtFdMVR
	I7J1Myy+0b4FuVUfujI72AecSI+10b/57XEZu/KXzjVxNVZD/d8dsVX0JwPq9cJmPY5v
	CBenqwzaTcOq7FCcdkI5OYbBUY8060rOWCaeYhyKR4oWG6Sv432iWE0ROuTjJXnWIXT7
	NJljq9pE3oseMistgO/WMq8xtITS335qX9pG7uZ9fNkjEzPABN3uOHDIOMt/D3o8Qn5d
	aZh241hL8aVW93XGhB1Ob4pN7FvskkajBlGxox25qEF69N+IuJ3vP/pdZXKyaa6skJVc
	+07Q==
Received: by 10.14.198.65 with SMTP id u41mr3321234een.22.1347625443333;
	Fri, 14 Sep 2012 05:24:03 -0700 (PDT)
Received: from [192.168.1.69] (host86-184-74-117.range86-184.btcentralplus.com.
	[86.184.74.117])
	by mx.google.com with ESMTPS id h42sm4030503eem.5.2012.09.14.05.24.01
	(version=SSLv3 cipher=OTHER); Fri, 14 Sep 2012 05:24:02 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Fri, 14 Sep 2012 13:23:59 +0100
From: Keir Fraser <keir.xen@gmail.com>
To: Ian Campbell <ian.campbell@citrix.com>,
	<xen-devel@lists.xen.org>
Message-ID: <CC78E06F.3EC49%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [PATCH] .*ignore: drop ia64 entries
Thread-Index: Ac2Sc9EQla/5NSi1mE2N4cGbJoFpzg==
In-Reply-To: <0547430886c507989dd9.1347616854@cosworth.uk.xensource.com>
Mime-version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] .*ignore: drop ia64 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 14/09/2012 11:00, "Ian Campbell" <ian.campbell@citrix.com> wrote:

> # HG changeset patch
> # User Ian Campbell <ian.campbell@citrix.com>
> # Date 1347616840 -3600
> # Node ID 0547430886c507989dd9091ef5f1e2d089a50351
> # Parent  640a0b0b44e67c8434735c5129400b3a56a43683
> .*ignore: drop ia64 entries
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

Acked-by: Keir Fraser <keir@xen.org>

> diff -r 640a0b0b44e6 -r 0547430886c5 .gitignore
> --- a/.gitignore Fri Sep 14 10:59:08 2012 +0100
> +++ b/.gitignore Fri Sep 14 11:00:40 2012 +0100
> @@ -64,10 +64,7 @@ docs/xen-api/xenapi.dvi
>  docs/xen-api/xenapi.pdf
>  docs/xen-api/xenapi.ps
>  docs/xen-api/xenapi.toc
> -extras/mini-os/arch/ia64/gen_off.s
>  extras/mini-os/include/mini-os
> -extras/mini-os/include/ia64/mini-os
> -extras/mini-os/include/ia64/offsets.h
>  extras/mini-os/include/x86/mini-os
>  extras/mini-os/include/xen
>  extras/mini-os/include/list.h
> @@ -174,13 +171,6 @@ tools/hotplug/common/hotplugpath.sh
>  tools/include/xen/*
>  tools/include/xen-foreign/*.(c|h|size)
>  tools/include/xen-foreign/checker
> -tools/libxc/ia64/asm/*.h
> -tools/libxc/ia64/acpi/*.h
> -tools/libxc/ia64/acpi/platform/*.h
> -tools/libxc/ia64/dom_fw_asm.S
> -tools/libxc/ia64/dom_fw_common.c
> -tools/libxc/ia64/dom_fw_domu.c
> -tools/libxc/ia64/xen/*.h
>  tools/libxen/libxenapi-
>  tools/libxen/test/test_bindings
>  tools/libxen/test/test_event_handling
> @@ -309,9 +299,6 @@ xen/ddb/*
>  xen/include/headers.chk
>  xen/include/asm
>  xen/include/asm-*/asm-offsets.h
> -xen/include/asm-ia64/asm-xsi-offsets.h
> -xen/include/asm-ia64/.offsets.h.stamp
> -xen/include/asm-ia64/xen
>  xen/include/compat/*
>  xen/include/hypervisor-ifs/arch
>  xen/include/linux
> @@ -325,10 +312,6 @@ xen/tools/symbols
>  xen/xen
>  xen/xen-syms
>  xen/xen.*
> -xen/arch/ia64/asm-offsets.s
> -xen/arch/ia64/asm-xsi-offsets.s
> -xen/arch/ia64/map.out
> -xen/arch/ia64/xen.lds.s
>  unmodified_drivers/linux-2.6/.tmp_versions
>  unmodified_drivers/linux-2.6/*.cmd
>  unmodified_drivers/linux-2.6/*.ko
> @@ -348,7 +331,6 @@ tools/firmware/rombios/_rombios_.c
>  tools/firmware/rombios/rombios.s
>  tools/firmware/rombios/rombios.sym
>  tools/include/xen-foreign/checker.c
> -tools/include/xen-foreign/ia64.h
>  tools/include/xen-foreign/structs.pyc
>  tools/include/xen-foreign/x86_32.h
>  tools/include/xen-foreign/x86_64.h
> diff -r 640a0b0b44e6 -r 0547430886c5 .hgignore
> --- a/.hgignore Fri Sep 14 10:59:08 2012 +0100
> +++ b/.hgignore Fri Sep 14 11:00:40 2012 +0100
> @@ -64,11 +64,8 @@
>  ^docs/xen-api/vm_lifecycle.eps$
>  ^docs/xen-api/xenapi-datamodel-graph.eps$
>  ^docs/xen-api/xenapi.out$
> -^extras/mini-os/arch/ia64/gen_off.s$
>  ^extras/mini-os/include/list\.h$
>  ^extras/mini-os/include/mini-os$
> -^extras/mini-os/include/ia64/mini-os$
> -^extras/mini-os/include/ia64/offsets.h$
>  ^extras/mini-os/include/x86/mini-os$
>  ^extras/mini-os/include/xen$
>  ^extras/mini-os/mini-os.*$
> @@ -168,13 +165,6 @@
>  ^tools/include/xen/.*$
>  ^tools/include/xen-foreign/.*\.(c|h|size)$
>  ^tools/include/xen-foreign/checker$
> -^tools/libxc/ia64/asm/.*\.h$
> -^tools/libxc/ia64/acpi/.*\.h$
> -^tools/libxc/ia64/acpi/platform/.*\.h$
> -^tools/libxc/ia64/dom_fw_asm.S$
> -^tools/libxc/ia64/dom_fw_common\.c$
> -^tools/libxc/ia64/dom_fw_domu\.c$
> -^tools/libxc/ia64/xen/.*\.h$
>  ^tools/libxen/libxenapi-
>  ^tools/libxen/test/test_bindings$
>  ^tools/libxen/test/test_event_handling$
> @@ -338,9 +328,6 @@
>  ^xen/include/headers\.chk$
>  ^xen/include/asm$
>  ^xen/include/asm-.*/asm-offsets\.h$
> -^xen/include/asm-ia64/asm-xsi-offsets\.h$
> -^xen/include/asm-ia64/.offsets.h.stamp$
> -^xen/include/asm-ia64/xen$
>  ^xen/include/compat/.*$
>  ^xen/include/hypervisor-ifs/arch$
>  ^xen/include/linux$
> @@ -354,10 +341,6 @@
>  ^xen/xen$
>  ^xen/xen-syms$
>  ^xen/xen\..*$
> -^xen/arch/ia64/asm-offsets\.s$
> -^xen/arch/ia64/asm-xsi-offsets\.s$
> -^xen/arch/ia64/map\.out$
> -^xen/arch/ia64/xen\.lds\.s$
>  ^unmodified_drivers/linux-2.6/\.tmp_versions
>  ^unmodified_drivers/linux-2.6/.*\.cmd$
>  ^unmodified_drivers/linux-2.6/.*\.ko$
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Sep 14 12:24:28 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 12:24:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TCUwJ-0001Gu-3o; Fri, 14 Sep 2012 12:24:07 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1TCUwH-0001GV-3z
	for xen-devel@lists.xen.org; Fri, 14 Sep 2012 12:24:05 +0000
Received: from [85.158.139.83:7533] by server-2.bemta-5.messagelabs.com id
	9A/BA-11456-4E123505; Fri, 14 Sep 2012 12:24:04 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1347625415!16423695!2
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-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17256 invoked from network); 14 Sep 2012 12:24:03 -0000
Received: from mail-ey0-f173.google.com (HELO mail-ey0-f173.google.com)
	(209.85.215.173)
	by server-8.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Sep 2012 12:24:03 -0000
Received: by mail-ey0-f173.google.com with SMTP id c13so1706415eaa.32
	for <xen-devel@lists.xen.org>; Fri, 14 Sep 2012 05:24:03 -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=RXL/wOvJbrrkZxUm/RKSFEwMSR7X7ZNm3z53JZOurpg=;
	b=TQ5C2eOAt0RF8OvsaLyEox7MZX8G0l4tbjpEq5nVAUQW2QsQwmK1ALaiBKRqtFdMVR
	I7J1Myy+0b4FuVUfujI72AecSI+10b/57XEZu/KXzjVxNVZD/d8dsVX0JwPq9cJmPY5v
	CBenqwzaTcOq7FCcdkI5OYbBUY8060rOWCaeYhyKR4oWG6Sv432iWE0ROuTjJXnWIXT7
	NJljq9pE3oseMistgO/WMq8xtITS335qX9pG7uZ9fNkjEzPABN3uOHDIOMt/D3o8Qn5d
	aZh241hL8aVW93XGhB1Ob4pN7FvskkajBlGxox25qEF69N+IuJ3vP/pdZXKyaa6skJVc
	+07Q==
Received: by 10.14.198.65 with SMTP id u41mr3321234een.22.1347625443333;
	Fri, 14 Sep 2012 05:24:03 -0700 (PDT)
Received: from [192.168.1.69] (host86-184-74-117.range86-184.btcentralplus.com.
	[86.184.74.117])
	by mx.google.com with ESMTPS id h42sm4030503eem.5.2012.09.14.05.24.01
	(version=SSLv3 cipher=OTHER); Fri, 14 Sep 2012 05:24:02 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Fri, 14 Sep 2012 13:23:59 +0100
From: Keir Fraser <keir.xen@gmail.com>
To: Ian Campbell <ian.campbell@citrix.com>,
	<xen-devel@lists.xen.org>
Message-ID: <CC78E06F.3EC49%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [PATCH] .*ignore: drop ia64 entries
Thread-Index: Ac2Sc9EQla/5NSi1mE2N4cGbJoFpzg==
In-Reply-To: <0547430886c507989dd9.1347616854@cosworth.uk.xensource.com>
Mime-version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] .*ignore: drop ia64 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 14/09/2012 11:00, "Ian Campbell" <ian.campbell@citrix.com> wrote:

> # HG changeset patch
> # User Ian Campbell <ian.campbell@citrix.com>
> # Date 1347616840 -3600
> # Node ID 0547430886c507989dd9091ef5f1e2d089a50351
> # Parent  640a0b0b44e67c8434735c5129400b3a56a43683
> .*ignore: drop ia64 entries
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

Acked-by: Keir Fraser <keir@xen.org>

> diff -r 640a0b0b44e6 -r 0547430886c5 .gitignore
> --- a/.gitignore Fri Sep 14 10:59:08 2012 +0100
> +++ b/.gitignore Fri Sep 14 11:00:40 2012 +0100
> @@ -64,10 +64,7 @@ docs/xen-api/xenapi.dvi
>  docs/xen-api/xenapi.pdf
>  docs/xen-api/xenapi.ps
>  docs/xen-api/xenapi.toc
> -extras/mini-os/arch/ia64/gen_off.s
>  extras/mini-os/include/mini-os
> -extras/mini-os/include/ia64/mini-os
> -extras/mini-os/include/ia64/offsets.h
>  extras/mini-os/include/x86/mini-os
>  extras/mini-os/include/xen
>  extras/mini-os/include/list.h
> @@ -174,13 +171,6 @@ tools/hotplug/common/hotplugpath.sh
>  tools/include/xen/*
>  tools/include/xen-foreign/*.(c|h|size)
>  tools/include/xen-foreign/checker
> -tools/libxc/ia64/asm/*.h
> -tools/libxc/ia64/acpi/*.h
> -tools/libxc/ia64/acpi/platform/*.h
> -tools/libxc/ia64/dom_fw_asm.S
> -tools/libxc/ia64/dom_fw_common.c
> -tools/libxc/ia64/dom_fw_domu.c
> -tools/libxc/ia64/xen/*.h
>  tools/libxen/libxenapi-
>  tools/libxen/test/test_bindings
>  tools/libxen/test/test_event_handling
> @@ -309,9 +299,6 @@ xen/ddb/*
>  xen/include/headers.chk
>  xen/include/asm
>  xen/include/asm-*/asm-offsets.h
> -xen/include/asm-ia64/asm-xsi-offsets.h
> -xen/include/asm-ia64/.offsets.h.stamp
> -xen/include/asm-ia64/xen
>  xen/include/compat/*
>  xen/include/hypervisor-ifs/arch
>  xen/include/linux
> @@ -325,10 +312,6 @@ xen/tools/symbols
>  xen/xen
>  xen/xen-syms
>  xen/xen.*
> -xen/arch/ia64/asm-offsets.s
> -xen/arch/ia64/asm-xsi-offsets.s
> -xen/arch/ia64/map.out
> -xen/arch/ia64/xen.lds.s
>  unmodified_drivers/linux-2.6/.tmp_versions
>  unmodified_drivers/linux-2.6/*.cmd
>  unmodified_drivers/linux-2.6/*.ko
> @@ -348,7 +331,6 @@ tools/firmware/rombios/_rombios_.c
>  tools/firmware/rombios/rombios.s
>  tools/firmware/rombios/rombios.sym
>  tools/include/xen-foreign/checker.c
> -tools/include/xen-foreign/ia64.h
>  tools/include/xen-foreign/structs.pyc
>  tools/include/xen-foreign/x86_32.h
>  tools/include/xen-foreign/x86_64.h
> diff -r 640a0b0b44e6 -r 0547430886c5 .hgignore
> --- a/.hgignore Fri Sep 14 10:59:08 2012 +0100
> +++ b/.hgignore Fri Sep 14 11:00:40 2012 +0100
> @@ -64,11 +64,8 @@
>  ^docs/xen-api/vm_lifecycle.eps$
>  ^docs/xen-api/xenapi-datamodel-graph.eps$
>  ^docs/xen-api/xenapi.out$
> -^extras/mini-os/arch/ia64/gen_off.s$
>  ^extras/mini-os/include/list\.h$
>  ^extras/mini-os/include/mini-os$
> -^extras/mini-os/include/ia64/mini-os$
> -^extras/mini-os/include/ia64/offsets.h$
>  ^extras/mini-os/include/x86/mini-os$
>  ^extras/mini-os/include/xen$
>  ^extras/mini-os/mini-os.*$
> @@ -168,13 +165,6 @@
>  ^tools/include/xen/.*$
>  ^tools/include/xen-foreign/.*\.(c|h|size)$
>  ^tools/include/xen-foreign/checker$
> -^tools/libxc/ia64/asm/.*\.h$
> -^tools/libxc/ia64/acpi/.*\.h$
> -^tools/libxc/ia64/acpi/platform/.*\.h$
> -^tools/libxc/ia64/dom_fw_asm.S$
> -^tools/libxc/ia64/dom_fw_common\.c$
> -^tools/libxc/ia64/dom_fw_domu\.c$
> -^tools/libxc/ia64/xen/.*\.h$
>  ^tools/libxen/libxenapi-
>  ^tools/libxen/test/test_bindings$
>  ^tools/libxen/test/test_event_handling$
> @@ -338,9 +328,6 @@
>  ^xen/include/headers\.chk$
>  ^xen/include/asm$
>  ^xen/include/asm-.*/asm-offsets\.h$
> -^xen/include/asm-ia64/asm-xsi-offsets\.h$
> -^xen/include/asm-ia64/.offsets.h.stamp$
> -^xen/include/asm-ia64/xen$
>  ^xen/include/compat/.*$
>  ^xen/include/hypervisor-ifs/arch$
>  ^xen/include/linux$
> @@ -354,10 +341,6 @@
>  ^xen/xen$
>  ^xen/xen-syms$
>  ^xen/xen\..*$
> -^xen/arch/ia64/asm-offsets\.s$
> -^xen/arch/ia64/asm-xsi-offsets\.s$
> -^xen/arch/ia64/map\.out$
> -^xen/arch/ia64/xen\.lds\.s$
>  ^unmodified_drivers/linux-2.6/\.tmp_versions
>  ^unmodified_drivers/linux-2.6/.*\.cmd$
>  ^unmodified_drivers/linux-2.6/.*\.ko$
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Sep 14 12:30:50 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 12:30:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TCV2T-0001Xg-5h; Fri, 14 Sep 2012 12:30:29 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <pawel.moll@arm.com>) id 1TCUzK-0001SE-DG
	for xen-devel@lists.xensource.com; Fri, 14 Sep 2012 12:27:14 +0000
Received: from [85.158.143.35:9360] by server-3.bemta-4.messagelabs.com id
	FF/7C-08232-1A223505; Fri, 14 Sep 2012 12:27:13 +0000
X-Env-Sender: pawel.moll@arm.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1347625632!7223721!1
X-Originating-IP: [91.220.42.44]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogOTEuMjIwLjQyLjQ0ID0+IDI5NDIyMA==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32495 invoked from network); 14 Sep 2012 12:27:12 -0000
Received: from service87.mimecast.com (HELO service87.mimecast.com)
	(91.220.42.44) by server-9.tower-21.messagelabs.com with SMTP;
	14 Sep 2012 12:27:12 -0000
Received: from cam-owa1.Emea.Arm.com (fw-tnat.cambridge.arm.com
	[217.140.96.21]) by service87.mimecast.com;
	Fri, 14 Sep 2012 13:27:11 +0100
Received: from [10.1.205.42] ([10.1.255.212]) by cam-owa1.Emea.Arm.com with
	Microsoft SMTPSVC(6.0.3790.0); Fri, 14 Sep 2012 13:27:08 +0100
Message-ID: <1347625628.2497.65.camel@hornet>
From: Pawel Moll <pawel.moll@arm.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Fri, 14 Sep 2012 13:27:08 +0100
In-Reply-To: <1347621207-11294-21-git-send-email-stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.02.1209141145150.29232@kaball.uk.xensource.com>
	<1347621207-11294-21-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: Evolution 3.2.3-0ubuntu6
Mime-Version: 1.0
X-OriginalArrivalTime: 14 Sep 2012 12:27:08.0448 (UTC)
	FILETIME=[41FB9200:01CD9274]
X-MC-Unique: 112091413271102001
X-Mailman-Approved-At: Fri, 14 Sep 2012 12:30:27 +0000
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linaro-dev@lists.linaro.org" <linaro-dev@lists.linaro.org>,
	"Ian.Campbell@citrix.com" <Ian.Campbell@citrix.com>,
	"arnd@arndb.de" <arnd@arndb.de>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
	Marc Zyngier <Marc.Zyngier@arm.com>,
	Catalin Marinas <Catalin.Marinas@arm.com>, "tim@xen.org" <tim@xen.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux@arm.linux.org.uk" <linux@arm.linux.org.uk>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Xen-devel] [PATCH v4 21/24] arm/v2m: initialize arch_timers
 even if v2m_timer is not present
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gRnJpLCAyMDEyLTA5LTE0IGF0IDEyOjEzICswMTAwLCBTdGVmYW5vIFN0YWJlbGxpbmkgd3Jv
dGU6Cj4gU2lnbmVkLW9mZi1ieTogU3RlZmFubyBTdGFiZWxsaW5pIDxzdGVmYW5vLnN0YWJlbGxp
bmlAZXUuY2l0cml4LmNvbT4KPiBDQzogUnVzc2VsbCBLaW5nIDxsaW51eEBhcm0ubGludXgub3Jn
LnVrPgo+IENDOiBQYXdlbCBNb2xsIDxwYXdlbC5tb2xsQGFybS5jb20+Cj4gQ0M6IE1hcmMgWnlu
Z2llciA8bWFyYy56eW5naWVyQGFybS5jb20+Cj4gLS0tCj4gIGFyY2gvYXJtL21hY2gtdmV4cHJl
c3MvdjJtLmMgfCAgIDExICsrKysrKy0tLS0tCj4gIDEgZmlsZXMgY2hhbmdlZCwgNiBpbnNlcnRp
b25zKCspLCA1IGRlbGV0aW9ucygtKQo+IAo+IGRpZmYgLS1naXQgYS9hcmNoL2FybS9tYWNoLXZl
eHByZXNzL3YybS5jIGIvYXJjaC9hcm0vbWFjaC12ZXhwcmVzcy92Mm0uYwo+IGluZGV4IDM3NjA4
ZjIuLjRlNTY3ZjcgMTAwNjQ0Cj4gLS0tIGEvYXJjaC9hcm0vbWFjaC12ZXhwcmVzcy92Mm0uYwo+
ICsrKyBiL2FyY2gvYXJtL21hY2gtdmV4cHJlc3MvdjJtLmMKPiBAQCAtNjIxLDE2ICs2MjEsMTcg
QEAgc3RhdGljIHZvaWQgX19pbml0IHYybV9kdF90aW1lcl9pbml0KHZvaWQpCj4gIAo+ICAJdjJt
X2Nsa19pbml0KCk7Cj4gIAo+IC0JZXJyID0gb2ZfcHJvcGVydHlfcmVhZF9zdHJpbmcob2ZfYWxp
YXNlcywgImFybSx2Mm1fdGltZXIiLCAmcGF0aCk7Cj4gLQlpZiAoV0FSTl9PTihlcnIpKQo+IC0J
CXJldHVybjsKPiAtCW5vZGUgPSBvZl9maW5kX25vZGVfYnlfcGF0aChwYXRoKTsKPiAtCXYybV9z
cDgwNF9pbml0KG9mX2lvbWFwKG5vZGUsIDApLCBpcnFfb2ZfcGFyc2VfYW5kX21hcChub2RlLCAw
KSk7Cj4gIAlpZiAoYXJjaF90aW1lcl9vZl9yZWdpc3RlcigpICE9IDApCj4gIAkJdHdkX2xvY2Fs
X3RpbWVyX29mX3JlZ2lzdGVyKCk7Cj4gIAo+ICAJaWYgKGFyY2hfdGltZXJfc2NoZWRfY2xvY2tf
aW5pdCgpICE9IDApCj4gIAkJdmVyc2F0aWxlX3NjaGVkX2Nsb2NrX2luaXQodjJtX3N5c3JlZ19i
YXNlICsgVjJNX1NZU18yNE1IWiwgMjQwMDAwMDApOwo+ICsKPiArCWVyciA9IG9mX3Byb3BlcnR5
X3JlYWRfc3RyaW5nKG9mX2FsaWFzZXMsICJhcm0sdjJtX3RpbWVyIiwgJnBhdGgpOwo+ICsJaWYg
KFdBUk5fT04oZXJyKSkKPiArCQlyZXR1cm47Cj4gKwlub2RlID0gb2ZfZmluZF9ub2RlX2J5X3Bh
dGgocGF0aCk7Cj4gKwl2Mm1fc3A4MDRfaW5pdChvZl9pb21hcChub2RlLCAwKSwgaXJxX29mX3Bh
cnNlX2FuZF9tYXAobm9kZSwgMCkpOwo+ICB9Cj4gIAo+ICBzdGF0aWMgc3RydWN0IHN5c190aW1l
ciB2Mm1fZHRfdGltZXIgPSB7CgpGYWlyIHBvaW50LiBUaGUgYWxpYXMgaXMgZ29pbmcgdG8gZGlz
YXBwZWFyIGFueXdheSAoSSdtIHdvcmtpbmcgb24gYSBWRQpwbGF0Zm9ybSByZXdvcmsgcmlnaHQg
bm93KSwgYnV0IGluIGNhc2UgSSB3b24ndCBnZXQgaXQgb24gdGltZSBmb3IgMy43LApJJ2xsIG1h
a2Ugc3VyZSB0aGlzIG9uZSBpcyBtZXJnZWQgaW5zdGVhZC4KCkNoZWVycyEKClBhd2XFggoKCgoK
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVs
IG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwOi8vbGlzdHMueGVuLm9y
Zy94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xen.org Fri Sep 14 12:30:50 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 12:30:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TCV2T-0001Xg-5h; Fri, 14 Sep 2012 12:30:29 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <pawel.moll@arm.com>) id 1TCUzK-0001SE-DG
	for xen-devel@lists.xensource.com; Fri, 14 Sep 2012 12:27:14 +0000
Received: from [85.158.143.35:9360] by server-3.bemta-4.messagelabs.com id
	FF/7C-08232-1A223505; Fri, 14 Sep 2012 12:27:13 +0000
X-Env-Sender: pawel.moll@arm.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1347625632!7223721!1
X-Originating-IP: [91.220.42.44]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogOTEuMjIwLjQyLjQ0ID0+IDI5NDIyMA==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32495 invoked from network); 14 Sep 2012 12:27:12 -0000
Received: from service87.mimecast.com (HELO service87.mimecast.com)
	(91.220.42.44) by server-9.tower-21.messagelabs.com with SMTP;
	14 Sep 2012 12:27:12 -0000
Received: from cam-owa1.Emea.Arm.com (fw-tnat.cambridge.arm.com
	[217.140.96.21]) by service87.mimecast.com;
	Fri, 14 Sep 2012 13:27:11 +0100
Received: from [10.1.205.42] ([10.1.255.212]) by cam-owa1.Emea.Arm.com with
	Microsoft SMTPSVC(6.0.3790.0); Fri, 14 Sep 2012 13:27:08 +0100
Message-ID: <1347625628.2497.65.camel@hornet>
From: Pawel Moll <pawel.moll@arm.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Fri, 14 Sep 2012 13:27:08 +0100
In-Reply-To: <1347621207-11294-21-git-send-email-stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.02.1209141145150.29232@kaball.uk.xensource.com>
	<1347621207-11294-21-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: Evolution 3.2.3-0ubuntu6
Mime-Version: 1.0
X-OriginalArrivalTime: 14 Sep 2012 12:27:08.0448 (UTC)
	FILETIME=[41FB9200:01CD9274]
X-MC-Unique: 112091413271102001
X-Mailman-Approved-At: Fri, 14 Sep 2012 12:30:27 +0000
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linaro-dev@lists.linaro.org" <linaro-dev@lists.linaro.org>,
	"Ian.Campbell@citrix.com" <Ian.Campbell@citrix.com>,
	"arnd@arndb.de" <arnd@arndb.de>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
	Marc Zyngier <Marc.Zyngier@arm.com>,
	Catalin Marinas <Catalin.Marinas@arm.com>, "tim@xen.org" <tim@xen.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux@arm.linux.org.uk" <linux@arm.linux.org.uk>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Xen-devel] [PATCH v4 21/24] arm/v2m: initialize arch_timers
 even if v2m_timer is not present
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gRnJpLCAyMDEyLTA5LTE0IGF0IDEyOjEzICswMTAwLCBTdGVmYW5vIFN0YWJlbGxpbmkgd3Jv
dGU6Cj4gU2lnbmVkLW9mZi1ieTogU3RlZmFubyBTdGFiZWxsaW5pIDxzdGVmYW5vLnN0YWJlbGxp
bmlAZXUuY2l0cml4LmNvbT4KPiBDQzogUnVzc2VsbCBLaW5nIDxsaW51eEBhcm0ubGludXgub3Jn
LnVrPgo+IENDOiBQYXdlbCBNb2xsIDxwYXdlbC5tb2xsQGFybS5jb20+Cj4gQ0M6IE1hcmMgWnlu
Z2llciA8bWFyYy56eW5naWVyQGFybS5jb20+Cj4gLS0tCj4gIGFyY2gvYXJtL21hY2gtdmV4cHJl
c3MvdjJtLmMgfCAgIDExICsrKysrKy0tLS0tCj4gIDEgZmlsZXMgY2hhbmdlZCwgNiBpbnNlcnRp
b25zKCspLCA1IGRlbGV0aW9ucygtKQo+IAo+IGRpZmYgLS1naXQgYS9hcmNoL2FybS9tYWNoLXZl
eHByZXNzL3YybS5jIGIvYXJjaC9hcm0vbWFjaC12ZXhwcmVzcy92Mm0uYwo+IGluZGV4IDM3NjA4
ZjIuLjRlNTY3ZjcgMTAwNjQ0Cj4gLS0tIGEvYXJjaC9hcm0vbWFjaC12ZXhwcmVzcy92Mm0uYwo+
ICsrKyBiL2FyY2gvYXJtL21hY2gtdmV4cHJlc3MvdjJtLmMKPiBAQCAtNjIxLDE2ICs2MjEsMTcg
QEAgc3RhdGljIHZvaWQgX19pbml0IHYybV9kdF90aW1lcl9pbml0KHZvaWQpCj4gIAo+ICAJdjJt
X2Nsa19pbml0KCk7Cj4gIAo+IC0JZXJyID0gb2ZfcHJvcGVydHlfcmVhZF9zdHJpbmcob2ZfYWxp
YXNlcywgImFybSx2Mm1fdGltZXIiLCAmcGF0aCk7Cj4gLQlpZiAoV0FSTl9PTihlcnIpKQo+IC0J
CXJldHVybjsKPiAtCW5vZGUgPSBvZl9maW5kX25vZGVfYnlfcGF0aChwYXRoKTsKPiAtCXYybV9z
cDgwNF9pbml0KG9mX2lvbWFwKG5vZGUsIDApLCBpcnFfb2ZfcGFyc2VfYW5kX21hcChub2RlLCAw
KSk7Cj4gIAlpZiAoYXJjaF90aW1lcl9vZl9yZWdpc3RlcigpICE9IDApCj4gIAkJdHdkX2xvY2Fs
X3RpbWVyX29mX3JlZ2lzdGVyKCk7Cj4gIAo+ICAJaWYgKGFyY2hfdGltZXJfc2NoZWRfY2xvY2tf
aW5pdCgpICE9IDApCj4gIAkJdmVyc2F0aWxlX3NjaGVkX2Nsb2NrX2luaXQodjJtX3N5c3JlZ19i
YXNlICsgVjJNX1NZU18yNE1IWiwgMjQwMDAwMDApOwo+ICsKPiArCWVyciA9IG9mX3Byb3BlcnR5
X3JlYWRfc3RyaW5nKG9mX2FsaWFzZXMsICJhcm0sdjJtX3RpbWVyIiwgJnBhdGgpOwo+ICsJaWYg
KFdBUk5fT04oZXJyKSkKPiArCQlyZXR1cm47Cj4gKwlub2RlID0gb2ZfZmluZF9ub2RlX2J5X3Bh
dGgocGF0aCk7Cj4gKwl2Mm1fc3A4MDRfaW5pdChvZl9pb21hcChub2RlLCAwKSwgaXJxX29mX3Bh
cnNlX2FuZF9tYXAobm9kZSwgMCkpOwo+ICB9Cj4gIAo+ICBzdGF0aWMgc3RydWN0IHN5c190aW1l
ciB2Mm1fZHRfdGltZXIgPSB7CgpGYWlyIHBvaW50LiBUaGUgYWxpYXMgaXMgZ29pbmcgdG8gZGlz
YXBwZWFyIGFueXdheSAoSSdtIHdvcmtpbmcgb24gYSBWRQpwbGF0Zm9ybSByZXdvcmsgcmlnaHQg
bm93KSwgYnV0IGluIGNhc2UgSSB3b24ndCBnZXQgaXQgb24gdGltZSBmb3IgMy43LApJJ2xsIG1h
a2Ugc3VyZSB0aGlzIG9uZSBpcyBtZXJnZWQgaW5zdGVhZC4KCkNoZWVycyEKClBhd2XFggoKCgoK
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVs
IG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwOi8vbGlzdHMueGVuLm9y
Zy94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xen.org Fri Sep 14 12:32:50 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 12:32:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TCV4J-0001cs-MM; Fri, 14 Sep 2012 12:32:23 +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 1TCV4I-0001cm-Cs
	for xen-devel@lists.xen.org; Fri, 14 Sep 2012 12:32:22 +0000
Received: from [85.158.143.35:47388] by server-2.bemta-4.messagelabs.com id
	EE/68-21239-5D323505; Fri, 14 Sep 2012 12:32:21 +0000
X-Env-Sender: lars.kurth.xen@gmail.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1347625940!12445082!1
X-Originating-IP: [74.125.83.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7089 invoked from network); 14 Sep 2012 12:32:20 -0000
Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com)
	(74.125.83.45)
	by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Sep 2012 12:32:20 -0000
Received: by eeke53 with SMTP id e53so2584884eek.32
	for <xen-devel@lists.xen.org>; Fri, 14 Sep 2012 05:32:20 -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=ELhABEw066arP0kUFWVpfJttHNCtnfUb3HC2jl4ZnCA=;
	b=a47YDqe2NwAFoCxKm+KLutWI3WHyJQ7nLkaPledVOtOHdcpt1nTxYyk4IkQXqAbgyX
	EllGpunei0W3BGWO4ovIgbVZcxsINy7P82aYwUFccfFbdm2XVXlScr0IAp7nUgkex/qe
	rrTuaYlm1tdpXfiMArML0lEFfq4cMlu+72T2tZIpKaqWQCa5UOmI6UOfLHWhHvVZ3bLv
	e1UEMc7PYG9hL1X4plLtUsCvq7/y3oVyVuxsQJlMtDaAJjgXrJLrY+s3hN12JJIkzxVD
	gwEg2ePe1W1Okp9Tjsqr/ijCISlNxvw1p4kH86l4dL0UgoUGhp5H+PG4ksfaOli4Kj0h
	76VA==
Received: by 10.14.213.137 with SMTP id a9mr3240213eep.38.1347625940161;
	Fri, 14 Sep 2012 05:32:20 -0700 (PDT)
Received: from [172.16.26.11] (b0fb5b35.bb.sky.com. [176.251.91.53])
	by mx.google.com with ESMTPS id u8sm4048678eel.11.2012.09.14.05.32.17
	(version=SSLv3 cipher=OTHER); Fri, 14 Sep 2012 05:32:18 -0700 (PDT)
Message-ID: <505323CF.5090508@xen.org>
Date: Fri, 14 Sep 2012 13:32:15 +0100
From: Lars Kurth <lars.kurth@xen.org>
User-Agent: Mozilla/5.0 (Windows NT 6.1;
	rv:15.0) Gecko/20120907 Thunderbird/15.0.1
MIME-Version: 1.0
To: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: [Xen-devel] Xen 4.2 Contribution Statistics
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: lars.kurth@xen.org
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi everybody,

I created a wiki page with Xen 4.2 contribution stats and 
acknowledgements at http://wiki.xen.org/wiki/Xen_4.2_Acknowledgments - 
Thank you for all the contributions.

We will link to this in the Xen 4.2 release blog post as well as on the 
release page

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 Sep 14 12:32:50 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 12:32:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TCV4J-0001cs-MM; Fri, 14 Sep 2012 12:32:23 +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 1TCV4I-0001cm-Cs
	for xen-devel@lists.xen.org; Fri, 14 Sep 2012 12:32:22 +0000
Received: from [85.158.143.35:47388] by server-2.bemta-4.messagelabs.com id
	EE/68-21239-5D323505; Fri, 14 Sep 2012 12:32:21 +0000
X-Env-Sender: lars.kurth.xen@gmail.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1347625940!12445082!1
X-Originating-IP: [74.125.83.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7089 invoked from network); 14 Sep 2012 12:32:20 -0000
Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com)
	(74.125.83.45)
	by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Sep 2012 12:32:20 -0000
Received: by eeke53 with SMTP id e53so2584884eek.32
	for <xen-devel@lists.xen.org>; Fri, 14 Sep 2012 05:32:20 -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=ELhABEw066arP0kUFWVpfJttHNCtnfUb3HC2jl4ZnCA=;
	b=a47YDqe2NwAFoCxKm+KLutWI3WHyJQ7nLkaPledVOtOHdcpt1nTxYyk4IkQXqAbgyX
	EllGpunei0W3BGWO4ovIgbVZcxsINy7P82aYwUFccfFbdm2XVXlScr0IAp7nUgkex/qe
	rrTuaYlm1tdpXfiMArML0lEFfq4cMlu+72T2tZIpKaqWQCa5UOmI6UOfLHWhHvVZ3bLv
	e1UEMc7PYG9hL1X4plLtUsCvq7/y3oVyVuxsQJlMtDaAJjgXrJLrY+s3hN12JJIkzxVD
	gwEg2ePe1W1Okp9Tjsqr/ijCISlNxvw1p4kH86l4dL0UgoUGhp5H+PG4ksfaOli4Kj0h
	76VA==
Received: by 10.14.213.137 with SMTP id a9mr3240213eep.38.1347625940161;
	Fri, 14 Sep 2012 05:32:20 -0700 (PDT)
Received: from [172.16.26.11] (b0fb5b35.bb.sky.com. [176.251.91.53])
	by mx.google.com with ESMTPS id u8sm4048678eel.11.2012.09.14.05.32.17
	(version=SSLv3 cipher=OTHER); Fri, 14 Sep 2012 05:32:18 -0700 (PDT)
Message-ID: <505323CF.5090508@xen.org>
Date: Fri, 14 Sep 2012 13:32:15 +0100
From: Lars Kurth <lars.kurth@xen.org>
User-Agent: Mozilla/5.0 (Windows NT 6.1;
	rv:15.0) Gecko/20120907 Thunderbird/15.0.1
MIME-Version: 1.0
To: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: [Xen-devel] Xen 4.2 Contribution Statistics
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: lars.kurth@xen.org
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi everybody,

I created a wiki page with Xen 4.2 contribution stats and 
acknowledgements at http://wiki.xen.org/wiki/Xen_4.2_Acknowledgments - 
Thank you for all the contributions.

We will link to this in the Xen 4.2 release blog post as well as on the 
release page

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 Sep 14 12:42:50 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 12:42:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TCVEA-0001vn-09; Fri, 14 Sep 2012 12:42:34 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1TCVE8-0001vc-O4
	for xen-devel@lists.xen.org; Fri, 14 Sep 2012 12:42:32 +0000
Received: from [85.158.139.83:8272] by server-9.bemta-5.messagelabs.com id
	D8/1B-20529-73623505; Fri, 14 Sep 2012 12:42:31 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1347626549!16426476!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNjk2MTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21517 invoked from network); 14 Sep 2012 12:42:31 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-8.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Sep 2012 12:42:31 -0000
X-IronPort-AV: E=Sophos;i="4.80,422,1344211200"; d="scan'208";a="37881296"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Sep 2012 12:42:29 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Fri, 14 Sep 2012 08:42:29 -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 1TCVE4-0007Ic-Tr;
	Fri, 14 Sep 2012 13:42:28 +0100
MIME-Version: 1.0
Message-ID: <patchbomb.1347626548@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Fri, 14 Sep 2012 13:42:28 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 0 of 3] libxl/xl: Enable -Wshadow
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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've had several occuranced of confusion on xl due to shadowing the
global domid variable with a local one. The main bulk of this series
removes that global, the rest is smaller cleanups to allow Wshadow.

I've already sent the libxl part of this, but am reincluding here as
part of the set.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 14 12:42:50 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 12:42:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TCVEA-0001vn-09; Fri, 14 Sep 2012 12:42:34 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1TCVE8-0001vc-O4
	for xen-devel@lists.xen.org; Fri, 14 Sep 2012 12:42:32 +0000
Received: from [85.158.139.83:8272] by server-9.bemta-5.messagelabs.com id
	D8/1B-20529-73623505; Fri, 14 Sep 2012 12:42:31 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1347626549!16426476!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNjk2MTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21517 invoked from network); 14 Sep 2012 12:42:31 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-8.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Sep 2012 12:42:31 -0000
X-IronPort-AV: E=Sophos;i="4.80,422,1344211200"; d="scan'208";a="37881296"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Sep 2012 12:42:29 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Fri, 14 Sep 2012 08:42:29 -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 1TCVE4-0007Ic-Tr;
	Fri, 14 Sep 2012 13:42:28 +0100
MIME-Version: 1.0
Message-ID: <patchbomb.1347626548@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Fri, 14 Sep 2012 13:42:28 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 0 of 3] libxl/xl: Enable -Wshadow
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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've had several occuranced of confusion on xl due to shadowing the
global domid variable with a local one. The main bulk of this series
removes that global, the rest is smaller cleanups to allow Wshadow.

I've already sent the libxl part of this, but am reincluding here as
part of the set.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 14 12:42:51 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 12: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 1TCVEB-0001w9-OB; Fri, 14 Sep 2012 12:42:35 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1TCVE9-0001vi-R4
	for xen-devel@lists.xen.org; Fri, 14 Sep 2012 12:42:34 +0000
Received: from [85.158.138.51:18802] by server-3.bemta-3.messagelabs.com id
	2B/06-21322-83623505; Fri, 14 Sep 2012 12:42:32 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1347626550!28875356!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNzQ1Njg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22381 invoked from network); 14 Sep 2012 12:42:31 -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;
	14 Sep 2012 12:42:31 -0000
X-IronPort-AV: E=Sophos;i="4.80,422,1344211200"; d="scan'208";a="208108655"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Sep 2012 12:42:29 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Fri, 14 Sep 2012 08:42:29 -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 1TCVE4-0007Ic-UL;
	Fri, 14 Sep 2012 13:42:28 +0100
MIME-Version: 1.0
X-Mercurial-Node: 58ab3fb73d13e250f334a38599b749640deac190
Message-ID: <58ab3fb73d13e250f334.1347626549@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1347626548@cosworth.uk.xensource.com>
References: <patchbomb.1347626548@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Fri, 14 Sep 2012 13:42:29 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 1 of 3] libxl: Enable -Wshadow
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 1347620983 -3600
# Node ID 58ab3fb73d13e250f334a38599b749640deac190
# Parent  0547430886c507989dd9091ef5f1e2d089a50351
libxl: Enable -Wshadow.

It was convenient to invent $(CFLAGS_LIBXL) to do this.

Various renamings to avoid shadowing standard functions:
  - index(3)
  - listen(2)
  - link(2)
  - abort(3)
  - abs(3)

Reduced the scope of some variables to avoid conflicts.

Change to libxc is due to the nested hypercall buf macros in
set_xen_guest_handle (used in libxl) using the same local private vars.

Build tested only.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r 0547430886c5 -r 58ab3fb73d13 tools/libxc/xenctrl.h
--- a/tools/libxc/xenctrl.h	Fri Sep 14 11:00:40 2012 +0100
+++ b/tools/libxc/xenctrl.h	Fri Sep 14 12:09:43 2012 +0100
@@ -236,10 +236,10 @@ typedef struct xc_hypercall_buffer xc_hy
  * Returns the hypercall_buffer associated with a variable.
  */
 #define HYPERCALL_BUFFER(_name)                                                              \
-    ({  xc_hypercall_buffer_t _val1;                                                         \
-        typeof(XC__HYPERCALL_BUFFER_NAME(_name)) *_val2 = &XC__HYPERCALL_BUFFER_NAME(_name); \
-        (void)(&_val1 == _val2);                                                             \
-        (_val2)->param_shadow ? (_val2)->param_shadow : (_val2);                             \
+    ({  xc_hypercall_buffer_t _buf1;                                                         \
+        typeof(XC__HYPERCALL_BUFFER_NAME(_name)) *_buf2 = &XC__HYPERCALL_BUFFER_NAME(_name); \
+        (void)(&_buf1 == _buf2);                                                             \
+        (_buf2)->param_shadow ? (_buf2)->param_shadow : (_buf2);                             \
      })
 
 #define HYPERCALL_BUFFER_INIT_NO_BOUNCE .dir = 0, .sz = 0, .ubuf = (void *)-1
@@ -274,10 +274,10 @@ typedef struct xc_hypercall_buffer xc_hy
  * directly as a hypercall argument.
  */
 #define HYPERCALL_BUFFER_AS_ARG(_name)                                             \
-    ({  xc_hypercall_buffer_t _val1;                                               \
-        typeof(XC__HYPERCALL_BUFFER_NAME(_name)) *_val2 = HYPERCALL_BUFFER(_name); \
-        (void)(&_val1 == _val2);                                                   \
-        (unsigned long)(_val2)->hbuf;                                              \
+    ({  xc_hypercall_buffer_t _bufarg1;                                               \
+        typeof(XC__HYPERCALL_BUFFER_NAME(_name)) *_bufarg2 = HYPERCALL_BUFFER(_name); \
+        (void)(&_bufarg1 == _bufarg2);                                                   \
+        (unsigned long)(_bufarg2)->hbuf;                                              \
      })
 
 /*
@@ -287,10 +287,10 @@ typedef struct xc_hypercall_buffer xc_hy
 #undef set_xen_guest_handle
 #define set_xen_guest_handle(_hnd, _val)                                         \
     do {                                                                         \
-        xc_hypercall_buffer_t _val1;                                             \
-        typeof(XC__HYPERCALL_BUFFER_NAME(_val)) *_val2 = HYPERCALL_BUFFER(_val); \
-        (void) (&_val1 == _val2);                                                 \
-        set_xen_guest_handle_raw(_hnd, (_val2)->hbuf);                           \
+        xc_hypercall_buffer_t _bufhnd1;                                             \
+        typeof(XC__HYPERCALL_BUFFER_NAME(_val)) *_bufhnd2 = HYPERCALL_BUFFER(_val); \
+        (void) (&_bufhnd1 == _bufhnd2);                                                 \
+        set_xen_guest_handle_raw(_hnd, (_bufhnd2)->hbuf);                           \
     } while (0)
 
 /* Use with set_xen_guest_handle in place of NULL */
diff -r 0547430886c5 -r 58ab3fb73d13 tools/libxl/Makefile
--- a/tools/libxl/Makefile	Fri Sep 14 11:00:40 2012 +0100
+++ b/tools/libxl/Makefile	Fri Sep 14 12:09:43 2012 +0100
@@ -22,6 +22,12 @@ endif
 LIBXL_LIBS =
 LIBXL_LIBS = $(LDLIBS_libxenctrl) $(LDLIBS_libxenguest) $(LDLIBS_libxenstore) $(LDLIBS_libblktapctl) $(PTYFUNCS_LIBS) $(LIBUUID_LIBS)
 
+CFLAGS_LIBXL += $(CFLAGS_libxenctrl)
+CFLAGS_LIBXL += $(CFLAGS_libxenguest)
+CFLAGS_LIBXL += $(CFLAGS_libxenstore)
+CFLAGS_LIBXL += $(CFLAGS_libblktapctl) 
+CFLAGS_LIBXL += -Wshadow
+
 CFLAGS += $(PTHREAD_CFLAGS)
 LDFLAGS += $(PTHREAD_LDFLAGS)
 LIBXL_LIBS += $(PTHREAD_LIBS)
@@ -71,7 +77,7 @@ LIBXL_OBJS = flexarray.o libxl.o libxl_c
 			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
+$(LIBXL_OBJS): CFLAGS += $(CFLAGS_LIBXL) -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
diff -r 0547430886c5 -r 58ab3fb73d13 tools/libxl/flexarray.c
--- a/tools/libxl/flexarray.c	Fri Sep 14 11:00:40 2012 +0100
+++ b/tools/libxl/flexarray.c	Fri Sep 14 12:09:43 2012 +0100
@@ -48,19 +48,19 @@ int flexarray_grow(flexarray_t *array, i
     return 0;
 }
 
-int flexarray_set(flexarray_t *array, unsigned int index, void *ptr)
+int flexarray_set(flexarray_t *array, unsigned int idx, void *ptr)
 {
-    if (index >= array->size) {
+    if (idx >= array->size) {
         int newsize;
         if (!array->autogrow)
             return 1;
-        newsize = (array->size * 2 < index) ? index + 1 : array->size * 2;
+        newsize = (array->size * 2 < idx) ? idx + 1 : array->size * 2;
         if (flexarray_grow(array, newsize - array->size))
             return 2;
     }
-    if ( index + 1 > array->count )
-        array->count = index + 1;
-    array->data[index] = ptr;
+    if ( idx + 1 > array->count )
+        array->count = idx + 1;
+    array->data[idx] = ptr;
     return 0;
 }
 
@@ -92,11 +92,11 @@ int flexarray_vappend(flexarray_t *array
     return ret;
 }
 
-int flexarray_get(flexarray_t *array, int index, void **ptr)
+int flexarray_get(flexarray_t *array, int idx, void **ptr)
 {
-    if (index >= array->size)
+    if (idx >= array->size)
         return 1;
-    *ptr = array->data[index];
+    *ptr = array->data[idx];
     return 0;
 }
 
diff -r 0547430886c5 -r 58ab3fb73d13 tools/libxl/libxl.c
--- a/tools/libxl/libxl.c	Fri Sep 14 11:00:40 2012 +0100
+++ b/tools/libxl/libxl.c	Fri Sep 14 12:09:43 2012 +0100
@@ -665,7 +665,7 @@ out:
 libxl_vminfo * libxl_list_vm(libxl_ctx *ctx, int *nb_vm_out)
 {
     libxl_vminfo *ptr;
-    int index, i, ret;
+    int idx, i, ret;
     xc_domaininfo_t info[1024];
     int size = 1024;
 
@@ -678,15 +678,15 @@ libxl_vminfo * libxl_list_vm(libxl_ctx *
         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "geting domain info list");
         return NULL;
     }
-    for (index = i = 0; i < ret; i++) {
+    for (idx = i = 0; i < ret; i++) {
         if (libxl_is_stubdom(ctx, info[i].domain, NULL))
             continue;
-        memcpy(&(ptr[index].uuid), info[i].handle, sizeof(xen_domain_handle_t));
-        ptr[index].domid = info[i].domain;
-
-        index++;
-    }
-    *nb_vm_out = index;
+        memcpy(&(ptr[idx].uuid), info[i].handle, sizeof(xen_domain_handle_t));
+        ptr[idx].domid = info[i].domain;
+
+        idx++;
+    }
+    *nb_vm_out = idx;
     return ptr;
 }
 
@@ -3354,7 +3354,7 @@ int libxl_set_memory_target(libxl_ctx *c
         int32_t target_memkb, int relative, int enforce)
 {
     GC_INIT(ctx);
-    int rc = 1, abort = 0;
+    int rc = 1, abort_transaction = 0;
     uint32_t memorykb = 0, videoram = 0;
     uint32_t current_target_memkb = 0, new_target_memkb = 0;
     char *memmax, *endptr, *videoram_s = NULL, *target = NULL;
@@ -3373,7 +3373,7 @@ retry_transaction:
         xs_transaction_end(ctx->xsh, t, 1);
         rc = libxl__fill_dom0_memory_info(gc, &current_target_memkb);
         if (rc < 0) {
-            abort = 1;
+            abort_transaction = 1;
             goto out;
         }
         goto retry_transaction;
@@ -3381,7 +3381,7 @@ retry_transaction:
         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR,
                 "cannot get target memory info from %s/memory/target\n",
                 dompath);
-        abort = 1;
+        abort_transaction = 1;
         goto out;
     } else {
         current_target_memkb = strtoul(target, &endptr, 10);
@@ -3389,7 +3389,7 @@ retry_transaction:
             LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR,
                     "invalid memory target %s from %s/memory/target\n",
                     target, dompath);
-            abort = 1;
+            abort_transaction = 1;
             goto out;
         }
     }
@@ -3399,7 +3399,7 @@ retry_transaction:
         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR,
                 "cannot get memory info from %s/memory/static-max\n",
                 dompath);
-        abort = 1;
+        abort_transaction = 1;
         goto out;
     }
     memorykb = strtoul(memmax, &endptr, 10);
@@ -3407,7 +3407,7 @@ retry_transaction:
         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR,
                 "invalid max memory %s from %s/memory/static-max\n",
                 memmax, dompath);
-        abort = 1;
+        abort_transaction = 1;
         goto out;
     }
 
@@ -3422,7 +3422,7 @@ retry_transaction:
         LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
                 "memory_dynamic_max must be less than or equal to"
                 " memory_static_max\n");
-        abort = 1;
+        abort_transaction = 1;
         goto out;
     }
 
@@ -3430,7 +3430,7 @@ retry_transaction:
         LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
                 "new target %d for dom0 is below the minimum threshold\n",
                  new_target_memkb);
-        abort = 1;
+        abort_transaction = 1;
         goto out;
     }
     videoram_s = libxl__xs_read(gc, t, libxl__sprintf(gc,
@@ -3445,7 +3445,7 @@ retry_transaction:
             LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR,
                     "xc_domain_setmaxmem domid=%d memkb=%d failed "
                     "rc=%d\n", domid, memorykb + LIBXL_MAXMEM_CONSTANT, rc);
-            abort = 1;
+            abort_transaction = 1;
             goto out;
         }
     }
@@ -3458,7 +3458,7 @@ retry_transaction:
                 "xc_domain_set_pod_target domid=%d, memkb=%d "
                 "failed rc=%d\n", domid, new_target_memkb / 4,
                 rc);
-        abort = 1;
+        abort_transaction = 1;
         goto out;
     }
 
@@ -3466,7 +3466,7 @@ retry_transaction:
                 dompath), "%"PRIu32, new_target_memkb);
     rc = xc_domain_getinfolist(ctx->xch, domid, 1, &info);
     if (rc != 1 || info.domain != domid) {
-        abort = 1;
+        abort_transaction = 1;
         goto out;
     }
     xcinfo2xlinfo(&info, &ptr);
@@ -3475,7 +3475,8 @@ retry_transaction:
             "%"PRIu32, new_target_memkb / 1024);
 
 out:
-    if (!xs_transaction_end(ctx->xsh, t, abort) && !abort)
+    if (!xs_transaction_end(ctx->xsh, t, abort_transaction)
+        && !abort_transaction)
         if (errno == EAGAIN)
             goto retry_transaction;
 
diff -r 0547430886c5 -r 58ab3fb73d13 tools/libxl/libxl_dm.c
--- a/tools/libxl/libxl_dm.c	Fri Sep 14 11:00:40 2012 +0100
+++ b/tools/libxl/libxl_dm.c	Fri Sep 14 12:09:43 2012 +0100
@@ -379,7 +379,7 @@ static char ** libxl__build_device_model
     }
     if (vnc) {
         int display = 0;
-        const char *listen = "127.0.0.1";
+        const char *addr = "127.0.0.1";
         char *vncarg = NULL;
 
         flexarray_append(dm_args, "-vnc");
@@ -387,16 +387,16 @@ static char ** libxl__build_device_model
         if (vnc->display) {
             display = vnc->display;
             if (vnc->listen && strchr(vnc->listen, ':') == NULL) {
-                listen = vnc->listen;
+                addr = vnc->listen;
             }
         } else if (vnc->listen) {
-            listen = vnc->listen;
+            addr = vnc->listen;
         }
 
-        if (strchr(listen, ':') != NULL)
-            vncarg = libxl__sprintf(gc, "%s", listen);
+        if (strchr(addr, ':') != NULL)
+            vncarg = libxl__sprintf(gc, "%s", addr);
         else
-            vncarg = libxl__sprintf(gc, "%s:%d", listen, display);
+            vncarg = libxl__sprintf(gc, "%s:%d", addr, display);
         if (vnc->passwd && vnc->passwd[0]) {
             vncarg = libxl__sprintf(gc, "%s,password", vncarg);
         }
diff -r 0547430886c5 -r 58ab3fb73d13 tools/libxl/libxl_event.c
--- a/tools/libxl/libxl_event.c	Fri Sep 14 11:00:40 2012 +0100
+++ b/tools/libxl/libxl_event.c	Fri Sep 14 12:09:43 2012 +0100
@@ -167,15 +167,15 @@ static void time_insert_finite(libxl__gc
 }
 
 static int time_register_finite(libxl__gc *gc, libxl__ev_time *ev,
-                                struct timeval abs)
+                                struct timeval absolute)
 {
     int rc;
 
-    rc = OSEVENT_HOOK(timeout_register, &ev->for_app_reg, abs, ev);
+    rc = OSEVENT_HOOK(timeout_register, &ev->for_app_reg, absolute, ev);
     if (rc) return rc;
 
     ev->infinite = 0;
-    ev->abs = abs;
+    ev->abs = absolute;
     time_insert_finite(gc, ev);
 
     return 0;
@@ -202,16 +202,16 @@ static void time_done_debug(libxl__gc *g
 
 int libxl__ev_time_register_abs(libxl__gc *gc, libxl__ev_time *ev,
                                 libxl__ev_time_callback *func,
-                                struct timeval abs)
+                                struct timeval absolute)
 {
     int rc;
 
     CTX_LOCK;
 
     DBG("ev_time=%p register abs=%lu.%06lu",
-        ev, (unsigned long)abs.tv_sec, (unsigned long)abs.tv_usec);
+        ev, (unsigned long)absolute.tv_sec, (unsigned long)absolute.tv_usec);
 
-    rc = time_register_finite(gc, ev, abs);
+    rc = time_register_finite(gc, ev, absolute);
     if (rc) goto out;
 
     ev->func = func;
@@ -228,7 +228,7 @@ int libxl__ev_time_register_rel(libxl__g
                                 libxl__ev_time_callback *func,
                                 int milliseconds /* as for poll(2) */)
 {
-    struct timeval abs;
+    struct timeval absolute;
     int rc;
 
     CTX_LOCK;
@@ -238,10 +238,10 @@ int libxl__ev_time_register_rel(libxl__g
     if (milliseconds < 0) {
         ev->infinite = 1;
     } else {
-        rc = time_rel_to_abs(gc, milliseconds, &abs);
+        rc = time_rel_to_abs(gc, milliseconds, &absolute);
         if (rc) goto out;
 
-        rc = time_register_finite(gc, ev, abs);
+        rc = time_register_finite(gc, ev, absolute);
         if (rc) goto out;
     }
 
@@ -255,26 +255,26 @@ int libxl__ev_time_register_rel(libxl__g
 }
 
 int libxl__ev_time_modify_abs(libxl__gc *gc, libxl__ev_time *ev,
-                              struct timeval abs)
+                              struct timeval absolute)
 {
     int rc;
 
     CTX_LOCK;
 
     DBG("ev_time=%p modify abs==%lu.%06lu",
-        ev, (unsigned long)abs.tv_sec, (unsigned long)abs.tv_usec);
+        ev, (unsigned long)absolute.tv_sec, (unsigned long)absolute.tv_usec);
 
     assert(libxl__ev_time_isregistered(ev));
 
     if (ev->infinite) {
-        rc = time_register_finite(gc, ev, abs);
+        rc = time_register_finite(gc, ev, absolute);
         if (rc) goto out;
     } else {
-        rc = OSEVENT_HOOK(timeout_modify, &ev->for_app_reg, abs);
+        rc = OSEVENT_HOOK(timeout_modify, &ev->for_app_reg, absolute);
         if (rc) goto out;
 
         LIBXL_TAILQ_REMOVE(&CTX->etimes, ev, entry);
-        ev->abs = abs;
+        ev->abs = absolute;
         time_insert_finite(gc, ev);
     }
 
@@ -288,7 +288,7 @@ int libxl__ev_time_modify_abs(libxl__gc 
 int libxl__ev_time_modify_rel(libxl__gc *gc, libxl__ev_time *ev,
                               int milliseconds)
 {
-    struct timeval abs;
+    struct timeval absolute;
     int rc;
 
     CTX_LOCK;
@@ -304,10 +304,10 @@ int libxl__ev_time_modify_rel(libxl__gc 
         goto out;
     }
 
-    rc = time_rel_to_abs(gc, milliseconds, &abs);
+    rc = time_rel_to_abs(gc, milliseconds, &absolute);
     if (rc) goto out;
 
-    rc = libxl__ev_time_modify_abs(gc, ev, abs);
+    rc = libxl__ev_time_modify_abs(gc, ev, absolute);
     if (rc) goto out;
 
     rc = 0;
diff -r 0547430886c5 -r 58ab3fb73d13 tools/libxl/libxl_exec.c
--- a/tools/libxl/libxl_exec.c	Fri Sep 14 11:00:40 2012 +0100
+++ b/tools/libxl/libxl_exec.c	Fri Sep 14 12:09:43 2012 +0100
@@ -35,7 +35,7 @@ static void check_open_fds(const char *w
 #ifdef __linux__
         size_t len;
         char path[PATH_MAX];
-        char link[PATH_MAX+1];
+        char linkpath[PATH_MAX+1];
 #endif
         flags = fcntl(i, F_GETFD);
         if ( flags == -1 ) {
@@ -52,11 +52,11 @@ static void check_open_fds(const char *w
 
 #ifdef __linux__
         snprintf(path, PATH_MAX, "/proc/%d/fd/%d", getpid(), i);
-        len = readlink(path, link, PATH_MAX);
+        len = readlink(path, linkpath, PATH_MAX);
         if (len > 0) {
-            link[len] = '\0';
+            linkpath[len] = '\0';
             fprintf(stderr, "libxl: execing %s: fd %d is open to %s with flags %#x\n",
-                    what, i, link, flags);
+                    what, i, linkpath, flags);
         } else
 #endif
             fprintf(stderr, "libxl: execing %s: fd %d is open with flags %#x\n",
diff -r 0547430886c5 -r 58ab3fb73d13 tools/libxl/libxl_json.c
--- a/tools/libxl/libxl_json.c	Fri Sep 14 11:00:40 2012 +0100
+++ b/tools/libxl/libxl_json.c	Fri Sep 14 12:09:43 2012 +0100
@@ -275,7 +275,7 @@ static int json_object_append_to(libxl__
 
 void libxl__json_object_free(libxl__gc *gc, libxl__json_object *obj)
 {
-    int index = 0;
+    int idx = 0;
 
     if (obj == NULL)
         return;
@@ -287,8 +287,8 @@ void libxl__json_object_free(libxl__gc *
     case JSON_MAP: {
         libxl__json_map_node *node = NULL;
 
-        for (index = 0; index < obj->u.map->count; index++) {
-            if (flexarray_get(obj->u.map, index, (void**)&node) != 0)
+        for (idx = 0; idx < obj->u.map->count; idx++) {
+            if (flexarray_get(obj->u.map, idx, (void**)&node) != 0)
                 break;
             libxl__json_object_free(gc, node->obj);
             free(node->map_key);
@@ -302,8 +302,8 @@ void libxl__json_object_free(libxl__gc *
         libxl__json_object *node = NULL;
         break;
 
-        for (index = 0; index < obj->u.array->count; index++) {
-            if (flexarray_get(obj->u.array, index, (void**)&node) != 0)
+        for (idx = 0; idx < obj->u.array->count; idx++) {
+            if (flexarray_get(obj->u.array, idx, (void**)&node) != 0)
                 break;
             libxl__json_object_free(gc, node);
             node = NULL;
@@ -359,14 +359,14 @@ const libxl__json_object *libxl__json_ma
                                           libxl__json_node_type expected_type)
 {
     flexarray_t *maps = NULL;
-    int index = 0;
+    int idx = 0;
 
     if (libxl__json_object_is_map(o)) {
         libxl__json_map_node *node = NULL;
 
         maps = o->u.map;
-        for (index = 0; index < maps->count; index++) {
-            if (flexarray_get(maps, index, (void**)&node) != 0)
+        for (idx = 0; idx < maps->count; idx++) {
+            if (flexarray_get(maps, idx, (void**)&node) != 0)
                 return NULL;
             if (strcmp(key, node->map_key) == 0) {
                 if (expected_type == JSON_ANY
diff -r 0547430886c5 -r 58ab3fb73d13 tools/libxl/libxl_pci.c
--- a/tools/libxl/libxl_pci.c	Fri Sep 14 11:00:40 2012 +0100
+++ b/tools/libxl/libxl_pci.c	Fri Sep 14 12:09:43 2012 +0100
@@ -167,7 +167,6 @@ static int libxl__device_pci_remove_xens
     char *be_path, *num_devs_path, *num_devs, *xsdev, *tmp, *tmppath;
     int num, i, j;
     xs_transaction_t t;
-    unsigned int domain = 0, bus = 0, dev = 0, func = 0;
 
     be_path = libxl__sprintf(gc, "%s/backend/pci/%d/0", libxl__xs_get_dompath(gc, 0), domid);
     num_devs_path = libxl__sprintf(gc, "%s/num_devs", be_path);
@@ -188,6 +187,7 @@ static int libxl__device_pci_remove_xens
     }
 
     for (i = 0; i < num; i++) {
+        unsigned int domain = 0, bus = 0, dev = 0, func = 0;
         xsdev = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/dev-%d", be_path, i));
         sscanf(xsdev, PCI_BDF, &domain, &bus, &dev, &func);
         if (domain == pcidev->domain && bus == pcidev->bus &&
diff -r 0547430886c5 -r 58ab3fb73d13 tools/libxl/libxl_qmp.c
--- a/tools/libxl/libxl_qmp.c	Fri Sep 14 11:00:40 2012 +0100
+++ b/tools/libxl/libxl_qmp.c	Fri Sep 14 12:09:43 2012 +0100
@@ -171,7 +171,7 @@ static int qmp_register_vnc_callback(lib
 {
     GC_INIT(qmp->ctx);
     const libxl__json_object *obj;
-    const char *listen, *port;
+    const char *addr, *port;
     int rc = -1;
 
     if (!libxl__json_object_is_map(o)) {
@@ -184,17 +184,17 @@ static int qmp_register_vnc_callback(lib
     }
 
     obj = libxl__json_map_get("host", o, JSON_STRING);
-    listen = libxl__json_object_get_string(obj);
+    addr = libxl__json_object_get_string(obj);
     obj = libxl__json_map_get("service", o, JSON_STRING);
     port = libxl__json_object_get_string(obj);
 
-    if (!listen || !port) {
+    if (!addr || !port) {
         LIBXL__LOG(qmp->ctx, LIBXL__LOG_ERROR,
                    "Failed to retreive VNC connect information.");
         goto out;
     }
 
-    rc = qmp_write_domain_console_item(gc, qmp->domid, "vnc-listen", listen);
+    rc = qmp_write_domain_console_item(gc, qmp->domid, "vnc-listen", addr);
     if (!rc)
         rc = qmp_write_domain_console_item(gc, qmp->domid, "vnc-port", port);
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 14 12:42:51 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 12: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 1TCVEB-0001w9-OB; Fri, 14 Sep 2012 12:42:35 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1TCVE9-0001vi-R4
	for xen-devel@lists.xen.org; Fri, 14 Sep 2012 12:42:34 +0000
Received: from [85.158.138.51:18802] by server-3.bemta-3.messagelabs.com id
	2B/06-21322-83623505; Fri, 14 Sep 2012 12:42:32 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1347626550!28875356!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNzQ1Njg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22381 invoked from network); 14 Sep 2012 12:42:31 -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;
	14 Sep 2012 12:42:31 -0000
X-IronPort-AV: E=Sophos;i="4.80,422,1344211200"; d="scan'208";a="208108655"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Sep 2012 12:42:29 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Fri, 14 Sep 2012 08:42:29 -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 1TCVE4-0007Ic-UL;
	Fri, 14 Sep 2012 13:42:28 +0100
MIME-Version: 1.0
X-Mercurial-Node: 58ab3fb73d13e250f334a38599b749640deac190
Message-ID: <58ab3fb73d13e250f334.1347626549@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1347626548@cosworth.uk.xensource.com>
References: <patchbomb.1347626548@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Fri, 14 Sep 2012 13:42:29 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 1 of 3] libxl: Enable -Wshadow
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 1347620983 -3600
# Node ID 58ab3fb73d13e250f334a38599b749640deac190
# Parent  0547430886c507989dd9091ef5f1e2d089a50351
libxl: Enable -Wshadow.

It was convenient to invent $(CFLAGS_LIBXL) to do this.

Various renamings to avoid shadowing standard functions:
  - index(3)
  - listen(2)
  - link(2)
  - abort(3)
  - abs(3)

Reduced the scope of some variables to avoid conflicts.

Change to libxc is due to the nested hypercall buf macros in
set_xen_guest_handle (used in libxl) using the same local private vars.

Build tested only.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r 0547430886c5 -r 58ab3fb73d13 tools/libxc/xenctrl.h
--- a/tools/libxc/xenctrl.h	Fri Sep 14 11:00:40 2012 +0100
+++ b/tools/libxc/xenctrl.h	Fri Sep 14 12:09:43 2012 +0100
@@ -236,10 +236,10 @@ typedef struct xc_hypercall_buffer xc_hy
  * Returns the hypercall_buffer associated with a variable.
  */
 #define HYPERCALL_BUFFER(_name)                                                              \
-    ({  xc_hypercall_buffer_t _val1;                                                         \
-        typeof(XC__HYPERCALL_BUFFER_NAME(_name)) *_val2 = &XC__HYPERCALL_BUFFER_NAME(_name); \
-        (void)(&_val1 == _val2);                                                             \
-        (_val2)->param_shadow ? (_val2)->param_shadow : (_val2);                             \
+    ({  xc_hypercall_buffer_t _buf1;                                                         \
+        typeof(XC__HYPERCALL_BUFFER_NAME(_name)) *_buf2 = &XC__HYPERCALL_BUFFER_NAME(_name); \
+        (void)(&_buf1 == _buf2);                                                             \
+        (_buf2)->param_shadow ? (_buf2)->param_shadow : (_buf2);                             \
      })
 
 #define HYPERCALL_BUFFER_INIT_NO_BOUNCE .dir = 0, .sz = 0, .ubuf = (void *)-1
@@ -274,10 +274,10 @@ typedef struct xc_hypercall_buffer xc_hy
  * directly as a hypercall argument.
  */
 #define HYPERCALL_BUFFER_AS_ARG(_name)                                             \
-    ({  xc_hypercall_buffer_t _val1;                                               \
-        typeof(XC__HYPERCALL_BUFFER_NAME(_name)) *_val2 = HYPERCALL_BUFFER(_name); \
-        (void)(&_val1 == _val2);                                                   \
-        (unsigned long)(_val2)->hbuf;                                              \
+    ({  xc_hypercall_buffer_t _bufarg1;                                               \
+        typeof(XC__HYPERCALL_BUFFER_NAME(_name)) *_bufarg2 = HYPERCALL_BUFFER(_name); \
+        (void)(&_bufarg1 == _bufarg2);                                                   \
+        (unsigned long)(_bufarg2)->hbuf;                                              \
      })
 
 /*
@@ -287,10 +287,10 @@ typedef struct xc_hypercall_buffer xc_hy
 #undef set_xen_guest_handle
 #define set_xen_guest_handle(_hnd, _val)                                         \
     do {                                                                         \
-        xc_hypercall_buffer_t _val1;                                             \
-        typeof(XC__HYPERCALL_BUFFER_NAME(_val)) *_val2 = HYPERCALL_BUFFER(_val); \
-        (void) (&_val1 == _val2);                                                 \
-        set_xen_guest_handle_raw(_hnd, (_val2)->hbuf);                           \
+        xc_hypercall_buffer_t _bufhnd1;                                             \
+        typeof(XC__HYPERCALL_BUFFER_NAME(_val)) *_bufhnd2 = HYPERCALL_BUFFER(_val); \
+        (void) (&_bufhnd1 == _bufhnd2);                                                 \
+        set_xen_guest_handle_raw(_hnd, (_bufhnd2)->hbuf);                           \
     } while (0)
 
 /* Use with set_xen_guest_handle in place of NULL */
diff -r 0547430886c5 -r 58ab3fb73d13 tools/libxl/Makefile
--- a/tools/libxl/Makefile	Fri Sep 14 11:00:40 2012 +0100
+++ b/tools/libxl/Makefile	Fri Sep 14 12:09:43 2012 +0100
@@ -22,6 +22,12 @@ endif
 LIBXL_LIBS =
 LIBXL_LIBS = $(LDLIBS_libxenctrl) $(LDLIBS_libxenguest) $(LDLIBS_libxenstore) $(LDLIBS_libblktapctl) $(PTYFUNCS_LIBS) $(LIBUUID_LIBS)
 
+CFLAGS_LIBXL += $(CFLAGS_libxenctrl)
+CFLAGS_LIBXL += $(CFLAGS_libxenguest)
+CFLAGS_LIBXL += $(CFLAGS_libxenstore)
+CFLAGS_LIBXL += $(CFLAGS_libblktapctl) 
+CFLAGS_LIBXL += -Wshadow
+
 CFLAGS += $(PTHREAD_CFLAGS)
 LDFLAGS += $(PTHREAD_LDFLAGS)
 LIBXL_LIBS += $(PTHREAD_LIBS)
@@ -71,7 +77,7 @@ LIBXL_OBJS = flexarray.o libxl.o libxl_c
 			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
+$(LIBXL_OBJS): CFLAGS += $(CFLAGS_LIBXL) -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
diff -r 0547430886c5 -r 58ab3fb73d13 tools/libxl/flexarray.c
--- a/tools/libxl/flexarray.c	Fri Sep 14 11:00:40 2012 +0100
+++ b/tools/libxl/flexarray.c	Fri Sep 14 12:09:43 2012 +0100
@@ -48,19 +48,19 @@ int flexarray_grow(flexarray_t *array, i
     return 0;
 }
 
-int flexarray_set(flexarray_t *array, unsigned int index, void *ptr)
+int flexarray_set(flexarray_t *array, unsigned int idx, void *ptr)
 {
-    if (index >= array->size) {
+    if (idx >= array->size) {
         int newsize;
         if (!array->autogrow)
             return 1;
-        newsize = (array->size * 2 < index) ? index + 1 : array->size * 2;
+        newsize = (array->size * 2 < idx) ? idx + 1 : array->size * 2;
         if (flexarray_grow(array, newsize - array->size))
             return 2;
     }
-    if ( index + 1 > array->count )
-        array->count = index + 1;
-    array->data[index] = ptr;
+    if ( idx + 1 > array->count )
+        array->count = idx + 1;
+    array->data[idx] = ptr;
     return 0;
 }
 
@@ -92,11 +92,11 @@ int flexarray_vappend(flexarray_t *array
     return ret;
 }
 
-int flexarray_get(flexarray_t *array, int index, void **ptr)
+int flexarray_get(flexarray_t *array, int idx, void **ptr)
 {
-    if (index >= array->size)
+    if (idx >= array->size)
         return 1;
-    *ptr = array->data[index];
+    *ptr = array->data[idx];
     return 0;
 }
 
diff -r 0547430886c5 -r 58ab3fb73d13 tools/libxl/libxl.c
--- a/tools/libxl/libxl.c	Fri Sep 14 11:00:40 2012 +0100
+++ b/tools/libxl/libxl.c	Fri Sep 14 12:09:43 2012 +0100
@@ -665,7 +665,7 @@ out:
 libxl_vminfo * libxl_list_vm(libxl_ctx *ctx, int *nb_vm_out)
 {
     libxl_vminfo *ptr;
-    int index, i, ret;
+    int idx, i, ret;
     xc_domaininfo_t info[1024];
     int size = 1024;
 
@@ -678,15 +678,15 @@ libxl_vminfo * libxl_list_vm(libxl_ctx *
         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "geting domain info list");
         return NULL;
     }
-    for (index = i = 0; i < ret; i++) {
+    for (idx = i = 0; i < ret; i++) {
         if (libxl_is_stubdom(ctx, info[i].domain, NULL))
             continue;
-        memcpy(&(ptr[index].uuid), info[i].handle, sizeof(xen_domain_handle_t));
-        ptr[index].domid = info[i].domain;
-
-        index++;
-    }
-    *nb_vm_out = index;
+        memcpy(&(ptr[idx].uuid), info[i].handle, sizeof(xen_domain_handle_t));
+        ptr[idx].domid = info[i].domain;
+
+        idx++;
+    }
+    *nb_vm_out = idx;
     return ptr;
 }
 
@@ -3354,7 +3354,7 @@ int libxl_set_memory_target(libxl_ctx *c
         int32_t target_memkb, int relative, int enforce)
 {
     GC_INIT(ctx);
-    int rc = 1, abort = 0;
+    int rc = 1, abort_transaction = 0;
     uint32_t memorykb = 0, videoram = 0;
     uint32_t current_target_memkb = 0, new_target_memkb = 0;
     char *memmax, *endptr, *videoram_s = NULL, *target = NULL;
@@ -3373,7 +3373,7 @@ retry_transaction:
         xs_transaction_end(ctx->xsh, t, 1);
         rc = libxl__fill_dom0_memory_info(gc, &current_target_memkb);
         if (rc < 0) {
-            abort = 1;
+            abort_transaction = 1;
             goto out;
         }
         goto retry_transaction;
@@ -3381,7 +3381,7 @@ retry_transaction:
         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR,
                 "cannot get target memory info from %s/memory/target\n",
                 dompath);
-        abort = 1;
+        abort_transaction = 1;
         goto out;
     } else {
         current_target_memkb = strtoul(target, &endptr, 10);
@@ -3389,7 +3389,7 @@ retry_transaction:
             LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR,
                     "invalid memory target %s from %s/memory/target\n",
                     target, dompath);
-            abort = 1;
+            abort_transaction = 1;
             goto out;
         }
     }
@@ -3399,7 +3399,7 @@ retry_transaction:
         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR,
                 "cannot get memory info from %s/memory/static-max\n",
                 dompath);
-        abort = 1;
+        abort_transaction = 1;
         goto out;
     }
     memorykb = strtoul(memmax, &endptr, 10);
@@ -3407,7 +3407,7 @@ retry_transaction:
         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR,
                 "invalid max memory %s from %s/memory/static-max\n",
                 memmax, dompath);
-        abort = 1;
+        abort_transaction = 1;
         goto out;
     }
 
@@ -3422,7 +3422,7 @@ retry_transaction:
         LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
                 "memory_dynamic_max must be less than or equal to"
                 " memory_static_max\n");
-        abort = 1;
+        abort_transaction = 1;
         goto out;
     }
 
@@ -3430,7 +3430,7 @@ retry_transaction:
         LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
                 "new target %d for dom0 is below the minimum threshold\n",
                  new_target_memkb);
-        abort = 1;
+        abort_transaction = 1;
         goto out;
     }
     videoram_s = libxl__xs_read(gc, t, libxl__sprintf(gc,
@@ -3445,7 +3445,7 @@ retry_transaction:
             LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR,
                     "xc_domain_setmaxmem domid=%d memkb=%d failed "
                     "rc=%d\n", domid, memorykb + LIBXL_MAXMEM_CONSTANT, rc);
-            abort = 1;
+            abort_transaction = 1;
             goto out;
         }
     }
@@ -3458,7 +3458,7 @@ retry_transaction:
                 "xc_domain_set_pod_target domid=%d, memkb=%d "
                 "failed rc=%d\n", domid, new_target_memkb / 4,
                 rc);
-        abort = 1;
+        abort_transaction = 1;
         goto out;
     }
 
@@ -3466,7 +3466,7 @@ retry_transaction:
                 dompath), "%"PRIu32, new_target_memkb);
     rc = xc_domain_getinfolist(ctx->xch, domid, 1, &info);
     if (rc != 1 || info.domain != domid) {
-        abort = 1;
+        abort_transaction = 1;
         goto out;
     }
     xcinfo2xlinfo(&info, &ptr);
@@ -3475,7 +3475,8 @@ retry_transaction:
             "%"PRIu32, new_target_memkb / 1024);
 
 out:
-    if (!xs_transaction_end(ctx->xsh, t, abort) && !abort)
+    if (!xs_transaction_end(ctx->xsh, t, abort_transaction)
+        && !abort_transaction)
         if (errno == EAGAIN)
             goto retry_transaction;
 
diff -r 0547430886c5 -r 58ab3fb73d13 tools/libxl/libxl_dm.c
--- a/tools/libxl/libxl_dm.c	Fri Sep 14 11:00:40 2012 +0100
+++ b/tools/libxl/libxl_dm.c	Fri Sep 14 12:09:43 2012 +0100
@@ -379,7 +379,7 @@ static char ** libxl__build_device_model
     }
     if (vnc) {
         int display = 0;
-        const char *listen = "127.0.0.1";
+        const char *addr = "127.0.0.1";
         char *vncarg = NULL;
 
         flexarray_append(dm_args, "-vnc");
@@ -387,16 +387,16 @@ static char ** libxl__build_device_model
         if (vnc->display) {
             display = vnc->display;
             if (vnc->listen && strchr(vnc->listen, ':') == NULL) {
-                listen = vnc->listen;
+                addr = vnc->listen;
             }
         } else if (vnc->listen) {
-            listen = vnc->listen;
+            addr = vnc->listen;
         }
 
-        if (strchr(listen, ':') != NULL)
-            vncarg = libxl__sprintf(gc, "%s", listen);
+        if (strchr(addr, ':') != NULL)
+            vncarg = libxl__sprintf(gc, "%s", addr);
         else
-            vncarg = libxl__sprintf(gc, "%s:%d", listen, display);
+            vncarg = libxl__sprintf(gc, "%s:%d", addr, display);
         if (vnc->passwd && vnc->passwd[0]) {
             vncarg = libxl__sprintf(gc, "%s,password", vncarg);
         }
diff -r 0547430886c5 -r 58ab3fb73d13 tools/libxl/libxl_event.c
--- a/tools/libxl/libxl_event.c	Fri Sep 14 11:00:40 2012 +0100
+++ b/tools/libxl/libxl_event.c	Fri Sep 14 12:09:43 2012 +0100
@@ -167,15 +167,15 @@ static void time_insert_finite(libxl__gc
 }
 
 static int time_register_finite(libxl__gc *gc, libxl__ev_time *ev,
-                                struct timeval abs)
+                                struct timeval absolute)
 {
     int rc;
 
-    rc = OSEVENT_HOOK(timeout_register, &ev->for_app_reg, abs, ev);
+    rc = OSEVENT_HOOK(timeout_register, &ev->for_app_reg, absolute, ev);
     if (rc) return rc;
 
     ev->infinite = 0;
-    ev->abs = abs;
+    ev->abs = absolute;
     time_insert_finite(gc, ev);
 
     return 0;
@@ -202,16 +202,16 @@ static void time_done_debug(libxl__gc *g
 
 int libxl__ev_time_register_abs(libxl__gc *gc, libxl__ev_time *ev,
                                 libxl__ev_time_callback *func,
-                                struct timeval abs)
+                                struct timeval absolute)
 {
     int rc;
 
     CTX_LOCK;
 
     DBG("ev_time=%p register abs=%lu.%06lu",
-        ev, (unsigned long)abs.tv_sec, (unsigned long)abs.tv_usec);
+        ev, (unsigned long)absolute.tv_sec, (unsigned long)absolute.tv_usec);
 
-    rc = time_register_finite(gc, ev, abs);
+    rc = time_register_finite(gc, ev, absolute);
     if (rc) goto out;
 
     ev->func = func;
@@ -228,7 +228,7 @@ int libxl__ev_time_register_rel(libxl__g
                                 libxl__ev_time_callback *func,
                                 int milliseconds /* as for poll(2) */)
 {
-    struct timeval abs;
+    struct timeval absolute;
     int rc;
 
     CTX_LOCK;
@@ -238,10 +238,10 @@ int libxl__ev_time_register_rel(libxl__g
     if (milliseconds < 0) {
         ev->infinite = 1;
     } else {
-        rc = time_rel_to_abs(gc, milliseconds, &abs);
+        rc = time_rel_to_abs(gc, milliseconds, &absolute);
         if (rc) goto out;
 
-        rc = time_register_finite(gc, ev, abs);
+        rc = time_register_finite(gc, ev, absolute);
         if (rc) goto out;
     }
 
@@ -255,26 +255,26 @@ int libxl__ev_time_register_rel(libxl__g
 }
 
 int libxl__ev_time_modify_abs(libxl__gc *gc, libxl__ev_time *ev,
-                              struct timeval abs)
+                              struct timeval absolute)
 {
     int rc;
 
     CTX_LOCK;
 
     DBG("ev_time=%p modify abs==%lu.%06lu",
-        ev, (unsigned long)abs.tv_sec, (unsigned long)abs.tv_usec);
+        ev, (unsigned long)absolute.tv_sec, (unsigned long)absolute.tv_usec);
 
     assert(libxl__ev_time_isregistered(ev));
 
     if (ev->infinite) {
-        rc = time_register_finite(gc, ev, abs);
+        rc = time_register_finite(gc, ev, absolute);
         if (rc) goto out;
     } else {
-        rc = OSEVENT_HOOK(timeout_modify, &ev->for_app_reg, abs);
+        rc = OSEVENT_HOOK(timeout_modify, &ev->for_app_reg, absolute);
         if (rc) goto out;
 
         LIBXL_TAILQ_REMOVE(&CTX->etimes, ev, entry);
-        ev->abs = abs;
+        ev->abs = absolute;
         time_insert_finite(gc, ev);
     }
 
@@ -288,7 +288,7 @@ int libxl__ev_time_modify_abs(libxl__gc 
 int libxl__ev_time_modify_rel(libxl__gc *gc, libxl__ev_time *ev,
                               int milliseconds)
 {
-    struct timeval abs;
+    struct timeval absolute;
     int rc;
 
     CTX_LOCK;
@@ -304,10 +304,10 @@ int libxl__ev_time_modify_rel(libxl__gc 
         goto out;
     }
 
-    rc = time_rel_to_abs(gc, milliseconds, &abs);
+    rc = time_rel_to_abs(gc, milliseconds, &absolute);
     if (rc) goto out;
 
-    rc = libxl__ev_time_modify_abs(gc, ev, abs);
+    rc = libxl__ev_time_modify_abs(gc, ev, absolute);
     if (rc) goto out;
 
     rc = 0;
diff -r 0547430886c5 -r 58ab3fb73d13 tools/libxl/libxl_exec.c
--- a/tools/libxl/libxl_exec.c	Fri Sep 14 11:00:40 2012 +0100
+++ b/tools/libxl/libxl_exec.c	Fri Sep 14 12:09:43 2012 +0100
@@ -35,7 +35,7 @@ static void check_open_fds(const char *w
 #ifdef __linux__
         size_t len;
         char path[PATH_MAX];
-        char link[PATH_MAX+1];
+        char linkpath[PATH_MAX+1];
 #endif
         flags = fcntl(i, F_GETFD);
         if ( flags == -1 ) {
@@ -52,11 +52,11 @@ static void check_open_fds(const char *w
 
 #ifdef __linux__
         snprintf(path, PATH_MAX, "/proc/%d/fd/%d", getpid(), i);
-        len = readlink(path, link, PATH_MAX);
+        len = readlink(path, linkpath, PATH_MAX);
         if (len > 0) {
-            link[len] = '\0';
+            linkpath[len] = '\0';
             fprintf(stderr, "libxl: execing %s: fd %d is open to %s with flags %#x\n",
-                    what, i, link, flags);
+                    what, i, linkpath, flags);
         } else
 #endif
             fprintf(stderr, "libxl: execing %s: fd %d is open with flags %#x\n",
diff -r 0547430886c5 -r 58ab3fb73d13 tools/libxl/libxl_json.c
--- a/tools/libxl/libxl_json.c	Fri Sep 14 11:00:40 2012 +0100
+++ b/tools/libxl/libxl_json.c	Fri Sep 14 12:09:43 2012 +0100
@@ -275,7 +275,7 @@ static int json_object_append_to(libxl__
 
 void libxl__json_object_free(libxl__gc *gc, libxl__json_object *obj)
 {
-    int index = 0;
+    int idx = 0;
 
     if (obj == NULL)
         return;
@@ -287,8 +287,8 @@ void libxl__json_object_free(libxl__gc *
     case JSON_MAP: {
         libxl__json_map_node *node = NULL;
 
-        for (index = 0; index < obj->u.map->count; index++) {
-            if (flexarray_get(obj->u.map, index, (void**)&node) != 0)
+        for (idx = 0; idx < obj->u.map->count; idx++) {
+            if (flexarray_get(obj->u.map, idx, (void**)&node) != 0)
                 break;
             libxl__json_object_free(gc, node->obj);
             free(node->map_key);
@@ -302,8 +302,8 @@ void libxl__json_object_free(libxl__gc *
         libxl__json_object *node = NULL;
         break;
 
-        for (index = 0; index < obj->u.array->count; index++) {
-            if (flexarray_get(obj->u.array, index, (void**)&node) != 0)
+        for (idx = 0; idx < obj->u.array->count; idx++) {
+            if (flexarray_get(obj->u.array, idx, (void**)&node) != 0)
                 break;
             libxl__json_object_free(gc, node);
             node = NULL;
@@ -359,14 +359,14 @@ const libxl__json_object *libxl__json_ma
                                           libxl__json_node_type expected_type)
 {
     flexarray_t *maps = NULL;
-    int index = 0;
+    int idx = 0;
 
     if (libxl__json_object_is_map(o)) {
         libxl__json_map_node *node = NULL;
 
         maps = o->u.map;
-        for (index = 0; index < maps->count; index++) {
-            if (flexarray_get(maps, index, (void**)&node) != 0)
+        for (idx = 0; idx < maps->count; idx++) {
+            if (flexarray_get(maps, idx, (void**)&node) != 0)
                 return NULL;
             if (strcmp(key, node->map_key) == 0) {
                 if (expected_type == JSON_ANY
diff -r 0547430886c5 -r 58ab3fb73d13 tools/libxl/libxl_pci.c
--- a/tools/libxl/libxl_pci.c	Fri Sep 14 11:00:40 2012 +0100
+++ b/tools/libxl/libxl_pci.c	Fri Sep 14 12:09:43 2012 +0100
@@ -167,7 +167,6 @@ static int libxl__device_pci_remove_xens
     char *be_path, *num_devs_path, *num_devs, *xsdev, *tmp, *tmppath;
     int num, i, j;
     xs_transaction_t t;
-    unsigned int domain = 0, bus = 0, dev = 0, func = 0;
 
     be_path = libxl__sprintf(gc, "%s/backend/pci/%d/0", libxl__xs_get_dompath(gc, 0), domid);
     num_devs_path = libxl__sprintf(gc, "%s/num_devs", be_path);
@@ -188,6 +187,7 @@ static int libxl__device_pci_remove_xens
     }
 
     for (i = 0; i < num; i++) {
+        unsigned int domain = 0, bus = 0, dev = 0, func = 0;
         xsdev = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/dev-%d", be_path, i));
         sscanf(xsdev, PCI_BDF, &domain, &bus, &dev, &func);
         if (domain == pcidev->domain && bus == pcidev->bus &&
diff -r 0547430886c5 -r 58ab3fb73d13 tools/libxl/libxl_qmp.c
--- a/tools/libxl/libxl_qmp.c	Fri Sep 14 11:00:40 2012 +0100
+++ b/tools/libxl/libxl_qmp.c	Fri Sep 14 12:09:43 2012 +0100
@@ -171,7 +171,7 @@ static int qmp_register_vnc_callback(lib
 {
     GC_INIT(qmp->ctx);
     const libxl__json_object *obj;
-    const char *listen, *port;
+    const char *addr, *port;
     int rc = -1;
 
     if (!libxl__json_object_is_map(o)) {
@@ -184,17 +184,17 @@ static int qmp_register_vnc_callback(lib
     }
 
     obj = libxl__json_map_get("host", o, JSON_STRING);
-    listen = libxl__json_object_get_string(obj);
+    addr = libxl__json_object_get_string(obj);
     obj = libxl__json_map_get("service", o, JSON_STRING);
     port = libxl__json_object_get_string(obj);
 
-    if (!listen || !port) {
+    if (!addr || !port) {
         LIBXL__LOG(qmp->ctx, LIBXL__LOG_ERROR,
                    "Failed to retreive VNC connect information.");
         goto out;
     }
 
-    rc = qmp_write_domain_console_item(gc, qmp->domid, "vnc-listen", listen);
+    rc = qmp_write_domain_console_item(gc, qmp->domid, "vnc-listen", addr);
     if (!rc)
         rc = qmp_write_domain_console_item(gc, qmp->domid, "vnc-port", port);
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 14 12:42:51 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 12: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 1TCVEC-0001wQ-9D; Fri, 14 Sep 2012 12:42:36 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1TCVEA-0001vc-Dl
	for xen-devel@lists.xen.org; Fri, 14 Sep 2012 12:42:34 +0000
Received: from [85.158.139.83:19611] by server-9.bemta-5.messagelabs.com id
	76/3B-20529-A3623505; Fri, 14 Sep 2012 12:42:34 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1347626549!16426476!3
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNjk2MTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21618 invoked from network); 14 Sep 2012 12:42:32 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-8.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Sep 2012 12:42:32 -0000
X-IronPort-AV: E=Sophos;i="4.80,422,1344211200"; d="scan'208";a="37881298"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Sep 2012 12:42:29 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Fri, 14 Sep 2012 08:42:29 -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 1TCVE4-0007Ic-VF;
	Fri, 14 Sep 2012 13:42:28 +0100
MIME-Version: 1.0
X-Mercurial-Node: 8fad3481f8c90bb66fff4973b4c5653ebb7ca52e
Message-ID: <8fad3481f8c90bb66fff.1347626551@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1347626548@cosworth.uk.xensource.com>
References: <patchbomb.1347626548@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Fri, 14 Sep 2012 13:42:31 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 3 of 3] xl: Remove global domid and enable
	-Wshadow
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 1347626449 -3600
# Node ID 8fad3481f8c90bb66fff4973b4c5653ebb7ca52e
# Parent  192e4a16a057a456cc78e4ee46242315d474d116
xl: Remove global domid and enable -Wshadow

Lots of functions loop over a list of domain and others take a domid as
a parameter, shadowing the global one and leading to all sorts of
confusion.

Therefore remove the global domid and explicitly pass it around as
necessary.

Adds a domid to the parameters for many functions and switches many
others from taking a char * domain specifier to taking a domid, pushing
the domid lookup to the toplevel.

Replaces some open-coded domain_qualifier_to_domid error checking with
find_domain.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---

I find it hard to believe I won't have broken anything here... I tested
basic lifecycle ops only.

diff -r 192e4a16a057 -r 8fad3481f8c9 tools/libxl/Makefile
--- a/tools/libxl/Makefile	Fri Sep 14 12:21:24 2012 +0100
+++ b/tools/libxl/Makefile	Fri Sep 14 13:40:49 2012 +0100
@@ -89,10 +89,13 @@ LIBXLU_OBJS = libxlu_cfg_y.o libxlu_cfg_
 
 CLIENTS = xl testidl libxl-save-helper
 
+CFLAGS_XL += $(CFLAGS_libxenlight)
+CFLAGS_XL += -Wshadow
+
 XL_OBJS = xl.o xl_cmdimpl.o xl_cmdtable.o xl_sxp.o
 $(XL_OBJS) _libxl.api-for-check: \
             CFLAGS += $(CFLAGS_libxenctrl) # For xentoollog.h
-$(XL_OBJS): CFLAGS += $(CFLAGS_libxenlight)
+$(XL_OBJS): CFLAGS += $(CFLAGS_XL)
 $(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
diff -r 192e4a16a057 -r 8fad3481f8c9 tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Fri Sep 14 12:21:24 2012 +0100
+++ b/tools/libxl/xl_cmdimpl.c	Fri Sep 14 13:40:49 2012 +0100
@@ -67,9 +67,7 @@ libxl_ctx *ctx;
 
 xlchild children[child_max];
 
-/* when we operate on a domain, it is this one: */
 #define INVALID_DOMID ~0
-static uint32_t domid = INVALID_DOMID;
 static const char *common_domname;
 static int fd_lock = -1;
 
@@ -197,8 +195,9 @@ static int cpupool_qualifier_to_cpupooli
     return was_name ? libxl_name_to_cpupoolid(ctx, p, poolid_r) : 0;
 }
 
-static void find_domain(const char *p)
-{
+static uint32_t find_domain(const char *p)
+{
+    uint32_t domid;
     int rc, was_name;
 
     rc = domain_qualifier_to_domid(p, &domid, &was_name);
@@ -207,6 +206,7 @@ static void find_domain(const char *p)
         exit(2);
     }
     common_domname = was_name ? p : libxl_domid_to_name(ctx, domid);
+    return domid;
 }
 
 static int vncviewer(uint32_t domid, int autopass)
@@ -1590,7 +1590,7 @@ static int preserve_domain(uint32_t *r_d
     return rc == 0 ? 1 : 0;
 }
 
-static int freemem(libxl_domain_build_info *b_info)
+static int freemem(uint32_t domid, libxl_domain_build_info *b_info)
 {
     int rc, retries = 3;
     uint32_t need_memkb, free_memkb;
@@ -1670,7 +1670,7 @@ static void autoconnect_console(libxl_ct
     _exit(1);
 }
 
-static int domain_wait_event(libxl_event **event_r)
+static int domain_wait_event(uint32_t domid, libxl_event **event_r)
 {
     int ret;
     for (;;) {
@@ -1704,8 +1704,10 @@ static void evdisable_disk_ejects(libxl_
     }
 }
 
-static int create_domain(struct domain_create *dom_info)
-{
+static uint32_t create_domain(struct domain_create *dom_info)
+{
+    uint32_t domid = INVALID_DOMID;
+
     libxl_domain_config d_config;
 
     int debug = dom_info->debug;
@@ -1881,7 +1883,7 @@ start:
     if (rc < 0)
         goto error_out;
 
-    ret = freemem(&d_config.b_info);
+    ret = freemem(domid, &d_config.b_info);
     if (ret < 0) {
         fprintf(stderr, "failed to free memory for the domain\n");
         ret = ERROR_FAIL;
@@ -2031,7 +2033,7 @@ start:
     }
     while (1) {
         libxl_event *event;
-        ret = domain_wait_event(&event);
+        ret = domain_wait_event(domid, &event);
         if (ret) goto out;
 
         switch (event->type) {
@@ -2243,13 +2245,11 @@ static int def_getopt(int argc, char * c
     return -1;
 }
 
-static int set_memory_max(const char *p, const char *mem)
+static int set_memory_max(uint32_t domid, const char *mem)
 {
     int64_t memorykb;
     int rc;
 
-    find_domain(p);
-
     memorykb = parse_mem_size_kb(mem);
     if (memorykb == -1) {
         fprintf(stderr, "invalid memory size: %s\n", mem);
@@ -2263,17 +2263,18 @@ static int set_memory_max(const char *p,
 
 int main_memmax(int argc, char **argv)
 {
+    uint32_t domid;
     int opt = 0;
-    char *p = NULL, *mem;
+    char *mem;
     int rc;
 
     if ((opt = def_getopt(argc, argv, "", "mem-max", 2)) != -1)
         return opt;
 
-    p = argv[optind];
+    domid = find_domain(argv[optind]);
     mem = argv[optind + 1];
 
-    rc = set_memory_max(p, mem);
+    rc = set_memory_max(domid, mem);
     if (rc) {
         fprintf(stderr, "cannot set domid %d static max memory to : %s\n", domid, mem);
         return 1;
@@ -2282,12 +2283,10 @@ int main_memmax(int argc, char **argv)
     return 0;
 }
 
-static void set_memory_target(const char *p, const char *mem)
+static void set_memory_target(uint32_t domid, const char *mem)
 {
     long long int memorykb;
 
-    find_domain(p);
-
     memorykb = parse_mem_size_kb(mem);
     if (memorykb == -1)  {
         fprintf(stderr, "invalid memory size: %s\n", mem);
@@ -2299,26 +2298,26 @@ static void set_memory_target(const char
 
 int main_memset(int argc, char **argv)
 {
+    uint32_t domid;
     int opt = 0;
-    const char *p = NULL, *mem;
+    const char *mem;
 
     if ((opt = def_getopt(argc, argv, "", "mem-set", 2)) != -1)
         return opt;
 
-    p = argv[optind];
+    domid = find_domain(argv[optind]);
     mem = argv[optind + 1];
 
-    set_memory_target(p, mem);
+    set_memory_target(domid, mem);
     return 0;
 }
 
-static void cd_insert(const char *dom, const char *virtdev, char *phys)
+static void cd_insert(uint32_t domid, const char *virtdev, char *phys)
 {
     libxl_device_disk disk; /* we don't free disk's contents */
     char *buf = NULL;
     XLU_Config *config = 0;
 
-    find_domain(dom);
 
     if (asprintf(&buf, "vdev=%s,access=r,devtype=cdrom,target=%s",
                  virtdev, phys ? phys : "") < 0) {
@@ -2338,38 +2337,41 @@ static void cd_insert(const char *dom, c
 
 int main_cd_eject(int argc, char **argv)
 {
+    uint32_t domid;
     int opt = 0;
-    const char *p = NULL, *virtdev;
+    const char *virtdev;
 
     if ((opt = def_getopt(argc, argv, "", "cd-eject", 2)) != -1)
         return opt;
 
-    p = argv[optind];
+    domid = find_domain(argv[optind]);
     virtdev = argv[optind + 1];
 
-    cd_insert(p, virtdev, NULL);
+    cd_insert(domid, virtdev, NULL);
     return 0;
 }
 
 int main_cd_insert(int argc, char **argv)
 {
+    uint32_t domid;
     int opt = 0;
-    const char *p = NULL, *virtdev;
+    const char *virtdev;
     char *file = NULL; /* modified by cd_insert tokenising it */
 
     if ((opt = def_getopt(argc, argv, "", "cd-insert", 3)) != -1)
         return opt;
 
-    p = argv[optind];
+    domid = find_domain(argv[optind]);
     virtdev = argv[optind + 1];
     file = argv[optind + 2];
 
-    cd_insert(p, virtdev, file);
+    cd_insert(domid, virtdev, file);
     return 0;
 }
 
 int main_console(int argc, char **argv)
 {
+    uint32_t domid;
     int opt = 0, num = 0;
     libxl_console_type type = 0;
 
@@ -2393,7 +2395,7 @@ int main_console(int argc, char **argv)
         }
     }
 
-    find_domain(argv[optind]);
+    domid = find_domain(argv[optind]);
     if (!type)
         libxl_primary_console_exec(ctx, domid);
     else
@@ -2410,6 +2412,7 @@ int main_vncviewer(int argc, char **argv
         {"help", 0, 0, 'h'},
         {0, 0, 0, 0}
     };
+    uint32_t domid;
     int opt, autopass = 0;
 
     while (1) {
@@ -2435,20 +2438,18 @@ int main_vncviewer(int argc, char **argv
         return 2;
     }
 
-    find_domain(argv[optind]);
+    domid = find_domain(argv[optind]);
 
     if (vncviewer(domid, autopass))
         return 1;
     return 0;
 }
 
-static void pcilist(const char *dom)
+static void pcilist(uint32_t domid)
 {
     libxl_device_pci *pcidevs;
     int num, i;
 
-    find_domain(dom);
-
     pcidevs = libxl_device_pci_list(ctx, domid, &num);
     if (pcidevs == NULL)
         return;
@@ -2464,27 +2465,25 @@ static void pcilist(const char *dom)
 
 int main_pcilist(int argc, char **argv)
 {
+    uint32_t domid;
     int opt;
-    const char *domname = NULL;
 
     if ((opt = def_getopt(argc, argv, "", "pci-list", 1)) != -1)
         return opt;
 
-    domname = argv[optind];
-
-    pcilist(domname);
+    domid = find_domain(argv[optind]);
+
+    pcilist(domid);
     return 0;
 }
 
-static void pcidetach(const char *dom, const char *bdf, int force)
+static void pcidetach(uint32_t domid, const char *bdf, int force)
 {
     libxl_device_pci pcidev;
     XLU_Config *config;
 
-    find_domain(dom);
-
     libxl_device_pci_init(&pcidev);
-    
+
     config = xlu_cfg_init(stderr, "command line");
     if (!config) { perror("xlu_cfg_inig"); exit(-1); }
 
@@ -2503,9 +2502,10 @@ static void pcidetach(const char *dom, c
 
 int main_pcidetach(int argc, char **argv)
 {
+    uint32_t domid;
     int opt;
     int force = 0;
-    const char *domname = NULL, *bdf = NULL;
+    const char *bdf = NULL;
 
     while ((opt = def_getopt(argc, argv, "f", "pci-detach", 2)) != -1) {
         switch (opt) {
@@ -2517,19 +2517,17 @@ int main_pcidetach(int argc, char **argv
         }
     }
 
-    domname = argv[optind];
+    domid = find_domain(argv[optind]);
     bdf = argv[optind + 1];
 
-    pcidetach(domname, bdf, force);
+    pcidetach(domid, bdf, force);
     return 0;
 }
-static void pciattach(const char *dom, const char *bdf, const char *vs)
+static void pciattach(uint32_t domid, const char *bdf, const char *vs)
 {
     libxl_device_pci pcidev;
     XLU_Config *config;
 
-    find_domain(dom);
-
     libxl_device_pci_init(&pcidev);
 
     config = xlu_cfg_init(stderr, "command line");
@@ -2547,19 +2545,20 @@ static void pciattach(const char *dom, c
 
 int main_pciattach(int argc, char **argv)
 {
+    uint32_t domid;
     int opt;
-    const char *domname = NULL, *bdf = NULL, *vs = NULL;
+    const char *bdf = NULL, *vs = NULL;
 
     if ((opt = def_getopt(argc, argv, "", "pci-attach", 2)) != -1)
         return opt;
 
-    domname = argv[optind];
+    domid = find_domain(argv[optind]);
     bdf = argv[optind + 1];
 
     if (optind + 1 < argc)
         vs = argv[optind + 2];
 
-    pciattach(domname, bdf, vs);
+    pciattach(domid, bdf, vs);
     return 0;
 }
 
@@ -2671,22 +2670,20 @@ int main_pciassignable_remove(int argc, 
     return 0;
 }
 
-static void pause_domain(const char *p)
-{
-    find_domain(p);
+static void pause_domain(uint32_t domid)
+{
     libxl_domain_pause(ctx, domid);
 }
 
-static void unpause_domain(const char *p)
-{
-    find_domain(p);
+static void unpause_domain(uint32_t domid)
+{
     libxl_domain_unpause(ctx, domid);
 }
 
-static void destroy_domain(const char *p)
+static void destroy_domain(uint32_t domid)
 {
     int rc;
-    find_domain(p);
+
     if (domid == 0) {
         fprintf(stderr, "Cannot destroy privileged domain 0.\n\n");
         exit(-1);
@@ -2695,13 +2692,12 @@ static void destroy_domain(const char *p
     if (rc) { fprintf(stderr,"destroy failed (rc=%d)\n",rc); exit(-1); }
 }
 
-static void shutdown_domain(const char *p, int wait_for_it,
+static void shutdown_domain(uint32_t domid, int wait_for_it,
                             int fallback_trigger)
 {
     int rc;
     libxl_event *event;
 
-    find_domain(p);
     rc=libxl_domain_shutdown(ctx, domid);
     if (rc == ERROR_NOPARAVIRT) {
         if (fallback_trigger) {
@@ -2728,7 +2724,7 @@ static void shutdown_domain(const char *
         }
 
         for (;;) {
-            rc = domain_wait_event(&event);
+            rc = domain_wait_event(domid, &event);
             if (rc) exit(-1);
 
             switch (event->type) {
@@ -2755,10 +2751,10 @@ static void shutdown_domain(const char *
     }
 }
 
-static void reboot_domain(const char *p, int fallback_trigger)
+static void reboot_domain(uint32_t domid, int fallback_trigger)
 {
     int rc;
-    find_domain(p);
+
     rc=libxl_domain_reboot(ctx, domid);
     if (rc == ERROR_NOPARAVIRT) {
         if (fallback_trigger) {
@@ -2815,7 +2811,7 @@ static void list_domains_details(const l
         if (default_output_format == OUTPUT_FORMAT_JSON)
             s = printf_info_one_json(hand, info[i].domid, &d_config);
         else
-            printf_info_sexp(domid, &d_config);
+            printf_info_sexp(info[i].domid, &d_config);
         libxl_domain_config_dispose(&d_config);
         free(data);
         free(config_source);
@@ -2917,15 +2913,13 @@ static void list_vm(void)
     libxl_vminfo_list_free(info, nb_vm);
 }
 
-static void save_domain_core_begin(const char *domain_spec,
+static void save_domain_core_begin(uint32_t domid,
                                    const char *override_config_file,
                                    uint8_t **config_data_r,
                                    int *config_len_r)
 {
     int rc;
 
-    find_domain(domain_spec);
-
     /* configuration file in optional data: */
 
     if (override_config_file) {
@@ -2982,14 +2976,15 @@ static void save_domain_core_writeconfig
             hdr.optional_data_len);
 }
 
-static int save_domain(const char *p, const char *filename, int checkpoint,
+static int save_domain(uint32_t domid, const char *filename, int checkpoint,
                 const char *override_config_file)
 {
     int fd;
     uint8_t *config_data;
     int config_len;
 
-    save_domain_core_begin(p, override_config_file, &config_data, &config_len);
+    save_domain_core_begin(domid, override_config_file,
+                           &config_data, &config_len);
 
     if (!config_len) {
         fputs(" Savefile will not contain xl domain config\n", stderr);
@@ -3159,7 +3154,7 @@ static void migrate_do_preamble(int send
 
 }
 
-static void migrate_domain(const char *domain_spec, const char *rune,
+static void migrate_domain(uint32_t domid, const char *rune,
                            const char *override_config_file)
 {
     pid_t child = -1;
@@ -3170,7 +3165,7 @@ static void migrate_domain(const char *d
     uint8_t *config_data;
     int config_len;
 
-    save_domain_core_begin(domain_spec, override_config_file,
+    save_domain_core_begin(domid, override_config_file,
                            &config_data, &config_len);
 
     if (!config_len) {
@@ -3297,10 +3292,10 @@ static void migrate_domain(const char *d
     exit(-ERROR_BADFAIL);
 }
 
-static void core_dump_domain(const char *domain_spec, const char *filename)
+static void core_dump_domain(uint32_t domid, const char *filename)
 {
     int rc;
-    find_domain(domain_spec);
+
     rc=libxl_domain_core_dump(ctx, domid, filename, NULL);
     if (rc) { fprintf(stderr,"core dump failed (rc=%d)\n",rc);exit(-1); }
 }
@@ -3308,6 +3303,7 @@ static void core_dump_domain(const char 
 static void migrate_receive(int debug, int daemonize, int monitor,
                             int send_fd, int recv_fd, int remus)
 {
+    uint32_t domid;
     int rc, rc2;
     char rc_buf;
     char *migration_domname;
@@ -3339,6 +3335,8 @@ static void migrate_receive(int debug, i
         exit(-rc);
     }
 
+    domid = rc;
+
     if (remus) {
         /* If we are here, it means that the sender (primary) has crashed.
          * TODO: Split-Brain Check.
@@ -3557,7 +3555,8 @@ int main_migrate_receive(int argc, char 
 
 int main_save(int argc, char **argv)
 {
-    const char *filename, *p;
+    uint32_t domid;
+    const char *filename;
     const char *config_filename = NULL;
     int checkpoint = 0;
     int opt;
@@ -3577,18 +3576,18 @@ int main_save(int argc, char **argv)
         return 2;
     }
 
-    p = argv[optind];
+    domid = find_domain(argv[optind]);
     filename = argv[optind + 1];
     if ( argc - optind >= 3 )
         config_filename = argv[optind + 2];
 
-    save_domain(p, filename, checkpoint, config_filename);
+    save_domain(domid, filename, checkpoint, config_filename);
     return 0;
 }
 
 int main_migrate(int argc, char **argv)
 {
-    const char *p = NULL;
+    uint32_t domid;
     const char *config_filename = NULL;
     const char *ssh_command = "ssh";
     char *rune = NULL;
@@ -3618,7 +3617,7 @@ int main_migrate(int argc, char **argv)
         }
     }
 
-    p = argv[optind];
+    domid = find_domain(argv[optind]);
     host = argv[optind + 1];
 
     if (!ssh_command[0]) {
@@ -3631,7 +3630,7 @@ int main_migrate(int argc, char **argv)
             return 1;
     }
 
-    migrate_domain(p, rune, config_filename);
+    migrate_domain(domid, rune, config_filename);
     return 0;
 }
 
@@ -3642,7 +3641,7 @@ int main_dump_core(int argc, char **argv
     if ((opt = def_getopt(argc, argv, "", "dump-core", 2)) != -1)
         return opt;
 
-    core_dump_domain(argv[optind], argv[optind + 1]);
+    core_dump_domain(find_domain(argv[optind]), argv[optind + 1]);
     return 0;
 }
 
@@ -3653,7 +3652,7 @@ int main_pause(int argc, char **argv)
     if ((opt = def_getopt(argc, argv, "", "pause", 1)) != -1)
         return opt;
 
-    pause_domain(argv[optind]);
+    pause_domain(find_domain(argv[optind]));
 
     return 0;
 }
@@ -3665,7 +3664,7 @@ int main_unpause(int argc, char **argv)
     if ((opt = def_getopt(argc, argv, "", "unpause", 1)) != -1)
         return opt;
 
-    unpause_domain(argv[optind]);
+    unpause_domain(find_domain(argv[optind]));
 
     return 0;
 }
@@ -3677,7 +3676,7 @@ int main_destroy(int argc, char **argv)
     if ((opt = def_getopt(argc, argv, "", "destroy", 1)) != -1)
         return opt;
 
-    destroy_domain(argv[optind]);
+    destroy_domain(find_domain(argv[optind]));
     return 0;
 }
 
@@ -3700,7 +3699,7 @@ int main_shutdown(int argc, char **argv)
         }
     }
 
-    shutdown_domain(argv[optind], wait_for_it, fallback_trigger);
+    shutdown_domain(find_domain(argv[optind]), wait_for_it, fallback_trigger);
     return 0;
 }
 
@@ -3719,7 +3718,7 @@ int main_reboot(int argc, char **argv)
         }
     }
 
-    reboot_domain(argv[optind], fallback_trigger);
+    reboot_domain(find_domain(argv[optind]), fallback_trigger);
     return 0;
 }
 
@@ -3773,7 +3772,7 @@ int main_list(int argc, char **argv)
         }
         info_free = info;
     } else if (optind == argc-1) {
-        find_domain(argv[optind]);
+        uint32_t domid = find_domain(argv[optind]);
         rc = libxl_domain_info(ctx, &info_buf, domid);
         if (rc == ERROR_INVAL) {
             fprintf(stderr, "Error: Domain \'%s\' does not exist.\n",
@@ -3922,6 +3921,7 @@ int main_create(int argc, char **argv)
 
 int main_config_update(int argc, char **argv)
 {
+    uint32_t domid;
     const char *filename = NULL;
     char *p;
     char extra_config[1024];
@@ -3943,7 +3943,7 @@ int main_config_update(int argc, char **
         exit(1);
     }
 
-    find_domain(argv[1]);
+    domid = find_domain(argv[1]);
     argc--; argv++;
 
     if (argv[1] && argv[1][0] != '-' && !strchr(argv[1], '=')) {
@@ -4034,12 +4034,10 @@ int main_config_update(int argc, char **
     return 0;
 }
 
-static void button_press(const char *p, const char *b)
+static void button_press(uint32_t domid, const char *b)
 {
     libxl_trigger trigger;
 
-    find_domain(p);
-
     if (!strcmp(b, "power")) {
         trigger = LIBXL_TRIGGER_POWER;
     } else if (!strcmp(b, "sleep")) {
@@ -4062,7 +4060,7 @@ int main_button_press(int argc, char **a
     if ((opt = def_getopt(argc, argv, "", "button-press", 2)) != -1)
         return opt;
 
-    button_press(argv[optind], argv[optind + 1]);
+    button_press(find_domain(argv[optind]), argv[optind + 1]);
 
     return 0;
 }
@@ -4188,11 +4186,7 @@ static void vcpulist(int argc, char **ar
         libxl_dominfo_list_free(dominfo, nb_domain);
     } else {
         for (; argc > 0; ++argv, --argc) {
-            if (domain_qualifier_to_domid(*argv, &domid, 0) < 0) {
-                fprintf(stderr, "%s is an invalid domain identifier\n", *argv);
-                goto vcpulist_out;
-            }
-
+            uint32_t domid = find_domain(*argv);
             print_domain_vcpuinfo(domid, physinfo.nr_cpus);
         }
     }
@@ -4211,7 +4205,7 @@ int main_vcpulist(int argc, char **argv)
     return 0;
 }
 
-static void vcpupin(const char *d, const char *vcpu, char *cpu)
+static void vcpupin(uint32_t domid, const char *vcpu, char *cpu)
 {
     libxl_vcpuinfo *vcpuinfo;
     libxl_bitmap cpumap;
@@ -4229,8 +4223,6 @@ static void vcpupin(const char *d, const
         vcpuid = -1;
     }
 
-    find_domain(d);
-
     if (libxl_cpu_bitmap_alloc(ctx, &cpumap, 0)) {
         goto vcpupin_out;
     }
@@ -4270,11 +4262,11 @@ int main_vcpupin(int argc, char **argv)
     if ((opt = def_getopt(argc, argv, "", "vcpu-pin", 3)) != -1)
         return opt;
 
-    vcpupin(argv[optind], argv[optind+1] , argv[optind+2]);
+    vcpupin(find_domain(argv[optind]), argv[optind+1] , argv[optind+2]);
     return 0;
 }
 
-static void vcpuset(const char *d, const char* nr_vcpus)
+static void vcpuset(uint32_t domid, const char* nr_vcpus)
 {
     char *endptr;
     unsigned int max_vcpus, i;
@@ -4286,8 +4278,6 @@ static void vcpuset(const char *d, const
         return;
     }
 
-    find_domain(d);
-
     if (libxl_cpu_bitmap_alloc(ctx, &cpumap, 0)) {
         fprintf(stderr, "libxl_cpu_bitmap_alloc failed\n");
         return;
@@ -4308,7 +4298,7 @@ int main_vcpuset(int argc, char **argv)
     if ((opt = def_getopt(argc, argv, "", "vcpu-set", 2)) != -1)
         return opt;
 
-    vcpuset(argv[optind], argv[optind+1]);
+    vcpuset(find_domain(argv[optind]), argv[optind+1]);
     return 0;
 }
 
@@ -4545,7 +4535,7 @@ int main_sharing(int argc, char **argv)
         }
         info_free = info;
     } else if (optind == argc-1) {
-        find_domain(argv[optind]);
+        uint32_t domid = find_domain(argv[optind]);
         rc = libxl_domain_info(ctx, &info_buf, domid);
         if (rc == ERROR_INVAL) {
             fprintf(stderr, "Error: Domain \'%s\' does not exist.\n",
@@ -4905,7 +4895,7 @@ int main_sched_credit(int argc, char **a
                                     sched_credit_pool_output,
                                     cpupool);
     } else {
-        find_domain(dom);
+        uint32_t domid = find_domain(dom);
 
         if (!opt_w && !opt_c) { /* output credit scheduler info */
             sched_credit_domain_output(-1);
@@ -4982,7 +4972,7 @@ int main_sched_credit2(int argc, char **
                                     sched_default_pool_output,
                                     cpupool);
     } else {
-        find_domain(dom);
+        uint32_t domid = find_domain(dom);
 
         if (!opt_w) { /* output credit2 scheduler info */
             sched_credit2_domain_output(-1);
@@ -5085,7 +5075,7 @@ int main_sched_sedf(int argc, char **arg
                                     sched_default_pool_output,
                                     cpupool);
     } else {
-        find_domain(dom);
+        uint32_t domid = find_domain(dom);
 
         if (!opt_p && !opt_s && !opt_l && !opt_e && !opt_w) {
             /* output sedf scheduler info */
@@ -5125,6 +5115,7 @@ int main_sched_sedf(int argc, char **arg
 
 int main_domid(int argc, char **argv)
 {
+    uint32_t domid;
     int opt;
     const char *domname = NULL;
 
@@ -5145,6 +5136,7 @@ int main_domid(int argc, char **argv)
 
 int main_domname(int argc, char **argv)
 {
+    uint32_t domid;
     int opt;
     char *domname = NULL;
     char *endptr = NULL;
@@ -5173,18 +5165,17 @@ int main_domname(int argc, char **argv)
 
 int main_rename(int argc, char **argv)
 {
+    uint32_t domid;
     int opt;
-    const char *dom;
-    const char *new_name;
+    const char *dom, *new_name;
 
     if ((opt = def_getopt(argc, argv, "", "rename", 2)) != -1)
         return opt;
 
     dom = argv[optind++];
-
-    find_domain(dom);
     new_name = argv[optind];
 
+    domid = find_domain(dom);
     if (libxl_domain_rename(ctx, domid, common_domname, new_name)) {
         fprintf(stderr, "Can't rename domain '%s'.\n", dom);
         return 1;
@@ -5195,9 +5186,9 @@ int main_rename(int argc, char **argv)
 
 int main_trigger(int argc, char **argv)
 {
+    uint32_t domid;
     int opt;
     char *endptr = NULL;
-    const char *dom = NULL;
     int vcpuid = 0;
     const char *trigger_name = NULL;
     libxl_trigger trigger;
@@ -5205,9 +5196,7 @@ int main_trigger(int argc, char **argv)
     if ((opt = def_getopt(argc, argv, "", "trigger", 2)) != -1)
         return opt;
 
-    dom = argv[optind++];
-
-    find_domain(dom);
+    domid = find_domain(argv[optind++]);
 
     trigger_name = argv[optind++];
     if (libxl_trigger_from_string(trigger_name, &trigger)) {
@@ -5230,16 +5219,14 @@ int main_trigger(int argc, char **argv)
 
 int main_sysrq(int argc, char **argv)
 {
+    uint32_t domid;
     int opt;
     const char *sysrq = NULL;
-    const char *dom = NULL;
 
     if ((opt = def_getopt(argc, argv, "", "sysrq", 2)) != -1)
         return opt;
 
-    dom = argv[optind++];
-
-    find_domain(dom);
+    domid = find_domain(argv[optind++]);
 
     sysrq = argv[optind];
 
@@ -5313,6 +5300,7 @@ int main_top(int argc, char **argv)
 
 int main_networkattach(int argc, char **argv)
 {
+    uint32_t domid;
     int opt;
     libxl_device_nic nic;
     XLU_Config *config = 0;
@@ -5329,10 +5317,7 @@ int main_networkattach(int argc, char **
         return 0;
     }
 
-    if (domain_qualifier_to_domid(argv[optind], &domid, 0) < 0) {
-        fprintf(stderr, "%s is an invalid domain identifier\n", argv[optind]);
-        return 1;
-    }
+    domid = find_domain(argv[optind]);
 
     config= xlu_cfg_init(stderr, "command line");
     if (!config) {
@@ -5418,10 +5403,7 @@ int main_networklist(int argc, char **ar
     printf("%-3s %-2s %-17s %-6s %-5s %-6s %5s/%-5s %-30s\n",
            "Idx", "BE", "Mac Addr.", "handle", "state", "evt-ch", "tx-", "rx-ring-ref", "BE-path");
     for (argv += optind, argc -= optind; argc > 0; --argc, ++argv) {
-        if (domain_qualifier_to_domid(*argv, &domid, 0) < 0) {
-            fprintf(stderr, "%s is an invalid domain identifier\n", *argv);
-            continue;
-        }
+        uint32_t domid = find_domain(*argv);
         nics = libxl_device_nic_list(ctx, domid, &nb);
         if (!nics) {
             continue;
@@ -5447,16 +5429,14 @@ int main_networklist(int argc, char **ar
 
 int main_networkdetach(int argc, char **argv)
 {
+    uint32_t domid;
     int opt;
     libxl_device_nic nic;
 
     if ((opt = def_getopt(argc, argv, "", "network-detach", 2)) != -1)
         return opt;
 
-    if (domain_qualifier_to_domid(argv[optind], &domid, 0) < 0) {
-        fprintf(stderr, "%s is an invalid domain identifier\n", argv[optind]);
-        return 1;
-    }
+    domid = find_domain(argv[optind]);
 
     if (!strchr(argv[optind+1], ':')) {
         if (libxl_devid_to_device_nic(ctx, domid, atoi(argv[optind+1]), &nic)) {
@@ -5525,6 +5505,7 @@ int main_blocklist(int argc, char **argv
     printf("%-5s %-3s %-6s %-5s %-6s %-8s %-30s\n",
            "Vdev", "BE", "handle", "state", "evt-ch", "ring-ref", "BE-path");
     for (argv += optind, argc -= optind; argc > 0; --argc, ++argv) {
+        uint32_t domid;
         if (domain_qualifier_to_domid(*argv, &domid, 0) < 0) {
             fprintf(stderr, "%s is an invalid domain identifier\n", *argv);
             continue;
@@ -5550,16 +5531,15 @@ int main_blocklist(int argc, char **argv
 
 int main_blockdetach(int argc, char **argv)
 {
+    uint32_t domid;
     int opt, rc = 0;
     libxl_device_disk disk;
 
     if ((opt = def_getopt(argc, argv, "", "block-detach", 2)) != -1)
         return opt;
 
-    if (domain_qualifier_to_domid(argv[optind], &domid, 0) < 0) {
-        fprintf(stderr, "%s is an invalid domain identifier\n", argv[optind]);
-        return 1;
-    }
+    domid = find_domain(argv[optind]);
+
     if (libxl_vdev_to_device_disk(ctx, domid, argv[optind+1], &disk)) {
         fprintf(stderr, "Error: Device %s not connected.\n", argv[optind+1]);
         return 1;
@@ -5733,7 +5713,7 @@ static void print_uptime(int short_mode,
 
 int main_uptime(int argc, char **argv)
 {
-    const char *dom = NULL;
+    const char *dom;
     int short_mode = 0;
     uint32_t domains[100];
     int nb_doms = 0;
@@ -5749,10 +5729,8 @@ int main_uptime(int argc, char **argv)
         }
     }
 
-    for (;(dom = argv[optind]) != NULL; nb_doms++,optind++) {
-        find_domain(dom);
-        domains[nb_doms] = domid;
-    }
+    for (;(dom = argv[optind]) != NULL; nb_doms++,optind++)
+        domains[nb_doms] = find_domain(dom);
 
     print_uptime(short_mode, domains, nb_doms);
 
@@ -5761,6 +5739,7 @@ int main_uptime(int argc, char **argv)
 
 int main_tmem_list(int argc, char **argv)
 {
+    uint32_t domid;
     const char *dom = NULL;
     char *buf = NULL;
     int use_long = 0;
@@ -5788,9 +5767,9 @@ int main_tmem_list(int argc, char **argv
     }
 
     if (all)
-        domid = -1;
+        domid = INVALID_DOMID;
     else
-        find_domain(dom);
+        domid = find_domain(dom);
 
     buf = libxl_tmem_list(ctx, domid, use_long);
     if (buf == NULL)
@@ -5803,6 +5782,7 @@ int main_tmem_list(int argc, char **argv
 
 int main_tmem_freeze(int argc, char **argv)
 {
+    uint32_t domid;
     const char *dom = NULL;
     int all = 0;
     int opt;
@@ -5825,7 +5805,7 @@ int main_tmem_freeze(int argc, char **ar
     }
 
     if (all)
-        domid = -1;
+        domid = INVALID_DOMID;
     else
         find_domain(dom);
 
@@ -5835,6 +5815,7 @@ int main_tmem_freeze(int argc, char **ar
 
 int main_tmem_thaw(int argc, char **argv)
 {
+    uint32_t domid;
     const char *dom = NULL;
     int all = 0;
     int opt;
@@ -5857,7 +5838,7 @@ int main_tmem_thaw(int argc, char **argv
     }
 
     if (all)
-        domid = -1;
+        domid = INVALID_DOMID;
     else
         find_domain(dom);
 
@@ -5867,6 +5848,7 @@ int main_tmem_thaw(int argc, char **argv
 
 int main_tmem_set(int argc, char **argv)
 {
+    uint32_t domid;
     const char *dom = NULL;
     uint32_t weight = 0, cap = 0, compress = 0;
     int opt_w = 0, opt_c = 0, opt_p = 0;
@@ -5903,7 +5885,7 @@ int main_tmem_set(int argc, char **argv)
     }
 
     if (all)
-        domid = -1;
+        domid = INVALID_DOMID;
     else
         find_domain(dom);
 
@@ -5925,6 +5907,7 @@ int main_tmem_set(int argc, char **argv)
 
 int main_tmem_shared_auth(int argc, char **argv)
 {
+    uint32_t domid;
     const char *autharg = NULL;
     char *endptr = NULL;
     const char *dom = NULL;
@@ -5957,7 +5940,7 @@ int main_tmem_shared_auth(int argc, char
     }
 
     if (all)
-        domid = -1;
+        domid = INVALID_DOMID;
     else
         find_domain(dom);
 
@@ -6712,9 +6695,10 @@ done:
 
 int main_remus(int argc, char **argv)
 {
+    uint32_t domid;
     int opt, rc, daemonize = 1;
     const char *ssh_command = "ssh";
-    char *host = NULL, *rune = NULL, *domain = NULL;
+    char *host = NULL, *rune = NULL;
     libxl_domain_remus_info r_info;
     int send_fd = -1, recv_fd = -1;
     pid_t child = -1;
@@ -6750,11 +6734,10 @@ int main_remus(int argc, char **argv)
         }
     }
 
-    domain = argv[optind];
+    domid = find_domain(argv[optind]);
     host = argv[optind + 1];
 
     if (r_info.blackhole) {
-        find_domain(domain);
         send_fd = open("/dev/null", O_RDWR, 0644);
         if (send_fd < 0) {
             perror("failed to open /dev/null");
@@ -6771,7 +6754,7 @@ int main_remus(int argc, char **argv)
                 return 1;
         }
 
-        save_domain_core_begin(domain, NULL, &config_data, &config_len);
+        save_domain_core_begin(domid, NULL, &config_data, &config_len);
 
         if (!config_len) {
             fprintf(stderr, "No config file stored for running domain and "

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 14 12:42:51 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 12: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 1TCVEC-0001wQ-9D; Fri, 14 Sep 2012 12:42:36 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1TCVEA-0001vc-Dl
	for xen-devel@lists.xen.org; Fri, 14 Sep 2012 12:42:34 +0000
Received: from [85.158.139.83:19611] by server-9.bemta-5.messagelabs.com id
	76/3B-20529-A3623505; Fri, 14 Sep 2012 12:42:34 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1347626549!16426476!3
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNjk2MTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21618 invoked from network); 14 Sep 2012 12:42:32 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-8.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Sep 2012 12:42:32 -0000
X-IronPort-AV: E=Sophos;i="4.80,422,1344211200"; d="scan'208";a="37881298"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Sep 2012 12:42:29 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Fri, 14 Sep 2012 08:42:29 -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 1TCVE4-0007Ic-VF;
	Fri, 14 Sep 2012 13:42:28 +0100
MIME-Version: 1.0
X-Mercurial-Node: 8fad3481f8c90bb66fff4973b4c5653ebb7ca52e
Message-ID: <8fad3481f8c90bb66fff.1347626551@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1347626548@cosworth.uk.xensource.com>
References: <patchbomb.1347626548@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Fri, 14 Sep 2012 13:42:31 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 3 of 3] xl: Remove global domid and enable
	-Wshadow
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 1347626449 -3600
# Node ID 8fad3481f8c90bb66fff4973b4c5653ebb7ca52e
# Parent  192e4a16a057a456cc78e4ee46242315d474d116
xl: Remove global domid and enable -Wshadow

Lots of functions loop over a list of domain and others take a domid as
a parameter, shadowing the global one and leading to all sorts of
confusion.

Therefore remove the global domid and explicitly pass it around as
necessary.

Adds a domid to the parameters for many functions and switches many
others from taking a char * domain specifier to taking a domid, pushing
the domid lookup to the toplevel.

Replaces some open-coded domain_qualifier_to_domid error checking with
find_domain.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---

I find it hard to believe I won't have broken anything here... I tested
basic lifecycle ops only.

diff -r 192e4a16a057 -r 8fad3481f8c9 tools/libxl/Makefile
--- a/tools/libxl/Makefile	Fri Sep 14 12:21:24 2012 +0100
+++ b/tools/libxl/Makefile	Fri Sep 14 13:40:49 2012 +0100
@@ -89,10 +89,13 @@ LIBXLU_OBJS = libxlu_cfg_y.o libxlu_cfg_
 
 CLIENTS = xl testidl libxl-save-helper
 
+CFLAGS_XL += $(CFLAGS_libxenlight)
+CFLAGS_XL += -Wshadow
+
 XL_OBJS = xl.o xl_cmdimpl.o xl_cmdtable.o xl_sxp.o
 $(XL_OBJS) _libxl.api-for-check: \
             CFLAGS += $(CFLAGS_libxenctrl) # For xentoollog.h
-$(XL_OBJS): CFLAGS += $(CFLAGS_libxenlight)
+$(XL_OBJS): CFLAGS += $(CFLAGS_XL)
 $(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
diff -r 192e4a16a057 -r 8fad3481f8c9 tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Fri Sep 14 12:21:24 2012 +0100
+++ b/tools/libxl/xl_cmdimpl.c	Fri Sep 14 13:40:49 2012 +0100
@@ -67,9 +67,7 @@ libxl_ctx *ctx;
 
 xlchild children[child_max];
 
-/* when we operate on a domain, it is this one: */
 #define INVALID_DOMID ~0
-static uint32_t domid = INVALID_DOMID;
 static const char *common_domname;
 static int fd_lock = -1;
 
@@ -197,8 +195,9 @@ static int cpupool_qualifier_to_cpupooli
     return was_name ? libxl_name_to_cpupoolid(ctx, p, poolid_r) : 0;
 }
 
-static void find_domain(const char *p)
-{
+static uint32_t find_domain(const char *p)
+{
+    uint32_t domid;
     int rc, was_name;
 
     rc = domain_qualifier_to_domid(p, &domid, &was_name);
@@ -207,6 +206,7 @@ static void find_domain(const char *p)
         exit(2);
     }
     common_domname = was_name ? p : libxl_domid_to_name(ctx, domid);
+    return domid;
 }
 
 static int vncviewer(uint32_t domid, int autopass)
@@ -1590,7 +1590,7 @@ static int preserve_domain(uint32_t *r_d
     return rc == 0 ? 1 : 0;
 }
 
-static int freemem(libxl_domain_build_info *b_info)
+static int freemem(uint32_t domid, libxl_domain_build_info *b_info)
 {
     int rc, retries = 3;
     uint32_t need_memkb, free_memkb;
@@ -1670,7 +1670,7 @@ static void autoconnect_console(libxl_ct
     _exit(1);
 }
 
-static int domain_wait_event(libxl_event **event_r)
+static int domain_wait_event(uint32_t domid, libxl_event **event_r)
 {
     int ret;
     for (;;) {
@@ -1704,8 +1704,10 @@ static void evdisable_disk_ejects(libxl_
     }
 }
 
-static int create_domain(struct domain_create *dom_info)
-{
+static uint32_t create_domain(struct domain_create *dom_info)
+{
+    uint32_t domid = INVALID_DOMID;
+
     libxl_domain_config d_config;
 
     int debug = dom_info->debug;
@@ -1881,7 +1883,7 @@ start:
     if (rc < 0)
         goto error_out;
 
-    ret = freemem(&d_config.b_info);
+    ret = freemem(domid, &d_config.b_info);
     if (ret < 0) {
         fprintf(stderr, "failed to free memory for the domain\n");
         ret = ERROR_FAIL;
@@ -2031,7 +2033,7 @@ start:
     }
     while (1) {
         libxl_event *event;
-        ret = domain_wait_event(&event);
+        ret = domain_wait_event(domid, &event);
         if (ret) goto out;
 
         switch (event->type) {
@@ -2243,13 +2245,11 @@ static int def_getopt(int argc, char * c
     return -1;
 }
 
-static int set_memory_max(const char *p, const char *mem)
+static int set_memory_max(uint32_t domid, const char *mem)
 {
     int64_t memorykb;
     int rc;
 
-    find_domain(p);
-
     memorykb = parse_mem_size_kb(mem);
     if (memorykb == -1) {
         fprintf(stderr, "invalid memory size: %s\n", mem);
@@ -2263,17 +2263,18 @@ static int set_memory_max(const char *p,
 
 int main_memmax(int argc, char **argv)
 {
+    uint32_t domid;
     int opt = 0;
-    char *p = NULL, *mem;
+    char *mem;
     int rc;
 
     if ((opt = def_getopt(argc, argv, "", "mem-max", 2)) != -1)
         return opt;
 
-    p = argv[optind];
+    domid = find_domain(argv[optind]);
     mem = argv[optind + 1];
 
-    rc = set_memory_max(p, mem);
+    rc = set_memory_max(domid, mem);
     if (rc) {
         fprintf(stderr, "cannot set domid %d static max memory to : %s\n", domid, mem);
         return 1;
@@ -2282,12 +2283,10 @@ int main_memmax(int argc, char **argv)
     return 0;
 }
 
-static void set_memory_target(const char *p, const char *mem)
+static void set_memory_target(uint32_t domid, const char *mem)
 {
     long long int memorykb;
 
-    find_domain(p);
-
     memorykb = parse_mem_size_kb(mem);
     if (memorykb == -1)  {
         fprintf(stderr, "invalid memory size: %s\n", mem);
@@ -2299,26 +2298,26 @@ static void set_memory_target(const char
 
 int main_memset(int argc, char **argv)
 {
+    uint32_t domid;
     int opt = 0;
-    const char *p = NULL, *mem;
+    const char *mem;
 
     if ((opt = def_getopt(argc, argv, "", "mem-set", 2)) != -1)
         return opt;
 
-    p = argv[optind];
+    domid = find_domain(argv[optind]);
     mem = argv[optind + 1];
 
-    set_memory_target(p, mem);
+    set_memory_target(domid, mem);
     return 0;
 }
 
-static void cd_insert(const char *dom, const char *virtdev, char *phys)
+static void cd_insert(uint32_t domid, const char *virtdev, char *phys)
 {
     libxl_device_disk disk; /* we don't free disk's contents */
     char *buf = NULL;
     XLU_Config *config = 0;
 
-    find_domain(dom);
 
     if (asprintf(&buf, "vdev=%s,access=r,devtype=cdrom,target=%s",
                  virtdev, phys ? phys : "") < 0) {
@@ -2338,38 +2337,41 @@ static void cd_insert(const char *dom, c
 
 int main_cd_eject(int argc, char **argv)
 {
+    uint32_t domid;
     int opt = 0;
-    const char *p = NULL, *virtdev;
+    const char *virtdev;
 
     if ((opt = def_getopt(argc, argv, "", "cd-eject", 2)) != -1)
         return opt;
 
-    p = argv[optind];
+    domid = find_domain(argv[optind]);
     virtdev = argv[optind + 1];
 
-    cd_insert(p, virtdev, NULL);
+    cd_insert(domid, virtdev, NULL);
     return 0;
 }
 
 int main_cd_insert(int argc, char **argv)
 {
+    uint32_t domid;
     int opt = 0;
-    const char *p = NULL, *virtdev;
+    const char *virtdev;
     char *file = NULL; /* modified by cd_insert tokenising it */
 
     if ((opt = def_getopt(argc, argv, "", "cd-insert", 3)) != -1)
         return opt;
 
-    p = argv[optind];
+    domid = find_domain(argv[optind]);
     virtdev = argv[optind + 1];
     file = argv[optind + 2];
 
-    cd_insert(p, virtdev, file);
+    cd_insert(domid, virtdev, file);
     return 0;
 }
 
 int main_console(int argc, char **argv)
 {
+    uint32_t domid;
     int opt = 0, num = 0;
     libxl_console_type type = 0;
 
@@ -2393,7 +2395,7 @@ int main_console(int argc, char **argv)
         }
     }
 
-    find_domain(argv[optind]);
+    domid = find_domain(argv[optind]);
     if (!type)
         libxl_primary_console_exec(ctx, domid);
     else
@@ -2410,6 +2412,7 @@ int main_vncviewer(int argc, char **argv
         {"help", 0, 0, 'h'},
         {0, 0, 0, 0}
     };
+    uint32_t domid;
     int opt, autopass = 0;
 
     while (1) {
@@ -2435,20 +2438,18 @@ int main_vncviewer(int argc, char **argv
         return 2;
     }
 
-    find_domain(argv[optind]);
+    domid = find_domain(argv[optind]);
 
     if (vncviewer(domid, autopass))
         return 1;
     return 0;
 }
 
-static void pcilist(const char *dom)
+static void pcilist(uint32_t domid)
 {
     libxl_device_pci *pcidevs;
     int num, i;
 
-    find_domain(dom);
-
     pcidevs = libxl_device_pci_list(ctx, domid, &num);
     if (pcidevs == NULL)
         return;
@@ -2464,27 +2465,25 @@ static void pcilist(const char *dom)
 
 int main_pcilist(int argc, char **argv)
 {
+    uint32_t domid;
     int opt;
-    const char *domname = NULL;
 
     if ((opt = def_getopt(argc, argv, "", "pci-list", 1)) != -1)
         return opt;
 
-    domname = argv[optind];
-
-    pcilist(domname);
+    domid = find_domain(argv[optind]);
+
+    pcilist(domid);
     return 0;
 }
 
-static void pcidetach(const char *dom, const char *bdf, int force)
+static void pcidetach(uint32_t domid, const char *bdf, int force)
 {
     libxl_device_pci pcidev;
     XLU_Config *config;
 
-    find_domain(dom);
-
     libxl_device_pci_init(&pcidev);
-    
+
     config = xlu_cfg_init(stderr, "command line");
     if (!config) { perror("xlu_cfg_inig"); exit(-1); }
 
@@ -2503,9 +2502,10 @@ static void pcidetach(const char *dom, c
 
 int main_pcidetach(int argc, char **argv)
 {
+    uint32_t domid;
     int opt;
     int force = 0;
-    const char *domname = NULL, *bdf = NULL;
+    const char *bdf = NULL;
 
     while ((opt = def_getopt(argc, argv, "f", "pci-detach", 2)) != -1) {
         switch (opt) {
@@ -2517,19 +2517,17 @@ int main_pcidetach(int argc, char **argv
         }
     }
 
-    domname = argv[optind];
+    domid = find_domain(argv[optind]);
     bdf = argv[optind + 1];
 
-    pcidetach(domname, bdf, force);
+    pcidetach(domid, bdf, force);
     return 0;
 }
-static void pciattach(const char *dom, const char *bdf, const char *vs)
+static void pciattach(uint32_t domid, const char *bdf, const char *vs)
 {
     libxl_device_pci pcidev;
     XLU_Config *config;
 
-    find_domain(dom);
-
     libxl_device_pci_init(&pcidev);
 
     config = xlu_cfg_init(stderr, "command line");
@@ -2547,19 +2545,20 @@ static void pciattach(const char *dom, c
 
 int main_pciattach(int argc, char **argv)
 {
+    uint32_t domid;
     int opt;
-    const char *domname = NULL, *bdf = NULL, *vs = NULL;
+    const char *bdf = NULL, *vs = NULL;
 
     if ((opt = def_getopt(argc, argv, "", "pci-attach", 2)) != -1)
         return opt;
 
-    domname = argv[optind];
+    domid = find_domain(argv[optind]);
     bdf = argv[optind + 1];
 
     if (optind + 1 < argc)
         vs = argv[optind + 2];
 
-    pciattach(domname, bdf, vs);
+    pciattach(domid, bdf, vs);
     return 0;
 }
 
@@ -2671,22 +2670,20 @@ int main_pciassignable_remove(int argc, 
     return 0;
 }
 
-static void pause_domain(const char *p)
-{
-    find_domain(p);
+static void pause_domain(uint32_t domid)
+{
     libxl_domain_pause(ctx, domid);
 }
 
-static void unpause_domain(const char *p)
-{
-    find_domain(p);
+static void unpause_domain(uint32_t domid)
+{
     libxl_domain_unpause(ctx, domid);
 }
 
-static void destroy_domain(const char *p)
+static void destroy_domain(uint32_t domid)
 {
     int rc;
-    find_domain(p);
+
     if (domid == 0) {
         fprintf(stderr, "Cannot destroy privileged domain 0.\n\n");
         exit(-1);
@@ -2695,13 +2692,12 @@ static void destroy_domain(const char *p
     if (rc) { fprintf(stderr,"destroy failed (rc=%d)\n",rc); exit(-1); }
 }
 
-static void shutdown_domain(const char *p, int wait_for_it,
+static void shutdown_domain(uint32_t domid, int wait_for_it,
                             int fallback_trigger)
 {
     int rc;
     libxl_event *event;
 
-    find_domain(p);
     rc=libxl_domain_shutdown(ctx, domid);
     if (rc == ERROR_NOPARAVIRT) {
         if (fallback_trigger) {
@@ -2728,7 +2724,7 @@ static void shutdown_domain(const char *
         }
 
         for (;;) {
-            rc = domain_wait_event(&event);
+            rc = domain_wait_event(domid, &event);
             if (rc) exit(-1);
 
             switch (event->type) {
@@ -2755,10 +2751,10 @@ static void shutdown_domain(const char *
     }
 }
 
-static void reboot_domain(const char *p, int fallback_trigger)
+static void reboot_domain(uint32_t domid, int fallback_trigger)
 {
     int rc;
-    find_domain(p);
+
     rc=libxl_domain_reboot(ctx, domid);
     if (rc == ERROR_NOPARAVIRT) {
         if (fallback_trigger) {
@@ -2815,7 +2811,7 @@ static void list_domains_details(const l
         if (default_output_format == OUTPUT_FORMAT_JSON)
             s = printf_info_one_json(hand, info[i].domid, &d_config);
         else
-            printf_info_sexp(domid, &d_config);
+            printf_info_sexp(info[i].domid, &d_config);
         libxl_domain_config_dispose(&d_config);
         free(data);
         free(config_source);
@@ -2917,15 +2913,13 @@ static void list_vm(void)
     libxl_vminfo_list_free(info, nb_vm);
 }
 
-static void save_domain_core_begin(const char *domain_spec,
+static void save_domain_core_begin(uint32_t domid,
                                    const char *override_config_file,
                                    uint8_t **config_data_r,
                                    int *config_len_r)
 {
     int rc;
 
-    find_domain(domain_spec);
-
     /* configuration file in optional data: */
 
     if (override_config_file) {
@@ -2982,14 +2976,15 @@ static void save_domain_core_writeconfig
             hdr.optional_data_len);
 }
 
-static int save_domain(const char *p, const char *filename, int checkpoint,
+static int save_domain(uint32_t domid, const char *filename, int checkpoint,
                 const char *override_config_file)
 {
     int fd;
     uint8_t *config_data;
     int config_len;
 
-    save_domain_core_begin(p, override_config_file, &config_data, &config_len);
+    save_domain_core_begin(domid, override_config_file,
+                           &config_data, &config_len);
 
     if (!config_len) {
         fputs(" Savefile will not contain xl domain config\n", stderr);
@@ -3159,7 +3154,7 @@ static void migrate_do_preamble(int send
 
 }
 
-static void migrate_domain(const char *domain_spec, const char *rune,
+static void migrate_domain(uint32_t domid, const char *rune,
                            const char *override_config_file)
 {
     pid_t child = -1;
@@ -3170,7 +3165,7 @@ static void migrate_domain(const char *d
     uint8_t *config_data;
     int config_len;
 
-    save_domain_core_begin(domain_spec, override_config_file,
+    save_domain_core_begin(domid, override_config_file,
                            &config_data, &config_len);
 
     if (!config_len) {
@@ -3297,10 +3292,10 @@ static void migrate_domain(const char *d
     exit(-ERROR_BADFAIL);
 }
 
-static void core_dump_domain(const char *domain_spec, const char *filename)
+static void core_dump_domain(uint32_t domid, const char *filename)
 {
     int rc;
-    find_domain(domain_spec);
+
     rc=libxl_domain_core_dump(ctx, domid, filename, NULL);
     if (rc) { fprintf(stderr,"core dump failed (rc=%d)\n",rc);exit(-1); }
 }
@@ -3308,6 +3303,7 @@ static void core_dump_domain(const char 
 static void migrate_receive(int debug, int daemonize, int monitor,
                             int send_fd, int recv_fd, int remus)
 {
+    uint32_t domid;
     int rc, rc2;
     char rc_buf;
     char *migration_domname;
@@ -3339,6 +3335,8 @@ static void migrate_receive(int debug, i
         exit(-rc);
     }
 
+    domid = rc;
+
     if (remus) {
         /* If we are here, it means that the sender (primary) has crashed.
          * TODO: Split-Brain Check.
@@ -3557,7 +3555,8 @@ int main_migrate_receive(int argc, char 
 
 int main_save(int argc, char **argv)
 {
-    const char *filename, *p;
+    uint32_t domid;
+    const char *filename;
     const char *config_filename = NULL;
     int checkpoint = 0;
     int opt;
@@ -3577,18 +3576,18 @@ int main_save(int argc, char **argv)
         return 2;
     }
 
-    p = argv[optind];
+    domid = find_domain(argv[optind]);
     filename = argv[optind + 1];
     if ( argc - optind >= 3 )
         config_filename = argv[optind + 2];
 
-    save_domain(p, filename, checkpoint, config_filename);
+    save_domain(domid, filename, checkpoint, config_filename);
     return 0;
 }
 
 int main_migrate(int argc, char **argv)
 {
-    const char *p = NULL;
+    uint32_t domid;
     const char *config_filename = NULL;
     const char *ssh_command = "ssh";
     char *rune = NULL;
@@ -3618,7 +3617,7 @@ int main_migrate(int argc, char **argv)
         }
     }
 
-    p = argv[optind];
+    domid = find_domain(argv[optind]);
     host = argv[optind + 1];
 
     if (!ssh_command[0]) {
@@ -3631,7 +3630,7 @@ int main_migrate(int argc, char **argv)
             return 1;
     }
 
-    migrate_domain(p, rune, config_filename);
+    migrate_domain(domid, rune, config_filename);
     return 0;
 }
 
@@ -3642,7 +3641,7 @@ int main_dump_core(int argc, char **argv
     if ((opt = def_getopt(argc, argv, "", "dump-core", 2)) != -1)
         return opt;
 
-    core_dump_domain(argv[optind], argv[optind + 1]);
+    core_dump_domain(find_domain(argv[optind]), argv[optind + 1]);
     return 0;
 }
 
@@ -3653,7 +3652,7 @@ int main_pause(int argc, char **argv)
     if ((opt = def_getopt(argc, argv, "", "pause", 1)) != -1)
         return opt;
 
-    pause_domain(argv[optind]);
+    pause_domain(find_domain(argv[optind]));
 
     return 0;
 }
@@ -3665,7 +3664,7 @@ int main_unpause(int argc, char **argv)
     if ((opt = def_getopt(argc, argv, "", "unpause", 1)) != -1)
         return opt;
 
-    unpause_domain(argv[optind]);
+    unpause_domain(find_domain(argv[optind]));
 
     return 0;
 }
@@ -3677,7 +3676,7 @@ int main_destroy(int argc, char **argv)
     if ((opt = def_getopt(argc, argv, "", "destroy", 1)) != -1)
         return opt;
 
-    destroy_domain(argv[optind]);
+    destroy_domain(find_domain(argv[optind]));
     return 0;
 }
 
@@ -3700,7 +3699,7 @@ int main_shutdown(int argc, char **argv)
         }
     }
 
-    shutdown_domain(argv[optind], wait_for_it, fallback_trigger);
+    shutdown_domain(find_domain(argv[optind]), wait_for_it, fallback_trigger);
     return 0;
 }
 
@@ -3719,7 +3718,7 @@ int main_reboot(int argc, char **argv)
         }
     }
 
-    reboot_domain(argv[optind], fallback_trigger);
+    reboot_domain(find_domain(argv[optind]), fallback_trigger);
     return 0;
 }
 
@@ -3773,7 +3772,7 @@ int main_list(int argc, char **argv)
         }
         info_free = info;
     } else if (optind == argc-1) {
-        find_domain(argv[optind]);
+        uint32_t domid = find_domain(argv[optind]);
         rc = libxl_domain_info(ctx, &info_buf, domid);
         if (rc == ERROR_INVAL) {
             fprintf(stderr, "Error: Domain \'%s\' does not exist.\n",
@@ -3922,6 +3921,7 @@ int main_create(int argc, char **argv)
 
 int main_config_update(int argc, char **argv)
 {
+    uint32_t domid;
     const char *filename = NULL;
     char *p;
     char extra_config[1024];
@@ -3943,7 +3943,7 @@ int main_config_update(int argc, char **
         exit(1);
     }
 
-    find_domain(argv[1]);
+    domid = find_domain(argv[1]);
     argc--; argv++;
 
     if (argv[1] && argv[1][0] != '-' && !strchr(argv[1], '=')) {
@@ -4034,12 +4034,10 @@ int main_config_update(int argc, char **
     return 0;
 }
 
-static void button_press(const char *p, const char *b)
+static void button_press(uint32_t domid, const char *b)
 {
     libxl_trigger trigger;
 
-    find_domain(p);
-
     if (!strcmp(b, "power")) {
         trigger = LIBXL_TRIGGER_POWER;
     } else if (!strcmp(b, "sleep")) {
@@ -4062,7 +4060,7 @@ int main_button_press(int argc, char **a
     if ((opt = def_getopt(argc, argv, "", "button-press", 2)) != -1)
         return opt;
 
-    button_press(argv[optind], argv[optind + 1]);
+    button_press(find_domain(argv[optind]), argv[optind + 1]);
 
     return 0;
 }
@@ -4188,11 +4186,7 @@ static void vcpulist(int argc, char **ar
         libxl_dominfo_list_free(dominfo, nb_domain);
     } else {
         for (; argc > 0; ++argv, --argc) {
-            if (domain_qualifier_to_domid(*argv, &domid, 0) < 0) {
-                fprintf(stderr, "%s is an invalid domain identifier\n", *argv);
-                goto vcpulist_out;
-            }
-
+            uint32_t domid = find_domain(*argv);
             print_domain_vcpuinfo(domid, physinfo.nr_cpus);
         }
     }
@@ -4211,7 +4205,7 @@ int main_vcpulist(int argc, char **argv)
     return 0;
 }
 
-static void vcpupin(const char *d, const char *vcpu, char *cpu)
+static void vcpupin(uint32_t domid, const char *vcpu, char *cpu)
 {
     libxl_vcpuinfo *vcpuinfo;
     libxl_bitmap cpumap;
@@ -4229,8 +4223,6 @@ static void vcpupin(const char *d, const
         vcpuid = -1;
     }
 
-    find_domain(d);
-
     if (libxl_cpu_bitmap_alloc(ctx, &cpumap, 0)) {
         goto vcpupin_out;
     }
@@ -4270,11 +4262,11 @@ int main_vcpupin(int argc, char **argv)
     if ((opt = def_getopt(argc, argv, "", "vcpu-pin", 3)) != -1)
         return opt;
 
-    vcpupin(argv[optind], argv[optind+1] , argv[optind+2]);
+    vcpupin(find_domain(argv[optind]), argv[optind+1] , argv[optind+2]);
     return 0;
 }
 
-static void vcpuset(const char *d, const char* nr_vcpus)
+static void vcpuset(uint32_t domid, const char* nr_vcpus)
 {
     char *endptr;
     unsigned int max_vcpus, i;
@@ -4286,8 +4278,6 @@ static void vcpuset(const char *d, const
         return;
     }
 
-    find_domain(d);
-
     if (libxl_cpu_bitmap_alloc(ctx, &cpumap, 0)) {
         fprintf(stderr, "libxl_cpu_bitmap_alloc failed\n");
         return;
@@ -4308,7 +4298,7 @@ int main_vcpuset(int argc, char **argv)
     if ((opt = def_getopt(argc, argv, "", "vcpu-set", 2)) != -1)
         return opt;
 
-    vcpuset(argv[optind], argv[optind+1]);
+    vcpuset(find_domain(argv[optind]), argv[optind+1]);
     return 0;
 }
 
@@ -4545,7 +4535,7 @@ int main_sharing(int argc, char **argv)
         }
         info_free = info;
     } else if (optind == argc-1) {
-        find_domain(argv[optind]);
+        uint32_t domid = find_domain(argv[optind]);
         rc = libxl_domain_info(ctx, &info_buf, domid);
         if (rc == ERROR_INVAL) {
             fprintf(stderr, "Error: Domain \'%s\' does not exist.\n",
@@ -4905,7 +4895,7 @@ int main_sched_credit(int argc, char **a
                                     sched_credit_pool_output,
                                     cpupool);
     } else {
-        find_domain(dom);
+        uint32_t domid = find_domain(dom);
 
         if (!opt_w && !opt_c) { /* output credit scheduler info */
             sched_credit_domain_output(-1);
@@ -4982,7 +4972,7 @@ int main_sched_credit2(int argc, char **
                                     sched_default_pool_output,
                                     cpupool);
     } else {
-        find_domain(dom);
+        uint32_t domid = find_domain(dom);
 
         if (!opt_w) { /* output credit2 scheduler info */
             sched_credit2_domain_output(-1);
@@ -5085,7 +5075,7 @@ int main_sched_sedf(int argc, char **arg
                                     sched_default_pool_output,
                                     cpupool);
     } else {
-        find_domain(dom);
+        uint32_t domid = find_domain(dom);
 
         if (!opt_p && !opt_s && !opt_l && !opt_e && !opt_w) {
             /* output sedf scheduler info */
@@ -5125,6 +5115,7 @@ int main_sched_sedf(int argc, char **arg
 
 int main_domid(int argc, char **argv)
 {
+    uint32_t domid;
     int opt;
     const char *domname = NULL;
 
@@ -5145,6 +5136,7 @@ int main_domid(int argc, char **argv)
 
 int main_domname(int argc, char **argv)
 {
+    uint32_t domid;
     int opt;
     char *domname = NULL;
     char *endptr = NULL;
@@ -5173,18 +5165,17 @@ int main_domname(int argc, char **argv)
 
 int main_rename(int argc, char **argv)
 {
+    uint32_t domid;
     int opt;
-    const char *dom;
-    const char *new_name;
+    const char *dom, *new_name;
 
     if ((opt = def_getopt(argc, argv, "", "rename", 2)) != -1)
         return opt;
 
     dom = argv[optind++];
-
-    find_domain(dom);
     new_name = argv[optind];
 
+    domid = find_domain(dom);
     if (libxl_domain_rename(ctx, domid, common_domname, new_name)) {
         fprintf(stderr, "Can't rename domain '%s'.\n", dom);
         return 1;
@@ -5195,9 +5186,9 @@ int main_rename(int argc, char **argv)
 
 int main_trigger(int argc, char **argv)
 {
+    uint32_t domid;
     int opt;
     char *endptr = NULL;
-    const char *dom = NULL;
     int vcpuid = 0;
     const char *trigger_name = NULL;
     libxl_trigger trigger;
@@ -5205,9 +5196,7 @@ int main_trigger(int argc, char **argv)
     if ((opt = def_getopt(argc, argv, "", "trigger", 2)) != -1)
         return opt;
 
-    dom = argv[optind++];
-
-    find_domain(dom);
+    domid = find_domain(argv[optind++]);
 
     trigger_name = argv[optind++];
     if (libxl_trigger_from_string(trigger_name, &trigger)) {
@@ -5230,16 +5219,14 @@ int main_trigger(int argc, char **argv)
 
 int main_sysrq(int argc, char **argv)
 {
+    uint32_t domid;
     int opt;
     const char *sysrq = NULL;
-    const char *dom = NULL;
 
     if ((opt = def_getopt(argc, argv, "", "sysrq", 2)) != -1)
         return opt;
 
-    dom = argv[optind++];
-
-    find_domain(dom);
+    domid = find_domain(argv[optind++]);
 
     sysrq = argv[optind];
 
@@ -5313,6 +5300,7 @@ int main_top(int argc, char **argv)
 
 int main_networkattach(int argc, char **argv)
 {
+    uint32_t domid;
     int opt;
     libxl_device_nic nic;
     XLU_Config *config = 0;
@@ -5329,10 +5317,7 @@ int main_networkattach(int argc, char **
         return 0;
     }
 
-    if (domain_qualifier_to_domid(argv[optind], &domid, 0) < 0) {
-        fprintf(stderr, "%s is an invalid domain identifier\n", argv[optind]);
-        return 1;
-    }
+    domid = find_domain(argv[optind]);
 
     config= xlu_cfg_init(stderr, "command line");
     if (!config) {
@@ -5418,10 +5403,7 @@ int main_networklist(int argc, char **ar
     printf("%-3s %-2s %-17s %-6s %-5s %-6s %5s/%-5s %-30s\n",
            "Idx", "BE", "Mac Addr.", "handle", "state", "evt-ch", "tx-", "rx-ring-ref", "BE-path");
     for (argv += optind, argc -= optind; argc > 0; --argc, ++argv) {
-        if (domain_qualifier_to_domid(*argv, &domid, 0) < 0) {
-            fprintf(stderr, "%s is an invalid domain identifier\n", *argv);
-            continue;
-        }
+        uint32_t domid = find_domain(*argv);
         nics = libxl_device_nic_list(ctx, domid, &nb);
         if (!nics) {
             continue;
@@ -5447,16 +5429,14 @@ int main_networklist(int argc, char **ar
 
 int main_networkdetach(int argc, char **argv)
 {
+    uint32_t domid;
     int opt;
     libxl_device_nic nic;
 
     if ((opt = def_getopt(argc, argv, "", "network-detach", 2)) != -1)
         return opt;
 
-    if (domain_qualifier_to_domid(argv[optind], &domid, 0) < 0) {
-        fprintf(stderr, "%s is an invalid domain identifier\n", argv[optind]);
-        return 1;
-    }
+    domid = find_domain(argv[optind]);
 
     if (!strchr(argv[optind+1], ':')) {
         if (libxl_devid_to_device_nic(ctx, domid, atoi(argv[optind+1]), &nic)) {
@@ -5525,6 +5505,7 @@ int main_blocklist(int argc, char **argv
     printf("%-5s %-3s %-6s %-5s %-6s %-8s %-30s\n",
            "Vdev", "BE", "handle", "state", "evt-ch", "ring-ref", "BE-path");
     for (argv += optind, argc -= optind; argc > 0; --argc, ++argv) {
+        uint32_t domid;
         if (domain_qualifier_to_domid(*argv, &domid, 0) < 0) {
             fprintf(stderr, "%s is an invalid domain identifier\n", *argv);
             continue;
@@ -5550,16 +5531,15 @@ int main_blocklist(int argc, char **argv
 
 int main_blockdetach(int argc, char **argv)
 {
+    uint32_t domid;
     int opt, rc = 0;
     libxl_device_disk disk;
 
     if ((opt = def_getopt(argc, argv, "", "block-detach", 2)) != -1)
         return opt;
 
-    if (domain_qualifier_to_domid(argv[optind], &domid, 0) < 0) {
-        fprintf(stderr, "%s is an invalid domain identifier\n", argv[optind]);
-        return 1;
-    }
+    domid = find_domain(argv[optind]);
+
     if (libxl_vdev_to_device_disk(ctx, domid, argv[optind+1], &disk)) {
         fprintf(stderr, "Error: Device %s not connected.\n", argv[optind+1]);
         return 1;
@@ -5733,7 +5713,7 @@ static void print_uptime(int short_mode,
 
 int main_uptime(int argc, char **argv)
 {
-    const char *dom = NULL;
+    const char *dom;
     int short_mode = 0;
     uint32_t domains[100];
     int nb_doms = 0;
@@ -5749,10 +5729,8 @@ int main_uptime(int argc, char **argv)
         }
     }
 
-    for (;(dom = argv[optind]) != NULL; nb_doms++,optind++) {
-        find_domain(dom);
-        domains[nb_doms] = domid;
-    }
+    for (;(dom = argv[optind]) != NULL; nb_doms++,optind++)
+        domains[nb_doms] = find_domain(dom);
 
     print_uptime(short_mode, domains, nb_doms);
 
@@ -5761,6 +5739,7 @@ int main_uptime(int argc, char **argv)
 
 int main_tmem_list(int argc, char **argv)
 {
+    uint32_t domid;
     const char *dom = NULL;
     char *buf = NULL;
     int use_long = 0;
@@ -5788,9 +5767,9 @@ int main_tmem_list(int argc, char **argv
     }
 
     if (all)
-        domid = -1;
+        domid = INVALID_DOMID;
     else
-        find_domain(dom);
+        domid = find_domain(dom);
 
     buf = libxl_tmem_list(ctx, domid, use_long);
     if (buf == NULL)
@@ -5803,6 +5782,7 @@ int main_tmem_list(int argc, char **argv
 
 int main_tmem_freeze(int argc, char **argv)
 {
+    uint32_t domid;
     const char *dom = NULL;
     int all = 0;
     int opt;
@@ -5825,7 +5805,7 @@ int main_tmem_freeze(int argc, char **ar
     }
 
     if (all)
-        domid = -1;
+        domid = INVALID_DOMID;
     else
         find_domain(dom);
 
@@ -5835,6 +5815,7 @@ int main_tmem_freeze(int argc, char **ar
 
 int main_tmem_thaw(int argc, char **argv)
 {
+    uint32_t domid;
     const char *dom = NULL;
     int all = 0;
     int opt;
@@ -5857,7 +5838,7 @@ int main_tmem_thaw(int argc, char **argv
     }
 
     if (all)
-        domid = -1;
+        domid = INVALID_DOMID;
     else
         find_domain(dom);
 
@@ -5867,6 +5848,7 @@ int main_tmem_thaw(int argc, char **argv
 
 int main_tmem_set(int argc, char **argv)
 {
+    uint32_t domid;
     const char *dom = NULL;
     uint32_t weight = 0, cap = 0, compress = 0;
     int opt_w = 0, opt_c = 0, opt_p = 0;
@@ -5903,7 +5885,7 @@ int main_tmem_set(int argc, char **argv)
     }
 
     if (all)
-        domid = -1;
+        domid = INVALID_DOMID;
     else
         find_domain(dom);
 
@@ -5925,6 +5907,7 @@ int main_tmem_set(int argc, char **argv)
 
 int main_tmem_shared_auth(int argc, char **argv)
 {
+    uint32_t domid;
     const char *autharg = NULL;
     char *endptr = NULL;
     const char *dom = NULL;
@@ -5957,7 +5940,7 @@ int main_tmem_shared_auth(int argc, char
     }
 
     if (all)
-        domid = -1;
+        domid = INVALID_DOMID;
     else
         find_domain(dom);
 
@@ -6712,9 +6695,10 @@ done:
 
 int main_remus(int argc, char **argv)
 {
+    uint32_t domid;
     int opt, rc, daemonize = 1;
     const char *ssh_command = "ssh";
-    char *host = NULL, *rune = NULL, *domain = NULL;
+    char *host = NULL, *rune = NULL;
     libxl_domain_remus_info r_info;
     int send_fd = -1, recv_fd = -1;
     pid_t child = -1;
@@ -6750,11 +6734,10 @@ int main_remus(int argc, char **argv)
         }
     }
 
-    domain = argv[optind];
+    domid = find_domain(argv[optind]);
     host = argv[optind + 1];
 
     if (r_info.blackhole) {
-        find_domain(domain);
         send_fd = open("/dev/null", O_RDWR, 0644);
         if (send_fd < 0) {
             perror("failed to open /dev/null");
@@ -6771,7 +6754,7 @@ int main_remus(int argc, char **argv)
                 return 1;
         }
 
-        save_domain_core_begin(domain, NULL, &config_data, &config_len);
+        save_domain_core_begin(domid, NULL, &config_data, &config_len);
 
         if (!config_len) {
             fprintf(stderr, "No config file stored for running domain and "

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 14 12:42:55 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 12: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 1TCVEB-0001w2-CB; Fri, 14 Sep 2012 12:42: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 1TCVE9-0001vd-B7
	for xen-devel@lists.xen.org; Fri, 14 Sep 2012 12:42:33 +0000
Received: from [85.158.139.83:8341] by server-7.bemta-5.messagelabs.com id
	4F/43-19703-83623505; Fri, 14 Sep 2012 12:42:32 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1347626549!16426476!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNjk2MTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21575 invoked from network); 14 Sep 2012 12:42:31 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-8.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Sep 2012 12:42:31 -0000
X-IronPort-AV: E=Sophos;i="4.80,422,1344211200"; d="scan'208";a="37881297"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Sep 2012 12:42:29 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Fri, 14 Sep 2012 08:42:29 -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 1TCVE4-0007Ic-Uq;
	Fri, 14 Sep 2012 13:42:28 +0100
MIME-Version: 1.0
X-Mercurial-Node: 192e4a16a057a456cc78e4ee46242315d474d116
Message-ID: <192e4a16a057a456cc78.1347626550@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1347626548@cosworth.uk.xensource.com>
References: <patchbomb.1347626548@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Fri, 14 Sep 2012 13:42:30 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 2 of 3] xl: prepare to enable Wshadow
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 1347621684 -3600
# Node ID 192e4a16a057a456cc78e4ee46242315d474d116
# Parent  58ab3fb73d13e250f334a38599b749640deac190
xl: prepare to enable Wshadow

Takes care of everything other than the global domid clashes.

Avoid galobal functions
  - stime(2)
  - time(2)

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r 58ab3fb73d13 -r 192e4a16a057 tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Fri Sep 14 12:09:43 2012 +0100
+++ b/tools/libxl/xl_cmdimpl.c	Fri Sep 14 12:21:24 2012 +0100
@@ -676,7 +676,7 @@ static void parse_config_data(const char
         b_info->max_vcpus = l;
 
     if (!xlu_cfg_get_list (config, "cpus", &cpus, 0, 1)) {
-        int i, n_cpus = 0;
+        int n_cpus = 0;
 
         if (libxl_cpu_bitmap_alloc(ctx, &b_info->cpumap, 0)) {
             fprintf(stderr, "Unable to allocate cpumap\n");
@@ -1200,7 +1200,6 @@ skip_vfb:
     }
 
     if (!xlu_cfg_get_list (config, "pci", &pcis, 0, 0)) {
-        int i;
         d_config->num_pcidevs = 0;
         d_config->pcidevs = NULL;
         for(i = 0; (buf = xlu_cfg_get_listitem (pcis, i)) != NULL; i++) {
@@ -1223,7 +1222,6 @@ skip_vfb:
     switch (xlu_cfg_get_list(config, "cpuid", &cpuids, 0, 1)) {
     case 0:
         {
-            int i;
             const char *errstr;
 
             for (i = 0; (buf = xlu_cfg_get_listitem(cpuids, i)) != NULL; i++) {
@@ -1553,7 +1551,7 @@ static int preserve_domain(uint32_t *r_d
 {
     time_t now;
     struct tm tm;
-    char stime[24];
+    char strtime[24];
 
     libxl_uuid new_uuid;
 
@@ -1571,7 +1569,7 @@ static int preserve_domain(uint32_t *r_d
         return 0;
     }
 
-    if (!strftime(&stime[0], sizeof(stime), "-%Y%m%dT%H%MZ", &tm)) {
+    if (!strftime(&strtime[0], sizeof(strtime), "-%Y%m%dT%H%MZ", &tm)) {
         LOG("Failed to format time as a string");
         return 0;
     }
@@ -1579,9 +1577,9 @@ static int preserve_domain(uint32_t *r_d
     libxl_uuid_generate(&new_uuid);
 
     LOG("Preserving domain %d %s with suffix%s",
-        *r_domid, d_config->c_info.name, stime);
+        *r_domid, d_config->c_info.name, strtime);
     rc = libxl_domain_preserve(ctx, *r_domid, &d_config->c_info,
-                               stime, new_uuid);
+                               strtime, new_uuid);
 
     /*
      * Although the domain still exists it is no longer the one we are
@@ -2697,7 +2695,8 @@ static void destroy_domain(const char *p
     if (rc) { fprintf(stderr,"destroy failed (rc=%d)\n",rc); exit(-1); }
 }
 
-static void shutdown_domain(const char *p, int wait, int fallback_trigger)
+static void shutdown_domain(const char *p, int wait_for_it,
+                            int fallback_trigger)
 {
     int rc;
     libxl_event *event;
@@ -2719,7 +2718,7 @@ static void shutdown_domain(const char *
         fprintf(stderr,"shutdown failed (rc=%d)\n",rc);exit(-1);
     }
 
-    if (wait) {
+    if (wait_for_it) {
         libxl_evgen_domain_death *deathw;
 
         rc = libxl_evenable_domain_death(ctx, domid, 0, &deathw);
@@ -3685,7 +3684,7 @@ int main_destroy(int argc, char **argv)
 int main_shutdown(int argc, char **argv)
 {
     int opt;
-    int wait = 0;
+    int wait_for_it = 0;
     int fallback_trigger = 0;
 
     while ((opt = def_getopt(argc, argv, "wF", "shutdown", 1)) != -1) {
@@ -3693,7 +3692,7 @@ int main_shutdown(int argc, char **argv)
         case 0: case 2:
             return opt;
         case 'w':
-            wait = 1;
+            wait_for_it = 1;
             break;
         case 'F':
             fallback_trigger = 1;
@@ -3701,7 +3700,7 @@ int main_shutdown(int argc, char **argv)
         }
     }
 
-    shutdown_domain(argv[optind], wait, fallback_trigger);
+    shutdown_domain(argv[optind], wait_for_it, fallback_trigger);
     return 0;
 }
 
@@ -4461,7 +4460,7 @@ static void output_topologyinfo(void)
     return;
 }
 
-static void info(int numa)
+static void print_info(int numa)
 {
     output_nodeinfo();
 
@@ -4504,7 +4503,7 @@ int main_info(int argc, char **argv)
         }
     }
 
-    info(numa);
+    print_info(numa);
     return 0;
 }
 
@@ -5573,19 +5572,19 @@ int main_blockdetach(int argc, char **ar
     return rc;
 }
 
-static char *uptime_to_string(unsigned long time, int short_mode)
+static char *uptime_to_string(unsigned long uptime, int short_mode)
 {
     int sec, min, hour, day;
     char *time_string;
     int ret;
 
-    day = (int)(time / 86400);
-    time -= (day * 86400);
-    hour = (int)(time / 3600);
-    time -= (hour * 3600);
-    min = (int)(time / 60);
-    time -= (min * 60);
-    sec = time;
+    day = (int)(uptime / 86400);
+    uptime -= (day * 86400);
+    hour = (int)(uptime / 3600);
+    uptime -= (hour * 3600);
+    min = (int)(uptime / 60);
+    uptime -= (min * 60);
+    sec = uptime;
 
     if (short_mode)
         if (day > 1)
diff -r 58ab3fb73d13 -r 192e4a16a057 tools/libxl/xl_sxp.c
--- a/tools/libxl/xl_sxp.c	Fri Sep 14 12:09:43 2012 +0100
+++ b/tools/libxl/xl_sxp.c	Fri Sep 14 12:21:24 2012 +0100
@@ -78,7 +78,6 @@ void printf_info_sexp(int domid, libxl_d
            libxl_defbool_to_string(b_info->disable_migrate));
 
     if (c_info->type == LIBXL_DOMAIN_TYPE_PV && b_info->u.pv.bootloader) {
-        int i;
         printf("\t(bootloader %s)\n", b_info->u.pv.bootloader);
         if (b_info->u.pv.bootloader_args) {
             printf("\t(bootloader_args");

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 14 12:42:55 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 12: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 1TCVEB-0001w2-CB; Fri, 14 Sep 2012 12:42: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 1TCVE9-0001vd-B7
	for xen-devel@lists.xen.org; Fri, 14 Sep 2012 12:42:33 +0000
Received: from [85.158.139.83:8341] by server-7.bemta-5.messagelabs.com id
	4F/43-19703-83623505; Fri, 14 Sep 2012 12:42:32 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1347626549!16426476!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNjk2MTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21575 invoked from network); 14 Sep 2012 12:42:31 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-8.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Sep 2012 12:42:31 -0000
X-IronPort-AV: E=Sophos;i="4.80,422,1344211200"; d="scan'208";a="37881297"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Sep 2012 12:42:29 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Fri, 14 Sep 2012 08:42:29 -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 1TCVE4-0007Ic-Uq;
	Fri, 14 Sep 2012 13:42:28 +0100
MIME-Version: 1.0
X-Mercurial-Node: 192e4a16a057a456cc78e4ee46242315d474d116
Message-ID: <192e4a16a057a456cc78.1347626550@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1347626548@cosworth.uk.xensource.com>
References: <patchbomb.1347626548@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Fri, 14 Sep 2012 13:42:30 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 2 of 3] xl: prepare to enable Wshadow
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 1347621684 -3600
# Node ID 192e4a16a057a456cc78e4ee46242315d474d116
# Parent  58ab3fb73d13e250f334a38599b749640deac190
xl: prepare to enable Wshadow

Takes care of everything other than the global domid clashes.

Avoid galobal functions
  - stime(2)
  - time(2)

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r 58ab3fb73d13 -r 192e4a16a057 tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Fri Sep 14 12:09:43 2012 +0100
+++ b/tools/libxl/xl_cmdimpl.c	Fri Sep 14 12:21:24 2012 +0100
@@ -676,7 +676,7 @@ static void parse_config_data(const char
         b_info->max_vcpus = l;
 
     if (!xlu_cfg_get_list (config, "cpus", &cpus, 0, 1)) {
-        int i, n_cpus = 0;
+        int n_cpus = 0;
 
         if (libxl_cpu_bitmap_alloc(ctx, &b_info->cpumap, 0)) {
             fprintf(stderr, "Unable to allocate cpumap\n");
@@ -1200,7 +1200,6 @@ skip_vfb:
     }
 
     if (!xlu_cfg_get_list (config, "pci", &pcis, 0, 0)) {
-        int i;
         d_config->num_pcidevs = 0;
         d_config->pcidevs = NULL;
         for(i = 0; (buf = xlu_cfg_get_listitem (pcis, i)) != NULL; i++) {
@@ -1223,7 +1222,6 @@ skip_vfb:
     switch (xlu_cfg_get_list(config, "cpuid", &cpuids, 0, 1)) {
     case 0:
         {
-            int i;
             const char *errstr;
 
             for (i = 0; (buf = xlu_cfg_get_listitem(cpuids, i)) != NULL; i++) {
@@ -1553,7 +1551,7 @@ static int preserve_domain(uint32_t *r_d
 {
     time_t now;
     struct tm tm;
-    char stime[24];
+    char strtime[24];
 
     libxl_uuid new_uuid;
 
@@ -1571,7 +1569,7 @@ static int preserve_domain(uint32_t *r_d
         return 0;
     }
 
-    if (!strftime(&stime[0], sizeof(stime), "-%Y%m%dT%H%MZ", &tm)) {
+    if (!strftime(&strtime[0], sizeof(strtime), "-%Y%m%dT%H%MZ", &tm)) {
         LOG("Failed to format time as a string");
         return 0;
     }
@@ -1579,9 +1577,9 @@ static int preserve_domain(uint32_t *r_d
     libxl_uuid_generate(&new_uuid);
 
     LOG("Preserving domain %d %s with suffix%s",
-        *r_domid, d_config->c_info.name, stime);
+        *r_domid, d_config->c_info.name, strtime);
     rc = libxl_domain_preserve(ctx, *r_domid, &d_config->c_info,
-                               stime, new_uuid);
+                               strtime, new_uuid);
 
     /*
      * Although the domain still exists it is no longer the one we are
@@ -2697,7 +2695,8 @@ static void destroy_domain(const char *p
     if (rc) { fprintf(stderr,"destroy failed (rc=%d)\n",rc); exit(-1); }
 }
 
-static void shutdown_domain(const char *p, int wait, int fallback_trigger)
+static void shutdown_domain(const char *p, int wait_for_it,
+                            int fallback_trigger)
 {
     int rc;
     libxl_event *event;
@@ -2719,7 +2718,7 @@ static void shutdown_domain(const char *
         fprintf(stderr,"shutdown failed (rc=%d)\n",rc);exit(-1);
     }
 
-    if (wait) {
+    if (wait_for_it) {
         libxl_evgen_domain_death *deathw;
 
         rc = libxl_evenable_domain_death(ctx, domid, 0, &deathw);
@@ -3685,7 +3684,7 @@ int main_destroy(int argc, char **argv)
 int main_shutdown(int argc, char **argv)
 {
     int opt;
-    int wait = 0;
+    int wait_for_it = 0;
     int fallback_trigger = 0;
 
     while ((opt = def_getopt(argc, argv, "wF", "shutdown", 1)) != -1) {
@@ -3693,7 +3692,7 @@ int main_shutdown(int argc, char **argv)
         case 0: case 2:
             return opt;
         case 'w':
-            wait = 1;
+            wait_for_it = 1;
             break;
         case 'F':
             fallback_trigger = 1;
@@ -3701,7 +3700,7 @@ int main_shutdown(int argc, char **argv)
         }
     }
 
-    shutdown_domain(argv[optind], wait, fallback_trigger);
+    shutdown_domain(argv[optind], wait_for_it, fallback_trigger);
     return 0;
 }
 
@@ -4461,7 +4460,7 @@ static void output_topologyinfo(void)
     return;
 }
 
-static void info(int numa)
+static void print_info(int numa)
 {
     output_nodeinfo();
 
@@ -4504,7 +4503,7 @@ int main_info(int argc, char **argv)
         }
     }
 
-    info(numa);
+    print_info(numa);
     return 0;
 }
 
@@ -5573,19 +5572,19 @@ int main_blockdetach(int argc, char **ar
     return rc;
 }
 
-static char *uptime_to_string(unsigned long time, int short_mode)
+static char *uptime_to_string(unsigned long uptime, int short_mode)
 {
     int sec, min, hour, day;
     char *time_string;
     int ret;
 
-    day = (int)(time / 86400);
-    time -= (day * 86400);
-    hour = (int)(time / 3600);
-    time -= (hour * 3600);
-    min = (int)(time / 60);
-    time -= (min * 60);
-    sec = time;
+    day = (int)(uptime / 86400);
+    uptime -= (day * 86400);
+    hour = (int)(uptime / 3600);
+    uptime -= (hour * 3600);
+    min = (int)(uptime / 60);
+    uptime -= (min * 60);
+    sec = uptime;
 
     if (short_mode)
         if (day > 1)
diff -r 58ab3fb73d13 -r 192e4a16a057 tools/libxl/xl_sxp.c
--- a/tools/libxl/xl_sxp.c	Fri Sep 14 12:09:43 2012 +0100
+++ b/tools/libxl/xl_sxp.c	Fri Sep 14 12:21:24 2012 +0100
@@ -78,7 +78,6 @@ void printf_info_sexp(int domid, libxl_d
            libxl_defbool_to_string(b_info->disable_migrate));
 
     if (c_info->type == LIBXL_DOMAIN_TYPE_PV && b_info->u.pv.bootloader) {
-        int i;
         printf("\t(bootloader %s)\n", b_info->u.pv.bootloader);
         if (b_info->u.pv.bootloader_args) {
             printf("\t(bootloader_args");

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 14 12:47:33 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 12:47:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TCVIm-0002UU-6d; Fri, 14 Sep 2012 12:47:20 +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 1TCVIl-0002U1-CA
	for xen-devel@lists.xen.org; Fri, 14 Sep 2012 12:47:19 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1347626832!5852818!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDkyOTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12774 invoked from network); 14 Sep 2012 12:47:12 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Sep 2012 12:47:12 -0000
X-IronPort-AV: E=Sophos;i="4.80,422,1344211200"; d="scan'208";a="14546095"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Sep 2012 12: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.279.1;
	Fri, 14 Sep 2012 13:47:11 +0100
Message-ID: <1347626830.24226.183.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, 14 Sep 2012 13:47:10 +0100
In-Reply-To: <8fad3481f8c90bb66fff.1347626551@cosworth.uk.xensource.com>
References: <patchbomb.1347626548@cosworth.uk.xensource.com>
	<8fad3481f8c90bb66fff.1347626551@cosworth.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 3 of 3] xl: Remove global domid and enable
 -Wshadow
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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-09-14 at 13:42 +0100, Ian Campbell wrote:
> I find it hard to believe I won't have broken anything here... I
> tested basic lifecycle ops only. 

I should have taken this bet :-/

Incremental fixup to the patch below... (could be folded in)

8<--------------------------------------------------

xl: make sure we always use the result of find_domain

This is a leftover from when domid was a global.

Annotate it with want_unused_result and fix the handful of errors.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r 8fad3481f8c9 tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Fri Sep 14 13:40:49 2012 +0100
+++ b/tools/libxl/xl_cmdimpl.c	Fri Sep 14 13:45:23 2012 +0100
@@ -195,6 +195,7 @@ static int cpupool_qualifier_to_cpupooli
     return was_name ? libxl_name_to_cpupoolid(ctx, p, poolid_r) : 0;
 }
 
+static uint32_t find_domain(const char *p) __attribute__((warn_unused_result));
 static uint32_t find_domain(const char *p)
 {
     uint32_t domid;
@@ -5807,7 +5808,7 @@ int main_tmem_freeze(int argc, char **ar
     if (all)
         domid = INVALID_DOMID;
     else
-        find_domain(dom);
+        domid = find_domain(dom);
 
     libxl_tmem_freeze(ctx, domid);
     return 0;
@@ -5840,7 +5841,7 @@ int main_tmem_thaw(int argc, char **argv
     if (all)
         domid = INVALID_DOMID;
     else
-        find_domain(dom);
+        domid = find_domain(dom);
 
     libxl_tmem_thaw(ctx, domid);
     return 0;
@@ -5887,7 +5888,7 @@ int main_tmem_set(int argc, char **argv)
     if (all)
         domid = INVALID_DOMID;
     else
-        find_domain(dom);
+        domid = find_domain(dom);
 
     if (!opt_w && !opt_c && !opt_p) {
         fprintf(stderr, "No set value specified.\n\n");
@@ -5942,7 +5943,7 @@ int main_tmem_shared_auth(int argc, char
     if (all)
         domid = INVALID_DOMID;
     else
-        find_domain(dom);
+        domid = find_domain(dom);
 
     if (uuid == NULL || autharg == NULL) {
         fprintf(stderr, "No uuid or auth specified.\n\n");




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 14 12:47:33 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 12:47:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TCVIm-0002UU-6d; Fri, 14 Sep 2012 12:47:20 +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 1TCVIl-0002U1-CA
	for xen-devel@lists.xen.org; Fri, 14 Sep 2012 12:47:19 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1347626832!5852818!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDkyOTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12774 invoked from network); 14 Sep 2012 12:47:12 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Sep 2012 12:47:12 -0000
X-IronPort-AV: E=Sophos;i="4.80,422,1344211200"; d="scan'208";a="14546095"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Sep 2012 12: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.279.1;
	Fri, 14 Sep 2012 13:47:11 +0100
Message-ID: <1347626830.24226.183.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, 14 Sep 2012 13:47:10 +0100
In-Reply-To: <8fad3481f8c90bb66fff.1347626551@cosworth.uk.xensource.com>
References: <patchbomb.1347626548@cosworth.uk.xensource.com>
	<8fad3481f8c90bb66fff.1347626551@cosworth.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 3 of 3] xl: Remove global domid and enable
 -Wshadow
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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-09-14 at 13:42 +0100, Ian Campbell wrote:
> I find it hard to believe I won't have broken anything here... I
> tested basic lifecycle ops only. 

I should have taken this bet :-/

Incremental fixup to the patch below... (could be folded in)

8<--------------------------------------------------

xl: make sure we always use the result of find_domain

This is a leftover from when domid was a global.

Annotate it with want_unused_result and fix the handful of errors.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r 8fad3481f8c9 tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Fri Sep 14 13:40:49 2012 +0100
+++ b/tools/libxl/xl_cmdimpl.c	Fri Sep 14 13:45:23 2012 +0100
@@ -195,6 +195,7 @@ static int cpupool_qualifier_to_cpupooli
     return was_name ? libxl_name_to_cpupoolid(ctx, p, poolid_r) : 0;
 }
 
+static uint32_t find_domain(const char *p) __attribute__((warn_unused_result));
 static uint32_t find_domain(const char *p)
 {
     uint32_t domid;
@@ -5807,7 +5808,7 @@ int main_tmem_freeze(int argc, char **ar
     if (all)
         domid = INVALID_DOMID;
     else
-        find_domain(dom);
+        domid = find_domain(dom);
 
     libxl_tmem_freeze(ctx, domid);
     return 0;
@@ -5840,7 +5841,7 @@ int main_tmem_thaw(int argc, char **argv
     if (all)
         domid = INVALID_DOMID;
     else
-        find_domain(dom);
+        domid = find_domain(dom);
 
     libxl_tmem_thaw(ctx, domid);
     return 0;
@@ -5887,7 +5888,7 @@ int main_tmem_set(int argc, char **argv)
     if (all)
         domid = INVALID_DOMID;
     else
-        find_domain(dom);
+        domid = find_domain(dom);
 
     if (!opt_w && !opt_c && !opt_p) {
         fprintf(stderr, "No set value specified.\n\n");
@@ -5942,7 +5943,7 @@ int main_tmem_shared_auth(int argc, char
     if (all)
         domid = INVALID_DOMID;
     else
-        find_domain(dom);
+        domid = find_domain(dom);
 
     if (uuid == NULL || autharg == NULL) {
         fprintf(stderr, "No uuid or auth specified.\n\n");




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 14 12:49:32 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 12:49:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TCVKh-0002dV-Ok; Fri, 14 Sep 2012 12:49:19 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1TCVKg-0002dD-W3
	for xen-devel@lists.xensource.com; Fri, 14 Sep 2012 12:49:19 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1347626952!11045720!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDkyOTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4195 invoked from network); 14 Sep 2012 12:49:13 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Sep 2012 12:49:13 -0000
X-IronPort-AV: E=Sophos;i="4.80,422,1344211200"; d="scan'208";a="14546136"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Sep 2012 12:49: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.279.1; Fri, 14 Sep 2012 13:49:12 +0100
Date: Fri, 14 Sep 2012 13:48:29 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Pawel Moll <pawel.moll@arm.com>
In-Reply-To: <1347625628.2497.65.camel@hornet>
Message-ID: <alpine.DEB.2.02.1209141347250.29232@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1209141145150.29232@kaball.uk.xensource.com>
	<1347621207-11294-21-git-send-email-stefano.stabellini@eu.citrix.com>
	<1347625628.2497.65.camel@hornet>
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>,
	"linaro-dev@lists.linaro.org" <linaro-dev@lists.linaro.org>,
	Ian Campbell <Ian.Campbell@citrix.com>, "arnd@arndb.de" <arnd@arndb.de>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Marc Zyngier <Marc.Zyngier@arm.com>,
	Catalin Marinas <Catalin.Marinas@arm.com>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
	"Tim \(Xen.org\)" <tim@xen.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux@arm.linux.org.uk" <linux@arm.linux.org.uk>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Xen-devel] [PATCH v4 21/24] arm/v2m: initialize arch_timers
 even if v2m_timer is not present
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 14 Sep 2012, Pawel Moll wrote:
> On Fri, 2012-09-14 at 12:13 +0100, Stefano Stabellini wrote:
> > Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> > CC: Russell King <linux@arm.linux.org.uk>
> > CC: Pawel Moll <pawel.moll@arm.com>
> > CC: Marc Zyngier <marc.zyngier@arm.com>
> > ---
> >  arch/arm/mach-vexpress/v2m.c |   11 ++++++-----
> >  1 files changed, 6 insertions(+), 5 deletions(-)
> > 
> > diff --git a/arch/arm/mach-vexpress/v2m.c b/arch/arm/mach-vexpress/v2m.c
> > index 37608f2..4e567f7 100644
> > --- a/arch/arm/mach-vexpress/v2m.c
> > +++ b/arch/arm/mach-vexpress/v2m.c
> > @@ -621,16 +621,17 @@ static void __init v2m_dt_timer_init(void)
> >  
> >  	v2m_clk_init();
> >  
> > -	err = of_property_read_string(of_aliases, "arm,v2m_timer", &path);
> > -	if (WARN_ON(err))
> > -		return;
> > -	node = of_find_node_by_path(path);
> > -	v2m_sp804_init(of_iomap(node, 0), irq_of_parse_and_map(node, 0));
> >  	if (arch_timer_of_register() != 0)
> >  		twd_local_timer_of_register();
> >  
> >  	if (arch_timer_sched_clock_init() != 0)
> >  		versatile_sched_clock_init(v2m_sysreg_base + V2M_SYS_24MHZ, 24000000);
> > +
> > +	err = of_property_read_string(of_aliases, "arm,v2m_timer", &path);
> > +	if (WARN_ON(err))
> > +		return;
> > +	node = of_find_node_by_path(path);
> > +	v2m_sp804_init(of_iomap(node, 0), irq_of_parse_and_map(node, 0));
> >  }
> >  
> >  static struct sys_timer v2m_dt_timer = {
> 
> Fair point. The alias is going to disappear anyway (I'm working on a VE
> platform rework right now), but in case I won't get it on time for 3.7,
> I'll make sure this one is merged instead.

Great, thanks!
Should I leave this patch out of the Xen on ARM series for 3.7 then?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 14 12:49:32 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 12:49:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TCVKh-0002dV-Ok; Fri, 14 Sep 2012 12:49:19 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1TCVKg-0002dD-W3
	for xen-devel@lists.xensource.com; Fri, 14 Sep 2012 12:49:19 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1347626952!11045720!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDkyOTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4195 invoked from network); 14 Sep 2012 12:49:13 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Sep 2012 12:49:13 -0000
X-IronPort-AV: E=Sophos;i="4.80,422,1344211200"; d="scan'208";a="14546136"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Sep 2012 12:49: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.279.1; Fri, 14 Sep 2012 13:49:12 +0100
Date: Fri, 14 Sep 2012 13:48:29 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Pawel Moll <pawel.moll@arm.com>
In-Reply-To: <1347625628.2497.65.camel@hornet>
Message-ID: <alpine.DEB.2.02.1209141347250.29232@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1209141145150.29232@kaball.uk.xensource.com>
	<1347621207-11294-21-git-send-email-stefano.stabellini@eu.citrix.com>
	<1347625628.2497.65.camel@hornet>
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>,
	"linaro-dev@lists.linaro.org" <linaro-dev@lists.linaro.org>,
	Ian Campbell <Ian.Campbell@citrix.com>, "arnd@arndb.de" <arnd@arndb.de>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Marc Zyngier <Marc.Zyngier@arm.com>,
	Catalin Marinas <Catalin.Marinas@arm.com>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
	"Tim \(Xen.org\)" <tim@xen.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux@arm.linux.org.uk" <linux@arm.linux.org.uk>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Xen-devel] [PATCH v4 21/24] arm/v2m: initialize arch_timers
 even if v2m_timer is not present
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 14 Sep 2012, Pawel Moll wrote:
> On Fri, 2012-09-14 at 12:13 +0100, Stefano Stabellini wrote:
> > Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> > CC: Russell King <linux@arm.linux.org.uk>
> > CC: Pawel Moll <pawel.moll@arm.com>
> > CC: Marc Zyngier <marc.zyngier@arm.com>
> > ---
> >  arch/arm/mach-vexpress/v2m.c |   11 ++++++-----
> >  1 files changed, 6 insertions(+), 5 deletions(-)
> > 
> > diff --git a/arch/arm/mach-vexpress/v2m.c b/arch/arm/mach-vexpress/v2m.c
> > index 37608f2..4e567f7 100644
> > --- a/arch/arm/mach-vexpress/v2m.c
> > +++ b/arch/arm/mach-vexpress/v2m.c
> > @@ -621,16 +621,17 @@ static void __init v2m_dt_timer_init(void)
> >  
> >  	v2m_clk_init();
> >  
> > -	err = of_property_read_string(of_aliases, "arm,v2m_timer", &path);
> > -	if (WARN_ON(err))
> > -		return;
> > -	node = of_find_node_by_path(path);
> > -	v2m_sp804_init(of_iomap(node, 0), irq_of_parse_and_map(node, 0));
> >  	if (arch_timer_of_register() != 0)
> >  		twd_local_timer_of_register();
> >  
> >  	if (arch_timer_sched_clock_init() != 0)
> >  		versatile_sched_clock_init(v2m_sysreg_base + V2M_SYS_24MHZ, 24000000);
> > +
> > +	err = of_property_read_string(of_aliases, "arm,v2m_timer", &path);
> > +	if (WARN_ON(err))
> > +		return;
> > +	node = of_find_node_by_path(path);
> > +	v2m_sp804_init(of_iomap(node, 0), irq_of_parse_and_map(node, 0));
> >  }
> >  
> >  static struct sys_timer v2m_dt_timer = {
> 
> Fair point. The alias is going to disappear anyway (I'm working on a VE
> platform rework right now), but in case I won't get it on time for 3.7,
> I'll make sure this one is merged instead.

Great, thanks!
Should I leave this patch out of the Xen on ARM series for 3.7 then?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 14 13:00:45 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 13: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 1TCVVX-0002sR-Ur; Fri, 14 Sep 2012 13:00: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 1TCVVW-0002sM-CS
	for xen-devel@lists.xensource.com; Fri, 14 Sep 2012 13:00:30 +0000
Received: from [85.158.143.99:4986] by server-1.bemta-4.messagelabs.com id
	69/92-12504-D6A23505; Fri, 14 Sep 2012 13:00:29 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1347627619!30030163!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDkyOTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19038 invoked from network); 14 Sep 2012 13:00:29 -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;
	14 Sep 2012 13:00:29 -0000
X-IronPort-AV: E=Sophos;i="4.80,422,1344211200"; d="scan'208";a="14546460"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Sep 2012 12: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.279.1;
	Fri, 14 Sep 2012 13:59:48 +0100
Message-ID: <1347627587.24226.192.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Fri, 14 Sep 2012 13:59:47 +0100
In-Reply-To: <1345633688-31684-1-git-send-email-stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.02.1208221159560.15568@kaball.uk.xensource.com>
	<1345633688-31684-1-git-send-email-stefano.stabellini@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-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 v4 1/6] xen: improve changes to
	xen_add_to_physmap
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


On Wed, 2012-08-22 at 12:08 +0100, Stefano Stabellini wrote:
> This is an incremental patch on top of
> c0bc926083b5987a3e9944eec2c12ad0580100e2: in order to retain binary
> compatibility, it is better to introduce foreign_domid as part of a
> union containing both size and foreign_domid.
[...]
> diff --git a/xen/include/public/memory.h b/xen/include/public/memory.h
> index b2adfbe..7d4ee26 100644
> --- a/xen/include/public/memory.h
> +++ b/xen/include/public/memory.h
> @@ -208,8 +208,12 @@ struct xen_add_to_physmap {
>      /* Which domain to change the mapping for. */
>      domid_t domid;
>  
> -    /* Number of pages to go through for gmfn_range */
> -    uint16_t    size;
> +    union {
> +        /* Number of pages to go through for gmfn_range */
> +        uint16_t    size;
> +        /* IFF gmfn_foreign */
> +        domid_t foreign_domid;
> +    } u;
>  
>      /* Source mapping space. */
>  #define XENMAPSPACE_shared_info  0 /* shared info page */
> @@ -217,8 +221,7 @@ struct xen_add_to_physmap {
>  #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 */
> +    unsigned int space;
>  
>  #define XENMAPIDX_grant_table_status 0x80000000

Was this the final consensus on what this interface ought to look like?

Does it work for PVH too (Mukesh CCd)?

Might we prefer to have a batched version of this call? I don't think we
can shoehorn the necessary fields into xen_add_to_physmap_t though.

Do we think libxc will ever want to call a batch version of
XENMAPSPACE_gmfn_foreign ? If not then we can probably get away using
multicall batching. If yes then perhaps not -- libxc doesn'tdo
multicalls.

XENMAPSPACE_gmfn_range was added to avoid an issue with tonnes of
(iommu?) flushes when remapping large numbers of pages with
XENMAPSPACE_gmfn. It seems like XENMAPSPACE_gmfn_foreign  could suffer
the same issue, in which case multicalls won't cut it.

I guess XENMAPSPACE_gmfn_range works only on contiguous ranges in both P
and M space? That style probably doesn't work for foreign anyway (where
at least the M isn't going to be contiguous)

Sorry for not thinking about this until after all the faff with unions
was done...

Ian.





_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 14 13:00:45 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 13: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 1TCVVX-0002sR-Ur; Fri, 14 Sep 2012 13:00: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 1TCVVW-0002sM-CS
	for xen-devel@lists.xensource.com; Fri, 14 Sep 2012 13:00:30 +0000
Received: from [85.158.143.99:4986] by server-1.bemta-4.messagelabs.com id
	69/92-12504-D6A23505; Fri, 14 Sep 2012 13:00:29 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1347627619!30030163!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDkyOTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19038 invoked from network); 14 Sep 2012 13:00:29 -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;
	14 Sep 2012 13:00:29 -0000
X-IronPort-AV: E=Sophos;i="4.80,422,1344211200"; d="scan'208";a="14546460"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Sep 2012 12: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.279.1;
	Fri, 14 Sep 2012 13:59:48 +0100
Message-ID: <1347627587.24226.192.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Fri, 14 Sep 2012 13:59:47 +0100
In-Reply-To: <1345633688-31684-1-git-send-email-stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.02.1208221159560.15568@kaball.uk.xensource.com>
	<1345633688-31684-1-git-send-email-stefano.stabellini@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-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 v4 1/6] xen: improve changes to
	xen_add_to_physmap
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


On Wed, 2012-08-22 at 12:08 +0100, Stefano Stabellini wrote:
> This is an incremental patch on top of
> c0bc926083b5987a3e9944eec2c12ad0580100e2: in order to retain binary
> compatibility, it is better to introduce foreign_domid as part of a
> union containing both size and foreign_domid.
[...]
> diff --git a/xen/include/public/memory.h b/xen/include/public/memory.h
> index b2adfbe..7d4ee26 100644
> --- a/xen/include/public/memory.h
> +++ b/xen/include/public/memory.h
> @@ -208,8 +208,12 @@ struct xen_add_to_physmap {
>      /* Which domain to change the mapping for. */
>      domid_t domid;
>  
> -    /* Number of pages to go through for gmfn_range */
> -    uint16_t    size;
> +    union {
> +        /* Number of pages to go through for gmfn_range */
> +        uint16_t    size;
> +        /* IFF gmfn_foreign */
> +        domid_t foreign_domid;
> +    } u;
>  
>      /* Source mapping space. */
>  #define XENMAPSPACE_shared_info  0 /* shared info page */
> @@ -217,8 +221,7 @@ struct xen_add_to_physmap {
>  #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 */
> +    unsigned int space;
>  
>  #define XENMAPIDX_grant_table_status 0x80000000

Was this the final consensus on what this interface ought to look like?

Does it work for PVH too (Mukesh CCd)?

Might we prefer to have a batched version of this call? I don't think we
can shoehorn the necessary fields into xen_add_to_physmap_t though.

Do we think libxc will ever want to call a batch version of
XENMAPSPACE_gmfn_foreign ? If not then we can probably get away using
multicall batching. If yes then perhaps not -- libxc doesn'tdo
multicalls.

XENMAPSPACE_gmfn_range was added to avoid an issue with tonnes of
(iommu?) flushes when remapping large numbers of pages with
XENMAPSPACE_gmfn. It seems like XENMAPSPACE_gmfn_foreign  could suffer
the same issue, in which case multicalls won't cut it.

I guess XENMAPSPACE_gmfn_range works only on contiguous ranges in both P
and M space? That style probably doesn't work for foreign anyway (where
at least the M isn't going to be contiguous)

Sorry for not thinking about this until after all the faff with unions
was done...

Ian.





_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 14 13:02:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 13:02:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TCVXB-0002wq-Es; Fri, 14 Sep 2012 13:02:13 +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 1TCVX9-0002wb-AP
	for xen-devel@lists.xen.org; Fri, 14 Sep 2012 13:02:11 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1347627723!4024618!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3170 invoked from network); 14 Sep 2012 13:02:03 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-14.tower-27.messagelabs.com with SMTP;
	14 Sep 2012 13:02:03 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 14 Sep 2012 14:02:03 +0100
Message-Id: <50534722020000780009B70D@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 14 Sep 2012 14:02: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="=__Part52635C12.0__="
Subject: [Xen-devel] [PATCH] xenpm: make argument parsing and error handling
 more consistent
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
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.

--=__Part52635C12.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Specifically, what values are or aren't accepted as CPU identifier, and
how the values get interpreted should be consistent across sub-commands
(intended behavior now: non-negative values are okay, and along with
omitting the argument, specifying "all" will also be accepted).

For error handling, error messages should get consistently issued to
stderr, and the tool should now (hopefully) produce an exit code of
zero only in the (partial) success case (there may still be a small
number of questionable cases).

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/tools/misc/xenpm.c
+++ b/tools/misc/xenpm.c
@@ -36,7 +36,7 @@
 #define CPUFREQ_TURBO_ENABLED       1
=20
 static xc_interface *xc_handle;
-static int max_cpu_nr;
+static unsigned int max_cpu_nr;
=20
 /* help message */
 void show_help(void)
@@ -77,6 +77,33 @@ void help_func(int argc, char *argv[])
     show_help();
 }
=20
+static void parse_cpuid(const char *arg, int *cpuid)
+{
+    if ( sscanf(arg, "%d", cpuid) !=3D 1 || *cpuid < 0 )
+    {
+        if ( strcasecmp(arg, "all") )
+        {
+            fprintf(stderr, "Invalid CPU identifier: '%s'\n", arg);
+            exit(EINVAL);
+        }
+        *cpuid =3D -1;
+    }
+}
+
+static void parse_cpuid_and_int(int argc, char *argv[],
+                                int *cpuid, int *val, const char *what)
+{
+    if ( argc > 1 )
+        parse_cpuid(argv[0], cpuid);
+
+    if ( argc =3D=3D 0 || sscanf(argv[argc > 1], "%d", val) !=3D 1 )
+    {
+        fprintf(stderr, argc ? "Invalid %s '%s'\n" : "Missing %s\n",
+                what, argv[argc > 1]);
+        exit(EINVAL);
+    }
+}
+
 static void print_cxstat(int cpuid, struct xc_cx_stat *cxstat)
 {
     int i;
@@ -166,7 +193,8 @@ static int show_cxstat_by_cpuid(xc_inter
     if ( ret )
     {
         if ( ret =3D=3D -ENODEV )
-            printf("Either xen cpuidle is disabled or no valid information=
 is registered!\n");
+            fprintf(stderr,
+                    "Either Xen cpuidle is disabled or no valid informatio=
n is registered!\n");
         return ret;
     }
=20
@@ -181,11 +209,8 @@ void cxstat_func(int argc, char *argv[])
 {
     int cpuid =3D -1;
=20
-    if ( argc > 0 && sscanf(argv[0], "%d", &cpuid) !=3D 1 )
-        cpuid =3D -1;
-
-    if ( cpuid >=3D max_cpu_nr )
-        cpuid =3D -1;
+    if ( argc > 0 )
+        parse_cpuid(argv[0], &cpuid);
=20
     show_max_cstate(xc_handle);
=20
@@ -294,11 +319,8 @@ void pxstat_func(int argc, char *argv[])
 {
     int cpuid =3D -1;
=20
-    if ( argc > 0 && sscanf(argv[0], "%d", &cpuid) !=3D 1 )
-        cpuid =3D -1;
-
-    if ( cpuid >=3D max_cpu_nr )
-        cpuid =3D -1;
+    if ( argc > 0 )
+        parse_cpuid(argv[0], &cpuid);
=20
     if ( cpuid < 0 )
     {
@@ -338,10 +360,10 @@ static void signal_int_handler(int signo
 	goto out;
     }
=20
-    if ( gettimeofday(&tv, NULL) =3D=3D -1 )
+    if ( gettimeofday(&tv, NULL) )
     {
         fprintf(stderr, "failed to get timeofday\n");
-        goto out ;
+        goto out;
     }
     usec_end =3D tv.tv_sec * 1000000UL + tv.tv_usec;
=20
@@ -541,7 +563,7 @@ void start_gather_func(int argc, char *a
             printf("Timeout set to %d seconds\n", timeout);
     }
=20
-    if ( gettimeofday(&tv, NULL) =3D=3D -1 )
+    if ( gettimeofday(&tv, NULL) )
     {
         fprintf(stderr, "failed to get timeofday\n");
         return ;
@@ -766,11 +788,8 @@ void cpufreq_para_func(int argc, char *a
 {
     int cpuid =3D -1;
=20
-    if ( argc > 0 && sscanf(argv[0], "%d", &cpuid) !=3D 1 )
-        cpuid =3D -1;
-
-    if ( cpuid >=3D max_cpu_nr )
-        cpuid =3D -1;
+    if ( argc > 0 )
+        parse_cpuid(argv[0], &cpuid);
=20
     if ( cpuid < 0 )
     {
@@ -788,26 +807,22 @@ void scaling_max_freq_func(int argc, cha
 {
     int cpuid =3D -1, freq =3D -1;
=20
-    if ( (argc >=3D 2 && (sscanf(argv[1], "%d", &freq) !=3D 1 ||
-                        sscanf(argv[0], "%d", &cpuid) !=3D 1)) ||
-         (argc =3D=3D 1 && sscanf(argv[0], "%d", &freq) !=3D 1 ) ||
-         argc =3D=3D 0 )
-    {
-        fprintf(stderr, "failed to set scaling max freq\n");
-        return ;
-    }
+    parse_cpuid_and_int(argc, argv, &cpuid, &freq, "frequency");
=20
     if ( cpuid < 0 )
     {
         int i;
         for ( i =3D 0; i < max_cpu_nr; i++ )
             if ( xc_set_cpufreq_para(xc_handle, i, SCALING_MAX_FREQ, =
freq) )
-                fprintf(stderr, "[CPU%d] failed to set scaling max =
freq\n", i);
+                fprintf(stderr,
+                        "[CPU%d] failed to set scaling max freq (%d - =
%s)\n",
+                        i, errno, strerror(errno));
     }
     else
     {
         if ( xc_set_cpufreq_para(xc_handle, cpuid, SCALING_MAX_FREQ, =
freq) )
-            fprintf(stderr, "failed to set scaling max freq\n");
+            fprintf(stderr, "failed to set scaling max freq (%d - %s)\n",
+                    errno, strerror(errno));
     }
 }
=20
@@ -815,26 +830,22 @@ void scaling_min_freq_func(int argc, cha
 {
     int cpuid =3D -1, freq =3D -1;
=20
-    if ( (argc >=3D 2 && (sscanf(argv[1], "%d", &freq) !=3D 1 ||
-                        sscanf(argv[0], "%d", &cpuid) !=3D 1) ) ||
-         (argc =3D=3D 1 && sscanf(argv[0], "%d", &freq) !=3D 1 ) ||
-         argc =3D=3D 0 )
-    {
-        fprintf(stderr, "failed to set scaling min freq\n");
-        return ;
-    }
+    parse_cpuid_and_int(argc, argv, &cpuid, &freq, "frequency");
=20
     if ( cpuid < 0 )
     {
         int i;
         for ( i =3D 0; i < max_cpu_nr; i++ )
             if ( xc_set_cpufreq_para(xc_handle, i, SCALING_MIN_FREQ, =
freq) )
-                fprintf(stderr, "[CPU%d] failed to set scaling min =
freq\n", i);
+                fprintf(stderr,
+                        "[CPU%d] failed to set scaling min freq (%d - =
%s)\n",
+                        i, errno, strerror(errno));
     }
     else
     {
         if ( xc_set_cpufreq_para(xc_handle, cpuid, SCALING_MIN_FREQ, =
freq) )
-            fprintf(stderr, "failed to set scaling min freq\n");
+            fprintf(stderr, "failed to set scaling min freq (%d - %s)\n",
+                    errno, strerror(errno));
     }
 }
=20
@@ -842,26 +853,22 @@ void scaling_speed_func(int argc, char *
 {
     int cpuid =3D -1, speed =3D -1;
=20
-    if ( (argc >=3D 2 && (sscanf(argv[1], "%d", &speed) !=3D 1 ||
-                        sscanf(argv[0], "%d", &cpuid) !=3D 1) ) ||
-         (argc =3D=3D 1 && sscanf(argv[0], "%d", &speed) !=3D 1 ) ||
-         argc =3D=3D 0 )
-    {
-        fprintf(stderr, "failed to set scaling speed\n");
-        return ;
-    }
+    parse_cpuid_and_int(argc, argv, &cpuid, &speed, "speed");
=20
     if ( cpuid < 0 )
     {
         int i;
         for ( i =3D 0; i < max_cpu_nr; i++ )
             if ( xc_set_cpufreq_para(xc_handle, i, SCALING_SETSPEED, =
speed) )
-                fprintf(stderr, "[CPU%d] failed to set scaling speed\n", =
i);
+                fprintf(stderr,
+                        "[CPU%d] failed to set scaling speed (%d - =
%s)\n",
+                        i, errno, strerror(errno));
     }
     else
     {
         if ( xc_set_cpufreq_para(xc_handle, cpuid, SCALING_SETSPEED, =
speed) )
-            fprintf(stderr, "failed to set scaling speed\n");
+            fprintf(stderr, "failed to set scaling speed (%d - %s)\n",
+                    errno, strerror(errno));
     }
 }
=20
@@ -869,14 +876,7 @@ void scaling_sampling_rate_func(int argc
 {
     int cpuid =3D -1, rate =3D -1;
=20
-    if ( (argc >=3D 2 && (sscanf(argv[1], "%d", &rate) !=3D 1 ||
-                        sscanf(argv[0], "%d", &cpuid) !=3D 1) ) ||
-         (argc =3D=3D 1 && sscanf(argv[0], "%d", &rate) !=3D 1 ) ||
-         argc =3D=3D 0 )
-    {
-        fprintf(stderr, "failed to set scaling sampling rate\n");
-        return ;
-    }
+    parse_cpuid_and_int(argc, argv, &cpuid, &rate, "rate");
=20
     if ( cpuid < 0 )
     {
@@ -884,12 +884,14 @@ void scaling_sampling_rate_func(int argc
         for ( i =3D 0; i < max_cpu_nr; i++ )
             if ( xc_set_cpufreq_para(xc_handle, i, SAMPLING_RATE, rate) )
                 fprintf(stderr,
-                        "[CPU%d] failed to set scaling sampling rate\n", =
i);
+                        "[CPU%d] failed to set scaling sampling rate (%d =
- %s)\n",
+                        i, errno, strerror(errno));
     }
     else
     {
         if ( xc_set_cpufreq_para(xc_handle, cpuid, SAMPLING_RATE, rate) )
-            fprintf(stderr, "failed to set scaling sampling rate\n");
+            fprintf(stderr, "failed to set scaling sampling rate (%d - =
%s)\n",
+                    errno, strerror(errno));
     }
 }
=20
@@ -897,14 +899,7 @@ void scaling_up_threshold_func(int argc,
 {
     int cpuid =3D -1, threshold =3D -1;
=20
-    if ( (argc >=3D 2 && (sscanf(argv[1], "%d", &threshold) !=3D 1 ||
-                        sscanf(argv[0], "%d", &cpuid) !=3D 1) ) ||
-         (argc =3D=3D 1 && sscanf(argv[0], "%d", &threshold) !=3D 1 ) ||
-         argc =3D=3D 0 )
-    {
-        fprintf(stderr, "failed to set up scaling threshold\n");
-        return ;
-    }
+    parse_cpuid_and_int(argc, argv, &cpuid, &threshold, "threshold");
=20
     if ( cpuid < 0 )
     {
@@ -912,57 +907,49 @@ void scaling_up_threshold_func(int argc,
         for ( i =3D 0; i < max_cpu_nr; i++ )
             if ( xc_set_cpufreq_para(xc_handle, i, UP_THRESHOLD, =
threshold) )
                 fprintf(stderr,
-                        "[CPU%d] failed to set up scaling threshold\n", =
i);
+                        "[CPU%d] failed to set up scaling threshold (%d - =
%s)\n",
+                        i, errno, strerror(errno));
     }
     else
     {
         if ( xc_set_cpufreq_para(xc_handle, cpuid, UP_THRESHOLD, =
threshold) )
-            fprintf(stderr, "failed to set up scaling threshold\n");
+            fprintf(stderr, "failed to set up scaling threshold (%d - =
%s)\n",
+                    errno, strerror(errno));
     }
 }
=20
 void scaling_governor_func(int argc, char *argv[])
 {
     int cpuid =3D -1;
-    char *name =3D NULL;
+    char *name;
=20
     if ( argc >=3D 2 )
     {
-        name =3D strdup(argv[1]);
-        if ( name =3D=3D NULL )
-            goto out;
-        if ( sscanf(argv[0], "%d", &cpuid) !=3D 1 )
-        {
-            free(name);
-            goto out;
-        }
+        parse_cpuid(argv[0], &cpuid);
+        name =3D argv[1];
     }
     else if ( argc > 0 )
+        name =3D argv[0];
+    else
     {
-        name =3D strdup(argv[0]);
-        if ( name =3D=3D NULL )
-            goto out;
+        fprintf(stderr, "Missing argument(s)\n");
+        exit(EINVAL);
     }
-    else
-        goto out;
=20
     if ( cpuid < 0 )
     {
         int i;
         for ( i =3D 0; i < max_cpu_nr; i++ )
             if ( xc_set_cpufreq_gov(xc_handle, i, name) )
-                fprintf(stderr, "[CPU%d] failed to set governor name\n", =
i);
+                fprintf(stderr, "[CPU%d] failed to set governor name (%d =
- %s)\n",
+                        i, errno, strerror(errno));
     }
     else
     {
         if ( xc_set_cpufreq_gov(xc_handle, cpuid, name) )
-            fprintf(stderr, "failed to set governor name\n");
+            fprintf(stderr, "failed to set governor name (%d - %s)\n",
+                    errno, strerror(errno));
     }
-
-    free(name);
-    return ;
-out:
-    fprintf(stderr, "failed to set governor name\n");
 }
=20
 void cpu_topology_func(int argc, char *argv[])
@@ -971,7 +958,7 @@ void cpu_topology_func(int argc, char *a
     DECLARE_HYPERCALL_BUFFER(uint32_t, cpu_to_socket);
     DECLARE_HYPERCALL_BUFFER(uint32_t, cpu_to_node);
     xc_topologyinfo_t info =3D { 0 };
-    int i;
+    int i, rc =3D ENOMEM;
=20
     cpu_to_core =3D xc_hypercall_buffer_alloc(xc_handle, cpu_to_core, =
sizeof(*cpu_to_core) * MAX_NR_CPU);
     cpu_to_socket =3D xc_hypercall_buffer_alloc(xc_handle, cpu_to_socket, =
sizeof(*cpu_to_socket) * MAX_NR_CPU);
@@ -990,7 +977,9 @@ void cpu_topology_func(int argc, char *a
=20
     if ( xc_topologyinfo(xc_handle, &info) )
     {
-        printf("Can not get Xen CPU topology: %d\n", errno);
+        rc =3D errno;
+        fprintf(stderr, "Cannot get Xen CPU topology (%d - %s)\n",
+                errno, strerror(errno));
         goto out;
     }
=20
@@ -1005,116 +994,95 @@ void cpu_topology_func(int argc, char *a
         printf("CPU%d\t %d\t %d\t %d\n",
                i, cpu_to_core[i], cpu_to_socket[i], cpu_to_node[i]);
     }
+    rc =3D 0;
 out:
     xc_hypercall_buffer_free(xc_handle, cpu_to_core);
     xc_hypercall_buffer_free(xc_handle, cpu_to_socket);
     xc_hypercall_buffer_free(xc_handle, cpu_to_node);
+    if ( rc )
+        exit(rc);
 }
=20
 void set_sched_smt_func(int argc, char *argv[])
 {
-    int value, rc;
+    int value;
=20
-    if (argc !=3D 1){
-        show_help();
-        exit(-1);
+    if ( argc !=3D 1 ) {
+        fprintf(stderr, "Missing or invalid argument(s)\n");
+        exit(EINVAL);
     }
=20
-    if ( !strncmp(argv[0], "disable", sizeof("disable")) )
-    {
+    if ( !strcasecmp(argv[0], "disable") )
         value =3D 0;
-    }
-    else if ( !strncmp(argv[0], "enable", sizeof("enable")) )
-    {
+    else if ( !strcasecmp(argv[0], "enable") )
         value =3D 1;
-    }
     else
     {
-        show_help();
-        exit(-1);
+        fprintf(stderr, "Invalid argument: %s\n", argv[0]);
+        exit(EINVAL);
     }
=20
-    rc =3D xc_set_sched_opt_smt(xc_handle, value);
-    printf("%s sched_smt_power_savings %s\n", argv[0],
-                    rc? "failed":"succeeded" );
-
-    return;
+    if ( !xc_set_sched_opt_smt(xc_handle, value) )
+        printf("%s sched_smt_power_savings succeeded\n", argv[0]);
+    else
+        fprintf(stderr, "%s sched_smt_power_savings failed (%d - %s)\n",
+                argv[0], errno, strerror(errno));
 }
=20
 void set_vcpu_migration_delay_func(int argc, char *argv[])
 {
     int value;
-    int rc;
-
-    if (argc !=3D 1){
-        show_help();
-        exit(-1);
-    }
-
-    value =3D atoi(argv[0]);
=20
-    if (value < 0)
-    {
-        printf("Please try non-negative vcpu migration delay\n");
-        exit(-1);
+    if ( argc !=3D 1 || (value =3D atoi(argv[0])) < 0 ) {
+        fprintf(stderr, "Missing or invalid argument(s)\n");
+        exit(EINVAL);
     }
=20
-    rc =3D xc_set_vcpu_migration_delay(xc_handle, value);
-    printf("%s to set vcpu migration delay to %d us\n",
-                    rc? "Fail":"Succeed", value );
-
-    return;
+    if ( !xc_set_vcpu_migration_delay(xc_handle, value) )
+        printf("set vcpu migration delay to %d us succeeded\n", value);
+    else
+        fprintf(stderr, "set vcpu migration delay failed (%d - %s)\n",
+                errno, strerror(errno));
 }
=20
 void get_vcpu_migration_delay_func(int argc, char *argv[])
 {
     uint32_t value;
-    int rc;
=20
-    if (argc !=3D 0){
-        show_help();
-        exit(-1);
-    }
+    if ( argc )
+        fprintf(stderr, "Ignoring argument(s)\n");
=20
-    rc =3D xc_get_vcpu_migration_delay(xc_handle, &value);
-    if (!rc)
-    {
-        printf("Schduler vcpu migration delay is %d us\n", value);
-    }
+    if ( !xc_get_vcpu_migration_delay(xc_handle, &value) )
+        printf("Scheduler vcpu migration delay is %d us\n", value);
     else
-    {
-        printf("Failed to get scheduler vcpu migration delay, errno=3D%d\n=
", errno);
-    }
-
-    return;
+        fprintf(stderr,
+                "Failed to get scheduler vcpu migration delay (%d - =
%s)\n",
+                errno, strerror(errno));
 }
=20
 void set_max_cstate_func(int argc, char *argv[])
 {
-    int value, rc;
+    int value;
=20
     if ( argc !=3D 1 || sscanf(argv[0], "%d", &value) !=3D 1 || value < 0 =
)
     {
-        show_help();
-        exit(-1);
+        fprintf(stderr, "Missing or invalid argument(s)\n");
+        exit(EINVAL);
     }
=20
-    rc =3D xc_set_cpuidle_max_cstate(xc_handle, (uint32_t)value);
-    printf("set max_cstate to C%d %s\n", value,
-                    rc? "failed":"succeeded" );
-
-    return;
+    if ( !xc_set_cpuidle_max_cstate(xc_handle, (uint32_t)value) )
+        printf("set max_cstate to C%d succeeded\n", value);
+    else
+        fprintf(stderr, "set max_cstate to C%d failed (%d - %s)\n",
+                value, errno, strerror(errno));
 }
=20
 void enable_turbo_mode(int argc, char *argv[])
 {
     int cpuid =3D -1;
=20
-    if ( argc > 0 && sscanf(argv[0], "%d", &cpuid) !=3D 1 )
-        cpuid =3D -1;
-
-    if ( cpuid >=3D max_cpu_nr )
-        cpuid =3D -1;
+    if ( argc > 0 )
+        parse_cpuid(argv[0], &cpuid);
=20
     if ( cpuid < 0 )
     {
@@ -1122,21 +1090,22 @@ void enable_turbo_mode(int argc, char *a
          * only make effects on dbs governor */
         int i;
         for ( i =3D 0; i < max_cpu_nr; i++ )
-            xc_enable_turbo(xc_handle, i);
+            if ( xc_enable_turbo(xc_handle, i) )
+                fprintf(stderr,
+                        "[CPU%d] failed to enable turbo mode (%d - =
%s)\n",
+                        i, errno, strerror(errno));
     }
-    else
-        xc_enable_turbo(xc_handle, cpuid);
+    else if ( xc_enable_turbo(xc_handle, cpuid) )
+        fprintf(stderr, "failed to enable turbo mode (%d - %s)\n",
+                errno, strerror(errno));
 }
=20
 void disable_turbo_mode(int argc, char *argv[])
 {
     int cpuid =3D -1;
=20
-    if ( argc > 0 && sscanf(argv[0], "%d", &cpuid) !=3D 1 )
-        cpuid =3D -1;
-
-    if ( cpuid >=3D max_cpu_nr )
-        cpuid =3D -1;
+    if ( argc > 0 )
+        parse_cpuid(argv[0], &cpuid);
=20
     if ( cpuid < 0 )
     {
@@ -1144,10 +1113,14 @@ void disable_turbo_mode(int argc, char *
          * only make effects on dbs governor */
         int i;
         for ( i =3D 0; i < max_cpu_nr; i++ )
-            xc_disable_turbo(xc_handle, i);
+            if ( xc_disable_turbo(xc_handle, i) )
+                fprintf(stderr,
+                        "[CPU%d] failed to disable turbo mode (%d - =
%s)\n",
+                        i, errno, strerror(errno));
     }
-    else
-        xc_disable_turbo(xc_handle, cpuid);
+    else if ( xc_disable_turbo(xc_handle, cpuid) )
+        fprintf(stderr, "failed to disable turbo mode (%d - %s)\n",
+                errno, strerror(errno));
 }
=20
 struct {
@@ -1191,15 +1164,17 @@ int main(int argc, char *argv[])
     if ( !xc_handle )
     {
         fprintf(stderr, "failed to get the handler\n");
-        return 0;
+        return EIO;
     }
=20
     ret =3D xc_physinfo(xc_handle, &physinfo);
     if ( ret )
     {
-        fprintf(stderr, "failed to get the processor information\n");
+        ret =3D errno;
+        fprintf(stderr, "failed to get processor information (%d - =
%s)\n",
+                ret, strerror(ret));
         xc_interface_close(xc_handle);
-        return 0;
+        return ret;
     }
     max_cpu_nr =3D physinfo.nr_cpus;
=20
@@ -1214,14 +1189,18 @@ int main(int argc, char *argv[])
         for ( i =3D 0; i < nr_matches; i++ )
             fprintf(stderr, " %s", main_options[matches_main_options[i]].n=
ame);
         fprintf(stderr, "\n");
+        ret =3D EINVAL;
     }
     else if ( nr_matches =3D=3D 1 )
         /* dispatch to the corresponding function handler */
         main_options[matches_main_options[0]].function(argc - 2, argv + =
2);
     else
+    {
         show_help();
+        ret =3D EINVAL;
+    }
=20
     xc_interface_close(xc_handle);
-    return 0;
+    return ret;
 }
=20



--=__Part52635C12.0__=
Content-Type: text/plain; name="xenpm-consistent.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="xenpm-consistent.patch"

xenpm: make argument parsing and error handling more consistent=0A=0ASpecif=
ically, what values are or aren't accepted as CPU identifier, and=0Ahow =
the values get interpreted should be consistent across sub-commands=0A(inte=
nded behavior now: non-negative values are okay, and along with=0Aomitting =
the argument, specifying "all" will also be accepted).=0A=0AFor error =
handling, error messages should get consistently issued to=0Astderr, and =
the tool should now (hopefully) produce an exit code of=0Azero only in the =
(partial) success case (there may still be a small=0Anumber of questionable=
 cases).=0A=0ASigned-off-by: Jan Beulich <jbeulich@suse.com>=0A=0A--- =
a/tools/misc/xenpm.c=0A+++ b/tools/misc/xenpm.c=0A@@ -36,7 +36,7 @@=0A =
#define CPUFREQ_TURBO_ENABLED       1=0A =0A static xc_interface *xc_handle=
;=0A-static int max_cpu_nr;=0A+static unsigned int max_cpu_nr;=0A =0A /* =
help message */=0A void show_help(void)=0A@@ -77,6 +77,33 @@ void =
help_func(int argc, char *argv[])=0A     show_help();=0A }=0A =0A+static =
void parse_cpuid(const char *arg, int *cpuid)=0A+{=0A+    if ( sscanf(arg, =
"%d", cpuid) !=3D 1 || *cpuid < 0 )=0A+    {=0A+        if ( strcasecmp(arg=
, "all") )=0A+        {=0A+            fprintf(stderr, "Invalid CPU =
identifier: '%s'\n", arg);=0A+            exit(EINVAL);=0A+        }=0A+   =
     *cpuid =3D -1;=0A+    }=0A+}=0A+=0A+static void parse_cpuid_and_int(in=
t argc, char *argv[],=0A+                                int *cpuid, int =
*val, const char *what)=0A+{=0A+    if ( argc > 1 )=0A+        parse_cpuid(=
argv[0], cpuid);=0A+=0A+    if ( argc =3D=3D 0 || sscanf(argv[argc > 1], =
"%d", val) !=3D 1 )=0A+    {=0A+        fprintf(stderr, argc ? "Invalid %s =
'%s'\n" : "Missing %s\n",=0A+                what, argv[argc > 1]);=0A+    =
    exit(EINVAL);=0A+    }=0A+}=0A+=0A static void print_cxstat(int cpuid, =
struct xc_cx_stat *cxstat)=0A {=0A     int i;=0A@@ -166,7 +193,8 @@ static =
int show_cxstat_by_cpuid(xc_inter=0A     if ( ret )=0A     {=0A         if =
( ret =3D=3D -ENODEV )=0A-            printf("Either xen cpuidle is =
disabled or no valid information is registered!\n");=0A+            =
fprintf(stderr,=0A+                    "Either Xen cpuidle is disabled or =
no valid information is registered!\n");=0A         return ret;=0A     =
}=0A =0A@@ -181,11 +209,8 @@ void cxstat_func(int argc, char *argv[])=0A =
{=0A     int cpuid =3D -1;=0A =0A-    if ( argc > 0 && sscanf(argv[0], =
"%d", &cpuid) !=3D 1 )=0A-        cpuid =3D -1;=0A-=0A-    if ( cpuid >=3D =
max_cpu_nr )=0A-        cpuid =3D -1;=0A+    if ( argc > 0 )=0A+        =
parse_cpuid(argv[0], &cpuid);=0A =0A     show_max_cstate(xc_handle);=0A =
=0A@@ -294,11 +319,8 @@ void pxstat_func(int argc, char *argv[])=0A {=0A   =
  int cpuid =3D -1;=0A =0A-    if ( argc > 0 && sscanf(argv[0], "%d", =
&cpuid) !=3D 1 )=0A-        cpuid =3D -1;=0A-=0A-    if ( cpuid >=3D =
max_cpu_nr )=0A-        cpuid =3D -1;=0A+    if ( argc > 0 )=0A+        =
parse_cpuid(argv[0], &cpuid);=0A =0A     if ( cpuid < 0 )=0A     {=0A@@ =
-338,10 +360,10 @@ static void signal_int_handler(int signo=0A 	goto =
out;=0A     }=0A =0A-    if ( gettimeofday(&tv, NULL) =3D=3D -1 )=0A+    =
if ( gettimeofday(&tv, NULL) )=0A     {=0A         fprintf(stderr, "failed =
to get timeofday\n");=0A-        goto out ;=0A+        goto out;=0A     =
}=0A     usec_end =3D tv.tv_sec * 1000000UL + tv.tv_usec;=0A =0A@@ -541,7 =
+563,7 @@ void start_gather_func(int argc, char *a=0A             =
printf("Timeout set to %d seconds\n", timeout);=0A     }=0A =0A-    if ( =
gettimeofday(&tv, NULL) =3D=3D -1 )=0A+    if ( gettimeofday(&tv, NULL) =
)=0A     {=0A         fprintf(stderr, "failed to get timeofday\n");=0A     =
    return ;=0A@@ -766,11 +788,8 @@ void cpufreq_para_func(int argc, char =
*a=0A {=0A     int cpuid =3D -1;=0A =0A-    if ( argc > 0 && sscanf(argv[0]=
, "%d", &cpuid) !=3D 1 )=0A-        cpuid =3D -1;=0A-=0A-    if ( cpuid =
>=3D max_cpu_nr )=0A-        cpuid =3D -1;=0A+    if ( argc > 0 )=0A+      =
  parse_cpuid(argv[0], &cpuid);=0A =0A     if ( cpuid < 0 )=0A     {=0A@@ =
-788,26 +807,22 @@ void scaling_max_freq_func(int argc, cha=0A {=0A     =
int cpuid =3D -1, freq =3D -1;=0A =0A-    if ( (argc >=3D 2 && (sscanf(argv=
[1], "%d", &freq) !=3D 1 ||=0A-                        sscanf(argv[0], =
"%d", &cpuid) !=3D 1)) ||=0A-         (argc =3D=3D 1 && sscanf(argv[0], =
"%d", &freq) !=3D 1 ) ||=0A-         argc =3D=3D 0 )=0A-    {=0A-        =
fprintf(stderr, "failed to set scaling max freq\n");=0A-        return =
;=0A-    }=0A+    parse_cpuid_and_int(argc, argv, &cpuid, &freq, "frequency=
");=0A =0A     if ( cpuid < 0 )=0A     {=0A         int i;=0A         for =
( i =3D 0; i < max_cpu_nr; i++ )=0A             if ( xc_set_cpufreq_para(xc=
_handle, i, SCALING_MAX_FREQ, freq) )=0A-                fprintf(stderr, =
"[CPU%d] failed to set scaling max freq\n", i);=0A+                =
fprintf(stderr,=0A+                        "[CPU%d] failed to set scaling =
max freq (%d - %s)\n",=0A+                        i, errno, strerror(errno)=
);=0A     }=0A     else=0A     {=0A         if ( xc_set_cpufreq_para(xc_han=
dle, cpuid, SCALING_MAX_FREQ, freq) )=0A-            fprintf(stderr, =
"failed to set scaling max freq\n");=0A+            fprintf(stderr, =
"failed to set scaling max freq (%d - %s)\n",=0A+                    =
errno, strerror(errno));=0A     }=0A }=0A =0A@@ -815,26 +830,22 @@ void =
scaling_min_freq_func(int argc, cha=0A {=0A     int cpuid =3D -1, freq =3D =
-1;=0A =0A-    if ( (argc >=3D 2 && (sscanf(argv[1], "%d", &freq) !=3D 1 =
||=0A-                        sscanf(argv[0], "%d", &cpuid) !=3D 1) ) =
||=0A-         (argc =3D=3D 1 && sscanf(argv[0], "%d", &freq) !=3D 1 ) =
||=0A-         argc =3D=3D 0 )=0A-    {=0A-        fprintf(stderr, "failed =
to set scaling min freq\n");=0A-        return ;=0A-    }=0A+    parse_cpui=
d_and_int(argc, argv, &cpuid, &freq, "frequency");=0A =0A     if ( cpuid < =
0 )=0A     {=0A         int i;=0A         for ( i =3D 0; i < max_cpu_nr; =
i++ )=0A             if ( xc_set_cpufreq_para(xc_handle, i, SCALING_MIN_FRE=
Q, freq) )=0A-                fprintf(stderr, "[CPU%d] failed to set =
scaling min freq\n", i);=0A+                fprintf(stderr,=0A+            =
            "[CPU%d] failed to set scaling min freq (%d - %s)\n",=0A+      =
                  i, errno, strerror(errno));=0A     }=0A     else=0A     =
{=0A         if ( xc_set_cpufreq_para(xc_handle, cpuid, SCALING_MIN_FREQ, =
freq) )=0A-            fprintf(stderr, "failed to set scaling min =
freq\n");=0A+            fprintf(stderr, "failed to set scaling min freq =
(%d - %s)\n",=0A+                    errno, strerror(errno));=0A     }=0A =
}=0A =0A@@ -842,26 +853,22 @@ void scaling_speed_func(int argc, char *=0A =
{=0A     int cpuid =3D -1, speed =3D -1;=0A =0A-    if ( (argc >=3D 2 && =
(sscanf(argv[1], "%d", &speed) !=3D 1 ||=0A-                        =
sscanf(argv[0], "%d", &cpuid) !=3D 1) ) ||=0A-         (argc =3D=3D 1 && =
sscanf(argv[0], "%d", &speed) !=3D 1 ) ||=0A-         argc =3D=3D 0 )=0A-  =
  {=0A-        fprintf(stderr, "failed to set scaling speed\n");=0A-       =
 return ;=0A-    }=0A+    parse_cpuid_and_int(argc, argv, &cpuid, &speed, =
"speed");=0A =0A     if ( cpuid < 0 )=0A     {=0A         int i;=0A        =
 for ( i =3D 0; i < max_cpu_nr; i++ )=0A             if ( xc_set_cpufreq_pa=
ra(xc_handle, i, SCALING_SETSPEED, speed) )=0A-                fprintf(stde=
rr, "[CPU%d] failed to set scaling speed\n", i);=0A+                =
fprintf(stderr,=0A+                        "[CPU%d] failed to set scaling =
speed (%d - %s)\n",=0A+                        i, errno, strerror(errno));=
=0A     }=0A     else=0A     {=0A         if ( xc_set_cpufreq_para(xc_handl=
e, cpuid, SCALING_SETSPEED, speed) )=0A-            fprintf(stderr, =
"failed to set scaling speed\n");=0A+            fprintf(stderr, "failed =
to set scaling speed (%d - %s)\n",=0A+                    errno, strerror(e=
rrno));=0A     }=0A }=0A =0A@@ -869,14 +876,7 @@ void scaling_sampling_rate=
_func(int argc=0A {=0A     int cpuid =3D -1, rate =3D -1;=0A =0A-    if ( =
(argc >=3D 2 && (sscanf(argv[1], "%d", &rate) !=3D 1 ||=0A-                =
        sscanf(argv[0], "%d", &cpuid) !=3D 1) ) ||=0A-         (argc =
=3D=3D 1 && sscanf(argv[0], "%d", &rate) !=3D 1 ) ||=0A-         argc =
=3D=3D 0 )=0A-    {=0A-        fprintf(stderr, "failed to set scaling =
sampling rate\n");=0A-        return ;=0A-    }=0A+    parse_cpuid_and_int(=
argc, argv, &cpuid, &rate, "rate");=0A =0A     if ( cpuid < 0 )=0A     =
{=0A@@ -884,12 +884,14 @@ void scaling_sampling_rate_func(int argc=0A      =
   for ( i =3D 0; i < max_cpu_nr; i++ )=0A             if ( xc_set_cpufreq_=
para(xc_handle, i, SAMPLING_RATE, rate) )=0A                 fprintf(stderr=
,=0A-                        "[CPU%d] failed to set scaling sampling =
rate\n", i);=0A+                        "[CPU%d] failed to set scaling =
sampling rate (%d - %s)\n",=0A+                        i, errno, strerror(e=
rrno));=0A     }=0A     else=0A     {=0A         if ( xc_set_cpufreq_para(x=
c_handle, cpuid, SAMPLING_RATE, rate) )=0A-            fprintf(stderr, =
"failed to set scaling sampling rate\n");=0A+            fprintf(stderr, =
"failed to set scaling sampling rate (%d - %s)\n",=0A+                    =
errno, strerror(errno));=0A     }=0A }=0A =0A@@ -897,14 +899,7 @@ void =
scaling_up_threshold_func(int argc,=0A {=0A     int cpuid =3D -1, =
threshold =3D -1;=0A =0A-    if ( (argc >=3D 2 && (sscanf(argv[1], "%d", =
&threshold) !=3D 1 ||=0A-                        sscanf(argv[0], "%d", =
&cpuid) !=3D 1) ) ||=0A-         (argc =3D=3D 1 && sscanf(argv[0], "%d", =
&threshold) !=3D 1 ) ||=0A-         argc =3D=3D 0 )=0A-    {=0A-        =
fprintf(stderr, "failed to set up scaling threshold\n");=0A-        return =
;=0A-    }=0A+    parse_cpuid_and_int(argc, argv, &cpuid, &threshold, =
"threshold");=0A =0A     if ( cpuid < 0 )=0A     {=0A@@ -912,57 +907,49 @@ =
void scaling_up_threshold_func(int argc,=0A         for ( i =3D 0; i < =
max_cpu_nr; i++ )=0A             if ( xc_set_cpufreq_para(xc_handle, i, =
UP_THRESHOLD, threshold) )=0A                 fprintf(stderr,=0A-          =
              "[CPU%d] failed to set up scaling threshold\n", i);=0A+      =
                  "[CPU%d] failed to set up scaling threshold (%d - =
%s)\n",=0A+                        i, errno, strerror(errno));=0A     }=0A =
    else=0A     {=0A         if ( xc_set_cpufreq_para(xc_handle, cpuid, =
UP_THRESHOLD, threshold) )=0A-            fprintf(stderr, "failed to set =
up scaling threshold\n");=0A+            fprintf(stderr, "failed to set up =
scaling threshold (%d - %s)\n",=0A+                    errno, strerror(errn=
o));=0A     }=0A }=0A =0A void scaling_governor_func(int argc, char =
*argv[])=0A {=0A     int cpuid =3D -1;=0A-    char *name =3D NULL;=0A+    =
char *name;=0A =0A     if ( argc >=3D 2 )=0A     {=0A-        name =3D =
strdup(argv[1]);=0A-        if ( name =3D=3D NULL )=0A-            goto =
out;=0A-        if ( sscanf(argv[0], "%d", &cpuid) !=3D 1 )=0A-        =
{=0A-            free(name);=0A-            goto out;=0A-        }=0A+     =
   parse_cpuid(argv[0], &cpuid);=0A+        name =3D argv[1];=0A     }=0A  =
   else if ( argc > 0 )=0A+        name =3D argv[0];=0A+    else=0A     =
{=0A-        name =3D strdup(argv[0]);=0A-        if ( name =3D=3D NULL =
)=0A-            goto out;=0A+        fprintf(stderr, "Missing argument(s)\=
n");=0A+        exit(EINVAL);=0A     }=0A-    else=0A-        goto out;=0A =
=0A     if ( cpuid < 0 )=0A     {=0A         int i;=0A         for ( i =3D =
0; i < max_cpu_nr; i++ )=0A             if ( xc_set_cpufreq_gov(xc_handle, =
i, name) )=0A-                fprintf(stderr, "[CPU%d] failed to set =
governor name\n", i);=0A+                fprintf(stderr, "[CPU%d] failed =
to set governor name (%d - %s)\n",=0A+                        i, errno, =
strerror(errno));=0A     }=0A     else=0A     {=0A         if ( xc_set_cpuf=
req_gov(xc_handle, cpuid, name) )=0A-            fprintf(stderr, "failed =
to set governor name\n");=0A+            fprintf(stderr, "failed to set =
governor name (%d - %s)\n",=0A+                    errno, strerror(errno));=
=0A     }=0A-=0A-    free(name);=0A-    return ;=0A-out:=0A-    fprintf(std=
err, "failed to set governor name\n");=0A }=0A =0A void cpu_topology_func(i=
nt argc, char *argv[])=0A@@ -971,7 +958,7 @@ void cpu_topology_func(int =
argc, char *a=0A     DECLARE_HYPERCALL_BUFFER(uint32_t, cpu_to_socket);=0A =
    DECLARE_HYPERCALL_BUFFER(uint32_t, cpu_to_node);=0A     xc_topologyinfo=
_t info =3D { 0 };=0A-    int i;=0A+    int i, rc =3D ENOMEM;=0A =0A     =
cpu_to_core =3D xc_hypercall_buffer_alloc(xc_handle, cpu_to_core, =
sizeof(*cpu_to_core) * MAX_NR_CPU);=0A     cpu_to_socket =3D xc_hypercall_b=
uffer_alloc(xc_handle, cpu_to_socket, sizeof(*cpu_to_socket) * MAX_NR_CPU);=
=0A@@ -990,7 +977,9 @@ void cpu_topology_func(int argc, char *a=0A =0A     =
if ( xc_topologyinfo(xc_handle, &info) )=0A     {=0A-        printf("Can =
not get Xen CPU topology: %d\n", errno);=0A+        rc =3D errno;=0A+      =
  fprintf(stderr, "Cannot get Xen CPU topology (%d - %s)\n",=0A+           =
     errno, strerror(errno));=0A         goto out;=0A     }=0A =0A@@ =
-1005,116 +994,95 @@ void cpu_topology_func(int argc, char *a=0A         =
printf("CPU%d\t %d\t %d\t %d\n",=0A                i, cpu_to_core[i], =
cpu_to_socket[i], cpu_to_node[i]);=0A     }=0A+    rc =3D 0;=0A out:=0A    =
 xc_hypercall_buffer_free(xc_handle, cpu_to_core);=0A     xc_hypercall_buff=
er_free(xc_handle, cpu_to_socket);=0A     xc_hypercall_buffer_free(xc_handl=
e, cpu_to_node);=0A+    if ( rc )=0A+        exit(rc);=0A }=0A =0A void =
set_sched_smt_func(int argc, char *argv[])=0A {=0A-    int value, rc;=0A+  =
  int value;=0A =0A-    if (argc !=3D 1){=0A-        show_help();=0A-      =
  exit(-1);=0A+    if ( argc !=3D 1 ) {=0A+        fprintf(stderr, =
"Missing or invalid argument(s)\n");=0A+        exit(EINVAL);=0A     }=0A =
=0A-    if ( !strncmp(argv[0], "disable", sizeof("disable")) )=0A-    =
{=0A+    if ( !strcasecmp(argv[0], "disable") )=0A         value =3D =
0;=0A-    }=0A-    else if ( !strncmp(argv[0], "enable", sizeof("enable")) =
)=0A-    {=0A+    else if ( !strcasecmp(argv[0], "enable") )=0A         =
value =3D 1;=0A-    }=0A     else=0A     {=0A-        show_help();=0A-     =
   exit(-1);=0A+        fprintf(stderr, "Invalid argument: %s\n", =
argv[0]);=0A+        exit(EINVAL);=0A     }=0A =0A-    rc =3D xc_set_sched_=
opt_smt(xc_handle, value);=0A-    printf("%s sched_smt_power_savings =
%s\n", argv[0],=0A-                    rc? "failed":"succeeded" );=0A-=0A- =
   return;=0A+    if ( !xc_set_sched_opt_smt(xc_handle, value) )=0A+       =
 printf("%s sched_smt_power_savings succeeded\n", argv[0]);=0A+    =
else=0A+        fprintf(stderr, "%s sched_smt_power_savings failed (%d - =
%s)\n",=0A+                argv[0], errno, strerror(errno));=0A }=0A =0A =
void set_vcpu_migration_delay_func(int argc, char *argv[])=0A {=0A     int =
value;=0A-    int rc;=0A-=0A-    if (argc !=3D 1){=0A-        show_help();=
=0A-        exit(-1);=0A-    }=0A-=0A-    value =3D atoi(argv[0]);=0A =0A- =
   if (value < 0)=0A-    {=0A-        printf("Please try non-negative vcpu =
migration delay\n");=0A-        exit(-1);=0A+    if ( argc !=3D 1 || =
(value =3D atoi(argv[0])) < 0 ) {=0A+        fprintf(stderr, "Missing or =
invalid argument(s)\n");=0A+        exit(EINVAL);=0A     }=0A =0A-    rc =
=3D xc_set_vcpu_migration_delay(xc_handle, value);=0A-    printf("%s to =
set vcpu migration delay to %d us\n",=0A-                    rc? "Fail":"Su=
cceed", value );=0A-=0A-    return;=0A+    if ( !xc_set_vcpu_migration_dela=
y(xc_handle, value) )=0A+        printf("set vcpu migration delay to %d us =
succeeded\n", value);=0A+    else=0A+        fprintf(stderr, "set vcpu =
migration delay failed (%d - %s)\n",=0A+                errno, strerror(err=
no));=0A }=0A =0A void get_vcpu_migration_delay_func(int argc, char =
*argv[])=0A {=0A     uint32_t value;=0A-    int rc;=0A =0A-    if (argc =
!=3D 0){=0A-        show_help();=0A-        exit(-1);=0A-    }=0A+    if ( =
argc )=0A+        fprintf(stderr, "Ignoring argument(s)\n");=0A =0A-    rc =
=3D xc_get_vcpu_migration_delay(xc_handle, &value);=0A-    if (!rc)=0A-    =
{=0A-        printf("Schduler vcpu migration delay is %d us\n", value);=0A-=
    }=0A+    if ( !xc_get_vcpu_migration_delay(xc_handle, &value) )=0A+    =
    printf("Scheduler vcpu migration delay is %d us\n", value);=0A     =
else=0A-    {=0A-        printf("Failed to get scheduler vcpu migration =
delay, errno=3D%d\n", errno);=0A-    }=0A-=0A-    return;=0A+        =
fprintf(stderr,=0A+                "Failed to get scheduler vcpu migration =
delay (%d - %s)\n",=0A+                errno, strerror(errno));=0A }=0A =
=0A void set_max_cstate_func(int argc, char *argv[])=0A {=0A-    int =
value, rc;=0A+    int value;=0A =0A     if ( argc !=3D 1 || sscanf(argv[0],=
 "%d", &value) !=3D 1 || value < 0 )=0A     {=0A-        show_help();=0A-  =
      exit(-1);=0A+        fprintf(stderr, "Missing or invalid argument(s)\=
n");=0A+        exit(EINVAL);=0A     }=0A =0A-    rc =3D xc_set_cpuidle_max=
_cstate(xc_handle, (uint32_t)value);=0A-    printf("set max_cstate to C%d =
%s\n", value,=0A-                    rc? "failed":"succeeded" );=0A-=0A-   =
 return;=0A+    if ( !xc_set_cpuidle_max_cstate(xc_handle, (uint32_t)value)=
 )=0A+        printf("set max_cstate to C%d succeeded\n", value);=0A+    =
else=0A+        fprintf(stderr, "set max_cstate to C%d failed (%d - =
%s)\n",=0A+                value, errno, strerror(errno));=0A }=0A =0A =
void enable_turbo_mode(int argc, char *argv[])=0A {=0A     int cpuid =3D =
-1;=0A =0A-    if ( argc > 0 && sscanf(argv[0], "%d", &cpuid) !=3D 1 )=0A- =
       cpuid =3D -1;=0A-=0A-    if ( cpuid >=3D max_cpu_nr )=0A-        =
cpuid =3D -1;=0A+    if ( argc > 0 )=0A+        parse_cpuid(argv[0], =
&cpuid);=0A =0A     if ( cpuid < 0 )=0A     {=0A@@ -1122,21 +1090,22 @@ =
void enable_turbo_mode(int argc, char *a=0A          * only make effects =
on dbs governor */=0A         int i;=0A         for ( i =3D 0; i < =
max_cpu_nr; i++ )=0A-            xc_enable_turbo(xc_handle, i);=0A+        =
    if ( xc_enable_turbo(xc_handle, i) )=0A+                fprintf(stderr,=
=0A+                        "[CPU%d] failed to enable turbo mode (%d - =
%s)\n",=0A+                        i, errno, strerror(errno));=0A     =
}=0A-    else=0A-        xc_enable_turbo(xc_handle, cpuid);=0A+    else if =
( xc_enable_turbo(xc_handle, cpuid) )=0A+        fprintf(stderr, "failed =
to enable turbo mode (%d - %s)\n",=0A+                errno, strerror(errno=
));=0A }=0A =0A void disable_turbo_mode(int argc, char *argv[])=0A {=0A    =
 int cpuid =3D -1;=0A =0A-    if ( argc > 0 && sscanf(argv[0], "%d", =
&cpuid) !=3D 1 )=0A-        cpuid =3D -1;=0A-=0A-    if ( cpuid >=3D =
max_cpu_nr )=0A-        cpuid =3D -1;=0A+    if ( argc > 0 )=0A+        =
parse_cpuid(argv[0], &cpuid);=0A =0A     if ( cpuid < 0 )=0A     {=0A@@ =
-1144,10 +1113,14 @@ void disable_turbo_mode(int argc, char *=0A          =
* only make effects on dbs governor */=0A         int i;=0A         for ( =
i =3D 0; i < max_cpu_nr; i++ )=0A-            xc_disable_turbo(xc_handle, =
i);=0A+            if ( xc_disable_turbo(xc_handle, i) )=0A+               =
 fprintf(stderr,=0A+                        "[CPU%d] failed to disable =
turbo mode (%d - %s)\n",=0A+                        i, errno, strerror(errn=
o));=0A     }=0A-    else=0A-        xc_disable_turbo(xc_handle, cpuid);=0A=
+    else if ( xc_disable_turbo(xc_handle, cpuid) )=0A+        fprintf(stde=
rr, "failed to disable turbo mode (%d - %s)\n",=0A+                errno, =
strerror(errno));=0A }=0A =0A struct {=0A@@ -1191,15 +1164,17 @@ int =
main(int argc, char *argv[])=0A     if ( !xc_handle )=0A     {=0A         =
fprintf(stderr, "failed to get the handler\n");=0A-        return 0;=0A+   =
     return EIO;=0A     }=0A =0A     ret =3D xc_physinfo(xc_handle, =
&physinfo);=0A     if ( ret )=0A     {=0A-        fprintf(stderr, "failed =
to get the processor information\n");=0A+        ret =3D errno;=0A+        =
fprintf(stderr, "failed to get processor information (%d - %s)\n",=0A+     =
           ret, strerror(ret));=0A         xc_interface_close(xc_handle);=
=0A-        return 0;=0A+        return ret;=0A     }=0A     max_cpu_nr =
=3D physinfo.nr_cpus;=0A =0A@@ -1214,14 +1189,18 @@ int main(int argc, =
char *argv[])=0A         for ( i =3D 0; i < nr_matches; i++ )=0A           =
  fprintf(stderr, " %s", main_options[matches_main_options[i]].name);=0A   =
      fprintf(stderr, "\n");=0A+        ret =3D EINVAL;=0A     }=0A     =
else if ( nr_matches =3D=3D 1 )=0A         /* dispatch to the corresponding=
 function handler */=0A         main_options[matches_main_options[0]].funct=
ion(argc - 2, argv + 2);=0A     else=0A+    {=0A         show_help();=0A+  =
      ret =3D EINVAL;=0A+    }=0A =0A     xc_interface_close(xc_handle);=0A=
-    return 0;=0A+    return ret;=0A }=0A =0A
--=__Part52635C12.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

--=__Part52635C12.0__=--


From xen-devel-bounces@lists.xen.org Fri Sep 14 13:02:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 13:02:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TCVXB-0002wq-Es; Fri, 14 Sep 2012 13:02:13 +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 1TCVX9-0002wb-AP
	for xen-devel@lists.xen.org; Fri, 14 Sep 2012 13:02:11 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1347627723!4024618!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3170 invoked from network); 14 Sep 2012 13:02:03 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-14.tower-27.messagelabs.com with SMTP;
	14 Sep 2012 13:02:03 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 14 Sep 2012 14:02:03 +0100
Message-Id: <50534722020000780009B70D@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 14 Sep 2012 14:02: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="=__Part52635C12.0__="
Subject: [Xen-devel] [PATCH] xenpm: make argument parsing and error handling
 more consistent
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
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.

--=__Part52635C12.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Specifically, what values are or aren't accepted as CPU identifier, and
how the values get interpreted should be consistent across sub-commands
(intended behavior now: non-negative values are okay, and along with
omitting the argument, specifying "all" will also be accepted).

For error handling, error messages should get consistently issued to
stderr, and the tool should now (hopefully) produce an exit code of
zero only in the (partial) success case (there may still be a small
number of questionable cases).

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/tools/misc/xenpm.c
+++ b/tools/misc/xenpm.c
@@ -36,7 +36,7 @@
 #define CPUFREQ_TURBO_ENABLED       1
=20
 static xc_interface *xc_handle;
-static int max_cpu_nr;
+static unsigned int max_cpu_nr;
=20
 /* help message */
 void show_help(void)
@@ -77,6 +77,33 @@ void help_func(int argc, char *argv[])
     show_help();
 }
=20
+static void parse_cpuid(const char *arg, int *cpuid)
+{
+    if ( sscanf(arg, "%d", cpuid) !=3D 1 || *cpuid < 0 )
+    {
+        if ( strcasecmp(arg, "all") )
+        {
+            fprintf(stderr, "Invalid CPU identifier: '%s'\n", arg);
+            exit(EINVAL);
+        }
+        *cpuid =3D -1;
+    }
+}
+
+static void parse_cpuid_and_int(int argc, char *argv[],
+                                int *cpuid, int *val, const char *what)
+{
+    if ( argc > 1 )
+        parse_cpuid(argv[0], cpuid);
+
+    if ( argc =3D=3D 0 || sscanf(argv[argc > 1], "%d", val) !=3D 1 )
+    {
+        fprintf(stderr, argc ? "Invalid %s '%s'\n" : "Missing %s\n",
+                what, argv[argc > 1]);
+        exit(EINVAL);
+    }
+}
+
 static void print_cxstat(int cpuid, struct xc_cx_stat *cxstat)
 {
     int i;
@@ -166,7 +193,8 @@ static int show_cxstat_by_cpuid(xc_inter
     if ( ret )
     {
         if ( ret =3D=3D -ENODEV )
-            printf("Either xen cpuidle is disabled or no valid information=
 is registered!\n");
+            fprintf(stderr,
+                    "Either Xen cpuidle is disabled or no valid informatio=
n is registered!\n");
         return ret;
     }
=20
@@ -181,11 +209,8 @@ void cxstat_func(int argc, char *argv[])
 {
     int cpuid =3D -1;
=20
-    if ( argc > 0 && sscanf(argv[0], "%d", &cpuid) !=3D 1 )
-        cpuid =3D -1;
-
-    if ( cpuid >=3D max_cpu_nr )
-        cpuid =3D -1;
+    if ( argc > 0 )
+        parse_cpuid(argv[0], &cpuid);
=20
     show_max_cstate(xc_handle);
=20
@@ -294,11 +319,8 @@ void pxstat_func(int argc, char *argv[])
 {
     int cpuid =3D -1;
=20
-    if ( argc > 0 && sscanf(argv[0], "%d", &cpuid) !=3D 1 )
-        cpuid =3D -1;
-
-    if ( cpuid >=3D max_cpu_nr )
-        cpuid =3D -1;
+    if ( argc > 0 )
+        parse_cpuid(argv[0], &cpuid);
=20
     if ( cpuid < 0 )
     {
@@ -338,10 +360,10 @@ static void signal_int_handler(int signo
 	goto out;
     }
=20
-    if ( gettimeofday(&tv, NULL) =3D=3D -1 )
+    if ( gettimeofday(&tv, NULL) )
     {
         fprintf(stderr, "failed to get timeofday\n");
-        goto out ;
+        goto out;
     }
     usec_end =3D tv.tv_sec * 1000000UL + tv.tv_usec;
=20
@@ -541,7 +563,7 @@ void start_gather_func(int argc, char *a
             printf("Timeout set to %d seconds\n", timeout);
     }
=20
-    if ( gettimeofday(&tv, NULL) =3D=3D -1 )
+    if ( gettimeofday(&tv, NULL) )
     {
         fprintf(stderr, "failed to get timeofday\n");
         return ;
@@ -766,11 +788,8 @@ void cpufreq_para_func(int argc, char *a
 {
     int cpuid =3D -1;
=20
-    if ( argc > 0 && sscanf(argv[0], "%d", &cpuid) !=3D 1 )
-        cpuid =3D -1;
-
-    if ( cpuid >=3D max_cpu_nr )
-        cpuid =3D -1;
+    if ( argc > 0 )
+        parse_cpuid(argv[0], &cpuid);
=20
     if ( cpuid < 0 )
     {
@@ -788,26 +807,22 @@ void scaling_max_freq_func(int argc, cha
 {
     int cpuid =3D -1, freq =3D -1;
=20
-    if ( (argc >=3D 2 && (sscanf(argv[1], "%d", &freq) !=3D 1 ||
-                        sscanf(argv[0], "%d", &cpuid) !=3D 1)) ||
-         (argc =3D=3D 1 && sscanf(argv[0], "%d", &freq) !=3D 1 ) ||
-         argc =3D=3D 0 )
-    {
-        fprintf(stderr, "failed to set scaling max freq\n");
-        return ;
-    }
+    parse_cpuid_and_int(argc, argv, &cpuid, &freq, "frequency");
=20
     if ( cpuid < 0 )
     {
         int i;
         for ( i =3D 0; i < max_cpu_nr; i++ )
             if ( xc_set_cpufreq_para(xc_handle, i, SCALING_MAX_FREQ, =
freq) )
-                fprintf(stderr, "[CPU%d] failed to set scaling max =
freq\n", i);
+                fprintf(stderr,
+                        "[CPU%d] failed to set scaling max freq (%d - =
%s)\n",
+                        i, errno, strerror(errno));
     }
     else
     {
         if ( xc_set_cpufreq_para(xc_handle, cpuid, SCALING_MAX_FREQ, =
freq) )
-            fprintf(stderr, "failed to set scaling max freq\n");
+            fprintf(stderr, "failed to set scaling max freq (%d - %s)\n",
+                    errno, strerror(errno));
     }
 }
=20
@@ -815,26 +830,22 @@ void scaling_min_freq_func(int argc, cha
 {
     int cpuid =3D -1, freq =3D -1;
=20
-    if ( (argc >=3D 2 && (sscanf(argv[1], "%d", &freq) !=3D 1 ||
-                        sscanf(argv[0], "%d", &cpuid) !=3D 1) ) ||
-         (argc =3D=3D 1 && sscanf(argv[0], "%d", &freq) !=3D 1 ) ||
-         argc =3D=3D 0 )
-    {
-        fprintf(stderr, "failed to set scaling min freq\n");
-        return ;
-    }
+    parse_cpuid_and_int(argc, argv, &cpuid, &freq, "frequency");
=20
     if ( cpuid < 0 )
     {
         int i;
         for ( i =3D 0; i < max_cpu_nr; i++ )
             if ( xc_set_cpufreq_para(xc_handle, i, SCALING_MIN_FREQ, =
freq) )
-                fprintf(stderr, "[CPU%d] failed to set scaling min =
freq\n", i);
+                fprintf(stderr,
+                        "[CPU%d] failed to set scaling min freq (%d - =
%s)\n",
+                        i, errno, strerror(errno));
     }
     else
     {
         if ( xc_set_cpufreq_para(xc_handle, cpuid, SCALING_MIN_FREQ, =
freq) )
-            fprintf(stderr, "failed to set scaling min freq\n");
+            fprintf(stderr, "failed to set scaling min freq (%d - %s)\n",
+                    errno, strerror(errno));
     }
 }
=20
@@ -842,26 +853,22 @@ void scaling_speed_func(int argc, char *
 {
     int cpuid =3D -1, speed =3D -1;
=20
-    if ( (argc >=3D 2 && (sscanf(argv[1], "%d", &speed) !=3D 1 ||
-                        sscanf(argv[0], "%d", &cpuid) !=3D 1) ) ||
-         (argc =3D=3D 1 && sscanf(argv[0], "%d", &speed) !=3D 1 ) ||
-         argc =3D=3D 0 )
-    {
-        fprintf(stderr, "failed to set scaling speed\n");
-        return ;
-    }
+    parse_cpuid_and_int(argc, argv, &cpuid, &speed, "speed");
=20
     if ( cpuid < 0 )
     {
         int i;
         for ( i =3D 0; i < max_cpu_nr; i++ )
             if ( xc_set_cpufreq_para(xc_handle, i, SCALING_SETSPEED, =
speed) )
-                fprintf(stderr, "[CPU%d] failed to set scaling speed\n", =
i);
+                fprintf(stderr,
+                        "[CPU%d] failed to set scaling speed (%d - =
%s)\n",
+                        i, errno, strerror(errno));
     }
     else
     {
         if ( xc_set_cpufreq_para(xc_handle, cpuid, SCALING_SETSPEED, =
speed) )
-            fprintf(stderr, "failed to set scaling speed\n");
+            fprintf(stderr, "failed to set scaling speed (%d - %s)\n",
+                    errno, strerror(errno));
     }
 }
=20
@@ -869,14 +876,7 @@ void scaling_sampling_rate_func(int argc
 {
     int cpuid =3D -1, rate =3D -1;
=20
-    if ( (argc >=3D 2 && (sscanf(argv[1], "%d", &rate) !=3D 1 ||
-                        sscanf(argv[0], "%d", &cpuid) !=3D 1) ) ||
-         (argc =3D=3D 1 && sscanf(argv[0], "%d", &rate) !=3D 1 ) ||
-         argc =3D=3D 0 )
-    {
-        fprintf(stderr, "failed to set scaling sampling rate\n");
-        return ;
-    }
+    parse_cpuid_and_int(argc, argv, &cpuid, &rate, "rate");
=20
     if ( cpuid < 0 )
     {
@@ -884,12 +884,14 @@ void scaling_sampling_rate_func(int argc
         for ( i =3D 0; i < max_cpu_nr; i++ )
             if ( xc_set_cpufreq_para(xc_handle, i, SAMPLING_RATE, rate) )
                 fprintf(stderr,
-                        "[CPU%d] failed to set scaling sampling rate\n", =
i);
+                        "[CPU%d] failed to set scaling sampling rate (%d =
- %s)\n",
+                        i, errno, strerror(errno));
     }
     else
     {
         if ( xc_set_cpufreq_para(xc_handle, cpuid, SAMPLING_RATE, rate) )
-            fprintf(stderr, "failed to set scaling sampling rate\n");
+            fprintf(stderr, "failed to set scaling sampling rate (%d - =
%s)\n",
+                    errno, strerror(errno));
     }
 }
=20
@@ -897,14 +899,7 @@ void scaling_up_threshold_func(int argc,
 {
     int cpuid =3D -1, threshold =3D -1;
=20
-    if ( (argc >=3D 2 && (sscanf(argv[1], "%d", &threshold) !=3D 1 ||
-                        sscanf(argv[0], "%d", &cpuid) !=3D 1) ) ||
-         (argc =3D=3D 1 && sscanf(argv[0], "%d", &threshold) !=3D 1 ) ||
-         argc =3D=3D 0 )
-    {
-        fprintf(stderr, "failed to set up scaling threshold\n");
-        return ;
-    }
+    parse_cpuid_and_int(argc, argv, &cpuid, &threshold, "threshold");
=20
     if ( cpuid < 0 )
     {
@@ -912,57 +907,49 @@ void scaling_up_threshold_func(int argc,
         for ( i =3D 0; i < max_cpu_nr; i++ )
             if ( xc_set_cpufreq_para(xc_handle, i, UP_THRESHOLD, =
threshold) )
                 fprintf(stderr,
-                        "[CPU%d] failed to set up scaling threshold\n", =
i);
+                        "[CPU%d] failed to set up scaling threshold (%d - =
%s)\n",
+                        i, errno, strerror(errno));
     }
     else
     {
         if ( xc_set_cpufreq_para(xc_handle, cpuid, UP_THRESHOLD, =
threshold) )
-            fprintf(stderr, "failed to set up scaling threshold\n");
+            fprintf(stderr, "failed to set up scaling threshold (%d - =
%s)\n",
+                    errno, strerror(errno));
     }
 }
=20
 void scaling_governor_func(int argc, char *argv[])
 {
     int cpuid =3D -1;
-    char *name =3D NULL;
+    char *name;
=20
     if ( argc >=3D 2 )
     {
-        name =3D strdup(argv[1]);
-        if ( name =3D=3D NULL )
-            goto out;
-        if ( sscanf(argv[0], "%d", &cpuid) !=3D 1 )
-        {
-            free(name);
-            goto out;
-        }
+        parse_cpuid(argv[0], &cpuid);
+        name =3D argv[1];
     }
     else if ( argc > 0 )
+        name =3D argv[0];
+    else
     {
-        name =3D strdup(argv[0]);
-        if ( name =3D=3D NULL )
-            goto out;
+        fprintf(stderr, "Missing argument(s)\n");
+        exit(EINVAL);
     }
-    else
-        goto out;
=20
     if ( cpuid < 0 )
     {
         int i;
         for ( i =3D 0; i < max_cpu_nr; i++ )
             if ( xc_set_cpufreq_gov(xc_handle, i, name) )
-                fprintf(stderr, "[CPU%d] failed to set governor name\n", =
i);
+                fprintf(stderr, "[CPU%d] failed to set governor name (%d =
- %s)\n",
+                        i, errno, strerror(errno));
     }
     else
     {
         if ( xc_set_cpufreq_gov(xc_handle, cpuid, name) )
-            fprintf(stderr, "failed to set governor name\n");
+            fprintf(stderr, "failed to set governor name (%d - %s)\n",
+                    errno, strerror(errno));
     }
-
-    free(name);
-    return ;
-out:
-    fprintf(stderr, "failed to set governor name\n");
 }
=20
 void cpu_topology_func(int argc, char *argv[])
@@ -971,7 +958,7 @@ void cpu_topology_func(int argc, char *a
     DECLARE_HYPERCALL_BUFFER(uint32_t, cpu_to_socket);
     DECLARE_HYPERCALL_BUFFER(uint32_t, cpu_to_node);
     xc_topologyinfo_t info =3D { 0 };
-    int i;
+    int i, rc =3D ENOMEM;
=20
     cpu_to_core =3D xc_hypercall_buffer_alloc(xc_handle, cpu_to_core, =
sizeof(*cpu_to_core) * MAX_NR_CPU);
     cpu_to_socket =3D xc_hypercall_buffer_alloc(xc_handle, cpu_to_socket, =
sizeof(*cpu_to_socket) * MAX_NR_CPU);
@@ -990,7 +977,9 @@ void cpu_topology_func(int argc, char *a
=20
     if ( xc_topologyinfo(xc_handle, &info) )
     {
-        printf("Can not get Xen CPU topology: %d\n", errno);
+        rc =3D errno;
+        fprintf(stderr, "Cannot get Xen CPU topology (%d - %s)\n",
+                errno, strerror(errno));
         goto out;
     }
=20
@@ -1005,116 +994,95 @@ void cpu_topology_func(int argc, char *a
         printf("CPU%d\t %d\t %d\t %d\n",
                i, cpu_to_core[i], cpu_to_socket[i], cpu_to_node[i]);
     }
+    rc =3D 0;
 out:
     xc_hypercall_buffer_free(xc_handle, cpu_to_core);
     xc_hypercall_buffer_free(xc_handle, cpu_to_socket);
     xc_hypercall_buffer_free(xc_handle, cpu_to_node);
+    if ( rc )
+        exit(rc);
 }
=20
 void set_sched_smt_func(int argc, char *argv[])
 {
-    int value, rc;
+    int value;
=20
-    if (argc !=3D 1){
-        show_help();
-        exit(-1);
+    if ( argc !=3D 1 ) {
+        fprintf(stderr, "Missing or invalid argument(s)\n");
+        exit(EINVAL);
     }
=20
-    if ( !strncmp(argv[0], "disable", sizeof("disable")) )
-    {
+    if ( !strcasecmp(argv[0], "disable") )
         value =3D 0;
-    }
-    else if ( !strncmp(argv[0], "enable", sizeof("enable")) )
-    {
+    else if ( !strcasecmp(argv[0], "enable") )
         value =3D 1;
-    }
     else
     {
-        show_help();
-        exit(-1);
+        fprintf(stderr, "Invalid argument: %s\n", argv[0]);
+        exit(EINVAL);
     }
=20
-    rc =3D xc_set_sched_opt_smt(xc_handle, value);
-    printf("%s sched_smt_power_savings %s\n", argv[0],
-                    rc? "failed":"succeeded" );
-
-    return;
+    if ( !xc_set_sched_opt_smt(xc_handle, value) )
+        printf("%s sched_smt_power_savings succeeded\n", argv[0]);
+    else
+        fprintf(stderr, "%s sched_smt_power_savings failed (%d - %s)\n",
+                argv[0], errno, strerror(errno));
 }
=20
 void set_vcpu_migration_delay_func(int argc, char *argv[])
 {
     int value;
-    int rc;
-
-    if (argc !=3D 1){
-        show_help();
-        exit(-1);
-    }
-
-    value =3D atoi(argv[0]);
=20
-    if (value < 0)
-    {
-        printf("Please try non-negative vcpu migration delay\n");
-        exit(-1);
+    if ( argc !=3D 1 || (value =3D atoi(argv[0])) < 0 ) {
+        fprintf(stderr, "Missing or invalid argument(s)\n");
+        exit(EINVAL);
     }
=20
-    rc =3D xc_set_vcpu_migration_delay(xc_handle, value);
-    printf("%s to set vcpu migration delay to %d us\n",
-                    rc? "Fail":"Succeed", value );
-
-    return;
+    if ( !xc_set_vcpu_migration_delay(xc_handle, value) )
+        printf("set vcpu migration delay to %d us succeeded\n", value);
+    else
+        fprintf(stderr, "set vcpu migration delay failed (%d - %s)\n",
+                errno, strerror(errno));
 }
=20
 void get_vcpu_migration_delay_func(int argc, char *argv[])
 {
     uint32_t value;
-    int rc;
=20
-    if (argc !=3D 0){
-        show_help();
-        exit(-1);
-    }
+    if ( argc )
+        fprintf(stderr, "Ignoring argument(s)\n");
=20
-    rc =3D xc_get_vcpu_migration_delay(xc_handle, &value);
-    if (!rc)
-    {
-        printf("Schduler vcpu migration delay is %d us\n", value);
-    }
+    if ( !xc_get_vcpu_migration_delay(xc_handle, &value) )
+        printf("Scheduler vcpu migration delay is %d us\n", value);
     else
-    {
-        printf("Failed to get scheduler vcpu migration delay, errno=3D%d\n=
", errno);
-    }
-
-    return;
+        fprintf(stderr,
+                "Failed to get scheduler vcpu migration delay (%d - =
%s)\n",
+                errno, strerror(errno));
 }
=20
 void set_max_cstate_func(int argc, char *argv[])
 {
-    int value, rc;
+    int value;
=20
     if ( argc !=3D 1 || sscanf(argv[0], "%d", &value) !=3D 1 || value < 0 =
)
     {
-        show_help();
-        exit(-1);
+        fprintf(stderr, "Missing or invalid argument(s)\n");
+        exit(EINVAL);
     }
=20
-    rc =3D xc_set_cpuidle_max_cstate(xc_handle, (uint32_t)value);
-    printf("set max_cstate to C%d %s\n", value,
-                    rc? "failed":"succeeded" );
-
-    return;
+    if ( !xc_set_cpuidle_max_cstate(xc_handle, (uint32_t)value) )
+        printf("set max_cstate to C%d succeeded\n", value);
+    else
+        fprintf(stderr, "set max_cstate to C%d failed (%d - %s)\n",
+                value, errno, strerror(errno));
 }
=20
 void enable_turbo_mode(int argc, char *argv[])
 {
     int cpuid =3D -1;
=20
-    if ( argc > 0 && sscanf(argv[0], "%d", &cpuid) !=3D 1 )
-        cpuid =3D -1;
-
-    if ( cpuid >=3D max_cpu_nr )
-        cpuid =3D -1;
+    if ( argc > 0 )
+        parse_cpuid(argv[0], &cpuid);
=20
     if ( cpuid < 0 )
     {
@@ -1122,21 +1090,22 @@ void enable_turbo_mode(int argc, char *a
          * only make effects on dbs governor */
         int i;
         for ( i =3D 0; i < max_cpu_nr; i++ )
-            xc_enable_turbo(xc_handle, i);
+            if ( xc_enable_turbo(xc_handle, i) )
+                fprintf(stderr,
+                        "[CPU%d] failed to enable turbo mode (%d - =
%s)\n",
+                        i, errno, strerror(errno));
     }
-    else
-        xc_enable_turbo(xc_handle, cpuid);
+    else if ( xc_enable_turbo(xc_handle, cpuid) )
+        fprintf(stderr, "failed to enable turbo mode (%d - %s)\n",
+                errno, strerror(errno));
 }
=20
 void disable_turbo_mode(int argc, char *argv[])
 {
     int cpuid =3D -1;
=20
-    if ( argc > 0 && sscanf(argv[0], "%d", &cpuid) !=3D 1 )
-        cpuid =3D -1;
-
-    if ( cpuid >=3D max_cpu_nr )
-        cpuid =3D -1;
+    if ( argc > 0 )
+        parse_cpuid(argv[0], &cpuid);
=20
     if ( cpuid < 0 )
     {
@@ -1144,10 +1113,14 @@ void disable_turbo_mode(int argc, char *
          * only make effects on dbs governor */
         int i;
         for ( i =3D 0; i < max_cpu_nr; i++ )
-            xc_disable_turbo(xc_handle, i);
+            if ( xc_disable_turbo(xc_handle, i) )
+                fprintf(stderr,
+                        "[CPU%d] failed to disable turbo mode (%d - =
%s)\n",
+                        i, errno, strerror(errno));
     }
-    else
-        xc_disable_turbo(xc_handle, cpuid);
+    else if ( xc_disable_turbo(xc_handle, cpuid) )
+        fprintf(stderr, "failed to disable turbo mode (%d - %s)\n",
+                errno, strerror(errno));
 }
=20
 struct {
@@ -1191,15 +1164,17 @@ int main(int argc, char *argv[])
     if ( !xc_handle )
     {
         fprintf(stderr, "failed to get the handler\n");
-        return 0;
+        return EIO;
     }
=20
     ret =3D xc_physinfo(xc_handle, &physinfo);
     if ( ret )
     {
-        fprintf(stderr, "failed to get the processor information\n");
+        ret =3D errno;
+        fprintf(stderr, "failed to get processor information (%d - =
%s)\n",
+                ret, strerror(ret));
         xc_interface_close(xc_handle);
-        return 0;
+        return ret;
     }
     max_cpu_nr =3D physinfo.nr_cpus;
=20
@@ -1214,14 +1189,18 @@ int main(int argc, char *argv[])
         for ( i =3D 0; i < nr_matches; i++ )
             fprintf(stderr, " %s", main_options[matches_main_options[i]].n=
ame);
         fprintf(stderr, "\n");
+        ret =3D EINVAL;
     }
     else if ( nr_matches =3D=3D 1 )
         /* dispatch to the corresponding function handler */
         main_options[matches_main_options[0]].function(argc - 2, argv + =
2);
     else
+    {
         show_help();
+        ret =3D EINVAL;
+    }
=20
     xc_interface_close(xc_handle);
-    return 0;
+    return ret;
 }
=20



--=__Part52635C12.0__=
Content-Type: text/plain; name="xenpm-consistent.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="xenpm-consistent.patch"

xenpm: make argument parsing and error handling more consistent=0A=0ASpecif=
ically, what values are or aren't accepted as CPU identifier, and=0Ahow =
the values get interpreted should be consistent across sub-commands=0A(inte=
nded behavior now: non-negative values are okay, and along with=0Aomitting =
the argument, specifying "all" will also be accepted).=0A=0AFor error =
handling, error messages should get consistently issued to=0Astderr, and =
the tool should now (hopefully) produce an exit code of=0Azero only in the =
(partial) success case (there may still be a small=0Anumber of questionable=
 cases).=0A=0ASigned-off-by: Jan Beulich <jbeulich@suse.com>=0A=0A--- =
a/tools/misc/xenpm.c=0A+++ b/tools/misc/xenpm.c=0A@@ -36,7 +36,7 @@=0A =
#define CPUFREQ_TURBO_ENABLED       1=0A =0A static xc_interface *xc_handle=
;=0A-static int max_cpu_nr;=0A+static unsigned int max_cpu_nr;=0A =0A /* =
help message */=0A void show_help(void)=0A@@ -77,6 +77,33 @@ void =
help_func(int argc, char *argv[])=0A     show_help();=0A }=0A =0A+static =
void parse_cpuid(const char *arg, int *cpuid)=0A+{=0A+    if ( sscanf(arg, =
"%d", cpuid) !=3D 1 || *cpuid < 0 )=0A+    {=0A+        if ( strcasecmp(arg=
, "all") )=0A+        {=0A+            fprintf(stderr, "Invalid CPU =
identifier: '%s'\n", arg);=0A+            exit(EINVAL);=0A+        }=0A+   =
     *cpuid =3D -1;=0A+    }=0A+}=0A+=0A+static void parse_cpuid_and_int(in=
t argc, char *argv[],=0A+                                int *cpuid, int =
*val, const char *what)=0A+{=0A+    if ( argc > 1 )=0A+        parse_cpuid(=
argv[0], cpuid);=0A+=0A+    if ( argc =3D=3D 0 || sscanf(argv[argc > 1], =
"%d", val) !=3D 1 )=0A+    {=0A+        fprintf(stderr, argc ? "Invalid %s =
'%s'\n" : "Missing %s\n",=0A+                what, argv[argc > 1]);=0A+    =
    exit(EINVAL);=0A+    }=0A+}=0A+=0A static void print_cxstat(int cpuid, =
struct xc_cx_stat *cxstat)=0A {=0A     int i;=0A@@ -166,7 +193,8 @@ static =
int show_cxstat_by_cpuid(xc_inter=0A     if ( ret )=0A     {=0A         if =
( ret =3D=3D -ENODEV )=0A-            printf("Either xen cpuidle is =
disabled or no valid information is registered!\n");=0A+            =
fprintf(stderr,=0A+                    "Either Xen cpuidle is disabled or =
no valid information is registered!\n");=0A         return ret;=0A     =
}=0A =0A@@ -181,11 +209,8 @@ void cxstat_func(int argc, char *argv[])=0A =
{=0A     int cpuid =3D -1;=0A =0A-    if ( argc > 0 && sscanf(argv[0], =
"%d", &cpuid) !=3D 1 )=0A-        cpuid =3D -1;=0A-=0A-    if ( cpuid >=3D =
max_cpu_nr )=0A-        cpuid =3D -1;=0A+    if ( argc > 0 )=0A+        =
parse_cpuid(argv[0], &cpuid);=0A =0A     show_max_cstate(xc_handle);=0A =
=0A@@ -294,11 +319,8 @@ void pxstat_func(int argc, char *argv[])=0A {=0A   =
  int cpuid =3D -1;=0A =0A-    if ( argc > 0 && sscanf(argv[0], "%d", =
&cpuid) !=3D 1 )=0A-        cpuid =3D -1;=0A-=0A-    if ( cpuid >=3D =
max_cpu_nr )=0A-        cpuid =3D -1;=0A+    if ( argc > 0 )=0A+        =
parse_cpuid(argv[0], &cpuid);=0A =0A     if ( cpuid < 0 )=0A     {=0A@@ =
-338,10 +360,10 @@ static void signal_int_handler(int signo=0A 	goto =
out;=0A     }=0A =0A-    if ( gettimeofday(&tv, NULL) =3D=3D -1 )=0A+    =
if ( gettimeofday(&tv, NULL) )=0A     {=0A         fprintf(stderr, "failed =
to get timeofday\n");=0A-        goto out ;=0A+        goto out;=0A     =
}=0A     usec_end =3D tv.tv_sec * 1000000UL + tv.tv_usec;=0A =0A@@ -541,7 =
+563,7 @@ void start_gather_func(int argc, char *a=0A             =
printf("Timeout set to %d seconds\n", timeout);=0A     }=0A =0A-    if ( =
gettimeofday(&tv, NULL) =3D=3D -1 )=0A+    if ( gettimeofday(&tv, NULL) =
)=0A     {=0A         fprintf(stderr, "failed to get timeofday\n");=0A     =
    return ;=0A@@ -766,11 +788,8 @@ void cpufreq_para_func(int argc, char =
*a=0A {=0A     int cpuid =3D -1;=0A =0A-    if ( argc > 0 && sscanf(argv[0]=
, "%d", &cpuid) !=3D 1 )=0A-        cpuid =3D -1;=0A-=0A-    if ( cpuid =
>=3D max_cpu_nr )=0A-        cpuid =3D -1;=0A+    if ( argc > 0 )=0A+      =
  parse_cpuid(argv[0], &cpuid);=0A =0A     if ( cpuid < 0 )=0A     {=0A@@ =
-788,26 +807,22 @@ void scaling_max_freq_func(int argc, cha=0A {=0A     =
int cpuid =3D -1, freq =3D -1;=0A =0A-    if ( (argc >=3D 2 && (sscanf(argv=
[1], "%d", &freq) !=3D 1 ||=0A-                        sscanf(argv[0], =
"%d", &cpuid) !=3D 1)) ||=0A-         (argc =3D=3D 1 && sscanf(argv[0], =
"%d", &freq) !=3D 1 ) ||=0A-         argc =3D=3D 0 )=0A-    {=0A-        =
fprintf(stderr, "failed to set scaling max freq\n");=0A-        return =
;=0A-    }=0A+    parse_cpuid_and_int(argc, argv, &cpuid, &freq, "frequency=
");=0A =0A     if ( cpuid < 0 )=0A     {=0A         int i;=0A         for =
( i =3D 0; i < max_cpu_nr; i++ )=0A             if ( xc_set_cpufreq_para(xc=
_handle, i, SCALING_MAX_FREQ, freq) )=0A-                fprintf(stderr, =
"[CPU%d] failed to set scaling max freq\n", i);=0A+                =
fprintf(stderr,=0A+                        "[CPU%d] failed to set scaling =
max freq (%d - %s)\n",=0A+                        i, errno, strerror(errno)=
);=0A     }=0A     else=0A     {=0A         if ( xc_set_cpufreq_para(xc_han=
dle, cpuid, SCALING_MAX_FREQ, freq) )=0A-            fprintf(stderr, =
"failed to set scaling max freq\n");=0A+            fprintf(stderr, =
"failed to set scaling max freq (%d - %s)\n",=0A+                    =
errno, strerror(errno));=0A     }=0A }=0A =0A@@ -815,26 +830,22 @@ void =
scaling_min_freq_func(int argc, cha=0A {=0A     int cpuid =3D -1, freq =3D =
-1;=0A =0A-    if ( (argc >=3D 2 && (sscanf(argv[1], "%d", &freq) !=3D 1 =
||=0A-                        sscanf(argv[0], "%d", &cpuid) !=3D 1) ) =
||=0A-         (argc =3D=3D 1 && sscanf(argv[0], "%d", &freq) !=3D 1 ) =
||=0A-         argc =3D=3D 0 )=0A-    {=0A-        fprintf(stderr, "failed =
to set scaling min freq\n");=0A-        return ;=0A-    }=0A+    parse_cpui=
d_and_int(argc, argv, &cpuid, &freq, "frequency");=0A =0A     if ( cpuid < =
0 )=0A     {=0A         int i;=0A         for ( i =3D 0; i < max_cpu_nr; =
i++ )=0A             if ( xc_set_cpufreq_para(xc_handle, i, SCALING_MIN_FRE=
Q, freq) )=0A-                fprintf(stderr, "[CPU%d] failed to set =
scaling min freq\n", i);=0A+                fprintf(stderr,=0A+            =
            "[CPU%d] failed to set scaling min freq (%d - %s)\n",=0A+      =
                  i, errno, strerror(errno));=0A     }=0A     else=0A     =
{=0A         if ( xc_set_cpufreq_para(xc_handle, cpuid, SCALING_MIN_FREQ, =
freq) )=0A-            fprintf(stderr, "failed to set scaling min =
freq\n");=0A+            fprintf(stderr, "failed to set scaling min freq =
(%d - %s)\n",=0A+                    errno, strerror(errno));=0A     }=0A =
}=0A =0A@@ -842,26 +853,22 @@ void scaling_speed_func(int argc, char *=0A =
{=0A     int cpuid =3D -1, speed =3D -1;=0A =0A-    if ( (argc >=3D 2 && =
(sscanf(argv[1], "%d", &speed) !=3D 1 ||=0A-                        =
sscanf(argv[0], "%d", &cpuid) !=3D 1) ) ||=0A-         (argc =3D=3D 1 && =
sscanf(argv[0], "%d", &speed) !=3D 1 ) ||=0A-         argc =3D=3D 0 )=0A-  =
  {=0A-        fprintf(stderr, "failed to set scaling speed\n");=0A-       =
 return ;=0A-    }=0A+    parse_cpuid_and_int(argc, argv, &cpuid, &speed, =
"speed");=0A =0A     if ( cpuid < 0 )=0A     {=0A         int i;=0A        =
 for ( i =3D 0; i < max_cpu_nr; i++ )=0A             if ( xc_set_cpufreq_pa=
ra(xc_handle, i, SCALING_SETSPEED, speed) )=0A-                fprintf(stde=
rr, "[CPU%d] failed to set scaling speed\n", i);=0A+                =
fprintf(stderr,=0A+                        "[CPU%d] failed to set scaling =
speed (%d - %s)\n",=0A+                        i, errno, strerror(errno));=
=0A     }=0A     else=0A     {=0A         if ( xc_set_cpufreq_para(xc_handl=
e, cpuid, SCALING_SETSPEED, speed) )=0A-            fprintf(stderr, =
"failed to set scaling speed\n");=0A+            fprintf(stderr, "failed =
to set scaling speed (%d - %s)\n",=0A+                    errno, strerror(e=
rrno));=0A     }=0A }=0A =0A@@ -869,14 +876,7 @@ void scaling_sampling_rate=
_func(int argc=0A {=0A     int cpuid =3D -1, rate =3D -1;=0A =0A-    if ( =
(argc >=3D 2 && (sscanf(argv[1], "%d", &rate) !=3D 1 ||=0A-                =
        sscanf(argv[0], "%d", &cpuid) !=3D 1) ) ||=0A-         (argc =
=3D=3D 1 && sscanf(argv[0], "%d", &rate) !=3D 1 ) ||=0A-         argc =
=3D=3D 0 )=0A-    {=0A-        fprintf(stderr, "failed to set scaling =
sampling rate\n");=0A-        return ;=0A-    }=0A+    parse_cpuid_and_int(=
argc, argv, &cpuid, &rate, "rate");=0A =0A     if ( cpuid < 0 )=0A     =
{=0A@@ -884,12 +884,14 @@ void scaling_sampling_rate_func(int argc=0A      =
   for ( i =3D 0; i < max_cpu_nr; i++ )=0A             if ( xc_set_cpufreq_=
para(xc_handle, i, SAMPLING_RATE, rate) )=0A                 fprintf(stderr=
,=0A-                        "[CPU%d] failed to set scaling sampling =
rate\n", i);=0A+                        "[CPU%d] failed to set scaling =
sampling rate (%d - %s)\n",=0A+                        i, errno, strerror(e=
rrno));=0A     }=0A     else=0A     {=0A         if ( xc_set_cpufreq_para(x=
c_handle, cpuid, SAMPLING_RATE, rate) )=0A-            fprintf(stderr, =
"failed to set scaling sampling rate\n");=0A+            fprintf(stderr, =
"failed to set scaling sampling rate (%d - %s)\n",=0A+                    =
errno, strerror(errno));=0A     }=0A }=0A =0A@@ -897,14 +899,7 @@ void =
scaling_up_threshold_func(int argc,=0A {=0A     int cpuid =3D -1, =
threshold =3D -1;=0A =0A-    if ( (argc >=3D 2 && (sscanf(argv[1], "%d", =
&threshold) !=3D 1 ||=0A-                        sscanf(argv[0], "%d", =
&cpuid) !=3D 1) ) ||=0A-         (argc =3D=3D 1 && sscanf(argv[0], "%d", =
&threshold) !=3D 1 ) ||=0A-         argc =3D=3D 0 )=0A-    {=0A-        =
fprintf(stderr, "failed to set up scaling threshold\n");=0A-        return =
;=0A-    }=0A+    parse_cpuid_and_int(argc, argv, &cpuid, &threshold, =
"threshold");=0A =0A     if ( cpuid < 0 )=0A     {=0A@@ -912,57 +907,49 @@ =
void scaling_up_threshold_func(int argc,=0A         for ( i =3D 0; i < =
max_cpu_nr; i++ )=0A             if ( xc_set_cpufreq_para(xc_handle, i, =
UP_THRESHOLD, threshold) )=0A                 fprintf(stderr,=0A-          =
              "[CPU%d] failed to set up scaling threshold\n", i);=0A+      =
                  "[CPU%d] failed to set up scaling threshold (%d - =
%s)\n",=0A+                        i, errno, strerror(errno));=0A     }=0A =
    else=0A     {=0A         if ( xc_set_cpufreq_para(xc_handle, cpuid, =
UP_THRESHOLD, threshold) )=0A-            fprintf(stderr, "failed to set =
up scaling threshold\n");=0A+            fprintf(stderr, "failed to set up =
scaling threshold (%d - %s)\n",=0A+                    errno, strerror(errn=
o));=0A     }=0A }=0A =0A void scaling_governor_func(int argc, char =
*argv[])=0A {=0A     int cpuid =3D -1;=0A-    char *name =3D NULL;=0A+    =
char *name;=0A =0A     if ( argc >=3D 2 )=0A     {=0A-        name =3D =
strdup(argv[1]);=0A-        if ( name =3D=3D NULL )=0A-            goto =
out;=0A-        if ( sscanf(argv[0], "%d", &cpuid) !=3D 1 )=0A-        =
{=0A-            free(name);=0A-            goto out;=0A-        }=0A+     =
   parse_cpuid(argv[0], &cpuid);=0A+        name =3D argv[1];=0A     }=0A  =
   else if ( argc > 0 )=0A+        name =3D argv[0];=0A+    else=0A     =
{=0A-        name =3D strdup(argv[0]);=0A-        if ( name =3D=3D NULL =
)=0A-            goto out;=0A+        fprintf(stderr, "Missing argument(s)\=
n");=0A+        exit(EINVAL);=0A     }=0A-    else=0A-        goto out;=0A =
=0A     if ( cpuid < 0 )=0A     {=0A         int i;=0A         for ( i =3D =
0; i < max_cpu_nr; i++ )=0A             if ( xc_set_cpufreq_gov(xc_handle, =
i, name) )=0A-                fprintf(stderr, "[CPU%d] failed to set =
governor name\n", i);=0A+                fprintf(stderr, "[CPU%d] failed =
to set governor name (%d - %s)\n",=0A+                        i, errno, =
strerror(errno));=0A     }=0A     else=0A     {=0A         if ( xc_set_cpuf=
req_gov(xc_handle, cpuid, name) )=0A-            fprintf(stderr, "failed =
to set governor name\n");=0A+            fprintf(stderr, "failed to set =
governor name (%d - %s)\n",=0A+                    errno, strerror(errno));=
=0A     }=0A-=0A-    free(name);=0A-    return ;=0A-out:=0A-    fprintf(std=
err, "failed to set governor name\n");=0A }=0A =0A void cpu_topology_func(i=
nt argc, char *argv[])=0A@@ -971,7 +958,7 @@ void cpu_topology_func(int =
argc, char *a=0A     DECLARE_HYPERCALL_BUFFER(uint32_t, cpu_to_socket);=0A =
    DECLARE_HYPERCALL_BUFFER(uint32_t, cpu_to_node);=0A     xc_topologyinfo=
_t info =3D { 0 };=0A-    int i;=0A+    int i, rc =3D ENOMEM;=0A =0A     =
cpu_to_core =3D xc_hypercall_buffer_alloc(xc_handle, cpu_to_core, =
sizeof(*cpu_to_core) * MAX_NR_CPU);=0A     cpu_to_socket =3D xc_hypercall_b=
uffer_alloc(xc_handle, cpu_to_socket, sizeof(*cpu_to_socket) * MAX_NR_CPU);=
=0A@@ -990,7 +977,9 @@ void cpu_topology_func(int argc, char *a=0A =0A     =
if ( xc_topologyinfo(xc_handle, &info) )=0A     {=0A-        printf("Can =
not get Xen CPU topology: %d\n", errno);=0A+        rc =3D errno;=0A+      =
  fprintf(stderr, "Cannot get Xen CPU topology (%d - %s)\n",=0A+           =
     errno, strerror(errno));=0A         goto out;=0A     }=0A =0A@@ =
-1005,116 +994,95 @@ void cpu_topology_func(int argc, char *a=0A         =
printf("CPU%d\t %d\t %d\t %d\n",=0A                i, cpu_to_core[i], =
cpu_to_socket[i], cpu_to_node[i]);=0A     }=0A+    rc =3D 0;=0A out:=0A    =
 xc_hypercall_buffer_free(xc_handle, cpu_to_core);=0A     xc_hypercall_buff=
er_free(xc_handle, cpu_to_socket);=0A     xc_hypercall_buffer_free(xc_handl=
e, cpu_to_node);=0A+    if ( rc )=0A+        exit(rc);=0A }=0A =0A void =
set_sched_smt_func(int argc, char *argv[])=0A {=0A-    int value, rc;=0A+  =
  int value;=0A =0A-    if (argc !=3D 1){=0A-        show_help();=0A-      =
  exit(-1);=0A+    if ( argc !=3D 1 ) {=0A+        fprintf(stderr, =
"Missing or invalid argument(s)\n");=0A+        exit(EINVAL);=0A     }=0A =
=0A-    if ( !strncmp(argv[0], "disable", sizeof("disable")) )=0A-    =
{=0A+    if ( !strcasecmp(argv[0], "disable") )=0A         value =3D =
0;=0A-    }=0A-    else if ( !strncmp(argv[0], "enable", sizeof("enable")) =
)=0A-    {=0A+    else if ( !strcasecmp(argv[0], "enable") )=0A         =
value =3D 1;=0A-    }=0A     else=0A     {=0A-        show_help();=0A-     =
   exit(-1);=0A+        fprintf(stderr, "Invalid argument: %s\n", =
argv[0]);=0A+        exit(EINVAL);=0A     }=0A =0A-    rc =3D xc_set_sched_=
opt_smt(xc_handle, value);=0A-    printf("%s sched_smt_power_savings =
%s\n", argv[0],=0A-                    rc? "failed":"succeeded" );=0A-=0A- =
   return;=0A+    if ( !xc_set_sched_opt_smt(xc_handle, value) )=0A+       =
 printf("%s sched_smt_power_savings succeeded\n", argv[0]);=0A+    =
else=0A+        fprintf(stderr, "%s sched_smt_power_savings failed (%d - =
%s)\n",=0A+                argv[0], errno, strerror(errno));=0A }=0A =0A =
void set_vcpu_migration_delay_func(int argc, char *argv[])=0A {=0A     int =
value;=0A-    int rc;=0A-=0A-    if (argc !=3D 1){=0A-        show_help();=
=0A-        exit(-1);=0A-    }=0A-=0A-    value =3D atoi(argv[0]);=0A =0A- =
   if (value < 0)=0A-    {=0A-        printf("Please try non-negative vcpu =
migration delay\n");=0A-        exit(-1);=0A+    if ( argc !=3D 1 || =
(value =3D atoi(argv[0])) < 0 ) {=0A+        fprintf(stderr, "Missing or =
invalid argument(s)\n");=0A+        exit(EINVAL);=0A     }=0A =0A-    rc =
=3D xc_set_vcpu_migration_delay(xc_handle, value);=0A-    printf("%s to =
set vcpu migration delay to %d us\n",=0A-                    rc? "Fail":"Su=
cceed", value );=0A-=0A-    return;=0A+    if ( !xc_set_vcpu_migration_dela=
y(xc_handle, value) )=0A+        printf("set vcpu migration delay to %d us =
succeeded\n", value);=0A+    else=0A+        fprintf(stderr, "set vcpu =
migration delay failed (%d - %s)\n",=0A+                errno, strerror(err=
no));=0A }=0A =0A void get_vcpu_migration_delay_func(int argc, char =
*argv[])=0A {=0A     uint32_t value;=0A-    int rc;=0A =0A-    if (argc =
!=3D 0){=0A-        show_help();=0A-        exit(-1);=0A-    }=0A+    if ( =
argc )=0A+        fprintf(stderr, "Ignoring argument(s)\n");=0A =0A-    rc =
=3D xc_get_vcpu_migration_delay(xc_handle, &value);=0A-    if (!rc)=0A-    =
{=0A-        printf("Schduler vcpu migration delay is %d us\n", value);=0A-=
    }=0A+    if ( !xc_get_vcpu_migration_delay(xc_handle, &value) )=0A+    =
    printf("Scheduler vcpu migration delay is %d us\n", value);=0A     =
else=0A-    {=0A-        printf("Failed to get scheduler vcpu migration =
delay, errno=3D%d\n", errno);=0A-    }=0A-=0A-    return;=0A+        =
fprintf(stderr,=0A+                "Failed to get scheduler vcpu migration =
delay (%d - %s)\n",=0A+                errno, strerror(errno));=0A }=0A =
=0A void set_max_cstate_func(int argc, char *argv[])=0A {=0A-    int =
value, rc;=0A+    int value;=0A =0A     if ( argc !=3D 1 || sscanf(argv[0],=
 "%d", &value) !=3D 1 || value < 0 )=0A     {=0A-        show_help();=0A-  =
      exit(-1);=0A+        fprintf(stderr, "Missing or invalid argument(s)\=
n");=0A+        exit(EINVAL);=0A     }=0A =0A-    rc =3D xc_set_cpuidle_max=
_cstate(xc_handle, (uint32_t)value);=0A-    printf("set max_cstate to C%d =
%s\n", value,=0A-                    rc? "failed":"succeeded" );=0A-=0A-   =
 return;=0A+    if ( !xc_set_cpuidle_max_cstate(xc_handle, (uint32_t)value)=
 )=0A+        printf("set max_cstate to C%d succeeded\n", value);=0A+    =
else=0A+        fprintf(stderr, "set max_cstate to C%d failed (%d - =
%s)\n",=0A+                value, errno, strerror(errno));=0A }=0A =0A =
void enable_turbo_mode(int argc, char *argv[])=0A {=0A     int cpuid =3D =
-1;=0A =0A-    if ( argc > 0 && sscanf(argv[0], "%d", &cpuid) !=3D 1 )=0A- =
       cpuid =3D -1;=0A-=0A-    if ( cpuid >=3D max_cpu_nr )=0A-        =
cpuid =3D -1;=0A+    if ( argc > 0 )=0A+        parse_cpuid(argv[0], =
&cpuid);=0A =0A     if ( cpuid < 0 )=0A     {=0A@@ -1122,21 +1090,22 @@ =
void enable_turbo_mode(int argc, char *a=0A          * only make effects =
on dbs governor */=0A         int i;=0A         for ( i =3D 0; i < =
max_cpu_nr; i++ )=0A-            xc_enable_turbo(xc_handle, i);=0A+        =
    if ( xc_enable_turbo(xc_handle, i) )=0A+                fprintf(stderr,=
=0A+                        "[CPU%d] failed to enable turbo mode (%d - =
%s)\n",=0A+                        i, errno, strerror(errno));=0A     =
}=0A-    else=0A-        xc_enable_turbo(xc_handle, cpuid);=0A+    else if =
( xc_enable_turbo(xc_handle, cpuid) )=0A+        fprintf(stderr, "failed =
to enable turbo mode (%d - %s)\n",=0A+                errno, strerror(errno=
));=0A }=0A =0A void disable_turbo_mode(int argc, char *argv[])=0A {=0A    =
 int cpuid =3D -1;=0A =0A-    if ( argc > 0 && sscanf(argv[0], "%d", =
&cpuid) !=3D 1 )=0A-        cpuid =3D -1;=0A-=0A-    if ( cpuid >=3D =
max_cpu_nr )=0A-        cpuid =3D -1;=0A+    if ( argc > 0 )=0A+        =
parse_cpuid(argv[0], &cpuid);=0A =0A     if ( cpuid < 0 )=0A     {=0A@@ =
-1144,10 +1113,14 @@ void disable_turbo_mode(int argc, char *=0A          =
* only make effects on dbs governor */=0A         int i;=0A         for ( =
i =3D 0; i < max_cpu_nr; i++ )=0A-            xc_disable_turbo(xc_handle, =
i);=0A+            if ( xc_disable_turbo(xc_handle, i) )=0A+               =
 fprintf(stderr,=0A+                        "[CPU%d] failed to disable =
turbo mode (%d - %s)\n",=0A+                        i, errno, strerror(errn=
o));=0A     }=0A-    else=0A-        xc_disable_turbo(xc_handle, cpuid);=0A=
+    else if ( xc_disable_turbo(xc_handle, cpuid) )=0A+        fprintf(stde=
rr, "failed to disable turbo mode (%d - %s)\n",=0A+                errno, =
strerror(errno));=0A }=0A =0A struct {=0A@@ -1191,15 +1164,17 @@ int =
main(int argc, char *argv[])=0A     if ( !xc_handle )=0A     {=0A         =
fprintf(stderr, "failed to get the handler\n");=0A-        return 0;=0A+   =
     return EIO;=0A     }=0A =0A     ret =3D xc_physinfo(xc_handle, =
&physinfo);=0A     if ( ret )=0A     {=0A-        fprintf(stderr, "failed =
to get the processor information\n");=0A+        ret =3D errno;=0A+        =
fprintf(stderr, "failed to get processor information (%d - %s)\n",=0A+     =
           ret, strerror(ret));=0A         xc_interface_close(xc_handle);=
=0A-        return 0;=0A+        return ret;=0A     }=0A     max_cpu_nr =
=3D physinfo.nr_cpus;=0A =0A@@ -1214,14 +1189,18 @@ int main(int argc, =
char *argv[])=0A         for ( i =3D 0; i < nr_matches; i++ )=0A           =
  fprintf(stderr, " %s", main_options[matches_main_options[i]].name);=0A   =
      fprintf(stderr, "\n");=0A+        ret =3D EINVAL;=0A     }=0A     =
else if ( nr_matches =3D=3D 1 )=0A         /* dispatch to the corresponding=
 function handler */=0A         main_options[matches_main_options[0]].funct=
ion(argc - 2, argv + 2);=0A     else=0A+    {=0A         show_help();=0A+  =
      ret =3D EINVAL;=0A+    }=0A =0A     xc_interface_close(xc_handle);=0A=
-    return 0;=0A+    return ret;=0A }=0A =0A
--=__Part52635C12.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

--=__Part52635C12.0__=--


From xen-devel-bounces@lists.xen.org Fri Sep 14 13:02:33 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 13:02:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TCVXK-0002y6-2R; Fri, 14 Sep 2012 13:02:22 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <daniel.kiper@oracle.com>) id 1TCVXJ-0002xq-5Q
	for xen-devel@lists.xensource.com; Fri, 14 Sep 2012 13:02:21 +0000
Received: from [85.158.143.35:33924] by server-3.bemta-4.messagelabs.com id
	66/FB-08232-CDA23505; Fri, 14 Sep 2012 13:02:20 +0000
X-Env-Sender: daniel.kiper@oracle.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1347627723!11488903!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzQxNzU0\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23367 invoked from network); 14 Sep 2012 13:02:04 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-11.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 14 Sep 2012 13:02:04 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q8ED1tUU026926
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 14 Sep 2012 13:01: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
	q8ED1rru029466
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 14 Sep 2012 13:01:54 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
	q8ED1r8a021518; Fri, 14 Sep 2012 08:01:53 -0500
MIME-Version: 1.0
Message-ID: <ff6ec2d4-fe0b-4c2e-8547-567e887355d3@default>
Date: Fri, 14 Sep 2012 06:01:53 -0700 (PDT)
From: Daniel Kiper <daniel.kiper@oracle.com>
To: <horms@verge.net.au>
X-Mailer: Zimbra on Oracle Beehive
Content-Disposition: inline
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: olaf@aepfle.de, xen-devel@lists.xensource.com, konrad.wilk@oracle.com,
	andrew.cooper3@citrix.com, kexec@lists.infradead.org,
	ptesarik@suse.cz, jbeulich@suse.com
Subject: Re: [Xen-devel] [PATCH 0/7] kdump: Xen 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

Hi Simon,

> do these relate to the changes that you were discussing
> with Petr Tesarik in July?

No. They are independent of vmcoreinfo patch.

Daniel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 14 13:02:33 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 13:02:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TCVXK-0002y6-2R; Fri, 14 Sep 2012 13:02:22 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <daniel.kiper@oracle.com>) id 1TCVXJ-0002xq-5Q
	for xen-devel@lists.xensource.com; Fri, 14 Sep 2012 13:02:21 +0000
Received: from [85.158.143.35:33924] by server-3.bemta-4.messagelabs.com id
	66/FB-08232-CDA23505; Fri, 14 Sep 2012 13:02:20 +0000
X-Env-Sender: daniel.kiper@oracle.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1347627723!11488903!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzQxNzU0\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23367 invoked from network); 14 Sep 2012 13:02:04 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-11.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 14 Sep 2012 13:02:04 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q8ED1tUU026926
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 14 Sep 2012 13:01: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
	q8ED1rru029466
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 14 Sep 2012 13:01:54 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
	q8ED1r8a021518; Fri, 14 Sep 2012 08:01:53 -0500
MIME-Version: 1.0
Message-ID: <ff6ec2d4-fe0b-4c2e-8547-567e887355d3@default>
Date: Fri, 14 Sep 2012 06:01:53 -0700 (PDT)
From: Daniel Kiper <daniel.kiper@oracle.com>
To: <horms@verge.net.au>
X-Mailer: Zimbra on Oracle Beehive
Content-Disposition: inline
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: olaf@aepfle.de, xen-devel@lists.xensource.com, konrad.wilk@oracle.com,
	andrew.cooper3@citrix.com, kexec@lists.infradead.org,
	ptesarik@suse.cz, jbeulich@suse.com
Subject: Re: [Xen-devel] [PATCH 0/7] kdump: Xen 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

Hi Simon,

> do these relate to the changes that you were discussing
> with Petr Tesarik in July?

No. They are independent of vmcoreinfo patch.

Daniel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 14 13:08:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 13: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 1TCVdT-0003SM-1D; Fri, 14 Sep 2012 13:08:43 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1TCVdR-0003SH-4A
	for xen-devel@lists.xensource.com; Fri, 14 Sep 2012 13:08:41 +0000
Received: from [85.158.143.35:59901] by server-2.bemta-4.messagelabs.com id
	09/18-21239-75C23505; Fri, 14 Sep 2012 13:08:39 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1347628117!15792779!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzQxNzU0\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9665 invoked from network); 14 Sep 2012 13:08:38 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-16.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 14 Sep 2012 13:08: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 q8ED8ASl000729
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 14 Sep 2012 13:08:11 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q8ED8A2v029252
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 14 Sep 2012 13:08:10 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
	q8ED8Axg029440; Fri, 14 Sep 2012 08:08:10 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 14 Sep 2012 06:08:09 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id D2AF74031C; Fri, 14 Sep 2012 08:57:29 -0400 (EDT)
Date: Fri, 14 Sep 2012 08:57:29 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20120914125729.GG25249@phenom.dumpdata.com>
References: <alpine.DEB.2.02.1209141145150.29232@kaball.uk.xensource.com>
	<1347621207-11294-2-git-send-email-stefano.stabellini@eu.citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1347621207-11294-2-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, linaro-dev@lists.linaro.org,
	Ian.Campbell@citrix.com, arnd@arndb.de, catalin.marinas@arm.com,
	tim@xen.org, linux-kernel@vger.kernel.org,
	linux@arm.linux.org.uk, linux-arm-kernel@lists.infradead.org
Subject: Re: [Xen-devel] [PATCH v4 02/24] xen/arm: hypercalls
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Sep 14, 2012 at 12:13:04PM +0100, Stefano Stabellini wrote:
> Use r12 to pass the hypercall number to the hypervisor.
> 
> We need a register to pass the hypercall number because we might not
> know it at compile time and HVC only takes an immediate argument.
> 
> Among the available registers r12 seems to be the best choice because it
> is defined as "intra-procedure call scratch register".
> 
> Use the ISS to pass an hypervisor specific tag.
> 
> 
> Changes in v2:
> - define an HYPERCALL macro for 5 arguments hypercall wrappers, even if
> at the moment is unused;
> - use ldm instead of pop;
> - fix up comments.
> 
> 
> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

.. since this is all in non-x86 and non-Xen generic parts so cannot
provide you with an Ack :-)

> ---
>  arch/arm/include/asm/xen/hypercall.h |   50 ++++++++++++++++
>  arch/arm/xen/Makefile                |    2 +-
>  arch/arm/xen/hypercall.S             |  106 ++++++++++++++++++++++++++++++++++
>  3 files changed, 157 insertions(+), 1 deletions(-)
>  create mode 100644 arch/arm/include/asm/xen/hypercall.h
>  create mode 100644 arch/arm/xen/hypercall.S
> 
> diff --git a/arch/arm/include/asm/xen/hypercall.h b/arch/arm/include/asm/xen/hypercall.h
> new file mode 100644
> index 0000000..4ac0624
> --- /dev/null
> +++ b/arch/arm/include/asm/xen/hypercall.h
> @@ -0,0 +1,50 @@
> +/******************************************************************************
> + * hypercall.h
> + *
> + * Linux-specific hypervisor handling.
> + *
> + * Stefano Stabellini <stefano.stabellini@eu.citrix.com>, Citrix, 2012
> + *
> + * 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.
> + */
> +
> +#ifndef _ASM_ARM_XEN_HYPERCALL_H
> +#define _ASM_ARM_XEN_HYPERCALL_H
> +
> +#include <xen/interface/xen.h>
> +
> +long privcmd_call(unsigned call, unsigned long a1,
> +		unsigned long a2, unsigned long a3,
> +		unsigned long a4, unsigned long a5);
> +int HYPERVISOR_xen_version(int cmd, void *arg);
> +int HYPERVISOR_console_io(int cmd, int count, char *str);
> +int HYPERVISOR_grant_table_op(unsigned int cmd, void *uop, unsigned int count);
> +int HYPERVISOR_sched_op(int cmd, void *arg);
> +int HYPERVISOR_event_channel_op(int cmd, void *arg);
> +unsigned long HYPERVISOR_hvm_op(int op, void *arg);
> +int HYPERVISOR_memory_op(unsigned int cmd, void *arg);
> +int HYPERVISOR_physdev_op(int cmd, void *arg);
> +
> +#endif /* _ASM_ARM_XEN_HYPERCALL_H */
> diff --git a/arch/arm/xen/Makefile b/arch/arm/xen/Makefile
> index 0bad594..b9d6acc 100644
> --- a/arch/arm/xen/Makefile
> +++ b/arch/arm/xen/Makefile
> @@ -1 +1 @@
> -obj-y		:= enlighten.o
> +obj-y		:= enlighten.o hypercall.o
> diff --git a/arch/arm/xen/hypercall.S b/arch/arm/xen/hypercall.S
> new file mode 100644
> index 0000000..074f5ed
> --- /dev/null
> +++ b/arch/arm/xen/hypercall.S
> @@ -0,0 +1,106 @@
> +/******************************************************************************
> + * hypercall.S
> + *
> + * Xen hypercall wrappers
> + *
> + * Stefano Stabellini <stefano.stabellini@eu.citrix.com>, Citrix, 2012
> + *
> + * 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.
> + */
> +
> +/*
> + * The Xen hypercall calling convention is very similar to the ARM
> + * procedure calling convention: the first paramter is passed in r0, the
> + * second in r1, the third in r2 and the fourth in r3. Considering that
> + * Xen hypercalls have 5 arguments at most, the fifth paramter is passed
> + * in r4, differently from the procedure calling convention of using the
> + * stack for that case.
> + *
> + * The hypercall number is passed in r12.
> + *
> + * The return value is in r0.
> + *
> + * The hvc ISS is required to be 0xEA1, that is the Xen specific ARM
> + * hypercall tag.
> + */
> +
> +#include <linux/linkage.h>
> +#include <asm/assembler.h>
> +#include <xen/interface/xen.h>
> +
> +
> +/* HVC 0xEA1 */
> +#ifdef CONFIG_THUMB2_KERNEL
> +#define xen_hvc .word 0xf7e08ea1
> +#else
> +#define xen_hvc .word 0xe140ea71
> +#endif
> +
> +#define HYPERCALL_SIMPLE(hypercall)		\
> +ENTRY(HYPERVISOR_##hypercall)			\
> +	mov r12, #__HYPERVISOR_##hypercall;	\
> +	xen_hvc;							\
> +	mov pc, lr;							\
> +ENDPROC(HYPERVISOR_##hypercall)
> +
> +#define HYPERCALL0 HYPERCALL_SIMPLE
> +#define HYPERCALL1 HYPERCALL_SIMPLE
> +#define HYPERCALL2 HYPERCALL_SIMPLE
> +#define HYPERCALL3 HYPERCALL_SIMPLE
> +#define HYPERCALL4 HYPERCALL_SIMPLE
> +
> +#define HYPERCALL5(hypercall)			\
> +ENTRY(HYPERVISOR_##hypercall)			\
> +	stmdb sp!, {r4}						\
> +	ldr r4, [sp, #4]					\
> +	mov r12, #__HYPERVISOR_##hypercall;	\
> +	xen_hvc								\
> +	ldm sp!, {r4}						\
> +	mov pc, lr							\
> +ENDPROC(HYPERVISOR_##hypercall)
> +
> +                .text
> +
> +HYPERCALL2(xen_version);
> +HYPERCALL3(console_io);
> +HYPERCALL3(grant_table_op);
> +HYPERCALL2(sched_op);
> +HYPERCALL2(event_channel_op);
> +HYPERCALL2(hvm_op);
> +HYPERCALL2(memory_op);
> +HYPERCALL2(physdev_op);
> +
> +ENTRY(privcmd_call)
> +	stmdb sp!, {r4}
> +	mov r12, r0
> +	mov r0, r1
> +	mov r1, r2
> +	mov r2, r3
> +	ldr r3, [sp, #8]
> +	ldr r4, [sp, #4]
> +	xen_hvc
> +	ldm sp!, {r4}
> +	mov pc, lr
> +ENDPROC(privcmd_call);
> -- 
> 1.7.2.5

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 14 13:08:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 13: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 1TCVdT-0003SM-1D; Fri, 14 Sep 2012 13:08:43 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1TCVdR-0003SH-4A
	for xen-devel@lists.xensource.com; Fri, 14 Sep 2012 13:08:41 +0000
Received: from [85.158.143.35:59901] by server-2.bemta-4.messagelabs.com id
	09/18-21239-75C23505; Fri, 14 Sep 2012 13:08:39 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1347628117!15792779!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzQxNzU0\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9665 invoked from network); 14 Sep 2012 13:08:38 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-16.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 14 Sep 2012 13:08: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 q8ED8ASl000729
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 14 Sep 2012 13:08:11 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q8ED8A2v029252
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 14 Sep 2012 13:08:10 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
	q8ED8Axg029440; Fri, 14 Sep 2012 08:08:10 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 14 Sep 2012 06:08:09 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id D2AF74031C; Fri, 14 Sep 2012 08:57:29 -0400 (EDT)
Date: Fri, 14 Sep 2012 08:57:29 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20120914125729.GG25249@phenom.dumpdata.com>
References: <alpine.DEB.2.02.1209141145150.29232@kaball.uk.xensource.com>
	<1347621207-11294-2-git-send-email-stefano.stabellini@eu.citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1347621207-11294-2-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, linaro-dev@lists.linaro.org,
	Ian.Campbell@citrix.com, arnd@arndb.de, catalin.marinas@arm.com,
	tim@xen.org, linux-kernel@vger.kernel.org,
	linux@arm.linux.org.uk, linux-arm-kernel@lists.infradead.org
Subject: Re: [Xen-devel] [PATCH v4 02/24] xen/arm: hypercalls
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Sep 14, 2012 at 12:13:04PM +0100, Stefano Stabellini wrote:
> Use r12 to pass the hypercall number to the hypervisor.
> 
> We need a register to pass the hypercall number because we might not
> know it at compile time and HVC only takes an immediate argument.
> 
> Among the available registers r12 seems to be the best choice because it
> is defined as "intra-procedure call scratch register".
> 
> Use the ISS to pass an hypervisor specific tag.
> 
> 
> Changes in v2:
> - define an HYPERCALL macro for 5 arguments hypercall wrappers, even if
> at the moment is unused;
> - use ldm instead of pop;
> - fix up comments.
> 
> 
> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

.. since this is all in non-x86 and non-Xen generic parts so cannot
provide you with an Ack :-)

> ---
>  arch/arm/include/asm/xen/hypercall.h |   50 ++++++++++++++++
>  arch/arm/xen/Makefile                |    2 +-
>  arch/arm/xen/hypercall.S             |  106 ++++++++++++++++++++++++++++++++++
>  3 files changed, 157 insertions(+), 1 deletions(-)
>  create mode 100644 arch/arm/include/asm/xen/hypercall.h
>  create mode 100644 arch/arm/xen/hypercall.S
> 
> diff --git a/arch/arm/include/asm/xen/hypercall.h b/arch/arm/include/asm/xen/hypercall.h
> new file mode 100644
> index 0000000..4ac0624
> --- /dev/null
> +++ b/arch/arm/include/asm/xen/hypercall.h
> @@ -0,0 +1,50 @@
> +/******************************************************************************
> + * hypercall.h
> + *
> + * Linux-specific hypervisor handling.
> + *
> + * Stefano Stabellini <stefano.stabellini@eu.citrix.com>, Citrix, 2012
> + *
> + * 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.
> + */
> +
> +#ifndef _ASM_ARM_XEN_HYPERCALL_H
> +#define _ASM_ARM_XEN_HYPERCALL_H
> +
> +#include <xen/interface/xen.h>
> +
> +long privcmd_call(unsigned call, unsigned long a1,
> +		unsigned long a2, unsigned long a3,
> +		unsigned long a4, unsigned long a5);
> +int HYPERVISOR_xen_version(int cmd, void *arg);
> +int HYPERVISOR_console_io(int cmd, int count, char *str);
> +int HYPERVISOR_grant_table_op(unsigned int cmd, void *uop, unsigned int count);
> +int HYPERVISOR_sched_op(int cmd, void *arg);
> +int HYPERVISOR_event_channel_op(int cmd, void *arg);
> +unsigned long HYPERVISOR_hvm_op(int op, void *arg);
> +int HYPERVISOR_memory_op(unsigned int cmd, void *arg);
> +int HYPERVISOR_physdev_op(int cmd, void *arg);
> +
> +#endif /* _ASM_ARM_XEN_HYPERCALL_H */
> diff --git a/arch/arm/xen/Makefile b/arch/arm/xen/Makefile
> index 0bad594..b9d6acc 100644
> --- a/arch/arm/xen/Makefile
> +++ b/arch/arm/xen/Makefile
> @@ -1 +1 @@
> -obj-y		:= enlighten.o
> +obj-y		:= enlighten.o hypercall.o
> diff --git a/arch/arm/xen/hypercall.S b/arch/arm/xen/hypercall.S
> new file mode 100644
> index 0000000..074f5ed
> --- /dev/null
> +++ b/arch/arm/xen/hypercall.S
> @@ -0,0 +1,106 @@
> +/******************************************************************************
> + * hypercall.S
> + *
> + * Xen hypercall wrappers
> + *
> + * Stefano Stabellini <stefano.stabellini@eu.citrix.com>, Citrix, 2012
> + *
> + * 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.
> + */
> +
> +/*
> + * The Xen hypercall calling convention is very similar to the ARM
> + * procedure calling convention: the first paramter is passed in r0, the
> + * second in r1, the third in r2 and the fourth in r3. Considering that
> + * Xen hypercalls have 5 arguments at most, the fifth paramter is passed
> + * in r4, differently from the procedure calling convention of using the
> + * stack for that case.
> + *
> + * The hypercall number is passed in r12.
> + *
> + * The return value is in r0.
> + *
> + * The hvc ISS is required to be 0xEA1, that is the Xen specific ARM
> + * hypercall tag.
> + */
> +
> +#include <linux/linkage.h>
> +#include <asm/assembler.h>
> +#include <xen/interface/xen.h>
> +
> +
> +/* HVC 0xEA1 */
> +#ifdef CONFIG_THUMB2_KERNEL
> +#define xen_hvc .word 0xf7e08ea1
> +#else
> +#define xen_hvc .word 0xe140ea71
> +#endif
> +
> +#define HYPERCALL_SIMPLE(hypercall)		\
> +ENTRY(HYPERVISOR_##hypercall)			\
> +	mov r12, #__HYPERVISOR_##hypercall;	\
> +	xen_hvc;							\
> +	mov pc, lr;							\
> +ENDPROC(HYPERVISOR_##hypercall)
> +
> +#define HYPERCALL0 HYPERCALL_SIMPLE
> +#define HYPERCALL1 HYPERCALL_SIMPLE
> +#define HYPERCALL2 HYPERCALL_SIMPLE
> +#define HYPERCALL3 HYPERCALL_SIMPLE
> +#define HYPERCALL4 HYPERCALL_SIMPLE
> +
> +#define HYPERCALL5(hypercall)			\
> +ENTRY(HYPERVISOR_##hypercall)			\
> +	stmdb sp!, {r4}						\
> +	ldr r4, [sp, #4]					\
> +	mov r12, #__HYPERVISOR_##hypercall;	\
> +	xen_hvc								\
> +	ldm sp!, {r4}						\
> +	mov pc, lr							\
> +ENDPROC(HYPERVISOR_##hypercall)
> +
> +                .text
> +
> +HYPERCALL2(xen_version);
> +HYPERCALL3(console_io);
> +HYPERCALL3(grant_table_op);
> +HYPERCALL2(sched_op);
> +HYPERCALL2(event_channel_op);
> +HYPERCALL2(hvm_op);
> +HYPERCALL2(memory_op);
> +HYPERCALL2(physdev_op);
> +
> +ENTRY(privcmd_call)
> +	stmdb sp!, {r4}
> +	mov r12, r0
> +	mov r0, r1
> +	mov r1, r2
> +	mov r2, r3
> +	ldr r3, [sp, #8]
> +	ldr r4, [sp, #4]
> +	xen_hvc
> +	ldm sp!, {r4}
> +	mov pc, lr
> +ENDPROC(privcmd_call);
> -- 
> 1.7.2.5

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 14 13:13:25 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 13:13:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TCVho-0003ff-Bt; Fri, 14 Sep 2012 13:13:12 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1TCVhn-0003fS-11
	for xen-devel@lists.xensource.com; Fri, 14 Sep 2012 13:13:11 +0000
Received: from [85.158.137.99:16786] by server-7.bemta-3.messagelabs.com id
	A0/56-32000-66D23505; Fri, 14 Sep 2012 13:13:10 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-2.tower-217.messagelabs.com!1347628387!17568747!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzQxNzU0\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15413 invoked from network); 14 Sep 2012 13:13:09 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-2.tower-217.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 14 Sep 2012 13:13:09 -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 q8EDCXZi005376
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 14 Sep 2012 13:12:34 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
	q8EDCWbc014093
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 14 Sep 2012 13:12:32 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
	q8EDCVMu028984; Fri, 14 Sep 2012 08:12:31 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 14 Sep 2012 06:12:31 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 655054031C; Fri, 14 Sep 2012 09:01:51 -0400 (EDT)
Date: Fri, 14 Sep 2012 09:01:51 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20120914130151.GH25249@phenom.dumpdata.com>
References: <alpine.DEB.2.02.1209141145150.29232@kaball.uk.xensource.com>
	<1347621207-11294-6-git-send-email-stefano.stabellini@eu.citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1347621207-11294-6-git-send-email-stefano.stabellini@eu.citrix.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: Dave Martin <dave.martin@linaro.org>, xen-devel@lists.xensource.com,
	linaro-dev@lists.linaro.org, Ian.Campbell@citrix.com,
	arnd@arndb.de, catalin.marinas@arm.com,
	devicetree-discuss@lists.ozlabs.org, tim@xen.org,
	linux-kernel@vger.kernel.org, Rob Herring <robherring2@gmail.com>,
	David Vrabel <david.vrabel@citrix.com>, linux@arm.linux.org.uk,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [Xen-devel] [PATCH v4 06/24] docs: Xen ARM DT bindings
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Sep 14, 2012 at 12:13:08PM +0100, Stefano Stabellini wrote:
> Add a doc to describe the Xen ARM device tree bindings
> 
> 
> Changes in v4:
> 
> - "xen,xen" should be last as it is less specific;
> - update reg property using 2 address-cells and 2 size-cells.
> 
> 
> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> CC: devicetree-discuss@lists.ozlabs.org
> CC: David Vrabel <david.vrabel@citrix.com>
> CC: Rob Herring <robherring2@gmail.com>
> CC: Dave Martin <dave.martin@linaro.org>
> ---
>  Documentation/devicetree/bindings/arm/xen.txt |   22 ++++++++++++++++++++++
>  1 files changed, 22 insertions(+), 0 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/arm/xen.txt
> 
> diff --git a/Documentation/devicetree/bindings/arm/xen.txt b/Documentation/devicetree/bindings/arm/xen.txt
> new file mode 100644
> index 0000000..1f8f7d4
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/arm/xen.txt
> @@ -0,0 +1,22 @@
> +* Xen hypervisor device tree bindings
> +
> +Xen ARM virtual platforms shall have the following properties:
> +
> +- compatible:
> +	compatible = "xen,xen-<version>", "xen,xen";
> +  where <version> is the version of the Xen ABI of the platform.
> +
> +- reg: specifies the base physical address and size of a region in
> +  memory where the grant table should be mapped to, using an
> +  HYPERVISOR_memory_op hypercall. 
> +
> +- interrupts: the interrupt used by Xen to inject event notifications.

Its singular here.. but in the example its plurar. What if you use
multiple of the same number ("16 0xf")?

> +
> +
> +Example:
> +
> +hypervisor {
> +	compatible = "xen,xen-4.3", "xen,xen";
> +	reg = <0 0xb0000000 0 0x20000>;

So two grant tables?

Hm, physical address is zero, and the size is 0xbignumber?
Or is the '0' denotating a seperator of arguments, so it is
0xb000.. for physical address and 0x20000 for size?


> +	interrupts = <1 15 0xf08>;
> +};
> -- 
> 1.7.2.5

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 14 13:13:25 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 13:13:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TCVho-0003ff-Bt; Fri, 14 Sep 2012 13:13:12 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1TCVhn-0003fS-11
	for xen-devel@lists.xensource.com; Fri, 14 Sep 2012 13:13:11 +0000
Received: from [85.158.137.99:16786] by server-7.bemta-3.messagelabs.com id
	A0/56-32000-66D23505; Fri, 14 Sep 2012 13:13:10 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-2.tower-217.messagelabs.com!1347628387!17568747!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzQxNzU0\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15413 invoked from network); 14 Sep 2012 13:13:09 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-2.tower-217.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 14 Sep 2012 13:13:09 -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 q8EDCXZi005376
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 14 Sep 2012 13:12:34 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
	q8EDCWbc014093
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 14 Sep 2012 13:12:32 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
	q8EDCVMu028984; Fri, 14 Sep 2012 08:12:31 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 14 Sep 2012 06:12:31 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 655054031C; Fri, 14 Sep 2012 09:01:51 -0400 (EDT)
Date: Fri, 14 Sep 2012 09:01:51 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20120914130151.GH25249@phenom.dumpdata.com>
References: <alpine.DEB.2.02.1209141145150.29232@kaball.uk.xensource.com>
	<1347621207-11294-6-git-send-email-stefano.stabellini@eu.citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1347621207-11294-6-git-send-email-stefano.stabellini@eu.citrix.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: Dave Martin <dave.martin@linaro.org>, xen-devel@lists.xensource.com,
	linaro-dev@lists.linaro.org, Ian.Campbell@citrix.com,
	arnd@arndb.de, catalin.marinas@arm.com,
	devicetree-discuss@lists.ozlabs.org, tim@xen.org,
	linux-kernel@vger.kernel.org, Rob Herring <robherring2@gmail.com>,
	David Vrabel <david.vrabel@citrix.com>, linux@arm.linux.org.uk,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [Xen-devel] [PATCH v4 06/24] docs: Xen ARM DT bindings
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Sep 14, 2012 at 12:13:08PM +0100, Stefano Stabellini wrote:
> Add a doc to describe the Xen ARM device tree bindings
> 
> 
> Changes in v4:
> 
> - "xen,xen" should be last as it is less specific;
> - update reg property using 2 address-cells and 2 size-cells.
> 
> 
> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> CC: devicetree-discuss@lists.ozlabs.org
> CC: David Vrabel <david.vrabel@citrix.com>
> CC: Rob Herring <robherring2@gmail.com>
> CC: Dave Martin <dave.martin@linaro.org>
> ---
>  Documentation/devicetree/bindings/arm/xen.txt |   22 ++++++++++++++++++++++
>  1 files changed, 22 insertions(+), 0 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/arm/xen.txt
> 
> diff --git a/Documentation/devicetree/bindings/arm/xen.txt b/Documentation/devicetree/bindings/arm/xen.txt
> new file mode 100644
> index 0000000..1f8f7d4
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/arm/xen.txt
> @@ -0,0 +1,22 @@
> +* Xen hypervisor device tree bindings
> +
> +Xen ARM virtual platforms shall have the following properties:
> +
> +- compatible:
> +	compatible = "xen,xen-<version>", "xen,xen";
> +  where <version> is the version of the Xen ABI of the platform.
> +
> +- reg: specifies the base physical address and size of a region in
> +  memory where the grant table should be mapped to, using an
> +  HYPERVISOR_memory_op hypercall. 
> +
> +- interrupts: the interrupt used by Xen to inject event notifications.

Its singular here.. but in the example its plurar. What if you use
multiple of the same number ("16 0xf")?

> +
> +
> +Example:
> +
> +hypervisor {
> +	compatible = "xen,xen-4.3", "xen,xen";
> +	reg = <0 0xb0000000 0 0x20000>;

So two grant tables?

Hm, physical address is zero, and the size is 0xbignumber?
Or is the '0' denotating a seperator of arguments, so it is
0xb000.. for physical address and 0x20000 for size?


> +	interrupts = <1 15 0xf08>;
> +};
> -- 
> 1.7.2.5

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 14 13:14:25 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 13: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 1TCVio-0003n5-T1; Fri, 14 Sep 2012 13:14:14 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1TCVin-0003mr-OS
	for xen-devel@lists.xensource.com; Fri, 14 Sep 2012 13:14:13 +0000
Received: from [85.158.143.35:24390] by server-2.bemta-4.messagelabs.com id
	07/00-21239-5AD23505; Fri, 14 Sep 2012 13:14:13 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1347628450!18264880!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzQxNzU0\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1721 invoked from network); 14 Sep 2012 13:14:12 -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; 14 Sep 2012 13:14:12 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q8EDDoQr006709
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 14 Sep 2012 13:13: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
	q8EDDoCd003714
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 14 Sep 2012 13:13:50 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
	q8EDDnu5001786; Fri, 14 Sep 2012 08:13:49 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 14 Sep 2012 06:13:49 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 826DB4031C; Fri, 14 Sep 2012 09:03:08 -0400 (EDT)
Date: Fri, 14 Sep 2012 09:03:08 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20120914130308.GI25249@phenom.dumpdata.com>
References: <alpine.DEB.2.02.1209141145150.29232@kaball.uk.xensource.com>
	<1347621207-11294-10-git-send-email-stefano.stabellini@eu.citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1347621207-11294-10-git-send-email-stefano.stabellini@eu.citrix.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: xen-devel@lists.xensource.com, linaro-dev@lists.linaro.org,
	Ian.Campbell@citrix.com, arnd@arndb.de, catalin.marinas@arm.com,
	tim@xen.org, linux-kernel@vger.kernel.org,
	linux@arm.linux.org.uk, linux-arm-kernel@lists.infradead.org
Subject: Re: [Xen-devel] [PATCH v4 10/24] xen/arm: compile and run xenbus
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Sep 14, 2012 at 12:13:12PM +0100, Stefano Stabellini wrote:
> bind_evtchn_to_irqhandler can legitimately return 0 (irq 0): it is not
> an error.
> 
> If Linux is running as an HVM domain and is running as Dom0, use
> xenstored_local_init to initialize the xenstore page and event channel.

Let me stick it in my tree and see how it works overnight with HVM and PV guests.


> 
> 
> Changes in v4:
> 
> - do not xs_reset_watches on dom0.
> 
> 
> Changes in v2:
> 
> - refactor xenbus_init.
> 
> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> ---
>  drivers/xen/xenbus/xenbus_comms.c |    2 +-
>  drivers/xen/xenbus/xenbus_probe.c |   62 +++++++++++++++++++++++++-----------
>  drivers/xen/xenbus/xenbus_xs.c    |    3 +-
>  3 files changed, 46 insertions(+), 21 deletions(-)
> 
> diff --git a/drivers/xen/xenbus/xenbus_comms.c b/drivers/xen/xenbus/xenbus_comms.c
> index 52fe7ad..c5aa55c 100644
> --- a/drivers/xen/xenbus/xenbus_comms.c
> +++ b/drivers/xen/xenbus/xenbus_comms.c
> @@ -224,7 +224,7 @@ int xb_init_comms(void)
>  		int err;
>  		err = bind_evtchn_to_irqhandler(xen_store_evtchn, wake_waiting,
>  						0, "xenbus", &xb_waitq);
> -		if (err <= 0) {
> +		if (err < 0) {
>  			printk(KERN_ERR "XENBUS request irq failed %i\n", err);
>  			return err;
>  		}
> diff --git a/drivers/xen/xenbus/xenbus_probe.c b/drivers/xen/xenbus/xenbus_probe.c
> index b793723..a67ccc0 100644
> --- a/drivers/xen/xenbus/xenbus_probe.c
> +++ b/drivers/xen/xenbus/xenbus_probe.c
> @@ -719,37 +719,61 @@ static int __init xenstored_local_init(void)
>  	return err;
>  }
>  
> +enum xenstore_init {
> +	UNKNOWN,
> +	PV,
> +	HVM,
> +	LOCAL,
> +};
>  static int __init xenbus_init(void)
>  {
>  	int err = 0;
> +	enum xenstore_init usage = UNKNOWN;
> +	uint64_t v = 0;
>  
>  	if (!xen_domain())
>  		return -ENODEV;
>  
>  	xenbus_ring_ops_init();
>  
> -	if (xen_hvm_domain()) {
> -		uint64_t v = 0;
> -		err = hvm_get_parameter(HVM_PARAM_STORE_EVTCHN, &v);
> -		if (err)
> -			goto out_error;
> -		xen_store_evtchn = (int)v;
> -		err = hvm_get_parameter(HVM_PARAM_STORE_PFN, &v);
> -		if (err)
> -			goto out_error;
> -		xen_store_mfn = (unsigned long)v;
> -		xen_store_interface = ioremap(xen_store_mfn << PAGE_SHIFT, PAGE_SIZE);
> -	} else {
> -		xen_store_evtchn = xen_start_info->store_evtchn;
> -		xen_store_mfn = xen_start_info->store_mfn;
> -		if (xen_store_evtchn)
> -			xenstored_ready = 1;
> -		else {
> +	if (xen_pv_domain())
> +		usage = PV;
> +	if (xen_hvm_domain())
> +		usage = HVM;
> +	if (xen_hvm_domain() && xen_initial_domain())
> +		usage = LOCAL;
> +	if (xen_pv_domain() && !xen_start_info->store_evtchn)
> +		usage = LOCAL;
> +	if (xen_pv_domain() && xen_start_info->store_evtchn)
> +		xenstored_ready = 1;
> +
> +	switch (usage) {
> +		case LOCAL:
>  			err = xenstored_local_init();
>  			if (err)
>  				goto out_error;
> -		}
> -		xen_store_interface = mfn_to_virt(xen_store_mfn);
> +			xen_store_interface = mfn_to_virt(xen_store_mfn);
> +			break;
> +		case PV:
> +			xen_store_evtchn = xen_start_info->store_evtchn;
> +			xen_store_mfn = xen_start_info->store_mfn;
> +			xen_store_interface = mfn_to_virt(xen_store_mfn);
> +			break;
> +		case HVM:
> +			err = hvm_get_parameter(HVM_PARAM_STORE_EVTCHN, &v);
> +			if (err)
> +				goto out_error;
> +			xen_store_evtchn = (int)v;
> +			err = hvm_get_parameter(HVM_PARAM_STORE_PFN, &v);
> +			if (err)
> +				goto out_error;
> +			xen_store_mfn = (unsigned long)v;
> +			xen_store_interface =
> +				ioremap(xen_store_mfn << PAGE_SHIFT, PAGE_SIZE);
> +			break;
> +		default:
> +			pr_warn("Xenstore state unknown\n");
> +			break;
>  	}
>  
>  	/* Initialize the interface to xenstore. */
> diff --git a/drivers/xen/xenbus/xenbus_xs.c b/drivers/xen/xenbus/xenbus_xs.c
> index bce15cf..131dec0 100644
> --- a/drivers/xen/xenbus/xenbus_xs.c
> +++ b/drivers/xen/xenbus/xenbus_xs.c
> @@ -44,6 +44,7 @@
>  #include <linux/rwsem.h>
>  #include <linux/module.h>
>  #include <linux/mutex.h>
> +#include <asm/xen/hypervisor.h>
>  #include <xen/xenbus.h>
>  #include <xen/xen.h>
>  #include "xenbus_comms.h"
> @@ -622,7 +623,7 @@ static void xs_reset_watches(void)
>  {
>  	int err, supported = 0;
>  
> -	if (!xen_hvm_domain())
> +	if (!xen_hvm_domain() || xen_initial_domain())
>  		return;
>  
>  	err = xenbus_scanf(XBT_NIL, "control",
> -- 
> 1.7.2.5

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 14 13:14:25 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 13: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 1TCVio-0003n5-T1; Fri, 14 Sep 2012 13:14:14 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1TCVin-0003mr-OS
	for xen-devel@lists.xensource.com; Fri, 14 Sep 2012 13:14:13 +0000
Received: from [85.158.143.35:24390] by server-2.bemta-4.messagelabs.com id
	07/00-21239-5AD23505; Fri, 14 Sep 2012 13:14:13 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1347628450!18264880!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzQxNzU0\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1721 invoked from network); 14 Sep 2012 13:14:12 -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; 14 Sep 2012 13:14:12 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q8EDDoQr006709
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 14 Sep 2012 13:13: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
	q8EDDoCd003714
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 14 Sep 2012 13:13:50 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
	q8EDDnu5001786; Fri, 14 Sep 2012 08:13:49 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 14 Sep 2012 06:13:49 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 826DB4031C; Fri, 14 Sep 2012 09:03:08 -0400 (EDT)
Date: Fri, 14 Sep 2012 09:03:08 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20120914130308.GI25249@phenom.dumpdata.com>
References: <alpine.DEB.2.02.1209141145150.29232@kaball.uk.xensource.com>
	<1347621207-11294-10-git-send-email-stefano.stabellini@eu.citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1347621207-11294-10-git-send-email-stefano.stabellini@eu.citrix.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: xen-devel@lists.xensource.com, linaro-dev@lists.linaro.org,
	Ian.Campbell@citrix.com, arnd@arndb.de, catalin.marinas@arm.com,
	tim@xen.org, linux-kernel@vger.kernel.org,
	linux@arm.linux.org.uk, linux-arm-kernel@lists.infradead.org
Subject: Re: [Xen-devel] [PATCH v4 10/24] xen/arm: compile and run xenbus
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Sep 14, 2012 at 12:13:12PM +0100, Stefano Stabellini wrote:
> bind_evtchn_to_irqhandler can legitimately return 0 (irq 0): it is not
> an error.
> 
> If Linux is running as an HVM domain and is running as Dom0, use
> xenstored_local_init to initialize the xenstore page and event channel.

Let me stick it in my tree and see how it works overnight with HVM and PV guests.


> 
> 
> Changes in v4:
> 
> - do not xs_reset_watches on dom0.
> 
> 
> Changes in v2:
> 
> - refactor xenbus_init.
> 
> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> ---
>  drivers/xen/xenbus/xenbus_comms.c |    2 +-
>  drivers/xen/xenbus/xenbus_probe.c |   62 +++++++++++++++++++++++++-----------
>  drivers/xen/xenbus/xenbus_xs.c    |    3 +-
>  3 files changed, 46 insertions(+), 21 deletions(-)
> 
> diff --git a/drivers/xen/xenbus/xenbus_comms.c b/drivers/xen/xenbus/xenbus_comms.c
> index 52fe7ad..c5aa55c 100644
> --- a/drivers/xen/xenbus/xenbus_comms.c
> +++ b/drivers/xen/xenbus/xenbus_comms.c
> @@ -224,7 +224,7 @@ int xb_init_comms(void)
>  		int err;
>  		err = bind_evtchn_to_irqhandler(xen_store_evtchn, wake_waiting,
>  						0, "xenbus", &xb_waitq);
> -		if (err <= 0) {
> +		if (err < 0) {
>  			printk(KERN_ERR "XENBUS request irq failed %i\n", err);
>  			return err;
>  		}
> diff --git a/drivers/xen/xenbus/xenbus_probe.c b/drivers/xen/xenbus/xenbus_probe.c
> index b793723..a67ccc0 100644
> --- a/drivers/xen/xenbus/xenbus_probe.c
> +++ b/drivers/xen/xenbus/xenbus_probe.c
> @@ -719,37 +719,61 @@ static int __init xenstored_local_init(void)
>  	return err;
>  }
>  
> +enum xenstore_init {
> +	UNKNOWN,
> +	PV,
> +	HVM,
> +	LOCAL,
> +};
>  static int __init xenbus_init(void)
>  {
>  	int err = 0;
> +	enum xenstore_init usage = UNKNOWN;
> +	uint64_t v = 0;
>  
>  	if (!xen_domain())
>  		return -ENODEV;
>  
>  	xenbus_ring_ops_init();
>  
> -	if (xen_hvm_domain()) {
> -		uint64_t v = 0;
> -		err = hvm_get_parameter(HVM_PARAM_STORE_EVTCHN, &v);
> -		if (err)
> -			goto out_error;
> -		xen_store_evtchn = (int)v;
> -		err = hvm_get_parameter(HVM_PARAM_STORE_PFN, &v);
> -		if (err)
> -			goto out_error;
> -		xen_store_mfn = (unsigned long)v;
> -		xen_store_interface = ioremap(xen_store_mfn << PAGE_SHIFT, PAGE_SIZE);
> -	} else {
> -		xen_store_evtchn = xen_start_info->store_evtchn;
> -		xen_store_mfn = xen_start_info->store_mfn;
> -		if (xen_store_evtchn)
> -			xenstored_ready = 1;
> -		else {
> +	if (xen_pv_domain())
> +		usage = PV;
> +	if (xen_hvm_domain())
> +		usage = HVM;
> +	if (xen_hvm_domain() && xen_initial_domain())
> +		usage = LOCAL;
> +	if (xen_pv_domain() && !xen_start_info->store_evtchn)
> +		usage = LOCAL;
> +	if (xen_pv_domain() && xen_start_info->store_evtchn)
> +		xenstored_ready = 1;
> +
> +	switch (usage) {
> +		case LOCAL:
>  			err = xenstored_local_init();
>  			if (err)
>  				goto out_error;
> -		}
> -		xen_store_interface = mfn_to_virt(xen_store_mfn);
> +			xen_store_interface = mfn_to_virt(xen_store_mfn);
> +			break;
> +		case PV:
> +			xen_store_evtchn = xen_start_info->store_evtchn;
> +			xen_store_mfn = xen_start_info->store_mfn;
> +			xen_store_interface = mfn_to_virt(xen_store_mfn);
> +			break;
> +		case HVM:
> +			err = hvm_get_parameter(HVM_PARAM_STORE_EVTCHN, &v);
> +			if (err)
> +				goto out_error;
> +			xen_store_evtchn = (int)v;
> +			err = hvm_get_parameter(HVM_PARAM_STORE_PFN, &v);
> +			if (err)
> +				goto out_error;
> +			xen_store_mfn = (unsigned long)v;
> +			xen_store_interface =
> +				ioremap(xen_store_mfn << PAGE_SHIFT, PAGE_SIZE);
> +			break;
> +		default:
> +			pr_warn("Xenstore state unknown\n");
> +			break;
>  	}
>  
>  	/* Initialize the interface to xenstore. */
> diff --git a/drivers/xen/xenbus/xenbus_xs.c b/drivers/xen/xenbus/xenbus_xs.c
> index bce15cf..131dec0 100644
> --- a/drivers/xen/xenbus/xenbus_xs.c
> +++ b/drivers/xen/xenbus/xenbus_xs.c
> @@ -44,6 +44,7 @@
>  #include <linux/rwsem.h>
>  #include <linux/module.h>
>  #include <linux/mutex.h>
> +#include <asm/xen/hypervisor.h>
>  #include <xen/xenbus.h>
>  #include <xen/xen.h>
>  #include "xenbus_comms.h"
> @@ -622,7 +623,7 @@ static void xs_reset_watches(void)
>  {
>  	int err, supported = 0;
>  
> -	if (!xen_hvm_domain())
> +	if (!xen_hvm_domain() || xen_initial_domain())
>  		return;
>  
>  	err = xenbus_scanf(XBT_NIL, "control",
> -- 
> 1.7.2.5

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 14 13:16:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 13:16:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TCVkW-0003z0-DA; Fri, 14 Sep 2012 13:16: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 1TCVkU-0003yk-B5
	for xen-devel@lists.xensource.com; Fri, 14 Sep 2012 13:15:58 +0000
Received: from [85.158.139.83:37083] by server-3.bemta-5.messagelabs.com id
	D9/D0-21836-D0E23505; Fri, 14 Sep 2012 13:15:57 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1347628555!26568050!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDc1MTgyMQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31094 invoked from network); 14 Sep 2012 13:15:56 -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; 14 Sep 2012 13:15:56 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q8EDFVXB003928
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 14 Sep 2012 13:15:31 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q8EDFUKv011984
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 14 Sep 2012 13:15:30 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
	q8EDFUhW031022; Fri, 14 Sep 2012 08:15:30 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 14 Sep 2012 06:15:30 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 4D12A4031C; Fri, 14 Sep 2012 09:04:50 -0400 (EDT)
Date: Fri, 14 Sep 2012 09:04:50 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20120914130450.GJ25249@phenom.dumpdata.com>
References: <alpine.DEB.2.02.1209141145150.29232@kaball.uk.xensource.com>
	<1347621207-11294-9-git-send-email-stefano.stabellini@eu.citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1347621207-11294-9-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, linaro-dev@lists.linaro.org,
	Ian.Campbell@citrix.com, arnd@arndb.de, catalin.marinas@arm.com,
	tim@xen.org, linux-kernel@vger.kernel.org,
	linux@arm.linux.org.uk, linux-arm-kernel@lists.infradead.org
Subject: Re: [Xen-devel] [PATCH v4 09/24] xen/arm: Introduce xen_ulong_t for
	unsigned long
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Sep 14, 2012 at 12:13:11PM +0100, Stefano Stabellini wrote:
> All the original Xen headers have xen_ulong_t as unsigned long type, however
> when they have been imported in Linux, xen_ulong_t has been replaced with
> unsigned long. That might work for x86 and ia64 but it does not for arm.
> Bring back xen_ulong_t and let each architecture define xen_ulong_t as they
> see fit.
> 
> Also explicitly size pointers (__DEFINE_GUEST_HANDLE) to 64 bit.
> 
> 
> Changes in v3:
> 
> - remove the incorrect changes to multicall_entry;
> - remove the change to apic_physbase.
> 
> 
> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
for the generic parts; all other:
Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

> ---
>  arch/arm/include/asm/xen/interface.h  |    8 ++++++--
>  arch/ia64/include/asm/xen/interface.h |    1 +
>  arch/x86/include/asm/xen/interface.h  |    1 +
>  include/xen/interface/memory.h        |   12 ++++++------
>  include/xen/interface/physdev.h       |    2 +-
>  include/xen/interface/version.h       |    2 +-
>  6 files changed, 16 insertions(+), 10 deletions(-)
> 
> diff --git a/arch/arm/include/asm/xen/interface.h b/arch/arm/include/asm/xen/interface.h
> index 74c72b5..ae05e56 100644
> --- a/arch/arm/include/asm/xen/interface.h
> +++ b/arch/arm/include/asm/xen/interface.h
> @@ -9,8 +9,11 @@
>  
>  #include <linux/types.h>
>  
> +#define uint64_aligned_t uint64_t __attribute__((aligned(8)))
> +
>  #define __DEFINE_GUEST_HANDLE(name, type) \
> -	typedef type * __guest_handle_ ## name
> +	typedef struct { union { type *p; uint64_aligned_t q; }; }  \
> +        __guest_handle_ ## name
>  
>  #define DEFINE_GUEST_HANDLE_STRUCT(name) \
>  	__DEFINE_GUEST_HANDLE(name, struct name)
> @@ -21,13 +24,14 @@
>  	do {						\
>  		if (sizeof(hnd) == 8)			\
>  			*(uint64_t *)&(hnd) = 0;	\
> -		(hnd) = val;				\
> +		(hnd).p = val;				\
>  	} while (0)
>  
>  #ifndef __ASSEMBLY__
>  /* Explicitly size integers that represent pfns in the interface with
>   * Xen so that we can have one ABI that works for 32 and 64 bit guests. */
>  typedef uint64_t xen_pfn_t;
> +typedef uint64_t xen_ulong_t;
>  /* Guest handles for primitive C types. */
>  __DEFINE_GUEST_HANDLE(uchar, unsigned char);
>  __DEFINE_GUEST_HANDLE(uint,  unsigned int);
> diff --git a/arch/ia64/include/asm/xen/interface.h b/arch/ia64/include/asm/xen/interface.h
> index 686464e..7c83445 100644
> --- a/arch/ia64/include/asm/xen/interface.h
> +++ b/arch/ia64/include/asm/xen/interface.h
> @@ -71,6 +71,7 @@
>   * with Xen so that we could have one ABI that works for 32 and 64 bit
>   * guests. */
>  typedef unsigned long xen_pfn_t;
> +typedef unsigned long xen_ulong_t;
>  /* Guest handles for primitive C types. */
>  __DEFINE_GUEST_HANDLE(uchar, unsigned char);
>  __DEFINE_GUEST_HANDLE(uint, unsigned int);
> diff --git a/arch/x86/include/asm/xen/interface.h b/arch/x86/include/asm/xen/interface.h
> index 2289075..25cc8df 100644
> --- a/arch/x86/include/asm/xen/interface.h
> +++ b/arch/x86/include/asm/xen/interface.h
> @@ -51,6 +51,7 @@
>   * with Xen so that on ARM we can have one ABI that works for 32 and 64
>   * bit guests. */
>  typedef unsigned long xen_pfn_t;
> +typedef unsigned long xen_ulong_t;
>  /* Guest handles for primitive C types. */
>  __DEFINE_GUEST_HANDLE(uchar, unsigned char);
>  __DEFINE_GUEST_HANDLE(uint,  unsigned int);
> diff --git a/include/xen/interface/memory.h b/include/xen/interface/memory.h
> index abbbff0..b5c3098 100644
> --- a/include/xen/interface/memory.h
> +++ b/include/xen/interface/memory.h
> @@ -34,7 +34,7 @@ struct xen_memory_reservation {
>      GUEST_HANDLE(xen_pfn_t) extent_start;
>  
>      /* Number of extents, and size/alignment of each (2^extent_order pages). */
> -    unsigned long  nr_extents;
> +    xen_ulong_t  nr_extents;
>      unsigned int   extent_order;
>  
>      /*
> @@ -92,7 +92,7 @@ struct xen_memory_exchange {
>       *     command will be non-zero.
>       *  5. THIS FIELD MUST BE INITIALISED TO ZERO BY THE CALLER!
>       */
> -    unsigned long nr_exchanged;
> +    xen_ulong_t nr_exchanged;
>  };
>  
>  DEFINE_GUEST_HANDLE_STRUCT(xen_memory_exchange);
> @@ -148,8 +148,8 @@ DEFINE_GUEST_HANDLE_STRUCT(xen_machphys_mfn_list);
>   */
>  #define XENMEM_machphys_mapping     12
>  struct xen_machphys_mapping {
> -    unsigned long v_start, v_end; /* Start and end virtual addresses.   */
> -    unsigned long max_mfn;        /* Maximum MFN that can be looked up. */
> +    xen_ulong_t v_start, v_end; /* Start and end virtual addresses.   */
> +    xen_ulong_t max_mfn;        /* Maximum MFN that can be looked up. */
>  };
>  DEFINE_GUEST_HANDLE_STRUCT(xen_machphys_mapping_t);
>  
> @@ -169,7 +169,7 @@ struct xen_add_to_physmap {
>      unsigned int space;
>  
>      /* Index into source mapping space. */
> -    unsigned long idx;
> +    xen_ulong_t idx;
>  
>      /* GPFN where the source mapping page should appear. */
>      xen_pfn_t gpfn;
> @@ -186,7 +186,7 @@ struct xen_translate_gpfn_list {
>      domid_t domid;
>  
>      /* Length of list. */
> -    unsigned long nr_gpfns;
> +    xen_ulong_t nr_gpfns;
>  
>      /* List of GPFNs to translate. */
>      GUEST_HANDLE(ulong) gpfn_list;
> diff --git a/include/xen/interface/physdev.h b/include/xen/interface/physdev.h
> index 9ce788d..f616514 100644
> --- a/include/xen/interface/physdev.h
> +++ b/include/xen/interface/physdev.h
> @@ -56,7 +56,7 @@ struct physdev_eoi {
>  #define PHYSDEVOP_pirq_eoi_gmfn_v2       28
>  struct physdev_pirq_eoi_gmfn {
>      /* IN */
> -    unsigned long gmfn;
> +    xen_ulong_t gmfn;
>  };
>  
>  /*
> diff --git a/include/xen/interface/version.h b/include/xen/interface/version.h
> index e8b6519..30280c9 100644
> --- a/include/xen/interface/version.h
> +++ b/include/xen/interface/version.h
> @@ -45,7 +45,7 @@ struct xen_changeset_info {
>  
>  #define XENVER_platform_parameters 5
>  struct xen_platform_parameters {
> -    unsigned long virt_start;
> +    xen_ulong_t virt_start;
>  };
>  
>  #define XENVER_get_features 6
> -- 
> 1.7.2.5

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 14 13:16:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 13:16:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TCVkW-0003z0-DA; Fri, 14 Sep 2012 13:16: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 1TCVkU-0003yk-B5
	for xen-devel@lists.xensource.com; Fri, 14 Sep 2012 13:15:58 +0000
Received: from [85.158.139.83:37083] by server-3.bemta-5.messagelabs.com id
	D9/D0-21836-D0E23505; Fri, 14 Sep 2012 13:15:57 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1347628555!26568050!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDc1MTgyMQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31094 invoked from network); 14 Sep 2012 13:15:56 -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; 14 Sep 2012 13:15:56 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q8EDFVXB003928
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 14 Sep 2012 13:15:31 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q8EDFUKv011984
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 14 Sep 2012 13:15:30 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
	q8EDFUhW031022; Fri, 14 Sep 2012 08:15:30 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 14 Sep 2012 06:15:30 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 4D12A4031C; Fri, 14 Sep 2012 09:04:50 -0400 (EDT)
Date: Fri, 14 Sep 2012 09:04:50 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20120914130450.GJ25249@phenom.dumpdata.com>
References: <alpine.DEB.2.02.1209141145150.29232@kaball.uk.xensource.com>
	<1347621207-11294-9-git-send-email-stefano.stabellini@eu.citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1347621207-11294-9-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, linaro-dev@lists.linaro.org,
	Ian.Campbell@citrix.com, arnd@arndb.de, catalin.marinas@arm.com,
	tim@xen.org, linux-kernel@vger.kernel.org,
	linux@arm.linux.org.uk, linux-arm-kernel@lists.infradead.org
Subject: Re: [Xen-devel] [PATCH v4 09/24] xen/arm: Introduce xen_ulong_t for
	unsigned long
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Sep 14, 2012 at 12:13:11PM +0100, Stefano Stabellini wrote:
> All the original Xen headers have xen_ulong_t as unsigned long type, however
> when they have been imported in Linux, xen_ulong_t has been replaced with
> unsigned long. That might work for x86 and ia64 but it does not for arm.
> Bring back xen_ulong_t and let each architecture define xen_ulong_t as they
> see fit.
> 
> Also explicitly size pointers (__DEFINE_GUEST_HANDLE) to 64 bit.
> 
> 
> Changes in v3:
> 
> - remove the incorrect changes to multicall_entry;
> - remove the change to apic_physbase.
> 
> 
> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
for the generic parts; all other:
Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

> ---
>  arch/arm/include/asm/xen/interface.h  |    8 ++++++--
>  arch/ia64/include/asm/xen/interface.h |    1 +
>  arch/x86/include/asm/xen/interface.h  |    1 +
>  include/xen/interface/memory.h        |   12 ++++++------
>  include/xen/interface/physdev.h       |    2 +-
>  include/xen/interface/version.h       |    2 +-
>  6 files changed, 16 insertions(+), 10 deletions(-)
> 
> diff --git a/arch/arm/include/asm/xen/interface.h b/arch/arm/include/asm/xen/interface.h
> index 74c72b5..ae05e56 100644
> --- a/arch/arm/include/asm/xen/interface.h
> +++ b/arch/arm/include/asm/xen/interface.h
> @@ -9,8 +9,11 @@
>  
>  #include <linux/types.h>
>  
> +#define uint64_aligned_t uint64_t __attribute__((aligned(8)))
> +
>  #define __DEFINE_GUEST_HANDLE(name, type) \
> -	typedef type * __guest_handle_ ## name
> +	typedef struct { union { type *p; uint64_aligned_t q; }; }  \
> +        __guest_handle_ ## name
>  
>  #define DEFINE_GUEST_HANDLE_STRUCT(name) \
>  	__DEFINE_GUEST_HANDLE(name, struct name)
> @@ -21,13 +24,14 @@
>  	do {						\
>  		if (sizeof(hnd) == 8)			\
>  			*(uint64_t *)&(hnd) = 0;	\
> -		(hnd) = val;				\
> +		(hnd).p = val;				\
>  	} while (0)
>  
>  #ifndef __ASSEMBLY__
>  /* Explicitly size integers that represent pfns in the interface with
>   * Xen so that we can have one ABI that works for 32 and 64 bit guests. */
>  typedef uint64_t xen_pfn_t;
> +typedef uint64_t xen_ulong_t;
>  /* Guest handles for primitive C types. */
>  __DEFINE_GUEST_HANDLE(uchar, unsigned char);
>  __DEFINE_GUEST_HANDLE(uint,  unsigned int);
> diff --git a/arch/ia64/include/asm/xen/interface.h b/arch/ia64/include/asm/xen/interface.h
> index 686464e..7c83445 100644
> --- a/arch/ia64/include/asm/xen/interface.h
> +++ b/arch/ia64/include/asm/xen/interface.h
> @@ -71,6 +71,7 @@
>   * with Xen so that we could have one ABI that works for 32 and 64 bit
>   * guests. */
>  typedef unsigned long xen_pfn_t;
> +typedef unsigned long xen_ulong_t;
>  /* Guest handles for primitive C types. */
>  __DEFINE_GUEST_HANDLE(uchar, unsigned char);
>  __DEFINE_GUEST_HANDLE(uint, unsigned int);
> diff --git a/arch/x86/include/asm/xen/interface.h b/arch/x86/include/asm/xen/interface.h
> index 2289075..25cc8df 100644
> --- a/arch/x86/include/asm/xen/interface.h
> +++ b/arch/x86/include/asm/xen/interface.h
> @@ -51,6 +51,7 @@
>   * with Xen so that on ARM we can have one ABI that works for 32 and 64
>   * bit guests. */
>  typedef unsigned long xen_pfn_t;
> +typedef unsigned long xen_ulong_t;
>  /* Guest handles for primitive C types. */
>  __DEFINE_GUEST_HANDLE(uchar, unsigned char);
>  __DEFINE_GUEST_HANDLE(uint,  unsigned int);
> diff --git a/include/xen/interface/memory.h b/include/xen/interface/memory.h
> index abbbff0..b5c3098 100644
> --- a/include/xen/interface/memory.h
> +++ b/include/xen/interface/memory.h
> @@ -34,7 +34,7 @@ struct xen_memory_reservation {
>      GUEST_HANDLE(xen_pfn_t) extent_start;
>  
>      /* Number of extents, and size/alignment of each (2^extent_order pages). */
> -    unsigned long  nr_extents;
> +    xen_ulong_t  nr_extents;
>      unsigned int   extent_order;
>  
>      /*
> @@ -92,7 +92,7 @@ struct xen_memory_exchange {
>       *     command will be non-zero.
>       *  5. THIS FIELD MUST BE INITIALISED TO ZERO BY THE CALLER!
>       */
> -    unsigned long nr_exchanged;
> +    xen_ulong_t nr_exchanged;
>  };
>  
>  DEFINE_GUEST_HANDLE_STRUCT(xen_memory_exchange);
> @@ -148,8 +148,8 @@ DEFINE_GUEST_HANDLE_STRUCT(xen_machphys_mfn_list);
>   */
>  #define XENMEM_machphys_mapping     12
>  struct xen_machphys_mapping {
> -    unsigned long v_start, v_end; /* Start and end virtual addresses.   */
> -    unsigned long max_mfn;        /* Maximum MFN that can be looked up. */
> +    xen_ulong_t v_start, v_end; /* Start and end virtual addresses.   */
> +    xen_ulong_t max_mfn;        /* Maximum MFN that can be looked up. */
>  };
>  DEFINE_GUEST_HANDLE_STRUCT(xen_machphys_mapping_t);
>  
> @@ -169,7 +169,7 @@ struct xen_add_to_physmap {
>      unsigned int space;
>  
>      /* Index into source mapping space. */
> -    unsigned long idx;
> +    xen_ulong_t idx;
>  
>      /* GPFN where the source mapping page should appear. */
>      xen_pfn_t gpfn;
> @@ -186,7 +186,7 @@ struct xen_translate_gpfn_list {
>      domid_t domid;
>  
>      /* Length of list. */
> -    unsigned long nr_gpfns;
> +    xen_ulong_t nr_gpfns;
>  
>      /* List of GPFNs to translate. */
>      GUEST_HANDLE(ulong) gpfn_list;
> diff --git a/include/xen/interface/physdev.h b/include/xen/interface/physdev.h
> index 9ce788d..f616514 100644
> --- a/include/xen/interface/physdev.h
> +++ b/include/xen/interface/physdev.h
> @@ -56,7 +56,7 @@ struct physdev_eoi {
>  #define PHYSDEVOP_pirq_eoi_gmfn_v2       28
>  struct physdev_pirq_eoi_gmfn {
>      /* IN */
> -    unsigned long gmfn;
> +    xen_ulong_t gmfn;
>  };
>  
>  /*
> diff --git a/include/xen/interface/version.h b/include/xen/interface/version.h
> index e8b6519..30280c9 100644
> --- a/include/xen/interface/version.h
> +++ b/include/xen/interface/version.h
> @@ -45,7 +45,7 @@ struct xen_changeset_info {
>  
>  #define XENVER_platform_parameters 5
>  struct xen_platform_parameters {
> -    unsigned long virt_start;
> +    xen_ulong_t virt_start;
>  };
>  
>  #define XENVER_get_features 6
> -- 
> 1.7.2.5

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 14 13:17:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 13:17:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TCVmD-0004BU-2h; Fri, 14 Sep 2012 13:17: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 1TCVmB-0004BE-F0
	for xen-devel@lists.xensource.com; Fri, 14 Sep 2012 13:17:43 +0000
Received: from [85.158.139.211:60992] by server-11.bemta-5.messagelabs.com id
	C9/DB-24658-67E23505; Fri, 14 Sep 2012 13:17:42 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-206.messagelabs.com!1347628662!18583037!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDkyOTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11808 invoked from network); 14 Sep 2012 13:17:42 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Sep 2012 13:17:42 -0000
X-IronPort-AV: E=Sophos;i="4.80,422,1344211200"; d="scan'208";a="14546991"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Sep 2012 13:17: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.279.1;
	Fri, 14 Sep 2012 14:17:41 +0100
Message-ID: <1347628660.24226.197.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Date: Fri, 14 Sep 2012 14:17:40 +0100
In-Reply-To: <1347627587.24226.192.camel@zakaz.uk.xensource.com>
References: <alpine.DEB.2.02.1208221159560.15568@kaball.uk.xensource.com>
	<1345633688-31684-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<1347627587.24226.192.camel@zakaz.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-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 v4 1/6] xen: improve changes to
 xen_add_to_physmap
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

(forgot to CC Mukesh on y last mail like I said it would, I've done it
now and will bounce the last one to you Mukesh)

On Fri, 2012-09-14 at 13:59 +0100, Ian Campbell wrote:
> 
> Might we prefer to have a batched version of this call? I don't think
> we can shoehorn the necessary fields into xen_add_to_physmap_t though.

Actually, talking about this we Stefano we think we can. Since both idx
and gpfn are unsigned longs they can become unions with a GUEST_HANDLE
without changing the ABI on x86_32 or x86_64.

If we do this then we should do away with the singleton
XENMAPSPACE_gmfn_foreign and just make it a batched interface.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 14 13:17:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 13:17:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TCVmD-0004BU-2h; Fri, 14 Sep 2012 13:17: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 1TCVmB-0004BE-F0
	for xen-devel@lists.xensource.com; Fri, 14 Sep 2012 13:17:43 +0000
Received: from [85.158.139.211:60992] by server-11.bemta-5.messagelabs.com id
	C9/DB-24658-67E23505; Fri, 14 Sep 2012 13:17:42 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-206.messagelabs.com!1347628662!18583037!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDkyOTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11808 invoked from network); 14 Sep 2012 13:17:42 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Sep 2012 13:17:42 -0000
X-IronPort-AV: E=Sophos;i="4.80,422,1344211200"; d="scan'208";a="14546991"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Sep 2012 13:17: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.279.1;
	Fri, 14 Sep 2012 14:17:41 +0100
Message-ID: <1347628660.24226.197.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Date: Fri, 14 Sep 2012 14:17:40 +0100
In-Reply-To: <1347627587.24226.192.camel@zakaz.uk.xensource.com>
References: <alpine.DEB.2.02.1208221159560.15568@kaball.uk.xensource.com>
	<1345633688-31684-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<1347627587.24226.192.camel@zakaz.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-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 v4 1/6] xen: improve changes to
 xen_add_to_physmap
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

(forgot to CC Mukesh on y last mail like I said it would, I've done it
now and will bounce the last one to you Mukesh)

On Fri, 2012-09-14 at 13:59 +0100, Ian Campbell wrote:
> 
> Might we prefer to have a batched version of this call? I don't think
> we can shoehorn the necessary fields into xen_add_to_physmap_t though.

Actually, talking about this we Stefano we think we can. Since both idx
and gpfn are unsigned longs they can become unions with a GUEST_HANDLE
without changing the ABI on x86_32 or x86_64.

If we do this then we should do away with the singleton
XENMAPSPACE_gmfn_foreign and just make it a batched interface.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 14 13:19:20 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 13: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 1TCVnZ-0004KT-JA; Fri, 14 Sep 2012 13:19:09 +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 1TCVnY-0004KI-AU
	for xen-devel@lists.xensource.com; Fri, 14 Sep 2012 13:19:08 +0000
Received: from [85.158.139.83:60710] by server-8.bemta-5.messagelabs.com id
	4B/A5-15219-BCE23505; Fri, 14 Sep 2012 13:19:07 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1347628745!30502498!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDc1MTgyMQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25233 invoked from network); 14 Sep 2012 13:19:06 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-3.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 14 Sep 2012 13:19:06 -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 q8EDInil007043
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 14 Sep 2012 13:18:49 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
	q8EDImEW012292
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 14 Sep 2012 13:18:48 GMT
Received: from abhmt104.oracle.com (abhmt104.oracle.com [141.146.116.56])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q8EDImlS000836; Fri, 14 Sep 2012 08:18:48 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 14 Sep 2012 06:18:47 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id C66464031C; Fri, 14 Sep 2012 09:08:07 -0400 (EDT)
Date: Fri, 14 Sep 2012 09:08:07 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20120914130807.GK25249@phenom.dumpdata.com>
References: <alpine.DEB.2.02.1209141145150.29232@kaball.uk.xensource.com>
	<1347621207-11294-7-git-send-email-stefano.stabellini@eu.citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1347621207-11294-7-git-send-email-stefano.stabellini@eu.citrix.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: xen-devel@lists.xensource.com, linaro-dev@lists.linaro.org,
	Ian.Campbell@citrix.com, arnd@arndb.de, catalin.marinas@arm.com,
	tim@xen.org, linux-kernel@vger.kernel.org,
	linux@arm.linux.org.uk, linux-arm-kernel@lists.infradead.org
Subject: Re: [Xen-devel] [PATCH v4 07/24] xen/arm: Xen detection and
 shared_info page mapping
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Sep 14, 2012 at 12:13:09PM +0100, Stefano Stabellini wrote:
> Check for a node in the device tree compatible with "xen,xen", if it is
> present set xen_domain_type to XEN_HVM_DOMAIN and continue
> initialization.
> 
> Map the real shared info page using XENMEM_add_to_physmap with
> XENMAPSPACE_shared_info.
> 
> Changes in v4:
> 
> - simpler parsing of Xen version in the compatible DT node.
> 
> Changes in v3:
> 
> - use the "xen,xen" notation rather than "arm,xen";
> - add an additional check on the presence of the Xen version.
> 
> Changes in v2:
> 
> - replace pr_info with pr_debug.
> 
> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> ---
>  arch/arm/xen/enlighten.c |   61 ++++++++++++++++++++++++++++++++++++++++++++++
>  1 files changed, 61 insertions(+), 0 deletions(-)
> 
> diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
> index c535540..6a0217d 100644
> --- a/arch/arm/xen/enlighten.c
> +++ b/arch/arm/xen/enlighten.c
> @@ -5,6 +5,9 @@
>  #include <asm/xen/hypervisor.h>
>  #include <asm/xen/hypercall.h>
>  #include <linux/module.h>
> +#include <linux/of.h>
> +#include <linux/of_irq.h>
> +#include <linux/of_address.h>
>  
>  struct start_info _xen_start_info;
>  struct start_info *xen_start_info = &_xen_start_info;
> @@ -33,3 +36,61 @@ int xen_remap_domain_mfn_range(struct vm_area_struct *vma,
>  	return -ENOSYS;
>  }
>  EXPORT_SYMBOL_GPL(xen_remap_domain_mfn_range);
> +
> +/*
> + * see Documentation/devicetree/bindings/arm/xen.txt for the
> + * documentation of the Xen Device Tree format.
> + */
> +static int __init xen_guest_init(void)
> +{
> +	struct xen_add_to_physmap xatp;
> +	static struct shared_info *shared_info_page = 0;
> +	struct device_node *node;
> +	int len;
> +	const char *s = NULL;
> +	const char *version = NULL;
> +	const char *xen_prefix = "xen,xen-";
> +
> +	node = of_find_compatible_node(NULL, NULL, "xen,xen");
> +	if (!node) {
> +		pr_debug("No Xen support\n");
> +		return 0;
> +	}
> +	s = of_get_property(node, "compatible", &len);
> +	if (strlen(xen_prefix) + 3  < len &&
> +			!strncmp(xen_prefix, s, strlen(xen_prefix)))

If we have version '4.3.1' won't this trip us over?

Or if we only have 'major' and 'minor', then won't '4.11' trip us
over too?


> +		version = s + strlen(xen_prefix);
> +	if (version == NULL) {
> +		pr_debug("Xen version not found\n");
> +		return 0;
> +	}
> +	xen_domain_type = XEN_HVM_DOMAIN;
> +
> +	if (!shared_info_page)
> +		shared_info_page = (struct shared_info *)
> +			get_zeroed_page(GFP_KERNEL);
> +	if (!shared_info_page) {
> +		pr_err("not enough memory\n");
> +		return -ENOMEM;
> +	}
> +	xatp.domid = DOMID_SELF;
> +	xatp.idx = 0;
> +	xatp.space = XENMAPSPACE_shared_info;
> +	xatp.gpfn = __pa(shared_info_page) >> PAGE_SHIFT;
> +	if (HYPERVISOR_memory_op(XENMEM_add_to_physmap, &xatp))
> +		BUG();
> +
> +	HYPERVISOR_shared_info = (struct shared_info *)shared_info_page;
> +
> +	/* xen_vcpu is a pointer to the vcpu_info struct in the shared_info
> +	 * page, we use it in the event channel upcall and in some pvclock
> +	 * related functions. We don't need the vcpu_info placement
> +	 * optimizations because we don't use any pv_mmu or pv_irq op on
> +	 * HVM.
> +	 * The shared info contains exactly 1 CPU (the boot CPU). The guest
> +	 * is required to use VCPUOP_register_vcpu_info to place vcpu info
> +	 * for secondary CPUs as they are brought up. */
> +	per_cpu(xen_vcpu, 0) = &HYPERVISOR_shared_info->vcpu_info[0];
> +	return 0;
> +}
> +core_initcall(xen_guest_init);
> -- 
> 1.7.2.5

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 14 13:19:20 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 13: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 1TCVnZ-0004KT-JA; Fri, 14 Sep 2012 13:19:09 +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 1TCVnY-0004KI-AU
	for xen-devel@lists.xensource.com; Fri, 14 Sep 2012 13:19:08 +0000
Received: from [85.158.139.83:60710] by server-8.bemta-5.messagelabs.com id
	4B/A5-15219-BCE23505; Fri, 14 Sep 2012 13:19:07 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1347628745!30502498!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDc1MTgyMQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25233 invoked from network); 14 Sep 2012 13:19:06 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-3.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 14 Sep 2012 13:19:06 -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 q8EDInil007043
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 14 Sep 2012 13:18:49 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
	q8EDImEW012292
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 14 Sep 2012 13:18:48 GMT
Received: from abhmt104.oracle.com (abhmt104.oracle.com [141.146.116.56])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q8EDImlS000836; Fri, 14 Sep 2012 08:18:48 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 14 Sep 2012 06:18:47 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id C66464031C; Fri, 14 Sep 2012 09:08:07 -0400 (EDT)
Date: Fri, 14 Sep 2012 09:08:07 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20120914130807.GK25249@phenom.dumpdata.com>
References: <alpine.DEB.2.02.1209141145150.29232@kaball.uk.xensource.com>
	<1347621207-11294-7-git-send-email-stefano.stabellini@eu.citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1347621207-11294-7-git-send-email-stefano.stabellini@eu.citrix.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: xen-devel@lists.xensource.com, linaro-dev@lists.linaro.org,
	Ian.Campbell@citrix.com, arnd@arndb.de, catalin.marinas@arm.com,
	tim@xen.org, linux-kernel@vger.kernel.org,
	linux@arm.linux.org.uk, linux-arm-kernel@lists.infradead.org
Subject: Re: [Xen-devel] [PATCH v4 07/24] xen/arm: Xen detection and
 shared_info page mapping
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Sep 14, 2012 at 12:13:09PM +0100, Stefano Stabellini wrote:
> Check for a node in the device tree compatible with "xen,xen", if it is
> present set xen_domain_type to XEN_HVM_DOMAIN and continue
> initialization.
> 
> Map the real shared info page using XENMEM_add_to_physmap with
> XENMAPSPACE_shared_info.
> 
> Changes in v4:
> 
> - simpler parsing of Xen version in the compatible DT node.
> 
> Changes in v3:
> 
> - use the "xen,xen" notation rather than "arm,xen";
> - add an additional check on the presence of the Xen version.
> 
> Changes in v2:
> 
> - replace pr_info with pr_debug.
> 
> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> ---
>  arch/arm/xen/enlighten.c |   61 ++++++++++++++++++++++++++++++++++++++++++++++
>  1 files changed, 61 insertions(+), 0 deletions(-)
> 
> diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
> index c535540..6a0217d 100644
> --- a/arch/arm/xen/enlighten.c
> +++ b/arch/arm/xen/enlighten.c
> @@ -5,6 +5,9 @@
>  #include <asm/xen/hypervisor.h>
>  #include <asm/xen/hypercall.h>
>  #include <linux/module.h>
> +#include <linux/of.h>
> +#include <linux/of_irq.h>
> +#include <linux/of_address.h>
>  
>  struct start_info _xen_start_info;
>  struct start_info *xen_start_info = &_xen_start_info;
> @@ -33,3 +36,61 @@ int xen_remap_domain_mfn_range(struct vm_area_struct *vma,
>  	return -ENOSYS;
>  }
>  EXPORT_SYMBOL_GPL(xen_remap_domain_mfn_range);
> +
> +/*
> + * see Documentation/devicetree/bindings/arm/xen.txt for the
> + * documentation of the Xen Device Tree format.
> + */
> +static int __init xen_guest_init(void)
> +{
> +	struct xen_add_to_physmap xatp;
> +	static struct shared_info *shared_info_page = 0;
> +	struct device_node *node;
> +	int len;
> +	const char *s = NULL;
> +	const char *version = NULL;
> +	const char *xen_prefix = "xen,xen-";
> +
> +	node = of_find_compatible_node(NULL, NULL, "xen,xen");
> +	if (!node) {
> +		pr_debug("No Xen support\n");
> +		return 0;
> +	}
> +	s = of_get_property(node, "compatible", &len);
> +	if (strlen(xen_prefix) + 3  < len &&
> +			!strncmp(xen_prefix, s, strlen(xen_prefix)))

If we have version '4.3.1' won't this trip us over?

Or if we only have 'major' and 'minor', then won't '4.11' trip us
over too?


> +		version = s + strlen(xen_prefix);
> +	if (version == NULL) {
> +		pr_debug("Xen version not found\n");
> +		return 0;
> +	}
> +	xen_domain_type = XEN_HVM_DOMAIN;
> +
> +	if (!shared_info_page)
> +		shared_info_page = (struct shared_info *)
> +			get_zeroed_page(GFP_KERNEL);
> +	if (!shared_info_page) {
> +		pr_err("not enough memory\n");
> +		return -ENOMEM;
> +	}
> +	xatp.domid = DOMID_SELF;
> +	xatp.idx = 0;
> +	xatp.space = XENMAPSPACE_shared_info;
> +	xatp.gpfn = __pa(shared_info_page) >> PAGE_SHIFT;
> +	if (HYPERVISOR_memory_op(XENMEM_add_to_physmap, &xatp))
> +		BUG();
> +
> +	HYPERVISOR_shared_info = (struct shared_info *)shared_info_page;
> +
> +	/* xen_vcpu is a pointer to the vcpu_info struct in the shared_info
> +	 * page, we use it in the event channel upcall and in some pvclock
> +	 * related functions. We don't need the vcpu_info placement
> +	 * optimizations because we don't use any pv_mmu or pv_irq op on
> +	 * HVM.
> +	 * The shared info contains exactly 1 CPU (the boot CPU). The guest
> +	 * is required to use VCPUOP_register_vcpu_info to place vcpu info
> +	 * for secondary CPUs as they are brought up. */
> +	per_cpu(xen_vcpu, 0) = &HYPERVISOR_shared_info->vcpu_info[0];
> +	return 0;
> +}
> +core_initcall(xen_guest_init);
> -- 
> 1.7.2.5

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 14 13:20:27 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 13:20: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 1TCVoe-0004S0-0n; Fri, 14 Sep 2012 13:20:16 +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 1TCVod-0004Ra-6h
	for xen-devel@lists.xensource.com; Fri, 14 Sep 2012 13:20:15 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1347628807!5857144!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDc1MTgyMQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20462 invoked from network); 14 Sep 2012 13:20:08 -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; 14 Sep 2012 13:20:08 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q8EDJspW008009
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 14 Sep 2012 13:19:54 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
	q8EDJr4Y014161
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 14 Sep 2012 13:19:53 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
	q8EDJr35005058; Fri, 14 Sep 2012 08:19:53 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 14 Sep 2012 06:19:53 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 200144031C; Fri, 14 Sep 2012 09:09:13 -0400 (EDT)
Date: Fri, 14 Sep 2012 09:09:13 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20120914130913.GL25249@phenom.dumpdata.com>
References: <alpine.DEB.2.02.1209141145150.29232@kaball.uk.xensource.com>
	<1347621207-11294-24-git-send-email-stefano.stabellini@eu.citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1347621207-11294-24-git-send-email-stefano.stabellini@eu.citrix.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: xen-devel@lists.xensource.com, linaro-dev@lists.linaro.org,
	Ian.Campbell@citrix.com, arnd@arndb.de, catalin.marinas@arm.com,
	tim@xen.org, linux-kernel@vger.kernel.org,
	linux@arm.linux.org.uk, linux-arm-kernel@lists.infradead.org
Subject: Re: [Xen-devel] [PATCH v4 24/24] MAINTAINERS: add myself as Xen ARM
	maintainer
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Sep 14, 2012 at 12:13:26PM +0100, Stefano Stabellini wrote:
> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> CC: Arnd Bergmann <arnd@arndb.de>
> CC: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

> ---
>  MAINTAINERS |    7 +++++++
>  1 files changed, 7 insertions(+), 0 deletions(-)
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index fdc0119..3d38291 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -7752,6 +7752,13 @@ F:	drivers/xen/
>  F:	arch/x86/include/asm/xen/
>  F:	include/xen/
>  
> +XEN HYPERVISOR ARM
> +M:	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> +L:	xen-devel@lists.xensource.com (moderated for non-subscribers)
> +S:	Supported
> +F:	arch/arm/xen/
> +F:	arch/arm/include/asm/xen/
> +
>  XEN NETWORK BACKEND DRIVER
>  M:	Ian Campbell <ian.campbell@citrix.com>
>  L:	xen-devel@lists.xensource.com (moderated for non-subscribers)
> -- 
> 1.7.2.5

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 14 13:20:27 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 13:20: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 1TCVoe-0004S0-0n; Fri, 14 Sep 2012 13:20:16 +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 1TCVod-0004Ra-6h
	for xen-devel@lists.xensource.com; Fri, 14 Sep 2012 13:20:15 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1347628807!5857144!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDc1MTgyMQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20462 invoked from network); 14 Sep 2012 13:20:08 -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; 14 Sep 2012 13:20:08 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q8EDJspW008009
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 14 Sep 2012 13:19:54 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
	q8EDJr4Y014161
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 14 Sep 2012 13:19:53 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
	q8EDJr35005058; Fri, 14 Sep 2012 08:19:53 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 14 Sep 2012 06:19:53 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 200144031C; Fri, 14 Sep 2012 09:09:13 -0400 (EDT)
Date: Fri, 14 Sep 2012 09:09:13 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20120914130913.GL25249@phenom.dumpdata.com>
References: <alpine.DEB.2.02.1209141145150.29232@kaball.uk.xensource.com>
	<1347621207-11294-24-git-send-email-stefano.stabellini@eu.citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1347621207-11294-24-git-send-email-stefano.stabellini@eu.citrix.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: xen-devel@lists.xensource.com, linaro-dev@lists.linaro.org,
	Ian.Campbell@citrix.com, arnd@arndb.de, catalin.marinas@arm.com,
	tim@xen.org, linux-kernel@vger.kernel.org,
	linux@arm.linux.org.uk, linux-arm-kernel@lists.infradead.org
Subject: Re: [Xen-devel] [PATCH v4 24/24] MAINTAINERS: add myself as Xen ARM
	maintainer
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Sep 14, 2012 at 12:13:26PM +0100, Stefano Stabellini wrote:
> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> CC: Arnd Bergmann <arnd@arndb.de>
> CC: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

> ---
>  MAINTAINERS |    7 +++++++
>  1 files changed, 7 insertions(+), 0 deletions(-)
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index fdc0119..3d38291 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -7752,6 +7752,13 @@ F:	drivers/xen/
>  F:	arch/x86/include/asm/xen/
>  F:	include/xen/
>  
> +XEN HYPERVISOR ARM
> +M:	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> +L:	xen-devel@lists.xensource.com (moderated for non-subscribers)
> +S:	Supported
> +F:	arch/arm/xen/
> +F:	arch/arm/include/asm/xen/
> +
>  XEN NETWORK BACKEND DRIVER
>  M:	Ian Campbell <ian.campbell@citrix.com>
>  L:	xen-devel@lists.xensource.com (moderated for non-subscribers)
> -- 
> 1.7.2.5

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 14 13:21:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 13:21:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TCVpt-0004bj-G4; Fri, 14 Sep 2012 13:21:33 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1TCVpr-0004bW-Rf
	for xen-devel@lists.xensource.com; Fri, 14 Sep 2012 13:21:32 +0000
Received: from [85.158.143.99:3970] by server-1.bemta-4.messagelabs.com id
	70/A2-12504-B5F23505; Fri, 14 Sep 2012 13:21:31 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1347628889!29463761!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDc1MTgyMQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25465 invoked from network); 14 Sep 2012 13:21:30 -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; 14 Sep 2012 13:21:30 -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 q8EDLEYN009500
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 14 Sep 2012 13:21:15 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q8EDLDdj004817
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 14 Sep 2012 13:21:14 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
	q8EDLD6E006842; Fri, 14 Sep 2012 08:21:13 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 14 Sep 2012 06:21:13 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 1E1F14031C; Fri, 14 Sep 2012 09:10:33 -0400 (EDT)
Date: Fri, 14 Sep 2012 09:10:33 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20120914131033.GM25249@phenom.dumpdata.com>
References: <alpine.DEB.2.02.1209141145150.29232@kaball.uk.xensource.com>
	<1347621207-11294-14-git-send-email-stefano.stabellini@eu.citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1347621207-11294-14-git-send-email-stefano.stabellini@eu.citrix.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: xen-devel@lists.xensource.com, linaro-dev@lists.linaro.org,
	Ian.Campbell@citrix.com, arnd@arndb.de, catalin.marinas@arm.com,
	tim@xen.org, linux-kernel@vger.kernel.org,
	linux@arm.linux.org.uk, linux-arm-kernel@lists.infradead.org
Subject: Re: [Xen-devel] [PATCH v4 14/24] xen/arm: initialize grant_table on
	ARM
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Sep 14, 2012 at 12:13:16PM +0100, Stefano Stabellini wrote:
> Initialize the grant table mapping at the address specified at index 0
> in the DT under the /xen node.
> After the grant table is initialized, call xenbus_probe (if not dom0).

So we don't really care about the grant's size then? The DT xen.txt
talks about it..
> 
> Changes in v2:
> 
> - introduce GRANT_TABLE_PHYSADDR;
> - remove unneeded initialization of boot_max_nr_grant_frames.
> 
> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> ---
>  arch/arm/xen/enlighten.c |   14 ++++++++++++++
>  1 files changed, 14 insertions(+), 0 deletions(-)
> 
> diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
> index c2a47a7..036a4d8 100644
> --- a/arch/arm/xen/enlighten.c
> +++ b/arch/arm/xen/enlighten.c
> @@ -1,8 +1,12 @@
>  #include <xen/xen.h>
> +#include <xen/grant_table.h>
> +#include <xen/hvm.h>
>  #include <xen/interface/xen.h>
>  #include <xen/interface/memory.h>
> +#include <xen/interface/hvm/params.h>
>  #include <xen/features.h>
>  #include <xen/platform_pci.h>
> +#include <xen/xenbus.h>
>  #include <asm/xen/hypervisor.h>
>  #include <asm/xen/hypercall.h>
>  #include <linux/module.h>
> @@ -42,6 +46,7 @@ EXPORT_SYMBOL_GPL(xen_remap_domain_mfn_range);
>   * see Documentation/devicetree/bindings/arm/xen.txt for the
>   * documentation of the Xen Device Tree format.
>   */
> +#define GRANT_TABLE_PHYSADDR 0
>  static int __init xen_guest_init(void)
>  {
>  	struct xen_add_to_physmap xatp;
> @@ -51,6 +56,7 @@ static int __init xen_guest_init(void)
>  	const char *s = NULL;
>  	const char *version = NULL;
>  	const char *xen_prefix = "xen,xen-";
> +	struct resource res;
>  
>  	node = of_find_compatible_node(NULL, NULL, "xen,xen");
>  	if (!node) {
> @@ -65,6 +71,9 @@ static int __init xen_guest_init(void)
>  		pr_debug("Xen version not found\n");
>  		return 0;
>  	}
> +	if (of_address_to_resource(node, GRANT_TABLE_PHYSADDR, &res))
> +		return 0;
> +	xen_hvm_resume_frames = res.start >> PAGE_SHIFT;
>  	xen_domain_type = XEN_HVM_DOMAIN;
>  
>  	xen_setup_features();
> @@ -98,6 +107,11 @@ static int __init xen_guest_init(void)
>  	 * is required to use VCPUOP_register_vcpu_info to place vcpu info
>  	 * for secondary CPUs as they are brought up. */
>  	per_cpu(xen_vcpu, 0) = &HYPERVISOR_shared_info->vcpu_info[0];
> +
> +	gnttab_init();
> +	if (!xen_initial_domain())
> +		xenbus_probe(NULL);
> +
>  	return 0;
>  }
>  core_initcall(xen_guest_init);
> -- 
> 1.7.2.5

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 14 13:21:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 13:21:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TCVpt-0004bj-G4; Fri, 14 Sep 2012 13:21:33 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1TCVpr-0004bW-Rf
	for xen-devel@lists.xensource.com; Fri, 14 Sep 2012 13:21:32 +0000
Received: from [85.158.143.99:3970] by server-1.bemta-4.messagelabs.com id
	70/A2-12504-B5F23505; Fri, 14 Sep 2012 13:21:31 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1347628889!29463761!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDc1MTgyMQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25465 invoked from network); 14 Sep 2012 13:21:30 -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; 14 Sep 2012 13:21:30 -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 q8EDLEYN009500
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 14 Sep 2012 13:21:15 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q8EDLDdj004817
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 14 Sep 2012 13:21:14 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
	q8EDLD6E006842; Fri, 14 Sep 2012 08:21:13 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 14 Sep 2012 06:21:13 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 1E1F14031C; Fri, 14 Sep 2012 09:10:33 -0400 (EDT)
Date: Fri, 14 Sep 2012 09:10:33 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20120914131033.GM25249@phenom.dumpdata.com>
References: <alpine.DEB.2.02.1209141145150.29232@kaball.uk.xensource.com>
	<1347621207-11294-14-git-send-email-stefano.stabellini@eu.citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1347621207-11294-14-git-send-email-stefano.stabellini@eu.citrix.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: xen-devel@lists.xensource.com, linaro-dev@lists.linaro.org,
	Ian.Campbell@citrix.com, arnd@arndb.de, catalin.marinas@arm.com,
	tim@xen.org, linux-kernel@vger.kernel.org,
	linux@arm.linux.org.uk, linux-arm-kernel@lists.infradead.org
Subject: Re: [Xen-devel] [PATCH v4 14/24] xen/arm: initialize grant_table on
	ARM
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Sep 14, 2012 at 12:13:16PM +0100, Stefano Stabellini wrote:
> Initialize the grant table mapping at the address specified at index 0
> in the DT under the /xen node.
> After the grant table is initialized, call xenbus_probe (if not dom0).

So we don't really care about the grant's size then? The DT xen.txt
talks about it..
> 
> Changes in v2:
> 
> - introduce GRANT_TABLE_PHYSADDR;
> - remove unneeded initialization of boot_max_nr_grant_frames.
> 
> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> ---
>  arch/arm/xen/enlighten.c |   14 ++++++++++++++
>  1 files changed, 14 insertions(+), 0 deletions(-)
> 
> diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
> index c2a47a7..036a4d8 100644
> --- a/arch/arm/xen/enlighten.c
> +++ b/arch/arm/xen/enlighten.c
> @@ -1,8 +1,12 @@
>  #include <xen/xen.h>
> +#include <xen/grant_table.h>
> +#include <xen/hvm.h>
>  #include <xen/interface/xen.h>
>  #include <xen/interface/memory.h>
> +#include <xen/interface/hvm/params.h>
>  #include <xen/features.h>
>  #include <xen/platform_pci.h>
> +#include <xen/xenbus.h>
>  #include <asm/xen/hypervisor.h>
>  #include <asm/xen/hypercall.h>
>  #include <linux/module.h>
> @@ -42,6 +46,7 @@ EXPORT_SYMBOL_GPL(xen_remap_domain_mfn_range);
>   * see Documentation/devicetree/bindings/arm/xen.txt for the
>   * documentation of the Xen Device Tree format.
>   */
> +#define GRANT_TABLE_PHYSADDR 0
>  static int __init xen_guest_init(void)
>  {
>  	struct xen_add_to_physmap xatp;
> @@ -51,6 +56,7 @@ static int __init xen_guest_init(void)
>  	const char *s = NULL;
>  	const char *version = NULL;
>  	const char *xen_prefix = "xen,xen-";
> +	struct resource res;
>  
>  	node = of_find_compatible_node(NULL, NULL, "xen,xen");
>  	if (!node) {
> @@ -65,6 +71,9 @@ static int __init xen_guest_init(void)
>  		pr_debug("Xen version not found\n");
>  		return 0;
>  	}
> +	if (of_address_to_resource(node, GRANT_TABLE_PHYSADDR, &res))
> +		return 0;
> +	xen_hvm_resume_frames = res.start >> PAGE_SHIFT;
>  	xen_domain_type = XEN_HVM_DOMAIN;
>  
>  	xen_setup_features();
> @@ -98,6 +107,11 @@ static int __init xen_guest_init(void)
>  	 * is required to use VCPUOP_register_vcpu_info to place vcpu info
>  	 * for secondary CPUs as they are brought up. */
>  	per_cpu(xen_vcpu, 0) = &HYPERVISOR_shared_info->vcpu_info[0];
> +
> +	gnttab_init();
> +	if (!xen_initial_domain())
> +		xenbus_probe(NULL);
> +
>  	return 0;
>  }
>  core_initcall(xen_guest_init);
> -- 
> 1.7.2.5

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 14 13:23:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 13:23: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 1TCVs4-0004pf-1Z; Fri, 14 Sep 2012 13:23: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 1TCVs2-0004pS-3m
	for xen-devel@lists.xensource.com; Fri, 14 Sep 2012 13:23:46 +0000
Received: from [85.158.138.51:21387] by server-3.bemta-3.messagelabs.com id
	FE/1B-21322-1EF23505; Fri, 14 Sep 2012 13:23:45 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1347629023!22632802!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDc1MTgyMQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18147 invoked from network); 14 Sep 2012 13:23:44 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-12.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 14 Sep 2012 13:23:44 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q8EDNNM9011518
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 14 Sep 2012 13:23: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
	q8EDNNRj019845
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 14 Sep 2012 13:23:23 GMT
Received: from abhmt102.oracle.com (abhmt102.oracle.com [141.146.116.54])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q8EDNMiH008351; Fri, 14 Sep 2012 08:23:22 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 14 Sep 2012 06:23:22 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 916274031C; Fri, 14 Sep 2012 09:12:42 -0400 (EDT)
Date: Fri, 14 Sep 2012 09:12:42 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>, axboe@kernel.dk
Message-ID: <20120914131242.GN25249@phenom.dumpdata.com>
References: <alpine.DEB.2.02.1209141145150.29232@kaball.uk.xensource.com>
	<1347621207-11294-19-git-send-email-stefano.stabellini@eu.citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1347621207-11294-19-git-send-email-stefano.stabellini@eu.citrix.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: xen-devel@lists.xensource.com, linaro-dev@lists.linaro.org,
	Ian.Campbell@citrix.com, arnd@arndb.de, catalin.marinas@arm.com,
	tim@xen.org, linux-kernel@vger.kernel.org,
	linux@arm.linux.org.uk, linux-arm-kernel@lists.infradead.org
Subject: Re: [Xen-devel] [PATCH v4 19/24] xen/arm: compile blkfront and
	blkback
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Sep 14, 2012 at 12:13:21PM +0100, Stefano Stabellini wrote:
> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

So this should go through Jen's tree or at least get his Ack.
But doing all of these patches seperatly is painfull - and remembering
where they go is a bit of logistical nightmare.

Jen, are you OK with this patch?
> ---
>  drivers/block/xen-blkback/blkback.c  |    1 +
>  include/xen/interface/io/protocols.h |    3 +++
>  2 files changed, 4 insertions(+), 0 deletions(-)
> 
> diff --git a/drivers/block/xen-blkback/blkback.c b/drivers/block/xen-blkback/blkback.c
> index 73f196c..63dd5b9 100644
> --- a/drivers/block/xen-blkback/blkback.c
> +++ b/drivers/block/xen-blkback/blkback.c
> @@ -42,6 +42,7 @@
>  
>  #include <xen/events.h>
>  #include <xen/page.h>
> +#include <xen/xen.h>
>  #include <asm/xen/hypervisor.h>
>  #include <asm/xen/hypercall.h>
>  #include "common.h"
> diff --git a/include/xen/interface/io/protocols.h b/include/xen/interface/io/protocols.h
> index 01fc8ae..0eafaf2 100644
> --- a/include/xen/interface/io/protocols.h
> +++ b/include/xen/interface/io/protocols.h
> @@ -5,6 +5,7 @@
>  #define XEN_IO_PROTO_ABI_X86_64     "x86_64-abi"
>  #define XEN_IO_PROTO_ABI_IA64       "ia64-abi"
>  #define XEN_IO_PROTO_ABI_POWERPC64  "powerpc64-abi"
> +#define XEN_IO_PROTO_ABI_ARM        "arm-abi"
>  
>  #if defined(__i386__)
>  # define XEN_IO_PROTO_ABI_NATIVE XEN_IO_PROTO_ABI_X86_32
> @@ -14,6 +15,8 @@
>  # define XEN_IO_PROTO_ABI_NATIVE XEN_IO_PROTO_ABI_IA64
>  #elif defined(__powerpc64__)
>  # define XEN_IO_PROTO_ABI_NATIVE XEN_IO_PROTO_ABI_POWERPC64
> +#elif defined(__arm__)
> +# define XEN_IO_PROTO_ABI_NATIVE XEN_IO_PROTO_ABI_ARM
>  #else
>  # error arch fixup needed here
>  #endif
> -- 
> 1.7.2.5

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 14 13:23:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 13:23: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 1TCVs4-0004pf-1Z; Fri, 14 Sep 2012 13:23: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 1TCVs2-0004pS-3m
	for xen-devel@lists.xensource.com; Fri, 14 Sep 2012 13:23:46 +0000
Received: from [85.158.138.51:21387] by server-3.bemta-3.messagelabs.com id
	FE/1B-21322-1EF23505; Fri, 14 Sep 2012 13:23:45 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1347629023!22632802!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDc1MTgyMQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18147 invoked from network); 14 Sep 2012 13:23:44 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-12.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 14 Sep 2012 13:23:44 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q8EDNNM9011518
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 14 Sep 2012 13:23: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
	q8EDNNRj019845
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 14 Sep 2012 13:23:23 GMT
Received: from abhmt102.oracle.com (abhmt102.oracle.com [141.146.116.54])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q8EDNMiH008351; Fri, 14 Sep 2012 08:23:22 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 14 Sep 2012 06:23:22 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 916274031C; Fri, 14 Sep 2012 09:12:42 -0400 (EDT)
Date: Fri, 14 Sep 2012 09:12:42 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>, axboe@kernel.dk
Message-ID: <20120914131242.GN25249@phenom.dumpdata.com>
References: <alpine.DEB.2.02.1209141145150.29232@kaball.uk.xensource.com>
	<1347621207-11294-19-git-send-email-stefano.stabellini@eu.citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1347621207-11294-19-git-send-email-stefano.stabellini@eu.citrix.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: xen-devel@lists.xensource.com, linaro-dev@lists.linaro.org,
	Ian.Campbell@citrix.com, arnd@arndb.de, catalin.marinas@arm.com,
	tim@xen.org, linux-kernel@vger.kernel.org,
	linux@arm.linux.org.uk, linux-arm-kernel@lists.infradead.org
Subject: Re: [Xen-devel] [PATCH v4 19/24] xen/arm: compile blkfront and
	blkback
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Sep 14, 2012 at 12:13:21PM +0100, Stefano Stabellini wrote:
> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

So this should go through Jen's tree or at least get his Ack.
But doing all of these patches seperatly is painfull - and remembering
where they go is a bit of logistical nightmare.

Jen, are you OK with this patch?
> ---
>  drivers/block/xen-blkback/blkback.c  |    1 +
>  include/xen/interface/io/protocols.h |    3 +++
>  2 files changed, 4 insertions(+), 0 deletions(-)
> 
> diff --git a/drivers/block/xen-blkback/blkback.c b/drivers/block/xen-blkback/blkback.c
> index 73f196c..63dd5b9 100644
> --- a/drivers/block/xen-blkback/blkback.c
> +++ b/drivers/block/xen-blkback/blkback.c
> @@ -42,6 +42,7 @@
>  
>  #include <xen/events.h>
>  #include <xen/page.h>
> +#include <xen/xen.h>
>  #include <asm/xen/hypervisor.h>
>  #include <asm/xen/hypercall.h>
>  #include "common.h"
> diff --git a/include/xen/interface/io/protocols.h b/include/xen/interface/io/protocols.h
> index 01fc8ae..0eafaf2 100644
> --- a/include/xen/interface/io/protocols.h
> +++ b/include/xen/interface/io/protocols.h
> @@ -5,6 +5,7 @@
>  #define XEN_IO_PROTO_ABI_X86_64     "x86_64-abi"
>  #define XEN_IO_PROTO_ABI_IA64       "ia64-abi"
>  #define XEN_IO_PROTO_ABI_POWERPC64  "powerpc64-abi"
> +#define XEN_IO_PROTO_ABI_ARM        "arm-abi"
>  
>  #if defined(__i386__)
>  # define XEN_IO_PROTO_ABI_NATIVE XEN_IO_PROTO_ABI_X86_32
> @@ -14,6 +15,8 @@
>  # define XEN_IO_PROTO_ABI_NATIVE XEN_IO_PROTO_ABI_IA64
>  #elif defined(__powerpc64__)
>  # define XEN_IO_PROTO_ABI_NATIVE XEN_IO_PROTO_ABI_POWERPC64
> +#elif defined(__arm__)
> +# define XEN_IO_PROTO_ABI_NATIVE XEN_IO_PROTO_ABI_ARM
>  #else
>  # error arch fixup needed here
>  #endif
> -- 
> 1.7.2.5

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 14 13:25:39 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 13: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 1TCVtL-0004ym-Gj; Fri, 14 Sep 2012 13:25:07 +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 1TCVtK-0004yH-4g
	for xen-devel@lists.xensource.com; Fri, 14 Sep 2012 13:25:06 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1347629098!9927419!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzQxNzU0\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7120 invoked from network); 14 Sep 2012 13:25:00 -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; 14 Sep 2012 13:25: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 q8EDOeXa017886
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 14 Sep 2012 13:24:41 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q8EDOc6b007346
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 14 Sep 2012 13:24:38 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
	q8EDOc2d008365; Fri, 14 Sep 2012 08:24:38 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 14 Sep 2012 06:24:37 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id AB4DF4031C; Fri, 14 Sep 2012 09:13:57 -0400 (EDT)
Date: Fri, 14 Sep 2012 09:13:57 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20120914131357.GO25249@phenom.dumpdata.com>
References: <alpine.DEB.2.02.1209141145150.29232@kaball.uk.xensource.com>
	<1347621207-11294-23-git-send-email-stefano.stabellini@eu.citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1347621207-11294-23-git-send-email-stefano.stabellini@eu.citrix.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, linaro-dev@lists.linaro.org,
	Ian.Campbell@citrix.com, arnd@arndb.de, catalin.marinas@arm.com,
	tim@xen.org, linux-kernel@vger.kernel.org,
	linux@arm.linux.org.uk, linux-arm-kernel@lists.infradead.org
Subject: Re: [Xen-devel] [PATCH v4 23/24] xen: update xen_add_to_physmap
	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 Fri, Sep 14, 2012 at 12:13:25PM +0100, Stefano Stabellini wrote:
> Update struct xen_add_to_physmap to be in sync with Xen's version of the
> structure.
> The size field was introduced by:
> 
> changeset:   24164:707d27fe03e7
> user:        Jean Guyader <jean.guyader@eu.citrix.com>
> date:        Fri Nov 18 13:42:08 2011 +0000
> summary:     mm: New XENMEM space, XENMAPSPACE_gmfn_range
> 
> According to the comment:
> 
> "This new field .size is located in the 16 bits padding between .domid
> and .space in struct xen_add_to_physmap to stay compatible with older
> versions."
> 
> Note: this patch should be already in Konrad's tree, it is here just for
> convenience.
> 
> Changes in v2:
> 
> - remove erroneous comment in the commit message.
> 
> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

.. and I already have this queued for 3.7.
> ---
>  include/xen/interface/memory.h |    3 +++
>  1 files changed, 3 insertions(+), 0 deletions(-)
> 
> diff --git a/include/xen/interface/memory.h b/include/xen/interface/memory.h
> index b5c3098..b66d04c 100644
> --- a/include/xen/interface/memory.h
> +++ b/include/xen/interface/memory.h
> @@ -163,6 +163,9 @@ struct xen_add_to_physmap {
>      /* Which domain to change the mapping for. */
>      domid_t domid;
>  
> +    /* Number of pages to go through for gmfn_range */
> +    uint16_t    size;
> +
>      /* Source mapping space. */
>  #define XENMAPSPACE_shared_info 0 /* shared info page */
>  #define XENMAPSPACE_grant_table 1 /* grant table page */
> -- 
> 1.7.2.5

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 14 13:25:39 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 13: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 1TCVtL-0004ym-Gj; Fri, 14 Sep 2012 13:25:07 +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 1TCVtK-0004yH-4g
	for xen-devel@lists.xensource.com; Fri, 14 Sep 2012 13:25:06 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1347629098!9927419!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzQxNzU0\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7120 invoked from network); 14 Sep 2012 13:25:00 -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; 14 Sep 2012 13:25: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 q8EDOeXa017886
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 14 Sep 2012 13:24:41 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q8EDOc6b007346
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 14 Sep 2012 13:24:38 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
	q8EDOc2d008365; Fri, 14 Sep 2012 08:24:38 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 14 Sep 2012 06:24:37 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id AB4DF4031C; Fri, 14 Sep 2012 09:13:57 -0400 (EDT)
Date: Fri, 14 Sep 2012 09:13:57 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20120914131357.GO25249@phenom.dumpdata.com>
References: <alpine.DEB.2.02.1209141145150.29232@kaball.uk.xensource.com>
	<1347621207-11294-23-git-send-email-stefano.stabellini@eu.citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1347621207-11294-23-git-send-email-stefano.stabellini@eu.citrix.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, linaro-dev@lists.linaro.org,
	Ian.Campbell@citrix.com, arnd@arndb.de, catalin.marinas@arm.com,
	tim@xen.org, linux-kernel@vger.kernel.org,
	linux@arm.linux.org.uk, linux-arm-kernel@lists.infradead.org
Subject: Re: [Xen-devel] [PATCH v4 23/24] xen: update xen_add_to_physmap
	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 Fri, Sep 14, 2012 at 12:13:25PM +0100, Stefano Stabellini wrote:
> Update struct xen_add_to_physmap to be in sync with Xen's version of the
> structure.
> The size field was introduced by:
> 
> changeset:   24164:707d27fe03e7
> user:        Jean Guyader <jean.guyader@eu.citrix.com>
> date:        Fri Nov 18 13:42:08 2011 +0000
> summary:     mm: New XENMEM space, XENMAPSPACE_gmfn_range
> 
> According to the comment:
> 
> "This new field .size is located in the 16 bits padding between .domid
> and .space in struct xen_add_to_physmap to stay compatible with older
> versions."
> 
> Note: this patch should be already in Konrad's tree, it is here just for
> convenience.
> 
> Changes in v2:
> 
> - remove erroneous comment in the commit message.
> 
> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

.. and I already have this queued for 3.7.
> ---
>  include/xen/interface/memory.h |    3 +++
>  1 files changed, 3 insertions(+), 0 deletions(-)
> 
> diff --git a/include/xen/interface/memory.h b/include/xen/interface/memory.h
> index b5c3098..b66d04c 100644
> --- a/include/xen/interface/memory.h
> +++ b/include/xen/interface/memory.h
> @@ -163,6 +163,9 @@ struct xen_add_to_physmap {
>      /* Which domain to change the mapping for. */
>      domid_t domid;
>  
> +    /* Number of pages to go through for gmfn_range */
> +    uint16_t    size;
> +
>      /* Source mapping space. */
>  #define XENMAPSPACE_shared_info 0 /* shared info page */
>  #define XENMAPSPACE_grant_table 1 /* grant table page */
> -- 
> 1.7.2.5

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 14 13:26:06 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 13:26: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 1TCVuA-00055b-4p; Fri, 14 Sep 2012 13:25:58 +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 1TCVu8-00055J-C3
	for xen-devel@lists.xensource.com; Fri, 14 Sep 2012 13:25:56 +0000
Received: from [85.158.139.211:14320] by server-6.bemta-5.messagelabs.com id
	09/1A-21336-36033505; Fri, 14 Sep 2012 13:25:55 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-11.tower-206.messagelabs.com!1347629153!18584380!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzQxNzU0\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16864 invoked from network); 14 Sep 2012 13:25:54 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-11.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 14 Sep 2012 13:25: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 q8EDPZpf018754
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 14 Sep 2012 13:25: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
	q8EDPYFQ011564
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 14 Sep 2012 13:25:35 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
	q8EDPYp7009870; Fri, 14 Sep 2012 08:25:34 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 14 Sep 2012 06:25:33 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id E23234031C; Fri, 14 Sep 2012 09:14:53 -0400 (EDT)
Date: Fri, 14 Sep 2012 09:14:53 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20120914131453.GP25249@phenom.dumpdata.com>
References: <alpine.DEB.2.02.1209141145150.29232@kaball.uk.xensource.com>
	<1347621207-11294-15-git-send-email-stefano.stabellini@eu.citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1347621207-11294-15-git-send-email-stefano.stabellini@eu.citrix.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: xen-devel@lists.xensource.com, linaro-dev@lists.linaro.org,
	Ian.Campbell@citrix.com, arnd@arndb.de, catalin.marinas@arm.com,
	tim@xen.org, linux-kernel@vger.kernel.org,
	linux@arm.linux.org.uk, linux-arm-kernel@lists.infradead.org
Subject: Re: [Xen-devel] [PATCH v4 15/24] xen/arm: receive Xen events on ARM
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Sep 14, 2012 at 12:13:17PM +0100, Stefano Stabellini wrote:
> Compile events.c on ARM.
> Parse, map and enable the IRQ to get event notifications from the device
> tree (node "/xen").
> 
> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

> ---
>  arch/arm/include/asm/xen/events.h |   18 ++++++++++++++++++
>  arch/arm/xen/enlighten.c          |   33 +++++++++++++++++++++++++++++++++
>  arch/x86/xen/enlighten.c          |    1 +
>  arch/x86/xen/irq.c                |    1 +
>  arch/x86/xen/xen-ops.h            |    1 -
>  drivers/xen/events.c              |   17 ++++++++++++++---
>  include/xen/events.h              |    2 ++
>  7 files changed, 69 insertions(+), 4 deletions(-)
>  create mode 100644 arch/arm/include/asm/xen/events.h
> 
> diff --git a/arch/arm/include/asm/xen/events.h b/arch/arm/include/asm/xen/events.h
> new file mode 100644
> index 0000000..94b4e90
> --- /dev/null
> +++ b/arch/arm/include/asm/xen/events.h
> @@ -0,0 +1,18 @@
> +#ifndef _ASM_ARM_XEN_EVENTS_H
> +#define _ASM_ARM_XEN_EVENTS_H
> +
> +#include <asm/ptrace.h>
> +
> +enum ipi_vector {
> +	XEN_PLACEHOLDER_VECTOR,
> +
> +	/* Xen IPIs go here */
> +	XEN_NR_IPIS,
> +};
> +
> +static inline int xen_irqs_disabled(struct pt_regs *regs)
> +{
> +	return raw_irqs_disabled_flags(regs->ARM_cpsr);
> +}
> +
> +#endif /* _ASM_ARM_XEN_EVENTS_H */
> diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
> index 036a4d8..bad67ad 100644
> --- a/arch/arm/xen/enlighten.c
> +++ b/arch/arm/xen/enlighten.c
> @@ -1,4 +1,5 @@
>  #include <xen/xen.h>
> +#include <xen/events.h>
>  #include <xen/grant_table.h>
>  #include <xen/hvm.h>
>  #include <xen/interface/xen.h>
> @@ -9,6 +10,8 @@
>  #include <xen/xenbus.h>
>  #include <asm/xen/hypervisor.h>
>  #include <asm/xen/hypercall.h>
> +#include <linux/interrupt.h>
> +#include <linux/irqreturn.h>
>  #include <linux/module.h>
>  #include <linux/of.h>
>  #include <linux/of_irq.h>
> @@ -33,6 +36,8 @@ EXPORT_SYMBOL_GPL(xen_have_vector_callback);
>  int xen_platform_pci_unplug = XEN_UNPLUG_ALL;
>  EXPORT_SYMBOL_GPL(xen_platform_pci_unplug);
>  
> +static __read_mostly int xen_events_irq = -1;
> +
>  int xen_remap_domain_mfn_range(struct vm_area_struct *vma,
>  			       unsigned long addr,
>  			       unsigned long mfn, int nr,
> @@ -74,6 +79,9 @@ static int __init xen_guest_init(void)
>  	if (of_address_to_resource(node, GRANT_TABLE_PHYSADDR, &res))
>  		return 0;
>  	xen_hvm_resume_frames = res.start >> PAGE_SHIFT;
> +	xen_events_irq = irq_of_parse_and_map(node, 0);
> +	pr_info("Xen %s support found, events_irq=%d gnttab_frame_pfn=%lx\n",
> +			version, xen_events_irq, xen_hvm_resume_frames);
>  	xen_domain_type = XEN_HVM_DOMAIN;
>  
>  	xen_setup_features();
> @@ -115,3 +123,28 @@ static int __init xen_guest_init(void)
>  	return 0;
>  }
>  core_initcall(xen_guest_init);
> +
> +static irqreturn_t xen_arm_callback(int irq, void *arg)
> +{
> +	xen_hvm_evtchn_do_upcall();
> +	return IRQ_HANDLED;
> +}
> +
> +static int __init xen_init_events(void)
> +{
> +	if (!xen_domain() || xen_events_irq < 0)
> +		return -ENODEV;
> +
> +	xen_init_IRQ();
> +
> +	if (request_percpu_irq(xen_events_irq, xen_arm_callback,
> +			"events", xen_vcpu)) {
> +		pr_err("Error requesting IRQ %d\n", xen_events_irq);
> +		return -EINVAL;
> +	}
> +
> +	enable_percpu_irq(xen_events_irq, 0);
> +
> +	return 0;
> +}
> +postcore_initcall(xen_init_events);
> diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
> index 9642d4a..3f8263e 100644
> --- a/arch/x86/xen/enlighten.c
> +++ b/arch/x86/xen/enlighten.c
> @@ -33,6 +33,7 @@
>  #include <linux/memblock.h>
>  
>  #include <xen/xen.h>
> +#include <xen/events.h>
>  #include <xen/interface/xen.h>
>  #include <xen/interface/version.h>
>  #include <xen/interface/physdev.h>
> diff --git a/arch/x86/xen/irq.c b/arch/x86/xen/irq.c
> index 1573376..01a4dc0 100644
> --- a/arch/x86/xen/irq.c
> +++ b/arch/x86/xen/irq.c
> @@ -5,6 +5,7 @@
>  #include <xen/interface/xen.h>
>  #include <xen/interface/sched.h>
>  #include <xen/interface/vcpu.h>
> +#include <xen/events.h>
>  
>  #include <asm/xen/hypercall.h>
>  #include <asm/xen/hypervisor.h>
> diff --git a/arch/x86/xen/xen-ops.h b/arch/x86/xen/xen-ops.h
> index 202d4c1..2368295 100644
> --- a/arch/x86/xen/xen-ops.h
> +++ b/arch/x86/xen/xen-ops.h
> @@ -35,7 +35,6 @@ void xen_set_pat(u64);
>  
>  char * __init xen_memory_setup(void);
>  void __init xen_arch_setup(void);
> -void __init xen_init_IRQ(void);
>  void xen_enable_sysenter(void);
>  void xen_enable_syscall(void);
>  void xen_vcpu_restore(void);
> diff --git a/drivers/xen/events.c b/drivers/xen/events.c
> index 7595581..5ecb596 100644
> --- a/drivers/xen/events.c
> +++ b/drivers/xen/events.c
> @@ -31,14 +31,16 @@
>  #include <linux/irqnr.h>
>  #include <linux/pci.h>
>  
> +#ifdef CONFIG_X86
>  #include <asm/desc.h>
>  #include <asm/ptrace.h>
>  #include <asm/irq.h>
>  #include <asm/idle.h>
>  #include <asm/io_apic.h>
> -#include <asm/sync_bitops.h>
>  #include <asm/xen/page.h>
>  #include <asm/xen/pci.h>
> +#endif
> +#include <asm/sync_bitops.h>
>  #include <asm/xen/hypercall.h>
>  #include <asm/xen/hypervisor.h>
>  
> @@ -50,6 +52,9 @@
>  #include <xen/interface/event_channel.h>
>  #include <xen/interface/hvm/hvm_op.h>
>  #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
> @@ -1374,7 +1379,9 @@ void xen_evtchn_do_upcall(struct pt_regs *regs)
>  {
>  	struct pt_regs *old_regs = set_irq_regs(regs);
>  
> +#ifdef CONFIG_X86
>  	exit_idle();
> +#endif
>  	irq_enter();
>  
>  	__xen_evtchn_do_upcall();
> @@ -1783,9 +1790,9 @@ void xen_callback_vector(void)
>  void xen_callback_vector(void) {}
>  #endif
>  
> -void __init xen_init_IRQ(void)
> +void xen_init_IRQ(void)
>  {
> -	int i, rc;
> +	int i;
>  
>  	evtchn_to_irq = kcalloc(NR_EVENT_CHANNELS, sizeof(*evtchn_to_irq),
>  				    GFP_KERNEL);
> @@ -1801,6 +1808,7 @@ void __init xen_init_IRQ(void)
>  
>  	pirq_needs_eoi = pirq_needs_eoi_flag;
>  
> +#ifdef CONFIG_X86
>  	if (xen_hvm_domain()) {
>  		xen_callback_vector();
>  		native_init_IRQ();
> @@ -1808,6 +1816,7 @@ void __init xen_init_IRQ(void)
>  		 * __acpi_register_gsi can point at the right function */
>  		pci_xen_hvm_init();
>  	} else {
> +		int rc;
>  		struct physdev_pirq_eoi_gmfn eoi_gmfn;
>  
>  		irq_ctx_init(smp_processor_id());
> @@ -1823,4 +1832,6 @@ void __init xen_init_IRQ(void)
>  		} else
>  			pirq_needs_eoi = pirq_check_eoi_map;
>  	}
> +#endif
>  }
> +EXPORT_SYMBOL_GPL(xen_init_IRQ);
> diff --git a/include/xen/events.h b/include/xen/events.h
> index 04399b2..c6bfe01 100644
> --- a/include/xen/events.h
> +++ b/include/xen/events.h
> @@ -109,4 +109,6 @@ int xen_irq_from_gsi(unsigned gsi);
>  /* Determine whether to ignore this IRQ if it is passed to a guest. */
>  int xen_test_irq_shared(int irq);
>  
> +/* initialize Xen IRQ subsystem */
> +void xen_init_IRQ(void);
>  #endif	/* _XEN_EVENTS_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 Sep 14 13:26:06 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 13:26: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 1TCVuA-00055b-4p; Fri, 14 Sep 2012 13:25:58 +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 1TCVu8-00055J-C3
	for xen-devel@lists.xensource.com; Fri, 14 Sep 2012 13:25:56 +0000
Received: from [85.158.139.211:14320] by server-6.bemta-5.messagelabs.com id
	09/1A-21336-36033505; Fri, 14 Sep 2012 13:25:55 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-11.tower-206.messagelabs.com!1347629153!18584380!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzQxNzU0\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16864 invoked from network); 14 Sep 2012 13:25:54 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-11.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 14 Sep 2012 13:25: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 q8EDPZpf018754
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 14 Sep 2012 13:25: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
	q8EDPYFQ011564
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 14 Sep 2012 13:25:35 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
	q8EDPYp7009870; Fri, 14 Sep 2012 08:25:34 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 14 Sep 2012 06:25:33 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id E23234031C; Fri, 14 Sep 2012 09:14:53 -0400 (EDT)
Date: Fri, 14 Sep 2012 09:14:53 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20120914131453.GP25249@phenom.dumpdata.com>
References: <alpine.DEB.2.02.1209141145150.29232@kaball.uk.xensource.com>
	<1347621207-11294-15-git-send-email-stefano.stabellini@eu.citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1347621207-11294-15-git-send-email-stefano.stabellini@eu.citrix.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: xen-devel@lists.xensource.com, linaro-dev@lists.linaro.org,
	Ian.Campbell@citrix.com, arnd@arndb.de, catalin.marinas@arm.com,
	tim@xen.org, linux-kernel@vger.kernel.org,
	linux@arm.linux.org.uk, linux-arm-kernel@lists.infradead.org
Subject: Re: [Xen-devel] [PATCH v4 15/24] xen/arm: receive Xen events on ARM
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Sep 14, 2012 at 12:13:17PM +0100, Stefano Stabellini wrote:
> Compile events.c on ARM.
> Parse, map and enable the IRQ to get event notifications from the device
> tree (node "/xen").
> 
> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

> ---
>  arch/arm/include/asm/xen/events.h |   18 ++++++++++++++++++
>  arch/arm/xen/enlighten.c          |   33 +++++++++++++++++++++++++++++++++
>  arch/x86/xen/enlighten.c          |    1 +
>  arch/x86/xen/irq.c                |    1 +
>  arch/x86/xen/xen-ops.h            |    1 -
>  drivers/xen/events.c              |   17 ++++++++++++++---
>  include/xen/events.h              |    2 ++
>  7 files changed, 69 insertions(+), 4 deletions(-)
>  create mode 100644 arch/arm/include/asm/xen/events.h
> 
> diff --git a/arch/arm/include/asm/xen/events.h b/arch/arm/include/asm/xen/events.h
> new file mode 100644
> index 0000000..94b4e90
> --- /dev/null
> +++ b/arch/arm/include/asm/xen/events.h
> @@ -0,0 +1,18 @@
> +#ifndef _ASM_ARM_XEN_EVENTS_H
> +#define _ASM_ARM_XEN_EVENTS_H
> +
> +#include <asm/ptrace.h>
> +
> +enum ipi_vector {
> +	XEN_PLACEHOLDER_VECTOR,
> +
> +	/* Xen IPIs go here */
> +	XEN_NR_IPIS,
> +};
> +
> +static inline int xen_irqs_disabled(struct pt_regs *regs)
> +{
> +	return raw_irqs_disabled_flags(regs->ARM_cpsr);
> +}
> +
> +#endif /* _ASM_ARM_XEN_EVENTS_H */
> diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
> index 036a4d8..bad67ad 100644
> --- a/arch/arm/xen/enlighten.c
> +++ b/arch/arm/xen/enlighten.c
> @@ -1,4 +1,5 @@
>  #include <xen/xen.h>
> +#include <xen/events.h>
>  #include <xen/grant_table.h>
>  #include <xen/hvm.h>
>  #include <xen/interface/xen.h>
> @@ -9,6 +10,8 @@
>  #include <xen/xenbus.h>
>  #include <asm/xen/hypervisor.h>
>  #include <asm/xen/hypercall.h>
> +#include <linux/interrupt.h>
> +#include <linux/irqreturn.h>
>  #include <linux/module.h>
>  #include <linux/of.h>
>  #include <linux/of_irq.h>
> @@ -33,6 +36,8 @@ EXPORT_SYMBOL_GPL(xen_have_vector_callback);
>  int xen_platform_pci_unplug = XEN_UNPLUG_ALL;
>  EXPORT_SYMBOL_GPL(xen_platform_pci_unplug);
>  
> +static __read_mostly int xen_events_irq = -1;
> +
>  int xen_remap_domain_mfn_range(struct vm_area_struct *vma,
>  			       unsigned long addr,
>  			       unsigned long mfn, int nr,
> @@ -74,6 +79,9 @@ static int __init xen_guest_init(void)
>  	if (of_address_to_resource(node, GRANT_TABLE_PHYSADDR, &res))
>  		return 0;
>  	xen_hvm_resume_frames = res.start >> PAGE_SHIFT;
> +	xen_events_irq = irq_of_parse_and_map(node, 0);
> +	pr_info("Xen %s support found, events_irq=%d gnttab_frame_pfn=%lx\n",
> +			version, xen_events_irq, xen_hvm_resume_frames);
>  	xen_domain_type = XEN_HVM_DOMAIN;
>  
>  	xen_setup_features();
> @@ -115,3 +123,28 @@ static int __init xen_guest_init(void)
>  	return 0;
>  }
>  core_initcall(xen_guest_init);
> +
> +static irqreturn_t xen_arm_callback(int irq, void *arg)
> +{
> +	xen_hvm_evtchn_do_upcall();
> +	return IRQ_HANDLED;
> +}
> +
> +static int __init xen_init_events(void)
> +{
> +	if (!xen_domain() || xen_events_irq < 0)
> +		return -ENODEV;
> +
> +	xen_init_IRQ();
> +
> +	if (request_percpu_irq(xen_events_irq, xen_arm_callback,
> +			"events", xen_vcpu)) {
> +		pr_err("Error requesting IRQ %d\n", xen_events_irq);
> +		return -EINVAL;
> +	}
> +
> +	enable_percpu_irq(xen_events_irq, 0);
> +
> +	return 0;
> +}
> +postcore_initcall(xen_init_events);
> diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
> index 9642d4a..3f8263e 100644
> --- a/arch/x86/xen/enlighten.c
> +++ b/arch/x86/xen/enlighten.c
> @@ -33,6 +33,7 @@
>  #include <linux/memblock.h>
>  
>  #include <xen/xen.h>
> +#include <xen/events.h>
>  #include <xen/interface/xen.h>
>  #include <xen/interface/version.h>
>  #include <xen/interface/physdev.h>
> diff --git a/arch/x86/xen/irq.c b/arch/x86/xen/irq.c
> index 1573376..01a4dc0 100644
> --- a/arch/x86/xen/irq.c
> +++ b/arch/x86/xen/irq.c
> @@ -5,6 +5,7 @@
>  #include <xen/interface/xen.h>
>  #include <xen/interface/sched.h>
>  #include <xen/interface/vcpu.h>
> +#include <xen/events.h>
>  
>  #include <asm/xen/hypercall.h>
>  #include <asm/xen/hypervisor.h>
> diff --git a/arch/x86/xen/xen-ops.h b/arch/x86/xen/xen-ops.h
> index 202d4c1..2368295 100644
> --- a/arch/x86/xen/xen-ops.h
> +++ b/arch/x86/xen/xen-ops.h
> @@ -35,7 +35,6 @@ void xen_set_pat(u64);
>  
>  char * __init xen_memory_setup(void);
>  void __init xen_arch_setup(void);
> -void __init xen_init_IRQ(void);
>  void xen_enable_sysenter(void);
>  void xen_enable_syscall(void);
>  void xen_vcpu_restore(void);
> diff --git a/drivers/xen/events.c b/drivers/xen/events.c
> index 7595581..5ecb596 100644
> --- a/drivers/xen/events.c
> +++ b/drivers/xen/events.c
> @@ -31,14 +31,16 @@
>  #include <linux/irqnr.h>
>  #include <linux/pci.h>
>  
> +#ifdef CONFIG_X86
>  #include <asm/desc.h>
>  #include <asm/ptrace.h>
>  #include <asm/irq.h>
>  #include <asm/idle.h>
>  #include <asm/io_apic.h>
> -#include <asm/sync_bitops.h>
>  #include <asm/xen/page.h>
>  #include <asm/xen/pci.h>
> +#endif
> +#include <asm/sync_bitops.h>
>  #include <asm/xen/hypercall.h>
>  #include <asm/xen/hypervisor.h>
>  
> @@ -50,6 +52,9 @@
>  #include <xen/interface/event_channel.h>
>  #include <xen/interface/hvm/hvm_op.h>
>  #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
> @@ -1374,7 +1379,9 @@ void xen_evtchn_do_upcall(struct pt_regs *regs)
>  {
>  	struct pt_regs *old_regs = set_irq_regs(regs);
>  
> +#ifdef CONFIG_X86
>  	exit_idle();
> +#endif
>  	irq_enter();
>  
>  	__xen_evtchn_do_upcall();
> @@ -1783,9 +1790,9 @@ void xen_callback_vector(void)
>  void xen_callback_vector(void) {}
>  #endif
>  
> -void __init xen_init_IRQ(void)
> +void xen_init_IRQ(void)
>  {
> -	int i, rc;
> +	int i;
>  
>  	evtchn_to_irq = kcalloc(NR_EVENT_CHANNELS, sizeof(*evtchn_to_irq),
>  				    GFP_KERNEL);
> @@ -1801,6 +1808,7 @@ void __init xen_init_IRQ(void)
>  
>  	pirq_needs_eoi = pirq_needs_eoi_flag;
>  
> +#ifdef CONFIG_X86
>  	if (xen_hvm_domain()) {
>  		xen_callback_vector();
>  		native_init_IRQ();
> @@ -1808,6 +1816,7 @@ void __init xen_init_IRQ(void)
>  		 * __acpi_register_gsi can point at the right function */
>  		pci_xen_hvm_init();
>  	} else {
> +		int rc;
>  		struct physdev_pirq_eoi_gmfn eoi_gmfn;
>  
>  		irq_ctx_init(smp_processor_id());
> @@ -1823,4 +1832,6 @@ void __init xen_init_IRQ(void)
>  		} else
>  			pirq_needs_eoi = pirq_check_eoi_map;
>  	}
> +#endif
>  }
> +EXPORT_SYMBOL_GPL(xen_init_IRQ);
> diff --git a/include/xen/events.h b/include/xen/events.h
> index 04399b2..c6bfe01 100644
> --- a/include/xen/events.h
> +++ b/include/xen/events.h
> @@ -109,4 +109,6 @@ int xen_irq_from_gsi(unsigned gsi);
>  /* Determine whether to ignore this IRQ if it is passed to a guest. */
>  int xen_test_irq_shared(int irq);
>  
> +/* initialize Xen IRQ subsystem */
> +void xen_init_IRQ(void);
>  #endif	/* _XEN_EVENTS_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 Sep 14 13:32:28 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 13:32:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TCW0F-0005UG-KF; Fri, 14 Sep 2012 13:32:15 +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 1TCW0E-0005U5-3J
	for xen-devel@lists.xensource.com; Fri, 14 Sep 2012 13:32:14 +0000
Received: from [85.158.143.35:53060] by server-2.bemta-4.messagelabs.com id
	AD/9B-21239-DD133505; Fri, 14 Sep 2012 13:32:13 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1347629531!10169802!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDc1MTgyMQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29259 invoked from network); 14 Sep 2012 13:32:12 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-10.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 14 Sep 2012 13:32: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 q8EDVpg0020204
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 14 Sep 2012 13:31: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
	q8EDVnfi022374
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 14 Sep 2012 13:31:49 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
	q8EDVmwk010038; Fri, 14 Sep 2012 08:31:48 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 14 Sep 2012 06:31:48 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 93C014031C; Fri, 14 Sep 2012 09:21:08 -0400 (EDT)
Date: Fri, 14 Sep 2012 09:21:08 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	linux@arm.linux.org.uk
Message-ID: <20120914132108.GQ25249@phenom.dumpdata.com>
References: <alpine.DEB.2.02.1209141145150.29232@kaball.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <alpine.DEB.2.02.1209141145150.29232@kaball.uk.xensource.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linaro-dev@lists.linaro.org" <linaro-dev@lists.linaro.org>,
	Ian Campbell <Ian.Campbell@citrix.com>, "arnd@arndb.de" <arnd@arndb.de>,
	"catalin.marinas@arm.com" <catalin.marinas@arm.com>,
	"Tim \(Xen.org\)" <tim@xen.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Russell King - ARM Linux <linux@arm.linux.org.uk>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Xen-devel] [PATCH v4 00/24] Introduce Xen support on ARM
	(based on 3.6-rc5)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Sep 14, 2012 at 12:12:59PM +0100, Stefano Stabellini wrote:
> Hi all,
> this patch series implements Xen support for ARMv7 with virtualization
> extensions.  It allows a Linux guest to boot as dom0 and
> as domU on Xen on ARM. PV console, disk and network frontends and
> backends are all working correctly.
> 
> It has been tested on a Versatile Express Cortex A15 emulator, using the
> latest Xen ARM developement branch
> (git://xenbits.xen.org/people/ianc/xen-unstable.git arm-for-4.3) plus
> the "ARM hypercall ABI: 64 bit ready" patch series
> (http://marc.info/?l=xen-devel&m=134426267205408), and a simple ad-hoc
> tool to build guest domains (marc.info/?l=xen-devel&m=134089788016546).
> 
> The patch marked with [HACK] has been dropped from this series, however
> you can find it here:
> http://marc.info/?l=linux-kernel&m=134513277823527&w=2.
> 
> I am also attaching to this email the dts'es that I am currently using
> for dom0 and domU: vexpress-v2p-ca15-tc1.dts (that includes
> vexpress-v2m-rs1-rtsm.dtsi) is the dts used for dom0 and it is passed to
> Linux by Xen, while vexpress-virt.dts is the dts used for other domUs
> and it is appended in binary form to the guest kernel image. I am not
> sure where they are supposed to live yet, so I am just attaching them
> here so that people can actually try out this series if they want to.
> 
> Comments are very welcome!

I already put in these

1)      xen/events: fix unmask_evtchn for PV on HVM guests
2)      xen: missing includes
3)      xen: update xen_add_to_physmap interface
4)      xen: Introduce xen_pfn_t for pfn and mfn types
5)      xen: clear IRQ_NOAUTOEN and IRQ_NOREQUEST
6)      xen: allow privcmd for HVM guests

in my tree as they also impact/help the PVH domains which works for
x86 (Well, not all of them). They are in my stable/for-linus-3.7 git tree
(git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git)
and also in #linux-next.


If it would make reviewing easier, I would recommend you rebase
your tree on top of the stable/for-linus-3.7 and just post them
as it would make the number of patches smaller.

Or alternatively, if the ARM maintainer wishes - just give you
the OK and we can figure out how/who is going to do the git-fu.

> 
> 
> 
> Patch #21 "arm/v2m: initialize arch_timers even if v2m_timer is not
> present" touches generic ARM code and still needs to be acked/reviewed.
> 
> Arnd, Russell, what do you think about this series? If you are OK with
> it, to whom should I submit it?
> 
> 
> 
> Changes in v4:
> - rebase on 3.6-rc5;
> - devicetree: "xen,xen" should be last as it is less specific;
> - devicetree: use 2 address-cells and 2 size-cells in the reg property;
> - do not xs_reset_watches on dom0;
> - compile drivers/xen/pcpu.c only on x86;
> - use "+=" instead of ":=" for dom0- targets;
> - add a patch to update the MAINTAINERS file.
> 
> 
> Changes in v3:
> - move patches that have been picked up by Konrad at the end of the
>   series;
> - improve comments;
> - add a doc to describe the Xen Device Tree format;
> - do not use xen_ulong_t for multicalls and apic_physbase;
> - add a patch at the end of the series to use the new __HVC macro;
> - add missing pvclock-abi.h include to ia64 header files;
> - do not use an anonymous union in struct xen_add_to_physmap.
> 
> 
> Changes in v2:
> - fix up many comments and commit messages;
> - remove the early_printk patches: rely on the emulated serial for now;
> - remove the xen_guest_init patch: without any PV early_printk, we don't
>   need any early call to xen_guest_init, we can rely on core_initcall
>   alone;
> - define an HYPERCALL macro for 5 arguments hypercall wrappers, even if
>   at the moment is unused;
> - use ldm instead of pop in the hypercall wrappers;
> - return -ENOSYS rather than -1 from the unimplemented grant_table
>   functions;
> - remove the pvclock ifdef in the Xen headers;
> - remove include linux/types.h from xen/interface/xen.h;
> - replace pr_info with pr_debug in xen_guest_init;
> - add a new patch to introduce xen_ulong_t and use it top replace all
>   the occurences of unsigned long in the public Xen interface;
> - explicitely size all the pointers to 64 bit on ARM, so that the
>   hypercall ABI is "64 bit ready";
> - clean up xenbus_init;
> - make pci.o depend on CONFIG_PCI and acpi.o depend on CONFIG_ACPI;
> - mark Xen guest support on ARM as EXPERIMENTAL;
> - introduce GRANT_TABLE_PHYSADDR;
> - remove unneeded initialization of boot_max_nr_grant_frames;
> - add a new patch to clear IRQ_NOAUTOEN and IRQ_NOREQUEST in events.c;
> - return -EINVAL from xen_remap_domain_mfn_range if
>   auto_translated_physmap;
> - retain binary compatibility in xen_add_to_physmap: use a union to
>   introduce foreign_domid.
> 
> 
> Shortlog and diffstat:
> 
> Stefano Stabellini (24):
>       arm: initial Xen support
>       xen/arm: hypercalls
>       xen/arm: page.h definitions
>       xen/arm: sync_bitops
>       xen/arm: empty implementation of grant_table arch specific functions
>       docs: Xen ARM DT bindings
>       xen/arm: Xen detection and shared_info page mapping
>       xen/arm: Introduce xen_pfn_t for pfn and mfn types
>       xen/arm: Introduce xen_ulong_t for unsigned long
>       xen/arm: compile and run xenbus
>       xen: do not compile manage, balloon, pci, acpi, pcpu and cpu_hotplug on ARM
>       xen/arm: introduce CONFIG_XEN on ARM
>       xen/arm: get privilege status
>       xen/arm: initialize grant_table on ARM
>       xen/arm: receive Xen events on ARM
>       xen: clear IRQ_NOAUTOEN and IRQ_NOREQUEST
>       xen/arm: implement alloc/free_xenballooned_pages with alloc_pages/kfree
>       xen: allow privcmd for HVM guests
>       xen/arm: compile blkfront and blkback
>       xen/arm: compile netback
>       arm/v2m: initialize arch_timers even if v2m_timer is not present
>       xen: missing includes
>       xen: update xen_add_to_physmap interface
>       MAINTAINERS: add myself as Xen ARM maintainer
> 
>  Documentation/devicetree/bindings/arm/xen.txt |   22 ++++
>  MAINTAINERS                                   |    7 +
>  arch/arm/Kconfig                              |   10 ++
>  arch/arm/Makefile                             |    1 +
>  arch/arm/include/asm/hypervisor.h             |    6 +
>  arch/arm/include/asm/sync_bitops.h            |   27 ++++
>  arch/arm/include/asm/xen/events.h             |   18 +++
>  arch/arm/include/asm/xen/hypercall.h          |   69 ++++++++++
>  arch/arm/include/asm/xen/hypervisor.h         |   19 +++
>  arch/arm/include/asm/xen/interface.h          |   73 +++++++++++
>  arch/arm/include/asm/xen/page.h               |   82 ++++++++++++
>  arch/arm/mach-vexpress/v2m.c                  |   11 +-
>  arch/arm/xen/Makefile                         |    1 +
>  arch/arm/xen/enlighten.c                      |  168 +++++++++++++++++++++++++
>  arch/arm/xen/grant-table.c                    |   53 ++++++++
>  arch/arm/xen/hypercall.S                      |  106 ++++++++++++++++
>  arch/ia64/include/asm/xen/interface.h         |    8 +-
>  arch/x86/include/asm/xen/interface.h          |    8 ++
>  arch/x86/xen/enlighten.c                      |    1 +
>  arch/x86/xen/irq.c                            |    1 +
>  arch/x86/xen/mmu.c                            |    3 +
>  arch/x86/xen/xen-ops.h                        |    1 -
>  drivers/block/xen-blkback/blkback.c           |    1 +
>  drivers/net/xen-netback/netback.c             |    1 +
>  drivers/net/xen-netfront.c                    |    1 +
>  drivers/tty/hvc/hvc_xen.c                     |    2 +
>  drivers/xen/Makefile                          |   13 ++-
>  drivers/xen/events.c                          |   18 +++-
>  drivers/xen/grant-table.c                     |    1 +
>  drivers/xen/privcmd.c                         |    4 -
>  drivers/xen/xenbus/xenbus_comms.c             |    2 +-
>  drivers/xen/xenbus/xenbus_probe.c             |   62 +++++++---
>  drivers/xen/xenbus/xenbus_probe_frontend.c    |    1 +
>  drivers/xen/xenbus/xenbus_xs.c                |    3 +-
>  include/xen/events.h                          |    2 +
>  include/xen/interface/features.h              |    3 +
>  include/xen/interface/grant_table.h           |    4 +-
>  include/xen/interface/io/protocols.h          |    3 +
>  include/xen/interface/memory.h                |   21 ++--
>  include/xen/interface/physdev.h               |    2 +-
>  include/xen/interface/platform.h              |    4 +-
>  include/xen/interface/version.h               |    2 +-
>  include/xen/interface/xen.h                   |    7 +-
>  include/xen/privcmd.h                         |    3 +-
>  include/xen/xen.h                             |    2 +-
>  45 files changed, 796 insertions(+), 61 deletions(-)
> 
> 
> 
> A branch based on 3.6-rc5 is available here:
> 
> git://xenbits.xen.org/people/sstabellini/linux-pvhvm.git 3.6-rc5-arm-4
> 
> 
> Cheers,
> 
> Stefano

> /*
>  * ARM Ltd. Versatile Express
>  *
>  * Motherboard Express uATX
>  * V2M-P1
>  *
>  * HBI-0190D
>  *
>  * RS1 memory map ("ARM Cortex-A Series memory map" in the board's
>  * Technical Reference Manual)
>  *
>  * WARNING! The hardware described in this file is independent from the
>  * original variant (vexpress-v2m.dtsi), but there is a strong
>  * correspondence between the two configurations.
>  *
>  * TAKE CARE WHEN MAINTAINING THIS FILE TO PROPAGATE ANY RELEVANT
>  * CHANGES TO vexpress-v2m.dtsi!
>  */
> 
> / {
> 	aliases {
> 		arm,v2m_timer = &v2m_timer01;
> 	};
> 
> 	motherboard {
> 		compatible = "simple-bus";
> 		arm,v2m-memory-map = "rs1";
> 		#address-cells = <2>; /* SMB chipselect number and offset */
> 		#size-cells = <1>;
> 		#interrupt-cells = <1>;
> 
> 		flash@0,00000000 {
> 			compatible = "arm,vexpress-flash", "cfi-flash";
> 			reg = <0 0x00000000 0x04000000>,
> 			      <4 0x00000000 0x04000000>;
> 			bank-width = <4>;
> 		};
> 
> 		psram@1,00000000 {
> 			compatible = "arm,vexpress-psram", "mtd-ram";
> 			reg = <1 0x00000000 0x02000000>;
> 			bank-width = <4>;
> 		};
> 
> 		vram@2,00000000 {
> 			compatible = "arm,vexpress-vram";
> 			reg = <2 0x00000000 0x00800000>;
> 		};
> 
> 		ethernet@2,02000000 {
> 			compatible = "smsc,lan91c111";
> 			reg = <2 0x02000000 0x10000>;
> 			interrupts = <15>;
> 		};
> 
> 		usb@2,03000000 {
> 			compatible = "nxp,usb-isp1761";
> 			reg = <2 0x03000000 0x20000>;
> 			interrupts = <16>;
> 			port1-otg;
> 		};
> 
> 		iofpga@3,00000000 {
> 			compatible = "arm,amba-bus", "simple-bus";
> 			#address-cells = <1>;
> 			#size-cells = <1>;
> 			ranges = <0 3 0 0x200000>;
> 
> 			sysreg@010000 {
> 				compatible = "arm,vexpress-sysreg";
> 				reg = <0x010000 0x1000>;
> 			};
> 
> 			sysctl@020000 {
> 				compatible = "arm,sp810", "arm,primecell";
> 				reg = <0x020000 0x1000>;
> 			};
> 
> 			/* PCI-E I2C bus */
> 			v2m_i2c_pcie: i2c@030000 {
> 				compatible = "arm,versatile-i2c";
> 				reg = <0x030000 0x1000>;
> 
> 				#address-cells = <1>;
> 				#size-cells = <0>;
> 
> 				pcie-switch@60 {
> 					compatible = "idt,89hpes32h8";
> 					reg = <0x60>;
> 				};
> 			};
> 
> 			aaci@040000 {
> 				compatible = "arm,pl041", "arm,primecell";
> 				reg = <0x040000 0x1000>;
> 				interrupts = <11>;
> 			};
> 
> 			mmci@050000 {
> 				compatible = "arm,pl180", "arm,primecell";
> 				reg = <0x050000 0x1000>;
> 				interrupts = <9 10>;
> 			};
> 
> 			kmi@060000 {
> 				compatible = "arm,pl050", "arm,primecell";
> 				reg = <0x060000 0x1000>;
> 				interrupts = <12>;
> 			};
> 
> 			kmi@070000 {
> 				compatible = "arm,pl050", "arm,primecell";
> 				reg = <0x070000 0x1000>;
> 				interrupts = <13>;
> 			};
> 
> 			v2m_serial0: uart@090000 {
> 				compatible = "arm,pl011", "arm,primecell";
> 				reg = <0x090000 0x1000>;
> 				interrupts = <5>;
> 			};
> 
> 			v2m_serial1: uart@0a0000 {
> 				compatible = "arm,pl011", "arm,primecell";
> 				reg = <0x0a0000 0x1000>;
> 				interrupts = <6>;
> 			};
> 
> 			v2m_serial2: uart@0b0000 {
> 				compatible = "arm,pl011", "arm,primecell";
> 				reg = <0x0b0000 0x1000>;
> 				interrupts = <7>;
> 			};
> 
> 			v2m_serial3: uart@0c0000 {
> 				compatible = "arm,pl011", "arm,primecell";
> 				reg = <0x0c0000 0x1000>;
> 				interrupts = <8>;
> 			};
> 
> 			wdt@0f0000 {
> 				compatible = "arm,sp805", "arm,primecell";
> 				reg = <0x0f0000 0x1000>;
> 				interrupts = <0>;
> 			};
> 
> 			v2m_timer01: timer@110000 {
> 				compatible = "arm,sp804", "arm,primecell";
> 				reg = <0x110000 0x1000>;
> 				interrupts = <2>;
> 			};
> 
> 			v2m_timer23: timer@120000 {
> 				compatible = "arm,sp804", "arm,primecell";
> 				reg = <0x120000 0x1000>;
> 				interrupts = <3>;
> 			};
> 
> 			/* DVI I2C bus */
> 			v2m_i2c_dvi: i2c@160000 {
> 				compatible = "arm,versatile-i2c";
> 				reg = <0x160000 0x1000>;
> 
> 				#address-cells = <1>;
> 				#size-cells = <0>;
> 
> 				dvi-transmitter@39 {
> 					compatible = "sil,sii9022-tpi", "sil,sii9022";
> 					reg = <0x39>;
> 				};
> 
> 				dvi-transmitter@60 {
> 					compatible = "sil,sii9022-cpi", "sil,sii9022";
> 					reg = <0x60>;
> 				};
> 			};
> 
> 			rtc@170000 {
> 				compatible = "arm,pl031", "arm,primecell";
> 				reg = <0x170000 0x1000>;
> 				interrupts = <4>;
> 			};
> 
> 			compact-flash@1a0000 {
> 				compatible = "arm,vexpress-cf", "ata-generic";
> 				reg = <0x1a0000 0x100
> 				       0x1a0100 0xf00>;
> 				reg-shift = <2>;
> 			};
> 
> 			clcd@1f0000 {
> 				compatible = "arm,pl111", "arm,primecell";
> 				reg = <0x1f0000 0x1000>;
> 				interrupts = <14>;
> 			};
> 		};
> 
> 		v2m_fixed_3v3: fixedregulator@0 {
> 			compatible = "regulator-fixed";
> 			regulator-name = "3V3";
> 			regulator-min-microvolt = <3300000>;
> 			regulator-max-microvolt = <3300000>;
> 			regulator-always-on;
> 		};
> 	};
> };

> /*
>  * ARM Ltd. Versatile Express
>  *
>  * CoreTile Express A15x2 (version with Test Chip 1)
>  * Cortex-A15 MPCore (V2P-CA15)
>  *
>  * HBI-0237A
>  */
> 
> /dts-v1/;
> 
> / {
> 	model = "V2P-CA15";
> 	arm,hbi = <0x237>;
> 	compatible = "arm,vexpress,v2p-ca15,tc1", "arm,vexpress,v2p-ca15", "arm,vexpress";
> 	interrupt-parent = <&gic>;
> 	#address-cells = <2>;
> 	#size-cells = <2>;
> 
> 	chosen {
>                  bootargs = "dom0_mem=128M";
>                  xen,dom0-bootargs = "earlyprintk console=ttyAMA1 root=/dev/mmcblk0 debug rw";
> 	};
> 
> 	aliases {
> 		serial0 = &v2m_serial0;
> 		serial1 = &v2m_serial1;
> 		serial2 = &v2m_serial2;
> 		serial3 = &v2m_serial3;
> 		i2c0 = &v2m_i2c_dvi;
> 		i2c1 = &v2m_i2c_pcie;
> 	};
> 
> 	cpus {
> 		#address-cells = <1>;
> 		#size-cells = <0>;
> 
> 		cpu@0 {
> 			device_type = "cpu";
> 			compatible = "arm,cortex-a15";
> 			reg = <0>;
> 		};
> 	};
> 
> 	memory@80000000 {
> 		device_type = "memory";
> 		reg = <0 0x80000000 0 0x80000000>;
> 	};
> 
> 	gic: interrupt-controller@2c001000 {
> 		compatible = "arm,cortex-a15-gic", "arm,cortex-a9-gic";
> 		#interrupt-cells = <3>;
> 		#address-cells = <0>;
> 		interrupt-controller;
> 		reg = <0 0x2c001000 0 0x1000>,
> 		      <0 0x2c002000 0 0x1000>,
> 		      <0 0x2c004000 0 0x2000>,
> 		      <0 0x2c006000 0 0x2000>;
> 		interrupts = <1 9 0xf04>;
> 	};
> 
> 	timer {
> 		compatible = "arm,armv7-timer";
> 		interrupts = <1 13 0xf08>,
> 			     <1 14 0xf08>,
> 			     <1 11 0xf08>,
> 			     <1 10 0xf08>;
> 	};
> 
> 	pmu {
> 		compatible = "arm,cortex-a15-pmu", "arm,cortex-a9-pmu";
> 		interrupts = <0 68 4>,
> 			     <0 69 4>;
> 	};
> 
> 	hypervisor {
> 		compatible = "xen,xen-4.2", "xen,xen";
> 		reg = <0 0xb0000000 0 0x20000>;
> 		interrupts = <1 15 0xf08>;
> 	};
> 
> 	motherboard {
> 		ranges = <0 0 0 0x08000000 0x04000000>,
> 			 <1 0 0 0x14000000 0x04000000>,
> 			 <2 0 0 0x18000000 0x04000000>,
> 			 <3 0 0 0x1c000000 0x04000000>,
> 			 <4 0 0 0x0c000000 0x04000000>,
> 			 <5 0 0 0x10000000 0x04000000>;
> 
> 		interrupt-map-mask = <0 0 63>;
> 		interrupt-map = <0 0  0 &gic 0  0 4>,
> 				<0 0  1 &gic 0  1 4>,
> 				<0 0  2 &gic 0  2 4>,
> 				<0 0  3 &gic 0  3 4>,
> 				<0 0  4 &gic 0  4 4>,
> 				<0 0  5 &gic 0  5 4>,
> 				<0 0  6 &gic 0  6 4>,
> 				<0 0  7 &gic 0  7 4>,
> 				<0 0  8 &gic 0  8 4>,
> 				<0 0  9 &gic 0  9 4>,
> 				<0 0 10 &gic 0 10 4>,
> 				<0 0 11 &gic 0 11 4>,
> 				<0 0 12 &gic 0 12 4>,
> 				<0 0 13 &gic 0 13 4>,
> 				<0 0 14 &gic 0 14 4>,
> 				<0 0 15 &gic 0 15 4>,
> 				<0 0 16 &gic 0 16 4>,
> 				<0 0 17 &gic 0 17 4>,
> 				<0 0 18 &gic 0 18 4>,
> 				<0 0 19 &gic 0 19 4>,
> 				<0 0 20 &gic 0 20 4>,
> 				<0 0 21 &gic 0 21 4>,
> 				<0 0 22 &gic 0 22 4>,
> 				<0 0 23 &gic 0 23 4>,
> 				<0 0 24 &gic 0 24 4>,
> 				<0 0 25 &gic 0 25 4>,
> 				<0 0 26 &gic 0 26 4>,
> 				<0 0 27 &gic 0 27 4>,
> 				<0 0 28 &gic 0 28 4>,
> 				<0 0 29 &gic 0 29 4>,
> 				<0 0 30 &gic 0 30 4>,
> 				<0 0 31 &gic 0 31 4>,
> 				<0 0 32 &gic 0 32 4>,
> 				<0 0 33 &gic 0 33 4>,
> 				<0 0 34 &gic 0 34 4>,
> 				<0 0 35 &gic 0 35 4>,
> 				<0 0 36 &gic 0 36 4>,
> 				<0 0 37 &gic 0 37 4>,
> 				<0 0 38 &gic 0 38 4>,
> 				<0 0 39 &gic 0 39 4>,
> 				<0 0 40 &gic 0 40 4>,
> 				<0 0 41 &gic 0 41 4>,
> 				<0 0 42 &gic 0 42 4>;
> 	};
> };
> 
> /include/ "vexpress-v2m-rs1.dtsi"

> /*
>  * ARM Ltd. Versatile Express
>  *
>  * ARM Envelope Model v7A (single CPU).
>  */
> 
> /dts-v1/;
> 
> /include/ "skeleton.dtsi"
> 
> / {
> 	model = "V2P-AEMv7A";
> 	compatible = "arm,vexpress,v2p-aem,v7a", "arm,vexpress,v2p-aem", "arm,vexpress";
> 	interrupt-parent = <&gic>;
> 
>         chosen {
>                 bootargs = "earlyprintk debug loglevel=9 console=hvc0 root=/dev/xvda init=/sbin/init";
>         };
> 
> 	cpus {
> 		#address-cells = <1>;
> 		#size-cells = <0>;
> 
> 		cpu@0 {
> 			device_type = "cpu";
> 			compatible = "arm,cortex-a15";
> 			reg = <0>;
> 		};
> 	};
> 
> 	memory {
> 		device_type = "memory";
> 		reg = <0x80000000 0x08000000>;
> 	};
> 
> 	gic: interrupt-controller@2c001000 {
> 		compatible = "arm,cortex-a9-gic";
> 		#interrupt-cells = <3>;
> 		#address-cells = <0>;
> 		interrupt-controller;
> 		reg = <0x2c001000 0x1000>,
> 		      <0x2c002000 0x100>;
> 	};
> 
> 	timer {
> 		compatible = "arm,armv7-timer";
> 		interrupts = <1 13 0xf08>,
> 			     <1 14 0xf08>,
> 			     <1 11 0xf08>,
> 			     <1 10 0xf08>;
> 	};
> 
> 	hypervisor {
> 		compatible = "xen,xen-4.2", "xen,xen";
> 		reg = <0xb0000000 0x20000>;
> 		interrupts = <1 15 0xf08>;
> 	};
> 
> 	motherboard {
> 		arm,v2m-memory-map = "rs1";
> 		ranges = <0 0 0x08000000 0x04000000>,
> 			 <1 0 0x14000000 0x04000000>,
> 			 <2 0 0x18000000 0x04000000>,
> 			 <3 0 0x1c000000 0x04000000>,
> 			 <4 0 0x0c000000 0x04000000>,
> 			 <5 0 0x10000000 0x04000000>;
> 
> 		interrupt-map-mask = <0 0 63>;
> 		interrupt-map = <0 0  0 &gic 0  0 4>,
> 				<0 0  1 &gic 0  1 4>,
> 				<0 0  2 &gic 0  2 4>,
> 				<0 0  3 &gic 0  3 4>,
> 				<0 0  4 &gic 0  4 4>,
> 				<0 0  5 &gic 0  5 4>,
> 				<0 0  6 &gic 0  6 4>,
> 				<0 0  7 &gic 0  7 4>,
> 				<0 0  8 &gic 0  8 4>,
> 				<0 0  9 &gic 0  9 4>,
> 				<0 0 10 &gic 0 10 4>,
> 				<0 0 11 &gic 0 11 4>,
> 				<0 0 12 &gic 0 12 4>,
> 				<0 0 13 &gic 0 13 4>,
> 				<0 0 14 &gic 0 14 4>,
> 				<0 0 15 &gic 0 15 4>,
> 				<0 0 16 &gic 0 16 4>,
> 				<0 0 17 &gic 0 17 4>,
> 				<0 0 18 &gic 0 18 4>,
> 				<0 0 19 &gic 0 19 4>,
> 				<0 0 20 &gic 0 20 4>,
> 				<0 0 21 &gic 0 21 4>,
> 				<0 0 22 &gic 0 22 4>,
> 				<0 0 23 &gic 0 23 4>,
> 				<0 0 24 &gic 0 24 4>,
> 				<0 0 25 &gic 0 25 4>,
> 				<0 0 26 &gic 0 26 4>,
> 				<0 0 27 &gic 0 27 4>,
> 				<0 0 28 &gic 0 28 4>,
> 				<0 0 29 &gic 0 29 4>,
> 				<0 0 30 &gic 0 30 4>,
> 				<0 0 31 &gic 0 31 4>,
> 				<0 0 32 &gic 0 32 4>,
> 				<0 0 33 &gic 0 33 4>,
> 				<0 0 34 &gic 0 34 4>,
> 				<0 0 35 &gic 0 35 4>,
> 				<0 0 36 &gic 0 36 4>,
> 				<0 0 37 &gic 0 37 4>,
> 				<0 0 38 &gic 0 38 4>,
> 				<0 0 39 &gic 0 39 4>,
> 				<0 0 40 &gic 0 40 4>,
> 				<0 0 41 &gic 0 41 4>,
> 				<0 0 42 &gic 0 42 4>;
> 	};
> };
> 
> /* /include/ "vexpress-v2m-rs1-rtsm.dtsi" */


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 14 13:32:28 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 13:32:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TCW0F-0005UG-KF; Fri, 14 Sep 2012 13:32:15 +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 1TCW0E-0005U5-3J
	for xen-devel@lists.xensource.com; Fri, 14 Sep 2012 13:32:14 +0000
Received: from [85.158.143.35:53060] by server-2.bemta-4.messagelabs.com id
	AD/9B-21239-DD133505; Fri, 14 Sep 2012 13:32:13 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1347629531!10169802!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDc1MTgyMQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29259 invoked from network); 14 Sep 2012 13:32:12 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-10.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 14 Sep 2012 13:32: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 q8EDVpg0020204
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 14 Sep 2012 13:31: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
	q8EDVnfi022374
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 14 Sep 2012 13:31:49 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
	q8EDVmwk010038; Fri, 14 Sep 2012 08:31:48 -0500
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 14 Sep 2012 06:31:48 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 93C014031C; Fri, 14 Sep 2012 09:21:08 -0400 (EDT)
Date: Fri, 14 Sep 2012 09:21:08 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	linux@arm.linux.org.uk
Message-ID: <20120914132108.GQ25249@phenom.dumpdata.com>
References: <alpine.DEB.2.02.1209141145150.29232@kaball.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <alpine.DEB.2.02.1209141145150.29232@kaball.uk.xensource.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linaro-dev@lists.linaro.org" <linaro-dev@lists.linaro.org>,
	Ian Campbell <Ian.Campbell@citrix.com>, "arnd@arndb.de" <arnd@arndb.de>,
	"catalin.marinas@arm.com" <catalin.marinas@arm.com>,
	"Tim \(Xen.org\)" <tim@xen.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Russell King - ARM Linux <linux@arm.linux.org.uk>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Xen-devel] [PATCH v4 00/24] Introduce Xen support on ARM
	(based on 3.6-rc5)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Sep 14, 2012 at 12:12:59PM +0100, Stefano Stabellini wrote:
> Hi all,
> this patch series implements Xen support for ARMv7 with virtualization
> extensions.  It allows a Linux guest to boot as dom0 and
> as domU on Xen on ARM. PV console, disk and network frontends and
> backends are all working correctly.
> 
> It has been tested on a Versatile Express Cortex A15 emulator, using the
> latest Xen ARM developement branch
> (git://xenbits.xen.org/people/ianc/xen-unstable.git arm-for-4.3) plus
> the "ARM hypercall ABI: 64 bit ready" patch series
> (http://marc.info/?l=xen-devel&m=134426267205408), and a simple ad-hoc
> tool to build guest domains (marc.info/?l=xen-devel&m=134089788016546).
> 
> The patch marked with [HACK] has been dropped from this series, however
> you can find it here:
> http://marc.info/?l=linux-kernel&m=134513277823527&w=2.
> 
> I am also attaching to this email the dts'es that I am currently using
> for dom0 and domU: vexpress-v2p-ca15-tc1.dts (that includes
> vexpress-v2m-rs1-rtsm.dtsi) is the dts used for dom0 and it is passed to
> Linux by Xen, while vexpress-virt.dts is the dts used for other domUs
> and it is appended in binary form to the guest kernel image. I am not
> sure where they are supposed to live yet, so I am just attaching them
> here so that people can actually try out this series if they want to.
> 
> Comments are very welcome!

I already put in these

1)      xen/events: fix unmask_evtchn for PV on HVM guests
2)      xen: missing includes
3)      xen: update xen_add_to_physmap interface
4)      xen: Introduce xen_pfn_t for pfn and mfn types
5)      xen: clear IRQ_NOAUTOEN and IRQ_NOREQUEST
6)      xen: allow privcmd for HVM guests

in my tree as they also impact/help the PVH domains which works for
x86 (Well, not all of them). They are in my stable/for-linus-3.7 git tree
(git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git)
and also in #linux-next.


If it would make reviewing easier, I would recommend you rebase
your tree on top of the stable/for-linus-3.7 and just post them
as it would make the number of patches smaller.

Or alternatively, if the ARM maintainer wishes - just give you
the OK and we can figure out how/who is going to do the git-fu.

> 
> 
> 
> Patch #21 "arm/v2m: initialize arch_timers even if v2m_timer is not
> present" touches generic ARM code and still needs to be acked/reviewed.
> 
> Arnd, Russell, what do you think about this series? If you are OK with
> it, to whom should I submit it?
> 
> 
> 
> Changes in v4:
> - rebase on 3.6-rc5;
> - devicetree: "xen,xen" should be last as it is less specific;
> - devicetree: use 2 address-cells and 2 size-cells in the reg property;
> - do not xs_reset_watches on dom0;
> - compile drivers/xen/pcpu.c only on x86;
> - use "+=" instead of ":=" for dom0- targets;
> - add a patch to update the MAINTAINERS file.
> 
> 
> Changes in v3:
> - move patches that have been picked up by Konrad at the end of the
>   series;
> - improve comments;
> - add a doc to describe the Xen Device Tree format;
> - do not use xen_ulong_t for multicalls and apic_physbase;
> - add a patch at the end of the series to use the new __HVC macro;
> - add missing pvclock-abi.h include to ia64 header files;
> - do not use an anonymous union in struct xen_add_to_physmap.
> 
> 
> Changes in v2:
> - fix up many comments and commit messages;
> - remove the early_printk patches: rely on the emulated serial for now;
> - remove the xen_guest_init patch: without any PV early_printk, we don't
>   need any early call to xen_guest_init, we can rely on core_initcall
>   alone;
> - define an HYPERCALL macro for 5 arguments hypercall wrappers, even if
>   at the moment is unused;
> - use ldm instead of pop in the hypercall wrappers;
> - return -ENOSYS rather than -1 from the unimplemented grant_table
>   functions;
> - remove the pvclock ifdef in the Xen headers;
> - remove include linux/types.h from xen/interface/xen.h;
> - replace pr_info with pr_debug in xen_guest_init;
> - add a new patch to introduce xen_ulong_t and use it top replace all
>   the occurences of unsigned long in the public Xen interface;
> - explicitely size all the pointers to 64 bit on ARM, so that the
>   hypercall ABI is "64 bit ready";
> - clean up xenbus_init;
> - make pci.o depend on CONFIG_PCI and acpi.o depend on CONFIG_ACPI;
> - mark Xen guest support on ARM as EXPERIMENTAL;
> - introduce GRANT_TABLE_PHYSADDR;
> - remove unneeded initialization of boot_max_nr_grant_frames;
> - add a new patch to clear IRQ_NOAUTOEN and IRQ_NOREQUEST in events.c;
> - return -EINVAL from xen_remap_domain_mfn_range if
>   auto_translated_physmap;
> - retain binary compatibility in xen_add_to_physmap: use a union to
>   introduce foreign_domid.
> 
> 
> Shortlog and diffstat:
> 
> Stefano Stabellini (24):
>       arm: initial Xen support
>       xen/arm: hypercalls
>       xen/arm: page.h definitions
>       xen/arm: sync_bitops
>       xen/arm: empty implementation of grant_table arch specific functions
>       docs: Xen ARM DT bindings
>       xen/arm: Xen detection and shared_info page mapping
>       xen/arm: Introduce xen_pfn_t for pfn and mfn types
>       xen/arm: Introduce xen_ulong_t for unsigned long
>       xen/arm: compile and run xenbus
>       xen: do not compile manage, balloon, pci, acpi, pcpu and cpu_hotplug on ARM
>       xen/arm: introduce CONFIG_XEN on ARM
>       xen/arm: get privilege status
>       xen/arm: initialize grant_table on ARM
>       xen/arm: receive Xen events on ARM
>       xen: clear IRQ_NOAUTOEN and IRQ_NOREQUEST
>       xen/arm: implement alloc/free_xenballooned_pages with alloc_pages/kfree
>       xen: allow privcmd for HVM guests
>       xen/arm: compile blkfront and blkback
>       xen/arm: compile netback
>       arm/v2m: initialize arch_timers even if v2m_timer is not present
>       xen: missing includes
>       xen: update xen_add_to_physmap interface
>       MAINTAINERS: add myself as Xen ARM maintainer
> 
>  Documentation/devicetree/bindings/arm/xen.txt |   22 ++++
>  MAINTAINERS                                   |    7 +
>  arch/arm/Kconfig                              |   10 ++
>  arch/arm/Makefile                             |    1 +
>  arch/arm/include/asm/hypervisor.h             |    6 +
>  arch/arm/include/asm/sync_bitops.h            |   27 ++++
>  arch/arm/include/asm/xen/events.h             |   18 +++
>  arch/arm/include/asm/xen/hypercall.h          |   69 ++++++++++
>  arch/arm/include/asm/xen/hypervisor.h         |   19 +++
>  arch/arm/include/asm/xen/interface.h          |   73 +++++++++++
>  arch/arm/include/asm/xen/page.h               |   82 ++++++++++++
>  arch/arm/mach-vexpress/v2m.c                  |   11 +-
>  arch/arm/xen/Makefile                         |    1 +
>  arch/arm/xen/enlighten.c                      |  168 +++++++++++++++++++++++++
>  arch/arm/xen/grant-table.c                    |   53 ++++++++
>  arch/arm/xen/hypercall.S                      |  106 ++++++++++++++++
>  arch/ia64/include/asm/xen/interface.h         |    8 +-
>  arch/x86/include/asm/xen/interface.h          |    8 ++
>  arch/x86/xen/enlighten.c                      |    1 +
>  arch/x86/xen/irq.c                            |    1 +
>  arch/x86/xen/mmu.c                            |    3 +
>  arch/x86/xen/xen-ops.h                        |    1 -
>  drivers/block/xen-blkback/blkback.c           |    1 +
>  drivers/net/xen-netback/netback.c             |    1 +
>  drivers/net/xen-netfront.c                    |    1 +
>  drivers/tty/hvc/hvc_xen.c                     |    2 +
>  drivers/xen/Makefile                          |   13 ++-
>  drivers/xen/events.c                          |   18 +++-
>  drivers/xen/grant-table.c                     |    1 +
>  drivers/xen/privcmd.c                         |    4 -
>  drivers/xen/xenbus/xenbus_comms.c             |    2 +-
>  drivers/xen/xenbus/xenbus_probe.c             |   62 +++++++---
>  drivers/xen/xenbus/xenbus_probe_frontend.c    |    1 +
>  drivers/xen/xenbus/xenbus_xs.c                |    3 +-
>  include/xen/events.h                          |    2 +
>  include/xen/interface/features.h              |    3 +
>  include/xen/interface/grant_table.h           |    4 +-
>  include/xen/interface/io/protocols.h          |    3 +
>  include/xen/interface/memory.h                |   21 ++--
>  include/xen/interface/physdev.h               |    2 +-
>  include/xen/interface/platform.h              |    4 +-
>  include/xen/interface/version.h               |    2 +-
>  include/xen/interface/xen.h                   |    7 +-
>  include/xen/privcmd.h                         |    3 +-
>  include/xen/xen.h                             |    2 +-
>  45 files changed, 796 insertions(+), 61 deletions(-)
> 
> 
> 
> A branch based on 3.6-rc5 is available here:
> 
> git://xenbits.xen.org/people/sstabellini/linux-pvhvm.git 3.6-rc5-arm-4
> 
> 
> Cheers,
> 
> Stefano

> /*
>  * ARM Ltd. Versatile Express
>  *
>  * Motherboard Express uATX
>  * V2M-P1
>  *
>  * HBI-0190D
>  *
>  * RS1 memory map ("ARM Cortex-A Series memory map" in the board's
>  * Technical Reference Manual)
>  *
>  * WARNING! The hardware described in this file is independent from the
>  * original variant (vexpress-v2m.dtsi), but there is a strong
>  * correspondence between the two configurations.
>  *
>  * TAKE CARE WHEN MAINTAINING THIS FILE TO PROPAGATE ANY RELEVANT
>  * CHANGES TO vexpress-v2m.dtsi!
>  */
> 
> / {
> 	aliases {
> 		arm,v2m_timer = &v2m_timer01;
> 	};
> 
> 	motherboard {
> 		compatible = "simple-bus";
> 		arm,v2m-memory-map = "rs1";
> 		#address-cells = <2>; /* SMB chipselect number and offset */
> 		#size-cells = <1>;
> 		#interrupt-cells = <1>;
> 
> 		flash@0,00000000 {
> 			compatible = "arm,vexpress-flash", "cfi-flash";
> 			reg = <0 0x00000000 0x04000000>,
> 			      <4 0x00000000 0x04000000>;
> 			bank-width = <4>;
> 		};
> 
> 		psram@1,00000000 {
> 			compatible = "arm,vexpress-psram", "mtd-ram";
> 			reg = <1 0x00000000 0x02000000>;
> 			bank-width = <4>;
> 		};
> 
> 		vram@2,00000000 {
> 			compatible = "arm,vexpress-vram";
> 			reg = <2 0x00000000 0x00800000>;
> 		};
> 
> 		ethernet@2,02000000 {
> 			compatible = "smsc,lan91c111";
> 			reg = <2 0x02000000 0x10000>;
> 			interrupts = <15>;
> 		};
> 
> 		usb@2,03000000 {
> 			compatible = "nxp,usb-isp1761";
> 			reg = <2 0x03000000 0x20000>;
> 			interrupts = <16>;
> 			port1-otg;
> 		};
> 
> 		iofpga@3,00000000 {
> 			compatible = "arm,amba-bus", "simple-bus";
> 			#address-cells = <1>;
> 			#size-cells = <1>;
> 			ranges = <0 3 0 0x200000>;
> 
> 			sysreg@010000 {
> 				compatible = "arm,vexpress-sysreg";
> 				reg = <0x010000 0x1000>;
> 			};
> 
> 			sysctl@020000 {
> 				compatible = "arm,sp810", "arm,primecell";
> 				reg = <0x020000 0x1000>;
> 			};
> 
> 			/* PCI-E I2C bus */
> 			v2m_i2c_pcie: i2c@030000 {
> 				compatible = "arm,versatile-i2c";
> 				reg = <0x030000 0x1000>;
> 
> 				#address-cells = <1>;
> 				#size-cells = <0>;
> 
> 				pcie-switch@60 {
> 					compatible = "idt,89hpes32h8";
> 					reg = <0x60>;
> 				};
> 			};
> 
> 			aaci@040000 {
> 				compatible = "arm,pl041", "arm,primecell";
> 				reg = <0x040000 0x1000>;
> 				interrupts = <11>;
> 			};
> 
> 			mmci@050000 {
> 				compatible = "arm,pl180", "arm,primecell";
> 				reg = <0x050000 0x1000>;
> 				interrupts = <9 10>;
> 			};
> 
> 			kmi@060000 {
> 				compatible = "arm,pl050", "arm,primecell";
> 				reg = <0x060000 0x1000>;
> 				interrupts = <12>;
> 			};
> 
> 			kmi@070000 {
> 				compatible = "arm,pl050", "arm,primecell";
> 				reg = <0x070000 0x1000>;
> 				interrupts = <13>;
> 			};
> 
> 			v2m_serial0: uart@090000 {
> 				compatible = "arm,pl011", "arm,primecell";
> 				reg = <0x090000 0x1000>;
> 				interrupts = <5>;
> 			};
> 
> 			v2m_serial1: uart@0a0000 {
> 				compatible = "arm,pl011", "arm,primecell";
> 				reg = <0x0a0000 0x1000>;
> 				interrupts = <6>;
> 			};
> 
> 			v2m_serial2: uart@0b0000 {
> 				compatible = "arm,pl011", "arm,primecell";
> 				reg = <0x0b0000 0x1000>;
> 				interrupts = <7>;
> 			};
> 
> 			v2m_serial3: uart@0c0000 {
> 				compatible = "arm,pl011", "arm,primecell";
> 				reg = <0x0c0000 0x1000>;
> 				interrupts = <8>;
> 			};
> 
> 			wdt@0f0000 {
> 				compatible = "arm,sp805", "arm,primecell";
> 				reg = <0x0f0000 0x1000>;
> 				interrupts = <0>;
> 			};
> 
> 			v2m_timer01: timer@110000 {
> 				compatible = "arm,sp804", "arm,primecell";
> 				reg = <0x110000 0x1000>;
> 				interrupts = <2>;
> 			};
> 
> 			v2m_timer23: timer@120000 {
> 				compatible = "arm,sp804", "arm,primecell";
> 				reg = <0x120000 0x1000>;
> 				interrupts = <3>;
> 			};
> 
> 			/* DVI I2C bus */
> 			v2m_i2c_dvi: i2c@160000 {
> 				compatible = "arm,versatile-i2c";
> 				reg = <0x160000 0x1000>;
> 
> 				#address-cells = <1>;
> 				#size-cells = <0>;
> 
> 				dvi-transmitter@39 {
> 					compatible = "sil,sii9022-tpi", "sil,sii9022";
> 					reg = <0x39>;
> 				};
> 
> 				dvi-transmitter@60 {
> 					compatible = "sil,sii9022-cpi", "sil,sii9022";
> 					reg = <0x60>;
> 				};
> 			};
> 
> 			rtc@170000 {
> 				compatible = "arm,pl031", "arm,primecell";
> 				reg = <0x170000 0x1000>;
> 				interrupts = <4>;
> 			};
> 
> 			compact-flash@1a0000 {
> 				compatible = "arm,vexpress-cf", "ata-generic";
> 				reg = <0x1a0000 0x100
> 				       0x1a0100 0xf00>;
> 				reg-shift = <2>;
> 			};
> 
> 			clcd@1f0000 {
> 				compatible = "arm,pl111", "arm,primecell";
> 				reg = <0x1f0000 0x1000>;
> 				interrupts = <14>;
> 			};
> 		};
> 
> 		v2m_fixed_3v3: fixedregulator@0 {
> 			compatible = "regulator-fixed";
> 			regulator-name = "3V3";
> 			regulator-min-microvolt = <3300000>;
> 			regulator-max-microvolt = <3300000>;
> 			regulator-always-on;
> 		};
> 	};
> };

> /*
>  * ARM Ltd. Versatile Express
>  *
>  * CoreTile Express A15x2 (version with Test Chip 1)
>  * Cortex-A15 MPCore (V2P-CA15)
>  *
>  * HBI-0237A
>  */
> 
> /dts-v1/;
> 
> / {
> 	model = "V2P-CA15";
> 	arm,hbi = <0x237>;
> 	compatible = "arm,vexpress,v2p-ca15,tc1", "arm,vexpress,v2p-ca15", "arm,vexpress";
> 	interrupt-parent = <&gic>;
> 	#address-cells = <2>;
> 	#size-cells = <2>;
> 
> 	chosen {
>                  bootargs = "dom0_mem=128M";
>                  xen,dom0-bootargs = "earlyprintk console=ttyAMA1 root=/dev/mmcblk0 debug rw";
> 	};
> 
> 	aliases {
> 		serial0 = &v2m_serial0;
> 		serial1 = &v2m_serial1;
> 		serial2 = &v2m_serial2;
> 		serial3 = &v2m_serial3;
> 		i2c0 = &v2m_i2c_dvi;
> 		i2c1 = &v2m_i2c_pcie;
> 	};
> 
> 	cpus {
> 		#address-cells = <1>;
> 		#size-cells = <0>;
> 
> 		cpu@0 {
> 			device_type = "cpu";
> 			compatible = "arm,cortex-a15";
> 			reg = <0>;
> 		};
> 	};
> 
> 	memory@80000000 {
> 		device_type = "memory";
> 		reg = <0 0x80000000 0 0x80000000>;
> 	};
> 
> 	gic: interrupt-controller@2c001000 {
> 		compatible = "arm,cortex-a15-gic", "arm,cortex-a9-gic";
> 		#interrupt-cells = <3>;
> 		#address-cells = <0>;
> 		interrupt-controller;
> 		reg = <0 0x2c001000 0 0x1000>,
> 		      <0 0x2c002000 0 0x1000>,
> 		      <0 0x2c004000 0 0x2000>,
> 		      <0 0x2c006000 0 0x2000>;
> 		interrupts = <1 9 0xf04>;
> 	};
> 
> 	timer {
> 		compatible = "arm,armv7-timer";
> 		interrupts = <1 13 0xf08>,
> 			     <1 14 0xf08>,
> 			     <1 11 0xf08>,
> 			     <1 10 0xf08>;
> 	};
> 
> 	pmu {
> 		compatible = "arm,cortex-a15-pmu", "arm,cortex-a9-pmu";
> 		interrupts = <0 68 4>,
> 			     <0 69 4>;
> 	};
> 
> 	hypervisor {
> 		compatible = "xen,xen-4.2", "xen,xen";
> 		reg = <0 0xb0000000 0 0x20000>;
> 		interrupts = <1 15 0xf08>;
> 	};
> 
> 	motherboard {
> 		ranges = <0 0 0 0x08000000 0x04000000>,
> 			 <1 0 0 0x14000000 0x04000000>,
> 			 <2 0 0 0x18000000 0x04000000>,
> 			 <3 0 0 0x1c000000 0x04000000>,
> 			 <4 0 0 0x0c000000 0x04000000>,
> 			 <5 0 0 0x10000000 0x04000000>;
> 
> 		interrupt-map-mask = <0 0 63>;
> 		interrupt-map = <0 0  0 &gic 0  0 4>,
> 				<0 0  1 &gic 0  1 4>,
> 				<0 0  2 &gic 0  2 4>,
> 				<0 0  3 &gic 0  3 4>,
> 				<0 0  4 &gic 0  4 4>,
> 				<0 0  5 &gic 0  5 4>,
> 				<0 0  6 &gic 0  6 4>,
> 				<0 0  7 &gic 0  7 4>,
> 				<0 0  8 &gic 0  8 4>,
> 				<0 0  9 &gic 0  9 4>,
> 				<0 0 10 &gic 0 10 4>,
> 				<0 0 11 &gic 0 11 4>,
> 				<0 0 12 &gic 0 12 4>,
> 				<0 0 13 &gic 0 13 4>,
> 				<0 0 14 &gic 0 14 4>,
> 				<0 0 15 &gic 0 15 4>,
> 				<0 0 16 &gic 0 16 4>,
> 				<0 0 17 &gic 0 17 4>,
> 				<0 0 18 &gic 0 18 4>,
> 				<0 0 19 &gic 0 19 4>,
> 				<0 0 20 &gic 0 20 4>,
> 				<0 0 21 &gic 0 21 4>,
> 				<0 0 22 &gic 0 22 4>,
> 				<0 0 23 &gic 0 23 4>,
> 				<0 0 24 &gic 0 24 4>,
> 				<0 0 25 &gic 0 25 4>,
> 				<0 0 26 &gic 0 26 4>,
> 				<0 0 27 &gic 0 27 4>,
> 				<0 0 28 &gic 0 28 4>,
> 				<0 0 29 &gic 0 29 4>,
> 				<0 0 30 &gic 0 30 4>,
> 				<0 0 31 &gic 0 31 4>,
> 				<0 0 32 &gic 0 32 4>,
> 				<0 0 33 &gic 0 33 4>,
> 				<0 0 34 &gic 0 34 4>,
> 				<0 0 35 &gic 0 35 4>,
> 				<0 0 36 &gic 0 36 4>,
> 				<0 0 37 &gic 0 37 4>,
> 				<0 0 38 &gic 0 38 4>,
> 				<0 0 39 &gic 0 39 4>,
> 				<0 0 40 &gic 0 40 4>,
> 				<0 0 41 &gic 0 41 4>,
> 				<0 0 42 &gic 0 42 4>;
> 	};
> };
> 
> /include/ "vexpress-v2m-rs1.dtsi"

> /*
>  * ARM Ltd. Versatile Express
>  *
>  * ARM Envelope Model v7A (single CPU).
>  */
> 
> /dts-v1/;
> 
> /include/ "skeleton.dtsi"
> 
> / {
> 	model = "V2P-AEMv7A";
> 	compatible = "arm,vexpress,v2p-aem,v7a", "arm,vexpress,v2p-aem", "arm,vexpress";
> 	interrupt-parent = <&gic>;
> 
>         chosen {
>                 bootargs = "earlyprintk debug loglevel=9 console=hvc0 root=/dev/xvda init=/sbin/init";
>         };
> 
> 	cpus {
> 		#address-cells = <1>;
> 		#size-cells = <0>;
> 
> 		cpu@0 {
> 			device_type = "cpu";
> 			compatible = "arm,cortex-a15";
> 			reg = <0>;
> 		};
> 	};
> 
> 	memory {
> 		device_type = "memory";
> 		reg = <0x80000000 0x08000000>;
> 	};
> 
> 	gic: interrupt-controller@2c001000 {
> 		compatible = "arm,cortex-a9-gic";
> 		#interrupt-cells = <3>;
> 		#address-cells = <0>;
> 		interrupt-controller;
> 		reg = <0x2c001000 0x1000>,
> 		      <0x2c002000 0x100>;
> 	};
> 
> 	timer {
> 		compatible = "arm,armv7-timer";
> 		interrupts = <1 13 0xf08>,
> 			     <1 14 0xf08>,
> 			     <1 11 0xf08>,
> 			     <1 10 0xf08>;
> 	};
> 
> 	hypervisor {
> 		compatible = "xen,xen-4.2", "xen,xen";
> 		reg = <0xb0000000 0x20000>;
> 		interrupts = <1 15 0xf08>;
> 	};
> 
> 	motherboard {
> 		arm,v2m-memory-map = "rs1";
> 		ranges = <0 0 0x08000000 0x04000000>,
> 			 <1 0 0x14000000 0x04000000>,
> 			 <2 0 0x18000000 0x04000000>,
> 			 <3 0 0x1c000000 0x04000000>,
> 			 <4 0 0x0c000000 0x04000000>,
> 			 <5 0 0x10000000 0x04000000>;
> 
> 		interrupt-map-mask = <0 0 63>;
> 		interrupt-map = <0 0  0 &gic 0  0 4>,
> 				<0 0  1 &gic 0  1 4>,
> 				<0 0  2 &gic 0  2 4>,
> 				<0 0  3 &gic 0  3 4>,
> 				<0 0  4 &gic 0  4 4>,
> 				<0 0  5 &gic 0  5 4>,
> 				<0 0  6 &gic 0  6 4>,
> 				<0 0  7 &gic 0  7 4>,
> 				<0 0  8 &gic 0  8 4>,
> 				<0 0  9 &gic 0  9 4>,
> 				<0 0 10 &gic 0 10 4>,
> 				<0 0 11 &gic 0 11 4>,
> 				<0 0 12 &gic 0 12 4>,
> 				<0 0 13 &gic 0 13 4>,
> 				<0 0 14 &gic 0 14 4>,
> 				<0 0 15 &gic 0 15 4>,
> 				<0 0 16 &gic 0 16 4>,
> 				<0 0 17 &gic 0 17 4>,
> 				<0 0 18 &gic 0 18 4>,
> 				<0 0 19 &gic 0 19 4>,
> 				<0 0 20 &gic 0 20 4>,
> 				<0 0 21 &gic 0 21 4>,
> 				<0 0 22 &gic 0 22 4>,
> 				<0 0 23 &gic 0 23 4>,
> 				<0 0 24 &gic 0 24 4>,
> 				<0 0 25 &gic 0 25 4>,
> 				<0 0 26 &gic 0 26 4>,
> 				<0 0 27 &gic 0 27 4>,
> 				<0 0 28 &gic 0 28 4>,
> 				<0 0 29 &gic 0 29 4>,
> 				<0 0 30 &gic 0 30 4>,
> 				<0 0 31 &gic 0 31 4>,
> 				<0 0 32 &gic 0 32 4>,
> 				<0 0 33 &gic 0 33 4>,
> 				<0 0 34 &gic 0 34 4>,
> 				<0 0 35 &gic 0 35 4>,
> 				<0 0 36 &gic 0 36 4>,
> 				<0 0 37 &gic 0 37 4>,
> 				<0 0 38 &gic 0 38 4>,
> 				<0 0 39 &gic 0 39 4>,
> 				<0 0 40 &gic 0 40 4>,
> 				<0 0 41 &gic 0 41 4>,
> 				<0 0 42 &gic 0 42 4>;
> 	};
> };
> 
> /* /include/ "vexpress-v2m-rs1-rtsm.dtsi" */


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 14 13:38:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 13: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 1TCW5l-0005sr-Jn; Fri, 14 Sep 2012 13:37:57 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1TCW5k-0005sj-38
	for xen-devel@lists.xen.org; Fri, 14 Sep 2012 13:37:56 +0000
Received: from [85.158.139.83:26224] by server-10.bemta-5.messagelabs.com id
	36/AF-10969-33333505; Fri, 14 Sep 2012 13:37:55 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-16.tower-182.messagelabs.com!1347629874!23179645!1
X-Originating-IP: [63.239.67.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6370 invoked from network); 14 Sep 2012 13:37:54 -0000
Received: from emvm-gh1-uea09.nsa.gov (HELO nsa.gov) (63.239.67.10)
	by server-16.tower-182.messagelabs.com with SMTP;
	14 Sep 2012 13:37:54 -0000
X-TM-IMSS-Message-ID: <43abc15200120265@nsa.gov>
Received: from tarius.tycho.ncsc.mil ([144.51.3.1]) by nsa.gov
	([63.239.67.10]) with ESMTP (TREND IMSS SMTP Service 7.1) id
	43abc15200120265 ; Fri, 14 Sep 2012 09:39:56 -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 q8EDbqML011361; 
	Fri, 14 Sep 2012 09:37:52 -0400
Message-ID: <50533330.9020600@tycho.nsa.gov>
Date: Fri, 14 Sep 2012 09:37:52 -0400
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Organization: National Security Agency
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120828 Thunderbird/15.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <1347465586-20009-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1347465586-20009-20-git-send-email-dgdegra@tycho.nsa.gov>
	<5051AED7020000780009AFC3@nat28.tlf.novell.com>
	<5051E3AC.2060700@tycho.nsa.gov>
	<50520634020000780009B162@nat28.tlf.novell.com>
	<5051ECC7.7050901@tycho.nsa.gov>
	<5052121F020000780009B1E9@nat28.tlf.novell.com>
	<50520DFF.4030505@tycho.nsa.gov>
	<50530CF0020000780009B49B@nat28.tlf.novell.com>
In-Reply-To: <50530CF0020000780009B49B@nat28.tlf.novell.com>
Cc: Tim Deegan <tim@xen.org>, Keir Fraser <keir@xen.org>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 19/22] arch/x86: check remote MMIO remap
	permissions
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 09/14/2012 04:54 AM, Jan Beulich wrote:
>>>> On 13.09.12 at 18:46, Daniel De Graaf <dgdegra@tycho.nsa.gov> wrote:
>> For this example, assume domain A has access to map domain B's memory
>> read-only. Domain B has access to a device with MMIO where reads to the
>> device's memory cause state changes - an example of such as device is a
>> TPM, where replies are read by repeated reads to a single 4-byte 
>> address. Domain A does not have access to this device, and would like to
>> maliciously interfere with the device.
>>
>> If domain A maps the MMIO page from domain B using pg_owner == domB, the
>> iomem_access_permitted check will be done from domain B's perspective. 
>> While this is needed when domain A is mapping pages on behalf of domB, 
>> it is not sufficient when attempting to constrain domain A's access. 
>>
>> These checks only apply to MMIO, so the condition on line 735 will
>> evaluate to true (!mfn_valid || real_pg_owner == dom_io).
>>
>> The (existing) check on domain B's MMIO access is:
>>         if ( !iomem_access_permitted(pg_owner, mfn, mfn) )
>>
>> This patch adds a check on domain A:
>>         if ( !iomem_access_permitted(curr->domain, mfn, mfn) )
> 
> So then I think I was right suggesting that the second check
> should be done at the same place where the first one is, not
> outside/after the MMIO conditional.

That is where I am doing the second check; it is not outside the MMIO
conditional (which ends 8 lines after the inserted check).

>> This extra checking has not been required without XSM because only FLASK
>> implements the ability to grant one domain read-only access to another 
>> domain. With read-write access, this extra access check is simple to get
>> around: domain A can modify some part of the executable code in domain B
>> to act as a proxy for its accesses. Additionally, domain A is usually
>> dom0 or the device model, which have equal or greater MMIO access.
> 
> Understood.
> 
> Jan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 14 13:38:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 13: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 1TCW5l-0005sr-Jn; Fri, 14 Sep 2012 13:37:57 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1TCW5k-0005sj-38
	for xen-devel@lists.xen.org; Fri, 14 Sep 2012 13:37:56 +0000
Received: from [85.158.139.83:26224] by server-10.bemta-5.messagelabs.com id
	36/AF-10969-33333505; Fri, 14 Sep 2012 13:37:55 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-16.tower-182.messagelabs.com!1347629874!23179645!1
X-Originating-IP: [63.239.67.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6370 invoked from network); 14 Sep 2012 13:37:54 -0000
Received: from emvm-gh1-uea09.nsa.gov (HELO nsa.gov) (63.239.67.10)
	by server-16.tower-182.messagelabs.com with SMTP;
	14 Sep 2012 13:37:54 -0000
X-TM-IMSS-Message-ID: <43abc15200120265@nsa.gov>
Received: from tarius.tycho.ncsc.mil ([144.51.3.1]) by nsa.gov
	([63.239.67.10]) with ESMTP (TREND IMSS SMTP Service 7.1) id
	43abc15200120265 ; Fri, 14 Sep 2012 09:39:56 -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 q8EDbqML011361; 
	Fri, 14 Sep 2012 09:37:52 -0400
Message-ID: <50533330.9020600@tycho.nsa.gov>
Date: Fri, 14 Sep 2012 09:37:52 -0400
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Organization: National Security Agency
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120828 Thunderbird/15.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <1347465586-20009-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1347465586-20009-20-git-send-email-dgdegra@tycho.nsa.gov>
	<5051AED7020000780009AFC3@nat28.tlf.novell.com>
	<5051E3AC.2060700@tycho.nsa.gov>
	<50520634020000780009B162@nat28.tlf.novell.com>
	<5051ECC7.7050901@tycho.nsa.gov>
	<5052121F020000780009B1E9@nat28.tlf.novell.com>
	<50520DFF.4030505@tycho.nsa.gov>
	<50530CF0020000780009B49B@nat28.tlf.novell.com>
In-Reply-To: <50530CF0020000780009B49B@nat28.tlf.novell.com>
Cc: Tim Deegan <tim@xen.org>, Keir Fraser <keir@xen.org>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 19/22] arch/x86: check remote MMIO remap
	permissions
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 09/14/2012 04:54 AM, Jan Beulich wrote:
>>>> On 13.09.12 at 18:46, Daniel De Graaf <dgdegra@tycho.nsa.gov> wrote:
>> For this example, assume domain A has access to map domain B's memory
>> read-only. Domain B has access to a device with MMIO where reads to the
>> device's memory cause state changes - an example of such as device is a
>> TPM, where replies are read by repeated reads to a single 4-byte 
>> address. Domain A does not have access to this device, and would like to
>> maliciously interfere with the device.
>>
>> If domain A maps the MMIO page from domain B using pg_owner == domB, the
>> iomem_access_permitted check will be done from domain B's perspective. 
>> While this is needed when domain A is mapping pages on behalf of domB, 
>> it is not sufficient when attempting to constrain domain A's access. 
>>
>> These checks only apply to MMIO, so the condition on line 735 will
>> evaluate to true (!mfn_valid || real_pg_owner == dom_io).
>>
>> The (existing) check on domain B's MMIO access is:
>>         if ( !iomem_access_permitted(pg_owner, mfn, mfn) )
>>
>> This patch adds a check on domain A:
>>         if ( !iomem_access_permitted(curr->domain, mfn, mfn) )
> 
> So then I think I was right suggesting that the second check
> should be done at the same place where the first one is, not
> outside/after the MMIO conditional.

That is where I am doing the second check; it is not outside the MMIO
conditional (which ends 8 lines after the inserted check).

>> This extra checking has not been required without XSM because only FLASK
>> implements the ability to grant one domain read-only access to another 
>> domain. With read-write access, this extra access check is simple to get
>> around: domain A can modify some part of the executable code in domain B
>> to act as a proxy for its accesses. Additionally, domain A is usually
>> dom0 or the device model, which have equal or greater MMIO access.
> 
> Understood.
> 
> Jan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 14 13:46:28 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 13:46:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TCWDM-0006At-II; Fri, 14 Sep 2012 13:45:48 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <marc.zyngier@arm.com>) id 1TCWDK-0006Am-FQ
	for xen-devel@lists.xensource.com; Fri, 14 Sep 2012 13:45:46 +0000
Received: from [85.158.139.211:44296] by server-5.bemta-5.messagelabs.com id
	53/6B-30514-90533505; Fri, 14 Sep 2012 13:45:45 +0000
X-Env-Sender: marc.zyngier@arm.com
X-Msg-Ref: server-12.tower-206.messagelabs.com!1347630345!18532997!1
X-Originating-IP: [91.220.42.44]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogOTEuMjIwLjQyLjQ0ID0+IDI5NDIyMA==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28759 invoked from network); 14 Sep 2012 13:45:45 -0000
Received: from service87.mimecast.com (HELO service87.mimecast.com)
	(91.220.42.44) by server-12.tower-206.messagelabs.com with SMTP;
	14 Sep 2012 13:45:45 -0000
Received: from cam-owa1.Emea.Arm.com (fw-tnat.cambridge.arm.com
	[217.140.96.21]) by service87.mimecast.com;
	Fri, 14 Sep 2012 14:45:44 +0100
Received: from [10.1.70.21] ([10.1.255.212]) by cam-owa1.Emea.Arm.com with
	Microsoft SMTPSVC(6.0.3790.0); Fri, 14 Sep 2012 14:45:38 +0100
Message-ID: <50533500.2020606@arm.com>
Date: Fri, 14 Sep 2012 14:45:36 +0100
From: Marc Zyngier <marc.zyngier@arm.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:14.0) Gecko/20120714 Thunderbird/14.0
MIME-Version: 1.0
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.02.1209141145150.29232@kaball.uk.xensource.com>
	<1347621207-11294-2-git-send-email-stefano.stabellini@eu.citrix.com>
In-Reply-To: <1347621207-11294-2-git-send-email-stefano.stabellini@eu.citrix.com>
X-Enigmail-Version: 1.5a1pre
X-OriginalArrivalTime: 14 Sep 2012 13:45:38.0123 (UTC)
	FILETIME=[392AF1B0:01CD927F]
X-MC-Unique: 112091414454404301
Cc: Dave Martin <dave.martin@linaro.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linaro-dev@lists.linaro.org" <linaro-dev@lists.linaro.org>,
	"Ian.Campbell@citrix.com" <Ian.Campbell@citrix.com>,
	"arnd@arndb.de" <arnd@arndb.de>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
	Catalin Marinas <Catalin.Marinas@arm.com>, "tim@xen.org" <tim@xen.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux@arm.linux.org.uk" <linux@arm.linux.org.uk>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Xen-devel] [PATCH v4 02/24] xen/arm: hypercalls
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 14/09/12 12:13, Stefano Stabellini wrote:
> Use r12 to pass the hypercall number to the hypervisor.
> 
> We need a register to pass the hypercall number because we might not
> know it at compile time and HVC only takes an immediate argument.
> 
> Among the available registers r12 seems to be the best choice because it
> is defined as "intra-procedure call scratch register".
> 
> Use the ISS to pass an hypervisor specific tag.
> 
> 
> Changes in v2:
> - define an HYPERCALL macro for 5 arguments hypercall wrappers, even if
> at the moment is unused;
> - use ldm instead of pop;
> - fix up comments.
> 
> 
> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> ---
>  arch/arm/include/asm/xen/hypercall.h |   50 ++++++++++++++++
>  arch/arm/xen/Makefile                |    2 +-
>  arch/arm/xen/hypercall.S             |  106 ++++++++++++++++++++++++++++++++++
>  3 files changed, 157 insertions(+), 1 deletions(-)
>  create mode 100644 arch/arm/include/asm/xen/hypercall.h
>  create mode 100644 arch/arm/xen/hypercall.S
> 
> diff --git a/arch/arm/include/asm/xen/hypercall.h b/arch/arm/include/asm/xen/hypercall.h
> new file mode 100644
> index 0000000..4ac0624
> --- /dev/null
> +++ b/arch/arm/include/asm/xen/hypercall.h
> @@ -0,0 +1,50 @@
> +/******************************************************************************
> + * hypercall.h
> + *
> + * Linux-specific hypervisor handling.
> + *
> + * Stefano Stabellini <stefano.stabellini@eu.citrix.com>, Citrix, 2012
> + *
> + * 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.
> + */
> +
> +#ifndef _ASM_ARM_XEN_HYPERCALL_H
> +#define _ASM_ARM_XEN_HYPERCALL_H
> +
> +#include <xen/interface/xen.h>
> +
> +long privcmd_call(unsigned call, unsigned long a1,
> +		unsigned long a2, unsigned long a3,
> +		unsigned long a4, unsigned long a5);
> +int HYPERVISOR_xen_version(int cmd, void *arg);
> +int HYPERVISOR_console_io(int cmd, int count, char *str);
> +int HYPERVISOR_grant_table_op(unsigned int cmd, void *uop, unsigned int count);
> +int HYPERVISOR_sched_op(int cmd, void *arg);
> +int HYPERVISOR_event_channel_op(int cmd, void *arg);
> +unsigned long HYPERVISOR_hvm_op(int op, void *arg);
> +int HYPERVISOR_memory_op(unsigned int cmd, void *arg);
> +int HYPERVISOR_physdev_op(int cmd, void *arg);
> +
> +#endif /* _ASM_ARM_XEN_HYPERCALL_H */
> diff --git a/arch/arm/xen/Makefile b/arch/arm/xen/Makefile
> index 0bad594..b9d6acc 100644
> --- a/arch/arm/xen/Makefile
> +++ b/arch/arm/xen/Makefile
> @@ -1 +1 @@
> -obj-y		:= enlighten.o
> +obj-y		:= enlighten.o hypercall.o
> diff --git a/arch/arm/xen/hypercall.S b/arch/arm/xen/hypercall.S
> new file mode 100644
> index 0000000..074f5ed
> --- /dev/null
> +++ b/arch/arm/xen/hypercall.S
> @@ -0,0 +1,106 @@
> +/******************************************************************************
> + * hypercall.S
> + *
> + * Xen hypercall wrappers
> + *
> + * Stefano Stabellini <stefano.stabellini@eu.citrix.com>, Citrix, 2012
> + *
> + * 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.
> + */
> +
> +/*
> + * The Xen hypercall calling convention is very similar to the ARM
> + * procedure calling convention: the first paramter is passed in r0, the
> + * second in r1, the third in r2 and the fourth in r3. Considering that
> + * Xen hypercalls have 5 arguments at most, the fifth paramter is passed
> + * in r4, differently from the procedure calling convention of using the
> + * stack for that case.
> + *
> + * The hypercall number is passed in r12.
> + *
> + * The return value is in r0.
> + *
> + * The hvc ISS is required to be 0xEA1, that is the Xen specific ARM
> + * hypercall tag.
> + */
> +
> +#include <linux/linkage.h>
> +#include <asm/assembler.h>
> +#include <xen/interface/xen.h>
> +
> +
> +/* HVC 0xEA1 */
> +#ifdef CONFIG_THUMB2_KERNEL
> +#define xen_hvc .word 0xf7e08ea1
> +#else
> +#define xen_hvc .word 0xe140ea71
> +#endif

You should consider using Dave Martin's opcode injection series for
that. The patches are already in Russell's for-next branch.

	M.
-- 
Jazz is not dead. It just smells funny...


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 14 13:46:28 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 13:46:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TCWDM-0006At-II; Fri, 14 Sep 2012 13:45:48 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <marc.zyngier@arm.com>) id 1TCWDK-0006Am-FQ
	for xen-devel@lists.xensource.com; Fri, 14 Sep 2012 13:45:46 +0000
Received: from [85.158.139.211:44296] by server-5.bemta-5.messagelabs.com id
	53/6B-30514-90533505; Fri, 14 Sep 2012 13:45:45 +0000
X-Env-Sender: marc.zyngier@arm.com
X-Msg-Ref: server-12.tower-206.messagelabs.com!1347630345!18532997!1
X-Originating-IP: [91.220.42.44]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogOTEuMjIwLjQyLjQ0ID0+IDI5NDIyMA==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28759 invoked from network); 14 Sep 2012 13:45:45 -0000
Received: from service87.mimecast.com (HELO service87.mimecast.com)
	(91.220.42.44) by server-12.tower-206.messagelabs.com with SMTP;
	14 Sep 2012 13:45:45 -0000
Received: from cam-owa1.Emea.Arm.com (fw-tnat.cambridge.arm.com
	[217.140.96.21]) by service87.mimecast.com;
	Fri, 14 Sep 2012 14:45:44 +0100
Received: from [10.1.70.21] ([10.1.255.212]) by cam-owa1.Emea.Arm.com with
	Microsoft SMTPSVC(6.0.3790.0); Fri, 14 Sep 2012 14:45:38 +0100
Message-ID: <50533500.2020606@arm.com>
Date: Fri, 14 Sep 2012 14:45:36 +0100
From: Marc Zyngier <marc.zyngier@arm.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:14.0) Gecko/20120714 Thunderbird/14.0
MIME-Version: 1.0
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.02.1209141145150.29232@kaball.uk.xensource.com>
	<1347621207-11294-2-git-send-email-stefano.stabellini@eu.citrix.com>
In-Reply-To: <1347621207-11294-2-git-send-email-stefano.stabellini@eu.citrix.com>
X-Enigmail-Version: 1.5a1pre
X-OriginalArrivalTime: 14 Sep 2012 13:45:38.0123 (UTC)
	FILETIME=[392AF1B0:01CD927F]
X-MC-Unique: 112091414454404301
Cc: Dave Martin <dave.martin@linaro.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linaro-dev@lists.linaro.org" <linaro-dev@lists.linaro.org>,
	"Ian.Campbell@citrix.com" <Ian.Campbell@citrix.com>,
	"arnd@arndb.de" <arnd@arndb.de>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
	Catalin Marinas <Catalin.Marinas@arm.com>, "tim@xen.org" <tim@xen.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux@arm.linux.org.uk" <linux@arm.linux.org.uk>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Xen-devel] [PATCH v4 02/24] xen/arm: hypercalls
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 14/09/12 12:13, Stefano Stabellini wrote:
> Use r12 to pass the hypercall number to the hypervisor.
> 
> We need a register to pass the hypercall number because we might not
> know it at compile time and HVC only takes an immediate argument.
> 
> Among the available registers r12 seems to be the best choice because it
> is defined as "intra-procedure call scratch register".
> 
> Use the ISS to pass an hypervisor specific tag.
> 
> 
> Changes in v2:
> - define an HYPERCALL macro for 5 arguments hypercall wrappers, even if
> at the moment is unused;
> - use ldm instead of pop;
> - fix up comments.
> 
> 
> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> ---
>  arch/arm/include/asm/xen/hypercall.h |   50 ++++++++++++++++
>  arch/arm/xen/Makefile                |    2 +-
>  arch/arm/xen/hypercall.S             |  106 ++++++++++++++++++++++++++++++++++
>  3 files changed, 157 insertions(+), 1 deletions(-)
>  create mode 100644 arch/arm/include/asm/xen/hypercall.h
>  create mode 100644 arch/arm/xen/hypercall.S
> 
> diff --git a/arch/arm/include/asm/xen/hypercall.h b/arch/arm/include/asm/xen/hypercall.h
> new file mode 100644
> index 0000000..4ac0624
> --- /dev/null
> +++ b/arch/arm/include/asm/xen/hypercall.h
> @@ -0,0 +1,50 @@
> +/******************************************************************************
> + * hypercall.h
> + *
> + * Linux-specific hypervisor handling.
> + *
> + * Stefano Stabellini <stefano.stabellini@eu.citrix.com>, Citrix, 2012
> + *
> + * 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.
> + */
> +
> +#ifndef _ASM_ARM_XEN_HYPERCALL_H
> +#define _ASM_ARM_XEN_HYPERCALL_H
> +
> +#include <xen/interface/xen.h>
> +
> +long privcmd_call(unsigned call, unsigned long a1,
> +		unsigned long a2, unsigned long a3,
> +		unsigned long a4, unsigned long a5);
> +int HYPERVISOR_xen_version(int cmd, void *arg);
> +int HYPERVISOR_console_io(int cmd, int count, char *str);
> +int HYPERVISOR_grant_table_op(unsigned int cmd, void *uop, unsigned int count);
> +int HYPERVISOR_sched_op(int cmd, void *arg);
> +int HYPERVISOR_event_channel_op(int cmd, void *arg);
> +unsigned long HYPERVISOR_hvm_op(int op, void *arg);
> +int HYPERVISOR_memory_op(unsigned int cmd, void *arg);
> +int HYPERVISOR_physdev_op(int cmd, void *arg);
> +
> +#endif /* _ASM_ARM_XEN_HYPERCALL_H */
> diff --git a/arch/arm/xen/Makefile b/arch/arm/xen/Makefile
> index 0bad594..b9d6acc 100644
> --- a/arch/arm/xen/Makefile
> +++ b/arch/arm/xen/Makefile
> @@ -1 +1 @@
> -obj-y		:= enlighten.o
> +obj-y		:= enlighten.o hypercall.o
> diff --git a/arch/arm/xen/hypercall.S b/arch/arm/xen/hypercall.S
> new file mode 100644
> index 0000000..074f5ed
> --- /dev/null
> +++ b/arch/arm/xen/hypercall.S
> @@ -0,0 +1,106 @@
> +/******************************************************************************
> + * hypercall.S
> + *
> + * Xen hypercall wrappers
> + *
> + * Stefano Stabellini <stefano.stabellini@eu.citrix.com>, Citrix, 2012
> + *
> + * 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.
> + */
> +
> +/*
> + * The Xen hypercall calling convention is very similar to the ARM
> + * procedure calling convention: the first paramter is passed in r0, the
> + * second in r1, the third in r2 and the fourth in r3. Considering that
> + * Xen hypercalls have 5 arguments at most, the fifth paramter is passed
> + * in r4, differently from the procedure calling convention of using the
> + * stack for that case.
> + *
> + * The hypercall number is passed in r12.
> + *
> + * The return value is in r0.
> + *
> + * The hvc ISS is required to be 0xEA1, that is the Xen specific ARM
> + * hypercall tag.
> + */
> +
> +#include <linux/linkage.h>
> +#include <asm/assembler.h>
> +#include <xen/interface/xen.h>
> +
> +
> +/* HVC 0xEA1 */
> +#ifdef CONFIG_THUMB2_KERNEL
> +#define xen_hvc .word 0xf7e08ea1
> +#else
> +#define xen_hvc .word 0xe140ea71
> +#endif

You should consider using Dave Martin's opcode injection series for
that. The patches are already in Russell's for-next branch.

	M.
-- 
Jazz is not dead. It just smells funny...


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 14 13:47:42 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 13:47:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TCWEw-0006Fg-2X; Fri, 14 Sep 2012 13:47:26 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1TCWEv-0006FX-5n
	for xen-devel@lists.xensource.com; Fri, 14 Sep 2012 13:47:25 +0000
Received: from [85.158.143.35:14983] by server-2.bemta-4.messagelabs.com id
	E4/33-21239-C6533505; Fri, 14 Sep 2012 13:47:24 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1347630444!7236282!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDkyOTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30382 invoked from network); 14 Sep 2012 13:47:24 -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 Sep 2012 13:47:24 -0000
X-IronPort-AV: E=Sophos;i="4.80,423,1344211200"; d="scan'208";a="14547917"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Sep 2012 13: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.279.1;
	Fri, 14 Sep 2012 14:47:23 +0100
Message-ID: <1347630442.24226.211.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Date: Fri, 14 Sep 2012 14:47:22 +0100
In-Reply-To: <1347628660.24226.197.camel@zakaz.uk.xensource.com>
References: <alpine.DEB.2.02.1208221159560.15568@kaball.uk.xensource.com>
	<1345633688-31684-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<1347627587.24226.192.camel@zakaz.uk.xensource.com>
	<1347628660.24226.197.camel@zakaz.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-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 v4 1/6] xen: improve changes to
 xen_add_to_physmap
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gRnJpLCAyMDEyLTA5LTE0IGF0IDE0OjE3ICswMTAwLCBJYW4gQ2FtcGJlbGwgd3JvdGU6Cj4g
KGZvcmdvdCB0byBDQyBNdWtlc2ggb24geSBsYXN0IG1haWwgbGlrZSBJIHNhaWQgaXQgd291bGQs
IEkndmUgZG9uZSBpdAo+IG5vdyBhbmQgd2lsbCBib3VuY2UgdGhlIGxhc3Qgb25lIHRvIHlvdSBN
dWtlc2gpCgomJSTCoyUgSSd2ZSBkb25lIGl0IGFnYWluLiBBY3R1YWxseSBDQ2luZyBNdWtlc2gg
dGhpcyB0aW1lIQoKPiAKPiBPbiBGcmksIDIwMTItMDktMTQgYXQgMTM6NTkgKzAxMDAsIElhbiBD
YW1wYmVsbCB3cm90ZToKPiA+IAo+ID4gTWlnaHQgd2UgcHJlZmVyIHRvIGhhdmUgYSBiYXRjaGVk
IHZlcnNpb24gb2YgdGhpcyBjYWxsPyBJIGRvbid0IHRoaW5rCj4gPiB3ZSBjYW4gc2hvZWhvcm4g
dGhlIG5lY2Vzc2FyeSBmaWVsZHMgaW50byB4ZW5fYWRkX3RvX3BoeXNtYXBfdCB0aG91Z2guCj4g
Cj4gQWN0dWFsbHksIHRhbGtpbmcgYWJvdXQgdGhpcyB3ZSBTdGVmYW5vIHdlIHRoaW5rIHdlIGNh
bi4gU2luY2UgYm90aCBpZHgKPiBhbmQgZ3BmbiBhcmUgdW5zaWduZWQgbG9uZ3MgdGhleSBjYW4g
YmVjb21lIHVuaW9ucyB3aXRoIGEgR1VFU1RfSEFORExFCj4gd2l0aG91dCBjaGFuZ2luZyB0aGUg
QUJJIG9uIHg4Nl8zMiBvciB4ODZfNjQuCj4gCj4gSWYgd2UgZG8gdGhpcyB0aGVuIHdlIHNob3Vs
ZCBkbyBhd2F5IHdpdGggdGhlIHNpbmdsZXRvbgo+IFhFTk1BUFNQQUNFX2dtZm5fZm9yZWlnbiBh
bmQganVzdCBtYWtlIGl0IGEgYmF0Y2hlZCBpbnRlcmZhY2UuCj4gCj4gSWFuLgo+IAo+IAo+IF9f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCj4gWGVuLWRldmVs
IG1haWxpbmcgbGlzdAo+IFhlbi1kZXZlbEBsaXN0cy54ZW4ub3JnCj4gaHR0cDovL2xpc3RzLnhl
bi5vcmcveGVuLWRldmVsCgoKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbi5vcmcK
aHR0cDovL2xpc3RzLnhlbi5vcmcveGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Fri Sep 14 13:47:42 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 13:47:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TCWEw-0006Fg-2X; Fri, 14 Sep 2012 13:47:26 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1TCWEv-0006FX-5n
	for xen-devel@lists.xensource.com; Fri, 14 Sep 2012 13:47:25 +0000
Received: from [85.158.143.35:14983] by server-2.bemta-4.messagelabs.com id
	E4/33-21239-C6533505; Fri, 14 Sep 2012 13:47:24 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1347630444!7236282!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDkyOTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30382 invoked from network); 14 Sep 2012 13:47:24 -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 Sep 2012 13:47:24 -0000
X-IronPort-AV: E=Sophos;i="4.80,423,1344211200"; d="scan'208";a="14547917"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Sep 2012 13: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.279.1;
	Fri, 14 Sep 2012 14:47:23 +0100
Message-ID: <1347630442.24226.211.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Date: Fri, 14 Sep 2012 14:47:22 +0100
In-Reply-To: <1347628660.24226.197.camel@zakaz.uk.xensource.com>
References: <alpine.DEB.2.02.1208221159560.15568@kaball.uk.xensource.com>
	<1345633688-31684-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<1347627587.24226.192.camel@zakaz.uk.xensource.com>
	<1347628660.24226.197.camel@zakaz.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-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 v4 1/6] xen: improve changes to
 xen_add_to_physmap
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gRnJpLCAyMDEyLTA5LTE0IGF0IDE0OjE3ICswMTAwLCBJYW4gQ2FtcGJlbGwgd3JvdGU6Cj4g
KGZvcmdvdCB0byBDQyBNdWtlc2ggb24geSBsYXN0IG1haWwgbGlrZSBJIHNhaWQgaXQgd291bGQs
IEkndmUgZG9uZSBpdAo+IG5vdyBhbmQgd2lsbCBib3VuY2UgdGhlIGxhc3Qgb25lIHRvIHlvdSBN
dWtlc2gpCgomJSTCoyUgSSd2ZSBkb25lIGl0IGFnYWluLiBBY3R1YWxseSBDQ2luZyBNdWtlc2gg
dGhpcyB0aW1lIQoKPiAKPiBPbiBGcmksIDIwMTItMDktMTQgYXQgMTM6NTkgKzAxMDAsIElhbiBD
YW1wYmVsbCB3cm90ZToKPiA+IAo+ID4gTWlnaHQgd2UgcHJlZmVyIHRvIGhhdmUgYSBiYXRjaGVk
IHZlcnNpb24gb2YgdGhpcyBjYWxsPyBJIGRvbid0IHRoaW5rCj4gPiB3ZSBjYW4gc2hvZWhvcm4g
dGhlIG5lY2Vzc2FyeSBmaWVsZHMgaW50byB4ZW5fYWRkX3RvX3BoeXNtYXBfdCB0aG91Z2guCj4g
Cj4gQWN0dWFsbHksIHRhbGtpbmcgYWJvdXQgdGhpcyB3ZSBTdGVmYW5vIHdlIHRoaW5rIHdlIGNh
bi4gU2luY2UgYm90aCBpZHgKPiBhbmQgZ3BmbiBhcmUgdW5zaWduZWQgbG9uZ3MgdGhleSBjYW4g
YmVjb21lIHVuaW9ucyB3aXRoIGEgR1VFU1RfSEFORExFCj4gd2l0aG91dCBjaGFuZ2luZyB0aGUg
QUJJIG9uIHg4Nl8zMiBvciB4ODZfNjQuCj4gCj4gSWYgd2UgZG8gdGhpcyB0aGVuIHdlIHNob3Vs
ZCBkbyBhd2F5IHdpdGggdGhlIHNpbmdsZXRvbgo+IFhFTk1BUFNQQUNFX2dtZm5fZm9yZWlnbiBh
bmQganVzdCBtYWtlIGl0IGEgYmF0Y2hlZCBpbnRlcmZhY2UuCj4gCj4gSWFuLgo+IAo+IAo+IF9f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCj4gWGVuLWRldmVs
IG1haWxpbmcgbGlzdAo+IFhlbi1kZXZlbEBsaXN0cy54ZW4ub3JnCj4gaHR0cDovL2xpc3RzLnhl
bi5vcmcveGVuLWRldmVsCgoKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbi5vcmcK
aHR0cDovL2xpc3RzLnhlbi5vcmcveGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Fri Sep 14 13:57:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 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 1TCWNl-0006UL-5h; Fri, 14 Sep 2012 13:56: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 1TCWNj-0006UG-Nd
	for xen-devel@lists.xensource.com; Fri, 14 Sep 2012 13:56:31 +0000
Received: from [85.158.137.99:13759] by server-7.bemta-3.messagelabs.com id
	5A/2F-32000-E8733505; Fri, 14 Sep 2012 13:56:30 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-217.messagelabs.com!1347630989!12333626!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDkyOTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16483 invoked from network); 14 Sep 2012 13:56:29 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Sep 2012 13:56:29 -0000
X-IronPort-AV: E=Sophos;i="4.80,423,1344211200"; d="scan'208";a="14548138"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Sep 2012 13:56:13 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Fri, 14 Sep 2012 14:56:12 +0100
Message-ID: <1347630971.24226.214.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Date: Fri, 14 Sep 2012 14:56:11 +0100
In-Reply-To: <1347630442.24226.211.camel@zakaz.uk.xensource.com>
References: <alpine.DEB.2.02.1208221159560.15568@kaball.uk.xensource.com>
	<1345633688-31684-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<1347627587.24226.192.camel@zakaz.uk.xensource.com>
	<1347628660.24226.197.camel@zakaz.uk.xensource.com>
	<1347630442.24226.211.camel@zakaz.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-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 v4 1/6] xen: improve changes to
 xen_add_to_physmap
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gRnJpLCAyMDEyLTA5LTE0IGF0IDE0OjQ3ICswMTAwLCBJYW4gQ2FtcGJlbGwgd3JvdGU6Cj4g
T24gRnJpLCAyMDEyLTA5LTE0IGF0IDE0OjE3ICswMTAwLCBJYW4gQ2FtcGJlbGwgd3JvdGU6Cj4g
PiAoZm9yZ290IHRvIENDIE11a2VzaCBvbiB5IGxhc3QgbWFpbCBsaWtlIEkgc2FpZCBpdCB3b3Vs
ZCwgSSd2ZSBkb25lIGl0Cj4gPiBub3cgYW5kIHdpbGwgYm91bmNlIHRoZSBsYXN0IG9uZSB0byB5
b3UgTXVrZXNoKQo+IAo+ICYlJMKjJSBJJ3ZlIGRvbmUgaXQgYWdhaW4uIEFjdHVhbGx5IENDaW5n
IE11a2VzaCB0aGlzIHRpbWUhCgpPSywgaXQncyBkZWZpbml0ZWx5IG5vdCBtZSwgSSdtIGNlcnRh
aW4gSSBDQ2QgaGltIHRoaXMgdGltZS4gV2hlcmUgb24KZWFydGggYXJlIHRoZXkgZ29pbmchCgo+
IAo+ID4gCj4gPiBPbiBGcmksIDIwMTItMDktMTQgYXQgMTM6NTkgKzAxMDAsIElhbiBDYW1wYmVs
bCB3cm90ZToKPiA+ID4gCj4gPiA+IE1pZ2h0IHdlIHByZWZlciB0byBoYXZlIGEgYmF0Y2hlZCB2
ZXJzaW9uIG9mIHRoaXMgY2FsbD8gSSBkb24ndCB0aGluawo+ID4gPiB3ZSBjYW4gc2hvZWhvcm4g
dGhlIG5lY2Vzc2FyeSBmaWVsZHMgaW50byB4ZW5fYWRkX3RvX3BoeXNtYXBfdCB0aG91Z2guCj4g
PiAKPiA+IEFjdHVhbGx5LCB0YWxraW5nIGFib3V0IHRoaXMgd2UgU3RlZmFubyB3ZSB0aGluayB3
ZSBjYW4uIFNpbmNlIGJvdGggaWR4Cj4gPiBhbmQgZ3BmbiBhcmUgdW5zaWduZWQgbG9uZ3MgdGhl
eSBjYW4gYmVjb21lIHVuaW9ucyB3aXRoIGEgR1VFU1RfSEFORExFCj4gPiB3aXRob3V0IGNoYW5n
aW5nIHRoZSBBQkkgb24geDg2XzMyIG9yIHg4Nl82NC4KCkV4Y2VwdCB3ZSBuZWVkIGJvdGggZm9y
ZWlnbl9kb21pZCBhbmQgc2l6ZSwgd2hpY2ggY3VycmVudGx5IG92ZXJsYXAsIGFuZAp0aGVyZSdz
IG5vIG90aGVyIHNwYXJlIGJpdHMuIERhbW4uCgpMb29rcyBsaWtlIFhFTk1FTV9hZGRfdG9fcGh5
c21hcF9yYW5nZSBpcyB0aGUgb25seSBvcHRpb24gOi0oCgpJYW4uCgo+ID4gCj4gPiBJZiB3ZSBk
byB0aGlzIHRoZW4gd2Ugc2hvdWxkIGRvIGF3YXkgd2l0aCB0aGUgc2luZ2xldG9uCj4gPiBYRU5N
QVBTUEFDRV9nbWZuX2ZvcmVpZ24gYW5kIGp1c3QgbWFrZSBpdCBhIGJhdGNoZWQgaW50ZXJmYWNl
Lgo+ID4gCj4gPiBJYW4uCj4gPiAKPiA+IAo+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX18KPiA+IFhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKPiA+IFhlbi1k
ZXZlbEBsaXN0cy54ZW4ub3JnCj4gPiBodHRwOi8vbGlzdHMueGVuLm9yZy94ZW4tZGV2ZWwKPiAK
PiAKPiAKPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwo+
IFhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKPiBYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwo+IGh0dHA6
Ly9saXN0cy54ZW4ub3JnL3hlbi1kZXZlbAoKCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fXwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0
cy54ZW4ub3JnCmh0dHA6Ly9saXN0cy54ZW4ub3JnL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xen.org Fri Sep 14 13:57:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 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 1TCWNl-0006UL-5h; Fri, 14 Sep 2012 13:56: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 1TCWNj-0006UG-Nd
	for xen-devel@lists.xensource.com; Fri, 14 Sep 2012 13:56:31 +0000
Received: from [85.158.137.99:13759] by server-7.bemta-3.messagelabs.com id
	5A/2F-32000-E8733505; Fri, 14 Sep 2012 13:56:30 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-217.messagelabs.com!1347630989!12333626!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDkyOTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16483 invoked from network); 14 Sep 2012 13:56:29 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Sep 2012 13:56:29 -0000
X-IronPort-AV: E=Sophos;i="4.80,423,1344211200"; d="scan'208";a="14548138"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Sep 2012 13:56:13 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Fri, 14 Sep 2012 14:56:12 +0100
Message-ID: <1347630971.24226.214.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Date: Fri, 14 Sep 2012 14:56:11 +0100
In-Reply-To: <1347630442.24226.211.camel@zakaz.uk.xensource.com>
References: <alpine.DEB.2.02.1208221159560.15568@kaball.uk.xensource.com>
	<1345633688-31684-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<1347627587.24226.192.camel@zakaz.uk.xensource.com>
	<1347628660.24226.197.camel@zakaz.uk.xensource.com>
	<1347630442.24226.211.camel@zakaz.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-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 v4 1/6] xen: improve changes to
 xen_add_to_physmap
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gRnJpLCAyMDEyLTA5LTE0IGF0IDE0OjQ3ICswMTAwLCBJYW4gQ2FtcGJlbGwgd3JvdGU6Cj4g
T24gRnJpLCAyMDEyLTA5LTE0IGF0IDE0OjE3ICswMTAwLCBJYW4gQ2FtcGJlbGwgd3JvdGU6Cj4g
PiAoZm9yZ290IHRvIENDIE11a2VzaCBvbiB5IGxhc3QgbWFpbCBsaWtlIEkgc2FpZCBpdCB3b3Vs
ZCwgSSd2ZSBkb25lIGl0Cj4gPiBub3cgYW5kIHdpbGwgYm91bmNlIHRoZSBsYXN0IG9uZSB0byB5
b3UgTXVrZXNoKQo+IAo+ICYlJMKjJSBJJ3ZlIGRvbmUgaXQgYWdhaW4uIEFjdHVhbGx5IENDaW5n
IE11a2VzaCB0aGlzIHRpbWUhCgpPSywgaXQncyBkZWZpbml0ZWx5IG5vdCBtZSwgSSdtIGNlcnRh
aW4gSSBDQ2QgaGltIHRoaXMgdGltZS4gV2hlcmUgb24KZWFydGggYXJlIHRoZXkgZ29pbmchCgo+
IAo+ID4gCj4gPiBPbiBGcmksIDIwMTItMDktMTQgYXQgMTM6NTkgKzAxMDAsIElhbiBDYW1wYmVs
bCB3cm90ZToKPiA+ID4gCj4gPiA+IE1pZ2h0IHdlIHByZWZlciB0byBoYXZlIGEgYmF0Y2hlZCB2
ZXJzaW9uIG9mIHRoaXMgY2FsbD8gSSBkb24ndCB0aGluawo+ID4gPiB3ZSBjYW4gc2hvZWhvcm4g
dGhlIG5lY2Vzc2FyeSBmaWVsZHMgaW50byB4ZW5fYWRkX3RvX3BoeXNtYXBfdCB0aG91Z2guCj4g
PiAKPiA+IEFjdHVhbGx5LCB0YWxraW5nIGFib3V0IHRoaXMgd2UgU3RlZmFubyB3ZSB0aGluayB3
ZSBjYW4uIFNpbmNlIGJvdGggaWR4Cj4gPiBhbmQgZ3BmbiBhcmUgdW5zaWduZWQgbG9uZ3MgdGhl
eSBjYW4gYmVjb21lIHVuaW9ucyB3aXRoIGEgR1VFU1RfSEFORExFCj4gPiB3aXRob3V0IGNoYW5n
aW5nIHRoZSBBQkkgb24geDg2XzMyIG9yIHg4Nl82NC4KCkV4Y2VwdCB3ZSBuZWVkIGJvdGggZm9y
ZWlnbl9kb21pZCBhbmQgc2l6ZSwgd2hpY2ggY3VycmVudGx5IG92ZXJsYXAsIGFuZAp0aGVyZSdz
IG5vIG90aGVyIHNwYXJlIGJpdHMuIERhbW4uCgpMb29rcyBsaWtlIFhFTk1FTV9hZGRfdG9fcGh5
c21hcF9yYW5nZSBpcyB0aGUgb25seSBvcHRpb24gOi0oCgpJYW4uCgo+ID4gCj4gPiBJZiB3ZSBk
byB0aGlzIHRoZW4gd2Ugc2hvdWxkIGRvIGF3YXkgd2l0aCB0aGUgc2luZ2xldG9uCj4gPiBYRU5N
QVBTUEFDRV9nbWZuX2ZvcmVpZ24gYW5kIGp1c3QgbWFrZSBpdCBhIGJhdGNoZWQgaW50ZXJmYWNl
Lgo+ID4gCj4gPiBJYW4uCj4gPiAKPiA+IAo+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX18KPiA+IFhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKPiA+IFhlbi1k
ZXZlbEBsaXN0cy54ZW4ub3JnCj4gPiBodHRwOi8vbGlzdHMueGVuLm9yZy94ZW4tZGV2ZWwKPiAK
PiAKPiAKPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwo+
IFhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKPiBYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwo+IGh0dHA6
Ly9saXN0cy54ZW4ub3JnL3hlbi1kZXZlbAoKCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fXwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0
cy54ZW4ub3JnCmh0dHA6Ly9saXN0cy54ZW4ub3JnL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xen.org Fri Sep 14 13:57:43 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 13:57:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TCWOd-0006XD-KK; Fri, 14 Sep 2012 13:57: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 1TCWOc-0006X4-39
	for xen-devel@lists.xensource.com; Fri, 14 Sep 2012 13:57:26 +0000
Received: from [85.158.138.51:43766] by server-2.bemta-3.messagelabs.com id
	DD/66-04862-5C733505; Fri, 14 Sep 2012 13:57:25 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1347631042!24234053!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDkyOTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23658 invoked from network); 14 Sep 2012 13:57:22 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Sep 2012 13:57:22 -0000
X-IronPort-AV: E=Sophos;i="4.80,423,1344211200"; d="scan'208";a="14548192"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Sep 2012 13:57: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.279.1; Fri, 14 Sep 2012 14:57:21 +0100
Date: Fri, 14 Sep 2012 14:56:38 +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: <20120914132108.GQ25249@phenom.dumpdata.com>
Message-ID: <alpine.DEB.2.02.1209141455350.29232@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1209141145150.29232@kaball.uk.xensource.com>
	<20120914132108.GQ25249@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@arm.linux.org.uk" <linux@arm.linux.org.uk>,
	Ian Campbell <Ian.Campbell@citrix.com>, "arnd@arndb.de" <arnd@arndb.de>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"catalin.marinas@arm.com" <catalin.marinas@arm.com>,
	"Tim \(Xen.org\)" <tim@xen.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linaro-dev@lists.linaro.org" <linaro-dev@lists.linaro.org>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Xen-devel] [PATCH v4 00/24] Introduce Xen support on ARM
 (based on 3.6-rc5)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 14 Sep 2012, Konrad Rzeszutek Wilk wrote:
> I already put in these
> 
> 1)      xen/events: fix unmask_evtchn for PV on HVM guests
> 2)      xen: missing includes
> 3)      xen: update xen_add_to_physmap interface
> 4)      xen: Introduce xen_pfn_t for pfn and mfn types
> 5)      xen: clear IRQ_NOAUTOEN and IRQ_NOREQUEST
> 6)      xen: allow privcmd for HVM guests
> 
> in my tree as they also impact/help the PVH domains which works for
> x86 (Well, not all of them). They are in my stable/for-linus-3.7 git tree
> (git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git)
> and also in #linux-next.
> 
> 
> If it would make reviewing easier, I would recommend you rebase
> your tree on top of the stable/for-linus-3.7 and just post them
> as it would make the number of patches smaller.

I have done that and it went quite smoothly. The patch series is now 5
patches smaller.
Thanks!

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 14 13:57:43 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 13:57:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TCWOd-0006XD-KK; Fri, 14 Sep 2012 13:57: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 1TCWOc-0006X4-39
	for xen-devel@lists.xensource.com; Fri, 14 Sep 2012 13:57:26 +0000
Received: from [85.158.138.51:43766] by server-2.bemta-3.messagelabs.com id
	DD/66-04862-5C733505; Fri, 14 Sep 2012 13:57:25 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1347631042!24234053!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDkyOTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23658 invoked from network); 14 Sep 2012 13:57:22 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Sep 2012 13:57:22 -0000
X-IronPort-AV: E=Sophos;i="4.80,423,1344211200"; d="scan'208";a="14548192"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Sep 2012 13:57: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.279.1; Fri, 14 Sep 2012 14:57:21 +0100
Date: Fri, 14 Sep 2012 14:56:38 +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: <20120914132108.GQ25249@phenom.dumpdata.com>
Message-ID: <alpine.DEB.2.02.1209141455350.29232@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1209141145150.29232@kaball.uk.xensource.com>
	<20120914132108.GQ25249@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@arm.linux.org.uk" <linux@arm.linux.org.uk>,
	Ian Campbell <Ian.Campbell@citrix.com>, "arnd@arndb.de" <arnd@arndb.de>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"catalin.marinas@arm.com" <catalin.marinas@arm.com>,
	"Tim \(Xen.org\)" <tim@xen.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linaro-dev@lists.linaro.org" <linaro-dev@lists.linaro.org>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Xen-devel] [PATCH v4 00/24] Introduce Xen support on ARM
 (based on 3.6-rc5)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 14 Sep 2012, Konrad Rzeszutek Wilk wrote:
> I already put in these
> 
> 1)      xen/events: fix unmask_evtchn for PV on HVM guests
> 2)      xen: missing includes
> 3)      xen: update xen_add_to_physmap interface
> 4)      xen: Introduce xen_pfn_t for pfn and mfn types
> 5)      xen: clear IRQ_NOAUTOEN and IRQ_NOREQUEST
> 6)      xen: allow privcmd for HVM guests
> 
> in my tree as they also impact/help the PVH domains which works for
> x86 (Well, not all of them). They are in my stable/for-linus-3.7 git tree
> (git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git)
> and also in #linux-next.
> 
> 
> If it would make reviewing easier, I would recommend you rebase
> your tree on top of the stable/for-linus-3.7 and just post them
> as it would make the number of patches smaller.

I have done that and it went quite smoothly. The patch series is now 5
patches smaller.
Thanks!

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 14 14:02:53 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 14:02: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 1TCWTM-0006pE-DG; Fri, 14 Sep 2012 14:02:20 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <marc.zyngier@arm.com>) id 1TCWTL-0006p7-C3
	for xen-devel@lists.xensource.com; Fri, 14 Sep 2012 14:02:19 +0000
Received: from [85.158.139.83:43473] by server-12.bemta-5.messagelabs.com id
	FD/44-19338-AE833505; Fri, 14 Sep 2012 14:02:18 +0000
X-Env-Sender: marc.zyngier@arm.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1347631337!23184211!1
X-Originating-IP: [91.220.42.44]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogOTEuMjIwLjQyLjQ0ID0+IDI5NDIyMA==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 617 invoked from network); 14 Sep 2012 14:02:17 -0000
Received: from service87.mimecast.com (HELO service87.mimecast.com)
	(91.220.42.44) by server-16.tower-182.messagelabs.com with SMTP;
	14 Sep 2012 14:02:17 -0000
Received: from cam-owa1.Emea.Arm.com (fw-tnat.cambridge.arm.com
	[217.140.96.21]) by service87.mimecast.com;
	Fri, 14 Sep 2012 15:02:17 +0100
Received: from [10.1.70.21] ([10.1.255.212]) by cam-owa1.Emea.Arm.com with
	Microsoft SMTPSVC(6.0.3790.0); Fri, 14 Sep 2012 15:02:14 +0100
Message-ID: <505338E6.4050504@arm.com>
Date: Fri, 14 Sep 2012 15:02:14 +0100
From: Marc Zyngier <marc.zyngier@arm.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:14.0) Gecko/20120714 Thunderbird/14.0
MIME-Version: 1.0
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.02.1209141145150.29232@kaball.uk.xensource.com>
	<1347621207-11294-16-git-send-email-stefano.stabellini@eu.citrix.com>
In-Reply-To: <1347621207-11294-16-git-send-email-stefano.stabellini@eu.citrix.com>
X-Enigmail-Version: 1.5a1pre
X-OriginalArrivalTime: 14 Sep 2012 14:02:14.0797 (UTC)
	FILETIME=[8B3B53D0:01CD9281]
X-MC-Unique: 112091415021705701
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linaro-dev@lists.linaro.org" <linaro-dev@lists.linaro.org>,
	"Ian.Campbell@citrix.com" <Ian.Campbell@citrix.com>,
	"arnd@arndb.de" <arnd@arndb.de>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
	Catalin Marinas <Catalin.Marinas@arm.com>, "tim@xen.org" <tim@xen.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux@arm.linux.org.uk" <linux@arm.linux.org.uk>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Xen-devel] [PATCH v4 16/24] xen: clear IRQ_NOAUTOEN and
	IRQ_NOREQUEST
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/09/12 12:13, Stefano Stabellini wrote:
> Reset the IRQ_NOAUTOEN and IRQ_NOREQUEST flags that are enabled by
> default on ARM. If IRQ_NOAUTOEN is set, __setup_irq doesn't call
> irq_startup, that is responsible for calling irq_unmask at startup time.
> As a result event channels remain masked.
> 
> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> ---
>  drivers/xen/events.c |    1 +
>  1 files changed, 1 insertions(+), 0 deletions(-)
> 
> diff --git a/drivers/xen/events.c b/drivers/xen/events.c
> index 5ecb596..8ffb7b7 100644
> --- a/drivers/xen/events.c
> +++ b/drivers/xen/events.c
> @@ -836,6 +836,7 @@ int bind_evtchn_to_irq(unsigned int evtchn)
>  		struct irq_info *info = info_for_irq(irq);
>  		WARN_ON(info == NULL || info->type != IRQT_EVTCHN);
>  	}
> +	irq_clear_status_flags(irq, IRQ_NOREQUEST|IRQ_NOAUTOEN);

This one just sent a shiver down my spine. Are you doing this for a PPI?

	M.
-- 
Jazz is not dead. It just smells funny...


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 14 14:02:53 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 14:02: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 1TCWTM-0006pE-DG; Fri, 14 Sep 2012 14:02:20 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <marc.zyngier@arm.com>) id 1TCWTL-0006p7-C3
	for xen-devel@lists.xensource.com; Fri, 14 Sep 2012 14:02:19 +0000
Received: from [85.158.139.83:43473] by server-12.bemta-5.messagelabs.com id
	FD/44-19338-AE833505; Fri, 14 Sep 2012 14:02:18 +0000
X-Env-Sender: marc.zyngier@arm.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1347631337!23184211!1
X-Originating-IP: [91.220.42.44]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogOTEuMjIwLjQyLjQ0ID0+IDI5NDIyMA==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 617 invoked from network); 14 Sep 2012 14:02:17 -0000
Received: from service87.mimecast.com (HELO service87.mimecast.com)
	(91.220.42.44) by server-16.tower-182.messagelabs.com with SMTP;
	14 Sep 2012 14:02:17 -0000
Received: from cam-owa1.Emea.Arm.com (fw-tnat.cambridge.arm.com
	[217.140.96.21]) by service87.mimecast.com;
	Fri, 14 Sep 2012 15:02:17 +0100
Received: from [10.1.70.21] ([10.1.255.212]) by cam-owa1.Emea.Arm.com with
	Microsoft SMTPSVC(6.0.3790.0); Fri, 14 Sep 2012 15:02:14 +0100
Message-ID: <505338E6.4050504@arm.com>
Date: Fri, 14 Sep 2012 15:02:14 +0100
From: Marc Zyngier <marc.zyngier@arm.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:14.0) Gecko/20120714 Thunderbird/14.0
MIME-Version: 1.0
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.02.1209141145150.29232@kaball.uk.xensource.com>
	<1347621207-11294-16-git-send-email-stefano.stabellini@eu.citrix.com>
In-Reply-To: <1347621207-11294-16-git-send-email-stefano.stabellini@eu.citrix.com>
X-Enigmail-Version: 1.5a1pre
X-OriginalArrivalTime: 14 Sep 2012 14:02:14.0797 (UTC)
	FILETIME=[8B3B53D0:01CD9281]
X-MC-Unique: 112091415021705701
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linaro-dev@lists.linaro.org" <linaro-dev@lists.linaro.org>,
	"Ian.Campbell@citrix.com" <Ian.Campbell@citrix.com>,
	"arnd@arndb.de" <arnd@arndb.de>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
	Catalin Marinas <Catalin.Marinas@arm.com>, "tim@xen.org" <tim@xen.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux@arm.linux.org.uk" <linux@arm.linux.org.uk>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Xen-devel] [PATCH v4 16/24] xen: clear IRQ_NOAUTOEN and
	IRQ_NOREQUEST
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/09/12 12:13, Stefano Stabellini wrote:
> Reset the IRQ_NOAUTOEN and IRQ_NOREQUEST flags that are enabled by
> default on ARM. If IRQ_NOAUTOEN is set, __setup_irq doesn't call
> irq_startup, that is responsible for calling irq_unmask at startup time.
> As a result event channels remain masked.
> 
> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> ---
>  drivers/xen/events.c |    1 +
>  1 files changed, 1 insertions(+), 0 deletions(-)
> 
> diff --git a/drivers/xen/events.c b/drivers/xen/events.c
> index 5ecb596..8ffb7b7 100644
> --- a/drivers/xen/events.c
> +++ b/drivers/xen/events.c
> @@ -836,6 +836,7 @@ int bind_evtchn_to_irq(unsigned int evtchn)
>  		struct irq_info *info = info_for_irq(irq);
>  		WARN_ON(info == NULL || info->type != IRQT_EVTCHN);
>  	}
> +	irq_clear_status_flags(irq, IRQ_NOREQUEST|IRQ_NOAUTOEN);

This one just sent a shiver down my spine. Are you doing this for a PPI?

	M.
-- 
Jazz is not dead. It just smells funny...


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 14 14:03:44 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 14:03:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TCWUQ-0006vR-2n; Fri, 14 Sep 2012 14:03: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 1TCWUO-0006vB-91
	for xen-devel@lists.xensource.com; Fri, 14 Sep 2012 14:03:24 +0000
Received: from [85.158.143.35:25613] by server-1.bemta-4.messagelabs.com id
	21/83-12504-B2933505; Fri, 14 Sep 2012 14:03:23 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1347631399!10175578!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDkyOTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28730 invoked from network); 14 Sep 2012 14:03:19 -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;
	14 Sep 2012 14:03:19 -0000
X-IronPort-AV: E=Sophos;i="4.80,423,1344211200"; d="scan'208";a="14548302"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Sep 2012 14:03: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.279.1; Fri, 14 Sep 2012 15:03:18 +0100
Date: Fri, 14 Sep 2012 15:02:35 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Marc Zyngier <marc.zyngier@arm.com>
In-Reply-To: <50533500.2020606@arm.com>
Message-ID: <alpine.DEB.2.02.1209141458340.29232@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1209141145150.29232@kaball.uk.xensource.com>
	<1347621207-11294-2-git-send-email-stefano.stabellini@eu.citrix.com>
	<50533500.2020606@arm.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: Dave Martin <dave.martin@linaro.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linaro-dev@lists.linaro.org" <linaro-dev@lists.linaro.org>,
	Ian Campbell <Ian.Campbell@citrix.com>, "arnd@arndb.de" <arnd@arndb.de>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
	Catalin Marinas <Catalin.Marinas@arm.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"Tim \(Xen.org\)" <tim@xen.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux@arm.linux.org.uk" <linux@arm.linux.org.uk>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Xen-devel] [PATCH v4 02/24] xen/arm: hypercalls
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 14 Sep 2012, Marc Zyngier wrote:
> On 14/09/12 12:13, Stefano Stabellini wrote:
> > Use r12 to pass the hypercall number to the hypervisor.
> > 
> > We need a register to pass the hypercall number because we might not
> > know it at compile time and HVC only takes an immediate argument.
> > 
> > Among the available registers r12 seems to be the best choice because it
> > is defined as "intra-procedure call scratch register".
> > 
> > Use the ISS to pass an hypervisor specific tag.
> > 
> > 
> > Changes in v2:
> > - define an HYPERCALL macro for 5 arguments hypercall wrappers, even if
> > at the moment is unused;
> > - use ldm instead of pop;
> > - fix up comments.
> > 
> > 
> > Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> > ---
> >  arch/arm/include/asm/xen/hypercall.h |   50 ++++++++++++++++
> >  arch/arm/xen/Makefile                |    2 +-
> >  arch/arm/xen/hypercall.S             |  106 ++++++++++++++++++++++++++++++++++
> >  3 files changed, 157 insertions(+), 1 deletions(-)
> >  create mode 100644 arch/arm/include/asm/xen/hypercall.h
> >  create mode 100644 arch/arm/xen/hypercall.S
> > 
> > diff --git a/arch/arm/include/asm/xen/hypercall.h b/arch/arm/include/asm/xen/hypercall.h
> > new file mode 100644
> > index 0000000..4ac0624
> > --- /dev/null
> > +++ b/arch/arm/include/asm/xen/hypercall.h
> > @@ -0,0 +1,50 @@
> > +/******************************************************************************
> > + * hypercall.h
> > + *
> > + * Linux-specific hypervisor handling.
> > + *
> > + * Stefano Stabellini <stefano.stabellini@eu.citrix.com>, Citrix, 2012
> > + *
> > + * 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.
> > + */
> > +
> > +#ifndef _ASM_ARM_XEN_HYPERCALL_H
> > +#define _ASM_ARM_XEN_HYPERCALL_H
> > +
> > +#include <xen/interface/xen.h>
> > +
> > +long privcmd_call(unsigned call, unsigned long a1,
> > +		unsigned long a2, unsigned long a3,
> > +		unsigned long a4, unsigned long a5);
> > +int HYPERVISOR_xen_version(int cmd, void *arg);
> > +int HYPERVISOR_console_io(int cmd, int count, char *str);
> > +int HYPERVISOR_grant_table_op(unsigned int cmd, void *uop, unsigned int count);
> > +int HYPERVISOR_sched_op(int cmd, void *arg);
> > +int HYPERVISOR_event_channel_op(int cmd, void *arg);
> > +unsigned long HYPERVISOR_hvm_op(int op, void *arg);
> > +int HYPERVISOR_memory_op(unsigned int cmd, void *arg);
> > +int HYPERVISOR_physdev_op(int cmd, void *arg);
> > +
> > +#endif /* _ASM_ARM_XEN_HYPERCALL_H */
> > diff --git a/arch/arm/xen/Makefile b/arch/arm/xen/Makefile
> > index 0bad594..b9d6acc 100644
> > --- a/arch/arm/xen/Makefile
> > +++ b/arch/arm/xen/Makefile
> > @@ -1 +1 @@
> > -obj-y		:= enlighten.o
> > +obj-y		:= enlighten.o hypercall.o
> > diff --git a/arch/arm/xen/hypercall.S b/arch/arm/xen/hypercall.S
> > new file mode 100644
> > index 0000000..074f5ed
> > --- /dev/null
> > +++ b/arch/arm/xen/hypercall.S
> > @@ -0,0 +1,106 @@
> > +/******************************************************************************
> > + * hypercall.S
> > + *
> > + * Xen hypercall wrappers
> > + *
> > + * Stefano Stabellini <stefano.stabellini@eu.citrix.com>, Citrix, 2012
> > + *
> > + * 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.
> > + */
> > +
> > +/*
> > + * The Xen hypercall calling convention is very similar to the ARM
> > + * procedure calling convention: the first paramter is passed in r0, the
> > + * second in r1, the third in r2 and the fourth in r3. Considering that
> > + * Xen hypercalls have 5 arguments at most, the fifth paramter is passed
> > + * in r4, differently from the procedure calling convention of using the
> > + * stack for that case.
> > + *
> > + * The hypercall number is passed in r12.
> > + *
> > + * The return value is in r0.
> > + *
> > + * The hvc ISS is required to be 0xEA1, that is the Xen specific ARM
> > + * hypercall tag.
> > + */
> > +
> > +#include <linux/linkage.h>
> > +#include <asm/assembler.h>
> > +#include <xen/interface/xen.h>
> > +
> > +
> > +/* HVC 0xEA1 */
> > +#ifdef CONFIG_THUMB2_KERNEL
> > +#define xen_hvc .word 0xf7e08ea1
> > +#else
> > +#define xen_hvc .word 0xe140ea71
> > +#endif
> 
> You should consider using Dave Martin's opcode injection series for
> that. The patches are already in Russell's for-next branch.

I am all for using Dave's patches and I have even already sent a patch
to change the wrappers to use __HVC:

http://marc.info/?l=linux-kernel&m=134513261623427&w=2

I have only temporarely dropped it, only to reduce the amount of
external dependencies of this series. It already depends on Konrad's
stable/for-linus-3.7, so I would rather send this patch out later on its
own...

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 14 14:03:44 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 14:03:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TCWUQ-0006vR-2n; Fri, 14 Sep 2012 14:03: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 1TCWUO-0006vB-91
	for xen-devel@lists.xensource.com; Fri, 14 Sep 2012 14:03:24 +0000
Received: from [85.158.143.35:25613] by server-1.bemta-4.messagelabs.com id
	21/83-12504-B2933505; Fri, 14 Sep 2012 14:03:23 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1347631399!10175578!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDkyOTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28730 invoked from network); 14 Sep 2012 14:03:19 -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;
	14 Sep 2012 14:03:19 -0000
X-IronPort-AV: E=Sophos;i="4.80,423,1344211200"; d="scan'208";a="14548302"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Sep 2012 14:03: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.279.1; Fri, 14 Sep 2012 15:03:18 +0100
Date: Fri, 14 Sep 2012 15:02:35 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Marc Zyngier <marc.zyngier@arm.com>
In-Reply-To: <50533500.2020606@arm.com>
Message-ID: <alpine.DEB.2.02.1209141458340.29232@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1209141145150.29232@kaball.uk.xensource.com>
	<1347621207-11294-2-git-send-email-stefano.stabellini@eu.citrix.com>
	<50533500.2020606@arm.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: Dave Martin <dave.martin@linaro.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linaro-dev@lists.linaro.org" <linaro-dev@lists.linaro.org>,
	Ian Campbell <Ian.Campbell@citrix.com>, "arnd@arndb.de" <arnd@arndb.de>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
	Catalin Marinas <Catalin.Marinas@arm.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"Tim \(Xen.org\)" <tim@xen.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux@arm.linux.org.uk" <linux@arm.linux.org.uk>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Xen-devel] [PATCH v4 02/24] xen/arm: hypercalls
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 14 Sep 2012, Marc Zyngier wrote:
> On 14/09/12 12:13, Stefano Stabellini wrote:
> > Use r12 to pass the hypercall number to the hypervisor.
> > 
> > We need a register to pass the hypercall number because we might not
> > know it at compile time and HVC only takes an immediate argument.
> > 
> > Among the available registers r12 seems to be the best choice because it
> > is defined as "intra-procedure call scratch register".
> > 
> > Use the ISS to pass an hypervisor specific tag.
> > 
> > 
> > Changes in v2:
> > - define an HYPERCALL macro for 5 arguments hypercall wrappers, even if
> > at the moment is unused;
> > - use ldm instead of pop;
> > - fix up comments.
> > 
> > 
> > Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> > ---
> >  arch/arm/include/asm/xen/hypercall.h |   50 ++++++++++++++++
> >  arch/arm/xen/Makefile                |    2 +-
> >  arch/arm/xen/hypercall.S             |  106 ++++++++++++++++++++++++++++++++++
> >  3 files changed, 157 insertions(+), 1 deletions(-)
> >  create mode 100644 arch/arm/include/asm/xen/hypercall.h
> >  create mode 100644 arch/arm/xen/hypercall.S
> > 
> > diff --git a/arch/arm/include/asm/xen/hypercall.h b/arch/arm/include/asm/xen/hypercall.h
> > new file mode 100644
> > index 0000000..4ac0624
> > --- /dev/null
> > +++ b/arch/arm/include/asm/xen/hypercall.h
> > @@ -0,0 +1,50 @@
> > +/******************************************************************************
> > + * hypercall.h
> > + *
> > + * Linux-specific hypervisor handling.
> > + *
> > + * Stefano Stabellini <stefano.stabellini@eu.citrix.com>, Citrix, 2012
> > + *
> > + * 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.
> > + */
> > +
> > +#ifndef _ASM_ARM_XEN_HYPERCALL_H
> > +#define _ASM_ARM_XEN_HYPERCALL_H
> > +
> > +#include <xen/interface/xen.h>
> > +
> > +long privcmd_call(unsigned call, unsigned long a1,
> > +		unsigned long a2, unsigned long a3,
> > +		unsigned long a4, unsigned long a5);
> > +int HYPERVISOR_xen_version(int cmd, void *arg);
> > +int HYPERVISOR_console_io(int cmd, int count, char *str);
> > +int HYPERVISOR_grant_table_op(unsigned int cmd, void *uop, unsigned int count);
> > +int HYPERVISOR_sched_op(int cmd, void *arg);
> > +int HYPERVISOR_event_channel_op(int cmd, void *arg);
> > +unsigned long HYPERVISOR_hvm_op(int op, void *arg);
> > +int HYPERVISOR_memory_op(unsigned int cmd, void *arg);
> > +int HYPERVISOR_physdev_op(int cmd, void *arg);
> > +
> > +#endif /* _ASM_ARM_XEN_HYPERCALL_H */
> > diff --git a/arch/arm/xen/Makefile b/arch/arm/xen/Makefile
> > index 0bad594..b9d6acc 100644
> > --- a/arch/arm/xen/Makefile
> > +++ b/arch/arm/xen/Makefile
> > @@ -1 +1 @@
> > -obj-y		:= enlighten.o
> > +obj-y		:= enlighten.o hypercall.o
> > diff --git a/arch/arm/xen/hypercall.S b/arch/arm/xen/hypercall.S
> > new file mode 100644
> > index 0000000..074f5ed
> > --- /dev/null
> > +++ b/arch/arm/xen/hypercall.S
> > @@ -0,0 +1,106 @@
> > +/******************************************************************************
> > + * hypercall.S
> > + *
> > + * Xen hypercall wrappers
> > + *
> > + * Stefano Stabellini <stefano.stabellini@eu.citrix.com>, Citrix, 2012
> > + *
> > + * 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.
> > + */
> > +
> > +/*
> > + * The Xen hypercall calling convention is very similar to the ARM
> > + * procedure calling convention: the first paramter is passed in r0, the
> > + * second in r1, the third in r2 and the fourth in r3. Considering that
> > + * Xen hypercalls have 5 arguments at most, the fifth paramter is passed
> > + * in r4, differently from the procedure calling convention of using the
> > + * stack for that case.
> > + *
> > + * The hypercall number is passed in r12.
> > + *
> > + * The return value is in r0.
> > + *
> > + * The hvc ISS is required to be 0xEA1, that is the Xen specific ARM
> > + * hypercall tag.
> > + */
> > +
> > +#include <linux/linkage.h>
> > +#include <asm/assembler.h>
> > +#include <xen/interface/xen.h>
> > +
> > +
> > +/* HVC 0xEA1 */
> > +#ifdef CONFIG_THUMB2_KERNEL
> > +#define xen_hvc .word 0xf7e08ea1
> > +#else
> > +#define xen_hvc .word 0xe140ea71
> > +#endif
> 
> You should consider using Dave Martin's opcode injection series for
> that. The patches are already in Russell's for-next branch.

I am all for using Dave's patches and I have even already sent a patch
to change the wrappers to use __HVC:

http://marc.info/?l=linux-kernel&m=134513261623427&w=2

I have only temporarely dropped it, only to reduce the amount of
external dependencies of this series. It already depends on Konrad's
stable/for-linus-3.7, so I would rather send this patch out later on its
own...

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 14 14:06:21 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 14:06:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TCWX2-0007Ac-Lq; Fri, 14 Sep 2012 14:06:08 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <marc.zyngier@arm.com>) id 1TCWX1-0007AA-6n
	for xen-devel@lists.xensource.com; Fri, 14 Sep 2012 14:06:07 +0000
X-Env-Sender: marc.zyngier@arm.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1347631560!9760917!1
X-Originating-IP: [91.220.42.44]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogOTEuMjIwLjQyLjQ0ID0+IDI5NDIyMA==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31334 invoked from network); 14 Sep 2012 14:06:00 -0000
Received: from service87.mimecast.com (HELO service87.mimecast.com)
	(91.220.42.44) by server-9.tower-27.messagelabs.com with SMTP;
	14 Sep 2012 14:06:00 -0000
Received: from cam-owa1.Emea.Arm.com (fw-tnat.cambridge.arm.com
	[217.140.96.21]) by service87.mimecast.com;
	Fri, 14 Sep 2012 15:06:00 +0100
Received: from [10.1.70.21] ([10.1.255.212]) by cam-owa1.Emea.Arm.com with
	Microsoft SMTPSVC(6.0.3790.0); Fri, 14 Sep 2012 15:05:58 +0100
Message-ID: <505339C5.60907@arm.com>
Date: Fri, 14 Sep 2012 15:05:57 +0100
From: Marc Zyngier <marc.zyngier@arm.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:14.0) Gecko/20120714 Thunderbird/14.0
MIME-Version: 1.0
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.02.1209141145150.29232@kaball.uk.xensource.com>
	<1347621207-11294-2-git-send-email-stefano.stabellini@eu.citrix.com>
	<50533500.2020606@arm.com>
	<alpine.DEB.2.02.1209141458340.29232@kaball.uk.xensource.com>
In-Reply-To: <alpine.DEB.2.02.1209141458340.29232@kaball.uk.xensource.com>
X-Enigmail-Version: 1.5a1pre
X-OriginalArrivalTime: 14 Sep 2012 14:05:58.0826 (UTC)
	FILETIME=[10C370A0:01CD9282]
X-MC-Unique: 112091415060009001
Cc: Dave Martin <dave.martin@linaro.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linaro-dev@lists.linaro.org" <linaro-dev@lists.linaro.org>,
	Ian Campbell <Ian.Campbell@citrix.com>, "arnd@arndb.de" <arnd@arndb.de>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
	Catalin Marinas <Catalin.Marinas@arm.com>, "Tim \(Xen.org\)" <tim@xen.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux@arm.linux.org.uk" <linux@arm.linux.org.uk>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Xen-devel] [PATCH v4 02/24] xen/arm: hypercalls
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 14/09/12 15:02, Stefano Stabellini wrote:
> On Fri, 14 Sep 2012, Marc Zyngier wrote:
>>> +/* HVC 0xEA1 */
>>> +#ifdef CONFIG_THUMB2_KERNEL
>>> +#define xen_hvc .word 0xf7e08ea1
>>> +#else
>>> +#define xen_hvc .word 0xe140ea71
>>> +#endif
>>
>> You should consider using Dave Martin's opcode injection series for
>> that. The patches are already in Russell's for-next branch.
> 
> I am all for using Dave's patches and I have even already sent a patch
> to change the wrappers to use __HVC:
> 
> http://marc.info/?l=linux-kernel&m=134513261623427&w=2
> 
> I have only temporarely dropped it, only to reduce the amount of
> external dependencies of this series. It already depends on Konrad's
> stable/for-linus-3.7, so I would rather send this patch out later on its
> own...

Fair enough. As long as there's a plan to fix this soon enough, it
should be alright.

	M.
-- 
Jazz is not dead. It just smells funny...


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 14 14:06:21 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 14:06:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TCWX2-0007Ac-Lq; Fri, 14 Sep 2012 14:06:08 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <marc.zyngier@arm.com>) id 1TCWX1-0007AA-6n
	for xen-devel@lists.xensource.com; Fri, 14 Sep 2012 14:06:07 +0000
X-Env-Sender: marc.zyngier@arm.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1347631560!9760917!1
X-Originating-IP: [91.220.42.44]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogOTEuMjIwLjQyLjQ0ID0+IDI5NDIyMA==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31334 invoked from network); 14 Sep 2012 14:06:00 -0000
Received: from service87.mimecast.com (HELO service87.mimecast.com)
	(91.220.42.44) by server-9.tower-27.messagelabs.com with SMTP;
	14 Sep 2012 14:06:00 -0000
Received: from cam-owa1.Emea.Arm.com (fw-tnat.cambridge.arm.com
	[217.140.96.21]) by service87.mimecast.com;
	Fri, 14 Sep 2012 15:06:00 +0100
Received: from [10.1.70.21] ([10.1.255.212]) by cam-owa1.Emea.Arm.com with
	Microsoft SMTPSVC(6.0.3790.0); Fri, 14 Sep 2012 15:05:58 +0100
Message-ID: <505339C5.60907@arm.com>
Date: Fri, 14 Sep 2012 15:05:57 +0100
From: Marc Zyngier <marc.zyngier@arm.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:14.0) Gecko/20120714 Thunderbird/14.0
MIME-Version: 1.0
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.02.1209141145150.29232@kaball.uk.xensource.com>
	<1347621207-11294-2-git-send-email-stefano.stabellini@eu.citrix.com>
	<50533500.2020606@arm.com>
	<alpine.DEB.2.02.1209141458340.29232@kaball.uk.xensource.com>
In-Reply-To: <alpine.DEB.2.02.1209141458340.29232@kaball.uk.xensource.com>
X-Enigmail-Version: 1.5a1pre
X-OriginalArrivalTime: 14 Sep 2012 14:05:58.0826 (UTC)
	FILETIME=[10C370A0:01CD9282]
X-MC-Unique: 112091415060009001
Cc: Dave Martin <dave.martin@linaro.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linaro-dev@lists.linaro.org" <linaro-dev@lists.linaro.org>,
	Ian Campbell <Ian.Campbell@citrix.com>, "arnd@arndb.de" <arnd@arndb.de>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
	Catalin Marinas <Catalin.Marinas@arm.com>, "Tim \(Xen.org\)" <tim@xen.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux@arm.linux.org.uk" <linux@arm.linux.org.uk>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Xen-devel] [PATCH v4 02/24] xen/arm: hypercalls
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 14/09/12 15:02, Stefano Stabellini wrote:
> On Fri, 14 Sep 2012, Marc Zyngier wrote:
>>> +/* HVC 0xEA1 */
>>> +#ifdef CONFIG_THUMB2_KERNEL
>>> +#define xen_hvc .word 0xf7e08ea1
>>> +#else
>>> +#define xen_hvc .word 0xe140ea71
>>> +#endif
>>
>> You should consider using Dave Martin's opcode injection series for
>> that. The patches are already in Russell's for-next branch.
> 
> I am all for using Dave's patches and I have even already sent a patch
> to change the wrappers to use __HVC:
> 
> http://marc.info/?l=linux-kernel&m=134513261623427&w=2
> 
> I have only temporarely dropped it, only to reduce the amount of
> external dependencies of this series. It already depends on Konrad's
> stable/for-linus-3.7, so I would rather send this patch out later on its
> own...

Fair enough. As long as there's a plan to fix this soon enough, it
should be alright.

	M.
-- 
Jazz is not dead. It just smells funny...


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 14 14:14:48 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 14:14:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TCWf9-0007T6-Kv; Fri, 14 Sep 2012 14:14:31 +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 1TCWf8-0007T1-J3
	for xen-devel@lists.xensource.com; Fri, 14 Sep 2012 14:14:30 +0000
Received: from [85.158.139.83:8501] by server-5.bemta-5.messagelabs.com id
	EF/C8-30514-5CB33505; Fri, 14 Sep 2012 14:14:29 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1347632068!23186831!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDkyOTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12041 invoked from network); 14 Sep 2012 14:14:28 -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;
	14 Sep 2012 14:14:28 -0000
X-IronPort-AV: E=Sophos;i="4.80,423,1344211200"; d="scan'208";a="14548646"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Sep 2012 14:14: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.279.1; Fri, 14 Sep 2012 15:14:21 +0100
Date: Fri, 14 Sep 2012 15:13:38 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Marc Zyngier <marc.zyngier@arm.com>
In-Reply-To: <505338E6.4050504@arm.com>
Message-ID: <alpine.DEB.2.02.1209141508130.29232@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1209141145150.29232@kaball.uk.xensource.com>
	<1347621207-11294-16-git-send-email-stefano.stabellini@eu.citrix.com>
	<505338E6.4050504@arm.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>,
	"linaro-dev@lists.linaro.org" <linaro-dev@lists.linaro.org>,
	Ian Campbell <Ian.Campbell@citrix.com>, "arnd@arndb.de" <arnd@arndb.de>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
	Catalin Marinas <Catalin.Marinas@arm.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"Tim \(Xen.org\)" <tim@xen.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux@arm.linux.org.uk" <linux@arm.linux.org.uk>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Xen-devel] [PATCH v4 16/24] xen: clear IRQ_NOAUTOEN and
	IRQ_NOREQUEST
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 14 Sep 2012, Marc Zyngier wrote:
> On 14/09/12 12:13, Stefano Stabellini wrote:
> > Reset the IRQ_NOAUTOEN and IRQ_NOREQUEST flags that are enabled by
> > default on ARM. If IRQ_NOAUTOEN is set, __setup_irq doesn't call
> > irq_startup, that is responsible for calling irq_unmask at startup time.
> > As a result event channels remain masked.
> > 
> > Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> > Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> > ---
> >  drivers/xen/events.c |    1 +
> >  1 files changed, 1 insertions(+), 0 deletions(-)
> > 
> > diff --git a/drivers/xen/events.c b/drivers/xen/events.c
> > index 5ecb596..8ffb7b7 100644
> > --- a/drivers/xen/events.c
> > +++ b/drivers/xen/events.c
> > @@ -836,6 +836,7 @@ int bind_evtchn_to_irq(unsigned int evtchn)
> >  		struct irq_info *info = info_for_irq(irq);
> >  		WARN_ON(info == NULL || info->type != IRQT_EVTCHN);
> >  	}
> > +	irq_clear_status_flags(irq, IRQ_NOREQUEST|IRQ_NOAUTOEN);
> 
> This one just sent a shiver down my spine. Are you doing this for a PPI?

Not really: even though there is just one source of event notifications
(that is a PPI), we have many event channels. When a domain receives a
notification (via the PPI), it checks on a bitmask to which event channel
it corresponds. From the Linux point of view every event channel is a
Linux irq belonging to the xen_dynamic_chip (see
drivers/xen/events.c:xen_dynamic_chip).

So here I am not doing this for the one PPI, but I am doing this for
every Linux irq (of chip xen_dynamic_chip) that represents an event
channel.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 14 14:14:48 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 14:14:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TCWf9-0007T6-Kv; Fri, 14 Sep 2012 14:14:31 +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 1TCWf8-0007T1-J3
	for xen-devel@lists.xensource.com; Fri, 14 Sep 2012 14:14:30 +0000
Received: from [85.158.139.83:8501] by server-5.bemta-5.messagelabs.com id
	EF/C8-30514-5CB33505; Fri, 14 Sep 2012 14:14:29 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1347632068!23186831!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDkyOTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12041 invoked from network); 14 Sep 2012 14:14:28 -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;
	14 Sep 2012 14:14:28 -0000
X-IronPort-AV: E=Sophos;i="4.80,423,1344211200"; d="scan'208";a="14548646"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Sep 2012 14:14: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.279.1; Fri, 14 Sep 2012 15:14:21 +0100
Date: Fri, 14 Sep 2012 15:13:38 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Marc Zyngier <marc.zyngier@arm.com>
In-Reply-To: <505338E6.4050504@arm.com>
Message-ID: <alpine.DEB.2.02.1209141508130.29232@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1209141145150.29232@kaball.uk.xensource.com>
	<1347621207-11294-16-git-send-email-stefano.stabellini@eu.citrix.com>
	<505338E6.4050504@arm.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>,
	"linaro-dev@lists.linaro.org" <linaro-dev@lists.linaro.org>,
	Ian Campbell <Ian.Campbell@citrix.com>, "arnd@arndb.de" <arnd@arndb.de>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
	Catalin Marinas <Catalin.Marinas@arm.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"Tim \(Xen.org\)" <tim@xen.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux@arm.linux.org.uk" <linux@arm.linux.org.uk>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Xen-devel] [PATCH v4 16/24] xen: clear IRQ_NOAUTOEN and
	IRQ_NOREQUEST
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 14 Sep 2012, Marc Zyngier wrote:
> On 14/09/12 12:13, Stefano Stabellini wrote:
> > Reset the IRQ_NOAUTOEN and IRQ_NOREQUEST flags that are enabled by
> > default on ARM. If IRQ_NOAUTOEN is set, __setup_irq doesn't call
> > irq_startup, that is responsible for calling irq_unmask at startup time.
> > As a result event channels remain masked.
> > 
> > Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> > Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> > ---
> >  drivers/xen/events.c |    1 +
> >  1 files changed, 1 insertions(+), 0 deletions(-)
> > 
> > diff --git a/drivers/xen/events.c b/drivers/xen/events.c
> > index 5ecb596..8ffb7b7 100644
> > --- a/drivers/xen/events.c
> > +++ b/drivers/xen/events.c
> > @@ -836,6 +836,7 @@ int bind_evtchn_to_irq(unsigned int evtchn)
> >  		struct irq_info *info = info_for_irq(irq);
> >  		WARN_ON(info == NULL || info->type != IRQT_EVTCHN);
> >  	}
> > +	irq_clear_status_flags(irq, IRQ_NOREQUEST|IRQ_NOAUTOEN);
> 
> This one just sent a shiver down my spine. Are you doing this for a PPI?

Not really: even though there is just one source of event notifications
(that is a PPI), we have many event channels. When a domain receives a
notification (via the PPI), it checks on a bitmask to which event channel
it corresponds. From the Linux point of view every event channel is a
Linux irq belonging to the xen_dynamic_chip (see
drivers/xen/events.c:xen_dynamic_chip).

So here I am not doing this for the one PPI, but I am doing this for
every Linux irq (of chip xen_dynamic_chip) that represents an event
channel.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 14 14:20:56 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 14: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 1TCWl6-0007eS-Ez; Fri, 14 Sep 2012 14:20: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 1TCWl5-0007eM-54
	for xen-devel@lists.xen.org; Fri, 14 Sep 2012 14:20:39 +0000
Received: from [85.158.138.51:63416] by server-11.bemta-3.messagelabs.com id
	CF/33-30250-63D33505; Fri, 14 Sep 2012 14:20:38 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1347632437!30554035!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10264 invoked from network); 14 Sep 2012 14:20:37 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-2.tower-174.messagelabs.com with SMTP;
	14 Sep 2012 14:20:37 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 14 Sep 2012 15:20:37 +0100
Message-Id: <5053598C020000780009B7A4@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 14 Sep 2012 15:21:32 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Daniel De Graaf" <dgdegra@tycho.nsa.gov>
References: <1347465586-20009-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1347465586-20009-20-git-send-email-dgdegra@tycho.nsa.gov>
	<5051AED7020000780009AFC3@nat28.tlf.novell.com>
	<5051E3AC.2060700@tycho.nsa.gov>
	<50520634020000780009B162@nat28.tlf.novell.com>
	<5051ECC7.7050901@tycho.nsa.gov>
	<5052121F020000780009B1E9@nat28.tlf.novell.com>
	<50520DFF.4030505@tycho.nsa.gov>
	<50530CF0020000780009B49B@nat28.tlf.novell.com>
	<50533330.9020600@tycho.nsa.gov>
In-Reply-To: <50533330.9020600@tycho.nsa.gov>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Tim Deegan <tim@xen.org>, Keir Fraser <keir@xen.org>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 19/22] arch/x86: check remote MMIO remap
 permissions
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.09.12 at 15:37, Daniel De Graaf <dgdegra@tycho.nsa.gov> wrote:
> On 09/14/2012 04:54 AM, Jan Beulich wrote:
>>>>> On 13.09.12 at 18:46, Daniel De Graaf <dgdegra@tycho.nsa.gov> wrote:
>>> For this example, assume domain A has access to map domain B's memory
>>> read-only. Domain B has access to a device with MMIO where reads to the
>>> device's memory cause state changes - an example of such as device is a
>>> TPM, where replies are read by repeated reads to a single 4-byte 
>>> address. Domain A does not have access to this device, and would like to
>>> maliciously interfere with the device.
>>>
>>> If domain A maps the MMIO page from domain B using pg_owner == domB, the
>>> iomem_access_permitted check will be done from domain B's perspective. 
>>> While this is needed when domain A is mapping pages on behalf of domB, 
>>> it is not sufficient when attempting to constrain domain A's access. 
>>>
>>> These checks only apply to MMIO, so the condition on line 735 will
>>> evaluate to true (!mfn_valid || real_pg_owner == dom_io).
>>>
>>> The (existing) check on domain B's MMIO access is:
>>>         if ( !iomem_access_permitted(pg_owner, mfn, mfn) )
>>>
>>> This patch adds a check on domain A:
>>>         if ( !iomem_access_permitted(curr->domain, mfn, mfn) )
>> 
>> So then I think I was right suggesting that the second check
>> should be done at the same place where the first one is, not
>> outside/after the MMIO conditional.
> 
> That is where I am doing the second check; it is not outside the MMIO
> conditional (which ends 8 lines after the inserted check).

Then I must have got the context wrong when looking for the
insertion place. Checking... Indeed, I didn't pay close enough
attention. Sorry for all the complaints then.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 14 14:20:56 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 14: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 1TCWl6-0007eS-Ez; Fri, 14 Sep 2012 14:20: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 1TCWl5-0007eM-54
	for xen-devel@lists.xen.org; Fri, 14 Sep 2012 14:20:39 +0000
Received: from [85.158.138.51:63416] by server-11.bemta-3.messagelabs.com id
	CF/33-30250-63D33505; Fri, 14 Sep 2012 14:20:38 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1347632437!30554035!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10264 invoked from network); 14 Sep 2012 14:20:37 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-2.tower-174.messagelabs.com with SMTP;
	14 Sep 2012 14:20:37 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 14 Sep 2012 15:20:37 +0100
Message-Id: <5053598C020000780009B7A4@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 14 Sep 2012 15:21:32 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Daniel De Graaf" <dgdegra@tycho.nsa.gov>
References: <1347465586-20009-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1347465586-20009-20-git-send-email-dgdegra@tycho.nsa.gov>
	<5051AED7020000780009AFC3@nat28.tlf.novell.com>
	<5051E3AC.2060700@tycho.nsa.gov>
	<50520634020000780009B162@nat28.tlf.novell.com>
	<5051ECC7.7050901@tycho.nsa.gov>
	<5052121F020000780009B1E9@nat28.tlf.novell.com>
	<50520DFF.4030505@tycho.nsa.gov>
	<50530CF0020000780009B49B@nat28.tlf.novell.com>
	<50533330.9020600@tycho.nsa.gov>
In-Reply-To: <50533330.9020600@tycho.nsa.gov>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Tim Deegan <tim@xen.org>, Keir Fraser <keir@xen.org>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 19/22] arch/x86: check remote MMIO remap
 permissions
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.09.12 at 15:37, Daniel De Graaf <dgdegra@tycho.nsa.gov> wrote:
> On 09/14/2012 04:54 AM, Jan Beulich wrote:
>>>>> On 13.09.12 at 18:46, Daniel De Graaf <dgdegra@tycho.nsa.gov> wrote:
>>> For this example, assume domain A has access to map domain B's memory
>>> read-only. Domain B has access to a device with MMIO where reads to the
>>> device's memory cause state changes - an example of such as device is a
>>> TPM, where replies are read by repeated reads to a single 4-byte 
>>> address. Domain A does not have access to this device, and would like to
>>> maliciously interfere with the device.
>>>
>>> If domain A maps the MMIO page from domain B using pg_owner == domB, the
>>> iomem_access_permitted check will be done from domain B's perspective. 
>>> While this is needed when domain A is mapping pages on behalf of domB, 
>>> it is not sufficient when attempting to constrain domain A's access. 
>>>
>>> These checks only apply to MMIO, so the condition on line 735 will
>>> evaluate to true (!mfn_valid || real_pg_owner == dom_io).
>>>
>>> The (existing) check on domain B's MMIO access is:
>>>         if ( !iomem_access_permitted(pg_owner, mfn, mfn) )
>>>
>>> This patch adds a check on domain A:
>>>         if ( !iomem_access_permitted(curr->domain, mfn, mfn) )
>> 
>> So then I think I was right suggesting that the second check
>> should be done at the same place where the first one is, not
>> outside/after the MMIO conditional.
> 
> That is where I am doing the second check; it is not outside the MMIO
> conditional (which ends 8 lines after the inserted check).

Then I must have got the context wrong when looking for the
insertion place. Checking... Indeed, I didn't pay close enough
attention. Sorry for all the complaints then.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 14 14:21:19 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 14:21:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TCWlU-0007gM-Uh; Fri, 14 Sep 2012 14:21:04 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <marc.zyngier@arm.com>) id 1TCWlS-0007g4-Qo
	for xen-devel@lists.xensource.com; Fri, 14 Sep 2012 14:21:03 +0000
Received: from [85.158.139.83:39029] by server-8.bemta-5.messagelabs.com id
	60/32-15219-E4D33505; Fri, 14 Sep 2012 14:21:02 +0000
X-Env-Sender: marc.zyngier@arm.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1347632461!23188222!1
X-Originating-IP: [91.220.42.44]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogOTEuMjIwLjQyLjQ0ID0+IDI5NDIyMA==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12870 invoked from network); 14 Sep 2012 14:21:01 -0000
Received: from service87.mimecast.com (HELO service87.mimecast.com)
	(91.220.42.44) by server-16.tower-182.messagelabs.com with SMTP;
	14 Sep 2012 14:21:01 -0000
Received: from cam-owa1.Emea.Arm.com (fw-tnat.cambridge.arm.com
	[217.140.96.21]) by service87.mimecast.com;
	Fri, 14 Sep 2012 15:21:00 +0100
Received: from [10.1.70.21] ([10.1.255.212]) by cam-owa1.Emea.Arm.com with
	Microsoft SMTPSVC(6.0.3790.0); Fri, 14 Sep 2012 15:20:57 +0100
Message-ID: <50533D46.5000704@arm.com>
Date: Fri, 14 Sep 2012 15:20:54 +0100
From: Marc Zyngier <marc.zyngier@arm.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:14.0) Gecko/20120714 Thunderbird/14.0
MIME-Version: 1.0
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.02.1209141145150.29232@kaball.uk.xensource.com>
	<1347621207-11294-16-git-send-email-stefano.stabellini@eu.citrix.com>
	<505338E6.4050504@arm.com>
	<alpine.DEB.2.02.1209141508130.29232@kaball.uk.xensource.com>
In-Reply-To: <alpine.DEB.2.02.1209141508130.29232@kaball.uk.xensource.com>
X-Enigmail-Version: 1.5a1pre
X-OriginalArrivalTime: 14 Sep 2012 14:20:57.0799 (UTC)
	FILETIME=[2897D570:01CD9284]
X-MC-Unique: 112091415210007201
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linaro-dev@lists.linaro.org" <linaro-dev@lists.linaro.org>,
	Ian Campbell <Ian.Campbell@citrix.com>, "arnd@arndb.de" <arnd@arndb.de>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
	Catalin Marinas <Catalin.Marinas@arm.com>, "Tim \(Xen.org\)" <tim@xen.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux@arm.linux.org.uk" <linux@arm.linux.org.uk>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Xen-devel] [PATCH v4 16/24] xen: clear IRQ_NOAUTOEN and
	IRQ_NOREQUEST
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/09/12 15:13, Stefano Stabellini wrote:
> On Fri, 14 Sep 2012, Marc Zyngier wrote:
>> On 14/09/12 12:13, Stefano Stabellini wrote:
>>> Reset the IRQ_NOAUTOEN and IRQ_NOREQUEST flags that are enabled by
>>> default on ARM. If IRQ_NOAUTOEN is set, __setup_irq doesn't call
>>> irq_startup, that is responsible for calling irq_unmask at startup time.
>>> As a result event channels remain masked.
>>>
>>> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
>>> Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
>>> ---
>>>  drivers/xen/events.c |    1 +
>>>  1 files changed, 1 insertions(+), 0 deletions(-)
>>>
>>> diff --git a/drivers/xen/events.c b/drivers/xen/events.c
>>> index 5ecb596..8ffb7b7 100644
>>> --- a/drivers/xen/events.c
>>> +++ b/drivers/xen/events.c
>>> @@ -836,6 +836,7 @@ int bind_evtchn_to_irq(unsigned int evtchn)
>>>  		struct irq_info *info = info_for_irq(irq);
>>>  		WARN_ON(info == NULL || info->type != IRQT_EVTCHN);
>>>  	}
>>> +	irq_clear_status_flags(irq, IRQ_NOREQUEST|IRQ_NOAUTOEN);
>>
>> This one just sent a shiver down my spine. Are you doing this for a PPI?
> 
> Not really: even though there is just one source of event notifications
> (that is a PPI), we have many event channels. When a domain receives a
> notification (via the PPI), it checks on a bitmask to which event channel
> it corresponds. From the Linux point of view every event channel is a
> Linux irq belonging to the xen_dynamic_chip (see
> drivers/xen/events.c:xen_dynamic_chip).
> 
> So here I am not doing this for the one PPI, but I am doing this for
> every Linux irq (of chip xen_dynamic_chip) that represents an event
> channel.

So this is some sort of secondary interrupt controller, cascaded into
your GIC emulation, and this patch only affects the xen_dynamic_chip?

	M.
-- 
Jazz is not dead. It just smells funny...


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 14 14:21:19 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 14:21:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TCWlU-0007gM-Uh; Fri, 14 Sep 2012 14:21:04 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <marc.zyngier@arm.com>) id 1TCWlS-0007g4-Qo
	for xen-devel@lists.xensource.com; Fri, 14 Sep 2012 14:21:03 +0000
Received: from [85.158.139.83:39029] by server-8.bemta-5.messagelabs.com id
	60/32-15219-E4D33505; Fri, 14 Sep 2012 14:21:02 +0000
X-Env-Sender: marc.zyngier@arm.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1347632461!23188222!1
X-Originating-IP: [91.220.42.44]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogOTEuMjIwLjQyLjQ0ID0+IDI5NDIyMA==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12870 invoked from network); 14 Sep 2012 14:21:01 -0000
Received: from service87.mimecast.com (HELO service87.mimecast.com)
	(91.220.42.44) by server-16.tower-182.messagelabs.com with SMTP;
	14 Sep 2012 14:21:01 -0000
Received: from cam-owa1.Emea.Arm.com (fw-tnat.cambridge.arm.com
	[217.140.96.21]) by service87.mimecast.com;
	Fri, 14 Sep 2012 15:21:00 +0100
Received: from [10.1.70.21] ([10.1.255.212]) by cam-owa1.Emea.Arm.com with
	Microsoft SMTPSVC(6.0.3790.0); Fri, 14 Sep 2012 15:20:57 +0100
Message-ID: <50533D46.5000704@arm.com>
Date: Fri, 14 Sep 2012 15:20:54 +0100
From: Marc Zyngier <marc.zyngier@arm.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:14.0) Gecko/20120714 Thunderbird/14.0
MIME-Version: 1.0
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.02.1209141145150.29232@kaball.uk.xensource.com>
	<1347621207-11294-16-git-send-email-stefano.stabellini@eu.citrix.com>
	<505338E6.4050504@arm.com>
	<alpine.DEB.2.02.1209141508130.29232@kaball.uk.xensource.com>
In-Reply-To: <alpine.DEB.2.02.1209141508130.29232@kaball.uk.xensource.com>
X-Enigmail-Version: 1.5a1pre
X-OriginalArrivalTime: 14 Sep 2012 14:20:57.0799 (UTC)
	FILETIME=[2897D570:01CD9284]
X-MC-Unique: 112091415210007201
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linaro-dev@lists.linaro.org" <linaro-dev@lists.linaro.org>,
	Ian Campbell <Ian.Campbell@citrix.com>, "arnd@arndb.de" <arnd@arndb.de>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
	Catalin Marinas <Catalin.Marinas@arm.com>, "Tim \(Xen.org\)" <tim@xen.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux@arm.linux.org.uk" <linux@arm.linux.org.uk>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Xen-devel] [PATCH v4 16/24] xen: clear IRQ_NOAUTOEN and
	IRQ_NOREQUEST
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/09/12 15:13, Stefano Stabellini wrote:
> On Fri, 14 Sep 2012, Marc Zyngier wrote:
>> On 14/09/12 12:13, Stefano Stabellini wrote:
>>> Reset the IRQ_NOAUTOEN and IRQ_NOREQUEST flags that are enabled by
>>> default on ARM. If IRQ_NOAUTOEN is set, __setup_irq doesn't call
>>> irq_startup, that is responsible for calling irq_unmask at startup time.
>>> As a result event channels remain masked.
>>>
>>> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
>>> Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
>>> ---
>>>  drivers/xen/events.c |    1 +
>>>  1 files changed, 1 insertions(+), 0 deletions(-)
>>>
>>> diff --git a/drivers/xen/events.c b/drivers/xen/events.c
>>> index 5ecb596..8ffb7b7 100644
>>> --- a/drivers/xen/events.c
>>> +++ b/drivers/xen/events.c
>>> @@ -836,6 +836,7 @@ int bind_evtchn_to_irq(unsigned int evtchn)
>>>  		struct irq_info *info = info_for_irq(irq);
>>>  		WARN_ON(info == NULL || info->type != IRQT_EVTCHN);
>>>  	}
>>> +	irq_clear_status_flags(irq, IRQ_NOREQUEST|IRQ_NOAUTOEN);
>>
>> This one just sent a shiver down my spine. Are you doing this for a PPI?
> 
> Not really: even though there is just one source of event notifications
> (that is a PPI), we have many event channels. When a domain receives a
> notification (via the PPI), it checks on a bitmask to which event channel
> it corresponds. From the Linux point of view every event channel is a
> Linux irq belonging to the xen_dynamic_chip (see
> drivers/xen/events.c:xen_dynamic_chip).
> 
> So here I am not doing this for the one PPI, but I am doing this for
> every Linux irq (of chip xen_dynamic_chip) that represents an event
> channel.

So this is some sort of secondary interrupt controller, cascaded into
your GIC emulation, and this patch only affects the xen_dynamic_chip?

	M.
-- 
Jazz is not dead. It just smells funny...


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 14 14:24:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 14:24: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 1TCWoF-0007s2-HJ; Fri, 14 Sep 2012 14:23:55 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1TCWoE-0007rY-6y
	for xen-devel@lists.xen.org; Fri, 14 Sep 2012 14:23:54 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1347632627!1729543!1
X-Originating-IP: [74.125.83.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4750 invoked from network); 14 Sep 2012 14:23:47 -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;
	14 Sep 2012 14:23:47 -0000
Received: by eeke53 with SMTP id e53so2649535eek.32
	for <xen-devel@lists.xen.org>; Fri, 14 Sep 2012 07:23:47 -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=nLJbCaXpFitbSzPmGKlQMnK6Zhz78Tw1m14nOWFdJv0=;
	b=QfO6zUQ8AFK96xVRIYHN0HXL6JJz25HOxI5dSFPUolghlqIDcYq+ebLmLo2bcMmIfp
	f9/R52kKUhFK94Kwc+Kn+O+nuwknjcrN5q5Vxrlfa6oINg/qJzSRDt4ZpoKBd26WvNMB
	dNVDeYVnqsH5Y1B/X0oYA9AzAD3FPrVYdGTlJIQJvnsnZ542wXihjsnYPfsjHm9fGT9c
	GQw9i08dj7c0HR2+HD6cUCzX8f2HZp3hxJ9yh+UdNA2+ztLNEz6DTWd2tws6vjZ8RxB7
	Uylnu88w/UDb61Yl9VVOmoiVeo60CRhgMaBEQxAYaq1TmuWruOlOVDb8yDokBma7W71L
	aSog==
Received: by 10.14.177.193 with SMTP id d41mr3755299eem.19.1347632627033;
	Fri, 14 Sep 2012 07:23:47 -0700 (PDT)
Received: from [192.168.1.3] (host86-184-74-117.range86-184.btcentralplus.com.
	[86.184.74.117])
	by mx.google.com with ESMTPS id a7sm4850507eep.14.2012.09.14.07.23.44
	(version=SSLv3 cipher=OTHER); Fri, 14 Sep 2012 07:23:46 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.33.0.120411
Date: Fri, 14 Sep 2012 15:23:41 +0100
From: Keir Fraser <keir@xen.org>
To: Jan Beulich <JBeulich@suse.com>,
	xen-devel <xen-devel@lists.xen.org>
Message-ID: <CC78FC7D.4BC43%keir@xen.org>
Thread-Topic: [Xen-devel] [PATCH] xenpm: make argument parsing and error
	handling more consistent
Thread-Index: Ac2ShInea1X+CC2cz0CyKhRDiQeukA==
In-Reply-To: <50534722020000780009B70D@nat28.tlf.novell.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] [PATCH] xenpm: make argument parsing and error
 handling more consistent
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 14/09/2012 14:02, "Jan Beulich" <JBeulich@suse.com> wrote:

> Specifically, what values are or aren't accepted as CPU identifier, and
> how the values get interpreted should be consistent across sub-commands
> (intended behavior now: non-negative values are okay, and along with
> omitting the argument, specifying "all" will also be accepted).
> 
> For error handling, error messages should get consistently issued to
> stderr, and the tool should now (hopefully) produce an exit code of
> zero only in the (partial) success case (there may still be a small
> number of questionable cases).
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Acked-by: Keir Fraser <keir@xen.org>

You can apply this one if you get no furthe feedback.

 -- Keir

> --- a/tools/misc/xenpm.c
> +++ b/tools/misc/xenpm.c
> @@ -36,7 +36,7 @@
>  #define CPUFREQ_TURBO_ENABLED       1
>  
>  static xc_interface *xc_handle;
> -static int max_cpu_nr;
> +static unsigned int max_cpu_nr;
>  
>  /* help message */
>  void show_help(void)
> @@ -77,6 +77,33 @@ void help_func(int argc, char *argv[])
>      show_help();
>  }
>  
> +static void parse_cpuid(const char *arg, int *cpuid)
> +{
> +    if ( sscanf(arg, "%d", cpuid) != 1 || *cpuid < 0 )
> +    {
> +        if ( strcasecmp(arg, "all") )
> +        {
> +            fprintf(stderr, "Invalid CPU identifier: '%s'\n", arg);
> +            exit(EINVAL);
> +        }
> +        *cpuid = -1;
> +    }
> +}
> +
> +static void parse_cpuid_and_int(int argc, char *argv[],
> +                                int *cpuid, int *val, const char *what)
> +{
> +    if ( argc > 1 )
> +        parse_cpuid(argv[0], cpuid);
> +
> +    if ( argc == 0 || sscanf(argv[argc > 1], "%d", val) != 1 )
> +    {
> +        fprintf(stderr, argc ? "Invalid %s '%s'\n" : "Missing %s\n",
> +                what, argv[argc > 1]);
> +        exit(EINVAL);
> +    }
> +}
> +
>  static void print_cxstat(int cpuid, struct xc_cx_stat *cxstat)
>  {
>      int i;
> @@ -166,7 +193,8 @@ static int show_cxstat_by_cpuid(xc_inter
>      if ( ret )
>      {
>          if ( ret == -ENODEV )
> -            printf("Either xen cpuidle is disabled or no valid information is
> registered!\n");
> +            fprintf(stderr,
> +                    "Either Xen cpuidle is disabled or no valid information
> is registered!\n");
>          return ret;
>      }
>  
> @@ -181,11 +209,8 @@ void cxstat_func(int argc, char *argv[])
>  {
>      int cpuid = -1;
>  
> -    if ( argc > 0 && sscanf(argv[0], "%d", &cpuid) != 1 )
> -        cpuid = -1;
> -
> -    if ( cpuid >= max_cpu_nr )
> -        cpuid = -1;
> +    if ( argc > 0 )
> +        parse_cpuid(argv[0], &cpuid);
>  
>      show_max_cstate(xc_handle);
>  
> @@ -294,11 +319,8 @@ void pxstat_func(int argc, char *argv[])
>  {
>      int cpuid = -1;
>  
> -    if ( argc > 0 && sscanf(argv[0], "%d", &cpuid) != 1 )
> -        cpuid = -1;
> -
> -    if ( cpuid >= max_cpu_nr )
> -        cpuid = -1;
> +    if ( argc > 0 )
> +        parse_cpuid(argv[0], &cpuid);
>  
>      if ( cpuid < 0 )
>      {
> @@ -338,10 +360,10 @@ static void signal_int_handler(int signo
> goto out;
>      }
>  
> -    if ( gettimeofday(&tv, NULL) == -1 )
> +    if ( gettimeofday(&tv, NULL) )
>      {
>          fprintf(stderr, "failed to get timeofday\n");
> -        goto out ;
> +        goto out;
>      }
>      usec_end = tv.tv_sec * 1000000UL + tv.tv_usec;
>  
> @@ -541,7 +563,7 @@ void start_gather_func(int argc, char *a
>              printf("Timeout set to %d seconds\n", timeout);
>      }
>  
> -    if ( gettimeofday(&tv, NULL) == -1 )
> +    if ( gettimeofday(&tv, NULL) )
>      {
>          fprintf(stderr, "failed to get timeofday\n");
>          return ;
> @@ -766,11 +788,8 @@ void cpufreq_para_func(int argc, char *a
>  {
>      int cpuid = -1;
>  
> -    if ( argc > 0 && sscanf(argv[0], "%d", &cpuid) != 1 )
> -        cpuid = -1;
> -
> -    if ( cpuid >= max_cpu_nr )
> -        cpuid = -1;
> +    if ( argc > 0 )
> +        parse_cpuid(argv[0], &cpuid);
>  
>      if ( cpuid < 0 )
>      {
> @@ -788,26 +807,22 @@ void scaling_max_freq_func(int argc, cha
>  {
>      int cpuid = -1, freq = -1;
>  
> -    if ( (argc >= 2 && (sscanf(argv[1], "%d", &freq) != 1 ||
> -                        sscanf(argv[0], "%d", &cpuid) != 1)) ||
> -         (argc == 1 && sscanf(argv[0], "%d", &freq) != 1 ) ||
> -         argc == 0 )
> -    {
> -        fprintf(stderr, "failed to set scaling max freq\n");
> -        return ;
> -    }
> +    parse_cpuid_and_int(argc, argv, &cpuid, &freq, "frequency");
>  
>      if ( cpuid < 0 )
>      {
>          int i;
>          for ( i = 0; i < max_cpu_nr; i++ )
>              if ( xc_set_cpufreq_para(xc_handle, i, SCALING_MAX_FREQ, freq) )
> -                fprintf(stderr, "[CPU%d] failed to set scaling max freq\n",
> i);
> +                fprintf(stderr,
> +                        "[CPU%d] failed to set scaling max freq (%d - %s)\n",
> +                        i, errno, strerror(errno));
>      }
>      else
>      {
>          if ( xc_set_cpufreq_para(xc_handle, cpuid, SCALING_MAX_FREQ, freq) )
> -            fprintf(stderr, "failed to set scaling max freq\n");
> +            fprintf(stderr, "failed to set scaling max freq (%d - %s)\n",
> +                    errno, strerror(errno));
>      }
>  }
>  
> @@ -815,26 +830,22 @@ void scaling_min_freq_func(int argc, cha
>  {
>      int cpuid = -1, freq = -1;
>  
> -    if ( (argc >= 2 && (sscanf(argv[1], "%d", &freq) != 1 ||
> -                        sscanf(argv[0], "%d", &cpuid) != 1) ) ||
> -         (argc == 1 && sscanf(argv[0], "%d", &freq) != 1 ) ||
> -         argc == 0 )
> -    {
> -        fprintf(stderr, "failed to set scaling min freq\n");
> -        return ;
> -    }
> +    parse_cpuid_and_int(argc, argv, &cpuid, &freq, "frequency");
>  
>      if ( cpuid < 0 )
>      {
>          int i;
>          for ( i = 0; i < max_cpu_nr; i++ )
>              if ( xc_set_cpufreq_para(xc_handle, i, SCALING_MIN_FREQ, freq) )
> -                fprintf(stderr, "[CPU%d] failed to set scaling min freq\n",
> i);
> +                fprintf(stderr,
> +                        "[CPU%d] failed to set scaling min freq (%d - %s)\n",
> +                        i, errno, strerror(errno));
>      }
>      else
>      {
>          if ( xc_set_cpufreq_para(xc_handle, cpuid, SCALING_MIN_FREQ, freq) )
> -            fprintf(stderr, "failed to set scaling min freq\n");
> +            fprintf(stderr, "failed to set scaling min freq (%d - %s)\n",
> +                    errno, strerror(errno));
>      }
>  }
>  
> @@ -842,26 +853,22 @@ void scaling_speed_func(int argc, char *
>  {
>      int cpuid = -1, speed = -1;
>  
> -    if ( (argc >= 2 && (sscanf(argv[1], "%d", &speed) != 1 ||
> -                        sscanf(argv[0], "%d", &cpuid) != 1) ) ||
> -         (argc == 1 && sscanf(argv[0], "%d", &speed) != 1 ) ||
> -         argc == 0 )
> -    {
> -        fprintf(stderr, "failed to set scaling speed\n");
> -        return ;
> -    }
> +    parse_cpuid_and_int(argc, argv, &cpuid, &speed, "speed");
>  
>      if ( cpuid < 0 )
>      {
>          int i;
>          for ( i = 0; i < max_cpu_nr; i++ )
>              if ( xc_set_cpufreq_para(xc_handle, i, SCALING_SETSPEED, speed) )
> -                fprintf(stderr, "[CPU%d] failed to set scaling speed\n", i);
> +                fprintf(stderr,
> +                        "[CPU%d] failed to set scaling speed (%d - %s)\n",
> +                        i, errno, strerror(errno));
>      }
>      else
>      {
>          if ( xc_set_cpufreq_para(xc_handle, cpuid, SCALING_SETSPEED, speed) )
> -            fprintf(stderr, "failed to set scaling speed\n");
> +            fprintf(stderr, "failed to set scaling speed (%d - %s)\n",
> +                    errno, strerror(errno));
>      }
>  }
>  
> @@ -869,14 +876,7 @@ void scaling_sampling_rate_func(int argc
>  {
>      int cpuid = -1, rate = -1;
>  
> -    if ( (argc >= 2 && (sscanf(argv[1], "%d", &rate) != 1 ||
> -                        sscanf(argv[0], "%d", &cpuid) != 1) ) ||
> -         (argc == 1 && sscanf(argv[0], "%d", &rate) != 1 ) ||
> -         argc == 0 )
> -    {
> -        fprintf(stderr, "failed to set scaling sampling rate\n");
> -        return ;
> -    }
> +    parse_cpuid_and_int(argc, argv, &cpuid, &rate, "rate");
>  
>      if ( cpuid < 0 )
>      {
> @@ -884,12 +884,14 @@ void scaling_sampling_rate_func(int argc
>          for ( i = 0; i < max_cpu_nr; i++ )
>              if ( xc_set_cpufreq_para(xc_handle, i, SAMPLING_RATE, rate) )
>                  fprintf(stderr,
> -                        "[CPU%d] failed to set scaling sampling rate\n", i);
> +                        "[CPU%d] failed to set scaling sampling rate (%d -
> %s)\n",
> +                        i, errno, strerror(errno));
>      }
>      else
>      {
>          if ( xc_set_cpufreq_para(xc_handle, cpuid, SAMPLING_RATE, rate) )
> -            fprintf(stderr, "failed to set scaling sampling rate\n");
> +            fprintf(stderr, "failed to set scaling sampling rate (%d -
> %s)\n",
> +                    errno, strerror(errno));
>      }
>  }
>  
> @@ -897,14 +899,7 @@ void scaling_up_threshold_func(int argc,
>  {
>      int cpuid = -1, threshold = -1;
>  
> -    if ( (argc >= 2 && (sscanf(argv[1], "%d", &threshold) != 1 ||
> -                        sscanf(argv[0], "%d", &cpuid) != 1) ) ||
> -         (argc == 1 && sscanf(argv[0], "%d", &threshold) != 1 ) ||
> -         argc == 0 )
> -    {
> -        fprintf(stderr, "failed to set up scaling threshold\n");
> -        return ;
> -    }
> +    parse_cpuid_and_int(argc, argv, &cpuid, &threshold, "threshold");
>  
>      if ( cpuid < 0 )
>      {
> @@ -912,57 +907,49 @@ void scaling_up_threshold_func(int argc,
>          for ( i = 0; i < max_cpu_nr; i++ )
>              if ( xc_set_cpufreq_para(xc_handle, i, UP_THRESHOLD, threshold) )
>                  fprintf(stderr,
> -                        "[CPU%d] failed to set up scaling threshold\n", i);
> +                        "[CPU%d] failed to set up scaling threshold (%d -
> %s)\n",
> +                        i, errno, strerror(errno));
>      }
>      else
>      {
>          if ( xc_set_cpufreq_para(xc_handle, cpuid, UP_THRESHOLD, threshold) )
> -            fprintf(stderr, "failed to set up scaling threshold\n");
> +            fprintf(stderr, "failed to set up scaling threshold (%d - %s)\n",
> +                    errno, strerror(errno));
>      }
>  }
>  
>  void scaling_governor_func(int argc, char *argv[])
>  {
>      int cpuid = -1;
> -    char *name = NULL;
> +    char *name;
>  
>      if ( argc >= 2 )
>      {
> -        name = strdup(argv[1]);
> -        if ( name == NULL )
> -            goto out;
> -        if ( sscanf(argv[0], "%d", &cpuid) != 1 )
> -        {
> -            free(name);
> -            goto out;
> -        }
> +        parse_cpuid(argv[0], &cpuid);
> +        name = argv[1];
>      }
>      else if ( argc > 0 )
> +        name = argv[0];
> +    else
>      {
> -        name = strdup(argv[0]);
> -        if ( name == NULL )
> -            goto out;
> +        fprintf(stderr, "Missing argument(s)\n");
> +        exit(EINVAL);
>      }
> -    else
> -        goto out;
>  
>      if ( cpuid < 0 )
>      {
>          int i;
>          for ( i = 0; i < max_cpu_nr; i++ )
>              if ( xc_set_cpufreq_gov(xc_handle, i, name) )
> -                fprintf(stderr, "[CPU%d] failed to set governor name\n", i);
> +                fprintf(stderr, "[CPU%d] failed to set governor name (%d -
> %s)\n",
> +                        i, errno, strerror(errno));
>      }
>      else
>      {
>          if ( xc_set_cpufreq_gov(xc_handle, cpuid, name) )
> -            fprintf(stderr, "failed to set governor name\n");
> +            fprintf(stderr, "failed to set governor name (%d - %s)\n",
> +                    errno, strerror(errno));
>      }
> -
> -    free(name);
> -    return ;
> -out:
> -    fprintf(stderr, "failed to set governor name\n");
>  }
>  
>  void cpu_topology_func(int argc, char *argv[])
> @@ -971,7 +958,7 @@ void cpu_topology_func(int argc, char *a
>      DECLARE_HYPERCALL_BUFFER(uint32_t, cpu_to_socket);
>      DECLARE_HYPERCALL_BUFFER(uint32_t, cpu_to_node);
>      xc_topologyinfo_t info = { 0 };
> -    int i;
> +    int i, rc = ENOMEM;
>  
>      cpu_to_core = xc_hypercall_buffer_alloc(xc_handle, cpu_to_core,
> sizeof(*cpu_to_core) * MAX_NR_CPU);
>      cpu_to_socket = xc_hypercall_buffer_alloc(xc_handle, cpu_to_socket,
> sizeof(*cpu_to_socket) * MAX_NR_CPU);
> @@ -990,7 +977,9 @@ void cpu_topology_func(int argc, char *a
>  
>      if ( xc_topologyinfo(xc_handle, &info) )
>      {
> -        printf("Can not get Xen CPU topology: %d\n", errno);
> +        rc = errno;
> +        fprintf(stderr, "Cannot get Xen CPU topology (%d - %s)\n",
> +                errno, strerror(errno));
>          goto out;
>      }
>  
> @@ -1005,116 +994,95 @@ void cpu_topology_func(int argc, char *a
>          printf("CPU%d\t %d\t %d\t %d\n",
>                 i, cpu_to_core[i], cpu_to_socket[i], cpu_to_node[i]);
>      }
> +    rc = 0;
>  out:
>      xc_hypercall_buffer_free(xc_handle, cpu_to_core);
>      xc_hypercall_buffer_free(xc_handle, cpu_to_socket);
>      xc_hypercall_buffer_free(xc_handle, cpu_to_node);
> +    if ( rc )
> +        exit(rc);
>  }
>  
>  void set_sched_smt_func(int argc, char *argv[])
>  {
> -    int value, rc;
> +    int value;
>  
> -    if (argc != 1){
> -        show_help();
> -        exit(-1);
> +    if ( argc != 1 ) {
> +        fprintf(stderr, "Missing or invalid argument(s)\n");
> +        exit(EINVAL);
>      }
>  
> -    if ( !strncmp(argv[0], "disable", sizeof("disable")) )
> -    {
> +    if ( !strcasecmp(argv[0], "disable") )
>          value = 0;
> -    }
> -    else if ( !strncmp(argv[0], "enable", sizeof("enable")) )
> -    {
> +    else if ( !strcasecmp(argv[0], "enable") )
>          value = 1;
> -    }
>      else
>      {
> -        show_help();
> -        exit(-1);
> +        fprintf(stderr, "Invalid argument: %s\n", argv[0]);
> +        exit(EINVAL);
>      }
>  
> -    rc = xc_set_sched_opt_smt(xc_handle, value);
> -    printf("%s sched_smt_power_savings %s\n", argv[0],
> -                    rc? "failed":"succeeded" );
> -
> -    return;
> +    if ( !xc_set_sched_opt_smt(xc_handle, value) )
> +        printf("%s sched_smt_power_savings succeeded\n", argv[0]);
> +    else
> +        fprintf(stderr, "%s sched_smt_power_savings failed (%d - %s)\n",
> +                argv[0], errno, strerror(errno));
>  }
>  
>  void set_vcpu_migration_delay_func(int argc, char *argv[])
>  {
>      int value;
> -    int rc;
> -
> -    if (argc != 1){
> -        show_help();
> -        exit(-1);
> -    }
> -
> -    value = atoi(argv[0]);
>  
> -    if (value < 0)
> -    {
> -        printf("Please try non-negative vcpu migration delay\n");
> -        exit(-1);
> +    if ( argc != 1 || (value = atoi(argv[0])) < 0 ) {
> +        fprintf(stderr, "Missing or invalid argument(s)\n");
> +        exit(EINVAL);
>      }
>  
> -    rc = xc_set_vcpu_migration_delay(xc_handle, value);
> -    printf("%s to set vcpu migration delay to %d us\n",
> -                    rc? "Fail":"Succeed", value );
> -
> -    return;
> +    if ( !xc_set_vcpu_migration_delay(xc_handle, value) )
> +        printf("set vcpu migration delay to %d us succeeded\n", value);
> +    else
> +        fprintf(stderr, "set vcpu migration delay failed (%d - %s)\n",
> +                errno, strerror(errno));
>  }
>  
>  void get_vcpu_migration_delay_func(int argc, char *argv[])
>  {
>      uint32_t value;
> -    int rc;
>  
> -    if (argc != 0){
> -        show_help();
> -        exit(-1);
> -    }
> +    if ( argc )
> +        fprintf(stderr, "Ignoring argument(s)\n");
>  
> -    rc = xc_get_vcpu_migration_delay(xc_handle, &value);
> -    if (!rc)
> -    {
> -        printf("Schduler vcpu migration delay is %d us\n", value);
> -    }
> +    if ( !xc_get_vcpu_migration_delay(xc_handle, &value) )
> +        printf("Scheduler vcpu migration delay is %d us\n", value);
>      else
> -    {
> -        printf("Failed to get scheduler vcpu migration delay, errno=%d\n",
> errno);
> -    }
> -
> -    return;
> +        fprintf(stderr,
> +                "Failed to get scheduler vcpu migration delay (%d - %s)\n",
> +                errno, strerror(errno));
>  }
>  
>  void set_max_cstate_func(int argc, char *argv[])
>  {
> -    int value, rc;
> +    int value;
>  
>      if ( argc != 1 || sscanf(argv[0], "%d", &value) != 1 || value < 0 )
>      {
> -        show_help();
> -        exit(-1);
> +        fprintf(stderr, "Missing or invalid argument(s)\n");
> +        exit(EINVAL);
>      }
>  
> -    rc = xc_set_cpuidle_max_cstate(xc_handle, (uint32_t)value);
> -    printf("set max_cstate to C%d %s\n", value,
> -                    rc? "failed":"succeeded" );
> -
> -    return;
> +    if ( !xc_set_cpuidle_max_cstate(xc_handle, (uint32_t)value) )
> +        printf("set max_cstate to C%d succeeded\n", value);
> +    else
> +        fprintf(stderr, "set max_cstate to C%d failed (%d - %s)\n",
> +                value, errno, strerror(errno));
>  }
>  
>  void enable_turbo_mode(int argc, char *argv[])
>  {
>      int cpuid = -1;
>  
> -    if ( argc > 0 && sscanf(argv[0], "%d", &cpuid) != 1 )
> -        cpuid = -1;
> -
> -    if ( cpuid >= max_cpu_nr )
> -        cpuid = -1;
> +    if ( argc > 0 )
> +        parse_cpuid(argv[0], &cpuid);
>  
>      if ( cpuid < 0 )
>      {
> @@ -1122,21 +1090,22 @@ void enable_turbo_mode(int argc, char *a
>           * only make effects on dbs governor */
>          int i;
>          for ( i = 0; i < max_cpu_nr; i++ )
> -            xc_enable_turbo(xc_handle, i);
> +            if ( xc_enable_turbo(xc_handle, i) )
> +                fprintf(stderr,
> +                        "[CPU%d] failed to enable turbo mode (%d - %s)\n",
> +                        i, errno, strerror(errno));
>      }
> -    else
> -        xc_enable_turbo(xc_handle, cpuid);
> +    else if ( xc_enable_turbo(xc_handle, cpuid) )
> +        fprintf(stderr, "failed to enable turbo mode (%d - %s)\n",
> +                errno, strerror(errno));
>  }
>  
>  void disable_turbo_mode(int argc, char *argv[])
>  {
>      int cpuid = -1;
>  
> -    if ( argc > 0 && sscanf(argv[0], "%d", &cpuid) != 1 )
> -        cpuid = -1;
> -
> -    if ( cpuid >= max_cpu_nr )
> -        cpuid = -1;
> +    if ( argc > 0 )
> +        parse_cpuid(argv[0], &cpuid);
>  
>      if ( cpuid < 0 )
>      {
> @@ -1144,10 +1113,14 @@ void disable_turbo_mode(int argc, char *
>           * only make effects on dbs governor */
>          int i;
>          for ( i = 0; i < max_cpu_nr; i++ )
> -            xc_disable_turbo(xc_handle, i);
> +            if ( xc_disable_turbo(xc_handle, i) )
> +                fprintf(stderr,
> +                        "[CPU%d] failed to disable turbo mode (%d - %s)\n",
> +                        i, errno, strerror(errno));
>      }
> -    else
> -        xc_disable_turbo(xc_handle, cpuid);
> +    else if ( xc_disable_turbo(xc_handle, cpuid) )
> +        fprintf(stderr, "failed to disable turbo mode (%d - %s)\n",
> +                errno, strerror(errno));
>  }
>  
>  struct {
> @@ -1191,15 +1164,17 @@ int main(int argc, char *argv[])
>      if ( !xc_handle )
>      {
>          fprintf(stderr, "failed to get the handler\n");
> -        return 0;
> +        return EIO;
>      }
>  
>      ret = xc_physinfo(xc_handle, &physinfo);
>      if ( ret )
>      {
> -        fprintf(stderr, "failed to get the processor information\n");
> +        ret = errno;
> +        fprintf(stderr, "failed to get processor information (%d - %s)\n",
> +                ret, strerror(ret));
>          xc_interface_close(xc_handle);
> -        return 0;
> +        return ret;
>      }
>      max_cpu_nr = physinfo.nr_cpus;
>  
> @@ -1214,14 +1189,18 @@ int main(int argc, char *argv[])
>          for ( i = 0; i < nr_matches; i++ )
>              fprintf(stderr, " %s",
> main_options[matches_main_options[i]].name);
>          fprintf(stderr, "\n");
> +        ret = EINVAL;
>      }
>      else if ( nr_matches == 1 )
>          /* dispatch to the corresponding function handler */
>          main_options[matches_main_options[0]].function(argc - 2, argv + 2);
>      else
> +    {
>          show_help();
> +        ret = EINVAL;
> +    }
>  
>      xc_interface_close(xc_handle);
> -    return 0;
> +    return ret;
>  }
>  
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 14 14:24:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 14:24: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 1TCWoF-0007s2-HJ; Fri, 14 Sep 2012 14:23:55 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1TCWoE-0007rY-6y
	for xen-devel@lists.xen.org; Fri, 14 Sep 2012 14:23:54 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1347632627!1729543!1
X-Originating-IP: [74.125.83.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4750 invoked from network); 14 Sep 2012 14:23:47 -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;
	14 Sep 2012 14:23:47 -0000
Received: by eeke53 with SMTP id e53so2649535eek.32
	for <xen-devel@lists.xen.org>; Fri, 14 Sep 2012 07:23:47 -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=nLJbCaXpFitbSzPmGKlQMnK6Zhz78Tw1m14nOWFdJv0=;
	b=QfO6zUQ8AFK96xVRIYHN0HXL6JJz25HOxI5dSFPUolghlqIDcYq+ebLmLo2bcMmIfp
	f9/R52kKUhFK94Kwc+Kn+O+nuwknjcrN5q5Vxrlfa6oINg/qJzSRDt4ZpoKBd26WvNMB
	dNVDeYVnqsH5Y1B/X0oYA9AzAD3FPrVYdGTlJIQJvnsnZ542wXihjsnYPfsjHm9fGT9c
	GQw9i08dj7c0HR2+HD6cUCzX8f2HZp3hxJ9yh+UdNA2+ztLNEz6DTWd2tws6vjZ8RxB7
	Uylnu88w/UDb61Yl9VVOmoiVeo60CRhgMaBEQxAYaq1TmuWruOlOVDb8yDokBma7W71L
	aSog==
Received: by 10.14.177.193 with SMTP id d41mr3755299eem.19.1347632627033;
	Fri, 14 Sep 2012 07:23:47 -0700 (PDT)
Received: from [192.168.1.3] (host86-184-74-117.range86-184.btcentralplus.com.
	[86.184.74.117])
	by mx.google.com with ESMTPS id a7sm4850507eep.14.2012.09.14.07.23.44
	(version=SSLv3 cipher=OTHER); Fri, 14 Sep 2012 07:23:46 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.33.0.120411
Date: Fri, 14 Sep 2012 15:23:41 +0100
From: Keir Fraser <keir@xen.org>
To: Jan Beulich <JBeulich@suse.com>,
	xen-devel <xen-devel@lists.xen.org>
Message-ID: <CC78FC7D.4BC43%keir@xen.org>
Thread-Topic: [Xen-devel] [PATCH] xenpm: make argument parsing and error
	handling more consistent
Thread-Index: Ac2ShInea1X+CC2cz0CyKhRDiQeukA==
In-Reply-To: <50534722020000780009B70D@nat28.tlf.novell.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] [PATCH] xenpm: make argument parsing and error
 handling more consistent
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 14/09/2012 14:02, "Jan Beulich" <JBeulich@suse.com> wrote:

> Specifically, what values are or aren't accepted as CPU identifier, and
> how the values get interpreted should be consistent across sub-commands
> (intended behavior now: non-negative values are okay, and along with
> omitting the argument, specifying "all" will also be accepted).
> 
> For error handling, error messages should get consistently issued to
> stderr, and the tool should now (hopefully) produce an exit code of
> zero only in the (partial) success case (there may still be a small
> number of questionable cases).
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Acked-by: Keir Fraser <keir@xen.org>

You can apply this one if you get no furthe feedback.

 -- Keir

> --- a/tools/misc/xenpm.c
> +++ b/tools/misc/xenpm.c
> @@ -36,7 +36,7 @@
>  #define CPUFREQ_TURBO_ENABLED       1
>  
>  static xc_interface *xc_handle;
> -static int max_cpu_nr;
> +static unsigned int max_cpu_nr;
>  
>  /* help message */
>  void show_help(void)
> @@ -77,6 +77,33 @@ void help_func(int argc, char *argv[])
>      show_help();
>  }
>  
> +static void parse_cpuid(const char *arg, int *cpuid)
> +{
> +    if ( sscanf(arg, "%d", cpuid) != 1 || *cpuid < 0 )
> +    {
> +        if ( strcasecmp(arg, "all") )
> +        {
> +            fprintf(stderr, "Invalid CPU identifier: '%s'\n", arg);
> +            exit(EINVAL);
> +        }
> +        *cpuid = -1;
> +    }
> +}
> +
> +static void parse_cpuid_and_int(int argc, char *argv[],
> +                                int *cpuid, int *val, const char *what)
> +{
> +    if ( argc > 1 )
> +        parse_cpuid(argv[0], cpuid);
> +
> +    if ( argc == 0 || sscanf(argv[argc > 1], "%d", val) != 1 )
> +    {
> +        fprintf(stderr, argc ? "Invalid %s '%s'\n" : "Missing %s\n",
> +                what, argv[argc > 1]);
> +        exit(EINVAL);
> +    }
> +}
> +
>  static void print_cxstat(int cpuid, struct xc_cx_stat *cxstat)
>  {
>      int i;
> @@ -166,7 +193,8 @@ static int show_cxstat_by_cpuid(xc_inter
>      if ( ret )
>      {
>          if ( ret == -ENODEV )
> -            printf("Either xen cpuidle is disabled or no valid information is
> registered!\n");
> +            fprintf(stderr,
> +                    "Either Xen cpuidle is disabled or no valid information
> is registered!\n");
>          return ret;
>      }
>  
> @@ -181,11 +209,8 @@ void cxstat_func(int argc, char *argv[])
>  {
>      int cpuid = -1;
>  
> -    if ( argc > 0 && sscanf(argv[0], "%d", &cpuid) != 1 )
> -        cpuid = -1;
> -
> -    if ( cpuid >= max_cpu_nr )
> -        cpuid = -1;
> +    if ( argc > 0 )
> +        parse_cpuid(argv[0], &cpuid);
>  
>      show_max_cstate(xc_handle);
>  
> @@ -294,11 +319,8 @@ void pxstat_func(int argc, char *argv[])
>  {
>      int cpuid = -1;
>  
> -    if ( argc > 0 && sscanf(argv[0], "%d", &cpuid) != 1 )
> -        cpuid = -1;
> -
> -    if ( cpuid >= max_cpu_nr )
> -        cpuid = -1;
> +    if ( argc > 0 )
> +        parse_cpuid(argv[0], &cpuid);
>  
>      if ( cpuid < 0 )
>      {
> @@ -338,10 +360,10 @@ static void signal_int_handler(int signo
> goto out;
>      }
>  
> -    if ( gettimeofday(&tv, NULL) == -1 )
> +    if ( gettimeofday(&tv, NULL) )
>      {
>          fprintf(stderr, "failed to get timeofday\n");
> -        goto out ;
> +        goto out;
>      }
>      usec_end = tv.tv_sec * 1000000UL + tv.tv_usec;
>  
> @@ -541,7 +563,7 @@ void start_gather_func(int argc, char *a
>              printf("Timeout set to %d seconds\n", timeout);
>      }
>  
> -    if ( gettimeofday(&tv, NULL) == -1 )
> +    if ( gettimeofday(&tv, NULL) )
>      {
>          fprintf(stderr, "failed to get timeofday\n");
>          return ;
> @@ -766,11 +788,8 @@ void cpufreq_para_func(int argc, char *a
>  {
>      int cpuid = -1;
>  
> -    if ( argc > 0 && sscanf(argv[0], "%d", &cpuid) != 1 )
> -        cpuid = -1;
> -
> -    if ( cpuid >= max_cpu_nr )
> -        cpuid = -1;
> +    if ( argc > 0 )
> +        parse_cpuid(argv[0], &cpuid);
>  
>      if ( cpuid < 0 )
>      {
> @@ -788,26 +807,22 @@ void scaling_max_freq_func(int argc, cha
>  {
>      int cpuid = -1, freq = -1;
>  
> -    if ( (argc >= 2 && (sscanf(argv[1], "%d", &freq) != 1 ||
> -                        sscanf(argv[0], "%d", &cpuid) != 1)) ||
> -         (argc == 1 && sscanf(argv[0], "%d", &freq) != 1 ) ||
> -         argc == 0 )
> -    {
> -        fprintf(stderr, "failed to set scaling max freq\n");
> -        return ;
> -    }
> +    parse_cpuid_and_int(argc, argv, &cpuid, &freq, "frequency");
>  
>      if ( cpuid < 0 )
>      {
>          int i;
>          for ( i = 0; i < max_cpu_nr; i++ )
>              if ( xc_set_cpufreq_para(xc_handle, i, SCALING_MAX_FREQ, freq) )
> -                fprintf(stderr, "[CPU%d] failed to set scaling max freq\n",
> i);
> +                fprintf(stderr,
> +                        "[CPU%d] failed to set scaling max freq (%d - %s)\n",
> +                        i, errno, strerror(errno));
>      }
>      else
>      {
>          if ( xc_set_cpufreq_para(xc_handle, cpuid, SCALING_MAX_FREQ, freq) )
> -            fprintf(stderr, "failed to set scaling max freq\n");
> +            fprintf(stderr, "failed to set scaling max freq (%d - %s)\n",
> +                    errno, strerror(errno));
>      }
>  }
>  
> @@ -815,26 +830,22 @@ void scaling_min_freq_func(int argc, cha
>  {
>      int cpuid = -1, freq = -1;
>  
> -    if ( (argc >= 2 && (sscanf(argv[1], "%d", &freq) != 1 ||
> -                        sscanf(argv[0], "%d", &cpuid) != 1) ) ||
> -         (argc == 1 && sscanf(argv[0], "%d", &freq) != 1 ) ||
> -         argc == 0 )
> -    {
> -        fprintf(stderr, "failed to set scaling min freq\n");
> -        return ;
> -    }
> +    parse_cpuid_and_int(argc, argv, &cpuid, &freq, "frequency");
>  
>      if ( cpuid < 0 )
>      {
>          int i;
>          for ( i = 0; i < max_cpu_nr; i++ )
>              if ( xc_set_cpufreq_para(xc_handle, i, SCALING_MIN_FREQ, freq) )
> -                fprintf(stderr, "[CPU%d] failed to set scaling min freq\n",
> i);
> +                fprintf(stderr,
> +                        "[CPU%d] failed to set scaling min freq (%d - %s)\n",
> +                        i, errno, strerror(errno));
>      }
>      else
>      {
>          if ( xc_set_cpufreq_para(xc_handle, cpuid, SCALING_MIN_FREQ, freq) )
> -            fprintf(stderr, "failed to set scaling min freq\n");
> +            fprintf(stderr, "failed to set scaling min freq (%d - %s)\n",
> +                    errno, strerror(errno));
>      }
>  }
>  
> @@ -842,26 +853,22 @@ void scaling_speed_func(int argc, char *
>  {
>      int cpuid = -1, speed = -1;
>  
> -    if ( (argc >= 2 && (sscanf(argv[1], "%d", &speed) != 1 ||
> -                        sscanf(argv[0], "%d", &cpuid) != 1) ) ||
> -         (argc == 1 && sscanf(argv[0], "%d", &speed) != 1 ) ||
> -         argc == 0 )
> -    {
> -        fprintf(stderr, "failed to set scaling speed\n");
> -        return ;
> -    }
> +    parse_cpuid_and_int(argc, argv, &cpuid, &speed, "speed");
>  
>      if ( cpuid < 0 )
>      {
>          int i;
>          for ( i = 0; i < max_cpu_nr; i++ )
>              if ( xc_set_cpufreq_para(xc_handle, i, SCALING_SETSPEED, speed) )
> -                fprintf(stderr, "[CPU%d] failed to set scaling speed\n", i);
> +                fprintf(stderr,
> +                        "[CPU%d] failed to set scaling speed (%d - %s)\n",
> +                        i, errno, strerror(errno));
>      }
>      else
>      {
>          if ( xc_set_cpufreq_para(xc_handle, cpuid, SCALING_SETSPEED, speed) )
> -            fprintf(stderr, "failed to set scaling speed\n");
> +            fprintf(stderr, "failed to set scaling speed (%d - %s)\n",
> +                    errno, strerror(errno));
>      }
>  }
>  
> @@ -869,14 +876,7 @@ void scaling_sampling_rate_func(int argc
>  {
>      int cpuid = -1, rate = -1;
>  
> -    if ( (argc >= 2 && (sscanf(argv[1], "%d", &rate) != 1 ||
> -                        sscanf(argv[0], "%d", &cpuid) != 1) ) ||
> -         (argc == 1 && sscanf(argv[0], "%d", &rate) != 1 ) ||
> -         argc == 0 )
> -    {
> -        fprintf(stderr, "failed to set scaling sampling rate\n");
> -        return ;
> -    }
> +    parse_cpuid_and_int(argc, argv, &cpuid, &rate, "rate");
>  
>      if ( cpuid < 0 )
>      {
> @@ -884,12 +884,14 @@ void scaling_sampling_rate_func(int argc
>          for ( i = 0; i < max_cpu_nr; i++ )
>              if ( xc_set_cpufreq_para(xc_handle, i, SAMPLING_RATE, rate) )
>                  fprintf(stderr,
> -                        "[CPU%d] failed to set scaling sampling rate\n", i);
> +                        "[CPU%d] failed to set scaling sampling rate (%d -
> %s)\n",
> +                        i, errno, strerror(errno));
>      }
>      else
>      {
>          if ( xc_set_cpufreq_para(xc_handle, cpuid, SAMPLING_RATE, rate) )
> -            fprintf(stderr, "failed to set scaling sampling rate\n");
> +            fprintf(stderr, "failed to set scaling sampling rate (%d -
> %s)\n",
> +                    errno, strerror(errno));
>      }
>  }
>  
> @@ -897,14 +899,7 @@ void scaling_up_threshold_func(int argc,
>  {
>      int cpuid = -1, threshold = -1;
>  
> -    if ( (argc >= 2 && (sscanf(argv[1], "%d", &threshold) != 1 ||
> -                        sscanf(argv[0], "%d", &cpuid) != 1) ) ||
> -         (argc == 1 && sscanf(argv[0], "%d", &threshold) != 1 ) ||
> -         argc == 0 )
> -    {
> -        fprintf(stderr, "failed to set up scaling threshold\n");
> -        return ;
> -    }
> +    parse_cpuid_and_int(argc, argv, &cpuid, &threshold, "threshold");
>  
>      if ( cpuid < 0 )
>      {
> @@ -912,57 +907,49 @@ void scaling_up_threshold_func(int argc,
>          for ( i = 0; i < max_cpu_nr; i++ )
>              if ( xc_set_cpufreq_para(xc_handle, i, UP_THRESHOLD, threshold) )
>                  fprintf(stderr,
> -                        "[CPU%d] failed to set up scaling threshold\n", i);
> +                        "[CPU%d] failed to set up scaling threshold (%d -
> %s)\n",
> +                        i, errno, strerror(errno));
>      }
>      else
>      {
>          if ( xc_set_cpufreq_para(xc_handle, cpuid, UP_THRESHOLD, threshold) )
> -            fprintf(stderr, "failed to set up scaling threshold\n");
> +            fprintf(stderr, "failed to set up scaling threshold (%d - %s)\n",
> +                    errno, strerror(errno));
>      }
>  }
>  
>  void scaling_governor_func(int argc, char *argv[])
>  {
>      int cpuid = -1;
> -    char *name = NULL;
> +    char *name;
>  
>      if ( argc >= 2 )
>      {
> -        name = strdup(argv[1]);
> -        if ( name == NULL )
> -            goto out;
> -        if ( sscanf(argv[0], "%d", &cpuid) != 1 )
> -        {
> -            free(name);
> -            goto out;
> -        }
> +        parse_cpuid(argv[0], &cpuid);
> +        name = argv[1];
>      }
>      else if ( argc > 0 )
> +        name = argv[0];
> +    else
>      {
> -        name = strdup(argv[0]);
> -        if ( name == NULL )
> -            goto out;
> +        fprintf(stderr, "Missing argument(s)\n");
> +        exit(EINVAL);
>      }
> -    else
> -        goto out;
>  
>      if ( cpuid < 0 )
>      {
>          int i;
>          for ( i = 0; i < max_cpu_nr; i++ )
>              if ( xc_set_cpufreq_gov(xc_handle, i, name) )
> -                fprintf(stderr, "[CPU%d] failed to set governor name\n", i);
> +                fprintf(stderr, "[CPU%d] failed to set governor name (%d -
> %s)\n",
> +                        i, errno, strerror(errno));
>      }
>      else
>      {
>          if ( xc_set_cpufreq_gov(xc_handle, cpuid, name) )
> -            fprintf(stderr, "failed to set governor name\n");
> +            fprintf(stderr, "failed to set governor name (%d - %s)\n",
> +                    errno, strerror(errno));
>      }
> -
> -    free(name);
> -    return ;
> -out:
> -    fprintf(stderr, "failed to set governor name\n");
>  }
>  
>  void cpu_topology_func(int argc, char *argv[])
> @@ -971,7 +958,7 @@ void cpu_topology_func(int argc, char *a
>      DECLARE_HYPERCALL_BUFFER(uint32_t, cpu_to_socket);
>      DECLARE_HYPERCALL_BUFFER(uint32_t, cpu_to_node);
>      xc_topologyinfo_t info = { 0 };
> -    int i;
> +    int i, rc = ENOMEM;
>  
>      cpu_to_core = xc_hypercall_buffer_alloc(xc_handle, cpu_to_core,
> sizeof(*cpu_to_core) * MAX_NR_CPU);
>      cpu_to_socket = xc_hypercall_buffer_alloc(xc_handle, cpu_to_socket,
> sizeof(*cpu_to_socket) * MAX_NR_CPU);
> @@ -990,7 +977,9 @@ void cpu_topology_func(int argc, char *a
>  
>      if ( xc_topologyinfo(xc_handle, &info) )
>      {
> -        printf("Can not get Xen CPU topology: %d\n", errno);
> +        rc = errno;
> +        fprintf(stderr, "Cannot get Xen CPU topology (%d - %s)\n",
> +                errno, strerror(errno));
>          goto out;
>      }
>  
> @@ -1005,116 +994,95 @@ void cpu_topology_func(int argc, char *a
>          printf("CPU%d\t %d\t %d\t %d\n",
>                 i, cpu_to_core[i], cpu_to_socket[i], cpu_to_node[i]);
>      }
> +    rc = 0;
>  out:
>      xc_hypercall_buffer_free(xc_handle, cpu_to_core);
>      xc_hypercall_buffer_free(xc_handle, cpu_to_socket);
>      xc_hypercall_buffer_free(xc_handle, cpu_to_node);
> +    if ( rc )
> +        exit(rc);
>  }
>  
>  void set_sched_smt_func(int argc, char *argv[])
>  {
> -    int value, rc;
> +    int value;
>  
> -    if (argc != 1){
> -        show_help();
> -        exit(-1);
> +    if ( argc != 1 ) {
> +        fprintf(stderr, "Missing or invalid argument(s)\n");
> +        exit(EINVAL);
>      }
>  
> -    if ( !strncmp(argv[0], "disable", sizeof("disable")) )
> -    {
> +    if ( !strcasecmp(argv[0], "disable") )
>          value = 0;
> -    }
> -    else if ( !strncmp(argv[0], "enable", sizeof("enable")) )
> -    {
> +    else if ( !strcasecmp(argv[0], "enable") )
>          value = 1;
> -    }
>      else
>      {
> -        show_help();
> -        exit(-1);
> +        fprintf(stderr, "Invalid argument: %s\n", argv[0]);
> +        exit(EINVAL);
>      }
>  
> -    rc = xc_set_sched_opt_smt(xc_handle, value);
> -    printf("%s sched_smt_power_savings %s\n", argv[0],
> -                    rc? "failed":"succeeded" );
> -
> -    return;
> +    if ( !xc_set_sched_opt_smt(xc_handle, value) )
> +        printf("%s sched_smt_power_savings succeeded\n", argv[0]);
> +    else
> +        fprintf(stderr, "%s sched_smt_power_savings failed (%d - %s)\n",
> +                argv[0], errno, strerror(errno));
>  }
>  
>  void set_vcpu_migration_delay_func(int argc, char *argv[])
>  {
>      int value;
> -    int rc;
> -
> -    if (argc != 1){
> -        show_help();
> -        exit(-1);
> -    }
> -
> -    value = atoi(argv[0]);
>  
> -    if (value < 0)
> -    {
> -        printf("Please try non-negative vcpu migration delay\n");
> -        exit(-1);
> +    if ( argc != 1 || (value = atoi(argv[0])) < 0 ) {
> +        fprintf(stderr, "Missing or invalid argument(s)\n");
> +        exit(EINVAL);
>      }
>  
> -    rc = xc_set_vcpu_migration_delay(xc_handle, value);
> -    printf("%s to set vcpu migration delay to %d us\n",
> -                    rc? "Fail":"Succeed", value );
> -
> -    return;
> +    if ( !xc_set_vcpu_migration_delay(xc_handle, value) )
> +        printf("set vcpu migration delay to %d us succeeded\n", value);
> +    else
> +        fprintf(stderr, "set vcpu migration delay failed (%d - %s)\n",
> +                errno, strerror(errno));
>  }
>  
>  void get_vcpu_migration_delay_func(int argc, char *argv[])
>  {
>      uint32_t value;
> -    int rc;
>  
> -    if (argc != 0){
> -        show_help();
> -        exit(-1);
> -    }
> +    if ( argc )
> +        fprintf(stderr, "Ignoring argument(s)\n");
>  
> -    rc = xc_get_vcpu_migration_delay(xc_handle, &value);
> -    if (!rc)
> -    {
> -        printf("Schduler vcpu migration delay is %d us\n", value);
> -    }
> +    if ( !xc_get_vcpu_migration_delay(xc_handle, &value) )
> +        printf("Scheduler vcpu migration delay is %d us\n", value);
>      else
> -    {
> -        printf("Failed to get scheduler vcpu migration delay, errno=%d\n",
> errno);
> -    }
> -
> -    return;
> +        fprintf(stderr,
> +                "Failed to get scheduler vcpu migration delay (%d - %s)\n",
> +                errno, strerror(errno));
>  }
>  
>  void set_max_cstate_func(int argc, char *argv[])
>  {
> -    int value, rc;
> +    int value;
>  
>      if ( argc != 1 || sscanf(argv[0], "%d", &value) != 1 || value < 0 )
>      {
> -        show_help();
> -        exit(-1);
> +        fprintf(stderr, "Missing or invalid argument(s)\n");
> +        exit(EINVAL);
>      }
>  
> -    rc = xc_set_cpuidle_max_cstate(xc_handle, (uint32_t)value);
> -    printf("set max_cstate to C%d %s\n", value,
> -                    rc? "failed":"succeeded" );
> -
> -    return;
> +    if ( !xc_set_cpuidle_max_cstate(xc_handle, (uint32_t)value) )
> +        printf("set max_cstate to C%d succeeded\n", value);
> +    else
> +        fprintf(stderr, "set max_cstate to C%d failed (%d - %s)\n",
> +                value, errno, strerror(errno));
>  }
>  
>  void enable_turbo_mode(int argc, char *argv[])
>  {
>      int cpuid = -1;
>  
> -    if ( argc > 0 && sscanf(argv[0], "%d", &cpuid) != 1 )
> -        cpuid = -1;
> -
> -    if ( cpuid >= max_cpu_nr )
> -        cpuid = -1;
> +    if ( argc > 0 )
> +        parse_cpuid(argv[0], &cpuid);
>  
>      if ( cpuid < 0 )
>      {
> @@ -1122,21 +1090,22 @@ void enable_turbo_mode(int argc, char *a
>           * only make effects on dbs governor */
>          int i;
>          for ( i = 0; i < max_cpu_nr; i++ )
> -            xc_enable_turbo(xc_handle, i);
> +            if ( xc_enable_turbo(xc_handle, i) )
> +                fprintf(stderr,
> +                        "[CPU%d] failed to enable turbo mode (%d - %s)\n",
> +                        i, errno, strerror(errno));
>      }
> -    else
> -        xc_enable_turbo(xc_handle, cpuid);
> +    else if ( xc_enable_turbo(xc_handle, cpuid) )
> +        fprintf(stderr, "failed to enable turbo mode (%d - %s)\n",
> +                errno, strerror(errno));
>  }
>  
>  void disable_turbo_mode(int argc, char *argv[])
>  {
>      int cpuid = -1;
>  
> -    if ( argc > 0 && sscanf(argv[0], "%d", &cpuid) != 1 )
> -        cpuid = -1;
> -
> -    if ( cpuid >= max_cpu_nr )
> -        cpuid = -1;
> +    if ( argc > 0 )
> +        parse_cpuid(argv[0], &cpuid);
>  
>      if ( cpuid < 0 )
>      {
> @@ -1144,10 +1113,14 @@ void disable_turbo_mode(int argc, char *
>           * only make effects on dbs governor */
>          int i;
>          for ( i = 0; i < max_cpu_nr; i++ )
> -            xc_disable_turbo(xc_handle, i);
> +            if ( xc_disable_turbo(xc_handle, i) )
> +                fprintf(stderr,
> +                        "[CPU%d] failed to disable turbo mode (%d - %s)\n",
> +                        i, errno, strerror(errno));
>      }
> -    else
> -        xc_disable_turbo(xc_handle, cpuid);
> +    else if ( xc_disable_turbo(xc_handle, cpuid) )
> +        fprintf(stderr, "failed to disable turbo mode (%d - %s)\n",
> +                errno, strerror(errno));
>  }
>  
>  struct {
> @@ -1191,15 +1164,17 @@ int main(int argc, char *argv[])
>      if ( !xc_handle )
>      {
>          fprintf(stderr, "failed to get the handler\n");
> -        return 0;
> +        return EIO;
>      }
>  
>      ret = xc_physinfo(xc_handle, &physinfo);
>      if ( ret )
>      {
> -        fprintf(stderr, "failed to get the processor information\n");
> +        ret = errno;
> +        fprintf(stderr, "failed to get processor information (%d - %s)\n",
> +                ret, strerror(ret));
>          xc_interface_close(xc_handle);
> -        return 0;
> +        return ret;
>      }
>      max_cpu_nr = physinfo.nr_cpus;
>  
> @@ -1214,14 +1189,18 @@ int main(int argc, char *argv[])
>          for ( i = 0; i < nr_matches; i++ )
>              fprintf(stderr, " %s",
> main_options[matches_main_options[i]].name);
>          fprintf(stderr, "\n");
> +        ret = EINVAL;
>      }
>      else if ( nr_matches == 1 )
>          /* dispatch to the corresponding function handler */
>          main_options[matches_main_options[0]].function(argc - 2, argv + 2);
>      else
> +    {
>          show_help();
> +        ret = EINVAL;
> +    }
>  
>      xc_interface_close(xc_handle);
> -    return 0;
> +    return ret;
>  }
>  
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 14 14:27:00 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 14:27: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 1TCWr1-00084H-AD; Fri, 14 Sep 2012 14:26:47 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1TCWqz-00084A-Nb
	for xen-devel@lists.xensource.com; Fri, 14 Sep 2012 14:26:45 +0000
Received: from [85.158.139.211:48826] by server-7.bemta-5.messagelabs.com id
	F9/E0-19703-4AE33505; Fri, 14 Sep 2012 14:26:44 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-4.tower-206.messagelabs.com!1347632804!18598530!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28962 invoked from network); 14 Sep 2012 14:26:44 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-4.tower-206.messagelabs.com with SMTP;
	14 Sep 2012 14:26:44 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 14 Sep 2012 15:26:43 +0100
Message-Id: <50535AFA020000780009B7C4@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 14 Sep 2012 15:27:38 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Campbell" <Ian.Campbell@citrix.com>,
	"Stefano Stabellini" <Stefano.Stabellini@eu.citrix.com>
References: <alpine.DEB.2.02.1208221159560.15568@kaball.uk.xensource.com>
	<1345633688-31684-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<1347627587.24226.192.camel@zakaz.uk.xensource.com>
	<1347628660.24226.197.camel@zakaz.uk.xensource.com>
	<1347630442.24226.211.camel@zakaz.uk.xensource.com>
	<1347630971.24226.214.camel@zakaz.uk.xensource.com>
In-Reply-To: <1347630971.24226.214.camel@zakaz.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Tim\(Xen.org\)" <tim@xen.org>
Subject: Re: [Xen-devel] [PATCH v4 1/6] xen: improve changes to
 xen_add_to_physmap
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 14.09.12 at 15:56, Ian Campbell <Ian.Campbell@citrix.com> wrote:
>> > > Might we prefer to have a batched version of this call? I don't think
>> > > we can shoehorn the necessary fields into xen_add_to_physmap_t though.
>> > 
>> > Actually, talking about this we Stefano we think we can. Since both idx
>> > and gpfn are unsigned longs they can become unions with a GUEST_HANDLE
>> > without changing the ABI on x86_32 or x86_64.
> 
> Except we need both foreign_domid and size, which currently overlap, and
> there's no other spare bits. Damn.
> 
> Looks like XENMEM_add_to_physmap_range is the only option :-(

You could use the first entry in each array to specify the counts,
which would at once allow mixed granularity on each list (should
that ever turn out useful); initially you would certainly want both
counts to match.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 14 14:27:00 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 14:27: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 1TCWr1-00084H-AD; Fri, 14 Sep 2012 14:26:47 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1TCWqz-00084A-Nb
	for xen-devel@lists.xensource.com; Fri, 14 Sep 2012 14:26:45 +0000
Received: from [85.158.139.211:48826] by server-7.bemta-5.messagelabs.com id
	F9/E0-19703-4AE33505; Fri, 14 Sep 2012 14:26:44 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-4.tower-206.messagelabs.com!1347632804!18598530!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28962 invoked from network); 14 Sep 2012 14:26:44 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-4.tower-206.messagelabs.com with SMTP;
	14 Sep 2012 14:26:44 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 14 Sep 2012 15:26:43 +0100
Message-Id: <50535AFA020000780009B7C4@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 14 Sep 2012 15:27:38 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Campbell" <Ian.Campbell@citrix.com>,
	"Stefano Stabellini" <Stefano.Stabellini@eu.citrix.com>
References: <alpine.DEB.2.02.1208221159560.15568@kaball.uk.xensource.com>
	<1345633688-31684-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<1347627587.24226.192.camel@zakaz.uk.xensource.com>
	<1347628660.24226.197.camel@zakaz.uk.xensource.com>
	<1347630442.24226.211.camel@zakaz.uk.xensource.com>
	<1347630971.24226.214.camel@zakaz.uk.xensource.com>
In-Reply-To: <1347630971.24226.214.camel@zakaz.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Tim\(Xen.org\)" <tim@xen.org>
Subject: Re: [Xen-devel] [PATCH v4 1/6] xen: improve changes to
 xen_add_to_physmap
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 14.09.12 at 15:56, Ian Campbell <Ian.Campbell@citrix.com> wrote:
>> > > Might we prefer to have a batched version of this call? I don't think
>> > > we can shoehorn the necessary fields into xen_add_to_physmap_t though.
>> > 
>> > Actually, talking about this we Stefano we think we can. Since both idx
>> > and gpfn are unsigned longs they can become unions with a GUEST_HANDLE
>> > without changing the ABI on x86_32 or x86_64.
> 
> Except we need both foreign_domid and size, which currently overlap, and
> there's no other spare bits. Damn.
> 
> Looks like XENMEM_add_to_physmap_range is the only option :-(

You could use the first entry in each array to specify the counts,
which would at once allow mixed granularity on each list (should
that ever turn out useful); initially you would certainly want both
counts to match.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 14 14:27:49 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 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 1TCWrq-00089Q-Nk; Fri, 14 Sep 2012 14: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 1TCWrp-00089F-C1
	for xen-devel@lists.xensource.com; Fri, 14 Sep 2012 14:27:37 +0000
Received: from [85.158.143.35:27175] by server-2.bemta-4.messagelabs.com id
	88/3F-21239-8DE33505; Fri, 14 Sep 2012 14:27:36 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1347632843!15806676!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDkyOTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4595 invoked from network); 14 Sep 2012 14:27:24 -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;
	14 Sep 2012 14:27:24 -0000
X-IronPort-AV: E=Sophos;i="4.80,423,1344211200"; d="scan'208";a="14549060"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Sep 2012 14:27: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.279.1; Fri, 14 Sep 2012 15:27:21 +0100
Date: Fri, 14 Sep 2012 15:26:34 +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: <20120914130151.GH25249@phenom.dumpdata.com>
Message-ID: <alpine.DEB.2.02.1209141514590.29232@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1209141145150.29232@kaball.uk.xensource.com>
	<1347621207-11294-6-git-send-email-stefano.stabellini@eu.citrix.com>
	<20120914130151.GH25249@phenom.dumpdata.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: Dave Martin <dave.martin@linaro.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linaro-dev@lists.linaro.org" <linaro-dev@lists.linaro.org>,
	Ian Campbell <Ian.Campbell@citrix.com>, "arnd@arndb.de" <arnd@arndb.de>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"catalin.marinas@arm.com" <catalin.marinas@arm.com>,
	"devicetree-discuss@lists.ozlabs.org"
	<devicetree-discuss@lists.ozlabs.org>, "Tim \(Xen.org\)" <tim@xen.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Rob Herring <robherring2@gmail.com>,
	David Vrabel <david.vrabel@citrix.com>,
	"linux@arm.linux.org.uk" <linux@arm.linux.org.uk>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Xen-devel] [PATCH v4 06/24] docs: Xen ARM DT bindings
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 14 Sep 2012, Konrad Rzeszutek Wilk wrote:
> On Fri, Sep 14, 2012 at 12:13:08PM +0100, Stefano Stabellini wrote:
> > Add a doc to describe the Xen ARM device tree bindings
> > 
> > 
> > Changes in v4:
> > 
> > - "xen,xen" should be last as it is less specific;
> > - update reg property using 2 address-cells and 2 size-cells.
> > 
> > 
> > Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> > CC: devicetree-discuss@lists.ozlabs.org
> > CC: David Vrabel <david.vrabel@citrix.com>
> > CC: Rob Herring <robherring2@gmail.com>
> > CC: Dave Martin <dave.martin@linaro.org>
> > ---
> >  Documentation/devicetree/bindings/arm/xen.txt |   22 ++++++++++++++++++++++
> >  1 files changed, 22 insertions(+), 0 deletions(-)
> >  create mode 100644 Documentation/devicetree/bindings/arm/xen.txt
> > 
> > diff --git a/Documentation/devicetree/bindings/arm/xen.txt b/Documentation/devicetree/bindings/arm/xen.txt
> > new file mode 100644
> > index 0000000..1f8f7d4
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/arm/xen.txt
> > @@ -0,0 +1,22 @@
> > +* Xen hypervisor device tree bindings
> > +
> > +Xen ARM virtual platforms shall have the following properties:
> > +
> > +- compatible:
> > +	compatible = "xen,xen-<version>", "xen,xen";
> > +  where <version> is the version of the Xen ABI of the platform.
> > +
> > +- reg: specifies the base physical address and size of a region in
> > +  memory where the grant table should be mapped to, using an
> > +  HYPERVISOR_memory_op hypercall. 
> > +
> > +- interrupts: the interrupt used by Xen to inject event notifications.
> 
> Its singular here.. but in the example its plurar. What if you use
> multiple of the same number ("16 0xf")?

The "interrupts" property in the example below is a standard property to
describe interrupts. We just happen to declare only one interrupt.

>From the device tree point of view it would be possible to declare more
than one interrupt here, but Xen only supports one really.

Regarding the three cells used in the example (<1 15 0xf08>), they have
a specific meaning in the GIC context:

"""
  The 1st cell is the interrupt type; 0 for SPI interrupts, 1 for PPI
  interrupts.

  The 2nd cell contains the interrupt number for the interrupt type.
  SPI interrupts are in the range [0-987].  PPI interrupts are in the
  range [0-15].

  The 3rd cell is the flags, encoded as follows:
	bits[3:0] trigger type and level flags.
		1 = low-to-high edge triggered
		2 = high-to-low edge triggered
		4 = active high level-sensitive
		8 = active low level-sensitive
	bits[15:8] PPI interrupt cpu mask.  Each bit corresponds to each of
	the 8 possible cpus attached to the GIC.  A bit set to '1' indicated
	the interrupt is wired to that CPU.  Only valid for PPI interrupts.
"""

So <1 15 0xf08> means the last PPI.



> > +
> > +
> > +Example:
> > +
> > +hypervisor {
> > +	compatible = "xen,xen-4.3", "xen,xen";
> > +	reg = <0 0xb0000000 0 0x20000>;
> 
> So two grant tables?
> 
> Hm, physical address is zero, and the size is 0xbignumber?
> Or is the '0' denotating a seperator of arguments, so it is
> 0xb000.. for physical address and 0x20000 for size?

from http://devicetree.org/Device_Tree_Usage:

"Each addressable device gets a reg which is a list of tuples in the
form reg = <address1 length1 [address2 length2] [address3 length3] ...
Each tuple represents an address range used by the device. Each address
value is a list of one or more 32 bit integers called cells. Similarly,
the length value can either be a list of cells, or empty."

In this case the address is: [0 0xb0000000], that means
0x00000000b0000000, and the length is [0 0x20000], that means
0x0000000000020000.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 14 14:27:49 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 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 1TCWrq-00089Q-Nk; Fri, 14 Sep 2012 14: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 1TCWrp-00089F-C1
	for xen-devel@lists.xensource.com; Fri, 14 Sep 2012 14:27:37 +0000
Received: from [85.158.143.35:27175] by server-2.bemta-4.messagelabs.com id
	88/3F-21239-8DE33505; Fri, 14 Sep 2012 14:27:36 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1347632843!15806676!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDkyOTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4595 invoked from network); 14 Sep 2012 14:27:24 -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;
	14 Sep 2012 14:27:24 -0000
X-IronPort-AV: E=Sophos;i="4.80,423,1344211200"; d="scan'208";a="14549060"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Sep 2012 14:27: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.279.1; Fri, 14 Sep 2012 15:27:21 +0100
Date: Fri, 14 Sep 2012 15:26:34 +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: <20120914130151.GH25249@phenom.dumpdata.com>
Message-ID: <alpine.DEB.2.02.1209141514590.29232@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1209141145150.29232@kaball.uk.xensource.com>
	<1347621207-11294-6-git-send-email-stefano.stabellini@eu.citrix.com>
	<20120914130151.GH25249@phenom.dumpdata.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: Dave Martin <dave.martin@linaro.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linaro-dev@lists.linaro.org" <linaro-dev@lists.linaro.org>,
	Ian Campbell <Ian.Campbell@citrix.com>, "arnd@arndb.de" <arnd@arndb.de>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"catalin.marinas@arm.com" <catalin.marinas@arm.com>,
	"devicetree-discuss@lists.ozlabs.org"
	<devicetree-discuss@lists.ozlabs.org>, "Tim \(Xen.org\)" <tim@xen.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Rob Herring <robherring2@gmail.com>,
	David Vrabel <david.vrabel@citrix.com>,
	"linux@arm.linux.org.uk" <linux@arm.linux.org.uk>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Xen-devel] [PATCH v4 06/24] docs: Xen ARM DT bindings
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 14 Sep 2012, Konrad Rzeszutek Wilk wrote:
> On Fri, Sep 14, 2012 at 12:13:08PM +0100, Stefano Stabellini wrote:
> > Add a doc to describe the Xen ARM device tree bindings
> > 
> > 
> > Changes in v4:
> > 
> > - "xen,xen" should be last as it is less specific;
> > - update reg property using 2 address-cells and 2 size-cells.
> > 
> > 
> > Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> > CC: devicetree-discuss@lists.ozlabs.org
> > CC: David Vrabel <david.vrabel@citrix.com>
> > CC: Rob Herring <robherring2@gmail.com>
> > CC: Dave Martin <dave.martin@linaro.org>
> > ---
> >  Documentation/devicetree/bindings/arm/xen.txt |   22 ++++++++++++++++++++++
> >  1 files changed, 22 insertions(+), 0 deletions(-)
> >  create mode 100644 Documentation/devicetree/bindings/arm/xen.txt
> > 
> > diff --git a/Documentation/devicetree/bindings/arm/xen.txt b/Documentation/devicetree/bindings/arm/xen.txt
> > new file mode 100644
> > index 0000000..1f8f7d4
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/arm/xen.txt
> > @@ -0,0 +1,22 @@
> > +* Xen hypervisor device tree bindings
> > +
> > +Xen ARM virtual platforms shall have the following properties:
> > +
> > +- compatible:
> > +	compatible = "xen,xen-<version>", "xen,xen";
> > +  where <version> is the version of the Xen ABI of the platform.
> > +
> > +- reg: specifies the base physical address and size of a region in
> > +  memory where the grant table should be mapped to, using an
> > +  HYPERVISOR_memory_op hypercall. 
> > +
> > +- interrupts: the interrupt used by Xen to inject event notifications.
> 
> Its singular here.. but in the example its plurar. What if you use
> multiple of the same number ("16 0xf")?

The "interrupts" property in the example below is a standard property to
describe interrupts. We just happen to declare only one interrupt.

>From the device tree point of view it would be possible to declare more
than one interrupt here, but Xen only supports one really.

Regarding the three cells used in the example (<1 15 0xf08>), they have
a specific meaning in the GIC context:

"""
  The 1st cell is the interrupt type; 0 for SPI interrupts, 1 for PPI
  interrupts.

  The 2nd cell contains the interrupt number for the interrupt type.
  SPI interrupts are in the range [0-987].  PPI interrupts are in the
  range [0-15].

  The 3rd cell is the flags, encoded as follows:
	bits[3:0] trigger type and level flags.
		1 = low-to-high edge triggered
		2 = high-to-low edge triggered
		4 = active high level-sensitive
		8 = active low level-sensitive
	bits[15:8] PPI interrupt cpu mask.  Each bit corresponds to each of
	the 8 possible cpus attached to the GIC.  A bit set to '1' indicated
	the interrupt is wired to that CPU.  Only valid for PPI interrupts.
"""

So <1 15 0xf08> means the last PPI.



> > +
> > +
> > +Example:
> > +
> > +hypervisor {
> > +	compatible = "xen,xen-4.3", "xen,xen";
> > +	reg = <0 0xb0000000 0 0x20000>;
> 
> So two grant tables?
> 
> Hm, physical address is zero, and the size is 0xbignumber?
> Or is the '0' denotating a seperator of arguments, so it is
> 0xb000.. for physical address and 0x20000 for size?

from http://devicetree.org/Device_Tree_Usage:

"Each addressable device gets a reg which is a list of tuples in the
form reg = <address1 length1 [address2 length2] [address3 length3] ...
Each tuple represents an address range used by the device. Each address
value is a list of one or more 32 bit integers called cells. Similarly,
the length value can either be a list of cells, or empty."

In this case the address is: [0 0xb0000000], that means
0x00000000b0000000, and the length is [0 0x20000], that means
0x0000000000020000.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 14 14:31:06 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 14:31:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TCWug-0008Lc-AX; Fri, 14 Sep 2012 14:30: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 1TCWuf-0008LW-4s
	for xen-devel@lists.xensource.com; Fri, 14 Sep 2012 14:30:33 +0000
Received: from [85.158.137.99:46574] by server-7.bemta-3.messagelabs.com id
	89/47-32000-88F33505; Fri, 14 Sep 2012 14:30:32 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-7.tower-217.messagelabs.com!1347633029!12903326!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDkyOTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 307 invoked from network); 14 Sep 2012 14:30:31 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Sep 2012 14:30:31 -0000
X-IronPort-AV: E=Sophos;i="4.80,423,1344211200"; d="scan'208";a="14549106"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Sep 2012 14:29:01 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Fri, 14 Sep 2012 15:29:01 +0100
Date: Fri, 14 Sep 2012 15:28:18 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Marc Zyngier <marc.zyngier@arm.com>
In-Reply-To: <50533D46.5000704@arm.com>
Message-ID: <alpine.DEB.2.02.1209141527030.29232@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1209141145150.29232@kaball.uk.xensource.com>
	<1347621207-11294-16-git-send-email-stefano.stabellini@eu.citrix.com>
	<505338E6.4050504@arm.com>
	<alpine.DEB.2.02.1209141508130.29232@kaball.uk.xensource.com>
	<50533D46.5000704@arm.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>,
	"linaro-dev@lists.linaro.org" <linaro-dev@lists.linaro.org>,
	Ian Campbell <Ian.Campbell@citrix.com>, "arnd@arndb.de" <arnd@arndb.de>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
	Catalin Marinas <Catalin.Marinas@arm.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"Tim \(Xen.org\)" <tim@xen.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux@arm.linux.org.uk" <linux@arm.linux.org.uk>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Xen-devel] [PATCH v4 16/24] xen: clear IRQ_NOAUTOEN and
	IRQ_NOREQUEST
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 14 Sep 2012, Marc Zyngier wrote:
> On 14/09/12 15:13, Stefano Stabellini wrote:
> > On Fri, 14 Sep 2012, Marc Zyngier wrote:
> >> On 14/09/12 12:13, Stefano Stabellini wrote:
> >>> Reset the IRQ_NOAUTOEN and IRQ_NOREQUEST flags that are enabled by
> >>> default on ARM. If IRQ_NOAUTOEN is set, __setup_irq doesn't call
> >>> irq_startup, that is responsible for calling irq_unmask at startup time.
> >>> As a result event channels remain masked.
> >>>
> >>> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> >>> Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> >>> ---
> >>>  drivers/xen/events.c |    1 +
> >>>  1 files changed, 1 insertions(+), 0 deletions(-)
> >>>
> >>> diff --git a/drivers/xen/events.c b/drivers/xen/events.c
> >>> index 5ecb596..8ffb7b7 100644
> >>> --- a/drivers/xen/events.c
> >>> +++ b/drivers/xen/events.c
> >>> @@ -836,6 +836,7 @@ int bind_evtchn_to_irq(unsigned int evtchn)
> >>>  		struct irq_info *info = info_for_irq(irq);
> >>>  		WARN_ON(info == NULL || info->type != IRQT_EVTCHN);
> >>>  	}
> >>> +	irq_clear_status_flags(irq, IRQ_NOREQUEST|IRQ_NOAUTOEN);
> >>
> >> This one just sent a shiver down my spine. Are you doing this for a PPI?
> > 
> > Not really: even though there is just one source of event notifications
> > (that is a PPI), we have many event channels. When a domain receives a
> > notification (via the PPI), it checks on a bitmask to which event channel
> > it corresponds. From the Linux point of view every event channel is a
> > Linux irq belonging to the xen_dynamic_chip (see
> > drivers/xen/events.c:xen_dynamic_chip).
> > 
> > So here I am not doing this for the one PPI, but I am doing this for
> > every Linux irq (of chip xen_dynamic_chip) that represents an event
> > channel.
> 
> So this is some sort of secondary interrupt controller, cascaded into
> your GIC emulation,
    
I guess it could be seen as a secondary interrupt controller


> and this patch only affects the xen_dynamic_chip?

Yep

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 14 14:31:06 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 14:31:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TCWug-0008Lc-AX; Fri, 14 Sep 2012 14:30: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 1TCWuf-0008LW-4s
	for xen-devel@lists.xensource.com; Fri, 14 Sep 2012 14:30:33 +0000
Received: from [85.158.137.99:46574] by server-7.bemta-3.messagelabs.com id
	89/47-32000-88F33505; Fri, 14 Sep 2012 14:30:32 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-7.tower-217.messagelabs.com!1347633029!12903326!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDkyOTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 307 invoked from network); 14 Sep 2012 14:30:31 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Sep 2012 14:30:31 -0000
X-IronPort-AV: E=Sophos;i="4.80,423,1344211200"; d="scan'208";a="14549106"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Sep 2012 14:29:01 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Fri, 14 Sep 2012 15:29:01 +0100
Date: Fri, 14 Sep 2012 15:28:18 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Marc Zyngier <marc.zyngier@arm.com>
In-Reply-To: <50533D46.5000704@arm.com>
Message-ID: <alpine.DEB.2.02.1209141527030.29232@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1209141145150.29232@kaball.uk.xensource.com>
	<1347621207-11294-16-git-send-email-stefano.stabellini@eu.citrix.com>
	<505338E6.4050504@arm.com>
	<alpine.DEB.2.02.1209141508130.29232@kaball.uk.xensource.com>
	<50533D46.5000704@arm.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>,
	"linaro-dev@lists.linaro.org" <linaro-dev@lists.linaro.org>,
	Ian Campbell <Ian.Campbell@citrix.com>, "arnd@arndb.de" <arnd@arndb.de>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
	Catalin Marinas <Catalin.Marinas@arm.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"Tim \(Xen.org\)" <tim@xen.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux@arm.linux.org.uk" <linux@arm.linux.org.uk>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Xen-devel] [PATCH v4 16/24] xen: clear IRQ_NOAUTOEN and
	IRQ_NOREQUEST
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 14 Sep 2012, Marc Zyngier wrote:
> On 14/09/12 15:13, Stefano Stabellini wrote:
> > On Fri, 14 Sep 2012, Marc Zyngier wrote:
> >> On 14/09/12 12:13, Stefano Stabellini wrote:
> >>> Reset the IRQ_NOAUTOEN and IRQ_NOREQUEST flags that are enabled by
> >>> default on ARM. If IRQ_NOAUTOEN is set, __setup_irq doesn't call
> >>> irq_startup, that is responsible for calling irq_unmask at startup time.
> >>> As a result event channels remain masked.
> >>>
> >>> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> >>> Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> >>> ---
> >>>  drivers/xen/events.c |    1 +
> >>>  1 files changed, 1 insertions(+), 0 deletions(-)
> >>>
> >>> diff --git a/drivers/xen/events.c b/drivers/xen/events.c
> >>> index 5ecb596..8ffb7b7 100644
> >>> --- a/drivers/xen/events.c
> >>> +++ b/drivers/xen/events.c
> >>> @@ -836,6 +836,7 @@ int bind_evtchn_to_irq(unsigned int evtchn)
> >>>  		struct irq_info *info = info_for_irq(irq);
> >>>  		WARN_ON(info == NULL || info->type != IRQT_EVTCHN);
> >>>  	}
> >>> +	irq_clear_status_flags(irq, IRQ_NOREQUEST|IRQ_NOAUTOEN);
> >>
> >> This one just sent a shiver down my spine. Are you doing this for a PPI?
> > 
> > Not really: even though there is just one source of event notifications
> > (that is a PPI), we have many event channels. When a domain receives a
> > notification (via the PPI), it checks on a bitmask to which event channel
> > it corresponds. From the Linux point of view every event channel is a
> > Linux irq belonging to the xen_dynamic_chip (see
> > drivers/xen/events.c:xen_dynamic_chip).
> > 
> > So here I am not doing this for the one PPI, but I am doing this for
> > every Linux irq (of chip xen_dynamic_chip) that represents an event
> > channel.
> 
> So this is some sort of secondary interrupt controller, cascaded into
> your GIC emulation,
    
I guess it could be seen as a secondary interrupt controller


> and this patch only affects the xen_dynamic_chip?

Yep

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 14 14:32:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 14:32:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TCWvx-0008UQ-UU; Fri, 14 Sep 2012 14:31:53 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <marc.zyngier@arm.com>) id 1TCWvw-0008UC-Mm
	for xen-devel@lists.xensource.com; Fri, 14 Sep 2012 14:31:52 +0000
Received: from [85.158.139.83:48870] by server-6.bemta-5.messagelabs.com id
	07/8B-21336-3DF33505; Fri, 14 Sep 2012 14:31:47 +0000
X-Env-Sender: marc.zyngier@arm.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1347633107!16446763!1
X-Originating-IP: [91.220.42.44]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogOTEuMjIwLjQyLjQ0ID0+IDI5NDIyMA==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3471 invoked from network); 14 Sep 2012 14:31:47 -0000
Received: from service87.mimecast.com (HELO service87.mimecast.com)
	(91.220.42.44) by server-8.tower-182.messagelabs.com with SMTP;
	14 Sep 2012 14:31:47 -0000
Received: from cam-owa1.Emea.Arm.com (fw-tnat.cambridge.arm.com
	[217.140.96.21]) by service87.mimecast.com;
	Fri, 14 Sep 2012 15:31:46 +0100
Received: from [10.1.70.21] ([10.1.255.212]) by cam-owa1.Emea.Arm.com with
	Microsoft SMTPSVC(6.0.3790.0); Fri, 14 Sep 2012 15:31:46 +0100
Message-ID: <50533FD1.6000005@arm.com>
Date: Fri, 14 Sep 2012 15:31:45 +0100
From: Marc Zyngier <marc.zyngier@arm.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:14.0) Gecko/20120714 Thunderbird/14.0
MIME-Version: 1.0
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.02.1209141145150.29232@kaball.uk.xensource.com>
	<1347621207-11294-16-git-send-email-stefano.stabellini@eu.citrix.com>
	<505338E6.4050504@arm.com>
	<alpine.DEB.2.02.1209141508130.29232@kaball.uk.xensource.com>
	<50533D46.5000704@arm.com>
	<alpine.DEB.2.02.1209141527030.29232@kaball.uk.xensource.com>
In-Reply-To: <alpine.DEB.2.02.1209141527030.29232@kaball.uk.xensource.com>
X-Enigmail-Version: 1.5a1pre
X-OriginalArrivalTime: 14 Sep 2012 14:31:46.0196 (UTC)
	FILETIME=[AB115D40:01CD9285]
X-MC-Unique: 112091415314607301
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linaro-dev@lists.linaro.org" <linaro-dev@lists.linaro.org>,
	Ian Campbell <Ian.Campbell@citrix.com>, "arnd@arndb.de" <arnd@arndb.de>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
	Catalin Marinas <Catalin.Marinas@arm.com>, "Tim \(Xen.org\)" <tim@xen.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux@arm.linux.org.uk" <linux@arm.linux.org.uk>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Xen-devel] [PATCH v4 16/24] xen: clear IRQ_NOAUTOEN and
	IRQ_NOREQUEST
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/09/12 15:28, Stefano Stabellini wrote:
> On Fri, 14 Sep 2012, Marc Zyngier wrote:
>> On 14/09/12 15:13, Stefano Stabellini wrote:
>>> On Fri, 14 Sep 2012, Marc Zyngier wrote:
>>>> On 14/09/12 12:13, Stefano Stabellini wrote:
>>>>> Reset the IRQ_NOAUTOEN and IRQ_NOREQUEST flags that are enabled by
>>>>> default on ARM. If IRQ_NOAUTOEN is set, __setup_irq doesn't call
>>>>> irq_startup, that is responsible for calling irq_unmask at startup time.
>>>>> As a result event channels remain masked.
>>>>>
>>>>> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
>>>>> Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
>>>>> ---
>>>>>  drivers/xen/events.c |    1 +
>>>>>  1 files changed, 1 insertions(+), 0 deletions(-)
>>>>>
>>>>> diff --git a/drivers/xen/events.c b/drivers/xen/events.c
>>>>> index 5ecb596..8ffb7b7 100644
>>>>> --- a/drivers/xen/events.c
>>>>> +++ b/drivers/xen/events.c
>>>>> @@ -836,6 +836,7 @@ int bind_evtchn_to_irq(unsigned int evtchn)
>>>>>  		struct irq_info *info = info_for_irq(irq);
>>>>>  		WARN_ON(info == NULL || info->type != IRQT_EVTCHN);
>>>>>  	}
>>>>> +	irq_clear_status_flags(irq, IRQ_NOREQUEST|IRQ_NOAUTOEN);
>>>>
>>>> This one just sent a shiver down my spine. Are you doing this for a PPI?
>>>
>>> Not really: even though there is just one source of event notifications
>>> (that is a PPI), we have many event channels. When a domain receives a
>>> notification (via the PPI), it checks on a bitmask to which event channel
>>> it corresponds. From the Linux point of view every event channel is a
>>> Linux irq belonging to the xen_dynamic_chip (see
>>> drivers/xen/events.c:xen_dynamic_chip).
>>>
>>> So here I am not doing this for the one PPI, but I am doing this for
>>> every Linux irq (of chip xen_dynamic_chip) that represents an event
>>> channel.
>>
>> So this is some sort of secondary interrupt controller, cascaded into
>> your GIC emulation,
>     
> I guess it could be seen as a secondary interrupt controller
> 
> 
>> and this patch only affects the xen_dynamic_chip?
> 
> Yep

Thanks. I feel relieved... ;-)

	M.
-- 
Jazz is not dead. It just smells funny...


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 14 14:32:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 14:32:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TCWvx-0008UQ-UU; Fri, 14 Sep 2012 14:31:53 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <marc.zyngier@arm.com>) id 1TCWvw-0008UC-Mm
	for xen-devel@lists.xensource.com; Fri, 14 Sep 2012 14:31:52 +0000
Received: from [85.158.139.83:48870] by server-6.bemta-5.messagelabs.com id
	07/8B-21336-3DF33505; Fri, 14 Sep 2012 14:31:47 +0000
X-Env-Sender: marc.zyngier@arm.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1347633107!16446763!1
X-Originating-IP: [91.220.42.44]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogOTEuMjIwLjQyLjQ0ID0+IDI5NDIyMA==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3471 invoked from network); 14 Sep 2012 14:31:47 -0000
Received: from service87.mimecast.com (HELO service87.mimecast.com)
	(91.220.42.44) by server-8.tower-182.messagelabs.com with SMTP;
	14 Sep 2012 14:31:47 -0000
Received: from cam-owa1.Emea.Arm.com (fw-tnat.cambridge.arm.com
	[217.140.96.21]) by service87.mimecast.com;
	Fri, 14 Sep 2012 15:31:46 +0100
Received: from [10.1.70.21] ([10.1.255.212]) by cam-owa1.Emea.Arm.com with
	Microsoft SMTPSVC(6.0.3790.0); Fri, 14 Sep 2012 15:31:46 +0100
Message-ID: <50533FD1.6000005@arm.com>
Date: Fri, 14 Sep 2012 15:31:45 +0100
From: Marc Zyngier <marc.zyngier@arm.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:14.0) Gecko/20120714 Thunderbird/14.0
MIME-Version: 1.0
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.02.1209141145150.29232@kaball.uk.xensource.com>
	<1347621207-11294-16-git-send-email-stefano.stabellini@eu.citrix.com>
	<505338E6.4050504@arm.com>
	<alpine.DEB.2.02.1209141508130.29232@kaball.uk.xensource.com>
	<50533D46.5000704@arm.com>
	<alpine.DEB.2.02.1209141527030.29232@kaball.uk.xensource.com>
In-Reply-To: <alpine.DEB.2.02.1209141527030.29232@kaball.uk.xensource.com>
X-Enigmail-Version: 1.5a1pre
X-OriginalArrivalTime: 14 Sep 2012 14:31:46.0196 (UTC)
	FILETIME=[AB115D40:01CD9285]
X-MC-Unique: 112091415314607301
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linaro-dev@lists.linaro.org" <linaro-dev@lists.linaro.org>,
	Ian Campbell <Ian.Campbell@citrix.com>, "arnd@arndb.de" <arnd@arndb.de>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
	Catalin Marinas <Catalin.Marinas@arm.com>, "Tim \(Xen.org\)" <tim@xen.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux@arm.linux.org.uk" <linux@arm.linux.org.uk>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Xen-devel] [PATCH v4 16/24] xen: clear IRQ_NOAUTOEN and
	IRQ_NOREQUEST
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/09/12 15:28, Stefano Stabellini wrote:
> On Fri, 14 Sep 2012, Marc Zyngier wrote:
>> On 14/09/12 15:13, Stefano Stabellini wrote:
>>> On Fri, 14 Sep 2012, Marc Zyngier wrote:
>>>> On 14/09/12 12:13, Stefano Stabellini wrote:
>>>>> Reset the IRQ_NOAUTOEN and IRQ_NOREQUEST flags that are enabled by
>>>>> default on ARM. If IRQ_NOAUTOEN is set, __setup_irq doesn't call
>>>>> irq_startup, that is responsible for calling irq_unmask at startup time.
>>>>> As a result event channels remain masked.
>>>>>
>>>>> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
>>>>> Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
>>>>> ---
>>>>>  drivers/xen/events.c |    1 +
>>>>>  1 files changed, 1 insertions(+), 0 deletions(-)
>>>>>
>>>>> diff --git a/drivers/xen/events.c b/drivers/xen/events.c
>>>>> index 5ecb596..8ffb7b7 100644
>>>>> --- a/drivers/xen/events.c
>>>>> +++ b/drivers/xen/events.c
>>>>> @@ -836,6 +836,7 @@ int bind_evtchn_to_irq(unsigned int evtchn)
>>>>>  		struct irq_info *info = info_for_irq(irq);
>>>>>  		WARN_ON(info == NULL || info->type != IRQT_EVTCHN);
>>>>>  	}
>>>>> +	irq_clear_status_flags(irq, IRQ_NOREQUEST|IRQ_NOAUTOEN);
>>>>
>>>> This one just sent a shiver down my spine. Are you doing this for a PPI?
>>>
>>> Not really: even though there is just one source of event notifications
>>> (that is a PPI), we have many event channels. When a domain receives a
>>> notification (via the PPI), it checks on a bitmask to which event channel
>>> it corresponds. From the Linux point of view every event channel is a
>>> Linux irq belonging to the xen_dynamic_chip (see
>>> drivers/xen/events.c:xen_dynamic_chip).
>>>
>>> So here I am not doing this for the one PPI, but I am doing this for
>>> every Linux irq (of chip xen_dynamic_chip) that represents an event
>>> channel.
>>
>> So this is some sort of secondary interrupt controller, cascaded into
>> your GIC emulation,
>     
> I guess it could be seen as a secondary interrupt controller
> 
> 
>> and this patch only affects the xen_dynamic_chip?
> 
> Yep

Thanks. I feel relieved... ;-)

	M.
-- 
Jazz is not dead. It just smells funny...


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 14 14:32:45 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 14:32: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 1TCWwZ-000088-CN; Fri, 14 Sep 2012 14:32:31 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andreslc@gridcentric.ca>) id 1TCWwX-00007h-Go
	for xen-devel@lists.xen.org; Fri, 14 Sep 2012 14:32:29 +0000
Received: from [85.158.139.83:54218] by server-1.bemta-5.messagelabs.com id
	33/41-32692-CFF33505; Fri, 14 Sep 2012 14:32:28 +0000
X-Env-Sender: andreslc@gridcentric.ca
X-Msg-Ref: server-10.tower-182.messagelabs.com!1347633146!30816805!1
X-Originating-IP: [209.85.161.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13234 invoked from network); 14 Sep 2012 14:32:27 -0000
Received: from mail-gg0-f173.google.com (HELO mail-gg0-f173.google.com)
	(209.85.161.173)
	by server-10.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Sep 2012 14:32:27 -0000
Received: by ggna5 with SMTP id a5so1117794ggn.32
	for <xen-devel@lists.xen.org>; Fri, 14 Sep 2012 07:32:26 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=subject:mime-version:content-type:from:in-reply-to:date:cc
	:content-transfer-encoding:message-id:references:to:x-mailer
	:x-gm-message-state;
	bh=M0mGyL/iBJ6S6f0uggjkdrkQQCtWaRin3yt49BZtQEM=;
	b=lFHkv/qNF4TNm93U+Hi0c2paENtBcGGJQZ0E89SQf8FvSkOBsjRGWyvL/Qe6yxAwAw
	5vqiMGmLP0xlfVHQs8DDs4+RHAhtaPtM9Xy7C7HbSpHFJSYWbeIWekzmQKfnD+SE5ggp
	oisC2OTLYBLZojUmyhBBkMkQJDQxokoIG836lAAa+LiCzAWhkxi5BYP/+D9HGcV/d1wN
	f21P6rk4hY1dcNSX28MMOTD2pnbiCpVYPIvTX+J3WpHI0bKd0tho1hgj3ls5HYwcFXM2
	9AfjvrzbOyw34WMvGI7/K1TsaALNKP08/e2ke61uvZXM9iSk5MtcYjEhP1oOSe0O9Bq4
	IrKA==
Received: by 10.236.185.201 with SMTP id u49mr3445842yhm.28.1347633145859;
	Fri, 14 Sep 2012 07:32:25 -0700 (PDT)
Received: from [192.168.7.212] ([206.223.182.18])
	by mx.google.com with ESMTPS id x4sm2211389yhh.2.2012.09.14.07.32.24
	(version=TLSv1/SSLv3 cipher=OTHER);
	Fri, 14 Sep 2012 07:32:25 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1278)
From: Andres Lagar-Cavilla <andreslc@gridcentric.ca>
In-Reply-To: <1347613333.24226.165.camel@zakaz.uk.xensource.com>
Date: Fri, 14 Sep 2012 10:32:25 -0400
Message-Id: <4C733982-6BB9-459A-97E2-02B8E23E563D@gridcentric.ca>
References: <9bfaf86e061f433c65ae.1347552545@xdev.gridcentric.ca>
	<1347613333.24226.165.camel@zakaz.uk.xensource.com>
To: Ian Campbell <ian.campbell@citrix.com>
X-Mailer: Apple Mail (2.1278)
X-Gm-Message-State: ALoCoQk+xAt2vZq05ECnTqs1GVVfsTNEYBfQ4PZ2J+1jhjCRb5NYNxhYUz1LS0qbmV0V2pDx5UII
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Andres Lagar-Cavilla <andres@lagarcavilla.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] Fix libxenstore memory leak when
	USE_PTHREAD is not defined
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Sep 14, 2012, at 5:02 AM, Ian Campbell wrote:

> On Thu, 2012-09-13 at 17:09 +0100, Andres Lagar-Cavilla wrote:
>> tools/xenstore/xs.c |  22 ++++++----------------
>> 1 files changed, 6 insertions(+), 16 deletions(-)
>> 
>> 
>> Remove usage of pthread_cleanup_push and _pop, and explicitly call free for
>> heap objects in error paths. Also remove cleanup_p* for a mutex unlock path. By
>> the way, set a suitable errno value for an error path that had none.
>> 
>> Resend due to small fix spotted, please ignore previous one.
>> 
>> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
> 
> Does this reintroduce the same issue as 21353:2dd3141b3e3e was supposed
> to solve (i.e. leaks memory or mutexes if you pthread_cancel the thread
> in the midst of things operation)?
Oh I never saw that coming. The approach below is what I would have done. Let me give that a try.
Andres

> 
> Can we keep cleanup_push/pop for use with the mutexes and for the
> malloc/free do:
> 
> #ifdef USE_PTHREAD
> #define cleanup_push... as currently
> #define cleanup_pop... as currently
> #define cleanup_malloc(x) cleanup_push(free, x)
> #define cleanup_free(doit, x)  cleanup_pop(doit)
> #else
> #define cleanup_push... nop as now
> #define cleanup_pop... nop as now
> #define cleanup_malloc... NOP
> #define cleanup_free(doit, x) if (doit) free(x)
> #endif
> 
> Does that work?
>> 
>> diff -r 588d0dc298a4 -r 9bfaf86e061f tools/xenstore/xs.c
>> --- a/tools/xenstore/xs.c
>> +++ b/tools/xenstore/xs.c
>> @@ -99,14 +99,6 @@ struct xs_handle {
>> #define mutex_unlock(m)		pthread_mutex_unlock(m)
>> #define condvar_signal(c)	pthread_cond_signal(c)
>> #define condvar_wait(c,m)	pthread_cond_wait(c,m)
>> -#define cleanup_push(f, a)	\
>> -    pthread_cleanup_push((void (*)(void *))(f), (void *)(a))
>> -/*
>> - * Some definitions of pthread_cleanup_pop() are a macro starting with an
>> - * end-brace. GCC then complains if we immediately precede that with a label.
>> - * Hence we insert a dummy statement to appease the compiler in this situation.
>> - */
>> -#define cleanup_pop(run)        ((void)0); pthread_cleanup_pop(run)
>> 
>> #define read_thread_exists(h)	(h->read_thr_exists)
>> 
>> @@ -126,8 +118,6 @@ struct xs_handle {
>> #define mutex_unlock(m)		((void)0)
>> #define condvar_signal(c)	((void)0)
>> #define condvar_wait(c,m)	((void)0)
>> -#define cleanup_push(f, a)	((void)0)
>> -#define cleanup_pop(run)	((void)0)
>> #define read_thread_exists(h)	(0)
>> 
>> #endif
>> @@ -1059,7 +1049,6 @@ static int read_message(struct xs_handle
>> 	msg = malloc(sizeof(*msg));
>> 	if (msg == NULL)
>> 		goto error;
>> -	cleanup_push(free, msg);
>> 	if (!read_all(h->fd, &msg->hdr, sizeof(msg->hdr), nonblocking)) { /* Cancellation point */
>> 		saved_errno = errno;
>> 		goto error_freemsg;
>> @@ -1069,7 +1058,6 @@ static int read_message(struct xs_handle
>> 	body = msg->body = malloc(msg->hdr.len + 1);
>> 	if (body == NULL)
>> 		goto error_freemsg;
>> -	cleanup_push(free, body);
>> 	if (!read_all(h->fd, body, msg->hdr.len, 0)) { /* Cancellation point */
>> 		saved_errno = errno;
>> 		goto error_freebody;
>> @@ -1079,7 +1067,6 @@ static int read_message(struct xs_handle
>> 
>> 	if (msg->hdr.type == XS_WATCH_EVENT) {
>> 		mutex_lock(&h->watch_mutex);
>> -		cleanup_push(pthread_mutex_unlock, &h->watch_mutex);
>> 
>> 		/* Kick users out of their select() loop. */
>> 		if (list_empty(&h->watch_list) &&
>> @@ -1091,13 +1078,14 @@ static int read_message(struct xs_handle
>> 
>> 		condvar_signal(&h->watch_condvar);
>> 
>> -		cleanup_pop(1);
>> +		mutex_unlock(&h->watch_mutex);
>> 	} else {
>> 		mutex_lock(&h->reply_mutex);
>> 
>> 		/* There should only ever be one response pending! */
>> 		if (!list_empty(&h->reply_list)) {
>> 			mutex_unlock(&h->reply_mutex);
>> +			saved_errno = EEXIST; 
>> 			goto error_freebody;
>> 		}
>> 
>> @@ -1110,9 +1098,11 @@ static int read_message(struct xs_handle
>> 	ret = 0;
>> 
>> error_freebody:
>> -	cleanup_pop(ret == -1);
>> +	if (ret)
>> +		free(body);
>> error_freemsg:
>> -	cleanup_pop(ret == -1);
>> +	if (ret)
>> +		free(msg);
>> error:
>> 	errno = saved_errno;
>> 
> 
> 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 14 14:32:45 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 14:32: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 1TCWwZ-000088-CN; Fri, 14 Sep 2012 14:32:31 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andreslc@gridcentric.ca>) id 1TCWwX-00007h-Go
	for xen-devel@lists.xen.org; Fri, 14 Sep 2012 14:32:29 +0000
Received: from [85.158.139.83:54218] by server-1.bemta-5.messagelabs.com id
	33/41-32692-CFF33505; Fri, 14 Sep 2012 14:32:28 +0000
X-Env-Sender: andreslc@gridcentric.ca
X-Msg-Ref: server-10.tower-182.messagelabs.com!1347633146!30816805!1
X-Originating-IP: [209.85.161.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13234 invoked from network); 14 Sep 2012 14:32:27 -0000
Received: from mail-gg0-f173.google.com (HELO mail-gg0-f173.google.com)
	(209.85.161.173)
	by server-10.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Sep 2012 14:32:27 -0000
Received: by ggna5 with SMTP id a5so1117794ggn.32
	for <xen-devel@lists.xen.org>; Fri, 14 Sep 2012 07:32:26 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=subject:mime-version:content-type:from:in-reply-to:date:cc
	:content-transfer-encoding:message-id:references:to:x-mailer
	:x-gm-message-state;
	bh=M0mGyL/iBJ6S6f0uggjkdrkQQCtWaRin3yt49BZtQEM=;
	b=lFHkv/qNF4TNm93U+Hi0c2paENtBcGGJQZ0E89SQf8FvSkOBsjRGWyvL/Qe6yxAwAw
	5vqiMGmLP0xlfVHQs8DDs4+RHAhtaPtM9Xy7C7HbSpHFJSYWbeIWekzmQKfnD+SE5ggp
	oisC2OTLYBLZojUmyhBBkMkQJDQxokoIG836lAAa+LiCzAWhkxi5BYP/+D9HGcV/d1wN
	f21P6rk4hY1dcNSX28MMOTD2pnbiCpVYPIvTX+J3WpHI0bKd0tho1hgj3ls5HYwcFXM2
	9AfjvrzbOyw34WMvGI7/K1TsaALNKP08/e2ke61uvZXM9iSk5MtcYjEhP1oOSe0O9Bq4
	IrKA==
Received: by 10.236.185.201 with SMTP id u49mr3445842yhm.28.1347633145859;
	Fri, 14 Sep 2012 07:32:25 -0700 (PDT)
Received: from [192.168.7.212] ([206.223.182.18])
	by mx.google.com with ESMTPS id x4sm2211389yhh.2.2012.09.14.07.32.24
	(version=TLSv1/SSLv3 cipher=OTHER);
	Fri, 14 Sep 2012 07:32:25 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1278)
From: Andres Lagar-Cavilla <andreslc@gridcentric.ca>
In-Reply-To: <1347613333.24226.165.camel@zakaz.uk.xensource.com>
Date: Fri, 14 Sep 2012 10:32:25 -0400
Message-Id: <4C733982-6BB9-459A-97E2-02B8E23E563D@gridcentric.ca>
References: <9bfaf86e061f433c65ae.1347552545@xdev.gridcentric.ca>
	<1347613333.24226.165.camel@zakaz.uk.xensource.com>
To: Ian Campbell <ian.campbell@citrix.com>
X-Mailer: Apple Mail (2.1278)
X-Gm-Message-State: ALoCoQk+xAt2vZq05ECnTqs1GVVfsTNEYBfQ4PZ2J+1jhjCRb5NYNxhYUz1LS0qbmV0V2pDx5UII
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Andres Lagar-Cavilla <andres@lagarcavilla.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] Fix libxenstore memory leak when
	USE_PTHREAD is not defined
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Sep 14, 2012, at 5:02 AM, Ian Campbell wrote:

> On Thu, 2012-09-13 at 17:09 +0100, Andres Lagar-Cavilla wrote:
>> tools/xenstore/xs.c |  22 ++++++----------------
>> 1 files changed, 6 insertions(+), 16 deletions(-)
>> 
>> 
>> Remove usage of pthread_cleanup_push and _pop, and explicitly call free for
>> heap objects in error paths. Also remove cleanup_p* for a mutex unlock path. By
>> the way, set a suitable errno value for an error path that had none.
>> 
>> Resend due to small fix spotted, please ignore previous one.
>> 
>> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
> 
> Does this reintroduce the same issue as 21353:2dd3141b3e3e was supposed
> to solve (i.e. leaks memory or mutexes if you pthread_cancel the thread
> in the midst of things operation)?
Oh I never saw that coming. The approach below is what I would have done. Let me give that a try.
Andres

> 
> Can we keep cleanup_push/pop for use with the mutexes and for the
> malloc/free do:
> 
> #ifdef USE_PTHREAD
> #define cleanup_push... as currently
> #define cleanup_pop... as currently
> #define cleanup_malloc(x) cleanup_push(free, x)
> #define cleanup_free(doit, x)  cleanup_pop(doit)
> #else
> #define cleanup_push... nop as now
> #define cleanup_pop... nop as now
> #define cleanup_malloc... NOP
> #define cleanup_free(doit, x) if (doit) free(x)
> #endif
> 
> Does that work?
>> 
>> diff -r 588d0dc298a4 -r 9bfaf86e061f tools/xenstore/xs.c
>> --- a/tools/xenstore/xs.c
>> +++ b/tools/xenstore/xs.c
>> @@ -99,14 +99,6 @@ struct xs_handle {
>> #define mutex_unlock(m)		pthread_mutex_unlock(m)
>> #define condvar_signal(c)	pthread_cond_signal(c)
>> #define condvar_wait(c,m)	pthread_cond_wait(c,m)
>> -#define cleanup_push(f, a)	\
>> -    pthread_cleanup_push((void (*)(void *))(f), (void *)(a))
>> -/*
>> - * Some definitions of pthread_cleanup_pop() are a macro starting with an
>> - * end-brace. GCC then complains if we immediately precede that with a label.
>> - * Hence we insert a dummy statement to appease the compiler in this situation.
>> - */
>> -#define cleanup_pop(run)        ((void)0); pthread_cleanup_pop(run)
>> 
>> #define read_thread_exists(h)	(h->read_thr_exists)
>> 
>> @@ -126,8 +118,6 @@ struct xs_handle {
>> #define mutex_unlock(m)		((void)0)
>> #define condvar_signal(c)	((void)0)
>> #define condvar_wait(c,m)	((void)0)
>> -#define cleanup_push(f, a)	((void)0)
>> -#define cleanup_pop(run)	((void)0)
>> #define read_thread_exists(h)	(0)
>> 
>> #endif
>> @@ -1059,7 +1049,6 @@ static int read_message(struct xs_handle
>> 	msg = malloc(sizeof(*msg));
>> 	if (msg == NULL)
>> 		goto error;
>> -	cleanup_push(free, msg);
>> 	if (!read_all(h->fd, &msg->hdr, sizeof(msg->hdr), nonblocking)) { /* Cancellation point */
>> 		saved_errno = errno;
>> 		goto error_freemsg;
>> @@ -1069,7 +1058,6 @@ static int read_message(struct xs_handle
>> 	body = msg->body = malloc(msg->hdr.len + 1);
>> 	if (body == NULL)
>> 		goto error_freemsg;
>> -	cleanup_push(free, body);
>> 	if (!read_all(h->fd, body, msg->hdr.len, 0)) { /* Cancellation point */
>> 		saved_errno = errno;
>> 		goto error_freebody;
>> @@ -1079,7 +1067,6 @@ static int read_message(struct xs_handle
>> 
>> 	if (msg->hdr.type == XS_WATCH_EVENT) {
>> 		mutex_lock(&h->watch_mutex);
>> -		cleanup_push(pthread_mutex_unlock, &h->watch_mutex);
>> 
>> 		/* Kick users out of their select() loop. */
>> 		if (list_empty(&h->watch_list) &&
>> @@ -1091,13 +1078,14 @@ static int read_message(struct xs_handle
>> 
>> 		condvar_signal(&h->watch_condvar);
>> 
>> -		cleanup_pop(1);
>> +		mutex_unlock(&h->watch_mutex);
>> 	} else {
>> 		mutex_lock(&h->reply_mutex);
>> 
>> 		/* There should only ever be one response pending! */
>> 		if (!list_empty(&h->reply_list)) {
>> 			mutex_unlock(&h->reply_mutex);
>> +			saved_errno = EEXIST; 
>> 			goto error_freebody;
>> 		}
>> 
>> @@ -1110,9 +1098,11 @@ static int read_message(struct xs_handle
>> 	ret = 0;
>> 
>> error_freebody:
>> -	cleanup_pop(ret == -1);
>> +	if (ret)
>> +		free(body);
>> error_freemsg:
>> -	cleanup_pop(ret == -1);
>> +	if (ret)
>> +		free(msg);
>> error:
>> 	errno = saved_errno;
>> 
> 
> 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 14 14:36:30 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 14: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 1TCWzv-0000Yg-0Y; Fri, 14 Sep 2012 14:35:59 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1TCWzt-0000YY-Ip
	for xen-devel@lists.xensource.com; Fri, 14 Sep 2012 14:35:57 +0000
Received: from [85.158.139.83:44432] by server-6.bemta-5.messagelabs.com id
	BD/14-21336-CC043505; Fri, 14 Sep 2012 14:35:56 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1347633356!27688938!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDkyOTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24802 invoked from network); 14 Sep 2012 14:35:56 -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;
	14 Sep 2012 14:35:56 -0000
X-IronPort-AV: E=Sophos;i="4.80,423,1344211200"; d="scan'208";a="14549248"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Sep 2012 14: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.279.1; Fri, 14 Sep 2012 15:35: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
	1TCWzr-00083u-M8; Fri, 14 Sep 2012 14:35:55 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1TCWzr-0006xz-FV;
	Fri, 14 Sep 2012 15:35:55 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20563.16587.353267.925485@mariner.uk.xensource.com>
Date: Fri, 14 Sep 2012 15:35:55 +0100
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
In-Reply-To: <alpine.DEB.2.02.1209141057280.29232@kaball.uk.xensource.com>
References: <f32959a0c14799617f7f.1346862971@makatos-desktop>
	<20562.6285.724880.885473@mariner.uk.xensource.com>
	<alpine.DEB.2.02.1209131857520.29232@kaball.uk.xensource.com>
	<1347609931.24226.149.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.02.1209141057280.29232@kaball.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Thanos Makatos <thanos.makatos@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH] use spaces instead of tabs in vim
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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] use spaces instead of tabs in vim"):
> That's right, it would be wrong for Linux, but I think it is correct for
> libxl and QEMU (both use 4 whitespaces for indentation), so in practice it
> should be correct for anything under xen-unstable except Makefiles and
> stuff imported as-is from Linux (xen/arch/arm/lib/* for example). Better
> than nothing :)

On that basis, it should go in, I think.

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 Sep 14 14:36:30 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 14: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 1TCWzv-0000Yg-0Y; Fri, 14 Sep 2012 14:35:59 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1TCWzt-0000YY-Ip
	for xen-devel@lists.xensource.com; Fri, 14 Sep 2012 14:35:57 +0000
Received: from [85.158.139.83:44432] by server-6.bemta-5.messagelabs.com id
	BD/14-21336-CC043505; Fri, 14 Sep 2012 14:35:56 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1347633356!27688938!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDkyOTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24802 invoked from network); 14 Sep 2012 14:35:56 -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;
	14 Sep 2012 14:35:56 -0000
X-IronPort-AV: E=Sophos;i="4.80,423,1344211200"; d="scan'208";a="14549248"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Sep 2012 14: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.279.1; Fri, 14 Sep 2012 15:35: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
	1TCWzr-00083u-M8; Fri, 14 Sep 2012 14:35:55 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1TCWzr-0006xz-FV;
	Fri, 14 Sep 2012 15:35:55 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20563.16587.353267.925485@mariner.uk.xensource.com>
Date: Fri, 14 Sep 2012 15:35:55 +0100
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
In-Reply-To: <alpine.DEB.2.02.1209141057280.29232@kaball.uk.xensource.com>
References: <f32959a0c14799617f7f.1346862971@makatos-desktop>
	<20562.6285.724880.885473@mariner.uk.xensource.com>
	<alpine.DEB.2.02.1209131857520.29232@kaball.uk.xensource.com>
	<1347609931.24226.149.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.02.1209141057280.29232@kaball.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Thanos Makatos <thanos.makatos@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH] use spaces instead of tabs in vim
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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] use spaces instead of tabs in vim"):
> That's right, it would be wrong for Linux, but I think it is correct for
> libxl and QEMU (both use 4 whitespaces for indentation), so in practice it
> should be correct for anything under xen-unstable except Makefiles and
> stuff imported as-is from Linux (xen/arch/arm/lib/* for example). Better
> than nothing :)

On that basis, it should go in, I think.

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 Sep 14 14:41:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 14:41: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 1TCX4z-0000lw-3D; Fri, 14 Sep 2012 14:41:13 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1TCX4y-0000lo-2w
	for xen-devel@lists.xen.org; Fri, 14 Sep 2012 14:41:12 +0000
Received: from [85.158.137.99:23611] by server-2.bemta-3.messagelabs.com id
	03/52-04862-70243505; Fri, 14 Sep 2012 14:41:11 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-217.messagelabs.com!1347633668!17676697!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDkyOTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3185 invoked from network); 14 Sep 2012 14:41:09 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Sep 2012 14:41:09 -0000
X-IronPort-AV: E=Sophos;i="4.80,423,1344211200"; d="scan'208";a="14549365"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Sep 2012 14:41:08 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Fri, 14 Sep 2012 15:41: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
	1TCX4u-00088h-Be; Fri, 14 Sep 2012 14:41:08 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1TCX4u-0006yK-7g;
	Fri, 14 Sep 2012 15:41:08 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20563.16899.949080.543875@mariner.uk.xensource.com>
Date: Fri, 14 Sep 2012 15:41:07 +0100
To: Ian Campbell <ian.campbell@citrix.com>
In-Reply-To: <58ab3fb73d13e250f334.1347620998@cosworth.uk.xensource.com>
References: <58ab3fb73d13e250f334.1347620998@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: Enable -Wshadow
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="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: Enable -Wshadow"):
> libxl: Enable -Wshadow.
> 
> It was convenient to invent $(CFLAGS_LIBXL) to do this.
> 
> Various renamings to avoid shadowing standard functions:
>   - index(3)
>   - listen(2)
>   - link(2)
>   - abort(3)
>   - abs(3)

Thanks.

> Reduced the scope of some variables to avoid conflicts.
> 
> Change to libxc is due to the nested hypercall buf macros in
> set_xen_guest_handle (used in libxl) using the same local private vars.
> 
> Build tested only.

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 Sep 14 14:41:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 14:41: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 1TCX4z-0000lw-3D; Fri, 14 Sep 2012 14:41:13 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1TCX4y-0000lo-2w
	for xen-devel@lists.xen.org; Fri, 14 Sep 2012 14:41:12 +0000
Received: from [85.158.137.99:23611] by server-2.bemta-3.messagelabs.com id
	03/52-04862-70243505; Fri, 14 Sep 2012 14:41:11 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-217.messagelabs.com!1347633668!17676697!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDkyOTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3185 invoked from network); 14 Sep 2012 14:41:09 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Sep 2012 14:41:09 -0000
X-IronPort-AV: E=Sophos;i="4.80,423,1344211200"; d="scan'208";a="14549365"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Sep 2012 14:41:08 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Fri, 14 Sep 2012 15:41: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
	1TCX4u-00088h-Be; Fri, 14 Sep 2012 14:41:08 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1TCX4u-0006yK-7g;
	Fri, 14 Sep 2012 15:41:08 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20563.16899.949080.543875@mariner.uk.xensource.com>
Date: Fri, 14 Sep 2012 15:41:07 +0100
To: Ian Campbell <ian.campbell@citrix.com>
In-Reply-To: <58ab3fb73d13e250f334.1347620998@cosworth.uk.xensource.com>
References: <58ab3fb73d13e250f334.1347620998@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: Enable -Wshadow
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="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: Enable -Wshadow"):
> libxl: Enable -Wshadow.
> 
> It was convenient to invent $(CFLAGS_LIBXL) to do this.
> 
> Various renamings to avoid shadowing standard functions:
>   - index(3)
>   - listen(2)
>   - link(2)
>   - abort(3)
>   - abs(3)

Thanks.

> Reduced the scope of some variables to avoid conflicts.
> 
> Change to libxc is due to the nested hypercall buf macros in
> set_xen_guest_handle (used in libxl) using the same local private vars.
> 
> Build tested only.

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 Sep 14 14:42:40 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 14:42: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 1TCX68-0000qH-I4; Fri, 14 Sep 2012 14:42: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 1TCX66-0000q9-JS
	for xen-devel@lists.xen.org; Fri, 14 Sep 2012 14:42:22 +0000
Received: from [85.158.138.51:64230] by server-11.bemta-3.messagelabs.com id
	C8/11-30250-D4243505; Fri, 14 Sep 2012 14:42:21 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1347633740!22645058!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDkyOTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1800 invoked from network); 14 Sep 2012 14:42:21 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Sep 2012 14:42:21 -0000
X-IronPort-AV: E=Sophos;i="4.80,423,1344211200"; d="scan'208";a="14549390"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Sep 2012 14:42: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.279.1; Fri, 14 Sep 2012 15:42: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
	1TCX64-00089L-Cv; Fri, 14 Sep 2012 14:42:20 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1TCX64-0006yY-81;
	Fri, 14 Sep 2012 15:42:20 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20563.16972.124870.221950@mariner.uk.xensource.com>
Date: Fri, 14 Sep 2012 15:42:20 +0100
To: Ian Campbell <ian.campbell@citrix.com>
In-Reply-To: <58ab3fb73d13e250f334.1347620998@cosworth.uk.xensource.com>
References: <58ab3fb73d13e250f334.1347620998@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: Enable -Wshadow
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="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: Enable -Wshadow"):
> libxl: Enable -Wshadow.

Oh I just thought of this:

> diff -r 0547430886c5 -r 58ab3fb73d13 tools/libxc/xenctrl.h
> --- a/tools/libxc/xenctrl.h     Fri Sep 14 11:00:40 2012 +0100
> +++ b/tools/libxc/xenctrl.h     Fri Sep 14 12:09:43 2012 +0100
> @@ -236,10 +236,10 @@ typedef struct xc_hypercall_buffer xc_hy
>   * Returns the hypercall_buffer associated with a variable.
>   */
>  #define HYPERCALL_BUFFER(_name)                                                              \
> -    ({  xc_hypercall_buffer_t _val1;                                                         \
> -        typeof(XC__HYPERCALL_BUFFER_NAME(_name)) *_val2 = &XC__HYPERCALL_BUFFER_NAME(_name); \
> -        (void)(&_val1 == _val2);                                                             \
> -        (_val2)->param_shadow ? (_val2)->param_shadow : (_val2);                             \
> +    ({  xc_hypercall_buffer_t _buf1;                                                         \
> +        typeof(XC__HYPERCALL_BUFFER_NAME(_name)) *_buf2 = &XC__HYPERCALL_BUFFER_NAME(_name); \
> +        (void)(&_buf1 == _buf2);                                                             \
> +        (_buf2)->param_shadow ? (_buf2)->param_shadow : (_buf2);                             \
>       })

This should be something like

> +    ({  xc_hypercall_buffer_t _hcbuf_buf1;

surely ?  As there is (and can be) no reasonable rule requiring users
of this macro to avoid using the name _val1 or whatever.

If we're doing -Wshadow then macros which introduce local variables
like this should give them names qualified somehow for the macro.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 14 14:42:40 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 14:42: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 1TCX68-0000qH-I4; Fri, 14 Sep 2012 14:42: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 1TCX66-0000q9-JS
	for xen-devel@lists.xen.org; Fri, 14 Sep 2012 14:42:22 +0000
Received: from [85.158.138.51:64230] by server-11.bemta-3.messagelabs.com id
	C8/11-30250-D4243505; Fri, 14 Sep 2012 14:42:21 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1347633740!22645058!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDkyOTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1800 invoked from network); 14 Sep 2012 14:42:21 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Sep 2012 14:42:21 -0000
X-IronPort-AV: E=Sophos;i="4.80,423,1344211200"; d="scan'208";a="14549390"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Sep 2012 14:42: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.279.1; Fri, 14 Sep 2012 15:42: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
	1TCX64-00089L-Cv; Fri, 14 Sep 2012 14:42:20 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1TCX64-0006yY-81;
	Fri, 14 Sep 2012 15:42:20 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20563.16972.124870.221950@mariner.uk.xensource.com>
Date: Fri, 14 Sep 2012 15:42:20 +0100
To: Ian Campbell <ian.campbell@citrix.com>
In-Reply-To: <58ab3fb73d13e250f334.1347620998@cosworth.uk.xensource.com>
References: <58ab3fb73d13e250f334.1347620998@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: Enable -Wshadow
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="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: Enable -Wshadow"):
> libxl: Enable -Wshadow.

Oh I just thought of this:

> diff -r 0547430886c5 -r 58ab3fb73d13 tools/libxc/xenctrl.h
> --- a/tools/libxc/xenctrl.h     Fri Sep 14 11:00:40 2012 +0100
> +++ b/tools/libxc/xenctrl.h     Fri Sep 14 12:09:43 2012 +0100
> @@ -236,10 +236,10 @@ typedef struct xc_hypercall_buffer xc_hy
>   * Returns the hypercall_buffer associated with a variable.
>   */
>  #define HYPERCALL_BUFFER(_name)                                                              \
> -    ({  xc_hypercall_buffer_t _val1;                                                         \
> -        typeof(XC__HYPERCALL_BUFFER_NAME(_name)) *_val2 = &XC__HYPERCALL_BUFFER_NAME(_name); \
> -        (void)(&_val1 == _val2);                                                             \
> -        (_val2)->param_shadow ? (_val2)->param_shadow : (_val2);                             \
> +    ({  xc_hypercall_buffer_t _buf1;                                                         \
> +        typeof(XC__HYPERCALL_BUFFER_NAME(_name)) *_buf2 = &XC__HYPERCALL_BUFFER_NAME(_name); \
> +        (void)(&_buf1 == _buf2);                                                             \
> +        (_buf2)->param_shadow ? (_buf2)->param_shadow : (_buf2);                             \
>       })

This should be something like

> +    ({  xc_hypercall_buffer_t _hcbuf_buf1;

surely ?  As there is (and can be) no reasonable rule requiring users
of this macro to avoid using the name _val1 or whatever.

If we're doing -Wshadow then macros which introduce local variables
like this should give them names qualified somehow for the macro.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 14 14:44:51 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 14: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 1TCX8M-0000z4-2n; Fri, 14 Sep 2012 14:44: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 1TCX8L-0000yy-6I
	for xen-devel@lists.xen.org; Fri, 14 Sep 2012 14:44:41 +0000
Received: from [85.158.139.83:19916] by server-7.bemta-5.messagelabs.com id
	B2/66-19703-8D243505; Fri, 14 Sep 2012 14:44:40 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1347633879!27690564!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDkyOTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1359 invoked from network); 14 Sep 2012 14:44:39 -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;
	14 Sep 2012 14:44:39 -0000
X-IronPort-AV: E=Sophos;i="4.80,423,1344211200"; d="scan'208";a="14549435"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Sep 2012 14:44: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.279.1; Fri, 14 Sep 2012 15:44: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
	1TCX8J-0008Dk-1c; Fri, 14 Sep 2012 14:44:39 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1TCX8I-0006yj-TO;
	Fri, 14 Sep 2012 15:44:38 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20563.17110.809168.58412@mariner.uk.xensource.com>
Date: Fri, 14 Sep 2012 15:44:38 +0100
To: Ian Campbell <ian.campbell@citrix.com>
In-Reply-To: <192e4a16a057a456cc78.1347626550@cosworth.uk.xensource.com>
References: <patchbomb.1347626548@cosworth.uk.xensource.com>
	<192e4a16a057a456cc78.1347626550@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 2 of 3] xl: prepare to enable Wshadow
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="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 2 of 3] xl: prepare to enable Wshadow"):
> xl: prepare to enable Wshadow

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 Sep 14 14:44:51 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 14: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 1TCX8M-0000z4-2n; Fri, 14 Sep 2012 14:44: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 1TCX8L-0000yy-6I
	for xen-devel@lists.xen.org; Fri, 14 Sep 2012 14:44:41 +0000
Received: from [85.158.139.83:19916] by server-7.bemta-5.messagelabs.com id
	B2/66-19703-8D243505; Fri, 14 Sep 2012 14:44:40 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1347633879!27690564!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDkyOTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1359 invoked from network); 14 Sep 2012 14:44:39 -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;
	14 Sep 2012 14:44:39 -0000
X-IronPort-AV: E=Sophos;i="4.80,423,1344211200"; d="scan'208";a="14549435"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Sep 2012 14:44: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.279.1; Fri, 14 Sep 2012 15:44: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
	1TCX8J-0008Dk-1c; Fri, 14 Sep 2012 14:44:39 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1TCX8I-0006yj-TO;
	Fri, 14 Sep 2012 15:44:38 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20563.17110.809168.58412@mariner.uk.xensource.com>
Date: Fri, 14 Sep 2012 15:44:38 +0100
To: Ian Campbell <ian.campbell@citrix.com>
In-Reply-To: <192e4a16a057a456cc78.1347626550@cosworth.uk.xensource.com>
References: <patchbomb.1347626548@cosworth.uk.xensource.com>
	<192e4a16a057a456cc78.1347626550@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 2 of 3] xl: prepare to enable Wshadow
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="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 2 of 3] xl: prepare to enable Wshadow"):
> xl: prepare to enable Wshadow

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 Sep 14 14:44:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 14:44: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 1TCX8U-000109-FJ; Fri, 14 Sep 2012 14:44:50 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1TCX8T-0000zs-FL
	for xen-devel@lists.xensource.com; Fri, 14 Sep 2012 14:44:49 +0000
Received: from [85.158.139.211:4568] by server-12.bemta-5.messagelabs.com id
	E2/EA-19338-0E243505; Fri, 14 Sep 2012 14:44:48 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-2.tower-206.messagelabs.com!1347633888!18573570!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDkyOTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29550 invoked from network); 14 Sep 2012 14:44:48 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Sep 2012 14:44:48 -0000
X-IronPort-AV: E=Sophos;i="4.80,423,1344211200"; d="scan'208";a="14549442"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Sep 2012 14:44: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.279.1; Fri, 14 Sep 2012 15:44:48 +0100
Date: Fri, 14 Sep 2012 15:44:05 +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: <20120914130807.GK25249@phenom.dumpdata.com>
Message-ID: <alpine.DEB.2.02.1209141530340.29232@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1209141145150.29232@kaball.uk.xensource.com>
	<1347621207-11294-7-git-send-email-stefano.stabellini@eu.citrix.com>
	<20120914130807.GK25249@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>,
	"linaro-dev@lists.linaro.org" <linaro-dev@lists.linaro.org>,
	Ian Campbell <Ian.Campbell@citrix.com>, "arnd@arndb.de" <arnd@arndb.de>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"catalin.marinas@arm.com" <catalin.marinas@arm.com>,
	"Tim \(Xen.org\)" <tim@xen.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux@arm.linux.org.uk" <linux@arm.linux.org.uk>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Xen-devel] [PATCH v4 07/24] xen/arm: Xen detection and
 shared_info page mapping
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 14 Sep 2012, Konrad Rzeszutek Wilk wrote:
> On Fri, Sep 14, 2012 at 12:13:09PM +0100, Stefano Stabellini wrote:
> > Check for a node in the device tree compatible with "xen,xen", if it is
> > present set xen_domain_type to XEN_HVM_DOMAIN and continue
> > initialization.
> > 
> > Map the real shared info page using XENMEM_add_to_physmap with
> > XENMAPSPACE_shared_info.
> > 
> > Changes in v4:
> > 
> > - simpler parsing of Xen version in the compatible DT node.
> > 
> > Changes in v3:
> > 
> > - use the "xen,xen" notation rather than "arm,xen";
> > - add an additional check on the presence of the Xen version.
> > 
> > Changes in v2:
> > 
> > - replace pr_info with pr_debug.
> > 
> > Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> > ---
> >  arch/arm/xen/enlighten.c |   61 ++++++++++++++++++++++++++++++++++++++++++++++
> >  1 files changed, 61 insertions(+), 0 deletions(-)
> > 
> > diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
> > index c535540..6a0217d 100644
> > --- a/arch/arm/xen/enlighten.c
> > +++ b/arch/arm/xen/enlighten.c
> > @@ -5,6 +5,9 @@
> >  #include <asm/xen/hypervisor.h>
> >  #include <asm/xen/hypercall.h>
> >  #include <linux/module.h>
> > +#include <linux/of.h>
> > +#include <linux/of_irq.h>
> > +#include <linux/of_address.h>
> >  
> >  struct start_info _xen_start_info;
> >  struct start_info *xen_start_info = &_xen_start_info;
> > @@ -33,3 +36,61 @@ int xen_remap_domain_mfn_range(struct vm_area_struct *vma,
> >  	return -ENOSYS;
> >  }
> >  EXPORT_SYMBOL_GPL(xen_remap_domain_mfn_range);
> > +
> > +/*
> > + * see Documentation/devicetree/bindings/arm/xen.txt for the
> > + * documentation of the Xen Device Tree format.
> > + */
> > +static int __init xen_guest_init(void)
> > +{
> > +	struct xen_add_to_physmap xatp;
> > +	static struct shared_info *shared_info_page = 0;
> > +	struct device_node *node;
> > +	int len;
> > +	const char *s = NULL;
> > +	const char *version = NULL;
> > +	const char *xen_prefix = "xen,xen-";
> > +
> > +	node = of_find_compatible_node(NULL, NULL, "xen,xen");
> > +	if (!node) {
> > +		pr_debug("No Xen support\n");
> > +		return 0;
> > +	}
> > +	s = of_get_property(node, "compatible", &len);
> > +	if (strlen(xen_prefix) + 3  < len &&
> > +			!strncmp(xen_prefix, s, strlen(xen_prefix)))
> 
> If we have version '4.3.1' won't this trip us over?

This isn't an issue:

if (8 + 3 < 14 &&
    !strncmp("xen,xen-", "xen,xen-4.3.1", 8)

would return true

and version is set to "4.3.1".


> Or if we only have 'major' and 'minor', then won't '4.11' trip us
> over too?

For the same reason this shouldn't be an issue either:

if (8 + 3 < 13 &&
    !strncmp("xen,xen-", "xen,xen-4.11", 8)

would return true

and version would be set to "4.11".

BTW I have just tried both out of paranoia and it works as expected.


> > +		version = s + strlen(xen_prefix);
> > +	if (version == NULL) {
> > +		pr_debug("Xen version not found\n");
> > +		return 0;
> > +	}
> > +	xen_domain_type = XEN_HVM_DOMAIN;
> > +
> > +	if (!shared_info_page)
> > +		shared_info_page = (struct shared_info *)
> > +			get_zeroed_page(GFP_KERNEL);
> > +	if (!shared_info_page) {
> > +		pr_err("not enough memory\n");
> > +		return -ENOMEM;
> > +	}
> > +	xatp.domid = DOMID_SELF;
> > +	xatp.idx = 0;
> > +	xatp.space = XENMAPSPACE_shared_info;
> > +	xatp.gpfn = __pa(shared_info_page) >> PAGE_SHIFT;
> > +	if (HYPERVISOR_memory_op(XENMEM_add_to_physmap, &xatp))
> > +		BUG();
> > +
> > +	HYPERVISOR_shared_info = (struct shared_info *)shared_info_page;
> > +
> > +	/* xen_vcpu is a pointer to the vcpu_info struct in the shared_info
> > +	 * page, we use it in the event channel upcall and in some pvclock
> > +	 * related functions. We don't need the vcpu_info placement
> > +	 * optimizations because we don't use any pv_mmu or pv_irq op on
> > +	 * HVM.
> > +	 * The shared info contains exactly 1 CPU (the boot CPU). The guest
> > +	 * is required to use VCPUOP_register_vcpu_info to place vcpu info
> > +	 * for secondary CPUs as they are brought up. */
> > +	per_cpu(xen_vcpu, 0) = &HYPERVISOR_shared_info->vcpu_info[0];
> > +	return 0;
> > +}
> > +core_initcall(xen_guest_init);
> > -- 
> > 1.7.2.5
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 14 14:44:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 14:44: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 1TCX8U-000109-FJ; Fri, 14 Sep 2012 14:44:50 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1TCX8T-0000zs-FL
	for xen-devel@lists.xensource.com; Fri, 14 Sep 2012 14:44:49 +0000
Received: from [85.158.139.211:4568] by server-12.bemta-5.messagelabs.com id
	E2/EA-19338-0E243505; Fri, 14 Sep 2012 14:44:48 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-2.tower-206.messagelabs.com!1347633888!18573570!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDkyOTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29550 invoked from network); 14 Sep 2012 14:44:48 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Sep 2012 14:44:48 -0000
X-IronPort-AV: E=Sophos;i="4.80,423,1344211200"; d="scan'208";a="14549442"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Sep 2012 14:44: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.279.1; Fri, 14 Sep 2012 15:44:48 +0100
Date: Fri, 14 Sep 2012 15:44:05 +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: <20120914130807.GK25249@phenom.dumpdata.com>
Message-ID: <alpine.DEB.2.02.1209141530340.29232@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1209141145150.29232@kaball.uk.xensource.com>
	<1347621207-11294-7-git-send-email-stefano.stabellini@eu.citrix.com>
	<20120914130807.GK25249@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>,
	"linaro-dev@lists.linaro.org" <linaro-dev@lists.linaro.org>,
	Ian Campbell <Ian.Campbell@citrix.com>, "arnd@arndb.de" <arnd@arndb.de>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"catalin.marinas@arm.com" <catalin.marinas@arm.com>,
	"Tim \(Xen.org\)" <tim@xen.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux@arm.linux.org.uk" <linux@arm.linux.org.uk>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Xen-devel] [PATCH v4 07/24] xen/arm: Xen detection and
 shared_info page mapping
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 14 Sep 2012, Konrad Rzeszutek Wilk wrote:
> On Fri, Sep 14, 2012 at 12:13:09PM +0100, Stefano Stabellini wrote:
> > Check for a node in the device tree compatible with "xen,xen", if it is
> > present set xen_domain_type to XEN_HVM_DOMAIN and continue
> > initialization.
> > 
> > Map the real shared info page using XENMEM_add_to_physmap with
> > XENMAPSPACE_shared_info.
> > 
> > Changes in v4:
> > 
> > - simpler parsing of Xen version in the compatible DT node.
> > 
> > Changes in v3:
> > 
> > - use the "xen,xen" notation rather than "arm,xen";
> > - add an additional check on the presence of the Xen version.
> > 
> > Changes in v2:
> > 
> > - replace pr_info with pr_debug.
> > 
> > Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> > ---
> >  arch/arm/xen/enlighten.c |   61 ++++++++++++++++++++++++++++++++++++++++++++++
> >  1 files changed, 61 insertions(+), 0 deletions(-)
> > 
> > diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
> > index c535540..6a0217d 100644
> > --- a/arch/arm/xen/enlighten.c
> > +++ b/arch/arm/xen/enlighten.c
> > @@ -5,6 +5,9 @@
> >  #include <asm/xen/hypervisor.h>
> >  #include <asm/xen/hypercall.h>
> >  #include <linux/module.h>
> > +#include <linux/of.h>
> > +#include <linux/of_irq.h>
> > +#include <linux/of_address.h>
> >  
> >  struct start_info _xen_start_info;
> >  struct start_info *xen_start_info = &_xen_start_info;
> > @@ -33,3 +36,61 @@ int xen_remap_domain_mfn_range(struct vm_area_struct *vma,
> >  	return -ENOSYS;
> >  }
> >  EXPORT_SYMBOL_GPL(xen_remap_domain_mfn_range);
> > +
> > +/*
> > + * see Documentation/devicetree/bindings/arm/xen.txt for the
> > + * documentation of the Xen Device Tree format.
> > + */
> > +static int __init xen_guest_init(void)
> > +{
> > +	struct xen_add_to_physmap xatp;
> > +	static struct shared_info *shared_info_page = 0;
> > +	struct device_node *node;
> > +	int len;
> > +	const char *s = NULL;
> > +	const char *version = NULL;
> > +	const char *xen_prefix = "xen,xen-";
> > +
> > +	node = of_find_compatible_node(NULL, NULL, "xen,xen");
> > +	if (!node) {
> > +		pr_debug("No Xen support\n");
> > +		return 0;
> > +	}
> > +	s = of_get_property(node, "compatible", &len);
> > +	if (strlen(xen_prefix) + 3  < len &&
> > +			!strncmp(xen_prefix, s, strlen(xen_prefix)))
> 
> If we have version '4.3.1' won't this trip us over?

This isn't an issue:

if (8 + 3 < 14 &&
    !strncmp("xen,xen-", "xen,xen-4.3.1", 8)

would return true

and version is set to "4.3.1".


> Or if we only have 'major' and 'minor', then won't '4.11' trip us
> over too?

For the same reason this shouldn't be an issue either:

if (8 + 3 < 13 &&
    !strncmp("xen,xen-", "xen,xen-4.11", 8)

would return true

and version would be set to "4.11".

BTW I have just tried both out of paranoia and it works as expected.


> > +		version = s + strlen(xen_prefix);
> > +	if (version == NULL) {
> > +		pr_debug("Xen version not found\n");
> > +		return 0;
> > +	}
> > +	xen_domain_type = XEN_HVM_DOMAIN;
> > +
> > +	if (!shared_info_page)
> > +		shared_info_page = (struct shared_info *)
> > +			get_zeroed_page(GFP_KERNEL);
> > +	if (!shared_info_page) {
> > +		pr_err("not enough memory\n");
> > +		return -ENOMEM;
> > +	}
> > +	xatp.domid = DOMID_SELF;
> > +	xatp.idx = 0;
> > +	xatp.space = XENMAPSPACE_shared_info;
> > +	xatp.gpfn = __pa(shared_info_page) >> PAGE_SHIFT;
> > +	if (HYPERVISOR_memory_op(XENMEM_add_to_physmap, &xatp))
> > +		BUG();
> > +
> > +	HYPERVISOR_shared_info = (struct shared_info *)shared_info_page;
> > +
> > +	/* xen_vcpu is a pointer to the vcpu_info struct in the shared_info
> > +	 * page, we use it in the event channel upcall and in some pvclock
> > +	 * related functions. We don't need the vcpu_info placement
> > +	 * optimizations because we don't use any pv_mmu or pv_irq op on
> > +	 * HVM.
> > +	 * The shared info contains exactly 1 CPU (the boot CPU). The guest
> > +	 * is required to use VCPUOP_register_vcpu_info to place vcpu info
> > +	 * for secondary CPUs as they are brought up. */
> > +	per_cpu(xen_vcpu, 0) = &HYPERVISOR_shared_info->vcpu_info[0];
> > +	return 0;
> > +}
> > +core_initcall(xen_guest_init);
> > -- 
> > 1.7.2.5
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 14 14:51:10 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 14: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 1TCXET-0001LJ-9k; Fri, 14 Sep 2012 14:51:01 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1TCXER-0001LE-FZ
	for xen-devel@lists.xensource.com; Fri, 14 Sep 2012 14:50:59 +0000
Received: from [85.158.137.99:51927] by server-5.bemta-3.messagelabs.com id
	75/DA-13133-25443505; Fri, 14 Sep 2012 14:50:58 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-217.messagelabs.com!1347634257!12906474!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDkyOTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6521 invoked from network); 14 Sep 2012 14:50:57 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Sep 2012 14:50:57 -0000
X-IronPort-AV: E=Sophos;i="4.80,423,1344211200"; d="scan'208";a="14549612"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Sep 2012 14:50: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.279.1; Fri, 14 Sep 2012 15:50: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 1TCXEP-0008KW-1q;
	Fri, 14 Sep 2012 14:50:57 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1TCXEO-0002zw-MP;
	Fri, 14 Sep 2012 15:50:56 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-13762-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 14 Sep 2012 15:50:56 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13762: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 13762 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13762/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-win7-amd64  5 xen-boot                 fail REGR. vs. 13760

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore            fail   like 13760
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail like 13760
 test-amd64-amd64-xl-sedf     14 guest-localmigrate/x10    fail REGR. vs. 13760
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail like 13760

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  28bb7ba5faf6
baseline version:
 xen                  5613018f93b1

------------------------------------------------------------
People who touched revisions under test:
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jason McCarver <slam@parasite.cc>
  Juergen Gross<juergen.gross@ts.fujitsu.com>
  Keir Fraser <keir@xen.org>
  Matt Wilson <msw@amazon.com>
  Olaf Hering <olaf@aepfle.de>
  Roger Pau Monne <roger.pau@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-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-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-amd64-amd64-xl-win                                      fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
changeset:   25902:28bb7ba5faf6
tag:         tip
user:        Ian Jackson <Ian.Jackson@eu.citrix.com>
date:        Fri Sep 14 10:25:15 2012 +0100
    
    libxl: Tolerate xl config files missing trailing newline
    
    Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
    Acked-by: Ian Campbell <ian.campbell@citrix.com>
    Committed-by: Ian Campbell <ian.campbell@citrix.com>
    
    
changeset:   25901:c51229d1522e
user:        Ian Jackson <Ian.Jackson@eu.citrix.com>
date:        Fri Sep 14 10:02:52 2012 +0100
    
    libxl: Fix missing dependency in api check rule
    
    Without this, the api check cpp run might happen before the various
    autogenerated files which are #include by libxl.h are ready.
    
    We need to remove the api-ok file from AUTOINCS to avoid a circular
    dependency.  Instead, we list it explicitly as a dependency of the
    object files.  The result is that the api check is the last thing to
    be done before make considers the preparation done and can start work
    on compiling .c files into .o's.
    
    Reported-by: Olaf Hering <olaf@aepfle.de>
    Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
    Tested-by: Olaf Hering <olaf@aepfle.de>
    Acked-by: Ian Campbell <ian.campbell@citrix.com>
    Committed-by: Ian Campbell <ian.campbell@citrix.com>
    
    
changeset:   25900:0b03d5624025
user:        Matt Wilson <msw@amazon.com>
date:        Fri Sep 14 10:02:51 2012 +0100
    
    docs: flesh out xl.cfg documentation, correct typos, reorganize
    
    Some highlights:
     * Correct some markup errors:
           Around line 663:
               '=item' outside of any '=over'
           Around line 671:
               You forgot a '=back' before '=head3'
     * Add documentation for msitranslate, power_mgnt, acpi_s3, aspi_s4,
       gfx_passthru, nomigrate, etc.
     * Reorganize items in "unclassified" sections like cpuid,
       gfx_passthru to where they belong
     * Correct link L<> references so they can be resolved within the
       document
     * Remove placeholders for deprecated options device_model and vif2
     * Remove placeholder for "sched" and "node", as these are options for
       cpupool configuration. Perhaps cpupool configuration deserves
       a section in this document.
     * Rename "global" options to "general"
     * Add section headers to group general VM options.
    
    Signed-off-by: Matt Wilson <msw@amazon.com>
    Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
    Committed-by: Ian Campbell <ian.campbell@citrix.com>
    
    
changeset:   25899:116f5c34354b
user:        Jason McCarver <slam@parasite.cc>
date:        Fri Sep 14 10:02:51 2012 +0100
    
    xentop.c: Change curses painting behavior to avoid flicker
    
    Currently, xentop calls clear() before drawing the screen and calling
    refresh().  This causes the entire screen to be repainted from scratch
    on each call to refresh().  It is inefficient and causes visible flicker
    when using xentop.
    
    This patch fixes this by calling erase() instead of clear() which overwrites
    the current screen with blanks instead.  The screen is then drawn as usual
    in the top() function and refresh() is called.  This method allows curses
    to only repaint the characters that have changed since the last call
    to refresh(), thus avoiding the flicker and sending fewer characters to
    the terminal.
    
    In the event the screen becomes corrupted, this patch accepts a CTRL-L
    keystroke from the user which will call clear() and force a repaint of
    the entire screen.
    
    Signed-off-by: Jason McCarver <slam@parasite.cc>
    Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
    Committed-by: Ian Campbell <ian.campbell@citrix.com>
    
    
changeset:   25898:6ba5dd841439
user:        Ian Campbell <ian.campbell@citrix.com>
date:        Fri Sep 14 10:02:50 2012 +0100
    
    xl: do not leak cpupool names.
    
    Valgrind reports:
    ==3076== 7 bytes in 1 blocks are definitely lost in loss record 1 of 1
    ==3076==    at 0x402458C: malloc (vg_replace_malloc.c:270)
    ==3076==    by 0x406F86D: libxl_cpupoolid_to_name (libxl_utils.c:102)
    ==3076==    by 0x8058742: parse_config_data (xl_cmdimpl.c:639)
    ==3076==    by 0x805BD56: create_domain (xl_cmdimpl.c:1838)
    ==3076==    by 0x805DAED: main_create (xl_cmdimpl.c:3903)
    ==3076==    by 0x804D39D: main (xl.c:285)
    
    And indeed there are several places where xl uses
    libxl_cpupoolid_to_name as a boolean to test if the pool name is
    valid and leaks the name if it is. Introduce an is_valid helper and
    use that instead.
    
    Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
    Acked-by: Juergen Gross<juergen.gross@ts.fujitsu.com>
    Committed-by: Ian Campbell <ian.campbell@citrix.com>
    
    
changeset:   25897:ff6d94944039
user:        Roger Pau Monne <roger.pau@citrix.com>
date:        Fri Sep 14 10:02:49 2012 +0100
    
    xl: error if vif backend!=0 is used with run_hotplug_scripts
    
    Print an error and exit if backend!=0 is used in conjunction with
    run_hotplug_scripts. Currently libxl can only execute hotplug scripts
    from the toolstack domain (the same domain xl is running from).
    
    Added a description and workaround of this issue on
    xl-network-configuration.
    
    Signed-off-by: Roger Pau Monne <roger.pau@citrix.com>
    Acked-by: Ian Campbell <ian.campbell@citrix.com>
    Committed-by: Ian Campbell <ian.campbell@citrix.com>
    
    
changeset:   25896:259c4e9d8adf
user:        Roger Pau Monne <roger.pau@citrix.com>
date:        Fri Sep 14 10:02:48 2012 +0100
    
    libxl: fix usage of backend parameter and run_hotplug_scripts
    
    vif interfaces allows the user to specify the domain that should run
    the backend (also known as driver domain) using the 'backend'
    parameter. This is not compatible with run_hotplug_scripts=1, since
    libxl can only run the hotplug scripts from the Domain 0.
    
    Signed-off-by: Roger Pau Monne <roger.pau@citrix.com>
    Acked-by: Ian Campbell <ian.campbell@citrix.com>
    Committed-by: Ian Campbell <ian.campbell@citrix.com>
    
    
changeset:   25895:98e1ba6a672a
user:        Roger Pau Monne <roger.pau@citrix.com>
date:        Fri Sep 14 10:02:47 2012 +0100
    
    libfsimage: add ext4 support for CentOS 5.x
    
    CentOS 5.x forked e2fs ext4 support into a different package called
    e4fs, and so headers and library names changed from ext2fs to ext4fs.
    Check if ext4fs/ext2fs.h and -lext4fs work, and use that instead of
    ext2fs to build libfsimage. This patch assumes that if the ext4fs
    library is present it should always be used instead of ext2fs.
    
    This patch includes a rework of the ext2fs check, a new ext4fs check
    and a minor modification in libfsimage to use the correct library.
    
    Signed-off-by: Roger Pau Monne <roger.pau@citrix.com>
    Acked-by: Ian Campbell <ian.campbell@citrix.com>
    Committed-by: Ian Campbell <ian.campbell@citrix.com>
    
    
changeset:   25894:95a971c8058f
user:        Ian Campbell <Ian.Campbell@citrix.com>
date:        Fri Sep 14 10:02:46 2012 +0100
    
    libxl: handle errors from xc_sharing_* info functions
    
    On a 32 bit hypervisor xl info currently reports:
    sharing_freed_memory   : 72057594037927935
    sharing_used_memory    : 72057594037927935
    
    Eat the ENOSYS and turn it into 0. Log and propagate other errors.
    
    I don't have a 32 bit system handy, so tested on x86_64 with a libxc
    hacked to return -ENOSYS and -EINVAL.
    
    Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
    Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
    Acked-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
    Committed-by: Ian Campbell <ian.campbell@citrix.com>
    
    
changeset:   25893:5613018f93b1
user:        Keir Fraser <keir@xen.org>
date:        Thu Sep 13 20:13:36 2012 +0100
    
    build: Require GCC 4.1 or later.
    
    Centralise the version check in Config.mk. Any more strict version
    requirements can be added to specific subdirs/arches.
    
    Signed-off-by: Keir Fraser <keir@xen.org>
    
    
(qemu changes not included)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 14 14:51:10 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 14: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 1TCXET-0001LJ-9k; Fri, 14 Sep 2012 14:51:01 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1TCXER-0001LE-FZ
	for xen-devel@lists.xensource.com; Fri, 14 Sep 2012 14:50:59 +0000
Received: from [85.158.137.99:51927] by server-5.bemta-3.messagelabs.com id
	75/DA-13133-25443505; Fri, 14 Sep 2012 14:50:58 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-217.messagelabs.com!1347634257!12906474!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDkyOTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6521 invoked from network); 14 Sep 2012 14:50:57 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Sep 2012 14:50:57 -0000
X-IronPort-AV: E=Sophos;i="4.80,423,1344211200"; d="scan'208";a="14549612"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Sep 2012 14:50: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.279.1; Fri, 14 Sep 2012 15:50: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 1TCXEP-0008KW-1q;
	Fri, 14 Sep 2012 14:50:57 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1TCXEO-0002zw-MP;
	Fri, 14 Sep 2012 15:50:56 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-13762-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 14 Sep 2012 15:50:56 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13762: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 13762 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13762/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-win7-amd64  5 xen-boot                 fail REGR. vs. 13760

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore            fail   like 13760
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail like 13760
 test-amd64-amd64-xl-sedf     14 guest-localmigrate/x10    fail REGR. vs. 13760
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail like 13760

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  28bb7ba5faf6
baseline version:
 xen                  5613018f93b1

------------------------------------------------------------
People who touched revisions under test:
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jason McCarver <slam@parasite.cc>
  Juergen Gross<juergen.gross@ts.fujitsu.com>
  Keir Fraser <keir@xen.org>
  Matt Wilson <msw@amazon.com>
  Olaf Hering <olaf@aepfle.de>
  Roger Pau Monne <roger.pau@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-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-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-amd64-amd64-xl-win                                      fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
changeset:   25902:28bb7ba5faf6
tag:         tip
user:        Ian Jackson <Ian.Jackson@eu.citrix.com>
date:        Fri Sep 14 10:25:15 2012 +0100
    
    libxl: Tolerate xl config files missing trailing newline
    
    Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
    Acked-by: Ian Campbell <ian.campbell@citrix.com>
    Committed-by: Ian Campbell <ian.campbell@citrix.com>
    
    
changeset:   25901:c51229d1522e
user:        Ian Jackson <Ian.Jackson@eu.citrix.com>
date:        Fri Sep 14 10:02:52 2012 +0100
    
    libxl: Fix missing dependency in api check rule
    
    Without this, the api check cpp run might happen before the various
    autogenerated files which are #include by libxl.h are ready.
    
    We need to remove the api-ok file from AUTOINCS to avoid a circular
    dependency.  Instead, we list it explicitly as a dependency of the
    object files.  The result is that the api check is the last thing to
    be done before make considers the preparation done and can start work
    on compiling .c files into .o's.
    
    Reported-by: Olaf Hering <olaf@aepfle.de>
    Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
    Tested-by: Olaf Hering <olaf@aepfle.de>
    Acked-by: Ian Campbell <ian.campbell@citrix.com>
    Committed-by: Ian Campbell <ian.campbell@citrix.com>
    
    
changeset:   25900:0b03d5624025
user:        Matt Wilson <msw@amazon.com>
date:        Fri Sep 14 10:02:51 2012 +0100
    
    docs: flesh out xl.cfg documentation, correct typos, reorganize
    
    Some highlights:
     * Correct some markup errors:
           Around line 663:
               '=item' outside of any '=over'
           Around line 671:
               You forgot a '=back' before '=head3'
     * Add documentation for msitranslate, power_mgnt, acpi_s3, aspi_s4,
       gfx_passthru, nomigrate, etc.
     * Reorganize items in "unclassified" sections like cpuid,
       gfx_passthru to where they belong
     * Correct link L<> references so they can be resolved within the
       document
     * Remove placeholders for deprecated options device_model and vif2
     * Remove placeholder for "sched" and "node", as these are options for
       cpupool configuration. Perhaps cpupool configuration deserves
       a section in this document.
     * Rename "global" options to "general"
     * Add section headers to group general VM options.
    
    Signed-off-by: Matt Wilson <msw@amazon.com>
    Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
    Committed-by: Ian Campbell <ian.campbell@citrix.com>
    
    
changeset:   25899:116f5c34354b
user:        Jason McCarver <slam@parasite.cc>
date:        Fri Sep 14 10:02:51 2012 +0100
    
    xentop.c: Change curses painting behavior to avoid flicker
    
    Currently, xentop calls clear() before drawing the screen and calling
    refresh().  This causes the entire screen to be repainted from scratch
    on each call to refresh().  It is inefficient and causes visible flicker
    when using xentop.
    
    This patch fixes this by calling erase() instead of clear() which overwrites
    the current screen with blanks instead.  The screen is then drawn as usual
    in the top() function and refresh() is called.  This method allows curses
    to only repaint the characters that have changed since the last call
    to refresh(), thus avoiding the flicker and sending fewer characters to
    the terminal.
    
    In the event the screen becomes corrupted, this patch accepts a CTRL-L
    keystroke from the user which will call clear() and force a repaint of
    the entire screen.
    
    Signed-off-by: Jason McCarver <slam@parasite.cc>
    Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
    Committed-by: Ian Campbell <ian.campbell@citrix.com>
    
    
changeset:   25898:6ba5dd841439
user:        Ian Campbell <ian.campbell@citrix.com>
date:        Fri Sep 14 10:02:50 2012 +0100
    
    xl: do not leak cpupool names.
    
    Valgrind reports:
    ==3076== 7 bytes in 1 blocks are definitely lost in loss record 1 of 1
    ==3076==    at 0x402458C: malloc (vg_replace_malloc.c:270)
    ==3076==    by 0x406F86D: libxl_cpupoolid_to_name (libxl_utils.c:102)
    ==3076==    by 0x8058742: parse_config_data (xl_cmdimpl.c:639)
    ==3076==    by 0x805BD56: create_domain (xl_cmdimpl.c:1838)
    ==3076==    by 0x805DAED: main_create (xl_cmdimpl.c:3903)
    ==3076==    by 0x804D39D: main (xl.c:285)
    
    And indeed there are several places where xl uses
    libxl_cpupoolid_to_name as a boolean to test if the pool name is
    valid and leaks the name if it is. Introduce an is_valid helper and
    use that instead.
    
    Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
    Acked-by: Juergen Gross<juergen.gross@ts.fujitsu.com>
    Committed-by: Ian Campbell <ian.campbell@citrix.com>
    
    
changeset:   25897:ff6d94944039
user:        Roger Pau Monne <roger.pau@citrix.com>
date:        Fri Sep 14 10:02:49 2012 +0100
    
    xl: error if vif backend!=0 is used with run_hotplug_scripts
    
    Print an error and exit if backend!=0 is used in conjunction with
    run_hotplug_scripts. Currently libxl can only execute hotplug scripts
    from the toolstack domain (the same domain xl is running from).
    
    Added a description and workaround of this issue on
    xl-network-configuration.
    
    Signed-off-by: Roger Pau Monne <roger.pau@citrix.com>
    Acked-by: Ian Campbell <ian.campbell@citrix.com>
    Committed-by: Ian Campbell <ian.campbell@citrix.com>
    
    
changeset:   25896:259c4e9d8adf
user:        Roger Pau Monne <roger.pau@citrix.com>
date:        Fri Sep 14 10:02:48 2012 +0100
    
    libxl: fix usage of backend parameter and run_hotplug_scripts
    
    vif interfaces allows the user to specify the domain that should run
    the backend (also known as driver domain) using the 'backend'
    parameter. This is not compatible with run_hotplug_scripts=1, since
    libxl can only run the hotplug scripts from the Domain 0.
    
    Signed-off-by: Roger Pau Monne <roger.pau@citrix.com>
    Acked-by: Ian Campbell <ian.campbell@citrix.com>
    Committed-by: Ian Campbell <ian.campbell@citrix.com>
    
    
changeset:   25895:98e1ba6a672a
user:        Roger Pau Monne <roger.pau@citrix.com>
date:        Fri Sep 14 10:02:47 2012 +0100
    
    libfsimage: add ext4 support for CentOS 5.x
    
    CentOS 5.x forked e2fs ext4 support into a different package called
    e4fs, and so headers and library names changed from ext2fs to ext4fs.
    Check if ext4fs/ext2fs.h and -lext4fs work, and use that instead of
    ext2fs to build libfsimage. This patch assumes that if the ext4fs
    library is present it should always be used instead of ext2fs.
    
    This patch includes a rework of the ext2fs check, a new ext4fs check
    and a minor modification in libfsimage to use the correct library.
    
    Signed-off-by: Roger Pau Monne <roger.pau@citrix.com>
    Acked-by: Ian Campbell <ian.campbell@citrix.com>
    Committed-by: Ian Campbell <ian.campbell@citrix.com>
    
    
changeset:   25894:95a971c8058f
user:        Ian Campbell <Ian.Campbell@citrix.com>
date:        Fri Sep 14 10:02:46 2012 +0100
    
    libxl: handle errors from xc_sharing_* info functions
    
    On a 32 bit hypervisor xl info currently reports:
    sharing_freed_memory   : 72057594037927935
    sharing_used_memory    : 72057594037927935
    
    Eat the ENOSYS and turn it into 0. Log and propagate other errors.
    
    I don't have a 32 bit system handy, so tested on x86_64 with a libxc
    hacked to return -ENOSYS and -EINVAL.
    
    Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
    Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
    Acked-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
    Committed-by: Ian Campbell <ian.campbell@citrix.com>
    
    
changeset:   25893:5613018f93b1
user:        Keir Fraser <keir@xen.org>
date:        Thu Sep 13 20:13:36 2012 +0100
    
    build: Require GCC 4.1 or later.
    
    Centralise the version check in Config.mk. Any more strict version
    requirements can be added to specific subdirs/arches.
    
    Signed-off-by: Keir Fraser <keir@xen.org>
    
    
(qemu changes not included)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 14 14:52:48 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 14:52:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TCXG3-0001RV-3W; Fri, 14 Sep 2012 14:52:39 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1TCXG2-0001RM-1Z
	for xen-devel@lists.xen.org; Fri, 14 Sep 2012 14:52:38 +0000
Received: from [85.158.143.35:12525] by server-1.bemta-4.messagelabs.com id
	84/CA-12504-5B443505; Fri, 14 Sep 2012 14:52:37 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-13.tower-21.messagelabs.com!1347634356!16912485!1
X-Originating-IP: [208.97.132.119]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4xMTkgPT4gMzQ1ODg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10298 invoked from network); 14 Sep 2012 14:52:36 -0000
Received: from caiajhbdcbbj.dreamhost.com (HELO homiemail-a19.g.dreamhost.com)
	(208.97.132.119) by server-13.tower-21.messagelabs.com with SMTP;
	14 Sep 2012 14:52:36 -0000
Received: from homiemail-a19.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a19.g.dreamhost.com (Postfix) with ESMTP id B175260407C;
	Fri, 14 Sep 2012 07:52:35 -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=YhOKDnlx9L+b/v+kEVTJdu
	DCmdnv9L56Kr/QWWtscG72tuD+JsM2jDCXJbSzPqJnGTFphypi+YcgJ/AasJgGAa
	gXCzQBQJ+OVPXPHTXIMq2GtkBghQb06BnmayMSrTHFgg7bp6TnBxBxDXEyuKED0t
	GhBshTvylBQxKiJFw0Zrw=
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=Gcd12dH2A1td
	JCnw2KHixMeK2oI=; b=orPTXgxVpUr6k0ktaYY6oh8eDaGK0YD0tFZQqlfF+w83
	8S/JE3M+mbvNE0K6xbzZaP1fM3QuBBknpnGnJoqOwcszXlBjX6MPRaywh5l7FMD/
	KQM4KHtrbhsPs+Zl9nUZ6qWVuUnYVr3/LnuUTxd2Nmg5kDtw1qqlR/YmAlhpvl0=
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-a19.g.dreamhost.com (Postfix) with ESMTPSA id 363C0604079; 
	Fri, 14 Sep 2012 07:52:35 -0700 (PDT)
MIME-Version: 1.0
X-Mercurial-Node: a83fd69dcb277ce12bf6203e0f69071a47d9b24f
Message-Id: <a83fd69dcb277ce12bf6.1347634735@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Fri, 14 Sep 2012 10:58:55 -0400
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xen.org
Cc: ian.jackson@citrix.com, andres@gridcentric.ca, ian.campbell@citrix.com
Subject: [Xen-devel] [PATCH] Fix libxenstore memory leak when USE_PTHREAD is
 not defined, 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

 tools/xenstore/xs.c |  17 +++++++++++++----
 1 files changed, 13 insertions(+), 4 deletions(-)


Redefine usage of pthread_cleanup_push and _pop, to explicitly call free for
heap objects in error paths.

By the way, set a suitable errno value for an error path that had none.

This is V2 after comments from Ian Campbell.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r 588d0dc298a4 -r a83fd69dcb27 tools/xenstore/xs.c
--- a/tools/xenstore/xs.c
+++ b/tools/xenstore/xs.c
@@ -110,6 +110,11 @@ struct xs_handle {
 
 #define read_thread_exists(h)	(h->read_thr_exists)
 
+/* Because pthread_cleanup_p* are not available when USE_PTHREAD is
+ * disabled, use these macros which convert appropriately. */
+#define cleanup_push_heap(p)        cleanup_push(free, p)
+#define cleanup_pop_heap(run, p)    cleanup_pop((run))
+
 static void *read_thread(void *arg);
 
 #else /* !defined(USE_PTHREAD) */
@@ -130,6 +135,9 @@ struct xs_handle {
 #define cleanup_pop(run)	((void)0)
 #define read_thread_exists(h)	(0)
 
+#define cleanup_push_heap(p)        ((void)0)
+#define cleanup_pop_heap(run, p)    do { if ((run)) free(p); } while(0)
+
 #endif
 
 static int read_message(struct xs_handle *h, int nonblocking);
@@ -1059,7 +1067,7 @@ static int read_message(struct xs_handle
 	msg = malloc(sizeof(*msg));
 	if (msg == NULL)
 		goto error;
-	cleanup_push(free, msg);
+	cleanup_push_heap(msg);
 	if (!read_all(h->fd, &msg->hdr, sizeof(msg->hdr), nonblocking)) { /* Cancellation point */
 		saved_errno = errno;
 		goto error_freemsg;
@@ -1069,7 +1077,7 @@ static int read_message(struct xs_handle
 	body = msg->body = malloc(msg->hdr.len + 1);
 	if (body == NULL)
 		goto error_freemsg;
-	cleanup_push(free, body);
+	cleanup_push_heap(body);
 	if (!read_all(h->fd, body, msg->hdr.len, 0)) { /* Cancellation point */
 		saved_errno = errno;
 		goto error_freebody;
@@ -1098,6 +1106,7 @@ static int read_message(struct xs_handle
 		/* There should only ever be one response pending! */
 		if (!list_empty(&h->reply_list)) {
 			mutex_unlock(&h->reply_mutex);
+			saved_errno = EEXIST; 
 			goto error_freebody;
 		}
 
@@ -1110,9 +1119,9 @@ static int read_message(struct xs_handle
 	ret = 0;
 
 error_freebody:
-	cleanup_pop(ret == -1);
+	cleanup_pop_heap(ret == -1, body);
 error_freemsg:
-	cleanup_pop(ret == -1);
+	cleanup_pop_heap(ret == -1, msg);
 error:
 	errno = saved_errno;
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 14 14:52:48 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 14:52:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TCXG3-0001RV-3W; Fri, 14 Sep 2012 14:52:39 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1TCXG2-0001RM-1Z
	for xen-devel@lists.xen.org; Fri, 14 Sep 2012 14:52:38 +0000
Received: from [85.158.143.35:12525] by server-1.bemta-4.messagelabs.com id
	84/CA-12504-5B443505; Fri, 14 Sep 2012 14:52:37 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-13.tower-21.messagelabs.com!1347634356!16912485!1
X-Originating-IP: [208.97.132.119]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4xMTkgPT4gMzQ1ODg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10298 invoked from network); 14 Sep 2012 14:52:36 -0000
Received: from caiajhbdcbbj.dreamhost.com (HELO homiemail-a19.g.dreamhost.com)
	(208.97.132.119) by server-13.tower-21.messagelabs.com with SMTP;
	14 Sep 2012 14:52:36 -0000
Received: from homiemail-a19.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a19.g.dreamhost.com (Postfix) with ESMTP id B175260407C;
	Fri, 14 Sep 2012 07:52:35 -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=YhOKDnlx9L+b/v+kEVTJdu
	DCmdnv9L56Kr/QWWtscG72tuD+JsM2jDCXJbSzPqJnGTFphypi+YcgJ/AasJgGAa
	gXCzQBQJ+OVPXPHTXIMq2GtkBghQb06BnmayMSrTHFgg7bp6TnBxBxDXEyuKED0t
	GhBshTvylBQxKiJFw0Zrw=
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=Gcd12dH2A1td
	JCnw2KHixMeK2oI=; b=orPTXgxVpUr6k0ktaYY6oh8eDaGK0YD0tFZQqlfF+w83
	8S/JE3M+mbvNE0K6xbzZaP1fM3QuBBknpnGnJoqOwcszXlBjX6MPRaywh5l7FMD/
	KQM4KHtrbhsPs+Zl9nUZ6qWVuUnYVr3/LnuUTxd2Nmg5kDtw1qqlR/YmAlhpvl0=
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-a19.g.dreamhost.com (Postfix) with ESMTPSA id 363C0604079; 
	Fri, 14 Sep 2012 07:52:35 -0700 (PDT)
MIME-Version: 1.0
X-Mercurial-Node: a83fd69dcb277ce12bf6203e0f69071a47d9b24f
Message-Id: <a83fd69dcb277ce12bf6.1347634735@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Fri, 14 Sep 2012 10:58:55 -0400
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xen.org
Cc: ian.jackson@citrix.com, andres@gridcentric.ca, ian.campbell@citrix.com
Subject: [Xen-devel] [PATCH] Fix libxenstore memory leak when USE_PTHREAD is
 not defined, 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

 tools/xenstore/xs.c |  17 +++++++++++++----
 1 files changed, 13 insertions(+), 4 deletions(-)


Redefine usage of pthread_cleanup_push and _pop, to explicitly call free for
heap objects in error paths.

By the way, set a suitable errno value for an error path that had none.

This is V2 after comments from Ian Campbell.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r 588d0dc298a4 -r a83fd69dcb27 tools/xenstore/xs.c
--- a/tools/xenstore/xs.c
+++ b/tools/xenstore/xs.c
@@ -110,6 +110,11 @@ struct xs_handle {
 
 #define read_thread_exists(h)	(h->read_thr_exists)
 
+/* Because pthread_cleanup_p* are not available when USE_PTHREAD is
+ * disabled, use these macros which convert appropriately. */
+#define cleanup_push_heap(p)        cleanup_push(free, p)
+#define cleanup_pop_heap(run, p)    cleanup_pop((run))
+
 static void *read_thread(void *arg);
 
 #else /* !defined(USE_PTHREAD) */
@@ -130,6 +135,9 @@ struct xs_handle {
 #define cleanup_pop(run)	((void)0)
 #define read_thread_exists(h)	(0)
 
+#define cleanup_push_heap(p)        ((void)0)
+#define cleanup_pop_heap(run, p)    do { if ((run)) free(p); } while(0)
+
 #endif
 
 static int read_message(struct xs_handle *h, int nonblocking);
@@ -1059,7 +1067,7 @@ static int read_message(struct xs_handle
 	msg = malloc(sizeof(*msg));
 	if (msg == NULL)
 		goto error;
-	cleanup_push(free, msg);
+	cleanup_push_heap(msg);
 	if (!read_all(h->fd, &msg->hdr, sizeof(msg->hdr), nonblocking)) { /* Cancellation point */
 		saved_errno = errno;
 		goto error_freemsg;
@@ -1069,7 +1077,7 @@ static int read_message(struct xs_handle
 	body = msg->body = malloc(msg->hdr.len + 1);
 	if (body == NULL)
 		goto error_freemsg;
-	cleanup_push(free, body);
+	cleanup_push_heap(body);
 	if (!read_all(h->fd, body, msg->hdr.len, 0)) { /* Cancellation point */
 		saved_errno = errno;
 		goto error_freebody;
@@ -1098,6 +1106,7 @@ static int read_message(struct xs_handle
 		/* There should only ever be one response pending! */
 		if (!list_empty(&h->reply_list)) {
 			mutex_unlock(&h->reply_mutex);
+			saved_errno = EEXIST; 
 			goto error_freebody;
 		}
 
@@ -1110,9 +1119,9 @@ static int read_message(struct xs_handle
 	ret = 0;
 
 error_freebody:
-	cleanup_pop(ret == -1);
+	cleanup_pop_heap(ret == -1, body);
 error_freemsg:
-	cleanup_pop(ret == -1);
+	cleanup_pop_heap(ret == -1, msg);
 error:
 	errno = saved_errno;
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 14 14:53:43 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 14: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 1TCXGv-0001WW-Jn; Fri, 14 Sep 2012 14:53:33 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Conny.Seidel@amd.com>) id 1TCXFS-0001Po-CK
	for xen-devel@lists.xen.org; Fri, 14 Sep 2012 14:52:02 +0000
Received: from [85.158.137.99:61491] by server-8.bemta-3.messagelabs.com id
	F3/D2-24700-19443505; Fri, 14 Sep 2012 14:52:01 +0000
X-Env-Sender: Conny.Seidel@amd.com
X-Msg-Ref: server-9.tower-217.messagelabs.com!1347634319!14534384!1
X-Originating-IP: [65.55.88.11]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2472 invoked from network); 14 Sep 2012 14:52:00 -0000
Received: from tx2ehsobe001.messaging.microsoft.com (HELO
	tx2outboundpool.messaging.microsoft.com) (65.55.88.11)
	by server-9.tower-217.messagelabs.com with AES128-SHA encrypted SMTP;
	14 Sep 2012 14:52:00 -0000
Received: from mail244-tx2-R.bigfish.com (10.9.14.243) by
	TX2EHSOBE014.bigfish.com (10.9.40.34) with Microsoft SMTP Server id
	14.1.225.23; Fri, 14 Sep 2012 14:51:58 +0000
Received: from mail244-tx2 (localhost [127.0.0.1])	by
	mail244-tx2-R.bigfish.com (Postfix) with ESMTP id BF2264200C4;
	Fri, 14 Sep 2012 14:51:58 +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(zz98dI1be0I1432Izz1202h1d1ah1d2ahzz8275bh8275dh15d4Iz2dh668h839hd24he5bhf0ah107ah1288h12a5h12bdh34h1155h)
Received: from mail244-tx2 (localhost.localdomain [127.0.0.1]) by mail244-tx2
	(MessageSwitch) id 1347634317220113_29583;
	Fri, 14 Sep 2012 14:51:57 +0000 (UTC)
Received: from TX2EHSMHS033.bigfish.com (unknown [10.9.14.251])	by
	mail244-tx2.bigfish.com (Postfix) with ESMTP id 298BB20A0096;
	Fri, 14 Sep 2012 14:51:57 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	TX2EHSMHS033.bigfish.com (10.9.99.133) with Microsoft SMTP Server id
	14.1.225.23; Fri, 14 Sep 2012 14:51:55 +0000
X-WSS-ID: 0MACHAH-01-2KA-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 27DDB10280A5;	Fri, 14 Sep 2012 09:51:52 -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;
	Fri, 14 Sep 2012 10:05:46 -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, 14 Sep 2012 09:51:52 -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, 14 Sep 2012
	10:51:51 -0400
Received: from marah.osrc.amd.com (marah.osrc.amd.com [165.204.15.125])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id A5DD649C5E4; Fri, 14 Sep 2012
	15:51:50 +0100 (BST)
Date: Fri, 14 Sep 2012 16:53:33 +0200
From: Conny Seidel <conny.seidel@amd.com>
To: Konrad Rzeszutek Wilk <konrad@kernel.org>
Message-ID: <20120914165333.69aa6626.conny.seidel@amd.com>
In-Reply-To: <20120913133211.GB17060@localhost.localdomain>
References: <1136369816.20120904183757@eikelenboom.it>
	<20120904163347.GH23361@phenom.dumpdata.com>
	<143844933.20120904191941@eikelenboom.it>
	<CAOvdn6U_yHgtZwv9MWazdLbd3NLq3pwGXnZY5sL2UVBhV_FUoQ@mail.gmail.com>
	<1813712325.20120904213459@eikelenboom.it>
	<048EAD622912254A9DEA24C1734613C18C864C3C5D@FTLPMAILBOX02.citrite.net>
	<20120905140600.GA5844@phenom.dumpdata.com>
	<alpine.DEB.2.02.1209111652590.15568@kaball.uk.xensource.com>
	<1901811929.20120912122848@eikelenboom.it>
	<20120913133211.GB17060@localhost.localdomain>
Organization: Advanced Micro Devices GmbH; Einsteinring 24; 85609 Dornach
	bei Muenchen; Geschaeftsfuehrer: Alberto Bozzo; Sitz: Dornach, Gemeinde
	Aschheim, Landkreis Muenchen; Registergericht Muenchen, HRB Nr. 43632
X-Mailer: Claws Mail 3.8.1cvs53 (GTK+ 2.24.10; x86_64-pc-linux-gnu)
MIME-Version: 1.0
X-OriginatorOrg: amd.com
X-Mailman-Approved-At: Fri, 14 Sep 2012 14:53:32 +0000
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Sander Eikelenboom <linux@eikelenboom.it>, Ben Guthro <ben@guthro.net>,
	Robert Phillips <robert.phillips@citrix.com>
Subject: Re: [Xen-devel] dom0 linux 3.6.0-rc4,
 crash due to ballooning althoug dom0_mem=X, max:X 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="===============4694687182094061816=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============4694687182094061816==
Content-Type: multipart/signed; micalg=PGP-SHA1;
	boundary="Sig_/8bfkmlBtJm9uZ_+Esquy/sF";
	protocol="application/pgp-signature"

--Sig_/8bfkmlBtJm9uZ_+Esquy/sF
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

Hi,


On Thu, 13 Sep 2012 09:32:14 -0400
Konrad Rzeszutek Wilk <konrad@kernel.org> wrote:

>> > Sander, could you please let me know if it fixes the problem for
>> > you?
>>
>> It does !
>>
>> Tested-By: Sander Eikelenboom <linux@eikelenboom.it>
>
>Excellent. Applied. Thx for reporting and testing.

Is it possible that this patch is backported to stable?

--
Kind regards.

Conny Seidel

##################################################################
# Email : conny.seidel@amd.com            GnuPG-Key : 0xA6AB055D #
# Fingerprint: 17C4 5DB2 7C4C C1C7 1452 8148 F139 7C09 A6AB 055D #
##################################################################
# Advanced Micro Devices GmbH Einsteinring 24 85609 Dornach      #
# General Managers: Alberto Bozzo                                #
# Registration: Dornach, Landkr. Muenchen; Registerger. Muenchen #
#               HRB Nr. 43632                                    #
##################################################################

--Sig_/8bfkmlBtJm9uZ_+Esquy/sF
Content-Type: application/pgp-signature; name="signature.asc"
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlBTRO4ACgkQ8Tl8CaarBV2jIQCg334ryPcXKQ2plghoBhl58VBw
KC4AnRe4m/MTQJYh+menWXGsVqrvw8Eg
=S1q3
-----END PGP SIGNATURE-----

--Sig_/8bfkmlBtJm9uZ_+Esquy/sF--


--===============4694687182094061816==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============4694687182094061816==--


From xen-devel-bounces@lists.xen.org Fri Sep 14 14:53:43 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 14: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 1TCXGv-0001WW-Jn; Fri, 14 Sep 2012 14:53:33 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Conny.Seidel@amd.com>) id 1TCXFS-0001Po-CK
	for xen-devel@lists.xen.org; Fri, 14 Sep 2012 14:52:02 +0000
Received: from [85.158.137.99:61491] by server-8.bemta-3.messagelabs.com id
	F3/D2-24700-19443505; Fri, 14 Sep 2012 14:52:01 +0000
X-Env-Sender: Conny.Seidel@amd.com
X-Msg-Ref: server-9.tower-217.messagelabs.com!1347634319!14534384!1
X-Originating-IP: [65.55.88.11]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2472 invoked from network); 14 Sep 2012 14:52:00 -0000
Received: from tx2ehsobe001.messaging.microsoft.com (HELO
	tx2outboundpool.messaging.microsoft.com) (65.55.88.11)
	by server-9.tower-217.messagelabs.com with AES128-SHA encrypted SMTP;
	14 Sep 2012 14:52:00 -0000
Received: from mail244-tx2-R.bigfish.com (10.9.14.243) by
	TX2EHSOBE014.bigfish.com (10.9.40.34) with Microsoft SMTP Server id
	14.1.225.23; Fri, 14 Sep 2012 14:51:58 +0000
Received: from mail244-tx2 (localhost [127.0.0.1])	by
	mail244-tx2-R.bigfish.com (Postfix) with ESMTP id BF2264200C4;
	Fri, 14 Sep 2012 14:51:58 +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(zz98dI1be0I1432Izz1202h1d1ah1d2ahzz8275bh8275dh15d4Iz2dh668h839hd24he5bhf0ah107ah1288h12a5h12bdh34h1155h)
Received: from mail244-tx2 (localhost.localdomain [127.0.0.1]) by mail244-tx2
	(MessageSwitch) id 1347634317220113_29583;
	Fri, 14 Sep 2012 14:51:57 +0000 (UTC)
Received: from TX2EHSMHS033.bigfish.com (unknown [10.9.14.251])	by
	mail244-tx2.bigfish.com (Postfix) with ESMTP id 298BB20A0096;
	Fri, 14 Sep 2012 14:51:57 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	TX2EHSMHS033.bigfish.com (10.9.99.133) with Microsoft SMTP Server id
	14.1.225.23; Fri, 14 Sep 2012 14:51:55 +0000
X-WSS-ID: 0MACHAH-01-2KA-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 27DDB10280A5;	Fri, 14 Sep 2012 09:51:52 -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;
	Fri, 14 Sep 2012 10:05:46 -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, 14 Sep 2012 09:51:52 -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, 14 Sep 2012
	10:51:51 -0400
Received: from marah.osrc.amd.com (marah.osrc.amd.com [165.204.15.125])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id A5DD649C5E4; Fri, 14 Sep 2012
	15:51:50 +0100 (BST)
Date: Fri, 14 Sep 2012 16:53:33 +0200
From: Conny Seidel <conny.seidel@amd.com>
To: Konrad Rzeszutek Wilk <konrad@kernel.org>
Message-ID: <20120914165333.69aa6626.conny.seidel@amd.com>
In-Reply-To: <20120913133211.GB17060@localhost.localdomain>
References: <1136369816.20120904183757@eikelenboom.it>
	<20120904163347.GH23361@phenom.dumpdata.com>
	<143844933.20120904191941@eikelenboom.it>
	<CAOvdn6U_yHgtZwv9MWazdLbd3NLq3pwGXnZY5sL2UVBhV_FUoQ@mail.gmail.com>
	<1813712325.20120904213459@eikelenboom.it>
	<048EAD622912254A9DEA24C1734613C18C864C3C5D@FTLPMAILBOX02.citrite.net>
	<20120905140600.GA5844@phenom.dumpdata.com>
	<alpine.DEB.2.02.1209111652590.15568@kaball.uk.xensource.com>
	<1901811929.20120912122848@eikelenboom.it>
	<20120913133211.GB17060@localhost.localdomain>
Organization: Advanced Micro Devices GmbH; Einsteinring 24; 85609 Dornach
	bei Muenchen; Geschaeftsfuehrer: Alberto Bozzo; Sitz: Dornach, Gemeinde
	Aschheim, Landkreis Muenchen; Registergericht Muenchen, HRB Nr. 43632
X-Mailer: Claws Mail 3.8.1cvs53 (GTK+ 2.24.10; x86_64-pc-linux-gnu)
MIME-Version: 1.0
X-OriginatorOrg: amd.com
X-Mailman-Approved-At: Fri, 14 Sep 2012 14:53:32 +0000
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Sander Eikelenboom <linux@eikelenboom.it>, Ben Guthro <ben@guthro.net>,
	Robert Phillips <robert.phillips@citrix.com>
Subject: Re: [Xen-devel] dom0 linux 3.6.0-rc4,
 crash due to ballooning althoug dom0_mem=X, max:X 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="===============4694687182094061816=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============4694687182094061816==
Content-Type: multipart/signed; micalg=PGP-SHA1;
	boundary="Sig_/8bfkmlBtJm9uZ_+Esquy/sF";
	protocol="application/pgp-signature"

--Sig_/8bfkmlBtJm9uZ_+Esquy/sF
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

Hi,


On Thu, 13 Sep 2012 09:32:14 -0400
Konrad Rzeszutek Wilk <konrad@kernel.org> wrote:

>> > Sander, could you please let me know if it fixes the problem for
>> > you?
>>
>> It does !
>>
>> Tested-By: Sander Eikelenboom <linux@eikelenboom.it>
>
>Excellent. Applied. Thx for reporting and testing.

Is it possible that this patch is backported to stable?

--
Kind regards.

Conny Seidel

##################################################################
# Email : conny.seidel@amd.com            GnuPG-Key : 0xA6AB055D #
# Fingerprint: 17C4 5DB2 7C4C C1C7 1452 8148 F139 7C09 A6AB 055D #
##################################################################
# Advanced Micro Devices GmbH Einsteinring 24 85609 Dornach      #
# General Managers: Alberto Bozzo                                #
# Registration: Dornach, Landkr. Muenchen; Registerger. Muenchen #
#               HRB Nr. 43632                                    #
##################################################################

--Sig_/8bfkmlBtJm9uZ_+Esquy/sF
Content-Type: application/pgp-signature; name="signature.asc"
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlBTRO4ACgkQ8Tl8CaarBV2jIQCg334ryPcXKQ2plghoBhl58VBw
KC4AnRe4m/MTQJYh+menWXGsVqrvw8Eg
=S1q3
-----END PGP SIGNATURE-----

--Sig_/8bfkmlBtJm9uZ_+Esquy/sF--


--===============4694687182094061816==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============4694687182094061816==--


From xen-devel-bounces@lists.xen.org Fri Sep 14 14:54:52 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 14:54:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TCXI3-0001fR-Oq; Fri, 14 Sep 2012 14:54:43 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1TCXI3-0001fF-0A
	for xen-devel@lists.xen.org; Fri, 14 Sep 2012 14:54:43 +0000
Received: from [85.158.138.51:14262] by server-11.bemta-3.messagelabs.com id
	07/D0-30250-23543505; Fri, 14 Sep 2012 14:54:42 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1347634481!22646515!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDkyOTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32344 invoked from network); 14 Sep 2012 14:54:41 -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;
	14 Sep 2012 14:54:41 -0000
X-IronPort-AV: E=Sophos;i="4.80,423,1344211200"; d="scan'208";a="14549679"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Sep 2012 14:54: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.279.1; Fri, 14 Sep 2012 15:54: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
	1TCXHh-0008N9-42; Fri, 14 Sep 2012 14:54:21 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1TCXHh-0006zb-09;
	Fri, 14 Sep 2012 15:54:21 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20563.17692.884894.521705@mariner.uk.xensource.com>
Date: Fri, 14 Sep 2012 15:54:20 +0100
To: Ian Campbell <ian.campbell@citrix.com>
In-Reply-To: <8fad3481f8c90bb66fff.1347626551@cosworth.uk.xensource.com>
References: <patchbomb.1347626548@cosworth.uk.xensource.com>
	<8fad3481f8c90bb66fff.1347626551@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 3 of 3] xl: Remove global domid and enable
	-Wshadow
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="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 3 of 3] xl: Remove global domid and enable -Wshadow"):
> xl: Remove global domid and enable -Wshadow

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

> I find it hard to believe I won't have broken anything here... I tested
> basic lifecycle ops only.

You may also have fixed something.  I say commit it.

Also, sorry for being the ultimate cause of this mess.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 14 14:54:52 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 14:54:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TCXI3-0001fR-Oq; Fri, 14 Sep 2012 14:54:43 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1TCXI3-0001fF-0A
	for xen-devel@lists.xen.org; Fri, 14 Sep 2012 14:54:43 +0000
Received: from [85.158.138.51:14262] by server-11.bemta-3.messagelabs.com id
	07/D0-30250-23543505; Fri, 14 Sep 2012 14:54:42 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1347634481!22646515!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDkyOTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32344 invoked from network); 14 Sep 2012 14:54:41 -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;
	14 Sep 2012 14:54:41 -0000
X-IronPort-AV: E=Sophos;i="4.80,423,1344211200"; d="scan'208";a="14549679"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Sep 2012 14:54: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.279.1; Fri, 14 Sep 2012 15:54: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
	1TCXHh-0008N9-42; Fri, 14 Sep 2012 14:54:21 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1TCXHh-0006zb-09;
	Fri, 14 Sep 2012 15:54:21 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20563.17692.884894.521705@mariner.uk.xensource.com>
Date: Fri, 14 Sep 2012 15:54:20 +0100
To: Ian Campbell <ian.campbell@citrix.com>
In-Reply-To: <8fad3481f8c90bb66fff.1347626551@cosworth.uk.xensource.com>
References: <patchbomb.1347626548@cosworth.uk.xensource.com>
	<8fad3481f8c90bb66fff.1347626551@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 3 of 3] xl: Remove global domid and enable
	-Wshadow
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="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 3 of 3] xl: Remove global domid and enable -Wshadow"):
> xl: Remove global domid and enable -Wshadow

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

> I find it hard to believe I won't have broken anything here... I tested
> basic lifecycle ops only.

You may also have fixed something.  I say commit it.

Also, sorry for being the ultimate cause of this mess.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 14 14:54:58 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 14: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 1TCXI8-0001gU-60; Fri, 14 Sep 2012 14:54:48 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1TCXI6-0001fv-Jp
	for xen-devel@lists.xen.org; Fri, 14 Sep 2012 14:54:46 +0000
Received: from [85.158.138.51:12458] by server-5.bemta-3.messagelabs.com id
	09/02-13133-53543505; Fri, 14 Sep 2012 14:54:45 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1347634481!22646515!2
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDkyOTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32654 invoked from network); 14 Sep 2012 14:54:45 -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;
	14 Sep 2012 14:54:45 -0000
X-IronPort-AV: E=Sophos;i="4.80,423,1344211200"; d="scan'208";a="14549710"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Sep 2012 14:54: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.279.1; Fri, 14 Sep 2012 15:54: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
	1TCXI4-0008Sj-QD; Fri, 14 Sep 2012 14:54:44 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1TCXI4-0006zg-Kw;
	Fri, 14 Sep 2012 15:54:44 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20563.17716.542058.529527@mariner.uk.xensource.com>
Date: Fri, 14 Sep 2012 15:54:44 +0100
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1347626830.24226.183.camel@zakaz.uk.xensource.com>
References: <patchbomb.1347626548@cosworth.uk.xensource.com>
	<8fad3481f8c90bb66fff.1347626551@cosworth.uk.xensource.com>
	<1347626830.24226.183.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 3 of 3] xl: Remove global domid and enable
 -Wshadow
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="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 3 of 3] xl: Remove global domid and enable -Wshadow"):
> Annotate it with want_unused_result and fix the handful of errors.

Oops,

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 Sep 14 14:54:58 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 14: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 1TCXI8-0001gU-60; Fri, 14 Sep 2012 14:54:48 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1TCXI6-0001fv-Jp
	for xen-devel@lists.xen.org; Fri, 14 Sep 2012 14:54:46 +0000
Received: from [85.158.138.51:12458] by server-5.bemta-3.messagelabs.com id
	09/02-13133-53543505; Fri, 14 Sep 2012 14:54:45 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1347634481!22646515!2
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDkyOTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32654 invoked from network); 14 Sep 2012 14:54:45 -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;
	14 Sep 2012 14:54:45 -0000
X-IronPort-AV: E=Sophos;i="4.80,423,1344211200"; d="scan'208";a="14549710"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Sep 2012 14:54: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.279.1; Fri, 14 Sep 2012 15:54: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
	1TCXI4-0008Sj-QD; Fri, 14 Sep 2012 14:54:44 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1TCXI4-0006zg-Kw;
	Fri, 14 Sep 2012 15:54:44 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20563.17716.542058.529527@mariner.uk.xensource.com>
Date: Fri, 14 Sep 2012 15:54:44 +0100
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1347626830.24226.183.camel@zakaz.uk.xensource.com>
References: <patchbomb.1347626548@cosworth.uk.xensource.com>
	<8fad3481f8c90bb66fff.1347626551@cosworth.uk.xensource.com>
	<1347626830.24226.183.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 3 of 3] xl: Remove global domid and enable
 -Wshadow
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="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 3 of 3] xl: Remove global domid and enable -Wshadow"):
> Annotate it with want_unused_result and fix the handful of errors.

Oops,

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 Sep 14 14:57:17 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 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 1TCXKQ-00026j-Op; Fri, 14 Sep 2012 14:57:10 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1TCXKO-00026E-ON
	for xen-devel@lists.xensource.com; Fri, 14 Sep 2012 14:57:08 +0000
Received: from [85.158.139.83:52062] by server-8.bemta-5.messagelabs.com id
	F7/DC-15219-4C543505; Fri, 14 Sep 2012 14:57:08 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1347634627!23320308!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDkyOTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 488 invoked from network); 14 Sep 2012 14:57:07 -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;
	14 Sep 2012 14:57:07 -0000
X-IronPort-AV: E=Sophos;i="4.80,423,1344211200"; d="scan'208";a="14549792"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Sep 2012 14:57:07 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Fri, 14 Sep 2012 15:57:07 +0100
Date: Fri, 14 Sep 2012 15:56:24 +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: <20120914131033.GM25249@phenom.dumpdata.com>
Message-ID: <alpine.DEB.2.02.1209141550080.29232@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1209141145150.29232@kaball.uk.xensource.com>
	<1347621207-11294-14-git-send-email-stefano.stabellini@eu.citrix.com>
	<20120914131033.GM25249@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>,
	"linaro-dev@lists.linaro.org" <linaro-dev@lists.linaro.org>,
	Ian Campbell <Ian.Campbell@citrix.com>, "arnd@arndb.de" <arnd@arndb.de>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"catalin.marinas@arm.com" <catalin.marinas@arm.com>,
	"Tim \(Xen.org\)" <tim@xen.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux@arm.linux.org.uk" <linux@arm.linux.org.uk>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Xen-devel] [PATCH v4 14/24] xen/arm: initialize grant_table on
	ARM
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 14 Sep 2012, Konrad Rzeszutek Wilk wrote:
> On Fri, Sep 14, 2012 at 12:13:16PM +0100, Stefano Stabellini wrote:
> > Initialize the grant table mapping at the address specified at index 0
> > in the DT under the /xen node.
> > After the grant table is initialized, call xenbus_probe (if not dom0).
> 
> So we don't really care about the grant's size then? The DT xen.txt
> talks about it..

I am assuming that the size of the memory region specified in the device
tree is sufficiently large to map the entire grant table, given that both
the device tree hypervisor entry and the grant table size comes from Xen.

The grant table size is currently queried to Xen directly via an
hypercall (GNTTABOP_query_size). Basically the size in the device tree
is redundant information.


> > Changes in v2:
> > 
> > - introduce GRANT_TABLE_PHYSADDR;
> > - remove unneeded initialization of boot_max_nr_grant_frames.
> > 
> > Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> > ---
> >  arch/arm/xen/enlighten.c |   14 ++++++++++++++
> >  1 files changed, 14 insertions(+), 0 deletions(-)
> > 
> > diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
> > index c2a47a7..036a4d8 100644
> > --- a/arch/arm/xen/enlighten.c
> > +++ b/arch/arm/xen/enlighten.c
> > @@ -1,8 +1,12 @@
> >  #include <xen/xen.h>
> > +#include <xen/grant_table.h>
> > +#include <xen/hvm.h>
> >  #include <xen/interface/xen.h>
> >  #include <xen/interface/memory.h>
> > +#include <xen/interface/hvm/params.h>
> >  #include <xen/features.h>
> >  #include <xen/platform_pci.h>
> > +#include <xen/xenbus.h>
> >  #include <asm/xen/hypervisor.h>
> >  #include <asm/xen/hypercall.h>
> >  #include <linux/module.h>
> > @@ -42,6 +46,7 @@ EXPORT_SYMBOL_GPL(xen_remap_domain_mfn_range);
> >   * see Documentation/devicetree/bindings/arm/xen.txt for the
> >   * documentation of the Xen Device Tree format.
> >   */
> > +#define GRANT_TABLE_PHYSADDR 0
> >  static int __init xen_guest_init(void)
> >  {
> >  	struct xen_add_to_physmap xatp;
> > @@ -51,6 +56,7 @@ static int __init xen_guest_init(void)
> >  	const char *s = NULL;
> >  	const char *version = NULL;
> >  	const char *xen_prefix = "xen,xen-";
> > +	struct resource res;
> >  
> >  	node = of_find_compatible_node(NULL, NULL, "xen,xen");
> >  	if (!node) {
> > @@ -65,6 +71,9 @@ static int __init xen_guest_init(void)
> >  		pr_debug("Xen version not found\n");
> >  		return 0;
> >  	}
> > +	if (of_address_to_resource(node, GRANT_TABLE_PHYSADDR, &res))
> > +		return 0;
> > +	xen_hvm_resume_frames = res.start >> PAGE_SHIFT;
> >  	xen_domain_type = XEN_HVM_DOMAIN;
> >  
> >  	xen_setup_features();
> > @@ -98,6 +107,11 @@ static int __init xen_guest_init(void)
> >  	 * is required to use VCPUOP_register_vcpu_info to place vcpu info
> >  	 * for secondary CPUs as they are brought up. */
> >  	per_cpu(xen_vcpu, 0) = &HYPERVISOR_shared_info->vcpu_info[0];
> > +
> > +	gnttab_init();
> > +	if (!xen_initial_domain())
> > +		xenbus_probe(NULL);
> > +
> >  	return 0;
> >  }
> >  core_initcall(xen_guest_init);
> > -- 
> > 1.7.2.5
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 14 14:57:17 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 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 1TCXKQ-00026j-Op; Fri, 14 Sep 2012 14:57:10 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1TCXKO-00026E-ON
	for xen-devel@lists.xensource.com; Fri, 14 Sep 2012 14:57:08 +0000
Received: from [85.158.139.83:52062] by server-8.bemta-5.messagelabs.com id
	F7/DC-15219-4C543505; Fri, 14 Sep 2012 14:57:08 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1347634627!23320308!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDkyOTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 488 invoked from network); 14 Sep 2012 14:57:07 -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;
	14 Sep 2012 14:57:07 -0000
X-IronPort-AV: E=Sophos;i="4.80,423,1344211200"; d="scan'208";a="14549792"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Sep 2012 14:57:07 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Fri, 14 Sep 2012 15:57:07 +0100
Date: Fri, 14 Sep 2012 15:56:24 +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: <20120914131033.GM25249@phenom.dumpdata.com>
Message-ID: <alpine.DEB.2.02.1209141550080.29232@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1209141145150.29232@kaball.uk.xensource.com>
	<1347621207-11294-14-git-send-email-stefano.stabellini@eu.citrix.com>
	<20120914131033.GM25249@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>,
	"linaro-dev@lists.linaro.org" <linaro-dev@lists.linaro.org>,
	Ian Campbell <Ian.Campbell@citrix.com>, "arnd@arndb.de" <arnd@arndb.de>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"catalin.marinas@arm.com" <catalin.marinas@arm.com>,
	"Tim \(Xen.org\)" <tim@xen.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux@arm.linux.org.uk" <linux@arm.linux.org.uk>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Xen-devel] [PATCH v4 14/24] xen/arm: initialize grant_table on
	ARM
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 14 Sep 2012, Konrad Rzeszutek Wilk wrote:
> On Fri, Sep 14, 2012 at 12:13:16PM +0100, Stefano Stabellini wrote:
> > Initialize the grant table mapping at the address specified at index 0
> > in the DT under the /xen node.
> > After the grant table is initialized, call xenbus_probe (if not dom0).
> 
> So we don't really care about the grant's size then? The DT xen.txt
> talks about it..

I am assuming that the size of the memory region specified in the device
tree is sufficiently large to map the entire grant table, given that both
the device tree hypervisor entry and the grant table size comes from Xen.

The grant table size is currently queried to Xen directly via an
hypercall (GNTTABOP_query_size). Basically the size in the device tree
is redundant information.


> > Changes in v2:
> > 
> > - introduce GRANT_TABLE_PHYSADDR;
> > - remove unneeded initialization of boot_max_nr_grant_frames.
> > 
> > Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> > ---
> >  arch/arm/xen/enlighten.c |   14 ++++++++++++++
> >  1 files changed, 14 insertions(+), 0 deletions(-)
> > 
> > diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
> > index c2a47a7..036a4d8 100644
> > --- a/arch/arm/xen/enlighten.c
> > +++ b/arch/arm/xen/enlighten.c
> > @@ -1,8 +1,12 @@
> >  #include <xen/xen.h>
> > +#include <xen/grant_table.h>
> > +#include <xen/hvm.h>
> >  #include <xen/interface/xen.h>
> >  #include <xen/interface/memory.h>
> > +#include <xen/interface/hvm/params.h>
> >  #include <xen/features.h>
> >  #include <xen/platform_pci.h>
> > +#include <xen/xenbus.h>
> >  #include <asm/xen/hypervisor.h>
> >  #include <asm/xen/hypercall.h>
> >  #include <linux/module.h>
> > @@ -42,6 +46,7 @@ EXPORT_SYMBOL_GPL(xen_remap_domain_mfn_range);
> >   * see Documentation/devicetree/bindings/arm/xen.txt for the
> >   * documentation of the Xen Device Tree format.
> >   */
> > +#define GRANT_TABLE_PHYSADDR 0
> >  static int __init xen_guest_init(void)
> >  {
> >  	struct xen_add_to_physmap xatp;
> > @@ -51,6 +56,7 @@ static int __init xen_guest_init(void)
> >  	const char *s = NULL;
> >  	const char *version = NULL;
> >  	const char *xen_prefix = "xen,xen-";
> > +	struct resource res;
> >  
> >  	node = of_find_compatible_node(NULL, NULL, "xen,xen");
> >  	if (!node) {
> > @@ -65,6 +71,9 @@ static int __init xen_guest_init(void)
> >  		pr_debug("Xen version not found\n");
> >  		return 0;
> >  	}
> > +	if (of_address_to_resource(node, GRANT_TABLE_PHYSADDR, &res))
> > +		return 0;
> > +	xen_hvm_resume_frames = res.start >> PAGE_SHIFT;
> >  	xen_domain_type = XEN_HVM_DOMAIN;
> >  
> >  	xen_setup_features();
> > @@ -98,6 +107,11 @@ static int __init xen_guest_init(void)
> >  	 * is required to use VCPUOP_register_vcpu_info to place vcpu info
> >  	 * for secondary CPUs as they are brought up. */
> >  	per_cpu(xen_vcpu, 0) = &HYPERVISOR_shared_info->vcpu_info[0];
> > +
> > +	gnttab_init();
> > +	if (!xen_initial_domain())
> > +		xenbus_probe(NULL);
> > +
> >  	return 0;
> >  }
> >  core_initcall(xen_guest_init);
> > -- 
> > 1.7.2.5
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 14 15:09:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 15: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 1TCXVk-0002ml-3p; Fri, 14 Sep 2012 15:08: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 1TCXVi-0002mb-Dt
	for xen-devel@lists.xensource.com; Fri, 14 Sep 2012 15:08:50 +0000
Received: from [85.158.139.83:17443] by server-11.bemta-5.messagelabs.com id
	86/27-24658-F7843505; Fri, 14 Sep 2012 15:08:47 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1347635326!27694797!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDkyOTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18048 invoked from network); 14 Sep 2012 15:08:46 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Sep 2012 15:08:46 -0000
X-IronPort-AV: E=Sophos;i="4.80,423,1344211200"; d="scan'208";a="14550091"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Sep 2012 15:08: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.279.1;
	Fri, 14 Sep 2012 16:08:46 +0100
Message-ID: <1347635324.24226.229.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Date: Fri, 14 Sep 2012 16:08:44 +0100
In-Reply-To: <alpine.DEB.2.02.1209141550080.29232@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1209141145150.29232@kaball.uk.xensource.com>
	<1347621207-11294-14-git-send-email-stefano.stabellini@eu.citrix.com>
	<20120914131033.GM25249@phenom.dumpdata.com>
	<alpine.DEB.2.02.1209141550080.29232@kaball.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linaro-dev@lists.linaro.org" <linaro-dev@lists.linaro.org>,
	"arnd@arndb.de" <arnd@arndb.de>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"catalin.marinas@arm.com" <catalin.marinas@arm.com>,
	"Tim \(Xen.org\)" <tim@xen.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux@arm.linux.org.uk" <linux@arm.linux.org.uk>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Xen-devel] [PATCH v4 14/24] xen/arm: initialize grant_table on
	ARM
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-09-14 at 15:56 +0100, Stefano Stabellini wrote:
> On Fri, 14 Sep 2012, Konrad Rzeszutek Wilk wrote:
> > On Fri, Sep 14, 2012 at 12:13:16PM +0100, Stefano Stabellini wrote:
> > > Initialize the grant table mapping at the address specified at index 0
> > > in the DT under the /xen node.
> > > After the grant table is initialized, call xenbus_probe (if not dom0).
> > 
> > So we don't really care about the grant's size then? The DT xen.txt
> > talks about it..
> 
> I am assuming that the size of the memory region specified in the device
> tree is sufficiently large to map the entire grant table, given that both
> the device tree hypervisor entry and the grant table size comes from Xen.

Actually, the grant table can grow dynamically under the control of the
guest, I think you just pass GNTTABOP_setup_table with some more frames.
See drivers/xen/grant_table.c:gnttab_expand().

> The grant table size is currently queried to Xen directly via an
> hypercall (GNTTABOP_query_size). Basically the size in the device tree
> is redundant information.

This size is the size of the physical address space where the guest
could chose map grant table frames. It could be either larger or smaller
than the actual grant table. (smaller because the guest could use
physical addresses not within this region, if it wanted to for some
reason).

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 14 15:09:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 15: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 1TCXVk-0002ml-3p; Fri, 14 Sep 2012 15:08: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 1TCXVi-0002mb-Dt
	for xen-devel@lists.xensource.com; Fri, 14 Sep 2012 15:08:50 +0000
Received: from [85.158.139.83:17443] by server-11.bemta-5.messagelabs.com id
	86/27-24658-F7843505; Fri, 14 Sep 2012 15:08:47 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1347635326!27694797!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDkyOTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18048 invoked from network); 14 Sep 2012 15:08:46 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Sep 2012 15:08:46 -0000
X-IronPort-AV: E=Sophos;i="4.80,423,1344211200"; d="scan'208";a="14550091"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Sep 2012 15:08: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.279.1;
	Fri, 14 Sep 2012 16:08:46 +0100
Message-ID: <1347635324.24226.229.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Date: Fri, 14 Sep 2012 16:08:44 +0100
In-Reply-To: <alpine.DEB.2.02.1209141550080.29232@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1209141145150.29232@kaball.uk.xensource.com>
	<1347621207-11294-14-git-send-email-stefano.stabellini@eu.citrix.com>
	<20120914131033.GM25249@phenom.dumpdata.com>
	<alpine.DEB.2.02.1209141550080.29232@kaball.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linaro-dev@lists.linaro.org" <linaro-dev@lists.linaro.org>,
	"arnd@arndb.de" <arnd@arndb.de>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"catalin.marinas@arm.com" <catalin.marinas@arm.com>,
	"Tim \(Xen.org\)" <tim@xen.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux@arm.linux.org.uk" <linux@arm.linux.org.uk>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Xen-devel] [PATCH v4 14/24] xen/arm: initialize grant_table on
	ARM
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-09-14 at 15:56 +0100, Stefano Stabellini wrote:
> On Fri, 14 Sep 2012, Konrad Rzeszutek Wilk wrote:
> > On Fri, Sep 14, 2012 at 12:13:16PM +0100, Stefano Stabellini wrote:
> > > Initialize the grant table mapping at the address specified at index 0
> > > in the DT under the /xen node.
> > > After the grant table is initialized, call xenbus_probe (if not dom0).
> > 
> > So we don't really care about the grant's size then? The DT xen.txt
> > talks about it..
> 
> I am assuming that the size of the memory region specified in the device
> tree is sufficiently large to map the entire grant table, given that both
> the device tree hypervisor entry and the grant table size comes from Xen.

Actually, the grant table can grow dynamically under the control of the
guest, I think you just pass GNTTABOP_setup_table with some more frames.
See drivers/xen/grant_table.c:gnttab_expand().

> The grant table size is currently queried to Xen directly via an
> hypercall (GNTTABOP_query_size). Basically the size in the device tree
> is redundant information.

This size is the size of the physical address space where the guest
could chose map grant table frames. It could be either larger or smaller
than the actual grant table. (smaller because the guest could use
physical addresses not within this region, if it wanted to for some
reason).

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 14 15:10:23 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 15: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 1TCXWx-0002v2-JD; Fri, 14 Sep 2012 15:10: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 1TCXWw-0002uu-1n
	for xen-devel@lists.xen.org; Fri, 14 Sep 2012 15:10:06 +0000
Received: from [85.158.139.83:25533] by server-11.bemta-5.messagelabs.com id
	E6/B9-24658-DC843505; Fri, 14 Sep 2012 15:10:05 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1347635404!16453750!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDkyOTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24095 invoked from network); 14 Sep 2012 15:10:04 -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;
	14 Sep 2012 15:10:04 -0000
X-IronPort-AV: E=Sophos;i="4.80,423,1344211200"; d="scan'208";a="14550117"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Sep 2012 15:10: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.279.1;
	Fri, 14 Sep 2012 16:10:04 +0100
Message-ID: <1347635403.24226.230.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Date: Fri, 14 Sep 2012 16:10:03 +0100
In-Reply-To: <a83fd69dcb277ce12bf6.1347634735@xdev.gridcentric.ca>
References: <a83fd69dcb277ce12bf6.1347634735@xdev.gridcentric.ca>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "andres@gridcentric.ca" <andres@gridcentric.ca>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] Fix libxenstore memory leak when
 USE_PTHREAD is not defined, 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 Fri, 2012-09-14 at 15:58 +0100, Andres Lagar-Cavilla wrote:
> tools/xenstore/xs.c |  17 +++++++++++++----
>  1 files changed, 13 insertions(+), 4 deletions(-)
> 
> 
> Redefine usage of pthread_cleanup_push and _pop, to explicitly call free for
> heap objects in error paths.
> 
> By the way, set a suitable errno value for an error path that had none.
> 
> This is V2 after comments from Ian Campbell.
> 
> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

Looks good to me

Acked-by: Ian Campbell <ian.campbell@citrix.com>

> 
> diff -r 588d0dc298a4 -r a83fd69dcb27 tools/xenstore/xs.c
> --- a/tools/xenstore/xs.c
> +++ b/tools/xenstore/xs.c
> @@ -110,6 +110,11 @@ struct xs_handle {
>  
>  #define read_thread_exists(h)	(h->read_thr_exists)
>  
> +/* Because pthread_cleanup_p* are not available when USE_PTHREAD is
> + * disabled, use these macros which convert appropriately. */
> +#define cleanup_push_heap(p)        cleanup_push(free, p)
> +#define cleanup_pop_heap(run, p)    cleanup_pop((run))
> +
>  static void *read_thread(void *arg);
>  
>  #else /* !defined(USE_PTHREAD) */
> @@ -130,6 +135,9 @@ struct xs_handle {
>  #define cleanup_pop(run)	((void)0)
>  #define read_thread_exists(h)	(0)
>  
> +#define cleanup_push_heap(p)        ((void)0)
> +#define cleanup_pop_heap(run, p)    do { if ((run)) free(p); } while(0)
> +
>  #endif
>  
>  static int read_message(struct xs_handle *h, int nonblocking);
> @@ -1059,7 +1067,7 @@ static int read_message(struct xs_handle
>  	msg = malloc(sizeof(*msg));
>  	if (msg == NULL)
>  		goto error;
> -	cleanup_push(free, msg);
> +	cleanup_push_heap(msg);
>  	if (!read_all(h->fd, &msg->hdr, sizeof(msg->hdr), nonblocking)) { /* Cancellation point */
>  		saved_errno = errno;
>  		goto error_freemsg;
> @@ -1069,7 +1077,7 @@ static int read_message(struct xs_handle
>  	body = msg->body = malloc(msg->hdr.len + 1);
>  	if (body == NULL)
>  		goto error_freemsg;
> -	cleanup_push(free, body);
> +	cleanup_push_heap(body);
>  	if (!read_all(h->fd, body, msg->hdr.len, 0)) { /* Cancellation point */
>  		saved_errno = errno;
>  		goto error_freebody;
> @@ -1098,6 +1106,7 @@ static int read_message(struct xs_handle
>  		/* There should only ever be one response pending! */
>  		if (!list_empty(&h->reply_list)) {
>  			mutex_unlock(&h->reply_mutex);
> +			saved_errno = EEXIST; 
>  			goto error_freebody;
>  		}
>  
> @@ -1110,9 +1119,9 @@ static int read_message(struct xs_handle
>  	ret = 0;
>  
>  error_freebody:
> -	cleanup_pop(ret == -1);
> +	cleanup_pop_heap(ret == -1, body);
>  error_freemsg:
> -	cleanup_pop(ret == -1);
> +	cleanup_pop_heap(ret == -1, msg);
>  error:
>  	errno = saved_errno;
>  



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 14 15:10:23 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 15: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 1TCXWx-0002v2-JD; Fri, 14 Sep 2012 15:10: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 1TCXWw-0002uu-1n
	for xen-devel@lists.xen.org; Fri, 14 Sep 2012 15:10:06 +0000
Received: from [85.158.139.83:25533] by server-11.bemta-5.messagelabs.com id
	E6/B9-24658-DC843505; Fri, 14 Sep 2012 15:10:05 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1347635404!16453750!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDkyOTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24095 invoked from network); 14 Sep 2012 15:10:04 -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;
	14 Sep 2012 15:10:04 -0000
X-IronPort-AV: E=Sophos;i="4.80,423,1344211200"; d="scan'208";a="14550117"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Sep 2012 15:10: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.279.1;
	Fri, 14 Sep 2012 16:10:04 +0100
Message-ID: <1347635403.24226.230.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Date: Fri, 14 Sep 2012 16:10:03 +0100
In-Reply-To: <a83fd69dcb277ce12bf6.1347634735@xdev.gridcentric.ca>
References: <a83fd69dcb277ce12bf6.1347634735@xdev.gridcentric.ca>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "andres@gridcentric.ca" <andres@gridcentric.ca>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] Fix libxenstore memory leak when
 USE_PTHREAD is not defined, 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 Fri, 2012-09-14 at 15:58 +0100, Andres Lagar-Cavilla wrote:
> tools/xenstore/xs.c |  17 +++++++++++++----
>  1 files changed, 13 insertions(+), 4 deletions(-)
> 
> 
> Redefine usage of pthread_cleanup_push and _pop, to explicitly call free for
> heap objects in error paths.
> 
> By the way, set a suitable errno value for an error path that had none.
> 
> This is V2 after comments from Ian Campbell.
> 
> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

Looks good to me

Acked-by: Ian Campbell <ian.campbell@citrix.com>

> 
> diff -r 588d0dc298a4 -r a83fd69dcb27 tools/xenstore/xs.c
> --- a/tools/xenstore/xs.c
> +++ b/tools/xenstore/xs.c
> @@ -110,6 +110,11 @@ struct xs_handle {
>  
>  #define read_thread_exists(h)	(h->read_thr_exists)
>  
> +/* Because pthread_cleanup_p* are not available when USE_PTHREAD is
> + * disabled, use these macros which convert appropriately. */
> +#define cleanup_push_heap(p)        cleanup_push(free, p)
> +#define cleanup_pop_heap(run, p)    cleanup_pop((run))
> +
>  static void *read_thread(void *arg);
>  
>  #else /* !defined(USE_PTHREAD) */
> @@ -130,6 +135,9 @@ struct xs_handle {
>  #define cleanup_pop(run)	((void)0)
>  #define read_thread_exists(h)	(0)
>  
> +#define cleanup_push_heap(p)        ((void)0)
> +#define cleanup_pop_heap(run, p)    do { if ((run)) free(p); } while(0)
> +
>  #endif
>  
>  static int read_message(struct xs_handle *h, int nonblocking);
> @@ -1059,7 +1067,7 @@ static int read_message(struct xs_handle
>  	msg = malloc(sizeof(*msg));
>  	if (msg == NULL)
>  		goto error;
> -	cleanup_push(free, msg);
> +	cleanup_push_heap(msg);
>  	if (!read_all(h->fd, &msg->hdr, sizeof(msg->hdr), nonblocking)) { /* Cancellation point */
>  		saved_errno = errno;
>  		goto error_freemsg;
> @@ -1069,7 +1077,7 @@ static int read_message(struct xs_handle
>  	body = msg->body = malloc(msg->hdr.len + 1);
>  	if (body == NULL)
>  		goto error_freemsg;
> -	cleanup_push(free, body);
> +	cleanup_push_heap(body);
>  	if (!read_all(h->fd, body, msg->hdr.len, 0)) { /* Cancellation point */
>  		saved_errno = errno;
>  		goto error_freebody;
> @@ -1098,6 +1106,7 @@ static int read_message(struct xs_handle
>  		/* There should only ever be one response pending! */
>  		if (!list_empty(&h->reply_list)) {
>  			mutex_unlock(&h->reply_mutex);
> +			saved_errno = EEXIST; 
>  			goto error_freebody;
>  		}
>  
> @@ -1110,9 +1119,9 @@ static int read_message(struct xs_handle
>  	ret = 0;
>  
>  error_freebody:
> -	cleanup_pop(ret == -1);
> +	cleanup_pop_heap(ret == -1, body);
>  error_freemsg:
> -	cleanup_pop(ret == -1);
> +	cleanup_pop_heap(ret == -1, msg);
>  error:
>  	errno = saved_errno;
>  



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 14 15:30:36 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 15:30:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TCXqT-0003IU-NT; Fri, 14 Sep 2012 15:30:17 +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 1TCXqS-0003IP-E3
	for xen-devel@lists.xensource.com; Fri, 14 Sep 2012 15:30:16 +0000
Received: from [85.158.139.83:38465] by server-9.bemta-5.messagelabs.com id
	66/EA-20529-78D43505; Fri, 14 Sep 2012 15:30:15 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1347636613!30220041!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDkyOTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12008 invoked from network); 14 Sep 2012 15:30:13 -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;
	14 Sep 2012 15:30:13 -0000
X-IronPort-AV: E=Sophos;i="4.80,423,1344211200"; d="scan'208";a="14550607"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Sep 2012 15:30:13 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Fri, 14 Sep 2012 16:30:13 +0100
Date: Fri, 14 Sep 2012 16:29:30 +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: <1347635324.24226.229.camel@zakaz.uk.xensource.com>
Message-ID: <alpine.DEB.2.02.1209141624570.29232@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1209141145150.29232@kaball.uk.xensource.com>
	<1347621207-11294-14-git-send-email-stefano.stabellini@eu.citrix.com>
	<20120914131033.GM25249@phenom.dumpdata.com>
	<alpine.DEB.2.02.1209141550080.29232@kaball.uk.xensource.com>
	<1347635324.24226.229.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>,
	"linaro-dev@lists.linaro.org" <linaro-dev@lists.linaro.org>,
	"arnd@arndb.de" <arnd@arndb.de>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"catalin.marinas@arm.com" <catalin.marinas@arm.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"Tim \(Xen.org\)" <tim@xen.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux@arm.linux.org.uk" <linux@arm.linux.org.uk>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Xen-devel] [PATCH v4 14/24] xen/arm: initialize grant_table on
	ARM
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 14 Sep 2012, Ian Campbell wrote:
> On Fri, 2012-09-14 at 15:56 +0100, Stefano Stabellini wrote:
> > On Fri, 14 Sep 2012, Konrad Rzeszutek Wilk wrote:
> > > On Fri, Sep 14, 2012 at 12:13:16PM +0100, Stefano Stabellini wrote:
> > > > Initialize the grant table mapping at the address specified at index 0
> > > > in the DT under the /xen node.
> > > > After the grant table is initialized, call xenbus_probe (if not dom0).
> > > 
> > > So we don't really care about the grant's size then? The DT xen.txt
> > > talks about it..
> > 
> > I am assuming that the size of the memory region specified in the device
> > tree is sufficiently large to map the entire grant table, given that both
> > the device tree hypervisor entry and the grant table size comes from Xen.
> 
> Actually, the grant table can grow dynamically under the control of the
> guest, I think you just pass GNTTABOP_setup_table with some more frames.
> See drivers/xen/grant_table.c:gnttab_expand().

gnttab_expand can return error if the new size exceeds
gnttab_max_grant_frames(), that is implemented using
GNTTABOP_query_size.


> > The grant table size is currently queried to Xen directly via an
> > hypercall (GNTTABOP_query_size). Basically the size in the device tree
> > is redundant information.
> 
> This size is the size of the physical address space where the guest
> could chose map grant table frames. It could be either larger or smaller
> than the actual grant table. (smaller because the guest could use
> physical addresses not within this region, if it wanted to for some
> reason).

Right.

What I am saying is that I assume that the memory region specified in
the device tree is greater or equal than gnttab_max_grant_frames().
Maybe I should add this to the device tree doc.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 14 15:30:36 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 15:30:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TCXqT-0003IU-NT; Fri, 14 Sep 2012 15:30:17 +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 1TCXqS-0003IP-E3
	for xen-devel@lists.xensource.com; Fri, 14 Sep 2012 15:30:16 +0000
Received: from [85.158.139.83:38465] by server-9.bemta-5.messagelabs.com id
	66/EA-20529-78D43505; Fri, 14 Sep 2012 15:30:15 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1347636613!30220041!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDkyOTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12008 invoked from network); 14 Sep 2012 15:30:13 -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;
	14 Sep 2012 15:30:13 -0000
X-IronPort-AV: E=Sophos;i="4.80,423,1344211200"; d="scan'208";a="14550607"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Sep 2012 15:30:13 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Fri, 14 Sep 2012 16:30:13 +0100
Date: Fri, 14 Sep 2012 16:29:30 +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: <1347635324.24226.229.camel@zakaz.uk.xensource.com>
Message-ID: <alpine.DEB.2.02.1209141624570.29232@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1209141145150.29232@kaball.uk.xensource.com>
	<1347621207-11294-14-git-send-email-stefano.stabellini@eu.citrix.com>
	<20120914131033.GM25249@phenom.dumpdata.com>
	<alpine.DEB.2.02.1209141550080.29232@kaball.uk.xensource.com>
	<1347635324.24226.229.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>,
	"linaro-dev@lists.linaro.org" <linaro-dev@lists.linaro.org>,
	"arnd@arndb.de" <arnd@arndb.de>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"catalin.marinas@arm.com" <catalin.marinas@arm.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"Tim \(Xen.org\)" <tim@xen.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux@arm.linux.org.uk" <linux@arm.linux.org.uk>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Xen-devel] [PATCH v4 14/24] xen/arm: initialize grant_table on
	ARM
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 14 Sep 2012, Ian Campbell wrote:
> On Fri, 2012-09-14 at 15:56 +0100, Stefano Stabellini wrote:
> > On Fri, 14 Sep 2012, Konrad Rzeszutek Wilk wrote:
> > > On Fri, Sep 14, 2012 at 12:13:16PM +0100, Stefano Stabellini wrote:
> > > > Initialize the grant table mapping at the address specified at index 0
> > > > in the DT under the /xen node.
> > > > After the grant table is initialized, call xenbus_probe (if not dom0).
> > > 
> > > So we don't really care about the grant's size then? The DT xen.txt
> > > talks about it..
> > 
> > I am assuming that the size of the memory region specified in the device
> > tree is sufficiently large to map the entire grant table, given that both
> > the device tree hypervisor entry and the grant table size comes from Xen.
> 
> Actually, the grant table can grow dynamically under the control of the
> guest, I think you just pass GNTTABOP_setup_table with some more frames.
> See drivers/xen/grant_table.c:gnttab_expand().

gnttab_expand can return error if the new size exceeds
gnttab_max_grant_frames(), that is implemented using
GNTTABOP_query_size.


> > The grant table size is currently queried to Xen directly via an
> > hypercall (GNTTABOP_query_size). Basically the size in the device tree
> > is redundant information.
> 
> This size is the size of the physical address space where the guest
> could chose map grant table frames. It could be either larger or smaller
> than the actual grant table. (smaller because the guest could use
> physical addresses not within this region, if it wanted to for some
> reason).

Right.

What I am saying is that I assume that the memory region specified in
the device tree is greater or equal than gnttab_max_grant_frames().
Maybe I should add this to the device tree doc.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 14 15:35:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 15: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 1TCXuz-0003a7-Dk; Fri, 14 Sep 2012 15:34: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 1TCXux-0003a1-L6
	for xen-devel@lists.xensource.com; Fri, 14 Sep 2012 15:34:55 +0000
Received: from [85.158.143.99:9273] by server-1.bemta-4.messagelabs.com id
	75/F0-12504-E9E43505; Fri, 14 Sep 2012 15:34:54 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1347636894!30380297!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDkyOTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31216 invoked from network); 14 Sep 2012 15:34:54 -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;
	14 Sep 2012 15:34:54 -0000
X-IronPort-AV: E=Sophos;i="4.80,423,1344211200"; d="scan'208";a="14550853"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Sep 2012 15:34: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.279.1;
	Fri, 14 Sep 2012 16:34:21 +0100
Message-ID: <1347636860.24226.236.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Date: Fri, 14 Sep 2012 16:34:20 +0100
In-Reply-To: <alpine.DEB.2.02.1209141624570.29232@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1209141145150.29232@kaball.uk.xensource.com>
	<1347621207-11294-14-git-send-email-stefano.stabellini@eu.citrix.com>
	<20120914131033.GM25249@phenom.dumpdata.com>
	<alpine.DEB.2.02.1209141550080.29232@kaball.uk.xensource.com>
	<1347635324.24226.229.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.02.1209141624570.29232@kaball.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linaro-dev@lists.linaro.org" <linaro-dev@lists.linaro.org>,
	"arnd@arndb.de" <arnd@arndb.de>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"catalin.marinas@arm.com" <catalin.marinas@arm.com>,
	"Tim \(Xen.org\)" <tim@xen.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux@arm.linux.org.uk" <linux@arm.linux.org.uk>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Xen-devel] [PATCH v4 14/24] xen/arm: initialize grant_table on
	ARM
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-09-14 at 16:29 +0100, Stefano Stabellini wrote:
> On Fri, 14 Sep 2012, Ian Campbell wrote:
> > On Fri, 2012-09-14 at 15:56 +0100, Stefano Stabellini wrote:
> > > On Fri, 14 Sep 2012, Konrad Rzeszutek Wilk wrote:
> > > > On Fri, Sep 14, 2012 at 12:13:16PM +0100, Stefano Stabellini wrote:
> > > > > Initialize the grant table mapping at the address specified at index 0
> > > > > in the DT under the /xen node.
> > > > > After the grant table is initialized, call xenbus_probe (if not dom0).
> > > > 
> > > > So we don't really care about the grant's size then? The DT xen.txt
> > > > talks about it..
> > > 
> > > I am assuming that the size of the memory region specified in the device
> > > tree is sufficiently large to map the entire grant table, given that both
> > > the device tree hypervisor entry and the grant table size comes from Xen.
> > 
> > Actually, the grant table can grow dynamically under the control of the
> > guest, I think you just pass GNTTABOP_setup_table with some more frames.
> > See drivers/xen/grant_table.c:gnttab_expand().
> 
> gnttab_expand can return error if the new size exceeds
> gnttab_max_grant_frames(), that is implemented using
> GNTTABOP_query_size.

I hadn't spotted / wasn't aware that this gives you the max too.

> > > The grant table size is currently queried to Xen directly via an
> > > hypercall (GNTTABOP_query_size). Basically the size in the device tree
> > > is redundant information.
> > 
> > This size is the size of the physical address space where the guest
> > could chose map grant table frames. It could be either larger or smaller
> > than the actual grant table. (smaller because the guest could use
> > physical addresses not within this region, if it wanted to for some
> > reason).
> 
> Right.
> 
> What I am saying is that I assume that the memory region specified in
> the device tree is greater or equal than gnttab_max_grant_frames().

Makes sense.

(note that gnttab_max_grant_frames can be set on the hypervisor command
line though)

> Maybe I should add this to the device tree doc.

No harm in being explicit. 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 14 15:35:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 15: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 1TCXuz-0003a7-Dk; Fri, 14 Sep 2012 15:34: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 1TCXux-0003a1-L6
	for xen-devel@lists.xensource.com; Fri, 14 Sep 2012 15:34:55 +0000
Received: from [85.158.143.99:9273] by server-1.bemta-4.messagelabs.com id
	75/F0-12504-E9E43505; Fri, 14 Sep 2012 15:34:54 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1347636894!30380297!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDkyOTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31216 invoked from network); 14 Sep 2012 15:34:54 -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;
	14 Sep 2012 15:34:54 -0000
X-IronPort-AV: E=Sophos;i="4.80,423,1344211200"; d="scan'208";a="14550853"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Sep 2012 15:34: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.279.1;
	Fri, 14 Sep 2012 16:34:21 +0100
Message-ID: <1347636860.24226.236.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Date: Fri, 14 Sep 2012 16:34:20 +0100
In-Reply-To: <alpine.DEB.2.02.1209141624570.29232@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1209141145150.29232@kaball.uk.xensource.com>
	<1347621207-11294-14-git-send-email-stefano.stabellini@eu.citrix.com>
	<20120914131033.GM25249@phenom.dumpdata.com>
	<alpine.DEB.2.02.1209141550080.29232@kaball.uk.xensource.com>
	<1347635324.24226.229.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.02.1209141624570.29232@kaball.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linaro-dev@lists.linaro.org" <linaro-dev@lists.linaro.org>,
	"arnd@arndb.de" <arnd@arndb.de>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"catalin.marinas@arm.com" <catalin.marinas@arm.com>,
	"Tim \(Xen.org\)" <tim@xen.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux@arm.linux.org.uk" <linux@arm.linux.org.uk>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Xen-devel] [PATCH v4 14/24] xen/arm: initialize grant_table on
	ARM
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-09-14 at 16:29 +0100, Stefano Stabellini wrote:
> On Fri, 14 Sep 2012, Ian Campbell wrote:
> > On Fri, 2012-09-14 at 15:56 +0100, Stefano Stabellini wrote:
> > > On Fri, 14 Sep 2012, Konrad Rzeszutek Wilk wrote:
> > > > On Fri, Sep 14, 2012 at 12:13:16PM +0100, Stefano Stabellini wrote:
> > > > > Initialize the grant table mapping at the address specified at index 0
> > > > > in the DT under the /xen node.
> > > > > After the grant table is initialized, call xenbus_probe (if not dom0).
> > > > 
> > > > So we don't really care about the grant's size then? The DT xen.txt
> > > > talks about it..
> > > 
> > > I am assuming that the size of the memory region specified in the device
> > > tree is sufficiently large to map the entire grant table, given that both
> > > the device tree hypervisor entry and the grant table size comes from Xen.
> > 
> > Actually, the grant table can grow dynamically under the control of the
> > guest, I think you just pass GNTTABOP_setup_table with some more frames.
> > See drivers/xen/grant_table.c:gnttab_expand().
> 
> gnttab_expand can return error if the new size exceeds
> gnttab_max_grant_frames(), that is implemented using
> GNTTABOP_query_size.

I hadn't spotted / wasn't aware that this gives you the max too.

> > > The grant table size is currently queried to Xen directly via an
> > > hypercall (GNTTABOP_query_size). Basically the size in the device tree
> > > is redundant information.
> > 
> > This size is the size of the physical address space where the guest
> > could chose map grant table frames. It could be either larger or smaller
> > than the actual grant table. (smaller because the guest could use
> > physical addresses not within this region, if it wanted to for some
> > reason).
> 
> Right.
> 
> What I am saying is that I assume that the memory region specified in
> the device tree is greater or equal than gnttab_max_grant_frames().

Makes sense.

(note that gnttab_max_grant_frames can be set on the hypervisor command
line though)

> Maybe I should add this to the device tree doc.

No harm in being explicit. 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 14 15:35:33 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 15:35:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TCXvJ-0003bt-Qs; Fri, 14 Sep 2012 15:35: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 1TCXvI-0003bd-FG
	for xen-devel@lists.xen.org; Fri, 14 Sep 2012 15:35:16 +0000
Received: from [85.158.138.51:19925] by server-10.bemta-3.messagelabs.com id
	1B/F1-10411-3BE43505; Fri, 14 Sep 2012 15:35:15 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1347636914!30677578!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDkyOTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23662 invoked from network); 14 Sep 2012 15:35:14 -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;
	14 Sep 2012 15:35:14 -0000
X-IronPort-AV: E=Sophos;i="4.80,423,1344211200"; d="scan'208";a="14550864"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Sep 2012 15:34: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.279.1;
	Fri, 14 Sep 2012 16:34:48 +0100
Message-ID: <1347636887.24226.237.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Fri, 14 Sep 2012 16:34:47 +0100
In-Reply-To: <20563.16972.124870.221950@mariner.uk.xensource.com>
References: <58ab3fb73d13e250f334.1347620998@cosworth.uk.xensource.com>
	<20563.16972.124870.221950@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] libxl: Enable -Wshadow
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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-09-14 at 15:42 +0100, Ian Jackson wrote:
> If we're doing -Wshadow then macros which introduce local variables
> like this should give them names qualified somehow for the macro.

Done, v2 below.

Since I was touching every line I fixed the line length in those macros
too.

8<------------------------------------------------------

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1347636539 -3600
# Node ID 6aacce1d8650e4fec5ddc524fd9a779e05434b26
# Parent  0547430886c507989dd9091ef5f1e2d089a50351
libxl: Enable -Wshadow.

It was convenient to invent $(CFLAGS_LIBXL) to do this.

Various renamings to avoid shadowing standard functions:
  - index(3)
  - listen(2)
  - link(2)
  - abort(3)
  - abs(3)

Reduced the scope of some variables to avoid conflicts.

Change to libxc is due to the nested hypercall buf macros in
set_xen_guest_handle (used in libxl) using the same local private vars.

Build tested only.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r 0547430886c5 -r 6aacce1d8650 tools/libxc/xenctrl.h
--- a/tools/libxc/xenctrl.h	Fri Sep 14 11:00:40 2012 +0100
+++ b/tools/libxc/xenctrl.h	Fri Sep 14 16:28:59 2012 +0100
@@ -235,11 +235,13 @@ typedef struct xc_hypercall_buffer xc_hy
 /*
  * Returns the hypercall_buffer associated with a variable.
  */
-#define HYPERCALL_BUFFER(_name)                                                              \
-    ({  xc_hypercall_buffer_t _val1;                                                         \
-        typeof(XC__HYPERCALL_BUFFER_NAME(_name)) *_val2 = &XC__HYPERCALL_BUFFER_NAME(_name); \
-        (void)(&_val1 == _val2);                                                             \
-        (_val2)->param_shadow ? (_val2)->param_shadow : (_val2);                             \
+#define HYPERCALL_BUFFER(_name)                                 \
+    ({  xc_hypercall_buffer_t _hcbuf_buf1;                      \
+        typeof(XC__HYPERCALL_BUFFER_NAME(_name)) *_hcbuf_buf2 = \
+                &XC__HYPERCALL_BUFFER_NAME(_name);              \
+        (void)(&_hcbuf_buf1 == _hcbuf_buf2);                    \
+        (_hcbuf_buf2)->param_shadow ?                           \
+                (_hcbuf_buf2)->param_shadow : (_hcbuf_buf2);    \
      })
 
 #define HYPERCALL_BUFFER_INIT_NO_BOUNCE .dir = 0, .sz = 0, .ubuf = (void *)-1
@@ -273,11 +275,12 @@ typedef struct xc_hypercall_buffer xc_hy
  * Get the hypercall buffer data pointer in a form suitable for use
  * directly as a hypercall argument.
  */
-#define HYPERCALL_BUFFER_AS_ARG(_name)                                             \
-    ({  xc_hypercall_buffer_t _val1;                                               \
-        typeof(XC__HYPERCALL_BUFFER_NAME(_name)) *_val2 = HYPERCALL_BUFFER(_name); \
-        (void)(&_val1 == _val2);                                                   \
-        (unsigned long)(_val2)->hbuf;                                              \
+#define HYPERCALL_BUFFER_AS_ARG(_name)                          \
+    ({  xc_hypercall_buffer_t _hcbuf_arg1;                      \
+        typeof(XC__HYPERCALL_BUFFER_NAME(_name)) *_hcbuf_arg2 = \
+                HYPERCALL_BUFFER(_name);                        \
+        (void)(&_hcbuf_arg1 == _hcbuf_arg2);                    \
+        (unsigned long)(_hcbuf_arg2)->hbuf;                     \
      })
 
 /*
@@ -285,12 +288,13 @@ typedef struct xc_hypercall_buffer xc_hy
  * data pointer has been correctly allocated.
  */
 #undef set_xen_guest_handle
-#define set_xen_guest_handle(_hnd, _val)                                         \
-    do {                                                                         \
-        xc_hypercall_buffer_t _val1;                                             \
-        typeof(XC__HYPERCALL_BUFFER_NAME(_val)) *_val2 = HYPERCALL_BUFFER(_val); \
-        (void) (&_val1 == _val2);                                                 \
-        set_xen_guest_handle_raw(_hnd, (_val2)->hbuf);                           \
+#define set_xen_guest_handle(_hnd, _val)                        \
+    do {                                                        \
+        xc_hypercall_buffer_t _hcbuf_hnd1;                      \
+        typeof(XC__HYPERCALL_BUFFER_NAME(_val)) *_hcbuf_hnd2 =  \
+                HYPERCALL_BUFFER(_val);                         \
+        (void) (&_hcbuf_hnd1 == _hcbuf_hnd2);                   \
+        set_xen_guest_handle_raw(_hnd, (_hcbuf_hnd2)->hbuf);    \
     } while (0)
 
 /* Use with set_xen_guest_handle in place of NULL */
diff -r 0547430886c5 -r 6aacce1d8650 tools/libxl/Makefile
--- a/tools/libxl/Makefile	Fri Sep 14 11:00:40 2012 +0100
+++ b/tools/libxl/Makefile	Fri Sep 14 16:28:59 2012 +0100
@@ -22,6 +22,12 @@ endif
 LIBXL_LIBS =
 LIBXL_LIBS = $(LDLIBS_libxenctrl) $(LDLIBS_libxenguest) $(LDLIBS_libxenstore) $(LDLIBS_libblktapctl) $(PTYFUNCS_LIBS) $(LIBUUID_LIBS)
 
+CFLAGS_LIBXL += $(CFLAGS_libxenctrl)
+CFLAGS_LIBXL += $(CFLAGS_libxenguest)
+CFLAGS_LIBXL += $(CFLAGS_libxenstore)
+CFLAGS_LIBXL += $(CFLAGS_libblktapctl) 
+CFLAGS_LIBXL += -Wshadow
+
 CFLAGS += $(PTHREAD_CFLAGS)
 LDFLAGS += $(PTHREAD_LDFLAGS)
 LIBXL_LIBS += $(PTHREAD_LIBS)
@@ -71,7 +77,7 @@ LIBXL_OBJS = flexarray.o libxl.o libxl_c
 			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
+$(LIBXL_OBJS): CFLAGS += $(CFLAGS_LIBXL) -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
diff -r 0547430886c5 -r 6aacce1d8650 tools/libxl/flexarray.c
--- a/tools/libxl/flexarray.c	Fri Sep 14 11:00:40 2012 +0100
+++ b/tools/libxl/flexarray.c	Fri Sep 14 16:28:59 2012 +0100
@@ -48,19 +48,19 @@ int flexarray_grow(flexarray_t *array, i
     return 0;
 }
 
-int flexarray_set(flexarray_t *array, unsigned int index, void *ptr)
+int flexarray_set(flexarray_t *array, unsigned int idx, void *ptr)
 {
-    if (index >= array->size) {
+    if (idx >= array->size) {
         int newsize;
         if (!array->autogrow)
             return 1;
-        newsize = (array->size * 2 < index) ? index + 1 : array->size * 2;
+        newsize = (array->size * 2 < idx) ? idx + 1 : array->size * 2;
         if (flexarray_grow(array, newsize - array->size))
             return 2;
     }
-    if ( index + 1 > array->count )
-        array->count = index + 1;
-    array->data[index] = ptr;
+    if ( idx + 1 > array->count )
+        array->count = idx + 1;
+    array->data[idx] = ptr;
     return 0;
 }
 
@@ -92,11 +92,11 @@ int flexarray_vappend(flexarray_t *array
     return ret;
 }
 
-int flexarray_get(flexarray_t *array, int index, void **ptr)
+int flexarray_get(flexarray_t *array, int idx, void **ptr)
 {
-    if (index >= array->size)
+    if (idx >= array->size)
         return 1;
-    *ptr = array->data[index];
+    *ptr = array->data[idx];
     return 0;
 }
 
diff -r 0547430886c5 -r 6aacce1d8650 tools/libxl/libxl.c
--- a/tools/libxl/libxl.c	Fri Sep 14 11:00:40 2012 +0100
+++ b/tools/libxl/libxl.c	Fri Sep 14 16:28:59 2012 +0100
@@ -665,7 +665,7 @@ out:
 libxl_vminfo * libxl_list_vm(libxl_ctx *ctx, int *nb_vm_out)
 {
     libxl_vminfo *ptr;
-    int index, i, ret;
+    int idx, i, ret;
     xc_domaininfo_t info[1024];
     int size = 1024;
 
@@ -678,15 +678,15 @@ libxl_vminfo * libxl_list_vm(libxl_ctx *
         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "geting domain info list");
         return NULL;
     }
-    for (index = i = 0; i < ret; i++) {
+    for (idx = i = 0; i < ret; i++) {
         if (libxl_is_stubdom(ctx, info[i].domain, NULL))
             continue;
-        memcpy(&(ptr[index].uuid), info[i].handle, sizeof(xen_domain_handle_t));
-        ptr[index].domid = info[i].domain;
-
-        index++;
-    }
-    *nb_vm_out = index;
+        memcpy(&(ptr[idx].uuid), info[i].handle, sizeof(xen_domain_handle_t));
+        ptr[idx].domid = info[i].domain;
+
+        idx++;
+    }
+    *nb_vm_out = idx;
     return ptr;
 }
 
@@ -3354,7 +3354,7 @@ int libxl_set_memory_target(libxl_ctx *c
         int32_t target_memkb, int relative, int enforce)
 {
     GC_INIT(ctx);
-    int rc = 1, abort = 0;
+    int rc = 1, abort_transaction = 0;
     uint32_t memorykb = 0, videoram = 0;
     uint32_t current_target_memkb = 0, new_target_memkb = 0;
     char *memmax, *endptr, *videoram_s = NULL, *target = NULL;
@@ -3373,7 +3373,7 @@ retry_transaction:
         xs_transaction_end(ctx->xsh, t, 1);
         rc = libxl__fill_dom0_memory_info(gc, &current_target_memkb);
         if (rc < 0) {
-            abort = 1;
+            abort_transaction = 1;
             goto out;
         }
         goto retry_transaction;
@@ -3381,7 +3381,7 @@ retry_transaction:
         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR,
                 "cannot get target memory info from %s/memory/target\n",
                 dompath);
-        abort = 1;
+        abort_transaction = 1;
         goto out;
     } else {
         current_target_memkb = strtoul(target, &endptr, 10);
@@ -3389,7 +3389,7 @@ retry_transaction:
             LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR,
                     "invalid memory target %s from %s/memory/target\n",
                     target, dompath);
-            abort = 1;
+            abort_transaction = 1;
             goto out;
         }
     }
@@ -3399,7 +3399,7 @@ retry_transaction:
         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR,
                 "cannot get memory info from %s/memory/static-max\n",
                 dompath);
-        abort = 1;
+        abort_transaction = 1;
         goto out;
     }
     memorykb = strtoul(memmax, &endptr, 10);
@@ -3407,7 +3407,7 @@ retry_transaction:
         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR,
                 "invalid max memory %s from %s/memory/static-max\n",
                 memmax, dompath);
-        abort = 1;
+        abort_transaction = 1;
         goto out;
     }
 
@@ -3422,7 +3422,7 @@ retry_transaction:
         LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
                 "memory_dynamic_max must be less than or equal to"
                 " memory_static_max\n");
-        abort = 1;
+        abort_transaction = 1;
         goto out;
     }
 
@@ -3430,7 +3430,7 @@ retry_transaction:
         LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
                 "new target %d for dom0 is below the minimum threshold\n",
                  new_target_memkb);
-        abort = 1;
+        abort_transaction = 1;
         goto out;
     }
     videoram_s = libxl__xs_read(gc, t, libxl__sprintf(gc,
@@ -3445,7 +3445,7 @@ retry_transaction:
             LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR,
                     "xc_domain_setmaxmem domid=%d memkb=%d failed "
                     "rc=%d\n", domid, memorykb + LIBXL_MAXMEM_CONSTANT, rc);
-            abort = 1;
+            abort_transaction = 1;
             goto out;
         }
     }
@@ -3458,7 +3458,7 @@ retry_transaction:
                 "xc_domain_set_pod_target domid=%d, memkb=%d "
                 "failed rc=%d\n", domid, new_target_memkb / 4,
                 rc);
-        abort = 1;
+        abort_transaction = 1;
         goto out;
     }
 
@@ -3466,7 +3466,7 @@ retry_transaction:
                 dompath), "%"PRIu32, new_target_memkb);
     rc = xc_domain_getinfolist(ctx->xch, domid, 1, &info);
     if (rc != 1 || info.domain != domid) {
-        abort = 1;
+        abort_transaction = 1;
         goto out;
     }
     xcinfo2xlinfo(&info, &ptr);
@@ -3475,7 +3475,8 @@ retry_transaction:
             "%"PRIu32, new_target_memkb / 1024);
 
 out:
-    if (!xs_transaction_end(ctx->xsh, t, abort) && !abort)
+    if (!xs_transaction_end(ctx->xsh, t, abort_transaction)
+        && !abort_transaction)
         if (errno == EAGAIN)
             goto retry_transaction;
 
diff -r 0547430886c5 -r 6aacce1d8650 tools/libxl/libxl_dm.c
--- a/tools/libxl/libxl_dm.c	Fri Sep 14 11:00:40 2012 +0100
+++ b/tools/libxl/libxl_dm.c	Fri Sep 14 16:28:59 2012 +0100
@@ -379,7 +379,7 @@ static char ** libxl__build_device_model
     }
     if (vnc) {
         int display = 0;
-        const char *listen = "127.0.0.1";
+        const char *addr = "127.0.0.1";
         char *vncarg = NULL;
 
         flexarray_append(dm_args, "-vnc");
@@ -387,16 +387,16 @@ static char ** libxl__build_device_model
         if (vnc->display) {
             display = vnc->display;
             if (vnc->listen && strchr(vnc->listen, ':') == NULL) {
-                listen = vnc->listen;
+                addr = vnc->listen;
             }
         } else if (vnc->listen) {
-            listen = vnc->listen;
+            addr = vnc->listen;
         }
 
-        if (strchr(listen, ':') != NULL)
-            vncarg = libxl__sprintf(gc, "%s", listen);
+        if (strchr(addr, ':') != NULL)
+            vncarg = libxl__sprintf(gc, "%s", addr);
         else
-            vncarg = libxl__sprintf(gc, "%s:%d", listen, display);
+            vncarg = libxl__sprintf(gc, "%s:%d", addr, display);
         if (vnc->passwd && vnc->passwd[0]) {
             vncarg = libxl__sprintf(gc, "%s,password", vncarg);
         }
diff -r 0547430886c5 -r 6aacce1d8650 tools/libxl/libxl_event.c
--- a/tools/libxl/libxl_event.c	Fri Sep 14 11:00:40 2012 +0100
+++ b/tools/libxl/libxl_event.c	Fri Sep 14 16:28:59 2012 +0100
@@ -167,15 +167,15 @@ static void time_insert_finite(libxl__gc
 }
 
 static int time_register_finite(libxl__gc *gc, libxl__ev_time *ev,
-                                struct timeval abs)
+                                struct timeval absolute)
 {
     int rc;
 
-    rc = OSEVENT_HOOK(timeout_register, &ev->for_app_reg, abs, ev);
+    rc = OSEVENT_HOOK(timeout_register, &ev->for_app_reg, absolute, ev);
     if (rc) return rc;
 
     ev->infinite = 0;
-    ev->abs = abs;
+    ev->abs = absolute;
     time_insert_finite(gc, ev);
 
     return 0;
@@ -202,16 +202,16 @@ static void time_done_debug(libxl__gc *g
 
 int libxl__ev_time_register_abs(libxl__gc *gc, libxl__ev_time *ev,
                                 libxl__ev_time_callback *func,
-                                struct timeval abs)
+                                struct timeval absolute)
 {
     int rc;
 
     CTX_LOCK;
 
     DBG("ev_time=%p register abs=%lu.%06lu",
-        ev, (unsigned long)abs.tv_sec, (unsigned long)abs.tv_usec);
+        ev, (unsigned long)absolute.tv_sec, (unsigned long)absolute.tv_usec);
 
-    rc = time_register_finite(gc, ev, abs);
+    rc = time_register_finite(gc, ev, absolute);
     if (rc) goto out;
 
     ev->func = func;
@@ -228,7 +228,7 @@ int libxl__ev_time_register_rel(libxl__g
                                 libxl__ev_time_callback *func,
                                 int milliseconds /* as for poll(2) */)
 {
-    struct timeval abs;
+    struct timeval absolute;
     int rc;
 
     CTX_LOCK;
@@ -238,10 +238,10 @@ int libxl__ev_time_register_rel(libxl__g
     if (milliseconds < 0) {
         ev->infinite = 1;
     } else {
-        rc = time_rel_to_abs(gc, milliseconds, &abs);
+        rc = time_rel_to_abs(gc, milliseconds, &absolute);
         if (rc) goto out;
 
-        rc = time_register_finite(gc, ev, abs);
+        rc = time_register_finite(gc, ev, absolute);
         if (rc) goto out;
     }
 
@@ -255,26 +255,26 @@ int libxl__ev_time_register_rel(libxl__g
 }
 
 int libxl__ev_time_modify_abs(libxl__gc *gc, libxl__ev_time *ev,
-                              struct timeval abs)
+                              struct timeval absolute)
 {
     int rc;
 
     CTX_LOCK;
 
     DBG("ev_time=%p modify abs==%lu.%06lu",
-        ev, (unsigned long)abs.tv_sec, (unsigned long)abs.tv_usec);
+        ev, (unsigned long)absolute.tv_sec, (unsigned long)absolute.tv_usec);
 
     assert(libxl__ev_time_isregistered(ev));
 
     if (ev->infinite) {
-        rc = time_register_finite(gc, ev, abs);
+        rc = time_register_finite(gc, ev, absolute);
         if (rc) goto out;
     } else {
-        rc = OSEVENT_HOOK(timeout_modify, &ev->for_app_reg, abs);
+        rc = OSEVENT_HOOK(timeout_modify, &ev->for_app_reg, absolute);
         if (rc) goto out;
 
         LIBXL_TAILQ_REMOVE(&CTX->etimes, ev, entry);
-        ev->abs = abs;
+        ev->abs = absolute;
         time_insert_finite(gc, ev);
     }
 
@@ -288,7 +288,7 @@ int libxl__ev_time_modify_abs(libxl__gc 
 int libxl__ev_time_modify_rel(libxl__gc *gc, libxl__ev_time *ev,
                               int milliseconds)
 {
-    struct timeval abs;
+    struct timeval absolute;
     int rc;
 
     CTX_LOCK;
@@ -304,10 +304,10 @@ int libxl__ev_time_modify_rel(libxl__gc 
         goto out;
     }
 
-    rc = time_rel_to_abs(gc, milliseconds, &abs);
+    rc = time_rel_to_abs(gc, milliseconds, &absolute);
     if (rc) goto out;
 
-    rc = libxl__ev_time_modify_abs(gc, ev, abs);
+    rc = libxl__ev_time_modify_abs(gc, ev, absolute);
     if (rc) goto out;
 
     rc = 0;
diff -r 0547430886c5 -r 6aacce1d8650 tools/libxl/libxl_exec.c
--- a/tools/libxl/libxl_exec.c	Fri Sep 14 11:00:40 2012 +0100
+++ b/tools/libxl/libxl_exec.c	Fri Sep 14 16:28:59 2012 +0100
@@ -35,7 +35,7 @@ static void check_open_fds(const char *w
 #ifdef __linux__
         size_t len;
         char path[PATH_MAX];
-        char link[PATH_MAX+1];
+        char linkpath[PATH_MAX+1];
 #endif
         flags = fcntl(i, F_GETFD);
         if ( flags == -1 ) {
@@ -52,11 +52,11 @@ static void check_open_fds(const char *w
 
 #ifdef __linux__
         snprintf(path, PATH_MAX, "/proc/%d/fd/%d", getpid(), i);
-        len = readlink(path, link, PATH_MAX);
+        len = readlink(path, linkpath, PATH_MAX);
         if (len > 0) {
-            link[len] = '\0';
+            linkpath[len] = '\0';
             fprintf(stderr, "libxl: execing %s: fd %d is open to %s with flags %#x\n",
-                    what, i, link, flags);
+                    what, i, linkpath, flags);
         } else
 #endif
             fprintf(stderr, "libxl: execing %s: fd %d is open with flags %#x\n",
diff -r 0547430886c5 -r 6aacce1d8650 tools/libxl/libxl_json.c
--- a/tools/libxl/libxl_json.c	Fri Sep 14 11:00:40 2012 +0100
+++ b/tools/libxl/libxl_json.c	Fri Sep 14 16:28:59 2012 +0100
@@ -275,7 +275,7 @@ static int json_object_append_to(libxl__
 
 void libxl__json_object_free(libxl__gc *gc, libxl__json_object *obj)
 {
-    int index = 0;
+    int idx = 0;
 
     if (obj == NULL)
         return;
@@ -287,8 +287,8 @@ void libxl__json_object_free(libxl__gc *
     case JSON_MAP: {
         libxl__json_map_node *node = NULL;
 
-        for (index = 0; index < obj->u.map->count; index++) {
-            if (flexarray_get(obj->u.map, index, (void**)&node) != 0)
+        for (idx = 0; idx < obj->u.map->count; idx++) {
+            if (flexarray_get(obj->u.map, idx, (void**)&node) != 0)
                 break;
             libxl__json_object_free(gc, node->obj);
             free(node->map_key);
@@ -302,8 +302,8 @@ void libxl__json_object_free(libxl__gc *
         libxl__json_object *node = NULL;
         break;
 
-        for (index = 0; index < obj->u.array->count; index++) {
-            if (flexarray_get(obj->u.array, index, (void**)&node) != 0)
+        for (idx = 0; idx < obj->u.array->count; idx++) {
+            if (flexarray_get(obj->u.array, idx, (void**)&node) != 0)
                 break;
             libxl__json_object_free(gc, node);
             node = NULL;
@@ -359,14 +359,14 @@ const libxl__json_object *libxl__json_ma
                                           libxl__json_node_type expected_type)
 {
     flexarray_t *maps = NULL;
-    int index = 0;
+    int idx = 0;
 
     if (libxl__json_object_is_map(o)) {
         libxl__json_map_node *node = NULL;
 
         maps = o->u.map;
-        for (index = 0; index < maps->count; index++) {
-            if (flexarray_get(maps, index, (void**)&node) != 0)
+        for (idx = 0; idx < maps->count; idx++) {
+            if (flexarray_get(maps, idx, (void**)&node) != 0)
                 return NULL;
             if (strcmp(key, node->map_key) == 0) {
                 if (expected_type == JSON_ANY
diff -r 0547430886c5 -r 6aacce1d8650 tools/libxl/libxl_pci.c
--- a/tools/libxl/libxl_pci.c	Fri Sep 14 11:00:40 2012 +0100
+++ b/tools/libxl/libxl_pci.c	Fri Sep 14 16:28:59 2012 +0100
@@ -167,7 +167,6 @@ static int libxl__device_pci_remove_xens
     char *be_path, *num_devs_path, *num_devs, *xsdev, *tmp, *tmppath;
     int num, i, j;
     xs_transaction_t t;
-    unsigned int domain = 0, bus = 0, dev = 0, func = 0;
 
     be_path = libxl__sprintf(gc, "%s/backend/pci/%d/0", libxl__xs_get_dompath(gc, 0), domid);
     num_devs_path = libxl__sprintf(gc, "%s/num_devs", be_path);
@@ -188,6 +187,7 @@ static int libxl__device_pci_remove_xens
     }
 
     for (i = 0; i < num; i++) {
+        unsigned int domain = 0, bus = 0, dev = 0, func = 0;
         xsdev = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/dev-%d", be_path, i));
         sscanf(xsdev, PCI_BDF, &domain, &bus, &dev, &func);
         if (domain == pcidev->domain && bus == pcidev->bus &&
diff -r 0547430886c5 -r 6aacce1d8650 tools/libxl/libxl_qmp.c
--- a/tools/libxl/libxl_qmp.c	Fri Sep 14 11:00:40 2012 +0100
+++ b/tools/libxl/libxl_qmp.c	Fri Sep 14 16:28:59 2012 +0100
@@ -171,7 +171,7 @@ static int qmp_register_vnc_callback(lib
 {
     GC_INIT(qmp->ctx);
     const libxl__json_object *obj;
-    const char *listen, *port;
+    const char *addr, *port;
     int rc = -1;
 
     if (!libxl__json_object_is_map(o)) {
@@ -184,17 +184,17 @@ static int qmp_register_vnc_callback(lib
     }
 
     obj = libxl__json_map_get("host", o, JSON_STRING);
-    listen = libxl__json_object_get_string(obj);
+    addr = libxl__json_object_get_string(obj);
     obj = libxl__json_map_get("service", o, JSON_STRING);
     port = libxl__json_object_get_string(obj);
 
-    if (!listen || !port) {
+    if (!addr || !port) {
         LIBXL__LOG(qmp->ctx, LIBXL__LOG_ERROR,
                    "Failed to retreive VNC connect information.");
         goto out;
     }
 
-    rc = qmp_write_domain_console_item(gc, qmp->domid, "vnc-listen", listen);
+    rc = qmp_write_domain_console_item(gc, qmp->domid, "vnc-listen", addr);
     if (!rc)
         rc = qmp_write_domain_console_item(gc, qmp->domid, "vnc-port", port);
 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 14 15:35:33 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 15:35:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TCXvJ-0003bt-Qs; Fri, 14 Sep 2012 15:35: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 1TCXvI-0003bd-FG
	for xen-devel@lists.xen.org; Fri, 14 Sep 2012 15:35:16 +0000
Received: from [85.158.138.51:19925] by server-10.bemta-3.messagelabs.com id
	1B/F1-10411-3BE43505; Fri, 14 Sep 2012 15:35:15 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1347636914!30677578!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDkyOTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23662 invoked from network); 14 Sep 2012 15:35:14 -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;
	14 Sep 2012 15:35:14 -0000
X-IronPort-AV: E=Sophos;i="4.80,423,1344211200"; d="scan'208";a="14550864"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Sep 2012 15:34: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.279.1;
	Fri, 14 Sep 2012 16:34:48 +0100
Message-ID: <1347636887.24226.237.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Fri, 14 Sep 2012 16:34:47 +0100
In-Reply-To: <20563.16972.124870.221950@mariner.uk.xensource.com>
References: <58ab3fb73d13e250f334.1347620998@cosworth.uk.xensource.com>
	<20563.16972.124870.221950@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] libxl: Enable -Wshadow
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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-09-14 at 15:42 +0100, Ian Jackson wrote:
> If we're doing -Wshadow then macros which introduce local variables
> like this should give them names qualified somehow for the macro.

Done, v2 below.

Since I was touching every line I fixed the line length in those macros
too.

8<------------------------------------------------------

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1347636539 -3600
# Node ID 6aacce1d8650e4fec5ddc524fd9a779e05434b26
# Parent  0547430886c507989dd9091ef5f1e2d089a50351
libxl: Enable -Wshadow.

It was convenient to invent $(CFLAGS_LIBXL) to do this.

Various renamings to avoid shadowing standard functions:
  - index(3)
  - listen(2)
  - link(2)
  - abort(3)
  - abs(3)

Reduced the scope of some variables to avoid conflicts.

Change to libxc is due to the nested hypercall buf macros in
set_xen_guest_handle (used in libxl) using the same local private vars.

Build tested only.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r 0547430886c5 -r 6aacce1d8650 tools/libxc/xenctrl.h
--- a/tools/libxc/xenctrl.h	Fri Sep 14 11:00:40 2012 +0100
+++ b/tools/libxc/xenctrl.h	Fri Sep 14 16:28:59 2012 +0100
@@ -235,11 +235,13 @@ typedef struct xc_hypercall_buffer xc_hy
 /*
  * Returns the hypercall_buffer associated with a variable.
  */
-#define HYPERCALL_BUFFER(_name)                                                              \
-    ({  xc_hypercall_buffer_t _val1;                                                         \
-        typeof(XC__HYPERCALL_BUFFER_NAME(_name)) *_val2 = &XC__HYPERCALL_BUFFER_NAME(_name); \
-        (void)(&_val1 == _val2);                                                             \
-        (_val2)->param_shadow ? (_val2)->param_shadow : (_val2);                             \
+#define HYPERCALL_BUFFER(_name)                                 \
+    ({  xc_hypercall_buffer_t _hcbuf_buf1;                      \
+        typeof(XC__HYPERCALL_BUFFER_NAME(_name)) *_hcbuf_buf2 = \
+                &XC__HYPERCALL_BUFFER_NAME(_name);              \
+        (void)(&_hcbuf_buf1 == _hcbuf_buf2);                    \
+        (_hcbuf_buf2)->param_shadow ?                           \
+                (_hcbuf_buf2)->param_shadow : (_hcbuf_buf2);    \
      })
 
 #define HYPERCALL_BUFFER_INIT_NO_BOUNCE .dir = 0, .sz = 0, .ubuf = (void *)-1
@@ -273,11 +275,12 @@ typedef struct xc_hypercall_buffer xc_hy
  * Get the hypercall buffer data pointer in a form suitable for use
  * directly as a hypercall argument.
  */
-#define HYPERCALL_BUFFER_AS_ARG(_name)                                             \
-    ({  xc_hypercall_buffer_t _val1;                                               \
-        typeof(XC__HYPERCALL_BUFFER_NAME(_name)) *_val2 = HYPERCALL_BUFFER(_name); \
-        (void)(&_val1 == _val2);                                                   \
-        (unsigned long)(_val2)->hbuf;                                              \
+#define HYPERCALL_BUFFER_AS_ARG(_name)                          \
+    ({  xc_hypercall_buffer_t _hcbuf_arg1;                      \
+        typeof(XC__HYPERCALL_BUFFER_NAME(_name)) *_hcbuf_arg2 = \
+                HYPERCALL_BUFFER(_name);                        \
+        (void)(&_hcbuf_arg1 == _hcbuf_arg2);                    \
+        (unsigned long)(_hcbuf_arg2)->hbuf;                     \
      })
 
 /*
@@ -285,12 +288,13 @@ typedef struct xc_hypercall_buffer xc_hy
  * data pointer has been correctly allocated.
  */
 #undef set_xen_guest_handle
-#define set_xen_guest_handle(_hnd, _val)                                         \
-    do {                                                                         \
-        xc_hypercall_buffer_t _val1;                                             \
-        typeof(XC__HYPERCALL_BUFFER_NAME(_val)) *_val2 = HYPERCALL_BUFFER(_val); \
-        (void) (&_val1 == _val2);                                                 \
-        set_xen_guest_handle_raw(_hnd, (_val2)->hbuf);                           \
+#define set_xen_guest_handle(_hnd, _val)                        \
+    do {                                                        \
+        xc_hypercall_buffer_t _hcbuf_hnd1;                      \
+        typeof(XC__HYPERCALL_BUFFER_NAME(_val)) *_hcbuf_hnd2 =  \
+                HYPERCALL_BUFFER(_val);                         \
+        (void) (&_hcbuf_hnd1 == _hcbuf_hnd2);                   \
+        set_xen_guest_handle_raw(_hnd, (_hcbuf_hnd2)->hbuf);    \
     } while (0)
 
 /* Use with set_xen_guest_handle in place of NULL */
diff -r 0547430886c5 -r 6aacce1d8650 tools/libxl/Makefile
--- a/tools/libxl/Makefile	Fri Sep 14 11:00:40 2012 +0100
+++ b/tools/libxl/Makefile	Fri Sep 14 16:28:59 2012 +0100
@@ -22,6 +22,12 @@ endif
 LIBXL_LIBS =
 LIBXL_LIBS = $(LDLIBS_libxenctrl) $(LDLIBS_libxenguest) $(LDLIBS_libxenstore) $(LDLIBS_libblktapctl) $(PTYFUNCS_LIBS) $(LIBUUID_LIBS)
 
+CFLAGS_LIBXL += $(CFLAGS_libxenctrl)
+CFLAGS_LIBXL += $(CFLAGS_libxenguest)
+CFLAGS_LIBXL += $(CFLAGS_libxenstore)
+CFLAGS_LIBXL += $(CFLAGS_libblktapctl) 
+CFLAGS_LIBXL += -Wshadow
+
 CFLAGS += $(PTHREAD_CFLAGS)
 LDFLAGS += $(PTHREAD_LDFLAGS)
 LIBXL_LIBS += $(PTHREAD_LIBS)
@@ -71,7 +77,7 @@ LIBXL_OBJS = flexarray.o libxl.o libxl_c
 			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
+$(LIBXL_OBJS): CFLAGS += $(CFLAGS_LIBXL) -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
diff -r 0547430886c5 -r 6aacce1d8650 tools/libxl/flexarray.c
--- a/tools/libxl/flexarray.c	Fri Sep 14 11:00:40 2012 +0100
+++ b/tools/libxl/flexarray.c	Fri Sep 14 16:28:59 2012 +0100
@@ -48,19 +48,19 @@ int flexarray_grow(flexarray_t *array, i
     return 0;
 }
 
-int flexarray_set(flexarray_t *array, unsigned int index, void *ptr)
+int flexarray_set(flexarray_t *array, unsigned int idx, void *ptr)
 {
-    if (index >= array->size) {
+    if (idx >= array->size) {
         int newsize;
         if (!array->autogrow)
             return 1;
-        newsize = (array->size * 2 < index) ? index + 1 : array->size * 2;
+        newsize = (array->size * 2 < idx) ? idx + 1 : array->size * 2;
         if (flexarray_grow(array, newsize - array->size))
             return 2;
     }
-    if ( index + 1 > array->count )
-        array->count = index + 1;
-    array->data[index] = ptr;
+    if ( idx + 1 > array->count )
+        array->count = idx + 1;
+    array->data[idx] = ptr;
     return 0;
 }
 
@@ -92,11 +92,11 @@ int flexarray_vappend(flexarray_t *array
     return ret;
 }
 
-int flexarray_get(flexarray_t *array, int index, void **ptr)
+int flexarray_get(flexarray_t *array, int idx, void **ptr)
 {
-    if (index >= array->size)
+    if (idx >= array->size)
         return 1;
-    *ptr = array->data[index];
+    *ptr = array->data[idx];
     return 0;
 }
 
diff -r 0547430886c5 -r 6aacce1d8650 tools/libxl/libxl.c
--- a/tools/libxl/libxl.c	Fri Sep 14 11:00:40 2012 +0100
+++ b/tools/libxl/libxl.c	Fri Sep 14 16:28:59 2012 +0100
@@ -665,7 +665,7 @@ out:
 libxl_vminfo * libxl_list_vm(libxl_ctx *ctx, int *nb_vm_out)
 {
     libxl_vminfo *ptr;
-    int index, i, ret;
+    int idx, i, ret;
     xc_domaininfo_t info[1024];
     int size = 1024;
 
@@ -678,15 +678,15 @@ libxl_vminfo * libxl_list_vm(libxl_ctx *
         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "geting domain info list");
         return NULL;
     }
-    for (index = i = 0; i < ret; i++) {
+    for (idx = i = 0; i < ret; i++) {
         if (libxl_is_stubdom(ctx, info[i].domain, NULL))
             continue;
-        memcpy(&(ptr[index].uuid), info[i].handle, sizeof(xen_domain_handle_t));
-        ptr[index].domid = info[i].domain;
-
-        index++;
-    }
-    *nb_vm_out = index;
+        memcpy(&(ptr[idx].uuid), info[i].handle, sizeof(xen_domain_handle_t));
+        ptr[idx].domid = info[i].domain;
+
+        idx++;
+    }
+    *nb_vm_out = idx;
     return ptr;
 }
 
@@ -3354,7 +3354,7 @@ int libxl_set_memory_target(libxl_ctx *c
         int32_t target_memkb, int relative, int enforce)
 {
     GC_INIT(ctx);
-    int rc = 1, abort = 0;
+    int rc = 1, abort_transaction = 0;
     uint32_t memorykb = 0, videoram = 0;
     uint32_t current_target_memkb = 0, new_target_memkb = 0;
     char *memmax, *endptr, *videoram_s = NULL, *target = NULL;
@@ -3373,7 +3373,7 @@ retry_transaction:
         xs_transaction_end(ctx->xsh, t, 1);
         rc = libxl__fill_dom0_memory_info(gc, &current_target_memkb);
         if (rc < 0) {
-            abort = 1;
+            abort_transaction = 1;
             goto out;
         }
         goto retry_transaction;
@@ -3381,7 +3381,7 @@ retry_transaction:
         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR,
                 "cannot get target memory info from %s/memory/target\n",
                 dompath);
-        abort = 1;
+        abort_transaction = 1;
         goto out;
     } else {
         current_target_memkb = strtoul(target, &endptr, 10);
@@ -3389,7 +3389,7 @@ retry_transaction:
             LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR,
                     "invalid memory target %s from %s/memory/target\n",
                     target, dompath);
-            abort = 1;
+            abort_transaction = 1;
             goto out;
         }
     }
@@ -3399,7 +3399,7 @@ retry_transaction:
         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR,
                 "cannot get memory info from %s/memory/static-max\n",
                 dompath);
-        abort = 1;
+        abort_transaction = 1;
         goto out;
     }
     memorykb = strtoul(memmax, &endptr, 10);
@@ -3407,7 +3407,7 @@ retry_transaction:
         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR,
                 "invalid max memory %s from %s/memory/static-max\n",
                 memmax, dompath);
-        abort = 1;
+        abort_transaction = 1;
         goto out;
     }
 
@@ -3422,7 +3422,7 @@ retry_transaction:
         LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
                 "memory_dynamic_max must be less than or equal to"
                 " memory_static_max\n");
-        abort = 1;
+        abort_transaction = 1;
         goto out;
     }
 
@@ -3430,7 +3430,7 @@ retry_transaction:
         LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
                 "new target %d for dom0 is below the minimum threshold\n",
                  new_target_memkb);
-        abort = 1;
+        abort_transaction = 1;
         goto out;
     }
     videoram_s = libxl__xs_read(gc, t, libxl__sprintf(gc,
@@ -3445,7 +3445,7 @@ retry_transaction:
             LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR,
                     "xc_domain_setmaxmem domid=%d memkb=%d failed "
                     "rc=%d\n", domid, memorykb + LIBXL_MAXMEM_CONSTANT, rc);
-            abort = 1;
+            abort_transaction = 1;
             goto out;
         }
     }
@@ -3458,7 +3458,7 @@ retry_transaction:
                 "xc_domain_set_pod_target domid=%d, memkb=%d "
                 "failed rc=%d\n", domid, new_target_memkb / 4,
                 rc);
-        abort = 1;
+        abort_transaction = 1;
         goto out;
     }
 
@@ -3466,7 +3466,7 @@ retry_transaction:
                 dompath), "%"PRIu32, new_target_memkb);
     rc = xc_domain_getinfolist(ctx->xch, domid, 1, &info);
     if (rc != 1 || info.domain != domid) {
-        abort = 1;
+        abort_transaction = 1;
         goto out;
     }
     xcinfo2xlinfo(&info, &ptr);
@@ -3475,7 +3475,8 @@ retry_transaction:
             "%"PRIu32, new_target_memkb / 1024);
 
 out:
-    if (!xs_transaction_end(ctx->xsh, t, abort) && !abort)
+    if (!xs_transaction_end(ctx->xsh, t, abort_transaction)
+        && !abort_transaction)
         if (errno == EAGAIN)
             goto retry_transaction;
 
diff -r 0547430886c5 -r 6aacce1d8650 tools/libxl/libxl_dm.c
--- a/tools/libxl/libxl_dm.c	Fri Sep 14 11:00:40 2012 +0100
+++ b/tools/libxl/libxl_dm.c	Fri Sep 14 16:28:59 2012 +0100
@@ -379,7 +379,7 @@ static char ** libxl__build_device_model
     }
     if (vnc) {
         int display = 0;
-        const char *listen = "127.0.0.1";
+        const char *addr = "127.0.0.1";
         char *vncarg = NULL;
 
         flexarray_append(dm_args, "-vnc");
@@ -387,16 +387,16 @@ static char ** libxl__build_device_model
         if (vnc->display) {
             display = vnc->display;
             if (vnc->listen && strchr(vnc->listen, ':') == NULL) {
-                listen = vnc->listen;
+                addr = vnc->listen;
             }
         } else if (vnc->listen) {
-            listen = vnc->listen;
+            addr = vnc->listen;
         }
 
-        if (strchr(listen, ':') != NULL)
-            vncarg = libxl__sprintf(gc, "%s", listen);
+        if (strchr(addr, ':') != NULL)
+            vncarg = libxl__sprintf(gc, "%s", addr);
         else
-            vncarg = libxl__sprintf(gc, "%s:%d", listen, display);
+            vncarg = libxl__sprintf(gc, "%s:%d", addr, display);
         if (vnc->passwd && vnc->passwd[0]) {
             vncarg = libxl__sprintf(gc, "%s,password", vncarg);
         }
diff -r 0547430886c5 -r 6aacce1d8650 tools/libxl/libxl_event.c
--- a/tools/libxl/libxl_event.c	Fri Sep 14 11:00:40 2012 +0100
+++ b/tools/libxl/libxl_event.c	Fri Sep 14 16:28:59 2012 +0100
@@ -167,15 +167,15 @@ static void time_insert_finite(libxl__gc
 }
 
 static int time_register_finite(libxl__gc *gc, libxl__ev_time *ev,
-                                struct timeval abs)
+                                struct timeval absolute)
 {
     int rc;
 
-    rc = OSEVENT_HOOK(timeout_register, &ev->for_app_reg, abs, ev);
+    rc = OSEVENT_HOOK(timeout_register, &ev->for_app_reg, absolute, ev);
     if (rc) return rc;
 
     ev->infinite = 0;
-    ev->abs = abs;
+    ev->abs = absolute;
     time_insert_finite(gc, ev);
 
     return 0;
@@ -202,16 +202,16 @@ static void time_done_debug(libxl__gc *g
 
 int libxl__ev_time_register_abs(libxl__gc *gc, libxl__ev_time *ev,
                                 libxl__ev_time_callback *func,
-                                struct timeval abs)
+                                struct timeval absolute)
 {
     int rc;
 
     CTX_LOCK;
 
     DBG("ev_time=%p register abs=%lu.%06lu",
-        ev, (unsigned long)abs.tv_sec, (unsigned long)abs.tv_usec);
+        ev, (unsigned long)absolute.tv_sec, (unsigned long)absolute.tv_usec);
 
-    rc = time_register_finite(gc, ev, abs);
+    rc = time_register_finite(gc, ev, absolute);
     if (rc) goto out;
 
     ev->func = func;
@@ -228,7 +228,7 @@ int libxl__ev_time_register_rel(libxl__g
                                 libxl__ev_time_callback *func,
                                 int milliseconds /* as for poll(2) */)
 {
-    struct timeval abs;
+    struct timeval absolute;
     int rc;
 
     CTX_LOCK;
@@ -238,10 +238,10 @@ int libxl__ev_time_register_rel(libxl__g
     if (milliseconds < 0) {
         ev->infinite = 1;
     } else {
-        rc = time_rel_to_abs(gc, milliseconds, &abs);
+        rc = time_rel_to_abs(gc, milliseconds, &absolute);
         if (rc) goto out;
 
-        rc = time_register_finite(gc, ev, abs);
+        rc = time_register_finite(gc, ev, absolute);
         if (rc) goto out;
     }
 
@@ -255,26 +255,26 @@ int libxl__ev_time_register_rel(libxl__g
 }
 
 int libxl__ev_time_modify_abs(libxl__gc *gc, libxl__ev_time *ev,
-                              struct timeval abs)
+                              struct timeval absolute)
 {
     int rc;
 
     CTX_LOCK;
 
     DBG("ev_time=%p modify abs==%lu.%06lu",
-        ev, (unsigned long)abs.tv_sec, (unsigned long)abs.tv_usec);
+        ev, (unsigned long)absolute.tv_sec, (unsigned long)absolute.tv_usec);
 
     assert(libxl__ev_time_isregistered(ev));
 
     if (ev->infinite) {
-        rc = time_register_finite(gc, ev, abs);
+        rc = time_register_finite(gc, ev, absolute);
         if (rc) goto out;
     } else {
-        rc = OSEVENT_HOOK(timeout_modify, &ev->for_app_reg, abs);
+        rc = OSEVENT_HOOK(timeout_modify, &ev->for_app_reg, absolute);
         if (rc) goto out;
 
         LIBXL_TAILQ_REMOVE(&CTX->etimes, ev, entry);
-        ev->abs = abs;
+        ev->abs = absolute;
         time_insert_finite(gc, ev);
     }
 
@@ -288,7 +288,7 @@ int libxl__ev_time_modify_abs(libxl__gc 
 int libxl__ev_time_modify_rel(libxl__gc *gc, libxl__ev_time *ev,
                               int milliseconds)
 {
-    struct timeval abs;
+    struct timeval absolute;
     int rc;
 
     CTX_LOCK;
@@ -304,10 +304,10 @@ int libxl__ev_time_modify_rel(libxl__gc 
         goto out;
     }
 
-    rc = time_rel_to_abs(gc, milliseconds, &abs);
+    rc = time_rel_to_abs(gc, milliseconds, &absolute);
     if (rc) goto out;
 
-    rc = libxl__ev_time_modify_abs(gc, ev, abs);
+    rc = libxl__ev_time_modify_abs(gc, ev, absolute);
     if (rc) goto out;
 
     rc = 0;
diff -r 0547430886c5 -r 6aacce1d8650 tools/libxl/libxl_exec.c
--- a/tools/libxl/libxl_exec.c	Fri Sep 14 11:00:40 2012 +0100
+++ b/tools/libxl/libxl_exec.c	Fri Sep 14 16:28:59 2012 +0100
@@ -35,7 +35,7 @@ static void check_open_fds(const char *w
 #ifdef __linux__
         size_t len;
         char path[PATH_MAX];
-        char link[PATH_MAX+1];
+        char linkpath[PATH_MAX+1];
 #endif
         flags = fcntl(i, F_GETFD);
         if ( flags == -1 ) {
@@ -52,11 +52,11 @@ static void check_open_fds(const char *w
 
 #ifdef __linux__
         snprintf(path, PATH_MAX, "/proc/%d/fd/%d", getpid(), i);
-        len = readlink(path, link, PATH_MAX);
+        len = readlink(path, linkpath, PATH_MAX);
         if (len > 0) {
-            link[len] = '\0';
+            linkpath[len] = '\0';
             fprintf(stderr, "libxl: execing %s: fd %d is open to %s with flags %#x\n",
-                    what, i, link, flags);
+                    what, i, linkpath, flags);
         } else
 #endif
             fprintf(stderr, "libxl: execing %s: fd %d is open with flags %#x\n",
diff -r 0547430886c5 -r 6aacce1d8650 tools/libxl/libxl_json.c
--- a/tools/libxl/libxl_json.c	Fri Sep 14 11:00:40 2012 +0100
+++ b/tools/libxl/libxl_json.c	Fri Sep 14 16:28:59 2012 +0100
@@ -275,7 +275,7 @@ static int json_object_append_to(libxl__
 
 void libxl__json_object_free(libxl__gc *gc, libxl__json_object *obj)
 {
-    int index = 0;
+    int idx = 0;
 
     if (obj == NULL)
         return;
@@ -287,8 +287,8 @@ void libxl__json_object_free(libxl__gc *
     case JSON_MAP: {
         libxl__json_map_node *node = NULL;
 
-        for (index = 0; index < obj->u.map->count; index++) {
-            if (flexarray_get(obj->u.map, index, (void**)&node) != 0)
+        for (idx = 0; idx < obj->u.map->count; idx++) {
+            if (flexarray_get(obj->u.map, idx, (void**)&node) != 0)
                 break;
             libxl__json_object_free(gc, node->obj);
             free(node->map_key);
@@ -302,8 +302,8 @@ void libxl__json_object_free(libxl__gc *
         libxl__json_object *node = NULL;
         break;
 
-        for (index = 0; index < obj->u.array->count; index++) {
-            if (flexarray_get(obj->u.array, index, (void**)&node) != 0)
+        for (idx = 0; idx < obj->u.array->count; idx++) {
+            if (flexarray_get(obj->u.array, idx, (void**)&node) != 0)
                 break;
             libxl__json_object_free(gc, node);
             node = NULL;
@@ -359,14 +359,14 @@ const libxl__json_object *libxl__json_ma
                                           libxl__json_node_type expected_type)
 {
     flexarray_t *maps = NULL;
-    int index = 0;
+    int idx = 0;
 
     if (libxl__json_object_is_map(o)) {
         libxl__json_map_node *node = NULL;
 
         maps = o->u.map;
-        for (index = 0; index < maps->count; index++) {
-            if (flexarray_get(maps, index, (void**)&node) != 0)
+        for (idx = 0; idx < maps->count; idx++) {
+            if (flexarray_get(maps, idx, (void**)&node) != 0)
                 return NULL;
             if (strcmp(key, node->map_key) == 0) {
                 if (expected_type == JSON_ANY
diff -r 0547430886c5 -r 6aacce1d8650 tools/libxl/libxl_pci.c
--- a/tools/libxl/libxl_pci.c	Fri Sep 14 11:00:40 2012 +0100
+++ b/tools/libxl/libxl_pci.c	Fri Sep 14 16:28:59 2012 +0100
@@ -167,7 +167,6 @@ static int libxl__device_pci_remove_xens
     char *be_path, *num_devs_path, *num_devs, *xsdev, *tmp, *tmppath;
     int num, i, j;
     xs_transaction_t t;
-    unsigned int domain = 0, bus = 0, dev = 0, func = 0;
 
     be_path = libxl__sprintf(gc, "%s/backend/pci/%d/0", libxl__xs_get_dompath(gc, 0), domid);
     num_devs_path = libxl__sprintf(gc, "%s/num_devs", be_path);
@@ -188,6 +187,7 @@ static int libxl__device_pci_remove_xens
     }
 
     for (i = 0; i < num; i++) {
+        unsigned int domain = 0, bus = 0, dev = 0, func = 0;
         xsdev = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/dev-%d", be_path, i));
         sscanf(xsdev, PCI_BDF, &domain, &bus, &dev, &func);
         if (domain == pcidev->domain && bus == pcidev->bus &&
diff -r 0547430886c5 -r 6aacce1d8650 tools/libxl/libxl_qmp.c
--- a/tools/libxl/libxl_qmp.c	Fri Sep 14 11:00:40 2012 +0100
+++ b/tools/libxl/libxl_qmp.c	Fri Sep 14 16:28:59 2012 +0100
@@ -171,7 +171,7 @@ static int qmp_register_vnc_callback(lib
 {
     GC_INIT(qmp->ctx);
     const libxl__json_object *obj;
-    const char *listen, *port;
+    const char *addr, *port;
     int rc = -1;
 
     if (!libxl__json_object_is_map(o)) {
@@ -184,17 +184,17 @@ static int qmp_register_vnc_callback(lib
     }
 
     obj = libxl__json_map_get("host", o, JSON_STRING);
-    listen = libxl__json_object_get_string(obj);
+    addr = libxl__json_object_get_string(obj);
     obj = libxl__json_map_get("service", o, JSON_STRING);
     port = libxl__json_object_get_string(obj);
 
-    if (!listen || !port) {
+    if (!addr || !port) {
         LIBXL__LOG(qmp->ctx, LIBXL__LOG_ERROR,
                    "Failed to retreive VNC connect information.");
         goto out;
     }
 
-    rc = qmp_write_domain_console_item(gc, qmp->domid, "vnc-listen", listen);
+    rc = qmp_write_domain_console_item(gc, qmp->domid, "vnc-listen", addr);
     if (!rc)
         rc = qmp_write_domain_console_item(gc, qmp->domid, "vnc-port", port);
 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 14 15:36:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 15:36: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 1TCXvv-0003hR-Fw; Fri, 14 Sep 2012 15:35:55 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <adrian.adams00@gmail.com>) id 1TCXvu-0003hF-KF
	for xen-devel@lists.xen.org; Fri, 14 Sep 2012 15:35:54 +0000
Received: from [85.158.139.83:17542] by server-11.bemta-5.messagelabs.com id
	45/01-24658-9DE43505; Fri, 14 Sep 2012 15:35:53 +0000
X-Env-Sender: adrian.adams00@gmail.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1347636951!30379011!1
X-Originating-IP: [209.85.219.45]
X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_50_60,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,USERPASS,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10453 invoked from network); 14 Sep 2012 15:35:52 -0000
Received: from mail-oa0-f45.google.com (HELO mail-oa0-f45.google.com)
	(209.85.219.45)
	by server-12.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Sep 2012 15:35:52 -0000
Received: by oagn12 with SMTP id n12so3670218oag.32
	for <xen-devel@lists.xen.org>; Fri, 14 Sep 2012 08:35: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=uiHaKFV3DLxzDS4LwjCS/bIur7WcEtpmL+zZAopOAN4=;
	b=SUJwU8qfo57h6gQV80kovW3lT/KjyHJKRCtbf7xCs/hsM/iYF6Di8b5jo4rM7oV4l2
	dk6rMsNpMEzgTfxqQUcp5umAk8R32nUqn2ccnG31lpprdLTuEopuBi+U48Glf+YZbt0f
	uxCnxgthD54nrdi94RGOiP9fYyOhx+E4sLpG7ccV3N/B52z1/SveBovCo5N20ZjBgJCD
	sh4TbxA6SsKVkbQak5RSdsPRZCGKHI0TeJ+ek1FJ4rQp1CS4A+60Hd0jbrjyeSvMpeaB
	Mnt++oee9dkJfKem4dqK2OGs07DVt0QYBcJ+DtBcU0PaipmGs+XHtO9LgJsKKY+7Wx7v
	csFg==
MIME-Version: 1.0
Received: by 10.182.45.42 with SMTP id j10mr3797147obm.60.1347636950556; Fri,
	14 Sep 2012 08:35:50 -0700 (PDT)
Received: by 10.76.11.70 with HTTP; Fri, 14 Sep 2012 08:35:50 -0700 (PDT)
In-Reply-To: <CC788BF7.3EBE7%keir.xen@gmail.com>
References: <CAMJZU375dEqgWtSGWsRn7o_UG1QChgVZRp7fQFLatkg96c_uzQ@mail.gmail.com>
	<CC788BF7.3EBE7%keir.xen@gmail.com>
Date: Fri, 14 Sep 2012 07:35:50 -0800
Message-ID: <CAMJZU34JBh3be73QF_K9EUREiqiBA6ehOhA4Qj9nfVv7=Ouqiw@mail.gmail.com>
From: adrian adams <adrian.adams00@gmail.com>
To: Keir Fraser <keir.xen@gmail.com>
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] System reboots while installing a guest Windows
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============7407221842177079171=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============7407221842177079171==
Content-Type: multipart/alternative; boundary=f46d044472b5b95e0204c9ab2d73

--f46d044472b5b95e0204c9ab2d73
Content-Type: text/plain; charset=ISO-8859-1

I need to use ether http://ether.gtisc.gatech.edu/source.html
I used debian Lenny and the same kernel version in the link.

Thank you,
-Adrian
On Friday, September 14, 2012, Keir Fraser wrote:

>  Are you really using Xen 3.1.0. You should upgrade to a newer version if
> so.
>
>
> On 14/09/2012 02:26, "adrian adams" <adrian.adams00@gmail.com> wrote:
>
> Hi,
>
> For doing a project, I am using xen (version 3.1.0) from source code.
> When I want to install the guest system (using i.e. xm create w2k3.hvm), my
> whole system reboots and nothing else happens. I do not know how to find
> out what is wrong with my xen installation.
>
> I will appreciate if some one helps me to solve this problem.
>
> Thank you,
> -Adrian
>
> ------------------------------
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
>
>

--f46d044472b5b95e0204c9ab2d73
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

I need to use ether=A0<a href=3D"http://ether.gtisc.gatech.edu/source.html"=
>http://ether.gtisc.gatech.edu/source.html</a><div>I used debian Lenny and =
the same kernel version in the link.<br><div><div><br></div><div>Thank you,=
</div>
<div>-Adrian<span></span><br>On Friday, September 14, 2012, Keir Fraser  wr=
ote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border=
-left:1px #ccc solid;padding-left:1ex">



<div>
<font face=3D"Calibri, Verdana, Helvetica, Arial"><span style=3D"font-size:=
11pt">Are you really using Xen 3.1.0. You should upgrade to a newer version=
 if so.<br>
<br>
<br>
On 14/09/2012 02:26, &quot;adrian adams&quot; &lt;<a href=3D"http://adrian.=
adams00@gmail.com" target=3D"_blank">adrian.adams00@gmail.com</a>&gt; wrote=
:<br>
<br>
</span></font><blockquote><font face=3D"Calibri, Verdana, Helvetica, Arial"=
><span style=3D"font-size:11pt">Hi,<br>
<br>
For doing a project, I am using xen </span></font><span style=3D"font-size:=
11pt"><font face=3D"Arial">(version 3.1.0) from source code. When I want to=
 install the guest system (using i.e.=A0xm create w2k3.hvm), my whole syste=
m reboots and nothing else happens. I do not know how to find out what is w=
rong with my xen installation.<br>

<br>
I will appreciate if some one helps me to solve this problem.<br>
<br>
Thank you,<br>
-Adrian<br>
</font><font face=3D"Calibri, Verdana, Helvetica, Arial"><br>
<hr align=3D"CENTER" size=3D"3" width=3D"95%"></font></span><font><font fac=
e=3D"Consolas, Courier New, Courier"><span style=3D"font-size:10pt">_______=
________________________________________<br>
Xen-devel mailing list<br>
<a href=3D"http://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>
</span></font></font></blockquote>
</div>


</blockquote></div></div></div>

--f46d044472b5b95e0204c9ab2d73--


--===============7407221842177079171==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============7407221842177079171==--


From xen-devel-bounces@lists.xen.org Fri Sep 14 15:36:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 15:36: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 1TCXvv-0003hR-Fw; Fri, 14 Sep 2012 15:35:55 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <adrian.adams00@gmail.com>) id 1TCXvu-0003hF-KF
	for xen-devel@lists.xen.org; Fri, 14 Sep 2012 15:35:54 +0000
Received: from [85.158.139.83:17542] by server-11.bemta-5.messagelabs.com id
	45/01-24658-9DE43505; Fri, 14 Sep 2012 15:35:53 +0000
X-Env-Sender: adrian.adams00@gmail.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1347636951!30379011!1
X-Originating-IP: [209.85.219.45]
X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_50_60,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,USERPASS,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10453 invoked from network); 14 Sep 2012 15:35:52 -0000
Received: from mail-oa0-f45.google.com (HELO mail-oa0-f45.google.com)
	(209.85.219.45)
	by server-12.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Sep 2012 15:35:52 -0000
Received: by oagn12 with SMTP id n12so3670218oag.32
	for <xen-devel@lists.xen.org>; Fri, 14 Sep 2012 08:35: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=uiHaKFV3DLxzDS4LwjCS/bIur7WcEtpmL+zZAopOAN4=;
	b=SUJwU8qfo57h6gQV80kovW3lT/KjyHJKRCtbf7xCs/hsM/iYF6Di8b5jo4rM7oV4l2
	dk6rMsNpMEzgTfxqQUcp5umAk8R32nUqn2ccnG31lpprdLTuEopuBi+U48Glf+YZbt0f
	uxCnxgthD54nrdi94RGOiP9fYyOhx+E4sLpG7ccV3N/B52z1/SveBovCo5N20ZjBgJCD
	sh4TbxA6SsKVkbQak5RSdsPRZCGKHI0TeJ+ek1FJ4rQp1CS4A+60Hd0jbrjyeSvMpeaB
	Mnt++oee9dkJfKem4dqK2OGs07DVt0QYBcJ+DtBcU0PaipmGs+XHtO9LgJsKKY+7Wx7v
	csFg==
MIME-Version: 1.0
Received: by 10.182.45.42 with SMTP id j10mr3797147obm.60.1347636950556; Fri,
	14 Sep 2012 08:35:50 -0700 (PDT)
Received: by 10.76.11.70 with HTTP; Fri, 14 Sep 2012 08:35:50 -0700 (PDT)
In-Reply-To: <CC788BF7.3EBE7%keir.xen@gmail.com>
References: <CAMJZU375dEqgWtSGWsRn7o_UG1QChgVZRp7fQFLatkg96c_uzQ@mail.gmail.com>
	<CC788BF7.3EBE7%keir.xen@gmail.com>
Date: Fri, 14 Sep 2012 07:35:50 -0800
Message-ID: <CAMJZU34JBh3be73QF_K9EUREiqiBA6ehOhA4Qj9nfVv7=Ouqiw@mail.gmail.com>
From: adrian adams <adrian.adams00@gmail.com>
To: Keir Fraser <keir.xen@gmail.com>
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] System reboots while installing a guest Windows
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============7407221842177079171=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============7407221842177079171==
Content-Type: multipart/alternative; boundary=f46d044472b5b95e0204c9ab2d73

--f46d044472b5b95e0204c9ab2d73
Content-Type: text/plain; charset=ISO-8859-1

I need to use ether http://ether.gtisc.gatech.edu/source.html
I used debian Lenny and the same kernel version in the link.

Thank you,
-Adrian
On Friday, September 14, 2012, Keir Fraser wrote:

>  Are you really using Xen 3.1.0. You should upgrade to a newer version if
> so.
>
>
> On 14/09/2012 02:26, "adrian adams" <adrian.adams00@gmail.com> wrote:
>
> Hi,
>
> For doing a project, I am using xen (version 3.1.0) from source code.
> When I want to install the guest system (using i.e. xm create w2k3.hvm), my
> whole system reboots and nothing else happens. I do not know how to find
> out what is wrong with my xen installation.
>
> I will appreciate if some one helps me to solve this problem.
>
> Thank you,
> -Adrian
>
> ------------------------------
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
>
>

--f46d044472b5b95e0204c9ab2d73
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

I need to use ether=A0<a href=3D"http://ether.gtisc.gatech.edu/source.html"=
>http://ether.gtisc.gatech.edu/source.html</a><div>I used debian Lenny and =
the same kernel version in the link.<br><div><div><br></div><div>Thank you,=
</div>
<div>-Adrian<span></span><br>On Friday, September 14, 2012, Keir Fraser  wr=
ote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border=
-left:1px #ccc solid;padding-left:1ex">



<div>
<font face=3D"Calibri, Verdana, Helvetica, Arial"><span style=3D"font-size:=
11pt">Are you really using Xen 3.1.0. You should upgrade to a newer version=
 if so.<br>
<br>
<br>
On 14/09/2012 02:26, &quot;adrian adams&quot; &lt;<a href=3D"http://adrian.=
adams00@gmail.com" target=3D"_blank">adrian.adams00@gmail.com</a>&gt; wrote=
:<br>
<br>
</span></font><blockquote><font face=3D"Calibri, Verdana, Helvetica, Arial"=
><span style=3D"font-size:11pt">Hi,<br>
<br>
For doing a project, I am using xen </span></font><span style=3D"font-size:=
11pt"><font face=3D"Arial">(version 3.1.0) from source code. When I want to=
 install the guest system (using i.e.=A0xm create w2k3.hvm), my whole syste=
m reboots and nothing else happens. I do not know how to find out what is w=
rong with my xen installation.<br>

<br>
I will appreciate if some one helps me to solve this problem.<br>
<br>
Thank you,<br>
-Adrian<br>
</font><font face=3D"Calibri, Verdana, Helvetica, Arial"><br>
<hr align=3D"CENTER" size=3D"3" width=3D"95%"></font></span><font><font fac=
e=3D"Consolas, Courier New, Courier"><span style=3D"font-size:10pt">_______=
________________________________________<br>
Xen-devel mailing list<br>
<a href=3D"http://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>
</span></font></font></blockquote>
</div>


</blockquote></div></div></div>

--f46d044472b5b95e0204c9ab2d73--


--===============7407221842177079171==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============7407221842177079171==--


From xen-devel-bounces@lists.xen.org Fri Sep 14 15:41:20 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 15:41:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TCY0x-000439-8I; Fri, 14 Sep 2012 15:41:07 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1TCY0v-000431-Vs
	for xen-devel@lists.xen.org; Fri, 14 Sep 2012 15:41:06 +0000
Received: from [85.158.137.99:39106] by server-10.bemta-3.messagelabs.com id
	9D/BF-10411-11053505; Fri, 14 Sep 2012 15:41:05 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-217.messagelabs.com!1347637264!12913350!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDkyOTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30525 invoked from network); 14 Sep 2012 15:41:04 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Sep 2012 15:41:04 -0000
X-IronPort-AV: E=Sophos;i="4.80,423,1344211200"; d="scan'208";a="14550987"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Sep 2012 15:41:03 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Fri, 14 Sep 2012 16:41: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
	1TCY0t-0000OC-LM; Fri, 14 Sep 2012 15:41:03 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1TCY0t-00072I-HL;
	Fri, 14 Sep 2012 16:41:03 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20563.20495.204901.209605@mariner.uk.xensource.com>
Date: Fri, 14 Sep 2012 16:41:03 +0100
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1347636887.24226.237.camel@zakaz.uk.xensource.com>
References: <58ab3fb73d13e250f334.1347620998@cosworth.uk.xensource.com>
	<20563.16972.124870.221950@mariner.uk.xensource.com>
	<1347636887.24226.237.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] libxl: Enable -Wshadow
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("Re: [PATCH] libxl: Enable -Wshadow"):
> On Fri, 2012-09-14 at 15:42 +0100, Ian Jackson wrote:
> > If we're doing -Wshadow then macros which introduce local variables
> > like this should give them names qualified somehow for the macro.
> 
> Done, v2 below.
> 
> Since I was touching every line I fixed the line length in those macros
> too.

:-).

Thanks,

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 Sep 14 15:41:20 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 15:41:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TCY0x-000439-8I; Fri, 14 Sep 2012 15:41:07 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1TCY0v-000431-Vs
	for xen-devel@lists.xen.org; Fri, 14 Sep 2012 15:41:06 +0000
Received: from [85.158.137.99:39106] by server-10.bemta-3.messagelabs.com id
	9D/BF-10411-11053505; Fri, 14 Sep 2012 15:41:05 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-217.messagelabs.com!1347637264!12913350!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDkyOTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30525 invoked from network); 14 Sep 2012 15:41:04 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Sep 2012 15:41:04 -0000
X-IronPort-AV: E=Sophos;i="4.80,423,1344211200"; d="scan'208";a="14550987"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Sep 2012 15:41:03 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Fri, 14 Sep 2012 16:41: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
	1TCY0t-0000OC-LM; Fri, 14 Sep 2012 15:41:03 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1TCY0t-00072I-HL;
	Fri, 14 Sep 2012 16:41:03 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20563.20495.204901.209605@mariner.uk.xensource.com>
Date: Fri, 14 Sep 2012 16:41:03 +0100
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1347636887.24226.237.camel@zakaz.uk.xensource.com>
References: <58ab3fb73d13e250f334.1347620998@cosworth.uk.xensource.com>
	<20563.16972.124870.221950@mariner.uk.xensource.com>
	<1347636887.24226.237.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] libxl: Enable -Wshadow
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("Re: [PATCH] libxl: Enable -Wshadow"):
> On Fri, 2012-09-14 at 15:42 +0100, Ian Jackson wrote:
> > If we're doing -Wshadow then macros which introduce local variables
> > like this should give them names qualified somehow for the macro.
> 
> Done, v2 below.
> 
> Since I was touching every line I fixed the line length in those macros
> too.

:-).

Thanks,

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 Sep 14 15:41:29 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 15:41: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 1TCY15-00043r-LY; Fri, 14 Sep 2012 15:41: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 1TCY14-00043g-8S
	for xen-devel@lists.xen.org; Fri, 14 Sep 2012 15:41:14 +0000
Received: from [85.158.138.51:40228] by server-7.bemta-3.messagelabs.com id
	6A/AE-32000-91053505; Fri, 14 Sep 2012 15:41:13 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1347637272!30569660!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDkyOTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5303 invoked from network); 14 Sep 2012 15:41:12 -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;
	14 Sep 2012 15:41:12 -0000
X-IronPort-AV: E=Sophos;i="4.80,423,1344211200"; d="scan'208";a="14550993"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Sep 2012 15:41:12 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Fri, 14 Sep 2012 16:41: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
	1TCY12-0000OO-4i; Fri, 14 Sep 2012 15:41:12 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1TCY12-00072S-11;
	Fri, 14 Sep 2012 16:41:12 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20563.20503.933248.679465@mariner.uk.xensource.com>
Date: Fri, 14 Sep 2012 16:41:11 +0100
To: Ian Campbell <ian.campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <844e10487b91fb4dcb9c.1346932946@cosworth.uk.xensource.com>
References: <844e10487b91fb4dcb9c.1346932946@cosworth.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Ian.Jackson@citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] xl: free libxl context,
 logger and lockfile using atexit handler
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("[Xen-devel] [PATCH] xl: free libxl context, logger and lockfile using atexit handler"):
> xl: free libxl context, logger and lockfile using atexit handler

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 Sep 14 15:41:29 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 15:41: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 1TCY15-00043r-LY; Fri, 14 Sep 2012 15:41: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 1TCY14-00043g-8S
	for xen-devel@lists.xen.org; Fri, 14 Sep 2012 15:41:14 +0000
Received: from [85.158.138.51:40228] by server-7.bemta-3.messagelabs.com id
	6A/AE-32000-91053505; Fri, 14 Sep 2012 15:41:13 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1347637272!30569660!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDkyOTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5303 invoked from network); 14 Sep 2012 15:41:12 -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;
	14 Sep 2012 15:41:12 -0000
X-IronPort-AV: E=Sophos;i="4.80,423,1344211200"; d="scan'208";a="14550993"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Sep 2012 15:41:12 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Fri, 14 Sep 2012 16:41: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
	1TCY12-0000OO-4i; Fri, 14 Sep 2012 15:41:12 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1TCY12-00072S-11;
	Fri, 14 Sep 2012 16:41:12 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20563.20503.933248.679465@mariner.uk.xensource.com>
Date: Fri, 14 Sep 2012 16:41:11 +0100
To: Ian Campbell <ian.campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <844e10487b91fb4dcb9c.1346932946@cosworth.uk.xensource.com>
References: <844e10487b91fb4dcb9c.1346932946@cosworth.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Ian.Jackson@citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] xl: free libxl context,
 logger and lockfile using atexit handler
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("[Xen-devel] [PATCH] xl: free libxl context, logger and lockfile using atexit handler"):
> xl: free libxl context, logger and lockfile using atexit handler

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 Sep 14 15:45:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 15: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 1TCY4s-0004Ip-Ab; Fri, 14 Sep 2012 15:45:10 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1TCY4q-0004Ig-UK
	for xen-devel@lists.xensource.com; Fri, 14 Sep 2012 15:45:09 +0000
Received: from [85.158.143.35:54286] by server-2.bemta-4.messagelabs.com id
	99/05-21239-40153505; Fri, 14 Sep 2012 15:45:08 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1347637506!13708711!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDkyOTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16735 invoked from network); 14 Sep 2012 15:45:06 -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;
	14 Sep 2012 15:45:06 -0000
X-IronPort-AV: E=Sophos;i="4.80,423,1344211200"; d="scan'208";a="14551048"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Sep 2012 15:45:05 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Fri, 14 Sep 2012 16:45:05 +0100
Date: Fri, 14 Sep 2012 16:44: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: <50535AFA020000780009B7C4@nat28.tlf.novell.com>
Message-ID: <alpine.DEB.2.02.1209141631200.29232@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1208221159560.15568@kaball.uk.xensource.com>
	<1345633688-31684-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<1347627587.24226.192.camel@zakaz.uk.xensource.com>
	<1347628660.24226.197.camel@zakaz.uk.xensource.com>
	<1347630442.24226.211.camel@zakaz.uk.xensource.com>
	<1347630971.24226.214.camel@zakaz.uk.xensource.com>
	<50535AFA020000780009B7C4@nat28.tlf.novell.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Tim \(Xen.org\)" <tim@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v4 1/6] xen: improve changes to
 xen_add_to_physmap
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 14 Sep 2012, Jan Beulich wrote:
> >>> On 14.09.12 at 15:56, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> >> > > Might we prefer to have a batched version of this call? I don't think
> >> > > we can shoehorn the necessary fields into xen_add_to_physmap_t though.
> >> > 
> >> > Actually, talking about this we Stefano we think we can. Since both idx
> >> > and gpfn are unsigned longs they can become unions with a GUEST_HANDLE
> >> > without changing the ABI on x86_32 or x86_64.
> > 
> > Except we need both foreign_domid and size, which currently overlap, and
> > there's no other spare bits. Damn.
> > 
> > Looks like XENMEM_add_to_physmap_range is the only option :-(
> 
> You could use the first entry in each array to specify the counts,
> which would at once allow mixed granularity on each list (should
> that ever turn out useful); initially you would certainly want both
> counts to match.

I think it would be better from the interface point of view to have idx
become the number of frames, and gpfn a pointer (a GUEST_HANDLE) to a
struct that contains both arrays.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 14 15:45:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 15: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 1TCY4s-0004Ip-Ab; Fri, 14 Sep 2012 15:45:10 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1TCY4q-0004Ig-UK
	for xen-devel@lists.xensource.com; Fri, 14 Sep 2012 15:45:09 +0000
Received: from [85.158.143.35:54286] by server-2.bemta-4.messagelabs.com id
	99/05-21239-40153505; Fri, 14 Sep 2012 15:45:08 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1347637506!13708711!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDkyOTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16735 invoked from network); 14 Sep 2012 15:45:06 -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;
	14 Sep 2012 15:45:06 -0000
X-IronPort-AV: E=Sophos;i="4.80,423,1344211200"; d="scan'208";a="14551048"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Sep 2012 15:45:05 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Fri, 14 Sep 2012 16:45:05 +0100
Date: Fri, 14 Sep 2012 16:44: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: <50535AFA020000780009B7C4@nat28.tlf.novell.com>
Message-ID: <alpine.DEB.2.02.1209141631200.29232@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1208221159560.15568@kaball.uk.xensource.com>
	<1345633688-31684-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<1347627587.24226.192.camel@zakaz.uk.xensource.com>
	<1347628660.24226.197.camel@zakaz.uk.xensource.com>
	<1347630442.24226.211.camel@zakaz.uk.xensource.com>
	<1347630971.24226.214.camel@zakaz.uk.xensource.com>
	<50535AFA020000780009B7C4@nat28.tlf.novell.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Tim \(Xen.org\)" <tim@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v4 1/6] xen: improve changes to
 xen_add_to_physmap
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 14 Sep 2012, Jan Beulich wrote:
> >>> On 14.09.12 at 15:56, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> >> > > Might we prefer to have a batched version of this call? I don't think
> >> > > we can shoehorn the necessary fields into xen_add_to_physmap_t though.
> >> > 
> >> > Actually, talking about this we Stefano we think we can. Since both idx
> >> > and gpfn are unsigned longs they can become unions with a GUEST_HANDLE
> >> > without changing the ABI on x86_32 or x86_64.
> > 
> > Except we need both foreign_domid and size, which currently overlap, and
> > there's no other spare bits. Damn.
> > 
> > Looks like XENMEM_add_to_physmap_range is the only option :-(
> 
> You could use the first entry in each array to specify the counts,
> which would at once allow mixed granularity on each list (should
> that ever turn out useful); initially you would certainly want both
> counts to match.

I think it would be better from the interface point of view to have idx
become the number of frames, and gpfn a pointer (a GUEST_HANDLE) to a
struct that contains both arrays.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 14 15:49:58 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 15:49:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TCY9H-0004Tm-1X; Fri, 14 Sep 2012 15:49: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 1TCY9F-0004Th-KL
	for xen-devel@lists.xen.org; Fri, 14 Sep 2012 15:49:41 +0000
Received: from [85.158.143.35:12645] by server-1.bemta-4.messagelabs.com id
	1E/E1-12504-51253505; Fri, 14 Sep 2012 15:49:41 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1347637780!12476557!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDkyOTU=\n,
	ML_RADAR_SPEW_LINKS_9, spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19060 invoked from network); 14 Sep 2012 15:49:40 -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 Sep 2012 15:49:40 -0000
X-IronPort-AV: E=Sophos;i="4.80,423,1344211200"; d="scan'208";a="14551159"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Sep 2012 15:49: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.279.1;
	Fri, 14 Sep 2012 16:49:40 +0100
Message-ID: <1347637778.14977.7.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: adrian adams <adrian.adams00@gmail.com>
Date: Fri, 14 Sep 2012 16:49:38 +0100
In-Reply-To: <CAMJZU34JBh3be73QF_K9EUREiqiBA6ehOhA4Qj9nfVv7=Ouqiw@mail.gmail.com>
References: <CAMJZU375dEqgWtSGWsRn7o_UG1QChgVZRp7fQFLatkg96c_uzQ@mail.gmail.com>
	<CC788BF7.3EBE7%keir.xen@gmail.com>
	<CAMJZU34JBh3be73QF_K9EUREiqiBA6ehOhA4Qj9nfVv7=Ouqiw@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Keir Fraser <keir.xen@gmail.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] System reboots while installing a guest Windows
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Please don't top post.

On Fri, 2012-09-14 at 16:35 +0100, adrian adams wrote:
> I need to use ether http://ether.gtisc.gatech.edu/source.html
> I used debian Lenny and the same kernel version in the link.

I think if ether is going to require such an ancient version of Xen then
it is only fair that they pickup the burden of supporting their users.

http://ether.gtisc.gatech.edu/contact.html suggests that
http://groups.google.com/group/ether-devel is the place to go.

I don't think it is reasonable to expect the Xen.org community to
support old releases indefinitely. Sorry.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 14 15:49:58 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 15:49:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TCY9H-0004Tm-1X; Fri, 14 Sep 2012 15:49: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 1TCY9F-0004Th-KL
	for xen-devel@lists.xen.org; Fri, 14 Sep 2012 15:49:41 +0000
Received: from [85.158.143.35:12645] by server-1.bemta-4.messagelabs.com id
	1E/E1-12504-51253505; Fri, 14 Sep 2012 15:49:41 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1347637780!12476557!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDkyOTU=\n,
	ML_RADAR_SPEW_LINKS_9, spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19060 invoked from network); 14 Sep 2012 15:49:40 -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 Sep 2012 15:49:40 -0000
X-IronPort-AV: E=Sophos;i="4.80,423,1344211200"; d="scan'208";a="14551159"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Sep 2012 15:49: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.279.1;
	Fri, 14 Sep 2012 16:49:40 +0100
Message-ID: <1347637778.14977.7.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: adrian adams <adrian.adams00@gmail.com>
Date: Fri, 14 Sep 2012 16:49:38 +0100
In-Reply-To: <CAMJZU34JBh3be73QF_K9EUREiqiBA6ehOhA4Qj9nfVv7=Ouqiw@mail.gmail.com>
References: <CAMJZU375dEqgWtSGWsRn7o_UG1QChgVZRp7fQFLatkg96c_uzQ@mail.gmail.com>
	<CC788BF7.3EBE7%keir.xen@gmail.com>
	<CAMJZU34JBh3be73QF_K9EUREiqiBA6ehOhA4Qj9nfVv7=Ouqiw@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Keir Fraser <keir.xen@gmail.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] System reboots while installing a guest Windows
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Please don't top post.

On Fri, 2012-09-14 at 16:35 +0100, adrian adams wrote:
> I need to use ether http://ether.gtisc.gatech.edu/source.html
> I used debian Lenny and the same kernel version in the link.

I think if ether is going to require such an ancient version of Xen then
it is only fair that they pickup the burden of supporting their users.

http://ether.gtisc.gatech.edu/contact.html suggests that
http://groups.google.com/group/ether-devel is the place to go.

I don't think it is reasonable to expect the Xen.org community to
support old releases indefinitely. Sorry.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 14 15:52:56 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 15:52:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TCYC8-0004bF-KZ; Fri, 14 Sep 2012 15:52:40 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1TCYC6-0004az-HW
	for xen-devel@lists.xensource.com; Fri, 14 Sep 2012 15:52:38 +0000
Received: from [85.158.139.211:49230] by server-3.bemta-5.messagelabs.com id
	7A/D2-21836-5C253505; Fri, 14 Sep 2012 15:52:37 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-206.messagelabs.com!1347637956!18550826!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDkyOTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24323 invoked from network); 14 Sep 2012 15:52:36 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Sep 2012 15:52:36 -0000
X-IronPort-AV: E=Sophos;i="4.80,423,1344211200"; d="scan'208";a="14551196"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Sep 2012 15:52: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.279.1;
	Fri, 14 Sep 2012 16:52:35 +0100
Message-ID: <1347637953.14977.10.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Date: Fri, 14 Sep 2012 16:52:33 +0100
In-Reply-To: <alpine.DEB.2.02.1209141631200.29232@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1208221159560.15568@kaball.uk.xensource.com>
	<1345633688-31684-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<1347627587.24226.192.camel@zakaz.uk.xensource.com>
	<1347628660.24226.197.camel@zakaz.uk.xensource.com>
	<1347630442.24226.211.camel@zakaz.uk.xensource.com>
	<1347630971.24226.214.camel@zakaz.uk.xensource.com>
	<50535AFA020000780009B7C4@nat28.tlf.novell.com>
	<alpine.DEB.2.02.1209141631200.29232@kaball.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, Keir
	Fraser <keir@xen.org>, "Tim \(Xen.org\)" <tim@xen.org>,
	ijackson@chiark.greenend.org.uk, Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH v4 1/6] xen: improve changes to
 xen_add_to_physmap
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-09-14 at 16:44 +0100, Stefano Stabellini wrote:
> On Fri, 14 Sep 2012, Jan Beulich wrote:
> > >>> On 14.09.12 at 15:56, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> > >> > > Might we prefer to have a batched version of this call? I don't think
> > >> > > we can shoehorn the necessary fields into xen_add_to_physmap_t though.
> > >> > 
> > >> > Actually, talking about this we Stefano we think we can. Since both idx
> > >> > and gpfn are unsigned longs they can become unions with a GUEST_HANDLE
> > >> > without changing the ABI on x86_32 or x86_64.
> > > 
> > > Except we need both foreign_domid and size, which currently overlap, and
> > > there's no other spare bits. Damn.
> > > 
> > > Looks like XENMEM_add_to_physmap_range is the only option :-(
> > 
> > You could use the first entry in each array to specify the counts,
> > which would at once allow mixed granularity on each list (should
> > that ever turn out useful); initially you would certainly want both
> > counts to match.
> 
> I think it would be better from the interface point of view to have idx
> become the number of frames, and gpfn a pointer (a GUEST_HANDLE) to a
> struct that contains both arrays.

We'd need to slip in enough info to allow continuations too. Perhaps
that can be done by manipulating the size and the handle to keep track
of progress. Or maybe we can get away with just just frobbing the size
if we process the array backwards.

Which is all sounding pretty gross. I'm very temped to add
add_to_physmap2...

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 14 15:52:56 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 15:52:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TCYC8-0004bF-KZ; Fri, 14 Sep 2012 15:52:40 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1TCYC6-0004az-HW
	for xen-devel@lists.xensource.com; Fri, 14 Sep 2012 15:52:38 +0000
Received: from [85.158.139.211:49230] by server-3.bemta-5.messagelabs.com id
	7A/D2-21836-5C253505; Fri, 14 Sep 2012 15:52:37 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-206.messagelabs.com!1347637956!18550826!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDkyOTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24323 invoked from network); 14 Sep 2012 15:52:36 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Sep 2012 15:52:36 -0000
X-IronPort-AV: E=Sophos;i="4.80,423,1344211200"; d="scan'208";a="14551196"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Sep 2012 15:52: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.279.1;
	Fri, 14 Sep 2012 16:52:35 +0100
Message-ID: <1347637953.14977.10.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Date: Fri, 14 Sep 2012 16:52:33 +0100
In-Reply-To: <alpine.DEB.2.02.1209141631200.29232@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1208221159560.15568@kaball.uk.xensource.com>
	<1345633688-31684-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<1347627587.24226.192.camel@zakaz.uk.xensource.com>
	<1347628660.24226.197.camel@zakaz.uk.xensource.com>
	<1347630442.24226.211.camel@zakaz.uk.xensource.com>
	<1347630971.24226.214.camel@zakaz.uk.xensource.com>
	<50535AFA020000780009B7C4@nat28.tlf.novell.com>
	<alpine.DEB.2.02.1209141631200.29232@kaball.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, Keir
	Fraser <keir@xen.org>, "Tim \(Xen.org\)" <tim@xen.org>,
	ijackson@chiark.greenend.org.uk, Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH v4 1/6] xen: improve changes to
 xen_add_to_physmap
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-09-14 at 16:44 +0100, Stefano Stabellini wrote:
> On Fri, 14 Sep 2012, Jan Beulich wrote:
> > >>> On 14.09.12 at 15:56, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> > >> > > Might we prefer to have a batched version of this call? I don't think
> > >> > > we can shoehorn the necessary fields into xen_add_to_physmap_t though.
> > >> > 
> > >> > Actually, talking about this we Stefano we think we can. Since both idx
> > >> > and gpfn are unsigned longs they can become unions with a GUEST_HANDLE
> > >> > without changing the ABI on x86_32 or x86_64.
> > > 
> > > Except we need both foreign_domid and size, which currently overlap, and
> > > there's no other spare bits. Damn.
> > > 
> > > Looks like XENMEM_add_to_physmap_range is the only option :-(
> > 
> > You could use the first entry in each array to specify the counts,
> > which would at once allow mixed granularity on each list (should
> > that ever turn out useful); initially you would certainly want both
> > counts to match.
> 
> I think it would be better from the interface point of view to have idx
> become the number of frames, and gpfn a pointer (a GUEST_HANDLE) to a
> struct that contains both arrays.

We'd need to slip in enough info to allow continuations too. Perhaps
that can be done by manipulating the size and the handle to keep track
of progress. Or maybe we can get away with just just frobbing the size
if we process the array backwards.

Which is all sounding pretty gross. I'm very temped to add
add_to_physmap2...

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 14 15:55:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 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 1TCYEG-0004k1-5k; Fri, 14 Sep 2012 15:54: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 1TCYEE-0004jp-Lo
	for xen-devel@lists.xensource.com; Fri, 14 Sep 2012 15:54:50 +0000
Received: from [85.158.143.99:18121] by server-3.bemta-4.messagelabs.com id
	FB/B5-08232-94353505; Fri, 14 Sep 2012 15:54:49 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1347638089!22196856!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDkyOTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18642 invoked from network); 14 Sep 2012 15:54:49 -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;
	14 Sep 2012 15:54:49 -0000
X-IronPort-AV: E=Sophos;i="4.80,423,1344211200"; d="scan'208";a="14551236"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Sep 2012 15:54: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.279.1; Fri, 14 Sep 2012 16:54:49 +0100
Date: Fri, 14 Sep 2012 16:54:06 +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: <1347637953.14977.10.camel@zakaz.uk.xensource.com>
Message-ID: <alpine.DEB.2.02.1209141652440.29232@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1208221159560.15568@kaball.uk.xensource.com>
	<1345633688-31684-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<1347627587.24226.192.camel@zakaz.uk.xensource.com>
	<1347628660.24226.197.camel@zakaz.uk.xensource.com> 
	<1347630442.24226.211.camel@zakaz.uk.xensource.com>
	<1347630971.24226.214.camel@zakaz.uk.xensource.com>
	<50535AFA020000780009B7C4@nat28.tlf.novell.com>
	<alpine.DEB.2.02.1209141631200.29232@kaball.uk.xensource.com>
	<1347637953.14977.10.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>,
	"Keir \(Xen.org\)" <keir@xen.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"Tim \(Xen.org\)" <tim@xen.org>,
	"ijackson@chiark.greenend.org.uk" <ijackson@chiark.greenend.org.uk>,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH v4 1/6] xen: improve changes to
 xen_add_to_physmap
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 14 Sep 2012, Ian Campbell wrote:
> On Fri, 2012-09-14 at 16:44 +0100, Stefano Stabellini wrote:
> > On Fri, 14 Sep 2012, Jan Beulich wrote:
> > > >>> On 14.09.12 at 15:56, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> > > >> > > Might we prefer to have a batched version of this call? I don't think
> > > >> > > we can shoehorn the necessary fields into xen_add_to_physmap_t though.
> > > >> > 
> > > >> > Actually, talking about this we Stefano we think we can. Since both idx
> > > >> > and gpfn are unsigned longs they can become unions with a GUEST_HANDLE
> > > >> > without changing the ABI on x86_32 or x86_64.
> > > > 
> > > > Except we need both foreign_domid and size, which currently overlap, and
> > > > there's no other spare bits. Damn.
> > > > 
> > > > Looks like XENMEM_add_to_physmap_range is the only option :-(
> > > 
> > > You could use the first entry in each array to specify the counts,
> > > which would at once allow mixed granularity on each list (should
> > > that ever turn out useful); initially you would certainly want both
> > > counts to match.
> > 
> > I think it would be better from the interface point of view to have idx
> > become the number of frames, and gpfn a pointer (a GUEST_HANDLE) to a
> > struct that contains both arrays.
> 
> We'd need to slip in enough info to allow continuations too. Perhaps
> that can be done by manipulating the size and the handle to keep track
> of progress. Or maybe we can get away with just just frobbing the size
> if we process the array backwards.
> 
> Which is all sounding pretty gross. I'm very temped to add
> add_to_physmap2...

Yeah, I am 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 Fri Sep 14 15:55:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 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 1TCYEG-0004k1-5k; Fri, 14 Sep 2012 15:54: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 1TCYEE-0004jp-Lo
	for xen-devel@lists.xensource.com; Fri, 14 Sep 2012 15:54:50 +0000
Received: from [85.158.143.99:18121] by server-3.bemta-4.messagelabs.com id
	FB/B5-08232-94353505; Fri, 14 Sep 2012 15:54:49 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1347638089!22196856!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDkyOTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18642 invoked from network); 14 Sep 2012 15:54:49 -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;
	14 Sep 2012 15:54:49 -0000
X-IronPort-AV: E=Sophos;i="4.80,423,1344211200"; d="scan'208";a="14551236"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Sep 2012 15:54: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.279.1; Fri, 14 Sep 2012 16:54:49 +0100
Date: Fri, 14 Sep 2012 16:54:06 +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: <1347637953.14977.10.camel@zakaz.uk.xensource.com>
Message-ID: <alpine.DEB.2.02.1209141652440.29232@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1208221159560.15568@kaball.uk.xensource.com>
	<1345633688-31684-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<1347627587.24226.192.camel@zakaz.uk.xensource.com>
	<1347628660.24226.197.camel@zakaz.uk.xensource.com> 
	<1347630442.24226.211.camel@zakaz.uk.xensource.com>
	<1347630971.24226.214.camel@zakaz.uk.xensource.com>
	<50535AFA020000780009B7C4@nat28.tlf.novell.com>
	<alpine.DEB.2.02.1209141631200.29232@kaball.uk.xensource.com>
	<1347637953.14977.10.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>,
	"Keir \(Xen.org\)" <keir@xen.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"Tim \(Xen.org\)" <tim@xen.org>,
	"ijackson@chiark.greenend.org.uk" <ijackson@chiark.greenend.org.uk>,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH v4 1/6] xen: improve changes to
 xen_add_to_physmap
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 14 Sep 2012, Ian Campbell wrote:
> On Fri, 2012-09-14 at 16:44 +0100, Stefano Stabellini wrote:
> > On Fri, 14 Sep 2012, Jan Beulich wrote:
> > > >>> On 14.09.12 at 15:56, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> > > >> > > Might we prefer to have a batched version of this call? I don't think
> > > >> > > we can shoehorn the necessary fields into xen_add_to_physmap_t though.
> > > >> > 
> > > >> > Actually, talking about this we Stefano we think we can. Since both idx
> > > >> > and gpfn are unsigned longs they can become unions with a GUEST_HANDLE
> > > >> > without changing the ABI on x86_32 or x86_64.
> > > > 
> > > > Except we need both foreign_domid and size, which currently overlap, and
> > > > there's no other spare bits. Damn.
> > > > 
> > > > Looks like XENMEM_add_to_physmap_range is the only option :-(
> > > 
> > > You could use the first entry in each array to specify the counts,
> > > which would at once allow mixed granularity on each list (should
> > > that ever turn out useful); initially you would certainly want both
> > > counts to match.
> > 
> > I think it would be better from the interface point of view to have idx
> > become the number of frames, and gpfn a pointer (a GUEST_HANDLE) to a
> > struct that contains both arrays.
> 
> We'd need to slip in enough info to allow continuations too. Perhaps
> that can be done by manipulating the size and the handle to keep track
> of progress. Or maybe we can get away with just just frobbing the size
> if we process the array backwards.
> 
> Which is all sounding pretty gross. I'm very temped to add
> add_to_physmap2...

Yeah, I am 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 Fri Sep 14 16:01:40 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 16:01:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TCYKb-0005Sa-LC; Fri, 14 Sep 2012 16:01:25 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1TCYKZ-0005SP-Os
	for xen-devel@lists.xensource.com; Fri, 14 Sep 2012 16:01:23 +0000
Received: from [85.158.139.211:55038] by server-12.bemta-5.messagelabs.com id
	5E/55-19338-3D453505; Fri, 14 Sep 2012 16:01:23 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-15.tower-206.messagelabs.com!1347638482!18648630!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDkyOTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28127 invoked from network); 14 Sep 2012 16:01:22 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Sep 2012 16:01:22 -0000
X-IronPort-AV: E=Sophos;i="4.80,423,1344211200"; d="scan'208";a="14551368"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Sep 2012 16:01: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.279.1; Fri, 14 Sep 2012 17:01:22 +0100
Date: Fri, 14 Sep 2012 17:00:39 +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: <1347306367-28669-6-git-send-email-konrad.wilk@oracle.com>
Message-ID: <alpine.DEB.2.02.1209141700320.29232@kaball.uk.xensource.com>
References: <1347306367-28669-1-git-send-email-konrad.wilk@oracle.com>
	<1347306367-28669-6-git-send-email-konrad.wilk@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>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 05/10] xen/swiotlb: Move the error strings
 to its own 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 Mon, 10 Sep 2012, Konrad Rzeszutek Wilk wrote:
> That way we can more easily reuse those errors when using the
> late SWIOTLB init.
> 
> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>


Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>


>  drivers/xen/swiotlb-xen.c |   35 +++++++++++++++++++++++++++--------
>  1 files changed, 27 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
> index a2aad6e..701b103 100644
> --- a/drivers/xen/swiotlb-xen.c
> +++ b/drivers/xen/swiotlb-xen.c
> @@ -154,11 +154,33 @@ static unsigned long xen_set_nslabs(unsigned long nr_tbl)
>  
>  	return xen_io_tlb_nslabs << IO_TLB_SHIFT;
>  }
> +
> +enum xen_swiotlb_err {
> +	XEN_SWIOTLB_UNKNOWN = 0,
> +	XEN_SWIOTLB_ENOMEM,
> +	XEN_SWIOTLB_EFIXUP
> +};
> +
> +static const char *xen_swiotlb_error(enum xen_swiotlb_err err)
> +{
> +	switch (err) {
> +	case XEN_SWIOTLB_ENOMEM:
> +		return "Cannot allocate Xen-SWIOTLB buffer\n";
> +	case XEN_SWIOTLB_EFIXUP:
> +		return "Failed to get contiguous memory for DMA from Xen!\n"\
> +		    "You either: don't have the permissions, do not have"\
> +		    " enough free memory under 4GB, or the hypervisor memory"\
> +		    " is too fragmented!";
> +	default:
> +		break;
> +	}
> +	return "";
> +}
>  void __init xen_swiotlb_init(int verbose)
>  {
>  	unsigned long bytes;
>  	int rc = -ENOMEM;
> -	char *m = NULL;
> +	enum xen_swiotlb_err m_ret = XEN_SWIOTLB_UNKNOWN;
>  	unsigned int repeat = 3;
>  
>  	xen_io_tlb_nslabs = swiotlb_nr_tbl();
> @@ -169,7 +191,7 @@ retry:
>  	 */
>  	xen_io_tlb_start = alloc_bootmem_pages(PAGE_ALIGN(bytes));
>  	if (!xen_io_tlb_start) {
> -		m = "Cannot allocate Xen-SWIOTLB buffer!\n";
> +		m_ret = XEN_SWIOTLB_ENOMEM;
>  		goto error;
>  	}
>  	xen_io_tlb_end = xen_io_tlb_start + bytes;
> @@ -181,10 +203,7 @@ retry:
>  			       xen_io_tlb_nslabs);
>  	if (rc) {
>  		free_bootmem(__pa(xen_io_tlb_start), PAGE_ALIGN(bytes));
> -		m = "Failed to get contiguous memory for DMA from Xen!\n"\
> -		    "You either: don't have the permissions, do not have"\
> -		    " enough free memory under 4GB, or the hypervisor memory"\
> -		    "is too fragmented!";
> +		m_ret = XEN_SWIOTLB_EFIXUP;
>  		goto error;
>  	}
>  	start_dma_addr = xen_virt_to_bus(xen_io_tlb_start);
> @@ -199,8 +218,8 @@ error:
>  		      (xen_io_tlb_nslabs << IO_TLB_SHIFT) >> 20);
>  		goto retry;
>  	}
> -	xen_raw_printk("%s (rc:%d)", m, rc);
> -	panic("%s (rc:%d)", m, rc);
> +	xen_raw_printk("%s (rc:%d)", xen_swiotlb_error(m_ret), rc);
> +	panic("%s (rc:%d)", xen_swiotlb_error(m_ret), rc);
>  }
>  
>  void *
> -- 
> 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 Sep 14 16:01:40 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 16:01:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TCYKb-0005Sa-LC; Fri, 14 Sep 2012 16:01:25 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1TCYKZ-0005SP-Os
	for xen-devel@lists.xensource.com; Fri, 14 Sep 2012 16:01:23 +0000
Received: from [85.158.139.211:55038] by server-12.bemta-5.messagelabs.com id
	5E/55-19338-3D453505; Fri, 14 Sep 2012 16:01:23 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-15.tower-206.messagelabs.com!1347638482!18648630!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDkyOTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28127 invoked from network); 14 Sep 2012 16:01:22 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Sep 2012 16:01:22 -0000
X-IronPort-AV: E=Sophos;i="4.80,423,1344211200"; d="scan'208";a="14551368"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Sep 2012 16:01: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.279.1; Fri, 14 Sep 2012 17:01:22 +0100
Date: Fri, 14 Sep 2012 17:00:39 +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: <1347306367-28669-6-git-send-email-konrad.wilk@oracle.com>
Message-ID: <alpine.DEB.2.02.1209141700320.29232@kaball.uk.xensource.com>
References: <1347306367-28669-1-git-send-email-konrad.wilk@oracle.com>
	<1347306367-28669-6-git-send-email-konrad.wilk@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>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 05/10] xen/swiotlb: Move the error strings
 to its own 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 Mon, 10 Sep 2012, Konrad Rzeszutek Wilk wrote:
> That way we can more easily reuse those errors when using the
> late SWIOTLB init.
> 
> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>


Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>


>  drivers/xen/swiotlb-xen.c |   35 +++++++++++++++++++++++++++--------
>  1 files changed, 27 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
> index a2aad6e..701b103 100644
> --- a/drivers/xen/swiotlb-xen.c
> +++ b/drivers/xen/swiotlb-xen.c
> @@ -154,11 +154,33 @@ static unsigned long xen_set_nslabs(unsigned long nr_tbl)
>  
>  	return xen_io_tlb_nslabs << IO_TLB_SHIFT;
>  }
> +
> +enum xen_swiotlb_err {
> +	XEN_SWIOTLB_UNKNOWN = 0,
> +	XEN_SWIOTLB_ENOMEM,
> +	XEN_SWIOTLB_EFIXUP
> +};
> +
> +static const char *xen_swiotlb_error(enum xen_swiotlb_err err)
> +{
> +	switch (err) {
> +	case XEN_SWIOTLB_ENOMEM:
> +		return "Cannot allocate Xen-SWIOTLB buffer\n";
> +	case XEN_SWIOTLB_EFIXUP:
> +		return "Failed to get contiguous memory for DMA from Xen!\n"\
> +		    "You either: don't have the permissions, do not have"\
> +		    " enough free memory under 4GB, or the hypervisor memory"\
> +		    " is too fragmented!";
> +	default:
> +		break;
> +	}
> +	return "";
> +}
>  void __init xen_swiotlb_init(int verbose)
>  {
>  	unsigned long bytes;
>  	int rc = -ENOMEM;
> -	char *m = NULL;
> +	enum xen_swiotlb_err m_ret = XEN_SWIOTLB_UNKNOWN;
>  	unsigned int repeat = 3;
>  
>  	xen_io_tlb_nslabs = swiotlb_nr_tbl();
> @@ -169,7 +191,7 @@ retry:
>  	 */
>  	xen_io_tlb_start = alloc_bootmem_pages(PAGE_ALIGN(bytes));
>  	if (!xen_io_tlb_start) {
> -		m = "Cannot allocate Xen-SWIOTLB buffer!\n";
> +		m_ret = XEN_SWIOTLB_ENOMEM;
>  		goto error;
>  	}
>  	xen_io_tlb_end = xen_io_tlb_start + bytes;
> @@ -181,10 +203,7 @@ retry:
>  			       xen_io_tlb_nslabs);
>  	if (rc) {
>  		free_bootmem(__pa(xen_io_tlb_start), PAGE_ALIGN(bytes));
> -		m = "Failed to get contiguous memory for DMA from Xen!\n"\
> -		    "You either: don't have the permissions, do not have"\
> -		    " enough free memory under 4GB, or the hypervisor memory"\
> -		    "is too fragmented!";
> +		m_ret = XEN_SWIOTLB_EFIXUP;
>  		goto error;
>  	}
>  	start_dma_addr = xen_virt_to_bus(xen_io_tlb_start);
> @@ -199,8 +218,8 @@ error:
>  		      (xen_io_tlb_nslabs << IO_TLB_SHIFT) >> 20);
>  		goto retry;
>  	}
> -	xen_raw_printk("%s (rc:%d)", m, rc);
> -	panic("%s (rc:%d)", m, rc);
> +	xen_raw_printk("%s (rc:%d)", xen_swiotlb_error(m_ret), rc);
> +	panic("%s (rc:%d)", xen_swiotlb_error(m_ret), rc);
>  }
>  
>  void *
> -- 
> 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 Sep 14 16:07:48 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 16:07:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TCYQZ-0005w3-Je; Fri, 14 Sep 2012 16:07: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 1TCYQY-0005vw-LF
	for xen-devel@lists.xensource.com; Fri, 14 Sep 2012 16:07:34 +0000
Received: from [85.158.143.99:10705] by server-2.bemta-4.messagelabs.com id
	87/41-21239-54653505; Fri, 14 Sep 2012 16:07:33 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1347638853!30384739!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDkyOTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9948 invoked from network); 14 Sep 2012 16:07:33 -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;
	14 Sep 2012 16:07:33 -0000
X-IronPort-AV: E=Sophos;i="4.80,423,1344211200"; d="scan'208";a="14551471"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Sep 2012 16:06: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.279.1; Fri, 14 Sep 2012 17:06:59 +0100
Date: Fri, 14 Sep 2012 17:06:16 +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: <1347306367-28669-9-git-send-email-konrad.wilk@oracle.com>
Message-ID: <alpine.DEB.2.02.1209141704330.29232@kaball.uk.xensource.com>
References: <1347306367-28669-1-git-send-email-konrad.wilk@oracle.com>
	<1347306367-28669-9-git-send-email-konrad.wilk@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>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 08/10] xen/swiotlb: Remove functions not
 needed anymore.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 10 Sep 2012, Konrad Rzeszutek Wilk wrote:
> Sparse warns us off:
> drivers/xen/swiotlb-xen.c:506:1: warning: symbol 'xen_swiotlb_map_sg' was not declared. Should it be static?
> drivers/xen/swiotlb-xen.c:534:1: warning: symbol 'xen_swiotlb_unmap_sg' was not declared. Should it be static?
> 
> and it looks like we do not need this function at all.

A grep seems to find them used in arch/x86/xen/pci-swiotlb-xen.c.
I fail to see where you removed them from pci-swiotlb-xen.c. Is it in
this patch series or another one?


> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> ---
>  drivers/xen/swiotlb-xen.c |   16 ----------------
>  include/xen/swiotlb-xen.h |    9 ---------
>  2 files changed, 0 insertions(+), 25 deletions(-)
> 
> diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
> index f0825cb..6f81994 100644
> --- a/drivers/xen/swiotlb-xen.c
> +++ b/drivers/xen/swiotlb-xen.c
> @@ -514,14 +514,6 @@ xen_swiotlb_map_sg_attrs(struct device *hwdev, struct scatterlist *sgl,
>  }
>  EXPORT_SYMBOL_GPL(xen_swiotlb_map_sg_attrs);
>  
> -int
> -xen_swiotlb_map_sg(struct device *hwdev, struct scatterlist *sgl, int nelems,
> -		   enum dma_data_direction dir)
> -{
> -	return xen_swiotlb_map_sg_attrs(hwdev, sgl, nelems, dir, NULL);
> -}
> -EXPORT_SYMBOL_GPL(xen_swiotlb_map_sg);
> -
>  /*
>   * Unmap a set of streaming mode DMA translations.  Again, cpu read rules
>   * concerning calls here are the same as for swiotlb_unmap_page() above.
> @@ -542,14 +534,6 @@ xen_swiotlb_unmap_sg_attrs(struct device *hwdev, struct scatterlist *sgl,
>  }
>  EXPORT_SYMBOL_GPL(xen_swiotlb_unmap_sg_attrs);
>  
> -void
> -xen_swiotlb_unmap_sg(struct device *hwdev, struct scatterlist *sgl, int nelems,
> -		     enum dma_data_direction dir)
> -{
> -	return xen_swiotlb_unmap_sg_attrs(hwdev, sgl, nelems, dir, NULL);
> -}
> -EXPORT_SYMBOL_GPL(xen_swiotlb_unmap_sg);
> -
>  /*
>   * Make physical memory consistent for a set of streaming mode DMA translations
>   * after a transfer.
> diff --git a/include/xen/swiotlb-xen.h b/include/xen/swiotlb-xen.h
> index f26f9f3..a0db2b7 100644
> --- a/include/xen/swiotlb-xen.h
> +++ b/include/xen/swiotlb-xen.h
> @@ -23,15 +23,6 @@ extern dma_addr_t xen_swiotlb_map_page(struct device *dev, struct page *page,
>  extern void xen_swiotlb_unmap_page(struct device *hwdev, dma_addr_t dev_addr,
>  				   size_t size, enum dma_data_direction dir,
>  				   struct dma_attrs *attrs);
> -/*
> -extern int
> -xen_swiotlb_map_sg(struct device *hwdev, struct scatterlist *sg, int nents,
> -		   enum dma_data_direction dir);
> -
> -extern void
> -xen_swiotlb_unmap_sg(struct device *hwdev, struct scatterlist *sg, int nents,
> -		     enum dma_data_direction dir);
> -*/
>  extern int
>  xen_swiotlb_map_sg_attrs(struct device *hwdev, struct scatterlist *sgl,
>  			 int nelems, enum dma_data_direction dir,
> -- 
> 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 Sep 14 16:07:48 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 16:07:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TCYQZ-0005w3-Je; Fri, 14 Sep 2012 16:07: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 1TCYQY-0005vw-LF
	for xen-devel@lists.xensource.com; Fri, 14 Sep 2012 16:07:34 +0000
Received: from [85.158.143.99:10705] by server-2.bemta-4.messagelabs.com id
	87/41-21239-54653505; Fri, 14 Sep 2012 16:07:33 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1347638853!30384739!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDkyOTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9948 invoked from network); 14 Sep 2012 16:07:33 -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;
	14 Sep 2012 16:07:33 -0000
X-IronPort-AV: E=Sophos;i="4.80,423,1344211200"; d="scan'208";a="14551471"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Sep 2012 16:06: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.279.1; Fri, 14 Sep 2012 17:06:59 +0100
Date: Fri, 14 Sep 2012 17:06:16 +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: <1347306367-28669-9-git-send-email-konrad.wilk@oracle.com>
Message-ID: <alpine.DEB.2.02.1209141704330.29232@kaball.uk.xensource.com>
References: <1347306367-28669-1-git-send-email-konrad.wilk@oracle.com>
	<1347306367-28669-9-git-send-email-konrad.wilk@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>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 08/10] xen/swiotlb: Remove functions not
 needed anymore.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 10 Sep 2012, Konrad Rzeszutek Wilk wrote:
> Sparse warns us off:
> drivers/xen/swiotlb-xen.c:506:1: warning: symbol 'xen_swiotlb_map_sg' was not declared. Should it be static?
> drivers/xen/swiotlb-xen.c:534:1: warning: symbol 'xen_swiotlb_unmap_sg' was not declared. Should it be static?
> 
> and it looks like we do not need this function at all.

A grep seems to find them used in arch/x86/xen/pci-swiotlb-xen.c.
I fail to see where you removed them from pci-swiotlb-xen.c. Is it in
this patch series or another one?


> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> ---
>  drivers/xen/swiotlb-xen.c |   16 ----------------
>  include/xen/swiotlb-xen.h |    9 ---------
>  2 files changed, 0 insertions(+), 25 deletions(-)
> 
> diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
> index f0825cb..6f81994 100644
> --- a/drivers/xen/swiotlb-xen.c
> +++ b/drivers/xen/swiotlb-xen.c
> @@ -514,14 +514,6 @@ xen_swiotlb_map_sg_attrs(struct device *hwdev, struct scatterlist *sgl,
>  }
>  EXPORT_SYMBOL_GPL(xen_swiotlb_map_sg_attrs);
>  
> -int
> -xen_swiotlb_map_sg(struct device *hwdev, struct scatterlist *sgl, int nelems,
> -		   enum dma_data_direction dir)
> -{
> -	return xen_swiotlb_map_sg_attrs(hwdev, sgl, nelems, dir, NULL);
> -}
> -EXPORT_SYMBOL_GPL(xen_swiotlb_map_sg);
> -
>  /*
>   * Unmap a set of streaming mode DMA translations.  Again, cpu read rules
>   * concerning calls here are the same as for swiotlb_unmap_page() above.
> @@ -542,14 +534,6 @@ xen_swiotlb_unmap_sg_attrs(struct device *hwdev, struct scatterlist *sgl,
>  }
>  EXPORT_SYMBOL_GPL(xen_swiotlb_unmap_sg_attrs);
>  
> -void
> -xen_swiotlb_unmap_sg(struct device *hwdev, struct scatterlist *sgl, int nelems,
> -		     enum dma_data_direction dir)
> -{
> -	return xen_swiotlb_unmap_sg_attrs(hwdev, sgl, nelems, dir, NULL);
> -}
> -EXPORT_SYMBOL_GPL(xen_swiotlb_unmap_sg);
> -
>  /*
>   * Make physical memory consistent for a set of streaming mode DMA translations
>   * after a transfer.
> diff --git a/include/xen/swiotlb-xen.h b/include/xen/swiotlb-xen.h
> index f26f9f3..a0db2b7 100644
> --- a/include/xen/swiotlb-xen.h
> +++ b/include/xen/swiotlb-xen.h
> @@ -23,15 +23,6 @@ extern dma_addr_t xen_swiotlb_map_page(struct device *dev, struct page *page,
>  extern void xen_swiotlb_unmap_page(struct device *hwdev, dma_addr_t dev_addr,
>  				   size_t size, enum dma_data_direction dir,
>  				   struct dma_attrs *attrs);
> -/*
> -extern int
> -xen_swiotlb_map_sg(struct device *hwdev, struct scatterlist *sg, int nents,
> -		   enum dma_data_direction dir);
> -
> -extern void
> -xen_swiotlb_unmap_sg(struct device *hwdev, struct scatterlist *sg, int nents,
> -		     enum dma_data_direction dir);
> -*/
>  extern int
>  xen_swiotlb_map_sg_attrs(struct device *hwdev, struct scatterlist *sgl,
>  			 int nelems, enum dma_data_direction dir,
> -- 
> 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 Sep 14 16:09:51 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 16: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 1TCYSZ-00062p-4S; Fri, 14 Sep 2012 16:09: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 1TCYSX-00062i-P8
	for xen-devel@lists.xensource.com; Fri, 14 Sep 2012 16:09:38 +0000
Received: from [85.158.137.99:15888] by server-4.bemta-3.messagelabs.com id
	9C/BF-24831-FB653505; Fri, 14 Sep 2012 16:09:35 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-4.tower-217.messagelabs.com!1347638974!17712749!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDkyOTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28315 invoked from network); 14 Sep 2012 16:09:34 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Sep 2012 16:09:34 -0000
X-IronPort-AV: E=Sophos;i="4.80,423,1344211200"; d="scan'208";a="14551548"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Sep 2012 16:09: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.279.1; Fri, 14 Sep 2012 17:09:18 +0100
Date: Fri, 14 Sep 2012 17:08:35 +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: <1347306367-28669-5-git-send-email-konrad.wilk@oracle.com>
Message-ID: <alpine.DEB.2.02.1209141708300.29232@kaball.uk.xensource.com>
References: <1347306367-28669-1-git-send-email-konrad.wilk@oracle.com>
	<1347306367-28669-5-git-send-email-konrad.wilk@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>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 04/10] xen/swiotlb: Move the nr_tbl
 determination in its own 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 Mon, 10 Sep 2012, Konrad Rzeszutek Wilk wrote:
> Moving the function out of the way to prepare for the late
> SWIOTLB init.
> 
> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>


Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

>  drivers/xen/swiotlb-xen.c |   21 +++++++++++----------
>  1 files changed, 11 insertions(+), 10 deletions(-)
> 
> diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
> index 1afb4fb..a2aad6e 100644
> --- a/drivers/xen/swiotlb-xen.c
> +++ b/drivers/xen/swiotlb-xen.c
> @@ -144,25 +144,26 @@ xen_swiotlb_fixup(void *buf, size_t size, unsigned long nslabs)
>  	} while (i < nslabs);
>  	return 0;
>  }
> +static unsigned long xen_set_nslabs(unsigned long nr_tbl)
> +{
> +	if (!nr_tbl) {
> +		xen_io_tlb_nslabs = (64 * 1024 * 1024 >> IO_TLB_SHIFT);
> +		xen_io_tlb_nslabs = ALIGN(xen_io_tlb_nslabs, IO_TLB_SEGSIZE);
> +	} else
> +		xen_io_tlb_nslabs = nr_tbl;
>  
> +	return xen_io_tlb_nslabs << IO_TLB_SHIFT;
> +}
>  void __init xen_swiotlb_init(int verbose)
>  {
>  	unsigned long bytes;
>  	int rc = -ENOMEM;
> -	unsigned long nr_tbl;
>  	char *m = NULL;
>  	unsigned int repeat = 3;
>  
> -	nr_tbl = swiotlb_nr_tbl();
> -	if (nr_tbl)
> -		xen_io_tlb_nslabs = nr_tbl;
> -	else {
> -		xen_io_tlb_nslabs = (64 * 1024 * 1024 >> IO_TLB_SHIFT);
> -		xen_io_tlb_nslabs = ALIGN(xen_io_tlb_nslabs, IO_TLB_SEGSIZE);
> -	}
> +	xen_io_tlb_nslabs = swiotlb_nr_tbl();
>  retry:
> -	bytes = xen_io_tlb_nslabs << IO_TLB_SHIFT;
> -
> +	bytes = xen_set_nslabs(xen_io_tlb_nslabs);
>  	/*
>  	 * Get IO TLB memory from any location.
>  	 */
> -- 
> 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 Sep 14 16:09:51 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 16: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 1TCYSZ-00062p-4S; Fri, 14 Sep 2012 16:09: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 1TCYSX-00062i-P8
	for xen-devel@lists.xensource.com; Fri, 14 Sep 2012 16:09:38 +0000
Received: from [85.158.137.99:15888] by server-4.bemta-3.messagelabs.com id
	9C/BF-24831-FB653505; Fri, 14 Sep 2012 16:09:35 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-4.tower-217.messagelabs.com!1347638974!17712749!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDkyOTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28315 invoked from network); 14 Sep 2012 16:09:34 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Sep 2012 16:09:34 -0000
X-IronPort-AV: E=Sophos;i="4.80,423,1344211200"; d="scan'208";a="14551548"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Sep 2012 16:09: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.279.1; Fri, 14 Sep 2012 17:09:18 +0100
Date: Fri, 14 Sep 2012 17:08:35 +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: <1347306367-28669-5-git-send-email-konrad.wilk@oracle.com>
Message-ID: <alpine.DEB.2.02.1209141708300.29232@kaball.uk.xensource.com>
References: <1347306367-28669-1-git-send-email-konrad.wilk@oracle.com>
	<1347306367-28669-5-git-send-email-konrad.wilk@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>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 04/10] xen/swiotlb: Move the nr_tbl
 determination in its own 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 Mon, 10 Sep 2012, Konrad Rzeszutek Wilk wrote:
> Moving the function out of the way to prepare for the late
> SWIOTLB init.
> 
> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>


Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

>  drivers/xen/swiotlb-xen.c |   21 +++++++++++----------
>  1 files changed, 11 insertions(+), 10 deletions(-)
> 
> diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
> index 1afb4fb..a2aad6e 100644
> --- a/drivers/xen/swiotlb-xen.c
> +++ b/drivers/xen/swiotlb-xen.c
> @@ -144,25 +144,26 @@ xen_swiotlb_fixup(void *buf, size_t size, unsigned long nslabs)
>  	} while (i < nslabs);
>  	return 0;
>  }
> +static unsigned long xen_set_nslabs(unsigned long nr_tbl)
> +{
> +	if (!nr_tbl) {
> +		xen_io_tlb_nslabs = (64 * 1024 * 1024 >> IO_TLB_SHIFT);
> +		xen_io_tlb_nslabs = ALIGN(xen_io_tlb_nslabs, IO_TLB_SEGSIZE);
> +	} else
> +		xen_io_tlb_nslabs = nr_tbl;
>  
> +	return xen_io_tlb_nslabs << IO_TLB_SHIFT;
> +}
>  void __init xen_swiotlb_init(int verbose)
>  {
>  	unsigned long bytes;
>  	int rc = -ENOMEM;
> -	unsigned long nr_tbl;
>  	char *m = NULL;
>  	unsigned int repeat = 3;
>  
> -	nr_tbl = swiotlb_nr_tbl();
> -	if (nr_tbl)
> -		xen_io_tlb_nslabs = nr_tbl;
> -	else {
> -		xen_io_tlb_nslabs = (64 * 1024 * 1024 >> IO_TLB_SHIFT);
> -		xen_io_tlb_nslabs = ALIGN(xen_io_tlb_nslabs, IO_TLB_SEGSIZE);
> -	}
> +	xen_io_tlb_nslabs = swiotlb_nr_tbl();
>  retry:
> -	bytes = xen_io_tlb_nslabs << IO_TLB_SHIFT;
> -
> +	bytes = xen_set_nslabs(xen_io_tlb_nslabs);
>  	/*
>  	 * Get IO TLB memory from any location.
>  	 */
> -- 
> 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 Sep 14 16:11:52 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 16:11:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TCYUT-0006DT-Kj; Fri, 14 Sep 2012 16:11: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 1TCYUS-0006DF-8k
	for xen-devel@lists.xensource.com; Fri, 14 Sep 2012 16:11:36 +0000
Received: from [85.158.139.211:14620] by server-7.bemta-5.messagelabs.com id
	44/D1-19703-73753505; Fri, 14 Sep 2012 16:11:35 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-5.tower-206.messagelabs.com!1347639091!18548041!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDkyOTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14927 invoked from network); 14 Sep 2012 16:11:31 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Sep 2012 16:11:31 -0000
X-IronPort-AV: E=Sophos;i="4.80,423,1344211200"; d="scan'208";a="14551602"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Sep 2012 16:11: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.279.1; Fri, 14 Sep 2012 17:11:31 +0100
Date: Fri, 14 Sep 2012 17:10:48 +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: <1347306367-28669-11-git-send-email-konrad.wilk@oracle.com>
Message-ID: <alpine.DEB.2.02.1209141709580.29232@kaball.uk.xensource.com>
References: <1347306367-28669-1-git-send-email-konrad.wilk@oracle.com>
	<1347306367-28669-11-git-send-email-konrad.wilk@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>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 10/10] xen/swiotlb: Depending on
 after_bootmem is not 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 Mon, 10 Sep 2012, Konrad Rzeszutek Wilk wrote:
> When PCI IOMMUs are initialized it is after after_bootmem but
> before a lot of "other" subsystems are initialized. As such
> the check for after_bootmem is incorrect and we should
> just use a parameter to define whether we are early or late.
> 
> This solves this bootup problem:
> 
> __ex_table already sorted, skipping sortM
> Initializing CPU#0
> Warning: only able to allocate 1 MB for software IO TLB
> Xen-SWIOTLB: Lowering to 2MB
> Warning: only able to allocate 1 MB for software IO TLB
> Xen-SWIOTLB: Lowering to 2MB
> Warning: only able to allocate 1 MB for software IO TLB
> Xen-SWIOTLB: Lowering to 2MB
> Warning: only able to allocate 1 MB for software IO TLB
> Cannot allocate Xen-SWIOTLB buffer (rc:-12)
> 
> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> ---
>  arch/x86/xen/pci-swiotlb-xen.c |    4 ++--
>  drivers/xen/swiotlb-xen.c      |   11 ++++++-----
>  include/xen/swiotlb-xen.h      |    2 +-
>  3 files changed, 9 insertions(+), 8 deletions(-)
> 
> diff --git a/arch/x86/xen/pci-swiotlb-xen.c b/arch/x86/xen/pci-swiotlb-xen.c
> index fc0c78f..1608244 100644
> --- a/arch/x86/xen/pci-swiotlb-xen.c
> +++ b/arch/x86/xen/pci-swiotlb-xen.c
> @@ -69,7 +69,7 @@ int __init pci_xen_swiotlb_detect(void)
>  void __init pci_xen_swiotlb_init(void)
>  {
>  	if (xen_swiotlb) {
> -		xen_swiotlb_init(1);
> +		xen_swiotlb_init(1, true /* early */);
>  		dma_ops = &xen_swiotlb_dma_ops;
>  
>  		/* Make sure ACS will be enabled */
> @@ -84,7 +84,7 @@ int pci_xen_swiotlb_init_late(void)
>  	if (xen_swiotlb)
>  		return 0;
>  
> -	rc = xen_swiotlb_init(1);
> +	rc = xen_swiotlb_init(1, false /* late */);
>  	if (rc)
>  		return rc;
>  
> diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
> index 6f81994..7443e19 100644
> --- a/drivers/xen/swiotlb-xen.c
> +++ b/drivers/xen/swiotlb-xen.c
> @@ -176,7 +176,7 @@ static const char *xen_swiotlb_error(enum xen_swiotlb_err err)
>  	}
>  	return "";
>  }
> -int __ref xen_swiotlb_init(int verbose)
> +int __ref xen_swiotlb_init(int verbose, bool early)
>  {
>  	unsigned long bytes, order;
>  	int rc = -ENOMEM;
> @@ -190,7 +190,7 @@ retry:
>  	/*
>  	 * Get IO TLB memory from any location.
>  	 */
> -	if (!after_bootmem)
> +	if (early)
>  		xen_io_tlb_start = alloc_bootmem_pages(PAGE_ALIGN(bytes));
>  	else {
>  #define SLABS_PER_PAGE (1 << (PAGE_SHIFT - IO_TLB_SHIFT))
> @@ -220,7 +220,7 @@ retry:
>  			       bytes,
>  			       xen_io_tlb_nslabs);
>  	if (rc) {
> -		if (!after_bootmem)
> +		if (early)
>  			free_bootmem(__pa(xen_io_tlb_start), PAGE_ALIGN(bytes));
>  		else {
>  			free_pages((unsigned long)xen_io_tlb_start, order);
> @@ -230,7 +230,8 @@ retry:
>  		goto error;
>  	}
>  	start_dma_addr = xen_virt_to_bus(xen_io_tlb_start);
> -	if (!after_bootmem)
> +	rc = 0;
     ^
why does this change belong to this patch?


> +	if (early)
>  		swiotlb_init_with_tbl(xen_io_tlb_start, xen_io_tlb_nslabs, verbose);
>  	else
>  		rc = swiotlb_late_init_with_tbl(xen_io_tlb_start, xen_io_tlb_nslabs);
> @@ -244,7 +245,7 @@ error:
>  		goto retry;
>  	}
>  	pr_err("%s (rc:%d)", xen_swiotlb_error(m_ret), rc);
> -	if (!after_bootmem)
> +	if (early)
>  		panic("%s (rc:%d)", xen_swiotlb_error(m_ret), rc);
>  	else
>  		free_pages((unsigned long)xen_io_tlb_start, order);
> diff --git a/include/xen/swiotlb-xen.h b/include/xen/swiotlb-xen.h
> index a0db2b7..de8bcc6 100644
> --- a/include/xen/swiotlb-xen.h
> +++ b/include/xen/swiotlb-xen.h
> @@ -3,7 +3,7 @@
>  
>  #include <linux/swiotlb.h>
>  
> -extern int xen_swiotlb_init(int verbose);
> +extern int xen_swiotlb_init(int verbose, bool early);
>  
>  extern void
>  *xen_swiotlb_alloc_coherent(struct device *hwdev, size_t size,
> -- 
> 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 Sep 14 16:11:52 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 16:11:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TCYUT-0006DT-Kj; Fri, 14 Sep 2012 16:11: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 1TCYUS-0006DF-8k
	for xen-devel@lists.xensource.com; Fri, 14 Sep 2012 16:11:36 +0000
Received: from [85.158.139.211:14620] by server-7.bemta-5.messagelabs.com id
	44/D1-19703-73753505; Fri, 14 Sep 2012 16:11:35 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-5.tower-206.messagelabs.com!1347639091!18548041!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDkyOTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14927 invoked from network); 14 Sep 2012 16:11:31 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Sep 2012 16:11:31 -0000
X-IronPort-AV: E=Sophos;i="4.80,423,1344211200"; d="scan'208";a="14551602"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Sep 2012 16:11: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.279.1; Fri, 14 Sep 2012 17:11:31 +0100
Date: Fri, 14 Sep 2012 17:10:48 +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: <1347306367-28669-11-git-send-email-konrad.wilk@oracle.com>
Message-ID: <alpine.DEB.2.02.1209141709580.29232@kaball.uk.xensource.com>
References: <1347306367-28669-1-git-send-email-konrad.wilk@oracle.com>
	<1347306367-28669-11-git-send-email-konrad.wilk@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>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 10/10] xen/swiotlb: Depending on
 after_bootmem is not 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 Mon, 10 Sep 2012, Konrad Rzeszutek Wilk wrote:
> When PCI IOMMUs are initialized it is after after_bootmem but
> before a lot of "other" subsystems are initialized. As such
> the check for after_bootmem is incorrect and we should
> just use a parameter to define whether we are early or late.
> 
> This solves this bootup problem:
> 
> __ex_table already sorted, skipping sortM
> Initializing CPU#0
> Warning: only able to allocate 1 MB for software IO TLB
> Xen-SWIOTLB: Lowering to 2MB
> Warning: only able to allocate 1 MB for software IO TLB
> Xen-SWIOTLB: Lowering to 2MB
> Warning: only able to allocate 1 MB for software IO TLB
> Xen-SWIOTLB: Lowering to 2MB
> Warning: only able to allocate 1 MB for software IO TLB
> Cannot allocate Xen-SWIOTLB buffer (rc:-12)
> 
> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> ---
>  arch/x86/xen/pci-swiotlb-xen.c |    4 ++--
>  drivers/xen/swiotlb-xen.c      |   11 ++++++-----
>  include/xen/swiotlb-xen.h      |    2 +-
>  3 files changed, 9 insertions(+), 8 deletions(-)
> 
> diff --git a/arch/x86/xen/pci-swiotlb-xen.c b/arch/x86/xen/pci-swiotlb-xen.c
> index fc0c78f..1608244 100644
> --- a/arch/x86/xen/pci-swiotlb-xen.c
> +++ b/arch/x86/xen/pci-swiotlb-xen.c
> @@ -69,7 +69,7 @@ int __init pci_xen_swiotlb_detect(void)
>  void __init pci_xen_swiotlb_init(void)
>  {
>  	if (xen_swiotlb) {
> -		xen_swiotlb_init(1);
> +		xen_swiotlb_init(1, true /* early */);
>  		dma_ops = &xen_swiotlb_dma_ops;
>  
>  		/* Make sure ACS will be enabled */
> @@ -84,7 +84,7 @@ int pci_xen_swiotlb_init_late(void)
>  	if (xen_swiotlb)
>  		return 0;
>  
> -	rc = xen_swiotlb_init(1);
> +	rc = xen_swiotlb_init(1, false /* late */);
>  	if (rc)
>  		return rc;
>  
> diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
> index 6f81994..7443e19 100644
> --- a/drivers/xen/swiotlb-xen.c
> +++ b/drivers/xen/swiotlb-xen.c
> @@ -176,7 +176,7 @@ static const char *xen_swiotlb_error(enum xen_swiotlb_err err)
>  	}
>  	return "";
>  }
> -int __ref xen_swiotlb_init(int verbose)
> +int __ref xen_swiotlb_init(int verbose, bool early)
>  {
>  	unsigned long bytes, order;
>  	int rc = -ENOMEM;
> @@ -190,7 +190,7 @@ retry:
>  	/*
>  	 * Get IO TLB memory from any location.
>  	 */
> -	if (!after_bootmem)
> +	if (early)
>  		xen_io_tlb_start = alloc_bootmem_pages(PAGE_ALIGN(bytes));
>  	else {
>  #define SLABS_PER_PAGE (1 << (PAGE_SHIFT - IO_TLB_SHIFT))
> @@ -220,7 +220,7 @@ retry:
>  			       bytes,
>  			       xen_io_tlb_nslabs);
>  	if (rc) {
> -		if (!after_bootmem)
> +		if (early)
>  			free_bootmem(__pa(xen_io_tlb_start), PAGE_ALIGN(bytes));
>  		else {
>  			free_pages((unsigned long)xen_io_tlb_start, order);
> @@ -230,7 +230,8 @@ retry:
>  		goto error;
>  	}
>  	start_dma_addr = xen_virt_to_bus(xen_io_tlb_start);
> -	if (!after_bootmem)
> +	rc = 0;
     ^
why does this change belong to this patch?


> +	if (early)
>  		swiotlb_init_with_tbl(xen_io_tlb_start, xen_io_tlb_nslabs, verbose);
>  	else
>  		rc = swiotlb_late_init_with_tbl(xen_io_tlb_start, xen_io_tlb_nslabs);
> @@ -244,7 +245,7 @@ error:
>  		goto retry;
>  	}
>  	pr_err("%s (rc:%d)", xen_swiotlb_error(m_ret), rc);
> -	if (!after_bootmem)
> +	if (early)
>  		panic("%s (rc:%d)", xen_swiotlb_error(m_ret), rc);
>  	else
>  		free_pages((unsigned long)xen_io_tlb_start, order);
> diff --git a/include/xen/swiotlb-xen.h b/include/xen/swiotlb-xen.h
> index a0db2b7..de8bcc6 100644
> --- a/include/xen/swiotlb-xen.h
> +++ b/include/xen/swiotlb-xen.h
> @@ -3,7 +3,7 @@
>  
>  #include <linux/swiotlb.h>
>  
> -extern int xen_swiotlb_init(int verbose);
> +extern int xen_swiotlb_init(int verbose, bool early);
>  
>  extern void
>  *xen_swiotlb_alloc_coherent(struct device *hwdev, size_t size,
> -- 
> 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 Sep 14 16:12:56 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 16:12:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TCYVY-0006Kp-3i; Fri, 14 Sep 2012 16:12:44 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1TCYVW-0006Kb-UR
	for xen-devel@lists.xensource.com; Fri, 14 Sep 2012 16:12:43 +0000
Received: from [85.158.143.99:28285] by server-2.bemta-4.messagelabs.com id
	55/E5-21239-A7753505; Fri, 14 Sep 2012 16:12:42 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1347639161!24271430!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDkyOTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28787 invoked from network); 14 Sep 2012 16:12:41 -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;
	14 Sep 2012 16:12:41 -0000
X-IronPort-AV: E=Sophos;i="4.80,423,1344211200"; d="scan'208";a="14551616"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Sep 2012 16:12: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.279.1; Fri, 14 Sep 2012 17:12:41 +0100
Date: Fri, 14 Sep 2012 17:11:58 +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: <1347306367-28669-10-git-send-email-konrad.wilk@oracle.com>
Message-ID: <alpine.DEB.2.02.1209141711310.29232@kaball.uk.xensource.com>
References: <1347306367-28669-1-git-send-email-konrad.wilk@oracle.com>
	<1347306367-28669-10-git-send-email-konrad.wilk@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>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 09/10] xen/swiotlb: Fix compile warnings
 when using plain integer instead of NULL pointer.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 10 Sep 2012, Konrad Rzeszutek Wilk wrote:
> arch/x86/xen/pci-swiotlb-xen.c:96:1: warning: Using plain integer as NULL pointer
> arch/x86/xen/pci-swiotlb-xen.c:96:1: warning: Using plain integer as NULL pointer
> 
> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>


>  arch/x86/xen/pci-swiotlb-xen.c |    4 ++--
>  1 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/x86/xen/pci-swiotlb-xen.c b/arch/x86/xen/pci-swiotlb-xen.c
> index 406f9c4..fc0c78f 100644
> --- a/arch/x86/xen/pci-swiotlb-xen.c
> +++ b/arch/x86/xen/pci-swiotlb-xen.c
> @@ -97,6 +97,6 @@ int pci_xen_swiotlb_init_late(void)
>  EXPORT_SYMBOL_GPL(pci_xen_swiotlb_init_late);
>  
>  IOMMU_INIT_FINISH(pci_xen_swiotlb_detect,
> -		  0,
> +		  NULL,
>  		  pci_xen_swiotlb_init,
> -		  0);
> +		  NULL);
> -- 
> 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 Sep 14 16:12:56 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 16:12:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TCYVY-0006Kp-3i; Fri, 14 Sep 2012 16:12:44 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1TCYVW-0006Kb-UR
	for xen-devel@lists.xensource.com; Fri, 14 Sep 2012 16:12:43 +0000
Received: from [85.158.143.99:28285] by server-2.bemta-4.messagelabs.com id
	55/E5-21239-A7753505; Fri, 14 Sep 2012 16:12:42 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1347639161!24271430!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDkyOTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28787 invoked from network); 14 Sep 2012 16:12:41 -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;
	14 Sep 2012 16:12:41 -0000
X-IronPort-AV: E=Sophos;i="4.80,423,1344211200"; d="scan'208";a="14551616"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Sep 2012 16:12: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.279.1; Fri, 14 Sep 2012 17:12:41 +0100
Date: Fri, 14 Sep 2012 17:11:58 +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: <1347306367-28669-10-git-send-email-konrad.wilk@oracle.com>
Message-ID: <alpine.DEB.2.02.1209141711310.29232@kaball.uk.xensource.com>
References: <1347306367-28669-1-git-send-email-konrad.wilk@oracle.com>
	<1347306367-28669-10-git-send-email-konrad.wilk@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>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 09/10] xen/swiotlb: Fix compile warnings
 when using plain integer instead of NULL pointer.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 10 Sep 2012, Konrad Rzeszutek Wilk wrote:
> arch/x86/xen/pci-swiotlb-xen.c:96:1: warning: Using plain integer as NULL pointer
> arch/x86/xen/pci-swiotlb-xen.c:96:1: warning: Using plain integer as NULL pointer
> 
> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>


>  arch/x86/xen/pci-swiotlb-xen.c |    4 ++--
>  1 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/x86/xen/pci-swiotlb-xen.c b/arch/x86/xen/pci-swiotlb-xen.c
> index 406f9c4..fc0c78f 100644
> --- a/arch/x86/xen/pci-swiotlb-xen.c
> +++ b/arch/x86/xen/pci-swiotlb-xen.c
> @@ -97,6 +97,6 @@ int pci_xen_swiotlb_init_late(void)
>  EXPORT_SYMBOL_GPL(pci_xen_swiotlb_init_late);
>  
>  IOMMU_INIT_FINISH(pci_xen_swiotlb_detect,
> -		  0,
> +		  NULL,
>  		  pci_xen_swiotlb_init,
> -		  0);
> +		  NULL);
> -- 
> 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 Sep 14 16:19:29 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 16:19:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TCYbr-0006eU-Vs; Fri, 14 Sep 2012 16:19:15 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1TCYbq-0006eP-Ky
	for xen-devel@lists.xensource.com; Fri, 14 Sep 2012 16:19:14 +0000
Received: from [85.158.139.211:8138] by server-11.bemta-5.messagelabs.com id
	7A/BA-24658-10953505; Fri, 14 Sep 2012 16:19:13 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-206.messagelabs.com!1347639553!18548867!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDkyOTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1597 invoked from network); 14 Sep 2012 16:19:13 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Sep 2012 16:19:13 -0000
X-IronPort-AV: E=Sophos;i="4.80,423,1344211200"; d="scan'208";a="14551707"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Sep 2012 16:18: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.279.1; Fri, 14 Sep 2012 17:18: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 1TCYbJ-0000gp-Hj;
	Fri, 14 Sep 2012 16:18:41 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1TCYbJ-0006XL-7S;
	Fri, 14 Sep 2012 17:18:41 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-13763-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 14 Sep 2012 17:18:41 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [qemu-upstream-4.2-testing baseline test] 13763:
	tolerable FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

"Old" tested version had not actually been tested; therefore in this
flight we test it, rather than a new candidate.  The baseline, if
any, is the most recent actually tested revision.

flight 13763 qemu-upstream-4.2-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13763/

Failures :-/ but no regressions.

Tests which did not succeed,
including tests which could not be run:
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  9 guest-localmigrate fail never pass
 test-i386-i386-xl-qemuu-win   9 guest-localmigrate           fail   never pass
 test-amd64-amd64-qemuu-win   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-qemuu-win-vcpus1  9 guest-localmigrate      fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64  9 guest-localmigrate      fail never pass
 test-amd64-i386-xend-qemuu-winxpsp3 16 leak-check/check        fail never pass
 test-i386-i386-qemuu-win     16 leak-check/check             fail   never pass
 test-amd64-i386-qemuu-win-vcpus1 16 leak-check/check           fail never pass
 test-amd64-i386-qemuu-win    16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemuu-win  9 guest-localmigrate           fail  never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail never pass
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass


jobs:
 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                           pass    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-win-vcpus1                             fail    
 test-amd64-i386-xl-qemuu-win-vcpus1                          fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-amd64-qemuu-win                                   fail    
 test-amd64-i386-qemuu-win                                    fail    
 test-i386-i386-qemuu-win                                     fail    
 test-amd64-amd64-xl-qemuu-win                                fail    
 test-i386-i386-xl-qemuu-win                                  fail    
 test-amd64-i386-xend-qemuu-winxpsp3                          fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


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 Sep 14 16:19:29 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 16:19:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TCYbr-0006eU-Vs; Fri, 14 Sep 2012 16:19:15 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1TCYbq-0006eP-Ky
	for xen-devel@lists.xensource.com; Fri, 14 Sep 2012 16:19:14 +0000
Received: from [85.158.139.211:8138] by server-11.bemta-5.messagelabs.com id
	7A/BA-24658-10953505; Fri, 14 Sep 2012 16:19:13 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-206.messagelabs.com!1347639553!18548867!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDkyOTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1597 invoked from network); 14 Sep 2012 16:19:13 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Sep 2012 16:19:13 -0000
X-IronPort-AV: E=Sophos;i="4.80,423,1344211200"; d="scan'208";a="14551707"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Sep 2012 16:18: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.279.1; Fri, 14 Sep 2012 17:18: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 1TCYbJ-0000gp-Hj;
	Fri, 14 Sep 2012 16:18:41 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1TCYbJ-0006XL-7S;
	Fri, 14 Sep 2012 17:18:41 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-13763-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 14 Sep 2012 17:18:41 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [qemu-upstream-4.2-testing baseline test] 13763:
	tolerable FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

"Old" tested version had not actually been tested; therefore in this
flight we test it, rather than a new candidate.  The baseline, if
any, is the most recent actually tested revision.

flight 13763 qemu-upstream-4.2-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13763/

Failures :-/ but no regressions.

Tests which did not succeed,
including tests which could not be run:
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  9 guest-localmigrate fail never pass
 test-i386-i386-xl-qemuu-win   9 guest-localmigrate           fail   never pass
 test-amd64-amd64-qemuu-win   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-qemuu-win-vcpus1  9 guest-localmigrate      fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64  9 guest-localmigrate      fail never pass
 test-amd64-i386-xend-qemuu-winxpsp3 16 leak-check/check        fail never pass
 test-i386-i386-qemuu-win     16 leak-check/check             fail   never pass
 test-amd64-i386-qemuu-win-vcpus1 16 leak-check/check           fail never pass
 test-amd64-i386-qemuu-win    16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemuu-win  9 guest-localmigrate           fail  never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail never pass
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass


jobs:
 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                           pass    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-win-vcpus1                             fail    
 test-amd64-i386-xl-qemuu-win-vcpus1                          fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-amd64-qemuu-win                                   fail    
 test-amd64-i386-qemuu-win                                    fail    
 test-i386-i386-qemuu-win                                     fail    
 test-amd64-amd64-xl-qemuu-win                                fail    
 test-i386-i386-xl-qemuu-win                                  fail    
 test-amd64-i386-xend-qemuu-winxpsp3                          fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


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 Sep 14 16:20:44 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 16:20: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 1TCYd6-0006ip-Eh; Fri, 14 Sep 2012 16:20: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 1TCYd5-0006ie-8m
	for Xen-devel@lists.xensource.com; Fri, 14 Sep 2012 16:20:31 +0000
Received: from [85.158.138.51:54417] by server-10.bemta-3.messagelabs.com id
	82/64-10411-E4953505; Fri, 14 Sep 2012 16:20:30 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1347639629!30507598!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDkyOTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28689 invoked from network); 14 Sep 2012 16:20:29 -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;
	14 Sep 2012 16:20:29 -0000
X-IronPort-AV: E=Sophos;i="4.80,423,1344211200"; d="scan'208";a="14551762"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Sep 2012 16:20: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.279.1;
	Fri, 14 Sep 2012 17:20:29 +0100
Message-ID: <1347639628.14977.12.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Mukesh Rathor <mukesh.rathor@oracle.com>
Date: Fri, 14 Sep 2012 17:20:28 +0100
In-Reply-To: <20120815180250.1e068d10@mantra.us.oracle.com>
References: <20120815180250.1e068d10@mantra.us.oracle.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [RFC PATCH 3/8]: PVH: memory manager and paging
 related changes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-08-16 at 02:02 +0100, Mukesh Rathor wrote:
> 
> +/* Map foreign gmfn, fgmfn, to local pfn, lpfn. This for the user
> space
> + * creating new guest on PVH dom0 and needs to map domU pages. Called
> from
> + * exported function, so no need to export this.
> + */
> +static int pvh_add_to_xen_p2m(unsigned long lpfn, unsigned long
> fgmfn,
> +                             unsigned int domid)
> +{
> +       int rc;
> +       struct xen_add_to_physmap pmb = {.foreign_domid = domid};
> +
> +       pmb.gpfn = lpfn;
> +       pmb.idx = fgmfn;
> +       pmb.space = XENMAPSPACE_gmfn_foreign;

You've not initialised pmb.domid here. I think you want/need to set it
to DOMID_SELF and have the h/v side behave accordingly.

> +       rc = HYPERVISOR_memory_op(XENMEM_add_to_physmap, &pmb); 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 14 16:20:44 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 16:20: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 1TCYd6-0006ip-Eh; Fri, 14 Sep 2012 16:20: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 1TCYd5-0006ie-8m
	for Xen-devel@lists.xensource.com; Fri, 14 Sep 2012 16:20:31 +0000
Received: from [85.158.138.51:54417] by server-10.bemta-3.messagelabs.com id
	82/64-10411-E4953505; Fri, 14 Sep 2012 16:20:30 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1347639629!30507598!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDkyOTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28689 invoked from network); 14 Sep 2012 16:20:29 -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;
	14 Sep 2012 16:20:29 -0000
X-IronPort-AV: E=Sophos;i="4.80,423,1344211200"; d="scan'208";a="14551762"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Sep 2012 16:20: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.279.1;
	Fri, 14 Sep 2012 17:20:29 +0100
Message-ID: <1347639628.14977.12.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Mukesh Rathor <mukesh.rathor@oracle.com>
Date: Fri, 14 Sep 2012 17:20:28 +0100
In-Reply-To: <20120815180250.1e068d10@mantra.us.oracle.com>
References: <20120815180250.1e068d10@mantra.us.oracle.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [RFC PATCH 3/8]: PVH: memory manager and paging
 related changes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-08-16 at 02:02 +0100, Mukesh Rathor wrote:
> 
> +/* Map foreign gmfn, fgmfn, to local pfn, lpfn. This for the user
> space
> + * creating new guest on PVH dom0 and needs to map domU pages. Called
> from
> + * exported function, so no need to export this.
> + */
> +static int pvh_add_to_xen_p2m(unsigned long lpfn, unsigned long
> fgmfn,
> +                             unsigned int domid)
> +{
> +       int rc;
> +       struct xen_add_to_physmap pmb = {.foreign_domid = domid};
> +
> +       pmb.gpfn = lpfn;
> +       pmb.idx = fgmfn;
> +       pmb.space = XENMAPSPACE_gmfn_foreign;

You've not initialised pmb.domid here. I think you want/need to set it
to DOMID_SELF and have the h/v side behave accordingly.

> +       rc = HYPERVISOR_memory_op(XENMEM_add_to_physmap, &pmb); 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 14 16:27:22 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 16:27: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 1TCYjX-0006xF-9Y; Fri, 14 Sep 2012 16:27: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 1TCYjV-0006x7-NF
	for xen-devel@lists.xensource.com; Fri, 14 Sep 2012 16:27:09 +0000
Received: from [85.158.143.99:18077] by server-1.bemta-4.messagelabs.com id
	74/39-12504-CDA53505; Fri, 14 Sep 2012 16:27:08 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1347640028!29489851!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDkyOTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1501 invoked from network); 14 Sep 2012 16:27:08 -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;
	14 Sep 2012 16:27:08 -0000
X-IronPort-AV: E=Sophos;i="4.80,423,1344211200"; d="scan'208";a="14551866"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Sep 2012 16:27:07 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Fri, 14 Sep 2012 17:27:07 +0100
Date: Fri, 14 Sep 2012 17:26:24 +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: <1347306367-28669-7-git-send-email-konrad.wilk@oracle.com>
Message-ID: <alpine.DEB.2.02.1209141720160.29232@kaball.uk.xensource.com>
References: <1347306367-28669-1-git-send-email-konrad.wilk@oracle.com>
	<1347306367-28669-7-git-send-email-konrad.wilk@oracle.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>,
	"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 06/10] xen/swiotlb: Use the
 swiotlb_late_init_with_tbl to init Xen-SWIOTLB late when PV PCI is 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, 10 Sep 2012, Konrad Rzeszutek Wilk wrote:
> With this patch we provide the functionality to initialize the
> Xen-SWIOTLB late in the bootup cycle - specifically for
> Xen PCI-frontend. We still will work if the user had
> supplied 'iommu=soft' on the Linux command line.
> 
> CC: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
> [v1: Fix smatch warnings]
> [v2: Added check for xen_swiotlb]
> [v3: Rebased with new xen-swiotlb changes]
> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

Reviewed-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>


>  arch/x86/include/asm/xen/swiotlb-xen.h |    2 +
>  arch/x86/xen/pci-swiotlb-xen.c         |   22 ++++++++++++++-
>  drivers/xen/swiotlb-xen.c              |   48 +++++++++++++++++++++++++------
>  include/xen/swiotlb-xen.h              |    2 +-
>  4 files changed, 62 insertions(+), 12 deletions(-)
> 
> diff --git a/arch/x86/include/asm/xen/swiotlb-xen.h b/arch/x86/include/asm/xen/swiotlb-xen.h
> index 1be1ab7..ee52fca 100644
> --- a/arch/x86/include/asm/xen/swiotlb-xen.h
> +++ b/arch/x86/include/asm/xen/swiotlb-xen.h
> @@ -5,10 +5,12 @@
>  extern int xen_swiotlb;
>  extern int __init pci_xen_swiotlb_detect(void);
>  extern void __init pci_xen_swiotlb_init(void);
> +extern int pci_xen_swiotlb_init_late(void);
>  #else
>  #define xen_swiotlb (0)
>  static inline int __init pci_xen_swiotlb_detect(void) { return 0; }
>  static inline void __init pci_xen_swiotlb_init(void) { }
> +static inline int pci_xen_swiotlb_init_late(void) { return -ENXIO; }
>  #endif
>  
>  #endif /* _ASM_X86_SWIOTLB_XEN_H */
> diff --git a/arch/x86/xen/pci-swiotlb-xen.c b/arch/x86/xen/pci-swiotlb-xen.c
> index 1c17227..406f9c4 100644
> --- a/arch/x86/xen/pci-swiotlb-xen.c
> +++ b/arch/x86/xen/pci-swiotlb-xen.c
> @@ -12,7 +12,7 @@
>  #include <asm/iommu.h>
>  #include <asm/dma.h>
>  #endif
> -
> +#include <linux/export.h>
>  int xen_swiotlb __read_mostly;
>  
>  static struct dma_map_ops xen_swiotlb_dma_ops = {
> @@ -76,6 +76,26 @@ void __init pci_xen_swiotlb_init(void)
>  		pci_request_acs();
>  	}
>  }
> +
> +int pci_xen_swiotlb_init_late(void)
> +{
> +	int rc;
> +
> +	if (xen_swiotlb)
> +		return 0;
> +
> +	rc = xen_swiotlb_init(1);
> +	if (rc)
> +		return rc;
> +
> +	dma_ops = &xen_swiotlb_dma_ops;
> +	/* Make sure ACS will be enabled */
> +	pci_request_acs();
> +
> +	return 0;
> +}
> +EXPORT_SYMBOL_GPL(pci_xen_swiotlb_init_late);
> +
>  IOMMU_INIT_FINISH(pci_xen_swiotlb_detect,
>  		  0,
>  		  pci_xen_swiotlb_init,
> diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
> index 701b103..f0825cb 100644
> --- a/drivers/xen/swiotlb-xen.c
> +++ b/drivers/xen/swiotlb-xen.c
> @@ -176,9 +176,9 @@ static const char *xen_swiotlb_error(enum xen_swiotlb_err err)
>  	}
>  	return "";
>  }
> -void __init xen_swiotlb_init(int verbose)
> +int __ref xen_swiotlb_init(int verbose)
>  {
> -	unsigned long bytes;
> +	unsigned long bytes, order;
>  	int rc = -ENOMEM;
>  	enum xen_swiotlb_err m_ret = XEN_SWIOTLB_UNKNOWN;
>  	unsigned int repeat = 3;
> @@ -186,10 +186,28 @@ void __init xen_swiotlb_init(int verbose)
>  	xen_io_tlb_nslabs = swiotlb_nr_tbl();
>  retry:
>  	bytes = xen_set_nslabs(xen_io_tlb_nslabs);
> +	order = get_order(xen_io_tlb_nslabs << IO_TLB_SHIFT);
>  	/*
>  	 * Get IO TLB memory from any location.
>  	 */
> -	xen_io_tlb_start = alloc_bootmem_pages(PAGE_ALIGN(bytes));
> +	if (!after_bootmem)
> +		xen_io_tlb_start = alloc_bootmem_pages(PAGE_ALIGN(bytes));
> +	else {
> +#define SLABS_PER_PAGE (1 << (PAGE_SHIFT - IO_TLB_SHIFT))
> +#define IO_TLB_MIN_SLABS ((1<<20) >> IO_TLB_SHIFT)
> +		while ((SLABS_PER_PAGE << order) > IO_TLB_MIN_SLABS) {
> +			xen_io_tlb_start = (void *)__get_free_pages(__GFP_NOWARN, order);
> +			if (xen_io_tlb_start)
> +				break;
> +			order--;
> +		}
> +		if (order != get_order(bytes)) {
> +			pr_warn("Warning: only able to allocate %ld MB "
> +				"for software IO TLB\n", (PAGE_SIZE << order) >> 20);
> +			xen_io_tlb_nslabs = SLABS_PER_PAGE << order;
> +			bytes = xen_io_tlb_nslabs << IO_TLB_SHIFT;
> +		}
> +	}
>  	if (!xen_io_tlb_start) {
>  		m_ret = XEN_SWIOTLB_ENOMEM;
>  		goto error;
> @@ -202,14 +220,21 @@ retry:
>  			       bytes,
>  			       xen_io_tlb_nslabs);
>  	if (rc) {
> -		free_bootmem(__pa(xen_io_tlb_start), PAGE_ALIGN(bytes));
> +		if (!after_bootmem)
> +			free_bootmem(__pa(xen_io_tlb_start), PAGE_ALIGN(bytes));
> +		else {
> +			free_pages((unsigned long)xen_io_tlb_start, order);
> +			xen_io_tlb_start = NULL;
> +		}
>  		m_ret = XEN_SWIOTLB_EFIXUP;
>  		goto error;
>  	}
>  	start_dma_addr = xen_virt_to_bus(xen_io_tlb_start);
> -	swiotlb_init_with_tbl(xen_io_tlb_start, xen_io_tlb_nslabs, verbose);
> -
> -	return;
> +	if (!after_bootmem)
> +		swiotlb_init_with_tbl(xen_io_tlb_start, xen_io_tlb_nslabs, verbose);
> +	else
> +		rc = swiotlb_late_init_with_tbl(xen_io_tlb_start, xen_io_tlb_nslabs);
> +	return rc;
>  error:
>  	if (repeat--) {
>  		xen_io_tlb_nslabs = max(1024UL, /* Min is 2MB */
> @@ -218,10 +243,13 @@ error:
>  		      (xen_io_tlb_nslabs << IO_TLB_SHIFT) >> 20);
>  		goto retry;
>  	}
> -	xen_raw_printk("%s (rc:%d)", xen_swiotlb_error(m_ret), rc);
> -	panic("%s (rc:%d)", xen_swiotlb_error(m_ret), rc);
> +	pr_err("%s (rc:%d)", xen_swiotlb_error(m_ret), rc);
> +	if (!after_bootmem)
> +		panic("%s (rc:%d)", xen_swiotlb_error(m_ret), rc);
> +	else
> +		free_pages((unsigned long)xen_io_tlb_start, order);
> +	return rc;
>  }
> -
>  void *
>  xen_swiotlb_alloc_coherent(struct device *hwdev, size_t size,
>  			   dma_addr_t *dma_handle, gfp_t flags,
> diff --git a/include/xen/swiotlb-xen.h b/include/xen/swiotlb-xen.h
> index 4f4d449..f26f9f3 100644
> --- a/include/xen/swiotlb-xen.h
> +++ b/include/xen/swiotlb-xen.h
> @@ -3,7 +3,7 @@
>  
>  #include <linux/swiotlb.h>
>  
> -extern void xen_swiotlb_init(int verbose);
> +extern int xen_swiotlb_init(int verbose);
>  
>  extern void
>  *xen_swiotlb_alloc_coherent(struct device *hwdev, size_t size,
> -- 
> 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 Sep 14 16:27:22 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 16:27: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 1TCYjX-0006xF-9Y; Fri, 14 Sep 2012 16:27: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 1TCYjV-0006x7-NF
	for xen-devel@lists.xensource.com; Fri, 14 Sep 2012 16:27:09 +0000
Received: from [85.158.143.99:18077] by server-1.bemta-4.messagelabs.com id
	74/39-12504-CDA53505; Fri, 14 Sep 2012 16:27:08 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1347640028!29489851!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDkyOTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1501 invoked from network); 14 Sep 2012 16:27:08 -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;
	14 Sep 2012 16:27:08 -0000
X-IronPort-AV: E=Sophos;i="4.80,423,1344211200"; d="scan'208";a="14551866"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Sep 2012 16:27:07 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Fri, 14 Sep 2012 17:27:07 +0100
Date: Fri, 14 Sep 2012 17:26:24 +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: <1347306367-28669-7-git-send-email-konrad.wilk@oracle.com>
Message-ID: <alpine.DEB.2.02.1209141720160.29232@kaball.uk.xensource.com>
References: <1347306367-28669-1-git-send-email-konrad.wilk@oracle.com>
	<1347306367-28669-7-git-send-email-konrad.wilk@oracle.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>,
	"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 06/10] xen/swiotlb: Use the
 swiotlb_late_init_with_tbl to init Xen-SWIOTLB late when PV PCI is 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, 10 Sep 2012, Konrad Rzeszutek Wilk wrote:
> With this patch we provide the functionality to initialize the
> Xen-SWIOTLB late in the bootup cycle - specifically for
> Xen PCI-frontend. We still will work if the user had
> supplied 'iommu=soft' on the Linux command line.
> 
> CC: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
> [v1: Fix smatch warnings]
> [v2: Added check for xen_swiotlb]
> [v3: Rebased with new xen-swiotlb changes]
> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

Reviewed-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>


>  arch/x86/include/asm/xen/swiotlb-xen.h |    2 +
>  arch/x86/xen/pci-swiotlb-xen.c         |   22 ++++++++++++++-
>  drivers/xen/swiotlb-xen.c              |   48 +++++++++++++++++++++++++------
>  include/xen/swiotlb-xen.h              |    2 +-
>  4 files changed, 62 insertions(+), 12 deletions(-)
> 
> diff --git a/arch/x86/include/asm/xen/swiotlb-xen.h b/arch/x86/include/asm/xen/swiotlb-xen.h
> index 1be1ab7..ee52fca 100644
> --- a/arch/x86/include/asm/xen/swiotlb-xen.h
> +++ b/arch/x86/include/asm/xen/swiotlb-xen.h
> @@ -5,10 +5,12 @@
>  extern int xen_swiotlb;
>  extern int __init pci_xen_swiotlb_detect(void);
>  extern void __init pci_xen_swiotlb_init(void);
> +extern int pci_xen_swiotlb_init_late(void);
>  #else
>  #define xen_swiotlb (0)
>  static inline int __init pci_xen_swiotlb_detect(void) { return 0; }
>  static inline void __init pci_xen_swiotlb_init(void) { }
> +static inline int pci_xen_swiotlb_init_late(void) { return -ENXIO; }
>  #endif
>  
>  #endif /* _ASM_X86_SWIOTLB_XEN_H */
> diff --git a/arch/x86/xen/pci-swiotlb-xen.c b/arch/x86/xen/pci-swiotlb-xen.c
> index 1c17227..406f9c4 100644
> --- a/arch/x86/xen/pci-swiotlb-xen.c
> +++ b/arch/x86/xen/pci-swiotlb-xen.c
> @@ -12,7 +12,7 @@
>  #include <asm/iommu.h>
>  #include <asm/dma.h>
>  #endif
> -
> +#include <linux/export.h>
>  int xen_swiotlb __read_mostly;
>  
>  static struct dma_map_ops xen_swiotlb_dma_ops = {
> @@ -76,6 +76,26 @@ void __init pci_xen_swiotlb_init(void)
>  		pci_request_acs();
>  	}
>  }
> +
> +int pci_xen_swiotlb_init_late(void)
> +{
> +	int rc;
> +
> +	if (xen_swiotlb)
> +		return 0;
> +
> +	rc = xen_swiotlb_init(1);
> +	if (rc)
> +		return rc;
> +
> +	dma_ops = &xen_swiotlb_dma_ops;
> +	/* Make sure ACS will be enabled */
> +	pci_request_acs();
> +
> +	return 0;
> +}
> +EXPORT_SYMBOL_GPL(pci_xen_swiotlb_init_late);
> +
>  IOMMU_INIT_FINISH(pci_xen_swiotlb_detect,
>  		  0,
>  		  pci_xen_swiotlb_init,
> diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
> index 701b103..f0825cb 100644
> --- a/drivers/xen/swiotlb-xen.c
> +++ b/drivers/xen/swiotlb-xen.c
> @@ -176,9 +176,9 @@ static const char *xen_swiotlb_error(enum xen_swiotlb_err err)
>  	}
>  	return "";
>  }
> -void __init xen_swiotlb_init(int verbose)
> +int __ref xen_swiotlb_init(int verbose)
>  {
> -	unsigned long bytes;
> +	unsigned long bytes, order;
>  	int rc = -ENOMEM;
>  	enum xen_swiotlb_err m_ret = XEN_SWIOTLB_UNKNOWN;
>  	unsigned int repeat = 3;
> @@ -186,10 +186,28 @@ void __init xen_swiotlb_init(int verbose)
>  	xen_io_tlb_nslabs = swiotlb_nr_tbl();
>  retry:
>  	bytes = xen_set_nslabs(xen_io_tlb_nslabs);
> +	order = get_order(xen_io_tlb_nslabs << IO_TLB_SHIFT);
>  	/*
>  	 * Get IO TLB memory from any location.
>  	 */
> -	xen_io_tlb_start = alloc_bootmem_pages(PAGE_ALIGN(bytes));
> +	if (!after_bootmem)
> +		xen_io_tlb_start = alloc_bootmem_pages(PAGE_ALIGN(bytes));
> +	else {
> +#define SLABS_PER_PAGE (1 << (PAGE_SHIFT - IO_TLB_SHIFT))
> +#define IO_TLB_MIN_SLABS ((1<<20) >> IO_TLB_SHIFT)
> +		while ((SLABS_PER_PAGE << order) > IO_TLB_MIN_SLABS) {
> +			xen_io_tlb_start = (void *)__get_free_pages(__GFP_NOWARN, order);
> +			if (xen_io_tlb_start)
> +				break;
> +			order--;
> +		}
> +		if (order != get_order(bytes)) {
> +			pr_warn("Warning: only able to allocate %ld MB "
> +				"for software IO TLB\n", (PAGE_SIZE << order) >> 20);
> +			xen_io_tlb_nslabs = SLABS_PER_PAGE << order;
> +			bytes = xen_io_tlb_nslabs << IO_TLB_SHIFT;
> +		}
> +	}
>  	if (!xen_io_tlb_start) {
>  		m_ret = XEN_SWIOTLB_ENOMEM;
>  		goto error;
> @@ -202,14 +220,21 @@ retry:
>  			       bytes,
>  			       xen_io_tlb_nslabs);
>  	if (rc) {
> -		free_bootmem(__pa(xen_io_tlb_start), PAGE_ALIGN(bytes));
> +		if (!after_bootmem)
> +			free_bootmem(__pa(xen_io_tlb_start), PAGE_ALIGN(bytes));
> +		else {
> +			free_pages((unsigned long)xen_io_tlb_start, order);
> +			xen_io_tlb_start = NULL;
> +		}
>  		m_ret = XEN_SWIOTLB_EFIXUP;
>  		goto error;
>  	}
>  	start_dma_addr = xen_virt_to_bus(xen_io_tlb_start);
> -	swiotlb_init_with_tbl(xen_io_tlb_start, xen_io_tlb_nslabs, verbose);
> -
> -	return;
> +	if (!after_bootmem)
> +		swiotlb_init_with_tbl(xen_io_tlb_start, xen_io_tlb_nslabs, verbose);
> +	else
> +		rc = swiotlb_late_init_with_tbl(xen_io_tlb_start, xen_io_tlb_nslabs);
> +	return rc;
>  error:
>  	if (repeat--) {
>  		xen_io_tlb_nslabs = max(1024UL, /* Min is 2MB */
> @@ -218,10 +243,13 @@ error:
>  		      (xen_io_tlb_nslabs << IO_TLB_SHIFT) >> 20);
>  		goto retry;
>  	}
> -	xen_raw_printk("%s (rc:%d)", xen_swiotlb_error(m_ret), rc);
> -	panic("%s (rc:%d)", xen_swiotlb_error(m_ret), rc);
> +	pr_err("%s (rc:%d)", xen_swiotlb_error(m_ret), rc);
> +	if (!after_bootmem)
> +		panic("%s (rc:%d)", xen_swiotlb_error(m_ret), rc);
> +	else
> +		free_pages((unsigned long)xen_io_tlb_start, order);
> +	return rc;
>  }
> -
>  void *
>  xen_swiotlb_alloc_coherent(struct device *hwdev, size_t size,
>  			   dma_addr_t *dma_handle, gfp_t flags,
> diff --git a/include/xen/swiotlb-xen.h b/include/xen/swiotlb-xen.h
> index 4f4d449..f26f9f3 100644
> --- a/include/xen/swiotlb-xen.h
> +++ b/include/xen/swiotlb-xen.h
> @@ -3,7 +3,7 @@
>  
>  #include <linux/swiotlb.h>
>  
> -extern void xen_swiotlb_init(int verbose);
> +extern int xen_swiotlb_init(int verbose);
>  
>  extern void
>  *xen_swiotlb_alloc_coherent(struct device *hwdev, size_t size,
> -- 
> 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 Sep 14 16:34:19 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 16:34:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TCYqE-0007BX-B4; Fri, 14 Sep 2012 16:34: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 1TCYqC-0007BS-Qb
	for xen-devel@lists.xensource.com; Fri, 14 Sep 2012 16:34:05 +0000
Received: from [85.158.139.211:36296] by server-11.bemta-5.messagelabs.com id
	FF/A6-24658-B7C53505; Fri, 14 Sep 2012 16:34:03 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-16.tower-206.messagelabs.com!1347640443!18637788!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDkyOTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6252 invoked from network); 14 Sep 2012 16:34:03 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Sep 2012 16:34:03 -0000
X-IronPort-AV: E=Sophos;i="4.80,423,1344211200"; d="scan'208";a="14551943"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Sep 2012 16:33: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.279.1; Fri, 14 Sep 2012 17:33: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
	1TCYpt-0000pv-Nv	for xen-devel@lists.xensource.com;
	Fri, 14 Sep 2012 16:33:45 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1TCYpt-00076k-KB	for
	xen-devel@lists.xensource.com; Fri, 14 Sep 2012 17:33:45 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20563.23657.516907.474556@mariner.uk.xensource.com>
Date: Fri, 14 Sep 2012 17:33:45 +0100
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
In-Reply-To: <osstest-13763-mainreport@xen.org>
References: <osstest-13763-mainreport@xen.org>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Subject: Re: [Xen-devel] [qemu-upstream-4.2-testing baseline test] 13763:
	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

xen.org writes ("[qemu-upstream-4.2-testing baseline test] 13763: tolerable FAIL"):
> "Old" tested version had not actually been tested; therefore in this
> flight we test it, rather than a new candidate.  The baseline, if
> any, is the most recent actually tested revision.

This is not, in fact, true.  I have fixed the autotester's
over-cautious analysis of what previous versions have been tested.
However, that change will have to go through the testing system
itself.

In the meantime I'm going to leave the qemu-upstream-4.2-testing
branch un-stopped in the tester, so we will expect to see a few more
of these over the weekend.  It should be sorted out by Monday morning
I hope.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 14 16:34:19 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 16:34:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TCYqE-0007BX-B4; Fri, 14 Sep 2012 16:34: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 1TCYqC-0007BS-Qb
	for xen-devel@lists.xensource.com; Fri, 14 Sep 2012 16:34:05 +0000
Received: from [85.158.139.211:36296] by server-11.bemta-5.messagelabs.com id
	FF/A6-24658-B7C53505; Fri, 14 Sep 2012 16:34:03 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-16.tower-206.messagelabs.com!1347640443!18637788!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDkyOTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6252 invoked from network); 14 Sep 2012 16:34:03 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Sep 2012 16:34:03 -0000
X-IronPort-AV: E=Sophos;i="4.80,423,1344211200"; d="scan'208";a="14551943"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Sep 2012 16:33: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.279.1; Fri, 14 Sep 2012 17:33: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
	1TCYpt-0000pv-Nv	for xen-devel@lists.xensource.com;
	Fri, 14 Sep 2012 16:33:45 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1TCYpt-00076k-KB	for
	xen-devel@lists.xensource.com; Fri, 14 Sep 2012 17:33:45 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20563.23657.516907.474556@mariner.uk.xensource.com>
Date: Fri, 14 Sep 2012 17:33:45 +0100
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
In-Reply-To: <osstest-13763-mainreport@xen.org>
References: <osstest-13763-mainreport@xen.org>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Subject: Re: [Xen-devel] [qemu-upstream-4.2-testing baseline test] 13763:
	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

xen.org writes ("[qemu-upstream-4.2-testing baseline test] 13763: tolerable FAIL"):
> "Old" tested version had not actually been tested; therefore in this
> flight we test it, rather than a new candidate.  The baseline, if
> any, is the most recent actually tested revision.

This is not, in fact, true.  I have fixed the autotester's
over-cautious analysis of what previous versions have been tested.
However, that change will have to go through the testing system
itself.

In the meantime I'm going to leave the qemu-upstream-4.2-testing
branch un-stopped in the tester, so we will expect to see a few more
of these over the weekend.  It should be sorted out by Monday morning
I hope.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 14 17:12:09 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 17:12:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TCZQg-0007jn-IQ; Fri, 14 Sep 2012 17:11:46 +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 1TCZQe-0007jh-Ne
	for xen-devel@lists.xen.org; Fri, 14 Sep 2012 17:11:44 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1347642696!11031758!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDc1MTgyMQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22579 invoked from network); 14 Sep 2012 17:11:38 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-2.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 14 Sep 2012 17:11: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 q8EHBO9D030839
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 14 Sep 2012 17:11:25 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
	q8EHBNur024285
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 14 Sep 2012 17:11:23 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
	q8EHBMd0014039; Fri, 14 Sep 2012 12:11:22 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 14 Sep 2012 10:11:22 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 11DD74032B; Fri, 14 Sep 2012 13:00:42 -0400 (EDT)
Date: Fri, 14 Sep 2012 13:00:42 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Conny Seidel <conny.seidel@amd.com>
Message-ID: <20120914170041.GA1481@phenom.dumpdata.com>
References: <20120904163347.GH23361@phenom.dumpdata.com>
	<143844933.20120904191941@eikelenboom.it>
	<CAOvdn6U_yHgtZwv9MWazdLbd3NLq3pwGXnZY5sL2UVBhV_FUoQ@mail.gmail.com>
	<1813712325.20120904213459@eikelenboom.it>
	<048EAD622912254A9DEA24C1734613C18C864C3C5D@FTLPMAILBOX02.citrite.net>
	<20120905140600.GA5844@phenom.dumpdata.com>
	<alpine.DEB.2.02.1209111652590.15568@kaball.uk.xensource.com>
	<1901811929.20120912122848@eikelenboom.it>
	<20120913133211.GB17060@localhost.localdomain>
	<20120914165333.69aa6626.conny.seidel@amd.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120914165333.69aa6626.conny.seidel@amd.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Konrad Rzeszutek Wilk <konrad@kernel.org>,
	Sander Eikelenboom <linux@eikelenboom.it>, Ben Guthro <ben@guthro.net>,
	Robert Phillips <robert.phillips@citrix.com>
Subject: Re: [Xen-devel] dom0 linux 3.6.0-rc4,
 crash due to ballooning althoug dom0_mem=X, max:X set
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Sep 14, 2012 at 04:53:33PM +0200, Conny Seidel wrote:
> Hi,
> 
> 
> On Thu, 13 Sep 2012 09:32:14 -0400
> Konrad Rzeszutek Wilk <konrad@kernel.org> wrote:
> 
> >> > Sander, could you please let me know if it fixes the problem for
> >> > you?
> >>
> >> It does !
> >>
> >> Tested-By: Sander Eikelenboom <linux@eikelenboom.it>
> >
> >Excellent. Applied. Thx for reporting and testing.
> 
> Is it possible that this patch is backported to stable?

It is on the stable release train.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 14 17:12:09 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 17:12:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TCZQg-0007jn-IQ; Fri, 14 Sep 2012 17:11:46 +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 1TCZQe-0007jh-Ne
	for xen-devel@lists.xen.org; Fri, 14 Sep 2012 17:11:44 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1347642696!11031758!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDc1MTgyMQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22579 invoked from network); 14 Sep 2012 17:11:38 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-2.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 14 Sep 2012 17:11: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 q8EHBO9D030839
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 14 Sep 2012 17:11:25 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
	q8EHBNur024285
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 14 Sep 2012 17:11:23 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
	q8EHBMd0014039; Fri, 14 Sep 2012 12:11:22 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 14 Sep 2012 10:11:22 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 11DD74032B; Fri, 14 Sep 2012 13:00:42 -0400 (EDT)
Date: Fri, 14 Sep 2012 13:00:42 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Conny Seidel <conny.seidel@amd.com>
Message-ID: <20120914170041.GA1481@phenom.dumpdata.com>
References: <20120904163347.GH23361@phenom.dumpdata.com>
	<143844933.20120904191941@eikelenboom.it>
	<CAOvdn6U_yHgtZwv9MWazdLbd3NLq3pwGXnZY5sL2UVBhV_FUoQ@mail.gmail.com>
	<1813712325.20120904213459@eikelenboom.it>
	<048EAD622912254A9DEA24C1734613C18C864C3C5D@FTLPMAILBOX02.citrite.net>
	<20120905140600.GA5844@phenom.dumpdata.com>
	<alpine.DEB.2.02.1209111652590.15568@kaball.uk.xensource.com>
	<1901811929.20120912122848@eikelenboom.it>
	<20120913133211.GB17060@localhost.localdomain>
	<20120914165333.69aa6626.conny.seidel@amd.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120914165333.69aa6626.conny.seidel@amd.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Konrad Rzeszutek Wilk <konrad@kernel.org>,
	Sander Eikelenboom <linux@eikelenboom.it>, Ben Guthro <ben@guthro.net>,
	Robert Phillips <robert.phillips@citrix.com>
Subject: Re: [Xen-devel] dom0 linux 3.6.0-rc4,
 crash due to ballooning althoug dom0_mem=X, max:X set
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Sep 14, 2012 at 04:53:33PM +0200, Conny Seidel wrote:
> Hi,
> 
> 
> On Thu, 13 Sep 2012 09:32:14 -0400
> Konrad Rzeszutek Wilk <konrad@kernel.org> wrote:
> 
> >> > Sander, could you please let me know if it fixes the problem for
> >> > you?
> >>
> >> It does !
> >>
> >> Tested-By: Sander Eikelenboom <linux@eikelenboom.it>
> >
> >Excellent. Applied. Thx for reporting and testing.
> 
> Is it possible that this patch is backported to stable?

It is on the stable release train.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 14 17:17:54 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 17:17: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 1TCZWI-0007ss-Ce; Fri, 14 Sep 2012 17:17:34 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1TCZWH-0007sn-SZ
	for xen-devel@lists.xensource.com; Fri, 14 Sep 2012 17:17:34 +0000
Received: from [85.158.138.51:40110] by server-8.bemta-3.messagelabs.com id
	83/B4-24700-DA663505; Fri, 14 Sep 2012 17:17:33 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1347643050!24258596!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzQxNzU0\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23372 invoked from network); 14 Sep 2012 17:17:32 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-14.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 14 Sep 2012 17:17:32 -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 q8EHHPfQ011069
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 14 Sep 2012 17:17:26 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
	q8EHHOO5016015
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 14 Sep 2012 17:17:25 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
	q8EHHOFF019353; Fri, 14 Sep 2012 12:17:24 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 14 Sep 2012 10:17:24 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 744FC4032B; Fri, 14 Sep 2012 13:06:44 -0400 (EDT)
Date: Fri, 14 Sep 2012 13:06:44 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20120914170644.GC1481@phenom.dumpdata.com>
References: <1347306367-28669-1-git-send-email-konrad.wilk@oracle.com>
	<1347306367-28669-9-git-send-email-konrad.wilk@oracle.com>
	<alpine.DEB.2.02.1209141704330.29232@kaball.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <alpine.DEB.2.02.1209141704330.29232@kaball.uk.xensource.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [Xen-devel] [PATCH 08/10] xen/swiotlb: Remove functions not
	needed anymore.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Sep 14, 2012 at 05:06:16PM +0100, Stefano Stabellini wrote:
> On Mon, 10 Sep 2012, Konrad Rzeszutek Wilk wrote:
> > Sparse warns us off:
> > drivers/xen/swiotlb-xen.c:506:1: warning: symbol 'xen_swiotlb_map_sg' was not declared. Should it be static?
> > drivers/xen/swiotlb-xen.c:534:1: warning: symbol 'xen_swiotlb_unmap_sg' was not declared. Should it be static?
> > 
> > and it looks like we do not need this function at all.
> 
> A grep seems to find them used in arch/x86/xen/pci-swiotlb-xen.c.
> I fail to see where you removed them from pci-swiotlb-xen.c. Is it in
> this patch series or another one?

I am not seeing them in that file. I think you found the
other variant of it:

xen_swiotlb_map_sg_attrs

> 
> 
> > Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> > ---
> >  drivers/xen/swiotlb-xen.c |   16 ----------------
> >  include/xen/swiotlb-xen.h |    9 ---------
> >  2 files changed, 0 insertions(+), 25 deletions(-)
> > 
> > diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
> > index f0825cb..6f81994 100644
> > --- a/drivers/xen/swiotlb-xen.c
> > +++ b/drivers/xen/swiotlb-xen.c
> > @@ -514,14 +514,6 @@ xen_swiotlb_map_sg_attrs(struct device *hwdev, struct scatterlist *sgl,
> >  }
> >  EXPORT_SYMBOL_GPL(xen_swiotlb_map_sg_attrs);
> >  
> > -int
> > -xen_swiotlb_map_sg(struct device *hwdev, struct scatterlist *sgl, int nelems,
> > -		   enum dma_data_direction dir)
> > -{
> > -	return xen_swiotlb_map_sg_attrs(hwdev, sgl, nelems, dir, NULL);
> > -}
> > -EXPORT_SYMBOL_GPL(xen_swiotlb_map_sg);
> > -
> >  /*
> >   * Unmap a set of streaming mode DMA translations.  Again, cpu read rules
> >   * concerning calls here are the same as for swiotlb_unmap_page() above.
> > @@ -542,14 +534,6 @@ xen_swiotlb_unmap_sg_attrs(struct device *hwdev, struct scatterlist *sgl,
> >  }
> >  EXPORT_SYMBOL_GPL(xen_swiotlb_unmap_sg_attrs);
> >  
> > -void
> > -xen_swiotlb_unmap_sg(struct device *hwdev, struct scatterlist *sgl, int nelems,
> > -		     enum dma_data_direction dir)
> > -{
> > -	return xen_swiotlb_unmap_sg_attrs(hwdev, sgl, nelems, dir, NULL);
> > -}
> > -EXPORT_SYMBOL_GPL(xen_swiotlb_unmap_sg);
> > -
> >  /*
> >   * Make physical memory consistent for a set of streaming mode DMA translations
> >   * after a transfer.
> > diff --git a/include/xen/swiotlb-xen.h b/include/xen/swiotlb-xen.h
> > index f26f9f3..a0db2b7 100644
> > --- a/include/xen/swiotlb-xen.h
> > +++ b/include/xen/swiotlb-xen.h
> > @@ -23,15 +23,6 @@ extern dma_addr_t xen_swiotlb_map_page(struct device *dev, struct page *page,
> >  extern void xen_swiotlb_unmap_page(struct device *hwdev, dma_addr_t dev_addr,
> >  				   size_t size, enum dma_data_direction dir,
> >  				   struct dma_attrs *attrs);
> > -/*
> > -extern int
> > -xen_swiotlb_map_sg(struct device *hwdev, struct scatterlist *sg, int nents,
> > -		   enum dma_data_direction dir);
> > -
> > -extern void
> > -xen_swiotlb_unmap_sg(struct device *hwdev, struct scatterlist *sg, int nents,
> > -		     enum dma_data_direction dir);
> > -*/
> >  extern int
> >  xen_swiotlb_map_sg_attrs(struct device *hwdev, struct scatterlist *sgl,
> >  			 int nelems, enum dma_data_direction dir,
> > -- 
> > 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 Sep 14 17:17:54 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 17:17: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 1TCZWI-0007ss-Ce; Fri, 14 Sep 2012 17:17:34 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1TCZWH-0007sn-SZ
	for xen-devel@lists.xensource.com; Fri, 14 Sep 2012 17:17:34 +0000
Received: from [85.158.138.51:40110] by server-8.bemta-3.messagelabs.com id
	83/B4-24700-DA663505; Fri, 14 Sep 2012 17:17:33 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1347643050!24258596!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzQxNzU0\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23372 invoked from network); 14 Sep 2012 17:17:32 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-14.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 14 Sep 2012 17:17:32 -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 q8EHHPfQ011069
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 14 Sep 2012 17:17:26 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
	q8EHHOO5016015
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 14 Sep 2012 17:17:25 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
	q8EHHOFF019353; Fri, 14 Sep 2012 12:17:24 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 14 Sep 2012 10:17:24 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 744FC4032B; Fri, 14 Sep 2012 13:06:44 -0400 (EDT)
Date: Fri, 14 Sep 2012 13:06:44 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20120914170644.GC1481@phenom.dumpdata.com>
References: <1347306367-28669-1-git-send-email-konrad.wilk@oracle.com>
	<1347306367-28669-9-git-send-email-konrad.wilk@oracle.com>
	<alpine.DEB.2.02.1209141704330.29232@kaball.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <alpine.DEB.2.02.1209141704330.29232@kaball.uk.xensource.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [Xen-devel] [PATCH 08/10] xen/swiotlb: Remove functions not
	needed anymore.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Sep 14, 2012 at 05:06:16PM +0100, Stefano Stabellini wrote:
> On Mon, 10 Sep 2012, Konrad Rzeszutek Wilk wrote:
> > Sparse warns us off:
> > drivers/xen/swiotlb-xen.c:506:1: warning: symbol 'xen_swiotlb_map_sg' was not declared. Should it be static?
> > drivers/xen/swiotlb-xen.c:534:1: warning: symbol 'xen_swiotlb_unmap_sg' was not declared. Should it be static?
> > 
> > and it looks like we do not need this function at all.
> 
> A grep seems to find them used in arch/x86/xen/pci-swiotlb-xen.c.
> I fail to see where you removed them from pci-swiotlb-xen.c. Is it in
> this patch series or another one?

I am not seeing them in that file. I think you found the
other variant of it:

xen_swiotlb_map_sg_attrs

> 
> 
> > Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> > ---
> >  drivers/xen/swiotlb-xen.c |   16 ----------------
> >  include/xen/swiotlb-xen.h |    9 ---------
> >  2 files changed, 0 insertions(+), 25 deletions(-)
> > 
> > diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
> > index f0825cb..6f81994 100644
> > --- a/drivers/xen/swiotlb-xen.c
> > +++ b/drivers/xen/swiotlb-xen.c
> > @@ -514,14 +514,6 @@ xen_swiotlb_map_sg_attrs(struct device *hwdev, struct scatterlist *sgl,
> >  }
> >  EXPORT_SYMBOL_GPL(xen_swiotlb_map_sg_attrs);
> >  
> > -int
> > -xen_swiotlb_map_sg(struct device *hwdev, struct scatterlist *sgl, int nelems,
> > -		   enum dma_data_direction dir)
> > -{
> > -	return xen_swiotlb_map_sg_attrs(hwdev, sgl, nelems, dir, NULL);
> > -}
> > -EXPORT_SYMBOL_GPL(xen_swiotlb_map_sg);
> > -
> >  /*
> >   * Unmap a set of streaming mode DMA translations.  Again, cpu read rules
> >   * concerning calls here are the same as for swiotlb_unmap_page() above.
> > @@ -542,14 +534,6 @@ xen_swiotlb_unmap_sg_attrs(struct device *hwdev, struct scatterlist *sgl,
> >  }
> >  EXPORT_SYMBOL_GPL(xen_swiotlb_unmap_sg_attrs);
> >  
> > -void
> > -xen_swiotlb_unmap_sg(struct device *hwdev, struct scatterlist *sgl, int nelems,
> > -		     enum dma_data_direction dir)
> > -{
> > -	return xen_swiotlb_unmap_sg_attrs(hwdev, sgl, nelems, dir, NULL);
> > -}
> > -EXPORT_SYMBOL_GPL(xen_swiotlb_unmap_sg);
> > -
> >  /*
> >   * Make physical memory consistent for a set of streaming mode DMA translations
> >   * after a transfer.
> > diff --git a/include/xen/swiotlb-xen.h b/include/xen/swiotlb-xen.h
> > index f26f9f3..a0db2b7 100644
> > --- a/include/xen/swiotlb-xen.h
> > +++ b/include/xen/swiotlb-xen.h
> > @@ -23,15 +23,6 @@ extern dma_addr_t xen_swiotlb_map_page(struct device *dev, struct page *page,
> >  extern void xen_swiotlb_unmap_page(struct device *hwdev, dma_addr_t dev_addr,
> >  				   size_t size, enum dma_data_direction dir,
> >  				   struct dma_attrs *attrs);
> > -/*
> > -extern int
> > -xen_swiotlb_map_sg(struct device *hwdev, struct scatterlist *sg, int nents,
> > -		   enum dma_data_direction dir);
> > -
> > -extern void
> > -xen_swiotlb_unmap_sg(struct device *hwdev, struct scatterlist *sg, int nents,
> > -		     enum dma_data_direction dir);
> > -*/
> >  extern int
> >  xen_swiotlb_map_sg_attrs(struct device *hwdev, struct scatterlist *sgl,
> >  			 int nelems, enum dma_data_direction dir,
> > -- 
> > 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 Sep 14 17:20:46 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 17: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 1TCZZ5-0007zf-WB; Fri, 14 Sep 2012 17:20:27 +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 1TCZZ4-0007zS-O8
	for xen-devel@lists.xensource.com; Fri, 14 Sep 2012 17:20:26 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1347643219!9641586!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzQxNzU0\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10634 invoked from network); 14 Sep 2012 17:20:20 -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; 14 Sep 2012 17:20:20 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q8EHKGWQ013904
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 14 Sep 2012 17:20:16 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q8EHKFM0020741
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 14 Sep 2012 17:20: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
	q8EHKFRL020413; Fri, 14 Sep 2012 12:20:15 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 14 Sep 2012 10:20:15 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 405924032B; Fri, 14 Sep 2012 13:09:35 -0400 (EDT)
Date: Fri, 14 Sep 2012 13:09:35 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20120914170935.GD1481@phenom.dumpdata.com>
References: <1347306367-28669-1-git-send-email-konrad.wilk@oracle.com>
	<1347306367-28669-11-git-send-email-konrad.wilk@oracle.com>
	<alpine.DEB.2.02.1209141709580.29232@kaball.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <alpine.DEB.2.02.1209141709580.29232@kaball.uk.xensource.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [Xen-devel] [PATCH 10/10] xen/swiotlb: Depending on
 after_bootmem is not 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, Sep 14, 2012 at 05:10:48PM +0100, Stefano Stabellini wrote:
> On Mon, 10 Sep 2012, Konrad Rzeszutek Wilk wrote:
> > When PCI IOMMUs are initialized it is after after_bootmem but
> > before a lot of "other" subsystems are initialized. As such
> > the check for after_bootmem is incorrect and we should
> > just use a parameter to define whether we are early or late.
> > 
> > This solves this bootup problem:
> > 
> > __ex_table already sorted, skipping sortM
> > Initializing CPU#0
> > Warning: only able to allocate 1 MB for software IO TLB
> > Xen-SWIOTLB: Lowering to 2MB
> > Warning: only able to allocate 1 MB for software IO TLB
> > Xen-SWIOTLB: Lowering to 2MB
> > Warning: only able to allocate 1 MB for software IO TLB
> > Xen-SWIOTLB: Lowering to 2MB
> > Warning: only able to allocate 1 MB for software IO TLB
> > Cannot allocate Xen-SWIOTLB buffer (rc:-12)
> > 
> > Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> > ---
> >  arch/x86/xen/pci-swiotlb-xen.c |    4 ++--
> >  drivers/xen/swiotlb-xen.c      |   11 ++++++-----
> >  include/xen/swiotlb-xen.h      |    2 +-
> >  3 files changed, 9 insertions(+), 8 deletions(-)
> > 
> > diff --git a/arch/x86/xen/pci-swiotlb-xen.c b/arch/x86/xen/pci-swiotlb-xen.c
> > index fc0c78f..1608244 100644
> > --- a/arch/x86/xen/pci-swiotlb-xen.c
> > +++ b/arch/x86/xen/pci-swiotlb-xen.c
> > @@ -69,7 +69,7 @@ int __init pci_xen_swiotlb_detect(void)
> >  void __init pci_xen_swiotlb_init(void)
> >  {
> >  	if (xen_swiotlb) {
> > -		xen_swiotlb_init(1);
> > +		xen_swiotlb_init(1, true /* early */);
> >  		dma_ops = &xen_swiotlb_dma_ops;
> >  
> >  		/* Make sure ACS will be enabled */
> > @@ -84,7 +84,7 @@ int pci_xen_swiotlb_init_late(void)
> >  	if (xen_swiotlb)
> >  		return 0;
> >  
> > -	rc = xen_swiotlb_init(1);
> > +	rc = xen_swiotlb_init(1, false /* late */);
> >  	if (rc)
> >  		return rc;
> >  
> > diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
> > index 6f81994..7443e19 100644
> > --- a/drivers/xen/swiotlb-xen.c
> > +++ b/drivers/xen/swiotlb-xen.c
> > @@ -176,7 +176,7 @@ static const char *xen_swiotlb_error(enum xen_swiotlb_err err)
> >  	}
> >  	return "";
> >  }
> > -int __ref xen_swiotlb_init(int verbose)
> > +int __ref xen_swiotlb_init(int verbose, bool early)
> >  {
> >  	unsigned long bytes, order;
> >  	int rc = -ENOMEM;
> > @@ -190,7 +190,7 @@ retry:
> >  	/*
> >  	 * Get IO TLB memory from any location.
> >  	 */
> > -	if (!after_bootmem)
> > +	if (early)
> >  		xen_io_tlb_start = alloc_bootmem_pages(PAGE_ALIGN(bytes));
> >  	else {
> >  #define SLABS_PER_PAGE (1 << (PAGE_SHIFT - IO_TLB_SHIFT))
> > @@ -220,7 +220,7 @@ retry:
> >  			       bytes,
> >  			       xen_io_tlb_nslabs);
> >  	if (rc) {
> > -		if (!after_bootmem)
> > +		if (early)
> >  			free_bootmem(__pa(xen_io_tlb_start), PAGE_ALIGN(bytes));
> >  		else {
> >  			free_pages((unsigned long)xen_io_tlb_start, order);
> > @@ -230,7 +230,8 @@ retry:
> >  		goto error;
> >  	}
> >  	start_dma_addr = xen_virt_to_bus(xen_io_tlb_start);
> > -	if (!after_bootmem)
> > +	rc = 0;
>      ^
> why does this change belong to this patch?

Good eyes. I was being sneaky and rolled it in. But I can't recall why I needed
this. <sigh>

> 
> 
> > +	if (early)
> >  		swiotlb_init_with_tbl(xen_io_tlb_start, xen_io_tlb_nslabs, verbose);
> >  	else
> >  		rc = swiotlb_late_init_with_tbl(xen_io_tlb_start, xen_io_tlb_nslabs);
> > @@ -244,7 +245,7 @@ error:
> >  		goto retry;
> >  	}
> >  	pr_err("%s (rc:%d)", xen_swiotlb_error(m_ret), rc);
> > -	if (!after_bootmem)
> > +	if (early)
> >  		panic("%s (rc:%d)", xen_swiotlb_error(m_ret), rc);
> >  	else
> >  		free_pages((unsigned long)xen_io_tlb_start, order);
> > diff --git a/include/xen/swiotlb-xen.h b/include/xen/swiotlb-xen.h
> > index a0db2b7..de8bcc6 100644
> > --- a/include/xen/swiotlb-xen.h
> > +++ b/include/xen/swiotlb-xen.h
> > @@ -3,7 +3,7 @@
> >  
> >  #include <linux/swiotlb.h>
> >  
> > -extern int xen_swiotlb_init(int verbose);
> > +extern int xen_swiotlb_init(int verbose, bool early);
> >  
> >  extern void
> >  *xen_swiotlb_alloc_coherent(struct device *hwdev, size_t size,
> > -- 
> > 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 Sep 14 17:20:46 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 17: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 1TCZZ5-0007zf-WB; Fri, 14 Sep 2012 17:20:27 +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 1TCZZ4-0007zS-O8
	for xen-devel@lists.xensource.com; Fri, 14 Sep 2012 17:20:26 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1347643219!9641586!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzQxNzU0\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10634 invoked from network); 14 Sep 2012 17:20:20 -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; 14 Sep 2012 17:20:20 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q8EHKGWQ013904
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 14 Sep 2012 17:20:16 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q8EHKFM0020741
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 14 Sep 2012 17:20: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
	q8EHKFRL020413; Fri, 14 Sep 2012 12:20:15 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 14 Sep 2012 10:20:15 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 405924032B; Fri, 14 Sep 2012 13:09:35 -0400 (EDT)
Date: Fri, 14 Sep 2012 13:09:35 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20120914170935.GD1481@phenom.dumpdata.com>
References: <1347306367-28669-1-git-send-email-konrad.wilk@oracle.com>
	<1347306367-28669-11-git-send-email-konrad.wilk@oracle.com>
	<alpine.DEB.2.02.1209141709580.29232@kaball.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <alpine.DEB.2.02.1209141709580.29232@kaball.uk.xensource.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [Xen-devel] [PATCH 10/10] xen/swiotlb: Depending on
 after_bootmem is not 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, Sep 14, 2012 at 05:10:48PM +0100, Stefano Stabellini wrote:
> On Mon, 10 Sep 2012, Konrad Rzeszutek Wilk wrote:
> > When PCI IOMMUs are initialized it is after after_bootmem but
> > before a lot of "other" subsystems are initialized. As such
> > the check for after_bootmem is incorrect and we should
> > just use a parameter to define whether we are early or late.
> > 
> > This solves this bootup problem:
> > 
> > __ex_table already sorted, skipping sortM
> > Initializing CPU#0
> > Warning: only able to allocate 1 MB for software IO TLB
> > Xen-SWIOTLB: Lowering to 2MB
> > Warning: only able to allocate 1 MB for software IO TLB
> > Xen-SWIOTLB: Lowering to 2MB
> > Warning: only able to allocate 1 MB for software IO TLB
> > Xen-SWIOTLB: Lowering to 2MB
> > Warning: only able to allocate 1 MB for software IO TLB
> > Cannot allocate Xen-SWIOTLB buffer (rc:-12)
> > 
> > Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> > ---
> >  arch/x86/xen/pci-swiotlb-xen.c |    4 ++--
> >  drivers/xen/swiotlb-xen.c      |   11 ++++++-----
> >  include/xen/swiotlb-xen.h      |    2 +-
> >  3 files changed, 9 insertions(+), 8 deletions(-)
> > 
> > diff --git a/arch/x86/xen/pci-swiotlb-xen.c b/arch/x86/xen/pci-swiotlb-xen.c
> > index fc0c78f..1608244 100644
> > --- a/arch/x86/xen/pci-swiotlb-xen.c
> > +++ b/arch/x86/xen/pci-swiotlb-xen.c
> > @@ -69,7 +69,7 @@ int __init pci_xen_swiotlb_detect(void)
> >  void __init pci_xen_swiotlb_init(void)
> >  {
> >  	if (xen_swiotlb) {
> > -		xen_swiotlb_init(1);
> > +		xen_swiotlb_init(1, true /* early */);
> >  		dma_ops = &xen_swiotlb_dma_ops;
> >  
> >  		/* Make sure ACS will be enabled */
> > @@ -84,7 +84,7 @@ int pci_xen_swiotlb_init_late(void)
> >  	if (xen_swiotlb)
> >  		return 0;
> >  
> > -	rc = xen_swiotlb_init(1);
> > +	rc = xen_swiotlb_init(1, false /* late */);
> >  	if (rc)
> >  		return rc;
> >  
> > diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
> > index 6f81994..7443e19 100644
> > --- a/drivers/xen/swiotlb-xen.c
> > +++ b/drivers/xen/swiotlb-xen.c
> > @@ -176,7 +176,7 @@ static const char *xen_swiotlb_error(enum xen_swiotlb_err err)
> >  	}
> >  	return "";
> >  }
> > -int __ref xen_swiotlb_init(int verbose)
> > +int __ref xen_swiotlb_init(int verbose, bool early)
> >  {
> >  	unsigned long bytes, order;
> >  	int rc = -ENOMEM;
> > @@ -190,7 +190,7 @@ retry:
> >  	/*
> >  	 * Get IO TLB memory from any location.
> >  	 */
> > -	if (!after_bootmem)
> > +	if (early)
> >  		xen_io_tlb_start = alloc_bootmem_pages(PAGE_ALIGN(bytes));
> >  	else {
> >  #define SLABS_PER_PAGE (1 << (PAGE_SHIFT - IO_TLB_SHIFT))
> > @@ -220,7 +220,7 @@ retry:
> >  			       bytes,
> >  			       xen_io_tlb_nslabs);
> >  	if (rc) {
> > -		if (!after_bootmem)
> > +		if (early)
> >  			free_bootmem(__pa(xen_io_tlb_start), PAGE_ALIGN(bytes));
> >  		else {
> >  			free_pages((unsigned long)xen_io_tlb_start, order);
> > @@ -230,7 +230,8 @@ retry:
> >  		goto error;
> >  	}
> >  	start_dma_addr = xen_virt_to_bus(xen_io_tlb_start);
> > -	if (!after_bootmem)
> > +	rc = 0;
>      ^
> why does this change belong to this patch?

Good eyes. I was being sneaky and rolled it in. But I can't recall why I needed
this. <sigh>

> 
> 
> > +	if (early)
> >  		swiotlb_init_with_tbl(xen_io_tlb_start, xen_io_tlb_nslabs, verbose);
> >  	else
> >  		rc = swiotlb_late_init_with_tbl(xen_io_tlb_start, xen_io_tlb_nslabs);
> > @@ -244,7 +245,7 @@ error:
> >  		goto retry;
> >  	}
> >  	pr_err("%s (rc:%d)", xen_swiotlb_error(m_ret), rc);
> > -	if (!after_bootmem)
> > +	if (early)
> >  		panic("%s (rc:%d)", xen_swiotlb_error(m_ret), rc);
> >  	else
> >  		free_pages((unsigned long)xen_io_tlb_start, order);
> > diff --git a/include/xen/swiotlb-xen.h b/include/xen/swiotlb-xen.h
> > index a0db2b7..de8bcc6 100644
> > --- a/include/xen/swiotlb-xen.h
> > +++ b/include/xen/swiotlb-xen.h
> > @@ -3,7 +3,7 @@
> >  
> >  #include <linux/swiotlb.h>
> >  
> > -extern int xen_swiotlb_init(int verbose);
> > +extern int xen_swiotlb_init(int verbose, bool early);
> >  
> >  extern void
> >  *xen_swiotlb_alloc_coherent(struct device *hwdev, size_t size,
> > -- 
> > 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 Sep 14 17:37:37 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 17: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 1TCZpN-0008Pd-Js; Fri, 14 Sep 2012 17:37:17 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Conny.Seidel@amd.com>) id 1TCZpL-0008PY-Vk
	for xen-devel@lists.xen.org; Fri, 14 Sep 2012 17:37:16 +0000
Received: from [85.158.138.51:41229] by server-12.bemta-3.messagelabs.com id
	CA/73-10384-B4B63505; Fri, 14 Sep 2012 17:37:15 +0000
X-Env-Sender: Conny.Seidel@amd.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1347644233!30550819!1
X-Originating-IP: [216.32.181.181]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27702 invoked from network); 14 Sep 2012 17:37:14 -0000
Received: from ch1ehsobe001.messaging.microsoft.com (HELO
	ch1outboundpool.messaging.microsoft.com) (216.32.181.181)
	by server-8.tower-174.messagelabs.com with AES128-SHA encrypted SMTP;
	14 Sep 2012 17:37:14 -0000
Received: from mail15-ch1-R.bigfish.com (10.43.68.235) by
	CH1EHSOBE011.bigfish.com (10.43.70.61) with Microsoft SMTP Server id
	14.1.225.23; Fri, 14 Sep 2012 17:37:12 +0000
Received: from mail15-ch1 (localhost [127.0.0.1])	by mail15-ch1-R.bigfish.com
	(Postfix) with ESMTP id 9885A22013C;
	Fri, 14 Sep 2012 17:37:12 +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(zz98dI1be0I1432Izz1202h1d1ah1d2ahzz8275bh8275dh15d4Iz2dh668h839hd24he5bhf0ah107ah1288h12a5h12bdh34h1155h)
Received: from mail15-ch1 (localhost.localdomain [127.0.0.1]) by mail15-ch1
	(MessageSwitch) id 1347644230894305_31407;
	Fri, 14 Sep 2012 17:37:10 +0000 (UTC)
Received: from CH1EHSMHS029.bigfish.com (snatpool2.int.messaging.microsoft.com
	[10.43.68.230])	by mail15-ch1.bigfish.com (Postfix) with ESMTP id
	CC243160144;	Fri, 14 Sep 2012 17:37:10 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	CH1EHSMHS029.bigfish.com (10.43.70.29) with Microsoft SMTP Server id
	14.1.225.23; Fri, 14 Sep 2012 17:37:10 +0000
X-WSS-ID: 0MACOXW-01-3EU-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 242781028115;	Fri, 14 Sep 2012 12:37:08 -0500 (CDT)
Received: from SAUSEXDAG01.amd.com (163.181.55.1) by sausexedgep02.amd.com
	(163.181.36.59) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Fri, 14 Sep 2012 12:51:02 -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, 14 Sep 2012 12:37:07 -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, 14 Sep 2012
	13:37:07 -0400
Received: from marah.osrc.amd.com (marah.osrc.amd.com [165.204.15.125])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id 081F449C5E4; Fri, 14 Sep 2012
	18:37:02 +0100 (BST)
Date: Fri, 14 Sep 2012 19:38:54 +0200
From: Conny Seidel <conny.seidel@amd.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Message-ID: <20120914193854.6dea5213.conny.seidel@amd.com>
In-Reply-To: <20120914170041.GA1481@phenom.dumpdata.com>
References: <20120904163347.GH23361@phenom.dumpdata.com>
	<143844933.20120904191941@eikelenboom.it>
	<CAOvdn6U_yHgtZwv9MWazdLbd3NLq3pwGXnZY5sL2UVBhV_FUoQ@mail.gmail.com>
	<1813712325.20120904213459@eikelenboom.it>
	<048EAD622912254A9DEA24C1734613C18C864C3C5D@FTLPMAILBOX02.citrite.net>
	<20120905140600.GA5844@phenom.dumpdata.com>
	<alpine.DEB.2.02.1209111652590.15568@kaball.uk.xensource.com>
	<1901811929.20120912122848@eikelenboom.it>
	<20120913133211.GB17060@localhost.localdomain>
	<20120914165333.69aa6626.conny.seidel@amd.com>
	<20120914170041.GA1481@phenom.dumpdata.com>
Organization: Advanced Micro Devices GmbH; Einsteinring 24; 85609 Dornach
	bei Muenchen; Geschaeftsfuehrer: Alberto Bozzo; Sitz: Dornach, Gemeinde
	Aschheim, Landkreis Muenchen; Registergericht Muenchen, HRB Nr. 43632
X-Mailer: Claws Mail 3.8.1cvs53 (GTK+ 2.24.10; x86_64-pc-linux-gnu)
MIME-Version: 1.0
X-OriginatorOrg: amd.com
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Konrad Rzeszutek Wilk <konrad@kernel.org>,
	Sander Eikelenboom <linux@eikelenboom.it>, Ben Guthro <ben@guthro.net>,
	Robert Phillips <robert.phillips@citrix.com>
Subject: Re: [Xen-devel] dom0 linux 3.6.0-rc4,
 crash due to ballooning althoug dom0_mem=X, max:X 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="===============5736315644951427726=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============5736315644951427726==
Content-Type: multipart/signed; micalg=PGP-SHA1;
	boundary="Sig_/LvAPvDyy3U5/stJdtG/7VPq";
	protocol="application/pgp-signature"

--Sig_/LvAPvDyy3U5/stJdtG/7VPq
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

On Fri, 14 Sep 2012 13:00:42 -0400
Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:

>On Fri, Sep 14, 2012 at 04:53:33PM +0200, Conny Seidel wrote:
>> Hi,
>>
>>
>> On Thu, 13 Sep 2012 09:32:14 -0400
>> Konrad Rzeszutek Wilk <konrad@kernel.org> wrote:
>>
>> >> > Sander, could you please let me know if it fixes the problem for
>> >> > you?
>> >>
>> >> It does !
>> >>
>> >> Tested-By: Sander Eikelenboom <linux@eikelenboom.it>
>> >
>> >Excellent. Applied. Thx for reporting and testing.
>>
>> Is it possible that this patch is backported to stable?
>
>It is on the stable release train.
>
Thank you, thats nice to know.

--
Kind regards.

Conny Seidel

##################################################################
# Email : conny.seidel@amd.com            GnuPG-Key : 0xA6AB055D #
# Fingerprint: 17C4 5DB2 7C4C C1C7 1452 8148 F139 7C09 A6AB 055D #
##################################################################
# Advanced Micro Devices GmbH Einsteinring 24 85609 Dornach      #
# General Managers: Alberto Bozzo                                #
# Registration: Dornach, Landkr. Muenchen; Registerger. Muenchen #
#               HRB Nr. 43632                                    #
##################################################################

--Sig_/LvAPvDyy3U5/stJdtG/7VPq
Content-Type: application/pgp-signature; name="signature.asc"
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlBTa64ACgkQ8Tl8CaarBV2TDwCg5x+YhBxvv4xwaYQb+FQo11B6
cfQAnRYCsX4WMdB8DBln0+atZ7IpMFpL
=yJgh
-----END PGP SIGNATURE-----

--Sig_/LvAPvDyy3U5/stJdtG/7VPq--


--===============5736315644951427726==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============5736315644951427726==--


From xen-devel-bounces@lists.xen.org Fri Sep 14 17:37:37 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 17: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 1TCZpN-0008Pd-Js; Fri, 14 Sep 2012 17:37:17 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Conny.Seidel@amd.com>) id 1TCZpL-0008PY-Vk
	for xen-devel@lists.xen.org; Fri, 14 Sep 2012 17:37:16 +0000
Received: from [85.158.138.51:41229] by server-12.bemta-3.messagelabs.com id
	CA/73-10384-B4B63505; Fri, 14 Sep 2012 17:37:15 +0000
X-Env-Sender: Conny.Seidel@amd.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1347644233!30550819!1
X-Originating-IP: [216.32.181.181]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27702 invoked from network); 14 Sep 2012 17:37:14 -0000
Received: from ch1ehsobe001.messaging.microsoft.com (HELO
	ch1outboundpool.messaging.microsoft.com) (216.32.181.181)
	by server-8.tower-174.messagelabs.com with AES128-SHA encrypted SMTP;
	14 Sep 2012 17:37:14 -0000
Received: from mail15-ch1-R.bigfish.com (10.43.68.235) by
	CH1EHSOBE011.bigfish.com (10.43.70.61) with Microsoft SMTP Server id
	14.1.225.23; Fri, 14 Sep 2012 17:37:12 +0000
Received: from mail15-ch1 (localhost [127.0.0.1])	by mail15-ch1-R.bigfish.com
	(Postfix) with ESMTP id 9885A22013C;
	Fri, 14 Sep 2012 17:37:12 +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(zz98dI1be0I1432Izz1202h1d1ah1d2ahzz8275bh8275dh15d4Iz2dh668h839hd24he5bhf0ah107ah1288h12a5h12bdh34h1155h)
Received: from mail15-ch1 (localhost.localdomain [127.0.0.1]) by mail15-ch1
	(MessageSwitch) id 1347644230894305_31407;
	Fri, 14 Sep 2012 17:37:10 +0000 (UTC)
Received: from CH1EHSMHS029.bigfish.com (snatpool2.int.messaging.microsoft.com
	[10.43.68.230])	by mail15-ch1.bigfish.com (Postfix) with ESMTP id
	CC243160144;	Fri, 14 Sep 2012 17:37:10 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	CH1EHSMHS029.bigfish.com (10.43.70.29) with Microsoft SMTP Server id
	14.1.225.23; Fri, 14 Sep 2012 17:37:10 +0000
X-WSS-ID: 0MACOXW-01-3EU-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 242781028115;	Fri, 14 Sep 2012 12:37:08 -0500 (CDT)
Received: from SAUSEXDAG01.amd.com (163.181.55.1) by sausexedgep02.amd.com
	(163.181.36.59) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Fri, 14 Sep 2012 12:51:02 -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, 14 Sep 2012 12:37:07 -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, 14 Sep 2012
	13:37:07 -0400
Received: from marah.osrc.amd.com (marah.osrc.amd.com [165.204.15.125])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id 081F449C5E4; Fri, 14 Sep 2012
	18:37:02 +0100 (BST)
Date: Fri, 14 Sep 2012 19:38:54 +0200
From: Conny Seidel <conny.seidel@amd.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Message-ID: <20120914193854.6dea5213.conny.seidel@amd.com>
In-Reply-To: <20120914170041.GA1481@phenom.dumpdata.com>
References: <20120904163347.GH23361@phenom.dumpdata.com>
	<143844933.20120904191941@eikelenboom.it>
	<CAOvdn6U_yHgtZwv9MWazdLbd3NLq3pwGXnZY5sL2UVBhV_FUoQ@mail.gmail.com>
	<1813712325.20120904213459@eikelenboom.it>
	<048EAD622912254A9DEA24C1734613C18C864C3C5D@FTLPMAILBOX02.citrite.net>
	<20120905140600.GA5844@phenom.dumpdata.com>
	<alpine.DEB.2.02.1209111652590.15568@kaball.uk.xensource.com>
	<1901811929.20120912122848@eikelenboom.it>
	<20120913133211.GB17060@localhost.localdomain>
	<20120914165333.69aa6626.conny.seidel@amd.com>
	<20120914170041.GA1481@phenom.dumpdata.com>
Organization: Advanced Micro Devices GmbH; Einsteinring 24; 85609 Dornach
	bei Muenchen; Geschaeftsfuehrer: Alberto Bozzo; Sitz: Dornach, Gemeinde
	Aschheim, Landkreis Muenchen; Registergericht Muenchen, HRB Nr. 43632
X-Mailer: Claws Mail 3.8.1cvs53 (GTK+ 2.24.10; x86_64-pc-linux-gnu)
MIME-Version: 1.0
X-OriginatorOrg: amd.com
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Konrad Rzeszutek Wilk <konrad@kernel.org>,
	Sander Eikelenboom <linux@eikelenboom.it>, Ben Guthro <ben@guthro.net>,
	Robert Phillips <robert.phillips@citrix.com>
Subject: Re: [Xen-devel] dom0 linux 3.6.0-rc4,
 crash due to ballooning althoug dom0_mem=X, max:X 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="===============5736315644951427726=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============5736315644951427726==
Content-Type: multipart/signed; micalg=PGP-SHA1;
	boundary="Sig_/LvAPvDyy3U5/stJdtG/7VPq";
	protocol="application/pgp-signature"

--Sig_/LvAPvDyy3U5/stJdtG/7VPq
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

On Fri, 14 Sep 2012 13:00:42 -0400
Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:

>On Fri, Sep 14, 2012 at 04:53:33PM +0200, Conny Seidel wrote:
>> Hi,
>>
>>
>> On Thu, 13 Sep 2012 09:32:14 -0400
>> Konrad Rzeszutek Wilk <konrad@kernel.org> wrote:
>>
>> >> > Sander, could you please let me know if it fixes the problem for
>> >> > you?
>> >>
>> >> It does !
>> >>
>> >> Tested-By: Sander Eikelenboom <linux@eikelenboom.it>
>> >
>> >Excellent. Applied. Thx for reporting and testing.
>>
>> Is it possible that this patch is backported to stable?
>
>It is on the stable release train.
>
Thank you, thats nice to know.

--
Kind regards.

Conny Seidel

##################################################################
# Email : conny.seidel@amd.com            GnuPG-Key : 0xA6AB055D #
# Fingerprint: 17C4 5DB2 7C4C C1C7 1452 8148 F139 7C09 A6AB 055D #
##################################################################
# Advanced Micro Devices GmbH Einsteinring 24 85609 Dornach      #
# General Managers: Alberto Bozzo                                #
# Registration: Dornach, Landkr. Muenchen; Registerger. Muenchen #
#               HRB Nr. 43632                                    #
##################################################################

--Sig_/LvAPvDyy3U5/stJdtG/7VPq
Content-Type: application/pgp-signature; name="signature.asc"
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlBTa64ACgkQ8Tl8CaarBV2TDwCg5x+YhBxvv4xwaYQb+FQo11B6
cfQAnRYCsX4WMdB8DBln0+atZ7IpMFpL
=yJgh
-----END PGP SIGNATURE-----

--Sig_/LvAPvDyy3U5/stJdtG/7VPq--


--===============5736315644951427726==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============5736315644951427726==--


From xen-devel-bounces@lists.xen.org Fri Sep 14 19:10:07 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 19: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 1TCbGm-0001Xy-D4; Fri, 14 Sep 2012 19:09:40 +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 1TCbGk-0001Xt-9v
	for xen-devel@lists.xen.org; Fri, 14 Sep 2012 19:09:38 +0000
Received: from [85.158.139.211:24587] by server-4.bemta-5.messagelabs.com id
	1D/A9-23042-1F083505; Fri, 14 Sep 2012 19:09:37 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-11.tower-206.messagelabs.com!1347649775!18621915!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzQxNzU0\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 549 invoked from network); 14 Sep 2012 19:09:36 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-11.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 14 Sep 2012 19:09:36 -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 q8EJ9AmH023431
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 14 Sep 2012 19:09:11 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
	q8EJ963F028595
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 14 Sep 2012 19:09:08 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
	q8EJ92Ih026678; Fri, 14 Sep 2012 14:09:03 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 14 Sep 2012 12:09:02 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 033EB4032B; Fri, 14 Sep 2012 14:58:22 -0400 (EDT)
Date: Fri, 14 Sep 2012 14:58:22 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Konrad Rzeszutek Wilk <konrad@darnok.org>
Message-ID: <20120914185822.GA7495@phenom.dumpdata.com>
References: <501BC20F.3040205@amd.com>
	<20120803123628.GB10670@andromeda.dapyr.net>
	<20120817142237.GA8467@phenom.dumpdata.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120817142237.GA8467@phenom.dumpdata.com>
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 Fitzhardinge <jeremy@goop.org>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Dom0 crash with old style AMD NUMA detection
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> > > [    0.000000] Kernel panic - not syncing: Attempted to kill the idle task!
> > > (XEN) Domain 0 crashed: 'noreboot' set - not rebooting.
> > > 
> > > 
> > > 
> > > The obvious solution would be to explicitly deny northbridge scanning 
> > > when running as Dom0, though I am not sure how to implement this without 
> > > upsetting the other kernel folks about "that crappy Xen thing" again ;-)
> > 
> > Heh.
> > Is there a numa=0 option that could be used to override it to turn it
> > off?
> 
> Not compile tested.. but was thinking something like this:

ping?
> 
> diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c
> index 43fd630..838cc1f 100644
> --- a/arch/x86/xen/setup.c
> +++ b/arch/x86/xen/setup.c
> @@ -17,6 +17,7 @@
>  #include <asm/e820.h>
>  #include <asm/setup.h>
>  #include <asm/acpi.h>
> +#include <asm/numa.h>
>  #include <asm/xen/hypervisor.h>
>  #include <asm/xen/hypercall.h>
>  
> @@ -528,4 +529,7 @@ void __init xen_arch_setup(void)
>  	disable_cpufreq();
>  	WARN_ON(set_pm_idle_to_default());
>  	fiddle_vdso();
> +#ifdef CONFIG_NUMA
> +	numa_off = 1;
> +#endif
>  }

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 14 19:10:07 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 19: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 1TCbGm-0001Xy-D4; Fri, 14 Sep 2012 19:09:40 +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 1TCbGk-0001Xt-9v
	for xen-devel@lists.xen.org; Fri, 14 Sep 2012 19:09:38 +0000
Received: from [85.158.139.211:24587] by server-4.bemta-5.messagelabs.com id
	1D/A9-23042-1F083505; Fri, 14 Sep 2012 19:09:37 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-11.tower-206.messagelabs.com!1347649775!18621915!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzQxNzU0\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 549 invoked from network); 14 Sep 2012 19:09:36 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-11.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 14 Sep 2012 19:09:36 -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 q8EJ9AmH023431
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 14 Sep 2012 19:09:11 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
	q8EJ963F028595
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 14 Sep 2012 19:09:08 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
	q8EJ92Ih026678; Fri, 14 Sep 2012 14:09:03 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 14 Sep 2012 12:09:02 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 033EB4032B; Fri, 14 Sep 2012 14:58:22 -0400 (EDT)
Date: Fri, 14 Sep 2012 14:58:22 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Konrad Rzeszutek Wilk <konrad@darnok.org>
Message-ID: <20120914185822.GA7495@phenom.dumpdata.com>
References: <501BC20F.3040205@amd.com>
	<20120803123628.GB10670@andromeda.dapyr.net>
	<20120817142237.GA8467@phenom.dumpdata.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120817142237.GA8467@phenom.dumpdata.com>
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 Fitzhardinge <jeremy@goop.org>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Dom0 crash with old style AMD NUMA detection
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> > > [    0.000000] Kernel panic - not syncing: Attempted to kill the idle task!
> > > (XEN) Domain 0 crashed: 'noreboot' set - not rebooting.
> > > 
> > > 
> > > 
> > > The obvious solution would be to explicitly deny northbridge scanning 
> > > when running as Dom0, though I am not sure how to implement this without 
> > > upsetting the other kernel folks about "that crappy Xen thing" again ;-)
> > 
> > Heh.
> > Is there a numa=0 option that could be used to override it to turn it
> > off?
> 
> Not compile tested.. but was thinking something like this:

ping?
> 
> diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c
> index 43fd630..838cc1f 100644
> --- a/arch/x86/xen/setup.c
> +++ b/arch/x86/xen/setup.c
> @@ -17,6 +17,7 @@
>  #include <asm/e820.h>
>  #include <asm/setup.h>
>  #include <asm/acpi.h>
> +#include <asm/numa.h>
>  #include <asm/xen/hypervisor.h>
>  #include <asm/xen/hypercall.h>
>  
> @@ -528,4 +529,7 @@ void __init xen_arch_setup(void)
>  	disable_cpufreq();
>  	WARN_ON(set_pm_idle_to_default());
>  	fiddle_vdso();
> +#ifdef CONFIG_NUMA
> +	numa_off = 1;
> +#endif
>  }

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 14 20:13:52 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 20: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 1TCcGJ-00027l-Nm; Fri, 14 Sep 2012 20:13:15 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <sshtylyov@mvista.com>) id 1TCaUB-0000lg-4l
	for xen-devel@lists.xensource.com; Fri, 14 Sep 2012 18:19:27 +0000
Received: from [85.158.143.99:55990] by server-3.bemta-4.messagelabs.com id
	96/2E-08232-E2573505; Fri, 14 Sep 2012 18:19:26 +0000
X-Env-Sender: sshtylyov@mvista.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1347646765!25120523!1
X-Originating-IP: [209.85.215.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16592 invoked from network); 14 Sep 2012 18:19:25 -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;
	14 Sep 2012 18:19:25 -0000
Received: by lagm14 with SMTP id m14so3455531lag.30
	for <xen-devel@lists.xensource.com>;
	Fri, 14 Sep 2012 11:19:25 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=message-id:date:from:user-agent:mime-version:to:cc:subject
	:references:in-reply-to:content-type:content-transfer-encoding
	:x-gm-message-state;
	bh=2KGmnQCkS1CCI9jKuh3vY3IXhOzagA7TIstmVfSMzl4=;
	b=frmH93Bsyr1Og2cuZK28Kp3ncvCCRmyd8pT9tqMzvoUbuurBvygQH0EY1NWtQPmfMt
	l0/esIbYJvpx9+dMSfI7pkAnDsiXqWvY6MD/9UiNRylS5FVrmlVAjjo/fnrZ/xWARTQo
	CC6jsxMJg1eB5/e7zn8dZEL7ZkhFrso8Uen4v4WTDJq2TtRm4EQWV7PlPoLzhbH/BVP0
	1j0DgX5VWHOSZo15AAaaDjBRgtOmzlsDgoM1vlmNDJ98aNBiqkA9/56ukHCDEkte0adn
	jWBMR9iJsjIjuX1mrVqSxFqkQARUNq6E/LRwruWy0voNrqEUbUzRcSX+vS3EZIjRKFcl
	hZ1g==
Received: by 10.152.131.37 with SMTP id oj5mr3192053lab.14.1347646764933;
	Fri, 14 Sep 2012 11:19:24 -0700 (PDT)
Received: from [192.168.11.174] (mail.dev.rtsoft.ru. [213.79.90.226])
	by mx.google.com with ESMTPS id nf5sm727180lab.3.2012.09.14.11.19.22
	(version=TLSv1/SSLv3 cipher=OTHER);
	Fri, 14 Sep 2012 11:19:23 -0700 (PDT)
Message-ID: <505374E2.5080308@mvista.com>
Date: Fri, 14 Sep 2012 22:18:10 +0400
From: Sergei Shtylyov <sshtylyov@mvista.com>
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:15.0) Gecko/20120824 Thunderbird/15.0
MIME-Version: 1.0
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.02.1209141145150.29232@kaball.uk.xensource.com>
	<1347621207-11294-12-git-send-email-stefano.stabellini@eu.citrix.com>
In-Reply-To: <1347621207-11294-12-git-send-email-stefano.stabellini@eu.citrix.com>
X-Gm-Message-State: ALoCoQm6WH5ReUVQc3MZiLNXT6oertZmcbVyS75DhX/rXWh1zSj+t7MVHL3139Vu8JtJeHaUC+zD
X-Mailman-Approved-At: Fri, 14 Sep 2012 20:13:14 +0000
Cc: xen-devel@lists.xensource.com, linaro-dev@lists.linaro.org,
	Ian.Campbell@citrix.com, arnd@arndb.de, konrad.wilk@oracle.com,
	catalin.marinas@arm.com, tim@xen.org,
	linux-kernel@vger.kernel.org, linux@arm.linux.org.uk,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [Xen-devel] [PATCH v4 12/24] xen/arm: introduce CONFIG_XEN on
	ARM
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hello.

On 09/14/2012 03:13 PM, Stefano Stabellini wrote:

> Changes in v2:

> - mark Xen guest support on ARM as EXPERIMENTAL.

> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> ---
>  arch/arm/Kconfig |   10 ++++++++++
>  1 files changed, 10 insertions(+), 0 deletions(-)

> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index 2f88d8d..e92518d 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -1897,6 +1897,16 @@ config DEPRECATED_PARAM_STRUCT
>  	  This was deprecated in 2001 and announced to live on for 5 years.
>  	  Some old boot loaders still use this way.
>  
> +config XEN_DOM0
> +	def_bool y
> +
> +config XEN
> +	bool "Xen guest support on ARM (EXPERIMENTAL)"
> +	depends on EXPERIMENTAL && ARM && OF
> +	select XEN_DOM0

   What's the point of selecting it if it's always "y"?

WBR, Sergei


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 14 20:13:52 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 20: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 1TCcGJ-00027l-Nm; Fri, 14 Sep 2012 20:13:15 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <sshtylyov@mvista.com>) id 1TCaUB-0000lg-4l
	for xen-devel@lists.xensource.com; Fri, 14 Sep 2012 18:19:27 +0000
Received: from [85.158.143.99:55990] by server-3.bemta-4.messagelabs.com id
	96/2E-08232-E2573505; Fri, 14 Sep 2012 18:19:26 +0000
X-Env-Sender: sshtylyov@mvista.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1347646765!25120523!1
X-Originating-IP: [209.85.215.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16592 invoked from network); 14 Sep 2012 18:19:25 -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;
	14 Sep 2012 18:19:25 -0000
Received: by lagm14 with SMTP id m14so3455531lag.30
	for <xen-devel@lists.xensource.com>;
	Fri, 14 Sep 2012 11:19:25 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=message-id:date:from:user-agent:mime-version:to:cc:subject
	:references:in-reply-to:content-type:content-transfer-encoding
	:x-gm-message-state;
	bh=2KGmnQCkS1CCI9jKuh3vY3IXhOzagA7TIstmVfSMzl4=;
	b=frmH93Bsyr1Og2cuZK28Kp3ncvCCRmyd8pT9tqMzvoUbuurBvygQH0EY1NWtQPmfMt
	l0/esIbYJvpx9+dMSfI7pkAnDsiXqWvY6MD/9UiNRylS5FVrmlVAjjo/fnrZ/xWARTQo
	CC6jsxMJg1eB5/e7zn8dZEL7ZkhFrso8Uen4v4WTDJq2TtRm4EQWV7PlPoLzhbH/BVP0
	1j0DgX5VWHOSZo15AAaaDjBRgtOmzlsDgoM1vlmNDJ98aNBiqkA9/56ukHCDEkte0adn
	jWBMR9iJsjIjuX1mrVqSxFqkQARUNq6E/LRwruWy0voNrqEUbUzRcSX+vS3EZIjRKFcl
	hZ1g==
Received: by 10.152.131.37 with SMTP id oj5mr3192053lab.14.1347646764933;
	Fri, 14 Sep 2012 11:19:24 -0700 (PDT)
Received: from [192.168.11.174] (mail.dev.rtsoft.ru. [213.79.90.226])
	by mx.google.com with ESMTPS id nf5sm727180lab.3.2012.09.14.11.19.22
	(version=TLSv1/SSLv3 cipher=OTHER);
	Fri, 14 Sep 2012 11:19:23 -0700 (PDT)
Message-ID: <505374E2.5080308@mvista.com>
Date: Fri, 14 Sep 2012 22:18:10 +0400
From: Sergei Shtylyov <sshtylyov@mvista.com>
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:15.0) Gecko/20120824 Thunderbird/15.0
MIME-Version: 1.0
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.02.1209141145150.29232@kaball.uk.xensource.com>
	<1347621207-11294-12-git-send-email-stefano.stabellini@eu.citrix.com>
In-Reply-To: <1347621207-11294-12-git-send-email-stefano.stabellini@eu.citrix.com>
X-Gm-Message-State: ALoCoQm6WH5ReUVQc3MZiLNXT6oertZmcbVyS75DhX/rXWh1zSj+t7MVHL3139Vu8JtJeHaUC+zD
X-Mailman-Approved-At: Fri, 14 Sep 2012 20:13:14 +0000
Cc: xen-devel@lists.xensource.com, linaro-dev@lists.linaro.org,
	Ian.Campbell@citrix.com, arnd@arndb.de, konrad.wilk@oracle.com,
	catalin.marinas@arm.com, tim@xen.org,
	linux-kernel@vger.kernel.org, linux@arm.linux.org.uk,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [Xen-devel] [PATCH v4 12/24] xen/arm: introduce CONFIG_XEN on
	ARM
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hello.

On 09/14/2012 03:13 PM, Stefano Stabellini wrote:

> Changes in v2:

> - mark Xen guest support on ARM as EXPERIMENTAL.

> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> ---
>  arch/arm/Kconfig |   10 ++++++++++
>  1 files changed, 10 insertions(+), 0 deletions(-)

> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index 2f88d8d..e92518d 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -1897,6 +1897,16 @@ config DEPRECATED_PARAM_STRUCT
>  	  This was deprecated in 2001 and announced to live on for 5 years.
>  	  Some old boot loaders still use this way.
>  
> +config XEN_DOM0
> +	def_bool y
> +
> +config XEN
> +	bool "Xen guest support on ARM (EXPERIMENTAL)"
> +	depends on EXPERIMENTAL && ARM && OF
> +	select XEN_DOM0

   What's the point of selecting it if it's always "y"?

WBR, Sergei


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 14 20:31:45 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 20: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 1TCcXl-0002IR-EK; Fri, 14 Sep 2012 20:31:17 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ketuzsezr@gmail.com>) id 1TCcXj-0002IM-RH
	for xen-devel@lists.xen.org; Fri, 14 Sep 2012 20:31:16 +0000
Received: from [85.158.138.51:48311] by server-10.bemta-3.messagelabs.com id
	D0/EB-10411-21493505; Fri, 14 Sep 2012 20:31:14 +0000
X-Env-Sender: ketuzsezr@gmail.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1347654672!28928064!1
X-Originating-IP: [209.85.160.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11197 invoked from network); 14 Sep 2012 20:31:14 -0000
Received: from mail-pb0-f45.google.com (HELO mail-pb0-f45.google.com)
	(209.85.160.45)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Sep 2012 20:31:14 -0000
Received: by pbbrp12 with SMTP id rp12so6352875pbb.32
	for <xen-devel@lists.xen.org>; Fri, 14 Sep 2012 13:31:12 -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=CS4jZ+z9MYa/3x3wp7ux8ZBs2SVfS1zC6paXXBFWepY=;
	b=ExAbD+/69L8WYLhPRznPx01moMP/9UpcToZI620iWDRFp7UPPalE/z4jWDL4OQ81gq
	JsUcLmR7/W4CxyEdGthJ3VRCZFsDlGwh355EkBBoOL4/Zj3IUGncajieWDv2kR3/D5HP
	nmih8pzMo49ERDNkcyvPGOBlgFJn8qNqEt50FNogMafJyxISZEkxqxYhkPk+1+PnMNe+
	ReRX/UkJEIjNoUs9DuvW+pcfzB9yey2SMRE32L2jPyJwCQuLoGzduhGwB9IqkjINz9/7
	PrP673MfFVSuQ9oiyximGHJ2SJJWQjBHer3l1Dt4UmXYaCmyainwyDAh7r/kSzUa6Gwb
	0YRg==
MIME-Version: 1.0
Received: by 10.68.239.135 with SMTP id vs7mr6525876pbc.38.1347654671943; Fri,
	14 Sep 2012 13:31:11 -0700 (PDT)
Received: by 10.66.193.9 with HTTP; Fri, 14 Sep 2012 13:31:11 -0700 (PDT)
In-Reply-To: <CC780B38.4BAEB%keir@xen.org>
References: <CACJDEmo7EbT+e0oSvnYGntX=ZKg65U2EGhhDpUKURF6xjw=Fpg@mail.gmail.com>
	<CC780B38.4BAEB%keir@xen.org>
Date: Fri, 14 Sep 2012 16:31:11 -0400
X-Google-Sender-Auth: 6D4vLCf7ksJRIVdWM6pIDgHVSOs
Message-ID: <CACJDEmpMXLEvtv-Y8X6StBOd0B7jLZfvFG1B_Ru1_uUimU2kiA@mail.gmail.com>
From: Konrad Rzeszutek Wilk <konrad@kernel.org>
To: Keir Fraser <keir@xen.org>
Cc: Keir Fraser <keir.xen@gmail.com>, Tim Deegan <tim@xen.org>,
	Jan Beulich <JBeulich@suse.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] x86/mm: remove the linear mapping of the
	p2m tables
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Sep 13, 2012 at 5:14 PM, Keir Fraser <keir@xen.org> wrote:
> On 13/09/2012 21:43, "Konrad Rzeszutek Wilk" <konrad@kernel.org> wrote:
>
>>> Auto-translated PV seems to be one of those unsupported things that never
>>> quite dies. With PVH just round the corner, let's definitively call it dead.
>>> :)
>>
>> I thought we discussed that we need this as backup for running older guests?
>
> Don't think so, since we'll continue to run old guests as pure PV.
>
> There was a backup for running on older CPUs, and that was to allow PVH
> guests to run on shadow page tables. That's a totally separate compatibility
> concern however.

I am talking about the inverse. Running the "new" PV guests which do
not have PV MMU
enabled in them (since the PV MMU calls would not be necessary
anymore) and running
on non-NPT hardware.

For that PV auto-xlat would be necessary.
>
>> BTW, the auto-xlat is what PVH is advertising to the PV guest.
>
> Yes, but it's auto-xlat in an HVM container. Pure PV auto-xlat is what we're
> looking to kill here.
>
>  -- Keir
>
>> CC-ing Mukesh here
>
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Sep 14 20:31:45 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 20: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 1TCcXl-0002IR-EK; Fri, 14 Sep 2012 20:31:17 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ketuzsezr@gmail.com>) id 1TCcXj-0002IM-RH
	for xen-devel@lists.xen.org; Fri, 14 Sep 2012 20:31:16 +0000
Received: from [85.158.138.51:48311] by server-10.bemta-3.messagelabs.com id
	D0/EB-10411-21493505; Fri, 14 Sep 2012 20:31:14 +0000
X-Env-Sender: ketuzsezr@gmail.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1347654672!28928064!1
X-Originating-IP: [209.85.160.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11197 invoked from network); 14 Sep 2012 20:31:14 -0000
Received: from mail-pb0-f45.google.com (HELO mail-pb0-f45.google.com)
	(209.85.160.45)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Sep 2012 20:31:14 -0000
Received: by pbbrp12 with SMTP id rp12so6352875pbb.32
	for <xen-devel@lists.xen.org>; Fri, 14 Sep 2012 13:31:12 -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=CS4jZ+z9MYa/3x3wp7ux8ZBs2SVfS1zC6paXXBFWepY=;
	b=ExAbD+/69L8WYLhPRznPx01moMP/9UpcToZI620iWDRFp7UPPalE/z4jWDL4OQ81gq
	JsUcLmR7/W4CxyEdGthJ3VRCZFsDlGwh355EkBBoOL4/Zj3IUGncajieWDv2kR3/D5HP
	nmih8pzMo49ERDNkcyvPGOBlgFJn8qNqEt50FNogMafJyxISZEkxqxYhkPk+1+PnMNe+
	ReRX/UkJEIjNoUs9DuvW+pcfzB9yey2SMRE32L2jPyJwCQuLoGzduhGwB9IqkjINz9/7
	PrP673MfFVSuQ9oiyximGHJ2SJJWQjBHer3l1Dt4UmXYaCmyainwyDAh7r/kSzUa6Gwb
	0YRg==
MIME-Version: 1.0
Received: by 10.68.239.135 with SMTP id vs7mr6525876pbc.38.1347654671943; Fri,
	14 Sep 2012 13:31:11 -0700 (PDT)
Received: by 10.66.193.9 with HTTP; Fri, 14 Sep 2012 13:31:11 -0700 (PDT)
In-Reply-To: <CC780B38.4BAEB%keir@xen.org>
References: <CACJDEmo7EbT+e0oSvnYGntX=ZKg65U2EGhhDpUKURF6xjw=Fpg@mail.gmail.com>
	<CC780B38.4BAEB%keir@xen.org>
Date: Fri, 14 Sep 2012 16:31:11 -0400
X-Google-Sender-Auth: 6D4vLCf7ksJRIVdWM6pIDgHVSOs
Message-ID: <CACJDEmpMXLEvtv-Y8X6StBOd0B7jLZfvFG1B_Ru1_uUimU2kiA@mail.gmail.com>
From: Konrad Rzeszutek Wilk <konrad@kernel.org>
To: Keir Fraser <keir@xen.org>
Cc: Keir Fraser <keir.xen@gmail.com>, Tim Deegan <tim@xen.org>,
	Jan Beulich <JBeulich@suse.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] x86/mm: remove the linear mapping of the
	p2m tables
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Sep 13, 2012 at 5:14 PM, Keir Fraser <keir@xen.org> wrote:
> On 13/09/2012 21:43, "Konrad Rzeszutek Wilk" <konrad@kernel.org> wrote:
>
>>> Auto-translated PV seems to be one of those unsupported things that never
>>> quite dies. With PVH just round the corner, let's definitively call it dead.
>>> :)
>>
>> I thought we discussed that we need this as backup for running older guests?
>
> Don't think so, since we'll continue to run old guests as pure PV.
>
> There was a backup for running on older CPUs, and that was to allow PVH
> guests to run on shadow page tables. That's a totally separate compatibility
> concern however.

I am talking about the inverse. Running the "new" PV guests which do
not have PV MMU
enabled in them (since the PV MMU calls would not be necessary
anymore) and running
on non-NPT hardware.

For that PV auto-xlat would be necessary.
>
>> BTW, the auto-xlat is what PVH is advertising to the PV guest.
>
> Yes, but it's auto-xlat in an HVM container. Pure PV auto-xlat is what we're
> looking to kill here.
>
>  -- Keir
>
>> CC-ing Mukesh here
>
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Sep 14 20:48:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 20: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 1TCcnh-0002Yb-WB; Fri, 14 Sep 2012 20:47:45 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ketuzsezr@gmail.com>) id 1TCcng-0002YW-L7
	for xen-devel@lists.xen.org; Fri, 14 Sep 2012 20:47:44 +0000
Received: from [85.158.137.99:47978] by server-7.bemta-3.messagelabs.com id
	BF/AC-32000-FE793505; Fri, 14 Sep 2012 20:47:43 +0000
X-Env-Sender: ketuzsezr@gmail.com
X-Msg-Ref: server-6.tower-217.messagelabs.com!1347655661!12600614!1
X-Originating-IP: [209.85.210.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22982 invoked from network); 14 Sep 2012 20:47:42 -0000
Received: from mail-pz0-f45.google.com (HELO mail-pz0-f45.google.com)
	(209.85.210.45)
	by server-6.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Sep 2012 20:47:42 -0000
Received: by dadn15 with SMTP id n15so2712637dad.32
	for <xen-devel@lists.xen.org>; Fri, 14 Sep 2012 13:47: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=6y+jMA4YkE5cCusf/faf42BbEXkhi3m+J3+IcKFb+F4=;
	b=yqhFCzVkJw5ycfoNAMBZmXBZJUuNcOUL2Weh1DJdLYl5lDzpRWFTK/7ycIefT73G1S
	IQYDfJAdYiwXUKVkgvBBd5SgwSiRjOaap0haAknMH3WA1L05e4wu0B0pYEG/fHefcwkm
	tlIW5lPM6ScAECtf/8Oj8cPbHDlgfMELOUIWFnBo2LaFOmhS3Rc/amDE/3HWG9+Pn7Ma
	PPQ/Cs7XXwFa66G8ALCRrkK9fh9CGTAIIDrEfMOE3wuGYzxI34gkHBJVrOJWG7sLrV4n
	p51LPJ8kTR6KGy2e6HIFXcybEFQWQmgOGlhnj1x6n/KfqwqITCJ0TWkE/hvB96wRN23R
	dn7g==
MIME-Version: 1.0
Received: by 10.68.218.196 with SMTP id pi4mr6434118pbc.128.1347655660669;
	Fri, 14 Sep 2012 13:47:40 -0700 (PDT)
Received: by 10.66.193.9 with HTTP; Fri, 14 Sep 2012 13:47:40 -0700 (PDT)
In-Reply-To: <CAAnFQG9TZj=SxYK_jxqN=M6L40vL=AZu9EM2tbEffPhkL1s8FA@mail.gmail.com>
References: <CAAnFQG9TZj=SxYK_jxqN=M6L40vL=AZu9EM2tbEffPhkL1s8FA@mail.gmail.com>
Date: Fri, 14 Sep 2012 16:47:40 -0400
X-Google-Sender-Auth: kbH84BRN0ohl-mI58LPpPRX6jQ8
Message-ID: <CACJDEmqdqA6CE9SgLL2QCNmQH1dOX0_4OHfJfzes+G6bEkQ7FA@mail.gmail.com>
From: Konrad Rzeszutek Wilk <konrad@kernel.org>
To: Javier Marcet <jmarcet@gmail.com>
Cc: Xen Devel Mailing list <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.2.0-rc4 issues with DVB tuner
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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 replaced the problematic (due to BIOS bugs) GigaByte motherboard with
> an ASRock Z77M-Pro4 and the difference is awesome. All the issues I had
> with the IOMMU, ACPI and ASPM are gone.
>
> I still have to pass the intel_iommu=3Digfx_off kernel parameter or I con=
tinue
> to see lots of DMAR errors for the first couple of seconds after booting
> and I can=B4t use the DVB tuners either.
>
> This last point is a showstopper for me and I don=B4t know where the
> problem might come from. The cx23885 module (which my tuners use)
> loads fine, as do the devices under /dev/dvb. Upon tuning a channel,
> however, there is not data received.
>
> Does anyone have the slightest idea what might be causing this?

Are there any warnings or such being printed? Are the interrupts increasing?
Does lspci show anything 'disabled' in the guest?
>
> I wonder whether it would work within a DomU with the PCIe tuner
> passed through.

I've a 4 channel security card passed in and it works nicely. The
trick is that you need 'iommu=3Dsoft' on the domU command line.
>
>
> --
> Javier Marcet <jmarcet@gmail.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 Sep 14 20:48:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 20: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 1TCcnh-0002Yb-WB; Fri, 14 Sep 2012 20:47:45 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ketuzsezr@gmail.com>) id 1TCcng-0002YW-L7
	for xen-devel@lists.xen.org; Fri, 14 Sep 2012 20:47:44 +0000
Received: from [85.158.137.99:47978] by server-7.bemta-3.messagelabs.com id
	BF/AC-32000-FE793505; Fri, 14 Sep 2012 20:47:43 +0000
X-Env-Sender: ketuzsezr@gmail.com
X-Msg-Ref: server-6.tower-217.messagelabs.com!1347655661!12600614!1
X-Originating-IP: [209.85.210.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22982 invoked from network); 14 Sep 2012 20:47:42 -0000
Received: from mail-pz0-f45.google.com (HELO mail-pz0-f45.google.com)
	(209.85.210.45)
	by server-6.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Sep 2012 20:47:42 -0000
Received: by dadn15 with SMTP id n15so2712637dad.32
	for <xen-devel@lists.xen.org>; Fri, 14 Sep 2012 13:47: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=6y+jMA4YkE5cCusf/faf42BbEXkhi3m+J3+IcKFb+F4=;
	b=yqhFCzVkJw5ycfoNAMBZmXBZJUuNcOUL2Weh1DJdLYl5lDzpRWFTK/7ycIefT73G1S
	IQYDfJAdYiwXUKVkgvBBd5SgwSiRjOaap0haAknMH3WA1L05e4wu0B0pYEG/fHefcwkm
	tlIW5lPM6ScAECtf/8Oj8cPbHDlgfMELOUIWFnBo2LaFOmhS3Rc/amDE/3HWG9+Pn7Ma
	PPQ/Cs7XXwFa66G8ALCRrkK9fh9CGTAIIDrEfMOE3wuGYzxI34gkHBJVrOJWG7sLrV4n
	p51LPJ8kTR6KGy2e6HIFXcybEFQWQmgOGlhnj1x6n/KfqwqITCJ0TWkE/hvB96wRN23R
	dn7g==
MIME-Version: 1.0
Received: by 10.68.218.196 with SMTP id pi4mr6434118pbc.128.1347655660669;
	Fri, 14 Sep 2012 13:47:40 -0700 (PDT)
Received: by 10.66.193.9 with HTTP; Fri, 14 Sep 2012 13:47:40 -0700 (PDT)
In-Reply-To: <CAAnFQG9TZj=SxYK_jxqN=M6L40vL=AZu9EM2tbEffPhkL1s8FA@mail.gmail.com>
References: <CAAnFQG9TZj=SxYK_jxqN=M6L40vL=AZu9EM2tbEffPhkL1s8FA@mail.gmail.com>
Date: Fri, 14 Sep 2012 16:47:40 -0400
X-Google-Sender-Auth: kbH84BRN0ohl-mI58LPpPRX6jQ8
Message-ID: <CACJDEmqdqA6CE9SgLL2QCNmQH1dOX0_4OHfJfzes+G6bEkQ7FA@mail.gmail.com>
From: Konrad Rzeszutek Wilk <konrad@kernel.org>
To: Javier Marcet <jmarcet@gmail.com>
Cc: Xen Devel Mailing list <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.2.0-rc4 issues with DVB tuner
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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 replaced the problematic (due to BIOS bugs) GigaByte motherboard with
> an ASRock Z77M-Pro4 and the difference is awesome. All the issues I had
> with the IOMMU, ACPI and ASPM are gone.
>
> I still have to pass the intel_iommu=3Digfx_off kernel parameter or I con=
tinue
> to see lots of DMAR errors for the first couple of seconds after booting
> and I can=B4t use the DVB tuners either.
>
> This last point is a showstopper for me and I don=B4t know where the
> problem might come from. The cx23885 module (which my tuners use)
> loads fine, as do the devices under /dev/dvb. Upon tuning a channel,
> however, there is not data received.
>
> Does anyone have the slightest idea what might be causing this?

Are there any warnings or such being printed? Are the interrupts increasing?
Does lspci show anything 'disabled' in the guest?
>
> I wonder whether it would work within a DomU with the PCIe tuner
> passed through.

I've a 4 channel security card passed in and it works nicely. The
trick is that you need 'iommu=3Dsoft' on the domU command line.
>
>
> --
> Javier Marcet <jmarcet@gmail.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 Sep 14 20:56:19 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 20:56:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TCcvf-0002i9-VU; Fri, 14 Sep 2012 20:55:59 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1TCcve-0002i4-LY
	for xen-devel@lists.xen.org; Fri, 14 Sep 2012 20:55:58 +0000
Received: from [85.158.143.99:61038] by server-2.bemta-4.messagelabs.com id
	0F/E6-21239-ED993505; Fri, 14 Sep 2012 20:55:58 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1347656157!20800815!1
X-Originating-IP: [74.125.82.51]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6043 invoked from network); 14 Sep 2012 20:55:57 -0000
Received: from mail-wg0-f51.google.com (HELO mail-wg0-f51.google.com)
	(74.125.82.51)
	by server-14.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Sep 2012 20:55:57 -0000
Received: by wgbed3 with SMTP id ed3so305572wgb.32
	for <xen-devel@lists.xen.org>; Fri, 14 Sep 2012 13:55:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=Zx/AJSY+KGJe7gi/eaIIFvohzacDnJvwy+Lv2xttPko=;
	b=xJd2yzI2GODViqwo/pE0mmqEsjo3qdY2i3ATvfzQzkWu09E0hMq5ST378EnRxgztYt
	0Ya87/kZLq1YIkT0aaoZBX/PVbjOQV8y3eF3GmYPabQYMAo1ocZ4RA5XpP7H0HIopm4r
	xrm61+X1BPiu3L0aCEVS20xXS2VVLaYoPUAThaFq3IFADa0+g9wjs2vCwEl6uuPrv5yp
	gmMkj7WDhsISpBsLGU+ur3VvLaejkUyYf1W8GMXgRSCWUf98UbVjjOpanIz9/7nqMULy
	0ZGga6vg6ui8HGOiqOJxXEF67T2EZlANAGg/KSUYIM3qT0eNN8BvNtLA0vjvGFD4yR3l
	z4gQ==
Received: by 10.216.54.212 with SMTP id i62mr1940813wec.98.1347656157156;
	Fri, 14 Sep 2012 13:55:57 -0700 (PDT)
Received: from [192.168.1.3] (host86-184-74-117.range86-184.btcentralplus.com.
	[86.184.74.117])
	by mx.google.com with ESMTPS id l5sm1088266wix.5.2012.09.14.13.55.50
	(version=SSLv3 cipher=OTHER); Fri, 14 Sep 2012 13:55:56 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.33.0.120411
Date: Fri, 14 Sep 2012 21:55:40 +0100
From: Keir Fraser <keir@xen.org>
To: Konrad Rzeszutek Wilk <konrad@kernel.org>
Message-ID: <CC79585C.4BD12%keir@xen.org>
Thread-Topic: [Xen-devel] [PATCH] x86/mm: remove the linear mapping of the p2m
	tables
Thread-Index: Ac2Su0xIi4S4Q1c520qAaxX7Dmyq6w==
In-Reply-To: <CACJDEmpMXLEvtv-Y8X6StBOd0B7jLZfvFG1B_Ru1_uUimU2kiA@mail.gmail.com>
Mime-version: 1.0
Cc: Tim Deegan <tim@xen.org>, Jan Beulich <JBeulich@suse.com>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] x86/mm: remove the linear mapping of the
 p2m tables
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 14/09/2012 21:31, "Konrad Rzeszutek Wilk" <konrad@kernel.org> wrote:

>> Don't think so, since we'll continue to run old guests as pure PV.
>> 
>> There was a backup for running on older CPUs, and that was to allow PVH
>> guests to run on shadow page tables. That's a totally separate compatibility
>> concern however.
> 
> I am talking about the inverse. Running the "new" PV guests which do
> not have PV MMU
> enabled in them (since the PV MMU calls would not be necessary
> anymore) and running
> on non-NPT hardware.
> 
> For that PV auto-xlat would be necessary.

These 'new' PV guests are PVH guests. We're talking about removing PV
auto-xlat, not disallowing PVH auto-xlat. Subtle difference, but PVH will
always run in an HVM container.

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 14 20:56:19 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 20:56:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TCcvf-0002i9-VU; Fri, 14 Sep 2012 20:55:59 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1TCcve-0002i4-LY
	for xen-devel@lists.xen.org; Fri, 14 Sep 2012 20:55:58 +0000
Received: from [85.158.143.99:61038] by server-2.bemta-4.messagelabs.com id
	0F/E6-21239-ED993505; Fri, 14 Sep 2012 20:55:58 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1347656157!20800815!1
X-Originating-IP: [74.125.82.51]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6043 invoked from network); 14 Sep 2012 20:55:57 -0000
Received: from mail-wg0-f51.google.com (HELO mail-wg0-f51.google.com)
	(74.125.82.51)
	by server-14.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Sep 2012 20:55:57 -0000
Received: by wgbed3 with SMTP id ed3so305572wgb.32
	for <xen-devel@lists.xen.org>; Fri, 14 Sep 2012 13:55:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=Zx/AJSY+KGJe7gi/eaIIFvohzacDnJvwy+Lv2xttPko=;
	b=xJd2yzI2GODViqwo/pE0mmqEsjo3qdY2i3ATvfzQzkWu09E0hMq5ST378EnRxgztYt
	0Ya87/kZLq1YIkT0aaoZBX/PVbjOQV8y3eF3GmYPabQYMAo1ocZ4RA5XpP7H0HIopm4r
	xrm61+X1BPiu3L0aCEVS20xXS2VVLaYoPUAThaFq3IFADa0+g9wjs2vCwEl6uuPrv5yp
	gmMkj7WDhsISpBsLGU+ur3VvLaejkUyYf1W8GMXgRSCWUf98UbVjjOpanIz9/7nqMULy
	0ZGga6vg6ui8HGOiqOJxXEF67T2EZlANAGg/KSUYIM3qT0eNN8BvNtLA0vjvGFD4yR3l
	z4gQ==
Received: by 10.216.54.212 with SMTP id i62mr1940813wec.98.1347656157156;
	Fri, 14 Sep 2012 13:55:57 -0700 (PDT)
Received: from [192.168.1.3] (host86-184-74-117.range86-184.btcentralplus.com.
	[86.184.74.117])
	by mx.google.com with ESMTPS id l5sm1088266wix.5.2012.09.14.13.55.50
	(version=SSLv3 cipher=OTHER); Fri, 14 Sep 2012 13:55:56 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.33.0.120411
Date: Fri, 14 Sep 2012 21:55:40 +0100
From: Keir Fraser <keir@xen.org>
To: Konrad Rzeszutek Wilk <konrad@kernel.org>
Message-ID: <CC79585C.4BD12%keir@xen.org>
Thread-Topic: [Xen-devel] [PATCH] x86/mm: remove the linear mapping of the p2m
	tables
Thread-Index: Ac2Su0xIi4S4Q1c520qAaxX7Dmyq6w==
In-Reply-To: <CACJDEmpMXLEvtv-Y8X6StBOd0B7jLZfvFG1B_Ru1_uUimU2kiA@mail.gmail.com>
Mime-version: 1.0
Cc: Tim Deegan <tim@xen.org>, Jan Beulich <JBeulich@suse.com>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] x86/mm: remove the linear mapping of the
 p2m tables
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 14/09/2012 21:31, "Konrad Rzeszutek Wilk" <konrad@kernel.org> wrote:

>> Don't think so, since we'll continue to run old guests as pure PV.
>> 
>> There was a backup for running on older CPUs, and that was to allow PVH
>> guests to run on shadow page tables. That's a totally separate compatibility
>> concern however.
> 
> I am talking about the inverse. Running the "new" PV guests which do
> not have PV MMU
> enabled in them (since the PV MMU calls would not be necessary
> anymore) and running
> on non-NPT hardware.
> 
> For that PV auto-xlat would be necessary.

These 'new' PV guests are PVH guests. We're talking about removing PV
auto-xlat, not disallowing PVH auto-xlat. Subtle difference, but PVH will
always run in an HVM container.

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 14 21:08:53 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 21:08:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TCd7m-0002vB-8y; Fri, 14 Sep 2012 21:08:30 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1TCd7k-0002v6-E3
	for xen-devel@lists.xensource.com; Fri, 14 Sep 2012 21:08:28 +0000
Received: from [85.158.137.99:8002] by server-3.bemta-3.messagelabs.com id
	6A/1C-21322-BCC93505; Fri, 14 Sep 2012 21:08:27 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-16.tower-217.messagelabs.com!1347656906!17737274!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDkyOTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6900 invoked from network); 14 Sep 2012 21:08:26 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Sep 2012 21:08:26 -0000
X-IronPort-AV: E=Sophos;i="4.80,424,1344211200"; d="scan'208";a="14555115"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Sep 2012 21:08:26 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Fri, 14 Sep 2012 22:08:26 +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 1TCd7i-00033G-6w;
	Fri, 14 Sep 2012 21:08:26 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1TCd7h-0007mT-Jb;
	Fri, 14 Sep 2012 22:08:26 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-13764-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 14 Sep 2012 22:08:25 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13764: 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 13764 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13764/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore            fail   like 13760
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail like 13760
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail like 13760

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  a177725aa492
baseline version:
 xen                  5613018f93b1

------------------------------------------------------------
People who touched revisions under test:
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Jason McCarver <slam@parasite.cc>
  Juergen Gross<juergen.gross@ts.fujitsu.com>
  Keir Fraser <keir@xen.org>
  Matt Wilson <msw@amazon.com>
  Olaf Hering <olaf@aepfle.de>
  Roger Pau Monne <roger.pau@citrix.com>
  Wei Wang <wei.wang2@amd.com>
  Xiantao Zhang <xiantao.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-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-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-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-amd64-amd64-xl-win                                      fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=xen-unstable
+ revision=a177725aa492
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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 a177725aa492
+ branch=xen-unstable
+ revision=a177725aa492
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-unstable
+ '[' xxen = xlinux ']'
+ linuxbranch=linux
+ : master
+ : tested/2.6.39.x
+ . ap-common
++ : xen@xenbits.xensource.com
++ : http://xenbits.xen.org/hg/staging/xen-unstable.hg
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : xen@xenbits.xensource.com:git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.xen-unstable
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-unstable.git
++ : daily-cron.xen-unstable
+ TREE_LINUX=xen@xenbits.xensource.com:git/linux-pvops.git
+ TREE_QEMU_UPSTREAM=xen@xenbits.xensource.com:git/qemu-upstream-unstable.git
+ info_linux_tree xen-unstable
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/xen-unstable.hg
+ hg push -r a177725aa492 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 14 changesets with 48 changes to 42 files

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 14 21:08:53 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 21:08:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TCd7m-0002vB-8y; Fri, 14 Sep 2012 21:08:30 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1TCd7k-0002v6-E3
	for xen-devel@lists.xensource.com; Fri, 14 Sep 2012 21:08:28 +0000
Received: from [85.158.137.99:8002] by server-3.bemta-3.messagelabs.com id
	6A/1C-21322-BCC93505; Fri, 14 Sep 2012 21:08:27 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-16.tower-217.messagelabs.com!1347656906!17737274!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDkyOTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6900 invoked from network); 14 Sep 2012 21:08:26 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Sep 2012 21:08:26 -0000
X-IronPort-AV: E=Sophos;i="4.80,424,1344211200"; d="scan'208";a="14555115"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Sep 2012 21:08:26 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Fri, 14 Sep 2012 22:08:26 +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 1TCd7i-00033G-6w;
	Fri, 14 Sep 2012 21:08:26 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1TCd7h-0007mT-Jb;
	Fri, 14 Sep 2012 22:08:26 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-13764-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 14 Sep 2012 22:08:25 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13764: 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 13764 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13764/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore            fail   like 13760
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail like 13760
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail like 13760

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  a177725aa492
baseline version:
 xen                  5613018f93b1

------------------------------------------------------------
People who touched revisions under test:
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Jason McCarver <slam@parasite.cc>
  Juergen Gross<juergen.gross@ts.fujitsu.com>
  Keir Fraser <keir@xen.org>
  Matt Wilson <msw@amazon.com>
  Olaf Hering <olaf@aepfle.de>
  Roger Pau Monne <roger.pau@citrix.com>
  Wei Wang <wei.wang2@amd.com>
  Xiantao Zhang <xiantao.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-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-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-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-amd64-amd64-xl-win                                      fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=xen-unstable
+ revision=a177725aa492
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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 a177725aa492
+ branch=xen-unstable
+ revision=a177725aa492
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-unstable
+ '[' xxen = xlinux ']'
+ linuxbranch=linux
+ : master
+ : tested/2.6.39.x
+ . ap-common
++ : xen@xenbits.xensource.com
++ : http://xenbits.xen.org/hg/staging/xen-unstable.hg
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : xen@xenbits.xensource.com:git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.xen-unstable
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-unstable.git
++ : daily-cron.xen-unstable
+ TREE_LINUX=xen@xenbits.xensource.com:git/linux-pvops.git
+ TREE_QEMU_UPSTREAM=xen@xenbits.xensource.com:git/qemu-upstream-unstable.git
+ info_linux_tree xen-unstable
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/xen-unstable.hg
+ hg push -r a177725aa492 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 14 changesets with 48 changes to 42 files

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 14 22:35:53 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 22:35:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TCeTs-0003k5-37; Fri, 14 Sep 2012 22:35: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 1TCeTp-0003k0-Sx
	for xen-devel@lists.xensource.com; Fri, 14 Sep 2012 22:35:22 +0000
Received: from [85.158.143.99:62608] by server-3.bemta-4.messagelabs.com id
	BC/CC-08232-921B3505; Fri, 14 Sep 2012 22:35:21 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1347662119!29517333!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDkyOTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25356 invoked from network); 14 Sep 2012 22:35:20 -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;
	14 Sep 2012 22:35:20 -0000
X-IronPort-AV: E=Sophos;i="4.80,424,1344211200"; d="scan'208";a="14556708"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Sep 2012 22:35: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.279.1; Fri, 14 Sep 2012 23:35: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 1TCeTn-0003aB-82;
	Fri, 14 Sep 2012 22:35:19 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1TCeTn-0005B5-2C;
	Fri, 14 Sep 2012 23:35:19 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-13766-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 14 Sep 2012 23:35:19 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [qemu-upstream-4.2-testing baseline test] 13766:
	tolerable FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

"Old" tested version had not actually been tested; therefore in this
flight we test it, rather than a new candidate.  The baseline, if
any, is the most recent actually tested revision.

flight 13766 qemu-upstream-4.2-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13766/

Failures :-/ but no regressions.

Tests which did not succeed,
including tests which could not be run:
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  9 guest-localmigrate fail never pass
 test-i386-i386-xl-qemuu-win   9 guest-localmigrate           fail   never pass
 test-amd64-amd64-qemuu-win   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64  9 guest-localmigrate      fail never pass
 test-amd64-i386-xl-qemuu-win-vcpus1  9 guest-localmigrate      fail never pass
 test-amd64-i386-xend-qemuu-winxpsp3 16 leak-check/check        fail never pass
 test-i386-i386-qemuu-win     16 leak-check/check             fail   never pass
 test-amd64-i386-qemuu-win-vcpus1 16 leak-check/check           fail never pass
 test-amd64-i386-qemuu-win    16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemuu-win  9 guest-localmigrate           fail  never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail never pass
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass


jobs:
 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                           pass    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-win-vcpus1                             fail    
 test-amd64-i386-xl-qemuu-win-vcpus1                          fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-amd64-qemuu-win                                   fail    
 test-amd64-i386-qemuu-win                                    fail    
 test-i386-i386-qemuu-win                                     fail    
 test-amd64-amd64-xl-qemuu-win                                fail    
 test-i386-i386-xl-qemuu-win                                  fail    
 test-amd64-i386-xend-qemuu-winxpsp3                          fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


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 Sep 14 22:35:53 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 22:35:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TCeTs-0003k5-37; Fri, 14 Sep 2012 22:35: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 1TCeTp-0003k0-Sx
	for xen-devel@lists.xensource.com; Fri, 14 Sep 2012 22:35:22 +0000
Received: from [85.158.143.99:62608] by server-3.bemta-4.messagelabs.com id
	BC/CC-08232-921B3505; Fri, 14 Sep 2012 22:35:21 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1347662119!29517333!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDkyOTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25356 invoked from network); 14 Sep 2012 22:35:20 -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;
	14 Sep 2012 22:35:20 -0000
X-IronPort-AV: E=Sophos;i="4.80,424,1344211200"; d="scan'208";a="14556708"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Sep 2012 22:35: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.279.1; Fri, 14 Sep 2012 23:35: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 1TCeTn-0003aB-82;
	Fri, 14 Sep 2012 22:35:19 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1TCeTn-0005B5-2C;
	Fri, 14 Sep 2012 23:35:19 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-13766-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 14 Sep 2012 23:35:19 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [qemu-upstream-4.2-testing baseline test] 13766:
	tolerable FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

"Old" tested version had not actually been tested; therefore in this
flight we test it, rather than a new candidate.  The baseline, if
any, is the most recent actually tested revision.

flight 13766 qemu-upstream-4.2-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13766/

Failures :-/ but no regressions.

Tests which did not succeed,
including tests which could not be run:
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  9 guest-localmigrate fail never pass
 test-i386-i386-xl-qemuu-win   9 guest-localmigrate           fail   never pass
 test-amd64-amd64-qemuu-win   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64  9 guest-localmigrate      fail never pass
 test-amd64-i386-xl-qemuu-win-vcpus1  9 guest-localmigrate      fail never pass
 test-amd64-i386-xend-qemuu-winxpsp3 16 leak-check/check        fail never pass
 test-i386-i386-qemuu-win     16 leak-check/check             fail   never pass
 test-amd64-i386-qemuu-win-vcpus1 16 leak-check/check           fail never pass
 test-amd64-i386-qemuu-win    16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemuu-win  9 guest-localmigrate           fail  never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail never pass
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass


jobs:
 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                           pass    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-win-vcpus1                             fail    
 test-amd64-i386-xl-qemuu-win-vcpus1                          fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-amd64-qemuu-win                                   fail    
 test-amd64-i386-qemuu-win                                    fail    
 test-i386-i386-qemuu-win                                     fail    
 test-amd64-amd64-xl-qemuu-win                                fail    
 test-i386-i386-xl-qemuu-win                                  fail    
 test-amd64-i386-xend-qemuu-winxpsp3                          fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


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 Sep 14 23:08:07 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 23:08:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TCez8-00040B-04; Fri, 14 Sep 2012 23:07:42 +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 1TCez6-000406-Nh
	for xen-devel@lists.xensource.com; Fri, 14 Sep 2012 23:07:40 +0000
Received: from [85.158.143.99:26266] by server-1.bemta-4.messagelabs.com id
	1C/C3-12504-CB8B3505; Fri, 14 Sep 2012 23:07:40 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1347664058!22299179!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDc1MzA3MQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30387 invoked from network); 14 Sep 2012 23:07:39 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-12.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 14 Sep 2012 23:07:39 -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 q8EN7UnN013263
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 14 Sep 2012 23:07:31 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
	q8EN7TPF007791
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 14 Sep 2012 23:07:30 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
	q8EN7TfV008031; Fri, 14 Sep 2012 18:07:29 -0500
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 14 Sep 2012 16:07:28 -0700
Date: Fri, 14 Sep 2012 16:07:27 -0700
From: Mukesh Rathor <mukesh.rathor@oracle.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120914160727.1ff41de2@mantra.us.oracle.com>
In-Reply-To: <1347627587.24226.192.camel@zakaz.uk.xensource.com>
References: <alpine.DEB.2.02.1208221159560.15568@kaball.uk.xensource.com>
	<1345633688-31684-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<1347627587.24226.192.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>,
	"Tim \(Xen.org\)" <tim@xen.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v4 1/6] xen: improve changes to
	xen_add_to_physmap
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 14 Sep 2012 13:59:47 +0100
Ian Campbell <Ian.Campbell@citrix.com> wrote:

> 
> On Wed, 2012-08-22 at 12:08 +0100, Stefano Stabellini wrote:
> > This is an incremental patch on top of
> > c0bc926083b5987a3e9944eec2c12ad0580100e2: in order to retain binary
> > compatibility, it is better to introduce foreign_domid as part of a
> > union containing both size and foreign_domid.
> [...]
> > -    domid_t foreign_domid; /* IFF gmfn_foreign */
> > +    unsigned int space;
> >  
> >  #define XENMAPIDX_grant_table_status 0x80000000
> 
> Was this the final consensus on what this interface ought to look
> like?
> 
> Does it work for PVH too (Mukesh CCd)?

Yes it does. Please lmk if the final version asap so I can put in
my patch, and also test it.


> Might we prefer to have a batched version of this call? I don't think
> we can shoehorn the necessary fields into xen_add_to_physmap_t though.
> 
> Do we think libxc will ever want to call a batch version of
> XENMAPSPACE_gmfn_foreign ? If not then we can probably get away using
> multicall batching. If yes then perhaps not -- libxc doesn'tdo
> multicalls.

Not right now. The whole remap api is one page at a time. 


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 Sep 14 23:08:07 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 23:08:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TCez8-00040B-04; Fri, 14 Sep 2012 23:07:42 +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 1TCez6-000406-Nh
	for xen-devel@lists.xensource.com; Fri, 14 Sep 2012 23:07:40 +0000
Received: from [85.158.143.99:26266] by server-1.bemta-4.messagelabs.com id
	1C/C3-12504-CB8B3505; Fri, 14 Sep 2012 23:07:40 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1347664058!22299179!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDc1MzA3MQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30387 invoked from network); 14 Sep 2012 23:07:39 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-12.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 14 Sep 2012 23:07:39 -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 q8EN7UnN013263
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 14 Sep 2012 23:07:31 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
	q8EN7TPF007791
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 14 Sep 2012 23:07:30 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
	q8EN7TfV008031; Fri, 14 Sep 2012 18:07:29 -0500
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 14 Sep 2012 16:07:28 -0700
Date: Fri, 14 Sep 2012 16:07:27 -0700
From: Mukesh Rathor <mukesh.rathor@oracle.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120914160727.1ff41de2@mantra.us.oracle.com>
In-Reply-To: <1347627587.24226.192.camel@zakaz.uk.xensource.com>
References: <alpine.DEB.2.02.1208221159560.15568@kaball.uk.xensource.com>
	<1345633688-31684-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<1347627587.24226.192.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>,
	"Tim \(Xen.org\)" <tim@xen.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v4 1/6] xen: improve changes to
	xen_add_to_physmap
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 14 Sep 2012 13:59:47 +0100
Ian Campbell <Ian.Campbell@citrix.com> wrote:

> 
> On Wed, 2012-08-22 at 12:08 +0100, Stefano Stabellini wrote:
> > This is an incremental patch on top of
> > c0bc926083b5987a3e9944eec2c12ad0580100e2: in order to retain binary
> > compatibility, it is better to introduce foreign_domid as part of a
> > union containing both size and foreign_domid.
> [...]
> > -    domid_t foreign_domid; /* IFF gmfn_foreign */
> > +    unsigned int space;
> >  
> >  #define XENMAPIDX_grant_table_status 0x80000000
> 
> Was this the final consensus on what this interface ought to look
> like?
> 
> Does it work for PVH too (Mukesh CCd)?

Yes it does. Please lmk if the final version asap so I can put in
my patch, and also test it.


> Might we prefer to have a batched version of this call? I don't think
> we can shoehorn the necessary fields into xen_add_to_physmap_t though.
> 
> Do we think libxc will ever want to call a batch version of
> XENMAPSPACE_gmfn_foreign ? If not then we can probably get away using
> multicall batching. If yes then perhaps not -- libxc doesn'tdo
> multicalls.

Not right now. The whole remap api is one page at a time. 


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 Sep 14 23:10:06 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 23: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 1TCf13-00045F-Gv; Fri, 14 Sep 2012 23:09:41 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mukesh.rathor@oracle.com>) id 1TCf11-000453-VH
	for xen-devel@lists.xensource.com; Fri, 14 Sep 2012 23:09:40 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1347664172!9666173!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDc1MzA3MQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29399 invoked from network); 14 Sep 2012 23:09:33 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-16.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 14 Sep 2012 23:09:33 -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 q8EN9LCa014250
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 14 Sep 2012 23:09:21 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q8EN9JHi014682
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 14 Sep 2012 23:09:20 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
	q8EN9JnO011262; Fri, 14 Sep 2012 18:09:19 -0500
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 14 Sep 2012 16:09:19 -0700
Date: Fri, 14 Sep 2012 16:09:18 -0700
From: Mukesh Rathor <mukesh.rathor@oracle.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20120914160918.7e61d1d0@mantra.us.oracle.com>
In-Reply-To: <alpine.DEB.2.02.1209141652440.29232@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1208221159560.15568@kaball.uk.xensource.com>
	<1345633688-31684-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<1347627587.24226.192.camel@zakaz.uk.xensource.com>
	<1347628660.24226.197.camel@zakaz.uk.xensource.com>
	<1347630442.24226.211.camel@zakaz.uk.xensource.com>
	<1347630971.24226.214.camel@zakaz.uk.xensource.com>
	<50535AFA020000780009B7C4@nat28.tlf.novell.com>
	<alpine.DEB.2.02.1209141631200.29232@kaball.uk.xensource.com>
	<1347637953.14977.10.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.02.1209141652440.29232@kaball.uk.xensource.com>
Organization: Oracle Corporation
X-Mailer: Claws Mail 3.7.6 (GTK+ 2.18.9; x86_64-redhat-linux-gnu)
Mime-Version: 1.0
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Keir \(Xen.org\)" <keir@xen.org>,
	Ian Campbell <Ian.Campbell@citrix.com>, "Tim \(Xen.org\)" <tim@xen.org>,
	"ijackson@chiark.greenend.org.uk" <ijackson@chiark.greenend.org.uk>,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH v4 1/6] xen: improve changes to
 xen_add_to_physmap
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 14 Sep 2012 16:54:06 +0100
Stefano Stabellini <stefano.stabellini@eu.citrix.com> wrote:

> On Fri, 14 Sep 2012, Ian Campbell wrote:
> > On Fri, 2012-09-14 at 16:44 +0100, Stefano Stabellini wrote:
> > > On Fri, 14 Sep 2012, Jan Beulich wrote:
> > > > >>> On 14.09.12 at 15:56, Ian Campbell
> > > > >>> <Ian.Campbell@citrix.com> wrote:
> > > > >> > > Might we prefer to have a batched version of this call?
> > > > >> > > I don't think we can shoehorn the necessary fields into
> > > > >> > > xen_add_to_physmap_t though.
> > > > >> > 
> > > > >> > Actually, talking about this we Stefano we think we can.
> > > > >> > Since both idx and gpfn are unsigned longs they can become
> > > > >> > unions with a GUEST_HANDLE without changing the ABI on
> > > > >> > x86_32 or x86_64.
> > > > > 
> > > > > Except we need both foreign_domid and size, which currently
> > > > > overlap, and there's no other spare bits. Damn.
> > > > > 
> > > > > Looks like XENMEM_add_to_physmap_range is the only option :-(
> > > > 
> > > > You could use the first entry in each array to specify the
> > > > counts, which would at once allow mixed granularity on each
> > > > list (should that ever turn out useful); initially you would
> > > > certainly want both counts to match.
> > > 
> > > I think it would be better from the interface point of view to
> > > have idx become the number of frames, and gpfn a pointer (a
> > > GUEST_HANDLE) to a struct that contains both arrays.
> > 
> > We'd need to slip in enough info to allow continuations too. Perhaps
> > that can be done by manipulating the size and the handle to keep
> > track of progress. Or maybe we can get away with just just frobbing
> > the size if we process the array backwards.
> > 
> > Which is all sounding pretty gross. I'm very temped to add
> > add_to_physmap2...
> 
> Yeah, I am OK with that.

Agree, pmap2.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 14 23:10:06 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 14 Sep 2012 23: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 1TCf13-00045F-Gv; Fri, 14 Sep 2012 23:09:41 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mukesh.rathor@oracle.com>) id 1TCf11-000453-VH
	for xen-devel@lists.xensource.com; Fri, 14 Sep 2012 23:09:40 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1347664172!9666173!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDc1MzA3MQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29399 invoked from network); 14 Sep 2012 23:09:33 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-16.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 14 Sep 2012 23:09:33 -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 q8EN9LCa014250
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 14 Sep 2012 23:09:21 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q8EN9JHi014682
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 14 Sep 2012 23:09:20 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
	q8EN9JnO011262; Fri, 14 Sep 2012 18:09:19 -0500
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 14 Sep 2012 16:09:19 -0700
Date: Fri, 14 Sep 2012 16:09:18 -0700
From: Mukesh Rathor <mukesh.rathor@oracle.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20120914160918.7e61d1d0@mantra.us.oracle.com>
In-Reply-To: <alpine.DEB.2.02.1209141652440.29232@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1208221159560.15568@kaball.uk.xensource.com>
	<1345633688-31684-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<1347627587.24226.192.camel@zakaz.uk.xensource.com>
	<1347628660.24226.197.camel@zakaz.uk.xensource.com>
	<1347630442.24226.211.camel@zakaz.uk.xensource.com>
	<1347630971.24226.214.camel@zakaz.uk.xensource.com>
	<50535AFA020000780009B7C4@nat28.tlf.novell.com>
	<alpine.DEB.2.02.1209141631200.29232@kaball.uk.xensource.com>
	<1347637953.14977.10.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.02.1209141652440.29232@kaball.uk.xensource.com>
Organization: Oracle Corporation
X-Mailer: Claws Mail 3.7.6 (GTK+ 2.18.9; x86_64-redhat-linux-gnu)
Mime-Version: 1.0
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Keir \(Xen.org\)" <keir@xen.org>,
	Ian Campbell <Ian.Campbell@citrix.com>, "Tim \(Xen.org\)" <tim@xen.org>,
	"ijackson@chiark.greenend.org.uk" <ijackson@chiark.greenend.org.uk>,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH v4 1/6] xen: improve changes to
 xen_add_to_physmap
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 14 Sep 2012 16:54:06 +0100
Stefano Stabellini <stefano.stabellini@eu.citrix.com> wrote:

> On Fri, 14 Sep 2012, Ian Campbell wrote:
> > On Fri, 2012-09-14 at 16:44 +0100, Stefano Stabellini wrote:
> > > On Fri, 14 Sep 2012, Jan Beulich wrote:
> > > > >>> On 14.09.12 at 15:56, Ian Campbell
> > > > >>> <Ian.Campbell@citrix.com> wrote:
> > > > >> > > Might we prefer to have a batched version of this call?
> > > > >> > > I don't think we can shoehorn the necessary fields into
> > > > >> > > xen_add_to_physmap_t though.
> > > > >> > 
> > > > >> > Actually, talking about this we Stefano we think we can.
> > > > >> > Since both idx and gpfn are unsigned longs they can become
> > > > >> > unions with a GUEST_HANDLE without changing the ABI on
> > > > >> > x86_32 or x86_64.
> > > > > 
> > > > > Except we need both foreign_domid and size, which currently
> > > > > overlap, and there's no other spare bits. Damn.
> > > > > 
> > > > > Looks like XENMEM_add_to_physmap_range is the only option :-(
> > > > 
> > > > You could use the first entry in each array to specify the
> > > > counts, which would at once allow mixed granularity on each
> > > > list (should that ever turn out useful); initially you would
> > > > certainly want both counts to match.
> > > 
> > > I think it would be better from the interface point of view to
> > > have idx become the number of frames, and gpfn a pointer (a
> > > GUEST_HANDLE) to a struct that contains both arrays.
> > 
> > We'd need to slip in enough info to allow continuations too. Perhaps
> > that can be done by manipulating the size and the handle to keep
> > track of progress. Or maybe we can get away with just just frobbing
> > the size if we process the array backwards.
> > 
> > Which is all sounding pretty gross. I'm very temped to add
> > add_to_physmap2...
> 
> Yeah, I am OK with that.

Agree, pmap2.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Sep 15 03:16:22 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 15 Sep 2012 03: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 1TCir9-0000yc-CE; Sat, 15 Sep 2012 03:15:43 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1TCir8-0000yX-Hq
	for xen-devel@lists.xensource.com; Sat, 15 Sep 2012 03:15:42 +0000
Received: from [85.158.138.51:44684] by server-4.bemta-3.messagelabs.com id
	CA/6F-24831-DD2F3505; Sat, 15 Sep 2012 03:15:41 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1347678940!28952532!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDk0Nzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4355 invoked from network); 15 Sep 2012 03:15:41 -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;
	15 Sep 2012 03:15:41 -0000
X-IronPort-AV: E=Sophos;i="4.80,425,1344211200"; d="scan'208";a="14558721"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Sep 2012 03:15:40 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Sat, 15 Sep 2012 04:15: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 1TCir6-0006Kl-1r;
	Sat, 15 Sep 2012 03:15:40 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1TCir5-0001fl-LT;
	Sat, 15 Sep 2012 04:15:39 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-13769-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sat, 15 Sep 2012 04:15:39 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13769: 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 13769 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13769/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore            fail   like 13764
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail like 13764
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail like 13764

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  12fa949b9060
baseline version:
 xen                  a177725aa492

------------------------------------------------------------
People who touched revisions under test:
  Jan Beulich <jbeulich@suse.com>
  Keir Fraser <keir@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-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-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-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-amd64-amd64-xl-win                                      fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=xen-unstable
+ revision=12fa949b9060
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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 12fa949b9060
+ branch=xen-unstable
+ revision=12fa949b9060
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-unstable
+ '[' xxen = xlinux ']'
+ linuxbranch=linux
+ : master
+ : tested/2.6.39.x
+ . ap-common
++ : xen@xenbits.xensource.com
++ : http://xenbits.xen.org/hg/staging/xen-unstable.hg
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : xen@xenbits.xensource.com:git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.xen-unstable
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-unstable.git
++ : daily-cron.xen-unstable
+ TREE_LINUX=xen@xenbits.xensource.com:git/linux-pvops.git
+ TREE_QEMU_UPSTREAM=xen@xenbits.xensource.com:git/qemu-upstream-unstable.git
+ info_linux_tree xen-unstable
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/xen-unstable.hg
+ hg push -r 12fa949b9060 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 Sat Sep 15 03:16:22 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 15 Sep 2012 03: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 1TCir9-0000yc-CE; Sat, 15 Sep 2012 03:15:43 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1TCir8-0000yX-Hq
	for xen-devel@lists.xensource.com; Sat, 15 Sep 2012 03:15:42 +0000
Received: from [85.158.138.51:44684] by server-4.bemta-3.messagelabs.com id
	CA/6F-24831-DD2F3505; Sat, 15 Sep 2012 03:15:41 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1347678940!28952532!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDk0Nzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4355 invoked from network); 15 Sep 2012 03:15:41 -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;
	15 Sep 2012 03:15:41 -0000
X-IronPort-AV: E=Sophos;i="4.80,425,1344211200"; d="scan'208";a="14558721"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Sep 2012 03:15:40 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Sat, 15 Sep 2012 04:15: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 1TCir6-0006Kl-1r;
	Sat, 15 Sep 2012 03:15:40 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1TCir5-0001fl-LT;
	Sat, 15 Sep 2012 04:15:39 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-13769-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sat, 15 Sep 2012 04:15:39 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13769: 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 13769 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13769/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore            fail   like 13764
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail like 13764
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail like 13764

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  12fa949b9060
baseline version:
 xen                  a177725aa492

------------------------------------------------------------
People who touched revisions under test:
  Jan Beulich <jbeulich@suse.com>
  Keir Fraser <keir@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-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-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-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-amd64-amd64-xl-win                                      fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=xen-unstable
+ revision=12fa949b9060
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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 12fa949b9060
+ branch=xen-unstable
+ revision=12fa949b9060
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-unstable
+ '[' xxen = xlinux ']'
+ linuxbranch=linux
+ : master
+ : tested/2.6.39.x
+ . ap-common
++ : xen@xenbits.xensource.com
++ : http://xenbits.xen.org/hg/staging/xen-unstable.hg
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : xen@xenbits.xensource.com:git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.xen-unstable
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-unstable.git
++ : daily-cron.xen-unstable
+ TREE_LINUX=xen@xenbits.xensource.com:git/linux-pvops.git
+ TREE_QEMU_UPSTREAM=xen@xenbits.xensource.com:git/qemu-upstream-unstable.git
+ info_linux_tree xen-unstable
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/xen-unstable.hg
+ hg push -r 12fa949b9060 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 Sat Sep 15 05:06:40 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 15 Sep 2012 05:06:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TCkZp-0001gt-6g; Sat, 15 Sep 2012 05:05: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 1TCkZn-0001go-Tr
	for xen-devel@lists.xensource.com; Sat, 15 Sep 2012 05:05:56 +0000
Received: from [85.158.143.35:62975] by server-3.bemta-4.messagelabs.com id
	9B/38-08232-3BC04505; Sat, 15 Sep 2012 05:05:55 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1347685554!6632133!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDk0Nzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13772 invoked from network); 15 Sep 2012 05:05:54 -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;
	15 Sep 2012 05:05:54 -0000
X-IronPort-AV: E=Sophos;i="4.80,426,1344211200"; d="scan'208";a="14559204"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Sep 2012 05:05: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.279.1; Sat, 15 Sep 2012 06:05: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 1TCkZk-0006uf-SM;
	Sat, 15 Sep 2012 05:05:52 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1TCkZk-0004oZ-9Q;
	Sat, 15 Sep 2012 06:05:52 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-13770-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sat, 15 Sep 2012 06:05:52 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [qemu-upstream-4.2-testing baseline test] 13770:
	tolerable FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

"Old" tested version had not actually been tested; therefore in this
flight we test it, rather than a new candidate.  The baseline, if
any, is the most recent actually tested revision.

flight 13770 qemu-upstream-4.2-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13770/

Failures :-/ but no regressions.

Tests which did not succeed,
including tests which could not be run:
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  9 guest-localmigrate fail never pass
 test-i386-i386-xl-qemuu-win   9 guest-localmigrate           fail   never pass
 test-amd64-amd64-qemuu-win   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64  9 guest-localmigrate      fail never pass
 test-amd64-i386-xl-qemuu-win-vcpus1  9 guest-localmigrate      fail never pass
 test-amd64-i386-xend-qemuu-winxpsp3 16 leak-check/check        fail never pass
 test-i386-i386-qemuu-win     16 leak-check/check             fail   never pass
 test-amd64-i386-qemuu-win-vcpus1 16 leak-check/check           fail never pass
 test-amd64-i386-qemuu-win    16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemuu-win  9 guest-localmigrate           fail  never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail never pass
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass


jobs:
 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                           pass    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-win-vcpus1                             fail    
 test-amd64-i386-xl-qemuu-win-vcpus1                          fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-amd64-qemuu-win                                   fail    
 test-amd64-i386-qemuu-win                                    fail    
 test-i386-i386-qemuu-win                                     fail    
 test-amd64-amd64-xl-qemuu-win                                fail    
 test-i386-i386-xl-qemuu-win                                  fail    
 test-amd64-i386-xend-qemuu-winxpsp3                          fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


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 Sep 15 05:06:40 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 15 Sep 2012 05:06:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TCkZp-0001gt-6g; Sat, 15 Sep 2012 05:05: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 1TCkZn-0001go-Tr
	for xen-devel@lists.xensource.com; Sat, 15 Sep 2012 05:05:56 +0000
Received: from [85.158.143.35:62975] by server-3.bemta-4.messagelabs.com id
	9B/38-08232-3BC04505; Sat, 15 Sep 2012 05:05:55 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1347685554!6632133!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDk0Nzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13772 invoked from network); 15 Sep 2012 05:05:54 -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;
	15 Sep 2012 05:05:54 -0000
X-IronPort-AV: E=Sophos;i="4.80,426,1344211200"; d="scan'208";a="14559204"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Sep 2012 05:05: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.279.1; Sat, 15 Sep 2012 06:05: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 1TCkZk-0006uf-SM;
	Sat, 15 Sep 2012 05:05:52 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1TCkZk-0004oZ-9Q;
	Sat, 15 Sep 2012 06:05:52 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-13770-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sat, 15 Sep 2012 06:05:52 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [qemu-upstream-4.2-testing baseline test] 13770:
	tolerable FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

"Old" tested version had not actually been tested; therefore in this
flight we test it, rather than a new candidate.  The baseline, if
any, is the most recent actually tested revision.

flight 13770 qemu-upstream-4.2-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13770/

Failures :-/ but no regressions.

Tests which did not succeed,
including tests which could not be run:
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  9 guest-localmigrate fail never pass
 test-i386-i386-xl-qemuu-win   9 guest-localmigrate           fail   never pass
 test-amd64-amd64-qemuu-win   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64  9 guest-localmigrate      fail never pass
 test-amd64-i386-xl-qemuu-win-vcpus1  9 guest-localmigrate      fail never pass
 test-amd64-i386-xend-qemuu-winxpsp3 16 leak-check/check        fail never pass
 test-i386-i386-qemuu-win     16 leak-check/check             fail   never pass
 test-amd64-i386-qemuu-win-vcpus1 16 leak-check/check           fail never pass
 test-amd64-i386-qemuu-win    16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemuu-win  9 guest-localmigrate           fail  never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail never pass
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass


jobs:
 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                           pass    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-win-vcpus1                             fail    
 test-amd64-i386-xl-qemuu-win-vcpus1                          fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-amd64-qemuu-win                                   fail    
 test-amd64-i386-qemuu-win                                    fail    
 test-i386-i386-qemuu-win                                     fail    
 test-amd64-amd64-xl-qemuu-win                                fail    
 test-i386-i386-xl-qemuu-win                                  fail    
 test-amd64-i386-xend-qemuu-winxpsp3                          fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


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 Sep 15 09:34:44 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 15 Sep 2012 09:34:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TColH-0003l4-3I; Sat, 15 Sep 2012 09:34: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 1TColF-0003kz-9Y
	for xen-devel@lists.xensource.com; Sat, 15 Sep 2012 09:34:01 +0000
Received: from [85.158.143.35:32373] by server-2.bemta-4.messagelabs.com id
	C1/B1-21239-88B44505; Sat, 15 Sep 2012 09:34:00 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1347701640!11597100!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDk0Nzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24664 invoked from network); 15 Sep 2012 09:34:00 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Sep 2012 09:34:00 -0000
X-IronPort-AV: E=Sophos;i="4.80,426,1344211200"; d="scan'208";a="14560117"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Sep 2012 09:33: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.279.1; Sat, 15 Sep 2012 10:33:59 +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 1TColD-0008Lw-Ds;
	Sat, 15 Sep 2012 09:33:59 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1TColC-0003jv-TM;
	Sat, 15 Sep 2012 10:33:59 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-13772-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sat, 15 Sep 2012 10:33:58 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13772: 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 13772 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13772/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore            fail   like 13769
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail like 13769
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail like 13769

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  12fa949b9060
baseline version:
 xen                  12fa949b9060

jobs:
 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-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-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-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-amd64-amd64-xl-win                                      fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Published tested tree is already up to date.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Sep 15 09:34:44 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 15 Sep 2012 09:34:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TColH-0003l4-3I; Sat, 15 Sep 2012 09:34: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 1TColF-0003kz-9Y
	for xen-devel@lists.xensource.com; Sat, 15 Sep 2012 09:34:01 +0000
Received: from [85.158.143.35:32373] by server-2.bemta-4.messagelabs.com id
	C1/B1-21239-88B44505; Sat, 15 Sep 2012 09:34:00 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1347701640!11597100!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDk0Nzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24664 invoked from network); 15 Sep 2012 09:34:00 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Sep 2012 09:34:00 -0000
X-IronPort-AV: E=Sophos;i="4.80,426,1344211200"; d="scan'208";a="14560117"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Sep 2012 09:33: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.279.1; Sat, 15 Sep 2012 10:33:59 +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 1TColD-0008Lw-Ds;
	Sat, 15 Sep 2012 09:33:59 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1TColC-0003jv-TM;
	Sat, 15 Sep 2012 10:33:59 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-13772-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sat, 15 Sep 2012 10:33:58 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13772: 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 13772 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13772/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore            fail   like 13769
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail like 13769
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail like 13769

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  12fa949b9060
baseline version:
 xen                  12fa949b9060

jobs:
 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-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-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-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-amd64-amd64-xl-win                                      fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Published tested tree is already up to date.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Sep 15 11:29:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 15 Sep 2012 11:29:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TCqY3-0004GC-WE; Sat, 15 Sep 2012 11:28: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 1TCqY3-0004G7-6N
	for xen-devel@lists.xensource.com; Sat, 15 Sep 2012 11:28:31 +0000
Received: from [85.158.139.211:41502] by server-11.bemta-5.messagelabs.com id
	91/FA-24658-E5664505; Sat, 15 Sep 2012 11:28:30 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-206.messagelabs.com!1347708509!18644850!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDk0Nzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5891 invoked from network); 15 Sep 2012 11:28:29 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Sep 2012 11:28:29 -0000
X-IronPort-AV: E=Sophos;i="4.80,426,1344211200"; d="scan'208";a="14560454"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Sep 2012 11:28: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.279.1; Sat, 15 Sep 2012 12:28: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 1TCqY0-0000f2-On;
	Sat, 15 Sep 2012 11:28:28 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1TCqY0-0005es-8y;
	Sat, 15 Sep 2012 12:28:28 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-13773-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sat, 15 Sep 2012 12:28:28 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [qemu-upstream-4.2-testing baseline test] 13773:
	tolerable FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

"Old" tested version had not actually been tested; therefore in this
flight we test it, rather than a new candidate.  The baseline, if
any, is the most recent actually tested revision.

flight 13773 qemu-upstream-4.2-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13773/

Failures :-/ but no regressions.

Tests which did not succeed,
including tests which could not be run:
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  9 guest-localmigrate fail never pass
 test-i386-i386-xl-qemuu-win   9 guest-localmigrate           fail   never pass
 test-amd64-amd64-qemuu-win   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64  9 guest-localmigrate      fail never pass
 test-amd64-i386-xl-qemuu-win-vcpus1  9 guest-localmigrate      fail never pass
 test-amd64-i386-xend-qemuu-winxpsp3 16 leak-check/check        fail never pass
 test-i386-i386-qemuu-win     16 leak-check/check             fail   never pass
 test-amd64-i386-qemuu-win-vcpus1 16 leak-check/check           fail never pass
 test-amd64-i386-qemuu-win    16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemuu-win  9 guest-localmigrate           fail  never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail never pass
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass


jobs:
 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                           pass    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-win-vcpus1                             fail    
 test-amd64-i386-xl-qemuu-win-vcpus1                          fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-amd64-qemuu-win                                   fail    
 test-amd64-i386-qemuu-win                                    fail    
 test-i386-i386-qemuu-win                                     fail    
 test-amd64-amd64-xl-qemuu-win                                fail    
 test-i386-i386-xl-qemuu-win                                  fail    
 test-amd64-i386-xend-qemuu-winxpsp3                          fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


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 Sep 15 11:29:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 15 Sep 2012 11:29:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TCqY3-0004GC-WE; Sat, 15 Sep 2012 11:28: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 1TCqY3-0004G7-6N
	for xen-devel@lists.xensource.com; Sat, 15 Sep 2012 11:28:31 +0000
Received: from [85.158.139.211:41502] by server-11.bemta-5.messagelabs.com id
	91/FA-24658-E5664505; Sat, 15 Sep 2012 11:28:30 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-206.messagelabs.com!1347708509!18644850!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDk0Nzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5891 invoked from network); 15 Sep 2012 11:28:29 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Sep 2012 11:28:29 -0000
X-IronPort-AV: E=Sophos;i="4.80,426,1344211200"; d="scan'208";a="14560454"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Sep 2012 11:28: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.279.1; Sat, 15 Sep 2012 12:28: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 1TCqY0-0000f2-On;
	Sat, 15 Sep 2012 11:28:28 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1TCqY0-0005es-8y;
	Sat, 15 Sep 2012 12:28:28 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-13773-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sat, 15 Sep 2012 12:28:28 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [qemu-upstream-4.2-testing baseline test] 13773:
	tolerable FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

"Old" tested version had not actually been tested; therefore in this
flight we test it, rather than a new candidate.  The baseline, if
any, is the most recent actually tested revision.

flight 13773 qemu-upstream-4.2-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13773/

Failures :-/ but no regressions.

Tests which did not succeed,
including tests which could not be run:
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  9 guest-localmigrate fail never pass
 test-i386-i386-xl-qemuu-win   9 guest-localmigrate           fail   never pass
 test-amd64-amd64-qemuu-win   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64  9 guest-localmigrate      fail never pass
 test-amd64-i386-xl-qemuu-win-vcpus1  9 guest-localmigrate      fail never pass
 test-amd64-i386-xend-qemuu-winxpsp3 16 leak-check/check        fail never pass
 test-i386-i386-qemuu-win     16 leak-check/check             fail   never pass
 test-amd64-i386-qemuu-win-vcpus1 16 leak-check/check           fail never pass
 test-amd64-i386-qemuu-win    16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemuu-win  9 guest-localmigrate           fail  never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail never pass
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass


jobs:
 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                           pass    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-win-vcpus1                             fail    
 test-amd64-i386-xl-qemuu-win-vcpus1                          fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-amd64-qemuu-win                                   fail    
 test-amd64-i386-qemuu-win                                    fail    
 test-i386-i386-qemuu-win                                     fail    
 test-amd64-amd64-xl-qemuu-win                                fail    
 test-i386-i386-xl-qemuu-win                                  fail    
 test-amd64-i386-xend-qemuu-winxpsp3                          fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


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 Sep 15 14:09:22 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 15 Sep 2012 14:09:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TCt34-0005a0-OY; Sat, 15 Sep 2012 14:08:42 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <nitin.kobain@gmail.com>) id 1TCsTD-0004qN-Ep
	for xen-devel@lists.xen.org; Sat, 15 Sep 2012 13:31:39 +0000
Received: from [85.158.137.99:12435] by server-2.bemta-3.messagelabs.com id
	FA/A7-04862-A3384505; Sat, 15 Sep 2012 13:31:38 +0000
X-Env-Sender: nitin.kobain@gmail.com
X-Msg-Ref: server-10.tower-217.messagelabs.com!1347715896!17804521!1
X-Originating-IP: [209.85.212.45]
X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_10_20,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26135 invoked from network); 15 Sep 2012 13:31:37 -0000
Received: from mail-vb0-f45.google.com (HELO mail-vb0-f45.google.com)
	(209.85.212.45)
	by server-10.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Sep 2012 13:31:37 -0000
Received: by vbip1 with SMTP id p1so7109002vbi.32
	for <xen-devel@lists.xen.org>; Sat, 15 Sep 2012 06:31:36 -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=e4Z98prLYSbQIO6cwn4qX4ztbSOaczbnlN42jWrsNGI=;
	b=L+YZsAmAEtocFndY9KX1fKHsBQnCWOV491HR5T50H8uV9OMgQ7toHVLeRMlmHx8W3j
	iiRM/px51Vly6pyRKWtF6Hpqs2AngoSGBxFyCqdax26yThvv9RjrsbXHZ60I6xkG0qNt
	xCYDuRjYm3jBj1/1CNAOrvyahIpLdNB0jAPzyKx5gmfzGjv8syLInWFNDOkaxiMYbOtq
	MUtY2TijQrjLWXluNhNmtv1tWh3b1muWs6DvuxgW/XF+wqrpiJ6msmeTYHpEX5uCYcs+
	bvHvG4U3IZuV3Ybk8JadnJOfaUxNyUnI4ct0g6OKcnxOWB2j06/PxaSg0xgb7gl/7p4u
	0hYQ==
Received: by 10.220.150.15 with SMTP id w15mr4482130vcv.68.1347715896224; Sat,
	15 Sep 2012 06:31:36 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.58.102.37 with HTTP; Sat, 15 Sep 2012 06:30:56 -0700 (PDT)
From: Nitin Gupta <nitin.kobain@gmail.com>
Date: Sat, 15 Sep 2012 19:00:56 +0530
Message-ID: <CAESzvYTsHm+QYiP6TCYXUC3AWfP-LuzvxOVYN7bnd6MF=a3v6Q@mail.gmail.com>
To: xen-devel@lists.xen.org
X-Mailman-Approved-At: Sat, 15 Sep 2012 14:08:41 +0000
Subject: [Xen-devel] domu to dom0's entry point
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============6325258916719125104=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============6325258916719125104==
Content-Type: multipart/alternative; boundary=f46d0438911540a98e04c9bd8f81

--f46d0438911540a98e04c9bd8f81
Content-Type: text/plain; charset=ISO-8859-1

Hi,

I have a query.

Dom0 is the administrative kernel which can access I/O devices through
hypervisor. So if an application wants to write to an I/O device then it
should go through Dom0. Is it right? If its so then can anyone point to the
entry and exit points in Dom0.

-- 
Regards,
Nitin Gupta

--f46d0438911540a98e04c9bd8f81
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi,<br><br>I have a query.<br><br>Dom0 is the administrative kernel which c=
an access I/O devices through hypervisor. So if an application wants to wri=
te to an I/O device then it should go through Dom0. Is it right? If its so =
then can anyone point to the entry and exit points in Dom0.=A0 =A0 <br clea=
r=3D"all">

<br>-- <br>Regards,<br>Nitin Gupta<br><br><br>

--f46d0438911540a98e04c9bd8f81--


--===============6325258916719125104==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============6325258916719125104==--


From xen-devel-bounces@lists.xen.org Sat Sep 15 14:09:22 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 15 Sep 2012 14:09:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TCt34-0005a0-OY; Sat, 15 Sep 2012 14:08:42 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <nitin.kobain@gmail.com>) id 1TCsTD-0004qN-Ep
	for xen-devel@lists.xen.org; Sat, 15 Sep 2012 13:31:39 +0000
Received: from [85.158.137.99:12435] by server-2.bemta-3.messagelabs.com id
	FA/A7-04862-A3384505; Sat, 15 Sep 2012 13:31:38 +0000
X-Env-Sender: nitin.kobain@gmail.com
X-Msg-Ref: server-10.tower-217.messagelabs.com!1347715896!17804521!1
X-Originating-IP: [209.85.212.45]
X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_10_20,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26135 invoked from network); 15 Sep 2012 13:31:37 -0000
Received: from mail-vb0-f45.google.com (HELO mail-vb0-f45.google.com)
	(209.85.212.45)
	by server-10.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Sep 2012 13:31:37 -0000
Received: by vbip1 with SMTP id p1so7109002vbi.32
	for <xen-devel@lists.xen.org>; Sat, 15 Sep 2012 06:31:36 -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=e4Z98prLYSbQIO6cwn4qX4ztbSOaczbnlN42jWrsNGI=;
	b=L+YZsAmAEtocFndY9KX1fKHsBQnCWOV491HR5T50H8uV9OMgQ7toHVLeRMlmHx8W3j
	iiRM/px51Vly6pyRKWtF6Hpqs2AngoSGBxFyCqdax26yThvv9RjrsbXHZ60I6xkG0qNt
	xCYDuRjYm3jBj1/1CNAOrvyahIpLdNB0jAPzyKx5gmfzGjv8syLInWFNDOkaxiMYbOtq
	MUtY2TijQrjLWXluNhNmtv1tWh3b1muWs6DvuxgW/XF+wqrpiJ6msmeTYHpEX5uCYcs+
	bvHvG4U3IZuV3Ybk8JadnJOfaUxNyUnI4ct0g6OKcnxOWB2j06/PxaSg0xgb7gl/7p4u
	0hYQ==
Received: by 10.220.150.15 with SMTP id w15mr4482130vcv.68.1347715896224; Sat,
	15 Sep 2012 06:31:36 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.58.102.37 with HTTP; Sat, 15 Sep 2012 06:30:56 -0700 (PDT)
From: Nitin Gupta <nitin.kobain@gmail.com>
Date: Sat, 15 Sep 2012 19:00:56 +0530
Message-ID: <CAESzvYTsHm+QYiP6TCYXUC3AWfP-LuzvxOVYN7bnd6MF=a3v6Q@mail.gmail.com>
To: xen-devel@lists.xen.org
X-Mailman-Approved-At: Sat, 15 Sep 2012 14:08:41 +0000
Subject: [Xen-devel] domu to dom0's entry point
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============6325258916719125104=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============6325258916719125104==
Content-Type: multipart/alternative; boundary=f46d0438911540a98e04c9bd8f81

--f46d0438911540a98e04c9bd8f81
Content-Type: text/plain; charset=ISO-8859-1

Hi,

I have a query.

Dom0 is the administrative kernel which can access I/O devices through
hypervisor. So if an application wants to write to an I/O device then it
should go through Dom0. Is it right? If its so then can anyone point to the
entry and exit points in Dom0.

-- 
Regards,
Nitin Gupta

--f46d0438911540a98e04c9bd8f81
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi,<br><br>I have a query.<br><br>Dom0 is the administrative kernel which c=
an access I/O devices through hypervisor. So if an application wants to wri=
te to an I/O device then it should go through Dom0. Is it right? If its so =
then can anyone point to the entry and exit points in Dom0.=A0 =A0 <br clea=
r=3D"all">

<br>-- <br>Regards,<br>Nitin Gupta<br><br><br>

--f46d0438911540a98e04c9bd8f81--


--===============6325258916719125104==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============6325258916719125104==--


From xen-devel-bounces@lists.xen.org Sat Sep 15 15:56:06 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 15 Sep 2012 15:56:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TCuiH-0006A0-UA; Sat, 15 Sep 2012 15:55: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 1TCuiF-00069v-Qv
	for xen-devel@lists.xensource.com; Sat, 15 Sep 2012 15:55:20 +0000
Received: from [85.158.139.83:40232] by server-5.bemta-5.messagelabs.com id
	5A/75-30514-6E4A4505; Sat, 15 Sep 2012 15:55:18 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1347724517!26768121!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDk2MjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20278 invoked from network); 15 Sep 2012 15:55:18 -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;
	15 Sep 2012 15:55:18 -0000
X-IronPort-AV: E=Sophos;i="4.80,428,1344211200"; d="scan'208";a="14561895"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Sep 2012 15:55: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.279.1; Sat, 15 Sep 2012 16:55: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 1TCuiC-0002Dm-Lo;
	Sat, 15 Sep 2012 15:55:16 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1TCuiC-0003iC-Ek;
	Sat, 15 Sep 2012 16:55:16 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-13775-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sat, 15 Sep 2012 16:55:16 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-linus test] 13775: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 13775 linux-linus real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13775/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-credit2    5 xen-boot                  fail REGR. vs. 12557
 test-amd64-i386-xl-multivcpu  5 xen-boot                  fail REGR. vs. 12557

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin 14 guest-localmigrate/x10    fail REGR. vs. 12557

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  5 xen-boot                    fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  5 xen-boot               fail never pass
 test-amd64-i386-rhel6hvm-intel  5 xen-boot                     fail never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass

version targeted for testing:
 linux                3f0c3c8fe30c725c1264fb6db8cc4b69db3a658a
baseline version:
 linux                c16fa4f2ad19908a47c63d8fa436a1178438c7e7

------------------------------------------------------------
People who touched revisions under test:
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           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                                   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-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-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-amd64-amd64-xl-win                                      fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
commit 3f0c3c8fe30c725c1264fb6db8cc4b69db3a658a
Merge: 9cb0ee8... 62e252e...
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date:   Fri Sep 14 18:05:14 2012 -0700

    Merge git://git.kernel.org/pub/scm/linux/kernel/git/steve/gfs2-3.0-fixes
    
    Pull GFS2 fixes from Steven Whitehouse:
     "Here are three GFS2 fixes for the current kernel tree.  These are all
      related to the block reservation code which was added at the merge
      window.  That code will be getting an update at the forthcoming merge
      window too.  In the mean time though there are a few smaller issues
      which should be fixed.
    
      The first patch resolves an issue with write sizes of greater than 32
      bits with the size hinting code.  The second ensures that the
      allocation data structure is initialised when using xattrs and the
      third takes into account allocations which may have been made by other
      nodes which affect a reservation on the local node."
    
    * git://git.kernel.org/pub/scm/linux/kernel/git/steve/gfs2-3.0-fixes:
      GFS2: Take account of blockages when using reserved blocks
      GFS2: Fix missing allocation data for set/remove xattr
      GFS2: Make write size hinting code common

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Sep 15 15:56:06 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 15 Sep 2012 15:56:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TCuiH-0006A0-UA; Sat, 15 Sep 2012 15:55: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 1TCuiF-00069v-Qv
	for xen-devel@lists.xensource.com; Sat, 15 Sep 2012 15:55:20 +0000
Received: from [85.158.139.83:40232] by server-5.bemta-5.messagelabs.com id
	5A/75-30514-6E4A4505; Sat, 15 Sep 2012 15:55:18 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1347724517!26768121!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDk2MjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20278 invoked from network); 15 Sep 2012 15:55:18 -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;
	15 Sep 2012 15:55:18 -0000
X-IronPort-AV: E=Sophos;i="4.80,428,1344211200"; d="scan'208";a="14561895"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Sep 2012 15:55: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.279.1; Sat, 15 Sep 2012 16:55: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 1TCuiC-0002Dm-Lo;
	Sat, 15 Sep 2012 15:55:16 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1TCuiC-0003iC-Ek;
	Sat, 15 Sep 2012 16:55:16 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-13775-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sat, 15 Sep 2012 16:55:16 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-linus test] 13775: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 13775 linux-linus real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13775/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-credit2    5 xen-boot                  fail REGR. vs. 12557
 test-amd64-i386-xl-multivcpu  5 xen-boot                  fail REGR. vs. 12557

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin 14 guest-localmigrate/x10    fail REGR. vs. 12557

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  5 xen-boot                    fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  5 xen-boot               fail never pass
 test-amd64-i386-rhel6hvm-intel  5 xen-boot                     fail never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass

version targeted for testing:
 linux                3f0c3c8fe30c725c1264fb6db8cc4b69db3a658a
baseline version:
 linux                c16fa4f2ad19908a47c63d8fa436a1178438c7e7

------------------------------------------------------------
People who touched revisions under test:
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           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                                   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-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-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-amd64-amd64-xl-win                                      fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
commit 3f0c3c8fe30c725c1264fb6db8cc4b69db3a658a
Merge: 9cb0ee8... 62e252e...
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date:   Fri Sep 14 18:05:14 2012 -0700

    Merge git://git.kernel.org/pub/scm/linux/kernel/git/steve/gfs2-3.0-fixes
    
    Pull GFS2 fixes from Steven Whitehouse:
     "Here are three GFS2 fixes for the current kernel tree.  These are all
      related to the block reservation code which was added at the merge
      window.  That code will be getting an update at the forthcoming merge
      window too.  In the mean time though there are a few smaller issues
      which should be fixed.
    
      The first patch resolves an issue with write sizes of greater than 32
      bits with the size hinting code.  The second ensures that the
      allocation data structure is initialised when using xattrs and the
      third takes into account allocations which may have been made by other
      nodes which affect a reservation on the local node."
    
    * git://git.kernel.org/pub/scm/linux/kernel/git/steve/gfs2-3.0-fixes:
      GFS2: Take account of blockages when using reserved blocks
      GFS2: Fix missing allocation data for set/remove xattr
      GFS2: Make write size hinting code common

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Sep 15 17:27:37 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 15 Sep 2012 17: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 1TCw8x-0006yF-VD; Sat, 15 Sep 2012 17:26: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 1TCw8x-0006yA-6y
	for xen-devel@lists.xensource.com; Sat, 15 Sep 2012 17:26:59 +0000
Received: from [85.158.137.99:2537] by server-5.bemta-3.messagelabs.com id
	CB/96-13133-26AB4505; Sat, 15 Sep 2012 17:26:58 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-217.messagelabs.com!1347730017!14646911!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDk2MjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21260 invoked from network); 15 Sep 2012 17:26:57 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Sep 2012 17:26:57 -0000
X-IronPort-AV: E=Sophos;i="4.80,428,1344211200"; d="scan'208";a="14562071"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Sep 2012 17:26: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.279.1; Sat, 15 Sep 2012 18:26: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 1TCw8u-0002kE-6N;
	Sat, 15 Sep 2012 17:26:56 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1TCw8t-0000WX-OU;
	Sat, 15 Sep 2012 18:26:55 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-13776-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sat, 15 Sep 2012 18:26:55 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-mingo-tip-master test] 13776: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 13776 linux-mingo-tip-master real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13776/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xend-winxpsp3  5 xen-boot                 fail REGR. vs. 12678
 test-amd64-i386-xl-credit2    5 xen-boot                  fail REGR. vs. 12678
 test-amd64-amd64-pair         8 xen-boot/dst_host         fail REGR. vs. 12678
 test-amd64-amd64-pair         7 xen-boot/src_host         fail REGR. vs. 12678

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  5 xen-boot                    fail never pass
 test-amd64-i386-xl-win-vcpus1  5 xen-boot                     fail  never pass
 test-amd64-amd64-xl-win7-amd64  5 xen-boot                     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-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail never pass
 test-amd64-i386-pair          8 xen-boot/dst_host            fail   never pass
 test-amd64-i386-pair          7 xen-boot/src_host            fail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass

version targeted for testing:
 linux                2a346d40b9564288f5d41b441e14d6a4dae3be2b
baseline version:
 linux                d935d0f77650fea53986811ca8a2f8c726fd9857

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-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                                   fail    
 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                                        fail    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-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-amd64-amd64-xl-win                                      fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Sep 15 17:27:37 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 15 Sep 2012 17: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 1TCw8x-0006yF-VD; Sat, 15 Sep 2012 17:26: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 1TCw8x-0006yA-6y
	for xen-devel@lists.xensource.com; Sat, 15 Sep 2012 17:26:59 +0000
Received: from [85.158.137.99:2537] by server-5.bemta-3.messagelabs.com id
	CB/96-13133-26AB4505; Sat, 15 Sep 2012 17:26:58 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-217.messagelabs.com!1347730017!14646911!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDk2MjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21260 invoked from network); 15 Sep 2012 17:26:57 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Sep 2012 17:26:57 -0000
X-IronPort-AV: E=Sophos;i="4.80,428,1344211200"; d="scan'208";a="14562071"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Sep 2012 17:26: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.279.1; Sat, 15 Sep 2012 18:26: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 1TCw8u-0002kE-6N;
	Sat, 15 Sep 2012 17:26:56 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1TCw8t-0000WX-OU;
	Sat, 15 Sep 2012 18:26:55 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-13776-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sat, 15 Sep 2012 18:26:55 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-mingo-tip-master test] 13776: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 13776 linux-mingo-tip-master real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13776/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xend-winxpsp3  5 xen-boot                 fail REGR. vs. 12678
 test-amd64-i386-xl-credit2    5 xen-boot                  fail REGR. vs. 12678
 test-amd64-amd64-pair         8 xen-boot/dst_host         fail REGR. vs. 12678
 test-amd64-amd64-pair         7 xen-boot/src_host         fail REGR. vs. 12678

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  5 xen-boot                    fail never pass
 test-amd64-i386-xl-win-vcpus1  5 xen-boot                     fail  never pass
 test-amd64-amd64-xl-win7-amd64  5 xen-boot                     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-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail never pass
 test-amd64-i386-pair          8 xen-boot/dst_host            fail   never pass
 test-amd64-i386-pair          7 xen-boot/src_host            fail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass

version targeted for testing:
 linux                2a346d40b9564288f5d41b441e14d6a4dae3be2b
baseline version:
 linux                d935d0f77650fea53986811ca8a2f8c726fd9857

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-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                                   fail    
 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                                        fail    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-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-amd64-amd64-xl-win                                      fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Sep 15 19:55:48 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 15 Sep 2012 19:55:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TCySP-00084J-GP; Sat, 15 Sep 2012 19:55:13 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1TCySN-00084E-27
	for xen-devel@lists.xensource.com; Sat, 15 Sep 2012 19:55:11 +0000
Received: from [85.158.138.51:15024] by server-12.bemta-3.messagelabs.com id
	DD/15-10384-E1DD4505; Sat, 15 Sep 2012 19:55:10 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1347738908!22762551!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDk2MjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13282 invoked from network); 15 Sep 2012 19:55: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;
	15 Sep 2012 19:55:09 -0000
X-IronPort-AV: E=Sophos;i="4.80,428,1344211200"; d="scan'208";a="14562432"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Sep 2012 19:55: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.279.1; Sat, 15 Sep 2012 20:55: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 1TCySJ-0003XY-Gq;
	Sat, 15 Sep 2012 19:55:07 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1TCySJ-0004Hs-2T;
	Sat, 15 Sep 2012 20:55:07 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-13777-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sat, 15 Sep 2012 20:55:07 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-3.0 test] 13777: 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 13777 linux-3.0 real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13777/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin 14 guest-localmigrate/x10   fail blocked in 13637
 test-amd64-amd64-xl-sedf     14 guest-localmigrate/x10   fail blocked in 13637
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail like 13637
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail like 13637

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  8 debian-fixup                fail never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-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-win7-amd64 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

version targeted for testing:
 linux                3d2e7b3b3e876fae210e55c872df8f6750ab0fa3
baseline version:
 linux                5aa287dcf1b5879aa0150b0511833c52885f5b4c

------------------------------------------------------------
People who touched revisions under test:
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           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-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-amd64-amd64-xl-win                                      fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=linux-3.0
+ revision=3d2e7b3b3e876fae210e55c872df8f6750ab0fa3
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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 3d2e7b3b3e876fae210e55c872df8f6750ab0fa3
+ branch=linux-3.0
+ revision=3d2e7b3b3e876fae210e55c872df8f6750ab0fa3
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=linux
+ xenbranch=xen-unstable
+ '[' xlinux = xlinux ']'
+ linuxbranch=linux-3.0
+ : master
+ : tested/2.6.39.x
+ . ap-common
++ : xen@xenbits.xensource.com
++ : http://xenbits.xen.org/hg/staging/xen-unstable.hg
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
++ : master
++ : xen@xenbits.xensource.com:git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.linux-3.0
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-unstable.git
++ : daily-cron.linux-3.0
+ TREE_LINUX=xen@xenbits.xensource.com:git/linux-pvops.git
+ TREE_QEMU_UPSTREAM=xen@xenbits.xensource.com:git/qemu-upstream-unstable.git
+ info_linux_tree linux-3.0
+ case $1 in
+ : git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
+ : linux-3.0.y
+ : linux-3.0.y
+ : git
+ : git
+ : git://xenbits.xen.org/linux-pvops.git
+ : xen@xenbits.xensource.com:git/linux-pvops.git
+ : tested/linux-3.0
+ : tested/linux-3.0
+ return 0
+ cd /export/home/osstest/repos/linux
+ git push xen@xenbits.xensource.com:git/linux-pvops.git 3d2e7b3b3e876fae210e55c872df8f6750ab0fa3:tested/linux-3.0
Counting objects: 1   
Counting objects: 225   
Counting objects: 379, done.
Compressing objects:   2% (1/42)   
Compressing objects:   4% (2/42)   
Compressing objects:   7% (3/42)   
Compressing objects:   9% (4/42)   
Compressing objects:  11% (5/42)   
Compressing objects:  14% (6/42)   
Compressing objects:  16% (7/42)   
Compressing objects:  19% (8/42)   
Compressing objects:  21% (9/42)   
Compressing objects:  23% (10/42)   
Compressing objects:  26% (11/42)   
Compressing objects:  28% (12/42)   
Compressing objects:  30% (13/42)   
Compressing objects:  33% (14/42)   
Compressing objects:  35% (15/42)   
Compressing objects:  38% (16/42)   
Compressing objects:  40% (17/42)   
Compressing objects:  42% (18/42)   
Compressing objects:  45% (19/42)   
Compressing objects:  47% (20/42)   
Compressing objects:  50% (21/42)   
Compressing objects:  52% (22/42)   
Compressing objects:  54% (23/42)   
Compressing objects:  57% (24/42)   
Compressing objects:  59% (25/42)   
Compressing objects:  61% (26/42)   
Compressing objects:  64% (27/42)   
Compressing objects:  66% (28/42)   
Compressing objects:  69% (29/42)   
Compressing objects:  71% (30/42)   
Compressing objects:  73% (31/42)   
Compressing objects:  76% (32/42)   
Compressing objects:  78% (33/42)   
Compressing objects:  80% (34/42)   
Compressing objects:  83% (35/42)   
Compressing objects:  85% (36/42)   
Compressing objects:  88% (37/42)   
Compressing objects:  90% (38/42)   
Compressing objects:  92% (39/42)   
Compressing objects:  95% (40/42)   
Compressing objects:  97% (41/42)   
Compressing objects: 100% (42/42)   
Compressing objects: 100% (42/42), done.
Writing objects:   0% (1/268)   
Writing objects:   1% (3/268)   
Writing objects:   2% (6/268)   
Writing objects:   3% (9/268)   
Writing objects:   4% (11/268)   
Writing objects:   5% (14/268)   
Writing objects:   7% (19/268)   
Writing objects:   8% (22/268)   
Writing objects:   9% (25/268)   
Writing objects:  10% (27/268)   
Writing objects:  11% (30/268)   
Writing objects:  12% (33/268)   
Writing objects:  13% (35/268)   
Writing objects:  14% (38/268)   
Writing objects:  15% (41/268)   
Writing objects:  16% (43/268)   
Writing objects:  17% (46/268)   
Writing objects:  18% (49/268)   
Writing objects:  19% (51/268)   
Writing objects:  20% (54/268)   
Writing objects:  21% (57/268)   
Writing objects:  22% (59/268)   
Writing objects:  23% (62/268)   
Writing objects:  24% (65/268)   
Writing objects:  25% (67/268)   
Writing objects:  26% (70/268)   
Writing objects:  27% (73/268)   
Writing objects:  28% (76/268)   
Writing objects:  29% (78/268)   
Writing objects:  30% (81/268)   
Writing objects:  31% (84/268)   
Writing objects:  32% (86/268)   
Writing objects:  33% (89/268)   
Writing objects:  34% (92/268)   
Writing objects:  35% (94/268)   
Writing objects:  36% (97/268)   
Writing objects:  37% (100/268)   
Writing objects:  38% (102/268)   
Writing objects:  39% (105/268)   
Writing objects:  40% (108/268)   
Writing objects:  41% (110/268)   
Writing objects:  42% (113/268)   
Writing objects:  43% (116/268)   
Writing objects:  44% (118/268)   
Writing objects:  45% (121/268)   
Writing objects:  46% (124/268)   
Writing objects:  47% (126/268)   
Writing objects:  48% (129/268)   
Writing objects:  49% (132/268)   
Writing objects:  50% (134/268)   
Writing objects:  51% (137/268)   
Writing objects:  52% (140/268)   
Writing objects:  53% (144/268)   
Writing objects:  54% (145/268)   
Writing objects:  55% (148/268)   
Writing objects:  56% (151/268)   
Writing objects:  57% (153/268)   
Writing objects:  58% (156/268)   
Writing objects:  59% (159/268)   
Writing objects:  60% (161/268)   
Writing objects:  61% (164/268)   
Writing objects:  62% (167/268)   
Writing objects:  63% (169/268)   
Writing objects:  64% (172/268)   
Writing objects:  65% (175/268)   
Writing objects:  66% (177/268)   
Writing objects:  67% (180/268)   
Writing objects:  68% (183/268)   
Writing objects:  69% (185/268)   
Writing objects:  70% (188/268)   
Writing objects:  71% (191/268)   
Writing objects:  72% (193/268)   
Writing objects:  73% (196/268)   
Writing objects:  74% (199/268)   
Writing objects:  75% (201/268)   
Writing objects:  76% (204/268)   
Writing objects:  77% (207/268)   
Writing objects:  78% (210/268)   
Writing objects:  79% (212/268)   
Writing objects:  80% (215/268)   
Writing objects:  81% (218/268)   
Writing objects:  82% (220/268)   
Writing objects:  83% (223/268)   
Writing objects:  84% (226/268)   
Writing objects:  85% (228/268)   
Writing objects:  86% (231/268)   
Writing objects:  87% (234/268)   
Writing objects:  88% (236/268)   
Writing objects:  89% (239/268)   
Writing objects:  90% (242/268)   
Writing objects:  91% (244/268)   
Writing objects:  92% (247/268)   
Writing objects:  93% (250/268)   
Writing objects:  94% (252/268)   
Writing objects:  95% (255/268)   
Writing objects:  96% (258/268)   
Writing objects:  97% (260/268)   
Writing objects:  98% (263/268)   
Writing objects:  99% (266/268)   
Writing objects: 100% (268/268)   
Writing objects: 100% (268/268), 43.71 KiB, done.
Total 268 (delta 222), reused 268 (delta 222)
To xen@xenbits.xensource.com:git/linux-pvops.git
   5aa287d..3d2e7b3  3d2e7b3b3e876fae210e55c872df8f6750ab0fa3 -> 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 Sat Sep 15 19:55:48 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 15 Sep 2012 19:55:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TCySP-00084J-GP; Sat, 15 Sep 2012 19:55:13 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1TCySN-00084E-27
	for xen-devel@lists.xensource.com; Sat, 15 Sep 2012 19:55:11 +0000
Received: from [85.158.138.51:15024] by server-12.bemta-3.messagelabs.com id
	DD/15-10384-E1DD4505; Sat, 15 Sep 2012 19:55:10 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1347738908!22762551!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDk2MjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13282 invoked from network); 15 Sep 2012 19:55: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;
	15 Sep 2012 19:55:09 -0000
X-IronPort-AV: E=Sophos;i="4.80,428,1344211200"; d="scan'208";a="14562432"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Sep 2012 19:55: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.279.1; Sat, 15 Sep 2012 20:55: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 1TCySJ-0003XY-Gq;
	Sat, 15 Sep 2012 19:55:07 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1TCySJ-0004Hs-2T;
	Sat, 15 Sep 2012 20:55:07 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-13777-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sat, 15 Sep 2012 20:55:07 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-3.0 test] 13777: 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 13777 linux-3.0 real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13777/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin 14 guest-localmigrate/x10   fail blocked in 13637
 test-amd64-amd64-xl-sedf     14 guest-localmigrate/x10   fail blocked in 13637
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail like 13637
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail like 13637

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  8 debian-fixup                fail never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-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-win7-amd64 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

version targeted for testing:
 linux                3d2e7b3b3e876fae210e55c872df8f6750ab0fa3
baseline version:
 linux                5aa287dcf1b5879aa0150b0511833c52885f5b4c

------------------------------------------------------------
People who touched revisions under test:
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           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-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-amd64-amd64-xl-win                                      fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=linux-3.0
+ revision=3d2e7b3b3e876fae210e55c872df8f6750ab0fa3
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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 3d2e7b3b3e876fae210e55c872df8f6750ab0fa3
+ branch=linux-3.0
+ revision=3d2e7b3b3e876fae210e55c872df8f6750ab0fa3
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=linux
+ xenbranch=xen-unstable
+ '[' xlinux = xlinux ']'
+ linuxbranch=linux-3.0
+ : master
+ : tested/2.6.39.x
+ . ap-common
++ : xen@xenbits.xensource.com
++ : http://xenbits.xen.org/hg/staging/xen-unstable.hg
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
++ : master
++ : xen@xenbits.xensource.com:git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.linux-3.0
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-unstable.git
++ : daily-cron.linux-3.0
+ TREE_LINUX=xen@xenbits.xensource.com:git/linux-pvops.git
+ TREE_QEMU_UPSTREAM=xen@xenbits.xensource.com:git/qemu-upstream-unstable.git
+ info_linux_tree linux-3.0
+ case $1 in
+ : git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
+ : linux-3.0.y
+ : linux-3.0.y
+ : git
+ : git
+ : git://xenbits.xen.org/linux-pvops.git
+ : xen@xenbits.xensource.com:git/linux-pvops.git
+ : tested/linux-3.0
+ : tested/linux-3.0
+ return 0
+ cd /export/home/osstest/repos/linux
+ git push xen@xenbits.xensource.com:git/linux-pvops.git 3d2e7b3b3e876fae210e55c872df8f6750ab0fa3:tested/linux-3.0
Counting objects: 1   
Counting objects: 225   
Counting objects: 379, done.
Compressing objects:   2% (1/42)   
Compressing objects:   4% (2/42)   
Compressing objects:   7% (3/42)   
Compressing objects:   9% (4/42)   
Compressing objects:  11% (5/42)   
Compressing objects:  14% (6/42)   
Compressing objects:  16% (7/42)   
Compressing objects:  19% (8/42)   
Compressing objects:  21% (9/42)   
Compressing objects:  23% (10/42)   
Compressing objects:  26% (11/42)   
Compressing objects:  28% (12/42)   
Compressing objects:  30% (13/42)   
Compressing objects:  33% (14/42)   
Compressing objects:  35% (15/42)   
Compressing objects:  38% (16/42)   
Compressing objects:  40% (17/42)   
Compressing objects:  42% (18/42)   
Compressing objects:  45% (19/42)   
Compressing objects:  47% (20/42)   
Compressing objects:  50% (21/42)   
Compressing objects:  52% (22/42)   
Compressing objects:  54% (23/42)   
Compressing objects:  57% (24/42)   
Compressing objects:  59% (25/42)   
Compressing objects:  61% (26/42)   
Compressing objects:  64% (27/42)   
Compressing objects:  66% (28/42)   
Compressing objects:  69% (29/42)   
Compressing objects:  71% (30/42)   
Compressing objects:  73% (31/42)   
Compressing objects:  76% (32/42)   
Compressing objects:  78% (33/42)   
Compressing objects:  80% (34/42)   
Compressing objects:  83% (35/42)   
Compressing objects:  85% (36/42)   
Compressing objects:  88% (37/42)   
Compressing objects:  90% (38/42)   
Compressing objects:  92% (39/42)   
Compressing objects:  95% (40/42)   
Compressing objects:  97% (41/42)   
Compressing objects: 100% (42/42)   
Compressing objects: 100% (42/42), done.
Writing objects:   0% (1/268)   
Writing objects:   1% (3/268)   
Writing objects:   2% (6/268)   
Writing objects:   3% (9/268)   
Writing objects:   4% (11/268)   
Writing objects:   5% (14/268)   
Writing objects:   7% (19/268)   
Writing objects:   8% (22/268)   
Writing objects:   9% (25/268)   
Writing objects:  10% (27/268)   
Writing objects:  11% (30/268)   
Writing objects:  12% (33/268)   
Writing objects:  13% (35/268)   
Writing objects:  14% (38/268)   
Writing objects:  15% (41/268)   
Writing objects:  16% (43/268)   
Writing objects:  17% (46/268)   
Writing objects:  18% (49/268)   
Writing objects:  19% (51/268)   
Writing objects:  20% (54/268)   
Writing objects:  21% (57/268)   
Writing objects:  22% (59/268)   
Writing objects:  23% (62/268)   
Writing objects:  24% (65/268)   
Writing objects:  25% (67/268)   
Writing objects:  26% (70/268)   
Writing objects:  27% (73/268)   
Writing objects:  28% (76/268)   
Writing objects:  29% (78/268)   
Writing objects:  30% (81/268)   
Writing objects:  31% (84/268)   
Writing objects:  32% (86/268)   
Writing objects:  33% (89/268)   
Writing objects:  34% (92/268)   
Writing objects:  35% (94/268)   
Writing objects:  36% (97/268)   
Writing objects:  37% (100/268)   
Writing objects:  38% (102/268)   
Writing objects:  39% (105/268)   
Writing objects:  40% (108/268)   
Writing objects:  41% (110/268)   
Writing objects:  42% (113/268)   
Writing objects:  43% (116/268)   
Writing objects:  44% (118/268)   
Writing objects:  45% (121/268)   
Writing objects:  46% (124/268)   
Writing objects:  47% (126/268)   
Writing objects:  48% (129/268)   
Writing objects:  49% (132/268)   
Writing objects:  50% (134/268)   
Writing objects:  51% (137/268)   
Writing objects:  52% (140/268)   
Writing objects:  53% (144/268)   
Writing objects:  54% (145/268)   
Writing objects:  55% (148/268)   
Writing objects:  56% (151/268)   
Writing objects:  57% (153/268)   
Writing objects:  58% (156/268)   
Writing objects:  59% (159/268)   
Writing objects:  60% (161/268)   
Writing objects:  61% (164/268)   
Writing objects:  62% (167/268)   
Writing objects:  63% (169/268)   
Writing objects:  64% (172/268)   
Writing objects:  65% (175/268)   
Writing objects:  66% (177/268)   
Writing objects:  67% (180/268)   
Writing objects:  68% (183/268)   
Writing objects:  69% (185/268)   
Writing objects:  70% (188/268)   
Writing objects:  71% (191/268)   
Writing objects:  72% (193/268)   
Writing objects:  73% (196/268)   
Writing objects:  74% (199/268)   
Writing objects:  75% (201/268)   
Writing objects:  76% (204/268)   
Writing objects:  77% (207/268)   
Writing objects:  78% (210/268)   
Writing objects:  79% (212/268)   
Writing objects:  80% (215/268)   
Writing objects:  81% (218/268)   
Writing objects:  82% (220/268)   
Writing objects:  83% (223/268)   
Writing objects:  84% (226/268)   
Writing objects:  85% (228/268)   
Writing objects:  86% (231/268)   
Writing objects:  87% (234/268)   
Writing objects:  88% (236/268)   
Writing objects:  89% (239/268)   
Writing objects:  90% (242/268)   
Writing objects:  91% (244/268)   
Writing objects:  92% (247/268)   
Writing objects:  93% (250/268)   
Writing objects:  94% (252/268)   
Writing objects:  95% (255/268)   
Writing objects:  96% (258/268)   
Writing objects:  97% (260/268)   
Writing objects:  98% (263/268)   
Writing objects:  99% (266/268)   
Writing objects: 100% (268/268)   
Writing objects: 100% (268/268), 43.71 KiB, done.
Total 268 (delta 222), reused 268 (delta 222)
To xen@xenbits.xensource.com:git/linux-pvops.git
   5aa287d..3d2e7b3  3d2e7b3b3e876fae210e55c872df8f6750ab0fa3 -> 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 Sat Sep 15 22:35:59 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 15 Sep 2012 22:35:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TD0xQ-0000QN-P8; Sat, 15 Sep 2012 22:35: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 1TD0xP-0000QI-2b
	for xen-devel@lists.xensource.com; Sat, 15 Sep 2012 22:35:23 +0000
Received: from [85.158.143.35:3157] by server-2.bemta-4.messagelabs.com id
	82/9A-21239-AA205505; Sat, 15 Sep 2012 22:35:22 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1347748517!15173177!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDk2MjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4308 invoked from network); 15 Sep 2012 22:35: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;
	15 Sep 2012 22:35:17 -0000
X-IronPort-AV: E=Sophos;i="4.80,428,1344211200"; d="scan'208";a="14562801"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Sep 2012 22:35: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.279.1; Sat, 15 Sep 2012 23:35: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 1TD0xI-0004Nj-6N;
	Sat, 15 Sep 2012 22:35:16 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1TD0xH-0004aa-Pj;
	Sat, 15 Sep 2012 23:35:16 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-13778-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sat, 15 Sep 2012 23:35:15 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [qemu-upstream-4.2-testing baseline test] 13778:
	tolerable FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

"Old" tested version had not actually been tested; therefore in this
flight we test it, rather than a new candidate.  The baseline, if
any, is the most recent actually tested revision.

flight 13778 qemu-upstream-4.2-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13778/

Failures :-/ but no regressions.

Tests which did not succeed,
including tests which could not be run:
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  9 guest-localmigrate fail never pass
 test-amd64-amd64-qemuu-win   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64  9 guest-localmigrate      fail never pass
 test-amd64-i386-xl-qemuu-win-vcpus1  9 guest-localmigrate      fail never pass
 test-amd64-i386-xend-qemuu-winxpsp3 16 leak-check/check        fail never pass
 test-i386-i386-qemuu-win     16 leak-check/check             fail   never pass
 test-amd64-i386-qemuu-win-vcpus1 16 leak-check/check           fail never pass
 test-i386-i386-xl-qemuu-win   9 guest-localmigrate           fail   never pass
 test-amd64-i386-qemuu-win    16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemuu-win  9 guest-localmigrate           fail  never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail never pass
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass


jobs:
 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                           pass    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-win-vcpus1                             fail    
 test-amd64-i386-xl-qemuu-win-vcpus1                          fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-amd64-qemuu-win                                   fail    
 test-amd64-i386-qemuu-win                                    fail    
 test-i386-i386-qemuu-win                                     fail    
 test-amd64-amd64-xl-qemuu-win                                fail    
 test-i386-i386-xl-qemuu-win                                  fail    
 test-amd64-i386-xend-qemuu-winxpsp3                          fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


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 Sep 15 22:35:59 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 15 Sep 2012 22:35:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TD0xQ-0000QN-P8; Sat, 15 Sep 2012 22:35: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 1TD0xP-0000QI-2b
	for xen-devel@lists.xensource.com; Sat, 15 Sep 2012 22:35:23 +0000
Received: from [85.158.143.35:3157] by server-2.bemta-4.messagelabs.com id
	82/9A-21239-AA205505; Sat, 15 Sep 2012 22:35:22 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1347748517!15173177!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDk2MjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4308 invoked from network); 15 Sep 2012 22:35: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;
	15 Sep 2012 22:35:17 -0000
X-IronPort-AV: E=Sophos;i="4.80,428,1344211200"; d="scan'208";a="14562801"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Sep 2012 22:35: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.279.1; Sat, 15 Sep 2012 23:35: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 1TD0xI-0004Nj-6N;
	Sat, 15 Sep 2012 22:35:16 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1TD0xH-0004aa-Pj;
	Sat, 15 Sep 2012 23:35:16 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-13778-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sat, 15 Sep 2012 23:35:15 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [qemu-upstream-4.2-testing baseline test] 13778:
	tolerable FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

"Old" tested version had not actually been tested; therefore in this
flight we test it, rather than a new candidate.  The baseline, if
any, is the most recent actually tested revision.

flight 13778 qemu-upstream-4.2-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13778/

Failures :-/ but no regressions.

Tests which did not succeed,
including tests which could not be run:
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  9 guest-localmigrate fail never pass
 test-amd64-amd64-qemuu-win   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64  9 guest-localmigrate      fail never pass
 test-amd64-i386-xl-qemuu-win-vcpus1  9 guest-localmigrate      fail never pass
 test-amd64-i386-xend-qemuu-winxpsp3 16 leak-check/check        fail never pass
 test-i386-i386-qemuu-win     16 leak-check/check             fail   never pass
 test-amd64-i386-qemuu-win-vcpus1 16 leak-check/check           fail never pass
 test-i386-i386-xl-qemuu-win   9 guest-localmigrate           fail   never pass
 test-amd64-i386-qemuu-win    16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemuu-win  9 guest-localmigrate           fail  never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail never pass
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass


jobs:
 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                           pass    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-win-vcpus1                             fail    
 test-amd64-i386-xl-qemuu-win-vcpus1                          fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-amd64-qemuu-win                                   fail    
 test-amd64-i386-qemuu-win                                    fail    
 test-i386-i386-qemuu-win                                     fail    
 test-amd64-amd64-xl-qemuu-win                                fail    
 test-i386-i386-xl-qemuu-win                                  fail    
 test-amd64-i386-xend-qemuu-winxpsp3                          fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


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 Sep 16 04:32:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 16 Sep 2012 04:32:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TD6Vz-000611-8Z; Sun, 16 Sep 2012 04:31:27 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1TD6Vx-00060w-PZ
	for xen-devel@lists.xensource.com; Sun, 16 Sep 2012 04:31:25 +0000
Received: from [85.158.143.99:56597] by server-3.bemta-4.messagelabs.com id
	36/35-08232-D1655505; Sun, 16 Sep 2012 04:31:25 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1347769884!29616314!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDk2MjY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12267 invoked from network); 16 Sep 2012 04:31:24 -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;
	16 Sep 2012 04:31:24 -0000
X-IronPort-AV: E=Sophos;i="4.80,428,1344211200"; d="scan'208";a="14563803"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Sep 2012 04:31: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.279.1; Sun, 16 Sep 2012 05:31:23 +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 1TD6Vv-0006KY-Ia;
	Sun, 16 Sep 2012 04:31:23 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1TD6Vv-0001vv-6D;
	Sun, 16 Sep 2012 05:31:23 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-13780-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sun, 16 Sep 2012 05:31:23 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [qemu-upstream-4.2-testing baseline test] 13780:
	tolerable FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

"Old" tested version had not actually been tested; therefore in this
flight we test it, rather than a new candidate.  The baseline, if
any, is the most recent actually tested revision.

flight 13780 qemu-upstream-4.2-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13780/

Failures :-/ but no regressions.

Tests which did not succeed,
including tests which could not be run:
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  9 guest-localmigrate fail never pass
 test-amd64-amd64-qemuu-win   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64  9 guest-localmigrate      fail never pass
 test-amd64-i386-xl-qemuu-win-vcpus1  9 guest-localmigrate      fail never pass
 test-amd64-i386-xend-qemuu-winxpsp3 16 leak-check/check        fail never pass
 test-i386-i386-qemuu-win     16 leak-check/check             fail   never pass
 test-amd64-i386-qemuu-win-vcpus1 16 leak-check/check           fail never pass
 test-i386-i386-xl-qemuu-win   9 guest-localmigrate           fail   never pass
 test-amd64-i386-qemuu-win     7 windows-install         fail baseline untested
 test-amd64-amd64-xl-qemuu-win  9 guest-localmigrate           fail  never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail never pass
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass


jobs:
 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                           pass    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-win-vcpus1                             fail    
 test-amd64-i386-xl-qemuu-win-vcpus1                          fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-amd64-qemuu-win                                   fail    
 test-amd64-i386-qemuu-win                                    fail    
 test-i386-i386-qemuu-win                                     fail    
 test-amd64-amd64-xl-qemuu-win                                fail    
 test-i386-i386-xl-qemuu-win                                  fail    
 test-amd64-i386-xend-qemuu-winxpsp3                          fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


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 Sep 16 04:32:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 16 Sep 2012 04:32:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TD6Vz-000611-8Z; Sun, 16 Sep 2012 04:31:27 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1TD6Vx-00060w-PZ
	for xen-devel@lists.xensource.com; Sun, 16 Sep 2012 04:31:25 +0000
Received: from [85.158.143.99:56597] by server-3.bemta-4.messagelabs.com id
	36/35-08232-D1655505; Sun, 16 Sep 2012 04:31:25 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1347769884!29616314!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDk2MjY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12267 invoked from network); 16 Sep 2012 04:31:24 -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;
	16 Sep 2012 04:31:24 -0000
X-IronPort-AV: E=Sophos;i="4.80,428,1344211200"; d="scan'208";a="14563803"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Sep 2012 04:31: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.279.1; Sun, 16 Sep 2012 05:31:23 +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 1TD6Vv-0006KY-Ia;
	Sun, 16 Sep 2012 04:31:23 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1TD6Vv-0001vv-6D;
	Sun, 16 Sep 2012 05:31:23 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-13780-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sun, 16 Sep 2012 05:31:23 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [qemu-upstream-4.2-testing baseline test] 13780:
	tolerable FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

"Old" tested version had not actually been tested; therefore in this
flight we test it, rather than a new candidate.  The baseline, if
any, is the most recent actually tested revision.

flight 13780 qemu-upstream-4.2-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13780/

Failures :-/ but no regressions.

Tests which did not succeed,
including tests which could not be run:
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  9 guest-localmigrate fail never pass
 test-amd64-amd64-qemuu-win   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64  9 guest-localmigrate      fail never pass
 test-amd64-i386-xl-qemuu-win-vcpus1  9 guest-localmigrate      fail never pass
 test-amd64-i386-xend-qemuu-winxpsp3 16 leak-check/check        fail never pass
 test-i386-i386-qemuu-win     16 leak-check/check             fail   never pass
 test-amd64-i386-qemuu-win-vcpus1 16 leak-check/check           fail never pass
 test-i386-i386-xl-qemuu-win   9 guest-localmigrate           fail   never pass
 test-amd64-i386-qemuu-win     7 windows-install         fail baseline untested
 test-amd64-amd64-xl-qemuu-win  9 guest-localmigrate           fail  never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail never pass
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass


jobs:
 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                           pass    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-win-vcpus1                             fail    
 test-amd64-i386-xl-qemuu-win-vcpus1                          fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-amd64-qemuu-win                                   fail    
 test-amd64-i386-qemuu-win                                    fail    
 test-i386-i386-qemuu-win                                     fail    
 test-amd64-amd64-xl-qemuu-win                                fail    
 test-i386-i386-xl-qemuu-win                                  fail    
 test-amd64-i386-xend-qemuu-winxpsp3                          fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


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 Sep 16 07:01:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 16 Sep 2012 07:01:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TD8q5-0006i8-Et; Sun, 16 Sep 2012 07:00:21 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <joseph.glanville@orionvm.com.au>) id 1TD8q3-0006i3-Jc
	for xen-devel@lists.xen.org; Sun, 16 Sep 2012 07:00:19 +0000
Received: from [85.158.137.99:62906] by server-8.bemta-3.messagelabs.com id
	BB/04-24700-20975505; Sun, 16 Sep 2012 07:00:18 +0000
X-Env-Sender: joseph.glanville@orionvm.com.au
X-Msg-Ref: server-6.tower-217.messagelabs.com!1347778816!12718239!1
X-Originating-IP: [209.85.219.45]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
  RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25291 invoked from network); 16 Sep 2012 07:00:17 -0000
Received: from mail-oa0-f45.google.com (HELO mail-oa0-f45.google.com)
	(209.85.219.45)
	by server-6.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Sep 2012 07:00:17 -0000
Received: by oagn12 with SMTP id n12so4883633oag.32
	for <xen-devel@lists.xen.org>; Sun, 16 Sep 2012 00:00:15 -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=WRrYdlau8GQa7+LppKNuiUkOYrKbFruC7Yez6ZVUluY=;
	b=YlW4hD7TZaQmDuyAJkbwDVcTCLogB1AVxy5YzHZYxRV9xnQILBSlGdsCqqOdjp/pjv
	WlSaeRRJvv6Ajh/DGwzn0Dm3manWoIA1ubyhIcOfi54ajasgh3zGQm8IYgWpUo6n+LCh
	IJUVcv2++FKIA2D6wgmRN9StcCJxGyxcyVt6rE2S4V60zbq+59DIMv4Lc2DEGFjVYhgJ
	jWdNy2LMqy8bUW6DyhEULCURJgx2sRMDVav9QWob+0O6npTGwNUuaQRcO1SGgt1lNDHR
	hFnFtyNgh5c9SyGrMzaOAooUNKIlX3m2T5UYncgSvdN0qj/XE9HMuKMy10Cf0M8R53Nb
	raVQ==
MIME-Version: 1.0
Received: by 10.60.24.7 with SMTP id q7mr8611338oef.54.1347778815406; Sun, 16
	Sep 2012 00:00:15 -0700 (PDT)
Received: by 10.182.80.200 with HTTP; Sun, 16 Sep 2012 00:00:15 -0700 (PDT)
X-Originating-IP: [121.44.24.60]
In-Reply-To: <20120906105822.GB3668@phenom.dumpdata.com>
References: <6035A0D088A63A46850C3988ED045A4B299F74F8@BITCOM1.int.sbss.com.au>
	<20120905202927.GD27814@phenom.dumpdata.com>
	<6035A0D088A63A46850C3988ED045A4B29B5D23E@BITCOM1.int.sbss.com.au>
	<20120906105822.GB3668@phenom.dumpdata.com>
Date: Sun, 16 Sep 2012 17:00:15 +1000
Message-ID: <CAOzFzEiZopdFQuZkUcSWWre9b=NeZpJM9n2VtEoZcRo=ejYQPA@mail.gmail.com>
From: Joseph Glanville <joseph.glanville@orionvm.com.au>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
X-Gm-Message-State: ALoCoQm/KSwEtHyJnXtqU3YmApZWDugg1Nfa7uiw9ylbc0am+Qg2KUG2Qk9Hdl84gp0MH0zdFFia
Cc: James Harper <james.harper@bendigoit.com.au>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] bug when using 4K sectors?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 6 September 2012 20:58, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
> On Wed, Sep 05, 2012 at 11:56:08PM +0000, James Harper wrote:
>> > On Mon, Aug 13, 2012 at 02:12:58PM +0000, James Harper wrote:
>> > > I notice this code in drivers/block/xen-blkback/common.h
>> > >
>> > > #define vbd_sz(_v)      ((_v)->bdev->bd_part ? \
>> > >                          (_v)->bdev->bd_part->nr_sects : \
>> > >                           get_capacity((_v)->bdev->bd_disk))
>> > >
>> > > is the value returned by vbd_sz(_v) the number of sectors in the Linux
>> > > device (eg size / 4096), or the number of 512 byte sectors? I suspect
>> > > the former which is causing block requests beyond 1/8th the size of
>> > > the device to fail (assuming 4K sectors are expected to work at all -
>> > > I can't quite get my head around how it would be expected to work -
>> > > does Linux do the read-modify-write if required?)
>> >
>> > I think you need to instrument it to be sure.. But more interesting, do you
>> > actually have a disk that exposes a 4KB hardware and logical sector? So far
>> > I've only found SSDs that expose a 512kB logical sector but also expose the
>> > 4KB hardware.
>> >
>> > Never could figure out how that is all suppose to work as the blkback is filled
>> > with << 9 on a bunch of things.
>> >
>>
>> I was using bcache which does expose a 4K block size, by default. I changed it to 512 and it all works now, although I haven't tested if there is any loss of performance.
>
> OK, let me see how I can setup bcache and play with that.
>>
>> Does Xen provide a way to tell Windows that the underlying device is 512e (4K sector with 512 byte emulated interface)? This would keep everything working as is but allow windows to align writes to 4K boundaries where possible.
>
> We can certainly expose that via the XenBus interface.
>>
>> James
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

After reading through blkback it appears that it can only support 512
byte sector sizes and removing this limitation would take quite abit
of work.
It uses hard coded bitshifts pervasively to convert between number of
requests/pages and size of sectors etc. (that is all the >> 9
everywhere)

I am going to see what I can about working on getting it to support 4k
sectors too and eventually uncoupled logical/physical sizes but that
would take even more work as far as I can tell.

Being able to use 4k sectors seems like it would provide pretty
massive gains in performance just by being more efficient let alone
increasing byte aligned writes to the underlying block storage system.

Joseph.

-- 
CTO | Orion Virtualisation Solutions | www.orionvm.com.au
Phone: 1300 56 99 52 | Mobile: 0428 754 846

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Sep 16 07:01:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 16 Sep 2012 07:01:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TD8q5-0006i8-Et; Sun, 16 Sep 2012 07:00:21 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <joseph.glanville@orionvm.com.au>) id 1TD8q3-0006i3-Jc
	for xen-devel@lists.xen.org; Sun, 16 Sep 2012 07:00:19 +0000
Received: from [85.158.137.99:62906] by server-8.bemta-3.messagelabs.com id
	BB/04-24700-20975505; Sun, 16 Sep 2012 07:00:18 +0000
X-Env-Sender: joseph.glanville@orionvm.com.au
X-Msg-Ref: server-6.tower-217.messagelabs.com!1347778816!12718239!1
X-Originating-IP: [209.85.219.45]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
  RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25291 invoked from network); 16 Sep 2012 07:00:17 -0000
Received: from mail-oa0-f45.google.com (HELO mail-oa0-f45.google.com)
	(209.85.219.45)
	by server-6.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Sep 2012 07:00:17 -0000
Received: by oagn12 with SMTP id n12so4883633oag.32
	for <xen-devel@lists.xen.org>; Sun, 16 Sep 2012 00:00:15 -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=WRrYdlau8GQa7+LppKNuiUkOYrKbFruC7Yez6ZVUluY=;
	b=YlW4hD7TZaQmDuyAJkbwDVcTCLogB1AVxy5YzHZYxRV9xnQILBSlGdsCqqOdjp/pjv
	WlSaeRRJvv6Ajh/DGwzn0Dm3manWoIA1ubyhIcOfi54ajasgh3zGQm8IYgWpUo6n+LCh
	IJUVcv2++FKIA2D6wgmRN9StcCJxGyxcyVt6rE2S4V60zbq+59DIMv4Lc2DEGFjVYhgJ
	jWdNy2LMqy8bUW6DyhEULCURJgx2sRMDVav9QWob+0O6npTGwNUuaQRcO1SGgt1lNDHR
	hFnFtyNgh5c9SyGrMzaOAooUNKIlX3m2T5UYncgSvdN0qj/XE9HMuKMy10Cf0M8R53Nb
	raVQ==
MIME-Version: 1.0
Received: by 10.60.24.7 with SMTP id q7mr8611338oef.54.1347778815406; Sun, 16
	Sep 2012 00:00:15 -0700 (PDT)
Received: by 10.182.80.200 with HTTP; Sun, 16 Sep 2012 00:00:15 -0700 (PDT)
X-Originating-IP: [121.44.24.60]
In-Reply-To: <20120906105822.GB3668@phenom.dumpdata.com>
References: <6035A0D088A63A46850C3988ED045A4B299F74F8@BITCOM1.int.sbss.com.au>
	<20120905202927.GD27814@phenom.dumpdata.com>
	<6035A0D088A63A46850C3988ED045A4B29B5D23E@BITCOM1.int.sbss.com.au>
	<20120906105822.GB3668@phenom.dumpdata.com>
Date: Sun, 16 Sep 2012 17:00:15 +1000
Message-ID: <CAOzFzEiZopdFQuZkUcSWWre9b=NeZpJM9n2VtEoZcRo=ejYQPA@mail.gmail.com>
From: Joseph Glanville <joseph.glanville@orionvm.com.au>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
X-Gm-Message-State: ALoCoQm/KSwEtHyJnXtqU3YmApZWDugg1Nfa7uiw9ylbc0am+Qg2KUG2Qk9Hdl84gp0MH0zdFFia
Cc: James Harper <james.harper@bendigoit.com.au>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] bug when using 4K sectors?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 6 September 2012 20:58, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
> On Wed, Sep 05, 2012 at 11:56:08PM +0000, James Harper wrote:
>> > On Mon, Aug 13, 2012 at 02:12:58PM +0000, James Harper wrote:
>> > > I notice this code in drivers/block/xen-blkback/common.h
>> > >
>> > > #define vbd_sz(_v)      ((_v)->bdev->bd_part ? \
>> > >                          (_v)->bdev->bd_part->nr_sects : \
>> > >                           get_capacity((_v)->bdev->bd_disk))
>> > >
>> > > is the value returned by vbd_sz(_v) the number of sectors in the Linux
>> > > device (eg size / 4096), or the number of 512 byte sectors? I suspect
>> > > the former which is causing block requests beyond 1/8th the size of
>> > > the device to fail (assuming 4K sectors are expected to work at all -
>> > > I can't quite get my head around how it would be expected to work -
>> > > does Linux do the read-modify-write if required?)
>> >
>> > I think you need to instrument it to be sure.. But more interesting, do you
>> > actually have a disk that exposes a 4KB hardware and logical sector? So far
>> > I've only found SSDs that expose a 512kB logical sector but also expose the
>> > 4KB hardware.
>> >
>> > Never could figure out how that is all suppose to work as the blkback is filled
>> > with << 9 on a bunch of things.
>> >
>>
>> I was using bcache which does expose a 4K block size, by default. I changed it to 512 and it all works now, although I haven't tested if there is any loss of performance.
>
> OK, let me see how I can setup bcache and play with that.
>>
>> Does Xen provide a way to tell Windows that the underlying device is 512e (4K sector with 512 byte emulated interface)? This would keep everything working as is but allow windows to align writes to 4K boundaries where possible.
>
> We can certainly expose that via the XenBus interface.
>>
>> James
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

After reading through blkback it appears that it can only support 512
byte sector sizes and removing this limitation would take quite abit
of work.
It uses hard coded bitshifts pervasively to convert between number of
requests/pages and size of sectors etc. (that is all the >> 9
everywhere)

I am going to see what I can about working on getting it to support 4k
sectors too and eventually uncoupled logical/physical sizes but that
would take even more work as far as I can tell.

Being able to use 4k sectors seems like it would provide pretty
massive gains in performance just by being more efficient let alone
increasing byte aligned writes to the underlying block storage system.

Joseph.

-- 
CTO | Orion Virtualisation Solutions | www.orionvm.com.au
Phone: 1300 56 99 52 | Mobile: 0428 754 846

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Sep 16 08:05:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 16 Sep 2012 08:05:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TD9q9-0007de-40; Sun, 16 Sep 2012 08:04:29 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1TD9q6-0007dZ-TU
	for xen-devel@lists.xensource.com; Sun, 16 Sep 2012 08:04:27 +0000
Received: from [85.158.138.51:50614] by server-2.bemta-3.messagelabs.com id
	51/4B-04862-90885505; Sun, 16 Sep 2012 08:04:25 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1347782665!30713771!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDk2MjY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15192 invoked from network); 16 Sep 2012 08:04:25 -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 Sep 2012 08:04:25 -0000
X-IronPort-AV: E=Sophos;i="4.80,429,1344211200"; d="scan'208";a="14564518"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Sep 2012 08:04:24 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Sun, 16 Sep 2012 09:04:24 +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 1TD9q3-0007Vn-On;
	Sun, 16 Sep 2012 08:04:23 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1TD9q3-0000p3-9U;
	Sun, 16 Sep 2012 09:04:23 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-13782-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sun, 16 Sep 2012 09:04:23 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13782: 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 13782 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13782/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-sedf     14 guest-localmigrate/x10      fail pass in 13772

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore            fail   like 13772
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail like 13772
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail like 13772

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  12fa949b9060
baseline version:
 xen                  12fa949b9060

jobs:
 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-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-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-amd64-amd64-xl-win                                      fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Published tested tree is already up to date.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Sep 16 08:05:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 16 Sep 2012 08:05:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TD9q9-0007de-40; Sun, 16 Sep 2012 08:04:29 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1TD9q6-0007dZ-TU
	for xen-devel@lists.xensource.com; Sun, 16 Sep 2012 08:04:27 +0000
Received: from [85.158.138.51:50614] by server-2.bemta-3.messagelabs.com id
	51/4B-04862-90885505; Sun, 16 Sep 2012 08:04:25 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1347782665!30713771!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDk2MjY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15192 invoked from network); 16 Sep 2012 08:04:25 -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 Sep 2012 08:04:25 -0000
X-IronPort-AV: E=Sophos;i="4.80,429,1344211200"; d="scan'208";a="14564518"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Sep 2012 08:04:24 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Sun, 16 Sep 2012 09:04:24 +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 1TD9q3-0007Vn-On;
	Sun, 16 Sep 2012 08:04:23 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1TD9q3-0000p3-9U;
	Sun, 16 Sep 2012 09:04:23 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-13782-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sun, 16 Sep 2012 09:04:23 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13782: 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 13782 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13782/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-sedf     14 guest-localmigrate/x10      fail pass in 13772

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore            fail   like 13772
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail like 13772
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail like 13772

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  12fa949b9060
baseline version:
 xen                  12fa949b9060

jobs:
 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-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-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-amd64-amd64-xl-win                                      fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Published tested tree is already up to date.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Sep 16 08:32:02 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 16 Sep 2012 08:32:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDAGJ-0007qB-G0; Sun, 16 Sep 2012 08:31:31 +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 1TDAGI-0007q6-DG
	for xen-devel@lists.xen.org; Sun, 16 Sep 2012 08:31:30 +0000
Received: from [85.158.143.35:21260] by server-3.bemta-4.messagelabs.com id
	FF/44-08232-16E85505; Sun, 16 Sep 2012 08:31:29 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1347784285!14843324!1
X-Originating-IP: [74.125.82.41]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18031 invoked from network); 16 Sep 2012 08:31:25 -0000
Received: from mail-wg0-f41.google.com (HELO mail-wg0-f41.google.com)
	(74.125.82.41)
	by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Sep 2012 08:31:25 -0000
Received: by wgbds1 with SMTP id ds1so2158575wgb.2
	for <xen-devel@lists.xen.org>; Sun, 16 Sep 2012 01:31:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=IDf4hD1mhdG/EOTUdT+Y7I1E31hMeo+17ETZIxM1zA8=;
	b=N1WQpPo0hU76BlyE2oU/gf7f8xseNTLNOcZTXudR8kVQoW4lIUGOFosQ/zN60iUds0
	fnYVpJ9+nGxPG7EDZLt62RWjozycvp2ik6lb6j85eyfOazMm7iSG7mwqxWCXhM3h2Op4
	BhaPX0v5BMxc++GaiMiQ5TF+An9IzEwxdEMFx7P+T11+P1R8K7N7STN/5h5jsyoHCKYq
	tU9pEpb9W2wQ0JbIxMq3I7Pjn7IkVV362CAFtWxMBBrKtZWyM/4L+1piniwfD0sp/esW
	lAnzaKv9U5wu5dzWxdY9ErqPa+NMmeyryrNdZAQhMzETqKTBo08/NbifQUgcA3w/0NAs
	u1pQ==
Received: by 10.180.98.200 with SMTP id ek8mr8836495wib.0.1347784285087;
	Sun, 16 Sep 2012 01:31:25 -0700 (PDT)
Received: from [192.168.1.69] (host86-183-251-65.range86-183.btcentralplus.com.
	[86.183.251.65])
	by mx.google.com with ESMTPS id hv8sm14704673wib.0.2012.09.16.01.31.23
	(version=SSLv3 cipher=OTHER); Sun, 16 Sep 2012 01:31:24 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Sun, 16 Sep 2012 09:31:16 +0100
From: Keir Fraser <keir.xen@gmail.com>
To: Joseph Glanville <joseph.glanville@orionvm.com.au>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Message-ID: <CC7B4CE4.3EE74%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] bug when using 4K sectors?
Thread-Index: Ac2T5aNKxk0Xqe8BtEqgMpw2Z20LZA==
In-Reply-To: <CAOzFzEiZopdFQuZkUcSWWre9b=NeZpJM9n2VtEoZcRo=ejYQPA@mail.gmail.com>
Mime-version: 1.0
Cc: James Harper <james.harper@bendigoit.com.au>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] bug when using 4K sectors?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 16/09/2012 08:00, "Joseph Glanville" <joseph.glanville@orionvm.com.au>
wrote:

> After reading through blkback it appears that it can only support 512
> byte sector sizes and removing this limitation would take quite abit
> of work.
> It uses hard coded bitshifts pervasively to convert between number of
> requests/pages and size of sectors etc. (that is all the >> 9
> everywhere)
> 
> I am going to see what I can about working on getting it to support 4k
> sectors too and eventually uncoupled logical/physical sizes but that
> would take even more work as far as I can tell.
> 
> Being able to use 4k sectors seems like it would provide pretty
> massive gains in performance just by being more efficient let alone
> increasing byte aligned writes to the underlying block storage system.

The PV blk transport may be based on 512-byte sectors, but the real sector
size is communicated between blkfront and blkback via xenbus (field
'sector-size') and blkfront is expected to only make requests that are
multiple of, and aligned according to, that real 'sector-size'.

I would kind of expect it to work, as CD-ROMs have a larger sector size (2kB
IIRC) and we support those...

Bashing your head against the PV blk transport code may be premature. ;)

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Sep 16 08:32:02 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 16 Sep 2012 08:32:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDAGJ-0007qB-G0; Sun, 16 Sep 2012 08:31:31 +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 1TDAGI-0007q6-DG
	for xen-devel@lists.xen.org; Sun, 16 Sep 2012 08:31:30 +0000
Received: from [85.158.143.35:21260] by server-3.bemta-4.messagelabs.com id
	FF/44-08232-16E85505; Sun, 16 Sep 2012 08:31:29 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1347784285!14843324!1
X-Originating-IP: [74.125.82.41]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18031 invoked from network); 16 Sep 2012 08:31:25 -0000
Received: from mail-wg0-f41.google.com (HELO mail-wg0-f41.google.com)
	(74.125.82.41)
	by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Sep 2012 08:31:25 -0000
Received: by wgbds1 with SMTP id ds1so2158575wgb.2
	for <xen-devel@lists.xen.org>; Sun, 16 Sep 2012 01:31:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=IDf4hD1mhdG/EOTUdT+Y7I1E31hMeo+17ETZIxM1zA8=;
	b=N1WQpPo0hU76BlyE2oU/gf7f8xseNTLNOcZTXudR8kVQoW4lIUGOFosQ/zN60iUds0
	fnYVpJ9+nGxPG7EDZLt62RWjozycvp2ik6lb6j85eyfOazMm7iSG7mwqxWCXhM3h2Op4
	BhaPX0v5BMxc++GaiMiQ5TF+An9IzEwxdEMFx7P+T11+P1R8K7N7STN/5h5jsyoHCKYq
	tU9pEpb9W2wQ0JbIxMq3I7Pjn7IkVV362CAFtWxMBBrKtZWyM/4L+1piniwfD0sp/esW
	lAnzaKv9U5wu5dzWxdY9ErqPa+NMmeyryrNdZAQhMzETqKTBo08/NbifQUgcA3w/0NAs
	u1pQ==
Received: by 10.180.98.200 with SMTP id ek8mr8836495wib.0.1347784285087;
	Sun, 16 Sep 2012 01:31:25 -0700 (PDT)
Received: from [192.168.1.69] (host86-183-251-65.range86-183.btcentralplus.com.
	[86.183.251.65])
	by mx.google.com with ESMTPS id hv8sm14704673wib.0.2012.09.16.01.31.23
	(version=SSLv3 cipher=OTHER); Sun, 16 Sep 2012 01:31:24 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Sun, 16 Sep 2012 09:31:16 +0100
From: Keir Fraser <keir.xen@gmail.com>
To: Joseph Glanville <joseph.glanville@orionvm.com.au>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Message-ID: <CC7B4CE4.3EE74%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] bug when using 4K sectors?
Thread-Index: Ac2T5aNKxk0Xqe8BtEqgMpw2Z20LZA==
In-Reply-To: <CAOzFzEiZopdFQuZkUcSWWre9b=NeZpJM9n2VtEoZcRo=ejYQPA@mail.gmail.com>
Mime-version: 1.0
Cc: James Harper <james.harper@bendigoit.com.au>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] bug when using 4K sectors?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 16/09/2012 08:00, "Joseph Glanville" <joseph.glanville@orionvm.com.au>
wrote:

> After reading through blkback it appears that it can only support 512
> byte sector sizes and removing this limitation would take quite abit
> of work.
> It uses hard coded bitshifts pervasively to convert between number of
> requests/pages and size of sectors etc. (that is all the >> 9
> everywhere)
> 
> I am going to see what I can about working on getting it to support 4k
> sectors too and eventually uncoupled logical/physical sizes but that
> would take even more work as far as I can tell.
> 
> Being able to use 4k sectors seems like it would provide pretty
> massive gains in performance just by being more efficient let alone
> increasing byte aligned writes to the underlying block storage system.

The PV blk transport may be based on 512-byte sectors, but the real sector
size is communicated between blkfront and blkback via xenbus (field
'sector-size') and blkfront is expected to only make requests that are
multiple of, and aligned according to, that real 'sector-size'.

I would kind of expect it to work, as CD-ROMs have a larger sector size (2kB
IIRC) and we support those...

Bashing your head against the PV blk transport code may be premature. ;)

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Sep 16 09:01:00 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 16 Sep 2012 09: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 1TDAiP-00084m-8F; Sun, 16 Sep 2012 09:00:33 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <joseph.glanville@orionvm.com.au>) id 1TDAiM-00084h-PD
	for xen-devel@lists.xen.org; Sun, 16 Sep 2012 09:00:31 +0000
Received: from [85.158.138.51:59913] by server-7.bemta-3.messagelabs.com id
	A5/96-32000-E2595505; Sun, 16 Sep 2012 09:00:30 +0000
X-Env-Sender: joseph.glanville@orionvm.com.au
X-Msg-Ref: server-8.tower-174.messagelabs.com!1347786027!30685642!1
X-Originating-IP: [209.85.214.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26250 invoked from network); 16 Sep 2012 09:00:28 -0000
Received: from mail-ob0-f173.google.com (HELO mail-ob0-f173.google.com)
	(209.85.214.173)
	by server-8.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Sep 2012 09:00:28 -0000
Received: by obbta14 with SMTP id ta14so9950580obb.32
	for <xen-devel@lists.xen.org>; Sun, 16 Sep 2012 02:00: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:date
	:message-id:subject:from:to:cc:content-type:x-gm-message-state;
	bh=B9h40DwTy3mUZbuiyF6xhoOqAJ4jjgu5vZuU7X6WUWw=;
	b=C2Xb2L8awmGEO0dWSbMsi8QO8U0k/XmlwASIZ9627dG4MrvjrDGI9ldh+MQ5mpRF4w
	unZlP2sDZd86XwZQRpzqdZh4IJeuyqOwKfirtnidNMPOrzMJjsAncu0P697b5SwixMCa
	vbU1fKqlC84yhhZh17bQ8QWziAqdsUTY94aZUlOr1JIFV1w9VN8mkUXp5g32BFjEunDk
	sIDasfgGVfUlvWOK1zrVnx2G56XGQvy8P/WuQdj94GlnAZLazwHBFiPoy6i9WYif0Kpt
	NENTnmjImFmurkuo2jlMEvhDeyAXCyWKq2M0FUAjleDnqkjGeFWUqOItpLzRlSi8MgYv
	FPkg==
MIME-Version: 1.0
Received: by 10.60.5.234 with SMTP id v10mr8780176oev.59.1347786026732; Sun,
	16 Sep 2012 02:00:26 -0700 (PDT)
Received: by 10.182.80.200 with HTTP; Sun, 16 Sep 2012 02:00:26 -0700 (PDT)
X-Originating-IP: [121.44.24.60]
In-Reply-To: <CC7B4CE4.3EE74%keir.xen@gmail.com>
References: <CAOzFzEiZopdFQuZkUcSWWre9b=NeZpJM9n2VtEoZcRo=ejYQPA@mail.gmail.com>
	<CC7B4CE4.3EE74%keir.xen@gmail.com>
Date: Sun, 16 Sep 2012 19:00:26 +1000
Message-ID: <CAOzFzEhh7pfpcq+0X-g7BXGAyNqgb8dZT4=Ys=Pmu1dFqH+46A@mail.gmail.com>
From: Joseph Glanville <joseph.glanville@orionvm.com.au>
To: Keir Fraser <keir.xen@gmail.com>
X-Gm-Message-State: ALoCoQkaVKtffZAi2rOdXx4ISzFXIqbUojXAQ1sZbeErnG0ozRX/kD3ilN+X//oDjsRqub1TYGaV
Cc: James Harper <james.harper@bendigoit.com.au>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] bug when using 4K sectors?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 16 September 2012 18:31, Keir Fraser <keir.xen@gmail.com> wrote:
> On 16/09/2012 08:00, "Joseph Glanville" <joseph.glanville@orionvm.com.au>
> wrote:
>
>> After reading through blkback it appears that it can only support 512
>> byte sector sizes and removing this limitation would take quite abit
>> of work.
>> It uses hard coded bitshifts pervasively to convert between number of
>> requests/pages and size of sectors etc. (that is all the >> 9
>> everywhere)
>>
>> I am going to see what I can about working on getting it to support 4k
>> sectors too and eventually uncoupled logical/physical sizes but that
>> would take even more work as far as I can tell.
>>
>> Being able to use 4k sectors seems like it would provide pretty
>> massive gains in performance just by being more efficient let alone
>> increasing byte aligned writes to the underlying block storage system.
>
> The PV blk transport may be based on 512-byte sectors, but the real sector
> size is communicated between blkfront and blkback via xenbus (field
> 'sector-size') and blkfront is expected to only make requests that are
> multiple of, and aligned according to, that real 'sector-size'.
>
> I would kind of expect it to work, as CD-ROMs have a larger sector size (2kB
> IIRC) and we support those...
>
> Bashing your head against the PV blk transport code may be premature. ;)
>
>  -- Keir
>
>

Understood, still have a fair bit of reading to do. :)

Thanks,
Joseph.

-- 
CTO | Orion Virtualisation Solutions | www.orionvm.com.au
Phone: 1300 56 99 52 | Mobile: 0428 754 846

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Sep 16 09:01:00 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 16 Sep 2012 09: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 1TDAiP-00084m-8F; Sun, 16 Sep 2012 09:00:33 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <joseph.glanville@orionvm.com.au>) id 1TDAiM-00084h-PD
	for xen-devel@lists.xen.org; Sun, 16 Sep 2012 09:00:31 +0000
Received: from [85.158.138.51:59913] by server-7.bemta-3.messagelabs.com id
	A5/96-32000-E2595505; Sun, 16 Sep 2012 09:00:30 +0000
X-Env-Sender: joseph.glanville@orionvm.com.au
X-Msg-Ref: server-8.tower-174.messagelabs.com!1347786027!30685642!1
X-Originating-IP: [209.85.214.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26250 invoked from network); 16 Sep 2012 09:00:28 -0000
Received: from mail-ob0-f173.google.com (HELO mail-ob0-f173.google.com)
	(209.85.214.173)
	by server-8.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Sep 2012 09:00:28 -0000
Received: by obbta14 with SMTP id ta14so9950580obb.32
	for <xen-devel@lists.xen.org>; Sun, 16 Sep 2012 02:00: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:date
	:message-id:subject:from:to:cc:content-type:x-gm-message-state;
	bh=B9h40DwTy3mUZbuiyF6xhoOqAJ4jjgu5vZuU7X6WUWw=;
	b=C2Xb2L8awmGEO0dWSbMsi8QO8U0k/XmlwASIZ9627dG4MrvjrDGI9ldh+MQ5mpRF4w
	unZlP2sDZd86XwZQRpzqdZh4IJeuyqOwKfirtnidNMPOrzMJjsAncu0P697b5SwixMCa
	vbU1fKqlC84yhhZh17bQ8QWziAqdsUTY94aZUlOr1JIFV1w9VN8mkUXp5g32BFjEunDk
	sIDasfgGVfUlvWOK1zrVnx2G56XGQvy8P/WuQdj94GlnAZLazwHBFiPoy6i9WYif0Kpt
	NENTnmjImFmurkuo2jlMEvhDeyAXCyWKq2M0FUAjleDnqkjGeFWUqOItpLzRlSi8MgYv
	FPkg==
MIME-Version: 1.0
Received: by 10.60.5.234 with SMTP id v10mr8780176oev.59.1347786026732; Sun,
	16 Sep 2012 02:00:26 -0700 (PDT)
Received: by 10.182.80.200 with HTTP; Sun, 16 Sep 2012 02:00:26 -0700 (PDT)
X-Originating-IP: [121.44.24.60]
In-Reply-To: <CC7B4CE4.3EE74%keir.xen@gmail.com>
References: <CAOzFzEiZopdFQuZkUcSWWre9b=NeZpJM9n2VtEoZcRo=ejYQPA@mail.gmail.com>
	<CC7B4CE4.3EE74%keir.xen@gmail.com>
Date: Sun, 16 Sep 2012 19:00:26 +1000
Message-ID: <CAOzFzEhh7pfpcq+0X-g7BXGAyNqgb8dZT4=Ys=Pmu1dFqH+46A@mail.gmail.com>
From: Joseph Glanville <joseph.glanville@orionvm.com.au>
To: Keir Fraser <keir.xen@gmail.com>
X-Gm-Message-State: ALoCoQkaVKtffZAi2rOdXx4ISzFXIqbUojXAQ1sZbeErnG0ozRX/kD3ilN+X//oDjsRqub1TYGaV
Cc: James Harper <james.harper@bendigoit.com.au>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] bug when using 4K sectors?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 16 September 2012 18:31, Keir Fraser <keir.xen@gmail.com> wrote:
> On 16/09/2012 08:00, "Joseph Glanville" <joseph.glanville@orionvm.com.au>
> wrote:
>
>> After reading through blkback it appears that it can only support 512
>> byte sector sizes and removing this limitation would take quite abit
>> of work.
>> It uses hard coded bitshifts pervasively to convert between number of
>> requests/pages and size of sectors etc. (that is all the >> 9
>> everywhere)
>>
>> I am going to see what I can about working on getting it to support 4k
>> sectors too and eventually uncoupled logical/physical sizes but that
>> would take even more work as far as I can tell.
>>
>> Being able to use 4k sectors seems like it would provide pretty
>> massive gains in performance just by being more efficient let alone
>> increasing byte aligned writes to the underlying block storage system.
>
> The PV blk transport may be based on 512-byte sectors, but the real sector
> size is communicated between blkfront and blkback via xenbus (field
> 'sector-size') and blkfront is expected to only make requests that are
> multiple of, and aligned according to, that real 'sector-size'.
>
> I would kind of expect it to work, as CD-ROMs have a larger sector size (2kB
> IIRC) and we support those...
>
> Bashing your head against the PV blk transport code may be premature. ;)
>
>  -- Keir
>
>

Understood, still have a fair bit of reading to do. :)

Thanks,
Joseph.

-- 
CTO | Orion Virtualisation Solutions | www.orionvm.com.au
Phone: 1300 56 99 52 | Mobile: 0428 754 846

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Sep 16 10:38:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 16 Sep 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 1TDCEQ-0008Vw-VA; Sun, 16 Sep 2012 10:37:42 +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 1TDCEP-0008Vr-Dn
	for xen-devel@lists.xen.org; Sun, 16 Sep 2012 10:37:41 +0000
Received: from [85.158.139.211:8562] by server-4.bemta-5.messagelabs.com id
	C3/89-23042-4FBA5505; Sun, 16 Sep 2012 10:37:40 +0000
X-Env-Sender: james.harper@bendigoit.com.au
X-Msg-Ref: server-5.tower-206.messagelabs.com!1347791856!18694720!1
X-Originating-IP: [203.16.224.4]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24694 invoked from network); 16 Sep 2012 10:37:39 -0000
Received: from smtp1.bendigoit.com.au (HELO smtp1.bendigoit.com.au)
	(203.16.224.4)
	by server-5.tower-206.messagelabs.com with AES256-SHA encrypted SMTP;
	16 Sep 2012 10:37:39 -0000
Received: from [2001:388:e000:712:a5ca:4fd3:14f:ad5d]
	(helo=BITCOM1.int.sbss.com.au)
	by smtp1.bendigoit.com.au with esmtp (Exim 4.69)
	(envelope-from <james.harper@bendigoit.com.au>)
	id 1TDCE8-00026o-Iw; Sun, 16 Sep 2012 20:37:24 +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 id
	14.01.0379.000; Sun, 16 Sep 2012 20:37:24 +1000
From: James Harper <james.harper@bendigoit.com.au>
To: Keir Fraser <keir.xen@gmail.com>, Joseph Glanville
	<joseph.glanville@orionvm.com.au>, Konrad Rzeszutek Wilk
	<konrad.wilk@oracle.com>
Thread-Topic: [Xen-devel] bug when using 4K sectors?
Thread-Index: Ac15XJ9mOEWrLpZlQnymzekcRdWXAQR9LPqAABwcDwAAAjyqAAHumRqAAAMtwQAAGTSEYA==
Date: Sun, 16 Sep 2012 10:37:23 +0000
Message-ID: <6035A0D088A63A46850C3988ED045A4B29B96FA1@BITCOM1.int.sbss.com.au>
References: <CAOzFzEiZopdFQuZkUcSWWre9b=NeZpJM9n2VtEoZcRo=ejYQPA@mail.gmail.com>
	<CC7B4CE4.3EE74%keir.xen@gmail.com>
In-Reply-To: <CC7B4CE4.3EE74%keir.xen@gmail.com>
Accept-Language: en-AU, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [172.16.3.132]
x-tm-as-product-ver: SMEX-10.2.0.2087-7.000.1014-19186.006
x-tm-as-result: No--39.635800-0.000000-31
x-tm-as-user-approved-sender: Yes
x-tm-as-user-blocked-sender: No
MIME-Version: 1.0
X-Really-From-Bendigo-IT: magichashvalue
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] bug when using 4K sectors?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> > Being able to use 4k sectors seems like it would provide pretty
> > massive gains in performance just by being more efficient let alone
> > increasing byte aligned writes to the underlying block storage system.
> 
> The PV blk transport may be based on 512-byte sectors, but the real sector
> size is communicated between blkfront and blkback via xenbus (field
> 'sector-size') and blkfront is expected to only make requests that are
> multiple of, and aligned according to, that real 'sector-size'.
> 
> I would kind of expect it to work, as CD-ROMs have a larger sector size (2kB
> IIRC) and we support those...
> 
> Bashing your head against the PV blk transport code may be premature. ;)
> 

So a sector-size of 4096 would basically be a 512e device, allowing the underlying OS to communicate in 512 byte blocks but knowing that things will work best in 4096 byte sized transfers aligned to multiples of 4096 bytes, right?

James


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Sep 16 10:38:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 16 Sep 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 1TDCEQ-0008Vw-VA; Sun, 16 Sep 2012 10:37:42 +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 1TDCEP-0008Vr-Dn
	for xen-devel@lists.xen.org; Sun, 16 Sep 2012 10:37:41 +0000
Received: from [85.158.139.211:8562] by server-4.bemta-5.messagelabs.com id
	C3/89-23042-4FBA5505; Sun, 16 Sep 2012 10:37:40 +0000
X-Env-Sender: james.harper@bendigoit.com.au
X-Msg-Ref: server-5.tower-206.messagelabs.com!1347791856!18694720!1
X-Originating-IP: [203.16.224.4]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24694 invoked from network); 16 Sep 2012 10:37:39 -0000
Received: from smtp1.bendigoit.com.au (HELO smtp1.bendigoit.com.au)
	(203.16.224.4)
	by server-5.tower-206.messagelabs.com with AES256-SHA encrypted SMTP;
	16 Sep 2012 10:37:39 -0000
Received: from [2001:388:e000:712:a5ca:4fd3:14f:ad5d]
	(helo=BITCOM1.int.sbss.com.au)
	by smtp1.bendigoit.com.au with esmtp (Exim 4.69)
	(envelope-from <james.harper@bendigoit.com.au>)
	id 1TDCE8-00026o-Iw; Sun, 16 Sep 2012 20:37:24 +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 id
	14.01.0379.000; Sun, 16 Sep 2012 20:37:24 +1000
From: James Harper <james.harper@bendigoit.com.au>
To: Keir Fraser <keir.xen@gmail.com>, Joseph Glanville
	<joseph.glanville@orionvm.com.au>, Konrad Rzeszutek Wilk
	<konrad.wilk@oracle.com>
Thread-Topic: [Xen-devel] bug when using 4K sectors?
Thread-Index: Ac15XJ9mOEWrLpZlQnymzekcRdWXAQR9LPqAABwcDwAAAjyqAAHumRqAAAMtwQAAGTSEYA==
Date: Sun, 16 Sep 2012 10:37:23 +0000
Message-ID: <6035A0D088A63A46850C3988ED045A4B29B96FA1@BITCOM1.int.sbss.com.au>
References: <CAOzFzEiZopdFQuZkUcSWWre9b=NeZpJM9n2VtEoZcRo=ejYQPA@mail.gmail.com>
	<CC7B4CE4.3EE74%keir.xen@gmail.com>
In-Reply-To: <CC7B4CE4.3EE74%keir.xen@gmail.com>
Accept-Language: en-AU, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [172.16.3.132]
x-tm-as-product-ver: SMEX-10.2.0.2087-7.000.1014-19186.006
x-tm-as-result: No--39.635800-0.000000-31
x-tm-as-user-approved-sender: Yes
x-tm-as-user-blocked-sender: No
MIME-Version: 1.0
X-Really-From-Bendigo-IT: magichashvalue
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] bug when using 4K sectors?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> > Being able to use 4k sectors seems like it would provide pretty
> > massive gains in performance just by being more efficient let alone
> > increasing byte aligned writes to the underlying block storage system.
> 
> The PV blk transport may be based on 512-byte sectors, but the real sector
> size is communicated between blkfront and blkback via xenbus (field
> 'sector-size') and blkfront is expected to only make requests that are
> multiple of, and aligned according to, that real 'sector-size'.
> 
> I would kind of expect it to work, as CD-ROMs have a larger sector size (2kB
> IIRC) and we support those...
> 
> Bashing your head against the PV blk transport code may be premature. ;)
> 

So a sector-size of 4096 would basically be a 512e device, allowing the underlying OS to communicate in 512 byte blocks but knowing that things will work best in 4096 byte sized transfers aligned to multiples of 4096 bytes, right?

James


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Sep 16 11:19:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 16 Sep 2012 11: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 1TDCru-0000LD-CO; Sun, 16 Sep 2012 11:18:30 +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 1TDCrs-0000L8-Ls
	for xen-devel@lists.xen.org; Sun, 16 Sep 2012 11:18:28 +0000
Received: from [85.158.139.211:34213] by server-5.bemta-5.messagelabs.com id
	2D/C1-30514-385B5505; Sun, 16 Sep 2012 11:18:27 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-9.tower-206.messagelabs.com!1347794307!17232549!1
X-Originating-IP: [74.125.82.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25870 invoked from network); 16 Sep 2012 11:18:27 -0000
Received: from mail-we0-f173.google.com (HELO mail-we0-f173.google.com)
	(74.125.82.173)
	by server-9.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Sep 2012 11:18:27 -0000
Received: by weyz53 with SMTP id z53so3935678wey.32
	for <xen-devel@lists.xen.org>; Sun, 16 Sep 2012 04:18: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=pROnYNd7qiDjtLddakQicLeKE5/G+3m6hGvwdQDW0Oc=;
	b=HOzufG6feosp6vD3mXy28I6+QPfNXjCJowoO/wKQr2QJj4k3MXqgTt8qtF6fMepQ6o
	XYU1JLXTQ+6rmMHN0m9RSidXAawKhupIpM9iZhaWU7FdAmezn9VqWr23TIGZU/ZEFkAf
	Ucm2bgAhNzhTOb4yV354R7nL+DPm5gbmQxIu+XAH/WFyl/1hy/M8RR2dVK2qzRMcwVNN
	tTVGBb9gw3kZ+HMLhbLQvmBaHjLPPY4UmBw9NBh0BZFnM6wlRbT0XhGkcqLfjhIlORMN
	uckdJJhxKFUCjOqxlIcBPOFayslx9csgo962uMGMFyw0zdJZXnTtYyud9XVx7jXOc2cv
	gHHQ==
Received: by 10.216.194.223 with SMTP id m73mr4606315wen.144.1347794306972;
	Sun, 16 Sep 2012 04:18:26 -0700 (PDT)
Received: from [192.168.1.69] (host86-183-251-65.range86-183.btcentralplus.com.
	[86.183.251.65])
	by mx.google.com with ESMTPS id t8sm11156407wiy.3.2012.09.16.04.18.24
	(version=SSLv3 cipher=OTHER); Sun, 16 Sep 2012 04:18:26 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Sun, 16 Sep 2012 12:18:18 +0100
From: Keir Fraser <keir.xen@gmail.com>
To: James Harper <james.harper@bendigoit.com.au>,
	Joseph Glanville <joseph.glanville@orionvm.com.au>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Message-ID: <CC7B740A.3EE89%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] bug when using 4K sectors?
Thread-Index: Ac15XJ9mOEWrLpZlQnymzekcRdWXAQR9LPqAABwcDwAAAjyqAAHumRqAAAMtwQAAGTSEYAABlUzV
In-Reply-To: <6035A0D088A63A46850C3988ED045A4B29B96FA1@BITCOM1.int.sbss.com.au>
Mime-version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] bug when using 4K sectors?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 16/09/2012 11:37, "James Harper" <james.harper@bendigoit.com.au> wrote:

>>> Being able to use 4k sectors seems like it would provide pretty
>>> massive gains in performance just by being more efficient let alone
>>> increasing byte aligned writes to the underlying block storage system.
>> 
>> The PV blk transport may be based on 512-byte sectors, but the real sector
>> size is communicated between blkfront and blkback via xenbus (field
>> 'sector-size') and blkfront is expected to only make requests that are
>> multiple of, and aligned according to, that real 'sector-size'.
>> 
>> I would kind of expect it to work, as CD-ROMs have a larger sector size (2kB
>> IIRC) and we support those...
>> 
>> Bashing your head against the PV blk transport code may be premature. ;)
>> 
> 
> So a sector-size of 4096 would basically be a 512e device, allowing the
> underlying OS to communicate in 512 byte blocks but knowing that things will
> work best in 4096 byte sized transfers aligned to multiples of 4096 bytes,
> right?

My recollection is that blkfront is required to submit only appropriately
-sized and -aligned requests; i.e. it's not merely advisory. I remember this
got added for CD-ROM support and if they had worked without this, I'm sure
we wouldn't have bothered!

 -- Keir

> James
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Sep 16 11:19:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 16 Sep 2012 11: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 1TDCru-0000LD-CO; Sun, 16 Sep 2012 11:18:30 +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 1TDCrs-0000L8-Ls
	for xen-devel@lists.xen.org; Sun, 16 Sep 2012 11:18:28 +0000
Received: from [85.158.139.211:34213] by server-5.bemta-5.messagelabs.com id
	2D/C1-30514-385B5505; Sun, 16 Sep 2012 11:18:27 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-9.tower-206.messagelabs.com!1347794307!17232549!1
X-Originating-IP: [74.125.82.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25870 invoked from network); 16 Sep 2012 11:18:27 -0000
Received: from mail-we0-f173.google.com (HELO mail-we0-f173.google.com)
	(74.125.82.173)
	by server-9.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Sep 2012 11:18:27 -0000
Received: by weyz53 with SMTP id z53so3935678wey.32
	for <xen-devel@lists.xen.org>; Sun, 16 Sep 2012 04:18: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=pROnYNd7qiDjtLddakQicLeKE5/G+3m6hGvwdQDW0Oc=;
	b=HOzufG6feosp6vD3mXy28I6+QPfNXjCJowoO/wKQr2QJj4k3MXqgTt8qtF6fMepQ6o
	XYU1JLXTQ+6rmMHN0m9RSidXAawKhupIpM9iZhaWU7FdAmezn9VqWr23TIGZU/ZEFkAf
	Ucm2bgAhNzhTOb4yV354R7nL+DPm5gbmQxIu+XAH/WFyl/1hy/M8RR2dVK2qzRMcwVNN
	tTVGBb9gw3kZ+HMLhbLQvmBaHjLPPY4UmBw9NBh0BZFnM6wlRbT0XhGkcqLfjhIlORMN
	uckdJJhxKFUCjOqxlIcBPOFayslx9csgo962uMGMFyw0zdJZXnTtYyud9XVx7jXOc2cv
	gHHQ==
Received: by 10.216.194.223 with SMTP id m73mr4606315wen.144.1347794306972;
	Sun, 16 Sep 2012 04:18:26 -0700 (PDT)
Received: from [192.168.1.69] (host86-183-251-65.range86-183.btcentralplus.com.
	[86.183.251.65])
	by mx.google.com with ESMTPS id t8sm11156407wiy.3.2012.09.16.04.18.24
	(version=SSLv3 cipher=OTHER); Sun, 16 Sep 2012 04:18:26 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Sun, 16 Sep 2012 12:18:18 +0100
From: Keir Fraser <keir.xen@gmail.com>
To: James Harper <james.harper@bendigoit.com.au>,
	Joseph Glanville <joseph.glanville@orionvm.com.au>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Message-ID: <CC7B740A.3EE89%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] bug when using 4K sectors?
Thread-Index: Ac15XJ9mOEWrLpZlQnymzekcRdWXAQR9LPqAABwcDwAAAjyqAAHumRqAAAMtwQAAGTSEYAABlUzV
In-Reply-To: <6035A0D088A63A46850C3988ED045A4B29B96FA1@BITCOM1.int.sbss.com.au>
Mime-version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] bug when using 4K sectors?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 16/09/2012 11:37, "James Harper" <james.harper@bendigoit.com.au> wrote:

>>> Being able to use 4k sectors seems like it would provide pretty
>>> massive gains in performance just by being more efficient let alone
>>> increasing byte aligned writes to the underlying block storage system.
>> 
>> The PV blk transport may be based on 512-byte sectors, but the real sector
>> size is communicated between blkfront and blkback via xenbus (field
>> 'sector-size') and blkfront is expected to only make requests that are
>> multiple of, and aligned according to, that real 'sector-size'.
>> 
>> I would kind of expect it to work, as CD-ROMs have a larger sector size (2kB
>> IIRC) and we support those...
>> 
>> Bashing your head against the PV blk transport code may be premature. ;)
>> 
> 
> So a sector-size of 4096 would basically be a 512e device, allowing the
> underlying OS to communicate in 512 byte blocks but knowing that things will
> work best in 4096 byte sized transfers aligned to multiples of 4096 bytes,
> right?

My recollection is that blkfront is required to submit only appropriately
-sized and -aligned requests; i.e. it's not merely advisory. I remember this
got added for CD-ROM support and if they had worked without this, I'm sure
we wouldn't have bothered!

 -- Keir

> James
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Sep 16 11:22:33 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 16 Sep 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 1TDCvI-0000Rk-0H; Sun, 16 Sep 2012 11:22:00 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <james.harper@bendigoit.com.au>) id 1TDCvH-0000Rb-Cc
	for xen-devel@lists.xen.org; Sun, 16 Sep 2012 11:21:59 +0000
X-Env-Sender: james.harper@bendigoit.com.au
X-Msg-Ref: server-7.tower-27.messagelabs.com!1347794510!3502345!1
X-Originating-IP: [203.16.224.4]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8587 invoked from network); 16 Sep 2012 11:21:52 -0000
Received: from smtp1.bendigoit.com.au (HELO smtp1.bendigoit.com.au)
	(203.16.224.4)
	by server-7.tower-27.messagelabs.com with AES256-SHA encrypted SMTP;
	16 Sep 2012 11:21:52 -0000
Received: from [2001:388:e000:712:a5ca:4fd3:14f:ad5d]
	(helo=BITCOM1.int.sbss.com.au)
	by smtp1.bendigoit.com.au with esmtp (Exim 4.69)
	(envelope-from <james.harper@bendigoit.com.au>)
	id 1TDCuy-0002Ea-N5; Sun, 16 Sep 2012 21:21:41 +1000
Received: from BITCOM1.int.sbss.com.au ([fe80::a5ca:4fd3:14f:ad5d]) by
	BITCOM1.int.sbss.com.au ([fe80::a5ca:4fd3:14f:ad5d%12]) with mapi id
	14.01.0379.000; Sun, 16 Sep 2012 21:21:35 +1000
From: James Harper <james.harper@bendigoit.com.au>
To: Keir Fraser <keir.xen@gmail.com>, Joseph Glanville
	<joseph.glanville@orionvm.com.au>, Konrad Rzeszutek Wilk
	<konrad.wilk@oracle.com>
Thread-Topic: [Xen-devel] bug when using 4K sectors?
Thread-Index: Ac15XJ9mOEWrLpZlQnymzekcRdWXAQR9LPqAABwcDwAAAjyqAAHumRqAAAMtwQAAGTSEYAABlUzVAAALPUA=
Date: Sun, 16 Sep 2012 11:21:33 +0000
Message-ID: <6035A0D088A63A46850C3988ED045A4B29B9806B@BITCOM1.int.sbss.com.au>
References: <6035A0D088A63A46850C3988ED045A4B29B96FA1@BITCOM1.int.sbss.com.au>
	<CC7B740A.3EE89%keir.xen@gmail.com>
In-Reply-To: <CC7B740A.3EE89%keir.xen@gmail.com>
Accept-Language: en-AU, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [172.16.3.132]
x-tm-as-product-ver: SMEX-10.2.0.2087-7.000.1014-19186.006
x-tm-as-result: No--42.108700-0.000000-31
x-tm-as-user-approved-sender: Yes
x-tm-as-user-blocked-sender: No
MIME-Version: 1.0
X-Really-From-Bendigo-IT: magichashvalue
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] bug when using 4K sectors?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 a sector-size of 4096 would basically be a 512e device, allowing
> > the underlying OS to communicate in 512 byte blocks but knowing that
> > things will work best in 4096 byte sized transfers aligned to
> > multiples of 4096 bytes, right?
> 
> My recollection is that blkfront is required to submit only appropriately -sized
> and -aligned requests; i.e. it's not merely advisory. I remember this got
> added for CD-ROM support and if they had worked without this, I'm sure we
> wouldn't have bothered!
> 

That's a shame. It would be good to have separate values for Physical and Logical block sizes so the guest VM can make appropriate alignment decisions. In fact there is a lot of stuff in /sys for the block devices that would be nice to be mapped into xenstore!

James

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Sep 16 11:22:33 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 16 Sep 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 1TDCvI-0000Rk-0H; Sun, 16 Sep 2012 11:22:00 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <james.harper@bendigoit.com.au>) id 1TDCvH-0000Rb-Cc
	for xen-devel@lists.xen.org; Sun, 16 Sep 2012 11:21:59 +0000
X-Env-Sender: james.harper@bendigoit.com.au
X-Msg-Ref: server-7.tower-27.messagelabs.com!1347794510!3502345!1
X-Originating-IP: [203.16.224.4]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8587 invoked from network); 16 Sep 2012 11:21:52 -0000
Received: from smtp1.bendigoit.com.au (HELO smtp1.bendigoit.com.au)
	(203.16.224.4)
	by server-7.tower-27.messagelabs.com with AES256-SHA encrypted SMTP;
	16 Sep 2012 11:21:52 -0000
Received: from [2001:388:e000:712:a5ca:4fd3:14f:ad5d]
	(helo=BITCOM1.int.sbss.com.au)
	by smtp1.bendigoit.com.au with esmtp (Exim 4.69)
	(envelope-from <james.harper@bendigoit.com.au>)
	id 1TDCuy-0002Ea-N5; Sun, 16 Sep 2012 21:21:41 +1000
Received: from BITCOM1.int.sbss.com.au ([fe80::a5ca:4fd3:14f:ad5d]) by
	BITCOM1.int.sbss.com.au ([fe80::a5ca:4fd3:14f:ad5d%12]) with mapi id
	14.01.0379.000; Sun, 16 Sep 2012 21:21:35 +1000
From: James Harper <james.harper@bendigoit.com.au>
To: Keir Fraser <keir.xen@gmail.com>, Joseph Glanville
	<joseph.glanville@orionvm.com.au>, Konrad Rzeszutek Wilk
	<konrad.wilk@oracle.com>
Thread-Topic: [Xen-devel] bug when using 4K sectors?
Thread-Index: Ac15XJ9mOEWrLpZlQnymzekcRdWXAQR9LPqAABwcDwAAAjyqAAHumRqAAAMtwQAAGTSEYAABlUzVAAALPUA=
Date: Sun, 16 Sep 2012 11:21:33 +0000
Message-ID: <6035A0D088A63A46850C3988ED045A4B29B9806B@BITCOM1.int.sbss.com.au>
References: <6035A0D088A63A46850C3988ED045A4B29B96FA1@BITCOM1.int.sbss.com.au>
	<CC7B740A.3EE89%keir.xen@gmail.com>
In-Reply-To: <CC7B740A.3EE89%keir.xen@gmail.com>
Accept-Language: en-AU, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [172.16.3.132]
x-tm-as-product-ver: SMEX-10.2.0.2087-7.000.1014-19186.006
x-tm-as-result: No--42.108700-0.000000-31
x-tm-as-user-approved-sender: Yes
x-tm-as-user-blocked-sender: No
MIME-Version: 1.0
X-Really-From-Bendigo-IT: magichashvalue
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] bug when using 4K sectors?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 a sector-size of 4096 would basically be a 512e device, allowing
> > the underlying OS to communicate in 512 byte blocks but knowing that
> > things will work best in 4096 byte sized transfers aligned to
> > multiples of 4096 bytes, right?
> 
> My recollection is that blkfront is required to submit only appropriately -sized
> and -aligned requests; i.e. it's not merely advisory. I remember this got
> added for CD-ROM support and if they had worked without this, I'm sure we
> wouldn't have bothered!
> 

That's a shame. It would be good to have separate values for Physical and Logical block sizes so the guest VM can make appropriate alignment decisions. In fact there is a lot of stuff in /sys for the block devices that would be nice to be mapped into xenstore!

James

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Sep 16 11:23:19 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 16 Sep 2012 11: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 1TDCwD-0000WM-EN; Sun, 16 Sep 2012 11:22:57 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <alan@lxorguk.ukuu.org.uk>) id 1TDCwC-0000WA-73
	for xen-devel@lists.xen.org; Sun, 16 Sep 2012 11:22:56 +0000
Received: from [85.158.139.211:25182] by server-3.bemta-5.messagelabs.com id
	39/C9-21836-F86B5505; Sun, 16 Sep 2012 11:22:55 +0000
X-Env-Sender: alan@lxorguk.ukuu.org.uk
X-Msg-Ref: server-9.tower-206.messagelabs.com!1347794574!17232779!1
X-Originating-IP: [81.2.110.251]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32070 invoked from network); 16 Sep 2012 11:22:54 -0000
Received: from lxorguk.ukuu.org.uk (HELO lxorguk.ukuu.org.uk) (81.2.110.251)
	by server-9.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 16 Sep 2012 11:22: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 q8GBshb1017807;
	Sun, 16 Sep 2012 12:54:48 +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 q8GBR4wF008587;
	Sun, 16 Sep 2012 12:27:04 +0100
Date: Sun, 16 Sep 2012 12:27:04 +0100
From: Alan Cox <alan@lxorguk.ukuu.org.uk>
To: Keir Fraser <keir.xen@gmail.com>
Message-ID: <20120916122704.4ea05b45@pyramind.ukuu.org.uk>
In-Reply-To: <CC7B4CE4.3EE74%keir.xen@gmail.com>
References: <CAOzFzEiZopdFQuZkUcSWWre9b=NeZpJM9n2VtEoZcRo=ejYQPA@mail.gmail.com>
	<CC7B4CE4.3EE74%keir.xen@gmail.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: Joseph Glanville <joseph.glanville@orionvm.com.au>,
	James Harper <james.harper@bendigoit.com.au>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] bug when using 4K sectors?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 would kind of expect it to work, as CD-ROMs have a larger sector size (2kB
> IIRC) and we support those...

For data blocks they are 2K, as are some magneto-opticals.

The more complicated case is modern hard disks, while you can access them
on 512 byte boundaries they are actually using bigger block sizes but the
large blocks are not neccessarily on the 0 boundary in order to get
optimal alignment for existing file systems and partitioning.

So knowing the block size isn't the whole story.

Alan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Sep 16 11:23:19 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 16 Sep 2012 11: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 1TDCwD-0000WM-EN; Sun, 16 Sep 2012 11:22:57 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <alan@lxorguk.ukuu.org.uk>) id 1TDCwC-0000WA-73
	for xen-devel@lists.xen.org; Sun, 16 Sep 2012 11:22:56 +0000
Received: from [85.158.139.211:25182] by server-3.bemta-5.messagelabs.com id
	39/C9-21836-F86B5505; Sun, 16 Sep 2012 11:22:55 +0000
X-Env-Sender: alan@lxorguk.ukuu.org.uk
X-Msg-Ref: server-9.tower-206.messagelabs.com!1347794574!17232779!1
X-Originating-IP: [81.2.110.251]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32070 invoked from network); 16 Sep 2012 11:22:54 -0000
Received: from lxorguk.ukuu.org.uk (HELO lxorguk.ukuu.org.uk) (81.2.110.251)
	by server-9.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 16 Sep 2012 11:22: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 q8GBshb1017807;
	Sun, 16 Sep 2012 12:54:48 +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 q8GBR4wF008587;
	Sun, 16 Sep 2012 12:27:04 +0100
Date: Sun, 16 Sep 2012 12:27:04 +0100
From: Alan Cox <alan@lxorguk.ukuu.org.uk>
To: Keir Fraser <keir.xen@gmail.com>
Message-ID: <20120916122704.4ea05b45@pyramind.ukuu.org.uk>
In-Reply-To: <CC7B4CE4.3EE74%keir.xen@gmail.com>
References: <CAOzFzEiZopdFQuZkUcSWWre9b=NeZpJM9n2VtEoZcRo=ejYQPA@mail.gmail.com>
	<CC7B4CE4.3EE74%keir.xen@gmail.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: Joseph Glanville <joseph.glanville@orionvm.com.au>,
	James Harper <james.harper@bendigoit.com.au>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] bug when using 4K sectors?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 would kind of expect it to work, as CD-ROMs have a larger sector size (2kB
> IIRC) and we support those...

For data blocks they are 2K, as are some magneto-opticals.

The more complicated case is modern hard disks, while you can access them
on 512 byte boundaries they are actually using bigger block sizes but the
large blocks are not neccessarily on the 0 boundary in order to get
optimal alignment for existing file systems and partitioning.

So knowing the block size isn't the whole story.

Alan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Sep 16 11:40:16 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 16 Sep 2012 11:40:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDDCc-0000oP-25; Sun, 16 Sep 2012 11:39: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 1TDDCa-0000oK-Rt
	for xen-devel@lists.xensource.com; Sun, 16 Sep 2012 11:39:53 +0000
Received: from [85.158.139.83:23683] by server-7.bemta-5.messagelabs.com id
	F6/F1-19703-88AB5505; Sun, 16 Sep 2012 11:39:52 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1347795591!30553133!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDk2MjY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16310 invoked from network); 16 Sep 2012 11:39:51 -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 Sep 2012 11:39:51 -0000
X-IronPort-AV: E=Sophos;i="4.80,429,1344211200"; d="scan'208";a="14565244"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Sep 2012 11:39: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.279.1; Sun, 16 Sep 2012 12:39: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 1TDDCY-0000Bt-RJ;
	Sun, 16 Sep 2012 11:39:50 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1TDDCY-00066T-Bc;
	Sun, 16 Sep 2012 12:39:50 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-13783-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sun, 16 Sep 2012 12:39:50 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [qemu-upstream-4.2-testing baseline test] 13783:
	tolerable FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

"Old" tested version had not actually been tested; therefore in this
flight we test it, rather than a new candidate.  The baseline, if
any, is the most recent actually tested revision.

flight 13783 qemu-upstream-4.2-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13783/

Failures :-/ but no regressions.

Tests which did not succeed,
including tests which could not be run:
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  9 guest-localmigrate fail never pass
 test-amd64-amd64-qemuu-win   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64  9 guest-localmigrate      fail never pass
 test-amd64-i386-xl-qemuu-win-vcpus1  9 guest-localmigrate      fail never pass
 test-amd64-i386-xend-qemuu-winxpsp3 16 leak-check/check        fail never pass
 test-i386-i386-qemuu-win     16 leak-check/check             fail   never pass
 test-amd64-i386-qemuu-win-vcpus1 16 leak-check/check           fail never pass
 test-i386-i386-xl-qemuu-win   9 guest-localmigrate           fail   never pass
 test-amd64-i386-qemuu-win    16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemuu-win  9 guest-localmigrate           fail  never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail never pass
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass


jobs:
 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                           pass    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-win-vcpus1                             fail    
 test-amd64-i386-xl-qemuu-win-vcpus1                          fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-amd64-qemuu-win                                   fail    
 test-amd64-i386-qemuu-win                                    fail    
 test-i386-i386-qemuu-win                                     fail    
 test-amd64-amd64-xl-qemuu-win                                fail    
 test-i386-i386-xl-qemuu-win                                  fail    
 test-amd64-i386-xend-qemuu-winxpsp3                          fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


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 Sep 16 11:40:16 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 16 Sep 2012 11:40:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDDCc-0000oP-25; Sun, 16 Sep 2012 11:39: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 1TDDCa-0000oK-Rt
	for xen-devel@lists.xensource.com; Sun, 16 Sep 2012 11:39:53 +0000
Received: from [85.158.139.83:23683] by server-7.bemta-5.messagelabs.com id
	F6/F1-19703-88AB5505; Sun, 16 Sep 2012 11:39:52 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1347795591!30553133!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDk2MjY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16310 invoked from network); 16 Sep 2012 11:39:51 -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 Sep 2012 11:39:51 -0000
X-IronPort-AV: E=Sophos;i="4.80,429,1344211200"; d="scan'208";a="14565244"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Sep 2012 11:39: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.279.1; Sun, 16 Sep 2012 12:39: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 1TDDCY-0000Bt-RJ;
	Sun, 16 Sep 2012 11:39:50 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1TDDCY-00066T-Bc;
	Sun, 16 Sep 2012 12:39:50 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-13783-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sun, 16 Sep 2012 12:39:50 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [qemu-upstream-4.2-testing baseline test] 13783:
	tolerable FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

"Old" tested version had not actually been tested; therefore in this
flight we test it, rather than a new candidate.  The baseline, if
any, is the most recent actually tested revision.

flight 13783 qemu-upstream-4.2-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13783/

Failures :-/ but no regressions.

Tests which did not succeed,
including tests which could not be run:
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  9 guest-localmigrate fail never pass
 test-amd64-amd64-qemuu-win   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64  9 guest-localmigrate      fail never pass
 test-amd64-i386-xl-qemuu-win-vcpus1  9 guest-localmigrate      fail never pass
 test-amd64-i386-xend-qemuu-winxpsp3 16 leak-check/check        fail never pass
 test-i386-i386-qemuu-win     16 leak-check/check             fail   never pass
 test-amd64-i386-qemuu-win-vcpus1 16 leak-check/check           fail never pass
 test-i386-i386-xl-qemuu-win   9 guest-localmigrate           fail   never pass
 test-amd64-i386-qemuu-win    16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemuu-win  9 guest-localmigrate           fail  never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail never pass
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass


jobs:
 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                           pass    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-win-vcpus1                             fail    
 test-amd64-i386-xl-qemuu-win-vcpus1                          fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-amd64-qemuu-win                                   fail    
 test-amd64-i386-qemuu-win                                    fail    
 test-i386-i386-qemuu-win                                     fail    
 test-amd64-amd64-xl-qemuu-win                                fail    
 test-i386-i386-xl-qemuu-win                                  fail    
 test-amd64-i386-xend-qemuu-winxpsp3                          fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


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 Sep 16 11:51:23 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 16 Sep 2012 11:51:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDDNL-0000zD-Ht; Sun, 16 Sep 2012 11:50:59 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <james.harper@bendigoit.com.au>) id 1TDDNJ-0000z8-5q
	for xen-devel@lists.xen.org; Sun, 16 Sep 2012 11:50:57 +0000
Received: from [85.158.143.35:38165] by server-2.bemta-4.messagelabs.com id
	67/32-21239-02DB5505; Sun, 16 Sep 2012 11:50:56 +0000
X-Env-Sender: james.harper@bendigoit.com.au
X-Msg-Ref: server-15.tower-21.messagelabs.com!1347796252!14856046!1
X-Originating-IP: [203.16.207.99]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19937 invoked from network); 16 Sep 2012 11:50:55 -0000
Received: from mail.bendigoit.com.au (HELO smtp2.bendigoit.com.au)
	(203.16.207.99)
	by server-15.tower-21.messagelabs.com with AES256-SHA encrypted SMTP;
	16 Sep 2012 11:50:55 -0000
Received: from [2001:388:e000:712:a5ca:4fd3:14f:ad5d]
	(helo=BITCOM1.int.sbss.com.au)
	by smtp2.bendigoit.com.au with esmtp (Exim 4.72)
	(envelope-from <james.harper@bendigoit.com.au>)
	id 1TDDMv-0001CR-S5; Sun, 16 Sep 2012 21:50: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 id
	14.01.0379.000; Sun, 16 Sep 2012 21:50:33 +1000
From: James Harper <james.harper@bendigoit.com.au>
To: Alan Cox <alan@lxorguk.ukuu.org.uk>, Keir Fraser <keir.xen@gmail.com>
Thread-Topic: [Xen-devel] bug when using 4K sectors?
Thread-Index: Ac15XJ9mOEWrLpZlQnymzekcRdWXAQR9LPqAABwcDwAAAjyqAAHumRqAAAMtwQAABiPGAAAVq48g
Date: Sun, 16 Sep 2012 11:50:31 +0000
Message-ID: <6035A0D088A63A46850C3988ED045A4B29B980EB@BITCOM1.int.sbss.com.au>
References: <CAOzFzEiZopdFQuZkUcSWWre9b=NeZpJM9n2VtEoZcRo=ejYQPA@mail.gmail.com>
	<CC7B4CE4.3EE74%keir.xen@gmail.com>
	<20120916122704.4ea05b45@pyramind.ukuu.org.uk>
In-Reply-To: <20120916122704.4ea05b45@pyramind.ukuu.org.uk>
Accept-Language: en-AU, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [172.16.3.132]
x-tm-as-product-ver: SMEX-10.2.0.2087-7.000.1014-19186.006
x-tm-as-result: No--33.814600-0.000000-31
x-tm-as-user-approved-sender: Yes
x-tm-as-user-blocked-sender: No
MIME-Version: 1.0
X-Really-From-Bendigo-IT: magichashvalue
Cc: Joseph Glanville <joseph.glanville@orionvm.com.au>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] bug when using 4K sectors?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 would kind of expect it to work, as CD-ROMs have a larger sector
> > size (2kB
> > IIRC) and we support those...
> 
> For data blocks they are 2K, as are some magneto-opticals.
> 
> The more complicated case is modern hard disks, while you can access them
> on 512 byte boundaries they are actually using bigger block sizes but the large
> blocks are not neccessarily on the 0 boundary in order to get optimal
> alignment for existing file systems and partitioning.
> 
> So knowing the block size isn't the whole story.
> 

Are you saying that Xen and/or Linux needs to worry about a user setting up a poorly aligned filesystem to pass to a VM? Seems simpler just to set things up right in the first place.

Or did you mean something else?

James


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Sep 16 11:51:23 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 16 Sep 2012 11:51:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDDNL-0000zD-Ht; Sun, 16 Sep 2012 11:50:59 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <james.harper@bendigoit.com.au>) id 1TDDNJ-0000z8-5q
	for xen-devel@lists.xen.org; Sun, 16 Sep 2012 11:50:57 +0000
Received: from [85.158.143.35:38165] by server-2.bemta-4.messagelabs.com id
	67/32-21239-02DB5505; Sun, 16 Sep 2012 11:50:56 +0000
X-Env-Sender: james.harper@bendigoit.com.au
X-Msg-Ref: server-15.tower-21.messagelabs.com!1347796252!14856046!1
X-Originating-IP: [203.16.207.99]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19937 invoked from network); 16 Sep 2012 11:50:55 -0000
Received: from mail.bendigoit.com.au (HELO smtp2.bendigoit.com.au)
	(203.16.207.99)
	by server-15.tower-21.messagelabs.com with AES256-SHA encrypted SMTP;
	16 Sep 2012 11:50:55 -0000
Received: from [2001:388:e000:712:a5ca:4fd3:14f:ad5d]
	(helo=BITCOM1.int.sbss.com.au)
	by smtp2.bendigoit.com.au with esmtp (Exim 4.72)
	(envelope-from <james.harper@bendigoit.com.au>)
	id 1TDDMv-0001CR-S5; Sun, 16 Sep 2012 21:50: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 id
	14.01.0379.000; Sun, 16 Sep 2012 21:50:33 +1000
From: James Harper <james.harper@bendigoit.com.au>
To: Alan Cox <alan@lxorguk.ukuu.org.uk>, Keir Fraser <keir.xen@gmail.com>
Thread-Topic: [Xen-devel] bug when using 4K sectors?
Thread-Index: Ac15XJ9mOEWrLpZlQnymzekcRdWXAQR9LPqAABwcDwAAAjyqAAHumRqAAAMtwQAABiPGAAAVq48g
Date: Sun, 16 Sep 2012 11:50:31 +0000
Message-ID: <6035A0D088A63A46850C3988ED045A4B29B980EB@BITCOM1.int.sbss.com.au>
References: <CAOzFzEiZopdFQuZkUcSWWre9b=NeZpJM9n2VtEoZcRo=ejYQPA@mail.gmail.com>
	<CC7B4CE4.3EE74%keir.xen@gmail.com>
	<20120916122704.4ea05b45@pyramind.ukuu.org.uk>
In-Reply-To: <20120916122704.4ea05b45@pyramind.ukuu.org.uk>
Accept-Language: en-AU, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [172.16.3.132]
x-tm-as-product-ver: SMEX-10.2.0.2087-7.000.1014-19186.006
x-tm-as-result: No--33.814600-0.000000-31
x-tm-as-user-approved-sender: Yes
x-tm-as-user-blocked-sender: No
MIME-Version: 1.0
X-Really-From-Bendigo-IT: magichashvalue
Cc: Joseph Glanville <joseph.glanville@orionvm.com.au>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] bug when using 4K sectors?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 would kind of expect it to work, as CD-ROMs have a larger sector
> > size (2kB
> > IIRC) and we support those...
> 
> For data blocks they are 2K, as are some magneto-opticals.
> 
> The more complicated case is modern hard disks, while you can access them
> on 512 byte boundaries they are actually using bigger block sizes but the large
> blocks are not neccessarily on the 0 boundary in order to get optimal
> alignment for existing file systems and partitioning.
> 
> So knowing the block size isn't the whole story.
> 

Are you saying that Xen and/or Linux needs to worry about a user setting up a poorly aligned filesystem to pass to a VM? Seems simpler just to set things up right in the first place.

Or did you mean something else?

James


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Sep 16 14:58:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 16 Sep 2012 14:58:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDGI2-0003Oa-AD; Sun, 16 Sep 2012 14:57:42 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jmarcet@gmail.com>) id 1TDGI0-0003OV-Lw
	for xen-devel@lists.xen.org; Sun, 16 Sep 2012 14:57:40 +0000
Received: from [85.158.137.99:52852] by server-2.bemta-3.messagelabs.com id
	7A/DE-04862-3E8E5505; Sun, 16 Sep 2012 14:57:39 +0000
X-Env-Sender: jmarcet@gmail.com
X-Msg-Ref: server-13.tower-217.messagelabs.com!1347807457!17898030!1
X-Originating-IP: [209.85.210.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31972 invoked from network); 16 Sep 2012 14:57:38 -0000
Received: from mail-iy0-f173.google.com (HELO mail-iy0-f173.google.com)
	(209.85.210.173)
	by server-13.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Sep 2012 14:57:38 -0000
Received: by iakx26 with SMTP id x26so5861163iak.32
	for <xen-devel@lists.xen.org>; Sun, 16 Sep 2012 07:57: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:from:date:message-id:subject:to
	:cc:content-type:content-transfer-encoding;
	bh=tgYWBF53Mxh3bQh8/Zuf4NEVud2y0m8DlSBJ/gz1XWM=;
	b=KmAGT0y76LV6BhR1RKlodYvelifELHBeWOQELlGoAjKF2naf+M0MTUzsVz4bJnH4su
	X6esbv4+7VhtAYyAF9OchRVFELXWKnDUhOg1R+RIBvn04kp3n0tBUh5S++PTGJ78GaUA
	nuhAJMLDNnmrgKCB4erPCZkU/rjemW3JqB9oELnu05jCahrruDTO1hIfinVJxqgjOIlV
	4iAnwrcd2RwNiwjeUBiYIDK5ifjlOw1iUOpuPC9QPQI7bzeDSTx5u0BQPM/i19fae7cF
	+c26PeePm/MzCFfBSkk0cP81pfcgJs8EVicoyCrKQrkMRVpXE03nBi01ZRkc3Ly9HyNB
	jKmQ==
Received: by 10.50.195.233 with SMTP id ih9mr4336228igc.65.1347807457064; Sun,
	16 Sep 2012 07:57:37 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.64.14.212 with HTTP; Sun, 16 Sep 2012 07:57:16 -0700 (PDT)
In-Reply-To: <CACJDEmqdqA6CE9SgLL2QCNmQH1dOX0_4OHfJfzes+G6bEkQ7FA@mail.gmail.com>
References: <CAAnFQG9TZj=SxYK_jxqN=M6L40vL=AZu9EM2tbEffPhkL1s8FA@mail.gmail.com>
	<CACJDEmqdqA6CE9SgLL2QCNmQH1dOX0_4OHfJfzes+G6bEkQ7FA@mail.gmail.com>
From: Javier Marcet <jmarcet@gmail.com>
Date: Sun, 16 Sep 2012 16:57:16 +0200
Message-ID: <CAAnFQG-8Fkunv6R8+GCLAH4yQCx4-Nn0zN_Ntsf0wsh5yXeihQ@mail.gmail.com>
To: Konrad Rzeszutek Wilk <konrad@kernel.org>
Cc: Xen Devel Mailing list <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.2.0-rc4 issues with DVB tuner
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gRnJpLCBTZXAgMTQsIDIwMTIgYXQgMTA6NDcgUE0sIEtvbnJhZCBSemVzenV0ZWsgV2lsawo8
a29ucmFkQGtlcm5lbC5vcmc+IHdyb3RlOgoKPj4gVGhpcyBsYXN0IHBvaW50IGlzIGEgc2hvd3N0
b3BwZXIgZm9yIG1lIGFuZCBJIGRvbsK0dCBrbm93IHdoZXJlIHRoZQo+PiBwcm9ibGVtIG1pZ2h0
IGNvbWUgZnJvbS4gVGhlIGN4MjM4ODUgbW9kdWxlICh3aGljaCBteSB0dW5lcnMgdXNlKQo+PiBs
b2FkcyBmaW5lLCBhcyBkbyB0aGUgZGV2aWNlcyB1bmRlciAvZGV2L2R2Yi4gVXBvbiB0dW5pbmcg
YSBjaGFubmVsLAo+PiBob3dldmVyLCB0aGVyZSBpcyBub3QgZGF0YSByZWNlaXZlZC4KPj4KPj4g
RG9lcyBhbnlvbmUgaGF2ZSB0aGUgc2xpZ2h0ZXN0IGlkZWEgd2hhdCBtaWdodCBiZSBjYXVzaW5n
IHRoaXM/Cj4KPiBBcmUgdGhlcmUgYW55IHdhcm5pbmdzIG9yIHN1Y2ggYmVpbmcgcHJpbnRlZD8g
QXJlIHRoZSBpbnRlcnJ1cHRzIGluY3JlYXNpbmc/Cj4gRG9lcyBsc3BjaSBzaG93IGFueXRoaW5n
ICdkaXNhYmxlZCcgaW4gdGhlIGd1ZXN0PwoKWW91IGhhdmUgbWlzdW5kZXJzdG9vZCBtZS4gSSB3
YXMgdHJ5aW5nIHRvIGFjY2VzcyB0aGUgZHZiIHR1bmVycyBmcm9tIHRoZSBkb20wLgoKVXNpbmcg
a3ZtIEkgaGF2ZSBzdWNlc3NmdWxseSBwYXNzdGhyb3VnaCBhIHNhdGEgY29udHJvbGxlciwgYnV0
IGhhdmUgc29tZSBpc3N1ZXMKcGFzc2luIHRocm91Z2ggdGhlIGR2YiB0dW5lci4KCj4+IEkgd29u
ZGVyIHdoZXRoZXIgaXQgd291bGQgd29yayB3aXRoaW4gYSBEb21VIHdpdGggdGhlIFBDSWUgdHVu
ZXIKPj4gcGFzc2VkIHRocm91Z2guCj4KPiBJJ3ZlIGEgNCBjaGFubmVsIHNlY3VyaXR5IGNhcmQg
cGFzc2VkIGluIGFuZCBpdCB3b3JrcyBuaWNlbHkuIFRoZQo+IHRyaWNrIGlzIHRoYXQgeW91IG5l
ZWQgJ2lvbW11PXNvZnQnIG9uIHRoZSBkb21VIGNvbW1hbmQgbGluZS4KCkFsbCByaWdodC4gQnV0
IGlzIGl0IG5vcm1hbCB0aGF0IGl0IGRvZXMgbm90IHdvcmsgdW5kZXIgdGhlIGRvbTA/ClRoZSBz
YW1lIGtlcm5lbCBydW5uaW5nIG9uIGJhcmUgbWV0YWwgaGFzIG5vIHByb2JsZW1zLgoKCi0tIApK
YXZpZXIgTWFyY2V0IDxqbWFyY2V0QGdtYWlsLmNvbT4KCl9fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVs
QGxpc3RzLnhlbi5vcmcKaHR0cDovL2xpc3RzLnhlbi5vcmcveGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Sun Sep 16 14:58:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 16 Sep 2012 14:58:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDGI2-0003Oa-AD; Sun, 16 Sep 2012 14:57:42 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jmarcet@gmail.com>) id 1TDGI0-0003OV-Lw
	for xen-devel@lists.xen.org; Sun, 16 Sep 2012 14:57:40 +0000
Received: from [85.158.137.99:52852] by server-2.bemta-3.messagelabs.com id
	7A/DE-04862-3E8E5505; Sun, 16 Sep 2012 14:57:39 +0000
X-Env-Sender: jmarcet@gmail.com
X-Msg-Ref: server-13.tower-217.messagelabs.com!1347807457!17898030!1
X-Originating-IP: [209.85.210.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31972 invoked from network); 16 Sep 2012 14:57:38 -0000
Received: from mail-iy0-f173.google.com (HELO mail-iy0-f173.google.com)
	(209.85.210.173)
	by server-13.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Sep 2012 14:57:38 -0000
Received: by iakx26 with SMTP id x26so5861163iak.32
	for <xen-devel@lists.xen.org>; Sun, 16 Sep 2012 07:57: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:from:date:message-id:subject:to
	:cc:content-type:content-transfer-encoding;
	bh=tgYWBF53Mxh3bQh8/Zuf4NEVud2y0m8DlSBJ/gz1XWM=;
	b=KmAGT0y76LV6BhR1RKlodYvelifELHBeWOQELlGoAjKF2naf+M0MTUzsVz4bJnH4su
	X6esbv4+7VhtAYyAF9OchRVFELXWKnDUhOg1R+RIBvn04kp3n0tBUh5S++PTGJ78GaUA
	nuhAJMLDNnmrgKCB4erPCZkU/rjemW3JqB9oELnu05jCahrruDTO1hIfinVJxqgjOIlV
	4iAnwrcd2RwNiwjeUBiYIDK5ifjlOw1iUOpuPC9QPQI7bzeDSTx5u0BQPM/i19fae7cF
	+c26PeePm/MzCFfBSkk0cP81pfcgJs8EVicoyCrKQrkMRVpXE03nBi01ZRkc3Ly9HyNB
	jKmQ==
Received: by 10.50.195.233 with SMTP id ih9mr4336228igc.65.1347807457064; Sun,
	16 Sep 2012 07:57:37 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.64.14.212 with HTTP; Sun, 16 Sep 2012 07:57:16 -0700 (PDT)
In-Reply-To: <CACJDEmqdqA6CE9SgLL2QCNmQH1dOX0_4OHfJfzes+G6bEkQ7FA@mail.gmail.com>
References: <CAAnFQG9TZj=SxYK_jxqN=M6L40vL=AZu9EM2tbEffPhkL1s8FA@mail.gmail.com>
	<CACJDEmqdqA6CE9SgLL2QCNmQH1dOX0_4OHfJfzes+G6bEkQ7FA@mail.gmail.com>
From: Javier Marcet <jmarcet@gmail.com>
Date: Sun, 16 Sep 2012 16:57:16 +0200
Message-ID: <CAAnFQG-8Fkunv6R8+GCLAH4yQCx4-Nn0zN_Ntsf0wsh5yXeihQ@mail.gmail.com>
To: Konrad Rzeszutek Wilk <konrad@kernel.org>
Cc: Xen Devel Mailing list <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.2.0-rc4 issues with DVB tuner
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gRnJpLCBTZXAgMTQsIDIwMTIgYXQgMTA6NDcgUE0sIEtvbnJhZCBSemVzenV0ZWsgV2lsawo8
a29ucmFkQGtlcm5lbC5vcmc+IHdyb3RlOgoKPj4gVGhpcyBsYXN0IHBvaW50IGlzIGEgc2hvd3N0
b3BwZXIgZm9yIG1lIGFuZCBJIGRvbsK0dCBrbm93IHdoZXJlIHRoZQo+PiBwcm9ibGVtIG1pZ2h0
IGNvbWUgZnJvbS4gVGhlIGN4MjM4ODUgbW9kdWxlICh3aGljaCBteSB0dW5lcnMgdXNlKQo+PiBs
b2FkcyBmaW5lLCBhcyBkbyB0aGUgZGV2aWNlcyB1bmRlciAvZGV2L2R2Yi4gVXBvbiB0dW5pbmcg
YSBjaGFubmVsLAo+PiBob3dldmVyLCB0aGVyZSBpcyBub3QgZGF0YSByZWNlaXZlZC4KPj4KPj4g
RG9lcyBhbnlvbmUgaGF2ZSB0aGUgc2xpZ2h0ZXN0IGlkZWEgd2hhdCBtaWdodCBiZSBjYXVzaW5n
IHRoaXM/Cj4KPiBBcmUgdGhlcmUgYW55IHdhcm5pbmdzIG9yIHN1Y2ggYmVpbmcgcHJpbnRlZD8g
QXJlIHRoZSBpbnRlcnJ1cHRzIGluY3JlYXNpbmc/Cj4gRG9lcyBsc3BjaSBzaG93IGFueXRoaW5n
ICdkaXNhYmxlZCcgaW4gdGhlIGd1ZXN0PwoKWW91IGhhdmUgbWlzdW5kZXJzdG9vZCBtZS4gSSB3
YXMgdHJ5aW5nIHRvIGFjY2VzcyB0aGUgZHZiIHR1bmVycyBmcm9tIHRoZSBkb20wLgoKVXNpbmcg
a3ZtIEkgaGF2ZSBzdWNlc3NmdWxseSBwYXNzdGhyb3VnaCBhIHNhdGEgY29udHJvbGxlciwgYnV0
IGhhdmUgc29tZSBpc3N1ZXMKcGFzc2luIHRocm91Z2ggdGhlIGR2YiB0dW5lci4KCj4+IEkgd29u
ZGVyIHdoZXRoZXIgaXQgd291bGQgd29yayB3aXRoaW4gYSBEb21VIHdpdGggdGhlIFBDSWUgdHVu
ZXIKPj4gcGFzc2VkIHRocm91Z2guCj4KPiBJJ3ZlIGEgNCBjaGFubmVsIHNlY3VyaXR5IGNhcmQg
cGFzc2VkIGluIGFuZCBpdCB3b3JrcyBuaWNlbHkuIFRoZQo+IHRyaWNrIGlzIHRoYXQgeW91IG5l
ZWQgJ2lvbW11PXNvZnQnIG9uIHRoZSBkb21VIGNvbW1hbmQgbGluZS4KCkFsbCByaWdodC4gQnV0
IGlzIGl0IG5vcm1hbCB0aGF0IGl0IGRvZXMgbm90IHdvcmsgdW5kZXIgdGhlIGRvbTA/ClRoZSBz
YW1lIGtlcm5lbCBydW5uaW5nIG9uIGJhcmUgbWV0YWwgaGFzIG5vIHByb2JsZW1zLgoKCi0tIApK
YXZpZXIgTWFyY2V0IDxqbWFyY2V0QGdtYWlsLmNvbT4KCl9fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVs
QGxpc3RzLnhlbi5vcmcKaHR0cDovL2xpc3RzLnhlbi5vcmcveGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Sun Sep 16 14:59:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 16 Sep 2012 14: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 1TDGIu-0003Rm-Oh; Sun, 16 Sep 2012 14:58:36 +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 1TDGIs-0003Rb-MU
	for xen-devel@lists.xen.org; Sun, 16 Sep 2012 14:58:34 +0000
Received: from [85.158.137.99:59708] by server-8.bemta-3.messagelabs.com id
	49/62-24700-919E5505; Sun, 16 Sep 2012 14:58:33 +0000
X-Env-Sender: waldi@debian.org
X-Msg-Ref: server-8.tower-217.messagelabs.com!1347807512!12520212!1
X-Originating-IP: [82.139.201.20]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8359 invoked from network); 16 Sep 2012 14:58:33 -0000
Received: from wavehammer.waldi.eu.org (HELO wavehammer.waldi.eu.org)
	(82.139.201.20)
	by server-8.tower-217.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 16 Sep 2012 14:58:33 -0000
Received: by wavehammer.waldi.eu.org (Postfix, from userid 1000)
	id AFD005424E; Sun, 16 Sep 2012 16:58:30 +0200 (CEST)
Date: Sun, 16 Sep 2012 16:58:30 +0200
From: Bastian Blank <waldi@debian.org>
To: xen-devel@lists.xen.org
Message-ID: <20120916145830.GB22987@wavehammer.waldi.eu.org>
Mail-Followup-To: Bastian Blank <waldi@debian.org>, xen-devel@lists.xen.org
MIME-Version: 1.0
Content-Disposition: inline
User-Agent: Mutt/1.5.21 (2010-09-15)
Subject: [Xen-devel] Saving domain in xl does not have proper 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

Hi

Saving a domain without enough available space with xl in 4.2-rc5 fails
to cleanup completely. The domain informations remains in Xenstore,
the domain itself seems to remain in a suspended state and there is not
xl process for it anymore.

Reason is the use of the MUST macro in save_domain. It exits the process
prematurely instead of cleaning up the external visible changes.

Also the MUST macro is broken. exit() only takes "values & 0xff", so
this macro may exit the process with 0 if the error value is chosen
unwisely.

Bastian

-- 
A princess should not be afraid -- not with a brave knight to protect her.
		-- McCoy, "Shore Leave", stardate 3025.3

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Sep 16 14:59:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 16 Sep 2012 14: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 1TDGIu-0003Rm-Oh; Sun, 16 Sep 2012 14:58:36 +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 1TDGIs-0003Rb-MU
	for xen-devel@lists.xen.org; Sun, 16 Sep 2012 14:58:34 +0000
Received: from [85.158.137.99:59708] by server-8.bemta-3.messagelabs.com id
	49/62-24700-919E5505; Sun, 16 Sep 2012 14:58:33 +0000
X-Env-Sender: waldi@debian.org
X-Msg-Ref: server-8.tower-217.messagelabs.com!1347807512!12520212!1
X-Originating-IP: [82.139.201.20]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8359 invoked from network); 16 Sep 2012 14:58:33 -0000
Received: from wavehammer.waldi.eu.org (HELO wavehammer.waldi.eu.org)
	(82.139.201.20)
	by server-8.tower-217.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 16 Sep 2012 14:58:33 -0000
Received: by wavehammer.waldi.eu.org (Postfix, from userid 1000)
	id AFD005424E; Sun, 16 Sep 2012 16:58:30 +0200 (CEST)
Date: Sun, 16 Sep 2012 16:58:30 +0200
From: Bastian Blank <waldi@debian.org>
To: xen-devel@lists.xen.org
Message-ID: <20120916145830.GB22987@wavehammer.waldi.eu.org>
Mail-Followup-To: Bastian Blank <waldi@debian.org>, xen-devel@lists.xen.org
MIME-Version: 1.0
Content-Disposition: inline
User-Agent: Mutt/1.5.21 (2010-09-15)
Subject: [Xen-devel] Saving domain in xl does not have proper 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

Hi

Saving a domain without enough available space with xl in 4.2-rc5 fails
to cleanup completely. The domain informations remains in Xenstore,
the domain itself seems to remain in a suspended state and there is not
xl process for it anymore.

Reason is the use of the MUST macro in save_domain. It exits the process
prematurely instead of cleaning up the external visible changes.

Also the MUST macro is broken. exit() only takes "values & 0xff", so
this macro may exit the process with 0 if the error value is chosen
unwisely.

Bastian

-- 
A princess should not be afraid -- not with a brave knight to protect her.
		-- McCoy, "Shore Leave", stardate 3025.3

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Sep 16 15:37:24 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 16 Sep 2012 15:37: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 1TDGty-0004AU-Kv; Sun, 16 Sep 2012 15:36:54 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <waldi@debian.org>) id 1TDGtw-0004AN-PX
	for xen-devel@lists.xen.org; Sun, 16 Sep 2012 15:36:52 +0000
Received: from [85.158.139.83:57260] by server-8.bemta-5.messagelabs.com id
	3D/5F-15219-412F5505; Sun, 16 Sep 2012 15:36:52 +0000
X-Env-Sender: waldi@debian.org
X-Msg-Ref: server-16.tower-182.messagelabs.com!1347809810!23388802!1
X-Originating-IP: [82.139.201.20]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15326 invoked from network); 16 Sep 2012 15:36:51 -0000
Received: from wavehammer.waldi.eu.org (HELO wavehammer.waldi.eu.org)
	(82.139.201.20)
	by server-16.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 16 Sep 2012 15:36:51 -0000
Received: by wavehammer.waldi.eu.org (Postfix, from userid 1000)
	id D32615424E; Sun, 16 Sep 2012 17:36:49 +0200 (CEST)
Date: Sun, 16 Sep 2012 17:36:49 +0200
From: Bastian Blank <waldi@debian.org>
To: xen-devel@lists.xen.org
Message-ID: <20120916153649.GC22987@wavehammer.waldi.eu.org>
Mail-Followup-To: Bastian Blank <waldi@debian.org>, xen-devel@lists.xen.org
References: <20120916145830.GB22987@wavehammer.waldi.eu.org>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120916145830.GB22987@wavehammer.waldi.eu.org>
User-Agent: Mutt/1.5.21 (2010-09-15)
Subject: Re: [Xen-devel] Saving domain in xl does not have proper cleanup
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Sun, Sep 16, 2012 at 04:58:30PM +0200, Bastian Blank wrote:
> Saving a domain without enough available space with xl in 4.2-rc5 fails
> to cleanup completely. The domain informations remains in Xenstore,
> the domain itself seems to remain in a suspended state and there is not
> xl process for it anymore.

This patch fixes this bug. It resumes the domain in case of errors in
the save process.

Bastian

Signed-off-by: Bastian Blank <waldi@debian.org>

diff -r 4027d31caeb0 tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Thu Sep 13 12:21:09 2012 +0100
+++ b/tools/libxl/xl_cmdimpl.c	Sun Sep 16 17:33:25 2012 +0200
@@ -2990,15 +2990,18 @@
 
     save_domain_core_writeconfig(fd, filename, config_data, config_len);
 
-    MUST(libxl_domain_suspend(ctx, domid, fd, 0, NULL));
+    int rc = libxl_domain_suspend(ctx, domid, fd, 0, NULL);
     close(fd);
 
-    if (checkpoint)
+    if (rc < 0)
+        fprintf(stderr, "Failed to save domain, resuming domain\n");
+
+    if (checkpoint || rc < 0)
         libxl_domain_resume(ctx, domid, 1, 0);
     else
         libxl_domain_destroy(ctx, domid, 0);
 
-    exit(0);
+    exit(rc < 0 ? 1 : 0);
 }
 
 static pid_t create_migration_child(const char *rune, int *send_fd,
-- 
There are certain things men must do to remain men.
		-- Kirk, "The Ultimate Computer", stardate 4929.4

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Sep 16 15:37:24 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 16 Sep 2012 15:37: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 1TDGty-0004AU-Kv; Sun, 16 Sep 2012 15:36:54 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <waldi@debian.org>) id 1TDGtw-0004AN-PX
	for xen-devel@lists.xen.org; Sun, 16 Sep 2012 15:36:52 +0000
Received: from [85.158.139.83:57260] by server-8.bemta-5.messagelabs.com id
	3D/5F-15219-412F5505; Sun, 16 Sep 2012 15:36:52 +0000
X-Env-Sender: waldi@debian.org
X-Msg-Ref: server-16.tower-182.messagelabs.com!1347809810!23388802!1
X-Originating-IP: [82.139.201.20]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15326 invoked from network); 16 Sep 2012 15:36:51 -0000
Received: from wavehammer.waldi.eu.org (HELO wavehammer.waldi.eu.org)
	(82.139.201.20)
	by server-16.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 16 Sep 2012 15:36:51 -0000
Received: by wavehammer.waldi.eu.org (Postfix, from userid 1000)
	id D32615424E; Sun, 16 Sep 2012 17:36:49 +0200 (CEST)
Date: Sun, 16 Sep 2012 17:36:49 +0200
From: Bastian Blank <waldi@debian.org>
To: xen-devel@lists.xen.org
Message-ID: <20120916153649.GC22987@wavehammer.waldi.eu.org>
Mail-Followup-To: Bastian Blank <waldi@debian.org>, xen-devel@lists.xen.org
References: <20120916145830.GB22987@wavehammer.waldi.eu.org>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120916145830.GB22987@wavehammer.waldi.eu.org>
User-Agent: Mutt/1.5.21 (2010-09-15)
Subject: Re: [Xen-devel] Saving domain in xl does not have proper cleanup
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Sun, Sep 16, 2012 at 04:58:30PM +0200, Bastian Blank wrote:
> Saving a domain without enough available space with xl in 4.2-rc5 fails
> to cleanup completely. The domain informations remains in Xenstore,
> the domain itself seems to remain in a suspended state and there is not
> xl process for it anymore.

This patch fixes this bug. It resumes the domain in case of errors in
the save process.

Bastian

Signed-off-by: Bastian Blank <waldi@debian.org>

diff -r 4027d31caeb0 tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Thu Sep 13 12:21:09 2012 +0100
+++ b/tools/libxl/xl_cmdimpl.c	Sun Sep 16 17:33:25 2012 +0200
@@ -2990,15 +2990,18 @@
 
     save_domain_core_writeconfig(fd, filename, config_data, config_len);
 
-    MUST(libxl_domain_suspend(ctx, domid, fd, 0, NULL));
+    int rc = libxl_domain_suspend(ctx, domid, fd, 0, NULL);
     close(fd);
 
-    if (checkpoint)
+    if (rc < 0)
+        fprintf(stderr, "Failed to save domain, resuming domain\n");
+
+    if (checkpoint || rc < 0)
         libxl_domain_resume(ctx, domid, 1, 0);
     else
         libxl_domain_destroy(ctx, domid, 0);
 
-    exit(0);
+    exit(rc < 0 ? 1 : 0);
 }
 
 static pid_t create_migration_child(const char *rune, int *send_fd,
-- 
There are certain things men must do to remain men.
		-- Kirk, "The Ultimate Computer", stardate 4929.4

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Sep 16 15:52:50 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 16 Sep 2012 15:52: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 1TDH90-0004Ob-66; Sun, 16 Sep 2012 15:52:26 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <navinjpatel336@gmail.com>) id 1TDH8y-0004OW-TF
	for xen-devel@lists.xen.org; Sun, 16 Sep 2012 15:52:25 +0000
Received: from [85.158.139.211:46278] by server-10.bemta-5.messagelabs.com id
	17/0C-10969-7B5F5505; Sun, 16 Sep 2012 15:52:23 +0000
X-Env-Sender: navinjpatel336@gmail.com
X-Msg-Ref: server-4.tower-206.messagelabs.com!1347810741!18777645!1
X-Originating-IP: [209.85.219.45]
X-SpamReason: No, hits=1.5 required=7.0 tests=HTML_00_10,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9910 invoked from network); 16 Sep 2012 15:52:22 -0000
Received: from mail-oa0-f45.google.com (HELO mail-oa0-f45.google.com)
	(209.85.219.45)
	by server-4.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Sep 2012 15:52:22 -0000
Received: by oagn12 with SMTP id n12so5087321oag.32
	for <xen-devel@lists.xen.org>; Sun, 16 Sep 2012 08:52:21 -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=i8LNboIQPVgP5MmMEsCPHgDT+lVVTXOaCGoTT2gHkGQ=;
	b=r4js0VeSjJipDuhRs7CXCsqfE6wH1MKPIh8YUqBi3UckFlOH9+xHKlSUAybO4/TNct
	vyO7XWYZ9Yo33UQBzbnQ+lb3+npWtF9hi+h0WcP2Hx2U1ZYvpzrAE7deV4vutolDno7a
	0SxPja92FN90QzGocaSJkD8454l3U+tmlJugyzgJIyTbOg5B1lDjPWsd9SGbv71gk7N0
	zHa3rr3o5hbo0wfVotix0MfiyN3u+dfJiAHGRROaLbUY25mspxy0XCYbcNil/5h23dRH
	g5nTrypAZEUEyyU1qmqizUqtSBtIpWGz3cMkJ2qA6nilCTmOnsXfI9GgzPAW0Mf1uviz
	Tr4w==
MIME-Version: 1.0
Received: by 10.60.28.162 with SMTP id c2mr9645823oeh.3.1347810741133; Sun, 16
	Sep 2012 08:52:21 -0700 (PDT)
Received: by 10.76.117.73 with HTTP; Sun, 16 Sep 2012 08:52:21 -0700 (PDT)
Date: Sun, 16 Sep 2012 11:52:21 -0400
Message-ID: <CALEYbrhEoSEcXGpCkYqEz9K7Fgz7KLK_G2+Oz-FCc00Egr9RAg@mail.gmail.com>
From: Navin Patel <navinjpatel336@gmail.com>
To: xen-devel@lists.xen.org
Subject: [Xen-devel] 4.2.0-rc4 bug: memory events for CR3 register are
	broken (working in 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: multipart/mixed; boundary="===============4869742676339831031=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============4869742676339831031==
Content-Type: multipart/alternative; boundary=e89a8ff1c76273235204c9d3a45c

--e89a8ff1c76273235204c9d3a45c
Content-Type: text/plain; charset=ISO-8859-1

Greetings,

I have tested some of my research code watching for CR3 memory events on
Xen 4.2.0-rc4, and I have discovered that CR3 events are not being
delivered.  This did work properly in 4.1.3, so I think 4.2.0-rc4 may has a
bug.

 This feature has been removed maybe?

Crude test  to confirm this can be had by changing
tools/tests/xen-access/xen-access.c : replace HVM_PARAM_MEMORY_EVENT_INT3
with HVM_PARAM_MEMORY_EVENT_CR3 and rebuild (line 569 and 571 in 4.2.0-rc4).

Then (while domU is scheduling programs/launching new processes) run like
int3 were still the constant value: ./xen-access $DOMID int3

4.1.3: In the switch/case, printf will show "UNKNOWN REASON CODE $C", with
c == 3 == MEM_EVENT_REASON_CR3 (no case built to detect CR3 evnets).

4.2.0-rc4: In the switch/case, printf will never show "UNKNOWN REASON CODE
3"

Cheers,
Navin

--e89a8ff1c76273235204c9d3a45c
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Greetings,<br><br>I have tested some of my research code watching for CR3 m=
emory events on Xen 4.2.0-rc4, and I have discovered that CR3 events are no=
t being delivered.=A0 This did work properly in 4.1.3, so I think 4.2.0-rc4=
 may has a bug.<br>
<br>=A0This feature has been removed maybe?<br><br>Crude test=A0 to confirm=
 this can be had by changing tools/tests/xen-access/xen-access.c : replace =
HVM_PARAM_MEMORY_EVENT_INT3 with HVM_PARAM_MEMORY_EVENT_CR3 and rebuild (li=
ne 569 and 571 in 4.2.0-rc4).<br>
<br>Then (while domU is scheduling programs/launching new processes) run li=
ke int3 were still the constant value: ./xen-access $DOMID int3<br><br>4.1.=
3: In the switch/case, printf will show &quot;UNKNOWN REASON CODE $C&quot;,=
=20
with c =3D=3D 3 =3D=3D MEM_EVENT_REASON_CR3 (no case built to detect CR3=20
evnets).<br><br>4.2.0-rc4: In the switch/case, printf will never show &quot=
;UNKNOWN REASON CODE 3&quot;<br><br>Cheers,<br>Navin<br>

--e89a8ff1c76273235204c9d3a45c--


--===============4869742676339831031==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============4869742676339831031==--


From xen-devel-bounces@lists.xen.org Sun Sep 16 15:52:50 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 16 Sep 2012 15:52: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 1TDH90-0004Ob-66; Sun, 16 Sep 2012 15:52:26 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <navinjpatel336@gmail.com>) id 1TDH8y-0004OW-TF
	for xen-devel@lists.xen.org; Sun, 16 Sep 2012 15:52:25 +0000
Received: from [85.158.139.211:46278] by server-10.bemta-5.messagelabs.com id
	17/0C-10969-7B5F5505; Sun, 16 Sep 2012 15:52:23 +0000
X-Env-Sender: navinjpatel336@gmail.com
X-Msg-Ref: server-4.tower-206.messagelabs.com!1347810741!18777645!1
X-Originating-IP: [209.85.219.45]
X-SpamReason: No, hits=1.5 required=7.0 tests=HTML_00_10,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9910 invoked from network); 16 Sep 2012 15:52:22 -0000
Received: from mail-oa0-f45.google.com (HELO mail-oa0-f45.google.com)
	(209.85.219.45)
	by server-4.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Sep 2012 15:52:22 -0000
Received: by oagn12 with SMTP id n12so5087321oag.32
	for <xen-devel@lists.xen.org>; Sun, 16 Sep 2012 08:52:21 -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=i8LNboIQPVgP5MmMEsCPHgDT+lVVTXOaCGoTT2gHkGQ=;
	b=r4js0VeSjJipDuhRs7CXCsqfE6wH1MKPIh8YUqBi3UckFlOH9+xHKlSUAybO4/TNct
	vyO7XWYZ9Yo33UQBzbnQ+lb3+npWtF9hi+h0WcP2Hx2U1ZYvpzrAE7deV4vutolDno7a
	0SxPja92FN90QzGocaSJkD8454l3U+tmlJugyzgJIyTbOg5B1lDjPWsd9SGbv71gk7N0
	zHa3rr3o5hbo0wfVotix0MfiyN3u+dfJiAHGRROaLbUY25mspxy0XCYbcNil/5h23dRH
	g5nTrypAZEUEyyU1qmqizUqtSBtIpWGz3cMkJ2qA6nilCTmOnsXfI9GgzPAW0Mf1uviz
	Tr4w==
MIME-Version: 1.0
Received: by 10.60.28.162 with SMTP id c2mr9645823oeh.3.1347810741133; Sun, 16
	Sep 2012 08:52:21 -0700 (PDT)
Received: by 10.76.117.73 with HTTP; Sun, 16 Sep 2012 08:52:21 -0700 (PDT)
Date: Sun, 16 Sep 2012 11:52:21 -0400
Message-ID: <CALEYbrhEoSEcXGpCkYqEz9K7Fgz7KLK_G2+Oz-FCc00Egr9RAg@mail.gmail.com>
From: Navin Patel <navinjpatel336@gmail.com>
To: xen-devel@lists.xen.org
Subject: [Xen-devel] 4.2.0-rc4 bug: memory events for CR3 register are
	broken (working in 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: multipart/mixed; boundary="===============4869742676339831031=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============4869742676339831031==
Content-Type: multipart/alternative; boundary=e89a8ff1c76273235204c9d3a45c

--e89a8ff1c76273235204c9d3a45c
Content-Type: text/plain; charset=ISO-8859-1

Greetings,

I have tested some of my research code watching for CR3 memory events on
Xen 4.2.0-rc4, and I have discovered that CR3 events are not being
delivered.  This did work properly in 4.1.3, so I think 4.2.0-rc4 may has a
bug.

 This feature has been removed maybe?

Crude test  to confirm this can be had by changing
tools/tests/xen-access/xen-access.c : replace HVM_PARAM_MEMORY_EVENT_INT3
with HVM_PARAM_MEMORY_EVENT_CR3 and rebuild (line 569 and 571 in 4.2.0-rc4).

Then (while domU is scheduling programs/launching new processes) run like
int3 were still the constant value: ./xen-access $DOMID int3

4.1.3: In the switch/case, printf will show "UNKNOWN REASON CODE $C", with
c == 3 == MEM_EVENT_REASON_CR3 (no case built to detect CR3 evnets).

4.2.0-rc4: In the switch/case, printf will never show "UNKNOWN REASON CODE
3"

Cheers,
Navin

--e89a8ff1c76273235204c9d3a45c
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Greetings,<br><br>I have tested some of my research code watching for CR3 m=
emory events on Xen 4.2.0-rc4, and I have discovered that CR3 events are no=
t being delivered.=A0 This did work properly in 4.1.3, so I think 4.2.0-rc4=
 may has a bug.<br>
<br>=A0This feature has been removed maybe?<br><br>Crude test=A0 to confirm=
 this can be had by changing tools/tests/xen-access/xen-access.c : replace =
HVM_PARAM_MEMORY_EVENT_INT3 with HVM_PARAM_MEMORY_EVENT_CR3 and rebuild (li=
ne 569 and 571 in 4.2.0-rc4).<br>
<br>Then (while domU is scheduling programs/launching new processes) run li=
ke int3 were still the constant value: ./xen-access $DOMID int3<br><br>4.1.=
3: In the switch/case, printf will show &quot;UNKNOWN REASON CODE $C&quot;,=
=20
with c =3D=3D 3 =3D=3D MEM_EVENT_REASON_CR3 (no case built to detect CR3=20
evnets).<br><br>4.2.0-rc4: In the switch/case, printf will never show &quot=
;UNKNOWN REASON CODE 3&quot;<br><br>Cheers,<br>Navin<br>

--e89a8ff1c76273235204c9d3a45c--


--===============4869742676339831031==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============4869742676339831031==--


From xen-devel-bounces@lists.xen.org Sun Sep 16 16:02:00 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 16 Sep 2012 16:02:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDHHr-0004x9-7K; Sun, 16 Sep 2012 16:01: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 1TDHHp-0004x4-Mb
	for xen-devel@lists.xensource.com; Sun, 16 Sep 2012 16:01:33 +0000
Received: from [85.158.139.211:42117] by server-11.bemta-5.messagelabs.com id
	30/42-24658-CD7F5505; Sun, 16 Sep 2012 16:01:32 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-206.messagelabs.com!1347811292!17247775!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDk2MzE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14561 invoked from network); 16 Sep 2012 16:01:32 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Sep 2012 16:01:32 -0000
X-IronPort-AV: E=Sophos;i="4.80,431,1344211200"; d="scan'208";a="14566089"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Sep 2012 16:01: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.279.1; Sun, 16 Sep 2012 17:01:31 +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 1TDHHn-0001fh-EC;
	Sun, 16 Sep 2012 16:01:31 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1TDHHn-0005VL-1t;
	Sun, 16 Sep 2012 17:01:31 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-13785-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sun, 16 Sep 2012 17:01:31 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-linus test] 13785: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 13785 linux-linus real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13785/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-credit2    5 xen-boot                  fail REGR. vs. 12557
 test-amd64-i386-xl-multivcpu  5 xen-boot                  fail REGR. vs. 12557

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-pv           5 xen-boot                    fail pass in 13775
 test-amd64-amd64-xl-winxpsp3  7 windows-install             fail pass in 13775
 test-amd64-amd64-xl-sedf-pin 14 guest-localmigrate/x10 fail in 13775 pass in 13785

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-pv            5 xen-boot                     fail   like 12557

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  5 xen-boot                    fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  5 xen-boot               fail never pass
 test-amd64-i386-rhel6hvm-intel  5 xen-boot                     fail never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop            fail in 13775 never pass

version targeted for testing:
 linux                3f0c3c8fe30c725c1264fb6db8cc4b69db3a658a
baseline version:
 linux                c16fa4f2ad19908a47c63d8fa436a1178438c7e7

------------------------------------------------------------
People who touched revisions under test:
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           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                                   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-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          fail    
 test-amd64-i386-pv                                           fail    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-amd64-amd64-xl-win                                      fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
commit 3f0c3c8fe30c725c1264fb6db8cc4b69db3a658a
Merge: 9cb0ee8... 62e252e...
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date:   Fri Sep 14 18:05:14 2012 -0700

    Merge git://git.kernel.org/pub/scm/linux/kernel/git/steve/gfs2-3.0-fixes
    
    Pull GFS2 fixes from Steven Whitehouse:
     "Here are three GFS2 fixes for the current kernel tree.  These are all
      related to the block reservation code which was added at the merge
      window.  That code will be getting an update at the forthcoming merge
      window too.  In the mean time though there are a few smaller issues
      which should be fixed.
    
      The first patch resolves an issue with write sizes of greater than 32
      bits with the size hinting code.  The second ensures that the
      allocation data structure is initialised when using xattrs and the
      third takes into account allocations which may have been made by other
      nodes which affect a reservation on the local node."
    
    * git://git.kernel.org/pub/scm/linux/kernel/git/steve/gfs2-3.0-fixes:
      GFS2: Take account of blockages when using reserved blocks
      GFS2: Fix missing allocation data for set/remove xattr
      GFS2: Make write size hinting code common

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Sep 16 16:02:00 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 16 Sep 2012 16:02:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDHHr-0004x9-7K; Sun, 16 Sep 2012 16:01: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 1TDHHp-0004x4-Mb
	for xen-devel@lists.xensource.com; Sun, 16 Sep 2012 16:01:33 +0000
Received: from [85.158.139.211:42117] by server-11.bemta-5.messagelabs.com id
	30/42-24658-CD7F5505; Sun, 16 Sep 2012 16:01:32 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-206.messagelabs.com!1347811292!17247775!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDk2MzE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14561 invoked from network); 16 Sep 2012 16:01:32 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Sep 2012 16:01:32 -0000
X-IronPort-AV: E=Sophos;i="4.80,431,1344211200"; d="scan'208";a="14566089"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Sep 2012 16:01: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.279.1; Sun, 16 Sep 2012 17:01:31 +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 1TDHHn-0001fh-EC;
	Sun, 16 Sep 2012 16:01:31 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1TDHHn-0005VL-1t;
	Sun, 16 Sep 2012 17:01:31 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-13785-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sun, 16 Sep 2012 17:01:31 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-linus test] 13785: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 13785 linux-linus real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13785/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-credit2    5 xen-boot                  fail REGR. vs. 12557
 test-amd64-i386-xl-multivcpu  5 xen-boot                  fail REGR. vs. 12557

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-pv           5 xen-boot                    fail pass in 13775
 test-amd64-amd64-xl-winxpsp3  7 windows-install             fail pass in 13775
 test-amd64-amd64-xl-sedf-pin 14 guest-localmigrate/x10 fail in 13775 pass in 13785

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-pv            5 xen-boot                     fail   like 12557

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  5 xen-boot                    fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel  5 xen-boot               fail never pass
 test-amd64-i386-rhel6hvm-intel  5 xen-boot                     fail never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop            fail in 13775 never pass

version targeted for testing:
 linux                3f0c3c8fe30c725c1264fb6db8cc4b69db3a658a
baseline version:
 linux                c16fa4f2ad19908a47c63d8fa436a1178438c7e7

------------------------------------------------------------
People who touched revisions under test:
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           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                                   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-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          fail    
 test-amd64-i386-pv                                           fail    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-amd64-amd64-xl-win                                      fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
commit 3f0c3c8fe30c725c1264fb6db8cc4b69db3a658a
Merge: 9cb0ee8... 62e252e...
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date:   Fri Sep 14 18:05:14 2012 -0700

    Merge git://git.kernel.org/pub/scm/linux/kernel/git/steve/gfs2-3.0-fixes
    
    Pull GFS2 fixes from Steven Whitehouse:
     "Here are three GFS2 fixes for the current kernel tree.  These are all
      related to the block reservation code which was added at the merge
      window.  That code will be getting an update at the forthcoming merge
      window too.  In the mean time though there are a few smaller issues
      which should be fixed.
    
      The first patch resolves an issue with write sizes of greater than 32
      bits with the size hinting code.  The second ensures that the
      allocation data structure is initialised when using xattrs and the
      third takes into account allocations which may have been made by other
      nodes which affect a reservation on the local node."
    
    * git://git.kernel.org/pub/scm/linux/kernel/git/steve/gfs2-3.0-fixes:
      GFS2: Take account of blockages when using reserved blocks
      GFS2: Fix missing allocation data for set/remove xattr
      GFS2: Make write size hinting code common

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Sep 16 16:03:33 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 16 Sep 2012 16: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 1TDHJS-00053m-Nm; Sun, 16 Sep 2012 16:03:14 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <alan@lxorguk.ukuu.org.uk>) id 1TDHJR-00053Q-LF
	for xen-devel@lists.xen.org; Sun, 16 Sep 2012 16:03:13 +0000
X-Env-Sender: alan@lxorguk.ukuu.org.uk
X-Msg-Ref: server-5.tower-27.messagelabs.com!1347811384!7815285!1
X-Originating-IP: [81.2.110.251]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 511 invoked from network); 16 Sep 2012 16:03:04 -0000
Received: from lxorguk.ukuu.org.uk (HELO lxorguk.ukuu.org.uk) (81.2.110.251)
	by server-5.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 16 Sep 2012 16:03:04 -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 q8GGZGhb019756;
	Sun, 16 Sep 2012 17:35:22 +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 q8GG7ciK013536;
	Sun, 16 Sep 2012 17:07:38 +0100
Date: Sun, 16 Sep 2012 17:07:37 +0100
From: Alan Cox <alan@lxorguk.ukuu.org.uk>
To: James Harper <james.harper@bendigoit.com.au>
Message-ID: <20120916170737.3c8f7e9e@pyramind.ukuu.org.uk>
In-Reply-To: <6035A0D088A63A46850C3988ED045A4B29B980EB@BITCOM1.int.sbss.com.au>
References: <CAOzFzEiZopdFQuZkUcSWWre9b=NeZpJM9n2VtEoZcRo=ejYQPA@mail.gmail.com>
	<CC7B4CE4.3EE74%keir.xen@gmail.com>
	<20120916122704.4ea05b45@pyramind.ukuu.org.uk>
	<6035A0D088A63A46850C3988ED045A4B29B980EB@BITCOM1.int.sbss.com.au>
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: Joseph Glanville <joseph.glanville@orionvm.com.au>,
	Keir Fraser <keir.xen@gmail.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] bug when using 4K sectors?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 knowing the block size isn't the whole story.
> > 
> 
> Are you saying that Xen and/or Linux needs to worry about a user setting up a poorly aligned filesystem to pass to a VM? Seems simpler just to set things up right in the first place.

That assumes things like a file system and the existing layout being
correct. Plus you also have to set the thing up which means you have to
know about such stuff.

For file systems Linux itself does indeed take the approach of "so
partition sensibly" because in the fs case it's really hard if not
impossible to do a good job any other way.

For raw devices and things like databases wanting atomicity of block
writes however its quite different and you need to be aware of the
alignments.

Alan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Sep 16 16:03:33 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 16 Sep 2012 16: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 1TDHJS-00053m-Nm; Sun, 16 Sep 2012 16:03:14 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <alan@lxorguk.ukuu.org.uk>) id 1TDHJR-00053Q-LF
	for xen-devel@lists.xen.org; Sun, 16 Sep 2012 16:03:13 +0000
X-Env-Sender: alan@lxorguk.ukuu.org.uk
X-Msg-Ref: server-5.tower-27.messagelabs.com!1347811384!7815285!1
X-Originating-IP: [81.2.110.251]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 511 invoked from network); 16 Sep 2012 16:03:04 -0000
Received: from lxorguk.ukuu.org.uk (HELO lxorguk.ukuu.org.uk) (81.2.110.251)
	by server-5.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 16 Sep 2012 16:03:04 -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 q8GGZGhb019756;
	Sun, 16 Sep 2012 17:35:22 +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 q8GG7ciK013536;
	Sun, 16 Sep 2012 17:07:38 +0100
Date: Sun, 16 Sep 2012 17:07:37 +0100
From: Alan Cox <alan@lxorguk.ukuu.org.uk>
To: James Harper <james.harper@bendigoit.com.au>
Message-ID: <20120916170737.3c8f7e9e@pyramind.ukuu.org.uk>
In-Reply-To: <6035A0D088A63A46850C3988ED045A4B29B980EB@BITCOM1.int.sbss.com.au>
References: <CAOzFzEiZopdFQuZkUcSWWre9b=NeZpJM9n2VtEoZcRo=ejYQPA@mail.gmail.com>
	<CC7B4CE4.3EE74%keir.xen@gmail.com>
	<20120916122704.4ea05b45@pyramind.ukuu.org.uk>
	<6035A0D088A63A46850C3988ED045A4B29B980EB@BITCOM1.int.sbss.com.au>
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: Joseph Glanville <joseph.glanville@orionvm.com.au>,
	Keir Fraser <keir.xen@gmail.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] bug when using 4K sectors?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 knowing the block size isn't the whole story.
> > 
> 
> Are you saying that Xen and/or Linux needs to worry about a user setting up a poorly aligned filesystem to pass to a VM? Seems simpler just to set things up right in the first place.

That assumes things like a file system and the existing layout being
correct. Plus you also have to set the thing up which means you have to
know about such stuff.

For file systems Linux itself does indeed take the approach of "so
partition sensibly" because in the fs case it's really hard if not
impossible to do a good job any other way.

For raw devices and things like databases wanting atomicity of block
writes however its quite different and you need to be aware of the
alignments.

Alan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Sep 16 16:35:39 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 16 Sep 2012 16:35:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDHoQ-0005M8-DP; Sun, 16 Sep 2012 16:35: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 1TDHoO-0005M3-MM
	for xen-devel@lists.xen.org; Sun, 16 Sep 2012 16:35:12 +0000
Received: from [85.158.143.35:23939] by server-3.bemta-4.messagelabs.com id
	A1/1D-08232-FBFF5505; Sun, 16 Sep 2012 16:35:11 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1347813309!10384871!1
X-Originating-IP: [74.125.82.173]
X-SpamReason: No, hits=0.9 required=7.0 tests=HTML_30_40,HTML_MESSAGE,
	MAILTO_TO_SPAM_ADDR, MIME_QP_LONG_LINE, ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP, spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12781 invoked from network); 16 Sep 2012 16:35:09 -0000
Received: from mail-we0-f173.google.com (HELO mail-we0-f173.google.com)
	(74.125.82.173)
	by server-10.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Sep 2012 16:35:09 -0000
Received: by weyz53 with SMTP id z53so4050392wey.32
	for <xen-devel@lists.xen.org>; Sun, 16 Sep 2012 09:35:09 -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;
	bh=Wbrv6op/myy71TtcvExkHHIUXgFZOdz5/T8uxpArRmQ=;
	b=rIleqchKoX6EbNEY5hQyVNpcaf6J013eKDHNzFAt1FqGnzdoxRW2EZxrfZG5jVhO1m
	YmKVUSSRSIHTVYV5MUFN28Qmpa21dhjCE6dXr03SZxYZLrGubr1V0fcaxlVamSh45z2h
	zojKpdsutMkk+YRUzw9LsC8MxByZsc8mruVClYRHzzxLFp+dXoOzv31sB2Uu/MS6CgXy
	v0k125rPlKwkWUhgJw8E/AdBGvC8Vc4FX7eF4juHKTdaDrfW0v8MqfFeBW6X7/t50AlV
	FVbtewjm1T1VOtBhruc3RqHDA8aVLm/z5Bjsn8vvdCZuLToFgio7r6BeRNJ/EsiGZzFm
	eHxA==
Received: by 10.180.14.74 with SMTP id n10mr10627959wic.17.1347813309001;
	Sun, 16 Sep 2012 09:35:09 -0700 (PDT)
Received: from [192.168.1.69] (host86-183-251-65.range86-183.btcentralplus.com.
	[86.183.251.65])
	by mx.google.com with ESMTPS id cu1sm12773161wib.6.2012.09.16.09.35.06
	(version=SSLv3 cipher=OTHER); Sun, 16 Sep 2012 09:35:08 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Sun, 16 Sep 2012 17:35:02 +0100
From: Keir Fraser <keir.xen@gmail.com>
To: Navin Patel <navinjpatel336@gmail.com>,
	<xen-devel@lists.xen.org>
Message-ID: <CC7BBE46.3EE9C%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] 4.2.0-rc4 bug: memory events for CR3 register are
	broken (working in 4.1.3)
Thread-Index: Ac2UKTgiuzIeLUHbCECcraVtXYR+wg==
In-Reply-To: <CALEYbrhEoSEcXGpCkYqEz9K7Fgz7KLK_G2+Oz-FCc00Egr9RAg@mail.gmail.com>
Mime-version: 1.0
Cc: Steven Maresca <steve@zentific.com>
Subject: Re: [Xen-devel] 4.2.0-rc4 bug: memory events for CR3 register are
 broken (working in 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: multipart/mixed; boundary="===============7191763664289788255=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--===============7191763664289788255==
Content-type: multipart/alternative;
	boundary="B_3430661707_60064861"

> This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--B_3430661707_60064861
Content-type: text/plain;
	charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable

This issue is known and a fix has been proposed. It=B9s too late for 4.2.0
unfortunately, but will be fixed for 4.2.1.

 -- Keir

On 16/09/2012 16:52, "Navin Patel" <navinjpatel336@gmail.com> wrote:

> Greetings,
>=20
> I have tested some of my research code watching for CR3 memory events on =
Xen
> 4.2.0-rc4, and I have discovered that CR3 events are not being delivered.=
=A0
> This did work properly in 4.1.3, so I think 4.2.0-rc4 may has a bug.
>=20
> =A0This feature has been removed maybe?
>=20
> Crude test=A0 to confirm this can be had by changing
> tools/tests/xen-access/xen-access.c : replace HVM_PARAM_MEMORY_EVENT_INT3=
 with
> HVM_PARAM_MEMORY_EVENT_CR3 and rebuild (line 569 and 571 in 4.2.0-rc4).
>=20
> Then (while domU is scheduling programs/launching new processes) run like=
 int3
> were still the constant value: ./xen-access $DOMID int3
>=20
> 4.1.3: In the switch/case, printf will show "UNKNOWN REASON CODE $C", wit=
h c
> =3D=3D 3 =3D=3D MEM_EVENT_REASON_CR3 (no case built to detect CR3 evnets).
>=20
> 4.2.0-rc4: In the switch/case, printf will never show "UNKNOWN REASON COD=
E 3"
>=20
> Cheers,
> Navin
>=20
>=20
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel


--B_3430661707_60064861
Content-type: text/html;
	charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable

<HTML>
<HEAD>
<TITLE>Re: [Xen-devel] 4.2.0-rc4 bug: memory events for CR3 register are br=
oken (working in 4.1.3)</TITLE>
</HEAD>
<BODY>
<FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN STYLE=3D'font-size:11pt=
'>This issue is known and a fix has been proposed. It&#8217;s too late for 4=
.2.0 unfortunately, but will be fixed for 4.2.1.<BR>
<BR>
&nbsp;-- Keir<BR>
<BR>
On 16/09/2012 16:52, &quot;Navin Patel&quot; &lt;<a href=3D"navinjpatel336@gm=
ail.com">navinjpatel336@gmail.com</a>&gt; wrote:<BR>
<BR>
</SPAN></FONT><BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><=
SPAN STYLE=3D'font-size:11pt'>Greetings,<BR>
<BR>
I have tested some of my research code watching for CR3 memory events on Xe=
n 4.2.0-rc4, and I have discovered that CR3 events are not being delivered.=A0=
 This did work properly in 4.1.3, so I think 4.2.0-rc4 may has a bug.<BR>
<BR>
=A0This feature has been removed maybe?<BR>
<BR>
Crude test=A0 to confirm this can be had by changing tools/tests/xen-access/x=
en-access.c : replace HVM_PARAM_MEMORY_EVENT_INT3 with HVM_PARAM_MEMORY_EVEN=
T_CR3 and rebuild (line 569 and 571 in 4.2.0-rc4).<BR>
<BR>
Then (while domU is scheduling programs/launching new processes) run like i=
nt3 were still the constant value: ./xen-access $DOMID int3<BR>
<BR>
4.1.3: In the switch/case, printf will show &quot;UNKNOWN REASON CODE $C&qu=
ot;, with c =3D=3D 3 =3D=3D MEM_EVENT_REASON_CR3 (no case built to detect CR3 evnets=
).<BR>
<BR>
4.2.0-rc4: In the switch/case, printf will never show &quot;UNKNOWN REASON =
CODE 3&quot;<BR>
<BR>
Cheers,<BR>
Navin<BR>
<BR>
<HR ALIGN=3DCENTER SIZE=3D"3" WIDTH=3D"95%"></SPAN></FONT><FONT SIZE=3D"2"><FONT FA=
CE=3D"Consolas, Courier New, Courier"><SPAN STYLE=3D'font-size:10pt'>___________=
____________________________________<BR>
Xen-devel mailing list<BR>
<a href=3D"Xen-devel@lists.xen.org">Xen-devel@lists.xen.org</a><BR>
<a href=3D"http://lists.xen.org/xen-devel">http://lists.xen.org/xen-devel</a>=
<BR>
</SPAN></FONT></FONT></BLOCKQUOTE>
</BODY>
</HTML>


--B_3430661707_60064861--




--===============7191763664289788255==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============7191763664289788255==--




From xen-devel-bounces@lists.xen.org Sun Sep 16 16:35:39 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 16 Sep 2012 16:35:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDHoQ-0005M8-DP; Sun, 16 Sep 2012 16:35: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 1TDHoO-0005M3-MM
	for xen-devel@lists.xen.org; Sun, 16 Sep 2012 16:35:12 +0000
Received: from [85.158.143.35:23939] by server-3.bemta-4.messagelabs.com id
	A1/1D-08232-FBFF5505; Sun, 16 Sep 2012 16:35:11 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1347813309!10384871!1
X-Originating-IP: [74.125.82.173]
X-SpamReason: No, hits=0.9 required=7.0 tests=HTML_30_40,HTML_MESSAGE,
	MAILTO_TO_SPAM_ADDR, MIME_QP_LONG_LINE, ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP, spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12781 invoked from network); 16 Sep 2012 16:35:09 -0000
Received: from mail-we0-f173.google.com (HELO mail-we0-f173.google.com)
	(74.125.82.173)
	by server-10.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Sep 2012 16:35:09 -0000
Received: by weyz53 with SMTP id z53so4050392wey.32
	for <xen-devel@lists.xen.org>; Sun, 16 Sep 2012 09:35:09 -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;
	bh=Wbrv6op/myy71TtcvExkHHIUXgFZOdz5/T8uxpArRmQ=;
	b=rIleqchKoX6EbNEY5hQyVNpcaf6J013eKDHNzFAt1FqGnzdoxRW2EZxrfZG5jVhO1m
	YmKVUSSRSIHTVYV5MUFN28Qmpa21dhjCE6dXr03SZxYZLrGubr1V0fcaxlVamSh45z2h
	zojKpdsutMkk+YRUzw9LsC8MxByZsc8mruVClYRHzzxLFp+dXoOzv31sB2Uu/MS6CgXy
	v0k125rPlKwkWUhgJw8E/AdBGvC8Vc4FX7eF4juHKTdaDrfW0v8MqfFeBW6X7/t50AlV
	FVbtewjm1T1VOtBhruc3RqHDA8aVLm/z5Bjsn8vvdCZuLToFgio7r6BeRNJ/EsiGZzFm
	eHxA==
Received: by 10.180.14.74 with SMTP id n10mr10627959wic.17.1347813309001;
	Sun, 16 Sep 2012 09:35:09 -0700 (PDT)
Received: from [192.168.1.69] (host86-183-251-65.range86-183.btcentralplus.com.
	[86.183.251.65])
	by mx.google.com with ESMTPS id cu1sm12773161wib.6.2012.09.16.09.35.06
	(version=SSLv3 cipher=OTHER); Sun, 16 Sep 2012 09:35:08 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Sun, 16 Sep 2012 17:35:02 +0100
From: Keir Fraser <keir.xen@gmail.com>
To: Navin Patel <navinjpatel336@gmail.com>,
	<xen-devel@lists.xen.org>
Message-ID: <CC7BBE46.3EE9C%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] 4.2.0-rc4 bug: memory events for CR3 register are
	broken (working in 4.1.3)
Thread-Index: Ac2UKTgiuzIeLUHbCECcraVtXYR+wg==
In-Reply-To: <CALEYbrhEoSEcXGpCkYqEz9K7Fgz7KLK_G2+Oz-FCc00Egr9RAg@mail.gmail.com>
Mime-version: 1.0
Cc: Steven Maresca <steve@zentific.com>
Subject: Re: [Xen-devel] 4.2.0-rc4 bug: memory events for CR3 register are
 broken (working in 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: multipart/mixed; boundary="===============7191763664289788255=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--===============7191763664289788255==
Content-type: multipart/alternative;
	boundary="B_3430661707_60064861"

> This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--B_3430661707_60064861
Content-type: text/plain;
	charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable

This issue is known and a fix has been proposed. It=B9s too late for 4.2.0
unfortunately, but will be fixed for 4.2.1.

 -- Keir

On 16/09/2012 16:52, "Navin Patel" <navinjpatel336@gmail.com> wrote:

> Greetings,
>=20
> I have tested some of my research code watching for CR3 memory events on =
Xen
> 4.2.0-rc4, and I have discovered that CR3 events are not being delivered.=
=A0
> This did work properly in 4.1.3, so I think 4.2.0-rc4 may has a bug.
>=20
> =A0This feature has been removed maybe?
>=20
> Crude test=A0 to confirm this can be had by changing
> tools/tests/xen-access/xen-access.c : replace HVM_PARAM_MEMORY_EVENT_INT3=
 with
> HVM_PARAM_MEMORY_EVENT_CR3 and rebuild (line 569 and 571 in 4.2.0-rc4).
>=20
> Then (while domU is scheduling programs/launching new processes) run like=
 int3
> were still the constant value: ./xen-access $DOMID int3
>=20
> 4.1.3: In the switch/case, printf will show "UNKNOWN REASON CODE $C", wit=
h c
> =3D=3D 3 =3D=3D MEM_EVENT_REASON_CR3 (no case built to detect CR3 evnets).
>=20
> 4.2.0-rc4: In the switch/case, printf will never show "UNKNOWN REASON COD=
E 3"
>=20
> Cheers,
> Navin
>=20
>=20
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel


--B_3430661707_60064861
Content-type: text/html;
	charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable

<HTML>
<HEAD>
<TITLE>Re: [Xen-devel] 4.2.0-rc4 bug: memory events for CR3 register are br=
oken (working in 4.1.3)</TITLE>
</HEAD>
<BODY>
<FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN STYLE=3D'font-size:11pt=
'>This issue is known and a fix has been proposed. It&#8217;s too late for 4=
.2.0 unfortunately, but will be fixed for 4.2.1.<BR>
<BR>
&nbsp;-- Keir<BR>
<BR>
On 16/09/2012 16:52, &quot;Navin Patel&quot; &lt;<a href=3D"navinjpatel336@gm=
ail.com">navinjpatel336@gmail.com</a>&gt; wrote:<BR>
<BR>
</SPAN></FONT><BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><=
SPAN STYLE=3D'font-size:11pt'>Greetings,<BR>
<BR>
I have tested some of my research code watching for CR3 memory events on Xe=
n 4.2.0-rc4, and I have discovered that CR3 events are not being delivered.=A0=
 This did work properly in 4.1.3, so I think 4.2.0-rc4 may has a bug.<BR>
<BR>
=A0This feature has been removed maybe?<BR>
<BR>
Crude test=A0 to confirm this can be had by changing tools/tests/xen-access/x=
en-access.c : replace HVM_PARAM_MEMORY_EVENT_INT3 with HVM_PARAM_MEMORY_EVEN=
T_CR3 and rebuild (line 569 and 571 in 4.2.0-rc4).<BR>
<BR>
Then (while domU is scheduling programs/launching new processes) run like i=
nt3 were still the constant value: ./xen-access $DOMID int3<BR>
<BR>
4.1.3: In the switch/case, printf will show &quot;UNKNOWN REASON CODE $C&qu=
ot;, with c =3D=3D 3 =3D=3D MEM_EVENT_REASON_CR3 (no case built to detect CR3 evnets=
).<BR>
<BR>
4.2.0-rc4: In the switch/case, printf will never show &quot;UNKNOWN REASON =
CODE 3&quot;<BR>
<BR>
Cheers,<BR>
Navin<BR>
<BR>
<HR ALIGN=3DCENTER SIZE=3D"3" WIDTH=3D"95%"></SPAN></FONT><FONT SIZE=3D"2"><FONT FA=
CE=3D"Consolas, Courier New, Courier"><SPAN STYLE=3D'font-size:10pt'>___________=
____________________________________<BR>
Xen-devel mailing list<BR>
<a href=3D"Xen-devel@lists.xen.org">Xen-devel@lists.xen.org</a><BR>
<a href=3D"http://lists.xen.org/xen-devel">http://lists.xen.org/xen-devel</a>=
<BR>
</SPAN></FONT></FONT></BLOCKQUOTE>
</BODY>
</HTML>


--B_3430661707_60064861--




--===============7191763664289788255==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============7191763664289788255==--




From xen-devel-bounces@lists.xen.org Sun Sep 16 16:41:52 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 16 Sep 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 1TDHuS-0005X0-Fe; Sun, 16 Sep 2012 16:41:28 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ikozhukhov@gmail.com>) id 1TDHuQ-0005Wt-Ln
	for xen-devel@lists.xen.org; Sun, 16 Sep 2012 16:41:27 +0000
Received: from [85.158.137.99:35940] by server-7.bemta-3.messagelabs.com id
	45/CB-32000-53106505; Sun, 16 Sep 2012 16:41:25 +0000
X-Env-Sender: ikozhukhov@gmail.com
X-Msg-Ref: server-4.tower-217.messagelabs.com!1347813684!17886899!1
X-Originating-IP: [209.85.217.173]
X-SpamReason: No, hits=1.0 required=7.0 tests=HTML_90_100,HTML_MESSAGE,
	MIME_QP_LONG_LINE,ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3834 invoked from network); 16 Sep 2012 16:41:25 -0000
Received: from mail-lb0-f173.google.com (HELO mail-lb0-f173.google.com)
	(209.85.217.173)
	by server-4.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Sep 2012 16:41:25 -0000
Received: by lbbgm13 with SMTP id gm13so4526601lbb.32
	for <xen-devel@lists.xen.org>; Sun, 16 Sep 2012 09:41:24 -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
	:mime-version:content-type;
	bh=RCrp4KrDq3/Xz/4H9XflLFMue4xSwCD9f4ZUINZXya4=;
	b=VaAMcR+WCizGfW6v5wB3P6z1brot+jMEWfR4iI7LVg5LaaIw/WMEdZ9i9jA1tDVR2C
	ANHuV/hpSxwL5OsD4J+A1nJx1WQbHsB649JzIi6hHt5XsaAj1kAGLlB8ody/66TkvwKu
	ouklsSEbEDiEwil2BlwADoKEYUGp5syOStZNv5rHcK647Os9SID9fveWRprYEW5WksJs
	IqhznKIldhowyKTeM0WqobZilut94cGvHqjRrIcHYli5vgYLsXQOpnXPXTBufxxlU3VM
	1monrDvrJvsATHnHacGSXC7bY8/xs1Y7HPyN++RoYjCUQe83884z0JmSAyrd1x1rnf4W
	8+Jw==
Received: by 10.112.26.106 with SMTP id k10mr3115284lbg.100.1347813684407;
	Sun, 16 Sep 2012 09:41:24 -0700 (PDT)
Received: from [172.16.90.16] ([91.204.58.44])
	by mx.google.com with ESMTPS id mt19sm2203016lab.17.2012.09.16.09.41.21
	(version=SSLv3 cipher=OTHER); Sun, 16 Sep 2012 09:41:23 -0700 (PDT)
User-Agent: Microsoft-MacOutlook/14.2.3.120616
Date: Sun, 16 Sep 2012 20:41:19 +0400
From: Igor Kozhukhov <ikozhukhov@gmail.com>
To: <xen-devel@lists.xen.org>
Message-ID: <CC7BE9EE.2D8B7%ikozhukhov@gmail.com>
Thread-Topic: xen on illumos(OpenSolaris) based platform
Mime-version: 1.0
Subject: [Xen-devel] xen on illumos(OpenSolaris) based 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: multipart/mixed; boundary="===============8945539578395221355=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--===============8945539578395221355==
Content-type: multipart/alternative;
	boundary="B_3430672882_129451653"

> This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--B_3430672882_129451653
Content-type: text/plain;
	charset="US-ASCII"
Content-transfer-encoding: 7bit

hello all!

are you interested in port xen-4.1 to illumos(OpenSolaris) based platform?
I have found old Sun works with xen-3.4.2 and updated it to xen-3.4.4

I'll try to port xen-4.1.

can I file a bugs with issues on solaris based platform?
where can I file a bugs - I have bout some issues and I'd like to provide
fixes for solaris.

---
Best regards,
Igor Kozhukhov
IRC# igork



--B_3430672882_129451653
Content-type: text/html;
	charset="US-ASCII"
Content-transfer-encoding: quoted-printable

<html><head></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: s=
pace; -webkit-line-break: after-white-space; color: rgb(0, 0, 0); font-size:=
 14px; font-family: Calibri, sans-serif; "><div><div><div><span style=3D"color=
: rgb(0, 0, 0); font-size: 13px; font-style: normal; font-variant: normal; f=
ont-weight: normal; letter-spacing: normal; line-height: 15px; orphans: 2; t=
ext-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space=
: normal; widows: 2; word-spacing: 0px; -webkit-text-size-adjust: auto; -web=
kit-text-stroke-width: 0px; background-color: rgb(255, 255, 255); display: i=
nline !important; float: none; font-family: Arial, Helvetica, 'Nimbus Sans L=
', sans-serif; ">hello all!</span><br style=3D"color: rgb(0, 0, 0); font-famil=
y: Arial, Helvetica, 'Nimbus Sans L', sans-serif; font-size: 13px; font-styl=
e: normal; font-variant: normal; font-weight: normal; letter-spacing: normal=
; line-height: 15px; orphans: 2; text-align: -webkit-auto; text-indent: 0px;=
 text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -w=
ebkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; background-col=
or: rgb(255, 255, 255); "><br style=3D"color: rgb(0, 0, 0); font-family: Arial=
, Helvetica, 'Nimbus Sans L', sans-serif; font-size: 13px; font-style: norma=
l; font-variant: normal; font-weight: normal; letter-spacing: normal; line-h=
eight: 15px; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-tr=
ansform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-te=
xt-size-adjust: auto; -webkit-text-stroke-width: 0px; background-color: rgb(=
255, 255, 255); "><span style=3D"color: rgb(0, 0, 0); font-size: 13px; font-st=
yle: normal; font-variant: normal; font-weight: normal; letter-spacing: norm=
al; line-height: 15px; orphans: 2; text-align: -webkit-auto; text-indent: 0p=
x; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; =
-webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; background-c=
olor: rgb(255, 255, 255); display: inline !important; float: none; font-fami=
ly: Arial, Helvetica, 'Nimbus Sans L', sans-serif; ">are you interested in p=
ort xen-4.1 to illumos(OpenSolaris) based platform?</span><br style=3D"color: =
rgb(0, 0, 0); font-family: Arial, Helvetica, 'Nimbus Sans L', sans-serif; fo=
nt-size: 13px; font-style: normal; font-variant: normal; font-weight: normal=
; letter-spacing: normal; line-height: 15px; orphans: 2; text-align: -webkit=
-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: =
2; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-wi=
dth: 0px; background-color: rgb(255, 255, 255); "><span style=3D"color: rgb(0,=
 0, 0); font-size: 13px; font-style: normal; font-variant: normal; font-weig=
ht: normal; letter-spacing: normal; line-height: 15px; orphans: 2; text-alig=
n: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal=
; widows: 2; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text=
-stroke-width: 0px; background-color: rgb(255, 255, 255); display: inline !i=
mportant; float: none; font-family: Arial, Helvetica, 'Nimbus Sans L', sans-=
serif; ">I have found old Sun works with xen-3.4.2 and updated it to xen-3.4=
.4</span><br style=3D"color: rgb(0, 0, 0); font-family: Arial, Helvetica, 'Nim=
bus Sans L', sans-serif; font-size: 13px; font-style: normal; font-variant: =
normal; font-weight: normal; letter-spacing: normal; line-height: 15px; orph=
ans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; wh=
ite-space: normal; widows: 2; word-spacing: 0px; -webkit-text-size-adjust: a=
uto; -webkit-text-stroke-width: 0px; background-color: rgb(255, 255, 255); "=
><span style=3D"color: rgb(0, 0, 0); font-size: 13px; font-style: normal; font=
-variant: normal; font-weight: normal; letter-spacing: normal; line-height: =
15px; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform=
: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-text-size=
-adjust: auto; -webkit-text-stroke-width: 0px; background-color: rgb(255, 25=
5, 255); display: inline !important; float: none; font-family: Arial, Helvet=
ica, 'Nimbus Sans L', sans-serif; "><br></span></div><div><span style=3D"color=
: rgb(0, 0, 0); font-size: 13px; font-style: normal; font-variant: normal; f=
ont-weight: normal; letter-spacing: normal; line-height: 15px; orphans: 2; t=
ext-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space=
: normal; widows: 2; word-spacing: 0px; -webkit-text-size-adjust: auto; -web=
kit-text-stroke-width: 0px; background-color: rgb(255, 255, 255); display: i=
nline !important; float: none; font-family: Arial, Helvetica, 'Nimbus Sans L=
', sans-serif; ">I'll try to port xen-4.1.</span><br style=3D"color: rgb(0, 0,=
 0); font-family: Arial, Helvetica, 'Nimbus Sans L', sans-serif; font-size: =
13px; font-style: normal; font-variant: normal; font-weight: normal; letter-=
spacing: normal; line-height: 15px; orphans: 2; text-align: -webkit-auto; te=
xt-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-s=
pacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px;=
 background-color: rgb(255, 255, 255); "><br style=3D"color: rgb(0, 0, 0); fon=
t-family: Arial, Helvetica, 'Nimbus Sans L', sans-serif; font-size: 13px; fo=
nt-style: normal; font-variant: normal; font-weight: normal; letter-spacing:=
 normal; line-height: 15px; orphans: 2; text-align: -webkit-auto; text-inden=
t: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: =
0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; backgro=
und-color: rgb(255, 255, 255); "><span style=3D"color: rgb(0, 0, 0); font-size=
: 13px; font-style: normal; font-variant: normal; font-weight: normal; lette=
r-spacing: normal; line-height: 15px; orphans: 2; text-align: -webkit-auto; =
text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word=
-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0p=
x; background-color: rgb(255, 255, 255); display: inline !important; float: =
none; font-family: Arial, Helvetica, 'Nimbus Sans L', sans-serif; ">can I fi=
le a bugs with issues on solaris based platform?</span><br style=3D"color: rgb=
(0, 0, 0); font-family: Arial, Helvetica, 'Nimbus Sans L', sans-serif; font-=
size: 13px; font-style: normal; font-variant: normal; font-weight: normal; l=
etter-spacing: normal; line-height: 15px; orphans: 2; text-align: -webkit-au=
to; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; =
word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width=
: 0px; background-color: rgb(255, 255, 255); "><span style=3D"color: rgb(0, 0,=
 0); font-size: 13px; font-style: normal; font-variant: normal; font-weight:=
 normal; letter-spacing: normal; line-height: 15px; orphans: 2; text-align: =
-webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; w=
idows: 2; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-st=
roke-width: 0px; background-color: rgb(255, 255, 255); display: inline !impo=
rtant; float: none; font-family: Arial, Helvetica, 'Nimbus Sans L', sans-ser=
if; ">where can I file a bugs - I have bout some issues and I'd like to prov=
ide fixes for solaris.</span><br style=3D"color: rgb(0, 0, 0); font-family: Ar=
ial, Helvetica, 'Nimbus Sans L', sans-serif; font-size: 13px; font-style: no=
rmal; font-variant: normal; font-weight: normal; letter-spacing: normal; lin=
e-height: 15px; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text=
-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit=
-text-size-adjust: auto; -webkit-text-stroke-width: 0px; background-color: r=
gb(255, 255, 255); "><br style=3D"color: rgb(0, 0, 0); font-family: Arial, Hel=
vetica, 'Nimbus Sans L', sans-serif; font-size: 13px; font-style: normal; fo=
nt-variant: normal; font-weight: normal; letter-spacing: normal; line-height=
: 15px; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transfo=
rm: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-text-si=
ze-adjust: auto; -webkit-text-stroke-width: 0px; background-color: rgb(255, =
255, 255); "></div><div><font face=3D"Calibri,Verdana,Helvetica,Arial"><span s=
tyle=3D"font-size:11pt">---<br>
Best regards,<br>
Igor Kozhukhov<br>IRC# igork<br></span></font></div></div></div></body></ht=
ml>

--B_3430672882_129451653--




--===============8945539578395221355==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============8945539578395221355==--




From xen-devel-bounces@lists.xen.org Sun Sep 16 16:41:52 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 16 Sep 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 1TDHuS-0005X0-Fe; Sun, 16 Sep 2012 16:41:28 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ikozhukhov@gmail.com>) id 1TDHuQ-0005Wt-Ln
	for xen-devel@lists.xen.org; Sun, 16 Sep 2012 16:41:27 +0000
Received: from [85.158.137.99:35940] by server-7.bemta-3.messagelabs.com id
	45/CB-32000-53106505; Sun, 16 Sep 2012 16:41:25 +0000
X-Env-Sender: ikozhukhov@gmail.com
X-Msg-Ref: server-4.tower-217.messagelabs.com!1347813684!17886899!1
X-Originating-IP: [209.85.217.173]
X-SpamReason: No, hits=1.0 required=7.0 tests=HTML_90_100,HTML_MESSAGE,
	MIME_QP_LONG_LINE,ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3834 invoked from network); 16 Sep 2012 16:41:25 -0000
Received: from mail-lb0-f173.google.com (HELO mail-lb0-f173.google.com)
	(209.85.217.173)
	by server-4.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Sep 2012 16:41:25 -0000
Received: by lbbgm13 with SMTP id gm13so4526601lbb.32
	for <xen-devel@lists.xen.org>; Sun, 16 Sep 2012 09:41:24 -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
	:mime-version:content-type;
	bh=RCrp4KrDq3/Xz/4H9XflLFMue4xSwCD9f4ZUINZXya4=;
	b=VaAMcR+WCizGfW6v5wB3P6z1brot+jMEWfR4iI7LVg5LaaIw/WMEdZ9i9jA1tDVR2C
	ANHuV/hpSxwL5OsD4J+A1nJx1WQbHsB649JzIi6hHt5XsaAj1kAGLlB8ody/66TkvwKu
	ouklsSEbEDiEwil2BlwADoKEYUGp5syOStZNv5rHcK647Os9SID9fveWRprYEW5WksJs
	IqhznKIldhowyKTeM0WqobZilut94cGvHqjRrIcHYli5vgYLsXQOpnXPXTBufxxlU3VM
	1monrDvrJvsATHnHacGSXC7bY8/xs1Y7HPyN++RoYjCUQe83884z0JmSAyrd1x1rnf4W
	8+Jw==
Received: by 10.112.26.106 with SMTP id k10mr3115284lbg.100.1347813684407;
	Sun, 16 Sep 2012 09:41:24 -0700 (PDT)
Received: from [172.16.90.16] ([91.204.58.44])
	by mx.google.com with ESMTPS id mt19sm2203016lab.17.2012.09.16.09.41.21
	(version=SSLv3 cipher=OTHER); Sun, 16 Sep 2012 09:41:23 -0700 (PDT)
User-Agent: Microsoft-MacOutlook/14.2.3.120616
Date: Sun, 16 Sep 2012 20:41:19 +0400
From: Igor Kozhukhov <ikozhukhov@gmail.com>
To: <xen-devel@lists.xen.org>
Message-ID: <CC7BE9EE.2D8B7%ikozhukhov@gmail.com>
Thread-Topic: xen on illumos(OpenSolaris) based platform
Mime-version: 1.0
Subject: [Xen-devel] xen on illumos(OpenSolaris) based 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: multipart/mixed; boundary="===============8945539578395221355=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--===============8945539578395221355==
Content-type: multipart/alternative;
	boundary="B_3430672882_129451653"

> This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--B_3430672882_129451653
Content-type: text/plain;
	charset="US-ASCII"
Content-transfer-encoding: 7bit

hello all!

are you interested in port xen-4.1 to illumos(OpenSolaris) based platform?
I have found old Sun works with xen-3.4.2 and updated it to xen-3.4.4

I'll try to port xen-4.1.

can I file a bugs with issues on solaris based platform?
where can I file a bugs - I have bout some issues and I'd like to provide
fixes for solaris.

---
Best regards,
Igor Kozhukhov
IRC# igork



--B_3430672882_129451653
Content-type: text/html;
	charset="US-ASCII"
Content-transfer-encoding: quoted-printable

<html><head></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: s=
pace; -webkit-line-break: after-white-space; color: rgb(0, 0, 0); font-size:=
 14px; font-family: Calibri, sans-serif; "><div><div><div><span style=3D"color=
: rgb(0, 0, 0); font-size: 13px; font-style: normal; font-variant: normal; f=
ont-weight: normal; letter-spacing: normal; line-height: 15px; orphans: 2; t=
ext-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space=
: normal; widows: 2; word-spacing: 0px; -webkit-text-size-adjust: auto; -web=
kit-text-stroke-width: 0px; background-color: rgb(255, 255, 255); display: i=
nline !important; float: none; font-family: Arial, Helvetica, 'Nimbus Sans L=
', sans-serif; ">hello all!</span><br style=3D"color: rgb(0, 0, 0); font-famil=
y: Arial, Helvetica, 'Nimbus Sans L', sans-serif; font-size: 13px; font-styl=
e: normal; font-variant: normal; font-weight: normal; letter-spacing: normal=
; line-height: 15px; orphans: 2; text-align: -webkit-auto; text-indent: 0px;=
 text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -w=
ebkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; background-col=
or: rgb(255, 255, 255); "><br style=3D"color: rgb(0, 0, 0); font-family: Arial=
, Helvetica, 'Nimbus Sans L', sans-serif; font-size: 13px; font-style: norma=
l; font-variant: normal; font-weight: normal; letter-spacing: normal; line-h=
eight: 15px; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-tr=
ansform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-te=
xt-size-adjust: auto; -webkit-text-stroke-width: 0px; background-color: rgb(=
255, 255, 255); "><span style=3D"color: rgb(0, 0, 0); font-size: 13px; font-st=
yle: normal; font-variant: normal; font-weight: normal; letter-spacing: norm=
al; line-height: 15px; orphans: 2; text-align: -webkit-auto; text-indent: 0p=
x; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; =
-webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; background-c=
olor: rgb(255, 255, 255); display: inline !important; float: none; font-fami=
ly: Arial, Helvetica, 'Nimbus Sans L', sans-serif; ">are you interested in p=
ort xen-4.1 to illumos(OpenSolaris) based platform?</span><br style=3D"color: =
rgb(0, 0, 0); font-family: Arial, Helvetica, 'Nimbus Sans L', sans-serif; fo=
nt-size: 13px; font-style: normal; font-variant: normal; font-weight: normal=
; letter-spacing: normal; line-height: 15px; orphans: 2; text-align: -webkit=
-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: =
2; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-wi=
dth: 0px; background-color: rgb(255, 255, 255); "><span style=3D"color: rgb(0,=
 0, 0); font-size: 13px; font-style: normal; font-variant: normal; font-weig=
ht: normal; letter-spacing: normal; line-height: 15px; orphans: 2; text-alig=
n: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal=
; widows: 2; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text=
-stroke-width: 0px; background-color: rgb(255, 255, 255); display: inline !i=
mportant; float: none; font-family: Arial, Helvetica, 'Nimbus Sans L', sans-=
serif; ">I have found old Sun works with xen-3.4.2 and updated it to xen-3.4=
.4</span><br style=3D"color: rgb(0, 0, 0); font-family: Arial, Helvetica, 'Nim=
bus Sans L', sans-serif; font-size: 13px; font-style: normal; font-variant: =
normal; font-weight: normal; letter-spacing: normal; line-height: 15px; orph=
ans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; wh=
ite-space: normal; widows: 2; word-spacing: 0px; -webkit-text-size-adjust: a=
uto; -webkit-text-stroke-width: 0px; background-color: rgb(255, 255, 255); "=
><span style=3D"color: rgb(0, 0, 0); font-size: 13px; font-style: normal; font=
-variant: normal; font-weight: normal; letter-spacing: normal; line-height: =
15px; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform=
: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-text-size=
-adjust: auto; -webkit-text-stroke-width: 0px; background-color: rgb(255, 25=
5, 255); display: inline !important; float: none; font-family: Arial, Helvet=
ica, 'Nimbus Sans L', sans-serif; "><br></span></div><div><span style=3D"color=
: rgb(0, 0, 0); font-size: 13px; font-style: normal; font-variant: normal; f=
ont-weight: normal; letter-spacing: normal; line-height: 15px; orphans: 2; t=
ext-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space=
: normal; widows: 2; word-spacing: 0px; -webkit-text-size-adjust: auto; -web=
kit-text-stroke-width: 0px; background-color: rgb(255, 255, 255); display: i=
nline !important; float: none; font-family: Arial, Helvetica, 'Nimbus Sans L=
', sans-serif; ">I'll try to port xen-4.1.</span><br style=3D"color: rgb(0, 0,=
 0); font-family: Arial, Helvetica, 'Nimbus Sans L', sans-serif; font-size: =
13px; font-style: normal; font-variant: normal; font-weight: normal; letter-=
spacing: normal; line-height: 15px; orphans: 2; text-align: -webkit-auto; te=
xt-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-s=
pacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px;=
 background-color: rgb(255, 255, 255); "><br style=3D"color: rgb(0, 0, 0); fon=
t-family: Arial, Helvetica, 'Nimbus Sans L', sans-serif; font-size: 13px; fo=
nt-style: normal; font-variant: normal; font-weight: normal; letter-spacing:=
 normal; line-height: 15px; orphans: 2; text-align: -webkit-auto; text-inden=
t: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: =
0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; backgro=
und-color: rgb(255, 255, 255); "><span style=3D"color: rgb(0, 0, 0); font-size=
: 13px; font-style: normal; font-variant: normal; font-weight: normal; lette=
r-spacing: normal; line-height: 15px; orphans: 2; text-align: -webkit-auto; =
text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word=
-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0p=
x; background-color: rgb(255, 255, 255); display: inline !important; float: =
none; font-family: Arial, Helvetica, 'Nimbus Sans L', sans-serif; ">can I fi=
le a bugs with issues on solaris based platform?</span><br style=3D"color: rgb=
(0, 0, 0); font-family: Arial, Helvetica, 'Nimbus Sans L', sans-serif; font-=
size: 13px; font-style: normal; font-variant: normal; font-weight: normal; l=
etter-spacing: normal; line-height: 15px; orphans: 2; text-align: -webkit-au=
to; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; =
word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width=
: 0px; background-color: rgb(255, 255, 255); "><span style=3D"color: rgb(0, 0,=
 0); font-size: 13px; font-style: normal; font-variant: normal; font-weight:=
 normal; letter-spacing: normal; line-height: 15px; orphans: 2; text-align: =
-webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; w=
idows: 2; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-st=
roke-width: 0px; background-color: rgb(255, 255, 255); display: inline !impo=
rtant; float: none; font-family: Arial, Helvetica, 'Nimbus Sans L', sans-ser=
if; ">where can I file a bugs - I have bout some issues and I'd like to prov=
ide fixes for solaris.</span><br style=3D"color: rgb(0, 0, 0); font-family: Ar=
ial, Helvetica, 'Nimbus Sans L', sans-serif; font-size: 13px; font-style: no=
rmal; font-variant: normal; font-weight: normal; letter-spacing: normal; lin=
e-height: 15px; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text=
-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit=
-text-size-adjust: auto; -webkit-text-stroke-width: 0px; background-color: r=
gb(255, 255, 255); "><br style=3D"color: rgb(0, 0, 0); font-family: Arial, Hel=
vetica, 'Nimbus Sans L', sans-serif; font-size: 13px; font-style: normal; fo=
nt-variant: normal; font-weight: normal; letter-spacing: normal; line-height=
: 15px; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transfo=
rm: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-text-si=
ze-adjust: auto; -webkit-text-stroke-width: 0px; background-color: rgb(255, =
255, 255); "></div><div><font face=3D"Calibri,Verdana,Helvetica,Arial"><span s=
tyle=3D"font-size:11pt">---<br>
Best regards,<br>
Igor Kozhukhov<br>IRC# igork<br></span></font></div></div></div></body></ht=
ml>

--B_3430672882_129451653--




--===============8945539578395221355==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============8945539578395221355==--




From xen-devel-bounces@lists.xen.org Sun Sep 16 17:57:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 16 Sep 2012 17:57:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDJ5I-0006IW-DI; Sun, 16 Sep 2012 17:56: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 1TDJ5G-0006IR-FN
	for xen-devel@lists.xensource.com; Sun, 16 Sep 2012 17:56:42 +0000
Received: from [85.158.139.211:45439] by server-4.bemta-5.messagelabs.com id
	DF/8B-23042-9D216505; Sun, 16 Sep 2012 17:56:41 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-206.messagelabs.com!1347818201!18717970!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDk2MzE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8583 invoked from network); 16 Sep 2012 17:56:41 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Sep 2012 17:56:41 -0000
X-IronPort-AV: E=Sophos;i="4.80,431,1344211200"; d="scan'208";a="14566401"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Sep 2012 17:56: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.279.1; Sun, 16 Sep 2012 18:56: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 1TDJ5E-0002LL-Qd;
	Sun, 16 Sep 2012 17:56:40 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1TDJ5E-0007wD-KV;
	Sun, 16 Sep 2012 18:56:40 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-13786-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sun, 16 Sep 2012 18:56:40 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-mingo-tip-master test] 13786: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 13786 linux-mingo-tip-master real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13786/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xend-winxpsp3  5 xen-boot                 fail REGR. vs. 12678
 test-amd64-i386-xl-credit2    5 xen-boot                  fail REGR. vs. 12678
 test-amd64-amd64-pair         8 xen-boot/dst_host         fail REGR. vs. 12678
 test-amd64-amd64-pair         7 xen-boot/src_host         fail REGR. vs. 12678

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  5 xen-boot                    fail never pass
 test-amd64-amd64-xl-win7-amd64  5 xen-boot                     fail never pass
 test-amd64-i386-xl-win-vcpus1  5 xen-boot                     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-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail never pass
 test-amd64-i386-pair          8 xen-boot/dst_host            fail   never pass
 test-amd64-i386-pair          7 xen-boot/src_host            fail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass

version targeted for testing:
 linux                2a346d40b9564288f5d41b441e14d6a4dae3be2b
baseline version:
 linux                d935d0f77650fea53986811ca8a2f8c726fd9857

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-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                                   fail    
 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                                        fail    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-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-amd64-amd64-xl-win                                      fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Sep 16 17:57:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 16 Sep 2012 17:57:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDJ5I-0006IW-DI; Sun, 16 Sep 2012 17:56: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 1TDJ5G-0006IR-FN
	for xen-devel@lists.xensource.com; Sun, 16 Sep 2012 17:56:42 +0000
Received: from [85.158.139.211:45439] by server-4.bemta-5.messagelabs.com id
	DF/8B-23042-9D216505; Sun, 16 Sep 2012 17:56:41 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-206.messagelabs.com!1347818201!18717970!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDk2MzE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8583 invoked from network); 16 Sep 2012 17:56:41 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Sep 2012 17:56:41 -0000
X-IronPort-AV: E=Sophos;i="4.80,431,1344211200"; d="scan'208";a="14566401"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Sep 2012 17:56: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.279.1; Sun, 16 Sep 2012 18:56: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 1TDJ5E-0002LL-Qd;
	Sun, 16 Sep 2012 17:56:40 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1TDJ5E-0007wD-KV;
	Sun, 16 Sep 2012 18:56:40 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-13786-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sun, 16 Sep 2012 18:56:40 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux-mingo-tip-master test] 13786: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 13786 linux-mingo-tip-master real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13786/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xend-winxpsp3  5 xen-boot                 fail REGR. vs. 12678
 test-amd64-i386-xl-credit2    5 xen-boot                  fail REGR. vs. 12678
 test-amd64-amd64-pair         8 xen-boot/dst_host         fail REGR. vs. 12678
 test-amd64-amd64-pair         7 xen-boot/src_host         fail REGR. vs. 12678

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  5 xen-boot                    fail never pass
 test-amd64-amd64-xl-win7-amd64  5 xen-boot                     fail never pass
 test-amd64-i386-xl-win-vcpus1  5 xen-boot                     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-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail never pass
 test-amd64-i386-pair          8 xen-boot/dst_host            fail   never pass
 test-amd64-i386-pair          7 xen-boot/src_host            fail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass

version targeted for testing:
 linux                2a346d40b9564288f5d41b441e14d6a4dae3be2b
baseline version:
 linux                d935d0f77650fea53986811ca8a2f8c726fd9857

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-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                                   fail    
 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                                        fail    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-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-amd64-amd64-xl-win                                      fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Sep 16 18:36:31 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 16 Sep 2012 18:36:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDJhH-0007JG-16; Sun, 16 Sep 2012 18:35:59 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <navinjpatel336@gmail.com>) id 1TDJhF-0007JB-LG
	for xen-devel@lists.xen.org; Sun, 16 Sep 2012 18:35:57 +0000
Received: from [85.158.137.99:35831] by server-5.bemta-3.messagelabs.com id
	F0/47-13133-C0C16505; Sun, 16 Sep 2012 18:35:56 +0000
X-Env-Sender: navinjpatel336@gmail.com
X-Msg-Ref: server-7.tower-217.messagelabs.com!1347820553!13098357!1
X-Originating-IP: [209.85.214.173]
X-SpamReason: No, hits=1.6 required=7.0 tests=HTML_30_40,HTML_MESSAGE,
	MAILTO_TO_SPAM_ADDR,ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,USERPASS,
	spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 697 invoked from network); 16 Sep 2012 18:35:54 -0000
Received: from mail-ob0-f173.google.com (HELO mail-ob0-f173.google.com)
	(209.85.214.173)
	by server-7.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Sep 2012 18:35:54 -0000
Received: by obbta14 with SMTP id ta14so10275907obb.32
	for <xen-devel@lists.xen.org>; Sun, 16 Sep 2012 11:35: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=Hf8YAV5DN+lPFDchrTedZWBwDuAhU1Wd911NnIvgecY=;
	b=cL1mlydJ3F2ENggmMK8WUavECt3h00o3TioODiPsPrbUP6fjpTwluuiof8/uQiDqUy
	mloIf/Wvz+0ap9UexsxGIoK8r/AGLROMTjS5+XpjCqS2dGIfdzEV2GL5Ca8DvqcMIWVR
	hBIIUeqeS3K8VO5gLH/7G5Ys92txrctTNBXa8AMrGC8p8lk8bw6Xay4YGvgq7V1CaLDO
	GPKoTj5zICUK1WzKFos/pxkRI6+z2Io/QSOFvnicMR1E46JU0Yuj1w0bch2B6I1AmUUz
	bIck1SYZxnwR5UmFgyywHGExq41ILbvzZ/AEhIibxVIGfMKWUa4BgnLC4qjelkCrVbYB
	8aEQ==
MIME-Version: 1.0
Received: by 10.60.172.15 with SMTP id ay15mr9509560oec.64.1347820553174; Sun,
	16 Sep 2012 11:35:53 -0700 (PDT)
Received: by 10.76.117.73 with HTTP; Sun, 16 Sep 2012 11:35:53 -0700 (PDT)
In-Reply-To: <CC7BBE46.3EE9C%keir.xen@gmail.com>
References: <CALEYbrhEoSEcXGpCkYqEz9K7Fgz7KLK_G2+Oz-FCc00Egr9RAg@mail.gmail.com>
	<CC7BBE46.3EE9C%keir.xen@gmail.com>
Date: Sun, 16 Sep 2012 14:35:53 -0400
Message-ID: <CALEYbrhhLsnx_o2kezp+WbR553iwkHRPO7MQ5Nxi27n-ZovvVA@mail.gmail.com>
From: Navin Patel <navinjpatel336@gmail.com>
To: Keir Fraser <keir.xen@gmail.com>
Cc: Steven Maresca <steve@zentific.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] 4.2.0-rc4 bug: memory events for CR3 register are
 broken (working in 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: multipart/mixed; boundary="===============2015733442833265809=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============2015733442833265809==
Content-Type: multipart/alternative; boundary=bcaec54faf2c4afe7004c9d5ed5c

--bcaec54faf2c4afe7004c9d5ed5c
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

On Sun, Sep 16, 2012 at 12:35 PM, Keir Fraser <keir.xen@gmail.com> wrote:

>  This issue is known and a fix has been proposed. It=92s too late for 4.2=
.0
> unfortunately, but will be fixed for 4.2.1.
>
>  -- Keir
>
>
> On 16/09/2012 16:52, "Navin Patel" <navinjpatel336@gmail.com> wrote:
>
> Greetings,
>
> I have tested some of my research code watching for CR3 memory events on
> Xen 4.2.0-rc4, and I have discovered that CR3 events are not being
> delivered.  This did work properly in 4.1.3, so I think 4.2.0-rc4 may has=
 a
> bug.
>
>  This feature has been removed maybe?
>
> Crude test  to confirm this can be had by changing
> tools/tests/xen-access/xen-access.c : replace HVM_PARAM_MEMORY_EVENT_INT3
> with HVM_PARAM_MEMORY_EVENT_CR3 and rebuild (line 569 and 571 in 4.2.0-rc=
4).
>
> Then (while domU is scheduling programs/launching new processes) run like
> int3 were still the constant value: ./xen-access $DOMID int3
>
> 4.1.3: In the switch/case, printf will show "UNKNOWN REASON CODE $C", wit=
h
> c =3D=3D 3 =3D=3D MEM_EVENT_REASON_CR3 (no case built to detect CR3 evnet=
s).
>
> 4.2.0-rc4: In the switch/case, printf will never show "UNKNOWN REASON COD=
E
> 3"
>
> Cheers,
> Navin
>
> ------------------------------
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
>
>  Keir and Steven,

Thank you for your work. The proposed patch solved the bug!

After 4.2.0 is officially released this week, I very much hope that this
patch is backported to the 4.2.0 tree. Several distributions like Debian
are already building upon 4.2.0 and will not wait for 4.2.1, and without
the patch being backported, researchers like me will not be able to use the
supported Xen from package repository.  We can compile from source, but if
we have a supported version it is better for everyone. (And it is such a
simple patch! )

Is this something I can request in formal manner?

Cheers,
Navin

--bcaec54faf2c4afe7004c9d5ed5c
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

<br><br><div class=3D"gmail_quote">On Sun, Sep 16, 2012 at 12:35 PM, Keir F=
raser <span dir=3D"ltr">&lt;<a href=3D"mailto:keir.xen@gmail.com" target=3D=
"_blank">keir.xen@gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"g=
mail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-l=
eft:1ex">




<div>
<font face=3D"Calibri, Verdana, Helvetica, Arial"><span style=3D"font-size:=
11pt">This issue is known and a fix has been proposed. It=92s too late for =
4.2.0 unfortunately, but will be fixed for 4.2.1.<br>
<br>
=A0-- Keir<div><div class=3D"h5"><br>
<br>
On 16/09/2012 16:52, &quot;Navin Patel&quot; &lt;<a href=3D"http://navinjpa=
tel336@gmail.com" target=3D"_blank">navinjpatel336@gmail.com</a>&gt; wrote:=
<br>
<br>
</div></div></span></font><blockquote><font face=3D"Calibri, Verdana, Helve=
tica, Arial"><span style=3D"font-size:11pt"><div><div class=3D"h5">Greeting=
s,<br>
<br>
I have tested some of my research code watching for CR3 memory events on Xe=
n 4.2.0-rc4, and I have discovered that CR3 events are not being delivered.=
=A0 This did work properly in 4.1.3, so I think 4.2.0-rc4 may has a bug.<br=
>

<br>
=A0This feature has been removed maybe?<br>
<br>
Crude test=A0 to confirm this can be had by changing tools/tests/xen-access=
/xen-access.c : replace HVM_PARAM_MEMORY_EVENT_INT3 with HVM_PARAM_MEMORY_E=
VENT_CR3 and rebuild (line 569 and 571 in 4.2.0-rc4).<br>
<br>
Then (while domU is scheduling programs/launching new processes) run like i=
nt3 were still the constant value: ./xen-access $DOMID int3<br>
<br>
4.1.3: In the switch/case, printf will show &quot;UNKNOWN REASON CODE $C&qu=
ot;, with c =3D=3D 3 =3D=3D MEM_EVENT_REASON_CR3 (no case built to detect C=
R3 evnets).<br>
<br>
4.2.0-rc4: In the switch/case, printf will never show &quot;UNKNOWN REASON =
CODE 3&quot;<br>
<br>
Cheers,<br>
Navin<br>
<br>
</div></div><hr align=3D"CENTER" size=3D"3" width=3D"95%"></span></font><fo=
nt><font face=3D"Consolas, Courier New, Courier"><span style=3D"font-size:1=
0pt">_______________________________________________<br>
Xen-devel mailing list<br>
<a href=3D"http://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>
</span></font></font></blockquote>
</div>


</blockquote></div>Keir and Steven, <br><br>Thank you for your work. The pr=
oposed patch solved the bug! <br><br>After 4.2.0 is officially released thi=
s week, I very much hope that this patch is backported to the 4.2.0 tree. S=
everal distributions like Debian are already building upon 4.2.0 and will n=
ot wait for 4.2.1, and without the patch being backported, researchers like=
 me will not be able to use the supported Xen from package repository.=A0 W=
e can compile from source, but if we have a supported version it is better =
for everyone. (And it is such a simple patch! )<br>
<br>Is this something I can request in formal manner?<br><br>Cheers,<br>Nav=
in<br><br>

--bcaec54faf2c4afe7004c9d5ed5c--


--===============2015733442833265809==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============2015733442833265809==--


From xen-devel-bounces@lists.xen.org Sun Sep 16 18:36:31 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 16 Sep 2012 18:36:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDJhH-0007JG-16; Sun, 16 Sep 2012 18:35:59 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <navinjpatel336@gmail.com>) id 1TDJhF-0007JB-LG
	for xen-devel@lists.xen.org; Sun, 16 Sep 2012 18:35:57 +0000
Received: from [85.158.137.99:35831] by server-5.bemta-3.messagelabs.com id
	F0/47-13133-C0C16505; Sun, 16 Sep 2012 18:35:56 +0000
X-Env-Sender: navinjpatel336@gmail.com
X-Msg-Ref: server-7.tower-217.messagelabs.com!1347820553!13098357!1
X-Originating-IP: [209.85.214.173]
X-SpamReason: No, hits=1.6 required=7.0 tests=HTML_30_40,HTML_MESSAGE,
	MAILTO_TO_SPAM_ADDR,ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,USERPASS,
	spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 697 invoked from network); 16 Sep 2012 18:35:54 -0000
Received: from mail-ob0-f173.google.com (HELO mail-ob0-f173.google.com)
	(209.85.214.173)
	by server-7.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Sep 2012 18:35:54 -0000
Received: by obbta14 with SMTP id ta14so10275907obb.32
	for <xen-devel@lists.xen.org>; Sun, 16 Sep 2012 11:35: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=Hf8YAV5DN+lPFDchrTedZWBwDuAhU1Wd911NnIvgecY=;
	b=cL1mlydJ3F2ENggmMK8WUavECt3h00o3TioODiPsPrbUP6fjpTwluuiof8/uQiDqUy
	mloIf/Wvz+0ap9UexsxGIoK8r/AGLROMTjS5+XpjCqS2dGIfdzEV2GL5Ca8DvqcMIWVR
	hBIIUeqeS3K8VO5gLH/7G5Ys92txrctTNBXa8AMrGC8p8lk8bw6Xay4YGvgq7V1CaLDO
	GPKoTj5zICUK1WzKFos/pxkRI6+z2Io/QSOFvnicMR1E46JU0Yuj1w0bch2B6I1AmUUz
	bIck1SYZxnwR5UmFgyywHGExq41ILbvzZ/AEhIibxVIGfMKWUa4BgnLC4qjelkCrVbYB
	8aEQ==
MIME-Version: 1.0
Received: by 10.60.172.15 with SMTP id ay15mr9509560oec.64.1347820553174; Sun,
	16 Sep 2012 11:35:53 -0700 (PDT)
Received: by 10.76.117.73 with HTTP; Sun, 16 Sep 2012 11:35:53 -0700 (PDT)
In-Reply-To: <CC7BBE46.3EE9C%keir.xen@gmail.com>
References: <CALEYbrhEoSEcXGpCkYqEz9K7Fgz7KLK_G2+Oz-FCc00Egr9RAg@mail.gmail.com>
	<CC7BBE46.3EE9C%keir.xen@gmail.com>
Date: Sun, 16 Sep 2012 14:35:53 -0400
Message-ID: <CALEYbrhhLsnx_o2kezp+WbR553iwkHRPO7MQ5Nxi27n-ZovvVA@mail.gmail.com>
From: Navin Patel <navinjpatel336@gmail.com>
To: Keir Fraser <keir.xen@gmail.com>
Cc: Steven Maresca <steve@zentific.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] 4.2.0-rc4 bug: memory events for CR3 register are
 broken (working in 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: multipart/mixed; boundary="===============2015733442833265809=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============2015733442833265809==
Content-Type: multipart/alternative; boundary=bcaec54faf2c4afe7004c9d5ed5c

--bcaec54faf2c4afe7004c9d5ed5c
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

On Sun, Sep 16, 2012 at 12:35 PM, Keir Fraser <keir.xen@gmail.com> wrote:

>  This issue is known and a fix has been proposed. It=92s too late for 4.2=
.0
> unfortunately, but will be fixed for 4.2.1.
>
>  -- Keir
>
>
> On 16/09/2012 16:52, "Navin Patel" <navinjpatel336@gmail.com> wrote:
>
> Greetings,
>
> I have tested some of my research code watching for CR3 memory events on
> Xen 4.2.0-rc4, and I have discovered that CR3 events are not being
> delivered.  This did work properly in 4.1.3, so I think 4.2.0-rc4 may has=
 a
> bug.
>
>  This feature has been removed maybe?
>
> Crude test  to confirm this can be had by changing
> tools/tests/xen-access/xen-access.c : replace HVM_PARAM_MEMORY_EVENT_INT3
> with HVM_PARAM_MEMORY_EVENT_CR3 and rebuild (line 569 and 571 in 4.2.0-rc=
4).
>
> Then (while domU is scheduling programs/launching new processes) run like
> int3 were still the constant value: ./xen-access $DOMID int3
>
> 4.1.3: In the switch/case, printf will show "UNKNOWN REASON CODE $C", wit=
h
> c =3D=3D 3 =3D=3D MEM_EVENT_REASON_CR3 (no case built to detect CR3 evnet=
s).
>
> 4.2.0-rc4: In the switch/case, printf will never show "UNKNOWN REASON COD=
E
> 3"
>
> Cheers,
> Navin
>
> ------------------------------
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
>
>  Keir and Steven,

Thank you for your work. The proposed patch solved the bug!

After 4.2.0 is officially released this week, I very much hope that this
patch is backported to the 4.2.0 tree. Several distributions like Debian
are already building upon 4.2.0 and will not wait for 4.2.1, and without
the patch being backported, researchers like me will not be able to use the
supported Xen from package repository.  We can compile from source, but if
we have a supported version it is better for everyone. (And it is such a
simple patch! )

Is this something I can request in formal manner?

Cheers,
Navin

--bcaec54faf2c4afe7004c9d5ed5c
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

<br><br><div class=3D"gmail_quote">On Sun, Sep 16, 2012 at 12:35 PM, Keir F=
raser <span dir=3D"ltr">&lt;<a href=3D"mailto:keir.xen@gmail.com" target=3D=
"_blank">keir.xen@gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"g=
mail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-l=
eft:1ex">




<div>
<font face=3D"Calibri, Verdana, Helvetica, Arial"><span style=3D"font-size:=
11pt">This issue is known and a fix has been proposed. It=92s too late for =
4.2.0 unfortunately, but will be fixed for 4.2.1.<br>
<br>
=A0-- Keir<div><div class=3D"h5"><br>
<br>
On 16/09/2012 16:52, &quot;Navin Patel&quot; &lt;<a href=3D"http://navinjpa=
tel336@gmail.com" target=3D"_blank">navinjpatel336@gmail.com</a>&gt; wrote:=
<br>
<br>
</div></div></span></font><blockquote><font face=3D"Calibri, Verdana, Helve=
tica, Arial"><span style=3D"font-size:11pt"><div><div class=3D"h5">Greeting=
s,<br>
<br>
I have tested some of my research code watching for CR3 memory events on Xe=
n 4.2.0-rc4, and I have discovered that CR3 events are not being delivered.=
=A0 This did work properly in 4.1.3, so I think 4.2.0-rc4 may has a bug.<br=
>

<br>
=A0This feature has been removed maybe?<br>
<br>
Crude test=A0 to confirm this can be had by changing tools/tests/xen-access=
/xen-access.c : replace HVM_PARAM_MEMORY_EVENT_INT3 with HVM_PARAM_MEMORY_E=
VENT_CR3 and rebuild (line 569 and 571 in 4.2.0-rc4).<br>
<br>
Then (while domU is scheduling programs/launching new processes) run like i=
nt3 were still the constant value: ./xen-access $DOMID int3<br>
<br>
4.1.3: In the switch/case, printf will show &quot;UNKNOWN REASON CODE $C&qu=
ot;, with c =3D=3D 3 =3D=3D MEM_EVENT_REASON_CR3 (no case built to detect C=
R3 evnets).<br>
<br>
4.2.0-rc4: In the switch/case, printf will never show &quot;UNKNOWN REASON =
CODE 3&quot;<br>
<br>
Cheers,<br>
Navin<br>
<br>
</div></div><hr align=3D"CENTER" size=3D"3" width=3D"95%"></span></font><fo=
nt><font face=3D"Consolas, Courier New, Courier"><span style=3D"font-size:1=
0pt">_______________________________________________<br>
Xen-devel mailing list<br>
<a href=3D"http://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>
</span></font></font></blockquote>
</div>


</blockquote></div>Keir and Steven, <br><br>Thank you for your work. The pr=
oposed patch solved the bug! <br><br>After 4.2.0 is officially released thi=
s week, I very much hope that this patch is backported to the 4.2.0 tree. S=
everal distributions like Debian are already building upon 4.2.0 and will n=
ot wait for 4.2.1, and without the patch being backported, researchers like=
 me will not be able to use the supported Xen from package repository.=A0 W=
e can compile from source, but if we have a supported version it is better =
for everyone. (And it is such a simple patch! )<br>
<br>Is this something I can request in formal manner?<br><br>Cheers,<br>Nav=
in<br><br>

--bcaec54faf2c4afe7004c9d5ed5c--


--===============2015733442833265809==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============2015733442833265809==--


From xen-devel-bounces@lists.xen.org Sun Sep 16 18:38:38 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 16 Sep 2012 18:38:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDJjT-0007OZ-Jj; Sun, 16 Sep 2012 18:38:15 +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 1TDJjR-0007OU-Mj
	for xen-devel@lists.xen.org; Sun, 16 Sep 2012 18:38:13 +0000
Received: from [85.158.143.35:37973] by server-3.bemta-4.messagelabs.com id
	57/B9-08232-59C16505; Sun, 16 Sep 2012 18:38:13 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1347820692!6771241!1
X-Originating-IP: [74.125.82.41]
X-SpamReason: No, hits=1.7 required=7.0 tests=HTML_20_30,HTML_MESSAGE,
	MAILTO_TO_SPAM_ADDR,MIME_QP_LONG_LINE,RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28130 invoked from network); 16 Sep 2012 18:38:12 -0000
Received: from mail-wg0-f41.google.com (HELO mail-wg0-f41.google.com)
	(74.125.82.41)
	by server-4.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Sep 2012 18:38:12 -0000
Received: by wgbds1 with SMTP id ds1so2391661wgb.2
	for <xen-devel@lists.xen.org>; Sun, 16 Sep 2012 11:38:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type;
	bh=6XwH4sh5ov1SabfAiIwXusImfZdnJrrukV/bm1zc1GY=;
	b=zzV2SIWVPE3jRtjup2czXQ7UwhiFTgIcle9ULnipYXeG+EqaVtuWjczWr6jOra4FaT
	p+7XjwS3oHHdCYNNIcMQ3zPRgwELCGE2l0H3/KuCNkQb7Qk15GUZhqUatb0TqTK56S39
	hgtEU8uOftNx5QZNdK9e3epbosnswhEtCnIja1YrSrcGBg8v1FjNnnfKsafKTkfMwMWC
	K4oPQQTS9+61SutX4Y5NgvVJUh+D+0k9RgTJUJRT4aIzOiNmely4AZ/viwquiT6nng9e
	5CURZzTztjhllEuuVWqCaCi14vz1rdftDz+6ModjL0LWUDdykVYv4TPJwO5s5XOdQ8un
	zJCQ==
Received: by 10.216.147.4 with SMTP id s4mr5148061wej.9.1347820692087;
	Sun, 16 Sep 2012 11:38:12 -0700 (PDT)
Received: from [192.168.1.3] (host86-183-251-65.range86-183.btcentralplus.com.
	[86.183.251.65])
	by mx.google.com with ESMTPS id t8sm13373768wiy.3.2012.09.16.11.38.10
	(version=SSLv3 cipher=OTHER); Sun, 16 Sep 2012 11:38:11 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.33.0.120411
Date: Sun, 16 Sep 2012 19:38:06 +0100
From: Keir Fraser <keir@xen.org>
To: Navin Patel <navinjpatel336@gmail.com>
Message-ID: <CC7BDB1E.4BE20%keir@xen.org>
Thread-Topic: [Xen-devel] 4.2.0-rc4 bug: memory events for CR3 register are
	broken (working in 4.1.3)
Thread-Index: Ac2UOmlXbx0wNl/fLEmMccW8i1yNGw==
In-Reply-To: <CALEYbrhhLsnx_o2kezp+WbR553iwkHRPO7MQ5Nxi27n-ZovvVA@mail.gmail.com>
Mime-version: 1.0
Cc: Steven Maresca <steve@zentific.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] 4.2.0-rc4 bug: memory events for CR3 register are
 broken (working in 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: multipart/mixed; boundary="===============3459963200799474924=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--===============3459963200799474924==
Content-type: multipart/alternative;
	boundary="B_3430669090_2352173"

> This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--B_3430669090_2352173
Content-type: text/plain;
	charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable

Keep an eye on xen-unstable and make sure the patch, or equivalent, goes in
in the next week or two. Once it=B9s in you can request it be backported.

 -- Keir

On 16/09/2012 19:35, "Navin Patel" <navinjpatel336@gmail.com> wrote:

> Keir and Steven,=20
>=20
> Thank you for your work. The proposed patch solved the bug!
>=20
> After 4.2.0 is officially released this week, I very much hope that this =
patch
> is backported to the 4.2.0 tree. Several distributions like Debian are al=
ready
> building upon 4.2.0 and will not wait for 4.2.1, and without the patch be=
ing
> backported, researchers like me will not be able to use the supported Xen=
 from
> package repository.=A0 We can compile from source, but if we have a support=
ed
> version it is better for everyone. (And it is such a simple patch! )
>=20
> Is this something I can request in formal manner?


--B_3430669090_2352173
Content-type: text/html;
	charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable

<HTML>
<HEAD>
<TITLE>Re: [Xen-devel] 4.2.0-rc4 bug: memory events for CR3 register are br=
oken (working in 4.1.3)</TITLE>
</HEAD>
<BODY>
<FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN STYLE=3D'font-size:11pt=
'>Keep an eye on xen-unstable and make sure the patch, or equivalent, goes i=
n in the next week or two. Once it&#8217;s in you can request it be backport=
ed.<BR>
<BR>
&nbsp;-- Keir<BR>
<BR>
On 16/09/2012 19:35, &quot;Navin Patel&quot; &lt;<a href=3D"navinjpatel336@gm=
ail.com">navinjpatel336@gmail.com</a>&gt; wrote:<BR>
<BR>
</SPAN></FONT><BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><=
SPAN STYLE=3D'font-size:11pt'>Keir and Steven, <BR>
<BR>
Thank you for your work. The proposed patch solved the bug! <BR>
<BR>
After 4.2.0 is officially released this week, I very much hope that this pa=
tch is backported to the 4.2.0 tree. Several distributions like Debian are a=
lready building upon 4.2.0 and will not wait for 4.2.1, and without the patc=
h being backported, researchers like me will not be able to use the supporte=
d Xen from package repository.=A0 We can compile from source, but if we have a=
 supported version it is better for everyone. (And it is such a simple patch=
! )<BR>
<BR>
Is this something I can request in formal manner?<BR>
</SPAN></FONT></BLOCKQUOTE>
</BODY>
</HTML>


--B_3430669090_2352173--




--===============3459963200799474924==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============3459963200799474924==--




From xen-devel-bounces@lists.xen.org Sun Sep 16 18:38:38 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 16 Sep 2012 18:38:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDJjT-0007OZ-Jj; Sun, 16 Sep 2012 18:38:15 +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 1TDJjR-0007OU-Mj
	for xen-devel@lists.xen.org; Sun, 16 Sep 2012 18:38:13 +0000
Received: from [85.158.143.35:37973] by server-3.bemta-4.messagelabs.com id
	57/B9-08232-59C16505; Sun, 16 Sep 2012 18:38:13 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1347820692!6771241!1
X-Originating-IP: [74.125.82.41]
X-SpamReason: No, hits=1.7 required=7.0 tests=HTML_20_30,HTML_MESSAGE,
	MAILTO_TO_SPAM_ADDR,MIME_QP_LONG_LINE,RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28130 invoked from network); 16 Sep 2012 18:38:12 -0000
Received: from mail-wg0-f41.google.com (HELO mail-wg0-f41.google.com)
	(74.125.82.41)
	by server-4.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Sep 2012 18:38:12 -0000
Received: by wgbds1 with SMTP id ds1so2391661wgb.2
	for <xen-devel@lists.xen.org>; Sun, 16 Sep 2012 11:38:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type;
	bh=6XwH4sh5ov1SabfAiIwXusImfZdnJrrukV/bm1zc1GY=;
	b=zzV2SIWVPE3jRtjup2czXQ7UwhiFTgIcle9ULnipYXeG+EqaVtuWjczWr6jOra4FaT
	p+7XjwS3oHHdCYNNIcMQ3zPRgwELCGE2l0H3/KuCNkQb7Qk15GUZhqUatb0TqTK56S39
	hgtEU8uOftNx5QZNdK9e3epbosnswhEtCnIja1YrSrcGBg8v1FjNnnfKsafKTkfMwMWC
	K4oPQQTS9+61SutX4Y5NgvVJUh+D+0k9RgTJUJRT4aIzOiNmely4AZ/viwquiT6nng9e
	5CURZzTztjhllEuuVWqCaCi14vz1rdftDz+6ModjL0LWUDdykVYv4TPJwO5s5XOdQ8un
	zJCQ==
Received: by 10.216.147.4 with SMTP id s4mr5148061wej.9.1347820692087;
	Sun, 16 Sep 2012 11:38:12 -0700 (PDT)
Received: from [192.168.1.3] (host86-183-251-65.range86-183.btcentralplus.com.
	[86.183.251.65])
	by mx.google.com with ESMTPS id t8sm13373768wiy.3.2012.09.16.11.38.10
	(version=SSLv3 cipher=OTHER); Sun, 16 Sep 2012 11:38:11 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.33.0.120411
Date: Sun, 16 Sep 2012 19:38:06 +0100
From: Keir Fraser <keir@xen.org>
To: Navin Patel <navinjpatel336@gmail.com>
Message-ID: <CC7BDB1E.4BE20%keir@xen.org>
Thread-Topic: [Xen-devel] 4.2.0-rc4 bug: memory events for CR3 register are
	broken (working in 4.1.3)
Thread-Index: Ac2UOmlXbx0wNl/fLEmMccW8i1yNGw==
In-Reply-To: <CALEYbrhhLsnx_o2kezp+WbR553iwkHRPO7MQ5Nxi27n-ZovvVA@mail.gmail.com>
Mime-version: 1.0
Cc: Steven Maresca <steve@zentific.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] 4.2.0-rc4 bug: memory events for CR3 register are
 broken (working in 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: multipart/mixed; boundary="===============3459963200799474924=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--===============3459963200799474924==
Content-type: multipart/alternative;
	boundary="B_3430669090_2352173"

> This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--B_3430669090_2352173
Content-type: text/plain;
	charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable

Keep an eye on xen-unstable and make sure the patch, or equivalent, goes in
in the next week or two. Once it=B9s in you can request it be backported.

 -- Keir

On 16/09/2012 19:35, "Navin Patel" <navinjpatel336@gmail.com> wrote:

> Keir and Steven,=20
>=20
> Thank you for your work. The proposed patch solved the bug!
>=20
> After 4.2.0 is officially released this week, I very much hope that this =
patch
> is backported to the 4.2.0 tree. Several distributions like Debian are al=
ready
> building upon 4.2.0 and will not wait for 4.2.1, and without the patch be=
ing
> backported, researchers like me will not be able to use the supported Xen=
 from
> package repository.=A0 We can compile from source, but if we have a support=
ed
> version it is better for everyone. (And it is such a simple patch! )
>=20
> Is this something I can request in formal manner?


--B_3430669090_2352173
Content-type: text/html;
	charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable

<HTML>
<HEAD>
<TITLE>Re: [Xen-devel] 4.2.0-rc4 bug: memory events for CR3 register are br=
oken (working in 4.1.3)</TITLE>
</HEAD>
<BODY>
<FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN STYLE=3D'font-size:11pt=
'>Keep an eye on xen-unstable and make sure the patch, or equivalent, goes i=
n in the next week or two. Once it&#8217;s in you can request it be backport=
ed.<BR>
<BR>
&nbsp;-- Keir<BR>
<BR>
On 16/09/2012 19:35, &quot;Navin Patel&quot; &lt;<a href=3D"navinjpatel336@gm=
ail.com">navinjpatel336@gmail.com</a>&gt; wrote:<BR>
<BR>
</SPAN></FONT><BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><=
SPAN STYLE=3D'font-size:11pt'>Keir and Steven, <BR>
<BR>
Thank you for your work. The proposed patch solved the bug! <BR>
<BR>
After 4.2.0 is officially released this week, I very much hope that this pa=
tch is backported to the 4.2.0 tree. Several distributions like Debian are a=
lready building upon 4.2.0 and will not wait for 4.2.1, and without the patc=
h being backported, researchers like me will not be able to use the supporte=
d Xen from package repository.=A0 We can compile from source, but if we have a=
 supported version it is better for everyone. (And it is such a simple patch=
! )<BR>
<BR>
Is this something I can request in formal manner?<BR>
</SPAN></FONT></BLOCKQUOTE>
</BODY>
</HTML>


--B_3430669090_2352173--




--===============3459963200799474924==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============3459963200799474924==--




From xen-devel-bounces@lists.xen.org Sun Sep 16 19:09:42 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 16 Sep 2012 19:09:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDKDV-0007wn-0R; Sun, 16 Sep 2012 19:09:17 +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 1TDKDT-0007wg-SX
	for xen-devel@lists.xen.org; Sun, 16 Sep 2012 19:09:15 +0000
Received: from [85.158.143.35:45217] by server-2.bemta-4.messagelabs.com id
	F0/20-21239-BD326505; Sun, 16 Sep 2012 19:09:15 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-14.tower-21.messagelabs.com!1347822553!18556386!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA1MDQxNzg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9350 invoked from network); 16 Sep 2012 19:09:14 -0000
Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25)
	by server-14.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 16 Sep 2012 19:09:14 -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 D9EE52E95;
	Sun, 16 Sep 2012 22:09:12 +0300 (EEST)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id A52202005D; Sun, 16 Sep 2012 22:09:12 +0300 (EEST)
Date: Sun, 16 Sep 2012 22:09:12 +0300
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: Igor Kozhukhov <ikozhukhov@gmail.com>
Message-ID: <20120916190912.GC8912@reaktio.net>
References: <CC7BE9EE.2D8B7%ikozhukhov@gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CC7BE9EE.2D8B7%ikozhukhov@gmail.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] xen on illumos(OpenSolaris) based platform
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Sun, Sep 16, 2012 at 08:41:19PM +0400, Igor Kozhukhov wrote:
>    hello all!
>

Hello!
 
>    are you interested in port xen-4.1 to illumos(OpenSolaris) based platform?
>    I have found old Sun works with xen-3.4.2 and updated it to xen-3.4.4
>    I'll try to port xen-4.1.
> 

Nice to hear you're working on Xen on Illumos! 

Does the Illumos kernel still run as dom0 properly? 

>    can I file a bugs with issues on solaris based platform?
>    where can I file a bugs - I have bout some issues and I'd like to provide
>    fixes for solaris.
> 

I think you should follow the usual Xen development workflow; post patches
against xen-unstable, and when those patches are merged to xen-unstable, 
they can be considered for backports to stable branches (4.2, 4.1).

Thanks!

-- Pasi


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Sep 16 19:09:42 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 16 Sep 2012 19:09:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDKDV-0007wn-0R; Sun, 16 Sep 2012 19:09:17 +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 1TDKDT-0007wg-SX
	for xen-devel@lists.xen.org; Sun, 16 Sep 2012 19:09:15 +0000
Received: from [85.158.143.35:45217] by server-2.bemta-4.messagelabs.com id
	F0/20-21239-BD326505; Sun, 16 Sep 2012 19:09:15 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-14.tower-21.messagelabs.com!1347822553!18556386!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA1MDQxNzg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9350 invoked from network); 16 Sep 2012 19:09:14 -0000
Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25)
	by server-14.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 16 Sep 2012 19:09:14 -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 D9EE52E95;
	Sun, 16 Sep 2012 22:09:12 +0300 (EEST)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id A52202005D; Sun, 16 Sep 2012 22:09:12 +0300 (EEST)
Date: Sun, 16 Sep 2012 22:09:12 +0300
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: Igor Kozhukhov <ikozhukhov@gmail.com>
Message-ID: <20120916190912.GC8912@reaktio.net>
References: <CC7BE9EE.2D8B7%ikozhukhov@gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CC7BE9EE.2D8B7%ikozhukhov@gmail.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] xen on illumos(OpenSolaris) based platform
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Sun, Sep 16, 2012 at 08:41:19PM +0400, Igor Kozhukhov wrote:
>    hello all!
>

Hello!
 
>    are you interested in port xen-4.1 to illumos(OpenSolaris) based platform?
>    I have found old Sun works with xen-3.4.2 and updated it to xen-3.4.4
>    I'll try to port xen-4.1.
> 

Nice to hear you're working on Xen on Illumos! 

Does the Illumos kernel still run as dom0 properly? 

>    can I file a bugs with issues on solaris based platform?
>    where can I file a bugs - I have bout some issues and I'd like to provide
>    fixes for solaris.
> 

I think you should follow the usual Xen development workflow; post patches
against xen-unstable, and when those patches are merged to xen-unstable, 
they can be considered for backports to stable branches (4.2, 4.1).

Thanks!

-- Pasi


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Sep 16 20:01:42 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 16 Sep 2012 20:01: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 1TDL1n-0000R0-3s; Sun, 16 Sep 2012 20:01:15 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ikozhukhov@gmail.com>) id 1TDL1l-0000Qv-3b
	for xen-devel@lists.xen.org; Sun, 16 Sep 2012 20:01:13 +0000
Received: from [85.158.137.99:48798] by server-8.bemta-3.messagelabs.com id
	E8/47-24700-80036505; Sun, 16 Sep 2012 20:01:12 +0000
X-Env-Sender: ikozhukhov@gmail.com
X-Msg-Ref: server-9.tower-217.messagelabs.com!1347825671!14728708!1
X-Originating-IP: [209.85.217.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15574 invoked from network); 16 Sep 2012 20:01:11 -0000
Received: from mail-lb0-f173.google.com (HELO mail-lb0-f173.google.com)
	(209.85.217.173)
	by server-9.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Sep 2012 20:01:11 -0000
Received: by lbbgm13 with SMTP id gm13so4595495lbb.32
	for <xen-devel@lists.xen.org>; Sun, 16 Sep 2012 13:01: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:cc:message-id:thread-topic
	:in-reply-to:mime-version:content-type:content-transfer-encoding;
	bh=oZQ4D7cYOqHK7WcS36lLSbq76qUURrp0Yiy3E0ZdFAQ=;
	b=aRclDI2PsmFExiLi86KfTZfEdq61yQaiS6sZg8JsqhXmcfMp93RImyUn17aPWzt+RL
	NjOYA4GF0wdEKn6XLoNDkv1Cn/mxe+brDTTFCEzeY+CVwbZKMqHEArGT01H3Bh0JuBhR
	MNBo0NNLVIqNX0B/FSzu9z+1lrESW7vPYuKf3m+wOPv5IC67hK3qJcM++q0DqwXvfaYf
	+DU3lB+4/ebj1uL2na2oG5gwh1TOtK8rbMg8wyngs4dS90DQskp8AJn0v1VZTVFHQtvD
	NDmxo/Is6NvBgcpFWUQDDPbk7Lv4gFMc7Wk6YqrJcIssqJQQOAx9xgO5asUY43/JcpMF
	B5Ww==
Received: by 10.152.104.44 with SMTP id gb12mr7950843lab.29.1347825670855;
	Sun, 16 Sep 2012 13:01:10 -0700 (PDT)
Received: from [172.16.90.16] ([91.204.58.44])
	by mx.google.com with ESMTPS id sn2sm2326994lab.16.2012.09.16.13.01.08
	(version=SSLv3 cipher=OTHER); Sun, 16 Sep 2012 13:01:09 -0700 (PDT)
User-Agent: Microsoft-MacOutlook/14.2.3.120616
Date: Mon, 17 Sep 2012 00:00:54 +0400
From: Igor Kozhukhov <ikozhukhov@gmail.com>
To: Pasi =?ISO-8859-1?B?S+Rya2vkaW5lbg==?= <pasik@iki.fi>
Message-ID: <CC7C1783.2D8D5%ikozhukhov@gmail.com>
Thread-Topic: [Xen-devel] xen on illumos(OpenSolaris) based platform
In-Reply-To: <20120916190912.GC8912@reaktio.net>
Mime-version: 1.0
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] xen on illumos(OpenSolaris) based platform
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hello Pasi,

Yes - illumos is working as dom0 - I have tested it on my illumos based
platform - http://www.dilos.org.
I have tested with xen-3.4.4.

I have installed and started CentOS 5.8 as guest, and original DilOS iso -
paravirt.

I have problems with Debian 6, but I think it is scripting problem with
grub2 - with pygrub.

I hope xen-4.1 will be better.

Could you please point me to the Xen development workflow - where can I
find how to do it ?
I'll try to learn and contribute.

---
Best regards,
Igor Kozhukhov
IRC# igork




On 9/16/12 11:09 PM, "Pasi K=E4rkk=E4inen" <pasik@iki.fi> wrote:

>On Sun, Sep 16, 2012 at 08:41:19PM +0400, Igor Kozhukhov wrote:
>>    hello all!
>>
>
>Hello!
> =

>>    are you interested in port xen-4.1 to illumos(OpenSolaris) based
>>platform?
>>    I have found old Sun works with xen-3.4.2 and updated it to xen-3.4.4
>>    I'll try to port xen-4.1.
>> =

>
>Nice to hear you're working on Xen on Illumos!
>
>Does the Illumos kernel still run as dom0 properly?
>
>>    can I file a bugs with issues on solaris based platform?
>>    where can I file a bugs - I have bout some issues and I'd like to
>>provide
>>    fixes for solaris.
>> =

>
>I think you should follow the usual Xen development workflow; post patches
>against xen-unstable, and when those patches are merged to xen-unstable,
>they can be considered for backports to stable branches (4.2, 4.1).
>
>Thanks!
>
>-- Pasi
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Sep 16 20:01:42 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 16 Sep 2012 20:01: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 1TDL1n-0000R0-3s; Sun, 16 Sep 2012 20:01:15 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ikozhukhov@gmail.com>) id 1TDL1l-0000Qv-3b
	for xen-devel@lists.xen.org; Sun, 16 Sep 2012 20:01:13 +0000
Received: from [85.158.137.99:48798] by server-8.bemta-3.messagelabs.com id
	E8/47-24700-80036505; Sun, 16 Sep 2012 20:01:12 +0000
X-Env-Sender: ikozhukhov@gmail.com
X-Msg-Ref: server-9.tower-217.messagelabs.com!1347825671!14728708!1
X-Originating-IP: [209.85.217.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15574 invoked from network); 16 Sep 2012 20:01:11 -0000
Received: from mail-lb0-f173.google.com (HELO mail-lb0-f173.google.com)
	(209.85.217.173)
	by server-9.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Sep 2012 20:01:11 -0000
Received: by lbbgm13 with SMTP id gm13so4595495lbb.32
	for <xen-devel@lists.xen.org>; Sun, 16 Sep 2012 13:01: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:cc:message-id:thread-topic
	:in-reply-to:mime-version:content-type:content-transfer-encoding;
	bh=oZQ4D7cYOqHK7WcS36lLSbq76qUURrp0Yiy3E0ZdFAQ=;
	b=aRclDI2PsmFExiLi86KfTZfEdq61yQaiS6sZg8JsqhXmcfMp93RImyUn17aPWzt+RL
	NjOYA4GF0wdEKn6XLoNDkv1Cn/mxe+brDTTFCEzeY+CVwbZKMqHEArGT01H3Bh0JuBhR
	MNBo0NNLVIqNX0B/FSzu9z+1lrESW7vPYuKf3m+wOPv5IC67hK3qJcM++q0DqwXvfaYf
	+DU3lB+4/ebj1uL2na2oG5gwh1TOtK8rbMg8wyngs4dS90DQskp8AJn0v1VZTVFHQtvD
	NDmxo/Is6NvBgcpFWUQDDPbk7Lv4gFMc7Wk6YqrJcIssqJQQOAx9xgO5asUY43/JcpMF
	B5Ww==
Received: by 10.152.104.44 with SMTP id gb12mr7950843lab.29.1347825670855;
	Sun, 16 Sep 2012 13:01:10 -0700 (PDT)
Received: from [172.16.90.16] ([91.204.58.44])
	by mx.google.com with ESMTPS id sn2sm2326994lab.16.2012.09.16.13.01.08
	(version=SSLv3 cipher=OTHER); Sun, 16 Sep 2012 13:01:09 -0700 (PDT)
User-Agent: Microsoft-MacOutlook/14.2.3.120616
Date: Mon, 17 Sep 2012 00:00:54 +0400
From: Igor Kozhukhov <ikozhukhov@gmail.com>
To: Pasi =?ISO-8859-1?B?S+Rya2vkaW5lbg==?= <pasik@iki.fi>
Message-ID: <CC7C1783.2D8D5%ikozhukhov@gmail.com>
Thread-Topic: [Xen-devel] xen on illumos(OpenSolaris) based platform
In-Reply-To: <20120916190912.GC8912@reaktio.net>
Mime-version: 1.0
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] xen on illumos(OpenSolaris) based platform
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hello Pasi,

Yes - illumos is working as dom0 - I have tested it on my illumos based
platform - http://www.dilos.org.
I have tested with xen-3.4.4.

I have installed and started CentOS 5.8 as guest, and original DilOS iso -
paravirt.

I have problems with Debian 6, but I think it is scripting problem with
grub2 - with pygrub.

I hope xen-4.1 will be better.

Could you please point me to the Xen development workflow - where can I
find how to do it ?
I'll try to learn and contribute.

---
Best regards,
Igor Kozhukhov
IRC# igork




On 9/16/12 11:09 PM, "Pasi K=E4rkk=E4inen" <pasik@iki.fi> wrote:

>On Sun, Sep 16, 2012 at 08:41:19PM +0400, Igor Kozhukhov wrote:
>>    hello all!
>>
>
>Hello!
> =

>>    are you interested in port xen-4.1 to illumos(OpenSolaris) based
>>platform?
>>    I have found old Sun works with xen-3.4.2 and updated it to xen-3.4.4
>>    I'll try to port xen-4.1.
>> =

>
>Nice to hear you're working on Xen on Illumos!
>
>Does the Illumos kernel still run as dom0 properly?
>
>>    can I file a bugs with issues on solaris based platform?
>>    where can I file a bugs - I have bout some issues and I'd like to
>>provide
>>    fixes for solaris.
>> =

>
>I think you should follow the usual Xen development workflow; post patches
>against xen-unstable, and when those patches are merged to xen-unstable,
>they can be considered for backports to stable branches (4.2, 4.1).
>
>Thanks!
>
>-- Pasi
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Sep 16 21:02:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 16 Sep 2012 21:02:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDLyN-0001Od-28; Sun, 16 Sep 2012 21:01:47 +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 1TDLyL-0001OY-Rq
	for xen-devel@lists.xen.org; Sun, 16 Sep 2012 21:01:46 +0000
Received: from [85.158.137.99:52307] by server-8.bemta-3.messagelabs.com id
	37/EC-24700-93E36505; Sun, 16 Sep 2012 21:01:45 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-14.tower-217.messagelabs.com!1347829304!17874907!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA1MDQxNzg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23397 invoked from network); 16 Sep 2012 21:01:44 -0000
Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25)
	by server-14.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 16 Sep 2012 21:01:44 -0000
X-Originating-Ip: [194.89.68.22]
Received: from ydin.reaktio.net (reaktio.net [194.89.68.22])
	by smtp.tele.fi (Postfix) with ESMTP id 1B0EF1DFC;
	Mon, 17 Sep 2012 00:01:43 +0300 (EEST)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id 9C0642005D; Mon, 17 Sep 2012 00:01:42 +0300 (EEST)
Date: Mon, 17 Sep 2012 00:01:42 +0300
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: Igor Kozhukhov <ikozhukhov@gmail.com>
Message-ID: <20120916210142.GD8912@reaktio.net>
References: <20120916190912.GC8912@reaktio.net>
	<CC7C1783.2D8D5%ikozhukhov@gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CC7C1783.2D8D5%ikozhukhov@gmail.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] xen on illumos(OpenSolaris) based platform
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Sep 17, 2012 at 12:00:54AM +0400, Igor Kozhukhov wrote:
> Hello Pasi,
> =

> Yes - illumos is working as dom0 - I have tested it on my illumos based
> platform - http://www.dilos.org.
> I have tested with xen-3.4.4.
> =


Nice!

> I have installed and started CentOS 5.8 as guest, and original DilOS iso -
> paravirt.
>

Ok.
 =

> I have problems with Debian 6, but I think it is scripting problem with
> grub2 - with pygrub.
> =


Yep, Xen 3.4 doesn't have pygrub grub2 support. Xen 4.1.3 (and later versio=
ns) do have it.

> I hope xen-4.1 will be better.
> =


It will.

> Could you please point me to the Xen development workflow - where can I
> find how to do it ?
> I'll try to learn and contribute.
> =


Just use mercurial to fetch xen-unstable:
hg clone http://xenbits.xen.org/xen-unstable.hg

To send/submit patches against xen-unstable:
http://wiki.xen.org/wiki/Submitting_Xen_Patches

Also if you want, you can write documentation about Xen+Illumos on wiki.xen=
.org.
Hopefully that helps,

-- Pasi


> ---
> Best regards,
> Igor Kozhukhov
> IRC# igork
> =

> =

> =

> =

> On 9/16/12 11:09 PM, "Pasi K=E4rkk=E4inen" <pasik@iki.fi> wrote:
> =

> >On Sun, Sep 16, 2012 at 08:41:19PM +0400, Igor Kozhukhov wrote:
> >>    hello all!
> >>
> >
> >Hello!
> > =

> >>    are you interested in port xen-4.1 to illumos(OpenSolaris) based
> >>platform?
> >>    I have found old Sun works with xen-3.4.2 and updated it to xen-3.4=
.4
> >>    I'll try to port xen-4.1.
> >> =

> >
> >Nice to hear you're working on Xen on Illumos!
> >
> >Does the Illumos kernel still run as dom0 properly?
> >
> >>    can I file a bugs with issues on solaris based platform?
> >>    where can I file a bugs - I have bout some issues and I'd like to
> >>provide
> >>    fixes for solaris.
> >> =

> >
> >I think you should follow the usual Xen development workflow; post patch=
es
> >against xen-unstable, and when those patches are merged to xen-unstable,
> >they can be considered for backports to stable branches (4.2, 4.1).
> >
> >Thanks!
> >
> >-- Pasi
> >
> =

> =


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Sep 16 21:02:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 16 Sep 2012 21:02:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDLyN-0001Od-28; Sun, 16 Sep 2012 21:01:47 +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 1TDLyL-0001OY-Rq
	for xen-devel@lists.xen.org; Sun, 16 Sep 2012 21:01:46 +0000
Received: from [85.158.137.99:52307] by server-8.bemta-3.messagelabs.com id
	37/EC-24700-93E36505; Sun, 16 Sep 2012 21:01:45 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-14.tower-217.messagelabs.com!1347829304!17874907!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA1MDQxNzg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23397 invoked from network); 16 Sep 2012 21:01:44 -0000
Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25)
	by server-14.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 16 Sep 2012 21:01:44 -0000
X-Originating-Ip: [194.89.68.22]
Received: from ydin.reaktio.net (reaktio.net [194.89.68.22])
	by smtp.tele.fi (Postfix) with ESMTP id 1B0EF1DFC;
	Mon, 17 Sep 2012 00:01:43 +0300 (EEST)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id 9C0642005D; Mon, 17 Sep 2012 00:01:42 +0300 (EEST)
Date: Mon, 17 Sep 2012 00:01:42 +0300
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: Igor Kozhukhov <ikozhukhov@gmail.com>
Message-ID: <20120916210142.GD8912@reaktio.net>
References: <20120916190912.GC8912@reaktio.net>
	<CC7C1783.2D8D5%ikozhukhov@gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CC7C1783.2D8D5%ikozhukhov@gmail.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] xen on illumos(OpenSolaris) based platform
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Sep 17, 2012 at 12:00:54AM +0400, Igor Kozhukhov wrote:
> Hello Pasi,
> =

> Yes - illumos is working as dom0 - I have tested it on my illumos based
> platform - http://www.dilos.org.
> I have tested with xen-3.4.4.
> =


Nice!

> I have installed and started CentOS 5.8 as guest, and original DilOS iso -
> paravirt.
>

Ok.
 =

> I have problems with Debian 6, but I think it is scripting problem with
> grub2 - with pygrub.
> =


Yep, Xen 3.4 doesn't have pygrub grub2 support. Xen 4.1.3 (and later versio=
ns) do have it.

> I hope xen-4.1 will be better.
> =


It will.

> Could you please point me to the Xen development workflow - where can I
> find how to do it ?
> I'll try to learn and contribute.
> =


Just use mercurial to fetch xen-unstable:
hg clone http://xenbits.xen.org/xen-unstable.hg

To send/submit patches against xen-unstable:
http://wiki.xen.org/wiki/Submitting_Xen_Patches

Also if you want, you can write documentation about Xen+Illumos on wiki.xen=
.org.
Hopefully that helps,

-- Pasi


> ---
> Best regards,
> Igor Kozhukhov
> IRC# igork
> =

> =

> =

> =

> On 9/16/12 11:09 PM, "Pasi K=E4rkk=E4inen" <pasik@iki.fi> wrote:
> =

> >On Sun, Sep 16, 2012 at 08:41:19PM +0400, Igor Kozhukhov wrote:
> >>    hello all!
> >>
> >
> >Hello!
> > =

> >>    are you interested in port xen-4.1 to illumos(OpenSolaris) based
> >>platform?
> >>    I have found old Sun works with xen-3.4.2 and updated it to xen-3.4=
.4
> >>    I'll try to port xen-4.1.
> >> =

> >
> >Nice to hear you're working on Xen on Illumos!
> >
> >Does the Illumos kernel still run as dom0 properly?
> >
> >>    can I file a bugs with issues on solaris based platform?
> >>    where can I file a bugs - I have bout some issues and I'd like to
> >>provide
> >>    fixes for solaris.
> >> =

> >
> >I think you should follow the usual Xen development workflow; post patch=
es
> >against xen-unstable, and when those patches are merged to xen-unstable,
> >they can be considered for backports to stable branches (4.2, 4.1).
> >
> >Thanks!
> >
> >-- Pasi
> >
> =

> =


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Sep 16 21:23:38 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 16 Sep 2012 21:23:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDMJ5-0001gX-V0; Sun, 16 Sep 2012 21:23:11 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1TDMJ5-0001gS-42
	for xen-devel@lists.xensource.com; Sun, 16 Sep 2012 21:23:11 +0000
Received: from [85.158.143.35:6418] by server-3.bemta-4.messagelabs.com id
	AA/B1-08232-E3346505; Sun, 16 Sep 2012 21:23:10 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1347830589!6780348!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDk2MzE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7992 invoked from network); 16 Sep 2012 21:23:09 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Sep 2012 21:23:09 -0000
X-IronPort-AV: E=Sophos;i="4.80,431,1344211200"; d="scan'208";a="14567205"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Sep 2012 21:23: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.279.1; Sun, 16 Sep 2012 22:23: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 1TDMJ2-0003Ue-Et;
	Sun, 16 Sep 2012 21:23:08 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1TDMJ2-0003yy-At;
	Sun, 16 Sep 2012 22:23:08 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-13787-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sun, 16 Sep 2012 22:23:08 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [qemu-upstream-4.2-testing baseline test] 13787:
	tolerable FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

"Old" tested version had not actually been tested; therefore in this
flight we test it, rather than a new candidate.  The baseline, if
any, is the most recent actually tested revision.

flight 13787 qemu-upstream-4.2-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13787/

Failures :-/ but no regressions.

Tests which did not succeed,
including tests which could not be run:
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  9 guest-localmigrate fail never pass
 test-amd64-amd64-qemuu-win   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64  9 guest-localmigrate      fail never pass
 test-amd64-i386-xl-qemuu-win-vcpus1  9 guest-localmigrate      fail never pass
 test-amd64-i386-xend-qemuu-winxpsp3 16 leak-check/check        fail never pass
 test-i386-i386-qemuu-win     16 leak-check/check             fail   never pass
 test-amd64-i386-qemuu-win-vcpus1 16 leak-check/check           fail never pass
 test-i386-i386-xl-qemuu-win   9 guest-localmigrate           fail   never pass
 test-amd64-i386-qemuu-win    16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemuu-win  9 guest-localmigrate           fail  never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail never pass
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass


jobs:
 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                           pass    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-win-vcpus1                             fail    
 test-amd64-i386-xl-qemuu-win-vcpus1                          fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-amd64-qemuu-win                                   fail    
 test-amd64-i386-qemuu-win                                    fail    
 test-i386-i386-qemuu-win                                     fail    
 test-amd64-amd64-xl-qemuu-win                                fail    
 test-i386-i386-xl-qemuu-win                                  fail    
 test-amd64-i386-xend-qemuu-winxpsp3                          fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


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 Sep 16 21:23:38 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 16 Sep 2012 21:23:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDMJ5-0001gX-V0; Sun, 16 Sep 2012 21:23:11 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1TDMJ5-0001gS-42
	for xen-devel@lists.xensource.com; Sun, 16 Sep 2012 21:23:11 +0000
Received: from [85.158.143.35:6418] by server-3.bemta-4.messagelabs.com id
	AA/B1-08232-E3346505; Sun, 16 Sep 2012 21:23:10 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1347830589!6780348!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDk2MzE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7992 invoked from network); 16 Sep 2012 21:23:09 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Sep 2012 21:23:09 -0000
X-IronPort-AV: E=Sophos;i="4.80,431,1344211200"; d="scan'208";a="14567205"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Sep 2012 21:23: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.279.1; Sun, 16 Sep 2012 22:23: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 1TDMJ2-0003Ue-Et;
	Sun, 16 Sep 2012 21:23:08 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1TDMJ2-0003yy-At;
	Sun, 16 Sep 2012 22:23:08 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-13787-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sun, 16 Sep 2012 22:23:08 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [qemu-upstream-4.2-testing baseline test] 13787:
	tolerable FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

"Old" tested version had not actually been tested; therefore in this
flight we test it, rather than a new candidate.  The baseline, if
any, is the most recent actually tested revision.

flight 13787 qemu-upstream-4.2-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13787/

Failures :-/ but no regressions.

Tests which did not succeed,
including tests which could not be run:
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  9 guest-localmigrate fail never pass
 test-amd64-amd64-qemuu-win   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64  9 guest-localmigrate      fail never pass
 test-amd64-i386-xl-qemuu-win-vcpus1  9 guest-localmigrate      fail never pass
 test-amd64-i386-xend-qemuu-winxpsp3 16 leak-check/check        fail never pass
 test-i386-i386-qemuu-win     16 leak-check/check             fail   never pass
 test-amd64-i386-qemuu-win-vcpus1 16 leak-check/check           fail never pass
 test-i386-i386-xl-qemuu-win   9 guest-localmigrate           fail   never pass
 test-amd64-i386-qemuu-win    16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemuu-win  9 guest-localmigrate           fail  never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail never pass
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass


jobs:
 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                           pass    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-win-vcpus1                             fail    
 test-amd64-i386-xl-qemuu-win-vcpus1                          fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-amd64-qemuu-win                                   fail    
 test-amd64-i386-qemuu-win                                    fail    
 test-i386-i386-qemuu-win                                     fail    
 test-amd64-amd64-xl-qemuu-win                                fail    
 test-i386-i386-xl-qemuu-win                                  fail    
 test-amd64-i386-xend-qemuu-winxpsp3                          fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


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 Sep 17 01:46:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 01:46: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 1TDQPt-0007xd-H4; Mon, 17 Sep 2012 01:46:29 +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 1TDQPl-0007x8-Mc
	for xen-devel@lists.xensource.com; Mon, 17 Sep 2012 01:46:28 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1347846372!9272215!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDk2Mzg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14493 invoked from network); 17 Sep 2012 01:46:12 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Sep 2012 01:46:12 -0000
X-IronPort-AV: E=Sophos;i="4.80,432,1344211200"; d="scan'208";a="14568737"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Sep 2012 01:46: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.279.1; Mon, 17 Sep 2012 02:46:01 +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 1TDQPR-0004um-3q;
	Mon, 17 Sep 2012 01:46:01 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1TDQPQ-0002z8-GH;
	Mon, 17 Sep 2012 02:46:00 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-13789-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Mon, 17 Sep 2012 02:46:00 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [qemu-upstream-4.2-testing baseline test] 13789:
	tolerable FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

"Old" tested version had not actually been tested; therefore in this
flight we test it, rather than a new candidate.  The baseline, if
any, is the most recent actually tested revision.

flight 13789 qemu-upstream-4.2-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13789/

Failures :-/ but no regressions.

Tests which did not succeed,
including tests which could not be run:
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  9 guest-localmigrate fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail never pass
 test-amd64-amd64-qemuu-win   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-qemuu-win-vcpus1  9 guest-localmigrate      fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64  9 guest-localmigrate      fail never pass
 test-i386-i386-qemuu-win     16 leak-check/check             fail   never pass
 test-amd64-i386-qemuu-win-vcpus1 16 leak-check/check           fail never pass
 test-i386-i386-xl-qemuu-win   9 guest-localmigrate           fail   never pass
 test-amd64-i386-xend-qemuu-winxpsp3 16 leak-check/check        fail never pass
 test-amd64-i386-qemuu-win    16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemuu-win  9 guest-localmigrate           fail  never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail never pass
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass


jobs:
 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                           pass    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-win-vcpus1                             fail    
 test-amd64-i386-xl-qemuu-win-vcpus1                          fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-amd64-qemuu-win                                   fail    
 test-amd64-i386-qemuu-win                                    fail    
 test-i386-i386-qemuu-win                                     fail    
 test-amd64-amd64-xl-qemuu-win                                fail    
 test-i386-i386-xl-qemuu-win                                  fail    
 test-amd64-i386-xend-qemuu-winxpsp3                          fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


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 Sep 17 01:46:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 01:46: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 1TDQPt-0007xd-H4; Mon, 17 Sep 2012 01:46:29 +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 1TDQPl-0007x8-Mc
	for xen-devel@lists.xensource.com; Mon, 17 Sep 2012 01:46:28 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1347846372!9272215!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDk2Mzg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14493 invoked from network); 17 Sep 2012 01:46:12 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Sep 2012 01:46:12 -0000
X-IronPort-AV: E=Sophos;i="4.80,432,1344211200"; d="scan'208";a="14568737"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Sep 2012 01:46: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.279.1; Mon, 17 Sep 2012 02:46:01 +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 1TDQPR-0004um-3q;
	Mon, 17 Sep 2012 01:46:01 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1TDQPQ-0002z8-GH;
	Mon, 17 Sep 2012 02:46:00 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-13789-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Mon, 17 Sep 2012 02:46:00 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [qemu-upstream-4.2-testing baseline test] 13789:
	tolerable FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

"Old" tested version had not actually been tested; therefore in this
flight we test it, rather than a new candidate.  The baseline, if
any, is the most recent actually tested revision.

flight 13789 qemu-upstream-4.2-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13789/

Failures :-/ but no regressions.

Tests which did not succeed,
including tests which could not be run:
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  9 guest-localmigrate fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail never pass
 test-amd64-amd64-qemuu-win   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-qemuu-win-vcpus1  9 guest-localmigrate      fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64  9 guest-localmigrate      fail never pass
 test-i386-i386-qemuu-win     16 leak-check/check             fail   never pass
 test-amd64-i386-qemuu-win-vcpus1 16 leak-check/check           fail never pass
 test-i386-i386-xl-qemuu-win   9 guest-localmigrate           fail   never pass
 test-amd64-i386-xend-qemuu-winxpsp3 16 leak-check/check        fail never pass
 test-amd64-i386-qemuu-win    16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemuu-win  9 guest-localmigrate           fail  never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail never pass
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass


jobs:
 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                           pass    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-win-vcpus1                             fail    
 test-amd64-i386-xl-qemuu-win-vcpus1                          fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-amd64-qemuu-win                                   fail    
 test-amd64-i386-qemuu-win                                    fail    
 test-i386-i386-qemuu-win                                     fail    
 test-amd64-amd64-xl-qemuu-win                                fail    
 test-i386-i386-xl-qemuu-win                                  fail    
 test-amd64-i386-xend-qemuu-winxpsp3                          fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


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 Sep 17 03:21:19 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 03:21:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDRtG-000283-Sc; Mon, 17 Sep 2012 03:20:54 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ShengGe.Ding@amd.com>) id 1TDRtF-00027x-Kj
	for xen-devel@lists.xen.org; Mon, 17 Sep 2012 03:20:53 +0000
Received: from [85.158.143.99:24946] by server-3.bemta-4.messagelabs.com id
	94/95-08232-41796505; Mon, 17 Sep 2012 03:20:52 +0000
X-Env-Sender: ShengGe.Ding@amd.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1347852051!20814326!1
X-Originating-IP: [213.199.154.140]
X-SpamReason: No, hits=0.0 required=7.0 tests=HTML_MESSAGE
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16569 invoked from network); 17 Sep 2012 03:20:52 -0000
Received: from db3ehsobe002.messaging.microsoft.com (HELO
	db3outboundpool.messaging.microsoft.com) (213.199.154.140)
	by server-8.tower-216.messagelabs.com with AES128-SHA encrypted SMTP;
	17 Sep 2012 03:20:52 -0000
Received: from mail28-db3-R.bigfish.com (10.3.81.229) by
	DB3EHSOBE008.bigfish.com (10.3.84.28) with Microsoft SMTP Server id
	14.1.225.23; Mon, 17 Sep 2012 03:20:51 +0000
Received: from mail28-db3 (localhost [127.0.0.1])	by mail28-db3-R.bigfish.com
	(Postfix) with ESMTP id 73BDC46013C	for <xen-devel@lists.xen.org>;
	Mon, 17 Sep 2012 03:20:51 +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(zzc85fh103dK14ffIzz1202h1d1ah1d2ahzz17326ah8275bh8275dhz2dh668h839hd25hf0ah107ah1288h12a5h12bdh1155h)
Received: from mail28-db3 (localhost.localdomain [127.0.0.1]) by mail28-db3
	(MessageSwitch) id 1347852049400162_5007;
	Mon, 17 Sep 2012 03:20:49 +0000 (UTC)
Received: from DB3EHSMHS002.bigfish.com (unknown [10.3.81.236])	by
	mail28-db3.bigfish.com (Postfix) with ESMTP id 4686442005C	for
	<xen-devel@lists.xen.org>; Mon, 17 Sep 2012 03:20:49 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	DB3EHSMHS002.bigfish.com (10.3.87.102) with Microsoft SMTP Server id
	14.1.225.23; Mon, 17 Sep 2012 03:20:48 +0000
X-WSS-ID: 0MAH5AK-02-18Z-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 2001FC80E3	for <xen-devel@lists.xen.org>; Sun, 16 Sep 2012
	22:20:43 -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;
	Sun, 16 Sep 2012 22:20:42 -0500
Received: from SCYBEXDAG01.amd.com (10.34.11.11) by sausexdag04.amd.com
	(163.181.55.4) with Microsoft SMTP Server (TLS) id 14.1.323.3;
	Sun, 16 Sep 2012 22:20:30 -0500
Received: from SCYBEXDAG03.amd.com ([169.254.3.3]) by SCYBEXDAG01.amd.com
	([169.254.1.82]) with mapi id 14.01.0323.003;
	Mon, 17 Sep 2012 11:20:28 +0800
From: "Ding, ShengGe" <ShengGe.Ding@amd.com>
To: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Thread-Topic: dom0 crashes while domain_pause in NPF handler
Thread-Index: Ac2Ug2IAr2Bf1LiASnmtzqjgJoXf9g==
Date: Mon, 17 Sep 2012 03:20:27 +0000
Message-ID: <4DEE49724F3FA0438F8949D4497F451A05620957@SCYBEXDAG03.amd.com>
Accept-Language: zh-CN, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.237.74.37]
MIME-Version: 1.0
X-OriginatorOrg: amd.com
Subject: [Xen-devel] dom0 crashes while domain_pause in NPF handler
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1436227261654024862=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============1436227261654024862==
Content-Language: en-US
Content-Type: multipart/alternative;
	boundary="_000_4DEE49724F3FA0438F8949D4497F451A05620957SCYBEXDAG03amdc_"

--_000_4DEE49724F3FA0438F8949D4497F451A05620957SCYBEXDAG03amdc_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi all,

I ran into trouble on nested page fault handling.

I removed p2m entries of passthrough type via clear_mmio_p2m_entry() to unm=
ap mmio space of passthough HW.
Then the nested page fault of physical mmio space can be trapped and the do=
mU can be paused here via domain_pause().

These are fine in xen-4.1.1 with debian patch(ubuntu).
But while I try to port them to xen-unstable version, the dom0 crashes.

The paused domain is absolutely domU. Is there any new restriction in NPF h=
andler in unstable version?

Thanks!
ShengGe

--_000_4DEE49724F3FA0438F8949D4497F451A05620957SCYBEXDAG03amdc_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:=
//www.w3.org/TR/REC-html40">
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"=
>
<meta name=3D"Generator" content=3D"Microsoft Word 12 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
	{font-family:SimSun;
	panose-1:2 1 6 0 3 1 1 1 1 1;}
@font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:SimSun;
	panose-1:2 1 6 0 3 1 1 1 1 1;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal-compose;
	font-family:"Calibri","sans-serif";
	color:windowtext;}
.MsoChpDefault
	{mso-style-type:export-only;}
@page WordSection1
	{size:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;}
div.WordSection1
	{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang=3D"EN-US" link=3D"blue" vlink=3D"purple">
<div class=3D"WordSection1">
<p class=3D"MsoNormal">Hi all,<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal">I ran into trouble on nested page fault handling.<o:=
p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal">I removed p2m entries of passthrough type via clear_=
mmio_p2m_entry() to unmap mmio space of passthough HW.<o:p></o:p></p>
<p class=3D"MsoNormal">Then the nested page fault of physical mmio space ca=
n be trapped and the domU can be paused here via domain_pause().<o:p></o:p>=
</p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal">These are fine in xen-4.1.1 with debian patch(ubuntu=
). <o:p>
</o:p></p>
<p class=3D"MsoNormal">But while I try to port them to xen-unstable version=
, the dom0 crashes.<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal">The paused domain is absolutely domU. Is there any n=
ew restriction in NPF handler in unstable version?<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal">Thanks!<o:p></o:p></p>
<p class=3D"MsoNormal">ShengGe<o:p></o:p></p>
</div>
</body>
</html>

--_000_4DEE49724F3FA0438F8949D4497F451A05620957SCYBEXDAG03amdc_--


--===============1436227261654024862==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============1436227261654024862==--


From xen-devel-bounces@lists.xen.org Mon Sep 17 03:21:19 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 03:21:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDRtG-000283-Sc; Mon, 17 Sep 2012 03:20:54 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ShengGe.Ding@amd.com>) id 1TDRtF-00027x-Kj
	for xen-devel@lists.xen.org; Mon, 17 Sep 2012 03:20:53 +0000
Received: from [85.158.143.99:24946] by server-3.bemta-4.messagelabs.com id
	94/95-08232-41796505; Mon, 17 Sep 2012 03:20:52 +0000
X-Env-Sender: ShengGe.Ding@amd.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1347852051!20814326!1
X-Originating-IP: [213.199.154.140]
X-SpamReason: No, hits=0.0 required=7.0 tests=HTML_MESSAGE
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16569 invoked from network); 17 Sep 2012 03:20:52 -0000
Received: from db3ehsobe002.messaging.microsoft.com (HELO
	db3outboundpool.messaging.microsoft.com) (213.199.154.140)
	by server-8.tower-216.messagelabs.com with AES128-SHA encrypted SMTP;
	17 Sep 2012 03:20:52 -0000
Received: from mail28-db3-R.bigfish.com (10.3.81.229) by
	DB3EHSOBE008.bigfish.com (10.3.84.28) with Microsoft SMTP Server id
	14.1.225.23; Mon, 17 Sep 2012 03:20:51 +0000
Received: from mail28-db3 (localhost [127.0.0.1])	by mail28-db3-R.bigfish.com
	(Postfix) with ESMTP id 73BDC46013C	for <xen-devel@lists.xen.org>;
	Mon, 17 Sep 2012 03:20:51 +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(zzc85fh103dK14ffIzz1202h1d1ah1d2ahzz17326ah8275bh8275dhz2dh668h839hd25hf0ah107ah1288h12a5h12bdh1155h)
Received: from mail28-db3 (localhost.localdomain [127.0.0.1]) by mail28-db3
	(MessageSwitch) id 1347852049400162_5007;
	Mon, 17 Sep 2012 03:20:49 +0000 (UTC)
Received: from DB3EHSMHS002.bigfish.com (unknown [10.3.81.236])	by
	mail28-db3.bigfish.com (Postfix) with ESMTP id 4686442005C	for
	<xen-devel@lists.xen.org>; Mon, 17 Sep 2012 03:20:49 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	DB3EHSMHS002.bigfish.com (10.3.87.102) with Microsoft SMTP Server id
	14.1.225.23; Mon, 17 Sep 2012 03:20:48 +0000
X-WSS-ID: 0MAH5AK-02-18Z-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 2001FC80E3	for <xen-devel@lists.xen.org>; Sun, 16 Sep 2012
	22:20:43 -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;
	Sun, 16 Sep 2012 22:20:42 -0500
Received: from SCYBEXDAG01.amd.com (10.34.11.11) by sausexdag04.amd.com
	(163.181.55.4) with Microsoft SMTP Server (TLS) id 14.1.323.3;
	Sun, 16 Sep 2012 22:20:30 -0500
Received: from SCYBEXDAG03.amd.com ([169.254.3.3]) by SCYBEXDAG01.amd.com
	([169.254.1.82]) with mapi id 14.01.0323.003;
	Mon, 17 Sep 2012 11:20:28 +0800
From: "Ding, ShengGe" <ShengGe.Ding@amd.com>
To: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Thread-Topic: dom0 crashes while domain_pause in NPF handler
Thread-Index: Ac2Ug2IAr2Bf1LiASnmtzqjgJoXf9g==
Date: Mon, 17 Sep 2012 03:20:27 +0000
Message-ID: <4DEE49724F3FA0438F8949D4497F451A05620957@SCYBEXDAG03.amd.com>
Accept-Language: zh-CN, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.237.74.37]
MIME-Version: 1.0
X-OriginatorOrg: amd.com
Subject: [Xen-devel] dom0 crashes while domain_pause in NPF handler
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1436227261654024862=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============1436227261654024862==
Content-Language: en-US
Content-Type: multipart/alternative;
	boundary="_000_4DEE49724F3FA0438F8949D4497F451A05620957SCYBEXDAG03amdc_"

--_000_4DEE49724F3FA0438F8949D4497F451A05620957SCYBEXDAG03amdc_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi all,

I ran into trouble on nested page fault handling.

I removed p2m entries of passthrough type via clear_mmio_p2m_entry() to unm=
ap mmio space of passthough HW.
Then the nested page fault of physical mmio space can be trapped and the do=
mU can be paused here via domain_pause().

These are fine in xen-4.1.1 with debian patch(ubuntu).
But while I try to port them to xen-unstable version, the dom0 crashes.

The paused domain is absolutely domU. Is there any new restriction in NPF h=
andler in unstable version?

Thanks!
ShengGe

--_000_4DEE49724F3FA0438F8949D4497F451A05620957SCYBEXDAG03amdc_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:=
//www.w3.org/TR/REC-html40">
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"=
>
<meta name=3D"Generator" content=3D"Microsoft Word 12 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
	{font-family:SimSun;
	panose-1:2 1 6 0 3 1 1 1 1 1;}
@font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:SimSun;
	panose-1:2 1 6 0 3 1 1 1 1 1;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal-compose;
	font-family:"Calibri","sans-serif";
	color:windowtext;}
.MsoChpDefault
	{mso-style-type:export-only;}
@page WordSection1
	{size:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;}
div.WordSection1
	{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang=3D"EN-US" link=3D"blue" vlink=3D"purple">
<div class=3D"WordSection1">
<p class=3D"MsoNormal">Hi all,<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal">I ran into trouble on nested page fault handling.<o:=
p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal">I removed p2m entries of passthrough type via clear_=
mmio_p2m_entry() to unmap mmio space of passthough HW.<o:p></o:p></p>
<p class=3D"MsoNormal">Then the nested page fault of physical mmio space ca=
n be trapped and the domU can be paused here via domain_pause().<o:p></o:p>=
</p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal">These are fine in xen-4.1.1 with debian patch(ubuntu=
). <o:p>
</o:p></p>
<p class=3D"MsoNormal">But while I try to port them to xen-unstable version=
, the dom0 crashes.<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal">The paused domain is absolutely domU. Is there any n=
ew restriction in NPF handler in unstable version?<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal">Thanks!<o:p></o:p></p>
<p class=3D"MsoNormal">ShengGe<o:p></o:p></p>
</div>
</body>
</html>

--_000_4DEE49724F3FA0438F8949D4497F451A05620957SCYBEXDAG03amdc_--


--===============1436227261654024862==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============1436227261654024862==--


From xen-devel-bounces@lists.xen.org Mon Sep 17 04:27:40 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 04: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 1TDSvO-0002cy-8f; Mon, 17 Sep 2012 04:27:10 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andreww591@gmail.com>) id 1TDSvN-0002ct-5Y
	for xen-devel@lists.xen.org; Mon, 17 Sep 2012 04:27:09 +0000
Received: from [85.158.143.99:8278] by server-1.bemta-4.messagelabs.com id
	F6/BF-12504-C96A6505; Mon, 17 Sep 2012 04:27:08 +0000
X-Env-Sender: andreww591@gmail.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1347856026!24182465!1
X-Originating-IP: [209.85.223.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2667 invoked from network); 17 Sep 2012 04:27:07 -0000
Received: from mail-ie0-f173.google.com (HELO mail-ie0-f173.google.com)
	(209.85.223.173)
	by server-10.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Sep 2012 04:27:07 -0000
Received: by iebc10 with SMTP id c10so11152410ieb.32
	for <xen-devel@lists.xen.org>; Sun, 16 Sep 2012 21:27:05 -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=IV0jCf6c2S/fKoeueZtKyg/nqRdEajD+jl1OmKGax+c=;
	b=Z4CIUAnm7LFRir2Mwc1qQhE0B9T1XRC/EQCjsOQw2SqebicLOKH+Daq44SbwIOE9OI
	EcQ4YNaY48kBydSUpnJwWRJCV8rdYM/UAFe87dArnQXeJztRUigHlh9DhJhsMN8H9APY
	9WwmChz6i/x9H4nzR9qh+qIxXW3E8cM985W1td3C2IpVAyHa7fTpRTT8Ew2a8shjim7g
	WAgc6WMcF0/Kj8HdM7lC5XFCukFyVCP7q0MAs/iH1YiZ2BjaRSwM+vV7dA6ZeEepYXWj
	zBs/L0AboGe3Zko86NCgLclpt0Lw2D25ileRWbTTeK/pbkcCXYnBrfGLrlc5yvSW9dY4
	vpIg==
Received: by 10.50.5.133 with SMTP id s5mr5434020igs.49.1347856025750;
	Sun, 16 Sep 2012 21:27:05 -0700 (PDT)
Received: from [192.168.0.1] (d199-126-218-183.abhsia.telus.net.
	[199.126.218.183])
	by mx.google.com with ESMTPS id fu4sm6233800igc.4.2012.09.16.21.27.03
	(version=TLSv1/SSLv3 cipher=OTHER);
	Sun, 16 Sep 2012 21:27:04 -0700 (PDT)
Message-ID: <5056A6AC.5040502@gmail.com>
Date: Sun, 16 Sep 2012 22:27:24 -0600
From: Andrew Warkentin <andreww591@gmail.com>
User-Agent: Thunderbird 2.0.0.24 (X11/20100302)
MIME-Version: 1.0
To: xen-devel@lists.xen.org
References: <CC7BE9EE.2D8B7%ikozhukhov@gmail.com>
In-Reply-To: <CC7BE9EE.2D8B7%ikozhukhov@gmail.com>
Subject: Re: [Xen-devel] xen on illumos(OpenSolaris) based 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-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Igor Kozhukhov wrote:
> hello all!
>
> are you interested in port xen-4.1 to illumos(OpenSolaris) based platform?
> I have found old Sun works with xen-3.4.2 and updated it to xen-3.4.4
>
> I'll try to port xen-4.1.
>
> can I file a bugs with issues on solaris based platform?
> where can I file a bugs - I have bout some issues and I'd like to 
> provide fixes for solaris.
>
>
I'm interested specifically in HVM domU support. I'm using NCP3 on a 
minimal Debian 6.0 dom0 (with a kernel from XCP 1.5 and the Debian 6.0 
version of Xen 4.0.1 with patches to qemu-dm to support custom graphics 
and input servers for desktop use), but would like to update to both a 
newer Solaris distribution and a newer Xen version. NCP3 hangs on boot 
on any versions of Xen newer than 4.0.1 that I tried (even on 4.0.1, the 
kernel needs to be patched ), and illumos hangs on boot on all the Xen 
versions that I tried. These hangs are related to the PVHVM drivers (the 
install systems run OK, and they don't include them). Right now, I am 
trying to debug the problem with NCP3 and then will move onto illumos 
(I'm not sure if the problem is the same or not; illumos hangs sooner in 
the boot process than NCP3).

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 17 04:27:40 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 04: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 1TDSvO-0002cy-8f; Mon, 17 Sep 2012 04:27:10 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andreww591@gmail.com>) id 1TDSvN-0002ct-5Y
	for xen-devel@lists.xen.org; Mon, 17 Sep 2012 04:27:09 +0000
Received: from [85.158.143.99:8278] by server-1.bemta-4.messagelabs.com id
	F6/BF-12504-C96A6505; Mon, 17 Sep 2012 04:27:08 +0000
X-Env-Sender: andreww591@gmail.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1347856026!24182465!1
X-Originating-IP: [209.85.223.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2667 invoked from network); 17 Sep 2012 04:27:07 -0000
Received: from mail-ie0-f173.google.com (HELO mail-ie0-f173.google.com)
	(209.85.223.173)
	by server-10.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Sep 2012 04:27:07 -0000
Received: by iebc10 with SMTP id c10so11152410ieb.32
	for <xen-devel@lists.xen.org>; Sun, 16 Sep 2012 21:27:05 -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=IV0jCf6c2S/fKoeueZtKyg/nqRdEajD+jl1OmKGax+c=;
	b=Z4CIUAnm7LFRir2Mwc1qQhE0B9T1XRC/EQCjsOQw2SqebicLOKH+Daq44SbwIOE9OI
	EcQ4YNaY48kBydSUpnJwWRJCV8rdYM/UAFe87dArnQXeJztRUigHlh9DhJhsMN8H9APY
	9WwmChz6i/x9H4nzR9qh+qIxXW3E8cM985W1td3C2IpVAyHa7fTpRTT8Ew2a8shjim7g
	WAgc6WMcF0/Kj8HdM7lC5XFCukFyVCP7q0MAs/iH1YiZ2BjaRSwM+vV7dA6ZeEepYXWj
	zBs/L0AboGe3Zko86NCgLclpt0Lw2D25ileRWbTTeK/pbkcCXYnBrfGLrlc5yvSW9dY4
	vpIg==
Received: by 10.50.5.133 with SMTP id s5mr5434020igs.49.1347856025750;
	Sun, 16 Sep 2012 21:27:05 -0700 (PDT)
Received: from [192.168.0.1] (d199-126-218-183.abhsia.telus.net.
	[199.126.218.183])
	by mx.google.com with ESMTPS id fu4sm6233800igc.4.2012.09.16.21.27.03
	(version=TLSv1/SSLv3 cipher=OTHER);
	Sun, 16 Sep 2012 21:27:04 -0700 (PDT)
Message-ID: <5056A6AC.5040502@gmail.com>
Date: Sun, 16 Sep 2012 22:27:24 -0600
From: Andrew Warkentin <andreww591@gmail.com>
User-Agent: Thunderbird 2.0.0.24 (X11/20100302)
MIME-Version: 1.0
To: xen-devel@lists.xen.org
References: <CC7BE9EE.2D8B7%ikozhukhov@gmail.com>
In-Reply-To: <CC7BE9EE.2D8B7%ikozhukhov@gmail.com>
Subject: Re: [Xen-devel] xen on illumos(OpenSolaris) based 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-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Igor Kozhukhov wrote:
> hello all!
>
> are you interested in port xen-4.1 to illumos(OpenSolaris) based platform?
> I have found old Sun works with xen-3.4.2 and updated it to xen-3.4.4
>
> I'll try to port xen-4.1.
>
> can I file a bugs with issues on solaris based platform?
> where can I file a bugs - I have bout some issues and I'd like to 
> provide fixes for solaris.
>
>
I'm interested specifically in HVM domU support. I'm using NCP3 on a 
minimal Debian 6.0 dom0 (with a kernel from XCP 1.5 and the Debian 6.0 
version of Xen 4.0.1 with patches to qemu-dm to support custom graphics 
and input servers for desktop use), but would like to update to both a 
newer Solaris distribution and a newer Xen version. NCP3 hangs on boot 
on any versions of Xen newer than 4.0.1 that I tried (even on 4.0.1, the 
kernel needs to be patched ), and illumos hangs on boot on all the Xen 
versions that I tried. These hangs are related to the PVHVM drivers (the 
install systems run OK, and they don't include them). Right now, I am 
trying to debug the problem with NCP3 and then will move onto illumos 
(I'm not sure if the problem is the same or not; illumos hangs sooner in 
the boot process than NCP3).

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 17 04:37:50 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 04:37:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDT5I-0002mx-C7; Mon, 17 Sep 2012 04:37:24 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <fajar@fajar.net>) id 1TDT5G-0002ms-Fc
	for xen-devel@lists.xen.org; Mon, 17 Sep 2012 04:37:22 +0000
Received: from [85.158.138.51:9484] by server-12.bemta-3.messagelabs.com id
	34/BF-10384-109A6505; Mon, 17 Sep 2012 04:37:21 +0000
X-Env-Sender: fajar@fajar.net
X-Msg-Ref: server-2.tower-174.messagelabs.com!1347856639!30774736!1
X-Originating-IP: [209.85.219.45]
X-SpamReason: No, hits=0.6 required=7.0 tests=MAILTO_TO_SPAM_ADDR, RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9285 invoked from network); 17 Sep 2012 04:37:21 -0000
Received: from mail-oa0-f45.google.com (HELO mail-oa0-f45.google.com)
	(209.85.219.45)
	by server-2.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Sep 2012 04:37:21 -0000
Received: by oagn12 with SMTP id n12so5470469oag.32
	for <xen-devel@lists.xen.org>; Sun, 16 Sep 2012 21:37:19 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type:x-gm-message-state;
	bh=VH3ApI0Qf1Pm0kcEixF1OLWvod06me9psOUGdebF6p4=;
	b=mxNpLriZx/SVytmRVCwg6GaDfewipg5R2YB1Qd4GbYjRB3AlMu2caNlu1y17pA//cb
	VATI6xMisQIrB9F48uMnZep2UBzoWOWaneqOZkDD8kxe0lUOnT1JH3jjH1PmVFwpG0B5
	ZVIpCchxbT9OkUgVAQ5scNcoZolBULBZhlPxHTwvtmz8bp5zALN5ZqJnzre8b97tuQYr
	GVLpw4cPWgLUIVZ1RWZ9IywbrkBYd1ZXJj/ovPEu2UDgmo8M7xxJot5suC3dG204G/53
	33MZqcUsiHMI727YSXvkpqbyGAFHyaJ+jlz8oDs/94IP/ECNwfs3V5Dc3b0+Puw18ZDN
	edVQ==
MIME-Version: 1.0
Received: by 10.60.8.104 with SMTP id q8mr10093368oea.120.1347856639420; Sun,
	16 Sep 2012 21:37:19 -0700 (PDT)
Received: by 10.60.6.230 with HTTP; Sun, 16 Sep 2012 21:37:19 -0700 (PDT)
In-Reply-To: <5056A6AC.5040502@gmail.com>
References: <CC7BE9EE.2D8B7%ikozhukhov@gmail.com> <5056A6AC.5040502@gmail.com>
Date: Mon, 17 Sep 2012 11:37:19 +0700
Message-ID: <CAG1y0sczO296+UkFeNwQjGyV3sVssCA-W95iuY8KEEpFcDsJcQ@mail.gmail.com>
From: "Fajar A. Nugraha" <list@fajar.net>
To: Andrew Warkentin <andreww591@gmail.com>
X-Gm-Message-State: ALoCoQkGPjGSUXtE995Ru7Ytc2Y9hmAg58uZWWiTuSyQHBs598JM9f8Mhq8m74rLtZcKd8TbWdAh
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] xen on illumos(OpenSolaris) based platform
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Sep 17, 2012 at 11:27 AM, Andrew Warkentin <andreww591@gmail.com> wrote:
> Igor Kozhukhov wrote:
>>
>> hello all!
>>
>> are you interested in port xen-4.1 to illumos(OpenSolaris) based platform?
>> I have found old Sun works with xen-3.4.2 and updated it to xen-3.4.4
>>
>> I'll try to port xen-4.1.

> I'm interested specifically in HVM domU support.

> NCP3 hangs on boot on any versions of
> Xen newer than 4.0.1 that I tried (even on 4.0.1, the kernel needs to be
> patched ), and illumos hangs on boot on all the Xen versions that I tried.
> These hangs are related to the PVHVM drivers (the install systems run OK,
> and they don't include them).

I thought opensolaris (and derivatives) runs well as PV domU? What do
you use HVM for?

Also, doesn't illumos support KVM? If you need full virtualization
with *solaris, wouldn't it be easier for that particular purpose to
try KVM instead?

-- 
Fajar

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 17 04:37:50 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 04:37:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDT5I-0002mx-C7; Mon, 17 Sep 2012 04:37:24 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <fajar@fajar.net>) id 1TDT5G-0002ms-Fc
	for xen-devel@lists.xen.org; Mon, 17 Sep 2012 04:37:22 +0000
Received: from [85.158.138.51:9484] by server-12.bemta-3.messagelabs.com id
	34/BF-10384-109A6505; Mon, 17 Sep 2012 04:37:21 +0000
X-Env-Sender: fajar@fajar.net
X-Msg-Ref: server-2.tower-174.messagelabs.com!1347856639!30774736!1
X-Originating-IP: [209.85.219.45]
X-SpamReason: No, hits=0.6 required=7.0 tests=MAILTO_TO_SPAM_ADDR, RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9285 invoked from network); 17 Sep 2012 04:37:21 -0000
Received: from mail-oa0-f45.google.com (HELO mail-oa0-f45.google.com)
	(209.85.219.45)
	by server-2.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Sep 2012 04:37:21 -0000
Received: by oagn12 with SMTP id n12so5470469oag.32
	for <xen-devel@lists.xen.org>; Sun, 16 Sep 2012 21:37:19 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type:x-gm-message-state;
	bh=VH3ApI0Qf1Pm0kcEixF1OLWvod06me9psOUGdebF6p4=;
	b=mxNpLriZx/SVytmRVCwg6GaDfewipg5R2YB1Qd4GbYjRB3AlMu2caNlu1y17pA//cb
	VATI6xMisQIrB9F48uMnZep2UBzoWOWaneqOZkDD8kxe0lUOnT1JH3jjH1PmVFwpG0B5
	ZVIpCchxbT9OkUgVAQ5scNcoZolBULBZhlPxHTwvtmz8bp5zALN5ZqJnzre8b97tuQYr
	GVLpw4cPWgLUIVZ1RWZ9IywbrkBYd1ZXJj/ovPEu2UDgmo8M7xxJot5suC3dG204G/53
	33MZqcUsiHMI727YSXvkpqbyGAFHyaJ+jlz8oDs/94IP/ECNwfs3V5Dc3b0+Puw18ZDN
	edVQ==
MIME-Version: 1.0
Received: by 10.60.8.104 with SMTP id q8mr10093368oea.120.1347856639420; Sun,
	16 Sep 2012 21:37:19 -0700 (PDT)
Received: by 10.60.6.230 with HTTP; Sun, 16 Sep 2012 21:37:19 -0700 (PDT)
In-Reply-To: <5056A6AC.5040502@gmail.com>
References: <CC7BE9EE.2D8B7%ikozhukhov@gmail.com> <5056A6AC.5040502@gmail.com>
Date: Mon, 17 Sep 2012 11:37:19 +0700
Message-ID: <CAG1y0sczO296+UkFeNwQjGyV3sVssCA-W95iuY8KEEpFcDsJcQ@mail.gmail.com>
From: "Fajar A. Nugraha" <list@fajar.net>
To: Andrew Warkentin <andreww591@gmail.com>
X-Gm-Message-State: ALoCoQkGPjGSUXtE995Ru7Ytc2Y9hmAg58uZWWiTuSyQHBs598JM9f8Mhq8m74rLtZcKd8TbWdAh
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] xen on illumos(OpenSolaris) based platform
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Sep 17, 2012 at 11:27 AM, Andrew Warkentin <andreww591@gmail.com> wrote:
> Igor Kozhukhov wrote:
>>
>> hello all!
>>
>> are you interested in port xen-4.1 to illumos(OpenSolaris) based platform?
>> I have found old Sun works with xen-3.4.2 and updated it to xen-3.4.4
>>
>> I'll try to port xen-4.1.

> I'm interested specifically in HVM domU support.

> NCP3 hangs on boot on any versions of
> Xen newer than 4.0.1 that I tried (even on 4.0.1, the kernel needs to be
> patched ), and illumos hangs on boot on all the Xen versions that I tried.
> These hangs are related to the PVHVM drivers (the install systems run OK,
> and they don't include them).

I thought opensolaris (and derivatives) runs well as PV domU? What do
you use HVM for?

Also, doesn't illumos support KVM? If you need full virtualization
with *solaris, wouldn't it be easier for that particular purpose to
try KVM instead?

-- 
Fajar

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 17 06:34:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 06: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 1TDUtn-000586-Ao; Mon, 17 Sep 2012 06:33:39 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ronghui.duan@intel.com>) id 1TDUtl-00057x-Tb
	for xen-devel@lists.xen.org; Mon, 17 Sep 2012 06:33:38 +0000
Received: from [85.158.139.83:41011] by server-4.bemta-5.messagelabs.com id
	D4/36-23042-044C6505; Mon, 17 Sep 2012 06:33:36 +0000
X-Env-Sender: ronghui.duan@intel.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1347863615!28593679!1
X-Originating-IP: [134.134.136.20]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjAgPT4gMjk4OTMy\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9678 invoked from network); 17 Sep 2012 06:33:35 -0000
Received: from mga02.intel.com (HELO mga02.intel.com) (134.134.136.20)
	by server-15.tower-182.messagelabs.com with SMTP;
	17 Sep 2012 06:33:35 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga101.jf.intel.com with ESMTP; 16 Sep 2012 23:33:34 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.80,433,1344236400"; d="scan'208";a="205923784"
Received: from fmsmsx104.amr.corp.intel.com ([10.19.9.35])
	by orsmga002.jf.intel.com with ESMTP; 16 Sep 2012 23:33:33 -0700
Received: from fmsmsx153.amr.corp.intel.com (10.19.17.7) by
	FMSMSX104.amr.corp.intel.com (10.19.9.35) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Sun, 16 Sep 2012 23:33:32 -0700
Received: from shsmsx101.ccr.corp.intel.com (10.239.4.153) by
	FMSMSX153.amr.corp.intel.com (10.19.17.7) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Sun, 16 Sep 2012 23:33:31 -0700
Received: from shsmsx102.ccr.corp.intel.com ([169.254.2.92]) by
	SHSMSX101.ccr.corp.intel.com ([169.254.1.239]) with mapi id
	14.01.0355.002; Mon, 17 Sep 2012 14:33:30 +0800
From: "Duan, Ronghui" <ronghui.duan@intel.com>
To: "Duan, Ronghui" <ronghui.duan@intel.com>, 'Konrad Rzeszutek Wilk'
	<konrad.wilk@oracle.com>, 'Stefano Stabellini'
	<stefano.stabellini@eu.citrix.com>
Thread-Topic: [Xen-devel] [RFC v1 0/5] VBD: enlarge max segment per request
	in blkfront
Thread-Index: Ac17mRnxOUx7HczFSN2/QYn7Hm+BlQRRPS0AAR4vKmD//9A5gIAAO3mAgAAmkYD//2/KAP/5HT3g
Date: Mon, 17 Sep 2012 06:33:29 +0000
Message-ID: <A21691DE07B84740B5F0B81466D5148A23BF7E2F@SHSMSX102.ccr.corp.intel.com>
References: <A21691DE07B84740B5F0B81466D5148A23BCF1DF@SHSMSX102.ccr.corp.intel.com>
	<20120907174922.GA13040@phenom.dumpdata.com>
	<A21691DE07B84740B5F0B81466D5148A23BF6833@SHSMSX102.ccr.corp.intel.com>
	<5051A83B020000780009AF93@nat28.tlf.novell.com>
	<alpine.DEB.2.02.1209131203270.15568@kaball.uk.xensource.com>
	<20120913132335.GD16635@localhost.localdomain>
	<A21691DE07B84740B5F0B81466D5148A23BF6C1D@SHSMSX102.ccr.corp.intel.com>
In-Reply-To: <A21691DE07B84740B5F0B81466D5148A23BF6C1D@SHSMSX102.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_A21691DE07B84740B5F0B81466D5148A23BF7E2FSHSMSX102ccrcor_"
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] [RFC v1 0/5] VBD: enlarge max segment per request
 in blkfront
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<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_A21691DE07B84740B5F0B81466D5148A23BF7E2FSHSMSX102ccrcor_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

At last, I saw the regression in random io.
This is a patch to fix the performance regression. Original the pending req=
uest members are allocated from the stack, I alloc them when each request a=
rrives in my last patch. But it will hurt performance. In this fix, I alloc=
 all of them when blkback init. But due to some bugs there, we can't free i=
t, the same to other pending requests member. I am looking for the reason. =
But have no idea for this now.=20
Konrad, thanks for your comments. Could you have a try when you have time.

-ronghui

> -----Original Message-----
> From: Duan, Ronghui
> Sent: Thursday, September 13, 2012 10:06 PM
> To: Konrad Rzeszutek Wilk; Stefano Stabellini
> Cc: Jan Beulich; Ian Jackson; xen-devel@lists.xen.org
> Subject: RE: [Xen-devel] [RFC v1 0/5] VBD: enlarge max segment per reques=
t in
> blkfront
>=20
> > > > But you certainly shouldn't be proposing features getting used
> > > > unconditionally or by default that benefit one class of backing
> > > > devices and severely penalize others.
> > >
> > > Right.
> > > I am wondering.. Considering that the in-kernel blkback is mainly
> > > used with physical partitions, is it possible that your patches
> > > cause a regression with unmodified backends that don't support the
> > > new protocol, like QEMU for example?
> >
> > Well for right now I am just using the most simple configuration to
> > eliminate any extra variables (stacking of components). So my
> > "testing" has been just on phy:/dev/sda,xvda,w with the sda being a Cor=
sair
> SSD.
>=20
> I totally agree that we should not break others when enable what we want.
> But just from my mind, the patch only have a little overhead in the
> front/backend code path. It will induce pure random IO with a little over=
head.
> I tried the 4K read case, I just got 50MB/s w/o the patch. I need a more
> powerful disk to verified it.
>=20
> Ronghui
>=20
>=20
> > -----Original Message-----
> > From: Konrad Rzeszutek Wilk [mailto:konrad.wilk@oracle.com]
> > Sent: Thursday, September 13, 2012 9:24 PM
> > To: Stefano Stabellini
> > Cc: Jan Beulich; Duan, Ronghui; Ian Jackson; xen-devel@lists.xen.org
> > Subject: Re: [Xen-devel] [RFC v1 0/5] VBD: enlarge max segment per
> > request in blkfront
> >
> > On Thu, Sep 13, 2012 at 12:05:35PM +0100, Stefano Stabellini wrote:
> > > On Thu, 13 Sep 2012, Jan Beulich wrote:
> > > > >>> On 13.09.12 at 04:28, "Duan, Ronghui" <ronghui.duan@intel.com> =
wrote:
> > > > >> And with your patch got:
> > > > >>   read : io=3D4096.0MB, bw=3D92606KB/s, iops=3D23151 , runt=3D
> > > > >> 45292msec
> > > > >>
> > > > >> without:
> > > > >>   read : io=3D4096.0MB, bw=3D145187KB/s, iops=3D36296 , runt=3D
> > > > >> 28889msec
> > > > >>
> > > > > What type of backend file you are using? In order to remove the
> > > > > influence of cache in Dom0, I use a physical partition as backend=
.
> > > >
> > > > But you certainly shouldn't be proposing features getting used
> > > > unconditionally or by default that benefit one class of backing
> > > > devices and severely penalize others.
> > >
> > > Right.
> > > I am wondering.. Considering that the in-kernel blkback is mainly
> > > used with physical partitions, is it possible that your patches
> > > cause a regression with unmodified backends that don't support the
> > > new protocol, like QEMU for example?
> >
> > Well for right now I am just using the most simple configuration to
> > eliminate any extra variables (stacking of components). So my
> > "testing" has been just on phy:/dev/sda,xvda,w with the sda being a Cor=
sair
> SSD.


--_002_A21691DE07B84740B5F0B81466D5148A23BF7E2FSHSMSX102ccrcor_
Content-Type: application/octet-stream; name="alloc_req.patch"
Content-Description: alloc_req.patch
Content-Disposition: attachment; filename="alloc_req.patch"; size=2639;
	creation-date="Mon, 17 Sep 2012 05:56:23 GMT";
	modification-date="Sun, 16 Sep 2012 22:57:57 GMT"
Content-Transfer-Encoding: base64

Y29tbWl0IDE3YjRjY2VlODZhMTdjZTMyZTQxZmJhZmQyZTY3ZjNlYmM1NzY4MTYKQXV0aG9yOiBS
b25naHVpIER1YW4gPHJvbmdodWkuZHVhbkBpbnRlbC5jb20+CkRhdGU6ICAgTW9uIFNlcCAxNyAw
NjowODoyNiAyMDEyICswODAwCgphbGxvYyByZXEgYXQgaW5pdCB0aW1lIHRvIGZpeCBwZXJmcm9t
YW5jZSByZWdyZXNzaW9uLgpkdWUgdG8gc29tZSBidWdzLCB0aGVzZSBtZW1vcnkgY2FuJ3QgYmUg
ZnJlZSBub3cuIFRoaXMgaXMganVzdCB3b3JrIGFzIFJGQy4KCmRpZmYgLS1naXQgYS9kcml2ZXJz
L2Jsb2NrL3hlbi1ibGtiYWNrL2Jsa2JhY2suYyBiL2RyaXZlcnMvYmxvY2sveGVuLWJsa2JhY2sv
YmxrYmFjay5jCmluZGV4IDBiYmMyMjYuLjdjODE4ZmUgMTAwNjQ0Ci0tLSBhL2RyaXZlcnMvYmxv
Y2sveGVuLWJsa2JhY2svYmxrYmFjay5jCisrKyBiL2RyaXZlcnMvYmxvY2sveGVuLWJsa2JhY2sv
YmxrYmFjay5jCkBAIC0xMDgsMTEgKzEwOCw2IEBAIHN0YXRpYyB2b2lkIGZyZWVfcmVxKHN0cnVj
dCBwZW5kaW5nX3JlcSAqcmVxKQogCXVuc2lnbmVkIGxvbmcgZmxhZ3M7CiAJaW50IHdhc19lbXB0
eTsKIAotCWtmcmVlKHJlcS0+bWFwKTsKLQlrZnJlZShyZXEtPnVubWFwKTsKLQlrZnJlZShyZXEt
PmJpb2xpc3QpOwotCWtmcmVlKHJlcS0+c2VnKTsKLQlrZnJlZShyZXEtPnBhZ2VzKTsKIAogCXNw
aW5fbG9ja19pcnFzYXZlKCZibGtiay0+cGVuZGluZ19mcmVlX2xvY2ssIGZsYWdzKTsKIAl3YXNf
ZW1wdHkgPSBsaXN0X2VtcHR5KCZibGtiay0+cGVuZGluZ19mcmVlKTsKQEAgLTE0MCwyMyArMTM1
LDYgQEAgc3RhdGljIHN0cnVjdCBwZW5kaW5nX3JlcSAqYWxsb2NfcmVxKHN0cnVjdCB4ZW5fYmxr
aWYgKmJsa2lmKQogCX0KIAlzcGluX3VubG9ja19pcnFyZXN0b3JlKCZibGtiay0+cGVuZGluZ19m
cmVlX2xvY2ssIGZsYWdzKTsKIAkKLQlpZiAocmVxICE9IE5VTEwpIHsKLQkJcmVxLT5tYXAgPSBr
emFsbG9jKHNpemVvZihzdHJ1Y3QgZ250dGFiX21hcF9ncmFudF9yZWYpICoKLQkJCQkgICBtYXhf
c2VnLCBHRlBfS0VSTkVMKTsKLQkJcmVxLT51bm1hcCA9IGt6YWxsb2Moc2l6ZW9mKHN0cnVjdCBn
bnR0YWJfdW5tYXBfZ3JhbnRfcmVmKSAqCi0JCQkJICAgbWF4X3NlZywgR0ZQX0tFUk5FTCk7Ci0J
CXJlcS0+YmlvbGlzdCA9IGt6YWxsb2Moc2l6ZW9mKHN0cnVjdCBiaW8gKikgKiBtYXhfc2VnLAot
CQkJCSAgICAgICBHRlBfS0VSTkVMKTsKLQkJcmVxLT5zZWcgPSBremFsbG9jKHNpemVvZihzdHJ1
Y3Qgc2VnX2J1ZikgKiBtYXhfc2VnLAotCQkJCSAgIEdGUF9LRVJORUwpOwotCQlyZXEtPnBhZ2Vz
ID0ga3phbGxvYyhzaXplb2Yoc3RydWN0IHBhZ2UgKikgKiBtYXhfc2VnLAotCQkJCSAgIEdGUF9L
RVJORUwpOwotCQlpZiAoIXJlcS0+bWFwIHx8ICFyZXEtPnVubWFwIHx8ICFyZXEtPmJpb2xpc3Qg
fHwKLQkJICAgICFyZXEtPnNlZyB8fCAhcmVxLT5wYWdlcykgewotCQkJZnJlZV9yZXEocmVxKTsK
LQkJCXJlcSA9IE5VTEw7Ci0JCX0KLQl9CiAJcmV0dXJuIHJlcTsKIH0KIC8qCkBAIC05MTgsNiAr
ODk2LDcgQEAgaW50IHhlbl9ibGtpZl9pbml0X2Jsa2JrKHN0cnVjdCB4ZW5fYmxraWYgKmJsa2lm
KQogCWludCByYyA9IDA7CiAJaW50IGksIG1tYXBfcGFnZXM7CiAJc3RydWN0IHhlbl9ibGtiayAq
YmxrYms7CisJdW5zaWduZWQgaW50IG1heF9zZWcgPSBibGtpZi0+b3BzLT5tYXhfc2VnOwogCiAJ
YmxraWYtPmJsa2JrID0ga3phbGxvYyhzaXplb2Yoc3RydWN0IHhlbl9ibGtiayksIEdGUF9LRVJO
RUwpOwogCWlmICghYmxraWYtPmJsa2JrKSB7CkBAIC05NTMsOSArOTMyLDIwIEBAIGludCB4ZW5f
YmxraWZfaW5pdF9ibGtiayhzdHJ1Y3QgeGVuX2Jsa2lmICpibGtpZikKIAlzcGluX2xvY2tfaW5p
dCgmYmxrYmstPnBlbmRpbmdfZnJlZV9sb2NrKTsKIAlpbml0X3dhaXRxdWV1ZV9oZWFkKCZibGti
ay0+cGVuZGluZ19mcmVlX3dxKTsKIAotCWZvciAoaSA9IDA7IGkgPCB4ZW5fYmxraWZfcmVxczsg
aSsrKQorCWZvciAoaSA9IDA7IGkgPCB4ZW5fYmxraWZfcmVxczsgaSsrKSB7CisJCWJsa2JrLT5w
ZW5kaW5nX3JlcXNbaV0ubWFwID0ga3phbGxvYyhzaXplb2Yoc3RydWN0IGdudHRhYl9tYXBfZ3Jh
bnRfcmVmKSAqCisJCQkJbWF4X3NlZywgR0ZQX0tFUk5FTCk7CisJCWJsa2JrLT5wZW5kaW5nX3Jl
cXNbaV0udW5tYXAgPSBremFsbG9jKHNpemVvZihzdHJ1Y3QgZ250dGFiX3VubWFwX2dyYW50X3Jl
ZikgKgorCQkJCW1heF9zZWcsIEdGUF9LRVJORUwpOworCQlibGtiay0+cGVuZGluZ19yZXFzW2ld
LmJpb2xpc3QgPSBremFsbG9jKHNpemVvZihzdHJ1Y3QgYmlvICopICogbWF4X3NlZywKKwkJCQlH
RlBfS0VSTkVMKTsKKwkJYmxrYmstPnBlbmRpbmdfcmVxc1tpXS5zZWcgPSBremFsbG9jKHNpemVv
ZihzdHJ1Y3Qgc2VnX2J1ZikgKiBtYXhfc2VnLAorCQkJCUdGUF9LRVJORUwpOworCQlibGtiay0+
cGVuZGluZ19yZXFzW2ldLnBhZ2VzID0ga3phbGxvYyhzaXplb2Yoc3RydWN0IHBhZ2UgKikgKiBt
YXhfc2VnLAorCQkJCUdGUF9LRVJORUwpOwogCQlsaXN0X2FkZF90YWlsKCZibGtiay0+cGVuZGlu
Z19yZXFzW2ldLmZyZWVfbGlzdCwKIAkJCSAgICAgICZibGtiay0+cGVuZGluZ19mcmVlKTsKKwl9
CiAKIAlyZXR1cm4gMDsKIAo=

--_002_A21691DE07B84740B5F0B81466D5148A23BF7E2FSHSMSX102ccrcor_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 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_A21691DE07B84740B5F0B81466D5148A23BF7E2FSHSMSX102ccrcor_--


From xen-devel-bounces@lists.xen.org Mon Sep 17 06:34:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 06: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 1TDUtn-000586-Ao; Mon, 17 Sep 2012 06:33:39 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ronghui.duan@intel.com>) id 1TDUtl-00057x-Tb
	for xen-devel@lists.xen.org; Mon, 17 Sep 2012 06:33:38 +0000
Received: from [85.158.139.83:41011] by server-4.bemta-5.messagelabs.com id
	D4/36-23042-044C6505; Mon, 17 Sep 2012 06:33:36 +0000
X-Env-Sender: ronghui.duan@intel.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1347863615!28593679!1
X-Originating-IP: [134.134.136.20]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjAgPT4gMjk4OTMy\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9678 invoked from network); 17 Sep 2012 06:33:35 -0000
Received: from mga02.intel.com (HELO mga02.intel.com) (134.134.136.20)
	by server-15.tower-182.messagelabs.com with SMTP;
	17 Sep 2012 06:33:35 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga101.jf.intel.com with ESMTP; 16 Sep 2012 23:33:34 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.80,433,1344236400"; d="scan'208";a="205923784"
Received: from fmsmsx104.amr.corp.intel.com ([10.19.9.35])
	by orsmga002.jf.intel.com with ESMTP; 16 Sep 2012 23:33:33 -0700
Received: from fmsmsx153.amr.corp.intel.com (10.19.17.7) by
	FMSMSX104.amr.corp.intel.com (10.19.9.35) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Sun, 16 Sep 2012 23:33:32 -0700
Received: from shsmsx101.ccr.corp.intel.com (10.239.4.153) by
	FMSMSX153.amr.corp.intel.com (10.19.17.7) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Sun, 16 Sep 2012 23:33:31 -0700
Received: from shsmsx102.ccr.corp.intel.com ([169.254.2.92]) by
	SHSMSX101.ccr.corp.intel.com ([169.254.1.239]) with mapi id
	14.01.0355.002; Mon, 17 Sep 2012 14:33:30 +0800
From: "Duan, Ronghui" <ronghui.duan@intel.com>
To: "Duan, Ronghui" <ronghui.duan@intel.com>, 'Konrad Rzeszutek Wilk'
	<konrad.wilk@oracle.com>, 'Stefano Stabellini'
	<stefano.stabellini@eu.citrix.com>
Thread-Topic: [Xen-devel] [RFC v1 0/5] VBD: enlarge max segment per request
	in blkfront
Thread-Index: Ac17mRnxOUx7HczFSN2/QYn7Hm+BlQRRPS0AAR4vKmD//9A5gIAAO3mAgAAmkYD//2/KAP/5HT3g
Date: Mon, 17 Sep 2012 06:33:29 +0000
Message-ID: <A21691DE07B84740B5F0B81466D5148A23BF7E2F@SHSMSX102.ccr.corp.intel.com>
References: <A21691DE07B84740B5F0B81466D5148A23BCF1DF@SHSMSX102.ccr.corp.intel.com>
	<20120907174922.GA13040@phenom.dumpdata.com>
	<A21691DE07B84740B5F0B81466D5148A23BF6833@SHSMSX102.ccr.corp.intel.com>
	<5051A83B020000780009AF93@nat28.tlf.novell.com>
	<alpine.DEB.2.02.1209131203270.15568@kaball.uk.xensource.com>
	<20120913132335.GD16635@localhost.localdomain>
	<A21691DE07B84740B5F0B81466D5148A23BF6C1D@SHSMSX102.ccr.corp.intel.com>
In-Reply-To: <A21691DE07B84740B5F0B81466D5148A23BF6C1D@SHSMSX102.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_A21691DE07B84740B5F0B81466D5148A23BF7E2FSHSMSX102ccrcor_"
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] [RFC v1 0/5] VBD: enlarge max segment per request
 in blkfront
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<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_A21691DE07B84740B5F0B81466D5148A23BF7E2FSHSMSX102ccrcor_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

At last, I saw the regression in random io.
This is a patch to fix the performance regression. Original the pending req=
uest members are allocated from the stack, I alloc them when each request a=
rrives in my last patch. But it will hurt performance. In this fix, I alloc=
 all of them when blkback init. But due to some bugs there, we can't free i=
t, the same to other pending requests member. I am looking for the reason. =
But have no idea for this now.=20
Konrad, thanks for your comments. Could you have a try when you have time.

-ronghui

> -----Original Message-----
> From: Duan, Ronghui
> Sent: Thursday, September 13, 2012 10:06 PM
> To: Konrad Rzeszutek Wilk; Stefano Stabellini
> Cc: Jan Beulich; Ian Jackson; xen-devel@lists.xen.org
> Subject: RE: [Xen-devel] [RFC v1 0/5] VBD: enlarge max segment per reques=
t in
> blkfront
>=20
> > > > But you certainly shouldn't be proposing features getting used
> > > > unconditionally or by default that benefit one class of backing
> > > > devices and severely penalize others.
> > >
> > > Right.
> > > I am wondering.. Considering that the in-kernel blkback is mainly
> > > used with physical partitions, is it possible that your patches
> > > cause a regression with unmodified backends that don't support the
> > > new protocol, like QEMU for example?
> >
> > Well for right now I am just using the most simple configuration to
> > eliminate any extra variables (stacking of components). So my
> > "testing" has been just on phy:/dev/sda,xvda,w with the sda being a Cor=
sair
> SSD.
>=20
> I totally agree that we should not break others when enable what we want.
> But just from my mind, the patch only have a little overhead in the
> front/backend code path. It will induce pure random IO with a little over=
head.
> I tried the 4K read case, I just got 50MB/s w/o the patch. I need a more
> powerful disk to verified it.
>=20
> Ronghui
>=20
>=20
> > -----Original Message-----
> > From: Konrad Rzeszutek Wilk [mailto:konrad.wilk@oracle.com]
> > Sent: Thursday, September 13, 2012 9:24 PM
> > To: Stefano Stabellini
> > Cc: Jan Beulich; Duan, Ronghui; Ian Jackson; xen-devel@lists.xen.org
> > Subject: Re: [Xen-devel] [RFC v1 0/5] VBD: enlarge max segment per
> > request in blkfront
> >
> > On Thu, Sep 13, 2012 at 12:05:35PM +0100, Stefano Stabellini wrote:
> > > On Thu, 13 Sep 2012, Jan Beulich wrote:
> > > > >>> On 13.09.12 at 04:28, "Duan, Ronghui" <ronghui.duan@intel.com> =
wrote:
> > > > >> And with your patch got:
> > > > >>   read : io=3D4096.0MB, bw=3D92606KB/s, iops=3D23151 , runt=3D
> > > > >> 45292msec
> > > > >>
> > > > >> without:
> > > > >>   read : io=3D4096.0MB, bw=3D145187KB/s, iops=3D36296 , runt=3D
> > > > >> 28889msec
> > > > >>
> > > > > What type of backend file you are using? In order to remove the
> > > > > influence of cache in Dom0, I use a physical partition as backend=
.
> > > >
> > > > But you certainly shouldn't be proposing features getting used
> > > > unconditionally or by default that benefit one class of backing
> > > > devices and severely penalize others.
> > >
> > > Right.
> > > I am wondering.. Considering that the in-kernel blkback is mainly
> > > used with physical partitions, is it possible that your patches
> > > cause a regression with unmodified backends that don't support the
> > > new protocol, like QEMU for example?
> >
> > Well for right now I am just using the most simple configuration to
> > eliminate any extra variables (stacking of components). So my
> > "testing" has been just on phy:/dev/sda,xvda,w with the sda being a Cor=
sair
> SSD.


--_002_A21691DE07B84740B5F0B81466D5148A23BF7E2FSHSMSX102ccrcor_
Content-Type: application/octet-stream; name="alloc_req.patch"
Content-Description: alloc_req.patch
Content-Disposition: attachment; filename="alloc_req.patch"; size=2639;
	creation-date="Mon, 17 Sep 2012 05:56:23 GMT";
	modification-date="Sun, 16 Sep 2012 22:57:57 GMT"
Content-Transfer-Encoding: base64

Y29tbWl0IDE3YjRjY2VlODZhMTdjZTMyZTQxZmJhZmQyZTY3ZjNlYmM1NzY4MTYKQXV0aG9yOiBS
b25naHVpIER1YW4gPHJvbmdodWkuZHVhbkBpbnRlbC5jb20+CkRhdGU6ICAgTW9uIFNlcCAxNyAw
NjowODoyNiAyMDEyICswODAwCgphbGxvYyByZXEgYXQgaW5pdCB0aW1lIHRvIGZpeCBwZXJmcm9t
YW5jZSByZWdyZXNzaW9uLgpkdWUgdG8gc29tZSBidWdzLCB0aGVzZSBtZW1vcnkgY2FuJ3QgYmUg
ZnJlZSBub3cuIFRoaXMgaXMganVzdCB3b3JrIGFzIFJGQy4KCmRpZmYgLS1naXQgYS9kcml2ZXJz
L2Jsb2NrL3hlbi1ibGtiYWNrL2Jsa2JhY2suYyBiL2RyaXZlcnMvYmxvY2sveGVuLWJsa2JhY2sv
YmxrYmFjay5jCmluZGV4IDBiYmMyMjYuLjdjODE4ZmUgMTAwNjQ0Ci0tLSBhL2RyaXZlcnMvYmxv
Y2sveGVuLWJsa2JhY2svYmxrYmFjay5jCisrKyBiL2RyaXZlcnMvYmxvY2sveGVuLWJsa2JhY2sv
YmxrYmFjay5jCkBAIC0xMDgsMTEgKzEwOCw2IEBAIHN0YXRpYyB2b2lkIGZyZWVfcmVxKHN0cnVj
dCBwZW5kaW5nX3JlcSAqcmVxKQogCXVuc2lnbmVkIGxvbmcgZmxhZ3M7CiAJaW50IHdhc19lbXB0
eTsKIAotCWtmcmVlKHJlcS0+bWFwKTsKLQlrZnJlZShyZXEtPnVubWFwKTsKLQlrZnJlZShyZXEt
PmJpb2xpc3QpOwotCWtmcmVlKHJlcS0+c2VnKTsKLQlrZnJlZShyZXEtPnBhZ2VzKTsKIAogCXNw
aW5fbG9ja19pcnFzYXZlKCZibGtiay0+cGVuZGluZ19mcmVlX2xvY2ssIGZsYWdzKTsKIAl3YXNf
ZW1wdHkgPSBsaXN0X2VtcHR5KCZibGtiay0+cGVuZGluZ19mcmVlKTsKQEAgLTE0MCwyMyArMTM1
LDYgQEAgc3RhdGljIHN0cnVjdCBwZW5kaW5nX3JlcSAqYWxsb2NfcmVxKHN0cnVjdCB4ZW5fYmxr
aWYgKmJsa2lmKQogCX0KIAlzcGluX3VubG9ja19pcnFyZXN0b3JlKCZibGtiay0+cGVuZGluZ19m
cmVlX2xvY2ssIGZsYWdzKTsKIAkKLQlpZiAocmVxICE9IE5VTEwpIHsKLQkJcmVxLT5tYXAgPSBr
emFsbG9jKHNpemVvZihzdHJ1Y3QgZ250dGFiX21hcF9ncmFudF9yZWYpICoKLQkJCQkgICBtYXhf
c2VnLCBHRlBfS0VSTkVMKTsKLQkJcmVxLT51bm1hcCA9IGt6YWxsb2Moc2l6ZW9mKHN0cnVjdCBn
bnR0YWJfdW5tYXBfZ3JhbnRfcmVmKSAqCi0JCQkJICAgbWF4X3NlZywgR0ZQX0tFUk5FTCk7Ci0J
CXJlcS0+YmlvbGlzdCA9IGt6YWxsb2Moc2l6ZW9mKHN0cnVjdCBiaW8gKikgKiBtYXhfc2VnLAot
CQkJCSAgICAgICBHRlBfS0VSTkVMKTsKLQkJcmVxLT5zZWcgPSBremFsbG9jKHNpemVvZihzdHJ1
Y3Qgc2VnX2J1ZikgKiBtYXhfc2VnLAotCQkJCSAgIEdGUF9LRVJORUwpOwotCQlyZXEtPnBhZ2Vz
ID0ga3phbGxvYyhzaXplb2Yoc3RydWN0IHBhZ2UgKikgKiBtYXhfc2VnLAotCQkJCSAgIEdGUF9L
RVJORUwpOwotCQlpZiAoIXJlcS0+bWFwIHx8ICFyZXEtPnVubWFwIHx8ICFyZXEtPmJpb2xpc3Qg
fHwKLQkJICAgICFyZXEtPnNlZyB8fCAhcmVxLT5wYWdlcykgewotCQkJZnJlZV9yZXEocmVxKTsK
LQkJCXJlcSA9IE5VTEw7Ci0JCX0KLQl9CiAJcmV0dXJuIHJlcTsKIH0KIC8qCkBAIC05MTgsNiAr
ODk2LDcgQEAgaW50IHhlbl9ibGtpZl9pbml0X2Jsa2JrKHN0cnVjdCB4ZW5fYmxraWYgKmJsa2lm
KQogCWludCByYyA9IDA7CiAJaW50IGksIG1tYXBfcGFnZXM7CiAJc3RydWN0IHhlbl9ibGtiayAq
YmxrYms7CisJdW5zaWduZWQgaW50IG1heF9zZWcgPSBibGtpZi0+b3BzLT5tYXhfc2VnOwogCiAJ
YmxraWYtPmJsa2JrID0ga3phbGxvYyhzaXplb2Yoc3RydWN0IHhlbl9ibGtiayksIEdGUF9LRVJO
RUwpOwogCWlmICghYmxraWYtPmJsa2JrKSB7CkBAIC05NTMsOSArOTMyLDIwIEBAIGludCB4ZW5f
YmxraWZfaW5pdF9ibGtiayhzdHJ1Y3QgeGVuX2Jsa2lmICpibGtpZikKIAlzcGluX2xvY2tfaW5p
dCgmYmxrYmstPnBlbmRpbmdfZnJlZV9sb2NrKTsKIAlpbml0X3dhaXRxdWV1ZV9oZWFkKCZibGti
ay0+cGVuZGluZ19mcmVlX3dxKTsKIAotCWZvciAoaSA9IDA7IGkgPCB4ZW5fYmxraWZfcmVxczsg
aSsrKQorCWZvciAoaSA9IDA7IGkgPCB4ZW5fYmxraWZfcmVxczsgaSsrKSB7CisJCWJsa2JrLT5w
ZW5kaW5nX3JlcXNbaV0ubWFwID0ga3phbGxvYyhzaXplb2Yoc3RydWN0IGdudHRhYl9tYXBfZ3Jh
bnRfcmVmKSAqCisJCQkJbWF4X3NlZywgR0ZQX0tFUk5FTCk7CisJCWJsa2JrLT5wZW5kaW5nX3Jl
cXNbaV0udW5tYXAgPSBremFsbG9jKHNpemVvZihzdHJ1Y3QgZ250dGFiX3VubWFwX2dyYW50X3Jl
ZikgKgorCQkJCW1heF9zZWcsIEdGUF9LRVJORUwpOworCQlibGtiay0+cGVuZGluZ19yZXFzW2ld
LmJpb2xpc3QgPSBremFsbG9jKHNpemVvZihzdHJ1Y3QgYmlvICopICogbWF4X3NlZywKKwkJCQlH
RlBfS0VSTkVMKTsKKwkJYmxrYmstPnBlbmRpbmdfcmVxc1tpXS5zZWcgPSBremFsbG9jKHNpemVv
ZihzdHJ1Y3Qgc2VnX2J1ZikgKiBtYXhfc2VnLAorCQkJCUdGUF9LRVJORUwpOworCQlibGtiay0+
cGVuZGluZ19yZXFzW2ldLnBhZ2VzID0ga3phbGxvYyhzaXplb2Yoc3RydWN0IHBhZ2UgKikgKiBt
YXhfc2VnLAorCQkJCUdGUF9LRVJORUwpOwogCQlsaXN0X2FkZF90YWlsKCZibGtiay0+cGVuZGlu
Z19yZXFzW2ldLmZyZWVfbGlzdCwKIAkJCSAgICAgICZibGtiay0+cGVuZGluZ19mcmVlKTsKKwl9
CiAKIAlyZXR1cm4gMDsKIAo=

--_002_A21691DE07B84740B5F0B81466D5148A23BF7E2FSHSMSX102ccrcor_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 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_A21691DE07B84740B5F0B81466D5148A23BF7E2FSHSMSX102ccrcor_--


From xen-devel-bounces@lists.xen.org Mon Sep 17 06:48:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 06:48:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDV7Q-0005IO-Nt; Mon, 17 Sep 2012 06:47:44 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <pasik@iki.fi>) id 1TDV7P-0005IJ-Bi
	for xen-devel@lists.xen.org; Mon, 17 Sep 2012 06:47:43 +0000
Received: from [85.158.143.99:49139] by server-2.bemta-4.messagelabs.com id
	2C/83-06610-E87C6505; Mon, 17 Sep 2012 06:47:42 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-14.tower-216.messagelabs.com!1347864461!20995112!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA1MDQ1NDk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17574 invoked from network); 17 Sep 2012 06:47:42 -0000
Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25)
	by server-14.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 17 Sep 2012 06:47:42 -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 6C5B21D3F;
	Mon, 17 Sep 2012 09:47:41 +0300 (EEST)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id C804A2005D; Mon, 17 Sep 2012 09:47:40 +0300 (EEST)
Date: Mon, 17 Sep 2012 09:47:40 +0300
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: "Fajar A. Nugraha" <list@fajar.net>
Message-ID: <20120917064740.GE8912@reaktio.net>
References: <CC7BE9EE.2D8B7%ikozhukhov@gmail.com> <5056A6AC.5040502@gmail.com>
	<CAG1y0sczO296+UkFeNwQjGyV3sVssCA-W95iuY8KEEpFcDsJcQ@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAG1y0sczO296+UkFeNwQjGyV3sVssCA-W95iuY8KEEpFcDsJcQ@mail.gmail.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: Andrew Warkentin <andreww591@gmail.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] xen on illumos(OpenSolaris) based platform
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Sep 17, 2012 at 11:37:19AM +0700, Fajar A. Nugraha wrote:
> On Mon, Sep 17, 2012 at 11:27 AM, Andrew Warkentin <andreww591@gmail.com> wrote:
> > Igor Kozhukhov wrote:
> >>
> >> hello all!
> >>
> >> are you interested in port xen-4.1 to illumos(OpenSolaris) based platform?
> >> I have found old Sun works with xen-3.4.2 and updated it to xen-3.4.4
> >>
> >> I'll try to port xen-4.1.
> 
> > I'm interested specifically in HVM domU support.
> 
> > NCP3 hangs on boot on any versions of
> > Xen newer than 4.0.1 that I tried (even on 4.0.1, the kernel needs to be
> > patched ), and illumos hangs on boot on all the Xen versions that I tried.
> > These hangs are related to the PVHVM drivers (the install systems run OK,
> > and they don't include them).
> 
> I thought opensolaris (and derivatives) runs well as PV domU? What do
> you use HVM for?
> 

For some workloads it makes sense to use HVM (PVHVM). 
So the kernel bugs/issues in Illumos should be ironed out.. 

> Also, doesn't illumos support KVM? If you need full virtualization
> with *solaris, wouldn't it be easier for that particular purpose to
> try KVM instead?
>

A bit unusual suggestion on xen-devel mailinglist ;)

-- Pasi
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 17 06:48:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 06:48:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDV7Q-0005IO-Nt; Mon, 17 Sep 2012 06:47:44 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <pasik@iki.fi>) id 1TDV7P-0005IJ-Bi
	for xen-devel@lists.xen.org; Mon, 17 Sep 2012 06:47:43 +0000
Received: from [85.158.143.99:49139] by server-2.bemta-4.messagelabs.com id
	2C/83-06610-E87C6505; Mon, 17 Sep 2012 06:47:42 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-14.tower-216.messagelabs.com!1347864461!20995112!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA1MDQ1NDk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17574 invoked from network); 17 Sep 2012 06:47:42 -0000
Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25)
	by server-14.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 17 Sep 2012 06:47:42 -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 6C5B21D3F;
	Mon, 17 Sep 2012 09:47:41 +0300 (EEST)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id C804A2005D; Mon, 17 Sep 2012 09:47:40 +0300 (EEST)
Date: Mon, 17 Sep 2012 09:47:40 +0300
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: "Fajar A. Nugraha" <list@fajar.net>
Message-ID: <20120917064740.GE8912@reaktio.net>
References: <CC7BE9EE.2D8B7%ikozhukhov@gmail.com> <5056A6AC.5040502@gmail.com>
	<CAG1y0sczO296+UkFeNwQjGyV3sVssCA-W95iuY8KEEpFcDsJcQ@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAG1y0sczO296+UkFeNwQjGyV3sVssCA-W95iuY8KEEpFcDsJcQ@mail.gmail.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: Andrew Warkentin <andreww591@gmail.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] xen on illumos(OpenSolaris) based platform
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Sep 17, 2012 at 11:37:19AM +0700, Fajar A. Nugraha wrote:
> On Mon, Sep 17, 2012 at 11:27 AM, Andrew Warkentin <andreww591@gmail.com> wrote:
> > Igor Kozhukhov wrote:
> >>
> >> hello all!
> >>
> >> are you interested in port xen-4.1 to illumos(OpenSolaris) based platform?
> >> I have found old Sun works with xen-3.4.2 and updated it to xen-3.4.4
> >>
> >> I'll try to port xen-4.1.
> 
> > I'm interested specifically in HVM domU support.
> 
> > NCP3 hangs on boot on any versions of
> > Xen newer than 4.0.1 that I tried (even on 4.0.1, the kernel needs to be
> > patched ), and illumos hangs on boot on all the Xen versions that I tried.
> > These hangs are related to the PVHVM drivers (the install systems run OK,
> > and they don't include them).
> 
> I thought opensolaris (and derivatives) runs well as PV domU? What do
> you use HVM for?
> 

For some workloads it makes sense to use HVM (PVHVM). 
So the kernel bugs/issues in Illumos should be ironed out.. 

> Also, doesn't illumos support KVM? If you need full virtualization
> with *solaris, wouldn't it be easier for that particular purpose to
> try KVM instead?
>

A bit unusual suggestion on xen-devel mailinglist ;)

-- Pasi
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 17 06:57:43 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 06:57:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDVGi-0005Rq-QM; Mon, 17 Sep 2012 06:57: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 1TDVGg-0005Rl-Te
	for xen-devel@lists.xensource.com; Mon, 17 Sep 2012 06:57:19 +0000
Received: from [85.158.139.211:41709] by server-4.bemta-5.messagelabs.com id
	9F/D7-23042-EC9C6505; Mon, 17 Sep 2012 06:57:18 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-206.messagelabs.com!1347865037!18763638!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDk2Mzg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12252 invoked from network); 17 Sep 2012 06:57:17 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Sep 2012 06:57:17 -0000
X-IronPort-AV: E=Sophos;i="4.80,433,1344211200"; d="scan'208";a="14570711"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Sep 2012 06:57: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.279.1; Mon, 17 Sep 2012 07:57: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 1TDVGe-0006fh-VE;
	Mon, 17 Sep 2012 06:57:16 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1TDVGe-000572-JW;
	Mon, 17 Sep 2012 07:57:16 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-13791-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Mon, 17 Sep 2012 07:57:16 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13791: 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 13791 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13791/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore            fail   like 13782
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail like 13782
 test-amd64-amd64-xl-sedf     14 guest-localmigrate/x10       fail   like 13782
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail like 13782

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  12fa949b9060
baseline version:
 xen                  12fa949b9060

jobs:
 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-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-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-amd64-amd64-xl-win                                      fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Published tested tree is already up to date.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 17 06:57:43 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 06:57:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDVGi-0005Rq-QM; Mon, 17 Sep 2012 06:57: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 1TDVGg-0005Rl-Te
	for xen-devel@lists.xensource.com; Mon, 17 Sep 2012 06:57:19 +0000
Received: from [85.158.139.211:41709] by server-4.bemta-5.messagelabs.com id
	9F/D7-23042-EC9C6505; Mon, 17 Sep 2012 06:57:18 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-206.messagelabs.com!1347865037!18763638!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDk2Mzg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12252 invoked from network); 17 Sep 2012 06:57:17 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Sep 2012 06:57:17 -0000
X-IronPort-AV: E=Sophos;i="4.80,433,1344211200"; d="scan'208";a="14570711"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Sep 2012 06:57: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.279.1; Mon, 17 Sep 2012 07:57: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 1TDVGe-0006fh-VE;
	Mon, 17 Sep 2012 06:57:16 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1TDVGe-000572-JW;
	Mon, 17 Sep 2012 07:57:16 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-13791-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Mon, 17 Sep 2012 07:57:16 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13791: 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 13791 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13791/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore            fail   like 13782
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail like 13782
 test-amd64-amd64-xl-sedf     14 guest-localmigrate/x10       fail   like 13782
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail like 13782

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  12fa949b9060
baseline version:
 xen                  12fa949b9060

jobs:
 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-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-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-amd64-amd64-xl-win                                      fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Published tested tree is already up to date.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 17 07:31:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 07: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 1TDVnf-0006Bb-2y; Mon, 17 Sep 2012 07:31:23 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andre.Przywara@amd.com>) id 1TDVnd-0006BW-7t
	for xen-devel@lists.xen.org; Mon, 17 Sep 2012 07:31:21 +0000
X-Env-Sender: Andre.Przywara@amd.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1347867030!3574555!1
X-Originating-IP: [216.32.180.186]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6888 invoked from network); 17 Sep 2012 07:30:32 -0000
Received: from co1ehsobe003.messaging.microsoft.com (HELO
	co1outboundpool.messaging.microsoft.com) (216.32.180.186)
	by server-7.tower-27.messagelabs.com with AES128-SHA encrypted SMTP;
	17 Sep 2012 07:30:32 -0000
Received: from mail22-co1-R.bigfish.com (10.243.78.247) by
	CO1EHSOBE004.bigfish.com (10.243.66.67) with Microsoft SMTP Server id
	14.1.225.23; Mon, 17 Sep 2012 07:30:29 +0000
Received: from mail22-co1 (localhost [127.0.0.1])	by mail22-co1-R.bigfish.com
	(Postfix) with ESMTP id C9B50CA0145;
	Mon, 17 Sep 2012 07:30:29 +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: -3
X-BigFish: VPS-3(z551bizbb2dI98dI9371I1432I4015Id6f1izz1202h1d1ah1d2ahzzz2dh668h839hd25he5bhf0ah107ah1288h12a5h12a9h12bdh1155h)
Received: from mail22-co1 (localhost.localdomain [127.0.0.1]) by mail22-co1
	(MessageSwitch) id 1347867027956614_11608;
	Mon, 17 Sep 2012 07:30:27 +0000 (UTC)
Received: from CO1EHSMHS001.bigfish.com (unknown [10.243.78.238])	by
	mail22-co1.bigfish.com (Postfix) with ESMTP id DDA31880043;
	Mon, 17 Sep 2012 07:30:27 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	CO1EHSMHS001.bigfish.com (10.243.66.11) with Microsoft SMTP Server id
	14.1.225.23; Mon, 17 Sep 2012 07:30:27 +0000
X-WSS-ID: 0MAHGUQ-01-2O6-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 2908510280B1;	Mon, 17 Sep 2012 02:30:25 -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, 17 Sep 2012 02:30:29 -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;
	Mon, 17 Sep 2012 02:30:24 -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; Mon, 17 Sep 2012
	03:30:24 -0400
Received: from mail.osrc.amd.com (aluminium.osrc.amd.com [165.204.15.141])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id C310949C1EC;
	Mon, 17 Sep 2012 08:30:22 +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 87B461C8001; Mon, 17 Sep 2012
	09:30:22 +0200 (CEST)
Message-ID: <5056D152.2090708@amd.com>
Date: Mon, 17 Sep 2012 09:29:22 +0200
From: Andre Przywara <andre.przywara@amd.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:13.0) Gecko/20120615 Thunderbird/13.0.1
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
References: <501BC20F.3040205@amd.com>
	<20120803123628.GB10670@andromeda.dapyr.net>
	<20120817142237.GA8467@phenom.dumpdata.com>
	<20120914185822.GA7495@phenom.dumpdata.com>
In-Reply-To: <20120914185822.GA7495@phenom.dumpdata.com>
X-OriginatorOrg: amd.com
Cc: Konrad Rzeszutek Wilk <konrad@darnok.org>,
	Jeremy Fitzhardinge <jeremy@goop.org>, Dario Faggioli <raistlin@linux.it>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Dom0 crash with old style AMD NUMA detection
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 09/14/2012 08:58 PM, Konrad Rzeszutek Wilk wrote:
>>>> [    0.000000] Kernel panic - not syncing: Attempted to kill the idle task!
>>>> (XEN) Domain 0 crashed: 'noreboot' set - not rebooting.
>>>>
>>>>
>>>>
>>>> The obvious solution would be to explicitly deny northbridge scanning
>>>> when running as Dom0, though I am not sure how to implement this without
>>>> upsetting the other kernel folks about "that crappy Xen thing" again ;-)
>>>
>>> Heh.
>>> Is there a numa=0 option that could be used to override it to turn it
>>> off?
>>
>> Not compile tested.. but was thinking something like this:
>
> ping?

That looks good to me - at least for the time being.
I just want to check how this interacts with upcoming Dom0 NUMA support. 
It wouldn't be too clever if we deliberately disable NUMA and future Xen 
version will allow us to use it. So let me check if I can confine this 
turn-off to the fallback K8 northbridge reading.

Thanks,
Andre.

>>
>> diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c
>> index 43fd630..838cc1f 100644
>> --- a/arch/x86/xen/setup.c
>> +++ b/arch/x86/xen/setup.c
>> @@ -17,6 +17,7 @@
>>   #include <asm/e820.h>
>>   #include <asm/setup.h>
>>   #include <asm/acpi.h>
>> +#include <asm/numa.h>
>>   #include <asm/xen/hypervisor.h>
>>   #include <asm/xen/hypercall.h>
>>
>> @@ -528,4 +529,7 @@ void __init xen_arch_setup(void)
>>   	disable_cpufreq();
>>   	WARN_ON(set_pm_idle_to_default());
>>   	fiddle_vdso();
>> +#ifdef CONFIG_NUMA
>> +	numa_off = 1;
>> +#endif
>>   }
>



-- 
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 Mon Sep 17 07:31:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 07: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 1TDVnf-0006Bb-2y; Mon, 17 Sep 2012 07:31:23 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andre.Przywara@amd.com>) id 1TDVnd-0006BW-7t
	for xen-devel@lists.xen.org; Mon, 17 Sep 2012 07:31:21 +0000
X-Env-Sender: Andre.Przywara@amd.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1347867030!3574555!1
X-Originating-IP: [216.32.180.186]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6888 invoked from network); 17 Sep 2012 07:30:32 -0000
Received: from co1ehsobe003.messaging.microsoft.com (HELO
	co1outboundpool.messaging.microsoft.com) (216.32.180.186)
	by server-7.tower-27.messagelabs.com with AES128-SHA encrypted SMTP;
	17 Sep 2012 07:30:32 -0000
Received: from mail22-co1-R.bigfish.com (10.243.78.247) by
	CO1EHSOBE004.bigfish.com (10.243.66.67) with Microsoft SMTP Server id
	14.1.225.23; Mon, 17 Sep 2012 07:30:29 +0000
Received: from mail22-co1 (localhost [127.0.0.1])	by mail22-co1-R.bigfish.com
	(Postfix) with ESMTP id C9B50CA0145;
	Mon, 17 Sep 2012 07:30:29 +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: -3
X-BigFish: VPS-3(z551bizbb2dI98dI9371I1432I4015Id6f1izz1202h1d1ah1d2ahzzz2dh668h839hd25he5bhf0ah107ah1288h12a5h12a9h12bdh1155h)
Received: from mail22-co1 (localhost.localdomain [127.0.0.1]) by mail22-co1
	(MessageSwitch) id 1347867027956614_11608;
	Mon, 17 Sep 2012 07:30:27 +0000 (UTC)
Received: from CO1EHSMHS001.bigfish.com (unknown [10.243.78.238])	by
	mail22-co1.bigfish.com (Postfix) with ESMTP id DDA31880043;
	Mon, 17 Sep 2012 07:30:27 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	CO1EHSMHS001.bigfish.com (10.243.66.11) with Microsoft SMTP Server id
	14.1.225.23; Mon, 17 Sep 2012 07:30:27 +0000
X-WSS-ID: 0MAHGUQ-01-2O6-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 2908510280B1;	Mon, 17 Sep 2012 02:30:25 -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, 17 Sep 2012 02:30:29 -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;
	Mon, 17 Sep 2012 02:30:24 -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; Mon, 17 Sep 2012
	03:30:24 -0400
Received: from mail.osrc.amd.com (aluminium.osrc.amd.com [165.204.15.141])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id C310949C1EC;
	Mon, 17 Sep 2012 08:30:22 +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 87B461C8001; Mon, 17 Sep 2012
	09:30:22 +0200 (CEST)
Message-ID: <5056D152.2090708@amd.com>
Date: Mon, 17 Sep 2012 09:29:22 +0200
From: Andre Przywara <andre.przywara@amd.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:13.0) Gecko/20120615 Thunderbird/13.0.1
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
References: <501BC20F.3040205@amd.com>
	<20120803123628.GB10670@andromeda.dapyr.net>
	<20120817142237.GA8467@phenom.dumpdata.com>
	<20120914185822.GA7495@phenom.dumpdata.com>
In-Reply-To: <20120914185822.GA7495@phenom.dumpdata.com>
X-OriginatorOrg: amd.com
Cc: Konrad Rzeszutek Wilk <konrad@darnok.org>,
	Jeremy Fitzhardinge <jeremy@goop.org>, Dario Faggioli <raistlin@linux.it>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Dom0 crash with old style AMD NUMA detection
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 09/14/2012 08:58 PM, Konrad Rzeszutek Wilk wrote:
>>>> [    0.000000] Kernel panic - not syncing: Attempted to kill the idle task!
>>>> (XEN) Domain 0 crashed: 'noreboot' set - not rebooting.
>>>>
>>>>
>>>>
>>>> The obvious solution would be to explicitly deny northbridge scanning
>>>> when running as Dom0, though I am not sure how to implement this without
>>>> upsetting the other kernel folks about "that crappy Xen thing" again ;-)
>>>
>>> Heh.
>>> Is there a numa=0 option that could be used to override it to turn it
>>> off?
>>
>> Not compile tested.. but was thinking something like this:
>
> ping?

That looks good to me - at least for the time being.
I just want to check how this interacts with upcoming Dom0 NUMA support. 
It wouldn't be too clever if we deliberately disable NUMA and future Xen 
version will allow us to use it. So let me check if I can confine this 
turn-off to the fallback K8 northbridge reading.

Thanks,
Andre.

>>
>> diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c
>> index 43fd630..838cc1f 100644
>> --- a/arch/x86/xen/setup.c
>> +++ b/arch/x86/xen/setup.c
>> @@ -17,6 +17,7 @@
>>   #include <asm/e820.h>
>>   #include <asm/setup.h>
>>   #include <asm/acpi.h>
>> +#include <asm/numa.h>
>>   #include <asm/xen/hypervisor.h>
>>   #include <asm/xen/hypercall.h>
>>
>> @@ -528,4 +529,7 @@ void __init xen_arch_setup(void)
>>   	disable_cpufreq();
>>   	WARN_ON(set_pm_idle_to_default());
>>   	fiddle_vdso();
>> +#ifdef CONFIG_NUMA
>> +	numa_off = 1;
>> +#endif
>>   }
>



-- 
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 Mon Sep 17 08:13:29 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 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 1TDWS2-0007cc-Je; Mon, 17 Sep 2012 08: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 1TDWS1-0007cO-IP
	for xen-devel@lists.xen.org; Mon, 17 Sep 2012 08:13:05 +0000
Received: from [85.158.137.99:14423] by server-9.bemta-3.messagelabs.com id
	B7/82-15390-09BD6505; Mon, 17 Sep 2012 08:13:04 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-217.messagelabs.com!1347869583!17925361!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31458 invoked from network); 17 Sep 2012 08:13:03 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-14.tower-217.messagelabs.com with SMTP;
	17 Sep 2012 08:13:03 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 17 Sep 2012 09:13:03 +0100
Message-Id: <5056F7AB020000780009BB19@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 17 Sep 2012 09:12:59 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part2E1F259B.1__="
Cc: Jun Nakajima <jun.nakajima@intel.com>
Subject: [Xen-devel] [PATCH] x86/Intel: add further support for Ivy Bridge
 CPU models
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
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.

--=__Part2E1F259B.1__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

And some initial Haswell ones at once.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/arch/x86/acpi/cpu_idle.c
+++ b/xen/arch/x86/acpi/cpu_idle.c
@@ -105,11 +105,15 @@ static void do_get_hw_residencies(void *
=20
     switch ( c->x86_model )
     {
-    /* Ivy bridge */
-    case 0x3A:
     /* Sandy bridge */
     case 0x2A:
     case 0x2D:
+    /* Ivy bridge */
+    case 0x3A:
+    case 0x3E:
+    /* Haswell */
+    case 0x3c:
+    case 0x45:
         GET_PC2_RES(hw_res->pc2);
         GET_CC7_RES(hw_res->cc7);
         /* fall through */
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -1731,7 +1731,9 @@ static const struct lbr_info *last_branc
         /* Sandy Bridge */
         case 42: case 45:
         /* Ivy Bridge */
-        case 58:
+        case 58: case 62:
+        /* Haswell */
+        case 60: case 69:
             return nh_lbr;
             break;
         /* Atom */
--- a/xen/arch/x86/hvm/vmx/vpmu_core2.c
+++ b/xen/arch/x86/hvm/vmx/vpmu_core2.c
@@ -747,6 +747,7 @@ int vmx_vpmu_initialise(struct vcpu *v,=20
         case 46:
         case 47:
         case 58:
+        case 62:
             ret =3D core2_vpmu_initialise(v, vpmu_flags);
             if ( !ret )
                 vpmu->arch_vpmu_ops =3D &core2_vpmu_ops;




--=__Part2E1F259B.1__=
Content-Type: text/plain; name="x86-IvyBridge.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="x86-IvyBridge.patch"

x86/Intel: add further support for Ivy Bridge CPU models=0A=0AAnd some =
initial Haswell ones at once.=0A=0ASigned-off-by: Jan Beulich <jbeulich@sus=
e.com>=0A=0A--- a/xen/arch/x86/acpi/cpu_idle.c=0A+++ b/xen/arch/x86/acpi/cp=
u_idle.c=0A@@ -105,11 +105,15 @@ static void do_get_hw_residencies(void =
*=0A =0A     switch ( c->x86_model )=0A     {=0A-    /* Ivy bridge */=0A-  =
  case 0x3A:=0A     /* Sandy bridge */=0A     case 0x2A:=0A     case =
0x2D:=0A+    /* Ivy bridge */=0A+    case 0x3A:=0A+    case 0x3E:=0A+    =
/* Haswell */=0A+    case 0x3c:=0A+    case 0x45:=0A         GET_PC2_RES(hw=
_res->pc2);=0A         GET_CC7_RES(hw_res->cc7);=0A         /* fall =
through */=0A--- a/xen/arch/x86/hvm/vmx/vmx.c=0A+++ b/xen/arch/x86/hvm/vmx/=
vmx.c=0A@@ -1731,7 +1731,9 @@ static const struct lbr_info *last_branc=0A  =
       /* Sandy Bridge */=0A         case 42: case 45:=0A         /* Ivy =
Bridge */=0A-        case 58:=0A+        case 58: case 62:=0A+        /* =
Haswell */=0A+        case 60: case 69:=0A             return nh_lbr;=0A   =
          break;=0A         /* Atom */=0A--- a/xen/arch/x86/hvm/vmx/vpmu_co=
re2.c=0A+++ b/xen/arch/x86/hvm/vmx/vpmu_core2.c=0A@@ -747,6 +747,7 @@ int =
vmx_vpmu_initialise(struct vcpu *v, =0A         case 46:=0A         case =
47:=0A         case 58:=0A+        case 62:=0A             ret =3D =
core2_vpmu_initialise(v, vpmu_flags);=0A             if ( !ret )=0A        =
         vpmu->arch_vpmu_ops =3D &core2_vpmu_ops;=0A
--=__Part2E1F259B.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

--=__Part2E1F259B.1__=--


From xen-devel-bounces@lists.xen.org Mon Sep 17 08:13:29 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 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 1TDWS2-0007cc-Je; Mon, 17 Sep 2012 08: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 1TDWS1-0007cO-IP
	for xen-devel@lists.xen.org; Mon, 17 Sep 2012 08:13:05 +0000
Received: from [85.158.137.99:14423] by server-9.bemta-3.messagelabs.com id
	B7/82-15390-09BD6505; Mon, 17 Sep 2012 08:13:04 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-217.messagelabs.com!1347869583!17925361!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31458 invoked from network); 17 Sep 2012 08:13:03 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-14.tower-217.messagelabs.com with SMTP;
	17 Sep 2012 08:13:03 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 17 Sep 2012 09:13:03 +0100
Message-Id: <5056F7AB020000780009BB19@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 17 Sep 2012 09:12:59 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part2E1F259B.1__="
Cc: Jun Nakajima <jun.nakajima@intel.com>
Subject: [Xen-devel] [PATCH] x86/Intel: add further support for Ivy Bridge
 CPU models
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
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.

--=__Part2E1F259B.1__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

And some initial Haswell ones at once.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/arch/x86/acpi/cpu_idle.c
+++ b/xen/arch/x86/acpi/cpu_idle.c
@@ -105,11 +105,15 @@ static void do_get_hw_residencies(void *
=20
     switch ( c->x86_model )
     {
-    /* Ivy bridge */
-    case 0x3A:
     /* Sandy bridge */
     case 0x2A:
     case 0x2D:
+    /* Ivy bridge */
+    case 0x3A:
+    case 0x3E:
+    /* Haswell */
+    case 0x3c:
+    case 0x45:
         GET_PC2_RES(hw_res->pc2);
         GET_CC7_RES(hw_res->cc7);
         /* fall through */
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -1731,7 +1731,9 @@ static const struct lbr_info *last_branc
         /* Sandy Bridge */
         case 42: case 45:
         /* Ivy Bridge */
-        case 58:
+        case 58: case 62:
+        /* Haswell */
+        case 60: case 69:
             return nh_lbr;
             break;
         /* Atom */
--- a/xen/arch/x86/hvm/vmx/vpmu_core2.c
+++ b/xen/arch/x86/hvm/vmx/vpmu_core2.c
@@ -747,6 +747,7 @@ int vmx_vpmu_initialise(struct vcpu *v,=20
         case 46:
         case 47:
         case 58:
+        case 62:
             ret =3D core2_vpmu_initialise(v, vpmu_flags);
             if ( !ret )
                 vpmu->arch_vpmu_ops =3D &core2_vpmu_ops;




--=__Part2E1F259B.1__=
Content-Type: text/plain; name="x86-IvyBridge.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="x86-IvyBridge.patch"

x86/Intel: add further support for Ivy Bridge CPU models=0A=0AAnd some =
initial Haswell ones at once.=0A=0ASigned-off-by: Jan Beulich <jbeulich@sus=
e.com>=0A=0A--- a/xen/arch/x86/acpi/cpu_idle.c=0A+++ b/xen/arch/x86/acpi/cp=
u_idle.c=0A@@ -105,11 +105,15 @@ static void do_get_hw_residencies(void =
*=0A =0A     switch ( c->x86_model )=0A     {=0A-    /* Ivy bridge */=0A-  =
  case 0x3A:=0A     /* Sandy bridge */=0A     case 0x2A:=0A     case =
0x2D:=0A+    /* Ivy bridge */=0A+    case 0x3A:=0A+    case 0x3E:=0A+    =
/* Haswell */=0A+    case 0x3c:=0A+    case 0x45:=0A         GET_PC2_RES(hw=
_res->pc2);=0A         GET_CC7_RES(hw_res->cc7);=0A         /* fall =
through */=0A--- a/xen/arch/x86/hvm/vmx/vmx.c=0A+++ b/xen/arch/x86/hvm/vmx/=
vmx.c=0A@@ -1731,7 +1731,9 @@ static const struct lbr_info *last_branc=0A  =
       /* Sandy Bridge */=0A         case 42: case 45:=0A         /* Ivy =
Bridge */=0A-        case 58:=0A+        case 58: case 62:=0A+        /* =
Haswell */=0A+        case 60: case 69:=0A             return nh_lbr;=0A   =
          break;=0A         /* Atom */=0A--- a/xen/arch/x86/hvm/vmx/vpmu_co=
re2.c=0A+++ b/xen/arch/x86/hvm/vmx/vpmu_core2.c=0A@@ -747,6 +747,7 @@ int =
vmx_vpmu_initialise(struct vcpu *v, =0A         case 46:=0A         case =
47:=0A         case 58:=0A+        case 62:=0A             ret =3D =
core2_vpmu_initialise(v, vpmu_flags);=0A             if ( !ret )=0A        =
         vpmu->arch_vpmu_ops =3D &core2_vpmu_ops;=0A
--=__Part2E1F259B.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

--=__Part2E1F259B.1__=--


From xen-devel-bounces@lists.xen.org Mon Sep 17 08:18:11 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 08:18:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDWWc-0007v6-Aq; Mon, 17 Sep 2012 08:17: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 1TDWWb-0007uy-2N
	for xen-devel@lists.xen.org; Mon, 17 Sep 2012 08:17:49 +0000
Received: from [85.158.143.99:17329] by server-1.bemta-4.messagelabs.com id
	D6/DC-12504-CACD6505; Mon, 17 Sep 2012 08:17:48 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1347869867!30656055!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDk2Mzg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2937 invoked from network); 17 Sep 2012 08:17:47 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Sep 2012 08:17:47 -0000
X-IronPort-AV: E=Sophos;i="4.80,434,1344211200"; d="scan'208";a="14572556"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Sep 2012 08:17: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.279.1;
	Mon, 17 Sep 2012 09:17:47 +0100
Message-ID: <1347869865.14977.15.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Date: Mon, 17 Sep 2012 09:17:45 +0100
In-Reply-To: <1347632819-13684-1-git-send-email-andres@lagarcavilla.org>
References: <1347632819-13684-1-git-send-email-andres@lagarcavilla.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	xen-devel <xen-devel@lists.xen.org>,
	David Vrabel <david.vrabel@citrix.com>, David Miller <davem@davemloft.net>
Subject: Re: [Xen-devel] [PATCH] Xen backend support for paged out grant
	targets V4.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 I forgot to hit send on this on Friday, sorry. Also
s/xen.lists.org/lists.xen.org in the CC line...)

On Fri, 2012-09-14 at 15:26 +0100, Andres Lagar-Cavilla wrote:
> Since Xen-4.2, hvm domains may have portions of their memory paged out. When a
> foreign domain (such as dom0) attempts to map these frames, the map will
> initially fail. The hypervisor returns a suitable errno, and kicks an
> asynchronous page-in operation carried out by a helper. The foreign domain is
> expected to retry the mapping operation until it eventually succeeds. The
> foreign domain is not put to sleep because itself could be the one running the
> pager assist (typical scenario for dom0).
> 
> This patch adds support for this mechanism for backend drivers using grant
> mapping and copying operations. Specifically, this covers the blkback and
> gntdev drivers (which map foregin grants), and the netback driver (which copies

                           foreign

> foreign grants).
> 
> * Add a retry method for grants that fail with GNTST_eagain (i.e. because the
>   target foregin frame is paged out).

          foreign

> * Insert hooks with appropriate wrappers in the aforementioned drivers.
> 
> The retry loop is only invoked if the grant operation status is GNTST_eagain.
> It guarantees to leave a new status code different from GNTST_eagain. Any other
> status code results in identical code execution as before.
> 
> The retry loop performs 256 attempts with increasing time intervals through a
> 32 second period. It uses msleep to yield while waiting for the next retry.
[...]
> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

Acked-by: Ian Campbell <ian.campbell@citrix.com>

Since this is more about grant tables than netback this should probably
go via Konrad rather than Dave, is that OK with you Dave?

(there's one more typo below)

> ---
>  drivers/net/xen-netback/netback.c  |   11 ++------
>  drivers/xen/grant-table.c          |   53 ++++++++++++++++++++++++++++++++++++
>  drivers/xen/xenbus/xenbus_client.c |    6 ++--
>  include/xen/grant_table.h          |   12 ++++++++
>  4 files changed, 70 insertions(+), 12 deletions(-)
[...]
> diff --git a/include/xen/grant_table.h b/include/xen/grant_table.h
> index 11e27c3..da9386e 100644
> --- a/include/xen/grant_table.h
> +++ b/include/xen/grant_table.h
> @@ -189,4 +189,16 @@ int gnttab_map_refs(struct gnttab_map_grant_ref *map_ops,
>  int gnttab_unmap_refs(struct gnttab_unmap_grant_ref *unmap_ops,
>  		      struct page **pages, unsigned int count, bool clear_pte);
>  
> +/* Perform a batch of grant map/copy operations. Retry every batch slot
> + * for which the hypervisor returns GNTST_eagain. This is typically due 
> + * to paged out target frames.
> + *
> + * Will retry for 1, 2, ... 255 ms, i.e. 256 times during 32 seconds.
> + *
> + * Return value in each iand every status field of the batch guaranteed

                          and

> + * to not be GNTST_eagain. 
> + */
> +void gnttab_batch_map(struct gnttab_map_grant_ref *batch, unsigned count);
> +void gnttab_batch_copy(struct gnttab_copy *batch, unsigned count);
> +
>  #endif /* __ASM_GNTTAB_H__ */




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 17 08:18:11 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 08:18:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDWWc-0007v6-Aq; Mon, 17 Sep 2012 08:17: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 1TDWWb-0007uy-2N
	for xen-devel@lists.xen.org; Mon, 17 Sep 2012 08:17:49 +0000
Received: from [85.158.143.99:17329] by server-1.bemta-4.messagelabs.com id
	D6/DC-12504-CACD6505; Mon, 17 Sep 2012 08:17:48 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1347869867!30656055!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDk2Mzg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2937 invoked from network); 17 Sep 2012 08:17:47 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Sep 2012 08:17:47 -0000
X-IronPort-AV: E=Sophos;i="4.80,434,1344211200"; d="scan'208";a="14572556"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Sep 2012 08:17: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.279.1;
	Mon, 17 Sep 2012 09:17:47 +0100
Message-ID: <1347869865.14977.15.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Date: Mon, 17 Sep 2012 09:17:45 +0100
In-Reply-To: <1347632819-13684-1-git-send-email-andres@lagarcavilla.org>
References: <1347632819-13684-1-git-send-email-andres@lagarcavilla.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	xen-devel <xen-devel@lists.xen.org>,
	David Vrabel <david.vrabel@citrix.com>, David Miller <davem@davemloft.net>
Subject: Re: [Xen-devel] [PATCH] Xen backend support for paged out grant
	targets V4.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 I forgot to hit send on this on Friday, sorry. Also
s/xen.lists.org/lists.xen.org in the CC line...)

On Fri, 2012-09-14 at 15:26 +0100, Andres Lagar-Cavilla wrote:
> Since Xen-4.2, hvm domains may have portions of their memory paged out. When a
> foreign domain (such as dom0) attempts to map these frames, the map will
> initially fail. The hypervisor returns a suitable errno, and kicks an
> asynchronous page-in operation carried out by a helper. The foreign domain is
> expected to retry the mapping operation until it eventually succeeds. The
> foreign domain is not put to sleep because itself could be the one running the
> pager assist (typical scenario for dom0).
> 
> This patch adds support for this mechanism for backend drivers using grant
> mapping and copying operations. Specifically, this covers the blkback and
> gntdev drivers (which map foregin grants), and the netback driver (which copies

                           foreign

> foreign grants).
> 
> * Add a retry method for grants that fail with GNTST_eagain (i.e. because the
>   target foregin frame is paged out).

          foreign

> * Insert hooks with appropriate wrappers in the aforementioned drivers.
> 
> The retry loop is only invoked if the grant operation status is GNTST_eagain.
> It guarantees to leave a new status code different from GNTST_eagain. Any other
> status code results in identical code execution as before.
> 
> The retry loop performs 256 attempts with increasing time intervals through a
> 32 second period. It uses msleep to yield while waiting for the next retry.
[...]
> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

Acked-by: Ian Campbell <ian.campbell@citrix.com>

Since this is more about grant tables than netback this should probably
go via Konrad rather than Dave, is that OK with you Dave?

(there's one more typo below)

> ---
>  drivers/net/xen-netback/netback.c  |   11 ++------
>  drivers/xen/grant-table.c          |   53 ++++++++++++++++++++++++++++++++++++
>  drivers/xen/xenbus/xenbus_client.c |    6 ++--
>  include/xen/grant_table.h          |   12 ++++++++
>  4 files changed, 70 insertions(+), 12 deletions(-)
[...]
> diff --git a/include/xen/grant_table.h b/include/xen/grant_table.h
> index 11e27c3..da9386e 100644
> --- a/include/xen/grant_table.h
> +++ b/include/xen/grant_table.h
> @@ -189,4 +189,16 @@ int gnttab_map_refs(struct gnttab_map_grant_ref *map_ops,
>  int gnttab_unmap_refs(struct gnttab_unmap_grant_ref *unmap_ops,
>  		      struct page **pages, unsigned int count, bool clear_pte);
>  
> +/* Perform a batch of grant map/copy operations. Retry every batch slot
> + * for which the hypervisor returns GNTST_eagain. This is typically due 
> + * to paged out target frames.
> + *
> + * Will retry for 1, 2, ... 255 ms, i.e. 256 times during 32 seconds.
> + *
> + * Return value in each iand every status field of the batch guaranteed

                          and

> + * to not be GNTST_eagain. 
> + */
> +void gnttab_batch_map(struct gnttab_map_grant_ref *batch, unsigned count);
> +void gnttab_batch_copy(struct gnttab_copy *batch, unsigned count);
> +
>  #endif /* __ASM_GNTTAB_H__ */




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 17 08:25:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 08: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 1TDWe8-0008DD-8u; Mon, 17 Sep 2012 08:25: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 1TDWe6-0008D8-Ry
	for xen-devel@lists.xensource.com; Mon, 17 Sep 2012 08:25:35 +0000
Received: from [85.158.143.35:28316] by server-2.bemta-4.messagelabs.com id
	72/A5-06610-E7ED6505; Mon, 17 Sep 2012 08:25:34 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1347870331!15304831!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDk2Mzg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11650 invoked from network); 17 Sep 2012 08:25:32 -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;
	17 Sep 2012 08:25:32 -0000
X-IronPort-AV: E=Sophos;i="4.80,434,1344211200"; d="scan'208";a="14572787"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Sep 2012 08:25: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.279.1; Mon, 17 Sep 2012 09:25:31 +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 1TDWe3-0007Ch-71;
	Mon, 17 Sep 2012 08:25:31 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1TDWe3-0003KX-3Z;
	Mon, 17 Sep 2012 09:25:31 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-13792-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Mon, 17 Sep 2012 09:25:31 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [qemu-upstream-4.2-testing baseline test] 13792:
	tolerable FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

"Old" tested version had not actually been tested; therefore in this
flight we test it, rather than a new candidate.  The baseline, if
any, is the most recent actually tested revision.

flight 13792 qemu-upstream-4.2-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13792/

Failures :-/ but no regressions.

Tests which did not succeed,
including tests which could not be run:
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  9 guest-localmigrate fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail never pass
 test-amd64-amd64-qemuu-win   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-qemuu-win-vcpus1  9 guest-localmigrate      fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64  9 guest-localmigrate      fail never pass
 test-i386-i386-qemuu-win     16 leak-check/check             fail   never pass
 test-amd64-i386-qemuu-win-vcpus1 16 leak-check/check           fail never pass
 test-i386-i386-xl-qemuu-win   9 guest-localmigrate           fail   never pass
 test-amd64-i386-xend-qemuu-winxpsp3 16 leak-check/check        fail never pass
 test-amd64-i386-qemuu-win    16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemuu-win  9 guest-localmigrate           fail  never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail never pass
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass


jobs:
 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                           pass    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-win-vcpus1                             fail    
 test-amd64-i386-xl-qemuu-win-vcpus1                          fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-amd64-qemuu-win                                   fail    
 test-amd64-i386-qemuu-win                                    fail    
 test-i386-i386-qemuu-win                                     fail    
 test-amd64-amd64-xl-qemuu-win                                fail    
 test-i386-i386-xl-qemuu-win                                  fail    
 test-amd64-i386-xend-qemuu-winxpsp3                          fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


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 Sep 17 08:25:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 08: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 1TDWe8-0008DD-8u; Mon, 17 Sep 2012 08:25: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 1TDWe6-0008D8-Ry
	for xen-devel@lists.xensource.com; Mon, 17 Sep 2012 08:25:35 +0000
Received: from [85.158.143.35:28316] by server-2.bemta-4.messagelabs.com id
	72/A5-06610-E7ED6505; Mon, 17 Sep 2012 08:25:34 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1347870331!15304831!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDk2Mzg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11650 invoked from network); 17 Sep 2012 08:25:32 -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;
	17 Sep 2012 08:25:32 -0000
X-IronPort-AV: E=Sophos;i="4.80,434,1344211200"; d="scan'208";a="14572787"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Sep 2012 08:25: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.279.1; Mon, 17 Sep 2012 09:25:31 +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 1TDWe3-0007Ch-71;
	Mon, 17 Sep 2012 08:25:31 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1TDWe3-0003KX-3Z;
	Mon, 17 Sep 2012 09:25:31 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-13792-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Mon, 17 Sep 2012 09:25:31 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [qemu-upstream-4.2-testing baseline test] 13792:
	tolerable FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

"Old" tested version had not actually been tested; therefore in this
flight we test it, rather than a new candidate.  The baseline, if
any, is the most recent actually tested revision.

flight 13792 qemu-upstream-4.2-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13792/

Failures :-/ but no regressions.

Tests which did not succeed,
including tests which could not be run:
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  9 guest-localmigrate fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail never pass
 test-amd64-amd64-qemuu-win   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-qemuu-win-vcpus1  9 guest-localmigrate      fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64  9 guest-localmigrate      fail never pass
 test-i386-i386-qemuu-win     16 leak-check/check             fail   never pass
 test-amd64-i386-qemuu-win-vcpus1 16 leak-check/check           fail never pass
 test-i386-i386-xl-qemuu-win   9 guest-localmigrate           fail   never pass
 test-amd64-i386-xend-qemuu-winxpsp3 16 leak-check/check        fail never pass
 test-amd64-i386-qemuu-win    16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemuu-win  9 guest-localmigrate           fail  never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail never pass
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass


jobs:
 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                           pass    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-win-vcpus1                             fail    
 test-amd64-i386-xl-qemuu-win-vcpus1                          fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-amd64-qemuu-win                                   fail    
 test-amd64-i386-qemuu-win                                    fail    
 test-i386-i386-qemuu-win                                     fail    
 test-amd64-amd64-xl-qemuu-win                                fail    
 test-i386-i386-xl-qemuu-win                                  fail    
 test-amd64-i386-xend-qemuu-winxpsp3                          fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


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 Sep 17 08:44:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 08:44:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDWvt-0008Rs-0p; Mon, 17 Sep 2012 08:43: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 1TDWvr-0008Rn-9T
	for xen-devel@lists.xen.org; Mon, 17 Sep 2012 08:43:55 +0000
Received: from [85.158.143.99:32012] by server-3.bemta-4.messagelabs.com id
	27/51-08232-AC2E6505; Mon, 17 Sep 2012 08:43:54 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1347871432!24214507!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNzQ5NzA=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7343 invoked from network); 17 Sep 2012 08:43:54 -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;
	17 Sep 2012 08:43:54 -0000
X-IronPort-AV: E=Sophos;i="4.80,434,1344211200"; d="scan'208";a="208263435"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Sep 2012 08:43:52 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1;
	Mon, 17 Sep 2012 04:43:51 -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 1TDWvn-0008Iw-Hr;
	Mon, 17 Sep 2012 09:43:51 +0100
MIME-Version: 1.0
X-Mercurial-Node: ba1c6e807c8b1684a83e3692abcc5d42587f16f7
Message-ID: <ba1c6e807c8b1684a83e.1347871431@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Mon, 17 Sep 2012 09:43:51 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Cc: keir@xen.org, Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH] tools: bump SONAMEs for changes during 4.2
	development cycle
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 1347871358 -3600
# Node ID ba1c6e807c8b1684a83e3692abcc5d42587f16f7
# Parent  a649d26baee12239a12f5fba7e7746dc4b7d7c89
tools: bump SONAMEs for changes during 4.2 development cycle.

We mostly did this as we went along, only a couple of minor number
bumps were missed http://marc.info/?l=xen-devel&m=134366054929255&w=2:
 - Bumped libxl from 1.0.0 -> 1.0.1
 - Bumped libxenstore from 3.0.1 -> 3.0.2

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
This should be considered for 4.2.1.

diff -r a649d26baee1 -r ba1c6e807c8b tools/libxl/Makefile
--- a/tools/libxl/Makefile	Mon Sep 17 09:29:33 2012 +0100
+++ b/tools/libxl/Makefile	Mon Sep 17 09:42:38 2012 +0100
@@ -9,7 +9,7 @@ MAJOR = 2.0
 MINOR = 0
 
 XLUMAJOR = 1.0
-XLUMINOR = 0
+XLUMINOR = 1
 
 CFLAGS += -Werror -Wno-format-zero-length -Wmissing-declarations \
 	-Wno-declaration-after-statement -Wformat-nonliteral
diff -r a649d26baee1 -r ba1c6e807c8b tools/xenstore/Makefile
--- a/tools/xenstore/Makefile	Mon Sep 17 09:29:33 2012 +0100
+++ b/tools/xenstore/Makefile	Mon Sep 17 09:42:38 2012 +0100
@@ -2,7 +2,7 @@ XEN_ROOT=$(CURDIR)/../..
 include $(XEN_ROOT)/tools/Rules.mk
 
 MAJOR = 3.0
-MINOR = 1
+MINOR = 2
 
 CFLAGS += -Werror
 CFLAGS += -I.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 17 08:44:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 08:44:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDWvt-0008Rs-0p; Mon, 17 Sep 2012 08:43: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 1TDWvr-0008Rn-9T
	for xen-devel@lists.xen.org; Mon, 17 Sep 2012 08:43:55 +0000
Received: from [85.158.143.99:32012] by server-3.bemta-4.messagelabs.com id
	27/51-08232-AC2E6505; Mon, 17 Sep 2012 08:43:54 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1347871432!24214507!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNzQ5NzA=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7343 invoked from network); 17 Sep 2012 08:43:54 -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;
	17 Sep 2012 08:43:54 -0000
X-IronPort-AV: E=Sophos;i="4.80,434,1344211200"; d="scan'208";a="208263435"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Sep 2012 08:43:52 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1;
	Mon, 17 Sep 2012 04:43:51 -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 1TDWvn-0008Iw-Hr;
	Mon, 17 Sep 2012 09:43:51 +0100
MIME-Version: 1.0
X-Mercurial-Node: ba1c6e807c8b1684a83e3692abcc5d42587f16f7
Message-ID: <ba1c6e807c8b1684a83e.1347871431@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Mon, 17 Sep 2012 09:43:51 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Cc: keir@xen.org, Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH] tools: bump SONAMEs for changes during 4.2
	development cycle
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 1347871358 -3600
# Node ID ba1c6e807c8b1684a83e3692abcc5d42587f16f7
# Parent  a649d26baee12239a12f5fba7e7746dc4b7d7c89
tools: bump SONAMEs for changes during 4.2 development cycle.

We mostly did this as we went along, only a couple of minor number
bumps were missed http://marc.info/?l=xen-devel&m=134366054929255&w=2:
 - Bumped libxl from 1.0.0 -> 1.0.1
 - Bumped libxenstore from 3.0.1 -> 3.0.2

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
This should be considered for 4.2.1.

diff -r a649d26baee1 -r ba1c6e807c8b tools/libxl/Makefile
--- a/tools/libxl/Makefile	Mon Sep 17 09:29:33 2012 +0100
+++ b/tools/libxl/Makefile	Mon Sep 17 09:42:38 2012 +0100
@@ -9,7 +9,7 @@ MAJOR = 2.0
 MINOR = 0
 
 XLUMAJOR = 1.0
-XLUMINOR = 0
+XLUMINOR = 1
 
 CFLAGS += -Werror -Wno-format-zero-length -Wmissing-declarations \
 	-Wno-declaration-after-statement -Wformat-nonliteral
diff -r a649d26baee1 -r ba1c6e807c8b tools/xenstore/Makefile
--- a/tools/xenstore/Makefile	Mon Sep 17 09:29:33 2012 +0100
+++ b/tools/xenstore/Makefile	Mon Sep 17 09:42:38 2012 +0100
@@ -2,7 +2,7 @@ XEN_ROOT=$(CURDIR)/../..
 include $(XEN_ROOT)/tools/Rules.mk
 
 MAJOR = 3.0
-MINOR = 1
+MINOR = 2
 
 CFLAGS += -Werror
 CFLAGS += -I.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 17 09:05:22 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 09: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 1TDXGL-0000nM-Cp; Mon, 17 Sep 2012 09:05:05 +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 1TDXGK-0000nF-Ch
	for xen-devel@lists.xen.org; Mon, 17 Sep 2012 09:05:04 +0000
Received: from [85.158.143.35:28582] by server-2.bemta-4.messagelabs.com id
	24/7F-06610-FB7E6505; Mon, 17 Sep 2012 09:05:03 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1347872702!11785784!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDk2NDU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23385 invoked from network); 17 Sep 2012 09:05:02 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Sep 2012 09:05:02 -0000
X-IronPort-AV: E=Sophos;i="4.80,434,1344211200"; d="scan'208";a="14573824"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Sep 2012 09:05:02 +0000
Received: from Roger-2.local (10.31.3.231) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Mon, 17 Sep 2012 10:05:02 +0100
Message-ID: <5056E7C9.2080200@citrix.com>
Date: Mon, 17 Sep 2012 11:05:13 +0200
From: Roger Pau Monne <roger.pau@citrix.com>
User-Agent: Postbox 3.0.5 (Macintosh/20120826)
MIME-Version: 1.0
To: Igor Kozhukhov <ikozhukhov@gmail.com>
References: <CC7BE9EE.2D8B7%ikozhukhov@gmail.com>
In-Reply-To: <CC7BE9EE.2D8B7%ikozhukhov@gmail.com>
X-Enigmail-Version: 1.2.2
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] xen on illumos(OpenSolaris) based 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

Igor Kozhukhov wrote:
> hello all!
> 
> are you interested in port xen-4.1 to illumos(OpenSolaris) based platform?
> I have found old Sun works with xen-3.4.2 and updated it to xen-3.4.4

It's great to know there's still interest for Xen on the Solaris platform!

> 
> I'll try to port xen-4.1.

Please work against xen-unstable, it will be much more easier to
upstream the changes and get Solaris support in newer versions.

> can I file a bugs with issues on solaris based platform?
> where can I file a bugs - I have bout some issues and I'd like to provide fixes for solaris.

If the Solaris kernel is still working as Dom0/DomU, there's probably
not much work, you will have to look at the tools side, and check that
the remaining Solaris pieces are still working, and probably add new
ones, for example libxl currently doesn't have any kind of Solaris
support, but I see that libxc seems to have support for Solaris (don't
have any idea if that's in working condition).

Regards, Roger.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 17 09:05:22 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 09: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 1TDXGL-0000nM-Cp; Mon, 17 Sep 2012 09:05:05 +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 1TDXGK-0000nF-Ch
	for xen-devel@lists.xen.org; Mon, 17 Sep 2012 09:05:04 +0000
Received: from [85.158.143.35:28582] by server-2.bemta-4.messagelabs.com id
	24/7F-06610-FB7E6505; Mon, 17 Sep 2012 09:05:03 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1347872702!11785784!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDk2NDU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23385 invoked from network); 17 Sep 2012 09:05:02 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Sep 2012 09:05:02 -0000
X-IronPort-AV: E=Sophos;i="4.80,434,1344211200"; d="scan'208";a="14573824"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Sep 2012 09:05:02 +0000
Received: from Roger-2.local (10.31.3.231) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Mon, 17 Sep 2012 10:05:02 +0100
Message-ID: <5056E7C9.2080200@citrix.com>
Date: Mon, 17 Sep 2012 11:05:13 +0200
From: Roger Pau Monne <roger.pau@citrix.com>
User-Agent: Postbox 3.0.5 (Macintosh/20120826)
MIME-Version: 1.0
To: Igor Kozhukhov <ikozhukhov@gmail.com>
References: <CC7BE9EE.2D8B7%ikozhukhov@gmail.com>
In-Reply-To: <CC7BE9EE.2D8B7%ikozhukhov@gmail.com>
X-Enigmail-Version: 1.2.2
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] xen on illumos(OpenSolaris) based 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

Igor Kozhukhov wrote:
> hello all!
> 
> are you interested in port xen-4.1 to illumos(OpenSolaris) based platform?
> I have found old Sun works with xen-3.4.2 and updated it to xen-3.4.4

It's great to know there's still interest for Xen on the Solaris platform!

> 
> I'll try to port xen-4.1.

Please work against xen-unstable, it will be much more easier to
upstream the changes and get Solaris support in newer versions.

> can I file a bugs with issues on solaris based platform?
> where can I file a bugs - I have bout some issues and I'd like to provide fixes for solaris.

If the Solaris kernel is still working as Dom0/DomU, there's probably
not much work, you will have to look at the tools side, and check that
the remaining Solaris pieces are still working, and probably add new
ones, for example libxl currently doesn't have any kind of Solaris
support, but I see that libxc seems to have support for Solaris (don't
have any idea if that's in working condition).

Regards, Roger.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 17 09:18:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 09:18:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDXSf-00014H-Nr; Mon, 17 Sep 2012 09:17:49 +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 1TDXSd-00014A-Ut
	for xen-devel@lists.xen.org; Mon, 17 Sep 2012 09:17:48 +0000
Received: from [85.158.139.83:3128] by server-1.bemta-5.messagelabs.com id
	19/AD-32692-BBAE6505; Mon, 17 Sep 2012 09:17:47 +0000
X-Env-Sender: Christoph.Egger@amd.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1347873464!30279893!1
X-Originating-IP: [216.32.180.184]
X-SpamReason: No, hits=0.3 required=7.0 tests=MAILTO_TO_SPAM_ADDR
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18997 invoked from network); 17 Sep 2012 09:17:46 -0000
Received: from co1ehsobe001.messaging.microsoft.com (HELO
	co1outboundpool.messaging.microsoft.com) (216.32.180.184)
	by server-13.tower-182.messagelabs.com with AES128-SHA encrypted SMTP;
	17 Sep 2012 09:17:46 -0000
Received: from mail142-co1-R.bigfish.com (10.243.78.232) by
	CO1EHSOBE013.bigfish.com (10.243.66.76) with Microsoft SMTP Server id
	14.1.225.23; Mon, 17 Sep 2012 09:17:44 +0000
Received: from mail142-co1 (localhost [127.0.0.1])	by
	mail142-co1-R.bigfish.com (Postfix) with ESMTP id EC08B7800B9;
	Mon, 17 Sep 2012 09:17:43 +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: -10
X-BigFish: VPS-10(zzbb2dI98dI9371I1432I41c5Nzz1202h1d1ah1d2ahzz8275bhz2dh668h839hd25he5bhf0ah107ah1288h12a5h12a9h12bdh1155h)
Received: from mail142-co1 (localhost.localdomain [127.0.0.1]) by mail142-co1
	(MessageSwitch) id 134787346270813_24663;
	Mon, 17 Sep 2012 09:17:42 +0000 (UTC)
Received: from CO1EHSMHS024.bigfish.com (unknown [10.243.78.236])	by
	mail142-co1.bigfish.com (Postfix) with ESMTP id 080A1BC0046;
	Mon, 17 Sep 2012 09:17:42 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	CO1EHSMHS024.bigfish.com (10.243.66.34) with Microsoft SMTP Server id
	14.1.225.23; Mon, 17 Sep 2012 09:17:40 +0000
X-WSS-ID: 0MAHLTE-01-21N-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 2502210280B5;	Mon, 17 Sep 2012 04:17:38 -0500 (CDT)
Received: from SAUSEXDAG06.amd.com (163.181.55.7) by sausexedgep01.amd.com
	(163.181.36.54) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Mon, 17 Sep 2012 04:17:42 -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;
	Mon, 17 Sep 2012 04:17:38 -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, 17 Sep 2012
	05:17:37 -0400
Message-ID: <5056EAAF.70401@amd.com>
Date: Mon, 17 Sep 2012 11:17:35 +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: "Fajar A. Nugraha" <list@fajar.net>
References: <CC7BE9EE.2D8B7%ikozhukhov@gmail.com> <5056A6AC.5040502@gmail.com>
	<CAG1y0sczO296+UkFeNwQjGyV3sVssCA-W95iuY8KEEpFcDsJcQ@mail.gmail.com>
In-Reply-To: <CAG1y0sczO296+UkFeNwQjGyV3sVssCA-W95iuY8KEEpFcDsJcQ@mail.gmail.com>
X-OriginatorOrg: amd.com
Cc: Andrew Warkentin <andreww591@gmail.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] xen on illumos(OpenSolaris) based 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 09/17/12 06:37, Fajar A. Nugraha wrote:

> On Mon, Sep 17, 2012 at 11:27 AM, Andrew Warkentin <andreww591@gmail.com> wrote:
> I thought opensolaris (and derivatives) runs well as PV domU? What do
> you use HVM for?
> 
> Also, doesn't illumos support KVM? If you need full virtualization
> with *solaris, wouldn't it be easier for that particular purpose to
> try KVM instead?


Mmmmmh... KVM lacks AMD support :(

Christoph



-- 
---to satisfy European Law for business letters:
Advanced Micro Devices GmbH
Einsteinring 24, 85689 Dornach b. Muenchen
Geschaeftsfuehrer: Alberto Bozzo
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 Sep 17 09:18:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 09:18:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDXSf-00014H-Nr; Mon, 17 Sep 2012 09:17:49 +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 1TDXSd-00014A-Ut
	for xen-devel@lists.xen.org; Mon, 17 Sep 2012 09:17:48 +0000
Received: from [85.158.139.83:3128] by server-1.bemta-5.messagelabs.com id
	19/AD-32692-BBAE6505; Mon, 17 Sep 2012 09:17:47 +0000
X-Env-Sender: Christoph.Egger@amd.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1347873464!30279893!1
X-Originating-IP: [216.32.180.184]
X-SpamReason: No, hits=0.3 required=7.0 tests=MAILTO_TO_SPAM_ADDR
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18997 invoked from network); 17 Sep 2012 09:17:46 -0000
Received: from co1ehsobe001.messaging.microsoft.com (HELO
	co1outboundpool.messaging.microsoft.com) (216.32.180.184)
	by server-13.tower-182.messagelabs.com with AES128-SHA encrypted SMTP;
	17 Sep 2012 09:17:46 -0000
Received: from mail142-co1-R.bigfish.com (10.243.78.232) by
	CO1EHSOBE013.bigfish.com (10.243.66.76) with Microsoft SMTP Server id
	14.1.225.23; Mon, 17 Sep 2012 09:17:44 +0000
Received: from mail142-co1 (localhost [127.0.0.1])	by
	mail142-co1-R.bigfish.com (Postfix) with ESMTP id EC08B7800B9;
	Mon, 17 Sep 2012 09:17:43 +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: -10
X-BigFish: VPS-10(zzbb2dI98dI9371I1432I41c5Nzz1202h1d1ah1d2ahzz8275bhz2dh668h839hd25he5bhf0ah107ah1288h12a5h12a9h12bdh1155h)
Received: from mail142-co1 (localhost.localdomain [127.0.0.1]) by mail142-co1
	(MessageSwitch) id 134787346270813_24663;
	Mon, 17 Sep 2012 09:17:42 +0000 (UTC)
Received: from CO1EHSMHS024.bigfish.com (unknown [10.243.78.236])	by
	mail142-co1.bigfish.com (Postfix) with ESMTP id 080A1BC0046;
	Mon, 17 Sep 2012 09:17:42 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	CO1EHSMHS024.bigfish.com (10.243.66.34) with Microsoft SMTP Server id
	14.1.225.23; Mon, 17 Sep 2012 09:17:40 +0000
X-WSS-ID: 0MAHLTE-01-21N-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 2502210280B5;	Mon, 17 Sep 2012 04:17:38 -0500 (CDT)
Received: from SAUSEXDAG06.amd.com (163.181.55.7) by sausexedgep01.amd.com
	(163.181.36.54) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Mon, 17 Sep 2012 04:17:42 -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;
	Mon, 17 Sep 2012 04:17:38 -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, 17 Sep 2012
	05:17:37 -0400
Message-ID: <5056EAAF.70401@amd.com>
Date: Mon, 17 Sep 2012 11:17:35 +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: "Fajar A. Nugraha" <list@fajar.net>
References: <CC7BE9EE.2D8B7%ikozhukhov@gmail.com> <5056A6AC.5040502@gmail.com>
	<CAG1y0sczO296+UkFeNwQjGyV3sVssCA-W95iuY8KEEpFcDsJcQ@mail.gmail.com>
In-Reply-To: <CAG1y0sczO296+UkFeNwQjGyV3sVssCA-W95iuY8KEEpFcDsJcQ@mail.gmail.com>
X-OriginatorOrg: amd.com
Cc: Andrew Warkentin <andreww591@gmail.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] xen on illumos(OpenSolaris) based 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 09/17/12 06:37, Fajar A. Nugraha wrote:

> On Mon, Sep 17, 2012 at 11:27 AM, Andrew Warkentin <andreww591@gmail.com> wrote:
> I thought opensolaris (and derivatives) runs well as PV domU? What do
> you use HVM for?
> 
> Also, doesn't illumos support KVM? If you need full virtualization
> with *solaris, wouldn't it be easier for that particular purpose to
> try KVM instead?


Mmmmmh... KVM lacks AMD support :(

Christoph



-- 
---to satisfy European Law for business letters:
Advanced Micro Devices GmbH
Einsteinring 24, 85689 Dornach b. Muenchen
Geschaeftsfuehrer: Alberto Bozzo
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 Sep 17 09:27:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 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 1TDXbx-0001EL-Oi; Mon, 17 Sep 2012 09:27:25 +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 1TDXbx-0001EG-9b
	for xen-devel@lists.xen.org; Mon, 17 Sep 2012 09:27:25 +0000
Received: from [85.158.139.83:28690] by server-5.bemta-5.messagelabs.com id
	71/A0-30514-CFCE6505; Mon, 17 Sep 2012 09:27:24 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-11.tower-182.messagelabs.com!1347874043!23603471!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA1MDQ5ODc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1415 invoked from network); 17 Sep 2012 09:27:24 -0000
Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25)
	by server-11.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 17 Sep 2012 09:27:24 -0000
X-Originating-Ip: [194.89.68.22]
Received: from ydin.reaktio.net (reaktio.net [194.89.68.22])
	by smtp.tele.fi (Postfix) with ESMTP id 57B35164C;
	Mon, 17 Sep 2012 12:27:23 +0300 (EEST)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id E04FB2005D; Mon, 17 Sep 2012 12:27:22 +0300 (EEST)
Date: Mon, 17 Sep 2012 12:27:22 +0300
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: Igor Kozhukhov <ikozhukhov@gmail.com>
Message-ID: <20120917092722.GF8912@reaktio.net>
References: <CC7BE9EE.2D8B7%ikozhukhov@gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CC7BE9EE.2D8B7%ikozhukhov@gmail.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] xen on illumos(OpenSolaris) based platform
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Sun, Sep 16, 2012 at 08:41:19PM +0400, Igor Kozhukhov wrote:
>    hello all!
> 
>    are you interested in port xen-4.1 to illumos(OpenSolaris) based platform?
>    I have found old Sun works with xen-3.4.2 and updated it to xen-3.4.4
>

Oh, and please post the current patches against Xen 3.4.4,
it'd be interesting to take a look at the patches to see how much changes
are needed for Illumos/Opensolaris.

I assume these are the ex. Sun/OpenSolaris XVM bits, that Oracle discontinued? 

-- Pasi


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 17 09:27:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 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 1TDXbx-0001EL-Oi; Mon, 17 Sep 2012 09:27:25 +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 1TDXbx-0001EG-9b
	for xen-devel@lists.xen.org; Mon, 17 Sep 2012 09:27:25 +0000
Received: from [85.158.139.83:28690] by server-5.bemta-5.messagelabs.com id
	71/A0-30514-CFCE6505; Mon, 17 Sep 2012 09:27:24 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-11.tower-182.messagelabs.com!1347874043!23603471!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA1MDQ5ODc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1415 invoked from network); 17 Sep 2012 09:27:24 -0000
Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25)
	by server-11.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 17 Sep 2012 09:27:24 -0000
X-Originating-Ip: [194.89.68.22]
Received: from ydin.reaktio.net (reaktio.net [194.89.68.22])
	by smtp.tele.fi (Postfix) with ESMTP id 57B35164C;
	Mon, 17 Sep 2012 12:27:23 +0300 (EEST)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id E04FB2005D; Mon, 17 Sep 2012 12:27:22 +0300 (EEST)
Date: Mon, 17 Sep 2012 12:27:22 +0300
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: Igor Kozhukhov <ikozhukhov@gmail.com>
Message-ID: <20120917092722.GF8912@reaktio.net>
References: <CC7BE9EE.2D8B7%ikozhukhov@gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CC7BE9EE.2D8B7%ikozhukhov@gmail.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] xen on illumos(OpenSolaris) based platform
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Sun, Sep 16, 2012 at 08:41:19PM +0400, Igor Kozhukhov wrote:
>    hello all!
> 
>    are you interested in port xen-4.1 to illumos(OpenSolaris) based platform?
>    I have found old Sun works with xen-3.4.2 and updated it to xen-3.4.4
>

Oh, and please post the current patches against Xen 3.4.4,
it'd be interesting to take a look at the patches to see how much changes
are needed for Illumos/Opensolaris.

I assume these are the ex. Sun/OpenSolaris XVM bits, that Oracle discontinued? 

-- Pasi


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 17 09:30:48 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 09:30:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDXet-0001Ls-H1; Mon, 17 Sep 2012 09:30:27 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andreslc@gridcentric.ca>) id 1TDXes-0001Lj-GS
	for xen-devel@lists.xen.org; Mon, 17 Sep 2012 09:30:26 +0000
Received: from [85.158.137.99:58205] by server-12.bemta-3.messagelabs.com id
	92/2E-10384-1BDE6505; Mon, 17 Sep 2012 09:30:25 +0000
X-Env-Sender: andreslc@gridcentric.ca
X-Msg-Ref: server-3.tower-217.messagelabs.com!1347874223!12892477!1
X-Originating-IP: [209.85.213.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17132 invoked from network); 17 Sep 2012 09:30:24 -0000
Received: from mail-yw0-f45.google.com (HELO mail-yw0-f45.google.com)
	(209.85.213.45)
	by server-3.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Sep 2012 09:30:24 -0000
Received: by yhpp34 with SMTP id p34so1657679yhp.32
	for <xen-devel@lists.xen.org>; Mon, 17 Sep 2012 02:29:23 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=subject:mime-version:content-type:from:in-reply-to:date:cc
	:content-transfer-encoding:message-id:references:to:x-mailer
	:x-gm-message-state;
	bh=M3rgYuWFiHkazTgdd1MjoVLOK7aCLeXwFkngSuB95FY=;
	b=iJkZbAdRBgiLVxLxcu8co2SNJoiYFDjfpQJe2WwuPj6UMHIBLH2PsTMuIkpHRAbKlb
	9J2lqQUTXdEr9cMaJ58y7B8m5bb0fk5YXxSB0MQOkuhYg5NUsjGrfKSKm1kqg8Ll9LXp
	xDtllUs9S7AV0b+My+tmfHXTfYH4h4v0/H/gjvHV3xOy4KJhe8NX6UH0lL4e33f0YUAD
	YAkvoEUyDub5u3nFBensvmoNkUveTk1lU4SCPfGFEyN7FM98dNngNstXev68oo8Crg7s
	JIaf9K2vx9Os0j6xzr3vPcYUO3xeLpWl1W/i36Yvf5gM5wV+m09kIj8llqEVlr8jQH1B
	3UzA==
Received: by 10.236.161.7 with SMTP id v7mr722602yhk.36.1347874163783;
	Mon, 17 Sep 2012 02:29:23 -0700 (PDT)
Received: from [10.80.114.249] (firewall.ctxuk.citrix.com. [62.200.22.2])
	by mx.google.com with ESMTPS id y10sm13398046yhd.6.2012.09.17.02.29.20
	(version=TLSv1/SSLv3 cipher=OTHER);
	Mon, 17 Sep 2012 02:29:21 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1278)
From: Andres Lagar-Cavilla <andreslc@gridcentric.ca>
In-Reply-To: <1347869865.14977.15.camel@zakaz.uk.xensource.com>
Date: Mon, 17 Sep 2012 05:29:24 -0400
Message-Id: <5B5132A4-93B2-41D0-B1A6-048810565DB5@gridcentric.ca>
References: <1347632819-13684-1-git-send-email-andres@lagarcavilla.org>
	<1347869865.14977.15.camel@zakaz.uk.xensource.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
X-Mailer: Apple Mail (2.1278)
X-Gm-Message-State: ALoCoQk8ZIyI47PDd8FRqgWW3Fowr6WHEiObH/u8ntysuhr56DIpUyxmmJlJNYd1QdydBLqx9uIa
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	xen-devel <xen-devel@lists.xen.org>,
	David Vrabel <david.vrabel@citrix.com>, David Miller <davem@davemloft.net>,
	Andres Lagar-Cavilla <andres@lagarcavilla.org>
Subject: Re: [Xen-devel] [PATCH] Xen backend support for paged out grant
	targets V4.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <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 Sep 17, 2012, at 4:17 AM, Ian Campbell wrote:

> (I think I forgot to hit send on this on Friday, sorry. Also
> s/xen.lists.org/lists.xen.org in the CC line=85)
I'm on a roll here=85

> =

> On Fri, 2012-09-14 at 15:26 +0100, Andres Lagar-Cavilla wrote:
>> Since Xen-4.2, hvm domains may have portions of their memory paged out. =
When a
>> foreign domain (such as dom0) attempts to map these frames, the map will
>> initially fail. The hypervisor returns a suitable errno, and kicks an
>> asynchronous page-in operation carried out by a helper. The foreign doma=
in is
>> expected to retry the mapping operation until it eventually succeeds. The
>> foreign domain is not put to sleep because itself could be the one runni=
ng the
>> pager assist (typical scenario for dom0).
>> =

>> This patch adds support for this mechanism for backend drivers using gra=
nt
>> mapping and copying operations. Specifically, this covers the blkback and
>> gntdev drivers (which map foregin grants), and the netback driver (which=
 copies
> =

>                           foreign
> =

>> foreign grants).
>> =

>> * Add a retry method for grants that fail with GNTST_eagain (i.e. becaus=
e the
>>  target foregin frame is paged out).
> =

>          foreign
> =

>> * Insert hooks with appropriate wrappers in the aforementioned drivers.
>> =

>> The retry loop is only invoked if the grant operation status is GNTST_ea=
gain.
>> It guarantees to leave a new status code different from GNTST_eagain. An=
y other
>> status code results in identical code execution as before.
>> =

>> The retry loop performs 256 attempts with increasing time intervals thro=
ugh a
>> 32 second period. It uses msleep to yield while waiting for the next ret=
ry.
> [...]
>> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
> =

> Acked-by: Ian Campbell <ian.campbell@citrix.com>
> =

> Since this is more about grant tables than netback this should probably
> go via Konrad rather than Dave, is that OK with you Dave?

If that is the case hopefully Konrad can deal with the two typos? Otherwise=
 happy to re-spin the patch.
Thanks!
Andres

> =

> (there's one more typo below)
> =

>> ---
>> drivers/net/xen-netback/netback.c  |   11 ++------
>> drivers/xen/grant-table.c          |   53 ++++++++++++++++++++++++++++++=
++++++
>> drivers/xen/xenbus/xenbus_client.c |    6 ++--
>> include/xen/grant_table.h          |   12 ++++++++
>> 4 files changed, 70 insertions(+), 12 deletions(-)
> [...]
>> diff --git a/include/xen/grant_table.h b/include/xen/grant_table.h
>> index 11e27c3..da9386e 100644
>> --- a/include/xen/grant_table.h
>> +++ b/include/xen/grant_table.h
>> @@ -189,4 +189,16 @@ int gnttab_map_refs(struct gnttab_map_grant_ref *ma=
p_ops,
>> int gnttab_unmap_refs(struct gnttab_unmap_grant_ref *unmap_ops,
>> 		      struct page **pages, unsigned int count, bool clear_pte);
>> =

>> +/* Perform a batch of grant map/copy operations. Retry every batch slot
>> + * for which the hypervisor returns GNTST_eagain. This is typically due =

>> + * to paged out target frames.
>> + *
>> + * Will retry for 1, 2, ... 255 ms, i.e. 256 times during 32 seconds.
>> + *
>> + * Return value in each iand every status field of the batch guaranteed
> =

>                          and
> =

>> + * to not be GNTST_eagain. =

>> + */
>> +void gnttab_batch_map(struct gnttab_map_grant_ref *batch, unsigned coun=
t);
>> +void gnttab_batch_copy(struct gnttab_copy *batch, unsigned count);
>> +
>> #endif /* __ASM_GNTTAB_H__ */
> =

> =

> =

> --
> 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 Mon Sep 17 09:30:48 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 09:30:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDXet-0001Ls-H1; Mon, 17 Sep 2012 09:30:27 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andreslc@gridcentric.ca>) id 1TDXes-0001Lj-GS
	for xen-devel@lists.xen.org; Mon, 17 Sep 2012 09:30:26 +0000
Received: from [85.158.137.99:58205] by server-12.bemta-3.messagelabs.com id
	92/2E-10384-1BDE6505; Mon, 17 Sep 2012 09:30:25 +0000
X-Env-Sender: andreslc@gridcentric.ca
X-Msg-Ref: server-3.tower-217.messagelabs.com!1347874223!12892477!1
X-Originating-IP: [209.85.213.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17132 invoked from network); 17 Sep 2012 09:30:24 -0000
Received: from mail-yw0-f45.google.com (HELO mail-yw0-f45.google.com)
	(209.85.213.45)
	by server-3.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Sep 2012 09:30:24 -0000
Received: by yhpp34 with SMTP id p34so1657679yhp.32
	for <xen-devel@lists.xen.org>; Mon, 17 Sep 2012 02:29:23 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=subject:mime-version:content-type:from:in-reply-to:date:cc
	:content-transfer-encoding:message-id:references:to:x-mailer
	:x-gm-message-state;
	bh=M3rgYuWFiHkazTgdd1MjoVLOK7aCLeXwFkngSuB95FY=;
	b=iJkZbAdRBgiLVxLxcu8co2SNJoiYFDjfpQJe2WwuPj6UMHIBLH2PsTMuIkpHRAbKlb
	9J2lqQUTXdEr9cMaJ58y7B8m5bb0fk5YXxSB0MQOkuhYg5NUsjGrfKSKm1kqg8Ll9LXp
	xDtllUs9S7AV0b+My+tmfHXTfYH4h4v0/H/gjvHV3xOy4KJhe8NX6UH0lL4e33f0YUAD
	YAkvoEUyDub5u3nFBensvmoNkUveTk1lU4SCPfGFEyN7FM98dNngNstXev68oo8Crg7s
	JIaf9K2vx9Os0j6xzr3vPcYUO3xeLpWl1W/i36Yvf5gM5wV+m09kIj8llqEVlr8jQH1B
	3UzA==
Received: by 10.236.161.7 with SMTP id v7mr722602yhk.36.1347874163783;
	Mon, 17 Sep 2012 02:29:23 -0700 (PDT)
Received: from [10.80.114.249] (firewall.ctxuk.citrix.com. [62.200.22.2])
	by mx.google.com with ESMTPS id y10sm13398046yhd.6.2012.09.17.02.29.20
	(version=TLSv1/SSLv3 cipher=OTHER);
	Mon, 17 Sep 2012 02:29:21 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1278)
From: Andres Lagar-Cavilla <andreslc@gridcentric.ca>
In-Reply-To: <1347869865.14977.15.camel@zakaz.uk.xensource.com>
Date: Mon, 17 Sep 2012 05:29:24 -0400
Message-Id: <5B5132A4-93B2-41D0-B1A6-048810565DB5@gridcentric.ca>
References: <1347632819-13684-1-git-send-email-andres@lagarcavilla.org>
	<1347869865.14977.15.camel@zakaz.uk.xensource.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
X-Mailer: Apple Mail (2.1278)
X-Gm-Message-State: ALoCoQk8ZIyI47PDd8FRqgWW3Fowr6WHEiObH/u8ntysuhr56DIpUyxmmJlJNYd1QdydBLqx9uIa
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	xen-devel <xen-devel@lists.xen.org>,
	David Vrabel <david.vrabel@citrix.com>, David Miller <davem@davemloft.net>,
	Andres Lagar-Cavilla <andres@lagarcavilla.org>
Subject: Re: [Xen-devel] [PATCH] Xen backend support for paged out grant
	targets V4.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <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 Sep 17, 2012, at 4:17 AM, Ian Campbell wrote:

> (I think I forgot to hit send on this on Friday, sorry. Also
> s/xen.lists.org/lists.xen.org in the CC line=85)
I'm on a roll here=85

> =

> On Fri, 2012-09-14 at 15:26 +0100, Andres Lagar-Cavilla wrote:
>> Since Xen-4.2, hvm domains may have portions of their memory paged out. =
When a
>> foreign domain (such as dom0) attempts to map these frames, the map will
>> initially fail. The hypervisor returns a suitable errno, and kicks an
>> asynchronous page-in operation carried out by a helper. The foreign doma=
in is
>> expected to retry the mapping operation until it eventually succeeds. The
>> foreign domain is not put to sleep because itself could be the one runni=
ng the
>> pager assist (typical scenario for dom0).
>> =

>> This patch adds support for this mechanism for backend drivers using gra=
nt
>> mapping and copying operations. Specifically, this covers the blkback and
>> gntdev drivers (which map foregin grants), and the netback driver (which=
 copies
> =

>                           foreign
> =

>> foreign grants).
>> =

>> * Add a retry method for grants that fail with GNTST_eagain (i.e. becaus=
e the
>>  target foregin frame is paged out).
> =

>          foreign
> =

>> * Insert hooks with appropriate wrappers in the aforementioned drivers.
>> =

>> The retry loop is only invoked if the grant operation status is GNTST_ea=
gain.
>> It guarantees to leave a new status code different from GNTST_eagain. An=
y other
>> status code results in identical code execution as before.
>> =

>> The retry loop performs 256 attempts with increasing time intervals thro=
ugh a
>> 32 second period. It uses msleep to yield while waiting for the next ret=
ry.
> [...]
>> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
> =

> Acked-by: Ian Campbell <ian.campbell@citrix.com>
> =

> Since this is more about grant tables than netback this should probably
> go via Konrad rather than Dave, is that OK with you Dave?

If that is the case hopefully Konrad can deal with the two typos? Otherwise=
 happy to re-spin the patch.
Thanks!
Andres

> =

> (there's one more typo below)
> =

>> ---
>> drivers/net/xen-netback/netback.c  |   11 ++------
>> drivers/xen/grant-table.c          |   53 ++++++++++++++++++++++++++++++=
++++++
>> drivers/xen/xenbus/xenbus_client.c |    6 ++--
>> include/xen/grant_table.h          |   12 ++++++++
>> 4 files changed, 70 insertions(+), 12 deletions(-)
> [...]
>> diff --git a/include/xen/grant_table.h b/include/xen/grant_table.h
>> index 11e27c3..da9386e 100644
>> --- a/include/xen/grant_table.h
>> +++ b/include/xen/grant_table.h
>> @@ -189,4 +189,16 @@ int gnttab_map_refs(struct gnttab_map_grant_ref *ma=
p_ops,
>> int gnttab_unmap_refs(struct gnttab_unmap_grant_ref *unmap_ops,
>> 		      struct page **pages, unsigned int count, bool clear_pte);
>> =

>> +/* Perform a batch of grant map/copy operations. Retry every batch slot
>> + * for which the hypervisor returns GNTST_eagain. This is typically due =

>> + * to paged out target frames.
>> + *
>> + * Will retry for 1, 2, ... 255 ms, i.e. 256 times during 32 seconds.
>> + *
>> + * Return value in each iand every status field of the batch guaranteed
> =

>                          and
> =

>> + * to not be GNTST_eagain. =

>> + */
>> +void gnttab_batch_map(struct gnttab_map_grant_ref *batch, unsigned coun=
t);
>> +void gnttab_batch_copy(struct gnttab_copy *batch, unsigned count);
>> +
>> #endif /* __ASM_GNTTAB_H__ */
> =

> =

> =

> --
> 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 Mon Sep 17 09:43:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 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 1TDXqx-0001bE-Q1; Mon, 17 Sep 2012 09:42: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 1TDXqw-0001b9-Bl
	for xen-devel@lists.xen.org; Mon, 17 Sep 2012 09:42:54 +0000
Received: from [85.158.139.211:11517] by server-7.bemta-5.messagelabs.com id
	AE/71-19703-D90F6505; Mon, 17 Sep 2012 09:42:53 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-206.messagelabs.com!1347874971!18793844!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDk2NDU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25589 invoked from network); 17 Sep 2012 09:42:53 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Sep 2012 09:42:53 -0000
X-IronPort-AV: E=Sophos;i="4.80,434,1344211200"; d="scan'208";a="14574852"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Sep 2012 09:42: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.279.1;
	Mon, 17 Sep 2012 10:42:46 +0100
Message-ID: <1347874964.14977.34.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Matt Wilson <msw@amazon.com>
Date: Mon, 17 Sep 2012 10:42:44 +0100
In-Reply-To: <3b3582f4dc423daa8040.1346992558@u002268147cd4502c336d.ant.amazon.com>
References: <patchbomb.1346992557@u002268147cd4502c336d.ant.amazon.com>
	<3b3582f4dc423daa8040.1346992558@u002268147cd4502c336d.ant.amazon.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 1 of 2 v3] tools: check for documentation
 generation tools at configure 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 Fri, 2012-09-07 at 05:35 +0100, Matt Wilson wrote:
> It is sometimes hard to discover all the optional tools that should be
> on a system to build all available Xen documentation. By checking for
> documentation generation tools at ./configure time and displaying a
> warning, Xen packagers will more easily learn about new optional build
> dependencies, like markdown, when they are introduced.
> 
> Signed-off-by: Matt Wilson <msw@amazon.com>

While investigating an (unrelated) issue with the cronjob that generates
http://xenbits.xen.org/docs/unstable/ I had a sudden though about a
downside of this approach.

Trying to run ./configure on xenbits results in:
        $ ./configure 
        checking build system type... x86_64-unknown-linux-gnu
        checking host system type... x86_64-unknown-linux-gnu
        checking for gcc... no
        checking for cc... no
        checking for cl.exe... no
        configure: error: in `/home/xendocs/cronjobs/working/docs/unstable/tree/tools':
        configure: error: no acceptable C compiler found in $PATH
        See `config.log' for more details

Which is a bit annoying if all you wanted was to build docs. I'm not
sure I really want to advocate putting gcc on xenbits. I suppose I could
put a dummy shell script in $PATH.

AIUI autoconf allows you to define that a configure script calls a
sub-configure script. Could we use this at the toplevel to call both
tools/configure and a new docs/configure? Then my docs scripts could
just call docs/configure?

FWIW the unrelated issue was:
        $ make -C docs/ clean
        /bin/sh: gcc: not found
        /bin/sh: arithmetic expression: expecting primary: ""
which I think is down to the gcc version check in Config.mk.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 17 09:43:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 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 1TDXqx-0001bE-Q1; Mon, 17 Sep 2012 09:42: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 1TDXqw-0001b9-Bl
	for xen-devel@lists.xen.org; Mon, 17 Sep 2012 09:42:54 +0000
Received: from [85.158.139.211:11517] by server-7.bemta-5.messagelabs.com id
	AE/71-19703-D90F6505; Mon, 17 Sep 2012 09:42:53 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-206.messagelabs.com!1347874971!18793844!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDk2NDU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25589 invoked from network); 17 Sep 2012 09:42:53 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Sep 2012 09:42:53 -0000
X-IronPort-AV: E=Sophos;i="4.80,434,1344211200"; d="scan'208";a="14574852"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Sep 2012 09:42: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.279.1;
	Mon, 17 Sep 2012 10:42:46 +0100
Message-ID: <1347874964.14977.34.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Matt Wilson <msw@amazon.com>
Date: Mon, 17 Sep 2012 10:42:44 +0100
In-Reply-To: <3b3582f4dc423daa8040.1346992558@u002268147cd4502c336d.ant.amazon.com>
References: <patchbomb.1346992557@u002268147cd4502c336d.ant.amazon.com>
	<3b3582f4dc423daa8040.1346992558@u002268147cd4502c336d.ant.amazon.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 1 of 2 v3] tools: check for documentation
 generation tools at configure 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 Fri, 2012-09-07 at 05:35 +0100, Matt Wilson wrote:
> It is sometimes hard to discover all the optional tools that should be
> on a system to build all available Xen documentation. By checking for
> documentation generation tools at ./configure time and displaying a
> warning, Xen packagers will more easily learn about new optional build
> dependencies, like markdown, when they are introduced.
> 
> Signed-off-by: Matt Wilson <msw@amazon.com>

While investigating an (unrelated) issue with the cronjob that generates
http://xenbits.xen.org/docs/unstable/ I had a sudden though about a
downside of this approach.

Trying to run ./configure on xenbits results in:
        $ ./configure 
        checking build system type... x86_64-unknown-linux-gnu
        checking host system type... x86_64-unknown-linux-gnu
        checking for gcc... no
        checking for cc... no
        checking for cl.exe... no
        configure: error: in `/home/xendocs/cronjobs/working/docs/unstable/tree/tools':
        configure: error: no acceptable C compiler found in $PATH
        See `config.log' for more details

Which is a bit annoying if all you wanted was to build docs. I'm not
sure I really want to advocate putting gcc on xenbits. I suppose I could
put a dummy shell script in $PATH.

AIUI autoconf allows you to define that a configure script calls a
sub-configure script. Could we use this at the toplevel to call both
tools/configure and a new docs/configure? Then my docs scripts could
just call docs/configure?

FWIW the unrelated issue was:
        $ make -C docs/ clean
        /bin/sh: gcc: not found
        /bin/sh: arithmetic expression: expecting primary: ""
which I think is down to the gcc version check in Config.mk.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 17 09:49:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 09:49:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDXwe-0001kY-JR; Mon, 17 Sep 2012 09:48:48 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ikozhukhov@gmail.com>) id 1TDXwd-0001kR-Py
	for xen-devel@lists.xen.org; Mon, 17 Sep 2012 09:48:48 +0000
Received: from [85.158.139.83:46013] by server-9.bemta-5.messagelabs.com id
	9F/68-20529-FF1F6505; Mon, 17 Sep 2012 09:48:47 +0000
X-Env-Sender: ikozhukhov@gmail.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1347875326!23481530!1
X-Originating-IP: [209.85.217.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-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25597 invoked from network); 17 Sep 2012 09:48:46 -0000
Received: from mail-lb0-f173.google.com (HELO mail-lb0-f173.google.com)
	(209.85.217.173)
	by server-16.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Sep 2012 09:48:46 -0000
Received: by lbbgm13 with SMTP id gm13so4929771lbb.32
	for <xen-devel@lists.xen.org>; Mon, 17 Sep 2012 02:48:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=user-agent:date:subject:from:to:message-id:thread-topic:in-reply-to
	:mime-version:content-type:content-transfer-encoding;
	bh=PTEyjfMv9qR7AAKI/tk56ylxqjX1PakEpPOoxsxLXzY=;
	b=fO4RQGaeHh1yzovm4chsBNJb96OhaxxZB+6d/rST6ppziI/E5b2BVEJg4jrHs2on/b
	sAWsvLDxqaBVUybMzLz0kzFd5sDqbY85jyFY+OaVS//T7SaSkGNS+v9G7hZl4lEvjkg4
	S+A8gG+jAmLzQaPMBUV90904/7fyvI6oC6+h2l+SiWm9BDpAKfBLjpLu7+LRlAt4hACj
	S7JFskyt3XwRz+iFPG+F4O3dnfjS6AQ6O6Qskoouxzqsf5A1+bmX7UU7L8t5iKDdPNoC
	/LoWmsLZl8JyXIA3+px+S+uilV7FPz6T5nSqks2/bZ+3XqwWqPf0sH4mEO/vNzhMfdnS
	xL7g==
Received: by 10.112.85.200 with SMTP id j8mr3757914lbz.41.1347875325783;
	Mon, 17 Sep 2012 02:48:45 -0700 (PDT)
Received: from [172.16.90.16] ([91.204.58.44])
	by mx.google.com with ESMTPS id o3sm2465952lbk.6.2012.09.17.02.48.43
	(version=SSLv3 cipher=OTHER); Mon, 17 Sep 2012 02:48:44 -0700 (PDT)
User-Agent: Microsoft-MacOutlook/14.2.3.120616
Date: Mon, 17 Sep 2012 13:48:38 +0400
From: Igor Kozhukhov <ikozhukhov@gmail.com>
To: Andrew Warkentin <andreww591@gmail.com>,
	<xen-devel@lists.xen.org>
Message-ID: <CC7CD7E5.2D949%ikozhukhov@gmail.com>
Thread-Topic: [Xen-devel] xen on illumos(OpenSolaris) based platform
In-Reply-To: <5056A6AC.5040502@gmail.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] xen on illumos(OpenSolaris) based 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

NCP3 have old kernel - ON134 build.

DilOS based on illumos.

But these systems have Debian package manager - dpkg+apt.

I have updates for DPKG+APT for DilOS - added '-R' flag for more friendly
with IPS, added zones support.

We can install new packages to another root.

Example:
apt-get -R /<mount> install pkg [pkg1 pkg2 pkg3]

IPS:
pkg -R /<mount> install pkg [pkg1 pkg2 pkg3]

And I have updates for solaris zones.

New DilOS 1.1a2 will have packages with xen-3.4.4 and will be released Sep
18.
If you want - you can try.

---
Best regards,
Igor Kozhukhov
IRC# igork




On 9/17/12 8:27 AM, "Andrew Warkentin" <andreww591@gmail.com> wrote:

>Igor Kozhukhov wrote:
>> hello all!
>>
>> are you interested in port xen-4.1 to illumos(OpenSolaris) based
>>platform?
>> I have found old Sun works with xen-3.4.2 and updated it to xen-3.4.4
>>
>> I'll try to port xen-4.1.
>>
>> can I file a bugs with issues on solaris based platform?
>> where can I file a bugs - I have bout some issues and I'd like to
>> provide fixes for solaris.
>>
>>
>I'm interested specifically in HVM domU support. I'm using NCP3 on a
>minimal Debian 6.0 dom0 (with a kernel from XCP 1.5 and the Debian 6.0
>version of Xen 4.0.1 with patches to qemu-dm to support custom graphics
>and input servers for desktop use), but would like to update to both a
>newer Solaris distribution and a newer Xen version. NCP3 hangs on boot
>on any versions of Xen newer than 4.0.1 that I tried (even on 4.0.1, the
>kernel needs to be patched ), and illumos hangs on boot on all the Xen
>versions that I tried. These hangs are related to the PVHVM drivers (the
>install systems run OK, and they don't include them). Right now, I am
>trying to debug the problem with NCP3 and then will move onto illumos
>(I'm not sure if the problem is the same or not; illumos hangs sooner in
>the boot process than NCP3).
>
>_______________________________________________
>Xen-devel mailing list
>Xen-devel@lists.xen.org
>http://lists.xen.org/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 Sep 17 09:49:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 09:49:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDXwe-0001kY-JR; Mon, 17 Sep 2012 09:48:48 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ikozhukhov@gmail.com>) id 1TDXwd-0001kR-Py
	for xen-devel@lists.xen.org; Mon, 17 Sep 2012 09:48:48 +0000
Received: from [85.158.139.83:46013] by server-9.bemta-5.messagelabs.com id
	9F/68-20529-FF1F6505; Mon, 17 Sep 2012 09:48:47 +0000
X-Env-Sender: ikozhukhov@gmail.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1347875326!23481530!1
X-Originating-IP: [209.85.217.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-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25597 invoked from network); 17 Sep 2012 09:48:46 -0000
Received: from mail-lb0-f173.google.com (HELO mail-lb0-f173.google.com)
	(209.85.217.173)
	by server-16.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Sep 2012 09:48:46 -0000
Received: by lbbgm13 with SMTP id gm13so4929771lbb.32
	for <xen-devel@lists.xen.org>; Mon, 17 Sep 2012 02:48:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=user-agent:date:subject:from:to:message-id:thread-topic:in-reply-to
	:mime-version:content-type:content-transfer-encoding;
	bh=PTEyjfMv9qR7AAKI/tk56ylxqjX1PakEpPOoxsxLXzY=;
	b=fO4RQGaeHh1yzovm4chsBNJb96OhaxxZB+6d/rST6ppziI/E5b2BVEJg4jrHs2on/b
	sAWsvLDxqaBVUybMzLz0kzFd5sDqbY85jyFY+OaVS//T7SaSkGNS+v9G7hZl4lEvjkg4
	S+A8gG+jAmLzQaPMBUV90904/7fyvI6oC6+h2l+SiWm9BDpAKfBLjpLu7+LRlAt4hACj
	S7JFskyt3XwRz+iFPG+F4O3dnfjS6AQ6O6Qskoouxzqsf5A1+bmX7UU7L8t5iKDdPNoC
	/LoWmsLZl8JyXIA3+px+S+uilV7FPz6T5nSqks2/bZ+3XqwWqPf0sH4mEO/vNzhMfdnS
	xL7g==
Received: by 10.112.85.200 with SMTP id j8mr3757914lbz.41.1347875325783;
	Mon, 17 Sep 2012 02:48:45 -0700 (PDT)
Received: from [172.16.90.16] ([91.204.58.44])
	by mx.google.com with ESMTPS id o3sm2465952lbk.6.2012.09.17.02.48.43
	(version=SSLv3 cipher=OTHER); Mon, 17 Sep 2012 02:48:44 -0700 (PDT)
User-Agent: Microsoft-MacOutlook/14.2.3.120616
Date: Mon, 17 Sep 2012 13:48:38 +0400
From: Igor Kozhukhov <ikozhukhov@gmail.com>
To: Andrew Warkentin <andreww591@gmail.com>,
	<xen-devel@lists.xen.org>
Message-ID: <CC7CD7E5.2D949%ikozhukhov@gmail.com>
Thread-Topic: [Xen-devel] xen on illumos(OpenSolaris) based platform
In-Reply-To: <5056A6AC.5040502@gmail.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] xen on illumos(OpenSolaris) based 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

NCP3 have old kernel - ON134 build.

DilOS based on illumos.

But these systems have Debian package manager - dpkg+apt.

I have updates for DPKG+APT for DilOS - added '-R' flag for more friendly
with IPS, added zones support.

We can install new packages to another root.

Example:
apt-get -R /<mount> install pkg [pkg1 pkg2 pkg3]

IPS:
pkg -R /<mount> install pkg [pkg1 pkg2 pkg3]

And I have updates for solaris zones.

New DilOS 1.1a2 will have packages with xen-3.4.4 and will be released Sep
18.
If you want - you can try.

---
Best regards,
Igor Kozhukhov
IRC# igork




On 9/17/12 8:27 AM, "Andrew Warkentin" <andreww591@gmail.com> wrote:

>Igor Kozhukhov wrote:
>> hello all!
>>
>> are you interested in port xen-4.1 to illumos(OpenSolaris) based
>>platform?
>> I have found old Sun works with xen-3.4.2 and updated it to xen-3.4.4
>>
>> I'll try to port xen-4.1.
>>
>> can I file a bugs with issues on solaris based platform?
>> where can I file a bugs - I have bout some issues and I'd like to
>> provide fixes for solaris.
>>
>>
>I'm interested specifically in HVM domU support. I'm using NCP3 on a
>minimal Debian 6.0 dom0 (with a kernel from XCP 1.5 and the Debian 6.0
>version of Xen 4.0.1 with patches to qemu-dm to support custom graphics
>and input servers for desktop use), but would like to update to both a
>newer Solaris distribution and a newer Xen version. NCP3 hangs on boot
>on any versions of Xen newer than 4.0.1 that I tried (even on 4.0.1, the
>kernel needs to be patched ), and illumos hangs on boot on all the Xen
>versions that I tried. These hangs are related to the PVHVM drivers (the
>install systems run OK, and they don't include them). Right now, I am
>trying to debug the problem with NCP3 and then will move onto illumos
>(I'm not sure if the problem is the same or not; illumos hangs sooner in
>the boot process than NCP3).
>
>_______________________________________________
>Xen-devel mailing list
>Xen-devel@lists.xen.org
>http://lists.xen.org/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 Sep 17 09:54:48 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 09:54:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDY2C-0001tG-F1; Mon, 17 Sep 2012 09:54:32 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ikozhukhov@gmail.com>) id 1TDY2B-0001tA-Lo
	for xen-devel@lists.xen.org; Mon, 17 Sep 2012 09:54:31 +0000
Received: from [85.158.143.99:8912] by server-3.bemta-4.messagelabs.com id
	D7/99-08232-753F6505; Mon, 17 Sep 2012 09:54:31 +0000
X-Env-Sender: ikozhukhov@gmail.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1347875669!29734825!1
X-Originating-IP: [209.85.217.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-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 459 invoked from network); 17 Sep 2012 09:54:30 -0000
Received: from mail-lb0-f173.google.com (HELO mail-lb0-f173.google.com)
	(209.85.217.173)
	by server-13.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Sep 2012 09:54:30 -0000
Received: by lbbgm13 with SMTP id gm13so4933426lbb.32
	for <xen-devel@lists.xen.org>; Mon, 17 Sep 2012 02:54:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=user-agent:date:subject:from:to:cc:message-id:thread-topic
	:in-reply-to:mime-version:content-type:content-transfer-encoding;
	bh=hRFispQ/OoLHI8U130Ls5DpRC/S9GrTeawG/0xjNj6Y=;
	b=y0SxQU1ITHgLoMeiAu4qMGLAFmhLCebC9F9sfGc3j2eaNi2sdVoA5WPvKWD4+yxW3M
	FipL7jnCFhTNvYY0ANDuWepXbrCEinTPxFJmCJ9Gsr8CX+slGTKWGWNCd+WrQSmaaUCP
	etGz9o+Z1Isu9fAgahevuEbgP3XIYMM819BR+46sW7UbCLaTkAFX7aOMIQ+8YrymbztL
	lwYjjYbmOTzWo1nmMvtV3Vfzu8omSUMbid9QkO8ll4tfYwSKGBOW4+XJkFLi+bH5hp3v
	LGkD9wtR9WKs1BUZi1tbmvJ0UeC+1F6prb7inf9eYuOAVuQa/f1eS9qA/oY4kFv4XPIv
	rfgA==
Received: by 10.152.102.137 with SMTP id fo9mr9294676lab.35.1347875669360;
	Mon, 17 Sep 2012 02:54:29 -0700 (PDT)
Received: from [172.16.90.16] ([91.204.58.44])
	by mx.google.com with ESMTPS id d1sm2469643lbh.7.2012.09.17.02.54.26
	(version=SSLv3 cipher=OTHER); Mon, 17 Sep 2012 02:54:28 -0700 (PDT)
User-Agent: Microsoft-MacOutlook/14.2.3.120616
Date: Mon, 17 Sep 2012 13:54:21 +0400
From: Igor Kozhukhov <ikozhukhov@gmail.com>
To: "Fajar A. Nugraha" <list@fajar.net>,
	Andrew Warkentin <andreww591@gmail.com>
Message-ID: <CC7CDAD5.2D967%ikozhukhov@gmail.com>
Thread-Topic: [Xen-devel] xen on illumos(OpenSolaris) based platform
In-Reply-To: <CAG1y0sczO296+UkFeNwQjGyV3sVssCA-W95iuY8KEEpFcDsJcQ@mail.gmail.com>
Mime-version: 1.0
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] xen on illumos(OpenSolaris) based 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

About KVM - you need to have EPT support CPU - I have no it.

Driver for KVM without EPT support have coredumps and need more works for
stable.

OpenIndiana(OpenSolaris fork) have xen-3.4.2 with solaris patches - but
have no builds for it.

I have found sources on opensolaris.org site, port it to userland build
system, and try to upgrade to xen-3.4.4.

DilOS contain packages with KVM drivers and you can try to use it.

I'm interested in XEN on DilOS.

---
Best regards,
Igor Kozhukhov
IRC# igork




On 9/17/12 8:37 AM, "Fajar A. Nugraha" <list@fajar.net> wrote:

>On Mon, Sep 17, 2012 at 11:27 AM, Andrew Warkentin <andreww591@gmail.com>
>wrote:
>> Igor Kozhukhov wrote:
>>>
>>> hello all!
>>>
>>> are you interested in port xen-4.1 to illumos(OpenSolaris) based
>>>platform?
>>> I have found old Sun works with xen-3.4.2 and updated it to xen-3.4.4
>>>
>>> I'll try to port xen-4.1.
>
>> I'm interested specifically in HVM domU support.
>
>> NCP3 hangs on boot on any versions of
>> Xen newer than 4.0.1 that I tried (even on 4.0.1, the kernel needs to be
>> patched ), and illumos hangs on boot on all the Xen versions that I
>>tried.
>> These hangs are related to the PVHVM drivers (the install systems run
>>OK,
>> and they don't include them).
>
>I thought opensolaris (and derivatives) runs well as PV domU? What do
>you use HVM for?
>
>Also, doesn't illumos support KVM? If you need full virtualization
>with *solaris, wouldn't it be easier for that particular purpose to
>try KVM instead?
>
>-- 
>Fajar
>
>_______________________________________________
>Xen-devel mailing list
>Xen-devel@lists.xen.org
>http://lists.xen.org/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 Sep 17 09:54:48 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 09:54:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDY2C-0001tG-F1; Mon, 17 Sep 2012 09:54:32 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ikozhukhov@gmail.com>) id 1TDY2B-0001tA-Lo
	for xen-devel@lists.xen.org; Mon, 17 Sep 2012 09:54:31 +0000
Received: from [85.158.143.99:8912] by server-3.bemta-4.messagelabs.com id
	D7/99-08232-753F6505; Mon, 17 Sep 2012 09:54:31 +0000
X-Env-Sender: ikozhukhov@gmail.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1347875669!29734825!1
X-Originating-IP: [209.85.217.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-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 459 invoked from network); 17 Sep 2012 09:54:30 -0000
Received: from mail-lb0-f173.google.com (HELO mail-lb0-f173.google.com)
	(209.85.217.173)
	by server-13.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Sep 2012 09:54:30 -0000
Received: by lbbgm13 with SMTP id gm13so4933426lbb.32
	for <xen-devel@lists.xen.org>; Mon, 17 Sep 2012 02:54:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=user-agent:date:subject:from:to:cc:message-id:thread-topic
	:in-reply-to:mime-version:content-type:content-transfer-encoding;
	bh=hRFispQ/OoLHI8U130Ls5DpRC/S9GrTeawG/0xjNj6Y=;
	b=y0SxQU1ITHgLoMeiAu4qMGLAFmhLCebC9F9sfGc3j2eaNi2sdVoA5WPvKWD4+yxW3M
	FipL7jnCFhTNvYY0ANDuWepXbrCEinTPxFJmCJ9Gsr8CX+slGTKWGWNCd+WrQSmaaUCP
	etGz9o+Z1Isu9fAgahevuEbgP3XIYMM819BR+46sW7UbCLaTkAFX7aOMIQ+8YrymbztL
	lwYjjYbmOTzWo1nmMvtV3Vfzu8omSUMbid9QkO8ll4tfYwSKGBOW4+XJkFLi+bH5hp3v
	LGkD9wtR9WKs1BUZi1tbmvJ0UeC+1F6prb7inf9eYuOAVuQa/f1eS9qA/oY4kFv4XPIv
	rfgA==
Received: by 10.152.102.137 with SMTP id fo9mr9294676lab.35.1347875669360;
	Mon, 17 Sep 2012 02:54:29 -0700 (PDT)
Received: from [172.16.90.16] ([91.204.58.44])
	by mx.google.com with ESMTPS id d1sm2469643lbh.7.2012.09.17.02.54.26
	(version=SSLv3 cipher=OTHER); Mon, 17 Sep 2012 02:54:28 -0700 (PDT)
User-Agent: Microsoft-MacOutlook/14.2.3.120616
Date: Mon, 17 Sep 2012 13:54:21 +0400
From: Igor Kozhukhov <ikozhukhov@gmail.com>
To: "Fajar A. Nugraha" <list@fajar.net>,
	Andrew Warkentin <andreww591@gmail.com>
Message-ID: <CC7CDAD5.2D967%ikozhukhov@gmail.com>
Thread-Topic: [Xen-devel] xen on illumos(OpenSolaris) based platform
In-Reply-To: <CAG1y0sczO296+UkFeNwQjGyV3sVssCA-W95iuY8KEEpFcDsJcQ@mail.gmail.com>
Mime-version: 1.0
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] xen on illumos(OpenSolaris) based 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

About KVM - you need to have EPT support CPU - I have no it.

Driver for KVM without EPT support have coredumps and need more works for
stable.

OpenIndiana(OpenSolaris fork) have xen-3.4.2 with solaris patches - but
have no builds for it.

I have found sources on opensolaris.org site, port it to userland build
system, and try to upgrade to xen-3.4.4.

DilOS contain packages with KVM drivers and you can try to use it.

I'm interested in XEN on DilOS.

---
Best regards,
Igor Kozhukhov
IRC# igork




On 9/17/12 8:37 AM, "Fajar A. Nugraha" <list@fajar.net> wrote:

>On Mon, Sep 17, 2012 at 11:27 AM, Andrew Warkentin <andreww591@gmail.com>
>wrote:
>> Igor Kozhukhov wrote:
>>>
>>> hello all!
>>>
>>> are you interested in port xen-4.1 to illumos(OpenSolaris) based
>>>platform?
>>> I have found old Sun works with xen-3.4.2 and updated it to xen-3.4.4
>>>
>>> I'll try to port xen-4.1.
>
>> I'm interested specifically in HVM domU support.
>
>> NCP3 hangs on boot on any versions of
>> Xen newer than 4.0.1 that I tried (even on 4.0.1, the kernel needs to be
>> patched ), and illumos hangs on boot on all the Xen versions that I
>>tried.
>> These hangs are related to the PVHVM drivers (the install systems run
>>OK,
>> and they don't include them).
>
>I thought opensolaris (and derivatives) runs well as PV domU? What do
>you use HVM for?
>
>Also, doesn't illumos support KVM? If you need full virtualization
>with *solaris, wouldn't it be easier for that particular purpose to
>try KVM instead?
>
>-- 
>Fajar
>
>_______________________________________________
>Xen-devel mailing list
>Xen-devel@lists.xen.org
>http://lists.xen.org/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 Sep 17 10:02:40 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 10:02:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDY9l-000274-CW; Mon, 17 Sep 2012 10:02:21 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ikozhukhov@gmail.com>) id 1TDY9k-00026z-2c
	for xen-devel@lists.xen.org; Mon, 17 Sep 2012 10:02:20 +0000
Received: from [85.158.138.51:30354] by server-2.bemta-3.messagelabs.com id
	AD/73-04862-B25F6505; Mon, 17 Sep 2012 10:02:19 +0000
X-Env-Sender: ikozhukhov@gmail.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1347876138!30930079!1
X-Originating-IP: [209.85.215.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27336 invoked from network); 17 Sep 2012 10:02:18 -0000
Received: from mail-lpp01m010-f45.google.com (HELO
	mail-lpp01m010-f45.google.com) (209.85.215.45)
	by server-5.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Sep 2012 10:02:18 -0000
Received: by lagz14 with SMTP id z14so4883320lag.32
	for <xen-devel@lists.xen.org>; Mon, 17 Sep 2012 03:02: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
	:in-reply-to:mime-version:content-type:content-transfer-encoding;
	bh=H/mu7fip3kny7XZ82b8A1NLFJVGg1lxk+TFf5vHSM0I=;
	b=yro3BLQSLxybZ2BdldUJfBKkbqNkClsgayqajQRgCsuMSO3RFdb0ezBcc0MTBXTchv
	teYKujLHk0UkK8kR53EVoTfPpwoZ69ZdQjaal0w0Rf6VI9ynsCPj0VFpkqlrt4XUmKfy
	XtulLyv4tvFGcTb1IpSUXfD+39380DX0RswKkB+uDLWmEWi3Y0bZX5ZKTjazXoHPZGau
	khOySdAttVlcHLJVi9UbgKSh/GPdvyT6HeGRTu7cIUJRPJiGcTRe4UP+IA2gc9D2W2yu
	tHVNeeA9z1UU+HdhF8tcUkpY4mxwQ21KYmAcQBVaw9002IYG0V5gkznUgmAVCtRl04vy
	Xf7Q==
Received: by 10.112.8.100 with SMTP id q4mr3730250lba.86.1347876138028;
	Mon, 17 Sep 2012 03:02:18 -0700 (PDT)
Received: from [172.16.90.16] ([91.204.58.44])
	by mx.google.com with ESMTPS id fz8sm2474584lbb.9.2012.09.17.03.02.13
	(version=SSLv3 cipher=OTHER); Mon, 17 Sep 2012 03:02:17 -0700 (PDT)
User-Agent: Microsoft-MacOutlook/14.2.3.120616
Date: Mon, 17 Sep 2012 14:02:07 +0400
From: Igor Kozhukhov <ikozhukhov@gmail.com>
To: Pasi =?ISO-8859-1?B?S+Rya2vkaW5lbg==?= <pasik@iki.fi>
Message-ID: <CC7CDCB1.2D97A%ikozhukhov@gmail.com>
Thread-Topic: [Xen-devel] xen on illumos(OpenSolaris) based platform
In-Reply-To: <20120917092722.GF8912@reaktio.net>
Mime-version: 1.0
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] xen on illumos(OpenSolaris) based platform
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

About patches - I'll try to post, but I have dilos-userland on bitbucket
and if you are interested in it please send me your account on
bitbucket(free registration) - I'll add you to the dilos-userland-review
repo - it's free registration.

Or you can send email through bitbucket form to account 'dilos'

I'm working on xen-4.1.

As I know Oracle have no interest to xVM, because it have another
virtualization.

---
Best regards,
Igor Kozhukhov
IRC# igork




On 9/17/12 1:27 PM, "Pasi K=E4rkk=E4inen" <pasik@iki.fi> wrote:

>On Sun, Sep 16, 2012 at 08:41:19PM +0400, Igor Kozhukhov wrote:
>>    hello all!
>> =

>>    are you interested in port xen-4.1 to illumos(OpenSolaris) based
>>platform?
>>    I have found old Sun works with xen-3.4.2 and updated it to xen-3.4.4
>>
>
>Oh, and please post the current patches against Xen 3.4.4,
>it'd be interesting to take a look at the patches to see how much changes
>are needed for Illumos/Opensolaris.
>
>I assume these are the ex. Sun/OpenSolaris XVM bits, that Oracle
>discontinued? =

>
>-- Pasi
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 17 10:02:40 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 10:02:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDY9l-000274-CW; Mon, 17 Sep 2012 10:02:21 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ikozhukhov@gmail.com>) id 1TDY9k-00026z-2c
	for xen-devel@lists.xen.org; Mon, 17 Sep 2012 10:02:20 +0000
Received: from [85.158.138.51:30354] by server-2.bemta-3.messagelabs.com id
	AD/73-04862-B25F6505; Mon, 17 Sep 2012 10:02:19 +0000
X-Env-Sender: ikozhukhov@gmail.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1347876138!30930079!1
X-Originating-IP: [209.85.215.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27336 invoked from network); 17 Sep 2012 10:02:18 -0000
Received: from mail-lpp01m010-f45.google.com (HELO
	mail-lpp01m010-f45.google.com) (209.85.215.45)
	by server-5.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Sep 2012 10:02:18 -0000
Received: by lagz14 with SMTP id z14so4883320lag.32
	for <xen-devel@lists.xen.org>; Mon, 17 Sep 2012 03:02: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
	:in-reply-to:mime-version:content-type:content-transfer-encoding;
	bh=H/mu7fip3kny7XZ82b8A1NLFJVGg1lxk+TFf5vHSM0I=;
	b=yro3BLQSLxybZ2BdldUJfBKkbqNkClsgayqajQRgCsuMSO3RFdb0ezBcc0MTBXTchv
	teYKujLHk0UkK8kR53EVoTfPpwoZ69ZdQjaal0w0Rf6VI9ynsCPj0VFpkqlrt4XUmKfy
	XtulLyv4tvFGcTb1IpSUXfD+39380DX0RswKkB+uDLWmEWi3Y0bZX5ZKTjazXoHPZGau
	khOySdAttVlcHLJVi9UbgKSh/GPdvyT6HeGRTu7cIUJRPJiGcTRe4UP+IA2gc9D2W2yu
	tHVNeeA9z1UU+HdhF8tcUkpY4mxwQ21KYmAcQBVaw9002IYG0V5gkznUgmAVCtRl04vy
	Xf7Q==
Received: by 10.112.8.100 with SMTP id q4mr3730250lba.86.1347876138028;
	Mon, 17 Sep 2012 03:02:18 -0700 (PDT)
Received: from [172.16.90.16] ([91.204.58.44])
	by mx.google.com with ESMTPS id fz8sm2474584lbb.9.2012.09.17.03.02.13
	(version=SSLv3 cipher=OTHER); Mon, 17 Sep 2012 03:02:17 -0700 (PDT)
User-Agent: Microsoft-MacOutlook/14.2.3.120616
Date: Mon, 17 Sep 2012 14:02:07 +0400
From: Igor Kozhukhov <ikozhukhov@gmail.com>
To: Pasi =?ISO-8859-1?B?S+Rya2vkaW5lbg==?= <pasik@iki.fi>
Message-ID: <CC7CDCB1.2D97A%ikozhukhov@gmail.com>
Thread-Topic: [Xen-devel] xen on illumos(OpenSolaris) based platform
In-Reply-To: <20120917092722.GF8912@reaktio.net>
Mime-version: 1.0
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] xen on illumos(OpenSolaris) based platform
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

About patches - I'll try to post, but I have dilos-userland on bitbucket
and if you are interested in it please send me your account on
bitbucket(free registration) - I'll add you to the dilos-userland-review
repo - it's free registration.

Or you can send email through bitbucket form to account 'dilos'

I'm working on xen-4.1.

As I know Oracle have no interest to xVM, because it have another
virtualization.

---
Best regards,
Igor Kozhukhov
IRC# igork




On 9/17/12 1:27 PM, "Pasi K=E4rkk=E4inen" <pasik@iki.fi> wrote:

>On Sun, Sep 16, 2012 at 08:41:19PM +0400, Igor Kozhukhov wrote:
>>    hello all!
>> =

>>    are you interested in port xen-4.1 to illumos(OpenSolaris) based
>>platform?
>>    I have found old Sun works with xen-3.4.2 and updated it to xen-3.4.4
>>
>
>Oh, and please post the current patches against Xen 3.4.4,
>it'd be interesting to take a look at the patches to see how much changes
>are needed for Illumos/Opensolaris.
>
>I assume these are the ex. Sun/OpenSolaris XVM bits, that Oracle
>discontinued? =

>
>-- Pasi
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 17 10:19:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 10:19:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDYPd-0002Jp-UF; Mon, 17 Sep 2012 10:18: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 1TDYPc-0002Jk-82
	for xen-devel@lists.xen.org; Mon, 17 Sep 2012 10:18:44 +0000
Received: from [85.158.137.99:42829] by server-11.bemta-3.messagelabs.com id
	4F/04-30250-309F6505; Mon, 17 Sep 2012 10:18:43 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-217.messagelabs.com!1347877122!12835133!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDk2NDU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31770 invoked from network); 17 Sep 2012 10:18:43 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Sep 2012 10:18:43 -0000
X-IronPort-AV: E=Sophos;i="4.80,434,1344211200"; d="scan'208";a="14576020"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Sep 2012 10: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.279.1;
	Mon, 17 Sep 2012 11:18:42 +0100
Message-ID: <1347877121.14977.45.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Date: Mon, 17 Sep 2012 11:18:41 +0100
In-Reply-To: <1347635403.24226.230.camel@zakaz.uk.xensource.com>
References: <a83fd69dcb277ce12bf6.1347634735@xdev.gridcentric.ca>
	<1347635403.24226.230.camel@zakaz.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "andres@gridcentric.ca" <andres@gridcentric.ca>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] Fix libxenstore memory leak when
 USE_PTHREAD is not defined, 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 Fri, 2012-09-14 at 16:10 +0100, Ian Campbell wrote:
> On Fri, 2012-09-14 at 15:58 +0100, Andres Lagar-Cavilla wrote:
> > tools/xenstore/xs.c |  17 +++++++++++++----
> >  1 files changed, 13 insertions(+), 4 deletions(-)
> > 
> > 
> > Redefine usage of pthread_cleanup_push and _pop, to explicitly call free for
> > heap objects in error paths.
> > 
> > By the way, set a suitable errno value for an error path that had none.
> > 
> > This is V2 after comments from Ian Campbell.
> > 
> > Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
> 
> Looks good to me
> 
> Acked-by: Ian Campbell <ian.campbell@citrix.com>

and applied, thanks.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 17 10:19:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 10:19:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDYPd-0002Jp-UF; Mon, 17 Sep 2012 10:18: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 1TDYPc-0002Jk-82
	for xen-devel@lists.xen.org; Mon, 17 Sep 2012 10:18:44 +0000
Received: from [85.158.137.99:42829] by server-11.bemta-3.messagelabs.com id
	4F/04-30250-309F6505; Mon, 17 Sep 2012 10:18:43 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-217.messagelabs.com!1347877122!12835133!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDk2NDU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31770 invoked from network); 17 Sep 2012 10:18:43 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Sep 2012 10:18:43 -0000
X-IronPort-AV: E=Sophos;i="4.80,434,1344211200"; d="scan'208";a="14576020"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Sep 2012 10: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.279.1;
	Mon, 17 Sep 2012 11:18:42 +0100
Message-ID: <1347877121.14977.45.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Date: Mon, 17 Sep 2012 11:18:41 +0100
In-Reply-To: <1347635403.24226.230.camel@zakaz.uk.xensource.com>
References: <a83fd69dcb277ce12bf6.1347634735@xdev.gridcentric.ca>
	<1347635403.24226.230.camel@zakaz.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "andres@gridcentric.ca" <andres@gridcentric.ca>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] Fix libxenstore memory leak when
 USE_PTHREAD is not defined, 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 Fri, 2012-09-14 at 16:10 +0100, Ian Campbell wrote:
> On Fri, 2012-09-14 at 15:58 +0100, Andres Lagar-Cavilla wrote:
> > tools/xenstore/xs.c |  17 +++++++++++++----
> >  1 files changed, 13 insertions(+), 4 deletions(-)
> > 
> > 
> > Redefine usage of pthread_cleanup_push and _pop, to explicitly call free for
> > heap objects in error paths.
> > 
> > By the way, set a suitable errno value for an error path that had none.
> > 
> > This is V2 after comments from Ian Campbell.
> > 
> > Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
> 
> Looks good to me
> 
> Acked-by: Ian Campbell <ian.campbell@citrix.com>

and applied, thanks.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 17 10:19:06 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 10:19:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDYPl-0002Kt-RI; Mon, 17 Sep 2012 10:18:53 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1TDYPk-0002Kb-Kx
	for xen-devel@lists.xen.org; Mon, 17 Sep 2012 10:18:52 +0000
Received: from [85.158.137.99:30267] by server-6.bemta-3.messagelabs.com id
	1F/BE-29694-B09F6505; Mon, 17 Sep 2012 10:18:51 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-217.messagelabs.com!1347877122!12835133!3
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDk2NDU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32247 invoked from network); 17 Sep 2012 10:18:51 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Sep 2012 10:18:51 -0000
X-IronPort-AV: E=Sophos;i="4.80,434,1344211200"; d="scan'208";a="14576026"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Sep 2012 10:18: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.279.1;
	Mon, 17 Sep 2012 11:18:51 +0100
Message-ID: <1347877129.14977.47.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Mon, 17 Sep 2012 11:18:49 +0100
In-Reply-To: <50531D98020000780009B54D@nat28.tlf.novell.com>
References: <640a0b0b44e67c843473.1347616836@cosworth.uk.xensource.com>
	<50531D98020000780009B54D@nat28.tlf.novell.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] tools: drop ia64 only foreign structs from
	headers
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-09-14 at 11:05 +0100, Jan Beulich wrote:
> >>> On 14.09.12 at 12:00, Ian Campbell <ian.campbell@citrix.com> wrote:
> > # HG changeset patch
> > # User Ian Campbell <ian.campbell@citrix.com>
> > # Date 1347616748 -3600
> > # Node ID 640a0b0b44e67c8434735c5129400b3a56a43683
> > # Parent  aabf685cd613b11e9b9709ae2a43f23f56d4d7ff
> > tools: drop ia64 only foreign structs from headers
> 
> Not sure why they got put there in the first place.
> 
> > Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> 
> Acked-by: Jan Beulich <jbeulich@suse.com>

Applied, thanks.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 17 10:19:06 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 10:19:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDYPl-0002Kt-RI; Mon, 17 Sep 2012 10:18:53 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1TDYPk-0002Kb-Kx
	for xen-devel@lists.xen.org; Mon, 17 Sep 2012 10:18:52 +0000
Received: from [85.158.137.99:30267] by server-6.bemta-3.messagelabs.com id
	1F/BE-29694-B09F6505; Mon, 17 Sep 2012 10:18:51 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-217.messagelabs.com!1347877122!12835133!3
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDk2NDU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32247 invoked from network); 17 Sep 2012 10:18:51 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Sep 2012 10:18:51 -0000
X-IronPort-AV: E=Sophos;i="4.80,434,1344211200"; d="scan'208";a="14576026"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Sep 2012 10:18: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.279.1;
	Mon, 17 Sep 2012 11:18:51 +0100
Message-ID: <1347877129.14977.47.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Mon, 17 Sep 2012 11:18:49 +0100
In-Reply-To: <50531D98020000780009B54D@nat28.tlf.novell.com>
References: <640a0b0b44e67c843473.1347616836@cosworth.uk.xensource.com>
	<50531D98020000780009B54D@nat28.tlf.novell.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] tools: drop ia64 only foreign structs from
	headers
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-09-14 at 11:05 +0100, Jan Beulich wrote:
> >>> On 14.09.12 at 12:00, Ian Campbell <ian.campbell@citrix.com> wrote:
> > # HG changeset patch
> > # User Ian Campbell <ian.campbell@citrix.com>
> > # Date 1347616748 -3600
> > # Node ID 640a0b0b44e67c8434735c5129400b3a56a43683
> > # Parent  aabf685cd613b11e9b9709ae2a43f23f56d4d7ff
> > tools: drop ia64 only foreign structs from headers
> 
> Not sure why they got put there in the first place.
> 
> > Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> 
> Acked-by: Jan Beulich <jbeulich@suse.com>

Applied, thanks.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 17 10:19:07 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 10:19:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDYPh-0002K6-AA; Mon, 17 Sep 2012 10:18:49 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1TDYPg-0002Jx-3I
	for xen-devel@lists.xen.org; Mon, 17 Sep 2012 10:18:48 +0000
Received: from [85.158.137.99:43025] by server-2.bemta-3.messagelabs.com id
	BA/CB-04862-709F6505; Mon, 17 Sep 2012 10:18:47 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-217.messagelabs.com!1347877122!12835133!2
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDk2NDU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31924 invoked from network); 17 Sep 2012 10:18:46 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Sep 2012 10:18:46 -0000
X-IronPort-AV: E=Sophos;i="4.80,434,1344211200"; d="scan'208";a="14576022"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Sep 2012 10:18: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.279.1;
	Mon, 17 Sep 2012 11:18:46 +0100
Message-ID: <1347877125.14977.46.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Keir Fraser <keir.xen@gmail.com>
Date: Mon, 17 Sep 2012 11:18:45 +0100
In-Reply-To: <CC78E06F.3EC49%keir.xen@gmail.com>
References: <CC78E06F.3EC49%keir.xen@gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-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] .*ignore: drop ia64 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, 2012-09-14 at 13:23 +0100, Keir Fraser wrote:
> On 14/09/2012 11:00, "Ian Campbell" <ian.campbell@citrix.com> wrote:
> 
> > # HG changeset patch
> > # User Ian Campbell <ian.campbell@citrix.com>
> > # Date 1347616840 -3600
> > # Node ID 0547430886c507989dd9091ef5f1e2d089a50351
> > # Parent  640a0b0b44e67c8434735c5129400b3a56a43683
> > .*ignore: drop ia64 entries
> > 
> > Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> 
> Acked-by: Keir Fraser <keir@xen.org>

Applied, thanks.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 17 10:19:07 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 10:19:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDYPh-0002K6-AA; Mon, 17 Sep 2012 10:18:49 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1TDYPg-0002Jx-3I
	for xen-devel@lists.xen.org; Mon, 17 Sep 2012 10:18:48 +0000
Received: from [85.158.137.99:43025] by server-2.bemta-3.messagelabs.com id
	BA/CB-04862-709F6505; Mon, 17 Sep 2012 10:18:47 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-217.messagelabs.com!1347877122!12835133!2
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDk2NDU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31924 invoked from network); 17 Sep 2012 10:18:46 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Sep 2012 10:18:46 -0000
X-IronPort-AV: E=Sophos;i="4.80,434,1344211200"; d="scan'208";a="14576022"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Sep 2012 10:18: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.279.1;
	Mon, 17 Sep 2012 11:18:46 +0100
Message-ID: <1347877125.14977.46.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Keir Fraser <keir.xen@gmail.com>
Date: Mon, 17 Sep 2012 11:18:45 +0100
In-Reply-To: <CC78E06F.3EC49%keir.xen@gmail.com>
References: <CC78E06F.3EC49%keir.xen@gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-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] .*ignore: drop ia64 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, 2012-09-14 at 13:23 +0100, Keir Fraser wrote:
> On 14/09/2012 11:00, "Ian Campbell" <ian.campbell@citrix.com> wrote:
> 
> > # HG changeset patch
> > # User Ian Campbell <ian.campbell@citrix.com>
> > # Date 1347616840 -3600
> > # Node ID 0547430886c507989dd9091ef5f1e2d089a50351
> > # Parent  640a0b0b44e67c8434735c5129400b3a56a43683
> > .*ignore: drop ia64 entries
> > 
> > Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> 
> Acked-by: Keir Fraser <keir@xen.org>

Applied, thanks.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 17 10:19:10 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 10:19: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 1TDYPq-0002Ld-8P; Mon, 17 Sep 2012 10:18: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 1TDYPo-0002LF-6Q
	for xen-devel@lists.xen.org; Mon, 17 Sep 2012 10:18:56 +0000
Received: from [85.158.137.99:40614] by server-3.bemta-3.messagelabs.com id
	9D/83-21322-F09F6505; Mon, 17 Sep 2012 10:18:55 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-217.messagelabs.com!1347877122!12835133!4
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDk2NDU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32601 invoked from network); 17 Sep 2012 10:18:54 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Sep 2012 10:18:54 -0000
X-IronPort-AV: E=Sophos;i="4.80,434,1344211200"; d="scan'208";a="14576031"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Sep 2012 10:18: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.279.1;
	Mon, 17 Sep 2012 11:18:54 +0100
Message-ID: <1347877133.14977.48.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Date: Mon, 17 Sep 2012 11:18:53 +0100
In-Reply-To: <patchbomb.1347626548@cosworth.uk.xensource.com>
References: <patchbomb.1347626548@cosworth.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 0 of 3] libxl/xl: Enable -Wshadow
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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-09-14 at 13:42 +0100, Ian Campbell wrote:
> We've had several occuranced of confusion on xl due to shadowing the
> global domid variable with a local one. The main bulk of this series
> removes that global, the rest is smaller cleanups to allow Wshadow.
> 
> I've already sent the libxl part of this, but am reincluding here as
> part of the set.

I have applied 2/3 + 3/3 + folded in the incremental fix to 3/3 with
Ian's acks.

I applied V2 of 1/3 from the separate "libxl: Enable -Wshadow" thread.

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 Sep 17 10:19:10 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 10:19: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 1TDYPq-0002Ld-8P; Mon, 17 Sep 2012 10:18: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 1TDYPo-0002LF-6Q
	for xen-devel@lists.xen.org; Mon, 17 Sep 2012 10:18:56 +0000
Received: from [85.158.137.99:40614] by server-3.bemta-3.messagelabs.com id
	9D/83-21322-F09F6505; Mon, 17 Sep 2012 10:18:55 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-217.messagelabs.com!1347877122!12835133!4
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDk2NDU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32601 invoked from network); 17 Sep 2012 10:18:54 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Sep 2012 10:18:54 -0000
X-IronPort-AV: E=Sophos;i="4.80,434,1344211200"; d="scan'208";a="14576031"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Sep 2012 10:18: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.279.1;
	Mon, 17 Sep 2012 11:18:54 +0100
Message-ID: <1347877133.14977.48.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Date: Mon, 17 Sep 2012 11:18:53 +0100
In-Reply-To: <patchbomb.1347626548@cosworth.uk.xensource.com>
References: <patchbomb.1347626548@cosworth.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 0 of 3] libxl/xl: Enable -Wshadow
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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-09-14 at 13:42 +0100, Ian Campbell wrote:
> We've had several occuranced of confusion on xl due to shadowing the
> global domid variable with a local one. The main bulk of this series
> removes that global, the rest is smaller cleanups to allow Wshadow.
> 
> I've already sent the libxl part of this, but am reincluding here as
> part of the set.

I have applied 2/3 + 3/3 + folded in the incremental fix to 3/3 with
Ian's acks.

I applied V2 of 1/3 from the separate "libxl: Enable -Wshadow" thread.

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 Sep 17 10:19:10 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 10:19: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 1TDYPs-0002MI-Lw; Mon, 17 Sep 2012 10:19: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 1TDYPr-0002Lr-Lg
	for xen-devel@lists.xen.org; Mon, 17 Sep 2012 10:18:59 +0000
Received: from [85.158.137.99:40962] by server-9.bemta-3.messagelabs.com id
	57/BC-15390-219F6505; Mon, 17 Sep 2012 10:18:58 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-217.messagelabs.com!1347877122!12835133!5
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDk2NDU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 381 invoked from network); 17 Sep 2012 10:18:58 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Sep 2012 10:18:58 -0000
X-IronPort-AV: E=Sophos;i="4.80,434,1344211200"; d="scan'208";a="14576033"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Sep 2012 10:18: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.279.1;
	Mon, 17 Sep 2012 11:18:58 +0100
Message-ID: <1347877136.14977.49.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Mon, 17 Sep 2012 11:18:56 +0100
In-Reply-To: <20563.20495.204901.209605@mariner.uk.xensource.com>
References: <58ab3fb73d13e250f334.1347620998@cosworth.uk.xensource.com>
	<20563.16972.124870.221950@mariner.uk.xensource.com>
	<1347636887.24226.237.camel@zakaz.uk.xensource.com>
	<20563.20495.204901.209605@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] libxl: Enable -Wshadow
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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-09-14 at 16:41 +0100, Ian Jackson wrote:
> Ian Campbell writes ("Re: [PATCH] libxl: Enable -Wshadow"):
> > On Fri, 2012-09-14 at 15:42 +0100, Ian Jackson wrote:
> > > If we're doing -Wshadow then macros which introduce local variables
> > > like this should give them names qualified somehow for the macro.
> > 
> > Done, v2 below.
> > 
> > Since I was touching every line I fixed the line length in those macros
> > too.
> 
> :-).
> 
> Thanks,
> 
> Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

Applied, thanks.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 17 10:19:10 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 10:19: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 1TDYPs-0002MI-Lw; Mon, 17 Sep 2012 10:19: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 1TDYPr-0002Lr-Lg
	for xen-devel@lists.xen.org; Mon, 17 Sep 2012 10:18:59 +0000
Received: from [85.158.137.99:40962] by server-9.bemta-3.messagelabs.com id
	57/BC-15390-219F6505; Mon, 17 Sep 2012 10:18:58 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-217.messagelabs.com!1347877122!12835133!5
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDk2NDU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 381 invoked from network); 17 Sep 2012 10:18:58 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Sep 2012 10:18:58 -0000
X-IronPort-AV: E=Sophos;i="4.80,434,1344211200"; d="scan'208";a="14576033"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Sep 2012 10:18: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.279.1;
	Mon, 17 Sep 2012 11:18:58 +0100
Message-ID: <1347877136.14977.49.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Mon, 17 Sep 2012 11:18:56 +0100
In-Reply-To: <20563.20495.204901.209605@mariner.uk.xensource.com>
References: <58ab3fb73d13e250f334.1347620998@cosworth.uk.xensource.com>
	<20563.16972.124870.221950@mariner.uk.xensource.com>
	<1347636887.24226.237.camel@zakaz.uk.xensource.com>
	<20563.20495.204901.209605@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] libxl: Enable -Wshadow
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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-09-14 at 16:41 +0100, Ian Jackson wrote:
> Ian Campbell writes ("Re: [PATCH] libxl: Enable -Wshadow"):
> > On Fri, 2012-09-14 at 15:42 +0100, Ian Jackson wrote:
> > > If we're doing -Wshadow then macros which introduce local variables
> > > like this should give them names qualified somehow for the macro.
> > 
> > Done, v2 below.
> > 
> > Since I was touching every line I fixed the line length in those macros
> > too.
> 
> :-).
> 
> Thanks,
> 
> Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

Applied, thanks.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 17 10:19:16 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 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 1TDYPz-0002P7-2i; Mon, 17 Sep 2012 10:19:07 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1TDYPx-0002Nf-Dd
	for xen-devel@lists.xen.org; Mon, 17 Sep 2012 10:19:05 +0000
Received: from [85.158.137.99:41131] by server-12.bemta-3.messagelabs.com id
	95/26-10384-519F6505; Mon, 17 Sep 2012 10:19:01 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-217.messagelabs.com!1347877122!12835133!6
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDk2NDU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 456 invoked from network); 17 Sep 2012 10:19:00 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Sep 2012 10:19:00 -0000
X-IronPort-AV: E=Sophos;i="4.80,434,1344211200"; d="scan'208";a="14576035"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Sep 2012 10:19:00 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Mon, 17 Sep 2012 11:19:00 +0100
Message-ID: <1347877139.14977.50.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Mon, 17 Sep 2012 11:18:59 +0100
In-Reply-To: <20563.20503.933248.679465@mariner.uk.xensource.com>
References: <844e10487b91fb4dcb9c.1346932946@cosworth.uk.xensource.com>
	<20563.20503.933248.679465@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] xl: free libxl context,
 logger and lockfile using atexit handler
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-09-14 at 16:41 +0100, Ian Jackson wrote:
> Ian Campbell writes ("[Xen-devel] [PATCH] xl: free libxl context, logger and lockfile using atexit handler"):
> > xl: free libxl context, logger and lockfile using atexit handler
> 
> Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

Applied, thanks.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 17 10:19:16 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 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 1TDYPz-0002P7-2i; Mon, 17 Sep 2012 10:19:07 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1TDYPx-0002Nf-Dd
	for xen-devel@lists.xen.org; Mon, 17 Sep 2012 10:19:05 +0000
Received: from [85.158.137.99:41131] by server-12.bemta-3.messagelabs.com id
	95/26-10384-519F6505; Mon, 17 Sep 2012 10:19:01 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-217.messagelabs.com!1347877122!12835133!6
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDk2NDU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 456 invoked from network); 17 Sep 2012 10:19:00 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Sep 2012 10:19:00 -0000
X-IronPort-AV: E=Sophos;i="4.80,434,1344211200"; d="scan'208";a="14576035"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Sep 2012 10:19:00 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Mon, 17 Sep 2012 11:19:00 +0100
Message-ID: <1347877139.14977.50.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Mon, 17 Sep 2012 11:18:59 +0100
In-Reply-To: <20563.20503.933248.679465@mariner.uk.xensource.com>
References: <844e10487b91fb4dcb9c.1346932946@cosworth.uk.xensource.com>
	<20563.20503.933248.679465@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] xl: free libxl context,
 logger and lockfile using atexit handler
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-09-14 at 16:41 +0100, Ian Jackson wrote:
> Ian Campbell writes ("[Xen-devel] [PATCH] xl: free libxl context, logger and lockfile using atexit handler"):
> > xl: free libxl context, logger and lockfile using atexit handler
> 
> Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

Applied, thanks.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 17 10:26:34 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 10: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 1TDYX1-0003G2-EP; Mon, 17 Sep 2012 10:26:23 +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 1TDYX0-0003Fv-Q9
	for xen-devel@lists.xen.org; Mon, 17 Sep 2012 10:26:22 +0000
Received: from [85.158.143.99:2517] by server-1.bemta-4.messagelabs.com id
	7D/C7-12504-ECAF6505; Mon, 17 Sep 2012 10:26:22 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-11.tower-216.messagelabs.com!1347877581!23120488!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA1MDQ5ODc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9983 invoked from network); 17 Sep 2012 10:26:21 -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; 17 Sep 2012 10:26:21 -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 74DB42F12;
	Mon, 17 Sep 2012 13:26:20 +0300 (EEST)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id 5D43F2005D; Mon, 17 Sep 2012 13:26:20 +0300 (EEST)
Date: Mon, 17 Sep 2012 13:26:20 +0300
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: Igor Kozhukhov <ikozhukhov@gmail.com>
Message-ID: <20120917102620.GG8912@reaktio.net>
References: <CAG1y0sczO296+UkFeNwQjGyV3sVssCA-W95iuY8KEEpFcDsJcQ@mail.gmail.com>
	<CC7CDAD5.2D967%ikozhukhov@gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CC7CDAD5.2D967%ikozhukhov@gmail.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: Keith Coleman <keith.coleman@n2servers.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] xen on illumos(OpenSolaris) based platform
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Sep 17, 2012 at 01:54:21PM +0400, Igor Kozhukhov wrote:
> 
> OpenIndiana(OpenSolaris fork) have xen-3.4.2 with solaris patches - but
> have no builds for it.
> 
> I have found sources on opensolaris.org site, port it to userland build
> system, and try to upgrade to xen-3.4.4.
> 
> I'm interested in XEN on DilOS.
>

Btw Xen 3.4.4 doesn't have the latest security updates, just so you know..
Also they seem to be missing from 3.4 branch: http://xenbits.xen.org/hg/xen-3.4-testing.hg/

Keith Coleman (cc) is maintaining the "old" Xen 3.4 tree.

-- Pasi
 
> ---
> Best regards,
> Igor Kozhukhov
> IRC# igork
> 
> 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 17 10:26:34 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 10: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 1TDYX1-0003G2-EP; Mon, 17 Sep 2012 10:26:23 +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 1TDYX0-0003Fv-Q9
	for xen-devel@lists.xen.org; Mon, 17 Sep 2012 10:26:22 +0000
Received: from [85.158.143.99:2517] by server-1.bemta-4.messagelabs.com id
	7D/C7-12504-ECAF6505; Mon, 17 Sep 2012 10:26:22 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-11.tower-216.messagelabs.com!1347877581!23120488!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA1MDQ5ODc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9983 invoked from network); 17 Sep 2012 10:26:21 -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; 17 Sep 2012 10:26:21 -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 74DB42F12;
	Mon, 17 Sep 2012 13:26:20 +0300 (EEST)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id 5D43F2005D; Mon, 17 Sep 2012 13:26:20 +0300 (EEST)
Date: Mon, 17 Sep 2012 13:26:20 +0300
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: Igor Kozhukhov <ikozhukhov@gmail.com>
Message-ID: <20120917102620.GG8912@reaktio.net>
References: <CAG1y0sczO296+UkFeNwQjGyV3sVssCA-W95iuY8KEEpFcDsJcQ@mail.gmail.com>
	<CC7CDAD5.2D967%ikozhukhov@gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CC7CDAD5.2D967%ikozhukhov@gmail.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: Keith Coleman <keith.coleman@n2servers.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] xen on illumos(OpenSolaris) based platform
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Sep 17, 2012 at 01:54:21PM +0400, Igor Kozhukhov wrote:
> 
> OpenIndiana(OpenSolaris fork) have xen-3.4.2 with solaris patches - but
> have no builds for it.
> 
> I have found sources on opensolaris.org site, port it to userland build
> system, and try to upgrade to xen-3.4.4.
> 
> I'm interested in XEN on DilOS.
>

Btw Xen 3.4.4 doesn't have the latest security updates, just so you know..
Also they seem to be missing from 3.4 branch: http://xenbits.xen.org/hg/xen-3.4-testing.hg/

Keith Coleman (cc) is maintaining the "old" Xen 3.4 tree.

-- Pasi
 
> ---
> Best regards,
> Igor Kozhukhov
> IRC# igork
> 
> 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 17 10:35:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 10: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 1TDYfJ-0003Sg-Ds; Mon, 17 Sep 2012 10:34: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 1TDYfH-0003Sb-Ng
	for xen-devel@lists.xensource.com; Mon, 17 Sep 2012 10:34:55 +0000
Received: from [85.158.143.35:26486] by server-1.bemta-4.messagelabs.com id
	0F/C6-12504-FCCF6505; Mon, 17 Sep 2012 10:34:55 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1347878080!7605042!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDk2NDU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25802 invoked from network); 17 Sep 2012 10:34:40 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Sep 2012 10:34:40 -0000
X-IronPort-AV: E=Sophos;i="4.80,434,1344211200"; d="scan'208";a="14576443"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Sep 2012 10:34: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.279.1; Mon, 17 Sep 2012 11:34: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
	1TDYf1-00082g-J5	for xen-devel@lists.xensource.com;
	Mon, 17 Sep 2012 10:34:39 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1TDYf1-0008SR-2e	for
	xen-devel@lists.xensource.com; Mon, 17 Sep 2012 11:34:39 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20566.64702.541224.612496@mariner.uk.xensource.com>
Date: Mon, 17 Sep 2012 11:34:38 +0100
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
In-Reply-To: <osstest-13785-mainreport@xen.org>
References: <osstest-13785-mainreport@xen.org>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Subject: Re: [Xen-devel] [linux-linus test] 13785: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 ("[linux-linus test] 13785: regressions - FAIL"):
> flight 13785 linux-linus real [real]
> http://www.chiark.greenend.org.uk/~xensrcts/logs/13785/
> 
> Regressions :-(
> 
> Tests which did not succeed and are blocking,
> including tests which could not be run:
>  test-amd64-i386-xl-multivcpu  5 xen-boot               fail REGR. vs. 12557

This is a real problem but is not in upstream Linux.  The problem is
that I have no mechanism for updating the firmware tarball.  I
shouldn't have reenabled this test until I'd fixed that ...

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 17 10:35:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 10: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 1TDYfJ-0003Sg-Ds; Mon, 17 Sep 2012 10:34: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 1TDYfH-0003Sb-Ng
	for xen-devel@lists.xensource.com; Mon, 17 Sep 2012 10:34:55 +0000
Received: from [85.158.143.35:26486] by server-1.bemta-4.messagelabs.com id
	0F/C6-12504-FCCF6505; Mon, 17 Sep 2012 10:34:55 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1347878080!7605042!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDk2NDU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25802 invoked from network); 17 Sep 2012 10:34:40 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Sep 2012 10:34:40 -0000
X-IronPort-AV: E=Sophos;i="4.80,434,1344211200"; d="scan'208";a="14576443"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Sep 2012 10:34: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.279.1; Mon, 17 Sep 2012 11:34: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
	1TDYf1-00082g-J5	for xen-devel@lists.xensource.com;
	Mon, 17 Sep 2012 10:34:39 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1TDYf1-0008SR-2e	for
	xen-devel@lists.xensource.com; Mon, 17 Sep 2012 11:34:39 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20566.64702.541224.612496@mariner.uk.xensource.com>
Date: Mon, 17 Sep 2012 11:34:38 +0100
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
In-Reply-To: <osstest-13785-mainreport@xen.org>
References: <osstest-13785-mainreport@xen.org>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Subject: Re: [Xen-devel] [linux-linus test] 13785: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 ("[linux-linus test] 13785: regressions - FAIL"):
> flight 13785 linux-linus real [real]
> http://www.chiark.greenend.org.uk/~xensrcts/logs/13785/
> 
> Regressions :-(
> 
> Tests which did not succeed and are blocking,
> including tests which could not be run:
>  test-amd64-i386-xl-multivcpu  5 xen-boot               fail REGR. vs. 12557

This is a real problem but is not in upstream Linux.  The problem is
that I have no mechanism for updating the firmware tarball.  I
shouldn't have reenabled this test until I'd fixed that ...

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 17 10:53:23 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 10:53:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDYwn-0003fd-30; Mon, 17 Sep 2012 10:53: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 1TDYwl-0003fY-Qw
	for xen-devel@lists.xensource.com; Mon, 17 Sep 2012 10:53:00 +0000
Received: from [85.158.139.211:47770] by server-1.bemta-5.messagelabs.com id
	7B/A3-32692-A0107505; Mon, 17 Sep 2012 10:52:58 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1347879178!18396100!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDk2NDU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5122 invoked from network); 17 Sep 2012 10:52:58 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Sep 2012 10:52:58 -0000
X-IronPort-AV: E=Sophos;i="4.80,434,1344211200"; d="scan'208";a="14576915"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Sep 2012 10:52: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.279.1; Mon, 17 Sep 2012 11:52:58 +0100
Date: Mon, 17 Sep 2012 11:52:12 +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: <20120914170644.GC1481@phenom.dumpdata.com>
Message-ID: <alpine.DEB.2.02.1209171150370.29232@kaball.uk.xensource.com>
References: <1347306367-28669-1-git-send-email-konrad.wilk@oracle.com>
	<1347306367-28669-9-git-send-email-konrad.wilk@oracle.com>
	<alpine.DEB.2.02.1209141704330.29232@kaball.uk.xensource.com>
	<20120914170644.GC1481@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 08/10] xen/swiotlb: Remove functions not
 needed anymore.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 14 Sep 2012, Konrad Rzeszutek Wilk wrote:
> On Fri, Sep 14, 2012 at 05:06:16PM +0100, Stefano Stabellini wrote:
> > On Mon, 10 Sep 2012, Konrad Rzeszutek Wilk wrote:
> > > Sparse warns us off:
> > > drivers/xen/swiotlb-xen.c:506:1: warning: symbol 'xen_swiotlb_map_sg' was not declared. Should it be static?
> > > drivers/xen/swiotlb-xen.c:534:1: warning: symbol 'xen_swiotlb_unmap_sg' was not declared. Should it be static?
> > > 
> > > and it looks like we do not need this function at all.
> > 
> > A grep seems to find them used in arch/x86/xen/pci-swiotlb-xen.c.
> > I fail to see where you removed them from pci-swiotlb-xen.c. Is it in
> > this patch series or another one?
> 
> I am not seeing them in that file. I think you found the
> other variant of it:
> 
> xen_swiotlb_map_sg_attrs

Yes, you are right.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 17 10:53:23 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 10:53:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDYwn-0003fd-30; Mon, 17 Sep 2012 10:53: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 1TDYwl-0003fY-Qw
	for xen-devel@lists.xensource.com; Mon, 17 Sep 2012 10:53:00 +0000
Received: from [85.158.139.211:47770] by server-1.bemta-5.messagelabs.com id
	7B/A3-32692-A0107505; Mon, 17 Sep 2012 10:52:58 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1347879178!18396100!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDk2NDU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5122 invoked from network); 17 Sep 2012 10:52:58 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Sep 2012 10:52:58 -0000
X-IronPort-AV: E=Sophos;i="4.80,434,1344211200"; d="scan'208";a="14576915"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Sep 2012 10:52: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.279.1; Mon, 17 Sep 2012 11:52:58 +0100
Date: Mon, 17 Sep 2012 11:52:12 +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: <20120914170644.GC1481@phenom.dumpdata.com>
Message-ID: <alpine.DEB.2.02.1209171150370.29232@kaball.uk.xensource.com>
References: <1347306367-28669-1-git-send-email-konrad.wilk@oracle.com>
	<1347306367-28669-9-git-send-email-konrad.wilk@oracle.com>
	<alpine.DEB.2.02.1209141704330.29232@kaball.uk.xensource.com>
	<20120914170644.GC1481@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 08/10] xen/swiotlb: Remove functions not
 needed anymore.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 14 Sep 2012, Konrad Rzeszutek Wilk wrote:
> On Fri, Sep 14, 2012 at 05:06:16PM +0100, Stefano Stabellini wrote:
> > On Mon, 10 Sep 2012, Konrad Rzeszutek Wilk wrote:
> > > Sparse warns us off:
> > > drivers/xen/swiotlb-xen.c:506:1: warning: symbol 'xen_swiotlb_map_sg' was not declared. Should it be static?
> > > drivers/xen/swiotlb-xen.c:534:1: warning: symbol 'xen_swiotlb_unmap_sg' was not declared. Should it be static?
> > > 
> > > and it looks like we do not need this function at all.
> > 
> > A grep seems to find them used in arch/x86/xen/pci-swiotlb-xen.c.
> > I fail to see where you removed them from pci-swiotlb-xen.c. Is it in
> > this patch series or another one?
> 
> I am not seeing them in that file. I think you found the
> other variant of it:
> 
> xen_swiotlb_map_sg_attrs

Yes, you are right.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 17 10:55:41 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 10:55:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDYz9-0003lN-LF; Mon, 17 Sep 2012 10:55: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 1TDYz8-0003lG-Bk
	for xen-devel@lists.xensource.com; Mon, 17 Sep 2012 10:55:26 +0000
Received: from [85.158.143.99:5013] by server-3.bemta-4.messagelabs.com id
	94/A7-08232-D9107505; Mon, 17 Sep 2012 10:55:25 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1347879324!30314842!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDk2NDU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23941 invoked from network); 17 Sep 2012 10:55:24 -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;
	17 Sep 2012 10:55:24 -0000
X-IronPort-AV: E=Sophos;i="4.80,434,1344211200"; d="scan'208";a="14576972"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Sep 2012 10:55: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.279.1; Mon, 17 Sep 2012 11:55:24 +0100
Date: Mon, 17 Sep 2012 11:54:38 +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: <20120914160727.1ff41de2@mantra.us.oracle.com>
Message-ID: <alpine.DEB.2.02.1209171153350.29232@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1208221159560.15568@kaball.uk.xensource.com>
	<1345633688-31684-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<1347627587.24226.192.camel@zakaz.uk.xensource.com>
	<20120914160727.1ff41de2@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>,
	"Tim \(Xen.org\)" <tim@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v4 1/6] xen: improve changes to
	xen_add_to_physmap
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Sat, 15 Sep 2012, Mukesh Rathor wrote:
> On Fri, 14 Sep 2012 13:59:47 +0100
> Ian Campbell <Ian.Campbell@citrix.com> wrote:
> 
> > 
> > On Wed, 2012-08-22 at 12:08 +0100, Stefano Stabellini wrote:
> > > This is an incremental patch on top of
> > > c0bc926083b5987a3e9944eec2c12ad0580100e2: in order to retain binary
> > > compatibility, it is better to introduce foreign_domid as part of a
> > > union containing both size and foreign_domid.
> > [...]
> > > -    domid_t foreign_domid; /* IFF gmfn_foreign */
> > > +    unsigned int space;
> > >  
> > >  #define XENMAPIDX_grant_table_status 0x80000000
> > 
> > Was this the final consensus on what this interface ought to look
> > like?
> > 
> > Does it work for PVH too (Mukesh CCd)?
> 
> Yes it does. Please lmk if the final version asap so I can put in
> my patch, and also test it.

It the final version. I think it should go in, unless we want to drop it
entirely in favor of xen_add_to_physmap_range.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 17 10:55:41 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 10:55:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDYz9-0003lN-LF; Mon, 17 Sep 2012 10:55: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 1TDYz8-0003lG-Bk
	for xen-devel@lists.xensource.com; Mon, 17 Sep 2012 10:55:26 +0000
Received: from [85.158.143.99:5013] by server-3.bemta-4.messagelabs.com id
	94/A7-08232-D9107505; Mon, 17 Sep 2012 10:55:25 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1347879324!30314842!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDk2NDU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23941 invoked from network); 17 Sep 2012 10:55:24 -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;
	17 Sep 2012 10:55:24 -0000
X-IronPort-AV: E=Sophos;i="4.80,434,1344211200"; d="scan'208";a="14576972"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Sep 2012 10:55: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.279.1; Mon, 17 Sep 2012 11:55:24 +0100
Date: Mon, 17 Sep 2012 11:54:38 +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: <20120914160727.1ff41de2@mantra.us.oracle.com>
Message-ID: <alpine.DEB.2.02.1209171153350.29232@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1208221159560.15568@kaball.uk.xensource.com>
	<1345633688-31684-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<1347627587.24226.192.camel@zakaz.uk.xensource.com>
	<20120914160727.1ff41de2@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>,
	"Tim \(Xen.org\)" <tim@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v4 1/6] xen: improve changes to
	xen_add_to_physmap
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Sat, 15 Sep 2012, Mukesh Rathor wrote:
> On Fri, 14 Sep 2012 13:59:47 +0100
> Ian Campbell <Ian.Campbell@citrix.com> wrote:
> 
> > 
> > On Wed, 2012-08-22 at 12:08 +0100, Stefano Stabellini wrote:
> > > This is an incremental patch on top of
> > > c0bc926083b5987a3e9944eec2c12ad0580100e2: in order to retain binary
> > > compatibility, it is better to introduce foreign_domid as part of a
> > > union containing both size and foreign_domid.
> > [...]
> > > -    domid_t foreign_domid; /* IFF gmfn_foreign */
> > > +    unsigned int space;
> > >  
> > >  #define XENMAPIDX_grant_table_status 0x80000000
> > 
> > Was this the final consensus on what this interface ought to look
> > like?
> > 
> > Does it work for PVH too (Mukesh CCd)?
> 
> Yes it does. Please lmk if the final version asap so I can put in
> my patch, and also test it.

It the final version. I think it should go in, unless we want to drop it
entirely in favor of xen_add_to_physmap_range.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 17 10:58:38 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 10: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 1TDZ1y-0003vK-8e; Mon, 17 Sep 2012 10:58: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 1TDZ1x-0003vB-CX
	for xen-devel@lists.xensource.com; Mon, 17 Sep 2012 10:58:21 +0000
Received: from [85.158.143.35:38234] by server-2.bemta-4.messagelabs.com id
	B8/4D-06610-C4207505; Mon, 17 Sep 2012 10:58:20 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1347879499!15334992!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDk2NDU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32321 invoked from network); 17 Sep 2012 10:58:20 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Sep 2012 10:58:20 -0000
X-IronPort-AV: E=Sophos;i="4.80,434,1344211200"; d="scan'208";a="14577137"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Sep 2012 10:58: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.279.1; Mon, 17 Sep 2012 11:58:05 +0100
Date: Mon, 17 Sep 2012 11:57:19 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Sergei Shtylyov <sshtylyov@mvista.com>
In-Reply-To: <505374E2.5080308@mvista.com>
Message-ID: <alpine.DEB.2.02.1209171155010.29232@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1209141145150.29232@kaball.uk.xensource.com>
	<1347621207-11294-12-git-send-email-stefano.stabellini@eu.citrix.com>
	<505374E2.5080308@mvista.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>,
	"linaro-dev@lists.linaro.org" <linaro-dev@lists.linaro.org>,
	Ian Campbell <Ian.Campbell@citrix.com>, "arnd@arndb.de" <arnd@arndb.de>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
	"catalin.marinas@arm.com" <catalin.marinas@arm.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"Tim \(Xen.org\)" <tim@xen.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux@arm.linux.org.uk" <linux@arm.linux.org.uk>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Xen-devel] [PATCH v4 12/24] xen/arm: introduce CONFIG_XEN on
	ARM
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 14 Sep 2012, Sergei Shtylyov wrote:
> Hello.
> 
> On 09/14/2012 03:13 PM, Stefano Stabellini wrote:
> 
> > Changes in v2:
> 
> > - mark Xen guest support on ARM as EXPERIMENTAL.
> 
> > Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> > Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> > ---
> >  arch/arm/Kconfig |   10 ++++++++++
> >  1 files changed, 10 insertions(+), 0 deletions(-)
> 
> > diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> > index 2f88d8d..e92518d 100644
> > --- a/arch/arm/Kconfig
> > +++ b/arch/arm/Kconfig
> > @@ -1897,6 +1897,16 @@ config DEPRECATED_PARAM_STRUCT
> >  	  This was deprecated in 2001 and announced to live on for 5 years.
> >  	  Some old boot loaders still use this way.
> >  
> > +config XEN_DOM0
> > +	def_bool y
> > +
> > +config XEN
> > +	bool "Xen guest support on ARM (EXPERIMENTAL)"
> > +	depends on EXPERIMENTAL && ARM && OF
> > +	select XEN_DOM0
> 
>    What's the point of selecting it if it's always "y"?

That's because on X86 is not always "y": there are things under
drivers/xen that compile on both platforms and depend on XEN_DOM0.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 17 10:58:38 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 10: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 1TDZ1y-0003vK-8e; Mon, 17 Sep 2012 10:58: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 1TDZ1x-0003vB-CX
	for xen-devel@lists.xensource.com; Mon, 17 Sep 2012 10:58:21 +0000
Received: from [85.158.143.35:38234] by server-2.bemta-4.messagelabs.com id
	B8/4D-06610-C4207505; Mon, 17 Sep 2012 10:58:20 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1347879499!15334992!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDk2NDU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32321 invoked from network); 17 Sep 2012 10:58:20 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Sep 2012 10:58:20 -0000
X-IronPort-AV: E=Sophos;i="4.80,434,1344211200"; d="scan'208";a="14577137"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Sep 2012 10:58: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.279.1; Mon, 17 Sep 2012 11:58:05 +0100
Date: Mon, 17 Sep 2012 11:57:19 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Sergei Shtylyov <sshtylyov@mvista.com>
In-Reply-To: <505374E2.5080308@mvista.com>
Message-ID: <alpine.DEB.2.02.1209171155010.29232@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1209141145150.29232@kaball.uk.xensource.com>
	<1347621207-11294-12-git-send-email-stefano.stabellini@eu.citrix.com>
	<505374E2.5080308@mvista.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>,
	"linaro-dev@lists.linaro.org" <linaro-dev@lists.linaro.org>,
	Ian Campbell <Ian.Campbell@citrix.com>, "arnd@arndb.de" <arnd@arndb.de>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
	"catalin.marinas@arm.com" <catalin.marinas@arm.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"Tim \(Xen.org\)" <tim@xen.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux@arm.linux.org.uk" <linux@arm.linux.org.uk>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Xen-devel] [PATCH v4 12/24] xen/arm: introduce CONFIG_XEN on
	ARM
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 14 Sep 2012, Sergei Shtylyov wrote:
> Hello.
> 
> On 09/14/2012 03:13 PM, Stefano Stabellini wrote:
> 
> > Changes in v2:
> 
> > - mark Xen guest support on ARM as EXPERIMENTAL.
> 
> > Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> > Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> > ---
> >  arch/arm/Kconfig |   10 ++++++++++
> >  1 files changed, 10 insertions(+), 0 deletions(-)
> 
> > diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> > index 2f88d8d..e92518d 100644
> > --- a/arch/arm/Kconfig
> > +++ b/arch/arm/Kconfig
> > @@ -1897,6 +1897,16 @@ config DEPRECATED_PARAM_STRUCT
> >  	  This was deprecated in 2001 and announced to live on for 5 years.
> >  	  Some old boot loaders still use this way.
> >  
> > +config XEN_DOM0
> > +	def_bool y
> > +
> > +config XEN
> > +	bool "Xen guest support on ARM (EXPERIMENTAL)"
> > +	depends on EXPERIMENTAL && ARM && OF
> > +	select XEN_DOM0
> 
>    What's the point of selecting it if it's always "y"?

That's because on X86 is not always "y": there are things under
drivers/xen that compile on both platforms and depend on XEN_DOM0.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 17 11:00:36 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 11:00:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDZ3r-00045s-V5; Mon, 17 Sep 2012 11:00:19 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andreslc@gridcentric.ca>) id 1TDZ3q-00045i-AD
	for xen-devel@lists.xen.org; Mon, 17 Sep 2012 11:00:18 +0000
Received: from [85.158.138.51:3330] by server-9.bemta-3.messagelabs.com id
	EB/23-15390-1C207505; Mon, 17 Sep 2012 11:00:17 +0000
X-Env-Sender: andreslc@gridcentric.ca
X-Msg-Ref: server-16.tower-174.messagelabs.com!1347879615!30768590!1
X-Originating-IP: [209.85.160.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4288 invoked from network); 17 Sep 2012 11:00:16 -0000
Received: from mail-gh0-f173.google.com (HELO mail-gh0-f173.google.com)
	(209.85.160.173)
	by server-16.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Sep 2012 11:00:16 -0000
Received: by ghy16 with SMTP id 16so1710524ghy.32
	for <xen-devel@lists.xen.org>; Mon, 17 Sep 2012 04:00:15 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=subject:mime-version:content-type:from:in-reply-to:date:cc
	:content-transfer-encoding:message-id:references:to:x-mailer
	:x-gm-message-state;
	bh=FcdwF9c0kQTLYApl1A14VGx5aI2kr9L3PKleSlvFvG0=;
	b=IW8CAw/m5tDurt7zWurB/fQCD5M6O2+/vdE4yLnYgLMy2z3aGsbZfbTcryCX+FQack
	66rYYlSjhlyoBFueHWFft58QfCGEOy7cIMhnRFhKyINsbOSVaph+Uvfm9KbSiZZMGT6Z
	ArBJefi9h6CxE0tk3A15BrEjDPev9Io74XekgPAjXcnHETmkVgCY9CAbQtVnK5EJq9m3
	muEBGfDWN9g7tyDbYw6Fqws+84S1U2wOyoxMs0Cpy8wFF7fCuQ3czWa+yOSSp49FCTwY
	NPNtU5qY3lxYy3vqTY7rFEA/6YflwKeM5kjYTIjKAjQCxXxcMcGcqyLbkNeD7XloK5gp
	bQyA==
Received: by 10.236.76.135 with SMTP id b7mr1309102yhe.90.1347879615077;
	Mon, 17 Sep 2012 04:00:15 -0700 (PDT)
Received: from [10.80.114.249] (firewall.ctxuk.citrix.com. [62.200.22.2])
	by mx.google.com with ESMTPS id l25sm13603320yhk.8.2012.09.17.04.00.13
	(version=TLSv1/SSLv3 cipher=OTHER);
	Mon, 17 Sep 2012 04:00:14 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1278)
From: Andres Lagar-Cavilla <andreslc@gridcentric.ca>
In-Reply-To: <40b91bed1275b13e191f.1347550068@xdev.gridcentric.ca>
Date: Mon, 17 Sep 2012 07:00:18 -0400
Message-Id: <7A2C5C61-AFEF-4258-9EEB-CC4A0727920E@gridcentric.ca>
References: <40b91bed1275b13e191f.1347550068@xdev.gridcentric.ca>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
X-Mailer: Apple Mail (2.1278)
X-Gm-Message-State: ALoCoQk+Pb3/E8zVugAMdUWfdCyjagVGiP0TP9dEHiHUz+7cpQxGWPvJjnFjMcauliV1HLLTG5qp
Cc: keir@xen.org, tim@xen.org, JBeulich@suse.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] Extra check in grant table code for mapping
	of shared frame
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <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

ping=85
Thanks,
Andres
On Sep 13, 2012, at 11:27 AM, Andres Lagar-Cavilla wrote:

> xen/common/grant_table.c |  9 ++++++---
> 1 files changed, 6 insertions(+), 3 deletions(-)
> =

> =

> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
> =

> diff -r 5ce5b53ea68f -r 40b91bed1275 xen/common/grant_table.c
> --- a/xen/common/grant_table.c
> +++ b/xen/common/grant_table.c
> @@ -649,9 +649,12 @@ __gnttab_map_grant_ref(
>     }
>     else if ( owner =3D=3D rd || owner =3D=3D dom_cow )
>     {
> -        if ( gnttab_host_mapping_get_page_type(op, ld, rd) &&
> -             !get_page_type(pg, PGT_writable_page) )
> -            goto could_not_pin;
> +        if ( gnttab_host_mapping_get_page_type(op, ld, rd) )
> +        {
> +            if ( (owner =3D=3D dom_cow) ||
> +                 !get_page_type(pg, PGT_writable_page) )
> +                goto could_not_pin;
> +        }
> =

>         nr_gets++;
>         if ( op->flags & GNTMAP_host_map )


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 17 11:00:36 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 11:00:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDZ3r-00045s-V5; Mon, 17 Sep 2012 11:00:19 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andreslc@gridcentric.ca>) id 1TDZ3q-00045i-AD
	for xen-devel@lists.xen.org; Mon, 17 Sep 2012 11:00:18 +0000
Received: from [85.158.138.51:3330] by server-9.bemta-3.messagelabs.com id
	EB/23-15390-1C207505; Mon, 17 Sep 2012 11:00:17 +0000
X-Env-Sender: andreslc@gridcentric.ca
X-Msg-Ref: server-16.tower-174.messagelabs.com!1347879615!30768590!1
X-Originating-IP: [209.85.160.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4288 invoked from network); 17 Sep 2012 11:00:16 -0000
Received: from mail-gh0-f173.google.com (HELO mail-gh0-f173.google.com)
	(209.85.160.173)
	by server-16.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Sep 2012 11:00:16 -0000
Received: by ghy16 with SMTP id 16so1710524ghy.32
	for <xen-devel@lists.xen.org>; Mon, 17 Sep 2012 04:00:15 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=subject:mime-version:content-type:from:in-reply-to:date:cc
	:content-transfer-encoding:message-id:references:to:x-mailer
	:x-gm-message-state;
	bh=FcdwF9c0kQTLYApl1A14VGx5aI2kr9L3PKleSlvFvG0=;
	b=IW8CAw/m5tDurt7zWurB/fQCD5M6O2+/vdE4yLnYgLMy2z3aGsbZfbTcryCX+FQack
	66rYYlSjhlyoBFueHWFft58QfCGEOy7cIMhnRFhKyINsbOSVaph+Uvfm9KbSiZZMGT6Z
	ArBJefi9h6CxE0tk3A15BrEjDPev9Io74XekgPAjXcnHETmkVgCY9CAbQtVnK5EJq9m3
	muEBGfDWN9g7tyDbYw6Fqws+84S1U2wOyoxMs0Cpy8wFF7fCuQ3czWa+yOSSp49FCTwY
	NPNtU5qY3lxYy3vqTY7rFEA/6YflwKeM5kjYTIjKAjQCxXxcMcGcqyLbkNeD7XloK5gp
	bQyA==
Received: by 10.236.76.135 with SMTP id b7mr1309102yhe.90.1347879615077;
	Mon, 17 Sep 2012 04:00:15 -0700 (PDT)
Received: from [10.80.114.249] (firewall.ctxuk.citrix.com. [62.200.22.2])
	by mx.google.com with ESMTPS id l25sm13603320yhk.8.2012.09.17.04.00.13
	(version=TLSv1/SSLv3 cipher=OTHER);
	Mon, 17 Sep 2012 04:00:14 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1278)
From: Andres Lagar-Cavilla <andreslc@gridcentric.ca>
In-Reply-To: <40b91bed1275b13e191f.1347550068@xdev.gridcentric.ca>
Date: Mon, 17 Sep 2012 07:00:18 -0400
Message-Id: <7A2C5C61-AFEF-4258-9EEB-CC4A0727920E@gridcentric.ca>
References: <40b91bed1275b13e191f.1347550068@xdev.gridcentric.ca>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
X-Mailer: Apple Mail (2.1278)
X-Gm-Message-State: ALoCoQk+Pb3/E8zVugAMdUWfdCyjagVGiP0TP9dEHiHUz+7cpQxGWPvJjnFjMcauliV1HLLTG5qp
Cc: keir@xen.org, tim@xen.org, JBeulich@suse.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] Extra check in grant table code for mapping
	of shared frame
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <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

ping=85
Thanks,
Andres
On Sep 13, 2012, at 11:27 AM, Andres Lagar-Cavilla wrote:

> xen/common/grant_table.c |  9 ++++++---
> 1 files changed, 6 insertions(+), 3 deletions(-)
> =

> =

> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
> =

> diff -r 5ce5b53ea68f -r 40b91bed1275 xen/common/grant_table.c
> --- a/xen/common/grant_table.c
> +++ b/xen/common/grant_table.c
> @@ -649,9 +649,12 @@ __gnttab_map_grant_ref(
>     }
>     else if ( owner =3D=3D rd || owner =3D=3D dom_cow )
>     {
> -        if ( gnttab_host_mapping_get_page_type(op, ld, rd) &&
> -             !get_page_type(pg, PGT_writable_page) )
> -            goto could_not_pin;
> +        if ( gnttab_host_mapping_get_page_type(op, ld, rd) )
> +        {
> +            if ( (owner =3D=3D dom_cow) ||
> +                 !get_page_type(pg, PGT_writable_page) )
> +                goto could_not_pin;
> +        }
> =

>         nr_gets++;
>         if ( op->flags & GNTMAP_host_map )


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 17 11:05:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 11: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 1TDZ8I-0004LQ-LZ; Mon, 17 Sep 2012 11:04:54 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ikozhukhov@gmail.com>) id 1TDZ8H-0004LE-Vx
	for xen-devel@lists.xen.org; Mon, 17 Sep 2012 11:04:54 +0000
Received: from [85.158.139.211:46562] by server-10.bemta-5.messagelabs.com id
	54/6C-10969-5D307505; Mon, 17 Sep 2012 11:04:53 +0000
X-Env-Sender: ikozhukhov@gmail.com
X-Msg-Ref: server-16.tower-206.messagelabs.com!1347879892!18890684!1
X-Originating-IP: [209.85.217.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27560 invoked from network); 17 Sep 2012 11:04:52 -0000
Received: from mail-lb0-f173.google.com (HELO mail-lb0-f173.google.com)
	(209.85.217.173)
	by server-16.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Sep 2012 11:04:52 -0000
Received: by lbbgm13 with SMTP id gm13so4980338lbb.32
	for <xen-devel@lists.xen.org>; Mon, 17 Sep 2012 04:04:52 -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
	:in-reply-to:mime-version:content-type:content-transfer-encoding;
	bh=q9HUa1o+qmNTcOAdygUKjXndUbuC1D3yvd1VR7K4aSY=;
	b=R2rip5WnssgjxxBG8RZyezN4/7HfgaGrxa6nx5dEb9YIxYCIsS0ZvwEWPIJiialyOp
	kfXVLl+yNBCzB/1w3lf0cNPVmhF/yNABjxBQqpCb+q2CgNkLM6ZLLxTB/qcRblc5QnlV
	wDdw4hQTmtRNZg9VGio5ALZwQdy4bAg4D+7ltZmFThnLgOwgJ+VSvFQsZ5KGapV0fCm+
	3Yya38YeBej2fOlx0cd8bgIanXLS6Wi5mTlAKCBwkB5eHzr6/Nw8l4pPfjfizKnGa8Rv
	AnFb8wWuin/rL6zJS0mmTVpnFuWfXHwPJQrAJOCp3eKs6ygnNc2ltzW5Cg0n+uU16VPO
	0WKQ==
Received: by 10.112.85.35 with SMTP id e3mr3654141lbz.90.1347879891922;
	Mon, 17 Sep 2012 04:04:51 -0700 (PDT)
Received: from [172.16.90.16] ([91.204.58.44])
	by mx.google.com with ESMTPS id g6sm2524957lby.0.2012.09.17.04.04.48
	(version=SSLv3 cipher=OTHER); Mon, 17 Sep 2012 04:04:50 -0700 (PDT)
User-Agent: Microsoft-MacOutlook/14.2.3.120616
Date: Mon, 17 Sep 2012 15:04:44 +0400
From: Igor Kozhukhov <ikozhukhov@gmail.com>
To: Pasi =?ISO-8859-1?B?S+Rya2vkaW5lbg==?= <pasik@iki.fi>
Message-ID: <CC7CEABD.2D9A5%ikozhukhov@gmail.com>
Thread-Topic: [Xen-devel] xen on illumos(OpenSolaris) based platform
In-Reply-To: <20120917102620.GG8912@reaktio.net>
Mime-version: 1.0
Cc: Keith Coleman <keith.coleman@n2servers.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] xen on illumos(OpenSolaris) based platform
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Thanks for your info.

I'd like to see xen-4.1.3 port on DilOS :)

But - I have some problems with libxl ...

I'm working on build xen-4.1.3 by gcc44(with patches for illumos builds)
on DilOS build env.

Will se what I'll have.

I also have problems with build hvmloader with acpi - I have no acpica
compiler ... - I'll try to port it too for xen build.

Can I disable libel now ? Or I need it for next build steps ?

---
Best regards,
Igor Kozhukhov
IRC# igork




On 9/17/12 2:26 PM, "Pasi K=E4rkk=E4inen" <pasik@iki.fi> wrote:

>On Mon, Sep 17, 2012 at 01:54:21PM +0400, Igor Kozhukhov wrote:
>> =

>> OpenIndiana(OpenSolaris fork) have xen-3.4.2 with solaris patches - but
>> have no builds for it.
>> =

>> I have found sources on opensolaris.org site, port it to userland build
>> system, and try to upgrade to xen-3.4.4.
>> =

>> I'm interested in XEN on DilOS.
>>
>
>Btw Xen 3.4.4 doesn't have the latest security updates, just so you know..
>Also they seem to be missing from 3.4 branch:
>http://xenbits.xen.org/hg/xen-3.4-testing.hg/
>
>Keith Coleman (cc) is maintaining the "old" Xen 3.4 tree.
>
>-- Pasi
> =

>> ---
>> Best regards,
>> Igor Kozhukhov
>> IRC# igork
>> =

>> =

>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 17 11:05:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 11: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 1TDZ8I-0004LQ-LZ; Mon, 17 Sep 2012 11:04:54 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ikozhukhov@gmail.com>) id 1TDZ8H-0004LE-Vx
	for xen-devel@lists.xen.org; Mon, 17 Sep 2012 11:04:54 +0000
Received: from [85.158.139.211:46562] by server-10.bemta-5.messagelabs.com id
	54/6C-10969-5D307505; Mon, 17 Sep 2012 11:04:53 +0000
X-Env-Sender: ikozhukhov@gmail.com
X-Msg-Ref: server-16.tower-206.messagelabs.com!1347879892!18890684!1
X-Originating-IP: [209.85.217.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27560 invoked from network); 17 Sep 2012 11:04:52 -0000
Received: from mail-lb0-f173.google.com (HELO mail-lb0-f173.google.com)
	(209.85.217.173)
	by server-16.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Sep 2012 11:04:52 -0000
Received: by lbbgm13 with SMTP id gm13so4980338lbb.32
	for <xen-devel@lists.xen.org>; Mon, 17 Sep 2012 04:04:52 -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
	:in-reply-to:mime-version:content-type:content-transfer-encoding;
	bh=q9HUa1o+qmNTcOAdygUKjXndUbuC1D3yvd1VR7K4aSY=;
	b=R2rip5WnssgjxxBG8RZyezN4/7HfgaGrxa6nx5dEb9YIxYCIsS0ZvwEWPIJiialyOp
	kfXVLl+yNBCzB/1w3lf0cNPVmhF/yNABjxBQqpCb+q2CgNkLM6ZLLxTB/qcRblc5QnlV
	wDdw4hQTmtRNZg9VGio5ALZwQdy4bAg4D+7ltZmFThnLgOwgJ+VSvFQsZ5KGapV0fCm+
	3Yya38YeBej2fOlx0cd8bgIanXLS6Wi5mTlAKCBwkB5eHzr6/Nw8l4pPfjfizKnGa8Rv
	AnFb8wWuin/rL6zJS0mmTVpnFuWfXHwPJQrAJOCp3eKs6ygnNc2ltzW5Cg0n+uU16VPO
	0WKQ==
Received: by 10.112.85.35 with SMTP id e3mr3654141lbz.90.1347879891922;
	Mon, 17 Sep 2012 04:04:51 -0700 (PDT)
Received: from [172.16.90.16] ([91.204.58.44])
	by mx.google.com with ESMTPS id g6sm2524957lby.0.2012.09.17.04.04.48
	(version=SSLv3 cipher=OTHER); Mon, 17 Sep 2012 04:04:50 -0700 (PDT)
User-Agent: Microsoft-MacOutlook/14.2.3.120616
Date: Mon, 17 Sep 2012 15:04:44 +0400
From: Igor Kozhukhov <ikozhukhov@gmail.com>
To: Pasi =?ISO-8859-1?B?S+Rya2vkaW5lbg==?= <pasik@iki.fi>
Message-ID: <CC7CEABD.2D9A5%ikozhukhov@gmail.com>
Thread-Topic: [Xen-devel] xen on illumos(OpenSolaris) based platform
In-Reply-To: <20120917102620.GG8912@reaktio.net>
Mime-version: 1.0
Cc: Keith Coleman <keith.coleman@n2servers.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] xen on illumos(OpenSolaris) based platform
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Thanks for your info.

I'd like to see xen-4.1.3 port on DilOS :)

But - I have some problems with libxl ...

I'm working on build xen-4.1.3 by gcc44(with patches for illumos builds)
on DilOS build env.

Will se what I'll have.

I also have problems with build hvmloader with acpi - I have no acpica
compiler ... - I'll try to port it too for xen build.

Can I disable libel now ? Or I need it for next build steps ?

---
Best regards,
Igor Kozhukhov
IRC# igork




On 9/17/12 2:26 PM, "Pasi K=E4rkk=E4inen" <pasik@iki.fi> wrote:

>On Mon, Sep 17, 2012 at 01:54:21PM +0400, Igor Kozhukhov wrote:
>> =

>> OpenIndiana(OpenSolaris fork) have xen-3.4.2 with solaris patches - but
>> have no builds for it.
>> =

>> I have found sources on opensolaris.org site, port it to userland build
>> system, and try to upgrade to xen-3.4.4.
>> =

>> I'm interested in XEN on DilOS.
>>
>
>Btw Xen 3.4.4 doesn't have the latest security updates, just so you know..
>Also they seem to be missing from 3.4 branch:
>http://xenbits.xen.org/hg/xen-3.4-testing.hg/
>
>Keith Coleman (cc) is maintaining the "old" Xen 3.4 tree.
>
>-- Pasi
> =

>> ---
>> Best regards,
>> Igor Kozhukhov
>> IRC# igork
>> =

>> =

>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 17 11:07:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 11:07:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDZA7-0004Ry-5I; Mon, 17 Sep 2012 11:06:47 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1TDZA5-0004Rp-Mn
	for xen-devel@lists.xensource.com; Mon, 17 Sep 2012 11:06:45 +0000
Received: from [85.158.143.99:65243] by server-1.bemta-4.messagelabs.com id
	06/9E-12504-54407505; Mon, 17 Sep 2012 11:06:45 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1347880004!24531552!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDk2NDU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22146 invoked from network); 17 Sep 2012 11:06:44 -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;
	17 Sep 2012 11:06:44 -0000
X-IronPort-AV: E=Sophos;i="4.80,434,1344211200"; d="scan'208";a="14577361"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Sep 2012 11:06: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.279.1; Mon, 17 Sep 2012 12:06:44 +0100
Date: Mon, 17 Sep 2012 12:05:59 +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: <20120914130308.GI25249@phenom.dumpdata.com>
Message-ID: <alpine.DEB.2.02.1209171205470.29232@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1209141145150.29232@kaball.uk.xensource.com>
	<1347621207-11294-10-git-send-email-stefano.stabellini@eu.citrix.com>
	<20120914130308.GI25249@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>,
	"linaro-dev@lists.linaro.org" <linaro-dev@lists.linaro.org>,
	Ian Campbell <Ian.Campbell@citrix.com>, "arnd@arndb.de" <arnd@arndb.de>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"catalin.marinas@arm.com" <catalin.marinas@arm.com>,
	"Tim \(Xen.org\)" <tim@xen.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux@arm.linux.org.uk" <linux@arm.linux.org.uk>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Xen-devel] [PATCH v4 10/24] xen/arm: compile and run xenbus
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 14 Sep 2012, Konrad Rzeszutek Wilk wrote:
> On Fri, Sep 14, 2012 at 12:13:12PM +0100, Stefano Stabellini wrote:
> > bind_evtchn_to_irqhandler can legitimately return 0 (irq 0): it is not
> > an error.
> > 
> > If Linux is running as an HVM domain and is running as Dom0, use
> > xenstored_local_init to initialize the xenstore page and event channel.
> 
> Let me stick it in my tree and see how it works overnight with HVM and PV guests.

Did it work?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 17 11:07:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 11:07:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDZA7-0004Ry-5I; Mon, 17 Sep 2012 11:06:47 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1TDZA5-0004Rp-Mn
	for xen-devel@lists.xensource.com; Mon, 17 Sep 2012 11:06:45 +0000
Received: from [85.158.143.99:65243] by server-1.bemta-4.messagelabs.com id
	06/9E-12504-54407505; Mon, 17 Sep 2012 11:06:45 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1347880004!24531552!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDk2NDU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22146 invoked from network); 17 Sep 2012 11:06:44 -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;
	17 Sep 2012 11:06:44 -0000
X-IronPort-AV: E=Sophos;i="4.80,434,1344211200"; d="scan'208";a="14577361"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Sep 2012 11:06: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.279.1; Mon, 17 Sep 2012 12:06:44 +0100
Date: Mon, 17 Sep 2012 12:05:59 +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: <20120914130308.GI25249@phenom.dumpdata.com>
Message-ID: <alpine.DEB.2.02.1209171205470.29232@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1209141145150.29232@kaball.uk.xensource.com>
	<1347621207-11294-10-git-send-email-stefano.stabellini@eu.citrix.com>
	<20120914130308.GI25249@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>,
	"linaro-dev@lists.linaro.org" <linaro-dev@lists.linaro.org>,
	Ian Campbell <Ian.Campbell@citrix.com>, "arnd@arndb.de" <arnd@arndb.de>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"catalin.marinas@arm.com" <catalin.marinas@arm.com>,
	"Tim \(Xen.org\)" <tim@xen.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux@arm.linux.org.uk" <linux@arm.linux.org.uk>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Xen-devel] [PATCH v4 10/24] xen/arm: compile and run xenbus
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 14 Sep 2012, Konrad Rzeszutek Wilk wrote:
> On Fri, Sep 14, 2012 at 12:13:12PM +0100, Stefano Stabellini wrote:
> > bind_evtchn_to_irqhandler can legitimately return 0 (irq 0): it is not
> > an error.
> > 
> > If Linux is running as an HVM domain and is running as Dom0, use
> > xenstored_local_init to initialize the xenstore page and event channel.
> 
> Let me stick it in my tree and see how it works overnight with HVM and PV guests.

Did it work?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 17 11:17:55 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 11:17: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 1TDZKe-0004fH-At; Mon, 17 Sep 2012 11:17:40 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1TDZKc-0004fC-KG
	for xen-devel@lists.xen.org; Mon, 17 Sep 2012 11:17:38 +0000
Received: from [85.158.139.211:60380] by server-10.bemta-5.messagelabs.com id
	99/1A-10969-1D607505; Mon, 17 Sep 2012 11:17:37 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-4.tower-206.messagelabs.com!1347880657!18872045!1
X-Originating-IP: [74.125.83.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14376 invoked from network); 17 Sep 2012 11:17:37 -0000
Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com)
	(74.125.83.45)
	by server-4.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Sep 2012 11:17:37 -0000
Received: by eeke53 with SMTP id e53so3484107eek.32
	for <xen-devel@lists.xen.org>; Mon, 17 Sep 2012 04:17:37 -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=0z4ezaxCknV8MmLz9Xx4VTDGCzgukUHDIg6SJLduJlQ=;
	b=F/uPqXnJ6unmf5bcpokKh1NSzOz2V9FDLGszE8EgGv+N4+bfbsCK8NMiUeSeM+0DT2
	T7bT6ftGPWrUYtRol/PIN6Bp1An3Mgsn2isDwOXn+VCTW5Xu7ysc8gTmv++ENDvgOZeW
	wNwWBY2PB8iEDLJo5DhggBpvDihizGGnCPhn415ysOCIggev5HVZpIsFcwMvV0br1XcJ
	x70N/wndinIm3ns8V45wHPWXf8IbaC70e/gWqBdNj2V8fST89K1zcRG0Ra6kTRyTrk2k
	7wsARcro8aQOuwfW/6PEJ636mz6UX3RGTHYX7oprOMbTcP9O+4pcMUOJ2f/hcZLk5X5y
	kjCw==
Received: by 10.14.198.133 with SMTP id v5mr528221een.7.1347880657168;
	Mon, 17 Sep 2012 04:17:37 -0700 (PDT)
Received: from [192.168.1.3] (host86-183-251-65.range86-183.btcentralplus.com.
	[86.183.251.65])
	by mx.google.com with ESMTPS id 45sm26692095eed.17.2012.09.17.04.17.34
	(version=SSLv3 cipher=OTHER); Mon, 17 Sep 2012 04:17:36 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.33.0.120411
Date: Mon, 17 Sep 2012 12:17:27 +0100
From: Keir Fraser <keir@xen.org>
To: Andres Lagar-Cavilla <andreslc@gridcentric.ca>,
	Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <CC7CC557.4BEFD%keir@xen.org>
Thread-Topic: [PATCH] Extra check in grant table code for mapping of shared
	frame
Thread-Index: Ac2UxgTiWrBmrfifbU6E36D4vEPQ0A==
In-Reply-To: <7A2C5C61-AFEF-4258-9EEB-CC4A0727920E@gridcentric.ca>
Mime-version: 1.0
Cc: tim@xen.org, JBeulich@suse.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] Extra check in grant table code for mapping
 of shared frame
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Probably needs Tim to comment on it. Assuming he's any wiser about this code
than the rest of us. ;)

 -- Keir

On 17/09/2012 12:00, "Andres Lagar-Cavilla" <andreslc@gridcentric.ca> wrote:

> ping=8A
> Thanks,
> Andres
> On Sep 13, 2012, at 11:27 AM, Andres Lagar-Cavilla wrote:
> =

>> xen/common/grant_table.c |  9 ++++++---
>> 1 files changed, 6 insertions(+), 3 deletions(-)
>> =

>> =

>> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
>> =

>> diff -r 5ce5b53ea68f -r 40b91bed1275 xen/common/grant_table.c
>> --- a/xen/common/grant_table.c
>> +++ b/xen/common/grant_table.c
>> @@ -649,9 +649,12 @@ __gnttab_map_grant_ref(
>>     }
>>     else if ( owner =3D=3D rd || owner =3D=3D dom_cow )
>>     {
>> -        if ( gnttab_host_mapping_get_page_type(op, ld, rd) &&
>> -             !get_page_type(pg, PGT_writable_page) )
>> -            goto could_not_pin;
>> +        if ( gnttab_host_mapping_get_page_type(op, ld, rd) )
>> +        {
>> +            if ( (owner =3D=3D dom_cow) ||
>> +                 !get_page_type(pg, PGT_writable_page) )
>> +                goto could_not_pin;
>> +        }
>> =

>>         nr_gets++;
>>         if ( op->flags & GNTMAP_host_map )
> =




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 17 11:17:55 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 11:17: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 1TDZKe-0004fH-At; Mon, 17 Sep 2012 11:17:40 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1TDZKc-0004fC-KG
	for xen-devel@lists.xen.org; Mon, 17 Sep 2012 11:17:38 +0000
Received: from [85.158.139.211:60380] by server-10.bemta-5.messagelabs.com id
	99/1A-10969-1D607505; Mon, 17 Sep 2012 11:17:37 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-4.tower-206.messagelabs.com!1347880657!18872045!1
X-Originating-IP: [74.125.83.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14376 invoked from network); 17 Sep 2012 11:17:37 -0000
Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com)
	(74.125.83.45)
	by server-4.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Sep 2012 11:17:37 -0000
Received: by eeke53 with SMTP id e53so3484107eek.32
	for <xen-devel@lists.xen.org>; Mon, 17 Sep 2012 04:17:37 -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=0z4ezaxCknV8MmLz9Xx4VTDGCzgukUHDIg6SJLduJlQ=;
	b=F/uPqXnJ6unmf5bcpokKh1NSzOz2V9FDLGszE8EgGv+N4+bfbsCK8NMiUeSeM+0DT2
	T7bT6ftGPWrUYtRol/PIN6Bp1An3Mgsn2isDwOXn+VCTW5Xu7ysc8gTmv++ENDvgOZeW
	wNwWBY2PB8iEDLJo5DhggBpvDihizGGnCPhn415ysOCIggev5HVZpIsFcwMvV0br1XcJ
	x70N/wndinIm3ns8V45wHPWXf8IbaC70e/gWqBdNj2V8fST89K1zcRG0Ra6kTRyTrk2k
	7wsARcro8aQOuwfW/6PEJ636mz6UX3RGTHYX7oprOMbTcP9O+4pcMUOJ2f/hcZLk5X5y
	kjCw==
Received: by 10.14.198.133 with SMTP id v5mr528221een.7.1347880657168;
	Mon, 17 Sep 2012 04:17:37 -0700 (PDT)
Received: from [192.168.1.3] (host86-183-251-65.range86-183.btcentralplus.com.
	[86.183.251.65])
	by mx.google.com with ESMTPS id 45sm26692095eed.17.2012.09.17.04.17.34
	(version=SSLv3 cipher=OTHER); Mon, 17 Sep 2012 04:17:36 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.33.0.120411
Date: Mon, 17 Sep 2012 12:17:27 +0100
From: Keir Fraser <keir@xen.org>
To: Andres Lagar-Cavilla <andreslc@gridcentric.ca>,
	Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <CC7CC557.4BEFD%keir@xen.org>
Thread-Topic: [PATCH] Extra check in grant table code for mapping of shared
	frame
Thread-Index: Ac2UxgTiWrBmrfifbU6E36D4vEPQ0A==
In-Reply-To: <7A2C5C61-AFEF-4258-9EEB-CC4A0727920E@gridcentric.ca>
Mime-version: 1.0
Cc: tim@xen.org, JBeulich@suse.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] Extra check in grant table code for mapping
 of shared frame
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Probably needs Tim to comment on it. Assuming he's any wiser about this code
than the rest of us. ;)

 -- Keir

On 17/09/2012 12:00, "Andres Lagar-Cavilla" <andreslc@gridcentric.ca> wrote:

> ping=8A
> Thanks,
> Andres
> On Sep 13, 2012, at 11:27 AM, Andres Lagar-Cavilla wrote:
> =

>> xen/common/grant_table.c |  9 ++++++---
>> 1 files changed, 6 insertions(+), 3 deletions(-)
>> =

>> =

>> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
>> =

>> diff -r 5ce5b53ea68f -r 40b91bed1275 xen/common/grant_table.c
>> --- a/xen/common/grant_table.c
>> +++ b/xen/common/grant_table.c
>> @@ -649,9 +649,12 @@ __gnttab_map_grant_ref(
>>     }
>>     else if ( owner =3D=3D rd || owner =3D=3D dom_cow )
>>     {
>> -        if ( gnttab_host_mapping_get_page_type(op, ld, rd) &&
>> -             !get_page_type(pg, PGT_writable_page) )
>> -            goto could_not_pin;
>> +        if ( gnttab_host_mapping_get_page_type(op, ld, rd) )
>> +        {
>> +            if ( (owner =3D=3D dom_cow) ||
>> +                 !get_page_type(pg, PGT_writable_page) )
>> +                goto could_not_pin;
>> +        }
>> =

>>         nr_gets++;
>>         if ( op->flags & GNTMAP_host_map )
> =




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 17 11:24:10 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 11:24: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 1TDZQd-0004oq-8b; Mon, 17 Sep 2012 11:23:51 +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 1TDZQb-0004oi-9l
	for xen-devel@lists.xen.org; Mon, 17 Sep 2012 11:23:49 +0000
Received: from [85.158.139.83:34504] by server-9.bemta-5.messagelabs.com id
	DC/65-20529-44807505; Mon, 17 Sep 2012 11:23:48 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1347881027!26957452!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDk2NDU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27608 invoked from network); 17 Sep 2012 11:23:48 -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;
	17 Sep 2012 11:23:48 -0000
X-IronPort-AV: E=Sophos;i="4.80,434,1344211200"; d="scan'208";a="14577756"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Sep 2012 11:23:46 +0000
Received: from Roger-2.local (10.31.3.231) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Mon, 17 Sep 2012 12:23:46 +0100
Message-ID: <50570840.5020507@citrix.com>
Date: Mon, 17 Sep 2012 13:23:44 +0200
From: Roger Pau Monne <roger.pau@citrix.com>
User-Agent: Postbox 3.0.5 (Macintosh/20120826)
MIME-Version: 1.0
To: Igor Kozhukhov <ikozhukhov@gmail.com>
References: <CC7CEABD.2D9A5%ikozhukhov@gmail.com>
In-Reply-To: <CC7CEABD.2D9A5%ikozhukhov@gmail.com>
X-Enigmail-Version: 1.2.2
Cc: Keith Coleman <keith.coleman@n2servers.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] xen on illumos(OpenSolaris) based 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

Igor Kozhukhov wrote:
> Thanks for your info.
>
> I'd like to see xen-4.1.3 port on DilOS :)
>
> But - I have some problems with libxl ...

libxl has seen major changes in upcoming release (4.2), which I think
will be interesting for Solaris, and will make the port easier. Also
xend has been deprecated, so you should aim at porting libxl to Solaris.
I've been working on porting libxl to NetBSD, so if you need I can help
you on that.

> I'm working on build xen-4.1.3 by gcc44(with patches for illumos builds)
> on DilOS build env.
>
> Will se what I'll have.
>
> I also have problems with build hvmloader with acpi - I have no acpica
> compiler ... - I'll try to port it too for xen build.
>
> Can I disable libel now ? Or I need it for next build steps ?

You can disable libxl and use xend instead, but as I said above xend is
deprecated and libxl (xl) is going to replace it.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 17 11:24:10 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 11:24: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 1TDZQd-0004oq-8b; Mon, 17 Sep 2012 11:23:51 +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 1TDZQb-0004oi-9l
	for xen-devel@lists.xen.org; Mon, 17 Sep 2012 11:23:49 +0000
Received: from [85.158.139.83:34504] by server-9.bemta-5.messagelabs.com id
	DC/65-20529-44807505; Mon, 17 Sep 2012 11:23:48 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1347881027!26957452!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDk2NDU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27608 invoked from network); 17 Sep 2012 11:23:48 -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;
	17 Sep 2012 11:23:48 -0000
X-IronPort-AV: E=Sophos;i="4.80,434,1344211200"; d="scan'208";a="14577756"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Sep 2012 11:23:46 +0000
Received: from Roger-2.local (10.31.3.231) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Mon, 17 Sep 2012 12:23:46 +0100
Message-ID: <50570840.5020507@citrix.com>
Date: Mon, 17 Sep 2012 13:23:44 +0200
From: Roger Pau Monne <roger.pau@citrix.com>
User-Agent: Postbox 3.0.5 (Macintosh/20120826)
MIME-Version: 1.0
To: Igor Kozhukhov <ikozhukhov@gmail.com>
References: <CC7CEABD.2D9A5%ikozhukhov@gmail.com>
In-Reply-To: <CC7CEABD.2D9A5%ikozhukhov@gmail.com>
X-Enigmail-Version: 1.2.2
Cc: Keith Coleman <keith.coleman@n2servers.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] xen on illumos(OpenSolaris) based 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

Igor Kozhukhov wrote:
> Thanks for your info.
>
> I'd like to see xen-4.1.3 port on DilOS :)
>
> But - I have some problems with libxl ...

libxl has seen major changes in upcoming release (4.2), which I think
will be interesting for Solaris, and will make the port easier. Also
xend has been deprecated, so you should aim at porting libxl to Solaris.
I've been working on porting libxl to NetBSD, so if you need I can help
you on that.

> I'm working on build xen-4.1.3 by gcc44(with patches for illumos builds)
> on DilOS build env.
>
> Will se what I'll have.
>
> I also have problems with build hvmloader with acpi - I have no acpica
> compiler ... - I'll try to port it too for xen build.
>
> Can I disable libel now ? Or I need it for next build steps ?

You can disable libxl and use xend instead, but as I said above xend is
deprecated and libxl (xl) is going to replace it.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 17 11:30:51 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 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 1TDZX4-0004zi-3W; Mon, 17 Sep 2012 11:30:30 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ikozhukhov@gmail.com>) id 1TDZX3-0004zd-0o
	for xen-devel@lists.xen.org; Mon, 17 Sep 2012 11:30:29 +0000
Received: from [85.158.143.35:13450] by server-1.bemta-4.messagelabs.com id
	35/E8-12504-4D907505; Mon, 17 Sep 2012 11:30:28 +0000
X-Env-Sender: ikozhukhov@gmail.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1347881425!18594685!1
X-Originating-IP: [209.85.217.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3811 invoked from network); 17 Sep 2012 11:30:26 -0000
Received: from mail-lb0-f173.google.com (HELO mail-lb0-f173.google.com)
	(209.85.217.173)
	by server-6.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Sep 2012 11:30:26 -0000
Received: by lbbgm13 with SMTP id gm13so4998623lbb.32
	for <xen-devel@lists.xen.org>; Mon, 17 Sep 2012 04:30:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=user-agent:date:subject:from:to:cc:message-id:thread-topic
	:in-reply-to:mime-version:content-type:content-transfer-encoding;
	bh=4EG4goeD7K9ID4/tHA+ws9PZ2+QrW69J4yaUF/6KakE=;
	b=xAYmgzDG0gQcyr0mmldZEauw5Vrf7cNhJNrbl89CNxQLnRrrLmfidEKLOWoibbOmA9
	a2gd/klELwte9Nz9tM6uTzHzHMIHBETzae/q8f3sGLVgt4Uq7wjv+xoa7qtVz1/TSDOA
	ayWMHibnYdsnPtmyiSrw5PpECobwUpjwqXRIj+ECOW8/H+77pypK4gp2JbBW60arzWh6
	jUMRGRFJS/J1lzSbCRzv5yLY2uSQqEXZKMKG6df/5cRewlMrOU7wOlCwkuGd+YUwuDWn
	JuR5T9qAWaVFTyegRPQ8L96TNWZl9S5RXEXApX8243SsMnnamI0EQ3amY0/d51TQFRSM
	hdCw==
Received: by 10.152.104.202 with SMTP id gg10mr9538297lab.56.1347881425208;
	Mon, 17 Sep 2012 04:30:25 -0700 (PDT)
Received: from [172.16.90.16] ([91.204.58.44])
	by mx.google.com with ESMTPS id g6sm2542714lby.0.2012.09.17.04.30.19
	(version=SSLv3 cipher=OTHER); Mon, 17 Sep 2012 04:30:23 -0700 (PDT)
User-Agent: Microsoft-MacOutlook/14.2.3.120616
Date: Mon, 17 Sep 2012 15:30:12 +0400
From: Igor Kozhukhov <ikozhukhov@gmail.com>
To: Roger Pau Monne <roger.pau@citrix.com>
Message-ID: <CC7CF202.2D9CC%ikozhukhov@gmail.com>
Thread-Topic: [Xen-devel] xen on illumos(OpenSolaris) based platform
In-Reply-To: <50570840.5020507@citrix.com>
Mime-version: 1.0
Cc: Keith Coleman <keith.coleman@n2servers.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] xen on illumos(OpenSolaris) based 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

Roger,

Thanks for your update.
Yes - I have questions with libxl and we can talk about it.

I'll try disable it for xen-4.1.3 and use xend - the same with xen-3.4.4 -
I have scripts for it.

---
Best regards,
Igor Kozhukhov
IRC# igork




On 9/17/12 3:23 PM, "Roger Pau Monne" <roger.pau@citrix.com> wrote:

>Igor Kozhukhov wrote:
>> Thanks for your info.
>>
>> I'd like to see xen-4.1.3 port on DilOS :)
>>
>> But - I have some problems with libxl ...
>
>libxl has seen major changes in upcoming release (4.2), which I think
>will be interesting for Solaris, and will make the port easier. Also
>xend has been deprecated, so you should aim at porting libxl to Solaris.
>I've been working on porting libxl to NetBSD, so if you need I can help
>you on that.
>
>> I'm working on build xen-4.1.3 by gcc44(with patches for illumos builds)
>> on DilOS build env.
>>
>> Will se what I'll have.
>>
>> I also have problems with build hvmloader with acpi - I have no acpica
>> compiler ... - I'll try to port it too for xen build.
>>
>> Can I disable libel now ? Or I need it for next build steps ?
>
>You can disable libxl and use xend instead, but as I said above xend is
>deprecated and libxl (xl) is going to replace it.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 17 11:30:51 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 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 1TDZX4-0004zi-3W; Mon, 17 Sep 2012 11:30:30 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ikozhukhov@gmail.com>) id 1TDZX3-0004zd-0o
	for xen-devel@lists.xen.org; Mon, 17 Sep 2012 11:30:29 +0000
Received: from [85.158.143.35:13450] by server-1.bemta-4.messagelabs.com id
	35/E8-12504-4D907505; Mon, 17 Sep 2012 11:30:28 +0000
X-Env-Sender: ikozhukhov@gmail.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1347881425!18594685!1
X-Originating-IP: [209.85.217.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3811 invoked from network); 17 Sep 2012 11:30:26 -0000
Received: from mail-lb0-f173.google.com (HELO mail-lb0-f173.google.com)
	(209.85.217.173)
	by server-6.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Sep 2012 11:30:26 -0000
Received: by lbbgm13 with SMTP id gm13so4998623lbb.32
	for <xen-devel@lists.xen.org>; Mon, 17 Sep 2012 04:30:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=user-agent:date:subject:from:to:cc:message-id:thread-topic
	:in-reply-to:mime-version:content-type:content-transfer-encoding;
	bh=4EG4goeD7K9ID4/tHA+ws9PZ2+QrW69J4yaUF/6KakE=;
	b=xAYmgzDG0gQcyr0mmldZEauw5Vrf7cNhJNrbl89CNxQLnRrrLmfidEKLOWoibbOmA9
	a2gd/klELwte9Nz9tM6uTzHzHMIHBETzae/q8f3sGLVgt4Uq7wjv+xoa7qtVz1/TSDOA
	ayWMHibnYdsnPtmyiSrw5PpECobwUpjwqXRIj+ECOW8/H+77pypK4gp2JbBW60arzWh6
	jUMRGRFJS/J1lzSbCRzv5yLY2uSQqEXZKMKG6df/5cRewlMrOU7wOlCwkuGd+YUwuDWn
	JuR5T9qAWaVFTyegRPQ8L96TNWZl9S5RXEXApX8243SsMnnamI0EQ3amY0/d51TQFRSM
	hdCw==
Received: by 10.152.104.202 with SMTP id gg10mr9538297lab.56.1347881425208;
	Mon, 17 Sep 2012 04:30:25 -0700 (PDT)
Received: from [172.16.90.16] ([91.204.58.44])
	by mx.google.com with ESMTPS id g6sm2542714lby.0.2012.09.17.04.30.19
	(version=SSLv3 cipher=OTHER); Mon, 17 Sep 2012 04:30:23 -0700 (PDT)
User-Agent: Microsoft-MacOutlook/14.2.3.120616
Date: Mon, 17 Sep 2012 15:30:12 +0400
From: Igor Kozhukhov <ikozhukhov@gmail.com>
To: Roger Pau Monne <roger.pau@citrix.com>
Message-ID: <CC7CF202.2D9CC%ikozhukhov@gmail.com>
Thread-Topic: [Xen-devel] xen on illumos(OpenSolaris) based platform
In-Reply-To: <50570840.5020507@citrix.com>
Mime-version: 1.0
Cc: Keith Coleman <keith.coleman@n2servers.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] xen on illumos(OpenSolaris) based 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

Roger,

Thanks for your update.
Yes - I have questions with libxl and we can talk about it.

I'll try disable it for xen-4.1.3 and use xend - the same with xen-3.4.4 -
I have scripts for it.

---
Best regards,
Igor Kozhukhov
IRC# igork




On 9/17/12 3:23 PM, "Roger Pau Monne" <roger.pau@citrix.com> wrote:

>Igor Kozhukhov wrote:
>> Thanks for your info.
>>
>> I'd like to see xen-4.1.3 port on DilOS :)
>>
>> But - I have some problems with libxl ...
>
>libxl has seen major changes in upcoming release (4.2), which I think
>will be interesting for Solaris, and will make the port easier. Also
>xend has been deprecated, so you should aim at porting libxl to Solaris.
>I've been working on porting libxl to NetBSD, so if you need I can help
>you on that.
>
>> I'm working on build xen-4.1.3 by gcc44(with patches for illumos builds)
>> on DilOS build env.
>>
>> Will se what I'll have.
>>
>> I also have problems with build hvmloader with acpi - I have no acpica
>> compiler ... - I'll try to port it too for xen build.
>>
>> Can I disable libel now ? Or I need it for next build steps ?
>
>You can disable libxl and use xend instead, but as I said above xend is
>deprecated and libxl (xl) is going to replace it.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 17 11:34:20 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 11:34:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDZaa-0005HM-JH; Mon, 17 Sep 2012 11:34:08 +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 1TDZaY-0005Gv-WD
	for xen-devel@lists.xen.org; Mon, 17 Sep 2012 11:34:07 +0000
Received: from [85.158.143.35:34451] by server-2.bemta-4.messagelabs.com id
	74/EE-06610-EAA07505; Mon, 17 Sep 2012 11:34:06 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1347881645!16124182!1
X-Originating-IP: [74.125.83.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3896 invoked from network); 17 Sep 2012 11:34:05 -0000
Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com)
	(74.125.83.45)
	by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Sep 2012 11:34:05 -0000
Received: by eeke53 with SMTP id e53so3492694eek.32
	for <xen-devel@lists.xen.org>; Mon, 17 Sep 2012 04:34:05 -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=KvDUGwqL50EzLj62aNaIqzcaqjT+QM9gA3VNfw9HUtg=;
	b=EUbt4NxKA3BXuu3+dTLHLn9qpqnCVJCI0WjLEpszfUs78ApKc02NajRu5WB5mmlMnS
	4H2hShKAFCnXoczMKKOE4pmV0EQF1j3pCS1aZWYgyTYbcTIi3ASl4KU7sgiOsfaqFNa0
	Ivy7I6+z+Nt/puwtVQjM8c7N3eBciCofE3oo4XyXgNUF3XmTeOj6xAx8wDBKjns6qFii
	xKvM0emuN6EeTSOzk/HQWZkznXKWRC8iE0xBJh+j8RlpRafPW8LnBiHK24KDBJ3eSped
	M+idjD+hjUroIikZCHTeTkS4EpN6YrF5/zndkyh63hPOZR43rHOwTye7O4eA0fGjMuR7
	u4Pg==
Received: by 10.14.205.6 with SMTP id i6mr13062882eeo.13.1347881645486;
	Mon, 17 Sep 2012 04:34:05 -0700 (PDT)
Received: from [192.168.1.3] (host86-183-251-65.range86-183.btcentralplus.com.
	[86.183.251.65])
	by mx.google.com with ESMTPS id z3sm26833209eel.15.2012.09.17.04.34.04
	(version=SSLv3 cipher=OTHER); Mon, 17 Sep 2012 04:34:04 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.33.0.120411
Date: Mon, 17 Sep 2012 12:34:00 +0100
From: Keir Fraser <keir@xen.org>
To: <xen-devel@lists.xen.org>
Message-ID: <CC7CC938.4BF7C%keir@xen.org>
Thread-Topic: [ANNOUNCE] Xen 4.2 released!
Thread-Index: Ac2UyFTClqs3XI5IGUe8pAGekpsn7A==
Mime-version: 1.0
Subject: [Xen-devel] [ANNOUNCE] Xen 4.2 released!
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

The Xen team is pleased to announce the release of Xen 4.2.

The result of *18 months* of development, new features include:
 * Paging/sharing improvements for high-density VM environments (eg. VDI)
 * Enhancements to PV-HVM guest performance
 * Improved memaccess (guest introspection) support
 * EFI boot support, replacing the legacy BIOS boot environment
 * Improved RAS support
 * XL as the default toolstack; XEND officially deprecated
 * Upstream QEMU support, with its up-to-date feature list

Detailed release notes, including a more extensive feature list:
  http://wiki.xen.org/wiki/Xen_4.2_Release_Notes

To download tarballs:
  http://xen.org/download/index_4.2.0.html
Or the Mercurial source repository (tag 'RELEASE-4.2.0'):
  http://xenbits.xen.org/hg/staging/xen-4.2-testing.hg

And the announcement on the Xen blog:
  http://blog.xen.org/index.php/2012/09/17/xen-4-2-0-released/

Thanks to the many people who have contributed to this release!

 Regards,
 The Xen Team



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 17 11:34:20 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 11:34:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDZaa-0005HM-JH; Mon, 17 Sep 2012 11:34:08 +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 1TDZaY-0005Gv-WD
	for xen-devel@lists.xen.org; Mon, 17 Sep 2012 11:34:07 +0000
Received: from [85.158.143.35:34451] by server-2.bemta-4.messagelabs.com id
	74/EE-06610-EAA07505; Mon, 17 Sep 2012 11:34:06 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1347881645!16124182!1
X-Originating-IP: [74.125.83.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3896 invoked from network); 17 Sep 2012 11:34:05 -0000
Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com)
	(74.125.83.45)
	by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Sep 2012 11:34:05 -0000
Received: by eeke53 with SMTP id e53so3492694eek.32
	for <xen-devel@lists.xen.org>; Mon, 17 Sep 2012 04:34:05 -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=KvDUGwqL50EzLj62aNaIqzcaqjT+QM9gA3VNfw9HUtg=;
	b=EUbt4NxKA3BXuu3+dTLHLn9qpqnCVJCI0WjLEpszfUs78ApKc02NajRu5WB5mmlMnS
	4H2hShKAFCnXoczMKKOE4pmV0EQF1j3pCS1aZWYgyTYbcTIi3ASl4KU7sgiOsfaqFNa0
	Ivy7I6+z+Nt/puwtVQjM8c7N3eBciCofE3oo4XyXgNUF3XmTeOj6xAx8wDBKjns6qFii
	xKvM0emuN6EeTSOzk/HQWZkznXKWRC8iE0xBJh+j8RlpRafPW8LnBiHK24KDBJ3eSped
	M+idjD+hjUroIikZCHTeTkS4EpN6YrF5/zndkyh63hPOZR43rHOwTye7O4eA0fGjMuR7
	u4Pg==
Received: by 10.14.205.6 with SMTP id i6mr13062882eeo.13.1347881645486;
	Mon, 17 Sep 2012 04:34:05 -0700 (PDT)
Received: from [192.168.1.3] (host86-183-251-65.range86-183.btcentralplus.com.
	[86.183.251.65])
	by mx.google.com with ESMTPS id z3sm26833209eel.15.2012.09.17.04.34.04
	(version=SSLv3 cipher=OTHER); Mon, 17 Sep 2012 04:34:04 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.33.0.120411
Date: Mon, 17 Sep 2012 12:34:00 +0100
From: Keir Fraser <keir@xen.org>
To: <xen-devel@lists.xen.org>
Message-ID: <CC7CC938.4BF7C%keir@xen.org>
Thread-Topic: [ANNOUNCE] Xen 4.2 released!
Thread-Index: Ac2UyFTClqs3XI5IGUe8pAGekpsn7A==
Mime-version: 1.0
Subject: [Xen-devel] [ANNOUNCE] Xen 4.2 released!
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

The Xen team is pleased to announce the release of Xen 4.2.

The result of *18 months* of development, new features include:
 * Paging/sharing improvements for high-density VM environments (eg. VDI)
 * Enhancements to PV-HVM guest performance
 * Improved memaccess (guest introspection) support
 * EFI boot support, replacing the legacy BIOS boot environment
 * Improved RAS support
 * XL as the default toolstack; XEND officially deprecated
 * Upstream QEMU support, with its up-to-date feature list

Detailed release notes, including a more extensive feature list:
  http://wiki.xen.org/wiki/Xen_4.2_Release_Notes

To download tarballs:
  http://xen.org/download/index_4.2.0.html
Or the Mercurial source repository (tag 'RELEASE-4.2.0'):
  http://xenbits.xen.org/hg/staging/xen-4.2-testing.hg

And the announcement on the Xen blog:
  http://blog.xen.org/index.php/2012/09/17/xen-4-2-0-released/

Thanks to the many people who have contributed to this release!

 Regards,
 The Xen Team



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 17 11:40:59 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 11:40:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDZgj-0005yw-De; Mon, 17 Sep 2012 11:40:29 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1TDZgh-0005yh-Lh
	for xen-devel@lists.xen.org; Mon, 17 Sep 2012 11:40:27 +0000
Received: from [85.158.138.51:60486] by server-3.bemta-3.messagelabs.com id
	8F/68-21322-A2C07505; Mon, 17 Sep 2012 11:40:26 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1347882024!30843415!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDk2NDU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22572 invoked from network); 17 Sep 2012 11:40:24 -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;
	17 Sep 2012 11:40:24 -0000
X-IronPort-AV: E=Sophos;i="4.80,435,1344211200"; d="scan'208";a="14578180"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Sep 2012 11:40: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.279.1; Mon, 17 Sep 2012 12:40:24 +0100
Date: Mon, 17 Sep 2012 12:39:39 +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: <1347293560.5305.115.camel@zakaz.uk.xensource.com>
Message-ID: <alpine.DEB.2.02.1209171229360.29232@kaball.uk.xensource.com>
References: <1346678886.32462.9.camel@zakaz.uk.xensource.com>
	<5048B746.4070306@citrix.com>
	<1347293560.5305.115.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 <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 0/16] arm: support for initial modules (e.g.
 dom0) and DTB supplied in RAM
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 10 Sep 2012, Ian Campbell wrote:
> On Thu, 2012-09-06 at 15:46 +0100, David Vrabel wrote:
> > On 03/09/12 14:28, Ian Campbell wrote:
> > > The following series implements support for initial images and DTB in
> > > RAM, as opposed to in flash (dom0 kernel) or compiled into the
> > > hypervisor (DTB). It arranges to not clobber these with either the h/v
> > > text on relocation or with the heaps and frees them as appropriate.
> > > 
> > > Most of this is independent of the specific bootloader protocol which is
> > > used to tell Xen where these modules actually are, but I have included a
> > > simple PoC bootloader protocol based around device tree which is similar
> > > to the protocol used by Linux to find its initrd
> > > (where /chosen/linux,initrd-{start,end} indicate the physical address).
> > > 
> > > In the PoC the modules are listed in the chosen node starting
> > > with /chosen/nr-modules which contains the count and then /chosen/module
> > > %d-{start,end} which gives the physical address of the module
> > > and /chosen/module%d-args which give its command line.
> > 
> > Until there is an agreement on this protocol I would prepend a "xen,"
> > prefix to the node names (xen,nr-modules etc.).
> 
> OK.
> 
> > bootargs instead of args would be more consistent perhaps. So,
> > module1-args becomes xen,module1-bootargs.
> > 
> > The proposed protocol is functional and useful using nodes for each
> > module seems to be more device-tree-ish. I think in the longer term,
> > perhaps something like the following would be better?
> 
> I rather suspect I'm going to end up porting multiboot to ARM. But you
> are right that this looks like a better DTish way than mine.

I think that the grub folks have already extended the original spec to
make it easier to port to other archs.
Give a look at include/multiboot2.h, it seems to support mips as well as
x86.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 17 11:40:59 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 11:40:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDZgj-0005yw-De; Mon, 17 Sep 2012 11:40:29 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1TDZgh-0005yh-Lh
	for xen-devel@lists.xen.org; Mon, 17 Sep 2012 11:40:27 +0000
Received: from [85.158.138.51:60486] by server-3.bemta-3.messagelabs.com id
	8F/68-21322-A2C07505; Mon, 17 Sep 2012 11:40:26 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1347882024!30843415!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDk2NDU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22572 invoked from network); 17 Sep 2012 11:40:24 -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;
	17 Sep 2012 11:40:24 -0000
X-IronPort-AV: E=Sophos;i="4.80,435,1344211200"; d="scan'208";a="14578180"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Sep 2012 11:40: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.279.1; Mon, 17 Sep 2012 12:40:24 +0100
Date: Mon, 17 Sep 2012 12:39:39 +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: <1347293560.5305.115.camel@zakaz.uk.xensource.com>
Message-ID: <alpine.DEB.2.02.1209171229360.29232@kaball.uk.xensource.com>
References: <1346678886.32462.9.camel@zakaz.uk.xensource.com>
	<5048B746.4070306@citrix.com>
	<1347293560.5305.115.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 <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 0/16] arm: support for initial modules (e.g.
 dom0) and DTB supplied in RAM
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 10 Sep 2012, Ian Campbell wrote:
> On Thu, 2012-09-06 at 15:46 +0100, David Vrabel wrote:
> > On 03/09/12 14:28, Ian Campbell wrote:
> > > The following series implements support for initial images and DTB in
> > > RAM, as opposed to in flash (dom0 kernel) or compiled into the
> > > hypervisor (DTB). It arranges to not clobber these with either the h/v
> > > text on relocation or with the heaps and frees them as appropriate.
> > > 
> > > Most of this is independent of the specific bootloader protocol which is
> > > used to tell Xen where these modules actually are, but I have included a
> > > simple PoC bootloader protocol based around device tree which is similar
> > > to the protocol used by Linux to find its initrd
> > > (where /chosen/linux,initrd-{start,end} indicate the physical address).
> > > 
> > > In the PoC the modules are listed in the chosen node starting
> > > with /chosen/nr-modules which contains the count and then /chosen/module
> > > %d-{start,end} which gives the physical address of the module
> > > and /chosen/module%d-args which give its command line.
> > 
> > Until there is an agreement on this protocol I would prepend a "xen,"
> > prefix to the node names (xen,nr-modules etc.).
> 
> OK.
> 
> > bootargs instead of args would be more consistent perhaps. So,
> > module1-args becomes xen,module1-bootargs.
> > 
> > The proposed protocol is functional and useful using nodes for each
> > module seems to be more device-tree-ish. I think in the longer term,
> > perhaps something like the following would be better?
> 
> I rather suspect I'm going to end up porting multiboot to ARM. But you
> are right that this looks like a better DTish way than mine.

I think that the grub folks have already extended the original spec to
make it easier to port to other archs.
Give a look at include/multiboot2.h, it seems to support mips as well as
x86.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 17 12:32:38 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 12: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 1TDaUi-0006qe-TU; Mon, 17 Sep 2012 12:32:08 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <pasik@iki.fi>) id 1TDaUi-0006qZ-4J
	for xen-devel@lists.xen.org; Mon, 17 Sep 2012 12:32:08 +0000
Received: from [85.158.139.83:5785] by server-10.bemta-5.messagelabs.com id
	25/8A-10969-74817505; Mon, 17 Sep 2012 12:32:07 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-3.tower-182.messagelabs.com!1347885126!30840439!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA1MDQ5ODc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3435 invoked from network); 17 Sep 2012 12:32:07 -0000
Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25)
	by server-3.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 17 Sep 2012 12:32:07 -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 44C431A2C;
	Mon, 17 Sep 2012 15:32:06 +0300 (EEST)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id 19CBB2005D; Mon, 17 Sep 2012 15:32:06 +0300 (EEST)
Date: Mon, 17 Sep 2012 15:32:06 +0300
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: Robin Axelsson <gu99roax@student.chalmers.se>
Message-ID: <20120917123205.GJ8912@reaktio.net>
References: <20120917113833.GH8912@reaktio.net>
	<50570EA7.8060509@student.chalmers.se>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <50570EA7.8060509@student.chalmers.se>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: xen@lists.fedoraproject.org, xen-devel@lists.xen.org
Subject: [Xen-devel] Xen PCI passthru supported reset methods (d3d0, FLR,
 bus reset, link reset)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Sep 17, 2012 at 01:51:03PM +0200, Robin Axelsson wrote:
> 
> There is one thing I wonder though when it comes to PCI passthrough:
> 
> Can Xen reset hardware through the d3d0 in the ACPI interface and/or
> through a 'bus reset' or a 'link reset'? Or can it reset hardware
> that is marked for passthrough only through FLR?
> 
> For details see e.g.
> http://www.vmware.com/files/pdf/techpaper/vsp_4_vmdirectpath_host.pdf
>

I added xen-devel to the CC-list.
Hopefully someone there can reply this question.

-- Pasi
 
> Regards
> 
> Robin.
> 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 17 12:32:38 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 12: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 1TDaUi-0006qe-TU; Mon, 17 Sep 2012 12:32:08 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <pasik@iki.fi>) id 1TDaUi-0006qZ-4J
	for xen-devel@lists.xen.org; Mon, 17 Sep 2012 12:32:08 +0000
Received: from [85.158.139.83:5785] by server-10.bemta-5.messagelabs.com id
	25/8A-10969-74817505; Mon, 17 Sep 2012 12:32:07 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-3.tower-182.messagelabs.com!1347885126!30840439!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA1MDQ5ODc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3435 invoked from network); 17 Sep 2012 12:32:07 -0000
Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25)
	by server-3.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 17 Sep 2012 12:32:07 -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 44C431A2C;
	Mon, 17 Sep 2012 15:32:06 +0300 (EEST)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id 19CBB2005D; Mon, 17 Sep 2012 15:32:06 +0300 (EEST)
Date: Mon, 17 Sep 2012 15:32:06 +0300
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: Robin Axelsson <gu99roax@student.chalmers.se>
Message-ID: <20120917123205.GJ8912@reaktio.net>
References: <20120917113833.GH8912@reaktio.net>
	<50570EA7.8060509@student.chalmers.se>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <50570EA7.8060509@student.chalmers.se>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: xen@lists.fedoraproject.org, xen-devel@lists.xen.org
Subject: [Xen-devel] Xen PCI passthru supported reset methods (d3d0, FLR,
 bus reset, link reset)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Sep 17, 2012 at 01:51:03PM +0200, Robin Axelsson wrote:
> 
> There is one thing I wonder though when it comes to PCI passthrough:
> 
> Can Xen reset hardware through the d3d0 in the ACPI interface and/or
> through a 'bus reset' or a 'link reset'? Or can it reset hardware
> that is marked for passthrough only through FLR?
> 
> For details see e.g.
> http://www.vmware.com/files/pdf/techpaper/vsp_4_vmdirectpath_host.pdf
>

I added xen-devel to the CC-list.
Hopefully someone there can reply this question.

-- Pasi
 
> Regards
> 
> Robin.
> 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 17 12:43:20 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 12:43: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 1TDafD-00074Y-Ni; Mon, 17 Sep 2012 12:42: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 1TDafC-00074J-4C
	for xen-devel@lists.xen.org; Mon, 17 Sep 2012 12:42:58 +0000
Received: from [85.158.137.99:57202] by server-2.bemta-3.messagelabs.com id
	C0/41-04862-1DA17505; Mon, 17 Sep 2012 12:42:57 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-217.messagelabs.com!1347885775!17995768!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDk2NDU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27736 invoked from network); 17 Sep 2012 12:42:56 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Sep 2012 12:42:56 -0000
X-IronPort-AV: E=Sophos;i="4.80,435,1344211200"; d="scan'208";a="14580148"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Sep 2012 12:42: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.279.1;
	Mon, 17 Sep 2012 13:42:55 +0100
Message-ID: <1347885774.14977.64.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: Mon, 17 Sep 2012 13:42:54 +0100
In-Reply-To: <20120917123205.GJ8912@reaktio.net>
References: <20120917113833.GH8912@reaktio.net>
	<50570EA7.8060509@student.chalmers.se>
	<20120917123205.GJ8912@reaktio.net>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen@lists.fedoraproject.org" <xen@lists.fedoraproject.org>,
	Robin Axelsson <gu99roax@student.chalmers.se>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen PCI passthru supported reset methods (d3d0, FLR,
 bus reset, link reset)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gTW9uLCAyMDEyLTA5LTE3IGF0IDEzOjMyICswMTAwLCBQYXNpIEvDpHJra8OkaW5lbiB3cm90
ZToKPiBPbiBNb24sIFNlcCAxNywgMjAxMiBhdCAwMTo1MTowM1BNICswMjAwLCBSb2JpbiBBeGVs
c3NvbiB3cm90ZToKPiA+IAo+ID4gVGhlcmUgaXMgb25lIHRoaW5nIEkgd29uZGVyIHRob3VnaCB3
aGVuIGl0IGNvbWVzIHRvIFBDSSBwYXNzdGhyb3VnaDoKPiA+IAo+ID4gQ2FuIFhlbiByZXNldCBo
YXJkd2FyZSB0aHJvdWdoIHRoZSBkM2QwIGluIHRoZSBBQ1BJIGludGVyZmFjZSBhbmQvb3IKPiA+
IHRocm91Z2ggYSAnYnVzIHJlc2V0JyBvciBhICdsaW5rIHJlc2V0Jz8gT3IgY2FuIGl0IHJlc2V0
IGhhcmR3YXJlCj4gPiB0aGF0IGlzIG1hcmtlZCBmb3IgcGFzc3Rocm91Z2ggb25seSB0aHJvdWdo
IEZMUj8KPiA+IAo+ID4gRm9yIGRldGFpbHMgc2VlIGUuZy4KPiA+IGh0dHA6Ly93d3cudm13YXJl
LmNvbS9maWxlcy9wZGYvdGVjaHBhcGVyL3ZzcF80X3ZtZGlyZWN0cGF0aF9ob3N0LnBkZgo+ID4K
PiAKPiBJIGFkZGVkIHhlbi1kZXZlbCB0byB0aGUgQ0MtbGlzdC4KPiBIb3BlZnVsbHkgc29tZW9u
ZSB0aGVyZSBjYW4gcmVwbHkgdGhpcyBxdWVzdGlvbi4KCldpdGggYSBwdm9wcyBkb20wIFhlbiBy
ZXNldHMgZGV2aWNlcyBieSB3cml0aW5nIHRvIGl0cyAicmVzZXQiIG5vZGUgaW4Kc3lzZnMgc28g
aXQgd2lsbCByZXNldCB0aGUgZGV2aWNlIHVzaW5nIHdoYXRldmVyIG1ldGhvZCB0aGUgZG9tMCBr
ZXJuZWwKc3VwcG9ydHMgZm9yIHRoYXQgZGV2aWNlLgoKVGhlIHZlcnNpb24gb2YgTGludXggSSBo
YXZlIHRvIGhhbmQgaGFzLCBpbiBfX3BjaV9kZXZfcmVzZXQsIGNhbGxzIHRvCnRoZSBmb2xsb3dp
bmcgaW4gdGhpcyBvcmRlciBhbmQgc3RvcHMgYWZ0ZXIgdGhlIGZpcnN0IG9uZSB3aGljaApzdWNj
ZWVkczoKICAgICAgKiBwY2lfZGV2X3NwZWNpZmljX3Jlc2V0IChBS0EgcGVyIGRldmljZSBxdWly
a3MpCiAgICAgICogcGNpZV9mbHIKICAgICAgKiBwY2lfYWZfZmxyCiAgICAgICogcGNpX3BtX3Jl
c2V0CiAgICAgICogcGNpX3BhcmVudF9idXNfcmVzZXQKClNlZSBkcml2ZXJzL3BjaS9wY2kuYyBp
biB0aGUga2VybmVsIGZvciBtb3JlIGluZm8uCgpJSVJDIGNsYXNzaWMgWGVuIGtlcm5lbHMgaGFk
IHNpbWlsYXIgY29kZSBpbiBwY2liYWNrLCBhbHRob3VnaCBJIGRvbid0Cmtub3cgd2hpY2ggc3Bl
Y2lmaWMgc2V0cyBvZiBhY3Rpb25zIG9yIGluIHdoaWNoIG9yZGVyIHRoZXkgd2VyZSB0cmllZC4K
Cklhbi4KCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpY
ZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW4ub3JnCmh0dHA6Ly9saXN0
cy54ZW4ub3JnL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xen.org Mon Sep 17 12:43:20 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 12:43: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 1TDafD-00074Y-Ni; Mon, 17 Sep 2012 12:42: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 1TDafC-00074J-4C
	for xen-devel@lists.xen.org; Mon, 17 Sep 2012 12:42:58 +0000
Received: from [85.158.137.99:57202] by server-2.bemta-3.messagelabs.com id
	C0/41-04862-1DA17505; Mon, 17 Sep 2012 12:42:57 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-217.messagelabs.com!1347885775!17995768!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDk2NDU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27736 invoked from network); 17 Sep 2012 12:42:56 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Sep 2012 12:42:56 -0000
X-IronPort-AV: E=Sophos;i="4.80,435,1344211200"; d="scan'208";a="14580148"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Sep 2012 12:42: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.279.1;
	Mon, 17 Sep 2012 13:42:55 +0100
Message-ID: <1347885774.14977.64.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: Mon, 17 Sep 2012 13:42:54 +0100
In-Reply-To: <20120917123205.GJ8912@reaktio.net>
References: <20120917113833.GH8912@reaktio.net>
	<50570EA7.8060509@student.chalmers.se>
	<20120917123205.GJ8912@reaktio.net>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen@lists.fedoraproject.org" <xen@lists.fedoraproject.org>,
	Robin Axelsson <gu99roax@student.chalmers.se>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen PCI passthru supported reset methods (d3d0, FLR,
 bus reset, link reset)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gTW9uLCAyMDEyLTA5LTE3IGF0IDEzOjMyICswMTAwLCBQYXNpIEvDpHJra8OkaW5lbiB3cm90
ZToKPiBPbiBNb24sIFNlcCAxNywgMjAxMiBhdCAwMTo1MTowM1BNICswMjAwLCBSb2JpbiBBeGVs
c3NvbiB3cm90ZToKPiA+IAo+ID4gVGhlcmUgaXMgb25lIHRoaW5nIEkgd29uZGVyIHRob3VnaCB3
aGVuIGl0IGNvbWVzIHRvIFBDSSBwYXNzdGhyb3VnaDoKPiA+IAo+ID4gQ2FuIFhlbiByZXNldCBo
YXJkd2FyZSB0aHJvdWdoIHRoZSBkM2QwIGluIHRoZSBBQ1BJIGludGVyZmFjZSBhbmQvb3IKPiA+
IHRocm91Z2ggYSAnYnVzIHJlc2V0JyBvciBhICdsaW5rIHJlc2V0Jz8gT3IgY2FuIGl0IHJlc2V0
IGhhcmR3YXJlCj4gPiB0aGF0IGlzIG1hcmtlZCBmb3IgcGFzc3Rocm91Z2ggb25seSB0aHJvdWdo
IEZMUj8KPiA+IAo+ID4gRm9yIGRldGFpbHMgc2VlIGUuZy4KPiA+IGh0dHA6Ly93d3cudm13YXJl
LmNvbS9maWxlcy9wZGYvdGVjaHBhcGVyL3ZzcF80X3ZtZGlyZWN0cGF0aF9ob3N0LnBkZgo+ID4K
PiAKPiBJIGFkZGVkIHhlbi1kZXZlbCB0byB0aGUgQ0MtbGlzdC4KPiBIb3BlZnVsbHkgc29tZW9u
ZSB0aGVyZSBjYW4gcmVwbHkgdGhpcyBxdWVzdGlvbi4KCldpdGggYSBwdm9wcyBkb20wIFhlbiBy
ZXNldHMgZGV2aWNlcyBieSB3cml0aW5nIHRvIGl0cyAicmVzZXQiIG5vZGUgaW4Kc3lzZnMgc28g
aXQgd2lsbCByZXNldCB0aGUgZGV2aWNlIHVzaW5nIHdoYXRldmVyIG1ldGhvZCB0aGUgZG9tMCBr
ZXJuZWwKc3VwcG9ydHMgZm9yIHRoYXQgZGV2aWNlLgoKVGhlIHZlcnNpb24gb2YgTGludXggSSBo
YXZlIHRvIGhhbmQgaGFzLCBpbiBfX3BjaV9kZXZfcmVzZXQsIGNhbGxzIHRvCnRoZSBmb2xsb3dp
bmcgaW4gdGhpcyBvcmRlciBhbmQgc3RvcHMgYWZ0ZXIgdGhlIGZpcnN0IG9uZSB3aGljaApzdWNj
ZWVkczoKICAgICAgKiBwY2lfZGV2X3NwZWNpZmljX3Jlc2V0IChBS0EgcGVyIGRldmljZSBxdWly
a3MpCiAgICAgICogcGNpZV9mbHIKICAgICAgKiBwY2lfYWZfZmxyCiAgICAgICogcGNpX3BtX3Jl
c2V0CiAgICAgICogcGNpX3BhcmVudF9idXNfcmVzZXQKClNlZSBkcml2ZXJzL3BjaS9wY2kuYyBp
biB0aGUga2VybmVsIGZvciBtb3JlIGluZm8uCgpJSVJDIGNsYXNzaWMgWGVuIGtlcm5lbHMgaGFk
IHNpbWlsYXIgY29kZSBpbiBwY2liYWNrLCBhbHRob3VnaCBJIGRvbid0Cmtub3cgd2hpY2ggc3Bl
Y2lmaWMgc2V0cyBvZiBhY3Rpb25zIG9yIGluIHdoaWNoIG9yZGVyIHRoZXkgd2VyZSB0cmllZC4K
Cklhbi4KCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpY
ZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW4ub3JnCmh0dHA6Ly9saXN0
cy54ZW4ub3JnL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xen.org Mon Sep 17 12:59:55 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 12:59:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDavL-0007YL-EL; Mon, 17 Sep 2012 12:59:39 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <sshtylyov@mvista.com>) id 1TDa8F-0006kI-Po
	for xen-devel@lists.xensource.com; Mon, 17 Sep 2012 12:08:55 +0000
Received: from [85.158.139.211:13875] by server-12.bemta-5.messagelabs.com id
	06/5D-19338-6D217505; Mon, 17 Sep 2012 12:08:54 +0000
X-Env-Sender: sshtylyov@mvista.com
X-Msg-Ref: server-5.tower-206.messagelabs.com!1347883733!18815123!1
X-Originating-IP: [209.85.217.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28277 invoked from network); 17 Sep 2012 12:08:54 -0000
Received: from mail-lb0-f171.google.com (HELO mail-lb0-f171.google.com)
	(209.85.217.171)
	by server-5.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Sep 2012 12:08:54 -0000
Received: by lbol12 with SMTP id l12so4923877lbo.30
	for <xen-devel@lists.xensource.com>;
	Mon, 17 Sep 2012 05:08:53 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=message-id:date:from:user-agent:mime-version:to:cc:subject
	:references:in-reply-to:content-type:content-transfer-encoding
	:x-gm-message-state;
	bh=7vqWWsrvDGkliKl6lEIGVWiaJ/KTuxV26TGqMhSkuOU=;
	b=Mqt8+/M/esZUzx+Ypj2yOhvkcwb2Nars48M11BeHW8v404BwTSDD5NKPtXXcqJr1uq
	HChvvTfQNJc5zz4kiVPdqXPNdTUzRzMHGXxu6hADAISAPOyP38zdgwIdN7rZTyOFW61D
	iOQtKumPDymNkbW//6B3QJxykS/rSBSxxr0rULyeAUyn2lT2HhUirjnK6l9Lv/dz0tLo
	KvRKtMrv2kh9qOx3/y/EmjRbETTrLNO51a2vI4nx3mhuIYq8RTJfTl5gkV1tSwpl+v3C
	HWAbeB5vMptCOe0Nho6KnA5veq1MlJjTDzxOPM2Ig5va1zUZEwu0ITmADcDxDruiiY+Q
	7L7w==
Received: by 10.112.26.197 with SMTP id n5mr3905384lbg.18.1347883733364;
	Mon, 17 Sep 2012 05:08:53 -0700 (PDT)
Received: from [192.168.2.2] (ppp91-79-92-86.pppoe.mtu-net.ru. [91.79.92.86])
	by mx.google.com with ESMTPS id
	hj19sm2885935lab.13.2012.09.17.05.08.51
	(version=TLSv1/SSLv3 cipher=OTHER);
	Mon, 17 Sep 2012 05:08:52 -0700 (PDT)
Message-ID: <50571289.3040509@mvista.com>
Date: Mon, 17 Sep 2012 16:07:37 +0400
From: Sergei Shtylyov <sshtylyov@mvista.com>
User-Agent: Mozilla/5.0 (Windows NT 5.1;
	rv:15.0) Gecko/20120907 Thunderbird/15.0.1
MIME-Version: 1.0
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.02.1209141145150.29232@kaball.uk.xensource.com>
	<1347621207-11294-12-git-send-email-stefano.stabellini@eu.citrix.com>
	<505374E2.5080308@mvista.com>
	<alpine.DEB.2.02.1209171155010.29232@kaball.uk.xensource.com>
In-Reply-To: <alpine.DEB.2.02.1209171155010.29232@kaball.uk.xensource.com>
X-Gm-Message-State: ALoCoQlpITHsU59rqtQwj3BgriB+r0Biy6aKKePLdh4UfmRdztvCqujFCCCS6y42qtdN1C2lLCns
X-Mailman-Approved-At: Mon, 17 Sep 2012 12:59:38 +0000
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linaro-dev@lists.linaro.org" <linaro-dev@lists.linaro.org>,
	Ian Campbell <Ian.Campbell@citrix.com>, "arnd@arndb.de" <arnd@arndb.de>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
	"catalin.marinas@arm.com" <catalin.marinas@arm.com>,
	"Tim \(Xen.org\)" <tim@xen.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux@arm.linux.org.uk" <linux@arm.linux.org.uk>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Xen-devel] [PATCH v4 12/24] xen/arm: introduce CONFIG_XEN on
	ARM
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
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.

On 17-09-2012 14:57, Stefano Stabellini wrote:

>>> Changes in v2:

>>> - mark Xen guest support on ARM as EXPERIMENTAL.

>>> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
>>> Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
>>> ---
>>>   arch/arm/Kconfig |   10 ++++++++++
>>>   1 files changed, 10 insertions(+), 0 deletions(-)

>>> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
>>> index 2f88d8d..e92518d 100644
>>> --- a/arch/arm/Kconfig
>>> +++ b/arch/arm/Kconfig
>>> @@ -1897,6 +1897,16 @@ config DEPRECATED_PARAM_STRUCT
>>>   	  This was deprecated in 2001 and announced to live on for 5 years.
>>>   	  Some old boot loaders still use this way.
>>>
>>> +config XEN_DOM0
>>> +	def_bool y
>>> +
>>> +config XEN
>>> +	bool "Xen guest support on ARM (EXPERIMENTAL)"
>>> +	depends on EXPERIMENTAL && ARM && OF
>>> +	select XEN_DOM0

>>     What's the point of selecting it if it's always "y"?

> That's because on X86 is not always "y": there are things under
> drivers/xen that compile on both platforms and depend on XEN_DOM0.

    But we're not on x86. On ARM this select is pointless.

WBR, Sergei


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 17 12:59:55 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 12:59:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDavL-0007YL-EL; Mon, 17 Sep 2012 12:59:39 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <sshtylyov@mvista.com>) id 1TDa8F-0006kI-Po
	for xen-devel@lists.xensource.com; Mon, 17 Sep 2012 12:08:55 +0000
Received: from [85.158.139.211:13875] by server-12.bemta-5.messagelabs.com id
	06/5D-19338-6D217505; Mon, 17 Sep 2012 12:08:54 +0000
X-Env-Sender: sshtylyov@mvista.com
X-Msg-Ref: server-5.tower-206.messagelabs.com!1347883733!18815123!1
X-Originating-IP: [209.85.217.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28277 invoked from network); 17 Sep 2012 12:08:54 -0000
Received: from mail-lb0-f171.google.com (HELO mail-lb0-f171.google.com)
	(209.85.217.171)
	by server-5.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Sep 2012 12:08:54 -0000
Received: by lbol12 with SMTP id l12so4923877lbo.30
	for <xen-devel@lists.xensource.com>;
	Mon, 17 Sep 2012 05:08:53 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=message-id:date:from:user-agent:mime-version:to:cc:subject
	:references:in-reply-to:content-type:content-transfer-encoding
	:x-gm-message-state;
	bh=7vqWWsrvDGkliKl6lEIGVWiaJ/KTuxV26TGqMhSkuOU=;
	b=Mqt8+/M/esZUzx+Ypj2yOhvkcwb2Nars48M11BeHW8v404BwTSDD5NKPtXXcqJr1uq
	HChvvTfQNJc5zz4kiVPdqXPNdTUzRzMHGXxu6hADAISAPOyP38zdgwIdN7rZTyOFW61D
	iOQtKumPDymNkbW//6B3QJxykS/rSBSxxr0rULyeAUyn2lT2HhUirjnK6l9Lv/dz0tLo
	KvRKtMrv2kh9qOx3/y/EmjRbETTrLNO51a2vI4nx3mhuIYq8RTJfTl5gkV1tSwpl+v3C
	HWAbeB5vMptCOe0Nho6KnA5veq1MlJjTDzxOPM2Ig5va1zUZEwu0ITmADcDxDruiiY+Q
	7L7w==
Received: by 10.112.26.197 with SMTP id n5mr3905384lbg.18.1347883733364;
	Mon, 17 Sep 2012 05:08:53 -0700 (PDT)
Received: from [192.168.2.2] (ppp91-79-92-86.pppoe.mtu-net.ru. [91.79.92.86])
	by mx.google.com with ESMTPS id
	hj19sm2885935lab.13.2012.09.17.05.08.51
	(version=TLSv1/SSLv3 cipher=OTHER);
	Mon, 17 Sep 2012 05:08:52 -0700 (PDT)
Message-ID: <50571289.3040509@mvista.com>
Date: Mon, 17 Sep 2012 16:07:37 +0400
From: Sergei Shtylyov <sshtylyov@mvista.com>
User-Agent: Mozilla/5.0 (Windows NT 5.1;
	rv:15.0) Gecko/20120907 Thunderbird/15.0.1
MIME-Version: 1.0
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.02.1209141145150.29232@kaball.uk.xensource.com>
	<1347621207-11294-12-git-send-email-stefano.stabellini@eu.citrix.com>
	<505374E2.5080308@mvista.com>
	<alpine.DEB.2.02.1209171155010.29232@kaball.uk.xensource.com>
In-Reply-To: <alpine.DEB.2.02.1209171155010.29232@kaball.uk.xensource.com>
X-Gm-Message-State: ALoCoQlpITHsU59rqtQwj3BgriB+r0Biy6aKKePLdh4UfmRdztvCqujFCCCS6y42qtdN1C2lLCns
X-Mailman-Approved-At: Mon, 17 Sep 2012 12:59:38 +0000
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linaro-dev@lists.linaro.org" <linaro-dev@lists.linaro.org>,
	Ian Campbell <Ian.Campbell@citrix.com>, "arnd@arndb.de" <arnd@arndb.de>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
	"catalin.marinas@arm.com" <catalin.marinas@arm.com>,
	"Tim \(Xen.org\)" <tim@xen.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux@arm.linux.org.uk" <linux@arm.linux.org.uk>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Xen-devel] [PATCH v4 12/24] xen/arm: introduce CONFIG_XEN on
	ARM
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
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.

On 17-09-2012 14:57, Stefano Stabellini wrote:

>>> Changes in v2:

>>> - mark Xen guest support on ARM as EXPERIMENTAL.

>>> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
>>> Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
>>> ---
>>>   arch/arm/Kconfig |   10 ++++++++++
>>>   1 files changed, 10 insertions(+), 0 deletions(-)

>>> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
>>> index 2f88d8d..e92518d 100644
>>> --- a/arch/arm/Kconfig
>>> +++ b/arch/arm/Kconfig
>>> @@ -1897,6 +1897,16 @@ config DEPRECATED_PARAM_STRUCT
>>>   	  This was deprecated in 2001 and announced to live on for 5 years.
>>>   	  Some old boot loaders still use this way.
>>>
>>> +config XEN_DOM0
>>> +	def_bool y
>>> +
>>> +config XEN
>>> +	bool "Xen guest support on ARM (EXPERIMENTAL)"
>>> +	depends on EXPERIMENTAL && ARM && OF
>>> +	select XEN_DOM0

>>     What's the point of selecting it if it's always "y"?

> That's because on X86 is not always "y": there are things under
> drivers/xen that compile on both platforms and depend on XEN_DOM0.

    But we're not on x86. On ARM this select is pointless.

WBR, Sergei


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 17 13:29:17 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 13:29:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDbNa-0007ou-VA; Mon, 17 Sep 2012 13:28:50 +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 1TDbNY-0007op-EO
	for xen-devel@lists.xensource.com; Mon, 17 Sep 2012 13:28:48 +0000
Received: from [85.158.137.99:22963] by server-10.bemta-3.messagelabs.com id
	12/38-10411-F8527505; Mon, 17 Sep 2012 13:28:47 +0000
X-Env-Sender: fantonifabio@tiscali.it
X-Msg-Ref: server-14.tower-217.messagelabs.com!1347888526!17980780!1
X-Originating-IP: [94.23.245.208]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG,
	ML_RADAR_SPEW_LINKS_14,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31607 invoked from network); 17 Sep 2012 13:28:46 -0000
Received: from lnx3.fantu.it (HELO lnx3.fantu.it) (94.23.245.208)
	by server-14.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 17 Sep 2012 13:28:46 -0000
Received: from localhost (localhost.localdomain [127.0.0.1])
	by lnx3.fantu.it (Postfix) with ESMTP id 06B66401327;
	Mon, 17 Sep 2012 15:28:46 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at lnx3.fantu.it
Received: from lnx3.fantu.it ([127.0.0.1])
	by localhost (lnx3.fantu.it [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id zeyv0Xy0f4Ey; Mon, 17 Sep 2012 15:28:45 +0200 (CEST)
Received: from [192.168.178.50]
	(host106-81-dynamic.7-79-r.retail.telecomitalia.it [79.7.81.106])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: prova@fantu.it)
	by lnx3.fantu.it (Postfix) with ESMTPSA id 92ABA400599;
	Mon, 17 Sep 2012 15:28:44 +0200 (CEST)
Message-ID: <5057258B.2060003@tiscali.it>
Date: Mon, 17 Sep 2012 15:28:43 +0200
From: Fabio Fantoni <fantonifabio@tiscali.it>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:15.0) Gecko/20120907 Thunderbird/15.0.1
MIME-Version: 1.0
To: fantonifabio@tiscali.it
References: <5049EC11.9080302@tiscali.it>
	<1347030955.30018.115.camel@zakaz.uk.xensource.com>
	<504DB165.6040500@tiscali.it>
	<1347269362.5305.39.camel@zakaz.uk.xensource.com>
	<504DECE7.1050404@tiscali.it>
	<1347284515.5305.85.camel@zakaz.uk.xensource.com>
	<504DF87E.6020901@tiscali.it>
	<1347287277.5305.90.camel@zakaz.uk.xensource.com>
	<504EEEBA.9070708@tiscali.it>
In-Reply-To: <504EEEBA.9070708@tiscali.it>
Cc: xen-devel <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] Test report of xen 4.2.0-rc4
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="===============1814702204596927067=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Questo è un messaggio firmato digitalmente in formato MIME.

--===============1814702204596927067==
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms080001090703050308020307"

Questo è un messaggio firmato digitalmente in formato MIME.

--------------ms080001090703050308020307
Content-Type: multipart/mixed;
 boundary="------------010803070807050204010806"

This is a multi-part message in MIME format.
--------------010803070807050204010806
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable

Il 11/09/2012 09:56, Fabio Fantoni ha scritto:
> Il 10/09/2012 16:27, Ian Campbell ha scritto:
>> On Mon, 2012-09-10 at 15:26 +0100, Fabio Fantoni wrote:
>>> gdb --args xl -vvv cd-eject W7 hdb
>>> GNU gdb (GDB) 7.4.1-debian
>>> Copyright (C) 2012 Free Software Foundation, Inc.
>>> License GPLv3+: GNU GPL version 3 or later
>>> <http://gnu.org/licenses/gpl.html>
>>> This is free software: you are free to change and redistribute it.
>>> There is NO WARRANTY, to the extent permitted by law.  Type "show=20
>>> copying"
>>> and "show warranty" for details.
>>> This GDB was configured as "x86_64-linux-gnu".
>>> For bug reporting instructions, please see:
>>> <http://www.gnu.org/software/gdb/bugs/>...
>>> Reading symbols from /usr/sbin/xl...done.
>>> (gdb) run
>>> Starting program: /usr/sbin/xl -vvv cd-eject W7 hdb
>>> [Thread debugging using libthread_db enabled]
>>> Using host libthread_db library=20
>>> "/lib/x86_64-linux-gnu/libthread_db.so.1".
>>> libxl: debug: libxl.c:2143:libxl_cdrom_insert: ao 0x623980: create:
>>> how=3D(nil) callback=3D(nil) poller=3D0x6239e0
>>> libxl: debug: libxl_device.c:229:libxl__device_disk_set_backend: Disk=

>>> vdev=3Dhdb spec.backend=3Dunknown
>>> libxl: debug: libxl_device.c:175:disk_try_backend: Disk vdev=3Dhdb,
>>> backend phy unsuitable as phys path not a block device
>>> libxl: debug: libxl_device.c:210:disk_try_backend: Disk vdev=3Dhdb,
>>> backend tap unsuitable due to format empty
>>> libxl: debug: libxl_device.c:265:libxl__device_disk_set_backend: Disk=

>>> vdev=3Dhdb, using backend qdisk
>>> libxl: debug: libxl_event.c:1497:libxl__ao_complete: ao 0x623980:
>>> complete, rc=3D0
>>> libxl: debug: libxl.c:2236:libxl_cdrom_insert: ao 0x623980: inprogres=
s:
>>> poller=3D0x6239e0, flags=3Dic
>>> libxl: debug: libxl_event.c:1469:libxl__ao__destroy: ao 0x623980:=20
>>> destroy
>>> xc: debug: hypercall buffer: total allocations:4 total releases:4
>>> xc: debug: hypercall buffer: current allocations:0 maximum=20
>>> allocations:2
>>> xc: debug: hypercall buffer: cache current size:2
>>> xc: debug: hypercall buffer: cache hits:1 misses:2 toobig:1
>>> [Inferior 1 (process 5581) exited normally]
>>> (gdb) bt
>>> No stack.
>> That's because it seems to be working for you now... There is no crash=

>> here.
>>
>> Ian.
>>
>>
>>
>> -----
>> Nessun virus nel messaggio.
>> Controllato da AVG - www.avg.com
>> Versione: 2012.0.2197 / Database dei virus: 2437/5259 -  Data di=20
>> rilascio: 09/09/2012
>>
>>
> After issuing the command:
> xl -vvv cd-eject PRECISEHVM hdb
> libxl: debug: libxl.c:2143:libxl_cdrom_insert: ao 0x1812980: create:=20
> how=3D(nil) callback=3D(nil) poller=3D0x18129e0
> libxl: debug: libxl_device.c:229:libxl__device_disk_set_backend: Disk=20
> vdev=3Dhdb spec.backend=3Dunknown
> libxl: debug: libxl_device.c:175:disk_try_backend: Disk vdev=3Dhdb,=20
> backend phy unsuitable as phys path not a block device
> libxl: debug: libxl_device.c:210:disk_try_backend: Disk vdev=3Dhdb,=20
> backend tap unsuitable due to format empty
> libxl: debug: libxl_device.c:265:libxl__device_disk_set_backend: Disk=20
> vdev=3Dhdb, using backend qdisk
> libxl: debug: libxl_event.c:1497:libxl__ao_complete: ao 0x1812980:=20
> complete, rc=3D0
> libxl: debug: libxl.c:2236:libxl_cdrom_insert: ao 0x1812980:=20
> inprogress: poller=3D0x18129e0, flags=3Dic
> libxl: debug: libxl_event.c:1469:libxl__ao__destroy: ao 0x1812980:=20
> destroy
> xc: debug: hypercall buffer: total allocations:4 total releases:4
> xc: debug: hypercall buffer: current allocations:0 maximum allocations:=
2
> xc: debug: hypercall buffer: cache current size:2
> xc: debug: hypercall buffer: cache hits:1 misses:2 toobig:1
>
> The cdrom remain in domU and working
>
> I also tried with insert:
> root@vfarm:~# xl -vvv cd-insert PRECISEHVM hdb=20
> raw:/mnt/vm/iso/Clonezilla.iso
> libxl: debug: libxl.c:2143:libxl_cdrom_insert: ao 0xedd980: create:=20
> how=3D(nil) callback=3D(nil) poller=3D0xedd9e0
> Errore di segmentazione
>
> But give segmentation error and nothing change on domU (remain the old =

> cdrom working)
>
> Can you tell me datails about your dom0 configuration please?
>
I have redone a clean install of Wheezy 64 bit with xen 4.2.0-rc5.
The problem about network not working on restore is now solved.
Cdrom hotplug is not solved, it has the same problem, retried with=20
Windows 7 and Precise HVM.
I'm also attaching logs of Precise HVM with cd-insert and cd-eject,=20
qemu-dm...log seems to contain error logs that may be useful.

--------------010803070807050204010806
Content-Type: text/plain; charset=windows-1252;
 name="qemu-dm-PRECISEHVM.log"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
 filename="qemu-dm-PRECISEHVM.log"

ZG9taWQ6IDYKLXZpZGVvcmFtIG9wdGlvbiBkb2VzIG5vdCB3b3JrIHdpdGggY2lycnVzIHZn
YSBkZXZpY2UgbW9kZWwuIFZpZGVvcmFtIHNldCB0byA0TS4KVXNpbmcgZmlsZSAvZGV2L3hl
bi9ibGt0YXAtMi90YXBkZXYwIGluIHJlYWQtd3JpdGUgbW9kZQpVc2luZyBmaWxlIC9kZXYv
eGVuL2Jsa3RhcC0yL3RhcGRldjEgaW4gcmVhZC1vbmx5IG1vZGUKV2F0Y2hpbmcgL2xvY2Fs
L2RvbWFpbi8wL2RldmljZS1tb2RlbC82L2xvZ2RpcnR5L2NtZApXYXRjaGluZyAvbG9jYWwv
ZG9tYWluLzAvZGV2aWNlLW1vZGVsLzYvY29tbWFuZApXYXRjaGluZyAvbG9jYWwvZG9tYWlu
LzYvY3B1CnFlbXVfbWFwX2NhY2hlX2luaXQgbnJfYnVja2V0cyA9IDEwMDAwIHNpemUgNDE5
NDMwNApzaGFyZWQgcGFnZSBhdCBwZm4gZmVmZmQKYnVmZmVyZWQgaW8gcGFnZSBhdCBwZm4g
ZmVmZmIKR3Vlc3QgdXVpZCA9IDQ0ZGRlMzA1LWUxMzktNGViNi1iYWM2LWU0NTI2YjNmMDI3
YQpwb3B1bGF0aW5nIHZpZGVvIFJBTSBhdCBmZjAwMDAwMAptYXBwaW5nIHZpZGVvIFJBTSBm
cm9tIGZmMDAwMDAwClJlZ2lzdGVyIHhlbiBwbGF0Zm9ybS4KRG9uZSByZWdpc3RlciBwbGF0
Zm9ybS4KcGxhdGZvcm1fZml4ZWRfaW9wb3J0OiBjaGFuZ2VkIHJvL3J3IHN0YXRlIG9mIFJP
TSBtZW1vcnkgYXJlYS4gbm93IGlzIHJ3IHN0YXRlLgp4c19yZWFkKC9sb2NhbC9kb21haW4v
MC9kZXZpY2UtbW9kZWwvNi94ZW5fZXh0ZW5kZWRfcG93ZXJfbWdtdCk6IHJlYWQgZXJyb3IK
eHNfcmVhZCgpOiB2bmNwYXNzd2QgZ2V0IGVycm9yLiAvdm0vNDRkZGUzMDUtZTEzOS00ZWI2
LWJhYzYtZTQ1MjZiM2YwMjdhL3ZuY3Bhc3N3ZC4KbWVkaXVtIGNoYW5nZSB3YXRjaCBvbiBg
aGRiJyAoaW5kZXg6IDEpOiAvZGV2L3hlbi9ibGt0YXAtMi90YXBkZXYxCkkvTyByZXF1ZXN0
IG5vdCByZWFkeTogMCwgcHRyOiAwLCBwb3J0OiAwLCBkYXRhOiAwLCBjb3VudDogMCwgc2l6
ZTogMApMb2ctZGlydHk6IG5vIGNvbW1hbmQgeWV0LgpJL08gcmVxdWVzdCBub3QgcmVhZHk6
IDAsIHB0cjogMCwgcG9ydDogMCwgZGF0YTogMCwgY291bnQ6IDAsIHNpemU6IDAKdmNwdS1z
ZXQ6IHdhdGNoIG5vZGUgZXJyb3IuCnhzX3JlYWQoL2xvY2FsL2RvbWFpbi82L2xvZy10aHJv
dHRsaW5nKTogcmVhZCBlcnJvcgpxZW11OiBpZ25vcmluZyBub3QtdW5kZXJzdG9vZCBkcml2
ZSBgL2xvY2FsL2RvbWFpbi82L2xvZy10aHJvdHRsaW5nJwptZWRpdW0gY2hhbmdlIHdhdGNo
IG9uIGAvbG9jYWwvZG9tYWluLzYvbG9nLXRocm90dGxpbmcnIC0gdW5rbm93biBkZXZpY2Us
IGlnbm9yZWQKY2lycnVzIHZnYSBtYXAgY2hhbmdlIHdoaWxlIG9uIGxmYiBtb2RlCm1hcHBp
bmcgdnJhbSB0byBmMDAwMDAwMCAtIGYwNDAwMDAwCnBsYXRmb3JtX2ZpeGVkX2lvcG9ydDog
Y2hhbmdlZCByby9ydyBzdGF0ZSBvZiBST00gbWVtb3J5IGFyZWEuIG5vdyBpcyBydyBzdGF0
ZS4KcGxhdGZvcm1fZml4ZWRfaW9wb3J0OiBjaGFuZ2VkIHJvL3J3IHN0YXRlIG9mIFJPTSBt
ZW1vcnkgYXJlYS4gbm93IGlzIHJvIHN0YXRlLgpVbmtub3duIFBWIHByb2R1Y3QgMyBsb2Fk
ZWQgaW4gZ3Vlc3QKUFYgZHJpdmVyIGJ1aWxkIDEKcmVnaW9uIHR5cGUgMSBhdCBbYzEwMCxj
MjAwKS4KcmVnaW9uIHR5cGUgMCBhdCBbZjMwMDEwMDAsZjMwMDExMDApLgpzcXVhc2ggaW9t
ZW0gW2YzMDAxMDAwLCBmMzAwMTEwMCkuCnhjOiBlcnJvcjogbGludXhfZ250dGFiX3NldF9t
YXhfZ3JhbnRzOiBpb2N0bCBTRVRfTUFYX0dSQU5UUyBmYWlsZWQgKDIyID0gSW52YWxpZCBh
cmd1bWVudCk6IEludGVybmFsIGVycm9yCnhlbiBiZTogcWRpc2stODMyOiB4ZW4gYmU6IHFk
aXNrLTgzMjogeGNfZ250dGFiX3NldF9tYXhfZ3JhbnRzIGZhaWxlZDogSW52YWxpZCBhcmd1
bWVudAp4Y19nbnR0YWJfc2V0X21heF9ncmFudHMgZmFpbGVkOiBJbnZhbGlkIGFyZ3VtZW50
CnhlbiBiZTogcWRpc2stODMyOiB4ZW4gYmU6IHFkaXNrLTgzMjogcmVhZGluZyBiYWNrZW5k
IHN0YXRlIGZhaWxlZApyZWFkaW5nIGJhY2tlbmQgc3RhdGUgZmFpbGVkCnhlbiBiZTogcWRp
c2stODMyOiB4ZW4gYmU6IHFkaXNrLTgzMjogcmVhZGluZyBiYWNrZW5kIHN0YXRlIGZhaWxl
ZApyZWFkaW5nIGJhY2tlbmQgc3RhdGUgZmFpbGVkClRpbWUgb2Zmc2V0IHNldCAxLCBhZGRl
ZCBvZmZzZXQgMQpzaHV0ZG93biByZXF1ZXN0ZWQgaW4gY3B1X2hhbmRsZV9pb3JlcQpJc3N1
ZWQgZG9tYWluIDYgcG93ZXJvZmYK
--------------010803070807050204010806
Content-Type: text/plain; charset=windows-1252;
 name="xl-PRECISEHVM.log"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
 filename="xl-PRECISEHVM.log"

V2FpdGluZyBmb3IgZG9tYWluIFBSRUNJU0VIVk0gKGRvbWlkIDYpIHRvIGRpZSBbcGlkIDQ4
NTNdCkRvbWFpbiA2IGhhcyBzaHV0IGRvd24sIHJlYXNvbiBjb2RlIDAgMHgwCkFjdGlvbiBm
b3Igc2h1dGRvd24gcmVhc29uIGNvZGUgMCBpcyBkZXN0cm95CkRvbWFpbiA2IG5lZWRzIHRv
IGJlIGNsZWFuZWQgdXA6IGRlc3Ryb3lpbmcgdGhlIGRvbWFpbgpEb25lLiBFeGl0aW5nIG5v
dwo=
--------------010803070807050204010806--

--------------ms080001090703050308020307
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: Firma crittografica S/MIME

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINhjCC
BjQwggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT
DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp
Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3
MTAyNDIxMDI1NVoXDTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T
dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu
aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs
aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOM
KqANy9BV7V0igWdGxA8IU77L3aTxErQ+fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi
8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke/s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8M
DP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHksw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y
2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHHtOkzUreG//CsFnB9+uaYSlR65cdG
zTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB
Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd+q9rMfPIHeOsuzAfBgNV
HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH
MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3
dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu
c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v
c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0
dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93
d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqp
Jw3I07QWke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Mic
c/NXcs7kPBRdn6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9Jphw
UPTXwHovjavRnhUQHLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMc
p+reg9901zkyT3fDW/ivJVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT
+HBDYtbuvexNftwNQKD5193A7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1X
hwby6mLhkbaXslkVtwEWT3Van49rKjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvO
hNz/QplNa+VkIsrcp7+8ZhP1l1b2U6MaxIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC
0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqh
AChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H75dVCV33K6FuxZrf09yTz+Vx/PkdRUYk
XmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHSjCCBjKgAwIBAgICHmMwDQYJKoZIhvcNAQEF
BQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJT
ZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD
bGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0xMjAzMTgyMjE0MzBa
Fw0xNDAzMjAwODU3MDlaMIGMMRkwFwYDVQQNExBlQjZPRTM3UlJOUHlsNW0yMQswCQYDVQQG
EwJJVDEQMA4GA1UECBMHQmVyZ2FtbzEQMA4GA1UEBxMHUm92ZXR0YTEWMBQGA1UEAxMNRmFi
aW8gRmFudG9uaTEmMCQGCSqGSIb3DQEJARYXZmFudG9uaWZhYmlvQHRpc2NhbGkuaXQwggEi
MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC1XhckXsX23vgJq76s2f0KT8U8Msov5QgV
10eQBb2wL/TzcmqtZotI7ztKVhio3ehHg+mfu+3EqOkX9Umgut8rP0bPi7AGjkPXbOTT/cSU
Xz2Kw31VGOmiOVoUFGvpQitp3weCkhUJLBipI8EpNyBXpjtQ9yCpnIAqfuc77ybfSnCy7tTR
MBq1BUkfjH1+GL45riosuS4+F+MSUvlYzLiT4rAduAX1Y2IuORDsf9Bce8GBxa6syP9rCyzl
Vk7DIX5k8j2vlnyRATIypn5CQLQxGT6e0f6ac4gvWOHwO2QEBsmZKKs1ZidE4q/9OoNXYX6A
jnHtp1H1vcrek/vVcs19AgMBAAGjggOyMIIDrjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAd
BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFFan8cbEWWBmSTWFtLk2
YNdAcGUbMB8GA1UdIwQYMBaAFK5Vg2/sMcq59x36r2sx88gd46y7MCIGA1UdEQQbMBmBF2Zh
bnRvbmlmYWJpb0B0aXNjYWxpLml0MIICIQYDVR0gBIICGDCCAhQwggIQBgsrBgEEAYG1NwEC
AjCCAf8wLgYIKwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYw
NAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYw
gfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMC
AQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNjb3JkaW5nIHRvIHRoZSBDbGFz
cyAyIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3ks
IHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGluIGNvbXBsaWFuY2Ug
b2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMIGcBggrBgEFBQcCAjCBjzAnFiBT
dGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgECGmRMaWFiaWxpdHkgYW5kIHdh
cnJhbnRpZXMgYXJlIGxpbWl0ZWQhIFNlZSBzZWN0aW9uICJMZWdhbCBhbmQgTGltaXRhdGlv
bnMiIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3kuMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6
Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUyLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYI
KwYBBQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MyL2NsaWVudC9j
YTBCBggrBgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNz
Mi5jbGllbnQuY2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzAN
BgkqhkiG9w0BAQUFAAOCAQEAjzHNqifpDVMkH1TSPFZVIiQ4fh49/V5JMpstgqEZPDaDe5r8
h+fMBZtUa6LLMco03Z9BNEXlqlXKiFk8feVYB8obEjz7YYq1XhO9q7JUmkSs0WGIH4xU0XB1
kPC8T8H+5E//84poYSFHE4pA+Ff68UANP2/EuFJWMjegiefnOr8aM42OAcUkjEWSlautIIX8
oD2GizwQYjWdDDjEonbuMKFP6rY2xGI3PSLI3IVU2opb0/itNhQui3WRxafloJqTlriY8m8+
qSLr2HGftbBlbyzVWB8o//aW0H0LMabjkIvrm7Zmh2vcCxiSxGBwYASuSYXGuQiKAgGptUs1
XJLZuzGCA9owggPWAgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20g
THRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG
A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EC
Ah5jMAkGBSsOAwIaBQCgggIbMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcN
AQkFMQ8XDTEyMDkxNzEzMjg0M1owIwYJKoZIhvcNAQkEMRYEFGSK8c72POFSJGwTLV+fJMct
Q0YwMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggqhkiG
9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcN
AwICASgwgaQGCSsGAQQBgjcQBDGBljCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0
YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25p
bmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp
ZW50IENBAgIeYzCBpgYLKoZIhvcNAQkQAgsxgZaggZMwgYwxCzAJBgNVBAYTAklMMRYwFAYD
VQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0
ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRp
YXRlIENsaWVudCBDQQICHmMwDQYJKoZIhvcNAQEBBQAEggEAS6tOMtRt/UXbcusnyKAhvmJB
3hoNOoQs3hkH0iNtQinBYbDE5bWifTmri4oZDXxe92YNpCKcYZNcJ3nBGWX+Qm+zyRvnnFx3
cr7iQv64mcrR2+4erugjQ7KtXHFLOfNGjq6V8b3kxgSBCKpBh5gRT0lsNP4mz3IXR0cIK/MS
XxK70ffBUIiOTnnNjyDHsE4/non0nH5j8GO8nyY0O1J/AKgQ81sgaD/2HJjERMBWToxwql6a
m7AKsgLocuyho5RsDejnMr5HeC/fSqD3uxWJqybLttdIiXO0X0NhcQT+DAwTY2auyKMhzHTG
nKtsKk+Fo7+SrPjGjDUh+kt1a7dXoQAAAAAAAA==
--------------ms080001090703050308020307--


--===============1814702204596927067==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============1814702204596927067==--


From xen-devel-bounces@lists.xen.org Mon Sep 17 13:29:17 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 13:29:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDbNa-0007ou-VA; Mon, 17 Sep 2012 13:28:50 +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 1TDbNY-0007op-EO
	for xen-devel@lists.xensource.com; Mon, 17 Sep 2012 13:28:48 +0000
Received: from [85.158.137.99:22963] by server-10.bemta-3.messagelabs.com id
	12/38-10411-F8527505; Mon, 17 Sep 2012 13:28:47 +0000
X-Env-Sender: fantonifabio@tiscali.it
X-Msg-Ref: server-14.tower-217.messagelabs.com!1347888526!17980780!1
X-Originating-IP: [94.23.245.208]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG,
	ML_RADAR_SPEW_LINKS_14,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31607 invoked from network); 17 Sep 2012 13:28:46 -0000
Received: from lnx3.fantu.it (HELO lnx3.fantu.it) (94.23.245.208)
	by server-14.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 17 Sep 2012 13:28:46 -0000
Received: from localhost (localhost.localdomain [127.0.0.1])
	by lnx3.fantu.it (Postfix) with ESMTP id 06B66401327;
	Mon, 17 Sep 2012 15:28:46 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at lnx3.fantu.it
Received: from lnx3.fantu.it ([127.0.0.1])
	by localhost (lnx3.fantu.it [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id zeyv0Xy0f4Ey; Mon, 17 Sep 2012 15:28:45 +0200 (CEST)
Received: from [192.168.178.50]
	(host106-81-dynamic.7-79-r.retail.telecomitalia.it [79.7.81.106])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: prova@fantu.it)
	by lnx3.fantu.it (Postfix) with ESMTPSA id 92ABA400599;
	Mon, 17 Sep 2012 15:28:44 +0200 (CEST)
Message-ID: <5057258B.2060003@tiscali.it>
Date: Mon, 17 Sep 2012 15:28:43 +0200
From: Fabio Fantoni <fantonifabio@tiscali.it>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:15.0) Gecko/20120907 Thunderbird/15.0.1
MIME-Version: 1.0
To: fantonifabio@tiscali.it
References: <5049EC11.9080302@tiscali.it>
	<1347030955.30018.115.camel@zakaz.uk.xensource.com>
	<504DB165.6040500@tiscali.it>
	<1347269362.5305.39.camel@zakaz.uk.xensource.com>
	<504DECE7.1050404@tiscali.it>
	<1347284515.5305.85.camel@zakaz.uk.xensource.com>
	<504DF87E.6020901@tiscali.it>
	<1347287277.5305.90.camel@zakaz.uk.xensource.com>
	<504EEEBA.9070708@tiscali.it>
In-Reply-To: <504EEEBA.9070708@tiscali.it>
Cc: xen-devel <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] Test report of xen 4.2.0-rc4
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="===============1814702204596927067=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Questo è un messaggio firmato digitalmente in formato MIME.

--===============1814702204596927067==
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms080001090703050308020307"

Questo è un messaggio firmato digitalmente in formato MIME.

--------------ms080001090703050308020307
Content-Type: multipart/mixed;
 boundary="------------010803070807050204010806"

This is a multi-part message in MIME format.
--------------010803070807050204010806
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable

Il 11/09/2012 09:56, Fabio Fantoni ha scritto:
> Il 10/09/2012 16:27, Ian Campbell ha scritto:
>> On Mon, 2012-09-10 at 15:26 +0100, Fabio Fantoni wrote:
>>> gdb --args xl -vvv cd-eject W7 hdb
>>> GNU gdb (GDB) 7.4.1-debian
>>> Copyright (C) 2012 Free Software Foundation, Inc.
>>> License GPLv3+: GNU GPL version 3 or later
>>> <http://gnu.org/licenses/gpl.html>
>>> This is free software: you are free to change and redistribute it.
>>> There is NO WARRANTY, to the extent permitted by law.  Type "show=20
>>> copying"
>>> and "show warranty" for details.
>>> This GDB was configured as "x86_64-linux-gnu".
>>> For bug reporting instructions, please see:
>>> <http://www.gnu.org/software/gdb/bugs/>...
>>> Reading symbols from /usr/sbin/xl...done.
>>> (gdb) run
>>> Starting program: /usr/sbin/xl -vvv cd-eject W7 hdb
>>> [Thread debugging using libthread_db enabled]
>>> Using host libthread_db library=20
>>> "/lib/x86_64-linux-gnu/libthread_db.so.1".
>>> libxl: debug: libxl.c:2143:libxl_cdrom_insert: ao 0x623980: create:
>>> how=3D(nil) callback=3D(nil) poller=3D0x6239e0
>>> libxl: debug: libxl_device.c:229:libxl__device_disk_set_backend: Disk=

>>> vdev=3Dhdb spec.backend=3Dunknown
>>> libxl: debug: libxl_device.c:175:disk_try_backend: Disk vdev=3Dhdb,
>>> backend phy unsuitable as phys path not a block device
>>> libxl: debug: libxl_device.c:210:disk_try_backend: Disk vdev=3Dhdb,
>>> backend tap unsuitable due to format empty
>>> libxl: debug: libxl_device.c:265:libxl__device_disk_set_backend: Disk=

>>> vdev=3Dhdb, using backend qdisk
>>> libxl: debug: libxl_event.c:1497:libxl__ao_complete: ao 0x623980:
>>> complete, rc=3D0
>>> libxl: debug: libxl.c:2236:libxl_cdrom_insert: ao 0x623980: inprogres=
s:
>>> poller=3D0x6239e0, flags=3Dic
>>> libxl: debug: libxl_event.c:1469:libxl__ao__destroy: ao 0x623980:=20
>>> destroy
>>> xc: debug: hypercall buffer: total allocations:4 total releases:4
>>> xc: debug: hypercall buffer: current allocations:0 maximum=20
>>> allocations:2
>>> xc: debug: hypercall buffer: cache current size:2
>>> xc: debug: hypercall buffer: cache hits:1 misses:2 toobig:1
>>> [Inferior 1 (process 5581) exited normally]
>>> (gdb) bt
>>> No stack.
>> That's because it seems to be working for you now... There is no crash=

>> here.
>>
>> Ian.
>>
>>
>>
>> -----
>> Nessun virus nel messaggio.
>> Controllato da AVG - www.avg.com
>> Versione: 2012.0.2197 / Database dei virus: 2437/5259 -  Data di=20
>> rilascio: 09/09/2012
>>
>>
> After issuing the command:
> xl -vvv cd-eject PRECISEHVM hdb
> libxl: debug: libxl.c:2143:libxl_cdrom_insert: ao 0x1812980: create:=20
> how=3D(nil) callback=3D(nil) poller=3D0x18129e0
> libxl: debug: libxl_device.c:229:libxl__device_disk_set_backend: Disk=20
> vdev=3Dhdb spec.backend=3Dunknown
> libxl: debug: libxl_device.c:175:disk_try_backend: Disk vdev=3Dhdb,=20
> backend phy unsuitable as phys path not a block device
> libxl: debug: libxl_device.c:210:disk_try_backend: Disk vdev=3Dhdb,=20
> backend tap unsuitable due to format empty
> libxl: debug: libxl_device.c:265:libxl__device_disk_set_backend: Disk=20
> vdev=3Dhdb, using backend qdisk
> libxl: debug: libxl_event.c:1497:libxl__ao_complete: ao 0x1812980:=20
> complete, rc=3D0
> libxl: debug: libxl.c:2236:libxl_cdrom_insert: ao 0x1812980:=20
> inprogress: poller=3D0x18129e0, flags=3Dic
> libxl: debug: libxl_event.c:1469:libxl__ao__destroy: ao 0x1812980:=20
> destroy
> xc: debug: hypercall buffer: total allocations:4 total releases:4
> xc: debug: hypercall buffer: current allocations:0 maximum allocations:=
2
> xc: debug: hypercall buffer: cache current size:2
> xc: debug: hypercall buffer: cache hits:1 misses:2 toobig:1
>
> The cdrom remain in domU and working
>
> I also tried with insert:
> root@vfarm:~# xl -vvv cd-insert PRECISEHVM hdb=20
> raw:/mnt/vm/iso/Clonezilla.iso
> libxl: debug: libxl.c:2143:libxl_cdrom_insert: ao 0xedd980: create:=20
> how=3D(nil) callback=3D(nil) poller=3D0xedd9e0
> Errore di segmentazione
>
> But give segmentation error and nothing change on domU (remain the old =

> cdrom working)
>
> Can you tell me datails about your dom0 configuration please?
>
I have redone a clean install of Wheezy 64 bit with xen 4.2.0-rc5.
The problem about network not working on restore is now solved.
Cdrom hotplug is not solved, it has the same problem, retried with=20
Windows 7 and Precise HVM.
I'm also attaching logs of Precise HVM with cd-insert and cd-eject,=20
qemu-dm...log seems to contain error logs that may be useful.

--------------010803070807050204010806
Content-Type: text/plain; charset=windows-1252;
 name="qemu-dm-PRECISEHVM.log"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
 filename="qemu-dm-PRECISEHVM.log"

ZG9taWQ6IDYKLXZpZGVvcmFtIG9wdGlvbiBkb2VzIG5vdCB3b3JrIHdpdGggY2lycnVzIHZn
YSBkZXZpY2UgbW9kZWwuIFZpZGVvcmFtIHNldCB0byA0TS4KVXNpbmcgZmlsZSAvZGV2L3hl
bi9ibGt0YXAtMi90YXBkZXYwIGluIHJlYWQtd3JpdGUgbW9kZQpVc2luZyBmaWxlIC9kZXYv
eGVuL2Jsa3RhcC0yL3RhcGRldjEgaW4gcmVhZC1vbmx5IG1vZGUKV2F0Y2hpbmcgL2xvY2Fs
L2RvbWFpbi8wL2RldmljZS1tb2RlbC82L2xvZ2RpcnR5L2NtZApXYXRjaGluZyAvbG9jYWwv
ZG9tYWluLzAvZGV2aWNlLW1vZGVsLzYvY29tbWFuZApXYXRjaGluZyAvbG9jYWwvZG9tYWlu
LzYvY3B1CnFlbXVfbWFwX2NhY2hlX2luaXQgbnJfYnVja2V0cyA9IDEwMDAwIHNpemUgNDE5
NDMwNApzaGFyZWQgcGFnZSBhdCBwZm4gZmVmZmQKYnVmZmVyZWQgaW8gcGFnZSBhdCBwZm4g
ZmVmZmIKR3Vlc3QgdXVpZCA9IDQ0ZGRlMzA1LWUxMzktNGViNi1iYWM2LWU0NTI2YjNmMDI3
YQpwb3B1bGF0aW5nIHZpZGVvIFJBTSBhdCBmZjAwMDAwMAptYXBwaW5nIHZpZGVvIFJBTSBm
cm9tIGZmMDAwMDAwClJlZ2lzdGVyIHhlbiBwbGF0Zm9ybS4KRG9uZSByZWdpc3RlciBwbGF0
Zm9ybS4KcGxhdGZvcm1fZml4ZWRfaW9wb3J0OiBjaGFuZ2VkIHJvL3J3IHN0YXRlIG9mIFJP
TSBtZW1vcnkgYXJlYS4gbm93IGlzIHJ3IHN0YXRlLgp4c19yZWFkKC9sb2NhbC9kb21haW4v
MC9kZXZpY2UtbW9kZWwvNi94ZW5fZXh0ZW5kZWRfcG93ZXJfbWdtdCk6IHJlYWQgZXJyb3IK
eHNfcmVhZCgpOiB2bmNwYXNzd2QgZ2V0IGVycm9yLiAvdm0vNDRkZGUzMDUtZTEzOS00ZWI2
LWJhYzYtZTQ1MjZiM2YwMjdhL3ZuY3Bhc3N3ZC4KbWVkaXVtIGNoYW5nZSB3YXRjaCBvbiBg
aGRiJyAoaW5kZXg6IDEpOiAvZGV2L3hlbi9ibGt0YXAtMi90YXBkZXYxCkkvTyByZXF1ZXN0
IG5vdCByZWFkeTogMCwgcHRyOiAwLCBwb3J0OiAwLCBkYXRhOiAwLCBjb3VudDogMCwgc2l6
ZTogMApMb2ctZGlydHk6IG5vIGNvbW1hbmQgeWV0LgpJL08gcmVxdWVzdCBub3QgcmVhZHk6
IDAsIHB0cjogMCwgcG9ydDogMCwgZGF0YTogMCwgY291bnQ6IDAsIHNpemU6IDAKdmNwdS1z
ZXQ6IHdhdGNoIG5vZGUgZXJyb3IuCnhzX3JlYWQoL2xvY2FsL2RvbWFpbi82L2xvZy10aHJv
dHRsaW5nKTogcmVhZCBlcnJvcgpxZW11OiBpZ25vcmluZyBub3QtdW5kZXJzdG9vZCBkcml2
ZSBgL2xvY2FsL2RvbWFpbi82L2xvZy10aHJvdHRsaW5nJwptZWRpdW0gY2hhbmdlIHdhdGNo
IG9uIGAvbG9jYWwvZG9tYWluLzYvbG9nLXRocm90dGxpbmcnIC0gdW5rbm93biBkZXZpY2Us
IGlnbm9yZWQKY2lycnVzIHZnYSBtYXAgY2hhbmdlIHdoaWxlIG9uIGxmYiBtb2RlCm1hcHBp
bmcgdnJhbSB0byBmMDAwMDAwMCAtIGYwNDAwMDAwCnBsYXRmb3JtX2ZpeGVkX2lvcG9ydDog
Y2hhbmdlZCByby9ydyBzdGF0ZSBvZiBST00gbWVtb3J5IGFyZWEuIG5vdyBpcyBydyBzdGF0
ZS4KcGxhdGZvcm1fZml4ZWRfaW9wb3J0OiBjaGFuZ2VkIHJvL3J3IHN0YXRlIG9mIFJPTSBt
ZW1vcnkgYXJlYS4gbm93IGlzIHJvIHN0YXRlLgpVbmtub3duIFBWIHByb2R1Y3QgMyBsb2Fk
ZWQgaW4gZ3Vlc3QKUFYgZHJpdmVyIGJ1aWxkIDEKcmVnaW9uIHR5cGUgMSBhdCBbYzEwMCxj
MjAwKS4KcmVnaW9uIHR5cGUgMCBhdCBbZjMwMDEwMDAsZjMwMDExMDApLgpzcXVhc2ggaW9t
ZW0gW2YzMDAxMDAwLCBmMzAwMTEwMCkuCnhjOiBlcnJvcjogbGludXhfZ250dGFiX3NldF9t
YXhfZ3JhbnRzOiBpb2N0bCBTRVRfTUFYX0dSQU5UUyBmYWlsZWQgKDIyID0gSW52YWxpZCBh
cmd1bWVudCk6IEludGVybmFsIGVycm9yCnhlbiBiZTogcWRpc2stODMyOiB4ZW4gYmU6IHFk
aXNrLTgzMjogeGNfZ250dGFiX3NldF9tYXhfZ3JhbnRzIGZhaWxlZDogSW52YWxpZCBhcmd1
bWVudAp4Y19nbnR0YWJfc2V0X21heF9ncmFudHMgZmFpbGVkOiBJbnZhbGlkIGFyZ3VtZW50
CnhlbiBiZTogcWRpc2stODMyOiB4ZW4gYmU6IHFkaXNrLTgzMjogcmVhZGluZyBiYWNrZW5k
IHN0YXRlIGZhaWxlZApyZWFkaW5nIGJhY2tlbmQgc3RhdGUgZmFpbGVkCnhlbiBiZTogcWRp
c2stODMyOiB4ZW4gYmU6IHFkaXNrLTgzMjogcmVhZGluZyBiYWNrZW5kIHN0YXRlIGZhaWxl
ZApyZWFkaW5nIGJhY2tlbmQgc3RhdGUgZmFpbGVkClRpbWUgb2Zmc2V0IHNldCAxLCBhZGRl
ZCBvZmZzZXQgMQpzaHV0ZG93biByZXF1ZXN0ZWQgaW4gY3B1X2hhbmRsZV9pb3JlcQpJc3N1
ZWQgZG9tYWluIDYgcG93ZXJvZmYK
--------------010803070807050204010806
Content-Type: text/plain; charset=windows-1252;
 name="xl-PRECISEHVM.log"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
 filename="xl-PRECISEHVM.log"

V2FpdGluZyBmb3IgZG9tYWluIFBSRUNJU0VIVk0gKGRvbWlkIDYpIHRvIGRpZSBbcGlkIDQ4
NTNdCkRvbWFpbiA2IGhhcyBzaHV0IGRvd24sIHJlYXNvbiBjb2RlIDAgMHgwCkFjdGlvbiBm
b3Igc2h1dGRvd24gcmVhc29uIGNvZGUgMCBpcyBkZXN0cm95CkRvbWFpbiA2IG5lZWRzIHRv
IGJlIGNsZWFuZWQgdXA6IGRlc3Ryb3lpbmcgdGhlIGRvbWFpbgpEb25lLiBFeGl0aW5nIG5v
dwo=
--------------010803070807050204010806--

--------------ms080001090703050308020307
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: Firma crittografica S/MIME

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINhjCC
BjQwggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT
DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp
Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3
MTAyNDIxMDI1NVoXDTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T
dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu
aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs
aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOM
KqANy9BV7V0igWdGxA8IU77L3aTxErQ+fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi
8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke/s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8M
DP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHksw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y
2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHHtOkzUreG//CsFnB9+uaYSlR65cdG
zTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB
Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd+q9rMfPIHeOsuzAfBgNV
HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH
MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3
dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu
c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v
c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0
dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93
d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqp
Jw3I07QWke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Mic
c/NXcs7kPBRdn6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9Jphw
UPTXwHovjavRnhUQHLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMc
p+reg9901zkyT3fDW/ivJVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT
+HBDYtbuvexNftwNQKD5193A7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1X
hwby6mLhkbaXslkVtwEWT3Van49rKjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvO
hNz/QplNa+VkIsrcp7+8ZhP1l1b2U6MaxIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC
0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqh
AChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H75dVCV33K6FuxZrf09yTz+Vx/PkdRUYk
XmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHSjCCBjKgAwIBAgICHmMwDQYJKoZIhvcNAQEF
BQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJT
ZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD
bGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0xMjAzMTgyMjE0MzBa
Fw0xNDAzMjAwODU3MDlaMIGMMRkwFwYDVQQNExBlQjZPRTM3UlJOUHlsNW0yMQswCQYDVQQG
EwJJVDEQMA4GA1UECBMHQmVyZ2FtbzEQMA4GA1UEBxMHUm92ZXR0YTEWMBQGA1UEAxMNRmFi
aW8gRmFudG9uaTEmMCQGCSqGSIb3DQEJARYXZmFudG9uaWZhYmlvQHRpc2NhbGkuaXQwggEi
MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC1XhckXsX23vgJq76s2f0KT8U8Msov5QgV
10eQBb2wL/TzcmqtZotI7ztKVhio3ehHg+mfu+3EqOkX9Umgut8rP0bPi7AGjkPXbOTT/cSU
Xz2Kw31VGOmiOVoUFGvpQitp3weCkhUJLBipI8EpNyBXpjtQ9yCpnIAqfuc77ybfSnCy7tTR
MBq1BUkfjH1+GL45riosuS4+F+MSUvlYzLiT4rAduAX1Y2IuORDsf9Bce8GBxa6syP9rCyzl
Vk7DIX5k8j2vlnyRATIypn5CQLQxGT6e0f6ac4gvWOHwO2QEBsmZKKs1ZidE4q/9OoNXYX6A
jnHtp1H1vcrek/vVcs19AgMBAAGjggOyMIIDrjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAd
BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFFan8cbEWWBmSTWFtLk2
YNdAcGUbMB8GA1UdIwQYMBaAFK5Vg2/sMcq59x36r2sx88gd46y7MCIGA1UdEQQbMBmBF2Zh
bnRvbmlmYWJpb0B0aXNjYWxpLml0MIICIQYDVR0gBIICGDCCAhQwggIQBgsrBgEEAYG1NwEC
AjCCAf8wLgYIKwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYw
NAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYw
gfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMC
AQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNjb3JkaW5nIHRvIHRoZSBDbGFz
cyAyIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3ks
IHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGluIGNvbXBsaWFuY2Ug
b2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMIGcBggrBgEFBQcCAjCBjzAnFiBT
dGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgECGmRMaWFiaWxpdHkgYW5kIHdh
cnJhbnRpZXMgYXJlIGxpbWl0ZWQhIFNlZSBzZWN0aW9uICJMZWdhbCBhbmQgTGltaXRhdGlv
bnMiIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3kuMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6
Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUyLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYI
KwYBBQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MyL2NsaWVudC9j
YTBCBggrBgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNz
Mi5jbGllbnQuY2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzAN
BgkqhkiG9w0BAQUFAAOCAQEAjzHNqifpDVMkH1TSPFZVIiQ4fh49/V5JMpstgqEZPDaDe5r8
h+fMBZtUa6LLMco03Z9BNEXlqlXKiFk8feVYB8obEjz7YYq1XhO9q7JUmkSs0WGIH4xU0XB1
kPC8T8H+5E//84poYSFHE4pA+Ff68UANP2/EuFJWMjegiefnOr8aM42OAcUkjEWSlautIIX8
oD2GizwQYjWdDDjEonbuMKFP6rY2xGI3PSLI3IVU2opb0/itNhQui3WRxafloJqTlriY8m8+
qSLr2HGftbBlbyzVWB8o//aW0H0LMabjkIvrm7Zmh2vcCxiSxGBwYASuSYXGuQiKAgGptUs1
XJLZuzGCA9owggPWAgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20g
THRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG
A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EC
Ah5jMAkGBSsOAwIaBQCgggIbMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcN
AQkFMQ8XDTEyMDkxNzEzMjg0M1owIwYJKoZIhvcNAQkEMRYEFGSK8c72POFSJGwTLV+fJMct
Q0YwMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggqhkiG
9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcN
AwICASgwgaQGCSsGAQQBgjcQBDGBljCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0
YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25p
bmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp
ZW50IENBAgIeYzCBpgYLKoZIhvcNAQkQAgsxgZaggZMwgYwxCzAJBgNVBAYTAklMMRYwFAYD
VQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0
ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRp
YXRlIENsaWVudCBDQQICHmMwDQYJKoZIhvcNAQEBBQAEggEAS6tOMtRt/UXbcusnyKAhvmJB
3hoNOoQs3hkH0iNtQinBYbDE5bWifTmri4oZDXxe92YNpCKcYZNcJ3nBGWX+Qm+zyRvnnFx3
cr7iQv64mcrR2+4erugjQ7KtXHFLOfNGjq6V8b3kxgSBCKpBh5gRT0lsNP4mz3IXR0cIK/MS
XxK70ffBUIiOTnnNjyDHsE4/non0nH5j8GO8nyY0O1J/AKgQ81sgaD/2HJjERMBWToxwql6a
m7AKsgLocuyho5RsDejnMr5HeC/fSqD3uxWJqybLttdIiXO0X0NhcQT+DAwTY2auyKMhzHTG
nKtsKk+Fo7+SrPjGjDUh+kt1a7dXoQAAAAAAAA==
--------------ms080001090703050308020307--


--===============1814702204596927067==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============1814702204596927067==--


From xen-devel-bounces@lists.xen.org Mon Sep 17 13:41:17 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 13:41:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDbZC-00080j-9w; Mon, 17 Sep 2012 13:40: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 1TDbZA-00080e-O3
	for xen-devel@lists.xensource.com; Mon, 17 Sep 2012 13:40:48 +0000
Received: from [85.158.137.99:16378] by server-10.bemta-3.messagelabs.com id
	81/CB-10411-F5827505; Mon, 17 Sep 2012 13:40:47 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-7.tower-217.messagelabs.com!1347889245!13212004!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzQ1MDU4\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30621 invoked from network); 17 Sep 2012 13:40:47 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-7.tower-217.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 17 Sep 2012 13:40:47 -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 q8HDeM17009970
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 17 Sep 2012 13:40:22 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q8HDeKUs026013
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 17 Sep 2012 13:40:20 GMT
Received: from abhmt116.oracle.com (abhmt116.oracle.com [141.146.116.68])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q8HDeJ4J019343; Mon, 17 Sep 2012 08:40:19 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 17 Sep 2012 06:40:19 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 50A114032B; Mon, 17 Sep 2012 09:29:32 -0400 (EDT)
Date: Mon, 17 Sep 2012 09:29:32 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20120917132932.GA11517@phenom.dumpdata.com>
References: <alpine.DEB.2.02.1209141145150.29232@kaball.uk.xensource.com>
	<1347621207-11294-10-git-send-email-stefano.stabellini@eu.citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1347621207-11294-10-git-send-email-stefano.stabellini@eu.citrix.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, linaro-dev@lists.linaro.org,
	Ian.Campbell@citrix.com, arnd@arndb.de, catalin.marinas@arm.com,
	tim@xen.org, linux-kernel@vger.kernel.org,
	linux@arm.linux.org.uk, linux-arm-kernel@lists.infradead.org
Subject: Re: [Xen-devel] [PATCH v4 10/24] xen/arm: compile and run xenbus
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Sep 14, 2012 at 12:13:12PM +0100, Stefano Stabellini wrote:
> bind_evtchn_to_irqhandler can legitimately return 0 (irq 0): it is not
> an error.
> 
> If Linux is running as an HVM domain and is running as Dom0, use
> xenstored_local_init to initialize the xenstore page and event channel.
> 
> 
> Changes in v4:
> 
> - do not xs_reset_watches on dom0.
> 
> 
> Changes in v2:
> 
> - refactor xenbus_init.
> 
> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>


If you would like I can also carry this in my tree.
> ---
>  drivers/xen/xenbus/xenbus_comms.c |    2 +-
>  drivers/xen/xenbus/xenbus_probe.c |   62 +++++++++++++++++++++++++-----------
>  drivers/xen/xenbus/xenbus_xs.c    |    3 +-
>  3 files changed, 46 insertions(+), 21 deletions(-)
> 
> diff --git a/drivers/xen/xenbus/xenbus_comms.c b/drivers/xen/xenbus/xenbus_comms.c
> index 52fe7ad..c5aa55c 100644
> --- a/drivers/xen/xenbus/xenbus_comms.c
> +++ b/drivers/xen/xenbus/xenbus_comms.c
> @@ -224,7 +224,7 @@ int xb_init_comms(void)
>  		int err;
>  		err = bind_evtchn_to_irqhandler(xen_store_evtchn, wake_waiting,
>  						0, "xenbus", &xb_waitq);
> -		if (err <= 0) {
> +		if (err < 0) {
>  			printk(KERN_ERR "XENBUS request irq failed %i\n", err);
>  			return err;
>  		}
> diff --git a/drivers/xen/xenbus/xenbus_probe.c b/drivers/xen/xenbus/xenbus_probe.c
> index b793723..a67ccc0 100644
> --- a/drivers/xen/xenbus/xenbus_probe.c
> +++ b/drivers/xen/xenbus/xenbus_probe.c
> @@ -719,37 +719,61 @@ static int __init xenstored_local_init(void)
>  	return err;
>  }
>  
> +enum xenstore_init {
> +	UNKNOWN,
> +	PV,
> +	HVM,
> +	LOCAL,
> +};
>  static int __init xenbus_init(void)
>  {
>  	int err = 0;
> +	enum xenstore_init usage = UNKNOWN;
> +	uint64_t v = 0;
>  
>  	if (!xen_domain())
>  		return -ENODEV;
>  
>  	xenbus_ring_ops_init();
>  
> -	if (xen_hvm_domain()) {
> -		uint64_t v = 0;
> -		err = hvm_get_parameter(HVM_PARAM_STORE_EVTCHN, &v);
> -		if (err)
> -			goto out_error;
> -		xen_store_evtchn = (int)v;
> -		err = hvm_get_parameter(HVM_PARAM_STORE_PFN, &v);
> -		if (err)
> -			goto out_error;
> -		xen_store_mfn = (unsigned long)v;
> -		xen_store_interface = ioremap(xen_store_mfn << PAGE_SHIFT, PAGE_SIZE);
> -	} else {
> -		xen_store_evtchn = xen_start_info->store_evtchn;
> -		xen_store_mfn = xen_start_info->store_mfn;
> -		if (xen_store_evtchn)
> -			xenstored_ready = 1;
> -		else {
> +	if (xen_pv_domain())
> +		usage = PV;
> +	if (xen_hvm_domain())
> +		usage = HVM;
> +	if (xen_hvm_domain() && xen_initial_domain())
> +		usage = LOCAL;
> +	if (xen_pv_domain() && !xen_start_info->store_evtchn)
> +		usage = LOCAL;
> +	if (xen_pv_domain() && xen_start_info->store_evtchn)
> +		xenstored_ready = 1;
> +
> +	switch (usage) {
> +		case LOCAL:
>  			err = xenstored_local_init();
>  			if (err)
>  				goto out_error;
> -		}
> -		xen_store_interface = mfn_to_virt(xen_store_mfn);
> +			xen_store_interface = mfn_to_virt(xen_store_mfn);
> +			break;
> +		case PV:
> +			xen_store_evtchn = xen_start_info->store_evtchn;
> +			xen_store_mfn = xen_start_info->store_mfn;
> +			xen_store_interface = mfn_to_virt(xen_store_mfn);
> +			break;
> +		case HVM:
> +			err = hvm_get_parameter(HVM_PARAM_STORE_EVTCHN, &v);
> +			if (err)
> +				goto out_error;
> +			xen_store_evtchn = (int)v;
> +			err = hvm_get_parameter(HVM_PARAM_STORE_PFN, &v);
> +			if (err)
> +				goto out_error;
> +			xen_store_mfn = (unsigned long)v;
> +			xen_store_interface =
> +				ioremap(xen_store_mfn << PAGE_SHIFT, PAGE_SIZE);
> +			break;
> +		default:
> +			pr_warn("Xenstore state unknown\n");
> +			break;
>  	}
>  
>  	/* Initialize the interface to xenstore. */
> diff --git a/drivers/xen/xenbus/xenbus_xs.c b/drivers/xen/xenbus/xenbus_xs.c
> index bce15cf..131dec0 100644
> --- a/drivers/xen/xenbus/xenbus_xs.c
> +++ b/drivers/xen/xenbus/xenbus_xs.c
> @@ -44,6 +44,7 @@
>  #include <linux/rwsem.h>
>  #include <linux/module.h>
>  #include <linux/mutex.h>
> +#include <asm/xen/hypervisor.h>
>  #include <xen/xenbus.h>
>  #include <xen/xen.h>
>  #include "xenbus_comms.h"
> @@ -622,7 +623,7 @@ static void xs_reset_watches(void)
>  {
>  	int err, supported = 0;
>  
> -	if (!xen_hvm_domain())
> +	if (!xen_hvm_domain() || xen_initial_domain())
>  		return;
>  
>  	err = xenbus_scanf(XBT_NIL, "control",
> -- 
> 1.7.2.5

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 17 13:41:17 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 13:41:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDbZC-00080j-9w; Mon, 17 Sep 2012 13:40: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 1TDbZA-00080e-O3
	for xen-devel@lists.xensource.com; Mon, 17 Sep 2012 13:40:48 +0000
Received: from [85.158.137.99:16378] by server-10.bemta-3.messagelabs.com id
	81/CB-10411-F5827505; Mon, 17 Sep 2012 13:40:47 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-7.tower-217.messagelabs.com!1347889245!13212004!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzQ1MDU4\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30621 invoked from network); 17 Sep 2012 13:40:47 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-7.tower-217.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 17 Sep 2012 13:40:47 -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 q8HDeM17009970
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 17 Sep 2012 13:40:22 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q8HDeKUs026013
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 17 Sep 2012 13:40:20 GMT
Received: from abhmt116.oracle.com (abhmt116.oracle.com [141.146.116.68])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q8HDeJ4J019343; Mon, 17 Sep 2012 08:40:19 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 17 Sep 2012 06:40:19 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 50A114032B; Mon, 17 Sep 2012 09:29:32 -0400 (EDT)
Date: Mon, 17 Sep 2012 09:29:32 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20120917132932.GA11517@phenom.dumpdata.com>
References: <alpine.DEB.2.02.1209141145150.29232@kaball.uk.xensource.com>
	<1347621207-11294-10-git-send-email-stefano.stabellini@eu.citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1347621207-11294-10-git-send-email-stefano.stabellini@eu.citrix.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, linaro-dev@lists.linaro.org,
	Ian.Campbell@citrix.com, arnd@arndb.de, catalin.marinas@arm.com,
	tim@xen.org, linux-kernel@vger.kernel.org,
	linux@arm.linux.org.uk, linux-arm-kernel@lists.infradead.org
Subject: Re: [Xen-devel] [PATCH v4 10/24] xen/arm: compile and run xenbus
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Sep 14, 2012 at 12:13:12PM +0100, Stefano Stabellini wrote:
> bind_evtchn_to_irqhandler can legitimately return 0 (irq 0): it is not
> an error.
> 
> If Linux is running as an HVM domain and is running as Dom0, use
> xenstored_local_init to initialize the xenstore page and event channel.
> 
> 
> Changes in v4:
> 
> - do not xs_reset_watches on dom0.
> 
> 
> Changes in v2:
> 
> - refactor xenbus_init.
> 
> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>


If you would like I can also carry this in my tree.
> ---
>  drivers/xen/xenbus/xenbus_comms.c |    2 +-
>  drivers/xen/xenbus/xenbus_probe.c |   62 +++++++++++++++++++++++++-----------
>  drivers/xen/xenbus/xenbus_xs.c    |    3 +-
>  3 files changed, 46 insertions(+), 21 deletions(-)
> 
> diff --git a/drivers/xen/xenbus/xenbus_comms.c b/drivers/xen/xenbus/xenbus_comms.c
> index 52fe7ad..c5aa55c 100644
> --- a/drivers/xen/xenbus/xenbus_comms.c
> +++ b/drivers/xen/xenbus/xenbus_comms.c
> @@ -224,7 +224,7 @@ int xb_init_comms(void)
>  		int err;
>  		err = bind_evtchn_to_irqhandler(xen_store_evtchn, wake_waiting,
>  						0, "xenbus", &xb_waitq);
> -		if (err <= 0) {
> +		if (err < 0) {
>  			printk(KERN_ERR "XENBUS request irq failed %i\n", err);
>  			return err;
>  		}
> diff --git a/drivers/xen/xenbus/xenbus_probe.c b/drivers/xen/xenbus/xenbus_probe.c
> index b793723..a67ccc0 100644
> --- a/drivers/xen/xenbus/xenbus_probe.c
> +++ b/drivers/xen/xenbus/xenbus_probe.c
> @@ -719,37 +719,61 @@ static int __init xenstored_local_init(void)
>  	return err;
>  }
>  
> +enum xenstore_init {
> +	UNKNOWN,
> +	PV,
> +	HVM,
> +	LOCAL,
> +};
>  static int __init xenbus_init(void)
>  {
>  	int err = 0;
> +	enum xenstore_init usage = UNKNOWN;
> +	uint64_t v = 0;
>  
>  	if (!xen_domain())
>  		return -ENODEV;
>  
>  	xenbus_ring_ops_init();
>  
> -	if (xen_hvm_domain()) {
> -		uint64_t v = 0;
> -		err = hvm_get_parameter(HVM_PARAM_STORE_EVTCHN, &v);
> -		if (err)
> -			goto out_error;
> -		xen_store_evtchn = (int)v;
> -		err = hvm_get_parameter(HVM_PARAM_STORE_PFN, &v);
> -		if (err)
> -			goto out_error;
> -		xen_store_mfn = (unsigned long)v;
> -		xen_store_interface = ioremap(xen_store_mfn << PAGE_SHIFT, PAGE_SIZE);
> -	} else {
> -		xen_store_evtchn = xen_start_info->store_evtchn;
> -		xen_store_mfn = xen_start_info->store_mfn;
> -		if (xen_store_evtchn)
> -			xenstored_ready = 1;
> -		else {
> +	if (xen_pv_domain())
> +		usage = PV;
> +	if (xen_hvm_domain())
> +		usage = HVM;
> +	if (xen_hvm_domain() && xen_initial_domain())
> +		usage = LOCAL;
> +	if (xen_pv_domain() && !xen_start_info->store_evtchn)
> +		usage = LOCAL;
> +	if (xen_pv_domain() && xen_start_info->store_evtchn)
> +		xenstored_ready = 1;
> +
> +	switch (usage) {
> +		case LOCAL:
>  			err = xenstored_local_init();
>  			if (err)
>  				goto out_error;
> -		}
> -		xen_store_interface = mfn_to_virt(xen_store_mfn);
> +			xen_store_interface = mfn_to_virt(xen_store_mfn);
> +			break;
> +		case PV:
> +			xen_store_evtchn = xen_start_info->store_evtchn;
> +			xen_store_mfn = xen_start_info->store_mfn;
> +			xen_store_interface = mfn_to_virt(xen_store_mfn);
> +			break;
> +		case HVM:
> +			err = hvm_get_parameter(HVM_PARAM_STORE_EVTCHN, &v);
> +			if (err)
> +				goto out_error;
> +			xen_store_evtchn = (int)v;
> +			err = hvm_get_parameter(HVM_PARAM_STORE_PFN, &v);
> +			if (err)
> +				goto out_error;
> +			xen_store_mfn = (unsigned long)v;
> +			xen_store_interface =
> +				ioremap(xen_store_mfn << PAGE_SHIFT, PAGE_SIZE);
> +			break;
> +		default:
> +			pr_warn("Xenstore state unknown\n");
> +			break;
>  	}
>  
>  	/* Initialize the interface to xenstore. */
> diff --git a/drivers/xen/xenbus/xenbus_xs.c b/drivers/xen/xenbus/xenbus_xs.c
> index bce15cf..131dec0 100644
> --- a/drivers/xen/xenbus/xenbus_xs.c
> +++ b/drivers/xen/xenbus/xenbus_xs.c
> @@ -44,6 +44,7 @@
>  #include <linux/rwsem.h>
>  #include <linux/module.h>
>  #include <linux/mutex.h>
> +#include <asm/xen/hypervisor.h>
>  #include <xen/xenbus.h>
>  #include <xen/xen.h>
>  #include "xenbus_comms.h"
> @@ -622,7 +623,7 @@ static void xs_reset_watches(void)
>  {
>  	int err, supported = 0;
>  
> -	if (!xen_hvm_domain())
> +	if (!xen_hvm_domain() || xen_initial_domain())
>  		return;
>  
>  	err = xenbus_scanf(XBT_NIL, "control",
> -- 
> 1.7.2.5

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 17 13:44:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 13: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 1TDbc6-00088S-1m; Mon, 17 Sep 2012 13:43:50 +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 1TDbc4-00088L-Aj
	for xen-devel@lists.xen.org; Mon, 17 Sep 2012 13:43:48 +0000
Received: from [85.158.139.211:13612] by server-8.bemta-5.messagelabs.com id
	68/AD-15219-31927505; Mon, 17 Sep 2012 13:43:47 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-16.tower-206.messagelabs.com!1347889425!18915777!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDc1NTA4Mg==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30918 invoked from network); 17 Sep 2012 13:43:46 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-16.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 17 Sep 2012 13:43:46 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q8HDhORR010606
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 17 Sep 2012 13:43:24 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
	q8HDhLRT013702
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 17 Sep 2012 13:43:23 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
	q8HDhLE8021665; Mon, 17 Sep 2012 08:43:21 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 17 Sep 2012 06:43:21 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 4910C4032B; Mon, 17 Sep 2012 09:32:34 -0400 (EDT)
Date: Mon, 17 Sep 2012 09:32:34 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Andres Lagar-Cavilla <andreslc@gridcentric.ca>, davem@davemloft.net
Message-ID: <20120917133234.GB11553@phenom.dumpdata.com>
References: <1347632819-13684-1-git-send-email-andres@lagarcavilla.org>
	<1347869865.14977.15.camel@zakaz.uk.xensource.com>
	<5B5132A4-93B2-41D0-B1A6-048810565DB5@gridcentric.ca>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <5B5132A4-93B2-41D0-B1A6-048810565DB5@gridcentric.ca>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: Ian Campbell <Ian.Campbell@citrix.com>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	xen-devel <xen-devel@lists.xen.org>,
	David Vrabel <david.vrabel@citrix.com>, David Miller <davem@davemloft.net>,
	Andres Lagar-Cavilla <andres@lagarcavilla.org>
Subject: Re: [Xen-devel] [PATCH] Xen backend support for paged out grant
	targets V4.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> >> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
> > 
> > Acked-by: Ian Campbell <ian.campbell@citrix.com>
> > 
> > Since this is more about grant tables than netback this should probably
> > go via Konrad rather than Dave, is that OK with you Dave?
> 
> If that is the case hopefully Konrad can deal with the two typos? Otherwise happy to re-spin the patch.

Sure. Just waiting for an Ack from David.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 17 13:44:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 13: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 1TDbc6-00088S-1m; Mon, 17 Sep 2012 13:43:50 +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 1TDbc4-00088L-Aj
	for xen-devel@lists.xen.org; Mon, 17 Sep 2012 13:43:48 +0000
Received: from [85.158.139.211:13612] by server-8.bemta-5.messagelabs.com id
	68/AD-15219-31927505; Mon, 17 Sep 2012 13:43:47 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-16.tower-206.messagelabs.com!1347889425!18915777!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDc1NTA4Mg==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30918 invoked from network); 17 Sep 2012 13:43:46 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-16.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 17 Sep 2012 13:43:46 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q8HDhORR010606
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 17 Sep 2012 13:43:24 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
	q8HDhLRT013702
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 17 Sep 2012 13:43:23 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
	q8HDhLE8021665; Mon, 17 Sep 2012 08:43:21 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 17 Sep 2012 06:43:21 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 4910C4032B; Mon, 17 Sep 2012 09:32:34 -0400 (EDT)
Date: Mon, 17 Sep 2012 09:32:34 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Andres Lagar-Cavilla <andreslc@gridcentric.ca>, davem@davemloft.net
Message-ID: <20120917133234.GB11553@phenom.dumpdata.com>
References: <1347632819-13684-1-git-send-email-andres@lagarcavilla.org>
	<1347869865.14977.15.camel@zakaz.uk.xensource.com>
	<5B5132A4-93B2-41D0-B1A6-048810565DB5@gridcentric.ca>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <5B5132A4-93B2-41D0-B1A6-048810565DB5@gridcentric.ca>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: Ian Campbell <Ian.Campbell@citrix.com>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	xen-devel <xen-devel@lists.xen.org>,
	David Vrabel <david.vrabel@citrix.com>, David Miller <davem@davemloft.net>,
	Andres Lagar-Cavilla <andres@lagarcavilla.org>
Subject: Re: [Xen-devel] [PATCH] Xen backend support for paged out grant
	targets V4.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> >> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
> > 
> > Acked-by: Ian Campbell <ian.campbell@citrix.com>
> > 
> > Since this is more about grant tables than netback this should probably
> > go via Konrad rather than Dave, is that OK with you Dave?
> 
> If that is the case hopefully Konrad can deal with the two typos? Otherwise happy to re-spin the patch.

Sure. Just waiting for an Ack from David.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 17 13:46:18 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 13:46:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDbe7-0008Im-Mi; Mon, 17 Sep 2012 13:45:55 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1TDbe5-0008IP-U8
	for xen-devel@lists.xensource.com; Mon, 17 Sep 2012 13:45:54 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1347889547!3632645!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDk2NDU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13311 invoked from network); 17 Sep 2012 13:45:47 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Sep 2012 13:45:47 -0000
X-IronPort-AV: E=Sophos;i="4.80,435,1344211200"; d="scan'208";a="14581917"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Sep 2012 13:45: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.279.1; Mon, 17 Sep 2012 14:45:46 +0100
Date: Mon, 17 Sep 2012 14:45:00 +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: <20120917132932.GA11517@phenom.dumpdata.com>
Message-ID: <alpine.DEB.2.02.1209171444060.29232@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1209141145150.29232@kaball.uk.xensource.com>
	<1347621207-11294-10-git-send-email-stefano.stabellini@eu.citrix.com>
	<20120917132932.GA11517@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>,
	"linaro-dev@lists.linaro.org" <linaro-dev@lists.linaro.org>,
	Ian Campbell <Ian.Campbell@citrix.com>, "arnd@arndb.de" <arnd@arndb.de>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"catalin.marinas@arm.com" <catalin.marinas@arm.com>,
	"Tim \(Xen.org\)" <tim@xen.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux@arm.linux.org.uk" <linux@arm.linux.org.uk>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Xen-devel] [PATCH v4 10/24] xen/arm: compile and run xenbus
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 17 Sep 2012, Konrad Rzeszutek Wilk wrote:
> On Fri, Sep 14, 2012 at 12:13:12PM +0100, Stefano Stabellini wrote:
> > bind_evtchn_to_irqhandler can legitimately return 0 (irq 0): it is not
> > an error.
> > 
> > If Linux is running as an HVM domain and is running as Dom0, use
> > xenstored_local_init to initialize the xenstore page and event channel.
> > 
> > 
> > Changes in v4:
> > 
> > - do not xs_reset_watches on dom0.
> > 
> > 
> > Changes in v2:
> > 
> > - refactor xenbus_init.
> > 
> > Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> 
> Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> 
> 
> If you would like I can also carry this in my tree.

OK, let's do that. I'll rebase again on your tree with this patch.


> >  drivers/xen/xenbus/xenbus_comms.c |    2 +-
> >  drivers/xen/xenbus/xenbus_probe.c |   62 +++++++++++++++++++++++++-----------
> >  drivers/xen/xenbus/xenbus_xs.c    |    3 +-
> >  3 files changed, 46 insertions(+), 21 deletions(-)
> > 
> > diff --git a/drivers/xen/xenbus/xenbus_comms.c b/drivers/xen/xenbus/xenbus_comms.c
> > index 52fe7ad..c5aa55c 100644
> > --- a/drivers/xen/xenbus/xenbus_comms.c
> > +++ b/drivers/xen/xenbus/xenbus_comms.c
> > @@ -224,7 +224,7 @@ int xb_init_comms(void)
> >  		int err;
> >  		err = bind_evtchn_to_irqhandler(xen_store_evtchn, wake_waiting,
> >  						0, "xenbus", &xb_waitq);
> > -		if (err <= 0) {
> > +		if (err < 0) {
> >  			printk(KERN_ERR "XENBUS request irq failed %i\n", err);
> >  			return err;
> >  		}
> > diff --git a/drivers/xen/xenbus/xenbus_probe.c b/drivers/xen/xenbus/xenbus_probe.c
> > index b793723..a67ccc0 100644
> > --- a/drivers/xen/xenbus/xenbus_probe.c
> > +++ b/drivers/xen/xenbus/xenbus_probe.c
> > @@ -719,37 +719,61 @@ static int __init xenstored_local_init(void)
> >  	return err;
> >  }
> >  
> > +enum xenstore_init {
> > +	UNKNOWN,
> > +	PV,
> > +	HVM,
> > +	LOCAL,
> > +};
> >  static int __init xenbus_init(void)
> >  {
> >  	int err = 0;
> > +	enum xenstore_init usage = UNKNOWN;
> > +	uint64_t v = 0;
> >  
> >  	if (!xen_domain())
> >  		return -ENODEV;
> >  
> >  	xenbus_ring_ops_init();
> >  
> > -	if (xen_hvm_domain()) {
> > -		uint64_t v = 0;
> > -		err = hvm_get_parameter(HVM_PARAM_STORE_EVTCHN, &v);
> > -		if (err)
> > -			goto out_error;
> > -		xen_store_evtchn = (int)v;
> > -		err = hvm_get_parameter(HVM_PARAM_STORE_PFN, &v);
> > -		if (err)
> > -			goto out_error;
> > -		xen_store_mfn = (unsigned long)v;
> > -		xen_store_interface = ioremap(xen_store_mfn << PAGE_SHIFT, PAGE_SIZE);
> > -	} else {
> > -		xen_store_evtchn = xen_start_info->store_evtchn;
> > -		xen_store_mfn = xen_start_info->store_mfn;
> > -		if (xen_store_evtchn)
> > -			xenstored_ready = 1;
> > -		else {
> > +	if (xen_pv_domain())
> > +		usage = PV;
> > +	if (xen_hvm_domain())
> > +		usage = HVM;
> > +	if (xen_hvm_domain() && xen_initial_domain())
> > +		usage = LOCAL;
> > +	if (xen_pv_domain() && !xen_start_info->store_evtchn)
> > +		usage = LOCAL;
> > +	if (xen_pv_domain() && xen_start_info->store_evtchn)
> > +		xenstored_ready = 1;
> > +
> > +	switch (usage) {
> > +		case LOCAL:
> >  			err = xenstored_local_init();
> >  			if (err)
> >  				goto out_error;
> > -		}
> > -		xen_store_interface = mfn_to_virt(xen_store_mfn);
> > +			xen_store_interface = mfn_to_virt(xen_store_mfn);
> > +			break;
> > +		case PV:
> > +			xen_store_evtchn = xen_start_info->store_evtchn;
> > +			xen_store_mfn = xen_start_info->store_mfn;
> > +			xen_store_interface = mfn_to_virt(xen_store_mfn);
> > +			break;
> > +		case HVM:
> > +			err = hvm_get_parameter(HVM_PARAM_STORE_EVTCHN, &v);
> > +			if (err)
> > +				goto out_error;
> > +			xen_store_evtchn = (int)v;
> > +			err = hvm_get_parameter(HVM_PARAM_STORE_PFN, &v);
> > +			if (err)
> > +				goto out_error;
> > +			xen_store_mfn = (unsigned long)v;
> > +			xen_store_interface =
> > +				ioremap(xen_store_mfn << PAGE_SHIFT, PAGE_SIZE);
> > +			break;
> > +		default:
> > +			pr_warn("Xenstore state unknown\n");
> > +			break;
> >  	}
> >  
> >  	/* Initialize the interface to xenstore. */
> > diff --git a/drivers/xen/xenbus/xenbus_xs.c b/drivers/xen/xenbus/xenbus_xs.c
> > index bce15cf..131dec0 100644
> > --- a/drivers/xen/xenbus/xenbus_xs.c
> > +++ b/drivers/xen/xenbus/xenbus_xs.c
> > @@ -44,6 +44,7 @@
> >  #include <linux/rwsem.h>
> >  #include <linux/module.h>
> >  #include <linux/mutex.h>
> > +#include <asm/xen/hypervisor.h>
> >  #include <xen/xenbus.h>
> >  #include <xen/xen.h>
> >  #include "xenbus_comms.h"
> > @@ -622,7 +623,7 @@ static void xs_reset_watches(void)
> >  {
> >  	int err, supported = 0;
> >  
> > -	if (!xen_hvm_domain())
> > +	if (!xen_hvm_domain() || xen_initial_domain())
> >  		return;
> >  
> >  	err = xenbus_scanf(XBT_NIL, "control",
> > -- 
> > 1.7.2.5
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 17 13:46:18 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 13:46:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDbe7-0008Im-Mi; Mon, 17 Sep 2012 13:45:55 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1TDbe5-0008IP-U8
	for xen-devel@lists.xensource.com; Mon, 17 Sep 2012 13:45:54 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1347889547!3632645!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDk2NDU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13311 invoked from network); 17 Sep 2012 13:45:47 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Sep 2012 13:45:47 -0000
X-IronPort-AV: E=Sophos;i="4.80,435,1344211200"; d="scan'208";a="14581917"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Sep 2012 13:45: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.279.1; Mon, 17 Sep 2012 14:45:46 +0100
Date: Mon, 17 Sep 2012 14:45:00 +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: <20120917132932.GA11517@phenom.dumpdata.com>
Message-ID: <alpine.DEB.2.02.1209171444060.29232@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1209141145150.29232@kaball.uk.xensource.com>
	<1347621207-11294-10-git-send-email-stefano.stabellini@eu.citrix.com>
	<20120917132932.GA11517@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>,
	"linaro-dev@lists.linaro.org" <linaro-dev@lists.linaro.org>,
	Ian Campbell <Ian.Campbell@citrix.com>, "arnd@arndb.de" <arnd@arndb.de>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"catalin.marinas@arm.com" <catalin.marinas@arm.com>,
	"Tim \(Xen.org\)" <tim@xen.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux@arm.linux.org.uk" <linux@arm.linux.org.uk>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Xen-devel] [PATCH v4 10/24] xen/arm: compile and run xenbus
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 17 Sep 2012, Konrad Rzeszutek Wilk wrote:
> On Fri, Sep 14, 2012 at 12:13:12PM +0100, Stefano Stabellini wrote:
> > bind_evtchn_to_irqhandler can legitimately return 0 (irq 0): it is not
> > an error.
> > 
> > If Linux is running as an HVM domain and is running as Dom0, use
> > xenstored_local_init to initialize the xenstore page and event channel.
> > 
> > 
> > Changes in v4:
> > 
> > - do not xs_reset_watches on dom0.
> > 
> > 
> > Changes in v2:
> > 
> > - refactor xenbus_init.
> > 
> > Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> 
> Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> 
> 
> If you would like I can also carry this in my tree.

OK, let's do that. I'll rebase again on your tree with this patch.


> >  drivers/xen/xenbus/xenbus_comms.c |    2 +-
> >  drivers/xen/xenbus/xenbus_probe.c |   62 +++++++++++++++++++++++++-----------
> >  drivers/xen/xenbus/xenbus_xs.c    |    3 +-
> >  3 files changed, 46 insertions(+), 21 deletions(-)
> > 
> > diff --git a/drivers/xen/xenbus/xenbus_comms.c b/drivers/xen/xenbus/xenbus_comms.c
> > index 52fe7ad..c5aa55c 100644
> > --- a/drivers/xen/xenbus/xenbus_comms.c
> > +++ b/drivers/xen/xenbus/xenbus_comms.c
> > @@ -224,7 +224,7 @@ int xb_init_comms(void)
> >  		int err;
> >  		err = bind_evtchn_to_irqhandler(xen_store_evtchn, wake_waiting,
> >  						0, "xenbus", &xb_waitq);
> > -		if (err <= 0) {
> > +		if (err < 0) {
> >  			printk(KERN_ERR "XENBUS request irq failed %i\n", err);
> >  			return err;
> >  		}
> > diff --git a/drivers/xen/xenbus/xenbus_probe.c b/drivers/xen/xenbus/xenbus_probe.c
> > index b793723..a67ccc0 100644
> > --- a/drivers/xen/xenbus/xenbus_probe.c
> > +++ b/drivers/xen/xenbus/xenbus_probe.c
> > @@ -719,37 +719,61 @@ static int __init xenstored_local_init(void)
> >  	return err;
> >  }
> >  
> > +enum xenstore_init {
> > +	UNKNOWN,
> > +	PV,
> > +	HVM,
> > +	LOCAL,
> > +};
> >  static int __init xenbus_init(void)
> >  {
> >  	int err = 0;
> > +	enum xenstore_init usage = UNKNOWN;
> > +	uint64_t v = 0;
> >  
> >  	if (!xen_domain())
> >  		return -ENODEV;
> >  
> >  	xenbus_ring_ops_init();
> >  
> > -	if (xen_hvm_domain()) {
> > -		uint64_t v = 0;
> > -		err = hvm_get_parameter(HVM_PARAM_STORE_EVTCHN, &v);
> > -		if (err)
> > -			goto out_error;
> > -		xen_store_evtchn = (int)v;
> > -		err = hvm_get_parameter(HVM_PARAM_STORE_PFN, &v);
> > -		if (err)
> > -			goto out_error;
> > -		xen_store_mfn = (unsigned long)v;
> > -		xen_store_interface = ioremap(xen_store_mfn << PAGE_SHIFT, PAGE_SIZE);
> > -	} else {
> > -		xen_store_evtchn = xen_start_info->store_evtchn;
> > -		xen_store_mfn = xen_start_info->store_mfn;
> > -		if (xen_store_evtchn)
> > -			xenstored_ready = 1;
> > -		else {
> > +	if (xen_pv_domain())
> > +		usage = PV;
> > +	if (xen_hvm_domain())
> > +		usage = HVM;
> > +	if (xen_hvm_domain() && xen_initial_domain())
> > +		usage = LOCAL;
> > +	if (xen_pv_domain() && !xen_start_info->store_evtchn)
> > +		usage = LOCAL;
> > +	if (xen_pv_domain() && xen_start_info->store_evtchn)
> > +		xenstored_ready = 1;
> > +
> > +	switch (usage) {
> > +		case LOCAL:
> >  			err = xenstored_local_init();
> >  			if (err)
> >  				goto out_error;
> > -		}
> > -		xen_store_interface = mfn_to_virt(xen_store_mfn);
> > +			xen_store_interface = mfn_to_virt(xen_store_mfn);
> > +			break;
> > +		case PV:
> > +			xen_store_evtchn = xen_start_info->store_evtchn;
> > +			xen_store_mfn = xen_start_info->store_mfn;
> > +			xen_store_interface = mfn_to_virt(xen_store_mfn);
> > +			break;
> > +		case HVM:
> > +			err = hvm_get_parameter(HVM_PARAM_STORE_EVTCHN, &v);
> > +			if (err)
> > +				goto out_error;
> > +			xen_store_evtchn = (int)v;
> > +			err = hvm_get_parameter(HVM_PARAM_STORE_PFN, &v);
> > +			if (err)
> > +				goto out_error;
> > +			xen_store_mfn = (unsigned long)v;
> > +			xen_store_interface =
> > +				ioremap(xen_store_mfn << PAGE_SHIFT, PAGE_SIZE);
> > +			break;
> > +		default:
> > +			pr_warn("Xenstore state unknown\n");
> > +			break;
> >  	}
> >  
> >  	/* Initialize the interface to xenstore. */
> > diff --git a/drivers/xen/xenbus/xenbus_xs.c b/drivers/xen/xenbus/xenbus_xs.c
> > index bce15cf..131dec0 100644
> > --- a/drivers/xen/xenbus/xenbus_xs.c
> > +++ b/drivers/xen/xenbus/xenbus_xs.c
> > @@ -44,6 +44,7 @@
> >  #include <linux/rwsem.h>
> >  #include <linux/module.h>
> >  #include <linux/mutex.h>
> > +#include <asm/xen/hypervisor.h>
> >  #include <xen/xenbus.h>
> >  #include <xen/xen.h>
> >  #include "xenbus_comms.h"
> > @@ -622,7 +623,7 @@ static void xs_reset_watches(void)
> >  {
> >  	int err, supported = 0;
> >  
> > -	if (!xen_hvm_domain())
> > +	if (!xen_hvm_domain() || xen_initial_domain())
> >  		return;
> >  
> >  	err = xenbus_scanf(XBT_NIL, "control",
> > -- 
> > 1.7.2.5
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 17 14:06:27 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 14: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 1TDbxd-0000CF-IE; Mon, 17 Sep 2012 14:06:05 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1TDbxc-0000C8-GV
	for xen-devel@lists.xensource.com; Mon, 17 Sep 2012 14:06:04 +0000
Received: from [85.158.143.99:13549] by server-2.bemta-4.messagelabs.com id
	77/19-06610-B4E27505; Mon, 17 Sep 2012 14:06:03 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1347890762!23669525!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDk2NDU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31195 invoked from network); 17 Sep 2012 14:06:03 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Sep 2012 14:06:03 -0000
X-IronPort-AV: E=Sophos;i="4.80,435,1344211200"; d="scan'208";a="14582532"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Sep 2012 14:06: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.279.1; Mon, 17 Sep 2012 15:06:02 +0100
Date: Mon, 17 Sep 2012 15:05:16 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Sergei Shtylyov <sshtylyov@mvista.com>
In-Reply-To: <50571289.3040509@mvista.com>
Message-ID: <alpine.DEB.2.02.1209171454480.29232@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1209141145150.29232@kaball.uk.xensource.com>
	<1347621207-11294-12-git-send-email-stefano.stabellini@eu.citrix.com>
	<505374E2.5080308@mvista.com>
	<alpine.DEB.2.02.1209171155010.29232@kaball.uk.xensource.com>
	<50571289.3040509@mvista.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>,
	"linaro-dev@lists.linaro.org" <linaro-dev@lists.linaro.org>,
	Ian Campbell <Ian.Campbell@citrix.com>, "arnd@arndb.de" <arnd@arndb.de>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
	"catalin.marinas@arm.com" <catalin.marinas@arm.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"Tim \(Xen.org\)" <tim@xen.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux@arm.linux.org.uk" <linux@arm.linux.org.uk>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Xen-devel] [PATCH v4 12/24] xen/arm: introduce CONFIG_XEN on
	ARM
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 17 Sep 2012, Sergei Shtylyov wrote:
> Hello.
> 
> On 17-09-2012 14:57, Stefano Stabellini wrote:
> 
> >>> Changes in v2:
> 
> >>> - mark Xen guest support on ARM as EXPERIMENTAL.
> 
> >>> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> >>> Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> >>> ---
> >>>   arch/arm/Kconfig |   10 ++++++++++
> >>>   1 files changed, 10 insertions(+), 0 deletions(-)
> 
> >>> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> >>> index 2f88d8d..e92518d 100644
> >>> --- a/arch/arm/Kconfig
> >>> +++ b/arch/arm/Kconfig
> >>> @@ -1897,6 +1897,16 @@ config DEPRECATED_PARAM_STRUCT
> >>>   	  This was deprecated in 2001 and announced to live on for 5 years.
> >>>   	  Some old boot loaders still use this way.
> >>>
> >>> +config XEN_DOM0
> >>> +	def_bool y
> >>> +
> >>> +config XEN
> >>> +	bool "Xen guest support on ARM (EXPERIMENTAL)"
> >>> +	depends on EXPERIMENTAL && ARM && OF
> >>> +	select XEN_DOM0
> 
> >>     What's the point of selecting it if it's always "y"?
> 
> > That's because on X86 is not always "y": there are things under
> > drivers/xen that compile on both platforms and depend on XEN_DOM0.
> 
>     But we're not on x86. On ARM this select is pointless.

We need some common code (under drivers/xen) that compiles only if
XEN_DOM0 is selected, so it is not pointless after all.

XEN_DOM0 is not the only symbol that is conditionally compiled on one
architectuire and always "y" on another...

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 17 14:06:27 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 14: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 1TDbxd-0000CF-IE; Mon, 17 Sep 2012 14:06:05 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1TDbxc-0000C8-GV
	for xen-devel@lists.xensource.com; Mon, 17 Sep 2012 14:06:04 +0000
Received: from [85.158.143.99:13549] by server-2.bemta-4.messagelabs.com id
	77/19-06610-B4E27505; Mon, 17 Sep 2012 14:06:03 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1347890762!23669525!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDk2NDU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31195 invoked from network); 17 Sep 2012 14:06:03 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Sep 2012 14:06:03 -0000
X-IronPort-AV: E=Sophos;i="4.80,435,1344211200"; d="scan'208";a="14582532"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Sep 2012 14:06: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.279.1; Mon, 17 Sep 2012 15:06:02 +0100
Date: Mon, 17 Sep 2012 15:05:16 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Sergei Shtylyov <sshtylyov@mvista.com>
In-Reply-To: <50571289.3040509@mvista.com>
Message-ID: <alpine.DEB.2.02.1209171454480.29232@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1209141145150.29232@kaball.uk.xensource.com>
	<1347621207-11294-12-git-send-email-stefano.stabellini@eu.citrix.com>
	<505374E2.5080308@mvista.com>
	<alpine.DEB.2.02.1209171155010.29232@kaball.uk.xensource.com>
	<50571289.3040509@mvista.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>,
	"linaro-dev@lists.linaro.org" <linaro-dev@lists.linaro.org>,
	Ian Campbell <Ian.Campbell@citrix.com>, "arnd@arndb.de" <arnd@arndb.de>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
	"catalin.marinas@arm.com" <catalin.marinas@arm.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"Tim \(Xen.org\)" <tim@xen.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux@arm.linux.org.uk" <linux@arm.linux.org.uk>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Xen-devel] [PATCH v4 12/24] xen/arm: introduce CONFIG_XEN on
	ARM
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 17 Sep 2012, Sergei Shtylyov wrote:
> Hello.
> 
> On 17-09-2012 14:57, Stefano Stabellini wrote:
> 
> >>> Changes in v2:
> 
> >>> - mark Xen guest support on ARM as EXPERIMENTAL.
> 
> >>> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> >>> Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> >>> ---
> >>>   arch/arm/Kconfig |   10 ++++++++++
> >>>   1 files changed, 10 insertions(+), 0 deletions(-)
> 
> >>> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> >>> index 2f88d8d..e92518d 100644
> >>> --- a/arch/arm/Kconfig
> >>> +++ b/arch/arm/Kconfig
> >>> @@ -1897,6 +1897,16 @@ config DEPRECATED_PARAM_STRUCT
> >>>   	  This was deprecated in 2001 and announced to live on for 5 years.
> >>>   	  Some old boot loaders still use this way.
> >>>
> >>> +config XEN_DOM0
> >>> +	def_bool y
> >>> +
> >>> +config XEN
> >>> +	bool "Xen guest support on ARM (EXPERIMENTAL)"
> >>> +	depends on EXPERIMENTAL && ARM && OF
> >>> +	select XEN_DOM0
> 
> >>     What's the point of selecting it if it's always "y"?
> 
> > That's because on X86 is not always "y": there are things under
> > drivers/xen that compile on both platforms and depend on XEN_DOM0.
> 
>     But we're not on x86. On ARM this select is pointless.

We need some common code (under drivers/xen) that compiles only if
XEN_DOM0 is selected, so it is not pointless after all.

XEN_DOM0 is not the only symbol that is conditionally compiled on one
architectuire and always "y" on another...

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 17 14:08:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 14: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 1TDbzG-0000HM-1m; Mon, 17 Sep 2012 14:07: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 1TDbzE-0000HE-J6
	for xen-devel@lists.xensource.com; Mon, 17 Sep 2012 14:07:44 +0000
Received: from [85.158.139.211:21168] by server-2.bemta-5.messagelabs.com id
	FA/6E-11456-FAE27505; Mon, 17 Sep 2012 14:07:43 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-15.tower-206.messagelabs.com!1347890861!18934903!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzQ1MDU4\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2088 invoked from network); 17 Sep 2012 14:07:43 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-15.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 17 Sep 2012 14:07:43 -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 q8HE7Pfk013377
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 17 Sep 2012 14:07:26 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q8HE7O0g020104
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 17 Sep 2012 14:07:25 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
	q8HE7OWJ003275; Mon, 17 Sep 2012 09:07:24 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 17 Sep 2012 07:07:24 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 9A4F24032B; Mon, 17 Sep 2012 09:56:37 -0400 (EDT)
Date: Mon, 17 Sep 2012 09:56:37 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20120917135637.GG11553@phenom.dumpdata.com>
References: <alpine.DEB.2.02.1209141145150.29232@kaball.uk.xensource.com>
	<1347621207-11294-10-git-send-email-stefano.stabellini@eu.citrix.com>
	<20120914130308.GI25249@phenom.dumpdata.com>
	<alpine.DEB.2.02.1209171205470.29232@kaball.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <alpine.DEB.2.02.1209171205470.29232@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>,
	"linaro-dev@lists.linaro.org" <linaro-dev@lists.linaro.org>,
	Ian Campbell <Ian.Campbell@citrix.com>, "arnd@arndb.de" <arnd@arndb.de>,
	"catalin.marinas@arm.com" <catalin.marinas@arm.com>,
	"Tim \(Xen.org\)" <tim@xen.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux@arm.linux.org.uk" <linux@arm.linux.org.uk>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Xen-devel] [PATCH v4 10/24] xen/arm: compile and run xenbus
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Sep 17, 2012 at 12:05:59PM +0100, Stefano Stabellini wrote:
> On Fri, 14 Sep 2012, Konrad Rzeszutek Wilk wrote:
> > On Fri, Sep 14, 2012 at 12:13:12PM +0100, Stefano Stabellini wrote:
> > > bind_evtchn_to_irqhandler can legitimately return 0 (irq 0): it is not
> > > an error.
> > > 
> > > If Linux is running as an HVM domain and is running as Dom0, use
> > > xenstored_local_init to initialize the xenstore page and event channel.
> > 
> > Let me stick it in my tree and see how it works overnight with HVM and PV guests.
> 
> Did it work?

Yes!

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 17 14:08:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 14: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 1TDbzG-0000HM-1m; Mon, 17 Sep 2012 14:07: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 1TDbzE-0000HE-J6
	for xen-devel@lists.xensource.com; Mon, 17 Sep 2012 14:07:44 +0000
Received: from [85.158.139.211:21168] by server-2.bemta-5.messagelabs.com id
	FA/6E-11456-FAE27505; Mon, 17 Sep 2012 14:07:43 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-15.tower-206.messagelabs.com!1347890861!18934903!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzQ1MDU4\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2088 invoked from network); 17 Sep 2012 14:07:43 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-15.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 17 Sep 2012 14:07:43 -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 q8HE7Pfk013377
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 17 Sep 2012 14:07:26 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q8HE7O0g020104
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 17 Sep 2012 14:07:25 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
	q8HE7OWJ003275; Mon, 17 Sep 2012 09:07:24 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 17 Sep 2012 07:07:24 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 9A4F24032B; Mon, 17 Sep 2012 09:56:37 -0400 (EDT)
Date: Mon, 17 Sep 2012 09:56:37 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20120917135637.GG11553@phenom.dumpdata.com>
References: <alpine.DEB.2.02.1209141145150.29232@kaball.uk.xensource.com>
	<1347621207-11294-10-git-send-email-stefano.stabellini@eu.citrix.com>
	<20120914130308.GI25249@phenom.dumpdata.com>
	<alpine.DEB.2.02.1209171205470.29232@kaball.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <alpine.DEB.2.02.1209171205470.29232@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>,
	"linaro-dev@lists.linaro.org" <linaro-dev@lists.linaro.org>,
	Ian Campbell <Ian.Campbell@citrix.com>, "arnd@arndb.de" <arnd@arndb.de>,
	"catalin.marinas@arm.com" <catalin.marinas@arm.com>,
	"Tim \(Xen.org\)" <tim@xen.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux@arm.linux.org.uk" <linux@arm.linux.org.uk>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Xen-devel] [PATCH v4 10/24] xen/arm: compile and run xenbus
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Sep 17, 2012 at 12:05:59PM +0100, Stefano Stabellini wrote:
> On Fri, 14 Sep 2012, Konrad Rzeszutek Wilk wrote:
> > On Fri, Sep 14, 2012 at 12:13:12PM +0100, Stefano Stabellini wrote:
> > > bind_evtchn_to_irqhandler can legitimately return 0 (irq 0): it is not
> > > an error.
> > > 
> > > If Linux is running as an HVM domain and is running as Dom0, use
> > > xenstored_local_init to initialize the xenstore page and event channel.
> > 
> > Let me stick it in my tree and see how it works overnight with HVM and PV guests.
> 
> Did it work?

Yes!

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 17 14:11:30 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 14: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 1TDc2c-0000TQ-My; Mon, 17 Sep 2012 14:11:14 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <robherring2@gmail.com>) id 1TDbRq-0007wP-R6
	for xen-devel@lists.xensource.com; Mon, 17 Sep 2012 13:33:15 +0000
Received: from [85.158.139.211:12823] by server-10.bemta-5.messagelabs.com id
	71/64-10969-99627505; Mon, 17 Sep 2012 13:33:13 +0000
X-Env-Sender: robherring2@gmail.com
X-Msg-Ref: server-13.tower-206.messagelabs.com!1347888791!14887106!1
X-Originating-IP: [209.85.219.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3320 invoked from network); 17 Sep 2012 13:33:13 -0000
Received: from mail-oa0-f43.google.com (HELO mail-oa0-f43.google.com)
	(209.85.219.43)
	by server-13.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Sep 2012 13:33:13 -0000
Received: by oagl10 with SMTP id l10so6389944oag.30
	for <xen-devel@lists.xensource.com>;
	Mon, 17 Sep 2012 06:33: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:cc:subject
	:references:in-reply-to:content-type:content-transfer-encoding;
	bh=u+tY8D8SZxYqll2fOCc5v9FAaVhfMqm3d6gdERotmbE=;
	b=lbHj1UkiiGDK8YAqKdwAvKEq86xt02DimE3E/UQNeXGCrL1fDe6snz+OSaP38TXInA
	MVbsMzGo4d/qh1de+QmTwq3pIvUvYdPIUrjHHm17vw0KCGWRU7HenOpPxkSjteziXqBc
	JlZK5ukeFz26UVQJuGKoKftuFh2xxyT/koC/qzKGinq/B7luHQTfoCnNhkhnJ8mL3tzM
	azZW24lD4B0+eoKUcM8Apye8rqeJ9I0M9aB3PgxtBxtPIkHy48yWay6iHkTk65J6ySNs
	jpRQcQkRegusNRdKALH+22koMon1k9c9drLKZyL7Wp6j+WDlgAsWNOzzPEYsEDKnwSDi
	mQlA==
Received: by 10.182.118.41 with SMTP id kj9mr11646840obb.57.1347888791258;
	Mon, 17 Sep 2012 06:33:11 -0700 (PDT)
Received: from [192.168.1.103] (65-36-73-129.dyn.grandenetworks.net.
	[65.36.73.129])
	by mx.google.com with ESMTPS id ac10sm10710997obc.7.2012.09.17.06.33.09
	(version=SSLv3 cipher=OTHER); Mon, 17 Sep 2012 06:33:10 -0700 (PDT)
Message-ID: <50572692.1090805@gmail.com>
Date: Mon, 17 Sep 2012 08:33:06 -0500
From: Rob Herring <robherring2@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:14.0) Gecko/20120714 Thunderbird/14.0
MIME-Version: 1.0
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.02.1209141145150.29232@kaball.uk.xensource.com>
	<1347621207-11294-6-git-send-email-stefano.stabellini@eu.citrix.com>
	<20120914130151.GH25249@phenom.dumpdata.com>
	<alpine.DEB.2.02.1209141514590.29232@kaball.uk.xensource.com>
In-Reply-To: <alpine.DEB.2.02.1209141514590.29232@kaball.uk.xensource.com>
X-Mailman-Approved-At: Mon, 17 Sep 2012 14:11:13 +0000
Cc: Dave Martin <dave.martin@linaro.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linaro-dev@lists.linaro.org" <linaro-dev@lists.linaro.org>,
	Ian Campbell <Ian.Campbell@citrix.com>, "arnd@arndb.de" <arnd@arndb.de>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"catalin.marinas@arm.com" <catalin.marinas@arm.com>,
	"devicetree-discuss@lists.ozlabs.org"
	<devicetree-discuss@lists.ozlabs.org>, "Tim \(Xen.org\)" <tim@xen.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	David Vrabel <david.vrabel@citrix.com>,
	"linux@arm.linux.org.uk" <linux@arm.linux.org.uk>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Xen-devel] [PATCH v4 06/24] docs: Xen ARM DT bindings
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 09/14/2012 09:26 AM, Stefano Stabellini wrote:
> On Fri, 14 Sep 2012, Konrad Rzeszutek Wilk wrote:
>> On Fri, Sep 14, 2012 at 12:13:08PM +0100, Stefano Stabellini wrote:
>>> Add a doc to describe the Xen ARM device tree bindings
>>>
>>>
>>> Changes in v4:
>>>
>>> - "xen,xen" should be last as it is less specific;
>>> - update reg property using 2 address-cells and 2 size-cells.
>>>
>>>
>>> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
>>> CC: devicetree-discuss@lists.ozlabs.org
>>> CC: David Vrabel <david.vrabel@citrix.com>
>>> CC: Rob Herring <robherring2@gmail.com>
>>> CC: Dave Martin <dave.martin@linaro.org>
>>> ---
>>>  Documentation/devicetree/bindings/arm/xen.txt |   22 ++++++++++++++++++++++
>>>  1 files changed, 22 insertions(+), 0 deletions(-)
>>>  create mode 100644 Documentation/devicetree/bindings/arm/xen.txt
>>>
>>> diff --git a/Documentation/devicetree/bindings/arm/xen.txt b/Documentation/devicetree/bindings/arm/xen.txt
>>> new file mode 100644
>>> index 0000000..1f8f7d4
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/arm/xen.txt
>>> @@ -0,0 +1,22 @@
>>> +* Xen hypervisor device tree bindings
>>> +
>>> +Xen ARM virtual platforms shall have the following properties:
>>> +

State that they are part of top-level "hypervisor" node.

>>> +- compatible:
>>> +	compatible = "xen,xen-<version>", "xen,xen";
>>> +  where <version> is the version of the Xen ABI of the platform.
>>> +
>>> +- reg: specifies the base physical address and size of a region in
>>> +  memory where the grant table should be mapped to, using an
>>> +  HYPERVISOR_memory_op hypercall. 
>>> +
>>> +- interrupts: the interrupt used by Xen to inject event notifications.
>>
>> Its singular here.. but in the example its plurar. What if you use
>> multiple of the same number ("16 0xf")?
> 
> The "interrupts" property in the example below is a standard property to
> describe interrupts. We just happen to declare only one interrupt.
> 
> From the device tree point of view it would be possible to declare more
> than one interrupt here, but Xen only supports one really.
> 
> Regarding the three cells used in the example (<1 15 0xf08>), they have
> a specific meaning in the GIC context:
> 
> """
>   The 1st cell is the interrupt type; 0 for SPI interrupts, 1 for PPI
>   interrupts.
> 
>   The 2nd cell contains the interrupt number for the interrupt type.
>   SPI interrupts are in the range [0-987].  PPI interrupts are in the
>   range [0-15].
> 
>   The 3rd cell is the flags, encoded as follows:
> 	bits[3:0] trigger type and level flags.
> 		1 = low-to-high edge triggered
> 		2 = high-to-low edge triggered
> 		4 = active high level-sensitive
> 		8 = active low level-sensitive
> 	bits[15:8] PPI interrupt cpu mask.  Each bit corresponds to each of
> 	the 8 possible cpus attached to the GIC.  A bit set to '1' indicated
> 	the interrupt is wired to that CPU.  Only valid for PPI interrupts.
> """
> 
> So <1 15 0xf08> means the last PPI.

Since it is a PPI, it is handled differently than a normal interrupt.
That is fine, but you should somehow state that a GIC node is also required.

> 
>>> +
>>> +
>>> +Example:
>>> +
>>> +hypervisor {
>>> +	compatible = "xen,xen-4.3", "xen,xen";
>>> +	reg = <0 0xb0000000 0 0x20000>;
>>
>> So two grant tables?
>>
>> Hm, physical address is zero, and the size is 0xbignumber?
>> Or is the '0' denotating a seperator of arguments, so it is
>> 0xb000.. for physical address and 0x20000 for size?
> 
> from http://devicetree.org/Device_Tree_Usage:
> 
> "Each addressable device gets a reg which is a list of tuples in the
> form reg = <address1 length1 [address2 length2] [address3 length3] ...
> Each tuple represents an address range used by the device. Each address
> value is a list of one or more 32 bit integers called cells. Similarly,
> the length value can either be a list of cells, or empty."
> 
> In this case the address is: [0 0xb0000000], that means
> 0x00000000b0000000, and the length is [0 0x20000], that means
> 0x0000000000020000.

But the size depends on #size-cells and #address-cells. I would expect
those to be 1 for a 32-bit guest.

Rob


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 17 14:11:30 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 14: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 1TDc2c-0000TQ-My; Mon, 17 Sep 2012 14:11:14 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <robherring2@gmail.com>) id 1TDbRq-0007wP-R6
	for xen-devel@lists.xensource.com; Mon, 17 Sep 2012 13:33:15 +0000
Received: from [85.158.139.211:12823] by server-10.bemta-5.messagelabs.com id
	71/64-10969-99627505; Mon, 17 Sep 2012 13:33:13 +0000
X-Env-Sender: robherring2@gmail.com
X-Msg-Ref: server-13.tower-206.messagelabs.com!1347888791!14887106!1
X-Originating-IP: [209.85.219.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3320 invoked from network); 17 Sep 2012 13:33:13 -0000
Received: from mail-oa0-f43.google.com (HELO mail-oa0-f43.google.com)
	(209.85.219.43)
	by server-13.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Sep 2012 13:33:13 -0000
Received: by oagl10 with SMTP id l10so6389944oag.30
	for <xen-devel@lists.xensource.com>;
	Mon, 17 Sep 2012 06:33: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:cc:subject
	:references:in-reply-to:content-type:content-transfer-encoding;
	bh=u+tY8D8SZxYqll2fOCc5v9FAaVhfMqm3d6gdERotmbE=;
	b=lbHj1UkiiGDK8YAqKdwAvKEq86xt02DimE3E/UQNeXGCrL1fDe6snz+OSaP38TXInA
	MVbsMzGo4d/qh1de+QmTwq3pIvUvYdPIUrjHHm17vw0KCGWRU7HenOpPxkSjteziXqBc
	JlZK5ukeFz26UVQJuGKoKftuFh2xxyT/koC/qzKGinq/B7luHQTfoCnNhkhnJ8mL3tzM
	azZW24lD4B0+eoKUcM8Apye8rqeJ9I0M9aB3PgxtBxtPIkHy48yWay6iHkTk65J6ySNs
	jpRQcQkRegusNRdKALH+22koMon1k9c9drLKZyL7Wp6j+WDlgAsWNOzzPEYsEDKnwSDi
	mQlA==
Received: by 10.182.118.41 with SMTP id kj9mr11646840obb.57.1347888791258;
	Mon, 17 Sep 2012 06:33:11 -0700 (PDT)
Received: from [192.168.1.103] (65-36-73-129.dyn.grandenetworks.net.
	[65.36.73.129])
	by mx.google.com with ESMTPS id ac10sm10710997obc.7.2012.09.17.06.33.09
	(version=SSLv3 cipher=OTHER); Mon, 17 Sep 2012 06:33:10 -0700 (PDT)
Message-ID: <50572692.1090805@gmail.com>
Date: Mon, 17 Sep 2012 08:33:06 -0500
From: Rob Herring <robherring2@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:14.0) Gecko/20120714 Thunderbird/14.0
MIME-Version: 1.0
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.02.1209141145150.29232@kaball.uk.xensource.com>
	<1347621207-11294-6-git-send-email-stefano.stabellini@eu.citrix.com>
	<20120914130151.GH25249@phenom.dumpdata.com>
	<alpine.DEB.2.02.1209141514590.29232@kaball.uk.xensource.com>
In-Reply-To: <alpine.DEB.2.02.1209141514590.29232@kaball.uk.xensource.com>
X-Mailman-Approved-At: Mon, 17 Sep 2012 14:11:13 +0000
Cc: Dave Martin <dave.martin@linaro.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linaro-dev@lists.linaro.org" <linaro-dev@lists.linaro.org>,
	Ian Campbell <Ian.Campbell@citrix.com>, "arnd@arndb.de" <arnd@arndb.de>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"catalin.marinas@arm.com" <catalin.marinas@arm.com>,
	"devicetree-discuss@lists.ozlabs.org"
	<devicetree-discuss@lists.ozlabs.org>, "Tim \(Xen.org\)" <tim@xen.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	David Vrabel <david.vrabel@citrix.com>,
	"linux@arm.linux.org.uk" <linux@arm.linux.org.uk>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Xen-devel] [PATCH v4 06/24] docs: Xen ARM DT bindings
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 09/14/2012 09:26 AM, Stefano Stabellini wrote:
> On Fri, 14 Sep 2012, Konrad Rzeszutek Wilk wrote:
>> On Fri, Sep 14, 2012 at 12:13:08PM +0100, Stefano Stabellini wrote:
>>> Add a doc to describe the Xen ARM device tree bindings
>>>
>>>
>>> Changes in v4:
>>>
>>> - "xen,xen" should be last as it is less specific;
>>> - update reg property using 2 address-cells and 2 size-cells.
>>>
>>>
>>> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
>>> CC: devicetree-discuss@lists.ozlabs.org
>>> CC: David Vrabel <david.vrabel@citrix.com>
>>> CC: Rob Herring <robherring2@gmail.com>
>>> CC: Dave Martin <dave.martin@linaro.org>
>>> ---
>>>  Documentation/devicetree/bindings/arm/xen.txt |   22 ++++++++++++++++++++++
>>>  1 files changed, 22 insertions(+), 0 deletions(-)
>>>  create mode 100644 Documentation/devicetree/bindings/arm/xen.txt
>>>
>>> diff --git a/Documentation/devicetree/bindings/arm/xen.txt b/Documentation/devicetree/bindings/arm/xen.txt
>>> new file mode 100644
>>> index 0000000..1f8f7d4
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/arm/xen.txt
>>> @@ -0,0 +1,22 @@
>>> +* Xen hypervisor device tree bindings
>>> +
>>> +Xen ARM virtual platforms shall have the following properties:
>>> +

State that they are part of top-level "hypervisor" node.

>>> +- compatible:
>>> +	compatible = "xen,xen-<version>", "xen,xen";
>>> +  where <version> is the version of the Xen ABI of the platform.
>>> +
>>> +- reg: specifies the base physical address and size of a region in
>>> +  memory where the grant table should be mapped to, using an
>>> +  HYPERVISOR_memory_op hypercall. 
>>> +
>>> +- interrupts: the interrupt used by Xen to inject event notifications.
>>
>> Its singular here.. but in the example its plurar. What if you use
>> multiple of the same number ("16 0xf")?
> 
> The "interrupts" property in the example below is a standard property to
> describe interrupts. We just happen to declare only one interrupt.
> 
> From the device tree point of view it would be possible to declare more
> than one interrupt here, but Xen only supports one really.
> 
> Regarding the three cells used in the example (<1 15 0xf08>), they have
> a specific meaning in the GIC context:
> 
> """
>   The 1st cell is the interrupt type; 0 for SPI interrupts, 1 for PPI
>   interrupts.
> 
>   The 2nd cell contains the interrupt number for the interrupt type.
>   SPI interrupts are in the range [0-987].  PPI interrupts are in the
>   range [0-15].
> 
>   The 3rd cell is the flags, encoded as follows:
> 	bits[3:0] trigger type and level flags.
> 		1 = low-to-high edge triggered
> 		2 = high-to-low edge triggered
> 		4 = active high level-sensitive
> 		8 = active low level-sensitive
> 	bits[15:8] PPI interrupt cpu mask.  Each bit corresponds to each of
> 	the 8 possible cpus attached to the GIC.  A bit set to '1' indicated
> 	the interrupt is wired to that CPU.  Only valid for PPI interrupts.
> """
> 
> So <1 15 0xf08> means the last PPI.

Since it is a PPI, it is handled differently than a normal interrupt.
That is fine, but you should somehow state that a GIC node is also required.

> 
>>> +
>>> +
>>> +Example:
>>> +
>>> +hypervisor {
>>> +	compatible = "xen,xen-4.3", "xen,xen";
>>> +	reg = <0 0xb0000000 0 0x20000>;
>>
>> So two grant tables?
>>
>> Hm, physical address is zero, and the size is 0xbignumber?
>> Or is the '0' denotating a seperator of arguments, so it is
>> 0xb000.. for physical address and 0x20000 for size?
> 
> from http://devicetree.org/Device_Tree_Usage:
> 
> "Each addressable device gets a reg which is a list of tuples in the
> form reg = <address1 length1 [address2 length2] [address3 length3] ...
> Each tuple represents an address range used by the device. Each address
> value is a list of one or more 32 bit integers called cells. Similarly,
> the length value can either be a list of cells, or empty."
> 
> In this case the address is: [0 0xb0000000], that means
> 0x00000000b0000000, and the length is [0 0x20000], that means
> 0x0000000000020000.

But the size depends on #size-cells and #address-cells. I would expect
those to be 1 for a 32-bit guest.

Rob


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 17 14:13:19 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 14:13:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDc4K-0000b8-80; Mon, 17 Sep 2012 14:13: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 1TDc4J-0000b0-K1
	for xen-devel@lists.xensource.com; Mon, 17 Sep 2012 14:12:59 +0000
Received: from [85.158.143.35:28138] by server-2.bemta-4.messagelabs.com id
	2B/F3-06610-AEF27505; Mon, 17 Sep 2012 14:12:58 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1347891177!18682284!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDk2NDU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4197 invoked from network); 17 Sep 2012 14:12:57 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Sep 2012 14:12:57 -0000
X-IronPort-AV: E=Sophos;i="4.80,435,1344211200"; d="scan'208";a="14582720"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Sep 2012 14:12: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.279.1; Mon, 17 Sep 2012 15:12:57 +0100
Date: Mon, 17 Sep 2012 15:12:11 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Rob Herring <robherring2@gmail.com>
In-Reply-To: <50572692.1090805@gmail.com>
Message-ID: <alpine.DEB.2.02.1209171508470.29232@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1209141145150.29232@kaball.uk.xensource.com>
	<1347621207-11294-6-git-send-email-stefano.stabellini@eu.citrix.com>
	<20120914130151.GH25249@phenom.dumpdata.com>
	<alpine.DEB.2.02.1209141514590.29232@kaball.uk.xensource.com>
	<50572692.1090805@gmail.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: Dave Martin <dave.martin@linaro.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linaro-dev@lists.linaro.org" <linaro-dev@lists.linaro.org>,
	Ian Campbell <Ian.Campbell@citrix.com>, "arnd@arndb.de" <arnd@arndb.de>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"catalin.marinas@arm.com" <catalin.marinas@arm.com>,
	"devicetree-discuss@lists.ozlabs.org"
	<devicetree-discuss@lists.ozlabs.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"Tim \(Xen.org\)" <tim@xen.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	David Vrabel <david.vrabel@citrix.com>,
	"linux@arm.linux.org.uk" <linux@arm.linux.org.uk>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Xen-devel] [PATCH v4 06/24] docs: Xen ARM DT bindings
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 17 Sep 2012, Rob Herring wrote:
> On 09/14/2012 09:26 AM, Stefano Stabellini wrote:
> > On Fri, 14 Sep 2012, Konrad Rzeszutek Wilk wrote:
> >> On Fri, Sep 14, 2012 at 12:13:08PM +0100, Stefano Stabellini wrote:
> >>> Add a doc to describe the Xen ARM device tree bindings
> >>>
> >>>
> >>> Changes in v4:
> >>>
> >>> - "xen,xen" should be last as it is less specific;
> >>> - update reg property using 2 address-cells and 2 size-cells.
> >>>
> >>>
> >>> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> >>> CC: devicetree-discuss@lists.ozlabs.org
> >>> CC: David Vrabel <david.vrabel@citrix.com>
> >>> CC: Rob Herring <robherring2@gmail.com>
> >>> CC: Dave Martin <dave.martin@linaro.org>
> >>> ---
> >>>  Documentation/devicetree/bindings/arm/xen.txt |   22 ++++++++++++++++++++++
> >>>  1 files changed, 22 insertions(+), 0 deletions(-)
> >>>  create mode 100644 Documentation/devicetree/bindings/arm/xen.txt
> >>>
> >>> diff --git a/Documentation/devicetree/bindings/arm/xen.txt b/Documentation/devicetree/bindings/arm/xen.txt
> >>> new file mode 100644
> >>> index 0000000..1f8f7d4
> >>> --- /dev/null
> >>> +++ b/Documentation/devicetree/bindings/arm/xen.txt
> >>> @@ -0,0 +1,22 @@
> >>> +* Xen hypervisor device tree bindings
> >>> +
> >>> +Xen ARM virtual platforms shall have the following properties:
> >>> +
> 
> State that they are part of top-level "hypervisor" node.

OK


> >>> +- compatible:
> >>> +	compatible = "xen,xen-<version>", "xen,xen";
> >>> +  where <version> is the version of the Xen ABI of the platform.
> >>> +
> >>> +- reg: specifies the base physical address and size of a region in
> >>> +  memory where the grant table should be mapped to, using an
> >>> +  HYPERVISOR_memory_op hypercall. 
> >>> +
> >>> +- interrupts: the interrupt used by Xen to inject event notifications.
> >>
> >> Its singular here.. but in the example its plurar. What if you use
> >> multiple of the same number ("16 0xf")?
> > 
> > The "interrupts" property in the example below is a standard property to
> > describe interrupts. We just happen to declare only one interrupt.
> > 
> > From the device tree point of view it would be possible to declare more
> > than one interrupt here, but Xen only supports one really.
> > 
> > Regarding the three cells used in the example (<1 15 0xf08>), they have
> > a specific meaning in the GIC context:
> > 
> > """
> >   The 1st cell is the interrupt type; 0 for SPI interrupts, 1 for PPI
> >   interrupts.
> > 
> >   The 2nd cell contains the interrupt number for the interrupt type.
> >   SPI interrupts are in the range [0-987].  PPI interrupts are in the
> >   range [0-15].
> > 
> >   The 3rd cell is the flags, encoded as follows:
> > 	bits[3:0] trigger type and level flags.
> > 		1 = low-to-high edge triggered
> > 		2 = high-to-low edge triggered
> > 		4 = active high level-sensitive
> > 		8 = active low level-sensitive
> > 	bits[15:8] PPI interrupt cpu mask.  Each bit corresponds to each of
> > 	the 8 possible cpus attached to the GIC.  A bit set to '1' indicated
> > 	the interrupt is wired to that CPU.  Only valid for PPI interrupts.
> > """
> > 
> > So <1 15 0xf08> means the last PPI.
> 
> Since it is a PPI, it is handled differently than a normal interrupt.
> That is fine, but you should somehow state that a GIC node is also required.

Yes, good idea


> >>> +
> >>> +
> >>> +Example:
> >>> +
> >>> +hypervisor {
> >>> +	compatible = "xen,xen-4.3", "xen,xen";
> >>> +	reg = <0 0xb0000000 0 0x20000>;
> >>
> >> So two grant tables?
> >>
> >> Hm, physical address is zero, and the size is 0xbignumber?
> >> Or is the '0' denotating a seperator of arguments, so it is
> >> 0xb000.. for physical address and 0x20000 for size?
> > 
> > from http://devicetree.org/Device_Tree_Usage:
> > 
> > "Each addressable device gets a reg which is a list of tuples in the
> > form reg = <address1 length1 [address2 length2] [address3 length3] ...
> > Each tuple represents an address range used by the device. Each address
> > value is a list of one or more 32 bit integers called cells. Similarly,
> > the length value can either be a list of cells, or empty."
> > 
> > In this case the address is: [0 0xb0000000], that means
> > 0x00000000b0000000, and the length is [0 0x20000], that means
> > 0x0000000000020000.
> 
> But the size depends on #size-cells and #address-cells. I would expect
> those to be 1 for a 32-bit guest.
 
I was looking at the Versatile Express DTS (vexpress-v2p-ca15-tc1.dts)
that on Linux v3.6-rc5 has:

#address-cells = <2>;
#size-cells = <2>;

What should I use for the example in this doc?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 17 14:13:19 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 14:13:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDc4K-0000b8-80; Mon, 17 Sep 2012 14:13: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 1TDc4J-0000b0-K1
	for xen-devel@lists.xensource.com; Mon, 17 Sep 2012 14:12:59 +0000
Received: from [85.158.143.35:28138] by server-2.bemta-4.messagelabs.com id
	2B/F3-06610-AEF27505; Mon, 17 Sep 2012 14:12:58 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1347891177!18682284!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDk2NDU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4197 invoked from network); 17 Sep 2012 14:12:57 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Sep 2012 14:12:57 -0000
X-IronPort-AV: E=Sophos;i="4.80,435,1344211200"; d="scan'208";a="14582720"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Sep 2012 14:12: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.279.1; Mon, 17 Sep 2012 15:12:57 +0100
Date: Mon, 17 Sep 2012 15:12:11 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Rob Herring <robherring2@gmail.com>
In-Reply-To: <50572692.1090805@gmail.com>
Message-ID: <alpine.DEB.2.02.1209171508470.29232@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1209141145150.29232@kaball.uk.xensource.com>
	<1347621207-11294-6-git-send-email-stefano.stabellini@eu.citrix.com>
	<20120914130151.GH25249@phenom.dumpdata.com>
	<alpine.DEB.2.02.1209141514590.29232@kaball.uk.xensource.com>
	<50572692.1090805@gmail.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: Dave Martin <dave.martin@linaro.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linaro-dev@lists.linaro.org" <linaro-dev@lists.linaro.org>,
	Ian Campbell <Ian.Campbell@citrix.com>, "arnd@arndb.de" <arnd@arndb.de>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"catalin.marinas@arm.com" <catalin.marinas@arm.com>,
	"devicetree-discuss@lists.ozlabs.org"
	<devicetree-discuss@lists.ozlabs.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"Tim \(Xen.org\)" <tim@xen.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	David Vrabel <david.vrabel@citrix.com>,
	"linux@arm.linux.org.uk" <linux@arm.linux.org.uk>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Xen-devel] [PATCH v4 06/24] docs: Xen ARM DT bindings
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 17 Sep 2012, Rob Herring wrote:
> On 09/14/2012 09:26 AM, Stefano Stabellini wrote:
> > On Fri, 14 Sep 2012, Konrad Rzeszutek Wilk wrote:
> >> On Fri, Sep 14, 2012 at 12:13:08PM +0100, Stefano Stabellini wrote:
> >>> Add a doc to describe the Xen ARM device tree bindings
> >>>
> >>>
> >>> Changes in v4:
> >>>
> >>> - "xen,xen" should be last as it is less specific;
> >>> - update reg property using 2 address-cells and 2 size-cells.
> >>>
> >>>
> >>> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> >>> CC: devicetree-discuss@lists.ozlabs.org
> >>> CC: David Vrabel <david.vrabel@citrix.com>
> >>> CC: Rob Herring <robherring2@gmail.com>
> >>> CC: Dave Martin <dave.martin@linaro.org>
> >>> ---
> >>>  Documentation/devicetree/bindings/arm/xen.txt |   22 ++++++++++++++++++++++
> >>>  1 files changed, 22 insertions(+), 0 deletions(-)
> >>>  create mode 100644 Documentation/devicetree/bindings/arm/xen.txt
> >>>
> >>> diff --git a/Documentation/devicetree/bindings/arm/xen.txt b/Documentation/devicetree/bindings/arm/xen.txt
> >>> new file mode 100644
> >>> index 0000000..1f8f7d4
> >>> --- /dev/null
> >>> +++ b/Documentation/devicetree/bindings/arm/xen.txt
> >>> @@ -0,0 +1,22 @@
> >>> +* Xen hypervisor device tree bindings
> >>> +
> >>> +Xen ARM virtual platforms shall have the following properties:
> >>> +
> 
> State that they are part of top-level "hypervisor" node.

OK


> >>> +- compatible:
> >>> +	compatible = "xen,xen-<version>", "xen,xen";
> >>> +  where <version> is the version of the Xen ABI of the platform.
> >>> +
> >>> +- reg: specifies the base physical address and size of a region in
> >>> +  memory where the grant table should be mapped to, using an
> >>> +  HYPERVISOR_memory_op hypercall. 
> >>> +
> >>> +- interrupts: the interrupt used by Xen to inject event notifications.
> >>
> >> Its singular here.. but in the example its plurar. What if you use
> >> multiple of the same number ("16 0xf")?
> > 
> > The "interrupts" property in the example below is a standard property to
> > describe interrupts. We just happen to declare only one interrupt.
> > 
> > From the device tree point of view it would be possible to declare more
> > than one interrupt here, but Xen only supports one really.
> > 
> > Regarding the three cells used in the example (<1 15 0xf08>), they have
> > a specific meaning in the GIC context:
> > 
> > """
> >   The 1st cell is the interrupt type; 0 for SPI interrupts, 1 for PPI
> >   interrupts.
> > 
> >   The 2nd cell contains the interrupt number for the interrupt type.
> >   SPI interrupts are in the range [0-987].  PPI interrupts are in the
> >   range [0-15].
> > 
> >   The 3rd cell is the flags, encoded as follows:
> > 	bits[3:0] trigger type and level flags.
> > 		1 = low-to-high edge triggered
> > 		2 = high-to-low edge triggered
> > 		4 = active high level-sensitive
> > 		8 = active low level-sensitive
> > 	bits[15:8] PPI interrupt cpu mask.  Each bit corresponds to each of
> > 	the 8 possible cpus attached to the GIC.  A bit set to '1' indicated
> > 	the interrupt is wired to that CPU.  Only valid for PPI interrupts.
> > """
> > 
> > So <1 15 0xf08> means the last PPI.
> 
> Since it is a PPI, it is handled differently than a normal interrupt.
> That is fine, but you should somehow state that a GIC node is also required.

Yes, good idea


> >>> +
> >>> +
> >>> +Example:
> >>> +
> >>> +hypervisor {
> >>> +	compatible = "xen,xen-4.3", "xen,xen";
> >>> +	reg = <0 0xb0000000 0 0x20000>;
> >>
> >> So two grant tables?
> >>
> >> Hm, physical address is zero, and the size is 0xbignumber?
> >> Or is the '0' denotating a seperator of arguments, so it is
> >> 0xb000.. for physical address and 0x20000 for size?
> > 
> > from http://devicetree.org/Device_Tree_Usage:
> > 
> > "Each addressable device gets a reg which is a list of tuples in the
> > form reg = <address1 length1 [address2 length2] [address3 length3] ...
> > Each tuple represents an address range used by the device. Each address
> > value is a list of one or more 32 bit integers called cells. Similarly,
> > the length value can either be a list of cells, or empty."
> > 
> > In this case the address is: [0 0xb0000000], that means
> > 0x00000000b0000000, and the length is [0 0x20000], that means
> > 0x0000000000020000.
> 
> But the size depends on #size-cells and #address-cells. I would expect
> those to be 1 for a 32-bit guest.
 
I was looking at the Versatile Express DTS (vexpress-v2p-ca15-tc1.dts)
that on Linux v3.6-rc5 has:

#address-cells = <2>;
#size-cells = <2>;

What should I use for the example in this doc?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 17 14:13:54 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 14:13:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDc4x-0000fn-R2; Mon, 17 Sep 2012 14:13: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 1TDc4w-0000fc-JO
	for xen-devel@lists.xensource.com; Mon, 17 Sep 2012 14:13:38 +0000
Received: from [85.158.143.35:30417] by server-3.bemta-4.messagelabs.com id
	ED/B1-08232-11037505; Mon, 17 Sep 2012 14:13:37 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1347891216!13943243!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzQ1MDU4\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23205 invoked from network); 17 Sep 2012 14:13: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; 17 Sep 2012 14:13:37 -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 q8HEDKN9020775
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 17 Sep 2012 14:13: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
	q8HEDJp8004991
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 17 Sep 2012 14:13:20 GMT
Received: from abhmt105.oracle.com (abhmt105.oracle.com [141.146.116.57])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q8HEDJT8008013; Mon, 17 Sep 2012 09:13:19 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 17 Sep 2012 07:13:19 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 2F7A54032B; Mon, 17 Sep 2012 10:02:32 -0400 (EDT)
Date: Mon, 17 Sep 2012 10:02:32 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Sergei Shtylyov <sshtylyov@mvista.com>
Message-ID: <20120917140232.GA11996@phenom.dumpdata.com>
References: <alpine.DEB.2.02.1209141145150.29232@kaball.uk.xensource.com>
	<1347621207-11294-12-git-send-email-stefano.stabellini@eu.citrix.com>
	<505374E2.5080308@mvista.com>
	<alpine.DEB.2.02.1209171155010.29232@kaball.uk.xensource.com>
	<50571289.3040509@mvista.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <50571289.3040509@mvista.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>,
	"linaro-dev@lists.linaro.org" <linaro-dev@lists.linaro.org>,
	Ian Campbell <Ian.Campbell@citrix.com>, "arnd@arndb.de" <arnd@arndb.de>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	"catalin.marinas@arm.com" <catalin.marinas@arm.com>,
	"Tim \(Xen.org\)" <tim@xen.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux@arm.linux.org.uk" <linux@arm.linux.org.uk>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Xen-devel] [PATCH v4 12/24] xen/arm: introduce CONFIG_XEN on
	ARM
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Sep 17, 2012 at 04:07:37PM +0400, Sergei Shtylyov wrote:
> Hello.
> 
> On 17-09-2012 14:57, Stefano Stabellini wrote:
> 
> >>>Changes in v2:
> 
> >>>- mark Xen guest support on ARM as EXPERIMENTAL.
> 
> >>>Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> >>>Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> >>>---
> >>>  arch/arm/Kconfig |   10 ++++++++++
> >>>  1 files changed, 10 insertions(+), 0 deletions(-)
> 
> >>>diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> >>>index 2f88d8d..e92518d 100644
> >>>--- a/arch/arm/Kconfig
> >>>+++ b/arch/arm/Kconfig
> >>>@@ -1897,6 +1897,16 @@ config DEPRECATED_PARAM_STRUCT
> >>>  	  This was deprecated in 2001 and announced to live on for 5 years.
> >>>  	  Some old boot loaders still use this way.
> >>>
> >>>+config XEN_DOM0
> >>>+	def_bool y
> >>>+
> >>>+config XEN
> >>>+	bool "Xen guest support on ARM (EXPERIMENTAL)"
> >>>+	depends on EXPERIMENTAL && ARM && OF

I think the CONFIG_EXPERIMENTAL is going away. Or it has already
gone away?

> >>>+	select XEN_DOM0
> 
> >>    What's the point of selecting it if it's always "y"?
> 
> >That's because on X86 is not always "y": there are things under
> >drivers/xen that compile on both platforms and depend on XEN_DOM0.
> 
>    But we're not on x86. On ARM this select is pointless.

Sure, but parts of the generic Xen (drivers/xen) code functionality has checks
for that (CONFIG_DOM0) to use some functionality that is not neccessarily
considered "dom0" specific for ARM.

The right way is to seperate those to be more of a 'backend' config and
'frontend' config. But those CONFIG options are a maze and I figured I
will fix this Gordon knot once this is all accepted/compiled/works, and then
slowly untangle the CONFIG-mess.

> 
> WBR, Sergei

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 17 14:13:54 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 14:13:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDc4x-0000fn-R2; Mon, 17 Sep 2012 14:13: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 1TDc4w-0000fc-JO
	for xen-devel@lists.xensource.com; Mon, 17 Sep 2012 14:13:38 +0000
Received: from [85.158.143.35:30417] by server-3.bemta-4.messagelabs.com id
	ED/B1-08232-11037505; Mon, 17 Sep 2012 14:13:37 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1347891216!13943243!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzQ1MDU4\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23205 invoked from network); 17 Sep 2012 14:13: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; 17 Sep 2012 14:13:37 -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 q8HEDKN9020775
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 17 Sep 2012 14:13: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
	q8HEDJp8004991
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 17 Sep 2012 14:13:20 GMT
Received: from abhmt105.oracle.com (abhmt105.oracle.com [141.146.116.57])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q8HEDJT8008013; Mon, 17 Sep 2012 09:13:19 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 17 Sep 2012 07:13:19 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 2F7A54032B; Mon, 17 Sep 2012 10:02:32 -0400 (EDT)
Date: Mon, 17 Sep 2012 10:02:32 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Sergei Shtylyov <sshtylyov@mvista.com>
Message-ID: <20120917140232.GA11996@phenom.dumpdata.com>
References: <alpine.DEB.2.02.1209141145150.29232@kaball.uk.xensource.com>
	<1347621207-11294-12-git-send-email-stefano.stabellini@eu.citrix.com>
	<505374E2.5080308@mvista.com>
	<alpine.DEB.2.02.1209171155010.29232@kaball.uk.xensource.com>
	<50571289.3040509@mvista.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <50571289.3040509@mvista.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>,
	"linaro-dev@lists.linaro.org" <linaro-dev@lists.linaro.org>,
	Ian Campbell <Ian.Campbell@citrix.com>, "arnd@arndb.de" <arnd@arndb.de>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	"catalin.marinas@arm.com" <catalin.marinas@arm.com>,
	"Tim \(Xen.org\)" <tim@xen.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux@arm.linux.org.uk" <linux@arm.linux.org.uk>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Xen-devel] [PATCH v4 12/24] xen/arm: introduce CONFIG_XEN on
	ARM
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Sep 17, 2012 at 04:07:37PM +0400, Sergei Shtylyov wrote:
> Hello.
> 
> On 17-09-2012 14:57, Stefano Stabellini wrote:
> 
> >>>Changes in v2:
> 
> >>>- mark Xen guest support on ARM as EXPERIMENTAL.
> 
> >>>Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> >>>Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> >>>---
> >>>  arch/arm/Kconfig |   10 ++++++++++
> >>>  1 files changed, 10 insertions(+), 0 deletions(-)
> 
> >>>diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> >>>index 2f88d8d..e92518d 100644
> >>>--- a/arch/arm/Kconfig
> >>>+++ b/arch/arm/Kconfig
> >>>@@ -1897,6 +1897,16 @@ config DEPRECATED_PARAM_STRUCT
> >>>  	  This was deprecated in 2001 and announced to live on for 5 years.
> >>>  	  Some old boot loaders still use this way.
> >>>
> >>>+config XEN_DOM0
> >>>+	def_bool y
> >>>+
> >>>+config XEN
> >>>+	bool "Xen guest support on ARM (EXPERIMENTAL)"
> >>>+	depends on EXPERIMENTAL && ARM && OF

I think the CONFIG_EXPERIMENTAL is going away. Or it has already
gone away?

> >>>+	select XEN_DOM0
> 
> >>    What's the point of selecting it if it's always "y"?
> 
> >That's because on X86 is not always "y": there are things under
> >drivers/xen that compile on both platforms and depend on XEN_DOM0.
> 
>    But we're not on x86. On ARM this select is pointless.

Sure, but parts of the generic Xen (drivers/xen) code functionality has checks
for that (CONFIG_DOM0) to use some functionality that is not neccessarily
considered "dom0" specific for ARM.

The right way is to seperate those to be more of a 'backend' config and
'frontend' config. But those CONFIG options are a maze and I figured I
will fix this Gordon knot once this is all accepted/compiled/works, and then
slowly untangle the CONFIG-mess.

> 
> WBR, Sergei

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 17 14:17:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 14:17:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDc8j-0000xU-GS; Mon, 17 Sep 2012 14:17:33 +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 1TDc8h-0000xJ-Gy
	for xen-devel@lists.xensource.com; Mon, 17 Sep 2012 14:17:31 +0000
Received: from [85.158.137.99:2161] by server-5.bemta-3.messagelabs.com id
	C2/92-13133-AF037505; Mon, 17 Sep 2012 14:17:30 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-14.tower-217.messagelabs.com!1347891450!17988961!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDk2NDU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26785 invoked from network); 17 Sep 2012 14:17:30 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Sep 2012 14:17:30 -0000
X-IronPort-AV: E=Sophos;i="4.80,435,1344211200"; d="scan'208";a="14582830"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Sep 2012 14:17: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.279.1; Mon, 17 Sep 2012 15:17:30 +0100
Date: Mon, 17 Sep 2012 15:16:44 +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: <20120917140232.GA11996@phenom.dumpdata.com>
Message-ID: <alpine.DEB.2.02.1209171515420.29232@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1209141145150.29232@kaball.uk.xensource.com>
	<1347621207-11294-12-git-send-email-stefano.stabellini@eu.citrix.com>
	<505374E2.5080308@mvista.com>
	<alpine.DEB.2.02.1209171155010.29232@kaball.uk.xensource.com>
	<50571289.3040509@mvista.com>
	<20120917140232.GA11996@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>,
	"linaro-dev@lists.linaro.org" <linaro-dev@lists.linaro.org>,
	Ian Campbell <Ian.Campbell@citrix.com>, "arnd@arndb.de" <arnd@arndb.de>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"catalin.marinas@arm.com" <catalin.marinas@arm.com>,
	"Tim \(Xen.org\)" <tim@xen.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>,
	"linux@arm.linux.org.uk" <linux@arm.linux.org.uk>,
	Sergei Shtylyov <sshtylyov@mvista.com>
Subject: Re: [Xen-devel] [PATCH v4 12/24] xen/arm: introduce CONFIG_XEN on
	ARM
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 17 Sep 2012, Konrad Rzeszutek Wilk wrote:
> On Mon, Sep 17, 2012 at 04:07:37PM +0400, Sergei Shtylyov wrote:
> > Hello.
> > 
> > On 17-09-2012 14:57, Stefano Stabellini wrote:
> > 
> > >>>Changes in v2:
> > 
> > >>>- mark Xen guest support on ARM as EXPERIMENTAL.
> > 
> > >>>Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> > >>>Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> > >>>---
> > >>>  arch/arm/Kconfig |   10 ++++++++++
> > >>>  1 files changed, 10 insertions(+), 0 deletions(-)
> > 
> > >>>diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> > >>>index 2f88d8d..e92518d 100644
> > >>>--- a/arch/arm/Kconfig
> > >>>+++ b/arch/arm/Kconfig
> > >>>@@ -1897,6 +1897,16 @@ config DEPRECATED_PARAM_STRUCT
> > >>>  	  This was deprecated in 2001 and announced to live on for 5 years.
> > >>>  	  Some old boot loaders still use this way.
> > >>>
> > >>>+config XEN_DOM0
> > >>>+	def_bool y
> > >>>+
> > >>>+config XEN
> > >>>+	bool "Xen guest support on ARM (EXPERIMENTAL)"
> > >>>+	depends on EXPERIMENTAL && ARM && OF
> 
> I think the CONFIG_EXPERIMENTAL is going away. Or it has already
> gone away?

I would like to keep it for Linux v3.6, because the Xen ABI offered by
Xen 4.2 hasn't been declared stable yet.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 17 14:17:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 14:17:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDc8j-0000xU-GS; Mon, 17 Sep 2012 14:17:33 +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 1TDc8h-0000xJ-Gy
	for xen-devel@lists.xensource.com; Mon, 17 Sep 2012 14:17:31 +0000
Received: from [85.158.137.99:2161] by server-5.bemta-3.messagelabs.com id
	C2/92-13133-AF037505; Mon, 17 Sep 2012 14:17:30 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-14.tower-217.messagelabs.com!1347891450!17988961!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDk2NDU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26785 invoked from network); 17 Sep 2012 14:17:30 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Sep 2012 14:17:30 -0000
X-IronPort-AV: E=Sophos;i="4.80,435,1344211200"; d="scan'208";a="14582830"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Sep 2012 14:17: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.279.1; Mon, 17 Sep 2012 15:17:30 +0100
Date: Mon, 17 Sep 2012 15:16:44 +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: <20120917140232.GA11996@phenom.dumpdata.com>
Message-ID: <alpine.DEB.2.02.1209171515420.29232@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1209141145150.29232@kaball.uk.xensource.com>
	<1347621207-11294-12-git-send-email-stefano.stabellini@eu.citrix.com>
	<505374E2.5080308@mvista.com>
	<alpine.DEB.2.02.1209171155010.29232@kaball.uk.xensource.com>
	<50571289.3040509@mvista.com>
	<20120917140232.GA11996@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>,
	"linaro-dev@lists.linaro.org" <linaro-dev@lists.linaro.org>,
	Ian Campbell <Ian.Campbell@citrix.com>, "arnd@arndb.de" <arnd@arndb.de>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"catalin.marinas@arm.com" <catalin.marinas@arm.com>,
	"Tim \(Xen.org\)" <tim@xen.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>,
	"linux@arm.linux.org.uk" <linux@arm.linux.org.uk>,
	Sergei Shtylyov <sshtylyov@mvista.com>
Subject: Re: [Xen-devel] [PATCH v4 12/24] xen/arm: introduce CONFIG_XEN on
	ARM
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 17 Sep 2012, Konrad Rzeszutek Wilk wrote:
> On Mon, Sep 17, 2012 at 04:07:37PM +0400, Sergei Shtylyov wrote:
> > Hello.
> > 
> > On 17-09-2012 14:57, Stefano Stabellini wrote:
> > 
> > >>>Changes in v2:
> > 
> > >>>- mark Xen guest support on ARM as EXPERIMENTAL.
> > 
> > >>>Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> > >>>Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> > >>>---
> > >>>  arch/arm/Kconfig |   10 ++++++++++
> > >>>  1 files changed, 10 insertions(+), 0 deletions(-)
> > 
> > >>>diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> > >>>index 2f88d8d..e92518d 100644
> > >>>--- a/arch/arm/Kconfig
> > >>>+++ b/arch/arm/Kconfig
> > >>>@@ -1897,6 +1897,16 @@ config DEPRECATED_PARAM_STRUCT
> > >>>  	  This was deprecated in 2001 and announced to live on for 5 years.
> > >>>  	  Some old boot loaders still use this way.
> > >>>
> > >>>+config XEN_DOM0
> > >>>+	def_bool y
> > >>>+
> > >>>+config XEN
> > >>>+	bool "Xen guest support on ARM (EXPERIMENTAL)"
> > >>>+	depends on EXPERIMENTAL && ARM && OF
> 
> I think the CONFIG_EXPERIMENTAL is going away. Or it has already
> gone away?

I would like to keep it for Linux v3.6, because the Xen ABI offered by
Xen 4.2 hasn't been declared stable yet.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 17 14:18:20 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 14:18:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDc9K-00011A-0D; Mon, 17 Sep 2012 14:18:10 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1TDc9I-00010n-HN
	for xen-devel@lists.xensource.com; Mon, 17 Sep 2012 14:18:08 +0000
Received: from [85.158.143.99:5014] by server-2.bemta-4.messagelabs.com id
	0D/4C-06610-F1137505; Mon, 17 Sep 2012 14:18:07 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1347891485!24563030!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDc1NTA4Mg==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16446 invoked from network); 17 Sep 2012 14:18:07 -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; 17 Sep 2012 14:18:07 -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 q8HEHhe1023586
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 17 Sep 2012 14:17:44 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
	q8HEHgUX014377
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 17 Sep 2012 14:17:43 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
	q8HEHedX018872; Mon, 17 Sep 2012 09:17:40 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 17 Sep 2012 07:17:40 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id BA9634032B; Mon, 17 Sep 2012 10:06:53 -0400 (EDT)
Date: Mon, 17 Sep 2012 10:06:53 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20120917140653.GB11996@phenom.dumpdata.com>
References: <alpine.DEB.2.02.1209141145150.29232@kaball.uk.xensource.com>
	<1347621207-11294-10-git-send-email-stefano.stabellini@eu.citrix.com>
	<20120917132932.GA11517@phenom.dumpdata.com>
	<alpine.DEB.2.02.1209171444060.29232@kaball.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <alpine.DEB.2.02.1209171444060.29232@kaball.uk.xensource.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linaro-dev@lists.linaro.org" <linaro-dev@lists.linaro.org>,
	Ian Campbell <Ian.Campbell@citrix.com>, "arnd@arndb.de" <arnd@arndb.de>,
	"catalin.marinas@arm.com" <catalin.marinas@arm.com>,
	"Tim \(Xen.org\)" <tim@xen.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux@arm.linux.org.uk" <linux@arm.linux.org.uk>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Xen-devel] [PATCH v4 10/24] xen/arm: compile and run xenbus
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Sep 17, 2012 at 02:45:00PM +0100, Stefano Stabellini wrote:
> On Mon, 17 Sep 2012, Konrad Rzeszutek Wilk wrote:
> > On Fri, Sep 14, 2012 at 12:13:12PM +0100, Stefano Stabellini wrote:
> > > bind_evtchn_to_irqhandler can legitimately return 0 (irq 0): it is not
> > > an error.
> > > 
> > > If Linux is running as an HVM domain and is running as Dom0, use
> > > xenstored_local_init to initialize the xenstore page and event channel.
> > > 
> > > 
> > > Changes in v4:
> > > 
> > > - do not xs_reset_watches on dom0.
> > > 
> > > 
> > > Changes in v2:
> > > 
> > > - refactor xenbus_init.
> > > 
> > > Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> > 
> > Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> > 
> > 
> > If you would like I can also carry this in my tree.
> 
> OK, let's do that. I'll rebase again on your tree with this patch.

Done.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 17 14:18:20 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 14:18:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDc9K-00011A-0D; Mon, 17 Sep 2012 14:18:10 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1TDc9I-00010n-HN
	for xen-devel@lists.xensource.com; Mon, 17 Sep 2012 14:18:08 +0000
Received: from [85.158.143.99:5014] by server-2.bemta-4.messagelabs.com id
	0D/4C-06610-F1137505; Mon, 17 Sep 2012 14:18:07 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1347891485!24563030!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDc1NTA4Mg==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16446 invoked from network); 17 Sep 2012 14:18:07 -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; 17 Sep 2012 14:18:07 -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 q8HEHhe1023586
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 17 Sep 2012 14:17:44 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
	q8HEHgUX014377
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 17 Sep 2012 14:17:43 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
	q8HEHedX018872; Mon, 17 Sep 2012 09:17:40 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 17 Sep 2012 07:17:40 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id BA9634032B; Mon, 17 Sep 2012 10:06:53 -0400 (EDT)
Date: Mon, 17 Sep 2012 10:06:53 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20120917140653.GB11996@phenom.dumpdata.com>
References: <alpine.DEB.2.02.1209141145150.29232@kaball.uk.xensource.com>
	<1347621207-11294-10-git-send-email-stefano.stabellini@eu.citrix.com>
	<20120917132932.GA11517@phenom.dumpdata.com>
	<alpine.DEB.2.02.1209171444060.29232@kaball.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <alpine.DEB.2.02.1209171444060.29232@kaball.uk.xensource.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linaro-dev@lists.linaro.org" <linaro-dev@lists.linaro.org>,
	Ian Campbell <Ian.Campbell@citrix.com>, "arnd@arndb.de" <arnd@arndb.de>,
	"catalin.marinas@arm.com" <catalin.marinas@arm.com>,
	"Tim \(Xen.org\)" <tim@xen.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux@arm.linux.org.uk" <linux@arm.linux.org.uk>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Xen-devel] [PATCH v4 10/24] xen/arm: compile and run xenbus
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Sep 17, 2012 at 02:45:00PM +0100, Stefano Stabellini wrote:
> On Mon, 17 Sep 2012, Konrad Rzeszutek Wilk wrote:
> > On Fri, Sep 14, 2012 at 12:13:12PM +0100, Stefano Stabellini wrote:
> > > bind_evtchn_to_irqhandler can legitimately return 0 (irq 0): it is not
> > > an error.
> > > 
> > > If Linux is running as an HVM domain and is running as Dom0, use
> > > xenstored_local_init to initialize the xenstore page and event channel.
> > > 
> > > 
> > > Changes in v4:
> > > 
> > > - do not xs_reset_watches on dom0.
> > > 
> > > 
> > > Changes in v2:
> > > 
> > > - refactor xenbus_init.
> > > 
> > > Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> > 
> > Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> > 
> > 
> > If you would like I can also carry this in my tree.
> 
> OK, let's do that. I'll rebase again on your tree with this patch.

Done.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 17 14:31:37 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 14:31: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 1TDcM2-0001IQ-G2; Mon, 17 Sep 2012 14:31:18 +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 1TDcM0-0001IL-O7
	for xen-devel@lists.xensource.com; Mon, 17 Sep 2012 14:31:16 +0000
Received: from [85.158.138.51:52073] by server-10.bemta-3.messagelabs.com id
	5C/CE-10411-33437505; Mon, 17 Sep 2012 14:31:15 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1347892274!30838728!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDk2NDU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25564 invoked from network); 17 Sep 2012 14:31:15 -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;
	17 Sep 2012 14:31:15 -0000
X-IronPort-AV: E=Sophos;i="4.80,435,1344211200"; d="scan'208";a="14583396"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Sep 2012 14:31: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.279.1; Mon, 17 Sep 2012 15:31:14 +0100
Date: Mon, 17 Sep 2012 15:30:28 +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.1209171454480.29232@kaball.uk.xensource.com>
Message-ID: <alpine.DEB.2.02.1209171527210.29232@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1209141145150.29232@kaball.uk.xensource.com>
	<1347621207-11294-12-git-send-email-stefano.stabellini@eu.citrix.com>
	<505374E2.5080308@mvista.com>
	<alpine.DEB.2.02.1209171155010.29232@kaball.uk.xensource.com>
	<50571289.3040509@mvista.com>
	<alpine.DEB.2.02.1209171454480.29232@kaball.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>,
	"linaro-dev@lists.linaro.org" <linaro-dev@lists.linaro.org>,
	Sergei Shtylyov <sshtylyov@mvista.com>, "arnd@arndb.de" <arnd@arndb.de>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
	"catalin.marinas@arm.com" <catalin.marinas@arm.com>,
	"Tim \(Xen.org\)" <tim@xen.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux@arm.linux.org.uk" <linux@arm.linux.org.uk>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH v4 12/24] xen/arm: introduce CONFIG_XEN on
	ARM
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 17 Sep 2012, Stefano Stabellini wrote:
> On Mon, 17 Sep 2012, Sergei Shtylyov wrote:
> > Hello.
> > 
> > On 17-09-2012 14:57, Stefano Stabellini wrote:
> > 
> > >>> Changes in v2:
> > 
> > >>> - mark Xen guest support on ARM as EXPERIMENTAL.
> > 
> > >>> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> > >>> Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> > >>> ---
> > >>>   arch/arm/Kconfig |   10 ++++++++++
> > >>>   1 files changed, 10 insertions(+), 0 deletions(-)
> > 
> > >>> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> > >>> index 2f88d8d..e92518d 100644
> > >>> --- a/arch/arm/Kconfig
> > >>> +++ b/arch/arm/Kconfig
> > >>> @@ -1897,6 +1897,16 @@ config DEPRECATED_PARAM_STRUCT
> > >>>   	  This was deprecated in 2001 and announced to live on for 5 years.
> > >>>   	  Some old boot loaders still use this way.
> > >>>
> > >>> +config XEN_DOM0
> > >>> +	def_bool y
> > >>> +
> > >>> +config XEN
> > >>> +	bool "Xen guest support on ARM (EXPERIMENTAL)"
> > >>> +	depends on EXPERIMENTAL && ARM && OF
> > >>> +	select XEN_DOM0
> > 
> > >>     What's the point of selecting it if it's always "y"?
> > 
> > > That's because on X86 is not always "y": there are things under
> > > drivers/xen that compile on both platforms and depend on XEN_DOM0.
> > 
> >     But we're not on x86. On ARM this select is pointless.
> 
> We need some common code (under drivers/xen) that compiles only if
> XEN_DOM0 is selected, so it is not pointless after all.
> 
> XEN_DOM0 is not the only symbol that is conditionally compiled on one
> architectuire and always "y" on another...
> 

Wait a sec, I have just realized that written this way XEN_DOM0 is
always "y", even if XEN is not!
The right way of doing this is:


config XEN_DOM0
	def_bool y
	depends on XEN

config XEN
	bool "Xen guest support on ARM (EXPERIMENTAL)"
	depends on EXPERIMENTAL && ARM && OF
	help
	  Say Y if you want to run Linux in a Virtual Machine on Xen on ARM.


I am not sure if this is what you meant, but thanks for making me
realize this mistake anyway! :)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 17 14:31:37 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 14:31: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 1TDcM2-0001IQ-G2; Mon, 17 Sep 2012 14:31:18 +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 1TDcM0-0001IL-O7
	for xen-devel@lists.xensource.com; Mon, 17 Sep 2012 14:31:16 +0000
Received: from [85.158.138.51:52073] by server-10.bemta-3.messagelabs.com id
	5C/CE-10411-33437505; Mon, 17 Sep 2012 14:31:15 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1347892274!30838728!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDk2NDU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25564 invoked from network); 17 Sep 2012 14:31:15 -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;
	17 Sep 2012 14:31:15 -0000
X-IronPort-AV: E=Sophos;i="4.80,435,1344211200"; d="scan'208";a="14583396"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Sep 2012 14:31: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.279.1; Mon, 17 Sep 2012 15:31:14 +0100
Date: Mon, 17 Sep 2012 15:30:28 +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.1209171454480.29232@kaball.uk.xensource.com>
Message-ID: <alpine.DEB.2.02.1209171527210.29232@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1209141145150.29232@kaball.uk.xensource.com>
	<1347621207-11294-12-git-send-email-stefano.stabellini@eu.citrix.com>
	<505374E2.5080308@mvista.com>
	<alpine.DEB.2.02.1209171155010.29232@kaball.uk.xensource.com>
	<50571289.3040509@mvista.com>
	<alpine.DEB.2.02.1209171454480.29232@kaball.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>,
	"linaro-dev@lists.linaro.org" <linaro-dev@lists.linaro.org>,
	Sergei Shtylyov <sshtylyov@mvista.com>, "arnd@arndb.de" <arnd@arndb.de>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
	"catalin.marinas@arm.com" <catalin.marinas@arm.com>,
	"Tim \(Xen.org\)" <tim@xen.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux@arm.linux.org.uk" <linux@arm.linux.org.uk>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH v4 12/24] xen/arm: introduce CONFIG_XEN on
	ARM
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 17 Sep 2012, Stefano Stabellini wrote:
> On Mon, 17 Sep 2012, Sergei Shtylyov wrote:
> > Hello.
> > 
> > On 17-09-2012 14:57, Stefano Stabellini wrote:
> > 
> > >>> Changes in v2:
> > 
> > >>> - mark Xen guest support on ARM as EXPERIMENTAL.
> > 
> > >>> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> > >>> Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> > >>> ---
> > >>>   arch/arm/Kconfig |   10 ++++++++++
> > >>>   1 files changed, 10 insertions(+), 0 deletions(-)
> > 
> > >>> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> > >>> index 2f88d8d..e92518d 100644
> > >>> --- a/arch/arm/Kconfig
> > >>> +++ b/arch/arm/Kconfig
> > >>> @@ -1897,6 +1897,16 @@ config DEPRECATED_PARAM_STRUCT
> > >>>   	  This was deprecated in 2001 and announced to live on for 5 years.
> > >>>   	  Some old boot loaders still use this way.
> > >>>
> > >>> +config XEN_DOM0
> > >>> +	def_bool y
> > >>> +
> > >>> +config XEN
> > >>> +	bool "Xen guest support on ARM (EXPERIMENTAL)"
> > >>> +	depends on EXPERIMENTAL && ARM && OF
> > >>> +	select XEN_DOM0
> > 
> > >>     What's the point of selecting it if it's always "y"?
> > 
> > > That's because on X86 is not always "y": there are things under
> > > drivers/xen that compile on both platforms and depend on XEN_DOM0.
> > 
> >     But we're not on x86. On ARM this select is pointless.
> 
> We need some common code (under drivers/xen) that compiles only if
> XEN_DOM0 is selected, so it is not pointless after all.
> 
> XEN_DOM0 is not the only symbol that is conditionally compiled on one
> architectuire and always "y" on another...
> 

Wait a sec, I have just realized that written this way XEN_DOM0 is
always "y", even if XEN is not!
The right way of doing this is:


config XEN_DOM0
	def_bool y
	depends on XEN

config XEN
	bool "Xen guest support on ARM (EXPERIMENTAL)"
	depends on EXPERIMENTAL && ARM && OF
	help
	  Say Y if you want to run Linux in a Virtual Machine on Xen on ARM.


I am not sure if this is what you meant, but thanks for making me
realize this mistake anyway! :)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 17 14:34:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 14:34:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDcOt-0001PE-4k; Mon, 17 Sep 2012 14:34:15 +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 1TDcOr-0001P7-RG
	for xen-devel@lists.xensource.com; Mon, 17 Sep 2012 14:34:14 +0000
Received: from [85.158.143.99:8225] by server-1.bemta-4.messagelabs.com id
	D9/B5-12504-5E437505; Mon, 17 Sep 2012 14:34:13 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1347892451!19464515!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDc1NTA4Mg==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27626 invoked from network); 17 Sep 2012 14:34:12 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-16.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 17 Sep 2012 14:34: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 q8HEY3ow011150
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 17 Sep 2012 14:34:04 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
	q8HEY22Z016447
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 17 Sep 2012 14:34:03 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
	q8HEY2Lr020696; Mon, 17 Sep 2012 09:34:02 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 17 Sep 2012 07:34:02 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 9C0664032B; Mon, 17 Sep 2012 10:23:15 -0400 (EDT)
Date: Mon, 17 Sep 2012 10:23:15 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20120917142315.GA12541@phenom.dumpdata.com>
References: <1347306367-28669-1-git-send-email-konrad.wilk@oracle.com>
	<1347306367-28669-11-git-send-email-konrad.wilk@oracle.com>
	<alpine.DEB.2.02.1209141709580.29232@kaball.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <alpine.DEB.2.02.1209141709580.29232@kaball.uk.xensource.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [Xen-devel] [PATCH 10/10] xen/swiotlb: Depending on
 after_bootmem is not 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

> >  	start_dma_addr = xen_virt_to_bus(xen_io_tlb_start);
> > -	if (!after_bootmem)
> > +	rc = 0;
>      ^
> why does this change belong to this patch?
> 
> 

I took that out of the this patch, so it is now:


>From c5bc5502abc0f70b682c0f2a70d08e6319825163 Mon Sep 17 00:00:00 2001
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Wed, 5 Sep 2012 13:35:47 -0400
Subject: [PATCH 1/2] xen/swiotlb: Depending on after_bootmem is not correct.

When PCI IOMMUs are initialized it is after after_bootmem but
before a lot of "other" subsystems are initialized. As such
the check for after_bootmem is incorrect and we should
just use a parameter to define whether we are early or late.

This solves this bootup problem:

__ex_table already sorted, skipping sortM
Initializing CPU#0
Warning: only able to allocate 1 MB for software IO TLB
Xen-SWIOTLB: Lowering to 2MB
Warning: only able to allocate 1 MB for software IO TLB
Xen-SWIOTLB: Lowering to 2MB
Warning: only able to allocate 1 MB for software IO TLB
Xen-SWIOTLB: Lowering to 2MB
Warning: only able to allocate 1 MB for software IO TLB
Cannot allocate Xen-SWIOTLB buffer (rc:-12)

[v1: Had rc=0 in it by mistake]
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 arch/x86/xen/pci-swiotlb-xen.c |    4 ++--
 drivers/xen/swiotlb-xen.c      |   10 +++++-----
 include/xen/swiotlb-xen.h      |    2 +-
 3 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/arch/x86/xen/pci-swiotlb-xen.c b/arch/x86/xen/pci-swiotlb-xen.c
index fc0c78f..1608244 100644
--- a/arch/x86/xen/pci-swiotlb-xen.c
+++ b/arch/x86/xen/pci-swiotlb-xen.c
@@ -69,7 +69,7 @@ int __init pci_xen_swiotlb_detect(void)
 void __init pci_xen_swiotlb_init(void)
 {
 	if (xen_swiotlb) {
-		xen_swiotlb_init(1);
+		xen_swiotlb_init(1, true /* early */);
 		dma_ops = &xen_swiotlb_dma_ops;
 
 		/* Make sure ACS will be enabled */
@@ -84,7 +84,7 @@ int pci_xen_swiotlb_init_late(void)
 	if (xen_swiotlb)
 		return 0;
 
-	rc = xen_swiotlb_init(1);
+	rc = xen_swiotlb_init(1, false /* late */);
 	if (rc)
 		return rc;
 
diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
index 6f81994..02a52f3 100644
--- a/drivers/xen/swiotlb-xen.c
+++ b/drivers/xen/swiotlb-xen.c
@@ -176,7 +176,7 @@ static const char *xen_swiotlb_error(enum xen_swiotlb_err err)
 	}
 	return "";
 }
-int __ref xen_swiotlb_init(int verbose)
+int __ref xen_swiotlb_init(int verbose, bool early)
 {
 	unsigned long bytes, order;
 	int rc = -ENOMEM;
@@ -190,7 +190,7 @@ retry:
 	/*
 	 * Get IO TLB memory from any location.
 	 */
-	if (!after_bootmem)
+	if (early)
 		xen_io_tlb_start = alloc_bootmem_pages(PAGE_ALIGN(bytes));
 	else {
 #define SLABS_PER_PAGE (1 << (PAGE_SHIFT - IO_TLB_SHIFT))
@@ -220,7 +220,7 @@ retry:
 			       bytes,
 			       xen_io_tlb_nslabs);
 	if (rc) {
-		if (!after_bootmem)
+		if (early)
 			free_bootmem(__pa(xen_io_tlb_start), PAGE_ALIGN(bytes));
 		else {
 			free_pages((unsigned long)xen_io_tlb_start, order);
@@ -230,7 +230,7 @@ retry:
 		goto error;
 	}
 	start_dma_addr = xen_virt_to_bus(xen_io_tlb_start);
-	if (!after_bootmem)
+	if (early)
 		swiotlb_init_with_tbl(xen_io_tlb_start, xen_io_tlb_nslabs, verbose);
 	else
 		rc = swiotlb_late_init_with_tbl(xen_io_tlb_start, xen_io_tlb_nslabs);
@@ -244,7 +244,7 @@ error:
 		goto retry;
 	}
 	pr_err("%s (rc:%d)", xen_swiotlb_error(m_ret), rc);
-	if (!after_bootmem)
+	if (early)
 		panic("%s (rc:%d)", xen_swiotlb_error(m_ret), rc);
 	else
 		free_pages((unsigned long)xen_io_tlb_start, order);
diff --git a/include/xen/swiotlb-xen.h b/include/xen/swiotlb-xen.h
index a0db2b7..de8bcc6 100644
--- a/include/xen/swiotlb-xen.h
+++ b/include/xen/swiotlb-xen.h
@@ -3,7 +3,7 @@
 
 #include <linux/swiotlb.h>
 
-extern int xen_swiotlb_init(int verbose);
+extern int xen_swiotlb_init(int verbose, bool early);
 
 extern void
 *xen_swiotlb_alloc_coherent(struct device *hwdev, size_t size,
-- 
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 Sep 17 14:34:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 14:34:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDcOt-0001PE-4k; Mon, 17 Sep 2012 14:34:15 +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 1TDcOr-0001P7-RG
	for xen-devel@lists.xensource.com; Mon, 17 Sep 2012 14:34:14 +0000
Received: from [85.158.143.99:8225] by server-1.bemta-4.messagelabs.com id
	D9/B5-12504-5E437505; Mon, 17 Sep 2012 14:34:13 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1347892451!19464515!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDc1NTA4Mg==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27626 invoked from network); 17 Sep 2012 14:34:12 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-16.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 17 Sep 2012 14:34: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 q8HEY3ow011150
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 17 Sep 2012 14:34:04 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
	q8HEY22Z016447
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 17 Sep 2012 14:34:03 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
	q8HEY2Lr020696; Mon, 17 Sep 2012 09:34:02 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 17 Sep 2012 07:34:02 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 9C0664032B; Mon, 17 Sep 2012 10:23:15 -0400 (EDT)
Date: Mon, 17 Sep 2012 10:23:15 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20120917142315.GA12541@phenom.dumpdata.com>
References: <1347306367-28669-1-git-send-email-konrad.wilk@oracle.com>
	<1347306367-28669-11-git-send-email-konrad.wilk@oracle.com>
	<alpine.DEB.2.02.1209141709580.29232@kaball.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <alpine.DEB.2.02.1209141709580.29232@kaball.uk.xensource.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [Xen-devel] [PATCH 10/10] xen/swiotlb: Depending on
 after_bootmem is not 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

> >  	start_dma_addr = xen_virt_to_bus(xen_io_tlb_start);
> > -	if (!after_bootmem)
> > +	rc = 0;
>      ^
> why does this change belong to this patch?
> 
> 

I took that out of the this patch, so it is now:


>From c5bc5502abc0f70b682c0f2a70d08e6319825163 Mon Sep 17 00:00:00 2001
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Wed, 5 Sep 2012 13:35:47 -0400
Subject: [PATCH 1/2] xen/swiotlb: Depending on after_bootmem is not correct.

When PCI IOMMUs are initialized it is after after_bootmem but
before a lot of "other" subsystems are initialized. As such
the check for after_bootmem is incorrect and we should
just use a parameter to define whether we are early or late.

This solves this bootup problem:

__ex_table already sorted, skipping sortM
Initializing CPU#0
Warning: only able to allocate 1 MB for software IO TLB
Xen-SWIOTLB: Lowering to 2MB
Warning: only able to allocate 1 MB for software IO TLB
Xen-SWIOTLB: Lowering to 2MB
Warning: only able to allocate 1 MB for software IO TLB
Xen-SWIOTLB: Lowering to 2MB
Warning: only able to allocate 1 MB for software IO TLB
Cannot allocate Xen-SWIOTLB buffer (rc:-12)

[v1: Had rc=0 in it by mistake]
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 arch/x86/xen/pci-swiotlb-xen.c |    4 ++--
 drivers/xen/swiotlb-xen.c      |   10 +++++-----
 include/xen/swiotlb-xen.h      |    2 +-
 3 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/arch/x86/xen/pci-swiotlb-xen.c b/arch/x86/xen/pci-swiotlb-xen.c
index fc0c78f..1608244 100644
--- a/arch/x86/xen/pci-swiotlb-xen.c
+++ b/arch/x86/xen/pci-swiotlb-xen.c
@@ -69,7 +69,7 @@ int __init pci_xen_swiotlb_detect(void)
 void __init pci_xen_swiotlb_init(void)
 {
 	if (xen_swiotlb) {
-		xen_swiotlb_init(1);
+		xen_swiotlb_init(1, true /* early */);
 		dma_ops = &xen_swiotlb_dma_ops;
 
 		/* Make sure ACS will be enabled */
@@ -84,7 +84,7 @@ int pci_xen_swiotlb_init_late(void)
 	if (xen_swiotlb)
 		return 0;
 
-	rc = xen_swiotlb_init(1);
+	rc = xen_swiotlb_init(1, false /* late */);
 	if (rc)
 		return rc;
 
diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
index 6f81994..02a52f3 100644
--- a/drivers/xen/swiotlb-xen.c
+++ b/drivers/xen/swiotlb-xen.c
@@ -176,7 +176,7 @@ static const char *xen_swiotlb_error(enum xen_swiotlb_err err)
 	}
 	return "";
 }
-int __ref xen_swiotlb_init(int verbose)
+int __ref xen_swiotlb_init(int verbose, bool early)
 {
 	unsigned long bytes, order;
 	int rc = -ENOMEM;
@@ -190,7 +190,7 @@ retry:
 	/*
 	 * Get IO TLB memory from any location.
 	 */
-	if (!after_bootmem)
+	if (early)
 		xen_io_tlb_start = alloc_bootmem_pages(PAGE_ALIGN(bytes));
 	else {
 #define SLABS_PER_PAGE (1 << (PAGE_SHIFT - IO_TLB_SHIFT))
@@ -220,7 +220,7 @@ retry:
 			       bytes,
 			       xen_io_tlb_nslabs);
 	if (rc) {
-		if (!after_bootmem)
+		if (early)
 			free_bootmem(__pa(xen_io_tlb_start), PAGE_ALIGN(bytes));
 		else {
 			free_pages((unsigned long)xen_io_tlb_start, order);
@@ -230,7 +230,7 @@ retry:
 		goto error;
 	}
 	start_dma_addr = xen_virt_to_bus(xen_io_tlb_start);
-	if (!after_bootmem)
+	if (early)
 		swiotlb_init_with_tbl(xen_io_tlb_start, xen_io_tlb_nslabs, verbose);
 	else
 		rc = swiotlb_late_init_with_tbl(xen_io_tlb_start, xen_io_tlb_nslabs);
@@ -244,7 +244,7 @@ error:
 		goto retry;
 	}
 	pr_err("%s (rc:%d)", xen_swiotlb_error(m_ret), rc);
-	if (!after_bootmem)
+	if (early)
 		panic("%s (rc:%d)", xen_swiotlb_error(m_ret), rc);
 	else
 		free_pages((unsigned long)xen_io_tlb_start, order);
diff --git a/include/xen/swiotlb-xen.h b/include/xen/swiotlb-xen.h
index a0db2b7..de8bcc6 100644
--- a/include/xen/swiotlb-xen.h
+++ b/include/xen/swiotlb-xen.h
@@ -3,7 +3,7 @@
 
 #include <linux/swiotlb.h>
 
-extern int xen_swiotlb_init(int verbose);
+extern int xen_swiotlb_init(int verbose, bool early);
 
 extern void
 *xen_swiotlb_alloc_coherent(struct device *hwdev, size_t size,
-- 
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 Sep 17 14:36:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 14:36: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 1TDcQX-0001XD-Lv; Mon, 17 Sep 2012 14:35:57 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1TDcQW-0001X1-Rq
	for xen-devel@lists.xensource.com; Mon, 17 Sep 2012 14:35:57 +0000
Received: from [85.158.143.99:41906] by server-2.bemta-4.messagelabs.com id
	74/87-06610-C4537505; Mon, 17 Sep 2012 14:35:56 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1347892552!30678523!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzQ1MDU4\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29926 invoked from network); 17 Sep 2012 14:35:54 -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; 17 Sep 2012 14:35:54 -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 q8HEZn3b016016
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 17 Sep 2012 14:35:50 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
	q8HEZmbs002120
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 17 Sep 2012 14:35:49 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
	q8HEZm20025881; Mon, 17 Sep 2012 09:35:48 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 17 Sep 2012 07:35:48 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 20E084032B; Mon, 17 Sep 2012 10:25:02 -0400 (EDT)
Date: Mon, 17 Sep 2012 10:25:02 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20120917142502.GB12541@phenom.dumpdata.com>
References: <1347306367-28669-1-git-send-email-konrad.wilk@oracle.com>
	<1347306367-28669-11-git-send-email-konrad.wilk@oracle.com>
	<alpine.DEB.2.02.1209141709580.29232@kaball.uk.xensource.com>
	<20120917142315.GA12541@phenom.dumpdata.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120917142315.GA12541@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" <xen-devel@lists.xensource.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: [Xen-devel] Is: [PATCH 11/10] xen/swiotlb: For early initialization,
 return zero on success. Was: Re: [PATCH 10/10] xen/swiotlb: Depending on
 after_bootmem is not 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 Mon, Sep 17, 2012 at 10:23:15AM -0400, Konrad Rzeszutek Wilk wrote:
> > >  	start_dma_addr = xen_virt_to_bus(xen_io_tlb_start);
> > > -	if (!after_bootmem)
> > > +	rc = 0;
> >      ^
> > why does this change belong to this patch?
> > 
> > 
> 
> I took that out of the this patch, so it is now:
> 

..and spun out another patch to address the rc=0:

>From f85175ce01ba722cd4612230e7331dc0d4c8666f Mon Sep 17 00:00:00 2001
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Mon, 17 Sep 2012 10:20:09 -0400
Subject: [PATCH 2/2] xen/swiotlb: For early initialization, return zero on
 success.

If everything is setup properly we would return -ENOMEM since
rc by default is set to that value. Lets not do that and return
a proper return code.

Note: The reason the early code needs this special treatment
is that it SWIOTLB library call does not return anything (and
had it failed it would call panic()) - but our function does.

Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 drivers/xen/swiotlb-xen.c |    5 +++--
 1 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
index 02a52f3..ab4c66c 100644
--- a/drivers/xen/swiotlb-xen.c
+++ b/drivers/xen/swiotlb-xen.c
@@ -230,9 +230,10 @@ retry:
 		goto error;
 	}
 	start_dma_addr = xen_virt_to_bus(xen_io_tlb_start);
-	if (early)
+	if (early) {
 		swiotlb_init_with_tbl(xen_io_tlb_start, xen_io_tlb_nslabs, verbose);
-	else
+		rc = 0;
+	} else
 		rc = swiotlb_late_init_with_tbl(xen_io_tlb_start, xen_io_tlb_nslabs);
 	return rc;
 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 Sep 17 14:36:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 14:36: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 1TDcQX-0001XD-Lv; Mon, 17 Sep 2012 14:35:57 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1TDcQW-0001X1-Rq
	for xen-devel@lists.xensource.com; Mon, 17 Sep 2012 14:35:57 +0000
Received: from [85.158.143.99:41906] by server-2.bemta-4.messagelabs.com id
	74/87-06610-C4537505; Mon, 17 Sep 2012 14:35:56 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1347892552!30678523!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzQ1MDU4\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29926 invoked from network); 17 Sep 2012 14:35:54 -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; 17 Sep 2012 14:35:54 -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 q8HEZn3b016016
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 17 Sep 2012 14:35:50 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
	q8HEZmbs002120
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 17 Sep 2012 14:35:49 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
	q8HEZm20025881; Mon, 17 Sep 2012 09:35:48 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 17 Sep 2012 07:35:48 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 20E084032B; Mon, 17 Sep 2012 10:25:02 -0400 (EDT)
Date: Mon, 17 Sep 2012 10:25:02 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20120917142502.GB12541@phenom.dumpdata.com>
References: <1347306367-28669-1-git-send-email-konrad.wilk@oracle.com>
	<1347306367-28669-11-git-send-email-konrad.wilk@oracle.com>
	<alpine.DEB.2.02.1209141709580.29232@kaball.uk.xensource.com>
	<20120917142315.GA12541@phenom.dumpdata.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120917142315.GA12541@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" <xen-devel@lists.xensource.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: [Xen-devel] Is: [PATCH 11/10] xen/swiotlb: For early initialization,
 return zero on success. Was: Re: [PATCH 10/10] xen/swiotlb: Depending on
 after_bootmem is not 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 Mon, Sep 17, 2012 at 10:23:15AM -0400, Konrad Rzeszutek Wilk wrote:
> > >  	start_dma_addr = xen_virt_to_bus(xen_io_tlb_start);
> > > -	if (!after_bootmem)
> > > +	rc = 0;
> >      ^
> > why does this change belong to this patch?
> > 
> > 
> 
> I took that out of the this patch, so it is now:
> 

..and spun out another patch to address the rc=0:

>From f85175ce01ba722cd4612230e7331dc0d4c8666f Mon Sep 17 00:00:00 2001
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Mon, 17 Sep 2012 10:20:09 -0400
Subject: [PATCH 2/2] xen/swiotlb: For early initialization, return zero on
 success.

If everything is setup properly we would return -ENOMEM since
rc by default is set to that value. Lets not do that and return
a proper return code.

Note: The reason the early code needs this special treatment
is that it SWIOTLB library call does not return anything (and
had it failed it would call panic()) - but our function does.

Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 drivers/xen/swiotlb-xen.c |    5 +++--
 1 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
index 02a52f3..ab4c66c 100644
--- a/drivers/xen/swiotlb-xen.c
+++ b/drivers/xen/swiotlb-xen.c
@@ -230,9 +230,10 @@ retry:
 		goto error;
 	}
 	start_dma_addr = xen_virt_to_bus(xen_io_tlb_start);
-	if (early)
+	if (early) {
 		swiotlb_init_with_tbl(xen_io_tlb_start, xen_io_tlb_nslabs, verbose);
-	else
+		rc = 0;
+	} else
 		rc = swiotlb_late_init_with_tbl(xen_io_tlb_start, xen_io_tlb_nslabs);
 	return rc;
 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 Sep 17 14:39:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 14: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 1TDcTX-0001oy-Ny; Mon, 17 Sep 2012 14:39:03 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ketuzsezr@gmail.com>) id 1TDcTW-0001oZ-Fz
	for xen-devel@lists.xen.org; Mon, 17 Sep 2012 14:39:02 +0000
X-Env-Sender: ketuzsezr@gmail.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1347892710!9923548!1
X-Originating-IP: [209.85.216.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2190 invoked from network); 17 Sep 2012 14:38:31 -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;
	17 Sep 2012 14:38:31 -0000
Received: by qadc10 with SMTP id c10so1862834qad.11
	for <xen-devel@lists.xen.org>; Mon, 17 Sep 2012 07:38:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:date:from:to:cc:subject:message-id:references:mime-version
	:content-type:content-disposition:in-reply-to:user-agent;
	bh=GLZSudVIZAWhOX7af92J0CYjWwHpu8OSoAPMmnCuuLA=;
	b=G1IN364uAZCme5NVEL5SazJCT3jjXyGA5BQTe3bqTaOUuGPAa2l0IY2lwCqGeLRy/4
	aAjTRtBC4ynuK5k3fiKi81IRuiiDuY7E/3DkIkDECoaeDaMn+DiQ2ZzzK9BOjXgInQ2f
	0bL8F17UDP0F+4/jOyIQsIDFaqBMUgQV3MPegcSaakH8zhNJdZLniO02IR9bxXNemRfD
	3B9GyBy9fV30P2lkIwBa3VphlvoMxjOXwvXGUaD0RWp+jq/9n18tT0oWLz91iRpxfY9g
	fRPpGoJRkdEJe5k2AnxxPtlgXSQvGTFm3adieEorV8osAopcp15bZ9zifF0Hn9l36Edf
	atAw==
Received: by 10.229.134.200 with SMTP id k8mr7356081qct.135.1347892709686;
	Mon, 17 Sep 2012 07:38:29 -0700 (PDT)
Received: from phenom.dumpdata.com
	(50-195-21-189-static.hfc.comcastbusiness.net. [50.195.21.189])
	by mx.google.com with ESMTPS id ha5sm15463859qab.1.2012.09.17.07.38.28
	(version=TLSv1/SSLv3 cipher=OTHER);
	Mon, 17 Sep 2012 07:38:29 -0700 (PDT)
Date: Mon, 17 Sep 2012 10:27:36 -0400
From: Konrad Rzeszutek Wilk <konrad@kernel.org>
To: Nitin Gupta <nitin.kobain@gmail.com>
Message-ID: <20120917142734.GA14012@phenom.dumpdata.com>
References: <CAESzvYTsHm+QYiP6TCYXUC3AWfP-LuzvxOVYN7bnd6MF=a3v6Q@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAESzvYTsHm+QYiP6TCYXUC3AWfP-LuzvxOVYN7bnd6MF=a3v6Q@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] domu to dom0's entry point
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Sat, Sep 15, 2012 at 07:00:56PM +0530, Nitin Gupta wrote:
> Hi,
> 
> I have a query.
> 
> Dom0 is the administrative kernel which can access I/O devices through
> hypervisor. So if an application wants to write to an I/O device then it
> should go through Dom0. Is it right? If its so then can anyone point to the

No. It will go to the hypervisor if the DomU has been granted access
to those I/O ports/MMIO bars..

> entry and exit points in Dom0.
> 
> -- 
> Regards,
> Nitin Gupta

> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 17 14:39:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 14: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 1TDcTX-0001oy-Ny; Mon, 17 Sep 2012 14:39:03 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ketuzsezr@gmail.com>) id 1TDcTW-0001oZ-Fz
	for xen-devel@lists.xen.org; Mon, 17 Sep 2012 14:39:02 +0000
X-Env-Sender: ketuzsezr@gmail.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1347892710!9923548!1
X-Originating-IP: [209.85.216.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2190 invoked from network); 17 Sep 2012 14:38:31 -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;
	17 Sep 2012 14:38:31 -0000
Received: by qadc10 with SMTP id c10so1862834qad.11
	for <xen-devel@lists.xen.org>; Mon, 17 Sep 2012 07:38:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:date:from:to:cc:subject:message-id:references:mime-version
	:content-type:content-disposition:in-reply-to:user-agent;
	bh=GLZSudVIZAWhOX7af92J0CYjWwHpu8OSoAPMmnCuuLA=;
	b=G1IN364uAZCme5NVEL5SazJCT3jjXyGA5BQTe3bqTaOUuGPAa2l0IY2lwCqGeLRy/4
	aAjTRtBC4ynuK5k3fiKi81IRuiiDuY7E/3DkIkDECoaeDaMn+DiQ2ZzzK9BOjXgInQ2f
	0bL8F17UDP0F+4/jOyIQsIDFaqBMUgQV3MPegcSaakH8zhNJdZLniO02IR9bxXNemRfD
	3B9GyBy9fV30P2lkIwBa3VphlvoMxjOXwvXGUaD0RWp+jq/9n18tT0oWLz91iRpxfY9g
	fRPpGoJRkdEJe5k2AnxxPtlgXSQvGTFm3adieEorV8osAopcp15bZ9zifF0Hn9l36Edf
	atAw==
Received: by 10.229.134.200 with SMTP id k8mr7356081qct.135.1347892709686;
	Mon, 17 Sep 2012 07:38:29 -0700 (PDT)
Received: from phenom.dumpdata.com
	(50-195-21-189-static.hfc.comcastbusiness.net. [50.195.21.189])
	by mx.google.com with ESMTPS id ha5sm15463859qab.1.2012.09.17.07.38.28
	(version=TLSv1/SSLv3 cipher=OTHER);
	Mon, 17 Sep 2012 07:38:29 -0700 (PDT)
Date: Mon, 17 Sep 2012 10:27:36 -0400
From: Konrad Rzeszutek Wilk <konrad@kernel.org>
To: Nitin Gupta <nitin.kobain@gmail.com>
Message-ID: <20120917142734.GA14012@phenom.dumpdata.com>
References: <CAESzvYTsHm+QYiP6TCYXUC3AWfP-LuzvxOVYN7bnd6MF=a3v6Q@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAESzvYTsHm+QYiP6TCYXUC3AWfP-LuzvxOVYN7bnd6MF=a3v6Q@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] domu to dom0's entry point
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Sat, Sep 15, 2012 at 07:00:56PM +0530, Nitin Gupta wrote:
> Hi,
> 
> I have a query.
> 
> Dom0 is the administrative kernel which can access I/O devices through
> hypervisor. So if an application wants to write to an I/O device then it
> should go through Dom0. Is it right? If its so then can anyone point to the

No. It will go to the hypervisor if the DomU has been granted access
to those I/O ports/MMIO bars..

> entry and exit points in Dom0.
> 
> -- 
> Regards,
> Nitin Gupta

> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 17 14:39:56 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 14:39:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDcUE-0001vK-QX; Mon, 17 Sep 2012 14:39:46 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ketuzsezr@gmail.com>) id 1TDcUD-0001v0-OK
	for xen-devel@lists.xen.org; Mon, 17 Sep 2012 14:39:45 +0000
Received: from [85.158.139.83:2177] by server-10.bemta-5.messagelabs.com id
	83/8E-10969-03637505; Mon, 17 Sep 2012 14:39:44 +0000
X-Env-Sender: ketuzsezr@gmail.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1347892782!31163883!1
X-Originating-IP: [209.85.216.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6357 invoked from network); 17 Sep 2012 14:39:43 -0000
Received: from mail-qa0-f45.google.com (HELO mail-qa0-f45.google.com)
	(209.85.216.45)
	by server-10.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Sep 2012 14:39:43 -0000
Received: by qadc10 with SMTP id c10so1864382qad.11
	for <xen-devel@lists.xen.org>; Mon, 17 Sep 2012 07:39:42 -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:content-transfer-encoding
	:in-reply-to:user-agent;
	bh=n2HHN2nlrpMdjOPidsZWIyLu4BV5h2AjCiiKIqiyg6k=;
	b=Xi/s+QaOVHUvfn4HqXE+jKg78ukEddcdJHZrDeXVBzWgMSHzZA+HZq/hQpoC3d7bAD
	ViO+KymEnzDzyjDUBKL3OmwEnuFSnJAqD0YCsExEola9Ug2MLuMoi96O9LJdistLzpYz
	LG5lVHZFNgNuLcqy93fOZbO5KPlK5zHk0QW+qh/z5IvSWVlr3CsouZZXhdW87A87iKqG
	xEwHY4bcv/ukciFU2LUosyMsWj1mmqbt0pDymC7PxwijNC+aS+tKgzQakEX9wAAAwkNn
	YSXqnkdvvXQSLNadv33aifooe8+1bEtBbHb9Y6EHs8wf2/uyTe1X8YW8fVcup7pv8UZR
	fWpw==
Received: by 10.229.136.144 with SMTP id r16mr7552014qct.14.1347892782435;
	Mon, 17 Sep 2012 07:39:42 -0700 (PDT)
Received: from phenom.dumpdata.com
	(50-195-21-189-static.hfc.comcastbusiness.net. [50.195.21.189])
	by mx.google.com with ESMTPS id eh7sm15455273qab.13.2012.09.17.07.39.41
	(version=TLSv1/SSLv3 cipher=OTHER);
	Mon, 17 Sep 2012 07:39:41 -0700 (PDT)
Date: Mon, 17 Sep 2012 10:28:52 -0400
From: Konrad Rzeszutek Wilk <konrad@kernel.org>
To: Javier Marcet <jmarcet@gmail.com>
Message-ID: <20120917142851.GB14012@phenom.dumpdata.com>
References: <CAAnFQG9TZj=SxYK_jxqN=M6L40vL=AZu9EM2tbEffPhkL1s8FA@mail.gmail.com>
	<CACJDEmqdqA6CE9SgLL2QCNmQH1dOX0_4OHfJfzes+G6bEkQ7FA@mail.gmail.com>
	<CAAnFQG-8Fkunv6R8+GCLAH4yQCx4-Nn0zN_Ntsf0wsh5yXeihQ@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAAnFQG-8Fkunv6R8+GCLAH4yQCx4-Nn0zN_Ntsf0wsh5yXeihQ@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: Xen Devel Mailing list <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.2.0-rc4 issues with DVB tuner
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="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, Sep 16, 2012 at 04:57:16PM +0200, Javier Marcet wrote:
> On Fri, Sep 14, 2012 at 10:47 PM, Konrad Rzeszutek Wilk
> <konrad@kernel.org> wrote:
> =

> >> This last point is a showstopper for me and I don=B4t know where the
> >> problem might come from. The cx23885 module (which my tuners use)
> >> loads fine, as do the devices under /dev/dvb. Upon tuning a channel,
> >> however, there is not data received.
> >>
> >> Does anyone have the slightest idea what might be causing this?
> >
> > Are there any warnings or such being printed? Are the interrupts increa=
sing?
> > Does lspci show anything 'disabled' in the guest?
> =

> You have misunderstood me. I was trying to access the dvb tuners from the=
 dom0.

Ah.
> =

> Using kvm I have sucessfully passthrough a sata controller, but have some=
 issues
> passin through the dvb tuner.
> =

> >> I wonder whether it would work within a DomU with the PCIe tuner
> >> passed through.
> >
> > I've a 4 channel security card passed in and it works nicely. The
> > trick is that you need 'iommu=3Dsoft' on the domU command line.
> =

> All right. But is it normal that it does not work under the dom0?

No. PV domU and PV dom0 are pretty much the same in the way of handling
interrupts, ports, etc.

If you crank up the debug level of the kernel (debug loglevel=3D8) and
of the driver do you get anything obvious? What about the questions
I've asked?

> The same kernel running on bare metal has no problems.
> =

> =

> -- =

> Javier Marcet <jmarcet@gmail.com>
> =


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 17 14:39:56 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 14:39:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDcUE-0001vK-QX; Mon, 17 Sep 2012 14:39:46 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ketuzsezr@gmail.com>) id 1TDcUD-0001v0-OK
	for xen-devel@lists.xen.org; Mon, 17 Sep 2012 14:39:45 +0000
Received: from [85.158.139.83:2177] by server-10.bemta-5.messagelabs.com id
	83/8E-10969-03637505; Mon, 17 Sep 2012 14:39:44 +0000
X-Env-Sender: ketuzsezr@gmail.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1347892782!31163883!1
X-Originating-IP: [209.85.216.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6357 invoked from network); 17 Sep 2012 14:39:43 -0000
Received: from mail-qa0-f45.google.com (HELO mail-qa0-f45.google.com)
	(209.85.216.45)
	by server-10.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Sep 2012 14:39:43 -0000
Received: by qadc10 with SMTP id c10so1864382qad.11
	for <xen-devel@lists.xen.org>; Mon, 17 Sep 2012 07:39:42 -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:content-transfer-encoding
	:in-reply-to:user-agent;
	bh=n2HHN2nlrpMdjOPidsZWIyLu4BV5h2AjCiiKIqiyg6k=;
	b=Xi/s+QaOVHUvfn4HqXE+jKg78ukEddcdJHZrDeXVBzWgMSHzZA+HZq/hQpoC3d7bAD
	ViO+KymEnzDzyjDUBKL3OmwEnuFSnJAqD0YCsExEola9Ug2MLuMoi96O9LJdistLzpYz
	LG5lVHZFNgNuLcqy93fOZbO5KPlK5zHk0QW+qh/z5IvSWVlr3CsouZZXhdW87A87iKqG
	xEwHY4bcv/ukciFU2LUosyMsWj1mmqbt0pDymC7PxwijNC+aS+tKgzQakEX9wAAAwkNn
	YSXqnkdvvXQSLNadv33aifooe8+1bEtBbHb9Y6EHs8wf2/uyTe1X8YW8fVcup7pv8UZR
	fWpw==
Received: by 10.229.136.144 with SMTP id r16mr7552014qct.14.1347892782435;
	Mon, 17 Sep 2012 07:39:42 -0700 (PDT)
Received: from phenom.dumpdata.com
	(50-195-21-189-static.hfc.comcastbusiness.net. [50.195.21.189])
	by mx.google.com with ESMTPS id eh7sm15455273qab.13.2012.09.17.07.39.41
	(version=TLSv1/SSLv3 cipher=OTHER);
	Mon, 17 Sep 2012 07:39:41 -0700 (PDT)
Date: Mon, 17 Sep 2012 10:28:52 -0400
From: Konrad Rzeszutek Wilk <konrad@kernel.org>
To: Javier Marcet <jmarcet@gmail.com>
Message-ID: <20120917142851.GB14012@phenom.dumpdata.com>
References: <CAAnFQG9TZj=SxYK_jxqN=M6L40vL=AZu9EM2tbEffPhkL1s8FA@mail.gmail.com>
	<CACJDEmqdqA6CE9SgLL2QCNmQH1dOX0_4OHfJfzes+G6bEkQ7FA@mail.gmail.com>
	<CAAnFQG-8Fkunv6R8+GCLAH4yQCx4-Nn0zN_Ntsf0wsh5yXeihQ@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAAnFQG-8Fkunv6R8+GCLAH4yQCx4-Nn0zN_Ntsf0wsh5yXeihQ@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: Xen Devel Mailing list <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.2.0-rc4 issues with DVB tuner
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="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, Sep 16, 2012 at 04:57:16PM +0200, Javier Marcet wrote:
> On Fri, Sep 14, 2012 at 10:47 PM, Konrad Rzeszutek Wilk
> <konrad@kernel.org> wrote:
> =

> >> This last point is a showstopper for me and I don=B4t know where the
> >> problem might come from. The cx23885 module (which my tuners use)
> >> loads fine, as do the devices under /dev/dvb. Upon tuning a channel,
> >> however, there is not data received.
> >>
> >> Does anyone have the slightest idea what might be causing this?
> >
> > Are there any warnings or such being printed? Are the interrupts increa=
sing?
> > Does lspci show anything 'disabled' in the guest?
> =

> You have misunderstood me. I was trying to access the dvb tuners from the=
 dom0.

Ah.
> =

> Using kvm I have sucessfully passthrough a sata controller, but have some=
 issues
> passin through the dvb tuner.
> =

> >> I wonder whether it would work within a DomU with the PCIe tuner
> >> passed through.
> >
> > I've a 4 channel security card passed in and it works nicely. The
> > trick is that you need 'iommu=3Dsoft' on the domU command line.
> =

> All right. But is it normal that it does not work under the dom0?

No. PV domU and PV dom0 are pretty much the same in the way of handling
interrupts, ports, etc.

If you crank up the debug level of the kernel (debug loglevel=3D8) and
of the driver do you get anything obvious? What about the questions
I've asked?

> The same kernel running on bare metal has no problems.
> =

> =

> -- =

> Javier Marcet <jmarcet@gmail.com>
> =


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 17 14:45:53 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 14:45: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 1TDcZu-0002Ng-Kt; Mon, 17 Sep 2012 14:45:38 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ketuzsezr@gmail.com>) id 1TDcZs-0002Nb-JT
	for xen-devel@lists.xensource.com; Mon, 17 Sep 2012 14:45:36 +0000
Received: from [85.158.139.211:13884] by server-1.bemta-5.messagelabs.com id
	C9/45-32692-F8737505; Mon, 17 Sep 2012 14:45:35 +0000
X-Env-Sender: ketuzsezr@gmail.com
X-Msg-Ref: server-10.tower-206.messagelabs.com!1347893133!18861726!1
X-Originating-IP: [209.85.216.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17466 invoked from network); 17 Sep 2012 14:45:34 -0000
Received: from mail-qc0-f171.google.com (HELO mail-qc0-f171.google.com)
	(209.85.216.171)
	by server-10.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Sep 2012 14:45:34 -0000
Received: by qcad1 with SMTP id d1so5538750qca.30
	for <xen-devel@lists.xensource.com>;
	Mon, 17 Sep 2012 07:45:33 -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=s03r5E7KXXfxGsHyZ8JIb5qCvFSB+iG6Cv+MZmHDjzI=;
	b=DZ0o3FPI7pdTKmmpBbn+MaHQpliAsnWD26Bv7MXM50ZZTbjKIBOZn778o1VjXHMkO4
	3hgXyjJrjMoHZVKF/SoIgjJy/NfhqY94BkyinOwI4GLSd0+xouoR3TQYAWerzU5E3zEi
	vzMKB1Z87SMioHiwHeBIveQA0XuF8MwSsCjuLXo6hp9Se9jJ5q63EbzV9EFi3Lfk3SEv
	qlquv1XjHEAGywbpBEtL6G2AFPBz2b9vG8+b1lHzvgFp/jgUzFCJugRrlBl/cMOVL92O
	7S4TyMsb7gKdlv2p+DhcDfCba2lWAz1hlAEZRycaC1RbeB3P2irkZSnP7to3bgCWDZ3L
	/T+Q==
Received: by 10.229.134.206 with SMTP id k14mr7503691qct.25.1347893133522;
	Mon, 17 Sep 2012 07:45:33 -0700 (PDT)
Received: from phenom.dumpdata.com
	(50-195-21-189-static.hfc.comcastbusiness.net. [50.195.21.189])
	by mx.google.com with ESMTPS id h8sm15469906qap.16.2012.09.17.07.45.31
	(version=TLSv1/SSLv3 cipher=OTHER);
	Mon, 17 Sep 2012 07:45:32 -0700 (PDT)
Date: Mon, 17 Sep 2012 10:34:43 -0400
From: Konrad Rzeszutek Wilk <konrad@kernel.org>
To: "xen.org" <ian.jackson@eu.citrix.com>
Message-ID: <20120917143441.GC14012@phenom.dumpdata.com>
References: <osstest-13786-mainreport@xen.org>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <osstest-13786-mainreport@xen.org>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [linux-mingo-tip-master test] 13786: regressions -
 FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, Sep 16, 2012 at 06:56:40PM +0100, xen.org wrote:
> flight 13786 linux-mingo-tip-master real [real]
> http://www.chiark.greenend.org.uk/~xensrcts/logs/13786/
> 
> Regressions :-(
> 
> Tests which did not succeed and are blocking,
> including tests which could not be run:
>  test-amd64-i386-xend-winxpsp3  5 xen-boot                 fail REGR. vs. 12678
>  test-amd64-i386-xl-credit2    5 xen-boot                  fail REGR. vs. 12678
>  test-amd64-amd64-pair         8 xen-boot/dst_host         fail REGR. vs. 12678
>  test-amd64-amd64-pair         7 xen-boot/src_host         fail REGR. vs. 12678

I am not able to find 12678?

But more importantly, it looks like it lost SSH connection to
10.80.249.148 after it sent debug-key 'q' to the dom0?

> 
> Tests which did not succeed, but are not blocking:
>  test-amd64-amd64-xl-pcipt-intel  5 xen-boot                    fail never pass
>  test-amd64-amd64-xl-win7-amd64  5 xen-boot                     fail never pass
>  test-amd64-i386-xl-win-vcpus1  5 xen-boot                     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-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
>  test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail never pass
>  test-amd64-i386-pair          8 xen-boot/dst_host            fail   never pass
>  test-amd64-i386-pair          7 xen-boot/src_host            fail   never pass
>  test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail never pass
>  test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
>  test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
>  test-amd64-i386-win          16 leak-check/check             fail   never pass
>  test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
> 
> version targeted for testing:
>  linux                2a346d40b9564288f5d41b441e14d6a4dae3be2b
> baseline version:
>  linux                d935d0f77650fea53986811ca8a2f8c726fd9857
> 
> 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-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                                   fail    
>  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                                        fail    
>  test-amd64-i386-pair                                         fail    
>  test-amd64-amd64-xl-sedf-pin                                 pass    
>  test-amd64-amd64-pv                                          pass    
>  test-amd64-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-amd64-amd64-xl-win                                      fail    
>  test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
>  test-amd64-i386-xend-winxpsp3                                fail    
>  test-amd64-amd64-xl-winxpsp3                                 fail    
> 
> 
> ------------------------------------------------------------
> sg-report-flight on woking.cam.xci-test.com
> logs: /home/xc_osstest/logs
> images: /home/xc_osstest/images
> 
> Logs, config files, etc. are available at
>     http://www.chiark.greenend.org.uk/~xensrcts/logs
> 
> Test harness code can be found at
>     http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary
> 
> 
> Not pushing.
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 17 14:45:53 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 14:45: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 1TDcZu-0002Ng-Kt; Mon, 17 Sep 2012 14:45:38 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ketuzsezr@gmail.com>) id 1TDcZs-0002Nb-JT
	for xen-devel@lists.xensource.com; Mon, 17 Sep 2012 14:45:36 +0000
Received: from [85.158.139.211:13884] by server-1.bemta-5.messagelabs.com id
	C9/45-32692-F8737505; Mon, 17 Sep 2012 14:45:35 +0000
X-Env-Sender: ketuzsezr@gmail.com
X-Msg-Ref: server-10.tower-206.messagelabs.com!1347893133!18861726!1
X-Originating-IP: [209.85.216.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17466 invoked from network); 17 Sep 2012 14:45:34 -0000
Received: from mail-qc0-f171.google.com (HELO mail-qc0-f171.google.com)
	(209.85.216.171)
	by server-10.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Sep 2012 14:45:34 -0000
Received: by qcad1 with SMTP id d1so5538750qca.30
	for <xen-devel@lists.xensource.com>;
	Mon, 17 Sep 2012 07:45:33 -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=s03r5E7KXXfxGsHyZ8JIb5qCvFSB+iG6Cv+MZmHDjzI=;
	b=DZ0o3FPI7pdTKmmpBbn+MaHQpliAsnWD26Bv7MXM50ZZTbjKIBOZn778o1VjXHMkO4
	3hgXyjJrjMoHZVKF/SoIgjJy/NfhqY94BkyinOwI4GLSd0+xouoR3TQYAWerzU5E3zEi
	vzMKB1Z87SMioHiwHeBIveQA0XuF8MwSsCjuLXo6hp9Se9jJ5q63EbzV9EFi3Lfk3SEv
	qlquv1XjHEAGywbpBEtL6G2AFPBz2b9vG8+b1lHzvgFp/jgUzFCJugRrlBl/cMOVL92O
	7S4TyMsb7gKdlv2p+DhcDfCba2lWAz1hlAEZRycaC1RbeB3P2irkZSnP7to3bgCWDZ3L
	/T+Q==
Received: by 10.229.134.206 with SMTP id k14mr7503691qct.25.1347893133522;
	Mon, 17 Sep 2012 07:45:33 -0700 (PDT)
Received: from phenom.dumpdata.com
	(50-195-21-189-static.hfc.comcastbusiness.net. [50.195.21.189])
	by mx.google.com with ESMTPS id h8sm15469906qap.16.2012.09.17.07.45.31
	(version=TLSv1/SSLv3 cipher=OTHER);
	Mon, 17 Sep 2012 07:45:32 -0700 (PDT)
Date: Mon, 17 Sep 2012 10:34:43 -0400
From: Konrad Rzeszutek Wilk <konrad@kernel.org>
To: "xen.org" <ian.jackson@eu.citrix.com>
Message-ID: <20120917143441.GC14012@phenom.dumpdata.com>
References: <osstest-13786-mainreport@xen.org>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <osstest-13786-mainreport@xen.org>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [linux-mingo-tip-master test] 13786: regressions -
 FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, Sep 16, 2012 at 06:56:40PM +0100, xen.org wrote:
> flight 13786 linux-mingo-tip-master real [real]
> http://www.chiark.greenend.org.uk/~xensrcts/logs/13786/
> 
> Regressions :-(
> 
> Tests which did not succeed and are blocking,
> including tests which could not be run:
>  test-amd64-i386-xend-winxpsp3  5 xen-boot                 fail REGR. vs. 12678
>  test-amd64-i386-xl-credit2    5 xen-boot                  fail REGR. vs. 12678
>  test-amd64-amd64-pair         8 xen-boot/dst_host         fail REGR. vs. 12678
>  test-amd64-amd64-pair         7 xen-boot/src_host         fail REGR. vs. 12678

I am not able to find 12678?

But more importantly, it looks like it lost SSH connection to
10.80.249.148 after it sent debug-key 'q' to the dom0?

> 
> Tests which did not succeed, but are not blocking:
>  test-amd64-amd64-xl-pcipt-intel  5 xen-boot                    fail never pass
>  test-amd64-amd64-xl-win7-amd64  5 xen-boot                     fail never pass
>  test-amd64-i386-xl-win-vcpus1  5 xen-boot                     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-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
>  test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail never pass
>  test-amd64-i386-pair          8 xen-boot/dst_host            fail   never pass
>  test-amd64-i386-pair          7 xen-boot/src_host            fail   never pass
>  test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail never pass
>  test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
>  test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
>  test-amd64-i386-win          16 leak-check/check             fail   never pass
>  test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
> 
> version targeted for testing:
>  linux                2a346d40b9564288f5d41b441e14d6a4dae3be2b
> baseline version:
>  linux                d935d0f77650fea53986811ca8a2f8c726fd9857
> 
> 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-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                                   fail    
>  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                                        fail    
>  test-amd64-i386-pair                                         fail    
>  test-amd64-amd64-xl-sedf-pin                                 pass    
>  test-amd64-amd64-pv                                          pass    
>  test-amd64-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-amd64-amd64-xl-win                                      fail    
>  test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
>  test-amd64-i386-xend-winxpsp3                                fail    
>  test-amd64-amd64-xl-winxpsp3                                 fail    
> 
> 
> ------------------------------------------------------------
> sg-report-flight on woking.cam.xci-test.com
> logs: /home/xc_osstest/logs
> images: /home/xc_osstest/images
> 
> Logs, config files, etc. are available at
>     http://www.chiark.greenend.org.uk/~xensrcts/logs
> 
> Test harness code can be found at
>     http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary
> 
> 
> Not pushing.
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 17 14:48:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 14: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 1TDccF-0002UR-6H; Mon, 17 Sep 2012 14:48:03 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ketuzsezr@gmail.com>) id 1TDccD-0002UJ-Vy
	for xen-devel@lists.xen.org; Mon, 17 Sep 2012 14:48:02 +0000
Received: from [85.158.139.211:61790] by server-7.bemta-5.messagelabs.com id
	27/2A-19703-12837505; Mon, 17 Sep 2012 14:48:01 +0000
X-Env-Sender: ketuzsezr@gmail.com
X-Msg-Ref: server-3.tower-206.messagelabs.com!1347893279!18881674!1
X-Originating-IP: [209.85.216.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13664 invoked from network); 17 Sep 2012 14:48:00 -0000
Received: from mail-qc0-f173.google.com (HELO mail-qc0-f173.google.com)
	(209.85.216.173)
	by server-3.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Sep 2012 14:48:00 -0000
Received: by qcab12 with SMTP id b12so6045172qca.32
	for <xen-devel@lists.xen.org>; Mon, 17 Sep 2012 07:47:59 -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=c0sshydMfe4Z/5Yf0jQXADeGzX1eDj5S63JqY+Fb2o4=;
	b=fbX16YQBJPkijeQuycrnor7P9TmAr0PIFVoXymJR6GW0JPNHUzoKdiHxHxRU4D/IJj
	xARk5s4Zk3gQ0TfsEcc4tynjZ+u8MNyctsxRSD5bXZCodbmKT4c6pP8YN+/zmD+pIBJr
	tUuVngCRhq6t9n6xmytl+I/oXp3XaoB7nduj214GE+ooCxFDZjW4VAiyM6MzE/Q2z4Mg
	lb8rL8QODlsCDIpHKkga+WfhGeNEOTUgvh2NmWrgkLFpNR4a4dXiLSmafqi1szrGXMM1
	oampSOyvJowOKIzcq9PgRbM3HZwqrDakm5O2xB+IFPAFO01VxfCTqCMj1WeF2V6CBflq
	olsA==
Received: by 10.229.137.85 with SMTP id v21mr7318847qct.17.1347893278870;
	Mon, 17 Sep 2012 07:47:58 -0700 (PDT)
Received: from phenom.dumpdata.com
	(50-195-21-189-static.hfc.comcastbusiness.net. [50.195.21.189])
	by mx.google.com with ESMTPS id ck11sm6111106qab.17.2012.09.17.07.47.56
	(version=TLSv1/SSLv3 cipher=OTHER);
	Mon, 17 Sep 2012 07:47:57 -0700 (PDT)
Date: Mon, 17 Sep 2012 10:37:08 -0400
From: Konrad Rzeszutek Wilk <konrad@kernel.org>
To: "Duan, Ronghui" <ronghui.duan@intel.com>
Message-ID: <20120917143707.GD14012@phenom.dumpdata.com>
References: <A21691DE07B84740B5F0B81466D5148A23BCF1DF@SHSMSX102.ccr.corp.intel.com>
	<20120907174922.GA13040@phenom.dumpdata.com>
	<A21691DE07B84740B5F0B81466D5148A23BF6833@SHSMSX102.ccr.corp.intel.com>
	<5051A83B020000780009AF93@nat28.tlf.novell.com>
	<alpine.DEB.2.02.1209131203270.15568@kaball.uk.xensource.com>
	<20120913132335.GD16635@localhost.localdomain>
	<A21691DE07B84740B5F0B81466D5148A23BF6C1D@SHSMSX102.ccr.corp.intel.com>
	<A21691DE07B84740B5F0B81466D5148A23BF7E2F@SHSMSX102.ccr.corp.intel.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <A21691DE07B84740B5F0B81466D5148A23BF7E2F@SHSMSX102.ccr.corp.intel.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: "'xen-devel@lists.xen.org'" <xen-devel@lists.xen.org>,
	'Stefano Stabellini' <stefano.stabellini@eu.citrix.com>,
	'Ian Jackson' <Ian.Jackson@eu.citrix.com>,
	'Jan Beulich' <JBeulich@suse.com>,
	'Konrad Rzeszutek Wilk' <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [RFC v1 0/5] VBD: enlarge max segment per request
 in blkfront
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Sep 17, 2012 at 06:33:29AM +0000, Duan, Ronghui wrote:
> At last, I saw the regression in random io.
> This is a patch to fix the performance regression. Original the pending request members are allocated from the stack, I alloc them when each request arrives in my last patch. But it will hurt performance. In this fix, I alloc all of them when blkback init. But due to some bugs there, we can't free it, the same to other pending requests member. I am looking for the reason. But have no idea for this now. 

Right. When I implemented something similar to this (allocate at startup
those pools of pages), I had the same problem of freeing the grant array
blowing up the machine.

But... this was before
http://git.kernel.org/?p=linux/kernel/git/konrad/xen.git;a=commit;h=2fc136eecd0c647a6b13fcd00d0c41a1a28f35a5

- which might be the fix for this.

> Konrad, thanks for your comments. Could you have a try when you have time.
> 
> -ronghui
> 
> > -----Original Message-----
> > From: Duan, Ronghui
> > Sent: Thursday, September 13, 2012 10:06 PM
> > To: Konrad Rzeszutek Wilk; Stefano Stabellini
> > Cc: Jan Beulich; Ian Jackson; xen-devel@lists.xen.org
> > Subject: RE: [Xen-devel] [RFC v1 0/5] VBD: enlarge max segment per request in
> > blkfront
> > 
> > > > > But you certainly shouldn't be proposing features getting used
> > > > > unconditionally or by default that benefit one class of backing
> > > > > devices and severely penalize others.
> > > >
> > > > Right.
> > > > I am wondering.. Considering that the in-kernel blkback is mainly
> > > > used with physical partitions, is it possible that your patches
> > > > cause a regression with unmodified backends that don't support the
> > > > new protocol, like QEMU for example?
> > >
> > > Well for right now I am just using the most simple configuration to
> > > eliminate any extra variables (stacking of components). So my
> > > "testing" has been just on phy:/dev/sda,xvda,w with the sda being a Corsair
> > SSD.
> > 
> > I totally agree that we should not break others when enable what we want.
> > But just from my mind, the patch only have a little overhead in the
> > front/backend code path. It will induce pure random IO with a little overhead.
> > I tried the 4K read case, I just got 50MB/s w/o the patch. I need a more
> > powerful disk to verified it.
> > 
> > Ronghui
> > 
> > 
> > > -----Original Message-----
> > > From: Konrad Rzeszutek Wilk [mailto:konrad.wilk@oracle.com]
> > > Sent: Thursday, September 13, 2012 9:24 PM
> > > To: Stefano Stabellini
> > > Cc: Jan Beulich; Duan, Ronghui; Ian Jackson; xen-devel@lists.xen.org
> > > Subject: Re: [Xen-devel] [RFC v1 0/5] VBD: enlarge max segment per
> > > request in blkfront
> > >
> > > On Thu, Sep 13, 2012 at 12:05:35PM +0100, Stefano Stabellini wrote:
> > > > On Thu, 13 Sep 2012, Jan Beulich wrote:
> > > > > >>> On 13.09.12 at 04:28, "Duan, Ronghui" <ronghui.duan@intel.com> wrote:
> > > > > >> And with your patch got:
> > > > > >>   read : io=4096.0MB, bw=92606KB/s, iops=23151 , runt=
> > > > > >> 45292msec
> > > > > >>
> > > > > >> without:
> > > > > >>   read : io=4096.0MB, bw=145187KB/s, iops=36296 , runt=
> > > > > >> 28889msec
> > > > > >>
> > > > > > What type of backend file you are using? In order to remove the
> > > > > > influence of cache in Dom0, I use a physical partition as backend.
> > > > >
> > > > > But you certainly shouldn't be proposing features getting used
> > > > > unconditionally or by default that benefit one class of backing
> > > > > devices and severely penalize others.
> > > >
> > > > Right.
> > > > I am wondering.. Considering that the in-kernel blkback is mainly
> > > > used with physical partitions, is it possible that your patches
> > > > cause a regression with unmodified backends that don't support the
> > > > new protocol, like QEMU for example?
> > >
> > > Well for right now I am just using the most simple configuration to
> > > eliminate any extra variables (stacking of components). So my
> > > "testing" has been just on phy:/dev/sda,xvda,w with the sda being a Corsair
> > SSD.
> 


> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Sep 17 14:48:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 14: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 1TDccF-0002UR-6H; Mon, 17 Sep 2012 14:48:03 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ketuzsezr@gmail.com>) id 1TDccD-0002UJ-Vy
	for xen-devel@lists.xen.org; Mon, 17 Sep 2012 14:48:02 +0000
Received: from [85.158.139.211:61790] by server-7.bemta-5.messagelabs.com id
	27/2A-19703-12837505; Mon, 17 Sep 2012 14:48:01 +0000
X-Env-Sender: ketuzsezr@gmail.com
X-Msg-Ref: server-3.tower-206.messagelabs.com!1347893279!18881674!1
X-Originating-IP: [209.85.216.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13664 invoked from network); 17 Sep 2012 14:48:00 -0000
Received: from mail-qc0-f173.google.com (HELO mail-qc0-f173.google.com)
	(209.85.216.173)
	by server-3.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Sep 2012 14:48:00 -0000
Received: by qcab12 with SMTP id b12so6045172qca.32
	for <xen-devel@lists.xen.org>; Mon, 17 Sep 2012 07:47:59 -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=c0sshydMfe4Z/5Yf0jQXADeGzX1eDj5S63JqY+Fb2o4=;
	b=fbX16YQBJPkijeQuycrnor7P9TmAr0PIFVoXymJR6GW0JPNHUzoKdiHxHxRU4D/IJj
	xARk5s4Zk3gQ0TfsEcc4tynjZ+u8MNyctsxRSD5bXZCodbmKT4c6pP8YN+/zmD+pIBJr
	tUuVngCRhq6t9n6xmytl+I/oXp3XaoB7nduj214GE+ooCxFDZjW4VAiyM6MzE/Q2z4Mg
	lb8rL8QODlsCDIpHKkga+WfhGeNEOTUgvh2NmWrgkLFpNR4a4dXiLSmafqi1szrGXMM1
	oampSOyvJowOKIzcq9PgRbM3HZwqrDakm5O2xB+IFPAFO01VxfCTqCMj1WeF2V6CBflq
	olsA==
Received: by 10.229.137.85 with SMTP id v21mr7318847qct.17.1347893278870;
	Mon, 17 Sep 2012 07:47:58 -0700 (PDT)
Received: from phenom.dumpdata.com
	(50-195-21-189-static.hfc.comcastbusiness.net. [50.195.21.189])
	by mx.google.com with ESMTPS id ck11sm6111106qab.17.2012.09.17.07.47.56
	(version=TLSv1/SSLv3 cipher=OTHER);
	Mon, 17 Sep 2012 07:47:57 -0700 (PDT)
Date: Mon, 17 Sep 2012 10:37:08 -0400
From: Konrad Rzeszutek Wilk <konrad@kernel.org>
To: "Duan, Ronghui" <ronghui.duan@intel.com>
Message-ID: <20120917143707.GD14012@phenom.dumpdata.com>
References: <A21691DE07B84740B5F0B81466D5148A23BCF1DF@SHSMSX102.ccr.corp.intel.com>
	<20120907174922.GA13040@phenom.dumpdata.com>
	<A21691DE07B84740B5F0B81466D5148A23BF6833@SHSMSX102.ccr.corp.intel.com>
	<5051A83B020000780009AF93@nat28.tlf.novell.com>
	<alpine.DEB.2.02.1209131203270.15568@kaball.uk.xensource.com>
	<20120913132335.GD16635@localhost.localdomain>
	<A21691DE07B84740B5F0B81466D5148A23BF6C1D@SHSMSX102.ccr.corp.intel.com>
	<A21691DE07B84740B5F0B81466D5148A23BF7E2F@SHSMSX102.ccr.corp.intel.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <A21691DE07B84740B5F0B81466D5148A23BF7E2F@SHSMSX102.ccr.corp.intel.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: "'xen-devel@lists.xen.org'" <xen-devel@lists.xen.org>,
	'Stefano Stabellini' <stefano.stabellini@eu.citrix.com>,
	'Ian Jackson' <Ian.Jackson@eu.citrix.com>,
	'Jan Beulich' <JBeulich@suse.com>,
	'Konrad Rzeszutek Wilk' <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [RFC v1 0/5] VBD: enlarge max segment per request
 in blkfront
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Sep 17, 2012 at 06:33:29AM +0000, Duan, Ronghui wrote:
> At last, I saw the regression in random io.
> This is a patch to fix the performance regression. Original the pending request members are allocated from the stack, I alloc them when each request arrives in my last patch. But it will hurt performance. In this fix, I alloc all of them when blkback init. But due to some bugs there, we can't free it, the same to other pending requests member. I am looking for the reason. But have no idea for this now. 

Right. When I implemented something similar to this (allocate at startup
those pools of pages), I had the same problem of freeing the grant array
blowing up the machine.

But... this was before
http://git.kernel.org/?p=linux/kernel/git/konrad/xen.git;a=commit;h=2fc136eecd0c647a6b13fcd00d0c41a1a28f35a5

- which might be the fix for this.

> Konrad, thanks for your comments. Could you have a try when you have time.
> 
> -ronghui
> 
> > -----Original Message-----
> > From: Duan, Ronghui
> > Sent: Thursday, September 13, 2012 10:06 PM
> > To: Konrad Rzeszutek Wilk; Stefano Stabellini
> > Cc: Jan Beulich; Ian Jackson; xen-devel@lists.xen.org
> > Subject: RE: [Xen-devel] [RFC v1 0/5] VBD: enlarge max segment per request in
> > blkfront
> > 
> > > > > But you certainly shouldn't be proposing features getting used
> > > > > unconditionally or by default that benefit one class of backing
> > > > > devices and severely penalize others.
> > > >
> > > > Right.
> > > > I am wondering.. Considering that the in-kernel blkback is mainly
> > > > used with physical partitions, is it possible that your patches
> > > > cause a regression with unmodified backends that don't support the
> > > > new protocol, like QEMU for example?
> > >
> > > Well for right now I am just using the most simple configuration to
> > > eliminate any extra variables (stacking of components). So my
> > > "testing" has been just on phy:/dev/sda,xvda,w with the sda being a Corsair
> > SSD.
> > 
> > I totally agree that we should not break others when enable what we want.
> > But just from my mind, the patch only have a little overhead in the
> > front/backend code path. It will induce pure random IO with a little overhead.
> > I tried the 4K read case, I just got 50MB/s w/o the patch. I need a more
> > powerful disk to verified it.
> > 
> > Ronghui
> > 
> > 
> > > -----Original Message-----
> > > From: Konrad Rzeszutek Wilk [mailto:konrad.wilk@oracle.com]
> > > Sent: Thursday, September 13, 2012 9:24 PM
> > > To: Stefano Stabellini
> > > Cc: Jan Beulich; Duan, Ronghui; Ian Jackson; xen-devel@lists.xen.org
> > > Subject: Re: [Xen-devel] [RFC v1 0/5] VBD: enlarge max segment per
> > > request in blkfront
> > >
> > > On Thu, Sep 13, 2012 at 12:05:35PM +0100, Stefano Stabellini wrote:
> > > > On Thu, 13 Sep 2012, Jan Beulich wrote:
> > > > > >>> On 13.09.12 at 04:28, "Duan, Ronghui" <ronghui.duan@intel.com> wrote:
> > > > > >> And with your patch got:
> > > > > >>   read : io=4096.0MB, bw=92606KB/s, iops=23151 , runt=
> > > > > >> 45292msec
> > > > > >>
> > > > > >> without:
> > > > > >>   read : io=4096.0MB, bw=145187KB/s, iops=36296 , runt=
> > > > > >> 28889msec
> > > > > >>
> > > > > > What type of backend file you are using? In order to remove the
> > > > > > influence of cache in Dom0, I use a physical partition as backend.
> > > > >
> > > > > But you certainly shouldn't be proposing features getting used
> > > > > unconditionally or by default that benefit one class of backing
> > > > > devices and severely penalize others.
> > > >
> > > > Right.
> > > > I am wondering.. Considering that the in-kernel blkback is mainly
> > > > used with physical partitions, is it possible that your patches
> > > > cause a regression with unmodified backends that don't support the
> > > > new protocol, like QEMU for example?
> > >
> > > Well for right now I am just using the most simple configuration to
> > > eliminate any extra variables (stacking of components). So my
> > > "testing" has been just on phy:/dev/sda,xvda,w with the sda being a Corsair
> > SSD.
> 


> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Sep 17 14:53:20 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 14: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 1TDchA-0002jv-UZ; Mon, 17 Sep 2012 14:53:08 +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 1TDch9-0002jn-RI
	for xen-devel@lists.xensource.com; Mon, 17 Sep 2012 14:53:08 +0000
Received: from [85.158.138.51:16018] by server-2.bemta-3.messagelabs.com id
	26/56-04862-25937505; Mon, 17 Sep 2012 14:53:06 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1347893586!30807072!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDk2NDU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6926 invoked from network); 17 Sep 2012 14:53:06 -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;
	17 Sep 2012 14:53:06 -0000
X-IronPort-AV: E=Sophos;i="4.80,435,1344211200"; d="scan'208";a="14584172"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Sep 2012 14:53:05 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Mon, 17 Sep 2012 15:53:06 +0100
Date: Mon, 17 Sep 2012 15:52: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: <20120917142315.GA12541@phenom.dumpdata.com>
Message-ID: <alpine.DEB.2.02.1209171550570.29232@kaball.uk.xensource.com>
References: <1347306367-28669-1-git-send-email-konrad.wilk@oracle.com>
	<1347306367-28669-11-git-send-email-konrad.wilk@oracle.com>
	<alpine.DEB.2.02.1209141709580.29232@kaball.uk.xensource.com>
	<20120917142315.GA12541@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 10/10] xen/swiotlb: Depending on
 after_bootmem is not 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 Mon, 17 Sep 2012, Konrad Rzeszutek Wilk wrote:
> > >  	start_dma_addr = xen_virt_to_bus(xen_io_tlb_start);
> > > -	if (!after_bootmem)
> > > +	rc = 0;
> >      ^
> > why does this change belong to this patch?
> > 
> > 
> 
> I took that out of the this patch, so it is now:
> 
> 
> >From c5bc5502abc0f70b682c0f2a70d08e6319825163 Mon Sep 17 00:00:00 2001
> From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> Date: Wed, 5 Sep 2012 13:35:47 -0400
> Subject: [PATCH 1/2] xen/swiotlb: Depending on after_bootmem is not correct.
> 
> When PCI IOMMUs are initialized it is after after_bootmem but
> before a lot of "other" subsystems are initialized. As such
> the check for after_bootmem is incorrect and we should
> just use a parameter to define whether we are early or late.

Given that the after_bootmem checks are introduced by patch 6/10, I
would just merge the two.
In any case, it looks OK now.



> This solves this bootup problem:
> 
> __ex_table already sorted, skipping sortM
> Initializing CPU#0
> Warning: only able to allocate 1 MB for software IO TLB
> Xen-SWIOTLB: Lowering to 2MB
> Warning: only able to allocate 1 MB for software IO TLB
> Xen-SWIOTLB: Lowering to 2MB
> Warning: only able to allocate 1 MB for software IO TLB
> Xen-SWIOTLB: Lowering to 2MB
> Warning: only able to allocate 1 MB for software IO TLB
> Cannot allocate Xen-SWIOTLB buffer (rc:-12)
> 
> [v1: Had rc=0 in it by mistake]
> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> ---
>  arch/x86/xen/pci-swiotlb-xen.c |    4 ++--
>  drivers/xen/swiotlb-xen.c      |   10 +++++-----
>  include/xen/swiotlb-xen.h      |    2 +-
>  3 files changed, 8 insertions(+), 8 deletions(-)
> 
> diff --git a/arch/x86/xen/pci-swiotlb-xen.c b/arch/x86/xen/pci-swiotlb-xen.c
> index fc0c78f..1608244 100644
> --- a/arch/x86/xen/pci-swiotlb-xen.c
> +++ b/arch/x86/xen/pci-swiotlb-xen.c
> @@ -69,7 +69,7 @@ int __init pci_xen_swiotlb_detect(void)
>  void __init pci_xen_swiotlb_init(void)
>  {
>  	if (xen_swiotlb) {
> -		xen_swiotlb_init(1);
> +		xen_swiotlb_init(1, true /* early */);
>  		dma_ops = &xen_swiotlb_dma_ops;
>  
>  		/* Make sure ACS will be enabled */
> @@ -84,7 +84,7 @@ int pci_xen_swiotlb_init_late(void)
>  	if (xen_swiotlb)
>  		return 0;
>  
> -	rc = xen_swiotlb_init(1);
> +	rc = xen_swiotlb_init(1, false /* late */);
>  	if (rc)
>  		return rc;
>  
> diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
> index 6f81994..02a52f3 100644
> --- a/drivers/xen/swiotlb-xen.c
> +++ b/drivers/xen/swiotlb-xen.c
> @@ -176,7 +176,7 @@ static const char *xen_swiotlb_error(enum xen_swiotlb_err err)
>  	}
>  	return "";
>  }
> -int __ref xen_swiotlb_init(int verbose)
> +int __ref xen_swiotlb_init(int verbose, bool early)
>  {
>  	unsigned long bytes, order;
>  	int rc = -ENOMEM;
> @@ -190,7 +190,7 @@ retry:
>  	/*
>  	 * Get IO TLB memory from any location.
>  	 */
> -	if (!after_bootmem)
> +	if (early)
>  		xen_io_tlb_start = alloc_bootmem_pages(PAGE_ALIGN(bytes));
>  	else {
>  #define SLABS_PER_PAGE (1 << (PAGE_SHIFT - IO_TLB_SHIFT))
> @@ -220,7 +220,7 @@ retry:
>  			       bytes,
>  			       xen_io_tlb_nslabs);
>  	if (rc) {
> -		if (!after_bootmem)
> +		if (early)
>  			free_bootmem(__pa(xen_io_tlb_start), PAGE_ALIGN(bytes));
>  		else {
>  			free_pages((unsigned long)xen_io_tlb_start, order);
> @@ -230,7 +230,7 @@ retry:
>  		goto error;
>  	}
>  	start_dma_addr = xen_virt_to_bus(xen_io_tlb_start);
> -	if (!after_bootmem)
> +	if (early)
>  		swiotlb_init_with_tbl(xen_io_tlb_start, xen_io_tlb_nslabs, verbose);
>  	else
>  		rc = swiotlb_late_init_with_tbl(xen_io_tlb_start, xen_io_tlb_nslabs);
> @@ -244,7 +244,7 @@ error:
>  		goto retry;
>  	}
>  	pr_err("%s (rc:%d)", xen_swiotlb_error(m_ret), rc);
> -	if (!after_bootmem)
> +	if (early)
>  		panic("%s (rc:%d)", xen_swiotlb_error(m_ret), rc);
>  	else
>  		free_pages((unsigned long)xen_io_tlb_start, order);
> diff --git a/include/xen/swiotlb-xen.h b/include/xen/swiotlb-xen.h
> index a0db2b7..de8bcc6 100644
> --- a/include/xen/swiotlb-xen.h
> +++ b/include/xen/swiotlb-xen.h
> @@ -3,7 +3,7 @@
>  
>  #include <linux/swiotlb.h>
>  
> -extern int xen_swiotlb_init(int verbose);
> +extern int xen_swiotlb_init(int verbose, bool early);
>  
>  extern void
>  *xen_swiotlb_alloc_coherent(struct device *hwdev, size_t size,
> -- 
> 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 Sep 17 14:53:20 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 14: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 1TDchA-0002jv-UZ; Mon, 17 Sep 2012 14:53:08 +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 1TDch9-0002jn-RI
	for xen-devel@lists.xensource.com; Mon, 17 Sep 2012 14:53:08 +0000
Received: from [85.158.138.51:16018] by server-2.bemta-3.messagelabs.com id
	26/56-04862-25937505; Mon, 17 Sep 2012 14:53:06 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1347893586!30807072!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDk2NDU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6926 invoked from network); 17 Sep 2012 14:53:06 -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;
	17 Sep 2012 14:53:06 -0000
X-IronPort-AV: E=Sophos;i="4.80,435,1344211200"; d="scan'208";a="14584172"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Sep 2012 14:53:05 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Mon, 17 Sep 2012 15:53:06 +0100
Date: Mon, 17 Sep 2012 15:52: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: <20120917142315.GA12541@phenom.dumpdata.com>
Message-ID: <alpine.DEB.2.02.1209171550570.29232@kaball.uk.xensource.com>
References: <1347306367-28669-1-git-send-email-konrad.wilk@oracle.com>
	<1347306367-28669-11-git-send-email-konrad.wilk@oracle.com>
	<alpine.DEB.2.02.1209141709580.29232@kaball.uk.xensource.com>
	<20120917142315.GA12541@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 10/10] xen/swiotlb: Depending on
 after_bootmem is not 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 Mon, 17 Sep 2012, Konrad Rzeszutek Wilk wrote:
> > >  	start_dma_addr = xen_virt_to_bus(xen_io_tlb_start);
> > > -	if (!after_bootmem)
> > > +	rc = 0;
> >      ^
> > why does this change belong to this patch?
> > 
> > 
> 
> I took that out of the this patch, so it is now:
> 
> 
> >From c5bc5502abc0f70b682c0f2a70d08e6319825163 Mon Sep 17 00:00:00 2001
> From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> Date: Wed, 5 Sep 2012 13:35:47 -0400
> Subject: [PATCH 1/2] xen/swiotlb: Depending on after_bootmem is not correct.
> 
> When PCI IOMMUs are initialized it is after after_bootmem but
> before a lot of "other" subsystems are initialized. As such
> the check for after_bootmem is incorrect and we should
> just use a parameter to define whether we are early or late.

Given that the after_bootmem checks are introduced by patch 6/10, I
would just merge the two.
In any case, it looks OK now.



> This solves this bootup problem:
> 
> __ex_table already sorted, skipping sortM
> Initializing CPU#0
> Warning: only able to allocate 1 MB for software IO TLB
> Xen-SWIOTLB: Lowering to 2MB
> Warning: only able to allocate 1 MB for software IO TLB
> Xen-SWIOTLB: Lowering to 2MB
> Warning: only able to allocate 1 MB for software IO TLB
> Xen-SWIOTLB: Lowering to 2MB
> Warning: only able to allocate 1 MB for software IO TLB
> Cannot allocate Xen-SWIOTLB buffer (rc:-12)
> 
> [v1: Had rc=0 in it by mistake]
> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> ---
>  arch/x86/xen/pci-swiotlb-xen.c |    4 ++--
>  drivers/xen/swiotlb-xen.c      |   10 +++++-----
>  include/xen/swiotlb-xen.h      |    2 +-
>  3 files changed, 8 insertions(+), 8 deletions(-)
> 
> diff --git a/arch/x86/xen/pci-swiotlb-xen.c b/arch/x86/xen/pci-swiotlb-xen.c
> index fc0c78f..1608244 100644
> --- a/arch/x86/xen/pci-swiotlb-xen.c
> +++ b/arch/x86/xen/pci-swiotlb-xen.c
> @@ -69,7 +69,7 @@ int __init pci_xen_swiotlb_detect(void)
>  void __init pci_xen_swiotlb_init(void)
>  {
>  	if (xen_swiotlb) {
> -		xen_swiotlb_init(1);
> +		xen_swiotlb_init(1, true /* early */);
>  		dma_ops = &xen_swiotlb_dma_ops;
>  
>  		/* Make sure ACS will be enabled */
> @@ -84,7 +84,7 @@ int pci_xen_swiotlb_init_late(void)
>  	if (xen_swiotlb)
>  		return 0;
>  
> -	rc = xen_swiotlb_init(1);
> +	rc = xen_swiotlb_init(1, false /* late */);
>  	if (rc)
>  		return rc;
>  
> diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
> index 6f81994..02a52f3 100644
> --- a/drivers/xen/swiotlb-xen.c
> +++ b/drivers/xen/swiotlb-xen.c
> @@ -176,7 +176,7 @@ static const char *xen_swiotlb_error(enum xen_swiotlb_err err)
>  	}
>  	return "";
>  }
> -int __ref xen_swiotlb_init(int verbose)
> +int __ref xen_swiotlb_init(int verbose, bool early)
>  {
>  	unsigned long bytes, order;
>  	int rc = -ENOMEM;
> @@ -190,7 +190,7 @@ retry:
>  	/*
>  	 * Get IO TLB memory from any location.
>  	 */
> -	if (!after_bootmem)
> +	if (early)
>  		xen_io_tlb_start = alloc_bootmem_pages(PAGE_ALIGN(bytes));
>  	else {
>  #define SLABS_PER_PAGE (1 << (PAGE_SHIFT - IO_TLB_SHIFT))
> @@ -220,7 +220,7 @@ retry:
>  			       bytes,
>  			       xen_io_tlb_nslabs);
>  	if (rc) {
> -		if (!after_bootmem)
> +		if (early)
>  			free_bootmem(__pa(xen_io_tlb_start), PAGE_ALIGN(bytes));
>  		else {
>  			free_pages((unsigned long)xen_io_tlb_start, order);
> @@ -230,7 +230,7 @@ retry:
>  		goto error;
>  	}
>  	start_dma_addr = xen_virt_to_bus(xen_io_tlb_start);
> -	if (!after_bootmem)
> +	if (early)
>  		swiotlb_init_with_tbl(xen_io_tlb_start, xen_io_tlb_nslabs, verbose);
>  	else
>  		rc = swiotlb_late_init_with_tbl(xen_io_tlb_start, xen_io_tlb_nslabs);
> @@ -244,7 +244,7 @@ error:
>  		goto retry;
>  	}
>  	pr_err("%s (rc:%d)", xen_swiotlb_error(m_ret), rc);
> -	if (!after_bootmem)
> +	if (early)
>  		panic("%s (rc:%d)", xen_swiotlb_error(m_ret), rc);
>  	else
>  		free_pages((unsigned long)xen_io_tlb_start, order);
> diff --git a/include/xen/swiotlb-xen.h b/include/xen/swiotlb-xen.h
> index a0db2b7..de8bcc6 100644
> --- a/include/xen/swiotlb-xen.h
> +++ b/include/xen/swiotlb-xen.h
> @@ -3,7 +3,7 @@
>  
>  #include <linux/swiotlb.h>
>  
> -extern int xen_swiotlb_init(int verbose);
> +extern int xen_swiotlb_init(int verbose, bool early);
>  
>  extern void
>  *xen_swiotlb_alloc_coherent(struct device *hwdev, size_t size,
> -- 
> 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 Sep 17 14:54:09 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 14:54: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 1TDchz-0002oB-Id; Mon, 17 Sep 2012 14:53:59 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1TDchx-0002nt-Fr
	for xen-devel@lists.xensource.com; Mon, 17 Sep 2012 14:53:57 +0000
Received: from [85.158.139.211:11293] by server-4.bemta-5.messagelabs.com id
	0D/A0-23042-48937505; Mon, 17 Sep 2012 14:53:56 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-8.tower-206.messagelabs.com!1347893636!18868509!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDk2NDU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26738 invoked from network); 17 Sep 2012 14:53:56 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Sep 2012 14:53:56 -0000
X-IronPort-AV: E=Sophos;i="4.80,435,1344211200"; d="scan'208";a="14584195"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Sep 2012 14:53: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.279.1; Mon, 17 Sep 2012 15:53:56 +0100
Date: Mon, 17 Sep 2012 15:53:10 +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: <20120917142502.GB12541@phenom.dumpdata.com>
Message-ID: <alpine.DEB.2.02.1209171553030.29232@kaball.uk.xensource.com>
References: <1347306367-28669-1-git-send-email-konrad.wilk@oracle.com>
	<1347306367-28669-11-git-send-email-konrad.wilk@oracle.com>
	<alpine.DEB.2.02.1209141709580.29232@kaball.uk.xensource.com>
	<20120917142315.GA12541@phenom.dumpdata.com>
	<20120917142502.GB12541@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] Is: [PATCH 11/10] xen/swiotlb: For early
 initialization,
 return zero on success. Was: Re: [PATCH 10/10] xen/swiotlb: Depending on
 after_bootmem is not 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 Mon, 17 Sep 2012, Konrad Rzeszutek Wilk wrote:
> On Mon, Sep 17, 2012 at 10:23:15AM -0400, Konrad Rzeszutek Wilk wrote:
> > > >  	start_dma_addr = xen_virt_to_bus(xen_io_tlb_start);
> > > > -	if (!after_bootmem)
> > > > +	rc = 0;
> > >      ^
> > > why does this change belong to this patch?
> > > 
> > > 
> > 
> > I took that out of the this patch, so it is now:
> > 
> 
> ..and spun out another patch to address the rc=0:
> 
> >From f85175ce01ba722cd4612230e7331dc0d4c8666f Mon Sep 17 00:00:00 2001
> From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> Date: Mon, 17 Sep 2012 10:20:09 -0400
> Subject: [PATCH 2/2] xen/swiotlb: For early initialization, return zero on
>  success.
> 
> If everything is setup properly we would return -ENOMEM since
> rc by default is set to that value. Lets not do that and return
> a proper return code.
> 
> Note: The reason the early code needs this special treatment
> is that it SWIOTLB library call does not return anything (and
> had it failed it would call panic()) - but our function does.
> 
> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>


Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

>  drivers/xen/swiotlb-xen.c |    5 +++--
>  1 files changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
> index 02a52f3..ab4c66c 100644
> --- a/drivers/xen/swiotlb-xen.c
> +++ b/drivers/xen/swiotlb-xen.c
> @@ -230,9 +230,10 @@ retry:
>  		goto error;
>  	}
>  	start_dma_addr = xen_virt_to_bus(xen_io_tlb_start);
> -	if (early)
> +	if (early) {
>  		swiotlb_init_with_tbl(xen_io_tlb_start, xen_io_tlb_nslabs, verbose);
> -	else
> +		rc = 0;
> +	} else
>  		rc = swiotlb_late_init_with_tbl(xen_io_tlb_start, xen_io_tlb_nslabs);
>  	return rc;
>  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 Sep 17 14:54:09 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 14:54: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 1TDchz-0002oB-Id; Mon, 17 Sep 2012 14:53:59 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1TDchx-0002nt-Fr
	for xen-devel@lists.xensource.com; Mon, 17 Sep 2012 14:53:57 +0000
Received: from [85.158.139.211:11293] by server-4.bemta-5.messagelabs.com id
	0D/A0-23042-48937505; Mon, 17 Sep 2012 14:53:56 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-8.tower-206.messagelabs.com!1347893636!18868509!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDk2NDU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26738 invoked from network); 17 Sep 2012 14:53:56 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Sep 2012 14:53:56 -0000
X-IronPort-AV: E=Sophos;i="4.80,435,1344211200"; d="scan'208";a="14584195"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Sep 2012 14:53: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.279.1; Mon, 17 Sep 2012 15:53:56 +0100
Date: Mon, 17 Sep 2012 15:53:10 +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: <20120917142502.GB12541@phenom.dumpdata.com>
Message-ID: <alpine.DEB.2.02.1209171553030.29232@kaball.uk.xensource.com>
References: <1347306367-28669-1-git-send-email-konrad.wilk@oracle.com>
	<1347306367-28669-11-git-send-email-konrad.wilk@oracle.com>
	<alpine.DEB.2.02.1209141709580.29232@kaball.uk.xensource.com>
	<20120917142315.GA12541@phenom.dumpdata.com>
	<20120917142502.GB12541@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] Is: [PATCH 11/10] xen/swiotlb: For early
 initialization,
 return zero on success. Was: Re: [PATCH 10/10] xen/swiotlb: Depending on
 after_bootmem is not 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 Mon, 17 Sep 2012, Konrad Rzeszutek Wilk wrote:
> On Mon, Sep 17, 2012 at 10:23:15AM -0400, Konrad Rzeszutek Wilk wrote:
> > > >  	start_dma_addr = xen_virt_to_bus(xen_io_tlb_start);
> > > > -	if (!after_bootmem)
> > > > +	rc = 0;
> > >      ^
> > > why does this change belong to this patch?
> > > 
> > > 
> > 
> > I took that out of the this patch, so it is now:
> > 
> 
> ..and spun out another patch to address the rc=0:
> 
> >From f85175ce01ba722cd4612230e7331dc0d4c8666f Mon Sep 17 00:00:00 2001
> From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> Date: Mon, 17 Sep 2012 10:20:09 -0400
> Subject: [PATCH 2/2] xen/swiotlb: For early initialization, return zero on
>  success.
> 
> If everything is setup properly we would return -ENOMEM since
> rc by default is set to that value. Lets not do that and return
> a proper return code.
> 
> Note: The reason the early code needs this special treatment
> is that it SWIOTLB library call does not return anything (and
> had it failed it would call panic()) - but our function does.
> 
> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>


Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

>  drivers/xen/swiotlb-xen.c |    5 +++--
>  1 files changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
> index 02a52f3..ab4c66c 100644
> --- a/drivers/xen/swiotlb-xen.c
> +++ b/drivers/xen/swiotlb-xen.c
> @@ -230,9 +230,10 @@ retry:
>  		goto error;
>  	}
>  	start_dma_addr = xen_virt_to_bus(xen_io_tlb_start);
> -	if (early)
> +	if (early) {
>  		swiotlb_init_with_tbl(xen_io_tlb_start, xen_io_tlb_nslabs, verbose);
> -	else
> +		rc = 0;
> +	} else
>  		rc = swiotlb_late_init_with_tbl(xen_io_tlb_start, xen_io_tlb_nslabs);
>  	return rc;
>  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 Sep 17 15:03:17 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 15:03:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDcqg-0003F9-19; Mon, 17 Sep 2012 15:02:58 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jmarcet@gmail.com>) id 1TDcqe-0003F4-8F
	for xen-devel@lists.xen.org; Mon, 17 Sep 2012 15:02:56 +0000
Received: from [85.158.138.51:5543] by server-8.bemta-3.messagelabs.com id
	83/97-24700-F9B37505; Mon, 17 Sep 2012 15:02:55 +0000
X-Env-Sender: jmarcet@gmail.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1347894169!30877410!1
X-Originating-IP: [209.85.214.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28708 invoked from network); 17 Sep 2012 15:02:51 -0000
Received: from mail-ob0-f173.google.com (HELO mail-ob0-f173.google.com)
	(209.85.214.173)
	by server-11.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Sep 2012 15:02:51 -0000
Received: by obbta14 with SMTP id ta14so11404371obb.32
	for <xen-devel@lists.xen.org>; Mon, 17 Sep 2012 08:02:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to
	:cc:content-type:content-transfer-encoding;
	bh=qzAzj5ddBHZ0kB3kIiNdozhQY8nlOrBIh/lK7ziBtCI=;
	b=D9JbAWVuSqjcl4rRalHgYjNY14jm6E3jgEgu1tImNdkfIpsR9Mxy/2WB39pZQDktCn
	x+7ww7KqEZ5bzeHaSVP+BBZJkJULEWq8qiCMSLTMswEFIZfjiURuwYCj33A/9eUam5lf
	U8AgnGIEt9XJDDCB5DrbhdVj/wKpvsVGLrJnSh6x/i6e08LMVhJeI8kdAQgDLsyY15vJ
	CRai8mR4lfqn7QEcfACa5l+zhQxGc8rm1B4hfX4hgklyPe6fm8nBHzWofkiI7FSfrCiW
	eol7DJFDWW8sGGAgr5KkRlmd2UW2SMvVkV0O9H0OMXXUUyWoAe5+y0eAzhrO7fxh7N2v
	Vy7Q==
Received: by 10.60.22.103 with SMTP id c7mr11636187oef.75.1347894169148; Mon,
	17 Sep 2012 08:02:49 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.60.138.225 with HTTP; Mon, 17 Sep 2012 08:02:28 -0700 (PDT)
In-Reply-To: <20120917142851.GB14012@phenom.dumpdata.com>
References: <CAAnFQG9TZj=SxYK_jxqN=M6L40vL=AZu9EM2tbEffPhkL1s8FA@mail.gmail.com>
	<CACJDEmqdqA6CE9SgLL2QCNmQH1dOX0_4OHfJfzes+G6bEkQ7FA@mail.gmail.com>
	<CAAnFQG-8Fkunv6R8+GCLAH4yQCx4-Nn0zN_Ntsf0wsh5yXeihQ@mail.gmail.com>
	<20120917142851.GB14012@phenom.dumpdata.com>
From: Javier Marcet <jmarcet@gmail.com>
Date: Mon, 17 Sep 2012 17:02:28 +0200
Message-ID: <CAAnFQG8RqOra=e60OrZGeny55-gfm0nuveczc0R0rmVAJZUx7A@mail.gmail.com>
To: Konrad Rzeszutek Wilk <konrad@kernel.org>
Cc: Xen Devel Mailing list <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.2.0-rc4 issues with DVB tuner
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gTW9uLCBTZXAgMTcsIDIwMTIgYXQgNDoyOCBQTSwgS29ucmFkIFJ6ZXN6dXRlayBXaWxrCjxr
b25yYWRAa2VybmVsLm9yZz4gd3JvdGU6Cgo+PiA+PiBUaGlzIGxhc3QgcG9pbnQgaXMgYSBzaG93
c3RvcHBlciBmb3IgbWUgYW5kIEkgZG9uwrR0IGtub3cgd2hlcmUgdGhlCj4+ID4+IHByb2JsZW0g
bWlnaHQgY29tZSBmcm9tLiBUaGUgY3gyMzg4NSBtb2R1bGUgKHdoaWNoIG15IHR1bmVycyB1c2Up
Cj4+ID4+IGxvYWRzIGZpbmUsIGFzIGRvIHRoZSBkZXZpY2VzIHVuZGVyIC9kZXYvZHZiLiBVcG9u
IHR1bmluZyBhIGNoYW5uZWwsCj4+ID4+IGhvd2V2ZXIsIHRoZXJlIGlzIG5vdCBkYXRhIHJlY2Vp
dmVkLgo+PiA+Pgo+PiA+PiBEb2VzIGFueW9uZSBoYXZlIHRoZSBzbGlnaHRlc3QgaWRlYSB3aGF0
IG1pZ2h0IGJlIGNhdXNpbmcgdGhpcz8KPj4gPgo+PiA+IEFyZSB0aGVyZSBhbnkgd2FybmluZ3Mg
b3Igc3VjaCBiZWluZyBwcmludGVkPyBBcmUgdGhlIGludGVycnVwdHMgaW5jcmVhc2luZz8KPj4g
PiBEb2VzIGxzcGNpIHNob3cgYW55dGhpbmcgJ2Rpc2FibGVkJyBpbiB0aGUgZ3Vlc3Q/Cj4+Cj4+
IFlvdSBoYXZlIG1pc3VuZGVyc3Rvb2QgbWUuIEkgd2FzIHRyeWluZyB0byBhY2Nlc3MgdGhlIGR2
YiB0dW5lcnMgZnJvbSB0aGUgZG9tMC4KPgo+IEFoLgo+Pgo+PiBVc2luZyBrdm0gSSBoYXZlIHN1
Y2Vzc2Z1bGx5IHBhc3N0aHJvdWdoIGEgc2F0YSBjb250cm9sbGVyLCBidXQgaGF2ZSBzb21lIGlz
c3Vlcwo+PiBwYXNzaW4gdGhyb3VnaCB0aGUgZHZiIHR1bmVyLgo+Pgo+PiA+PiBJIHdvbmRlciB3
aGV0aGVyIGl0IHdvdWxkIHdvcmsgd2l0aGluIGEgRG9tVSB3aXRoIHRoZSBQQ0llIHR1bmVyCj4+
ID4+IHBhc3NlZCB0aHJvdWdoLgo+PiA+Cj4+ID4gSSd2ZSBhIDQgY2hhbm5lbCBzZWN1cml0eSBj
YXJkIHBhc3NlZCBpbiBhbmQgaXQgd29ya3MgbmljZWx5LiBUaGUKPj4gPiB0cmljayBpcyB0aGF0
IHlvdSBuZWVkICdpb21tdT1zb2Z0JyBvbiB0aGUgZG9tVSBjb21tYW5kIGxpbmUuCj4+Cj4+IEFs
bCByaWdodC4gQnV0IGlzIGl0IG5vcm1hbCB0aGF0IGl0IGRvZXMgbm90IHdvcmsgdW5kZXIgdGhl
IGRvbTA/Cj4KPiBOby4gUFYgZG9tVSBhbmQgUFYgZG9tMCBhcmUgcHJldHR5IG11Y2ggdGhlIHNh
bWUgaW4gdGhlIHdheSBvZiBoYW5kbGluZwo+IGludGVycnVwdHMsIHBvcnRzLCBldGMuCgpKdXN0
IGFzIEkgZ3Vlc3NlZC4KCj4gSWYgeW91IGNyYW5rIHVwIHRoZSBkZWJ1ZyBsZXZlbCBvZiB0aGUg
a2VybmVsIChkZWJ1ZyBsb2dsZXZlbD04KSBhbmQKPiBvZiB0aGUgZHJpdmVyIGRvIHlvdSBnZXQg
YW55dGhpbmcgb2J2aW91cz8gV2hhdCBhYm91dCB0aGUgcXVlc3Rpb25zCj4gSSd2ZSBhc2tlZD8K
ClNvIGZhciBJIGhhdmVuJ3QgZm91bmQgYW55dGhpbmcgd29ydGggbWVudGlvbmluZy4KCkFsbCBw
Y2kgZGV2aWNlcyBhcmUgZW5hYmxlZCwgaW50ZXJydXB0cyBsb29rIG5vcm1hbCBhbmQgdGhlcmUg
aXNuJ3QgYW55CmtpbmQgb2Ygd2FybmluZyBvciBlcnJvciBtZXNzYWdlLiBUaGUgb25seSB0aGlu
ZyB5b3Ugbm90aWNlIGlzIHRoYXQKdGhlIHR1bmVyIHByb2R1Y2VzIG5lYXJseSBubyBkYXRhLiBJ
IHNheSBuZWFybHkgYmVjYXVzZSB5b3UgZ2V0IHNvbWUKYnl0ZXMsIGFsYmVpdCBub3RoaW5nIGxp
a2UgdGhlIHNldmVyYWwgbWVnYWJpdHMgcGVyIHNlY29uZCBpdCBzaG91bGQgb3V0cHV0LgoKSSds
bCB0cnkgaW5jcmVhc2luZyB0aGUgZGVidWcgbGV2ZWwgYW5kIHJlcG9ydCBiYWNrLgoKQnkgdGhl
IHdheSwgdGhhdCBwcm9ibGVtIEkgaGFkIGFib3V0IHRoZSBjcHUgY2FwYWJpbGl0aWVzIGlzIG5v
dCBYZW4ncyBmYXVsdCwKaXQgaXMgYSBidWcgd2l0aGluIGxpYnZpcnQuCgoKLS0gCkphdmllciBN
YXJjZXQgPGptYXJjZXRAZ21haWwuY29tPgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMu
eGVuLm9yZwpodHRwOi8vbGlzdHMueGVuLm9yZy94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xen.org Mon Sep 17 15:03:17 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 15:03:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDcqg-0003F9-19; Mon, 17 Sep 2012 15:02:58 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jmarcet@gmail.com>) id 1TDcqe-0003F4-8F
	for xen-devel@lists.xen.org; Mon, 17 Sep 2012 15:02:56 +0000
Received: from [85.158.138.51:5543] by server-8.bemta-3.messagelabs.com id
	83/97-24700-F9B37505; Mon, 17 Sep 2012 15:02:55 +0000
X-Env-Sender: jmarcet@gmail.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1347894169!30877410!1
X-Originating-IP: [209.85.214.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28708 invoked from network); 17 Sep 2012 15:02:51 -0000
Received: from mail-ob0-f173.google.com (HELO mail-ob0-f173.google.com)
	(209.85.214.173)
	by server-11.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Sep 2012 15:02:51 -0000
Received: by obbta14 with SMTP id ta14so11404371obb.32
	for <xen-devel@lists.xen.org>; Mon, 17 Sep 2012 08:02:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to
	:cc:content-type:content-transfer-encoding;
	bh=qzAzj5ddBHZ0kB3kIiNdozhQY8nlOrBIh/lK7ziBtCI=;
	b=D9JbAWVuSqjcl4rRalHgYjNY14jm6E3jgEgu1tImNdkfIpsR9Mxy/2WB39pZQDktCn
	x+7ww7KqEZ5bzeHaSVP+BBZJkJULEWq8qiCMSLTMswEFIZfjiURuwYCj33A/9eUam5lf
	U8AgnGIEt9XJDDCB5DrbhdVj/wKpvsVGLrJnSh6x/i6e08LMVhJeI8kdAQgDLsyY15vJ
	CRai8mR4lfqn7QEcfACa5l+zhQxGc8rm1B4hfX4hgklyPe6fm8nBHzWofkiI7FSfrCiW
	eol7DJFDWW8sGGAgr5KkRlmd2UW2SMvVkV0O9H0OMXXUUyWoAe5+y0eAzhrO7fxh7N2v
	Vy7Q==
Received: by 10.60.22.103 with SMTP id c7mr11636187oef.75.1347894169148; Mon,
	17 Sep 2012 08:02:49 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.60.138.225 with HTTP; Mon, 17 Sep 2012 08:02:28 -0700 (PDT)
In-Reply-To: <20120917142851.GB14012@phenom.dumpdata.com>
References: <CAAnFQG9TZj=SxYK_jxqN=M6L40vL=AZu9EM2tbEffPhkL1s8FA@mail.gmail.com>
	<CACJDEmqdqA6CE9SgLL2QCNmQH1dOX0_4OHfJfzes+G6bEkQ7FA@mail.gmail.com>
	<CAAnFQG-8Fkunv6R8+GCLAH4yQCx4-Nn0zN_Ntsf0wsh5yXeihQ@mail.gmail.com>
	<20120917142851.GB14012@phenom.dumpdata.com>
From: Javier Marcet <jmarcet@gmail.com>
Date: Mon, 17 Sep 2012 17:02:28 +0200
Message-ID: <CAAnFQG8RqOra=e60OrZGeny55-gfm0nuveczc0R0rmVAJZUx7A@mail.gmail.com>
To: Konrad Rzeszutek Wilk <konrad@kernel.org>
Cc: Xen Devel Mailing list <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.2.0-rc4 issues with DVB tuner
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gTW9uLCBTZXAgMTcsIDIwMTIgYXQgNDoyOCBQTSwgS29ucmFkIFJ6ZXN6dXRlayBXaWxrCjxr
b25yYWRAa2VybmVsLm9yZz4gd3JvdGU6Cgo+PiA+PiBUaGlzIGxhc3QgcG9pbnQgaXMgYSBzaG93
c3RvcHBlciBmb3IgbWUgYW5kIEkgZG9uwrR0IGtub3cgd2hlcmUgdGhlCj4+ID4+IHByb2JsZW0g
bWlnaHQgY29tZSBmcm9tLiBUaGUgY3gyMzg4NSBtb2R1bGUgKHdoaWNoIG15IHR1bmVycyB1c2Up
Cj4+ID4+IGxvYWRzIGZpbmUsIGFzIGRvIHRoZSBkZXZpY2VzIHVuZGVyIC9kZXYvZHZiLiBVcG9u
IHR1bmluZyBhIGNoYW5uZWwsCj4+ID4+IGhvd2V2ZXIsIHRoZXJlIGlzIG5vdCBkYXRhIHJlY2Vp
dmVkLgo+PiA+Pgo+PiA+PiBEb2VzIGFueW9uZSBoYXZlIHRoZSBzbGlnaHRlc3QgaWRlYSB3aGF0
IG1pZ2h0IGJlIGNhdXNpbmcgdGhpcz8KPj4gPgo+PiA+IEFyZSB0aGVyZSBhbnkgd2FybmluZ3Mg
b3Igc3VjaCBiZWluZyBwcmludGVkPyBBcmUgdGhlIGludGVycnVwdHMgaW5jcmVhc2luZz8KPj4g
PiBEb2VzIGxzcGNpIHNob3cgYW55dGhpbmcgJ2Rpc2FibGVkJyBpbiB0aGUgZ3Vlc3Q/Cj4+Cj4+
IFlvdSBoYXZlIG1pc3VuZGVyc3Rvb2QgbWUuIEkgd2FzIHRyeWluZyB0byBhY2Nlc3MgdGhlIGR2
YiB0dW5lcnMgZnJvbSB0aGUgZG9tMC4KPgo+IEFoLgo+Pgo+PiBVc2luZyBrdm0gSSBoYXZlIHN1
Y2Vzc2Z1bGx5IHBhc3N0aHJvdWdoIGEgc2F0YSBjb250cm9sbGVyLCBidXQgaGF2ZSBzb21lIGlz
c3Vlcwo+PiBwYXNzaW4gdGhyb3VnaCB0aGUgZHZiIHR1bmVyLgo+Pgo+PiA+PiBJIHdvbmRlciB3
aGV0aGVyIGl0IHdvdWxkIHdvcmsgd2l0aGluIGEgRG9tVSB3aXRoIHRoZSBQQ0llIHR1bmVyCj4+
ID4+IHBhc3NlZCB0aHJvdWdoLgo+PiA+Cj4+ID4gSSd2ZSBhIDQgY2hhbm5lbCBzZWN1cml0eSBj
YXJkIHBhc3NlZCBpbiBhbmQgaXQgd29ya3MgbmljZWx5LiBUaGUKPj4gPiB0cmljayBpcyB0aGF0
IHlvdSBuZWVkICdpb21tdT1zb2Z0JyBvbiB0aGUgZG9tVSBjb21tYW5kIGxpbmUuCj4+Cj4+IEFs
bCByaWdodC4gQnV0IGlzIGl0IG5vcm1hbCB0aGF0IGl0IGRvZXMgbm90IHdvcmsgdW5kZXIgdGhl
IGRvbTA/Cj4KPiBOby4gUFYgZG9tVSBhbmQgUFYgZG9tMCBhcmUgcHJldHR5IG11Y2ggdGhlIHNh
bWUgaW4gdGhlIHdheSBvZiBoYW5kbGluZwo+IGludGVycnVwdHMsIHBvcnRzLCBldGMuCgpKdXN0
IGFzIEkgZ3Vlc3NlZC4KCj4gSWYgeW91IGNyYW5rIHVwIHRoZSBkZWJ1ZyBsZXZlbCBvZiB0aGUg
a2VybmVsIChkZWJ1ZyBsb2dsZXZlbD04KSBhbmQKPiBvZiB0aGUgZHJpdmVyIGRvIHlvdSBnZXQg
YW55dGhpbmcgb2J2aW91cz8gV2hhdCBhYm91dCB0aGUgcXVlc3Rpb25zCj4gSSd2ZSBhc2tlZD8K
ClNvIGZhciBJIGhhdmVuJ3QgZm91bmQgYW55dGhpbmcgd29ydGggbWVudGlvbmluZy4KCkFsbCBw
Y2kgZGV2aWNlcyBhcmUgZW5hYmxlZCwgaW50ZXJydXB0cyBsb29rIG5vcm1hbCBhbmQgdGhlcmUg
aXNuJ3QgYW55CmtpbmQgb2Ygd2FybmluZyBvciBlcnJvciBtZXNzYWdlLiBUaGUgb25seSB0aGlu
ZyB5b3Ugbm90aWNlIGlzIHRoYXQKdGhlIHR1bmVyIHByb2R1Y2VzIG5lYXJseSBubyBkYXRhLiBJ
IHNheSBuZWFybHkgYmVjYXVzZSB5b3UgZ2V0IHNvbWUKYnl0ZXMsIGFsYmVpdCBub3RoaW5nIGxp
a2UgdGhlIHNldmVyYWwgbWVnYWJpdHMgcGVyIHNlY29uZCBpdCBzaG91bGQgb3V0cHV0LgoKSSds
bCB0cnkgaW5jcmVhc2luZyB0aGUgZGVidWcgbGV2ZWwgYW5kIHJlcG9ydCBiYWNrLgoKQnkgdGhl
IHdheSwgdGhhdCBwcm9ibGVtIEkgaGFkIGFib3V0IHRoZSBjcHUgY2FwYWJpbGl0aWVzIGlzIG5v
dCBYZW4ncyBmYXVsdCwKaXQgaXMgYSBidWcgd2l0aGluIGxpYnZpcnQuCgoKLS0gCkphdmllciBN
YXJjZXQgPGptYXJjZXRAZ21haWwuY29tPgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMu
eGVuLm9yZwpodHRwOi8vbGlzdHMueGVuLm9yZy94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xen.org Mon Sep 17 15:24:22 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 15:24:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDdB8-0003aR-LN; Mon, 17 Sep 2012 15:24:06 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1TDdB7-0003Zt-1X
	for xen-devel@lists.xen.org; Mon, 17 Sep 2012 15:24:05 +0000
Received: from [85.158.139.211:45600] by server-12.bemta-5.messagelabs.com id
	71/3B-19338-49047505; Mon, 17 Sep 2012 15:24:04 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-15.tower-206.messagelabs.com!1347895443!18946108!1
X-Originating-IP: [63.239.67.9]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4516 invoked from network); 17 Sep 2012 15:24:03 -0000
Received: from emvm-gh1-uea08.nsa.gov (HELO nsa.gov) (63.239.67.9)
	by server-15.tower-206.messagelabs.com with SMTP;
	17 Sep 2012 15:24:03 -0000
X-TM-IMSS-Message-ID: <53802e3a0012acca@nsa.gov>
Received: from tarius.tycho.ncsc.mil ([144.51.3.1]) by nsa.gov ([63.239.67.9])
	with ESMTP (TREND IMSS SMTP Service 7.1) id 53802e3a0012acca ;
	Mon, 17 Sep 2012 11:23:42 -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 q8HFO0xS027504; 
	Mon, 17 Sep 2012 11:24:00 -0400
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xen.org
Date: Mon, 17 Sep 2012 11:23:24 -0400
Message-Id: <1347895425-17959-3-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.11.4
In-Reply-To: <1347895425-17959-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1347895425-17959-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: dgdegra@tycho.nsa.gov, keir@xen.org
Subject: [Xen-devel] [PATCH 02/23] xsm/flask: remove unneeded create_sid
	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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This field was only used to populate the ssid of dom0, which can be
handled explicitly in the domain creation hook. This also removes the
unnecessary permission check on the creation of dom0.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 tools/flask/policy/policy/modules/xen/xen.te |  2 --
 xen/xsm/flask/hooks.c                        | 23 ++++++++++-------------
 xen/xsm/flask/include/objsec.h               |  1 -
 3 files changed, 10 insertions(+), 16 deletions(-)

diff --git a/tools/flask/policy/policy/modules/xen/xen.te b/tools/flask/policy/policy/modules/xen/xen.te
index e175d4b..9cc5240 100644
--- a/tools/flask/policy/policy/modules/xen/xen.te
+++ b/tools/flask/policy/policy/modules/xen/xen.te
@@ -52,8 +52,6 @@ type device_t, resource_type;
 # Rules required to boot the hypervisor and dom0
 #
 ################################################################################
-allow xen_t dom0_t:domain { create };
-
 allow dom0_t xen_t:xen { kexec readapic writeapic mtrr_read mtrr_add mtrr_del
 	scheduler physinfo heap quirk readconsole writeconsole settime getcpuinfo
 	microcode cpupool_op sched_op pm_op };
diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
index 8c853de..88fef9c 100644
--- a/xen/xsm/flask/hooks.c
+++ b/xen/xsm/flask/hooks.c
@@ -108,12 +108,10 @@ static int flask_domain_alloc_security(struct domain *d)
 
     memset(dsec, 0, sizeof(struct domain_security_struct));
 
-    dsec->create_sid = SECSID_NULL;
     switch ( d->domain_id )
     {
     case DOMID_IDLE:
         dsec->sid = SECINITSID_XEN;
-        dsec->create_sid = SECINITSID_DOM0;
         break;
     case DOMID_XEN:
         dsec->sid = SECINITSID_DOMXEN;
@@ -489,25 +487,24 @@ static int flask_domain_create(struct domain *d, u32 ssidref)
     int rc;
     struct domain_security_struct *dsec1;
     struct domain_security_struct *dsec2;
+    static int dom0_created = 0;
 
     dsec1 = current->domain->ssid;
+    dsec2 = d->ssid;
 
-    if ( dsec1->create_sid == SECSID_NULL ) 
-        dsec1->create_sid = ssidref;
+    if ( is_idle_domain(current->domain) && !dom0_created )
+    {
+        dsec2->sid = SECINITSID_DOM0;
+        dom0_created = 1;
+        return 0;
+    }
 
-    rc = avc_has_perm(dsec1->sid, dsec1->create_sid, SECCLASS_DOMAIN, 
+    rc = avc_has_perm(dsec1->sid, ssidref, SECCLASS_DOMAIN,
                       DOMAIN__CREATE, NULL);
     if ( rc )
-    {
-        dsec1->create_sid = SECSID_NULL;
         return rc;
-    }
-
-    dsec2 = d->ssid;
-    dsec2->sid = dsec1->create_sid;
 
-    dsec1->create_sid = SECSID_NULL;
-    dsec2->create_sid = SECSID_NULL;
+    dsec2->sid = ssidref;
 
     return rc;
 }
diff --git a/xen/xsm/flask/include/objsec.h b/xen/xsm/flask/include/objsec.h
index df5baee..4ff52be 100644
--- a/xen/xsm/flask/include/objsec.h
+++ b/xen/xsm/flask/include/objsec.h
@@ -19,7 +19,6 @@
 
 struct domain_security_struct {
     u32 sid;               /* current SID */
-    u32 create_sid;
 };
 
 struct evtchn_security_struct {
-- 
1.7.11.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 17 15:24:22 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 15:24:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDdBC-0003dE-FX; Mon, 17 Sep 2012 15:24:10 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1TDdBA-0003Zt-1X
	for xen-devel@lists.xen.org; Mon, 17 Sep 2012 15:24:08 +0000
Received: from [85.158.139.211:11493] by server-12.bemta-5.messagelabs.com id
	94/6B-19338-79047505; Mon, 17 Sep 2012 15:24:07 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-4.tower-206.messagelabs.com!1347895444!18910985!1
X-Originating-IP: [63.239.67.9]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13652 invoked from network); 17 Sep 2012 15:24:04 -0000
Received: from emvm-gh1-uea08.nsa.gov (HELO nsa.gov) (63.239.67.9)
	by server-4.tower-206.messagelabs.com with SMTP;
	17 Sep 2012 15:24:04 -0000
X-TM-IMSS-Message-ID: <538037010012acd2@nsa.gov>
Received: from tarius.tycho.ncsc.mil ([144.51.3.1]) by nsa.gov ([63.239.67.9])
	with ESMTP (TREND IMSS SMTP Service 7.1) id 538037010012acd2 ;
	Mon, 17 Sep 2012 11:23:44 -0400
Received: from moss-nexus.epoch.ncsc.mil (moss-nexus [144.51.25.48])
	by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id q8HFO0xZ027504; 
	Mon, 17 Sep 2012 11:24:02 -0400
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xen.org
Date: Mon, 17 Sep 2012 11:23:31 -0400
Message-Id: <1347895425-17959-10-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.11.4
In-Reply-To: <1347895425-17959-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1347895425-17959-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: dgdegra@tycho.nsa.gov, keir@xen.org, Jan Beulich <jbeulich@suse.com>
Subject: [Xen-devel] [PATCH 09/23] xsm: Use the dummy XSM module if XSM is
	disabled
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/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 moves the implementation of the dummy XSM module to a header
file that provides inline functions when XSM_ENABLE is not defined. This
reduces duplication between the dummy module and callers when the
implementation of the dummy return is not just "return 0", and also
provides better compile-time checking for completeness of the XSM
implementations in the dummy module.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Cc: Keir Fraser <keir@xen.org>
Cc: Jan Beulich <jbeulich@suse.com>
---
 xen/common/domctl.c     |   2 -
 xen/include/xsm/dummy.h | 628 ++++++++++++++++++++++++++++++++++++++++++++++++
 xen/include/xsm/xsm.h   | 294 +++++++++++------------
 xen/xsm/dummy.c         | 619 +----------------------------------------------
 xen/xsm/flask/hooks.c   |   2 +-
 xen/xsm/xsm_core.c      |   2 +-
 6 files changed, 776 insertions(+), 771 deletions(-)
 create mode 100644 xen/include/xsm/dummy.h

diff --git a/xen/common/domctl.c b/xen/common/domctl.c
index 2b1f182..d99ba67 100644
--- a/xen/common/domctl.c
+++ b/xen/common/domctl.c
@@ -267,10 +267,8 @@ long do_domctl(XEN_GUEST_HANDLE(xen_domctl_t) u_domctl)
             return -EPERM;
         break;
     }
-#ifdef XSM_ENABLE
     case XEN_DOMCTL_getdomaininfo:
         break;
-#endif
     default:
         if ( !IS_PRIV(current->domain) )
             return -EPERM;
diff --git a/xen/include/xsm/dummy.h b/xen/include/xsm/dummy.h
new file mode 100644
index 0000000..0456bc8
--- /dev/null
+++ b/xen/include/xsm/dummy.h
@@ -0,0 +1,628 @@
+/*
+ *  Default XSM hooks - IS_PRIV and IS_PRIV_FOR checks
+ *
+ *  Author: Daniel De Graaf <dgdegra@tyhco.nsa.gov>
+ *
+ *  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.
+ */
+
+#include <xen/sched.h>
+#include <xsm/xsm.h>
+
+static XSM_DEFAULT(void, security_domaininfo)(struct domain *d,
+                                    struct xen_domctl_getdomaininfo *info)
+{
+    return;
+}
+
+static XSM_DEFAULT(int, setvcpucontext)(struct domain *d)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, pausedomain) (struct domain *d)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, unpausedomain) (struct domain *d)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, resumedomain) (struct domain *d)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, domain_create)(struct domain *d, u32 ssidref)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, max_vcpus)(struct domain *d)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, destroydomain) (struct domain *d)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, vcpuaffinity) (int cmd, struct domain *d)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, scheduler) (struct domain *d)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, getdomaininfo) (struct domain *d)
+{
+    if ( !IS_PRIV(current->domain) )
+        return -EPERM;
+    return 0;
+}
+
+static XSM_DEFAULT(int, getvcpucontext) (struct domain *d)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, getvcpuinfo) (struct domain *d)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, domain_settime) (struct domain *d)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, set_target) (struct domain *d, struct domain *e)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, domctl)(struct domain *d, int cmd)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, set_virq_handler)(struct domain *d, uint32_t virq)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, tbufcontrol) (void)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, readconsole) (uint32_t clear)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, sched_id) (void)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, setdomainmaxmem) (struct domain *d)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, setdomainhandle) (struct domain *d)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, setdebugging) (struct domain *d)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, perfcontrol) (void)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, debug_keys) (void)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, getcpuinfo) (void)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, get_pmstat) (void)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, setpminfo) (void)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, pm_op) (void)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, do_mca) (void)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, availheap) (void)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, alloc_security_domain) (struct domain *d)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(void, free_security_domain) (struct domain *d)
+{
+    return;
+}
+
+static XSM_DEFAULT(int, grant_mapref) (struct domain *d1, struct domain *d2,
+                                                                uint32_t flags)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, grant_unmapref) (struct domain *d1, struct domain *d2)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, grant_setup) (struct domain *d1, struct domain *d2)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, grant_transfer) (struct domain *d1, struct domain *d2)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, grant_copy) (struct domain *d1, struct domain *d2)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, grant_query_size) (struct domain *d1, struct domain *d2)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, memory_adjust_reservation) (struct domain *d1,
+                                                            struct domain *d2)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, memory_stat_reservation) (struct domain *d1, struct domain *d2)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, console_io) (struct domain *d, int cmd)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, profile) (struct domain *d, int op)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, kexec) (void)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, schedop_shutdown) (struct domain *d1, struct domain *d2)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, memory_pin_page) (struct domain *d1, struct domain *d2,
+                                          struct page_info *page)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, evtchn_unbound) (struct domain *d, struct evtchn *chn,
+                                         domid_t id2)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, evtchn_interdomain) (struct domain *d1, struct evtchn
+                                *chan1, struct domain *d2, struct evtchn *chan2)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(void, evtchn_close_post) (struct evtchn *chn)
+{
+    return;
+}
+
+static XSM_DEFAULT(int, evtchn_send) (struct domain *d, struct evtchn *chn)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, evtchn_status) (struct domain *d, struct evtchn *chn)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, evtchn_reset) (struct domain *d1, struct domain *d2)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, alloc_security_evtchn) (struct evtchn *chn)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(void, free_security_evtchn) (struct evtchn *chn)
+{
+    return;
+}
+
+static XSM_DEFAULT(char *, show_security_evtchn) (struct domain *d, const struct evtchn *chn)
+{
+    return NULL;
+}
+
+static XSM_DEFAULT(int, get_pod_target)(struct domain *d)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, set_pod_target)(struct domain *d)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, get_device_group) (uint32_t machine_bdf)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, test_assign_device) (uint32_t machine_bdf)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, assign_device) (struct domain *d, uint32_t machine_bdf)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, deassign_device) (struct domain *d, uint32_t machine_bdf)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, resource_plug_core) (void)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, resource_unplug_core) (void)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, resource_plug_pci) (uint32_t machine_bdf)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, resource_unplug_pci) (uint32_t machine_bdf)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, resource_setup_pci) (uint32_t machine_bdf)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, resource_setup_gsi) (int gsi)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, resource_setup_misc) (void)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, page_offline) (uint32_t cmd)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, lockprof) (void)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, cpupool_op) (void)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, sched_op) (void)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(long, do_xsm_op)(XEN_GUEST_HANDLE(xsm_op_t) op)
+{
+    return -ENOSYS;
+}
+
+static XSM_DEFAULT(char *, show_irq_sid) (int irq)
+{
+    return NULL;
+}
+
+static XSM_DEFAULT(int, map_domain_pirq) (struct domain *d, int irq, void *data)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, unmap_domain_pirq) (struct domain *d, int irq)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, irq_permission) (struct domain *d, int pirq, uint8_t allow)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, iomem_permission) (struct domain *d, uint64_t s, uint64_t e, uint8_t allow)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, iomem_mapping) (struct domain *d, uint64_t s, uint64_t e, uint8_t allow)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, pci_config_permission) (struct domain *d, uint32_t machine_bdf,
+                                        uint16_t start, uint16_t end,
+                                        uint8_t access)
+{
+    return 0;
+}
+
+#ifdef CONFIG_X86
+static XSM_DEFAULT(int, shadow_control) (struct domain *d, uint32_t op)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, getpageframeinfo) (struct domain *d)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, getmemlist) (struct domain *d)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, hypercall_init) (struct domain *d)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, hvmcontext) (struct domain *d, uint32_t cmd)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, address_size) (struct domain *d, uint32_t cmd)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, machine_address_size) (struct domain *d, uint32_t cmd)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, hvm_param) (struct domain *d, unsigned long op)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, hvm_set_pci_intx_level) (struct domain *d)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, hvm_set_isa_irq_level) (struct domain *d)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, hvm_set_pci_link_route) (struct domain *d)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, hvm_inject_msi) (struct domain *d)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, mem_event) (struct domain *d)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, mem_sharing) (struct domain *d)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, apic) (struct domain *d, int cmd)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, xen_settime) (void)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, memtype) (uint32_t access)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, microcode) (void)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, physinfo) (void)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, platform_quirk) (uint32_t quirk)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, firmware_info) (void)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, efi_call) (void)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, acpi_sleep) (void)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, change_freq) (void)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, getidletime) (void)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, machine_memory_map) (void)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, domain_memory_map) (struct domain *d)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, mmu_normal_update) (struct domain *d, struct domain *t,
+                                            struct domain *f, intpte_t fpte)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, mmu_machphys_update) (struct domain *d, struct domain *f,
+                                              unsigned long mfn)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, update_va_mapping) (struct domain *d, struct domain *f, 
+                                                            l1_pgentry_t pte)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, add_to_physmap) (struct domain *d1, struct domain *d2)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, remove_from_physmap) (struct domain *d1, struct domain *d2)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, sendtrigger) (struct domain *d)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, bind_pt_irq) (struct domain *d, struct xen_domctl_bind_pt_irq *bind)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, unbind_pt_irq) (struct domain *d, struct xen_domctl_bind_pt_irq *bind)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, pin_mem_cacheattr) (struct domain *d)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, ext_vcpucontext) (struct domain *d, uint32_t cmd)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, vcpuextstate) (struct domain *d, uint32_t cmd)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, ioport_permission) (struct domain *d, uint32_t s, uint32_t e, uint8_t allow)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, ioport_mapping) (struct domain *d, uint32_t s, uint32_t e, uint8_t allow)
+{
+    return 0;
+}
+
+#endif
diff --git a/xen/include/xsm/xsm.h b/xen/include/xsm/xsm.h
index cbbe673..1a63c27 100644
--- a/xen/include/xsm/xsm.h
+++ b/xen/include/xsm/xsm.h
@@ -21,12 +21,6 @@
 typedef void xsm_op_t;
 DEFINE_XEN_GUEST_HANDLE(xsm_op_t);
 
-#ifdef XSM_ENABLE
-    #define xsm_call(fn) xsm_ops->fn
-#else
-    #define xsm_call(fn) 0
-#endif
-
 /* policy magic number (defined by XSM_MAGIC) */
 typedef u32 xsm_magic_t;
 #ifndef XSM_MAGIC
@@ -141,7 +135,7 @@ struct xsm_operations {
     int (*cpupool_op)(void);
     int (*sched_op)(void);
 
-    long (*__do_xsm_op) (XEN_GUEST_HANDLE(xsm_op_t) op);
+    long (*do_xsm_op) (XEN_GUEST_HANDLE(xsm_op_t) op);
 
 #ifdef CONFIG_X86
     int (*shadow_control) (struct domain *d, uint32_t op);
@@ -187,645 +181,643 @@ struct xsm_operations {
 #endif
 };
 
-#endif
-
 extern struct xsm_operations *xsm_ops;
 
 static inline void xsm_security_domaininfo (struct domain *d,
                                         struct xen_domctl_getdomaininfo *info)
 {
-    (void)xsm_call(security_domaininfo(d, info));
+    xsm_ops->security_domaininfo(d, info);
 }
 
 static inline int xsm_setvcpucontext(struct domain *d)
 {
-    return xsm_call(setvcpucontext(d));
+    return xsm_ops->setvcpucontext(d);
 }
 
 static inline int xsm_pausedomain (struct domain *d)
 {
-    return xsm_call(pausedomain(d));
+    return xsm_ops->pausedomain(d);
 }
 
 static inline int xsm_unpausedomain (struct domain *d)
 {
-    return xsm_call(unpausedomain(d));
+    return xsm_ops->unpausedomain(d);
 }
 
 static inline int xsm_resumedomain (struct domain *d)
 {
-    return xsm_call(resumedomain(d));
+    return xsm_ops->resumedomain(d);
 }
 
 static inline int xsm_domain_create (struct domain *d, u32 ssidref)
 {
-    return xsm_call(domain_create(d, ssidref));
+    return xsm_ops->domain_create(d, ssidref);
 }
 
 static inline int xsm_max_vcpus(struct domain *d)
 {
-    return xsm_call(max_vcpus(d));
+    return xsm_ops->max_vcpus(d);
 }
 
 static inline int xsm_destroydomain (struct domain *d)
 {
-    return xsm_call(destroydomain(d));
+    return xsm_ops->destroydomain(d);
 }
 
 static inline int xsm_vcpuaffinity (int cmd, struct domain *d)
 {
-    return xsm_call(vcpuaffinity(cmd, d));
+    return xsm_ops->vcpuaffinity(cmd, d);
 }
 
 static inline int xsm_scheduler (struct domain *d)
 {
-    return xsm_call(scheduler(d));
+    return xsm_ops->scheduler(d);
 }
 
 static inline int xsm_getdomaininfo (struct domain *d)
 {
-    return xsm_call(getdomaininfo(d));
+    return xsm_ops->getdomaininfo(d);
 }
 
 static inline int xsm_getvcpucontext (struct domain *d)
 {
-    return xsm_call(getvcpucontext(d));
+    return xsm_ops->getvcpucontext(d);
 }
 
 static inline int xsm_getvcpuinfo (struct domain *d)
 {
-    return xsm_call(getvcpuinfo(d));
+    return xsm_ops->getvcpuinfo(d);
 }
 
 static inline int xsm_domain_settime (struct domain *d)
 {
-    return xsm_call(domain_settime(d));
+    return xsm_ops->domain_settime(d);
 }
 
 static inline int xsm_set_target (struct domain *d, struct domain *e)
 {
-    return xsm_call(set_target(d, e));
+    return xsm_ops->set_target(d, e);
 }
 
 static inline int xsm_domctl (struct domain *d, int cmd)
 {
-    return xsm_call(domctl(d, cmd));
+    return xsm_ops->domctl(d, cmd);
 }
 
 static inline int xsm_set_virq_handler (struct domain *d, uint32_t virq)
 {
-    return xsm_call(set_virq_handler(d, virq));
+    return xsm_ops->set_virq_handler(d, virq);
 }
 
 static inline int xsm_tbufcontrol (void)
 {
-    return xsm_call(tbufcontrol());
+    return xsm_ops->tbufcontrol();
 }
 
 static inline int xsm_readconsole (uint32_t clear)
 {
-    return xsm_call(readconsole(clear));
+    return xsm_ops->readconsole(clear);
 }
 
 static inline int xsm_sched_id (void)
 {
-    return xsm_call(sched_id());
+    return xsm_ops->sched_id();
 }
 
 static inline int xsm_setdomainmaxmem (struct domain *d)
 {
-    return xsm_call(setdomainmaxmem(d));
+    return xsm_ops->setdomainmaxmem(d);
 }
 
 static inline int xsm_setdomainhandle (struct domain *d)
 {
-    return xsm_call(setdomainhandle(d));
+    return xsm_ops->setdomainhandle(d);
 }
 
 static inline int xsm_setdebugging (struct domain *d)
 {
-    return xsm_call(setdebugging(d));
+    return xsm_ops->setdebugging(d);
 }
 
 static inline int xsm_perfcontrol (void)
 {
-    return xsm_call(perfcontrol());
+    return xsm_ops->perfcontrol();
 }
 
 static inline int xsm_debug_keys (void)
 {
-    return xsm_call(debug_keys());
+    return xsm_ops->debug_keys();
 }
 
 static inline int xsm_availheap (void)
 {
-    return xsm_call(availheap());
+    return xsm_ops->availheap();
 }
 
 static inline int xsm_getcpuinfo (void)
 {
-    return xsm_call(getcpuinfo());
+    return xsm_ops->getcpuinfo();
 }
 
 static inline int xsm_get_pmstat(void)
 {
-    return xsm_call(get_pmstat());
+    return xsm_ops->get_pmstat();
 }
 
 static inline int xsm_setpminfo(void)
 {
-	return xsm_call(setpminfo());
+    return xsm_ops->setpminfo();
 }
 
 static inline int xsm_pm_op(void)
 {
-    return xsm_call(pm_op());
+    return xsm_ops->pm_op();
 }
 
 static inline int xsm_do_mca(void)
 {
-    return xsm_call(do_mca());
+    return xsm_ops->do_mca();
 }
 
 static inline int xsm_evtchn_unbound (struct domain *d1, struct evtchn *chn,
                                                                     domid_t id2)
 {
-    return xsm_call(evtchn_unbound(d1, chn, id2));
+    return xsm_ops->evtchn_unbound(d1, chn, id2);
 }
 
 static inline int xsm_evtchn_interdomain (struct domain *d1, 
                 struct evtchn *chan1, struct domain *d2, struct evtchn *chan2)
 {
-    return xsm_call(evtchn_interdomain(d1, chan1, d2, chan2));
+    return xsm_ops->evtchn_interdomain(d1, chan1, d2, chan2);
 }
 
 static inline void xsm_evtchn_close_post (struct evtchn *chn)
 {
-    (void)xsm_call(evtchn_close_post(chn));
+    xsm_ops->evtchn_close_post(chn);
 }
 
 static inline int xsm_evtchn_send (struct domain *d, struct evtchn *chn)
 {
-    return xsm_call(evtchn_send(d, chn));
+    return xsm_ops->evtchn_send(d, chn);
 }
 
 static inline int xsm_evtchn_status (struct domain *d, struct evtchn *chn)
 {
-    return xsm_call(evtchn_status(d, chn));
+    return xsm_ops->evtchn_status(d, chn);
 }
 
 static inline int xsm_evtchn_reset (struct domain *d1, struct domain *d2)
 {
-    return xsm_call(evtchn_reset(d1, d2));
+    return xsm_ops->evtchn_reset(d1, d2);
 }
 
 static inline int xsm_grant_mapref (struct domain *d1, struct domain *d2,
                                                                 uint32_t flags)
 {
-    return xsm_call(grant_mapref(d1, d2, flags));
+    return xsm_ops->grant_mapref(d1, d2, flags);
 }
 
 static inline int xsm_grant_unmapref (struct domain *d1, struct domain *d2)
 {
-    return xsm_call(grant_unmapref(d1, d2));
+    return xsm_ops->grant_unmapref(d1, d2);
 }
 
 static inline int xsm_grant_setup (struct domain *d1, struct domain *d2)
 {
-    return xsm_call(grant_setup(d1, d2));
+    return xsm_ops->grant_setup(d1, d2);
 }
 
 static inline int xsm_grant_transfer (struct domain *d1, struct domain *d2)
 {
-    return xsm_call(grant_transfer(d1, d2));
+    return xsm_ops->grant_transfer(d1, d2);
 }
 
 static inline int xsm_grant_copy (struct domain *d1, struct domain *d2)
 {
-    return xsm_call(grant_copy(d1, d2));
+    return xsm_ops->grant_copy(d1, d2);
 }
 
 static inline int xsm_grant_query_size (struct domain *d1, struct domain *d2)
 {
-    return xsm_call(grant_query_size(d1, d2));
+    return xsm_ops->grant_query_size(d1, d2);
 }
 
 static inline int xsm_alloc_security_domain (struct domain *d)
 {
-    return xsm_call(alloc_security_domain(d));
+    return xsm_ops->alloc_security_domain(d);
 }
 
 static inline void xsm_free_security_domain (struct domain *d)
 {
-    (void)xsm_call(free_security_domain(d));
+    xsm_ops->free_security_domain(d);
 }
 
 static inline int xsm_alloc_security_evtchn (struct evtchn *chn)
 {
-    return xsm_call(alloc_security_evtchn(chn));
+    return xsm_ops->alloc_security_evtchn(chn);
 }
 
 static inline void xsm_free_security_evtchn (struct evtchn *chn)
 {
-    (void)xsm_call(free_security_evtchn(chn));
+    (void)xsm_ops->free_security_evtchn(chn);
 }
 
 static inline char *xsm_show_security_evtchn (struct domain *d, const struct evtchn *chn)
 {
-    return xsm_call(show_security_evtchn(d, chn));
+    return xsm_ops->show_security_evtchn(d, chn);
 }
 
 static inline int xsm_get_pod_target (struct domain *d)
 {
-    return xsm_call(get_pod_target(d));
+    return xsm_ops->get_pod_target(d);
 }
 
 static inline int xsm_set_pod_target (struct domain *d)
 {
-    return xsm_call(set_pod_target(d));
+    return xsm_ops->set_pod_target(d);
 }
 
 static inline int xsm_memory_adjust_reservation (struct domain *d1, struct
                                                                     domain *d2)
 {
-    return xsm_call(memory_adjust_reservation(d1, d2));
+    return xsm_ops->memory_adjust_reservation(d1, d2);
 }
 
 static inline int xsm_memory_stat_reservation (struct domain *d1,
                                                             struct domain *d2)
 {
-    return xsm_call(memory_stat_reservation(d1, d2));
+    return xsm_ops->memory_stat_reservation(d1, d2);
 }
 
 static inline int xsm_memory_pin_page(struct domain *d1, struct domain *d2,
                                       struct page_info *page)
 {
-    return xsm_call(memory_pin_page(d1, d2, page));
+    return xsm_ops->memory_pin_page(d1, d2, page);
 }
 
 static inline int xsm_remove_from_physmap(struct domain *d1, struct domain *d2)
 {
-    return xsm_call(remove_from_physmap(d1, d2));
+    return xsm_ops->remove_from_physmap(d1, d2);
 }
 
 static inline int xsm_console_io (struct domain *d, int cmd)
 {
-    return xsm_call(console_io(d, cmd));
+    return xsm_ops->console_io(d, cmd);
 }
 
 static inline int xsm_profile (struct domain *d, int op)
 {
-    return xsm_call(profile(d, op));
+    return xsm_ops->profile(d, op);
 }
 
 static inline int xsm_kexec (void)
 {
-    return xsm_call(kexec());
+    return xsm_ops->kexec();
 }
 
 static inline int xsm_schedop_shutdown (struct domain *d1, struct domain *d2)
 {
-    return xsm_call(schedop_shutdown(d1, d2));
+    return xsm_ops->schedop_shutdown(d1, d2);
 }
 
 static inline char *xsm_show_irq_sid (int irq)
 {
-    return xsm_call(show_irq_sid(irq));
+    return xsm_ops->show_irq_sid(irq);
 }
 
 static inline int xsm_map_domain_pirq (struct domain *d, int irq, void *data)
 {
-    return xsm_call(map_domain_pirq(d, irq, data));
+    return xsm_ops->map_domain_pirq(d, irq, data);
 }
 
 static inline int xsm_unmap_domain_pirq (struct domain *d, int irq)
 {
-    return xsm_call(unmap_domain_pirq(d, irq));
+    return xsm_ops->unmap_domain_pirq(d, irq);
 }
 
 static inline int xsm_irq_permission (struct domain *d, int pirq, uint8_t allow)
 {
-    return xsm_call(irq_permission(d, pirq, allow));
+    return xsm_ops->irq_permission(d, pirq, allow);
 }
 
 static inline int xsm_iomem_permission (struct domain *d, uint64_t s, uint64_t e, uint8_t allow)
 {
-    return xsm_call(iomem_permission(d, s, e, allow));
+    return xsm_ops->iomem_permission(d, s, e, allow);
 }
 
 static inline int xsm_iomem_mapping (struct domain *d, uint64_t s, uint64_t e, uint8_t allow)
 {
-    return xsm_call(iomem_mapping(d, s, e, allow));
+    return xsm_ops->iomem_mapping(d, s, e, allow);
 }
 
 static inline int xsm_pci_config_permission (struct domain *d, uint32_t machine_bdf, uint16_t start, uint16_t end, uint8_t access)
 {
-    return xsm_call(pci_config_permission(d, machine_bdf, start, end, access));
+    return xsm_ops->pci_config_permission(d, machine_bdf, start, end, access);
 }
 
 static inline int xsm_get_device_group(uint32_t machine_bdf)
 {
-    return xsm_call(get_device_group(machine_bdf));
+    return xsm_ops->get_device_group(machine_bdf);
 }
 
 static inline int xsm_test_assign_device(uint32_t machine_bdf)
 {
-    return xsm_call(test_assign_device(machine_bdf));
+    return xsm_ops->test_assign_device(machine_bdf);
 }
 
 static inline int xsm_assign_device(struct domain *d, uint32_t machine_bdf)
 {
-    return xsm_call(assign_device(d, machine_bdf));
+    return xsm_ops->assign_device(d, machine_bdf);
 }
 
 static inline int xsm_deassign_device(struct domain *d, uint32_t machine_bdf)
 {
-    return xsm_call(deassign_device(d, machine_bdf));
+    return xsm_ops->deassign_device(d, machine_bdf);
 }
 
 static inline int xsm_resource_plug_pci (uint32_t machine_bdf)
 {
-    return xsm_call(resource_plug_pci(machine_bdf));
+    return xsm_ops->resource_plug_pci(machine_bdf);
 }
 
 static inline int xsm_resource_unplug_pci (uint32_t machine_bdf)
 {
-    return xsm_call(resource_unplug_pci(machine_bdf));
+    return xsm_ops->resource_unplug_pci(machine_bdf);
 }
 
 static inline int xsm_resource_plug_core (void)
 {
-    return xsm_call(resource_plug_core());
+    return xsm_ops->resource_plug_core();
 }
 
 static inline int xsm_resource_unplug_core (void)
 {
-    return xsm_call(resource_unplug_core());
+    return xsm_ops->resource_unplug_core();
 }
 
 static inline int xsm_resource_setup_pci (uint32_t machine_bdf)
 {
-    return xsm_call(resource_setup_pci(machine_bdf));
+    return xsm_ops->resource_setup_pci(machine_bdf);
 }
 
 static inline int xsm_resource_setup_gsi (int gsi)
 {
-    return xsm_call(resource_setup_gsi(gsi));
+    return xsm_ops->resource_setup_gsi(gsi);
 }
 
 static inline int xsm_resource_setup_misc (void)
 {
-    return xsm_call(resource_setup_misc());
+    return xsm_ops->resource_setup_misc();
 }
 
 static inline int xsm_page_offline(uint32_t cmd)
 {
-    return xsm_call(page_offline(cmd));
+    return xsm_ops->page_offline(cmd);
 }
 
 static inline int xsm_lockprof(void)
 {
-    return xsm_call(lockprof());
+    return xsm_ops->lockprof();
 }
 
 static inline int xsm_cpupool_op(void)
 {
-    return xsm_call(cpupool_op());
+    return xsm_ops->cpupool_op();
 }
 
 static inline int xsm_sched_op(void)
 {
-    return xsm_call(sched_op());
-}
-
-static inline long __do_xsm_op (XEN_GUEST_HANDLE(xsm_op_t) op)
-{
-#ifdef XSM_ENABLE
-    return xsm_ops->__do_xsm_op(op);
-#else
-    return -ENOSYS;
-#endif
+    return xsm_ops->sched_op();
 }
 
-#ifdef XSM_ENABLE
-extern int xsm_init(unsigned long *module_map, const multiboot_info_t *mbi,
-                    void *(*bootstrap_map)(const module_t *));
-extern int xsm_policy_init(unsigned long *module_map,
-                           const multiboot_info_t *mbi,
-                           void *(*bootstrap_map)(const module_t *));
-extern int register_xsm(struct xsm_operations *ops);
-extern int unregister_xsm(struct xsm_operations *ops);
-#else
-static inline int xsm_init (unsigned long *module_map,
-                            const multiboot_info_t *mbi,
-                            void *(*bootstrap_map)(const module_t *))
+static inline long xsm_do_xsm_op (XEN_GUEST_HANDLE(xsm_op_t) op)
 {
-    return 0;
+    return xsm_ops->do_xsm_op(op);
 }
-#endif
 
 #ifdef CONFIG_X86
 static inline int xsm_shadow_control (struct domain *d, uint32_t op)
 {
-    return xsm_call(shadow_control(d, op));
+    return xsm_ops->shadow_control(d, op);
 }
 
 static inline int xsm_getpageframeinfo (struct domain *d)
 {
-    return xsm_call(getpageframeinfo(d));
+    return xsm_ops->getpageframeinfo(d);
 }
 
 static inline int xsm_getmemlist (struct domain *d)
 {
-    return xsm_call(getmemlist(d));
+    return xsm_ops->getmemlist(d);
 }
 
 static inline int xsm_hypercall_init (struct domain *d)
 {
-    return xsm_call(hypercall_init(d));
+    return xsm_ops->hypercall_init(d);
 }
 
 static inline int xsm_hvmcontext (struct domain *d, uint32_t cmd)
 {
-    return xsm_call(hvmcontext(d, cmd));
+    return xsm_ops->hvmcontext(d, cmd);
 }
 
 static inline int xsm_address_size (struct domain *d, uint32_t cmd)
 {
-    return xsm_call(address_size(d, cmd));
+    return xsm_ops->address_size(d, cmd);
 }
 
 static inline int xsm_machine_address_size (struct domain *d, uint32_t cmd)
 {
-    return xsm_call(machine_address_size(d, cmd));
+    return xsm_ops->machine_address_size(d, cmd);
 }
 
 static inline int xsm_hvm_param (struct domain *d, unsigned long op)
 {
-    return xsm_call(hvm_param(d, op));
+    return xsm_ops->hvm_param(d, op);
 }
 
 static inline int xsm_hvm_set_pci_intx_level (struct domain *d)
 {
-    return xsm_call(hvm_set_pci_intx_level(d));
+    return xsm_ops->hvm_set_pci_intx_level(d);
 }
 
 static inline int xsm_hvm_set_isa_irq_level (struct domain *d)
 {
-    return xsm_call(hvm_set_isa_irq_level(d));
+    return xsm_ops->hvm_set_isa_irq_level(d);
 }
 
 static inline int xsm_hvm_set_pci_link_route (struct domain *d)
 {
-    return xsm_call(hvm_set_pci_link_route(d));
+    return xsm_ops->hvm_set_pci_link_route(d);
 }
 
 static inline int xsm_hvm_inject_msi (struct domain *d)
 {
-    return xsm_call(hvm_inject_msi(d));
+    return xsm_ops->hvm_inject_msi(d);
 }
 
 static inline int xsm_mem_event (struct domain *d)
 {
-    return xsm_call(mem_event(d));
+    return xsm_ops->mem_event(d);
 }
 
 static inline int xsm_mem_sharing (struct domain *d)
 {
-    return xsm_call(mem_sharing(d));
+    return xsm_ops->mem_sharing(d);
 }
 
 static inline int xsm_apic (struct domain *d, int cmd)
 {
-    return xsm_call(apic(d, cmd));
+    return xsm_ops->apic(d, cmd);
 }
 
 static inline int xsm_xen_settime (void)
 {
-    return xsm_call(xen_settime());
+    return xsm_ops->xen_settime();
 }
 
 static inline int xsm_memtype (uint32_t access)
 {
-    return xsm_call(memtype(access));
+    return xsm_ops->memtype(access);
 }
 
 static inline int xsm_microcode (void)
 {
-    return xsm_call(microcode());
+    return xsm_ops->microcode();
 }
 
 static inline int xsm_physinfo (void)
 {
-    return xsm_call(physinfo());
+    return xsm_ops->physinfo();
 }
 
 static inline int xsm_platform_quirk (uint32_t quirk)
 {
-    return xsm_call(platform_quirk(quirk));
+    return xsm_ops->platform_quirk(quirk);
 }
 
 static inline int xsm_firmware_info (void)
 {
-    return xsm_call(firmware_info());
+    return xsm_ops->firmware_info();
 }
 
 static inline int xsm_efi_call (void)
 {
-    return xsm_call(efi_call());
+    return xsm_ops->efi_call();
 }
 
 static inline int xsm_acpi_sleep (void)
 {
-    return xsm_call(acpi_sleep());
+    return xsm_ops->acpi_sleep();
 }
 
 static inline int xsm_change_freq (void)
 {
-    return xsm_call(change_freq());
+    return xsm_ops->change_freq();
 }
 
 static inline int xsm_getidletime (void)
 {
-    return xsm_call(getidletime());
+    return xsm_ops->getidletime();
 }
 
 static inline int xsm_machine_memory_map(void)
 {
-    return xsm_call(machine_memory_map());
+    return xsm_ops->machine_memory_map();
 }
 
 static inline int xsm_domain_memory_map(struct domain *d)
 {
-    return xsm_call(domain_memory_map(d));
+    return xsm_ops->domain_memory_map(d);
 }
 
 static inline int xsm_mmu_normal_update (struct domain *d, struct domain *t,
                                          struct domain *f, intpte_t fpte)
 {
-    return xsm_call(mmu_normal_update(d, t, f, fpte));
+    return xsm_ops->mmu_normal_update(d, t, f, fpte);
 }
 
 static inline int xsm_mmu_machphys_update (struct domain *d1, struct domain *d2,
                                            unsigned long mfn)
 {
-    return xsm_call(mmu_machphys_update(d1, d2, mfn));
+    return xsm_ops->mmu_machphys_update(d1, d2, mfn);
 }
 
 static inline int xsm_update_va_mapping(struct domain *d, struct domain *f, 
                                                             l1_pgentry_t pte)
 {
-    return xsm_call(update_va_mapping(d, f, pte));
+    return xsm_ops->update_va_mapping(d, f, pte);
 }
 
 static inline int xsm_add_to_physmap(struct domain *d1, struct domain *d2)
 {
-    return xsm_call(add_to_physmap(d1, d2));
+    return xsm_ops->add_to_physmap(d1, d2);
 }
 
 static inline int xsm_sendtrigger(struct domain *d)
 {
-    return xsm_call(sendtrigger(d));
+    return xsm_ops->sendtrigger(d);
 }
 
 static inline int xsm_bind_pt_irq(struct domain *d, 
                                                 struct xen_domctl_bind_pt_irq *bind)
 {
-    return xsm_call(bind_pt_irq(d, bind));
+    return xsm_ops->bind_pt_irq(d, bind);
 }
 
 static inline int xsm_unbind_pt_irq(struct domain *d,
                                                 struct xen_domctl_bind_pt_irq *bind)
 {
-    return xsm_call(unbind_pt_irq(d, bind));
+    return xsm_ops->unbind_pt_irq(d, bind);
 }
 
 static inline int xsm_pin_mem_cacheattr(struct domain *d)
 {
-    return xsm_call(pin_mem_cacheattr(d));
+    return xsm_ops->pin_mem_cacheattr(d);
 }
 
 static inline int xsm_ext_vcpucontext(struct domain *d, uint32_t cmd)
 {
-    return xsm_call(ext_vcpucontext(d, cmd));
+    return xsm_ops->ext_vcpucontext(d, cmd);
 }
 static inline int xsm_vcpuextstate(struct domain *d, uint32_t cmd)
 {
-    return xsm_call(vcpuextstate(d, cmd));
+    return xsm_ops->vcpuextstate(d, cmd);
 }
 
 static inline int xsm_ioport_permission (struct domain *d, uint32_t s, uint32_t e, uint8_t allow)
 {
-    return xsm_call(ioport_permission(d, s, e, allow));
+    return xsm_ops->ioport_permission(d, s, e, allow);
 }
 
 static inline int xsm_ioport_mapping (struct domain *d, uint32_t s, uint32_t e, uint8_t allow)
 {
-    return xsm_call(ioport_mapping(d, s, e, allow));
+    return xsm_ops->ioport_mapping(d, s, e, allow);
 }
 #endif /* CONFIG_X86 */
 
+extern int xsm_init(unsigned long *module_map, const multiboot_info_t *mbi,
+                    void *(*bootstrap_map)(const module_t *));
+extern int xsm_policy_init(unsigned long *module_map,
+                           const multiboot_info_t *mbi,
+                           void *(*bootstrap_map)(const module_t *));
+extern int register_xsm(struct xsm_operations *ops);
+extern int unregister_xsm(struct xsm_operations *ops);
+
 extern struct xsm_operations dummy_xsm_ops;
 extern void xsm_fixup_ops(struct xsm_operations *ops);
 
+#else /* XSM_ENABLE */
+
+#define XSM_DEFAULT(type, name) inline type xsm_ ## name
+#include <xsm/dummy.h>
+
+static inline int xsm_init (unsigned long *module_map,
+                            const multiboot_info_t *mbi,
+                            void *(*bootstrap_map)(const module_t *))
+{
+    return 0;
+}
+#endif /* XSM_ENABLE */
+
 #endif /* __XSM_H */
diff --git a/xen/xsm/dummy.c b/xen/xsm/dummy.c
index a5dbfe7..47192d7 100644
--- a/xen/xsm/dummy.c
+++ b/xen/xsm/dummy.c
@@ -10,621 +10,8 @@
  *  as published by the Free Software Foundation.
  */
 
-#include <xen/sched.h>
-#include <xsm/xsm.h>
-
-static void dummy_security_domaininfo(struct domain *d,
-                                    struct xen_domctl_getdomaininfo *info)
-{
-    return;
-}
-
-static int dummy_setvcpucontext(struct domain *d)
-{
-    return 0;
-}
-
-static int dummy_pausedomain (struct domain *d)
-{
-    return 0;
-}
-
-static int dummy_unpausedomain (struct domain *d)
-{
-    return 0;
-}
-
-static int dummy_resumedomain (struct domain *d)
-{
-    return 0;
-}
-
-static int dummy_domain_create(struct domain *d, u32 ssidref)
-{
-    return 0;
-}
-
-static int dummy_max_vcpus(struct domain *d)
-{
-    return 0;
-}
-
-static int dummy_destroydomain (struct domain *d)
-{
-    return 0;
-}
-
-static int dummy_vcpuaffinity (int cmd, struct domain *d)
-{
-    return 0;
-}
-
-static int dummy_scheduler (struct domain *d)
-{
-    return 0;
-}
-
-static int dummy_getdomaininfo (struct domain *d)
-{
-    if ( !IS_PRIV(current->domain) )
-        return -EPERM;
-    return 0;
-}
-
-static int dummy_getvcpucontext (struct domain *d)
-{
-    return 0;
-}
-
-static int dummy_getvcpuinfo (struct domain *d)
-{
-    return 0;
-}
-
-static int dummy_domain_settime (struct domain *d)
-{
-    return 0;
-}
-
-static int dummy_set_target (struct domain *d, struct domain *e)
-{
-    return 0;
-}
-
-static int dummy_domctl(struct domain *d, int cmd)
-{
-    return 0;
-}
-
-static int dummy_set_virq_handler(struct domain *d, uint32_t virq)
-{
-    return 0;
-}
-
-static int dummy_tbufcontrol (void)
-{
-    return 0;
-}
-
-static int dummy_readconsole (uint32_t clear)
-{
-    return 0;
-}
-
-static int dummy_sched_id (void)
-{
-    return 0;
-}
-
-static int dummy_setdomainmaxmem (struct domain *d)
-{
-    return 0;
-}
-
-static int dummy_setdomainhandle (struct domain *d)
-{
-    return 0;
-}
-
-static int dummy_setdebugging (struct domain *d)
-{
-    return 0;
-}
-
-static int dummy_perfcontrol (void)
-{
-    return 0;
-}
-
-static int dummy_debug_keys (void)
-{
-    return 0;
-}
-
-static int dummy_getcpuinfo (void)
-{
-    return 0;
-}
-
-static int dummy_get_pmstat (void)
-{
-    return 0;
-}
-
-static int dummy_setpminfo (void)
-{
-    return 0;
-}
-
-static int dummy_pm_op (void)
-{
-    return 0;
-}
-
-static int dummy_do_mca (void)
-{
-    return 0;
-}
-
-static int dummy_availheap (void)
-{
-    return 0;
-}
-
-static int dummy_alloc_security_domain (struct domain *d)
-{
-    return 0;
-}
-
-static void dummy_free_security_domain (struct domain *d)
-{
-    return;
-}
-
-static int dummy_grant_mapref (struct domain *d1, struct domain *d2,
-                                                                uint32_t flags)
-{
-    return 0;
-}
-
-static int dummy_grant_unmapref (struct domain *d1, struct domain *d2)
-{
-    return 0;
-}
-
-static int dummy_grant_setup (struct domain *d1, struct domain *d2)
-{
-    return 0;
-}
-
-static int dummy_grant_transfer (struct domain *d1, struct domain *d2)
-{
-    return 0;
-}
-
-static int dummy_grant_copy (struct domain *d1, struct domain *d2)
-{
-    return 0;
-}
-
-static int dummy_grant_query_size (struct domain *d1, struct domain *d2)
-{
-    return 0;
-}
-
-static int dummy_memory_adjust_reservation (struct domain *d1,
-                                                            struct domain *d2)
-{
-    return 0;
-}
-
-static int dummy_memory_stat_reservation (struct domain *d1, struct domain *d2)
-{
-    return 0;
-}
-
-static int dummy_console_io (struct domain *d, int cmd)
-{
-    return 0;
-}
-
-static int dummy_profile (struct domain *d, int op)
-{
-    return 0;
-}
-
-static int dummy_kexec (void)
-{
-    return 0;
-}
-
-static int dummy_schedop_shutdown (struct domain *d1, struct domain *d2)
-{
-    return 0;
-}
-
-static int dummy_memory_pin_page(struct domain *d1, struct domain *d2, struct page_info *page)
-{
-    return 0;
-}
-
-static int dummy_evtchn_unbound (struct domain *d, struct evtchn *chn,
-                                                                    domid_t id2)
-{
-    return 0;
-}
-
-static int dummy_evtchn_interdomain (struct domain *d1, struct evtchn
-                                *chan1, struct domain *d2, struct evtchn *chan2)
-{
-    return 0;
-}
-
-static void dummy_evtchn_close_post (struct evtchn *chn)
-{
-    return;
-}
-
-static int dummy_evtchn_send (struct domain *d, struct evtchn *chn)
-{
-    return 0;
-}
-
-static int dummy_evtchn_status (struct domain *d, struct evtchn *chn)
-{
-    return 0;
-}
-
-static int dummy_evtchn_reset (struct domain *d1, struct domain *d2)
-{
-    return 0;
-}
-
-static int dummy_alloc_security_evtchn (struct evtchn *chn)
-{
-    return 0;
-}
-
-static void dummy_free_security_evtchn (struct evtchn *chn)
-{
-    return;
-}
-
-static char *dummy_show_security_evtchn (struct domain *d, const struct evtchn *chn)
-{
-    return NULL;
-}
-
-static int dummy_get_pod_target(struct domain *d)
-{
-    return 0;
-}
-
-static int dummy_set_pod_target(struct domain *d)
-{
-    return 0;
-}
-
-static int dummy_get_device_group (uint32_t machine_bdf)
-{
-    return 0;
-}
-
-static int dummy_test_assign_device (uint32_t machine_bdf)
-{
-    return 0;
-}
-
-static int dummy_assign_device (struct domain *d, uint32_t machine_bdf)
-{
-    return 0;
-}
-
-static int dummy_deassign_device (struct domain *d, uint32_t machine_bdf)
-{
-    return 0;
-}
-
-static int dummy_resource_plug_core (void)
-{
-    return 0;
-}
-
-static int dummy_resource_unplug_core (void)
-{
-    return 0;
-}
-
-static int dummy_resource_plug_pci (uint32_t machine_bdf)
-{
-    return 0;
-}
-
-static int dummy_resource_unplug_pci (uint32_t machine_bdf)
-{
-    return 0;
-}
-
-static int dummy_resource_setup_pci (uint32_t machine_bdf)
-{
-    return 0;
-}
-
-static int dummy_resource_setup_gsi (int gsi)
-{
-    return 0;
-}
-
-static int dummy_resource_setup_misc (void)
-{
-    return 0;
-}
-
-static int dummy_page_offline (uint32_t cmd)
-{
-    return 0;
-}
-
-static int dummy_lockprof (void)
-{
-    return 0;
-}
-
-static int dummy_cpupool_op (void)
-{
-    return 0;
-}
-
-static int dummy_sched_op (void)
-{
-    return 0;
-}
-
-static long dummy___do_xsm_op(XEN_GUEST_HANDLE(xsm_op_t) op)
-{
-    return -ENOSYS;
-}
-
-static char *dummy_show_irq_sid (int irq)
-{
-    return NULL;
-}
-
-static int dummy_map_domain_pirq (struct domain *d, int irq, void *data)
-{
-    return 0;
-}
-
-static int dummy_unmap_domain_pirq (struct domain *d, int irq)
-{
-    return 0;
-}
-
-static int dummy_irq_permission (struct domain *d, int pirq, uint8_t allow)
-{
-    return 0;
-}
-
-static int dummy_iomem_permission (struct domain *d, uint64_t s, uint64_t e, uint8_t allow)
-{
-    return 0;
-}
-
-static int dummy_iomem_mapping (struct domain *d, uint64_t s, uint64_t e, uint8_t allow)
-{
-    return 0;
-}
-
-static int dummy_pci_config_permission (struct domain *d, uint32_t machine_bdf,
-                                        uint16_t start, uint16_t end,
-                                        uint8_t access)
-{
-    return 0;
-}
-
-#ifdef CONFIG_X86
-static int dummy_shadow_control (struct domain *d, uint32_t op)
-{
-    return 0;
-}
-
-static int dummy_getpageframeinfo (struct domain *d)
-{
-    return 0;
-}
-
-static int dummy_getmemlist (struct domain *d)
-{
-    return 0;
-}
-
-static int dummy_hypercall_init (struct domain *d)
-{
-    return 0;
-}
-
-static int dummy_hvmcontext (struct domain *d, uint32_t cmd)
-{
-    return 0;
-}
-
-static int dummy_address_size (struct domain *d, uint32_t cmd)
-{
-    return 0;
-}
-
-static int dummy_machine_address_size (struct domain *d, uint32_t cmd)
-{
-    return 0;
-}
-
-static int dummy_hvm_param (struct domain *d, unsigned long op)
-{
-    return 0;
-}
-
-static int dummy_hvm_set_pci_intx_level (struct domain *d)
-{
-    return 0;
-}
-
-static int dummy_hvm_set_isa_irq_level (struct domain *d)
-{
-    return 0;
-}
-
-static int dummy_hvm_set_pci_link_route (struct domain *d)
-{
-    return 0;
-}
-
-static int dummy_hvm_inject_msi (struct domain *d)
-{
-    return 0;
-}
-
-static int dummy_mem_event (struct domain *d)
-{
-    return 0;
-}
-
-static int dummy_mem_sharing (struct domain *d)
-{
-    return 0;
-}
-
-static int dummy_apic (struct domain *d, int cmd)
-{
-    return 0;
-}
-
-static int dummy_xen_settime (void)
-{
-    return 0;
-}
-
-static int dummy_memtype (uint32_t access)
-{
-    return 0;
-}
-
-static int dummy_microcode (void)
-{
-    return 0;
-}
-
-static int dummy_physinfo (void)
-{
-    return 0;
-}
-
-static int dummy_platform_quirk (uint32_t quirk)
-{
-    return 0;
-}
-
-static int dummy_firmware_info (void)
-{
-    return 0;
-}
-
-static int dummy_efi_call(void)
-{
-    return 0;
-}
-
-static int dummy_acpi_sleep (void)
-{
-    return 0;
-}
-
-static int dummy_change_freq (void)
-{
-    return 0;
-}
-
-static int dummy_getidletime (void)
-{
-    return 0;
-}
-
-static int dummy_machine_memory_map (void)
-{
-    return 0;
-}
-
-static int dummy_domain_memory_map (struct domain *d)
-{
-    return 0;
-}
-
-static int dummy_mmu_normal_update (struct domain *d, struct domain *t,
-                                    struct domain *f, intpte_t fpte)
-{
-    return 0;
-}
-
-static int dummy_mmu_machphys_update (struct domain *d, struct domain *f, unsigned long mfn)
-{
-    return 0;
-}
-
-static int dummy_update_va_mapping (struct domain *d, struct domain *f, 
-                                                            l1_pgentry_t pte)
-{
-    return 0;
-}
-
-static int dummy_add_to_physmap (struct domain *d1, struct domain *d2)
-{
-    return 0;
-}
-
-static int dummy_remove_from_physmap (struct domain *d1, struct domain *d2)
-{
-    return 0;
-}
-
-static int dummy_sendtrigger (struct domain *d)
-{
-    return 0;
-}
-
-static int dummy_bind_pt_irq (struct domain *d, struct xen_domctl_bind_pt_irq *bind)
-{
-    return 0;
-}
-
-static int dummy_unbind_pt_irq (struct domain *d, struct xen_domctl_bind_pt_irq *bind)
-{
-    return 0;
-}
-
-static int dummy_pin_mem_cacheattr (struct domain *d)
-{
-    return 0;
-}
-
-static int dummy_ext_vcpucontext (struct domain *d, uint32_t cmd)
-{
-    return 0;
-}
-
-static int dummy_vcpuextstate (struct domain *d, uint32_t cmd)
-{
-    return 0;
-}
-
-static int dummy_ioport_permission (struct domain *d, uint32_t s, uint32_t e, uint8_t allow)
-{
-    return 0;
-}
-
-static int dummy_ioport_mapping (struct domain *d, uint32_t s, uint32_t e, uint8_t allow)
-{
-    return 0;
-}
-#endif
+#define XSM_DEFAULT(type, name) type dummy_ ## name
+#include <xsm/dummy.h>
 
 struct xsm_operations dummy_xsm_ops;
 
@@ -732,7 +119,7 @@ void xsm_fixup_ops (struct xsm_operations *ops)
     set_to_dummy_if_null(ops, cpupool_op);
     set_to_dummy_if_null(ops, sched_op);
 
-    set_to_dummy_if_null(ops, __do_xsm_op);
+    set_to_dummy_if_null(ops, do_xsm_op);
 
 #ifdef CONFIG_X86
     set_to_dummy_if_null(ops, shadow_control);
diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
index 6d4b4f0..7cc06a8 100644
--- a/xen/xsm/flask/hooks.c
+++ b/xen/xsm/flask/hooks.c
@@ -1555,7 +1555,7 @@ static struct xsm_operations flask_ops = {
     .cpupool_op = flask_cpupool_op,
     .sched_op = flask_sched_op,
 
-    .__do_xsm_op = do_flask_op,
+    .do_xsm_op = do_flask_op,
 
 #ifdef CONFIG_X86
     .shadow_control = flask_shadow_control,
diff --git a/xen/xsm/xsm_core.c b/xen/xsm/xsm_core.c
index 96c8669..9bf6ab9 100644
--- a/xen/xsm/xsm_core.c
+++ b/xen/xsm/xsm_core.c
@@ -113,7 +113,7 @@ int unregister_xsm(struct xsm_operations *ops)
 
 long do_xsm_op (XEN_GUEST_HANDLE(xsm_op_t) op)
 {
-    return __do_xsm_op(op);
+    return xsm_do_xsm_op(op);
 }
 
 
-- 
1.7.11.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 17 15:24:22 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 15:24:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDdBI-0003kH-HQ; Mon, 17 Sep 2012 15:24:16 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1TDdBF-0003ay-7H
	for xen-devel@lists.xen.org; Mon, 17 Sep 2012 15:24:13 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-2.tower-27.messagelabs.com!1347895445!11317573!1
X-Originating-IP: [63.239.67.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18737 invoked from network); 17 Sep 2012 15:24:06 -0000
Received: from emvm-gh1-uea09.nsa.gov (HELO nsa.gov) (63.239.67.10)
	by server-2.tower-27.messagelabs.com with SMTP;
	17 Sep 2012 15:24:06 -0000
X-TM-IMSS-Message-ID: <537ff43700131d7b@nsa.gov>
Received: from tarius.tycho.ncsc.mil ([144.51.3.1]) by nsa.gov
	([63.239.67.10]) with ESMTP (TREND IMSS SMTP Service 7.1) id
	537ff43700131d7b ; Mon, 17 Sep 2012 11:26:00 -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 q8HFO0xb027504; 
	Mon, 17 Sep 2012 11:24:03 -0400
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xen.org
Date: Mon, 17 Sep 2012 11:23:33 -0400
Message-Id: <1347895425-17959-12-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.11.4
In-Reply-To: <1347895425-17959-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1347895425-17959-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: dgdegra@tycho.nsa.gov, keir@xen.org, Jan Beulich <jbeulich@suse.com>
Subject: [Xen-devel] [PATCH 11/23] xen: avoid calling
	rcu_lock_*target_domain when an XSM hook 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>
MIME-Version: 1.0
Content-Type: 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 rcu_lock_{,remote_}target_domain_by_id functions are wrappers around
an IS_PRIV_FOR check for the current domain. This is now redundant with
XSM hooks, so replace these calls with rcu_lock_domain_by_any_id or
rcu_lock_remote_domain_by_id to remove the duplicate permission checks.

When XSM_ENABLE is not defined or when the dummy XSM module is used,
this patch should not change any functionality. Because the locations of
privilege checks have sometimes moved below argument validation, error
returns of some functions may change from EPERM to EINVAL when called
with invalid arguments and from a domain without permission to perform
the operation.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Cc: Keir Fraser <keir@xen.org>
Cc: Jan Beulich <jbeulich@suse.com>
---
 xen/arch/x86/hvm/hvm.c     | 38 +++++++++++++++----------------
 xen/arch/x86/mm.c          | 22 ++++++++----------
 xen/common/event_channel.c | 18 +++++++--------
 xen/common/grant_table.c   | 57 +++++++++++++++-------------------------------
 xen/common/memory.c        | 15 ++++++------
 xen/include/xsm/dummy.h    | 34 +++++++++++++++++++++++++++
 6 files changed, 97 insertions(+), 87 deletions(-)

diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index dfabe20..a21c9d2 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -3329,7 +3329,7 @@ static int hvmop_set_pci_intx_level(
     if ( (op.domain > 0) || (op.bus > 0) || (op.device > 31) || (op.intx > 3) )
         return -EINVAL;
 
-    rc = rcu_lock_remote_target_domain_by_id(op.domid, &d);
+    rc = rcu_lock_remote_domain_by_id(op.domid, &d);
     if ( rc != 0 )
         return rc;
 
@@ -3494,7 +3494,7 @@ static int hvmop_set_isa_irq_level(
     if ( op.isa_irq > 15 )
         return -EINVAL;
 
-    rc = rcu_lock_remote_target_domain_by_id(op.domid, &d);
+    rc = rcu_lock_remote_domain_by_id(op.domid, &d);
     if ( rc != 0 )
         return rc;
 
@@ -3538,7 +3538,7 @@ static int hvmop_set_pci_link_route(
     if ( (op.link > 3) || (op.isa_irq > 15) )
         return -EINVAL;
 
-    rc = rcu_lock_remote_target_domain_by_id(op.domid, &d);
+    rc = rcu_lock_remote_domain_by_id(op.domid, &d);
     if ( rc != 0 )
         return rc;
 
@@ -3568,7 +3568,7 @@ static int hvmop_inject_msi(
     if ( copy_from_guest(&op, uop, 1) )
         return -EFAULT;
 
-    rc = rcu_lock_remote_target_domain_by_id(op.domid, &d);
+    rc = rcu_lock_remote_domain_by_id(op.domid, &d);
     if ( rc != 0 )
         return rc;
 
@@ -3665,9 +3665,9 @@ long do_hvm_op(unsigned long op, XEN_GUEST_HANDLE(void) arg)
         if ( a.index >= HVM_NR_PARAMS )
             return -EINVAL;
 
-        rc = rcu_lock_target_domain_by_id(a.domid, &d);
-        if ( rc != 0 )
-            return rc;
+        d = rcu_lock_domain_by_any_id(a.domid);
+        if ( d == NULL )
+            return -ESRCH;
 
         rc = -EINVAL;
         if ( !is_hvm_domain(d) )
@@ -3911,7 +3911,7 @@ long do_hvm_op(unsigned long op, XEN_GUEST_HANDLE(void) arg)
         if ( copy_from_guest(&a, arg, 1) )
             return -EFAULT;
 
-        rc = rcu_lock_remote_target_domain_by_id(a.domid, &d);
+        rc = rcu_lock_remote_domain_by_id(a.domid, &d);
         if ( rc != 0 )
             return rc;
 
@@ -3950,7 +3950,7 @@ long do_hvm_op(unsigned long op, XEN_GUEST_HANDLE(void) arg)
         if ( copy_from_guest(&a, arg, 1) )
             return -EFAULT;
 
-        rc = rcu_lock_remote_target_domain_by_id(a.domid, &d);
+        rc = rcu_lock_remote_domain_by_id(a.domid, &d);
         if ( rc != 0 )
             return rc;
 
@@ -4000,9 +4000,9 @@ long do_hvm_op(unsigned long op, XEN_GUEST_HANDLE(void) arg)
         if ( copy_from_guest(&a, arg, 1) )
             return -EFAULT;
 
-        rc = rcu_lock_target_domain_by_id(a.domid, &d);
-        if ( rc != 0 )
-            return rc;
+        d = rcu_lock_domain_by_any_id(a.domid);
+        if ( d == NULL )
+            return -ESRCH;
 
         rc = xsm_hvm_param(d, op);
         if ( rc )
@@ -4047,7 +4047,7 @@ long do_hvm_op(unsigned long op, XEN_GUEST_HANDLE(void) arg)
         if ( copy_from_guest(&a, arg, 1) )
             return -EFAULT;
 
-        rc = rcu_lock_remote_target_domain_by_id(a.domid, &d);
+        rc = rcu_lock_remote_domain_by_id(a.domid, &d);
         if ( rc != 0 )
             return rc;
 
@@ -4126,7 +4126,7 @@ long do_hvm_op(unsigned long op, XEN_GUEST_HANDLE(void) arg)
         if ( copy_from_guest(&a, arg, 1) )
             return -EFAULT;
 
-        rc = rcu_lock_remote_target_domain_by_id(a.domid, &d);
+        rc = rcu_lock_remote_domain_by_id(a.domid, &d);
         if ( rc != 0 )
             return rc;
 
@@ -4161,7 +4161,7 @@ long do_hvm_op(unsigned long op, XEN_GUEST_HANDLE(void) arg)
         if ( copy_from_guest(&a, arg, 1) )
             return -EFAULT;
 
-        rc = rcu_lock_remote_target_domain_by_id(a.domid, &d);
+        rc = rcu_lock_remote_domain_by_id(a.domid, &d);
         if ( rc != 0 )
             return rc;
 
@@ -4197,9 +4197,9 @@ long do_hvm_op(unsigned long op, XEN_GUEST_HANDLE(void) arg)
         if ( copy_from_guest(&a, arg, 1) )
             return -EFAULT;
 
-        rc = rcu_lock_target_domain_by_id(a.domid, &d);
-        if ( rc != 0 )
-            return rc;
+        d = rcu_lock_domain_by_any_id(a.domid);
+        if ( d == NULL )
+            return -ESRCH;
 
         rc = -EINVAL;
         if ( !is_hvm_domain(d) || !paging_mode_shadow(d) )
@@ -4251,7 +4251,7 @@ long do_hvm_op(unsigned long op, XEN_GUEST_HANDLE(void) arg)
         if ( copy_from_guest(&tr, arg, 1 ) )
             return -EFAULT;
 
-        rc = rcu_lock_remote_target_domain_by_id(tr.domid, &d);
+        rc = rcu_lock_remote_domain_by_id(tr.domid, &d);
         if ( rc != 0 )
             return rc;
 
diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
index b370300..5c6ea2d 100644
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -4371,9 +4371,9 @@ long arch_memory_op(int op, XEN_GUEST_HANDLE(void) arg)
         if ( copy_from_guest(&xatp, arg, 1) )
             return -EFAULT;
 
-        rc = rcu_lock_target_domain_by_id(xatp.domid, &d);
-        if ( rc != 0 )
-            return rc;
+        d = rcu_lock_domain_by_any_id(xatp.domid);
+        if ( d == NULL )
+            return -ESRCH;
 
         if ( xsm_add_to_physmap(current->domain, d) )
         {
@@ -4410,9 +4410,9 @@ long arch_memory_op(int op, XEN_GUEST_HANDLE(void) arg)
         if ( fmap.map.nr_entries > E820MAX )
             return -EINVAL;
 
-        rc = rcu_lock_target_domain_by_id(fmap.domid, &d);
-        if ( rc != 0 )
-            return rc;
+        d = rcu_lock_domain_by_any_id(fmap.domid);
+        if ( d == NULL )
+            return -ESRCH;
 
         rc = xsm_domain_memory_map(d);
         if ( rc )
@@ -4563,16 +4563,12 @@ long arch_memory_op(int op, XEN_GUEST_HANDLE(void) arg)
         struct domain *d;
         struct p2m_domain *p2m;
 
-        /* Support DOMID_SELF? */
-        if ( !IS_PRIV(current->domain) )
-            return -EPERM;
-
         if ( copy_from_guest(&target, arg, 1) )
             return -EFAULT;
 
-        rc = rcu_lock_target_domain_by_id(target.domid, &d);
-        if ( rc != 0 )
-            return rc;
+        d = rcu_lock_domain_by_any_id(target.domid);
+        if ( d == NULL )
+            return -ESRCH;
 
         if ( op == XENMEM_set_pod_target )
             rc = xsm_set_pod_target(d);
diff --git a/xen/common/event_channel.c b/xen/common/event_channel.c
index 53777f8..70becdd 100644
--- a/xen/common/event_channel.c
+++ b/xen/common/event_channel.c
@@ -165,9 +165,9 @@ static long evtchn_alloc_unbound(evtchn_alloc_unbound_t *alloc)
     domid_t        dom = alloc->dom;
     long           rc;
 
-    rc = rcu_lock_target_domain_by_id(dom, &d);
-    if ( rc )
-        return rc;
+    d = rcu_lock_domain_by_any_id(dom);
+    if ( d == NULL )
+        return -ESRCH;
 
     spin_lock(&d->event_lock);
 
@@ -798,9 +798,9 @@ static long evtchn_status(evtchn_status_t *status)
     struct evtchn   *chn;
     long             rc = 0;
 
-    rc = rcu_lock_target_domain_by_id(dom, &d);
-    if ( rc )
-        return rc;
+    d = rcu_lock_domain_by_any_id(dom);
+    if ( d == NULL )
+        return -ESRCH;
 
     spin_lock(&d->event_lock);
 
@@ -950,9 +950,9 @@ static long evtchn_reset(evtchn_reset_t *r)
     struct domain *d;
     int i, rc;
 
-    rc = rcu_lock_target_domain_by_id(dom, &d);
-    if ( rc )
-        return rc;
+    d = rcu_lock_domain_by_any_id(dom);
+    if ( d == NULL )
+        return -ESRCH;
 
     rc = xsm_evtchn_reset(current->domain, d);
     if ( rc )
diff --git a/xen/common/grant_table.c b/xen/common/grant_table.c
index c23c053..10a34d6 100644
--- a/xen/common/grant_table.c
+++ b/xen/common/grant_table.c
@@ -230,30 +230,6 @@ double_gt_unlock(struct grant_table *lgt, struct grant_table *rgt)
         spin_unlock(&rgt->lock);
 }
 
-static struct domain *gt_lock_target_domain_by_id(domid_t dom)
-{
-    struct domain *d;
-    int rc = GNTST_general_error;
-
-    switch ( rcu_lock_target_domain_by_id(dom, &d) )
-    {
-    case 0:
-        return d;
-
-    case -ESRCH:
-        gdprintk(XENLOG_INFO, "Bad domid %d.\n", dom);
-        rc = GNTST_bad_domain;
-        break;
-
-    case -EPERM:
-        rc = GNTST_permission_denied;
-        break;
-    }
-
-    ASSERT(rc < 0 && -rc <= MAX_ERRNO);
-    return ERR_PTR(rc);
-}
-
 static inline int
 __get_maptrack_handle(
     struct grant_table *t)
@@ -1339,11 +1315,12 @@ gnttab_setup_table(
         goto out1;
     }
 
-    d = gt_lock_target_domain_by_id(op.dom);
-    if ( IS_ERR(d) )
+    d = rcu_lock_domain_by_any_id(op.dom);
+    if ( d == NULL )
     {
-        op.status = PTR_ERR(d);
-        goto out1;
+        gdprintk(XENLOG_INFO, "Bad domid %d.\n", op.dom);
+        op.status = GNTST_bad_domain;
+        goto out2;
     }
 
     if ( xsm_grant_setup(current->domain, d) )
@@ -1407,10 +1384,11 @@ gnttab_query_size(
         return -EFAULT;
     }
 
-    d = gt_lock_target_domain_by_id(op.dom);
-    if ( IS_ERR(d) )
+    d = rcu_lock_domain_by_any_id(op.dom);
+    if ( d == NULL )
     {
-        op.status = PTR_ERR(d);
+        gdprintk(XENLOG_INFO, "Bad domid %d.\n", op.dom);
+        op.status = GNTST_bad_domain;
         goto query_out;
     }
 
@@ -2280,10 +2258,10 @@ gnttab_get_status_frames(XEN_GUEST_HANDLE(gnttab_get_status_frames_t) uop,
         return -EFAULT;
     }
 
-    d = gt_lock_target_domain_by_id(op.dom);
-    if ( IS_ERR(d) )
+    d = rcu_lock_domain_by_any_id(op.dom);
+    if ( d == NULL )
     {
-        op.status = PTR_ERR(d);
+        op.status = GNTST_bad_domain;
         goto out1;
     }
     rc = xsm_grant_setup(current->domain, d);
@@ -2333,14 +2311,15 @@ gnttab_get_version(XEN_GUEST_HANDLE(gnttab_get_version_t uop))
     if ( copy_from_guest(&op, uop, 1) )
         return -EFAULT;
 
-    rc = rcu_lock_target_domain_by_id(op.dom, &d);
-    if ( rc < 0 )
-        return rc;
+    d = rcu_lock_domain_by_any_id(op.dom);
+    if ( d == NULL )
+        return -ESRCH;
 
-    if ( xsm_grant_query_size(current->domain, d) )
+    rc = xsm_grant_query_size(current->domain, d);
+    if ( rc )
     {
         rcu_unlock_domain(d);
-        return -EPERM;
+        return rc;
     }
 
     op.version = d->grant_table->gt_version;
diff --git a/xen/common/memory.c b/xen/common/memory.c
index 5bcb035..a984d51 100644
--- a/xen/common/memory.c
+++ b/xen/common/memory.c
@@ -570,7 +570,8 @@ long do_memory_op(unsigned long cmd, XEN_GUEST_HANDLE(void) arg)
              && (reservation.mem_flags & XENMEMF_populate_on_demand) )
             args.memflags |= MEMF_populate_on_demand;
 
-        if ( unlikely(rcu_lock_target_domain_by_id(reservation.domid, &d)) )
+        d = rcu_lock_domain_by_any_id(reservation.domid);
+        if ( d == NULL )
             return start_extent;
         args.domain = d;
 
@@ -619,9 +620,9 @@ long do_memory_op(unsigned long cmd, XEN_GUEST_HANDLE(void) arg)
         if ( copy_from_guest(&domid, arg, 1) )
             return -EFAULT;
 
-        rc = rcu_lock_target_domain_by_id(domid, &d);
-        if ( rc )
-            return rc;
+        d = rcu_lock_domain_by_any_id(domid);
+        if ( d == NULL )
+            return -ESRCH;
 
         rc = xsm_memory_stat_reservation(current->domain, d);
         if ( rc )
@@ -657,9 +658,9 @@ long do_memory_op(unsigned long cmd, XEN_GUEST_HANDLE(void) arg)
         if ( copy_from_guest(&xrfp, arg, 1) )
             return -EFAULT;
 
-        rc = rcu_lock_target_domain_by_id(xrfp.domid, &d);
-        if ( rc != 0 )
-            return rc;
+        d = rcu_lock_domain_by_any_id(xrfp.domid);
+        if ( d == NULL )
+            return -ESRCH;
 
         if ( xsm_remove_from_physmap(current->domain, d) )
         {
diff --git a/xen/include/xsm/dummy.h b/xen/include/xsm/dummy.h
index 7cb229d..448b5c1 100644
--- a/xen/include/xsm/dummy.h
+++ b/xen/include/xsm/dummy.h
@@ -194,6 +194,8 @@ static XSM_DEFAULT(int, grant_unmapref) (struct domain *d1, struct domain *d2)
 
 static XSM_DEFAULT(int, grant_setup) (struct domain *d1, struct domain *d2)
 {
+    if ( d1 != d2 && !IS_PRIV_FOR(d1, d2) )
+        return -EPERM;
     return 0;
 }
 
@@ -209,17 +211,23 @@ static XSM_DEFAULT(int, grant_copy) (struct domain *d1, struct domain *d2)
 
 static XSM_DEFAULT(int, grant_query_size) (struct domain *d1, struct domain *d2)
 {
+    if ( d1 != d2 && !IS_PRIV_FOR(d1, d2) )
+        return -EPERM;
     return 0;
 }
 
 static XSM_DEFAULT(int, memory_adjust_reservation) (struct domain *d1,
                                                             struct domain *d2)
 {
+    if ( d1 != d2 && !IS_PRIV_FOR(d1, d2) )
+        return -EPERM;
     return 0;
 }
 
 static XSM_DEFAULT(int, memory_stat_reservation) (struct domain *d1, struct domain *d2)
 {
+    if ( d1 != d2 && !IS_PRIV_FOR(d1, d2) )
+        return -EPERM;
     return 0;
 }
 
@@ -260,6 +268,8 @@ static XSM_DEFAULT(int, memory_pin_page) (struct domain *d1, struct domain *d2,
 static XSM_DEFAULT(int, evtchn_unbound) (struct domain *d, struct evtchn *chn,
                                          domid_t id2)
 {
+    if ( current->domain != d && !IS_PRIV_FOR(current->domain, d) )
+        return -EPERM;
     return 0;
 }
 
@@ -281,11 +291,15 @@ static XSM_DEFAULT(int, evtchn_send) (struct domain *d, struct evtchn *chn)
 
 static XSM_DEFAULT(int, evtchn_status) (struct domain *d, struct evtchn *chn)
 {
+    if ( current->domain != d && !IS_PRIV_FOR(current->domain, d) )
+        return -EPERM;
     return 0;
 }
 
 static XSM_DEFAULT(int, evtchn_reset) (struct domain *d1, struct domain *d2)
 {
+    if ( d1 != d2 && !IS_PRIV_FOR(d1, d2) )
+        return -EPERM;
     return 0;
 }
 
@@ -306,11 +320,15 @@ static XSM_DEFAULT(char *, show_security_evtchn) (struct domain *d, const struct
 
 static XSM_DEFAULT(int, get_pod_target)(struct domain *d)
 {
+    if ( !IS_PRIV(current->domain) )
+        return -EPERM;
     return 0;
 }
 
 static XSM_DEFAULT(int, set_pod_target)(struct domain *d)
 {
+    if ( !IS_PRIV(current->domain) )
+        return -EPERM;
     return 0;
 }
 
@@ -481,26 +499,36 @@ static XSM_DEFAULT(int, machine_address_size) (struct domain *d, uint32_t cmd)
 
 static XSM_DEFAULT(int, hvm_param) (struct domain *d, unsigned long op)
 {
+    if ( current->domain != d && !IS_PRIV_FOR(current->domain, d) )
+        return -EPERM;
     return 0;
 }
 
 static XSM_DEFAULT(int, hvm_set_pci_intx_level) (struct domain *d)
 {
+    if ( !IS_PRIV_FOR(current->domain, d) )
+        return -EPERM;
     return 0;
 }
 
 static XSM_DEFAULT(int, hvm_set_isa_irq_level) (struct domain *d)
 {
+    if ( !IS_PRIV_FOR(current->domain, d) )
+        return -EPERM;
     return 0;
 }
 
 static XSM_DEFAULT(int, hvm_set_pci_link_route) (struct domain *d)
 {
+    if ( !IS_PRIV_FOR(current->domain, d) )
+        return -EPERM;
     return 0;
 }
 
 static XSM_DEFAULT(int, hvm_inject_msi) (struct domain *d)
 {
+    if ( !IS_PRIV_FOR(current->domain, d) )
+        return -EPERM;
     return 0;
 }
 
@@ -582,6 +610,8 @@ static XSM_DEFAULT(int, machine_memory_map) (void)
 
 static XSM_DEFAULT(int, domain_memory_map) (struct domain *d)
 {
+    if ( current->domain != d && !IS_PRIV_FOR(current->domain, d) )
+        return -EPERM;
     return 0;
 }
 
@@ -605,11 +635,15 @@ static XSM_DEFAULT(int, update_va_mapping) (struct domain *d, struct domain *f,
 
 static XSM_DEFAULT(int, add_to_physmap) (struct domain *d1, struct domain *d2)
 {
+    if ( d1 != d2 && !IS_PRIV_FOR(d1, d2) )
+        return -EPERM;
     return 0;
 }
 
 static XSM_DEFAULT(int, remove_from_physmap) (struct domain *d1, struct domain *d2)
 {
+    if ( d1 != d2 && !IS_PRIV_FOR(d1, d2) )
+        return -EPERM;
     return 0;
 }
 
-- 
1.7.11.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 17 15:24:22 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 15:24:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDdBA-0003bR-Fl; Mon, 17 Sep 2012 15:24:08 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1TDdB8-0003Zv-0j
	for xen-devel@lists.xen.org; Mon, 17 Sep 2012 15:24:06 +0000
Received: from [85.158.139.211:45644] by server-1.bemta-5.messagelabs.com id
	82/F9-32692-59047505; Mon, 17 Sep 2012 15:24:05 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-11.tower-206.messagelabs.com!1347895443!18904562!1
X-Originating-IP: [63.239.67.9]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30116 invoked from network); 17 Sep 2012 15:24:03 -0000
Received: from emvm-gh1-uea08.nsa.gov (HELO nsa.gov) (63.239.67.9)
	by server-11.tower-206.messagelabs.com with SMTP;
	17 Sep 2012 15:24:03 -0000
X-TM-IMSS-Message-ID: <53802d9e0012acc6@nsa.gov>
Received: from tarius.tycho.ncsc.mil ([144.51.3.1]) by nsa.gov ([63.239.67.9])
	with ESMTP (TREND IMSS SMTP Service 7.1) id 53802d9e0012acc6 ;
	Mon, 17 Sep 2012 11:23:42 -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 q8HFO0xR027504; 
	Mon, 17 Sep 2012 11:24:00 -0400
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xen.org
Date: Mon, 17 Sep 2012 11:23:23 -0400
Message-Id: <1347895425-17959-2-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.11.4
In-Reply-To: <1347895425-17959-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1347895425-17959-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: dgdegra@tycho.nsa.gov, keir@xen.org
Subject: [Xen-devel] [PATCH 01/23] xsm/flask: remove inherited class
	attributes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 ability to declare common permission blocks shared across multiple
classes is not currently used in Xen. Currently, support for this
feature is broken in the header generation scripts, and it is not
expected that this feature will be used in the future, so remove the
dead code.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 tools/flask/policy/policy/flask/Makefile           |  2 +-
 tools/flask/policy/policy/flask/access_vectors     | 17 +----
 tools/flask/policy/policy/flask/mkaccess_vector.sh | 89 ----------------------
 xen/xsm/flask/avc.c                                | 39 ----------
 xen/xsm/flask/include/av_inherit.h                 |  1 -
 xen/xsm/flask/include/avc_ss.h                     |  8 --
 xen/xsm/flask/include/common_perm_to_string.h      |  1 -
 xen/xsm/flask/ss/policydb.c                        | 46 +----------
 xen/xsm/flask/ss/services.c                        | 54 +------------
 9 files changed, 8 insertions(+), 249 deletions(-)
 delete mode 100644 xen/xsm/flask/include/av_inherit.h
 delete mode 100644 xen/xsm/flask/include/common_perm_to_string.h

diff --git a/tools/flask/policy/policy/flask/Makefile b/tools/flask/policy/policy/flask/Makefile
index 970b9fe..5f57e88 100644
--- a/tools/flask/policy/policy/flask/Makefile
+++ b/tools/flask/policy/policy/flask/Makefile
@@ -14,7 +14,7 @@ FLASK_H_DEPEND = security_classes initial_sids
 AV_H_DEPEND = access_vectors
 
 FLASK_H_FILES = class_to_string.h flask.h initial_sid_to_string.h
-AV_H_FILES = av_inherit.h common_perm_to_string.h av_perm_to_string.h av_permissions.h
+AV_H_FILES = av_perm_to_string.h av_permissions.h
 ALL_H_FILES = $(FLASK_H_FILES) $(AV_H_FILES)
 
 all:  $(ALL_H_FILES)
diff --git a/tools/flask/policy/policy/flask/access_vectors b/tools/flask/policy/policy/flask/access_vectors
index 5901911..a884312 100644
--- a/tools/flask/policy/policy/flask/access_vectors
+++ b/tools/flask/policy/policy/flask/access_vectors
@@ -1,22 +1,7 @@
 #
-# Define common prefixes for access vectors
-#
-# common common_name { permission_name ... }
-
-#
-# Define a common prefix for file access vectors.
-#
-
-
-#
 # Define the access vectors.
 #
-# class class_name [ inherits common_name ] { permission_name ... }
-
-
-#
-# Define the access vector interpretation for file-related objects.
-#
+# class class_name { permission_name ... }
 
 class xen
 {
diff --git a/tools/flask/policy/policy/flask/mkaccess_vector.sh b/tools/flask/policy/policy/flask/mkaccess_vector.sh
index b5da734..43a60a7 100644
--- a/tools/flask/policy/policy/flask/mkaccess_vector.sh
+++ b/tools/flask/policy/policy/flask/mkaccess_vector.sh
@@ -10,50 +10,21 @@ shift
 
 # output files
 av_permissions="av_permissions.h"
-av_inherit="av_inherit.h"
-common_perm_to_string="common_perm_to_string.h"
 av_perm_to_string="av_perm_to_string.h"
 
 cat $* | $awk "
 BEGIN	{
 		outfile = \"$av_permissions\"
-		inheritfile = \"$av_inherit\"
-		cpermfile = \"$common_perm_to_string\"
 		avpermfile = \"$av_perm_to_string\"
 		"'
 		nextstate = "COMMON_OR_AV";
 		printf("/* This file is automatically generated.  Do not edit. */\n") > outfile;
-		printf("/* This file is automatically generated.  Do not edit. */\n") > inheritfile;
-		printf("/* This file is automatically generated.  Do not edit. */\n") > cpermfile;
 		printf("/* This file is automatically generated.  Do not edit. */\n") > avpermfile;
 ;
 	}
 /^[ \t]*#/	{ 
 			next;
 		}
-$1 == "common"	{ 
-			if (nextstate != "COMMON_OR_AV")
-			{
-				printf("Parse error:  Unexpected COMMON definition on line %d\n", NR);
-				next;	
-			}
-
-			if ($2 in common_defined)
-			{
-				printf("Duplicate COMMON definition for %s on line %d.\n", $2, NR);
-				next;
-			}	
-			common_defined[$2] = 1;
-
-			tclass = $2;
-			common_name = $2; 
-			permission = 1;
-
-			printf("TB_(common_%s_perm_to_string)\n", $2) > cpermfile;
-
-			nextstate = "COMMON-OPENBRACKET";
-			next;
-		}
 $1 == "class"	{
 			if (nextstate != "COMMON_OR_AV" &&
 			    nextstate != "CLASS_OR_CLASS-OPENBRACKET")
@@ -71,62 +42,11 @@ $1 == "class"	{
 			} 
 			av_defined[tclass] = 1;
 
-			inherits = "";
 			permission = 1;
 
 			nextstate = "INHERITS_OR_CLASS-OPENBRACKET";
 			next;
 		}
-$1 == "inherits" {			
-			if (nextstate != "INHERITS_OR_CLASS-OPENBRACKET")
-			{
-				printf("Parse error:  Unexpected INHERITS definition on line %d\n", NR);
-				next;	
-			}
-
-			if (!($2 in common_defined))
-			{
-				printf("COMMON %s is not defined (line %d).\n", $2, NR);
-				next;
-			}
-
-			inherits = $2;
-			permission = common_base[$2];
-
-			for (combined in common_perms)
-			{
-				split(combined,separate, SUBSEP);
-				if (separate[1] == inherits)
-				{
-					inherited_perms[common_perms[combined]] = separate[2];
-				}
-			}
-
-                        j = 1;
-                        for (i in inherited_perms) {
-                            ind[j] = i + 0;
-                            j++;
-                        }
-                        n = asort(ind);
-			for (i = 1; i <= n; i++) {
-				perm = inherited_perms[ind[i]];
-				printf("#define %s__%s", toupper(tclass), toupper(perm)) > outfile; 
-				spaces = 40 - (length(perm) + length(tclass));
-				if (spaces < 1)
-				      spaces = 1;
-				for (j = 0; j < spaces; j++) 
-					printf(" ") > outfile; 
-				printf("0x%08xUL\n", ind[i]) > outfile; 
-			}
-			printf("\n") > outfile;
-                        for (i in ind) delete ind[i];
-                        for (i in inherited_perms) delete inherited_perms[i];
-
-			printf("   S_(SECCLASS_%s, %s, 0x%08xUL)\n", toupper(tclass), inherits, permission) > inheritfile; 
-
-			nextstate = "CLASS_OR_CLASS-OPENBRACKET";
-			next;
-		}
 $1 == "{"	{ 
 			if (nextstate != "INHERITS_OR_CLASS-OPENBRACKET" &&
 			    nextstate != "CLASS_OR_CLASS-OPENBRACKET" &&
@@ -177,15 +97,6 @@ $1 == "{"	{
 
 				av_perms[tclass,$1] = permission;
 		
-				if (inherits != "")
-				{
-					if ((inherits,$1) in common_perms)
-					{
-						printf("Permission %s in %s on line %d conflicts with common permission.\n", $1, tclass, inherits, NR);
-						next;
-					}
-				}
-
 				printf("#define %s__%s", toupper(tclass), toupper($1)) > outfile; 
 
 				printf("   S_(SECCLASS_%s, %s__%s, \"%s\")\n", toupper(tclass), toupper(tclass), toupper($1), $1) > avpermfile; 
diff --git a/xen/xsm/flask/avc.c b/xen/xsm/flask/avc.c
index 44240a9..7fede00 100644
--- a/xen/xsm/flask/avc.c
+++ b/xen/xsm/flask/avc.c
@@ -45,28 +45,11 @@ static const char *class_to_string[] = {
 #undef S_
 };
 
-#define TB_(s) static const char * s [] = {
-#define TE_(s) };
-#define S_(s) s,
-#include "common_perm_to_string.h"
-#undef TB_
-#undef TE_
-#undef S_
-
-static const struct av_inherit av_inherit[] = {
-#define S_(c, i, b) { .tclass = c, .common_pts = common_##i##_perm_to_string, \
-                      .common_base = b },
-#include "av_inherit.h"
-#undef S_
-};
-
 const struct selinux_class_perm selinux_class_perm = {
     .av_perm_to_string = av_perm_to_string,
     .av_pts_len = ARRAY_SIZE(av_perm_to_string),
     .class_to_string = class_to_string,
     .cts_len = ARRAY_SIZE(class_to_string),
-    .av_inherit = av_inherit,
-    .av_inherit_len = ARRAY_SIZE(av_inherit)
 };
 
 #define AVC_CACHE_SLOTS            512
@@ -181,8 +164,6 @@ static void avc_printk(struct avc_dump_buf *buf, const char *fmt, ...)
  */
 static void avc_dump_av(struct avc_dump_buf *buf, u16 tclass, u32 av)
 {
-    const char **common_pts = NULL;
-    u32 common_base = 0;
     int i, i2, perm;
 
     if ( av == 0 )
@@ -191,29 +172,9 @@ static void avc_dump_av(struct avc_dump_buf *buf, u16 tclass, u32 av)
         return;
     }
 
-    for ( i = 0; i < ARRAY_SIZE(av_inherit); i++ )
-    {
-        if (av_inherit[i].tclass == tclass)
-        {
-            common_pts = av_inherit[i].common_pts;
-            common_base = av_inherit[i].common_base;
-            break;
-        }
-    }
-
     avc_printk(buf, " {");
     i = 0;
     perm = 1;
-    while ( perm < common_base )
-    {
-        if (perm & av)
-        {
-            avc_printk(buf, " %s", common_pts[i]);
-            av &= ~perm;
-        }
-        i++;
-        perm <<= 1;
-    }
 
     while ( i < sizeof(av) * 8 )
     {
diff --git a/xen/xsm/flask/include/av_inherit.h b/xen/xsm/flask/include/av_inherit.h
deleted file mode 100644
index 321ffe7..0000000
--- a/xen/xsm/flask/include/av_inherit.h
+++ /dev/null
@@ -1 +0,0 @@
-/* This file is automatically generated.  Do not edit. */
diff --git a/xen/xsm/flask/include/avc_ss.h b/xen/xsm/flask/include/avc_ss.h
index ea4e98c..a3d7d1e 100644
--- a/xen/xsm/flask/include/avc_ss.h
+++ b/xen/xsm/flask/include/avc_ss.h
@@ -16,19 +16,11 @@ struct av_perm_to_string {
     const char *name;
 };
 
-struct av_inherit {
-    const char **common_pts;
-    u32 common_base;
-    u16 tclass;
-};
-
 struct selinux_class_perm {
     const struct av_perm_to_string *av_perm_to_string;
     u32 av_pts_len;
     u32 cts_len;
     const char **class_to_string;
-    const struct av_inherit *av_inherit;
-    u32 av_inherit_len;
 };
 
 extern const struct selinux_class_perm selinux_class_perm;
diff --git a/xen/xsm/flask/include/common_perm_to_string.h b/xen/xsm/flask/include/common_perm_to_string.h
deleted file mode 100644
index 321ffe7..0000000
--- a/xen/xsm/flask/include/common_perm_to_string.h
+++ /dev/null
@@ -1 +0,0 @@
-/* This file is automatically generated.  Do not edit. */
diff --git a/xen/xsm/flask/ss/policydb.c b/xen/xsm/flask/ss/policydb.c
index 26097b9..fefcd59 100644
--- a/xen/xsm/flask/ss/policydb.c
+++ b/xen/xsm/flask/ss/policydb.c
@@ -254,14 +254,6 @@ out_free_symtab:
 
 static int common_index(void *key, void *datum, void *datap)
 {
-    struct policydb *p;
-    struct common_datum *comdatum;
-
-    comdatum = datum;
-    p = datap;
-    if ( !comdatum->value || comdatum->value > p->p_commons.nprim )
-        return -EINVAL;
-    p->p_common_val_to_name[comdatum->value - 1] = key;
     return 0;
 }
 
@@ -382,8 +374,7 @@ static int (*index_f[SYM_NUM]) (void *key, void *datum, void *datap) =
 };
 
 /*
- * Define the common val_to_name array and the class
- * val_to_name and val_to_struct arrays in a policy
+ * Define the class val_to_name and val_to_struct arrays in a policy
  * database structure.
  *
  * Caller must clean up upon failure.
@@ -392,18 +383,6 @@ static int policydb_index_classes(struct policydb *p)
 {
     int rc;
 
-    p->p_common_val_to_name =
-        xmalloc_array(char *, p->p_commons.nprim);
-    if ( !p->p_common_val_to_name )
-    {
-        rc = -ENOMEM;
-        goto out;
-    }
-
-    rc = hashtab_map(p->p_commons.table, common_index, p);
-    if ( rc )
-        goto out;
-
     p->class_val_to_struct =
         xmalloc_array(struct class_datum *, p->p_classes.nprim);
     if ( !p->class_val_to_struct )
@@ -1200,26 +1179,9 @@ static int class_read(struct policydb *p, struct hashtab *h, void *fp)
 
     if ( len2 )
     {
-        cladatum->comkey = xmalloc_array(char, len2 + 1);
-        if ( !cladatum->comkey )
-        {
-            rc = -ENOMEM;
-            goto bad;
-        }
-        rc = next_entry(cladatum->comkey, fp, len2);
-        if ( rc < 0 )
-            goto bad;
-        cladatum->comkey[len2] = 0;
-
-        cladatum->comdatum = hashtab_search(p->p_commons.table,
-                            cladatum->comkey);
-        if ( !cladatum->comdatum )
-        {
-            printk(KERN_ERR "Flask:  unknown common %s\n",
-                   cladatum->comkey);
-            rc = -EINVAL;
-            goto bad;
-        }
+        printk(KERN_ERR "Flask:  classes with common prefixes are not supported\n");
+        rc = -EINVAL;
+        goto bad;
     }
     for ( i = 0; i < nel; i++ )
     {
diff --git a/xen/xsm/flask/ss/services.c b/xen/xsm/flask/ss/services.c
index 363f586..1bf3b0c 100644
--- a/xen/xsm/flask/ss/services.c
+++ b/xen/xsm/flask/ss/services.c
@@ -1167,10 +1167,10 @@ int security_change_sid(u32 ssid, u32 tsid, u16 tclass, u32 *out_sid)
  */
 static int validate_classes(struct policydb *p)
 {
-    int i, j;
+    int i;
     struct class_datum *cladatum;
     struct perm_datum *perdatum;
-    u32 nprim, tmp, common_pts_len, perm_val, pol_val;
+    u32 nprim, perm_val, pol_val;
     u16 class_val;
     const struct selinux_class_perm *kdefs = &selinux_class_perm;
     const char *def_class, *def_perm, *pol_class;
@@ -1233,56 +1233,6 @@ static int validate_classes(struct policydb *p)
             return -EINVAL;
         }
     }
-    for ( i = 0; i < kdefs->av_inherit_len; i++ )
-    {
-        class_val = kdefs->av_inherit[i].tclass;
-        if ( class_val > p->p_classes.nprim )
-            continue;
-        pol_class = p->p_class_val_to_name[class_val-1];
-        cladatum = hashtab_search(p->p_classes.table, pol_class);
-        BUG_ON( !cladatum );
-        if ( !cladatum->comdatum )
-        {
-            printk(KERN_ERR
-            "Flask:  class %s should have an inherits clause but does not\n",
-                   pol_class);
-            return -EINVAL;
-        }
-        tmp = kdefs->av_inherit[i].common_base;
-        common_pts_len = 0;
-        while ( !(tmp & 0x01) )
-        {
-            common_pts_len++;
-            tmp >>= 1;
-        }
-        perms = &cladatum->comdatum->permissions;
-        for ( j = 0; j < common_pts_len; j++ )
-        {
-            def_perm = kdefs->av_inherit[i].common_pts[j];
-            if ( j >= perms->nprim )
-            {
-                printk(KERN_INFO
-                "Flask:  permission %s in class %s not defined in policy\n",
-                       def_perm, pol_class);
-                return -EINVAL;
-            }
-            perdatum = hashtab_search(perms->table, def_perm);
-            if ( perdatum == NULL )
-            {
-                printk(KERN_ERR
-                       "Flask:  permission %s in class %s not found in policy\n",
-                       def_perm, pol_class);
-                return -EINVAL;
-            }
-            if ( perdatum->value != j + 1 )
-            {
-                printk(KERN_ERR
-                      "Flask:  permission %s in class %s has incorrect value\n",
-                       def_perm, pol_class);
-                return -EINVAL;
-            }
-        }
-    }
     return 0;
 }
 
-- 
1.7.11.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 17 15:24:22 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 15:24:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDdBI-0003kH-HQ; Mon, 17 Sep 2012 15:24:16 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1TDdBF-0003ay-7H
	for xen-devel@lists.xen.org; Mon, 17 Sep 2012 15:24:13 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-2.tower-27.messagelabs.com!1347895445!11317573!1
X-Originating-IP: [63.239.67.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18737 invoked from network); 17 Sep 2012 15:24:06 -0000
Received: from emvm-gh1-uea09.nsa.gov (HELO nsa.gov) (63.239.67.10)
	by server-2.tower-27.messagelabs.com with SMTP;
	17 Sep 2012 15:24:06 -0000
X-TM-IMSS-Message-ID: <537ff43700131d7b@nsa.gov>
Received: from tarius.tycho.ncsc.mil ([144.51.3.1]) by nsa.gov
	([63.239.67.10]) with ESMTP (TREND IMSS SMTP Service 7.1) id
	537ff43700131d7b ; Mon, 17 Sep 2012 11:26:00 -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 q8HFO0xb027504; 
	Mon, 17 Sep 2012 11:24:03 -0400
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xen.org
Date: Mon, 17 Sep 2012 11:23:33 -0400
Message-Id: <1347895425-17959-12-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.11.4
In-Reply-To: <1347895425-17959-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1347895425-17959-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: dgdegra@tycho.nsa.gov, keir@xen.org, Jan Beulich <jbeulich@suse.com>
Subject: [Xen-devel] [PATCH 11/23] xen: avoid calling
	rcu_lock_*target_domain when an XSM hook 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>
MIME-Version: 1.0
Content-Type: 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 rcu_lock_{,remote_}target_domain_by_id functions are wrappers around
an IS_PRIV_FOR check for the current domain. This is now redundant with
XSM hooks, so replace these calls with rcu_lock_domain_by_any_id or
rcu_lock_remote_domain_by_id to remove the duplicate permission checks.

When XSM_ENABLE is not defined or when the dummy XSM module is used,
this patch should not change any functionality. Because the locations of
privilege checks have sometimes moved below argument validation, error
returns of some functions may change from EPERM to EINVAL when called
with invalid arguments and from a domain without permission to perform
the operation.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Cc: Keir Fraser <keir@xen.org>
Cc: Jan Beulich <jbeulich@suse.com>
---
 xen/arch/x86/hvm/hvm.c     | 38 +++++++++++++++----------------
 xen/arch/x86/mm.c          | 22 ++++++++----------
 xen/common/event_channel.c | 18 +++++++--------
 xen/common/grant_table.c   | 57 +++++++++++++++-------------------------------
 xen/common/memory.c        | 15 ++++++------
 xen/include/xsm/dummy.h    | 34 +++++++++++++++++++++++++++
 6 files changed, 97 insertions(+), 87 deletions(-)

diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index dfabe20..a21c9d2 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -3329,7 +3329,7 @@ static int hvmop_set_pci_intx_level(
     if ( (op.domain > 0) || (op.bus > 0) || (op.device > 31) || (op.intx > 3) )
         return -EINVAL;
 
-    rc = rcu_lock_remote_target_domain_by_id(op.domid, &d);
+    rc = rcu_lock_remote_domain_by_id(op.domid, &d);
     if ( rc != 0 )
         return rc;
 
@@ -3494,7 +3494,7 @@ static int hvmop_set_isa_irq_level(
     if ( op.isa_irq > 15 )
         return -EINVAL;
 
-    rc = rcu_lock_remote_target_domain_by_id(op.domid, &d);
+    rc = rcu_lock_remote_domain_by_id(op.domid, &d);
     if ( rc != 0 )
         return rc;
 
@@ -3538,7 +3538,7 @@ static int hvmop_set_pci_link_route(
     if ( (op.link > 3) || (op.isa_irq > 15) )
         return -EINVAL;
 
-    rc = rcu_lock_remote_target_domain_by_id(op.domid, &d);
+    rc = rcu_lock_remote_domain_by_id(op.domid, &d);
     if ( rc != 0 )
         return rc;
 
@@ -3568,7 +3568,7 @@ static int hvmop_inject_msi(
     if ( copy_from_guest(&op, uop, 1) )
         return -EFAULT;
 
-    rc = rcu_lock_remote_target_domain_by_id(op.domid, &d);
+    rc = rcu_lock_remote_domain_by_id(op.domid, &d);
     if ( rc != 0 )
         return rc;
 
@@ -3665,9 +3665,9 @@ long do_hvm_op(unsigned long op, XEN_GUEST_HANDLE(void) arg)
         if ( a.index >= HVM_NR_PARAMS )
             return -EINVAL;
 
-        rc = rcu_lock_target_domain_by_id(a.domid, &d);
-        if ( rc != 0 )
-            return rc;
+        d = rcu_lock_domain_by_any_id(a.domid);
+        if ( d == NULL )
+            return -ESRCH;
 
         rc = -EINVAL;
         if ( !is_hvm_domain(d) )
@@ -3911,7 +3911,7 @@ long do_hvm_op(unsigned long op, XEN_GUEST_HANDLE(void) arg)
         if ( copy_from_guest(&a, arg, 1) )
             return -EFAULT;
 
-        rc = rcu_lock_remote_target_domain_by_id(a.domid, &d);
+        rc = rcu_lock_remote_domain_by_id(a.domid, &d);
         if ( rc != 0 )
             return rc;
 
@@ -3950,7 +3950,7 @@ long do_hvm_op(unsigned long op, XEN_GUEST_HANDLE(void) arg)
         if ( copy_from_guest(&a, arg, 1) )
             return -EFAULT;
 
-        rc = rcu_lock_remote_target_domain_by_id(a.domid, &d);
+        rc = rcu_lock_remote_domain_by_id(a.domid, &d);
         if ( rc != 0 )
             return rc;
 
@@ -4000,9 +4000,9 @@ long do_hvm_op(unsigned long op, XEN_GUEST_HANDLE(void) arg)
         if ( copy_from_guest(&a, arg, 1) )
             return -EFAULT;
 
-        rc = rcu_lock_target_domain_by_id(a.domid, &d);
-        if ( rc != 0 )
-            return rc;
+        d = rcu_lock_domain_by_any_id(a.domid);
+        if ( d == NULL )
+            return -ESRCH;
 
         rc = xsm_hvm_param(d, op);
         if ( rc )
@@ -4047,7 +4047,7 @@ long do_hvm_op(unsigned long op, XEN_GUEST_HANDLE(void) arg)
         if ( copy_from_guest(&a, arg, 1) )
             return -EFAULT;
 
-        rc = rcu_lock_remote_target_domain_by_id(a.domid, &d);
+        rc = rcu_lock_remote_domain_by_id(a.domid, &d);
         if ( rc != 0 )
             return rc;
 
@@ -4126,7 +4126,7 @@ long do_hvm_op(unsigned long op, XEN_GUEST_HANDLE(void) arg)
         if ( copy_from_guest(&a, arg, 1) )
             return -EFAULT;
 
-        rc = rcu_lock_remote_target_domain_by_id(a.domid, &d);
+        rc = rcu_lock_remote_domain_by_id(a.domid, &d);
         if ( rc != 0 )
             return rc;
 
@@ -4161,7 +4161,7 @@ long do_hvm_op(unsigned long op, XEN_GUEST_HANDLE(void) arg)
         if ( copy_from_guest(&a, arg, 1) )
             return -EFAULT;
 
-        rc = rcu_lock_remote_target_domain_by_id(a.domid, &d);
+        rc = rcu_lock_remote_domain_by_id(a.domid, &d);
         if ( rc != 0 )
             return rc;
 
@@ -4197,9 +4197,9 @@ long do_hvm_op(unsigned long op, XEN_GUEST_HANDLE(void) arg)
         if ( copy_from_guest(&a, arg, 1) )
             return -EFAULT;
 
-        rc = rcu_lock_target_domain_by_id(a.domid, &d);
-        if ( rc != 0 )
-            return rc;
+        d = rcu_lock_domain_by_any_id(a.domid);
+        if ( d == NULL )
+            return -ESRCH;
 
         rc = -EINVAL;
         if ( !is_hvm_domain(d) || !paging_mode_shadow(d) )
@@ -4251,7 +4251,7 @@ long do_hvm_op(unsigned long op, XEN_GUEST_HANDLE(void) arg)
         if ( copy_from_guest(&tr, arg, 1 ) )
             return -EFAULT;
 
-        rc = rcu_lock_remote_target_domain_by_id(tr.domid, &d);
+        rc = rcu_lock_remote_domain_by_id(tr.domid, &d);
         if ( rc != 0 )
             return rc;
 
diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
index b370300..5c6ea2d 100644
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -4371,9 +4371,9 @@ long arch_memory_op(int op, XEN_GUEST_HANDLE(void) arg)
         if ( copy_from_guest(&xatp, arg, 1) )
             return -EFAULT;
 
-        rc = rcu_lock_target_domain_by_id(xatp.domid, &d);
-        if ( rc != 0 )
-            return rc;
+        d = rcu_lock_domain_by_any_id(xatp.domid);
+        if ( d == NULL )
+            return -ESRCH;
 
         if ( xsm_add_to_physmap(current->domain, d) )
         {
@@ -4410,9 +4410,9 @@ long arch_memory_op(int op, XEN_GUEST_HANDLE(void) arg)
         if ( fmap.map.nr_entries > E820MAX )
             return -EINVAL;
 
-        rc = rcu_lock_target_domain_by_id(fmap.domid, &d);
-        if ( rc != 0 )
-            return rc;
+        d = rcu_lock_domain_by_any_id(fmap.domid);
+        if ( d == NULL )
+            return -ESRCH;
 
         rc = xsm_domain_memory_map(d);
         if ( rc )
@@ -4563,16 +4563,12 @@ long arch_memory_op(int op, XEN_GUEST_HANDLE(void) arg)
         struct domain *d;
         struct p2m_domain *p2m;
 
-        /* Support DOMID_SELF? */
-        if ( !IS_PRIV(current->domain) )
-            return -EPERM;
-
         if ( copy_from_guest(&target, arg, 1) )
             return -EFAULT;
 
-        rc = rcu_lock_target_domain_by_id(target.domid, &d);
-        if ( rc != 0 )
-            return rc;
+        d = rcu_lock_domain_by_any_id(target.domid);
+        if ( d == NULL )
+            return -ESRCH;
 
         if ( op == XENMEM_set_pod_target )
             rc = xsm_set_pod_target(d);
diff --git a/xen/common/event_channel.c b/xen/common/event_channel.c
index 53777f8..70becdd 100644
--- a/xen/common/event_channel.c
+++ b/xen/common/event_channel.c
@@ -165,9 +165,9 @@ static long evtchn_alloc_unbound(evtchn_alloc_unbound_t *alloc)
     domid_t        dom = alloc->dom;
     long           rc;
 
-    rc = rcu_lock_target_domain_by_id(dom, &d);
-    if ( rc )
-        return rc;
+    d = rcu_lock_domain_by_any_id(dom);
+    if ( d == NULL )
+        return -ESRCH;
 
     spin_lock(&d->event_lock);
 
@@ -798,9 +798,9 @@ static long evtchn_status(evtchn_status_t *status)
     struct evtchn   *chn;
     long             rc = 0;
 
-    rc = rcu_lock_target_domain_by_id(dom, &d);
-    if ( rc )
-        return rc;
+    d = rcu_lock_domain_by_any_id(dom);
+    if ( d == NULL )
+        return -ESRCH;
 
     spin_lock(&d->event_lock);
 
@@ -950,9 +950,9 @@ static long evtchn_reset(evtchn_reset_t *r)
     struct domain *d;
     int i, rc;
 
-    rc = rcu_lock_target_domain_by_id(dom, &d);
-    if ( rc )
-        return rc;
+    d = rcu_lock_domain_by_any_id(dom);
+    if ( d == NULL )
+        return -ESRCH;
 
     rc = xsm_evtchn_reset(current->domain, d);
     if ( rc )
diff --git a/xen/common/grant_table.c b/xen/common/grant_table.c
index c23c053..10a34d6 100644
--- a/xen/common/grant_table.c
+++ b/xen/common/grant_table.c
@@ -230,30 +230,6 @@ double_gt_unlock(struct grant_table *lgt, struct grant_table *rgt)
         spin_unlock(&rgt->lock);
 }
 
-static struct domain *gt_lock_target_domain_by_id(domid_t dom)
-{
-    struct domain *d;
-    int rc = GNTST_general_error;
-
-    switch ( rcu_lock_target_domain_by_id(dom, &d) )
-    {
-    case 0:
-        return d;
-
-    case -ESRCH:
-        gdprintk(XENLOG_INFO, "Bad domid %d.\n", dom);
-        rc = GNTST_bad_domain;
-        break;
-
-    case -EPERM:
-        rc = GNTST_permission_denied;
-        break;
-    }
-
-    ASSERT(rc < 0 && -rc <= MAX_ERRNO);
-    return ERR_PTR(rc);
-}
-
 static inline int
 __get_maptrack_handle(
     struct grant_table *t)
@@ -1339,11 +1315,12 @@ gnttab_setup_table(
         goto out1;
     }
 
-    d = gt_lock_target_domain_by_id(op.dom);
-    if ( IS_ERR(d) )
+    d = rcu_lock_domain_by_any_id(op.dom);
+    if ( d == NULL )
     {
-        op.status = PTR_ERR(d);
-        goto out1;
+        gdprintk(XENLOG_INFO, "Bad domid %d.\n", op.dom);
+        op.status = GNTST_bad_domain;
+        goto out2;
     }
 
     if ( xsm_grant_setup(current->domain, d) )
@@ -1407,10 +1384,11 @@ gnttab_query_size(
         return -EFAULT;
     }
 
-    d = gt_lock_target_domain_by_id(op.dom);
-    if ( IS_ERR(d) )
+    d = rcu_lock_domain_by_any_id(op.dom);
+    if ( d == NULL )
     {
-        op.status = PTR_ERR(d);
+        gdprintk(XENLOG_INFO, "Bad domid %d.\n", op.dom);
+        op.status = GNTST_bad_domain;
         goto query_out;
     }
 
@@ -2280,10 +2258,10 @@ gnttab_get_status_frames(XEN_GUEST_HANDLE(gnttab_get_status_frames_t) uop,
         return -EFAULT;
     }
 
-    d = gt_lock_target_domain_by_id(op.dom);
-    if ( IS_ERR(d) )
+    d = rcu_lock_domain_by_any_id(op.dom);
+    if ( d == NULL )
     {
-        op.status = PTR_ERR(d);
+        op.status = GNTST_bad_domain;
         goto out1;
     }
     rc = xsm_grant_setup(current->domain, d);
@@ -2333,14 +2311,15 @@ gnttab_get_version(XEN_GUEST_HANDLE(gnttab_get_version_t uop))
     if ( copy_from_guest(&op, uop, 1) )
         return -EFAULT;
 
-    rc = rcu_lock_target_domain_by_id(op.dom, &d);
-    if ( rc < 0 )
-        return rc;
+    d = rcu_lock_domain_by_any_id(op.dom);
+    if ( d == NULL )
+        return -ESRCH;
 
-    if ( xsm_grant_query_size(current->domain, d) )
+    rc = xsm_grant_query_size(current->domain, d);
+    if ( rc )
     {
         rcu_unlock_domain(d);
-        return -EPERM;
+        return rc;
     }
 
     op.version = d->grant_table->gt_version;
diff --git a/xen/common/memory.c b/xen/common/memory.c
index 5bcb035..a984d51 100644
--- a/xen/common/memory.c
+++ b/xen/common/memory.c
@@ -570,7 +570,8 @@ long do_memory_op(unsigned long cmd, XEN_GUEST_HANDLE(void) arg)
              && (reservation.mem_flags & XENMEMF_populate_on_demand) )
             args.memflags |= MEMF_populate_on_demand;
 
-        if ( unlikely(rcu_lock_target_domain_by_id(reservation.domid, &d)) )
+        d = rcu_lock_domain_by_any_id(reservation.domid);
+        if ( d == NULL )
             return start_extent;
         args.domain = d;
 
@@ -619,9 +620,9 @@ long do_memory_op(unsigned long cmd, XEN_GUEST_HANDLE(void) arg)
         if ( copy_from_guest(&domid, arg, 1) )
             return -EFAULT;
 
-        rc = rcu_lock_target_domain_by_id(domid, &d);
-        if ( rc )
-            return rc;
+        d = rcu_lock_domain_by_any_id(domid);
+        if ( d == NULL )
+            return -ESRCH;
 
         rc = xsm_memory_stat_reservation(current->domain, d);
         if ( rc )
@@ -657,9 +658,9 @@ long do_memory_op(unsigned long cmd, XEN_GUEST_HANDLE(void) arg)
         if ( copy_from_guest(&xrfp, arg, 1) )
             return -EFAULT;
 
-        rc = rcu_lock_target_domain_by_id(xrfp.domid, &d);
-        if ( rc != 0 )
-            return rc;
+        d = rcu_lock_domain_by_any_id(xrfp.domid);
+        if ( d == NULL )
+            return -ESRCH;
 
         if ( xsm_remove_from_physmap(current->domain, d) )
         {
diff --git a/xen/include/xsm/dummy.h b/xen/include/xsm/dummy.h
index 7cb229d..448b5c1 100644
--- a/xen/include/xsm/dummy.h
+++ b/xen/include/xsm/dummy.h
@@ -194,6 +194,8 @@ static XSM_DEFAULT(int, grant_unmapref) (struct domain *d1, struct domain *d2)
 
 static XSM_DEFAULT(int, grant_setup) (struct domain *d1, struct domain *d2)
 {
+    if ( d1 != d2 && !IS_PRIV_FOR(d1, d2) )
+        return -EPERM;
     return 0;
 }
 
@@ -209,17 +211,23 @@ static XSM_DEFAULT(int, grant_copy) (struct domain *d1, struct domain *d2)
 
 static XSM_DEFAULT(int, grant_query_size) (struct domain *d1, struct domain *d2)
 {
+    if ( d1 != d2 && !IS_PRIV_FOR(d1, d2) )
+        return -EPERM;
     return 0;
 }
 
 static XSM_DEFAULT(int, memory_adjust_reservation) (struct domain *d1,
                                                             struct domain *d2)
 {
+    if ( d1 != d2 && !IS_PRIV_FOR(d1, d2) )
+        return -EPERM;
     return 0;
 }
 
 static XSM_DEFAULT(int, memory_stat_reservation) (struct domain *d1, struct domain *d2)
 {
+    if ( d1 != d2 && !IS_PRIV_FOR(d1, d2) )
+        return -EPERM;
     return 0;
 }
 
@@ -260,6 +268,8 @@ static XSM_DEFAULT(int, memory_pin_page) (struct domain *d1, struct domain *d2,
 static XSM_DEFAULT(int, evtchn_unbound) (struct domain *d, struct evtchn *chn,
                                          domid_t id2)
 {
+    if ( current->domain != d && !IS_PRIV_FOR(current->domain, d) )
+        return -EPERM;
     return 0;
 }
 
@@ -281,11 +291,15 @@ static XSM_DEFAULT(int, evtchn_send) (struct domain *d, struct evtchn *chn)
 
 static XSM_DEFAULT(int, evtchn_status) (struct domain *d, struct evtchn *chn)
 {
+    if ( current->domain != d && !IS_PRIV_FOR(current->domain, d) )
+        return -EPERM;
     return 0;
 }
 
 static XSM_DEFAULT(int, evtchn_reset) (struct domain *d1, struct domain *d2)
 {
+    if ( d1 != d2 && !IS_PRIV_FOR(d1, d2) )
+        return -EPERM;
     return 0;
 }
 
@@ -306,11 +320,15 @@ static XSM_DEFAULT(char *, show_security_evtchn) (struct domain *d, const struct
 
 static XSM_DEFAULT(int, get_pod_target)(struct domain *d)
 {
+    if ( !IS_PRIV(current->domain) )
+        return -EPERM;
     return 0;
 }
 
 static XSM_DEFAULT(int, set_pod_target)(struct domain *d)
 {
+    if ( !IS_PRIV(current->domain) )
+        return -EPERM;
     return 0;
 }
 
@@ -481,26 +499,36 @@ static XSM_DEFAULT(int, machine_address_size) (struct domain *d, uint32_t cmd)
 
 static XSM_DEFAULT(int, hvm_param) (struct domain *d, unsigned long op)
 {
+    if ( current->domain != d && !IS_PRIV_FOR(current->domain, d) )
+        return -EPERM;
     return 0;
 }
 
 static XSM_DEFAULT(int, hvm_set_pci_intx_level) (struct domain *d)
 {
+    if ( !IS_PRIV_FOR(current->domain, d) )
+        return -EPERM;
     return 0;
 }
 
 static XSM_DEFAULT(int, hvm_set_isa_irq_level) (struct domain *d)
 {
+    if ( !IS_PRIV_FOR(current->domain, d) )
+        return -EPERM;
     return 0;
 }
 
 static XSM_DEFAULT(int, hvm_set_pci_link_route) (struct domain *d)
 {
+    if ( !IS_PRIV_FOR(current->domain, d) )
+        return -EPERM;
     return 0;
 }
 
 static XSM_DEFAULT(int, hvm_inject_msi) (struct domain *d)
 {
+    if ( !IS_PRIV_FOR(current->domain, d) )
+        return -EPERM;
     return 0;
 }
 
@@ -582,6 +610,8 @@ static XSM_DEFAULT(int, machine_memory_map) (void)
 
 static XSM_DEFAULT(int, domain_memory_map) (struct domain *d)
 {
+    if ( current->domain != d && !IS_PRIV_FOR(current->domain, d) )
+        return -EPERM;
     return 0;
 }
 
@@ -605,11 +635,15 @@ static XSM_DEFAULT(int, update_va_mapping) (struct domain *d, struct domain *f,
 
 static XSM_DEFAULT(int, add_to_physmap) (struct domain *d1, struct domain *d2)
 {
+    if ( d1 != d2 && !IS_PRIV_FOR(d1, d2) )
+        return -EPERM;
     return 0;
 }
 
 static XSM_DEFAULT(int, remove_from_physmap) (struct domain *d1, struct domain *d2)
 {
+    if ( d1 != d2 && !IS_PRIV_FOR(d1, d2) )
+        return -EPERM;
     return 0;
 }
 
-- 
1.7.11.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 17 15:24:22 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 15:24:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDdBC-0003dE-FX; Mon, 17 Sep 2012 15:24:10 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1TDdBA-0003Zt-1X
	for xen-devel@lists.xen.org; Mon, 17 Sep 2012 15:24:08 +0000
Received: from [85.158.139.211:11493] by server-12.bemta-5.messagelabs.com id
	94/6B-19338-79047505; Mon, 17 Sep 2012 15:24:07 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-4.tower-206.messagelabs.com!1347895444!18910985!1
X-Originating-IP: [63.239.67.9]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13652 invoked from network); 17 Sep 2012 15:24:04 -0000
Received: from emvm-gh1-uea08.nsa.gov (HELO nsa.gov) (63.239.67.9)
	by server-4.tower-206.messagelabs.com with SMTP;
	17 Sep 2012 15:24:04 -0000
X-TM-IMSS-Message-ID: <538037010012acd2@nsa.gov>
Received: from tarius.tycho.ncsc.mil ([144.51.3.1]) by nsa.gov ([63.239.67.9])
	with ESMTP (TREND IMSS SMTP Service 7.1) id 538037010012acd2 ;
	Mon, 17 Sep 2012 11:23:44 -0400
Received: from moss-nexus.epoch.ncsc.mil (moss-nexus [144.51.25.48])
	by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id q8HFO0xZ027504; 
	Mon, 17 Sep 2012 11:24:02 -0400
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xen.org
Date: Mon, 17 Sep 2012 11:23:31 -0400
Message-Id: <1347895425-17959-10-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.11.4
In-Reply-To: <1347895425-17959-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1347895425-17959-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: dgdegra@tycho.nsa.gov, keir@xen.org, Jan Beulich <jbeulich@suse.com>
Subject: [Xen-devel] [PATCH 09/23] xsm: Use the dummy XSM module if XSM is
	disabled
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/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 moves the implementation of the dummy XSM module to a header
file that provides inline functions when XSM_ENABLE is not defined. This
reduces duplication between the dummy module and callers when the
implementation of the dummy return is not just "return 0", and also
provides better compile-time checking for completeness of the XSM
implementations in the dummy module.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Cc: Keir Fraser <keir@xen.org>
Cc: Jan Beulich <jbeulich@suse.com>
---
 xen/common/domctl.c     |   2 -
 xen/include/xsm/dummy.h | 628 ++++++++++++++++++++++++++++++++++++++++++++++++
 xen/include/xsm/xsm.h   | 294 +++++++++++------------
 xen/xsm/dummy.c         | 619 +----------------------------------------------
 xen/xsm/flask/hooks.c   |   2 +-
 xen/xsm/xsm_core.c      |   2 +-
 6 files changed, 776 insertions(+), 771 deletions(-)
 create mode 100644 xen/include/xsm/dummy.h

diff --git a/xen/common/domctl.c b/xen/common/domctl.c
index 2b1f182..d99ba67 100644
--- a/xen/common/domctl.c
+++ b/xen/common/domctl.c
@@ -267,10 +267,8 @@ long do_domctl(XEN_GUEST_HANDLE(xen_domctl_t) u_domctl)
             return -EPERM;
         break;
     }
-#ifdef XSM_ENABLE
     case XEN_DOMCTL_getdomaininfo:
         break;
-#endif
     default:
         if ( !IS_PRIV(current->domain) )
             return -EPERM;
diff --git a/xen/include/xsm/dummy.h b/xen/include/xsm/dummy.h
new file mode 100644
index 0000000..0456bc8
--- /dev/null
+++ b/xen/include/xsm/dummy.h
@@ -0,0 +1,628 @@
+/*
+ *  Default XSM hooks - IS_PRIV and IS_PRIV_FOR checks
+ *
+ *  Author: Daniel De Graaf <dgdegra@tyhco.nsa.gov>
+ *
+ *  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.
+ */
+
+#include <xen/sched.h>
+#include <xsm/xsm.h>
+
+static XSM_DEFAULT(void, security_domaininfo)(struct domain *d,
+                                    struct xen_domctl_getdomaininfo *info)
+{
+    return;
+}
+
+static XSM_DEFAULT(int, setvcpucontext)(struct domain *d)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, pausedomain) (struct domain *d)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, unpausedomain) (struct domain *d)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, resumedomain) (struct domain *d)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, domain_create)(struct domain *d, u32 ssidref)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, max_vcpus)(struct domain *d)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, destroydomain) (struct domain *d)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, vcpuaffinity) (int cmd, struct domain *d)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, scheduler) (struct domain *d)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, getdomaininfo) (struct domain *d)
+{
+    if ( !IS_PRIV(current->domain) )
+        return -EPERM;
+    return 0;
+}
+
+static XSM_DEFAULT(int, getvcpucontext) (struct domain *d)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, getvcpuinfo) (struct domain *d)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, domain_settime) (struct domain *d)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, set_target) (struct domain *d, struct domain *e)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, domctl)(struct domain *d, int cmd)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, set_virq_handler)(struct domain *d, uint32_t virq)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, tbufcontrol) (void)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, readconsole) (uint32_t clear)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, sched_id) (void)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, setdomainmaxmem) (struct domain *d)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, setdomainhandle) (struct domain *d)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, setdebugging) (struct domain *d)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, perfcontrol) (void)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, debug_keys) (void)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, getcpuinfo) (void)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, get_pmstat) (void)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, setpminfo) (void)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, pm_op) (void)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, do_mca) (void)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, availheap) (void)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, alloc_security_domain) (struct domain *d)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(void, free_security_domain) (struct domain *d)
+{
+    return;
+}
+
+static XSM_DEFAULT(int, grant_mapref) (struct domain *d1, struct domain *d2,
+                                                                uint32_t flags)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, grant_unmapref) (struct domain *d1, struct domain *d2)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, grant_setup) (struct domain *d1, struct domain *d2)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, grant_transfer) (struct domain *d1, struct domain *d2)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, grant_copy) (struct domain *d1, struct domain *d2)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, grant_query_size) (struct domain *d1, struct domain *d2)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, memory_adjust_reservation) (struct domain *d1,
+                                                            struct domain *d2)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, memory_stat_reservation) (struct domain *d1, struct domain *d2)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, console_io) (struct domain *d, int cmd)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, profile) (struct domain *d, int op)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, kexec) (void)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, schedop_shutdown) (struct domain *d1, struct domain *d2)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, memory_pin_page) (struct domain *d1, struct domain *d2,
+                                          struct page_info *page)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, evtchn_unbound) (struct domain *d, struct evtchn *chn,
+                                         domid_t id2)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, evtchn_interdomain) (struct domain *d1, struct evtchn
+                                *chan1, struct domain *d2, struct evtchn *chan2)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(void, evtchn_close_post) (struct evtchn *chn)
+{
+    return;
+}
+
+static XSM_DEFAULT(int, evtchn_send) (struct domain *d, struct evtchn *chn)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, evtchn_status) (struct domain *d, struct evtchn *chn)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, evtchn_reset) (struct domain *d1, struct domain *d2)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, alloc_security_evtchn) (struct evtchn *chn)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(void, free_security_evtchn) (struct evtchn *chn)
+{
+    return;
+}
+
+static XSM_DEFAULT(char *, show_security_evtchn) (struct domain *d, const struct evtchn *chn)
+{
+    return NULL;
+}
+
+static XSM_DEFAULT(int, get_pod_target)(struct domain *d)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, set_pod_target)(struct domain *d)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, get_device_group) (uint32_t machine_bdf)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, test_assign_device) (uint32_t machine_bdf)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, assign_device) (struct domain *d, uint32_t machine_bdf)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, deassign_device) (struct domain *d, uint32_t machine_bdf)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, resource_plug_core) (void)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, resource_unplug_core) (void)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, resource_plug_pci) (uint32_t machine_bdf)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, resource_unplug_pci) (uint32_t machine_bdf)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, resource_setup_pci) (uint32_t machine_bdf)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, resource_setup_gsi) (int gsi)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, resource_setup_misc) (void)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, page_offline) (uint32_t cmd)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, lockprof) (void)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, cpupool_op) (void)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, sched_op) (void)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(long, do_xsm_op)(XEN_GUEST_HANDLE(xsm_op_t) op)
+{
+    return -ENOSYS;
+}
+
+static XSM_DEFAULT(char *, show_irq_sid) (int irq)
+{
+    return NULL;
+}
+
+static XSM_DEFAULT(int, map_domain_pirq) (struct domain *d, int irq, void *data)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, unmap_domain_pirq) (struct domain *d, int irq)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, irq_permission) (struct domain *d, int pirq, uint8_t allow)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, iomem_permission) (struct domain *d, uint64_t s, uint64_t e, uint8_t allow)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, iomem_mapping) (struct domain *d, uint64_t s, uint64_t e, uint8_t allow)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, pci_config_permission) (struct domain *d, uint32_t machine_bdf,
+                                        uint16_t start, uint16_t end,
+                                        uint8_t access)
+{
+    return 0;
+}
+
+#ifdef CONFIG_X86
+static XSM_DEFAULT(int, shadow_control) (struct domain *d, uint32_t op)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, getpageframeinfo) (struct domain *d)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, getmemlist) (struct domain *d)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, hypercall_init) (struct domain *d)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, hvmcontext) (struct domain *d, uint32_t cmd)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, address_size) (struct domain *d, uint32_t cmd)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, machine_address_size) (struct domain *d, uint32_t cmd)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, hvm_param) (struct domain *d, unsigned long op)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, hvm_set_pci_intx_level) (struct domain *d)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, hvm_set_isa_irq_level) (struct domain *d)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, hvm_set_pci_link_route) (struct domain *d)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, hvm_inject_msi) (struct domain *d)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, mem_event) (struct domain *d)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, mem_sharing) (struct domain *d)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, apic) (struct domain *d, int cmd)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, xen_settime) (void)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, memtype) (uint32_t access)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, microcode) (void)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, physinfo) (void)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, platform_quirk) (uint32_t quirk)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, firmware_info) (void)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, efi_call) (void)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, acpi_sleep) (void)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, change_freq) (void)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, getidletime) (void)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, machine_memory_map) (void)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, domain_memory_map) (struct domain *d)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, mmu_normal_update) (struct domain *d, struct domain *t,
+                                            struct domain *f, intpte_t fpte)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, mmu_machphys_update) (struct domain *d, struct domain *f,
+                                              unsigned long mfn)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, update_va_mapping) (struct domain *d, struct domain *f, 
+                                                            l1_pgentry_t pte)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, add_to_physmap) (struct domain *d1, struct domain *d2)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, remove_from_physmap) (struct domain *d1, struct domain *d2)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, sendtrigger) (struct domain *d)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, bind_pt_irq) (struct domain *d, struct xen_domctl_bind_pt_irq *bind)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, unbind_pt_irq) (struct domain *d, struct xen_domctl_bind_pt_irq *bind)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, pin_mem_cacheattr) (struct domain *d)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, ext_vcpucontext) (struct domain *d, uint32_t cmd)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, vcpuextstate) (struct domain *d, uint32_t cmd)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, ioport_permission) (struct domain *d, uint32_t s, uint32_t e, uint8_t allow)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, ioport_mapping) (struct domain *d, uint32_t s, uint32_t e, uint8_t allow)
+{
+    return 0;
+}
+
+#endif
diff --git a/xen/include/xsm/xsm.h b/xen/include/xsm/xsm.h
index cbbe673..1a63c27 100644
--- a/xen/include/xsm/xsm.h
+++ b/xen/include/xsm/xsm.h
@@ -21,12 +21,6 @@
 typedef void xsm_op_t;
 DEFINE_XEN_GUEST_HANDLE(xsm_op_t);
 
-#ifdef XSM_ENABLE
-    #define xsm_call(fn) xsm_ops->fn
-#else
-    #define xsm_call(fn) 0
-#endif
-
 /* policy magic number (defined by XSM_MAGIC) */
 typedef u32 xsm_magic_t;
 #ifndef XSM_MAGIC
@@ -141,7 +135,7 @@ struct xsm_operations {
     int (*cpupool_op)(void);
     int (*sched_op)(void);
 
-    long (*__do_xsm_op) (XEN_GUEST_HANDLE(xsm_op_t) op);
+    long (*do_xsm_op) (XEN_GUEST_HANDLE(xsm_op_t) op);
 
 #ifdef CONFIG_X86
     int (*shadow_control) (struct domain *d, uint32_t op);
@@ -187,645 +181,643 @@ struct xsm_operations {
 #endif
 };
 
-#endif
-
 extern struct xsm_operations *xsm_ops;
 
 static inline void xsm_security_domaininfo (struct domain *d,
                                         struct xen_domctl_getdomaininfo *info)
 {
-    (void)xsm_call(security_domaininfo(d, info));
+    xsm_ops->security_domaininfo(d, info);
 }
 
 static inline int xsm_setvcpucontext(struct domain *d)
 {
-    return xsm_call(setvcpucontext(d));
+    return xsm_ops->setvcpucontext(d);
 }
 
 static inline int xsm_pausedomain (struct domain *d)
 {
-    return xsm_call(pausedomain(d));
+    return xsm_ops->pausedomain(d);
 }
 
 static inline int xsm_unpausedomain (struct domain *d)
 {
-    return xsm_call(unpausedomain(d));
+    return xsm_ops->unpausedomain(d);
 }
 
 static inline int xsm_resumedomain (struct domain *d)
 {
-    return xsm_call(resumedomain(d));
+    return xsm_ops->resumedomain(d);
 }
 
 static inline int xsm_domain_create (struct domain *d, u32 ssidref)
 {
-    return xsm_call(domain_create(d, ssidref));
+    return xsm_ops->domain_create(d, ssidref);
 }
 
 static inline int xsm_max_vcpus(struct domain *d)
 {
-    return xsm_call(max_vcpus(d));
+    return xsm_ops->max_vcpus(d);
 }
 
 static inline int xsm_destroydomain (struct domain *d)
 {
-    return xsm_call(destroydomain(d));
+    return xsm_ops->destroydomain(d);
 }
 
 static inline int xsm_vcpuaffinity (int cmd, struct domain *d)
 {
-    return xsm_call(vcpuaffinity(cmd, d));
+    return xsm_ops->vcpuaffinity(cmd, d);
 }
 
 static inline int xsm_scheduler (struct domain *d)
 {
-    return xsm_call(scheduler(d));
+    return xsm_ops->scheduler(d);
 }
 
 static inline int xsm_getdomaininfo (struct domain *d)
 {
-    return xsm_call(getdomaininfo(d));
+    return xsm_ops->getdomaininfo(d);
 }
 
 static inline int xsm_getvcpucontext (struct domain *d)
 {
-    return xsm_call(getvcpucontext(d));
+    return xsm_ops->getvcpucontext(d);
 }
 
 static inline int xsm_getvcpuinfo (struct domain *d)
 {
-    return xsm_call(getvcpuinfo(d));
+    return xsm_ops->getvcpuinfo(d);
 }
 
 static inline int xsm_domain_settime (struct domain *d)
 {
-    return xsm_call(domain_settime(d));
+    return xsm_ops->domain_settime(d);
 }
 
 static inline int xsm_set_target (struct domain *d, struct domain *e)
 {
-    return xsm_call(set_target(d, e));
+    return xsm_ops->set_target(d, e);
 }
 
 static inline int xsm_domctl (struct domain *d, int cmd)
 {
-    return xsm_call(domctl(d, cmd));
+    return xsm_ops->domctl(d, cmd);
 }
 
 static inline int xsm_set_virq_handler (struct domain *d, uint32_t virq)
 {
-    return xsm_call(set_virq_handler(d, virq));
+    return xsm_ops->set_virq_handler(d, virq);
 }
 
 static inline int xsm_tbufcontrol (void)
 {
-    return xsm_call(tbufcontrol());
+    return xsm_ops->tbufcontrol();
 }
 
 static inline int xsm_readconsole (uint32_t clear)
 {
-    return xsm_call(readconsole(clear));
+    return xsm_ops->readconsole(clear);
 }
 
 static inline int xsm_sched_id (void)
 {
-    return xsm_call(sched_id());
+    return xsm_ops->sched_id();
 }
 
 static inline int xsm_setdomainmaxmem (struct domain *d)
 {
-    return xsm_call(setdomainmaxmem(d));
+    return xsm_ops->setdomainmaxmem(d);
 }
 
 static inline int xsm_setdomainhandle (struct domain *d)
 {
-    return xsm_call(setdomainhandle(d));
+    return xsm_ops->setdomainhandle(d);
 }
 
 static inline int xsm_setdebugging (struct domain *d)
 {
-    return xsm_call(setdebugging(d));
+    return xsm_ops->setdebugging(d);
 }
 
 static inline int xsm_perfcontrol (void)
 {
-    return xsm_call(perfcontrol());
+    return xsm_ops->perfcontrol();
 }
 
 static inline int xsm_debug_keys (void)
 {
-    return xsm_call(debug_keys());
+    return xsm_ops->debug_keys();
 }
 
 static inline int xsm_availheap (void)
 {
-    return xsm_call(availheap());
+    return xsm_ops->availheap();
 }
 
 static inline int xsm_getcpuinfo (void)
 {
-    return xsm_call(getcpuinfo());
+    return xsm_ops->getcpuinfo();
 }
 
 static inline int xsm_get_pmstat(void)
 {
-    return xsm_call(get_pmstat());
+    return xsm_ops->get_pmstat();
 }
 
 static inline int xsm_setpminfo(void)
 {
-	return xsm_call(setpminfo());
+    return xsm_ops->setpminfo();
 }
 
 static inline int xsm_pm_op(void)
 {
-    return xsm_call(pm_op());
+    return xsm_ops->pm_op();
 }
 
 static inline int xsm_do_mca(void)
 {
-    return xsm_call(do_mca());
+    return xsm_ops->do_mca();
 }
 
 static inline int xsm_evtchn_unbound (struct domain *d1, struct evtchn *chn,
                                                                     domid_t id2)
 {
-    return xsm_call(evtchn_unbound(d1, chn, id2));
+    return xsm_ops->evtchn_unbound(d1, chn, id2);
 }
 
 static inline int xsm_evtchn_interdomain (struct domain *d1, 
                 struct evtchn *chan1, struct domain *d2, struct evtchn *chan2)
 {
-    return xsm_call(evtchn_interdomain(d1, chan1, d2, chan2));
+    return xsm_ops->evtchn_interdomain(d1, chan1, d2, chan2);
 }
 
 static inline void xsm_evtchn_close_post (struct evtchn *chn)
 {
-    (void)xsm_call(evtchn_close_post(chn));
+    xsm_ops->evtchn_close_post(chn);
 }
 
 static inline int xsm_evtchn_send (struct domain *d, struct evtchn *chn)
 {
-    return xsm_call(evtchn_send(d, chn));
+    return xsm_ops->evtchn_send(d, chn);
 }
 
 static inline int xsm_evtchn_status (struct domain *d, struct evtchn *chn)
 {
-    return xsm_call(evtchn_status(d, chn));
+    return xsm_ops->evtchn_status(d, chn);
 }
 
 static inline int xsm_evtchn_reset (struct domain *d1, struct domain *d2)
 {
-    return xsm_call(evtchn_reset(d1, d2));
+    return xsm_ops->evtchn_reset(d1, d2);
 }
 
 static inline int xsm_grant_mapref (struct domain *d1, struct domain *d2,
                                                                 uint32_t flags)
 {
-    return xsm_call(grant_mapref(d1, d2, flags));
+    return xsm_ops->grant_mapref(d1, d2, flags);
 }
 
 static inline int xsm_grant_unmapref (struct domain *d1, struct domain *d2)
 {
-    return xsm_call(grant_unmapref(d1, d2));
+    return xsm_ops->grant_unmapref(d1, d2);
 }
 
 static inline int xsm_grant_setup (struct domain *d1, struct domain *d2)
 {
-    return xsm_call(grant_setup(d1, d2));
+    return xsm_ops->grant_setup(d1, d2);
 }
 
 static inline int xsm_grant_transfer (struct domain *d1, struct domain *d2)
 {
-    return xsm_call(grant_transfer(d1, d2));
+    return xsm_ops->grant_transfer(d1, d2);
 }
 
 static inline int xsm_grant_copy (struct domain *d1, struct domain *d2)
 {
-    return xsm_call(grant_copy(d1, d2));
+    return xsm_ops->grant_copy(d1, d2);
 }
 
 static inline int xsm_grant_query_size (struct domain *d1, struct domain *d2)
 {
-    return xsm_call(grant_query_size(d1, d2));
+    return xsm_ops->grant_query_size(d1, d2);
 }
 
 static inline int xsm_alloc_security_domain (struct domain *d)
 {
-    return xsm_call(alloc_security_domain(d));
+    return xsm_ops->alloc_security_domain(d);
 }
 
 static inline void xsm_free_security_domain (struct domain *d)
 {
-    (void)xsm_call(free_security_domain(d));
+    xsm_ops->free_security_domain(d);
 }
 
 static inline int xsm_alloc_security_evtchn (struct evtchn *chn)
 {
-    return xsm_call(alloc_security_evtchn(chn));
+    return xsm_ops->alloc_security_evtchn(chn);
 }
 
 static inline void xsm_free_security_evtchn (struct evtchn *chn)
 {
-    (void)xsm_call(free_security_evtchn(chn));
+    (void)xsm_ops->free_security_evtchn(chn);
 }
 
 static inline char *xsm_show_security_evtchn (struct domain *d, const struct evtchn *chn)
 {
-    return xsm_call(show_security_evtchn(d, chn));
+    return xsm_ops->show_security_evtchn(d, chn);
 }
 
 static inline int xsm_get_pod_target (struct domain *d)
 {
-    return xsm_call(get_pod_target(d));
+    return xsm_ops->get_pod_target(d);
 }
 
 static inline int xsm_set_pod_target (struct domain *d)
 {
-    return xsm_call(set_pod_target(d));
+    return xsm_ops->set_pod_target(d);
 }
 
 static inline int xsm_memory_adjust_reservation (struct domain *d1, struct
                                                                     domain *d2)
 {
-    return xsm_call(memory_adjust_reservation(d1, d2));
+    return xsm_ops->memory_adjust_reservation(d1, d2);
 }
 
 static inline int xsm_memory_stat_reservation (struct domain *d1,
                                                             struct domain *d2)
 {
-    return xsm_call(memory_stat_reservation(d1, d2));
+    return xsm_ops->memory_stat_reservation(d1, d2);
 }
 
 static inline int xsm_memory_pin_page(struct domain *d1, struct domain *d2,
                                       struct page_info *page)
 {
-    return xsm_call(memory_pin_page(d1, d2, page));
+    return xsm_ops->memory_pin_page(d1, d2, page);
 }
 
 static inline int xsm_remove_from_physmap(struct domain *d1, struct domain *d2)
 {
-    return xsm_call(remove_from_physmap(d1, d2));
+    return xsm_ops->remove_from_physmap(d1, d2);
 }
 
 static inline int xsm_console_io (struct domain *d, int cmd)
 {
-    return xsm_call(console_io(d, cmd));
+    return xsm_ops->console_io(d, cmd);
 }
 
 static inline int xsm_profile (struct domain *d, int op)
 {
-    return xsm_call(profile(d, op));
+    return xsm_ops->profile(d, op);
 }
 
 static inline int xsm_kexec (void)
 {
-    return xsm_call(kexec());
+    return xsm_ops->kexec();
 }
 
 static inline int xsm_schedop_shutdown (struct domain *d1, struct domain *d2)
 {
-    return xsm_call(schedop_shutdown(d1, d2));
+    return xsm_ops->schedop_shutdown(d1, d2);
 }
 
 static inline char *xsm_show_irq_sid (int irq)
 {
-    return xsm_call(show_irq_sid(irq));
+    return xsm_ops->show_irq_sid(irq);
 }
 
 static inline int xsm_map_domain_pirq (struct domain *d, int irq, void *data)
 {
-    return xsm_call(map_domain_pirq(d, irq, data));
+    return xsm_ops->map_domain_pirq(d, irq, data);
 }
 
 static inline int xsm_unmap_domain_pirq (struct domain *d, int irq)
 {
-    return xsm_call(unmap_domain_pirq(d, irq));
+    return xsm_ops->unmap_domain_pirq(d, irq);
 }
 
 static inline int xsm_irq_permission (struct domain *d, int pirq, uint8_t allow)
 {
-    return xsm_call(irq_permission(d, pirq, allow));
+    return xsm_ops->irq_permission(d, pirq, allow);
 }
 
 static inline int xsm_iomem_permission (struct domain *d, uint64_t s, uint64_t e, uint8_t allow)
 {
-    return xsm_call(iomem_permission(d, s, e, allow));
+    return xsm_ops->iomem_permission(d, s, e, allow);
 }
 
 static inline int xsm_iomem_mapping (struct domain *d, uint64_t s, uint64_t e, uint8_t allow)
 {
-    return xsm_call(iomem_mapping(d, s, e, allow));
+    return xsm_ops->iomem_mapping(d, s, e, allow);
 }
 
 static inline int xsm_pci_config_permission (struct domain *d, uint32_t machine_bdf, uint16_t start, uint16_t end, uint8_t access)
 {
-    return xsm_call(pci_config_permission(d, machine_bdf, start, end, access));
+    return xsm_ops->pci_config_permission(d, machine_bdf, start, end, access);
 }
 
 static inline int xsm_get_device_group(uint32_t machine_bdf)
 {
-    return xsm_call(get_device_group(machine_bdf));
+    return xsm_ops->get_device_group(machine_bdf);
 }
 
 static inline int xsm_test_assign_device(uint32_t machine_bdf)
 {
-    return xsm_call(test_assign_device(machine_bdf));
+    return xsm_ops->test_assign_device(machine_bdf);
 }
 
 static inline int xsm_assign_device(struct domain *d, uint32_t machine_bdf)
 {
-    return xsm_call(assign_device(d, machine_bdf));
+    return xsm_ops->assign_device(d, machine_bdf);
 }
 
 static inline int xsm_deassign_device(struct domain *d, uint32_t machine_bdf)
 {
-    return xsm_call(deassign_device(d, machine_bdf));
+    return xsm_ops->deassign_device(d, machine_bdf);
 }
 
 static inline int xsm_resource_plug_pci (uint32_t machine_bdf)
 {
-    return xsm_call(resource_plug_pci(machine_bdf));
+    return xsm_ops->resource_plug_pci(machine_bdf);
 }
 
 static inline int xsm_resource_unplug_pci (uint32_t machine_bdf)
 {
-    return xsm_call(resource_unplug_pci(machine_bdf));
+    return xsm_ops->resource_unplug_pci(machine_bdf);
 }
 
 static inline int xsm_resource_plug_core (void)
 {
-    return xsm_call(resource_plug_core());
+    return xsm_ops->resource_plug_core();
 }
 
 static inline int xsm_resource_unplug_core (void)
 {
-    return xsm_call(resource_unplug_core());
+    return xsm_ops->resource_unplug_core();
 }
 
 static inline int xsm_resource_setup_pci (uint32_t machine_bdf)
 {
-    return xsm_call(resource_setup_pci(machine_bdf));
+    return xsm_ops->resource_setup_pci(machine_bdf);
 }
 
 static inline int xsm_resource_setup_gsi (int gsi)
 {
-    return xsm_call(resource_setup_gsi(gsi));
+    return xsm_ops->resource_setup_gsi(gsi);
 }
 
 static inline int xsm_resource_setup_misc (void)
 {
-    return xsm_call(resource_setup_misc());
+    return xsm_ops->resource_setup_misc();
 }
 
 static inline int xsm_page_offline(uint32_t cmd)
 {
-    return xsm_call(page_offline(cmd));
+    return xsm_ops->page_offline(cmd);
 }
 
 static inline int xsm_lockprof(void)
 {
-    return xsm_call(lockprof());
+    return xsm_ops->lockprof();
 }
 
 static inline int xsm_cpupool_op(void)
 {
-    return xsm_call(cpupool_op());
+    return xsm_ops->cpupool_op();
 }
 
 static inline int xsm_sched_op(void)
 {
-    return xsm_call(sched_op());
-}
-
-static inline long __do_xsm_op (XEN_GUEST_HANDLE(xsm_op_t) op)
-{
-#ifdef XSM_ENABLE
-    return xsm_ops->__do_xsm_op(op);
-#else
-    return -ENOSYS;
-#endif
+    return xsm_ops->sched_op();
 }
 
-#ifdef XSM_ENABLE
-extern int xsm_init(unsigned long *module_map, const multiboot_info_t *mbi,
-                    void *(*bootstrap_map)(const module_t *));
-extern int xsm_policy_init(unsigned long *module_map,
-                           const multiboot_info_t *mbi,
-                           void *(*bootstrap_map)(const module_t *));
-extern int register_xsm(struct xsm_operations *ops);
-extern int unregister_xsm(struct xsm_operations *ops);
-#else
-static inline int xsm_init (unsigned long *module_map,
-                            const multiboot_info_t *mbi,
-                            void *(*bootstrap_map)(const module_t *))
+static inline long xsm_do_xsm_op (XEN_GUEST_HANDLE(xsm_op_t) op)
 {
-    return 0;
+    return xsm_ops->do_xsm_op(op);
 }
-#endif
 
 #ifdef CONFIG_X86
 static inline int xsm_shadow_control (struct domain *d, uint32_t op)
 {
-    return xsm_call(shadow_control(d, op));
+    return xsm_ops->shadow_control(d, op);
 }
 
 static inline int xsm_getpageframeinfo (struct domain *d)
 {
-    return xsm_call(getpageframeinfo(d));
+    return xsm_ops->getpageframeinfo(d);
 }
 
 static inline int xsm_getmemlist (struct domain *d)
 {
-    return xsm_call(getmemlist(d));
+    return xsm_ops->getmemlist(d);
 }
 
 static inline int xsm_hypercall_init (struct domain *d)
 {
-    return xsm_call(hypercall_init(d));
+    return xsm_ops->hypercall_init(d);
 }
 
 static inline int xsm_hvmcontext (struct domain *d, uint32_t cmd)
 {
-    return xsm_call(hvmcontext(d, cmd));
+    return xsm_ops->hvmcontext(d, cmd);
 }
 
 static inline int xsm_address_size (struct domain *d, uint32_t cmd)
 {
-    return xsm_call(address_size(d, cmd));
+    return xsm_ops->address_size(d, cmd);
 }
 
 static inline int xsm_machine_address_size (struct domain *d, uint32_t cmd)
 {
-    return xsm_call(machine_address_size(d, cmd));
+    return xsm_ops->machine_address_size(d, cmd);
 }
 
 static inline int xsm_hvm_param (struct domain *d, unsigned long op)
 {
-    return xsm_call(hvm_param(d, op));
+    return xsm_ops->hvm_param(d, op);
 }
 
 static inline int xsm_hvm_set_pci_intx_level (struct domain *d)
 {
-    return xsm_call(hvm_set_pci_intx_level(d));
+    return xsm_ops->hvm_set_pci_intx_level(d);
 }
 
 static inline int xsm_hvm_set_isa_irq_level (struct domain *d)
 {
-    return xsm_call(hvm_set_isa_irq_level(d));
+    return xsm_ops->hvm_set_isa_irq_level(d);
 }
 
 static inline int xsm_hvm_set_pci_link_route (struct domain *d)
 {
-    return xsm_call(hvm_set_pci_link_route(d));
+    return xsm_ops->hvm_set_pci_link_route(d);
 }
 
 static inline int xsm_hvm_inject_msi (struct domain *d)
 {
-    return xsm_call(hvm_inject_msi(d));
+    return xsm_ops->hvm_inject_msi(d);
 }
 
 static inline int xsm_mem_event (struct domain *d)
 {
-    return xsm_call(mem_event(d));
+    return xsm_ops->mem_event(d);
 }
 
 static inline int xsm_mem_sharing (struct domain *d)
 {
-    return xsm_call(mem_sharing(d));
+    return xsm_ops->mem_sharing(d);
 }
 
 static inline int xsm_apic (struct domain *d, int cmd)
 {
-    return xsm_call(apic(d, cmd));
+    return xsm_ops->apic(d, cmd);
 }
 
 static inline int xsm_xen_settime (void)
 {
-    return xsm_call(xen_settime());
+    return xsm_ops->xen_settime();
 }
 
 static inline int xsm_memtype (uint32_t access)
 {
-    return xsm_call(memtype(access));
+    return xsm_ops->memtype(access);
 }
 
 static inline int xsm_microcode (void)
 {
-    return xsm_call(microcode());
+    return xsm_ops->microcode();
 }
 
 static inline int xsm_physinfo (void)
 {
-    return xsm_call(physinfo());
+    return xsm_ops->physinfo();
 }
 
 static inline int xsm_platform_quirk (uint32_t quirk)
 {
-    return xsm_call(platform_quirk(quirk));
+    return xsm_ops->platform_quirk(quirk);
 }
 
 static inline int xsm_firmware_info (void)
 {
-    return xsm_call(firmware_info());
+    return xsm_ops->firmware_info();
 }
 
 static inline int xsm_efi_call (void)
 {
-    return xsm_call(efi_call());
+    return xsm_ops->efi_call();
 }
 
 static inline int xsm_acpi_sleep (void)
 {
-    return xsm_call(acpi_sleep());
+    return xsm_ops->acpi_sleep();
 }
 
 static inline int xsm_change_freq (void)
 {
-    return xsm_call(change_freq());
+    return xsm_ops->change_freq();
 }
 
 static inline int xsm_getidletime (void)
 {
-    return xsm_call(getidletime());
+    return xsm_ops->getidletime();
 }
 
 static inline int xsm_machine_memory_map(void)
 {
-    return xsm_call(machine_memory_map());
+    return xsm_ops->machine_memory_map();
 }
 
 static inline int xsm_domain_memory_map(struct domain *d)
 {
-    return xsm_call(domain_memory_map(d));
+    return xsm_ops->domain_memory_map(d);
 }
 
 static inline int xsm_mmu_normal_update (struct domain *d, struct domain *t,
                                          struct domain *f, intpte_t fpte)
 {
-    return xsm_call(mmu_normal_update(d, t, f, fpte));
+    return xsm_ops->mmu_normal_update(d, t, f, fpte);
 }
 
 static inline int xsm_mmu_machphys_update (struct domain *d1, struct domain *d2,
                                            unsigned long mfn)
 {
-    return xsm_call(mmu_machphys_update(d1, d2, mfn));
+    return xsm_ops->mmu_machphys_update(d1, d2, mfn);
 }
 
 static inline int xsm_update_va_mapping(struct domain *d, struct domain *f, 
                                                             l1_pgentry_t pte)
 {
-    return xsm_call(update_va_mapping(d, f, pte));
+    return xsm_ops->update_va_mapping(d, f, pte);
 }
 
 static inline int xsm_add_to_physmap(struct domain *d1, struct domain *d2)
 {
-    return xsm_call(add_to_physmap(d1, d2));
+    return xsm_ops->add_to_physmap(d1, d2);
 }
 
 static inline int xsm_sendtrigger(struct domain *d)
 {
-    return xsm_call(sendtrigger(d));
+    return xsm_ops->sendtrigger(d);
 }
 
 static inline int xsm_bind_pt_irq(struct domain *d, 
                                                 struct xen_domctl_bind_pt_irq *bind)
 {
-    return xsm_call(bind_pt_irq(d, bind));
+    return xsm_ops->bind_pt_irq(d, bind);
 }
 
 static inline int xsm_unbind_pt_irq(struct domain *d,
                                                 struct xen_domctl_bind_pt_irq *bind)
 {
-    return xsm_call(unbind_pt_irq(d, bind));
+    return xsm_ops->unbind_pt_irq(d, bind);
 }
 
 static inline int xsm_pin_mem_cacheattr(struct domain *d)
 {
-    return xsm_call(pin_mem_cacheattr(d));
+    return xsm_ops->pin_mem_cacheattr(d);
 }
 
 static inline int xsm_ext_vcpucontext(struct domain *d, uint32_t cmd)
 {
-    return xsm_call(ext_vcpucontext(d, cmd));
+    return xsm_ops->ext_vcpucontext(d, cmd);
 }
 static inline int xsm_vcpuextstate(struct domain *d, uint32_t cmd)
 {
-    return xsm_call(vcpuextstate(d, cmd));
+    return xsm_ops->vcpuextstate(d, cmd);
 }
 
 static inline int xsm_ioport_permission (struct domain *d, uint32_t s, uint32_t e, uint8_t allow)
 {
-    return xsm_call(ioport_permission(d, s, e, allow));
+    return xsm_ops->ioport_permission(d, s, e, allow);
 }
 
 static inline int xsm_ioport_mapping (struct domain *d, uint32_t s, uint32_t e, uint8_t allow)
 {
-    return xsm_call(ioport_mapping(d, s, e, allow));
+    return xsm_ops->ioport_mapping(d, s, e, allow);
 }
 #endif /* CONFIG_X86 */
 
+extern int xsm_init(unsigned long *module_map, const multiboot_info_t *mbi,
+                    void *(*bootstrap_map)(const module_t *));
+extern int xsm_policy_init(unsigned long *module_map,
+                           const multiboot_info_t *mbi,
+                           void *(*bootstrap_map)(const module_t *));
+extern int register_xsm(struct xsm_operations *ops);
+extern int unregister_xsm(struct xsm_operations *ops);
+
 extern struct xsm_operations dummy_xsm_ops;
 extern void xsm_fixup_ops(struct xsm_operations *ops);
 
+#else /* XSM_ENABLE */
+
+#define XSM_DEFAULT(type, name) inline type xsm_ ## name
+#include <xsm/dummy.h>
+
+static inline int xsm_init (unsigned long *module_map,
+                            const multiboot_info_t *mbi,
+                            void *(*bootstrap_map)(const module_t *))
+{
+    return 0;
+}
+#endif /* XSM_ENABLE */
+
 #endif /* __XSM_H */
diff --git a/xen/xsm/dummy.c b/xen/xsm/dummy.c
index a5dbfe7..47192d7 100644
--- a/xen/xsm/dummy.c
+++ b/xen/xsm/dummy.c
@@ -10,621 +10,8 @@
  *  as published by the Free Software Foundation.
  */
 
-#include <xen/sched.h>
-#include <xsm/xsm.h>
-
-static void dummy_security_domaininfo(struct domain *d,
-                                    struct xen_domctl_getdomaininfo *info)
-{
-    return;
-}
-
-static int dummy_setvcpucontext(struct domain *d)
-{
-    return 0;
-}
-
-static int dummy_pausedomain (struct domain *d)
-{
-    return 0;
-}
-
-static int dummy_unpausedomain (struct domain *d)
-{
-    return 0;
-}
-
-static int dummy_resumedomain (struct domain *d)
-{
-    return 0;
-}
-
-static int dummy_domain_create(struct domain *d, u32 ssidref)
-{
-    return 0;
-}
-
-static int dummy_max_vcpus(struct domain *d)
-{
-    return 0;
-}
-
-static int dummy_destroydomain (struct domain *d)
-{
-    return 0;
-}
-
-static int dummy_vcpuaffinity (int cmd, struct domain *d)
-{
-    return 0;
-}
-
-static int dummy_scheduler (struct domain *d)
-{
-    return 0;
-}
-
-static int dummy_getdomaininfo (struct domain *d)
-{
-    if ( !IS_PRIV(current->domain) )
-        return -EPERM;
-    return 0;
-}
-
-static int dummy_getvcpucontext (struct domain *d)
-{
-    return 0;
-}
-
-static int dummy_getvcpuinfo (struct domain *d)
-{
-    return 0;
-}
-
-static int dummy_domain_settime (struct domain *d)
-{
-    return 0;
-}
-
-static int dummy_set_target (struct domain *d, struct domain *e)
-{
-    return 0;
-}
-
-static int dummy_domctl(struct domain *d, int cmd)
-{
-    return 0;
-}
-
-static int dummy_set_virq_handler(struct domain *d, uint32_t virq)
-{
-    return 0;
-}
-
-static int dummy_tbufcontrol (void)
-{
-    return 0;
-}
-
-static int dummy_readconsole (uint32_t clear)
-{
-    return 0;
-}
-
-static int dummy_sched_id (void)
-{
-    return 0;
-}
-
-static int dummy_setdomainmaxmem (struct domain *d)
-{
-    return 0;
-}
-
-static int dummy_setdomainhandle (struct domain *d)
-{
-    return 0;
-}
-
-static int dummy_setdebugging (struct domain *d)
-{
-    return 0;
-}
-
-static int dummy_perfcontrol (void)
-{
-    return 0;
-}
-
-static int dummy_debug_keys (void)
-{
-    return 0;
-}
-
-static int dummy_getcpuinfo (void)
-{
-    return 0;
-}
-
-static int dummy_get_pmstat (void)
-{
-    return 0;
-}
-
-static int dummy_setpminfo (void)
-{
-    return 0;
-}
-
-static int dummy_pm_op (void)
-{
-    return 0;
-}
-
-static int dummy_do_mca (void)
-{
-    return 0;
-}
-
-static int dummy_availheap (void)
-{
-    return 0;
-}
-
-static int dummy_alloc_security_domain (struct domain *d)
-{
-    return 0;
-}
-
-static void dummy_free_security_domain (struct domain *d)
-{
-    return;
-}
-
-static int dummy_grant_mapref (struct domain *d1, struct domain *d2,
-                                                                uint32_t flags)
-{
-    return 0;
-}
-
-static int dummy_grant_unmapref (struct domain *d1, struct domain *d2)
-{
-    return 0;
-}
-
-static int dummy_grant_setup (struct domain *d1, struct domain *d2)
-{
-    return 0;
-}
-
-static int dummy_grant_transfer (struct domain *d1, struct domain *d2)
-{
-    return 0;
-}
-
-static int dummy_grant_copy (struct domain *d1, struct domain *d2)
-{
-    return 0;
-}
-
-static int dummy_grant_query_size (struct domain *d1, struct domain *d2)
-{
-    return 0;
-}
-
-static int dummy_memory_adjust_reservation (struct domain *d1,
-                                                            struct domain *d2)
-{
-    return 0;
-}
-
-static int dummy_memory_stat_reservation (struct domain *d1, struct domain *d2)
-{
-    return 0;
-}
-
-static int dummy_console_io (struct domain *d, int cmd)
-{
-    return 0;
-}
-
-static int dummy_profile (struct domain *d, int op)
-{
-    return 0;
-}
-
-static int dummy_kexec (void)
-{
-    return 0;
-}
-
-static int dummy_schedop_shutdown (struct domain *d1, struct domain *d2)
-{
-    return 0;
-}
-
-static int dummy_memory_pin_page(struct domain *d1, struct domain *d2, struct page_info *page)
-{
-    return 0;
-}
-
-static int dummy_evtchn_unbound (struct domain *d, struct evtchn *chn,
-                                                                    domid_t id2)
-{
-    return 0;
-}
-
-static int dummy_evtchn_interdomain (struct domain *d1, struct evtchn
-                                *chan1, struct domain *d2, struct evtchn *chan2)
-{
-    return 0;
-}
-
-static void dummy_evtchn_close_post (struct evtchn *chn)
-{
-    return;
-}
-
-static int dummy_evtchn_send (struct domain *d, struct evtchn *chn)
-{
-    return 0;
-}
-
-static int dummy_evtchn_status (struct domain *d, struct evtchn *chn)
-{
-    return 0;
-}
-
-static int dummy_evtchn_reset (struct domain *d1, struct domain *d2)
-{
-    return 0;
-}
-
-static int dummy_alloc_security_evtchn (struct evtchn *chn)
-{
-    return 0;
-}
-
-static void dummy_free_security_evtchn (struct evtchn *chn)
-{
-    return;
-}
-
-static char *dummy_show_security_evtchn (struct domain *d, const struct evtchn *chn)
-{
-    return NULL;
-}
-
-static int dummy_get_pod_target(struct domain *d)
-{
-    return 0;
-}
-
-static int dummy_set_pod_target(struct domain *d)
-{
-    return 0;
-}
-
-static int dummy_get_device_group (uint32_t machine_bdf)
-{
-    return 0;
-}
-
-static int dummy_test_assign_device (uint32_t machine_bdf)
-{
-    return 0;
-}
-
-static int dummy_assign_device (struct domain *d, uint32_t machine_bdf)
-{
-    return 0;
-}
-
-static int dummy_deassign_device (struct domain *d, uint32_t machine_bdf)
-{
-    return 0;
-}
-
-static int dummy_resource_plug_core (void)
-{
-    return 0;
-}
-
-static int dummy_resource_unplug_core (void)
-{
-    return 0;
-}
-
-static int dummy_resource_plug_pci (uint32_t machine_bdf)
-{
-    return 0;
-}
-
-static int dummy_resource_unplug_pci (uint32_t machine_bdf)
-{
-    return 0;
-}
-
-static int dummy_resource_setup_pci (uint32_t machine_bdf)
-{
-    return 0;
-}
-
-static int dummy_resource_setup_gsi (int gsi)
-{
-    return 0;
-}
-
-static int dummy_resource_setup_misc (void)
-{
-    return 0;
-}
-
-static int dummy_page_offline (uint32_t cmd)
-{
-    return 0;
-}
-
-static int dummy_lockprof (void)
-{
-    return 0;
-}
-
-static int dummy_cpupool_op (void)
-{
-    return 0;
-}
-
-static int dummy_sched_op (void)
-{
-    return 0;
-}
-
-static long dummy___do_xsm_op(XEN_GUEST_HANDLE(xsm_op_t) op)
-{
-    return -ENOSYS;
-}
-
-static char *dummy_show_irq_sid (int irq)
-{
-    return NULL;
-}
-
-static int dummy_map_domain_pirq (struct domain *d, int irq, void *data)
-{
-    return 0;
-}
-
-static int dummy_unmap_domain_pirq (struct domain *d, int irq)
-{
-    return 0;
-}
-
-static int dummy_irq_permission (struct domain *d, int pirq, uint8_t allow)
-{
-    return 0;
-}
-
-static int dummy_iomem_permission (struct domain *d, uint64_t s, uint64_t e, uint8_t allow)
-{
-    return 0;
-}
-
-static int dummy_iomem_mapping (struct domain *d, uint64_t s, uint64_t e, uint8_t allow)
-{
-    return 0;
-}
-
-static int dummy_pci_config_permission (struct domain *d, uint32_t machine_bdf,
-                                        uint16_t start, uint16_t end,
-                                        uint8_t access)
-{
-    return 0;
-}
-
-#ifdef CONFIG_X86
-static int dummy_shadow_control (struct domain *d, uint32_t op)
-{
-    return 0;
-}
-
-static int dummy_getpageframeinfo (struct domain *d)
-{
-    return 0;
-}
-
-static int dummy_getmemlist (struct domain *d)
-{
-    return 0;
-}
-
-static int dummy_hypercall_init (struct domain *d)
-{
-    return 0;
-}
-
-static int dummy_hvmcontext (struct domain *d, uint32_t cmd)
-{
-    return 0;
-}
-
-static int dummy_address_size (struct domain *d, uint32_t cmd)
-{
-    return 0;
-}
-
-static int dummy_machine_address_size (struct domain *d, uint32_t cmd)
-{
-    return 0;
-}
-
-static int dummy_hvm_param (struct domain *d, unsigned long op)
-{
-    return 0;
-}
-
-static int dummy_hvm_set_pci_intx_level (struct domain *d)
-{
-    return 0;
-}
-
-static int dummy_hvm_set_isa_irq_level (struct domain *d)
-{
-    return 0;
-}
-
-static int dummy_hvm_set_pci_link_route (struct domain *d)
-{
-    return 0;
-}
-
-static int dummy_hvm_inject_msi (struct domain *d)
-{
-    return 0;
-}
-
-static int dummy_mem_event (struct domain *d)
-{
-    return 0;
-}
-
-static int dummy_mem_sharing (struct domain *d)
-{
-    return 0;
-}
-
-static int dummy_apic (struct domain *d, int cmd)
-{
-    return 0;
-}
-
-static int dummy_xen_settime (void)
-{
-    return 0;
-}
-
-static int dummy_memtype (uint32_t access)
-{
-    return 0;
-}
-
-static int dummy_microcode (void)
-{
-    return 0;
-}
-
-static int dummy_physinfo (void)
-{
-    return 0;
-}
-
-static int dummy_platform_quirk (uint32_t quirk)
-{
-    return 0;
-}
-
-static int dummy_firmware_info (void)
-{
-    return 0;
-}
-
-static int dummy_efi_call(void)
-{
-    return 0;
-}
-
-static int dummy_acpi_sleep (void)
-{
-    return 0;
-}
-
-static int dummy_change_freq (void)
-{
-    return 0;
-}
-
-static int dummy_getidletime (void)
-{
-    return 0;
-}
-
-static int dummy_machine_memory_map (void)
-{
-    return 0;
-}
-
-static int dummy_domain_memory_map (struct domain *d)
-{
-    return 0;
-}
-
-static int dummy_mmu_normal_update (struct domain *d, struct domain *t,
-                                    struct domain *f, intpte_t fpte)
-{
-    return 0;
-}
-
-static int dummy_mmu_machphys_update (struct domain *d, struct domain *f, unsigned long mfn)
-{
-    return 0;
-}
-
-static int dummy_update_va_mapping (struct domain *d, struct domain *f, 
-                                                            l1_pgentry_t pte)
-{
-    return 0;
-}
-
-static int dummy_add_to_physmap (struct domain *d1, struct domain *d2)
-{
-    return 0;
-}
-
-static int dummy_remove_from_physmap (struct domain *d1, struct domain *d2)
-{
-    return 0;
-}
-
-static int dummy_sendtrigger (struct domain *d)
-{
-    return 0;
-}
-
-static int dummy_bind_pt_irq (struct domain *d, struct xen_domctl_bind_pt_irq *bind)
-{
-    return 0;
-}
-
-static int dummy_unbind_pt_irq (struct domain *d, struct xen_domctl_bind_pt_irq *bind)
-{
-    return 0;
-}
-
-static int dummy_pin_mem_cacheattr (struct domain *d)
-{
-    return 0;
-}
-
-static int dummy_ext_vcpucontext (struct domain *d, uint32_t cmd)
-{
-    return 0;
-}
-
-static int dummy_vcpuextstate (struct domain *d, uint32_t cmd)
-{
-    return 0;
-}
-
-static int dummy_ioport_permission (struct domain *d, uint32_t s, uint32_t e, uint8_t allow)
-{
-    return 0;
-}
-
-static int dummy_ioport_mapping (struct domain *d, uint32_t s, uint32_t e, uint8_t allow)
-{
-    return 0;
-}
-#endif
+#define XSM_DEFAULT(type, name) type dummy_ ## name
+#include <xsm/dummy.h>
 
 struct xsm_operations dummy_xsm_ops;
 
@@ -732,7 +119,7 @@ void xsm_fixup_ops (struct xsm_operations *ops)
     set_to_dummy_if_null(ops, cpupool_op);
     set_to_dummy_if_null(ops, sched_op);
 
-    set_to_dummy_if_null(ops, __do_xsm_op);
+    set_to_dummy_if_null(ops, do_xsm_op);
 
 #ifdef CONFIG_X86
     set_to_dummy_if_null(ops, shadow_control);
diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
index 6d4b4f0..7cc06a8 100644
--- a/xen/xsm/flask/hooks.c
+++ b/xen/xsm/flask/hooks.c
@@ -1555,7 +1555,7 @@ static struct xsm_operations flask_ops = {
     .cpupool_op = flask_cpupool_op,
     .sched_op = flask_sched_op,
 
-    .__do_xsm_op = do_flask_op,
+    .do_xsm_op = do_flask_op,
 
 #ifdef CONFIG_X86
     .shadow_control = flask_shadow_control,
diff --git a/xen/xsm/xsm_core.c b/xen/xsm/xsm_core.c
index 96c8669..9bf6ab9 100644
--- a/xen/xsm/xsm_core.c
+++ b/xen/xsm/xsm_core.c
@@ -113,7 +113,7 @@ int unregister_xsm(struct xsm_operations *ops)
 
 long do_xsm_op (XEN_GUEST_HANDLE(xsm_op_t) op)
 {
-    return __do_xsm_op(op);
+    return xsm_do_xsm_op(op);
 }
 
 
-- 
1.7.11.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 17 15:24:22 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 15:24:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDdB8-0003aR-LN; Mon, 17 Sep 2012 15:24:06 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1TDdB7-0003Zt-1X
	for xen-devel@lists.xen.org; Mon, 17 Sep 2012 15:24:05 +0000
Received: from [85.158.139.211:45600] by server-12.bemta-5.messagelabs.com id
	71/3B-19338-49047505; Mon, 17 Sep 2012 15:24:04 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-15.tower-206.messagelabs.com!1347895443!18946108!1
X-Originating-IP: [63.239.67.9]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4516 invoked from network); 17 Sep 2012 15:24:03 -0000
Received: from emvm-gh1-uea08.nsa.gov (HELO nsa.gov) (63.239.67.9)
	by server-15.tower-206.messagelabs.com with SMTP;
	17 Sep 2012 15:24:03 -0000
X-TM-IMSS-Message-ID: <53802e3a0012acca@nsa.gov>
Received: from tarius.tycho.ncsc.mil ([144.51.3.1]) by nsa.gov ([63.239.67.9])
	with ESMTP (TREND IMSS SMTP Service 7.1) id 53802e3a0012acca ;
	Mon, 17 Sep 2012 11:23:42 -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 q8HFO0xS027504; 
	Mon, 17 Sep 2012 11:24:00 -0400
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xen.org
Date: Mon, 17 Sep 2012 11:23:24 -0400
Message-Id: <1347895425-17959-3-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.11.4
In-Reply-To: <1347895425-17959-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1347895425-17959-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: dgdegra@tycho.nsa.gov, keir@xen.org
Subject: [Xen-devel] [PATCH 02/23] xsm/flask: remove unneeded create_sid
	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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This field was only used to populate the ssid of dom0, which can be
handled explicitly in the domain creation hook. This also removes the
unnecessary permission check on the creation of dom0.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 tools/flask/policy/policy/modules/xen/xen.te |  2 --
 xen/xsm/flask/hooks.c                        | 23 ++++++++++-------------
 xen/xsm/flask/include/objsec.h               |  1 -
 3 files changed, 10 insertions(+), 16 deletions(-)

diff --git a/tools/flask/policy/policy/modules/xen/xen.te b/tools/flask/policy/policy/modules/xen/xen.te
index e175d4b..9cc5240 100644
--- a/tools/flask/policy/policy/modules/xen/xen.te
+++ b/tools/flask/policy/policy/modules/xen/xen.te
@@ -52,8 +52,6 @@ type device_t, resource_type;
 # Rules required to boot the hypervisor and dom0
 #
 ################################################################################
-allow xen_t dom0_t:domain { create };
-
 allow dom0_t xen_t:xen { kexec readapic writeapic mtrr_read mtrr_add mtrr_del
 	scheduler physinfo heap quirk readconsole writeconsole settime getcpuinfo
 	microcode cpupool_op sched_op pm_op };
diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
index 8c853de..88fef9c 100644
--- a/xen/xsm/flask/hooks.c
+++ b/xen/xsm/flask/hooks.c
@@ -108,12 +108,10 @@ static int flask_domain_alloc_security(struct domain *d)
 
     memset(dsec, 0, sizeof(struct domain_security_struct));
 
-    dsec->create_sid = SECSID_NULL;
     switch ( d->domain_id )
     {
     case DOMID_IDLE:
         dsec->sid = SECINITSID_XEN;
-        dsec->create_sid = SECINITSID_DOM0;
         break;
     case DOMID_XEN:
         dsec->sid = SECINITSID_DOMXEN;
@@ -489,25 +487,24 @@ static int flask_domain_create(struct domain *d, u32 ssidref)
     int rc;
     struct domain_security_struct *dsec1;
     struct domain_security_struct *dsec2;
+    static int dom0_created = 0;
 
     dsec1 = current->domain->ssid;
+    dsec2 = d->ssid;
 
-    if ( dsec1->create_sid == SECSID_NULL ) 
-        dsec1->create_sid = ssidref;
+    if ( is_idle_domain(current->domain) && !dom0_created )
+    {
+        dsec2->sid = SECINITSID_DOM0;
+        dom0_created = 1;
+        return 0;
+    }
 
-    rc = avc_has_perm(dsec1->sid, dsec1->create_sid, SECCLASS_DOMAIN, 
+    rc = avc_has_perm(dsec1->sid, ssidref, SECCLASS_DOMAIN,
                       DOMAIN__CREATE, NULL);
     if ( rc )
-    {
-        dsec1->create_sid = SECSID_NULL;
         return rc;
-    }
-
-    dsec2 = d->ssid;
-    dsec2->sid = dsec1->create_sid;
 
-    dsec1->create_sid = SECSID_NULL;
-    dsec2->create_sid = SECSID_NULL;
+    dsec2->sid = ssidref;
 
     return rc;
 }
diff --git a/xen/xsm/flask/include/objsec.h b/xen/xsm/flask/include/objsec.h
index df5baee..4ff52be 100644
--- a/xen/xsm/flask/include/objsec.h
+++ b/xen/xsm/flask/include/objsec.h
@@ -19,7 +19,6 @@
 
 struct domain_security_struct {
     u32 sid;               /* current SID */
-    u32 create_sid;
 };
 
 struct evtchn_security_struct {
-- 
1.7.11.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 17 15:24:22 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 15:24:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDdBA-0003bR-Fl; Mon, 17 Sep 2012 15:24:08 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1TDdB8-0003Zv-0j
	for xen-devel@lists.xen.org; Mon, 17 Sep 2012 15:24:06 +0000
Received: from [85.158.139.211:45644] by server-1.bemta-5.messagelabs.com id
	82/F9-32692-59047505; Mon, 17 Sep 2012 15:24:05 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-11.tower-206.messagelabs.com!1347895443!18904562!1
X-Originating-IP: [63.239.67.9]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30116 invoked from network); 17 Sep 2012 15:24:03 -0000
Received: from emvm-gh1-uea08.nsa.gov (HELO nsa.gov) (63.239.67.9)
	by server-11.tower-206.messagelabs.com with SMTP;
	17 Sep 2012 15:24:03 -0000
X-TM-IMSS-Message-ID: <53802d9e0012acc6@nsa.gov>
Received: from tarius.tycho.ncsc.mil ([144.51.3.1]) by nsa.gov ([63.239.67.9])
	with ESMTP (TREND IMSS SMTP Service 7.1) id 53802d9e0012acc6 ;
	Mon, 17 Sep 2012 11:23:42 -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 q8HFO0xR027504; 
	Mon, 17 Sep 2012 11:24:00 -0400
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xen.org
Date: Mon, 17 Sep 2012 11:23:23 -0400
Message-Id: <1347895425-17959-2-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.11.4
In-Reply-To: <1347895425-17959-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1347895425-17959-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: dgdegra@tycho.nsa.gov, keir@xen.org
Subject: [Xen-devel] [PATCH 01/23] xsm/flask: remove inherited class
	attributes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 ability to declare common permission blocks shared across multiple
classes is not currently used in Xen. Currently, support for this
feature is broken in the header generation scripts, and it is not
expected that this feature will be used in the future, so remove the
dead code.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 tools/flask/policy/policy/flask/Makefile           |  2 +-
 tools/flask/policy/policy/flask/access_vectors     | 17 +----
 tools/flask/policy/policy/flask/mkaccess_vector.sh | 89 ----------------------
 xen/xsm/flask/avc.c                                | 39 ----------
 xen/xsm/flask/include/av_inherit.h                 |  1 -
 xen/xsm/flask/include/avc_ss.h                     |  8 --
 xen/xsm/flask/include/common_perm_to_string.h      |  1 -
 xen/xsm/flask/ss/policydb.c                        | 46 +----------
 xen/xsm/flask/ss/services.c                        | 54 +------------
 9 files changed, 8 insertions(+), 249 deletions(-)
 delete mode 100644 xen/xsm/flask/include/av_inherit.h
 delete mode 100644 xen/xsm/flask/include/common_perm_to_string.h

diff --git a/tools/flask/policy/policy/flask/Makefile b/tools/flask/policy/policy/flask/Makefile
index 970b9fe..5f57e88 100644
--- a/tools/flask/policy/policy/flask/Makefile
+++ b/tools/flask/policy/policy/flask/Makefile
@@ -14,7 +14,7 @@ FLASK_H_DEPEND = security_classes initial_sids
 AV_H_DEPEND = access_vectors
 
 FLASK_H_FILES = class_to_string.h flask.h initial_sid_to_string.h
-AV_H_FILES = av_inherit.h common_perm_to_string.h av_perm_to_string.h av_permissions.h
+AV_H_FILES = av_perm_to_string.h av_permissions.h
 ALL_H_FILES = $(FLASK_H_FILES) $(AV_H_FILES)
 
 all:  $(ALL_H_FILES)
diff --git a/tools/flask/policy/policy/flask/access_vectors b/tools/flask/policy/policy/flask/access_vectors
index 5901911..a884312 100644
--- a/tools/flask/policy/policy/flask/access_vectors
+++ b/tools/flask/policy/policy/flask/access_vectors
@@ -1,22 +1,7 @@
 #
-# Define common prefixes for access vectors
-#
-# common common_name { permission_name ... }
-
-#
-# Define a common prefix for file access vectors.
-#
-
-
-#
 # Define the access vectors.
 #
-# class class_name [ inherits common_name ] { permission_name ... }
-
-
-#
-# Define the access vector interpretation for file-related objects.
-#
+# class class_name { permission_name ... }
 
 class xen
 {
diff --git a/tools/flask/policy/policy/flask/mkaccess_vector.sh b/tools/flask/policy/policy/flask/mkaccess_vector.sh
index b5da734..43a60a7 100644
--- a/tools/flask/policy/policy/flask/mkaccess_vector.sh
+++ b/tools/flask/policy/policy/flask/mkaccess_vector.sh
@@ -10,50 +10,21 @@ shift
 
 # output files
 av_permissions="av_permissions.h"
-av_inherit="av_inherit.h"
-common_perm_to_string="common_perm_to_string.h"
 av_perm_to_string="av_perm_to_string.h"
 
 cat $* | $awk "
 BEGIN	{
 		outfile = \"$av_permissions\"
-		inheritfile = \"$av_inherit\"
-		cpermfile = \"$common_perm_to_string\"
 		avpermfile = \"$av_perm_to_string\"
 		"'
 		nextstate = "COMMON_OR_AV";
 		printf("/* This file is automatically generated.  Do not edit. */\n") > outfile;
-		printf("/* This file is automatically generated.  Do not edit. */\n") > inheritfile;
-		printf("/* This file is automatically generated.  Do not edit. */\n") > cpermfile;
 		printf("/* This file is automatically generated.  Do not edit. */\n") > avpermfile;
 ;
 	}
 /^[ \t]*#/	{ 
 			next;
 		}
-$1 == "common"	{ 
-			if (nextstate != "COMMON_OR_AV")
-			{
-				printf("Parse error:  Unexpected COMMON definition on line %d\n", NR);
-				next;	
-			}
-
-			if ($2 in common_defined)
-			{
-				printf("Duplicate COMMON definition for %s on line %d.\n", $2, NR);
-				next;
-			}	
-			common_defined[$2] = 1;
-
-			tclass = $2;
-			common_name = $2; 
-			permission = 1;
-
-			printf("TB_(common_%s_perm_to_string)\n", $2) > cpermfile;
-
-			nextstate = "COMMON-OPENBRACKET";
-			next;
-		}
 $1 == "class"	{
 			if (nextstate != "COMMON_OR_AV" &&
 			    nextstate != "CLASS_OR_CLASS-OPENBRACKET")
@@ -71,62 +42,11 @@ $1 == "class"	{
 			} 
 			av_defined[tclass] = 1;
 
-			inherits = "";
 			permission = 1;
 
 			nextstate = "INHERITS_OR_CLASS-OPENBRACKET";
 			next;
 		}
-$1 == "inherits" {			
-			if (nextstate != "INHERITS_OR_CLASS-OPENBRACKET")
-			{
-				printf("Parse error:  Unexpected INHERITS definition on line %d\n", NR);
-				next;	
-			}
-
-			if (!($2 in common_defined))
-			{
-				printf("COMMON %s is not defined (line %d).\n", $2, NR);
-				next;
-			}
-
-			inherits = $2;
-			permission = common_base[$2];
-
-			for (combined in common_perms)
-			{
-				split(combined,separate, SUBSEP);
-				if (separate[1] == inherits)
-				{
-					inherited_perms[common_perms[combined]] = separate[2];
-				}
-			}
-
-                        j = 1;
-                        for (i in inherited_perms) {
-                            ind[j] = i + 0;
-                            j++;
-                        }
-                        n = asort(ind);
-			for (i = 1; i <= n; i++) {
-				perm = inherited_perms[ind[i]];
-				printf("#define %s__%s", toupper(tclass), toupper(perm)) > outfile; 
-				spaces = 40 - (length(perm) + length(tclass));
-				if (spaces < 1)
-				      spaces = 1;
-				for (j = 0; j < spaces; j++) 
-					printf(" ") > outfile; 
-				printf("0x%08xUL\n", ind[i]) > outfile; 
-			}
-			printf("\n") > outfile;
-                        for (i in ind) delete ind[i];
-                        for (i in inherited_perms) delete inherited_perms[i];
-
-			printf("   S_(SECCLASS_%s, %s, 0x%08xUL)\n", toupper(tclass), inherits, permission) > inheritfile; 
-
-			nextstate = "CLASS_OR_CLASS-OPENBRACKET";
-			next;
-		}
 $1 == "{"	{ 
 			if (nextstate != "INHERITS_OR_CLASS-OPENBRACKET" &&
 			    nextstate != "CLASS_OR_CLASS-OPENBRACKET" &&
@@ -177,15 +97,6 @@ $1 == "{"	{
 
 				av_perms[tclass,$1] = permission;
 		
-				if (inherits != "")
-				{
-					if ((inherits,$1) in common_perms)
-					{
-						printf("Permission %s in %s on line %d conflicts with common permission.\n", $1, tclass, inherits, NR);
-						next;
-					}
-				}
-
 				printf("#define %s__%s", toupper(tclass), toupper($1)) > outfile; 
 
 				printf("   S_(SECCLASS_%s, %s__%s, \"%s\")\n", toupper(tclass), toupper(tclass), toupper($1), $1) > avpermfile; 
diff --git a/xen/xsm/flask/avc.c b/xen/xsm/flask/avc.c
index 44240a9..7fede00 100644
--- a/xen/xsm/flask/avc.c
+++ b/xen/xsm/flask/avc.c
@@ -45,28 +45,11 @@ static const char *class_to_string[] = {
 #undef S_
 };
 
-#define TB_(s) static const char * s [] = {
-#define TE_(s) };
-#define S_(s) s,
-#include "common_perm_to_string.h"
-#undef TB_
-#undef TE_
-#undef S_
-
-static const struct av_inherit av_inherit[] = {
-#define S_(c, i, b) { .tclass = c, .common_pts = common_##i##_perm_to_string, \
-                      .common_base = b },
-#include "av_inherit.h"
-#undef S_
-};
-
 const struct selinux_class_perm selinux_class_perm = {
     .av_perm_to_string = av_perm_to_string,
     .av_pts_len = ARRAY_SIZE(av_perm_to_string),
     .class_to_string = class_to_string,
     .cts_len = ARRAY_SIZE(class_to_string),
-    .av_inherit = av_inherit,
-    .av_inherit_len = ARRAY_SIZE(av_inherit)
 };
 
 #define AVC_CACHE_SLOTS            512
@@ -181,8 +164,6 @@ static void avc_printk(struct avc_dump_buf *buf, const char *fmt, ...)
  */
 static void avc_dump_av(struct avc_dump_buf *buf, u16 tclass, u32 av)
 {
-    const char **common_pts = NULL;
-    u32 common_base = 0;
     int i, i2, perm;
 
     if ( av == 0 )
@@ -191,29 +172,9 @@ static void avc_dump_av(struct avc_dump_buf *buf, u16 tclass, u32 av)
         return;
     }
 
-    for ( i = 0; i < ARRAY_SIZE(av_inherit); i++ )
-    {
-        if (av_inherit[i].tclass == tclass)
-        {
-            common_pts = av_inherit[i].common_pts;
-            common_base = av_inherit[i].common_base;
-            break;
-        }
-    }
-
     avc_printk(buf, " {");
     i = 0;
     perm = 1;
-    while ( perm < common_base )
-    {
-        if (perm & av)
-        {
-            avc_printk(buf, " %s", common_pts[i]);
-            av &= ~perm;
-        }
-        i++;
-        perm <<= 1;
-    }
 
     while ( i < sizeof(av) * 8 )
     {
diff --git a/xen/xsm/flask/include/av_inherit.h b/xen/xsm/flask/include/av_inherit.h
deleted file mode 100644
index 321ffe7..0000000
--- a/xen/xsm/flask/include/av_inherit.h
+++ /dev/null
@@ -1 +0,0 @@
-/* This file is automatically generated.  Do not edit. */
diff --git a/xen/xsm/flask/include/avc_ss.h b/xen/xsm/flask/include/avc_ss.h
index ea4e98c..a3d7d1e 100644
--- a/xen/xsm/flask/include/avc_ss.h
+++ b/xen/xsm/flask/include/avc_ss.h
@@ -16,19 +16,11 @@ struct av_perm_to_string {
     const char *name;
 };
 
-struct av_inherit {
-    const char **common_pts;
-    u32 common_base;
-    u16 tclass;
-};
-
 struct selinux_class_perm {
     const struct av_perm_to_string *av_perm_to_string;
     u32 av_pts_len;
     u32 cts_len;
     const char **class_to_string;
-    const struct av_inherit *av_inherit;
-    u32 av_inherit_len;
 };
 
 extern const struct selinux_class_perm selinux_class_perm;
diff --git a/xen/xsm/flask/include/common_perm_to_string.h b/xen/xsm/flask/include/common_perm_to_string.h
deleted file mode 100644
index 321ffe7..0000000
--- a/xen/xsm/flask/include/common_perm_to_string.h
+++ /dev/null
@@ -1 +0,0 @@
-/* This file is automatically generated.  Do not edit. */
diff --git a/xen/xsm/flask/ss/policydb.c b/xen/xsm/flask/ss/policydb.c
index 26097b9..fefcd59 100644
--- a/xen/xsm/flask/ss/policydb.c
+++ b/xen/xsm/flask/ss/policydb.c
@@ -254,14 +254,6 @@ out_free_symtab:
 
 static int common_index(void *key, void *datum, void *datap)
 {
-    struct policydb *p;
-    struct common_datum *comdatum;
-
-    comdatum = datum;
-    p = datap;
-    if ( !comdatum->value || comdatum->value > p->p_commons.nprim )
-        return -EINVAL;
-    p->p_common_val_to_name[comdatum->value - 1] = key;
     return 0;
 }
 
@@ -382,8 +374,7 @@ static int (*index_f[SYM_NUM]) (void *key, void *datum, void *datap) =
 };
 
 /*
- * Define the common val_to_name array and the class
- * val_to_name and val_to_struct arrays in a policy
+ * Define the class val_to_name and val_to_struct arrays in a policy
  * database structure.
  *
  * Caller must clean up upon failure.
@@ -392,18 +383,6 @@ static int policydb_index_classes(struct policydb *p)
 {
     int rc;
 
-    p->p_common_val_to_name =
-        xmalloc_array(char *, p->p_commons.nprim);
-    if ( !p->p_common_val_to_name )
-    {
-        rc = -ENOMEM;
-        goto out;
-    }
-
-    rc = hashtab_map(p->p_commons.table, common_index, p);
-    if ( rc )
-        goto out;
-
     p->class_val_to_struct =
         xmalloc_array(struct class_datum *, p->p_classes.nprim);
     if ( !p->class_val_to_struct )
@@ -1200,26 +1179,9 @@ static int class_read(struct policydb *p, struct hashtab *h, void *fp)
 
     if ( len2 )
     {
-        cladatum->comkey = xmalloc_array(char, len2 + 1);
-        if ( !cladatum->comkey )
-        {
-            rc = -ENOMEM;
-            goto bad;
-        }
-        rc = next_entry(cladatum->comkey, fp, len2);
-        if ( rc < 0 )
-            goto bad;
-        cladatum->comkey[len2] = 0;
-
-        cladatum->comdatum = hashtab_search(p->p_commons.table,
-                            cladatum->comkey);
-        if ( !cladatum->comdatum )
-        {
-            printk(KERN_ERR "Flask:  unknown common %s\n",
-                   cladatum->comkey);
-            rc = -EINVAL;
-            goto bad;
-        }
+        printk(KERN_ERR "Flask:  classes with common prefixes are not supported\n");
+        rc = -EINVAL;
+        goto bad;
     }
     for ( i = 0; i < nel; i++ )
     {
diff --git a/xen/xsm/flask/ss/services.c b/xen/xsm/flask/ss/services.c
index 363f586..1bf3b0c 100644
--- a/xen/xsm/flask/ss/services.c
+++ b/xen/xsm/flask/ss/services.c
@@ -1167,10 +1167,10 @@ int security_change_sid(u32 ssid, u32 tsid, u16 tclass, u32 *out_sid)
  */
 static int validate_classes(struct policydb *p)
 {
-    int i, j;
+    int i;
     struct class_datum *cladatum;
     struct perm_datum *perdatum;
-    u32 nprim, tmp, common_pts_len, perm_val, pol_val;
+    u32 nprim, perm_val, pol_val;
     u16 class_val;
     const struct selinux_class_perm *kdefs = &selinux_class_perm;
     const char *def_class, *def_perm, *pol_class;
@@ -1233,56 +1233,6 @@ static int validate_classes(struct policydb *p)
             return -EINVAL;
         }
     }
-    for ( i = 0; i < kdefs->av_inherit_len; i++ )
-    {
-        class_val = kdefs->av_inherit[i].tclass;
-        if ( class_val > p->p_classes.nprim )
-            continue;
-        pol_class = p->p_class_val_to_name[class_val-1];
-        cladatum = hashtab_search(p->p_classes.table, pol_class);
-        BUG_ON( !cladatum );
-        if ( !cladatum->comdatum )
-        {
-            printk(KERN_ERR
-            "Flask:  class %s should have an inherits clause but does not\n",
-                   pol_class);
-            return -EINVAL;
-        }
-        tmp = kdefs->av_inherit[i].common_base;
-        common_pts_len = 0;
-        while ( !(tmp & 0x01) )
-        {
-            common_pts_len++;
-            tmp >>= 1;
-        }
-        perms = &cladatum->comdatum->permissions;
-        for ( j = 0; j < common_pts_len; j++ )
-        {
-            def_perm = kdefs->av_inherit[i].common_pts[j];
-            if ( j >= perms->nprim )
-            {
-                printk(KERN_INFO
-                "Flask:  permission %s in class %s not defined in policy\n",
-                       def_perm, pol_class);
-                return -EINVAL;
-            }
-            perdatum = hashtab_search(perms->table, def_perm);
-            if ( perdatum == NULL )
-            {
-                printk(KERN_ERR
-                       "Flask:  permission %s in class %s not found in policy\n",
-                       def_perm, pol_class);
-                return -EINVAL;
-            }
-            if ( perdatum->value != j + 1 )
-            {
-                printk(KERN_ERR
-                      "Flask:  permission %s in class %s has incorrect value\n",
-                       def_perm, pol_class);
-                return -EINVAL;
-            }
-        }
-    }
     return 0;
 }
 
-- 
1.7.11.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 17 15:24:22 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 15:24:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDdBA-0003bu-TC; Mon, 17 Sep 2012 15:24:08 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1TDdB8-0003aI-N0
	for xen-devel@lists.xen.org; Mon, 17 Sep 2012 15:24:07 +0000
Received: from [85.158.139.211:51644] by server-5.bemta-5.messagelabs.com id
	50/F2-30514-59047505; Mon, 17 Sep 2012 15:24:05 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-2.tower-206.messagelabs.com!1347895444!18880324!1
X-Originating-IP: [63.239.67.9]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29582 invoked from network); 17 Sep 2012 15:24:04 -0000
Received: from emvm-gh1-uea08.nsa.gov (HELO nsa.gov) (63.239.67.9)
	by server-2.tower-206.messagelabs.com with SMTP;
	17 Sep 2012 15:24:04 -0000
X-TM-IMSS-Message-ID: <538034710012acd0@nsa.gov>
Received: from tarius.tycho.ncsc.mil ([144.51.3.1]) by nsa.gov ([63.239.67.9])
	with ESMTP (TREND IMSS SMTP Service 7.1) id 538034710012acd0 ;
	Mon, 17 Sep 2012 11:23:43 -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 q8HFO0xX027504; 
	Mon, 17 Sep 2012 11:24:02 -0400
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xen.org
Date: Mon, 17 Sep 2012 11:23:29 -0400
Message-Id: <1347895425-17959-8-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.11.4
In-Reply-To: <1347895425-17959-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1347895425-17959-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: dgdegra@tycho.nsa.gov, keir@xen.org, Jan Beulich <jbeulich@suse.com>
Subject: [Xen-devel] [PATCH 07/23] arch/x86: add distinct XSM hooks for
	map/unmap
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 xsm_iomem_permission and xsm_ioport_permission hooks are intended to
be called by the domain builder, while the calls in arch/x86/domctl.c
which control mapping are also performed by the device model. Because of
this, they should not use the same XSM hooks.

This also adds a missing XSM hook in the unbind IRQ domctl.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Cc: Keir Fraser <keir@xen.org>
Cc: Jan Beulich <jbeulich@suse.com>
---
 xen/arch/x86/domctl.c  |  8 ++++++--
 xen/arch/x86/physdev.c |  2 +-
 xen/include/xsm/xsm.h  | 25 ++++++++++++++++++++++---
 xen/xsm/dummy.c        | 20 +++++++++++++++++++-
 xen/xsm/flask/hooks.c  | 42 ++++++++++++++++++++----------------------
 5 files changed, 68 insertions(+), 29 deletions(-)

diff --git a/xen/arch/x86/domctl.c b/xen/arch/x86/domctl.c
index f4e5705..da70e35 100644
--- a/xen/arch/x86/domctl.c
+++ b/xen/arch/x86/domctl.c
@@ -803,6 +803,10 @@ long arch_do_domctl(
              !irq_access_permitted(current->domain, bind->machine_irq) )
             goto unbind_out;
 
+        ret = xsm_unbind_pt_irq(d, bind);
+        if ( ret )
+            goto unbind_out;
+
         if ( iommu_enabled )
         {
             spin_lock(&pcidevs_lock);
@@ -840,7 +844,7 @@ long arch_do_domctl(
         if ( unlikely((d = rcu_lock_domain_by_id(domctl->domain)) == NULL) )
             break;
 
-        ret = xsm_iomem_permission(d, mfn, mfn + nr_mfns - 1, add);
+        ret = xsm_iomem_mapping(d, mfn, mfn + nr_mfns - 1, add);
         if ( ret ) {
             rcu_unlock_domain(d);
             break;
@@ -902,7 +906,7 @@ long arch_do_domctl(
         if ( unlikely((d = rcu_lock_domain_by_id(domctl->domain)) == NULL) )
             break;
 
-        ret = xsm_ioport_permission(d, fmp, fmp + np - 1, add);
+        ret = xsm_ioport_mapping(d, fmp, fmp + np - 1, add);
         if ( ret ) {
             rcu_unlock_domain(d);
             break;
diff --git a/xen/arch/x86/physdev.c b/xen/arch/x86/physdev.c
index 984c813..13b85da 100644
--- a/xen/arch/x86/physdev.c
+++ b/xen/arch/x86/physdev.c
@@ -242,7 +242,7 @@ int physdev_unmap_pirq(domid_t domid, int pirq)
     if ( !IS_PRIV_FOR(current->domain, d) )
         goto free_domain;
 
-    ret = xsm_irq_permission(d, domain_pirq_to_irq(d, pirq), 0);
+    ret = xsm_unmap_domain_pirq(d, domain_pirq_to_irq(d, pirq));
     if ( ret )
         goto free_domain;
 
diff --git a/xen/include/xsm/xsm.h b/xen/include/xsm/xsm.h
index 593cdbd..cbbe673 100644
--- a/xen/include/xsm/xsm.h
+++ b/xen/include/xsm/xsm.h
@@ -117,8 +117,10 @@ struct xsm_operations {
 
     char *(*show_irq_sid) (int irq);
     int (*map_domain_pirq) (struct domain *d, int irq, void *data);
+    int (*unmap_domain_pirq) (struct domain *d, int irq);
     int (*irq_permission) (struct domain *d, int pirq, uint8_t allow);
     int (*iomem_permission) (struct domain *d, uint64_t s, uint64_t e, uint8_t allow);
+    int (*iomem_mapping) (struct domain *d, uint64_t s, uint64_t e, uint8_t allow);
     int (*pci_config_permission) (struct domain *d, uint32_t machine_bdf, uint16_t start, uint16_t end, uint8_t access);
 
     int (*get_device_group) (uint32_t machine_bdf);
@@ -176,11 +178,12 @@ struct xsm_operations {
     int (*add_to_physmap) (struct domain *d1, struct domain *d2);
     int (*sendtrigger) (struct domain *d);
     int (*bind_pt_irq) (struct domain *d, struct xen_domctl_bind_pt_irq *bind);
-    int (*unbind_pt_irq) (struct domain *d);
+    int (*unbind_pt_irq) (struct domain *d, struct xen_domctl_bind_pt_irq *bind);
     int (*pin_mem_cacheattr) (struct domain *d);
     int (*ext_vcpucontext) (struct domain *d, uint32_t cmd);
     int (*vcpuextstate) (struct domain *d, uint32_t cmd);
     int (*ioport_permission) (struct domain *d, uint32_t s, uint32_t e, uint8_t allow);
+    int (*ioport_mapping) (struct domain *d, uint32_t s, uint32_t e, uint8_t allow);
 #endif
 };
 
@@ -495,6 +498,11 @@ static inline int xsm_map_domain_pirq (struct domain *d, int irq, void *data)
     return xsm_call(map_domain_pirq(d, irq, data));
 }
 
+static inline int xsm_unmap_domain_pirq (struct domain *d, int irq)
+{
+    return xsm_call(unmap_domain_pirq(d, irq));
+}
+
 static inline int xsm_irq_permission (struct domain *d, int pirq, uint8_t allow)
 {
     return xsm_call(irq_permission(d, pirq, allow));
@@ -505,6 +513,11 @@ static inline int xsm_iomem_permission (struct domain *d, uint64_t s, uint64_t e
     return xsm_call(iomem_permission(d, s, e, allow));
 }
 
+static inline int xsm_iomem_mapping (struct domain *d, uint64_t s, uint64_t e, uint8_t allow)
+{
+    return xsm_call(iomem_mapping(d, s, e, allow));
+}
+
 static inline int xsm_pci_config_permission (struct domain *d, uint32_t machine_bdf, uint16_t start, uint16_t end, uint8_t access)
 {
     return xsm_call(pci_config_permission(d, machine_bdf, start, end, access));
@@ -781,9 +794,10 @@ static inline int xsm_bind_pt_irq(struct domain *d,
     return xsm_call(bind_pt_irq(d, bind));
 }
 
-static inline int xsm_unbind_pt_irq(struct domain *d)
+static inline int xsm_unbind_pt_irq(struct domain *d,
+                                                struct xen_domctl_bind_pt_irq *bind)
 {
-    return xsm_call(unbind_pt_irq(d));
+    return xsm_call(unbind_pt_irq(d, bind));
 }
 
 static inline int xsm_pin_mem_cacheattr(struct domain *d)
@@ -804,6 +818,11 @@ static inline int xsm_ioport_permission (struct domain *d, uint32_t s, uint32_t
 {
     return xsm_call(ioport_permission(d, s, e, allow));
 }
+
+static inline int xsm_ioport_mapping (struct domain *d, uint32_t s, uint32_t e, uint8_t allow)
+{
+    return xsm_call(ioport_mapping(d, s, e, allow));
+}
 #endif /* CONFIG_X86 */
 
 extern struct xsm_operations dummy_xsm_ops;
diff --git a/xen/xsm/dummy.c b/xen/xsm/dummy.c
index 4836fc0..a5dbfe7 100644
--- a/xen/xsm/dummy.c
+++ b/xen/xsm/dummy.c
@@ -395,6 +395,11 @@ static int dummy_map_domain_pirq (struct domain *d, int irq, void *data)
     return 0;
 }
 
+static int dummy_unmap_domain_pirq (struct domain *d, int irq)
+{
+    return 0;
+}
+
 static int dummy_irq_permission (struct domain *d, int pirq, uint8_t allow)
 {
     return 0;
@@ -405,6 +410,11 @@ static int dummy_iomem_permission (struct domain *d, uint64_t s, uint64_t e, uin
     return 0;
 }
 
+static int dummy_iomem_mapping (struct domain *d, uint64_t s, uint64_t e, uint8_t allow)
+{
+    return 0;
+}
+
 static int dummy_pci_config_permission (struct domain *d, uint32_t machine_bdf,
                                         uint16_t start, uint16_t end,
                                         uint8_t access)
@@ -585,7 +595,7 @@ static int dummy_bind_pt_irq (struct domain *d, struct xen_domctl_bind_pt_irq *b
     return 0;
 }
 
-static int dummy_unbind_pt_irq (struct domain *d)
+static int dummy_unbind_pt_irq (struct domain *d, struct xen_domctl_bind_pt_irq *bind)
 {
     return 0;
 }
@@ -609,6 +619,11 @@ static int dummy_ioport_permission (struct domain *d, uint32_t s, uint32_t e, ui
 {
     return 0;
 }
+
+static int dummy_ioport_mapping (struct domain *d, uint32_t s, uint32_t e, uint8_t allow)
+{
+    return 0;
+}
 #endif
 
 struct xsm_operations dummy_xsm_ops;
@@ -693,8 +708,10 @@ void xsm_fixup_ops (struct xsm_operations *ops)
 
     set_to_dummy_if_null(ops, show_irq_sid);
     set_to_dummy_if_null(ops, map_domain_pirq);
+    set_to_dummy_if_null(ops, unmap_domain_pirq);
     set_to_dummy_if_null(ops, irq_permission);
     set_to_dummy_if_null(ops, iomem_permission);
+    set_to_dummy_if_null(ops, iomem_mapping);
     set_to_dummy_if_null(ops, pci_config_permission);
 
     set_to_dummy_if_null(ops, get_device_group);
@@ -757,5 +774,6 @@ void xsm_fixup_ops (struct xsm_operations *ops)
     set_to_dummy_if_null(ops, ext_vcpucontext);
     set_to_dummy_if_null(ops, vcpuextstate);
     set_to_dummy_if_null(ops, ioport_permission);
+    set_to_dummy_if_null(ops, ioport_mapping);
 #endif
 }
diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
index 88fef9c..74c9271 100644
--- a/xen/xsm/flask/hooks.c
+++ b/xen/xsm/flask/hooks.c
@@ -721,43 +721,40 @@ static int flask_map_domain_pirq (struct domain *d, int irq, void *data)
     return rc;
 }
 
-static int flask_irq_permission (struct domain *d, int irq, uint8_t access)
+static int flask_unmap_domain_pirq (struct domain *d, int irq)
 {
-    u32 perm;
-    u32 rsid;
+    u32 sid;
     int rc = -EPERM;
 
-    struct domain_security_struct *ssec, *tsec;
+    struct domain_security_struct *ssec;
     struct avc_audit_data ad;
 
-    rc = domain_has_perm(current->domain, d, SECCLASS_RESOURCE,
-                         resource_to_perm(access));
-
+    rc = domain_has_perm(current->domain, d, SECCLASS_RESOURCE, RESOURCE__REMOVE);
     if ( rc )
         return rc;
 
-    if ( access )
-        perm = RESOURCE__ADD_IRQ;
-    else
-        perm = RESOURCE__REMOVE_IRQ;
-
     ssec = current->domain->ssid;
-    tsec = d->ssid;
 
-    rc = get_irq_sid(irq, &rsid, &ad);
-    if ( rc )
-        return rc;
-
-    rc = avc_has_perm(ssec->sid, rsid, SECCLASS_RESOURCE, perm, &ad);
+    if ( irq >= nr_irqs_gsi ) {
+        /* TODO support for MSI here */
+        return 0;
+    } else {
+        rc = get_irq_sid(irq, &sid, &ad);
+    }
     if ( rc )
         return rc;
 
-    if ( access )
-        rc = avc_has_perm(tsec->sid, rsid, SECCLASS_RESOURCE, 
-                            RESOURCE__USE, &ad);
+    rc = avc_has_perm(ssec->sid, sid, SECCLASS_RESOURCE, RESOURCE__REMOVE_IRQ, &ad);
     return rc;
 }
 
+static int flask_irq_permission (struct domain *d, int pirq, uint8_t access)
+{
+    /* the PIRQ number is not useful; real IRQ is checked during mapping */
+    return domain_has_perm(current->domain, d, SECCLASS_RESOURCE,
+                           resource_to_perm(access));
+}
+
 struct iomem_has_perm_data {
     struct domain_security_struct *ssec, *tsec;
     u32 perm;
@@ -1413,7 +1410,7 @@ static int flask_bind_pt_irq (struct domain *d, struct xen_domctl_bind_pt_irq *b
     return avc_has_perm(tsec->sid, rsid, SECCLASS_RESOURCE, RESOURCE__USE, &ad);
 }
 
-static int flask_unbind_pt_irq (struct domain *d)
+static int flask_unbind_pt_irq (struct domain *d, struct xen_domctl_bind_pt_irq *bind)
 {
     return domain_has_perm(current->domain, d, SECCLASS_RESOURCE, RESOURCE__REMOVE);
 }
@@ -1533,6 +1530,7 @@ static struct xsm_operations flask_ops = {
     .show_irq_sid = flask_show_irq_sid,
 
     .map_domain_pirq = flask_map_domain_pirq,
+    .unmap_domain_pirq = flask_unmap_domain_pirq,
     .irq_permission = flask_irq_permission,
     .iomem_permission = flask_iomem_permission,
     .pci_config_permission = flask_pci_config_permission,
-- 
1.7.11.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 17 15:24:22 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 15:24:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDdBA-0003bu-TC; Mon, 17 Sep 2012 15:24:08 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1TDdB8-0003aI-N0
	for xen-devel@lists.xen.org; Mon, 17 Sep 2012 15:24:07 +0000
Received: from [85.158.139.211:51644] by server-5.bemta-5.messagelabs.com id
	50/F2-30514-59047505; Mon, 17 Sep 2012 15:24:05 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-2.tower-206.messagelabs.com!1347895444!18880324!1
X-Originating-IP: [63.239.67.9]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29582 invoked from network); 17 Sep 2012 15:24:04 -0000
Received: from emvm-gh1-uea08.nsa.gov (HELO nsa.gov) (63.239.67.9)
	by server-2.tower-206.messagelabs.com with SMTP;
	17 Sep 2012 15:24:04 -0000
X-TM-IMSS-Message-ID: <538034710012acd0@nsa.gov>
Received: from tarius.tycho.ncsc.mil ([144.51.3.1]) by nsa.gov ([63.239.67.9])
	with ESMTP (TREND IMSS SMTP Service 7.1) id 538034710012acd0 ;
	Mon, 17 Sep 2012 11:23:43 -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 q8HFO0xX027504; 
	Mon, 17 Sep 2012 11:24:02 -0400
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xen.org
Date: Mon, 17 Sep 2012 11:23:29 -0400
Message-Id: <1347895425-17959-8-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.11.4
In-Reply-To: <1347895425-17959-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1347895425-17959-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: dgdegra@tycho.nsa.gov, keir@xen.org, Jan Beulich <jbeulich@suse.com>
Subject: [Xen-devel] [PATCH 07/23] arch/x86: add distinct XSM hooks for
	map/unmap
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 xsm_iomem_permission and xsm_ioport_permission hooks are intended to
be called by the domain builder, while the calls in arch/x86/domctl.c
which control mapping are also performed by the device model. Because of
this, they should not use the same XSM hooks.

This also adds a missing XSM hook in the unbind IRQ domctl.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Cc: Keir Fraser <keir@xen.org>
Cc: Jan Beulich <jbeulich@suse.com>
---
 xen/arch/x86/domctl.c  |  8 ++++++--
 xen/arch/x86/physdev.c |  2 +-
 xen/include/xsm/xsm.h  | 25 ++++++++++++++++++++++---
 xen/xsm/dummy.c        | 20 +++++++++++++++++++-
 xen/xsm/flask/hooks.c  | 42 ++++++++++++++++++++----------------------
 5 files changed, 68 insertions(+), 29 deletions(-)

diff --git a/xen/arch/x86/domctl.c b/xen/arch/x86/domctl.c
index f4e5705..da70e35 100644
--- a/xen/arch/x86/domctl.c
+++ b/xen/arch/x86/domctl.c
@@ -803,6 +803,10 @@ long arch_do_domctl(
              !irq_access_permitted(current->domain, bind->machine_irq) )
             goto unbind_out;
 
+        ret = xsm_unbind_pt_irq(d, bind);
+        if ( ret )
+            goto unbind_out;
+
         if ( iommu_enabled )
         {
             spin_lock(&pcidevs_lock);
@@ -840,7 +844,7 @@ long arch_do_domctl(
         if ( unlikely((d = rcu_lock_domain_by_id(domctl->domain)) == NULL) )
             break;
 
-        ret = xsm_iomem_permission(d, mfn, mfn + nr_mfns - 1, add);
+        ret = xsm_iomem_mapping(d, mfn, mfn + nr_mfns - 1, add);
         if ( ret ) {
             rcu_unlock_domain(d);
             break;
@@ -902,7 +906,7 @@ long arch_do_domctl(
         if ( unlikely((d = rcu_lock_domain_by_id(domctl->domain)) == NULL) )
             break;
 
-        ret = xsm_ioport_permission(d, fmp, fmp + np - 1, add);
+        ret = xsm_ioport_mapping(d, fmp, fmp + np - 1, add);
         if ( ret ) {
             rcu_unlock_domain(d);
             break;
diff --git a/xen/arch/x86/physdev.c b/xen/arch/x86/physdev.c
index 984c813..13b85da 100644
--- a/xen/arch/x86/physdev.c
+++ b/xen/arch/x86/physdev.c
@@ -242,7 +242,7 @@ int physdev_unmap_pirq(domid_t domid, int pirq)
     if ( !IS_PRIV_FOR(current->domain, d) )
         goto free_domain;
 
-    ret = xsm_irq_permission(d, domain_pirq_to_irq(d, pirq), 0);
+    ret = xsm_unmap_domain_pirq(d, domain_pirq_to_irq(d, pirq));
     if ( ret )
         goto free_domain;
 
diff --git a/xen/include/xsm/xsm.h b/xen/include/xsm/xsm.h
index 593cdbd..cbbe673 100644
--- a/xen/include/xsm/xsm.h
+++ b/xen/include/xsm/xsm.h
@@ -117,8 +117,10 @@ struct xsm_operations {
 
     char *(*show_irq_sid) (int irq);
     int (*map_domain_pirq) (struct domain *d, int irq, void *data);
+    int (*unmap_domain_pirq) (struct domain *d, int irq);
     int (*irq_permission) (struct domain *d, int pirq, uint8_t allow);
     int (*iomem_permission) (struct domain *d, uint64_t s, uint64_t e, uint8_t allow);
+    int (*iomem_mapping) (struct domain *d, uint64_t s, uint64_t e, uint8_t allow);
     int (*pci_config_permission) (struct domain *d, uint32_t machine_bdf, uint16_t start, uint16_t end, uint8_t access);
 
     int (*get_device_group) (uint32_t machine_bdf);
@@ -176,11 +178,12 @@ struct xsm_operations {
     int (*add_to_physmap) (struct domain *d1, struct domain *d2);
     int (*sendtrigger) (struct domain *d);
     int (*bind_pt_irq) (struct domain *d, struct xen_domctl_bind_pt_irq *bind);
-    int (*unbind_pt_irq) (struct domain *d);
+    int (*unbind_pt_irq) (struct domain *d, struct xen_domctl_bind_pt_irq *bind);
     int (*pin_mem_cacheattr) (struct domain *d);
     int (*ext_vcpucontext) (struct domain *d, uint32_t cmd);
     int (*vcpuextstate) (struct domain *d, uint32_t cmd);
     int (*ioport_permission) (struct domain *d, uint32_t s, uint32_t e, uint8_t allow);
+    int (*ioport_mapping) (struct domain *d, uint32_t s, uint32_t e, uint8_t allow);
 #endif
 };
 
@@ -495,6 +498,11 @@ static inline int xsm_map_domain_pirq (struct domain *d, int irq, void *data)
     return xsm_call(map_domain_pirq(d, irq, data));
 }
 
+static inline int xsm_unmap_domain_pirq (struct domain *d, int irq)
+{
+    return xsm_call(unmap_domain_pirq(d, irq));
+}
+
 static inline int xsm_irq_permission (struct domain *d, int pirq, uint8_t allow)
 {
     return xsm_call(irq_permission(d, pirq, allow));
@@ -505,6 +513,11 @@ static inline int xsm_iomem_permission (struct domain *d, uint64_t s, uint64_t e
     return xsm_call(iomem_permission(d, s, e, allow));
 }
 
+static inline int xsm_iomem_mapping (struct domain *d, uint64_t s, uint64_t e, uint8_t allow)
+{
+    return xsm_call(iomem_mapping(d, s, e, allow));
+}
+
 static inline int xsm_pci_config_permission (struct domain *d, uint32_t machine_bdf, uint16_t start, uint16_t end, uint8_t access)
 {
     return xsm_call(pci_config_permission(d, machine_bdf, start, end, access));
@@ -781,9 +794,10 @@ static inline int xsm_bind_pt_irq(struct domain *d,
     return xsm_call(bind_pt_irq(d, bind));
 }
 
-static inline int xsm_unbind_pt_irq(struct domain *d)
+static inline int xsm_unbind_pt_irq(struct domain *d,
+                                                struct xen_domctl_bind_pt_irq *bind)
 {
-    return xsm_call(unbind_pt_irq(d));
+    return xsm_call(unbind_pt_irq(d, bind));
 }
 
 static inline int xsm_pin_mem_cacheattr(struct domain *d)
@@ -804,6 +818,11 @@ static inline int xsm_ioport_permission (struct domain *d, uint32_t s, uint32_t
 {
     return xsm_call(ioport_permission(d, s, e, allow));
 }
+
+static inline int xsm_ioport_mapping (struct domain *d, uint32_t s, uint32_t e, uint8_t allow)
+{
+    return xsm_call(ioport_mapping(d, s, e, allow));
+}
 #endif /* CONFIG_X86 */
 
 extern struct xsm_operations dummy_xsm_ops;
diff --git a/xen/xsm/dummy.c b/xen/xsm/dummy.c
index 4836fc0..a5dbfe7 100644
--- a/xen/xsm/dummy.c
+++ b/xen/xsm/dummy.c
@@ -395,6 +395,11 @@ static int dummy_map_domain_pirq (struct domain *d, int irq, void *data)
     return 0;
 }
 
+static int dummy_unmap_domain_pirq (struct domain *d, int irq)
+{
+    return 0;
+}
+
 static int dummy_irq_permission (struct domain *d, int pirq, uint8_t allow)
 {
     return 0;
@@ -405,6 +410,11 @@ static int dummy_iomem_permission (struct domain *d, uint64_t s, uint64_t e, uin
     return 0;
 }
 
+static int dummy_iomem_mapping (struct domain *d, uint64_t s, uint64_t e, uint8_t allow)
+{
+    return 0;
+}
+
 static int dummy_pci_config_permission (struct domain *d, uint32_t machine_bdf,
                                         uint16_t start, uint16_t end,
                                         uint8_t access)
@@ -585,7 +595,7 @@ static int dummy_bind_pt_irq (struct domain *d, struct xen_domctl_bind_pt_irq *b
     return 0;
 }
 
-static int dummy_unbind_pt_irq (struct domain *d)
+static int dummy_unbind_pt_irq (struct domain *d, struct xen_domctl_bind_pt_irq *bind)
 {
     return 0;
 }
@@ -609,6 +619,11 @@ static int dummy_ioport_permission (struct domain *d, uint32_t s, uint32_t e, ui
 {
     return 0;
 }
+
+static int dummy_ioport_mapping (struct domain *d, uint32_t s, uint32_t e, uint8_t allow)
+{
+    return 0;
+}
 #endif
 
 struct xsm_operations dummy_xsm_ops;
@@ -693,8 +708,10 @@ void xsm_fixup_ops (struct xsm_operations *ops)
 
     set_to_dummy_if_null(ops, show_irq_sid);
     set_to_dummy_if_null(ops, map_domain_pirq);
+    set_to_dummy_if_null(ops, unmap_domain_pirq);
     set_to_dummy_if_null(ops, irq_permission);
     set_to_dummy_if_null(ops, iomem_permission);
+    set_to_dummy_if_null(ops, iomem_mapping);
     set_to_dummy_if_null(ops, pci_config_permission);
 
     set_to_dummy_if_null(ops, get_device_group);
@@ -757,5 +774,6 @@ void xsm_fixup_ops (struct xsm_operations *ops)
     set_to_dummy_if_null(ops, ext_vcpucontext);
     set_to_dummy_if_null(ops, vcpuextstate);
     set_to_dummy_if_null(ops, ioport_permission);
+    set_to_dummy_if_null(ops, ioport_mapping);
 #endif
 }
diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
index 88fef9c..74c9271 100644
--- a/xen/xsm/flask/hooks.c
+++ b/xen/xsm/flask/hooks.c
@@ -721,43 +721,40 @@ static int flask_map_domain_pirq (struct domain *d, int irq, void *data)
     return rc;
 }
 
-static int flask_irq_permission (struct domain *d, int irq, uint8_t access)
+static int flask_unmap_domain_pirq (struct domain *d, int irq)
 {
-    u32 perm;
-    u32 rsid;
+    u32 sid;
     int rc = -EPERM;
 
-    struct domain_security_struct *ssec, *tsec;
+    struct domain_security_struct *ssec;
     struct avc_audit_data ad;
 
-    rc = domain_has_perm(current->domain, d, SECCLASS_RESOURCE,
-                         resource_to_perm(access));
-
+    rc = domain_has_perm(current->domain, d, SECCLASS_RESOURCE, RESOURCE__REMOVE);
     if ( rc )
         return rc;
 
-    if ( access )
-        perm = RESOURCE__ADD_IRQ;
-    else
-        perm = RESOURCE__REMOVE_IRQ;
-
     ssec = current->domain->ssid;
-    tsec = d->ssid;
 
-    rc = get_irq_sid(irq, &rsid, &ad);
-    if ( rc )
-        return rc;
-
-    rc = avc_has_perm(ssec->sid, rsid, SECCLASS_RESOURCE, perm, &ad);
+    if ( irq >= nr_irqs_gsi ) {
+        /* TODO support for MSI here */
+        return 0;
+    } else {
+        rc = get_irq_sid(irq, &sid, &ad);
+    }
     if ( rc )
         return rc;
 
-    if ( access )
-        rc = avc_has_perm(tsec->sid, rsid, SECCLASS_RESOURCE, 
-                            RESOURCE__USE, &ad);
+    rc = avc_has_perm(ssec->sid, sid, SECCLASS_RESOURCE, RESOURCE__REMOVE_IRQ, &ad);
     return rc;
 }
 
+static int flask_irq_permission (struct domain *d, int pirq, uint8_t access)
+{
+    /* the PIRQ number is not useful; real IRQ is checked during mapping */
+    return domain_has_perm(current->domain, d, SECCLASS_RESOURCE,
+                           resource_to_perm(access));
+}
+
 struct iomem_has_perm_data {
     struct domain_security_struct *ssec, *tsec;
     u32 perm;
@@ -1413,7 +1410,7 @@ static int flask_bind_pt_irq (struct domain *d, struct xen_domctl_bind_pt_irq *b
     return avc_has_perm(tsec->sid, rsid, SECCLASS_RESOURCE, RESOURCE__USE, &ad);
 }
 
-static int flask_unbind_pt_irq (struct domain *d)
+static int flask_unbind_pt_irq (struct domain *d, struct xen_domctl_bind_pt_irq *bind)
 {
     return domain_has_perm(current->domain, d, SECCLASS_RESOURCE, RESOURCE__REMOVE);
 }
@@ -1533,6 +1530,7 @@ static struct xsm_operations flask_ops = {
     .show_irq_sid = flask_show_irq_sid,
 
     .map_domain_pirq = flask_map_domain_pirq,
+    .unmap_domain_pirq = flask_unmap_domain_pirq,
     .irq_permission = flask_irq_permission,
     .iomem_permission = flask_iomem_permission,
     .pci_config_permission = flask_pci_config_permission,
-- 
1.7.11.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 17 15:24:23 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 15:24:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDdBG-0003hI-2J; Mon, 17 Sep 2012 15:24:14 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1TDdBD-0003Zw-7y
	for xen-devel@lists.xen.org; Mon, 17 Sep 2012 15:24:11 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-8.tower-27.messagelabs.com!1347895443!11366086!1
X-Originating-IP: [63.239.67.10]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9715 invoked from network); 17 Sep 2012 15:24:04 -0000
Received: from emvm-gh1-uea09.nsa.gov (HELO nsa.gov) (63.239.67.10)
	by server-8.tower-27.messagelabs.com with SMTP;
	17 Sep 2012 15:24:03 -0000
X-TM-IMSS-Message-ID: <537fef4700131d76@nsa.gov>
Received: from tarius.tycho.ncsc.mil ([144.51.3.1]) by nsa.gov
	([63.239.67.10]) with ESMTP (TREND IMSS SMTP Service 7.1) id
	537fef4700131d76 ; Mon, 17 Sep 2012 11:25:59 -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 q8HFO0xY027504; 
	Mon, 17 Sep 2012 11:24:02 -0400
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xen.org
Date: Mon, 17 Sep 2012 11:23:30 -0400
Message-Id: <1347895425-17959-9-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.11.4
In-Reply-To: <1347895425-17959-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1347895425-17959-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: dgdegra@tycho.nsa.gov, keir@xen.org
Subject: [Xen-devel] [PATCH 08/23] xsm/flask: Add checks on the domain
	performing the set_target 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>
MIME-Version: 1.0
Content-Type: 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 existing domain__set_target check only verifies that the source and
target domains can be associated. We also need to check that the
privileged domain making this association is allowed to do so.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 tools/flask/policy/policy/flask/access_vectors | 2 ++
 xen/xsm/flask/hooks.c                          | 7 +++++++
 xen/xsm/flask/include/av_perm_to_string.h      | 2 ++
 xen/xsm/flask/include/av_permissions.h         | 2 ++
 4 files changed, 13 insertions(+)

diff --git a/tools/flask/policy/policy/flask/access_vectors b/tools/flask/policy/policy/flask/access_vectors
index c7e29ab..11d02da 100644
--- a/tools/flask/policy/policy/flask/access_vectors
+++ b/tools/flask/policy/policy/flask/access_vectors
@@ -78,6 +78,8 @@ class domain2
 	relabelfrom
 	relabelto
 	relabelself
+	make_priv_for
+	set_as_target
 }
 
 class hvm
diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
index 74c9271..6d4b4f0 100644
--- a/xen/xsm/flask/hooks.c
+++ b/xen/xsm/flask/hooks.c
@@ -577,6 +577,13 @@ static int flask_domain_settime(struct domain *d)
 
 static int flask_set_target(struct domain *d, struct domain *e)
 {
+    int rc;
+    rc = domain_has_perm(current->domain, d, SECCLASS_DOMAIN2, DOMAIN2__MAKE_PRIV_FOR);
+    if ( rc )
+        return rc;
+    rc = domain_has_perm(current->domain, e, SECCLASS_DOMAIN2, DOMAIN2__SET_AS_TARGET);
+    if ( rc )
+        return rc;
     return domain_has_perm(d, e, SECCLASS_DOMAIN, DOMAIN__SET_TARGET);
 }
 
diff --git a/xen/xsm/flask/include/av_perm_to_string.h b/xen/xsm/flask/include/av_perm_to_string.h
index e7e2058..10f8e80 100644
--- a/xen/xsm/flask/include/av_perm_to_string.h
+++ b/xen/xsm/flask/include/av_perm_to_string.h
@@ -64,6 +64,8 @@
    S_(SECCLASS_DOMAIN2, DOMAIN2__RELABELFROM, "relabelfrom")
    S_(SECCLASS_DOMAIN2, DOMAIN2__RELABELTO, "relabelto")
    S_(SECCLASS_DOMAIN2, DOMAIN2__RELABELSELF, "relabelself")
+   S_(SECCLASS_DOMAIN2, DOMAIN2__MAKE_PRIV_FOR, "make_priv_for")
+   S_(SECCLASS_DOMAIN2, DOMAIN2__SET_AS_TARGET, "set_as_target")
    S_(SECCLASS_HVM, HVM__SETHVMC, "sethvmc")
    S_(SECCLASS_HVM, HVM__GETHVMC, "gethvmc")
    S_(SECCLASS_HVM, HVM__SETPARAM, "setparam")
diff --git a/xen/xsm/flask/include/av_permissions.h b/xen/xsm/flask/include/av_permissions.h
index cb1c5dc..f7cfee1 100644
--- a/xen/xsm/flask/include/av_permissions.h
+++ b/xen/xsm/flask/include/av_permissions.h
@@ -66,6 +66,8 @@
 #define DOMAIN2__RELABELFROM                      0x00000001UL
 #define DOMAIN2__RELABELTO                        0x00000002UL
 #define DOMAIN2__RELABELSELF                      0x00000004UL
+#define DOMAIN2__MAKE_PRIV_FOR                    0x00000008UL
+#define DOMAIN2__SET_AS_TARGET                    0x00000010UL
 
 #define HVM__SETHVMC                              0x00000001UL
 #define HVM__GETHVMC                              0x00000002UL
-- 
1.7.11.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 17 15:24:23 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 15:24:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDdBG-0003hI-2J; Mon, 17 Sep 2012 15:24:14 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1TDdBD-0003Zw-7y
	for xen-devel@lists.xen.org; Mon, 17 Sep 2012 15:24:11 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-8.tower-27.messagelabs.com!1347895443!11366086!1
X-Originating-IP: [63.239.67.10]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9715 invoked from network); 17 Sep 2012 15:24:04 -0000
Received: from emvm-gh1-uea09.nsa.gov (HELO nsa.gov) (63.239.67.10)
	by server-8.tower-27.messagelabs.com with SMTP;
	17 Sep 2012 15:24:03 -0000
X-TM-IMSS-Message-ID: <537fef4700131d76@nsa.gov>
Received: from tarius.tycho.ncsc.mil ([144.51.3.1]) by nsa.gov
	([63.239.67.10]) with ESMTP (TREND IMSS SMTP Service 7.1) id
	537fef4700131d76 ; Mon, 17 Sep 2012 11:25:59 -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 q8HFO0xY027504; 
	Mon, 17 Sep 2012 11:24:02 -0400
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xen.org
Date: Mon, 17 Sep 2012 11:23:30 -0400
Message-Id: <1347895425-17959-9-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.11.4
In-Reply-To: <1347895425-17959-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1347895425-17959-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: dgdegra@tycho.nsa.gov, keir@xen.org
Subject: [Xen-devel] [PATCH 08/23] xsm/flask: Add checks on the domain
	performing the set_target 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>
MIME-Version: 1.0
Content-Type: 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 existing domain__set_target check only verifies that the source and
target domains can be associated. We also need to check that the
privileged domain making this association is allowed to do so.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 tools/flask/policy/policy/flask/access_vectors | 2 ++
 xen/xsm/flask/hooks.c                          | 7 +++++++
 xen/xsm/flask/include/av_perm_to_string.h      | 2 ++
 xen/xsm/flask/include/av_permissions.h         | 2 ++
 4 files changed, 13 insertions(+)

diff --git a/tools/flask/policy/policy/flask/access_vectors b/tools/flask/policy/policy/flask/access_vectors
index c7e29ab..11d02da 100644
--- a/tools/flask/policy/policy/flask/access_vectors
+++ b/tools/flask/policy/policy/flask/access_vectors
@@ -78,6 +78,8 @@ class domain2
 	relabelfrom
 	relabelto
 	relabelself
+	make_priv_for
+	set_as_target
 }
 
 class hvm
diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
index 74c9271..6d4b4f0 100644
--- a/xen/xsm/flask/hooks.c
+++ b/xen/xsm/flask/hooks.c
@@ -577,6 +577,13 @@ static int flask_domain_settime(struct domain *d)
 
 static int flask_set_target(struct domain *d, struct domain *e)
 {
+    int rc;
+    rc = domain_has_perm(current->domain, d, SECCLASS_DOMAIN2, DOMAIN2__MAKE_PRIV_FOR);
+    if ( rc )
+        return rc;
+    rc = domain_has_perm(current->domain, e, SECCLASS_DOMAIN2, DOMAIN2__SET_AS_TARGET);
+    if ( rc )
+        return rc;
     return domain_has_perm(d, e, SECCLASS_DOMAIN, DOMAIN__SET_TARGET);
 }
 
diff --git a/xen/xsm/flask/include/av_perm_to_string.h b/xen/xsm/flask/include/av_perm_to_string.h
index e7e2058..10f8e80 100644
--- a/xen/xsm/flask/include/av_perm_to_string.h
+++ b/xen/xsm/flask/include/av_perm_to_string.h
@@ -64,6 +64,8 @@
    S_(SECCLASS_DOMAIN2, DOMAIN2__RELABELFROM, "relabelfrom")
    S_(SECCLASS_DOMAIN2, DOMAIN2__RELABELTO, "relabelto")
    S_(SECCLASS_DOMAIN2, DOMAIN2__RELABELSELF, "relabelself")
+   S_(SECCLASS_DOMAIN2, DOMAIN2__MAKE_PRIV_FOR, "make_priv_for")
+   S_(SECCLASS_DOMAIN2, DOMAIN2__SET_AS_TARGET, "set_as_target")
    S_(SECCLASS_HVM, HVM__SETHVMC, "sethvmc")
    S_(SECCLASS_HVM, HVM__GETHVMC, "gethvmc")
    S_(SECCLASS_HVM, HVM__SETPARAM, "setparam")
diff --git a/xen/xsm/flask/include/av_permissions.h b/xen/xsm/flask/include/av_permissions.h
index cb1c5dc..f7cfee1 100644
--- a/xen/xsm/flask/include/av_permissions.h
+++ b/xen/xsm/flask/include/av_permissions.h
@@ -66,6 +66,8 @@
 #define DOMAIN2__RELABELFROM                      0x00000001UL
 #define DOMAIN2__RELABELTO                        0x00000002UL
 #define DOMAIN2__RELABELSELF                      0x00000004UL
+#define DOMAIN2__MAKE_PRIV_FOR                    0x00000008UL
+#define DOMAIN2__SET_AS_TARGET                    0x00000010UL
 
 #define HVM__SETHVMC                              0x00000001UL
 #define HVM__GETHVMC                              0x00000002UL
-- 
1.7.11.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 17 15:24:23 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 15:24:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDdBH-0003j5-Ms; Mon, 17 Sep 2012 15:24:15 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1TDdBE-0003ad-EC
	for xen-devel@lists.xen.org; Mon, 17 Sep 2012 15:24:12 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-15.tower-27.messagelabs.com!1347895445!4372063!1
X-Originating-IP: [63.239.67.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9250 invoked from network); 17 Sep 2012 15:24:06 -0000
Received: from emvm-gh1-uea09.nsa.gov (HELO nsa.gov) (63.239.67.10)
	by server-15.tower-27.messagelabs.com with SMTP;
	17 Sep 2012 15:24:06 -0000
X-TM-IMSS-Message-ID: <537ff6a700131d7d@nsa.gov>
Received: from tarius.tycho.ncsc.mil ([144.51.3.1]) by nsa.gov
	([63.239.67.10]) with ESMTP (TREND IMSS SMTP Service 7.1) id
	537ff6a700131d7d ; Mon, 17 Sep 2012 11:26:01 -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 q8HFO0xe027504; 
	Mon, 17 Sep 2012 11:24:04 -0400
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xen.org
Date: Mon, 17 Sep 2012 11:23:36 -0400
Message-Id: <1347895425-17959-15-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.11.4
In-Reply-To: <1347895425-17959-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1347895425-17959-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: dgdegra@tycho.nsa.gov, keir@xen.org
Subject: [Xen-devel] [PATCH 14/23] xen: convert do_domctl to use 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

The xsm_domctl hook now covers every domctl, in addition to the more
fine-grained XSM hooks in most sub-functions. This also removes the need
to special-case XEN_DOMCTL_getdomaininfo.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 xen/arch/x86/domctl.c   |  2 +-
 xen/common/domctl.c     | 32 +++----------------
 xen/include/xsm/dummy.h | 16 ++++++++--
 xen/xsm/flask/hooks.c   | 85 ++++++++++++++++++++++++++++++++++++++++++++++++-
 4 files changed, 104 insertions(+), 31 deletions(-)

diff --git a/xen/arch/x86/domctl.c b/xen/arch/x86/domctl.c
index da70e35..24e2d93 100644
--- a/xen/arch/x86/domctl.c
+++ b/xen/arch/x86/domctl.c
@@ -1478,7 +1478,7 @@ long arch_do_domctl(
     {
         struct domain *d;
 
-        ret = rcu_lock_remote_target_domain_by_id(domctl->domain, &d);
+        ret = rcu_lock_remote_domain_by_id(domctl->domain, &d);
         if ( ret != 0 )
             break;
 
diff --git a/xen/common/domctl.c b/xen/common/domctl.c
index ef2700d..76f0f90 100644
--- a/xen/common/domctl.c
+++ b/xen/common/domctl.c
@@ -264,27 +264,9 @@ long do_domctl(XEN_GUEST_HANDLE(xen_domctl_t) u_domctl)
             return -ESRCH;
     }
 
-    switch ( op->cmd )
-    {
-    case XEN_DOMCTL_ioport_mapping:
-    case XEN_DOMCTL_memory_mapping:
-    case XEN_DOMCTL_bind_pt_irq:
-    case XEN_DOMCTL_unbind_pt_irq: {
-        bool_t is_priv = IS_PRIV_FOR(current->domain, d);
-        if ( !is_priv )
-        {
-            ret = -EPERM;
-            goto domctl_out_unlock;
-        }
-        break;
-    }
-    case XEN_DOMCTL_getdomaininfo:
-        break;
-    default:
-        if ( !IS_PRIV(current->domain) )
-            return -EPERM;
-        break;
-    }
+    ret = xsm_domctl(d, op->cmd);
+    if ( ret )
+        goto domctl_out_unlock;
 
     if ( !domctl_lock_acquire() )
     {
@@ -858,17 +840,13 @@ long do_domctl(XEN_GUEST_HANDLE(xen_domctl_t) u_domctl)
 
     case XEN_DOMCTL_subscribe:
     {
-        ret = xsm_domctl(d, op->cmd);
-        if ( !ret )
-            d->suspend_evtchn = op->u.subscribe.port;
+        d->suspend_evtchn = op->u.subscribe.port;
     }
     break;
 
     case XEN_DOMCTL_disable_migrate:
     {
-        ret = xsm_domctl(d, op->cmd);
-        if ( !ret )
-            d->disable_migrate = op->u.disable_migrate.disable;
+        d->disable_migrate = op->u.disable_migrate.disable;
     }
     break;
 
diff --git a/xen/include/xsm/dummy.h b/xen/include/xsm/dummy.h
index c7ee659..9d70587 100644
--- a/xen/include/xsm/dummy.h
+++ b/xen/include/xsm/dummy.h
@@ -64,8 +64,6 @@ static XSM_DEFAULT(int, scheduler) (struct domain *d)
 
 static XSM_DEFAULT(int, getdomaininfo) (struct domain *d)
 {
-    if ( !IS_PRIV(current->domain) )
-        return -EPERM;
     return 0;
 }
 
@@ -91,6 +89,20 @@ static XSM_DEFAULT(int, set_target) (struct domain *d, struct domain *e)
 
 static XSM_DEFAULT(int, domctl)(struct domain *d, int cmd)
 {
+    switch ( cmd )
+    {
+    case XEN_DOMCTL_ioport_mapping:
+    case XEN_DOMCTL_memory_mapping:
+    case XEN_DOMCTL_bind_pt_irq:
+    case XEN_DOMCTL_unbind_pt_irq: {
+        if ( !IS_PRIV_FOR(current->domain, d) )
+            return -EPERM;
+        break;
+    }
+    default:
+        if ( !IS_PRIV(current->domain) )
+            return -EPERM;
+    }
     return 0;
 }
 
diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
index 2a44a76..7caab52 100644
--- a/xen/xsm/flask/hooks.c
+++ b/xen/xsm/flask/hooks.c
@@ -589,7 +589,90 @@ static int flask_set_target(struct domain *d, struct domain *e)
 
 static int flask_domctl(struct domain *d, int cmd)
 {
-    return domain_has_perm(current->domain, d, SECCLASS_DOMAIN, DOMAIN__SET_MISC_INFO);
+    switch ( cmd )
+    {
+    /* These have individual XSM hooks (common/domctl.c) */
+    case XEN_DOMCTL_createdomain:
+    case XEN_DOMCTL_destroydomain:
+    case XEN_DOMCTL_pausedomain:
+    case XEN_DOMCTL_unpausedomain:
+    case XEN_DOMCTL_getdomaininfo:
+    case XEN_DOMCTL_setvcpuaffinity:
+    case XEN_DOMCTL_max_mem:
+    case XEN_DOMCTL_setvcpucontext:
+    case XEN_DOMCTL_getvcpucontext:
+    case XEN_DOMCTL_getvcpuinfo:
+    case XEN_DOMCTL_max_vcpus:
+    case XEN_DOMCTL_scheduler_op:
+    case XEN_DOMCTL_setdomainhandle:
+    case XEN_DOMCTL_setdebugging:
+    case XEN_DOMCTL_irq_permission:
+    case XEN_DOMCTL_iomem_permission:
+    case XEN_DOMCTL_settimeoffset:
+    case XEN_DOMCTL_getvcpuaffinity:
+    case XEN_DOMCTL_resumedomain:
+    case XEN_DOMCTL_set_target:
+    case XEN_DOMCTL_set_virq_handler:
+#ifdef CONFIG_X86
+    /* These have individual XSM hooks (arch/x86/domctl.c) */
+    case XEN_DOMCTL_shadow_op:
+    case XEN_DOMCTL_ioport_permission:
+    case XEN_DOMCTL_getpageframeinfo:
+    case XEN_DOMCTL_getpageframeinfo2:
+    case XEN_DOMCTL_getpageframeinfo3:
+    case XEN_DOMCTL_getmemlist:
+    case XEN_DOMCTL_hypercall_init:
+    case XEN_DOMCTL_sethvmcontext:
+    case XEN_DOMCTL_gethvmcontext:
+    case XEN_DOMCTL_gethvmcontext_partial:
+    case XEN_DOMCTL_set_address_size:
+    case XEN_DOMCTL_get_address_size:
+    case XEN_DOMCTL_set_machine_address_size:
+    case XEN_DOMCTL_get_machine_address_size:
+    case XEN_DOMCTL_sendtrigger:
+    case XEN_DOMCTL_bind_pt_irq:
+    case XEN_DOMCTL_unbind_pt_irq:
+    case XEN_DOMCTL_memory_mapping:
+    case XEN_DOMCTL_ioport_mapping:
+    case XEN_DOMCTL_pin_mem_cacheattr:
+    case XEN_DOMCTL_set_ext_vcpucontext:
+    case XEN_DOMCTL_get_ext_vcpucontext:
+    case XEN_DOMCTL_setvcpuextstate:
+    case XEN_DOMCTL_getvcpuextstate:
+    case XEN_DOMCTL_mem_event_op:
+    case XEN_DOMCTL_mem_sharing_op:
+    case XEN_DOMCTL_set_access_required:
+    /* These have individual XSM hooks (drivers/passthrough/iommu.c) */
+    case XEN_DOMCTL_get_device_group:
+    case XEN_DOMCTL_test_assign_device:
+    case XEN_DOMCTL_assign_device:
+    case XEN_DOMCTL_deassign_device:
+#endif
+        return 0;
+
+    case XEN_DOMCTL_subscribe:
+    case XEN_DOMCTL_disable_migrate:
+        return domain_has_perm(current->domain, d, SECCLASS_DOMAIN,
+                               DOMAIN__SET_MISC_INFO);
+
+    case XEN_DOMCTL_set_cpuid:
+    case XEN_DOMCTL_suppress_spurious_page_faults:
+    case XEN_DOMCTL_debug_op:
+    case XEN_DOMCTL_gettscinfo:
+    case XEN_DOMCTL_settscinfo:
+    case XEN_DOMCTL_audit_p2m:
+    case XEN_DOMCTL_gdbsx_guestmemio:
+    case XEN_DOMCTL_gdbsx_pausevcpu:
+    case XEN_DOMCTL_gdbsx_unpausevcpu:
+    case XEN_DOMCTL_gdbsx_domstatus:
+        /* TODO add per-subfunction hooks */
+        if ( !IS_PRIV(current->domain) )
+            return -EPERM;
+        return 0;
+    default:
+        printk("flask_domctl: Unknown op %d\n", cmd);
+        return -EPERM;
+    }
 }
 
 static int flask_set_virq_handler(struct domain *d, uint32_t virq)
-- 
1.7.11.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 17 15:24:23 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 15:24:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDdBH-0003j5-Ms; Mon, 17 Sep 2012 15:24:15 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1TDdBE-0003ad-EC
	for xen-devel@lists.xen.org; Mon, 17 Sep 2012 15:24:12 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-15.tower-27.messagelabs.com!1347895445!4372063!1
X-Originating-IP: [63.239.67.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9250 invoked from network); 17 Sep 2012 15:24:06 -0000
Received: from emvm-gh1-uea09.nsa.gov (HELO nsa.gov) (63.239.67.10)
	by server-15.tower-27.messagelabs.com with SMTP;
	17 Sep 2012 15:24:06 -0000
X-TM-IMSS-Message-ID: <537ff6a700131d7d@nsa.gov>
Received: from tarius.tycho.ncsc.mil ([144.51.3.1]) by nsa.gov
	([63.239.67.10]) with ESMTP (TREND IMSS SMTP Service 7.1) id
	537ff6a700131d7d ; Mon, 17 Sep 2012 11:26:01 -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 q8HFO0xe027504; 
	Mon, 17 Sep 2012 11:24:04 -0400
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xen.org
Date: Mon, 17 Sep 2012 11:23:36 -0400
Message-Id: <1347895425-17959-15-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.11.4
In-Reply-To: <1347895425-17959-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1347895425-17959-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: dgdegra@tycho.nsa.gov, keir@xen.org
Subject: [Xen-devel] [PATCH 14/23] xen: convert do_domctl to use 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

The xsm_domctl hook now covers every domctl, in addition to the more
fine-grained XSM hooks in most sub-functions. This also removes the need
to special-case XEN_DOMCTL_getdomaininfo.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 xen/arch/x86/domctl.c   |  2 +-
 xen/common/domctl.c     | 32 +++----------------
 xen/include/xsm/dummy.h | 16 ++++++++--
 xen/xsm/flask/hooks.c   | 85 ++++++++++++++++++++++++++++++++++++++++++++++++-
 4 files changed, 104 insertions(+), 31 deletions(-)

diff --git a/xen/arch/x86/domctl.c b/xen/arch/x86/domctl.c
index da70e35..24e2d93 100644
--- a/xen/arch/x86/domctl.c
+++ b/xen/arch/x86/domctl.c
@@ -1478,7 +1478,7 @@ long arch_do_domctl(
     {
         struct domain *d;
 
-        ret = rcu_lock_remote_target_domain_by_id(domctl->domain, &d);
+        ret = rcu_lock_remote_domain_by_id(domctl->domain, &d);
         if ( ret != 0 )
             break;
 
diff --git a/xen/common/domctl.c b/xen/common/domctl.c
index ef2700d..76f0f90 100644
--- a/xen/common/domctl.c
+++ b/xen/common/domctl.c
@@ -264,27 +264,9 @@ long do_domctl(XEN_GUEST_HANDLE(xen_domctl_t) u_domctl)
             return -ESRCH;
     }
 
-    switch ( op->cmd )
-    {
-    case XEN_DOMCTL_ioport_mapping:
-    case XEN_DOMCTL_memory_mapping:
-    case XEN_DOMCTL_bind_pt_irq:
-    case XEN_DOMCTL_unbind_pt_irq: {
-        bool_t is_priv = IS_PRIV_FOR(current->domain, d);
-        if ( !is_priv )
-        {
-            ret = -EPERM;
-            goto domctl_out_unlock;
-        }
-        break;
-    }
-    case XEN_DOMCTL_getdomaininfo:
-        break;
-    default:
-        if ( !IS_PRIV(current->domain) )
-            return -EPERM;
-        break;
-    }
+    ret = xsm_domctl(d, op->cmd);
+    if ( ret )
+        goto domctl_out_unlock;
 
     if ( !domctl_lock_acquire() )
     {
@@ -858,17 +840,13 @@ long do_domctl(XEN_GUEST_HANDLE(xen_domctl_t) u_domctl)
 
     case XEN_DOMCTL_subscribe:
     {
-        ret = xsm_domctl(d, op->cmd);
-        if ( !ret )
-            d->suspend_evtchn = op->u.subscribe.port;
+        d->suspend_evtchn = op->u.subscribe.port;
     }
     break;
 
     case XEN_DOMCTL_disable_migrate:
     {
-        ret = xsm_domctl(d, op->cmd);
-        if ( !ret )
-            d->disable_migrate = op->u.disable_migrate.disable;
+        d->disable_migrate = op->u.disable_migrate.disable;
     }
     break;
 
diff --git a/xen/include/xsm/dummy.h b/xen/include/xsm/dummy.h
index c7ee659..9d70587 100644
--- a/xen/include/xsm/dummy.h
+++ b/xen/include/xsm/dummy.h
@@ -64,8 +64,6 @@ static XSM_DEFAULT(int, scheduler) (struct domain *d)
 
 static XSM_DEFAULT(int, getdomaininfo) (struct domain *d)
 {
-    if ( !IS_PRIV(current->domain) )
-        return -EPERM;
     return 0;
 }
 
@@ -91,6 +89,20 @@ static XSM_DEFAULT(int, set_target) (struct domain *d, struct domain *e)
 
 static XSM_DEFAULT(int, domctl)(struct domain *d, int cmd)
 {
+    switch ( cmd )
+    {
+    case XEN_DOMCTL_ioport_mapping:
+    case XEN_DOMCTL_memory_mapping:
+    case XEN_DOMCTL_bind_pt_irq:
+    case XEN_DOMCTL_unbind_pt_irq: {
+        if ( !IS_PRIV_FOR(current->domain, d) )
+            return -EPERM;
+        break;
+    }
+    default:
+        if ( !IS_PRIV(current->domain) )
+            return -EPERM;
+    }
     return 0;
 }
 
diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
index 2a44a76..7caab52 100644
--- a/xen/xsm/flask/hooks.c
+++ b/xen/xsm/flask/hooks.c
@@ -589,7 +589,90 @@ static int flask_set_target(struct domain *d, struct domain *e)
 
 static int flask_domctl(struct domain *d, int cmd)
 {
-    return domain_has_perm(current->domain, d, SECCLASS_DOMAIN, DOMAIN__SET_MISC_INFO);
+    switch ( cmd )
+    {
+    /* These have individual XSM hooks (common/domctl.c) */
+    case XEN_DOMCTL_createdomain:
+    case XEN_DOMCTL_destroydomain:
+    case XEN_DOMCTL_pausedomain:
+    case XEN_DOMCTL_unpausedomain:
+    case XEN_DOMCTL_getdomaininfo:
+    case XEN_DOMCTL_setvcpuaffinity:
+    case XEN_DOMCTL_max_mem:
+    case XEN_DOMCTL_setvcpucontext:
+    case XEN_DOMCTL_getvcpucontext:
+    case XEN_DOMCTL_getvcpuinfo:
+    case XEN_DOMCTL_max_vcpus:
+    case XEN_DOMCTL_scheduler_op:
+    case XEN_DOMCTL_setdomainhandle:
+    case XEN_DOMCTL_setdebugging:
+    case XEN_DOMCTL_irq_permission:
+    case XEN_DOMCTL_iomem_permission:
+    case XEN_DOMCTL_settimeoffset:
+    case XEN_DOMCTL_getvcpuaffinity:
+    case XEN_DOMCTL_resumedomain:
+    case XEN_DOMCTL_set_target:
+    case XEN_DOMCTL_set_virq_handler:
+#ifdef CONFIG_X86
+    /* These have individual XSM hooks (arch/x86/domctl.c) */
+    case XEN_DOMCTL_shadow_op:
+    case XEN_DOMCTL_ioport_permission:
+    case XEN_DOMCTL_getpageframeinfo:
+    case XEN_DOMCTL_getpageframeinfo2:
+    case XEN_DOMCTL_getpageframeinfo3:
+    case XEN_DOMCTL_getmemlist:
+    case XEN_DOMCTL_hypercall_init:
+    case XEN_DOMCTL_sethvmcontext:
+    case XEN_DOMCTL_gethvmcontext:
+    case XEN_DOMCTL_gethvmcontext_partial:
+    case XEN_DOMCTL_set_address_size:
+    case XEN_DOMCTL_get_address_size:
+    case XEN_DOMCTL_set_machine_address_size:
+    case XEN_DOMCTL_get_machine_address_size:
+    case XEN_DOMCTL_sendtrigger:
+    case XEN_DOMCTL_bind_pt_irq:
+    case XEN_DOMCTL_unbind_pt_irq:
+    case XEN_DOMCTL_memory_mapping:
+    case XEN_DOMCTL_ioport_mapping:
+    case XEN_DOMCTL_pin_mem_cacheattr:
+    case XEN_DOMCTL_set_ext_vcpucontext:
+    case XEN_DOMCTL_get_ext_vcpucontext:
+    case XEN_DOMCTL_setvcpuextstate:
+    case XEN_DOMCTL_getvcpuextstate:
+    case XEN_DOMCTL_mem_event_op:
+    case XEN_DOMCTL_mem_sharing_op:
+    case XEN_DOMCTL_set_access_required:
+    /* These have individual XSM hooks (drivers/passthrough/iommu.c) */
+    case XEN_DOMCTL_get_device_group:
+    case XEN_DOMCTL_test_assign_device:
+    case XEN_DOMCTL_assign_device:
+    case XEN_DOMCTL_deassign_device:
+#endif
+        return 0;
+
+    case XEN_DOMCTL_subscribe:
+    case XEN_DOMCTL_disable_migrate:
+        return domain_has_perm(current->domain, d, SECCLASS_DOMAIN,
+                               DOMAIN__SET_MISC_INFO);
+
+    case XEN_DOMCTL_set_cpuid:
+    case XEN_DOMCTL_suppress_spurious_page_faults:
+    case XEN_DOMCTL_debug_op:
+    case XEN_DOMCTL_gettscinfo:
+    case XEN_DOMCTL_settscinfo:
+    case XEN_DOMCTL_audit_p2m:
+    case XEN_DOMCTL_gdbsx_guestmemio:
+    case XEN_DOMCTL_gdbsx_pausevcpu:
+    case XEN_DOMCTL_gdbsx_unpausevcpu:
+    case XEN_DOMCTL_gdbsx_domstatus:
+        /* TODO add per-subfunction hooks */
+        if ( !IS_PRIV(current->domain) )
+            return -EPERM;
+        return 0;
+    default:
+        printk("flask_domctl: Unknown op %d\n", cmd);
+        return -EPERM;
+    }
 }
 
 static int flask_set_virq_handler(struct domain *d, uint32_t virq)
-- 
1.7.11.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 17 15:24:24 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 15:24:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDdBG-0003i9-SV; Mon, 17 Sep 2012 15:24:14 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1TDdBE-0003aT-1p
	for xen-devel@lists.xen.org; Mon, 17 Sep 2012 15:24:12 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-5.tower-27.messagelabs.com!1347895444!7944810!1
X-Originating-IP: [63.239.67.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5301 invoked from network); 17 Sep 2012 15:24:05 -0000
Received: from emvm-gh1-uea09.nsa.gov (HELO nsa.gov) (63.239.67.10)
	by server-5.tower-27.messagelabs.com with SMTP;
	17 Sep 2012 15:24:05 -0000
X-TM-IMSS-Message-ID: <537ff17900131d7a@nsa.gov>
Received: from tarius.tycho.ncsc.mil ([144.51.3.1]) by nsa.gov
	([63.239.67.10]) with ESMTP (TREND IMSS SMTP Service 7.1) id
	537ff17900131d7a ; Mon, 17 Sep 2012 11:25:59 -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 q8HFO0xa027504; 
	Mon, 17 Sep 2012 11:24:03 -0400
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xen.org
Date: Mon, 17 Sep 2012 11:23:32 -0400
Message-Id: <1347895425-17959-11-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.11.4
In-Reply-To: <1347895425-17959-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1347895425-17959-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: dgdegra@tycho.nsa.gov, keir@xen.org, Jan Beulich <jbeulich@suse.com>
Subject: [Xen-devel] [PATCH 10/23] xen: use XSM instead of IS_PRIV where
	duplicated
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

The Xen hypervisor has two basic access control function calls: IS_PRIV
and the xsm_* functions. Most privileged operations currently require
that both checks succeed, and many times the checks are at different
locations in the code. This patch eliminates the explicit and implicit
IS_PRIV checks that are duplicated in XSM hooks.

When XSM_ENABLE is not defined or when the dummy XSM module is used,
this patch should not change any functionality. Because the locations of
privilege checks have sometimes moved below argument validation, error
returns of some functions may change from EPERM to EINVAL or ESRCH if
called with invalid arguments and from a domain without permission to
perform the operation.

Some checks are removed due to non-obvious duplicates in their callers:

 * acpi_enter_sleep is checked in XENPF_enter_acpi_sleep
 * map_domain_pirq has IS_PRIV_FOR checked in its callers:
   * physdev_map_pirq checks when acquiring the RCU lock
   * ioapic_guest_write is checked in PHYSDEVOP_apic_write
 * PHYSDEVOP_{manage_pci_add,manage_pci_add_ext,pci_device_add} are
   checked by xsm_resource_plug_pci in pci_add_device
 * PHYSDEVOP_manage_pci_remove is checked by xsm_resource_unplug_pci
   in pci_remove_device
 * PHYSDEVOP_{restore_msi,restore_msi_ext} are checked by
   xsm_resource_setup_pci in pci_restore_msi_state
 * do_console_io has changed to IS_PRIV from an explicit domid==0

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Cc: Keir Fraser <keir@xen.org>
Cc: Jan Beulich <jbeulich@suse.com>
---
 xen/arch/x86/acpi/power.c     |  2 +-
 xen/arch/x86/cpu/mcheck/mce.c |  3 ---
 xen/arch/x86/irq.c            |  3 +--
 xen/arch/x86/mm.c             |  3 ---
 xen/arch/x86/physdev.c        | 54 ++-----------------------------------------
 xen/common/kexec.c            |  3 ---
 xen/common/schedule.c         |  6 -----
 xen/drivers/char/console.c    |  6 -----
 xen/include/xsm/dummy.h       | 28 ++++++++++++++++++++++
 xen/xsm/flask/hooks.c         |  5 ++--
 10 files changed, 35 insertions(+), 78 deletions(-)

diff --git a/xen/arch/x86/acpi/power.c b/xen/arch/x86/acpi/power.c
index 9e1f989..c7b37ef 100644
--- a/xen/arch/x86/acpi/power.c
+++ b/xen/arch/x86/acpi/power.c
@@ -238,7 +238,7 @@ static long enter_state_helper(void *data)
  */
 int acpi_enter_sleep(struct xenpf_enter_acpi_sleep *sleep)
 {
-    if ( !IS_PRIV(current->domain) || !acpi_sinfo.pm1a_cnt_blk.address )
+    if ( !acpi_sinfo.pm1a_cnt_blk.address )
         return -EPERM;
 
     /* Sanity check */
diff --git a/xen/arch/x86/cpu/mcheck/mce.c b/xen/arch/x86/cpu/mcheck/mce.c
index f60d14f..9578194 100644
--- a/xen/arch/x86/cpu/mcheck/mce.c
+++ b/xen/arch/x86/cpu/mcheck/mce.c
@@ -1372,9 +1372,6 @@ long do_mca(XEN_GUEST_HANDLE(xen_mc_t) u_xen_mc)
     struct xen_mc_msrinject *mc_msrinject;
     struct xen_mc_mceinject *mc_mceinject;
 
-    if (!IS_PRIV(v->domain) )
-        return x86_mcerr(NULL, -EPERM);
-
     ret = xsm_do_mca();
     if ( ret )
         return x86_mcerr(NULL, ret);
diff --git a/xen/arch/x86/irq.c b/xen/arch/x86/irq.c
index c87027b..70b0f03 100644
--- a/xen/arch/x86/irq.c
+++ b/xen/arch/x86/irq.c
@@ -1853,8 +1853,7 @@ int map_domain_pirq(
     ASSERT(spin_is_locked(&d->event_lock));
 
     if ( !IS_PRIV(current->domain) &&
-         !(IS_PRIV_FOR(current->domain, d) &&
-           irq_access_permitted(current->domain, pirq)))
+         !irq_access_permitted(current->domain, pirq))
         return -EPERM;
 
     if ( pirq < 0 || pirq >= d->nr_pirqs || irq < 0 || irq >= nr_irqs )
diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
index 4ea5334..b370300 100644
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -4488,9 +4488,6 @@ long arch_memory_op(int op, XEN_GUEST_HANDLE(void) arg)
         XEN_GUEST_HANDLE(e820entry_t) buffer;
         unsigned int i;
 
-        if ( !IS_PRIV(current->domain) )
-            return -EINVAL;
-
         rc = xsm_machine_memory_map();
         if ( rc )
             return rc;
diff --git a/xen/arch/x86/physdev.c b/xen/arch/x86/physdev.c
index 13b85da..515dca3 100644
--- a/xen/arch/x86/physdev.c
+++ b/xen/arch/x86/physdev.c
@@ -109,12 +109,6 @@ int physdev_map_pirq(domid_t domid, int type, int *index, int *pirq_p,
     if ( ret )
         return ret;
 
-    if ( !IS_PRIV_FOR(current->domain, d) )
-    {
-        ret = -EPERM;
-        goto free_domain;
-    }
-
     /* Verify or get irq. */
     switch ( type )
     {
@@ -238,10 +232,6 @@ int physdev_unmap_pirq(domid_t domid, int pirq)
             goto free_domain;
     }
 
-    ret = -EPERM;
-    if ( !IS_PRIV_FOR(current->domain, d) )
-        goto free_domain;
-
     ret = xsm_unmap_domain_pirq(d, domain_pirq_to_irq(d, pirq));
     if ( ret )
         goto free_domain;
@@ -433,9 +423,6 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_HANDLE(void) arg)
         ret = -EFAULT;
         if ( copy_from_guest(&apic, arg, 1) != 0 )
             break;
-        ret = -EPERM;
-        if ( !IS_PRIV(v->domain) )
-            break;
         ret = xsm_apic(v->domain, cmd);
         if ( ret )
             break;
@@ -450,9 +437,6 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_HANDLE(void) arg)
         ret = -EFAULT;
         if ( copy_from_guest(&apic, arg, 1) != 0 )
             break;
-        ret = -EPERM;
-        if ( !IS_PRIV(v->domain) )
-            break;
         ret = xsm_apic(v->domain, cmd);
         if ( ret )
             break;
@@ -467,8 +451,8 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_HANDLE(void) arg)
         if ( copy_from_guest(&irq_op, arg, 1) != 0 )
             break;
 
-        ret = -EPERM;
-        if ( !IS_PRIV(v->domain) )
+        ret = xsm_apic(v->domain, cmd);
+        if ( ret )
             break;
 
         /* Vector is only used by hypervisor, and dom0 shouldn't
@@ -517,9 +501,6 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_HANDLE(void) arg)
 
     case PHYSDEVOP_manage_pci_add: {
         struct physdev_manage_pci manage_pci;
-        ret = -EPERM;
-        if ( !IS_PRIV(v->domain) )
-            break;
         ret = -EFAULT;
         if ( copy_from_guest(&manage_pci, arg, 1) != 0 )
             break;
@@ -530,9 +511,6 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_HANDLE(void) arg)
 
     case PHYSDEVOP_manage_pci_remove: {
         struct physdev_manage_pci manage_pci;
-        ret = -EPERM;
-        if ( !IS_PRIV(v->domain) )
-            break;
         ret = -EFAULT;
         if ( copy_from_guest(&manage_pci, arg, 1) != 0 )
             break;
@@ -545,10 +523,6 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_HANDLE(void) arg)
         struct physdev_manage_pci_ext manage_pci_ext;
         struct pci_dev_info pdev_info;
 
-        ret = -EPERM;
-        if ( !IS_PRIV(current->domain) )
-            break;
-
         ret = -EFAULT;
         if ( copy_from_guest(&manage_pci_ext, arg, 1) != 0 )
             break;
@@ -571,10 +545,6 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_HANDLE(void) arg)
         struct physdev_pci_device_add add;
         struct pci_dev_info pdev_info;
 
-        ret = -EPERM;
-        if ( !IS_PRIV(current->domain) )
-            break;
-
         ret = -EFAULT;
         if ( copy_from_guest(&add, arg, 1) != 0 )
             break;
@@ -595,10 +565,6 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_HANDLE(void) arg)
     case PHYSDEVOP_pci_device_remove: {
         struct physdev_pci_device dev;
 
-        ret = -EPERM;
-        if ( !IS_PRIV(v->domain) )
-            break;
-
         ret = -EFAULT;
         if ( copy_from_guest(&dev, arg, 1) != 0 )
             break;
@@ -610,10 +576,6 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_HANDLE(void) arg)
     case PHYSDEVOP_pci_mmcfg_reserved: {
         struct physdev_pci_mmcfg_reserved info;
 
-        ret = -EPERM;
-        if ( !IS_PRIV(current->domain) )
-            break;
-
         ret = xsm_resource_setup_misc();
         if ( ret )
             break;
@@ -631,10 +593,6 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_HANDLE(void) arg)
         struct physdev_restore_msi restore_msi;
         struct pci_dev *pdev;
 
-        ret = -EPERM;
-        if ( !IS_PRIV(v->domain) )
-            break;
-
         ret = -EFAULT;
         if ( copy_from_guest(&restore_msi, arg, 1) != 0 )
             break;
@@ -650,10 +608,6 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_HANDLE(void) arg)
         struct physdev_pci_device dev;
         struct pci_dev *pdev;
 
-        ret = -EPERM;
-        if ( !IS_PRIV(v->domain) )
-            break;
-
         ret = -EFAULT;
         if ( copy_from_guest(&dev, arg, 1) != 0 )
             break;
@@ -668,10 +622,6 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_HANDLE(void) arg)
     case PHYSDEVOP_setup_gsi: {
         struct physdev_setup_gsi setup_gsi;
 
-        ret = -EPERM;
-        if ( !IS_PRIV(v->domain) )
-            break;
-
         ret = -EFAULT;
         if ( copy_from_guest(&setup_gsi, arg, 1) != 0 )
             break;
diff --git a/xen/common/kexec.c b/xen/common/kexec.c
index 2bc3e33..7dc6f24 100644
--- a/xen/common/kexec.c
+++ b/xen/common/kexec.c
@@ -851,9 +851,6 @@ static int do_kexec_op_internal(unsigned long op, XEN_GUEST_HANDLE(void) uarg,
     unsigned long flags;
     int ret = -EINVAL;
 
-    if ( !IS_PRIV(current->domain) )
-        return -EPERM;
-
     ret = xsm_kexec();
     if ( ret )
         return ret;
diff --git a/xen/common/schedule.c b/xen/common/schedule.c
index eee74be..95142c0 100644
--- a/xen/common/schedule.c
+++ b/xen/common/schedule.c
@@ -919,12 +919,6 @@ ret_t do_sched_op(int cmd, XEN_GUEST_HANDLE(void) arg)
         if ( d == NULL )
             break;
 
-        if ( !IS_PRIV_FOR(current->domain, d) )
-        {
-            rcu_unlock_domain(d);
-            return -EPERM;
-        }
-
         ret = xsm_schedop_shutdown(current->domain, d);
         if ( ret )
         {
diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c
index d97170c..aee3b4b 100644
--- a/xen/drivers/char/console.c
+++ b/xen/drivers/char/console.c
@@ -363,12 +363,6 @@ long do_console_io(int cmd, int count, XEN_GUEST_HANDLE(char) buffer)
     long rc;
     unsigned int idx, len;
 
-#ifndef VERBOSE
-    /* Only domain 0 may access the emergency console. */
-    if ( current->domain->domain_id != 0 )
-        return -EPERM;
-#endif
-
     rc = xsm_console_io(current->domain, cmd);
     if ( rc )
         return rc;
diff --git a/xen/include/xsm/dummy.h b/xen/include/xsm/dummy.h
index 0456bc8..7cb229d 100644
--- a/xen/include/xsm/dummy.h
+++ b/xen/include/xsm/dummy.h
@@ -161,6 +161,8 @@ static XSM_DEFAULT(int, pm_op) (void)
 
 static XSM_DEFAULT(int, do_mca) (void)
 {
+    if ( !IS_PRIV(current->domain) )
+        return -EPERM;
     return 0;
 }
 
@@ -223,6 +225,10 @@ static XSM_DEFAULT(int, memory_stat_reservation) (struct domain *d1, struct doma
 
 static XSM_DEFAULT(int, console_io) (struct domain *d, int cmd)
 {
+#ifndef VERBOSE
+    if ( !IS_PRIV(current->domain) )
+        return -EPERM;
+#endif
     return 0;
 }
 
@@ -233,11 +239,15 @@ static XSM_DEFAULT(int, profile) (struct domain *d, int op)
 
 static XSM_DEFAULT(int, kexec) (void)
 {
+    if ( !IS_PRIV(current->domain) )
+        return -EPERM;
     return 0;
 }
 
 static XSM_DEFAULT(int, schedop_shutdown) (struct domain *d1, struct domain *d2)
 {
+    if ( !IS_PRIV_FOR(d1, d2) )
+        return -EPERM;
     return 0;
 }
 
@@ -336,26 +346,36 @@ static XSM_DEFAULT(int, resource_unplug_core) (void)
 
 static XSM_DEFAULT(int, resource_plug_pci) (uint32_t machine_bdf)
 {
+    if ( !IS_PRIV(current->domain) )
+        return -EPERM;
     return 0;
 }
 
 static XSM_DEFAULT(int, resource_unplug_pci) (uint32_t machine_bdf)
 {
+    if ( !IS_PRIV(current->domain) )
+        return -EPERM;
     return 0;
 }
 
 static XSM_DEFAULT(int, resource_setup_pci) (uint32_t machine_bdf)
 {
+    if ( !IS_PRIV(current->domain) )
+        return -EPERM;
     return 0;
 }
 
 static XSM_DEFAULT(int, resource_setup_gsi) (int gsi)
 {
+    if ( !IS_PRIV(current->domain) )
+        return -EPERM;
     return 0;
 }
 
 static XSM_DEFAULT(int, resource_setup_misc) (void)
 {
+    if ( !IS_PRIV(current->domain) )
+        return -EPERM;
     return 0;
 }
 
@@ -396,6 +416,8 @@ static XSM_DEFAULT(int, map_domain_pirq) (struct domain *d, int irq, void *data)
 
 static XSM_DEFAULT(int, unmap_domain_pirq) (struct domain *d, int irq)
 {
+    if ( !IS_PRIV_FOR(current->domain, d) )
+        return -EPERM;
     return 0;
 }
 
@@ -494,6 +516,8 @@ static XSM_DEFAULT(int, mem_sharing) (struct domain *d)
 
 static XSM_DEFAULT(int, apic) (struct domain *d, int cmd)
 {
+    if ( !IS_PRIV(d) )
+        return -EPERM;
     return 0;
 }
 
@@ -534,6 +558,8 @@ static XSM_DEFAULT(int, efi_call) (void)
 
 static XSM_DEFAULT(int, acpi_sleep) (void)
 {
+    if ( !IS_PRIV(current->domain) )
+        return -EPERM;
     return 0;
 }
 
@@ -549,6 +575,8 @@ static XSM_DEFAULT(int, getidletime) (void)
 
 static XSM_DEFAULT(int, machine_memory_map) (void)
 {
+    if ( !IS_PRIV(current->domain) )
+        return -EPERM;
     return 0;
 }
 
diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
index 7cc06a8..90b0388 100644
--- a/xen/xsm/flask/hooks.c
+++ b/xen/xsm/flask/hooks.c
@@ -1147,10 +1147,11 @@ static int flask_apic(struct domain *d, int cmd)
 
     switch ( cmd )
     {
-    case PHYSDEVOP_APIC_READ:
+    case PHYSDEVOP_apic_read:
+    case PHYSDEVOP_alloc_irq_vector:
         perm = XEN__READAPIC;
         break;
-    case PHYSDEVOP_APIC_WRITE:
+    case PHYSDEVOP_apic_write:
         perm = XEN__WRITEAPIC;
         break;
     default:
-- 
1.7.11.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 17 15:24:24 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 15:24:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDdBD-0003e1-Cy; Mon, 17 Sep 2012 15:24:11 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1TDdBA-0003as-TS
	for xen-devel@lists.xen.org; Mon, 17 Sep 2012 15:24:09 +0000
Received: from [85.158.139.211:11473] by server-10.bemta-5.messagelabs.com id
	A7/7C-10969-79047505; Mon, 17 Sep 2012 15:24:07 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-12.tower-206.messagelabs.com!1347895446!18848097!1
X-Originating-IP: [63.239.67.9]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19032 invoked from network); 17 Sep 2012 15:24:06 -0000
Received: from emvm-gh1-uea08.nsa.gov (HELO nsa.gov) (63.239.67.9)
	by server-12.tower-206.messagelabs.com with SMTP;
	17 Sep 2012 15:24:06 -0000
X-TM-IMSS-Message-ID: <53803de40012acdd@nsa.gov>
Received: from tarius.tycho.ncsc.mil ([144.51.3.1]) by nsa.gov ([63.239.67.9])
	with ESMTP (TREND IMSS SMTP Service 7.1) id 53803de40012acdd ;
	Mon, 17 Sep 2012 11:23:46 -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 q8HFO0xf027504; 
	Mon, 17 Sep 2012 11:24:04 -0400
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xen.org
Date: Mon, 17 Sep 2012 11:23:37 -0400
Message-Id: <1347895425-17959-16-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.11.4
In-Reply-To: <1347895425-17959-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1347895425-17959-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: dgdegra@tycho.nsa.gov, keir@xen.org
Subject: [Xen-devel] [PATCH 15/23] xen: convert do_sysctl to use 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

The xsm_sysctl hook now covers every sysctl, in addition to the more
fine-grained XSM hooks in most sub-functions.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 xen/common/sysctl.c     |  7 ++++---
 xen/include/xsm/dummy.h |  7 +++++++
 xen/include/xsm/xsm.h   |  6 ++++++
 xen/xsm/dummy.c         |  1 +
 xen/xsm/flask/hooks.c   | 33 +++++++++++++++++++++++++++++++++
 5 files changed, 51 insertions(+), 3 deletions(-)

diff --git a/xen/common/sysctl.c b/xen/common/sysctl.c
index ea68278..e009baa 100644
--- a/xen/common/sysctl.c
+++ b/xen/common/sysctl.c
@@ -33,15 +33,16 @@ long do_sysctl(XEN_GUEST_HANDLE(xen_sysctl_t) u_sysctl)
     struct xen_sysctl curop, *op = &curop;
     static DEFINE_SPINLOCK(sysctl_lock);
 
-    if ( !IS_PRIV(current->domain) )
-        return -EPERM;
-
     if ( copy_from_guest(op, u_sysctl, 1) )
         return -EFAULT;
 
     if ( op->interface_version != XEN_SYSCTL_INTERFACE_VERSION )
         return -EACCES;
 
+    ret = xsm_sysctl(op->cmd);
+    if ( ret )
+        return ret;
+
     /*
      * Trylock here avoids deadlock with an existing sysctl critical section
      * which might (for some current or future reason) want to synchronise
diff --git a/xen/include/xsm/dummy.h b/xen/include/xsm/dummy.h
index 9d70587..626a332 100644
--- a/xen/include/xsm/dummy.h
+++ b/xen/include/xsm/dummy.h
@@ -106,6 +106,13 @@ static XSM_DEFAULT(int, domctl)(struct domain *d, int cmd)
     return 0;
 }
 
+static XSM_DEFAULT(int, sysctl)(int cmd)
+{
+    if ( !IS_PRIV(current->domain) )
+        return -EPERM;
+    return 0;
+}
+
 static XSM_DEFAULT(int, set_virq_handler)(struct domain *d, uint32_t virq)
 {
     return 0;
diff --git a/xen/include/xsm/xsm.h b/xen/include/xsm/xsm.h
index 028661b..96e4b13 100644
--- a/xen/include/xsm/xsm.h
+++ b/xen/include/xsm/xsm.h
@@ -58,6 +58,7 @@ struct xsm_operations {
     int (*domain_settime) (struct domain *d);
     int (*set_target) (struct domain *d, struct domain *e);
     int (*domctl) (struct domain *d, int cmd);
+    int (*sysctl) (int cmd);
     int (*set_virq_handler) (struct domain *d, uint32_t virq);
     int (*tbufcontrol) (void);
     int (*readconsole) (uint32_t clear);
@@ -265,6 +266,11 @@ static inline int xsm_domctl (struct domain *d, int cmd)
     return xsm_ops->domctl(d, cmd);
 }
 
+static inline int xsm_sysctl (int cmd)
+{
+    return xsm_ops->sysctl(cmd);
+}
+
 static inline int xsm_set_virq_handler (struct domain *d, uint32_t virq)
 {
     return xsm_ops->set_virq_handler(d, virq);
diff --git a/xen/xsm/dummy.c b/xen/xsm/dummy.c
index 10f9c47..43e8617 100644
--- a/xen/xsm/dummy.c
+++ b/xen/xsm/dummy.c
@@ -44,6 +44,7 @@ void xsm_fixup_ops (struct xsm_operations *ops)
     set_to_dummy_if_null(ops, domain_settime);
     set_to_dummy_if_null(ops, set_target);
     set_to_dummy_if_null(ops, domctl);
+    set_to_dummy_if_null(ops, sysctl);
     set_to_dummy_if_null(ops, set_virq_handler);
     set_to_dummy_if_null(ops, tbufcontrol);
     set_to_dummy_if_null(ops, readconsole);
diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
index 7caab52..635f91c 100644
--- a/xen/xsm/flask/hooks.c
+++ b/xen/xsm/flask/hooks.c
@@ -675,6 +675,38 @@ static int flask_domctl(struct domain *d, int cmd)
     }
 }
 
+static int flask_sysctl(int cmd)
+{
+    switch ( cmd )
+    {
+    /* These have individual XSM hooks */
+    case XEN_SYSCTL_readconsole:
+    case XEN_SYSCTL_tbuf_op:
+    case XEN_SYSCTL_sched_id:
+    case XEN_SYSCTL_perfc_op:
+    case XEN_SYSCTL_getdomaininfolist:
+    case XEN_SYSCTL_debug_keys:
+    case XEN_SYSCTL_getcpuinfo:
+    case XEN_SYSCTL_availheap:
+    case XEN_SYSCTL_get_pmstat:
+    case XEN_SYSCTL_pm_op:
+    case XEN_SYSCTL_page_offline_op:
+    case XEN_SYSCTL_lockprof_op:
+    case XEN_SYSCTL_cpupool_op:
+    case XEN_SYSCTL_scheduler_op:
+#ifdef CONFIG_X86
+    case XEN_SYSCTL_physinfo:
+    case XEN_SYSCTL_cpu_hotplug:
+    case XEN_SYSCTL_topologyinfo:
+    case XEN_SYSCTL_numainfo:
+#endif
+        return 0;
+    default:
+        printk("flask_sysctl: Unknown op %d\n", cmd);
+        return -EPERM;
+    }
+}
+
 static int flask_set_virq_handler(struct domain *d, uint32_t virq)
 {
     return domain_has_perm(current->domain, d, SECCLASS_DOMAIN, DOMAIN__SET_VIRQ_HANDLER);
@@ -1601,6 +1633,7 @@ static struct xsm_operations flask_ops = {
     .domain_settime = flask_domain_settime,
     .set_target = flask_set_target,
     .domctl = flask_domctl,
+    .sysctl = flask_sysctl,
     .set_virq_handler = flask_set_virq_handler,
     .tbufcontrol = flask_tbufcontrol,
     .readconsole = flask_readconsole,
-- 
1.7.11.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 17 15:24:24 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 15:24:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDdBH-0003ib-96; Mon, 17 Sep 2012 15:24:15 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1TDdBE-0003aY-AH
	for xen-devel@lists.xen.org; Mon, 17 Sep 2012 15:24:12 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-7.tower-27.messagelabs.com!1347895445!3647354!1
X-Originating-IP: [63.239.67.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12992 invoked from network); 17 Sep 2012 15:24:06 -0000
Received: from emvm-gh1-uea09.nsa.gov (HELO nsa.gov) (63.239.67.10)
	by server-7.tower-27.messagelabs.com with SMTP;
	17 Sep 2012 15:24:06 -0000
X-TM-IMSS-Message-ID: <537ff52100131d7c@nsa.gov>
Received: from tarius.tycho.ncsc.mil ([144.51.3.1]) by nsa.gov
	([63.239.67.10]) with ESMTP (TREND IMSS SMTP Service 7.1) id
	537ff52100131d7c ; Mon, 17 Sep 2012 11:26:00 -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 q8HFO0xc027504; 
	Mon, 17 Sep 2012 11:24:04 -0400
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xen.org
Date: Mon, 17 Sep 2012 11:23:34 -0400
Message-Id: <1347895425-17959-13-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.11.4
In-Reply-To: <1347895425-17959-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1347895425-17959-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: dgdegra@tycho.nsa.gov, keir@xen.org, Jan Beulich <jbeulich@suse.com>
Subject: [Xen-devel] [PATCH 12/23] arch/x86: convert platform_hypercall to
	use 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

The newly introduced xsm_platform_op hook addresses new sub-ops, while
most ops already have their own XSM hooks.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Cc: Keir Fraser <keir@xen.org>
Cc: Jan Beulich <jbeulich@suse.com>
---
 xen/arch/x86/platform_hypercall.c | 11 ++++++++---
 xen/include/xsm/dummy.h           |  7 +++++++
 xen/include/xsm/xsm.h             |  6 ++++++
 xen/xsm/dummy.c                   |  1 +
 xen/xsm/flask/hooks.c             | 33 +++++++++++++++++++++++++++++++++
 5 files changed, 55 insertions(+), 3 deletions(-)

diff --git a/xen/arch/x86/platform_hypercall.c b/xen/arch/x86/platform_hypercall.c
index 073a2ea..50b5f1d 100644
--- a/xen/arch/x86/platform_hypercall.c
+++ b/xen/arch/x86/platform_hypercall.c
@@ -66,15 +66,16 @@ ret_t do_platform_op(XEN_GUEST_HANDLE(xen_platform_op_t) u_xenpf_op)
     ret_t ret = 0;
     struct xen_platform_op curop, *op = &curop;
 
-    if ( !IS_PRIV(current->domain) )
-        return -EPERM;
-
     if ( copy_from_guest(op, u_xenpf_op, 1) )
         return -EFAULT;
 
     if ( op->interface_version != XENPF_INTERFACE_VERSION )
         return -EACCES;
 
+    ret = xsm_platform_op(op->cmd);
+    if ( ret )
+        return ret;
+
     /*
      * Trylock here avoids deadlock with an existing platform critical section
      * which might (for some current or future reason) want to synchronise
@@ -507,6 +508,10 @@ ret_t do_platform_op(XEN_GUEST_HANDLE(xen_platform_op_t) u_xenpf_op)
     {
         struct xenpf_pcpu_version *ver = &op->u.pcpu_version;
 
+        ret = xsm_getcpuinfo();
+        if ( ret )
+            break;
+
         if ( !get_cpu_maps() )
         {
             ret = -EBUSY;
diff --git a/xen/include/xsm/dummy.h b/xen/include/xsm/dummy.h
index 448b5c1..c7ee659 100644
--- a/xen/include/xsm/dummy.h
+++ b/xen/include/xsm/dummy.h
@@ -574,6 +574,13 @@ static XSM_DEFAULT(int, platform_quirk) (uint32_t quirk)
     return 0;
 }
 
+static XSM_DEFAULT(int, platform_op) (uint32_t op)
+{
+    if ( !IS_PRIV(current->domain) )
+        return -EPERM;
+    return 0;
+}
+
 static XSM_DEFAULT(int, firmware_info) (void)
 {
     return 0;
diff --git a/xen/include/xsm/xsm.h b/xen/include/xsm/xsm.h
index 1a63c27..028661b 100644
--- a/xen/include/xsm/xsm.h
+++ b/xen/include/xsm/xsm.h
@@ -158,6 +158,7 @@ struct xsm_operations {
     int (*microcode) (void);
     int (*physinfo) (void);
     int (*platform_quirk) (uint32_t);
+    int (*platform_op) (uint32_t cmd);
     int (*firmware_info) (void);
     int (*efi_call) (void);
     int (*acpi_sleep) (void);
@@ -696,6 +697,11 @@ static inline int xsm_platform_quirk (uint32_t quirk)
     return xsm_ops->platform_quirk(quirk);
 }
 
+static inline int xsm_platform_op (uint32_t op)
+{
+    return xsm_ops->platform_op(op);
+}
+
 static inline int xsm_firmware_info (void)
 {
     return xsm_ops->firmware_info();
diff --git a/xen/xsm/dummy.c b/xen/xsm/dummy.c
index 47192d7..10f9c47 100644
--- a/xen/xsm/dummy.c
+++ b/xen/xsm/dummy.c
@@ -142,6 +142,7 @@ void xsm_fixup_ops (struct xsm_operations *ops)
     set_to_dummy_if_null(ops, microcode);
     set_to_dummy_if_null(ops, physinfo);
     set_to_dummy_if_null(ops, platform_quirk);
+    set_to_dummy_if_null(ops, platform_op);
     set_to_dummy_if_null(ops, firmware_info);
     set_to_dummy_if_null(ops, efi_call);
     set_to_dummy_if_null(ops, acpi_sleep);
diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
index 90b0388..2a44a76 100644
--- a/xen/xsm/flask/hooks.c
+++ b/xen/xsm/flask/hooks.c
@@ -1207,6 +1207,38 @@ static int flask_platform_quirk(uint32_t quirk)
                         XEN__QUIRK, NULL);
 }
 
+static int flask_platform_op(uint32_t op)
+{
+    switch ( op )
+    {
+    case XENPF_settime:
+    case XENPF_add_memtype:
+    case XENPF_del_memtype:
+    case XENPF_read_memtype:
+    case XENPF_microcode_update:
+    case XENPF_platform_quirk:
+    case XENPF_firmware_info:
+    case XENPF_efi_runtime_call:
+    case XENPF_enter_acpi_sleep:
+    case XENPF_change_freq:
+    case XENPF_getidletime:
+    case XENPF_set_processor_pminfo:
+    case XENPF_get_cpuinfo:
+    case XENPF_get_cpu_version:
+    case XENPF_cpu_online:
+    case XENPF_cpu_offline:
+    case XENPF_cpu_hotadd:
+    case XENPF_mem_hotadd:
+        /* These operations have their own XSM hooks */
+        return 0;
+    case XENPF_core_parking:
+        return domain_has_xen(current->domain, XEN__PM_OP);
+    default:
+        printk("flask_platform_op: Unknown op %d\n", op);
+        return -EPERM;
+    }
+}
+
 static int flask_firmware_info(void)
 {
     return domain_has_xen(current->domain, XEN__FIRMWARE);
@@ -1577,6 +1609,7 @@ static struct xsm_operations flask_ops = {
     .microcode = flask_microcode,
     .physinfo = flask_physinfo,
     .platform_quirk = flask_platform_quirk,
+    .platform_op = flask_platform_op,
     .firmware_info = flask_firmware_info,
     .efi_call = flask_efi_call,
     .acpi_sleep = flask_acpi_sleep,
-- 
1.7.11.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 17 15:24:24 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 15:24:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDdB9-0003b0-RZ; Mon, 17 Sep 2012 15:24:07 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1TDdB7-0003Zz-MN
	for xen-devel@lists.xen.org; Mon, 17 Sep 2012 15:24:05 +0000
Received: from [85.158.139.211:49323] by server-9.bemta-5.messagelabs.com id
	1F/93-20529-49047505; Mon, 17 Sep 2012 15:24:04 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-16.tower-206.messagelabs.com!1347895443!18930286!1
X-Originating-IP: [63.239.67.9]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18966 invoked from network); 17 Sep 2012 15:24:03 -0000
Received: from emvm-gh1-uea08.nsa.gov (HELO nsa.gov) (63.239.67.9)
	by server-16.tower-206.messagelabs.com with SMTP;
	17 Sep 2012 15:24:03 -0000
X-TM-IMSS-Message-ID: <538031080012accc@nsa.gov>
Received: from tarius.tycho.ncsc.mil ([144.51.3.1]) by nsa.gov ([63.239.67.9])
	with ESMTP (TREND IMSS SMTP Service 7.1) id 538031080012accc ;
	Mon, 17 Sep 2012 11:23:43 -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 q8HFO0xU027504; 
	Mon, 17 Sep 2012 11:24:01 -0400
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xen.org
Date: Mon, 17 Sep 2012 11:23:26 -0400
Message-Id: <1347895425-17959-5-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.11.4
In-Reply-To: <1347895425-17959-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1347895425-17959-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: dgdegra@tycho.nsa.gov, keir@xen.org
Subject: [Xen-devel] [PATCH 04/23] xsm/flask: add domain relabel 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

This adds the ability to change a domain's XSM label after creation.
The new label will be used for all future access checks; however,
existing event channels and memory mappings will remain valid even if
their creation would be denied by the new label.

With appropriate security policy and hooks in the domain builder, this
can be used to create domains that the domain builder does not have
access to after building. It can also be used to allow a domain to drop
privileges - for example, prior to launching a user-supplied kernel
loaded by a pv-grub stubdom.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 tools/flask/policy/policy/flask/access_vectors   |  7 ++++
 tools/flask/policy/policy/flask/security_classes |  1 +
 tools/flask/policy/policy/modules/xen/xen.te     |  2 +-
 xen/include/public/xsm/flask_op.h                |  8 ++++
 xen/xsm/flask/flask_op.c                         | 49 ++++++++++++++++++++++++
 xen/xsm/flask/include/av_perm_to_string.h        |  3 ++
 xen/xsm/flask/include/av_permissions.h           |  4 ++
 xen/xsm/flask/include/class_to_string.h          |  1 +
 xen/xsm/flask/include/flask.h                    | 15 ++++----
 9 files changed, 82 insertions(+), 8 deletions(-)

diff --git a/tools/flask/policy/policy/flask/access_vectors b/tools/flask/policy/policy/flask/access_vectors
index a884312..c7e29ab 100644
--- a/tools/flask/policy/policy/flask/access_vectors
+++ b/tools/flask/policy/policy/flask/access_vectors
@@ -73,6 +73,13 @@ class domain
 	set_virq_handler
 }
 
+class domain2
+{
+	relabelfrom
+	relabelto
+	relabelself
+}
+
 class hvm
 {
     sethvmc
diff --git a/tools/flask/policy/policy/flask/security_classes b/tools/flask/policy/policy/flask/security_classes
index 2ca35d2..ef134a7 100644
--- a/tools/flask/policy/policy/flask/security_classes
+++ b/tools/flask/policy/policy/flask/security_classes
@@ -9,6 +9,7 @@
 
 class xen
 class domain
+class domain2
 class hvm
 class mmu
 class resource
diff --git a/tools/flask/policy/policy/modules/xen/xen.te b/tools/flask/policy/policy/modules/xen/xen.te
index 9cc5240..9550397 100644
--- a/tools/flask/policy/policy/modules/xen/xen.te
+++ b/tools/flask/policy/policy/modules/xen/xen.te
@@ -169,7 +169,7 @@ delegate_devices(dom0_t, domU_t)
 ################################################################################
 
 # Domains must be declared using domain_type
-neverallow * ~domain_type:domain create;
+neverallow * ~domain_type:domain { create transition };
 
 # Resources must be declared using resource_type
 neverallow * ~resource_type:resource use;
diff --git a/xen/include/public/xsm/flask_op.h b/xen/include/public/xsm/flask_op.h
index 1a251c9..233de81 100644
--- a/xen/include/public/xsm/flask_op.h
+++ b/xen/include/public/xsm/flask_op.h
@@ -142,6 +142,12 @@ struct xen_flask_peersid {
     uint32_t sid;
 };
 
+struct xen_flask_relabel {
+    /* IN */
+    uint32_t domid;
+    uint32_t sid;
+};
+
 struct xen_flask_op {
     uint32_t cmd;
 #define FLASK_LOAD              1
@@ -167,6 +173,7 @@ struct xen_flask_op {
 #define FLASK_ADD_OCONTEXT      21
 #define FLASK_DEL_OCONTEXT      22
 #define FLASK_GET_PEER_SID      23
+#define FLASK_RELABEL_DOMAIN    24
     uint32_t interface_version; /* XEN_FLASK_INTERFACE_VERSION */
     union {
         struct xen_flask_load load;
@@ -185,6 +192,7 @@ struct xen_flask_op {
         /* FLASK_ADD_OCONTEXT, FLASK_DEL_OCONTEXT */
         struct xen_flask_ocontext ocontext;
         struct xen_flask_peersid peersid;
+        struct xen_flask_relabel relabel;
     } u;
 };
 typedef struct xen_flask_op xen_flask_op_t;
diff --git a/xen/xsm/flask/flask_op.c b/xen/xsm/flask/flask_op.c
index bd4db37..9c8dfe7 100644
--- a/xen/xsm/flask/flask_op.c
+++ b/xen/xsm/flask/flask_op.c
@@ -573,6 +573,51 @@ static int flask_get_peer_sid(struct xen_flask_peersid *arg)
     return rv;
 }
 
+static int flask_relabel_domain(struct xen_flask_relabel *arg)
+{
+    int rc;
+    struct domain *d;
+    struct domain_security_struct *csec = current->domain->ssid;
+    struct domain_security_struct *dsec;
+    struct avc_audit_data ad;
+    AVC_AUDIT_DATA_INIT(&ad, NONE);
+
+    d = rcu_lock_domain_by_any_id(arg->domid);
+    if ( d == NULL )
+        return -ESRCH;
+
+    ad.sdom = current->domain;
+    ad.tdom = d;
+    dsec = d->ssid;
+
+    if ( arg->domid == DOMID_SELF )
+    {
+        rc = avc_has_perm(dsec->sid, arg->sid, SECCLASS_DOMAIN2, DOMAIN2__RELABELSELF, &ad);
+        if ( rc )
+            goto out;
+    }
+    else
+    {
+        rc = avc_has_perm(csec->sid, dsec->sid, SECCLASS_DOMAIN2, DOMAIN2__RELABELFROM, &ad);
+        if ( rc )
+            goto out;
+
+        rc = avc_has_perm(csec->sid, arg->sid, SECCLASS_DOMAIN2, DOMAIN2__RELABELTO, &ad);
+        if ( rc )
+            goto out;
+    }
+
+    rc = avc_has_perm(dsec->sid, arg->sid, SECCLASS_DOMAIN, DOMAIN__TRANSITION, &ad);
+    if ( rc )
+        goto out;
+
+    dsec->sid = arg->sid;
+
+ out:
+    rcu_unlock_domain(d);
+    return rc;
+}
+
 long do_flask_op(XEN_GUEST_HANDLE(xsm_op_t) u_flask_op)
 {
     xen_flask_op_t op;
@@ -680,6 +725,10 @@ long do_flask_op(XEN_GUEST_HANDLE(xsm_op_t) u_flask_op)
         rv = flask_get_peer_sid(&op.u.peersid);
         break;
 
+    case FLASK_RELABEL_DOMAIN:
+        rv = flask_relabel_domain(&op.u.relabel);
+        break;
+
     default:
         rv = -ENOSYS;
     }
diff --git a/xen/xsm/flask/include/av_perm_to_string.h b/xen/xsm/flask/include/av_perm_to_string.h
index 17a1c36..e7e2058 100644
--- a/xen/xsm/flask/include/av_perm_to_string.h
+++ b/xen/xsm/flask/include/av_perm_to_string.h
@@ -61,6 +61,9 @@
    S_(SECCLASS_DOMAIN, DOMAIN__SETPODTARGET, "setpodtarget")
    S_(SECCLASS_DOMAIN, DOMAIN__SET_MISC_INFO, "set_misc_info")
    S_(SECCLASS_DOMAIN, DOMAIN__SET_VIRQ_HANDLER, "set_virq_handler")
+   S_(SECCLASS_DOMAIN2, DOMAIN2__RELABELFROM, "relabelfrom")
+   S_(SECCLASS_DOMAIN2, DOMAIN2__RELABELTO, "relabelto")
+   S_(SECCLASS_DOMAIN2, DOMAIN2__RELABELSELF, "relabelself")
    S_(SECCLASS_HVM, HVM__SETHVMC, "sethvmc")
    S_(SECCLASS_HVM, HVM__GETHVMC, "gethvmc")
    S_(SECCLASS_HVM, HVM__SETPARAM, "setparam")
diff --git a/xen/xsm/flask/include/av_permissions.h b/xen/xsm/flask/include/av_permissions.h
index 42eaf81..cb1c5dc 100644
--- a/xen/xsm/flask/include/av_permissions.h
+++ b/xen/xsm/flask/include/av_permissions.h
@@ -63,6 +63,10 @@
 #define DOMAIN__SET_MISC_INFO                     0x40000000UL
 #define DOMAIN__SET_VIRQ_HANDLER                  0x80000000UL
 
+#define DOMAIN2__RELABELFROM                      0x00000001UL
+#define DOMAIN2__RELABELTO                        0x00000002UL
+#define DOMAIN2__RELABELSELF                      0x00000004UL
+
 #define HVM__SETHVMC                              0x00000001UL
 #define HVM__GETHVMC                              0x00000002UL
 #define HVM__SETPARAM                             0x00000004UL
diff --git a/xen/xsm/flask/include/class_to_string.h b/xen/xsm/flask/include/class_to_string.h
index ab55700..7716645 100644
--- a/xen/xsm/flask/include/class_to_string.h
+++ b/xen/xsm/flask/include/class_to_string.h
@@ -5,6 +5,7 @@
     S_("null")
     S_("xen")
     S_("domain")
+    S_("domain2")
     S_("hvm")
     S_("mmu")
     S_("resource")
diff --git a/xen/xsm/flask/include/flask.h b/xen/xsm/flask/include/flask.h
index 6d29c5a..3bff998 100644
--- a/xen/xsm/flask/include/flask.h
+++ b/xen/xsm/flask/include/flask.h
@@ -7,13 +7,14 @@
  */
 #define SECCLASS_XEN                                     1
 #define SECCLASS_DOMAIN                                  2
-#define SECCLASS_HVM                                     3
-#define SECCLASS_MMU                                     4
-#define SECCLASS_RESOURCE                                5
-#define SECCLASS_SHADOW                                  6
-#define SECCLASS_EVENT                                   7
-#define SECCLASS_GRANT                                   8
-#define SECCLASS_SECURITY                                9
+#define SECCLASS_DOMAIN2                                 3
+#define SECCLASS_HVM                                     4
+#define SECCLASS_MMU                                     5
+#define SECCLASS_RESOURCE                                6
+#define SECCLASS_SHADOW                                  7
+#define SECCLASS_EVENT                                   8
+#define SECCLASS_GRANT                                   9
+#define SECCLASS_SECURITY                                10
 
 /*
  * Security identifier indices for initial entities
-- 
1.7.11.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 17 15:24:24 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 15:24:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDdBF-0003gR-Dw; Mon, 17 Sep 2012 15:24:13 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1TDdBB-0003as-N2
	for xen-devel@lists.xen.org; Mon, 17 Sep 2012 15:24:10 +0000
Received: from [85.158.139.211:53639] by server-10.bemta-5.messagelabs.com id
	80/9C-10969-99047505; Mon, 17 Sep 2012 15:24:09 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-3.tower-206.messagelabs.com!1347895447!18886541!1
X-Originating-IP: [63.239.67.9]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21536 invoked from network); 17 Sep 2012 15:24:07 -0000
Received: from emvm-gh1-uea08.nsa.gov (HELO nsa.gov) (63.239.67.9)
	by server-3.tower-206.messagelabs.com with SMTP;
	17 Sep 2012 15:24:07 -0000
X-TM-IMSS-Message-ID: <538040920012ace3@nsa.gov>
Received: from tarius.tycho.ncsc.mil ([144.51.3.1]) by nsa.gov ([63.239.67.9])
	with ESMTP (TREND IMSS SMTP Service 7.1) id 538040920012ace3 ;
	Mon, 17 Sep 2012 11:23:47 -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 q8HFO0xi027504; 
	Mon, 17 Sep 2012 11:24:05 -0400
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xen.org
Date: Mon, 17 Sep 2012 11:23:40 -0400
Message-Id: <1347895425-17959-19-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.11.4
In-Reply-To: <1347895425-17959-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1347895425-17959-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Tim Deegan <tim@xen.org>, dgdegra@tycho.nsa.gov, keir@xen.org,
	Jan Beulich <jbeulich@suse.com>
Subject: [Xen-devel] [PATCH 18/23] arch/x86: Add missing mem_sharing XSM
	hooks
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This patch adds splits up the mem_sharing and mem_event XSM hooks to
better cover what the code is doing. It also changes the utility
function get_mem_event_op_target to rcu_lock_live_remote_domain_by_id
because there is no mm-specific logic in there.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Cc: Keir Fraser <keir@xen.org>
Cc: Jan Beulich <jbeulich@suse.com>
Cc: Tim Deegan <tim@xen.org>
---
 tools/flask/policy/policy/flask/access_vectors |  1 +
 xen/arch/x86/domctl.c                          |  8 ++---
 xen/arch/x86/mm/mem_event.c                    | 41 ++++++++------------------
 xen/arch/x86/mm/mem_sharing.c                  | 25 +++++++++++++---
 xen/common/domain.c                            | 15 ++++++++++
 xen/include/asm-x86/mem_event.h                |  1 -
 xen/include/xen/sched.h                        |  6 ++++
 xen/include/xsm/dummy.h                        | 23 ++++++++++++++-
 xen/include/xsm/xsm.h                          | 24 +++++++++++++--
 xen/xsm/dummy.c                                |  5 +++-
 xen/xsm/flask/hooks.c                          | 25 ++++++++++++++--
 xen/xsm/flask/include/av_perm_to_string.h      |  1 +
 xen/xsm/flask/include/av_permissions.h         |  1 +
 13 files changed, 130 insertions(+), 46 deletions(-)

diff --git a/tools/flask/policy/policy/flask/access_vectors b/tools/flask/policy/policy/flask/access_vectors
index ea65e45..45ac437 100644
--- a/tools/flask/policy/policy/flask/access_vectors
+++ b/tools/flask/policy/policy/flask/access_vectors
@@ -102,6 +102,7 @@ class hvm
     mem_sharing
     audit_p2m
     send_irq
+    share_mem
 }
 
 class event
diff --git a/xen/arch/x86/domctl.c b/xen/arch/x86/domctl.c
index 24e2d93..7062f02 100644
--- a/xen/arch/x86/domctl.c
+++ b/xen/arch/x86/domctl.c
@@ -1447,10 +1447,8 @@ long arch_do_domctl(
         d = rcu_lock_domain_by_id(domctl->domain);
         if ( d != NULL )
         {
-            ret = xsm_mem_event(d);
-            if ( !ret )
-                ret = mem_event_domctl(d, &domctl->u.mem_event_op,
-                                       guest_handle_cast(u_domctl, void));
+            ret = mem_event_domctl(d, &domctl->u.mem_event_op,
+                                   guest_handle_cast(u_domctl, void));
             rcu_unlock_domain(d);
             copy_to_guest(u_domctl, domctl, 1);
         } 
@@ -1506,7 +1504,7 @@ long arch_do_domctl(
         d = rcu_lock_domain_by_id(domctl->domain);
         if ( d != NULL )
         {
-            ret = xsm_mem_event(d);
+            ret = xsm_mem_event_setup(d);
             if ( !ret ) {
                 p2m = p2m_get_hostp2m(d);
                 p2m->access_required = domctl->u.access_required.access_required;
diff --git a/xen/arch/x86/mm/mem_event.c b/xen/arch/x86/mm/mem_event.c
index d728889..950209b 100644
--- a/xen/arch/x86/mm/mem_event.c
+++ b/xen/arch/x86/mm/mem_event.c
@@ -29,6 +29,7 @@
 #include <asm/mem_paging.h>
 #include <asm/mem_access.h>
 #include <asm/mem_sharing.h>
+#include <xsm/xsm.h>
 
 /* for public/io/ring.h macros */
 #define xen_mb()   mb()
@@ -439,35 +440,19 @@ static void mem_sharing_notification(struct vcpu *v, unsigned int port)
         mem_sharing_sharing_resume(v->domain);
 }
 
-struct domain *get_mem_event_op_target(uint32_t domain, int *rc)
-{
-    struct domain *d;
-
-    /* Get the target domain */
-    *rc = rcu_lock_remote_target_domain_by_id(domain, &d);
-    if ( *rc != 0 )
-        return NULL;
-
-    /* Not dying? */
-    if ( d->is_dying )
-    {
-        rcu_unlock_domain(d);
-        *rc = -EINVAL;
-        return NULL;
-    }
-    
-    return d;
-}
-
 int do_mem_event_op(int op, uint32_t domain, void *arg)
 {
     int ret;
     struct domain *d;
 
-    d = get_mem_event_op_target(domain, &ret);
-    if ( !d )
+    ret = rcu_lock_live_remote_domain_by_id(domain, &d);
+    if ( ret )
         return ret;
 
+    ret = xsm_mem_event_op(d, op);
+    if ( ret )
+        goto out;
+
     switch (op)
     {
         case XENMEM_paging_op:
@@ -483,6 +468,7 @@ int do_mem_event_op(int op, uint32_t domain, void *arg)
             ret = -ENOSYS;
     }
 
+ out:
     rcu_unlock_domain(d);
     return ret;
 }
@@ -516,6 +502,10 @@ int mem_event_domctl(struct domain *d, xen_domctl_mem_event_op_t *mec,
 {
     int rc;
 
+    rc = xsm_mem_event_control(d, mec->mode, mec->op);
+    if ( rc )
+        return rc;
+
     if ( unlikely(d == current->domain) )
     {
         gdprintk(XENLOG_INFO, "Tried to do a memory event op on itself.\n");
@@ -537,13 +527,6 @@ int mem_event_domctl(struct domain *d, xen_domctl_mem_event_op_t *mec,
         return -EINVAL;
     }
 
-    /* TODO: XSM hook */
-#if 0
-    rc = xsm_mem_event_control(d, mec->op);
-    if ( rc )
-        return rc;
-#endif
-
     rc = -ENOSYS;
 
     switch ( mec->mode )
diff --git a/xen/arch/x86/mm/mem_sharing.c b/xen/arch/x86/mm/mem_sharing.c
index 5103285..9229b83 100644
--- a/xen/arch/x86/mm/mem_sharing.c
+++ b/xen/arch/x86/mm/mem_sharing.c
@@ -34,6 +34,7 @@
 #include <asm/atomic.h>
 #include <xen/rcupdate.h>
 #include <asm/event.h>
+#include <xsm/xsm.h>
 
 #include "mm-locks.h"
 
@@ -1345,10 +1346,18 @@ int mem_sharing_memop(struct domain *d, xen_mem_sharing_op_t *mec)
             if ( !mem_sharing_enabled(d) )
                 return -EINVAL;
 
-            cd = get_mem_event_op_target(mec->u.share.client_domain, &rc);
-            if ( !cd )
+            rc = rcu_lock_live_remote_domain_by_id(mec->u.share.client_domain,
+                                                   &cd);
+            if ( rc )
                 return rc;
 
+            rc = xsm_mem_sharing_op(d, cd, mec->op);
+            if ( rc )
+            {
+                rcu_unlock_domain(cd);
+                return rc;
+            }
+
             if ( !mem_sharing_enabled(cd) )
             {
                 rcu_unlock_domain(cd);
@@ -1401,10 +1410,18 @@ int mem_sharing_memop(struct domain *d, xen_mem_sharing_op_t *mec)
             if ( !mem_sharing_enabled(d) )
                 return -EINVAL;
 
-            cd = get_mem_event_op_target(mec->u.share.client_domain, &rc);
-            if ( !cd )
+            rc = rcu_lock_live_remote_domain_by_id(mec->u.share.client_domain,
+                                                   &cd);
+            if ( rc )
                 return rc;
 
+            rc = xsm_mem_sharing_op(d, cd, mec->op);
+            if ( rc )
+            {
+                rcu_unlock_domain(cd);
+                return rc;
+            }
+
             if ( !mem_sharing_enabled(cd) )
             {
                 rcu_unlock_domain(cd);
diff --git a/xen/common/domain.c b/xen/common/domain.c
index 52489b3..a205557 100644
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -475,6 +475,21 @@ int rcu_lock_remote_domain_by_id(domid_t dom, struct domain **d)
     return 0;
 }
 
+int rcu_lock_live_remote_domain_by_id(domid_t dom, struct domain **d)
+{
+    int rv;
+    rv = rcu_lock_remote_domain_by_id(dom, d);
+    if ( rv )
+        return rv;
+    if ( (*d)->is_dying )
+    {
+        rcu_unlock_domain(*d);
+        return -EINVAL;
+    }
+
+    return 0;
+}
+
 int domain_kill(struct domain *d)
 {
     int rc = 0;
diff --git a/xen/include/asm-x86/mem_event.h b/xen/include/asm-x86/mem_event.h
index 23d71c1..448be4f 100644
--- a/xen/include/asm-x86/mem_event.h
+++ b/xen/include/asm-x86/mem_event.h
@@ -62,7 +62,6 @@ void mem_event_put_request(struct domain *d, struct mem_event_domain *med,
 int mem_event_get_response(struct domain *d, struct mem_event_domain *med,
                            mem_event_response_t *rsp);
 
-struct domain *get_mem_event_op_target(uint32_t domain, int *rc);
 int do_mem_event_op(int op, uint32_t domain, void *arg);
 int mem_event_domctl(struct domain *d, xen_domctl_mem_event_op_t *mec,
                      XEN_GUEST_HANDLE(void) u_domctl);
diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
index b0def4a..b29ed13 100644
--- a/xen/include/xen/sched.h
+++ b/xen/include/xen/sched.h
@@ -471,6 +471,12 @@ int rcu_lock_remote_target_domain_by_id(domid_t dom, struct domain **d);
  */
 int rcu_lock_remote_domain_by_id(domid_t dom, struct domain **d);
 
+/*
+ * As rcu_lock_remote_domain_by_id() but will fail EINVAL if the domain is
+ * dying.
+ */
+int rcu_lock_live_remote_domain_by_id(domid_t dom, struct domain **d);
+
 /* Finish a RCU critical region started by rcu_lock_domain_by_id(). */
 static inline void rcu_unlock_domain(struct domain *d)
 {
diff --git a/xen/include/xsm/dummy.h b/xen/include/xsm/dummy.h
index 626a332..5fb0afe 100644
--- a/xen/include/xsm/dummy.h
+++ b/xen/include/xsm/dummy.h
@@ -551,16 +551,37 @@ static XSM_DEFAULT(int, hvm_inject_msi) (struct domain *d)
     return 0;
 }
 
-static XSM_DEFAULT(int, mem_event) (struct domain *d)
+static XSM_DEFAULT(int, mem_event_setup) (struct domain *d)
 {
     return 0;
 }
 
+static XSM_DEFAULT(int, mem_event_control) (struct domain *d, int mode, int op)
+{
+    if ( !IS_PRIV(current->domain) )
+        return -EPERM;
+    return 0;
+}
+
+static XSM_DEFAULT(int, mem_event_op) (struct domain *d, int op)
+{
+    if ( !IS_PRIV_FOR(current->domain, d) )
+        return -EPERM;
+    return 0;
+}
+
 static XSM_DEFAULT(int, mem_sharing) (struct domain *d)
 {
     return 0;
 }
 
+static XSM_DEFAULT(int, mem_sharing_op) (struct domain *d, struct domain *cd, int op)
+{
+    if ( !IS_PRIV_FOR(current->domain, cd) )
+        return -EPERM;
+    return 0;
+}
+
 static XSM_DEFAULT(int, apic) (struct domain *d, int cmd)
 {
     if ( !IS_PRIV(d) )
diff --git a/xen/include/xsm/xsm.h b/xen/include/xsm/xsm.h
index 96e4b13..c08a664 100644
--- a/xen/include/xsm/xsm.h
+++ b/xen/include/xsm/xsm.h
@@ -151,8 +151,11 @@ struct xsm_operations {
     int (*hvm_set_isa_irq_level) (struct domain *d);
     int (*hvm_set_pci_link_route) (struct domain *d);
     int (*hvm_inject_msi) (struct domain *d);
-    int (*mem_event) (struct domain *d);
+    int (*mem_event_setup) (struct domain *d);
+    int (*mem_event_control) (struct domain *d, int mode, int op);
+    int (*mem_event_op) (struct domain *d, int op);
     int (*mem_sharing) (struct domain *d);
+    int (*mem_sharing_op) (struct domain *d, struct domain *cd, int op);
     int (*apic) (struct domain *d, int cmd);
     int (*xen_settime) (void);
     int (*memtype) (uint32_t access);
@@ -663,9 +666,19 @@ static inline int xsm_hvm_inject_msi (struct domain *d)
     return xsm_ops->hvm_inject_msi(d);
 }
 
-static inline int xsm_mem_event (struct domain *d)
+static inline int xsm_mem_event_setup (struct domain *d)
 {
-    return xsm_ops->mem_event(d);
+    return xsm_ops->mem_event_setup(d);
+}
+
+static inline int xsm_mem_event_control (struct domain *d, int mode, int op)
+{
+    return xsm_ops->mem_event_control(d, mode, op);
+}
+
+static inline int xsm_mem_event_op (struct domain *d, int op)
+{
+    return xsm_ops->mem_event_op(d, op);
 }
 
 static inline int xsm_mem_sharing (struct domain *d)
@@ -673,6 +686,11 @@ static inline int xsm_mem_sharing (struct domain *d)
     return xsm_ops->mem_sharing(d);
 }
 
+static inline int xsm_mem_sharing_op (struct domain *d, struct domain *cd, int op)
+{
+    return xsm_ops->mem_sharing_op(d, cd, op);
+}
+
 static inline int xsm_apic (struct domain *d, int cmd)
 {
     return xsm_ops->apic(d, cmd);
diff --git a/xen/xsm/dummy.c b/xen/xsm/dummy.c
index 43e8617..3926b2b 100644
--- a/xen/xsm/dummy.c
+++ b/xen/xsm/dummy.c
@@ -135,8 +135,11 @@ void xsm_fixup_ops (struct xsm_operations *ops)
     set_to_dummy_if_null(ops, hvm_set_isa_irq_level);
     set_to_dummy_if_null(ops, hvm_set_pci_link_route);
     set_to_dummy_if_null(ops, hvm_inject_msi);
-    set_to_dummy_if_null(ops, mem_event);
+    set_to_dummy_if_null(ops, mem_event_setup);
+    set_to_dummy_if_null(ops, mem_event_control);
+    set_to_dummy_if_null(ops, mem_event_op);
     set_to_dummy_if_null(ops, mem_sharing);
+    set_to_dummy_if_null(ops, mem_sharing_op);
     set_to_dummy_if_null(ops, apic);
     set_to_dummy_if_null(ops, xen_settime);
     set_to_dummy_if_null(ops, memtype);
diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
index a242d65..65db2b7 100644
--- a/xen/xsm/flask/hooks.c
+++ b/xen/xsm/flask/hooks.c
@@ -1277,7 +1277,17 @@ static int flask_hvm_inject_msi(struct domain *d)
     return current_has_perm(d, SECCLASS_HVM, HVM__SEND_IRQ);
 }
 
-static int flask_mem_event(struct domain *d)
+static int flask_mem_event_setup(struct domain *d)
+{
+    return current_has_perm(d, SECCLASS_HVM, HVM__MEM_EVENT);
+}
+
+static int flask_mem_event_control(struct domain *d, int mode, int op)
+{
+    return current_has_perm(d, SECCLASS_HVM, HVM__MEM_EVENT);
+}
+
+static int flask_mem_event_op(struct domain *d, int op)
 {
     return current_has_perm(d, SECCLASS_HVM, HVM__MEM_EVENT);
 }
@@ -1287,6 +1297,14 @@ static int flask_mem_sharing(struct domain *d)
     return current_has_perm(d, SECCLASS_HVM, HVM__MEM_SHARING);
 }
 
+static int flask_mem_sharing_op(struct domain *d, struct domain *cd, int op)
+{
+    int rc = current_has_perm(cd, SECCLASS_HVM, HVM__MEM_SHARING);
+    if ( rc )
+        return rc;
+    return domain_has_perm(d, cd, SECCLASS_HVM, HVM__SHARE_MEM);
+}
+
 static int flask_apic(struct domain *d, int cmd)
 {
     u32 perm;
@@ -1736,8 +1754,11 @@ static struct xsm_operations flask_ops = {
     .hvm_set_isa_irq_level = flask_hvm_set_isa_irq_level,
     .hvm_set_pci_link_route = flask_hvm_set_pci_link_route,
     .hvm_inject_msi = flask_hvm_inject_msi,
-    .mem_event = flask_mem_event,
+    .mem_event_setup = flask_mem_event_setup,
+    .mem_event_control = flask_mem_event_control,
+    .mem_event_op = flask_mem_event_op,
     .mem_sharing = flask_mem_sharing,
+    .mem_sharing_op = flask_mem_sharing_op,
     .apic = flask_apic,
     .xen_settime = flask_xen_settime,
     .memtype = flask_memtype,
diff --git a/xen/xsm/flask/include/av_perm_to_string.h b/xen/xsm/flask/include/av_perm_to_string.h
index 894910c..186f1fa 100644
--- a/xen/xsm/flask/include/av_perm_to_string.h
+++ b/xen/xsm/flask/include/av_perm_to_string.h
@@ -84,6 +84,7 @@
    S_(SECCLASS_HVM, HVM__MEM_SHARING, "mem_sharing")
    S_(SECCLASS_HVM, HVM__AUDIT_P2M, "audit_p2m")
    S_(SECCLASS_HVM, HVM__SEND_IRQ, "send_irq")
+   S_(SECCLASS_HVM, HVM__SHARE_MEM, "share_mem")
    S_(SECCLASS_EVENT, EVENT__BIND, "bind")
    S_(SECCLASS_EVENT, EVENT__SEND, "send")
    S_(SECCLASS_EVENT, EVENT__STATUS, "status")
diff --git a/xen/xsm/flask/include/av_permissions.h b/xen/xsm/flask/include/av_permissions.h
index 1bdb515..b3831f6 100644
--- a/xen/xsm/flask/include/av_permissions.h
+++ b/xen/xsm/flask/include/av_permissions.h
@@ -87,6 +87,7 @@
 #define HVM__MEM_SHARING                          0x00001000UL
 #define HVM__AUDIT_P2M                            0x00002000UL
 #define HVM__SEND_IRQ                             0x00004000UL
+#define HVM__SHARE_MEM                            0x00008000UL
 
 #define EVENT__BIND                               0x00000001UL
 #define EVENT__SEND                               0x00000002UL
-- 
1.7.11.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 17 15:24:24 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 15:24:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDdBE-0003em-47; Mon, 17 Sep 2012 15:24:12 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1TDdBB-0003as-AD
	for xen-devel@lists.xen.org; Mon, 17 Sep 2012 15:24:09 +0000
Received: from [85.158.139.211:11569] by server-10.bemta-5.messagelabs.com id
	E3/8C-10969-89047505; Mon, 17 Sep 2012 15:24:08 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-2.tower-206.messagelabs.com!1347895447!18880334!1
X-Originating-IP: [63.239.67.9]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29739 invoked from network); 17 Sep 2012 15:24:07 -0000
Received: from emvm-gh1-uea08.nsa.gov (HELO nsa.gov) (63.239.67.9)
	by server-2.tower-206.messagelabs.com with SMTP;
	17 Sep 2012 15:24:07 -0000
X-TM-IMSS-Message-ID: <5380417c0012ace4@nsa.gov>
Received: from tarius.tycho.ncsc.mil ([144.51.3.1]) by nsa.gov ([63.239.67.9])
	with ESMTP (TREND IMSS SMTP Service 7.1) id 5380417c0012ace4 ;
	Mon, 17 Sep 2012 11:23:47 -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 q8HFO0xj027504; 
	Mon, 17 Sep 2012 11:24:05 -0400
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xen.org
Date: Mon, 17 Sep 2012 11:23:41 -0400
Message-Id: <1347895425-17959-20-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.11.4
In-Reply-To: <1347895425-17959-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1347895425-17959-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Tim Deegan <tim@xen.org>, dgdegra@tycho.nsa.gov, keir@xen.org,
	Jan Beulich <jbeulich@suse.com>
Subject: [Xen-devel] [PATCH 19/23] arch/x86: check remote MMIO remap
	permissions
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 domain is mapping pages from a different pg_owner domain, the
iomem_access checks are currently only applied to the pg_owner domain,
potentially allowing the current domain to bypass its more restrictive
iomem_access policy using another domain that it has access to.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Cc: Keir Fraser <keir@xen.org>
Cc: Jan Beulich <jbeulich@suse.com>
Cc: Tim Deegan <tim@xen.org>
---
 xen/arch/x86/mm.c | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
index 5c6ea2d..c0c2bf3 100644
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -754,6 +754,18 @@ get_page_from_l1e(
             return -EINVAL;
         }
 
+        if ( pg_owner != curr->domain &&
+             !iomem_access_permitted(curr->domain, mfn, mfn) )
+        {
+            if ( mfn != (PADDR_MASK >> PAGE_SHIFT) ) /* INVALID_MFN? */
+            {
+                MEM_LOG("Domain %u attempted to map I/O space %08lx in domain %u",
+                        curr->domain->domain_id, mfn, pg_owner->domain_id);
+                return -EPERM;
+            }
+            return -EINVAL;
+        }
+
         if ( !(l1f & _PAGE_RW) ||
              !rangeset_contains_singleton(mmio_ro_ranges, mfn) )
             return 0;
-- 
1.7.11.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 17 15:24:24 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 15:24:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDdBG-0003i9-SV; Mon, 17 Sep 2012 15:24:14 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1TDdBE-0003aT-1p
	for xen-devel@lists.xen.org; Mon, 17 Sep 2012 15:24:12 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-5.tower-27.messagelabs.com!1347895444!7944810!1
X-Originating-IP: [63.239.67.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5301 invoked from network); 17 Sep 2012 15:24:05 -0000
Received: from emvm-gh1-uea09.nsa.gov (HELO nsa.gov) (63.239.67.10)
	by server-5.tower-27.messagelabs.com with SMTP;
	17 Sep 2012 15:24:05 -0000
X-TM-IMSS-Message-ID: <537ff17900131d7a@nsa.gov>
Received: from tarius.tycho.ncsc.mil ([144.51.3.1]) by nsa.gov
	([63.239.67.10]) with ESMTP (TREND IMSS SMTP Service 7.1) id
	537ff17900131d7a ; Mon, 17 Sep 2012 11:25:59 -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 q8HFO0xa027504; 
	Mon, 17 Sep 2012 11:24:03 -0400
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xen.org
Date: Mon, 17 Sep 2012 11:23:32 -0400
Message-Id: <1347895425-17959-11-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.11.4
In-Reply-To: <1347895425-17959-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1347895425-17959-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: dgdegra@tycho.nsa.gov, keir@xen.org, Jan Beulich <jbeulich@suse.com>
Subject: [Xen-devel] [PATCH 10/23] xen: use XSM instead of IS_PRIV where
	duplicated
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

The Xen hypervisor has two basic access control function calls: IS_PRIV
and the xsm_* functions. Most privileged operations currently require
that both checks succeed, and many times the checks are at different
locations in the code. This patch eliminates the explicit and implicit
IS_PRIV checks that are duplicated in XSM hooks.

When XSM_ENABLE is not defined or when the dummy XSM module is used,
this patch should not change any functionality. Because the locations of
privilege checks have sometimes moved below argument validation, error
returns of some functions may change from EPERM to EINVAL or ESRCH if
called with invalid arguments and from a domain without permission to
perform the operation.

Some checks are removed due to non-obvious duplicates in their callers:

 * acpi_enter_sleep is checked in XENPF_enter_acpi_sleep
 * map_domain_pirq has IS_PRIV_FOR checked in its callers:
   * physdev_map_pirq checks when acquiring the RCU lock
   * ioapic_guest_write is checked in PHYSDEVOP_apic_write
 * PHYSDEVOP_{manage_pci_add,manage_pci_add_ext,pci_device_add} are
   checked by xsm_resource_plug_pci in pci_add_device
 * PHYSDEVOP_manage_pci_remove is checked by xsm_resource_unplug_pci
   in pci_remove_device
 * PHYSDEVOP_{restore_msi,restore_msi_ext} are checked by
   xsm_resource_setup_pci in pci_restore_msi_state
 * do_console_io has changed to IS_PRIV from an explicit domid==0

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Cc: Keir Fraser <keir@xen.org>
Cc: Jan Beulich <jbeulich@suse.com>
---
 xen/arch/x86/acpi/power.c     |  2 +-
 xen/arch/x86/cpu/mcheck/mce.c |  3 ---
 xen/arch/x86/irq.c            |  3 +--
 xen/arch/x86/mm.c             |  3 ---
 xen/arch/x86/physdev.c        | 54 ++-----------------------------------------
 xen/common/kexec.c            |  3 ---
 xen/common/schedule.c         |  6 -----
 xen/drivers/char/console.c    |  6 -----
 xen/include/xsm/dummy.h       | 28 ++++++++++++++++++++++
 xen/xsm/flask/hooks.c         |  5 ++--
 10 files changed, 35 insertions(+), 78 deletions(-)

diff --git a/xen/arch/x86/acpi/power.c b/xen/arch/x86/acpi/power.c
index 9e1f989..c7b37ef 100644
--- a/xen/arch/x86/acpi/power.c
+++ b/xen/arch/x86/acpi/power.c
@@ -238,7 +238,7 @@ static long enter_state_helper(void *data)
  */
 int acpi_enter_sleep(struct xenpf_enter_acpi_sleep *sleep)
 {
-    if ( !IS_PRIV(current->domain) || !acpi_sinfo.pm1a_cnt_blk.address )
+    if ( !acpi_sinfo.pm1a_cnt_blk.address )
         return -EPERM;
 
     /* Sanity check */
diff --git a/xen/arch/x86/cpu/mcheck/mce.c b/xen/arch/x86/cpu/mcheck/mce.c
index f60d14f..9578194 100644
--- a/xen/arch/x86/cpu/mcheck/mce.c
+++ b/xen/arch/x86/cpu/mcheck/mce.c
@@ -1372,9 +1372,6 @@ long do_mca(XEN_GUEST_HANDLE(xen_mc_t) u_xen_mc)
     struct xen_mc_msrinject *mc_msrinject;
     struct xen_mc_mceinject *mc_mceinject;
 
-    if (!IS_PRIV(v->domain) )
-        return x86_mcerr(NULL, -EPERM);
-
     ret = xsm_do_mca();
     if ( ret )
         return x86_mcerr(NULL, ret);
diff --git a/xen/arch/x86/irq.c b/xen/arch/x86/irq.c
index c87027b..70b0f03 100644
--- a/xen/arch/x86/irq.c
+++ b/xen/arch/x86/irq.c
@@ -1853,8 +1853,7 @@ int map_domain_pirq(
     ASSERT(spin_is_locked(&d->event_lock));
 
     if ( !IS_PRIV(current->domain) &&
-         !(IS_PRIV_FOR(current->domain, d) &&
-           irq_access_permitted(current->domain, pirq)))
+         !irq_access_permitted(current->domain, pirq))
         return -EPERM;
 
     if ( pirq < 0 || pirq >= d->nr_pirqs || irq < 0 || irq >= nr_irqs )
diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
index 4ea5334..b370300 100644
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -4488,9 +4488,6 @@ long arch_memory_op(int op, XEN_GUEST_HANDLE(void) arg)
         XEN_GUEST_HANDLE(e820entry_t) buffer;
         unsigned int i;
 
-        if ( !IS_PRIV(current->domain) )
-            return -EINVAL;
-
         rc = xsm_machine_memory_map();
         if ( rc )
             return rc;
diff --git a/xen/arch/x86/physdev.c b/xen/arch/x86/physdev.c
index 13b85da..515dca3 100644
--- a/xen/arch/x86/physdev.c
+++ b/xen/arch/x86/physdev.c
@@ -109,12 +109,6 @@ int physdev_map_pirq(domid_t domid, int type, int *index, int *pirq_p,
     if ( ret )
         return ret;
 
-    if ( !IS_PRIV_FOR(current->domain, d) )
-    {
-        ret = -EPERM;
-        goto free_domain;
-    }
-
     /* Verify or get irq. */
     switch ( type )
     {
@@ -238,10 +232,6 @@ int physdev_unmap_pirq(domid_t domid, int pirq)
             goto free_domain;
     }
 
-    ret = -EPERM;
-    if ( !IS_PRIV_FOR(current->domain, d) )
-        goto free_domain;
-
     ret = xsm_unmap_domain_pirq(d, domain_pirq_to_irq(d, pirq));
     if ( ret )
         goto free_domain;
@@ -433,9 +423,6 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_HANDLE(void) arg)
         ret = -EFAULT;
         if ( copy_from_guest(&apic, arg, 1) != 0 )
             break;
-        ret = -EPERM;
-        if ( !IS_PRIV(v->domain) )
-            break;
         ret = xsm_apic(v->domain, cmd);
         if ( ret )
             break;
@@ -450,9 +437,6 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_HANDLE(void) arg)
         ret = -EFAULT;
         if ( copy_from_guest(&apic, arg, 1) != 0 )
             break;
-        ret = -EPERM;
-        if ( !IS_PRIV(v->domain) )
-            break;
         ret = xsm_apic(v->domain, cmd);
         if ( ret )
             break;
@@ -467,8 +451,8 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_HANDLE(void) arg)
         if ( copy_from_guest(&irq_op, arg, 1) != 0 )
             break;
 
-        ret = -EPERM;
-        if ( !IS_PRIV(v->domain) )
+        ret = xsm_apic(v->domain, cmd);
+        if ( ret )
             break;
 
         /* Vector is only used by hypervisor, and dom0 shouldn't
@@ -517,9 +501,6 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_HANDLE(void) arg)
 
     case PHYSDEVOP_manage_pci_add: {
         struct physdev_manage_pci manage_pci;
-        ret = -EPERM;
-        if ( !IS_PRIV(v->domain) )
-            break;
         ret = -EFAULT;
         if ( copy_from_guest(&manage_pci, arg, 1) != 0 )
             break;
@@ -530,9 +511,6 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_HANDLE(void) arg)
 
     case PHYSDEVOP_manage_pci_remove: {
         struct physdev_manage_pci manage_pci;
-        ret = -EPERM;
-        if ( !IS_PRIV(v->domain) )
-            break;
         ret = -EFAULT;
         if ( copy_from_guest(&manage_pci, arg, 1) != 0 )
             break;
@@ -545,10 +523,6 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_HANDLE(void) arg)
         struct physdev_manage_pci_ext manage_pci_ext;
         struct pci_dev_info pdev_info;
 
-        ret = -EPERM;
-        if ( !IS_PRIV(current->domain) )
-            break;
-
         ret = -EFAULT;
         if ( copy_from_guest(&manage_pci_ext, arg, 1) != 0 )
             break;
@@ -571,10 +545,6 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_HANDLE(void) arg)
         struct physdev_pci_device_add add;
         struct pci_dev_info pdev_info;
 
-        ret = -EPERM;
-        if ( !IS_PRIV(current->domain) )
-            break;
-
         ret = -EFAULT;
         if ( copy_from_guest(&add, arg, 1) != 0 )
             break;
@@ -595,10 +565,6 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_HANDLE(void) arg)
     case PHYSDEVOP_pci_device_remove: {
         struct physdev_pci_device dev;
 
-        ret = -EPERM;
-        if ( !IS_PRIV(v->domain) )
-            break;
-
         ret = -EFAULT;
         if ( copy_from_guest(&dev, arg, 1) != 0 )
             break;
@@ -610,10 +576,6 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_HANDLE(void) arg)
     case PHYSDEVOP_pci_mmcfg_reserved: {
         struct physdev_pci_mmcfg_reserved info;
 
-        ret = -EPERM;
-        if ( !IS_PRIV(current->domain) )
-            break;
-
         ret = xsm_resource_setup_misc();
         if ( ret )
             break;
@@ -631,10 +593,6 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_HANDLE(void) arg)
         struct physdev_restore_msi restore_msi;
         struct pci_dev *pdev;
 
-        ret = -EPERM;
-        if ( !IS_PRIV(v->domain) )
-            break;
-
         ret = -EFAULT;
         if ( copy_from_guest(&restore_msi, arg, 1) != 0 )
             break;
@@ -650,10 +608,6 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_HANDLE(void) arg)
         struct physdev_pci_device dev;
         struct pci_dev *pdev;
 
-        ret = -EPERM;
-        if ( !IS_PRIV(v->domain) )
-            break;
-
         ret = -EFAULT;
         if ( copy_from_guest(&dev, arg, 1) != 0 )
             break;
@@ -668,10 +622,6 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_HANDLE(void) arg)
     case PHYSDEVOP_setup_gsi: {
         struct physdev_setup_gsi setup_gsi;
 
-        ret = -EPERM;
-        if ( !IS_PRIV(v->domain) )
-            break;
-
         ret = -EFAULT;
         if ( copy_from_guest(&setup_gsi, arg, 1) != 0 )
             break;
diff --git a/xen/common/kexec.c b/xen/common/kexec.c
index 2bc3e33..7dc6f24 100644
--- a/xen/common/kexec.c
+++ b/xen/common/kexec.c
@@ -851,9 +851,6 @@ static int do_kexec_op_internal(unsigned long op, XEN_GUEST_HANDLE(void) uarg,
     unsigned long flags;
     int ret = -EINVAL;
 
-    if ( !IS_PRIV(current->domain) )
-        return -EPERM;
-
     ret = xsm_kexec();
     if ( ret )
         return ret;
diff --git a/xen/common/schedule.c b/xen/common/schedule.c
index eee74be..95142c0 100644
--- a/xen/common/schedule.c
+++ b/xen/common/schedule.c
@@ -919,12 +919,6 @@ ret_t do_sched_op(int cmd, XEN_GUEST_HANDLE(void) arg)
         if ( d == NULL )
             break;
 
-        if ( !IS_PRIV_FOR(current->domain, d) )
-        {
-            rcu_unlock_domain(d);
-            return -EPERM;
-        }
-
         ret = xsm_schedop_shutdown(current->domain, d);
         if ( ret )
         {
diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c
index d97170c..aee3b4b 100644
--- a/xen/drivers/char/console.c
+++ b/xen/drivers/char/console.c
@@ -363,12 +363,6 @@ long do_console_io(int cmd, int count, XEN_GUEST_HANDLE(char) buffer)
     long rc;
     unsigned int idx, len;
 
-#ifndef VERBOSE
-    /* Only domain 0 may access the emergency console. */
-    if ( current->domain->domain_id != 0 )
-        return -EPERM;
-#endif
-
     rc = xsm_console_io(current->domain, cmd);
     if ( rc )
         return rc;
diff --git a/xen/include/xsm/dummy.h b/xen/include/xsm/dummy.h
index 0456bc8..7cb229d 100644
--- a/xen/include/xsm/dummy.h
+++ b/xen/include/xsm/dummy.h
@@ -161,6 +161,8 @@ static XSM_DEFAULT(int, pm_op) (void)
 
 static XSM_DEFAULT(int, do_mca) (void)
 {
+    if ( !IS_PRIV(current->domain) )
+        return -EPERM;
     return 0;
 }
 
@@ -223,6 +225,10 @@ static XSM_DEFAULT(int, memory_stat_reservation) (struct domain *d1, struct doma
 
 static XSM_DEFAULT(int, console_io) (struct domain *d, int cmd)
 {
+#ifndef VERBOSE
+    if ( !IS_PRIV(current->domain) )
+        return -EPERM;
+#endif
     return 0;
 }
 
@@ -233,11 +239,15 @@ static XSM_DEFAULT(int, profile) (struct domain *d, int op)
 
 static XSM_DEFAULT(int, kexec) (void)
 {
+    if ( !IS_PRIV(current->domain) )
+        return -EPERM;
     return 0;
 }
 
 static XSM_DEFAULT(int, schedop_shutdown) (struct domain *d1, struct domain *d2)
 {
+    if ( !IS_PRIV_FOR(d1, d2) )
+        return -EPERM;
     return 0;
 }
 
@@ -336,26 +346,36 @@ static XSM_DEFAULT(int, resource_unplug_core) (void)
 
 static XSM_DEFAULT(int, resource_plug_pci) (uint32_t machine_bdf)
 {
+    if ( !IS_PRIV(current->domain) )
+        return -EPERM;
     return 0;
 }
 
 static XSM_DEFAULT(int, resource_unplug_pci) (uint32_t machine_bdf)
 {
+    if ( !IS_PRIV(current->domain) )
+        return -EPERM;
     return 0;
 }
 
 static XSM_DEFAULT(int, resource_setup_pci) (uint32_t machine_bdf)
 {
+    if ( !IS_PRIV(current->domain) )
+        return -EPERM;
     return 0;
 }
 
 static XSM_DEFAULT(int, resource_setup_gsi) (int gsi)
 {
+    if ( !IS_PRIV(current->domain) )
+        return -EPERM;
     return 0;
 }
 
 static XSM_DEFAULT(int, resource_setup_misc) (void)
 {
+    if ( !IS_PRIV(current->domain) )
+        return -EPERM;
     return 0;
 }
 
@@ -396,6 +416,8 @@ static XSM_DEFAULT(int, map_domain_pirq) (struct domain *d, int irq, void *data)
 
 static XSM_DEFAULT(int, unmap_domain_pirq) (struct domain *d, int irq)
 {
+    if ( !IS_PRIV_FOR(current->domain, d) )
+        return -EPERM;
     return 0;
 }
 
@@ -494,6 +516,8 @@ static XSM_DEFAULT(int, mem_sharing) (struct domain *d)
 
 static XSM_DEFAULT(int, apic) (struct domain *d, int cmd)
 {
+    if ( !IS_PRIV(d) )
+        return -EPERM;
     return 0;
 }
 
@@ -534,6 +558,8 @@ static XSM_DEFAULT(int, efi_call) (void)
 
 static XSM_DEFAULT(int, acpi_sleep) (void)
 {
+    if ( !IS_PRIV(current->domain) )
+        return -EPERM;
     return 0;
 }
 
@@ -549,6 +575,8 @@ static XSM_DEFAULT(int, getidletime) (void)
 
 static XSM_DEFAULT(int, machine_memory_map) (void)
 {
+    if ( !IS_PRIV(current->domain) )
+        return -EPERM;
     return 0;
 }
 
diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
index 7cc06a8..90b0388 100644
--- a/xen/xsm/flask/hooks.c
+++ b/xen/xsm/flask/hooks.c
@@ -1147,10 +1147,11 @@ static int flask_apic(struct domain *d, int cmd)
 
     switch ( cmd )
     {
-    case PHYSDEVOP_APIC_READ:
+    case PHYSDEVOP_apic_read:
+    case PHYSDEVOP_alloc_irq_vector:
         perm = XEN__READAPIC;
         break;
-    case PHYSDEVOP_APIC_WRITE:
+    case PHYSDEVOP_apic_write:
         perm = XEN__WRITEAPIC;
         break;
     default:
-- 
1.7.11.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 17 15:24:24 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 15:24:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDdB9-0003b0-RZ; Mon, 17 Sep 2012 15:24:07 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1TDdB7-0003Zz-MN
	for xen-devel@lists.xen.org; Mon, 17 Sep 2012 15:24:05 +0000
Received: from [85.158.139.211:49323] by server-9.bemta-5.messagelabs.com id
	1F/93-20529-49047505; Mon, 17 Sep 2012 15:24:04 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-16.tower-206.messagelabs.com!1347895443!18930286!1
X-Originating-IP: [63.239.67.9]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18966 invoked from network); 17 Sep 2012 15:24:03 -0000
Received: from emvm-gh1-uea08.nsa.gov (HELO nsa.gov) (63.239.67.9)
	by server-16.tower-206.messagelabs.com with SMTP;
	17 Sep 2012 15:24:03 -0000
X-TM-IMSS-Message-ID: <538031080012accc@nsa.gov>
Received: from tarius.tycho.ncsc.mil ([144.51.3.1]) by nsa.gov ([63.239.67.9])
	with ESMTP (TREND IMSS SMTP Service 7.1) id 538031080012accc ;
	Mon, 17 Sep 2012 11:23:43 -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 q8HFO0xU027504; 
	Mon, 17 Sep 2012 11:24:01 -0400
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xen.org
Date: Mon, 17 Sep 2012 11:23:26 -0400
Message-Id: <1347895425-17959-5-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.11.4
In-Reply-To: <1347895425-17959-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1347895425-17959-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: dgdegra@tycho.nsa.gov, keir@xen.org
Subject: [Xen-devel] [PATCH 04/23] xsm/flask: add domain relabel 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

This adds the ability to change a domain's XSM label after creation.
The new label will be used for all future access checks; however,
existing event channels and memory mappings will remain valid even if
their creation would be denied by the new label.

With appropriate security policy and hooks in the domain builder, this
can be used to create domains that the domain builder does not have
access to after building. It can also be used to allow a domain to drop
privileges - for example, prior to launching a user-supplied kernel
loaded by a pv-grub stubdom.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 tools/flask/policy/policy/flask/access_vectors   |  7 ++++
 tools/flask/policy/policy/flask/security_classes |  1 +
 tools/flask/policy/policy/modules/xen/xen.te     |  2 +-
 xen/include/public/xsm/flask_op.h                |  8 ++++
 xen/xsm/flask/flask_op.c                         | 49 ++++++++++++++++++++++++
 xen/xsm/flask/include/av_perm_to_string.h        |  3 ++
 xen/xsm/flask/include/av_permissions.h           |  4 ++
 xen/xsm/flask/include/class_to_string.h          |  1 +
 xen/xsm/flask/include/flask.h                    | 15 ++++----
 9 files changed, 82 insertions(+), 8 deletions(-)

diff --git a/tools/flask/policy/policy/flask/access_vectors b/tools/flask/policy/policy/flask/access_vectors
index a884312..c7e29ab 100644
--- a/tools/flask/policy/policy/flask/access_vectors
+++ b/tools/flask/policy/policy/flask/access_vectors
@@ -73,6 +73,13 @@ class domain
 	set_virq_handler
 }
 
+class domain2
+{
+	relabelfrom
+	relabelto
+	relabelself
+}
+
 class hvm
 {
     sethvmc
diff --git a/tools/flask/policy/policy/flask/security_classes b/tools/flask/policy/policy/flask/security_classes
index 2ca35d2..ef134a7 100644
--- a/tools/flask/policy/policy/flask/security_classes
+++ b/tools/flask/policy/policy/flask/security_classes
@@ -9,6 +9,7 @@
 
 class xen
 class domain
+class domain2
 class hvm
 class mmu
 class resource
diff --git a/tools/flask/policy/policy/modules/xen/xen.te b/tools/flask/policy/policy/modules/xen/xen.te
index 9cc5240..9550397 100644
--- a/tools/flask/policy/policy/modules/xen/xen.te
+++ b/tools/flask/policy/policy/modules/xen/xen.te
@@ -169,7 +169,7 @@ delegate_devices(dom0_t, domU_t)
 ################################################################################
 
 # Domains must be declared using domain_type
-neverallow * ~domain_type:domain create;
+neverallow * ~domain_type:domain { create transition };
 
 # Resources must be declared using resource_type
 neverallow * ~resource_type:resource use;
diff --git a/xen/include/public/xsm/flask_op.h b/xen/include/public/xsm/flask_op.h
index 1a251c9..233de81 100644
--- a/xen/include/public/xsm/flask_op.h
+++ b/xen/include/public/xsm/flask_op.h
@@ -142,6 +142,12 @@ struct xen_flask_peersid {
     uint32_t sid;
 };
 
+struct xen_flask_relabel {
+    /* IN */
+    uint32_t domid;
+    uint32_t sid;
+};
+
 struct xen_flask_op {
     uint32_t cmd;
 #define FLASK_LOAD              1
@@ -167,6 +173,7 @@ struct xen_flask_op {
 #define FLASK_ADD_OCONTEXT      21
 #define FLASK_DEL_OCONTEXT      22
 #define FLASK_GET_PEER_SID      23
+#define FLASK_RELABEL_DOMAIN    24
     uint32_t interface_version; /* XEN_FLASK_INTERFACE_VERSION */
     union {
         struct xen_flask_load load;
@@ -185,6 +192,7 @@ struct xen_flask_op {
         /* FLASK_ADD_OCONTEXT, FLASK_DEL_OCONTEXT */
         struct xen_flask_ocontext ocontext;
         struct xen_flask_peersid peersid;
+        struct xen_flask_relabel relabel;
     } u;
 };
 typedef struct xen_flask_op xen_flask_op_t;
diff --git a/xen/xsm/flask/flask_op.c b/xen/xsm/flask/flask_op.c
index bd4db37..9c8dfe7 100644
--- a/xen/xsm/flask/flask_op.c
+++ b/xen/xsm/flask/flask_op.c
@@ -573,6 +573,51 @@ static int flask_get_peer_sid(struct xen_flask_peersid *arg)
     return rv;
 }
 
+static int flask_relabel_domain(struct xen_flask_relabel *arg)
+{
+    int rc;
+    struct domain *d;
+    struct domain_security_struct *csec = current->domain->ssid;
+    struct domain_security_struct *dsec;
+    struct avc_audit_data ad;
+    AVC_AUDIT_DATA_INIT(&ad, NONE);
+
+    d = rcu_lock_domain_by_any_id(arg->domid);
+    if ( d == NULL )
+        return -ESRCH;
+
+    ad.sdom = current->domain;
+    ad.tdom = d;
+    dsec = d->ssid;
+
+    if ( arg->domid == DOMID_SELF )
+    {
+        rc = avc_has_perm(dsec->sid, arg->sid, SECCLASS_DOMAIN2, DOMAIN2__RELABELSELF, &ad);
+        if ( rc )
+            goto out;
+    }
+    else
+    {
+        rc = avc_has_perm(csec->sid, dsec->sid, SECCLASS_DOMAIN2, DOMAIN2__RELABELFROM, &ad);
+        if ( rc )
+            goto out;
+
+        rc = avc_has_perm(csec->sid, arg->sid, SECCLASS_DOMAIN2, DOMAIN2__RELABELTO, &ad);
+        if ( rc )
+            goto out;
+    }
+
+    rc = avc_has_perm(dsec->sid, arg->sid, SECCLASS_DOMAIN, DOMAIN__TRANSITION, &ad);
+    if ( rc )
+        goto out;
+
+    dsec->sid = arg->sid;
+
+ out:
+    rcu_unlock_domain(d);
+    return rc;
+}
+
 long do_flask_op(XEN_GUEST_HANDLE(xsm_op_t) u_flask_op)
 {
     xen_flask_op_t op;
@@ -680,6 +725,10 @@ long do_flask_op(XEN_GUEST_HANDLE(xsm_op_t) u_flask_op)
         rv = flask_get_peer_sid(&op.u.peersid);
         break;
 
+    case FLASK_RELABEL_DOMAIN:
+        rv = flask_relabel_domain(&op.u.relabel);
+        break;
+
     default:
         rv = -ENOSYS;
     }
diff --git a/xen/xsm/flask/include/av_perm_to_string.h b/xen/xsm/flask/include/av_perm_to_string.h
index 17a1c36..e7e2058 100644
--- a/xen/xsm/flask/include/av_perm_to_string.h
+++ b/xen/xsm/flask/include/av_perm_to_string.h
@@ -61,6 +61,9 @@
    S_(SECCLASS_DOMAIN, DOMAIN__SETPODTARGET, "setpodtarget")
    S_(SECCLASS_DOMAIN, DOMAIN__SET_MISC_INFO, "set_misc_info")
    S_(SECCLASS_DOMAIN, DOMAIN__SET_VIRQ_HANDLER, "set_virq_handler")
+   S_(SECCLASS_DOMAIN2, DOMAIN2__RELABELFROM, "relabelfrom")
+   S_(SECCLASS_DOMAIN2, DOMAIN2__RELABELTO, "relabelto")
+   S_(SECCLASS_DOMAIN2, DOMAIN2__RELABELSELF, "relabelself")
    S_(SECCLASS_HVM, HVM__SETHVMC, "sethvmc")
    S_(SECCLASS_HVM, HVM__GETHVMC, "gethvmc")
    S_(SECCLASS_HVM, HVM__SETPARAM, "setparam")
diff --git a/xen/xsm/flask/include/av_permissions.h b/xen/xsm/flask/include/av_permissions.h
index 42eaf81..cb1c5dc 100644
--- a/xen/xsm/flask/include/av_permissions.h
+++ b/xen/xsm/flask/include/av_permissions.h
@@ -63,6 +63,10 @@
 #define DOMAIN__SET_MISC_INFO                     0x40000000UL
 #define DOMAIN__SET_VIRQ_HANDLER                  0x80000000UL
 
+#define DOMAIN2__RELABELFROM                      0x00000001UL
+#define DOMAIN2__RELABELTO                        0x00000002UL
+#define DOMAIN2__RELABELSELF                      0x00000004UL
+
 #define HVM__SETHVMC                              0x00000001UL
 #define HVM__GETHVMC                              0x00000002UL
 #define HVM__SETPARAM                             0x00000004UL
diff --git a/xen/xsm/flask/include/class_to_string.h b/xen/xsm/flask/include/class_to_string.h
index ab55700..7716645 100644
--- a/xen/xsm/flask/include/class_to_string.h
+++ b/xen/xsm/flask/include/class_to_string.h
@@ -5,6 +5,7 @@
     S_("null")
     S_("xen")
     S_("domain")
+    S_("domain2")
     S_("hvm")
     S_("mmu")
     S_("resource")
diff --git a/xen/xsm/flask/include/flask.h b/xen/xsm/flask/include/flask.h
index 6d29c5a..3bff998 100644
--- a/xen/xsm/flask/include/flask.h
+++ b/xen/xsm/flask/include/flask.h
@@ -7,13 +7,14 @@
  */
 #define SECCLASS_XEN                                     1
 #define SECCLASS_DOMAIN                                  2
-#define SECCLASS_HVM                                     3
-#define SECCLASS_MMU                                     4
-#define SECCLASS_RESOURCE                                5
-#define SECCLASS_SHADOW                                  6
-#define SECCLASS_EVENT                                   7
-#define SECCLASS_GRANT                                   8
-#define SECCLASS_SECURITY                                9
+#define SECCLASS_DOMAIN2                                 3
+#define SECCLASS_HVM                                     4
+#define SECCLASS_MMU                                     5
+#define SECCLASS_RESOURCE                                6
+#define SECCLASS_SHADOW                                  7
+#define SECCLASS_EVENT                                   8
+#define SECCLASS_GRANT                                   9
+#define SECCLASS_SECURITY                                10
 
 /*
  * Security identifier indices for initial entities
-- 
1.7.11.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 17 15:24:24 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 15:24:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDdBH-0003ib-96; Mon, 17 Sep 2012 15:24:15 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1TDdBE-0003aY-AH
	for xen-devel@lists.xen.org; Mon, 17 Sep 2012 15:24:12 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-7.tower-27.messagelabs.com!1347895445!3647354!1
X-Originating-IP: [63.239.67.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12992 invoked from network); 17 Sep 2012 15:24:06 -0000
Received: from emvm-gh1-uea09.nsa.gov (HELO nsa.gov) (63.239.67.10)
	by server-7.tower-27.messagelabs.com with SMTP;
	17 Sep 2012 15:24:06 -0000
X-TM-IMSS-Message-ID: <537ff52100131d7c@nsa.gov>
Received: from tarius.tycho.ncsc.mil ([144.51.3.1]) by nsa.gov
	([63.239.67.10]) with ESMTP (TREND IMSS SMTP Service 7.1) id
	537ff52100131d7c ; Mon, 17 Sep 2012 11:26:00 -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 q8HFO0xc027504; 
	Mon, 17 Sep 2012 11:24:04 -0400
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xen.org
Date: Mon, 17 Sep 2012 11:23:34 -0400
Message-Id: <1347895425-17959-13-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.11.4
In-Reply-To: <1347895425-17959-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1347895425-17959-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: dgdegra@tycho.nsa.gov, keir@xen.org, Jan Beulich <jbeulich@suse.com>
Subject: [Xen-devel] [PATCH 12/23] arch/x86: convert platform_hypercall to
	use 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

The newly introduced xsm_platform_op hook addresses new sub-ops, while
most ops already have their own XSM hooks.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Cc: Keir Fraser <keir@xen.org>
Cc: Jan Beulich <jbeulich@suse.com>
---
 xen/arch/x86/platform_hypercall.c | 11 ++++++++---
 xen/include/xsm/dummy.h           |  7 +++++++
 xen/include/xsm/xsm.h             |  6 ++++++
 xen/xsm/dummy.c                   |  1 +
 xen/xsm/flask/hooks.c             | 33 +++++++++++++++++++++++++++++++++
 5 files changed, 55 insertions(+), 3 deletions(-)

diff --git a/xen/arch/x86/platform_hypercall.c b/xen/arch/x86/platform_hypercall.c
index 073a2ea..50b5f1d 100644
--- a/xen/arch/x86/platform_hypercall.c
+++ b/xen/arch/x86/platform_hypercall.c
@@ -66,15 +66,16 @@ ret_t do_platform_op(XEN_GUEST_HANDLE(xen_platform_op_t) u_xenpf_op)
     ret_t ret = 0;
     struct xen_platform_op curop, *op = &curop;
 
-    if ( !IS_PRIV(current->domain) )
-        return -EPERM;
-
     if ( copy_from_guest(op, u_xenpf_op, 1) )
         return -EFAULT;
 
     if ( op->interface_version != XENPF_INTERFACE_VERSION )
         return -EACCES;
 
+    ret = xsm_platform_op(op->cmd);
+    if ( ret )
+        return ret;
+
     /*
      * Trylock here avoids deadlock with an existing platform critical section
      * which might (for some current or future reason) want to synchronise
@@ -507,6 +508,10 @@ ret_t do_platform_op(XEN_GUEST_HANDLE(xen_platform_op_t) u_xenpf_op)
     {
         struct xenpf_pcpu_version *ver = &op->u.pcpu_version;
 
+        ret = xsm_getcpuinfo();
+        if ( ret )
+            break;
+
         if ( !get_cpu_maps() )
         {
             ret = -EBUSY;
diff --git a/xen/include/xsm/dummy.h b/xen/include/xsm/dummy.h
index 448b5c1..c7ee659 100644
--- a/xen/include/xsm/dummy.h
+++ b/xen/include/xsm/dummy.h
@@ -574,6 +574,13 @@ static XSM_DEFAULT(int, platform_quirk) (uint32_t quirk)
     return 0;
 }
 
+static XSM_DEFAULT(int, platform_op) (uint32_t op)
+{
+    if ( !IS_PRIV(current->domain) )
+        return -EPERM;
+    return 0;
+}
+
 static XSM_DEFAULT(int, firmware_info) (void)
 {
     return 0;
diff --git a/xen/include/xsm/xsm.h b/xen/include/xsm/xsm.h
index 1a63c27..028661b 100644
--- a/xen/include/xsm/xsm.h
+++ b/xen/include/xsm/xsm.h
@@ -158,6 +158,7 @@ struct xsm_operations {
     int (*microcode) (void);
     int (*physinfo) (void);
     int (*platform_quirk) (uint32_t);
+    int (*platform_op) (uint32_t cmd);
     int (*firmware_info) (void);
     int (*efi_call) (void);
     int (*acpi_sleep) (void);
@@ -696,6 +697,11 @@ static inline int xsm_platform_quirk (uint32_t quirk)
     return xsm_ops->platform_quirk(quirk);
 }
 
+static inline int xsm_platform_op (uint32_t op)
+{
+    return xsm_ops->platform_op(op);
+}
+
 static inline int xsm_firmware_info (void)
 {
     return xsm_ops->firmware_info();
diff --git a/xen/xsm/dummy.c b/xen/xsm/dummy.c
index 47192d7..10f9c47 100644
--- a/xen/xsm/dummy.c
+++ b/xen/xsm/dummy.c
@@ -142,6 +142,7 @@ void xsm_fixup_ops (struct xsm_operations *ops)
     set_to_dummy_if_null(ops, microcode);
     set_to_dummy_if_null(ops, physinfo);
     set_to_dummy_if_null(ops, platform_quirk);
+    set_to_dummy_if_null(ops, platform_op);
     set_to_dummy_if_null(ops, firmware_info);
     set_to_dummy_if_null(ops, efi_call);
     set_to_dummy_if_null(ops, acpi_sleep);
diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
index 90b0388..2a44a76 100644
--- a/xen/xsm/flask/hooks.c
+++ b/xen/xsm/flask/hooks.c
@@ -1207,6 +1207,38 @@ static int flask_platform_quirk(uint32_t quirk)
                         XEN__QUIRK, NULL);
 }
 
+static int flask_platform_op(uint32_t op)
+{
+    switch ( op )
+    {
+    case XENPF_settime:
+    case XENPF_add_memtype:
+    case XENPF_del_memtype:
+    case XENPF_read_memtype:
+    case XENPF_microcode_update:
+    case XENPF_platform_quirk:
+    case XENPF_firmware_info:
+    case XENPF_efi_runtime_call:
+    case XENPF_enter_acpi_sleep:
+    case XENPF_change_freq:
+    case XENPF_getidletime:
+    case XENPF_set_processor_pminfo:
+    case XENPF_get_cpuinfo:
+    case XENPF_get_cpu_version:
+    case XENPF_cpu_online:
+    case XENPF_cpu_offline:
+    case XENPF_cpu_hotadd:
+    case XENPF_mem_hotadd:
+        /* These operations have their own XSM hooks */
+        return 0;
+    case XENPF_core_parking:
+        return domain_has_xen(current->domain, XEN__PM_OP);
+    default:
+        printk("flask_platform_op: Unknown op %d\n", op);
+        return -EPERM;
+    }
+}
+
 static int flask_firmware_info(void)
 {
     return domain_has_xen(current->domain, XEN__FIRMWARE);
@@ -1577,6 +1609,7 @@ static struct xsm_operations flask_ops = {
     .microcode = flask_microcode,
     .physinfo = flask_physinfo,
     .platform_quirk = flask_platform_quirk,
+    .platform_op = flask_platform_op,
     .firmware_info = flask_firmware_info,
     .efi_call = flask_efi_call,
     .acpi_sleep = flask_acpi_sleep,
-- 
1.7.11.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 17 15:24:24 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 15:24:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDdBB-0003cT-Hw; Mon, 17 Sep 2012 15:24:09 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1TDdBA-0003Zz-4k
	for xen-devel@lists.xen.org; Mon, 17 Sep 2012 15:24:08 +0000
Received: from [85.158.139.211:51795] by server-9.bemta-5.messagelabs.com id
	78/C3-20529-79047505; Mon, 17 Sep 2012 15:24:07 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-12.tower-206.messagelabs.com!1347895446!18848098!1
X-Originating-IP: [63.239.67.9]
X-SpamReason: No, hits=2.5 required=7.0 tests=BODY_RANDOM_LONG,LONGWORDS
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19038 invoked from network); 17 Sep 2012 15:24:06 -0000
Received: from emvm-gh1-uea08.nsa.gov (HELO nsa.gov) (63.239.67.9)
	by server-12.tower-206.messagelabs.com with SMTP;
	17 Sep 2012 15:24:06 -0000
X-TM-IMSS-Message-ID: <53803eae0012acde@nsa.gov>
Received: from tarius.tycho.ncsc.mil ([144.51.3.1]) by nsa.gov ([63.239.67.9])
	with ESMTP (TREND IMSS SMTP Service 7.1) id 53803eae0012acde ;
	Mon, 17 Sep 2012 11:23:46 -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 q8HFO0xg027504; 
	Mon, 17 Sep 2012 11:24:05 -0400
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xen.org
Date: Mon, 17 Sep 2012 11:23:38 -0400
Message-Id: <1347895425-17959-17-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.11.4
In-Reply-To: <1347895425-17959-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1347895425-17959-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: dgdegra@tycho.nsa.gov, keir@xen.org
Subject: [Xen-devel] [PATCH 16/23] xsm/flask: add missing hooks
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 FLASK module was missing implementations of some hooks and did not
have access vectors defined for 10 domctls; define these now.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 tools/flask/policy/policy/flask/access_vectors |  5 ++
 tools/flask/policy/policy/modules/xen/xen.if   |  4 +-
 xen/xsm/flask/hooks.c                          | 66 +++++++++++++++++++++-----
 xen/xsm/flask/include/av_perm_to_string.h      |  5 ++
 xen/xsm/flask/include/av_permissions.h         |  5 ++
 5 files changed, 73 insertions(+), 12 deletions(-)

diff --git a/tools/flask/policy/policy/flask/access_vectors b/tools/flask/policy/policy/flask/access_vectors
index 11d02da..ea65e45 100644
--- a/tools/flask/policy/policy/flask/access_vectors
+++ b/tools/flask/policy/policy/flask/access_vectors
@@ -80,6 +80,9 @@ class domain2
 	relabelself
 	make_priv_for
 	set_as_target
+	set_cpuid
+	gettsc
+	settsc
 }
 
 class hvm
@@ -97,6 +100,8 @@ class hvm
     hvmctl
     mem_event
     mem_sharing
+    audit_p2m
+    send_irq
 }
 
 class event
diff --git a/tools/flask/policy/policy/modules/xen/xen.if b/tools/flask/policy/policy/modules/xen/xen.if
index 2ad11b2..59ba171 100644
--- a/tools/flask/policy/policy/modules/xen/xen.if
+++ b/tools/flask/policy/policy/modules/xen/xen.if
@@ -29,6 +29,7 @@ define(`create_domain_common', `
 			getdomaininfo hypercall setvcpucontext setextvcpucontext
 			scheduler getvcpuinfo getvcpuextstate getaddrsize
 			getvcpuaffinity setvcpuaffinity };
+	allow $1 $2:domain2 { set_cpuid settsc };
 	allow $1 $2:security check_context;
 	allow $1 $2:shadow enable;
 	allow $1 $2:mmu {map_read map_write adjust memorymap physmap pinpage};
@@ -67,6 +68,7 @@ define(`migrate_domain_out', `
 	allow $1 $2:hvm { gethvmc getparam irqlevel };
 	allow $1 $2:mmu { stat pageinfo map_read };
 	allow $1 $2:domain { getaddrsize getvcpucontext getextvcpucontext getvcpuextstate pause destroy };
+	allow $1 $2:domain2 gettsc;
 ')
 
 ################################################################################
@@ -112,7 +114,7 @@ define(`device_model', `
 	domain_comms($1, $2)
 	allow $1 $2:domain { set_target shutdown };
 	allow $1 $2:mmu { map_read map_write adjust physmap };
-	allow $1 $2:hvm { getparam setparam trackdirtyvram hvmctl irqlevel pciroute };
+	allow $1 $2:hvm { getparam setparam trackdirtyvram hvmctl irqlevel pciroute cacheattr send_irq };
 ')
 ################################################################################
 #
diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
index 635f91c..089faf8 100644
--- a/xen/xsm/flask/hooks.c
+++ b/xen/xsm/flask/hooks.c
@@ -650,25 +650,32 @@ static int flask_domctl(struct domain *d, int cmd)
 #endif
         return 0;
 
+    case XEN_DOMCTL_debug_op:
+    case XEN_DOMCTL_gdbsx_guestmemio:
+    case XEN_DOMCTL_gdbsx_pausevcpu:
+    case XEN_DOMCTL_gdbsx_unpausevcpu:
+    case XEN_DOMCTL_gdbsx_domstatus:
+        return domain_has_perm(current->domain, d, SECCLASS_DOMAIN,
+                               DOMAIN__SETDEBUGGING);
+
     case XEN_DOMCTL_subscribe:
     case XEN_DOMCTL_disable_migrate:
+    case XEN_DOMCTL_suppress_spurious_page_faults:
         return domain_has_perm(current->domain, d, SECCLASS_DOMAIN,
                                DOMAIN__SET_MISC_INFO);
 
     case XEN_DOMCTL_set_cpuid:
-    case XEN_DOMCTL_suppress_spurious_page_faults:
-    case XEN_DOMCTL_debug_op:
+        return domain_has_perm(current->domain, d, SECCLASS_DOMAIN2, DOMAIN2__SET_CPUID);
+
     case XEN_DOMCTL_gettscinfo:
+        return domain_has_perm(current->domain, d, SECCLASS_DOMAIN2, DOMAIN2__GETTSC);
+
     case XEN_DOMCTL_settscinfo:
+        return domain_has_perm(current->domain, d, SECCLASS_DOMAIN2, DOMAIN2__SETTSC);
+
     case XEN_DOMCTL_audit_p2m:
-    case XEN_DOMCTL_gdbsx_guestmemio:
-    case XEN_DOMCTL_gdbsx_pausevcpu:
-    case XEN_DOMCTL_gdbsx_unpausevcpu:
-    case XEN_DOMCTL_gdbsx_domstatus:
-        /* TODO add per-subfunction hooks */
-        if ( !IS_PRIV(current->domain) )
-            return -EPERM;
-        return 0;
+        return domain_has_perm(current->domain, d, SECCLASS_HVM, HVM__AUDIT_P2M);
+
     default:
         printk("flask_domctl: Unknown op %d\n", cmd);
         return -EPERM;
@@ -921,6 +928,11 @@ static int flask_iomem_permission(struct domain *d, uint64_t start, uint64_t end
     return security_iterate_iomem_sids(start, end, _iomem_has_perm, &data);
 }
 
+static int flask_iomem_mapping(struct domain *d, uint64_t start, uint64_t end, uint8_t access)
+{
+    return flask_iomem_permission(d, start, end, access);
+}
+
 static int flask_pci_config_permission(struct domain *d, uint32_t machine_bdf, uint16_t start, uint16_t end, uint8_t access)
 {
     u32 rsid;
@@ -1128,7 +1140,6 @@ static int _ioport_has_perm(void *v, u32 sid, unsigned long start, unsigned long
     return avc_has_perm(data->tsec->sid, sid, SECCLASS_RESOURCE, RESOURCE__USE, &ad);
 }
 
-
 static int flask_ioport_permission(struct domain *d, uint32_t start, uint32_t end, uint8_t access)
 {
     int rc;
@@ -1151,6 +1162,11 @@ static int flask_ioport_permission(struct domain *d, uint32_t start, uint32_t en
     return security_iterate_ioport_sids(start, end, _ioport_has_perm, &data);
 }
 
+static int flask_ioport_mapping(struct domain *d, uint32_t start, uint32_t end, uint8_t access)
+{
+    return flask_ioport_permission(d, start, end, access);
+}
+
 static int flask_getpageframeinfo(struct domain *d)
 {
     return domain_has_perm(current->domain, d, SECCLASS_MMU, MMU__PAGEINFO);
@@ -1209,6 +1225,25 @@ static int flask_address_size(struct domain *d, uint32_t cmd)
     return domain_has_perm(current->domain, d, SECCLASS_DOMAIN, perm);
 }
 
+static int flask_machine_address_size(struct domain *d, uint32_t cmd)
+{
+    u32 perm;
+
+    switch ( cmd )
+    {
+    case XEN_DOMCTL_set_machine_address_size:
+        perm = DOMAIN__SETADDRSIZE;
+        break;
+    case XEN_DOMCTL_get_machine_address_size:
+        perm = DOMAIN__GETADDRSIZE;
+        break;
+    default:
+        return -EPERM;
+    }
+
+    return domain_has_perm(current->domain, d, SECCLASS_DOMAIN, perm);
+}
+
 static int flask_hvm_param(struct domain *d, unsigned long op)
 {
     u32 perm;
@@ -1246,6 +1281,11 @@ static int flask_hvm_set_pci_link_route(struct domain *d)
     return domain_has_perm(current->domain, d, SECCLASS_HVM, HVM__PCIROUTE);
 }
 
+static int flask_hvm_inject_msi(struct domain *d)
+{
+    return domain_has_perm(current->domain, d, SECCLASS_HVM, HVM__SEND_IRQ);
+}
+
 static int flask_mem_event(struct domain *d)
 {
     return domain_has_perm(current->domain, d, SECCLASS_HVM, HVM__MEM_EVENT);
@@ -1689,6 +1729,7 @@ static struct xsm_operations flask_ops = {
     .unmap_domain_pirq = flask_unmap_domain_pirq,
     .irq_permission = flask_irq_permission,
     .iomem_permission = flask_iomem_permission,
+    .iomem_mapping = flask_iomem_mapping,
     .pci_config_permission = flask_pci_config_permission,
 
     .resource_plug_core = flask_resource_plug_core,
@@ -1713,10 +1754,12 @@ static struct xsm_operations flask_ops = {
     .hypercall_init = flask_hypercall_init,
     .hvmcontext = flask_hvmcontext,
     .address_size = flask_address_size,
+    .machine_address_size = flask_machine_address_size,
     .hvm_param = flask_hvm_param,
     .hvm_set_pci_intx_level = flask_hvm_set_pci_intx_level,
     .hvm_set_isa_irq_level = flask_hvm_set_isa_irq_level,
     .hvm_set_pci_link_route = flask_hvm_set_pci_link_route,
+    .hvm_inject_msi = flask_hvm_inject_msi,
     .mem_event = flask_mem_event,
     .mem_sharing = flask_mem_sharing,
     .apic = flask_apic,
@@ -1749,6 +1792,7 @@ static struct xsm_operations flask_ops = {
     .ext_vcpucontext = flask_ext_vcpucontext,
     .vcpuextstate = flask_vcpuextstate,
     .ioport_permission = flask_ioport_permission,
+    .ioport_mapping = flask_ioport_mapping,
 #endif
 };
 
diff --git a/xen/xsm/flask/include/av_perm_to_string.h b/xen/xsm/flask/include/av_perm_to_string.h
index 10f8e80..894910c 100644
--- a/xen/xsm/flask/include/av_perm_to_string.h
+++ b/xen/xsm/flask/include/av_perm_to_string.h
@@ -66,6 +66,9 @@
    S_(SECCLASS_DOMAIN2, DOMAIN2__RELABELSELF, "relabelself")
    S_(SECCLASS_DOMAIN2, DOMAIN2__MAKE_PRIV_FOR, "make_priv_for")
    S_(SECCLASS_DOMAIN2, DOMAIN2__SET_AS_TARGET, "set_as_target")
+   S_(SECCLASS_DOMAIN2, DOMAIN2__SET_CPUID, "set_cpuid")
+   S_(SECCLASS_DOMAIN2, DOMAIN2__GETTSC, "gettsc")
+   S_(SECCLASS_DOMAIN2, DOMAIN2__SETTSC, "settsc")
    S_(SECCLASS_HVM, HVM__SETHVMC, "sethvmc")
    S_(SECCLASS_HVM, HVM__GETHVMC, "gethvmc")
    S_(SECCLASS_HVM, HVM__SETPARAM, "setparam")
@@ -79,6 +82,8 @@
    S_(SECCLASS_HVM, HVM__HVMCTL, "hvmctl")
    S_(SECCLASS_HVM, HVM__MEM_EVENT, "mem_event")
    S_(SECCLASS_HVM, HVM__MEM_SHARING, "mem_sharing")
+   S_(SECCLASS_HVM, HVM__AUDIT_P2M, "audit_p2m")
+   S_(SECCLASS_HVM, HVM__SEND_IRQ, "send_irq")
    S_(SECCLASS_EVENT, EVENT__BIND, "bind")
    S_(SECCLASS_EVENT, EVENT__SEND, "send")
    S_(SECCLASS_EVENT, EVENT__STATUS, "status")
diff --git a/xen/xsm/flask/include/av_permissions.h b/xen/xsm/flask/include/av_permissions.h
index f7cfee1..1bdb515 100644
--- a/xen/xsm/flask/include/av_permissions.h
+++ b/xen/xsm/flask/include/av_permissions.h
@@ -68,6 +68,9 @@
 #define DOMAIN2__RELABELSELF                      0x00000004UL
 #define DOMAIN2__MAKE_PRIV_FOR                    0x00000008UL
 #define DOMAIN2__SET_AS_TARGET                    0x00000010UL
+#define DOMAIN2__SET_CPUID                        0x00000020UL
+#define DOMAIN2__GETTSC                           0x00000040UL
+#define DOMAIN2__SETTSC                           0x00000080UL
 
 #define HVM__SETHVMC                              0x00000001UL
 #define HVM__GETHVMC                              0x00000002UL
@@ -82,6 +85,8 @@
 #define HVM__HVMCTL                               0x00000400UL
 #define HVM__MEM_EVENT                            0x00000800UL
 #define HVM__MEM_SHARING                          0x00001000UL
+#define HVM__AUDIT_P2M                            0x00002000UL
+#define HVM__SEND_IRQ                             0x00004000UL
 
 #define EVENT__BIND                               0x00000001UL
 #define EVENT__SEND                               0x00000002UL
-- 
1.7.11.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 17 15:24:24 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 15:24:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDdBD-0003e1-Cy; Mon, 17 Sep 2012 15:24:11 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1TDdBA-0003as-TS
	for xen-devel@lists.xen.org; Mon, 17 Sep 2012 15:24:09 +0000
Received: from [85.158.139.211:11473] by server-10.bemta-5.messagelabs.com id
	A7/7C-10969-79047505; Mon, 17 Sep 2012 15:24:07 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-12.tower-206.messagelabs.com!1347895446!18848097!1
X-Originating-IP: [63.239.67.9]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19032 invoked from network); 17 Sep 2012 15:24:06 -0000
Received: from emvm-gh1-uea08.nsa.gov (HELO nsa.gov) (63.239.67.9)
	by server-12.tower-206.messagelabs.com with SMTP;
	17 Sep 2012 15:24:06 -0000
X-TM-IMSS-Message-ID: <53803de40012acdd@nsa.gov>
Received: from tarius.tycho.ncsc.mil ([144.51.3.1]) by nsa.gov ([63.239.67.9])
	with ESMTP (TREND IMSS SMTP Service 7.1) id 53803de40012acdd ;
	Mon, 17 Sep 2012 11:23:46 -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 q8HFO0xf027504; 
	Mon, 17 Sep 2012 11:24:04 -0400
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xen.org
Date: Mon, 17 Sep 2012 11:23:37 -0400
Message-Id: <1347895425-17959-16-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.11.4
In-Reply-To: <1347895425-17959-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1347895425-17959-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: dgdegra@tycho.nsa.gov, keir@xen.org
Subject: [Xen-devel] [PATCH 15/23] xen: convert do_sysctl to use 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

The xsm_sysctl hook now covers every sysctl, in addition to the more
fine-grained XSM hooks in most sub-functions.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 xen/common/sysctl.c     |  7 ++++---
 xen/include/xsm/dummy.h |  7 +++++++
 xen/include/xsm/xsm.h   |  6 ++++++
 xen/xsm/dummy.c         |  1 +
 xen/xsm/flask/hooks.c   | 33 +++++++++++++++++++++++++++++++++
 5 files changed, 51 insertions(+), 3 deletions(-)

diff --git a/xen/common/sysctl.c b/xen/common/sysctl.c
index ea68278..e009baa 100644
--- a/xen/common/sysctl.c
+++ b/xen/common/sysctl.c
@@ -33,15 +33,16 @@ long do_sysctl(XEN_GUEST_HANDLE(xen_sysctl_t) u_sysctl)
     struct xen_sysctl curop, *op = &curop;
     static DEFINE_SPINLOCK(sysctl_lock);
 
-    if ( !IS_PRIV(current->domain) )
-        return -EPERM;
-
     if ( copy_from_guest(op, u_sysctl, 1) )
         return -EFAULT;
 
     if ( op->interface_version != XEN_SYSCTL_INTERFACE_VERSION )
         return -EACCES;
 
+    ret = xsm_sysctl(op->cmd);
+    if ( ret )
+        return ret;
+
     /*
      * Trylock here avoids deadlock with an existing sysctl critical section
      * which might (for some current or future reason) want to synchronise
diff --git a/xen/include/xsm/dummy.h b/xen/include/xsm/dummy.h
index 9d70587..626a332 100644
--- a/xen/include/xsm/dummy.h
+++ b/xen/include/xsm/dummy.h
@@ -106,6 +106,13 @@ static XSM_DEFAULT(int, domctl)(struct domain *d, int cmd)
     return 0;
 }
 
+static XSM_DEFAULT(int, sysctl)(int cmd)
+{
+    if ( !IS_PRIV(current->domain) )
+        return -EPERM;
+    return 0;
+}
+
 static XSM_DEFAULT(int, set_virq_handler)(struct domain *d, uint32_t virq)
 {
     return 0;
diff --git a/xen/include/xsm/xsm.h b/xen/include/xsm/xsm.h
index 028661b..96e4b13 100644
--- a/xen/include/xsm/xsm.h
+++ b/xen/include/xsm/xsm.h
@@ -58,6 +58,7 @@ struct xsm_operations {
     int (*domain_settime) (struct domain *d);
     int (*set_target) (struct domain *d, struct domain *e);
     int (*domctl) (struct domain *d, int cmd);
+    int (*sysctl) (int cmd);
     int (*set_virq_handler) (struct domain *d, uint32_t virq);
     int (*tbufcontrol) (void);
     int (*readconsole) (uint32_t clear);
@@ -265,6 +266,11 @@ static inline int xsm_domctl (struct domain *d, int cmd)
     return xsm_ops->domctl(d, cmd);
 }
 
+static inline int xsm_sysctl (int cmd)
+{
+    return xsm_ops->sysctl(cmd);
+}
+
 static inline int xsm_set_virq_handler (struct domain *d, uint32_t virq)
 {
     return xsm_ops->set_virq_handler(d, virq);
diff --git a/xen/xsm/dummy.c b/xen/xsm/dummy.c
index 10f9c47..43e8617 100644
--- a/xen/xsm/dummy.c
+++ b/xen/xsm/dummy.c
@@ -44,6 +44,7 @@ void xsm_fixup_ops (struct xsm_operations *ops)
     set_to_dummy_if_null(ops, domain_settime);
     set_to_dummy_if_null(ops, set_target);
     set_to_dummy_if_null(ops, domctl);
+    set_to_dummy_if_null(ops, sysctl);
     set_to_dummy_if_null(ops, set_virq_handler);
     set_to_dummy_if_null(ops, tbufcontrol);
     set_to_dummy_if_null(ops, readconsole);
diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
index 7caab52..635f91c 100644
--- a/xen/xsm/flask/hooks.c
+++ b/xen/xsm/flask/hooks.c
@@ -675,6 +675,38 @@ static int flask_domctl(struct domain *d, int cmd)
     }
 }
 
+static int flask_sysctl(int cmd)
+{
+    switch ( cmd )
+    {
+    /* These have individual XSM hooks */
+    case XEN_SYSCTL_readconsole:
+    case XEN_SYSCTL_tbuf_op:
+    case XEN_SYSCTL_sched_id:
+    case XEN_SYSCTL_perfc_op:
+    case XEN_SYSCTL_getdomaininfolist:
+    case XEN_SYSCTL_debug_keys:
+    case XEN_SYSCTL_getcpuinfo:
+    case XEN_SYSCTL_availheap:
+    case XEN_SYSCTL_get_pmstat:
+    case XEN_SYSCTL_pm_op:
+    case XEN_SYSCTL_page_offline_op:
+    case XEN_SYSCTL_lockprof_op:
+    case XEN_SYSCTL_cpupool_op:
+    case XEN_SYSCTL_scheduler_op:
+#ifdef CONFIG_X86
+    case XEN_SYSCTL_physinfo:
+    case XEN_SYSCTL_cpu_hotplug:
+    case XEN_SYSCTL_topologyinfo:
+    case XEN_SYSCTL_numainfo:
+#endif
+        return 0;
+    default:
+        printk("flask_sysctl: Unknown op %d\n", cmd);
+        return -EPERM;
+    }
+}
+
 static int flask_set_virq_handler(struct domain *d, uint32_t virq)
 {
     return domain_has_perm(current->domain, d, SECCLASS_DOMAIN, DOMAIN__SET_VIRQ_HANDLER);
@@ -1601,6 +1633,7 @@ static struct xsm_operations flask_ops = {
     .domain_settime = flask_domain_settime,
     .set_target = flask_set_target,
     .domctl = flask_domctl,
+    .sysctl = flask_sysctl,
     .set_virq_handler = flask_set_virq_handler,
     .tbufcontrol = flask_tbufcontrol,
     .readconsole = flask_readconsole,
-- 
1.7.11.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 17 15:24:24 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 15:24:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDdBF-0003gR-Dw; Mon, 17 Sep 2012 15:24:13 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1TDdBB-0003as-N2
	for xen-devel@lists.xen.org; Mon, 17 Sep 2012 15:24:10 +0000
Received: from [85.158.139.211:53639] by server-10.bemta-5.messagelabs.com id
	80/9C-10969-99047505; Mon, 17 Sep 2012 15:24:09 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-3.tower-206.messagelabs.com!1347895447!18886541!1
X-Originating-IP: [63.239.67.9]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21536 invoked from network); 17 Sep 2012 15:24:07 -0000
Received: from emvm-gh1-uea08.nsa.gov (HELO nsa.gov) (63.239.67.9)
	by server-3.tower-206.messagelabs.com with SMTP;
	17 Sep 2012 15:24:07 -0000
X-TM-IMSS-Message-ID: <538040920012ace3@nsa.gov>
Received: from tarius.tycho.ncsc.mil ([144.51.3.1]) by nsa.gov ([63.239.67.9])
	with ESMTP (TREND IMSS SMTP Service 7.1) id 538040920012ace3 ;
	Mon, 17 Sep 2012 11:23:47 -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 q8HFO0xi027504; 
	Mon, 17 Sep 2012 11:24:05 -0400
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xen.org
Date: Mon, 17 Sep 2012 11:23:40 -0400
Message-Id: <1347895425-17959-19-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.11.4
In-Reply-To: <1347895425-17959-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1347895425-17959-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Tim Deegan <tim@xen.org>, dgdegra@tycho.nsa.gov, keir@xen.org,
	Jan Beulich <jbeulich@suse.com>
Subject: [Xen-devel] [PATCH 18/23] arch/x86: Add missing mem_sharing XSM
	hooks
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This patch adds splits up the mem_sharing and mem_event XSM hooks to
better cover what the code is doing. It also changes the utility
function get_mem_event_op_target to rcu_lock_live_remote_domain_by_id
because there is no mm-specific logic in there.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Cc: Keir Fraser <keir@xen.org>
Cc: Jan Beulich <jbeulich@suse.com>
Cc: Tim Deegan <tim@xen.org>
---
 tools/flask/policy/policy/flask/access_vectors |  1 +
 xen/arch/x86/domctl.c                          |  8 ++---
 xen/arch/x86/mm/mem_event.c                    | 41 ++++++++------------------
 xen/arch/x86/mm/mem_sharing.c                  | 25 +++++++++++++---
 xen/common/domain.c                            | 15 ++++++++++
 xen/include/asm-x86/mem_event.h                |  1 -
 xen/include/xen/sched.h                        |  6 ++++
 xen/include/xsm/dummy.h                        | 23 ++++++++++++++-
 xen/include/xsm/xsm.h                          | 24 +++++++++++++--
 xen/xsm/dummy.c                                |  5 +++-
 xen/xsm/flask/hooks.c                          | 25 ++++++++++++++--
 xen/xsm/flask/include/av_perm_to_string.h      |  1 +
 xen/xsm/flask/include/av_permissions.h         |  1 +
 13 files changed, 130 insertions(+), 46 deletions(-)

diff --git a/tools/flask/policy/policy/flask/access_vectors b/tools/flask/policy/policy/flask/access_vectors
index ea65e45..45ac437 100644
--- a/tools/flask/policy/policy/flask/access_vectors
+++ b/tools/flask/policy/policy/flask/access_vectors
@@ -102,6 +102,7 @@ class hvm
     mem_sharing
     audit_p2m
     send_irq
+    share_mem
 }
 
 class event
diff --git a/xen/arch/x86/domctl.c b/xen/arch/x86/domctl.c
index 24e2d93..7062f02 100644
--- a/xen/arch/x86/domctl.c
+++ b/xen/arch/x86/domctl.c
@@ -1447,10 +1447,8 @@ long arch_do_domctl(
         d = rcu_lock_domain_by_id(domctl->domain);
         if ( d != NULL )
         {
-            ret = xsm_mem_event(d);
-            if ( !ret )
-                ret = mem_event_domctl(d, &domctl->u.mem_event_op,
-                                       guest_handle_cast(u_domctl, void));
+            ret = mem_event_domctl(d, &domctl->u.mem_event_op,
+                                   guest_handle_cast(u_domctl, void));
             rcu_unlock_domain(d);
             copy_to_guest(u_domctl, domctl, 1);
         } 
@@ -1506,7 +1504,7 @@ long arch_do_domctl(
         d = rcu_lock_domain_by_id(domctl->domain);
         if ( d != NULL )
         {
-            ret = xsm_mem_event(d);
+            ret = xsm_mem_event_setup(d);
             if ( !ret ) {
                 p2m = p2m_get_hostp2m(d);
                 p2m->access_required = domctl->u.access_required.access_required;
diff --git a/xen/arch/x86/mm/mem_event.c b/xen/arch/x86/mm/mem_event.c
index d728889..950209b 100644
--- a/xen/arch/x86/mm/mem_event.c
+++ b/xen/arch/x86/mm/mem_event.c
@@ -29,6 +29,7 @@
 #include <asm/mem_paging.h>
 #include <asm/mem_access.h>
 #include <asm/mem_sharing.h>
+#include <xsm/xsm.h>
 
 /* for public/io/ring.h macros */
 #define xen_mb()   mb()
@@ -439,35 +440,19 @@ static void mem_sharing_notification(struct vcpu *v, unsigned int port)
         mem_sharing_sharing_resume(v->domain);
 }
 
-struct domain *get_mem_event_op_target(uint32_t domain, int *rc)
-{
-    struct domain *d;
-
-    /* Get the target domain */
-    *rc = rcu_lock_remote_target_domain_by_id(domain, &d);
-    if ( *rc != 0 )
-        return NULL;
-
-    /* Not dying? */
-    if ( d->is_dying )
-    {
-        rcu_unlock_domain(d);
-        *rc = -EINVAL;
-        return NULL;
-    }
-    
-    return d;
-}
-
 int do_mem_event_op(int op, uint32_t domain, void *arg)
 {
     int ret;
     struct domain *d;
 
-    d = get_mem_event_op_target(domain, &ret);
-    if ( !d )
+    ret = rcu_lock_live_remote_domain_by_id(domain, &d);
+    if ( ret )
         return ret;
 
+    ret = xsm_mem_event_op(d, op);
+    if ( ret )
+        goto out;
+
     switch (op)
     {
         case XENMEM_paging_op:
@@ -483,6 +468,7 @@ int do_mem_event_op(int op, uint32_t domain, void *arg)
             ret = -ENOSYS;
     }
 
+ out:
     rcu_unlock_domain(d);
     return ret;
 }
@@ -516,6 +502,10 @@ int mem_event_domctl(struct domain *d, xen_domctl_mem_event_op_t *mec,
 {
     int rc;
 
+    rc = xsm_mem_event_control(d, mec->mode, mec->op);
+    if ( rc )
+        return rc;
+
     if ( unlikely(d == current->domain) )
     {
         gdprintk(XENLOG_INFO, "Tried to do a memory event op on itself.\n");
@@ -537,13 +527,6 @@ int mem_event_domctl(struct domain *d, xen_domctl_mem_event_op_t *mec,
         return -EINVAL;
     }
 
-    /* TODO: XSM hook */
-#if 0
-    rc = xsm_mem_event_control(d, mec->op);
-    if ( rc )
-        return rc;
-#endif
-
     rc = -ENOSYS;
 
     switch ( mec->mode )
diff --git a/xen/arch/x86/mm/mem_sharing.c b/xen/arch/x86/mm/mem_sharing.c
index 5103285..9229b83 100644
--- a/xen/arch/x86/mm/mem_sharing.c
+++ b/xen/arch/x86/mm/mem_sharing.c
@@ -34,6 +34,7 @@
 #include <asm/atomic.h>
 #include <xen/rcupdate.h>
 #include <asm/event.h>
+#include <xsm/xsm.h>
 
 #include "mm-locks.h"
 
@@ -1345,10 +1346,18 @@ int mem_sharing_memop(struct domain *d, xen_mem_sharing_op_t *mec)
             if ( !mem_sharing_enabled(d) )
                 return -EINVAL;
 
-            cd = get_mem_event_op_target(mec->u.share.client_domain, &rc);
-            if ( !cd )
+            rc = rcu_lock_live_remote_domain_by_id(mec->u.share.client_domain,
+                                                   &cd);
+            if ( rc )
                 return rc;
 
+            rc = xsm_mem_sharing_op(d, cd, mec->op);
+            if ( rc )
+            {
+                rcu_unlock_domain(cd);
+                return rc;
+            }
+
             if ( !mem_sharing_enabled(cd) )
             {
                 rcu_unlock_domain(cd);
@@ -1401,10 +1410,18 @@ int mem_sharing_memop(struct domain *d, xen_mem_sharing_op_t *mec)
             if ( !mem_sharing_enabled(d) )
                 return -EINVAL;
 
-            cd = get_mem_event_op_target(mec->u.share.client_domain, &rc);
-            if ( !cd )
+            rc = rcu_lock_live_remote_domain_by_id(mec->u.share.client_domain,
+                                                   &cd);
+            if ( rc )
                 return rc;
 
+            rc = xsm_mem_sharing_op(d, cd, mec->op);
+            if ( rc )
+            {
+                rcu_unlock_domain(cd);
+                return rc;
+            }
+
             if ( !mem_sharing_enabled(cd) )
             {
                 rcu_unlock_domain(cd);
diff --git a/xen/common/domain.c b/xen/common/domain.c
index 52489b3..a205557 100644
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -475,6 +475,21 @@ int rcu_lock_remote_domain_by_id(domid_t dom, struct domain **d)
     return 0;
 }
 
+int rcu_lock_live_remote_domain_by_id(domid_t dom, struct domain **d)
+{
+    int rv;
+    rv = rcu_lock_remote_domain_by_id(dom, d);
+    if ( rv )
+        return rv;
+    if ( (*d)->is_dying )
+    {
+        rcu_unlock_domain(*d);
+        return -EINVAL;
+    }
+
+    return 0;
+}
+
 int domain_kill(struct domain *d)
 {
     int rc = 0;
diff --git a/xen/include/asm-x86/mem_event.h b/xen/include/asm-x86/mem_event.h
index 23d71c1..448be4f 100644
--- a/xen/include/asm-x86/mem_event.h
+++ b/xen/include/asm-x86/mem_event.h
@@ -62,7 +62,6 @@ void mem_event_put_request(struct domain *d, struct mem_event_domain *med,
 int mem_event_get_response(struct domain *d, struct mem_event_domain *med,
                            mem_event_response_t *rsp);
 
-struct domain *get_mem_event_op_target(uint32_t domain, int *rc);
 int do_mem_event_op(int op, uint32_t domain, void *arg);
 int mem_event_domctl(struct domain *d, xen_domctl_mem_event_op_t *mec,
                      XEN_GUEST_HANDLE(void) u_domctl);
diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
index b0def4a..b29ed13 100644
--- a/xen/include/xen/sched.h
+++ b/xen/include/xen/sched.h
@@ -471,6 +471,12 @@ int rcu_lock_remote_target_domain_by_id(domid_t dom, struct domain **d);
  */
 int rcu_lock_remote_domain_by_id(domid_t dom, struct domain **d);
 
+/*
+ * As rcu_lock_remote_domain_by_id() but will fail EINVAL if the domain is
+ * dying.
+ */
+int rcu_lock_live_remote_domain_by_id(domid_t dom, struct domain **d);
+
 /* Finish a RCU critical region started by rcu_lock_domain_by_id(). */
 static inline void rcu_unlock_domain(struct domain *d)
 {
diff --git a/xen/include/xsm/dummy.h b/xen/include/xsm/dummy.h
index 626a332..5fb0afe 100644
--- a/xen/include/xsm/dummy.h
+++ b/xen/include/xsm/dummy.h
@@ -551,16 +551,37 @@ static XSM_DEFAULT(int, hvm_inject_msi) (struct domain *d)
     return 0;
 }
 
-static XSM_DEFAULT(int, mem_event) (struct domain *d)
+static XSM_DEFAULT(int, mem_event_setup) (struct domain *d)
 {
     return 0;
 }
 
+static XSM_DEFAULT(int, mem_event_control) (struct domain *d, int mode, int op)
+{
+    if ( !IS_PRIV(current->domain) )
+        return -EPERM;
+    return 0;
+}
+
+static XSM_DEFAULT(int, mem_event_op) (struct domain *d, int op)
+{
+    if ( !IS_PRIV_FOR(current->domain, d) )
+        return -EPERM;
+    return 0;
+}
+
 static XSM_DEFAULT(int, mem_sharing) (struct domain *d)
 {
     return 0;
 }
 
+static XSM_DEFAULT(int, mem_sharing_op) (struct domain *d, struct domain *cd, int op)
+{
+    if ( !IS_PRIV_FOR(current->domain, cd) )
+        return -EPERM;
+    return 0;
+}
+
 static XSM_DEFAULT(int, apic) (struct domain *d, int cmd)
 {
     if ( !IS_PRIV(d) )
diff --git a/xen/include/xsm/xsm.h b/xen/include/xsm/xsm.h
index 96e4b13..c08a664 100644
--- a/xen/include/xsm/xsm.h
+++ b/xen/include/xsm/xsm.h
@@ -151,8 +151,11 @@ struct xsm_operations {
     int (*hvm_set_isa_irq_level) (struct domain *d);
     int (*hvm_set_pci_link_route) (struct domain *d);
     int (*hvm_inject_msi) (struct domain *d);
-    int (*mem_event) (struct domain *d);
+    int (*mem_event_setup) (struct domain *d);
+    int (*mem_event_control) (struct domain *d, int mode, int op);
+    int (*mem_event_op) (struct domain *d, int op);
     int (*mem_sharing) (struct domain *d);
+    int (*mem_sharing_op) (struct domain *d, struct domain *cd, int op);
     int (*apic) (struct domain *d, int cmd);
     int (*xen_settime) (void);
     int (*memtype) (uint32_t access);
@@ -663,9 +666,19 @@ static inline int xsm_hvm_inject_msi (struct domain *d)
     return xsm_ops->hvm_inject_msi(d);
 }
 
-static inline int xsm_mem_event (struct domain *d)
+static inline int xsm_mem_event_setup (struct domain *d)
 {
-    return xsm_ops->mem_event(d);
+    return xsm_ops->mem_event_setup(d);
+}
+
+static inline int xsm_mem_event_control (struct domain *d, int mode, int op)
+{
+    return xsm_ops->mem_event_control(d, mode, op);
+}
+
+static inline int xsm_mem_event_op (struct domain *d, int op)
+{
+    return xsm_ops->mem_event_op(d, op);
 }
 
 static inline int xsm_mem_sharing (struct domain *d)
@@ -673,6 +686,11 @@ static inline int xsm_mem_sharing (struct domain *d)
     return xsm_ops->mem_sharing(d);
 }
 
+static inline int xsm_mem_sharing_op (struct domain *d, struct domain *cd, int op)
+{
+    return xsm_ops->mem_sharing_op(d, cd, op);
+}
+
 static inline int xsm_apic (struct domain *d, int cmd)
 {
     return xsm_ops->apic(d, cmd);
diff --git a/xen/xsm/dummy.c b/xen/xsm/dummy.c
index 43e8617..3926b2b 100644
--- a/xen/xsm/dummy.c
+++ b/xen/xsm/dummy.c
@@ -135,8 +135,11 @@ void xsm_fixup_ops (struct xsm_operations *ops)
     set_to_dummy_if_null(ops, hvm_set_isa_irq_level);
     set_to_dummy_if_null(ops, hvm_set_pci_link_route);
     set_to_dummy_if_null(ops, hvm_inject_msi);
-    set_to_dummy_if_null(ops, mem_event);
+    set_to_dummy_if_null(ops, mem_event_setup);
+    set_to_dummy_if_null(ops, mem_event_control);
+    set_to_dummy_if_null(ops, mem_event_op);
     set_to_dummy_if_null(ops, mem_sharing);
+    set_to_dummy_if_null(ops, mem_sharing_op);
     set_to_dummy_if_null(ops, apic);
     set_to_dummy_if_null(ops, xen_settime);
     set_to_dummy_if_null(ops, memtype);
diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
index a242d65..65db2b7 100644
--- a/xen/xsm/flask/hooks.c
+++ b/xen/xsm/flask/hooks.c
@@ -1277,7 +1277,17 @@ static int flask_hvm_inject_msi(struct domain *d)
     return current_has_perm(d, SECCLASS_HVM, HVM__SEND_IRQ);
 }
 
-static int flask_mem_event(struct domain *d)
+static int flask_mem_event_setup(struct domain *d)
+{
+    return current_has_perm(d, SECCLASS_HVM, HVM__MEM_EVENT);
+}
+
+static int flask_mem_event_control(struct domain *d, int mode, int op)
+{
+    return current_has_perm(d, SECCLASS_HVM, HVM__MEM_EVENT);
+}
+
+static int flask_mem_event_op(struct domain *d, int op)
 {
     return current_has_perm(d, SECCLASS_HVM, HVM__MEM_EVENT);
 }
@@ -1287,6 +1297,14 @@ static int flask_mem_sharing(struct domain *d)
     return current_has_perm(d, SECCLASS_HVM, HVM__MEM_SHARING);
 }
 
+static int flask_mem_sharing_op(struct domain *d, struct domain *cd, int op)
+{
+    int rc = current_has_perm(cd, SECCLASS_HVM, HVM__MEM_SHARING);
+    if ( rc )
+        return rc;
+    return domain_has_perm(d, cd, SECCLASS_HVM, HVM__SHARE_MEM);
+}
+
 static int flask_apic(struct domain *d, int cmd)
 {
     u32 perm;
@@ -1736,8 +1754,11 @@ static struct xsm_operations flask_ops = {
     .hvm_set_isa_irq_level = flask_hvm_set_isa_irq_level,
     .hvm_set_pci_link_route = flask_hvm_set_pci_link_route,
     .hvm_inject_msi = flask_hvm_inject_msi,
-    .mem_event = flask_mem_event,
+    .mem_event_setup = flask_mem_event_setup,
+    .mem_event_control = flask_mem_event_control,
+    .mem_event_op = flask_mem_event_op,
     .mem_sharing = flask_mem_sharing,
+    .mem_sharing_op = flask_mem_sharing_op,
     .apic = flask_apic,
     .xen_settime = flask_xen_settime,
     .memtype = flask_memtype,
diff --git a/xen/xsm/flask/include/av_perm_to_string.h b/xen/xsm/flask/include/av_perm_to_string.h
index 894910c..186f1fa 100644
--- a/xen/xsm/flask/include/av_perm_to_string.h
+++ b/xen/xsm/flask/include/av_perm_to_string.h
@@ -84,6 +84,7 @@
    S_(SECCLASS_HVM, HVM__MEM_SHARING, "mem_sharing")
    S_(SECCLASS_HVM, HVM__AUDIT_P2M, "audit_p2m")
    S_(SECCLASS_HVM, HVM__SEND_IRQ, "send_irq")
+   S_(SECCLASS_HVM, HVM__SHARE_MEM, "share_mem")
    S_(SECCLASS_EVENT, EVENT__BIND, "bind")
    S_(SECCLASS_EVENT, EVENT__SEND, "send")
    S_(SECCLASS_EVENT, EVENT__STATUS, "status")
diff --git a/xen/xsm/flask/include/av_permissions.h b/xen/xsm/flask/include/av_permissions.h
index 1bdb515..b3831f6 100644
--- a/xen/xsm/flask/include/av_permissions.h
+++ b/xen/xsm/flask/include/av_permissions.h
@@ -87,6 +87,7 @@
 #define HVM__MEM_SHARING                          0x00001000UL
 #define HVM__AUDIT_P2M                            0x00002000UL
 #define HVM__SEND_IRQ                             0x00004000UL
+#define HVM__SHARE_MEM                            0x00008000UL
 
 #define EVENT__BIND                               0x00000001UL
 #define EVENT__SEND                               0x00000002UL
-- 
1.7.11.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 17 15:24:24 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 15:24:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDdBE-0003em-47; Mon, 17 Sep 2012 15:24:12 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1TDdBB-0003as-AD
	for xen-devel@lists.xen.org; Mon, 17 Sep 2012 15:24:09 +0000
Received: from [85.158.139.211:11569] by server-10.bemta-5.messagelabs.com id
	E3/8C-10969-89047505; Mon, 17 Sep 2012 15:24:08 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-2.tower-206.messagelabs.com!1347895447!18880334!1
X-Originating-IP: [63.239.67.9]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29739 invoked from network); 17 Sep 2012 15:24:07 -0000
Received: from emvm-gh1-uea08.nsa.gov (HELO nsa.gov) (63.239.67.9)
	by server-2.tower-206.messagelabs.com with SMTP;
	17 Sep 2012 15:24:07 -0000
X-TM-IMSS-Message-ID: <5380417c0012ace4@nsa.gov>
Received: from tarius.tycho.ncsc.mil ([144.51.3.1]) by nsa.gov ([63.239.67.9])
	with ESMTP (TREND IMSS SMTP Service 7.1) id 5380417c0012ace4 ;
	Mon, 17 Sep 2012 11:23:47 -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 q8HFO0xj027504; 
	Mon, 17 Sep 2012 11:24:05 -0400
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xen.org
Date: Mon, 17 Sep 2012 11:23:41 -0400
Message-Id: <1347895425-17959-20-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.11.4
In-Reply-To: <1347895425-17959-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1347895425-17959-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Tim Deegan <tim@xen.org>, dgdegra@tycho.nsa.gov, keir@xen.org,
	Jan Beulich <jbeulich@suse.com>
Subject: [Xen-devel] [PATCH 19/23] arch/x86: check remote MMIO remap
	permissions
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 domain is mapping pages from a different pg_owner domain, the
iomem_access checks are currently only applied to the pg_owner domain,
potentially allowing the current domain to bypass its more restrictive
iomem_access policy using another domain that it has access to.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Cc: Keir Fraser <keir@xen.org>
Cc: Jan Beulich <jbeulich@suse.com>
Cc: Tim Deegan <tim@xen.org>
---
 xen/arch/x86/mm.c | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
index 5c6ea2d..c0c2bf3 100644
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -754,6 +754,18 @@ get_page_from_l1e(
             return -EINVAL;
         }
 
+        if ( pg_owner != curr->domain &&
+             !iomem_access_permitted(curr->domain, mfn, mfn) )
+        {
+            if ( mfn != (PADDR_MASK >> PAGE_SHIFT) ) /* INVALID_MFN? */
+            {
+                MEM_LOG("Domain %u attempted to map I/O space %08lx in domain %u",
+                        curr->domain->domain_id, mfn, pg_owner->domain_id);
+                return -EPERM;
+            }
+            return -EINVAL;
+        }
+
         if ( !(l1f & _PAGE_RW) ||
              !rangeset_contains_singleton(mmio_ro_ranges, mfn) )
             return 0;
-- 
1.7.11.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 17 15:24:24 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 15:24:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDdBB-0003cT-Hw; Mon, 17 Sep 2012 15:24:09 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1TDdBA-0003Zz-4k
	for xen-devel@lists.xen.org; Mon, 17 Sep 2012 15:24:08 +0000
Received: from [85.158.139.211:51795] by server-9.bemta-5.messagelabs.com id
	78/C3-20529-79047505; Mon, 17 Sep 2012 15:24:07 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-12.tower-206.messagelabs.com!1347895446!18848098!1
X-Originating-IP: [63.239.67.9]
X-SpamReason: No, hits=2.5 required=7.0 tests=BODY_RANDOM_LONG,LONGWORDS
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19038 invoked from network); 17 Sep 2012 15:24:06 -0000
Received: from emvm-gh1-uea08.nsa.gov (HELO nsa.gov) (63.239.67.9)
	by server-12.tower-206.messagelabs.com with SMTP;
	17 Sep 2012 15:24:06 -0000
X-TM-IMSS-Message-ID: <53803eae0012acde@nsa.gov>
Received: from tarius.tycho.ncsc.mil ([144.51.3.1]) by nsa.gov ([63.239.67.9])
	with ESMTP (TREND IMSS SMTP Service 7.1) id 53803eae0012acde ;
	Mon, 17 Sep 2012 11:23:46 -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 q8HFO0xg027504; 
	Mon, 17 Sep 2012 11:24:05 -0400
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xen.org
Date: Mon, 17 Sep 2012 11:23:38 -0400
Message-Id: <1347895425-17959-17-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.11.4
In-Reply-To: <1347895425-17959-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1347895425-17959-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: dgdegra@tycho.nsa.gov, keir@xen.org
Subject: [Xen-devel] [PATCH 16/23] xsm/flask: add missing hooks
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 FLASK module was missing implementations of some hooks and did not
have access vectors defined for 10 domctls; define these now.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 tools/flask/policy/policy/flask/access_vectors |  5 ++
 tools/flask/policy/policy/modules/xen/xen.if   |  4 +-
 xen/xsm/flask/hooks.c                          | 66 +++++++++++++++++++++-----
 xen/xsm/flask/include/av_perm_to_string.h      |  5 ++
 xen/xsm/flask/include/av_permissions.h         |  5 ++
 5 files changed, 73 insertions(+), 12 deletions(-)

diff --git a/tools/flask/policy/policy/flask/access_vectors b/tools/flask/policy/policy/flask/access_vectors
index 11d02da..ea65e45 100644
--- a/tools/flask/policy/policy/flask/access_vectors
+++ b/tools/flask/policy/policy/flask/access_vectors
@@ -80,6 +80,9 @@ class domain2
 	relabelself
 	make_priv_for
 	set_as_target
+	set_cpuid
+	gettsc
+	settsc
 }
 
 class hvm
@@ -97,6 +100,8 @@ class hvm
     hvmctl
     mem_event
     mem_sharing
+    audit_p2m
+    send_irq
 }
 
 class event
diff --git a/tools/flask/policy/policy/modules/xen/xen.if b/tools/flask/policy/policy/modules/xen/xen.if
index 2ad11b2..59ba171 100644
--- a/tools/flask/policy/policy/modules/xen/xen.if
+++ b/tools/flask/policy/policy/modules/xen/xen.if
@@ -29,6 +29,7 @@ define(`create_domain_common', `
 			getdomaininfo hypercall setvcpucontext setextvcpucontext
 			scheduler getvcpuinfo getvcpuextstate getaddrsize
 			getvcpuaffinity setvcpuaffinity };
+	allow $1 $2:domain2 { set_cpuid settsc };
 	allow $1 $2:security check_context;
 	allow $1 $2:shadow enable;
 	allow $1 $2:mmu {map_read map_write adjust memorymap physmap pinpage};
@@ -67,6 +68,7 @@ define(`migrate_domain_out', `
 	allow $1 $2:hvm { gethvmc getparam irqlevel };
 	allow $1 $2:mmu { stat pageinfo map_read };
 	allow $1 $2:domain { getaddrsize getvcpucontext getextvcpucontext getvcpuextstate pause destroy };
+	allow $1 $2:domain2 gettsc;
 ')
 
 ################################################################################
@@ -112,7 +114,7 @@ define(`device_model', `
 	domain_comms($1, $2)
 	allow $1 $2:domain { set_target shutdown };
 	allow $1 $2:mmu { map_read map_write adjust physmap };
-	allow $1 $2:hvm { getparam setparam trackdirtyvram hvmctl irqlevel pciroute };
+	allow $1 $2:hvm { getparam setparam trackdirtyvram hvmctl irqlevel pciroute cacheattr send_irq };
 ')
 ################################################################################
 #
diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
index 635f91c..089faf8 100644
--- a/xen/xsm/flask/hooks.c
+++ b/xen/xsm/flask/hooks.c
@@ -650,25 +650,32 @@ static int flask_domctl(struct domain *d, int cmd)
 #endif
         return 0;
 
+    case XEN_DOMCTL_debug_op:
+    case XEN_DOMCTL_gdbsx_guestmemio:
+    case XEN_DOMCTL_gdbsx_pausevcpu:
+    case XEN_DOMCTL_gdbsx_unpausevcpu:
+    case XEN_DOMCTL_gdbsx_domstatus:
+        return domain_has_perm(current->domain, d, SECCLASS_DOMAIN,
+                               DOMAIN__SETDEBUGGING);
+
     case XEN_DOMCTL_subscribe:
     case XEN_DOMCTL_disable_migrate:
+    case XEN_DOMCTL_suppress_spurious_page_faults:
         return domain_has_perm(current->domain, d, SECCLASS_DOMAIN,
                                DOMAIN__SET_MISC_INFO);
 
     case XEN_DOMCTL_set_cpuid:
-    case XEN_DOMCTL_suppress_spurious_page_faults:
-    case XEN_DOMCTL_debug_op:
+        return domain_has_perm(current->domain, d, SECCLASS_DOMAIN2, DOMAIN2__SET_CPUID);
+
     case XEN_DOMCTL_gettscinfo:
+        return domain_has_perm(current->domain, d, SECCLASS_DOMAIN2, DOMAIN2__GETTSC);
+
     case XEN_DOMCTL_settscinfo:
+        return domain_has_perm(current->domain, d, SECCLASS_DOMAIN2, DOMAIN2__SETTSC);
+
     case XEN_DOMCTL_audit_p2m:
-    case XEN_DOMCTL_gdbsx_guestmemio:
-    case XEN_DOMCTL_gdbsx_pausevcpu:
-    case XEN_DOMCTL_gdbsx_unpausevcpu:
-    case XEN_DOMCTL_gdbsx_domstatus:
-        /* TODO add per-subfunction hooks */
-        if ( !IS_PRIV(current->domain) )
-            return -EPERM;
-        return 0;
+        return domain_has_perm(current->domain, d, SECCLASS_HVM, HVM__AUDIT_P2M);
+
     default:
         printk("flask_domctl: Unknown op %d\n", cmd);
         return -EPERM;
@@ -921,6 +928,11 @@ static int flask_iomem_permission(struct domain *d, uint64_t start, uint64_t end
     return security_iterate_iomem_sids(start, end, _iomem_has_perm, &data);
 }
 
+static int flask_iomem_mapping(struct domain *d, uint64_t start, uint64_t end, uint8_t access)
+{
+    return flask_iomem_permission(d, start, end, access);
+}
+
 static int flask_pci_config_permission(struct domain *d, uint32_t machine_bdf, uint16_t start, uint16_t end, uint8_t access)
 {
     u32 rsid;
@@ -1128,7 +1140,6 @@ static int _ioport_has_perm(void *v, u32 sid, unsigned long start, unsigned long
     return avc_has_perm(data->tsec->sid, sid, SECCLASS_RESOURCE, RESOURCE__USE, &ad);
 }
 
-
 static int flask_ioport_permission(struct domain *d, uint32_t start, uint32_t end, uint8_t access)
 {
     int rc;
@@ -1151,6 +1162,11 @@ static int flask_ioport_permission(struct domain *d, uint32_t start, uint32_t en
     return security_iterate_ioport_sids(start, end, _ioport_has_perm, &data);
 }
 
+static int flask_ioport_mapping(struct domain *d, uint32_t start, uint32_t end, uint8_t access)
+{
+    return flask_ioport_permission(d, start, end, access);
+}
+
 static int flask_getpageframeinfo(struct domain *d)
 {
     return domain_has_perm(current->domain, d, SECCLASS_MMU, MMU__PAGEINFO);
@@ -1209,6 +1225,25 @@ static int flask_address_size(struct domain *d, uint32_t cmd)
     return domain_has_perm(current->domain, d, SECCLASS_DOMAIN, perm);
 }
 
+static int flask_machine_address_size(struct domain *d, uint32_t cmd)
+{
+    u32 perm;
+
+    switch ( cmd )
+    {
+    case XEN_DOMCTL_set_machine_address_size:
+        perm = DOMAIN__SETADDRSIZE;
+        break;
+    case XEN_DOMCTL_get_machine_address_size:
+        perm = DOMAIN__GETADDRSIZE;
+        break;
+    default:
+        return -EPERM;
+    }
+
+    return domain_has_perm(current->domain, d, SECCLASS_DOMAIN, perm);
+}
+
 static int flask_hvm_param(struct domain *d, unsigned long op)
 {
     u32 perm;
@@ -1246,6 +1281,11 @@ static int flask_hvm_set_pci_link_route(struct domain *d)
     return domain_has_perm(current->domain, d, SECCLASS_HVM, HVM__PCIROUTE);
 }
 
+static int flask_hvm_inject_msi(struct domain *d)
+{
+    return domain_has_perm(current->domain, d, SECCLASS_HVM, HVM__SEND_IRQ);
+}
+
 static int flask_mem_event(struct domain *d)
 {
     return domain_has_perm(current->domain, d, SECCLASS_HVM, HVM__MEM_EVENT);
@@ -1689,6 +1729,7 @@ static struct xsm_operations flask_ops = {
     .unmap_domain_pirq = flask_unmap_domain_pirq,
     .irq_permission = flask_irq_permission,
     .iomem_permission = flask_iomem_permission,
+    .iomem_mapping = flask_iomem_mapping,
     .pci_config_permission = flask_pci_config_permission,
 
     .resource_plug_core = flask_resource_plug_core,
@@ -1713,10 +1754,12 @@ static struct xsm_operations flask_ops = {
     .hypercall_init = flask_hypercall_init,
     .hvmcontext = flask_hvmcontext,
     .address_size = flask_address_size,
+    .machine_address_size = flask_machine_address_size,
     .hvm_param = flask_hvm_param,
     .hvm_set_pci_intx_level = flask_hvm_set_pci_intx_level,
     .hvm_set_isa_irq_level = flask_hvm_set_isa_irq_level,
     .hvm_set_pci_link_route = flask_hvm_set_pci_link_route,
+    .hvm_inject_msi = flask_hvm_inject_msi,
     .mem_event = flask_mem_event,
     .mem_sharing = flask_mem_sharing,
     .apic = flask_apic,
@@ -1749,6 +1792,7 @@ static struct xsm_operations flask_ops = {
     .ext_vcpucontext = flask_ext_vcpucontext,
     .vcpuextstate = flask_vcpuextstate,
     .ioport_permission = flask_ioport_permission,
+    .ioport_mapping = flask_ioport_mapping,
 #endif
 };
 
diff --git a/xen/xsm/flask/include/av_perm_to_string.h b/xen/xsm/flask/include/av_perm_to_string.h
index 10f8e80..894910c 100644
--- a/xen/xsm/flask/include/av_perm_to_string.h
+++ b/xen/xsm/flask/include/av_perm_to_string.h
@@ -66,6 +66,9 @@
    S_(SECCLASS_DOMAIN2, DOMAIN2__RELABELSELF, "relabelself")
    S_(SECCLASS_DOMAIN2, DOMAIN2__MAKE_PRIV_FOR, "make_priv_for")
    S_(SECCLASS_DOMAIN2, DOMAIN2__SET_AS_TARGET, "set_as_target")
+   S_(SECCLASS_DOMAIN2, DOMAIN2__SET_CPUID, "set_cpuid")
+   S_(SECCLASS_DOMAIN2, DOMAIN2__GETTSC, "gettsc")
+   S_(SECCLASS_DOMAIN2, DOMAIN2__SETTSC, "settsc")
    S_(SECCLASS_HVM, HVM__SETHVMC, "sethvmc")
    S_(SECCLASS_HVM, HVM__GETHVMC, "gethvmc")
    S_(SECCLASS_HVM, HVM__SETPARAM, "setparam")
@@ -79,6 +82,8 @@
    S_(SECCLASS_HVM, HVM__HVMCTL, "hvmctl")
    S_(SECCLASS_HVM, HVM__MEM_EVENT, "mem_event")
    S_(SECCLASS_HVM, HVM__MEM_SHARING, "mem_sharing")
+   S_(SECCLASS_HVM, HVM__AUDIT_P2M, "audit_p2m")
+   S_(SECCLASS_HVM, HVM__SEND_IRQ, "send_irq")
    S_(SECCLASS_EVENT, EVENT__BIND, "bind")
    S_(SECCLASS_EVENT, EVENT__SEND, "send")
    S_(SECCLASS_EVENT, EVENT__STATUS, "status")
diff --git a/xen/xsm/flask/include/av_permissions.h b/xen/xsm/flask/include/av_permissions.h
index f7cfee1..1bdb515 100644
--- a/xen/xsm/flask/include/av_permissions.h
+++ b/xen/xsm/flask/include/av_permissions.h
@@ -68,6 +68,9 @@
 #define DOMAIN2__RELABELSELF                      0x00000004UL
 #define DOMAIN2__MAKE_PRIV_FOR                    0x00000008UL
 #define DOMAIN2__SET_AS_TARGET                    0x00000010UL
+#define DOMAIN2__SET_CPUID                        0x00000020UL
+#define DOMAIN2__GETTSC                           0x00000040UL
+#define DOMAIN2__SETTSC                           0x00000080UL
 
 #define HVM__SETHVMC                              0x00000001UL
 #define HVM__GETHVMC                              0x00000002UL
@@ -82,6 +85,8 @@
 #define HVM__HVMCTL                               0x00000400UL
 #define HVM__MEM_EVENT                            0x00000800UL
 #define HVM__MEM_SHARING                          0x00001000UL
+#define HVM__AUDIT_P2M                            0x00002000UL
+#define HVM__SEND_IRQ                             0x00004000UL
 
 #define EVENT__BIND                               0x00000001UL
 #define EVENT__SEND                               0x00000002UL
-- 
1.7.11.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 17 15:24:24 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 15:24:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDdBE-0003fO-KM; Mon, 17 Sep 2012 15:24:12 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1TDdBB-0003Zo-9j
	for xen-devel@lists.xen.org; Mon, 17 Sep 2012 15:24:09 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-16.tower-27.messagelabs.com!1347895442!9928845!1
X-Originating-IP: [63.239.67.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8857 invoked from network); 17 Sep 2012 15:24:02 -0000
Received: from emvm-gh1-uea09.nsa.gov (HELO nsa.gov) (63.239.67.10)
	by server-16.tower-27.messagelabs.com with SMTP;
	17 Sep 2012 15:24:02 -0000
X-TM-IMSS-Message-ID: <537fe94f00131d74@nsa.gov>
Received: from tarius.tycho.ncsc.mil ([144.51.3.1]) by nsa.gov
	([63.239.67.10]) with ESMTP (TREND IMSS SMTP Service 7.1) id
	537fe94f00131d74 ; Mon, 17 Sep 2012 11:25:57 -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 q8HFO0xT027504; 
	Mon, 17 Sep 2012 11:24:01 -0400
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xen.org
Date: Mon, 17 Sep 2012 11:23:25 -0400
Message-Id: <1347895425-17959-4-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.11.4
In-Reply-To: <1347895425-17959-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1347895425-17959-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: dgdegra@tycho.nsa.gov, keir@xen.org
Subject: [Xen-devel] [PATCH 03/23] xen: Add versions of rcu_lock_*_domain
	without IS_PRIV checks
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

These functions will be used to avoid duplication of IS_PRIV calls
that will be introduced in XSM hooks.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 xen/common/domain.c     | 21 +++++++++++++++++++++
 xen/include/xen/sched.h | 11 +++++++++++
 2 files changed, 32 insertions(+)

diff --git a/xen/common/domain.c b/xen/common/domain.c
index a1aa05e..52489b3 100644
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -420,6 +420,13 @@ struct domain *rcu_lock_domain_by_id(domid_t dom)
     return d;
 }
 
+struct domain *rcu_lock_domain_by_any_id(domid_t dom)
+{
+    if ( dom == DOMID_SELF )
+        return rcu_lock_current_domain();
+    return rcu_lock_domain_by_id(dom);
+}
+
 int rcu_lock_target_domain_by_id(domid_t dom, struct domain **d)
 {
     if ( dom == DOMID_SELF )
@@ -454,6 +461,20 @@ int rcu_lock_remote_target_domain_by_id(domid_t dom, struct domain **d)
     return 0;
 }
 
+int rcu_lock_remote_domain_by_id(domid_t dom, struct domain **d)
+{
+    if ( (*d = rcu_lock_domain_by_id(dom)) == NULL )
+        return -ESRCH;
+
+    if ( *d == current->domain )
+    {
+        rcu_unlock_domain(*d);
+        return -EPERM;
+    }
+
+    return 0;
+}
+
 int domain_kill(struct domain *d)
 {
     int rc = 0;
diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
index 53804c8..b0def4a 100644
--- a/xen/include/xen/sched.h
+++ b/xen/include/xen/sched.h
@@ -447,6 +447,11 @@ struct domain *domain_create(
 struct domain *rcu_lock_domain_by_id(domid_t dom);
 
 /*
+ * As above function, but resolves DOMID_SELF to current domain
+ */
+struct domain *rcu_lock_domain_by_any_id(domid_t dom);
+
+/*
  * As above function, but accounts for current domain context:
  *  - Translates target DOMID_SELF into caller's domain id; and
  *  - Checks that caller has permission to act on the target domain.
@@ -460,6 +465,12 @@ int rcu_lock_target_domain_by_id(domid_t dom, struct domain **d);
  */
 int rcu_lock_remote_target_domain_by_id(domid_t dom, struct domain **d);
 
+/*
+ * As rcu_lock_domain_by_id(), but will fail EPERM or ESRCH rather than resolve
+ * to local domain.
+ */
+int rcu_lock_remote_domain_by_id(domid_t dom, struct domain **d);
+
 /* Finish a RCU critical region started by rcu_lock_domain_by_id(). */
 static inline void rcu_unlock_domain(struct domain *d)
 {
-- 
1.7.11.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 17 15:24:24 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 15:24:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDdBE-0003fO-KM; Mon, 17 Sep 2012 15:24:12 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1TDdBB-0003Zo-9j
	for xen-devel@lists.xen.org; Mon, 17 Sep 2012 15:24:09 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-16.tower-27.messagelabs.com!1347895442!9928845!1
X-Originating-IP: [63.239.67.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8857 invoked from network); 17 Sep 2012 15:24:02 -0000
Received: from emvm-gh1-uea09.nsa.gov (HELO nsa.gov) (63.239.67.10)
	by server-16.tower-27.messagelabs.com with SMTP;
	17 Sep 2012 15:24:02 -0000
X-TM-IMSS-Message-ID: <537fe94f00131d74@nsa.gov>
Received: from tarius.tycho.ncsc.mil ([144.51.3.1]) by nsa.gov
	([63.239.67.10]) with ESMTP (TREND IMSS SMTP Service 7.1) id
	537fe94f00131d74 ; Mon, 17 Sep 2012 11:25:57 -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 q8HFO0xT027504; 
	Mon, 17 Sep 2012 11:24:01 -0400
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xen.org
Date: Mon, 17 Sep 2012 11:23:25 -0400
Message-Id: <1347895425-17959-4-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.11.4
In-Reply-To: <1347895425-17959-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1347895425-17959-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: dgdegra@tycho.nsa.gov, keir@xen.org
Subject: [Xen-devel] [PATCH 03/23] xen: Add versions of rcu_lock_*_domain
	without IS_PRIV checks
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

These functions will be used to avoid duplication of IS_PRIV calls
that will be introduced in XSM hooks.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 xen/common/domain.c     | 21 +++++++++++++++++++++
 xen/include/xen/sched.h | 11 +++++++++++
 2 files changed, 32 insertions(+)

diff --git a/xen/common/domain.c b/xen/common/domain.c
index a1aa05e..52489b3 100644
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -420,6 +420,13 @@ struct domain *rcu_lock_domain_by_id(domid_t dom)
     return d;
 }
 
+struct domain *rcu_lock_domain_by_any_id(domid_t dom)
+{
+    if ( dom == DOMID_SELF )
+        return rcu_lock_current_domain();
+    return rcu_lock_domain_by_id(dom);
+}
+
 int rcu_lock_target_domain_by_id(domid_t dom, struct domain **d)
 {
     if ( dom == DOMID_SELF )
@@ -454,6 +461,20 @@ int rcu_lock_remote_target_domain_by_id(domid_t dom, struct domain **d)
     return 0;
 }
 
+int rcu_lock_remote_domain_by_id(domid_t dom, struct domain **d)
+{
+    if ( (*d = rcu_lock_domain_by_id(dom)) == NULL )
+        return -ESRCH;
+
+    if ( *d == current->domain )
+    {
+        rcu_unlock_domain(*d);
+        return -EPERM;
+    }
+
+    return 0;
+}
+
 int domain_kill(struct domain *d)
 {
     int rc = 0;
diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
index 53804c8..b0def4a 100644
--- a/xen/include/xen/sched.h
+++ b/xen/include/xen/sched.h
@@ -447,6 +447,11 @@ struct domain *domain_create(
 struct domain *rcu_lock_domain_by_id(domid_t dom);
 
 /*
+ * As above function, but resolves DOMID_SELF to current domain
+ */
+struct domain *rcu_lock_domain_by_any_id(domid_t dom);
+
+/*
  * As above function, but accounts for current domain context:
  *  - Translates target DOMID_SELF into caller's domain id; and
  *  - Checks that caller has permission to act on the target domain.
@@ -460,6 +465,12 @@ int rcu_lock_target_domain_by_id(domid_t dom, struct domain **d);
  */
 int rcu_lock_remote_target_domain_by_id(domid_t dom, struct domain **d);
 
+/*
+ * As rcu_lock_domain_by_id(), but will fail EPERM or ESRCH rather than resolve
+ * to local domain.
+ */
+int rcu_lock_remote_domain_by_id(domid_t dom, struct domain **d);
+
 /* Finish a RCU critical region started by rcu_lock_domain_by_id(). */
 static inline void rcu_unlock_domain(struct domain *d)
 {
-- 
1.7.11.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 17 15:24:25 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 15:24:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDdBC-0003de-TL; Mon, 17 Sep 2012 15:24:10 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1TDdBA-0003Zj-Bq
	for xen-devel@lists.xen.org; Mon, 17 Sep 2012 15:24:08 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-9.tower-27.messagelabs.com!1347895441!8532690!1
X-Originating-IP: [63.239.67.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4147 invoked from network); 17 Sep 2012 15:24:02 -0000
Received: from emvm-gh1-uea09.nsa.gov (HELO nsa.gov) (63.239.67.10)
	by server-9.tower-27.messagelabs.com with SMTP;
	17 Sep 2012 15:24:02 -0000
X-TM-IMSS-Message-ID: <537fe6a000131d72@nsa.gov>
Received: from tarius.tycho.ncsc.mil ([144.51.3.1]) by nsa.gov
	([63.239.67.10]) with ESMTP (TREND IMSS SMTP Service 7.1) id
	537fe6a000131d72 ; Mon, 17 Sep 2012 11:25:57 -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 q8HFO0xQ027504; 
	Mon, 17 Sep 2012 11:24:00 -0400
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xen.org
Date: Mon, 17 Sep 2012 11:23:22 -0400
Message-Id: <1347895425-17959-1-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.11.4
Cc: dgdegra@tycho.nsa.gov, keir@xen.org
Subject: [Xen-devel] [PATCH v4] Merge IS_PRIV checks into XSM hooks
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 v3:
 * Moved x86-specific sysctls into #ifdef CONFIG_X86 in flask/hooks.c
 * Removed pt_domain parameter from mmu_update hook when unused
 * Renamed xsm___do_xsm_op to xsm_do_xsm_op
 * Added struct domain* argument to arch_do_domctl
 * Cleaned up mem_event code duplication

Changes from v2:
 * Added overall hooks for domctl, sysctl, and platform_hypercall so
   that new sub-operations are protected by IS_PRIV checks
 * Reorganized the IS_PRIV additions to dummy.h so they are added in the
   same patch that removes the IS_PRIV they are replacing
 * Reworked hooks in the MM hotpath to increase efficiency
 * Dropped some unneeded XSM hook additions due to do_domctl hook
 * Dropped the rcu_lock*target_domain_by_id function removal patch
 * Restore IS_PRIV check in PHYSDEVOP_alloc_irq_vector
 * Use the existing hook function structure for tmem

Miscellaneous updates to FLASK:
    [PATCH 01/23] xsm/flask: remove inherited class attributes
    [PATCH 02/23] xsm/flask: remove unneeded create_sid field
    [PATCH 04/23] xsm/flask: add domain relabel support
    [PATCH 05/23] libxl: introduce XSM relabel on build
    [PATCH 06/23] flask/policy: Add domain relabel example
    [PATCH 08/23] xsm/flask: Add checks on the domain performing the

Preparatory new functions/hooks:
    [PATCH 03/23] xen: Add versions of rcu_lock_*_domain without IS_PRIV
    [PATCH 07/23] arch/x86: add distinct XSM hooks for map/unmap
    [PATCH 13/23] xen: lock target domain in do_domctl common code

IS_PRIV Refactoring:
    [PATCH 09/23] xsm: Use the dummy XSM module if XSM is disabled
    [PATCH 10/23] xen: use XSM instead of IS_PRIV where duplicated
    [PATCH 11/23] xen: avoid calling rcu_lock_*target_domain when an XSM
    [PATCH 12/23] arch/x86: convert platform_hypercall to use XSM
    [PATCH 14/23] xen: convert do_domctl to use XSM
    [PATCH 15/23] xen: convert do_sysctl to use XSM

Additional new/updated hooks:
    [PATCH 16/23] xsm/flask: add missing hooks
    [PATCH 17/23] xsm/flask: add distinct SIDs for self/target access
    [PATCH 18/23] arch/x86: Add missing mem_sharing XSM hooks
    [PATCH 19/23] arch/x86: check remote MMIO remap permissions
    [PATCH 20/23] arch/x86: use XSM hooks for get_pg_owner access checks
    [PATCH 21/23] xen: Add XSM hook for XENMEM_exchange
    [PATCH 22/23] tmem: add XSM hooks
    [PATCH 23/23] xen/arch/*: add struct domain parameter to arch_do_domctl

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 17 15:24:25 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 15:24:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDdBK-0003n6-2U; Mon, 17 Sep 2012 15:24:18 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1TDdBG-0003c7-KI
	for xen-devel@lists.xen.org; Mon, 17 Sep 2012 15:24:14 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-13.tower-27.messagelabs.com!1347895447!10242250!1
X-Originating-IP: [63.239.67.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16639 invoked from network); 17 Sep 2012 15:24:08 -0000
Received: from emvm-gh1-uea09.nsa.gov (HELO nsa.gov) (63.239.67.10)
	by server-13.tower-27.messagelabs.com with SMTP;
	17 Sep 2012 15:24:08 -0000
X-TM-IMSS-Message-ID: <537ffed100131d86@nsa.gov>
Received: from tarius.tycho.ncsc.mil ([144.51.3.1]) by nsa.gov
	([63.239.67.10]) with ESMTP (TREND IMSS SMTP Service 7.1) id
	537ffed100131d86 ; Mon, 17 Sep 2012 11:26:03 -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 q8HFO0xm027504; 
	Mon, 17 Sep 2012 11:24:06 -0400
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xen.org
Date: Mon, 17 Sep 2012 11:23:44 -0400
Message-Id: <1347895425-17959-23-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.11.4
In-Reply-To: <1347895425-17959-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1347895425-17959-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: dgdegra@tycho.nsa.gov, keir@xen.org,
	Dan Magenheimer <dan.magenheimer@oracle.com>
Subject: [Xen-devel] [PATCH 22/23] tmem: add XSM hooks
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This adds a pair of XSM hooks for tmem operations: xsm_tmem_op which
controls any use of tmem, and xsm_tmem_control which allows use of the
TMEM_CONTROL operations. By default, all domains can use tmem while only
IS_PRIV domains can use control operations.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Cc: Dan Magenheimer <dan.magenheimer@oracle.com>
---
 tools/flask/policy/policy/flask/access_vectors |  2 ++
 xen/common/tmem.c                              |  3 +++
 xen/include/xen/tmem_xen.h                     |  8 +++++++-
 xen/include/xsm/dummy.h                        | 12 ++++++++++++
 xen/include/xsm/xsm.h                          | 12 ++++++++++++
 xen/xsm/dummy.c                                |  2 ++
 xen/xsm/flask/hooks.c                          | 12 ++++++++++++
 xen/xsm/flask/include/av_perm_to_string.h      |  2 ++
 xen/xsm/flask/include/av_permissions.h         |  2 ++
 9 files changed, 54 insertions(+), 1 deletion(-)

diff --git a/tools/flask/policy/policy/flask/access_vectors b/tools/flask/policy/policy/flask/access_vectors
index caf65d2..7a7e253 100644
--- a/tools/flask/policy/policy/flask/access_vectors
+++ b/tools/flask/policy/policy/flask/access_vectors
@@ -35,6 +35,8 @@ class xen
 	lockprof
 	cpupool_op
 	sched_op
+	tmem_op
+	tmem_control
 }
 
 class domain
diff --git a/xen/common/tmem.c b/xen/common/tmem.c
index f4812b9..6d95296 100644
--- a/xen/common/tmem.c
+++ b/xen/common/tmem.c
@@ -2636,6 +2636,9 @@ EXPORT long do_tmem_op(tmem_cli_op_t uops)
     if ( !tmem_initialized )
         return -ENODEV;
 
+    if ( !tmh_current_permitted() )
+        return -EPERM;
+
     total_tmem_ops++;
 
     if ( tmh_lock_all )
diff --git a/xen/include/xen/tmem_xen.h b/xen/include/xen/tmem_xen.h
index 9492810..ae550af 100644
--- a/xen/include/xen/tmem_xen.h
+++ b/xen/include/xen/tmem_xen.h
@@ -16,6 +16,7 @@
 #include <xen/guest_access.h> /* copy_from_guest */
 #include <xen/hash.h> /* hash_long */
 #include <xen/domain_page.h> /* __map_domain_page */
+#include <xsm/xsm.h> /* xsm_tmem_control */
 #include <public/tmem.h>
 #ifdef CONFIG_COMPAT
 #include <compat/tmem.h>
@@ -326,9 +327,14 @@ static inline bool_t tmh_set_client_from_id(
     return rc;
 }
 
+static inline bool_t tmh_current_permitted(void)
+{
+    return !xsm_tmem_op();
+}
+
 static inline bool_t tmh_current_is_privileged(void)
 {
-    return IS_PRIV(current->domain);
+    return !xsm_tmem_control();
 }
 
 static inline uint8_t tmh_get_first_byte(pfp_t *pfp)
diff --git a/xen/include/xsm/dummy.h b/xen/include/xsm/dummy.h
index 331c423..277470b 100644
--- a/xen/include/xsm/dummy.h
+++ b/xen/include/xsm/dummy.h
@@ -443,6 +443,18 @@ static XSM_DEFAULT(int, sched_op) (void)
     return 0;
 }
 
+static XSM_DEFAULT(int, tmem_op) (void)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, tmem_control) (void)
+{
+    if ( !IS_PRIV(current->domain) )
+        return -EPERM;
+    return 0;
+}
+
 static XSM_DEFAULT(long, do_xsm_op)(XEN_GUEST_HANDLE(xsm_op_t) op)
 {
     return -ENOSYS;
diff --git a/xen/include/xsm/xsm.h b/xen/include/xsm/xsm.h
index db4902d..8eb3775 100644
--- a/xen/include/xsm/xsm.h
+++ b/xen/include/xsm/xsm.h
@@ -134,6 +134,8 @@ struct xsm_operations {
     int (*lockprof)(void);
     int (*cpupool_op)(void);
     int (*sched_op)(void);
+    int (*tmem_op)(void);
+    int (*tmem_control)(void);
 
     long (*do_xsm_op) (XEN_GUEST_HANDLE(xsm_op_t) op);
 
@@ -610,6 +612,16 @@ static inline int xsm_sched_op(void)
     return xsm_ops->sched_op();
 }
 
+static inline int xsm_tmem_op(void)
+{
+    return xsm_ops->tmem_op();
+}
+
+static inline int xsm_tmem_control(void)
+{
+    return xsm_ops->tmem_control();
+}
+
 static inline long xsm_do_xsm_op (XEN_GUEST_HANDLE(xsm_op_t) op)
 {
     return xsm_ops->do_xsm_op(op);
diff --git a/xen/xsm/dummy.c b/xen/xsm/dummy.c
index 26e04d5..6e113fb 100644
--- a/xen/xsm/dummy.c
+++ b/xen/xsm/dummy.c
@@ -120,6 +120,8 @@ void xsm_fixup_ops (struct xsm_operations *ops)
     set_to_dummy_if_null(ops, lockprof);
     set_to_dummy_if_null(ops, cpupool_op);
     set_to_dummy_if_null(ops, sched_op);
+    set_to_dummy_if_null(ops, tmem_op);
+    set_to_dummy_if_null(ops, tmem_control);
 
     set_to_dummy_if_null(ops, do_xsm_op);
 
diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
index a0f34b9..b59e4bb 100644
--- a/xen/xsm/flask/hooks.c
+++ b/xen/xsm/flask/hooks.c
@@ -1079,6 +1079,16 @@ static inline int flask_sched_op(void)
     return domain_has_xen(current->domain, XEN__SCHED_OP);
 }
 
+static inline int flask_tmem_op(void)
+{
+    return domain_has_xen(current->domain, XEN__TMEM_OP);
+}
+
+static inline int flask_tmem_control(void)
+{
+    return domain_has_xen(current->domain, XEN__TMEM_CONTROL);
+}
+
 static int flask_perfcontrol(void)
 {
     return domain_has_xen(current->domain, XEN__PERFCONTROL);
@@ -1723,6 +1733,8 @@ static struct xsm_operations flask_ops = {
     .lockprof = flask_lockprof,
     .cpupool_op = flask_cpupool_op,
     .sched_op = flask_sched_op,
+    .tmem_op = flask_tmem_op,
+    .tmem_control = flask_tmem_control,
 
     .do_xsm_op = do_flask_op,
 
diff --git a/xen/xsm/flask/include/av_perm_to_string.h b/xen/xsm/flask/include/av_perm_to_string.h
index 79d5939..c3f2370 100644
--- a/xen/xsm/flask/include/av_perm_to_string.h
+++ b/xen/xsm/flask/include/av_perm_to_string.h
@@ -29,6 +29,8 @@
    S_(SECCLASS_XEN, XEN__LOCKPROF, "lockprof")
    S_(SECCLASS_XEN, XEN__CPUPOOL_OP, "cpupool_op")
    S_(SECCLASS_XEN, XEN__SCHED_OP, "sched_op")
+   S_(SECCLASS_XEN, XEN__TMEM_OP, "tmem_op")
+   S_(SECCLASS_XEN, XEN__TMEM_CONTROL, "tmem_control")
    S_(SECCLASS_DOMAIN, DOMAIN__SETVCPUCONTEXT, "setvcpucontext")
    S_(SECCLASS_DOMAIN, DOMAIN__PAUSE, "pause")
    S_(SECCLASS_DOMAIN, DOMAIN__UNPAUSE, "unpause")
diff --git a/xen/xsm/flask/include/av_permissions.h b/xen/xsm/flask/include/av_permissions.h
index d982328..65302e8 100644
--- a/xen/xsm/flask/include/av_permissions.h
+++ b/xen/xsm/flask/include/av_permissions.h
@@ -29,6 +29,8 @@
 #define XEN__LOCKPROF                             0x08000000UL
 #define XEN__CPUPOOL_OP                           0x10000000UL
 #define XEN__SCHED_OP                             0x20000000UL
+#define XEN__TMEM_OP                              0x40000000UL
+#define XEN__TMEM_CONTROL                         0x80000000UL
 
 #define DOMAIN__SETVCPUCONTEXT                    0x00000001UL
 #define DOMAIN__PAUSE                             0x00000002UL
-- 
1.7.11.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 17 15:24:25 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 15:24:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDdBC-0003de-TL; Mon, 17 Sep 2012 15:24:10 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1TDdBA-0003Zj-Bq
	for xen-devel@lists.xen.org; Mon, 17 Sep 2012 15:24:08 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-9.tower-27.messagelabs.com!1347895441!8532690!1
X-Originating-IP: [63.239.67.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4147 invoked from network); 17 Sep 2012 15:24:02 -0000
Received: from emvm-gh1-uea09.nsa.gov (HELO nsa.gov) (63.239.67.10)
	by server-9.tower-27.messagelabs.com with SMTP;
	17 Sep 2012 15:24:02 -0000
X-TM-IMSS-Message-ID: <537fe6a000131d72@nsa.gov>
Received: from tarius.tycho.ncsc.mil ([144.51.3.1]) by nsa.gov
	([63.239.67.10]) with ESMTP (TREND IMSS SMTP Service 7.1) id
	537fe6a000131d72 ; Mon, 17 Sep 2012 11:25:57 -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 q8HFO0xQ027504; 
	Mon, 17 Sep 2012 11:24:00 -0400
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xen.org
Date: Mon, 17 Sep 2012 11:23:22 -0400
Message-Id: <1347895425-17959-1-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.11.4
Cc: dgdegra@tycho.nsa.gov, keir@xen.org
Subject: [Xen-devel] [PATCH v4] Merge IS_PRIV checks into XSM hooks
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 v3:
 * Moved x86-specific sysctls into #ifdef CONFIG_X86 in flask/hooks.c
 * Removed pt_domain parameter from mmu_update hook when unused
 * Renamed xsm___do_xsm_op to xsm_do_xsm_op
 * Added struct domain* argument to arch_do_domctl
 * Cleaned up mem_event code duplication

Changes from v2:
 * Added overall hooks for domctl, sysctl, and platform_hypercall so
   that new sub-operations are protected by IS_PRIV checks
 * Reorganized the IS_PRIV additions to dummy.h so they are added in the
   same patch that removes the IS_PRIV they are replacing
 * Reworked hooks in the MM hotpath to increase efficiency
 * Dropped some unneeded XSM hook additions due to do_domctl hook
 * Dropped the rcu_lock*target_domain_by_id function removal patch
 * Restore IS_PRIV check in PHYSDEVOP_alloc_irq_vector
 * Use the existing hook function structure for tmem

Miscellaneous updates to FLASK:
    [PATCH 01/23] xsm/flask: remove inherited class attributes
    [PATCH 02/23] xsm/flask: remove unneeded create_sid field
    [PATCH 04/23] xsm/flask: add domain relabel support
    [PATCH 05/23] libxl: introduce XSM relabel on build
    [PATCH 06/23] flask/policy: Add domain relabel example
    [PATCH 08/23] xsm/flask: Add checks on the domain performing the

Preparatory new functions/hooks:
    [PATCH 03/23] xen: Add versions of rcu_lock_*_domain without IS_PRIV
    [PATCH 07/23] arch/x86: add distinct XSM hooks for map/unmap
    [PATCH 13/23] xen: lock target domain in do_domctl common code

IS_PRIV Refactoring:
    [PATCH 09/23] xsm: Use the dummy XSM module if XSM is disabled
    [PATCH 10/23] xen: use XSM instead of IS_PRIV where duplicated
    [PATCH 11/23] xen: avoid calling rcu_lock_*target_domain when an XSM
    [PATCH 12/23] arch/x86: convert platform_hypercall to use XSM
    [PATCH 14/23] xen: convert do_domctl to use XSM
    [PATCH 15/23] xen: convert do_sysctl to use XSM

Additional new/updated hooks:
    [PATCH 16/23] xsm/flask: add missing hooks
    [PATCH 17/23] xsm/flask: add distinct SIDs for self/target access
    [PATCH 18/23] arch/x86: Add missing mem_sharing XSM hooks
    [PATCH 19/23] arch/x86: check remote MMIO remap permissions
    [PATCH 20/23] arch/x86: use XSM hooks for get_pg_owner access checks
    [PATCH 21/23] xen: Add XSM hook for XENMEM_exchange
    [PATCH 22/23] tmem: add XSM hooks
    [PATCH 23/23] xen/arch/*: add struct domain parameter to arch_do_domctl

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 17 15:24:25 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 15:24:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDdBK-0003n6-2U; Mon, 17 Sep 2012 15:24:18 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1TDdBG-0003c7-KI
	for xen-devel@lists.xen.org; Mon, 17 Sep 2012 15:24:14 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-13.tower-27.messagelabs.com!1347895447!10242250!1
X-Originating-IP: [63.239.67.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16639 invoked from network); 17 Sep 2012 15:24:08 -0000
Received: from emvm-gh1-uea09.nsa.gov (HELO nsa.gov) (63.239.67.10)
	by server-13.tower-27.messagelabs.com with SMTP;
	17 Sep 2012 15:24:08 -0000
X-TM-IMSS-Message-ID: <537ffed100131d86@nsa.gov>
Received: from tarius.tycho.ncsc.mil ([144.51.3.1]) by nsa.gov
	([63.239.67.10]) with ESMTP (TREND IMSS SMTP Service 7.1) id
	537ffed100131d86 ; Mon, 17 Sep 2012 11:26:03 -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 q8HFO0xm027504; 
	Mon, 17 Sep 2012 11:24:06 -0400
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xen.org
Date: Mon, 17 Sep 2012 11:23:44 -0400
Message-Id: <1347895425-17959-23-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.11.4
In-Reply-To: <1347895425-17959-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1347895425-17959-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: dgdegra@tycho.nsa.gov, keir@xen.org,
	Dan Magenheimer <dan.magenheimer@oracle.com>
Subject: [Xen-devel] [PATCH 22/23] tmem: add XSM hooks
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This adds a pair of XSM hooks for tmem operations: xsm_tmem_op which
controls any use of tmem, and xsm_tmem_control which allows use of the
TMEM_CONTROL operations. By default, all domains can use tmem while only
IS_PRIV domains can use control operations.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Cc: Dan Magenheimer <dan.magenheimer@oracle.com>
---
 tools/flask/policy/policy/flask/access_vectors |  2 ++
 xen/common/tmem.c                              |  3 +++
 xen/include/xen/tmem_xen.h                     |  8 +++++++-
 xen/include/xsm/dummy.h                        | 12 ++++++++++++
 xen/include/xsm/xsm.h                          | 12 ++++++++++++
 xen/xsm/dummy.c                                |  2 ++
 xen/xsm/flask/hooks.c                          | 12 ++++++++++++
 xen/xsm/flask/include/av_perm_to_string.h      |  2 ++
 xen/xsm/flask/include/av_permissions.h         |  2 ++
 9 files changed, 54 insertions(+), 1 deletion(-)

diff --git a/tools/flask/policy/policy/flask/access_vectors b/tools/flask/policy/policy/flask/access_vectors
index caf65d2..7a7e253 100644
--- a/tools/flask/policy/policy/flask/access_vectors
+++ b/tools/flask/policy/policy/flask/access_vectors
@@ -35,6 +35,8 @@ class xen
 	lockprof
 	cpupool_op
 	sched_op
+	tmem_op
+	tmem_control
 }
 
 class domain
diff --git a/xen/common/tmem.c b/xen/common/tmem.c
index f4812b9..6d95296 100644
--- a/xen/common/tmem.c
+++ b/xen/common/tmem.c
@@ -2636,6 +2636,9 @@ EXPORT long do_tmem_op(tmem_cli_op_t uops)
     if ( !tmem_initialized )
         return -ENODEV;
 
+    if ( !tmh_current_permitted() )
+        return -EPERM;
+
     total_tmem_ops++;
 
     if ( tmh_lock_all )
diff --git a/xen/include/xen/tmem_xen.h b/xen/include/xen/tmem_xen.h
index 9492810..ae550af 100644
--- a/xen/include/xen/tmem_xen.h
+++ b/xen/include/xen/tmem_xen.h
@@ -16,6 +16,7 @@
 #include <xen/guest_access.h> /* copy_from_guest */
 #include <xen/hash.h> /* hash_long */
 #include <xen/domain_page.h> /* __map_domain_page */
+#include <xsm/xsm.h> /* xsm_tmem_control */
 #include <public/tmem.h>
 #ifdef CONFIG_COMPAT
 #include <compat/tmem.h>
@@ -326,9 +327,14 @@ static inline bool_t tmh_set_client_from_id(
     return rc;
 }
 
+static inline bool_t tmh_current_permitted(void)
+{
+    return !xsm_tmem_op();
+}
+
 static inline bool_t tmh_current_is_privileged(void)
 {
-    return IS_PRIV(current->domain);
+    return !xsm_tmem_control();
 }
 
 static inline uint8_t tmh_get_first_byte(pfp_t *pfp)
diff --git a/xen/include/xsm/dummy.h b/xen/include/xsm/dummy.h
index 331c423..277470b 100644
--- a/xen/include/xsm/dummy.h
+++ b/xen/include/xsm/dummy.h
@@ -443,6 +443,18 @@ static XSM_DEFAULT(int, sched_op) (void)
     return 0;
 }
 
+static XSM_DEFAULT(int, tmem_op) (void)
+{
+    return 0;
+}
+
+static XSM_DEFAULT(int, tmem_control) (void)
+{
+    if ( !IS_PRIV(current->domain) )
+        return -EPERM;
+    return 0;
+}
+
 static XSM_DEFAULT(long, do_xsm_op)(XEN_GUEST_HANDLE(xsm_op_t) op)
 {
     return -ENOSYS;
diff --git a/xen/include/xsm/xsm.h b/xen/include/xsm/xsm.h
index db4902d..8eb3775 100644
--- a/xen/include/xsm/xsm.h
+++ b/xen/include/xsm/xsm.h
@@ -134,6 +134,8 @@ struct xsm_operations {
     int (*lockprof)(void);
     int (*cpupool_op)(void);
     int (*sched_op)(void);
+    int (*tmem_op)(void);
+    int (*tmem_control)(void);
 
     long (*do_xsm_op) (XEN_GUEST_HANDLE(xsm_op_t) op);
 
@@ -610,6 +612,16 @@ static inline int xsm_sched_op(void)
     return xsm_ops->sched_op();
 }
 
+static inline int xsm_tmem_op(void)
+{
+    return xsm_ops->tmem_op();
+}
+
+static inline int xsm_tmem_control(void)
+{
+    return xsm_ops->tmem_control();
+}
+
 static inline long xsm_do_xsm_op (XEN_GUEST_HANDLE(xsm_op_t) op)
 {
     return xsm_ops->do_xsm_op(op);
diff --git a/xen/xsm/dummy.c b/xen/xsm/dummy.c
index 26e04d5..6e113fb 100644
--- a/xen/xsm/dummy.c
+++ b/xen/xsm/dummy.c
@@ -120,6 +120,8 @@ void xsm_fixup_ops (struct xsm_operations *ops)
     set_to_dummy_if_null(ops, lockprof);
     set_to_dummy_if_null(ops, cpupool_op);
     set_to_dummy_if_null(ops, sched_op);
+    set_to_dummy_if_null(ops, tmem_op);
+    set_to_dummy_if_null(ops, tmem_control);
 
     set_to_dummy_if_null(ops, do_xsm_op);
 
diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
index a0f34b9..b59e4bb 100644
--- a/xen/xsm/flask/hooks.c
+++ b/xen/xsm/flask/hooks.c
@@ -1079,6 +1079,16 @@ static inline int flask_sched_op(void)
     return domain_has_xen(current->domain, XEN__SCHED_OP);
 }
 
+static inline int flask_tmem_op(void)
+{
+    return domain_has_xen(current->domain, XEN__TMEM_OP);
+}
+
+static inline int flask_tmem_control(void)
+{
+    return domain_has_xen(current->domain, XEN__TMEM_CONTROL);
+}
+
 static int flask_perfcontrol(void)
 {
     return domain_has_xen(current->domain, XEN__PERFCONTROL);
@@ -1723,6 +1733,8 @@ static struct xsm_operations flask_ops = {
     .lockprof = flask_lockprof,
     .cpupool_op = flask_cpupool_op,
     .sched_op = flask_sched_op,
+    .tmem_op = flask_tmem_op,
+    .tmem_control = flask_tmem_control,
 
     .do_xsm_op = do_flask_op,
 
diff --git a/xen/xsm/flask/include/av_perm_to_string.h b/xen/xsm/flask/include/av_perm_to_string.h
index 79d5939..c3f2370 100644
--- a/xen/xsm/flask/include/av_perm_to_string.h
+++ b/xen/xsm/flask/include/av_perm_to_string.h
@@ -29,6 +29,8 @@
    S_(SECCLASS_XEN, XEN__LOCKPROF, "lockprof")
    S_(SECCLASS_XEN, XEN__CPUPOOL_OP, "cpupool_op")
    S_(SECCLASS_XEN, XEN__SCHED_OP, "sched_op")
+   S_(SECCLASS_XEN, XEN__TMEM_OP, "tmem_op")
+   S_(SECCLASS_XEN, XEN__TMEM_CONTROL, "tmem_control")
    S_(SECCLASS_DOMAIN, DOMAIN__SETVCPUCONTEXT, "setvcpucontext")
    S_(SECCLASS_DOMAIN, DOMAIN__PAUSE, "pause")
    S_(SECCLASS_DOMAIN, DOMAIN__UNPAUSE, "unpause")
diff --git a/xen/xsm/flask/include/av_permissions.h b/xen/xsm/flask/include/av_permissions.h
index d982328..65302e8 100644
--- a/xen/xsm/flask/include/av_permissions.h
+++ b/xen/xsm/flask/include/av_permissions.h
@@ -29,6 +29,8 @@
 #define XEN__LOCKPROF                             0x08000000UL
 #define XEN__CPUPOOL_OP                           0x10000000UL
 #define XEN__SCHED_OP                             0x20000000UL
+#define XEN__TMEM_OP                              0x40000000UL
+#define XEN__TMEM_CONTROL                         0x80000000UL
 
 #define DOMAIN__SETVCPUCONTEXT                    0x00000001UL
 #define DOMAIN__PAUSE                             0x00000002UL
-- 
1.7.11.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 17 15:24:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 15:24:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDdBE-0003g0-WC; Mon, 17 Sep 2012 15:24:13 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1TDdBB-0003Zz-GW
	for xen-devel@lists.xen.org; Mon, 17 Sep 2012 15:24:09 +0000
Received: from [85.158.139.211:51880] by server-9.bemta-5.messagelabs.com id
	7C/D3-20529-99047505; Mon, 17 Sep 2012 15:24:09 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-4.tower-206.messagelabs.com!1347895447!18910997!1
X-Originating-IP: [63.239.67.9]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15429 invoked from network); 17 Sep 2012 15:24:07 -0000
Received: from emvm-gh1-uea08.nsa.gov (HELO nsa.gov) (63.239.67.9)
	by server-4.tower-206.messagelabs.com with SMTP;
	17 Sep 2012 15:24:07 -0000
X-TM-IMSS-Message-ID: <538043210012ace7@nsa.gov>
Received: from tarius.tycho.ncsc.mil ([144.51.3.1]) by nsa.gov ([63.239.67.9])
	with ESMTP (TREND IMSS SMTP Service 7.1) id 538043210012ace7 ;
	Mon, 17 Sep 2012 11:23:47 -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 q8HFO0xk027504; 
	Mon, 17 Sep 2012 11:24:06 -0400
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xen.org
Date: Mon, 17 Sep 2012 11:23:42 -0400
Message-Id: <1347895425-17959-21-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.11.4
In-Reply-To: <1347895425-17959-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1347895425-17959-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Tim Deegan <tim@xen.org>, dgdegra@tycho.nsa.gov, keir@xen.org,
	Jan Beulich <jbeulich@suse.com>
Subject: [Xen-devel] [PATCH 20/23] arch/x86: use XSM hooks for get_pg_owner
	access checks
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

There are three callers of get_pg_owner:
 * do_mmuext_op, which does not have XSM hooks on all subfunctions
 * do_mmu_update, which has hooks that are inefficient
 * do_update_va_mapping_otherdomain, which has a simple XSM hook

In order to preserve return values for the do_mmuext_op hypercall, an
additional XSM hook is required to check the operation even for those
subfunctions that do not use the pg_owner field. This also covers the
MMUEXT_UNPIN_TABLE operation which did previously have an XSM hook.

The XSM hooks in do_mmu_update were capable of replacing the checks in
get_pg_owner; however, the hooks are buried in the inner loop of the
function - not very good for performance when XSM is enabled and these
turn in to indirect function calls. This patch removes the PTE from the
hooks and replaces it with a bitfield describing what accesses are being
requested. The XSM hook can then be called only when additional bits are
set instead of once per iteration of the loop.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Cc: Keir Fraser <keir@xen.org>
Cc: Jan Beulich <jbeulich@suse.com>
Cc: Tim Deegan <tim@xen.org>
---
 tools/flask/policy/policy/flask/access_vectors |  1 +
 tools/flask/policy/policy/modules/xen/xen.if   |  4 +-
 xen/arch/x86/mm.c                              | 53 +++++++++++--------
 xen/include/xsm/dummy.h                        | 15 ++++--
 xen/include/xsm/xsm.h                          | 25 +++++----
 xen/xsm/dummy.c                                |  4 +-
 xen/xsm/flask/hooks.c                          | 71 +++++++++-----------------
 xen/xsm/flask/include/av_perm_to_string.h      |  1 +
 xen/xsm/flask/include/av_permissions.h         |  1 +
 9 files changed, 88 insertions(+), 87 deletions(-)

diff --git a/tools/flask/policy/policy/flask/access_vectors b/tools/flask/policy/policy/flask/access_vectors
index 45ac437..8324725 100644
--- a/tools/flask/policy/policy/flask/access_vectors
+++ b/tools/flask/policy/policy/flask/access_vectors
@@ -141,6 +141,7 @@ class mmu
     mfnlist
     memorymap
     remote_remap
+	mmuext_op
 }
 
 class shadow
diff --git a/tools/flask/policy/policy/modules/xen/xen.if b/tools/flask/policy/policy/modules/xen/xen.if
index d630f47..725d7a1 100644
--- a/tools/flask/policy/policy/modules/xen/xen.if
+++ b/tools/flask/policy/policy/modules/xen/xen.if
@@ -7,7 +7,7 @@
 ################################################################################
 define(`declare_domain_common', `
 	allow $1 $2:grant { query setup };
-	allow $1 $2:mmu { adjust physmap map_read map_write stat pinpage updatemp };
+	allow $1 $2:mmu { adjust physmap map_read map_write stat pinpage updatemp mmuext_op };
 	allow $1 $2:hvm { getparam setparam };
 ')
 
@@ -51,7 +51,7 @@ define(`create_domain_common', `
 	allow $1 $2:domain2 { set_cpuid settsc };
 	allow $1 $2:security check_context;
 	allow $1 $2:shadow enable;
-	allow $1 $2:mmu {map_read map_write adjust memorymap physmap pinpage};
+	allow $1 $2:mmu { map_read map_write adjust memorymap physmap pinpage mmuext_op };
 	allow $1 $2:grant setup;
 	allow $1 $2:hvm { cacheattr getparam hvmctl irqlevel pciroute sethvmc setparam pcilevel trackdirtyvram };
 ')
diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
index c0c2bf3..6e99b56 100644
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -2619,11 +2619,6 @@ static struct domain *get_pg_owner(domid_t domid)
         pg_owner = rcu_lock_domain(dom_io);
         break;
     case DOMID_XEN:
-        if ( !IS_PRIV(curr) )
-        {
-            MEM_LOG("Cannot set foreign dom");
-            break;
-        }
         pg_owner = rcu_lock_domain(dom_xen);
         break;
     default:
@@ -2632,12 +2627,6 @@ static struct domain *get_pg_owner(domid_t domid)
             MEM_LOG("Unknown domain '%u'", domid);
             break;
         }
-        if ( !IS_PRIV_FOR(curr, pg_owner) )
-        {
-            MEM_LOG("Cannot set foreign dom");
-            rcu_unlock_domain(pg_owner);
-            pg_owner = NULL;
-        }
         break;
     }
 
@@ -2725,6 +2714,13 @@ long do_mmuext_op(
         goto out;
     }
 
+    rc = xsm_mmuext_op(d, pg_owner);
+    if ( rc )
+    {
+        rcu_unlock_domain(pg_owner);
+        goto out;
+    }
+
     for ( i = 0; i < count; i++ )
     {
         if ( hypercall_preempt_check() )
@@ -3164,6 +3160,8 @@ long do_mmu_update(
     struct vcpu *v = current;
     struct domain *d = v->domain, *pt_owner = d, *pg_owner;
     struct domain_mmap_cache mapcache;
+    uint32_t xsm_needed = 0;
+    uint32_t xsm_checked = 0;
 
     if ( unlikely(count & MMU_UPDATE_PREEMPTED) )
     {
@@ -3195,11 +3193,6 @@ long do_mmu_update(
             rc = -EINVAL;
             goto out;
         }
-        if ( !IS_PRIV_FOR(d, pt_owner) )
-        {
-            rc = -ESRCH;
-            goto out;
-        }
     }
 
     if ( (pg_owner = get_pg_owner((uint16_t)foreigndom)) == NULL )
@@ -3239,9 +3232,20 @@ long do_mmu_update(
         {
             p2m_type_t p2mt;
 
-            rc = xsm_mmu_normal_update(d, pt_owner, pg_owner, req.val);
-            if ( rc )
-                break;
+            xsm_needed |= XSM_MMU_NORMAL_UPDATE;
+            if ( get_pte_flags(req.val) & _PAGE_PRESENT )
+            {
+                xsm_needed |= XSM_MMU_UPDATE_READ;
+                if ( get_pte_flags(req.val) & _PAGE_RW )
+                    xsm_needed |= XSM_MMU_UPDATE_WRITE;
+            }
+            if ( xsm_needed != xsm_checked )
+            {
+                rc = xsm_mmu_update(d, pt_owner, pg_owner, xsm_needed);
+                if ( rc )
+                    break;
+                xsm_checked = xsm_needed;
+            }
             rc = -EINVAL;
 
             req.ptr -= cmd;
@@ -3353,9 +3357,14 @@ long do_mmu_update(
             mfn = req.ptr >> PAGE_SHIFT;
             gpfn = req.val;
 
-            rc = xsm_mmu_machphys_update(d, pg_owner, mfn);
-            if ( rc )
-                break;
+            xsm_needed |= XSM_MMU_MACHPHYS_UPDATE;
+            if ( xsm_needed != xsm_checked )
+            {
+                rc = xsm_mmu_update(d, NULL, pg_owner, xsm_needed);
+                if ( rc )
+                    break;
+                xsm_checked = xsm_needed;
+            }
 
             if ( unlikely(!get_page_from_pagenr(mfn, pg_owner)) )
             {
diff --git a/xen/include/xsm/dummy.h b/xen/include/xsm/dummy.h
index 5fb0afe..dafecea 100644
--- a/xen/include/xsm/dummy.h
+++ b/xen/include/xsm/dummy.h
@@ -662,21 +662,28 @@ static XSM_DEFAULT(int, domain_memory_map) (struct domain *d)
     return 0;
 }
 
-static XSM_DEFAULT(int, mmu_normal_update) (struct domain *d, struct domain *t,
-                                            struct domain *f, intpte_t fpte)
+static XSM_DEFAULT(int, mmu_update) (struct domain *d, struct domain *t,
+                                     struct domain *f, uint32_t flags)
 {
+    if ( t && d != t && !IS_PRIV_FOR(d, t) )
+        return -EPERM;
+    if ( d != f && !IS_PRIV_FOR(d, f) )
+        return -EPERM;
     return 0;
 }
 
-static XSM_DEFAULT(int, mmu_machphys_update) (struct domain *d, struct domain *f,
-                                              unsigned long mfn)
+static XSM_DEFAULT(int, mmuext_op) (struct domain *d, struct domain *f)
 {
+    if ( d != f && !IS_PRIV_FOR(d, f) )
+        return -EPERM;
     return 0;
 }
 
 static XSM_DEFAULT(int, update_va_mapping) (struct domain *d, struct domain *f, 
                                                             l1_pgentry_t pte)
 {
+    if ( d != f && !IS_PRIV_FOR(d, f) )
+        return -EPERM;
     return 0;
 }
 
diff --git a/xen/include/xsm/xsm.h b/xen/include/xsm/xsm.h
index c08a664..6c78240 100644
--- a/xen/include/xsm/xsm.h
+++ b/xen/include/xsm/xsm.h
@@ -27,8 +27,6 @@ typedef u32 xsm_magic_t;
 #define XSM_MAGIC 0x00000000
 #endif
 
-#ifdef XSM_ENABLE
-
 extern char *policy_buffer;
 extern u32 policy_size;
 
@@ -170,9 +168,13 @@ struct xsm_operations {
     int (*getidletime) (void);
     int (*machine_memory_map) (void);
     int (*domain_memory_map) (struct domain *d);
-    int (*mmu_normal_update) (struct domain *d, struct domain *t,
-                              struct domain *f, intpte_t fpte);
-    int (*mmu_machphys_update) (struct domain *d1, struct domain *d2, unsigned long mfn);
+#define XSM_MMU_UPDATE_READ      1
+#define XSM_MMU_UPDATE_WRITE     2
+#define XSM_MMU_NORMAL_UPDATE    4
+#define XSM_MMU_MACHPHYS_UPDATE  8
+    int (*mmu_update) (struct domain *d, struct domain *t,
+                       struct domain *f, uint32_t flags);
+    int (*mmuext_op) (struct domain *d, struct domain *f);
     int (*update_va_mapping) (struct domain *d, struct domain *f, l1_pgentry_t pte);
     int (*add_to_physmap) (struct domain *d1, struct domain *d2);
     int (*sendtrigger) (struct domain *d);
@@ -186,6 +188,8 @@ struct xsm_operations {
 #endif
 };
 
+#ifdef XSM_ENABLE
+
 extern struct xsm_operations *xsm_ops;
 
 static inline void xsm_security_domaininfo (struct domain *d,
@@ -761,16 +765,15 @@ static inline int xsm_domain_memory_map(struct domain *d)
     return xsm_ops->domain_memory_map(d);
 }
 
-static inline int xsm_mmu_normal_update (struct domain *d, struct domain *t,
-                                         struct domain *f, intpte_t fpte)
+static inline int xsm_mmu_update (struct domain *d, struct domain *t,
+                                  struct domain *f, uint32_t flags)
 {
-    return xsm_ops->mmu_normal_update(d, t, f, fpte);
+    return xsm_ops->mmu_update(d, t, f, flags);
 }
 
-static inline int xsm_mmu_machphys_update (struct domain *d1, struct domain *d2,
-                                           unsigned long mfn)
+static inline int xsm_mmuext_op (struct domain *d, struct domain *f)
 {
-    return xsm_ops->mmu_machphys_update(d1, d2, mfn);
+    return xsm_ops->mmuext_op(d, f);
 }
 
 static inline int xsm_update_va_mapping(struct domain *d, struct domain *f, 
diff --git a/xen/xsm/dummy.c b/xen/xsm/dummy.c
index 3926b2b..588f367 100644
--- a/xen/xsm/dummy.c
+++ b/xen/xsm/dummy.c
@@ -154,8 +154,8 @@ void xsm_fixup_ops (struct xsm_operations *ops)
     set_to_dummy_if_null(ops, getidletime);
     set_to_dummy_if_null(ops, machine_memory_map);
     set_to_dummy_if_null(ops, domain_memory_map);
-    set_to_dummy_if_null(ops, mmu_normal_update);
-    set_to_dummy_if_null(ops, mmu_machphys_update);
+    set_to_dummy_if_null(ops, mmu_update);
+    set_to_dummy_if_null(ops, mmuext_op);
     set_to_dummy_if_null(ops, update_va_mapping);
     set_to_dummy_if_null(ops, add_to_physmap);
     set_to_dummy_if_null(ops, remove_from_physmap);
diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
index 65db2b7..cfa3683 100644
--- a/xen/xsm/flask/hooks.c
+++ b/xen/xsm/flask/hooks.c
@@ -1434,65 +1434,44 @@ static int flask_domain_memory_map(struct domain *d)
     return current_has_perm(d, SECCLASS_MMU, MMU__MEMORYMAP);
 }
 
-static int domain_memory_perm(struct domain *d, struct domain *f, l1_pgentry_t pte)
+static int flask_mmu_update(struct domain *d, struct domain *t,
+                            struct domain *f, uint32_t flags)
 {
     int rc = 0;
-    u32 map_perms = MMU__MAP_READ;
-    unsigned long fgfn, fmfn;
-    p2m_type_t p2mt;
-
-    if ( !(l1e_get_flags(pte) & _PAGE_PRESENT) )
-        return 0;
-
-    if ( l1e_get_flags(pte) & _PAGE_RW )
-        map_perms |= MMU__MAP_WRITE;
-
-    fgfn = l1e_get_pfn(pte);
-    fmfn = mfn_x(get_gfn_query(f, fgfn, &p2mt));
-    put_gfn(f, fgfn);
+    u32 map_perms = 0;
 
-    if ( f->domain_id == DOMID_IO || !mfn_valid(fmfn) )
-    {
-        struct avc_audit_data ad;
-        u32 dsid, fsid;
-        rc = security_iomem_sid(fmfn, &fsid);
-        if ( rc )
-            return rc;
-        AVC_AUDIT_DATA_INIT(&ad, MEMORY);
-        ad.sdom = d;
-        ad.tdom = f;
-        ad.memory.pte = pte.l1;
-        ad.memory.mfn = fmfn;
-        dsid = domain_sid(d);
-        return avc_has_perm(dsid, fsid, SECCLASS_MMU, map_perms, &ad);
-    }
-
-    return domain_has_perm(d, f, SECCLASS_MMU, map_perms);
-}
-
-static int flask_mmu_normal_update(struct domain *d, struct domain *t,
-                                   struct domain *f, intpte_t fpte)
-{
-    int rc = 0;
-
-    if (d != t)
+    if ( t && d != t )
         rc = domain_has_perm(d, t, SECCLASS_MMU, MMU__REMOTE_REMAP);
     if ( rc )
         return rc;
 
-    return domain_memory_perm(d, f, l1e_from_intpte(fpte));
+    if ( flags & XSM_MMU_UPDATE_READ )
+        map_perms |= MMU__MAP_READ;
+    if ( flags & XSM_MMU_UPDATE_WRITE )
+        map_perms |= MMU__MAP_WRITE;
+    if ( flags & XSM_MMU_MACHPHYS_UPDATE )
+        map_perms |= MMU__UPDATEMP;
+
+    if ( map_perms )
+        rc = domain_has_perm(d, f, SECCLASS_MMU, map_perms);
+    return rc;
 }
 
-static int flask_mmu_machphys_update(struct domain *d1, struct domain *d2,
-                                     unsigned long mfn)
+static int flask_mmuext_op(struct domain *d, struct domain *f)
 {
-    return domain_has_perm(d1, d2, SECCLASS_MMU, MMU__UPDATEMP);
+    return domain_has_perm(d, f, SECCLASS_MMU, MMU__MMUEXT_OP);
 }
 
 static int flask_update_va_mapping(struct domain *d, struct domain *f,
                                    l1_pgentry_t pte)
 {
-    return domain_memory_perm(d, f, pte);
+    u32 map_perms = MMU__MAP_READ;
+    if ( !(l1e_get_flags(pte) & _PAGE_PRESENT) )
+        return 0;
+    if ( l1e_get_flags(pte) & _PAGE_RW )
+        map_perms |= MMU__MAP_WRITE;
+
+    return domain_has_perm(d, f, SECCLASS_MMU, map_perms);
 }
 
 static int flask_add_to_physmap(struct domain *d1, struct domain *d2)
@@ -1773,8 +1752,8 @@ static struct xsm_operations flask_ops = {
     .getidletime = flask_getidletime,
     .machine_memory_map = flask_machine_memory_map,
     .domain_memory_map = flask_domain_memory_map,
-    .mmu_normal_update = flask_mmu_normal_update,
-    .mmu_machphys_update = flask_mmu_machphys_update,
+    .mmu_update = flask_mmu_update,
+    .mmuext_op = flask_mmuext_op,
     .update_va_mapping = flask_update_va_mapping,
     .add_to_physmap = flask_add_to_physmap,
     .remove_from_physmap = flask_remove_from_physmap,
diff --git a/xen/xsm/flask/include/av_perm_to_string.h b/xen/xsm/flask/include/av_perm_to_string.h
index 186f1fa..8f65b96 100644
--- a/xen/xsm/flask/include/av_perm_to_string.h
+++ b/xen/xsm/flask/include/av_perm_to_string.h
@@ -111,6 +111,7 @@
    S_(SECCLASS_MMU, MMU__MFNLIST, "mfnlist")
    S_(SECCLASS_MMU, MMU__MEMORYMAP, "memorymap")
    S_(SECCLASS_MMU, MMU__REMOTE_REMAP, "remote_remap")
+   S_(SECCLASS_MMU, MMU__MMUEXT_OP, "mmuext_op")
    S_(SECCLASS_SHADOW, SHADOW__DISABLE, "disable")
    S_(SECCLASS_SHADOW, SHADOW__ENABLE, "enable")
    S_(SECCLASS_SHADOW, SHADOW__LOGDIRTY, "logdirty")
diff --git a/xen/xsm/flask/include/av_permissions.h b/xen/xsm/flask/include/av_permissions.h
index b3831f6..18454fd 100644
--- a/xen/xsm/flask/include/av_permissions.h
+++ b/xen/xsm/flask/include/av_permissions.h
@@ -117,6 +117,7 @@
 #define MMU__MFNLIST                              0x00000400UL
 #define MMU__MEMORYMAP                            0x00000800UL
 #define MMU__REMOTE_REMAP                         0x00001000UL
+#define MMU__MMUEXT_OP                            0x00002000UL
 
 #define SHADOW__DISABLE                           0x00000001UL
 #define SHADOW__ENABLE                            0x00000002UL
-- 
1.7.11.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 17 15:24:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 15:24:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDdBE-0003g0-WC; Mon, 17 Sep 2012 15:24:13 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1TDdBB-0003Zz-GW
	for xen-devel@lists.xen.org; Mon, 17 Sep 2012 15:24:09 +0000
Received: from [85.158.139.211:51880] by server-9.bemta-5.messagelabs.com id
	7C/D3-20529-99047505; Mon, 17 Sep 2012 15:24:09 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-4.tower-206.messagelabs.com!1347895447!18910997!1
X-Originating-IP: [63.239.67.9]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15429 invoked from network); 17 Sep 2012 15:24:07 -0000
Received: from emvm-gh1-uea08.nsa.gov (HELO nsa.gov) (63.239.67.9)
	by server-4.tower-206.messagelabs.com with SMTP;
	17 Sep 2012 15:24:07 -0000
X-TM-IMSS-Message-ID: <538043210012ace7@nsa.gov>
Received: from tarius.tycho.ncsc.mil ([144.51.3.1]) by nsa.gov ([63.239.67.9])
	with ESMTP (TREND IMSS SMTP Service 7.1) id 538043210012ace7 ;
	Mon, 17 Sep 2012 11:23:47 -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 q8HFO0xk027504; 
	Mon, 17 Sep 2012 11:24:06 -0400
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xen.org
Date: Mon, 17 Sep 2012 11:23:42 -0400
Message-Id: <1347895425-17959-21-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.11.4
In-Reply-To: <1347895425-17959-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1347895425-17959-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Tim Deegan <tim@xen.org>, dgdegra@tycho.nsa.gov, keir@xen.org,
	Jan Beulich <jbeulich@suse.com>
Subject: [Xen-devel] [PATCH 20/23] arch/x86: use XSM hooks for get_pg_owner
	access checks
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

There are three callers of get_pg_owner:
 * do_mmuext_op, which does not have XSM hooks on all subfunctions
 * do_mmu_update, which has hooks that are inefficient
 * do_update_va_mapping_otherdomain, which has a simple XSM hook

In order to preserve return values for the do_mmuext_op hypercall, an
additional XSM hook is required to check the operation even for those
subfunctions that do not use the pg_owner field. This also covers the
MMUEXT_UNPIN_TABLE operation which did previously have an XSM hook.

The XSM hooks in do_mmu_update were capable of replacing the checks in
get_pg_owner; however, the hooks are buried in the inner loop of the
function - not very good for performance when XSM is enabled and these
turn in to indirect function calls. This patch removes the PTE from the
hooks and replaces it with a bitfield describing what accesses are being
requested. The XSM hook can then be called only when additional bits are
set instead of once per iteration of the loop.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Cc: Keir Fraser <keir@xen.org>
Cc: Jan Beulich <jbeulich@suse.com>
Cc: Tim Deegan <tim@xen.org>
---
 tools/flask/policy/policy/flask/access_vectors |  1 +
 tools/flask/policy/policy/modules/xen/xen.if   |  4 +-
 xen/arch/x86/mm.c                              | 53 +++++++++++--------
 xen/include/xsm/dummy.h                        | 15 ++++--
 xen/include/xsm/xsm.h                          | 25 +++++----
 xen/xsm/dummy.c                                |  4 +-
 xen/xsm/flask/hooks.c                          | 71 +++++++++-----------------
 xen/xsm/flask/include/av_perm_to_string.h      |  1 +
 xen/xsm/flask/include/av_permissions.h         |  1 +
 9 files changed, 88 insertions(+), 87 deletions(-)

diff --git a/tools/flask/policy/policy/flask/access_vectors b/tools/flask/policy/policy/flask/access_vectors
index 45ac437..8324725 100644
--- a/tools/flask/policy/policy/flask/access_vectors
+++ b/tools/flask/policy/policy/flask/access_vectors
@@ -141,6 +141,7 @@ class mmu
     mfnlist
     memorymap
     remote_remap
+	mmuext_op
 }
 
 class shadow
diff --git a/tools/flask/policy/policy/modules/xen/xen.if b/tools/flask/policy/policy/modules/xen/xen.if
index d630f47..725d7a1 100644
--- a/tools/flask/policy/policy/modules/xen/xen.if
+++ b/tools/flask/policy/policy/modules/xen/xen.if
@@ -7,7 +7,7 @@
 ################################################################################
 define(`declare_domain_common', `
 	allow $1 $2:grant { query setup };
-	allow $1 $2:mmu { adjust physmap map_read map_write stat pinpage updatemp };
+	allow $1 $2:mmu { adjust physmap map_read map_write stat pinpage updatemp mmuext_op };
 	allow $1 $2:hvm { getparam setparam };
 ')
 
@@ -51,7 +51,7 @@ define(`create_domain_common', `
 	allow $1 $2:domain2 { set_cpuid settsc };
 	allow $1 $2:security check_context;
 	allow $1 $2:shadow enable;
-	allow $1 $2:mmu {map_read map_write adjust memorymap physmap pinpage};
+	allow $1 $2:mmu { map_read map_write adjust memorymap physmap pinpage mmuext_op };
 	allow $1 $2:grant setup;
 	allow $1 $2:hvm { cacheattr getparam hvmctl irqlevel pciroute sethvmc setparam pcilevel trackdirtyvram };
 ')
diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
index c0c2bf3..6e99b56 100644
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -2619,11 +2619,6 @@ static struct domain *get_pg_owner(domid_t domid)
         pg_owner = rcu_lock_domain(dom_io);
         break;
     case DOMID_XEN:
-        if ( !IS_PRIV(curr) )
-        {
-            MEM_LOG("Cannot set foreign dom");
-            break;
-        }
         pg_owner = rcu_lock_domain(dom_xen);
         break;
     default:
@@ -2632,12 +2627,6 @@ static struct domain *get_pg_owner(domid_t domid)
             MEM_LOG("Unknown domain '%u'", domid);
             break;
         }
-        if ( !IS_PRIV_FOR(curr, pg_owner) )
-        {
-            MEM_LOG("Cannot set foreign dom");
-            rcu_unlock_domain(pg_owner);
-            pg_owner = NULL;
-        }
         break;
     }
 
@@ -2725,6 +2714,13 @@ long do_mmuext_op(
         goto out;
     }
 
+    rc = xsm_mmuext_op(d, pg_owner);
+    if ( rc )
+    {
+        rcu_unlock_domain(pg_owner);
+        goto out;
+    }
+
     for ( i = 0; i < count; i++ )
     {
         if ( hypercall_preempt_check() )
@@ -3164,6 +3160,8 @@ long do_mmu_update(
     struct vcpu *v = current;
     struct domain *d = v->domain, *pt_owner = d, *pg_owner;
     struct domain_mmap_cache mapcache;
+    uint32_t xsm_needed = 0;
+    uint32_t xsm_checked = 0;
 
     if ( unlikely(count & MMU_UPDATE_PREEMPTED) )
     {
@@ -3195,11 +3193,6 @@ long do_mmu_update(
             rc = -EINVAL;
             goto out;
         }
-        if ( !IS_PRIV_FOR(d, pt_owner) )
-        {
-            rc = -ESRCH;
-            goto out;
-        }
     }
 
     if ( (pg_owner = get_pg_owner((uint16_t)foreigndom)) == NULL )
@@ -3239,9 +3232,20 @@ long do_mmu_update(
         {
             p2m_type_t p2mt;
 
-            rc = xsm_mmu_normal_update(d, pt_owner, pg_owner, req.val);
-            if ( rc )
-                break;
+            xsm_needed |= XSM_MMU_NORMAL_UPDATE;
+            if ( get_pte_flags(req.val) & _PAGE_PRESENT )
+            {
+                xsm_needed |= XSM_MMU_UPDATE_READ;
+                if ( get_pte_flags(req.val) & _PAGE_RW )
+                    xsm_needed |= XSM_MMU_UPDATE_WRITE;
+            }
+            if ( xsm_needed != xsm_checked )
+            {
+                rc = xsm_mmu_update(d, pt_owner, pg_owner, xsm_needed);
+                if ( rc )
+                    break;
+                xsm_checked = xsm_needed;
+            }
             rc = -EINVAL;
 
             req.ptr -= cmd;
@@ -3353,9 +3357,14 @@ long do_mmu_update(
             mfn = req.ptr >> PAGE_SHIFT;
             gpfn = req.val;
 
-            rc = xsm_mmu_machphys_update(d, pg_owner, mfn);
-            if ( rc )
-                break;
+            xsm_needed |= XSM_MMU_MACHPHYS_UPDATE;
+            if ( xsm_needed != xsm_checked )
+            {
+                rc = xsm_mmu_update(d, NULL, pg_owner, xsm_needed);
+                if ( rc )
+                    break;
+                xsm_checked = xsm_needed;
+            }
 
             if ( unlikely(!get_page_from_pagenr(mfn, pg_owner)) )
             {
diff --git a/xen/include/xsm/dummy.h b/xen/include/xsm/dummy.h
index 5fb0afe..dafecea 100644
--- a/xen/include/xsm/dummy.h
+++ b/xen/include/xsm/dummy.h
@@ -662,21 +662,28 @@ static XSM_DEFAULT(int, domain_memory_map) (struct domain *d)
     return 0;
 }
 
-static XSM_DEFAULT(int, mmu_normal_update) (struct domain *d, struct domain *t,
-                                            struct domain *f, intpte_t fpte)
+static XSM_DEFAULT(int, mmu_update) (struct domain *d, struct domain *t,
+                                     struct domain *f, uint32_t flags)
 {
+    if ( t && d != t && !IS_PRIV_FOR(d, t) )
+        return -EPERM;
+    if ( d != f && !IS_PRIV_FOR(d, f) )
+        return -EPERM;
     return 0;
 }
 
-static XSM_DEFAULT(int, mmu_machphys_update) (struct domain *d, struct domain *f,
-                                              unsigned long mfn)
+static XSM_DEFAULT(int, mmuext_op) (struct domain *d, struct domain *f)
 {
+    if ( d != f && !IS_PRIV_FOR(d, f) )
+        return -EPERM;
     return 0;
 }
 
 static XSM_DEFAULT(int, update_va_mapping) (struct domain *d, struct domain *f, 
                                                             l1_pgentry_t pte)
 {
+    if ( d != f && !IS_PRIV_FOR(d, f) )
+        return -EPERM;
     return 0;
 }
 
diff --git a/xen/include/xsm/xsm.h b/xen/include/xsm/xsm.h
index c08a664..6c78240 100644
--- a/xen/include/xsm/xsm.h
+++ b/xen/include/xsm/xsm.h
@@ -27,8 +27,6 @@ typedef u32 xsm_magic_t;
 #define XSM_MAGIC 0x00000000
 #endif
 
-#ifdef XSM_ENABLE
-
 extern char *policy_buffer;
 extern u32 policy_size;
 
@@ -170,9 +168,13 @@ struct xsm_operations {
     int (*getidletime) (void);
     int (*machine_memory_map) (void);
     int (*domain_memory_map) (struct domain *d);
-    int (*mmu_normal_update) (struct domain *d, struct domain *t,
-                              struct domain *f, intpte_t fpte);
-    int (*mmu_machphys_update) (struct domain *d1, struct domain *d2, unsigned long mfn);
+#define XSM_MMU_UPDATE_READ      1
+#define XSM_MMU_UPDATE_WRITE     2
+#define XSM_MMU_NORMAL_UPDATE    4
+#define XSM_MMU_MACHPHYS_UPDATE  8
+    int (*mmu_update) (struct domain *d, struct domain *t,
+                       struct domain *f, uint32_t flags);
+    int (*mmuext_op) (struct domain *d, struct domain *f);
     int (*update_va_mapping) (struct domain *d, struct domain *f, l1_pgentry_t pte);
     int (*add_to_physmap) (struct domain *d1, struct domain *d2);
     int (*sendtrigger) (struct domain *d);
@@ -186,6 +188,8 @@ struct xsm_operations {
 #endif
 };
 
+#ifdef XSM_ENABLE
+
 extern struct xsm_operations *xsm_ops;
 
 static inline void xsm_security_domaininfo (struct domain *d,
@@ -761,16 +765,15 @@ static inline int xsm_domain_memory_map(struct domain *d)
     return xsm_ops->domain_memory_map(d);
 }
 
-static inline int xsm_mmu_normal_update (struct domain *d, struct domain *t,
-                                         struct domain *f, intpte_t fpte)
+static inline int xsm_mmu_update (struct domain *d, struct domain *t,
+                                  struct domain *f, uint32_t flags)
 {
-    return xsm_ops->mmu_normal_update(d, t, f, fpte);
+    return xsm_ops->mmu_update(d, t, f, flags);
 }
 
-static inline int xsm_mmu_machphys_update (struct domain *d1, struct domain *d2,
-                                           unsigned long mfn)
+static inline int xsm_mmuext_op (struct domain *d, struct domain *f)
 {
-    return xsm_ops->mmu_machphys_update(d1, d2, mfn);
+    return xsm_ops->mmuext_op(d, f);
 }
 
 static inline int xsm_update_va_mapping(struct domain *d, struct domain *f, 
diff --git a/xen/xsm/dummy.c b/xen/xsm/dummy.c
index 3926b2b..588f367 100644
--- a/xen/xsm/dummy.c
+++ b/xen/xsm/dummy.c
@@ -154,8 +154,8 @@ void xsm_fixup_ops (struct xsm_operations *ops)
     set_to_dummy_if_null(ops, getidletime);
     set_to_dummy_if_null(ops, machine_memory_map);
     set_to_dummy_if_null(ops, domain_memory_map);
-    set_to_dummy_if_null(ops, mmu_normal_update);
-    set_to_dummy_if_null(ops, mmu_machphys_update);
+    set_to_dummy_if_null(ops, mmu_update);
+    set_to_dummy_if_null(ops, mmuext_op);
     set_to_dummy_if_null(ops, update_va_mapping);
     set_to_dummy_if_null(ops, add_to_physmap);
     set_to_dummy_if_null(ops, remove_from_physmap);
diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
index 65db2b7..cfa3683 100644
--- a/xen/xsm/flask/hooks.c
+++ b/xen/xsm/flask/hooks.c
@@ -1434,65 +1434,44 @@ static int flask_domain_memory_map(struct domain *d)
     return current_has_perm(d, SECCLASS_MMU, MMU__MEMORYMAP);
 }
 
-static int domain_memory_perm(struct domain *d, struct domain *f, l1_pgentry_t pte)
+static int flask_mmu_update(struct domain *d, struct domain *t,
+                            struct domain *f, uint32_t flags)
 {
     int rc = 0;
-    u32 map_perms = MMU__MAP_READ;
-    unsigned long fgfn, fmfn;
-    p2m_type_t p2mt;
-
-    if ( !(l1e_get_flags(pte) & _PAGE_PRESENT) )
-        return 0;
-
-    if ( l1e_get_flags(pte) & _PAGE_RW )
-        map_perms |= MMU__MAP_WRITE;
-
-    fgfn = l1e_get_pfn(pte);
-    fmfn = mfn_x(get_gfn_query(f, fgfn, &p2mt));
-    put_gfn(f, fgfn);
+    u32 map_perms = 0;
 
-    if ( f->domain_id == DOMID_IO || !mfn_valid(fmfn) )
-    {
-        struct avc_audit_data ad;
-        u32 dsid, fsid;
-        rc = security_iomem_sid(fmfn, &fsid);
-        if ( rc )
-            return rc;
-        AVC_AUDIT_DATA_INIT(&ad, MEMORY);
-        ad.sdom = d;
-        ad.tdom = f;
-        ad.memory.pte = pte.l1;
-        ad.memory.mfn = fmfn;
-        dsid = domain_sid(d);
-        return avc_has_perm(dsid, fsid, SECCLASS_MMU, map_perms, &ad);
-    }
-
-    return domain_has_perm(d, f, SECCLASS_MMU, map_perms);
-}
-
-static int flask_mmu_normal_update(struct domain *d, struct domain *t,
-                                   struct domain *f, intpte_t fpte)
-{
-    int rc = 0;
-
-    if (d != t)
+    if ( t && d != t )
         rc = domain_has_perm(d, t, SECCLASS_MMU, MMU__REMOTE_REMAP);
     if ( rc )
         return rc;
 
-    return domain_memory_perm(d, f, l1e_from_intpte(fpte));
+    if ( flags & XSM_MMU_UPDATE_READ )
+        map_perms |= MMU__MAP_READ;
+    if ( flags & XSM_MMU_UPDATE_WRITE )
+        map_perms |= MMU__MAP_WRITE;
+    if ( flags & XSM_MMU_MACHPHYS_UPDATE )
+        map_perms |= MMU__UPDATEMP;
+
+    if ( map_perms )
+        rc = domain_has_perm(d, f, SECCLASS_MMU, map_perms);
+    return rc;
 }
 
-static int flask_mmu_machphys_update(struct domain *d1, struct domain *d2,
-                                     unsigned long mfn)
+static int flask_mmuext_op(struct domain *d, struct domain *f)
 {
-    return domain_has_perm(d1, d2, SECCLASS_MMU, MMU__UPDATEMP);
+    return domain_has_perm(d, f, SECCLASS_MMU, MMU__MMUEXT_OP);
 }
 
 static int flask_update_va_mapping(struct domain *d, struct domain *f,
                                    l1_pgentry_t pte)
 {
-    return domain_memory_perm(d, f, pte);
+    u32 map_perms = MMU__MAP_READ;
+    if ( !(l1e_get_flags(pte) & _PAGE_PRESENT) )
+        return 0;
+    if ( l1e_get_flags(pte) & _PAGE_RW )
+        map_perms |= MMU__MAP_WRITE;
+
+    return domain_has_perm(d, f, SECCLASS_MMU, map_perms);
 }
 
 static int flask_add_to_physmap(struct domain *d1, struct domain *d2)
@@ -1773,8 +1752,8 @@ static struct xsm_operations flask_ops = {
     .getidletime = flask_getidletime,
     .machine_memory_map = flask_machine_memory_map,
     .domain_memory_map = flask_domain_memory_map,
-    .mmu_normal_update = flask_mmu_normal_update,
-    .mmu_machphys_update = flask_mmu_machphys_update,
+    .mmu_update = flask_mmu_update,
+    .mmuext_op = flask_mmuext_op,
     .update_va_mapping = flask_update_va_mapping,
     .add_to_physmap = flask_add_to_physmap,
     .remove_from_physmap = flask_remove_from_physmap,
diff --git a/xen/xsm/flask/include/av_perm_to_string.h b/xen/xsm/flask/include/av_perm_to_string.h
index 186f1fa..8f65b96 100644
--- a/xen/xsm/flask/include/av_perm_to_string.h
+++ b/xen/xsm/flask/include/av_perm_to_string.h
@@ -111,6 +111,7 @@
    S_(SECCLASS_MMU, MMU__MFNLIST, "mfnlist")
    S_(SECCLASS_MMU, MMU__MEMORYMAP, "memorymap")
    S_(SECCLASS_MMU, MMU__REMOTE_REMAP, "remote_remap")
+   S_(SECCLASS_MMU, MMU__MMUEXT_OP, "mmuext_op")
    S_(SECCLASS_SHADOW, SHADOW__DISABLE, "disable")
    S_(SECCLASS_SHADOW, SHADOW__ENABLE, "enable")
    S_(SECCLASS_SHADOW, SHADOW__LOGDIRTY, "logdirty")
diff --git a/xen/xsm/flask/include/av_permissions.h b/xen/xsm/flask/include/av_permissions.h
index b3831f6..18454fd 100644
--- a/xen/xsm/flask/include/av_permissions.h
+++ b/xen/xsm/flask/include/av_permissions.h
@@ -117,6 +117,7 @@
 #define MMU__MFNLIST                              0x00000400UL
 #define MMU__MEMORYMAP                            0x00000800UL
 #define MMU__REMOTE_REMAP                         0x00001000UL
+#define MMU__MMUEXT_OP                            0x00002000UL
 
 #define SHADOW__DISABLE                           0x00000001UL
 #define SHADOW__ENABLE                            0x00000002UL
-- 
1.7.11.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 17 15:24:27 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 15:24:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDdBJ-0003mB-KD; Mon, 17 Sep 2012 15:24:17 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1TDdBG-0003c8-HO
	for xen-devel@lists.xen.org; Mon, 17 Sep 2012 15:24:14 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-11.tower-27.messagelabs.com!1347895447!2035150!1
X-Originating-IP: [63.239.67.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26508 invoked from network); 17 Sep 2012 15:24:08 -0000
Received: from emvm-gh1-uea09.nsa.gov (HELO nsa.gov) (63.239.67.10)
	by server-11.tower-27.messagelabs.com with SMTP;
	17 Sep 2012 15:24:08 -0000
X-TM-IMSS-Message-ID: <537ffd6b00131d85@nsa.gov>
Received: from tarius.tycho.ncsc.mil ([144.51.3.1]) by nsa.gov
	([63.239.67.10]) with ESMTP (TREND IMSS SMTP Service 7.1) id
	537ffd6b00131d85 ; Mon, 17 Sep 2012 11:26:02 -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 q8HFO0xl027504; 
	Mon, 17 Sep 2012 11:24:06 -0400
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xen.org
Date: Mon, 17 Sep 2012 11:23:43 -0400
Message-Id: <1347895425-17959-22-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.11.4
In-Reply-To: <1347895425-17959-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1347895425-17959-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: dgdegra@tycho.nsa.gov, keir@xen.org
Subject: [Xen-devel] [PATCH 21/23] xen: Add XSM hook for XENMEM_exchange
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Cc: Keir Fraser <keir@xen.org>
---
 tools/flask/policy/policy/flask/access_vectors |  1 +
 tools/flask/policy/policy/modules/xen/xen.if   |  2 ++
 xen/common/memory.c                            | 12 +++++++++++-
 xen/include/xsm/dummy.h                        |  7 +++++++
 xen/include/xsm/xsm.h                          |  6 ++++++
 xen/xsm/dummy.c                                |  1 +
 xen/xsm/flask/hooks.c                          |  6 ++++++
 xen/xsm/flask/include/av_perm_to_string.h      |  1 +
 xen/xsm/flask/include/av_permissions.h         |  1 +
 9 files changed, 36 insertions(+), 1 deletion(-)

diff --git a/tools/flask/policy/policy/flask/access_vectors b/tools/flask/policy/policy/flask/access_vectors
index 8324725..caf65d2 100644
--- a/tools/flask/policy/policy/flask/access_vectors
+++ b/tools/flask/policy/policy/flask/access_vectors
@@ -142,6 +142,7 @@ class mmu
     memorymap
     remote_remap
 	mmuext_op
+	exchange
 }
 
 class shadow
diff --git a/tools/flask/policy/policy/modules/xen/xen.if b/tools/flask/policy/policy/modules/xen/xen.if
index 725d7a1..67f5daf 100644
--- a/tools/flask/policy/policy/modules/xen/xen.if
+++ b/tools/flask/policy/policy/modules/xen/xen.if
@@ -30,6 +30,7 @@ define(`declare_domain', `
 #   containing at most one domain. This is not enforced by policy.
 define(`declare_singleton_domain', `
 	type $1, domain_type`'ifelse(`$#', `1', `', `,shift($@)');
+	define(`$1_self', `$1')
 	type $1_channel, event_type;
 	type_transition $1 domain_type:event $1_channel;
 	declare_domain_common($1, $1)
@@ -161,6 +162,7 @@ define(`make_device_model', `
 # use_device(domain, device)
 #   Allow a device to be used by a domain
 define(`use_device', `
+    allow $1 $1_self:mmu exchange;
     allow $1 $2:resource use;
     allow $1 $2:mmu { map_read map_write };
 ')
diff --git a/xen/common/memory.c b/xen/common/memory.c
index a984d51..edfaf3c 100644
--- a/xen/common/memory.c
+++ b/xen/common/memory.c
@@ -329,9 +329,19 @@ static long memory_exchange(XEN_GUEST_HANDLE(xen_memory_exchange_t) arg)
         out_chunk_order = exch.in.extent_order - exch.out.extent_order;
     }
 
-    rc = rcu_lock_target_domain_by_id(exch.in.domid, &d);
+    d = rcu_lock_domain_by_any_id(exch.in.domid);
+    if ( d == NULL )
+    {
+        rc = -ESRCH;
+        goto fail_early;
+    }
+
+    rc = xsm_memory_exchange(d);
     if ( rc )
+    {
+        rcu_unlock_domain(d);
         goto fail_early;
+    }
 
     memflags |= MEMF_bits(domain_clamp_alloc_bitsize(
         d,
diff --git a/xen/include/xsm/dummy.h b/xen/include/xsm/dummy.h
index dafecea..331c423 100644
--- a/xen/include/xsm/dummy.h
+++ b/xen/include/xsm/dummy.h
@@ -235,6 +235,13 @@ static XSM_DEFAULT(int, grant_query_size) (struct domain *d1, struct domain *d2)
     return 0;
 }
 
+static XSM_DEFAULT(int, memory_exchange) (struct domain *d)
+{
+    if ( d != current->domain && !IS_PRIV_FOR(current->domain, d) )
+        return -EPERM;
+    return 0;
+}
+
 static XSM_DEFAULT(int, memory_adjust_reservation) (struct domain *d1,
                                                             struct domain *d2)
 {
diff --git a/xen/include/xsm/xsm.h b/xen/include/xsm/xsm.h
index 6c78240..db4902d 100644
--- a/xen/include/xsm/xsm.h
+++ b/xen/include/xsm/xsm.h
@@ -96,6 +96,7 @@ struct xsm_operations {
 
     int (*get_pod_target) (struct domain *d);
     int (*set_pod_target) (struct domain *d);
+    int (*memory_exchange) (struct domain *d);
     int (*memory_adjust_reservation) (struct domain *d1, struct domain *d2);
     int (*memory_stat_reservation) (struct domain *d1, struct domain *d2);
     int (*memory_pin_page) (struct domain *d1, struct domain *d2, struct page_info *page);
@@ -451,6 +452,11 @@ static inline int xsm_set_pod_target (struct domain *d)
     return xsm_ops->set_pod_target(d);
 }
 
+static inline int xsm_memory_exchange (struct domain *d)
+{
+    return xsm_ops->memory_exchange(d);
+}
+
 static inline int xsm_memory_adjust_reservation (struct domain *d1, struct
                                                                     domain *d2)
 {
diff --git a/xen/xsm/dummy.c b/xen/xsm/dummy.c
index 588f367..26e04d5 100644
--- a/xen/xsm/dummy.c
+++ b/xen/xsm/dummy.c
@@ -83,6 +83,7 @@ void xsm_fixup_ops (struct xsm_operations *ops)
     set_to_dummy_if_null(ops, get_pod_target);
     set_to_dummy_if_null(ops, set_pod_target);
 
+    set_to_dummy_if_null(ops, memory_exchange);
     set_to_dummy_if_null(ops, memory_adjust_reservation);
     set_to_dummy_if_null(ops, memory_stat_reservation);
     set_to_dummy_if_null(ops, memory_pin_page);
diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
index cfa3683..a0f34b9 100644
--- a/xen/xsm/flask/hooks.c
+++ b/xen/xsm/flask/hooks.c
@@ -396,6 +396,11 @@ static int flask_set_pod_target(struct domain *d)
     return current_has_perm(d, SECCLASS_DOMAIN, DOMAIN__SETPODTARGET);
 }
 
+static int flask_memory_exchange(struct domain *d)
+{
+    return current_has_perm(d, SECCLASS_MMU, MMU__EXCHANGE);
+}
+
 static int flask_memory_adjust_reservation(struct domain *d1, struct domain *d2)
 {
     return domain_has_perm(d1, d2, SECCLASS_MMU, MMU__ADJUST);
@@ -1685,6 +1690,7 @@ static struct xsm_operations flask_ops = {
 
     .get_pod_target = flask_get_pod_target,
     .set_pod_target = flask_set_pod_target,
+    .memory_exchange = flask_memory_exchange,
     .memory_adjust_reservation = flask_memory_adjust_reservation,
     .memory_stat_reservation = flask_memory_stat_reservation,
     .memory_pin_page = flask_memory_pin_page,
diff --git a/xen/xsm/flask/include/av_perm_to_string.h b/xen/xsm/flask/include/av_perm_to_string.h
index 8f65b96..79d5939 100644
--- a/xen/xsm/flask/include/av_perm_to_string.h
+++ b/xen/xsm/flask/include/av_perm_to_string.h
@@ -112,6 +112,7 @@
    S_(SECCLASS_MMU, MMU__MEMORYMAP, "memorymap")
    S_(SECCLASS_MMU, MMU__REMOTE_REMAP, "remote_remap")
    S_(SECCLASS_MMU, MMU__MMUEXT_OP, "mmuext_op")
+   S_(SECCLASS_MMU, MMU__EXCHANGE, "exchange")
    S_(SECCLASS_SHADOW, SHADOW__DISABLE, "disable")
    S_(SECCLASS_SHADOW, SHADOW__ENABLE, "enable")
    S_(SECCLASS_SHADOW, SHADOW__LOGDIRTY, "logdirty")
diff --git a/xen/xsm/flask/include/av_permissions.h b/xen/xsm/flask/include/av_permissions.h
index 18454fd..d982328 100644
--- a/xen/xsm/flask/include/av_permissions.h
+++ b/xen/xsm/flask/include/av_permissions.h
@@ -118,6 +118,7 @@
 #define MMU__MEMORYMAP                            0x00000800UL
 #define MMU__REMOTE_REMAP                         0x00001000UL
 #define MMU__MMUEXT_OP                            0x00002000UL
+#define MMU__EXCHANGE                             0x00004000UL
 
 #define SHADOW__DISABLE                           0x00000001UL
 #define SHADOW__ENABLE                            0x00000002UL
-- 
1.7.11.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 17 15:24:27 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 15:24:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDdBJ-0003mB-KD; Mon, 17 Sep 2012 15:24:17 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1TDdBG-0003c8-HO
	for xen-devel@lists.xen.org; Mon, 17 Sep 2012 15:24:14 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-11.tower-27.messagelabs.com!1347895447!2035150!1
X-Originating-IP: [63.239.67.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26508 invoked from network); 17 Sep 2012 15:24:08 -0000
Received: from emvm-gh1-uea09.nsa.gov (HELO nsa.gov) (63.239.67.10)
	by server-11.tower-27.messagelabs.com with SMTP;
	17 Sep 2012 15:24:08 -0000
X-TM-IMSS-Message-ID: <537ffd6b00131d85@nsa.gov>
Received: from tarius.tycho.ncsc.mil ([144.51.3.1]) by nsa.gov
	([63.239.67.10]) with ESMTP (TREND IMSS SMTP Service 7.1) id
	537ffd6b00131d85 ; Mon, 17 Sep 2012 11:26:02 -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 q8HFO0xl027504; 
	Mon, 17 Sep 2012 11:24:06 -0400
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xen.org
Date: Mon, 17 Sep 2012 11:23:43 -0400
Message-Id: <1347895425-17959-22-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.11.4
In-Reply-To: <1347895425-17959-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1347895425-17959-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: dgdegra@tycho.nsa.gov, keir@xen.org
Subject: [Xen-devel] [PATCH 21/23] xen: Add XSM hook for XENMEM_exchange
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Cc: Keir Fraser <keir@xen.org>
---
 tools/flask/policy/policy/flask/access_vectors |  1 +
 tools/flask/policy/policy/modules/xen/xen.if   |  2 ++
 xen/common/memory.c                            | 12 +++++++++++-
 xen/include/xsm/dummy.h                        |  7 +++++++
 xen/include/xsm/xsm.h                          |  6 ++++++
 xen/xsm/dummy.c                                |  1 +
 xen/xsm/flask/hooks.c                          |  6 ++++++
 xen/xsm/flask/include/av_perm_to_string.h      |  1 +
 xen/xsm/flask/include/av_permissions.h         |  1 +
 9 files changed, 36 insertions(+), 1 deletion(-)

diff --git a/tools/flask/policy/policy/flask/access_vectors b/tools/flask/policy/policy/flask/access_vectors
index 8324725..caf65d2 100644
--- a/tools/flask/policy/policy/flask/access_vectors
+++ b/tools/flask/policy/policy/flask/access_vectors
@@ -142,6 +142,7 @@ class mmu
     memorymap
     remote_remap
 	mmuext_op
+	exchange
 }
 
 class shadow
diff --git a/tools/flask/policy/policy/modules/xen/xen.if b/tools/flask/policy/policy/modules/xen/xen.if
index 725d7a1..67f5daf 100644
--- a/tools/flask/policy/policy/modules/xen/xen.if
+++ b/tools/flask/policy/policy/modules/xen/xen.if
@@ -30,6 +30,7 @@ define(`declare_domain', `
 #   containing at most one domain. This is not enforced by policy.
 define(`declare_singleton_domain', `
 	type $1, domain_type`'ifelse(`$#', `1', `', `,shift($@)');
+	define(`$1_self', `$1')
 	type $1_channel, event_type;
 	type_transition $1 domain_type:event $1_channel;
 	declare_domain_common($1, $1)
@@ -161,6 +162,7 @@ define(`make_device_model', `
 # use_device(domain, device)
 #   Allow a device to be used by a domain
 define(`use_device', `
+    allow $1 $1_self:mmu exchange;
     allow $1 $2:resource use;
     allow $1 $2:mmu { map_read map_write };
 ')
diff --git a/xen/common/memory.c b/xen/common/memory.c
index a984d51..edfaf3c 100644
--- a/xen/common/memory.c
+++ b/xen/common/memory.c
@@ -329,9 +329,19 @@ static long memory_exchange(XEN_GUEST_HANDLE(xen_memory_exchange_t) arg)
         out_chunk_order = exch.in.extent_order - exch.out.extent_order;
     }
 
-    rc = rcu_lock_target_domain_by_id(exch.in.domid, &d);
+    d = rcu_lock_domain_by_any_id(exch.in.domid);
+    if ( d == NULL )
+    {
+        rc = -ESRCH;
+        goto fail_early;
+    }
+
+    rc = xsm_memory_exchange(d);
     if ( rc )
+    {
+        rcu_unlock_domain(d);
         goto fail_early;
+    }
 
     memflags |= MEMF_bits(domain_clamp_alloc_bitsize(
         d,
diff --git a/xen/include/xsm/dummy.h b/xen/include/xsm/dummy.h
index dafecea..331c423 100644
--- a/xen/include/xsm/dummy.h
+++ b/xen/include/xsm/dummy.h
@@ -235,6 +235,13 @@ static XSM_DEFAULT(int, grant_query_size) (struct domain *d1, struct domain *d2)
     return 0;
 }
 
+static XSM_DEFAULT(int, memory_exchange) (struct domain *d)
+{
+    if ( d != current->domain && !IS_PRIV_FOR(current->domain, d) )
+        return -EPERM;
+    return 0;
+}
+
 static XSM_DEFAULT(int, memory_adjust_reservation) (struct domain *d1,
                                                             struct domain *d2)
 {
diff --git a/xen/include/xsm/xsm.h b/xen/include/xsm/xsm.h
index 6c78240..db4902d 100644
--- a/xen/include/xsm/xsm.h
+++ b/xen/include/xsm/xsm.h
@@ -96,6 +96,7 @@ struct xsm_operations {
 
     int (*get_pod_target) (struct domain *d);
     int (*set_pod_target) (struct domain *d);
+    int (*memory_exchange) (struct domain *d);
     int (*memory_adjust_reservation) (struct domain *d1, struct domain *d2);
     int (*memory_stat_reservation) (struct domain *d1, struct domain *d2);
     int (*memory_pin_page) (struct domain *d1, struct domain *d2, struct page_info *page);
@@ -451,6 +452,11 @@ static inline int xsm_set_pod_target (struct domain *d)
     return xsm_ops->set_pod_target(d);
 }
 
+static inline int xsm_memory_exchange (struct domain *d)
+{
+    return xsm_ops->memory_exchange(d);
+}
+
 static inline int xsm_memory_adjust_reservation (struct domain *d1, struct
                                                                     domain *d2)
 {
diff --git a/xen/xsm/dummy.c b/xen/xsm/dummy.c
index 588f367..26e04d5 100644
--- a/xen/xsm/dummy.c
+++ b/xen/xsm/dummy.c
@@ -83,6 +83,7 @@ void xsm_fixup_ops (struct xsm_operations *ops)
     set_to_dummy_if_null(ops, get_pod_target);
     set_to_dummy_if_null(ops, set_pod_target);
 
+    set_to_dummy_if_null(ops, memory_exchange);
     set_to_dummy_if_null(ops, memory_adjust_reservation);
     set_to_dummy_if_null(ops, memory_stat_reservation);
     set_to_dummy_if_null(ops, memory_pin_page);
diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
index cfa3683..a0f34b9 100644
--- a/xen/xsm/flask/hooks.c
+++ b/xen/xsm/flask/hooks.c
@@ -396,6 +396,11 @@ static int flask_set_pod_target(struct domain *d)
     return current_has_perm(d, SECCLASS_DOMAIN, DOMAIN__SETPODTARGET);
 }
 
+static int flask_memory_exchange(struct domain *d)
+{
+    return current_has_perm(d, SECCLASS_MMU, MMU__EXCHANGE);
+}
+
 static int flask_memory_adjust_reservation(struct domain *d1, struct domain *d2)
 {
     return domain_has_perm(d1, d2, SECCLASS_MMU, MMU__ADJUST);
@@ -1685,6 +1690,7 @@ static struct xsm_operations flask_ops = {
 
     .get_pod_target = flask_get_pod_target,
     .set_pod_target = flask_set_pod_target,
+    .memory_exchange = flask_memory_exchange,
     .memory_adjust_reservation = flask_memory_adjust_reservation,
     .memory_stat_reservation = flask_memory_stat_reservation,
     .memory_pin_page = flask_memory_pin_page,
diff --git a/xen/xsm/flask/include/av_perm_to_string.h b/xen/xsm/flask/include/av_perm_to_string.h
index 8f65b96..79d5939 100644
--- a/xen/xsm/flask/include/av_perm_to_string.h
+++ b/xen/xsm/flask/include/av_perm_to_string.h
@@ -112,6 +112,7 @@
    S_(SECCLASS_MMU, MMU__MEMORYMAP, "memorymap")
    S_(SECCLASS_MMU, MMU__REMOTE_REMAP, "remote_remap")
    S_(SECCLASS_MMU, MMU__MMUEXT_OP, "mmuext_op")
+   S_(SECCLASS_MMU, MMU__EXCHANGE, "exchange")
    S_(SECCLASS_SHADOW, SHADOW__DISABLE, "disable")
    S_(SECCLASS_SHADOW, SHADOW__ENABLE, "enable")
    S_(SECCLASS_SHADOW, SHADOW__LOGDIRTY, "logdirty")
diff --git a/xen/xsm/flask/include/av_permissions.h b/xen/xsm/flask/include/av_permissions.h
index 18454fd..d982328 100644
--- a/xen/xsm/flask/include/av_permissions.h
+++ b/xen/xsm/flask/include/av_permissions.h
@@ -118,6 +118,7 @@
 #define MMU__MEMORYMAP                            0x00000800UL
 #define MMU__REMOTE_REMAP                         0x00001000UL
 #define MMU__MMUEXT_OP                            0x00002000UL
+#define MMU__EXCHANGE                             0x00004000UL
 
 #define SHADOW__DISABLE                           0x00000001UL
 #define SHADOW__ENABLE                            0x00000002UL
-- 
1.7.11.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 17 15:24:27 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 15:24:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDdBG-0003hh-FF; Mon, 17 Sep 2012 15:24:14 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1TDdBD-0003do-LO
	for xen-devel@lists.xen.org; Mon, 17 Sep 2012 15:24:12 +0000
Received: from [85.158.139.211:51995] by server-11.bemta-5.messagelabs.com id
	5C/80-24658-A9047505; Mon, 17 Sep 2012 15:24:10 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-2.tower-206.messagelabs.com!1347895448!18880337!1
X-Originating-IP: [63.239.67.9]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29810 invoked from network); 17 Sep 2012 15:24:08 -0000
Received: from emvm-gh1-uea08.nsa.gov (HELO nsa.gov) (63.239.67.9)
	by server-2.tower-206.messagelabs.com with SMTP;
	17 Sep 2012 15:24:08 -0000
X-TM-IMSS-Message-ID: <538046aa0012ace9@nsa.gov>
Received: from tarius.tycho.ncsc.mil ([144.51.3.1]) by nsa.gov ([63.239.67.9])
	with ESMTP (TREND IMSS SMTP Service 7.1) id 538046aa0012ace9 ;
	Mon, 17 Sep 2012 11:23:48 -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 q8HFO0xn027504; 
	Mon, 17 Sep 2012 11:24:06 -0400
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xen.org
Date: Mon, 17 Sep 2012 11:23:45 -0400
Message-Id: <1347895425-17959-24-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.11.4
In-Reply-To: <1347895425-17959-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1347895425-17959-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: keir@xen.org, Ian Campbell <ian.campbell@citrix.com>,
	Tim Deegan <tim@xen.org>,
	Stefano Stabellini <stefano.stabellini@citrix.com>,
	Jan Beulich <jbeulich@suse.com>, dgdegra@tycho.nsa.gov
Subject: [Xen-devel] [PATCH 23/23] xen/arch/*: add struct domain parameter
	to arch_do_domctl
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 arch-independent do_domctl function now RCU locks the domain
specified by op->domain, pass the struct domain to the arch-specific
domctl function and remove the duplicate per-subfunction locking.

This also removes two get_domain/put_domain call pairs (in
XEN_DOMCTL_assign_device and XEN_DOMCTL_deassign_device), replacing them
with RCU locking.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Cc: Ian Campbell <ian.campbell@citrix.com>
Cc: Stefano Stabellini <stefano.stabellini@citrix.com>
Cc: Tim Deegan <tim@xen.org>
Cc: Jan Beulich <jbeulich@suse.com>
---
 xen/arch/arm/domctl.c           |   2 +-
 xen/arch/x86/domctl.c           | 434 +++++++---------------------------------
 xen/common/domctl.c             |   2 +-
 xen/drivers/passthrough/iommu.c |  31 +--
 xen/include/xen/hypercall.h     |   2 +-
 xen/include/xen/iommu.h         |   3 +-
 6 files changed, 76 insertions(+), 398 deletions(-)

diff --git a/xen/arch/arm/domctl.c b/xen/arch/arm/domctl.c
index 1a5f79f..12531d1 100644
--- a/xen/arch/arm/domctl.c
+++ b/xen/arch/arm/domctl.c
@@ -10,7 +10,7 @@
 #include <xen/errno.h>
 #include <public/domctl.h>
 
-long arch_do_domctl(struct xen_domctl *domctl,
+long arch_do_domctl(struct xen_domctl *domctl, struct domain *d,
                     XEN_GUEST_HANDLE(xen_domctl_t) u_domctl)
 {
     return -ENOSYS;
diff --git a/xen/arch/x86/domctl.c b/xen/arch/x86/domctl.c
index 7062f02..734b2f2 100644
--- a/xen/arch/x86/domctl.c
+++ b/xen/arch/x86/domctl.c
@@ -47,7 +47,7 @@ static int gdbsx_guest_mem_io(
 }
 
 long arch_do_domctl(
-    struct xen_domctl *domctl,
+    struct xen_domctl *domctl, struct domain *d,
     XEN_GUEST_HANDLE(xen_domctl_t) u_domctl)
 {
     long ret = 0;
@@ -57,23 +57,15 @@ long arch_do_domctl(
 
     case XEN_DOMCTL_shadow_op:
     {
-        struct domain *d;
-        ret = -ESRCH;
-        d = rcu_lock_domain_by_id(domctl->domain);
-        if ( d != NULL )
-        {
-            ret = paging_domctl(d,
-                                &domctl->u.shadow_op,
-                                guest_handle_cast(u_domctl, void));
-            rcu_unlock_domain(d);
-            copy_to_guest(u_domctl, domctl, 1);
-        } 
+        ret = paging_domctl(d,
+                            &domctl->u.shadow_op,
+                            guest_handle_cast(u_domctl, void));
+        copy_to_guest(u_domctl, domctl, 1);
     }
     break;
 
     case XEN_DOMCTL_ioport_permission:
     {
-        struct domain *d;
         unsigned int fp = domctl->u.ioport_permission.first_port;
         unsigned int np = domctl->u.ioport_permission.nr_ports;
         int allow = domctl->u.ioport_permission.allow_access;
@@ -82,10 +74,6 @@ long arch_do_domctl(
         if ( (fp + np) > 65536 )
             break;
 
-        ret = -ESRCH;
-        if ( unlikely((d = rcu_lock_domain_by_id(domctl->domain)) == NULL) )
-            break;
-
         if ( np == 0 )
             ret = 0;
         else if ( xsm_ioport_permission(d, fp, fp + np - 1, allow) )
@@ -94,8 +82,6 @@ long arch_do_domctl(
             ret = ioports_permit_access(d, fp, fp + np - 1);
         else
             ret = ioports_deny_access(d, fp, fp + np - 1);
-
-        rcu_unlock_domain(d);
     }
     break;
 
@@ -103,23 +89,16 @@ long arch_do_domctl(
     {
         struct page_info *page;
         unsigned long mfn = domctl->u.getpageframeinfo.gmfn;
-        domid_t dom = domctl->domain;
-        struct domain *d;
 
         ret = -EINVAL;
-
-        if ( unlikely(!mfn_valid(mfn)) ||
-             unlikely((d = rcu_lock_domain_by_id(dom)) == NULL) )
+        if ( unlikely(!mfn_valid(mfn)) )
             break;
 
         page = mfn_to_page(mfn);
 
         ret = xsm_getpageframeinfo(d);
         if ( ret )
-        {
-            rcu_unlock_domain(d);
             break;
-        }
 
         if ( likely(get_page(page, d)) )
         {
@@ -149,8 +128,6 @@ long arch_do_domctl(
             put_page(page);
         }
 
-        rcu_unlock_domain(d);
-
         copy_to_guest(u_domctl, domctl, 1);
     }
     break;
@@ -160,27 +137,17 @@ long arch_do_domctl(
         {
             unsigned int n, j;
             unsigned int num = domctl->u.getpageframeinfo3.num;
-            domid_t dom = domctl->domain;
-            struct domain *d;
             struct page_info *page;
             xen_pfn_t *arr;
 
-            ret = -ESRCH;
-            if ( unlikely((d = rcu_lock_domain_by_id(dom)) == NULL) )
-                break;
-
             ret = xsm_getpageframeinfo(d);
             if ( ret )
-            {
-                rcu_unlock_domain(d);
                 break;
-            }
 
             if ( unlikely(num > 1024) ||
                  unlikely(num != domctl->u.getpageframeinfo3.num) )
             {
                 ret = -E2BIG;
-                rcu_unlock_domain(d);
                 break;
             }
 
@@ -188,7 +155,6 @@ long arch_do_domctl(
             if ( !page )
             {
                 ret = -ENOMEM;
-                rcu_unlock_domain(d);
                 break;
             }
             arr = page_to_virt(page);
@@ -254,7 +220,6 @@ long arch_do_domctl(
 
             free_domheap_page(virt_to_page(arr));
 
-            rcu_unlock_domain(d);
             break;
         }
         /* fall thru */
@@ -262,25 +227,15 @@ long arch_do_domctl(
     {
         int n,j;
         int num = domctl->u.getpageframeinfo2.num;
-        domid_t dom = domctl->domain;
-        struct domain *d;
         uint32_t *arr32;
-        ret = -ESRCH;
-
-        if ( unlikely((d = rcu_lock_domain_by_id(dom)) == NULL) )
-            break;
 
         ret = xsm_getpageframeinfo(d);
         if ( ret )
-        {
-            rcu_unlock_domain(d);
             break;
-        }
 
         if ( unlikely(num > 1024) )
         {
             ret = -E2BIG;
-            rcu_unlock_domain(d);
             break;
         }
 
@@ -288,7 +243,6 @@ long arch_do_domctl(
         if ( !arr32 )
         {
             ret = -ENOMEM;
-            rcu_unlock_domain(d);
             break;
         }
  
@@ -360,78 +314,58 @@ long arch_do_domctl(
         }
 
         free_xenheap_page(arr32);
-
-        rcu_unlock_domain(d);
     }
     break;
 
     case XEN_DOMCTL_getmemlist:
     {
         int i;
-        struct domain *d = rcu_lock_domain_by_id(domctl->domain);
         unsigned long max_pfns = domctl->u.getmemlist.max_pfns;
         uint64_t mfn;
         struct page_info *page;
 
-        ret = -EINVAL;
-        if ( d != NULL )
-        {
-            ret = xsm_getmemlist(d);
-            if ( ret )
-            {
-                rcu_unlock_domain(d);
-                break;
-            }
+        ret = xsm_getmemlist(d);
+        if ( ret )
+            break;
 
-            spin_lock(&d->page_alloc_lock);
+        if ( unlikely(d->is_dying) ) {
+            ret = -EINVAL;
+            break;
+        }
 
-            if ( unlikely(d->is_dying) ) {
-                spin_unlock(&d->page_alloc_lock);
-                goto getmemlist_out;
-            }
+        spin_lock(&d->page_alloc_lock);
 
-            ret = i = 0;
-            page_list_for_each(page, &d->page_list)
+        ret = i = 0;
+        page_list_for_each(page, &d->page_list)
+        {
+            if ( i >= max_pfns )
+                break;
+            mfn = page_to_mfn(page);
+            if ( copy_to_guest_offset(domctl->u.getmemlist.buffer,
+                                      i, &mfn, 1) )
             {
-                if ( i >= max_pfns )
-                    break;
-                mfn = page_to_mfn(page);
-                if ( copy_to_guest_offset(domctl->u.getmemlist.buffer,
-                                          i, &mfn, 1) )
-                {
-                    ret = -EFAULT;
-                    break;
-                }
-                ++i;
+                ret = -EFAULT;
+                break;
             }
-            
-            spin_unlock(&d->page_alloc_lock);
-
-            domctl->u.getmemlist.num_pfns = i;
-            copy_to_guest(u_domctl, domctl, 1);
-        getmemlist_out:
-            rcu_unlock_domain(d);
+            ++i;
         }
+        
+        spin_unlock(&d->page_alloc_lock);
+
+        domctl->u.getmemlist.num_pfns = i;
+        copy_to_guest(u_domctl, domctl, 1);
     }
     break;
 
     case XEN_DOMCTL_hypercall_init:
     {
-        struct domain *d = rcu_lock_domain_by_id(domctl->domain);
         unsigned long gmfn = domctl->u.hypercall_init.gmfn;
         struct page_info *page;
         void *hypercall_page;
 
-        ret = -ESRCH;
-        if ( unlikely(d == NULL) )
-            break;
-
         ret = xsm_hypercall_init(d);
         if ( ret )
-        {
-            rcu_unlock_domain(d);
             break;
-        }
 
         page = get_page_from_gfn(d, gmfn, NULL, P2M_ALLOC);
 
@@ -440,7 +374,6 @@ long arch_do_domctl(
         {
             if ( page )
                 put_page(page);
-            rcu_unlock_domain(d);
             break;
         }
 
@@ -451,19 +384,12 @@ long arch_do_domctl(
         unmap_domain_page(hypercall_page);
 
         put_page_and_type(page);
-
-        rcu_unlock_domain(d);
     }
     break;
 
     case XEN_DOMCTL_sethvmcontext:
     { 
         struct hvm_domain_context c = { .size = domctl->u.hvmcontext.size };
-        struct domain *d;
-
-        ret = -ESRCH;
-        if ( (d = rcu_lock_domain_by_id(domctl->domain)) == NULL )
-            break;
 
         ret = xsm_hvmcontext(d, domctl->cmd);
         if ( ret )
@@ -488,19 +414,12 @@ long arch_do_domctl(
     sethvmcontext_out:
         if ( c.data != NULL )
             xfree(c.data);
-
-        rcu_unlock_domain(d);
     }
     break;
 
     case XEN_DOMCTL_gethvmcontext:
     { 
         struct hvm_domain_context c = { 0 };
-        struct domain *d;
-
-        ret = -ESRCH;
-        if ( (d = rcu_lock_domain_by_id(domctl->domain)) == NULL )
-            break;
 
         ret = xsm_hvmcontext(d, domctl->cmd);
         if ( ret )
@@ -544,53 +463,33 @@ long arch_do_domctl(
 
         if ( c.data != NULL )
             xfree(c.data);
-
-        rcu_unlock_domain(d);
     }
     break;
 
     case XEN_DOMCTL_gethvmcontext_partial:
     { 
-        struct domain *d;
-
-        ret = -ESRCH;
-        if ( (d = rcu_lock_domain_by_id(domctl->domain)) == NULL )
-            break;
-
         ret = xsm_hvmcontext(d, domctl->cmd);
         if ( ret )
-            goto gethvmcontext_partial_out;
+            break;
 
         ret = -EINVAL;
         if ( !is_hvm_domain(d) ) 
-            goto gethvmcontext_partial_out;
+            break;
 
         domain_pause(d);
         ret = hvm_save_one(d, domctl->u.hvmcontext_partial.type,
                            domctl->u.hvmcontext_partial.instance,
                            domctl->u.hvmcontext_partial.buffer);
         domain_unpause(d);
-
-    gethvmcontext_partial_out:
-        rcu_unlock_domain(d);
     }
     break;
 
 
     case XEN_DOMCTL_set_address_size:
     {
-        struct domain *d;
-
-        ret = -ESRCH;
-        if ( (d = rcu_lock_domain_by_id(domctl->domain)) == NULL )
-            break;
-
         ret = xsm_address_size(d, domctl->cmd);
         if ( ret )
-        {
-            rcu_unlock_domain(d);
             break;
-        }
 
         switch ( domctl->u.address_size.size )
         {
@@ -604,31 +503,19 @@ long arch_do_domctl(
             ret = (domctl->u.address_size.size == BITS_PER_LONG) ? 0 : -EINVAL;
             break;
         }
-
-        rcu_unlock_domain(d);
     }
     break;
 
     case XEN_DOMCTL_get_address_size:
     {
-        struct domain *d;
-
-        ret = -ESRCH;
-        if ( (d = rcu_lock_domain_by_id(domctl->domain)) == NULL )
-            break;
-
         ret = xsm_address_size(d, domctl->cmd);
         if ( ret )
-        {
-            rcu_unlock_domain(d);
             break;
-        }
 
         domctl->u.address_size.size =
             is_pv_32on64_domain(d) ? 32 : BITS_PER_LONG;
 
         ret = 0;
-        rcu_unlock_domain(d);
 
         if ( copy_to_guest(u_domctl, domctl, 1) )
             ret = -EFAULT;
@@ -637,76 +524,51 @@ long arch_do_domctl(
 
     case XEN_DOMCTL_set_machine_address_size:
     {
-        struct domain *d;
-
-        ret = -ESRCH;
-        if ( (d = rcu_lock_domain_by_id(domctl->domain)) == NULL )
-            break;
-
         ret = xsm_machine_address_size(d, domctl->cmd);
         if ( ret )
-            goto set_machine_address_size_out;
+            break;
 
         ret = -EBUSY;
         if ( d->tot_pages > 0 )
-            goto set_machine_address_size_out;
+            break;
 
         d->arch.physaddr_bitsize = domctl->u.address_size.size;
 
         ret = 0;
-    set_machine_address_size_out:
-        rcu_unlock_domain(d);
     }
     break;
 
     case XEN_DOMCTL_get_machine_address_size:
     {
-        struct domain *d;
-
-        ret = -ESRCH;
-        if ( (d = rcu_lock_domain_by_id(domctl->domain)) == NULL )
-            break;
-
         ret = xsm_machine_address_size(d, domctl->cmd);
         if ( ret )
-        {
-            rcu_unlock_domain(d);
             break;
-        }
 
         domctl->u.address_size.size = d->arch.physaddr_bitsize;
 
         ret = 0;
-        rcu_unlock_domain(d);
 
         if ( copy_to_guest(u_domctl, domctl, 1) )
             ret = -EFAULT;
-
-
     }
     break;
 
     case XEN_DOMCTL_sendtrigger:
     {
-        struct domain *d;
         struct vcpu *v;
 
-        ret = -ESRCH;
-        if ( (d = rcu_lock_domain_by_id(domctl->domain)) == NULL )
-            break;
-
         ret = xsm_sendtrigger(d);
         if ( ret )
-            goto sendtrigger_out;
+            break;
 
         ret = -EINVAL;
         if ( domctl->u.sendtrigger.vcpu >= MAX_VIRT_CPUS )
-            goto sendtrigger_out;
+            break;
 
         ret = -ESRCH;
         if ( domctl->u.sendtrigger.vcpu >= d->max_vcpus ||
              (v = d->vcpu[domctl->u.sendtrigger.vcpu]) == NULL )
-            goto sendtrigger_out;
+            break;
 
         switch ( domctl->u.sendtrigger.trigger )
         {
@@ -743,34 +605,27 @@ long arch_do_domctl(
         default:
             ret = -ENOSYS;
         }
-
-    sendtrigger_out:
-        rcu_unlock_domain(d);
     }
     break;
 
     case XEN_DOMCTL_bind_pt_irq:
     {
-        struct domain * d;
         xen_domctl_bind_pt_irq_t * bind;
 
-        ret = -ESRCH;
-        if ( (d = rcu_lock_domain_by_id(domctl->domain)) == NULL )
-            break;
         bind = &(domctl->u.bind_pt_irq);
 
         ret = -EINVAL;
         if ( !is_hvm_domain(d) )
-            goto bind_out;
+            break;
 
         ret = xsm_bind_pt_irq(d, bind);
         if ( ret )
-            goto bind_out;
+            break;
 
         ret = -EPERM;
         if ( !IS_PRIV(current->domain) &&
              !irq_access_permitted(current->domain, bind->machine_irq) )
-            goto bind_out;
+            break;
 
         ret = -ESRCH;
         if ( iommu_enabled )
@@ -782,30 +637,23 @@ long arch_do_domctl(
         if ( ret < 0 )
             printk(XENLOG_G_ERR "pt_irq_create_bind failed (%ld) for dom%d\n",
                    ret, d->domain_id);
-
-    bind_out:
-        rcu_unlock_domain(d);
     }
     break;    
 
     case XEN_DOMCTL_unbind_pt_irq:
     {
-        struct domain * d;
         xen_domctl_bind_pt_irq_t * bind;
 
-        ret = -ESRCH;
-        if ( (d = rcu_lock_domain_by_id(domctl->domain)) == NULL )
-            break;
         bind = &(domctl->u.bind_pt_irq);
 
         ret = -EPERM;
         if ( !IS_PRIV(current->domain) &&
              !irq_access_permitted(current->domain, bind->machine_irq) )
-            goto unbind_out;
+            break;
 
         ret = xsm_unbind_pt_irq(d, bind);
         if ( ret )
-            goto unbind_out;
+            break;
 
         if ( iommu_enabled )
         {
@@ -816,15 +664,11 @@ long arch_do_domctl(
         if ( ret < 0 )
             printk(XENLOG_G_ERR "pt_irq_destroy_bind failed (%ld) for dom%d\n",
                    ret, d->domain_id);
-
-    unbind_out:
-        rcu_unlock_domain(d);
     }
     break;
 
     case XEN_DOMCTL_memory_mapping:
     {
-        struct domain *d;
         unsigned long gfn = domctl->u.memory_mapping.first_gfn;
         unsigned long mfn = domctl->u.memory_mapping.first_mfn;
         unsigned long nr_mfns = domctl->u.memory_mapping.nr_mfns;
@@ -840,15 +684,9 @@ long arch_do_domctl(
              !iomem_access_permitted(current->domain, mfn, mfn + nr_mfns - 1) )
             break;
 
-        ret = -ESRCH;
-        if ( unlikely((d = rcu_lock_domain_by_id(domctl->domain)) == NULL) )
-            break;
-
         ret = xsm_iomem_mapping(d, mfn, mfn + nr_mfns - 1, add);
-        if ( ret ) {
-            rcu_unlock_domain(d);
+        if ( ret )
             break;
-        }
 
         if ( add )
         {
@@ -870,15 +708,12 @@ long arch_do_domctl(
                 clear_mmio_p2m_entry(d, gfn+i);
             ret = iomem_deny_access(d, mfn, mfn + nr_mfns - 1);
         }
-
-        rcu_unlock_domain(d);
     }
     break;
 
     case XEN_DOMCTL_ioport_mapping:
     {
 #define MAX_IOPORTS    0x10000
-        struct domain *d;
         struct hvm_iommu *hd;
         unsigned int fgp = domctl->u.ioport_mapping.first_gport;
         unsigned int fmp = domctl->u.ioport_mapping.first_mport;
@@ -902,15 +737,9 @@ long arch_do_domctl(
              !ioports_access_permitted(current->domain, fmp, fmp + np - 1) )
             break;
 
-        ret = -ESRCH;
-        if ( unlikely((d = rcu_lock_domain_by_id(domctl->domain)) == NULL) )
-            break;
-
         ret = xsm_ioport_mapping(d, fmp, fmp + np - 1, add);
-        if ( ret ) {
-            rcu_unlock_domain(d);
+        if ( ret )
             break;
-        }
 
         hd = domain_hvm_iommu(d);
         if ( add )
@@ -951,30 +780,19 @@ long arch_do_domctl(
                 }
             ret = ioports_deny_access(d, fmp, fmp + np - 1);
         }
-        rcu_unlock_domain(d);
     }
     break;
 
     case XEN_DOMCTL_pin_mem_cacheattr:
     {
-        struct domain *d;
-
-        ret = -ESRCH;
-        d = rcu_lock_domain_by_id(domctl->domain);
-        if ( d == NULL )
-            break;
-
         ret = xsm_pin_mem_cacheattr(d);
         if ( ret )
-            goto pin_out;
+            break;
 
         ret = hvm_set_mem_pinned_cacheattr(
             d, domctl->u.pin_mem_cacheattr.start,
             domctl->u.pin_mem_cacheattr.end,
             domctl->u.pin_mem_cacheattr.type);
-
-    pin_out:
-        rcu_unlock_domain(d);
     }
     break;
 
@@ -982,19 +800,13 @@ long arch_do_domctl(
     case XEN_DOMCTL_get_ext_vcpucontext:
     {
         struct xen_domctl_ext_vcpucontext *evc;
-        struct domain *d;
         struct vcpu *v;
 
         evc = &domctl->u.ext_vcpucontext;
 
-        ret = -ESRCH;
-        d = rcu_lock_domain_by_id(domctl->domain);
-        if ( d == NULL )
-            break;
-
         ret = xsm_ext_vcpucontext(d, domctl->cmd);
         if ( ret )
-            goto ext_vcpucontext_out;
+            break;
 
         ret = -ESRCH;
         if ( (evc->vcpu >= d->max_vcpus) ||
@@ -1071,7 +883,6 @@ long arch_do_domctl(
         ret = 0;
 
     ext_vcpucontext_out:
-        rcu_unlock_domain(d);
         if ( (domctl->cmd == XEN_DOMCTL_get_ext_vcpucontext) &&
              copy_to_guest(u_domctl, domctl, 1) )
             ret = -EFAULT;
@@ -1080,16 +891,10 @@ long arch_do_domctl(
 
     case XEN_DOMCTL_set_cpuid:
     {
-        struct domain *d;
         xen_domctl_cpuid_t *ctl = &domctl->u.cpuid;
         cpuid_input_t *cpuid = NULL; 
         int i;
 
-        ret = -ESRCH;
-        d = rcu_lock_domain_by_id(domctl->domain);
-        if ( d == NULL )
-            break;
-
         for ( i = 0; i < MAX_CPUID_INPUT; i++ )
         {
             cpuid = &d->arch.cpuids[i];
@@ -1112,21 +917,13 @@ long arch_do_domctl(
             memcpy(cpuid, ctl, sizeof(cpuid_input_t));
             ret = 0;
         }
-
-        rcu_unlock_domain(d);
     }
     break;
 
     case XEN_DOMCTL_gettscinfo:
     {
-        struct domain *d;
         xen_guest_tsc_info_t info;
 
-        ret = -ESRCH;
-        d = rcu_lock_domain_by_id(domctl->domain);
-        if ( d == NULL )
-            break;
-
         domain_pause(d);
         tsc_get_info(d, &info.tsc_mode,
                         &info.elapsed_nsec,
@@ -1137,20 +934,11 @@ long arch_do_domctl(
         else
             ret = 0;
         domain_unpause(d);
-
-        rcu_unlock_domain(d);
     }
     break;
 
     case XEN_DOMCTL_settscinfo:
     {
-        struct domain *d;
-
-        ret = -ESRCH;
-        d = rcu_lock_domain_by_id(domctl->domain);
-        if ( d == NULL )
-            break;
-
         domain_pause(d);
         tsc_set_info(d, domctl->u.tsc_info.info.tsc_mode,
                      domctl->u.tsc_info.info.elapsed_nsec,
@@ -1158,138 +946,83 @@ long arch_do_domctl(
                      domctl->u.tsc_info.info.incarnation);
         domain_unpause(d);
 
-        rcu_unlock_domain(d);
         ret = 0;
     }
     break;
 
     case XEN_DOMCTL_suppress_spurious_page_faults:
     {
-        struct domain *d;
-
-        ret = -ESRCH;
-        d = rcu_lock_domain_by_id(domctl->domain);
-        if ( d != NULL )
-        {
-            d->arch.suppress_spurious_page_faults = 1;
-            rcu_unlock_domain(d);
-            ret = 0;
-        }
+        d->arch.suppress_spurious_page_faults = 1;
+        ret = 0;
     }
     break;
 
     case XEN_DOMCTL_debug_op:
     {
-        struct domain *d;
         struct vcpu *v;
 
-        ret = -ESRCH;
-        d = rcu_lock_domain_by_id(domctl->domain);
-        if ( d == NULL )
-            break;
-
         ret = -EINVAL;
         if ( (domctl->u.debug_op.vcpu >= d->max_vcpus) ||
              ((v = d->vcpu[domctl->u.debug_op.vcpu]) == NULL) )
-            goto debug_op_out;
+            break;
 
         ret = -EINVAL;
         if ( !is_hvm_domain(d))
-            goto debug_op_out;
+            break;
 
         ret = hvm_debug_op(v, domctl->u.debug_op.op);
-
-    debug_op_out:
-        rcu_unlock_domain(d);
     }
     break;
 
     case XEN_DOMCTL_gdbsx_guestmemio:
     {
-        struct domain *d;
-
-        ret = -ESRCH;
-        if ( (d = rcu_lock_domain_by_id(domctl->domain)) == NULL )
-            break;
-
         domctl->u.gdbsx_guest_memio.remain =
             domctl->u.gdbsx_guest_memio.len;
 
         ret = gdbsx_guest_mem_io(domctl->domain, &domctl->u.gdbsx_guest_memio);
         if ( !ret && copy_to_guest(u_domctl, domctl, 1) )
             ret = -EFAULT;
-
-        rcu_unlock_domain(d);
     }
     break;
 
     case XEN_DOMCTL_gdbsx_pausevcpu:
     {
-        struct domain *d;
         struct vcpu *v;
 
-        ret = -ESRCH;
-        if ( (d = rcu_lock_domain_by_id(domctl->domain)) == NULL )
-            break;
-
         ret = -EBUSY;
         if ( !d->is_paused_by_controller )
-        {
-            rcu_unlock_domain(d);
             break;
-        }
         ret = -EINVAL;
         if ( domctl->u.gdbsx_pauseunp_vcpu.vcpu >= MAX_VIRT_CPUS ||
              (v = d->vcpu[domctl->u.gdbsx_pauseunp_vcpu.vcpu]) == NULL )
-        {
-            rcu_unlock_domain(d);
             break;
-        }
         vcpu_pause(v);
         ret = 0;
-        rcu_unlock_domain(d);
     }
     break;
 
     case XEN_DOMCTL_gdbsx_unpausevcpu:
     {
-        struct domain *d;
         struct vcpu *v;
 
-        ret = -ESRCH;
-        if ( (d = rcu_lock_domain_by_id(domctl->domain)) == NULL )
-            break;
-
         ret = -EBUSY;
         if ( !d->is_paused_by_controller )
-        {
-            rcu_unlock_domain(d);
             break;
-        }
         ret = -EINVAL;
         if ( domctl->u.gdbsx_pauseunp_vcpu.vcpu >= MAX_VIRT_CPUS ||
              (v = d->vcpu[domctl->u.gdbsx_pauseunp_vcpu.vcpu]) == NULL )
-        {
-            rcu_unlock_domain(d);
             break;
-        }
         if ( !atomic_read(&v->pause_count) )
             printk("WARN: Unpausing vcpu:%d which is not paused\n", v->vcpu_id);
         vcpu_unpause(v);
         ret = 0;
-        rcu_unlock_domain(d);
     }
     break;
 
     case XEN_DOMCTL_gdbsx_domstatus:
     {
-        struct domain *d;
         struct vcpu *v;
 
-        ret = -ESRCH;
-        if ( (d = rcu_lock_domain_by_id(domctl->domain)) == NULL )
-            break;
-
         domctl->u.gdbsx_domstatus.vcpu_id = -1;
         domctl->u.gdbsx_domstatus.paused = d->is_paused_by_controller;
         if ( domctl->u.gdbsx_domstatus.paused )
@@ -1309,7 +1042,6 @@ long arch_do_domctl(
         ret = 0;
         if ( copy_to_guest(u_domctl, domctl, 1) )
             ret = -EFAULT;
-        rcu_unlock_domain(d);
     }
     break;
 
@@ -1317,7 +1049,6 @@ long arch_do_domctl(
     case XEN_DOMCTL_getvcpuextstate:
     {
         struct xen_domctl_vcpuextstate *evc;
-        struct domain *d;
         struct vcpu *v;
         uint32_t offset = 0;
         uint64_t _xfeature_mask = 0;
@@ -1328,12 +1059,6 @@ long arch_do_domctl(
 
         evc = &domctl->u.vcpuextstate;
 
-        ret = -ESRCH;
-
-        d = rcu_lock_domain_by_id(domctl->domain);
-        if ( d == NULL )
-            break;
-
         ret = xsm_vcpuextstate(d, domctl->cmd);
         if ( ret )
             goto vcpuextstate_out;
@@ -1432,7 +1157,6 @@ long arch_do_domctl(
         ret = 0;
 
     vcpuextstate_out:
-        rcu_unlock_domain(d);
         if ( (domctl->cmd == XEN_DOMCTL_getvcpuextstate) &&
              copy_to_guest(u_domctl, domctl, 1) )
             ret = -EFAULT;
@@ -1441,50 +1165,33 @@ long arch_do_domctl(
 
     case XEN_DOMCTL_mem_event_op:
     {
-        struct domain *d;
-
-        ret = -ESRCH;
-        d = rcu_lock_domain_by_id(domctl->domain);
-        if ( d != NULL )
-        {
-            ret = mem_event_domctl(d, &domctl->u.mem_event_op,
-                                   guest_handle_cast(u_domctl, void));
-            rcu_unlock_domain(d);
-            copy_to_guest(u_domctl, domctl, 1);
-        } 
+        ret = mem_event_domctl(d, &domctl->u.mem_event_op,
+                               guest_handle_cast(u_domctl, void));
+        copy_to_guest(u_domctl, domctl, 1);
     }
     break;
 
     case XEN_DOMCTL_mem_sharing_op:
     {
-        struct domain *d;
-
-        ret = -ESRCH;
-        d = rcu_lock_domain_by_id(domctl->domain);
-        if ( d != NULL )
-        {
-            ret = xsm_mem_sharing(d);
-            if ( !ret )
-                ret = mem_sharing_domctl(d, &domctl->u.mem_sharing_op);
-            rcu_unlock_domain(d);
-        } 
+        ret = xsm_mem_sharing(d);
+        if ( !ret )
+            ret = mem_sharing_domctl(d, &domctl->u.mem_sharing_op);
     }
     break;
 
 #if P2M_AUDIT
     case XEN_DOMCTL_audit_p2m:
     {
-        struct domain *d;
-
-        ret = rcu_lock_remote_domain_by_id(domctl->domain, &d);
-        if ( ret != 0 )
+        if ( d == current->domain )
+        {
+            ret = -EPERM;
             break;
+        }
 
         audit_p2m(d,
                   &domctl->u.audit_p2m.orphans,
                   &domctl->u.audit_p2m.m2p_bad,
                   &domctl->u.audit_p2m.p2m_bad);
-        rcu_unlock_domain(d);
         if ( copy_to_guest(u_domctl, domctl, 1) ) 
             ret = -EFAULT;
     }
@@ -1493,29 +1200,22 @@ long arch_do_domctl(
 
     case XEN_DOMCTL_set_access_required:
     {
-        struct domain *d;
         struct p2m_domain* p2m;
         
         ret = -EPERM;
-        if ( current->domain->domain_id == domctl->domain )
+        if ( current->domain == d )
             break;
 
-        ret = -ESRCH;
-        d = rcu_lock_domain_by_id(domctl->domain);
-        if ( d != NULL )
-        {
-            ret = xsm_mem_event_setup(d);
-            if ( !ret ) {
-                p2m = p2m_get_hostp2m(d);
-                p2m->access_required = domctl->u.access_required.access_required;
-            }
-            rcu_unlock_domain(d);
-        } 
+        ret = xsm_mem_event_setup(d);
+        if ( !ret ) {
+            p2m = p2m_get_hostp2m(d);
+            p2m->access_required = domctl->u.access_required.access_required;
+        }
     }
     break;
 
     default:
-        ret = iommu_do_domctl(domctl, u_domctl);
+        ret = iommu_do_domctl(domctl, d, u_domctl);
         break;
     }
 
diff --git a/xen/common/domctl.c b/xen/common/domctl.c
index 76f0f90..07c95a3 100644
--- a/xen/common/domctl.c
+++ b/xen/common/domctl.c
@@ -861,7 +861,7 @@ long do_domctl(XEN_GUEST_HANDLE(xen_domctl_t) u_domctl)
     break;
 
     default:
-        ret = arch_do_domctl(op, u_domctl);
+        ret = arch_do_domctl(op, d, u_domctl);
         break;
     }
 
diff --git a/xen/drivers/passthrough/iommu.c b/xen/drivers/passthrough/iommu.c
index b4cf16c..b3c66f8 100644
--- a/xen/drivers/passthrough/iommu.c
+++ b/xen/drivers/passthrough/iommu.c
@@ -526,10 +526,9 @@ void iommu_crash_shutdown(void)
 }
 
 int iommu_do_domctl(
-    struct xen_domctl *domctl,
+    struct xen_domctl *domctl, struct domain *d,
     XEN_GUEST_HANDLE(xen_domctl_t) u_domctl)
 {
-    struct domain *d;
     u16 seg;
     u8 bus, devfn;
     int ret = 0;
@@ -548,10 +547,6 @@ int iommu_do_domctl(
         if ( ret )
             break;
 
-        ret = -EINVAL;
-        if ( (d = rcu_lock_domain_by_id(domctl->domain)) == NULL )
-            break;
-
         seg = domctl->u.get_device_group.machine_sbdf >> 16;
         bus = (domctl->u.get_device_group.machine_sbdf >> 8) & 0xff;
         devfn = domctl->u.get_device_group.machine_sbdf & 0xff;
@@ -572,7 +567,6 @@ int iommu_do_domctl(
         }
         if ( copy_to_guest(u_domctl, domctl, 1) )
             ret = -EFAULT;
-        rcu_unlock_domain(d);
     }
     break;
 
@@ -595,20 +589,15 @@ int iommu_do_domctl(
         break;
 
     case XEN_DOMCTL_assign_device:
-        if ( unlikely((d = get_domain_by_id(domctl->domain)) == NULL) ||
-             unlikely(d->is_dying) )
+        if ( unlikely(d->is_dying) )
         {
-            printk(XENLOG_G_ERR
-                   "XEN_DOMCTL_assign_device: get_domain_by_id() failed\n");
             ret = -EINVAL;
-            if ( d )
-                goto assign_device_out;
             break;
         }
 
         ret = xsm_assign_device(d, domctl->u.assign_device.machine_sbdf);
         if ( ret )
-            goto assign_device_out;
+            break;
 
         seg = domctl->u.get_device_group.machine_sbdf >> 16;
         bus = (domctl->u.assign_device.machine_sbdf >> 8) & 0xff;
@@ -622,22 +611,12 @@ int iommu_do_domctl(
                    seg, bus, PCI_SLOT(devfn), PCI_FUNC(devfn),
                    d->domain_id, ret);
 
-    assign_device_out:
-        put_domain(d);
         break;
 
     case XEN_DOMCTL_deassign_device:
-        if ( unlikely((d = get_domain_by_id(domctl->domain)) == NULL) )
-        {
-            printk(XENLOG_G_ERR
-                   "XEN_DOMCTL_deassign_device: get_domain_by_id() failed\n");
-            ret = -EINVAL;
-            break;
-        }
-
         ret = xsm_deassign_device(d, domctl->u.assign_device.machine_sbdf);
         if ( ret )
-            goto deassign_device_out;
+            break;
 
         seg = domctl->u.get_device_group.machine_sbdf >> 16;
         bus = (domctl->u.assign_device.machine_sbdf >> 8) & 0xff;
@@ -652,8 +631,6 @@ int iommu_do_domctl(
                    seg, bus, PCI_SLOT(devfn), PCI_FUNC(devfn),
                    d->domain_id, ret);
 
-    deassign_device_out:
-        put_domain(d);
         break;
 
     default:
diff --git a/xen/include/xen/hypercall.h b/xen/include/xen/hypercall.h
index 1b71071..36796d2 100644
--- a/xen/include/xen/hypercall.h
+++ b/xen/include/xen/hypercall.h
@@ -37,7 +37,7 @@ do_domctl(
 
 extern long
 arch_do_domctl(
-    struct xen_domctl *domctl,
+    struct xen_domctl *domctl, struct domain *d,
     XEN_GUEST_HANDLE(xen_domctl_t) u_domctl);
 
 extern long
diff --git a/xen/include/xen/iommu.h b/xen/include/xen/iommu.h
index 605c7b3..c2951a5 100644
--- a/xen/include/xen/iommu.h
+++ b/xen/include/xen/iommu.h
@@ -156,7 +156,8 @@ void iommu_crash_shutdown(void);
 void iommu_set_dom0_mapping(struct domain *d);
 void iommu_share_p2m_table(struct domain *d);
 
-int iommu_do_domctl(struct xen_domctl *, XEN_GUEST_HANDLE(xen_domctl_t));
+int iommu_do_domctl(struct xen_domctl *, struct domain *d,
+                    XEN_GUEST_HANDLE(xen_domctl_t));
 
 void iommu_iotlb_flush(struct domain *d, unsigned long gfn, unsigned int page_count);
 void iommu_iotlb_flush_all(struct domain *d);
-- 
1.7.11.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 17 15:24:27 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 15:24:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDdBG-0003hh-FF; Mon, 17 Sep 2012 15:24:14 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1TDdBD-0003do-LO
	for xen-devel@lists.xen.org; Mon, 17 Sep 2012 15:24:12 +0000
Received: from [85.158.139.211:51995] by server-11.bemta-5.messagelabs.com id
	5C/80-24658-A9047505; Mon, 17 Sep 2012 15:24:10 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-2.tower-206.messagelabs.com!1347895448!18880337!1
X-Originating-IP: [63.239.67.9]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29810 invoked from network); 17 Sep 2012 15:24:08 -0000
Received: from emvm-gh1-uea08.nsa.gov (HELO nsa.gov) (63.239.67.9)
	by server-2.tower-206.messagelabs.com with SMTP;
	17 Sep 2012 15:24:08 -0000
X-TM-IMSS-Message-ID: <538046aa0012ace9@nsa.gov>
Received: from tarius.tycho.ncsc.mil ([144.51.3.1]) by nsa.gov ([63.239.67.9])
	with ESMTP (TREND IMSS SMTP Service 7.1) id 538046aa0012ace9 ;
	Mon, 17 Sep 2012 11:23:48 -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 q8HFO0xn027504; 
	Mon, 17 Sep 2012 11:24:06 -0400
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xen.org
Date: Mon, 17 Sep 2012 11:23:45 -0400
Message-Id: <1347895425-17959-24-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.11.4
In-Reply-To: <1347895425-17959-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1347895425-17959-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: keir@xen.org, Ian Campbell <ian.campbell@citrix.com>,
	Tim Deegan <tim@xen.org>,
	Stefano Stabellini <stefano.stabellini@citrix.com>,
	Jan Beulich <jbeulich@suse.com>, dgdegra@tycho.nsa.gov
Subject: [Xen-devel] [PATCH 23/23] xen/arch/*: add struct domain parameter
	to arch_do_domctl
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 arch-independent do_domctl function now RCU locks the domain
specified by op->domain, pass the struct domain to the arch-specific
domctl function and remove the duplicate per-subfunction locking.

This also removes two get_domain/put_domain call pairs (in
XEN_DOMCTL_assign_device and XEN_DOMCTL_deassign_device), replacing them
with RCU locking.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Cc: Ian Campbell <ian.campbell@citrix.com>
Cc: Stefano Stabellini <stefano.stabellini@citrix.com>
Cc: Tim Deegan <tim@xen.org>
Cc: Jan Beulich <jbeulich@suse.com>
---
 xen/arch/arm/domctl.c           |   2 +-
 xen/arch/x86/domctl.c           | 434 +++++++---------------------------------
 xen/common/domctl.c             |   2 +-
 xen/drivers/passthrough/iommu.c |  31 +--
 xen/include/xen/hypercall.h     |   2 +-
 xen/include/xen/iommu.h         |   3 +-
 6 files changed, 76 insertions(+), 398 deletions(-)

diff --git a/xen/arch/arm/domctl.c b/xen/arch/arm/domctl.c
index 1a5f79f..12531d1 100644
--- a/xen/arch/arm/domctl.c
+++ b/xen/arch/arm/domctl.c
@@ -10,7 +10,7 @@
 #include <xen/errno.h>
 #include <public/domctl.h>
 
-long arch_do_domctl(struct xen_domctl *domctl,
+long arch_do_domctl(struct xen_domctl *domctl, struct domain *d,
                     XEN_GUEST_HANDLE(xen_domctl_t) u_domctl)
 {
     return -ENOSYS;
diff --git a/xen/arch/x86/domctl.c b/xen/arch/x86/domctl.c
index 7062f02..734b2f2 100644
--- a/xen/arch/x86/domctl.c
+++ b/xen/arch/x86/domctl.c
@@ -47,7 +47,7 @@ static int gdbsx_guest_mem_io(
 }
 
 long arch_do_domctl(
-    struct xen_domctl *domctl,
+    struct xen_domctl *domctl, struct domain *d,
     XEN_GUEST_HANDLE(xen_domctl_t) u_domctl)
 {
     long ret = 0;
@@ -57,23 +57,15 @@ long arch_do_domctl(
 
     case XEN_DOMCTL_shadow_op:
     {
-        struct domain *d;
-        ret = -ESRCH;
-        d = rcu_lock_domain_by_id(domctl->domain);
-        if ( d != NULL )
-        {
-            ret = paging_domctl(d,
-                                &domctl->u.shadow_op,
-                                guest_handle_cast(u_domctl, void));
-            rcu_unlock_domain(d);
-            copy_to_guest(u_domctl, domctl, 1);
-        } 
+        ret = paging_domctl(d,
+                            &domctl->u.shadow_op,
+                            guest_handle_cast(u_domctl, void));
+        copy_to_guest(u_domctl, domctl, 1);
     }
     break;
 
     case XEN_DOMCTL_ioport_permission:
     {
-        struct domain *d;
         unsigned int fp = domctl->u.ioport_permission.first_port;
         unsigned int np = domctl->u.ioport_permission.nr_ports;
         int allow = domctl->u.ioport_permission.allow_access;
@@ -82,10 +74,6 @@ long arch_do_domctl(
         if ( (fp + np) > 65536 )
             break;
 
-        ret = -ESRCH;
-        if ( unlikely((d = rcu_lock_domain_by_id(domctl->domain)) == NULL) )
-            break;
-
         if ( np == 0 )
             ret = 0;
         else if ( xsm_ioport_permission(d, fp, fp + np - 1, allow) )
@@ -94,8 +82,6 @@ long arch_do_domctl(
             ret = ioports_permit_access(d, fp, fp + np - 1);
         else
             ret = ioports_deny_access(d, fp, fp + np - 1);
-
-        rcu_unlock_domain(d);
     }
     break;
 
@@ -103,23 +89,16 @@ long arch_do_domctl(
     {
         struct page_info *page;
         unsigned long mfn = domctl->u.getpageframeinfo.gmfn;
-        domid_t dom = domctl->domain;
-        struct domain *d;
 
         ret = -EINVAL;
-
-        if ( unlikely(!mfn_valid(mfn)) ||
-             unlikely((d = rcu_lock_domain_by_id(dom)) == NULL) )
+        if ( unlikely(!mfn_valid(mfn)) )
             break;
 
         page = mfn_to_page(mfn);
 
         ret = xsm_getpageframeinfo(d);
         if ( ret )
-        {
-            rcu_unlock_domain(d);
             break;
-        }
 
         if ( likely(get_page(page, d)) )
         {
@@ -149,8 +128,6 @@ long arch_do_domctl(
             put_page(page);
         }
 
-        rcu_unlock_domain(d);
-
         copy_to_guest(u_domctl, domctl, 1);
     }
     break;
@@ -160,27 +137,17 @@ long arch_do_domctl(
         {
             unsigned int n, j;
             unsigned int num = domctl->u.getpageframeinfo3.num;
-            domid_t dom = domctl->domain;
-            struct domain *d;
             struct page_info *page;
             xen_pfn_t *arr;
 
-            ret = -ESRCH;
-            if ( unlikely((d = rcu_lock_domain_by_id(dom)) == NULL) )
-                break;
-
             ret = xsm_getpageframeinfo(d);
             if ( ret )
-            {
-                rcu_unlock_domain(d);
                 break;
-            }
 
             if ( unlikely(num > 1024) ||
                  unlikely(num != domctl->u.getpageframeinfo3.num) )
             {
                 ret = -E2BIG;
-                rcu_unlock_domain(d);
                 break;
             }
 
@@ -188,7 +155,6 @@ long arch_do_domctl(
             if ( !page )
             {
                 ret = -ENOMEM;
-                rcu_unlock_domain(d);
                 break;
             }
             arr = page_to_virt(page);
@@ -254,7 +220,6 @@ long arch_do_domctl(
 
             free_domheap_page(virt_to_page(arr));
 
-            rcu_unlock_domain(d);
             break;
         }
         /* fall thru */
@@ -262,25 +227,15 @@ long arch_do_domctl(
     {
         int n,j;
         int num = domctl->u.getpageframeinfo2.num;
-        domid_t dom = domctl->domain;
-        struct domain *d;
         uint32_t *arr32;
-        ret = -ESRCH;
-
-        if ( unlikely((d = rcu_lock_domain_by_id(dom)) == NULL) )
-            break;
 
         ret = xsm_getpageframeinfo(d);
         if ( ret )
-        {
-            rcu_unlock_domain(d);
             break;
-        }
 
         if ( unlikely(num > 1024) )
         {
             ret = -E2BIG;
-            rcu_unlock_domain(d);
             break;
         }
 
@@ -288,7 +243,6 @@ long arch_do_domctl(
         if ( !arr32 )
         {
             ret = -ENOMEM;
-            rcu_unlock_domain(d);
             break;
         }
  
@@ -360,78 +314,58 @@ long arch_do_domctl(
         }
 
         free_xenheap_page(arr32);
-
-        rcu_unlock_domain(d);
     }
     break;
 
     case XEN_DOMCTL_getmemlist:
     {
         int i;
-        struct domain *d = rcu_lock_domain_by_id(domctl->domain);
         unsigned long max_pfns = domctl->u.getmemlist.max_pfns;
         uint64_t mfn;
         struct page_info *page;
 
-        ret = -EINVAL;
-        if ( d != NULL )
-        {
-            ret = xsm_getmemlist(d);
-            if ( ret )
-            {
-                rcu_unlock_domain(d);
-                break;
-            }
+        ret = xsm_getmemlist(d);
+        if ( ret )
+            break;
 
-            spin_lock(&d->page_alloc_lock);
+        if ( unlikely(d->is_dying) ) {
+            ret = -EINVAL;
+            break;
+        }
 
-            if ( unlikely(d->is_dying) ) {
-                spin_unlock(&d->page_alloc_lock);
-                goto getmemlist_out;
-            }
+        spin_lock(&d->page_alloc_lock);
 
-            ret = i = 0;
-            page_list_for_each(page, &d->page_list)
+        ret = i = 0;
+        page_list_for_each(page, &d->page_list)
+        {
+            if ( i >= max_pfns )
+                break;
+            mfn = page_to_mfn(page);
+            if ( copy_to_guest_offset(domctl->u.getmemlist.buffer,
+                                      i, &mfn, 1) )
             {
-                if ( i >= max_pfns )
-                    break;
-                mfn = page_to_mfn(page);
-                if ( copy_to_guest_offset(domctl->u.getmemlist.buffer,
-                                          i, &mfn, 1) )
-                {
-                    ret = -EFAULT;
-                    break;
-                }
-                ++i;
+                ret = -EFAULT;
+                break;
             }
-            
-            spin_unlock(&d->page_alloc_lock);
-
-            domctl->u.getmemlist.num_pfns = i;
-            copy_to_guest(u_domctl, domctl, 1);
-        getmemlist_out:
-            rcu_unlock_domain(d);
+            ++i;
         }
+        
+        spin_unlock(&d->page_alloc_lock);
+
+        domctl->u.getmemlist.num_pfns = i;
+        copy_to_guest(u_domctl, domctl, 1);
     }
     break;
 
     case XEN_DOMCTL_hypercall_init:
     {
-        struct domain *d = rcu_lock_domain_by_id(domctl->domain);
         unsigned long gmfn = domctl->u.hypercall_init.gmfn;
         struct page_info *page;
         void *hypercall_page;
 
-        ret = -ESRCH;
-        if ( unlikely(d == NULL) )
-            break;
-
         ret = xsm_hypercall_init(d);
         if ( ret )
-        {
-            rcu_unlock_domain(d);
             break;
-        }
 
         page = get_page_from_gfn(d, gmfn, NULL, P2M_ALLOC);
 
@@ -440,7 +374,6 @@ long arch_do_domctl(
         {
             if ( page )
                 put_page(page);
-            rcu_unlock_domain(d);
             break;
         }
 
@@ -451,19 +384,12 @@ long arch_do_domctl(
         unmap_domain_page(hypercall_page);
 
         put_page_and_type(page);
-
-        rcu_unlock_domain(d);
     }
     break;
 
     case XEN_DOMCTL_sethvmcontext:
     { 
         struct hvm_domain_context c = { .size = domctl->u.hvmcontext.size };
-        struct domain *d;
-
-        ret = -ESRCH;
-        if ( (d = rcu_lock_domain_by_id(domctl->domain)) == NULL )
-            break;
 
         ret = xsm_hvmcontext(d, domctl->cmd);
         if ( ret )
@@ -488,19 +414,12 @@ long arch_do_domctl(
     sethvmcontext_out:
         if ( c.data != NULL )
             xfree(c.data);
-
-        rcu_unlock_domain(d);
     }
     break;
 
     case XEN_DOMCTL_gethvmcontext:
     { 
         struct hvm_domain_context c = { 0 };
-        struct domain *d;
-
-        ret = -ESRCH;
-        if ( (d = rcu_lock_domain_by_id(domctl->domain)) == NULL )
-            break;
 
         ret = xsm_hvmcontext(d, domctl->cmd);
         if ( ret )
@@ -544,53 +463,33 @@ long arch_do_domctl(
 
         if ( c.data != NULL )
             xfree(c.data);
-
-        rcu_unlock_domain(d);
     }
     break;
 
     case XEN_DOMCTL_gethvmcontext_partial:
     { 
-        struct domain *d;
-
-        ret = -ESRCH;
-        if ( (d = rcu_lock_domain_by_id(domctl->domain)) == NULL )
-            break;
-
         ret = xsm_hvmcontext(d, domctl->cmd);
         if ( ret )
-            goto gethvmcontext_partial_out;
+            break;
 
         ret = -EINVAL;
         if ( !is_hvm_domain(d) ) 
-            goto gethvmcontext_partial_out;
+            break;
 
         domain_pause(d);
         ret = hvm_save_one(d, domctl->u.hvmcontext_partial.type,
                            domctl->u.hvmcontext_partial.instance,
                            domctl->u.hvmcontext_partial.buffer);
         domain_unpause(d);
-
-    gethvmcontext_partial_out:
-        rcu_unlock_domain(d);
     }
     break;
 
 
     case XEN_DOMCTL_set_address_size:
     {
-        struct domain *d;
-
-        ret = -ESRCH;
-        if ( (d = rcu_lock_domain_by_id(domctl->domain)) == NULL )
-            break;
-
         ret = xsm_address_size(d, domctl->cmd);
         if ( ret )
-        {
-            rcu_unlock_domain(d);
             break;
-        }
 
         switch ( domctl->u.address_size.size )
         {
@@ -604,31 +503,19 @@ long arch_do_domctl(
             ret = (domctl->u.address_size.size == BITS_PER_LONG) ? 0 : -EINVAL;
             break;
         }
-
-        rcu_unlock_domain(d);
     }
     break;
 
     case XEN_DOMCTL_get_address_size:
     {
-        struct domain *d;
-
-        ret = -ESRCH;
-        if ( (d = rcu_lock_domain_by_id(domctl->domain)) == NULL )
-            break;
-
         ret = xsm_address_size(d, domctl->cmd);
         if ( ret )
-        {
-            rcu_unlock_domain(d);
             break;
-        }
 
         domctl->u.address_size.size =
             is_pv_32on64_domain(d) ? 32 : BITS_PER_LONG;
 
         ret = 0;
-        rcu_unlock_domain(d);
 
         if ( copy_to_guest(u_domctl, domctl, 1) )
             ret = -EFAULT;
@@ -637,76 +524,51 @@ long arch_do_domctl(
 
     case XEN_DOMCTL_set_machine_address_size:
     {
-        struct domain *d;
-
-        ret = -ESRCH;
-        if ( (d = rcu_lock_domain_by_id(domctl->domain)) == NULL )
-            break;
-
         ret = xsm_machine_address_size(d, domctl->cmd);
         if ( ret )
-            goto set_machine_address_size_out;
+            break;
 
         ret = -EBUSY;
         if ( d->tot_pages > 0 )
-            goto set_machine_address_size_out;
+            break;
 
         d->arch.physaddr_bitsize = domctl->u.address_size.size;
 
         ret = 0;
-    set_machine_address_size_out:
-        rcu_unlock_domain(d);
     }
     break;
 
     case XEN_DOMCTL_get_machine_address_size:
     {
-        struct domain *d;
-
-        ret = -ESRCH;
-        if ( (d = rcu_lock_domain_by_id(domctl->domain)) == NULL )
-            break;
-
         ret = xsm_machine_address_size(d, domctl->cmd);
         if ( ret )
-        {
-            rcu_unlock_domain(d);
             break;
-        }
 
         domctl->u.address_size.size = d->arch.physaddr_bitsize;
 
         ret = 0;
-        rcu_unlock_domain(d);
 
         if ( copy_to_guest(u_domctl, domctl, 1) )
             ret = -EFAULT;
-
-
     }
     break;
 
     case XEN_DOMCTL_sendtrigger:
     {
-        struct domain *d;
         struct vcpu *v;
 
-        ret = -ESRCH;
-        if ( (d = rcu_lock_domain_by_id(domctl->domain)) == NULL )
-            break;
-
         ret = xsm_sendtrigger(d);
         if ( ret )
-            goto sendtrigger_out;
+            break;
 
         ret = -EINVAL;
         if ( domctl->u.sendtrigger.vcpu >= MAX_VIRT_CPUS )
-            goto sendtrigger_out;
+            break;
 
         ret = -ESRCH;
         if ( domctl->u.sendtrigger.vcpu >= d->max_vcpus ||
              (v = d->vcpu[domctl->u.sendtrigger.vcpu]) == NULL )
-            goto sendtrigger_out;
+            break;
 
         switch ( domctl->u.sendtrigger.trigger )
         {
@@ -743,34 +605,27 @@ long arch_do_domctl(
         default:
             ret = -ENOSYS;
         }
-
-    sendtrigger_out:
-        rcu_unlock_domain(d);
     }
     break;
 
     case XEN_DOMCTL_bind_pt_irq:
     {
-        struct domain * d;
         xen_domctl_bind_pt_irq_t * bind;
 
-        ret = -ESRCH;
-        if ( (d = rcu_lock_domain_by_id(domctl->domain)) == NULL )
-            break;
         bind = &(domctl->u.bind_pt_irq);
 
         ret = -EINVAL;
         if ( !is_hvm_domain(d) )
-            goto bind_out;
+            break;
 
         ret = xsm_bind_pt_irq(d, bind);
         if ( ret )
-            goto bind_out;
+            break;
 
         ret = -EPERM;
         if ( !IS_PRIV(current->domain) &&
              !irq_access_permitted(current->domain, bind->machine_irq) )
-            goto bind_out;
+            break;
 
         ret = -ESRCH;
         if ( iommu_enabled )
@@ -782,30 +637,23 @@ long arch_do_domctl(
         if ( ret < 0 )
             printk(XENLOG_G_ERR "pt_irq_create_bind failed (%ld) for dom%d\n",
                    ret, d->domain_id);
-
-    bind_out:
-        rcu_unlock_domain(d);
     }
     break;    
 
     case XEN_DOMCTL_unbind_pt_irq:
     {
-        struct domain * d;
         xen_domctl_bind_pt_irq_t * bind;
 
-        ret = -ESRCH;
-        if ( (d = rcu_lock_domain_by_id(domctl->domain)) == NULL )
-            break;
         bind = &(domctl->u.bind_pt_irq);
 
         ret = -EPERM;
         if ( !IS_PRIV(current->domain) &&
              !irq_access_permitted(current->domain, bind->machine_irq) )
-            goto unbind_out;
+            break;
 
         ret = xsm_unbind_pt_irq(d, bind);
         if ( ret )
-            goto unbind_out;
+            break;
 
         if ( iommu_enabled )
         {
@@ -816,15 +664,11 @@ long arch_do_domctl(
         if ( ret < 0 )
             printk(XENLOG_G_ERR "pt_irq_destroy_bind failed (%ld) for dom%d\n",
                    ret, d->domain_id);
-
-    unbind_out:
-        rcu_unlock_domain(d);
     }
     break;
 
     case XEN_DOMCTL_memory_mapping:
     {
-        struct domain *d;
         unsigned long gfn = domctl->u.memory_mapping.first_gfn;
         unsigned long mfn = domctl->u.memory_mapping.first_mfn;
         unsigned long nr_mfns = domctl->u.memory_mapping.nr_mfns;
@@ -840,15 +684,9 @@ long arch_do_domctl(
              !iomem_access_permitted(current->domain, mfn, mfn + nr_mfns - 1) )
             break;
 
-        ret = -ESRCH;
-        if ( unlikely((d = rcu_lock_domain_by_id(domctl->domain)) == NULL) )
-            break;
-
         ret = xsm_iomem_mapping(d, mfn, mfn + nr_mfns - 1, add);
-        if ( ret ) {
-            rcu_unlock_domain(d);
+        if ( ret )
             break;
-        }
 
         if ( add )
         {
@@ -870,15 +708,12 @@ long arch_do_domctl(
                 clear_mmio_p2m_entry(d, gfn+i);
             ret = iomem_deny_access(d, mfn, mfn + nr_mfns - 1);
         }
-
-        rcu_unlock_domain(d);
     }
     break;
 
     case XEN_DOMCTL_ioport_mapping:
     {
 #define MAX_IOPORTS    0x10000
-        struct domain *d;
         struct hvm_iommu *hd;
         unsigned int fgp = domctl->u.ioport_mapping.first_gport;
         unsigned int fmp = domctl->u.ioport_mapping.first_mport;
@@ -902,15 +737,9 @@ long arch_do_domctl(
              !ioports_access_permitted(current->domain, fmp, fmp + np - 1) )
             break;
 
-        ret = -ESRCH;
-        if ( unlikely((d = rcu_lock_domain_by_id(domctl->domain)) == NULL) )
-            break;
-
         ret = xsm_ioport_mapping(d, fmp, fmp + np - 1, add);
-        if ( ret ) {
-            rcu_unlock_domain(d);
+        if ( ret )
             break;
-        }
 
         hd = domain_hvm_iommu(d);
         if ( add )
@@ -951,30 +780,19 @@ long arch_do_domctl(
                 }
             ret = ioports_deny_access(d, fmp, fmp + np - 1);
         }
-        rcu_unlock_domain(d);
     }
     break;
 
     case XEN_DOMCTL_pin_mem_cacheattr:
     {
-        struct domain *d;
-
-        ret = -ESRCH;
-        d = rcu_lock_domain_by_id(domctl->domain);
-        if ( d == NULL )
-            break;
-
         ret = xsm_pin_mem_cacheattr(d);
         if ( ret )
-            goto pin_out;
+            break;
 
         ret = hvm_set_mem_pinned_cacheattr(
             d, domctl->u.pin_mem_cacheattr.start,
             domctl->u.pin_mem_cacheattr.end,
             domctl->u.pin_mem_cacheattr.type);
-
-    pin_out:
-        rcu_unlock_domain(d);
     }
     break;
 
@@ -982,19 +800,13 @@ long arch_do_domctl(
     case XEN_DOMCTL_get_ext_vcpucontext:
     {
         struct xen_domctl_ext_vcpucontext *evc;
-        struct domain *d;
         struct vcpu *v;
 
         evc = &domctl->u.ext_vcpucontext;
 
-        ret = -ESRCH;
-        d = rcu_lock_domain_by_id(domctl->domain);
-        if ( d == NULL )
-            break;
-
         ret = xsm_ext_vcpucontext(d, domctl->cmd);
         if ( ret )
-            goto ext_vcpucontext_out;
+            break;
 
         ret = -ESRCH;
         if ( (evc->vcpu >= d->max_vcpus) ||
@@ -1071,7 +883,6 @@ long arch_do_domctl(
         ret = 0;
 
     ext_vcpucontext_out:
-        rcu_unlock_domain(d);
         if ( (domctl->cmd == XEN_DOMCTL_get_ext_vcpucontext) &&
              copy_to_guest(u_domctl, domctl, 1) )
             ret = -EFAULT;
@@ -1080,16 +891,10 @@ long arch_do_domctl(
 
     case XEN_DOMCTL_set_cpuid:
     {
-        struct domain *d;
         xen_domctl_cpuid_t *ctl = &domctl->u.cpuid;
         cpuid_input_t *cpuid = NULL; 
         int i;
 
-        ret = -ESRCH;
-        d = rcu_lock_domain_by_id(domctl->domain);
-        if ( d == NULL )
-            break;
-
         for ( i = 0; i < MAX_CPUID_INPUT; i++ )
         {
             cpuid = &d->arch.cpuids[i];
@@ -1112,21 +917,13 @@ long arch_do_domctl(
             memcpy(cpuid, ctl, sizeof(cpuid_input_t));
             ret = 0;
         }
-
-        rcu_unlock_domain(d);
     }
     break;
 
     case XEN_DOMCTL_gettscinfo:
     {
-        struct domain *d;
         xen_guest_tsc_info_t info;
 
-        ret = -ESRCH;
-        d = rcu_lock_domain_by_id(domctl->domain);
-        if ( d == NULL )
-            break;
-
         domain_pause(d);
         tsc_get_info(d, &info.tsc_mode,
                         &info.elapsed_nsec,
@@ -1137,20 +934,11 @@ long arch_do_domctl(
         else
             ret = 0;
         domain_unpause(d);
-
-        rcu_unlock_domain(d);
     }
     break;
 
     case XEN_DOMCTL_settscinfo:
     {
-        struct domain *d;
-
-        ret = -ESRCH;
-        d = rcu_lock_domain_by_id(domctl->domain);
-        if ( d == NULL )
-            break;
-
         domain_pause(d);
         tsc_set_info(d, domctl->u.tsc_info.info.tsc_mode,
                      domctl->u.tsc_info.info.elapsed_nsec,
@@ -1158,138 +946,83 @@ long arch_do_domctl(
                      domctl->u.tsc_info.info.incarnation);
         domain_unpause(d);
 
-        rcu_unlock_domain(d);
         ret = 0;
     }
     break;
 
     case XEN_DOMCTL_suppress_spurious_page_faults:
     {
-        struct domain *d;
-
-        ret = -ESRCH;
-        d = rcu_lock_domain_by_id(domctl->domain);
-        if ( d != NULL )
-        {
-            d->arch.suppress_spurious_page_faults = 1;
-            rcu_unlock_domain(d);
-            ret = 0;
-        }
+        d->arch.suppress_spurious_page_faults = 1;
+        ret = 0;
     }
     break;
 
     case XEN_DOMCTL_debug_op:
     {
-        struct domain *d;
         struct vcpu *v;
 
-        ret = -ESRCH;
-        d = rcu_lock_domain_by_id(domctl->domain);
-        if ( d == NULL )
-            break;
-
         ret = -EINVAL;
         if ( (domctl->u.debug_op.vcpu >= d->max_vcpus) ||
              ((v = d->vcpu[domctl->u.debug_op.vcpu]) == NULL) )
-            goto debug_op_out;
+            break;
 
         ret = -EINVAL;
         if ( !is_hvm_domain(d))
-            goto debug_op_out;
+            break;
 
         ret = hvm_debug_op(v, domctl->u.debug_op.op);
-
-    debug_op_out:
-        rcu_unlock_domain(d);
     }
     break;
 
     case XEN_DOMCTL_gdbsx_guestmemio:
     {
-        struct domain *d;
-
-        ret = -ESRCH;
-        if ( (d = rcu_lock_domain_by_id(domctl->domain)) == NULL )
-            break;
-
         domctl->u.gdbsx_guest_memio.remain =
             domctl->u.gdbsx_guest_memio.len;
 
         ret = gdbsx_guest_mem_io(domctl->domain, &domctl->u.gdbsx_guest_memio);
         if ( !ret && copy_to_guest(u_domctl, domctl, 1) )
             ret = -EFAULT;
-
-        rcu_unlock_domain(d);
     }
     break;
 
     case XEN_DOMCTL_gdbsx_pausevcpu:
     {
-        struct domain *d;
         struct vcpu *v;
 
-        ret = -ESRCH;
-        if ( (d = rcu_lock_domain_by_id(domctl->domain)) == NULL )
-            break;
-
         ret = -EBUSY;
         if ( !d->is_paused_by_controller )
-        {
-            rcu_unlock_domain(d);
             break;
-        }
         ret = -EINVAL;
         if ( domctl->u.gdbsx_pauseunp_vcpu.vcpu >= MAX_VIRT_CPUS ||
              (v = d->vcpu[domctl->u.gdbsx_pauseunp_vcpu.vcpu]) == NULL )
-        {
-            rcu_unlock_domain(d);
             break;
-        }
         vcpu_pause(v);
         ret = 0;
-        rcu_unlock_domain(d);
     }
     break;
 
     case XEN_DOMCTL_gdbsx_unpausevcpu:
     {
-        struct domain *d;
         struct vcpu *v;
 
-        ret = -ESRCH;
-        if ( (d = rcu_lock_domain_by_id(domctl->domain)) == NULL )
-            break;
-
         ret = -EBUSY;
         if ( !d->is_paused_by_controller )
-        {
-            rcu_unlock_domain(d);
             break;
-        }
         ret = -EINVAL;
         if ( domctl->u.gdbsx_pauseunp_vcpu.vcpu >= MAX_VIRT_CPUS ||
              (v = d->vcpu[domctl->u.gdbsx_pauseunp_vcpu.vcpu]) == NULL )
-        {
-            rcu_unlock_domain(d);
             break;
-        }
         if ( !atomic_read(&v->pause_count) )
             printk("WARN: Unpausing vcpu:%d which is not paused\n", v->vcpu_id);
         vcpu_unpause(v);
         ret = 0;
-        rcu_unlock_domain(d);
     }
     break;
 
     case XEN_DOMCTL_gdbsx_domstatus:
     {
-        struct domain *d;
         struct vcpu *v;
 
-        ret = -ESRCH;
-        if ( (d = rcu_lock_domain_by_id(domctl->domain)) == NULL )
-            break;
-
         domctl->u.gdbsx_domstatus.vcpu_id = -1;
         domctl->u.gdbsx_domstatus.paused = d->is_paused_by_controller;
         if ( domctl->u.gdbsx_domstatus.paused )
@@ -1309,7 +1042,6 @@ long arch_do_domctl(
         ret = 0;
         if ( copy_to_guest(u_domctl, domctl, 1) )
             ret = -EFAULT;
-        rcu_unlock_domain(d);
     }
     break;
 
@@ -1317,7 +1049,6 @@ long arch_do_domctl(
     case XEN_DOMCTL_getvcpuextstate:
     {
         struct xen_domctl_vcpuextstate *evc;
-        struct domain *d;
         struct vcpu *v;
         uint32_t offset = 0;
         uint64_t _xfeature_mask = 0;
@@ -1328,12 +1059,6 @@ long arch_do_domctl(
 
         evc = &domctl->u.vcpuextstate;
 
-        ret = -ESRCH;
-
-        d = rcu_lock_domain_by_id(domctl->domain);
-        if ( d == NULL )
-            break;
-
         ret = xsm_vcpuextstate(d, domctl->cmd);
         if ( ret )
             goto vcpuextstate_out;
@@ -1432,7 +1157,6 @@ long arch_do_domctl(
         ret = 0;
 
     vcpuextstate_out:
-        rcu_unlock_domain(d);
         if ( (domctl->cmd == XEN_DOMCTL_getvcpuextstate) &&
              copy_to_guest(u_domctl, domctl, 1) )
             ret = -EFAULT;
@@ -1441,50 +1165,33 @@ long arch_do_domctl(
 
     case XEN_DOMCTL_mem_event_op:
     {
-        struct domain *d;
-
-        ret = -ESRCH;
-        d = rcu_lock_domain_by_id(domctl->domain);
-        if ( d != NULL )
-        {
-            ret = mem_event_domctl(d, &domctl->u.mem_event_op,
-                                   guest_handle_cast(u_domctl, void));
-            rcu_unlock_domain(d);
-            copy_to_guest(u_domctl, domctl, 1);
-        } 
+        ret = mem_event_domctl(d, &domctl->u.mem_event_op,
+                               guest_handle_cast(u_domctl, void));
+        copy_to_guest(u_domctl, domctl, 1);
     }
     break;
 
     case XEN_DOMCTL_mem_sharing_op:
     {
-        struct domain *d;
-
-        ret = -ESRCH;
-        d = rcu_lock_domain_by_id(domctl->domain);
-        if ( d != NULL )
-        {
-            ret = xsm_mem_sharing(d);
-            if ( !ret )
-                ret = mem_sharing_domctl(d, &domctl->u.mem_sharing_op);
-            rcu_unlock_domain(d);
-        } 
+        ret = xsm_mem_sharing(d);
+        if ( !ret )
+            ret = mem_sharing_domctl(d, &domctl->u.mem_sharing_op);
     }
     break;
 
 #if P2M_AUDIT
     case XEN_DOMCTL_audit_p2m:
     {
-        struct domain *d;
-
-        ret = rcu_lock_remote_domain_by_id(domctl->domain, &d);
-        if ( ret != 0 )
+        if ( d == current->domain )
+        {
+            ret = -EPERM;
             break;
+        }
 
         audit_p2m(d,
                   &domctl->u.audit_p2m.orphans,
                   &domctl->u.audit_p2m.m2p_bad,
                   &domctl->u.audit_p2m.p2m_bad);
-        rcu_unlock_domain(d);
         if ( copy_to_guest(u_domctl, domctl, 1) ) 
             ret = -EFAULT;
     }
@@ -1493,29 +1200,22 @@ long arch_do_domctl(
 
     case XEN_DOMCTL_set_access_required:
     {
-        struct domain *d;
         struct p2m_domain* p2m;
         
         ret = -EPERM;
-        if ( current->domain->domain_id == domctl->domain )
+        if ( current->domain == d )
             break;
 
-        ret = -ESRCH;
-        d = rcu_lock_domain_by_id(domctl->domain);
-        if ( d != NULL )
-        {
-            ret = xsm_mem_event_setup(d);
-            if ( !ret ) {
-                p2m = p2m_get_hostp2m(d);
-                p2m->access_required = domctl->u.access_required.access_required;
-            }
-            rcu_unlock_domain(d);
-        } 
+        ret = xsm_mem_event_setup(d);
+        if ( !ret ) {
+            p2m = p2m_get_hostp2m(d);
+            p2m->access_required = domctl->u.access_required.access_required;
+        }
     }
     break;
 
     default:
-        ret = iommu_do_domctl(domctl, u_domctl);
+        ret = iommu_do_domctl(domctl, d, u_domctl);
         break;
     }
 
diff --git a/xen/common/domctl.c b/xen/common/domctl.c
index 76f0f90..07c95a3 100644
--- a/xen/common/domctl.c
+++ b/xen/common/domctl.c
@@ -861,7 +861,7 @@ long do_domctl(XEN_GUEST_HANDLE(xen_domctl_t) u_domctl)
     break;
 
     default:
-        ret = arch_do_domctl(op, u_domctl);
+        ret = arch_do_domctl(op, d, u_domctl);
         break;
     }
 
diff --git a/xen/drivers/passthrough/iommu.c b/xen/drivers/passthrough/iommu.c
index b4cf16c..b3c66f8 100644
--- a/xen/drivers/passthrough/iommu.c
+++ b/xen/drivers/passthrough/iommu.c
@@ -526,10 +526,9 @@ void iommu_crash_shutdown(void)
 }
 
 int iommu_do_domctl(
-    struct xen_domctl *domctl,
+    struct xen_domctl *domctl, struct domain *d,
     XEN_GUEST_HANDLE(xen_domctl_t) u_domctl)
 {
-    struct domain *d;
     u16 seg;
     u8 bus, devfn;
     int ret = 0;
@@ -548,10 +547,6 @@ int iommu_do_domctl(
         if ( ret )
             break;
 
-        ret = -EINVAL;
-        if ( (d = rcu_lock_domain_by_id(domctl->domain)) == NULL )
-            break;
-
         seg = domctl->u.get_device_group.machine_sbdf >> 16;
         bus = (domctl->u.get_device_group.machine_sbdf >> 8) & 0xff;
         devfn = domctl->u.get_device_group.machine_sbdf & 0xff;
@@ -572,7 +567,6 @@ int iommu_do_domctl(
         }
         if ( copy_to_guest(u_domctl, domctl, 1) )
             ret = -EFAULT;
-        rcu_unlock_domain(d);
     }
     break;
 
@@ -595,20 +589,15 @@ int iommu_do_domctl(
         break;
 
     case XEN_DOMCTL_assign_device:
-        if ( unlikely((d = get_domain_by_id(domctl->domain)) == NULL) ||
-             unlikely(d->is_dying) )
+        if ( unlikely(d->is_dying) )
         {
-            printk(XENLOG_G_ERR
-                   "XEN_DOMCTL_assign_device: get_domain_by_id() failed\n");
             ret = -EINVAL;
-            if ( d )
-                goto assign_device_out;
             break;
         }
 
         ret = xsm_assign_device(d, domctl->u.assign_device.machine_sbdf);
         if ( ret )
-            goto assign_device_out;
+            break;
 
         seg = domctl->u.get_device_group.machine_sbdf >> 16;
         bus = (domctl->u.assign_device.machine_sbdf >> 8) & 0xff;
@@ -622,22 +611,12 @@ int iommu_do_domctl(
                    seg, bus, PCI_SLOT(devfn), PCI_FUNC(devfn),
                    d->domain_id, ret);
 
-    assign_device_out:
-        put_domain(d);
         break;
 
     case XEN_DOMCTL_deassign_device:
-        if ( unlikely((d = get_domain_by_id(domctl->domain)) == NULL) )
-        {
-            printk(XENLOG_G_ERR
-                   "XEN_DOMCTL_deassign_device: get_domain_by_id() failed\n");
-            ret = -EINVAL;
-            break;
-        }
-
         ret = xsm_deassign_device(d, domctl->u.assign_device.machine_sbdf);
         if ( ret )
-            goto deassign_device_out;
+            break;
 
         seg = domctl->u.get_device_group.machine_sbdf >> 16;
         bus = (domctl->u.assign_device.machine_sbdf >> 8) & 0xff;
@@ -652,8 +631,6 @@ int iommu_do_domctl(
                    seg, bus, PCI_SLOT(devfn), PCI_FUNC(devfn),
                    d->domain_id, ret);
 
-    deassign_device_out:
-        put_domain(d);
         break;
 
     default:
diff --git a/xen/include/xen/hypercall.h b/xen/include/xen/hypercall.h
index 1b71071..36796d2 100644
--- a/xen/include/xen/hypercall.h
+++ b/xen/include/xen/hypercall.h
@@ -37,7 +37,7 @@ do_domctl(
 
 extern long
 arch_do_domctl(
-    struct xen_domctl *domctl,
+    struct xen_domctl *domctl, struct domain *d,
     XEN_GUEST_HANDLE(xen_domctl_t) u_domctl);
 
 extern long
diff --git a/xen/include/xen/iommu.h b/xen/include/xen/iommu.h
index 605c7b3..c2951a5 100644
--- a/xen/include/xen/iommu.h
+++ b/xen/include/xen/iommu.h
@@ -156,7 +156,8 @@ void iommu_crash_shutdown(void);
 void iommu_set_dom0_mapping(struct domain *d);
 void iommu_share_p2m_table(struct domain *d);
 
-int iommu_do_domctl(struct xen_domctl *, XEN_GUEST_HANDLE(xen_domctl_t));
+int iommu_do_domctl(struct xen_domctl *, struct domain *d,
+                    XEN_GUEST_HANDLE(xen_domctl_t));
 
 void iommu_iotlb_flush(struct domain *d, unsigned long gfn, unsigned int page_count);
 void iommu_iotlb_flush_all(struct domain *d);
-- 
1.7.11.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 17 15:24:27 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 15:24:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDdB9-0003aa-1a; Mon, 17 Sep 2012 15:24:07 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1TDdB7-0003Zu-5G
	for xen-devel@lists.xen.org; Mon, 17 Sep 2012 15:24:05 +0000
Received: from [85.158.139.211:49310] by server-2.bemta-5.messagelabs.com id
	E1/01-11456-49047505; Mon, 17 Sep 2012 15:24:04 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-13.tower-206.messagelabs.com!1347895443!14903398!1
X-Originating-IP: [63.239.67.9]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1590 invoked from network); 17 Sep 2012 15:24:03 -0000
Received: from emvm-gh1-uea08.nsa.gov (HELO nsa.gov) (63.239.67.9)
	by server-13.tower-206.messagelabs.com with SMTP;
	17 Sep 2012 15:24:03 -0000
X-TM-IMSS-Message-ID: <538031d30012acce@nsa.gov>
Received: from tarius.tycho.ncsc.mil ([144.51.3.1]) by nsa.gov ([63.239.67.9])
	with ESMTP (TREND IMSS SMTP Service 7.1) id 538031d30012acce ;
	Mon, 17 Sep 2012 11:23:43 -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 q8HFO0xV027504; 
	Mon, 17 Sep 2012 11:24:01 -0400
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xen.org
Date: Mon, 17 Sep 2012 11:23:27 -0400
Message-Id: <1347895425-17959-6-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.11.4
In-Reply-To: <1347895425-17959-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1347895425-17959-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Ian Jackson <ian.jackson@eu.citrix.com>, dgdegra@tycho.nsa.gov,
	keir@xen.org, Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH 05/23] libxl: introduce XSM relabel on build
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Allow a domain to be built under one security label and run using a
different label. This can be used to prevent the domain builder or
control domain from having the ability to access a guest domain's memory
via map_foreign_range except during the build process where this is
required.

Note: this does not provide complete protection from a malicious dom0;
mappings created during the build process may persist after the relabel,
and could be used to indirectly access the guest's memory.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: Ian Campbell <ian.campbell@citrix.com>
---
 tools/libxc/xc_flask.c      | 10 ++++++++++
 tools/libxc/xenctrl.h       |  1 +
 tools/libxl/libxl_create.c  |  4 ++++
 tools/libxl/libxl_types.idl |  1 +
 tools/libxl/xl_cmdimpl.c    | 20 +++++++++++++++++++-
 5 files changed, 35 insertions(+), 1 deletion(-)

diff --git a/tools/libxc/xc_flask.c b/tools/libxc/xc_flask.c
index 80c5a2d..face1e0 100644
--- a/tools/libxc/xc_flask.c
+++ b/tools/libxc/xc_flask.c
@@ -422,6 +422,16 @@ int xc_flask_setavc_threshold(xc_interface *xch, int threshold)
     return xc_flask_op(xch, &op);
 }
 
+int xc_flask_relabel_domain(xc_interface *xch, int domid, uint32_t sid)
+{
+    DECLARE_FLASK_OP;
+    op.cmd = FLASK_RELABEL_DOMAIN;
+    op.u.relabel.domid = domid;
+    op.u.relabel.sid = sid;
+
+    return xc_flask_op(xch, &op);
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/tools/libxc/xenctrl.h b/tools/libxc/xenctrl.h
index 7eb5743..60391c6 100644
--- a/tools/libxc/xenctrl.h
+++ b/tools/libxc/xenctrl.h
@@ -2158,6 +2158,7 @@ int xc_flask_policyvers(xc_interface *xc_handle);
 int xc_flask_avc_hashstats(xc_interface *xc_handle, char *buf, int size);
 int xc_flask_getavc_threshold(xc_interface *xc_handle);
 int xc_flask_setavc_threshold(xc_interface *xc_handle, int threshold);
+int xc_flask_relabel_domain(xc_interface *xch, int domid, uint32_t sid);
 
 struct elf_binary;
 void xc_elf_set_logfile(xc_interface *xch, struct elf_binary *elf,
diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index ef17f05..6d7bf4e 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -1126,6 +1126,10 @@ static void domcreate_complete(libxl__egc *egc,
                                int rc)
 {
     STATE_AO_GC(dcs->ao);
+    libxl_domain_config *const d_config = dcs->guest_config;
+
+    if (!rc && d_config->b_info.exec_ssidref)
+        rc = xc_flask_relabel_domain(CTX->xch, dcs->guest_domid, d_config->b_info.exec_ssidref);
 
     if (rc) {
         if (dcs->guest_domid) {
diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
index 6d5c578..bc11591 100644
--- a/tools/libxl/libxl_types.idl
+++ b/tools/libxl/libxl_types.idl
@@ -262,6 +262,7 @@ libxl_domain_build_info = Struct("domain_build_info",[
     ("video_memkb",     MemKB),
     ("shadow_memkb",    MemKB),
     ("rtc_timeoffset",  uint32),
+    ("exec_ssidref",    uint32),
     ("localtime",       libxl_defbool),
     ("disable_migrate", libxl_defbool),
     ("cpuid",           libxl_cpuid_policy_list),
diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index 1627cac..ecea26a 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -596,16 +596,34 @@ static void parse_config_data(const char *config_source,
         exit(1);
     }
 
-    if (!xlu_cfg_get_string (config, "seclabel", &buf, 0)) {
+    if (!xlu_cfg_get_string (config, "init_seclabel", &buf, 0)) {
         e = libxl_flask_context_to_sid(ctx, (char *)buf, strlen(buf),
                                     &c_info->ssidref);
         if (e) {
             if (errno == ENOSYS) {
+                fprintf(stderr, "XSM Disabled: init_seclabel not supported\n");
+            } else {
+                fprintf(stderr, "Invalid init_seclabel: %s\n", buf);
+                exit(1);
+            }
+        }
+    }
+
+    if (!xlu_cfg_get_string (config, "seclabel", &buf, 0)) {
+        uint32_t ssidref;
+        e = libxl_flask_context_to_sid(ctx, (char *)buf, strlen(buf),
+                                    &ssidref);
+        if (e) {
+            if (errno == ENOSYS) {
                 fprintf(stderr, "XSM Disabled: seclabel not supported\n");
             } else {
                 fprintf(stderr, "Invalid seclabel: %s\n", buf);
                 exit(1);
             }
+        } else if (c_info->ssidref) {
+            b_info->exec_ssidref = ssidref;
+        } else {
+            c_info->ssidref = ssidref;
         }
     }
 
-- 
1.7.11.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 17 15:24:27 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 15:24:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDdB9-0003aa-1a; Mon, 17 Sep 2012 15:24:07 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1TDdB7-0003Zu-5G
	for xen-devel@lists.xen.org; Mon, 17 Sep 2012 15:24:05 +0000
Received: from [85.158.139.211:49310] by server-2.bemta-5.messagelabs.com id
	E1/01-11456-49047505; Mon, 17 Sep 2012 15:24:04 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-13.tower-206.messagelabs.com!1347895443!14903398!1
X-Originating-IP: [63.239.67.9]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1590 invoked from network); 17 Sep 2012 15:24:03 -0000
Received: from emvm-gh1-uea08.nsa.gov (HELO nsa.gov) (63.239.67.9)
	by server-13.tower-206.messagelabs.com with SMTP;
	17 Sep 2012 15:24:03 -0000
X-TM-IMSS-Message-ID: <538031d30012acce@nsa.gov>
Received: from tarius.tycho.ncsc.mil ([144.51.3.1]) by nsa.gov ([63.239.67.9])
	with ESMTP (TREND IMSS SMTP Service 7.1) id 538031d30012acce ;
	Mon, 17 Sep 2012 11:23:43 -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 q8HFO0xV027504; 
	Mon, 17 Sep 2012 11:24:01 -0400
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xen.org
Date: Mon, 17 Sep 2012 11:23:27 -0400
Message-Id: <1347895425-17959-6-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.11.4
In-Reply-To: <1347895425-17959-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1347895425-17959-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Ian Jackson <ian.jackson@eu.citrix.com>, dgdegra@tycho.nsa.gov,
	keir@xen.org, Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH 05/23] libxl: introduce XSM relabel on build
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Allow a domain to be built under one security label and run using a
different label. This can be used to prevent the domain builder or
control domain from having the ability to access a guest domain's memory
via map_foreign_range except during the build process where this is
required.

Note: this does not provide complete protection from a malicious dom0;
mappings created during the build process may persist after the relabel,
and could be used to indirectly access the guest's memory.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: Ian Campbell <ian.campbell@citrix.com>
---
 tools/libxc/xc_flask.c      | 10 ++++++++++
 tools/libxc/xenctrl.h       |  1 +
 tools/libxl/libxl_create.c  |  4 ++++
 tools/libxl/libxl_types.idl |  1 +
 tools/libxl/xl_cmdimpl.c    | 20 +++++++++++++++++++-
 5 files changed, 35 insertions(+), 1 deletion(-)

diff --git a/tools/libxc/xc_flask.c b/tools/libxc/xc_flask.c
index 80c5a2d..face1e0 100644
--- a/tools/libxc/xc_flask.c
+++ b/tools/libxc/xc_flask.c
@@ -422,6 +422,16 @@ int xc_flask_setavc_threshold(xc_interface *xch, int threshold)
     return xc_flask_op(xch, &op);
 }
 
+int xc_flask_relabel_domain(xc_interface *xch, int domid, uint32_t sid)
+{
+    DECLARE_FLASK_OP;
+    op.cmd = FLASK_RELABEL_DOMAIN;
+    op.u.relabel.domid = domid;
+    op.u.relabel.sid = sid;
+
+    return xc_flask_op(xch, &op);
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/tools/libxc/xenctrl.h b/tools/libxc/xenctrl.h
index 7eb5743..60391c6 100644
--- a/tools/libxc/xenctrl.h
+++ b/tools/libxc/xenctrl.h
@@ -2158,6 +2158,7 @@ int xc_flask_policyvers(xc_interface *xc_handle);
 int xc_flask_avc_hashstats(xc_interface *xc_handle, char *buf, int size);
 int xc_flask_getavc_threshold(xc_interface *xc_handle);
 int xc_flask_setavc_threshold(xc_interface *xc_handle, int threshold);
+int xc_flask_relabel_domain(xc_interface *xch, int domid, uint32_t sid);
 
 struct elf_binary;
 void xc_elf_set_logfile(xc_interface *xch, struct elf_binary *elf,
diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index ef17f05..6d7bf4e 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -1126,6 +1126,10 @@ static void domcreate_complete(libxl__egc *egc,
                                int rc)
 {
     STATE_AO_GC(dcs->ao);
+    libxl_domain_config *const d_config = dcs->guest_config;
+
+    if (!rc && d_config->b_info.exec_ssidref)
+        rc = xc_flask_relabel_domain(CTX->xch, dcs->guest_domid, d_config->b_info.exec_ssidref);
 
     if (rc) {
         if (dcs->guest_domid) {
diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
index 6d5c578..bc11591 100644
--- a/tools/libxl/libxl_types.idl
+++ b/tools/libxl/libxl_types.idl
@@ -262,6 +262,7 @@ libxl_domain_build_info = Struct("domain_build_info",[
     ("video_memkb",     MemKB),
     ("shadow_memkb",    MemKB),
     ("rtc_timeoffset",  uint32),
+    ("exec_ssidref",    uint32),
     ("localtime",       libxl_defbool),
     ("disable_migrate", libxl_defbool),
     ("cpuid",           libxl_cpuid_policy_list),
diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index 1627cac..ecea26a 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -596,16 +596,34 @@ static void parse_config_data(const char *config_source,
         exit(1);
     }
 
-    if (!xlu_cfg_get_string (config, "seclabel", &buf, 0)) {
+    if (!xlu_cfg_get_string (config, "init_seclabel", &buf, 0)) {
         e = libxl_flask_context_to_sid(ctx, (char *)buf, strlen(buf),
                                     &c_info->ssidref);
         if (e) {
             if (errno == ENOSYS) {
+                fprintf(stderr, "XSM Disabled: init_seclabel not supported\n");
+            } else {
+                fprintf(stderr, "Invalid init_seclabel: %s\n", buf);
+                exit(1);
+            }
+        }
+    }
+
+    if (!xlu_cfg_get_string (config, "seclabel", &buf, 0)) {
+        uint32_t ssidref;
+        e = libxl_flask_context_to_sid(ctx, (char *)buf, strlen(buf),
+                                    &ssidref);
+        if (e) {
+            if (errno == ENOSYS) {
                 fprintf(stderr, "XSM Disabled: seclabel not supported\n");
             } else {
                 fprintf(stderr, "Invalid seclabel: %s\n", buf);
                 exit(1);
             }
+        } else if (c_info->ssidref) {
+            b_info->exec_ssidref = ssidref;
+        } else {
+            c_info->ssidref = ssidref;
         }
     }
 
-- 
1.7.11.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 17 15:24:27 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 15:24:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDdBC-0003cp-0i; Mon, 17 Sep 2012 15:24:10 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1TDdBA-0003as-3X
	for xen-devel@lists.xen.org; Mon, 17 Sep 2012 15:24:08 +0000
Received: from [85.158.139.211:51752] by server-10.bemta-5.messagelabs.com id
	F5/7C-10969-79047505; Mon, 17 Sep 2012 15:24:07 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-13.tower-206.messagelabs.com!1347895445!14903404!1
X-Originating-IP: [63.239.67.9]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1717 invoked from network); 17 Sep 2012 15:24:05 -0000
Received: from emvm-gh1-uea08.nsa.gov (HELO nsa.gov) (63.239.67.9)
	by server-13.tower-206.messagelabs.com with SMTP;
	17 Sep 2012 15:24:05 -0000
X-TM-IMSS-Message-ID: <53803c100012acda@nsa.gov>
Received: from tarius.tycho.ncsc.mil ([144.51.3.1]) by nsa.gov ([63.239.67.9])
	with ESMTP (TREND IMSS SMTP Service 7.1) id 53803c100012acda ;
	Mon, 17 Sep 2012 11:23:45 -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 q8HFO0xd027504; 
	Mon, 17 Sep 2012 11:24:04 -0400
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xen.org
Date: Mon, 17 Sep 2012 11:23:35 -0400
Message-Id: <1347895425-17959-14-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.11.4
In-Reply-To: <1347895425-17959-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1347895425-17959-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: dgdegra@tycho.nsa.gov, keir@xen.org, Jan Beulich <jbeulich@suse.com>
Subject: [Xen-devel] [PATCH 13/23] xen: lock target domain in do_domctl
	common code
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 almost all domctls need to lock the target domain, do this by
default instead of repeating it in each domctl. This is not currently
extended to the arch-specific domctls, but RCU locks are safe to take
recursively so this only causes duplicate but correct locking.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Cc: Keir Fraser <keir@xen.org>
Cc: Jan Beulich <jbeulich@suse.com>
---
 xen/common/domctl.c | 268 ++++++++++++----------------------------------------
 1 file changed, 59 insertions(+), 209 deletions(-)

diff --git a/xen/common/domctl.c b/xen/common/domctl.c
index d99ba67..ef2700d 100644
--- a/xen/common/domctl.c
+++ b/xen/common/domctl.c
@@ -243,6 +243,7 @@ long do_domctl(XEN_GUEST_HANDLE(xen_domctl_t) u_domctl)
 {
     long ret = 0;
     struct xen_domctl curop, *op = &curop;
+    struct domain *d;
 
     if ( copy_from_guest(op, u_domctl, 1) )
         return -EFAULT;
@@ -252,19 +253,29 @@ long do_domctl(XEN_GUEST_HANDLE(xen_domctl_t) u_domctl)
 
     switch ( op->cmd )
     {
+    case XEN_DOMCTL_createdomain:
+    case XEN_DOMCTL_getdomaininfo:
+    case XEN_DOMCTL_test_assign_device:
+        d = NULL;
+        break;
+    default:
+        d = rcu_lock_domain_by_id(op->domain);
+        if ( d == NULL )
+            return -ESRCH;
+    }
+
+    switch ( op->cmd )
+    {
     case XEN_DOMCTL_ioport_mapping:
     case XEN_DOMCTL_memory_mapping:
     case XEN_DOMCTL_bind_pt_irq:
     case XEN_DOMCTL_unbind_pt_irq: {
-        struct domain *d;
-        bool_t is_priv = IS_PRIV(current->domain);
-        if ( !is_priv && ((d = rcu_lock_domain_by_id(op->domain)) != NULL) )
+        bool_t is_priv = IS_PRIV_FOR(current->domain, d);
+        if ( !is_priv )
         {
-            is_priv = IS_PRIV_FOR(current->domain, d);
-            rcu_unlock_domain(d);
+            ret = -EPERM;
+            goto domctl_out_unlock;
         }
-        if ( !is_priv )
-            return -EPERM;
         break;
     }
     case XEN_DOMCTL_getdomaininfo:
@@ -276,15 +287,18 @@ long do_domctl(XEN_GUEST_HANDLE(xen_domctl_t) u_domctl)
     }
 
     if ( !domctl_lock_acquire() )
+    {
+        if ( d )
+            rcu_unlock_domain(d);
         return hypercall_create_continuation(
             __HYPERVISOR_domctl, "h", u_domctl);
+    }
 
     switch ( op->cmd )
     {
 
     case XEN_DOMCTL_setvcpucontext:
     {
-        struct domain *d = rcu_lock_domain_by_id(op->domain);
         vcpu_guest_context_u c = { .nat = NULL };
         unsigned int vcpu = op->u.vcpucontext.vcpu;
         struct vcpu *v;
@@ -338,77 +352,48 @@ long do_domctl(XEN_GUEST_HANDLE(xen_domctl_t) u_domctl)
 
     svc_out:
         free_vcpu_guest_context(c.nat);
-        rcu_unlock_domain(d);
     }
     break;
 
     case XEN_DOMCTL_pausedomain:
     {
-        struct domain *d = rcu_lock_domain_by_id(op->domain);
-        ret = -ESRCH;
-        if ( d != NULL )
-        {
-            ret = xsm_pausedomain(d);
-            if ( ret )
-                goto pausedomain_out;
+        ret = xsm_pausedomain(d);
+        if ( ret )
+            break;
 
-            ret = -EINVAL;
-            if ( d != current->domain )
-            {
-                domain_pause_by_systemcontroller(d);
-                ret = 0;
-            }
-        pausedomain_out:
-            rcu_unlock_domain(d);
+        ret = -EINVAL;
+        if ( d != current->domain )
+        {
+            domain_pause_by_systemcontroller(d);
+            ret = 0;
         }
     }
     break;
 
     case XEN_DOMCTL_unpausedomain:
     {
-        struct domain *d = rcu_lock_domain_by_id(op->domain);
-
-        ret = -ESRCH;
-        if ( d == NULL )
-            break;
-
         ret = xsm_unpausedomain(d);
         if ( ret )
-        {
-            rcu_unlock_domain(d);
             break;
-        }
 
         domain_unpause_by_systemcontroller(d);
-        rcu_unlock_domain(d);
         ret = 0;
     }
     break;
 
     case XEN_DOMCTL_resumedomain:
     {
-        struct domain *d = rcu_lock_domain_by_id(op->domain);
-
-        ret = -ESRCH;
-        if ( d == NULL )
-            break;
-
         ret = xsm_resumedomain(d);
         if ( ret )
-        {
-            rcu_unlock_domain(d);
             break;
-        }
 
         domain_resume(d);
-        rcu_unlock_domain(d);
         ret = 0;
     }
     break;
 
     case XEN_DOMCTL_createdomain:
     {
-        struct domain *d;
         domid_t        dom;
         static domid_t rover = 0;
         unsigned int domcr_flags;
@@ -458,6 +443,7 @@ long do_domctl(XEN_GUEST_HANDLE(xen_domctl_t) u_domctl)
         if ( IS_ERR(d) )
         {
             ret = PTR_ERR(d);
+            d = NULL;
             break;
         }
 
@@ -469,39 +455,28 @@ long do_domctl(XEN_GUEST_HANDLE(xen_domctl_t) u_domctl)
         op->domain = d->domain_id;
         if ( copy_to_guest(u_domctl, op, 1) )
             ret = -EFAULT;
+        d = NULL;
     }
     break;
 
     case XEN_DOMCTL_max_vcpus:
     {
-        struct domain *d;
         unsigned int i, max = op->u.max_vcpus.max, cpu;
         cpumask_t *online;
 
-        ret = -ESRCH;
-        if ( (d = rcu_lock_domain_by_id(op->domain)) == NULL )
-            break;
-
         ret = -EINVAL;
         if ( (d == current->domain) || /* no domain_pause() */
              (max > MAX_VIRT_CPUS) ||
              (is_hvm_domain(d) && (max > MAX_HVM_VCPUS)) )
-        {
-            rcu_unlock_domain(d);
             break;
-        }
 
         ret = xsm_max_vcpus(d);
         if ( ret )
-        {
-            rcu_unlock_domain(d);
             break;
-        }
 
         /* Until Xenoprof can dynamically grow its vcpu-s array... */
         if ( d->xenoprof )
         {
-            rcu_unlock_domain(d);
             ret = -EAGAIN;
             break;
         }
@@ -576,44 +551,31 @@ long do_domctl(XEN_GUEST_HANDLE(xen_domctl_t) u_domctl)
 
     maxvcpu_out_novcpulock:
         domain_unpause(d);
-        rcu_unlock_domain(d);
     }
     break;
 
     case XEN_DOMCTL_destroydomain:
     {
-        struct domain *d = rcu_lock_domain_by_id(op->domain);
-        ret = -ESRCH;
-        if ( d != NULL )
-        {
-            ret = xsm_destroydomain(d) ? : domain_kill(d);
-            rcu_unlock_domain(d);
-        }
+        ret = xsm_destroydomain(d) ? : domain_kill(d);
     }
     break;
 
     case XEN_DOMCTL_setvcpuaffinity:
     case XEN_DOMCTL_getvcpuaffinity:
     {
-        domid_t dom = op->domain;
-        struct domain *d = rcu_lock_domain_by_id(dom);
         struct vcpu *v;
 
-        ret = -ESRCH;
-        if ( d == NULL )
-            break;
-
         ret = xsm_vcpuaffinity(op->cmd, d);
         if ( ret )
-            goto vcpuaffinity_out;
+            break;
 
         ret = -EINVAL;
         if ( op->u.vcpuaffinity.vcpu >= d->max_vcpus )
-            goto vcpuaffinity_out;
+            break;
 
         ret = -ESRCH;
         if ( (v = d->vcpu[op->u.vcpuaffinity.vcpu]) == NULL )
-            goto vcpuaffinity_out;
+            break;
 
         if ( op->cmd == XEN_DOMCTL_setvcpuaffinity )
         {
@@ -632,36 +594,23 @@ long do_domctl(XEN_GUEST_HANDLE(xen_domctl_t) u_domctl)
             ret = cpumask_to_xenctl_cpumap(
                 &op->u.vcpuaffinity.cpumap, v->cpu_affinity);
         }
-
-    vcpuaffinity_out:
-        rcu_unlock_domain(d);
     }
     break;
 
     case XEN_DOMCTL_scheduler_op:
     {
-        struct domain *d;
-
-        ret = -ESRCH;
-        if ( (d = rcu_lock_domain_by_id(op->domain)) == NULL )
-            break;
-
         ret = xsm_scheduler(d);
         if ( ret )
-            goto scheduler_op_out;
+            break;
 
         ret = sched_adjust(d, &op->u.scheduler_op);
         if ( copy_to_guest(u_domctl, op, 1) )
             ret = -EFAULT;
-
-    scheduler_op_out:
-        rcu_unlock_domain(d);
     }
     break;
 
     case XEN_DOMCTL_getdomaininfo:
     { 
-        struct domain *d;
         domid_t dom = op->domain;
 
         rcu_read_lock(&domlist_read_lock);
@@ -689,19 +638,15 @@ long do_domctl(XEN_GUEST_HANDLE(xen_domctl_t) u_domctl)
 
     getdomaininfo_out:
         rcu_read_unlock(&domlist_read_lock);
+        d = NULL;
     }
     break;
 
     case XEN_DOMCTL_getvcpucontext:
     { 
         vcpu_guest_context_u c = { .nat = NULL };
-        struct domain       *d;
         struct vcpu         *v;
 
-        ret = -ESRCH;
-        if ( (d = rcu_lock_domain_by_id(op->domain)) == NULL )
-            break;
-
         ret = xsm_getvcpucontext(d);
         if ( ret )
             goto getvcpucontext_out;
@@ -750,31 +695,25 @@ long do_domctl(XEN_GUEST_HANDLE(xen_domctl_t) u_domctl)
 
     getvcpucontext_out:
         xfree(c.nat);
-        rcu_unlock_domain(d);
     }
     break;
 
     case XEN_DOMCTL_getvcpuinfo:
     { 
-        struct domain *d;
         struct vcpu   *v;
         struct vcpu_runstate_info runstate;
 
-        ret = -ESRCH;
-        if ( (d = rcu_lock_domain_by_id(op->domain)) == NULL )
-            break;
-
         ret = xsm_getvcpuinfo(d);
         if ( ret )
-            goto getvcpuinfo_out;
+            break;
 
         ret = -EINVAL;
         if ( op->u.getvcpuinfo.vcpu >= d->max_vcpus )
-            goto getvcpuinfo_out;
+            break;
 
         ret = -ESRCH;
         if ( (v = d->vcpu[op->u.getvcpuinfo.vcpu]) == NULL )
-            goto getvcpuinfo_out;
+            break;
 
         vcpu_runstate_get(v, &runstate);
 
@@ -787,25 +726,16 @@ long do_domctl(XEN_GUEST_HANDLE(xen_domctl_t) u_domctl)
 
         if ( copy_to_guest(u_domctl, op, 1) )
             ret = -EFAULT;
-
-    getvcpuinfo_out:
-        rcu_unlock_domain(d);
     }
     break;
 
     case XEN_DOMCTL_max_mem:
     {
-        struct domain *d;
         unsigned long new_max;
 
-        ret = -ESRCH;
-        d = rcu_lock_domain_by_id(op->domain);
-        if ( d == NULL )
-            break;
-
         ret = xsm_setdomainmaxmem(d);
         if ( ret )
-            goto max_mem_out;
+            break;
 
         ret = -EINVAL;
         new_max = op->u.max_mem.max_memkb >> (PAGE_SHIFT-10);
@@ -819,77 +749,43 @@ long do_domctl(XEN_GUEST_HANDLE(xen_domctl_t) u_domctl)
         d->max_pages = new_max;
         ret = 0;
         spin_unlock(&d->page_alloc_lock);
-
-    max_mem_out:
-        rcu_unlock_domain(d);
     }
     break;
 
     case XEN_DOMCTL_setdomainhandle:
     {
-        struct domain *d;
-
-        ret = -ESRCH;
-        d = rcu_lock_domain_by_id(op->domain);
-        if ( d == NULL )
-            break;
-
         ret = xsm_setdomainhandle(d);
         if ( ret )
-        {
-            rcu_unlock_domain(d);
             break;
-        }
 
         memcpy(d->handle, op->u.setdomainhandle.handle,
                sizeof(xen_domain_handle_t));
-        rcu_unlock_domain(d);
         ret = 0;
     }
     break;
 
     case XEN_DOMCTL_setdebugging:
     {
-        struct domain *d;
-
-        ret = -ESRCH;
-        d = rcu_lock_domain_by_id(op->domain);
-        if ( d == NULL )
-            break;
-
         ret = -EINVAL;
         if ( d == current->domain ) /* no domain_pause() */
-        {
-            rcu_unlock_domain(d);
             break;
-        }
 
         ret = xsm_setdebugging(d);
         if ( ret )
-        {
-            rcu_unlock_domain(d);
             break;
-        }
 
         domain_pause(d);
         d->debugger_attached = !!op->u.setdebugging.enable;
         domain_unpause(d); /* causes guest to latch new status */
-        rcu_unlock_domain(d);
         ret = 0;
     }
     break;
 
     case XEN_DOMCTL_irq_permission:
     {
-        struct domain *d;
         unsigned int pirq = op->u.irq_permission.pirq;
         int allow = op->u.irq_permission.allow_access;
 
-        ret = -ESRCH;
-        d = rcu_lock_domain_by_id(op->domain);
-        if ( d == NULL )
-            break;
-
         if ( pirq >= d->nr_pirqs )
             ret = -EINVAL;
         else if ( xsm_irq_permission(d, pirq, allow) )
@@ -898,14 +794,11 @@ long do_domctl(XEN_GUEST_HANDLE(xen_domctl_t) u_domctl)
             ret = irq_permit_access(d, pirq);
         else
             ret = irq_deny_access(d, pirq);
-
-        rcu_unlock_domain(d);
     }
     break;
 
     case XEN_DOMCTL_iomem_permission:
     {
-        struct domain *d;
         unsigned long mfn = op->u.iomem_permission.first_mfn;
         unsigned long nr_mfns = op->u.iomem_permission.nr_mfns;
         int allow = op->u.iomem_permission.allow_access;
@@ -914,125 +807,78 @@ long do_domctl(XEN_GUEST_HANDLE(xen_domctl_t) u_domctl)
         if ( (mfn + nr_mfns - 1) < mfn ) /* wrap? */
             break;
 
-        ret = -ESRCH;
-        d = rcu_lock_domain_by_id(op->domain);
-        if ( d == NULL )
-            break;
-
         if ( xsm_iomem_permission(d, mfn, mfn + nr_mfns - 1, allow) )
             ret = -EPERM;
         else if ( allow )
             ret = iomem_permit_access(d, mfn, mfn + nr_mfns - 1);
         else
             ret = iomem_deny_access(d, mfn, mfn + nr_mfns - 1);
-
-        rcu_unlock_domain(d);
     }
     break;
 
     case XEN_DOMCTL_settimeoffset:
     {
-        struct domain *d;
-
-        ret = -ESRCH;
-        d = rcu_lock_domain_by_id(op->domain);
-        if ( d == NULL )
-            break;
-
         ret = xsm_domain_settime(d);
         if ( ret )
-        {
-            rcu_unlock_domain(d);
             break;
-        }
 
         domain_set_time_offset(d, op->u.settimeoffset.time_offset_seconds);
-        rcu_unlock_domain(d);
         ret = 0;
     }
     break;
 
     case XEN_DOMCTL_set_target:
     {
-        struct domain *d, *e;
-
-        ret = -ESRCH;
-        d = rcu_lock_domain_by_id(op->domain);
-        if ( d == NULL )
-            break;
+        struct domain *e;
 
         ret = -ESRCH;
         e = get_domain_by_id(op->u.set_target.target);
         if ( e == NULL )
-            goto set_target_out;
+            break;
 
         ret = -EINVAL;
         if ( (d == e) || (d->target != NULL) )
         {
             put_domain(e);
-            goto set_target_out;
+            break;
         }
 
         ret = xsm_set_target(d, e);
         if ( ret ) {
             put_domain(e);
-            goto set_target_out;            
+            break;
         }
 
         /* Hold reference on @e until we destroy @d. */
         d->target = e;
 
         ret = 0;
-
-    set_target_out:
-        rcu_unlock_domain(d);
     }
     break;
 
     case XEN_DOMCTL_subscribe:
     {
-        struct domain *d;
-
-        ret = -ESRCH;
-        d = rcu_lock_domain_by_id(op->domain);
-        if ( d != NULL )
-        {
-            ret = xsm_domctl(d, op->cmd);
-            if ( !ret )
-                d->suspend_evtchn = op->u.subscribe.port;
-            rcu_unlock_domain(d);
-        }
+        ret = xsm_domctl(d, op->cmd);
+        if ( !ret )
+            d->suspend_evtchn = op->u.subscribe.port;
     }
     break;
 
     case XEN_DOMCTL_disable_migrate:
     {
-        struct domain *d;
-        ret = -ESRCH;
-        if ( (d = rcu_lock_domain_by_id(op->domain)) != NULL )
-        {
-            ret = xsm_domctl(d, op->cmd);
-            if ( !ret )
-                d->disable_migrate = op->u.disable_migrate.disable;
-            rcu_unlock_domain(d);
-        }
+        ret = xsm_domctl(d, op->cmd);
+        if ( !ret )
+            d->disable_migrate = op->u.disable_migrate.disable;
     }
     break;
 
     case XEN_DOMCTL_set_virq_handler:
     {
-        struct domain *d;
         uint32_t virq = op->u.set_virq_handler.virq;
 
-        ret = -ESRCH;
-        d = rcu_lock_domain_by_id(op->domain);
-        if ( d != NULL )
-        {
-            ret = xsm_set_virq_handler(d, virq);
-            if ( !ret )
-                ret = set_global_virq_handler(d, virq);
-            rcu_unlock_domain(d);
-        }
+        ret = xsm_set_virq_handler(d, virq);
+        if ( !ret )
+            ret = set_global_virq_handler(d, virq);
     }
     break;
 
@@ -1043,6 +889,10 @@ long do_domctl(XEN_GUEST_HANDLE(xen_domctl_t) u_domctl)
 
     domctl_lock_release();
 
+ domctl_out_unlock:
+    if ( d )
+        rcu_unlock_domain(d);
+
     return ret;
 }
 
-- 
1.7.11.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 17 15:24:27 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 15:24:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDdBC-0003cp-0i; Mon, 17 Sep 2012 15:24:10 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1TDdBA-0003as-3X
	for xen-devel@lists.xen.org; Mon, 17 Sep 2012 15:24:08 +0000
Received: from [85.158.139.211:51752] by server-10.bemta-5.messagelabs.com id
	F5/7C-10969-79047505; Mon, 17 Sep 2012 15:24:07 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-13.tower-206.messagelabs.com!1347895445!14903404!1
X-Originating-IP: [63.239.67.9]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1717 invoked from network); 17 Sep 2012 15:24:05 -0000
Received: from emvm-gh1-uea08.nsa.gov (HELO nsa.gov) (63.239.67.9)
	by server-13.tower-206.messagelabs.com with SMTP;
	17 Sep 2012 15:24:05 -0000
X-TM-IMSS-Message-ID: <53803c100012acda@nsa.gov>
Received: from tarius.tycho.ncsc.mil ([144.51.3.1]) by nsa.gov ([63.239.67.9])
	with ESMTP (TREND IMSS SMTP Service 7.1) id 53803c100012acda ;
	Mon, 17 Sep 2012 11:23:45 -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 q8HFO0xd027504; 
	Mon, 17 Sep 2012 11:24:04 -0400
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xen.org
Date: Mon, 17 Sep 2012 11:23:35 -0400
Message-Id: <1347895425-17959-14-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.11.4
In-Reply-To: <1347895425-17959-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1347895425-17959-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: dgdegra@tycho.nsa.gov, keir@xen.org, Jan Beulich <jbeulich@suse.com>
Subject: [Xen-devel] [PATCH 13/23] xen: lock target domain in do_domctl
	common code
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 almost all domctls need to lock the target domain, do this by
default instead of repeating it in each domctl. This is not currently
extended to the arch-specific domctls, but RCU locks are safe to take
recursively so this only causes duplicate but correct locking.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Cc: Keir Fraser <keir@xen.org>
Cc: Jan Beulich <jbeulich@suse.com>
---
 xen/common/domctl.c | 268 ++++++++++++----------------------------------------
 1 file changed, 59 insertions(+), 209 deletions(-)

diff --git a/xen/common/domctl.c b/xen/common/domctl.c
index d99ba67..ef2700d 100644
--- a/xen/common/domctl.c
+++ b/xen/common/domctl.c
@@ -243,6 +243,7 @@ long do_domctl(XEN_GUEST_HANDLE(xen_domctl_t) u_domctl)
 {
     long ret = 0;
     struct xen_domctl curop, *op = &curop;
+    struct domain *d;
 
     if ( copy_from_guest(op, u_domctl, 1) )
         return -EFAULT;
@@ -252,19 +253,29 @@ long do_domctl(XEN_GUEST_HANDLE(xen_domctl_t) u_domctl)
 
     switch ( op->cmd )
     {
+    case XEN_DOMCTL_createdomain:
+    case XEN_DOMCTL_getdomaininfo:
+    case XEN_DOMCTL_test_assign_device:
+        d = NULL;
+        break;
+    default:
+        d = rcu_lock_domain_by_id(op->domain);
+        if ( d == NULL )
+            return -ESRCH;
+    }
+
+    switch ( op->cmd )
+    {
     case XEN_DOMCTL_ioport_mapping:
     case XEN_DOMCTL_memory_mapping:
     case XEN_DOMCTL_bind_pt_irq:
     case XEN_DOMCTL_unbind_pt_irq: {
-        struct domain *d;
-        bool_t is_priv = IS_PRIV(current->domain);
-        if ( !is_priv && ((d = rcu_lock_domain_by_id(op->domain)) != NULL) )
+        bool_t is_priv = IS_PRIV_FOR(current->domain, d);
+        if ( !is_priv )
         {
-            is_priv = IS_PRIV_FOR(current->domain, d);
-            rcu_unlock_domain(d);
+            ret = -EPERM;
+            goto domctl_out_unlock;
         }
-        if ( !is_priv )
-            return -EPERM;
         break;
     }
     case XEN_DOMCTL_getdomaininfo:
@@ -276,15 +287,18 @@ long do_domctl(XEN_GUEST_HANDLE(xen_domctl_t) u_domctl)
     }
 
     if ( !domctl_lock_acquire() )
+    {
+        if ( d )
+            rcu_unlock_domain(d);
         return hypercall_create_continuation(
             __HYPERVISOR_domctl, "h", u_domctl);
+    }
 
     switch ( op->cmd )
     {
 
     case XEN_DOMCTL_setvcpucontext:
     {
-        struct domain *d = rcu_lock_domain_by_id(op->domain);
         vcpu_guest_context_u c = { .nat = NULL };
         unsigned int vcpu = op->u.vcpucontext.vcpu;
         struct vcpu *v;
@@ -338,77 +352,48 @@ long do_domctl(XEN_GUEST_HANDLE(xen_domctl_t) u_domctl)
 
     svc_out:
         free_vcpu_guest_context(c.nat);
-        rcu_unlock_domain(d);
     }
     break;
 
     case XEN_DOMCTL_pausedomain:
     {
-        struct domain *d = rcu_lock_domain_by_id(op->domain);
-        ret = -ESRCH;
-        if ( d != NULL )
-        {
-            ret = xsm_pausedomain(d);
-            if ( ret )
-                goto pausedomain_out;
+        ret = xsm_pausedomain(d);
+        if ( ret )
+            break;
 
-            ret = -EINVAL;
-            if ( d != current->domain )
-            {
-                domain_pause_by_systemcontroller(d);
-                ret = 0;
-            }
-        pausedomain_out:
-            rcu_unlock_domain(d);
+        ret = -EINVAL;
+        if ( d != current->domain )
+        {
+            domain_pause_by_systemcontroller(d);
+            ret = 0;
         }
     }
     break;
 
     case XEN_DOMCTL_unpausedomain:
     {
-        struct domain *d = rcu_lock_domain_by_id(op->domain);
-
-        ret = -ESRCH;
-        if ( d == NULL )
-            break;
-
         ret = xsm_unpausedomain(d);
         if ( ret )
-        {
-            rcu_unlock_domain(d);
             break;
-        }
 
         domain_unpause_by_systemcontroller(d);
-        rcu_unlock_domain(d);
         ret = 0;
     }
     break;
 
     case XEN_DOMCTL_resumedomain:
     {
-        struct domain *d = rcu_lock_domain_by_id(op->domain);
-
-        ret = -ESRCH;
-        if ( d == NULL )
-            break;
-
         ret = xsm_resumedomain(d);
         if ( ret )
-        {
-            rcu_unlock_domain(d);
             break;
-        }
 
         domain_resume(d);
-        rcu_unlock_domain(d);
         ret = 0;
     }
     break;
 
     case XEN_DOMCTL_createdomain:
     {
-        struct domain *d;
         domid_t        dom;
         static domid_t rover = 0;
         unsigned int domcr_flags;
@@ -458,6 +443,7 @@ long do_domctl(XEN_GUEST_HANDLE(xen_domctl_t) u_domctl)
         if ( IS_ERR(d) )
         {
             ret = PTR_ERR(d);
+            d = NULL;
             break;
         }
 
@@ -469,39 +455,28 @@ long do_domctl(XEN_GUEST_HANDLE(xen_domctl_t) u_domctl)
         op->domain = d->domain_id;
         if ( copy_to_guest(u_domctl, op, 1) )
             ret = -EFAULT;
+        d = NULL;
     }
     break;
 
     case XEN_DOMCTL_max_vcpus:
     {
-        struct domain *d;
         unsigned int i, max = op->u.max_vcpus.max, cpu;
         cpumask_t *online;
 
-        ret = -ESRCH;
-        if ( (d = rcu_lock_domain_by_id(op->domain)) == NULL )
-            break;
-
         ret = -EINVAL;
         if ( (d == current->domain) || /* no domain_pause() */
              (max > MAX_VIRT_CPUS) ||
              (is_hvm_domain(d) && (max > MAX_HVM_VCPUS)) )
-        {
-            rcu_unlock_domain(d);
             break;
-        }
 
         ret = xsm_max_vcpus(d);
         if ( ret )
-        {
-            rcu_unlock_domain(d);
             break;
-        }
 
         /* Until Xenoprof can dynamically grow its vcpu-s array... */
         if ( d->xenoprof )
         {
-            rcu_unlock_domain(d);
             ret = -EAGAIN;
             break;
         }
@@ -576,44 +551,31 @@ long do_domctl(XEN_GUEST_HANDLE(xen_domctl_t) u_domctl)
 
     maxvcpu_out_novcpulock:
         domain_unpause(d);
-        rcu_unlock_domain(d);
     }
     break;
 
     case XEN_DOMCTL_destroydomain:
     {
-        struct domain *d = rcu_lock_domain_by_id(op->domain);
-        ret = -ESRCH;
-        if ( d != NULL )
-        {
-            ret = xsm_destroydomain(d) ? : domain_kill(d);
-            rcu_unlock_domain(d);
-        }
+        ret = xsm_destroydomain(d) ? : domain_kill(d);
     }
     break;
 
     case XEN_DOMCTL_setvcpuaffinity:
     case XEN_DOMCTL_getvcpuaffinity:
     {
-        domid_t dom = op->domain;
-        struct domain *d = rcu_lock_domain_by_id(dom);
         struct vcpu *v;
 
-        ret = -ESRCH;
-        if ( d == NULL )
-            break;
-
         ret = xsm_vcpuaffinity(op->cmd, d);
         if ( ret )
-            goto vcpuaffinity_out;
+            break;
 
         ret = -EINVAL;
         if ( op->u.vcpuaffinity.vcpu >= d->max_vcpus )
-            goto vcpuaffinity_out;
+            break;
 
         ret = -ESRCH;
         if ( (v = d->vcpu[op->u.vcpuaffinity.vcpu]) == NULL )
-            goto vcpuaffinity_out;
+            break;
 
         if ( op->cmd == XEN_DOMCTL_setvcpuaffinity )
         {
@@ -632,36 +594,23 @@ long do_domctl(XEN_GUEST_HANDLE(xen_domctl_t) u_domctl)
             ret = cpumask_to_xenctl_cpumap(
                 &op->u.vcpuaffinity.cpumap, v->cpu_affinity);
         }
-
-    vcpuaffinity_out:
-        rcu_unlock_domain(d);
     }
     break;
 
     case XEN_DOMCTL_scheduler_op:
     {
-        struct domain *d;
-
-        ret = -ESRCH;
-        if ( (d = rcu_lock_domain_by_id(op->domain)) == NULL )
-            break;
-
         ret = xsm_scheduler(d);
         if ( ret )
-            goto scheduler_op_out;
+            break;
 
         ret = sched_adjust(d, &op->u.scheduler_op);
         if ( copy_to_guest(u_domctl, op, 1) )
             ret = -EFAULT;
-
-    scheduler_op_out:
-        rcu_unlock_domain(d);
     }
     break;
 
     case XEN_DOMCTL_getdomaininfo:
     { 
-        struct domain *d;
         domid_t dom = op->domain;
 
         rcu_read_lock(&domlist_read_lock);
@@ -689,19 +638,15 @@ long do_domctl(XEN_GUEST_HANDLE(xen_domctl_t) u_domctl)
 
     getdomaininfo_out:
         rcu_read_unlock(&domlist_read_lock);
+        d = NULL;
     }
     break;
 
     case XEN_DOMCTL_getvcpucontext:
     { 
         vcpu_guest_context_u c = { .nat = NULL };
-        struct domain       *d;
         struct vcpu         *v;
 
-        ret = -ESRCH;
-        if ( (d = rcu_lock_domain_by_id(op->domain)) == NULL )
-            break;
-
         ret = xsm_getvcpucontext(d);
         if ( ret )
             goto getvcpucontext_out;
@@ -750,31 +695,25 @@ long do_domctl(XEN_GUEST_HANDLE(xen_domctl_t) u_domctl)
 
     getvcpucontext_out:
         xfree(c.nat);
-        rcu_unlock_domain(d);
     }
     break;
 
     case XEN_DOMCTL_getvcpuinfo:
     { 
-        struct domain *d;
         struct vcpu   *v;
         struct vcpu_runstate_info runstate;
 
-        ret = -ESRCH;
-        if ( (d = rcu_lock_domain_by_id(op->domain)) == NULL )
-            break;
-
         ret = xsm_getvcpuinfo(d);
         if ( ret )
-            goto getvcpuinfo_out;
+            break;
 
         ret = -EINVAL;
         if ( op->u.getvcpuinfo.vcpu >= d->max_vcpus )
-            goto getvcpuinfo_out;
+            break;
 
         ret = -ESRCH;
         if ( (v = d->vcpu[op->u.getvcpuinfo.vcpu]) == NULL )
-            goto getvcpuinfo_out;
+            break;
 
         vcpu_runstate_get(v, &runstate);
 
@@ -787,25 +726,16 @@ long do_domctl(XEN_GUEST_HANDLE(xen_domctl_t) u_domctl)
 
         if ( copy_to_guest(u_domctl, op, 1) )
             ret = -EFAULT;
-
-    getvcpuinfo_out:
-        rcu_unlock_domain(d);
     }
     break;
 
     case XEN_DOMCTL_max_mem:
     {
-        struct domain *d;
         unsigned long new_max;
 
-        ret = -ESRCH;
-        d = rcu_lock_domain_by_id(op->domain);
-        if ( d == NULL )
-            break;
-
         ret = xsm_setdomainmaxmem(d);
         if ( ret )
-            goto max_mem_out;
+            break;
 
         ret = -EINVAL;
         new_max = op->u.max_mem.max_memkb >> (PAGE_SHIFT-10);
@@ -819,77 +749,43 @@ long do_domctl(XEN_GUEST_HANDLE(xen_domctl_t) u_domctl)
         d->max_pages = new_max;
         ret = 0;
         spin_unlock(&d->page_alloc_lock);
-
-    max_mem_out:
-        rcu_unlock_domain(d);
     }
     break;
 
     case XEN_DOMCTL_setdomainhandle:
     {
-        struct domain *d;
-
-        ret = -ESRCH;
-        d = rcu_lock_domain_by_id(op->domain);
-        if ( d == NULL )
-            break;
-
         ret = xsm_setdomainhandle(d);
         if ( ret )
-        {
-            rcu_unlock_domain(d);
             break;
-        }
 
         memcpy(d->handle, op->u.setdomainhandle.handle,
                sizeof(xen_domain_handle_t));
-        rcu_unlock_domain(d);
         ret = 0;
     }
     break;
 
     case XEN_DOMCTL_setdebugging:
     {
-        struct domain *d;
-
-        ret = -ESRCH;
-        d = rcu_lock_domain_by_id(op->domain);
-        if ( d == NULL )
-            break;
-
         ret = -EINVAL;
         if ( d == current->domain ) /* no domain_pause() */
-        {
-            rcu_unlock_domain(d);
             break;
-        }
 
         ret = xsm_setdebugging(d);
         if ( ret )
-        {
-            rcu_unlock_domain(d);
             break;
-        }
 
         domain_pause(d);
         d->debugger_attached = !!op->u.setdebugging.enable;
         domain_unpause(d); /* causes guest to latch new status */
-        rcu_unlock_domain(d);
         ret = 0;
     }
     break;
 
     case XEN_DOMCTL_irq_permission:
     {
-        struct domain *d;
         unsigned int pirq = op->u.irq_permission.pirq;
         int allow = op->u.irq_permission.allow_access;
 
-        ret = -ESRCH;
-        d = rcu_lock_domain_by_id(op->domain);
-        if ( d == NULL )
-            break;
-
         if ( pirq >= d->nr_pirqs )
             ret = -EINVAL;
         else if ( xsm_irq_permission(d, pirq, allow) )
@@ -898,14 +794,11 @@ long do_domctl(XEN_GUEST_HANDLE(xen_domctl_t) u_domctl)
             ret = irq_permit_access(d, pirq);
         else
             ret = irq_deny_access(d, pirq);
-
-        rcu_unlock_domain(d);
     }
     break;
 
     case XEN_DOMCTL_iomem_permission:
     {
-        struct domain *d;
         unsigned long mfn = op->u.iomem_permission.first_mfn;
         unsigned long nr_mfns = op->u.iomem_permission.nr_mfns;
         int allow = op->u.iomem_permission.allow_access;
@@ -914,125 +807,78 @@ long do_domctl(XEN_GUEST_HANDLE(xen_domctl_t) u_domctl)
         if ( (mfn + nr_mfns - 1) < mfn ) /* wrap? */
             break;
 
-        ret = -ESRCH;
-        d = rcu_lock_domain_by_id(op->domain);
-        if ( d == NULL )
-            break;
-
         if ( xsm_iomem_permission(d, mfn, mfn + nr_mfns - 1, allow) )
             ret = -EPERM;
         else if ( allow )
             ret = iomem_permit_access(d, mfn, mfn + nr_mfns - 1);
         else
             ret = iomem_deny_access(d, mfn, mfn + nr_mfns - 1);
-
-        rcu_unlock_domain(d);
     }
     break;
 
     case XEN_DOMCTL_settimeoffset:
     {
-        struct domain *d;
-
-        ret = -ESRCH;
-        d = rcu_lock_domain_by_id(op->domain);
-        if ( d == NULL )
-            break;
-
         ret = xsm_domain_settime(d);
         if ( ret )
-        {
-            rcu_unlock_domain(d);
             break;
-        }
 
         domain_set_time_offset(d, op->u.settimeoffset.time_offset_seconds);
-        rcu_unlock_domain(d);
         ret = 0;
     }
     break;
 
     case XEN_DOMCTL_set_target:
     {
-        struct domain *d, *e;
-
-        ret = -ESRCH;
-        d = rcu_lock_domain_by_id(op->domain);
-        if ( d == NULL )
-            break;
+        struct domain *e;
 
         ret = -ESRCH;
         e = get_domain_by_id(op->u.set_target.target);
         if ( e == NULL )
-            goto set_target_out;
+            break;
 
         ret = -EINVAL;
         if ( (d == e) || (d->target != NULL) )
         {
             put_domain(e);
-            goto set_target_out;
+            break;
         }
 
         ret = xsm_set_target(d, e);
         if ( ret ) {
             put_domain(e);
-            goto set_target_out;            
+            break;
         }
 
         /* Hold reference on @e until we destroy @d. */
         d->target = e;
 
         ret = 0;
-
-    set_target_out:
-        rcu_unlock_domain(d);
     }
     break;
 
     case XEN_DOMCTL_subscribe:
     {
-        struct domain *d;
-
-        ret = -ESRCH;
-        d = rcu_lock_domain_by_id(op->domain);
-        if ( d != NULL )
-        {
-            ret = xsm_domctl(d, op->cmd);
-            if ( !ret )
-                d->suspend_evtchn = op->u.subscribe.port;
-            rcu_unlock_domain(d);
-        }
+        ret = xsm_domctl(d, op->cmd);
+        if ( !ret )
+            d->suspend_evtchn = op->u.subscribe.port;
     }
     break;
 
     case XEN_DOMCTL_disable_migrate:
     {
-        struct domain *d;
-        ret = -ESRCH;
-        if ( (d = rcu_lock_domain_by_id(op->domain)) != NULL )
-        {
-            ret = xsm_domctl(d, op->cmd);
-            if ( !ret )
-                d->disable_migrate = op->u.disable_migrate.disable;
-            rcu_unlock_domain(d);
-        }
+        ret = xsm_domctl(d, op->cmd);
+        if ( !ret )
+            d->disable_migrate = op->u.disable_migrate.disable;
     }
     break;
 
     case XEN_DOMCTL_set_virq_handler:
     {
-        struct domain *d;
         uint32_t virq = op->u.set_virq_handler.virq;
 
-        ret = -ESRCH;
-        d = rcu_lock_domain_by_id(op->domain);
-        if ( d != NULL )
-        {
-            ret = xsm_set_virq_handler(d, virq);
-            if ( !ret )
-                ret = set_global_virq_handler(d, virq);
-            rcu_unlock_domain(d);
-        }
+        ret = xsm_set_virq_handler(d, virq);
+        if ( !ret )
+            ret = set_global_virq_handler(d, virq);
     }
     break;
 
@@ -1043,6 +889,10 @@ long do_domctl(XEN_GUEST_HANDLE(xen_domctl_t) u_domctl)
 
     domctl_lock_release();
 
+ domctl_out_unlock:
+    if ( d )
+        rcu_unlock_domain(d);
+
     return ret;
 }
 
-- 
1.7.11.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 17 15:24:29 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 15: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 1TDdBI-0003kx-VB; Mon, 17 Sep 2012 15:24:16 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1TDdBF-0003Zt-E3
	for xen-devel@lists.xen.org; Mon, 17 Sep 2012 15:24:14 +0000
Received: from [85.158.139.211:51923] by server-12.bemta-5.messagelabs.com id
	07/8B-19338-A9047505; Mon, 17 Sep 2012 15:24:10 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-14.tower-206.messagelabs.com!1347895446!18842501!1
X-Originating-IP: [63.239.67.9]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14971 invoked from network); 17 Sep 2012 15:24:06 -0000
Received: from emvm-gh1-uea08.nsa.gov (HELO nsa.gov) (63.239.67.9)
	by server-14.tower-206.messagelabs.com with SMTP;
	17 Sep 2012 15:24:06 -0000
X-TM-IMSS-Message-ID: <53803fb80012ace2@nsa.gov>
Received: from tarius.tycho.ncsc.mil ([144.51.3.1]) by nsa.gov ([63.239.67.9])
	with ESMTP (TREND IMSS SMTP Service 7.1) id 53803fb80012ace2 ;
	Mon, 17 Sep 2012 11:23:46 -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 q8HFO0xh027504; 
	Mon, 17 Sep 2012 11:24:05 -0400
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xen.org
Date: Mon, 17 Sep 2012 11:23:39 -0400
Message-Id: <1347895425-17959-18-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.11.4
In-Reply-To: <1347895425-17959-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1347895425-17959-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: dgdegra@tycho.nsa.gov, keir@xen.org
Subject: [Xen-devel] [PATCH 17/23] xsm/flask: add distinct SIDs for
	self/target 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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Because the FLASK XSM module no longer checks IS_PRIV for remote domain
accesses covered by XSM permissions, domains now have the ability to
perform memory management and other functions on all domains that have
the same type. While it is possible to prevent this by only creating one
domain per type, this solution significantly limits the flexibility of
the type system.

This patch introduces a domain type transition to represent a domain
that is operating on itself. In the example policy, this is demonstrated
by creating a type with _self appended when declaring a domain type
which will be used for reflexive operations. AVCs for a domain of type
domU_t will look like the following:

scontext=system_u:system_r:domU_t tcontext=system_u:system_r:domU_t_self

This change also allows policy to distinguish between event channels a
domain creates to itself and event channels created between domains of
the same type.

The IS_PRIV_FOR check used for device model domains is also no longer
checked by FLASK; a similar transition is performed when the target is
set and used when the device model accesses its target domain.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 docs/misc/xsm-flask.txt                      |  43 ++-
 tools/flask/policy/policy/modules/xen/xen.if |  60 +++-
 tools/flask/policy/policy/modules/xen/xen.te |  13 +-
 xen/xsm/flask/flask_op.c                     |   9 +
 xen/xsm/flask/hooks.c                        | 422 +++++++++++++--------------
 xen/xsm/flask/include/objsec.h               |   2 +
 6 files changed, 307 insertions(+), 242 deletions(-)

diff --git a/docs/misc/xsm-flask.txt b/docs/misc/xsm-flask.txt
index 0778a28..ff81b01 100644
--- a/docs/misc/xsm-flask.txt
+++ b/docs/misc/xsm-flask.txt
@@ -68,9 +68,43 @@ HVM domains with stubdomain device models use two types (one per domain):
  - dm_dom_t is the device model for a domain with type domHVM_t
 
 One disadvantage of using type enforcement to enforce isolation is that a new
-type is needed for each group of domains. In addition, it is not possible to
-allow isolated_domU_t cannot to create loopback event channels without allowing
-two domains of type isolated_domU_t to communicate with one another.
+type is needed for each group of domains. The user field can be used to address
+this for the most common case of groups that can communicate internally but not
+externally; see "Users and roles" below.
+
+Type transitions
+----------------
+
+Xen defines a number of operations such as memory mapping that are necessary for
+a domain to perform on itself, but are also undesirable to allow a domain to
+perform on every other domain of the same label. While it is possible to address
+this by only creating one domain per type, this solution significantly limits
+the flexibility of the type system. Another method to address this issue is to
+duplicate the permission names for every operation that can be performed on the
+current domain or on other domains; however, this significantly increases the
+necessary number of permissions and complicates the XSM hooks. Instead, this is
+addressed by allowing a distinct type to be used for a domain's access to
+itself. The same applies for a device model domain's access to its designated
+target, allowing the IS_PRIV_FOR checks used in Xen's DAC model to be
+implemented in FLASK.
+
+Upon domain creation (or relabel), a type transition is computed using the
+domain's label as the source and target. The result of this computation is used
+as the target when the domain accesses itself. In the example policy, this
+computed type is the result of appending _self to a domain's type: domU_t_self
+for domU_t. If no type transition rule exists, the domain will continue to use
+its own label for both the source and target. An AVC message will look like:
+
+    scontext=system_u:system_r:domU_t tcontext=system_u:system_r:domU_t_self
+
+A similar type transition is done when a device model domain is associated with
+its target using the set_target operation. The transition is computed with the
+target domain as the source and the device model domain as the target: this
+ordering was chosen in order to preserve the original label for the target when
+no type transition rule exists. In the example policy, these computed types are
+the result of appending _target to the domain.
+
+Type transitions are also used to compute the labels of event channels.
 
 Users and roles
 ---------------
@@ -84,7 +118,8 @@ the customer_1 user.
 Access control rules involving users and roles are defined in the policy
 constraints file (tools/flask/policy/policy/constraints). The example policy
 provides constraints that prevent different users from communicating using
-grants or event channels, while still allowing communication with dom0.
+grants or event channels, while still allowing communication with the system_u
+user where dom0 resides.
 
 Resource Policy
 ---------------
diff --git a/tools/flask/policy/policy/modules/xen/xen.if b/tools/flask/policy/policy/modules/xen/xen.if
index 59ba171..d630f47 100644
--- a/tools/flask/policy/policy/modules/xen/xen.if
+++ b/tools/flask/policy/policy/modules/xen/xen.if
@@ -5,15 +5,34 @@
 # Domain creation and setup
 #
 ################################################################################
+define(`declare_domain_common', `
+	allow $1 $2:grant { query setup };
+	allow $1 $2:mmu { adjust physmap map_read map_write stat pinpage updatemp };
+	allow $1 $2:hvm { getparam setparam };
+')
+
 # declare_domain(type, attrs...)
-#   Declare a type as a domain type, and allow basic domain setup
+#   Declare a domain type, along with associated _self and _channel types
+#   Allow the domain to perform basic operations on itself
 define(`declare_domain', `
 	type $1, domain_type`'ifelse(`$#', `1', `', `,shift($@)');
+	type $1_self, domain_type, domain_self_type;
+	type_transition $1 $1:domain $1_self;
+	type $1_channel, event_type;
+	type_transition $1 domain_type:event $1_channel;
+	declare_domain_common($1, $1_self)
+')
+
+# declare_singleton_domain(type, attrs...)
+#   Declare a domain type and associated _channel types.
+#   Note: Because the domain can perform basic operations on itself and any
+#   other domain of the same type, this constructor should be used for types
+#   containing at most one domain. This is not enforced by policy.
+define(`declare_singleton_domain', `
+	type $1, domain_type`'ifelse(`$#', `1', `', `,shift($@)');
 	type $1_channel, event_type;
 	type_transition $1 domain_type:event $1_channel;
-	allow $1 $1:grant { query setup };
-	allow $1 $1:mmu { adjust physmap map_read map_write stat pinpage };
-	allow $1 $1:hvm { getparam setparam };
+	declare_domain_common($1, $1)
 ')
 
 # declare_build_label(type)
@@ -51,6 +70,7 @@ define(`create_domain_build_label', `
 	allow $1 $2_channel:event create;
 	allow $1 $2_building:domain2 relabelfrom;
 	allow $1 $2:domain2 relabelto;
+	allow $2_building $2:domain transition;
 ')
 
 # manage_domain(priv, target)
@@ -101,20 +121,36 @@ define(`domain_comms', `
 ')
 
 # domain_self_comms(domain)
-#   Allow a domain types to communicate with others of its type using grants
-#   and event channels (this includes event channels to DOMID_SELF)
+#   Allow a non-singleton domain type to communicate with itself using grants
+#   and event channels
 define(`domain_self_comms', `
-	create_channel($1, $1, $1_channel)
-	allow $1 $1:grant { map_read map_write copy unmap };
+	create_channel($1, $1_self, $1_channel)
+	allow $1 $1_self:grant { map_read map_write copy unmap };
 ')
 
 # device_model(dm_dom, hvm_dom)
 #   Define how a device model domain interacts with its target
 define(`device_model', `
-	domain_comms($1, $2)
-	allow $1 $2:domain { set_target shutdown };
-	allow $1 $2:mmu { map_read map_write adjust physmap };
-	allow $1 $2:hvm { getparam setparam trackdirtyvram hvmctl irqlevel pciroute cacheattr send_irq };
+	type $2_target, domain_type, domain_target_type;
+	type_transition $2 $1:domain $2_target;
+	allow $1 $2:domain set_target;
+
+	type_transition $2_target domain_type:event $2_channel;
+	create_channel($1, $2_target, $1_channel)
+	create_channel($2, $1, $2_channel)
+	allow $1 $2_channel:event create;
+
+	allow $1 $2_target:domain shutdown;
+	allow $1 $2_target:mmu { map_read map_write adjust physmap };
+	allow $1 $2_target:hvm { getparam setparam trackdirtyvram hvmctl irqlevel pciroute cacheattr send_irq };
+')
+
+# make_device_model(priv, dm_dom, hvm_dom)
+#   Allow creation of a device model and HVM domain pair
+define(`make_device_model', `
+	device_model($2, $3)
+	allow $1 $2:domain2 make_priv_for;
+	allow $1 $3:domain2 set_as_target;
 ')
 ################################################################################
 #
diff --git a/tools/flask/policy/policy/modules/xen/xen.te b/tools/flask/policy/policy/modules/xen/xen.te
index 1162153..8d33285 100644
--- a/tools/flask/policy/policy/modules/xen/xen.te
+++ b/tools/flask/policy/policy/modules/xen/xen.te
@@ -8,6 +8,8 @@
 ################################################################################
 attribute xen_type;
 attribute domain_type;
+attribute domain_self_type;
+attribute domain_target_type;
 attribute resource_type;
 attribute event_type;
 attribute mls_priv;
@@ -25,7 +27,7 @@ attribute mls_priv;
 type xen_t, xen_type, mls_priv;
 
 # Domain 0
-declare_domain(dom0_t, mls_priv);
+declare_singleton_domain(dom0_t, mls_priv);
 
 # Untracked I/O memory (pseudo-domain)
 type domio_t, xen_type;
@@ -69,7 +71,7 @@ admin_device(dom0_t, ioport_t)
 admin_device(dom0_t, iomem_t)
 allow dom0_t domio_t:mmu { map_read map_write };
 
-domain_self_comms(dom0_t)
+domain_comms(dom0_t, dom0_t)
 
 auditallow dom0_t security_t:security { load_policy setenforce setbool };
 
@@ -84,11 +86,14 @@ domain_self_comms(domU_t)
 create_domain(dom0_t, domU_t)
 manage_domain(dom0_t, domU_t)
 domain_comms(dom0_t, domU_t)
+domain_comms(domU_t, domU_t)
+domain_self_comms(domU_t)
 
 declare_domain(isolated_domU_t)
 create_domain(dom0_t, isolated_domU_t)
 manage_domain(dom0_t, isolated_domU_t)
 domain_comms(dom0_t, isolated_domU_t)
+domain_self_comms(isolated_domU_t)
 
 # Declare a boolean that denies creation of prot_domU_t domains
 gen_bool(prot_doms_locked, false)
@@ -98,6 +103,8 @@ if (!prot_doms_locked) {
 }
 domain_comms(dom0_t, prot_domU_t)
 domain_comms(domU_t, prot_domU_t)
+domain_comms(prot_domU_t, prot_domU_t)
+domain_self_comms(prot_domU_t)
 
 # domHVM_t is meant to be paired with a qemu-dm stub domain of type dm_dom_t
 declare_domain(domHVM_t)
@@ -110,7 +117,7 @@ declare_domain(dm_dom_t)
 create_domain(dom0_t, dm_dom_t)
 manage_domain(dom0_t, dm_dom_t)
 domain_comms(dom0_t, dm_dom_t)
-device_model(dm_dom_t, domHVM_t)
+make_device_model(dom0_t, dm_dom_t, domHVM_t)
 
 # nomigrate_t must be built via the nomigrate_t_building label; once built,
 # dom0 cannot read its memory.
diff --git a/xen/xsm/flask/flask_op.c b/xen/xsm/flask/flask_op.c
index 9c8dfe7..f8fc108 100644
--- a/xen/xsm/flask/flask_op.c
+++ b/xen/xsm/flask/flask_op.c
@@ -612,6 +612,15 @@ static int flask_relabel_domain(struct xen_flask_relabel *arg)
         goto out;
 
     dsec->sid = arg->sid;
+    dsec->self_sid = arg->sid;
+    security_transition_sid(dsec->sid, dsec->sid, SECCLASS_DOMAIN,
+                            &dsec->self_sid);
+    if ( d->target )
+    {
+        struct domain_security_struct *tsec = d->target->ssid;
+        security_transition_sid(tsec->sid, dsec->sid, SECCLASS_DOMAIN,
+                                &dsec->target_sid);
+    }
 
  out:
     rcu_unlock_domain(d);
diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
index 089faf8..a242d65 100644
--- a/xen/xsm/flask/hooks.c
+++ b/xen/xsm/flask/hooks.c
@@ -33,38 +33,69 @@
 
 struct xsm_operations *original_ops = NULL;
 
+static u32 domain_sid(struct domain *dom)
+{
+    struct domain_security_struct *dsec = dom->ssid;
+    return dsec->sid;
+}
+
+static u32 domain_target_sid(struct domain *src, struct domain *dst)
+{
+    struct domain_security_struct *ssec = src->ssid;
+    struct domain_security_struct *dsec = dst->ssid;
+    if (src == dst)
+        return ssec->self_sid;
+    if (src->target == dst)
+        return ssec->target_sid;
+    return dsec->sid;
+}
+
+static u32 evtchn_sid(const struct evtchn *chn)
+{
+    struct evtchn_security_struct *esec = chn->ssid;
+    return esec->sid;
+}
+
 static int domain_has_perm(struct domain *dom1, struct domain *dom2, 
                            u16 class, u32 perms)
 {
-    struct domain_security_struct *dsec1, *dsec2;
+    u32 ssid, tsid;
     struct avc_audit_data ad;
     AVC_AUDIT_DATA_INIT(&ad, NONE);
     ad.sdom = dom1;
     ad.tdom = dom2;
 
-    dsec1 = dom1->ssid;
-    dsec2 = dom2->ssid;
+    ssid = domain_sid(dom1);
+    tsid = domain_target_sid(dom1, dom2);
 
-    return avc_has_perm(dsec1->sid, dsec2->sid, class, perms, &ad);
+    return avc_has_perm(ssid, tsid, class, perms, &ad);
 }
 
-static int domain_has_evtchn(struct domain *d, struct evtchn *chn, u32 perms)
+static int avc_current_has_perm(u32 tsid, u16 class, u32 perm,
+                                struct avc_audit_data *ad)
 {
-    struct domain_security_struct *dsec;
-    struct evtchn_security_struct *esec;
+    u32 csid = domain_sid(current->domain);
+    return avc_has_perm(csid, tsid, class, perm, ad);
+}
 
-    dsec = d->ssid;
-    esec = chn->ssid;
+static int current_has_perm(struct domain *d, u16 class, u32 perms)
+{
+    return domain_has_perm(current->domain, d, class, perms);
+}
 
-    return avc_has_perm(dsec->sid, esec->sid, SECCLASS_EVENT, perms, NULL);
+static int domain_has_evtchn(struct domain *d, struct evtchn *chn, u32 perms)
+{
+    u32 dsid = domain_sid(d);
+    u32 esid = evtchn_sid(chn);
+
+    return avc_has_perm(dsid, esid, SECCLASS_EVENT, perms, NULL);
 }
 
 static int domain_has_xen(struct domain *d, u32 perms)
 {
-    struct domain_security_struct *dsec;
-    dsec = d->ssid;
+    u32 dsid = domain_sid(d);
 
-    return avc_has_perm(dsec->sid, SECINITSID_XEN, SECCLASS_XEN, perms, NULL);
+    return avc_has_perm(dsid, SECINITSID_XEN, SECCLASS_XEN, perms, NULL);
 }
 
 static int get_irq_sid(int irq, u32 *sid, struct avc_audit_data *ad)
@@ -123,6 +154,7 @@ static int flask_domain_alloc_security(struct domain *d)
         dsec->sid = SECINITSID_UNLABELED;
     }
 
+    dsec->self_sid = dsec->sid;
     d->ssid = dsec;
 
     return 0;
@@ -142,68 +174,55 @@ static void flask_domain_free_security(struct domain *d)
 static int flask_evtchn_unbound(struct domain *d1, struct evtchn *chn, 
                                 domid_t id2)
 {
-    u32 newsid;
+    u32 sid1, sid2, newsid;
     int rc;
-    domid_t id;
     struct domain *d2;
-    struct domain_security_struct *dsec, *dsec1, *dsec2;
     struct evtchn_security_struct *esec;
 
-    dsec = current->domain->ssid;
-    dsec1 = d1->ssid;
-    esec = chn->ssid;
-
-    if ( id2 == DOMID_SELF )
-        id = current->domain->domain_id;
-    else
-        id = id2;
-
-    d2 = get_domain_by_id(id);
+    d2 = rcu_lock_domain_by_any_id(id2);
     if ( d2 == NULL )
         return -EPERM;
 
-    dsec2 = d2->ssid;
-    rc = security_transition_sid(dsec1->sid, dsec2->sid, SECCLASS_EVENT, 
-                                 &newsid);
+    sid1 = domain_sid(d1);
+    sid2 = domain_target_sid(d1, d2);
+    esec = chn->ssid;
+
+    rc = security_transition_sid(sid1, sid2, SECCLASS_EVENT, &newsid);
     if ( rc )
         goto out;
 
-    rc = avc_has_perm(dsec->sid, newsid, SECCLASS_EVENT, EVENT__CREATE, NULL);
+    rc = avc_current_has_perm(newsid, SECCLASS_EVENT, EVENT__CREATE, NULL);
     if ( rc )
         goto out;
 
-    rc = avc_has_perm(newsid, dsec2->sid, SECCLASS_EVENT, EVENT__BIND, NULL);
+    rc = avc_has_perm(newsid, sid2, SECCLASS_EVENT, EVENT__BIND, NULL);
     if ( rc )
         goto out;
-    else
-        esec->sid = newsid;
+
+    esec->sid = newsid;
 
  out:
-    put_domain(d2);
+    rcu_unlock_domain(d2);
     return rc;
 }
 
 static int flask_evtchn_interdomain(struct domain *d1, struct evtchn *chn1, 
                                     struct domain *d2, struct evtchn *chn2)
 {
-    u32 newsid;
+    u32 sid1, sid2, newsid, reverse_sid;
     int rc;
-    struct domain_security_struct *dsec, *dsec1, *dsec2;
-    struct evtchn_security_struct *esec1, *esec2;
+    struct evtchn_security_struct *esec1;
     struct avc_audit_data ad;
     AVC_AUDIT_DATA_INIT(&ad, NONE);
     ad.sdom = d1;
     ad.tdom = d2;
 
-    dsec = current->domain->ssid;
-    dsec1 = d1->ssid;
-    dsec2 = d2->ssid;
+    sid1 = domain_sid(d1);
+    sid2 = domain_target_sid(d1, d2);
 
     esec1 = chn1->ssid;
-    esec2 = chn2->ssid;
 
-    rc = security_transition_sid(dsec1->sid, dsec2->sid, 
-                                 SECCLASS_EVENT, &newsid);
+    rc = security_transition_sid(sid1, sid2, SECCLASS_EVENT, &newsid);
     if ( rc )
     {
         printk("%s: security_transition_sid failed, rc=%d (domain=%d)\n",
@@ -211,15 +230,20 @@ static int flask_evtchn_interdomain(struct domain *d1, struct evtchn *chn1,
         return rc;
     }
 
-    rc = avc_has_perm(dsec->sid, newsid, SECCLASS_EVENT, EVENT__CREATE, &ad);
+    rc = avc_current_has_perm(newsid, SECCLASS_EVENT, EVENT__CREATE, &ad);
     if ( rc )
         return rc;
 
-    rc = avc_has_perm(newsid, dsec2->sid, SECCLASS_EVENT, EVENT__BIND, &ad);
+    rc = avc_has_perm(newsid, sid2, SECCLASS_EVENT, EVENT__BIND, &ad);
     if ( rc )
         return rc;
 
-    rc = avc_has_perm(esec2->sid, dsec1->sid, SECCLASS_EVENT, EVENT__BIND, &ad);
+    /* It's possible the target domain has changed (relabel or destroy/create)
+     * since the unbound part was created; re-validate this binding now.
+     */
+    reverse_sid = evtchn_sid(chn2);
+    sid1 = domain_target_sid(d2, d1);
+    rc = avc_has_perm(reverse_sid, sid1, SECCLASS_EVENT, EVENT__BIND, &ad);
     if ( rc )
         return rc;
 
@@ -302,7 +326,6 @@ static void flask_free_security_evtchn(struct evtchn *chn)
 
 static char *flask_show_security_evtchn(struct domain *d, const struct evtchn *chn)
 {
-    struct evtchn_security_struct *esec;
     int irq;
     u32 sid = 0;
     char *ctx;
@@ -312,9 +335,7 @@ static char *flask_show_security_evtchn(struct domain *d, const struct evtchn *c
     {
     case ECS_UNBOUND:
     case ECS_INTERDOMAIN:
-        esec = chn->ssid;
-        if ( esec )
-            sid = esec->sid;
+        sid = evtchn_sid(chn);
         break;
     case ECS_PIRQ:
         irq = domain_pirq_to_irq(d, chn->u.pirq.irq);
@@ -367,12 +388,12 @@ static int flask_grant_query_size(struct domain *d1, struct domain *d2)
 
 static int flask_get_pod_target(struct domain *d)
 {
-    return domain_has_perm(current->domain, d, SECCLASS_DOMAIN, DOMAIN__GETPODTARGET);
+    return current_has_perm(d, SECCLASS_DOMAIN, DOMAIN__GETPODTARGET);
 }
 
 static int flask_set_pod_target(struct domain *d)
 {
-    return domain_has_perm(current->domain, d, SECCLASS_DOMAIN, DOMAIN__SETPODTARGET);
+    return current_has_perm(d, SECCLASS_DOMAIN, DOMAIN__SETPODTARGET);
 }
 
 static int flask_memory_adjust_reservation(struct domain *d1, struct domain *d2)
@@ -455,70 +476,65 @@ static int flask_schedop_shutdown(struct domain *d1, struct domain *d2)
 static void flask_security_domaininfo(struct domain *d, 
                                       struct xen_domctl_getdomaininfo *info)
 {
-    struct domain_security_struct *dsec;
-
-    dsec = d->ssid;
-    info->ssidref = dsec->sid;
+    info->ssidref = domain_sid(d);
 }
 
 static int flask_setvcpucontext(struct domain *d)
 {
-    return domain_has_perm(current->domain, d, SECCLASS_DOMAIN, 
-                           DOMAIN__SETVCPUCONTEXT);
+    return current_has_perm(d, SECCLASS_DOMAIN, DOMAIN__SETVCPUCONTEXT);
 }
 
 static int flask_pausedomain(struct domain *d)
 {
-    return domain_has_perm(current->domain, d, SECCLASS_DOMAIN, DOMAIN__PAUSE);
+    return current_has_perm(d, SECCLASS_DOMAIN, DOMAIN__PAUSE);
 }
 
 static int flask_unpausedomain(struct domain *d)
 {
-    return domain_has_perm(current->domain, d, SECCLASS_DOMAIN, DOMAIN__UNPAUSE);
+    return current_has_perm(d, SECCLASS_DOMAIN, DOMAIN__UNPAUSE);
 }
 
 static int flask_resumedomain(struct domain *d)
 {
-    return domain_has_perm(current->domain, d, SECCLASS_DOMAIN, DOMAIN__RESUME);
+    return current_has_perm(d, SECCLASS_DOMAIN, DOMAIN__RESUME);
 }
 
 static int flask_domain_create(struct domain *d, u32 ssidref)
 {
     int rc;
-    struct domain_security_struct *dsec1;
-    struct domain_security_struct *dsec2;
+    struct domain_security_struct *dsec = d->ssid;
     static int dom0_created = 0;
 
-    dsec1 = current->domain->ssid;
-    dsec2 = d->ssid;
-
     if ( is_idle_domain(current->domain) && !dom0_created )
     {
-        dsec2->sid = SECINITSID_DOM0;
+        dsec->sid = SECINITSID_DOM0;
         dom0_created = 1;
-        return 0;
     }
+    else
+    {
+        rc = avc_current_has_perm(ssidref, SECCLASS_DOMAIN,
+                          DOMAIN__CREATE, NULL);
+        if ( rc )
+            return rc;
 
-    rc = avc_has_perm(dsec1->sid, ssidref, SECCLASS_DOMAIN,
-                      DOMAIN__CREATE, NULL);
-    if ( rc )
-        return rc;
+        dsec->sid = ssidref;
+    }
+    dsec->self_sid = dsec->sid;
 
-    dsec2->sid = ssidref;
+    rc = security_transition_sid(dsec->sid, dsec->sid, SECCLASS_DOMAIN,
+                                 &dsec->self_sid);
 
     return rc;
 }
 
 static int flask_max_vcpus(struct domain *d)
 {
-    return domain_has_perm(current->domain, d, SECCLASS_DOMAIN, 
-                           DOMAIN__MAX_VCPUS);
+    return current_has_perm(d, SECCLASS_DOMAIN, DOMAIN__MAX_VCPUS);
 }
 
 static int flask_destroydomain(struct domain *d)
 {
-    return domain_has_perm(current->domain, d, SECCLASS_DOMAIN, 
-                           DOMAIN__DESTROY);
+    return current_has_perm(d, SECCLASS_DOMAIN, DOMAIN__DESTROY);
 }
 
 static int flask_vcpuaffinity(int cmd, struct domain *d)
@@ -537,7 +553,7 @@ static int flask_vcpuaffinity(int cmd, struct domain *d)
         return -EPERM;
     }
 
-    return domain_has_perm(current->domain, d, SECCLASS_DOMAIN, perm );
+    return current_has_perm(d, SECCLASS_DOMAIN, perm );
 }
 
 static int flask_scheduler(struct domain *d)
@@ -548,43 +564,51 @@ static int flask_scheduler(struct domain *d)
     if ( rc )
         return rc;
 
-    return domain_has_perm(current->domain, d, SECCLASS_DOMAIN, 
-                           DOMAIN__SCHEDULER);
+    return current_has_perm(d, SECCLASS_DOMAIN, DOMAIN__SCHEDULER);
 }
 
 static int flask_getdomaininfo(struct domain *d)
 {
-    return domain_has_perm(current->domain, d, SECCLASS_DOMAIN,
-                           DOMAIN__GETDOMAININFO);
+    return current_has_perm(d, SECCLASS_DOMAIN, DOMAIN__GETDOMAININFO);
 }
 
 static int flask_getvcpucontext(struct domain *d)
 {
-    return domain_has_perm(current->domain, d, SECCLASS_DOMAIN, 
-                           DOMAIN__GETVCPUCONTEXT);
+    return current_has_perm(d, SECCLASS_DOMAIN, DOMAIN__GETVCPUCONTEXT);
 }
 
 static int flask_getvcpuinfo(struct domain *d)
 {
-    return domain_has_perm(current->domain, d, SECCLASS_DOMAIN,
-                           DOMAIN__GETVCPUINFO);
+    return current_has_perm(d, SECCLASS_DOMAIN, DOMAIN__GETVCPUINFO);
 }
 
 static int flask_domain_settime(struct domain *d)
 {
-    return domain_has_perm(current->domain, d, SECCLASS_DOMAIN, DOMAIN__SETTIME);
+    return current_has_perm(d, SECCLASS_DOMAIN, DOMAIN__SETTIME);
 }
 
-static int flask_set_target(struct domain *d, struct domain *e)
+static int flask_set_target(struct domain *d, struct domain *t)
 {
     int rc;
-    rc = domain_has_perm(current->domain, d, SECCLASS_DOMAIN2, DOMAIN2__MAKE_PRIV_FOR);
+    struct domain_security_struct *dsec, *tsec;
+    dsec = d->ssid;
+    tsec = t->ssid;
+
+    rc = current_has_perm(d, SECCLASS_DOMAIN2, DOMAIN2__MAKE_PRIV_FOR);
     if ( rc )
         return rc;
-    rc = domain_has_perm(current->domain, e, SECCLASS_DOMAIN2, DOMAIN2__SET_AS_TARGET);
+    rc = current_has_perm(t, SECCLASS_DOMAIN2, DOMAIN2__SET_AS_TARGET);
     if ( rc )
         return rc;
-    return domain_has_perm(d, e, SECCLASS_DOMAIN, DOMAIN__SET_TARGET);
+    /* Use avc_has_perm to avoid resolving target/current SID */
+    rc = avc_has_perm(dsec->sid, tsec->sid, SECCLASS_DOMAIN, DOMAIN__SET_TARGET, NULL);
+    if ( rc )
+        return rc;
+
+    /* (tsec, dsec) defaults the label to tsec, as it should here */
+    rc = security_transition_sid(tsec->sid, dsec->sid, SECCLASS_DOMAIN,
+                                 &dsec->target_sid);
+    return rc;
 }
 
 static int flask_domctl(struct domain *d, int cmd)
@@ -655,26 +679,24 @@ static int flask_domctl(struct domain *d, int cmd)
     case XEN_DOMCTL_gdbsx_pausevcpu:
     case XEN_DOMCTL_gdbsx_unpausevcpu:
     case XEN_DOMCTL_gdbsx_domstatus:
-        return domain_has_perm(current->domain, d, SECCLASS_DOMAIN,
-                               DOMAIN__SETDEBUGGING);
+        return current_has_perm(d, SECCLASS_DOMAIN, DOMAIN__SETDEBUGGING);
 
     case XEN_DOMCTL_subscribe:
     case XEN_DOMCTL_disable_migrate:
     case XEN_DOMCTL_suppress_spurious_page_faults:
-        return domain_has_perm(current->domain, d, SECCLASS_DOMAIN,
-                               DOMAIN__SET_MISC_INFO);
+        return current_has_perm(d, SECCLASS_DOMAIN, DOMAIN__SET_MISC_INFO);
 
     case XEN_DOMCTL_set_cpuid:
-        return domain_has_perm(current->domain, d, SECCLASS_DOMAIN2, DOMAIN2__SET_CPUID);
+        return current_has_perm(d, SECCLASS_DOMAIN2, DOMAIN2__SET_CPUID);
 
     case XEN_DOMCTL_gettscinfo:
-        return domain_has_perm(current->domain, d, SECCLASS_DOMAIN2, DOMAIN2__GETTSC);
+        return current_has_perm(d, SECCLASS_DOMAIN2, DOMAIN2__GETTSC);
 
     case XEN_DOMCTL_settscinfo:
-        return domain_has_perm(current->domain, d, SECCLASS_DOMAIN2, DOMAIN2__SETTSC);
+        return current_has_perm(d, SECCLASS_DOMAIN2, DOMAIN2__SETTSC);
 
     case XEN_DOMCTL_audit_p2m:
-        return domain_has_perm(current->domain, d, SECCLASS_HVM, HVM__AUDIT_P2M);
+        return current_has_perm(d, SECCLASS_HVM, HVM__AUDIT_P2M);
 
     default:
         printk("flask_domctl: Unknown op %d\n", cmd);
@@ -716,7 +738,7 @@ static int flask_sysctl(int cmd)
 
 static int flask_set_virq_handler(struct domain *d, uint32_t virq)
 {
-    return domain_has_perm(current->domain, d, SECCLASS_DOMAIN, DOMAIN__SET_VIRQ_HANDLER);
+    return current_has_perm(d, SECCLASS_DOMAIN, DOMAIN__SET_VIRQ_HANDLER);
 }
 
 static int flask_tbufcontrol(void)
@@ -741,20 +763,17 @@ static int flask_sched_id(void)
 
 static int flask_setdomainmaxmem(struct domain *d)
 {
-    return domain_has_perm(current->domain, d, SECCLASS_DOMAIN,
-                           DOMAIN__SETDOMAINMAXMEM);
+    return current_has_perm(d, SECCLASS_DOMAIN, DOMAIN__SETDOMAINMAXMEM);
 }
 
 static int flask_setdomainhandle(struct domain *d)
 {
-    return domain_has_perm(current->domain, d, SECCLASS_DOMAIN,
-                           DOMAIN__SETDOMAINHANDLE);
+    return current_has_perm(d, SECCLASS_DOMAIN, DOMAIN__SETDOMAINHANDLE);
 }
 
 static int flask_setdebugging(struct domain *d)
 {
-    return domain_has_perm(current->domain, d, SECCLASS_DOMAIN,
-                           DOMAIN__SETDEBUGGING);
+    return current_has_perm(d, SECCLASS_DOMAIN, DOMAIN__SETDEBUGGING);
 }
 
 static int flask_debug_keys(void)
@@ -816,14 +835,12 @@ static char *flask_show_irq_sid (int irq)
 
 static int flask_map_domain_pirq (struct domain *d, int irq, void *data)
 {
-    u32 sid;
+    u32 sid, dsid;
     int rc = -EPERM;
     struct msi_info *msi = data;
-
-    struct domain_security_struct *ssec, *tsec;
     struct avc_audit_data ad;
 
-    rc = domain_has_perm(current->domain, d, SECCLASS_RESOURCE, RESOURCE__ADD);
+    rc = current_has_perm(d, SECCLASS_RESOURCE, RESOURCE__ADD);
 
     if ( rc )
         return rc;
@@ -839,14 +856,13 @@ static int flask_map_domain_pirq (struct domain *d, int irq, void *data)
     if ( rc )
         return rc;
 
-    ssec = current->domain->ssid;
-    tsec = d->ssid;
+    dsid = domain_sid(d);
 
-    rc = avc_has_perm(ssec->sid, sid, SECCLASS_RESOURCE, RESOURCE__ADD_IRQ, &ad);
+    rc = avc_current_has_perm(sid, SECCLASS_RESOURCE, RESOURCE__ADD_IRQ, &ad);
     if ( rc )
         return rc;
 
-    rc = avc_has_perm(tsec->sid, sid, SECCLASS_RESOURCE, RESOURCE__USE, &ad);
+    rc = avc_has_perm(dsid, sid, SECCLASS_RESOURCE, RESOURCE__USE, &ad);
     return rc;
 }
 
@@ -854,16 +870,12 @@ static int flask_unmap_domain_pirq (struct domain *d, int irq)
 {
     u32 sid;
     int rc = -EPERM;
-
-    struct domain_security_struct *ssec;
     struct avc_audit_data ad;
 
-    rc = domain_has_perm(current->domain, d, SECCLASS_RESOURCE, RESOURCE__REMOVE);
+    rc = current_has_perm(d, SECCLASS_RESOURCE, RESOURCE__REMOVE);
     if ( rc )
         return rc;
 
-    ssec = current->domain->ssid;
-
     if ( irq >= nr_irqs_gsi ) {
         /* TODO support for MSI here */
         return 0;
@@ -873,19 +885,19 @@ static int flask_unmap_domain_pirq (struct domain *d, int irq)
     if ( rc )
         return rc;
 
-    rc = avc_has_perm(ssec->sid, sid, SECCLASS_RESOURCE, RESOURCE__REMOVE_IRQ, &ad);
+    rc = avc_current_has_perm(sid, SECCLASS_RESOURCE, RESOURCE__REMOVE_IRQ, &ad);
     return rc;
 }
 
 static int flask_irq_permission (struct domain *d, int pirq, uint8_t access)
 {
     /* the PIRQ number is not useful; real IRQ is checked during mapping */
-    return domain_has_perm(current->domain, d, SECCLASS_RESOURCE,
-                           resource_to_perm(access));
+    return current_has_perm(d, SECCLASS_RESOURCE, resource_to_perm(access));
 }
 
 struct iomem_has_perm_data {
-    struct domain_security_struct *ssec, *tsec;
+    u32 ssid;
+    u32 dsid;
     u32 perm;
 };
 
@@ -899,12 +911,12 @@ static int _iomem_has_perm(void *v, u32 sid, unsigned long start, unsigned long
     ad.range.start = start;
     ad.range.end = end;
 
-    rc = avc_has_perm(data->ssec->sid, sid, SECCLASS_RESOURCE, data->perm, &ad);
+    rc = avc_has_perm(data->ssid, sid, SECCLASS_RESOURCE, data->perm, &ad);
 
     if ( rc )
         return rc;
 
-    return avc_has_perm(data->tsec->sid, sid, SECCLASS_RESOURCE, RESOURCE__USE, &ad);
+    return avc_has_perm(data->dsid, sid, SECCLASS_RESOURCE, RESOURCE__USE, &ad);
 }
 
 static int flask_iomem_permission(struct domain *d, uint64_t start, uint64_t end, uint8_t access)
@@ -912,7 +924,7 @@ static int flask_iomem_permission(struct domain *d, uint64_t start, uint64_t end
     struct iomem_has_perm_data data;
     int rc;
 
-    rc = domain_has_perm(current->domain, d, SECCLASS_RESOURCE,
+    rc = current_has_perm(d, SECCLASS_RESOURCE,
                          resource_to_perm(access));
     if ( rc )
         return rc;
@@ -922,8 +934,8 @@ static int flask_iomem_permission(struct domain *d, uint64_t start, uint64_t end
     else
         data.perm = RESOURCE__REMOVE_IOMEM;
 
-    data.ssec = current->domain->ssid;
-    data.tsec = d->ssid;
+    data.ssid = domain_sid(current->domain);
+    data.dsid = domain_sid(d);
 
     return security_iterate_iomem_sids(start, end, _iomem_has_perm, &data);
 }
@@ -935,10 +947,9 @@ static int flask_iomem_mapping(struct domain *d, uint64_t start, uint64_t end, u
 
 static int flask_pci_config_permission(struct domain *d, uint32_t machine_bdf, uint16_t start, uint16_t end, uint8_t access)
 {
-    u32 rsid;
+    u32 dsid, rsid;
     int rc = -EPERM;
     struct avc_audit_data ad;
-    struct domain_security_struct *ssec;
     u32 perm = RESOURCE__USE;
 
     rc = security_device_sid(machine_bdf, &rsid);
@@ -951,33 +962,24 @@ static int flask_pci_config_permission(struct domain *d, uint32_t machine_bdf, u
 
     AVC_AUDIT_DATA_INIT(&ad, DEV);
     ad.device = (unsigned long) machine_bdf;
-    ssec = d->ssid;
-    return avc_has_perm(ssec->sid, rsid, SECCLASS_RESOURCE, perm, &ad);
+    dsid = domain_sid(d);
+    return avc_has_perm(dsid, rsid, SECCLASS_RESOURCE, perm, &ad);
 
 }
 
 static int flask_resource_plug_core(void)
 {
-    struct domain_security_struct *ssec;
-
-    ssec = current->domain->ssid;
-    return avc_has_perm(ssec->sid, SECINITSID_DOMXEN, SECCLASS_RESOURCE, RESOURCE__PLUG, NULL);
+    return avc_current_has_perm(SECINITSID_DOMXEN, SECCLASS_RESOURCE, RESOURCE__PLUG, NULL);
 }
 
 static int flask_resource_unplug_core(void)
 {
-    struct domain_security_struct *ssec;
-
-    ssec = current->domain->ssid;
-    return avc_has_perm(ssec->sid, SECINITSID_DOMXEN, SECCLASS_RESOURCE, RESOURCE__UNPLUG, NULL);
+    return avc_current_has_perm(SECINITSID_DOMXEN, SECCLASS_RESOURCE, RESOURCE__UNPLUG, NULL);
 }
 
 static int flask_resource_use_core(void)
 {
-    struct domain_security_struct *ssec;
-
-    ssec = current->domain->ssid;
-    return avc_has_perm(ssec->sid, SECINITSID_DOMXEN, SECCLASS_RESOURCE, RESOURCE__USE, NULL);
+    return avc_current_has_perm(SECINITSID_DOMXEN, SECCLASS_RESOURCE, RESOURCE__USE, NULL);
 }
 
 static int flask_resource_plug_pci(uint32_t machine_bdf)
@@ -985,7 +987,6 @@ static int flask_resource_plug_pci(uint32_t machine_bdf)
     u32 rsid;
     int rc = -EPERM;
     struct avc_audit_data ad;
-    struct domain_security_struct *ssec;
 
     rc = security_device_sid(machine_bdf, &rsid);
     if ( rc )
@@ -993,8 +994,7 @@ static int flask_resource_plug_pci(uint32_t machine_bdf)
 
     AVC_AUDIT_DATA_INIT(&ad, DEV);
     ad.device = (unsigned long) machine_bdf;
-    ssec = current->domain->ssid;
-    return avc_has_perm(ssec->sid, rsid, SECCLASS_RESOURCE, RESOURCE__PLUG, &ad);
+    return avc_current_has_perm(rsid, SECCLASS_RESOURCE, RESOURCE__PLUG, &ad);
 }
 
 static int flask_resource_unplug_pci(uint32_t machine_bdf)
@@ -1002,7 +1002,6 @@ static int flask_resource_unplug_pci(uint32_t machine_bdf)
     u32 rsid;
     int rc = -EPERM;
     struct avc_audit_data ad;
-    struct domain_security_struct *ssec;
 
     rc = security_device_sid(machine_bdf, &rsid);
     if ( rc )
@@ -1010,8 +1009,7 @@ static int flask_resource_unplug_pci(uint32_t machine_bdf)
 
     AVC_AUDIT_DATA_INIT(&ad, DEV);
     ad.device = (unsigned long) machine_bdf;
-    ssec = current->domain->ssid;
-    return avc_has_perm(ssec->sid, rsid, SECCLASS_RESOURCE, RESOURCE__UNPLUG, &ad);
+    return avc_current_has_perm(rsid, SECCLASS_RESOURCE, RESOURCE__UNPLUG, &ad);
 }
 
 static int flask_resource_setup_pci(uint32_t machine_bdf)
@@ -1019,7 +1017,6 @@ static int flask_resource_setup_pci(uint32_t machine_bdf)
     u32 rsid;
     int rc = -EPERM;
     struct avc_audit_data ad;
-    struct domain_security_struct *ssec;
 
     rc = security_device_sid(machine_bdf, &rsid);
     if ( rc )
@@ -1027,8 +1024,7 @@ static int flask_resource_setup_pci(uint32_t machine_bdf)
 
     AVC_AUDIT_DATA_INIT(&ad, DEV);
     ad.device = (unsigned long) machine_bdf;
-    ssec = current->domain->ssid;
-    return avc_has_perm(ssec->sid, rsid, SECCLASS_RESOURCE, RESOURCE__SETUP, &ad);
+    return avc_current_has_perm(rsid, SECCLASS_RESOURCE, RESOURCE__SETUP, &ad);
 }
 
 static int flask_resource_setup_gsi(int gsi)
@@ -1036,22 +1032,17 @@ static int flask_resource_setup_gsi(int gsi)
     u32 rsid;
     int rc = -EPERM;
     struct avc_audit_data ad;
-    struct domain_security_struct *ssec;
 
     rc = get_irq_sid(gsi, &rsid, &ad);
     if ( rc )
         return rc;
 
-    ssec = current->domain->ssid;
-    return avc_has_perm(ssec->sid, rsid, SECCLASS_RESOURCE, RESOURCE__SETUP, &ad);
+    return avc_current_has_perm(rsid, SECCLASS_RESOURCE, RESOURCE__SETUP, &ad);
 }
 
 static int flask_resource_setup_misc(void)
 {
-    struct domain_security_struct *ssec;
-
-    ssec = current->domain->ssid;
-    return avc_has_perm(ssec->sid, SECINITSID_XEN, SECCLASS_RESOURCE, RESOURCE__SETUP, NULL);
+    return avc_current_has_perm(SECINITSID_XEN, SECCLASS_RESOURCE, RESOURCE__SETUP, NULL);
 }
 
 static inline int flask_page_offline(uint32_t cmd)
@@ -1114,11 +1105,12 @@ static int flask_shadow_control(struct domain *d, uint32_t op)
         return -EPERM;
     }
 
-    return domain_has_perm(current->domain, d, SECCLASS_SHADOW, perm);
+    return current_has_perm(d, SECCLASS_SHADOW, perm);
 }
 
 struct ioport_has_perm_data {
-    struct domain_security_struct *ssec, *tsec;
+    u32 ssid;
+    u32 dsid;
     u32 perm;
 };
 
@@ -1132,12 +1124,12 @@ static int _ioport_has_perm(void *v, u32 sid, unsigned long start, unsigned long
     ad.range.start = start;
     ad.range.end = end;
 
-    rc = avc_has_perm(data->ssec->sid, sid, SECCLASS_RESOURCE, data->perm, &ad);
+    rc = avc_has_perm(data->ssid, sid, SECCLASS_RESOURCE, data->perm, &ad);
 
     if ( rc )
         return rc;
 
-    return avc_has_perm(data->tsec->sid, sid, SECCLASS_RESOURCE, RESOURCE__USE, &ad);
+    return avc_has_perm(data->dsid, sid, SECCLASS_RESOURCE, RESOURCE__USE, &ad);
 }
 
 static int flask_ioport_permission(struct domain *d, uint32_t start, uint32_t end, uint8_t access)
@@ -1145,7 +1137,7 @@ static int flask_ioport_permission(struct domain *d, uint32_t start, uint32_t en
     int rc;
     struct ioport_has_perm_data data;
 
-    rc = domain_has_perm(current->domain, d, SECCLASS_RESOURCE,
+    rc = current_has_perm(d, SECCLASS_RESOURCE,
                          resource_to_perm(access));
 
     if ( rc )
@@ -1156,8 +1148,8 @@ static int flask_ioport_permission(struct domain *d, uint32_t start, uint32_t en
     else
         data.perm = RESOURCE__REMOVE_IOPORT;
 
-    data.ssec = current->domain->ssid;
-    data.tsec = d->ssid;
+    data.ssid = domain_sid(current->domain);
+    data.dsid = domain_sid(d);
 
     return security_iterate_ioport_sids(start, end, _ioport_has_perm, &data);
 }
@@ -1169,18 +1161,17 @@ static int flask_ioport_mapping(struct domain *d, uint32_t start, uint32_t end,
 
 static int flask_getpageframeinfo(struct domain *d)
 {
-    return domain_has_perm(current->domain, d, SECCLASS_MMU, MMU__PAGEINFO);
+    return current_has_perm(d, SECCLASS_MMU, MMU__PAGEINFO);
 }
 
 static int flask_getmemlist(struct domain *d)
 {
-    return domain_has_perm(current->domain, d, SECCLASS_MMU, MMU__PAGELIST);
+    return current_has_perm(d, SECCLASS_MMU, MMU__PAGELIST);
 }
 
 static int flask_hypercall_init(struct domain *d)
 {
-    return domain_has_perm(current->domain, d, SECCLASS_DOMAIN,
-                           DOMAIN__HYPERCALL);
+    return current_has_perm(d, SECCLASS_DOMAIN, DOMAIN__HYPERCALL);
 }
 
 static int flask_hvmcontext(struct domain *d, uint32_t cmd)
@@ -1203,7 +1194,7 @@ static int flask_hvmcontext(struct domain *d, uint32_t cmd)
         return -EPERM;
     }
 
-    return domain_has_perm(current->domain, d, SECCLASS_HVM, perm);
+    return current_has_perm(d, SECCLASS_HVM, perm);
 }
 
 static int flask_address_size(struct domain *d, uint32_t cmd)
@@ -1222,7 +1213,7 @@ static int flask_address_size(struct domain *d, uint32_t cmd)
         return -EPERM;
     }
 
-    return domain_has_perm(current->domain, d, SECCLASS_DOMAIN, perm);
+    return current_has_perm(d, SECCLASS_DOMAIN, perm);
 }
 
 static int flask_machine_address_size(struct domain *d, uint32_t cmd)
@@ -1263,37 +1254,37 @@ static int flask_hvm_param(struct domain *d, unsigned long op)
         perm = HVM__HVMCTL;
     }
 
-    return domain_has_perm(current->domain, d, SECCLASS_HVM, perm);
+    return current_has_perm(d, SECCLASS_HVM, perm);
 }
 
 static int flask_hvm_set_pci_intx_level(struct domain *d)
 {
-    return domain_has_perm(current->domain, d, SECCLASS_HVM, HVM__PCILEVEL);
+    return current_has_perm(d, SECCLASS_HVM, HVM__PCILEVEL);
 }
 
 static int flask_hvm_set_isa_irq_level(struct domain *d)
 {
-    return domain_has_perm(current->domain, d, SECCLASS_HVM, HVM__IRQLEVEL);
+    return current_has_perm(d, SECCLASS_HVM, HVM__IRQLEVEL);
 }
 
 static int flask_hvm_set_pci_link_route(struct domain *d)
 {
-    return domain_has_perm(current->domain, d, SECCLASS_HVM, HVM__PCIROUTE);
+    return current_has_perm(d, SECCLASS_HVM, HVM__PCIROUTE);
 }
 
 static int flask_hvm_inject_msi(struct domain *d)
 {
-    return domain_has_perm(current->domain, d, SECCLASS_HVM, HVM__SEND_IRQ);
+    return current_has_perm(d, SECCLASS_HVM, HVM__SEND_IRQ);
 }
 
 static int flask_mem_event(struct domain *d)
 {
-    return domain_has_perm(current->domain, d, SECCLASS_HVM, HVM__MEM_EVENT);
+    return current_has_perm(d, SECCLASS_HVM, HVM__MEM_EVENT);
 }
 
 static int flask_mem_sharing(struct domain *d)
 {
-    return domain_has_perm(current->domain, d, SECCLASS_HVM, HVM__MEM_SHARING);
+    return current_has_perm(d, SECCLASS_HVM, HVM__MEM_SHARING);
 }
 
 static int flask_apic(struct domain *d, int cmd)
@@ -1355,11 +1346,7 @@ static int flask_physinfo(void)
 
 static int flask_platform_quirk(uint32_t quirk)
 {
-    struct domain_security_struct *dsec;
-    dsec = current->domain->ssid;
-
-    return avc_has_perm(dsec->sid, SECINITSID_XEN, SECCLASS_XEN, 
-                        XEN__QUIRK, NULL);
+    return avc_current_has_perm(SECINITSID_XEN, SECCLASS_XEN, XEN__QUIRK, NULL);
 }
 
 static int flask_platform_op(uint32_t op)
@@ -1421,16 +1408,12 @@ static int flask_getidletime(void)
 
 static int flask_machine_memory_map(void)
 {
-    struct domain_security_struct *dsec;
-    dsec = current->domain->ssid;
-
-    return avc_has_perm(dsec->sid, SECINITSID_XEN, SECCLASS_MMU, 
-                        MMU__MEMORYMAP, NULL);
+    return avc_current_has_perm(SECINITSID_XEN, SECCLASS_MMU, MMU__MEMORYMAP, NULL);
 }
 
 static int flask_domain_memory_map(struct domain *d)
 {
-    return domain_has_perm(current->domain, d, SECCLASS_MMU, MMU__MEMORYMAP);
+    return current_has_perm(d, SECCLASS_MMU, MMU__MEMORYMAP);
 }
 
 static int domain_memory_perm(struct domain *d, struct domain *f, l1_pgentry_t pte)
@@ -1453,17 +1436,17 @@ static int domain_memory_perm(struct domain *d, struct domain *f, l1_pgentry_t p
     if ( f->domain_id == DOMID_IO || !mfn_valid(fmfn) )
     {
         struct avc_audit_data ad;
-        struct domain_security_struct *dsec = d->ssid;
-        u32 fsid;
+        u32 dsid, fsid;
+        rc = security_iomem_sid(fmfn, &fsid);
+        if ( rc )
+            return rc;
         AVC_AUDIT_DATA_INIT(&ad, MEMORY);
         ad.sdom = d;
         ad.tdom = f;
         ad.memory.pte = pte.l1;
         ad.memory.mfn = fmfn;
-        rc = security_iomem_sid(fmfn, &fsid);
-        if ( rc )
-            return rc;
-        return avc_has_perm(dsec->sid, fsid, SECCLASS_MMU, map_perms, &ad);
+        dsid = domain_sid(d);
+        return avc_has_perm(dsid, fsid, SECCLASS_MMU, map_perms, &ad);
     }
 
     return domain_has_perm(d, f, SECCLASS_MMU, map_perms);
@@ -1506,43 +1489,40 @@ static int flask_remove_from_physmap(struct domain *d1, struct domain *d2)
 
 static int flask_sendtrigger(struct domain *d)
 {
-    return domain_has_perm(current->domain, d, SECCLASS_DOMAIN, DOMAIN__TRIGGER);
+    return current_has_perm(d, SECCLASS_DOMAIN, DOMAIN__TRIGGER);
 }
 
 static int flask_get_device_group(uint32_t machine_bdf)
 {
     u32 rsid;
     int rc = -EPERM;
-    struct domain_security_struct *ssec = current->domain->ssid;
 
     rc = security_device_sid(machine_bdf, &rsid);
     if ( rc )
         return rc;
 
-    return avc_has_perm(ssec->sid, rsid, SECCLASS_RESOURCE, RESOURCE__STAT_DEVICE, NULL);
+    return avc_current_has_perm(rsid, SECCLASS_RESOURCE, RESOURCE__STAT_DEVICE, NULL);
 }
 
 static int flask_test_assign_device(uint32_t machine_bdf)
 {
     u32 rsid;
     int rc = -EPERM;
-    struct domain_security_struct *ssec = current->domain->ssid;
 
     rc = security_device_sid(machine_bdf, &rsid);
     if ( rc )
         return rc;
 
-    return rc = avc_has_perm(ssec->sid, rsid, SECCLASS_RESOURCE, RESOURCE__STAT_DEVICE, NULL);
+    return avc_current_has_perm(rsid, SECCLASS_RESOURCE, RESOURCE__STAT_DEVICE, NULL);
 }
 
 static int flask_assign_device(struct domain *d, uint32_t machine_bdf)
 {
-    u32 rsid;
+    u32 dsid, rsid;
     int rc = -EPERM;
-    struct domain_security_struct *ssec, *tsec;
     struct avc_audit_data ad;
 
-    rc = domain_has_perm(current->domain, d, SECCLASS_RESOURCE, RESOURCE__ADD);
+    rc = current_has_perm(d, SECCLASS_RESOURCE, RESOURCE__ADD);
     if ( rc )
         return rc;
 
@@ -1552,22 +1532,20 @@ static int flask_assign_device(struct domain *d, uint32_t machine_bdf)
 
     AVC_AUDIT_DATA_INIT(&ad, DEV);
     ad.device = (unsigned long) machine_bdf;
-    ssec = current->domain->ssid;
-    rc = avc_has_perm(ssec->sid, rsid, SECCLASS_RESOURCE, RESOURCE__ADD_DEVICE, &ad);
+    rc = avc_current_has_perm(rsid, SECCLASS_RESOURCE, RESOURCE__ADD_DEVICE, &ad);
     if ( rc )
         return rc;
 
-    tsec = d->ssid;
-    return avc_has_perm(tsec->sid, rsid, SECCLASS_RESOURCE, RESOURCE__USE, &ad);
+    dsid = domain_sid(d);
+    return avc_has_perm(dsid, rsid, SECCLASS_RESOURCE, RESOURCE__USE, &ad);
 }
 
 static int flask_deassign_device(struct domain *d, uint32_t machine_bdf)
 {
     u32 rsid;
     int rc = -EPERM;
-    struct domain_security_struct *ssec = current->domain->ssid;
 
-    rc = domain_has_perm(current->domain, d, SECCLASS_RESOURCE, RESOURCE__REMOVE);
+    rc = current_has_perm(d, SECCLASS_RESOURCE, RESOURCE__REMOVE);
     if ( rc )
         return rc;
 
@@ -1575,18 +1553,17 @@ static int flask_deassign_device(struct domain *d, uint32_t machine_bdf)
     if ( rc )
         return rc;
 
-    return rc = avc_has_perm(ssec->sid, rsid, SECCLASS_RESOURCE, RESOURCE__REMOVE_DEVICE, NULL);
+    return avc_current_has_perm(rsid, SECCLASS_RESOURCE, RESOURCE__REMOVE_DEVICE, NULL);
 }
 
 static int flask_bind_pt_irq (struct domain *d, struct xen_domctl_bind_pt_irq *bind)
 {
-    u32 rsid;
+    u32 dsid, rsid;
     int rc = -EPERM;
     int irq;
-    struct domain_security_struct *ssec, *tsec;
     struct avc_audit_data ad;
 
-    rc = domain_has_perm(current->domain, d, SECCLASS_RESOURCE, RESOURCE__ADD);
+    rc = current_has_perm(d, SECCLASS_RESOURCE, RESOURCE__ADD);
     if ( rc )
         return rc;
 
@@ -1596,23 +1573,22 @@ static int flask_bind_pt_irq (struct domain *d, struct xen_domctl_bind_pt_irq *b
     if ( rc )
         return rc;
 
-    ssec = current->domain->ssid;
-    rc = avc_has_perm(ssec->sid, rsid, SECCLASS_HVM, HVM__BIND_IRQ, &ad);
+    rc = avc_current_has_perm(rsid, SECCLASS_HVM, HVM__BIND_IRQ, &ad);
     if ( rc )
         return rc;
 
-    tsec = d->ssid;
-    return avc_has_perm(tsec->sid, rsid, SECCLASS_RESOURCE, RESOURCE__USE, &ad);
+    dsid = domain_sid(d);
+    return avc_has_perm(dsid, rsid, SECCLASS_RESOURCE, RESOURCE__USE, &ad);
 }
 
 static int flask_unbind_pt_irq (struct domain *d, struct xen_domctl_bind_pt_irq *bind)
 {
-    return domain_has_perm(current->domain, d, SECCLASS_RESOURCE, RESOURCE__REMOVE);
+    return current_has_perm(d, SECCLASS_RESOURCE, RESOURCE__REMOVE);
 }
 
 static int flask_pin_mem_cacheattr (struct domain *d)
 {
-    return domain_has_perm(current->domain, d, SECCLASS_HVM, HVM__CACHEATTR);
+    return current_has_perm(d, SECCLASS_HVM, HVM__CACHEATTR);
 }
 
 static int flask_ext_vcpucontext (struct domain *d, uint32_t cmd)
@@ -1631,7 +1607,7 @@ static int flask_ext_vcpucontext (struct domain *d, uint32_t cmd)
         return -EPERM;
     }
 
-    return domain_has_perm(current->domain, d, SECCLASS_DOMAIN, perm);
+    return current_has_perm(d, SECCLASS_DOMAIN, perm);
 }
 
 static int flask_vcpuextstate (struct domain *d, uint32_t cmd)
@@ -1650,7 +1626,7 @@ static int flask_vcpuextstate (struct domain *d, uint32_t cmd)
             return -EPERM;
     }
 
-    return domain_has_perm(current->domain, d, SECCLASS_DOMAIN, perm);
+    return current_has_perm(d, SECCLASS_DOMAIN, perm);
 }
 #endif
 
diff --git a/xen/xsm/flask/include/objsec.h b/xen/xsm/flask/include/objsec.h
index 4ff52be..6595dc3 100644
--- a/xen/xsm/flask/include/objsec.h
+++ b/xen/xsm/flask/include/objsec.h
@@ -19,6 +19,8 @@
 
 struct domain_security_struct {
     u32 sid;               /* current SID */
+    u32 self_sid;          /* SID for target when operating on DOMID_SELF */
+    u32 target_sid;        /* SID for device model target domain */
 };
 
 struct evtchn_security_struct {
-- 
1.7.11.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 17 15:24:29 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 15: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 1TDdBI-0003kx-VB; Mon, 17 Sep 2012 15:24:16 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1TDdBF-0003Zt-E3
	for xen-devel@lists.xen.org; Mon, 17 Sep 2012 15:24:14 +0000
Received: from [85.158.139.211:51923] by server-12.bemta-5.messagelabs.com id
	07/8B-19338-A9047505; Mon, 17 Sep 2012 15:24:10 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-14.tower-206.messagelabs.com!1347895446!18842501!1
X-Originating-IP: [63.239.67.9]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14971 invoked from network); 17 Sep 2012 15:24:06 -0000
Received: from emvm-gh1-uea08.nsa.gov (HELO nsa.gov) (63.239.67.9)
	by server-14.tower-206.messagelabs.com with SMTP;
	17 Sep 2012 15:24:06 -0000
X-TM-IMSS-Message-ID: <53803fb80012ace2@nsa.gov>
Received: from tarius.tycho.ncsc.mil ([144.51.3.1]) by nsa.gov ([63.239.67.9])
	with ESMTP (TREND IMSS SMTP Service 7.1) id 53803fb80012ace2 ;
	Mon, 17 Sep 2012 11:23:46 -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 q8HFO0xh027504; 
	Mon, 17 Sep 2012 11:24:05 -0400
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xen.org
Date: Mon, 17 Sep 2012 11:23:39 -0400
Message-Id: <1347895425-17959-18-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.11.4
In-Reply-To: <1347895425-17959-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1347895425-17959-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: dgdegra@tycho.nsa.gov, keir@xen.org
Subject: [Xen-devel] [PATCH 17/23] xsm/flask: add distinct SIDs for
	self/target 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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Because the FLASK XSM module no longer checks IS_PRIV for remote domain
accesses covered by XSM permissions, domains now have the ability to
perform memory management and other functions on all domains that have
the same type. While it is possible to prevent this by only creating one
domain per type, this solution significantly limits the flexibility of
the type system.

This patch introduces a domain type transition to represent a domain
that is operating on itself. In the example policy, this is demonstrated
by creating a type with _self appended when declaring a domain type
which will be used for reflexive operations. AVCs for a domain of type
domU_t will look like the following:

scontext=system_u:system_r:domU_t tcontext=system_u:system_r:domU_t_self

This change also allows policy to distinguish between event channels a
domain creates to itself and event channels created between domains of
the same type.

The IS_PRIV_FOR check used for device model domains is also no longer
checked by FLASK; a similar transition is performed when the target is
set and used when the device model accesses its target domain.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 docs/misc/xsm-flask.txt                      |  43 ++-
 tools/flask/policy/policy/modules/xen/xen.if |  60 +++-
 tools/flask/policy/policy/modules/xen/xen.te |  13 +-
 xen/xsm/flask/flask_op.c                     |   9 +
 xen/xsm/flask/hooks.c                        | 422 +++++++++++++--------------
 xen/xsm/flask/include/objsec.h               |   2 +
 6 files changed, 307 insertions(+), 242 deletions(-)

diff --git a/docs/misc/xsm-flask.txt b/docs/misc/xsm-flask.txt
index 0778a28..ff81b01 100644
--- a/docs/misc/xsm-flask.txt
+++ b/docs/misc/xsm-flask.txt
@@ -68,9 +68,43 @@ HVM domains with stubdomain device models use two types (one per domain):
  - dm_dom_t is the device model for a domain with type domHVM_t
 
 One disadvantage of using type enforcement to enforce isolation is that a new
-type is needed for each group of domains. In addition, it is not possible to
-allow isolated_domU_t cannot to create loopback event channels without allowing
-two domains of type isolated_domU_t to communicate with one another.
+type is needed for each group of domains. The user field can be used to address
+this for the most common case of groups that can communicate internally but not
+externally; see "Users and roles" below.
+
+Type transitions
+----------------
+
+Xen defines a number of operations such as memory mapping that are necessary for
+a domain to perform on itself, but are also undesirable to allow a domain to
+perform on every other domain of the same label. While it is possible to address
+this by only creating one domain per type, this solution significantly limits
+the flexibility of the type system. Another method to address this issue is to
+duplicate the permission names for every operation that can be performed on the
+current domain or on other domains; however, this significantly increases the
+necessary number of permissions and complicates the XSM hooks. Instead, this is
+addressed by allowing a distinct type to be used for a domain's access to
+itself. The same applies for a device model domain's access to its designated
+target, allowing the IS_PRIV_FOR checks used in Xen's DAC model to be
+implemented in FLASK.
+
+Upon domain creation (or relabel), a type transition is computed using the
+domain's label as the source and target. The result of this computation is used
+as the target when the domain accesses itself. In the example policy, this
+computed type is the result of appending _self to a domain's type: domU_t_self
+for domU_t. If no type transition rule exists, the domain will continue to use
+its own label for both the source and target. An AVC message will look like:
+
+    scontext=system_u:system_r:domU_t tcontext=system_u:system_r:domU_t_self
+
+A similar type transition is done when a device model domain is associated with
+its target using the set_target operation. The transition is computed with the
+target domain as the source and the device model domain as the target: this
+ordering was chosen in order to preserve the original label for the target when
+no type transition rule exists. In the example policy, these computed types are
+the result of appending _target to the domain.
+
+Type transitions are also used to compute the labels of event channels.
 
 Users and roles
 ---------------
@@ -84,7 +118,8 @@ the customer_1 user.
 Access control rules involving users and roles are defined in the policy
 constraints file (tools/flask/policy/policy/constraints). The example policy
 provides constraints that prevent different users from communicating using
-grants or event channels, while still allowing communication with dom0.
+grants or event channels, while still allowing communication with the system_u
+user where dom0 resides.
 
 Resource Policy
 ---------------
diff --git a/tools/flask/policy/policy/modules/xen/xen.if b/tools/flask/policy/policy/modules/xen/xen.if
index 59ba171..d630f47 100644
--- a/tools/flask/policy/policy/modules/xen/xen.if
+++ b/tools/flask/policy/policy/modules/xen/xen.if
@@ -5,15 +5,34 @@
 # Domain creation and setup
 #
 ################################################################################
+define(`declare_domain_common', `
+	allow $1 $2:grant { query setup };
+	allow $1 $2:mmu { adjust physmap map_read map_write stat pinpage updatemp };
+	allow $1 $2:hvm { getparam setparam };
+')
+
 # declare_domain(type, attrs...)
-#   Declare a type as a domain type, and allow basic domain setup
+#   Declare a domain type, along with associated _self and _channel types
+#   Allow the domain to perform basic operations on itself
 define(`declare_domain', `
 	type $1, domain_type`'ifelse(`$#', `1', `', `,shift($@)');
+	type $1_self, domain_type, domain_self_type;
+	type_transition $1 $1:domain $1_self;
+	type $1_channel, event_type;
+	type_transition $1 domain_type:event $1_channel;
+	declare_domain_common($1, $1_self)
+')
+
+# declare_singleton_domain(type, attrs...)
+#   Declare a domain type and associated _channel types.
+#   Note: Because the domain can perform basic operations on itself and any
+#   other domain of the same type, this constructor should be used for types
+#   containing at most one domain. This is not enforced by policy.
+define(`declare_singleton_domain', `
+	type $1, domain_type`'ifelse(`$#', `1', `', `,shift($@)');
 	type $1_channel, event_type;
 	type_transition $1 domain_type:event $1_channel;
-	allow $1 $1:grant { query setup };
-	allow $1 $1:mmu { adjust physmap map_read map_write stat pinpage };
-	allow $1 $1:hvm { getparam setparam };
+	declare_domain_common($1, $1)
 ')
 
 # declare_build_label(type)
@@ -51,6 +70,7 @@ define(`create_domain_build_label', `
 	allow $1 $2_channel:event create;
 	allow $1 $2_building:domain2 relabelfrom;
 	allow $1 $2:domain2 relabelto;
+	allow $2_building $2:domain transition;
 ')
 
 # manage_domain(priv, target)
@@ -101,20 +121,36 @@ define(`domain_comms', `
 ')
 
 # domain_self_comms(domain)
-#   Allow a domain types to communicate with others of its type using grants
-#   and event channels (this includes event channels to DOMID_SELF)
+#   Allow a non-singleton domain type to communicate with itself using grants
+#   and event channels
 define(`domain_self_comms', `
-	create_channel($1, $1, $1_channel)
-	allow $1 $1:grant { map_read map_write copy unmap };
+	create_channel($1, $1_self, $1_channel)
+	allow $1 $1_self:grant { map_read map_write copy unmap };
 ')
 
 # device_model(dm_dom, hvm_dom)
 #   Define how a device model domain interacts with its target
 define(`device_model', `
-	domain_comms($1, $2)
-	allow $1 $2:domain { set_target shutdown };
-	allow $1 $2:mmu { map_read map_write adjust physmap };
-	allow $1 $2:hvm { getparam setparam trackdirtyvram hvmctl irqlevel pciroute cacheattr send_irq };
+	type $2_target, domain_type, domain_target_type;
+	type_transition $2 $1:domain $2_target;
+	allow $1 $2:domain set_target;
+
+	type_transition $2_target domain_type:event $2_channel;
+	create_channel($1, $2_target, $1_channel)
+	create_channel($2, $1, $2_channel)
+	allow $1 $2_channel:event create;
+
+	allow $1 $2_target:domain shutdown;
+	allow $1 $2_target:mmu { map_read map_write adjust physmap };
+	allow $1 $2_target:hvm { getparam setparam trackdirtyvram hvmctl irqlevel pciroute cacheattr send_irq };
+')
+
+# make_device_model(priv, dm_dom, hvm_dom)
+#   Allow creation of a device model and HVM domain pair
+define(`make_device_model', `
+	device_model($2, $3)
+	allow $1 $2:domain2 make_priv_for;
+	allow $1 $3:domain2 set_as_target;
 ')
 ################################################################################
 #
diff --git a/tools/flask/policy/policy/modules/xen/xen.te b/tools/flask/policy/policy/modules/xen/xen.te
index 1162153..8d33285 100644
--- a/tools/flask/policy/policy/modules/xen/xen.te
+++ b/tools/flask/policy/policy/modules/xen/xen.te
@@ -8,6 +8,8 @@
 ################################################################################
 attribute xen_type;
 attribute domain_type;
+attribute domain_self_type;
+attribute domain_target_type;
 attribute resource_type;
 attribute event_type;
 attribute mls_priv;
@@ -25,7 +27,7 @@ attribute mls_priv;
 type xen_t, xen_type, mls_priv;
 
 # Domain 0
-declare_domain(dom0_t, mls_priv);
+declare_singleton_domain(dom0_t, mls_priv);
 
 # Untracked I/O memory (pseudo-domain)
 type domio_t, xen_type;
@@ -69,7 +71,7 @@ admin_device(dom0_t, ioport_t)
 admin_device(dom0_t, iomem_t)
 allow dom0_t domio_t:mmu { map_read map_write };
 
-domain_self_comms(dom0_t)
+domain_comms(dom0_t, dom0_t)
 
 auditallow dom0_t security_t:security { load_policy setenforce setbool };
 
@@ -84,11 +86,14 @@ domain_self_comms(domU_t)
 create_domain(dom0_t, domU_t)
 manage_domain(dom0_t, domU_t)
 domain_comms(dom0_t, domU_t)
+domain_comms(domU_t, domU_t)
+domain_self_comms(domU_t)
 
 declare_domain(isolated_domU_t)
 create_domain(dom0_t, isolated_domU_t)
 manage_domain(dom0_t, isolated_domU_t)
 domain_comms(dom0_t, isolated_domU_t)
+domain_self_comms(isolated_domU_t)
 
 # Declare a boolean that denies creation of prot_domU_t domains
 gen_bool(prot_doms_locked, false)
@@ -98,6 +103,8 @@ if (!prot_doms_locked) {
 }
 domain_comms(dom0_t, prot_domU_t)
 domain_comms(domU_t, prot_domU_t)
+domain_comms(prot_domU_t, prot_domU_t)
+domain_self_comms(prot_domU_t)
 
 # domHVM_t is meant to be paired with a qemu-dm stub domain of type dm_dom_t
 declare_domain(domHVM_t)
@@ -110,7 +117,7 @@ declare_domain(dm_dom_t)
 create_domain(dom0_t, dm_dom_t)
 manage_domain(dom0_t, dm_dom_t)
 domain_comms(dom0_t, dm_dom_t)
-device_model(dm_dom_t, domHVM_t)
+make_device_model(dom0_t, dm_dom_t, domHVM_t)
 
 # nomigrate_t must be built via the nomigrate_t_building label; once built,
 # dom0 cannot read its memory.
diff --git a/xen/xsm/flask/flask_op.c b/xen/xsm/flask/flask_op.c
index 9c8dfe7..f8fc108 100644
--- a/xen/xsm/flask/flask_op.c
+++ b/xen/xsm/flask/flask_op.c
@@ -612,6 +612,15 @@ static int flask_relabel_domain(struct xen_flask_relabel *arg)
         goto out;
 
     dsec->sid = arg->sid;
+    dsec->self_sid = arg->sid;
+    security_transition_sid(dsec->sid, dsec->sid, SECCLASS_DOMAIN,
+                            &dsec->self_sid);
+    if ( d->target )
+    {
+        struct domain_security_struct *tsec = d->target->ssid;
+        security_transition_sid(tsec->sid, dsec->sid, SECCLASS_DOMAIN,
+                                &dsec->target_sid);
+    }
 
  out:
     rcu_unlock_domain(d);
diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
index 089faf8..a242d65 100644
--- a/xen/xsm/flask/hooks.c
+++ b/xen/xsm/flask/hooks.c
@@ -33,38 +33,69 @@
 
 struct xsm_operations *original_ops = NULL;
 
+static u32 domain_sid(struct domain *dom)
+{
+    struct domain_security_struct *dsec = dom->ssid;
+    return dsec->sid;
+}
+
+static u32 domain_target_sid(struct domain *src, struct domain *dst)
+{
+    struct domain_security_struct *ssec = src->ssid;
+    struct domain_security_struct *dsec = dst->ssid;
+    if (src == dst)
+        return ssec->self_sid;
+    if (src->target == dst)
+        return ssec->target_sid;
+    return dsec->sid;
+}
+
+static u32 evtchn_sid(const struct evtchn *chn)
+{
+    struct evtchn_security_struct *esec = chn->ssid;
+    return esec->sid;
+}
+
 static int domain_has_perm(struct domain *dom1, struct domain *dom2, 
                            u16 class, u32 perms)
 {
-    struct domain_security_struct *dsec1, *dsec2;
+    u32 ssid, tsid;
     struct avc_audit_data ad;
     AVC_AUDIT_DATA_INIT(&ad, NONE);
     ad.sdom = dom1;
     ad.tdom = dom2;
 
-    dsec1 = dom1->ssid;
-    dsec2 = dom2->ssid;
+    ssid = domain_sid(dom1);
+    tsid = domain_target_sid(dom1, dom2);
 
-    return avc_has_perm(dsec1->sid, dsec2->sid, class, perms, &ad);
+    return avc_has_perm(ssid, tsid, class, perms, &ad);
 }
 
-static int domain_has_evtchn(struct domain *d, struct evtchn *chn, u32 perms)
+static int avc_current_has_perm(u32 tsid, u16 class, u32 perm,
+                                struct avc_audit_data *ad)
 {
-    struct domain_security_struct *dsec;
-    struct evtchn_security_struct *esec;
+    u32 csid = domain_sid(current->domain);
+    return avc_has_perm(csid, tsid, class, perm, ad);
+}
 
-    dsec = d->ssid;
-    esec = chn->ssid;
+static int current_has_perm(struct domain *d, u16 class, u32 perms)
+{
+    return domain_has_perm(current->domain, d, class, perms);
+}
 
-    return avc_has_perm(dsec->sid, esec->sid, SECCLASS_EVENT, perms, NULL);
+static int domain_has_evtchn(struct domain *d, struct evtchn *chn, u32 perms)
+{
+    u32 dsid = domain_sid(d);
+    u32 esid = evtchn_sid(chn);
+
+    return avc_has_perm(dsid, esid, SECCLASS_EVENT, perms, NULL);
 }
 
 static int domain_has_xen(struct domain *d, u32 perms)
 {
-    struct domain_security_struct *dsec;
-    dsec = d->ssid;
+    u32 dsid = domain_sid(d);
 
-    return avc_has_perm(dsec->sid, SECINITSID_XEN, SECCLASS_XEN, perms, NULL);
+    return avc_has_perm(dsid, SECINITSID_XEN, SECCLASS_XEN, perms, NULL);
 }
 
 static int get_irq_sid(int irq, u32 *sid, struct avc_audit_data *ad)
@@ -123,6 +154,7 @@ static int flask_domain_alloc_security(struct domain *d)
         dsec->sid = SECINITSID_UNLABELED;
     }
 
+    dsec->self_sid = dsec->sid;
     d->ssid = dsec;
 
     return 0;
@@ -142,68 +174,55 @@ static void flask_domain_free_security(struct domain *d)
 static int flask_evtchn_unbound(struct domain *d1, struct evtchn *chn, 
                                 domid_t id2)
 {
-    u32 newsid;
+    u32 sid1, sid2, newsid;
     int rc;
-    domid_t id;
     struct domain *d2;
-    struct domain_security_struct *dsec, *dsec1, *dsec2;
     struct evtchn_security_struct *esec;
 
-    dsec = current->domain->ssid;
-    dsec1 = d1->ssid;
-    esec = chn->ssid;
-
-    if ( id2 == DOMID_SELF )
-        id = current->domain->domain_id;
-    else
-        id = id2;
-
-    d2 = get_domain_by_id(id);
+    d2 = rcu_lock_domain_by_any_id(id2);
     if ( d2 == NULL )
         return -EPERM;
 
-    dsec2 = d2->ssid;
-    rc = security_transition_sid(dsec1->sid, dsec2->sid, SECCLASS_EVENT, 
-                                 &newsid);
+    sid1 = domain_sid(d1);
+    sid2 = domain_target_sid(d1, d2);
+    esec = chn->ssid;
+
+    rc = security_transition_sid(sid1, sid2, SECCLASS_EVENT, &newsid);
     if ( rc )
         goto out;
 
-    rc = avc_has_perm(dsec->sid, newsid, SECCLASS_EVENT, EVENT__CREATE, NULL);
+    rc = avc_current_has_perm(newsid, SECCLASS_EVENT, EVENT__CREATE, NULL);
     if ( rc )
         goto out;
 
-    rc = avc_has_perm(newsid, dsec2->sid, SECCLASS_EVENT, EVENT__BIND, NULL);
+    rc = avc_has_perm(newsid, sid2, SECCLASS_EVENT, EVENT__BIND, NULL);
     if ( rc )
         goto out;
-    else
-        esec->sid = newsid;
+
+    esec->sid = newsid;
 
  out:
-    put_domain(d2);
+    rcu_unlock_domain(d2);
     return rc;
 }
 
 static int flask_evtchn_interdomain(struct domain *d1, struct evtchn *chn1, 
                                     struct domain *d2, struct evtchn *chn2)
 {
-    u32 newsid;
+    u32 sid1, sid2, newsid, reverse_sid;
     int rc;
-    struct domain_security_struct *dsec, *dsec1, *dsec2;
-    struct evtchn_security_struct *esec1, *esec2;
+    struct evtchn_security_struct *esec1;
     struct avc_audit_data ad;
     AVC_AUDIT_DATA_INIT(&ad, NONE);
     ad.sdom = d1;
     ad.tdom = d2;
 
-    dsec = current->domain->ssid;
-    dsec1 = d1->ssid;
-    dsec2 = d2->ssid;
+    sid1 = domain_sid(d1);
+    sid2 = domain_target_sid(d1, d2);
 
     esec1 = chn1->ssid;
-    esec2 = chn2->ssid;
 
-    rc = security_transition_sid(dsec1->sid, dsec2->sid, 
-                                 SECCLASS_EVENT, &newsid);
+    rc = security_transition_sid(sid1, sid2, SECCLASS_EVENT, &newsid);
     if ( rc )
     {
         printk("%s: security_transition_sid failed, rc=%d (domain=%d)\n",
@@ -211,15 +230,20 @@ static int flask_evtchn_interdomain(struct domain *d1, struct evtchn *chn1,
         return rc;
     }
 
-    rc = avc_has_perm(dsec->sid, newsid, SECCLASS_EVENT, EVENT__CREATE, &ad);
+    rc = avc_current_has_perm(newsid, SECCLASS_EVENT, EVENT__CREATE, &ad);
     if ( rc )
         return rc;
 
-    rc = avc_has_perm(newsid, dsec2->sid, SECCLASS_EVENT, EVENT__BIND, &ad);
+    rc = avc_has_perm(newsid, sid2, SECCLASS_EVENT, EVENT__BIND, &ad);
     if ( rc )
         return rc;
 
-    rc = avc_has_perm(esec2->sid, dsec1->sid, SECCLASS_EVENT, EVENT__BIND, &ad);
+    /* It's possible the target domain has changed (relabel or destroy/create)
+     * since the unbound part was created; re-validate this binding now.
+     */
+    reverse_sid = evtchn_sid(chn2);
+    sid1 = domain_target_sid(d2, d1);
+    rc = avc_has_perm(reverse_sid, sid1, SECCLASS_EVENT, EVENT__BIND, &ad);
     if ( rc )
         return rc;
 
@@ -302,7 +326,6 @@ static void flask_free_security_evtchn(struct evtchn *chn)
 
 static char *flask_show_security_evtchn(struct domain *d, const struct evtchn *chn)
 {
-    struct evtchn_security_struct *esec;
     int irq;
     u32 sid = 0;
     char *ctx;
@@ -312,9 +335,7 @@ static char *flask_show_security_evtchn(struct domain *d, const struct evtchn *c
     {
     case ECS_UNBOUND:
     case ECS_INTERDOMAIN:
-        esec = chn->ssid;
-        if ( esec )
-            sid = esec->sid;
+        sid = evtchn_sid(chn);
         break;
     case ECS_PIRQ:
         irq = domain_pirq_to_irq(d, chn->u.pirq.irq);
@@ -367,12 +388,12 @@ static int flask_grant_query_size(struct domain *d1, struct domain *d2)
 
 static int flask_get_pod_target(struct domain *d)
 {
-    return domain_has_perm(current->domain, d, SECCLASS_DOMAIN, DOMAIN__GETPODTARGET);
+    return current_has_perm(d, SECCLASS_DOMAIN, DOMAIN__GETPODTARGET);
 }
 
 static int flask_set_pod_target(struct domain *d)
 {
-    return domain_has_perm(current->domain, d, SECCLASS_DOMAIN, DOMAIN__SETPODTARGET);
+    return current_has_perm(d, SECCLASS_DOMAIN, DOMAIN__SETPODTARGET);
 }
 
 static int flask_memory_adjust_reservation(struct domain *d1, struct domain *d2)
@@ -455,70 +476,65 @@ static int flask_schedop_shutdown(struct domain *d1, struct domain *d2)
 static void flask_security_domaininfo(struct domain *d, 
                                       struct xen_domctl_getdomaininfo *info)
 {
-    struct domain_security_struct *dsec;
-
-    dsec = d->ssid;
-    info->ssidref = dsec->sid;
+    info->ssidref = domain_sid(d);
 }
 
 static int flask_setvcpucontext(struct domain *d)
 {
-    return domain_has_perm(current->domain, d, SECCLASS_DOMAIN, 
-                           DOMAIN__SETVCPUCONTEXT);
+    return current_has_perm(d, SECCLASS_DOMAIN, DOMAIN__SETVCPUCONTEXT);
 }
 
 static int flask_pausedomain(struct domain *d)
 {
-    return domain_has_perm(current->domain, d, SECCLASS_DOMAIN, DOMAIN__PAUSE);
+    return current_has_perm(d, SECCLASS_DOMAIN, DOMAIN__PAUSE);
 }
 
 static int flask_unpausedomain(struct domain *d)
 {
-    return domain_has_perm(current->domain, d, SECCLASS_DOMAIN, DOMAIN__UNPAUSE);
+    return current_has_perm(d, SECCLASS_DOMAIN, DOMAIN__UNPAUSE);
 }
 
 static int flask_resumedomain(struct domain *d)
 {
-    return domain_has_perm(current->domain, d, SECCLASS_DOMAIN, DOMAIN__RESUME);
+    return current_has_perm(d, SECCLASS_DOMAIN, DOMAIN__RESUME);
 }
 
 static int flask_domain_create(struct domain *d, u32 ssidref)
 {
     int rc;
-    struct domain_security_struct *dsec1;
-    struct domain_security_struct *dsec2;
+    struct domain_security_struct *dsec = d->ssid;
     static int dom0_created = 0;
 
-    dsec1 = current->domain->ssid;
-    dsec2 = d->ssid;
-
     if ( is_idle_domain(current->domain) && !dom0_created )
     {
-        dsec2->sid = SECINITSID_DOM0;
+        dsec->sid = SECINITSID_DOM0;
         dom0_created = 1;
-        return 0;
     }
+    else
+    {
+        rc = avc_current_has_perm(ssidref, SECCLASS_DOMAIN,
+                          DOMAIN__CREATE, NULL);
+        if ( rc )
+            return rc;
 
-    rc = avc_has_perm(dsec1->sid, ssidref, SECCLASS_DOMAIN,
-                      DOMAIN__CREATE, NULL);
-    if ( rc )
-        return rc;
+        dsec->sid = ssidref;
+    }
+    dsec->self_sid = dsec->sid;
 
-    dsec2->sid = ssidref;
+    rc = security_transition_sid(dsec->sid, dsec->sid, SECCLASS_DOMAIN,
+                                 &dsec->self_sid);
 
     return rc;
 }
 
 static int flask_max_vcpus(struct domain *d)
 {
-    return domain_has_perm(current->domain, d, SECCLASS_DOMAIN, 
-                           DOMAIN__MAX_VCPUS);
+    return current_has_perm(d, SECCLASS_DOMAIN, DOMAIN__MAX_VCPUS);
 }
 
 static int flask_destroydomain(struct domain *d)
 {
-    return domain_has_perm(current->domain, d, SECCLASS_DOMAIN, 
-                           DOMAIN__DESTROY);
+    return current_has_perm(d, SECCLASS_DOMAIN, DOMAIN__DESTROY);
 }
 
 static int flask_vcpuaffinity(int cmd, struct domain *d)
@@ -537,7 +553,7 @@ static int flask_vcpuaffinity(int cmd, struct domain *d)
         return -EPERM;
     }
 
-    return domain_has_perm(current->domain, d, SECCLASS_DOMAIN, perm );
+    return current_has_perm(d, SECCLASS_DOMAIN, perm );
 }
 
 static int flask_scheduler(struct domain *d)
@@ -548,43 +564,51 @@ static int flask_scheduler(struct domain *d)
     if ( rc )
         return rc;
 
-    return domain_has_perm(current->domain, d, SECCLASS_DOMAIN, 
-                           DOMAIN__SCHEDULER);
+    return current_has_perm(d, SECCLASS_DOMAIN, DOMAIN__SCHEDULER);
 }
 
 static int flask_getdomaininfo(struct domain *d)
 {
-    return domain_has_perm(current->domain, d, SECCLASS_DOMAIN,
-                           DOMAIN__GETDOMAININFO);
+    return current_has_perm(d, SECCLASS_DOMAIN, DOMAIN__GETDOMAININFO);
 }
 
 static int flask_getvcpucontext(struct domain *d)
 {
-    return domain_has_perm(current->domain, d, SECCLASS_DOMAIN, 
-                           DOMAIN__GETVCPUCONTEXT);
+    return current_has_perm(d, SECCLASS_DOMAIN, DOMAIN__GETVCPUCONTEXT);
 }
 
 static int flask_getvcpuinfo(struct domain *d)
 {
-    return domain_has_perm(current->domain, d, SECCLASS_DOMAIN,
-                           DOMAIN__GETVCPUINFO);
+    return current_has_perm(d, SECCLASS_DOMAIN, DOMAIN__GETVCPUINFO);
 }
 
 static int flask_domain_settime(struct domain *d)
 {
-    return domain_has_perm(current->domain, d, SECCLASS_DOMAIN, DOMAIN__SETTIME);
+    return current_has_perm(d, SECCLASS_DOMAIN, DOMAIN__SETTIME);
 }
 
-static int flask_set_target(struct domain *d, struct domain *e)
+static int flask_set_target(struct domain *d, struct domain *t)
 {
     int rc;
-    rc = domain_has_perm(current->domain, d, SECCLASS_DOMAIN2, DOMAIN2__MAKE_PRIV_FOR);
+    struct domain_security_struct *dsec, *tsec;
+    dsec = d->ssid;
+    tsec = t->ssid;
+
+    rc = current_has_perm(d, SECCLASS_DOMAIN2, DOMAIN2__MAKE_PRIV_FOR);
     if ( rc )
         return rc;
-    rc = domain_has_perm(current->domain, e, SECCLASS_DOMAIN2, DOMAIN2__SET_AS_TARGET);
+    rc = current_has_perm(t, SECCLASS_DOMAIN2, DOMAIN2__SET_AS_TARGET);
     if ( rc )
         return rc;
-    return domain_has_perm(d, e, SECCLASS_DOMAIN, DOMAIN__SET_TARGET);
+    /* Use avc_has_perm to avoid resolving target/current SID */
+    rc = avc_has_perm(dsec->sid, tsec->sid, SECCLASS_DOMAIN, DOMAIN__SET_TARGET, NULL);
+    if ( rc )
+        return rc;
+
+    /* (tsec, dsec) defaults the label to tsec, as it should here */
+    rc = security_transition_sid(tsec->sid, dsec->sid, SECCLASS_DOMAIN,
+                                 &dsec->target_sid);
+    return rc;
 }
 
 static int flask_domctl(struct domain *d, int cmd)
@@ -655,26 +679,24 @@ static int flask_domctl(struct domain *d, int cmd)
     case XEN_DOMCTL_gdbsx_pausevcpu:
     case XEN_DOMCTL_gdbsx_unpausevcpu:
     case XEN_DOMCTL_gdbsx_domstatus:
-        return domain_has_perm(current->domain, d, SECCLASS_DOMAIN,
-                               DOMAIN__SETDEBUGGING);
+        return current_has_perm(d, SECCLASS_DOMAIN, DOMAIN__SETDEBUGGING);
 
     case XEN_DOMCTL_subscribe:
     case XEN_DOMCTL_disable_migrate:
     case XEN_DOMCTL_suppress_spurious_page_faults:
-        return domain_has_perm(current->domain, d, SECCLASS_DOMAIN,
-                               DOMAIN__SET_MISC_INFO);
+        return current_has_perm(d, SECCLASS_DOMAIN, DOMAIN__SET_MISC_INFO);
 
     case XEN_DOMCTL_set_cpuid:
-        return domain_has_perm(current->domain, d, SECCLASS_DOMAIN2, DOMAIN2__SET_CPUID);
+        return current_has_perm(d, SECCLASS_DOMAIN2, DOMAIN2__SET_CPUID);
 
     case XEN_DOMCTL_gettscinfo:
-        return domain_has_perm(current->domain, d, SECCLASS_DOMAIN2, DOMAIN2__GETTSC);
+        return current_has_perm(d, SECCLASS_DOMAIN2, DOMAIN2__GETTSC);
 
     case XEN_DOMCTL_settscinfo:
-        return domain_has_perm(current->domain, d, SECCLASS_DOMAIN2, DOMAIN2__SETTSC);
+        return current_has_perm(d, SECCLASS_DOMAIN2, DOMAIN2__SETTSC);
 
     case XEN_DOMCTL_audit_p2m:
-        return domain_has_perm(current->domain, d, SECCLASS_HVM, HVM__AUDIT_P2M);
+        return current_has_perm(d, SECCLASS_HVM, HVM__AUDIT_P2M);
 
     default:
         printk("flask_domctl: Unknown op %d\n", cmd);
@@ -716,7 +738,7 @@ static int flask_sysctl(int cmd)
 
 static int flask_set_virq_handler(struct domain *d, uint32_t virq)
 {
-    return domain_has_perm(current->domain, d, SECCLASS_DOMAIN, DOMAIN__SET_VIRQ_HANDLER);
+    return current_has_perm(d, SECCLASS_DOMAIN, DOMAIN__SET_VIRQ_HANDLER);
 }
 
 static int flask_tbufcontrol(void)
@@ -741,20 +763,17 @@ static int flask_sched_id(void)
 
 static int flask_setdomainmaxmem(struct domain *d)
 {
-    return domain_has_perm(current->domain, d, SECCLASS_DOMAIN,
-                           DOMAIN__SETDOMAINMAXMEM);
+    return current_has_perm(d, SECCLASS_DOMAIN, DOMAIN__SETDOMAINMAXMEM);
 }
 
 static int flask_setdomainhandle(struct domain *d)
 {
-    return domain_has_perm(current->domain, d, SECCLASS_DOMAIN,
-                           DOMAIN__SETDOMAINHANDLE);
+    return current_has_perm(d, SECCLASS_DOMAIN, DOMAIN__SETDOMAINHANDLE);
 }
 
 static int flask_setdebugging(struct domain *d)
 {
-    return domain_has_perm(current->domain, d, SECCLASS_DOMAIN,
-                           DOMAIN__SETDEBUGGING);
+    return current_has_perm(d, SECCLASS_DOMAIN, DOMAIN__SETDEBUGGING);
 }
 
 static int flask_debug_keys(void)
@@ -816,14 +835,12 @@ static char *flask_show_irq_sid (int irq)
 
 static int flask_map_domain_pirq (struct domain *d, int irq, void *data)
 {
-    u32 sid;
+    u32 sid, dsid;
     int rc = -EPERM;
     struct msi_info *msi = data;
-
-    struct domain_security_struct *ssec, *tsec;
     struct avc_audit_data ad;
 
-    rc = domain_has_perm(current->domain, d, SECCLASS_RESOURCE, RESOURCE__ADD);
+    rc = current_has_perm(d, SECCLASS_RESOURCE, RESOURCE__ADD);
 
     if ( rc )
         return rc;
@@ -839,14 +856,13 @@ static int flask_map_domain_pirq (struct domain *d, int irq, void *data)
     if ( rc )
         return rc;
 
-    ssec = current->domain->ssid;
-    tsec = d->ssid;
+    dsid = domain_sid(d);
 
-    rc = avc_has_perm(ssec->sid, sid, SECCLASS_RESOURCE, RESOURCE__ADD_IRQ, &ad);
+    rc = avc_current_has_perm(sid, SECCLASS_RESOURCE, RESOURCE__ADD_IRQ, &ad);
     if ( rc )
         return rc;
 
-    rc = avc_has_perm(tsec->sid, sid, SECCLASS_RESOURCE, RESOURCE__USE, &ad);
+    rc = avc_has_perm(dsid, sid, SECCLASS_RESOURCE, RESOURCE__USE, &ad);
     return rc;
 }
 
@@ -854,16 +870,12 @@ static int flask_unmap_domain_pirq (struct domain *d, int irq)
 {
     u32 sid;
     int rc = -EPERM;
-
-    struct domain_security_struct *ssec;
     struct avc_audit_data ad;
 
-    rc = domain_has_perm(current->domain, d, SECCLASS_RESOURCE, RESOURCE__REMOVE);
+    rc = current_has_perm(d, SECCLASS_RESOURCE, RESOURCE__REMOVE);
     if ( rc )
         return rc;
 
-    ssec = current->domain->ssid;
-
     if ( irq >= nr_irqs_gsi ) {
         /* TODO support for MSI here */
         return 0;
@@ -873,19 +885,19 @@ static int flask_unmap_domain_pirq (struct domain *d, int irq)
     if ( rc )
         return rc;
 
-    rc = avc_has_perm(ssec->sid, sid, SECCLASS_RESOURCE, RESOURCE__REMOVE_IRQ, &ad);
+    rc = avc_current_has_perm(sid, SECCLASS_RESOURCE, RESOURCE__REMOVE_IRQ, &ad);
     return rc;
 }
 
 static int flask_irq_permission (struct domain *d, int pirq, uint8_t access)
 {
     /* the PIRQ number is not useful; real IRQ is checked during mapping */
-    return domain_has_perm(current->domain, d, SECCLASS_RESOURCE,
-                           resource_to_perm(access));
+    return current_has_perm(d, SECCLASS_RESOURCE, resource_to_perm(access));
 }
 
 struct iomem_has_perm_data {
-    struct domain_security_struct *ssec, *tsec;
+    u32 ssid;
+    u32 dsid;
     u32 perm;
 };
 
@@ -899,12 +911,12 @@ static int _iomem_has_perm(void *v, u32 sid, unsigned long start, unsigned long
     ad.range.start = start;
     ad.range.end = end;
 
-    rc = avc_has_perm(data->ssec->sid, sid, SECCLASS_RESOURCE, data->perm, &ad);
+    rc = avc_has_perm(data->ssid, sid, SECCLASS_RESOURCE, data->perm, &ad);
 
     if ( rc )
         return rc;
 
-    return avc_has_perm(data->tsec->sid, sid, SECCLASS_RESOURCE, RESOURCE__USE, &ad);
+    return avc_has_perm(data->dsid, sid, SECCLASS_RESOURCE, RESOURCE__USE, &ad);
 }
 
 static int flask_iomem_permission(struct domain *d, uint64_t start, uint64_t end, uint8_t access)
@@ -912,7 +924,7 @@ static int flask_iomem_permission(struct domain *d, uint64_t start, uint64_t end
     struct iomem_has_perm_data data;
     int rc;
 
-    rc = domain_has_perm(current->domain, d, SECCLASS_RESOURCE,
+    rc = current_has_perm(d, SECCLASS_RESOURCE,
                          resource_to_perm(access));
     if ( rc )
         return rc;
@@ -922,8 +934,8 @@ static int flask_iomem_permission(struct domain *d, uint64_t start, uint64_t end
     else
         data.perm = RESOURCE__REMOVE_IOMEM;
 
-    data.ssec = current->domain->ssid;
-    data.tsec = d->ssid;
+    data.ssid = domain_sid(current->domain);
+    data.dsid = domain_sid(d);
 
     return security_iterate_iomem_sids(start, end, _iomem_has_perm, &data);
 }
@@ -935,10 +947,9 @@ static int flask_iomem_mapping(struct domain *d, uint64_t start, uint64_t end, u
 
 static int flask_pci_config_permission(struct domain *d, uint32_t machine_bdf, uint16_t start, uint16_t end, uint8_t access)
 {
-    u32 rsid;
+    u32 dsid, rsid;
     int rc = -EPERM;
     struct avc_audit_data ad;
-    struct domain_security_struct *ssec;
     u32 perm = RESOURCE__USE;
 
     rc = security_device_sid(machine_bdf, &rsid);
@@ -951,33 +962,24 @@ static int flask_pci_config_permission(struct domain *d, uint32_t machine_bdf, u
 
     AVC_AUDIT_DATA_INIT(&ad, DEV);
     ad.device = (unsigned long) machine_bdf;
-    ssec = d->ssid;
-    return avc_has_perm(ssec->sid, rsid, SECCLASS_RESOURCE, perm, &ad);
+    dsid = domain_sid(d);
+    return avc_has_perm(dsid, rsid, SECCLASS_RESOURCE, perm, &ad);
 
 }
 
 static int flask_resource_plug_core(void)
 {
-    struct domain_security_struct *ssec;
-
-    ssec = current->domain->ssid;
-    return avc_has_perm(ssec->sid, SECINITSID_DOMXEN, SECCLASS_RESOURCE, RESOURCE__PLUG, NULL);
+    return avc_current_has_perm(SECINITSID_DOMXEN, SECCLASS_RESOURCE, RESOURCE__PLUG, NULL);
 }
 
 static int flask_resource_unplug_core(void)
 {
-    struct domain_security_struct *ssec;
-
-    ssec = current->domain->ssid;
-    return avc_has_perm(ssec->sid, SECINITSID_DOMXEN, SECCLASS_RESOURCE, RESOURCE__UNPLUG, NULL);
+    return avc_current_has_perm(SECINITSID_DOMXEN, SECCLASS_RESOURCE, RESOURCE__UNPLUG, NULL);
 }
 
 static int flask_resource_use_core(void)
 {
-    struct domain_security_struct *ssec;
-
-    ssec = current->domain->ssid;
-    return avc_has_perm(ssec->sid, SECINITSID_DOMXEN, SECCLASS_RESOURCE, RESOURCE__USE, NULL);
+    return avc_current_has_perm(SECINITSID_DOMXEN, SECCLASS_RESOURCE, RESOURCE__USE, NULL);
 }
 
 static int flask_resource_plug_pci(uint32_t machine_bdf)
@@ -985,7 +987,6 @@ static int flask_resource_plug_pci(uint32_t machine_bdf)
     u32 rsid;
     int rc = -EPERM;
     struct avc_audit_data ad;
-    struct domain_security_struct *ssec;
 
     rc = security_device_sid(machine_bdf, &rsid);
     if ( rc )
@@ -993,8 +994,7 @@ static int flask_resource_plug_pci(uint32_t machine_bdf)
 
     AVC_AUDIT_DATA_INIT(&ad, DEV);
     ad.device = (unsigned long) machine_bdf;
-    ssec = current->domain->ssid;
-    return avc_has_perm(ssec->sid, rsid, SECCLASS_RESOURCE, RESOURCE__PLUG, &ad);
+    return avc_current_has_perm(rsid, SECCLASS_RESOURCE, RESOURCE__PLUG, &ad);
 }
 
 static int flask_resource_unplug_pci(uint32_t machine_bdf)
@@ -1002,7 +1002,6 @@ static int flask_resource_unplug_pci(uint32_t machine_bdf)
     u32 rsid;
     int rc = -EPERM;
     struct avc_audit_data ad;
-    struct domain_security_struct *ssec;
 
     rc = security_device_sid(machine_bdf, &rsid);
     if ( rc )
@@ -1010,8 +1009,7 @@ static int flask_resource_unplug_pci(uint32_t machine_bdf)
 
     AVC_AUDIT_DATA_INIT(&ad, DEV);
     ad.device = (unsigned long) machine_bdf;
-    ssec = current->domain->ssid;
-    return avc_has_perm(ssec->sid, rsid, SECCLASS_RESOURCE, RESOURCE__UNPLUG, &ad);
+    return avc_current_has_perm(rsid, SECCLASS_RESOURCE, RESOURCE__UNPLUG, &ad);
 }
 
 static int flask_resource_setup_pci(uint32_t machine_bdf)
@@ -1019,7 +1017,6 @@ static int flask_resource_setup_pci(uint32_t machine_bdf)
     u32 rsid;
     int rc = -EPERM;
     struct avc_audit_data ad;
-    struct domain_security_struct *ssec;
 
     rc = security_device_sid(machine_bdf, &rsid);
     if ( rc )
@@ -1027,8 +1024,7 @@ static int flask_resource_setup_pci(uint32_t machine_bdf)
 
     AVC_AUDIT_DATA_INIT(&ad, DEV);
     ad.device = (unsigned long) machine_bdf;
-    ssec = current->domain->ssid;
-    return avc_has_perm(ssec->sid, rsid, SECCLASS_RESOURCE, RESOURCE__SETUP, &ad);
+    return avc_current_has_perm(rsid, SECCLASS_RESOURCE, RESOURCE__SETUP, &ad);
 }
 
 static int flask_resource_setup_gsi(int gsi)
@@ -1036,22 +1032,17 @@ static int flask_resource_setup_gsi(int gsi)
     u32 rsid;
     int rc = -EPERM;
     struct avc_audit_data ad;
-    struct domain_security_struct *ssec;
 
     rc = get_irq_sid(gsi, &rsid, &ad);
     if ( rc )
         return rc;
 
-    ssec = current->domain->ssid;
-    return avc_has_perm(ssec->sid, rsid, SECCLASS_RESOURCE, RESOURCE__SETUP, &ad);
+    return avc_current_has_perm(rsid, SECCLASS_RESOURCE, RESOURCE__SETUP, &ad);
 }
 
 static int flask_resource_setup_misc(void)
 {
-    struct domain_security_struct *ssec;
-
-    ssec = current->domain->ssid;
-    return avc_has_perm(ssec->sid, SECINITSID_XEN, SECCLASS_RESOURCE, RESOURCE__SETUP, NULL);
+    return avc_current_has_perm(SECINITSID_XEN, SECCLASS_RESOURCE, RESOURCE__SETUP, NULL);
 }
 
 static inline int flask_page_offline(uint32_t cmd)
@@ -1114,11 +1105,12 @@ static int flask_shadow_control(struct domain *d, uint32_t op)
         return -EPERM;
     }
 
-    return domain_has_perm(current->domain, d, SECCLASS_SHADOW, perm);
+    return current_has_perm(d, SECCLASS_SHADOW, perm);
 }
 
 struct ioport_has_perm_data {
-    struct domain_security_struct *ssec, *tsec;
+    u32 ssid;
+    u32 dsid;
     u32 perm;
 };
 
@@ -1132,12 +1124,12 @@ static int _ioport_has_perm(void *v, u32 sid, unsigned long start, unsigned long
     ad.range.start = start;
     ad.range.end = end;
 
-    rc = avc_has_perm(data->ssec->sid, sid, SECCLASS_RESOURCE, data->perm, &ad);
+    rc = avc_has_perm(data->ssid, sid, SECCLASS_RESOURCE, data->perm, &ad);
 
     if ( rc )
         return rc;
 
-    return avc_has_perm(data->tsec->sid, sid, SECCLASS_RESOURCE, RESOURCE__USE, &ad);
+    return avc_has_perm(data->dsid, sid, SECCLASS_RESOURCE, RESOURCE__USE, &ad);
 }
 
 static int flask_ioport_permission(struct domain *d, uint32_t start, uint32_t end, uint8_t access)
@@ -1145,7 +1137,7 @@ static int flask_ioport_permission(struct domain *d, uint32_t start, uint32_t en
     int rc;
     struct ioport_has_perm_data data;
 
-    rc = domain_has_perm(current->domain, d, SECCLASS_RESOURCE,
+    rc = current_has_perm(d, SECCLASS_RESOURCE,
                          resource_to_perm(access));
 
     if ( rc )
@@ -1156,8 +1148,8 @@ static int flask_ioport_permission(struct domain *d, uint32_t start, uint32_t en
     else
         data.perm = RESOURCE__REMOVE_IOPORT;
 
-    data.ssec = current->domain->ssid;
-    data.tsec = d->ssid;
+    data.ssid = domain_sid(current->domain);
+    data.dsid = domain_sid(d);
 
     return security_iterate_ioport_sids(start, end, _ioport_has_perm, &data);
 }
@@ -1169,18 +1161,17 @@ static int flask_ioport_mapping(struct domain *d, uint32_t start, uint32_t end,
 
 static int flask_getpageframeinfo(struct domain *d)
 {
-    return domain_has_perm(current->domain, d, SECCLASS_MMU, MMU__PAGEINFO);
+    return current_has_perm(d, SECCLASS_MMU, MMU__PAGEINFO);
 }
 
 static int flask_getmemlist(struct domain *d)
 {
-    return domain_has_perm(current->domain, d, SECCLASS_MMU, MMU__PAGELIST);
+    return current_has_perm(d, SECCLASS_MMU, MMU__PAGELIST);
 }
 
 static int flask_hypercall_init(struct domain *d)
 {
-    return domain_has_perm(current->domain, d, SECCLASS_DOMAIN,
-                           DOMAIN__HYPERCALL);
+    return current_has_perm(d, SECCLASS_DOMAIN, DOMAIN__HYPERCALL);
 }
 
 static int flask_hvmcontext(struct domain *d, uint32_t cmd)
@@ -1203,7 +1194,7 @@ static int flask_hvmcontext(struct domain *d, uint32_t cmd)
         return -EPERM;
     }
 
-    return domain_has_perm(current->domain, d, SECCLASS_HVM, perm);
+    return current_has_perm(d, SECCLASS_HVM, perm);
 }
 
 static int flask_address_size(struct domain *d, uint32_t cmd)
@@ -1222,7 +1213,7 @@ static int flask_address_size(struct domain *d, uint32_t cmd)
         return -EPERM;
     }
 
-    return domain_has_perm(current->domain, d, SECCLASS_DOMAIN, perm);
+    return current_has_perm(d, SECCLASS_DOMAIN, perm);
 }
 
 static int flask_machine_address_size(struct domain *d, uint32_t cmd)
@@ -1263,37 +1254,37 @@ static int flask_hvm_param(struct domain *d, unsigned long op)
         perm = HVM__HVMCTL;
     }
 
-    return domain_has_perm(current->domain, d, SECCLASS_HVM, perm);
+    return current_has_perm(d, SECCLASS_HVM, perm);
 }
 
 static int flask_hvm_set_pci_intx_level(struct domain *d)
 {
-    return domain_has_perm(current->domain, d, SECCLASS_HVM, HVM__PCILEVEL);
+    return current_has_perm(d, SECCLASS_HVM, HVM__PCILEVEL);
 }
 
 static int flask_hvm_set_isa_irq_level(struct domain *d)
 {
-    return domain_has_perm(current->domain, d, SECCLASS_HVM, HVM__IRQLEVEL);
+    return current_has_perm(d, SECCLASS_HVM, HVM__IRQLEVEL);
 }
 
 static int flask_hvm_set_pci_link_route(struct domain *d)
 {
-    return domain_has_perm(current->domain, d, SECCLASS_HVM, HVM__PCIROUTE);
+    return current_has_perm(d, SECCLASS_HVM, HVM__PCIROUTE);
 }
 
 static int flask_hvm_inject_msi(struct domain *d)
 {
-    return domain_has_perm(current->domain, d, SECCLASS_HVM, HVM__SEND_IRQ);
+    return current_has_perm(d, SECCLASS_HVM, HVM__SEND_IRQ);
 }
 
 static int flask_mem_event(struct domain *d)
 {
-    return domain_has_perm(current->domain, d, SECCLASS_HVM, HVM__MEM_EVENT);
+    return current_has_perm(d, SECCLASS_HVM, HVM__MEM_EVENT);
 }
 
 static int flask_mem_sharing(struct domain *d)
 {
-    return domain_has_perm(current->domain, d, SECCLASS_HVM, HVM__MEM_SHARING);
+    return current_has_perm(d, SECCLASS_HVM, HVM__MEM_SHARING);
 }
 
 static int flask_apic(struct domain *d, int cmd)
@@ -1355,11 +1346,7 @@ static int flask_physinfo(void)
 
 static int flask_platform_quirk(uint32_t quirk)
 {
-    struct domain_security_struct *dsec;
-    dsec = current->domain->ssid;
-
-    return avc_has_perm(dsec->sid, SECINITSID_XEN, SECCLASS_XEN, 
-                        XEN__QUIRK, NULL);
+    return avc_current_has_perm(SECINITSID_XEN, SECCLASS_XEN, XEN__QUIRK, NULL);
 }
 
 static int flask_platform_op(uint32_t op)
@@ -1421,16 +1408,12 @@ static int flask_getidletime(void)
 
 static int flask_machine_memory_map(void)
 {
-    struct domain_security_struct *dsec;
-    dsec = current->domain->ssid;
-
-    return avc_has_perm(dsec->sid, SECINITSID_XEN, SECCLASS_MMU, 
-                        MMU__MEMORYMAP, NULL);
+    return avc_current_has_perm(SECINITSID_XEN, SECCLASS_MMU, MMU__MEMORYMAP, NULL);
 }
 
 static int flask_domain_memory_map(struct domain *d)
 {
-    return domain_has_perm(current->domain, d, SECCLASS_MMU, MMU__MEMORYMAP);
+    return current_has_perm(d, SECCLASS_MMU, MMU__MEMORYMAP);
 }
 
 static int domain_memory_perm(struct domain *d, struct domain *f, l1_pgentry_t pte)
@@ -1453,17 +1436,17 @@ static int domain_memory_perm(struct domain *d, struct domain *f, l1_pgentry_t p
     if ( f->domain_id == DOMID_IO || !mfn_valid(fmfn) )
     {
         struct avc_audit_data ad;
-        struct domain_security_struct *dsec = d->ssid;
-        u32 fsid;
+        u32 dsid, fsid;
+        rc = security_iomem_sid(fmfn, &fsid);
+        if ( rc )
+            return rc;
         AVC_AUDIT_DATA_INIT(&ad, MEMORY);
         ad.sdom = d;
         ad.tdom = f;
         ad.memory.pte = pte.l1;
         ad.memory.mfn = fmfn;
-        rc = security_iomem_sid(fmfn, &fsid);
-        if ( rc )
-            return rc;
-        return avc_has_perm(dsec->sid, fsid, SECCLASS_MMU, map_perms, &ad);
+        dsid = domain_sid(d);
+        return avc_has_perm(dsid, fsid, SECCLASS_MMU, map_perms, &ad);
     }
 
     return domain_has_perm(d, f, SECCLASS_MMU, map_perms);
@@ -1506,43 +1489,40 @@ static int flask_remove_from_physmap(struct domain *d1, struct domain *d2)
 
 static int flask_sendtrigger(struct domain *d)
 {
-    return domain_has_perm(current->domain, d, SECCLASS_DOMAIN, DOMAIN__TRIGGER);
+    return current_has_perm(d, SECCLASS_DOMAIN, DOMAIN__TRIGGER);
 }
 
 static int flask_get_device_group(uint32_t machine_bdf)
 {
     u32 rsid;
     int rc = -EPERM;
-    struct domain_security_struct *ssec = current->domain->ssid;
 
     rc = security_device_sid(machine_bdf, &rsid);
     if ( rc )
         return rc;
 
-    return avc_has_perm(ssec->sid, rsid, SECCLASS_RESOURCE, RESOURCE__STAT_DEVICE, NULL);
+    return avc_current_has_perm(rsid, SECCLASS_RESOURCE, RESOURCE__STAT_DEVICE, NULL);
 }
 
 static int flask_test_assign_device(uint32_t machine_bdf)
 {
     u32 rsid;
     int rc = -EPERM;
-    struct domain_security_struct *ssec = current->domain->ssid;
 
     rc = security_device_sid(machine_bdf, &rsid);
     if ( rc )
         return rc;
 
-    return rc = avc_has_perm(ssec->sid, rsid, SECCLASS_RESOURCE, RESOURCE__STAT_DEVICE, NULL);
+    return avc_current_has_perm(rsid, SECCLASS_RESOURCE, RESOURCE__STAT_DEVICE, NULL);
 }
 
 static int flask_assign_device(struct domain *d, uint32_t machine_bdf)
 {
-    u32 rsid;
+    u32 dsid, rsid;
     int rc = -EPERM;
-    struct domain_security_struct *ssec, *tsec;
     struct avc_audit_data ad;
 
-    rc = domain_has_perm(current->domain, d, SECCLASS_RESOURCE, RESOURCE__ADD);
+    rc = current_has_perm(d, SECCLASS_RESOURCE, RESOURCE__ADD);
     if ( rc )
         return rc;
 
@@ -1552,22 +1532,20 @@ static int flask_assign_device(struct domain *d, uint32_t machine_bdf)
 
     AVC_AUDIT_DATA_INIT(&ad, DEV);
     ad.device = (unsigned long) machine_bdf;
-    ssec = current->domain->ssid;
-    rc = avc_has_perm(ssec->sid, rsid, SECCLASS_RESOURCE, RESOURCE__ADD_DEVICE, &ad);
+    rc = avc_current_has_perm(rsid, SECCLASS_RESOURCE, RESOURCE__ADD_DEVICE, &ad);
     if ( rc )
         return rc;
 
-    tsec = d->ssid;
-    return avc_has_perm(tsec->sid, rsid, SECCLASS_RESOURCE, RESOURCE__USE, &ad);
+    dsid = domain_sid(d);
+    return avc_has_perm(dsid, rsid, SECCLASS_RESOURCE, RESOURCE__USE, &ad);
 }
 
 static int flask_deassign_device(struct domain *d, uint32_t machine_bdf)
 {
     u32 rsid;
     int rc = -EPERM;
-    struct domain_security_struct *ssec = current->domain->ssid;
 
-    rc = domain_has_perm(current->domain, d, SECCLASS_RESOURCE, RESOURCE__REMOVE);
+    rc = current_has_perm(d, SECCLASS_RESOURCE, RESOURCE__REMOVE);
     if ( rc )
         return rc;
 
@@ -1575,18 +1553,17 @@ static int flask_deassign_device(struct domain *d, uint32_t machine_bdf)
     if ( rc )
         return rc;
 
-    return rc = avc_has_perm(ssec->sid, rsid, SECCLASS_RESOURCE, RESOURCE__REMOVE_DEVICE, NULL);
+    return avc_current_has_perm(rsid, SECCLASS_RESOURCE, RESOURCE__REMOVE_DEVICE, NULL);
 }
 
 static int flask_bind_pt_irq (struct domain *d, struct xen_domctl_bind_pt_irq *bind)
 {
-    u32 rsid;
+    u32 dsid, rsid;
     int rc = -EPERM;
     int irq;
-    struct domain_security_struct *ssec, *tsec;
     struct avc_audit_data ad;
 
-    rc = domain_has_perm(current->domain, d, SECCLASS_RESOURCE, RESOURCE__ADD);
+    rc = current_has_perm(d, SECCLASS_RESOURCE, RESOURCE__ADD);
     if ( rc )
         return rc;
 
@@ -1596,23 +1573,22 @@ static int flask_bind_pt_irq (struct domain *d, struct xen_domctl_bind_pt_irq *b
     if ( rc )
         return rc;
 
-    ssec = current->domain->ssid;
-    rc = avc_has_perm(ssec->sid, rsid, SECCLASS_HVM, HVM__BIND_IRQ, &ad);
+    rc = avc_current_has_perm(rsid, SECCLASS_HVM, HVM__BIND_IRQ, &ad);
     if ( rc )
         return rc;
 
-    tsec = d->ssid;
-    return avc_has_perm(tsec->sid, rsid, SECCLASS_RESOURCE, RESOURCE__USE, &ad);
+    dsid = domain_sid(d);
+    return avc_has_perm(dsid, rsid, SECCLASS_RESOURCE, RESOURCE__USE, &ad);
 }
 
 static int flask_unbind_pt_irq (struct domain *d, struct xen_domctl_bind_pt_irq *bind)
 {
-    return domain_has_perm(current->domain, d, SECCLASS_RESOURCE, RESOURCE__REMOVE);
+    return current_has_perm(d, SECCLASS_RESOURCE, RESOURCE__REMOVE);
 }
 
 static int flask_pin_mem_cacheattr (struct domain *d)
 {
-    return domain_has_perm(current->domain, d, SECCLASS_HVM, HVM__CACHEATTR);
+    return current_has_perm(d, SECCLASS_HVM, HVM__CACHEATTR);
 }
 
 static int flask_ext_vcpucontext (struct domain *d, uint32_t cmd)
@@ -1631,7 +1607,7 @@ static int flask_ext_vcpucontext (struct domain *d, uint32_t cmd)
         return -EPERM;
     }
 
-    return domain_has_perm(current->domain, d, SECCLASS_DOMAIN, perm);
+    return current_has_perm(d, SECCLASS_DOMAIN, perm);
 }
 
 static int flask_vcpuextstate (struct domain *d, uint32_t cmd)
@@ -1650,7 +1626,7 @@ static int flask_vcpuextstate (struct domain *d, uint32_t cmd)
             return -EPERM;
     }
 
-    return domain_has_perm(current->domain, d, SECCLASS_DOMAIN, perm);
+    return current_has_perm(d, SECCLASS_DOMAIN, perm);
 }
 #endif
 
diff --git a/xen/xsm/flask/include/objsec.h b/xen/xsm/flask/include/objsec.h
index 4ff52be..6595dc3 100644
--- a/xen/xsm/flask/include/objsec.h
+++ b/xen/xsm/flask/include/objsec.h
@@ -19,6 +19,8 @@
 
 struct domain_security_struct {
     u32 sid;               /* current SID */
+    u32 self_sid;          /* SID for target when operating on DOMID_SELF */
+    u32 target_sid;        /* SID for device model target domain */
 };
 
 struct evtchn_security_struct {
-- 
1.7.11.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 17 15:24:30 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 15:24:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDdB9-0003ao-Dl; Mon, 17 Sep 2012 15:24:07 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1TDdB7-0003Zv-Dk
	for xen-devel@lists.xen.org; Mon, 17 Sep 2012 15:24:05 +0000
Received: from [85.158.139.211:49314] by server-1.bemta-5.messagelabs.com id
	3A/E9-32692-49047505; Mon, 17 Sep 2012 15:24:04 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-12.tower-206.messagelabs.com!1347895443!18848088!1
X-Originating-IP: [63.239.67.9]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18749 invoked from network); 17 Sep 2012 15:24:03 -0000
Received: from emvm-gh1-uea08.nsa.gov (HELO nsa.gov) (63.239.67.9)
	by server-12.tower-206.messagelabs.com with SMTP;
	17 Sep 2012 15:24:03 -0000
X-TM-IMSS-Message-ID: <538033680012accf@nsa.gov>
Received: from tarius.tycho.ncsc.mil ([144.51.3.1]) by nsa.gov ([63.239.67.9])
	with ESMTP (TREND IMSS SMTP Service 7.1) id 538033680012accf ;
	Mon, 17 Sep 2012 11:23:43 -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 q8HFO0xW027504; 
	Mon, 17 Sep 2012 11:24:02 -0400
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xen.org
Date: Mon, 17 Sep 2012 11:23:28 -0400
Message-Id: <1347895425-17959-7-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.11.4
In-Reply-To: <1347895425-17959-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1347895425-17959-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: dgdegra@tycho.nsa.gov, keir@xen.org
Subject: [Xen-devel] [PATCH 06/23] flask/policy: Add domain relabel example
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This adds the nomigrate_t type to the example FLASK policy which allows
domains to be created that dom0 cannot access after building.

Example domain configuration snippet:
  seclabel='customer_1:vm_r:nomigrate_t'
  init_seclabel='customer_1:vm_r:nomigrate_t_building'

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 docs/misc/xsm-flask.txt                      |  2 +
 tools/flask/policy/policy/modules/xen/xen.if | 56 +++++++++++++++++++++-------
 tools/flask/policy/policy/modules/xen/xen.te | 10 +++++
 3 files changed, 55 insertions(+), 13 deletions(-)

diff --git a/docs/misc/xsm-flask.txt b/docs/misc/xsm-flask.txt
index 6b0d327..0778a28 100644
--- a/docs/misc/xsm-flask.txt
+++ b/docs/misc/xsm-flask.txt
@@ -60,6 +60,8 @@ that can be used without dom0 disaggregation. The main types for domUs are:
  - domU_t is a domain that can communicate with any other domU_t
  - isolated_domU_t can only communicate with dom0
  - prot_domU_t is a domain type whose creation can be disabled with a boolean
+ - nomigrate_t is a domain that must be created via the nomigrate_t_building
+   type, and whose memory cannot be read by dom0 once created
 
 HVM domains with stubdomain device models use two types (one per domain):
  - domHVM_t is an HVM domain that uses a stubdomain device model
diff --git a/tools/flask/policy/policy/modules/xen/xen.if b/tools/flask/policy/policy/modules/xen/xen.if
index 3f58909..2ad11b2 100644
--- a/tools/flask/policy/policy/modules/xen/xen.if
+++ b/tools/flask/policy/policy/modules/xen/xen.if
@@ -9,24 +9,47 @@
 #   Declare a type as a domain type, and allow basic domain setup
 define(`declare_domain', `
 	type $1, domain_type`'ifelse(`$#', `1', `', `,shift($@)');
+	type $1_channel, event_type;
+	type_transition $1 domain_type:event $1_channel;
 	allow $1 $1:grant { query setup };
 	allow $1 $1:mmu { adjust physmap map_read map_write stat pinpage };
 	allow $1 $1:hvm { getparam setparam };
 ')
 
-# create_domain(priv, target)
-#   Allow a domain to be created
-define(`create_domain', `
+# declare_build_label(type)
+#   Declare a paired _building type for the given domain type
+define(`declare_build_label', `
+	type $1_building, domain_type;
+	type_transition $1_building domain_type:event $1_channel;
+	allow $1_building $1 : domain transition;
+')
+
+define(`create_domain_common', `
 	allow $1 $2:domain { create max_vcpus setdomainmaxmem setaddrsize
-			getdomaininfo hypercall setvcpucontext scheduler
-			unpause getvcpuinfo getvcpuextstate getaddrsize
-			getvcpuaffinity };
+			getdomaininfo hypercall setvcpucontext setextvcpucontext
+			scheduler getvcpuinfo getvcpuextstate getaddrsize
+			getvcpuaffinity setvcpuaffinity };
 	allow $1 $2:security check_context;
 	allow $1 $2:shadow enable;
 	allow $1 $2:mmu {map_read map_write adjust memorymap physmap pinpage};
 	allow $1 $2:grant setup;
-	allow $1 $2:hvm { cacheattr getparam hvmctl irqlevel pciroute setparam pcilevel trackdirtyvram };
-	allow $1 $2_$1_channel:event create;
+	allow $1 $2:hvm { cacheattr getparam hvmctl irqlevel pciroute sethvmc setparam pcilevel trackdirtyvram };
+')
+
+# create_domain(priv, target)
+#   Allow a domain to be created directly
+define(`create_domain', `
+	create_domain_common($1, $2)
+	allow $1 $2_channel:event create;
+')
+
+# create_domain_build_label(priv, target)
+#   Allow a domain to be created via its domain build label
+define(`create_domain_build_label', `
+	create_domain_common($1, $2_building)
+	allow $1 $2_channel:event create;
+	allow $1 $2_building:domain2 relabelfrom;
+	allow $1 $2:domain2 relabelto;
 ')
 
 # manage_domain(priv, target)
@@ -37,6 +60,15 @@ define(`manage_domain', `
 			setvcpuaffinity setdomainmaxmem };
 ')
 
+# migrate_domain_out(priv, target)
+#   Allow creation of a snapshot or migration image from a domain
+#   (inbound migration is the same as domain creation)
+define(`migrate_domain_out', `
+	allow $1 $2:hvm { gethvmc getparam irqlevel };
+	allow $1 $2:mmu { stat pageinfo map_read };
+	allow $1 $2:domain { getaddrsize getvcpucontext getextvcpucontext getvcpuextstate pause destroy };
+')
+
 ################################################################################
 #
 # Inter-domain communication
@@ -47,8 +79,6 @@ define(`manage_domain', `
 #   This allows an event channel to be created from domains with labels
 #   <source> to <dest> and will label it <chan-label>
 define(`create_channel', `
-	type $3, event_type;
-	type_transition $1 $2:event $3;
 	allow $1 $3:event { create send status };
 	allow $3 $2:event { bind };
 ')
@@ -56,8 +86,8 @@ define(`create_channel', `
 # domain_event_comms(dom1, dom2)
 #   Allow two domain types to communicate using event channels
 define(`domain_event_comms', `
-	create_channel($1, $2, $1_$2_channel)
-	create_channel($2, $1, $2_$1_channel)
+	create_channel($1, $2, $1_channel)
+	create_channel($2, $1, $2_channel)
 ')
 
 # domain_comms(dom1, dom2)
@@ -72,7 +102,7 @@ define(`domain_comms', `
 #   Allow a domain types to communicate with others of its type using grants
 #   and event channels (this includes event channels to DOMID_SELF)
 define(`domain_self_comms', `
-	create_channel($1, $1, $1_self_channel)
+	create_channel($1, $1, $1_channel)
 	allow $1 $1:grant { map_read map_write copy unmap };
 ')
 
diff --git a/tools/flask/policy/policy/modules/xen/xen.te b/tools/flask/policy/policy/modules/xen/xen.te
index 9550397..1162153 100644
--- a/tools/flask/policy/policy/modules/xen/xen.te
+++ b/tools/flask/policy/policy/modules/xen/xen.te
@@ -90,6 +90,7 @@ create_domain(dom0_t, isolated_domU_t)
 manage_domain(dom0_t, isolated_domU_t)
 domain_comms(dom0_t, isolated_domU_t)
 
+# Declare a boolean that denies creation of prot_domU_t domains
 gen_bool(prot_doms_locked, false)
 declare_domain(prot_domU_t)
 if (!prot_doms_locked) {
@@ -111,6 +112,15 @@ manage_domain(dom0_t, dm_dom_t)
 domain_comms(dom0_t, dm_dom_t)
 device_model(dm_dom_t, domHVM_t)
 
+# nomigrate_t must be built via the nomigrate_t_building label; once built,
+# dom0 cannot read its memory.
+declare_domain(nomigrate_t)
+declare_build_label(nomigrate_t)
+create_domain_build_label(dom0_t, nomigrate_t)
+manage_domain(dom0_t, nomigrate_t)
+domain_comms(dom0_t, nomigrate_t)
+domain_self_comms(nomigrate_t)
+
 ###############################################################################
 #
 # Device delegation
-- 
1.7.11.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 17 15:24:30 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 15:24:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDdB9-0003ao-Dl; Mon, 17 Sep 2012 15:24:07 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1TDdB7-0003Zv-Dk
	for xen-devel@lists.xen.org; Mon, 17 Sep 2012 15:24:05 +0000
Received: from [85.158.139.211:49314] by server-1.bemta-5.messagelabs.com id
	3A/E9-32692-49047505; Mon, 17 Sep 2012 15:24:04 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-12.tower-206.messagelabs.com!1347895443!18848088!1
X-Originating-IP: [63.239.67.9]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18749 invoked from network); 17 Sep 2012 15:24:03 -0000
Received: from emvm-gh1-uea08.nsa.gov (HELO nsa.gov) (63.239.67.9)
	by server-12.tower-206.messagelabs.com with SMTP;
	17 Sep 2012 15:24:03 -0000
X-TM-IMSS-Message-ID: <538033680012accf@nsa.gov>
Received: from tarius.tycho.ncsc.mil ([144.51.3.1]) by nsa.gov ([63.239.67.9])
	with ESMTP (TREND IMSS SMTP Service 7.1) id 538033680012accf ;
	Mon, 17 Sep 2012 11:23:43 -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 q8HFO0xW027504; 
	Mon, 17 Sep 2012 11:24:02 -0400
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xen.org
Date: Mon, 17 Sep 2012 11:23:28 -0400
Message-Id: <1347895425-17959-7-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.11.4
In-Reply-To: <1347895425-17959-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1347895425-17959-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: dgdegra@tycho.nsa.gov, keir@xen.org
Subject: [Xen-devel] [PATCH 06/23] flask/policy: Add domain relabel example
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This adds the nomigrate_t type to the example FLASK policy which allows
domains to be created that dom0 cannot access after building.

Example domain configuration snippet:
  seclabel='customer_1:vm_r:nomigrate_t'
  init_seclabel='customer_1:vm_r:nomigrate_t_building'

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 docs/misc/xsm-flask.txt                      |  2 +
 tools/flask/policy/policy/modules/xen/xen.if | 56 +++++++++++++++++++++-------
 tools/flask/policy/policy/modules/xen/xen.te | 10 +++++
 3 files changed, 55 insertions(+), 13 deletions(-)

diff --git a/docs/misc/xsm-flask.txt b/docs/misc/xsm-flask.txt
index 6b0d327..0778a28 100644
--- a/docs/misc/xsm-flask.txt
+++ b/docs/misc/xsm-flask.txt
@@ -60,6 +60,8 @@ that can be used without dom0 disaggregation. The main types for domUs are:
  - domU_t is a domain that can communicate with any other domU_t
  - isolated_domU_t can only communicate with dom0
  - prot_domU_t is a domain type whose creation can be disabled with a boolean
+ - nomigrate_t is a domain that must be created via the nomigrate_t_building
+   type, and whose memory cannot be read by dom0 once created
 
 HVM domains with stubdomain device models use two types (one per domain):
  - domHVM_t is an HVM domain that uses a stubdomain device model
diff --git a/tools/flask/policy/policy/modules/xen/xen.if b/tools/flask/policy/policy/modules/xen/xen.if
index 3f58909..2ad11b2 100644
--- a/tools/flask/policy/policy/modules/xen/xen.if
+++ b/tools/flask/policy/policy/modules/xen/xen.if
@@ -9,24 +9,47 @@
 #   Declare a type as a domain type, and allow basic domain setup
 define(`declare_domain', `
 	type $1, domain_type`'ifelse(`$#', `1', `', `,shift($@)');
+	type $1_channel, event_type;
+	type_transition $1 domain_type:event $1_channel;
 	allow $1 $1:grant { query setup };
 	allow $1 $1:mmu { adjust physmap map_read map_write stat pinpage };
 	allow $1 $1:hvm { getparam setparam };
 ')
 
-# create_domain(priv, target)
-#   Allow a domain to be created
-define(`create_domain', `
+# declare_build_label(type)
+#   Declare a paired _building type for the given domain type
+define(`declare_build_label', `
+	type $1_building, domain_type;
+	type_transition $1_building domain_type:event $1_channel;
+	allow $1_building $1 : domain transition;
+')
+
+define(`create_domain_common', `
 	allow $1 $2:domain { create max_vcpus setdomainmaxmem setaddrsize
-			getdomaininfo hypercall setvcpucontext scheduler
-			unpause getvcpuinfo getvcpuextstate getaddrsize
-			getvcpuaffinity };
+			getdomaininfo hypercall setvcpucontext setextvcpucontext
+			scheduler getvcpuinfo getvcpuextstate getaddrsize
+			getvcpuaffinity setvcpuaffinity };
 	allow $1 $2:security check_context;
 	allow $1 $2:shadow enable;
 	allow $1 $2:mmu {map_read map_write adjust memorymap physmap pinpage};
 	allow $1 $2:grant setup;
-	allow $1 $2:hvm { cacheattr getparam hvmctl irqlevel pciroute setparam pcilevel trackdirtyvram };
-	allow $1 $2_$1_channel:event create;
+	allow $1 $2:hvm { cacheattr getparam hvmctl irqlevel pciroute sethvmc setparam pcilevel trackdirtyvram };
+')
+
+# create_domain(priv, target)
+#   Allow a domain to be created directly
+define(`create_domain', `
+	create_domain_common($1, $2)
+	allow $1 $2_channel:event create;
+')
+
+# create_domain_build_label(priv, target)
+#   Allow a domain to be created via its domain build label
+define(`create_domain_build_label', `
+	create_domain_common($1, $2_building)
+	allow $1 $2_channel:event create;
+	allow $1 $2_building:domain2 relabelfrom;
+	allow $1 $2:domain2 relabelto;
 ')
 
 # manage_domain(priv, target)
@@ -37,6 +60,15 @@ define(`manage_domain', `
 			setvcpuaffinity setdomainmaxmem };
 ')
 
+# migrate_domain_out(priv, target)
+#   Allow creation of a snapshot or migration image from a domain
+#   (inbound migration is the same as domain creation)
+define(`migrate_domain_out', `
+	allow $1 $2:hvm { gethvmc getparam irqlevel };
+	allow $1 $2:mmu { stat pageinfo map_read };
+	allow $1 $2:domain { getaddrsize getvcpucontext getextvcpucontext getvcpuextstate pause destroy };
+')
+
 ################################################################################
 #
 # Inter-domain communication
@@ -47,8 +79,6 @@ define(`manage_domain', `
 #   This allows an event channel to be created from domains with labels
 #   <source> to <dest> and will label it <chan-label>
 define(`create_channel', `
-	type $3, event_type;
-	type_transition $1 $2:event $3;
 	allow $1 $3:event { create send status };
 	allow $3 $2:event { bind };
 ')
@@ -56,8 +86,8 @@ define(`create_channel', `
 # domain_event_comms(dom1, dom2)
 #   Allow two domain types to communicate using event channels
 define(`domain_event_comms', `
-	create_channel($1, $2, $1_$2_channel)
-	create_channel($2, $1, $2_$1_channel)
+	create_channel($1, $2, $1_channel)
+	create_channel($2, $1, $2_channel)
 ')
 
 # domain_comms(dom1, dom2)
@@ -72,7 +102,7 @@ define(`domain_comms', `
 #   Allow a domain types to communicate with others of its type using grants
 #   and event channels (this includes event channels to DOMID_SELF)
 define(`domain_self_comms', `
-	create_channel($1, $1, $1_self_channel)
+	create_channel($1, $1, $1_channel)
 	allow $1 $1:grant { map_read map_write copy unmap };
 ')
 
diff --git a/tools/flask/policy/policy/modules/xen/xen.te b/tools/flask/policy/policy/modules/xen/xen.te
index 9550397..1162153 100644
--- a/tools/flask/policy/policy/modules/xen/xen.te
+++ b/tools/flask/policy/policy/modules/xen/xen.te
@@ -90,6 +90,7 @@ create_domain(dom0_t, isolated_domU_t)
 manage_domain(dom0_t, isolated_domU_t)
 domain_comms(dom0_t, isolated_domU_t)
 
+# Declare a boolean that denies creation of prot_domU_t domains
 gen_bool(prot_doms_locked, false)
 declare_domain(prot_domU_t)
 if (!prot_doms_locked) {
@@ -111,6 +112,15 @@ manage_domain(dom0_t, dm_dom_t)
 domain_comms(dom0_t, dm_dom_t)
 device_model(dm_dom_t, domHVM_t)
 
+# nomigrate_t must be built via the nomigrate_t_building label; once built,
+# dom0 cannot read its memory.
+declare_domain(nomigrate_t)
+declare_build_label(nomigrate_t)
+create_domain_build_label(dom0_t, nomigrate_t)
+manage_domain(dom0_t, nomigrate_t)
+domain_comms(dom0_t, nomigrate_t)
+domain_self_comms(nomigrate_t)
+
 ###############################################################################
 #
 # Device delegation
-- 
1.7.11.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 17 15:56:46 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 15:56: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 1TDdgS-0007ZF-IZ; Mon, 17 Sep 2012 15:56:28 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dunlapg@gmail.com>) id 1TDdgR-0007ZA-0G
	for xen-devel@lists.xen.org; Mon, 17 Sep 2012 15:56:27 +0000
Received: from [85.158.143.35:18345] by server-2.bemta-4.messagelabs.com id
	90/96-06610-A2847505; Mon, 17 Sep 2012 15:56:26 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1347897365!17273758!1
X-Originating-IP: [209.85.212.173]
X-SpamReason: No, hits=0.6 required=7.0 tests=MAILTO_TO_SPAM_ADDR, RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4464 invoked from network); 17 Sep 2012 15:56:09 -0000
Received: from mail-wi0-f173.google.com (HELO mail-wi0-f173.google.com)
	(209.85.212.173)
	by server-13.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Sep 2012 15:56:09 -0000
Received: by wibhm6 with SMTP id hm6so2278886wib.14
	for <xen-devel@lists.xen.org>; Mon, 17 Sep 2012 08:56:05 -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=/VsNGC0JuoyoLjbKesgS4fovjM6rE8jnFYXMFau/j2U=;
	b=VsISoT6D69r1EuFDzXdcWwGQRSikxG2y2L2mgfWSYc1hKLQ/spHmcpeT2KbWhxhB2B
	feNWKZ2+93ILp1umLZ4EEynvYNhNuxYZ4mVWz/QqaraFXUnq7T3o9WOC7TvHvnECTLgf
	gGWv8LT7WdEolWmHOiOfIBRGpumkoujra2UrVwabnAbgt+QGvWM5RFsnS4GDEgJW4Fvy
	sqDF0KvyrHpdSl9qiUqzwJqMeEE39e+T4dZqf9BX2NYmEdLp+WabuWuCg9aa5PP0BgWN
	Tdg/tUTdsTLmHLWo8rP1oP7DNlHfSnBsDYfDQ1CMjfNRGcSaNTjFx3JugNA3i7AUx7Ls
	Cglw==
MIME-Version: 1.0
Received: by 10.180.98.200 with SMTP id ek8mr17116702wib.0.1347897364840; Mon,
	17 Sep 2012 08:56:04 -0700 (PDT)
Received: by 10.223.94.75 with HTTP; Mon, 17 Sep 2012 08:56:04 -0700 (PDT)
In-Reply-To: <CAJ2v2mjXZFMU0enKjkO7UedCazBte2HZLCs0gqc-TQ2nsJMcDg@mail.gmail.com>
References: <CAJ2v2mjXZFMU0enKjkO7UedCazBte2HZLCs0gqc-TQ2nsJMcDg@mail.gmail.com>
Date: Mon, 17 Sep 2012 16:56:04 +0100
X-Google-Sender-Auth: dOCQG-ig4p6SwbdBwBgeVqywzvw
Message-ID: <CAFLBxZbCQysv5ggOAqcYS4F2sZUnt+txh8nQTsmC35VzwbvMTQ@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: asad raza <asadrupucit2006@gmail.com>
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Error : regarding booting of xenified linux kernel
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Sep 11, 2012 at 9:11 AM, asad raza <asadrupucit2006@gmail.com> wrote:
> hi all,
>
> I have a problem regarding booting of xenified linux kernel,the error
> is some thing like this.
>
> Bug:soft lockup CPU#1 stuck for 111's! [swapper:0]
> Call Trace:
>     [<xxxxxxx>] ? xen_safe_halt
>     [<xxxxxxx>]   xen_idle
>     [<xxxxxxx>]   cpu_idle
>
> if you have faced this problem and have a solution then plz tell me
> regarding this issue that how to solve it.

This is not nearly enough information.  Is this a guest or dom0?  What
version of the kernel is it?  What workload are you running?

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 17 15:56:46 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 15:56: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 1TDdgS-0007ZF-IZ; Mon, 17 Sep 2012 15:56:28 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dunlapg@gmail.com>) id 1TDdgR-0007ZA-0G
	for xen-devel@lists.xen.org; Mon, 17 Sep 2012 15:56:27 +0000
Received: from [85.158.143.35:18345] by server-2.bemta-4.messagelabs.com id
	90/96-06610-A2847505; Mon, 17 Sep 2012 15:56:26 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1347897365!17273758!1
X-Originating-IP: [209.85.212.173]
X-SpamReason: No, hits=0.6 required=7.0 tests=MAILTO_TO_SPAM_ADDR, RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4464 invoked from network); 17 Sep 2012 15:56:09 -0000
Received: from mail-wi0-f173.google.com (HELO mail-wi0-f173.google.com)
	(209.85.212.173)
	by server-13.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Sep 2012 15:56:09 -0000
Received: by wibhm6 with SMTP id hm6so2278886wib.14
	for <xen-devel@lists.xen.org>; Mon, 17 Sep 2012 08:56:05 -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=/VsNGC0JuoyoLjbKesgS4fovjM6rE8jnFYXMFau/j2U=;
	b=VsISoT6D69r1EuFDzXdcWwGQRSikxG2y2L2mgfWSYc1hKLQ/spHmcpeT2KbWhxhB2B
	feNWKZ2+93ILp1umLZ4EEynvYNhNuxYZ4mVWz/QqaraFXUnq7T3o9WOC7TvHvnECTLgf
	gGWv8LT7WdEolWmHOiOfIBRGpumkoujra2UrVwabnAbgt+QGvWM5RFsnS4GDEgJW4Fvy
	sqDF0KvyrHpdSl9qiUqzwJqMeEE39e+T4dZqf9BX2NYmEdLp+WabuWuCg9aa5PP0BgWN
	Tdg/tUTdsTLmHLWo8rP1oP7DNlHfSnBsDYfDQ1CMjfNRGcSaNTjFx3JugNA3i7AUx7Ls
	Cglw==
MIME-Version: 1.0
Received: by 10.180.98.200 with SMTP id ek8mr17116702wib.0.1347897364840; Mon,
	17 Sep 2012 08:56:04 -0700 (PDT)
Received: by 10.223.94.75 with HTTP; Mon, 17 Sep 2012 08:56:04 -0700 (PDT)
In-Reply-To: <CAJ2v2mjXZFMU0enKjkO7UedCazBte2HZLCs0gqc-TQ2nsJMcDg@mail.gmail.com>
References: <CAJ2v2mjXZFMU0enKjkO7UedCazBte2HZLCs0gqc-TQ2nsJMcDg@mail.gmail.com>
Date: Mon, 17 Sep 2012 16:56:04 +0100
X-Google-Sender-Auth: dOCQG-ig4p6SwbdBwBgeVqywzvw
Message-ID: <CAFLBxZbCQysv5ggOAqcYS4F2sZUnt+txh8nQTsmC35VzwbvMTQ@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: asad raza <asadrupucit2006@gmail.com>
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Error : regarding booting of xenified linux kernel
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Sep 11, 2012 at 9:11 AM, asad raza <asadrupucit2006@gmail.com> wrote:
> hi all,
>
> I have a problem regarding booting of xenified linux kernel,the error
> is some thing like this.
>
> Bug:soft lockup CPU#1 stuck for 111's! [swapper:0]
> Call Trace:
>     [<xxxxxxx>] ? xen_safe_halt
>     [<xxxxxxx>]   xen_idle
>     [<xxxxxxx>]   cpu_idle
>
> if you have faced this problem and have a solution then plz tell me
> regarding this issue that how to solve it.

This is not nearly enough information.  Is this a guest or dom0?  What
version of the kernel is it?  What workload are you running?

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 17 16:30:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 16:30: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 1TDeCl-0008RC-Fs; Mon, 17 Sep 2012 16:29:51 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1TDeCj-0008R7-75
	for xen-devel@lists.xen.org; Mon, 17 Sep 2012 16:29:49 +0000
Received: from [85.158.139.211:46078] by server-8.bemta-5.messagelabs.com id
	25/F1-15219-CFF47505; Mon, 17 Sep 2012 16:29:48 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-12.tower-206.messagelabs.com!1347899387!18855943!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20703 invoked from network); 17 Sep 2012 16:29:47 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-12.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 17 Sep 2012 16:29:47 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1TDeCX-000IlJ-AA; Mon, 17 Sep 2012 16:29:37 +0000
Date: Mon, 17 Sep 2012 17:29:37 +0100
From: Tim Deegan <tim@xen.org>
To: Keir Fraser <keir@xen.org>
Message-ID: <20120917162937.GA72055@ocelot.phlegethon.org>
References: <7A2C5C61-AFEF-4258-9EEB-CC4A0727920E@gridcentric.ca>
	<CC7CC557.4BEFD%keir@xen.org>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CC7CC557.4BEFD%keir@xen.org>
User-Agent: Mutt/1.4.2.1i
Cc: Andres Lagar-Cavilla <andreslc@gridcentric.ca>,
	Andres Lagar-Cavilla <andres@lagarcavilla.org>,
	JBeulich@suse.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] Extra check in grant table code for mapping
	of shared frame
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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 12:17 +0100 on 17 Sep (1347884247), Keir Fraser wrote:
> Probably needs Tim to comment on it. Assuming he's any wiser about this c=
ode
> than the rest of us. ;)

Looks OK to my limited understanding. :)

Tim.

> On 17/09/2012 12:00, "Andres Lagar-Cavilla" <andreslc@gridcentric.ca> wro=
te:
> =

> > ping=8A
> > Thanks,
> > Andres
> > On Sep 13, 2012, at 11:27 AM, Andres Lagar-Cavilla wrote:
> > =

> >> xen/common/grant_table.c |  9 ++++++---
> >> 1 files changed, 6 insertions(+), 3 deletions(-)
> >> =

> >> =

> >> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
> >> =

> >> diff -r 5ce5b53ea68f -r 40b91bed1275 xen/common/grant_table.c
> >> --- a/xen/common/grant_table.c
> >> +++ b/xen/common/grant_table.c
> >> @@ -649,9 +649,12 @@ __gnttab_map_grant_ref(
> >>     }
> >>     else if ( owner =3D=3D rd || owner =3D=3D dom_cow )
> >>     {
> >> -        if ( gnttab_host_mapping_get_page_type(op, ld, rd) &&
> >> -             !get_page_type(pg, PGT_writable_page) )
> >> -            goto could_not_pin;
> >> +        if ( gnttab_host_mapping_get_page_type(op, ld, rd) )
> >> +        {
> >> +            if ( (owner =3D=3D dom_cow) ||
> >> +                 !get_page_type(pg, PGT_writable_page) )
> >> +                goto could_not_pin;
> >> +        }
> >> =

> >>         nr_gets++;
> >>         if ( op->flags & GNTMAP_host_map )
> > =

> =

> =


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 17 16:30:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 16:30: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 1TDeCl-0008RC-Fs; Mon, 17 Sep 2012 16:29:51 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1TDeCj-0008R7-75
	for xen-devel@lists.xen.org; Mon, 17 Sep 2012 16:29:49 +0000
Received: from [85.158.139.211:46078] by server-8.bemta-5.messagelabs.com id
	25/F1-15219-CFF47505; Mon, 17 Sep 2012 16:29:48 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-12.tower-206.messagelabs.com!1347899387!18855943!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20703 invoked from network); 17 Sep 2012 16:29:47 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-12.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 17 Sep 2012 16:29:47 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1TDeCX-000IlJ-AA; Mon, 17 Sep 2012 16:29:37 +0000
Date: Mon, 17 Sep 2012 17:29:37 +0100
From: Tim Deegan <tim@xen.org>
To: Keir Fraser <keir@xen.org>
Message-ID: <20120917162937.GA72055@ocelot.phlegethon.org>
References: <7A2C5C61-AFEF-4258-9EEB-CC4A0727920E@gridcentric.ca>
	<CC7CC557.4BEFD%keir@xen.org>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CC7CC557.4BEFD%keir@xen.org>
User-Agent: Mutt/1.4.2.1i
Cc: Andres Lagar-Cavilla <andreslc@gridcentric.ca>,
	Andres Lagar-Cavilla <andres@lagarcavilla.org>,
	JBeulich@suse.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] Extra check in grant table code for mapping
	of shared frame
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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 12:17 +0100 on 17 Sep (1347884247), Keir Fraser wrote:
> Probably needs Tim to comment on it. Assuming he's any wiser about this c=
ode
> than the rest of us. ;)

Looks OK to my limited understanding. :)

Tim.

> On 17/09/2012 12:00, "Andres Lagar-Cavilla" <andreslc@gridcentric.ca> wro=
te:
> =

> > ping=8A
> > Thanks,
> > Andres
> > On Sep 13, 2012, at 11:27 AM, Andres Lagar-Cavilla wrote:
> > =

> >> xen/common/grant_table.c |  9 ++++++---
> >> 1 files changed, 6 insertions(+), 3 deletions(-)
> >> =

> >> =

> >> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
> >> =

> >> diff -r 5ce5b53ea68f -r 40b91bed1275 xen/common/grant_table.c
> >> --- a/xen/common/grant_table.c
> >> +++ b/xen/common/grant_table.c
> >> @@ -649,9 +649,12 @@ __gnttab_map_grant_ref(
> >>     }
> >>     else if ( owner =3D=3D rd || owner =3D=3D dom_cow )
> >>     {
> >> -        if ( gnttab_host_mapping_get_page_type(op, ld, rd) &&
> >> -             !get_page_type(pg, PGT_writable_page) )
> >> -            goto could_not_pin;
> >> +        if ( gnttab_host_mapping_get_page_type(op, ld, rd) )
> >> +        {
> >> +            if ( (owner =3D=3D dom_cow) ||
> >> +                 !get_page_type(pg, PGT_writable_page) )
> >> +                goto could_not_pin;
> >> +        }
> >> =

> >>         nr_gets++;
> >>         if ( op->flags & GNTMAP_host_map )
> > =

> =

> =


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 17 16:37:00 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 16:37:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDeJF-0000DX-At; Mon, 17 Sep 2012 16:36:33 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1TDeJD-0000DS-S2
	for xen-devel@lists.xensource.com; Mon, 17 Sep 2012 16:36:32 +0000
Received: from [85.158.139.211:33150] by server-7.bemta-5.messagelabs.com id
	BC/A3-19703-E8157505; Mon, 17 Sep 2012 16:36:30 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-206.messagelabs.com!1347899790!18888683!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDk2NDU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16427 invoked from network); 17 Sep 2012 16:36:30 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Sep 2012 16:36:30 -0000
X-IronPort-AV: E=Sophos;i="4.80,437,1344211200"; d="scan'208";a="14586828"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Sep 2012 16:36: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.279.1; Mon, 17 Sep 2012 17:36: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 1TDeJB-0003s3-Le;
	Mon, 17 Sep 2012 16:36:29 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1TDeJB-0002ro-9L;
	Mon, 17 Sep 2012 17:36:29 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-13798-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Mon, 17 Sep 2012 17:36:29 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.2-testing test] 13798: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 13798 xen-4.2-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13798/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-rhel6hvm-amd  5 xen-boot                  fail REGR. vs. 13739
 test-amd64-amd64-xl-win       5 xen-boot                  fail REGR. vs. 13739

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf     14 guest-localmigrate/x10    fail REGR. vs. 13739

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore            fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-i386-i386-xl-qemuu-winxpsp3  9 guest-localmigrate         fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             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-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass

version targeted for testing:
 xen                  357bd4bb2950
baseline version:
 xen                  4027d31caeb0

------------------------------------------------------------
People who touched revisions under test:
------------------------------------------------------------

jobs:
 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                           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


Not pushing.

------------------------------------------------------------
changeset:   25844:357bd4bb2950
tag:         tip
user:        Keir Fraser <keir@xen.org>
date:        Mon Sep 17 09:25:24 2012 +0100
    
    Added signature for changeset af176624c3ae
    
    
changeset:   25843:fcf43d9649cd
user:        Keir Fraser <keir@xen.org>
date:        Mon Sep 17 09:25:05 2012 +0100
    
    Added tag RELEASE-4.2.0 for changeset af176624c3ae
    
    
changeset:   25842:af176624c3ae
tag:         RELEASE-4.2.0
user:        Keir Fraser <keir@xen.org>
date:        Mon Sep 17 09:24:34 2012 +0100
    
    Update Xen version to 4.2.0
    
    
changeset:   25841:4027d31caeb0
user:        Keir Fraser <keir@xen.org>
date:        Thu Sep 13 12:21:09 2012 +0100
    
    Added signature for changeset 14164c5f22c8
    
    
(qemu changes not included)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 17 16:37:00 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 16:37:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDeJF-0000DX-At; Mon, 17 Sep 2012 16:36:33 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1TDeJD-0000DS-S2
	for xen-devel@lists.xensource.com; Mon, 17 Sep 2012 16:36:32 +0000
Received: from [85.158.139.211:33150] by server-7.bemta-5.messagelabs.com id
	BC/A3-19703-E8157505; Mon, 17 Sep 2012 16:36:30 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-206.messagelabs.com!1347899790!18888683!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDk2NDU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16427 invoked from network); 17 Sep 2012 16:36:30 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Sep 2012 16:36:30 -0000
X-IronPort-AV: E=Sophos;i="4.80,437,1344211200"; d="scan'208";a="14586828"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Sep 2012 16:36: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.279.1; Mon, 17 Sep 2012 17:36: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 1TDeJB-0003s3-Le;
	Mon, 17 Sep 2012 16:36:29 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1TDeJB-0002ro-9L;
	Mon, 17 Sep 2012 17:36:29 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-13798-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Mon, 17 Sep 2012 17:36:29 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.2-testing test] 13798: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 13798 xen-4.2-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13798/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-rhel6hvm-amd  5 xen-boot                  fail REGR. vs. 13739
 test-amd64-amd64-xl-win       5 xen-boot                  fail REGR. vs. 13739

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf     14 guest-localmigrate/x10    fail REGR. vs. 13739

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore            fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-i386-i386-xl-qemuu-winxpsp3  9 guest-localmigrate         fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             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-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass

version targeted for testing:
 xen                  357bd4bb2950
baseline version:
 xen                  4027d31caeb0

------------------------------------------------------------
People who touched revisions under test:
------------------------------------------------------------

jobs:
 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                           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


Not pushing.

------------------------------------------------------------
changeset:   25844:357bd4bb2950
tag:         tip
user:        Keir Fraser <keir@xen.org>
date:        Mon Sep 17 09:25:24 2012 +0100
    
    Added signature for changeset af176624c3ae
    
    
changeset:   25843:fcf43d9649cd
user:        Keir Fraser <keir@xen.org>
date:        Mon Sep 17 09:25:05 2012 +0100
    
    Added tag RELEASE-4.2.0 for changeset af176624c3ae
    
    
changeset:   25842:af176624c3ae
tag:         RELEASE-4.2.0
user:        Keir Fraser <keir@xen.org>
date:        Mon Sep 17 09:24:34 2012 +0100
    
    Update Xen version to 4.2.0
    
    
changeset:   25841:4027d31caeb0
user:        Keir Fraser <keir@xen.org>
date:        Thu Sep 13 12:21:09 2012 +0100
    
    Added signature for changeset 14164c5f22c8
    
    
(qemu changes not included)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 17 16:39:41 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 16: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 1TDeM0-0000LK-3k; Mon, 17 Sep 2012 16:39:24 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1TDeLy-0000LD-54
	for xen-devel@lists.xen.org; Mon, 17 Sep 2012 16:39:22 +0000
Received: from [85.158.138.51:46541] by server-4.bemta-3.messagelabs.com id
	5B/A0-24831-93257505; Mon, 17 Sep 2012 16:39:21 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-15.tower-174.messagelabs.com!1347899960!29121580!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28166 invoked from network); 17 Sep 2012 16:39:20 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-15.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 17 Sep 2012 16:39:20 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1TDeLv-000Io5-1E; Mon, 17 Sep 2012 16:39:19 +0000
Date: Mon, 17 Sep 2012 17:39:18 +0100
From: Tim Deegan <tim@xen.org>
To: Andres Lagar-Cavilla <andres.lagarcavilla@gmail.com>
Message-ID: <20120917163918.GC72055@ocelot.phlegethon.org>
References: <CANSvah6PU5SOKd19qfbvTXvz4spcPYVUQHmiirmm5hPvmzR+pg@mail.gmail.com>
	<CC741C8D.4B3AF%keir@xen.org>
	<CANSvah6nWfKP9-PLSkhbFcO2ONmfj5Hhs-+3r0MhjOUHU1qNfg@mail.gmail.com>
	<5E75DC93-571F-4B6A-BABF-24ECF4BC843F@gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <5E75DC93-571F-4B6A-BABF-24ECF4BC843F@gmail.com>
User-Agent: Mutt/1.4.2.1i
Cc: Aravindh Puthiyaparambil <aravindh@virtuata.com>,
	Keir Fraser <keir@xen.org>, Steven Maresca <steve@zentific.com>,
	andres@lagarcavilla.org, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] mem_event: fix regression affecting CR3,
	CR4 memory events
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At 21:21 -0400 on 10 Sep (1347312087), Andres Lagar-Cavilla wrote:
> 
> On Sep 10, 2012, at 6:06 PM, Steven Maresca wrote:
> 
> > On Mon, Sep 10, 2012 at 5:39 PM, Keir Fraser <keir@xen.org> wrote:
> >> On 10/09/2012 22:20, "Steven Maresca" <steve@zentific.com> wrote:
> >> 
> >>> Given the refactoring in the commit related to the regression
> >>> http://xenbits.xen.org/hg/xen-unstable.hg/rev/1276926e3795, it seemed
> >>> (to me anyway) that inserting calls as shown in the patch would be
> >>> cleaner, but I can definitely come up with some drawbacks.  However, I
> >>> wanted to get this fixed for 4.2 if at all possible, so I wanted to
> >>> send regardless.
> >>> 
> >>> In terms of drawbacks, this will require some ifdefs for x86_64, for example.
> >>> 
> >>> Any suggestions for the cleanest means of achieving the same in vmx.c?
> >> 
> >> I don't understand this at all. The original commit moved some CR handling
> >> to common HVM code. Your patch adds some mem_event calls into that common
> >> HVM code. What would need to be "achieved" in vmx.c? What ifdefs would be
> >> required for x86_64?
> >> 
> >> -- Keir
> >> 
> >> 
> > 
> > Keir,
> > 
> > In the process of moving CR handling to common code, that commit
> > removed calls to hvm_memory_event_cr3() and hvm_memory_event_cr4().
> > Without some patch restoring the calls to those two functions, current
> > xen-unstable and xen-4.2-testing only reference them as function
> > prototypes and function definitions -- there are no calls whatsoever.
> > 
> > I only mentioned an ifdef relative to x86_64 because of the #ifdef
> > __x86_64__  around the function definitions. ( I know in the hvm.h
> > itself they're just empty inline functions if not __x86_64__. )
> > 
> > Regarding vmx.c: hvm_memory_event_cr0 is called within vmx_cr_access.
> > The patch I sent restoring the calls to hvm_memory_event_cr4 and
> > hvm_memory_event_cr3 could be treated similarly, that's all.
> 
> The patch looks ok to me.
> Acked-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
> 

Acked-by: Tim Deegan <tim@xen.org>

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 17 16:39:41 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 16: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 1TDeM0-0000LK-3k; Mon, 17 Sep 2012 16:39:24 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1TDeLy-0000LD-54
	for xen-devel@lists.xen.org; Mon, 17 Sep 2012 16:39:22 +0000
Received: from [85.158.138.51:46541] by server-4.bemta-3.messagelabs.com id
	5B/A0-24831-93257505; Mon, 17 Sep 2012 16:39:21 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-15.tower-174.messagelabs.com!1347899960!29121580!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28166 invoked from network); 17 Sep 2012 16:39:20 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-15.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 17 Sep 2012 16:39:20 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1TDeLv-000Io5-1E; Mon, 17 Sep 2012 16:39:19 +0000
Date: Mon, 17 Sep 2012 17:39:18 +0100
From: Tim Deegan <tim@xen.org>
To: Andres Lagar-Cavilla <andres.lagarcavilla@gmail.com>
Message-ID: <20120917163918.GC72055@ocelot.phlegethon.org>
References: <CANSvah6PU5SOKd19qfbvTXvz4spcPYVUQHmiirmm5hPvmzR+pg@mail.gmail.com>
	<CC741C8D.4B3AF%keir@xen.org>
	<CANSvah6nWfKP9-PLSkhbFcO2ONmfj5Hhs-+3r0MhjOUHU1qNfg@mail.gmail.com>
	<5E75DC93-571F-4B6A-BABF-24ECF4BC843F@gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <5E75DC93-571F-4B6A-BABF-24ECF4BC843F@gmail.com>
User-Agent: Mutt/1.4.2.1i
Cc: Aravindh Puthiyaparambil <aravindh@virtuata.com>,
	Keir Fraser <keir@xen.org>, Steven Maresca <steve@zentific.com>,
	andres@lagarcavilla.org, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] mem_event: fix regression affecting CR3,
	CR4 memory events
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At 21:21 -0400 on 10 Sep (1347312087), Andres Lagar-Cavilla wrote:
> 
> On Sep 10, 2012, at 6:06 PM, Steven Maresca wrote:
> 
> > On Mon, Sep 10, 2012 at 5:39 PM, Keir Fraser <keir@xen.org> wrote:
> >> On 10/09/2012 22:20, "Steven Maresca" <steve@zentific.com> wrote:
> >> 
> >>> Given the refactoring in the commit related to the regression
> >>> http://xenbits.xen.org/hg/xen-unstable.hg/rev/1276926e3795, it seemed
> >>> (to me anyway) that inserting calls as shown in the patch would be
> >>> cleaner, but I can definitely come up with some drawbacks.  However, I
> >>> wanted to get this fixed for 4.2 if at all possible, so I wanted to
> >>> send regardless.
> >>> 
> >>> In terms of drawbacks, this will require some ifdefs for x86_64, for example.
> >>> 
> >>> Any suggestions for the cleanest means of achieving the same in vmx.c?
> >> 
> >> I don't understand this at all. The original commit moved some CR handling
> >> to common HVM code. Your patch adds some mem_event calls into that common
> >> HVM code. What would need to be "achieved" in vmx.c? What ifdefs would be
> >> required for x86_64?
> >> 
> >> -- Keir
> >> 
> >> 
> > 
> > Keir,
> > 
> > In the process of moving CR handling to common code, that commit
> > removed calls to hvm_memory_event_cr3() and hvm_memory_event_cr4().
> > Without some patch restoring the calls to those two functions, current
> > xen-unstable and xen-4.2-testing only reference them as function
> > prototypes and function definitions -- there are no calls whatsoever.
> > 
> > I only mentioned an ifdef relative to x86_64 because of the #ifdef
> > __x86_64__  around the function definitions. ( I know in the hvm.h
> > itself they're just empty inline functions if not __x86_64__. )
> > 
> > Regarding vmx.c: hvm_memory_event_cr0 is called within vmx_cr_access.
> > The patch I sent restoring the calls to hvm_memory_event_cr4 and
> > hvm_memory_event_cr3 could be treated similarly, that's all.
> 
> The patch looks ok to me.
> Acked-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
> 

Acked-by: Tim Deegan <tim@xen.org>

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 17 17:06:07 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 17: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 1TDelQ-0000eq-KX; Mon, 17 Sep 2012 17: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.Jackson@eu.citrix.com>) id 1TDelP-0000el-Ar
	for xen-devel@lists.xensource.com; Mon, 17 Sep 2012 17:05:39 +0000
Received: from [85.158.143.35:16795] by server-1.bemta-4.messagelabs.com id
	88/28-12504-26857505; Mon, 17 Sep 2012 17:05:38 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1347901536!6922117!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDk2NDU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21533 invoked from network); 17 Sep 2012 17:05:37 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Sep 2012 17:05:37 -0000
X-IronPort-AV: E=Sophos;i="4.80,437,1344211200"; d="scan'208";a="14587219"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Sep 2012 17:05: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.279.1; Mon, 17 Sep 2012 18:05: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
	1TDelG-00046F-3W	for xen-devel@lists.xensource.com;
	Mon, 17 Sep 2012 17:05:30 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1TDelF-0000S4-VX	for
	xen-devel@lists.xensource.com; Mon, 17 Sep 2012 18:05:29 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20567.22617.708874.516876@mariner.uk.xensource.com>
Date: Mon, 17 Sep 2012 18:05:29 +0100
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
In-Reply-To: <osstest-13798-mainreport@xen.org>
References: <osstest-13798-mainreport@xen.org>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Subject: Re: [Xen-devel] [xen-4.2-testing test] 13798: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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.2-testing test] 13798: regressions - FAIL"):
> flight 13798 xen-4.2-testing real [real]
> http://www.chiark.greenend.org.uk/~xensrcts/logs/13798/
> 
> Regressions :-(
> 
> Tests which did not succeed and are blocking,
> including tests which could not be run:
>  test-amd64-i386-rhel6hvm-amd  5 xen-boot             fail REGR. vs. 13739

Sep 17 13:10:04.736640 Starting C xenstored...
Sep 17 13:10:07.476559 Setting domain 0 name...
Sep 17 13:10:07.476592 Starting xenconsoled...
Sep 17 13:10:07.476622 Starting QEMU as disk backend for dom0

and the the boot hung.  The intervention of the autotester, poking the
debug keys, seems to have unhung it.

The transcript seems to suggest some lost serial output, too, as the
next thing I see from the boot sequence (in the middle of the debug
keys) is a message about exim4.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 17 17:06:07 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 17: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 1TDelQ-0000eq-KX; Mon, 17 Sep 2012 17: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.Jackson@eu.citrix.com>) id 1TDelP-0000el-Ar
	for xen-devel@lists.xensource.com; Mon, 17 Sep 2012 17:05:39 +0000
Received: from [85.158.143.35:16795] by server-1.bemta-4.messagelabs.com id
	88/28-12504-26857505; Mon, 17 Sep 2012 17:05:38 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1347901536!6922117!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDk2NDU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21533 invoked from network); 17 Sep 2012 17:05:37 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Sep 2012 17:05:37 -0000
X-IronPort-AV: E=Sophos;i="4.80,437,1344211200"; d="scan'208";a="14587219"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Sep 2012 17:05: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.279.1; Mon, 17 Sep 2012 18:05: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
	1TDelG-00046F-3W	for xen-devel@lists.xensource.com;
	Mon, 17 Sep 2012 17:05:30 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1TDelF-0000S4-VX	for
	xen-devel@lists.xensource.com; Mon, 17 Sep 2012 18:05:29 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20567.22617.708874.516876@mariner.uk.xensource.com>
Date: Mon, 17 Sep 2012 18:05:29 +0100
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
In-Reply-To: <osstest-13798-mainreport@xen.org>
References: <osstest-13798-mainreport@xen.org>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Subject: Re: [Xen-devel] [xen-4.2-testing test] 13798: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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.2-testing test] 13798: regressions - FAIL"):
> flight 13798 xen-4.2-testing real [real]
> http://www.chiark.greenend.org.uk/~xensrcts/logs/13798/
> 
> Regressions :-(
> 
> Tests which did not succeed and are blocking,
> including tests which could not be run:
>  test-amd64-i386-rhel6hvm-amd  5 xen-boot             fail REGR. vs. 13739

Sep 17 13:10:04.736640 Starting C xenstored...
Sep 17 13:10:07.476559 Setting domain 0 name...
Sep 17 13:10:07.476592 Starting xenconsoled...
Sep 17 13:10:07.476622 Starting QEMU as disk backend for dom0

and the the boot hung.  The intervention of the autotester, poking the
debug keys, seems to have unhung it.

The transcript seems to suggest some lost serial output, too, as the
next thing I see from the boot sequence (in the middle of the debug
keys) is a message about exim4.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 17 17:08:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 17: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 1TDeoJ-0000lK-70; Mon, 17 Sep 2012 17:08:39 +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 1TDeoH-0000lB-Lq
	for xen-devel@lists.xen.org; Mon, 17 Sep 2012 17:08:37 +0000
Received: from [85.158.138.51:42543] by server-3.bemta-3.messagelabs.com id
	10/B5-21322-41957505; Mon, 17 Sep 2012 17:08:36 +0000
X-Env-Sender: msw@amazon.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1347901715!24569871!1
X-Originating-IP: [72.21.198.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNzIuMjEuMTk4LjI1ID0+IDE3NzA5MA==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26039 invoked from network); 17 Sep 2012 17:08:36 -0000
Received: from smtp-fw-4101.amazon.com (HELO smtp-fw-4101.amazon.com)
	(72.21.198.25)
	by server-14.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Sep 2012 17:08:36 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=amazon.com; i=msw@amazon.com; q=dns/txt; s=rte02;
	t=1347901715; x=1379437715;
	h=date:from:to:cc:subject:message-id:references:
	mime-version:in-reply-to;
	bh=LIAxVVp47LKGsAN0RAdhuTvKoz3YkGZgplUs1f2615c=;
	b=gJ+0zoJwTUwmfkZll8y3zOqXJ65DtqOW5Tj3PgXzLPyUTFTWy0qPuEwe
	jDqmfAFlqaFhI2Q8FysAuO80Ms8Ylw==;
X-IronPort-AV: E=Sophos;i="4.80,437,1344211200"; d="scan'208";a="797465748"
Received: from smtp-in-6002.iad6.amazon.com ([10.195.76.108])
	by smtp-border-fw-out-4101.iad4.amazon.com with
	ESMTP/TLS/DHE-RSA-AES256-SHA; 17 Sep 2012 17:08:28 +0000
Received: from ex10-hub-9004.ant.amazon.com (ex10-hub-9004.ant.amazon.com
	[10.185.137.182])
	by smtp-in-6002.iad6.amazon.com (8.13.8/8.13.8) with ESMTP id
	q8HH8Qk4021931
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL);
	Mon, 17 Sep 2012 17:08:28 GMT
Received: from u002268147cd4502c336d.ant.amazon.com (10.224.80.44) by
	ex10-hub-9004.ant.amazon.com (10.185.137.182) with Microsoft SMTP
	Server id 14.2.247.3; Mon, 17 Sep 2012 10:08:21 -0700
Received: by u002268147cd4502c336d.ant.amazon.com (sSMTP sendmail emulation); 
	Mon, 17 Sep 2012 10:08:21 -0700
Date: Mon, 17 Sep 2012 10:08:21 -0700
From: Matt Wilson <msw@amazon.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120917170814.GA22382@u002268147cd4502c336d.ant.amazon.com>
References: <patchbomb.1346992557@u002268147cd4502c336d.ant.amazon.com>
	<3b3582f4dc423daa8040.1346992558@u002268147cd4502c336d.ant.amazon.com>
	<1347874964.14977.34.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1347874964.14977.34.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 1 of 2 v3] tools: check for documentation
 generation tools at configure 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 Mon, Sep 17, 2012 at 10:42:44AM +0100, Ian Campbell wrote:
>         configure: error: in `/home/xendocs/cronjobs/working/docs/unstable/tree/tools':
>         configure: error: no acceptable C compiler found in $PATH
>         See `config.log' for more details
> 
> Which is a bit annoying if all you wanted was to build docs. I'm not
> sure I really want to advocate putting gcc on xenbits. I suppose I could
> put a dummy shell script in $PATH.

./configure is probably going to need a compiler that produces
executables.

> AIUI autoconf allows you to define that a configure script calls a
> sub-configure script. Could we use this at the toplevel to call both
> tools/configure and a new docs/configure? Then my docs scripts could
> just call docs/configure?

This sounds like a better idea.

> FWIW the unrelated issue was:
>         $ make -C docs/ clean
>         /bin/sh: gcc: not found
>         /bin/sh: arithmetic expression: expecting primary: ""
> which I think is down to the gcc version check in Config.mk.

While we're discussing expanding the coverage of ./configure, I
wonder: what (if any) is the resistance to requiring ./configure to
build the xen/ tree?

Matt

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 17 17:08:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 17: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 1TDeoJ-0000lK-70; Mon, 17 Sep 2012 17:08:39 +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 1TDeoH-0000lB-Lq
	for xen-devel@lists.xen.org; Mon, 17 Sep 2012 17:08:37 +0000
Received: from [85.158.138.51:42543] by server-3.bemta-3.messagelabs.com id
	10/B5-21322-41957505; Mon, 17 Sep 2012 17:08:36 +0000
X-Env-Sender: msw@amazon.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1347901715!24569871!1
X-Originating-IP: [72.21.198.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNzIuMjEuMTk4LjI1ID0+IDE3NzA5MA==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26039 invoked from network); 17 Sep 2012 17:08:36 -0000
Received: from smtp-fw-4101.amazon.com (HELO smtp-fw-4101.amazon.com)
	(72.21.198.25)
	by server-14.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Sep 2012 17:08:36 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=amazon.com; i=msw@amazon.com; q=dns/txt; s=rte02;
	t=1347901715; x=1379437715;
	h=date:from:to:cc:subject:message-id:references:
	mime-version:in-reply-to;
	bh=LIAxVVp47LKGsAN0RAdhuTvKoz3YkGZgplUs1f2615c=;
	b=gJ+0zoJwTUwmfkZll8y3zOqXJ65DtqOW5Tj3PgXzLPyUTFTWy0qPuEwe
	jDqmfAFlqaFhI2Q8FysAuO80Ms8Ylw==;
X-IronPort-AV: E=Sophos;i="4.80,437,1344211200"; d="scan'208";a="797465748"
Received: from smtp-in-6002.iad6.amazon.com ([10.195.76.108])
	by smtp-border-fw-out-4101.iad4.amazon.com with
	ESMTP/TLS/DHE-RSA-AES256-SHA; 17 Sep 2012 17:08:28 +0000
Received: from ex10-hub-9004.ant.amazon.com (ex10-hub-9004.ant.amazon.com
	[10.185.137.182])
	by smtp-in-6002.iad6.amazon.com (8.13.8/8.13.8) with ESMTP id
	q8HH8Qk4021931
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL);
	Mon, 17 Sep 2012 17:08:28 GMT
Received: from u002268147cd4502c336d.ant.amazon.com (10.224.80.44) by
	ex10-hub-9004.ant.amazon.com (10.185.137.182) with Microsoft SMTP
	Server id 14.2.247.3; Mon, 17 Sep 2012 10:08:21 -0700
Received: by u002268147cd4502c336d.ant.amazon.com (sSMTP sendmail emulation); 
	Mon, 17 Sep 2012 10:08:21 -0700
Date: Mon, 17 Sep 2012 10:08:21 -0700
From: Matt Wilson <msw@amazon.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120917170814.GA22382@u002268147cd4502c336d.ant.amazon.com>
References: <patchbomb.1346992557@u002268147cd4502c336d.ant.amazon.com>
	<3b3582f4dc423daa8040.1346992558@u002268147cd4502c336d.ant.amazon.com>
	<1347874964.14977.34.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1347874964.14977.34.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 1 of 2 v3] tools: check for documentation
 generation tools at configure 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 Mon, Sep 17, 2012 at 10:42:44AM +0100, Ian Campbell wrote:
>         configure: error: in `/home/xendocs/cronjobs/working/docs/unstable/tree/tools':
>         configure: error: no acceptable C compiler found in $PATH
>         See `config.log' for more details
> 
> Which is a bit annoying if all you wanted was to build docs. I'm not
> sure I really want to advocate putting gcc on xenbits. I suppose I could
> put a dummy shell script in $PATH.

./configure is probably going to need a compiler that produces
executables.

> AIUI autoconf allows you to define that a configure script calls a
> sub-configure script. Could we use this at the toplevel to call both
> tools/configure and a new docs/configure? Then my docs scripts could
> just call docs/configure?

This sounds like a better idea.

> FWIW the unrelated issue was:
>         $ make -C docs/ clean
>         /bin/sh: gcc: not found
>         /bin/sh: arithmetic expression: expecting primary: ""
> which I think is down to the gcc version check in Config.mk.

While we're discussing expanding the coverage of ./configure, I
wonder: what (if any) is the resistance to requiring ./configure to
build the xen/ tree?

Matt

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 17 17:13:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 17: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 1TDesr-0000xJ-TX; Mon, 17 Sep 2012 17:13:21 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1TDesq-0000xC-Jj
	for xen-devel@lists.xensource.com; Mon, 17 Sep 2012 17:13:20 +0000
Received: from [85.158.143.99:29632] by server-3.bemta-4.messagelabs.com id
	26/54-08232-F2A57505; Mon, 17 Sep 2012 17:13:19 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1347901997!22513261!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzQ1MDU4\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13955 invoked from network); 17 Sep 2012 17:13:19 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-2.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 17 Sep 2012 17:13:19 -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 q8HHDAEC013133
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 17 Sep 2012 17:13:11 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
	q8HHD94S011705
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 17 Sep 2012 17:13:10 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
	q8HHD9Rw023333; Mon, 17 Sep 2012 12:13:09 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 17 Sep 2012 10:13:08 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 62355402B4; Mon, 17 Sep 2012 13:02:22 -0400 (EDT)
Date: Mon, 17 Sep 2012 13:02:22 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20120917170221.GA15783@phenom.dumpdata.com>
References: <1347306367-28669-1-git-send-email-konrad.wilk@oracle.com>
	<1347306367-28669-11-git-send-email-konrad.wilk@oracle.com>
	<alpine.DEB.2.02.1209141709580.29232@kaball.uk.xensource.com>
	<20120917142315.GA12541@phenom.dumpdata.com>
	<alpine.DEB.2.02.1209171550570.29232@kaball.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <alpine.DEB.2.02.1209171550570.29232@kaball.uk.xensource.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [Xen-devel] [PATCH 10/10] xen/swiotlb: Depending on
 after_bootmem is not 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 Mon, Sep 17, 2012 at 03:52:20PM +0100, Stefano Stabellini wrote:
> On Mon, 17 Sep 2012, Konrad Rzeszutek Wilk wrote:
> > > >  	start_dma_addr = xen_virt_to_bus(xen_io_tlb_start);
> > > > -	if (!after_bootmem)
> > > > +	rc = 0;
> > >      ^
> > > why does this change belong to this patch?
> > > 
> > > 
> > 
> > I took that out of the this patch, so it is now:
> > 
> > 
> > >From c5bc5502abc0f70b682c0f2a70d08e6319825163 Mon Sep 17 00:00:00 2001
> > From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> > Date: Wed, 5 Sep 2012 13:35:47 -0400
> > Subject: [PATCH 1/2] xen/swiotlb: Depending on after_bootmem is not correct.
> > 
> > When PCI IOMMUs are initialized it is after after_bootmem but
> > before a lot of "other" subsystems are initialized. As such
> > the check for after_bootmem is incorrect and we should
> > just use a parameter to define whether we are early or late.
> 
> Given that the after_bootmem checks are introduced by patch 6/10, I
> would just merge the two.
> In any case, it looks OK now.

Squashed it in:

>From b82776005369899c1c7ca2e4b2414bb64b538d2c Mon Sep 17 00:00:00 2001
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Thu, 23 Aug 2012 14:36:15 -0400
Subject: [PATCH] xen/swiotlb: Use the swiotlb_late_init_with_tbl to init
 Xen-SWIOTLB late when PV PCI is used.

With this patch we provide the functionality to initialize the
Xen-SWIOTLB late in the bootup cycle - specifically for
Xen PCI-frontend. We still will work if the user had
supplied 'iommu=soft' on the Linux command line.

Note: We cannot depend on after_bootmem to automatically
determine whether this is early or not. This is because
when PCI IOMMUs are initialized it is after after_bootmem but
before a lot of "other" subsystems are initialized.

CC: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
[v1: Fix smatch warnings]
[v2: Added check for xen_swiotlb]
[v3: Rebased with new xen-swiotlb changes]
[v4: squashed xen/swiotlb: Depending on after_bootmem is not correct in]
Reviewed-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 arch/x86/include/asm/xen/swiotlb-xen.h |    2 +
 arch/x86/xen/pci-swiotlb-xen.c         |   24 ++++++++++++++-
 drivers/xen/swiotlb-xen.c              |   48 +++++++++++++++++++++++++------
 include/xen/swiotlb-xen.h              |    2 +-
 4 files changed, 63 insertions(+), 13 deletions(-)

diff --git a/arch/x86/include/asm/xen/swiotlb-xen.h b/arch/x86/include/asm/xen/swiotlb-xen.h
index 1be1ab7..ee52fca 100644
--- a/arch/x86/include/asm/xen/swiotlb-xen.h
+++ b/arch/x86/include/asm/xen/swiotlb-xen.h
@@ -5,10 +5,12 @@
 extern int xen_swiotlb;
 extern int __init pci_xen_swiotlb_detect(void);
 extern void __init pci_xen_swiotlb_init(void);
+extern int pci_xen_swiotlb_init_late(void);
 #else
 #define xen_swiotlb (0)
 static inline int __init pci_xen_swiotlb_detect(void) { return 0; }
 static inline void __init pci_xen_swiotlb_init(void) { }
+static inline int pci_xen_swiotlb_init_late(void) { return -ENXIO; }
 #endif
 
 #endif /* _ASM_X86_SWIOTLB_XEN_H */
diff --git a/arch/x86/xen/pci-swiotlb-xen.c b/arch/x86/xen/pci-swiotlb-xen.c
index 1c17227..b152640 100644
--- a/arch/x86/xen/pci-swiotlb-xen.c
+++ b/arch/x86/xen/pci-swiotlb-xen.c
@@ -12,7 +12,7 @@
 #include <asm/iommu.h>
 #include <asm/dma.h>
 #endif
-
+#include <linux/export.h>
 int xen_swiotlb __read_mostly;
 
 static struct dma_map_ops xen_swiotlb_dma_ops = {
@@ -69,13 +69,33 @@ int __init pci_xen_swiotlb_detect(void)
 void __init pci_xen_swiotlb_init(void)
 {
 	if (xen_swiotlb) {
-		xen_swiotlb_init(1);
+		xen_swiotlb_init(1, true /* early */);
 		dma_ops = &xen_swiotlb_dma_ops;
 
 		/* Make sure ACS will be enabled */
 		pci_request_acs();
 	}
 }
+
+int pci_xen_swiotlb_init_late(void)
+{
+	int rc;
+
+	if (xen_swiotlb)
+		return 0;
+
+	rc = xen_swiotlb_init(1, false /* late */);
+	if (rc)
+		return rc;
+
+	dma_ops = &xen_swiotlb_dma_ops;
+	/* Make sure ACS will be enabled */
+	pci_request_acs();
+
+	return 0;
+}
+EXPORT_SYMBOL_GPL(pci_xen_swiotlb_init_late);
+
 IOMMU_INIT_FINISH(pci_xen_swiotlb_detect,
 		  0,
 		  pci_xen_swiotlb_init,
diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
index 701b103..7461edb 100644
--- a/drivers/xen/swiotlb-xen.c
+++ b/drivers/xen/swiotlb-xen.c
@@ -176,9 +176,9 @@ static const char *xen_swiotlb_error(enum xen_swiotlb_err err)
 	}
 	return "";
 }
-void __init xen_swiotlb_init(int verbose)
+int __ref xen_swiotlb_init(int verbose, bool early)
 {
-	unsigned long bytes;
+	unsigned long bytes, order;
 	int rc = -ENOMEM;
 	enum xen_swiotlb_err m_ret = XEN_SWIOTLB_UNKNOWN;
 	unsigned int repeat = 3;
@@ -186,10 +186,28 @@ void __init xen_swiotlb_init(int verbose)
 	xen_io_tlb_nslabs = swiotlb_nr_tbl();
 retry:
 	bytes = xen_set_nslabs(xen_io_tlb_nslabs);
+	order = get_order(xen_io_tlb_nslabs << IO_TLB_SHIFT);
 	/*
 	 * Get IO TLB memory from any location.
 	 */
-	xen_io_tlb_start = alloc_bootmem_pages(PAGE_ALIGN(bytes));
+	if (early)
+		xen_io_tlb_start = alloc_bootmem_pages(PAGE_ALIGN(bytes));
+	else {
+#define SLABS_PER_PAGE (1 << (PAGE_SHIFT - IO_TLB_SHIFT))
+#define IO_TLB_MIN_SLABS ((1<<20) >> IO_TLB_SHIFT)
+		while ((SLABS_PER_PAGE << order) > IO_TLB_MIN_SLABS) {
+			xen_io_tlb_start = (void *)__get_free_pages(__GFP_NOWARN, order);
+			if (xen_io_tlb_start)
+				break;
+			order--;
+		}
+		if (order != get_order(bytes)) {
+			pr_warn("Warning: only able to allocate %ld MB "
+				"for software IO TLB\n", (PAGE_SIZE << order) >> 20);
+			xen_io_tlb_nslabs = SLABS_PER_PAGE << order;
+			bytes = xen_io_tlb_nslabs << IO_TLB_SHIFT;
+		}
+	}
 	if (!xen_io_tlb_start) {
 		m_ret = XEN_SWIOTLB_ENOMEM;
 		goto error;
@@ -202,14 +220,21 @@ retry:
 			       bytes,
 			       xen_io_tlb_nslabs);
 	if (rc) {
-		free_bootmem(__pa(xen_io_tlb_start), PAGE_ALIGN(bytes));
+		if (early)
+			free_bootmem(__pa(xen_io_tlb_start), PAGE_ALIGN(bytes));
+		else {
+			free_pages((unsigned long)xen_io_tlb_start, order);
+			xen_io_tlb_start = NULL;
+		}
 		m_ret = XEN_SWIOTLB_EFIXUP;
 		goto error;
 	}
 	start_dma_addr = xen_virt_to_bus(xen_io_tlb_start);
-	swiotlb_init_with_tbl(xen_io_tlb_start, xen_io_tlb_nslabs, verbose);
-
-	return;
+	if (early)
+		swiotlb_init_with_tbl(xen_io_tlb_start, xen_io_tlb_nslabs, verbose);
+	else
+		rc = swiotlb_late_init_with_tbl(xen_io_tlb_start, xen_io_tlb_nslabs);
+	return rc;
 error:
 	if (repeat--) {
 		xen_io_tlb_nslabs = max(1024UL, /* Min is 2MB */
@@ -218,10 +243,13 @@ error:
 		      (xen_io_tlb_nslabs << IO_TLB_SHIFT) >> 20);
 		goto retry;
 	}
-	xen_raw_printk("%s (rc:%d)", xen_swiotlb_error(m_ret), rc);
-	panic("%s (rc:%d)", xen_swiotlb_error(m_ret), rc);
+	pr_err("%s (rc:%d)", xen_swiotlb_error(m_ret), rc);
+	if (early)
+		panic("%s (rc:%d)", xen_swiotlb_error(m_ret), rc);
+	else
+		free_pages((unsigned long)xen_io_tlb_start, order);
+	return rc;
 }
-
 void *
 xen_swiotlb_alloc_coherent(struct device *hwdev, size_t size,
 			   dma_addr_t *dma_handle, gfp_t flags,
diff --git a/include/xen/swiotlb-xen.h b/include/xen/swiotlb-xen.h
index 4f4d449..289ee50 100644
--- a/include/xen/swiotlb-xen.h
+++ b/include/xen/swiotlb-xen.h
@@ -3,7 +3,7 @@
 
 #include <linux/swiotlb.h>
 
-extern void xen_swiotlb_init(int verbose);
+extern int xen_swiotlb_init(int verbose, bool early);
 
 extern void
 *xen_swiotlb_alloc_coherent(struct device *hwdev, size_t size,
-- 
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 Sep 17 17:13:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 17: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 1TDesr-0000xJ-TX; Mon, 17 Sep 2012 17:13:21 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1TDesq-0000xC-Jj
	for xen-devel@lists.xensource.com; Mon, 17 Sep 2012 17:13:20 +0000
Received: from [85.158.143.99:29632] by server-3.bemta-4.messagelabs.com id
	26/54-08232-F2A57505; Mon, 17 Sep 2012 17:13:19 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1347901997!22513261!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzQ1MDU4\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13955 invoked from network); 17 Sep 2012 17:13:19 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-2.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 17 Sep 2012 17:13:19 -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 q8HHDAEC013133
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 17 Sep 2012 17:13:11 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
	q8HHD94S011705
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 17 Sep 2012 17:13:10 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
	q8HHD9Rw023333; Mon, 17 Sep 2012 12:13:09 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 17 Sep 2012 10:13:08 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 62355402B4; Mon, 17 Sep 2012 13:02:22 -0400 (EDT)
Date: Mon, 17 Sep 2012 13:02:22 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20120917170221.GA15783@phenom.dumpdata.com>
References: <1347306367-28669-1-git-send-email-konrad.wilk@oracle.com>
	<1347306367-28669-11-git-send-email-konrad.wilk@oracle.com>
	<alpine.DEB.2.02.1209141709580.29232@kaball.uk.xensource.com>
	<20120917142315.GA12541@phenom.dumpdata.com>
	<alpine.DEB.2.02.1209171550570.29232@kaball.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <alpine.DEB.2.02.1209171550570.29232@kaball.uk.xensource.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [Xen-devel] [PATCH 10/10] xen/swiotlb: Depending on
 after_bootmem is not 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 Mon, Sep 17, 2012 at 03:52:20PM +0100, Stefano Stabellini wrote:
> On Mon, 17 Sep 2012, Konrad Rzeszutek Wilk wrote:
> > > >  	start_dma_addr = xen_virt_to_bus(xen_io_tlb_start);
> > > > -	if (!after_bootmem)
> > > > +	rc = 0;
> > >      ^
> > > why does this change belong to this patch?
> > > 
> > > 
> > 
> > I took that out of the this patch, so it is now:
> > 
> > 
> > >From c5bc5502abc0f70b682c0f2a70d08e6319825163 Mon Sep 17 00:00:00 2001
> > From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> > Date: Wed, 5 Sep 2012 13:35:47 -0400
> > Subject: [PATCH 1/2] xen/swiotlb: Depending on after_bootmem is not correct.
> > 
> > When PCI IOMMUs are initialized it is after after_bootmem but
> > before a lot of "other" subsystems are initialized. As such
> > the check for after_bootmem is incorrect and we should
> > just use a parameter to define whether we are early or late.
> 
> Given that the after_bootmem checks are introduced by patch 6/10, I
> would just merge the two.
> In any case, it looks OK now.

Squashed it in:

>From b82776005369899c1c7ca2e4b2414bb64b538d2c Mon Sep 17 00:00:00 2001
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Thu, 23 Aug 2012 14:36:15 -0400
Subject: [PATCH] xen/swiotlb: Use the swiotlb_late_init_with_tbl to init
 Xen-SWIOTLB late when PV PCI is used.

With this patch we provide the functionality to initialize the
Xen-SWIOTLB late in the bootup cycle - specifically for
Xen PCI-frontend. We still will work if the user had
supplied 'iommu=soft' on the Linux command line.

Note: We cannot depend on after_bootmem to automatically
determine whether this is early or not. This is because
when PCI IOMMUs are initialized it is after after_bootmem but
before a lot of "other" subsystems are initialized.

CC: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
[v1: Fix smatch warnings]
[v2: Added check for xen_swiotlb]
[v3: Rebased with new xen-swiotlb changes]
[v4: squashed xen/swiotlb: Depending on after_bootmem is not correct in]
Reviewed-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 arch/x86/include/asm/xen/swiotlb-xen.h |    2 +
 arch/x86/xen/pci-swiotlb-xen.c         |   24 ++++++++++++++-
 drivers/xen/swiotlb-xen.c              |   48 +++++++++++++++++++++++++------
 include/xen/swiotlb-xen.h              |    2 +-
 4 files changed, 63 insertions(+), 13 deletions(-)

diff --git a/arch/x86/include/asm/xen/swiotlb-xen.h b/arch/x86/include/asm/xen/swiotlb-xen.h
index 1be1ab7..ee52fca 100644
--- a/arch/x86/include/asm/xen/swiotlb-xen.h
+++ b/arch/x86/include/asm/xen/swiotlb-xen.h
@@ -5,10 +5,12 @@
 extern int xen_swiotlb;
 extern int __init pci_xen_swiotlb_detect(void);
 extern void __init pci_xen_swiotlb_init(void);
+extern int pci_xen_swiotlb_init_late(void);
 #else
 #define xen_swiotlb (0)
 static inline int __init pci_xen_swiotlb_detect(void) { return 0; }
 static inline void __init pci_xen_swiotlb_init(void) { }
+static inline int pci_xen_swiotlb_init_late(void) { return -ENXIO; }
 #endif
 
 #endif /* _ASM_X86_SWIOTLB_XEN_H */
diff --git a/arch/x86/xen/pci-swiotlb-xen.c b/arch/x86/xen/pci-swiotlb-xen.c
index 1c17227..b152640 100644
--- a/arch/x86/xen/pci-swiotlb-xen.c
+++ b/arch/x86/xen/pci-swiotlb-xen.c
@@ -12,7 +12,7 @@
 #include <asm/iommu.h>
 #include <asm/dma.h>
 #endif
-
+#include <linux/export.h>
 int xen_swiotlb __read_mostly;
 
 static struct dma_map_ops xen_swiotlb_dma_ops = {
@@ -69,13 +69,33 @@ int __init pci_xen_swiotlb_detect(void)
 void __init pci_xen_swiotlb_init(void)
 {
 	if (xen_swiotlb) {
-		xen_swiotlb_init(1);
+		xen_swiotlb_init(1, true /* early */);
 		dma_ops = &xen_swiotlb_dma_ops;
 
 		/* Make sure ACS will be enabled */
 		pci_request_acs();
 	}
 }
+
+int pci_xen_swiotlb_init_late(void)
+{
+	int rc;
+
+	if (xen_swiotlb)
+		return 0;
+
+	rc = xen_swiotlb_init(1, false /* late */);
+	if (rc)
+		return rc;
+
+	dma_ops = &xen_swiotlb_dma_ops;
+	/* Make sure ACS will be enabled */
+	pci_request_acs();
+
+	return 0;
+}
+EXPORT_SYMBOL_GPL(pci_xen_swiotlb_init_late);
+
 IOMMU_INIT_FINISH(pci_xen_swiotlb_detect,
 		  0,
 		  pci_xen_swiotlb_init,
diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
index 701b103..7461edb 100644
--- a/drivers/xen/swiotlb-xen.c
+++ b/drivers/xen/swiotlb-xen.c
@@ -176,9 +176,9 @@ static const char *xen_swiotlb_error(enum xen_swiotlb_err err)
 	}
 	return "";
 }
-void __init xen_swiotlb_init(int verbose)
+int __ref xen_swiotlb_init(int verbose, bool early)
 {
-	unsigned long bytes;
+	unsigned long bytes, order;
 	int rc = -ENOMEM;
 	enum xen_swiotlb_err m_ret = XEN_SWIOTLB_UNKNOWN;
 	unsigned int repeat = 3;
@@ -186,10 +186,28 @@ void __init xen_swiotlb_init(int verbose)
 	xen_io_tlb_nslabs = swiotlb_nr_tbl();
 retry:
 	bytes = xen_set_nslabs(xen_io_tlb_nslabs);
+	order = get_order(xen_io_tlb_nslabs << IO_TLB_SHIFT);
 	/*
 	 * Get IO TLB memory from any location.
 	 */
-	xen_io_tlb_start = alloc_bootmem_pages(PAGE_ALIGN(bytes));
+	if (early)
+		xen_io_tlb_start = alloc_bootmem_pages(PAGE_ALIGN(bytes));
+	else {
+#define SLABS_PER_PAGE (1 << (PAGE_SHIFT - IO_TLB_SHIFT))
+#define IO_TLB_MIN_SLABS ((1<<20) >> IO_TLB_SHIFT)
+		while ((SLABS_PER_PAGE << order) > IO_TLB_MIN_SLABS) {
+			xen_io_tlb_start = (void *)__get_free_pages(__GFP_NOWARN, order);
+			if (xen_io_tlb_start)
+				break;
+			order--;
+		}
+		if (order != get_order(bytes)) {
+			pr_warn("Warning: only able to allocate %ld MB "
+				"for software IO TLB\n", (PAGE_SIZE << order) >> 20);
+			xen_io_tlb_nslabs = SLABS_PER_PAGE << order;
+			bytes = xen_io_tlb_nslabs << IO_TLB_SHIFT;
+		}
+	}
 	if (!xen_io_tlb_start) {
 		m_ret = XEN_SWIOTLB_ENOMEM;
 		goto error;
@@ -202,14 +220,21 @@ retry:
 			       bytes,
 			       xen_io_tlb_nslabs);
 	if (rc) {
-		free_bootmem(__pa(xen_io_tlb_start), PAGE_ALIGN(bytes));
+		if (early)
+			free_bootmem(__pa(xen_io_tlb_start), PAGE_ALIGN(bytes));
+		else {
+			free_pages((unsigned long)xen_io_tlb_start, order);
+			xen_io_tlb_start = NULL;
+		}
 		m_ret = XEN_SWIOTLB_EFIXUP;
 		goto error;
 	}
 	start_dma_addr = xen_virt_to_bus(xen_io_tlb_start);
-	swiotlb_init_with_tbl(xen_io_tlb_start, xen_io_tlb_nslabs, verbose);
-
-	return;
+	if (early)
+		swiotlb_init_with_tbl(xen_io_tlb_start, xen_io_tlb_nslabs, verbose);
+	else
+		rc = swiotlb_late_init_with_tbl(xen_io_tlb_start, xen_io_tlb_nslabs);
+	return rc;
 error:
 	if (repeat--) {
 		xen_io_tlb_nslabs = max(1024UL, /* Min is 2MB */
@@ -218,10 +243,13 @@ error:
 		      (xen_io_tlb_nslabs << IO_TLB_SHIFT) >> 20);
 		goto retry;
 	}
-	xen_raw_printk("%s (rc:%d)", xen_swiotlb_error(m_ret), rc);
-	panic("%s (rc:%d)", xen_swiotlb_error(m_ret), rc);
+	pr_err("%s (rc:%d)", xen_swiotlb_error(m_ret), rc);
+	if (early)
+		panic("%s (rc:%d)", xen_swiotlb_error(m_ret), rc);
+	else
+		free_pages((unsigned long)xen_io_tlb_start, order);
+	return rc;
 }
-
 void *
 xen_swiotlb_alloc_coherent(struct device *hwdev, size_t size,
 			   dma_addr_t *dma_handle, gfp_t flags,
diff --git a/include/xen/swiotlb-xen.h b/include/xen/swiotlb-xen.h
index 4f4d449..289ee50 100644
--- a/include/xen/swiotlb-xen.h
+++ b/include/xen/swiotlb-xen.h
@@ -3,7 +3,7 @@
 
 #include <linux/swiotlb.h>
 
-extern void xen_swiotlb_init(int verbose);
+extern int xen_swiotlb_init(int verbose, bool early);
 
 extern void
 *xen_swiotlb_alloc_coherent(struct device *hwdev, size_t size,
-- 
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 Sep 17 17:16:41 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 17:16:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDevq-00014M-HN; Mon, 17 Sep 2012 17:16:26 +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 1TDevp-000145-Cn
	for xen-devel@lists.xen.org; Mon, 17 Sep 2012 17:16:25 +0000
Received: from [85.158.138.51:10440] by server-4.bemta-3.messagelabs.com id
	38/6B-24831-7EA57505; Mon, 17 Sep 2012 17:16:23 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1347902182!22872578!1
X-Originating-IP: [74.125.82.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1698 invoked from network); 17 Sep 2012 17:16:23 -0000
Received: from mail-we0-f173.google.com (HELO mail-we0-f173.google.com)
	(74.125.82.173)
	by server-6.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Sep 2012 17:16:23 -0000
Received: by weyz53 with SMTP id z53so4761742wey.32
	for <multiple recipients>; Mon, 17 Sep 2012 10:16:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:date:x-google-sender-auth:message-id:subject
	:from:to:content-type;
	bh=YgwfEtDpTEO5qNtiLjLhj/TBE+mLKwMAkpn0wxP2EHA=;
	b=0gcjLb0u1WKYVW5u33ENSartw7YSMZtVl+ks+jhWTuzp258xtEmpP7HrTzaULPGLBg
	kqMOTmI0miXiGGz3gCjWFUzyEvRl/RopRHJRog2lf+RVW3KdUae9PO64r+Np8SSX9KPx
	kCFct/wwI3DdY4j7L65LMhUrQ1IDp6h9Gos32XFwOCRil/EJbD5NJoO49hlbe8iXJW2w
	Rp7B3+9whn6McUH8wikmJH0ymD9tDVqHvp1ADpasqs3wovzGi5WkQigy2p4OPzDlwNdU
	XlToOIdOGDQjueCi1gbGmTNbQ0LXX1GajBykdBTJehhFAbcsBZ5OLudHOyUrT1VU/Pvi
	DHXg==
MIME-Version: 1.0
Received: by 10.180.109.129 with SMTP id hs1mr17535889wib.0.1347902182533;
	Mon, 17 Sep 2012 10:16:22 -0700 (PDT)
Received: by 10.223.94.75 with HTTP; Mon, 17 Sep 2012 10:16:22 -0700 (PDT)
Date: Mon, 17 Sep 2012 18:16:22 +0100
X-Google-Sender-Auth: IDMIhoye6JU342CTTZQh3qzFzgQ
Message-ID: <CAFLBxZZvBraj60sD3tikuiCzrhC9qftCUsd5jQ_DgjV8TjpgbQ@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: xen-devel@lists.xen.org, xen-users@lists.xen.org, 
	xen-announce@lists.xen.org
Subject: [Xen-devel] Experimenting with UserVoice.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

One of the issues in any software project can be the disconnect
between what users want or would find useful, and the developers' idea
of what users want or would find useful, and Xen is no exception.

To help address this issue, I am going to start experimenting with a
website called UserVoice.  UserVoice allows users to do two things:
* Suggest improvements or features
* "Vote" for which improvements or features they think are most important.

You can find the Xen.org uservoice page here:

http://xenorg.uservoice.com

You can either create an account, or log in with an existing Google or
Facebook account.

Obviously we can't promise that everything that is suggested or voted
highly will be implemented!  But hopefully it will give the developers
a better idea what our users are thinking.

To make sure that the site is as useful as possible, please try focus
on *things you want to do*, rather than *how* you want to be able to
do them.  That will help us choose the best way to help you; or
perhaps point you to an existing way of doing something that's already
available.

Enjoy!

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 17 17:16:41 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 17:16:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDevq-00014M-HN; Mon, 17 Sep 2012 17:16:26 +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 1TDevp-000145-Cn
	for xen-devel@lists.xen.org; Mon, 17 Sep 2012 17:16:25 +0000
Received: from [85.158.138.51:10440] by server-4.bemta-3.messagelabs.com id
	38/6B-24831-7EA57505; Mon, 17 Sep 2012 17:16:23 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1347902182!22872578!1
X-Originating-IP: [74.125.82.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1698 invoked from network); 17 Sep 2012 17:16:23 -0000
Received: from mail-we0-f173.google.com (HELO mail-we0-f173.google.com)
	(74.125.82.173)
	by server-6.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Sep 2012 17:16:23 -0000
Received: by weyz53 with SMTP id z53so4761742wey.32
	for <multiple recipients>; Mon, 17 Sep 2012 10:16:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:date:x-google-sender-auth:message-id:subject
	:from:to:content-type;
	bh=YgwfEtDpTEO5qNtiLjLhj/TBE+mLKwMAkpn0wxP2EHA=;
	b=0gcjLb0u1WKYVW5u33ENSartw7YSMZtVl+ks+jhWTuzp258xtEmpP7HrTzaULPGLBg
	kqMOTmI0miXiGGz3gCjWFUzyEvRl/RopRHJRog2lf+RVW3KdUae9PO64r+Np8SSX9KPx
	kCFct/wwI3DdY4j7L65LMhUrQ1IDp6h9Gos32XFwOCRil/EJbD5NJoO49hlbe8iXJW2w
	Rp7B3+9whn6McUH8wikmJH0ymD9tDVqHvp1ADpasqs3wovzGi5WkQigy2p4OPzDlwNdU
	XlToOIdOGDQjueCi1gbGmTNbQ0LXX1GajBykdBTJehhFAbcsBZ5OLudHOyUrT1VU/Pvi
	DHXg==
MIME-Version: 1.0
Received: by 10.180.109.129 with SMTP id hs1mr17535889wib.0.1347902182533;
	Mon, 17 Sep 2012 10:16:22 -0700 (PDT)
Received: by 10.223.94.75 with HTTP; Mon, 17 Sep 2012 10:16:22 -0700 (PDT)
Date: Mon, 17 Sep 2012 18:16:22 +0100
X-Google-Sender-Auth: IDMIhoye6JU342CTTZQh3qzFzgQ
Message-ID: <CAFLBxZZvBraj60sD3tikuiCzrhC9qftCUsd5jQ_DgjV8TjpgbQ@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: xen-devel@lists.xen.org, xen-users@lists.xen.org, 
	xen-announce@lists.xen.org
Subject: [Xen-devel] Experimenting with UserVoice.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

One of the issues in any software project can be the disconnect
between what users want or would find useful, and the developers' idea
of what users want or would find useful, and Xen is no exception.

To help address this issue, I am going to start experimenting with a
website called UserVoice.  UserVoice allows users to do two things:
* Suggest improvements or features
* "Vote" for which improvements or features they think are most important.

You can find the Xen.org uservoice page here:

http://xenorg.uservoice.com

You can either create an account, or log in with an existing Google or
Facebook account.

Obviously we can't promise that everything that is suggested or voted
highly will be implemented!  But hopefully it will give the developers
a better idea what our users are thinking.

To make sure that the site is as useful as possible, please try focus
on *things you want to do*, rather than *how* you want to be able to
do them.  That will help us choose the best way to help you; or
perhaps point you to an existing way of doing something that's already
available.

Enjoy!

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 17 17:38:30 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 17: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 1TDfGv-0001d1-2v; Mon, 17 Sep 2012 17:38:13 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1TDfGt-0001ct-9G
	for xen-devel@lists.xensource.com; Mon, 17 Sep 2012 17:38:11 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1347903482!5789801!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDk2NDU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3615 invoked from network); 17 Sep 2012 17:38:03 -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;
	17 Sep 2012 17:38:03 -0000
X-IronPort-AV: E=Sophos;i="4.80,437,1344211200"; 
	d="dts'?dtsi'?scan'208";a="14587634"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Sep 2012 17:37: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.279.1; Mon, 17 Sep 2012 18:37:54 +0100
Date: Mon, 17 Sep 2012 18:37:08 +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>
Message-ID: <alpine.DEB.2.02.1209171215490.29232@kaball.uk.xensource.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Content-Type: multipart/mixed;
	boundary="_004_alpineDEB202120914114515029232kaballukxensourcecom_"
Content-ID: <alpine.DEB.2.02.1209171215491.29232@kaball.uk.xensource.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linaro-dev@lists.linaro.org" <linaro-dev@lists.linaro.org>,
	Ian Campbell <Ian.Campbell@citrix.com>, "arnd@arndb.de" <arnd@arndb.de>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>, "Tim
	\(Xen.org\)" <tim@xen.org>,
	Russell King - ARM Linux <linux@arm.linux.org.uk>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: [Xen-devel] [PATCH v5 00/17] Introduce Xen support on ARM (based on
	3.6-rc5)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--_004_alpineDEB202120914114515029232kaballukxensourcecom_
Content-Type: text/plain; charset="US-ASCII"
Content-ID: <alpine.DEB.2.02.1209171215492.29232@kaball.uk.xensource.com>

Hi all,
this patch series implements Xen support for ARMv7 with virtualization
extensions.  It allows a Linux guest to boot as dom0 and
as domU on Xen on ARM. PV console, disk and network frontends and
backends are all working correctly.

It has been tested on a Versatile Express Cortex A15 emulator, using the
latest Xen ARM developement branch
(git://xenbits.xen.org/people/ianc/xen-unstable.git arm-for-4.3) plus
the "ARM hypercall ABI: 64 bit ready" patch series
(http://marc.info/?l=xen-devel&m=134426267205408), and a simple ad-hoc
tool to build guest domains (marc.info/?l=xen-devel&m=134089788016546).

The patch marked with [HACK] has been dropped from this series, however
you can find it here:
http://marc.info/?l=linux-kernel&m=134513277823527&w=2.

I am also attaching to this email the dts'es that I am currently using
for dom0 and domU: vexpress-v2p-ca15-tc1.dts (that includes
vexpress-v2m-rs1-rtsm.dtsi) is the dts used for dom0 and it is passed to
Linux by Xen, while vexpress-virt.dts is the dts used for other domUs
and it is appended in binary form to the guest kernel image. I am not
sure where they are supposed to live yet, so I am just attaching them
here so that people can actually try out this series if they want to.

Comments are very welcome!



The patch series has been rebased on Konrad's stable/for-linus-3.7
branch.

Arnd, Russell, what do you think about this series? If you are OK with
it, to whom should I submit it?



Changes in v5:
- rebase on Konrad's stable/for-linus-3.7;
- add a comment about the size of the grant table memory region in the
  device tree documentation;
- add a comment about the required presence of a GIC node in the device
  tree documentation;
- specify that the described properties are part of a top-level
  "hypervisor" node in the device tree documentation;
- specify #address-cells and #size-cells for the device tree example;
- make XEN_DOM0 depend on XEN;
- avoid "select XEN_DOM0" in XEN.


Changes in v4:
- rebase on 3.6-rc5;
- devicetree: "xen,xen" should be last as it is less specific;
- devicetree: use 2 address-cells and 2 size-cells in the reg property;
- do not xs_reset_watches on dom0;
- compile drivers/xen/pcpu.c only on x86;
- use "+=" instead of ":=" for dom0- targets;
- add a patch to update the MAINTAINERS file.


Changes in v3:
- move patches that have been picked up by Konrad at the end of the
  series;
- improve comments;
- add a doc to describe the Xen Device Tree format;
- do not use xen_ulong_t for multicalls and apic_physbase;
- add a patch at the end of the series to use the new __HVC macro;
- add missing pvclock-abi.h include to ia64 header files;
- do not use an anonymous union in struct xen_add_to_physmap.


Changes in v2:
- fix up many comments and commit messages;
- remove the early_printk patches: rely on the emulated serial for now;
- remove the xen_guest_init patch: without any PV early_printk, we don't
  need any early call to xen_guest_init, we can rely on core_initcall
  alone;
- define an HYPERCALL macro for 5 arguments hypercall wrappers, even if
  at the moment is unused;
- use ldm instead of pop in the hypercall wrappers;
- return -ENOSYS rather than -1 from the unimplemented grant_table
  functions;
- remove the pvclock ifdef in the Xen headers;
- remove include linux/types.h from xen/interface/xen.h;
- replace pr_info with pr_debug in xen_guest_init;
- add a new patch to introduce xen_ulong_t and use it top replace all
  the occurences of unsigned long in the public Xen interface;
- explicitely size all the pointers to 64 bit on ARM, so that the
  hypercall ABI is "64 bit ready";
- clean up xenbus_init;
- make pci.o depend on CONFIG_PCI and acpi.o depend on CONFIG_ACPI;
- mark Xen guest support on ARM as EXPERIMENTAL;
- introduce GRANT_TABLE_PHYSADDR;
- remove unneeded initialization of boot_max_nr_grant_frames;
- add a new patch to clear IRQ_NOAUTOEN and IRQ_NOREQUEST in events.c;
- return -EINVAL from xen_remap_domain_mfn_range if
  auto_translated_physmap;
- retain binary compatibility in xen_add_to_physmap: use a union to
  introduce foreign_domid.



Shortlog and diffstat:

Stefano Stabellini (17):
      arm: initial Xen support
      xen/arm: hypercalls
      xen/arm: page.h definitions
      xen/arm: sync_bitops
      xen/arm: empty implementation of grant_table arch specific functions
      docs: Xen ARM DT bindings
      xen/arm: Xen detection and shared_info page mapping
      xen/arm: Introduce xen_ulong_t for unsigned long
      xen: do not compile manage, balloon, pci, acpi, pcpu and cpu_hotplug on ARM
      xen/arm: introduce CONFIG_XEN on ARM
      xen/arm: get privilege status
      xen/arm: initialize grant_table on ARM
      xen/arm: receive Xen events on ARM
      xen/arm: implement alloc/free_xenballooned_pages with alloc_pages/kfree
      xen/arm: compile blkfront and blkback
      xen/arm: compile netback
      MAINTAINERS: add myself as Xen ARM maintainer

 Documentation/devicetree/bindings/arm/xen.txt |   25 ++++
 MAINTAINERS                                   |    7 +
 arch/arm/Kconfig                              |   10 ++
 arch/arm/Makefile                             |    1 +
 arch/arm/include/asm/hypervisor.h             |    6 +
 arch/arm/include/asm/sync_bitops.h            |   27 ++++
 arch/arm/include/asm/xen/events.h             |   18 +++
 arch/arm/include/asm/xen/hypercall.h          |   69 ++++++++++
 arch/arm/include/asm/xen/hypervisor.h         |   19 +++
 arch/arm/include/asm/xen/interface.h          |   73 +++++++++++
 arch/arm/include/asm/xen/page.h               |   82 ++++++++++++
 arch/arm/xen/Makefile                         |    1 +
 arch/arm/xen/enlighten.c                      |  168 +++++++++++++++++++++++++
 arch/arm/xen/grant-table.c                    |   53 ++++++++
 arch/arm/xen/hypercall.S                      |  106 ++++++++++++++++
 arch/ia64/include/asm/xen/interface.h         |    1 +
 arch/x86/include/asm/xen/interface.h          |    1 +
 arch/x86/xen/enlighten.c                      |    1 +
 arch/x86/xen/irq.c                            |    1 +
 arch/x86/xen/xen-ops.h                        |    1 -
 drivers/block/xen-blkback/blkback.c           |    1 +
 drivers/net/xen-netback/netback.c             |    1 +
 drivers/net/xen-netfront.c                    |    1 +
 drivers/xen/Makefile                          |   13 ++-
 drivers/xen/events.c                          |   17 ++-
 include/xen/events.h                          |    2 +
 include/xen/interface/features.h              |    3 +
 include/xen/interface/io/protocols.h          |    3 +
 include/xen/interface/memory.h                |   12 +-
 include/xen/interface/physdev.h               |    2 +-
 include/xen/interface/version.h               |    2 +-
 include/xen/xen.h                             |    2 +-
 32 files changed, 712 insertions(+), 17 deletions(-)


A branch based on 3.6-rc5 and Konrad's stable/for-linus-3.7 is available
here:

git://xenbits.xen.org/people/sstabellini/linux-pvhvm.git 3.6-rc5-arm-5


Cheers,

Stefano
--_004_alpineDEB202120914114515029232kaballukxensourcecom_
Content-Type: text/plain; name="vexpress-v2m-rs1.dtsi"
Content-Transfer-Encoding: BASE64
Content-ID: <alpine.DEB.2.02.1209141210430.29232@kaball.uk.xensource.com>
Content-Description: vexpress-v2m-rs1.dtsi
Content-Disposition: attachment; filename="vexpress-v2m-rs1.dtsi"; size=4677;
	creation-date="Fri, 14 Sep 2012 11:13:42 GMT";
	modification-date="Fri, 14 Sep 2012 11:13:42 GMT"

LyoNCiAqIEFSTSBMdGQuIFZlcnNhdGlsZSBFeHByZXNzDQogKg0KICogTW90aGVyYm9hcmQgRXhw
cmVzcyB1QVRYDQogKiBWMk0tUDENCiAqDQogKiBIQkktMDE5MEQNCiAqDQogKiBSUzEgbWVtb3J5
IG1hcCAoIkFSTSBDb3J0ZXgtQSBTZXJpZXMgbWVtb3J5IG1hcCIgaW4gdGhlIGJvYXJkJ3MNCiAq
IFRlY2huaWNhbCBSZWZlcmVuY2UgTWFudWFsKQ0KICoNCiAqIFdBUk5JTkchIFRoZSBoYXJkd2Fy
ZSBkZXNjcmliZWQgaW4gdGhpcyBmaWxlIGlzIGluZGVwZW5kZW50IGZyb20gdGhlDQogKiBvcmln
aW5hbCB2YXJpYW50ICh2ZXhwcmVzcy12Mm0uZHRzaSksIGJ1dCB0aGVyZSBpcyBhIHN0cm9uZw0K
ICogY29ycmVzcG9uZGVuY2UgYmV0d2VlbiB0aGUgdHdvIGNvbmZpZ3VyYXRpb25zLg0KICoNCiAq
IFRBS0UgQ0FSRSBXSEVOIE1BSU5UQUlOSU5HIFRISVMgRklMRSBUTyBQUk9QQUdBVEUgQU5ZIFJF
TEVWQU5UDQogKiBDSEFOR0VTIFRPIHZleHByZXNzLXYybS5kdHNpIQ0KICovDQoNCi8gew0KCWFs
aWFzZXMgew0KCQlhcm0sdjJtX3RpbWVyID0gJnYybV90aW1lcjAxOw0KCX07DQoNCgltb3RoZXJi
b2FyZCB7DQoJCWNvbXBhdGlibGUgPSAic2ltcGxlLWJ1cyI7DQoJCWFybSx2Mm0tbWVtb3J5LW1h
cCA9ICJyczEiOw0KCQkjYWRkcmVzcy1jZWxscyA9IDwyPjsgLyogU01CIGNoaXBzZWxlY3QgbnVt
YmVyIGFuZCBvZmZzZXQgKi8NCgkJI3NpemUtY2VsbHMgPSA8MT47DQoJCSNpbnRlcnJ1cHQtY2Vs
bHMgPSA8MT47DQoNCgkJZmxhc2hAMCwwMDAwMDAwMCB7DQoJCQljb21wYXRpYmxlID0gImFybSx2
ZXhwcmVzcy1mbGFzaCIsICJjZmktZmxhc2giOw0KCQkJcmVnID0gPDAgMHgwMDAwMDAwMCAweDA0
MDAwMDAwPiwNCgkJCSAgICAgIDw0IDB4MDAwMDAwMDAgMHgwNDAwMDAwMD47DQoJCQliYW5rLXdp
ZHRoID0gPDQ+Ow0KCQl9Ow0KDQoJCXBzcmFtQDEsMDAwMDAwMDAgew0KCQkJY29tcGF0aWJsZSA9
ICJhcm0sdmV4cHJlc3MtcHNyYW0iLCAibXRkLXJhbSI7DQoJCQlyZWcgPSA8MSAweDAwMDAwMDAw
IDB4MDIwMDAwMDA+Ow0KCQkJYmFuay13aWR0aCA9IDw0PjsNCgkJfTsNCg0KCQl2cmFtQDIsMDAw
MDAwMDAgew0KCQkJY29tcGF0aWJsZSA9ICJhcm0sdmV4cHJlc3MtdnJhbSI7DQoJCQlyZWcgPSA8
MiAweDAwMDAwMDAwIDB4MDA4MDAwMDA+Ow0KCQl9Ow0KDQoJCWV0aGVybmV0QDIsMDIwMDAwMDAg
ew0KCQkJY29tcGF0aWJsZSA9ICJzbXNjLGxhbjkxYzExMSI7DQoJCQlyZWcgPSA8MiAweDAyMDAw
MDAwIDB4MTAwMDA+Ow0KCQkJaW50ZXJydXB0cyA9IDwxNT47DQoJCX07DQoNCgkJdXNiQDIsMDMw
MDAwMDAgew0KCQkJY29tcGF0aWJsZSA9ICJueHAsdXNiLWlzcDE3NjEiOw0KCQkJcmVnID0gPDIg
MHgwMzAwMDAwMCAweDIwMDAwPjsNCgkJCWludGVycnVwdHMgPSA8MTY+Ow0KCQkJcG9ydDEtb3Rn
Ow0KCQl9Ow0KDQoJCWlvZnBnYUAzLDAwMDAwMDAwIHsNCgkJCWNvbXBhdGlibGUgPSAiYXJtLGFt
YmEtYnVzIiwgInNpbXBsZS1idXMiOw0KCQkJI2FkZHJlc3MtY2VsbHMgPSA8MT47DQoJCQkjc2l6
ZS1jZWxscyA9IDwxPjsNCgkJCXJhbmdlcyA9IDwwIDMgMCAweDIwMDAwMD47DQoNCgkJCXN5c3Jl
Z0AwMTAwMDAgew0KCQkJCWNvbXBhdGlibGUgPSAiYXJtLHZleHByZXNzLXN5c3JlZyI7DQoJCQkJ
cmVnID0gPDB4MDEwMDAwIDB4MTAwMD47DQoJCQl9Ow0KDQoJCQlzeXNjdGxAMDIwMDAwIHsNCgkJ
CQljb21wYXRpYmxlID0gImFybSxzcDgxMCIsICJhcm0scHJpbWVjZWxsIjsNCgkJCQlyZWcgPSA8
MHgwMjAwMDAgMHgxMDAwPjsNCgkJCX07DQoNCgkJCS8qIFBDSS1FIEkyQyBidXMgKi8NCgkJCXYy
bV9pMmNfcGNpZTogaTJjQDAzMDAwMCB7DQoJCQkJY29tcGF0aWJsZSA9ICJhcm0sdmVyc2F0aWxl
LWkyYyI7DQoJCQkJcmVnID0gPDB4MDMwMDAwIDB4MTAwMD47DQoNCgkJCQkjYWRkcmVzcy1jZWxs
cyA9IDwxPjsNCgkJCQkjc2l6ZS1jZWxscyA9IDwwPjsNCg0KCQkJCXBjaWUtc3dpdGNoQDYwIHsN
CgkJCQkJY29tcGF0aWJsZSA9ICJpZHQsODlocGVzMzJoOCI7DQoJCQkJCXJlZyA9IDwweDYwPjsN
CgkJCQl9Ow0KCQkJfTsNCg0KCQkJYWFjaUAwNDAwMDAgew0KCQkJCWNvbXBhdGlibGUgPSAiYXJt
LHBsMDQxIiwgImFybSxwcmltZWNlbGwiOw0KCQkJCXJlZyA9IDwweDA0MDAwMCAweDEwMDA+Ow0K
CQkJCWludGVycnVwdHMgPSA8MTE+Ow0KCQkJfTsNCg0KCQkJbW1jaUAwNTAwMDAgew0KCQkJCWNv
bXBhdGlibGUgPSAiYXJtLHBsMTgwIiwgImFybSxwcmltZWNlbGwiOw0KCQkJCXJlZyA9IDwweDA1
MDAwMCAweDEwMDA+Ow0KCQkJCWludGVycnVwdHMgPSA8OSAxMD47DQoJCQl9Ow0KDQoJCQlrbWlA
MDYwMDAwIHsNCgkJCQljb21wYXRpYmxlID0gImFybSxwbDA1MCIsICJhcm0scHJpbWVjZWxsIjsN
CgkJCQlyZWcgPSA8MHgwNjAwMDAgMHgxMDAwPjsNCgkJCQlpbnRlcnJ1cHRzID0gPDEyPjsNCgkJ
CX07DQoNCgkJCWttaUAwNzAwMDAgew0KCQkJCWNvbXBhdGlibGUgPSAiYXJtLHBsMDUwIiwgImFy
bSxwcmltZWNlbGwiOw0KCQkJCXJlZyA9IDwweDA3MDAwMCAweDEwMDA+Ow0KCQkJCWludGVycnVw
dHMgPSA8MTM+Ow0KCQkJfTsNCg0KCQkJdjJtX3NlcmlhbDA6IHVhcnRAMDkwMDAwIHsNCgkJCQlj
b21wYXRpYmxlID0gImFybSxwbDAxMSIsICJhcm0scHJpbWVjZWxsIjsNCgkJCQlyZWcgPSA8MHgw
OTAwMDAgMHgxMDAwPjsNCgkJCQlpbnRlcnJ1cHRzID0gPDU+Ow0KCQkJfTsNCg0KCQkJdjJtX3Nl
cmlhbDE6IHVhcnRAMGEwMDAwIHsNCgkJCQljb21wYXRpYmxlID0gImFybSxwbDAxMSIsICJhcm0s
cHJpbWVjZWxsIjsNCgkJCQlyZWcgPSA8MHgwYTAwMDAgMHgxMDAwPjsNCgkJCQlpbnRlcnJ1cHRz
ID0gPDY+Ow0KCQkJfTsNCg0KCQkJdjJtX3NlcmlhbDI6IHVhcnRAMGIwMDAwIHsNCgkJCQljb21w
YXRpYmxlID0gImFybSxwbDAxMSIsICJhcm0scHJpbWVjZWxsIjsNCgkJCQlyZWcgPSA8MHgwYjAw
MDAgMHgxMDAwPjsNCgkJCQlpbnRlcnJ1cHRzID0gPDc+Ow0KCQkJfTsNCg0KCQkJdjJtX3Nlcmlh
bDM6IHVhcnRAMGMwMDAwIHsNCgkJCQljb21wYXRpYmxlID0gImFybSxwbDAxMSIsICJhcm0scHJp
bWVjZWxsIjsNCgkJCQlyZWcgPSA8MHgwYzAwMDAgMHgxMDAwPjsNCgkJCQlpbnRlcnJ1cHRzID0g
PDg+Ow0KCQkJfTsNCg0KCQkJd2R0QDBmMDAwMCB7DQoJCQkJY29tcGF0aWJsZSA9ICJhcm0sc3A4
MDUiLCAiYXJtLHByaW1lY2VsbCI7DQoJCQkJcmVnID0gPDB4MGYwMDAwIDB4MTAwMD47DQoJCQkJ
aW50ZXJydXB0cyA9IDwwPjsNCgkJCX07DQoNCgkJCXYybV90aW1lcjAxOiB0aW1lckAxMTAwMDAg
ew0KCQkJCWNvbXBhdGlibGUgPSAiYXJtLHNwODA0IiwgImFybSxwcmltZWNlbGwiOw0KCQkJCXJl
ZyA9IDwweDExMDAwMCAweDEwMDA+Ow0KCQkJCWludGVycnVwdHMgPSA8Mj47DQoJCQl9Ow0KDQoJ
CQl2Mm1fdGltZXIyMzogdGltZXJAMTIwMDAwIHsNCgkJCQljb21wYXRpYmxlID0gImFybSxzcDgw
NCIsICJhcm0scHJpbWVjZWxsIjsNCgkJCQlyZWcgPSA8MHgxMjAwMDAgMHgxMDAwPjsNCgkJCQlp
bnRlcnJ1cHRzID0gPDM+Ow0KCQkJfTsNCg0KCQkJLyogRFZJIEkyQyBidXMgKi8NCgkJCXYybV9p
MmNfZHZpOiBpMmNAMTYwMDAwIHsNCgkJCQljb21wYXRpYmxlID0gImFybSx2ZXJzYXRpbGUtaTJj
IjsNCgkJCQlyZWcgPSA8MHgxNjAwMDAgMHgxMDAwPjsNCg0KCQkJCSNhZGRyZXNzLWNlbGxzID0g
PDE+Ow0KCQkJCSNzaXplLWNlbGxzID0gPDA+Ow0KDQoJCQkJZHZpLXRyYW5zbWl0dGVyQDM5IHsN
CgkJCQkJY29tcGF0aWJsZSA9ICJzaWwsc2lpOTAyMi10cGkiLCAic2lsLHNpaTkwMjIiOw0KCQkJ
CQlyZWcgPSA8MHgzOT47DQoJCQkJfTsNCg0KCQkJCWR2aS10cmFuc21pdHRlckA2MCB7DQoJCQkJ
CWNvbXBhdGlibGUgPSAic2lsLHNpaTkwMjItY3BpIiwgInNpbCxzaWk5MDIyIjsNCgkJCQkJcmVn
ID0gPDB4NjA+Ow0KCQkJCX07DQoJCQl9Ow0KDQoJCQlydGNAMTcwMDAwIHsNCgkJCQljb21wYXRp
YmxlID0gImFybSxwbDAzMSIsICJhcm0scHJpbWVjZWxsIjsNCgkJCQlyZWcgPSA8MHgxNzAwMDAg
MHgxMDAwPjsNCgkJCQlpbnRlcnJ1cHRzID0gPDQ+Ow0KCQkJfTsNCg0KCQkJY29tcGFjdC1mbGFz
aEAxYTAwMDAgew0KCQkJCWNvbXBhdGlibGUgPSAiYXJtLHZleHByZXNzLWNmIiwgImF0YS1nZW5l
cmljIjsNCgkJCQlyZWcgPSA8MHgxYTAwMDAgMHgxMDANCgkJCQkgICAgICAgMHgxYTAxMDAgMHhm
MDA+Ow0KCQkJCXJlZy1zaGlmdCA9IDwyPjsNCgkJCX07DQoNCgkJCWNsY2RAMWYwMDAwIHsNCgkJ
CQljb21wYXRpYmxlID0gImFybSxwbDExMSIsICJhcm0scHJpbWVjZWxsIjsNCgkJCQlyZWcgPSA8
MHgxZjAwMDAgMHgxMDAwPjsNCgkJCQlpbnRlcnJ1cHRzID0gPDE0PjsNCgkJCX07DQoJCX07DQoN
CgkJdjJtX2ZpeGVkXzN2MzogZml4ZWRyZWd1bGF0b3JAMCB7DQoJCQljb21wYXRpYmxlID0gInJl
Z3VsYXRvci1maXhlZCI7DQoJCQlyZWd1bGF0b3ItbmFtZSA9ICIzVjMiOw0KCQkJcmVndWxhdG9y
LW1pbi1taWNyb3ZvbHQgPSA8MzMwMDAwMD47DQoJCQlyZWd1bGF0b3ItbWF4LW1pY3Jvdm9sdCA9
IDwzMzAwMDAwPjsNCgkJCXJlZ3VsYXRvci1hbHdheXMtb247DQoJCX07DQoJfTsNCn07DQo=

--_004_alpineDEB202120914114515029232kaballukxensourcecom_
Content-Type: text/plain; name="vexpress-v2p-ca15-tc1.dts"
Content-Transfer-Encoding: BASE64
Content-ID: <alpine.DEB.2.02.1209141210431.29232@kaball.uk.xensource.com>
Content-Description: vexpress-v2p-ca15-tc1.dts
Content-Disposition: attachment; filename="vexpress-v2p-ca15-tc1.dts";
	size=3264; creation-date="Fri, 14 Sep 2012 11:13:42 GMT";
	modification-date="Fri, 14 Sep 2012 11:13:42 GMT"

LyoNCiAqIEFSTSBMdGQuIFZlcnNhdGlsZSBFeHByZXNzDQogKg0KICogQ29yZVRpbGUgRXhwcmVz
cyBBMTV4MiAodmVyc2lvbiB3aXRoIFRlc3QgQ2hpcCAxKQ0KICogQ29ydGV4LUExNSBNUENvcmUg
KFYyUC1DQTE1KQ0KICoNCiAqIEhCSS0wMjM3QQ0KICovDQoNCi9kdHMtdjEvOw0KDQovIHsNCglt
b2RlbCA9ICJWMlAtQ0ExNSI7DQoJYXJtLGhiaSA9IDwweDIzNz47DQoJY29tcGF0aWJsZSA9ICJh
cm0sdmV4cHJlc3MsdjJwLWNhMTUsdGMxIiwgImFybSx2ZXhwcmVzcyx2MnAtY2ExNSIsICJhcm0s
dmV4cHJlc3MiOw0KCWludGVycnVwdC1wYXJlbnQgPSA8JmdpYz47DQoJI2FkZHJlc3MtY2VsbHMg
PSA8Mj47DQoJI3NpemUtY2VsbHMgPSA8Mj47DQoNCgljaG9zZW4gew0KICAgICAgICAgICAgICAg
ICBib290YXJncyA9ICJkb20wX21lbT0xMjhNIjsNCiAgICAgICAgICAgICAgICAgeGVuLGRvbTAt
Ym9vdGFyZ3MgPSAiZWFybHlwcmludGsgY29uc29sZT10dHlBTUExIHJvb3Q9L2Rldi9tbWNibGsw
IGRlYnVnIHJ3IjsNCgl9Ow0KDQoJYWxpYXNlcyB7DQoJCXNlcmlhbDAgPSAmdjJtX3NlcmlhbDA7
DQoJCXNlcmlhbDEgPSAmdjJtX3NlcmlhbDE7DQoJCXNlcmlhbDIgPSAmdjJtX3NlcmlhbDI7DQoJ
CXNlcmlhbDMgPSAmdjJtX3NlcmlhbDM7DQoJCWkyYzAgPSAmdjJtX2kyY19kdmk7DQoJCWkyYzEg
PSAmdjJtX2kyY19wY2llOw0KCX07DQoNCgljcHVzIHsNCgkJI2FkZHJlc3MtY2VsbHMgPSA8MT47
DQoJCSNzaXplLWNlbGxzID0gPDA+Ow0KDQoJCWNwdUAwIHsNCgkJCWRldmljZV90eXBlID0gImNw
dSI7DQoJCQljb21wYXRpYmxlID0gImFybSxjb3J0ZXgtYTE1IjsNCgkJCXJlZyA9IDwwPjsNCgkJ
fTsNCgl9Ow0KDQoJbWVtb3J5QDgwMDAwMDAwIHsNCgkJZGV2aWNlX3R5cGUgPSAibWVtb3J5IjsN
CgkJcmVnID0gPDAgMHg4MDAwMDAwMCAwIDB4ODAwMDAwMDA+Ow0KCX07DQoNCglnaWM6IGludGVy
cnVwdC1jb250cm9sbGVyQDJjMDAxMDAwIHsNCgkJY29tcGF0aWJsZSA9ICJhcm0sY29ydGV4LWEx
NS1naWMiLCAiYXJtLGNvcnRleC1hOS1naWMiOw0KCQkjaW50ZXJydXB0LWNlbGxzID0gPDM+Ow0K
CQkjYWRkcmVzcy1jZWxscyA9IDwwPjsNCgkJaW50ZXJydXB0LWNvbnRyb2xsZXI7DQoJCXJlZyA9
IDwwIDB4MmMwMDEwMDAgMCAweDEwMDA+LA0KCQkgICAgICA8MCAweDJjMDAyMDAwIDAgMHgxMDAw
PiwNCgkJICAgICAgPDAgMHgyYzAwNDAwMCAwIDB4MjAwMD4sDQoJCSAgICAgIDwwIDB4MmMwMDYw
MDAgMCAweDIwMDA+Ow0KCQlpbnRlcnJ1cHRzID0gPDEgOSAweGYwND47DQoJfTsNCg0KCXRpbWVy
IHsNCgkJY29tcGF0aWJsZSA9ICJhcm0sYXJtdjctdGltZXIiOw0KCQlpbnRlcnJ1cHRzID0gPDEg
MTMgMHhmMDg+LA0KCQkJICAgICA8MSAxNCAweGYwOD4sDQoJCQkgICAgIDwxIDExIDB4ZjA4PiwN
CgkJCSAgICAgPDEgMTAgMHhmMDg+Ow0KCX07DQoNCglwbXUgew0KCQljb21wYXRpYmxlID0gImFy
bSxjb3J0ZXgtYTE1LXBtdSIsICJhcm0sY29ydGV4LWE5LXBtdSI7DQoJCWludGVycnVwdHMgPSA8
MCA2OCA0PiwNCgkJCSAgICAgPDAgNjkgND47DQoJfTsNCg0KCWh5cGVydmlzb3Igew0KCQljb21w
YXRpYmxlID0gInhlbix4ZW4tNC4yIiwgInhlbix4ZW4iOw0KCQlyZWcgPSA8MCAweGIwMDAwMDAw
IDAgMHgyMDAwMD47DQoJCWludGVycnVwdHMgPSA8MSAxNSAweGYwOD47DQoJfTsNCg0KCW1vdGhl
cmJvYXJkIHsNCgkJcmFuZ2VzID0gPDAgMCAwIDB4MDgwMDAwMDAgMHgwNDAwMDAwMD4sDQoJCQkg
PDEgMCAwIDB4MTQwMDAwMDAgMHgwNDAwMDAwMD4sDQoJCQkgPDIgMCAwIDB4MTgwMDAwMDAgMHgw
NDAwMDAwMD4sDQoJCQkgPDMgMCAwIDB4MWMwMDAwMDAgMHgwNDAwMDAwMD4sDQoJCQkgPDQgMCAw
IDB4MGMwMDAwMDAgMHgwNDAwMDAwMD4sDQoJCQkgPDUgMCAwIDB4MTAwMDAwMDAgMHgwNDAwMDAw
MD47DQoNCgkJaW50ZXJydXB0LW1hcC1tYXNrID0gPDAgMCA2Mz47DQoJCWludGVycnVwdC1tYXAg
PSA8MCAwICAwICZnaWMgMCAgMCA0PiwNCgkJCQk8MCAwICAxICZnaWMgMCAgMSA0PiwNCgkJCQk8
MCAwICAyICZnaWMgMCAgMiA0PiwNCgkJCQk8MCAwICAzICZnaWMgMCAgMyA0PiwNCgkJCQk8MCAw
ICA0ICZnaWMgMCAgNCA0PiwNCgkJCQk8MCAwICA1ICZnaWMgMCAgNSA0PiwNCgkJCQk8MCAwICA2
ICZnaWMgMCAgNiA0PiwNCgkJCQk8MCAwICA3ICZnaWMgMCAgNyA0PiwNCgkJCQk8MCAwICA4ICZn
aWMgMCAgOCA0PiwNCgkJCQk8MCAwICA5ICZnaWMgMCAgOSA0PiwNCgkJCQk8MCAwIDEwICZnaWMg
MCAxMCA0PiwNCgkJCQk8MCAwIDExICZnaWMgMCAxMSA0PiwNCgkJCQk8MCAwIDEyICZnaWMgMCAx
MiA0PiwNCgkJCQk8MCAwIDEzICZnaWMgMCAxMyA0PiwNCgkJCQk8MCAwIDE0ICZnaWMgMCAxNCA0
PiwNCgkJCQk8MCAwIDE1ICZnaWMgMCAxNSA0PiwNCgkJCQk8MCAwIDE2ICZnaWMgMCAxNiA0PiwN
CgkJCQk8MCAwIDE3ICZnaWMgMCAxNyA0PiwNCgkJCQk8MCAwIDE4ICZnaWMgMCAxOCA0PiwNCgkJ
CQk8MCAwIDE5ICZnaWMgMCAxOSA0PiwNCgkJCQk8MCAwIDIwICZnaWMgMCAyMCA0PiwNCgkJCQk8
MCAwIDIxICZnaWMgMCAyMSA0PiwNCgkJCQk8MCAwIDIyICZnaWMgMCAyMiA0PiwNCgkJCQk8MCAw
IDIzICZnaWMgMCAyMyA0PiwNCgkJCQk8MCAwIDI0ICZnaWMgMCAyNCA0PiwNCgkJCQk8MCAwIDI1
ICZnaWMgMCAyNSA0PiwNCgkJCQk8MCAwIDI2ICZnaWMgMCAyNiA0PiwNCgkJCQk8MCAwIDI3ICZn
aWMgMCAyNyA0PiwNCgkJCQk8MCAwIDI4ICZnaWMgMCAyOCA0PiwNCgkJCQk8MCAwIDI5ICZnaWMg
MCAyOSA0PiwNCgkJCQk8MCAwIDMwICZnaWMgMCAzMCA0PiwNCgkJCQk8MCAwIDMxICZnaWMgMCAz
MSA0PiwNCgkJCQk8MCAwIDMyICZnaWMgMCAzMiA0PiwNCgkJCQk8MCAwIDMzICZnaWMgMCAzMyA0
PiwNCgkJCQk8MCAwIDM0ICZnaWMgMCAzNCA0PiwNCgkJCQk8MCAwIDM1ICZnaWMgMCAzNSA0PiwN
CgkJCQk8MCAwIDM2ICZnaWMgMCAzNiA0PiwNCgkJCQk8MCAwIDM3ICZnaWMgMCAzNyA0PiwNCgkJ
CQk8MCAwIDM4ICZnaWMgMCAzOCA0PiwNCgkJCQk8MCAwIDM5ICZnaWMgMCAzOSA0PiwNCgkJCQk8
MCAwIDQwICZnaWMgMCA0MCA0PiwNCgkJCQk8MCAwIDQxICZnaWMgMCA0MSA0PiwNCgkJCQk8MCAw
IDQyICZnaWMgMCA0MiA0PjsNCgl9Ow0KfTsNCg0KL2luY2x1ZGUvICJ2ZXhwcmVzcy12Mm0tcnMx
LmR0c2kiDQo=

--_004_alpineDEB202120914114515029232kaballukxensourcecom_
Content-Type: text/plain; name="vexpress-virt.dts"
Content-Transfer-Encoding: BASE64
Content-ID: <alpine.DEB.2.02.1209141210432.29232@kaball.uk.xensource.com>
Content-Description: vexpress-virt.dts
Content-Disposition: attachment; filename="vexpress-virt.dts"; size=2729;
	creation-date="Fri, 14 Sep 2012 11:13:42 GMT";
	modification-date="Fri, 14 Sep 2012 11:13:42 GMT"

LyoNCiAqIEFSTSBMdGQuIFZlcnNhdGlsZSBFeHByZXNzDQogKg0KICogQVJNIEVudmVsb3BlIE1v
ZGVsIHY3QSAoc2luZ2xlIENQVSkuDQogKi8NCg0KL2R0cy12MS87DQoNCi9pbmNsdWRlLyAic2tl
bGV0b24uZHRzaSINCg0KLyB7DQoJbW9kZWwgPSAiVjJQLUFFTXY3QSI7DQoJY29tcGF0aWJsZSA9
ICJhcm0sdmV4cHJlc3MsdjJwLWFlbSx2N2EiLCAiYXJtLHZleHByZXNzLHYycC1hZW0iLCAiYXJt
LHZleHByZXNzIjsNCglpbnRlcnJ1cHQtcGFyZW50ID0gPCZnaWM+Ow0KDQogICAgICAgIGNob3Nl
biB7DQogICAgICAgICAgICAgICAgYm9vdGFyZ3MgPSAiZWFybHlwcmludGsgZGVidWcgbG9nbGV2
ZWw9OSBjb25zb2xlPWh2YzAgcm9vdD0vZGV2L3h2ZGEgaW5pdD0vc2Jpbi9pbml0IjsNCiAgICAg
ICAgfTsNCg0KCWNwdXMgew0KCQkjYWRkcmVzcy1jZWxscyA9IDwxPjsNCgkJI3NpemUtY2VsbHMg
PSA8MD47DQoNCgkJY3B1QDAgew0KCQkJZGV2aWNlX3R5cGUgPSAiY3B1IjsNCgkJCWNvbXBhdGli
bGUgPSAiYXJtLGNvcnRleC1hMTUiOw0KCQkJcmVnID0gPDA+Ow0KCQl9Ow0KCX07DQoNCgltZW1v
cnkgew0KCQlkZXZpY2VfdHlwZSA9ICJtZW1vcnkiOw0KCQlyZWcgPSA8MHg4MDAwMDAwMCAweDA4
MDAwMDAwPjsNCgl9Ow0KDQoJZ2ljOiBpbnRlcnJ1cHQtY29udHJvbGxlckAyYzAwMTAwMCB7DQoJ
CWNvbXBhdGlibGUgPSAiYXJtLGNvcnRleC1hOS1naWMiOw0KCQkjaW50ZXJydXB0LWNlbGxzID0g
PDM+Ow0KCQkjYWRkcmVzcy1jZWxscyA9IDwwPjsNCgkJaW50ZXJydXB0LWNvbnRyb2xsZXI7DQoJ
CXJlZyA9IDwweDJjMDAxMDAwIDB4MTAwMD4sDQoJCSAgICAgIDwweDJjMDAyMDAwIDB4MTAwPjsN
Cgl9Ow0KDQoJdGltZXIgew0KCQljb21wYXRpYmxlID0gImFybSxhcm12Ny10aW1lciI7DQoJCWlu
dGVycnVwdHMgPSA8MSAxMyAweGYwOD4sDQoJCQkgICAgIDwxIDE0IDB4ZjA4PiwNCgkJCSAgICAg
PDEgMTEgMHhmMDg+LA0KCQkJICAgICA8MSAxMCAweGYwOD47DQoJfTsNCg0KCWh5cGVydmlzb3Ig
ew0KCQljb21wYXRpYmxlID0gInhlbix4ZW4tNC4yIiwgInhlbix4ZW4iOw0KCQlyZWcgPSA8MHhi
MDAwMDAwMCAweDIwMDAwPjsNCgkJaW50ZXJydXB0cyA9IDwxIDE1IDB4ZjA4PjsNCgl9Ow0KDQoJ
bW90aGVyYm9hcmQgew0KCQlhcm0sdjJtLW1lbW9yeS1tYXAgPSAicnMxIjsNCgkJcmFuZ2VzID0g
PDAgMCAweDA4MDAwMDAwIDB4MDQwMDAwMDA+LA0KCQkJIDwxIDAgMHgxNDAwMDAwMCAweDA0MDAw
MDAwPiwNCgkJCSA8MiAwIDB4MTgwMDAwMDAgMHgwNDAwMDAwMD4sDQoJCQkgPDMgMCAweDFjMDAw
MDAwIDB4MDQwMDAwMDA+LA0KCQkJIDw0IDAgMHgwYzAwMDAwMCAweDA0MDAwMDAwPiwNCgkJCSA8
NSAwIDB4MTAwMDAwMDAgMHgwNDAwMDAwMD47DQoNCgkJaW50ZXJydXB0LW1hcC1tYXNrID0gPDAg
MCA2Mz47DQoJCWludGVycnVwdC1tYXAgPSA8MCAwICAwICZnaWMgMCAgMCA0PiwNCgkJCQk8MCAw
ICAxICZnaWMgMCAgMSA0PiwNCgkJCQk8MCAwICAyICZnaWMgMCAgMiA0PiwNCgkJCQk8MCAwICAz
ICZnaWMgMCAgMyA0PiwNCgkJCQk8MCAwICA0ICZnaWMgMCAgNCA0PiwNCgkJCQk8MCAwICA1ICZn
aWMgMCAgNSA0PiwNCgkJCQk8MCAwICA2ICZnaWMgMCAgNiA0PiwNCgkJCQk8MCAwICA3ICZnaWMg
MCAgNyA0PiwNCgkJCQk8MCAwICA4ICZnaWMgMCAgOCA0PiwNCgkJCQk8MCAwICA5ICZnaWMgMCAg
OSA0PiwNCgkJCQk8MCAwIDEwICZnaWMgMCAxMCA0PiwNCgkJCQk8MCAwIDExICZnaWMgMCAxMSA0
PiwNCgkJCQk8MCAwIDEyICZnaWMgMCAxMiA0PiwNCgkJCQk8MCAwIDEzICZnaWMgMCAxMyA0PiwN
CgkJCQk8MCAwIDE0ICZnaWMgMCAxNCA0PiwNCgkJCQk8MCAwIDE1ICZnaWMgMCAxNSA0PiwNCgkJ
CQk8MCAwIDE2ICZnaWMgMCAxNiA0PiwNCgkJCQk8MCAwIDE3ICZnaWMgMCAxNyA0PiwNCgkJCQk8
MCAwIDE4ICZnaWMgMCAxOCA0PiwNCgkJCQk8MCAwIDE5ICZnaWMgMCAxOSA0PiwNCgkJCQk8MCAw
IDIwICZnaWMgMCAyMCA0PiwNCgkJCQk8MCAwIDIxICZnaWMgMCAyMSA0PiwNCgkJCQk8MCAwIDIy
ICZnaWMgMCAyMiA0PiwNCgkJCQk8MCAwIDIzICZnaWMgMCAyMyA0PiwNCgkJCQk8MCAwIDI0ICZn
aWMgMCAyNCA0PiwNCgkJCQk8MCAwIDI1ICZnaWMgMCAyNSA0PiwNCgkJCQk8MCAwIDI2ICZnaWMg
MCAyNiA0PiwNCgkJCQk8MCAwIDI3ICZnaWMgMCAyNyA0PiwNCgkJCQk8MCAwIDI4ICZnaWMgMCAy
OCA0PiwNCgkJCQk8MCAwIDI5ICZnaWMgMCAyOSA0PiwNCgkJCQk8MCAwIDMwICZnaWMgMCAzMCA0
PiwNCgkJCQk8MCAwIDMxICZnaWMgMCAzMSA0PiwNCgkJCQk8MCAwIDMyICZnaWMgMCAzMiA0PiwN
CgkJCQk8MCAwIDMzICZnaWMgMCAzMyA0PiwNCgkJCQk8MCAwIDM0ICZnaWMgMCAzNCA0PiwNCgkJ
CQk8MCAwIDM1ICZnaWMgMCAzNSA0PiwNCgkJCQk8MCAwIDM2ICZnaWMgMCAzNiA0PiwNCgkJCQk8
MCAwIDM3ICZnaWMgMCAzNyA0PiwNCgkJCQk8MCAwIDM4ICZnaWMgMCAzOCA0PiwNCgkJCQk8MCAw
IDM5ICZnaWMgMCAzOSA0PiwNCgkJCQk8MCAwIDQwICZnaWMgMCA0MCA0PiwNCgkJCQk8MCAwIDQx
ICZnaWMgMCA0MSA0PiwNCgkJCQk8MCAwIDQyICZnaWMgMCA0MiA0PjsNCgl9Ow0KfTsNCg0KLyog
L2luY2x1ZGUvICJ2ZXhwcmVzcy12Mm0tcnMxLXJ0c20uZHRzaSIgKi8NCg==

--_004_alpineDEB202120914114515029232kaballukxensourcecom_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--_004_alpineDEB202120914114515029232kaballukxensourcecom_--


From xen-devel-bounces@lists.xen.org Mon Sep 17 17:38:30 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 17: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 1TDfGv-0001d1-2v; Mon, 17 Sep 2012 17:38:13 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1TDfGt-0001ct-9G
	for xen-devel@lists.xensource.com; Mon, 17 Sep 2012 17:38:11 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1347903482!5789801!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDk2NDU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3615 invoked from network); 17 Sep 2012 17:38:03 -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;
	17 Sep 2012 17:38:03 -0000
X-IronPort-AV: E=Sophos;i="4.80,437,1344211200"; 
	d="dts'?dtsi'?scan'208";a="14587634"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Sep 2012 17:37: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.279.1; Mon, 17 Sep 2012 18:37:54 +0100
Date: Mon, 17 Sep 2012 18:37:08 +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>
Message-ID: <alpine.DEB.2.02.1209171215490.29232@kaball.uk.xensource.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Content-Type: multipart/mixed;
	boundary="_004_alpineDEB202120914114515029232kaballukxensourcecom_"
Content-ID: <alpine.DEB.2.02.1209171215491.29232@kaball.uk.xensource.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linaro-dev@lists.linaro.org" <linaro-dev@lists.linaro.org>,
	Ian Campbell <Ian.Campbell@citrix.com>, "arnd@arndb.de" <arnd@arndb.de>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>, "Tim
	\(Xen.org\)" <tim@xen.org>,
	Russell King - ARM Linux <linux@arm.linux.org.uk>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: [Xen-devel] [PATCH v5 00/17] Introduce Xen support on ARM (based on
	3.6-rc5)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--_004_alpineDEB202120914114515029232kaballukxensourcecom_
Content-Type: text/plain; charset="US-ASCII"
Content-ID: <alpine.DEB.2.02.1209171215492.29232@kaball.uk.xensource.com>

Hi all,
this patch series implements Xen support for ARMv7 with virtualization
extensions.  It allows a Linux guest to boot as dom0 and
as domU on Xen on ARM. PV console, disk and network frontends and
backends are all working correctly.

It has been tested on a Versatile Express Cortex A15 emulator, using the
latest Xen ARM developement branch
(git://xenbits.xen.org/people/ianc/xen-unstable.git arm-for-4.3) plus
the "ARM hypercall ABI: 64 bit ready" patch series
(http://marc.info/?l=xen-devel&m=134426267205408), and a simple ad-hoc
tool to build guest domains (marc.info/?l=xen-devel&m=134089788016546).

The patch marked with [HACK] has been dropped from this series, however
you can find it here:
http://marc.info/?l=linux-kernel&m=134513277823527&w=2.

I am also attaching to this email the dts'es that I am currently using
for dom0 and domU: vexpress-v2p-ca15-tc1.dts (that includes
vexpress-v2m-rs1-rtsm.dtsi) is the dts used for dom0 and it is passed to
Linux by Xen, while vexpress-virt.dts is the dts used for other domUs
and it is appended in binary form to the guest kernel image. I am not
sure where they are supposed to live yet, so I am just attaching them
here so that people can actually try out this series if they want to.

Comments are very welcome!



The patch series has been rebased on Konrad's stable/for-linus-3.7
branch.

Arnd, Russell, what do you think about this series? If you are OK with
it, to whom should I submit it?



Changes in v5:
- rebase on Konrad's stable/for-linus-3.7;
- add a comment about the size of the grant table memory region in the
  device tree documentation;
- add a comment about the required presence of a GIC node in the device
  tree documentation;
- specify that the described properties are part of a top-level
  "hypervisor" node in the device tree documentation;
- specify #address-cells and #size-cells for the device tree example;
- make XEN_DOM0 depend on XEN;
- avoid "select XEN_DOM0" in XEN.


Changes in v4:
- rebase on 3.6-rc5;
- devicetree: "xen,xen" should be last as it is less specific;
- devicetree: use 2 address-cells and 2 size-cells in the reg property;
- do not xs_reset_watches on dom0;
- compile drivers/xen/pcpu.c only on x86;
- use "+=" instead of ":=" for dom0- targets;
- add a patch to update the MAINTAINERS file.


Changes in v3:
- move patches that have been picked up by Konrad at the end of the
  series;
- improve comments;
- add a doc to describe the Xen Device Tree format;
- do not use xen_ulong_t for multicalls and apic_physbase;
- add a patch at the end of the series to use the new __HVC macro;
- add missing pvclock-abi.h include to ia64 header files;
- do not use an anonymous union in struct xen_add_to_physmap.


Changes in v2:
- fix up many comments and commit messages;
- remove the early_printk patches: rely on the emulated serial for now;
- remove the xen_guest_init patch: without any PV early_printk, we don't
  need any early call to xen_guest_init, we can rely on core_initcall
  alone;
- define an HYPERCALL macro for 5 arguments hypercall wrappers, even if
  at the moment is unused;
- use ldm instead of pop in the hypercall wrappers;
- return -ENOSYS rather than -1 from the unimplemented grant_table
  functions;
- remove the pvclock ifdef in the Xen headers;
- remove include linux/types.h from xen/interface/xen.h;
- replace pr_info with pr_debug in xen_guest_init;
- add a new patch to introduce xen_ulong_t and use it top replace all
  the occurences of unsigned long in the public Xen interface;
- explicitely size all the pointers to 64 bit on ARM, so that the
  hypercall ABI is "64 bit ready";
- clean up xenbus_init;
- make pci.o depend on CONFIG_PCI and acpi.o depend on CONFIG_ACPI;
- mark Xen guest support on ARM as EXPERIMENTAL;
- introduce GRANT_TABLE_PHYSADDR;
- remove unneeded initialization of boot_max_nr_grant_frames;
- add a new patch to clear IRQ_NOAUTOEN and IRQ_NOREQUEST in events.c;
- return -EINVAL from xen_remap_domain_mfn_range if
  auto_translated_physmap;
- retain binary compatibility in xen_add_to_physmap: use a union to
  introduce foreign_domid.



Shortlog and diffstat:

Stefano Stabellini (17):
      arm: initial Xen support
      xen/arm: hypercalls
      xen/arm: page.h definitions
      xen/arm: sync_bitops
      xen/arm: empty implementation of grant_table arch specific functions
      docs: Xen ARM DT bindings
      xen/arm: Xen detection and shared_info page mapping
      xen/arm: Introduce xen_ulong_t for unsigned long
      xen: do not compile manage, balloon, pci, acpi, pcpu and cpu_hotplug on ARM
      xen/arm: introduce CONFIG_XEN on ARM
      xen/arm: get privilege status
      xen/arm: initialize grant_table on ARM
      xen/arm: receive Xen events on ARM
      xen/arm: implement alloc/free_xenballooned_pages with alloc_pages/kfree
      xen/arm: compile blkfront and blkback
      xen/arm: compile netback
      MAINTAINERS: add myself as Xen ARM maintainer

 Documentation/devicetree/bindings/arm/xen.txt |   25 ++++
 MAINTAINERS                                   |    7 +
 arch/arm/Kconfig                              |   10 ++
 arch/arm/Makefile                             |    1 +
 arch/arm/include/asm/hypervisor.h             |    6 +
 arch/arm/include/asm/sync_bitops.h            |   27 ++++
 arch/arm/include/asm/xen/events.h             |   18 +++
 arch/arm/include/asm/xen/hypercall.h          |   69 ++++++++++
 arch/arm/include/asm/xen/hypervisor.h         |   19 +++
 arch/arm/include/asm/xen/interface.h          |   73 +++++++++++
 arch/arm/include/asm/xen/page.h               |   82 ++++++++++++
 arch/arm/xen/Makefile                         |    1 +
 arch/arm/xen/enlighten.c                      |  168 +++++++++++++++++++++++++
 arch/arm/xen/grant-table.c                    |   53 ++++++++
 arch/arm/xen/hypercall.S                      |  106 ++++++++++++++++
 arch/ia64/include/asm/xen/interface.h         |    1 +
 arch/x86/include/asm/xen/interface.h          |    1 +
 arch/x86/xen/enlighten.c                      |    1 +
 arch/x86/xen/irq.c                            |    1 +
 arch/x86/xen/xen-ops.h                        |    1 -
 drivers/block/xen-blkback/blkback.c           |    1 +
 drivers/net/xen-netback/netback.c             |    1 +
 drivers/net/xen-netfront.c                    |    1 +
 drivers/xen/Makefile                          |   13 ++-
 drivers/xen/events.c                          |   17 ++-
 include/xen/events.h                          |    2 +
 include/xen/interface/features.h              |    3 +
 include/xen/interface/io/protocols.h          |    3 +
 include/xen/interface/memory.h                |   12 +-
 include/xen/interface/physdev.h               |    2 +-
 include/xen/interface/version.h               |    2 +-
 include/xen/xen.h                             |    2 +-
 32 files changed, 712 insertions(+), 17 deletions(-)


A branch based on 3.6-rc5 and Konrad's stable/for-linus-3.7 is available
here:

git://xenbits.xen.org/people/sstabellini/linux-pvhvm.git 3.6-rc5-arm-5


Cheers,

Stefano
--_004_alpineDEB202120914114515029232kaballukxensourcecom_
Content-Type: text/plain; name="vexpress-v2m-rs1.dtsi"
Content-Transfer-Encoding: BASE64
Content-ID: <alpine.DEB.2.02.1209141210430.29232@kaball.uk.xensource.com>
Content-Description: vexpress-v2m-rs1.dtsi
Content-Disposition: attachment; filename="vexpress-v2m-rs1.dtsi"; size=4677;
	creation-date="Fri, 14 Sep 2012 11:13:42 GMT";
	modification-date="Fri, 14 Sep 2012 11:13:42 GMT"

LyoNCiAqIEFSTSBMdGQuIFZlcnNhdGlsZSBFeHByZXNzDQogKg0KICogTW90aGVyYm9hcmQgRXhw
cmVzcyB1QVRYDQogKiBWMk0tUDENCiAqDQogKiBIQkktMDE5MEQNCiAqDQogKiBSUzEgbWVtb3J5
IG1hcCAoIkFSTSBDb3J0ZXgtQSBTZXJpZXMgbWVtb3J5IG1hcCIgaW4gdGhlIGJvYXJkJ3MNCiAq
IFRlY2huaWNhbCBSZWZlcmVuY2UgTWFudWFsKQ0KICoNCiAqIFdBUk5JTkchIFRoZSBoYXJkd2Fy
ZSBkZXNjcmliZWQgaW4gdGhpcyBmaWxlIGlzIGluZGVwZW5kZW50IGZyb20gdGhlDQogKiBvcmln
aW5hbCB2YXJpYW50ICh2ZXhwcmVzcy12Mm0uZHRzaSksIGJ1dCB0aGVyZSBpcyBhIHN0cm9uZw0K
ICogY29ycmVzcG9uZGVuY2UgYmV0d2VlbiB0aGUgdHdvIGNvbmZpZ3VyYXRpb25zLg0KICoNCiAq
IFRBS0UgQ0FSRSBXSEVOIE1BSU5UQUlOSU5HIFRISVMgRklMRSBUTyBQUk9QQUdBVEUgQU5ZIFJF
TEVWQU5UDQogKiBDSEFOR0VTIFRPIHZleHByZXNzLXYybS5kdHNpIQ0KICovDQoNCi8gew0KCWFs
aWFzZXMgew0KCQlhcm0sdjJtX3RpbWVyID0gJnYybV90aW1lcjAxOw0KCX07DQoNCgltb3RoZXJi
b2FyZCB7DQoJCWNvbXBhdGlibGUgPSAic2ltcGxlLWJ1cyI7DQoJCWFybSx2Mm0tbWVtb3J5LW1h
cCA9ICJyczEiOw0KCQkjYWRkcmVzcy1jZWxscyA9IDwyPjsgLyogU01CIGNoaXBzZWxlY3QgbnVt
YmVyIGFuZCBvZmZzZXQgKi8NCgkJI3NpemUtY2VsbHMgPSA8MT47DQoJCSNpbnRlcnJ1cHQtY2Vs
bHMgPSA8MT47DQoNCgkJZmxhc2hAMCwwMDAwMDAwMCB7DQoJCQljb21wYXRpYmxlID0gImFybSx2
ZXhwcmVzcy1mbGFzaCIsICJjZmktZmxhc2giOw0KCQkJcmVnID0gPDAgMHgwMDAwMDAwMCAweDA0
MDAwMDAwPiwNCgkJCSAgICAgIDw0IDB4MDAwMDAwMDAgMHgwNDAwMDAwMD47DQoJCQliYW5rLXdp
ZHRoID0gPDQ+Ow0KCQl9Ow0KDQoJCXBzcmFtQDEsMDAwMDAwMDAgew0KCQkJY29tcGF0aWJsZSA9
ICJhcm0sdmV4cHJlc3MtcHNyYW0iLCAibXRkLXJhbSI7DQoJCQlyZWcgPSA8MSAweDAwMDAwMDAw
IDB4MDIwMDAwMDA+Ow0KCQkJYmFuay13aWR0aCA9IDw0PjsNCgkJfTsNCg0KCQl2cmFtQDIsMDAw
MDAwMDAgew0KCQkJY29tcGF0aWJsZSA9ICJhcm0sdmV4cHJlc3MtdnJhbSI7DQoJCQlyZWcgPSA8
MiAweDAwMDAwMDAwIDB4MDA4MDAwMDA+Ow0KCQl9Ow0KDQoJCWV0aGVybmV0QDIsMDIwMDAwMDAg
ew0KCQkJY29tcGF0aWJsZSA9ICJzbXNjLGxhbjkxYzExMSI7DQoJCQlyZWcgPSA8MiAweDAyMDAw
MDAwIDB4MTAwMDA+Ow0KCQkJaW50ZXJydXB0cyA9IDwxNT47DQoJCX07DQoNCgkJdXNiQDIsMDMw
MDAwMDAgew0KCQkJY29tcGF0aWJsZSA9ICJueHAsdXNiLWlzcDE3NjEiOw0KCQkJcmVnID0gPDIg
MHgwMzAwMDAwMCAweDIwMDAwPjsNCgkJCWludGVycnVwdHMgPSA8MTY+Ow0KCQkJcG9ydDEtb3Rn
Ow0KCQl9Ow0KDQoJCWlvZnBnYUAzLDAwMDAwMDAwIHsNCgkJCWNvbXBhdGlibGUgPSAiYXJtLGFt
YmEtYnVzIiwgInNpbXBsZS1idXMiOw0KCQkJI2FkZHJlc3MtY2VsbHMgPSA8MT47DQoJCQkjc2l6
ZS1jZWxscyA9IDwxPjsNCgkJCXJhbmdlcyA9IDwwIDMgMCAweDIwMDAwMD47DQoNCgkJCXN5c3Jl
Z0AwMTAwMDAgew0KCQkJCWNvbXBhdGlibGUgPSAiYXJtLHZleHByZXNzLXN5c3JlZyI7DQoJCQkJ
cmVnID0gPDB4MDEwMDAwIDB4MTAwMD47DQoJCQl9Ow0KDQoJCQlzeXNjdGxAMDIwMDAwIHsNCgkJ
CQljb21wYXRpYmxlID0gImFybSxzcDgxMCIsICJhcm0scHJpbWVjZWxsIjsNCgkJCQlyZWcgPSA8
MHgwMjAwMDAgMHgxMDAwPjsNCgkJCX07DQoNCgkJCS8qIFBDSS1FIEkyQyBidXMgKi8NCgkJCXYy
bV9pMmNfcGNpZTogaTJjQDAzMDAwMCB7DQoJCQkJY29tcGF0aWJsZSA9ICJhcm0sdmVyc2F0aWxl
LWkyYyI7DQoJCQkJcmVnID0gPDB4MDMwMDAwIDB4MTAwMD47DQoNCgkJCQkjYWRkcmVzcy1jZWxs
cyA9IDwxPjsNCgkJCQkjc2l6ZS1jZWxscyA9IDwwPjsNCg0KCQkJCXBjaWUtc3dpdGNoQDYwIHsN
CgkJCQkJY29tcGF0aWJsZSA9ICJpZHQsODlocGVzMzJoOCI7DQoJCQkJCXJlZyA9IDwweDYwPjsN
CgkJCQl9Ow0KCQkJfTsNCg0KCQkJYWFjaUAwNDAwMDAgew0KCQkJCWNvbXBhdGlibGUgPSAiYXJt
LHBsMDQxIiwgImFybSxwcmltZWNlbGwiOw0KCQkJCXJlZyA9IDwweDA0MDAwMCAweDEwMDA+Ow0K
CQkJCWludGVycnVwdHMgPSA8MTE+Ow0KCQkJfTsNCg0KCQkJbW1jaUAwNTAwMDAgew0KCQkJCWNv
bXBhdGlibGUgPSAiYXJtLHBsMTgwIiwgImFybSxwcmltZWNlbGwiOw0KCQkJCXJlZyA9IDwweDA1
MDAwMCAweDEwMDA+Ow0KCQkJCWludGVycnVwdHMgPSA8OSAxMD47DQoJCQl9Ow0KDQoJCQlrbWlA
MDYwMDAwIHsNCgkJCQljb21wYXRpYmxlID0gImFybSxwbDA1MCIsICJhcm0scHJpbWVjZWxsIjsN
CgkJCQlyZWcgPSA8MHgwNjAwMDAgMHgxMDAwPjsNCgkJCQlpbnRlcnJ1cHRzID0gPDEyPjsNCgkJ
CX07DQoNCgkJCWttaUAwNzAwMDAgew0KCQkJCWNvbXBhdGlibGUgPSAiYXJtLHBsMDUwIiwgImFy
bSxwcmltZWNlbGwiOw0KCQkJCXJlZyA9IDwweDA3MDAwMCAweDEwMDA+Ow0KCQkJCWludGVycnVw
dHMgPSA8MTM+Ow0KCQkJfTsNCg0KCQkJdjJtX3NlcmlhbDA6IHVhcnRAMDkwMDAwIHsNCgkJCQlj
b21wYXRpYmxlID0gImFybSxwbDAxMSIsICJhcm0scHJpbWVjZWxsIjsNCgkJCQlyZWcgPSA8MHgw
OTAwMDAgMHgxMDAwPjsNCgkJCQlpbnRlcnJ1cHRzID0gPDU+Ow0KCQkJfTsNCg0KCQkJdjJtX3Nl
cmlhbDE6IHVhcnRAMGEwMDAwIHsNCgkJCQljb21wYXRpYmxlID0gImFybSxwbDAxMSIsICJhcm0s
cHJpbWVjZWxsIjsNCgkJCQlyZWcgPSA8MHgwYTAwMDAgMHgxMDAwPjsNCgkJCQlpbnRlcnJ1cHRz
ID0gPDY+Ow0KCQkJfTsNCg0KCQkJdjJtX3NlcmlhbDI6IHVhcnRAMGIwMDAwIHsNCgkJCQljb21w
YXRpYmxlID0gImFybSxwbDAxMSIsICJhcm0scHJpbWVjZWxsIjsNCgkJCQlyZWcgPSA8MHgwYjAw
MDAgMHgxMDAwPjsNCgkJCQlpbnRlcnJ1cHRzID0gPDc+Ow0KCQkJfTsNCg0KCQkJdjJtX3Nlcmlh
bDM6IHVhcnRAMGMwMDAwIHsNCgkJCQljb21wYXRpYmxlID0gImFybSxwbDAxMSIsICJhcm0scHJp
bWVjZWxsIjsNCgkJCQlyZWcgPSA8MHgwYzAwMDAgMHgxMDAwPjsNCgkJCQlpbnRlcnJ1cHRzID0g
PDg+Ow0KCQkJfTsNCg0KCQkJd2R0QDBmMDAwMCB7DQoJCQkJY29tcGF0aWJsZSA9ICJhcm0sc3A4
MDUiLCAiYXJtLHByaW1lY2VsbCI7DQoJCQkJcmVnID0gPDB4MGYwMDAwIDB4MTAwMD47DQoJCQkJ
aW50ZXJydXB0cyA9IDwwPjsNCgkJCX07DQoNCgkJCXYybV90aW1lcjAxOiB0aW1lckAxMTAwMDAg
ew0KCQkJCWNvbXBhdGlibGUgPSAiYXJtLHNwODA0IiwgImFybSxwcmltZWNlbGwiOw0KCQkJCXJl
ZyA9IDwweDExMDAwMCAweDEwMDA+Ow0KCQkJCWludGVycnVwdHMgPSA8Mj47DQoJCQl9Ow0KDQoJ
CQl2Mm1fdGltZXIyMzogdGltZXJAMTIwMDAwIHsNCgkJCQljb21wYXRpYmxlID0gImFybSxzcDgw
NCIsICJhcm0scHJpbWVjZWxsIjsNCgkJCQlyZWcgPSA8MHgxMjAwMDAgMHgxMDAwPjsNCgkJCQlp
bnRlcnJ1cHRzID0gPDM+Ow0KCQkJfTsNCg0KCQkJLyogRFZJIEkyQyBidXMgKi8NCgkJCXYybV9p
MmNfZHZpOiBpMmNAMTYwMDAwIHsNCgkJCQljb21wYXRpYmxlID0gImFybSx2ZXJzYXRpbGUtaTJj
IjsNCgkJCQlyZWcgPSA8MHgxNjAwMDAgMHgxMDAwPjsNCg0KCQkJCSNhZGRyZXNzLWNlbGxzID0g
PDE+Ow0KCQkJCSNzaXplLWNlbGxzID0gPDA+Ow0KDQoJCQkJZHZpLXRyYW5zbWl0dGVyQDM5IHsN
CgkJCQkJY29tcGF0aWJsZSA9ICJzaWwsc2lpOTAyMi10cGkiLCAic2lsLHNpaTkwMjIiOw0KCQkJ
CQlyZWcgPSA8MHgzOT47DQoJCQkJfTsNCg0KCQkJCWR2aS10cmFuc21pdHRlckA2MCB7DQoJCQkJ
CWNvbXBhdGlibGUgPSAic2lsLHNpaTkwMjItY3BpIiwgInNpbCxzaWk5MDIyIjsNCgkJCQkJcmVn
ID0gPDB4NjA+Ow0KCQkJCX07DQoJCQl9Ow0KDQoJCQlydGNAMTcwMDAwIHsNCgkJCQljb21wYXRp
YmxlID0gImFybSxwbDAzMSIsICJhcm0scHJpbWVjZWxsIjsNCgkJCQlyZWcgPSA8MHgxNzAwMDAg
MHgxMDAwPjsNCgkJCQlpbnRlcnJ1cHRzID0gPDQ+Ow0KCQkJfTsNCg0KCQkJY29tcGFjdC1mbGFz
aEAxYTAwMDAgew0KCQkJCWNvbXBhdGlibGUgPSAiYXJtLHZleHByZXNzLWNmIiwgImF0YS1nZW5l
cmljIjsNCgkJCQlyZWcgPSA8MHgxYTAwMDAgMHgxMDANCgkJCQkgICAgICAgMHgxYTAxMDAgMHhm
MDA+Ow0KCQkJCXJlZy1zaGlmdCA9IDwyPjsNCgkJCX07DQoNCgkJCWNsY2RAMWYwMDAwIHsNCgkJ
CQljb21wYXRpYmxlID0gImFybSxwbDExMSIsICJhcm0scHJpbWVjZWxsIjsNCgkJCQlyZWcgPSA8
MHgxZjAwMDAgMHgxMDAwPjsNCgkJCQlpbnRlcnJ1cHRzID0gPDE0PjsNCgkJCX07DQoJCX07DQoN
CgkJdjJtX2ZpeGVkXzN2MzogZml4ZWRyZWd1bGF0b3JAMCB7DQoJCQljb21wYXRpYmxlID0gInJl
Z3VsYXRvci1maXhlZCI7DQoJCQlyZWd1bGF0b3ItbmFtZSA9ICIzVjMiOw0KCQkJcmVndWxhdG9y
LW1pbi1taWNyb3ZvbHQgPSA8MzMwMDAwMD47DQoJCQlyZWd1bGF0b3ItbWF4LW1pY3Jvdm9sdCA9
IDwzMzAwMDAwPjsNCgkJCXJlZ3VsYXRvci1hbHdheXMtb247DQoJCX07DQoJfTsNCn07DQo=

--_004_alpineDEB202120914114515029232kaballukxensourcecom_
Content-Type: text/plain; name="vexpress-v2p-ca15-tc1.dts"
Content-Transfer-Encoding: BASE64
Content-ID: <alpine.DEB.2.02.1209141210431.29232@kaball.uk.xensource.com>
Content-Description: vexpress-v2p-ca15-tc1.dts
Content-Disposition: attachment; filename="vexpress-v2p-ca15-tc1.dts";
	size=3264; creation-date="Fri, 14 Sep 2012 11:13:42 GMT";
	modification-date="Fri, 14 Sep 2012 11:13:42 GMT"

LyoNCiAqIEFSTSBMdGQuIFZlcnNhdGlsZSBFeHByZXNzDQogKg0KICogQ29yZVRpbGUgRXhwcmVz
cyBBMTV4MiAodmVyc2lvbiB3aXRoIFRlc3QgQ2hpcCAxKQ0KICogQ29ydGV4LUExNSBNUENvcmUg
KFYyUC1DQTE1KQ0KICoNCiAqIEhCSS0wMjM3QQ0KICovDQoNCi9kdHMtdjEvOw0KDQovIHsNCglt
b2RlbCA9ICJWMlAtQ0ExNSI7DQoJYXJtLGhiaSA9IDwweDIzNz47DQoJY29tcGF0aWJsZSA9ICJh
cm0sdmV4cHJlc3MsdjJwLWNhMTUsdGMxIiwgImFybSx2ZXhwcmVzcyx2MnAtY2ExNSIsICJhcm0s
dmV4cHJlc3MiOw0KCWludGVycnVwdC1wYXJlbnQgPSA8JmdpYz47DQoJI2FkZHJlc3MtY2VsbHMg
PSA8Mj47DQoJI3NpemUtY2VsbHMgPSA8Mj47DQoNCgljaG9zZW4gew0KICAgICAgICAgICAgICAg
ICBib290YXJncyA9ICJkb20wX21lbT0xMjhNIjsNCiAgICAgICAgICAgICAgICAgeGVuLGRvbTAt
Ym9vdGFyZ3MgPSAiZWFybHlwcmludGsgY29uc29sZT10dHlBTUExIHJvb3Q9L2Rldi9tbWNibGsw
IGRlYnVnIHJ3IjsNCgl9Ow0KDQoJYWxpYXNlcyB7DQoJCXNlcmlhbDAgPSAmdjJtX3NlcmlhbDA7
DQoJCXNlcmlhbDEgPSAmdjJtX3NlcmlhbDE7DQoJCXNlcmlhbDIgPSAmdjJtX3NlcmlhbDI7DQoJ
CXNlcmlhbDMgPSAmdjJtX3NlcmlhbDM7DQoJCWkyYzAgPSAmdjJtX2kyY19kdmk7DQoJCWkyYzEg
PSAmdjJtX2kyY19wY2llOw0KCX07DQoNCgljcHVzIHsNCgkJI2FkZHJlc3MtY2VsbHMgPSA8MT47
DQoJCSNzaXplLWNlbGxzID0gPDA+Ow0KDQoJCWNwdUAwIHsNCgkJCWRldmljZV90eXBlID0gImNw
dSI7DQoJCQljb21wYXRpYmxlID0gImFybSxjb3J0ZXgtYTE1IjsNCgkJCXJlZyA9IDwwPjsNCgkJ
fTsNCgl9Ow0KDQoJbWVtb3J5QDgwMDAwMDAwIHsNCgkJZGV2aWNlX3R5cGUgPSAibWVtb3J5IjsN
CgkJcmVnID0gPDAgMHg4MDAwMDAwMCAwIDB4ODAwMDAwMDA+Ow0KCX07DQoNCglnaWM6IGludGVy
cnVwdC1jb250cm9sbGVyQDJjMDAxMDAwIHsNCgkJY29tcGF0aWJsZSA9ICJhcm0sY29ydGV4LWEx
NS1naWMiLCAiYXJtLGNvcnRleC1hOS1naWMiOw0KCQkjaW50ZXJydXB0LWNlbGxzID0gPDM+Ow0K
CQkjYWRkcmVzcy1jZWxscyA9IDwwPjsNCgkJaW50ZXJydXB0LWNvbnRyb2xsZXI7DQoJCXJlZyA9
IDwwIDB4MmMwMDEwMDAgMCAweDEwMDA+LA0KCQkgICAgICA8MCAweDJjMDAyMDAwIDAgMHgxMDAw
PiwNCgkJICAgICAgPDAgMHgyYzAwNDAwMCAwIDB4MjAwMD4sDQoJCSAgICAgIDwwIDB4MmMwMDYw
MDAgMCAweDIwMDA+Ow0KCQlpbnRlcnJ1cHRzID0gPDEgOSAweGYwND47DQoJfTsNCg0KCXRpbWVy
IHsNCgkJY29tcGF0aWJsZSA9ICJhcm0sYXJtdjctdGltZXIiOw0KCQlpbnRlcnJ1cHRzID0gPDEg
MTMgMHhmMDg+LA0KCQkJICAgICA8MSAxNCAweGYwOD4sDQoJCQkgICAgIDwxIDExIDB4ZjA4PiwN
CgkJCSAgICAgPDEgMTAgMHhmMDg+Ow0KCX07DQoNCglwbXUgew0KCQljb21wYXRpYmxlID0gImFy
bSxjb3J0ZXgtYTE1LXBtdSIsICJhcm0sY29ydGV4LWE5LXBtdSI7DQoJCWludGVycnVwdHMgPSA8
MCA2OCA0PiwNCgkJCSAgICAgPDAgNjkgND47DQoJfTsNCg0KCWh5cGVydmlzb3Igew0KCQljb21w
YXRpYmxlID0gInhlbix4ZW4tNC4yIiwgInhlbix4ZW4iOw0KCQlyZWcgPSA8MCAweGIwMDAwMDAw
IDAgMHgyMDAwMD47DQoJCWludGVycnVwdHMgPSA8MSAxNSAweGYwOD47DQoJfTsNCg0KCW1vdGhl
cmJvYXJkIHsNCgkJcmFuZ2VzID0gPDAgMCAwIDB4MDgwMDAwMDAgMHgwNDAwMDAwMD4sDQoJCQkg
PDEgMCAwIDB4MTQwMDAwMDAgMHgwNDAwMDAwMD4sDQoJCQkgPDIgMCAwIDB4MTgwMDAwMDAgMHgw
NDAwMDAwMD4sDQoJCQkgPDMgMCAwIDB4MWMwMDAwMDAgMHgwNDAwMDAwMD4sDQoJCQkgPDQgMCAw
IDB4MGMwMDAwMDAgMHgwNDAwMDAwMD4sDQoJCQkgPDUgMCAwIDB4MTAwMDAwMDAgMHgwNDAwMDAw
MD47DQoNCgkJaW50ZXJydXB0LW1hcC1tYXNrID0gPDAgMCA2Mz47DQoJCWludGVycnVwdC1tYXAg
PSA8MCAwICAwICZnaWMgMCAgMCA0PiwNCgkJCQk8MCAwICAxICZnaWMgMCAgMSA0PiwNCgkJCQk8
MCAwICAyICZnaWMgMCAgMiA0PiwNCgkJCQk8MCAwICAzICZnaWMgMCAgMyA0PiwNCgkJCQk8MCAw
ICA0ICZnaWMgMCAgNCA0PiwNCgkJCQk8MCAwICA1ICZnaWMgMCAgNSA0PiwNCgkJCQk8MCAwICA2
ICZnaWMgMCAgNiA0PiwNCgkJCQk8MCAwICA3ICZnaWMgMCAgNyA0PiwNCgkJCQk8MCAwICA4ICZn
aWMgMCAgOCA0PiwNCgkJCQk8MCAwICA5ICZnaWMgMCAgOSA0PiwNCgkJCQk8MCAwIDEwICZnaWMg
MCAxMCA0PiwNCgkJCQk8MCAwIDExICZnaWMgMCAxMSA0PiwNCgkJCQk8MCAwIDEyICZnaWMgMCAx
MiA0PiwNCgkJCQk8MCAwIDEzICZnaWMgMCAxMyA0PiwNCgkJCQk8MCAwIDE0ICZnaWMgMCAxNCA0
PiwNCgkJCQk8MCAwIDE1ICZnaWMgMCAxNSA0PiwNCgkJCQk8MCAwIDE2ICZnaWMgMCAxNiA0PiwN
CgkJCQk8MCAwIDE3ICZnaWMgMCAxNyA0PiwNCgkJCQk8MCAwIDE4ICZnaWMgMCAxOCA0PiwNCgkJ
CQk8MCAwIDE5ICZnaWMgMCAxOSA0PiwNCgkJCQk8MCAwIDIwICZnaWMgMCAyMCA0PiwNCgkJCQk8
MCAwIDIxICZnaWMgMCAyMSA0PiwNCgkJCQk8MCAwIDIyICZnaWMgMCAyMiA0PiwNCgkJCQk8MCAw
IDIzICZnaWMgMCAyMyA0PiwNCgkJCQk8MCAwIDI0ICZnaWMgMCAyNCA0PiwNCgkJCQk8MCAwIDI1
ICZnaWMgMCAyNSA0PiwNCgkJCQk8MCAwIDI2ICZnaWMgMCAyNiA0PiwNCgkJCQk8MCAwIDI3ICZn
aWMgMCAyNyA0PiwNCgkJCQk8MCAwIDI4ICZnaWMgMCAyOCA0PiwNCgkJCQk8MCAwIDI5ICZnaWMg
MCAyOSA0PiwNCgkJCQk8MCAwIDMwICZnaWMgMCAzMCA0PiwNCgkJCQk8MCAwIDMxICZnaWMgMCAz
MSA0PiwNCgkJCQk8MCAwIDMyICZnaWMgMCAzMiA0PiwNCgkJCQk8MCAwIDMzICZnaWMgMCAzMyA0
PiwNCgkJCQk8MCAwIDM0ICZnaWMgMCAzNCA0PiwNCgkJCQk8MCAwIDM1ICZnaWMgMCAzNSA0PiwN
CgkJCQk8MCAwIDM2ICZnaWMgMCAzNiA0PiwNCgkJCQk8MCAwIDM3ICZnaWMgMCAzNyA0PiwNCgkJ
CQk8MCAwIDM4ICZnaWMgMCAzOCA0PiwNCgkJCQk8MCAwIDM5ICZnaWMgMCAzOSA0PiwNCgkJCQk8
MCAwIDQwICZnaWMgMCA0MCA0PiwNCgkJCQk8MCAwIDQxICZnaWMgMCA0MSA0PiwNCgkJCQk8MCAw
IDQyICZnaWMgMCA0MiA0PjsNCgl9Ow0KfTsNCg0KL2luY2x1ZGUvICJ2ZXhwcmVzcy12Mm0tcnMx
LmR0c2kiDQo=

--_004_alpineDEB202120914114515029232kaballukxensourcecom_
Content-Type: text/plain; name="vexpress-virt.dts"
Content-Transfer-Encoding: BASE64
Content-ID: <alpine.DEB.2.02.1209141210432.29232@kaball.uk.xensource.com>
Content-Description: vexpress-virt.dts
Content-Disposition: attachment; filename="vexpress-virt.dts"; size=2729;
	creation-date="Fri, 14 Sep 2012 11:13:42 GMT";
	modification-date="Fri, 14 Sep 2012 11:13:42 GMT"

LyoNCiAqIEFSTSBMdGQuIFZlcnNhdGlsZSBFeHByZXNzDQogKg0KICogQVJNIEVudmVsb3BlIE1v
ZGVsIHY3QSAoc2luZ2xlIENQVSkuDQogKi8NCg0KL2R0cy12MS87DQoNCi9pbmNsdWRlLyAic2tl
bGV0b24uZHRzaSINCg0KLyB7DQoJbW9kZWwgPSAiVjJQLUFFTXY3QSI7DQoJY29tcGF0aWJsZSA9
ICJhcm0sdmV4cHJlc3MsdjJwLWFlbSx2N2EiLCAiYXJtLHZleHByZXNzLHYycC1hZW0iLCAiYXJt
LHZleHByZXNzIjsNCglpbnRlcnJ1cHQtcGFyZW50ID0gPCZnaWM+Ow0KDQogICAgICAgIGNob3Nl
biB7DQogICAgICAgICAgICAgICAgYm9vdGFyZ3MgPSAiZWFybHlwcmludGsgZGVidWcgbG9nbGV2
ZWw9OSBjb25zb2xlPWh2YzAgcm9vdD0vZGV2L3h2ZGEgaW5pdD0vc2Jpbi9pbml0IjsNCiAgICAg
ICAgfTsNCg0KCWNwdXMgew0KCQkjYWRkcmVzcy1jZWxscyA9IDwxPjsNCgkJI3NpemUtY2VsbHMg
PSA8MD47DQoNCgkJY3B1QDAgew0KCQkJZGV2aWNlX3R5cGUgPSAiY3B1IjsNCgkJCWNvbXBhdGli
bGUgPSAiYXJtLGNvcnRleC1hMTUiOw0KCQkJcmVnID0gPDA+Ow0KCQl9Ow0KCX07DQoNCgltZW1v
cnkgew0KCQlkZXZpY2VfdHlwZSA9ICJtZW1vcnkiOw0KCQlyZWcgPSA8MHg4MDAwMDAwMCAweDA4
MDAwMDAwPjsNCgl9Ow0KDQoJZ2ljOiBpbnRlcnJ1cHQtY29udHJvbGxlckAyYzAwMTAwMCB7DQoJ
CWNvbXBhdGlibGUgPSAiYXJtLGNvcnRleC1hOS1naWMiOw0KCQkjaW50ZXJydXB0LWNlbGxzID0g
PDM+Ow0KCQkjYWRkcmVzcy1jZWxscyA9IDwwPjsNCgkJaW50ZXJydXB0LWNvbnRyb2xsZXI7DQoJ
CXJlZyA9IDwweDJjMDAxMDAwIDB4MTAwMD4sDQoJCSAgICAgIDwweDJjMDAyMDAwIDB4MTAwPjsN
Cgl9Ow0KDQoJdGltZXIgew0KCQljb21wYXRpYmxlID0gImFybSxhcm12Ny10aW1lciI7DQoJCWlu
dGVycnVwdHMgPSA8MSAxMyAweGYwOD4sDQoJCQkgICAgIDwxIDE0IDB4ZjA4PiwNCgkJCSAgICAg
PDEgMTEgMHhmMDg+LA0KCQkJICAgICA8MSAxMCAweGYwOD47DQoJfTsNCg0KCWh5cGVydmlzb3Ig
ew0KCQljb21wYXRpYmxlID0gInhlbix4ZW4tNC4yIiwgInhlbix4ZW4iOw0KCQlyZWcgPSA8MHhi
MDAwMDAwMCAweDIwMDAwPjsNCgkJaW50ZXJydXB0cyA9IDwxIDE1IDB4ZjA4PjsNCgl9Ow0KDQoJ
bW90aGVyYm9hcmQgew0KCQlhcm0sdjJtLW1lbW9yeS1tYXAgPSAicnMxIjsNCgkJcmFuZ2VzID0g
PDAgMCAweDA4MDAwMDAwIDB4MDQwMDAwMDA+LA0KCQkJIDwxIDAgMHgxNDAwMDAwMCAweDA0MDAw
MDAwPiwNCgkJCSA8MiAwIDB4MTgwMDAwMDAgMHgwNDAwMDAwMD4sDQoJCQkgPDMgMCAweDFjMDAw
MDAwIDB4MDQwMDAwMDA+LA0KCQkJIDw0IDAgMHgwYzAwMDAwMCAweDA0MDAwMDAwPiwNCgkJCSA8
NSAwIDB4MTAwMDAwMDAgMHgwNDAwMDAwMD47DQoNCgkJaW50ZXJydXB0LW1hcC1tYXNrID0gPDAg
MCA2Mz47DQoJCWludGVycnVwdC1tYXAgPSA8MCAwICAwICZnaWMgMCAgMCA0PiwNCgkJCQk8MCAw
ICAxICZnaWMgMCAgMSA0PiwNCgkJCQk8MCAwICAyICZnaWMgMCAgMiA0PiwNCgkJCQk8MCAwICAz
ICZnaWMgMCAgMyA0PiwNCgkJCQk8MCAwICA0ICZnaWMgMCAgNCA0PiwNCgkJCQk8MCAwICA1ICZn
aWMgMCAgNSA0PiwNCgkJCQk8MCAwICA2ICZnaWMgMCAgNiA0PiwNCgkJCQk8MCAwICA3ICZnaWMg
MCAgNyA0PiwNCgkJCQk8MCAwICA4ICZnaWMgMCAgOCA0PiwNCgkJCQk8MCAwICA5ICZnaWMgMCAg
OSA0PiwNCgkJCQk8MCAwIDEwICZnaWMgMCAxMCA0PiwNCgkJCQk8MCAwIDExICZnaWMgMCAxMSA0
PiwNCgkJCQk8MCAwIDEyICZnaWMgMCAxMiA0PiwNCgkJCQk8MCAwIDEzICZnaWMgMCAxMyA0PiwN
CgkJCQk8MCAwIDE0ICZnaWMgMCAxNCA0PiwNCgkJCQk8MCAwIDE1ICZnaWMgMCAxNSA0PiwNCgkJ
CQk8MCAwIDE2ICZnaWMgMCAxNiA0PiwNCgkJCQk8MCAwIDE3ICZnaWMgMCAxNyA0PiwNCgkJCQk8
MCAwIDE4ICZnaWMgMCAxOCA0PiwNCgkJCQk8MCAwIDE5ICZnaWMgMCAxOSA0PiwNCgkJCQk8MCAw
IDIwICZnaWMgMCAyMCA0PiwNCgkJCQk8MCAwIDIxICZnaWMgMCAyMSA0PiwNCgkJCQk8MCAwIDIy
ICZnaWMgMCAyMiA0PiwNCgkJCQk8MCAwIDIzICZnaWMgMCAyMyA0PiwNCgkJCQk8MCAwIDI0ICZn
aWMgMCAyNCA0PiwNCgkJCQk8MCAwIDI1ICZnaWMgMCAyNSA0PiwNCgkJCQk8MCAwIDI2ICZnaWMg
MCAyNiA0PiwNCgkJCQk8MCAwIDI3ICZnaWMgMCAyNyA0PiwNCgkJCQk8MCAwIDI4ICZnaWMgMCAy
OCA0PiwNCgkJCQk8MCAwIDI5ICZnaWMgMCAyOSA0PiwNCgkJCQk8MCAwIDMwICZnaWMgMCAzMCA0
PiwNCgkJCQk8MCAwIDMxICZnaWMgMCAzMSA0PiwNCgkJCQk8MCAwIDMyICZnaWMgMCAzMiA0PiwN
CgkJCQk8MCAwIDMzICZnaWMgMCAzMyA0PiwNCgkJCQk8MCAwIDM0ICZnaWMgMCAzNCA0PiwNCgkJ
CQk8MCAwIDM1ICZnaWMgMCAzNSA0PiwNCgkJCQk8MCAwIDM2ICZnaWMgMCAzNiA0PiwNCgkJCQk8
MCAwIDM3ICZnaWMgMCAzNyA0PiwNCgkJCQk8MCAwIDM4ICZnaWMgMCAzOCA0PiwNCgkJCQk8MCAw
IDM5ICZnaWMgMCAzOSA0PiwNCgkJCQk8MCAwIDQwICZnaWMgMCA0MCA0PiwNCgkJCQk8MCAwIDQx
ICZnaWMgMCA0MSA0PiwNCgkJCQk8MCAwIDQyICZnaWMgMCA0MiA0PjsNCgl9Ow0KfTsNCg0KLyog
L2luY2x1ZGUvICJ2ZXhwcmVzcy12Mm0tcnMxLXJ0c20uZHRzaSIgKi8NCg==

--_004_alpineDEB202120914114515029232kaballukxensourcecom_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--_004_alpineDEB202120914114515029232kaballukxensourcecom_--


From xen-devel-bounces@lists.xen.org Mon Sep 17 17:40:19 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 17: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 1TDfIk-0001kP-Bt; Mon, 17 Sep 2012 17:40:06 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1TDfIi-0001jU-7n
	for xen-devel@lists.xensource.com; Mon, 17 Sep 2012 17:40:04 +0000
Received: from [85.158.138.51:28315] by server-8.bemta-3.messagelabs.com id
	5C/C9-24700-37067505; Mon, 17 Sep 2012 17:40:03 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1347903600!29127338!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNzUxNjg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32009 invoked from network); 17 Sep 2012 17:40:02 -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;
	17 Sep 2012 17:40:02 -0000
X-IronPort-AV: E=Sophos;i="4.80,437,1344211200"; d="scan'208";a="208319293"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Sep 2012 17:39:40 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Mon, 17 Sep 2012 13:39:39 -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 1TDfIE-0008AT-PJ;
	Mon, 17 Sep 2012 18:39:34 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: <arnd@arndb.de>
Date: Mon, 17 Sep 2012 18:38:48 +0100
Message-ID: <1347903543-2135-2-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <alpine.DEB.2.02.1209171215490.29232@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1209171215490.29232@kaball.uk.xensource.com>
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com, linaro-dev@lists.linaro.org,
	Ian.Campbell@citrix.com, konrad.wilk@oracle.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	tim@xen.org, linux-kernel@vger.kernel.org,
	linux@arm.linux.org.uk, linux-arm-kernel@lists.infradead.org
Subject: [Xen-devel] [PATCH v5 02/17] xen/arm: hypercalls
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Use r12 to pass the hypercall number to the hypervisor.

We need a register to pass the hypercall number because we might not
know it at compile time and HVC only takes an immediate argument.

Among the available registers r12 seems to be the best choice because it
is defined as "intra-procedure call scratch register".

Use the ISS to pass an hypervisor specific tag.


Changes in v2:
- define an HYPERCALL macro for 5 arguments hypercall wrappers, even if
at the moment is unused;
- use ldm instead of pop;
- fix up comments.


Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 arch/arm/include/asm/xen/hypercall.h |   50 ++++++++++++++++
 arch/arm/xen/Makefile                |    2 +-
 arch/arm/xen/hypercall.S             |  106 ++++++++++++++++++++++++++++++++++
 3 files changed, 157 insertions(+), 1 deletions(-)
 create mode 100644 arch/arm/include/asm/xen/hypercall.h
 create mode 100644 arch/arm/xen/hypercall.S

diff --git a/arch/arm/include/asm/xen/hypercall.h b/arch/arm/include/asm/xen/hypercall.h
new file mode 100644
index 0000000..4ac0624
--- /dev/null
+++ b/arch/arm/include/asm/xen/hypercall.h
@@ -0,0 +1,50 @@
+/******************************************************************************
+ * hypercall.h
+ *
+ * Linux-specific hypervisor handling.
+ *
+ * Stefano Stabellini <stefano.stabellini@eu.citrix.com>, Citrix, 2012
+ *
+ * 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.
+ */
+
+#ifndef _ASM_ARM_XEN_HYPERCALL_H
+#define _ASM_ARM_XEN_HYPERCALL_H
+
+#include <xen/interface/xen.h>
+
+long privcmd_call(unsigned call, unsigned long a1,
+		unsigned long a2, unsigned long a3,
+		unsigned long a4, unsigned long a5);
+int HYPERVISOR_xen_version(int cmd, void *arg);
+int HYPERVISOR_console_io(int cmd, int count, char *str);
+int HYPERVISOR_grant_table_op(unsigned int cmd, void *uop, unsigned int count);
+int HYPERVISOR_sched_op(int cmd, void *arg);
+int HYPERVISOR_event_channel_op(int cmd, void *arg);
+unsigned long HYPERVISOR_hvm_op(int op, void *arg);
+int HYPERVISOR_memory_op(unsigned int cmd, void *arg);
+int HYPERVISOR_physdev_op(int cmd, void *arg);
+
+#endif /* _ASM_ARM_XEN_HYPERCALL_H */
diff --git a/arch/arm/xen/Makefile b/arch/arm/xen/Makefile
index 0bad594..b9d6acc 100644
--- a/arch/arm/xen/Makefile
+++ b/arch/arm/xen/Makefile
@@ -1 +1 @@
-obj-y		:= enlighten.o
+obj-y		:= enlighten.o hypercall.o
diff --git a/arch/arm/xen/hypercall.S b/arch/arm/xen/hypercall.S
new file mode 100644
index 0000000..074f5ed
--- /dev/null
+++ b/arch/arm/xen/hypercall.S
@@ -0,0 +1,106 @@
+/******************************************************************************
+ * hypercall.S
+ *
+ * Xen hypercall wrappers
+ *
+ * Stefano Stabellini <stefano.stabellini@eu.citrix.com>, Citrix, 2012
+ *
+ * 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.
+ */
+
+/*
+ * The Xen hypercall calling convention is very similar to the ARM
+ * procedure calling convention: the first paramter is passed in r0, the
+ * second in r1, the third in r2 and the fourth in r3. Considering that
+ * Xen hypercalls have 5 arguments at most, the fifth paramter is passed
+ * in r4, differently from the procedure calling convention of using the
+ * stack for that case.
+ *
+ * The hypercall number is passed in r12.
+ *
+ * The return value is in r0.
+ *
+ * The hvc ISS is required to be 0xEA1, that is the Xen specific ARM
+ * hypercall tag.
+ */
+
+#include <linux/linkage.h>
+#include <asm/assembler.h>
+#include <xen/interface/xen.h>
+
+
+/* HVC 0xEA1 */
+#ifdef CONFIG_THUMB2_KERNEL
+#define xen_hvc .word 0xf7e08ea1
+#else
+#define xen_hvc .word 0xe140ea71
+#endif
+
+#define HYPERCALL_SIMPLE(hypercall)		\
+ENTRY(HYPERVISOR_##hypercall)			\
+	mov r12, #__HYPERVISOR_##hypercall;	\
+	xen_hvc;							\
+	mov pc, lr;							\
+ENDPROC(HYPERVISOR_##hypercall)
+
+#define HYPERCALL0 HYPERCALL_SIMPLE
+#define HYPERCALL1 HYPERCALL_SIMPLE
+#define HYPERCALL2 HYPERCALL_SIMPLE
+#define HYPERCALL3 HYPERCALL_SIMPLE
+#define HYPERCALL4 HYPERCALL_SIMPLE
+
+#define HYPERCALL5(hypercall)			\
+ENTRY(HYPERVISOR_##hypercall)			\
+	stmdb sp!, {r4}						\
+	ldr r4, [sp, #4]					\
+	mov r12, #__HYPERVISOR_##hypercall;	\
+	xen_hvc								\
+	ldm sp!, {r4}						\
+	mov pc, lr							\
+ENDPROC(HYPERVISOR_##hypercall)
+
+                .text
+
+HYPERCALL2(xen_version);
+HYPERCALL3(console_io);
+HYPERCALL3(grant_table_op);
+HYPERCALL2(sched_op);
+HYPERCALL2(event_channel_op);
+HYPERCALL2(hvm_op);
+HYPERCALL2(memory_op);
+HYPERCALL2(physdev_op);
+
+ENTRY(privcmd_call)
+	stmdb sp!, {r4}
+	mov r12, r0
+	mov r0, r1
+	mov r1, r2
+	mov r2, r3
+	ldr r3, [sp, #8]
+	ldr r4, [sp, #4]
+	xen_hvc
+	ldm sp!, {r4}
+	mov pc, lr
+ENDPROC(privcmd_call);
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 17 17:40:19 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 17: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 1TDfIk-0001kP-Bt; Mon, 17 Sep 2012 17:40:06 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1TDfIi-0001jU-7n
	for xen-devel@lists.xensource.com; Mon, 17 Sep 2012 17:40:04 +0000
Received: from [85.158.138.51:28315] by server-8.bemta-3.messagelabs.com id
	5C/C9-24700-37067505; Mon, 17 Sep 2012 17:40:03 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1347903600!29127338!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNzUxNjg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32009 invoked from network); 17 Sep 2012 17:40:02 -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;
	17 Sep 2012 17:40:02 -0000
X-IronPort-AV: E=Sophos;i="4.80,437,1344211200"; d="scan'208";a="208319293"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Sep 2012 17:39:40 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Mon, 17 Sep 2012 13:39:39 -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 1TDfIE-0008AT-PJ;
	Mon, 17 Sep 2012 18:39:34 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: <arnd@arndb.de>
Date: Mon, 17 Sep 2012 18:38:48 +0100
Message-ID: <1347903543-2135-2-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <alpine.DEB.2.02.1209171215490.29232@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1209171215490.29232@kaball.uk.xensource.com>
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com, linaro-dev@lists.linaro.org,
	Ian.Campbell@citrix.com, konrad.wilk@oracle.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	tim@xen.org, linux-kernel@vger.kernel.org,
	linux@arm.linux.org.uk, linux-arm-kernel@lists.infradead.org
Subject: [Xen-devel] [PATCH v5 02/17] xen/arm: hypercalls
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Use r12 to pass the hypercall number to the hypervisor.

We need a register to pass the hypercall number because we might not
know it at compile time and HVC only takes an immediate argument.

Among the available registers r12 seems to be the best choice because it
is defined as "intra-procedure call scratch register".

Use the ISS to pass an hypervisor specific tag.


Changes in v2:
- define an HYPERCALL macro for 5 arguments hypercall wrappers, even if
at the moment is unused;
- use ldm instead of pop;
- fix up comments.


Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 arch/arm/include/asm/xen/hypercall.h |   50 ++++++++++++++++
 arch/arm/xen/Makefile                |    2 +-
 arch/arm/xen/hypercall.S             |  106 ++++++++++++++++++++++++++++++++++
 3 files changed, 157 insertions(+), 1 deletions(-)
 create mode 100644 arch/arm/include/asm/xen/hypercall.h
 create mode 100644 arch/arm/xen/hypercall.S

diff --git a/arch/arm/include/asm/xen/hypercall.h b/arch/arm/include/asm/xen/hypercall.h
new file mode 100644
index 0000000..4ac0624
--- /dev/null
+++ b/arch/arm/include/asm/xen/hypercall.h
@@ -0,0 +1,50 @@
+/******************************************************************************
+ * hypercall.h
+ *
+ * Linux-specific hypervisor handling.
+ *
+ * Stefano Stabellini <stefano.stabellini@eu.citrix.com>, Citrix, 2012
+ *
+ * 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.
+ */
+
+#ifndef _ASM_ARM_XEN_HYPERCALL_H
+#define _ASM_ARM_XEN_HYPERCALL_H
+
+#include <xen/interface/xen.h>
+
+long privcmd_call(unsigned call, unsigned long a1,
+		unsigned long a2, unsigned long a3,
+		unsigned long a4, unsigned long a5);
+int HYPERVISOR_xen_version(int cmd, void *arg);
+int HYPERVISOR_console_io(int cmd, int count, char *str);
+int HYPERVISOR_grant_table_op(unsigned int cmd, void *uop, unsigned int count);
+int HYPERVISOR_sched_op(int cmd, void *arg);
+int HYPERVISOR_event_channel_op(int cmd, void *arg);
+unsigned long HYPERVISOR_hvm_op(int op, void *arg);
+int HYPERVISOR_memory_op(unsigned int cmd, void *arg);
+int HYPERVISOR_physdev_op(int cmd, void *arg);
+
+#endif /* _ASM_ARM_XEN_HYPERCALL_H */
diff --git a/arch/arm/xen/Makefile b/arch/arm/xen/Makefile
index 0bad594..b9d6acc 100644
--- a/arch/arm/xen/Makefile
+++ b/arch/arm/xen/Makefile
@@ -1 +1 @@
-obj-y		:= enlighten.o
+obj-y		:= enlighten.o hypercall.o
diff --git a/arch/arm/xen/hypercall.S b/arch/arm/xen/hypercall.S
new file mode 100644
index 0000000..074f5ed
--- /dev/null
+++ b/arch/arm/xen/hypercall.S
@@ -0,0 +1,106 @@
+/******************************************************************************
+ * hypercall.S
+ *
+ * Xen hypercall wrappers
+ *
+ * Stefano Stabellini <stefano.stabellini@eu.citrix.com>, Citrix, 2012
+ *
+ * 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.
+ */
+
+/*
+ * The Xen hypercall calling convention is very similar to the ARM
+ * procedure calling convention: the first paramter is passed in r0, the
+ * second in r1, the third in r2 and the fourth in r3. Considering that
+ * Xen hypercalls have 5 arguments at most, the fifth paramter is passed
+ * in r4, differently from the procedure calling convention of using the
+ * stack for that case.
+ *
+ * The hypercall number is passed in r12.
+ *
+ * The return value is in r0.
+ *
+ * The hvc ISS is required to be 0xEA1, that is the Xen specific ARM
+ * hypercall tag.
+ */
+
+#include <linux/linkage.h>
+#include <asm/assembler.h>
+#include <xen/interface/xen.h>
+
+
+/* HVC 0xEA1 */
+#ifdef CONFIG_THUMB2_KERNEL
+#define xen_hvc .word 0xf7e08ea1
+#else
+#define xen_hvc .word 0xe140ea71
+#endif
+
+#define HYPERCALL_SIMPLE(hypercall)		\
+ENTRY(HYPERVISOR_##hypercall)			\
+	mov r12, #__HYPERVISOR_##hypercall;	\
+	xen_hvc;							\
+	mov pc, lr;							\
+ENDPROC(HYPERVISOR_##hypercall)
+
+#define HYPERCALL0 HYPERCALL_SIMPLE
+#define HYPERCALL1 HYPERCALL_SIMPLE
+#define HYPERCALL2 HYPERCALL_SIMPLE
+#define HYPERCALL3 HYPERCALL_SIMPLE
+#define HYPERCALL4 HYPERCALL_SIMPLE
+
+#define HYPERCALL5(hypercall)			\
+ENTRY(HYPERVISOR_##hypercall)			\
+	stmdb sp!, {r4}						\
+	ldr r4, [sp, #4]					\
+	mov r12, #__HYPERVISOR_##hypercall;	\
+	xen_hvc								\
+	ldm sp!, {r4}						\
+	mov pc, lr							\
+ENDPROC(HYPERVISOR_##hypercall)
+
+                .text
+
+HYPERCALL2(xen_version);
+HYPERCALL3(console_io);
+HYPERCALL3(grant_table_op);
+HYPERCALL2(sched_op);
+HYPERCALL2(event_channel_op);
+HYPERCALL2(hvm_op);
+HYPERCALL2(memory_op);
+HYPERCALL2(physdev_op);
+
+ENTRY(privcmd_call)
+	stmdb sp!, {r4}
+	mov r12, r0
+	mov r0, r1
+	mov r1, r2
+	mov r2, r3
+	ldr r3, [sp, #8]
+	ldr r4, [sp, #4]
+	xen_hvc
+	ldm sp!, {r4}
+	mov pc, lr
+ENDPROC(privcmd_call);
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 17 17:40:19 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 17: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 1TDfIg-0001jH-Om; Mon, 17 Sep 2012 17:40:02 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1TDfIf-0001j2-9N
	for xen-devel@lists.xensource.com; Mon, 17 Sep 2012 17:40:01 +0000
Received: from [85.158.137.99:60147] by server-7.bemta-3.messagelabs.com id
	E4/83-32000-07067505; Mon, 17 Sep 2012 17:40:00 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-16.tower-217.messagelabs.com!1347903598!18037392!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNzUxNjg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 774 invoked from network); 17 Sep 2012 17:39:59 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-16.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Sep 2012 17:39:59 -0000
X-IronPort-AV: E=Sophos;i="4.80,437,1344211200"; d="scan'208";a="208319289"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Sep 2012 17:39:40 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Mon, 17 Sep 2012 13:39:39 -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 1TDfIE-0008AT-Pw;
	Mon, 17 Sep 2012 18:39:34 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: <arnd@arndb.de>
Date: Mon, 17 Sep 2012 18:38:49 +0100
Message-ID: <1347903543-2135-3-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <alpine.DEB.2.02.1209171215490.29232@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1209171215490.29232@kaball.uk.xensource.com>
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com, linaro-dev@lists.linaro.org,
	Ian.Campbell@citrix.com, konrad.wilk@oracle.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	tim@xen.org, linux-kernel@vger.kernel.org,
	linux@arm.linux.org.uk, linux-arm-kernel@lists.infradead.org
Subject: [Xen-devel] [PATCH v5 03/17] xen/arm: page.h 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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

ARM Xen guests always use paging in hardware, like PV on HVM guests in
the X86 world.

Changes in v3:

- improve comments.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 arch/arm/include/asm/xen/page.h |   82 +++++++++++++++++++++++++++++++++++++++
 1 files changed, 82 insertions(+), 0 deletions(-)
 create mode 100644 arch/arm/include/asm/xen/page.h

diff --git a/arch/arm/include/asm/xen/page.h b/arch/arm/include/asm/xen/page.h
new file mode 100644
index 0000000..1742023
--- /dev/null
+++ b/arch/arm/include/asm/xen/page.h
@@ -0,0 +1,82 @@
+#ifndef _ASM_ARM_XEN_PAGE_H
+#define _ASM_ARM_XEN_PAGE_H
+
+#include <asm/page.h>
+#include <asm/pgtable.h>
+
+#include <linux/pfn.h>
+#include <linux/types.h>
+
+#include <xen/interface/grant_table.h>
+
+#define pfn_to_mfn(pfn)			(pfn)
+#define phys_to_machine_mapping_valid	(1)
+#define mfn_to_pfn(mfn)			(mfn)
+#define mfn_to_virt(m)			(__va(mfn_to_pfn(m) << PAGE_SHIFT))
+
+#define pte_mfn	    pte_pfn
+#define mfn_pte	    pfn_pte
+
+/* Xen machine address */
+typedef struct xmaddr {
+	phys_addr_t maddr;
+} xmaddr_t;
+
+/* Xen pseudo-physical address */
+typedef struct xpaddr {
+	phys_addr_t paddr;
+} xpaddr_t;
+
+#define XMADDR(x)	((xmaddr_t) { .maddr = (x) })
+#define XPADDR(x)	((xpaddr_t) { .paddr = (x) })
+
+static inline xmaddr_t phys_to_machine(xpaddr_t phys)
+{
+	unsigned offset = phys.paddr & ~PAGE_MASK;
+	return XMADDR(PFN_PHYS(pfn_to_mfn(PFN_DOWN(phys.paddr))) | offset);
+}
+
+static inline xpaddr_t machine_to_phys(xmaddr_t machine)
+{
+	unsigned offset = machine.maddr & ~PAGE_MASK;
+	return XPADDR(PFN_PHYS(mfn_to_pfn(PFN_DOWN(machine.maddr))) | offset);
+}
+/* VIRT <-> MACHINE conversion */
+#define virt_to_machine(v)	(phys_to_machine(XPADDR(__pa(v))))
+#define virt_to_pfn(v)          (PFN_DOWN(__pa(v)))
+#define virt_to_mfn(v)		(pfn_to_mfn(virt_to_pfn(v)))
+#define mfn_to_virt(m)		(__va(mfn_to_pfn(m) << PAGE_SHIFT))
+
+static inline xmaddr_t arbitrary_virt_to_machine(void *vaddr)
+{
+	/* TODO: assuming it is mapped in the kernel 1:1 */
+	return virt_to_machine(vaddr);
+}
+
+/* TODO: this shouldn't be here but it is because the frontend drivers
+ * are using it (its rolled in headers) even though we won't hit the code path.
+ * So for right now just punt with this.
+ */
+static inline pte_t *lookup_address(unsigned long address, unsigned int *level)
+{
+	BUG();
+	return NULL;
+}
+
+static inline int m2p_add_override(unsigned long mfn, struct page *page,
+		struct gnttab_map_grant_ref *kmap_op)
+{
+	return 0;
+}
+
+static inline int m2p_remove_override(struct page *page, bool clear_pte)
+{
+	return 0;
+}
+
+static inline bool set_phys_to_machine(unsigned long pfn, unsigned long mfn)
+{
+	BUG();
+	return false;
+}
+#endif /* _ASM_ARM_XEN_PAGE_H */
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 17 17:40:19 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 17: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 1TDfIg-0001jH-Om; Mon, 17 Sep 2012 17:40:02 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1TDfIf-0001j2-9N
	for xen-devel@lists.xensource.com; Mon, 17 Sep 2012 17:40:01 +0000
Received: from [85.158.137.99:60147] by server-7.bemta-3.messagelabs.com id
	E4/83-32000-07067505; Mon, 17 Sep 2012 17:40:00 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-16.tower-217.messagelabs.com!1347903598!18037392!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNzUxNjg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 774 invoked from network); 17 Sep 2012 17:39:59 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-16.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Sep 2012 17:39:59 -0000
X-IronPort-AV: E=Sophos;i="4.80,437,1344211200"; d="scan'208";a="208319289"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Sep 2012 17:39:40 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Mon, 17 Sep 2012 13:39:39 -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 1TDfIE-0008AT-Pw;
	Mon, 17 Sep 2012 18:39:34 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: <arnd@arndb.de>
Date: Mon, 17 Sep 2012 18:38:49 +0100
Message-ID: <1347903543-2135-3-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <alpine.DEB.2.02.1209171215490.29232@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1209171215490.29232@kaball.uk.xensource.com>
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com, linaro-dev@lists.linaro.org,
	Ian.Campbell@citrix.com, konrad.wilk@oracle.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	tim@xen.org, linux-kernel@vger.kernel.org,
	linux@arm.linux.org.uk, linux-arm-kernel@lists.infradead.org
Subject: [Xen-devel] [PATCH v5 03/17] xen/arm: page.h 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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

ARM Xen guests always use paging in hardware, like PV on HVM guests in
the X86 world.

Changes in v3:

- improve comments.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 arch/arm/include/asm/xen/page.h |   82 +++++++++++++++++++++++++++++++++++++++
 1 files changed, 82 insertions(+), 0 deletions(-)
 create mode 100644 arch/arm/include/asm/xen/page.h

diff --git a/arch/arm/include/asm/xen/page.h b/arch/arm/include/asm/xen/page.h
new file mode 100644
index 0000000..1742023
--- /dev/null
+++ b/arch/arm/include/asm/xen/page.h
@@ -0,0 +1,82 @@
+#ifndef _ASM_ARM_XEN_PAGE_H
+#define _ASM_ARM_XEN_PAGE_H
+
+#include <asm/page.h>
+#include <asm/pgtable.h>
+
+#include <linux/pfn.h>
+#include <linux/types.h>
+
+#include <xen/interface/grant_table.h>
+
+#define pfn_to_mfn(pfn)			(pfn)
+#define phys_to_machine_mapping_valid	(1)
+#define mfn_to_pfn(mfn)			(mfn)
+#define mfn_to_virt(m)			(__va(mfn_to_pfn(m) << PAGE_SHIFT))
+
+#define pte_mfn	    pte_pfn
+#define mfn_pte	    pfn_pte
+
+/* Xen machine address */
+typedef struct xmaddr {
+	phys_addr_t maddr;
+} xmaddr_t;
+
+/* Xen pseudo-physical address */
+typedef struct xpaddr {
+	phys_addr_t paddr;
+} xpaddr_t;
+
+#define XMADDR(x)	((xmaddr_t) { .maddr = (x) })
+#define XPADDR(x)	((xpaddr_t) { .paddr = (x) })
+
+static inline xmaddr_t phys_to_machine(xpaddr_t phys)
+{
+	unsigned offset = phys.paddr & ~PAGE_MASK;
+	return XMADDR(PFN_PHYS(pfn_to_mfn(PFN_DOWN(phys.paddr))) | offset);
+}
+
+static inline xpaddr_t machine_to_phys(xmaddr_t machine)
+{
+	unsigned offset = machine.maddr & ~PAGE_MASK;
+	return XPADDR(PFN_PHYS(mfn_to_pfn(PFN_DOWN(machine.maddr))) | offset);
+}
+/* VIRT <-> MACHINE conversion */
+#define virt_to_machine(v)	(phys_to_machine(XPADDR(__pa(v))))
+#define virt_to_pfn(v)          (PFN_DOWN(__pa(v)))
+#define virt_to_mfn(v)		(pfn_to_mfn(virt_to_pfn(v)))
+#define mfn_to_virt(m)		(__va(mfn_to_pfn(m) << PAGE_SHIFT))
+
+static inline xmaddr_t arbitrary_virt_to_machine(void *vaddr)
+{
+	/* TODO: assuming it is mapped in the kernel 1:1 */
+	return virt_to_machine(vaddr);
+}
+
+/* TODO: this shouldn't be here but it is because the frontend drivers
+ * are using it (its rolled in headers) even though we won't hit the code path.
+ * So for right now just punt with this.
+ */
+static inline pte_t *lookup_address(unsigned long address, unsigned int *level)
+{
+	BUG();
+	return NULL;
+}
+
+static inline int m2p_add_override(unsigned long mfn, struct page *page,
+		struct gnttab_map_grant_ref *kmap_op)
+{
+	return 0;
+}
+
+static inline int m2p_remove_override(struct page *page, bool clear_pte)
+{
+	return 0;
+}
+
+static inline bool set_phys_to_machine(unsigned long pfn, unsigned long mfn)
+{
+	BUG();
+	return false;
+}
+#endif /* _ASM_ARM_XEN_PAGE_H */
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 17 17:40:20 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 17: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 1TDfIi-0001jp-HG; Mon, 17 Sep 2012 17:40:04 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1TDfIh-0001jN-O6
	for xen-devel@lists.xensource.com; Mon, 17 Sep 2012 17:40:04 +0000
Received: from [85.158.137.99:60216] by server-6.bemta-3.messagelabs.com id
	CC/2D-29694-27067505; Mon, 17 Sep 2012 17:40:02 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-16.tower-217.messagelabs.com!1347903598!18037392!3
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNzUxNjg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1274 invoked from network); 17 Sep 2012 17:40:01 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-16.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Sep 2012 17:40:01 -0000
X-IronPort-AV: E=Sophos;i="4.80,437,1344211200"; d="scan'208";a="208319291"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Sep 2012 17:39:40 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Mon, 17 Sep 2012 13:39:39 -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 1TDfIE-0008AT-Oc;
	Mon, 17 Sep 2012 18:39:34 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: <arnd@arndb.de>
Date: Mon, 17 Sep 2012 18:38:47 +0100
Message-ID: <1347903543-2135-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.1209171215490.29232@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1209171215490.29232@kaball.uk.xensource.com>
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com, linaro-dev@lists.linaro.org,
	Ian.Campbell@citrix.com, konrad.wilk@oracle.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	tim@xen.org, linux-kernel@vger.kernel.org,
	linux@arm.linux.org.uk, linux-arm-kernel@lists.infradead.org
Subject: [Xen-devel] [PATCH v5 01/17] arm: initial Xen 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

- Basic hypervisor.h and interface.h definitions.
- Skeleton enlighten.c, set xen_start_info to an empty struct.
- Make xen_initial_domain dependent on the SIF_PRIVILIGED_BIT.

The new code only compiles when CONFIG_XEN is set, that is going to be
added to arch/arm/Kconfig in patch #11 "xen/arm: introduce CONFIG_XEN on
ARM".

Changes in v3:

- improve comments.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 arch/arm/Makefile                     |    1 +
 arch/arm/include/asm/hypervisor.h     |    6 +++
 arch/arm/include/asm/xen/hypervisor.h |   19 +++++++++
 arch/arm/include/asm/xen/interface.h  |   69 +++++++++++++++++++++++++++++++++
 arch/arm/xen/Makefile                 |    1 +
 arch/arm/xen/enlighten.c              |   35 +++++++++++++++++
 include/xen/xen.h                     |    2 +-
 7 files changed, 132 insertions(+), 1 deletions(-)
 create mode 100644 arch/arm/include/asm/hypervisor.h
 create mode 100644 arch/arm/include/asm/xen/hypervisor.h
 create mode 100644 arch/arm/include/asm/xen/interface.h
 create mode 100644 arch/arm/xen/Makefile
 create mode 100644 arch/arm/xen/enlighten.c

diff --git a/arch/arm/Makefile b/arch/arm/Makefile
index 30eae87..f42968a 100644
--- a/arch/arm/Makefile
+++ b/arch/arm/Makefile
@@ -251,6 +251,7 @@ endif
 core-$(CONFIG_FPE_NWFPE)	+= arch/arm/nwfpe/
 core-$(CONFIG_FPE_FASTFPE)	+= $(FASTFPE_OBJ)
 core-$(CONFIG_VFP)		+= arch/arm/vfp/
+core-$(CONFIG_XEN)		+= arch/arm/xen/
 
 # If we have a machine-specific directory, then include it in the build.
 core-y				+= arch/arm/kernel/ arch/arm/mm/ arch/arm/common/
diff --git a/arch/arm/include/asm/hypervisor.h b/arch/arm/include/asm/hypervisor.h
new file mode 100644
index 0000000..b90d9e5
--- /dev/null
+++ b/arch/arm/include/asm/hypervisor.h
@@ -0,0 +1,6 @@
+#ifndef _ASM_ARM_HYPERVISOR_H
+#define _ASM_ARM_HYPERVISOR_H
+
+#include <asm/xen/hypervisor.h>
+
+#endif
diff --git a/arch/arm/include/asm/xen/hypervisor.h b/arch/arm/include/asm/xen/hypervisor.h
new file mode 100644
index 0000000..d7ab99a
--- /dev/null
+++ b/arch/arm/include/asm/xen/hypervisor.h
@@ -0,0 +1,19 @@
+#ifndef _ASM_ARM_XEN_HYPERVISOR_H
+#define _ASM_ARM_XEN_HYPERVISOR_H
+
+extern struct shared_info *HYPERVISOR_shared_info;
+extern struct start_info *xen_start_info;
+
+/* Lazy mode for batching updates / context switch */
+enum paravirt_lazy_mode {
+	PARAVIRT_LAZY_NONE,
+	PARAVIRT_LAZY_MMU,
+	PARAVIRT_LAZY_CPU,
+};
+
+static inline enum paravirt_lazy_mode paravirt_get_lazy_mode(void)
+{
+	return PARAVIRT_LAZY_NONE;
+}
+
+#endif /* _ASM_ARM_XEN_HYPERVISOR_H */
diff --git a/arch/arm/include/asm/xen/interface.h b/arch/arm/include/asm/xen/interface.h
new file mode 100644
index 0000000..74c72b5
--- /dev/null
+++ b/arch/arm/include/asm/xen/interface.h
@@ -0,0 +1,69 @@
+/******************************************************************************
+ * Guest OS interface to ARM Xen.
+ *
+ * Stefano Stabellini <stefano.stabellini@eu.citrix.com>, Citrix, 2012
+ */
+
+#ifndef _ASM_ARM_XEN_INTERFACE_H
+#define _ASM_ARM_XEN_INTERFACE_H
+
+#include <linux/types.h>
+
+#define __DEFINE_GUEST_HANDLE(name, type) \
+	typedef type * __guest_handle_ ## name
+
+#define DEFINE_GUEST_HANDLE_STRUCT(name) \
+	__DEFINE_GUEST_HANDLE(name, struct name)
+#define DEFINE_GUEST_HANDLE(name) __DEFINE_GUEST_HANDLE(name, name)
+#define GUEST_HANDLE(name)        __guest_handle_ ## name
+
+#define set_xen_guest_handle(hnd, val)			\
+	do {						\
+		if (sizeof(hnd) == 8)			\
+			*(uint64_t *)&(hnd) = 0;	\
+		(hnd) = val;				\
+	} while (0)
+
+#ifndef __ASSEMBLY__
+/* Explicitly size integers that represent pfns in the interface with
+ * Xen so that we can have one ABI that works for 32 and 64 bit guests. */
+typedef uint64_t xen_pfn_t;
+/* Guest handles for primitive C types. */
+__DEFINE_GUEST_HANDLE(uchar, unsigned char);
+__DEFINE_GUEST_HANDLE(uint,  unsigned int);
+__DEFINE_GUEST_HANDLE(ulong, unsigned long);
+DEFINE_GUEST_HANDLE(char);
+DEFINE_GUEST_HANDLE(int);
+DEFINE_GUEST_HANDLE(long);
+DEFINE_GUEST_HANDLE(void);
+DEFINE_GUEST_HANDLE(uint64_t);
+DEFINE_GUEST_HANDLE(uint32_t);
+DEFINE_GUEST_HANDLE(xen_pfn_t);
+
+/* Maximum number of virtual CPUs in multi-processor guests. */
+#define MAX_VIRT_CPUS 1
+
+struct arch_vcpu_info { };
+struct arch_shared_info { };
+
+/* TODO: Move pvclock definitions some place arch independent */
+struct pvclock_vcpu_time_info {
+	u32   version;
+	u32   pad0;
+	u64   tsc_timestamp;
+	u64   system_time;
+	u32   tsc_to_system_mul;
+	s8    tsc_shift;
+	u8    flags;
+	u8    pad[2];
+} __attribute__((__packed__)); /* 32 bytes */
+
+/* It is OK to have a 12 bytes struct with no padding because it is packed */
+struct pvclock_wall_clock {
+	u32   version;
+	u32   sec;
+	u32   nsec;
+} __attribute__((__packed__));
+#endif
+
+#endif /* _ASM_ARM_XEN_INTERFACE_H */
diff --git a/arch/arm/xen/Makefile b/arch/arm/xen/Makefile
new file mode 100644
index 0000000..0bad594
--- /dev/null
+++ b/arch/arm/xen/Makefile
@@ -0,0 +1 @@
+obj-y		:= enlighten.o
diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
new file mode 100644
index 0000000..c535540
--- /dev/null
+++ b/arch/arm/xen/enlighten.c
@@ -0,0 +1,35 @@
+#include <xen/xen.h>
+#include <xen/interface/xen.h>
+#include <xen/interface/memory.h>
+#include <xen/platform_pci.h>
+#include <asm/xen/hypervisor.h>
+#include <asm/xen/hypercall.h>
+#include <linux/module.h>
+
+struct start_info _xen_start_info;
+struct start_info *xen_start_info = &_xen_start_info;
+EXPORT_SYMBOL_GPL(xen_start_info);
+
+enum xen_domain_type xen_domain_type = XEN_NATIVE;
+EXPORT_SYMBOL_GPL(xen_domain_type);
+
+struct shared_info xen_dummy_shared_info;
+struct shared_info *HYPERVISOR_shared_info = (void *)&xen_dummy_shared_info;
+
+DEFINE_PER_CPU(struct vcpu_info *, xen_vcpu);
+
+/* TODO: to be removed */
+__read_mostly int xen_have_vector_callback;
+EXPORT_SYMBOL_GPL(xen_have_vector_callback);
+
+int xen_platform_pci_unplug = XEN_UNPLUG_ALL;
+EXPORT_SYMBOL_GPL(xen_platform_pci_unplug);
+
+int xen_remap_domain_mfn_range(struct vm_area_struct *vma,
+			       unsigned long addr,
+			       unsigned long mfn, int nr,
+			       pgprot_t prot, unsigned domid)
+{
+	return -ENOSYS;
+}
+EXPORT_SYMBOL_GPL(xen_remap_domain_mfn_range);
diff --git a/include/xen/xen.h b/include/xen/xen.h
index a164024..2c0d3a5 100644
--- a/include/xen/xen.h
+++ b/include/xen/xen.h
@@ -23,7 +23,7 @@ extern enum xen_domain_type xen_domain_type;
 #include <xen/interface/xen.h>
 #include <asm/xen/hypervisor.h>
 
-#define xen_initial_domain()	(xen_pv_domain() && \
+#define xen_initial_domain()	(xen_domain() && \
 				 xen_start_info->flags & SIF_INITDOMAIN)
 #else  /* !CONFIG_XEN_DOM0 */
 #define xen_initial_domain()	(0)
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 17 17:40:20 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 17: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 1TDfIi-0001jp-HG; Mon, 17 Sep 2012 17:40:04 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1TDfIh-0001jN-O6
	for xen-devel@lists.xensource.com; Mon, 17 Sep 2012 17:40:04 +0000
Received: from [85.158.137.99:60216] by server-6.bemta-3.messagelabs.com id
	CC/2D-29694-27067505; Mon, 17 Sep 2012 17:40:02 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-16.tower-217.messagelabs.com!1347903598!18037392!3
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNzUxNjg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1274 invoked from network); 17 Sep 2012 17:40:01 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-16.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Sep 2012 17:40:01 -0000
X-IronPort-AV: E=Sophos;i="4.80,437,1344211200"; d="scan'208";a="208319291"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Sep 2012 17:39:40 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Mon, 17 Sep 2012 13:39:39 -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 1TDfIE-0008AT-Oc;
	Mon, 17 Sep 2012 18:39:34 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: <arnd@arndb.de>
Date: Mon, 17 Sep 2012 18:38:47 +0100
Message-ID: <1347903543-2135-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.1209171215490.29232@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1209171215490.29232@kaball.uk.xensource.com>
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com, linaro-dev@lists.linaro.org,
	Ian.Campbell@citrix.com, konrad.wilk@oracle.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	tim@xen.org, linux-kernel@vger.kernel.org,
	linux@arm.linux.org.uk, linux-arm-kernel@lists.infradead.org
Subject: [Xen-devel] [PATCH v5 01/17] arm: initial Xen 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

- Basic hypervisor.h and interface.h definitions.
- Skeleton enlighten.c, set xen_start_info to an empty struct.
- Make xen_initial_domain dependent on the SIF_PRIVILIGED_BIT.

The new code only compiles when CONFIG_XEN is set, that is going to be
added to arch/arm/Kconfig in patch #11 "xen/arm: introduce CONFIG_XEN on
ARM".

Changes in v3:

- improve comments.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 arch/arm/Makefile                     |    1 +
 arch/arm/include/asm/hypervisor.h     |    6 +++
 arch/arm/include/asm/xen/hypervisor.h |   19 +++++++++
 arch/arm/include/asm/xen/interface.h  |   69 +++++++++++++++++++++++++++++++++
 arch/arm/xen/Makefile                 |    1 +
 arch/arm/xen/enlighten.c              |   35 +++++++++++++++++
 include/xen/xen.h                     |    2 +-
 7 files changed, 132 insertions(+), 1 deletions(-)
 create mode 100644 arch/arm/include/asm/hypervisor.h
 create mode 100644 arch/arm/include/asm/xen/hypervisor.h
 create mode 100644 arch/arm/include/asm/xen/interface.h
 create mode 100644 arch/arm/xen/Makefile
 create mode 100644 arch/arm/xen/enlighten.c

diff --git a/arch/arm/Makefile b/arch/arm/Makefile
index 30eae87..f42968a 100644
--- a/arch/arm/Makefile
+++ b/arch/arm/Makefile
@@ -251,6 +251,7 @@ endif
 core-$(CONFIG_FPE_NWFPE)	+= arch/arm/nwfpe/
 core-$(CONFIG_FPE_FASTFPE)	+= $(FASTFPE_OBJ)
 core-$(CONFIG_VFP)		+= arch/arm/vfp/
+core-$(CONFIG_XEN)		+= arch/arm/xen/
 
 # If we have a machine-specific directory, then include it in the build.
 core-y				+= arch/arm/kernel/ arch/arm/mm/ arch/arm/common/
diff --git a/arch/arm/include/asm/hypervisor.h b/arch/arm/include/asm/hypervisor.h
new file mode 100644
index 0000000..b90d9e5
--- /dev/null
+++ b/arch/arm/include/asm/hypervisor.h
@@ -0,0 +1,6 @@
+#ifndef _ASM_ARM_HYPERVISOR_H
+#define _ASM_ARM_HYPERVISOR_H
+
+#include <asm/xen/hypervisor.h>
+
+#endif
diff --git a/arch/arm/include/asm/xen/hypervisor.h b/arch/arm/include/asm/xen/hypervisor.h
new file mode 100644
index 0000000..d7ab99a
--- /dev/null
+++ b/arch/arm/include/asm/xen/hypervisor.h
@@ -0,0 +1,19 @@
+#ifndef _ASM_ARM_XEN_HYPERVISOR_H
+#define _ASM_ARM_XEN_HYPERVISOR_H
+
+extern struct shared_info *HYPERVISOR_shared_info;
+extern struct start_info *xen_start_info;
+
+/* Lazy mode for batching updates / context switch */
+enum paravirt_lazy_mode {
+	PARAVIRT_LAZY_NONE,
+	PARAVIRT_LAZY_MMU,
+	PARAVIRT_LAZY_CPU,
+};
+
+static inline enum paravirt_lazy_mode paravirt_get_lazy_mode(void)
+{
+	return PARAVIRT_LAZY_NONE;
+}
+
+#endif /* _ASM_ARM_XEN_HYPERVISOR_H */
diff --git a/arch/arm/include/asm/xen/interface.h b/arch/arm/include/asm/xen/interface.h
new file mode 100644
index 0000000..74c72b5
--- /dev/null
+++ b/arch/arm/include/asm/xen/interface.h
@@ -0,0 +1,69 @@
+/******************************************************************************
+ * Guest OS interface to ARM Xen.
+ *
+ * Stefano Stabellini <stefano.stabellini@eu.citrix.com>, Citrix, 2012
+ */
+
+#ifndef _ASM_ARM_XEN_INTERFACE_H
+#define _ASM_ARM_XEN_INTERFACE_H
+
+#include <linux/types.h>
+
+#define __DEFINE_GUEST_HANDLE(name, type) \
+	typedef type * __guest_handle_ ## name
+
+#define DEFINE_GUEST_HANDLE_STRUCT(name) \
+	__DEFINE_GUEST_HANDLE(name, struct name)
+#define DEFINE_GUEST_HANDLE(name) __DEFINE_GUEST_HANDLE(name, name)
+#define GUEST_HANDLE(name)        __guest_handle_ ## name
+
+#define set_xen_guest_handle(hnd, val)			\
+	do {						\
+		if (sizeof(hnd) == 8)			\
+			*(uint64_t *)&(hnd) = 0;	\
+		(hnd) = val;				\
+	} while (0)
+
+#ifndef __ASSEMBLY__
+/* Explicitly size integers that represent pfns in the interface with
+ * Xen so that we can have one ABI that works for 32 and 64 bit guests. */
+typedef uint64_t xen_pfn_t;
+/* Guest handles for primitive C types. */
+__DEFINE_GUEST_HANDLE(uchar, unsigned char);
+__DEFINE_GUEST_HANDLE(uint,  unsigned int);
+__DEFINE_GUEST_HANDLE(ulong, unsigned long);
+DEFINE_GUEST_HANDLE(char);
+DEFINE_GUEST_HANDLE(int);
+DEFINE_GUEST_HANDLE(long);
+DEFINE_GUEST_HANDLE(void);
+DEFINE_GUEST_HANDLE(uint64_t);
+DEFINE_GUEST_HANDLE(uint32_t);
+DEFINE_GUEST_HANDLE(xen_pfn_t);
+
+/* Maximum number of virtual CPUs in multi-processor guests. */
+#define MAX_VIRT_CPUS 1
+
+struct arch_vcpu_info { };
+struct arch_shared_info { };
+
+/* TODO: Move pvclock definitions some place arch independent */
+struct pvclock_vcpu_time_info {
+	u32   version;
+	u32   pad0;
+	u64   tsc_timestamp;
+	u64   system_time;
+	u32   tsc_to_system_mul;
+	s8    tsc_shift;
+	u8    flags;
+	u8    pad[2];
+} __attribute__((__packed__)); /* 32 bytes */
+
+/* It is OK to have a 12 bytes struct with no padding because it is packed */
+struct pvclock_wall_clock {
+	u32   version;
+	u32   sec;
+	u32   nsec;
+} __attribute__((__packed__));
+#endif
+
+#endif /* _ASM_ARM_XEN_INTERFACE_H */
diff --git a/arch/arm/xen/Makefile b/arch/arm/xen/Makefile
new file mode 100644
index 0000000..0bad594
--- /dev/null
+++ b/arch/arm/xen/Makefile
@@ -0,0 +1 @@
+obj-y		:= enlighten.o
diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
new file mode 100644
index 0000000..c535540
--- /dev/null
+++ b/arch/arm/xen/enlighten.c
@@ -0,0 +1,35 @@
+#include <xen/xen.h>
+#include <xen/interface/xen.h>
+#include <xen/interface/memory.h>
+#include <xen/platform_pci.h>
+#include <asm/xen/hypervisor.h>
+#include <asm/xen/hypercall.h>
+#include <linux/module.h>
+
+struct start_info _xen_start_info;
+struct start_info *xen_start_info = &_xen_start_info;
+EXPORT_SYMBOL_GPL(xen_start_info);
+
+enum xen_domain_type xen_domain_type = XEN_NATIVE;
+EXPORT_SYMBOL_GPL(xen_domain_type);
+
+struct shared_info xen_dummy_shared_info;
+struct shared_info *HYPERVISOR_shared_info = (void *)&xen_dummy_shared_info;
+
+DEFINE_PER_CPU(struct vcpu_info *, xen_vcpu);
+
+/* TODO: to be removed */
+__read_mostly int xen_have_vector_callback;
+EXPORT_SYMBOL_GPL(xen_have_vector_callback);
+
+int xen_platform_pci_unplug = XEN_UNPLUG_ALL;
+EXPORT_SYMBOL_GPL(xen_platform_pci_unplug);
+
+int xen_remap_domain_mfn_range(struct vm_area_struct *vma,
+			       unsigned long addr,
+			       unsigned long mfn, int nr,
+			       pgprot_t prot, unsigned domid)
+{
+	return -ENOSYS;
+}
+EXPORT_SYMBOL_GPL(xen_remap_domain_mfn_range);
diff --git a/include/xen/xen.h b/include/xen/xen.h
index a164024..2c0d3a5 100644
--- a/include/xen/xen.h
+++ b/include/xen/xen.h
@@ -23,7 +23,7 @@ extern enum xen_domain_type xen_domain_type;
 #include <xen/interface/xen.h>
 #include <asm/xen/hypervisor.h>
 
-#define xen_initial_domain()	(xen_pv_domain() && \
+#define xen_initial_domain()	(xen_domain() && \
 				 xen_start_info->flags & SIF_INITDOMAIN)
 #else  /* !CONFIG_XEN_DOM0 */
 #define xen_initial_domain()	(0)
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 17 17:40:20 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 17: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 1TDfIi-0001k1-UT; Mon, 17 Sep 2012 17:40:04 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1TDfIi-0001j7-1D
	for xen-devel@lists.xensource.com; Mon, 17 Sep 2012 17:40:04 +0000
Received: from [85.158.137.99:2697] by server-11.bemta-3.messagelabs.com id
	12/33-30250-37067505; Mon, 17 Sep 2012 17:40:03 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-16.tower-217.messagelabs.com!1347903598!18037392!4
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNzUxNjg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1317 invoked from network); 17 Sep 2012 17:40:02 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-16.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Sep 2012 17:40:02 -0000
X-IronPort-AV: E=Sophos;i="4.80,437,1344211200"; d="scan'208";a="208319294"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Sep 2012 17:39:40 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Mon, 17 Sep 2012 13:39:40 -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 1TDfIE-0008AT-UG;
	Mon, 17 Sep 2012 18:39:34 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: <arnd@arndb.de>
Date: Mon, 17 Sep 2012 18:38:52 +0100
Message-ID: <1347903543-2135-6-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <alpine.DEB.2.02.1209171215490.29232@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1209171215490.29232@kaball.uk.xensource.com>
MIME-Version: 1.0
Cc: Dave Martin <dave.martin@linaro.org>, xen-devel@lists.xensource.com,
	linaro-dev@lists.linaro.org, Ian.Campbell@citrix.com,
	konrad.wilk@oracle.com, devicetree-discuss@lists.ozlabs.org,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	tim@xen.org, linux-kernel@vger.kernel.org,
	Rob Herring <robherring2@gmail.com>,
	David Vrabel <david.vrabel@citrix.com>, linux@arm.linux.org.uk,
	linux-arm-kernel@lists.infradead.org
Subject: [Xen-devel] [PATCH v5 06/17] docs: Xen ARM DT bindings
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Add a doc to describe the Xen ARM device tree bindings


Changes in v5:

- add a comment about the size of the grant table memory region;
- add a comment about the required presence of a GIC node;
- specify that the described properties are part of a top-level
"hypervisor" node;
- specify #address-cells and #size-cells for the example.


Changes in v4:

- "xen,xen" should be last as it is less specific;
- update reg property using 2 address-cells and 2 size-cells.


Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
CC: devicetree-discuss@lists.ozlabs.org
CC: David Vrabel <david.vrabel@citrix.com>
CC: Rob Herring <robherring2@gmail.com>
CC: Dave Martin <dave.martin@linaro.org>
---
 Documentation/devicetree/bindings/arm/xen.txt |   25 +++++++++++++++++++++++++
 1 files changed, 25 insertions(+), 0 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/arm/xen.txt

diff --git a/Documentation/devicetree/bindings/arm/xen.txt b/Documentation/devicetree/bindings/arm/xen.txt
new file mode 100644
index 0000000..0f7b9c2
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/xen.txt
@@ -0,0 +1,25 @@
+* Xen hypervisor device tree bindings
+
+Xen ARM virtual platforms shall have a top-level "hypervisor" node with
+the following properties:
+
+- compatible:
+	compatible = "xen,xen-<version>", "xen,xen";
+  where <version> is the version of the Xen ABI of the platform.
+
+- reg: specifies the base physical address and size of a region in
+  memory where the grant table should be mapped to, using an
+  HYPERVISOR_memory_op hypercall. The memory region is large enough to map
+  the whole grant table (it is larger or equal to gnttab_max_grant_frames()).
+
+- interrupts: the interrupt used by Xen to inject event notifications.
+  A GIC node is also required.
+
+
+Example (assuming #address-cells = <2> and #size-cells = <2>):
+
+hypervisor {
+	compatible = "xen,xen-4.3", "xen,xen";
+	reg = <0 0xb0000000 0 0x20000>;
+	interrupts = <1 15 0xf08>;
+};
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 17 17:40:20 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 17: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 1TDfIl-0001lD-Vb; Mon, 17 Sep 2012 17:40: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 1TDfIk-0001kK-JR
	for xen-devel@lists.xensource.com; Mon, 17 Sep 2012 17:40:06 +0000
Received: from [85.158.137.99:57118] by server-10.bemta-3.messagelabs.com id
	14/0D-10411-57067505; Mon, 17 Sep 2012 17:40:05 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-16.tower-217.messagelabs.com!1347903598!18037392!5
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNzUxNjg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1620 invoked from network); 17 Sep 2012 17:40:05 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-16.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Sep 2012 17:40:05 -0000
X-IronPort-AV: E=Sophos;i="4.80,437,1344211200"; d="scan'208";a="208319292"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Sep 2012 17:39:40 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Mon, 17 Sep 2012 13:39:39 -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 1TDfIE-0008AT-SN;
	Mon, 17 Sep 2012 18:39:34 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: <arnd@arndb.de>
Date: Mon, 17 Sep 2012 18:38:51 +0100
Message-ID: <1347903543-2135-5-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <alpine.DEB.2.02.1209171215490.29232@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1209171215490.29232@kaball.uk.xensource.com>
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com, linaro-dev@lists.linaro.org,
	Ian.Campbell@citrix.com, konrad.wilk@oracle.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	tim@xen.org, linux-kernel@vger.kernel.org,
	linux@arm.linux.org.uk, linux-arm-kernel@lists.infradead.org
Subject: [Xen-devel] [PATCH v5 05/17] xen/arm: empty implementation of
	grant_table arch specific 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

Changes in v2:

- return -ENOSYS rather than -1.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 arch/arm/xen/Makefile      |    2 +-
 arch/arm/xen/grant-table.c |   53 ++++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 54 insertions(+), 1 deletions(-)
 create mode 100644 arch/arm/xen/grant-table.c

diff --git a/arch/arm/xen/Makefile b/arch/arm/xen/Makefile
index b9d6acc..4384103 100644
--- a/arch/arm/xen/Makefile
+++ b/arch/arm/xen/Makefile
@@ -1 +1 @@
-obj-y		:= enlighten.o hypercall.o
+obj-y		:= enlighten.o hypercall.o grant-table.o
diff --git a/arch/arm/xen/grant-table.c b/arch/arm/xen/grant-table.c
new file mode 100644
index 0000000..dbd1330
--- /dev/null
+++ b/arch/arm/xen/grant-table.c
@@ -0,0 +1,53 @@
+/******************************************************************************
+ * grant_table.c
+ * ARM specific part
+ *
+ * Granting foreign access to our memory reservation.
+ *
+ * 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 <xen/interface/xen.h>
+#include <xen/page.h>
+#include <xen/grant_table.h>
+
+int arch_gnttab_map_shared(unsigned long *frames, unsigned long nr_gframes,
+			   unsigned long max_nr_gframes,
+			   void **__shared)
+{
+	return -ENOSYS;
+}
+
+void arch_gnttab_unmap(void *shared, unsigned long nr_gframes)
+{
+	return;
+}
+
+int arch_gnttab_map_status(uint64_t *frames, unsigned long nr_gframes,
+			   unsigned long max_nr_gframes,
+			   grant_status_t **__shared)
+{
+	return -ENOSYS;
+}
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 17 17:40:20 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 17: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 1TDfIi-0001ja-59; Mon, 17 Sep 2012 17:40:04 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1TDfIg-0001j7-Sr
	for xen-devel@lists.xensource.com; Mon, 17 Sep 2012 17:40:03 +0000
Received: from [85.158.137.99:60168] by server-11.bemta-3.messagelabs.com id
	38/23-30250-17067505; Mon, 17 Sep 2012 17:40:01 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-16.tower-217.messagelabs.com!1347903598!18037392!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNzUxNjg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1062 invoked from network); 17 Sep 2012 17:40:00 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-16.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Sep 2012 17:40:00 -0000
X-IronPort-AV: E=Sophos;i="4.80,437,1344211200"; d="scan'208";a="208319290"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Sep 2012 17:39:40 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Mon, 17 Sep 2012 13:39:39 -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 1TDfIE-0008AT-Rk;
	Mon, 17 Sep 2012 18:39:34 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: <arnd@arndb.de>
Date: Mon, 17 Sep 2012 18:38:50 +0100
Message-ID: <1347903543-2135-4-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <alpine.DEB.2.02.1209171215490.29232@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1209171215490.29232@kaball.uk.xensource.com>
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com, linaro-dev@lists.linaro.org,
	Ian.Campbell@citrix.com, konrad.wilk@oracle.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	tim@xen.org, linux-kernel@vger.kernel.org,
	linux@arm.linux.org.uk, linux-arm-kernel@lists.infradead.org
Subject: [Xen-devel] [PATCH v5 04/17] xen/arm: sync_bitops
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

sync_bitops functions are equivalent to the SMP implementation of the
original functions, independently from CONFIG_SMP being defined.

We need them because _set_bit etc are not SMP safe if !CONFIG_SMP. But
under Xen you might be communicating with a completely external entity
who might be on another CPU (e.g. two uniprocessor guests communicating
via event channels and grant tables). So we need a variant of the bit
ops which are SMP safe even on a UP kernel.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 arch/arm/include/asm/sync_bitops.h |   27 +++++++++++++++++++++++++++
 1 files changed, 27 insertions(+), 0 deletions(-)
 create mode 100644 arch/arm/include/asm/sync_bitops.h

diff --git a/arch/arm/include/asm/sync_bitops.h b/arch/arm/include/asm/sync_bitops.h
new file mode 100644
index 0000000..63479ee
--- /dev/null
+++ b/arch/arm/include/asm/sync_bitops.h
@@ -0,0 +1,27 @@
+#ifndef __ASM_SYNC_BITOPS_H__
+#define __ASM_SYNC_BITOPS_H__
+
+#include <asm/bitops.h>
+#include <asm/system.h>
+
+/* sync_bitops functions are equivalent to the SMP implementation of the
+ * original functions, independently from CONFIG_SMP being defined.
+ *
+ * We need them because _set_bit etc are not SMP safe if !CONFIG_SMP. But
+ * under Xen you might be communicating with a completely external entity
+ * who might be on another CPU (e.g. two uniprocessor guests communicating
+ * via event channels and grant tables). So we need a variant of the bit
+ * ops which are SMP safe even on a UP kernel.
+ */
+
+#define sync_set_bit(nr, p)		_set_bit(nr, p)
+#define sync_clear_bit(nr, p)		_clear_bit(nr, p)
+#define sync_change_bit(nr, p)		_change_bit(nr, p)
+#define sync_test_and_set_bit(nr, p)	_test_and_set_bit(nr, p)
+#define sync_test_and_clear_bit(nr, p)	_test_and_clear_bit(nr, p)
+#define sync_test_and_change_bit(nr, p)	_test_and_change_bit(nr, p)
+#define sync_test_bit(nr, addr)		test_bit(nr, addr)
+#define sync_cmpxchg			cmpxchg
+
+
+#endif
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 17 17:40:20 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 17: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 1TDfIi-0001k1-UT; Mon, 17 Sep 2012 17:40:04 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1TDfIi-0001j7-1D
	for xen-devel@lists.xensource.com; Mon, 17 Sep 2012 17:40:04 +0000
Received: from [85.158.137.99:2697] by server-11.bemta-3.messagelabs.com id
	12/33-30250-37067505; Mon, 17 Sep 2012 17:40:03 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-16.tower-217.messagelabs.com!1347903598!18037392!4
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNzUxNjg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1317 invoked from network); 17 Sep 2012 17:40:02 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-16.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Sep 2012 17:40:02 -0000
X-IronPort-AV: E=Sophos;i="4.80,437,1344211200"; d="scan'208";a="208319294"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Sep 2012 17:39:40 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Mon, 17 Sep 2012 13:39:40 -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 1TDfIE-0008AT-UG;
	Mon, 17 Sep 2012 18:39:34 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: <arnd@arndb.de>
Date: Mon, 17 Sep 2012 18:38:52 +0100
Message-ID: <1347903543-2135-6-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <alpine.DEB.2.02.1209171215490.29232@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1209171215490.29232@kaball.uk.xensource.com>
MIME-Version: 1.0
Cc: Dave Martin <dave.martin@linaro.org>, xen-devel@lists.xensource.com,
	linaro-dev@lists.linaro.org, Ian.Campbell@citrix.com,
	konrad.wilk@oracle.com, devicetree-discuss@lists.ozlabs.org,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	tim@xen.org, linux-kernel@vger.kernel.org,
	Rob Herring <robherring2@gmail.com>,
	David Vrabel <david.vrabel@citrix.com>, linux@arm.linux.org.uk,
	linux-arm-kernel@lists.infradead.org
Subject: [Xen-devel] [PATCH v5 06/17] docs: Xen ARM DT bindings
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Add a doc to describe the Xen ARM device tree bindings


Changes in v5:

- add a comment about the size of the grant table memory region;
- add a comment about the required presence of a GIC node;
- specify that the described properties are part of a top-level
"hypervisor" node;
- specify #address-cells and #size-cells for the example.


Changes in v4:

- "xen,xen" should be last as it is less specific;
- update reg property using 2 address-cells and 2 size-cells.


Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
CC: devicetree-discuss@lists.ozlabs.org
CC: David Vrabel <david.vrabel@citrix.com>
CC: Rob Herring <robherring2@gmail.com>
CC: Dave Martin <dave.martin@linaro.org>
---
 Documentation/devicetree/bindings/arm/xen.txt |   25 +++++++++++++++++++++++++
 1 files changed, 25 insertions(+), 0 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/arm/xen.txt

diff --git a/Documentation/devicetree/bindings/arm/xen.txt b/Documentation/devicetree/bindings/arm/xen.txt
new file mode 100644
index 0000000..0f7b9c2
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/xen.txt
@@ -0,0 +1,25 @@
+* Xen hypervisor device tree bindings
+
+Xen ARM virtual platforms shall have a top-level "hypervisor" node with
+the following properties:
+
+- compatible:
+	compatible = "xen,xen-<version>", "xen,xen";
+  where <version> is the version of the Xen ABI of the platform.
+
+- reg: specifies the base physical address and size of a region in
+  memory where the grant table should be mapped to, using an
+  HYPERVISOR_memory_op hypercall. The memory region is large enough to map
+  the whole grant table (it is larger or equal to gnttab_max_grant_frames()).
+
+- interrupts: the interrupt used by Xen to inject event notifications.
+  A GIC node is also required.
+
+
+Example (assuming #address-cells = <2> and #size-cells = <2>):
+
+hypervisor {
+	compatible = "xen,xen-4.3", "xen,xen";
+	reg = <0 0xb0000000 0 0x20000>;
+	interrupts = <1 15 0xf08>;
+};
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 17 17:40:20 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 17: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 1TDfIl-0001lD-Vb; Mon, 17 Sep 2012 17:40: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 1TDfIk-0001kK-JR
	for xen-devel@lists.xensource.com; Mon, 17 Sep 2012 17:40:06 +0000
Received: from [85.158.137.99:57118] by server-10.bemta-3.messagelabs.com id
	14/0D-10411-57067505; Mon, 17 Sep 2012 17:40:05 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-16.tower-217.messagelabs.com!1347903598!18037392!5
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNzUxNjg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1620 invoked from network); 17 Sep 2012 17:40:05 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-16.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Sep 2012 17:40:05 -0000
X-IronPort-AV: E=Sophos;i="4.80,437,1344211200"; d="scan'208";a="208319292"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Sep 2012 17:39:40 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Mon, 17 Sep 2012 13:39:39 -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 1TDfIE-0008AT-SN;
	Mon, 17 Sep 2012 18:39:34 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: <arnd@arndb.de>
Date: Mon, 17 Sep 2012 18:38:51 +0100
Message-ID: <1347903543-2135-5-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <alpine.DEB.2.02.1209171215490.29232@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1209171215490.29232@kaball.uk.xensource.com>
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com, linaro-dev@lists.linaro.org,
	Ian.Campbell@citrix.com, konrad.wilk@oracle.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	tim@xen.org, linux-kernel@vger.kernel.org,
	linux@arm.linux.org.uk, linux-arm-kernel@lists.infradead.org
Subject: [Xen-devel] [PATCH v5 05/17] xen/arm: empty implementation of
	grant_table arch specific 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

Changes in v2:

- return -ENOSYS rather than -1.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 arch/arm/xen/Makefile      |    2 +-
 arch/arm/xen/grant-table.c |   53 ++++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 54 insertions(+), 1 deletions(-)
 create mode 100644 arch/arm/xen/grant-table.c

diff --git a/arch/arm/xen/Makefile b/arch/arm/xen/Makefile
index b9d6acc..4384103 100644
--- a/arch/arm/xen/Makefile
+++ b/arch/arm/xen/Makefile
@@ -1 +1 @@
-obj-y		:= enlighten.o hypercall.o
+obj-y		:= enlighten.o hypercall.o grant-table.o
diff --git a/arch/arm/xen/grant-table.c b/arch/arm/xen/grant-table.c
new file mode 100644
index 0000000..dbd1330
--- /dev/null
+++ b/arch/arm/xen/grant-table.c
@@ -0,0 +1,53 @@
+/******************************************************************************
+ * grant_table.c
+ * ARM specific part
+ *
+ * Granting foreign access to our memory reservation.
+ *
+ * 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 <xen/interface/xen.h>
+#include <xen/page.h>
+#include <xen/grant_table.h>
+
+int arch_gnttab_map_shared(unsigned long *frames, unsigned long nr_gframes,
+			   unsigned long max_nr_gframes,
+			   void **__shared)
+{
+	return -ENOSYS;
+}
+
+void arch_gnttab_unmap(void *shared, unsigned long nr_gframes)
+{
+	return;
+}
+
+int arch_gnttab_map_status(uint64_t *frames, unsigned long nr_gframes,
+			   unsigned long max_nr_gframes,
+			   grant_status_t **__shared)
+{
+	return -ENOSYS;
+}
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 17 17:40:20 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 17: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 1TDfIi-0001ja-59; Mon, 17 Sep 2012 17:40:04 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1TDfIg-0001j7-Sr
	for xen-devel@lists.xensource.com; Mon, 17 Sep 2012 17:40:03 +0000
Received: from [85.158.137.99:60168] by server-11.bemta-3.messagelabs.com id
	38/23-30250-17067505; Mon, 17 Sep 2012 17:40:01 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-16.tower-217.messagelabs.com!1347903598!18037392!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNzUxNjg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1062 invoked from network); 17 Sep 2012 17:40:00 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-16.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Sep 2012 17:40:00 -0000
X-IronPort-AV: E=Sophos;i="4.80,437,1344211200"; d="scan'208";a="208319290"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Sep 2012 17:39:40 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Mon, 17 Sep 2012 13:39:39 -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 1TDfIE-0008AT-Rk;
	Mon, 17 Sep 2012 18:39:34 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: <arnd@arndb.de>
Date: Mon, 17 Sep 2012 18:38:50 +0100
Message-ID: <1347903543-2135-4-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <alpine.DEB.2.02.1209171215490.29232@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1209171215490.29232@kaball.uk.xensource.com>
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com, linaro-dev@lists.linaro.org,
	Ian.Campbell@citrix.com, konrad.wilk@oracle.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	tim@xen.org, linux-kernel@vger.kernel.org,
	linux@arm.linux.org.uk, linux-arm-kernel@lists.infradead.org
Subject: [Xen-devel] [PATCH v5 04/17] xen/arm: sync_bitops
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

sync_bitops functions are equivalent to the SMP implementation of the
original functions, independently from CONFIG_SMP being defined.

We need them because _set_bit etc are not SMP safe if !CONFIG_SMP. But
under Xen you might be communicating with a completely external entity
who might be on another CPU (e.g. two uniprocessor guests communicating
via event channels and grant tables). So we need a variant of the bit
ops which are SMP safe even on a UP kernel.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 arch/arm/include/asm/sync_bitops.h |   27 +++++++++++++++++++++++++++
 1 files changed, 27 insertions(+), 0 deletions(-)
 create mode 100644 arch/arm/include/asm/sync_bitops.h

diff --git a/arch/arm/include/asm/sync_bitops.h b/arch/arm/include/asm/sync_bitops.h
new file mode 100644
index 0000000..63479ee
--- /dev/null
+++ b/arch/arm/include/asm/sync_bitops.h
@@ -0,0 +1,27 @@
+#ifndef __ASM_SYNC_BITOPS_H__
+#define __ASM_SYNC_BITOPS_H__
+
+#include <asm/bitops.h>
+#include <asm/system.h>
+
+/* sync_bitops functions are equivalent to the SMP implementation of the
+ * original functions, independently from CONFIG_SMP being defined.
+ *
+ * We need them because _set_bit etc are not SMP safe if !CONFIG_SMP. But
+ * under Xen you might be communicating with a completely external entity
+ * who might be on another CPU (e.g. two uniprocessor guests communicating
+ * via event channels and grant tables). So we need a variant of the bit
+ * ops which are SMP safe even on a UP kernel.
+ */
+
+#define sync_set_bit(nr, p)		_set_bit(nr, p)
+#define sync_clear_bit(nr, p)		_clear_bit(nr, p)
+#define sync_change_bit(nr, p)		_change_bit(nr, p)
+#define sync_test_and_set_bit(nr, p)	_test_and_set_bit(nr, p)
+#define sync_test_and_clear_bit(nr, p)	_test_and_clear_bit(nr, p)
+#define sync_test_and_change_bit(nr, p)	_test_and_change_bit(nr, p)
+#define sync_test_bit(nr, addr)		test_bit(nr, addr)
+#define sync_cmpxchg			cmpxchg
+
+
+#endif
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 17 17:40:30 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 17:40: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 1TDfJ2-0001uY-Sv; Mon, 17 Sep 2012 17:40:24 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1TDfJ1-0001tF-7o
	for xen-devel@lists.xensource.com; Mon, 17 Sep 2012 17:40:23 +0000
Received: from [85.158.137.99:3317] by server-6.bemta-3.messagelabs.com id
	0E/7D-29694-68067505; Mon, 17 Sep 2012 17:40:22 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-11.tower-217.messagelabs.com!1347903619!16839862!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzAyMzE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1865 invoked from network); 17 Sep 2012 17:40:21 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-11.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Sep 2012 17:40:21 -0000
X-IronPort-AV: E=Sophos;i="4.80,437,1344211200"; d="scan'208";a="38105086"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Sep 2012 17:39:46 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Mon, 17 Sep 2012 13:39:45 -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 1TDfIF-0008AT-1f;
	Mon, 17 Sep 2012 18:39:35 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: <arnd@arndb.de>
Date: Mon, 17 Sep 2012 18:38:54 +0100
Message-ID: <1347903543-2135-8-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <alpine.DEB.2.02.1209171215490.29232@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1209171215490.29232@kaball.uk.xensource.com>
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com, linaro-dev@lists.linaro.org,
	Ian.Campbell@citrix.com, konrad.wilk@oracle.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	tim@xen.org, linux-kernel@vger.kernel.org,
	linux@arm.linux.org.uk, linux-arm-kernel@lists.infradead.org
Subject: [Xen-devel] [PATCH v5 08/17] xen/arm: Introduce xen_ulong_t for
	unsigned long
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

All the original Xen headers have xen_ulong_t as unsigned long type, however
when they have been imported in Linux, xen_ulong_t has been replaced with
unsigned long. That might work for x86 and ia64 but it does not for arm.
Bring back xen_ulong_t and let each architecture define xen_ulong_t as they
see fit.

Also explicitly size pointers (__DEFINE_GUEST_HANDLE) to 64 bit.


Changes in v3:

- remove the incorrect changes to multicall_entry;
- remove the change to apic_physbase.


Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 arch/arm/include/asm/xen/interface.h  |    8 ++++++--
 arch/ia64/include/asm/xen/interface.h |    1 +
 arch/x86/include/asm/xen/interface.h  |    1 +
 include/xen/interface/memory.h        |   12 ++++++------
 include/xen/interface/physdev.h       |    2 +-
 include/xen/interface/version.h       |    2 +-
 6 files changed, 16 insertions(+), 10 deletions(-)

diff --git a/arch/arm/include/asm/xen/interface.h b/arch/arm/include/asm/xen/interface.h
index 74c72b5..ae05e56 100644
--- a/arch/arm/include/asm/xen/interface.h
+++ b/arch/arm/include/asm/xen/interface.h
@@ -9,8 +9,11 @@
 
 #include <linux/types.h>
 
+#define uint64_aligned_t uint64_t __attribute__((aligned(8)))
+
 #define __DEFINE_GUEST_HANDLE(name, type) \
-	typedef type * __guest_handle_ ## name
+	typedef struct { union { type *p; uint64_aligned_t q; }; }  \
+        __guest_handle_ ## name
 
 #define DEFINE_GUEST_HANDLE_STRUCT(name) \
 	__DEFINE_GUEST_HANDLE(name, struct name)
@@ -21,13 +24,14 @@
 	do {						\
 		if (sizeof(hnd) == 8)			\
 			*(uint64_t *)&(hnd) = 0;	\
-		(hnd) = val;				\
+		(hnd).p = val;				\
 	} while (0)
 
 #ifndef __ASSEMBLY__
 /* Explicitly size integers that represent pfns in the interface with
  * Xen so that we can have one ABI that works for 32 and 64 bit guests. */
 typedef uint64_t xen_pfn_t;
+typedef uint64_t xen_ulong_t;
 /* Guest handles for primitive C types. */
 __DEFINE_GUEST_HANDLE(uchar, unsigned char);
 __DEFINE_GUEST_HANDLE(uint,  unsigned int);
diff --git a/arch/ia64/include/asm/xen/interface.h b/arch/ia64/include/asm/xen/interface.h
index 3d52a5b..e88c5de 100644
--- a/arch/ia64/include/asm/xen/interface.h
+++ b/arch/ia64/include/asm/xen/interface.h
@@ -71,6 +71,7 @@
  * with Xen so that we could have one ABI that works for 32 and 64 bit
  * guests. */
 typedef unsigned long xen_pfn_t;
+typedef unsigned long xen_ulong_t;
 /* Guest handles for primitive C types. */
 __DEFINE_GUEST_HANDLE(uchar, unsigned char);
 __DEFINE_GUEST_HANDLE(uint, unsigned int);
diff --git a/arch/x86/include/asm/xen/interface.h b/arch/x86/include/asm/xen/interface.h
index 555f94d..28fc621 100644
--- a/arch/x86/include/asm/xen/interface.h
+++ b/arch/x86/include/asm/xen/interface.h
@@ -51,6 +51,7 @@
  * with Xen so that on ARM we can have one ABI that works for 32 and 64
  * bit guests. */
 typedef unsigned long xen_pfn_t;
+typedef unsigned long xen_ulong_t;
 /* Guest handles for primitive C types. */
 __DEFINE_GUEST_HANDLE(uchar, unsigned char);
 __DEFINE_GUEST_HANDLE(uint,  unsigned int);
diff --git a/include/xen/interface/memory.h b/include/xen/interface/memory.h
index d8e33a9..b66d04c 100644
--- a/include/xen/interface/memory.h
+++ b/include/xen/interface/memory.h
@@ -34,7 +34,7 @@ struct xen_memory_reservation {
     GUEST_HANDLE(xen_pfn_t) extent_start;
 
     /* Number of extents, and size/alignment of each (2^extent_order pages). */
-    unsigned long  nr_extents;
+    xen_ulong_t  nr_extents;
     unsigned int   extent_order;
 
     /*
@@ -92,7 +92,7 @@ struct xen_memory_exchange {
      *     command will be non-zero.
      *  5. THIS FIELD MUST BE INITIALISED TO ZERO BY THE CALLER!
      */
-    unsigned long nr_exchanged;
+    xen_ulong_t nr_exchanged;
 };
 
 DEFINE_GUEST_HANDLE_STRUCT(xen_memory_exchange);
@@ -148,8 +148,8 @@ DEFINE_GUEST_HANDLE_STRUCT(xen_machphys_mfn_list);
  */
 #define XENMEM_machphys_mapping     12
 struct xen_machphys_mapping {
-    unsigned long v_start, v_end; /* Start and end virtual addresses.   */
-    unsigned long max_mfn;        /* Maximum MFN that can be looked up. */
+    xen_ulong_t v_start, v_end; /* Start and end virtual addresses.   */
+    xen_ulong_t max_mfn;        /* Maximum MFN that can be looked up. */
 };
 DEFINE_GUEST_HANDLE_STRUCT(xen_machphys_mapping_t);
 
@@ -172,7 +172,7 @@ struct xen_add_to_physmap {
     unsigned int space;
 
     /* Index into source mapping space. */
-    unsigned long idx;
+    xen_ulong_t idx;
 
     /* GPFN where the source mapping page should appear. */
     xen_pfn_t gpfn;
@@ -189,7 +189,7 @@ struct xen_translate_gpfn_list {
     domid_t domid;
 
     /* Length of list. */
-    unsigned long nr_gpfns;
+    xen_ulong_t nr_gpfns;
 
     /* List of GPFNs to translate. */
     GUEST_HANDLE(ulong) gpfn_list;
diff --git a/include/xen/interface/physdev.h b/include/xen/interface/physdev.h
index 9ce788d..f616514 100644
--- a/include/xen/interface/physdev.h
+++ b/include/xen/interface/physdev.h
@@ -56,7 +56,7 @@ struct physdev_eoi {
 #define PHYSDEVOP_pirq_eoi_gmfn_v2       28
 struct physdev_pirq_eoi_gmfn {
     /* IN */
-    unsigned long gmfn;
+    xen_ulong_t gmfn;
 };
 
 /*
diff --git a/include/xen/interface/version.h b/include/xen/interface/version.h
index dd58cf5..3030c81 100644
--- a/include/xen/interface/version.h
+++ b/include/xen/interface/version.h
@@ -45,7 +45,7 @@ struct xen_changeset_info {
 
 #define XENVER_platform_parameters 5
 struct xen_platform_parameters {
-    unsigned long virt_start;
+    xen_ulong_t virt_start;
 };
 
 #define XENVER_get_features 6
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 17 17:40:30 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 17:40: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 1TDfJ2-0001uY-Sv; Mon, 17 Sep 2012 17:40:24 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1TDfJ1-0001tF-7o
	for xen-devel@lists.xensource.com; Mon, 17 Sep 2012 17:40:23 +0000
Received: from [85.158.137.99:3317] by server-6.bemta-3.messagelabs.com id
	0E/7D-29694-68067505; Mon, 17 Sep 2012 17:40:22 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-11.tower-217.messagelabs.com!1347903619!16839862!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzAyMzE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1865 invoked from network); 17 Sep 2012 17:40:21 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-11.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Sep 2012 17:40:21 -0000
X-IronPort-AV: E=Sophos;i="4.80,437,1344211200"; d="scan'208";a="38105086"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Sep 2012 17:39:46 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Mon, 17 Sep 2012 13:39:45 -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 1TDfIF-0008AT-1f;
	Mon, 17 Sep 2012 18:39:35 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: <arnd@arndb.de>
Date: Mon, 17 Sep 2012 18:38:54 +0100
Message-ID: <1347903543-2135-8-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <alpine.DEB.2.02.1209171215490.29232@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1209171215490.29232@kaball.uk.xensource.com>
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com, linaro-dev@lists.linaro.org,
	Ian.Campbell@citrix.com, konrad.wilk@oracle.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	tim@xen.org, linux-kernel@vger.kernel.org,
	linux@arm.linux.org.uk, linux-arm-kernel@lists.infradead.org
Subject: [Xen-devel] [PATCH v5 08/17] xen/arm: Introduce xen_ulong_t for
	unsigned long
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

All the original Xen headers have xen_ulong_t as unsigned long type, however
when they have been imported in Linux, xen_ulong_t has been replaced with
unsigned long. That might work for x86 and ia64 but it does not for arm.
Bring back xen_ulong_t and let each architecture define xen_ulong_t as they
see fit.

Also explicitly size pointers (__DEFINE_GUEST_HANDLE) to 64 bit.


Changes in v3:

- remove the incorrect changes to multicall_entry;
- remove the change to apic_physbase.


Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 arch/arm/include/asm/xen/interface.h  |    8 ++++++--
 arch/ia64/include/asm/xen/interface.h |    1 +
 arch/x86/include/asm/xen/interface.h  |    1 +
 include/xen/interface/memory.h        |   12 ++++++------
 include/xen/interface/physdev.h       |    2 +-
 include/xen/interface/version.h       |    2 +-
 6 files changed, 16 insertions(+), 10 deletions(-)

diff --git a/arch/arm/include/asm/xen/interface.h b/arch/arm/include/asm/xen/interface.h
index 74c72b5..ae05e56 100644
--- a/arch/arm/include/asm/xen/interface.h
+++ b/arch/arm/include/asm/xen/interface.h
@@ -9,8 +9,11 @@
 
 #include <linux/types.h>
 
+#define uint64_aligned_t uint64_t __attribute__((aligned(8)))
+
 #define __DEFINE_GUEST_HANDLE(name, type) \
-	typedef type * __guest_handle_ ## name
+	typedef struct { union { type *p; uint64_aligned_t q; }; }  \
+        __guest_handle_ ## name
 
 #define DEFINE_GUEST_HANDLE_STRUCT(name) \
 	__DEFINE_GUEST_HANDLE(name, struct name)
@@ -21,13 +24,14 @@
 	do {						\
 		if (sizeof(hnd) == 8)			\
 			*(uint64_t *)&(hnd) = 0;	\
-		(hnd) = val;				\
+		(hnd).p = val;				\
 	} while (0)
 
 #ifndef __ASSEMBLY__
 /* Explicitly size integers that represent pfns in the interface with
  * Xen so that we can have one ABI that works for 32 and 64 bit guests. */
 typedef uint64_t xen_pfn_t;
+typedef uint64_t xen_ulong_t;
 /* Guest handles for primitive C types. */
 __DEFINE_GUEST_HANDLE(uchar, unsigned char);
 __DEFINE_GUEST_HANDLE(uint,  unsigned int);
diff --git a/arch/ia64/include/asm/xen/interface.h b/arch/ia64/include/asm/xen/interface.h
index 3d52a5b..e88c5de 100644
--- a/arch/ia64/include/asm/xen/interface.h
+++ b/arch/ia64/include/asm/xen/interface.h
@@ -71,6 +71,7 @@
  * with Xen so that we could have one ABI that works for 32 and 64 bit
  * guests. */
 typedef unsigned long xen_pfn_t;
+typedef unsigned long xen_ulong_t;
 /* Guest handles for primitive C types. */
 __DEFINE_GUEST_HANDLE(uchar, unsigned char);
 __DEFINE_GUEST_HANDLE(uint, unsigned int);
diff --git a/arch/x86/include/asm/xen/interface.h b/arch/x86/include/asm/xen/interface.h
index 555f94d..28fc621 100644
--- a/arch/x86/include/asm/xen/interface.h
+++ b/arch/x86/include/asm/xen/interface.h
@@ -51,6 +51,7 @@
  * with Xen so that on ARM we can have one ABI that works for 32 and 64
  * bit guests. */
 typedef unsigned long xen_pfn_t;
+typedef unsigned long xen_ulong_t;
 /* Guest handles for primitive C types. */
 __DEFINE_GUEST_HANDLE(uchar, unsigned char);
 __DEFINE_GUEST_HANDLE(uint,  unsigned int);
diff --git a/include/xen/interface/memory.h b/include/xen/interface/memory.h
index d8e33a9..b66d04c 100644
--- a/include/xen/interface/memory.h
+++ b/include/xen/interface/memory.h
@@ -34,7 +34,7 @@ struct xen_memory_reservation {
     GUEST_HANDLE(xen_pfn_t) extent_start;
 
     /* Number of extents, and size/alignment of each (2^extent_order pages). */
-    unsigned long  nr_extents;
+    xen_ulong_t  nr_extents;
     unsigned int   extent_order;
 
     /*
@@ -92,7 +92,7 @@ struct xen_memory_exchange {
      *     command will be non-zero.
      *  5. THIS FIELD MUST BE INITIALISED TO ZERO BY THE CALLER!
      */
-    unsigned long nr_exchanged;
+    xen_ulong_t nr_exchanged;
 };
 
 DEFINE_GUEST_HANDLE_STRUCT(xen_memory_exchange);
@@ -148,8 +148,8 @@ DEFINE_GUEST_HANDLE_STRUCT(xen_machphys_mfn_list);
  */
 #define XENMEM_machphys_mapping     12
 struct xen_machphys_mapping {
-    unsigned long v_start, v_end; /* Start and end virtual addresses.   */
-    unsigned long max_mfn;        /* Maximum MFN that can be looked up. */
+    xen_ulong_t v_start, v_end; /* Start and end virtual addresses.   */
+    xen_ulong_t max_mfn;        /* Maximum MFN that can be looked up. */
 };
 DEFINE_GUEST_HANDLE_STRUCT(xen_machphys_mapping_t);
 
@@ -172,7 +172,7 @@ struct xen_add_to_physmap {
     unsigned int space;
 
     /* Index into source mapping space. */
-    unsigned long idx;
+    xen_ulong_t idx;
 
     /* GPFN where the source mapping page should appear. */
     xen_pfn_t gpfn;
@@ -189,7 +189,7 @@ struct xen_translate_gpfn_list {
     domid_t domid;
 
     /* Length of list. */
-    unsigned long nr_gpfns;
+    xen_ulong_t nr_gpfns;
 
     /* List of GPFNs to translate. */
     GUEST_HANDLE(ulong) gpfn_list;
diff --git a/include/xen/interface/physdev.h b/include/xen/interface/physdev.h
index 9ce788d..f616514 100644
--- a/include/xen/interface/physdev.h
+++ b/include/xen/interface/physdev.h
@@ -56,7 +56,7 @@ struct physdev_eoi {
 #define PHYSDEVOP_pirq_eoi_gmfn_v2       28
 struct physdev_pirq_eoi_gmfn {
     /* IN */
-    unsigned long gmfn;
+    xen_ulong_t gmfn;
 };
 
 /*
diff --git a/include/xen/interface/version.h b/include/xen/interface/version.h
index dd58cf5..3030c81 100644
--- a/include/xen/interface/version.h
+++ b/include/xen/interface/version.h
@@ -45,7 +45,7 @@ struct xen_changeset_info {
 
 #define XENVER_platform_parameters 5
 struct xen_platform_parameters {
-    unsigned long virt_start;
+    xen_ulong_t virt_start;
 };
 
 #define XENVER_get_features 6
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 17 17:40:31 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 17:40:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDfJ1-0001tm-E3; Mon, 17 Sep 2012 17:40:23 +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 1TDfJ0-0001so-Bw
	for xen-devel@lists.xensource.com; Mon, 17 Sep 2012 17:40:22 +0000
Received: from [85.158.137.99:61714] by server-11.bemta-3.messagelabs.com id
	61/83-30250-58067505; Mon, 17 Sep 2012 17:40:21 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-11.tower-217.messagelabs.com!1347903619!16839862!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzAyMzE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1787 invoked from network); 17 Sep 2012 17:40:20 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-11.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Sep 2012 17:40:20 -0000
X-IronPort-AV: E=Sophos;i="4.80,437,1344211200"; d="scan'208";a="38105085"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Sep 2012 17:39:46 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Mon, 17 Sep 2012 13:39:45 -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 1TDfIE-0008AT-W7;
	Mon, 17 Sep 2012 18:39:35 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: <arnd@arndb.de>
Date: Mon, 17 Sep 2012 18:38:53 +0100
Message-ID: <1347903543-2135-7-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <alpine.DEB.2.02.1209171215490.29232@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1209171215490.29232@kaball.uk.xensource.com>
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com, linaro-dev@lists.linaro.org,
	Ian.Campbell@citrix.com, konrad.wilk@oracle.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	tim@xen.org, linux-kernel@vger.kernel.org,
	linux@arm.linux.org.uk, linux-arm-kernel@lists.infradead.org
Subject: [Xen-devel] [PATCH v5 07/17] xen/arm: Xen detection and shared_info
	page mapping
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Check for a node in the device tree compatible with "xen,xen", if it is
present set xen_domain_type to XEN_HVM_DOMAIN and continue
initialization.

Map the real shared info page using XENMEM_add_to_physmap with
XENMAPSPACE_shared_info.

Changes in v4:

- simpler parsing of Xen version in the compatible DT node.

Changes in v3:

- use the "xen,xen" notation rather than "arm,xen";
- add an additional check on the presence of the Xen version.

Changes in v2:

- replace pr_info with pr_debug.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 arch/arm/xen/enlighten.c |   61 ++++++++++++++++++++++++++++++++++++++++++++++
 1 files changed, 61 insertions(+), 0 deletions(-)

diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
index c535540..6a0217d 100644
--- a/arch/arm/xen/enlighten.c
+++ b/arch/arm/xen/enlighten.c
@@ -5,6 +5,9 @@
 #include <asm/xen/hypervisor.h>
 #include <asm/xen/hypercall.h>
 #include <linux/module.h>
+#include <linux/of.h>
+#include <linux/of_irq.h>
+#include <linux/of_address.h>
 
 struct start_info _xen_start_info;
 struct start_info *xen_start_info = &_xen_start_info;
@@ -33,3 +36,61 @@ int xen_remap_domain_mfn_range(struct vm_area_struct *vma,
 	return -ENOSYS;
 }
 EXPORT_SYMBOL_GPL(xen_remap_domain_mfn_range);
+
+/*
+ * see Documentation/devicetree/bindings/arm/xen.txt for the
+ * documentation of the Xen Device Tree format.
+ */
+static int __init xen_guest_init(void)
+{
+	struct xen_add_to_physmap xatp;
+	static struct shared_info *shared_info_page = 0;
+	struct device_node *node;
+	int len;
+	const char *s = NULL;
+	const char *version = NULL;
+	const char *xen_prefix = "xen,xen-";
+
+	node = of_find_compatible_node(NULL, NULL, "xen,xen");
+	if (!node) {
+		pr_debug("No Xen support\n");
+		return 0;
+	}
+	s = of_get_property(node, "compatible", &len);
+	if (strlen(xen_prefix) + 3  < len &&
+			!strncmp(xen_prefix, s, strlen(xen_prefix)))
+		version = s + strlen(xen_prefix);
+	if (version == NULL) {
+		pr_debug("Xen version not found\n");
+		return 0;
+	}
+	xen_domain_type = XEN_HVM_DOMAIN;
+
+	if (!shared_info_page)
+		shared_info_page = (struct shared_info *)
+			get_zeroed_page(GFP_KERNEL);
+	if (!shared_info_page) {
+		pr_err("not enough memory\n");
+		return -ENOMEM;
+	}
+	xatp.domid = DOMID_SELF;
+	xatp.idx = 0;
+	xatp.space = XENMAPSPACE_shared_info;
+	xatp.gpfn = __pa(shared_info_page) >> PAGE_SHIFT;
+	if (HYPERVISOR_memory_op(XENMEM_add_to_physmap, &xatp))
+		BUG();
+
+	HYPERVISOR_shared_info = (struct shared_info *)shared_info_page;
+
+	/* xen_vcpu is a pointer to the vcpu_info struct in the shared_info
+	 * page, we use it in the event channel upcall and in some pvclock
+	 * related functions. We don't need the vcpu_info placement
+	 * optimizations because we don't use any pv_mmu or pv_irq op on
+	 * HVM.
+	 * The shared info contains exactly 1 CPU (the boot CPU). The guest
+	 * is required to use VCPUOP_register_vcpu_info to place vcpu info
+	 * for secondary CPUs as they are brought up. */
+	per_cpu(xen_vcpu, 0) = &HYPERVISOR_shared_info->vcpu_info[0];
+	return 0;
+}
+core_initcall(xen_guest_init);
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 17 17:40:31 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 17:40:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDfJ1-0001tm-E3; Mon, 17 Sep 2012 17:40:23 +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 1TDfJ0-0001so-Bw
	for xen-devel@lists.xensource.com; Mon, 17 Sep 2012 17:40:22 +0000
Received: from [85.158.137.99:61714] by server-11.bemta-3.messagelabs.com id
	61/83-30250-58067505; Mon, 17 Sep 2012 17:40:21 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-11.tower-217.messagelabs.com!1347903619!16839862!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzAyMzE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1787 invoked from network); 17 Sep 2012 17:40:20 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-11.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Sep 2012 17:40:20 -0000
X-IronPort-AV: E=Sophos;i="4.80,437,1344211200"; d="scan'208";a="38105085"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Sep 2012 17:39:46 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Mon, 17 Sep 2012 13:39:45 -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 1TDfIE-0008AT-W7;
	Mon, 17 Sep 2012 18:39:35 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: <arnd@arndb.de>
Date: Mon, 17 Sep 2012 18:38:53 +0100
Message-ID: <1347903543-2135-7-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <alpine.DEB.2.02.1209171215490.29232@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1209171215490.29232@kaball.uk.xensource.com>
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com, linaro-dev@lists.linaro.org,
	Ian.Campbell@citrix.com, konrad.wilk@oracle.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	tim@xen.org, linux-kernel@vger.kernel.org,
	linux@arm.linux.org.uk, linux-arm-kernel@lists.infradead.org
Subject: [Xen-devel] [PATCH v5 07/17] xen/arm: Xen detection and shared_info
	page mapping
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Check for a node in the device tree compatible with "xen,xen", if it is
present set xen_domain_type to XEN_HVM_DOMAIN and continue
initialization.

Map the real shared info page using XENMEM_add_to_physmap with
XENMAPSPACE_shared_info.

Changes in v4:

- simpler parsing of Xen version in the compatible DT node.

Changes in v3:

- use the "xen,xen" notation rather than "arm,xen";
- add an additional check on the presence of the Xen version.

Changes in v2:

- replace pr_info with pr_debug.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 arch/arm/xen/enlighten.c |   61 ++++++++++++++++++++++++++++++++++++++++++++++
 1 files changed, 61 insertions(+), 0 deletions(-)

diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
index c535540..6a0217d 100644
--- a/arch/arm/xen/enlighten.c
+++ b/arch/arm/xen/enlighten.c
@@ -5,6 +5,9 @@
 #include <asm/xen/hypervisor.h>
 #include <asm/xen/hypercall.h>
 #include <linux/module.h>
+#include <linux/of.h>
+#include <linux/of_irq.h>
+#include <linux/of_address.h>
 
 struct start_info _xen_start_info;
 struct start_info *xen_start_info = &_xen_start_info;
@@ -33,3 +36,61 @@ int xen_remap_domain_mfn_range(struct vm_area_struct *vma,
 	return -ENOSYS;
 }
 EXPORT_SYMBOL_GPL(xen_remap_domain_mfn_range);
+
+/*
+ * see Documentation/devicetree/bindings/arm/xen.txt for the
+ * documentation of the Xen Device Tree format.
+ */
+static int __init xen_guest_init(void)
+{
+	struct xen_add_to_physmap xatp;
+	static struct shared_info *shared_info_page = 0;
+	struct device_node *node;
+	int len;
+	const char *s = NULL;
+	const char *version = NULL;
+	const char *xen_prefix = "xen,xen-";
+
+	node = of_find_compatible_node(NULL, NULL, "xen,xen");
+	if (!node) {
+		pr_debug("No Xen support\n");
+		return 0;
+	}
+	s = of_get_property(node, "compatible", &len);
+	if (strlen(xen_prefix) + 3  < len &&
+			!strncmp(xen_prefix, s, strlen(xen_prefix)))
+		version = s + strlen(xen_prefix);
+	if (version == NULL) {
+		pr_debug("Xen version not found\n");
+		return 0;
+	}
+	xen_domain_type = XEN_HVM_DOMAIN;
+
+	if (!shared_info_page)
+		shared_info_page = (struct shared_info *)
+			get_zeroed_page(GFP_KERNEL);
+	if (!shared_info_page) {
+		pr_err("not enough memory\n");
+		return -ENOMEM;
+	}
+	xatp.domid = DOMID_SELF;
+	xatp.idx = 0;
+	xatp.space = XENMAPSPACE_shared_info;
+	xatp.gpfn = __pa(shared_info_page) >> PAGE_SHIFT;
+	if (HYPERVISOR_memory_op(XENMEM_add_to_physmap, &xatp))
+		BUG();
+
+	HYPERVISOR_shared_info = (struct shared_info *)shared_info_page;
+
+	/* xen_vcpu is a pointer to the vcpu_info struct in the shared_info
+	 * page, we use it in the event channel upcall and in some pvclock
+	 * related functions. We don't need the vcpu_info placement
+	 * optimizations because we don't use any pv_mmu or pv_irq op on
+	 * HVM.
+	 * The shared info contains exactly 1 CPU (the boot CPU). The guest
+	 * is required to use VCPUOP_register_vcpu_info to place vcpu info
+	 * for secondary CPUs as they are brought up. */
+	per_cpu(xen_vcpu, 0) = &HYPERVISOR_shared_info->vcpu_info[0];
+	return 0;
+}
+core_initcall(xen_guest_init);
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 17 17:40:31 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 17:40:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDfJ4-0001vs-PR; Mon, 17 Sep 2012 17:40: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 1TDfJ3-0001tF-Hn
	for xen-devel@lists.xensource.com; Mon, 17 Sep 2012 17:40:25 +0000
Received: from [85.158.137.99:3401] by server-6.bemta-3.messagelabs.com id
	B9/8D-29694-98067505; Mon, 17 Sep 2012 17:40:25 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-11.tower-217.messagelabs.com!1347903619!16839862!4
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzAyMzE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2002 invoked from network); 17 Sep 2012 17:40:24 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-11.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Sep 2012 17:40:24 -0000
X-IronPort-AV: E=Sophos;i="4.80,437,1344211200"; d="scan'208";a="38105084"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Sep 2012 17:39:45 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Mon, 17 Sep 2012 13:39:45 -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 1TDfIF-0008AT-46;
	Mon, 17 Sep 2012 18:39:35 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: <arnd@arndb.de>
Date: Mon, 17 Sep 2012 18:38:56 +0100
Message-ID: <1347903543-2135-10-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <alpine.DEB.2.02.1209171215490.29232@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1209171215490.29232@kaball.uk.xensource.com>
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com, linaro-dev@lists.linaro.org,
	Ian.Campbell@citrix.com, Sergei Shtylyov <sshtylyov@mvista.com>,
	konrad.wilk@oracle.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	tim@xen.org, linux-kernel@vger.kernel.org,
	linux@arm.linux.org.uk, linux-arm-kernel@lists.infradead.org
Subject: [Xen-devel] [PATCH v5 10/17] xen/arm: introduce CONFIG_XEN on ARM
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Changes in v5:

- make XEN_DOM0 depend on XEN;
- avoid "select XEN_DOM0" in XEN.


Changes in v2:

- mark Xen guest support on ARM as EXPERIMENTAL.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
CC: Sergei Shtylyov <sshtylyov@mvista.com>
---
 arch/arm/Kconfig |   10 ++++++++++
 1 files changed, 10 insertions(+), 0 deletions(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 2f88d8d..3361466 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1897,6 +1897,16 @@ config DEPRECATED_PARAM_STRUCT
 	  This was deprecated in 2001 and announced to live on for 5 years.
 	  Some old boot loaders still use this way.
 
+config XEN_DOM0
+	def_bool y
+	depends on XEN
+
+config XEN
+	bool "Xen guest support on ARM (EXPERIMENTAL)"
+	depends on EXPERIMENTAL && ARM && OF
+	help
+	  Say Y if you want to run Linux in a Virtual Machine on Xen on ARM.
+
 endmenu
 
 menu "Boot options"
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 17 17:40:31 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 17:40:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDfJ4-0001vs-PR; Mon, 17 Sep 2012 17:40: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 1TDfJ3-0001tF-Hn
	for xen-devel@lists.xensource.com; Mon, 17 Sep 2012 17:40:25 +0000
Received: from [85.158.137.99:3401] by server-6.bemta-3.messagelabs.com id
	B9/8D-29694-98067505; Mon, 17 Sep 2012 17:40:25 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-11.tower-217.messagelabs.com!1347903619!16839862!4
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzAyMzE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2002 invoked from network); 17 Sep 2012 17:40:24 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-11.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Sep 2012 17:40:24 -0000
X-IronPort-AV: E=Sophos;i="4.80,437,1344211200"; d="scan'208";a="38105084"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Sep 2012 17:39:45 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Mon, 17 Sep 2012 13:39:45 -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 1TDfIF-0008AT-46;
	Mon, 17 Sep 2012 18:39:35 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: <arnd@arndb.de>
Date: Mon, 17 Sep 2012 18:38:56 +0100
Message-ID: <1347903543-2135-10-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <alpine.DEB.2.02.1209171215490.29232@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1209171215490.29232@kaball.uk.xensource.com>
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com, linaro-dev@lists.linaro.org,
	Ian.Campbell@citrix.com, Sergei Shtylyov <sshtylyov@mvista.com>,
	konrad.wilk@oracle.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	tim@xen.org, linux-kernel@vger.kernel.org,
	linux@arm.linux.org.uk, linux-arm-kernel@lists.infradead.org
Subject: [Xen-devel] [PATCH v5 10/17] xen/arm: introduce CONFIG_XEN on ARM
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Changes in v5:

- make XEN_DOM0 depend on XEN;
- avoid "select XEN_DOM0" in XEN.


Changes in v2:

- mark Xen guest support on ARM as EXPERIMENTAL.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
CC: Sergei Shtylyov <sshtylyov@mvista.com>
---
 arch/arm/Kconfig |   10 ++++++++++
 1 files changed, 10 insertions(+), 0 deletions(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 2f88d8d..3361466 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1897,6 +1897,16 @@ config DEPRECATED_PARAM_STRUCT
 	  This was deprecated in 2001 and announced to live on for 5 years.
 	  Some old boot loaders still use this way.
 
+config XEN_DOM0
+	def_bool y
+	depends on XEN
+
+config XEN
+	bool "Xen guest support on ARM (EXPERIMENTAL)"
+	depends on EXPERIMENTAL && ARM && OF
+	help
+	  Say Y if you want to run Linux in a Virtual Machine on Xen on ARM.
+
 endmenu
 
 menu "Boot options"
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 17 17:40:31 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 17:40:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDfJ4-0001vW-Bo; Mon, 17 Sep 2012 17:40: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 1TDfJ3-0001uU-6B
	for xen-devel@lists.xensource.com; Mon, 17 Sep 2012 17:40:25 +0000
Received: from [85.158.137.99:61011] by server-1.bemta-3.messagelabs.com id
	92/D0-05884-88067505; Mon, 17 Sep 2012 17:40:24 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-11.tower-217.messagelabs.com!1347903619!16839862!3
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzAyMzE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1968 invoked from network); 17 Sep 2012 17:40:23 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-11.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Sep 2012 17:40:23 -0000
X-IronPort-AV: E=Sophos;i="4.80,437,1344211200"; d="scan'208";a="38105083"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Sep 2012 17:39:45 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Mon, 17 Sep 2012 13:39:45 -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 1TDfIF-0008AT-3U;
	Mon, 17 Sep 2012 18:39:35 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: <arnd@arndb.de>
Date: Mon, 17 Sep 2012 18:38:55 +0100
Message-ID: <1347903543-2135-9-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <alpine.DEB.2.02.1209171215490.29232@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1209171215490.29232@kaball.uk.xensource.com>
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com, linaro-dev@lists.linaro.org,
	Ian.Campbell@citrix.com, konrad.wilk@oracle.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	tim@xen.org, linux-kernel@vger.kernel.org,
	linux@arm.linux.org.uk, linux-arm-kernel@lists.infradead.org
Subject: [Xen-devel] [PATCH v5 09/17] xen: do not compile manage, balloon,
	pci, acpi, pcpu and cpu_hotplug on ARM
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Changes in v4:
- compile pcpu only on x86;
- use "+=" instead of ":=" for dom0- targets.

Changes in v2:

- make pci.o depend on CONFIG_PCI and acpi.o depend on CONFIG_ACPI.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 drivers/xen/Makefile |   13 +++++++++----
 1 files changed, 9 insertions(+), 4 deletions(-)

diff --git a/drivers/xen/Makefile b/drivers/xen/Makefile
index d80bea5..cd28aae 100644
--- a/drivers/xen/Makefile
+++ b/drivers/xen/Makefile
@@ -1,11 +1,18 @@
-obj-y	+= grant-table.o features.o events.o manage.o balloon.o
+ifneq ($(CONFIG_ARM),y)
+obj-y	+= manage.o balloon.o
+obj-$(CONFIG_HOTPLUG_CPU)		+= cpu_hotplug.o
+endif
+obj-y	+= grant-table.o features.o events.o
 obj-y	+= xenbus/
 
 nostackp := $(call cc-option, -fno-stack-protector)
 CFLAGS_features.o			:= $(nostackp)
 
+obj-$(CONFIG_XEN_DOM0)			+= $(dom0-y)
+dom0-$(CONFIG_PCI) += pci.o
+dom0-$(CONFIG_ACPI) += acpi.o
+dom0-$(CONFIG_X86) += pcpu.o
 obj-$(CONFIG_BLOCK)			+= biomerge.o
-obj-$(CONFIG_HOTPLUG_CPU)		+= cpu_hotplug.o
 obj-$(CONFIG_XEN_XENCOMM)		+= xencomm.o
 obj-$(CONFIG_XEN_BALLOON)		+= xen-balloon.o
 obj-$(CONFIG_XEN_SELFBALLOONING)	+= xen-selfballoon.o
@@ -17,8 +24,6 @@ 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/
 obj-$(CONFIG_XEN_PRIVCMD)		+= xen-privcmd.o
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 17 17:40:31 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 17:40:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDfJ4-0001vW-Bo; Mon, 17 Sep 2012 17:40: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 1TDfJ3-0001uU-6B
	for xen-devel@lists.xensource.com; Mon, 17 Sep 2012 17:40:25 +0000
Received: from [85.158.137.99:61011] by server-1.bemta-3.messagelabs.com id
	92/D0-05884-88067505; Mon, 17 Sep 2012 17:40:24 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-11.tower-217.messagelabs.com!1347903619!16839862!3
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzAyMzE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1968 invoked from network); 17 Sep 2012 17:40:23 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-11.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Sep 2012 17:40:23 -0000
X-IronPort-AV: E=Sophos;i="4.80,437,1344211200"; d="scan'208";a="38105083"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Sep 2012 17:39:45 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Mon, 17 Sep 2012 13:39:45 -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 1TDfIF-0008AT-3U;
	Mon, 17 Sep 2012 18:39:35 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: <arnd@arndb.de>
Date: Mon, 17 Sep 2012 18:38:55 +0100
Message-ID: <1347903543-2135-9-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <alpine.DEB.2.02.1209171215490.29232@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1209171215490.29232@kaball.uk.xensource.com>
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com, linaro-dev@lists.linaro.org,
	Ian.Campbell@citrix.com, konrad.wilk@oracle.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	tim@xen.org, linux-kernel@vger.kernel.org,
	linux@arm.linux.org.uk, linux-arm-kernel@lists.infradead.org
Subject: [Xen-devel] [PATCH v5 09/17] xen: do not compile manage, balloon,
	pci, acpi, pcpu and cpu_hotplug on ARM
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Changes in v4:
- compile pcpu only on x86;
- use "+=" instead of ":=" for dom0- targets.

Changes in v2:

- make pci.o depend on CONFIG_PCI and acpi.o depend on CONFIG_ACPI.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 drivers/xen/Makefile |   13 +++++++++----
 1 files changed, 9 insertions(+), 4 deletions(-)

diff --git a/drivers/xen/Makefile b/drivers/xen/Makefile
index d80bea5..cd28aae 100644
--- a/drivers/xen/Makefile
+++ b/drivers/xen/Makefile
@@ -1,11 +1,18 @@
-obj-y	+= grant-table.o features.o events.o manage.o balloon.o
+ifneq ($(CONFIG_ARM),y)
+obj-y	+= manage.o balloon.o
+obj-$(CONFIG_HOTPLUG_CPU)		+= cpu_hotplug.o
+endif
+obj-y	+= grant-table.o features.o events.o
 obj-y	+= xenbus/
 
 nostackp := $(call cc-option, -fno-stack-protector)
 CFLAGS_features.o			:= $(nostackp)
 
+obj-$(CONFIG_XEN_DOM0)			+= $(dom0-y)
+dom0-$(CONFIG_PCI) += pci.o
+dom0-$(CONFIG_ACPI) += acpi.o
+dom0-$(CONFIG_X86) += pcpu.o
 obj-$(CONFIG_BLOCK)			+= biomerge.o
-obj-$(CONFIG_HOTPLUG_CPU)		+= cpu_hotplug.o
 obj-$(CONFIG_XEN_XENCOMM)		+= xencomm.o
 obj-$(CONFIG_XEN_BALLOON)		+= xen-balloon.o
 obj-$(CONFIG_XEN_SELFBALLOONING)	+= xen-selfballoon.o
@@ -17,8 +24,6 @@ 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/
 obj-$(CONFIG_XEN_PRIVCMD)		+= xen-privcmd.o
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 17 17:41:09 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 17: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 1TDfJg-0002L0-76; Mon, 17 Sep 2012 17:41:04 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1TDfJe-0002Jq-NK
	for xen-devel@lists.xensource.com; Mon, 17 Sep 2012 17:41:02 +0000
Received: from [85.158.143.35:26015] by server-2.bemta-4.messagelabs.com id
	BF/C5-06610-EA067505; Mon, 17 Sep 2012 17:41:02 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1347903658!6925412!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNzUxNjg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1887 invoked from network); 17 Sep 2012 17:41:00 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-4.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Sep 2012 17:41:00 -0000
X-IronPort-AV: E=Sophos;i="4.80,437,1344211200"; d="scan'208";a="208319440"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Sep 2012 17:40:58 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Mon, 17 Sep 2012 13:40:57 -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 1TDfIF-0008AT-8t;
	Mon, 17 Sep 2012 18:39:35 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: <arnd@arndb.de>
Date: Mon, 17 Sep 2012 18:39:02 +0100
Message-ID: <1347903543-2135-16-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <alpine.DEB.2.02.1209171215490.29232@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1209171215490.29232@kaball.uk.xensource.com>
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com, linaro-dev@lists.linaro.org,
	Ian.Campbell@citrix.com, konrad.wilk@oracle.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	tim@xen.org, linux-kernel@vger.kernel.org,
	linux@arm.linux.org.uk, linux-arm-kernel@lists.infradead.org
Subject: [Xen-devel] [PATCH v5 16/17] xen/arm: compile netback
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="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>
Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 arch/arm/include/asm/xen/hypercall.h |   19 +++++++++++++++++++
 drivers/net/xen-netback/netback.c    |    1 +
 drivers/net/xen-netfront.c           |    1 +
 3 files changed, 21 insertions(+), 0 deletions(-)

diff --git a/arch/arm/include/asm/xen/hypercall.h b/arch/arm/include/asm/xen/hypercall.h
index 4ac0624..8a82325 100644
--- a/arch/arm/include/asm/xen/hypercall.h
+++ b/arch/arm/include/asm/xen/hypercall.h
@@ -47,4 +47,23 @@ unsigned long HYPERVISOR_hvm_op(int op, void *arg);
 int HYPERVISOR_memory_op(unsigned int cmd, void *arg);
 int HYPERVISOR_physdev_op(int cmd, void *arg);
 
+static inline void
+MULTI_update_va_mapping(struct multicall_entry *mcl, unsigned long va,
+			unsigned int new_val, unsigned long flags)
+{
+	BUG();
+}
+
+static inline void
+MULTI_mmu_update(struct multicall_entry *mcl, struct mmu_update *req,
+		 int count, int *success_count, domid_t domid)
+{
+	BUG();
+}
+
+static inline int
+HYPERVISOR_multicall(void *call_list, int nr_calls)
+{
+	BUG();
+}
 #endif /* _ASM_ARM_XEN_HYPERCALL_H */
diff --git a/drivers/net/xen-netback/netback.c b/drivers/net/xen-netback/netback.c
index 682633b..1c0a302 100644
--- a/drivers/net/xen-netback/netback.c
+++ b/drivers/net/xen-netback/netback.c
@@ -40,6 +40,7 @@
 
 #include <net/tcp.h>
 
+#include <xen/xen.h>
 #include <xen/events.h>
 #include <xen/interface/memory.h>
 
diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c
index 650f79a..24d968d 100644
--- a/drivers/net/xen-netfront.c
+++ b/drivers/net/xen-netfront.c
@@ -43,6 +43,7 @@
 #include <linux/slab.h>
 #include <net/ip.h>
 
+#include <asm/xen/page.h>
 #include <xen/xen.h>
 #include <xen/xenbus.h>
 #include <xen/events.h>
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 17 17:41:09 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 17: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 1TDfJg-0002L0-76; Mon, 17 Sep 2012 17:41:04 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1TDfJe-0002Jq-NK
	for xen-devel@lists.xensource.com; Mon, 17 Sep 2012 17:41:02 +0000
Received: from [85.158.143.35:26015] by server-2.bemta-4.messagelabs.com id
	BF/C5-06610-EA067505; Mon, 17 Sep 2012 17:41:02 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1347903658!6925412!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNzUxNjg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1887 invoked from network); 17 Sep 2012 17:41:00 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-4.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Sep 2012 17:41:00 -0000
X-IronPort-AV: E=Sophos;i="4.80,437,1344211200"; d="scan'208";a="208319440"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Sep 2012 17:40:58 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Mon, 17 Sep 2012 13:40:57 -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 1TDfIF-0008AT-8t;
	Mon, 17 Sep 2012 18:39:35 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: <arnd@arndb.de>
Date: Mon, 17 Sep 2012 18:39:02 +0100
Message-ID: <1347903543-2135-16-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <alpine.DEB.2.02.1209171215490.29232@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1209171215490.29232@kaball.uk.xensource.com>
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com, linaro-dev@lists.linaro.org,
	Ian.Campbell@citrix.com, konrad.wilk@oracle.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	tim@xen.org, linux-kernel@vger.kernel.org,
	linux@arm.linux.org.uk, linux-arm-kernel@lists.infradead.org
Subject: [Xen-devel] [PATCH v5 16/17] xen/arm: compile netback
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="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>
Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 arch/arm/include/asm/xen/hypercall.h |   19 +++++++++++++++++++
 drivers/net/xen-netback/netback.c    |    1 +
 drivers/net/xen-netfront.c           |    1 +
 3 files changed, 21 insertions(+), 0 deletions(-)

diff --git a/arch/arm/include/asm/xen/hypercall.h b/arch/arm/include/asm/xen/hypercall.h
index 4ac0624..8a82325 100644
--- a/arch/arm/include/asm/xen/hypercall.h
+++ b/arch/arm/include/asm/xen/hypercall.h
@@ -47,4 +47,23 @@ unsigned long HYPERVISOR_hvm_op(int op, void *arg);
 int HYPERVISOR_memory_op(unsigned int cmd, void *arg);
 int HYPERVISOR_physdev_op(int cmd, void *arg);
 
+static inline void
+MULTI_update_va_mapping(struct multicall_entry *mcl, unsigned long va,
+			unsigned int new_val, unsigned long flags)
+{
+	BUG();
+}
+
+static inline void
+MULTI_mmu_update(struct multicall_entry *mcl, struct mmu_update *req,
+		 int count, int *success_count, domid_t domid)
+{
+	BUG();
+}
+
+static inline int
+HYPERVISOR_multicall(void *call_list, int nr_calls)
+{
+	BUG();
+}
 #endif /* _ASM_ARM_XEN_HYPERCALL_H */
diff --git a/drivers/net/xen-netback/netback.c b/drivers/net/xen-netback/netback.c
index 682633b..1c0a302 100644
--- a/drivers/net/xen-netback/netback.c
+++ b/drivers/net/xen-netback/netback.c
@@ -40,6 +40,7 @@
 
 #include <net/tcp.h>
 
+#include <xen/xen.h>
 #include <xen/events.h>
 #include <xen/interface/memory.h>
 
diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c
index 650f79a..24d968d 100644
--- a/drivers/net/xen-netfront.c
+++ b/drivers/net/xen-netfront.c
@@ -43,6 +43,7 @@
 #include <linux/slab.h>
 #include <net/ip.h>
 
+#include <asm/xen/page.h>
 #include <xen/xen.h>
 #include <xen/xenbus.h>
 #include <xen/events.h>
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 17 17:41:18 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 17: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 1TDfJr-0002Sn-9o; Mon, 17 Sep 2012 17:41:15 +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 1TDfJp-0002Ql-Cw
	for xen-devel@lists.xensource.com; Mon, 17 Sep 2012 17:41:13 +0000
Received: from [85.158.139.83:7912] by server-12.bemta-5.messagelabs.com id
	08/62-19338-8B067505; Mon, 17 Sep 2012 17:41:12 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1347903669!30740402!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzAyMzE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2910 invoked from network); 17 Sep 2012 17:41:12 -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;
	17 Sep 2012 17:41:12 -0000
X-IronPort-AV: E=Sophos;i="4.80,437,1344211200"; d="scan'208";a="38105199"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Sep 2012 17:40:52 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Mon, 17 Sep 2012 13:40:51 -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 1TDfIF-0008AT-8I;
	Mon, 17 Sep 2012 18:39:35 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: <arnd@arndb.de>
Date: Mon, 17 Sep 2012 18:39:01 +0100
Message-ID: <1347903543-2135-15-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <alpine.DEB.2.02.1209171215490.29232@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1209171215490.29232@kaball.uk.xensource.com>
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com, linaro-dev@lists.linaro.org,
	Ian.Campbell@citrix.com, konrad.wilk@oracle.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	tim@xen.org, linux-kernel@vger.kernel.org,
	linux@arm.linux.org.uk, linux-arm-kernel@lists.infradead.org
Subject: [Xen-devel] [PATCH v5 15/17] xen/arm: compile blkfront and blkback
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="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>
Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 drivers/block/xen-blkback/blkback.c  |    1 +
 include/xen/interface/io/protocols.h |    3 +++
 2 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/drivers/block/xen-blkback/blkback.c b/drivers/block/xen-blkback/blkback.c
index 73f196c..63dd5b9 100644
--- a/drivers/block/xen-blkback/blkback.c
+++ b/drivers/block/xen-blkback/blkback.c
@@ -42,6 +42,7 @@
 
 #include <xen/events.h>
 #include <xen/page.h>
+#include <xen/xen.h>
 #include <asm/xen/hypervisor.h>
 #include <asm/xen/hypercall.h>
 #include "common.h"
diff --git a/include/xen/interface/io/protocols.h b/include/xen/interface/io/protocols.h
index 01fc8ae..0eafaf2 100644
--- a/include/xen/interface/io/protocols.h
+++ b/include/xen/interface/io/protocols.h
@@ -5,6 +5,7 @@
 #define XEN_IO_PROTO_ABI_X86_64     "x86_64-abi"
 #define XEN_IO_PROTO_ABI_IA64       "ia64-abi"
 #define XEN_IO_PROTO_ABI_POWERPC64  "powerpc64-abi"
+#define XEN_IO_PROTO_ABI_ARM        "arm-abi"
 
 #if defined(__i386__)
 # define XEN_IO_PROTO_ABI_NATIVE XEN_IO_PROTO_ABI_X86_32
@@ -14,6 +15,8 @@
 # define XEN_IO_PROTO_ABI_NATIVE XEN_IO_PROTO_ABI_IA64
 #elif defined(__powerpc64__)
 # define XEN_IO_PROTO_ABI_NATIVE XEN_IO_PROTO_ABI_POWERPC64
+#elif defined(__arm__)
+# define XEN_IO_PROTO_ABI_NATIVE XEN_IO_PROTO_ABI_ARM
 #else
 # error arch fixup needed here
 #endif
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 17 17:41:18 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 17: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 1TDfJr-0002Sn-9o; Mon, 17 Sep 2012 17:41:15 +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 1TDfJp-0002Ql-Cw
	for xen-devel@lists.xensource.com; Mon, 17 Sep 2012 17:41:13 +0000
Received: from [85.158.139.83:7912] by server-12.bemta-5.messagelabs.com id
	08/62-19338-8B067505; Mon, 17 Sep 2012 17:41:12 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1347903669!30740402!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzAyMzE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2910 invoked from network); 17 Sep 2012 17:41:12 -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;
	17 Sep 2012 17:41:12 -0000
X-IronPort-AV: E=Sophos;i="4.80,437,1344211200"; d="scan'208";a="38105199"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Sep 2012 17:40:52 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Mon, 17 Sep 2012 13:40:51 -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 1TDfIF-0008AT-8I;
	Mon, 17 Sep 2012 18:39:35 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: <arnd@arndb.de>
Date: Mon, 17 Sep 2012 18:39:01 +0100
Message-ID: <1347903543-2135-15-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <alpine.DEB.2.02.1209171215490.29232@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1209171215490.29232@kaball.uk.xensource.com>
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com, linaro-dev@lists.linaro.org,
	Ian.Campbell@citrix.com, konrad.wilk@oracle.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	tim@xen.org, linux-kernel@vger.kernel.org,
	linux@arm.linux.org.uk, linux-arm-kernel@lists.infradead.org
Subject: [Xen-devel] [PATCH v5 15/17] xen/arm: compile blkfront and blkback
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="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>
Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 drivers/block/xen-blkback/blkback.c  |    1 +
 include/xen/interface/io/protocols.h |    3 +++
 2 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/drivers/block/xen-blkback/blkback.c b/drivers/block/xen-blkback/blkback.c
index 73f196c..63dd5b9 100644
--- a/drivers/block/xen-blkback/blkback.c
+++ b/drivers/block/xen-blkback/blkback.c
@@ -42,6 +42,7 @@
 
 #include <xen/events.h>
 #include <xen/page.h>
+#include <xen/xen.h>
 #include <asm/xen/hypervisor.h>
 #include <asm/xen/hypercall.h>
 #include "common.h"
diff --git a/include/xen/interface/io/protocols.h b/include/xen/interface/io/protocols.h
index 01fc8ae..0eafaf2 100644
--- a/include/xen/interface/io/protocols.h
+++ b/include/xen/interface/io/protocols.h
@@ -5,6 +5,7 @@
 #define XEN_IO_PROTO_ABI_X86_64     "x86_64-abi"
 #define XEN_IO_PROTO_ABI_IA64       "ia64-abi"
 #define XEN_IO_PROTO_ABI_POWERPC64  "powerpc64-abi"
+#define XEN_IO_PROTO_ABI_ARM        "arm-abi"
 
 #if defined(__i386__)
 # define XEN_IO_PROTO_ABI_NATIVE XEN_IO_PROTO_ABI_X86_32
@@ -14,6 +15,8 @@
 # define XEN_IO_PROTO_ABI_NATIVE XEN_IO_PROTO_ABI_IA64
 #elif defined(__powerpc64__)
 # define XEN_IO_PROTO_ABI_NATIVE XEN_IO_PROTO_ABI_POWERPC64
+#elif defined(__arm__)
+# define XEN_IO_PROTO_ABI_NATIVE XEN_IO_PROTO_ABI_ARM
 #else
 # error arch fixup needed here
 #endif
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 17 17:41:18 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 17: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 1TDfJr-0002TL-Mu; Mon, 17 Sep 2012 17:41: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 1TDfJq-0002RF-0Z
	for xen-devel@lists.xensource.com; Mon, 17 Sep 2012 17:41:14 +0000
Received: from [85.158.138.51:15673] by server-1.bemta-3.messagelabs.com id
	8D/91-05884-9B067505; Mon, 17 Sep 2012 17:41:13 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1347903670!23302041!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNzUxNjg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32662 invoked from network); 17 Sep 2012 17:41:12 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-10.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Sep 2012 17:41:12 -0000
X-IronPort-AV: E=Sophos;i="4.80,437,1344211200"; d="scan'208";a="208319469"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Sep 2012 17:41:10 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Mon, 17 Sep 2012 13:41:09 -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 1TDfIF-0008AT-7k;
	Mon, 17 Sep 2012 18:39:35 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: <arnd@arndb.de>
Date: Mon, 17 Sep 2012 18:39:00 +0100
Message-ID: <1347903543-2135-14-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <alpine.DEB.2.02.1209171215490.29232@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1209171215490.29232@kaball.uk.xensource.com>
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com, linaro-dev@lists.linaro.org,
	Ian.Campbell@citrix.com, konrad.wilk@oracle.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	tim@xen.org, linux-kernel@vger.kernel.org,
	linux@arm.linux.org.uk, linux-arm-kernel@lists.infradead.org
Subject: [Xen-devel] [PATCH v5 14/17] xen/arm: implement
	alloc/free_xenballooned_pages with alloc_pages/kfree
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Only until we get the balloon driver to work.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 arch/arm/xen/enlighten.c |   18 ++++++++++++++++++
 1 files changed, 18 insertions(+), 0 deletions(-)

diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
index bad67ad..59bcb96 100644
--- a/arch/arm/xen/enlighten.c
+++ b/arch/arm/xen/enlighten.c
@@ -148,3 +148,21 @@ static int __init xen_init_events(void)
 	return 0;
 }
 postcore_initcall(xen_init_events);
+
+/* XXX: only until balloon is properly working */
+int alloc_xenballooned_pages(int nr_pages, struct page **pages, bool highmem)
+{
+	*pages = alloc_pages(highmem ? GFP_HIGHUSER : GFP_KERNEL,
+			get_order(nr_pages));
+	if (*pages == NULL)
+		return -ENOMEM;
+	return 0;
+}
+EXPORT_SYMBOL_GPL(alloc_xenballooned_pages);
+
+void free_xenballooned_pages(int nr_pages, struct page **pages)
+{
+	kfree(*pages);
+	*pages = NULL;
+}
+EXPORT_SYMBOL_GPL(free_xenballooned_pages);
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 17 17:41:18 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 17: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 1TDfJr-0002TL-Mu; Mon, 17 Sep 2012 17:41: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 1TDfJq-0002RF-0Z
	for xen-devel@lists.xensource.com; Mon, 17 Sep 2012 17:41:14 +0000
Received: from [85.158.138.51:15673] by server-1.bemta-3.messagelabs.com id
	8D/91-05884-9B067505; Mon, 17 Sep 2012 17:41:13 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1347903670!23302041!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNzUxNjg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32662 invoked from network); 17 Sep 2012 17:41:12 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-10.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Sep 2012 17:41:12 -0000
X-IronPort-AV: E=Sophos;i="4.80,437,1344211200"; d="scan'208";a="208319469"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Sep 2012 17:41:10 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Mon, 17 Sep 2012 13:41:09 -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 1TDfIF-0008AT-7k;
	Mon, 17 Sep 2012 18:39:35 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: <arnd@arndb.de>
Date: Mon, 17 Sep 2012 18:39:00 +0100
Message-ID: <1347903543-2135-14-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <alpine.DEB.2.02.1209171215490.29232@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1209171215490.29232@kaball.uk.xensource.com>
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com, linaro-dev@lists.linaro.org,
	Ian.Campbell@citrix.com, konrad.wilk@oracle.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	tim@xen.org, linux-kernel@vger.kernel.org,
	linux@arm.linux.org.uk, linux-arm-kernel@lists.infradead.org
Subject: [Xen-devel] [PATCH v5 14/17] xen/arm: implement
	alloc/free_xenballooned_pages with alloc_pages/kfree
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Only until we get the balloon driver to work.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 arch/arm/xen/enlighten.c |   18 ++++++++++++++++++
 1 files changed, 18 insertions(+), 0 deletions(-)

diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
index bad67ad..59bcb96 100644
--- a/arch/arm/xen/enlighten.c
+++ b/arch/arm/xen/enlighten.c
@@ -148,3 +148,21 @@ static int __init xen_init_events(void)
 	return 0;
 }
 postcore_initcall(xen_init_events);
+
+/* XXX: only until balloon is properly working */
+int alloc_xenballooned_pages(int nr_pages, struct page **pages, bool highmem)
+{
+	*pages = alloc_pages(highmem ? GFP_HIGHUSER : GFP_KERNEL,
+			get_order(nr_pages));
+	if (*pages == NULL)
+		return -ENOMEM;
+	return 0;
+}
+EXPORT_SYMBOL_GPL(alloc_xenballooned_pages);
+
+void free_xenballooned_pages(int nr_pages, struct page **pages)
+{
+	kfree(*pages);
+	*pages = NULL;
+}
+EXPORT_SYMBOL_GPL(free_xenballooned_pages);
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 17 17:41:20 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 17:41:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDfJp-0002Rb-S0; Mon, 17 Sep 2012 17:41: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 1TDfJo-0002QN-VH
	for xen-devel@lists.xensource.com; Mon, 17 Sep 2012 17:41:13 +0000
Received: from [85.158.139.83:50229] by server-7.bemta-5.messagelabs.com id
	4A/E6-19703-8B067505; Mon, 17 Sep 2012 17:41:12 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1347903669!30740402!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzAyMzE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2894 invoked from network); 17 Sep 2012 17:41:11 -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;
	17 Sep 2012 17:41:11 -0000
X-IronPort-AV: E=Sophos;i="4.80,437,1344211200"; d="scan'208";a="38105188"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Sep 2012 17:40:46 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Mon, 17 Sep 2012 13:40:45 -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 1TDfIF-0008AT-5I;
	Mon, 17 Sep 2012 18:39:35 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: <arnd@arndb.de>
Date: Mon, 17 Sep 2012 18:38:58 +0100
Message-ID: <1347903543-2135-12-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <alpine.DEB.2.02.1209171215490.29232@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1209171215490.29232@kaball.uk.xensource.com>
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com, linaro-dev@lists.linaro.org,
	Ian.Campbell@citrix.com, konrad.wilk@oracle.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	tim@xen.org, linux-kernel@vger.kernel.org,
	linux@arm.linux.org.uk, linux-arm-kernel@lists.infradead.org
Subject: [Xen-devel] [PATCH v5 12/17] xen/arm: initialize grant_table on ARM
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Initialize the grant table mapping at the address specified at index 0
in the DT under the /xen node.
After the grant table is initialized, call xenbus_probe (if not dom0).

Changes in v2:

- introduce GRANT_TABLE_PHYSADDR;
- remove unneeded initialization of boot_max_nr_grant_frames.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 arch/arm/xen/enlighten.c |   14 ++++++++++++++
 1 files changed, 14 insertions(+), 0 deletions(-)

diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
index c2a47a7..036a4d8 100644
--- a/arch/arm/xen/enlighten.c
+++ b/arch/arm/xen/enlighten.c
@@ -1,8 +1,12 @@
 #include <xen/xen.h>
+#include <xen/grant_table.h>
+#include <xen/hvm.h>
 #include <xen/interface/xen.h>
 #include <xen/interface/memory.h>
+#include <xen/interface/hvm/params.h>
 #include <xen/features.h>
 #include <xen/platform_pci.h>
+#include <xen/xenbus.h>
 #include <asm/xen/hypervisor.h>
 #include <asm/xen/hypercall.h>
 #include <linux/module.h>
@@ -42,6 +46,7 @@ EXPORT_SYMBOL_GPL(xen_remap_domain_mfn_range);
  * see Documentation/devicetree/bindings/arm/xen.txt for the
  * documentation of the Xen Device Tree format.
  */
+#define GRANT_TABLE_PHYSADDR 0
 static int __init xen_guest_init(void)
 {
 	struct xen_add_to_physmap xatp;
@@ -51,6 +56,7 @@ static int __init xen_guest_init(void)
 	const char *s = NULL;
 	const char *version = NULL;
 	const char *xen_prefix = "xen,xen-";
+	struct resource res;
 
 	node = of_find_compatible_node(NULL, NULL, "xen,xen");
 	if (!node) {
@@ -65,6 +71,9 @@ static int __init xen_guest_init(void)
 		pr_debug("Xen version not found\n");
 		return 0;
 	}
+	if (of_address_to_resource(node, GRANT_TABLE_PHYSADDR, &res))
+		return 0;
+	xen_hvm_resume_frames = res.start >> PAGE_SHIFT;
 	xen_domain_type = XEN_HVM_DOMAIN;
 
 	xen_setup_features();
@@ -98,6 +107,11 @@ static int __init xen_guest_init(void)
 	 * is required to use VCPUOP_register_vcpu_info to place vcpu info
 	 * for secondary CPUs as they are brought up. */
 	per_cpu(xen_vcpu, 0) = &HYPERVISOR_shared_info->vcpu_info[0];
+
+	gnttab_init();
+	if (!xen_initial_domain())
+		xenbus_probe(NULL);
+
 	return 0;
 }
 core_initcall(xen_guest_init);
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 17 17:41:20 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 17:41:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDfJp-0002Rb-S0; Mon, 17 Sep 2012 17:41: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 1TDfJo-0002QN-VH
	for xen-devel@lists.xensource.com; Mon, 17 Sep 2012 17:41:13 +0000
Received: from [85.158.139.83:50229] by server-7.bemta-5.messagelabs.com id
	4A/E6-19703-8B067505; Mon, 17 Sep 2012 17:41:12 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1347903669!30740402!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzAyMzE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2894 invoked from network); 17 Sep 2012 17:41:11 -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;
	17 Sep 2012 17:41:11 -0000
X-IronPort-AV: E=Sophos;i="4.80,437,1344211200"; d="scan'208";a="38105188"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Sep 2012 17:40:46 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Mon, 17 Sep 2012 13:40:45 -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 1TDfIF-0008AT-5I;
	Mon, 17 Sep 2012 18:39:35 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: <arnd@arndb.de>
Date: Mon, 17 Sep 2012 18:38:58 +0100
Message-ID: <1347903543-2135-12-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <alpine.DEB.2.02.1209171215490.29232@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1209171215490.29232@kaball.uk.xensource.com>
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com, linaro-dev@lists.linaro.org,
	Ian.Campbell@citrix.com, konrad.wilk@oracle.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	tim@xen.org, linux-kernel@vger.kernel.org,
	linux@arm.linux.org.uk, linux-arm-kernel@lists.infradead.org
Subject: [Xen-devel] [PATCH v5 12/17] xen/arm: initialize grant_table on ARM
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Initialize the grant table mapping at the address specified at index 0
in the DT under the /xen node.
After the grant table is initialized, call xenbus_probe (if not dom0).

Changes in v2:

- introduce GRANT_TABLE_PHYSADDR;
- remove unneeded initialization of boot_max_nr_grant_frames.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 arch/arm/xen/enlighten.c |   14 ++++++++++++++
 1 files changed, 14 insertions(+), 0 deletions(-)

diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
index c2a47a7..036a4d8 100644
--- a/arch/arm/xen/enlighten.c
+++ b/arch/arm/xen/enlighten.c
@@ -1,8 +1,12 @@
 #include <xen/xen.h>
+#include <xen/grant_table.h>
+#include <xen/hvm.h>
 #include <xen/interface/xen.h>
 #include <xen/interface/memory.h>
+#include <xen/interface/hvm/params.h>
 #include <xen/features.h>
 #include <xen/platform_pci.h>
+#include <xen/xenbus.h>
 #include <asm/xen/hypervisor.h>
 #include <asm/xen/hypercall.h>
 #include <linux/module.h>
@@ -42,6 +46,7 @@ EXPORT_SYMBOL_GPL(xen_remap_domain_mfn_range);
  * see Documentation/devicetree/bindings/arm/xen.txt for the
  * documentation of the Xen Device Tree format.
  */
+#define GRANT_TABLE_PHYSADDR 0
 static int __init xen_guest_init(void)
 {
 	struct xen_add_to_physmap xatp;
@@ -51,6 +56,7 @@ static int __init xen_guest_init(void)
 	const char *s = NULL;
 	const char *version = NULL;
 	const char *xen_prefix = "xen,xen-";
+	struct resource res;
 
 	node = of_find_compatible_node(NULL, NULL, "xen,xen");
 	if (!node) {
@@ -65,6 +71,9 @@ static int __init xen_guest_init(void)
 		pr_debug("Xen version not found\n");
 		return 0;
 	}
+	if (of_address_to_resource(node, GRANT_TABLE_PHYSADDR, &res))
+		return 0;
+	xen_hvm_resume_frames = res.start >> PAGE_SHIFT;
 	xen_domain_type = XEN_HVM_DOMAIN;
 
 	xen_setup_features();
@@ -98,6 +107,11 @@ static int __init xen_guest_init(void)
 	 * is required to use VCPUOP_register_vcpu_info to place vcpu info
 	 * for secondary CPUs as they are brought up. */
 	per_cpu(xen_vcpu, 0) = &HYPERVISOR_shared_info->vcpu_info[0];
+
+	gnttab_init();
+	if (!xen_initial_domain())
+		xenbus_probe(NULL);
+
 	return 0;
 }
 core_initcall(xen_guest_init);
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 17 17:41:20 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 17:41:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDfJt-0002UY-5J; Mon, 17 Sep 2012 17:41:17 +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 1TDfJs-0002TK-B9
	for xen-devel@lists.xensource.com; Mon, 17 Sep 2012 17:41:16 +0000
Received: from [85.158.139.83:10020] by server-3.bemta-5.messagelabs.com id
	3A/B7-21836-BB067505; Mon, 17 Sep 2012 17:41:15 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1347903669!30740402!3
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzAyMzE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2947 invoked from network); 17 Sep 2012 17:41:14 -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;
	17 Sep 2012 17:41:14 -0000
X-IronPort-AV: E=Sophos;i="4.80,437,1344211200"; d="scan'208";a="38105219"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Sep 2012 17:41:04 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Mon, 17 Sep 2012 13:41:03 -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 1TDfIF-0008AT-9V;
	Mon, 17 Sep 2012 18:39:35 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: <arnd@arndb.de>
Date: Mon, 17 Sep 2012 18:39:03 +0100
Message-ID: <1347903543-2135-17-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <alpine.DEB.2.02.1209171215490.29232@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1209171215490.29232@kaball.uk.xensource.com>
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com, linaro-dev@lists.linaro.org,
	Ian.Campbell@citrix.com, konrad.wilk@oracle.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	tim@xen.org, linux-kernel@vger.kernel.org,
	linux@arm.linux.org.uk, linux-arm-kernel@lists.infradead.org
Subject: [Xen-devel] [PATCH v5 17/17] MAINTAINERS: add myself as Xen ARM
	maintainer
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="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>
Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
CC: Arnd Bergmann <arnd@arndb.de>
---
 MAINTAINERS |    7 +++++++
 1 files changed, 7 insertions(+), 0 deletions(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index fdc0119..3d38291 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -7752,6 +7752,13 @@ F:	drivers/xen/
 F:	arch/x86/include/asm/xen/
 F:	include/xen/
 
+XEN HYPERVISOR ARM
+M:	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
+L:	xen-devel@lists.xensource.com (moderated for non-subscribers)
+S:	Supported
+F:	arch/arm/xen/
+F:	arch/arm/include/asm/xen/
+
 XEN NETWORK BACKEND DRIVER
 M:	Ian Campbell <ian.campbell@citrix.com>
 L:	xen-devel@lists.xensource.com (moderated for non-subscribers)
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 17 17:41:20 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 17:41:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDfJt-0002UY-5J; Mon, 17 Sep 2012 17:41:17 +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 1TDfJs-0002TK-B9
	for xen-devel@lists.xensource.com; Mon, 17 Sep 2012 17:41:16 +0000
Received: from [85.158.139.83:10020] by server-3.bemta-5.messagelabs.com id
	3A/B7-21836-BB067505; Mon, 17 Sep 2012 17:41:15 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1347903669!30740402!3
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzAyMzE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2947 invoked from network); 17 Sep 2012 17:41:14 -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;
	17 Sep 2012 17:41:14 -0000
X-IronPort-AV: E=Sophos;i="4.80,437,1344211200"; d="scan'208";a="38105219"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Sep 2012 17:41:04 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Mon, 17 Sep 2012 13:41:03 -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 1TDfIF-0008AT-9V;
	Mon, 17 Sep 2012 18:39:35 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: <arnd@arndb.de>
Date: Mon, 17 Sep 2012 18:39:03 +0100
Message-ID: <1347903543-2135-17-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <alpine.DEB.2.02.1209171215490.29232@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1209171215490.29232@kaball.uk.xensource.com>
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com, linaro-dev@lists.linaro.org,
	Ian.Campbell@citrix.com, konrad.wilk@oracle.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	tim@xen.org, linux-kernel@vger.kernel.org,
	linux@arm.linux.org.uk, linux-arm-kernel@lists.infradead.org
Subject: [Xen-devel] [PATCH v5 17/17] MAINTAINERS: add myself as Xen ARM
	maintainer
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="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>
Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
CC: Arnd Bergmann <arnd@arndb.de>
---
 MAINTAINERS |    7 +++++++
 1 files changed, 7 insertions(+), 0 deletions(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index fdc0119..3d38291 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -7752,6 +7752,13 @@ F:	drivers/xen/
 F:	arch/x86/include/asm/xen/
 F:	include/xen/
 
+XEN HYPERVISOR ARM
+M:	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
+L:	xen-devel@lists.xensource.com (moderated for non-subscribers)
+S:	Supported
+F:	arch/arm/xen/
+F:	arch/arm/include/asm/xen/
+
 XEN NETWORK BACKEND DRIVER
 M:	Ian Campbell <ian.campbell@citrix.com>
 L:	xen-devel@lists.xensource.com (moderated for non-subscribers)
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 17 17:41:25 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 17:41:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDfJy-0002b8-JG; Mon, 17 Sep 2012 17:41:22 +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 1TDfJx-0002ZG-6O
	for xen-devel@lists.xensource.com; Mon, 17 Sep 2012 17:41:21 +0000
Received: from [85.158.139.83:10185] by server-2.bemta-5.messagelabs.com id
	D1/FC-11456-0C067505; Mon, 17 Sep 2012 17:41:20 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1347903669!30740402!4
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzAyMzE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3073 invoked from network); 17 Sep 2012 17:41:19 -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;
	17 Sep 2012 17:41:19 -0000
X-IronPort-AV: E=Sophos;i="4.80,437,1344211200"; d="scan'208";a="38105242"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Sep 2012 17:41:16 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Mon, 17 Sep 2012 13:41:15 -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 1TDfIF-0008AT-4g;
	Mon, 17 Sep 2012 18:39:35 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: <arnd@arndb.de>
Date: Mon, 17 Sep 2012 18:38:57 +0100
Message-ID: <1347903543-2135-11-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <alpine.DEB.2.02.1209171215490.29232@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1209171215490.29232@kaball.uk.xensource.com>
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com, linaro-dev@lists.linaro.org,
	Ian.Campbell@citrix.com, konrad.wilk@oracle.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	tim@xen.org, linux-kernel@vger.kernel.org,
	linux@arm.linux.org.uk, linux-arm-kernel@lists.infradead.org
Subject: [Xen-devel] [PATCH v5 11/17] 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.

XENFEAT_dom0 was introduced by 23735 in xen-unstable.hg.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 arch/arm/xen/enlighten.c         |    7 +++++++
 include/xen/interface/features.h |    3 +++
 2 files changed, 10 insertions(+), 0 deletions(-)

diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
index 6a0217d..c2a47a7 100644
--- a/arch/arm/xen/enlighten.c
+++ b/arch/arm/xen/enlighten.c
@@ -1,6 +1,7 @@
 #include <xen/xen.h>
 #include <xen/interface/xen.h>
 #include <xen/interface/memory.h>
+#include <xen/features.h>
 #include <xen/platform_pci.h>
 #include <asm/xen/hypervisor.h>
 #include <asm/xen/hypercall.h>
@@ -66,6 +67,12 @@ static int __init xen_guest_init(void)
 	}
 	xen_domain_type = XEN_HVM_DOMAIN;
 
+	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);
+
 	if (!shared_info_page)
 		shared_info_page = (struct shared_info *)
 			get_zeroed_page(GFP_KERNEL);
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 Mon Sep 17 17:41:25 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 17:41:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDfJy-0002b8-JG; Mon, 17 Sep 2012 17:41:22 +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 1TDfJx-0002ZG-6O
	for xen-devel@lists.xensource.com; Mon, 17 Sep 2012 17:41:21 +0000
Received: from [85.158.139.83:10185] by server-2.bemta-5.messagelabs.com id
	D1/FC-11456-0C067505; Mon, 17 Sep 2012 17:41:20 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1347903669!30740402!4
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzAyMzE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3073 invoked from network); 17 Sep 2012 17:41:19 -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;
	17 Sep 2012 17:41:19 -0000
X-IronPort-AV: E=Sophos;i="4.80,437,1344211200"; d="scan'208";a="38105242"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Sep 2012 17:41:16 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Mon, 17 Sep 2012 13:41:15 -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 1TDfIF-0008AT-4g;
	Mon, 17 Sep 2012 18:39:35 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: <arnd@arndb.de>
Date: Mon, 17 Sep 2012 18:38:57 +0100
Message-ID: <1347903543-2135-11-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <alpine.DEB.2.02.1209171215490.29232@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1209171215490.29232@kaball.uk.xensource.com>
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com, linaro-dev@lists.linaro.org,
	Ian.Campbell@citrix.com, konrad.wilk@oracle.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	tim@xen.org, linux-kernel@vger.kernel.org,
	linux@arm.linux.org.uk, linux-arm-kernel@lists.infradead.org
Subject: [Xen-devel] [PATCH v5 11/17] 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.

XENFEAT_dom0 was introduced by 23735 in xen-unstable.hg.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 arch/arm/xen/enlighten.c         |    7 +++++++
 include/xen/interface/features.h |    3 +++
 2 files changed, 10 insertions(+), 0 deletions(-)

diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
index 6a0217d..c2a47a7 100644
--- a/arch/arm/xen/enlighten.c
+++ b/arch/arm/xen/enlighten.c
@@ -1,6 +1,7 @@
 #include <xen/xen.h>
 #include <xen/interface/xen.h>
 #include <xen/interface/memory.h>
+#include <xen/features.h>
 #include <xen/platform_pci.h>
 #include <asm/xen/hypervisor.h>
 #include <asm/xen/hypercall.h>
@@ -66,6 +67,12 @@ static int __init xen_guest_init(void)
 	}
 	xen_domain_type = XEN_HVM_DOMAIN;
 
+	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);
+
 	if (!shared_info_page)
 		shared_info_page = (struct shared_info *)
 			get_zeroed_page(GFP_KERNEL);
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 Mon Sep 17 17:41:30 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 17:41:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDfK3-0002gi-1u; Mon, 17 Sep 2012 17:41:27 +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 1TDfK1-0002dZ-DT
	for xen-devel@lists.xensource.com; Mon, 17 Sep 2012 17:41:25 +0000
Received: from [85.158.139.211:38959] by server-3.bemta-5.messagelabs.com id
	33/E7-21836-4C067505; Mon, 17 Sep 2012 17:41:24 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-13.tower-206.messagelabs.com!1347903682!14917637!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNzUxNjg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2934 invoked from network); 17 Sep 2012 17:41:23 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-13.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Sep 2012 17:41:23 -0000
X-IronPort-AV: E=Sophos;i="4.80,437,1344211200"; d="scan'208";a="208319491"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Sep 2012 17:41:22 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Mon, 17 Sep 2012 13:41:21 -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 1TDfIF-0008AT-77;
	Mon, 17 Sep 2012 18:39:35 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: <arnd@arndb.de>
Date: Mon, 17 Sep 2012 18:38:59 +0100
Message-ID: <1347903543-2135-13-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <alpine.DEB.2.02.1209171215490.29232@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1209171215490.29232@kaball.uk.xensource.com>
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com, linaro-dev@lists.linaro.org,
	Ian.Campbell@citrix.com, konrad.wilk@oracle.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	tim@xen.org, linux-kernel@vger.kernel.org,
	linux@arm.linux.org.uk, linux-arm-kernel@lists.infradead.org
Subject: [Xen-devel] [PATCH v5 13/17] xen/arm: receive Xen events on ARM
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Compile events.c on ARM.
Parse, map and enable the IRQ to get event notifications from the device
tree (node "/xen").

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 arch/arm/include/asm/xen/events.h |   18 ++++++++++++++++++
 arch/arm/xen/enlighten.c          |   33 +++++++++++++++++++++++++++++++++
 arch/x86/xen/enlighten.c          |    1 +
 arch/x86/xen/irq.c                |    1 +
 arch/x86/xen/xen-ops.h            |    1 -
 drivers/xen/events.c              |   17 ++++++++++++++---
 include/xen/events.h              |    2 ++
 7 files changed, 69 insertions(+), 4 deletions(-)
 create mode 100644 arch/arm/include/asm/xen/events.h

diff --git a/arch/arm/include/asm/xen/events.h b/arch/arm/include/asm/xen/events.h
new file mode 100644
index 0000000..94b4e90
--- /dev/null
+++ b/arch/arm/include/asm/xen/events.h
@@ -0,0 +1,18 @@
+#ifndef _ASM_ARM_XEN_EVENTS_H
+#define _ASM_ARM_XEN_EVENTS_H
+
+#include <asm/ptrace.h>
+
+enum ipi_vector {
+	XEN_PLACEHOLDER_VECTOR,
+
+	/* Xen IPIs go here */
+	XEN_NR_IPIS,
+};
+
+static inline int xen_irqs_disabled(struct pt_regs *regs)
+{
+	return raw_irqs_disabled_flags(regs->ARM_cpsr);
+}
+
+#endif /* _ASM_ARM_XEN_EVENTS_H */
diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
index 036a4d8..bad67ad 100644
--- a/arch/arm/xen/enlighten.c
+++ b/arch/arm/xen/enlighten.c
@@ -1,4 +1,5 @@
 #include <xen/xen.h>
+#include <xen/events.h>
 #include <xen/grant_table.h>
 #include <xen/hvm.h>
 #include <xen/interface/xen.h>
@@ -9,6 +10,8 @@
 #include <xen/xenbus.h>
 #include <asm/xen/hypervisor.h>
 #include <asm/xen/hypercall.h>
+#include <linux/interrupt.h>
+#include <linux/irqreturn.h>
 #include <linux/module.h>
 #include <linux/of.h>
 #include <linux/of_irq.h>
@@ -33,6 +36,8 @@ EXPORT_SYMBOL_GPL(xen_have_vector_callback);
 int xen_platform_pci_unplug = XEN_UNPLUG_ALL;
 EXPORT_SYMBOL_GPL(xen_platform_pci_unplug);
 
+static __read_mostly int xen_events_irq = -1;
+
 int xen_remap_domain_mfn_range(struct vm_area_struct *vma,
 			       unsigned long addr,
 			       unsigned long mfn, int nr,
@@ -74,6 +79,9 @@ static int __init xen_guest_init(void)
 	if (of_address_to_resource(node, GRANT_TABLE_PHYSADDR, &res))
 		return 0;
 	xen_hvm_resume_frames = res.start >> PAGE_SHIFT;
+	xen_events_irq = irq_of_parse_and_map(node, 0);
+	pr_info("Xen %s support found, events_irq=%d gnttab_frame_pfn=%lx\n",
+			version, xen_events_irq, xen_hvm_resume_frames);
 	xen_domain_type = XEN_HVM_DOMAIN;
 
 	xen_setup_features();
@@ -115,3 +123,28 @@ static int __init xen_guest_init(void)
 	return 0;
 }
 core_initcall(xen_guest_init);
+
+static irqreturn_t xen_arm_callback(int irq, void *arg)
+{
+	xen_hvm_evtchn_do_upcall();
+	return IRQ_HANDLED;
+}
+
+static int __init xen_init_events(void)
+{
+	if (!xen_domain() || xen_events_irq < 0)
+		return -ENODEV;
+
+	xen_init_IRQ();
+
+	if (request_percpu_irq(xen_events_irq, xen_arm_callback,
+			"events", xen_vcpu)) {
+		pr_err("Error requesting IRQ %d\n", xen_events_irq);
+		return -EINVAL;
+	}
+
+	enable_percpu_irq(xen_events_irq, 0);
+
+	return 0;
+}
+postcore_initcall(xen_init_events);
diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
index 47b3acd..689a4c9 100644
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -33,6 +33,7 @@
 #include <linux/memblock.h>
 
 #include <xen/xen.h>
+#include <xen/events.h>
 #include <xen/interface/xen.h>
 #include <xen/interface/version.h>
 #include <xen/interface/physdev.h>
diff --git a/arch/x86/xen/irq.c b/arch/x86/xen/irq.c
index 1573376..01a4dc0 100644
--- a/arch/x86/xen/irq.c
+++ b/arch/x86/xen/irq.c
@@ -5,6 +5,7 @@
 #include <xen/interface/xen.h>
 #include <xen/interface/sched.h>
 #include <xen/interface/vcpu.h>
+#include <xen/events.h>
 
 #include <asm/xen/hypercall.h>
 #include <asm/xen/hypervisor.h>
diff --git a/arch/x86/xen/xen-ops.h b/arch/x86/xen/xen-ops.h
index bb5a810..a95b417 100644
--- a/arch/x86/xen/xen-ops.h
+++ b/arch/x86/xen/xen-ops.h
@@ -35,7 +35,6 @@ void xen_set_pat(u64);
 
 char * __init xen_memory_setup(void);
 void __init xen_arch_setup(void);
-void __init xen_init_IRQ(void);
 void xen_enable_sysenter(void);
 void xen_enable_syscall(void);
 void xen_vcpu_restore(void);
diff --git a/drivers/xen/events.c b/drivers/xen/events.c
index c60d162..8672211 100644
--- a/drivers/xen/events.c
+++ b/drivers/xen/events.c
@@ -31,14 +31,16 @@
 #include <linux/irqnr.h>
 #include <linux/pci.h>
 
+#ifdef CONFIG_X86
 #include <asm/desc.h>
 #include <asm/ptrace.h>
 #include <asm/irq.h>
 #include <asm/idle.h>
 #include <asm/io_apic.h>
-#include <asm/sync_bitops.h>
 #include <asm/xen/page.h>
 #include <asm/xen/pci.h>
+#endif
+#include <asm/sync_bitops.h>
 #include <asm/xen/hypercall.h>
 #include <asm/xen/hypervisor.h>
 
@@ -50,6 +52,9 @@
 #include <xen/interface/event_channel.h>
 #include <xen/interface/hvm/hvm_op.h>
 #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
@@ -1386,7 +1391,9 @@ void xen_evtchn_do_upcall(struct pt_regs *regs)
 {
 	struct pt_regs *old_regs = set_irq_regs(regs);
 
+#ifdef CONFIG_X86
 	exit_idle();
+#endif
 	irq_enter();
 
 	__xen_evtchn_do_upcall();
@@ -1795,9 +1802,9 @@ void xen_callback_vector(void)
 void xen_callback_vector(void) {}
 #endif
 
-void __init xen_init_IRQ(void)
+void xen_init_IRQ(void)
 {
-	int i, rc;
+	int i;
 
 	evtchn_to_irq = kcalloc(NR_EVENT_CHANNELS, sizeof(*evtchn_to_irq),
 				    GFP_KERNEL);
@@ -1813,6 +1820,7 @@ void __init xen_init_IRQ(void)
 
 	pirq_needs_eoi = pirq_needs_eoi_flag;
 
+#ifdef CONFIG_X86
 	if (xen_hvm_domain()) {
 		xen_callback_vector();
 		native_init_IRQ();
@@ -1820,6 +1828,7 @@ void __init xen_init_IRQ(void)
 		 * __acpi_register_gsi can point at the right function */
 		pci_xen_hvm_init();
 	} else {
+		int rc;
 		struct physdev_pirq_eoi_gmfn eoi_gmfn;
 
 		irq_ctx_init(smp_processor_id());
@@ -1835,4 +1844,6 @@ void __init xen_init_IRQ(void)
 		} else
 			pirq_needs_eoi = pirq_check_eoi_map;
 	}
+#endif
 }
+EXPORT_SYMBOL_GPL(xen_init_IRQ);
diff --git a/include/xen/events.h b/include/xen/events.h
index 04399b2..c6bfe01 100644
--- a/include/xen/events.h
+++ b/include/xen/events.h
@@ -109,4 +109,6 @@ int xen_irq_from_gsi(unsigned gsi);
 /* Determine whether to ignore this IRQ if it is passed to a guest. */
 int xen_test_irq_shared(int irq);
 
+/* initialize Xen IRQ subsystem */
+void xen_init_IRQ(void);
 #endif	/* _XEN_EVENTS_H */
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 17 17:41:30 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 17:41:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDfK3-0002gi-1u; Mon, 17 Sep 2012 17:41:27 +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 1TDfK1-0002dZ-DT
	for xen-devel@lists.xensource.com; Mon, 17 Sep 2012 17:41:25 +0000
Received: from [85.158.139.211:38959] by server-3.bemta-5.messagelabs.com id
	33/E7-21836-4C067505; Mon, 17 Sep 2012 17:41:24 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-13.tower-206.messagelabs.com!1347903682!14917637!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNzUxNjg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2934 invoked from network); 17 Sep 2012 17:41:23 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-13.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Sep 2012 17:41:23 -0000
X-IronPort-AV: E=Sophos;i="4.80,437,1344211200"; d="scan'208";a="208319491"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Sep 2012 17:41:22 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Mon, 17 Sep 2012 13:41:21 -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 1TDfIF-0008AT-77;
	Mon, 17 Sep 2012 18:39:35 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: <arnd@arndb.de>
Date: Mon, 17 Sep 2012 18:38:59 +0100
Message-ID: <1347903543-2135-13-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <alpine.DEB.2.02.1209171215490.29232@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1209171215490.29232@kaball.uk.xensource.com>
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com, linaro-dev@lists.linaro.org,
	Ian.Campbell@citrix.com, konrad.wilk@oracle.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	tim@xen.org, linux-kernel@vger.kernel.org,
	linux@arm.linux.org.uk, linux-arm-kernel@lists.infradead.org
Subject: [Xen-devel] [PATCH v5 13/17] xen/arm: receive Xen events on ARM
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Compile events.c on ARM.
Parse, map and enable the IRQ to get event notifications from the device
tree (node "/xen").

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 arch/arm/include/asm/xen/events.h |   18 ++++++++++++++++++
 arch/arm/xen/enlighten.c          |   33 +++++++++++++++++++++++++++++++++
 arch/x86/xen/enlighten.c          |    1 +
 arch/x86/xen/irq.c                |    1 +
 arch/x86/xen/xen-ops.h            |    1 -
 drivers/xen/events.c              |   17 ++++++++++++++---
 include/xen/events.h              |    2 ++
 7 files changed, 69 insertions(+), 4 deletions(-)
 create mode 100644 arch/arm/include/asm/xen/events.h

diff --git a/arch/arm/include/asm/xen/events.h b/arch/arm/include/asm/xen/events.h
new file mode 100644
index 0000000..94b4e90
--- /dev/null
+++ b/arch/arm/include/asm/xen/events.h
@@ -0,0 +1,18 @@
+#ifndef _ASM_ARM_XEN_EVENTS_H
+#define _ASM_ARM_XEN_EVENTS_H
+
+#include <asm/ptrace.h>
+
+enum ipi_vector {
+	XEN_PLACEHOLDER_VECTOR,
+
+	/* Xen IPIs go here */
+	XEN_NR_IPIS,
+};
+
+static inline int xen_irqs_disabled(struct pt_regs *regs)
+{
+	return raw_irqs_disabled_flags(regs->ARM_cpsr);
+}
+
+#endif /* _ASM_ARM_XEN_EVENTS_H */
diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
index 036a4d8..bad67ad 100644
--- a/arch/arm/xen/enlighten.c
+++ b/arch/arm/xen/enlighten.c
@@ -1,4 +1,5 @@
 #include <xen/xen.h>
+#include <xen/events.h>
 #include <xen/grant_table.h>
 #include <xen/hvm.h>
 #include <xen/interface/xen.h>
@@ -9,6 +10,8 @@
 #include <xen/xenbus.h>
 #include <asm/xen/hypervisor.h>
 #include <asm/xen/hypercall.h>
+#include <linux/interrupt.h>
+#include <linux/irqreturn.h>
 #include <linux/module.h>
 #include <linux/of.h>
 #include <linux/of_irq.h>
@@ -33,6 +36,8 @@ EXPORT_SYMBOL_GPL(xen_have_vector_callback);
 int xen_platform_pci_unplug = XEN_UNPLUG_ALL;
 EXPORT_SYMBOL_GPL(xen_platform_pci_unplug);
 
+static __read_mostly int xen_events_irq = -1;
+
 int xen_remap_domain_mfn_range(struct vm_area_struct *vma,
 			       unsigned long addr,
 			       unsigned long mfn, int nr,
@@ -74,6 +79,9 @@ static int __init xen_guest_init(void)
 	if (of_address_to_resource(node, GRANT_TABLE_PHYSADDR, &res))
 		return 0;
 	xen_hvm_resume_frames = res.start >> PAGE_SHIFT;
+	xen_events_irq = irq_of_parse_and_map(node, 0);
+	pr_info("Xen %s support found, events_irq=%d gnttab_frame_pfn=%lx\n",
+			version, xen_events_irq, xen_hvm_resume_frames);
 	xen_domain_type = XEN_HVM_DOMAIN;
 
 	xen_setup_features();
@@ -115,3 +123,28 @@ static int __init xen_guest_init(void)
 	return 0;
 }
 core_initcall(xen_guest_init);
+
+static irqreturn_t xen_arm_callback(int irq, void *arg)
+{
+	xen_hvm_evtchn_do_upcall();
+	return IRQ_HANDLED;
+}
+
+static int __init xen_init_events(void)
+{
+	if (!xen_domain() || xen_events_irq < 0)
+		return -ENODEV;
+
+	xen_init_IRQ();
+
+	if (request_percpu_irq(xen_events_irq, xen_arm_callback,
+			"events", xen_vcpu)) {
+		pr_err("Error requesting IRQ %d\n", xen_events_irq);
+		return -EINVAL;
+	}
+
+	enable_percpu_irq(xen_events_irq, 0);
+
+	return 0;
+}
+postcore_initcall(xen_init_events);
diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
index 47b3acd..689a4c9 100644
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -33,6 +33,7 @@
 #include <linux/memblock.h>
 
 #include <xen/xen.h>
+#include <xen/events.h>
 #include <xen/interface/xen.h>
 #include <xen/interface/version.h>
 #include <xen/interface/physdev.h>
diff --git a/arch/x86/xen/irq.c b/arch/x86/xen/irq.c
index 1573376..01a4dc0 100644
--- a/arch/x86/xen/irq.c
+++ b/arch/x86/xen/irq.c
@@ -5,6 +5,7 @@
 #include <xen/interface/xen.h>
 #include <xen/interface/sched.h>
 #include <xen/interface/vcpu.h>
+#include <xen/events.h>
 
 #include <asm/xen/hypercall.h>
 #include <asm/xen/hypervisor.h>
diff --git a/arch/x86/xen/xen-ops.h b/arch/x86/xen/xen-ops.h
index bb5a810..a95b417 100644
--- a/arch/x86/xen/xen-ops.h
+++ b/arch/x86/xen/xen-ops.h
@@ -35,7 +35,6 @@ void xen_set_pat(u64);
 
 char * __init xen_memory_setup(void);
 void __init xen_arch_setup(void);
-void __init xen_init_IRQ(void);
 void xen_enable_sysenter(void);
 void xen_enable_syscall(void);
 void xen_vcpu_restore(void);
diff --git a/drivers/xen/events.c b/drivers/xen/events.c
index c60d162..8672211 100644
--- a/drivers/xen/events.c
+++ b/drivers/xen/events.c
@@ -31,14 +31,16 @@
 #include <linux/irqnr.h>
 #include <linux/pci.h>
 
+#ifdef CONFIG_X86
 #include <asm/desc.h>
 #include <asm/ptrace.h>
 #include <asm/irq.h>
 #include <asm/idle.h>
 #include <asm/io_apic.h>
-#include <asm/sync_bitops.h>
 #include <asm/xen/page.h>
 #include <asm/xen/pci.h>
+#endif
+#include <asm/sync_bitops.h>
 #include <asm/xen/hypercall.h>
 #include <asm/xen/hypervisor.h>
 
@@ -50,6 +52,9 @@
 #include <xen/interface/event_channel.h>
 #include <xen/interface/hvm/hvm_op.h>
 #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
@@ -1386,7 +1391,9 @@ void xen_evtchn_do_upcall(struct pt_regs *regs)
 {
 	struct pt_regs *old_regs = set_irq_regs(regs);
 
+#ifdef CONFIG_X86
 	exit_idle();
+#endif
 	irq_enter();
 
 	__xen_evtchn_do_upcall();
@@ -1795,9 +1802,9 @@ void xen_callback_vector(void)
 void xen_callback_vector(void) {}
 #endif
 
-void __init xen_init_IRQ(void)
+void xen_init_IRQ(void)
 {
-	int i, rc;
+	int i;
 
 	evtchn_to_irq = kcalloc(NR_EVENT_CHANNELS, sizeof(*evtchn_to_irq),
 				    GFP_KERNEL);
@@ -1813,6 +1820,7 @@ void __init xen_init_IRQ(void)
 
 	pirq_needs_eoi = pirq_needs_eoi_flag;
 
+#ifdef CONFIG_X86
 	if (xen_hvm_domain()) {
 		xen_callback_vector();
 		native_init_IRQ();
@@ -1820,6 +1828,7 @@ void __init xen_init_IRQ(void)
 		 * __acpi_register_gsi can point at the right function */
 		pci_xen_hvm_init();
 	} else {
+		int rc;
 		struct physdev_pirq_eoi_gmfn eoi_gmfn;
 
 		irq_ctx_init(smp_processor_id());
@@ -1835,4 +1844,6 @@ void __init xen_init_IRQ(void)
 		} else
 			pirq_needs_eoi = pirq_check_eoi_map;
 	}
+#endif
 }
+EXPORT_SYMBOL_GPL(xen_init_IRQ);
diff --git a/include/xen/events.h b/include/xen/events.h
index 04399b2..c6bfe01 100644
--- a/include/xen/events.h
+++ b/include/xen/events.h
@@ -109,4 +109,6 @@ int xen_irq_from_gsi(unsigned gsi);
 /* Determine whether to ignore this IRQ if it is passed to a guest. */
 int xen_test_irq_shared(int irq);
 
+/* initialize Xen IRQ subsystem */
+void xen_init_IRQ(void);
 #endif	/* _XEN_EVENTS_H */
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 17 17:54:22 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 17:54:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDfWP-0004Fp-Jd; Mon, 17 Sep 2012 17:54:13 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <matthew.fioravante@jhuapl.edu>) id 1TDfWN-0004Fk-07
	for xen-devel@lists.xensource.com; Mon, 17 Sep 2012 17:54:11 +0000
Received: from [85.158.138.51:11693] by server-10.bemta-3.messagelabs.com id
	48/0B-10411-2C367505; Mon, 17 Sep 2012 17:54:10 +0000
X-Env-Sender: matthew.fioravante@jhuapl.edu
X-Msg-Ref: server-6.tower-174.messagelabs.com!1347904441!22875728!1
X-Originating-IP: [128.244.251.36]
X-SpamReason: No, hits=0.0 required=7.0 tests=UNPARSEABLE_RELAY
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23144 invoked from network); 17 Sep 2012 17:54:03 -0000
Received: from pilot.jhuapl.edu (HELO jhuapl.edu) (128.244.251.36)
	by server-6.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 17 Sep 2012 17:54:03 -0000
Received: from ([128.244.207.89])
	by pilot.jhuapl.edu with ESMTP with TLS id 63GHCH1.153058441;
	Mon, 17 Sep 2012 13:53:55 -0400
Message-ID: <50576368.3070007@jhuapl.edu>
Date: Mon, 17 Sep 2012 13:52:40 -0400
From: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:14.0) Gecko/20120714 Thunderbird/14.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
X-Enigmail-Version: 1.5a1pre
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: [Xen-devel] [PATCH] Upgrade vtpmd to berlios version 0.7.4
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============3101777180007788348=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a cryptographically signed message in MIME format.

--===============3101777180007788348==
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms030704010609040205060800"

This is a cryptographically signed message in MIME format.

--------------ms030704010609040205060800
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

What will follow soon are updates to vtpmd, vtpm_manager, xm, xl,
mini-os, and new vtpm and vtpm manager stub domains.

The first patch I'd like to submit upgrades vtpmd to version 0.7.4

This patch does the following:
-add checks to configure to check for cmake (required by berlios 0.7.4)
-removes all of the 0.5.1 patches
-adds a single patch for 0.7.4
-cleans up the makefile, should work for parallel make (avoiding
version.h discussion from august 2012)
-builds vtpmd to use berlios 0.7.4
-Remoed the tpm_emualtor build option. berlios itself provides a kernel
module if you want to use it in dom0 to emulate the physical tpm.

Signed of by: Matthew Fioravante matthew.fioravante@jhuapl.edu

diff --git a/tools/configure.ac b/tools/configure.ac
--- a/tools/configure.ac
+++ b/tools/configure.ac
@@ -67,6 +67,7 @@ AC_ARG_VAR([CURL], [Path to curl-config tool])
 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([CMAKE], [Path to cmake binary])
=20
 dnl as86, ld86, bcc and iasl are only present in x86* systems
 case "$host_cpu" in
@@ -108,6 +109,9 @@ AS_IF([test "x$pythontools" =3D "xy"], [
     AX_CHECK_PYTHON_VERSION([2], [3])
     AX_CHECK_PYTHON_DEVEL()
 ])
+AS_IF([test "x$vtpm" =3D "xy"], [
+    AX_PATH_PROG_OR_FAIL([CMAKE], [cmake])
+])
 AX_PATH_PROG_OR_FAIL([XGETTEXT], [xgettext])
 AX_PATH_PROG_OR_FAIL([AS86], [as86])
 AX_PATH_PROG_OR_FAIL([LD86], [ld86])
diff --git a/tools/vtpm/Makefile b/tools/vtpm/Makefile
--- a/tools/vtpm/Makefile
+++ b/tools/vtpm/Makefile
@@ -1,19 +1,15 @@
 XEN_ROOT =3D $(CURDIR)/../..
+include $(XEN_ROOT)/tools/Rules.mk
=20
-# Base definitions and rules
-include $(XEN_ROOT)/tools/vtpm/Rules.mk
-
-# Dir name for emulator (as dom0 tpm driver)
-TPM_EMULATOR_DIR =3D tpm_emulator
 # Dir name for vtpm instance
 VTPM_DIR =3D vtpm
-ORIG_DIR =3D orig
=20
 # Emulator tarball name
-TPM_EMULATOR_NAME =3D tpm_emulator-0.5.1
+TPM_EMULATOR_URL =3D http://download.berlios.de/tpm-emulator
+TPM_EMULATOR_NAME =3D tpm_emulator-0.7.4
 TPM_EMULATOR_TARFILE =3D $(TPM_EMULATOR_NAME).tar.gz
=20
-GMP_HEADER =3D /usr/include/gmp.h
+VTPM_PATCH =3D vtpm-0.7.4.patch
=20
 .PHONY: all
 all: build
@@ -23,51 +19,34 @@ build: build_sub
=20
 .PHONY: install
 install: build
-    $(MAKE) -C $(VTPM_DIR) $@
+    $(INSTALL_PROG) -m 0755 $(VTPM_DIR)/build/tpmd/unix/tpmd
$(DESTDIR)$(BINDIR)/vtpmd
=20
 .PHONY: clean
 clean:
-    @if [ -d $(TPM_EMULATOR_DIR) ]; \
-        then $(MAKE) -C $(TPM_EMULATOR_DIR) clean; \
-    fi
-    @if [ -d $(VTPM_DIR) ]; \
-        then $(MAKE) -C $(VTPM_DIR) clean; \
+    @-if [ -d $(VTPM_DIR)/build ]; \
+        then $(MAKE) -C $(VTPM_DIR)/build clean; \
     fi
=20
 .PHONY: mrproper
 mrproper:
-    rm -f $(TPM_EMULATOR_TARFILE) tpm_emulator.patch.old vtpm.patch.old
-    rm -rf $(TPM_EMULATOR_DIR) $(VTPM_DIR) $(ORIG_DIR)
+    rm -f $(TPM_EMULATOR_TARFILE)
+    rm -rf $(VTPM_DIR) $(ORIG_DIR)
=20
 # Download Swiss emulator
 $(TPM_EMULATOR_TARFILE):
-    wget http://download.berlios.de/tpm-emulator/$(TPM_EMULATOR_TARFILE)=

+    wget $(TPM_EMULATOR_URL)/$(TPM_EMULATOR_TARFILE)
=20
 # Create vtpm dirs
-$(VTPM_DIR)/tpmd/tpmd: $(TPM_EMULATOR_TARFILE) vtpm-0.5.1.patch
+$(VTPM_DIR)/build: $(TPM_EMULATOR_TARFILE) $(VTPM_PATCH)
     rm -rf $(VTPM_DIR)
     tar -xzf $(TPM_EMULATOR_TARFILE)
     mv $(TPM_EMULATOR_NAME) $(VTPM_DIR)
-
     set -e; cd $(VTPM_DIR); \
-    patch -p1 < ../vtpm-0.5.1.patch; \
-    patch -p1 < ../vtpm-0.5.1-LDLIBS.patch
-
-orig: $(TPM_EMULATOR_TARFILE)
-    mkdir $(ORIG_DIR);
-    set -e; cd $(ORIG_DIR); \
-    tar -xzf ../$(TPM_EMULATOR_TARFILE);
-
-updatepatches: clean orig
-    find $(VTPM_DIR) -name "*.orig" -print | xargs rm -f;
-    mv vtpm.patch vtpm.patch.old;
-    diff -uprN $(TPM_EMULATOR_DIR) $(VTPM_DIR) > vtpm.patch || true;
+    patch -p1 < ../$(VTPM_PATCH); \
+    mkdir build; cd build; cmake -DCMAKE_INSTALL_PREFIX=3D${PREFIX} ..
+    touch $@
=20
 .PHONY: build_sub
-build_sub: $(VTPM_DIR)/tpmd/tpmd
-    set -e; if [ -e $(GMP_HEADER) ]; then \
-        $(MAKE) -C $(VTPM_DIR); \
-    else \
-        echo "=3D=3D=3D Unable to build VTPMs. libgmp could not be found=
=2E"; \
-    fi
-
+build_sub: $(VTPM_DIR)/build
+    set -e; \
+    cd $<; $(MAKE) tpmd
diff --git a/tools/vtpm/Rules.mk b/tools/vtpm/Rules.mk
--- a/tools/vtpm/Rules.mk
+++ /dev/null
@@ -1,26 +0,0 @@
-# Base definitions and rules (XEN_ROOT must be defined in including
Makefile)
-include $(XEN_ROOT)/tools/Rules.mk
-
-#
-# Tool definitions
-#
-
-# General compiler flags
-CFLAGS   =3D -Werror -g3
-
-# Generic project files
-HDRS    =3D $(wildcard *.h)
-SRCS    =3D $(wildcard *.c)
-OBJS    =3D $(patsubst %.c,%.o,$(SRCS))
-
-# Generic (non-header) dependencies
-$(SRCS): Makefile $(XEN_ROOT)/tools/Rules.mk
$(XEN_ROOT)/tools/vtpm/Rules.mk
-
-$(OBJS): $(SRCS)
-
--include $(DEPS)
-
-BUILD_EMULATOR =3D y
-
-# Make sure these are just rules
-.PHONY : all build install clean
diff --git a/tools/vtpm/tpm_emulator.patch b/tools/vtpm/tpm_emulator.patc=
h
--- a/tools/vtpm/tpm_emulator.patch
+++ /dev/null
@@ -1,1919 +0,0 @@
-diff -uprN orig/tpm_emulator-0.4/AUTHORS tpm_emulator/AUTHORS
---- orig/tpm_emulator-0.4/AUTHORS    2006-06-23 03:37:07.000000000 -0700=

-+++ tpm_emulator/AUTHORS    2006-07-24 14:35:35.000000000 -0700
-@@ -1,2 +1,3 @@
- Mario Strasser <mast@gmx.net>
- Heiko Stamer <stamer@gaos.org> [DAA]
-+INTEL Corp <> [Dropped to Ring3]
-diff -uprN orig/tpm_emulator-0.4/ChangeLog tpm_emulator/ChangeLog
---- orig/tpm_emulator-0.4/ChangeLog    2006-06-23 03:37:07.000000000 -07=
00
-+++ tpm_emulator/ChangeLog    2006-07-24 14:35:35.000000000 -0700
-@@ -1,3 +1,6 @@
-+????-??-?? Intel Corp
-+    * Moved module out of kernel to run as a ring 3 app
-+
- 2006-06-23  Mario Strasser <mast@gmx.net>
-     * tpm_startup.c: behaviour of ST_CLEAR and storage of
-         persistent data adapted
-diff -uprN orig/tpm_emulator-0.4/crypto/gmp_kernel_wrapper.c
tpm_emulator/crypto/gmp_kernel_wrapper.c
---- orig/tpm_emulator-0.4/crypto/gmp_kernel_wrapper.c    2006-06-23
03:37:07.000000000 -0700
-+++ tpm_emulator/crypto/gmp_kernel_wrapper.c    2006-07-24
14:35:35.000000000 -0700
-@@ -1,5 +1,6 @@
- /* Software-Based Trusted Platform Module (TPM) Emulator for Linux
-  * Copyright (C) 2004 Mario Strasser <mast@gmx.net>,
-+ * Copyright (C) 2005 INTEL Corp
-  *
-  * This module is free software; you can redistribute it and/or modify
-  * it under the terms of the GNU General Public License as published
-@@ -24,15 +25,10 @@ int __gmp_junk;
- void __attribute__ ((regparm(0))) __gmp_assert_fail(const char *filenam=
e,
-   int linenum, const char *expr)
- {
--  panic(KERN_CRIT TPM_MODULE_NAME "%s:%d: GNU MP assertion failed: %s\n=
",
-+  error("%s:%d: GNU MP assertion failed: %s\n",
-     filename, linenum, expr);
- }
-
--void __attribute__ ((regparm(0))) abort(void)
--{
--  panic(KERN_CRIT TPM_MODULE_NAME "GNU MP abort() was called\n");
--}
--
- /* overwrite GNU MP random functions (used by mpz/millerrabin.c) */
-
- void __attribute__ ((regparm(0))) gmp_randinit(gmp_randstate_t rstate,
-@@ -77,20 +73,19 @@ void __attribute__ ((regparm(0))) mpz_ur
-
- void __attribute__ ((regparm(0))) *kernel_allocate(size_t size)
- {
--  void *ret  =3D (void*)kmalloc(size, GFP_KERNEL);
--  if (!ret) panic(KERN_CRIT TPM_MODULE_NAME
--    "GMP: cannot allocate memory (size=3D%u)\n", size);
-+  void *ret  =3D (void*)malloc(size);
-+  if (!ret) error("GMP: cannot allocate memory (size=3D%Zu)\n", size);
-   return ret;
- }
-
- void __attribute__ ((regparm(0))) *kernel_reallocate(void *oldptr,
-   size_t old_size, size_t new_size)
- {
--  void *ret =3D (void*)kmalloc(new_size, GFP_KERNEL);
--  if (!ret) panic(KERN_CRIT TPM_MODULE_NAME "GMP: Cannot reallocate
memory "
--    "(old_size=3D%u new_size=3D%u)\n", old_size, new_size);
-+  void *ret =3D (void*)malloc(new_size);
-+  if (!ret) error("GMP: Cannot reallocate memory "
-+    "(old_size=3D%Zu new_size=3D%Zu)\n", old_size, new_size);
-   memcpy(ret, oldptr, old_size);
--  kfree(oldptr);
-+  free(oldptr);
-   return ret;
- }
-
-@@ -99,7 +94,7 @@ void __attribute__ ((regparm(0))) kernel
-   /* overwrite used memory */
-   if (blk_ptr !=3D NULL) {
-     memset(blk_ptr, 0, blk_size);
--    kfree(blk_ptr);
-+    free(blk_ptr);
-   }
- }
-
-diff -uprN orig/tpm_emulator-0.4/crypto/rsa.c tpm_emulator/crypto/rsa.c
---- orig/tpm_emulator-0.4/crypto/rsa.c    2006-06-23 03:37:07.000000000
-0700
-+++ tpm_emulator/crypto/rsa.c    2006-07-24 14:35:35.000000000 -0700
-@@ -1,5 +1,6 @@
- /* Software-Based Trusted Platform Module (TPM) Emulator for Linux
-  * Copyright (C) 2004 Mario Strasser <mast@gmx.net>,
-+ * Copyright (C) 2005 INTEL Corp
-  *
-  * This module is free software; you can redistribute it and/or modify
-  * it under the terms of the GNU General Public License as published
-@@ -381,7 +382,7 @@ static int encode_message(int type, uint
-       msg[0] =3D 0x00;
-       get_random_bytes(&msg[1], SHA1_DIGEST_LENGTH);
-       sha1_init(&ctx);
--      sha1_update(&ctx, "TCPA", 4);
-+      sha1_update(&ctx, (uint8_t *) "TCPA", 4);
-       sha1_final(&ctx, &msg[1 + SHA1_DIGEST_LENGTH]);
-       memset(&msg[1 + 2 * SHA1_DIGEST_LENGTH], 0x00,
-         msg_len - data_len - 2 * SHA1_DIGEST_LENGTH - 2);
-@@ -429,7 +430,7 @@ static int decode_message(int type, uint
-       mask_generation(&msg[1], SHA1_DIGEST_LENGTH,
-         &msg[1 + SHA1_DIGEST_LENGTH], msg_len - SHA1_DIGEST_LENGTH - 1)=
;
-       sha1_init(&ctx);
--      sha1_update(&ctx, "TCPA", 4);
-+      sha1_update(&ctx, (uint8_t *) "TCPA", 4);
-       sha1_final(&ctx, &msg[1]);
-       if (memcmp(&msg[1], &msg[1 + SHA1_DIGEST_LENGTH],
-           SHA1_DIGEST_LENGTH) !=3D 0) return -1;
-diff -uprN orig/tpm_emulator-0.4/linux_module.c tpm_emulator/linux_modul=
e.c
---- orig/tpm_emulator-0.4/linux_module.c    2006-06-23
03:37:07.000000000 -0700
-+++ tpm_emulator/linux_module.c    1969-12-31 16:00:00.000000000 -0800
-@@ -1,195 +0,0 @@
--/* Software-Based Trusted Platform Module (TPM) Emulator for Linux
-- * Copyright (C) 2004 Mario Strasser <mast@gmx.net>,
-- *
-- * This module 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.=20
-- *
-- * This module 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.
-- *
-- * $Id: linux_module.c 91 2006-03-13 13:51:41Z mast $
-- */
--
--#include <linux/module.h>
--#include <linux/kernel.h>
--#include <linux/init.h>
--#include <linux/miscdevice.h>
--#include <linux/poll.h>
--#include "linux_module.h"
--#include "tpm/tpm_emulator.h"
--
--MODULE_LICENSE("GPL");
--MODULE_AUTHOR("Mario Strasser <mast@gmx.net>");
--MODULE_DESCRIPTION("Trusted Platform Module (TPM) Emulator");
--MODULE_SUPPORTED_DEVICE(TPM_DEVICE_NAME);
--
--/* module startup parameters */
--char *startup =3D "save";
--module_param(startup, charp, 0444);
--MODULE_PARM_DESC(startup, " Sets the startup mode of the TPM. "
--  "Possible values are 'clear', 'save' (default) and 'deactivated.");
--char *storage_file =3D "/var/tpm/tpm_emulator-1.2.0.2";
--module_param(storage_file, charp, 0644);
--MODULE_PARM_DESC(storage_file, " Sets the persistent-data storage "
--  "file of the TPM.");
--
--/* TPM lock */
--static struct semaphore tpm_mutex;
--
--/* TPM command response */
--static struct {
--  uint8_t *data;
--  uint32_t size;
--} tpm_response;
--
--/* module state */
--#define STATE_IS_OPEN 0
--static uint32_t module_state;
--static struct timespec old_time;
--
--static int tpm_open(struct inode *inode, struct file *file)
--{
--  debug("%s()", __FUNCTION__);
--  if (test_and_set_bit(STATE_IS_OPEN, (void*)&module_state)) return
-EBUSY;
--  return 0;
--}
--
--static int tpm_release(struct inode *inode, struct file *file)
--{
--  debug("%s()", __FUNCTION__);
--  clear_bit(STATE_IS_OPEN, (void*)&module_state);
--  down(&tpm_mutex);
--  if (tpm_response.data !=3D NULL) {
--    kfree(tpm_response.data);
--    tpm_response.data =3D NULL;
--  }
--  up(&tpm_mutex);
--  return 0;
--}
--
--static ssize_t tpm_read(struct file *file, char *buf, size_t count,
loff_t *ppos)
--{
--  debug("%s(%d)", __FUNCTION__, count);
--  down(&tpm_mutex);
--  if (tpm_response.data !=3D NULL) {
--    count =3D min(count, (size_t)tpm_response.size - (size_t)*ppos);
--    count -=3D copy_to_user(buf, &tpm_response.data[*ppos], count);
--    *ppos +=3D count;
--    if ((size_t)tpm_response.size =3D=3D (size_t)*ppos) {
--      kfree(tpm_response.data);
--      tpm_response.data =3D NULL;
--    }
--  } else {
--    count =3D 0;
--  }
--  up(&tpm_mutex);
--  return count;
--}
--
--static ssize_t tpm_write(struct file *file, const char *buf, size_t
count, loff_t *ppos)
--{
--  debug("%s(%d)", __FUNCTION__, count);
--  down(&tpm_mutex);
--  *ppos =3D 0;
--  if (tpm_response.data !=3D NULL) kfree(tpm_response.data);
--  if (tpm_handle_command(buf, count, &tpm_response.data,
--                         &tpm_response.size) !=3D 0) {
--    count =3D -EILSEQ;
--    tpm_response.data =3D NULL;
--  }
--  up(&tpm_mutex);
--  return count;
--}
--
--#define TPMIOC_CANCEL   _IO('T', 0x00)
--#define TPMIOC_TRANSMIT _IO('T', 0x01)
--
--static int tpm_ioctl(struct inode *inode, struct file *file, unsigned
int cmd, unsigned long arg)
--{
--  debug("%s(%d, %p)", __FUNCTION__, cmd, (char*)arg);
--  if (cmd =3D=3D TPMIOC_TRANSMIT) {
--    uint32_t count =3D ntohl(*(uint32_t*)(arg + 2));
--    down(&tpm_mutex);
--    if (tpm_response.data !=3D NULL) kfree(tpm_response.data);
--    if (tpm_handle_command((char*)arg, count, &tpm_response.data,
--                           &tpm_response.size) =3D=3D 0) {
--      tpm_response.size -=3D copy_to_user((char*)arg, tpm_response.data=
,
--                            tpm_response.size);
--      kfree(tpm_response.data);
--      tpm_response.data =3D NULL;
--    } else {
--      tpm_response.size =3D 0;
--      tpm_response.data =3D NULL;
--    }
--    up(&tpm_mutex);
--    return tpm_response.size;
--  }
--  return -1;
--}
--
--struct file_operations fops =3D {
--  .owner   =3D THIS_MODULE,
--  .open    =3D tpm_open,
--  .release =3D tpm_release,
--  .read    =3D tpm_read,
--  .write   =3D tpm_write,
--  .ioctl   =3D tpm_ioctl,
--};
--
--static struct miscdevice tpm_dev =3D {
--  .minor      =3D TPM_DEVICE_MINOR,
--  .name       =3D TPM_DEVICE_NAME,
--  .fops       =3D &fops,
--};
--
--int __init init_tpm_module(void)
--{
--  int res =3D misc_register(&tpm_dev);
--  if (res !=3D 0) {
--    error("misc_register() failed for minor %d\n", TPM_DEVICE_MINOR);
--    return res;
--  }
--  /* initialize variables */
--  sema_init(&tpm_mutex, 1);
--  module_state =3D 0;
--  tpm_response.data =3D NULL;
--  old_time =3D current_kernel_time();
--  /* initialize TPM emulator */
--  if (!strcmp(startup, "clear")) {
--    tpm_emulator_init(1);
--  } else if (!strcmp(startup, "save")) {
--    tpm_emulator_init(2);
--  } else if (!strcmp(startup, "deactivated")) {
--    tpm_emulator_init(3);
--  } else {
--    error("invalid startup mode '%s'; must be 'clear', "
--      "'save' (default) or 'deactivated", startup);
--    misc_deregister(&tpm_dev);
--    return -EINVAL;
--  }
--  return 0;
--}
--
--void __exit cleanup_tpm_module(void)
--{
--  tpm_emulator_shutdown();
--  misc_deregister(&tpm_dev);
--  if (tpm_response.data !=3D NULL) kfree(tpm_response.data);
--}
--
--module_init(init_tpm_module);
--module_exit(cleanup_tpm_module);
--
--uint64_t tpm_get_ticks(void)
--{
--  struct timespec new_time =3D current_kernel_time();
--  uint64_t ticks =3D (uint64_t)(new_time.tv_sec - old_time.tv_sec) * 10=
00000
--                   + (new_time.tv_nsec - old_time.tv_nsec) / 1000;
--  old_time =3D new_time;
--  return (ticks > 0) ? ticks : 1;
--}
--
-diff -uprN orig/tpm_emulator-0.4/linux_module.h tpm_emulator/linux_modul=
e.h
---- orig/tpm_emulator-0.4/linux_module.h    2006-06-23
03:37:07.000000000 -0700
-+++ tpm_emulator/linux_module.h    2006-07-24 14:35:35.000000000 -0700
-@@ -1,5 +1,6 @@
- /* Software-Based Trusted Platform Module (TPM) Emulator for Linux
-  * Copyright (C) 2004 Mario Strasser <mast@gmx.net>,
-+ * Copyright (C) 2005 INTEL Corp
-  *
-  * This module is free software; you can redistribute it and/or modify
-  * it under the terms of the GNU General Public License as published
-@@ -17,54 +18,62 @@
- #ifndef _LINUX_MODULE_H_
- #define _LINUX_MODULE_H_
-
--#include <linux/version.h>
--#include <linux/kernel.h>
--#include <linux/slab.h>
-+#include <malloc.h>
-+#include <stdint.h>
-+#include <stdio.h>
-+#include <string.h>
- #include <linux/types.h>
--#include <linux/string.h>
--#include <linux/random.h>
--#include <linux/time.h>
--#include <asm/byteorder.h>
-
--/* module settings */
-+#include <endian.h>
-+#define __BYTEORDER_HAS_U64__
-+#ifdef LITTLE_ENDIAN
-+ #include <linux/byteorder/little_endian.h>
-+#else
-+ #include <linux/byteorder/big_endian.h>
-+#endif
-
-+/* module settings */
-+#define min(A,B) ((A)<(B)?(A):(B))
-+#ifndef STR
- #define STR(s) __STR__(s)
- #define __STR__(s) #s
-+#endif
- #include "tpm_version.h"
-
- #define TPM_DEVICE_MINOR  224
- #define TPM_DEVICE_NAME   "tpm"
- #define TPM_MODULE_NAME   "tpm_emulator"
-
--/* debug and log output functions */
--
- #ifdef DEBUG
--#define debug(fmt, ...) printk(KERN_DEBUG "%s %s:%d: Debug: " fmt "\n",=
 \
--                        TPM_MODULE_NAME, __FILE__, __LINE__, ##
__VA_ARGS__)
-+#define debug(fmt, ...) printf("TPMD: %s:%d: Debug: " fmt "\n", \
-+                        __FILE__, __LINE__, ## __VA_ARGS__)
- #else
- #define debug(fmt, ...)
- #endif
--#define info(fmt, ...)  printk(KERN_INFO "%s %s:%d: Info: " fmt "\n", \=

--                        TPM_MODULE_NAME, __FILE__, __LINE__, ##
__VA_ARGS__)
--#define error(fmt, ...) printk(KERN_ERR "%s %s:%d: Error: " fmt "\n", \=

--                        TPM_MODULE_NAME, __FILE__, __LINE__, ##
__VA_ARGS__)
--#define alert(fmt, ...) printk(KERN_ALERT "%s %s:%d: Alert: " fmt "\n",=
 \
--                        TPM_MODULE_NAME, __FILE__, __LINE__, ##
__VA_ARGS__)
-+#define info(fmt, ...)  printf("TPMD: %s:%d: Info: " fmt "\n", \
-+                        __FILE__, __LINE__, ## __VA_ARGS__)
-+#define error(fmt, ...) printf("TPMD: %s:%d: Error: " fmt "\n", \
-+                        __FILE__, __LINE__, ## __VA_ARGS__)
-+#define alert(fmt, ...) printf("TPMD: %s:%d: Alert: " fmt "\n", \
-+                        __FILE__, __LINE__, ## __VA_ARGS__)
-
- /* memory allocation */
-
- static inline void *tpm_malloc(size_t size)
- {
--  return kmalloc(size, GFP_KERNEL);=20
-+  return malloc(size);=20
- }
-
- static inline void tpm_free(const void *ptr)
- {
--  if (ptr !=3D NULL) kfree(ptr);
-+  if (ptr !=3D NULL) free( (void *) ptr);
- }
-
- /* random numbers */
-
-+//FIXME;
-+void get_random_bytes(void *buf, int nbytes);
-+
- static inline void tpm_get_random_bytes(void *buf, int nbytes)
- {
-   get_random_bytes(buf, nbytes);
-@@ -84,9 +93,9 @@ uint64_t tpm_get_ticks(void);
- #define CPU_TO_LE16(x) __cpu_to_le16(x)
-
- #define BE64_TO_CPU(x) __be64_to_cpu(x)
--#define LE64_TO_CPU(x) __be64_to_cpu(x)
-+#define LE64_TO_CPU(x) __le64_to_cpu(x)
- #define BE32_TO_CPU(x) __be32_to_cpu(x)
--#define LE32_TO_CPU(x) __be32_to_cpu(x)
-+#define LE32_TO_CPU(x) __le32_to_cpu(x)
- #define BE16_TO_CPU(x) __be16_to_cpu(x)
- #define LE16_TO_CPU(x) __le16_to_cpu(x)
-
-diff -uprN orig/tpm_emulator-0.4/Makefile tpm_emulator/Makefile
---- orig/tpm_emulator-0.4/Makefile    2006-06-23 03:37:07.000000000 -070=
0
-+++ tpm_emulator/Makefile    2006-07-24 14:35:35.000000000 -0700
-@@ -1,24 +1,40 @@
- # Software-Based Trusted Platform Module (TPM) Emulator for Linux
- # Copyright (C) 2004 Mario Strasser <mast@gmx.net>
-+# Copyright (C) 2006 INTEL Corp.
- #
- # $Id: Makefile 115 2006-06-23 10:36:44Z mast $
-
--# kernel settings
--KERNEL_RELEASE :=3D $(shell uname -r)
--KERNEL_BUILD   :=3D /lib/modules/$(KERNEL_RELEASE)/build
--MOD_SUBDIR     :=3D misc
-+COMPILE_ARCH    ?=3D $(shell uname -m | sed -e s/i.86/x86_32/)
-
- # module settings
--MODULE_NAME    :=3D tpm_emulator
-+BIN            :=3D tpm_emulator
- VERSION_MAJOR  :=3D 0
- VERSION_MINOR  :=3D 4
- VERSION_BUILD  :=3D $(shell date +"%s")
-
--# enable/disable DEBUG messages
--EXTRA_CFLAGS   +=3D -Wall -DDEBUG -g=20
-+# Installation program and options
-+INSTALL         =3D install
-+INSTALL_PROG    =3D $(INSTALL) -m0755
-+INSTALL_DIR     =3D $(INSTALL) -d -m0755
-+
-+# Xen tools installation directory
-+TOOLS_INSTALL_DIR =3D $(DESTDIR)/usr/bin
-+
-+CC      :=3D gcc
-+CFLAGS  +=3D -g -Wall $(INCLUDE) -DDEBUG
-+CFLAGS  +=3D -I. -Itpm
-+
-+# Is the simulator running in it's own vm?
-+#CFLAGS +=3D -DVTPM_MULTI_VM
-+
-+ifeq ($(COMPILE_ARCH),x86_64)
-+LIBDIR =3D lib64
-+else
-+LIBDIR =3D lib
-+endif
-
- # GNU MP configuration
--GMP_LIB        :=3D /usr/lib/libgmp.a
-+GMP_LIB        :=3D /usr/$(LIBDIR)/libgmp.a
- GMP_HEADER     :=3D /usr/include/gmp.h
-
- # sources and objects
-@@ -27,38 +43,32 @@ DIRS           :=3D . crypto tpm
- SRCS           :=3D $(foreach dir, $(DIRS), $(wildcard $(src)/$(dir)/*.=
c))
- OBJS           :=3D $(patsubst %.c, %.o, $(SRCS))
- SRCS           +=3D $(foreach dir, $(DIRS), $(wildcard $(src)/$(dir)/*.=
h))
--DISTSRC        :=3D ./README ./AUTHORS ./ChangeLog ./Makefile $(SRCS)
--DISTDIR        :=3D tpm_emulator-$(VERSION_MAJOR).$(VERSION_MINOR)
-
--obj-m               :=3D $(MODULE_NAME).o
--$(MODULE_NAME)-objs :=3D $(patsubst $(src)/%.o, %.o, $(OBJS))
crypto/libgmp.a
-+obj-m               :=3D $(BIN)
-+$(BIN)-objs :=3D $(patsubst $(src)/%.o, %.o, $(OBJS)) crypto/libgmp.a
-
- EXTRA_CFLAGS   +=3D -I$(src) -I$(src)/crypto -I$(src)/tpm
-
- # do not print "Entering directory ..."
- MAKEFLAGS      +=3D --no-print-directory
-
--all:    $(src)/crypto/gmp.h $(src)/crypto/libgmp.a version
--    @$(MAKE) -C $(KERNEL_BUILD) M=3D$(CURDIR) modules
-+all: $(BIN)
-
--install:
--    @$(MAKE) -C $(KERNEL_BUILD) M=3D$(CURDIR) modules_install
--    test -d /var/tpm || mkdir /var/tpm
--    test -c /dev/tpm || mknod /dev/tpm c 10 224
--    chmod 666 /dev/tpm
--    depmod -a
-+$(BIN):    $(src)/crypto/gmp.h $(src)/crypto/libgmp.a version $(SRCS)
$(OBJS)
-+    $(CC) $(CFLAGS) $(OBJS) $(src)/crypto/libgmp.a -o $(BIN)
-+
-+%.o: %.c
-+    $(CC) $(CFLAGS) -c $< -o $@
-+
-+install: $(BIN)
-+    $(INSTALL_PROG) $(BIN) $(TOOLS_INSTALL_DIR)
-+    @if [ ! -d "/var/tpm" ]; then mkdir /var/tpm; fi
-
- clean:
--    @$(MAKE) -C $(KERNEL_BUILD) M=3D$(CURDIR) clean
--    rm -f $(src)/crypto/gmp.h $(src)/crypto/libgmp.a
-+    rm -f $(src)/crypto/gmp.h $(src)/crypto/libgmp.a $(OBJS)
-
--dist:    $(DISTSRC)
--    rm -rf $(DISTDIR)
--    mkdir $(DISTDIR)
--    cp --parents $(DISTSRC) $(DISTDIR)/
--    rm -f $(DISTDIR)/crypto/gmp.h
--    tar -chzf $(DISTDIR).tar.gz $(DISTDIR)
--    rm -rf $(DISTDIR)
-+mrproper: clean
-+    rm -f $(BIN) tpm_version.h
-
- $(src)/crypto/libgmp.a:
-     test -f $(src)/crypto/libgmp.a || ln -s $(GMP_LIB)
$(src)/crypto/libgmp.a
-@@ -88,4 +98,3 @@ version:
-     @echo "#endif /* _TPM_VERSION_H_ */" >> $(src)/tpm_version.h
-
- .PHONY: all install clean dist gmp version
--
-diff -uprN orig/tpm_emulator-0.4/README tpm_emulator/README
---- orig/tpm_emulator-0.4/README    2006-06-23 03:37:07.000000000 -0700
-+++ tpm_emulator/README    2006-07-24 14:35:35.000000000 -0700
-@@ -13,7 +13,8 @@ $Id: README 113 2006-06-18 12:38:13Z hst
- Copyright
- -----------------------------------------------------------------------=
---
- Copyright (C) 2004 Mario Strasser <mast@gmx.net> and Swiss Federal
--Institute of Technology (ETH) Zurich.
-+                   Institute of Technology (ETH) Zurich.
-+Copyright (C) 2005 INTEL Corp
-             =20
- 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
-@@ -43,6 +44,12 @@ Example:
- GMP_LIB        :=3D /usr/lib/libgmp.a
- GMP_HEADER     :=3D /usr/include/gmp.h
-
-+GNU MP Library on 64 bit Systems
-+-----------------------------------------------------------------------=
---
-+Some 64-bit kernels have problems with importing the user-space gmp
-+library (/usr/lib*/libgmp.a) into kernel space.  These kernels will
require
-+that the gmp library be recompiled for kernel space with -mcmodel=3Dker=
nel.
-+
- Installation
- -----------------------------------------------------------------------=
---
- The compilation and installation process uses the build environment for=

-diff -uprN orig/tpm_emulator-0.4/tpm/tpm_capability.c
tpm_emulator/tpm/tpm_capability.c
---- orig/tpm_emulator-0.4/tpm/tpm_capability.c    2006-06-23
19:37:07.000000000 +0900
-+++ tpm_emulator/tpm/tpm_capability.c    2007-12-28 22:50:19.000000000
+0900
-@@ -701,7 +701,10 @@ TPM_RESULT TPM_GetCapabilityOwner(TPM_VE
-   TPM_RESULT res;
- =20
-   info("TPM_GetCapabilityOwner()");
--=20
-+
-+  if (!tpmData.permanent.flags.owned) {
-+    return TPM_NOSRK;
-+  }
-   /* Verify owner authorization */
-   res =3D tpm_verify_auth(auth1, tpmData.permanent.data.ownerAuth,
TPM_KH_OWNER);
-   if (res !=3D TPM_SUCCESS) return res;
-diff -uprN orig/tpm_emulator-0.4/tpm/tpm_cmd_handler.c
tpm_emulator/tpm/tpm_cmd_handler.c
---- orig/tpm_emulator-0.4/tpm/tpm_cmd_handler.c    2006-06-23
19:37:07.000000000 +0900
-+++ tpm_emulator/tpm/tpm_cmd_handler.c    2007-09-12 20:23:00.000000000
+0900
-@@ -565,7 +565,7 @@ static TPM_RESULT execute_TPM_Seal(TPM_R
-   if (tpm_unmarshal_TPM_KEY_HANDLE(&ptr, &len, &keyHandle)
-       || tpm_unmarshal_TPM_ENCAUTH(&ptr, &len, &encAuth)
-       || tpm_unmarshal_UINT32(&ptr, &len, &pcrInfoSize)
--      || tpm_unmarshal_TPM_PCR_INFO(&ptr, &len, &pcrInfo)
-+      || (pcrInfoSize >0 && tpm_unmarshal_TPM_PCR_INFO(&ptr, &len,
&pcrInfo))
-       || tpm_unmarshal_UINT32(&ptr, &len, &inDataSize)
-       || tpm_unmarshal_BLOB(&ptr, &len, &inData, inDataSize)
-       || len !=3D 0) return TPM_BAD_PARAMETER;
-@@ -798,7 +798,7 @@ static TPM_RESULT execute_TPM_Sealx(TPM_
-   if (tpm_unmarshal_TPM_KEY_HANDLE(&ptr, &len, &keyHandle)
-       || tpm_unmarshal_TPM_ENCAUTH(&ptr, &len, &encAuth)
-       || tpm_unmarshal_UINT32(&ptr, &len, &pcrInfoSize)
--      || tpm_unmarshal_TPM_PCR_INFO(&ptr, &len, &pcrInfo)
-+      || (pcrInfoSize > 0 && tpm_unmarshal_TPM_PCR_INFO(&ptr, &len,
&pcrInfo))
-       || tpm_unmarshal_UINT32(&ptr, &len, &inDataSize)
-       || tpm_unmarshal_BLOB(&ptr, &len, &inData, inDataSize)
-       || len !=3D 0) return TPM_BAD_PARAMETER;
-diff -uprN orig/tpm_emulator-0.4/tpm/tpm_credentials.c
tpm_emulator/tpm/tpm_credentials.c
---- orig/tpm_emulator-0.4/tpm/tpm_credentials.c    2006-06-23
19:37:07.000000000 +0900
-+++ tpm_emulator/tpm/tpm_credentials.c    2007-09-12 20:23:30.000000000
+0900
-@@ -47,20 +47,20 @@ int tpm_compute_pubkey_checksum(TPM_NONC
-
- TPM_RESULT tpm_get_pubek(TPM_PUBKEY *pubEndorsementKey)
- {
--  UINT32 key_length;
-+  size_t key_length;
-   if (!tpmData.permanent.data.endorsementKey.size) return
TPM_NO_ENDORSEMENT;
-   /* setup TPM_PUBKEY structure */
--  key_length =3D tpmData.permanent.data.endorsementKey.size;
--  pubEndorsementKey->pubKey.keyLength =3D key_length >> 3;
-+  pubEndorsementKey->pubKey.keyLength =3D
tpmData.permanent.data.endorsementKey.size >> 3;
-   pubEndorsementKey->pubKey.key =3D
tpm_malloc(pubEndorsementKey->pubKey.keyLength);
-   if (pubEndorsementKey->pubKey.key =3D=3D NULL) return TPM_FAIL;
-   rsa_export_modulus(&tpmData.permanent.data.endorsementKey,
--    pubEndorsementKey->pubKey.key,
--    &pubEndorsementKey->pubKey.keyLength);
-+             pubEndorsementKey->pubKey.key,
-+             &key_length);
-+  pubEndorsementKey->pubKey.keyLength =3D key_length;
-   pubEndorsementKey->algorithmParms.algorithmID =3D TPM_ALG_RSA;
-   pubEndorsementKey->algorithmParms.encScheme =3D
TPM_ES_RSAESOAEP_SHA1_MGF1;
-   pubEndorsementKey->algorithmParms.sigScheme =3D TPM_SS_NONE;
--  pubEndorsementKey->algorithmParms.parms.rsa.keyLength =3D key_length;=

-+  pubEndorsementKey->algorithmParms.parms.rsa.keyLength =3D key_length =
<< 3;
-   pubEndorsementKey->algorithmParms.parms.rsa.numPrimes =3D 2;
-   pubEndorsementKey->algorithmParms.parms.rsa.exponentSize =3D 0;
-   pubEndorsementKey->algorithmParms.parms.rsa.exponent =3D NULL;
-@@ -175,6 +175,7 @@ TPM_RESULT TPM_OwnerReadInternalPub(TPM_
- {
-   TPM_RESULT res;
-   TPM_KEY_DATA *srk =3D &tpmData.permanent.data.srk;
-+  size_t key_length;
-   info("TPM_OwnerReadInternalPub()");
-   /* verify authorization */
-   res =3D tpm_verify_auth(auth1, tpmData.permanent.data.ownerAuth,
TPM_KH_OWNER);
-@@ -186,7 +187,8 @@ TPM_RESULT TPM_OwnerReadInternalPub(TPM_
-     publicPortion->pubKey.key =3D
tpm_malloc(publicPortion->pubKey.keyLength);
-     if (publicPortion->pubKey.key =3D=3D NULL) return TPM_FAIL;
-     rsa_export_modulus(&srk->key, publicPortion->pubKey.key,
--      &publicPortion->pubKey.keyLength);
-+      &key_length);
-+    publicPortion->pubKey.keyLength =3D key_length;
-     publicPortion->algorithmParms.algorithmID =3D TPM_ALG_RSA;
-     publicPortion->algorithmParms.encScheme =3D srk->encScheme;
-     publicPortion->algorithmParms.sigScheme =3D srk->sigScheme;
-diff -uprN orig/tpm_emulator-0.4/tpm/tpm_crypto.c
tpm_emulator/tpm/tpm_crypto.c
---- orig/tpm_emulator-0.4/tpm/tpm_crypto.c    2006-06-23
03:37:07.000000000 -0700
-+++ tpm_emulator/tpm/tpm_crypto.c    2006-07-24 14:35:35.000000000 -0700=

-@@ -182,7 +182,8 @@ TPM_RESULT TPM_CertifyKey(TPM_KEY_HANDLE
-   TPM_KEY_DATA *cert, *key;
-   sha1_ctx_t sha1_ctx;
-   BYTE *buf, *p;
--  UINT32 length;
-+  UINT32 length32;
-+  size_t length;
-   info("TPM_CertifyKey()");
-   /* get keys */
-   cert =3D tpm_get_key(certHandle);
-@@ -264,14 +265,15 @@ TPM_RESULT TPM_CertifyKey(TPM_KEY_HANDLE
-   /* compute the digest of the CERTIFY_INFO[2] structure and sign it */=

-   length =3D sizeof_TPM_CERTIFY_INFO((*certifyInfo));
-   p =3D buf =3D tpm_malloc(length);
-+  length32=3D(UINT32) length;
-   if (buf =3D=3D NULL
--      || tpm_marshal_TPM_CERTIFY_INFO(&p, &length, certifyInfo)) {
-+      || tpm_marshal_TPM_CERTIFY_INFO(&p, &length32, certifyInfo)) {
-     free_TPM_KEY_PARMS(certifyInfo->algorithmParms);
-     return TPM_FAIL;
-   }
-   length =3D sizeof_TPM_CERTIFY_INFO((*certifyInfo));
-   sha1_init(&sha1_ctx);
--  sha1_update(&sha1_ctx, buf, length);
-+  sha1_update(&sha1_ctx, buf, (size_t) length);
-   sha1_final(&sha1_ctx, buf);
-   res =3D tpm_sign(cert, auth1, FALSE, buf, SHA1_DIGEST_LENGTH, outData=
,
outDataSize);
-   tpm_free(buf);
-@@ -292,7 +294,8 @@ TPM_RESULT TPM_CertifyKey2(TPM_KEY_HANDL
-   TPM_KEY_DATA *cert, *key;
-   sha1_ctx_t sha1_ctx;
-   BYTE *buf, *p;
--  UINT32 length;
-+  size_t length;
-+  UINT32 length32;
-   info("TPM_CertifyKey2()");
-   /* get keys */
-   cert =3D tpm_get_key(certHandle);
-@@ -362,8 +365,9 @@ TPM_RESULT TPM_CertifyKey2(TPM_KEY_HANDL
-   /* compute the digest of the CERTIFY_INFO[2] structure and sign it */=

-   length =3D sizeof_TPM_CERTIFY_INFO((*certifyInfo));
-   p =3D buf =3D tpm_malloc(length);
-+  length32 =3D (UINT32) length;
-   if (buf =3D=3D NULL
--      || tpm_marshal_TPM_CERTIFY_INFO(&p, &length, certifyInfo)) {
-+      || tpm_marshal_TPM_CERTIFY_INFO(&p, &length32, certifyInfo)) {
-     free_TPM_KEY_PARMS(certifyInfo->algorithmParms);
-     return TPM_FAIL;
-   }
-diff -uprN orig/tpm_emulator-0.4/tpm/tpm_daa.c tpm_emulator/tpm/tpm_daa.=
c
---- orig/tpm_emulator-0.4/tpm/tpm_daa.c    2006-06-23
03:37:07.000000000 -0700
-+++ tpm_emulator/tpm/tpm_daa.c    2006-07-24 14:35:35.000000000 -0700
-@@ -716,14 +716,14 @@ TPM_RESULT TPM_DAA_Join(TPM_HANDLE handl
-           sizeof(session->DAA_tpmSpecific.DAA_rekey));
-       sha1_update(&sha1, (BYTE*) &session->DAA_tpmSpecific.DAA_count,
-           sizeof(session->DAA_tpmSpecific.DAA_count));
--      sha1_update(&sha1, "\x00", 1);
-+      sha1_update(&sha1, (BYTE *) "\x00", 1);
-       sha1_final(&sha1, scratch);
-       sha1_init(&sha1);
-       sha1_update(&sha1, (BYTE*) &session->DAA_tpmSpecific.DAA_rekey,
-           sizeof(session->DAA_tpmSpecific.DAA_rekey));
-       sha1_update(&sha1, (BYTE*) &session->DAA_tpmSpecific.DAA_count,
-           sizeof(session->DAA_tpmSpecific.DAA_count));
--      sha1_update(&sha1, "\x01", 1);
-+      sha1_update(&sha1, (BYTE *) "\x01", 1);
-       sha1_final(&sha1, scratch + SHA1_DIGEST_LENGTH);
-       mpz_init(f), mpz_init(q);
-       mpz_import(f, 2 * SHA1_DIGEST_LENGTH, 1, 1, 0, 0, scratch);
-@@ -805,14 +805,14 @@ TPM_RESULT TPM_DAA_Join(TPM_HANDLE handl
-           sizeof(session->DAA_tpmSpecific.DAA_rekey));
-       sha1_update(&sha1, (BYTE*) &session->DAA_tpmSpecific.DAA_count,
-           sizeof(session->DAA_tpmSpecific.DAA_count));
--      sha1_update(&sha1, "\x00", 1);
-+      sha1_update(&sha1, (BYTE *) "\x00", 1);
-       sha1_final(&sha1, scratch);
-       sha1_init(&sha1);
-       sha1_update(&sha1, (BYTE*) &session->DAA_tpmSpecific.DAA_rekey,
-           sizeof(session->DAA_tpmSpecific.DAA_rekey));
-       sha1_update(&sha1, (BYTE*) &session->DAA_tpmSpecific.DAA_count,
-           sizeof(session->DAA_tpmSpecific.DAA_count));
--      sha1_update(&sha1, "\x01", 1);
-+      sha1_update(&sha1, (BYTE *) "\x01", 1);
-       sha1_final(&sha1, scratch + SHA1_DIGEST_LENGTH);
-       mpz_init(f), mpz_init(q);
-       mpz_import(f, 2 * SHA1_DIGEST_LENGTH, 1, 1, 0, 0, scratch);
-@@ -1489,14 +1489,14 @@ TPM_RESULT TPM_DAA_Join(TPM_HANDLE handl
-           sizeof(session->DAA_tpmSpecific.DAA_rekey));
-       sha1_update(&sha1, (BYTE*) &session->DAA_tpmSpecific.DAA_count,
-           sizeof(session->DAA_tpmSpecific.DAA_count));
--      sha1_update(&sha1, "\x00", 1);
-+      sha1_update(&sha1, (BYTE *) "\x00", 1);
-       sha1_final(&sha1, scratch);
-       sha1_init(&sha1);
-       sha1_update(&sha1, (BYTE*) &session->DAA_tpmSpecific.DAA_rekey,
-           sizeof(session->DAA_tpmSpecific.DAA_rekey));
-       sha1_update(&sha1, (BYTE*) &session->DAA_tpmSpecific.DAA_count,
-           sizeof(session->DAA_tpmSpecific.DAA_count));
--      sha1_update(&sha1, "\x01", 1);
-+      sha1_update(&sha1, (BYTE *) "\x01", 1);
-       sha1_final(&sha1, scratch + SHA1_DIGEST_LENGTH);
-       mpz_init(f), mpz_init(q);
-       mpz_import(f, 2 * SHA1_DIGEST_LENGTH, 1, 1, 0, 0, scratch);
-@@ -1712,14 +1712,14 @@ TPM_RESULT TPM_DAA_Join(TPM_HANDLE handl
-           sizeof(session->DAA_tpmSpecific.DAA_rekey));
-       sha1_update(&sha1, (BYTE*) &session->DAA_tpmSpecific.DAA_count,
-           sizeof(session->DAA_tpmSpecific.DAA_count));
--      sha1_update(&sha1, "\x00", 1);
-+      sha1_update(&sha1, (BYTE *) "\x00", 1);
-       sha1_final(&sha1, scratch);
-       sha1_init(&sha1);
-       sha1_update(&sha1, (BYTE*) &session->DAA_tpmSpecific.DAA_rekey,
-           sizeof(session->DAA_tpmSpecific.DAA_rekey));
-       sha1_update(&sha1, (BYTE*) &session->DAA_tpmSpecific.DAA_count,
-           sizeof(session->DAA_tpmSpecific.DAA_count));
--      sha1_update(&sha1, "\x01", 1);
-+      sha1_update(&sha1, (BYTE *) "\x01", 1);
-       sha1_final(&sha1, scratch + SHA1_DIGEST_LENGTH);
-       mpz_init(f), mpz_init(q);
-       mpz_import(f, 2 * SHA1_DIGEST_LENGTH, 1, 1, 0, 0, scratch);
-@@ -1793,14 +1793,14 @@ TPM_RESULT TPM_DAA_Join(TPM_HANDLE handl
-           sizeof(session->DAA_tpmSpecific.DAA_rekey));
-       sha1_update(&sha1, (BYTE*) &session->DAA_tpmSpecific.DAA_count,
-           sizeof(session->DAA_tpmSpecific.DAA_count));
--      sha1_update(&sha1, "\x00", 1);
-+      sha1_update(&sha1, (BYTE *) "\x00", 1);
-       sha1_final(&sha1, scratch);
-       sha1_init(&sha1);
-       sha1_update(&sha1, (BYTE*) &session->DAA_tpmSpecific.DAA_rekey,
-           sizeof(session->DAA_tpmSpecific.DAA_rekey));
-       sha1_update(&sha1, (BYTE*) &session->DAA_tpmSpecific.DAA_count,
-           sizeof(session->DAA_tpmSpecific.DAA_count));
--      sha1_update(&sha1, "\x01", 1);
-+      sha1_update(&sha1, (BYTE *) "\x01", 1);
-       sha1_final(&sha1, scratch + SHA1_DIGEST_LENGTH);
-       mpz_init(f), mpz_init(q);
-       mpz_import(f, 2 * SHA1_DIGEST_LENGTH, 1, 1, 0, 0, scratch);
-@@ -2918,14 +2918,14 @@ TPM_RESULT TPM_DAA_Sign(TPM_HANDLE handl
-           sizeof(session->DAA_tpmSpecific.DAA_rekey));
-       sha1_update(&sha1, (BYTE*) &session->DAA_tpmSpecific.DAA_count,
-           sizeof(session->DAA_tpmSpecific.DAA_count));
--      sha1_update(&sha1, "\x00", 1);
-+      sha1_update(&sha1, (BYTE *) "\x00", 1);
-       sha1_final(&sha1, scratch);
-       sha1_init(&sha1);
-       sha1_update(&sha1, (BYTE*) &session->DAA_tpmSpecific.DAA_rekey,
-           sizeof(session->DAA_tpmSpecific.DAA_rekey));
-       sha1_update(&sha1, (BYTE*) &session->DAA_tpmSpecific.DAA_count,
-           sizeof(session->DAA_tpmSpecific.DAA_count));
--      sha1_update(&sha1, "\x01", 1);
-+      sha1_update(&sha1, (BYTE *) "\x01", 1);
-       sha1_final(&sha1, scratch + SHA1_DIGEST_LENGTH);
-       mpz_init(f), mpz_init(q);
-       mpz_import(f, 2 * SHA1_DIGEST_LENGTH, 1, 1, 0, 0, scratch);
-@@ -3143,7 +3143,7 @@ TPM_RESULT TPM_DAA_Sign(TPM_HANDLE handl
-         sha1_init(&sha1);
-         sha1_update(&sha1, (BYTE*) &session->DAA_session.DAA_digest,
-           sizeof(session->DAA_session.DAA_digest));
--        sha1_update(&sha1, "\x01", 1);
-+        sha1_update(&sha1, (BYTE *) "\x01", 1);
-         sha1_update(&sha1, inputData1, inputSize1);
-         sha1_final(&sha1, (BYTE*) &session->DAA_session.DAA_digest);
-       }
-@@ -3172,7 +3172,7 @@ TPM_RESULT TPM_DAA_Sign(TPM_HANDLE handl
-         sha1_init(&sha1);
-         sha1_update(&sha1, (BYTE*) &session->DAA_session.DAA_digest,
-           sizeof(session->DAA_session.DAA_digest));
--        sha1_update(&sha1, "\x00", 1);
-+        sha1_update(&sha1, (BYTE*) "\x00", 1);
-         rsa_export_modulus(&aikData->key, scratch, &size);
-         sha1_update(&sha1, scratch, size);
-         sha1_final(&sha1, (BYTE*) &session->DAA_session.DAA_digest);
-@@ -3229,14 +3229,14 @@ TPM_RESULT TPM_DAA_Sign(TPM_HANDLE handl
-           sizeof(session->DAA_tpmSpecific.DAA_rekey));
-       sha1_update(&sha1, (BYTE*) &session->DAA_tpmSpecific.DAA_count,
-           sizeof(session->DAA_tpmSpecific.DAA_count));
--      sha1_update(&sha1, "\x00", 1);
-+      sha1_update(&sha1, (BYTE *) "\x00", 1);
-       sha1_final(&sha1, scratch);
-       sha1_init(&sha1);
-       sha1_update(&sha1, (BYTE*) &session->DAA_tpmSpecific.DAA_rekey,
-           sizeof(session->DAA_tpmSpecific.DAA_rekey));
-       sha1_update(&sha1, (BYTE*) &session->DAA_tpmSpecific.DAA_count,
-           sizeof(session->DAA_tpmSpecific.DAA_count));
--      sha1_update(&sha1, "\x01", 1);
-+      sha1_update(&sha1, (BYTE *) "\x01", 1);
-       sha1_final(&sha1, scratch + SHA1_DIGEST_LENGTH);
-       mpz_init(f), mpz_init(q);
-       mpz_import(f, 2 * SHA1_DIGEST_LENGTH, 1, 1, 0, 0, scratch);
-@@ -3309,14 +3309,14 @@ TPM_RESULT TPM_DAA_Sign(TPM_HANDLE handl
-           sizeof(session->DAA_tpmSpecific.DAA_rekey));
-       sha1_update(&sha1, (BYTE*) &session->DAA_tpmSpecific.DAA_count,
-           sizeof(session->DAA_tpmSpecific.DAA_count));
--      sha1_update(&sha1, "\x00", 1);
-+      sha1_update(&sha1, (BYTE *) "\x00", 1);
-       sha1_final(&sha1, scratch);
-       sha1_init(&sha1);
-       sha1_update(&sha1, (BYTE*) &session->DAA_tpmSpecific.DAA_rekey,
-           sizeof(session->DAA_tpmSpecific.DAA_rekey));
-       sha1_update(&sha1, (BYTE*) &session->DAA_tpmSpecific.DAA_count,
-           sizeof(session->DAA_tpmSpecific.DAA_count));
--      sha1_update(&sha1, "\x01", 1);
-+      sha1_update(&sha1, (BYTE *) "\x01", 1);
-       sha1_final(&sha1, scratch + SHA1_DIGEST_LENGTH);
-       mpz_init(f), mpz_init(q);
-       mpz_import(f, 2 * SHA1_DIGEST_LENGTH, 1, 1, 0, 0, scratch);
-diff -uprN orig/tpm_emulator-0.4/tpm/tpm_data.c tpm_emulator/tpm/tpm_dat=
a.c
---- orig/tpm_emulator-0.4/tpm/tpm_data.c    2006-06-23
03:37:07.000000000 -0700
-+++ tpm_emulator/tpm/tpm_data.c    2006-07-24 14:35:35.000000000 -0700
-@@ -40,6 +40,7 @@ static inline void init_pcr_attr(int pcr
- void tpm_init_data(void)
- {
-   /* endorsement key */
-+#ifndef TPM_GENERATE_EK
-   uint8_t ek_n[] =3D=20
"\xa8\xdb\xa9\x42\xa8\xf3\xb8\x06\x85\x90\x76\x93\xad\xf7"
-     "\x74\xec\x3f\xd3\x3d\x9d\xe8\x2e\xff\x15\xed\x0e\xce\x5f\x93"
-     "\x92\xeb\xd1\x96\x2b\x72\x18\x81\x79\x12\x9d\x9c\x40\xd7\x1a"
-@@ -77,6 +78,8 @@ void tpm_init_data(void)
-     "\xd1\xc0\x8b\x5b\xa2\x2e\xa7\x15\xca\x50\x75\x10\x48\x9c\x2b"
-     "\x18\xb9\x67\x8f\x5d\x64\xc3\x28\x9f\x2f\x16\x2f\x08\xda\x47"
-     "\xec\x86\x43\x0c\x80\x99\x07\x34\x0f";
-+#endif
-+
-   int i;
-   /* reset all data to NULL, FALSE or 0 */
-   memset(&tpmData, 0, sizeof(tpmData));
-@@ -152,44 +155,43 @@ void tpm_release_data(void)
-
- #ifdef TPM_STORE_TO_FILE
-
--#include <linux/fs.h>
--#include <linux/unistd.h>
--#include <asm/uaccess.h>
-+#include <sys/types.h>
-+#include <sys/stat.h>
-+#include <fcntl.h>
-+#include <unistd.h>
-
- #define TPM_STORAGE_FILE "/var/tpm/tpm_emulator-1.2."
STR(VERSION_MAJOR) "." STR(VERSION_MINOR)
-
- static int write_to_file(uint8_t *data, size_t data_length)
- {
-   int res;
--  struct file *fp;
--  mm_segment_t old_fs =3D get_fs();
--  fp =3D filp_open(TPM_STORAGE_FILE, O_WRONLY | O_TRUNC | O_CREAT,
S_IRUSR | S_IWUSR);
--  if (IS_ERR(fp)) return -1;
--  set_fs(get_ds());
--  res =3D fp->f_op->write(fp, data, data_length, &fp->f_pos);
--  set_fs(old_fs);
--  filp_close(fp, NULL);
-+  int fp;
-+  fp =3D open(TPM_STORAGE_FILE, O_WRONLY | O_TRUNC | O_CREAT, S_IRUSR |=

S_IWUSR);
-+  res =3D write(fp, data, data_length);
-+  close(fp);
-   return (res =3D=3D data_length) ? 0 : -1;
- }
-
- static int read_from_file(uint8_t **data, size_t *data_length)
- {
-   int res;
--  struct file *fp;
--  mm_segment_t old_fs =3D get_fs();
--  fp =3D filp_open(TPM_STORAGE_FILE, O_RDONLY, 0);
--  if (IS_ERR(fp)) return -1;
--  *data_length =3D (size_t)fp->f_dentry->d_inode->i_size;
--  /* *data_length =3D i_size_read(fp->f_dentry->d_inode); */
-+  int fp, file_status;
-+  struct stat file_info;
-+  fp =3D open(TPM_STORAGE_FILE, O_RDONLY, 0);
-+  file_status =3D fstat(fp, &file_info);
-+  if (file_status < 0) {
-+    close(fp);
-+    return -1;
-+  }
-+
-+  *data_length =3D file_info.st_size;
-   *data =3D tpm_malloc(*data_length);
-   if (*data =3D=3D NULL) {
--    filp_close(fp, NULL);
-+    close(fp);
-     return -1;
-   }
--  set_fs(get_ds());
--  res =3D fp->f_op->read(fp, *data, *data_length, &fp->f_pos);
--  set_fs(old_fs);
--  filp_close(fp, NULL);
-+  res =3D read(fp, *data, *data_length);
-+  close(fp);
-   if (res !=3D *data_length) {
-     tpm_free(*data);
-     return -1;
-@@ -216,23 +218,30 @@ static int read_from_file(uint8_t **data
- int tpm_store_permanent_data(void)
- {
-   uint8_t *buf, *ptr;
--  size_t buf_length, len;
-+  UINT32 buf_length, len;
-
-   /* marshal data */
--  buf_length =3D len =3D sizeof_TPM_STCLEAR_FLAGS(tpmData.stclear.flags=
)
--    + sizeof_TPM_PERMANENT_FLAGS(tpmData.permanent.flags) + 2
--    + sizeof_TPM_PERMANENT_DATA(tpmData.permanent.data);
-+  buf_length =3D len =3D 4 + sizeof_TPM_STCLEAR_FLAGS(tpmData.stclear.f=
lags)
-+    + sizeof_TPM_PERMANENT_FLAGS(tpmData.permanent.flags)
-+    + sizeof_TPM_STANY_FLAGS(tpmData.stany.flags) + 2
-+    + sizeof_TPM_STCLEAR_DATA(tpmData.stclear.data)
-+    + sizeof_TPM_PERMANENT_DATA(tpmData.permanent.data)
-+    + sizeof_TPM_STANY_DATA(tpmData.stany.data);
-   buf =3D ptr =3D tpm_malloc(buf_length);
-   if (buf =3D=3D NULL
-       || tpm_marshal_TPM_VERSION(&ptr, &len,
&tpmData.permanent.data.version)
-       || tpm_marshal_TPM_STCLEAR_FLAGS(&ptr, &len, &tpmData.stclear.fla=
gs)
-       || tpm_marshal_TPM_PERMANENT_FLAGS(&ptr, &len,
&tpmData.permanent.flags)
-+      || tpm_marshal_TPM_STANY_FLAGS(&ptr, &len, &tpmData.stany.flags)
-       || tpm_marshal_BOOL(&ptr, &len,
tpmData.permanent.flags.selfTestSucceeded)
-       || tpm_marshal_BOOL(&ptr, &len, tpmData.permanent.flags.owned)
--      || tpm_marshal_TPM_PERMANENT_DATA(&ptr, &len,
&tpmData.permanent.data)) {
-+      || tpm_marshal_TPM_STCLEAR_DATA(&ptr, &len, &tpmData.stclear.data=
)
-+      || tpm_marshal_TPM_PERMANENT_DATA(&ptr, &len,
&tpmData.permanent.data)
-+      || tpm_marshal_TPM_STANY_DATA(&ptr, &len, &tpmData.stany.data)) {=

-     tpm_free(buf);
-     return -1;
-   }
-+
-   if (write_to_file(buf, buf_length - len)) {
-     tpm_free(buf);
-     return -1;
-@@ -244,31 +253,36 @@ int tpm_store_permanent_data(void)
- int tpm_restore_permanent_data(void)
- {
-   uint8_t *buf, *ptr;
--  size_t buf_length, len;
-+  size_t buf_length;
-+  UINT32 len;
-   TPM_VERSION ver;
-
-   /* read data */
-   if (read_from_file(&buf, &buf_length)) return -1;
-   ptr =3D buf;
--  len =3D buf_length;
-+  len =3D (uint32_t) buf_length;
-   /* unmarshal data */
-   if (tpm_unmarshal_TPM_VERSION(&ptr, &len, &ver)
-       || memcmp(&ver, &tpmData.permanent.data.version,
sizeof(TPM_VERSION))
-       || tpm_unmarshal_TPM_STCLEAR_FLAGS(&ptr, &len,
&tpmData.stclear.flags)
-       || tpm_unmarshal_TPM_PERMANENT_FLAGS(&ptr, &len,
&tpmData.permanent.flags)
-+      || tpm_unmarshal_TPM_STANY_FLAGS(&ptr, &len, &tpmData.stany.flags=
)
-       || tpm_unmarshal_BOOL(&ptr, &len,
&tpmData.permanent.flags.selfTestSucceeded)
-       || tpm_unmarshal_BOOL(&ptr, &len, &tpmData.permanent.flags.owned)=

--      || tpm_unmarshal_TPM_PERMANENT_DATA(&ptr, &len,
&tpmData.permanent.data)) {
-+      || tpm_unmarshal_TPM_STCLEAR_DATA(&ptr, &len, &tpmData.stclear.da=
ta)
-+      || tpm_unmarshal_TPM_PERMANENT_DATA(&ptr, &len,
&tpmData.permanent.data)
-+      || tpm_unmarshal_TPM_STANY_DATA(&ptr, &len, &tpmData.stany.data))=
 {
-     tpm_free(buf);
-     return -1;
-   }
-+
-   tpm_free(buf);
-   return 0;
- }
-
- int tpm_erase_permanent_data(void)
- {
--  int res =3D write_to_file("", 0);
-+  int res =3D write_to_file((uint8_t *) "", 0);
-   return res;
- }
-
-diff -uprN orig/tpm_emulator-0.4/tpm/tpm_deprecated.c
tpm_emulator/tpm/tpm_deprecated.c
---- orig/tpm_emulator-0.4/tpm/tpm_deprecated.c    2006-06-23
03:37:07.000000000 -0700
-+++ tpm_emulator/tpm/tpm_deprecated.c    2006-07-24 14:35:35.000000000
-0700
-@@ -1,6 +1,7 @@
- /* Software-Based Trusted Platform Module (TPM) Emulator for Linux
-  * Copyright (C) 2004 Mario Strasser <mast@gmx.net>,
-  *                    Swiss Federal Institute of Technology (ETH) Zuric=
h
-+ * Copyright (C) 2005 INTEL Corp
-  *
-  * This module is free software; you can redistribute it and/or modify
-  * it under the terms of the GNU General Public License as published
-@@ -50,7 +51,7 @@ TPM_RESULT TPM_SaveKeyContext(TPM_KEY_HA
-   BYTE *ptr;
-   UINT32 len;
-   info("TPM_SaveKeyContext()");
--  res =3D TPM_SaveContext(keyHandle, TPM_RT_KEY, "SaveKeyContext..",
-+  res =3D TPM_SaveContext(keyHandle, TPM_RT_KEY, (BYTE*)"SaveKeyContext=
=2E.",
-                         keyContextSize, &contextBlob);
-   if (res !=3D TPM_SUCCESS) return res;
-   len =3D *keyContextSize;
-@@ -82,7 +83,7 @@ TPM_RESULT TPM_SaveAuthContext(TPM_AUTHH
-   BYTE *ptr;
-   UINT32 len;
-   info("TPM_SaveAuthContext()");
--  res =3D TPM_SaveContext(authHandle, TPM_RT_KEY, "SaveAuthContext.",
-+  res =3D TPM_SaveContext(authHandle, TPM_RT_KEY,
(BYTE*)"SaveAuthContext.",
-                         authContextSize, &contextBlob);
-   if (res !=3D TPM_SUCCESS) return res;
-   len =3D *authContextSize;
-diff -uprN orig/tpm_emulator-0.4/tpm/tpm_emulator.h
tpm_emulator/tpm/tpm_emulator.h
---- orig/tpm_emulator-0.4/tpm/tpm_emulator.h    2006-06-23
03:37:07.000000000 -0700
-+++ tpm_emulator/tpm/tpm_emulator.h    2006-07-24 14:35:35.000000000 -07=
00
-@@ -1,5 +1,6 @@
- /* Software-Based Trusted Platform Module (TPM) Emulator for Linux
-  * Copyright (C) 2004 Mario Strasser <mast@gmx.net>,
-+ * Copyright (C) 2005 INTEL Corp
-  *
-  * This module is free software; you can redistribute it and/or modify
-  * it under the terms of the GNU General Public License as published
-@@ -22,7 +23,8 @@
- /* TPM configuration */
- #define TPM_STORE_TO_FILE       1
- #undef  TPM_STRONG_PERSISTENCE
--#undef  TPM_GENERATE_EK
-+//#undef  TPM_GENERATE_EK
-+#define  TPM_GENERATE_EK
- #undef  TPM_GENERATE_SEED_DAA
-
- #define TPM_MANUFACTURER 0x4554485A /* 'ETHZ' */      =20
-diff -uprN orig/tpm_emulator-0.4/tpm/tpm_marshalling.c
tpm_emulator/tpm/tpm_marshalling.c
---- orig/tpm_emulator-0.4/tpm/tpm_marshalling.c    2006-06-23
03:37:07.000000000 -0700
-+++ tpm_emulator/tpm/tpm_marshalling.c    2006-07-24 14:35:35.000000000
-0700
-@@ -1312,7 +1312,7 @@ int tpm_unmarshal_TPM_STANY_FLAGS(BYTE *
-
- int tpm_marshal_RSA(BYTE **ptr, UINT32 *length, rsa_private_key_t *v)
- {
--  UINT32 m_len, e_len, q_len;
-+  size_t m_len, e_len, q_len;
-   if (*length < sizeof_RSA((*v))) return -1;
-   if (v->size > 0) {
-     rsa_export_modulus(v, &(*ptr)[6], &m_len);
-@@ -1460,6 +1460,66 @@ int tpm_unmarshal_TPM_PERMANENT_DATA(BYT
-   return 0;
- }
-
-+int tpm_marshal_TPM_STCLEAR_DATA(BYTE **ptr, UINT32 *length,
TPM_STCLEAR_DATA *v)
-+{
-+  if (tpm_marshal_TPM_STRUCTURE_TAG(ptr, length, v->tag)
-+    || tpm_marshal_TPM_NONCE(ptr, length, &v->contextNonceKey)
-+    || tpm_marshal_TPM_COUNT_ID(ptr, length, v->countID) ) return -1;
-+
-+  return 0;
-+}
-+
-+int tpm_unmarshal_TPM_STCLEAR_DATA(BYTE **ptr, UINT32 *length,
TPM_STCLEAR_DATA *v)
-+{
-+  if (tpm_unmarshal_TPM_STRUCTURE_TAG(ptr, length, &v->tag)
-+    || tpm_unmarshal_TPM_NONCE(ptr, length, &v->contextNonceKey)
-+    || tpm_unmarshal_TPM_COUNT_ID(ptr, length, &v->countID) ) return -1=
;
-+
-+  return 0;
-+}
-+
-+int tpm_marshal_TPM_STANY_DATA(BYTE **ptr, UINT32 *length,
TPM_STANY_DATA *v)
-+{
-+  UINT32 i;
-+  if (tpm_marshal_TPM_STRUCTURE_TAG(ptr, length, v->tag)
-+    || tpm_marshal_TPM_NONCE(ptr, length, &v->contextNonceSession)
-+    || tpm_marshal_TPM_DIGEST(ptr, length, &v->auditDigest)
-+    || tpm_marshal_BOOL(ptr, length, v->auditSession)
-+    || tpm_marshal_TPM_CURRENT_TICKS(ptr, length, &v->currentTicks)
-+    || tpm_marshal_UINT32(ptr, length, v->contextCount)
-+    || tpm_marshal_UINT32_ARRAY(ptr, length, v->contextList,
TPM_MAX_SESSION_LIST)) return -1;
-+  for (i =3D 0; i < TPM_MAX_SESSIONS; i++) {
-+    if (tpm_marshal_TPM_SESSION_DATA(ptr, length, &v->sessions[i]))
return -1;
-+  }
-+  for (i =3D 0; i < TPM_MAX_SESSIONS_DAA; i++) {
-+    if (tpm_marshal_TPM_DAA_SESSION_DATA(ptr, length,
&v->sessionsDAA[i])) return -1;
-+  }
-+  if (tpm_marshal_TPM_TRANSHANDLE(ptr, length, v->transExclusive))
return -1;
-+
-+  return 0;
-+}
-+
-+int tpm_unmarshal_TPM_STANY_DATA(BYTE **ptr, UINT32 *length,
TPM_STANY_DATA *v)
-+{
-+  UINT32 i;
-+  if (tpm_unmarshal_TPM_STRUCTURE_TAG(ptr, length, &v->tag)
-+    || tpm_unmarshal_TPM_NONCE(ptr, length, &v->contextNonceSession)
-+    || tpm_unmarshal_TPM_DIGEST(ptr, length, &v->auditDigest)
-+    || tpm_unmarshal_BOOL(ptr, length, &v->auditSession)
-+    || tpm_unmarshal_TPM_CURRENT_TICKS(ptr, length, &v->currentTicks)
-+    || tpm_unmarshal_UINT32(ptr, length, &v->contextCount)
-+    || tpm_unmarshal_UINT32_ARRAY(ptr, length, v->contextList,
TPM_MAX_SESSION_LIST)) return -1;
-+  for (i =3D 0; i < TPM_MAX_SESSIONS; i++) {
-+    if (tpm_unmarshal_TPM_SESSION_DATA(ptr, length, &v->sessions[i]))
return -1;
-+  }
-+  for (i =3D 0; i < TPM_MAX_SESSIONS_DAA; i++) {
-+    if (tpm_unmarshal_TPM_DAA_SESSION_DATA(ptr, length,
&v->sessionsDAA[i])) return -1;
-+  }
-+  if (tpm_unmarshal_TPM_TRANSHANDLE(ptr, length, &v->transExclusive))
return -1;
-+
-+  return 0;
-+}
-+
- int tpm_marshal_TPM_SESSION_DATA(BYTE **ptr, UINT32 *length,
TPM_SESSION_DATA *v)
- {
-   if (tpm_marshal_BYTE(ptr, length, v->type)
-diff -uprN orig/tpm_emulator-0.4/tpm/tpm_marshalling.h
tpm_emulator/tpm/tpm_marshalling.h
---- orig/tpm_emulator-0.4/tpm/tpm_marshalling.h    2006-06-23
03:37:07.000000000 -0700
-+++ tpm_emulator/tpm/tpm_marshalling.h    2006-07-24 14:35:35.000000000
-0700
-@@ -432,6 +432,12 @@ int tpm_unmarshal_TPM_KEY_DATA(BYTE **pt
- int tpm_marshal_TPM_PERMANENT_DATA(BYTE **ptr, UINT32 *length,
TPM_PERMANENT_DATA *);
- int tpm_unmarshal_TPM_PERMANENT_DATA(BYTE **ptr, UINT32 *length,
TPM_PERMANENT_DATA *);
-
-+int tpm_marshal_TPM_STCLEAR_DATA(BYTE **ptr, UINT32 *length,
TPM_STCLEAR_DATA *v);
-+int tpm_unmarshal_TPM_STCLEAR_DATA(BYTE **ptr, UINT32 *length,
TPM_STCLEAR_DATA *v);
-+
-+int tpm_marshal_TPM_STANY_DATA(BYTE **ptr, UINT32 *length,
TPM_STANY_DATA *v);
-+int tpm_unmarshal_TPM_STANY_DATA(BYTE **ptr, UINT32 *length,
TPM_STANY_DATA *v);
-+
- int tpm_marshal_TPM_SESSION_DATA(BYTE **ptr, UINT32 *length,
TPM_SESSION_DATA *v);
- int tpm_unmarshal_TPM_SESSION_DATA(BYTE **ptr, UINT32 *length,
TPM_SESSION_DATA *v);
-
-diff -uprN orig/tpm_emulator-0.4/tpm/tpm_owner.c
tpm_emulator/tpm/tpm_owner.c
---- orig/tpm_emulator-0.4/tpm/tpm_owner.c    2006-06-23
03:37:07.000000000 -0700
-+++ tpm_emulator/tpm/tpm_owner.c    2006-07-24 14:35:35.000000000 -0700
-@@ -108,7 +108,7 @@ TPM_RESULT TPM_TakeOwnership(TPM_PROTOCO
-   TPM_RESULT res;
-   rsa_private_key_t *ek =3D &tpmData.permanent.data.endorsementKey;
-   TPM_KEY_DATA *srk =3D &tpmData.permanent.data.srk;
--  UINT32 buf_size =3D ek->size >> 3;
-+  size_t buf_size =3D ek->size >> 3, key_length;
-   BYTE buf[buf_size];
-
-   info("TPM_TakeOwnership()");
-@@ -173,7 +173,8 @@ TPM_RESULT TPM_TakeOwnership(TPM_PROTOCO
-     return TPM_FAIL;
-   }
-   rsa_export_modulus(&srk->key, srkPub->pubKey.key,
--    &srkPub->pubKey.keyLength);
-+             &key_length);
-+  srkPub->pubKey.keyLength =3D (UINT32) key_length;
-   /* setup tpmProof and set state to owned */
-   tpm_get_random_bytes(tpmData.permanent.data.tpmProof.nonce,
-     sizeof(tpmData.permanent.data.tpmProof.nonce));
-diff -uprN orig/tpm_emulator-0.4/tpm/tpm_startup.c
tpm_emulator/tpm/tpm_startup.c
---- orig/tpm_emulator-0.4/tpm/tpm_startup.c    2006-06-23
03:37:07.000000000 -0700
-+++ tpm_emulator/tpm/tpm_startup.c    2006-07-24 14:35:35.000000000 -070=
0
-@@ -41,26 +41,29 @@ void TPM_Init(TPM_STARTUP_TYPE startupTy
- TPM_RESULT TPM_Startup(TPM_STARTUP_TYPE startupType)
- {
-   int i;
-+  int restore_fail;
-   info("TPM_Startup(%d)", startupType);
-   if (tpmData.stany.flags.postInitialise =3D=3D FALSE) return
TPM_INVALID_POSTINIT;
--  /* reset STANY_FLAGS */
--  SET_TO_ZERO(&tpmData.stany.flags);
--  tpmData.stany.flags.tag =3D TPM_TAG_STANY_FLAGS;
--  /* reset STANY_DATA (invalidates ALL sessions) */
--  SET_TO_ZERO(&tpmData.stany.data);
--  tpmData.stany.data.tag =3D TPM_TAG_STANY_DATA;
--  /* init session-context nonce */
--  SET_TO_RAND(&tpmData.stany.data.contextNonceSession);
-+
-+  /* try and restore state to get EK, SRK, etc */
-+  restore_fail =3D tpm_restore_permanent_data();
-+
-   /* set data and flags according to the given startup type */
-   if (startupType =3D=3D TPM_ST_CLEAR) {
--    /* if available, restore permanent data */
--    tpm_restore_permanent_data();
-+    /* reset STANY_FLAGS */
-+    SET_TO_ZERO(&tpmData.stany.flags);
-+    tpmData.stany.flags.tag =3D TPM_TAG_STANY_FLAGS;
-+    /* reset STANY_DATA (invalidates ALL sessions) */
-+    SET_TO_ZERO(&tpmData.stany.data);
-+    tpmData.stany.data.tag =3D TPM_TAG_STANY_DATA;
-+    /* init session-context nonce */
-+    SET_TO_RAND(&tpmData.stany.data.contextNonceSession);
-     /* reset PCR values */
-     for (i =3D 0; i < TPM_NUM_PCR; i++) {
--      if (tpmData.permanent.data.pcrAttrib[i].pcrReset)
--        SET_TO_ZERO(tpmData.permanent.data.pcrValue[i].digest);
-+      if (!tpmData.permanent.data.pcrAttrib[i].pcrReset)
-+        SET_TO_ZERO(&tpmData.permanent.data.pcrValue[i].digest);
-       else
--        SET_TO_0xFF(tpmData.permanent.data.pcrValue[i].digest);
-+        SET_TO_0xFF(&tpmData.permanent.data.pcrValue[i].digest);
-     }
-     /* reset STCLEAR_FLAGS */
-     SET_TO_ZERO(&tpmData.stclear.flags);
-@@ -79,7 +82,8 @@ TPM_RESULT TPM_Startup(TPM_STARTUP_TYPE
-     /* init key-context nonce */
-     SET_TO_RAND(&tpmData.stclear.data.contextNonceKey);
-   } else if (startupType =3D=3D TPM_ST_STATE) {
--    if (tpm_restore_permanent_data()) {
-+    /* restore must have been successful for TPM_ST_STATE */
-+    if (restore_fail) {
-       error("restoring permanent data failed");
-       tpmData.permanent.data.testResult =3D
"tpm_restore_permanent_data() failed";
-       tpmData.permanent.flags.selfTestSucceeded =3D FALSE;
-diff -uprN orig/tpm_emulator-0.4/tpm/tpm_storage.c
tpm_emulator/tpm/tpm_storage.c
---- orig/tpm_emulator-0.4/tpm/tpm_storage.c    2006-06-23
03:37:07.000000000 -0700
-+++ tpm_emulator/tpm/tpm_storage.c    2006-07-24 14:35:35.000000000 -070=
0
-@@ -58,6 +58,7 @@ int encrypt_sealed_data(TPM_KEY_DATA *ke
-                         BYTE *enc, UINT32 *enc_size)
- {
-   UINT32 len;
-+  size_t enc_size32 =3D *enc_size;
-   BYTE *buf, *ptr;
-   rsa_public_key_t pub_key;
-   int scheme;
-@@ -72,7 +73,7 @@ int encrypt_sealed_data(TPM_KEY_DATA *ke
-   if (buf =3D=3D NULL
-       || tpm_marshal_TPM_SEALED_DATA(&ptr, &len, seal)
-       || rsa_encrypt(&pub_key, scheme, buf,
sizeof_TPM_SEALED_DATA((*seal)),
--                     enc, enc_size)) {
-+                     enc, &enc_size32)) {
-     tpm_free(buf);
-     rsa_release_public_key(&pub_key);
-     return -1;
-@@ -85,7 +86,8 @@ int encrypt_sealed_data(TPM_KEY_DATA *ke
- int decrypt_sealed_data(TPM_KEY_DATA *key, BYTE *enc, UINT32 enc_size,
-                         TPM_SEALED_DATA *seal, BYTE **buf)
- {
--  UINT32 len;
-+  size_t len;
-+  UINT32 len32;
-   BYTE *ptr;
-   int scheme;
-   switch (key->encScheme) {
-@@ -96,8 +98,12 @@ int decrypt_sealed_data(TPM_KEY_DATA *ke
-   len =3D enc_size;
-   *buf =3D ptr =3D tpm_malloc(len);
-   if (*buf =3D=3D NULL
--      || rsa_decrypt(&key->key, scheme, enc, enc_size, *buf, &len)
--      || tpm_unmarshal_TPM_SEALED_DATA(&ptr, &len, seal)) {
-+      || rsa_decrypt(&key->key, scheme, enc, enc_size, *buf, &len) ){
-+    tpm_free(*buf);
-+    return -1;
-+  }
-+  len32 =3D len;
-+  if (tpm_unmarshal_TPM_SEALED_DATA(&ptr, &len32, seal)) {
-     tpm_free(*buf);
-     return -1;
-   }
-@@ -240,11 +246,12 @@ TPM_RESULT TPM_Unseal(TPM_KEY_HANDLE par
-
- TPM_RESULT TPM_UnBind(TPM_KEY_HANDLE keyHandle, UINT32 inDataSize,
-                       BYTE *inData, TPM_AUTH *auth1,
--                      UINT32 *outDataSize, BYTE **outData)
-+                      UINT32 *outDataSize32, BYTE **outData)
- {
-   TPM_RESULT res;
-   TPM_KEY_DATA *key;
-   int scheme;
-+  size_t outDataSize;
- =20
-   info("TPM_UnBind()");
-   /* get key */
-@@ -262,8 +269,8 @@ TPM_RESULT TPM_UnBind(TPM_KEY_HANDLE key
-   /* the size of the input data muss be greater than zero */
-   if (inDataSize =3D=3D 0) return TPM_BAD_PARAMETER;
-   /* decrypt data */
--  *outDataSize =3D inDataSize;
--  *outData =3D tpm_malloc(*outDataSize);
-+  outDataSize =3D inDataSize;
-+  *outData =3D tpm_malloc(outDataSize);
-   if (*outData =3D=3D NULL) return TPM_NOSPACE;
-   switch (key->encScheme) {
-     case TPM_ES_RSAESOAEP_SHA1_MGF1: scheme =3D RSA_ES_OAEP_SHA1; break=
;
-@@ -271,20 +278,21 @@ TPM_RESULT TPM_UnBind(TPM_KEY_HANDLE key
-     default: tpm_free(*outData); return TPM_DECRYPT_ERROR;
-   }
-   if (rsa_decrypt(&key->key, scheme, inData, inDataSize,
--      *outData, outDataSize)) {
-+      *outData, &outDataSize)) {
-     tpm_free(*outData);
-     return TPM_DECRYPT_ERROR;
-   }
-   /* verify data if it is of type TPM_BOUND_DATA */
-   if (key->encScheme =3D=3D TPM_ES_RSAESOAEP_SHA1_MGF1
-       || key->keyUsage !=3D TPM_KEY_LEGACY) {
--    if (*outDataSize < 5 || memcmp(*outData, "\x01\x01\00\x00\x02", 5)
!=3D 0) {
-+    if (outDataSize < 5 || memcmp(*outData, "\x01\x01\00\x00\x02", 5)
!=3D 0) {
-       tpm_free(*outData);
-       return TPM_DECRYPT_ERROR;
-     }
--    *outDataSize -=3D 5;
--    memmove(*outData, &(*outData)[5], *outDataSize);
-+    outDataSize -=3D 5;
-+    memmove(*outData, &(*outData)[5], outDataSize);
-   }
-+  *outDataSize32 =3D (UINT32) outDataSize;
-   return TPM_SUCCESS;
- }
-
-@@ -334,12 +342,13 @@ int compute_pubkey_digest(TPM_PUBKEY *ke
- }
-
- int encrypt_private_key(TPM_KEY_DATA *key, TPM_STORE_ASYMKEY *store,
--                        BYTE *enc, UINT32 *enc_size)
-+                        BYTE *enc, UINT32 *enc_size32)
- {
-   UINT32 len;
-   BYTE *buf, *ptr;
-   rsa_public_key_t pub_key;
-   int scheme;
-+  size_t enc_size;
-   switch (key->encScheme) {
-     case TPM_ES_RSAESOAEP_SHA1_MGF1: scheme =3D RSA_ES_OAEP_SHA1; break=
;
-     case TPM_ES_RSAESPKCSv15: scheme =3D RSA_ES_PKCSV15; break;
-@@ -351,11 +360,12 @@ int encrypt_private_key(TPM_KEY_DATA *ke
-   if (buf =3D=3D NULL
-       || tpm_marshal_TPM_STORE_ASYMKEY(&ptr, &len, store)
-       || rsa_encrypt(&pub_key, scheme, buf,
sizeof_TPM_STORE_ASYMKEY((*store)),
--                     enc, enc_size)) {
-+                     enc, &enc_size)) {
-     tpm_free(buf);
-     rsa_release_public_key(&pub_key);
-     return -1;
-   }
-+  *enc_size32 =3D (UINT32) enc_size;
-   tpm_free(buf);
-   rsa_release_public_key(&pub_key);
-   return 0;
-@@ -364,7 +374,8 @@ int encrypt_private_key(TPM_KEY_DATA *ke
- int decrypt_private_key(TPM_KEY_DATA *key, BYTE *enc, UINT32 enc_size,
-                         TPM_STORE_ASYMKEY *store, BYTE **buf)
- {
--  UINT32 len;
-+  UINT32 len32;
-+  size_t len;
-   BYTE *ptr;
-   int scheme;
-   switch (key->encScheme) {
-@@ -375,8 +386,12 @@ int decrypt_private_key(TPM_KEY_DATA *ke
-   len =3D enc_size;
-   *buf =3D ptr =3D tpm_malloc(len);
-   if (*buf =3D=3D NULL
--      || rsa_decrypt(&key->key, scheme, enc, enc_size, *buf, &len)
--      || tpm_unmarshal_TPM_STORE_ASYMKEY(&ptr, &len, store)) {
-+      || rsa_decrypt(&key->key, scheme, enc, enc_size, *buf, &len) ) {
-+    tpm_free(*buf);
-+    return -1;
-+  }
-+  len32 =3D (UINT32) len;
-+  if (tpm_unmarshal_TPM_STORE_ASYMKEY(&ptr, &len32, store)) {=20
-     tpm_free(*buf);
-     return -1;
-   }
-@@ -394,7 +409,7 @@ TPM_RESULT TPM_CreateWrapKey(TPM_KEY_HAN
-   TPM_SESSION_DATA *session;
-   TPM_STORE_ASYMKEY store;
-   rsa_private_key_t rsa;
--  UINT32 key_length;
-+  size_t key_length;
-
-   info("TPM_CreateWrapKey()");
-   /* get parent key */
-@@ -450,11 +465,11 @@ TPM_RESULT TPM_CreateWrapKey(TPM_KEY_HAN
-     }
-   }
-   /* generate key and store it */
--  key_length =3D keyInfo->algorithmParms.parms.rsa.keyLength;
--  if (rsa_generate_key(&rsa, key_length)) return TPM_FAIL;
--  wrappedKey->pubKey.keyLength =3D key_length >> 3;
-+  if (rsa_generate_key(&rsa,
keyInfo->algorithmParms.parms.rsa.keyLength))
-+    return TPM_FAIL;
-+  wrappedKey->pubKey.keyLength =3D
keyInfo->algorithmParms.parms.rsa.keyLength >> 3;
-   wrappedKey->pubKey.key =3D tpm_malloc(wrappedKey->pubKey.keyLength);
--  store.privKey.keyLength =3D key_length >> 4;
-+  store.privKey.keyLength =3D
keyInfo->algorithmParms.parms.rsa.keyLength >> 4;
-   store.privKey.key =3D tpm_malloc(store.privKey.keyLength);
-   wrappedKey->encDataSize =3D parent->key.size >> 3;
-   wrappedKey->encData =3D tpm_malloc(wrappedKey->encDataSize);
-@@ -466,9 +481,11 @@ TPM_RESULT TPM_CreateWrapKey(TPM_KEY_HAN
-     tpm_free(wrappedKey->encData);
-     return TPM_NOSPACE;
-   }
--  rsa_export_modulus(&rsa, wrappedKey->pubKey.key,
--    &wrappedKey->pubKey.keyLength);
--  rsa_export_prime1(&rsa, store.privKey.key, &store.privKey.keyLength);=

-+  rsa_export_modulus(&rsa, wrappedKey->pubKey.key,
-+             &key_length);
-+  wrappedKey->pubKey.keyLength =3D (UINT32) key_length;
-+  rsa_export_prime1(&rsa, store.privKey.key, &key_length);
-+  store.privKey.keyLength =3D (UINT32) key_length;
-   rsa_release_private_key(&rsa);
-   /* compute the digest of the wrapped key (without encData) */
-   if (compute_key_digest(wrappedKey, &store.pubDataDigest)) {
-@@ -602,6 +619,7 @@ TPM_RESULT TPM_LoadKey2(TPM_KEY_HANDLE p
-
- int tpm_setup_key_parms(TPM_KEY_DATA *key, TPM_KEY_PARMS *parms)
- {
-+  size_t key_length;
-   parms->algorithmID =3D TPM_ALG_RSA;
-   parms->encScheme =3D key->encScheme;
-   parms->sigScheme =3D key->sigScheme;
-@@ -611,7 +629,8 @@ int tpm_setup_key_parms(TPM_KEY_DATA *ke
-   parms->parms.rsa.exponent =3D tpm_malloc(parms->parms.rsa.exponentSiz=
e);
-   if (parms->parms.rsa.exponent =3D=3D NULL) return -1;
-   rsa_export_exponent(&key->key, parms->parms.rsa.exponent,
--    &parms->parms.rsa.exponentSize);
-+    &key_length);
-+  parms->parms.rsa.exponentSize =3D (UINT32) key_length;
-   parms->parmSize =3D 12 + parms->parms.rsa.exponentSize;
-   return 0;
- }
-@@ -622,6 +641,7 @@ TPM_RESULT TPM_GetPubKey(TPM_KEY_HANDLE
-   TPM_RESULT res;
-   TPM_KEY_DATA *key;
-   TPM_DIGEST digest;
-+  size_t key_length;
-   info("TPM_GetPubKey()");
-   /* get key */
-   if (keyHandle =3D=3D TPM_KH_SRK
-@@ -650,8 +670,8 @@ TPM_RESULT TPM_GetPubKey(TPM_KEY_HANDLE
-   pubKey->pubKey.keyLength =3D key->key.size >> 3;
-   pubKey->pubKey.key =3D tpm_malloc(pubKey->pubKey.keyLength);
-   if (pubKey->pubKey.key =3D=3D NULL) return TPM_NOSPACE;
--  rsa_export_modulus(&key->key, pubKey->pubKey.key,
--    &pubKey->pubKey.keyLength);
-+  rsa_export_modulus(&key->key, pubKey->pubKey.key, &key_length);
-+  pubKey->pubKey.keyLength =3D (UINT32) key_length;
-   if (tpm_setup_key_parms(key, &pubKey->algorithmParms) !=3D 0) {
-     error("TPM_GetPubKey(): tpm_setup_key_parms() failed.");
-     tpm_free(pubKey->pubKey.key);
-diff -uprN orig/tpm_emulator-0.4/tpm/tpm_structures.h
tpm_emulator/tpm/tpm_structures.h
---- orig/tpm_emulator-0.4/tpm/tpm_structures.h    2006-06-23
03:37:07.000000000 -0700
-+++ tpm_emulator/tpm/tpm_structures.h    2006-07-24 14:35:35.000000000
-0700
-@@ -1958,6 +1958,7 @@ typedef struct tdTPM_DAA_ISSUER {
-   TPM_DIGEST DAA_digest_gamma;
-   BYTE DAA_generic_q[26];
- } TPM_DAA_ISSUER;
-+#define sizeof_TPM_DAA_ISSUER(s) (2 + (20 * 6) + 26 )
-
- /*
-  * TPM_DAA_TPM ([TPM_Part2], Section 22.4)
-@@ -1973,6 +1974,7 @@ typedef struct tdTPM_DAA_TPM {
-   TPM_DIGEST DAA_rekey;
-   UINT32 DAA_count;
- } TPM_DAA_TPM;
-+#define sizeof_TPM_DAA_TPM(s) (2 + (4 * 20) + 4)
-
- /*
-  * TPM_DAA_CONTEXT ([TPM_Part2], Section 22.5)
-@@ -1987,6 +1989,7 @@ typedef struct tdTPM_DAA_CONTEXT {
-   BYTE DAA_scratch[256];
-   BYTE DAA_stage;
- } TPM_DAA_CONTEXT;
-+#define sizeof_TPM_DAA_CONTEXT(s) (2 + (3 * 20) + 256 + 1)
-
- /*
-  * TPM_DAA_JOINDATA ([TPM_Part2], Section 22.6)
-@@ -1998,6 +2001,7 @@ typedef struct tdTPM_DAA_JOINDATA {
-   BYTE DAA_join_u1[138];
-   TPM_DIGEST DAA_digest_n0;
- } TPM_DAA_JOINDATA;
-+#define sizeof_TPM_DAA_JOINDATA(s) (1 + 1 + 20)
-
- /*
-  * TPM_DAA_BLOB ([TPM_Part2], Section 22.8)
-@@ -2202,6 +2206,7 @@ typedef struct tdTPM_STCLEAR_DATA {
-   //UINT32 ownerReference;
-   //BOOL disableResetLock;
- } TPM_STCLEAR_DATA;
-+#define sizeof_TPM_STCLEAR_DATA(s) (2 + 20 + 4)
-
- /*
-  * TPM_SESSION_DATA
-@@ -2238,6 +2243,11 @@ typedef struct tdTPM_DAA_SESSION_DATA {
-   TPM_DAA_JOINDATA DAA_joinSession;
-   TPM_HANDLE handle;
- } TPM_DAA_SESSION_DATA;
-+#define sizeof_TPM_DAA_SESSION_DATA(s) ( 1 \
-+  + sizeof_TPM_DAA_ISSUER(s.DAA_issuerSettings) \
-+  + sizeof_TPM_DAA_TPM(s.DAA_tpmSpecific) \
-+  + sizeof_TPM_DAA_CONTEXT(s.DAA_session) \
-+  + sizeof_TPM_DAA_JOINDATA(s.DAA_joinSession) + 4)
-
- /*
-  * TPM_STANY_DATA ([TPM_Part2], Section 7.6)
-@@ -2262,6 +2272,11 @@ typedef struct tdTPM_STANY_DATA {
-   TPM_DAAHANDLE currentDAA;
-   TPM_TRANSHANDLE transExclusive;
- } TPM_STANY_DATA;
-+#define sizeof_TPM_STANY_DATA(s) (2 + 20 + 20 + 1 \
-+  + sizeof_TPM_CURRENT_TICKS(s.currentTicks) \
-+  + 4 + (4 * TPM_MAX_SESSION_LIST) \
-+  + (sizeof_TPM_SESSION_DATA(s.sessions[0]) * TPM_MAX_SESSION_LIST) \
-+  + (sizeof_TPM_DAA_SESSION_DATA(s.sessionsDAA[0]) *
TPM_MAX_SESSIONS_DAA) + 4)
-
- /*
-  * TPM_DATA
-diff -uprN orig/tpm_emulator-0.4/tpm/tpm_testing.c
tpm_emulator/tpm/tpm_testing.c
---- orig/tpm_emulator-0.4/tpm/tpm_testing.c    2006-06-23
03:37:07.000000000 -0700
-+++ tpm_emulator/tpm/tpm_testing.c    2006-07-24 14:35:35.000000000 -070=
0
-@@ -1,6 +1,7 @@
- /* Software-Based Trusted Platform Module (TPM) Emulator for Linux
-  * Copyright (C) 2004 Mario Strasser <mast@gmx.net>,
-  *                    Swiss Federal Institute of Technology (ETH) Zuric=
h
-+ * Copyright (C) 2005 INTEL Corp
-  *
-  * This module is free software; you can redistribute it and/or modify
-  * it under the terms of the GNU General Public License as published
-@@ -95,24 +96,24 @@ static int tpm_test_sha1(void)
-   struct {
-     uint8_t *data; uint32_t repetitions; uint8_t *digest;
-   } test_cases[] =3D  {{
--    "abc", 1,
--  =20
"\xA9\x99\x3E\x36\x47\x06\x81\x6A\xBA\x3E\x25\x71\x78\x50\xC2\x6C\x9C\xD0=
\xD8\x9D"
-+    (uint8_t*)"abc", 1,
-+  =20
(uint8_t*)"\xA9\x99\x3E\x36\x47\x06\x81\x6A\xBA\x3E\x25\x71\x78\x50\xC2\x=
6C\x9C\xD0\xD8\x9D"
-   }, {
--    "abcdbcdecdefdefgefghfghighijhijkijkljklmklmnlmnomnopnopq", 1,
--  =20
"\x84\x98\x3E\x44\x1C\x3B\xD2\x6E\xBA\xAE\x4A\xA1\xF9\x51\x29\xE5\xE5\x46=
\x70\xF1"
-+  =20
(uint8_t*)"abcdbcdecdefdefgefghfghighijhijkijkljklmklmnlmnomnopnopq", 1,
-+  =20
(uint8_t*)"\x84\x98\x3E\x44\x1C\x3B\xD2\x6E\xBA\xAE\x4A\xA1\xF9\x51\x29\x=
E5\xE5\x46\x70\xF1"
-   }, {
--    "a", 1000000,
--  =20
"\x34\xAA\x97\x3C\xD4\xC4\xDA\xA4\xF6\x1E\xEB\x2B\xDB\xAD\x27\x31\x65\x34=
\x01\x6F"
-+    (uint8_t*)"a", 1000000,
-+  =20
(uint8_t*)"\x34\xAA\x97\x3C\xD4\xC4\xDA\xA4\xF6\x1E\xEB\x2B\xDB\xAD\x27\x=
31\x65\x34\x01\x6F"
-   }, {
--  =20
"0123456701234567012345670123456701234567012345670123456701234567", 10,
--  =20
"\xDE\xA3\x56\xA2\xCD\xDD\x90\xC7\xA7\xEC\xED\xC5\xEB\xB5\x63\x93\x4F\x46=
\x04\x52"
-+  =20
(uint8_t*)"01234567012345670123456701234567012345670123456701234567012345=
67",
10,
-+  =20
(uint8_t*)"\xDE\xA3\x56\xA2\xCD\xDD\x90\xC7\xA7\xEC\xED\xC5\xEB\xB5\x63\x=
93\x4F\x46\x04\x52"
-   }};
-
-   debug("tpm_test_sha1()");
-   for (i =3D 0; i < sizeof(test_cases) / sizeof(test_cases[0]); i++) {
-     sha1_init(&ctx);
-     for (j =3D 0; j < test_cases[i].repetitions; j++)
--      sha1_update(&ctx, test_cases[i].data, strlen(test_cases[i].data))=
;
-+      sha1_update(&ctx, test_cases[i].data,
strlen((char*)test_cases[i].data));
-     sha1_final(&ctx, digest);
-     if (memcmp(digest, test_cases[i].digest, SHA1_DIGEST_LENGTH) !=3D 0=
)
return -1;
-   }
-@@ -128,41 +129,41 @@ static int tpm_test_hmac(void)
-   struct {
-     uint8_t *key, key_len, *data, data_len, *digest;
-   } test_cases[] =3D {{
--    "\x0b", 20, "Hi There", 8,
--  =20
"\xb6\x17\x31\x86\x55\x05\x72\x64\xe2\x8b\xc0\xb6\xfb\x37\x8c\x8e\xf1\x46=
\xbe\x00"
-+    (uint8_t*)"\x0b", 20, (uint8_t*)"Hi There", 8,
-+  =20
(uint8_t*)"\xb6\x17\x31\x86\x55\x05\x72\x64\xe2\x8b\xc0\xb6\xfb\x37\x8c\x=
8e\xf1\x46\xbe\x00"
-   }, {
--    "Jefe", 4, "what do ya want for nothing?", 28,
--  =20
"\xef\xfc\xdf\x6a\xe5\xeb\x2f\xa2\xd2\x74\x16\xd5\xf1\x84\xdf\x9c\x25\x9a=
\x7c\x79"
-+    (uint8_t*)"Jefe", 4, (uint8_t*)"what do ya want for nothing?", 28,
-+  =20
(uint8_t*)"\xef\xfc\xdf\x6a\xe5\xeb\x2f\xa2\xd2\x74\x16\xd5\xf1\x84\xdf\x=
9c\x25\x9a\x7c\x79"
-   }, {
--    "\xaa", 20, "\xdd", 50,
--  =20
"\x12\x5d\x73\x42\xb9\xac\x11\xcd\x91\xa3\x9a\xf4\x8a\xa1\x7b\x4f\x63\xf1=
\x75\xd3"
-+    (uint8_t*)"\xaa", 20, (uint8_t*)"\xdd", 50,
-+  =20
(uint8_t*)"\x12\x5d\x73\x42\xb9\xac\x11\xcd\x91\xa3\x9a\xf4\x8a\xa1\x7b\x=
4f\x63\xf1\x75\xd3"
-   }, {
--  =20
"\x01\x02\x03\x04\x05\x06\x07\x08\x09\x0a\x0b\x0c\x0d\x0e\x0f\x10\x11\x12=
\x13\x14"
--    "\x15\x16\x17\x18\x19", 25, "\xcd", 50,
--  =20
"\x4c\x90\x07\xf4\x02\x62\x50\xc6\xbc\x84\x14\xf9\xbf\x50\xc8\x6c\x2d\x72=
\x35\xda"
-+  =20
(uint8_t*)"\x01\x02\x03\x04\x05\x06\x07\x08\x09\x0a\x0b\x0c\x0d\x0e\x0f\x=
10\x11\x12\x13\x14"
-+    "\x15\x16\x17\x18\x19", 25, (uint8_t*)"\xcd", 50,
-+  =20
(uint8_t*)"\x4c\x90\x07\xf4\x02\x62\x50\xc6\xbc\x84\x14\xf9\xbf\x50\xc8\x=
6c\x2d\x72\x35\xda"
-   }, {
--    "\x0c", 20, "Test With Truncation", 20,
--  =20
"\x4c\x1a\x03\x42\x4b\x55\xe0\x7f\xe7\xf2\x7b\xe1\xd5\x8b\xb9\x32\x4a\x9a=
\x5a\x04"
-+    (uint8_t*)"\x0c", 20, (uint8_t*)"Test With Truncation", 20,
-+  =20
(uint8_t*)"\x4c\x1a\x03\x42\x4b\x55\xe0\x7f\xe7\xf2\x7b\xe1\xd5\x8b\xb9\x=
32\x4a\x9a\x5a\x04"
-   }, {
--    "\xaa", 80, "Test Using Larger Than Block-Size Key - Hash Key
First", 54,
--  =20
"\xaa\x4a\xe5\xe1\x52\x72\xd0\x0e\x95\x70\x56\x37\xce\x8a\x3b\x55\xed\x40=
\x21\x12"
-+    (uint8_t*)"\xaa", 80, (uint8_t*)"Test Using Larger Than Block-Size
Key - Hash Key First", 54,
-+  =20
(uint8_t*)"\xaa\x4a\xe5\xe1\x52\x72\xd0\x0e\x95\x70\x56\x37\xce\x8a\x3b\x=
55\xed\x40\x21\x12"
-   }, {
--    "\xaa", 80,
--    "Test Using Larger Than Block-Size Key and Larger Than One
Block-Size Data", 73,
--  =20
"\xe8\xe9\x9d\x0f\x45\x23\x7d\x78\x6d\x6b\xba\xa7\x96\x5c\x78\x08\xbb\xff=
\x1a\x91"
-+    (uint8_t*)"\xaa", 80,
-+    (uint8_t*)"Test Using Larger Than Block-Size Key and Larger Than
One Block-Size Data", 73,
-+  =20
(uint8_t*)"\xe8\xe9\x9d\x0f\x45\x23\x7d\x78\x6d\x6b\xba\xa7\x96\x5c\x78\x=
08\xbb\xff\x1a\x91"
-   }};
-
-   debug("tpm_test_hmac()");
-   for (i =3D 0; i < sizeof(test_cases) / sizeof(test_cases[0]); i++) {
--    if (strlen(test_cases[i].key) < test_cases[i].key_len) {
-+    if (strlen((char*)test_cases[i].key) < test_cases[i].key_len) {
-       uint8_t key[test_cases[i].key_len];
-       memset(key, test_cases[i].key[0], test_cases[i].key_len);
-       hmac_init(&ctx, key, test_cases[i].key_len);
-     } else {
-       hmac_init(&ctx, test_cases[i].key, test_cases[i].key_len);
-     }
--    for (j =3D 0; j < test_cases[i].data_len; j +=3D
strlen(test_cases[i].data)) {
--      hmac_update(&ctx, test_cases[i].data, strlen(test_cases[i].data))=
;
-+    for (j =3D 0; j < test_cases[i].data_len; j +=3D
strlen((char*)test_cases[i].data)) {
-+      hmac_update(&ctx, test_cases[i].data,
strlen((char*)test_cases[i].data));
-     }
-     hmac_final(&ctx, digest);
-     if (memcmp(digest, test_cases[i].digest, SHA1_DIGEST_LENGTH) !=3D 0=
)
return -1;
-@@ -173,9 +174,9 @@ static int tpm_test_hmac(void)
- static int tpm_test_rsa_EK(void)
- {
-   int res =3D 0;
--  char *data =3D "RSA PKCS #1 v1.5 Test-String";
-+  uint8_t *data =3D (uint8_t*)"RSA PKCS #1 v1.5 Test-String";
-   uint8_t buf[256];
--  size_t buf_len, data_len =3D strlen(data);
-+  size_t buf_len, data_len =3D strlen((char*)data);
-   rsa_private_key_t priv_key;
-   rsa_public_key_t pub_key;
-
-diff -uprN orig/tpm_emulator-0.4/tpm/tpm_ticks.c
tpm_emulator/tpm/tpm_ticks.c
---- orig/tpm_emulator-0.4/tpm/tpm_ticks.c    2006-06-23
03:37:07.000000000 -0700
-+++ tpm_emulator/tpm/tpm_ticks.c    2006-07-24 14:35:35.000000000 -0700
-@@ -1,6 +1,7 @@
- /* Software-Based Trusted Platform Module (TPM) Emulator for Linux
-  * Copyright (C) 2004 Mario Strasser <mast@gmx.net>,
-  *                    Swiss Federal Institute of Technology (ETH) Zuric=
h
-+ * Copyright (C) 2005 INTEL Corp
-  *
-  * This module is free software; you can redistribute it and/or modify
-  * it under the terms of the GNU General Public License as published
-@@ -39,9 +40,7 @@ TPM_RESULT TPM_SetTickType(TPM_TICKTYPE
- TPM_RESULT TPM_GetTicks(TPM_CURRENT_TICKS *currentTime)
- {
-   info("TPM_GetTicks()");
--  memcpy(currentTime, &tpmData.stany.data.currentTicks,
--    sizeof(TPM_CURRENT_TICKS));
--  return TPM_SUCCESS;
-+  return TPM_DISABLED_CMD;
- }
-
- TPM_RESULT TPM_TickStampBlob(TPM_KEY_HANDLE keyHandle, TPM_NONCE
*antiReplay,
-@@ -49,64 +48,11 @@ TPM_RESULT TPM_TickStampBlob(TPM_KEY_HAN
-                              TPM_CURRENT_TICKS *currentTicks,
-                              UINT32 *sigSize, BYTE **sig)
- {
--  TPM_RESULT res;
--  TPM_KEY_DATA *key;
--  BYTE *info, *p;
--  UINT32 info_length, length;
-   info("TPM_TickStampBlob()");
--  /* get key */
--  key =3D tpm_get_key(keyHandle);
--  if (key =3D=3D NULL) return TPM_INVALID_KEYHANDLE;
--  /* verify authorization */
--  res =3D tpm_verify_auth(auth1, key->usageAuth, keyHandle);
--  if (res !=3D TPM_SUCCESS) return res;
--  if (key->keyUsage !=3D TPM_KEY_SIGNING && key->keyUsage !=3D TPM_KEY_=
LEGACY
--      && key->keyUsage !=3D TPM_KEY_IDENTITY) return TPM_INVALID_KEYUSA=
GE;
--  /* get current ticks */
--  TPM_GetTicks(currentTicks);
--  /* sign data using signature scheme PKCS1_SHA1 and TPM_SIGN_INFO
container */
--  *sigSize =3D key->key.size >> 3;
--  *sig =3D tpm_malloc(*sigSize);
--  if (*sig =3D=3D NULL) return TPM_FAIL;
--  /* setup TPM_SIGN_INFO structure */
--  info_length =3D 30 + sizeof(TPM_DIGEST) +
sizeof_TPM_CURRENT_TICKS(currentTicks);
--  info =3D tpm_malloc(info_length);
--  if (info =3D=3D NULL) {
--    tpm_free(*sig);
--    return TPM_FAIL;
--  }
--  memcpy(&info[0], "\x05\x00TSTP", 6);
--  memcpy(&info[6], antiReplay->nonce, 20);
--  *(UINT32*)&info[26] =3D CPU_TO_BE32(20
--                        + sizeof_TPM_CURRENT_TICKS(currentTicks));
--  memcpy(&info[30], digestToStamp->digest, sizeof(TPM_DIGEST));
--  p =3D &info[30 + sizeof(TPM_DIGEST)];
--  length =3D sizeof_TPM_CURRENT_TICKS(currentTicks);
--  if (tpm_marshal_TPM_CURRENT_TICKS(&p, &length, currentTicks)
--      || rsa_sign(&key->key, RSA_SSA_PKCS1_SHA1, info, info_length,
*sig)) { =20
--    tpm_free(*sig);
--    tpm_free(info);
--    return TPM_FAIL;
--  }
--  return TPM_SUCCESS;
-+  return TPM_DISABLED_CMD;
- }
-
- void tpm_update_ticks(void)
- {
--  if (tpmData.stany.data.currentTicks.tag =3D=3D 0) {
--    tpmData.stany.data.currentTicks.tag =3D TPM_TAG_CURRENT_TICKS;
--    tpmData.stany.data.currentTicks.currentTicks +=3D tpm_get_ticks();
--/* removed since v1.2 rev 94
--    tpmData.stany.data.currentTicks.tickType =3D
tpmData.permanent.data.tickType;
--*/
--    tpm_get_random_bytes(tpmData.stany.data.currentTicks.tickNonce.nonc=
e,
--      sizeof(TPM_NONCE));
--    tpmData.stany.data.currentTicks.tickRate =3D 1;
--/* removed since v1.2 rev 94
--    tpmData.stany.data.currentTicks.tickSecurity =3D TICK_SEC_NO_CHECK;=

--*/
--  } else {
--    tpmData.stany.data.currentTicks.currentTicks +=3D tpm_get_ticks(); =
=20
--  }
- }
-
-diff -uprN orig/tpm_emulator-0.4/tpm/tpm_transport.c
tpm_emulator/tpm/tpm_transport.c
---- orig/tpm_emulator-0.4/tpm/tpm_transport.c    2006-06-23
03:37:07.000000000 -0700
-+++ tpm_emulator/tpm/tpm_transport.c    2006-07-24 14:35:35.000000000 -0=
700
-@@ -189,7 +189,7 @@ static void decrypt_wrapped_command(BYTE
-     sha1_init(&sha1);
-     sha1_update(&sha1, auth->nonceEven.nonce,
sizeof(auth->nonceEven.nonce));
-     sha1_update(&sha1, auth->nonceOdd.nonce,
sizeof(auth->nonceOdd.nonce));
--    sha1_update(&sha1, "in", 2);
-+    sha1_update(&sha1, (BYTE*)"in", 2);
-     sha1_update(&sha1, secret, sizeof(TPM_SECRET));
-     j =3D CPU_TO_BE32(i);
-     sha1_update(&sha1, (BYTE*)&j, 4);
-@@ -211,7 +211,7 @@ static void encrypt_wrapped_command(BYTE
-     sha1_init(&sha1);
-     sha1_update(&sha1, auth->nonceEven.nonce,
sizeof(auth->nonceEven.nonce));
-     sha1_update(&sha1, auth->nonceOdd.nonce,
sizeof(auth->nonceOdd.nonce));
--    sha1_update(&sha1, "out", 3);
-+    sha1_update(&sha1, (BYTE*)"out", 3);
-     sha1_update(&sha1, secret, sizeof(TPM_SECRET));
-     j =3D CPU_TO_BE32(i);
-     sha1_update(&sha1, (BYTE*)&j, 4);
-diff -uprN orig/tpm_emulator-0.4/tpmd.c tpm_emulator/tpmd.c
---- orig/tpm_emulator-0.4/tpmd.c    1969-12-31 16:00:00.000000000 -0800
-+++ tpm_emulator/tpmd.c    2006-07-24 14:35:35.000000000 -0700
-@@ -0,0 +1,156 @@
-+/* Software-Based Trusted Platform Module (TPM) Emulator for Linux
-+ * Copyright (C) 2005 INTEL Corp
-+ *
-+ * This module 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 module is distributed in the hope that it will be useful,
-+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
-+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
-+ * GNU General Public License for more details.
-+ *
-+ */
-+
-+#include <stdio.h>
-+#include <stdlib.h>
-+#include <unistd.h>
-+#include <string.h>
-+#include <sys/types.h>
-+#include <sys/stat.h>
-+#include <fcntl.h>
-+#include <sys/time.h>
-+
-+#include "tpm_emulator.h"
-+
-+#define TPM_RX_FNAME "/var/tpm/tpm_in.fifo"
-+#define TPM_TX_FNAME "/var/tpm/tpm_out.fifo"
-+
-+#define BUFFER_SIZE 2048
-+
-+static int devurandom=3D0;
-+    =20
-+void get_random_bytes(void *buf, int nbytes) {
-+=20
-+  if (devurandom =3D=3D 0) {
-+    devurandom =3D open("/dev/urandom", O_RDONLY);
-+  }
-+
-+  if (read(devurandom, buf, nbytes) !=3D nbytes) {
-+      printf("Can't get random number.\n");
-+      exit(-1);
-+  }
-+}
-+
-+uint64_t tpm_get_ticks(void)
-+{
-+  //struct timeval tv;
-+  //int gettimeofday(&tv, struct timezone *tz);
-+  return 0;
-+}
-+
-+int main(int argc, char **argv)
-+{
-+  uint8_t in[BUFFER_SIZE], *out;
-+  uint32_t out_size;
-+  int in_size, written;
-+  int i;
-+  struct stat file_info;
-+
-+  int tpm_tx_fh=3D-1, tpm_rx_fh=3D-1;
-+  if (argc < 2) {
-+    printf("Usage: tpmd clear|save|deactivated\n" );
-+      return -1;
-+  }
-+
-+  /* initialize TPM emulator */
-+  if (!strcmp(argv[1], "clear")) {
-+    printf("Initializing tpm: %s\n", argv[1]);
-+    tpm_emulator_init(1);
-+  } else if (!strcmp(argv[1], "save")) {
-+    printf("Initializing tpm: %s\n", argv[1]);
-+    tpm_emulator_init(2);
-+  } else if (!strcmp(argv[1], "deactivated")) {
-+    printf("Initializing tpm: %s\n", argv[1]);
-+    tpm_emulator_init(3);
-+  } else {
-+    printf("invalid startup mode '%s'; must be 'clear', "
-+      "'save' (default) or 'deactivated", argv[1]);
-+    return -1;
-+  }
-+
-+  if ( stat(TPM_RX_FNAME, &file_info) =3D=3D -1) {
-+    if ( mkfifo(TPM_RX_FNAME, S_IWUSR | S_IRUSR ) ) {
-+      printf("Failed to create fifo %s.\n", TPM_RX_FNAME);
-+      return -1;
-+    }
-+  }
-+
-+  if ( stat(TPM_TX_FNAME, &file_info) =3D=3D -1) {
-+    if ( mkfifo(TPM_TX_FNAME, S_IWUSR | S_IRUSR ) ) {
-+      printf("Failed to create fifo %s.\n", TPM_TX_FNAME);
-+      return -1;
-+    }
-+  }
-+
-+  while (1) {
-+abort_command:
-+    if (tpm_rx_fh < 0) {
-+      tpm_rx_fh =3D open(TPM_RX_FNAME, O_RDONLY);
-+    }
-+  =20
-+    if (tpm_rx_fh < 0) {
-+      printf("ERROR: failed to open devices to listen to guest.\n");
-+      return -1;
-+    }
-+  =20
-+    if (tpm_tx_fh < 0) {
-+      tpm_tx_fh =3D open(TPM_TX_FNAME, O_WRONLY);
-+    }
-+
-+    if (tpm_tx_fh < 0) {
-+      printf("ERROR: failed to open devices to respond to guest.\n");
-+      return -1;
-+    }
-+
-+    in_size =3D read(tpm_rx_fh, in, BUFFER_SIZE);
-+    if (in_size < 6) { // Magic size of minium TPM command
-+      printf("Recv[%d] to small: 0x", in_size);
-+      if (in_size <=3D 0) {
-+          close(tpm_rx_fh);
-+          tpm_rx_fh =3D -1;
-+          goto abort_command;
-+      }
-+    } else {
-+      printf("Recv[%d]: 0x", in_size);
-+      for (i=3D0; i< in_size; i++)
-+        printf("%x ", in[i]);
-+      printf("\n");
-+    }
-+
-+  =20
-+    if (tpm_handle_command(in, in_size, &out, &out_size) !=3D 0) {
-+        printf("ERROR: Handler Failed.\n");
-+    }
-+
-+    written =3D write(tpm_tx_fh, out, out_size);
-+
-+    if (written !=3D out_size ) {
-+      printf("ERROR: Part of response not written %d/%d.\nAttempt: ",
written, out_size);
-+    } else {
-+      printf("Sent[%Zu]: ", out_size);
-+    }
-+    for (i=3D0; i< out_size; i++)
-+      printf("%x ", out[i]);
-+    printf("\n");
-+    tpm_free(out);
-+
-+  } // loop
-+
-+  tpm_emulator_shutdown();
-+
-+  close(tpm_tx_fh);
-+  close(tpm_rx_fh);
-+
-+}
-Binary files orig/tpm_emulator-0.4/tpm_emulator and
tpm_emulator/tpm_emulator differ
-diff -uprN orig/tpm_emulator-0.4/tpm_version.h tpm_emulator/tpm_version.=
h
---- orig/tpm_emulator-0.4/tpm_version.h    2006-06-23
03:37:07.000000000 -0700
-+++ tpm_emulator/tpm_version.h    2006-07-24 14:35:41.000000000 -0700
-@@ -2,5 +2,5 @@
- #define _TPM_VERSION_H_
- #define VERSION_MAJOR 0
- #define VERSION_MINOR 4
--#define VERSION_BUILD 1151058734
-+#define VERSION_BUILD 1153776940
- #endif /* _TPM_VERSION_H_ */
diff --git a/tools/vtpm/vtpm-0.5.1-LDLIBS.patch
b/tools/vtpm/vtpm-0.5.1-LDLIBS.patch
--- a/tools/vtpm/vtpm-0.5.1-LDLIBS.patch
+++ /dev/null
@@ -1,12 +0,0 @@
-diff -Naurp tpm_emulator-0.5.1/tpmd/Makefile
tpm_emulator-0.5.1/tpmd/Makefile
---- tpm_emulator-0.5.1/tpmd/Makefile
-+++ tpm_emulator-0.5.1/tpmd/Makefile
-@@ -8,7 +8,7 @@ WFLAGS  :=3D -Wall -Wno-unused -Wpointer-a
-            #WFLAGS  +=3D -Wextra -Wcast-qual -Wmissing-prototypes
-Wmissing-declarations -Wstrict-aliasing
- CFLAGS  +=3D $(WFLAGS) -g -I.. -I. -O2 -fno-strict-aliasing
- CFLAGS  +=3D -I../../../../tools/vtpm_manager/manager
--LDFLAGS +=3D -lgmp
-+LDLIBS  +=3D -lgmp
-
- BINDIR  :=3D /usr/bin/
-
diff --git a/tools/vtpm/vtpm-0.5.1.patch b/tools/vtpm/vtpm-0.5.1.patch
--- a/tools/vtpm/vtpm-0.5.1.patch
+++ /dev/null
@@ -1,766 +0,0 @@
-diff -Naurp tpm_emulator-0.5.1/Makefile tpm5-test/Makefile
---- tpm_emulator-0.5.1/Makefile    2008-02-14 03:22:48.000000000 -0500
-+++ tpm5-test/Makefile    2009-07-15 09:45:28.000000000 -0400
-@@ -10,7 +10,7 @@ VERSION_MINOR  :=3D 5
- VERSION_BUILD  :=3D $(shell date +"%s")
- VERSION_SUFFIX :=3D .1
-
--SUBDIRS :=3D tpmd tpmd_dev tddl
-+SUBDIRS :=3D tpmd
-
- all: version all-recursive
-
-@@ -48,12 +48,12 @@ user_install: user
- modules_install: modules
-     @$(MAKE) -C tpmd_dev install || exit -1
-
--DIRS    :=3D . tpm crypto tpmd tpmd_dev tddl tpmd_dev_openbsd
-+DIRS    :=3D . tpm crypto tpmd
- DISTSRC :=3D $(foreach dir, $(DIRS), $(wildcard $(dir)/*.c))
- DISTSRC +=3D $(foreach dir, $(DIRS), $(wildcard $(dir)/*.h))
--DIRS    :=3D . tpmd tpmd_dev tddl tpmd_dev_openbsd
-+DIRS    :=3D . tpmd
- DISTSRC +=3D $(foreach dir, $(DIRS), $(dir)/Makefile)
--DISTSRC +=3D ./README ./AUTHORS ./ChangeLog tpmd_dev/tpmd_dev.rules.in
-+DISTSRC +=3D ./README ./AUTHORS ./ChangeLog
- DISTDIR :=3D tpm_emulator-$(VERSION_MAJOR).$(VERSION_MINOR)$(VERSION_SU=
FFIX)
-
- dist: $(DISTSRC)
-diff -Naurp tpm_emulator-0.5.1/tpm/tpm_capability.c
tpm5-test/tpm/tpm_capability.c
---- tpm_emulator-0.5.1/tpm/tpm_capability.c    2008-02-14
03:22:48.000000000 -0500
-+++ tpm5-test/tpm/tpm_capability.c    2009-07-16 12:04:20.000000000 -040=
0
-@@ -136,8 +136,19 @@ static TPM_RESULT cap_property(UINT32 su
-
-     case TPM_CAP_PROP_TIS_TIMEOUT:
-       debug("[TPM_CAP_PROP_TIS_TIMEOUT]");
--      /* TODO: TPM_CAP_PROP_TIS_TIMEOUT */
--      return TPM_FAIL;
-+      /* TODO: TPM_CAP_PROP_TIS_TIMEOUT: Measure these values and
determine correct ones */
-+      UINT32 len =3D *respSize =3D 16;
-+      BYTE *ptr =3D *resp =3D tpm_malloc(*respSize);
-+      if (ptr =3D=3D NULL ||
-+          tpm_marshal_UINT32(&ptr, &len, 200000) ||
-+          tpm_marshal_UINT32(&ptr, &len, 200000) ||
-+          tpm_marshal_UINT32(&ptr, &len, 200000) ||
-+          tpm_marshal_UINT32(&ptr, &len, 200000)) {
-+        tpm_free(*resp);
-+        return TPM_FAIL;
-+      }
-+      return TPM_SUCCESS;
-+
-
-     case TPM_CAP_PROP_STARTUP_EFFECT:
-       debug("[TPM_CAP_PROP_STARTUP_EFFECT]");
-@@ -189,8 +200,12 @@ static TPM_RESULT cap_property(UINT32 su
-
-     case TPM_CAP_PROP_DURATION:
-       debug("[TPM_CAP_PROP_DURATION]");
--      /* TODO: TPM_CAP_PROP_DURATION */
--      return TPM_FAIL;
-+      /* TODO: TPM_CAP_PROP_DURATION: Measure these values and return
accurate ones */
-+      BYTE dur[]=3D
{0x0,0x0,0x0,0xc,0x0,0x7,0xa1,0x20,0x0,0x1e,0x84,0x80,0x11,0xe1,0xa3,0x0}=
;
-+      *respSize =3D 16;
-+      *resp =3D tpm_malloc(*respSize);
-+      memcpy(*resp,dur,16);
-+
-
-     case TPM_CAP_PROP_ACTIVE_COUNTER:
-       debug("[TPM_CAP_PROP_ACTIVE_COUNTER]");
-diff -Naurp tpm_emulator-0.5.1/tpmd/Makefile tpm5-test/tpmd/Makefile
---- tpm_emulator-0.5.1/tpmd/Makefile    2008-02-14 03:22:48.000000000 -0=
500
-+++ tpm5-test/tpmd/Makefile    2009-07-16 12:08:26.000000000 -0400
-@@ -8,9 +8,10 @@ WFLAGS  :=3D -Wall -Wno-unused -Wpointer-a
-            -Wwrite-strings -Wsign-compare -Wno-multichar
-            #WFLAGS  +=3D -Wextra -Wcast-qual -Wmissing-prototypes
-Wmissing-declarations -Wstrict-aliasing
- CFLAGS  +=3D $(WFLAGS) -g -I.. -I. -O2 -fno-strict-aliasing
-+CFLAGS  +=3D -I../../../../tools/vtpm_manager/manager
- LDFLAGS +=3D -lgmp
-
--BINDIR  :=3D /usr/sbin/
-+BINDIR  :=3D /usr/bin/
-
- TPMD    :=3D tpmd
- DIRS    :=3D ../tpm ../crypto
-@@ -18,6 +19,8 @@ SRCS    :=3D $(foreach dir, $(DIRS), $(wil
- OBJS    :=3D $(patsubst %.c, %.o, $(SRCS))
- OBJS    :=3D $(foreach dir, $(DIRS), $(patsubst $(dir)/%.o, %.o,
$(filter $(dir)/%.o, $(OBJS))))
-
-+VTPM_BIN :=3D vtpmd
-+
- vpath %.c $(strip $(DIRS))
-
- all: $(TPMD)
-@@ -32,10 +35,8 @@ TPMD_GROUP ?=3D tss
- INSTALL    ?=3D install
-
- install: $(TPMD)
--    $(INSTALL) -m 755 -o $(TPMD_USER) -g $(TPMD_GROUP) -d
$(DESTDIR)/var/lib/tpm
--    $(INSTALL) -m 755 -o $(TPMD_USER) -g $(TPMD_GROUP) -d
$(DESTDIR)/var/run/tpm
-     $(INSTALL) -D -d $(DESTDIR)/$(BINDIR)
--    $(INSTALL) -m 755 $(TPMD) $(DESTDIR)/$(BINDIR)
-+    $(INSTALL) -m 755 $(TPMD) $(DESTDIR)/$(BINDIR)/$(VTPM_BIN)
-
- .PHONY: all clean install
-
-diff -Naurp tpm_emulator-0.5.1/tpmd/tpmd.c tpm5-test/tpmd/tpmd.c
---- tpm_emulator-0.5.1/tpmd/tpmd.c    2008-02-14 03:22:48.000000000 -050=
0
-+++ tpm5-test/tpmd/tpmd.c    2009-07-16 11:19:05.000000000 -0400
-@@ -32,6 +32,9 @@
- #include <grp.h>
- #include "tpm_emulator_config.h"
- #include "tpm/tpm_emulator.h"
-+#include "tpm/tpm_structures.h"
-+#include "tpm/tpm_marshalling.h"
-+#include "vtpm_manager.h"
-
- #define TPM_DAEMON_NAME     "tpmd"
- #define TPM_CMD_BUF_SIZE    4096
-@@ -39,6 +42,24 @@
- #define TPM_RANDOM_DEVICE   "/dev/urandom"
- #undef  TPM_MKDIRS
-
-+#ifdef VTPM_MULTI_VM
-+ #define DEV_BE "/dev/vtpm"
-+ #define DEV_FE "/dev/tpm"
-+#else
-+ #define PVM_RX_FIFO_D "/var/vtpm/fifos/tpm_cmd_to_%d.fifo"
-+ #define PVM_TX_FIFO "/var/vtpm/fifos/tpm_rsp_from_all.fifo"
-+ #define HVM_RX_FIFO_D "/var/vtpm/socks/%d.socket"
-+
-+ #define VTPM_RX_FIFO_D "/var/vtpm/fifos/vtpm_rsp_to_%d.fifo"
-+ #define VTPM_TX_FIFO "/var/vtpm/fifos/vtpm_cmd_from_all.fifo"
-+
-+ static char *vtpm_rx_name=3DNULL;
-+#endif
-+
-+ static int vtpm_tx_fh=3D-1, vtpm_rx_fh=3D-1;
-+
-+#define BUFFER_SIZE 2048
-+
- static volatile int stopflag =3D 0;
- static int is_daemon =3D 0;
- static int opt_debug =3D 0;
-@@ -49,6 +70,8 @@ static const char *opt_storage_file =3D "/
- static uid_t opt_uid =3D 0;
- static gid_t opt_gid =3D 0;
- static int tpm_startup =3D 2;
-+static int vtpm_type =3D VTPM_TYPE_PVM;
-+int dmi_id =3D 0;
- static int rand_fh;
-
- void tpm_log(int priority, const char *fmt, ...)
-@@ -90,56 +113,241 @@ uint64_t tpm_get_ticks(void)
-
- int tpm_write_to_file(uint8_t *data, size_t data_length)
- {
--    int fh;
--    ssize_t res;
--    fh =3D open(opt_storage_file, O_WRONLY | O_TRUNC | O_CREAT, S_IRUSR=

| S_IWUSR);
--    if (fh < 0) return -1;
--    while (data_length > 0) {
--        res =3D write(fh, data, data_length);
--    if (res < 0) {
--        close(fh);
--        return -1;
--    }
--    data_length -=3D res;
--    data +=3D res;
-+  int res, out_data_size, in_header_size;
-+  BYTE *ptr, *out_data, *in_header;
-+  UINT32 result, len, in_rsp_size;
-+  UINT16 tag =3D VTPM_TAG_REQ;
-+  =20
-+  printf("Saving NVM\n");
-+  if (vtpm_tx_fh < 0) {
-+#ifdef VTPM_MUTLI_VM
-+    vtpm_tx_fh =3D open(DEV_FE, O_RDWR);
-+#else
-+    vtpm_tx_fh =3D open(VTPM_TX_FIFO, O_WRONLY);
-+#endif
-+  }
-+
-+  if (vtpm_tx_fh < 0) {
-+        return -1;
-+  }
-+
-+  // Send request to VTPM Manager to encrypt data
-+#ifdef VTPM_MUTLI_VM
-+  out_data_size =3D len =3D VTPM_COMMAND_HEADER_SIZE_CLT + data_length;=

-+#else
-+  out_data_size =3D len =3D VTPM_COMMAND_HEADER_SIZE_SRV + data_length;=

-+#endif
-+=20
-+  out_data =3D ptr =3D (BYTE *) malloc(len);
-+
-+  if (ptr =3D=3D NULL
-+#ifndef VTPM_MUTLI_VM
-+      || tpm_marshal_UINT32(&ptr, &len, dmi_id)
-+#endif
-+      || tpm_marshal_UINT16(&ptr, &len, tag)
-+#ifdef VTPM_MUTLI_VM
-+      || tpm_marshal_UINT32(&ptr, &len, out_data_size)
-+#else
-+      || tpm_marshal_UINT32(&ptr, &len, out_data_size - sizeof(uint32_t=
))
-+#endif=20
-+      || tpm_marshal_UINT32(&ptr, &len, VTPM_ORD_SAVENVM)
-+      || tpm_marshal_BYTE_ARRAY(&ptr, &len, data, data_length)) {
-+    free(out_data);
-+    return -1;
-+  }
-+=20
-+  printf("\tSending SaveNVM Command.\n");
-+  res =3D write(vtpm_tx_fh, out_data, out_data_size);
-+  free(out_data);
-+  if (res !=3D out_data_size) return -1;
-+
-+  if (vtpm_rx_fh < 0) {
-+#ifdef VTPM_MUTLI_VM
-+    vtpm_rx_fh =3D vtpm_tx_fh
-+#else
-+    if (vtpm_rx_name =3D=3D NULL) {
-+      vtpm_rx_name =3D malloc(10 + strlen(VTPM_RX_FIFO_D));
-+      sprintf(vtpm_rx_name, VTPM_RX_FIFO_D, (uint32_t) dmi_id);
-     }
--    close(fh);
--    return 0;
-+    vtpm_rx_fh =3D open(vtpm_rx_name, O_RDONLY);
-+#endif
-+  }
-+
-+  if (vtpm_rx_fh < 0) {
-+        return -1;
-+  }
-+=20
-+  // Read Header of response so we can get the size & status
-+#ifdef VTPM_MUTLI_VM
-+  in_header_size =3D len =3D VTPM_COMMAND_HEADER_SIZE_CLT;
-+#else
-+  in_header_size =3D len =3D VTPM_COMMAND_HEADER_SIZE_SRV;
-+#endif
-+  in_header =3D ptr =3D malloc(in_header_size);
-+=20
-+  printf("\tReading SaveNVM header.\n");
-+  res =3D read(vtpm_rx_fh, in_header, in_header_size);
-+
-+  if ( (res !=3D in_header_size)
-+#ifndef VTPM_MUTLI_VM
-+       || tpm_unmarshal_UINT32(&ptr, &len, (UINT32*)&dmi_id)
-+#endif
-+       || tpm_unmarshal_UINT16(&ptr, &len, &tag)
-+       || tpm_unmarshal_UINT32(&ptr, &len, &in_rsp_size)
-+       || tpm_unmarshal_UINT32(&ptr, &len, &result) ) {
-+      free(in_header);
-+      return -1;
-+  }
-+  free(in_header);
-+=20
-+  if (result !=3D VTPM_SUCCESS) {
-+      return -1;=20
-+  }
-+
-+#ifdef VTPM_MUTLI_VM
-+  close(vtpm_tx_fh); close(vtpm_rx_fh);
-+#endif
-+    =20
-+  printf("\tFinishing up SaveNVM\n");
-+  return (0);
- }
-
- int tpm_read_from_file(uint8_t **data, size_t *data_length)
- {
--    int fh;
--    ssize_t res;
--    size_t total_length;
--    fh =3D open(opt_storage_file, O_RDONLY);
--    if (fh < 0) return -1;
--    total_length =3D lseek(fh, 0, SEEK_END);
--    lseek(fh, 0, SEEK_SET);
--    *data =3D tpm_malloc(total_length);
--    if (*data =3D=3D NULL) {
--        close(fh);
--        return -1;
--    }
--    *data_length =3D 0;
--    while (total_length > 0) {
--        res =3D read(fh, &(*data)[*data_length], total_length);
--    if (res < 0) {
--        close(fh);
--        tpm_free(*data);
--        return -1;
--    }
--        *data_length +=3D res;
--    total_length -=3D res;
-+  int res, out_data_size, in_header_size;
-+  uint8_t *ptr, *out_data, *in_header;
-+  UINT16 tag =3D VTPM_TAG_REQ;
-+  UINT32 len, in_rsp_size, result;
-+#ifdef VTPM_MUTLI_VM
-+    int vtpm_rx_fh, vtpm_tx_fh;
-+#endif
-+  =20
-+  printf("Loading NVM.\n");
-+  if (vtpm_tx_fh < 0) {
-+#ifdef VTPM_MUTLI_VM
-+    vtpm_tx_fh =3D open(DEV_FE, O_RDWR);
-+#else
-+    vtpm_tx_fh =3D open(VTPM_TX_FIFO, O_WRONLY);
-+#endif
-+  }
-+
-+  if (vtpm_tx_fh < 0) {
-+    printf("Error in read_from_file:301\n");
-+        return -1;
-+  }
-+
-+  // Send request to VTPM Manager to encrypt data
-+#ifdef VTPM_MUTLI_VM
-+  out_data_size =3D len =3D VTPM_COMMAND_HEADER_SIZE_CLT;
-+#else
-+  out_data_size =3D len =3D VTPM_COMMAND_HEADER_SIZE_SRV;
-+#endif
-+  out_data =3D ptr =3D (BYTE *) malloc(len);
-+
-+  if (ptr =3D=3D NULL
-+#ifndef VTPM_MUTLI_VM
-+      || tpm_marshal_UINT32(&ptr, &len, dmi_id)
-+#endif=20
-+      || tpm_marshal_UINT16(&ptr, &len, tag)
-+#ifdef VTPM_MUTLI_VM
-+      || tpm_marshal_UINT32(&ptr, &len, out_data_size)
-+#else
-+      || tpm_marshal_UINT32(&ptr, &len, out_data_size - sizeof(uint32_t=
))
-+#endif
-+      || tpm_marshal_UINT32(&ptr, &len, VTPM_ORD_LOADNVM)) {
-+    free(out_data);
-+    printf("Error in read_from_file:325\n");
-+
-+    return -1;
-+  }
-+
-+  printf("\tSending LoadNVM command\n");
-+  res =3D write(vtpm_tx_fh, out_data, out_data_size);
-+  free(out_data);
-+  if (res !=3D out_data_size)
-+    {
-+    printf("Error in read_from_file:335\n");
-+    return -1;
-+    }
-+
-+    if (vtpm_rx_fh < 0) {
-+#ifdef VTPM_MUTLI_VM
-+    vtpm_rx_fh =3D vtpm_tx_fh;
-+#else
-+    if (vtpm_rx_name =3D=3D NULL) {
-+      vtpm_rx_name =3D malloc(10 + strlen(VTPM_RX_FIFO_D));
-+      sprintf(vtpm_rx_name, VTPM_RX_FIFO_D, (uint32_t) dmi_id);
-     }
--    close(fh);
--    return 0;
-+    vtpm_rx_fh =3D open(vtpm_rx_name, O_RDONLY);
-+#endif
-+  }
-+
-+  if (vtpm_rx_fh < 0) {
-+    printf("Error in read_from_file:352\n");  =20
-+    return -1;
-+  }
-+=20
-+  // Read Header of response so we can get the size & status
-+#ifdef VTPM_MUTLI_VM
-+  in_header_size =3D len =3D VTPM_COMMAND_HEADER_SIZE_CLT;
-+#else
-+  in_header_size =3D len =3D VTPM_COMMAND_HEADER_SIZE_SRV;
-+#endif
-+  in_header =3D ptr =3D malloc(in_header_size);
-+=20
-+  printf("\tReading LoadNVM header\n");
-+  res =3D read(vtpm_rx_fh, in_header, in_header_size);
-+
-+  if ( (res !=3D in_header_size)
-+#ifndef VTPM_MUTLI_VM
-+       || tpm_unmarshal_UINT32(&ptr, &len, (UINT32*)&dmi_id)
-+#endif
-+       || tpm_unmarshal_UINT16(&ptr, &len, &tag)
-+       || tpm_unmarshal_UINT32(&ptr, &len, &in_rsp_size)
-+       || tpm_unmarshal_UINT32(&ptr, &len, &result) ) {
-+      free(in_header);
-+      printf("Error in read_from_file:375\n");   =20
-+      return -1;
-+  }
-+  free(in_header);
-+=20
-+  if (result !=3D VTPM_SUCCESS) {
-+    printf("Error in read_from_file:381\n");
-+    return -1;=20
-+  }
-+
-+  // Read Encrypted data from VTPM Manager
-+  *data_length =3D in_rsp_size - VTPM_COMMAND_HEADER_SIZE_CLT;
-+  *data =3D (uint8_t *) malloc(*data_length);
-+
-+  printf("\tReading clear data from LoadNVM.\n");
-+  res =3D read(vtpm_rx_fh, *data, *data_length);
-+#ifdef VTPM_MUTLI_VM
-+  close(vtpm_rx_fh);close(vtpm_tx_fh);
-+#endif
-+  =20
-+  printf("\tReturing from loading NVM\n");
-+  if (res !=3D (int)*data_length) {
-+      free(*data);
-+      printf("Error in read_from_file:398\n");
-+      return -1;
-+  } else {
-+      return 0;
-+  }
-+
-+
-+  =20
- }
-
- static void print_usage(char *name)
- {
-     printf("usage: %s [-d] [-f] [-s storage file] [-u unix socket name]=
 "
--           "[-o user name] [-g group name] [-h] [startup mode]\n", name=
);
-+           "[-o user name] [-g group name] [-h]"
-+#ifdef VTPM_MULTI_VM
-+       "clear|save|deactivated\n", name);
-+#else
-+       "clear|save|deactivated pvm|hvm vtpmid\n", name);
-+#endif
-     printf("  d : enable debug mode\n");
-     printf("  f : forces the application to run in the foreground\n");
-     printf("  s : storage file to use (default: %s)\n", opt_storage_fil=
e);
-@@ -205,7 +413,13 @@ static void parse_options(int argc, char
-                 exit(EXIT_SUCCESS);
-         }
-     }
--    if (optind < argc) {
-+    /*Make sure we have all required options*/
-+#ifdef VTPM_MULTI_VM
-+#define EXTRA_OPTS 0
-+#else
-+#define EXTRA_OPTS 2
-+#endif
-+    if (optind < argc - EXTRA_OPTS ) {
-         debug("startup mode =3D '%s'", argv[optind]);
-         if (!strcmp(argv[optind], "clear")) {
-             tpm_startup =3D 1;
-@@ -219,6 +433,25 @@ static void parse_options(int argc, char
-             print_usage(argv[0]);
-             exit(EXIT_SUCCESS);
-         }
-+#ifndef VTPM_MULTI_VM
-+        ++optind;
-+    if(!strcmp(argv[optind], "pvm")) {
-+        vtpm_type =3D VTPM_TYPE_PVM;    // Get commands from vTPM
Manager through fifo
-+    } else if (!strcmp(argv[optind], "hvm")) {
-+        vtpm_type =3D VTPM_TYPE_HVM;    // Get commands from qemu via s=
ocket
-+        } else {
-+        error("Invalid vm mode '%s'; must be 'pvm', "
-+            "or 'hvm' ", argv[optind]);
-+        print_usage(argv[0]);
-+        exit(EXIT_SUCCESS);
-+    }
-+        ++optind;
-+    dmi_id =3D atoi(argv[optind]);
-+#endif
-+    } else {
-+    error("Invalid number of arguments");
-+    print_usage(argv[0]);
-+    exit(EXIT_SUCCESS);
-     }
- }
-
-@@ -348,93 +581,180 @@ static int init_socket(const char *name)
-
- static void main_loop(void)
- {
--    int sock, fh, res;
--    int32_t in_len;
-+    int32_t in_len, written;
-     uint32_t out_len;
--    uint8_t in[TPM_CMD_BUF_SIZE], *out;
-+    uint8_t in[TPM_CMD_BUF_SIZE], *out, *addressed_out;
-+    int guest_id=3D-1;
-+    int i;
-+    char *vtpm_rx_file=3DNULL;
-+    int res;
-+
-+#ifndef VTPM_MULTI_VM
-+    int sockfd =3D -1;
-     struct sockaddr_un addr;
--    socklen_t addr_len;
--    fd_set rfds;
--    struct timeval tv;
-+    struct sockaddr_un client_addr;
-+    unsigned int client_length;
-+#endif
-+
-+    int vtpm_tx_fh=3D-1, vtpm_rx_fh=3D-1;
-+
-+#ifndef VTPM_MULTI_VM
-+  if (vtpm_type =3D=3D VTPM_TYPE_PVM) {
-+    vtpm_rx_file =3D malloc(10 + strlen(PVM_RX_FIFO_D));
-+    sprintf(vtpm_rx_file, PVM_RX_FIFO_D, (uint32_t) dmi_id);
-+  } else {
-+    vtpm_rx_file =3D malloc(10 + strlen(HVM_RX_FIFO_D));
-+    sprintf(vtpm_rx_file, HVM_RX_FIFO_D, (uint32_t) dmi_id);
-+
-+    if ( (sockfd =3D socket(PF_UNIX,SOCK_STREAM,0)) < 0) {
-+          error("Unable to create socket. errno =3D %d\n", errno);
-+      exit (-1);
-+    }
-+
-+    memset(&addr, 0, sizeof(addr));
-+    addr.sun_family =3D AF_UNIX;
-+    strcpy(addr.sun_path,vtpm_rx_file );
-+    unlink(addr.sun_path);
-+  }
-+#endif
-
-     info("staring main loop");
--    /* open UNIX socket */
--    sock =3D init_socket(opt_socket_name);
--    if (sock < 0) exit(EXIT_FAILURE);
-     /* init tpm emulator */
--    debug("initializing TPM emulator: %d", tpm_startup);
-+#ifdef VTPM_MULTI_VM
-+    debug("initializing TPM emulator: state=3D%d", tpm_startup);
-+#else
-+    debug("initializing TPM emulator: state=3D%d, type=3D%d, id=3D%d",
tpm_startup, vtpm_type, dmi_id);
-+#endif
-     tpm_emulator_init(tpm_startup);
-     /* start command processing */
-     while (!stopflag) {
-         /* wait for incomming connections */
-         debug("waiting for connections...");
--        FD_ZERO(&rfds);
--        FD_SET(sock, &rfds);
--        tv.tv_sec =3D 10;
--        tv.tv_usec =3D 0;
--        res =3D select(sock + 1, &rfds, NULL, NULL, &tv);
--        if (res < 0) {
--            error("select(sock) failed: %s", strerror(errno));
--            break;
--        } else if (res =3D=3D 0) {
--            continue;
--        }
--        addr_len =3D sizeof(addr);
--        fh =3D accept(sock, (struct sockaddr*)&addr, &addr_len);
--        if (fh < 0) {
--            error("accept() failed: %s", strerror(errno));
--            continue;
--        }
-+    if (vtpm_rx_fh < 0) {
-+#ifdef VTPM_MUTLI_VM
-+        vtpm_rx_fh =3D open(DEV_BE, O_RDWR);
-+#else
-+        if (vtpm_type =3D=3D VTPM_TYPE_PVM)
-+        {
-+        vtpm_rx_fh =3D open(vtpm_rx_file, O_RDONLY);
-+        } else {
-+        if (bind(sockfd, (struct sockaddr *)&addr, sizeof(addr)) < 0) {=

-+            error("Unable to bind(). errno =3D %d\n", errno);
-+            exit (-1);
-+        }
-+
-+        if (listen(sockfd, 10) <0) {
-+            error("Unable to listen(). errno =3D %d\n", errno);
-+            exit (-1);
-+        }
-+
-+         memset(&client_addr, 0, sizeof(client_addr));
-+         client_length =3D sizeof(client_addr);
-+
-+         vtpm_rx_fh =3D vtpm_tx_fh =3D accept(sockfd, (struct sockaddr
*)&client_addr, &client_length);
-+        }
-+#endif
-+    }
-+  =20
-+    /*Error Checking*/
-+    if (vtpm_rx_fh < 0) {
-+      error("Failed to open devices to listen to guest.\n");
-+      exit(-1);
-+    }
-+
-         /* receive and handle commands */
-         in_len =3D 0;
-         do {
-             debug("waiting for commands...");
--            FD_ZERO(&rfds);
--            FD_SET(fh, &rfds);
--            tv.tv_sec =3D TPM_COMMAND_TIMEOUT;
--            tv.tv_usec =3D 0;
--            res =3D select(fh + 1, &rfds, NULL, NULL, &tv);
--            if (res < 0) {
--                error("select(fh) failed: %s", strerror(errno));
--                close(fh);
--                break;
--            } else if (res =3D=3D 0) {
--#ifdef TPMD_DISCONNECT_IDLE_CLIENTS      =20
--                info("connection closed due to inactivity");
--                close(fh);
--                break;
--#else      =20
--                continue;
--#endif      =20
--            }
--            in_len =3D read(fh, in, sizeof(in));
--            if (in_len > 0) {
-+
-+            in_len =3D read(vtpm_rx_fh, in, sizeof(in));
-+        /*Magic size of minimum TPM command is 6*/
-+        //FIXME Magic size check may not be required anymore
-+            if (in_len < 6) {
-+        info("Recv incomplete command of %d bytes.", in_len);
-+        if (in_len <=3D 0) {
-+            close(vtpm_rx_fh);
-+            vtpm_rx_fh =3D -1;
-+            continue;
-+                 }
-+        } else {
-+        /*Debug Printouts*/
-                 debug("received %d bytes", in_len);
-+        debug_nostop("Recv[%d]: 0x", in_len);
-+        for (i=3D0; i< in_len; i++)
-+            debug_more("%x ", in[i]);
-+        debug_more("\n");
-+        /*Multiple Guest check*/
-+        if (guest_id =3D=3D -1) {
-+            guest_id =3D *((int32_t *) in);
-+        } else {
-+            if (guest_id !=3D *((int32_t *) in) ) {
-+            error("WARNING: More than one guest attached\n");
-+            }
-+        }
-+
-+        /*Open tx handle now*/
-+        if (vtpm_tx_fh < 0) {
-+#ifdef VTPM_MUTLI_VM
-+            vtpm_tx_fh =3D open(DEV_BE, O_RDWR);
-+            vtpm_rx_fh =3D vtpm_tx_fh;
-+#else
-+            if (vtpm_type =3D=3D VTPM_TYPE_PVM) {
-+            vtpm_tx_fh =3D open(PVM_TX_FIFO, O_WRONLY);
-+                 } // No need to open the other direction for HVM
-+#endif
-+        }
-+        if (vtpm_tx_fh < 0) {
-+          error("Failed to open devices to respond to guest.\n");
-+          exit(-1);
-+        }
-+
-+        /*Handle the TPM command now*/
-                 out =3D NULL;
--                res =3D tpm_handle_command(in, in_len, &out, &out_len);=

-+                res =3D tpm_handle_command(in + sizeof(uint32_t), in_le=
n
- sizeof(uint32_t), &out, &out_len);
-                 if (res < 0) {
-                     error("tpm_handle_command() failed");
-                 } else {
-                     debug("sending %d bytes", out_len);
-+            //FIXME this prepending may or may not be needed
-+            /*Prepend the first 4 bytes of the in buffer.. why?*/
-+            addressed_out =3D (uint8_t *) tpm_malloc(sizeof(uint32_t) +=

out_len);
-+            *(uint32_t *) addressed_out =3D *(uint32_t *) in;
-+            memcpy(addressed_out + sizeof(uint32_t), out, out_len);
-+            out_len +=3D sizeof(uint32_t);
-+            /*End Prepend*/
-+
-+            /*Perform write operation now*/
-                     while (out_len > 0) {
--                        res =3D write(fh, out, out_len);
-+                        res =3D write(vtpm_tx_fh, addressed_out, out_le=
n);
-+
-                         if (res < 0) {
-                             error("write(%d) failed: %s", out_len,
strerror(errno));
-                             break;
--                        }
-+                        } else {
-+              debug_nostop("Sent[%Zu]: ", out_len);
-+              for (i=3D0; (unsigned int)i< out_len; i++)
-+                debug_more("%x ", addressed_out[i]);
-+              debug_more("\n");
-+            }
-                         out_len    -=3D res;
-                     }
-                     tpm_free(out);
-+            tpm_free(addressed_out);
-                 }
-             }
-         } while (in_len > 0);
--        close(fh);
-+        //close(fh);
-     }
-+  =20
-     /* shutdown tpm emulator */
-     tpm_emulator_shutdown();
--    /* close socket */
--    close(sock);
--    unlink(opt_socket_name);
-+    /* Close handles */
-+    close(vtpm_tx_fh);
-+#ifndef VTPM_MULTI_VM
-+    close(vtpm_rx_fh);
-+    free(vtpm_rx_file);
-+#endif
-     info("main loop stopped");
- }
-
-@@ -450,12 +770,13 @@ int main(int argc, char **argv)
-     /* open random device */
-     init_random();
-     /* init signal handlers */
--    init_signal_handler();
-+    //init_signal_handler();
-     /* unless requested otherwiese, fork and daemonize process */
--    if (!opt_foreground) daemonize();
-+    //if (!opt_foreground) daemonize();
-     /* start main processing loop */
-     main_loop();
-     info("stopping TPM Emulator daemon");
-     closelog();
-     return 0;
- }
-+
-diff -Naurp tpm_emulator-0.5.1/tpmd/tpm_emulator_config.h
tpm5-test/tpmd/tpm_emulator_config.h
---- tpm_emulator-0.5.1/tpmd/tpm_emulator_config.h    2008-02-14
03:22:48.000000000 -0500
-+++ tpm5-test/tpmd/tpm_emulator_config.h    2009-07-16
11:25:26.000000000 -0400
-@@ -29,23 +29,28 @@
-
- /* TPM emulator configuration */
-
--#undef  TPM_STRONG_PERSISTENCE
--#undef  TPM_GENERATE_EK
-+#define  TPM_STRONG_PERSISTENCE
-+#define  TPM_GENERATE_EK
- #undef  TPM_GENERATE_SEED_DAA
- #undef  TPM_MEMORY_ALIGNMENT_MANDATORY
-
-+extern int dmi_id;
-+
- /* log macros */
-
- void tpm_log(int priority, const char *fmt, ...);
-
--#define debug(fmt, ...) tpm_log(LOG_DEBUG, "%s:%d: Debug: " fmt "\n", \=

--                                __FILE__, __LINE__, ## __VA_ARGS__)
--#define info(fmt, ...)  tpm_log(LOG_INFO, "%s:%d: Info: " fmt "\n", \
--                                __FILE__, __LINE__, ## __VA_ARGS__)
--#define error(fmt, ...) tpm_log(LOG_ERR, "%s:%d: Error: " fmt "\n", \
--                                __FILE__, __LINE__, ## __VA_ARGS__)
--#define alert(fmt, ...) tpm_log(LOG_ALERT, "%s:%d: Alert: " fmt "\n", \=

--                                __FILE__, __LINE__, ## __VA_ARGS__)
-+#define debug(fmt, ...) tpm_log(LOG_DEBUG, "VTPMD[%d]: %s:%d: Debug: "
fmt "\n", \
-+                                dmi_id, __FILE__, __LINE__, ##
__VA_ARGS__)
-+#define info(fmt, ...)  tpm_log(LOG_INFO, "VTPMD[%d]: %s:%d: Info: "
fmt "\n", \
-+                                dmi_id, __FILE__, __LINE__, ##
__VA_ARGS__)
-+#define error(fmt, ...) tpm_log(LOG_ERR, "VTPMD[%d]: %s:%d: Error: "
fmt "\n", \
-+                                dmi_id, __FILE__, __LINE__, ##
__VA_ARGS__)
-+#define alert(fmt, ...) tpm_log(LOG_ALERT, "VTPMD[%d]: %s:%d: Alert: "
fmt "\n", \
-+                                dmi_id, __FILE__, __LINE__, ##
__VA_ARGS__)
-+#define debug_nostop(fmt, ...) tpm_log(LOG_DEBUG, "VTPMD[%d]: %s:%d:
Debug: " fmt, \
-+                                dmi_id, __FILE__, __LINE__, ##
__VA_ARGS__)
-+#define debug_more(fmt, ...) tpm_log(LOG_DEBUG, fmt, ## __VA_ARGS__)
-
- /*  min/max macros that also do strict type-checking */
-
diff --git a/tools/vtpm/vtpm-0.7.4.patch b/tools/vtpm/vtpm-0.7.4.patch
--- /dev/null
+++ b/tools/vtpm/vtpm-0.7.4.patch
@@ -0,0 +1,1138 @@
+diff -Naur tpm_emulator-0.7.4-orig/CMakeLists.txt
tpm_emulator-0.7.4/CMakeLists.txt
+--- tpm_emulator-0.7.4-orig/CMakeLists.txt    2012-09-17
13:16:27.832582475 -0400
++++ tpm_emulator-0.7.4/CMakeLists.txt    2012-09-17 13:16:41.621654594
-0400
+@@ -63,6 +63,7 @@
+ # include root directories
+ include_directories(${CMAKE_SOURCE_DIR})
+ include_directories(${CMAKE_BINARY_DIR})
++include_directories(../../vtpm_manager/manager)
+
+ # add internal libraries
+ add_subdirectory(tpm)
+diff -Naur tpm_emulator-0.7.4-orig/CMakeLists.txt.orig
tpm_emulator-0.7.4/CMakeLists.txt.orig
+--- tpm_emulator-0.7.4-orig/CMakeLists.txt.orig    1969-12-31
19:00:00.000000000 -0500
++++ tpm_emulator-0.7.4/CMakeLists.txt.orig    2011-12-20
13:30:06.000000000 -0500
+@@ -0,0 +1,80 @@
++# Software-based Trusted Platform Module (TPM) Emulator
++# Copyright (C) 2004-2010 Mario Strasser <mast@gmx.net>
++#
++# $Id: CMakeLists.txt 475 2011-12-20 18:21:19Z mast $
++
++project(TPM_Emulator C)
++
++cmake_minimum_required(VERSION 2.4)
++set(CMAKE_ALLOW_LOOSE_LOOP_CONSTRUCTS true)
++if(COMMAND cmake_policy)
++cmake_policy(SET CMP0003 NEW)
++endif()
++
++# enforce out of source build
++string(COMPARE EQUAL "${CMAKE_SOURCE_DIR}" "${CMAKE_BINARY_DIR}"
IS_INSOURCE)
++if(IS_INSOURCE)
++    message(FATAL_ERROR "${PROJECT_NAME} requires an out of source
build.")
++endif()
++
++# set project and build version
++set(${PROJECT_NAME}_VERSION_MAJOR 0)
++set(${PROJECT_NAME}_VERSION_MINOR 7)
++string(REGEX REPLACE ".*Revision: ([0-9]+).*" "\\1"
${PROJECT_NAME}_VERSION_BUILD "$Revision: 475 $")
++
++# create project configuration
++if(WIN32)
++STRING(REGEX REPLACE "\\\\" "/" PROGRAMFILES
"$ENV{PROGRAMFILES}/${PROJECT_NAME}")
++set(TPM_LOG_FILE "${PROGRAMFILES}/tpmd.log")
++set(TPM_STORAGE_NAME
"${PROGRAMFILES}/tpm_emulator-1_2_${${PROJECT_NAME}_VERSION_MAJOR}_${${PR=
OJECT_NAME}_VERSION_MINOR}")
++set(TPM_DEVICE_NAME "//./pipe/tpmd:0")
++elseif(APPLE)
++set(TPM_LOG_FILE "/private/var/log/tpmd.log")
++set(TPM_SOCKET_NAME "/private/var/run/tpm/tpmd_socket:0")
++set(TPM_STORAGE_NAME
"/private/var/lib/tpm/tpm_emulator-1_2_${${PROJECT_NAME}_VERSION_MAJOR}_$=
{${PROJECT_NAME}_VERSION_MINOR}")
++set(TPM_DEVICE_NAME "/dev/tpm")
++else()
++set(TPM_LOG_FILE "/var/log/tpmd.log")
++set(TPM_SOCKET_NAME "/var/run/tpm/tpmd_socket:0")
++set(TPM_STORAGE_NAME
"/var/lib/tpm/tpm_emulator-1_2_${${PROJECT_NAME}_VERSION_MAJOR}_${${PROJE=
CT_NAME}_VERSION_MINOR}")
++set(TPM_DEVICE_NAME "/dev/tpm")
++endif()
++configure_file(${CMAKE_CURRENT_SOURCE_DIR}/config.h.in
${CMAKE_CURRENT_BINARY_DIR}/config.h)
++add_definitions(-Wall -Werror -Wno-unused-parameter -Wpointer-arith
-Wcast-align -Wwrite-strings)
++if("${CMAKE_SYSTEM}" MATCHES "Linux")
++    add_definitions(-Wextra)
++endif()
++if(USE_OPENSSL)
++    add_definitions(-DUSE_OPENSSL)
++endif()
++include_directories("/opt/local/include")
++link_directories("/opt/local/lib")
++
++# configure CPack
++set(CPACK_PACKAGE_VERSION_MAJOR ${${PROJECT_NAME}_VERSION_MAJOR})
++set(CPACK_PACKAGE_VERSION_MINOR ${${PROJECT_NAME}_VERSION_MINOR})
++set(CPACK_SOURCE_PACKAGE_FILE_NAME
"tpm_emulator-${CPACK_PACKAGE_VERSION_MAJOR}.${CPACK_PACKAGE_VERSION_MINO=
R}.4")
++set(CPACK_SOURCE_GENERATOR "TGZ")
++set(CPACK_SOURCE_IGNORE_FILES ".svn/" "/build/" "/.project" "/.cproject=
")
++set(CPACK_GENERATOR "ZIP")
++set(CPACK_SET_DESTDIR ON)
++include(CPack)
++
++# include root directories
++include_directories(${CMAKE_SOURCE_DIR})
++include_directories(${CMAKE_BINARY_DIR})
++
++# add internal libraries
++add_subdirectory(tpm)
++add_subdirectory(mtm)
++add_subdirectory(crypto)
++
++# add TDDL
++add_subdirectory(tddl)
++
++# add kernel modules
++add_subdirectory(tpmd_dev)
++
++# add executables
++add_subdirectory(tpmd)
++
+diff -Naur tpm_emulator-0.7.4-orig/tpm/tpm_emulator_extern.h
tpm_emulator-0.7.4/tpm/tpm_emulator_extern.h
+--- tpm_emulator-0.7.4-orig/tpm/tpm_emulator_extern.h    2012-09-17
13:16:27.834582486 -0400
++++ tpm_emulator-0.7.4/tpm/tpm_emulator_extern.h    2012-09-17
13:16:41.621654594 -0400
+@@ -29,6 +29,8 @@
+   TPM_LOG_ERROR
+ };
+
++extern int dmi_id;
++
+ void (*tpm_log)(int priority, const char *fmt, ...);
+
+ #if defined(_WIN32) || defined(_WIN64)
+@@ -37,12 +39,16 @@
+ #define __BFILE__ ((strrchr(__FILE__, '/') ? : __FILE__ - 1) + 1)
+ #endif
+
+-#define debug(fmt, ...) tpm_log(TPM_LOG_DEBUG, "%s:%d: Debug: " fmt
"\n", \
+-                                __BFILE__, __LINE__, ## __VA_ARGS__)
+-#define info(fmt, ...)  tpm_log(TPM_LOG_INFO, "%s:%d: Info: " fmt "\n",=
 \
+-                                __BFILE__, __LINE__, ## __VA_ARGS__)
+-#define error(fmt, ...) tpm_log(TPM_LOG_ERROR, "%s:%d: Error: " fmt
"\n", \
+-                                __BFILE__, __LINE__, ## __VA_ARGS__)
++#define debug(fmt, ...) tpm_log(TPM_LOG_DEBUG, "VTPMD[%d]: %s:%d:
Debug: " fmt "\n", \
++                                dmi_id, __BFILE__, __LINE__, ##
__VA_ARGS__)
++#define info(fmt, ...)  tpm_log(TPM_LOG_INFO, "VTPMD[%d]: %s:%d: Info:
" fmt "\n", \
++                                dmi_id, __BFILE__, __LINE__, ##
__VA_ARGS__)
++#define error(fmt, ...) tpm_log(TPM_LOG_ERROR, "VTPMD[%d]: %s:%d:
Error: " fmt "\n", \
++                                dmi_id, __BFILE__, __LINE__, ##
__VA_ARGS__)
++#define debug_nostop(fmt, ...) tpm_log(TPM_LOG_DEBUG, "VTPMD[%d]:
%s:%d: Debug: " fmt, \
++                                dmi_id, __BFILE__, __LINE__, ##
__VA_ARGS__)
++#define debug_more(fmt, ...) tpm_log(TPM_LOG_DEBUG, fmt, ## __VA_ARGS__=
)
++
+ /* initialization */
+ int (*tpm_extern_init)(void);
+ void (*tpm_extern_release)(void);
+diff -Naur tpm_emulator-0.7.4-orig/tpmd/unix/tpmd.c
tpm_emulator-0.7.4/tpmd/unix/tpmd.c
+--- tpm_emulator-0.7.4-orig/tpmd/unix/tpmd.c    2012-09-17
13:16:27.839582511 -0400
++++ tpm_emulator-0.7.4/tpmd/unix/tpmd.c    2012-09-17
13:16:41.623654604 -0400
+@@ -30,9 +30,31 @@
+ #include <grp.h>
+ #include "config.h"
+ #include "tpm/tpm_emulator.h"
++#include "tpm/tpm_structures.h"
++#include "tpm/tpm_marshalling.h"
++#include "vtpm_manager.h"
+
+ #define TPM_COMMAND_TIMEOUT 30
+
++#define TPM_DAEMON_NAME     "tpmd"
++#define TPM_CMD_BUF_SIZE    4096
++#define TPM_RANDOM_DEVICE   "/dev/urandom"
++#undef  TPM_MKDIRS
++
++#define PVM_RX_FIFO_D "/var/vtpm/fifos/tpm_cmd_to_%d.fifo"
++#define PVM_TX_FIFO "/var/vtpm/fifos/tpm_rsp_from_all.fifo"
++#define HVM_RX_FIFO_D "/var/vtpm/socks/%d.socket"
++
++#define VTPM_RX_FIFO_D "/var/vtpm/fifos/vtpm_rsp_to_%d.fifo"
++#define VTPM_TX_FIFO "/var/vtpm/fifos/vtpm_cmd_from_all.fifo"
++
++static char *vtpm_rx_name=3DNULL;
++
++static int vtpm_tx_fh=3D-1, vtpm_rx_fh=3D-1;
++
++#define BUFFER_SIZE 2048
++
++
+ static volatile int stopflag =3D 0;
+ static int is_daemon =3D 0;
+ static int opt_debug =3D 0;
+@@ -44,6 +66,9 @@
+ static uint32_t tpm_config =3D 0;
+ extern const char *tpm_storage_file;
+
++static int vtpm_type =3D VTPM_TYPE_PVM;
++int dmi_id;
++
+ void my_log(int priority, const char *fmt, ...)
+ {
+     va_list ap, bp;
+@@ -156,35 +181,218 @@
+             exit(EXIT_SUCCESS);
+         }
+     } else {
+-        /* if no startup mode is given assume save if a configuration
+-           file is available, clear otherwise */
+-        int fh =3D open(tpm_storage_file, O_RDONLY);
+-        if (fh < 0) {
+-            tpm_startup =3D 1;
+-            info("no startup mode was specified; asuming 'clear'");
+-        } else {
+-            tpm_startup =3D 2;
+-            close(fh);
+-        }
++       tpm_startup =3D 1;
++       info("no startup mode was specified; asuming 'clear'");
+     }
++    /* GET VM TYPE */
++    ++optind;
++    if (optind < argc) {
++       if(!strcmp(argv[optind], "pvm")) {
++      vtpm_type =3D VTPM_TYPE_PVM;      // Get commands from vTPM
Manager through fifo
++       } else if (!strcmp(argv[optind], "hvm")) {
++      vtpm_type =3D VTPM_TYPE_HVM;      // Get commands from qemu via s=
ocket
++       } else {
++      error("Invalid vm mode '%s'; must be 'pvm', "
++        "or 'hvm' ", argv[optind]);
++      print_usage(argv[0]);
++      exit(EXIT_SUCCESS);
++       }
++    } else {
++       vtpm_type =3D VTPM_TYPE_PVM;
++       info("no vm mode specified; assuming 'pvm'");
++    }
++    /* GET DMI ID */
++    ++optind;
++    if(optind >=3D argc || sscanf(argv[optind], "%d", &dmi_id) !=3D 1) =
{
++       error("Missing or non-integer dmi_id specified!");
++       print_usage(argv[0]);
++       exit(EXIT_SUCCESS);
++    }
++}
++
++int vtpm_write_to_file(uint8_t *data, size_t data_length)
++{
++  int res, out_data_size, in_header_size;
++  BYTE *ptr, *out_data, *in_header;
++  UINT32 result, len, in_rsp_size;
++  UINT16 tag =3D VTPM_TAG_REQ;
++
++  printf("Saving NVM\n");
++  if (vtpm_tx_fh < 0) {
++     vtpm_tx_fh =3D open(VTPM_TX_FIFO, O_WRONLY);
++  }
++
++  if (vtpm_tx_fh < 0) {
++                return -1;
++  }
++
++  // Send request to VTPM Manager to encrypt data
++  out_data_size =3D len =3D VTPM_COMMAND_HEADER_SIZE_SRV + data_length;=

++
++  out_data =3D ptr =3D (BYTE *) malloc(len);
++
++  if (ptr =3D=3D NULL
++    || tpm_marshal_UINT32(&ptr, &len, dmi_id)
++    || tpm_marshal_UINT16(&ptr, &len, tag)
++    || tpm_marshal_UINT32(&ptr, &len, out_data_size - sizeof(uint32_t))=

++    || tpm_marshal_UINT32(&ptr, &len, VTPM_ORD_SAVENVM)
++    || tpm_marshal_BYTE_ARRAY(&ptr, &len, data, data_length)) {
++     free(out_data);
++     return -1;
++  }
++
++  printf("\tSending SaveNVM Command.\n");
++  res =3D write(vtpm_tx_fh, out_data, out_data_size);
++  free(out_data);
++  if (res !=3D out_data_size) return -1;
++
++  if (vtpm_rx_fh < 0) {
++    if (vtpm_rx_name =3D=3D NULL) {
++      vtpm_rx_name =3D malloc(10 + strlen(VTPM_RX_FIFO_D));
++      sprintf(vtpm_rx_name, VTPM_RX_FIFO_D, (uint32_t) dmi_id);
++    }
++        vtpm_rx_fh =3D open(vtpm_rx_name, O_RDONLY);
++  }
++
++  if (vtpm_rx_fh < 0) {
++                return -1;
++  }
++
++  // Read Header of response so we can get the size & status
++  in_header_size =3D len =3D VTPM_COMMAND_HEADER_SIZE_SRV;
++  in_header =3D ptr =3D malloc(in_header_size);
++
++  printf("\tReading SaveNVM header.\n");
++  res =3D read(vtpm_rx_fh, in_header, in_header_size);
++
++  if ( (res !=3D in_header_size)
++    || tpm_unmarshal_UINT32(&ptr, &len, (UINT32*)&dmi_id)
++    || tpm_unmarshal_UINT16(&ptr, &len, &tag)
++    || tpm_unmarshal_UINT32(&ptr, &len, &in_rsp_size)
++    || tpm_unmarshal_UINT32(&ptr, &len, &result) ) {
++     free(in_header);
++     return -1;
++  }
++  free(in_header);
++
++  if (result !=3D VTPM_SUCCESS) {
++      return -1;
++  }
++
++  printf("\tFinishing up SaveNVM\n");
++  return (0);
++}
++
++int vtpm_read_from_file(uint8_t **data, size_t *data_length)
++{
++   int res, out_data_size, in_header_size;
++   uint8_t *ptr, *out_data, *in_header;
++   UINT16 tag =3D VTPM_TAG_REQ;
++   UINT32 len, in_rsp_size, result;
++
++   printf("Loading NVM.\n");
++   if (vtpm_tx_fh < 0) {
++      vtpm_tx_fh =3D open(VTPM_TX_FIFO, O_WRONLY);
++   }
++
++   if (vtpm_tx_fh < 0) {
++      printf("Error in read_from_file:301\n");
++      return -1;
++   }
++
++   // Send request to VTPM Manager to encrypt data
++   out_data_size =3D len =3D VTPM_COMMAND_HEADER_SIZE_SRV;
++   out_data =3D ptr =3D (BYTE *) malloc(len);
++
++   if (ptr =3D=3D NULL
++     || tpm_marshal_UINT32(&ptr, &len, dmi_id)
++     || tpm_marshal_UINT16(&ptr, &len, tag)
++     || tpm_marshal_UINT32(&ptr, &len, out_data_size - sizeof(uint32_t)=
)
++     || tpm_marshal_UINT32(&ptr, &len, VTPM_ORD_LOADNVM)) {
++      free(out_data);
++      printf("Error in read_from_file:325\n");
++
++      return -1;
++   }
++
++   printf("\tSending LoadNVM command\n");
++   res =3D write(vtpm_tx_fh, out_data, out_data_size);
++   free(out_data);
++   if (res !=3D out_data_size)
++   {
++      printf("Error in read_from_file:335\n");
++      return -1;
++   }
++
++   if (vtpm_rx_fh < 0) {
++      if (vtpm_rx_name =3D=3D NULL) {
++     vtpm_rx_name =3D malloc(10 + strlen(VTPM_RX_FIFO_D));
++     sprintf(vtpm_rx_name, VTPM_RX_FIFO_D, (uint32_t) dmi_id);
++      }
++      vtpm_rx_fh =3D open(vtpm_rx_name, O_RDONLY);
++   }
++
++   if (vtpm_rx_fh < 0) {
++      printf("Error in read_from_file:352\n");
++      return -1;
++   }
++
++   // Read Header of response so we can get the size & status
++   in_header_size =3D len =3D VTPM_COMMAND_HEADER_SIZE_SRV;
++   in_header =3D ptr =3D malloc(in_header_size);
++
++   printf("\tReading LoadNVM header\n");
++   res =3D read(vtpm_rx_fh, in_header, in_header_size);
++
++   if ( (res !=3D in_header_size)
++     || tpm_unmarshal_UINT32(&ptr, &len, (UINT32*)&dmi_id)
++     || tpm_unmarshal_UINT16(&ptr, &len, &tag)
++     || tpm_unmarshal_UINT32(&ptr, &len, &in_rsp_size)
++     || tpm_unmarshal_UINT32(&ptr, &len, &result) ) {
++      free(in_header);
++      printf("Error in read_from_file:375\n");
++      return -1;
++   }
++   free(in_header);
++
++   if (result !=3D VTPM_SUCCESS) {
++      printf("Error in read_from_file:381\n");
++      return -1;
++   }
++
++   // Read Encrypted data from VTPM Manager
++   *data_length =3D in_rsp_size - VTPM_COMMAND_HEADER_SIZE_CLT;
++   *data =3D (uint8_t *) malloc(*data_length);
++
++   printf("\tReading clear data from LoadNVM.\n");
++   res =3D read(vtpm_rx_fh, *data, *data_length);
++
++   printf("\tReturing from loading NVM\n");
++   if (res !=3D (int)*data_length) {
++      free(*data);
++      printf("Error in read_from_file:398\n");
++      return -1;
++   } else {
++      return 0;
++   }
+ }
+
+ static void switch_uid_gid(void)
+ {
+-    if (opt_gid !=3D getgid()) {
+-        info("switching effective group ID to %d", opt_gid);=20
+-        if (setgid(opt_gid) =3D=3D -1) {
+-            error("switching effective group ID to %d failed: %s",
opt_gid, strerror(errno));
+-            exit(EXIT_FAILURE);
+-        }
+-    }
+-    if (opt_uid !=3D getuid()) {
+-        info("switching effective user ID to %d", opt_uid);
+-        if (setuid(opt_uid) =3D=3D -1) {
+-            error("switching effective user ID to %d failed: %s",
opt_uid, strerror(errno));
+-            exit(EXIT_FAILURE);
+-        }
+-    }
++   if (opt_gid !=3D getgid()) {
++      info("switching effective group ID to %d", opt_gid);=20
++      if (setgid(opt_gid) =3D=3D -1) {
++     error("switching effective group ID to %d failed: %s", opt_gid,
strerror(errno));
++     exit(EXIT_FAILURE);
++      }
++   }
++   if (opt_uid !=3D getuid()) {
++      info("switching effective user ID to %d", opt_uid);
++      if (setuid(opt_uid) =3D=3D -1) {
++     error("switching effective user ID to %d failed: %s", opt_uid,
strerror(errno));
++     exit(EXIT_FAILURE);
++      }
++   }
+ }
+
+ static void signal_handler(int sig)
+@@ -214,174 +422,175 @@
+     }
+ }
+
+-static void daemonize(void)
+-{
+-    pid_t sid, pid;
+-    info("daemonizing process");
+-    pid =3D fork();
+-    if (pid < 0) {
+-        error("fork() failed: %s", strerror(errno));
+-        exit(EXIT_FAILURE);
+-    }
+-    if (pid > 0) exit(EXIT_SUCCESS);
+-    pid =3D getpid();
+-    sid =3D setsid();
+-    if (sid < 0) {
+-        error("setsid() failed: %s", strerror(errno));
+-        exit(EXIT_FAILURE);
+-    }
+-    if (chdir("/") < 0) {
+-        error("chdir() failed: %s", strerror(errno));
+-        exit(EXIT_FAILURE);
+-    }
+-    close(STDIN_FILENO);
+-    close(STDOUT_FILENO);
+-    close(STDERR_FILENO);
+-    is_daemon =3D 1;
+-    info("process was successfully daemonized: pid=3D%d sid=3D%d", pid,=
 sid);
+-}
+-
+-static int mkdirs(const char *path)
+-{
+-    char *copy =3D strdup(path);
+-    char *p =3D strchr(copy + 1, '/');
+-    while (p !=3D NULL) {
+-        *p =3D '\0';
+-        if ((mkdir(copy, 0755) =3D=3D -1) && (errno !=3D EEXIST)) {
+-            free(copy);
+-            return errno;
+-        }
+-        *p =3D '/';
+-        p =3D strchr(p + 1, '/');
+-    }
+-    free(copy);
+-    return 0;
+-}
+-
+-static int init_socket(const char *name)
+-{
+-    int sock;
+-    struct sockaddr_un addr;
+-    info("initializing socket %s", name);
+-    sock =3D socket(AF_UNIX, SOCK_STREAM, 0);
+-    if (sock < 0) {
+-        error("socket(AF_UNIX) failed: %s", strerror(errno));
+-        return -1;
+-    }
+-    mkdirs(name);
+-    addr.sun_family =3D AF_UNIX;
+-    strncpy(addr.sun_path, name, sizeof(addr.sun_path));
+-    umask(0177);
+-    if (bind(sock, (struct sockaddr*)&addr, sizeof(addr)) < 0) {
+-        error("bind(%s) failed: %s", addr.sun_path, strerror(errno));
+-        close(sock);
+-        return -1;
+-    }
+-    listen(sock, 1);
+-    return sock;
+-}
+-
+ static void main_loop(void)
+ {
+-    int sock, fh, res;
+     int32_t in_len;
+     uint32_t out_len;
+-    uint8_t in[TPM_CMD_BUF_SIZE], *out;
++    uint8_t in[TPM_CMD_BUF_SIZE], *out, *addressed_out;
++    int guest_id=3D-1;
++    int i;
++    char *vtpm_rx_file=3DNULL;
++    int res;
++
++    int sockfd =3D -1;
+     struct sockaddr_un addr;
+-    socklen_t addr_len;
+-    fd_set rfds;
+-    struct timeval tv;
++    struct sockaddr_un client_addr;
++    unsigned int client_length;
++
++    int vtpm_tx_fh=3D-1, vtpm_rx_fh=3D-1;
++
++  if (vtpm_type =3D=3D VTPM_TYPE_PVM) {
++    vtpm_rx_file =3D malloc(10 + strlen(PVM_RX_FIFO_D));
++    sprintf(vtpm_rx_file, PVM_RX_FIFO_D, (uint32_t) dmi_id);
++  } else {
++    vtpm_rx_file =3D malloc(10 + strlen(HVM_RX_FIFO_D));
++    sprintf(vtpm_rx_file, HVM_RX_FIFO_D, (uint32_t) dmi_id);
++
++    if ( (sockfd =3D socket(PF_UNIX,SOCK_STREAM,0)) < 0) {
++          error("Unable to create socket. errno =3D %d\n", errno);
++      exit (-1);
++    }
++
++    memset(&addr, 0, sizeof(addr));
++    addr.sun_family =3D AF_UNIX;
++    strcpy(addr.sun_path,vtpm_rx_file );
++    unlink(addr.sun_path);
++  }
+
+     info("staring main loop");
+-    /* open UNIX socket */
+-    sock =3D init_socket(opt_socket_name);
+-    if (sock < 0) exit(EXIT_FAILURE);
+     /* init tpm emulator */
+-    debug("initializing TPM emulator");
+-    if (tpm_emulator_init(tpm_startup, tpm_config) !=3D 0) {
+-        error("tpm_emulator_init() failed");
+-        close(sock);
+-        unlink(opt_socket_name);
+-        exit(EXIT_FAILURE);
+-    }
++    debug("initializing TPM emulator: state=3D%d, type=3D%d, id=3D%d",
tpm_startup, vtpm_type, dmi_id);
++    /* Set config flags that must be on for vtpm operation */
++    tpm_config |=3D TPM_CONF_STRONG_PERSISTENCE;
++    tpm_config &=3D ~TPM_CONF_USE_INTERNAL_PRNG;
++    tpm_config |=3D TPM_CONF_GENERATE_EK;
++    tpm_config |=3D TPM_CONF_GENERATE_SEED_DAA;
++    /*Start the emulator */
++    tpm_emulator_init(tpm_startup, tpm_config);
+     /* start command processing */
+     while (!stopflag) {
+         /* wait for incomming connections */
+         debug("waiting for connections...");
+-        FD_ZERO(&rfds);
+-        FD_SET(sock, &rfds);
+-        tv.tv_sec =3D 10;
+-        tv.tv_usec =3D 0;
+-        res =3D select(sock + 1, &rfds, NULL, NULL, &tv);
+-        if (res < 0) {
+-            error("select(sock) failed: %s", strerror(errno));
+-            break;
+-        } else if (res =3D=3D 0) {
+-            continue;
++        if (vtpm_rx_fh < 0) {
++            if (vtpm_type =3D=3D VTPM_TYPE_PVM)
++            {
++                vtpm_rx_fh =3D open(vtpm_rx_file, O_RDONLY);
++            } else {
++                if (bind(sockfd, (struct sockaddr *)&addr,
sizeof(addr)) < 0) {
++                    error("Unable to bind(). errno =3D %d\n", errno);
++                    exit (-1);
++                }
++
++                if (listen(sockfd, 10) <0) {
++                    error("Unable to listen(). errno =3D %d\n", errno);=

++                    exit (-1);
++                }
++
++                 memset(&client_addr, 0, sizeof(client_addr));
++                 client_length =3D sizeof(client_addr);
++
++                 vtpm_rx_fh =3D vtpm_tx_fh =3D accept(sockfd, (struct
sockaddr *)&client_addr, &client_length);
++            }
+         }
+-        addr_len =3D sizeof(addr);
+-        fh =3D accept(sock, (struct sockaddr*)&addr, &addr_len);
+-        if (fh < 0) {
+-            error("accept() failed: %s", strerror(errno));
+-            continue;
++
++        /*Error Checking*/
++        if (vtpm_rx_fh < 0) {
++          error("Failed to open devices to listen to guest.\n");
++          exit(-1);
+         }
++
+         /* receive and handle commands */
+         in_len =3D 0;
+         do {
+             debug("waiting for commands...");
+-            FD_ZERO(&rfds);
+-            FD_SET(fh, &rfds);
+-            tv.tv_sec =3D TPM_COMMAND_TIMEOUT;
+-            tv.tv_usec =3D 0;
+-            res =3D select(fh + 1, &rfds, NULL, NULL, &tv);
+-            if (res < 0) {
+-                error("select(fh) failed: %s", strerror(errno));
+-                close(fh);
+-                break;
+-            } else if (res =3D=3D 0) {
+-#ifdef TPMD_DISCONNECT_IDLE_CLIENTS      =20
+-                info("connection closed due to inactivity");
+-                close(fh);
+-                break;
+-#else      =20
+-                continue;
+-#endif      =20
+-            }
+-            in_len =3D read(fh, in, sizeof(in));
+-            if (in_len > 0) {
++
++            in_len =3D read(vtpm_rx_fh, in, sizeof(in));
++            /*Magic size of minimum TPM command is 6*/
++            if (in_len < 6) {
++                info("Recv incomplete command of %d bytes.", in_len);
++                if (in_len <=3D 0) {
++                    close(vtpm_rx_fh);
++                    vtpm_rx_fh =3D -1;
++                    continue;
++                 }
++            } else {
++                /*Debug Printouts*/
+                 debug("received %d bytes", in_len);
++                debug_nostop("Recv[%d]: 0x", in_len);
++                for (i=3D0; i< in_len; i++)
++                    debug_more("%02x ", in[i]);
++                debug_more("\n");
++                /*Multiple Guest check*/
++                if (guest_id =3D=3D -1) {
++                    guest_id =3D *((int32_t *) in);
++                } else {
++                    if (guest_id !=3D *((int32_t *) in) ) {
++                        error("WARNING: More than one guest attached\n"=
);
++                    }
++                }
++
++                /*Open tx handle now*/
++                if (vtpm_tx_fh < 0) {
++                    if (vtpm_type =3D=3D VTPM_TYPE_PVM) {
++                        vtpm_tx_fh =3D open(PVM_TX_FIFO, O_WRONLY);
++                    } // No need to open the other direction for HVM
++                }
++                if (vtpm_tx_fh < 0) {
++                  error("Failed to open devices to respond to guest.\n"=
);
++                  exit(-1);
++                }
++
++                /*Handle the TPM command now*/
+                 out =3D NULL;
+-                res =3D tpm_handle_command(in, in_len, &out, &out_len);=

++                res =3D tpm_handle_command(in + sizeof(uint32_t), in_le=
n
- sizeof(uint32_t), &out, &out_len);
+                 if (res < 0) {
+                     error("tpm_handle_command() failed");
+                 } else {
+                     debug("sending %d bytes", out_len);
+-                    uint32_t len =3D 0;
+-                    while (len < out_len) {
+-                        res =3D write(fh, &out[len], out_len - len);
++            //Prepend the dmi_id
++                    addressed_out =3D (uint8_t *)
tpm_malloc(sizeof(uint32_t) + out_len);
++                    *(uint32_t *) addressed_out =3D *(uint32_t *) in;
++                    memcpy(addressed_out + sizeof(uint32_t), out,
out_len);
++                    out_len +=3D sizeof(uint32_t);
++                    /*End Prepend*/
++
++                    /*Perform write operation now*/
++                    while (out_len > 0) {
++                        res =3D write(vtpm_tx_fh, addressed_out, out_le=
n);
++
+                         if (res < 0) {
+-                            error("write(%d) failed: %s",
+-                                  out_len - len, strerror(errno));
++                            error("write(%d) failed: %s", out_len,
strerror(errno));
+                             break;
++                        } else {
++                          debug_nostop("Sent[%Zu]: ", out_len);
++                          for (i=3D0; (unsigned int)i< out_len; i++)
++                            debug_more("%02x ", addressed_out[i]);
++                          debug_more("\n");
+                         }
+-                        len +=3D res;
++                        out_len -=3D res;
+                     }
+                     tpm_free(out);
++                    tpm_free(addressed_out);
+                 }
+             }
+         } while (in_len > 0);
+-        close(fh);
+     }
++
+     /* shutdown tpm emulator */
+     tpm_emulator_shutdown();
+-    /* close socket */
+-    close(sock);
+-    unlink(opt_socket_name);
++    /* Close handles */
++    close(vtpm_tx_fh);
++    close(vtpm_rx_fh);
++    free(vtpm_rx_file);
+     info("main loop stopped");
+ }
+
+ int main(int argc, char **argv)
+ {
++    //Set load/store functions
++    tpm_write_to_storage =3D vtpm_write_to_file;
++    tpm_read_from_storage =3D vtpm_read_from_file;
++
+     openlog(argv[0], 0, LOG_DAEMON);
+     setlogmask(~LOG_MASK(LOG_DEBUG));
+     syslog(LOG_INFO, "--- separator ---\n");
+@@ -393,8 +602,6 @@
+     switch_uid_gid();
+     /* init signal handlers */
+     init_signal_handler();
+-    /* unless requested otherwiese, fork and daemonize process */
+-    if (!opt_foreground) daemonize();
+     /* start main processing loop */
+     main_loop();
+     info("stopping TPM Emulator daemon");
+diff -Naur tpm_emulator-0.7.4-orig/tpmd/unix/tpmd.c.orig
tpm_emulator-0.7.4/tpmd/unix/tpmd.c.orig
+--- tpm_emulator-0.7.4-orig/tpmd/unix/tpmd.c.orig    1969-12-31
19:00:00.000000000 -0500
++++ tpm_emulator-0.7.4/tpmd/unix/tpmd.c.orig    2011-12-20
13:30:06.000000000 -0500
+@@ -0,0 +1,403 @@
++/* Software-based Trusted Platform Module (TPM) Emulator
++ * Copyright (C) 2004-2010 Mario Strasser <mast@gmx.net>
++ *
++ * 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.
++ *
++ * $Id: tpmd.c 463 2011-06-08 14:25:04Z mast $
++ */
++
++#include <stdio.h>
++#include <stdlib.h>
++#include <unistd.h>
++#include <signal.h>
++#include <string.h>
++#include <errno.h>
++#include <syslog.h>
++#include <stdarg.h>
++#include <fcntl.h>
++#include <sys/stat.h>
++#include <sys/socket.h>
++#include <sys/un.h>
++#include <pwd.h>
++#include <grp.h>
++#include "config.h"
++#include "tpm/tpm_emulator.h"
++
++#define TPM_COMMAND_TIMEOUT 30
++
++static volatile int stopflag =3D 0;
++static int is_daemon =3D 0;
++static int opt_debug =3D 0;
++static int opt_foreground =3D 0;
++static const char *opt_socket_name =3D TPM_SOCKET_NAME;
++static uid_t opt_uid =3D 0;
++static gid_t opt_gid =3D 0;
++static int tpm_startup =3D 2;
++static uint32_t tpm_config =3D 0;
++extern const char *tpm_storage_file;
++
++void my_log(int priority, const char *fmt, ...)
++{
++    va_list ap, bp;
++    va_start(ap, fmt);
++    va_copy(bp, ap);
++    switch (priority) {
++      case TPM_LOG_DEBUG:
++        vsyslog(LOG_DEBUG, fmt, ap);
++        break;
++      case TPM_LOG_ERROR:
++        vsyslog(LOG_ERR, fmt, ap);
++        break;
++      case TPM_LOG_INFO:
++      default:
++        vsyslog(LOG_INFO, fmt, ap);
++        break;
++    }
++    va_end(ap);
++    if (!is_daemon && (priority !=3D TPM_LOG_DEBUG || opt_debug)) {
++        vprintf(fmt, bp);
++    }
++    va_end(bp);
++}
++
++static void print_usage(char *name)
++{
++    printf("usage: %s [-d] [-f] [-s storage file] [-u unix socket name]=
 "
++           "[-o user name] [-g group name] [-h] [startup mode]\n", name=
);
++    printf("  d : enable debug mode\n");
++    printf("  f : forces the application to run in the foreground\n");
++    printf("  s : storage file to use (default: %s)\n", tpm_storage_fil=
e);
++    printf("  u : unix socket name to use (default: %s)\n",
opt_socket_name);
++    printf("  o : effective user the application should run as\n");
++    printf("  g : effective group the application should run as\n");
++    printf("  h : print this help message\n");
++    printf("  startup mode : must be 'clear', "
++           "'save' (default) or 'deactivated\n");
++}
++
++static void parse_options(int argc, char **argv)
++{
++    char c;
++    struct passwd *pwd;
++    struct group *grp;
++    opt_uid =3D getuid();
++    opt_gid =3D getgid();
++    info("parsing options");
++    while ((c =3D getopt (argc, argv, "dfs:u:o:g:c:h")) !=3D -1) {
++        debug("handling option '-%c'", c);
++        switch (c) {
++            case 'd':
++                opt_debug =3D 1;
++                setlogmask(setlogmask(0) | LOG_MASK(LOG_DEBUG));
++                debug("debug mode enabled");
++                break;
++            case 'f':
++                debug("application is forced to run in foreground");
++                opt_foreground =3D 1;
++                break;
++            case 's':
++                tpm_storage_file =3D optarg;
++                debug("using storage file '%s'", tpm_storage_file);
++                break;
++            case 'u':
++                opt_socket_name =3D optarg;
++                debug("using unix socket '%s'", opt_socket_name);
++                break;
++            case 'o':
++                pwd  =3D getpwnam(optarg);
++                if (pwd =3D=3D NULL) {
++                    error("invalid user name '%s'\n", optarg);
++                    exit(EXIT_FAILURE);
++                }
++                opt_uid =3D pwd->pw_uid;
++                break;
++            case 'g':
++                grp  =3D getgrnam(optarg);
++                if (grp =3D=3D NULL) {
++                    error("invalid group name '%s'\n", optarg);
++                    exit(EXIT_FAILURE);
++                }
++                opt_gid =3D grp->gr_gid;
++                break;
++            case 'c':
++                tpm_config =3D strtol(optarg, NULL, 0);
++                debug("tpm_config =3D %04x", tpm_config);
++                break;
++            case '?':
++                error("unknown option '-%c'", optopt);
++                print_usage(argv[0]);
++                exit(EXIT_FAILURE);
++            case 'h':
++            default:
++                print_usage(argv[0]);
++                exit(EXIT_SUCCESS);
++        }
++    }
++    if (optind < argc) {
++        debug("startup mode =3D '%s'", argv[optind]);
++        if (!strcmp(argv[optind], "clear")) {
++            tpm_startup =3D 1;
++        } else if (!strcmp(argv[optind], "save")) {
++            tpm_startup =3D 2;
++        } else if (!strcmp(argv[optind], "deactivated")) {
++            tpm_startup =3D 3;
++        } else {
++            error("invalid startup mode '%s'; must be 'clear', "
++                  "'save' (default) or 'deactivated", argv[optind]);
++            print_usage(argv[0]);
++            exit(EXIT_SUCCESS);
++        }
++    } else {
++        /* if no startup mode is given assume save if a configuration
++           file is available, clear otherwise */
++        int fh =3D open(tpm_storage_file, O_RDONLY);
++        if (fh < 0) {
++            tpm_startup =3D 1;
++            info("no startup mode was specified; asuming 'clear'");
++        } else {
++            tpm_startup =3D 2;
++            close(fh);
++        }
++    }
++}
++
++static void switch_uid_gid(void)
++{
++    if (opt_gid !=3D getgid()) {
++        info("switching effective group ID to %d", opt_gid);=20
++        if (setgid(opt_gid) =3D=3D -1) {
++            error("switching effective group ID to %d failed: %s",
opt_gid, strerror(errno));
++            exit(EXIT_FAILURE);
++        }
++    }
++    if (opt_uid !=3D getuid()) {
++        info("switching effective user ID to %d", opt_uid);
++        if (setuid(opt_uid) =3D=3D -1) {
++            error("switching effective user ID to %d failed: %s",
opt_uid, strerror(errno));
++            exit(EXIT_FAILURE);
++        }
++    }
++}
++
++static void signal_handler(int sig)
++{
++    info("signal received: %d", sig);
++    if (sig =3D=3D SIGTERM || sig =3D=3D SIGQUIT || sig =3D=3D SIGINT) =
stopflag =3D 1;
++}
++
++static void init_signal_handler(void)
++{
++    info("installing signal handlers");
++    if (signal(SIGTERM, signal_handler) =3D=3D SIG_ERR) {
++        error("signal(SIGTERM) failed: %s", strerror(errno));
++        exit(EXIT_FAILURE);
++    }
++    if (signal(SIGQUIT, signal_handler) =3D=3D SIG_ERR) {
++        error("signal(SIGQUIT) failed: %s", strerror(errno));
++        exit(EXIT_FAILURE);
++    }
++    if (signal(SIGINT, signal_handler) =3D=3D SIG_ERR) {
++        error("signal(SIGINT) failed: %s", strerror(errno));
++        exit(EXIT_FAILURE);
++    }
++    if (signal(SIGPIPE, signal_handler) =3D=3D SIG_ERR) {
++        error("signal(SIGPIPE) failed: %s", strerror(errno));
++        exit(EXIT_FAILURE);
++    }
++}
++
++static void daemonize(void)
++{
++    pid_t sid, pid;
++    info("daemonizing process");
++    pid =3D fork();
++    if (pid < 0) {
++        error("fork() failed: %s", strerror(errno));
++        exit(EXIT_FAILURE);
++    }
++    if (pid > 0) exit(EXIT_SUCCESS);
++    pid =3D getpid();
++    sid =3D setsid();
++    if (sid < 0) {
++        error("setsid() failed: %s", strerror(errno));
++        exit(EXIT_FAILURE);
++    }
++    if (chdir("/") < 0) {
++        error("chdir() failed: %s", strerror(errno));
++        exit(EXIT_FAILURE);
++    }
++    close(STDIN_FILENO);
++    close(STDOUT_FILENO);
++    close(STDERR_FILENO);
++    is_daemon =3D 1;
++    info("process was successfully daemonized: pid=3D%d sid=3D%d", pid,=
 sid);
++}
++
++static int mkdirs(const char *path)
++{
++    char *copy =3D strdup(path);
++    char *p =3D strchr(copy + 1, '/');
++    while (p !=3D NULL) {
++        *p =3D '\0';
++        if ((mkdir(copy, 0755) =3D=3D -1) && (errno !=3D EEXIST)) {
++            free(copy);
++            return errno;
++        }
++        *p =3D '/';
++        p =3D strchr(p + 1, '/');
++    }
++    free(copy);
++    return 0;
++}
++
++static int init_socket(const char *name)
++{
++    int sock;
++    struct sockaddr_un addr;
++    info("initializing socket %s", name);
++    sock =3D socket(AF_UNIX, SOCK_STREAM, 0);
++    if (sock < 0) {
++        error("socket(AF_UNIX) failed: %s", strerror(errno));
++        return -1;
++    }
++    mkdirs(name);
++    addr.sun_family =3D AF_UNIX;
++    strncpy(addr.sun_path, name, sizeof(addr.sun_path));
++    umask(0177);
++    if (bind(sock, (struct sockaddr*)&addr, sizeof(addr)) < 0) {
++        error("bind(%s) failed: %s", addr.sun_path, strerror(errno));
++        close(sock);
++        return -1;
++    }
++    listen(sock, 1);
++    return sock;
++}
++
++static void main_loop(void)
++{
++    int sock, fh, res;
++    int32_t in_len;
++    uint32_t out_len;
++    uint8_t in[TPM_CMD_BUF_SIZE], *out;
++    struct sockaddr_un addr;
++    socklen_t addr_len;
++    fd_set rfds;
++    struct timeval tv;
++
++    info("staring main loop");
++    /* open UNIX socket */
++    sock =3D init_socket(opt_socket_name);
++    if (sock < 0) exit(EXIT_FAILURE);
++    /* init tpm emulator */
++    debug("initializing TPM emulator");
++    if (tpm_emulator_init(tpm_startup, tpm_config) !=3D 0) {
++        error("tpm_emulator_init() failed");
++        close(sock);
++        unlink(opt_socket_name);
++        exit(EXIT_FAILURE);
++    }
++    /* start command processing */
++    while (!stopflag) {
++        /* wait for incomming connections */
++        debug("waiting for connections...");
++        FD_ZERO(&rfds);
++        FD_SET(sock, &rfds);
++        tv.tv_sec =3D 10;
++        tv.tv_usec =3D 0;
++        res =3D select(sock + 1, &rfds, NULL, NULL, &tv);
++        if (res < 0) {
++            error("select(sock) failed: %s", strerror(errno));
++            break;
++        } else if (res =3D=3D 0) {
++            continue;
++        }
++        addr_len =3D sizeof(addr);
++        fh =3D accept(sock, (struct sockaddr*)&addr, &addr_len);
++        if (fh < 0) {
++            error("accept() failed: %s", strerror(errno));
++            continue;
++        }
++        /* receive and handle commands */
++        in_len =3D 0;
++        do {
++            debug("waiting for commands...");
++            FD_ZERO(&rfds);
++            FD_SET(fh, &rfds);
++            tv.tv_sec =3D TPM_COMMAND_TIMEOUT;
++            tv.tv_usec =3D 0;
++            res =3D select(fh + 1, &rfds, NULL, NULL, &tv);
++            if (res < 0) {
++                error("select(fh) failed: %s", strerror(errno));
++                close(fh);
++                break;
++            } else if (res =3D=3D 0) {
++#ifdef TPMD_DISCONNECT_IDLE_CLIENTS      =20
++                info("connection closed due to inactivity");
++                close(fh);
++                break;
++#else      =20
++                continue;
++#endif      =20
++            }
++            in_len =3D read(fh, in, sizeof(in));
++            if (in_len > 0) {
++                debug("received %d bytes", in_len);
++                out =3D NULL;
++                res =3D tpm_handle_command(in, in_len, &out, &out_len);=

++                if (res < 0) {
++                    error("tpm_handle_command() failed");
++                } else {
++                    debug("sending %d bytes", out_len);
++                    uint32_t len =3D 0;
++                    while (len < out_len) {
++                        res =3D write(fh, &out[len], out_len - len);
++                        if (res < 0) {
++                            error("write(%d) failed: %s",
++                                  out_len - len, strerror(errno));
++                            break;
++                        }
++                        len +=3D res;
++                    }
++                    tpm_free(out);
++                }
++            }
++        } while (in_len > 0);
++        close(fh);
++    }
++    /* shutdown tpm emulator */
++    tpm_emulator_shutdown();
++    /* close socket */
++    close(sock);
++    unlink(opt_socket_name);
++    info("main loop stopped");
++}
++
++int main(int argc, char **argv)
++{
++    openlog(argv[0], 0, LOG_DAEMON);
++    setlogmask(~LOG_MASK(LOG_DEBUG));
++    syslog(LOG_INFO, "--- separator ---\n");
++    tpm_log =3D my_log;
++    info("starting TPM Emulator daemon (1.2.%d.%d-%d)",
++         VERSION_MAJOR, VERSION_MINOR, VERSION_BUILD);
++    parse_options(argc, argv);
++    /* switch uid/gid if required */
++    switch_uid_gid();
++    /* init signal handlers */
++    init_signal_handler();
++    /* unless requested otherwiese, fork and daemonize process */
++    if (!opt_foreground) daemonize();
++    /* start main processing loop */
++    main_loop();
++    info("stopping TPM Emulator daemon");
++    closelog();
++    return EXIT_SUCCESS;
++}
diff --git a/tools/vtpm/vtpm.patch b/tools/vtpm/vtpm.patch
--- a/tools/vtpm/vtpm.patch
+++ /dev/null
@@ -1,716 +0,0 @@
-diff -uprN tpm_emulator/AUTHORS vtpm/AUTHORS
---- tpm_emulator/AUTHORS    2006-12-08 12:51:29.000000000 -0800
-+++ vtpm/AUTHORS    2006-12-13 16:38:52.000000000 -0800
-@@ -1,3 +1,3 @@
- Mario Strasser <mast@gmx.net>
- Heiko Stamer <stamer@gaos.org> [DAA]
--INTEL Corp <> [Dropped to Ring3]
-+INTEL Corp <> [VTPM Extensions]
-diff -uprN tpm_emulator/ChangeLog vtpm/ChangeLog
---- tpm_emulator/ChangeLog    2006-12-08 12:51:29.000000000 -0800
-+++ vtpm/ChangeLog    2006-12-13 16:38:52.000000000 -0800
-@@ -1,5 +1,6 @@
- ????-??-?? Intel Corp
-     * Moved module out of kernel to run as a ring 3 app
-+    * Modified save_to_file and load_from_file to call xen VTPM manager=

-
- 2006-06-23  Mario Strasser <mast@gmx.net>
-     * tpm_startup.c: behaviour of ST_CLEAR and storage of
-diff -uprN tpm_emulator/linux_module.h vtpm/linux_module.h
---- tpm_emulator/linux_module.h    2006-12-08 12:51:29.000000000 -0800
-+++ vtpm/linux_module.h    2007-01-09 14:49:06.000000000 -0800
-@@ -44,18 +44,26 @@
- #define TPM_DEVICE_NAME   "tpm"
- #define TPM_MODULE_NAME   "tpm_emulator"
-
-+/* debug and log output functions */
-+extern int dmi_id;
-+
- #ifdef DEBUG
--#define debug(fmt, ...) printf("TPMD: %s:%d: Debug: " fmt "\n", \
--                        __FILE__, __LINE__, ## __VA_ARGS__)
-+#define debug(fmt, ...) printf("TPMD[%d]: %s:%d: Debug: " fmt "\n", \
-+                        dmi_id, __FILE__, __LINE__, ## __VA_ARGS__)
-+#define debug_nostop(fmt, ...) printf("TPMD[%d]: %s:%d: Debug: " fmt, \=

-+                        dmi_id, __FILE__, __LINE__, ## __VA_ARGS__)
-+#define debug_more(fmt, ...) printf( fmt, ## __VA_ARGS__ )
- #else
- #define debug(fmt, ...)
-+#define debug_nostop(fmt, ...)
-+#define debug_more(fmt, ...)
- #endif
--#define info(fmt, ...)  printf("TPMD: %s:%d: Info: " fmt "\n", \
--                        __FILE__, __LINE__, ## __VA_ARGS__)
--#define error(fmt, ...) printf("TPMD: %s:%d: Error: " fmt "\n", \
--                        __FILE__, __LINE__, ## __VA_ARGS__)
--#define alert(fmt, ...) printf("TPMD: %s:%d: Alert: " fmt "\n", \
--                        __FILE__, __LINE__, ## __VA_ARGS__)
-+#define info(fmt, ...)  printf("TPMD[%d]: %s:%d: Info: " fmt "\n", \
-+                        dmi_id, __FILE__, __LINE__, ## __VA_ARGS__)
-+#define error(fmt, ...) printf("TPMD[%d]: %s:%d: Error: " fmt "\n", \
-+                        dmi_id, __FILE__, __LINE__, ## __VA_ARGS__)
-+#define alert(fmt, ...) printf("TPMD[%d]: %s:%d: Alert: " fmt "\n", \
-+                        dmi_id, __FILE__, __LINE__, ## __VA_ARGS__)
-
- /* memory allocation */
-
-diff -uprN tpm_emulator/Makefile vtpm/Makefile
---- tpm_emulator/Makefile    2006-12-08 12:51:29.000000000 -0800
-+++ vtpm/Makefile    2006-12-13 16:38:52.000000000 -0800
-@@ -7,7 +7,7 @@
- COMPILE_ARCH    ?=3D $(shell uname -m | sed -e s/i.86/x86_32/)
-
- # module settings
--BIN            :=3D tpm_emulator
-+BIN            :=3D vtpmd
- VERSION_MAJOR  :=3D 0
- VERSION_MINOR  :=3D 4
- VERSION_BUILD  :=3D $(shell date +"%s")
-@@ -22,7 +22,7 @@ TOOLS_INSTALL_DIR =3D $(DESTDIR)/usr/bin
-
- CC      :=3D gcc
- CFLAGS  +=3D -g -Wall $(INCLUDE) -DDEBUG
--CFLAGS  +=3D -I. -Itpm
-+CFLAGS  +=3D -I. -Itpm -I../../vtpm_manager/manager
-
- # Is the simulator running in it's own vm?
- #CFLAGS +=3D -DVTPM_MULTI_VM
-@@ -62,7 +62,6 @@ $(BIN):    $(src)/crypto/gmp.h $(src)/crypt
-
- install: $(BIN)
-     $(INSTALL_PROG) $(BIN) $(TOOLS_INSTALL_DIR)
--    @if [ ! -d "/var/tpm" ]; then mkdir /var/tpm; fi
-
- clean:
-     rm -f $(src)/crypto/gmp.h $(src)/crypto/libgmp.a $(OBJS)
-@@ -98,3 +97,4 @@ version:
-     @echo "#endif /* _TPM_VERSION_H_ */" >> $(src)/tpm_version.h
-
- .PHONY: all install clean dist gmp version
-+
-diff -uprN tpm_emulator/tpm/tpm_capability.c vtpm/tpm/tpm_capability.c
---- tpm_emulator/tpm/tpm_capability.c    2006-06-23 03:37:07.000000000
-0700
-+++ vtpm/tpm/tpm_capability.c    2007-01-10 10:00:49.000000000 -0800
-@@ -136,8 +136,18 @@ static TPM_RESULT cap_property(UINT32 su
-
-     case TPM_CAP_PROP_TIS_TIMEOUT:
-       debug("[TPM_CAP_PROP_TIS_TIMEOUT]");
--      /* TODO: TPM_CAP_PROP_TIS_TIMEOUT */
--      return TPM_FAIL;
-+      /* TODO: TPM_CAP_PROP_TIS_TIMEOUT: Measure these values and
determine correct ones */
-+      UINT32 len =3D *respSize =3D 16;
-+      BYTE *ptr =3D *resp =3D tpm_malloc(*respSize);
-+      if (ptr =3D=3D NULL ||
-+          tpm_marshal_UINT32(&ptr, &len, 200000) ||
-+          tpm_marshal_UINT32(&ptr, &len, 200000) ||
-+          tpm_marshal_UINT32(&ptr, &len, 200000) ||
-+          tpm_marshal_UINT32(&ptr, &len, 200000)) {
-+        tpm_free(*resp);
-+        return TPM_FAIL;
-+      }
-+      return TPM_SUCCESS;
-
-     case TPM_CAP_PROP_STARTUP_EFFECT:
-       debug("[TPM_CAP_PROP_STARTUP_EFFECT]");
-@@ -190,7 +200,11 @@ static TPM_RESULT cap_property(UINT32 su
-
-     case TPM_CAP_PROP_DURATION:
-       debug("[TPM_CAP_PROP_DURATION]");
--      /* TODO: TPM_CAP_PROP_DURATION */
-+      /* TODO: TPM_CAP_PROP_DURATION: Measure these values and return
accurate ones */
-+      BYTE dur[]=3D
{0x0,0x0,0x0,0xc,0x0,0x7,0xa1,0x20,0x0,0x1e,0x84,0x80,0x11,0xe1,0xa3,0x0}=
;
-+      *respSize =3D 16;
-+      *resp =3D tpm_malloc(*respSize);
-+      memcpy(*resp,dur,16);
-       return TPM_FAIL;
-
-     case TPM_CAP_PROP_ACTIVE_COUNTER:
-diff -uprN tpm_emulator/tpm/tpm_cmd_handler.c vtpm/tpm/tpm_cmd_handler.c=

---- tpm_emulator/tpm/tpm_cmd_handler.c    2008-02-27 16:35:41.000000000
-0500
-+++ vtpm/tpm/tpm_cmd_handler.c    2008-02-28 14:43:28.000000000 -0500
-@@ -94,12 +94,18 @@ void tpm_compute_out_param_digest(TPM_CO
-   sha1_ctx_t sha1;
-   UINT32 res =3D CPU_TO_BE32(rsp->result);
-   UINT32 ord =3D CPU_TO_BE32(ordinal);
-+  UINT32 offset =3D 0;
-
-   /* compute SHA1 hash */
-   sha1_init(&sha1);
-   sha1_update(&sha1, (BYTE*)&res, 4);
-   sha1_update(&sha1, (BYTE*)&ord, 4);
--  sha1_update(&sha1, rsp->param, rsp->paramSize);
-+  if (ordinal =3D=3D TPM_ORD_LoadKey2) {
-+      offset =3D 4;
-+  }
-+  if (rsp->paramSize - offset > 0) {
-+      sha1_update(&sha1, rsp->param + offset, rsp->paramSize - offset);=

-+  }
-   sha1_final(&sha1, rsp->auth1->digest);
-   if (rsp->auth2 !=3D NULL) memcpy(rsp->auth2->digest,
-     rsp->auth1->digest, sizeof(rsp->auth1->digest));
-diff -uprN tpm_emulator/tpm/tpm_data.c vtpm/tpm/tpm_data.c
---- tpm_emulator/tpm/tpm_data.c    2008-02-27 16:35:41.000000000 -0500
-+++ vtpm/tpm/tpm_data.c    2008-02-27 16:35:40.000000000 -0500
-@@ -1,6 +1,7 @@
- /* Software-Based Trusted Platform Module (TPM) Emulator for Linux
-  * Copyright (C) 2004 Mario Strasser <mast@gmx.net>,
-  *                    Swiss Federal Institute of Technology (ETH) Zuric=
h
-+ * Copyright (C) 2005 INTEL Corp
-  *
-  * This module is free software; you can redistribute it and/or modify
-  * it under the terms of the GNU General Public License as published
-@@ -15,10 +16,15 @@
-  * $Id: tpm_data.c 98 2006-05-07 14:16:29Z hstamer $
-  */
-
-+#include <sys/types.h>
-+#include <sys/stat.h>
-+#include <fcntl.h>
-+#include <unistd.h>
-+
- #include "tpm_emulator.h"
- #include "tpm_structures.h"
- #include "tpm_marshalling.h"
--#include "linux_module.h"
-+#include "vtpm_manager.h"
-
- TPM_DATA tpmData;
-
-@@ -158,45 +164,232 @@ void tpm_release_data(void)
- #include <sys/types.h>
- #include <sys/stat.h>
- #include <fcntl.h>
--#include <unistd.h>
-
--#define TPM_STORAGE_FILE "/var/tpm/tpm_emulator-1.2."
STR(VERSION_MAJOR) "." STR(VERSION_MINOR)
-+ static int vtpm_tx_fh=3D-1, vtpm_rx_fh=3D-1;
-+
-+#ifdef VTPM_MUTLI_VM
-+ #define DEV_FE "/dev/tpm"
-+#else
-+ #define VTPM_RX_FIFO_D  "/var/vtpm/fifos/vtpm_rsp_to_%d.fifo"
-+ #define VTPM_TX_FIFO  "/var/vtpm/fifos/vtpm_cmd_from_all.fifo"
-+
-+ extern int dmi_id;
-+ static char *vtpm_rx_name=3DNULL;
-+#endif
-
- static int write_to_file(uint8_t *data, size_t data_length)
- {
--  int res;
--  int fp;
--  fp =3D open(TPM_STORAGE_FILE, O_WRONLY | O_TRUNC | O_CREAT, S_IRUSR |=

S_IWUSR);
--  res =3D write(fp, data, data_length);
--  close(fp);
--  return (res =3D=3D data_length) ? 0 : -1;
-+  int res, out_data_size, in_header_size;
-+  BYTE *ptr, *out_data, *in_header;
-+  UINT32 result, len, in_rsp_size;
-+  UINT16 tag =3D VTPM_TAG_REQ;
-+  =20
-+  printf("Saving NVM\n");
-+  if (vtpm_tx_fh < 0) {
-+#ifdef VTPM_MUTLI_VM
-+    vtpm_tx_fh =3D open(DEV_FE, O_RDWR);
-+#else
-+    vtpm_tx_fh =3D open(VTPM_TX_FIFO, O_WRONLY);
-+#endif
-+  }
-+
-+  if (vtpm_tx_fh < 0) {
-+        return -1;
-+  }
-+
-+  // Send request to VTPM Manager to encrypt data
-+#ifdef VTPM_MUTLI_VM
-+  out_data_size =3D len =3D VTPM_COMMAND_HEADER_SIZE_CLT + data_length;=

-+#else
-+  out_data_size =3D len =3D VTPM_COMMAND_HEADER_SIZE_SRV + data_length;=

-+#endif
-+=20
-+  out_data =3D ptr =3D (BYTE *) malloc(len);
-+
-+  if (ptr =3D=3D NULL
-+#ifndef VTPM_MUTLI_VM
-+      || tpm_marshal_UINT32(&ptr, &len, dmi_id)
-+#endif
-+      || tpm_marshal_UINT16(&ptr, &len, tag)
-+#ifdef VTPM_MUTLI_VM
-+      || tpm_marshal_UINT32(&ptr, &len, out_data_size)
-+#else
-+      || tpm_marshal_UINT32(&ptr, &len, out_data_size - sizeof(uint32_t=
))
-+#endif=20
-+      || tpm_marshal_UINT32(&ptr, &len, VTPM_ORD_SAVENVM)
-+      || tpm_marshal_BYTE_ARRAY(&ptr, &len, data, data_length)) {
-+    free(out_data);
-+    return -1;
-+  }
-+=20
-+  printf("\tSending SaveNVM Command.\n");
-+  res =3D write(vtpm_tx_fh, out_data, out_data_size);
-+  free(out_data);
-+  if (res !=3D out_data_size) return -1;
-+
-+  if (vtpm_rx_fh < 0) {
-+#ifdef VTPM_MUTLI_VM
-+    vtpm_rx_fh =3D vtpm_tx_fh
-+#else
-+    if (vtpm_rx_name =3D=3D NULL) {
-+      vtpm_rx_name =3D malloc(10 + strlen(VTPM_RX_FIFO_D));
-+      sprintf(vtpm_rx_name, VTPM_RX_FIFO_D, (uint32_t) dmi_id);
-+    }
-+    vtpm_rx_fh =3D open(vtpm_rx_name, O_RDONLY);
-+#endif
-+  }
-+
-+  if (vtpm_rx_fh < 0) {
-+        return -1;
-+  }
-+=20
-+  // Read Header of response so we can get the size & status
-+#ifdef VTPM_MUTLI_VM
-+  in_header_size =3D len =3D VTPM_COMMAND_HEADER_SIZE_CLT;
-+#else
-+  in_header_size =3D len =3D VTPM_COMMAND_HEADER_SIZE_SRV;
-+#endif
-+  in_header =3D ptr =3D malloc(in_header_size);
-+=20
-+  printf("\tReading SaveNVM header.\n");
-+  res =3D read(vtpm_rx_fh, in_header, in_header_size);
-+
-+  if ( (res !=3D in_header_size)
-+#ifndef VTPM_MUTLI_VM
-+       || tpm_unmarshal_UINT32(&ptr, &len, (UINT32*)&dmi_id)
-+#endif
-+       || tpm_unmarshal_UINT16(&ptr, &len, &tag)
-+       || tpm_unmarshal_UINT32(&ptr, &len, &in_rsp_size)
-+       || tpm_unmarshal_UINT32(&ptr, &len, &result) ) {
-+      free(in_header);
-+      return -1;
-+  }
-+  free(in_header);
-+=20
-+  if (result !=3D VTPM_SUCCESS) {
-+      return -1;=20
-+  }
-+
-+#ifdef VTPM_MUTLI_VM
-+  close(vtpm_tx_fh); close(vtpm_rx_fh);
-+#endif
-+    =20
-+  printf("\tFinishing up SaveNVM\n");
-+  return (0);
- }
-
- static int read_from_file(uint8_t **data, size_t *data_length)
- {
--  int res;
--  int fp, file_status;
--  struct stat file_info;
--  fp =3D open(TPM_STORAGE_FILE, O_RDONLY, 0);
--  file_status =3D fstat(fp, &file_info);
--  if (file_status < 0) {
--    close(fp);
--    return -1;
--  }
-+  int res, out_data_size, in_header_size;
-+  uint8_t *ptr, *out_data, *in_header;
-+  UINT16 tag =3D VTPM_TAG_REQ;
-+  UINT32 len, in_rsp_size, result;
-+#ifdef VTPM_MUTLI_VM
-+    int vtpm_rx_fh, vtpm_tx_fh;
-+#endif
-+  =20
-+  printf("Loading NVM.\n");
-+  if (vtpm_tx_fh < 0) {
-+#ifdef VTPM_MUTLI_VM
-+    vtpm_tx_fh =3D open(DEV_FE, O_RDWR);
-+#else
-+    vtpm_tx_fh =3D open(VTPM_TX_FIFO, O_WRONLY);
-+#endif
-+  }
-
--  *data_length =3D file_info.st_size;
--  *data =3D tpm_malloc(*data_length);
--  if (*data =3D=3D NULL) {
--    close(fp);
-+  if (vtpm_tx_fh < 0) {
-+        return -1;
-+  }
-+
-+  // Send request to VTPM Manager to encrypt data
-+#ifdef VTPM_MUTLI_VM
-+  out_data_size =3D len =3D VTPM_COMMAND_HEADER_SIZE_CLT;
-+#else
-+  out_data_size =3D len =3D VTPM_COMMAND_HEADER_SIZE_SRV;
-+#endif
-+  out_data =3D ptr =3D (BYTE *) malloc(len);
-+
-+  if (ptr =3D=3D NULL
-+#ifndef VTPM_MUTLI_VM
-+      || tpm_marshal_UINT32(&ptr, &len, dmi_id)
-+#endif=20
-+      || tpm_marshal_UINT16(&ptr, &len, tag)
-+#ifdef VTPM_MUTLI_VM
-+      || tpm_marshal_UINT32(&ptr, &len, out_data_size)
-+#else
-+      || tpm_marshal_UINT32(&ptr, &len, out_data_size - sizeof(uint32_t=
))
-+#endif
-+      || tpm_marshal_UINT32(&ptr, &len, VTPM_ORD_LOADNVM)) {
-+    free(out_data);
-     return -1;
-   }
--  res =3D read(fp, *data, *data_length);
--  close(fp);
-+
-+  printf("\tSending LoadNVM command\n");
-+  res =3D write(vtpm_tx_fh, out_data, out_data_size);
-+  free(out_data);
-+  if (res !=3D out_data_size) return -1;
-+
-+    if (vtpm_rx_fh < 0) {
-+#ifdef VTPM_MUTLI_VM
-+    vtpm_rx_fh =3D vtpm_tx_fh;
-+#else
-+    if (vtpm_rx_name =3D=3D NULL) {
-+      vtpm_rx_name =3D malloc(10 + strlen(VTPM_RX_FIFO_D));
-+      sprintf(vtpm_rx_name, VTPM_RX_FIFO_D, (uint32_t) dmi_id);
-+    }
-+    vtpm_rx_fh =3D open(vtpm_rx_name, O_RDONLY);
-+#endif
-+  }
-+
-+  if (vtpm_rx_fh < 0) {
-+        return -1;
-+  }
-+=20
-+  // Read Header of response so we can get the size & status
-+#ifdef VTPM_MUTLI_VM
-+  in_header_size =3D len =3D VTPM_COMMAND_HEADER_SIZE_CLT;
-+#else
-+  in_header_size =3D len =3D VTPM_COMMAND_HEADER_SIZE_SRV;
-+#endif
-+  in_header =3D ptr =3D malloc(in_header_size);
-+=20
-+  printf("\tReading LoadNVM header\n");
-+  res =3D read(vtpm_rx_fh, in_header, in_header_size);
-+
-+  if ( (res !=3D in_header_size)
-+#ifndef VTPM_MUTLI_VM
-+       || tpm_unmarshal_UINT32(&ptr, &len, (UINT32*)&dmi_id)
-+#endif
-+       || tpm_unmarshal_UINT16(&ptr, &len, &tag)
-+       || tpm_unmarshal_UINT32(&ptr, &len, &in_rsp_size)
-+       || tpm_unmarshal_UINT32(&ptr, &len, &result) ) {
-+      free(in_header);
-+      return -1;
-+  }
-+  free(in_header);
-+=20
-+  if (result !=3D VTPM_SUCCESS) {
-+      return -1;=20
-+  }
-+
-+  // Read Encrypted data from VTPM Manager
-+  *data_length =3D in_rsp_size - VTPM_COMMAND_HEADER_SIZE_CLT;
-+  *data =3D (uint8_t *) malloc(*data_length);
-+
-+  printf("\tReading clear data from LoadNVM.\n");
-+  res =3D read(vtpm_rx_fh, *data, *data_length);
-+#ifdef VTPM_MUTLI_VM
-+  close(vtpm_rx_fh);close(vtpm_tx_fh);
-+#endif
-+  =20
-+  printf("\tReturing from loading NVM\n");
-   if (res !=3D *data_length) {
--    tpm_free(*data);
--    return -1;
-+      free(*data);
-+      return -1;
-+  } else {
-+      return 0;
-   }
--  return 0;
-+
- }
-
- #else
-diff -uprN tpm_emulator/tpmd.c vtpm/tpmd.c
---- tpm_emulator/tpmd.c    2006-12-08 12:51:29.000000000 -0800
-+++ vtpm/tpmd.c    2007-01-09 14:48:56.000000000 -0800
-@@ -21,12 +21,24 @@
- #include <sys/stat.h>
- #include <fcntl.h>
- #include <sys/time.h>
-+#include <sys/socket.h>
-+#include <sys/un.h>
-+#include <errno.h>
-
- #include "tpm_emulator.h"
-+#include "vtpm_manager.h"
-
--#define TPM_RX_FNAME "/var/tpm/tpm_in.fifo"
--#define TPM_TX_FNAME "/var/tpm/tpm_out.fifo"
-+#ifdef VTPM_MULTI_VM
-+ #define DEV_BE "/dev/vtpm"
-+#else
-+ #define PVM_RX_FIFO_D "/var/vtpm/fifos/tpm_cmd_to_%d.fifo"
-+ #define PVM_TX_FIFO "/var/vtpm/fifos/tpm_rsp_from_all.fifo"
-
-+ #define HVM_RX_FIFO_D "/var/vtpm/socks/%d.socket"
-+#endif
-+
-+ int dmi_id;
-+                      =20
- #define BUFFER_SIZE 2048
-
- static int devurandom=3D0;
-@@ -38,7 +50,7 @@ void get_random_bytes(void *buf, int nby
-   }
-
-   if (read(devurandom, buf, nbytes) !=3D nbytes) {
--      printf("Can't get random number.\n");
-+      error("Can't get random number.\n");
-       exit(-1);
-   }
- }
-@@ -52,105 +64,182 @@ uint64_t tpm_get_ticks(void)
-
- int main(int argc, char **argv)
- {
--  uint8_t in[BUFFER_SIZE], *out;
-+  uint8_t type, in[BUFFER_SIZE], *out, *addressed_out;
-+  char *vtpm_rx_file=3DNULL;
-   uint32_t out_size;
-   int in_size, written;
--  int i;
--  struct stat file_info;
-+  int i, guest_id=3D-1;
-
--  int tpm_tx_fh=3D-1, tpm_rx_fh=3D-1;
-+#ifndef VTPM_MULTI_VM
-+  int sockfd =3D -1;
-+  struct sockaddr_un addr;
-+  struct sockaddr_un client_addr;
-+  unsigned int client_length;
-+
-+#endif
-+
-+  int vtpm_tx_fh=3D-1, vtpm_rx_fh=3D-1;
-+#ifdef VTPM_MULTI_VM
-   if (argc < 2) {
--    printf("Usage: tpmd clear|save|deactivated\n" );
-+    error("Usage: tpmd clear|save|deactivated\n" );
-+#else
-+  if (argc < 4) {
-+    error("Usage: tpmd clear|save|deactivated pvm|hvm vtpmid\n" );
-+#endif
-       return -1;
-   }
-
-+#ifndef VTPM_MULTI_VM
-+  /* setup type of vm */
-+  if (!strcmp(argv[2], "pvm")) {
-+    type =3D VTPM_TYPE_PVM; // Get commands from vTPM Manager through f=
ifo
-+  } else if (!strcmp(argv[2], "hvm")) {
-+    type =3D VTPM_TYPE_HVM; // Get commands from qemu via socket
-+  } else {
-+    error("invalid vTPM type '%s'.\n", argv[2]);
-+  }
-+
-+  dmi_id =3D atoi(argv[3]);
-+
-+  if (type =3D=3D VTPM_TYPE_PVM) {
-+    vtpm_rx_file =3D malloc(10 + strlen(PVM_RX_FIFO_D));
-+    sprintf(vtpm_rx_file, PVM_RX_FIFO_D, (uint32_t) dmi_id);
-+  } else {
-+    vtpm_rx_file =3D malloc(10 + strlen(HVM_RX_FIFO_D));
-+    sprintf(vtpm_rx_file, HVM_RX_FIFO_D, (uint32_t) dmi_id);
-+
-+    if ( (sockfd =3D socket(PF_UNIX,SOCK_STREAM,0)) < 0) {
-+          error("Unable to create socket. errno =3D %d\n", errno);
-+      exit (-1);
-+    }
-+
-+    memset(&addr, 0, sizeof(addr));
-+    addr.sun_family =3D AF_UNIX;
-+    strcpy(addr.sun_path,vtpm_rx_file );
-+    unlink(addr.sun_path);
-+  }
-+#endif
-+
-+#ifdef VTPM_MULTI_VM
-+  info("Initializing tpm state: %s\n", argv[1]);
-+#else
-+  info("Initializing tpm state: %s, type: %s, id: %d\n", argv[1],
argv[2], dmi_id);
-+#endif
-+
-   /* initialize TPM emulator */
-   if (!strcmp(argv[1], "clear")) {
--    printf("Initializing tpm: %s\n", argv[1]);
-     tpm_emulator_init(1);
--  } else if (!strcmp(argv[1], "save")) {
--    printf("Initializing tpm: %s\n", argv[1]);
-+  } else if (!strcmp(argv[1], "save")) {
-     tpm_emulator_init(2);
-   } else if (!strcmp(argv[1], "deactivated")) {
--    printf("Initializing tpm: %s\n", argv[1]);
-     tpm_emulator_init(3);
-   } else {
--    printf("invalid startup mode '%s'; must be 'clear', "
-+    error("invalid startup mode '%s'; must be 'clear', "
-       "'save' (default) or 'deactivated", argv[1]);
-     return -1;
-   }
--
--  if ( stat(TPM_RX_FNAME, &file_info) =3D=3D -1) {
--    if ( mkfifo(TPM_RX_FNAME, S_IWUSR | S_IRUSR ) ) {
--      printf("Failed to create fifo %s.\n", TPM_RX_FNAME);
--      return -1;
--    }
--  }
--
--  if ( stat(TPM_TX_FNAME, &file_info) =3D=3D -1) {
--    if ( mkfifo(TPM_TX_FNAME, S_IWUSR | S_IRUSR ) ) {
--      printf("Failed to create fifo %s.\n", TPM_TX_FNAME);
--      return -1;
--    }
--  }
--
-+=20
-   while (1) {
- abort_command:
--    if (tpm_rx_fh < 0) {
--      tpm_rx_fh =3D open(TPM_RX_FNAME, O_RDONLY);
-+    if (vtpm_rx_fh < 0) {
-+#ifdef VTPM_MUTLI_VM
-+      vtpm_rx_fh =3D open(DEV_BE, O_RDWR);
-+#else
-+      if (type =3D=3D VTPM_TYPE_PVM) {
-+        vtpm_rx_fh =3D open(vtpm_rx_file, O_RDONLY);
-+      } else {
-+        if (bind(sockfd, (struct sockaddr *)&addr, sizeof(addr)) < 0) {=

-+          error("Unable to bind(). errno =3D %d\n", errno);
-+          exit (-1);
-+        }
-+
-+        if (listen(sockfd, 10) <0) {
-+          error("Unable to listen(). errno =3D %d\n", errno);
-+          exit (-1);
-+        }
-+
-+        memset(&client_addr, 0, sizeof(client_addr));
-+        client_length =3D sizeof(client_addr);
-+
-+        vtpm_rx_fh =3D vtpm_tx_fh =3D accept(sockfd, (struct sockaddr
*)&client_addr, &client_length);
-+      }
-+#endif
-     }
-   =20
--    if (tpm_rx_fh < 0) {
--      printf("ERROR: failed to open devices to listen to guest.\n");
-+    if (vtpm_rx_fh < 0) {
-+      error("Failed to open devices to listen to guest.\n");
-       return -1;
-     }
-   =20
--    if (tpm_tx_fh < 0) {
--      tpm_tx_fh =3D open(TPM_TX_FNAME, O_WRONLY);
--    }
--
--    if (tpm_tx_fh < 0) {
--      printf("ERROR: failed to open devices to respond to guest.\n");
--      return -1;
--    }
--
--    in_size =3D read(tpm_rx_fh, in, BUFFER_SIZE);
-+    in_size =3D read(vtpm_rx_fh, in, BUFFER_SIZE);
-     if (in_size < 6) { // Magic size of minium TPM command
--      printf("Recv[%d] to small: 0x", in_size);
-+      info("Recv incomplete command of %d bytes.", in_size);
-       if (in_size <=3D 0) {
--          close(tpm_rx_fh);
--          tpm_rx_fh =3D -1;
-+          close(vtpm_rx_fh);
-+          vtpm_rx_fh =3D -1;
-           goto abort_command;
-       }
-     } else {
--      printf("Recv[%d]: 0x", in_size);
-+      debug_nostop("Recv[%d]: 0x", in_size);
-       for (i=3D0; i< in_size; i++)
--        printf("%x ", in[i]);
--      printf("\n");
-+        debug_more("%x ", in[i]);
-+      debug_more("\n");
-     }
-
--  =20
--    if (tpm_handle_command(in, in_size, &out, &out_size) !=3D 0) {
--        printf("ERROR: Handler Failed.\n");
-+    if (guest_id =3D=3D -1) {
-+        guest_id =3D *((uint32_t *) in);
-+    } else {
-+        if (guest_id !=3D *((uint32_t *) in) ) {
-+            error("WARNING: More than one guest attached\n");
-+        }
-+    }
-+
-+    if (vtpm_tx_fh < 0) {
-+#ifdef VTPM_MUTLI_VM
-+      vtpm_tx_fh =3D open(DEV_BE, O_RDWR);
-+      vtpm_rx_fh =3D vtpm_tx_fh;
-+#else
-+      if (type =3D=3D VTPM_TYPE_PVM) {
-+        vtpm_tx_fh =3D open(PVM_TX_FIFO, O_WRONLY);
-+      } // No need to open the other direction for HVM
-+#endif
-+    }
-+
-+    if (vtpm_tx_fh < 0) {
-+      error("Failed to open devices to respond to guest.\n");
-+      return -1;
-+    }
-+
-+    // Handle the command, but skip the domain id header  =20
-+    if (tpm_handle_command(in + sizeof(uint32_t), in_size -
sizeof(uint32_t), &out, &out_size) !=3D 0) {
-+      error("Handler Failed.\n");
-     }
-
--    written =3D write(tpm_tx_fh, out, out_size);
-+    addressed_out =3D (uint8_t *) tpm_malloc(sizeof(uint32_t) + out_siz=
e);
-+    *(uint32_t *) addressed_out =3D *(uint32_t *) in;
-+    memcpy(addressed_out + sizeof(uint32_t), out, out_size);
-+
-+    written =3D write(vtpm_tx_fh, addressed_out, out_size +
sizeof(uint32_t));
-
--    if (written !=3D out_size ) {
--      printf("ERROR: Part of response not written %d/%d.\nAttempt: ",
written, out_size);
-+    if (written !=3D out_size + sizeof(uint32_t)) {
-+      error("Part of response not written %d/%d.\n", written, out_size)=
;
-     } else {
--      printf("Sent[%Zu]: ", out_size);
-+      debug_nostop("Sent[%Zu]: ", out_size + sizeof(uint32_t));
-+      for (i=3D0; i< out_size+ sizeof(uint32_t); i++)
-+        debug_more("%x ", addressed_out[i]);
-+      debug_more("\n");
-     }
--    for (i=3D0; i< out_size; i++)
--      printf("%x ", out[i]);
--    printf("\n");
-     tpm_free(out);
-+    tpm_free(addressed_out);
-
-   } // loop
-
-   tpm_emulator_shutdown();
-
--  close(tpm_tx_fh);
--  close(tpm_rx_fh);
-+  close(vtpm_tx_fh);
-+#ifndef VTPM_MUTLI_VM
-+  close(vtpm_rx_fh);
-+  free (vtpm_rx_file);
-+#endif
-
- }
--=20
1.7.4.4



--------------ms030704010609040205060800
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIDyjCC
A8YwggMvoAMCAQICBD/xyf0wDQYJKoZIhvcNAQEFBQAwLzELMAkGA1UEBhMCVVMxDzANBgNV
BAoTBkpIVUFQTDEPMA0GA1UECxMGQklTRENBMB4XDTEwMDYxMTE4MjIwNloXDTEzMDYxMTE4
NTIwNlowZjELMAkGA1UEBhMCVVMxDzANBgNVBAoTBkpIVUFQTDEPMA0GA1UECxMGUGVvcGxl
MTUwFgYDVQQLEw9WUE5Hcm91cC1CSVNEQ0EwGwYDVQQDExRNYXR0aGV3IEUgRmlvcmF2YW50
ZTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAnpbwVSP6o1Nb5lcW7dd3yTo9iBJdi7qz
4nANOMFPK7JOy5npKN1iiousl28U/scUJES55gPwAWYJK3uVyQAsA4adgDKi5DoD1UHDQEwp
bY7iHLJeq0NPr4BqYNqnCFPbE6HC8zSJrr4qKn+gVUQT39SIFqdiIPJwZL8FYTRQ/zsCAwEA
AaOCAbYwggGyMAsGA1UdDwQEAwIHgDArBgNVHRAEJDAigA8yMDEwMDYxMTE4MjIwNlqBDzIw
MTIwNzE3MjI1MjA2WjAbBg0rBgEEAbMlCwMBAQEBBAoWCGZpb3JhbWUxMBsGDSsGAQQBsyUL
AwEBAQIEChIIMDAxMDQyNjEwWAYJYIZIAYb6ax4BBEsMSVRoZSBwcml2YXRlIGtleSBjb3Jy
ZXNwb25kaW5nIHRvIHRoaXMgY2VydGlmaWNhdGUgbWF5IGhhdmUgYmVlbiBleHBvcnRlZC4w
KAYDVR0RBCEwH4EdTWF0dGhldy5GaW9yYXZhbnRlQGpodWFwbC5lZHUwUgYDVR0fBEswSTBH
oEWgQ6RBMD8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJU0RD
QTEOMAwGA1UEAxMFQ1JMNTYwHwYDVR0jBBgwFoAUCDUpmxH52EU2CyWmF2EJMB1yqeswHQYD
VR0OBBYEFO6LYxg6r9wHZ+zdQtBHn1dZ/YTNMAkGA1UdEwQCMAAwGQYJKoZIhvZ9B0EABAww
ChsEVjcuMQMCBLAwDQYJKoZIhvcNAQEFBQADgYEAJO9HQh4YNChVLzuZqK5ARJARD8JoujGZ
fdo75quvg2jXFQe2sEjvLnxJZgm/pv8fdZakq48CWwjYHKuvIp7sDjTEsQfo+y7SpN/N2NvJ
WU5SqfK1VgYtNLRRoGJUB5Q1aZ+Dg95g3kqpyfpUMISJL8IKVLtJVfN4fggFVUYZ9wwxggGr
MIIBpwIBATA3MC8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJ
U0RDQQIEP/HJ/TAJBgUrDgMCGgUAoIHLMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ
KoZIhvcNAQkFMQ8XDTEyMDkxNzE3NTI0MFowIwYJKoZIhvcNAQkEMRYEFKc1wjp+kmE0kjMy
K6/oTGjDugLtMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAK
BggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI
KoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEgYAUxbR1IWDOQOj9v4+3GL6p7XkNfXR0AuWT
jBAKO8ihVVIbKPpldN4rvGmXyC27nixOkOB7PmkrAZLLKyVbDLHipIiZ7+fA3WCm2temcqgn
J6MTiX55fIiNnHliWd2n0mxAQDKce51CE+liV25z6Qsr13cuQkIgIKGyWM2cj43jNgAAAAAA
AA==
--------------ms030704010609040205060800--


--===============3101777180007788348==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============3101777180007788348==--


From xen-devel-bounces@lists.xen.org Mon Sep 17 17:54:22 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 17:54:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDfWP-0004Fp-Jd; Mon, 17 Sep 2012 17:54:13 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <matthew.fioravante@jhuapl.edu>) id 1TDfWN-0004Fk-07
	for xen-devel@lists.xensource.com; Mon, 17 Sep 2012 17:54:11 +0000
Received: from [85.158.138.51:11693] by server-10.bemta-3.messagelabs.com id
	48/0B-10411-2C367505; Mon, 17 Sep 2012 17:54:10 +0000
X-Env-Sender: matthew.fioravante@jhuapl.edu
X-Msg-Ref: server-6.tower-174.messagelabs.com!1347904441!22875728!1
X-Originating-IP: [128.244.251.36]
X-SpamReason: No, hits=0.0 required=7.0 tests=UNPARSEABLE_RELAY
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23144 invoked from network); 17 Sep 2012 17:54:03 -0000
Received: from pilot.jhuapl.edu (HELO jhuapl.edu) (128.244.251.36)
	by server-6.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 17 Sep 2012 17:54:03 -0000
Received: from ([128.244.207.89])
	by pilot.jhuapl.edu with ESMTP with TLS id 63GHCH1.153058441;
	Mon, 17 Sep 2012 13:53:55 -0400
Message-ID: <50576368.3070007@jhuapl.edu>
Date: Mon, 17 Sep 2012 13:52:40 -0400
From: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:14.0) Gecko/20120714 Thunderbird/14.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
X-Enigmail-Version: 1.5a1pre
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: [Xen-devel] [PATCH] Upgrade vtpmd to berlios version 0.7.4
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============3101777180007788348=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a cryptographically signed message in MIME format.

--===============3101777180007788348==
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms030704010609040205060800"

This is a cryptographically signed message in MIME format.

--------------ms030704010609040205060800
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

What will follow soon are updates to vtpmd, vtpm_manager, xm, xl,
mini-os, and new vtpm and vtpm manager stub domains.

The first patch I'd like to submit upgrades vtpmd to version 0.7.4

This patch does the following:
-add checks to configure to check for cmake (required by berlios 0.7.4)
-removes all of the 0.5.1 patches
-adds a single patch for 0.7.4
-cleans up the makefile, should work for parallel make (avoiding
version.h discussion from august 2012)
-builds vtpmd to use berlios 0.7.4
-Remoed the tpm_emualtor build option. berlios itself provides a kernel
module if you want to use it in dom0 to emulate the physical tpm.

Signed of by: Matthew Fioravante matthew.fioravante@jhuapl.edu

diff --git a/tools/configure.ac b/tools/configure.ac
--- a/tools/configure.ac
+++ b/tools/configure.ac
@@ -67,6 +67,7 @@ AC_ARG_VAR([CURL], [Path to curl-config tool])
 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([CMAKE], [Path to cmake binary])
=20
 dnl as86, ld86, bcc and iasl are only present in x86* systems
 case "$host_cpu" in
@@ -108,6 +109,9 @@ AS_IF([test "x$pythontools" =3D "xy"], [
     AX_CHECK_PYTHON_VERSION([2], [3])
     AX_CHECK_PYTHON_DEVEL()
 ])
+AS_IF([test "x$vtpm" =3D "xy"], [
+    AX_PATH_PROG_OR_FAIL([CMAKE], [cmake])
+])
 AX_PATH_PROG_OR_FAIL([XGETTEXT], [xgettext])
 AX_PATH_PROG_OR_FAIL([AS86], [as86])
 AX_PATH_PROG_OR_FAIL([LD86], [ld86])
diff --git a/tools/vtpm/Makefile b/tools/vtpm/Makefile
--- a/tools/vtpm/Makefile
+++ b/tools/vtpm/Makefile
@@ -1,19 +1,15 @@
 XEN_ROOT =3D $(CURDIR)/../..
+include $(XEN_ROOT)/tools/Rules.mk
=20
-# Base definitions and rules
-include $(XEN_ROOT)/tools/vtpm/Rules.mk
-
-# Dir name for emulator (as dom0 tpm driver)
-TPM_EMULATOR_DIR =3D tpm_emulator
 # Dir name for vtpm instance
 VTPM_DIR =3D vtpm
-ORIG_DIR =3D orig
=20
 # Emulator tarball name
-TPM_EMULATOR_NAME =3D tpm_emulator-0.5.1
+TPM_EMULATOR_URL =3D http://download.berlios.de/tpm-emulator
+TPM_EMULATOR_NAME =3D tpm_emulator-0.7.4
 TPM_EMULATOR_TARFILE =3D $(TPM_EMULATOR_NAME).tar.gz
=20
-GMP_HEADER =3D /usr/include/gmp.h
+VTPM_PATCH =3D vtpm-0.7.4.patch
=20
 .PHONY: all
 all: build
@@ -23,51 +19,34 @@ build: build_sub
=20
 .PHONY: install
 install: build
-    $(MAKE) -C $(VTPM_DIR) $@
+    $(INSTALL_PROG) -m 0755 $(VTPM_DIR)/build/tpmd/unix/tpmd
$(DESTDIR)$(BINDIR)/vtpmd
=20
 .PHONY: clean
 clean:
-    @if [ -d $(TPM_EMULATOR_DIR) ]; \
-        then $(MAKE) -C $(TPM_EMULATOR_DIR) clean; \
-    fi
-    @if [ -d $(VTPM_DIR) ]; \
-        then $(MAKE) -C $(VTPM_DIR) clean; \
+    @-if [ -d $(VTPM_DIR)/build ]; \
+        then $(MAKE) -C $(VTPM_DIR)/build clean; \
     fi
=20
 .PHONY: mrproper
 mrproper:
-    rm -f $(TPM_EMULATOR_TARFILE) tpm_emulator.patch.old vtpm.patch.old
-    rm -rf $(TPM_EMULATOR_DIR) $(VTPM_DIR) $(ORIG_DIR)
+    rm -f $(TPM_EMULATOR_TARFILE)
+    rm -rf $(VTPM_DIR) $(ORIG_DIR)
=20
 # Download Swiss emulator
 $(TPM_EMULATOR_TARFILE):
-    wget http://download.berlios.de/tpm-emulator/$(TPM_EMULATOR_TARFILE)=

+    wget $(TPM_EMULATOR_URL)/$(TPM_EMULATOR_TARFILE)
=20
 # Create vtpm dirs
-$(VTPM_DIR)/tpmd/tpmd: $(TPM_EMULATOR_TARFILE) vtpm-0.5.1.patch
+$(VTPM_DIR)/build: $(TPM_EMULATOR_TARFILE) $(VTPM_PATCH)
     rm -rf $(VTPM_DIR)
     tar -xzf $(TPM_EMULATOR_TARFILE)
     mv $(TPM_EMULATOR_NAME) $(VTPM_DIR)
-
     set -e; cd $(VTPM_DIR); \
-    patch -p1 < ../vtpm-0.5.1.patch; \
-    patch -p1 < ../vtpm-0.5.1-LDLIBS.patch
-
-orig: $(TPM_EMULATOR_TARFILE)
-    mkdir $(ORIG_DIR);
-    set -e; cd $(ORIG_DIR); \
-    tar -xzf ../$(TPM_EMULATOR_TARFILE);
-
-updatepatches: clean orig
-    find $(VTPM_DIR) -name "*.orig" -print | xargs rm -f;
-    mv vtpm.patch vtpm.patch.old;
-    diff -uprN $(TPM_EMULATOR_DIR) $(VTPM_DIR) > vtpm.patch || true;
+    patch -p1 < ../$(VTPM_PATCH); \
+    mkdir build; cd build; cmake -DCMAKE_INSTALL_PREFIX=3D${PREFIX} ..
+    touch $@
=20
 .PHONY: build_sub
-build_sub: $(VTPM_DIR)/tpmd/tpmd
-    set -e; if [ -e $(GMP_HEADER) ]; then \
-        $(MAKE) -C $(VTPM_DIR); \
-    else \
-        echo "=3D=3D=3D Unable to build VTPMs. libgmp could not be found=
=2E"; \
-    fi
-
+build_sub: $(VTPM_DIR)/build
+    set -e; \
+    cd $<; $(MAKE) tpmd
diff --git a/tools/vtpm/Rules.mk b/tools/vtpm/Rules.mk
--- a/tools/vtpm/Rules.mk
+++ /dev/null
@@ -1,26 +0,0 @@
-# Base definitions and rules (XEN_ROOT must be defined in including
Makefile)
-include $(XEN_ROOT)/tools/Rules.mk
-
-#
-# Tool definitions
-#
-
-# General compiler flags
-CFLAGS   =3D -Werror -g3
-
-# Generic project files
-HDRS    =3D $(wildcard *.h)
-SRCS    =3D $(wildcard *.c)
-OBJS    =3D $(patsubst %.c,%.o,$(SRCS))
-
-# Generic (non-header) dependencies
-$(SRCS): Makefile $(XEN_ROOT)/tools/Rules.mk
$(XEN_ROOT)/tools/vtpm/Rules.mk
-
-$(OBJS): $(SRCS)
-
--include $(DEPS)
-
-BUILD_EMULATOR =3D y
-
-# Make sure these are just rules
-.PHONY : all build install clean
diff --git a/tools/vtpm/tpm_emulator.patch b/tools/vtpm/tpm_emulator.patc=
h
--- a/tools/vtpm/tpm_emulator.patch
+++ /dev/null
@@ -1,1919 +0,0 @@
-diff -uprN orig/tpm_emulator-0.4/AUTHORS tpm_emulator/AUTHORS
---- orig/tpm_emulator-0.4/AUTHORS    2006-06-23 03:37:07.000000000 -0700=

-+++ tpm_emulator/AUTHORS    2006-07-24 14:35:35.000000000 -0700
-@@ -1,2 +1,3 @@
- Mario Strasser <mast@gmx.net>
- Heiko Stamer <stamer@gaos.org> [DAA]
-+INTEL Corp <> [Dropped to Ring3]
-diff -uprN orig/tpm_emulator-0.4/ChangeLog tpm_emulator/ChangeLog
---- orig/tpm_emulator-0.4/ChangeLog    2006-06-23 03:37:07.000000000 -07=
00
-+++ tpm_emulator/ChangeLog    2006-07-24 14:35:35.000000000 -0700
-@@ -1,3 +1,6 @@
-+????-??-?? Intel Corp
-+    * Moved module out of kernel to run as a ring 3 app
-+
- 2006-06-23  Mario Strasser <mast@gmx.net>
-     * tpm_startup.c: behaviour of ST_CLEAR and storage of
-         persistent data adapted
-diff -uprN orig/tpm_emulator-0.4/crypto/gmp_kernel_wrapper.c
tpm_emulator/crypto/gmp_kernel_wrapper.c
---- orig/tpm_emulator-0.4/crypto/gmp_kernel_wrapper.c    2006-06-23
03:37:07.000000000 -0700
-+++ tpm_emulator/crypto/gmp_kernel_wrapper.c    2006-07-24
14:35:35.000000000 -0700
-@@ -1,5 +1,6 @@
- /* Software-Based Trusted Platform Module (TPM) Emulator for Linux
-  * Copyright (C) 2004 Mario Strasser <mast@gmx.net>,
-+ * Copyright (C) 2005 INTEL Corp
-  *
-  * This module is free software; you can redistribute it and/or modify
-  * it under the terms of the GNU General Public License as published
-@@ -24,15 +25,10 @@ int __gmp_junk;
- void __attribute__ ((regparm(0))) __gmp_assert_fail(const char *filenam=
e,
-   int linenum, const char *expr)
- {
--  panic(KERN_CRIT TPM_MODULE_NAME "%s:%d: GNU MP assertion failed: %s\n=
",
-+  error("%s:%d: GNU MP assertion failed: %s\n",
-     filename, linenum, expr);
- }
-
--void __attribute__ ((regparm(0))) abort(void)
--{
--  panic(KERN_CRIT TPM_MODULE_NAME "GNU MP abort() was called\n");
--}
--
- /* overwrite GNU MP random functions (used by mpz/millerrabin.c) */
-
- void __attribute__ ((regparm(0))) gmp_randinit(gmp_randstate_t rstate,
-@@ -77,20 +73,19 @@ void __attribute__ ((regparm(0))) mpz_ur
-
- void __attribute__ ((regparm(0))) *kernel_allocate(size_t size)
- {
--  void *ret  =3D (void*)kmalloc(size, GFP_KERNEL);
--  if (!ret) panic(KERN_CRIT TPM_MODULE_NAME
--    "GMP: cannot allocate memory (size=3D%u)\n", size);
-+  void *ret  =3D (void*)malloc(size);
-+  if (!ret) error("GMP: cannot allocate memory (size=3D%Zu)\n", size);
-   return ret;
- }
-
- void __attribute__ ((regparm(0))) *kernel_reallocate(void *oldptr,
-   size_t old_size, size_t new_size)
- {
--  void *ret =3D (void*)kmalloc(new_size, GFP_KERNEL);
--  if (!ret) panic(KERN_CRIT TPM_MODULE_NAME "GMP: Cannot reallocate
memory "
--    "(old_size=3D%u new_size=3D%u)\n", old_size, new_size);
-+  void *ret =3D (void*)malloc(new_size);
-+  if (!ret) error("GMP: Cannot reallocate memory "
-+    "(old_size=3D%Zu new_size=3D%Zu)\n", old_size, new_size);
-   memcpy(ret, oldptr, old_size);
--  kfree(oldptr);
-+  free(oldptr);
-   return ret;
- }
-
-@@ -99,7 +94,7 @@ void __attribute__ ((regparm(0))) kernel
-   /* overwrite used memory */
-   if (blk_ptr !=3D NULL) {
-     memset(blk_ptr, 0, blk_size);
--    kfree(blk_ptr);
-+    free(blk_ptr);
-   }
- }
-
-diff -uprN orig/tpm_emulator-0.4/crypto/rsa.c tpm_emulator/crypto/rsa.c
---- orig/tpm_emulator-0.4/crypto/rsa.c    2006-06-23 03:37:07.000000000
-0700
-+++ tpm_emulator/crypto/rsa.c    2006-07-24 14:35:35.000000000 -0700
-@@ -1,5 +1,6 @@
- /* Software-Based Trusted Platform Module (TPM) Emulator for Linux
-  * Copyright (C) 2004 Mario Strasser <mast@gmx.net>,
-+ * Copyright (C) 2005 INTEL Corp
-  *
-  * This module is free software; you can redistribute it and/or modify
-  * it under the terms of the GNU General Public License as published
-@@ -381,7 +382,7 @@ static int encode_message(int type, uint
-       msg[0] =3D 0x00;
-       get_random_bytes(&msg[1], SHA1_DIGEST_LENGTH);
-       sha1_init(&ctx);
--      sha1_update(&ctx, "TCPA", 4);
-+      sha1_update(&ctx, (uint8_t *) "TCPA", 4);
-       sha1_final(&ctx, &msg[1 + SHA1_DIGEST_LENGTH]);
-       memset(&msg[1 + 2 * SHA1_DIGEST_LENGTH], 0x00,
-         msg_len - data_len - 2 * SHA1_DIGEST_LENGTH - 2);
-@@ -429,7 +430,7 @@ static int decode_message(int type, uint
-       mask_generation(&msg[1], SHA1_DIGEST_LENGTH,
-         &msg[1 + SHA1_DIGEST_LENGTH], msg_len - SHA1_DIGEST_LENGTH - 1)=
;
-       sha1_init(&ctx);
--      sha1_update(&ctx, "TCPA", 4);
-+      sha1_update(&ctx, (uint8_t *) "TCPA", 4);
-       sha1_final(&ctx, &msg[1]);
-       if (memcmp(&msg[1], &msg[1 + SHA1_DIGEST_LENGTH],
-           SHA1_DIGEST_LENGTH) !=3D 0) return -1;
-diff -uprN orig/tpm_emulator-0.4/linux_module.c tpm_emulator/linux_modul=
e.c
---- orig/tpm_emulator-0.4/linux_module.c    2006-06-23
03:37:07.000000000 -0700
-+++ tpm_emulator/linux_module.c    1969-12-31 16:00:00.000000000 -0800
-@@ -1,195 +0,0 @@
--/* Software-Based Trusted Platform Module (TPM) Emulator for Linux
-- * Copyright (C) 2004 Mario Strasser <mast@gmx.net>,
-- *
-- * This module 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.=20
-- *
-- * This module 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.
-- *
-- * $Id: linux_module.c 91 2006-03-13 13:51:41Z mast $
-- */
--
--#include <linux/module.h>
--#include <linux/kernel.h>
--#include <linux/init.h>
--#include <linux/miscdevice.h>
--#include <linux/poll.h>
--#include "linux_module.h"
--#include "tpm/tpm_emulator.h"
--
--MODULE_LICENSE("GPL");
--MODULE_AUTHOR("Mario Strasser <mast@gmx.net>");
--MODULE_DESCRIPTION("Trusted Platform Module (TPM) Emulator");
--MODULE_SUPPORTED_DEVICE(TPM_DEVICE_NAME);
--
--/* module startup parameters */
--char *startup =3D "save";
--module_param(startup, charp, 0444);
--MODULE_PARM_DESC(startup, " Sets the startup mode of the TPM. "
--  "Possible values are 'clear', 'save' (default) and 'deactivated.");
--char *storage_file =3D "/var/tpm/tpm_emulator-1.2.0.2";
--module_param(storage_file, charp, 0644);
--MODULE_PARM_DESC(storage_file, " Sets the persistent-data storage "
--  "file of the TPM.");
--
--/* TPM lock */
--static struct semaphore tpm_mutex;
--
--/* TPM command response */
--static struct {
--  uint8_t *data;
--  uint32_t size;
--} tpm_response;
--
--/* module state */
--#define STATE_IS_OPEN 0
--static uint32_t module_state;
--static struct timespec old_time;
--
--static int tpm_open(struct inode *inode, struct file *file)
--{
--  debug("%s()", __FUNCTION__);
--  if (test_and_set_bit(STATE_IS_OPEN, (void*)&module_state)) return
-EBUSY;
--  return 0;
--}
--
--static int tpm_release(struct inode *inode, struct file *file)
--{
--  debug("%s()", __FUNCTION__);
--  clear_bit(STATE_IS_OPEN, (void*)&module_state);
--  down(&tpm_mutex);
--  if (tpm_response.data !=3D NULL) {
--    kfree(tpm_response.data);
--    tpm_response.data =3D NULL;
--  }
--  up(&tpm_mutex);
--  return 0;
--}
--
--static ssize_t tpm_read(struct file *file, char *buf, size_t count,
loff_t *ppos)
--{
--  debug("%s(%d)", __FUNCTION__, count);
--  down(&tpm_mutex);
--  if (tpm_response.data !=3D NULL) {
--    count =3D min(count, (size_t)tpm_response.size - (size_t)*ppos);
--    count -=3D copy_to_user(buf, &tpm_response.data[*ppos], count);
--    *ppos +=3D count;
--    if ((size_t)tpm_response.size =3D=3D (size_t)*ppos) {
--      kfree(tpm_response.data);
--      tpm_response.data =3D NULL;
--    }
--  } else {
--    count =3D 0;
--  }
--  up(&tpm_mutex);
--  return count;
--}
--
--static ssize_t tpm_write(struct file *file, const char *buf, size_t
count, loff_t *ppos)
--{
--  debug("%s(%d)", __FUNCTION__, count);
--  down(&tpm_mutex);
--  *ppos =3D 0;
--  if (tpm_response.data !=3D NULL) kfree(tpm_response.data);
--  if (tpm_handle_command(buf, count, &tpm_response.data,
--                         &tpm_response.size) !=3D 0) {
--    count =3D -EILSEQ;
--    tpm_response.data =3D NULL;
--  }
--  up(&tpm_mutex);
--  return count;
--}
--
--#define TPMIOC_CANCEL   _IO('T', 0x00)
--#define TPMIOC_TRANSMIT _IO('T', 0x01)
--
--static int tpm_ioctl(struct inode *inode, struct file *file, unsigned
int cmd, unsigned long arg)
--{
--  debug("%s(%d, %p)", __FUNCTION__, cmd, (char*)arg);
--  if (cmd =3D=3D TPMIOC_TRANSMIT) {
--    uint32_t count =3D ntohl(*(uint32_t*)(arg + 2));
--    down(&tpm_mutex);
--    if (tpm_response.data !=3D NULL) kfree(tpm_response.data);
--    if (tpm_handle_command((char*)arg, count, &tpm_response.data,
--                           &tpm_response.size) =3D=3D 0) {
--      tpm_response.size -=3D copy_to_user((char*)arg, tpm_response.data=
,
--                            tpm_response.size);
--      kfree(tpm_response.data);
--      tpm_response.data =3D NULL;
--    } else {
--      tpm_response.size =3D 0;
--      tpm_response.data =3D NULL;
--    }
--    up(&tpm_mutex);
--    return tpm_response.size;
--  }
--  return -1;
--}
--
--struct file_operations fops =3D {
--  .owner   =3D THIS_MODULE,
--  .open    =3D tpm_open,
--  .release =3D tpm_release,
--  .read    =3D tpm_read,
--  .write   =3D tpm_write,
--  .ioctl   =3D tpm_ioctl,
--};
--
--static struct miscdevice tpm_dev =3D {
--  .minor      =3D TPM_DEVICE_MINOR,
--  .name       =3D TPM_DEVICE_NAME,
--  .fops       =3D &fops,
--};
--
--int __init init_tpm_module(void)
--{
--  int res =3D misc_register(&tpm_dev);
--  if (res !=3D 0) {
--    error("misc_register() failed for minor %d\n", TPM_DEVICE_MINOR);
--    return res;
--  }
--  /* initialize variables */
--  sema_init(&tpm_mutex, 1);
--  module_state =3D 0;
--  tpm_response.data =3D NULL;
--  old_time =3D current_kernel_time();
--  /* initialize TPM emulator */
--  if (!strcmp(startup, "clear")) {
--    tpm_emulator_init(1);
--  } else if (!strcmp(startup, "save")) {
--    tpm_emulator_init(2);
--  } else if (!strcmp(startup, "deactivated")) {
--    tpm_emulator_init(3);
--  } else {
--    error("invalid startup mode '%s'; must be 'clear', "
--      "'save' (default) or 'deactivated", startup);
--    misc_deregister(&tpm_dev);
--    return -EINVAL;
--  }
--  return 0;
--}
--
--void __exit cleanup_tpm_module(void)
--{
--  tpm_emulator_shutdown();
--  misc_deregister(&tpm_dev);
--  if (tpm_response.data !=3D NULL) kfree(tpm_response.data);
--}
--
--module_init(init_tpm_module);
--module_exit(cleanup_tpm_module);
--
--uint64_t tpm_get_ticks(void)
--{
--  struct timespec new_time =3D current_kernel_time();
--  uint64_t ticks =3D (uint64_t)(new_time.tv_sec - old_time.tv_sec) * 10=
00000
--                   + (new_time.tv_nsec - old_time.tv_nsec) / 1000;
--  old_time =3D new_time;
--  return (ticks > 0) ? ticks : 1;
--}
--
-diff -uprN orig/tpm_emulator-0.4/linux_module.h tpm_emulator/linux_modul=
e.h
---- orig/tpm_emulator-0.4/linux_module.h    2006-06-23
03:37:07.000000000 -0700
-+++ tpm_emulator/linux_module.h    2006-07-24 14:35:35.000000000 -0700
-@@ -1,5 +1,6 @@
- /* Software-Based Trusted Platform Module (TPM) Emulator for Linux
-  * Copyright (C) 2004 Mario Strasser <mast@gmx.net>,
-+ * Copyright (C) 2005 INTEL Corp
-  *
-  * This module is free software; you can redistribute it and/or modify
-  * it under the terms of the GNU General Public License as published
-@@ -17,54 +18,62 @@
- #ifndef _LINUX_MODULE_H_
- #define _LINUX_MODULE_H_
-
--#include <linux/version.h>
--#include <linux/kernel.h>
--#include <linux/slab.h>
-+#include <malloc.h>
-+#include <stdint.h>
-+#include <stdio.h>
-+#include <string.h>
- #include <linux/types.h>
--#include <linux/string.h>
--#include <linux/random.h>
--#include <linux/time.h>
--#include <asm/byteorder.h>
-
--/* module settings */
-+#include <endian.h>
-+#define __BYTEORDER_HAS_U64__
-+#ifdef LITTLE_ENDIAN
-+ #include <linux/byteorder/little_endian.h>
-+#else
-+ #include <linux/byteorder/big_endian.h>
-+#endif
-
-+/* module settings */
-+#define min(A,B) ((A)<(B)?(A):(B))
-+#ifndef STR
- #define STR(s) __STR__(s)
- #define __STR__(s) #s
-+#endif
- #include "tpm_version.h"
-
- #define TPM_DEVICE_MINOR  224
- #define TPM_DEVICE_NAME   "tpm"
- #define TPM_MODULE_NAME   "tpm_emulator"
-
--/* debug and log output functions */
--
- #ifdef DEBUG
--#define debug(fmt, ...) printk(KERN_DEBUG "%s %s:%d: Debug: " fmt "\n",=
 \
--                        TPM_MODULE_NAME, __FILE__, __LINE__, ##
__VA_ARGS__)
-+#define debug(fmt, ...) printf("TPMD: %s:%d: Debug: " fmt "\n", \
-+                        __FILE__, __LINE__, ## __VA_ARGS__)
- #else
- #define debug(fmt, ...)
- #endif
--#define info(fmt, ...)  printk(KERN_INFO "%s %s:%d: Info: " fmt "\n", \=

--                        TPM_MODULE_NAME, __FILE__, __LINE__, ##
__VA_ARGS__)
--#define error(fmt, ...) printk(KERN_ERR "%s %s:%d: Error: " fmt "\n", \=

--                        TPM_MODULE_NAME, __FILE__, __LINE__, ##
__VA_ARGS__)
--#define alert(fmt, ...) printk(KERN_ALERT "%s %s:%d: Alert: " fmt "\n",=
 \
--                        TPM_MODULE_NAME, __FILE__, __LINE__, ##
__VA_ARGS__)
-+#define info(fmt, ...)  printf("TPMD: %s:%d: Info: " fmt "\n", \
-+                        __FILE__, __LINE__, ## __VA_ARGS__)
-+#define error(fmt, ...) printf("TPMD: %s:%d: Error: " fmt "\n", \
-+                        __FILE__, __LINE__, ## __VA_ARGS__)
-+#define alert(fmt, ...) printf("TPMD: %s:%d: Alert: " fmt "\n", \
-+                        __FILE__, __LINE__, ## __VA_ARGS__)
-
- /* memory allocation */
-
- static inline void *tpm_malloc(size_t size)
- {
--  return kmalloc(size, GFP_KERNEL);=20
-+  return malloc(size);=20
- }
-
- static inline void tpm_free(const void *ptr)
- {
--  if (ptr !=3D NULL) kfree(ptr);
-+  if (ptr !=3D NULL) free( (void *) ptr);
- }
-
- /* random numbers */
-
-+//FIXME;
-+void get_random_bytes(void *buf, int nbytes);
-+
- static inline void tpm_get_random_bytes(void *buf, int nbytes)
- {
-   get_random_bytes(buf, nbytes);
-@@ -84,9 +93,9 @@ uint64_t tpm_get_ticks(void);
- #define CPU_TO_LE16(x) __cpu_to_le16(x)
-
- #define BE64_TO_CPU(x) __be64_to_cpu(x)
--#define LE64_TO_CPU(x) __be64_to_cpu(x)
-+#define LE64_TO_CPU(x) __le64_to_cpu(x)
- #define BE32_TO_CPU(x) __be32_to_cpu(x)
--#define LE32_TO_CPU(x) __be32_to_cpu(x)
-+#define LE32_TO_CPU(x) __le32_to_cpu(x)
- #define BE16_TO_CPU(x) __be16_to_cpu(x)
- #define LE16_TO_CPU(x) __le16_to_cpu(x)
-
-diff -uprN orig/tpm_emulator-0.4/Makefile tpm_emulator/Makefile
---- orig/tpm_emulator-0.4/Makefile    2006-06-23 03:37:07.000000000 -070=
0
-+++ tpm_emulator/Makefile    2006-07-24 14:35:35.000000000 -0700
-@@ -1,24 +1,40 @@
- # Software-Based Trusted Platform Module (TPM) Emulator for Linux
- # Copyright (C) 2004 Mario Strasser <mast@gmx.net>
-+# Copyright (C) 2006 INTEL Corp.
- #
- # $Id: Makefile 115 2006-06-23 10:36:44Z mast $
-
--# kernel settings
--KERNEL_RELEASE :=3D $(shell uname -r)
--KERNEL_BUILD   :=3D /lib/modules/$(KERNEL_RELEASE)/build
--MOD_SUBDIR     :=3D misc
-+COMPILE_ARCH    ?=3D $(shell uname -m | sed -e s/i.86/x86_32/)
-
- # module settings
--MODULE_NAME    :=3D tpm_emulator
-+BIN            :=3D tpm_emulator
- VERSION_MAJOR  :=3D 0
- VERSION_MINOR  :=3D 4
- VERSION_BUILD  :=3D $(shell date +"%s")
-
--# enable/disable DEBUG messages
--EXTRA_CFLAGS   +=3D -Wall -DDEBUG -g=20
-+# Installation program and options
-+INSTALL         =3D install
-+INSTALL_PROG    =3D $(INSTALL) -m0755
-+INSTALL_DIR     =3D $(INSTALL) -d -m0755
-+
-+# Xen tools installation directory
-+TOOLS_INSTALL_DIR =3D $(DESTDIR)/usr/bin
-+
-+CC      :=3D gcc
-+CFLAGS  +=3D -g -Wall $(INCLUDE) -DDEBUG
-+CFLAGS  +=3D -I. -Itpm
-+
-+# Is the simulator running in it's own vm?
-+#CFLAGS +=3D -DVTPM_MULTI_VM
-+
-+ifeq ($(COMPILE_ARCH),x86_64)
-+LIBDIR =3D lib64
-+else
-+LIBDIR =3D lib
-+endif
-
- # GNU MP configuration
--GMP_LIB        :=3D /usr/lib/libgmp.a
-+GMP_LIB        :=3D /usr/$(LIBDIR)/libgmp.a
- GMP_HEADER     :=3D /usr/include/gmp.h
-
- # sources and objects
-@@ -27,38 +43,32 @@ DIRS           :=3D . crypto tpm
- SRCS           :=3D $(foreach dir, $(DIRS), $(wildcard $(src)/$(dir)/*.=
c))
- OBJS           :=3D $(patsubst %.c, %.o, $(SRCS))
- SRCS           +=3D $(foreach dir, $(DIRS), $(wildcard $(src)/$(dir)/*.=
h))
--DISTSRC        :=3D ./README ./AUTHORS ./ChangeLog ./Makefile $(SRCS)
--DISTDIR        :=3D tpm_emulator-$(VERSION_MAJOR).$(VERSION_MINOR)
-
--obj-m               :=3D $(MODULE_NAME).o
--$(MODULE_NAME)-objs :=3D $(patsubst $(src)/%.o, %.o, $(OBJS))
crypto/libgmp.a
-+obj-m               :=3D $(BIN)
-+$(BIN)-objs :=3D $(patsubst $(src)/%.o, %.o, $(OBJS)) crypto/libgmp.a
-
- EXTRA_CFLAGS   +=3D -I$(src) -I$(src)/crypto -I$(src)/tpm
-
- # do not print "Entering directory ..."
- MAKEFLAGS      +=3D --no-print-directory
-
--all:    $(src)/crypto/gmp.h $(src)/crypto/libgmp.a version
--    @$(MAKE) -C $(KERNEL_BUILD) M=3D$(CURDIR) modules
-+all: $(BIN)
-
--install:
--    @$(MAKE) -C $(KERNEL_BUILD) M=3D$(CURDIR) modules_install
--    test -d /var/tpm || mkdir /var/tpm
--    test -c /dev/tpm || mknod /dev/tpm c 10 224
--    chmod 666 /dev/tpm
--    depmod -a
-+$(BIN):    $(src)/crypto/gmp.h $(src)/crypto/libgmp.a version $(SRCS)
$(OBJS)
-+    $(CC) $(CFLAGS) $(OBJS) $(src)/crypto/libgmp.a -o $(BIN)
-+
-+%.o: %.c
-+    $(CC) $(CFLAGS) -c $< -o $@
-+
-+install: $(BIN)
-+    $(INSTALL_PROG) $(BIN) $(TOOLS_INSTALL_DIR)
-+    @if [ ! -d "/var/tpm" ]; then mkdir /var/tpm; fi
-
- clean:
--    @$(MAKE) -C $(KERNEL_BUILD) M=3D$(CURDIR) clean
--    rm -f $(src)/crypto/gmp.h $(src)/crypto/libgmp.a
-+    rm -f $(src)/crypto/gmp.h $(src)/crypto/libgmp.a $(OBJS)
-
--dist:    $(DISTSRC)
--    rm -rf $(DISTDIR)
--    mkdir $(DISTDIR)
--    cp --parents $(DISTSRC) $(DISTDIR)/
--    rm -f $(DISTDIR)/crypto/gmp.h
--    tar -chzf $(DISTDIR).tar.gz $(DISTDIR)
--    rm -rf $(DISTDIR)
-+mrproper: clean
-+    rm -f $(BIN) tpm_version.h
-
- $(src)/crypto/libgmp.a:
-     test -f $(src)/crypto/libgmp.a || ln -s $(GMP_LIB)
$(src)/crypto/libgmp.a
-@@ -88,4 +98,3 @@ version:
-     @echo "#endif /* _TPM_VERSION_H_ */" >> $(src)/tpm_version.h
-
- .PHONY: all install clean dist gmp version
--
-diff -uprN orig/tpm_emulator-0.4/README tpm_emulator/README
---- orig/tpm_emulator-0.4/README    2006-06-23 03:37:07.000000000 -0700
-+++ tpm_emulator/README    2006-07-24 14:35:35.000000000 -0700
-@@ -13,7 +13,8 @@ $Id: README 113 2006-06-18 12:38:13Z hst
- Copyright
- -----------------------------------------------------------------------=
---
- Copyright (C) 2004 Mario Strasser <mast@gmx.net> and Swiss Federal
--Institute of Technology (ETH) Zurich.
-+                   Institute of Technology (ETH) Zurich.
-+Copyright (C) 2005 INTEL Corp
-             =20
- 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
-@@ -43,6 +44,12 @@ Example:
- GMP_LIB        :=3D /usr/lib/libgmp.a
- GMP_HEADER     :=3D /usr/include/gmp.h
-
-+GNU MP Library on 64 bit Systems
-+-----------------------------------------------------------------------=
---
-+Some 64-bit kernels have problems with importing the user-space gmp
-+library (/usr/lib*/libgmp.a) into kernel space.  These kernels will
require
-+that the gmp library be recompiled for kernel space with -mcmodel=3Dker=
nel.
-+
- Installation
- -----------------------------------------------------------------------=
---
- The compilation and installation process uses the build environment for=

-diff -uprN orig/tpm_emulator-0.4/tpm/tpm_capability.c
tpm_emulator/tpm/tpm_capability.c
---- orig/tpm_emulator-0.4/tpm/tpm_capability.c    2006-06-23
19:37:07.000000000 +0900
-+++ tpm_emulator/tpm/tpm_capability.c    2007-12-28 22:50:19.000000000
+0900
-@@ -701,7 +701,10 @@ TPM_RESULT TPM_GetCapabilityOwner(TPM_VE
-   TPM_RESULT res;
- =20
-   info("TPM_GetCapabilityOwner()");
--=20
-+
-+  if (!tpmData.permanent.flags.owned) {
-+    return TPM_NOSRK;
-+  }
-   /* Verify owner authorization */
-   res =3D tpm_verify_auth(auth1, tpmData.permanent.data.ownerAuth,
TPM_KH_OWNER);
-   if (res !=3D TPM_SUCCESS) return res;
-diff -uprN orig/tpm_emulator-0.4/tpm/tpm_cmd_handler.c
tpm_emulator/tpm/tpm_cmd_handler.c
---- orig/tpm_emulator-0.4/tpm/tpm_cmd_handler.c    2006-06-23
19:37:07.000000000 +0900
-+++ tpm_emulator/tpm/tpm_cmd_handler.c    2007-09-12 20:23:00.000000000
+0900
-@@ -565,7 +565,7 @@ static TPM_RESULT execute_TPM_Seal(TPM_R
-   if (tpm_unmarshal_TPM_KEY_HANDLE(&ptr, &len, &keyHandle)
-       || tpm_unmarshal_TPM_ENCAUTH(&ptr, &len, &encAuth)
-       || tpm_unmarshal_UINT32(&ptr, &len, &pcrInfoSize)
--      || tpm_unmarshal_TPM_PCR_INFO(&ptr, &len, &pcrInfo)
-+      || (pcrInfoSize >0 && tpm_unmarshal_TPM_PCR_INFO(&ptr, &len,
&pcrInfo))
-       || tpm_unmarshal_UINT32(&ptr, &len, &inDataSize)
-       || tpm_unmarshal_BLOB(&ptr, &len, &inData, inDataSize)
-       || len !=3D 0) return TPM_BAD_PARAMETER;
-@@ -798,7 +798,7 @@ static TPM_RESULT execute_TPM_Sealx(TPM_
-   if (tpm_unmarshal_TPM_KEY_HANDLE(&ptr, &len, &keyHandle)
-       || tpm_unmarshal_TPM_ENCAUTH(&ptr, &len, &encAuth)
-       || tpm_unmarshal_UINT32(&ptr, &len, &pcrInfoSize)
--      || tpm_unmarshal_TPM_PCR_INFO(&ptr, &len, &pcrInfo)
-+      || (pcrInfoSize > 0 && tpm_unmarshal_TPM_PCR_INFO(&ptr, &len,
&pcrInfo))
-       || tpm_unmarshal_UINT32(&ptr, &len, &inDataSize)
-       || tpm_unmarshal_BLOB(&ptr, &len, &inData, inDataSize)
-       || len !=3D 0) return TPM_BAD_PARAMETER;
-diff -uprN orig/tpm_emulator-0.4/tpm/tpm_credentials.c
tpm_emulator/tpm/tpm_credentials.c
---- orig/tpm_emulator-0.4/tpm/tpm_credentials.c    2006-06-23
19:37:07.000000000 +0900
-+++ tpm_emulator/tpm/tpm_credentials.c    2007-09-12 20:23:30.000000000
+0900
-@@ -47,20 +47,20 @@ int tpm_compute_pubkey_checksum(TPM_NONC
-
- TPM_RESULT tpm_get_pubek(TPM_PUBKEY *pubEndorsementKey)
- {
--  UINT32 key_length;
-+  size_t key_length;
-   if (!tpmData.permanent.data.endorsementKey.size) return
TPM_NO_ENDORSEMENT;
-   /* setup TPM_PUBKEY structure */
--  key_length =3D tpmData.permanent.data.endorsementKey.size;
--  pubEndorsementKey->pubKey.keyLength =3D key_length >> 3;
-+  pubEndorsementKey->pubKey.keyLength =3D
tpmData.permanent.data.endorsementKey.size >> 3;
-   pubEndorsementKey->pubKey.key =3D
tpm_malloc(pubEndorsementKey->pubKey.keyLength);
-   if (pubEndorsementKey->pubKey.key =3D=3D NULL) return TPM_FAIL;
-   rsa_export_modulus(&tpmData.permanent.data.endorsementKey,
--    pubEndorsementKey->pubKey.key,
--    &pubEndorsementKey->pubKey.keyLength);
-+             pubEndorsementKey->pubKey.key,
-+             &key_length);
-+  pubEndorsementKey->pubKey.keyLength =3D key_length;
-   pubEndorsementKey->algorithmParms.algorithmID =3D TPM_ALG_RSA;
-   pubEndorsementKey->algorithmParms.encScheme =3D
TPM_ES_RSAESOAEP_SHA1_MGF1;
-   pubEndorsementKey->algorithmParms.sigScheme =3D TPM_SS_NONE;
--  pubEndorsementKey->algorithmParms.parms.rsa.keyLength =3D key_length;=

-+  pubEndorsementKey->algorithmParms.parms.rsa.keyLength =3D key_length =
<< 3;
-   pubEndorsementKey->algorithmParms.parms.rsa.numPrimes =3D 2;
-   pubEndorsementKey->algorithmParms.parms.rsa.exponentSize =3D 0;
-   pubEndorsementKey->algorithmParms.parms.rsa.exponent =3D NULL;
-@@ -175,6 +175,7 @@ TPM_RESULT TPM_OwnerReadInternalPub(TPM_
- {
-   TPM_RESULT res;
-   TPM_KEY_DATA *srk =3D &tpmData.permanent.data.srk;
-+  size_t key_length;
-   info("TPM_OwnerReadInternalPub()");
-   /* verify authorization */
-   res =3D tpm_verify_auth(auth1, tpmData.permanent.data.ownerAuth,
TPM_KH_OWNER);
-@@ -186,7 +187,8 @@ TPM_RESULT TPM_OwnerReadInternalPub(TPM_
-     publicPortion->pubKey.key =3D
tpm_malloc(publicPortion->pubKey.keyLength);
-     if (publicPortion->pubKey.key =3D=3D NULL) return TPM_FAIL;
-     rsa_export_modulus(&srk->key, publicPortion->pubKey.key,
--      &publicPortion->pubKey.keyLength);
-+      &key_length);
-+    publicPortion->pubKey.keyLength =3D key_length;
-     publicPortion->algorithmParms.algorithmID =3D TPM_ALG_RSA;
-     publicPortion->algorithmParms.encScheme =3D srk->encScheme;
-     publicPortion->algorithmParms.sigScheme =3D srk->sigScheme;
-diff -uprN orig/tpm_emulator-0.4/tpm/tpm_crypto.c
tpm_emulator/tpm/tpm_crypto.c
---- orig/tpm_emulator-0.4/tpm/tpm_crypto.c    2006-06-23
03:37:07.000000000 -0700
-+++ tpm_emulator/tpm/tpm_crypto.c    2006-07-24 14:35:35.000000000 -0700=

-@@ -182,7 +182,8 @@ TPM_RESULT TPM_CertifyKey(TPM_KEY_HANDLE
-   TPM_KEY_DATA *cert, *key;
-   sha1_ctx_t sha1_ctx;
-   BYTE *buf, *p;
--  UINT32 length;
-+  UINT32 length32;
-+  size_t length;
-   info("TPM_CertifyKey()");
-   /* get keys */
-   cert =3D tpm_get_key(certHandle);
-@@ -264,14 +265,15 @@ TPM_RESULT TPM_CertifyKey(TPM_KEY_HANDLE
-   /* compute the digest of the CERTIFY_INFO[2] structure and sign it */=

-   length =3D sizeof_TPM_CERTIFY_INFO((*certifyInfo));
-   p =3D buf =3D tpm_malloc(length);
-+  length32=3D(UINT32) length;
-   if (buf =3D=3D NULL
--      || tpm_marshal_TPM_CERTIFY_INFO(&p, &length, certifyInfo)) {
-+      || tpm_marshal_TPM_CERTIFY_INFO(&p, &length32, certifyInfo)) {
-     free_TPM_KEY_PARMS(certifyInfo->algorithmParms);
-     return TPM_FAIL;
-   }
-   length =3D sizeof_TPM_CERTIFY_INFO((*certifyInfo));
-   sha1_init(&sha1_ctx);
--  sha1_update(&sha1_ctx, buf, length);
-+  sha1_update(&sha1_ctx, buf, (size_t) length);
-   sha1_final(&sha1_ctx, buf);
-   res =3D tpm_sign(cert, auth1, FALSE, buf, SHA1_DIGEST_LENGTH, outData=
,
outDataSize);
-   tpm_free(buf);
-@@ -292,7 +294,8 @@ TPM_RESULT TPM_CertifyKey2(TPM_KEY_HANDL
-   TPM_KEY_DATA *cert, *key;
-   sha1_ctx_t sha1_ctx;
-   BYTE *buf, *p;
--  UINT32 length;
-+  size_t length;
-+  UINT32 length32;
-   info("TPM_CertifyKey2()");
-   /* get keys */
-   cert =3D tpm_get_key(certHandle);
-@@ -362,8 +365,9 @@ TPM_RESULT TPM_CertifyKey2(TPM_KEY_HANDL
-   /* compute the digest of the CERTIFY_INFO[2] structure and sign it */=

-   length =3D sizeof_TPM_CERTIFY_INFO((*certifyInfo));
-   p =3D buf =3D tpm_malloc(length);
-+  length32 =3D (UINT32) length;
-   if (buf =3D=3D NULL
--      || tpm_marshal_TPM_CERTIFY_INFO(&p, &length, certifyInfo)) {
-+      || tpm_marshal_TPM_CERTIFY_INFO(&p, &length32, certifyInfo)) {
-     free_TPM_KEY_PARMS(certifyInfo->algorithmParms);
-     return TPM_FAIL;
-   }
-diff -uprN orig/tpm_emulator-0.4/tpm/tpm_daa.c tpm_emulator/tpm/tpm_daa.=
c
---- orig/tpm_emulator-0.4/tpm/tpm_daa.c    2006-06-23
03:37:07.000000000 -0700
-+++ tpm_emulator/tpm/tpm_daa.c    2006-07-24 14:35:35.000000000 -0700
-@@ -716,14 +716,14 @@ TPM_RESULT TPM_DAA_Join(TPM_HANDLE handl
-           sizeof(session->DAA_tpmSpecific.DAA_rekey));
-       sha1_update(&sha1, (BYTE*) &session->DAA_tpmSpecific.DAA_count,
-           sizeof(session->DAA_tpmSpecific.DAA_count));
--      sha1_update(&sha1, "\x00", 1);
-+      sha1_update(&sha1, (BYTE *) "\x00", 1);
-       sha1_final(&sha1, scratch);
-       sha1_init(&sha1);
-       sha1_update(&sha1, (BYTE*) &session->DAA_tpmSpecific.DAA_rekey,
-           sizeof(session->DAA_tpmSpecific.DAA_rekey));
-       sha1_update(&sha1, (BYTE*) &session->DAA_tpmSpecific.DAA_count,
-           sizeof(session->DAA_tpmSpecific.DAA_count));
--      sha1_update(&sha1, "\x01", 1);
-+      sha1_update(&sha1, (BYTE *) "\x01", 1);
-       sha1_final(&sha1, scratch + SHA1_DIGEST_LENGTH);
-       mpz_init(f), mpz_init(q);
-       mpz_import(f, 2 * SHA1_DIGEST_LENGTH, 1, 1, 0, 0, scratch);
-@@ -805,14 +805,14 @@ TPM_RESULT TPM_DAA_Join(TPM_HANDLE handl
-           sizeof(session->DAA_tpmSpecific.DAA_rekey));
-       sha1_update(&sha1, (BYTE*) &session->DAA_tpmSpecific.DAA_count,
-           sizeof(session->DAA_tpmSpecific.DAA_count));
--      sha1_update(&sha1, "\x00", 1);
-+      sha1_update(&sha1, (BYTE *) "\x00", 1);
-       sha1_final(&sha1, scratch);
-       sha1_init(&sha1);
-       sha1_update(&sha1, (BYTE*) &session->DAA_tpmSpecific.DAA_rekey,
-           sizeof(session->DAA_tpmSpecific.DAA_rekey));
-       sha1_update(&sha1, (BYTE*) &session->DAA_tpmSpecific.DAA_count,
-           sizeof(session->DAA_tpmSpecific.DAA_count));
--      sha1_update(&sha1, "\x01", 1);
-+      sha1_update(&sha1, (BYTE *) "\x01", 1);
-       sha1_final(&sha1, scratch + SHA1_DIGEST_LENGTH);
-       mpz_init(f), mpz_init(q);
-       mpz_import(f, 2 * SHA1_DIGEST_LENGTH, 1, 1, 0, 0, scratch);
-@@ -1489,14 +1489,14 @@ TPM_RESULT TPM_DAA_Join(TPM_HANDLE handl
-           sizeof(session->DAA_tpmSpecific.DAA_rekey));
-       sha1_update(&sha1, (BYTE*) &session->DAA_tpmSpecific.DAA_count,
-           sizeof(session->DAA_tpmSpecific.DAA_count));
--      sha1_update(&sha1, "\x00", 1);
-+      sha1_update(&sha1, (BYTE *) "\x00", 1);
-       sha1_final(&sha1, scratch);
-       sha1_init(&sha1);
-       sha1_update(&sha1, (BYTE*) &session->DAA_tpmSpecific.DAA_rekey,
-           sizeof(session->DAA_tpmSpecific.DAA_rekey));
-       sha1_update(&sha1, (BYTE*) &session->DAA_tpmSpecific.DAA_count,
-           sizeof(session->DAA_tpmSpecific.DAA_count));
--      sha1_update(&sha1, "\x01", 1);
-+      sha1_update(&sha1, (BYTE *) "\x01", 1);
-       sha1_final(&sha1, scratch + SHA1_DIGEST_LENGTH);
-       mpz_init(f), mpz_init(q);
-       mpz_import(f, 2 * SHA1_DIGEST_LENGTH, 1, 1, 0, 0, scratch);
-@@ -1712,14 +1712,14 @@ TPM_RESULT TPM_DAA_Join(TPM_HANDLE handl
-           sizeof(session->DAA_tpmSpecific.DAA_rekey));
-       sha1_update(&sha1, (BYTE*) &session->DAA_tpmSpecific.DAA_count,
-           sizeof(session->DAA_tpmSpecific.DAA_count));
--      sha1_update(&sha1, "\x00", 1);
-+      sha1_update(&sha1, (BYTE *) "\x00", 1);
-       sha1_final(&sha1, scratch);
-       sha1_init(&sha1);
-       sha1_update(&sha1, (BYTE*) &session->DAA_tpmSpecific.DAA_rekey,
-           sizeof(session->DAA_tpmSpecific.DAA_rekey));
-       sha1_update(&sha1, (BYTE*) &session->DAA_tpmSpecific.DAA_count,
-           sizeof(session->DAA_tpmSpecific.DAA_count));
--      sha1_update(&sha1, "\x01", 1);
-+      sha1_update(&sha1, (BYTE *) "\x01", 1);
-       sha1_final(&sha1, scratch + SHA1_DIGEST_LENGTH);
-       mpz_init(f), mpz_init(q);
-       mpz_import(f, 2 * SHA1_DIGEST_LENGTH, 1, 1, 0, 0, scratch);
-@@ -1793,14 +1793,14 @@ TPM_RESULT TPM_DAA_Join(TPM_HANDLE handl
-           sizeof(session->DAA_tpmSpecific.DAA_rekey));
-       sha1_update(&sha1, (BYTE*) &session->DAA_tpmSpecific.DAA_count,
-           sizeof(session->DAA_tpmSpecific.DAA_count));
--      sha1_update(&sha1, "\x00", 1);
-+      sha1_update(&sha1, (BYTE *) "\x00", 1);
-       sha1_final(&sha1, scratch);
-       sha1_init(&sha1);
-       sha1_update(&sha1, (BYTE*) &session->DAA_tpmSpecific.DAA_rekey,
-           sizeof(session->DAA_tpmSpecific.DAA_rekey));
-       sha1_update(&sha1, (BYTE*) &session->DAA_tpmSpecific.DAA_count,
-           sizeof(session->DAA_tpmSpecific.DAA_count));
--      sha1_update(&sha1, "\x01", 1);
-+      sha1_update(&sha1, (BYTE *) "\x01", 1);
-       sha1_final(&sha1, scratch + SHA1_DIGEST_LENGTH);
-       mpz_init(f), mpz_init(q);
-       mpz_import(f, 2 * SHA1_DIGEST_LENGTH, 1, 1, 0, 0, scratch);
-@@ -2918,14 +2918,14 @@ TPM_RESULT TPM_DAA_Sign(TPM_HANDLE handl
-           sizeof(session->DAA_tpmSpecific.DAA_rekey));
-       sha1_update(&sha1, (BYTE*) &session->DAA_tpmSpecific.DAA_count,
-           sizeof(session->DAA_tpmSpecific.DAA_count));
--      sha1_update(&sha1, "\x00", 1);
-+      sha1_update(&sha1, (BYTE *) "\x00", 1);
-       sha1_final(&sha1, scratch);
-       sha1_init(&sha1);
-       sha1_update(&sha1, (BYTE*) &session->DAA_tpmSpecific.DAA_rekey,
-           sizeof(session->DAA_tpmSpecific.DAA_rekey));
-       sha1_update(&sha1, (BYTE*) &session->DAA_tpmSpecific.DAA_count,
-           sizeof(session->DAA_tpmSpecific.DAA_count));
--      sha1_update(&sha1, "\x01", 1);
-+      sha1_update(&sha1, (BYTE *) "\x01", 1);
-       sha1_final(&sha1, scratch + SHA1_DIGEST_LENGTH);
-       mpz_init(f), mpz_init(q);
-       mpz_import(f, 2 * SHA1_DIGEST_LENGTH, 1, 1, 0, 0, scratch);
-@@ -3143,7 +3143,7 @@ TPM_RESULT TPM_DAA_Sign(TPM_HANDLE handl
-         sha1_init(&sha1);
-         sha1_update(&sha1, (BYTE*) &session->DAA_session.DAA_digest,
-           sizeof(session->DAA_session.DAA_digest));
--        sha1_update(&sha1, "\x01", 1);
-+        sha1_update(&sha1, (BYTE *) "\x01", 1);
-         sha1_update(&sha1, inputData1, inputSize1);
-         sha1_final(&sha1, (BYTE*) &session->DAA_session.DAA_digest);
-       }
-@@ -3172,7 +3172,7 @@ TPM_RESULT TPM_DAA_Sign(TPM_HANDLE handl
-         sha1_init(&sha1);
-         sha1_update(&sha1, (BYTE*) &session->DAA_session.DAA_digest,
-           sizeof(session->DAA_session.DAA_digest));
--        sha1_update(&sha1, "\x00", 1);
-+        sha1_update(&sha1, (BYTE*) "\x00", 1);
-         rsa_export_modulus(&aikData->key, scratch, &size);
-         sha1_update(&sha1, scratch, size);
-         sha1_final(&sha1, (BYTE*) &session->DAA_session.DAA_digest);
-@@ -3229,14 +3229,14 @@ TPM_RESULT TPM_DAA_Sign(TPM_HANDLE handl
-           sizeof(session->DAA_tpmSpecific.DAA_rekey));
-       sha1_update(&sha1, (BYTE*) &session->DAA_tpmSpecific.DAA_count,
-           sizeof(session->DAA_tpmSpecific.DAA_count));
--      sha1_update(&sha1, "\x00", 1);
-+      sha1_update(&sha1, (BYTE *) "\x00", 1);
-       sha1_final(&sha1, scratch);
-       sha1_init(&sha1);
-       sha1_update(&sha1, (BYTE*) &session->DAA_tpmSpecific.DAA_rekey,
-           sizeof(session->DAA_tpmSpecific.DAA_rekey));
-       sha1_update(&sha1, (BYTE*) &session->DAA_tpmSpecific.DAA_count,
-           sizeof(session->DAA_tpmSpecific.DAA_count));
--      sha1_update(&sha1, "\x01", 1);
-+      sha1_update(&sha1, (BYTE *) "\x01", 1);
-       sha1_final(&sha1, scratch + SHA1_DIGEST_LENGTH);
-       mpz_init(f), mpz_init(q);
-       mpz_import(f, 2 * SHA1_DIGEST_LENGTH, 1, 1, 0, 0, scratch);
-@@ -3309,14 +3309,14 @@ TPM_RESULT TPM_DAA_Sign(TPM_HANDLE handl
-           sizeof(session->DAA_tpmSpecific.DAA_rekey));
-       sha1_update(&sha1, (BYTE*) &session->DAA_tpmSpecific.DAA_count,
-           sizeof(session->DAA_tpmSpecific.DAA_count));
--      sha1_update(&sha1, "\x00", 1);
-+      sha1_update(&sha1, (BYTE *) "\x00", 1);
-       sha1_final(&sha1, scratch);
-       sha1_init(&sha1);
-       sha1_update(&sha1, (BYTE*) &session->DAA_tpmSpecific.DAA_rekey,
-           sizeof(session->DAA_tpmSpecific.DAA_rekey));
-       sha1_update(&sha1, (BYTE*) &session->DAA_tpmSpecific.DAA_count,
-           sizeof(session->DAA_tpmSpecific.DAA_count));
--      sha1_update(&sha1, "\x01", 1);
-+      sha1_update(&sha1, (BYTE *) "\x01", 1);
-       sha1_final(&sha1, scratch + SHA1_DIGEST_LENGTH);
-       mpz_init(f), mpz_init(q);
-       mpz_import(f, 2 * SHA1_DIGEST_LENGTH, 1, 1, 0, 0, scratch);
-diff -uprN orig/tpm_emulator-0.4/tpm/tpm_data.c tpm_emulator/tpm/tpm_dat=
a.c
---- orig/tpm_emulator-0.4/tpm/tpm_data.c    2006-06-23
03:37:07.000000000 -0700
-+++ tpm_emulator/tpm/tpm_data.c    2006-07-24 14:35:35.000000000 -0700
-@@ -40,6 +40,7 @@ static inline void init_pcr_attr(int pcr
- void tpm_init_data(void)
- {
-   /* endorsement key */
-+#ifndef TPM_GENERATE_EK
-   uint8_t ek_n[] =3D=20
"\xa8\xdb\xa9\x42\xa8\xf3\xb8\x06\x85\x90\x76\x93\xad\xf7"
-     "\x74\xec\x3f\xd3\x3d\x9d\xe8\x2e\xff\x15\xed\x0e\xce\x5f\x93"
-     "\x92\xeb\xd1\x96\x2b\x72\x18\x81\x79\x12\x9d\x9c\x40\xd7\x1a"
-@@ -77,6 +78,8 @@ void tpm_init_data(void)
-     "\xd1\xc0\x8b\x5b\xa2\x2e\xa7\x15\xca\x50\x75\x10\x48\x9c\x2b"
-     "\x18\xb9\x67\x8f\x5d\x64\xc3\x28\x9f\x2f\x16\x2f\x08\xda\x47"
-     "\xec\x86\x43\x0c\x80\x99\x07\x34\x0f";
-+#endif
-+
-   int i;
-   /* reset all data to NULL, FALSE or 0 */
-   memset(&tpmData, 0, sizeof(tpmData));
-@@ -152,44 +155,43 @@ void tpm_release_data(void)
-
- #ifdef TPM_STORE_TO_FILE
-
--#include <linux/fs.h>
--#include <linux/unistd.h>
--#include <asm/uaccess.h>
-+#include <sys/types.h>
-+#include <sys/stat.h>
-+#include <fcntl.h>
-+#include <unistd.h>
-
- #define TPM_STORAGE_FILE "/var/tpm/tpm_emulator-1.2."
STR(VERSION_MAJOR) "." STR(VERSION_MINOR)
-
- static int write_to_file(uint8_t *data, size_t data_length)
- {
-   int res;
--  struct file *fp;
--  mm_segment_t old_fs =3D get_fs();
--  fp =3D filp_open(TPM_STORAGE_FILE, O_WRONLY | O_TRUNC | O_CREAT,
S_IRUSR | S_IWUSR);
--  if (IS_ERR(fp)) return -1;
--  set_fs(get_ds());
--  res =3D fp->f_op->write(fp, data, data_length, &fp->f_pos);
--  set_fs(old_fs);
--  filp_close(fp, NULL);
-+  int fp;
-+  fp =3D open(TPM_STORAGE_FILE, O_WRONLY | O_TRUNC | O_CREAT, S_IRUSR |=

S_IWUSR);
-+  res =3D write(fp, data, data_length);
-+  close(fp);
-   return (res =3D=3D data_length) ? 0 : -1;
- }
-
- static int read_from_file(uint8_t **data, size_t *data_length)
- {
-   int res;
--  struct file *fp;
--  mm_segment_t old_fs =3D get_fs();
--  fp =3D filp_open(TPM_STORAGE_FILE, O_RDONLY, 0);
--  if (IS_ERR(fp)) return -1;
--  *data_length =3D (size_t)fp->f_dentry->d_inode->i_size;
--  /* *data_length =3D i_size_read(fp->f_dentry->d_inode); */
-+  int fp, file_status;
-+  struct stat file_info;
-+  fp =3D open(TPM_STORAGE_FILE, O_RDONLY, 0);
-+  file_status =3D fstat(fp, &file_info);
-+  if (file_status < 0) {
-+    close(fp);
-+    return -1;
-+  }
-+
-+  *data_length =3D file_info.st_size;
-   *data =3D tpm_malloc(*data_length);
-   if (*data =3D=3D NULL) {
--    filp_close(fp, NULL);
-+    close(fp);
-     return -1;
-   }
--  set_fs(get_ds());
--  res =3D fp->f_op->read(fp, *data, *data_length, &fp->f_pos);
--  set_fs(old_fs);
--  filp_close(fp, NULL);
-+  res =3D read(fp, *data, *data_length);
-+  close(fp);
-   if (res !=3D *data_length) {
-     tpm_free(*data);
-     return -1;
-@@ -216,23 +218,30 @@ static int read_from_file(uint8_t **data
- int tpm_store_permanent_data(void)
- {
-   uint8_t *buf, *ptr;
--  size_t buf_length, len;
-+  UINT32 buf_length, len;
-
-   /* marshal data */
--  buf_length =3D len =3D sizeof_TPM_STCLEAR_FLAGS(tpmData.stclear.flags=
)
--    + sizeof_TPM_PERMANENT_FLAGS(tpmData.permanent.flags) + 2
--    + sizeof_TPM_PERMANENT_DATA(tpmData.permanent.data);
-+  buf_length =3D len =3D 4 + sizeof_TPM_STCLEAR_FLAGS(tpmData.stclear.f=
lags)
-+    + sizeof_TPM_PERMANENT_FLAGS(tpmData.permanent.flags)
-+    + sizeof_TPM_STANY_FLAGS(tpmData.stany.flags) + 2
-+    + sizeof_TPM_STCLEAR_DATA(tpmData.stclear.data)
-+    + sizeof_TPM_PERMANENT_DATA(tpmData.permanent.data)
-+    + sizeof_TPM_STANY_DATA(tpmData.stany.data);
-   buf =3D ptr =3D tpm_malloc(buf_length);
-   if (buf =3D=3D NULL
-       || tpm_marshal_TPM_VERSION(&ptr, &len,
&tpmData.permanent.data.version)
-       || tpm_marshal_TPM_STCLEAR_FLAGS(&ptr, &len, &tpmData.stclear.fla=
gs)
-       || tpm_marshal_TPM_PERMANENT_FLAGS(&ptr, &len,
&tpmData.permanent.flags)
-+      || tpm_marshal_TPM_STANY_FLAGS(&ptr, &len, &tpmData.stany.flags)
-       || tpm_marshal_BOOL(&ptr, &len,
tpmData.permanent.flags.selfTestSucceeded)
-       || tpm_marshal_BOOL(&ptr, &len, tpmData.permanent.flags.owned)
--      || tpm_marshal_TPM_PERMANENT_DATA(&ptr, &len,
&tpmData.permanent.data)) {
-+      || tpm_marshal_TPM_STCLEAR_DATA(&ptr, &len, &tpmData.stclear.data=
)
-+      || tpm_marshal_TPM_PERMANENT_DATA(&ptr, &len,
&tpmData.permanent.data)
-+      || tpm_marshal_TPM_STANY_DATA(&ptr, &len, &tpmData.stany.data)) {=

-     tpm_free(buf);
-     return -1;
-   }
-+
-   if (write_to_file(buf, buf_length - len)) {
-     tpm_free(buf);
-     return -1;
-@@ -244,31 +253,36 @@ int tpm_store_permanent_data(void)
- int tpm_restore_permanent_data(void)
- {
-   uint8_t *buf, *ptr;
--  size_t buf_length, len;
-+  size_t buf_length;
-+  UINT32 len;
-   TPM_VERSION ver;
-
-   /* read data */
-   if (read_from_file(&buf, &buf_length)) return -1;
-   ptr =3D buf;
--  len =3D buf_length;
-+  len =3D (uint32_t) buf_length;
-   /* unmarshal data */
-   if (tpm_unmarshal_TPM_VERSION(&ptr, &len, &ver)
-       || memcmp(&ver, &tpmData.permanent.data.version,
sizeof(TPM_VERSION))
-       || tpm_unmarshal_TPM_STCLEAR_FLAGS(&ptr, &len,
&tpmData.stclear.flags)
-       || tpm_unmarshal_TPM_PERMANENT_FLAGS(&ptr, &len,
&tpmData.permanent.flags)
-+      || tpm_unmarshal_TPM_STANY_FLAGS(&ptr, &len, &tpmData.stany.flags=
)
-       || tpm_unmarshal_BOOL(&ptr, &len,
&tpmData.permanent.flags.selfTestSucceeded)
-       || tpm_unmarshal_BOOL(&ptr, &len, &tpmData.permanent.flags.owned)=

--      || tpm_unmarshal_TPM_PERMANENT_DATA(&ptr, &len,
&tpmData.permanent.data)) {
-+      || tpm_unmarshal_TPM_STCLEAR_DATA(&ptr, &len, &tpmData.stclear.da=
ta)
-+      || tpm_unmarshal_TPM_PERMANENT_DATA(&ptr, &len,
&tpmData.permanent.data)
-+      || tpm_unmarshal_TPM_STANY_DATA(&ptr, &len, &tpmData.stany.data))=
 {
-     tpm_free(buf);
-     return -1;
-   }
-+
-   tpm_free(buf);
-   return 0;
- }
-
- int tpm_erase_permanent_data(void)
- {
--  int res =3D write_to_file("", 0);
-+  int res =3D write_to_file((uint8_t *) "", 0);
-   return res;
- }
-
-diff -uprN orig/tpm_emulator-0.4/tpm/tpm_deprecated.c
tpm_emulator/tpm/tpm_deprecated.c
---- orig/tpm_emulator-0.4/tpm/tpm_deprecated.c    2006-06-23
03:37:07.000000000 -0700
-+++ tpm_emulator/tpm/tpm_deprecated.c    2006-07-24 14:35:35.000000000
-0700
-@@ -1,6 +1,7 @@
- /* Software-Based Trusted Platform Module (TPM) Emulator for Linux
-  * Copyright (C) 2004 Mario Strasser <mast@gmx.net>,
-  *                    Swiss Federal Institute of Technology (ETH) Zuric=
h
-+ * Copyright (C) 2005 INTEL Corp
-  *
-  * This module is free software; you can redistribute it and/or modify
-  * it under the terms of the GNU General Public License as published
-@@ -50,7 +51,7 @@ TPM_RESULT TPM_SaveKeyContext(TPM_KEY_HA
-   BYTE *ptr;
-   UINT32 len;
-   info("TPM_SaveKeyContext()");
--  res =3D TPM_SaveContext(keyHandle, TPM_RT_KEY, "SaveKeyContext..",
-+  res =3D TPM_SaveContext(keyHandle, TPM_RT_KEY, (BYTE*)"SaveKeyContext=
=2E.",
-                         keyContextSize, &contextBlob);
-   if (res !=3D TPM_SUCCESS) return res;
-   len =3D *keyContextSize;
-@@ -82,7 +83,7 @@ TPM_RESULT TPM_SaveAuthContext(TPM_AUTHH
-   BYTE *ptr;
-   UINT32 len;
-   info("TPM_SaveAuthContext()");
--  res =3D TPM_SaveContext(authHandle, TPM_RT_KEY, "SaveAuthContext.",
-+  res =3D TPM_SaveContext(authHandle, TPM_RT_KEY,
(BYTE*)"SaveAuthContext.",
-                         authContextSize, &contextBlob);
-   if (res !=3D TPM_SUCCESS) return res;
-   len =3D *authContextSize;
-diff -uprN orig/tpm_emulator-0.4/tpm/tpm_emulator.h
tpm_emulator/tpm/tpm_emulator.h
---- orig/tpm_emulator-0.4/tpm/tpm_emulator.h    2006-06-23
03:37:07.000000000 -0700
-+++ tpm_emulator/tpm/tpm_emulator.h    2006-07-24 14:35:35.000000000 -07=
00
-@@ -1,5 +1,6 @@
- /* Software-Based Trusted Platform Module (TPM) Emulator for Linux
-  * Copyright (C) 2004 Mario Strasser <mast@gmx.net>,
-+ * Copyright (C) 2005 INTEL Corp
-  *
-  * This module is free software; you can redistribute it and/or modify
-  * it under the terms of the GNU General Public License as published
-@@ -22,7 +23,8 @@
- /* TPM configuration */
- #define TPM_STORE_TO_FILE       1
- #undef  TPM_STRONG_PERSISTENCE
--#undef  TPM_GENERATE_EK
-+//#undef  TPM_GENERATE_EK
-+#define  TPM_GENERATE_EK
- #undef  TPM_GENERATE_SEED_DAA
-
- #define TPM_MANUFACTURER 0x4554485A /* 'ETHZ' */      =20
-diff -uprN orig/tpm_emulator-0.4/tpm/tpm_marshalling.c
tpm_emulator/tpm/tpm_marshalling.c
---- orig/tpm_emulator-0.4/tpm/tpm_marshalling.c    2006-06-23
03:37:07.000000000 -0700
-+++ tpm_emulator/tpm/tpm_marshalling.c    2006-07-24 14:35:35.000000000
-0700
-@@ -1312,7 +1312,7 @@ int tpm_unmarshal_TPM_STANY_FLAGS(BYTE *
-
- int tpm_marshal_RSA(BYTE **ptr, UINT32 *length, rsa_private_key_t *v)
- {
--  UINT32 m_len, e_len, q_len;
-+  size_t m_len, e_len, q_len;
-   if (*length < sizeof_RSA((*v))) return -1;
-   if (v->size > 0) {
-     rsa_export_modulus(v, &(*ptr)[6], &m_len);
-@@ -1460,6 +1460,66 @@ int tpm_unmarshal_TPM_PERMANENT_DATA(BYT
-   return 0;
- }
-
-+int tpm_marshal_TPM_STCLEAR_DATA(BYTE **ptr, UINT32 *length,
TPM_STCLEAR_DATA *v)
-+{
-+  if (tpm_marshal_TPM_STRUCTURE_TAG(ptr, length, v->tag)
-+    || tpm_marshal_TPM_NONCE(ptr, length, &v->contextNonceKey)
-+    || tpm_marshal_TPM_COUNT_ID(ptr, length, v->countID) ) return -1;
-+
-+  return 0;
-+}
-+
-+int tpm_unmarshal_TPM_STCLEAR_DATA(BYTE **ptr, UINT32 *length,
TPM_STCLEAR_DATA *v)
-+{
-+  if (tpm_unmarshal_TPM_STRUCTURE_TAG(ptr, length, &v->tag)
-+    || tpm_unmarshal_TPM_NONCE(ptr, length, &v->contextNonceKey)
-+    || tpm_unmarshal_TPM_COUNT_ID(ptr, length, &v->countID) ) return -1=
;
-+
-+  return 0;
-+}
-+
-+int tpm_marshal_TPM_STANY_DATA(BYTE **ptr, UINT32 *length,
TPM_STANY_DATA *v)
-+{
-+  UINT32 i;
-+  if (tpm_marshal_TPM_STRUCTURE_TAG(ptr, length, v->tag)
-+    || tpm_marshal_TPM_NONCE(ptr, length, &v->contextNonceSession)
-+    || tpm_marshal_TPM_DIGEST(ptr, length, &v->auditDigest)
-+    || tpm_marshal_BOOL(ptr, length, v->auditSession)
-+    || tpm_marshal_TPM_CURRENT_TICKS(ptr, length, &v->currentTicks)
-+    || tpm_marshal_UINT32(ptr, length, v->contextCount)
-+    || tpm_marshal_UINT32_ARRAY(ptr, length, v->contextList,
TPM_MAX_SESSION_LIST)) return -1;
-+  for (i =3D 0; i < TPM_MAX_SESSIONS; i++) {
-+    if (tpm_marshal_TPM_SESSION_DATA(ptr, length, &v->sessions[i]))
return -1;
-+  }
-+  for (i =3D 0; i < TPM_MAX_SESSIONS_DAA; i++) {
-+    if (tpm_marshal_TPM_DAA_SESSION_DATA(ptr, length,
&v->sessionsDAA[i])) return -1;
-+  }
-+  if (tpm_marshal_TPM_TRANSHANDLE(ptr, length, v->transExclusive))
return -1;
-+
-+  return 0;
-+}
-+
-+int tpm_unmarshal_TPM_STANY_DATA(BYTE **ptr, UINT32 *length,
TPM_STANY_DATA *v)
-+{
-+  UINT32 i;
-+  if (tpm_unmarshal_TPM_STRUCTURE_TAG(ptr, length, &v->tag)
-+    || tpm_unmarshal_TPM_NONCE(ptr, length, &v->contextNonceSession)
-+    || tpm_unmarshal_TPM_DIGEST(ptr, length, &v->auditDigest)
-+    || tpm_unmarshal_BOOL(ptr, length, &v->auditSession)
-+    || tpm_unmarshal_TPM_CURRENT_TICKS(ptr, length, &v->currentTicks)
-+    || tpm_unmarshal_UINT32(ptr, length, &v->contextCount)
-+    || tpm_unmarshal_UINT32_ARRAY(ptr, length, v->contextList,
TPM_MAX_SESSION_LIST)) return -1;
-+  for (i =3D 0; i < TPM_MAX_SESSIONS; i++) {
-+    if (tpm_unmarshal_TPM_SESSION_DATA(ptr, length, &v->sessions[i]))
return -1;
-+  }
-+  for (i =3D 0; i < TPM_MAX_SESSIONS_DAA; i++) {
-+    if (tpm_unmarshal_TPM_DAA_SESSION_DATA(ptr, length,
&v->sessionsDAA[i])) return -1;
-+  }
-+  if (tpm_unmarshal_TPM_TRANSHANDLE(ptr, length, &v->transExclusive))
return -1;
-+
-+  return 0;
-+}
-+
- int tpm_marshal_TPM_SESSION_DATA(BYTE **ptr, UINT32 *length,
TPM_SESSION_DATA *v)
- {
-   if (tpm_marshal_BYTE(ptr, length, v->type)
-diff -uprN orig/tpm_emulator-0.4/tpm/tpm_marshalling.h
tpm_emulator/tpm/tpm_marshalling.h
---- orig/tpm_emulator-0.4/tpm/tpm_marshalling.h    2006-06-23
03:37:07.000000000 -0700
-+++ tpm_emulator/tpm/tpm_marshalling.h    2006-07-24 14:35:35.000000000
-0700
-@@ -432,6 +432,12 @@ int tpm_unmarshal_TPM_KEY_DATA(BYTE **pt
- int tpm_marshal_TPM_PERMANENT_DATA(BYTE **ptr, UINT32 *length,
TPM_PERMANENT_DATA *);
- int tpm_unmarshal_TPM_PERMANENT_DATA(BYTE **ptr, UINT32 *length,
TPM_PERMANENT_DATA *);
-
-+int tpm_marshal_TPM_STCLEAR_DATA(BYTE **ptr, UINT32 *length,
TPM_STCLEAR_DATA *v);
-+int tpm_unmarshal_TPM_STCLEAR_DATA(BYTE **ptr, UINT32 *length,
TPM_STCLEAR_DATA *v);
-+
-+int tpm_marshal_TPM_STANY_DATA(BYTE **ptr, UINT32 *length,
TPM_STANY_DATA *v);
-+int tpm_unmarshal_TPM_STANY_DATA(BYTE **ptr, UINT32 *length,
TPM_STANY_DATA *v);
-+
- int tpm_marshal_TPM_SESSION_DATA(BYTE **ptr, UINT32 *length,
TPM_SESSION_DATA *v);
- int tpm_unmarshal_TPM_SESSION_DATA(BYTE **ptr, UINT32 *length,
TPM_SESSION_DATA *v);
-
-diff -uprN orig/tpm_emulator-0.4/tpm/tpm_owner.c
tpm_emulator/tpm/tpm_owner.c
---- orig/tpm_emulator-0.4/tpm/tpm_owner.c    2006-06-23
03:37:07.000000000 -0700
-+++ tpm_emulator/tpm/tpm_owner.c    2006-07-24 14:35:35.000000000 -0700
-@@ -108,7 +108,7 @@ TPM_RESULT TPM_TakeOwnership(TPM_PROTOCO
-   TPM_RESULT res;
-   rsa_private_key_t *ek =3D &tpmData.permanent.data.endorsementKey;
-   TPM_KEY_DATA *srk =3D &tpmData.permanent.data.srk;
--  UINT32 buf_size =3D ek->size >> 3;
-+  size_t buf_size =3D ek->size >> 3, key_length;
-   BYTE buf[buf_size];
-
-   info("TPM_TakeOwnership()");
-@@ -173,7 +173,8 @@ TPM_RESULT TPM_TakeOwnership(TPM_PROTOCO
-     return TPM_FAIL;
-   }
-   rsa_export_modulus(&srk->key, srkPub->pubKey.key,
--    &srkPub->pubKey.keyLength);
-+             &key_length);
-+  srkPub->pubKey.keyLength =3D (UINT32) key_length;
-   /* setup tpmProof and set state to owned */
-   tpm_get_random_bytes(tpmData.permanent.data.tpmProof.nonce,
-     sizeof(tpmData.permanent.data.tpmProof.nonce));
-diff -uprN orig/tpm_emulator-0.4/tpm/tpm_startup.c
tpm_emulator/tpm/tpm_startup.c
---- orig/tpm_emulator-0.4/tpm/tpm_startup.c    2006-06-23
03:37:07.000000000 -0700
-+++ tpm_emulator/tpm/tpm_startup.c    2006-07-24 14:35:35.000000000 -070=
0
-@@ -41,26 +41,29 @@ void TPM_Init(TPM_STARTUP_TYPE startupTy
- TPM_RESULT TPM_Startup(TPM_STARTUP_TYPE startupType)
- {
-   int i;
-+  int restore_fail;
-   info("TPM_Startup(%d)", startupType);
-   if (tpmData.stany.flags.postInitialise =3D=3D FALSE) return
TPM_INVALID_POSTINIT;
--  /* reset STANY_FLAGS */
--  SET_TO_ZERO(&tpmData.stany.flags);
--  tpmData.stany.flags.tag =3D TPM_TAG_STANY_FLAGS;
--  /* reset STANY_DATA (invalidates ALL sessions) */
--  SET_TO_ZERO(&tpmData.stany.data);
--  tpmData.stany.data.tag =3D TPM_TAG_STANY_DATA;
--  /* init session-context nonce */
--  SET_TO_RAND(&tpmData.stany.data.contextNonceSession);
-+
-+  /* try and restore state to get EK, SRK, etc */
-+  restore_fail =3D tpm_restore_permanent_data();
-+
-   /* set data and flags according to the given startup type */
-   if (startupType =3D=3D TPM_ST_CLEAR) {
--    /* if available, restore permanent data */
--    tpm_restore_permanent_data();
-+    /* reset STANY_FLAGS */
-+    SET_TO_ZERO(&tpmData.stany.flags);
-+    tpmData.stany.flags.tag =3D TPM_TAG_STANY_FLAGS;
-+    /* reset STANY_DATA (invalidates ALL sessions) */
-+    SET_TO_ZERO(&tpmData.stany.data);
-+    tpmData.stany.data.tag =3D TPM_TAG_STANY_DATA;
-+    /* init session-context nonce */
-+    SET_TO_RAND(&tpmData.stany.data.contextNonceSession);
-     /* reset PCR values */
-     for (i =3D 0; i < TPM_NUM_PCR; i++) {
--      if (tpmData.permanent.data.pcrAttrib[i].pcrReset)
--        SET_TO_ZERO(tpmData.permanent.data.pcrValue[i].digest);
-+      if (!tpmData.permanent.data.pcrAttrib[i].pcrReset)
-+        SET_TO_ZERO(&tpmData.permanent.data.pcrValue[i].digest);
-       else
--        SET_TO_0xFF(tpmData.permanent.data.pcrValue[i].digest);
-+        SET_TO_0xFF(&tpmData.permanent.data.pcrValue[i].digest);
-     }
-     /* reset STCLEAR_FLAGS */
-     SET_TO_ZERO(&tpmData.stclear.flags);
-@@ -79,7 +82,8 @@ TPM_RESULT TPM_Startup(TPM_STARTUP_TYPE
-     /* init key-context nonce */
-     SET_TO_RAND(&tpmData.stclear.data.contextNonceKey);
-   } else if (startupType =3D=3D TPM_ST_STATE) {
--    if (tpm_restore_permanent_data()) {
-+    /* restore must have been successful for TPM_ST_STATE */
-+    if (restore_fail) {
-       error("restoring permanent data failed");
-       tpmData.permanent.data.testResult =3D
"tpm_restore_permanent_data() failed";
-       tpmData.permanent.flags.selfTestSucceeded =3D FALSE;
-diff -uprN orig/tpm_emulator-0.4/tpm/tpm_storage.c
tpm_emulator/tpm/tpm_storage.c
---- orig/tpm_emulator-0.4/tpm/tpm_storage.c    2006-06-23
03:37:07.000000000 -0700
-+++ tpm_emulator/tpm/tpm_storage.c    2006-07-24 14:35:35.000000000 -070=
0
-@@ -58,6 +58,7 @@ int encrypt_sealed_data(TPM_KEY_DATA *ke
-                         BYTE *enc, UINT32 *enc_size)
- {
-   UINT32 len;
-+  size_t enc_size32 =3D *enc_size;
-   BYTE *buf, *ptr;
-   rsa_public_key_t pub_key;
-   int scheme;
-@@ -72,7 +73,7 @@ int encrypt_sealed_data(TPM_KEY_DATA *ke
-   if (buf =3D=3D NULL
-       || tpm_marshal_TPM_SEALED_DATA(&ptr, &len, seal)
-       || rsa_encrypt(&pub_key, scheme, buf,
sizeof_TPM_SEALED_DATA((*seal)),
--                     enc, enc_size)) {
-+                     enc, &enc_size32)) {
-     tpm_free(buf);
-     rsa_release_public_key(&pub_key);
-     return -1;
-@@ -85,7 +86,8 @@ int encrypt_sealed_data(TPM_KEY_DATA *ke
- int decrypt_sealed_data(TPM_KEY_DATA *key, BYTE *enc, UINT32 enc_size,
-                         TPM_SEALED_DATA *seal, BYTE **buf)
- {
--  UINT32 len;
-+  size_t len;
-+  UINT32 len32;
-   BYTE *ptr;
-   int scheme;
-   switch (key->encScheme) {
-@@ -96,8 +98,12 @@ int decrypt_sealed_data(TPM_KEY_DATA *ke
-   len =3D enc_size;
-   *buf =3D ptr =3D tpm_malloc(len);
-   if (*buf =3D=3D NULL
--      || rsa_decrypt(&key->key, scheme, enc, enc_size, *buf, &len)
--      || tpm_unmarshal_TPM_SEALED_DATA(&ptr, &len, seal)) {
-+      || rsa_decrypt(&key->key, scheme, enc, enc_size, *buf, &len) ){
-+    tpm_free(*buf);
-+    return -1;
-+  }
-+  len32 =3D len;
-+  if (tpm_unmarshal_TPM_SEALED_DATA(&ptr, &len32, seal)) {
-     tpm_free(*buf);
-     return -1;
-   }
-@@ -240,11 +246,12 @@ TPM_RESULT TPM_Unseal(TPM_KEY_HANDLE par
-
- TPM_RESULT TPM_UnBind(TPM_KEY_HANDLE keyHandle, UINT32 inDataSize,
-                       BYTE *inData, TPM_AUTH *auth1,
--                      UINT32 *outDataSize, BYTE **outData)
-+                      UINT32 *outDataSize32, BYTE **outData)
- {
-   TPM_RESULT res;
-   TPM_KEY_DATA *key;
-   int scheme;
-+  size_t outDataSize;
- =20
-   info("TPM_UnBind()");
-   /* get key */
-@@ -262,8 +269,8 @@ TPM_RESULT TPM_UnBind(TPM_KEY_HANDLE key
-   /* the size of the input data muss be greater than zero */
-   if (inDataSize =3D=3D 0) return TPM_BAD_PARAMETER;
-   /* decrypt data */
--  *outDataSize =3D inDataSize;
--  *outData =3D tpm_malloc(*outDataSize);
-+  outDataSize =3D inDataSize;
-+  *outData =3D tpm_malloc(outDataSize);
-   if (*outData =3D=3D NULL) return TPM_NOSPACE;
-   switch (key->encScheme) {
-     case TPM_ES_RSAESOAEP_SHA1_MGF1: scheme =3D RSA_ES_OAEP_SHA1; break=
;
-@@ -271,20 +278,21 @@ TPM_RESULT TPM_UnBind(TPM_KEY_HANDLE key
-     default: tpm_free(*outData); return TPM_DECRYPT_ERROR;
-   }
-   if (rsa_decrypt(&key->key, scheme, inData, inDataSize,
--      *outData, outDataSize)) {
-+      *outData, &outDataSize)) {
-     tpm_free(*outData);
-     return TPM_DECRYPT_ERROR;
-   }
-   /* verify data if it is of type TPM_BOUND_DATA */
-   if (key->encScheme =3D=3D TPM_ES_RSAESOAEP_SHA1_MGF1
-       || key->keyUsage !=3D TPM_KEY_LEGACY) {
--    if (*outDataSize < 5 || memcmp(*outData, "\x01\x01\00\x00\x02", 5)
!=3D 0) {
-+    if (outDataSize < 5 || memcmp(*outData, "\x01\x01\00\x00\x02", 5)
!=3D 0) {
-       tpm_free(*outData);
-       return TPM_DECRYPT_ERROR;
-     }
--    *outDataSize -=3D 5;
--    memmove(*outData, &(*outData)[5], *outDataSize);
-+    outDataSize -=3D 5;
-+    memmove(*outData, &(*outData)[5], outDataSize);
-   }
-+  *outDataSize32 =3D (UINT32) outDataSize;
-   return TPM_SUCCESS;
- }
-
-@@ -334,12 +342,13 @@ int compute_pubkey_digest(TPM_PUBKEY *ke
- }
-
- int encrypt_private_key(TPM_KEY_DATA *key, TPM_STORE_ASYMKEY *store,
--                        BYTE *enc, UINT32 *enc_size)
-+                        BYTE *enc, UINT32 *enc_size32)
- {
-   UINT32 len;
-   BYTE *buf, *ptr;
-   rsa_public_key_t pub_key;
-   int scheme;
-+  size_t enc_size;
-   switch (key->encScheme) {
-     case TPM_ES_RSAESOAEP_SHA1_MGF1: scheme =3D RSA_ES_OAEP_SHA1; break=
;
-     case TPM_ES_RSAESPKCSv15: scheme =3D RSA_ES_PKCSV15; break;
-@@ -351,11 +360,12 @@ int encrypt_private_key(TPM_KEY_DATA *ke
-   if (buf =3D=3D NULL
-       || tpm_marshal_TPM_STORE_ASYMKEY(&ptr, &len, store)
-       || rsa_encrypt(&pub_key, scheme, buf,
sizeof_TPM_STORE_ASYMKEY((*store)),
--                     enc, enc_size)) {
-+                     enc, &enc_size)) {
-     tpm_free(buf);
-     rsa_release_public_key(&pub_key);
-     return -1;
-   }
-+  *enc_size32 =3D (UINT32) enc_size;
-   tpm_free(buf);
-   rsa_release_public_key(&pub_key);
-   return 0;
-@@ -364,7 +374,8 @@ int encrypt_private_key(TPM_KEY_DATA *ke
- int decrypt_private_key(TPM_KEY_DATA *key, BYTE *enc, UINT32 enc_size,
-                         TPM_STORE_ASYMKEY *store, BYTE **buf)
- {
--  UINT32 len;
-+  UINT32 len32;
-+  size_t len;
-   BYTE *ptr;
-   int scheme;
-   switch (key->encScheme) {
-@@ -375,8 +386,12 @@ int decrypt_private_key(TPM_KEY_DATA *ke
-   len =3D enc_size;
-   *buf =3D ptr =3D tpm_malloc(len);
-   if (*buf =3D=3D NULL
--      || rsa_decrypt(&key->key, scheme, enc, enc_size, *buf, &len)
--      || tpm_unmarshal_TPM_STORE_ASYMKEY(&ptr, &len, store)) {
-+      || rsa_decrypt(&key->key, scheme, enc, enc_size, *buf, &len) ) {
-+    tpm_free(*buf);
-+    return -1;
-+  }
-+  len32 =3D (UINT32) len;
-+  if (tpm_unmarshal_TPM_STORE_ASYMKEY(&ptr, &len32, store)) {=20
-     tpm_free(*buf);
-     return -1;
-   }
-@@ -394,7 +409,7 @@ TPM_RESULT TPM_CreateWrapKey(TPM_KEY_HAN
-   TPM_SESSION_DATA *session;
-   TPM_STORE_ASYMKEY store;
-   rsa_private_key_t rsa;
--  UINT32 key_length;
-+  size_t key_length;
-
-   info("TPM_CreateWrapKey()");
-   /* get parent key */
-@@ -450,11 +465,11 @@ TPM_RESULT TPM_CreateWrapKey(TPM_KEY_HAN
-     }
-   }
-   /* generate key and store it */
--  key_length =3D keyInfo->algorithmParms.parms.rsa.keyLength;
--  if (rsa_generate_key(&rsa, key_length)) return TPM_FAIL;
--  wrappedKey->pubKey.keyLength =3D key_length >> 3;
-+  if (rsa_generate_key(&rsa,
keyInfo->algorithmParms.parms.rsa.keyLength))
-+    return TPM_FAIL;
-+  wrappedKey->pubKey.keyLength =3D
keyInfo->algorithmParms.parms.rsa.keyLength >> 3;
-   wrappedKey->pubKey.key =3D tpm_malloc(wrappedKey->pubKey.keyLength);
--  store.privKey.keyLength =3D key_length >> 4;
-+  store.privKey.keyLength =3D
keyInfo->algorithmParms.parms.rsa.keyLength >> 4;
-   store.privKey.key =3D tpm_malloc(store.privKey.keyLength);
-   wrappedKey->encDataSize =3D parent->key.size >> 3;
-   wrappedKey->encData =3D tpm_malloc(wrappedKey->encDataSize);
-@@ -466,9 +481,11 @@ TPM_RESULT TPM_CreateWrapKey(TPM_KEY_HAN
-     tpm_free(wrappedKey->encData);
-     return TPM_NOSPACE;
-   }
--  rsa_export_modulus(&rsa, wrappedKey->pubKey.key,
--    &wrappedKey->pubKey.keyLength);
--  rsa_export_prime1(&rsa, store.privKey.key, &store.privKey.keyLength);=

-+  rsa_export_modulus(&rsa, wrappedKey->pubKey.key,
-+             &key_length);
-+  wrappedKey->pubKey.keyLength =3D (UINT32) key_length;
-+  rsa_export_prime1(&rsa, store.privKey.key, &key_length);
-+  store.privKey.keyLength =3D (UINT32) key_length;
-   rsa_release_private_key(&rsa);
-   /* compute the digest of the wrapped key (without encData) */
-   if (compute_key_digest(wrappedKey, &store.pubDataDigest)) {
-@@ -602,6 +619,7 @@ TPM_RESULT TPM_LoadKey2(TPM_KEY_HANDLE p
-
- int tpm_setup_key_parms(TPM_KEY_DATA *key, TPM_KEY_PARMS *parms)
- {
-+  size_t key_length;
-   parms->algorithmID =3D TPM_ALG_RSA;
-   parms->encScheme =3D key->encScheme;
-   parms->sigScheme =3D key->sigScheme;
-@@ -611,7 +629,8 @@ int tpm_setup_key_parms(TPM_KEY_DATA *ke
-   parms->parms.rsa.exponent =3D tpm_malloc(parms->parms.rsa.exponentSiz=
e);
-   if (parms->parms.rsa.exponent =3D=3D NULL) return -1;
-   rsa_export_exponent(&key->key, parms->parms.rsa.exponent,
--    &parms->parms.rsa.exponentSize);
-+    &key_length);
-+  parms->parms.rsa.exponentSize =3D (UINT32) key_length;
-   parms->parmSize =3D 12 + parms->parms.rsa.exponentSize;
-   return 0;
- }
-@@ -622,6 +641,7 @@ TPM_RESULT TPM_GetPubKey(TPM_KEY_HANDLE
-   TPM_RESULT res;
-   TPM_KEY_DATA *key;
-   TPM_DIGEST digest;
-+  size_t key_length;
-   info("TPM_GetPubKey()");
-   /* get key */
-   if (keyHandle =3D=3D TPM_KH_SRK
-@@ -650,8 +670,8 @@ TPM_RESULT TPM_GetPubKey(TPM_KEY_HANDLE
-   pubKey->pubKey.keyLength =3D key->key.size >> 3;
-   pubKey->pubKey.key =3D tpm_malloc(pubKey->pubKey.keyLength);
-   if (pubKey->pubKey.key =3D=3D NULL) return TPM_NOSPACE;
--  rsa_export_modulus(&key->key, pubKey->pubKey.key,
--    &pubKey->pubKey.keyLength);
-+  rsa_export_modulus(&key->key, pubKey->pubKey.key, &key_length);
-+  pubKey->pubKey.keyLength =3D (UINT32) key_length;
-   if (tpm_setup_key_parms(key, &pubKey->algorithmParms) !=3D 0) {
-     error("TPM_GetPubKey(): tpm_setup_key_parms() failed.");
-     tpm_free(pubKey->pubKey.key);
-diff -uprN orig/tpm_emulator-0.4/tpm/tpm_structures.h
tpm_emulator/tpm/tpm_structures.h
---- orig/tpm_emulator-0.4/tpm/tpm_structures.h    2006-06-23
03:37:07.000000000 -0700
-+++ tpm_emulator/tpm/tpm_structures.h    2006-07-24 14:35:35.000000000
-0700
-@@ -1958,6 +1958,7 @@ typedef struct tdTPM_DAA_ISSUER {
-   TPM_DIGEST DAA_digest_gamma;
-   BYTE DAA_generic_q[26];
- } TPM_DAA_ISSUER;
-+#define sizeof_TPM_DAA_ISSUER(s) (2 + (20 * 6) + 26 )
-
- /*
-  * TPM_DAA_TPM ([TPM_Part2], Section 22.4)
-@@ -1973,6 +1974,7 @@ typedef struct tdTPM_DAA_TPM {
-   TPM_DIGEST DAA_rekey;
-   UINT32 DAA_count;
- } TPM_DAA_TPM;
-+#define sizeof_TPM_DAA_TPM(s) (2 + (4 * 20) + 4)
-
- /*
-  * TPM_DAA_CONTEXT ([TPM_Part2], Section 22.5)
-@@ -1987,6 +1989,7 @@ typedef struct tdTPM_DAA_CONTEXT {
-   BYTE DAA_scratch[256];
-   BYTE DAA_stage;
- } TPM_DAA_CONTEXT;
-+#define sizeof_TPM_DAA_CONTEXT(s) (2 + (3 * 20) + 256 + 1)
-
- /*
-  * TPM_DAA_JOINDATA ([TPM_Part2], Section 22.6)
-@@ -1998,6 +2001,7 @@ typedef struct tdTPM_DAA_JOINDATA {
-   BYTE DAA_join_u1[138];
-   TPM_DIGEST DAA_digest_n0;
- } TPM_DAA_JOINDATA;
-+#define sizeof_TPM_DAA_JOINDATA(s) (1 + 1 + 20)
-
- /*
-  * TPM_DAA_BLOB ([TPM_Part2], Section 22.8)
-@@ -2202,6 +2206,7 @@ typedef struct tdTPM_STCLEAR_DATA {
-   //UINT32 ownerReference;
-   //BOOL disableResetLock;
- } TPM_STCLEAR_DATA;
-+#define sizeof_TPM_STCLEAR_DATA(s) (2 + 20 + 4)
-
- /*
-  * TPM_SESSION_DATA
-@@ -2238,6 +2243,11 @@ typedef struct tdTPM_DAA_SESSION_DATA {
-   TPM_DAA_JOINDATA DAA_joinSession;
-   TPM_HANDLE handle;
- } TPM_DAA_SESSION_DATA;
-+#define sizeof_TPM_DAA_SESSION_DATA(s) ( 1 \
-+  + sizeof_TPM_DAA_ISSUER(s.DAA_issuerSettings) \
-+  + sizeof_TPM_DAA_TPM(s.DAA_tpmSpecific) \
-+  + sizeof_TPM_DAA_CONTEXT(s.DAA_session) \
-+  + sizeof_TPM_DAA_JOINDATA(s.DAA_joinSession) + 4)
-
- /*
-  * TPM_STANY_DATA ([TPM_Part2], Section 7.6)
-@@ -2262,6 +2272,11 @@ typedef struct tdTPM_STANY_DATA {
-   TPM_DAAHANDLE currentDAA;
-   TPM_TRANSHANDLE transExclusive;
- } TPM_STANY_DATA;
-+#define sizeof_TPM_STANY_DATA(s) (2 + 20 + 20 + 1 \
-+  + sizeof_TPM_CURRENT_TICKS(s.currentTicks) \
-+  + 4 + (4 * TPM_MAX_SESSION_LIST) \
-+  + (sizeof_TPM_SESSION_DATA(s.sessions[0]) * TPM_MAX_SESSION_LIST) \
-+  + (sizeof_TPM_DAA_SESSION_DATA(s.sessionsDAA[0]) *
TPM_MAX_SESSIONS_DAA) + 4)
-
- /*
-  * TPM_DATA
-diff -uprN orig/tpm_emulator-0.4/tpm/tpm_testing.c
tpm_emulator/tpm/tpm_testing.c
---- orig/tpm_emulator-0.4/tpm/tpm_testing.c    2006-06-23
03:37:07.000000000 -0700
-+++ tpm_emulator/tpm/tpm_testing.c    2006-07-24 14:35:35.000000000 -070=
0
-@@ -1,6 +1,7 @@
- /* Software-Based Trusted Platform Module (TPM) Emulator for Linux
-  * Copyright (C) 2004 Mario Strasser <mast@gmx.net>,
-  *                    Swiss Federal Institute of Technology (ETH) Zuric=
h
-+ * Copyright (C) 2005 INTEL Corp
-  *
-  * This module is free software; you can redistribute it and/or modify
-  * it under the terms of the GNU General Public License as published
-@@ -95,24 +96,24 @@ static int tpm_test_sha1(void)
-   struct {
-     uint8_t *data; uint32_t repetitions; uint8_t *digest;
-   } test_cases[] =3D  {{
--    "abc", 1,
--  =20
"\xA9\x99\x3E\x36\x47\x06\x81\x6A\xBA\x3E\x25\x71\x78\x50\xC2\x6C\x9C\xD0=
\xD8\x9D"
-+    (uint8_t*)"abc", 1,
-+  =20
(uint8_t*)"\xA9\x99\x3E\x36\x47\x06\x81\x6A\xBA\x3E\x25\x71\x78\x50\xC2\x=
6C\x9C\xD0\xD8\x9D"
-   }, {
--    "abcdbcdecdefdefgefghfghighijhijkijkljklmklmnlmnomnopnopq", 1,
--  =20
"\x84\x98\x3E\x44\x1C\x3B\xD2\x6E\xBA\xAE\x4A\xA1\xF9\x51\x29\xE5\xE5\x46=
\x70\xF1"
-+  =20
(uint8_t*)"abcdbcdecdefdefgefghfghighijhijkijkljklmklmnlmnomnopnopq", 1,
-+  =20
(uint8_t*)"\x84\x98\x3E\x44\x1C\x3B\xD2\x6E\xBA\xAE\x4A\xA1\xF9\x51\x29\x=
E5\xE5\x46\x70\xF1"
-   }, {
--    "a", 1000000,
--  =20
"\x34\xAA\x97\x3C\xD4\xC4\xDA\xA4\xF6\x1E\xEB\x2B\xDB\xAD\x27\x31\x65\x34=
\x01\x6F"
-+    (uint8_t*)"a", 1000000,
-+  =20
(uint8_t*)"\x34\xAA\x97\x3C\xD4\xC4\xDA\xA4\xF6\x1E\xEB\x2B\xDB\xAD\x27\x=
31\x65\x34\x01\x6F"
-   }, {
--  =20
"0123456701234567012345670123456701234567012345670123456701234567", 10,
--  =20
"\xDE\xA3\x56\xA2\xCD\xDD\x90\xC7\xA7\xEC\xED\xC5\xEB\xB5\x63\x93\x4F\x46=
\x04\x52"
-+  =20
(uint8_t*)"01234567012345670123456701234567012345670123456701234567012345=
67",
10,
-+  =20
(uint8_t*)"\xDE\xA3\x56\xA2\xCD\xDD\x90\xC7\xA7\xEC\xED\xC5\xEB\xB5\x63\x=
93\x4F\x46\x04\x52"
-   }};
-
-   debug("tpm_test_sha1()");
-   for (i =3D 0; i < sizeof(test_cases) / sizeof(test_cases[0]); i++) {
-     sha1_init(&ctx);
-     for (j =3D 0; j < test_cases[i].repetitions; j++)
--      sha1_update(&ctx, test_cases[i].data, strlen(test_cases[i].data))=
;
-+      sha1_update(&ctx, test_cases[i].data,
strlen((char*)test_cases[i].data));
-     sha1_final(&ctx, digest);
-     if (memcmp(digest, test_cases[i].digest, SHA1_DIGEST_LENGTH) !=3D 0=
)
return -1;
-   }
-@@ -128,41 +129,41 @@ static int tpm_test_hmac(void)
-   struct {
-     uint8_t *key, key_len, *data, data_len, *digest;
-   } test_cases[] =3D {{
--    "\x0b", 20, "Hi There", 8,
--  =20
"\xb6\x17\x31\x86\x55\x05\x72\x64\xe2\x8b\xc0\xb6\xfb\x37\x8c\x8e\xf1\x46=
\xbe\x00"
-+    (uint8_t*)"\x0b", 20, (uint8_t*)"Hi There", 8,
-+  =20
(uint8_t*)"\xb6\x17\x31\x86\x55\x05\x72\x64\xe2\x8b\xc0\xb6\xfb\x37\x8c\x=
8e\xf1\x46\xbe\x00"
-   }, {
--    "Jefe", 4, "what do ya want for nothing?", 28,
--  =20
"\xef\xfc\xdf\x6a\xe5\xeb\x2f\xa2\xd2\x74\x16\xd5\xf1\x84\xdf\x9c\x25\x9a=
\x7c\x79"
-+    (uint8_t*)"Jefe", 4, (uint8_t*)"what do ya want for nothing?", 28,
-+  =20
(uint8_t*)"\xef\xfc\xdf\x6a\xe5\xeb\x2f\xa2\xd2\x74\x16\xd5\xf1\x84\xdf\x=
9c\x25\x9a\x7c\x79"
-   }, {
--    "\xaa", 20, "\xdd", 50,
--  =20
"\x12\x5d\x73\x42\xb9\xac\x11\xcd\x91\xa3\x9a\xf4\x8a\xa1\x7b\x4f\x63\xf1=
\x75\xd3"
-+    (uint8_t*)"\xaa", 20, (uint8_t*)"\xdd", 50,
-+  =20
(uint8_t*)"\x12\x5d\x73\x42\xb9\xac\x11\xcd\x91\xa3\x9a\xf4\x8a\xa1\x7b\x=
4f\x63\xf1\x75\xd3"
-   }, {
--  =20
"\x01\x02\x03\x04\x05\x06\x07\x08\x09\x0a\x0b\x0c\x0d\x0e\x0f\x10\x11\x12=
\x13\x14"
--    "\x15\x16\x17\x18\x19", 25, "\xcd", 50,
--  =20
"\x4c\x90\x07\xf4\x02\x62\x50\xc6\xbc\x84\x14\xf9\xbf\x50\xc8\x6c\x2d\x72=
\x35\xda"
-+  =20
(uint8_t*)"\x01\x02\x03\x04\x05\x06\x07\x08\x09\x0a\x0b\x0c\x0d\x0e\x0f\x=
10\x11\x12\x13\x14"
-+    "\x15\x16\x17\x18\x19", 25, (uint8_t*)"\xcd", 50,
-+  =20
(uint8_t*)"\x4c\x90\x07\xf4\x02\x62\x50\xc6\xbc\x84\x14\xf9\xbf\x50\xc8\x=
6c\x2d\x72\x35\xda"
-   }, {
--    "\x0c", 20, "Test With Truncation", 20,
--  =20
"\x4c\x1a\x03\x42\x4b\x55\xe0\x7f\xe7\xf2\x7b\xe1\xd5\x8b\xb9\x32\x4a\x9a=
\x5a\x04"
-+    (uint8_t*)"\x0c", 20, (uint8_t*)"Test With Truncation", 20,
-+  =20
(uint8_t*)"\x4c\x1a\x03\x42\x4b\x55\xe0\x7f\xe7\xf2\x7b\xe1\xd5\x8b\xb9\x=
32\x4a\x9a\x5a\x04"
-   }, {
--    "\xaa", 80, "Test Using Larger Than Block-Size Key - Hash Key
First", 54,
--  =20
"\xaa\x4a\xe5\xe1\x52\x72\xd0\x0e\x95\x70\x56\x37\xce\x8a\x3b\x55\xed\x40=
\x21\x12"
-+    (uint8_t*)"\xaa", 80, (uint8_t*)"Test Using Larger Than Block-Size
Key - Hash Key First", 54,
-+  =20
(uint8_t*)"\xaa\x4a\xe5\xe1\x52\x72\xd0\x0e\x95\x70\x56\x37\xce\x8a\x3b\x=
55\xed\x40\x21\x12"
-   }, {
--    "\xaa", 80,
--    "Test Using Larger Than Block-Size Key and Larger Than One
Block-Size Data", 73,
--  =20
"\xe8\xe9\x9d\x0f\x45\x23\x7d\x78\x6d\x6b\xba\xa7\x96\x5c\x78\x08\xbb\xff=
\x1a\x91"
-+    (uint8_t*)"\xaa", 80,
-+    (uint8_t*)"Test Using Larger Than Block-Size Key and Larger Than
One Block-Size Data", 73,
-+  =20
(uint8_t*)"\xe8\xe9\x9d\x0f\x45\x23\x7d\x78\x6d\x6b\xba\xa7\x96\x5c\x78\x=
08\xbb\xff\x1a\x91"
-   }};
-
-   debug("tpm_test_hmac()");
-   for (i =3D 0; i < sizeof(test_cases) / sizeof(test_cases[0]); i++) {
--    if (strlen(test_cases[i].key) < test_cases[i].key_len) {
-+    if (strlen((char*)test_cases[i].key) < test_cases[i].key_len) {
-       uint8_t key[test_cases[i].key_len];
-       memset(key, test_cases[i].key[0], test_cases[i].key_len);
-       hmac_init(&ctx, key, test_cases[i].key_len);
-     } else {
-       hmac_init(&ctx, test_cases[i].key, test_cases[i].key_len);
-     }
--    for (j =3D 0; j < test_cases[i].data_len; j +=3D
strlen(test_cases[i].data)) {
--      hmac_update(&ctx, test_cases[i].data, strlen(test_cases[i].data))=
;
-+    for (j =3D 0; j < test_cases[i].data_len; j +=3D
strlen((char*)test_cases[i].data)) {
-+      hmac_update(&ctx, test_cases[i].data,
strlen((char*)test_cases[i].data));
-     }
-     hmac_final(&ctx, digest);
-     if (memcmp(digest, test_cases[i].digest, SHA1_DIGEST_LENGTH) !=3D 0=
)
return -1;
-@@ -173,9 +174,9 @@ static int tpm_test_hmac(void)
- static int tpm_test_rsa_EK(void)
- {
-   int res =3D 0;
--  char *data =3D "RSA PKCS #1 v1.5 Test-String";
-+  uint8_t *data =3D (uint8_t*)"RSA PKCS #1 v1.5 Test-String";
-   uint8_t buf[256];
--  size_t buf_len, data_len =3D strlen(data);
-+  size_t buf_len, data_len =3D strlen((char*)data);
-   rsa_private_key_t priv_key;
-   rsa_public_key_t pub_key;
-
-diff -uprN orig/tpm_emulator-0.4/tpm/tpm_ticks.c
tpm_emulator/tpm/tpm_ticks.c
---- orig/tpm_emulator-0.4/tpm/tpm_ticks.c    2006-06-23
03:37:07.000000000 -0700
-+++ tpm_emulator/tpm/tpm_ticks.c    2006-07-24 14:35:35.000000000 -0700
-@@ -1,6 +1,7 @@
- /* Software-Based Trusted Platform Module (TPM) Emulator for Linux
-  * Copyright (C) 2004 Mario Strasser <mast@gmx.net>,
-  *                    Swiss Federal Institute of Technology (ETH) Zuric=
h
-+ * Copyright (C) 2005 INTEL Corp
-  *
-  * This module is free software; you can redistribute it and/or modify
-  * it under the terms of the GNU General Public License as published
-@@ -39,9 +40,7 @@ TPM_RESULT TPM_SetTickType(TPM_TICKTYPE
- TPM_RESULT TPM_GetTicks(TPM_CURRENT_TICKS *currentTime)
- {
-   info("TPM_GetTicks()");
--  memcpy(currentTime, &tpmData.stany.data.currentTicks,
--    sizeof(TPM_CURRENT_TICKS));
--  return TPM_SUCCESS;
-+  return TPM_DISABLED_CMD;
- }
-
- TPM_RESULT TPM_TickStampBlob(TPM_KEY_HANDLE keyHandle, TPM_NONCE
*antiReplay,
-@@ -49,64 +48,11 @@ TPM_RESULT TPM_TickStampBlob(TPM_KEY_HAN
-                              TPM_CURRENT_TICKS *currentTicks,
-                              UINT32 *sigSize, BYTE **sig)
- {
--  TPM_RESULT res;
--  TPM_KEY_DATA *key;
--  BYTE *info, *p;
--  UINT32 info_length, length;
-   info("TPM_TickStampBlob()");
--  /* get key */
--  key =3D tpm_get_key(keyHandle);
--  if (key =3D=3D NULL) return TPM_INVALID_KEYHANDLE;
--  /* verify authorization */
--  res =3D tpm_verify_auth(auth1, key->usageAuth, keyHandle);
--  if (res !=3D TPM_SUCCESS) return res;
--  if (key->keyUsage !=3D TPM_KEY_SIGNING && key->keyUsage !=3D TPM_KEY_=
LEGACY
--      && key->keyUsage !=3D TPM_KEY_IDENTITY) return TPM_INVALID_KEYUSA=
GE;
--  /* get current ticks */
--  TPM_GetTicks(currentTicks);
--  /* sign data using signature scheme PKCS1_SHA1 and TPM_SIGN_INFO
container */
--  *sigSize =3D key->key.size >> 3;
--  *sig =3D tpm_malloc(*sigSize);
--  if (*sig =3D=3D NULL) return TPM_FAIL;
--  /* setup TPM_SIGN_INFO structure */
--  info_length =3D 30 + sizeof(TPM_DIGEST) +
sizeof_TPM_CURRENT_TICKS(currentTicks);
--  info =3D tpm_malloc(info_length);
--  if (info =3D=3D NULL) {
--    tpm_free(*sig);
--    return TPM_FAIL;
--  }
--  memcpy(&info[0], "\x05\x00TSTP", 6);
--  memcpy(&info[6], antiReplay->nonce, 20);
--  *(UINT32*)&info[26] =3D CPU_TO_BE32(20
--                        + sizeof_TPM_CURRENT_TICKS(currentTicks));
--  memcpy(&info[30], digestToStamp->digest, sizeof(TPM_DIGEST));
--  p =3D &info[30 + sizeof(TPM_DIGEST)];
--  length =3D sizeof_TPM_CURRENT_TICKS(currentTicks);
--  if (tpm_marshal_TPM_CURRENT_TICKS(&p, &length, currentTicks)
--      || rsa_sign(&key->key, RSA_SSA_PKCS1_SHA1, info, info_length,
*sig)) { =20
--    tpm_free(*sig);
--    tpm_free(info);
--    return TPM_FAIL;
--  }
--  return TPM_SUCCESS;
-+  return TPM_DISABLED_CMD;
- }
-
- void tpm_update_ticks(void)
- {
--  if (tpmData.stany.data.currentTicks.tag =3D=3D 0) {
--    tpmData.stany.data.currentTicks.tag =3D TPM_TAG_CURRENT_TICKS;
--    tpmData.stany.data.currentTicks.currentTicks +=3D tpm_get_ticks();
--/* removed since v1.2 rev 94
--    tpmData.stany.data.currentTicks.tickType =3D
tpmData.permanent.data.tickType;
--*/
--    tpm_get_random_bytes(tpmData.stany.data.currentTicks.tickNonce.nonc=
e,
--      sizeof(TPM_NONCE));
--    tpmData.stany.data.currentTicks.tickRate =3D 1;
--/* removed since v1.2 rev 94
--    tpmData.stany.data.currentTicks.tickSecurity =3D TICK_SEC_NO_CHECK;=

--*/
--  } else {
--    tpmData.stany.data.currentTicks.currentTicks +=3D tpm_get_ticks(); =
=20
--  }
- }
-
-diff -uprN orig/tpm_emulator-0.4/tpm/tpm_transport.c
tpm_emulator/tpm/tpm_transport.c
---- orig/tpm_emulator-0.4/tpm/tpm_transport.c    2006-06-23
03:37:07.000000000 -0700
-+++ tpm_emulator/tpm/tpm_transport.c    2006-07-24 14:35:35.000000000 -0=
700
-@@ -189,7 +189,7 @@ static void decrypt_wrapped_command(BYTE
-     sha1_init(&sha1);
-     sha1_update(&sha1, auth->nonceEven.nonce,
sizeof(auth->nonceEven.nonce));
-     sha1_update(&sha1, auth->nonceOdd.nonce,
sizeof(auth->nonceOdd.nonce));
--    sha1_update(&sha1, "in", 2);
-+    sha1_update(&sha1, (BYTE*)"in", 2);
-     sha1_update(&sha1, secret, sizeof(TPM_SECRET));
-     j =3D CPU_TO_BE32(i);
-     sha1_update(&sha1, (BYTE*)&j, 4);
-@@ -211,7 +211,7 @@ static void encrypt_wrapped_command(BYTE
-     sha1_init(&sha1);
-     sha1_update(&sha1, auth->nonceEven.nonce,
sizeof(auth->nonceEven.nonce));
-     sha1_update(&sha1, auth->nonceOdd.nonce,
sizeof(auth->nonceOdd.nonce));
--    sha1_update(&sha1, "out", 3);
-+    sha1_update(&sha1, (BYTE*)"out", 3);
-     sha1_update(&sha1, secret, sizeof(TPM_SECRET));
-     j =3D CPU_TO_BE32(i);
-     sha1_update(&sha1, (BYTE*)&j, 4);
-diff -uprN orig/tpm_emulator-0.4/tpmd.c tpm_emulator/tpmd.c
---- orig/tpm_emulator-0.4/tpmd.c    1969-12-31 16:00:00.000000000 -0800
-+++ tpm_emulator/tpmd.c    2006-07-24 14:35:35.000000000 -0700
-@@ -0,0 +1,156 @@
-+/* Software-Based Trusted Platform Module (TPM) Emulator for Linux
-+ * Copyright (C) 2005 INTEL Corp
-+ *
-+ * This module 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 module is distributed in the hope that it will be useful,
-+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
-+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
-+ * GNU General Public License for more details.
-+ *
-+ */
-+
-+#include <stdio.h>
-+#include <stdlib.h>
-+#include <unistd.h>
-+#include <string.h>
-+#include <sys/types.h>
-+#include <sys/stat.h>
-+#include <fcntl.h>
-+#include <sys/time.h>
-+
-+#include "tpm_emulator.h"
-+
-+#define TPM_RX_FNAME "/var/tpm/tpm_in.fifo"
-+#define TPM_TX_FNAME "/var/tpm/tpm_out.fifo"
-+
-+#define BUFFER_SIZE 2048
-+
-+static int devurandom=3D0;
-+    =20
-+void get_random_bytes(void *buf, int nbytes) {
-+=20
-+  if (devurandom =3D=3D 0) {
-+    devurandom =3D open("/dev/urandom", O_RDONLY);
-+  }
-+
-+  if (read(devurandom, buf, nbytes) !=3D nbytes) {
-+      printf("Can't get random number.\n");
-+      exit(-1);
-+  }
-+}
-+
-+uint64_t tpm_get_ticks(void)
-+{
-+  //struct timeval tv;
-+  //int gettimeofday(&tv, struct timezone *tz);
-+  return 0;
-+}
-+
-+int main(int argc, char **argv)
-+{
-+  uint8_t in[BUFFER_SIZE], *out;
-+  uint32_t out_size;
-+  int in_size, written;
-+  int i;
-+  struct stat file_info;
-+
-+  int tpm_tx_fh=3D-1, tpm_rx_fh=3D-1;
-+  if (argc < 2) {
-+    printf("Usage: tpmd clear|save|deactivated\n" );
-+      return -1;
-+  }
-+
-+  /* initialize TPM emulator */
-+  if (!strcmp(argv[1], "clear")) {
-+    printf("Initializing tpm: %s\n", argv[1]);
-+    tpm_emulator_init(1);
-+  } else if (!strcmp(argv[1], "save")) {
-+    printf("Initializing tpm: %s\n", argv[1]);
-+    tpm_emulator_init(2);
-+  } else if (!strcmp(argv[1], "deactivated")) {
-+    printf("Initializing tpm: %s\n", argv[1]);
-+    tpm_emulator_init(3);
-+  } else {
-+    printf("invalid startup mode '%s'; must be 'clear', "
-+      "'save' (default) or 'deactivated", argv[1]);
-+    return -1;
-+  }
-+
-+  if ( stat(TPM_RX_FNAME, &file_info) =3D=3D -1) {
-+    if ( mkfifo(TPM_RX_FNAME, S_IWUSR | S_IRUSR ) ) {
-+      printf("Failed to create fifo %s.\n", TPM_RX_FNAME);
-+      return -1;
-+    }
-+  }
-+
-+  if ( stat(TPM_TX_FNAME, &file_info) =3D=3D -1) {
-+    if ( mkfifo(TPM_TX_FNAME, S_IWUSR | S_IRUSR ) ) {
-+      printf("Failed to create fifo %s.\n", TPM_TX_FNAME);
-+      return -1;
-+    }
-+  }
-+
-+  while (1) {
-+abort_command:
-+    if (tpm_rx_fh < 0) {
-+      tpm_rx_fh =3D open(TPM_RX_FNAME, O_RDONLY);
-+    }
-+  =20
-+    if (tpm_rx_fh < 0) {
-+      printf("ERROR: failed to open devices to listen to guest.\n");
-+      return -1;
-+    }
-+  =20
-+    if (tpm_tx_fh < 0) {
-+      tpm_tx_fh =3D open(TPM_TX_FNAME, O_WRONLY);
-+    }
-+
-+    if (tpm_tx_fh < 0) {
-+      printf("ERROR: failed to open devices to respond to guest.\n");
-+      return -1;
-+    }
-+
-+    in_size =3D read(tpm_rx_fh, in, BUFFER_SIZE);
-+    if (in_size < 6) { // Magic size of minium TPM command
-+      printf("Recv[%d] to small: 0x", in_size);
-+      if (in_size <=3D 0) {
-+          close(tpm_rx_fh);
-+          tpm_rx_fh =3D -1;
-+          goto abort_command;
-+      }
-+    } else {
-+      printf("Recv[%d]: 0x", in_size);
-+      for (i=3D0; i< in_size; i++)
-+        printf("%x ", in[i]);
-+      printf("\n");
-+    }
-+
-+  =20
-+    if (tpm_handle_command(in, in_size, &out, &out_size) !=3D 0) {
-+        printf("ERROR: Handler Failed.\n");
-+    }
-+
-+    written =3D write(tpm_tx_fh, out, out_size);
-+
-+    if (written !=3D out_size ) {
-+      printf("ERROR: Part of response not written %d/%d.\nAttempt: ",
written, out_size);
-+    } else {
-+      printf("Sent[%Zu]: ", out_size);
-+    }
-+    for (i=3D0; i< out_size; i++)
-+      printf("%x ", out[i]);
-+    printf("\n");
-+    tpm_free(out);
-+
-+  } // loop
-+
-+  tpm_emulator_shutdown();
-+
-+  close(tpm_tx_fh);
-+  close(tpm_rx_fh);
-+
-+}
-Binary files orig/tpm_emulator-0.4/tpm_emulator and
tpm_emulator/tpm_emulator differ
-diff -uprN orig/tpm_emulator-0.4/tpm_version.h tpm_emulator/tpm_version.=
h
---- orig/tpm_emulator-0.4/tpm_version.h    2006-06-23
03:37:07.000000000 -0700
-+++ tpm_emulator/tpm_version.h    2006-07-24 14:35:41.000000000 -0700
-@@ -2,5 +2,5 @@
- #define _TPM_VERSION_H_
- #define VERSION_MAJOR 0
- #define VERSION_MINOR 4
--#define VERSION_BUILD 1151058734
-+#define VERSION_BUILD 1153776940
- #endif /* _TPM_VERSION_H_ */
diff --git a/tools/vtpm/vtpm-0.5.1-LDLIBS.patch
b/tools/vtpm/vtpm-0.5.1-LDLIBS.patch
--- a/tools/vtpm/vtpm-0.5.1-LDLIBS.patch
+++ /dev/null
@@ -1,12 +0,0 @@
-diff -Naurp tpm_emulator-0.5.1/tpmd/Makefile
tpm_emulator-0.5.1/tpmd/Makefile
---- tpm_emulator-0.5.1/tpmd/Makefile
-+++ tpm_emulator-0.5.1/tpmd/Makefile
-@@ -8,7 +8,7 @@ WFLAGS  :=3D -Wall -Wno-unused -Wpointer-a
-            #WFLAGS  +=3D -Wextra -Wcast-qual -Wmissing-prototypes
-Wmissing-declarations -Wstrict-aliasing
- CFLAGS  +=3D $(WFLAGS) -g -I.. -I. -O2 -fno-strict-aliasing
- CFLAGS  +=3D -I../../../../tools/vtpm_manager/manager
--LDFLAGS +=3D -lgmp
-+LDLIBS  +=3D -lgmp
-
- BINDIR  :=3D /usr/bin/
-
diff --git a/tools/vtpm/vtpm-0.5.1.patch b/tools/vtpm/vtpm-0.5.1.patch
--- a/tools/vtpm/vtpm-0.5.1.patch
+++ /dev/null
@@ -1,766 +0,0 @@
-diff -Naurp tpm_emulator-0.5.1/Makefile tpm5-test/Makefile
---- tpm_emulator-0.5.1/Makefile    2008-02-14 03:22:48.000000000 -0500
-+++ tpm5-test/Makefile    2009-07-15 09:45:28.000000000 -0400
-@@ -10,7 +10,7 @@ VERSION_MINOR  :=3D 5
- VERSION_BUILD  :=3D $(shell date +"%s")
- VERSION_SUFFIX :=3D .1
-
--SUBDIRS :=3D tpmd tpmd_dev tddl
-+SUBDIRS :=3D tpmd
-
- all: version all-recursive
-
-@@ -48,12 +48,12 @@ user_install: user
- modules_install: modules
-     @$(MAKE) -C tpmd_dev install || exit -1
-
--DIRS    :=3D . tpm crypto tpmd tpmd_dev tddl tpmd_dev_openbsd
-+DIRS    :=3D . tpm crypto tpmd
- DISTSRC :=3D $(foreach dir, $(DIRS), $(wildcard $(dir)/*.c))
- DISTSRC +=3D $(foreach dir, $(DIRS), $(wildcard $(dir)/*.h))
--DIRS    :=3D . tpmd tpmd_dev tddl tpmd_dev_openbsd
-+DIRS    :=3D . tpmd
- DISTSRC +=3D $(foreach dir, $(DIRS), $(dir)/Makefile)
--DISTSRC +=3D ./README ./AUTHORS ./ChangeLog tpmd_dev/tpmd_dev.rules.in
-+DISTSRC +=3D ./README ./AUTHORS ./ChangeLog
- DISTDIR :=3D tpm_emulator-$(VERSION_MAJOR).$(VERSION_MINOR)$(VERSION_SU=
FFIX)
-
- dist: $(DISTSRC)
-diff -Naurp tpm_emulator-0.5.1/tpm/tpm_capability.c
tpm5-test/tpm/tpm_capability.c
---- tpm_emulator-0.5.1/tpm/tpm_capability.c    2008-02-14
03:22:48.000000000 -0500
-+++ tpm5-test/tpm/tpm_capability.c    2009-07-16 12:04:20.000000000 -040=
0
-@@ -136,8 +136,19 @@ static TPM_RESULT cap_property(UINT32 su
-
-     case TPM_CAP_PROP_TIS_TIMEOUT:
-       debug("[TPM_CAP_PROP_TIS_TIMEOUT]");
--      /* TODO: TPM_CAP_PROP_TIS_TIMEOUT */
--      return TPM_FAIL;
-+      /* TODO: TPM_CAP_PROP_TIS_TIMEOUT: Measure these values and
determine correct ones */
-+      UINT32 len =3D *respSize =3D 16;
-+      BYTE *ptr =3D *resp =3D tpm_malloc(*respSize);
-+      if (ptr =3D=3D NULL ||
-+          tpm_marshal_UINT32(&ptr, &len, 200000) ||
-+          tpm_marshal_UINT32(&ptr, &len, 200000) ||
-+          tpm_marshal_UINT32(&ptr, &len, 200000) ||
-+          tpm_marshal_UINT32(&ptr, &len, 200000)) {
-+        tpm_free(*resp);
-+        return TPM_FAIL;
-+      }
-+      return TPM_SUCCESS;
-+
-
-     case TPM_CAP_PROP_STARTUP_EFFECT:
-       debug("[TPM_CAP_PROP_STARTUP_EFFECT]");
-@@ -189,8 +200,12 @@ static TPM_RESULT cap_property(UINT32 su
-
-     case TPM_CAP_PROP_DURATION:
-       debug("[TPM_CAP_PROP_DURATION]");
--      /* TODO: TPM_CAP_PROP_DURATION */
--      return TPM_FAIL;
-+      /* TODO: TPM_CAP_PROP_DURATION: Measure these values and return
accurate ones */
-+      BYTE dur[]=3D
{0x0,0x0,0x0,0xc,0x0,0x7,0xa1,0x20,0x0,0x1e,0x84,0x80,0x11,0xe1,0xa3,0x0}=
;
-+      *respSize =3D 16;
-+      *resp =3D tpm_malloc(*respSize);
-+      memcpy(*resp,dur,16);
-+
-
-     case TPM_CAP_PROP_ACTIVE_COUNTER:
-       debug("[TPM_CAP_PROP_ACTIVE_COUNTER]");
-diff -Naurp tpm_emulator-0.5.1/tpmd/Makefile tpm5-test/tpmd/Makefile
---- tpm_emulator-0.5.1/tpmd/Makefile    2008-02-14 03:22:48.000000000 -0=
500
-+++ tpm5-test/tpmd/Makefile    2009-07-16 12:08:26.000000000 -0400
-@@ -8,9 +8,10 @@ WFLAGS  :=3D -Wall -Wno-unused -Wpointer-a
-            -Wwrite-strings -Wsign-compare -Wno-multichar
-            #WFLAGS  +=3D -Wextra -Wcast-qual -Wmissing-prototypes
-Wmissing-declarations -Wstrict-aliasing
- CFLAGS  +=3D $(WFLAGS) -g -I.. -I. -O2 -fno-strict-aliasing
-+CFLAGS  +=3D -I../../../../tools/vtpm_manager/manager
- LDFLAGS +=3D -lgmp
-
--BINDIR  :=3D /usr/sbin/
-+BINDIR  :=3D /usr/bin/
-
- TPMD    :=3D tpmd
- DIRS    :=3D ../tpm ../crypto
-@@ -18,6 +19,8 @@ SRCS    :=3D $(foreach dir, $(DIRS), $(wil
- OBJS    :=3D $(patsubst %.c, %.o, $(SRCS))
- OBJS    :=3D $(foreach dir, $(DIRS), $(patsubst $(dir)/%.o, %.o,
$(filter $(dir)/%.o, $(OBJS))))
-
-+VTPM_BIN :=3D vtpmd
-+
- vpath %.c $(strip $(DIRS))
-
- all: $(TPMD)
-@@ -32,10 +35,8 @@ TPMD_GROUP ?=3D tss
- INSTALL    ?=3D install
-
- install: $(TPMD)
--    $(INSTALL) -m 755 -o $(TPMD_USER) -g $(TPMD_GROUP) -d
$(DESTDIR)/var/lib/tpm
--    $(INSTALL) -m 755 -o $(TPMD_USER) -g $(TPMD_GROUP) -d
$(DESTDIR)/var/run/tpm
-     $(INSTALL) -D -d $(DESTDIR)/$(BINDIR)
--    $(INSTALL) -m 755 $(TPMD) $(DESTDIR)/$(BINDIR)
-+    $(INSTALL) -m 755 $(TPMD) $(DESTDIR)/$(BINDIR)/$(VTPM_BIN)
-
- .PHONY: all clean install
-
-diff -Naurp tpm_emulator-0.5.1/tpmd/tpmd.c tpm5-test/tpmd/tpmd.c
---- tpm_emulator-0.5.1/tpmd/tpmd.c    2008-02-14 03:22:48.000000000 -050=
0
-+++ tpm5-test/tpmd/tpmd.c    2009-07-16 11:19:05.000000000 -0400
-@@ -32,6 +32,9 @@
- #include <grp.h>
- #include "tpm_emulator_config.h"
- #include "tpm/tpm_emulator.h"
-+#include "tpm/tpm_structures.h"
-+#include "tpm/tpm_marshalling.h"
-+#include "vtpm_manager.h"
-
- #define TPM_DAEMON_NAME     "tpmd"
- #define TPM_CMD_BUF_SIZE    4096
-@@ -39,6 +42,24 @@
- #define TPM_RANDOM_DEVICE   "/dev/urandom"
- #undef  TPM_MKDIRS
-
-+#ifdef VTPM_MULTI_VM
-+ #define DEV_BE "/dev/vtpm"
-+ #define DEV_FE "/dev/tpm"
-+#else
-+ #define PVM_RX_FIFO_D "/var/vtpm/fifos/tpm_cmd_to_%d.fifo"
-+ #define PVM_TX_FIFO "/var/vtpm/fifos/tpm_rsp_from_all.fifo"
-+ #define HVM_RX_FIFO_D "/var/vtpm/socks/%d.socket"
-+
-+ #define VTPM_RX_FIFO_D "/var/vtpm/fifos/vtpm_rsp_to_%d.fifo"
-+ #define VTPM_TX_FIFO "/var/vtpm/fifos/vtpm_cmd_from_all.fifo"
-+
-+ static char *vtpm_rx_name=3DNULL;
-+#endif
-+
-+ static int vtpm_tx_fh=3D-1, vtpm_rx_fh=3D-1;
-+
-+#define BUFFER_SIZE 2048
-+
- static volatile int stopflag =3D 0;
- static int is_daemon =3D 0;
- static int opt_debug =3D 0;
-@@ -49,6 +70,8 @@ static const char *opt_storage_file =3D "/
- static uid_t opt_uid =3D 0;
- static gid_t opt_gid =3D 0;
- static int tpm_startup =3D 2;
-+static int vtpm_type =3D VTPM_TYPE_PVM;
-+int dmi_id =3D 0;
- static int rand_fh;
-
- void tpm_log(int priority, const char *fmt, ...)
-@@ -90,56 +113,241 @@ uint64_t tpm_get_ticks(void)
-
- int tpm_write_to_file(uint8_t *data, size_t data_length)
- {
--    int fh;
--    ssize_t res;
--    fh =3D open(opt_storage_file, O_WRONLY | O_TRUNC | O_CREAT, S_IRUSR=

| S_IWUSR);
--    if (fh < 0) return -1;
--    while (data_length > 0) {
--        res =3D write(fh, data, data_length);
--    if (res < 0) {
--        close(fh);
--        return -1;
--    }
--    data_length -=3D res;
--    data +=3D res;
-+  int res, out_data_size, in_header_size;
-+  BYTE *ptr, *out_data, *in_header;
-+  UINT32 result, len, in_rsp_size;
-+  UINT16 tag =3D VTPM_TAG_REQ;
-+  =20
-+  printf("Saving NVM\n");
-+  if (vtpm_tx_fh < 0) {
-+#ifdef VTPM_MUTLI_VM
-+    vtpm_tx_fh =3D open(DEV_FE, O_RDWR);
-+#else
-+    vtpm_tx_fh =3D open(VTPM_TX_FIFO, O_WRONLY);
-+#endif
-+  }
-+
-+  if (vtpm_tx_fh < 0) {
-+        return -1;
-+  }
-+
-+  // Send request to VTPM Manager to encrypt data
-+#ifdef VTPM_MUTLI_VM
-+  out_data_size =3D len =3D VTPM_COMMAND_HEADER_SIZE_CLT + data_length;=

-+#else
-+  out_data_size =3D len =3D VTPM_COMMAND_HEADER_SIZE_SRV + data_length;=

-+#endif
-+=20
-+  out_data =3D ptr =3D (BYTE *) malloc(len);
-+
-+  if (ptr =3D=3D NULL
-+#ifndef VTPM_MUTLI_VM
-+      || tpm_marshal_UINT32(&ptr, &len, dmi_id)
-+#endif
-+      || tpm_marshal_UINT16(&ptr, &len, tag)
-+#ifdef VTPM_MUTLI_VM
-+      || tpm_marshal_UINT32(&ptr, &len, out_data_size)
-+#else
-+      || tpm_marshal_UINT32(&ptr, &len, out_data_size - sizeof(uint32_t=
))
-+#endif=20
-+      || tpm_marshal_UINT32(&ptr, &len, VTPM_ORD_SAVENVM)
-+      || tpm_marshal_BYTE_ARRAY(&ptr, &len, data, data_length)) {
-+    free(out_data);
-+    return -1;
-+  }
-+=20
-+  printf("\tSending SaveNVM Command.\n");
-+  res =3D write(vtpm_tx_fh, out_data, out_data_size);
-+  free(out_data);
-+  if (res !=3D out_data_size) return -1;
-+
-+  if (vtpm_rx_fh < 0) {
-+#ifdef VTPM_MUTLI_VM
-+    vtpm_rx_fh =3D vtpm_tx_fh
-+#else
-+    if (vtpm_rx_name =3D=3D NULL) {
-+      vtpm_rx_name =3D malloc(10 + strlen(VTPM_RX_FIFO_D));
-+      sprintf(vtpm_rx_name, VTPM_RX_FIFO_D, (uint32_t) dmi_id);
-     }
--    close(fh);
--    return 0;
-+    vtpm_rx_fh =3D open(vtpm_rx_name, O_RDONLY);
-+#endif
-+  }
-+
-+  if (vtpm_rx_fh < 0) {
-+        return -1;
-+  }
-+=20
-+  // Read Header of response so we can get the size & status
-+#ifdef VTPM_MUTLI_VM
-+  in_header_size =3D len =3D VTPM_COMMAND_HEADER_SIZE_CLT;
-+#else
-+  in_header_size =3D len =3D VTPM_COMMAND_HEADER_SIZE_SRV;
-+#endif
-+  in_header =3D ptr =3D malloc(in_header_size);
-+=20
-+  printf("\tReading SaveNVM header.\n");
-+  res =3D read(vtpm_rx_fh, in_header, in_header_size);
-+
-+  if ( (res !=3D in_header_size)
-+#ifndef VTPM_MUTLI_VM
-+       || tpm_unmarshal_UINT32(&ptr, &len, (UINT32*)&dmi_id)
-+#endif
-+       || tpm_unmarshal_UINT16(&ptr, &len, &tag)
-+       || tpm_unmarshal_UINT32(&ptr, &len, &in_rsp_size)
-+       || tpm_unmarshal_UINT32(&ptr, &len, &result) ) {
-+      free(in_header);
-+      return -1;
-+  }
-+  free(in_header);
-+=20
-+  if (result !=3D VTPM_SUCCESS) {
-+      return -1;=20
-+  }
-+
-+#ifdef VTPM_MUTLI_VM
-+  close(vtpm_tx_fh); close(vtpm_rx_fh);
-+#endif
-+    =20
-+  printf("\tFinishing up SaveNVM\n");
-+  return (0);
- }
-
- int tpm_read_from_file(uint8_t **data, size_t *data_length)
- {
--    int fh;
--    ssize_t res;
--    size_t total_length;
--    fh =3D open(opt_storage_file, O_RDONLY);
--    if (fh < 0) return -1;
--    total_length =3D lseek(fh, 0, SEEK_END);
--    lseek(fh, 0, SEEK_SET);
--    *data =3D tpm_malloc(total_length);
--    if (*data =3D=3D NULL) {
--        close(fh);
--        return -1;
--    }
--    *data_length =3D 0;
--    while (total_length > 0) {
--        res =3D read(fh, &(*data)[*data_length], total_length);
--    if (res < 0) {
--        close(fh);
--        tpm_free(*data);
--        return -1;
--    }
--        *data_length +=3D res;
--    total_length -=3D res;
-+  int res, out_data_size, in_header_size;
-+  uint8_t *ptr, *out_data, *in_header;
-+  UINT16 tag =3D VTPM_TAG_REQ;
-+  UINT32 len, in_rsp_size, result;
-+#ifdef VTPM_MUTLI_VM
-+    int vtpm_rx_fh, vtpm_tx_fh;
-+#endif
-+  =20
-+  printf("Loading NVM.\n");
-+  if (vtpm_tx_fh < 0) {
-+#ifdef VTPM_MUTLI_VM
-+    vtpm_tx_fh =3D open(DEV_FE, O_RDWR);
-+#else
-+    vtpm_tx_fh =3D open(VTPM_TX_FIFO, O_WRONLY);
-+#endif
-+  }
-+
-+  if (vtpm_tx_fh < 0) {
-+    printf("Error in read_from_file:301\n");
-+        return -1;
-+  }
-+
-+  // Send request to VTPM Manager to encrypt data
-+#ifdef VTPM_MUTLI_VM
-+  out_data_size =3D len =3D VTPM_COMMAND_HEADER_SIZE_CLT;
-+#else
-+  out_data_size =3D len =3D VTPM_COMMAND_HEADER_SIZE_SRV;
-+#endif
-+  out_data =3D ptr =3D (BYTE *) malloc(len);
-+
-+  if (ptr =3D=3D NULL
-+#ifndef VTPM_MUTLI_VM
-+      || tpm_marshal_UINT32(&ptr, &len, dmi_id)
-+#endif=20
-+      || tpm_marshal_UINT16(&ptr, &len, tag)
-+#ifdef VTPM_MUTLI_VM
-+      || tpm_marshal_UINT32(&ptr, &len, out_data_size)
-+#else
-+      || tpm_marshal_UINT32(&ptr, &len, out_data_size - sizeof(uint32_t=
))
-+#endif
-+      || tpm_marshal_UINT32(&ptr, &len, VTPM_ORD_LOADNVM)) {
-+    free(out_data);
-+    printf("Error in read_from_file:325\n");
-+
-+    return -1;
-+  }
-+
-+  printf("\tSending LoadNVM command\n");
-+  res =3D write(vtpm_tx_fh, out_data, out_data_size);
-+  free(out_data);
-+  if (res !=3D out_data_size)
-+    {
-+    printf("Error in read_from_file:335\n");
-+    return -1;
-+    }
-+
-+    if (vtpm_rx_fh < 0) {
-+#ifdef VTPM_MUTLI_VM
-+    vtpm_rx_fh =3D vtpm_tx_fh;
-+#else
-+    if (vtpm_rx_name =3D=3D NULL) {
-+      vtpm_rx_name =3D malloc(10 + strlen(VTPM_RX_FIFO_D));
-+      sprintf(vtpm_rx_name, VTPM_RX_FIFO_D, (uint32_t) dmi_id);
-     }
--    close(fh);
--    return 0;
-+    vtpm_rx_fh =3D open(vtpm_rx_name, O_RDONLY);
-+#endif
-+  }
-+
-+  if (vtpm_rx_fh < 0) {
-+    printf("Error in read_from_file:352\n");  =20
-+    return -1;
-+  }
-+=20
-+  // Read Header of response so we can get the size & status
-+#ifdef VTPM_MUTLI_VM
-+  in_header_size =3D len =3D VTPM_COMMAND_HEADER_SIZE_CLT;
-+#else
-+  in_header_size =3D len =3D VTPM_COMMAND_HEADER_SIZE_SRV;
-+#endif
-+  in_header =3D ptr =3D malloc(in_header_size);
-+=20
-+  printf("\tReading LoadNVM header\n");
-+  res =3D read(vtpm_rx_fh, in_header, in_header_size);
-+
-+  if ( (res !=3D in_header_size)
-+#ifndef VTPM_MUTLI_VM
-+       || tpm_unmarshal_UINT32(&ptr, &len, (UINT32*)&dmi_id)
-+#endif
-+       || tpm_unmarshal_UINT16(&ptr, &len, &tag)
-+       || tpm_unmarshal_UINT32(&ptr, &len, &in_rsp_size)
-+       || tpm_unmarshal_UINT32(&ptr, &len, &result) ) {
-+      free(in_header);
-+      printf("Error in read_from_file:375\n");   =20
-+      return -1;
-+  }
-+  free(in_header);
-+=20
-+  if (result !=3D VTPM_SUCCESS) {
-+    printf("Error in read_from_file:381\n");
-+    return -1;=20
-+  }
-+
-+  // Read Encrypted data from VTPM Manager
-+  *data_length =3D in_rsp_size - VTPM_COMMAND_HEADER_SIZE_CLT;
-+  *data =3D (uint8_t *) malloc(*data_length);
-+
-+  printf("\tReading clear data from LoadNVM.\n");
-+  res =3D read(vtpm_rx_fh, *data, *data_length);
-+#ifdef VTPM_MUTLI_VM
-+  close(vtpm_rx_fh);close(vtpm_tx_fh);
-+#endif
-+  =20
-+  printf("\tReturing from loading NVM\n");
-+  if (res !=3D (int)*data_length) {
-+      free(*data);
-+      printf("Error in read_from_file:398\n");
-+      return -1;
-+  } else {
-+      return 0;
-+  }
-+
-+
-+  =20
- }
-
- static void print_usage(char *name)
- {
-     printf("usage: %s [-d] [-f] [-s storage file] [-u unix socket name]=
 "
--           "[-o user name] [-g group name] [-h] [startup mode]\n", name=
);
-+           "[-o user name] [-g group name] [-h]"
-+#ifdef VTPM_MULTI_VM
-+       "clear|save|deactivated\n", name);
-+#else
-+       "clear|save|deactivated pvm|hvm vtpmid\n", name);
-+#endif
-     printf("  d : enable debug mode\n");
-     printf("  f : forces the application to run in the foreground\n");
-     printf("  s : storage file to use (default: %s)\n", opt_storage_fil=
e);
-@@ -205,7 +413,13 @@ static void parse_options(int argc, char
-                 exit(EXIT_SUCCESS);
-         }
-     }
--    if (optind < argc) {
-+    /*Make sure we have all required options*/
-+#ifdef VTPM_MULTI_VM
-+#define EXTRA_OPTS 0
-+#else
-+#define EXTRA_OPTS 2
-+#endif
-+    if (optind < argc - EXTRA_OPTS ) {
-         debug("startup mode =3D '%s'", argv[optind]);
-         if (!strcmp(argv[optind], "clear")) {
-             tpm_startup =3D 1;
-@@ -219,6 +433,25 @@ static void parse_options(int argc, char
-             print_usage(argv[0]);
-             exit(EXIT_SUCCESS);
-         }
-+#ifndef VTPM_MULTI_VM
-+        ++optind;
-+    if(!strcmp(argv[optind], "pvm")) {
-+        vtpm_type =3D VTPM_TYPE_PVM;    // Get commands from vTPM
Manager through fifo
-+    } else if (!strcmp(argv[optind], "hvm")) {
-+        vtpm_type =3D VTPM_TYPE_HVM;    // Get commands from qemu via s=
ocket
-+        } else {
-+        error("Invalid vm mode '%s'; must be 'pvm', "
-+            "or 'hvm' ", argv[optind]);
-+        print_usage(argv[0]);
-+        exit(EXIT_SUCCESS);
-+    }
-+        ++optind;
-+    dmi_id =3D atoi(argv[optind]);
-+#endif
-+    } else {
-+    error("Invalid number of arguments");
-+    print_usage(argv[0]);
-+    exit(EXIT_SUCCESS);
-     }
- }
-
-@@ -348,93 +581,180 @@ static int init_socket(const char *name)
-
- static void main_loop(void)
- {
--    int sock, fh, res;
--    int32_t in_len;
-+    int32_t in_len, written;
-     uint32_t out_len;
--    uint8_t in[TPM_CMD_BUF_SIZE], *out;
-+    uint8_t in[TPM_CMD_BUF_SIZE], *out, *addressed_out;
-+    int guest_id=3D-1;
-+    int i;
-+    char *vtpm_rx_file=3DNULL;
-+    int res;
-+
-+#ifndef VTPM_MULTI_VM
-+    int sockfd =3D -1;
-     struct sockaddr_un addr;
--    socklen_t addr_len;
--    fd_set rfds;
--    struct timeval tv;
-+    struct sockaddr_un client_addr;
-+    unsigned int client_length;
-+#endif
-+
-+    int vtpm_tx_fh=3D-1, vtpm_rx_fh=3D-1;
-+
-+#ifndef VTPM_MULTI_VM
-+  if (vtpm_type =3D=3D VTPM_TYPE_PVM) {
-+    vtpm_rx_file =3D malloc(10 + strlen(PVM_RX_FIFO_D));
-+    sprintf(vtpm_rx_file, PVM_RX_FIFO_D, (uint32_t) dmi_id);
-+  } else {
-+    vtpm_rx_file =3D malloc(10 + strlen(HVM_RX_FIFO_D));
-+    sprintf(vtpm_rx_file, HVM_RX_FIFO_D, (uint32_t) dmi_id);
-+
-+    if ( (sockfd =3D socket(PF_UNIX,SOCK_STREAM,0)) < 0) {
-+          error("Unable to create socket. errno =3D %d\n", errno);
-+      exit (-1);
-+    }
-+
-+    memset(&addr, 0, sizeof(addr));
-+    addr.sun_family =3D AF_UNIX;
-+    strcpy(addr.sun_path,vtpm_rx_file );
-+    unlink(addr.sun_path);
-+  }
-+#endif
-
-     info("staring main loop");
--    /* open UNIX socket */
--    sock =3D init_socket(opt_socket_name);
--    if (sock < 0) exit(EXIT_FAILURE);
-     /* init tpm emulator */
--    debug("initializing TPM emulator: %d", tpm_startup);
-+#ifdef VTPM_MULTI_VM
-+    debug("initializing TPM emulator: state=3D%d", tpm_startup);
-+#else
-+    debug("initializing TPM emulator: state=3D%d, type=3D%d, id=3D%d",
tpm_startup, vtpm_type, dmi_id);
-+#endif
-     tpm_emulator_init(tpm_startup);
-     /* start command processing */
-     while (!stopflag) {
-         /* wait for incomming connections */
-         debug("waiting for connections...");
--        FD_ZERO(&rfds);
--        FD_SET(sock, &rfds);
--        tv.tv_sec =3D 10;
--        tv.tv_usec =3D 0;
--        res =3D select(sock + 1, &rfds, NULL, NULL, &tv);
--        if (res < 0) {
--            error("select(sock) failed: %s", strerror(errno));
--            break;
--        } else if (res =3D=3D 0) {
--            continue;
--        }
--        addr_len =3D sizeof(addr);
--        fh =3D accept(sock, (struct sockaddr*)&addr, &addr_len);
--        if (fh < 0) {
--            error("accept() failed: %s", strerror(errno));
--            continue;
--        }
-+    if (vtpm_rx_fh < 0) {
-+#ifdef VTPM_MUTLI_VM
-+        vtpm_rx_fh =3D open(DEV_BE, O_RDWR);
-+#else
-+        if (vtpm_type =3D=3D VTPM_TYPE_PVM)
-+        {
-+        vtpm_rx_fh =3D open(vtpm_rx_file, O_RDONLY);
-+        } else {
-+        if (bind(sockfd, (struct sockaddr *)&addr, sizeof(addr)) < 0) {=

-+            error("Unable to bind(). errno =3D %d\n", errno);
-+            exit (-1);
-+        }
-+
-+        if (listen(sockfd, 10) <0) {
-+            error("Unable to listen(). errno =3D %d\n", errno);
-+            exit (-1);
-+        }
-+
-+         memset(&client_addr, 0, sizeof(client_addr));
-+         client_length =3D sizeof(client_addr);
-+
-+         vtpm_rx_fh =3D vtpm_tx_fh =3D accept(sockfd, (struct sockaddr
*)&client_addr, &client_length);
-+        }
-+#endif
-+    }
-+  =20
-+    /*Error Checking*/
-+    if (vtpm_rx_fh < 0) {
-+      error("Failed to open devices to listen to guest.\n");
-+      exit(-1);
-+    }
-+
-         /* receive and handle commands */
-         in_len =3D 0;
-         do {
-             debug("waiting for commands...");
--            FD_ZERO(&rfds);
--            FD_SET(fh, &rfds);
--            tv.tv_sec =3D TPM_COMMAND_TIMEOUT;
--            tv.tv_usec =3D 0;
--            res =3D select(fh + 1, &rfds, NULL, NULL, &tv);
--            if (res < 0) {
--                error("select(fh) failed: %s", strerror(errno));
--                close(fh);
--                break;
--            } else if (res =3D=3D 0) {
--#ifdef TPMD_DISCONNECT_IDLE_CLIENTS      =20
--                info("connection closed due to inactivity");
--                close(fh);
--                break;
--#else      =20
--                continue;
--#endif      =20
--            }
--            in_len =3D read(fh, in, sizeof(in));
--            if (in_len > 0) {
-+
-+            in_len =3D read(vtpm_rx_fh, in, sizeof(in));
-+        /*Magic size of minimum TPM command is 6*/
-+        //FIXME Magic size check may not be required anymore
-+            if (in_len < 6) {
-+        info("Recv incomplete command of %d bytes.", in_len);
-+        if (in_len <=3D 0) {
-+            close(vtpm_rx_fh);
-+            vtpm_rx_fh =3D -1;
-+            continue;
-+                 }
-+        } else {
-+        /*Debug Printouts*/
-                 debug("received %d bytes", in_len);
-+        debug_nostop("Recv[%d]: 0x", in_len);
-+        for (i=3D0; i< in_len; i++)
-+            debug_more("%x ", in[i]);
-+        debug_more("\n");
-+        /*Multiple Guest check*/
-+        if (guest_id =3D=3D -1) {
-+            guest_id =3D *((int32_t *) in);
-+        } else {
-+            if (guest_id !=3D *((int32_t *) in) ) {
-+            error("WARNING: More than one guest attached\n");
-+            }
-+        }
-+
-+        /*Open tx handle now*/
-+        if (vtpm_tx_fh < 0) {
-+#ifdef VTPM_MUTLI_VM
-+            vtpm_tx_fh =3D open(DEV_BE, O_RDWR);
-+            vtpm_rx_fh =3D vtpm_tx_fh;
-+#else
-+            if (vtpm_type =3D=3D VTPM_TYPE_PVM) {
-+            vtpm_tx_fh =3D open(PVM_TX_FIFO, O_WRONLY);
-+                 } // No need to open the other direction for HVM
-+#endif
-+        }
-+        if (vtpm_tx_fh < 0) {
-+          error("Failed to open devices to respond to guest.\n");
-+          exit(-1);
-+        }
-+
-+        /*Handle the TPM command now*/
-                 out =3D NULL;
--                res =3D tpm_handle_command(in, in_len, &out, &out_len);=

-+                res =3D tpm_handle_command(in + sizeof(uint32_t), in_le=
n
- sizeof(uint32_t), &out, &out_len);
-                 if (res < 0) {
-                     error("tpm_handle_command() failed");
-                 } else {
-                     debug("sending %d bytes", out_len);
-+            //FIXME this prepending may or may not be needed
-+            /*Prepend the first 4 bytes of the in buffer.. why?*/
-+            addressed_out =3D (uint8_t *) tpm_malloc(sizeof(uint32_t) +=

out_len);
-+            *(uint32_t *) addressed_out =3D *(uint32_t *) in;
-+            memcpy(addressed_out + sizeof(uint32_t), out, out_len);
-+            out_len +=3D sizeof(uint32_t);
-+            /*End Prepend*/
-+
-+            /*Perform write operation now*/
-                     while (out_len > 0) {
--                        res =3D write(fh, out, out_len);
-+                        res =3D write(vtpm_tx_fh, addressed_out, out_le=
n);
-+
-                         if (res < 0) {
-                             error("write(%d) failed: %s", out_len,
strerror(errno));
-                             break;
--                        }
-+                        } else {
-+              debug_nostop("Sent[%Zu]: ", out_len);
-+              for (i=3D0; (unsigned int)i< out_len; i++)
-+                debug_more("%x ", addressed_out[i]);
-+              debug_more("\n");
-+            }
-                         out_len    -=3D res;
-                     }
-                     tpm_free(out);
-+            tpm_free(addressed_out);
-                 }
-             }
-         } while (in_len > 0);
--        close(fh);
-+        //close(fh);
-     }
-+  =20
-     /* shutdown tpm emulator */
-     tpm_emulator_shutdown();
--    /* close socket */
--    close(sock);
--    unlink(opt_socket_name);
-+    /* Close handles */
-+    close(vtpm_tx_fh);
-+#ifndef VTPM_MULTI_VM
-+    close(vtpm_rx_fh);
-+    free(vtpm_rx_file);
-+#endif
-     info("main loop stopped");
- }
-
-@@ -450,12 +770,13 @@ int main(int argc, char **argv)
-     /* open random device */
-     init_random();
-     /* init signal handlers */
--    init_signal_handler();
-+    //init_signal_handler();
-     /* unless requested otherwiese, fork and daemonize process */
--    if (!opt_foreground) daemonize();
-+    //if (!opt_foreground) daemonize();
-     /* start main processing loop */
-     main_loop();
-     info("stopping TPM Emulator daemon");
-     closelog();
-     return 0;
- }
-+
-diff -Naurp tpm_emulator-0.5.1/tpmd/tpm_emulator_config.h
tpm5-test/tpmd/tpm_emulator_config.h
---- tpm_emulator-0.5.1/tpmd/tpm_emulator_config.h    2008-02-14
03:22:48.000000000 -0500
-+++ tpm5-test/tpmd/tpm_emulator_config.h    2009-07-16
11:25:26.000000000 -0400
-@@ -29,23 +29,28 @@
-
- /* TPM emulator configuration */
-
--#undef  TPM_STRONG_PERSISTENCE
--#undef  TPM_GENERATE_EK
-+#define  TPM_STRONG_PERSISTENCE
-+#define  TPM_GENERATE_EK
- #undef  TPM_GENERATE_SEED_DAA
- #undef  TPM_MEMORY_ALIGNMENT_MANDATORY
-
-+extern int dmi_id;
-+
- /* log macros */
-
- void tpm_log(int priority, const char *fmt, ...);
-
--#define debug(fmt, ...) tpm_log(LOG_DEBUG, "%s:%d: Debug: " fmt "\n", \=

--                                __FILE__, __LINE__, ## __VA_ARGS__)
--#define info(fmt, ...)  tpm_log(LOG_INFO, "%s:%d: Info: " fmt "\n", \
--                                __FILE__, __LINE__, ## __VA_ARGS__)
--#define error(fmt, ...) tpm_log(LOG_ERR, "%s:%d: Error: " fmt "\n", \
--                                __FILE__, __LINE__, ## __VA_ARGS__)
--#define alert(fmt, ...) tpm_log(LOG_ALERT, "%s:%d: Alert: " fmt "\n", \=

--                                __FILE__, __LINE__, ## __VA_ARGS__)
-+#define debug(fmt, ...) tpm_log(LOG_DEBUG, "VTPMD[%d]: %s:%d: Debug: "
fmt "\n", \
-+                                dmi_id, __FILE__, __LINE__, ##
__VA_ARGS__)
-+#define info(fmt, ...)  tpm_log(LOG_INFO, "VTPMD[%d]: %s:%d: Info: "
fmt "\n", \
-+                                dmi_id, __FILE__, __LINE__, ##
__VA_ARGS__)
-+#define error(fmt, ...) tpm_log(LOG_ERR, "VTPMD[%d]: %s:%d: Error: "
fmt "\n", \
-+                                dmi_id, __FILE__, __LINE__, ##
__VA_ARGS__)
-+#define alert(fmt, ...) tpm_log(LOG_ALERT, "VTPMD[%d]: %s:%d: Alert: "
fmt "\n", \
-+                                dmi_id, __FILE__, __LINE__, ##
__VA_ARGS__)
-+#define debug_nostop(fmt, ...) tpm_log(LOG_DEBUG, "VTPMD[%d]: %s:%d:
Debug: " fmt, \
-+                                dmi_id, __FILE__, __LINE__, ##
__VA_ARGS__)
-+#define debug_more(fmt, ...) tpm_log(LOG_DEBUG, fmt, ## __VA_ARGS__)
-
- /*  min/max macros that also do strict type-checking */
-
diff --git a/tools/vtpm/vtpm-0.7.4.patch b/tools/vtpm/vtpm-0.7.4.patch
--- /dev/null
+++ b/tools/vtpm/vtpm-0.7.4.patch
@@ -0,0 +1,1138 @@
+diff -Naur tpm_emulator-0.7.4-orig/CMakeLists.txt
tpm_emulator-0.7.4/CMakeLists.txt
+--- tpm_emulator-0.7.4-orig/CMakeLists.txt    2012-09-17
13:16:27.832582475 -0400
++++ tpm_emulator-0.7.4/CMakeLists.txt    2012-09-17 13:16:41.621654594
-0400
+@@ -63,6 +63,7 @@
+ # include root directories
+ include_directories(${CMAKE_SOURCE_DIR})
+ include_directories(${CMAKE_BINARY_DIR})
++include_directories(../../vtpm_manager/manager)
+
+ # add internal libraries
+ add_subdirectory(tpm)
+diff -Naur tpm_emulator-0.7.4-orig/CMakeLists.txt.orig
tpm_emulator-0.7.4/CMakeLists.txt.orig
+--- tpm_emulator-0.7.4-orig/CMakeLists.txt.orig    1969-12-31
19:00:00.000000000 -0500
++++ tpm_emulator-0.7.4/CMakeLists.txt.orig    2011-12-20
13:30:06.000000000 -0500
+@@ -0,0 +1,80 @@
++# Software-based Trusted Platform Module (TPM) Emulator
++# Copyright (C) 2004-2010 Mario Strasser <mast@gmx.net>
++#
++# $Id: CMakeLists.txt 475 2011-12-20 18:21:19Z mast $
++
++project(TPM_Emulator C)
++
++cmake_minimum_required(VERSION 2.4)
++set(CMAKE_ALLOW_LOOSE_LOOP_CONSTRUCTS true)
++if(COMMAND cmake_policy)
++cmake_policy(SET CMP0003 NEW)
++endif()
++
++# enforce out of source build
++string(COMPARE EQUAL "${CMAKE_SOURCE_DIR}" "${CMAKE_BINARY_DIR}"
IS_INSOURCE)
++if(IS_INSOURCE)
++    message(FATAL_ERROR "${PROJECT_NAME} requires an out of source
build.")
++endif()
++
++# set project and build version
++set(${PROJECT_NAME}_VERSION_MAJOR 0)
++set(${PROJECT_NAME}_VERSION_MINOR 7)
++string(REGEX REPLACE ".*Revision: ([0-9]+).*" "\\1"
${PROJECT_NAME}_VERSION_BUILD "$Revision: 475 $")
++
++# create project configuration
++if(WIN32)
++STRING(REGEX REPLACE "\\\\" "/" PROGRAMFILES
"$ENV{PROGRAMFILES}/${PROJECT_NAME}")
++set(TPM_LOG_FILE "${PROGRAMFILES}/tpmd.log")
++set(TPM_STORAGE_NAME
"${PROGRAMFILES}/tpm_emulator-1_2_${${PROJECT_NAME}_VERSION_MAJOR}_${${PR=
OJECT_NAME}_VERSION_MINOR}")
++set(TPM_DEVICE_NAME "//./pipe/tpmd:0")
++elseif(APPLE)
++set(TPM_LOG_FILE "/private/var/log/tpmd.log")
++set(TPM_SOCKET_NAME "/private/var/run/tpm/tpmd_socket:0")
++set(TPM_STORAGE_NAME
"/private/var/lib/tpm/tpm_emulator-1_2_${${PROJECT_NAME}_VERSION_MAJOR}_$=
{${PROJECT_NAME}_VERSION_MINOR}")
++set(TPM_DEVICE_NAME "/dev/tpm")
++else()
++set(TPM_LOG_FILE "/var/log/tpmd.log")
++set(TPM_SOCKET_NAME "/var/run/tpm/tpmd_socket:0")
++set(TPM_STORAGE_NAME
"/var/lib/tpm/tpm_emulator-1_2_${${PROJECT_NAME}_VERSION_MAJOR}_${${PROJE=
CT_NAME}_VERSION_MINOR}")
++set(TPM_DEVICE_NAME "/dev/tpm")
++endif()
++configure_file(${CMAKE_CURRENT_SOURCE_DIR}/config.h.in
${CMAKE_CURRENT_BINARY_DIR}/config.h)
++add_definitions(-Wall -Werror -Wno-unused-parameter -Wpointer-arith
-Wcast-align -Wwrite-strings)
++if("${CMAKE_SYSTEM}" MATCHES "Linux")
++    add_definitions(-Wextra)
++endif()
++if(USE_OPENSSL)
++    add_definitions(-DUSE_OPENSSL)
++endif()
++include_directories("/opt/local/include")
++link_directories("/opt/local/lib")
++
++# configure CPack
++set(CPACK_PACKAGE_VERSION_MAJOR ${${PROJECT_NAME}_VERSION_MAJOR})
++set(CPACK_PACKAGE_VERSION_MINOR ${${PROJECT_NAME}_VERSION_MINOR})
++set(CPACK_SOURCE_PACKAGE_FILE_NAME
"tpm_emulator-${CPACK_PACKAGE_VERSION_MAJOR}.${CPACK_PACKAGE_VERSION_MINO=
R}.4")
++set(CPACK_SOURCE_GENERATOR "TGZ")
++set(CPACK_SOURCE_IGNORE_FILES ".svn/" "/build/" "/.project" "/.cproject=
")
++set(CPACK_GENERATOR "ZIP")
++set(CPACK_SET_DESTDIR ON)
++include(CPack)
++
++# include root directories
++include_directories(${CMAKE_SOURCE_DIR})
++include_directories(${CMAKE_BINARY_DIR})
++
++# add internal libraries
++add_subdirectory(tpm)
++add_subdirectory(mtm)
++add_subdirectory(crypto)
++
++# add TDDL
++add_subdirectory(tddl)
++
++# add kernel modules
++add_subdirectory(tpmd_dev)
++
++# add executables
++add_subdirectory(tpmd)
++
+diff -Naur tpm_emulator-0.7.4-orig/tpm/tpm_emulator_extern.h
tpm_emulator-0.7.4/tpm/tpm_emulator_extern.h
+--- tpm_emulator-0.7.4-orig/tpm/tpm_emulator_extern.h    2012-09-17
13:16:27.834582486 -0400
++++ tpm_emulator-0.7.4/tpm/tpm_emulator_extern.h    2012-09-17
13:16:41.621654594 -0400
+@@ -29,6 +29,8 @@
+   TPM_LOG_ERROR
+ };
+
++extern int dmi_id;
++
+ void (*tpm_log)(int priority, const char *fmt, ...);
+
+ #if defined(_WIN32) || defined(_WIN64)
+@@ -37,12 +39,16 @@
+ #define __BFILE__ ((strrchr(__FILE__, '/') ? : __FILE__ - 1) + 1)
+ #endif
+
+-#define debug(fmt, ...) tpm_log(TPM_LOG_DEBUG, "%s:%d: Debug: " fmt
"\n", \
+-                                __BFILE__, __LINE__, ## __VA_ARGS__)
+-#define info(fmt, ...)  tpm_log(TPM_LOG_INFO, "%s:%d: Info: " fmt "\n",=
 \
+-                                __BFILE__, __LINE__, ## __VA_ARGS__)
+-#define error(fmt, ...) tpm_log(TPM_LOG_ERROR, "%s:%d: Error: " fmt
"\n", \
+-                                __BFILE__, __LINE__, ## __VA_ARGS__)
++#define debug(fmt, ...) tpm_log(TPM_LOG_DEBUG, "VTPMD[%d]: %s:%d:
Debug: " fmt "\n", \
++                                dmi_id, __BFILE__, __LINE__, ##
__VA_ARGS__)
++#define info(fmt, ...)  tpm_log(TPM_LOG_INFO, "VTPMD[%d]: %s:%d: Info:
" fmt "\n", \
++                                dmi_id, __BFILE__, __LINE__, ##
__VA_ARGS__)
++#define error(fmt, ...) tpm_log(TPM_LOG_ERROR, "VTPMD[%d]: %s:%d:
Error: " fmt "\n", \
++                                dmi_id, __BFILE__, __LINE__, ##
__VA_ARGS__)
++#define debug_nostop(fmt, ...) tpm_log(TPM_LOG_DEBUG, "VTPMD[%d]:
%s:%d: Debug: " fmt, \
++                                dmi_id, __BFILE__, __LINE__, ##
__VA_ARGS__)
++#define debug_more(fmt, ...) tpm_log(TPM_LOG_DEBUG, fmt, ## __VA_ARGS__=
)
++
+ /* initialization */
+ int (*tpm_extern_init)(void);
+ void (*tpm_extern_release)(void);
+diff -Naur tpm_emulator-0.7.4-orig/tpmd/unix/tpmd.c
tpm_emulator-0.7.4/tpmd/unix/tpmd.c
+--- tpm_emulator-0.7.4-orig/tpmd/unix/tpmd.c    2012-09-17
13:16:27.839582511 -0400
++++ tpm_emulator-0.7.4/tpmd/unix/tpmd.c    2012-09-17
13:16:41.623654604 -0400
+@@ -30,9 +30,31 @@
+ #include <grp.h>
+ #include "config.h"
+ #include "tpm/tpm_emulator.h"
++#include "tpm/tpm_structures.h"
++#include "tpm/tpm_marshalling.h"
++#include "vtpm_manager.h"
+
+ #define TPM_COMMAND_TIMEOUT 30
+
++#define TPM_DAEMON_NAME     "tpmd"
++#define TPM_CMD_BUF_SIZE    4096
++#define TPM_RANDOM_DEVICE   "/dev/urandom"
++#undef  TPM_MKDIRS
++
++#define PVM_RX_FIFO_D "/var/vtpm/fifos/tpm_cmd_to_%d.fifo"
++#define PVM_TX_FIFO "/var/vtpm/fifos/tpm_rsp_from_all.fifo"
++#define HVM_RX_FIFO_D "/var/vtpm/socks/%d.socket"
++
++#define VTPM_RX_FIFO_D "/var/vtpm/fifos/vtpm_rsp_to_%d.fifo"
++#define VTPM_TX_FIFO "/var/vtpm/fifos/vtpm_cmd_from_all.fifo"
++
++static char *vtpm_rx_name=3DNULL;
++
++static int vtpm_tx_fh=3D-1, vtpm_rx_fh=3D-1;
++
++#define BUFFER_SIZE 2048
++
++
+ static volatile int stopflag =3D 0;
+ static int is_daemon =3D 0;
+ static int opt_debug =3D 0;
+@@ -44,6 +66,9 @@
+ static uint32_t tpm_config =3D 0;
+ extern const char *tpm_storage_file;
+
++static int vtpm_type =3D VTPM_TYPE_PVM;
++int dmi_id;
++
+ void my_log(int priority, const char *fmt, ...)
+ {
+     va_list ap, bp;
+@@ -156,35 +181,218 @@
+             exit(EXIT_SUCCESS);
+         }
+     } else {
+-        /* if no startup mode is given assume save if a configuration
+-           file is available, clear otherwise */
+-        int fh =3D open(tpm_storage_file, O_RDONLY);
+-        if (fh < 0) {
+-            tpm_startup =3D 1;
+-            info("no startup mode was specified; asuming 'clear'");
+-        } else {
+-            tpm_startup =3D 2;
+-            close(fh);
+-        }
++       tpm_startup =3D 1;
++       info("no startup mode was specified; asuming 'clear'");
+     }
++    /* GET VM TYPE */
++    ++optind;
++    if (optind < argc) {
++       if(!strcmp(argv[optind], "pvm")) {
++      vtpm_type =3D VTPM_TYPE_PVM;      // Get commands from vTPM
Manager through fifo
++       } else if (!strcmp(argv[optind], "hvm")) {
++      vtpm_type =3D VTPM_TYPE_HVM;      // Get commands from qemu via s=
ocket
++       } else {
++      error("Invalid vm mode '%s'; must be 'pvm', "
++        "or 'hvm' ", argv[optind]);
++      print_usage(argv[0]);
++      exit(EXIT_SUCCESS);
++       }
++    } else {
++       vtpm_type =3D VTPM_TYPE_PVM;
++       info("no vm mode specified; assuming 'pvm'");
++    }
++    /* GET DMI ID */
++    ++optind;
++    if(optind >=3D argc || sscanf(argv[optind], "%d", &dmi_id) !=3D 1) =
{
++       error("Missing or non-integer dmi_id specified!");
++       print_usage(argv[0]);
++       exit(EXIT_SUCCESS);
++    }
++}
++
++int vtpm_write_to_file(uint8_t *data, size_t data_length)
++{
++  int res, out_data_size, in_header_size;
++  BYTE *ptr, *out_data, *in_header;
++  UINT32 result, len, in_rsp_size;
++  UINT16 tag =3D VTPM_TAG_REQ;
++
++  printf("Saving NVM\n");
++  if (vtpm_tx_fh < 0) {
++     vtpm_tx_fh =3D open(VTPM_TX_FIFO, O_WRONLY);
++  }
++
++  if (vtpm_tx_fh < 0) {
++                return -1;
++  }
++
++  // Send request to VTPM Manager to encrypt data
++  out_data_size =3D len =3D VTPM_COMMAND_HEADER_SIZE_SRV + data_length;=

++
++  out_data =3D ptr =3D (BYTE *) malloc(len);
++
++  if (ptr =3D=3D NULL
++    || tpm_marshal_UINT32(&ptr, &len, dmi_id)
++    || tpm_marshal_UINT16(&ptr, &len, tag)
++    || tpm_marshal_UINT32(&ptr, &len, out_data_size - sizeof(uint32_t))=

++    || tpm_marshal_UINT32(&ptr, &len, VTPM_ORD_SAVENVM)
++    || tpm_marshal_BYTE_ARRAY(&ptr, &len, data, data_length)) {
++     free(out_data);
++     return -1;
++  }
++
++  printf("\tSending SaveNVM Command.\n");
++  res =3D write(vtpm_tx_fh, out_data, out_data_size);
++  free(out_data);
++  if (res !=3D out_data_size) return -1;
++
++  if (vtpm_rx_fh < 0) {
++    if (vtpm_rx_name =3D=3D NULL) {
++      vtpm_rx_name =3D malloc(10 + strlen(VTPM_RX_FIFO_D));
++      sprintf(vtpm_rx_name, VTPM_RX_FIFO_D, (uint32_t) dmi_id);
++    }
++        vtpm_rx_fh =3D open(vtpm_rx_name, O_RDONLY);
++  }
++
++  if (vtpm_rx_fh < 0) {
++                return -1;
++  }
++
++  // Read Header of response so we can get the size & status
++  in_header_size =3D len =3D VTPM_COMMAND_HEADER_SIZE_SRV;
++  in_header =3D ptr =3D malloc(in_header_size);
++
++  printf("\tReading SaveNVM header.\n");
++  res =3D read(vtpm_rx_fh, in_header, in_header_size);
++
++  if ( (res !=3D in_header_size)
++    || tpm_unmarshal_UINT32(&ptr, &len, (UINT32*)&dmi_id)
++    || tpm_unmarshal_UINT16(&ptr, &len, &tag)
++    || tpm_unmarshal_UINT32(&ptr, &len, &in_rsp_size)
++    || tpm_unmarshal_UINT32(&ptr, &len, &result) ) {
++     free(in_header);
++     return -1;
++  }
++  free(in_header);
++
++  if (result !=3D VTPM_SUCCESS) {
++      return -1;
++  }
++
++  printf("\tFinishing up SaveNVM\n");
++  return (0);
++}
++
++int vtpm_read_from_file(uint8_t **data, size_t *data_length)
++{
++   int res, out_data_size, in_header_size;
++   uint8_t *ptr, *out_data, *in_header;
++   UINT16 tag =3D VTPM_TAG_REQ;
++   UINT32 len, in_rsp_size, result;
++
++   printf("Loading NVM.\n");
++   if (vtpm_tx_fh < 0) {
++      vtpm_tx_fh =3D open(VTPM_TX_FIFO, O_WRONLY);
++   }
++
++   if (vtpm_tx_fh < 0) {
++      printf("Error in read_from_file:301\n");
++      return -1;
++   }
++
++   // Send request to VTPM Manager to encrypt data
++   out_data_size =3D len =3D VTPM_COMMAND_HEADER_SIZE_SRV;
++   out_data =3D ptr =3D (BYTE *) malloc(len);
++
++   if (ptr =3D=3D NULL
++     || tpm_marshal_UINT32(&ptr, &len, dmi_id)
++     || tpm_marshal_UINT16(&ptr, &len, tag)
++     || tpm_marshal_UINT32(&ptr, &len, out_data_size - sizeof(uint32_t)=
)
++     || tpm_marshal_UINT32(&ptr, &len, VTPM_ORD_LOADNVM)) {
++      free(out_data);
++      printf("Error in read_from_file:325\n");
++
++      return -1;
++   }
++
++   printf("\tSending LoadNVM command\n");
++   res =3D write(vtpm_tx_fh, out_data, out_data_size);
++   free(out_data);
++   if (res !=3D out_data_size)
++   {
++      printf("Error in read_from_file:335\n");
++      return -1;
++   }
++
++   if (vtpm_rx_fh < 0) {
++      if (vtpm_rx_name =3D=3D NULL) {
++     vtpm_rx_name =3D malloc(10 + strlen(VTPM_RX_FIFO_D));
++     sprintf(vtpm_rx_name, VTPM_RX_FIFO_D, (uint32_t) dmi_id);
++      }
++      vtpm_rx_fh =3D open(vtpm_rx_name, O_RDONLY);
++   }
++
++   if (vtpm_rx_fh < 0) {
++      printf("Error in read_from_file:352\n");
++      return -1;
++   }
++
++   // Read Header of response so we can get the size & status
++   in_header_size =3D len =3D VTPM_COMMAND_HEADER_SIZE_SRV;
++   in_header =3D ptr =3D malloc(in_header_size);
++
++   printf("\tReading LoadNVM header\n");
++   res =3D read(vtpm_rx_fh, in_header, in_header_size);
++
++   if ( (res !=3D in_header_size)
++     || tpm_unmarshal_UINT32(&ptr, &len, (UINT32*)&dmi_id)
++     || tpm_unmarshal_UINT16(&ptr, &len, &tag)
++     || tpm_unmarshal_UINT32(&ptr, &len, &in_rsp_size)
++     || tpm_unmarshal_UINT32(&ptr, &len, &result) ) {
++      free(in_header);
++      printf("Error in read_from_file:375\n");
++      return -1;
++   }
++   free(in_header);
++
++   if (result !=3D VTPM_SUCCESS) {
++      printf("Error in read_from_file:381\n");
++      return -1;
++   }
++
++   // Read Encrypted data from VTPM Manager
++   *data_length =3D in_rsp_size - VTPM_COMMAND_HEADER_SIZE_CLT;
++   *data =3D (uint8_t *) malloc(*data_length);
++
++   printf("\tReading clear data from LoadNVM.\n");
++   res =3D read(vtpm_rx_fh, *data, *data_length);
++
++   printf("\tReturing from loading NVM\n");
++   if (res !=3D (int)*data_length) {
++      free(*data);
++      printf("Error in read_from_file:398\n");
++      return -1;
++   } else {
++      return 0;
++   }
+ }
+
+ static void switch_uid_gid(void)
+ {
+-    if (opt_gid !=3D getgid()) {
+-        info("switching effective group ID to %d", opt_gid);=20
+-        if (setgid(opt_gid) =3D=3D -1) {
+-            error("switching effective group ID to %d failed: %s",
opt_gid, strerror(errno));
+-            exit(EXIT_FAILURE);
+-        }
+-    }
+-    if (opt_uid !=3D getuid()) {
+-        info("switching effective user ID to %d", opt_uid);
+-        if (setuid(opt_uid) =3D=3D -1) {
+-            error("switching effective user ID to %d failed: %s",
opt_uid, strerror(errno));
+-            exit(EXIT_FAILURE);
+-        }
+-    }
++   if (opt_gid !=3D getgid()) {
++      info("switching effective group ID to %d", opt_gid);=20
++      if (setgid(opt_gid) =3D=3D -1) {
++     error("switching effective group ID to %d failed: %s", opt_gid,
strerror(errno));
++     exit(EXIT_FAILURE);
++      }
++   }
++   if (opt_uid !=3D getuid()) {
++      info("switching effective user ID to %d", opt_uid);
++      if (setuid(opt_uid) =3D=3D -1) {
++     error("switching effective user ID to %d failed: %s", opt_uid,
strerror(errno));
++     exit(EXIT_FAILURE);
++      }
++   }
+ }
+
+ static void signal_handler(int sig)
+@@ -214,174 +422,175 @@
+     }
+ }
+
+-static void daemonize(void)
+-{
+-    pid_t sid, pid;
+-    info("daemonizing process");
+-    pid =3D fork();
+-    if (pid < 0) {
+-        error("fork() failed: %s", strerror(errno));
+-        exit(EXIT_FAILURE);
+-    }
+-    if (pid > 0) exit(EXIT_SUCCESS);
+-    pid =3D getpid();
+-    sid =3D setsid();
+-    if (sid < 0) {
+-        error("setsid() failed: %s", strerror(errno));
+-        exit(EXIT_FAILURE);
+-    }
+-    if (chdir("/") < 0) {
+-        error("chdir() failed: %s", strerror(errno));
+-        exit(EXIT_FAILURE);
+-    }
+-    close(STDIN_FILENO);
+-    close(STDOUT_FILENO);
+-    close(STDERR_FILENO);
+-    is_daemon =3D 1;
+-    info("process was successfully daemonized: pid=3D%d sid=3D%d", pid,=
 sid);
+-}
+-
+-static int mkdirs(const char *path)
+-{
+-    char *copy =3D strdup(path);
+-    char *p =3D strchr(copy + 1, '/');
+-    while (p !=3D NULL) {
+-        *p =3D '\0';
+-        if ((mkdir(copy, 0755) =3D=3D -1) && (errno !=3D EEXIST)) {
+-            free(copy);
+-            return errno;
+-        }
+-        *p =3D '/';
+-        p =3D strchr(p + 1, '/');
+-    }
+-    free(copy);
+-    return 0;
+-}
+-
+-static int init_socket(const char *name)
+-{
+-    int sock;
+-    struct sockaddr_un addr;
+-    info("initializing socket %s", name);
+-    sock =3D socket(AF_UNIX, SOCK_STREAM, 0);
+-    if (sock < 0) {
+-        error("socket(AF_UNIX) failed: %s", strerror(errno));
+-        return -1;
+-    }
+-    mkdirs(name);
+-    addr.sun_family =3D AF_UNIX;
+-    strncpy(addr.sun_path, name, sizeof(addr.sun_path));
+-    umask(0177);
+-    if (bind(sock, (struct sockaddr*)&addr, sizeof(addr)) < 0) {
+-        error("bind(%s) failed: %s", addr.sun_path, strerror(errno));
+-        close(sock);
+-        return -1;
+-    }
+-    listen(sock, 1);
+-    return sock;
+-}
+-
+ static void main_loop(void)
+ {
+-    int sock, fh, res;
+     int32_t in_len;
+     uint32_t out_len;
+-    uint8_t in[TPM_CMD_BUF_SIZE], *out;
++    uint8_t in[TPM_CMD_BUF_SIZE], *out, *addressed_out;
++    int guest_id=3D-1;
++    int i;
++    char *vtpm_rx_file=3DNULL;
++    int res;
++
++    int sockfd =3D -1;
+     struct sockaddr_un addr;
+-    socklen_t addr_len;
+-    fd_set rfds;
+-    struct timeval tv;
++    struct sockaddr_un client_addr;
++    unsigned int client_length;
++
++    int vtpm_tx_fh=3D-1, vtpm_rx_fh=3D-1;
++
++  if (vtpm_type =3D=3D VTPM_TYPE_PVM) {
++    vtpm_rx_file =3D malloc(10 + strlen(PVM_RX_FIFO_D));
++    sprintf(vtpm_rx_file, PVM_RX_FIFO_D, (uint32_t) dmi_id);
++  } else {
++    vtpm_rx_file =3D malloc(10 + strlen(HVM_RX_FIFO_D));
++    sprintf(vtpm_rx_file, HVM_RX_FIFO_D, (uint32_t) dmi_id);
++
++    if ( (sockfd =3D socket(PF_UNIX,SOCK_STREAM,0)) < 0) {
++          error("Unable to create socket. errno =3D %d\n", errno);
++      exit (-1);
++    }
++
++    memset(&addr, 0, sizeof(addr));
++    addr.sun_family =3D AF_UNIX;
++    strcpy(addr.sun_path,vtpm_rx_file );
++    unlink(addr.sun_path);
++  }
+
+     info("staring main loop");
+-    /* open UNIX socket */
+-    sock =3D init_socket(opt_socket_name);
+-    if (sock < 0) exit(EXIT_FAILURE);
+     /* init tpm emulator */
+-    debug("initializing TPM emulator");
+-    if (tpm_emulator_init(tpm_startup, tpm_config) !=3D 0) {
+-        error("tpm_emulator_init() failed");
+-        close(sock);
+-        unlink(opt_socket_name);
+-        exit(EXIT_FAILURE);
+-    }
++    debug("initializing TPM emulator: state=3D%d, type=3D%d, id=3D%d",
tpm_startup, vtpm_type, dmi_id);
++    /* Set config flags that must be on for vtpm operation */
++    tpm_config |=3D TPM_CONF_STRONG_PERSISTENCE;
++    tpm_config &=3D ~TPM_CONF_USE_INTERNAL_PRNG;
++    tpm_config |=3D TPM_CONF_GENERATE_EK;
++    tpm_config |=3D TPM_CONF_GENERATE_SEED_DAA;
++    /*Start the emulator */
++    tpm_emulator_init(tpm_startup, tpm_config);
+     /* start command processing */
+     while (!stopflag) {
+         /* wait for incomming connections */
+         debug("waiting for connections...");
+-        FD_ZERO(&rfds);
+-        FD_SET(sock, &rfds);
+-        tv.tv_sec =3D 10;
+-        tv.tv_usec =3D 0;
+-        res =3D select(sock + 1, &rfds, NULL, NULL, &tv);
+-        if (res < 0) {
+-            error("select(sock) failed: %s", strerror(errno));
+-            break;
+-        } else if (res =3D=3D 0) {
+-            continue;
++        if (vtpm_rx_fh < 0) {
++            if (vtpm_type =3D=3D VTPM_TYPE_PVM)
++            {
++                vtpm_rx_fh =3D open(vtpm_rx_file, O_RDONLY);
++            } else {
++                if (bind(sockfd, (struct sockaddr *)&addr,
sizeof(addr)) < 0) {
++                    error("Unable to bind(). errno =3D %d\n", errno);
++                    exit (-1);
++                }
++
++                if (listen(sockfd, 10) <0) {
++                    error("Unable to listen(). errno =3D %d\n", errno);=

++                    exit (-1);
++                }
++
++                 memset(&client_addr, 0, sizeof(client_addr));
++                 client_length =3D sizeof(client_addr);
++
++                 vtpm_rx_fh =3D vtpm_tx_fh =3D accept(sockfd, (struct
sockaddr *)&client_addr, &client_length);
++            }
+         }
+-        addr_len =3D sizeof(addr);
+-        fh =3D accept(sock, (struct sockaddr*)&addr, &addr_len);
+-        if (fh < 0) {
+-            error("accept() failed: %s", strerror(errno));
+-            continue;
++
++        /*Error Checking*/
++        if (vtpm_rx_fh < 0) {
++          error("Failed to open devices to listen to guest.\n");
++          exit(-1);
+         }
++
+         /* receive and handle commands */
+         in_len =3D 0;
+         do {
+             debug("waiting for commands...");
+-            FD_ZERO(&rfds);
+-            FD_SET(fh, &rfds);
+-            tv.tv_sec =3D TPM_COMMAND_TIMEOUT;
+-            tv.tv_usec =3D 0;
+-            res =3D select(fh + 1, &rfds, NULL, NULL, &tv);
+-            if (res < 0) {
+-                error("select(fh) failed: %s", strerror(errno));
+-                close(fh);
+-                break;
+-            } else if (res =3D=3D 0) {
+-#ifdef TPMD_DISCONNECT_IDLE_CLIENTS      =20
+-                info("connection closed due to inactivity");
+-                close(fh);
+-                break;
+-#else      =20
+-                continue;
+-#endif      =20
+-            }
+-            in_len =3D read(fh, in, sizeof(in));
+-            if (in_len > 0) {
++
++            in_len =3D read(vtpm_rx_fh, in, sizeof(in));
++            /*Magic size of minimum TPM command is 6*/
++            if (in_len < 6) {
++                info("Recv incomplete command of %d bytes.", in_len);
++                if (in_len <=3D 0) {
++                    close(vtpm_rx_fh);
++                    vtpm_rx_fh =3D -1;
++                    continue;
++                 }
++            } else {
++                /*Debug Printouts*/
+                 debug("received %d bytes", in_len);
++                debug_nostop("Recv[%d]: 0x", in_len);
++                for (i=3D0; i< in_len; i++)
++                    debug_more("%02x ", in[i]);
++                debug_more("\n");
++                /*Multiple Guest check*/
++                if (guest_id =3D=3D -1) {
++                    guest_id =3D *((int32_t *) in);
++                } else {
++                    if (guest_id !=3D *((int32_t *) in) ) {
++                        error("WARNING: More than one guest attached\n"=
);
++                    }
++                }
++
++                /*Open tx handle now*/
++                if (vtpm_tx_fh < 0) {
++                    if (vtpm_type =3D=3D VTPM_TYPE_PVM) {
++                        vtpm_tx_fh =3D open(PVM_TX_FIFO, O_WRONLY);
++                    } // No need to open the other direction for HVM
++                }
++                if (vtpm_tx_fh < 0) {
++                  error("Failed to open devices to respond to guest.\n"=
);
++                  exit(-1);
++                }
++
++                /*Handle the TPM command now*/
+                 out =3D NULL;
+-                res =3D tpm_handle_command(in, in_len, &out, &out_len);=

++                res =3D tpm_handle_command(in + sizeof(uint32_t), in_le=
n
- sizeof(uint32_t), &out, &out_len);
+                 if (res < 0) {
+                     error("tpm_handle_command() failed");
+                 } else {
+                     debug("sending %d bytes", out_len);
+-                    uint32_t len =3D 0;
+-                    while (len < out_len) {
+-                        res =3D write(fh, &out[len], out_len - len);
++            //Prepend the dmi_id
++                    addressed_out =3D (uint8_t *)
tpm_malloc(sizeof(uint32_t) + out_len);
++                    *(uint32_t *) addressed_out =3D *(uint32_t *) in;
++                    memcpy(addressed_out + sizeof(uint32_t), out,
out_len);
++                    out_len +=3D sizeof(uint32_t);
++                    /*End Prepend*/
++
++                    /*Perform write operation now*/
++                    while (out_len > 0) {
++                        res =3D write(vtpm_tx_fh, addressed_out, out_le=
n);
++
+                         if (res < 0) {
+-                            error("write(%d) failed: %s",
+-                                  out_len - len, strerror(errno));
++                            error("write(%d) failed: %s", out_len,
strerror(errno));
+                             break;
++                        } else {
++                          debug_nostop("Sent[%Zu]: ", out_len);
++                          for (i=3D0; (unsigned int)i< out_len; i++)
++                            debug_more("%02x ", addressed_out[i]);
++                          debug_more("\n");
+                         }
+-                        len +=3D res;
++                        out_len -=3D res;
+                     }
+                     tpm_free(out);
++                    tpm_free(addressed_out);
+                 }
+             }
+         } while (in_len > 0);
+-        close(fh);
+     }
++
+     /* shutdown tpm emulator */
+     tpm_emulator_shutdown();
+-    /* close socket */
+-    close(sock);
+-    unlink(opt_socket_name);
++    /* Close handles */
++    close(vtpm_tx_fh);
++    close(vtpm_rx_fh);
++    free(vtpm_rx_file);
+     info("main loop stopped");
+ }
+
+ int main(int argc, char **argv)
+ {
++    //Set load/store functions
++    tpm_write_to_storage =3D vtpm_write_to_file;
++    tpm_read_from_storage =3D vtpm_read_from_file;
++
+     openlog(argv[0], 0, LOG_DAEMON);
+     setlogmask(~LOG_MASK(LOG_DEBUG));
+     syslog(LOG_INFO, "--- separator ---\n");
+@@ -393,8 +602,6 @@
+     switch_uid_gid();
+     /* init signal handlers */
+     init_signal_handler();
+-    /* unless requested otherwiese, fork and daemonize process */
+-    if (!opt_foreground) daemonize();
+     /* start main processing loop */
+     main_loop();
+     info("stopping TPM Emulator daemon");
+diff -Naur tpm_emulator-0.7.4-orig/tpmd/unix/tpmd.c.orig
tpm_emulator-0.7.4/tpmd/unix/tpmd.c.orig
+--- tpm_emulator-0.7.4-orig/tpmd/unix/tpmd.c.orig    1969-12-31
19:00:00.000000000 -0500
++++ tpm_emulator-0.7.4/tpmd/unix/tpmd.c.orig    2011-12-20
13:30:06.000000000 -0500
+@@ -0,0 +1,403 @@
++/* Software-based Trusted Platform Module (TPM) Emulator
++ * Copyright (C) 2004-2010 Mario Strasser <mast@gmx.net>
++ *
++ * 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.
++ *
++ * $Id: tpmd.c 463 2011-06-08 14:25:04Z mast $
++ */
++
++#include <stdio.h>
++#include <stdlib.h>
++#include <unistd.h>
++#include <signal.h>
++#include <string.h>
++#include <errno.h>
++#include <syslog.h>
++#include <stdarg.h>
++#include <fcntl.h>
++#include <sys/stat.h>
++#include <sys/socket.h>
++#include <sys/un.h>
++#include <pwd.h>
++#include <grp.h>
++#include "config.h"
++#include "tpm/tpm_emulator.h"
++
++#define TPM_COMMAND_TIMEOUT 30
++
++static volatile int stopflag =3D 0;
++static int is_daemon =3D 0;
++static int opt_debug =3D 0;
++static int opt_foreground =3D 0;
++static const char *opt_socket_name =3D TPM_SOCKET_NAME;
++static uid_t opt_uid =3D 0;
++static gid_t opt_gid =3D 0;
++static int tpm_startup =3D 2;
++static uint32_t tpm_config =3D 0;
++extern const char *tpm_storage_file;
++
++void my_log(int priority, const char *fmt, ...)
++{
++    va_list ap, bp;
++    va_start(ap, fmt);
++    va_copy(bp, ap);
++    switch (priority) {
++      case TPM_LOG_DEBUG:
++        vsyslog(LOG_DEBUG, fmt, ap);
++        break;
++      case TPM_LOG_ERROR:
++        vsyslog(LOG_ERR, fmt, ap);
++        break;
++      case TPM_LOG_INFO:
++      default:
++        vsyslog(LOG_INFO, fmt, ap);
++        break;
++    }
++    va_end(ap);
++    if (!is_daemon && (priority !=3D TPM_LOG_DEBUG || opt_debug)) {
++        vprintf(fmt, bp);
++    }
++    va_end(bp);
++}
++
++static void print_usage(char *name)
++{
++    printf("usage: %s [-d] [-f] [-s storage file] [-u unix socket name]=
 "
++           "[-o user name] [-g group name] [-h] [startup mode]\n", name=
);
++    printf("  d : enable debug mode\n");
++    printf("  f : forces the application to run in the foreground\n");
++    printf("  s : storage file to use (default: %s)\n", tpm_storage_fil=
e);
++    printf("  u : unix socket name to use (default: %s)\n",
opt_socket_name);
++    printf("  o : effective user the application should run as\n");
++    printf("  g : effective group the application should run as\n");
++    printf("  h : print this help message\n");
++    printf("  startup mode : must be 'clear', "
++           "'save' (default) or 'deactivated\n");
++}
++
++static void parse_options(int argc, char **argv)
++{
++    char c;
++    struct passwd *pwd;
++    struct group *grp;
++    opt_uid =3D getuid();
++    opt_gid =3D getgid();
++    info("parsing options");
++    while ((c =3D getopt (argc, argv, "dfs:u:o:g:c:h")) !=3D -1) {
++        debug("handling option '-%c'", c);
++        switch (c) {
++            case 'd':
++                opt_debug =3D 1;
++                setlogmask(setlogmask(0) | LOG_MASK(LOG_DEBUG));
++                debug("debug mode enabled");
++                break;
++            case 'f':
++                debug("application is forced to run in foreground");
++                opt_foreground =3D 1;
++                break;
++            case 's':
++                tpm_storage_file =3D optarg;
++                debug("using storage file '%s'", tpm_storage_file);
++                break;
++            case 'u':
++                opt_socket_name =3D optarg;
++                debug("using unix socket '%s'", opt_socket_name);
++                break;
++            case 'o':
++                pwd  =3D getpwnam(optarg);
++                if (pwd =3D=3D NULL) {
++                    error("invalid user name '%s'\n", optarg);
++                    exit(EXIT_FAILURE);
++                }
++                opt_uid =3D pwd->pw_uid;
++                break;
++            case 'g':
++                grp  =3D getgrnam(optarg);
++                if (grp =3D=3D NULL) {
++                    error("invalid group name '%s'\n", optarg);
++                    exit(EXIT_FAILURE);
++                }
++                opt_gid =3D grp->gr_gid;
++                break;
++            case 'c':
++                tpm_config =3D strtol(optarg, NULL, 0);
++                debug("tpm_config =3D %04x", tpm_config);
++                break;
++            case '?':
++                error("unknown option '-%c'", optopt);
++                print_usage(argv[0]);
++                exit(EXIT_FAILURE);
++            case 'h':
++            default:
++                print_usage(argv[0]);
++                exit(EXIT_SUCCESS);
++        }
++    }
++    if (optind < argc) {
++        debug("startup mode =3D '%s'", argv[optind]);
++        if (!strcmp(argv[optind], "clear")) {
++            tpm_startup =3D 1;
++        } else if (!strcmp(argv[optind], "save")) {
++            tpm_startup =3D 2;
++        } else if (!strcmp(argv[optind], "deactivated")) {
++            tpm_startup =3D 3;
++        } else {
++            error("invalid startup mode '%s'; must be 'clear', "
++                  "'save' (default) or 'deactivated", argv[optind]);
++            print_usage(argv[0]);
++            exit(EXIT_SUCCESS);
++        }
++    } else {
++        /* if no startup mode is given assume save if a configuration
++           file is available, clear otherwise */
++        int fh =3D open(tpm_storage_file, O_RDONLY);
++        if (fh < 0) {
++            tpm_startup =3D 1;
++            info("no startup mode was specified; asuming 'clear'");
++        } else {
++            tpm_startup =3D 2;
++            close(fh);
++        }
++    }
++}
++
++static void switch_uid_gid(void)
++{
++    if (opt_gid !=3D getgid()) {
++        info("switching effective group ID to %d", opt_gid);=20
++        if (setgid(opt_gid) =3D=3D -1) {
++            error("switching effective group ID to %d failed: %s",
opt_gid, strerror(errno));
++            exit(EXIT_FAILURE);
++        }
++    }
++    if (opt_uid !=3D getuid()) {
++        info("switching effective user ID to %d", opt_uid);
++        if (setuid(opt_uid) =3D=3D -1) {
++            error("switching effective user ID to %d failed: %s",
opt_uid, strerror(errno));
++            exit(EXIT_FAILURE);
++        }
++    }
++}
++
++static void signal_handler(int sig)
++{
++    info("signal received: %d", sig);
++    if (sig =3D=3D SIGTERM || sig =3D=3D SIGQUIT || sig =3D=3D SIGINT) =
stopflag =3D 1;
++}
++
++static void init_signal_handler(void)
++{
++    info("installing signal handlers");
++    if (signal(SIGTERM, signal_handler) =3D=3D SIG_ERR) {
++        error("signal(SIGTERM) failed: %s", strerror(errno));
++        exit(EXIT_FAILURE);
++    }
++    if (signal(SIGQUIT, signal_handler) =3D=3D SIG_ERR) {
++        error("signal(SIGQUIT) failed: %s", strerror(errno));
++        exit(EXIT_FAILURE);
++    }
++    if (signal(SIGINT, signal_handler) =3D=3D SIG_ERR) {
++        error("signal(SIGINT) failed: %s", strerror(errno));
++        exit(EXIT_FAILURE);
++    }
++    if (signal(SIGPIPE, signal_handler) =3D=3D SIG_ERR) {
++        error("signal(SIGPIPE) failed: %s", strerror(errno));
++        exit(EXIT_FAILURE);
++    }
++}
++
++static void daemonize(void)
++{
++    pid_t sid, pid;
++    info("daemonizing process");
++    pid =3D fork();
++    if (pid < 0) {
++        error("fork() failed: %s", strerror(errno));
++        exit(EXIT_FAILURE);
++    }
++    if (pid > 0) exit(EXIT_SUCCESS);
++    pid =3D getpid();
++    sid =3D setsid();
++    if (sid < 0) {
++        error("setsid() failed: %s", strerror(errno));
++        exit(EXIT_FAILURE);
++    }
++    if (chdir("/") < 0) {
++        error("chdir() failed: %s", strerror(errno));
++        exit(EXIT_FAILURE);
++    }
++    close(STDIN_FILENO);
++    close(STDOUT_FILENO);
++    close(STDERR_FILENO);
++    is_daemon =3D 1;
++    info("process was successfully daemonized: pid=3D%d sid=3D%d", pid,=
 sid);
++}
++
++static int mkdirs(const char *path)
++{
++    char *copy =3D strdup(path);
++    char *p =3D strchr(copy + 1, '/');
++    while (p !=3D NULL) {
++        *p =3D '\0';
++        if ((mkdir(copy, 0755) =3D=3D -1) && (errno !=3D EEXIST)) {
++            free(copy);
++            return errno;
++        }
++        *p =3D '/';
++        p =3D strchr(p + 1, '/');
++    }
++    free(copy);
++    return 0;
++}
++
++static int init_socket(const char *name)
++{
++    int sock;
++    struct sockaddr_un addr;
++    info("initializing socket %s", name);
++    sock =3D socket(AF_UNIX, SOCK_STREAM, 0);
++    if (sock < 0) {
++        error("socket(AF_UNIX) failed: %s", strerror(errno));
++        return -1;
++    }
++    mkdirs(name);
++    addr.sun_family =3D AF_UNIX;
++    strncpy(addr.sun_path, name, sizeof(addr.sun_path));
++    umask(0177);
++    if (bind(sock, (struct sockaddr*)&addr, sizeof(addr)) < 0) {
++        error("bind(%s) failed: %s", addr.sun_path, strerror(errno));
++        close(sock);
++        return -1;
++    }
++    listen(sock, 1);
++    return sock;
++}
++
++static void main_loop(void)
++{
++    int sock, fh, res;
++    int32_t in_len;
++    uint32_t out_len;
++    uint8_t in[TPM_CMD_BUF_SIZE], *out;
++    struct sockaddr_un addr;
++    socklen_t addr_len;
++    fd_set rfds;
++    struct timeval tv;
++
++    info("staring main loop");
++    /* open UNIX socket */
++    sock =3D init_socket(opt_socket_name);
++    if (sock < 0) exit(EXIT_FAILURE);
++    /* init tpm emulator */
++    debug("initializing TPM emulator");
++    if (tpm_emulator_init(tpm_startup, tpm_config) !=3D 0) {
++        error("tpm_emulator_init() failed");
++        close(sock);
++        unlink(opt_socket_name);
++        exit(EXIT_FAILURE);
++    }
++    /* start command processing */
++    while (!stopflag) {
++        /* wait for incomming connections */
++        debug("waiting for connections...");
++        FD_ZERO(&rfds);
++        FD_SET(sock, &rfds);
++        tv.tv_sec =3D 10;
++        tv.tv_usec =3D 0;
++        res =3D select(sock + 1, &rfds, NULL, NULL, &tv);
++        if (res < 0) {
++            error("select(sock) failed: %s", strerror(errno));
++            break;
++        } else if (res =3D=3D 0) {
++            continue;
++        }
++        addr_len =3D sizeof(addr);
++        fh =3D accept(sock, (struct sockaddr*)&addr, &addr_len);
++        if (fh < 0) {
++            error("accept() failed: %s", strerror(errno));
++            continue;
++        }
++        /* receive and handle commands */
++        in_len =3D 0;
++        do {
++            debug("waiting for commands...");
++            FD_ZERO(&rfds);
++            FD_SET(fh, &rfds);
++            tv.tv_sec =3D TPM_COMMAND_TIMEOUT;
++            tv.tv_usec =3D 0;
++            res =3D select(fh + 1, &rfds, NULL, NULL, &tv);
++            if (res < 0) {
++                error("select(fh) failed: %s", strerror(errno));
++                close(fh);
++                break;
++            } else if (res =3D=3D 0) {
++#ifdef TPMD_DISCONNECT_IDLE_CLIENTS      =20
++                info("connection closed due to inactivity");
++                close(fh);
++                break;
++#else      =20
++                continue;
++#endif      =20
++            }
++            in_len =3D read(fh, in, sizeof(in));
++            if (in_len > 0) {
++                debug("received %d bytes", in_len);
++                out =3D NULL;
++                res =3D tpm_handle_command(in, in_len, &out, &out_len);=

++                if (res < 0) {
++                    error("tpm_handle_command() failed");
++                } else {
++                    debug("sending %d bytes", out_len);
++                    uint32_t len =3D 0;
++                    while (len < out_len) {
++                        res =3D write(fh, &out[len], out_len - len);
++                        if (res < 0) {
++                            error("write(%d) failed: %s",
++                                  out_len - len, strerror(errno));
++                            break;
++                        }
++                        len +=3D res;
++                    }
++                    tpm_free(out);
++                }
++            }
++        } while (in_len > 0);
++        close(fh);
++    }
++    /* shutdown tpm emulator */
++    tpm_emulator_shutdown();
++    /* close socket */
++    close(sock);
++    unlink(opt_socket_name);
++    info("main loop stopped");
++}
++
++int main(int argc, char **argv)
++{
++    openlog(argv[0], 0, LOG_DAEMON);
++    setlogmask(~LOG_MASK(LOG_DEBUG));
++    syslog(LOG_INFO, "--- separator ---\n");
++    tpm_log =3D my_log;
++    info("starting TPM Emulator daemon (1.2.%d.%d-%d)",
++         VERSION_MAJOR, VERSION_MINOR, VERSION_BUILD);
++    parse_options(argc, argv);
++    /* switch uid/gid if required */
++    switch_uid_gid();
++    /* init signal handlers */
++    init_signal_handler();
++    /* unless requested otherwiese, fork and daemonize process */
++    if (!opt_foreground) daemonize();
++    /* start main processing loop */
++    main_loop();
++    info("stopping TPM Emulator daemon");
++    closelog();
++    return EXIT_SUCCESS;
++}
diff --git a/tools/vtpm/vtpm.patch b/tools/vtpm/vtpm.patch
--- a/tools/vtpm/vtpm.patch
+++ /dev/null
@@ -1,716 +0,0 @@
-diff -uprN tpm_emulator/AUTHORS vtpm/AUTHORS
---- tpm_emulator/AUTHORS    2006-12-08 12:51:29.000000000 -0800
-+++ vtpm/AUTHORS    2006-12-13 16:38:52.000000000 -0800
-@@ -1,3 +1,3 @@
- Mario Strasser <mast@gmx.net>
- Heiko Stamer <stamer@gaos.org> [DAA]
--INTEL Corp <> [Dropped to Ring3]
-+INTEL Corp <> [VTPM Extensions]
-diff -uprN tpm_emulator/ChangeLog vtpm/ChangeLog
---- tpm_emulator/ChangeLog    2006-12-08 12:51:29.000000000 -0800
-+++ vtpm/ChangeLog    2006-12-13 16:38:52.000000000 -0800
-@@ -1,5 +1,6 @@
- ????-??-?? Intel Corp
-     * Moved module out of kernel to run as a ring 3 app
-+    * Modified save_to_file and load_from_file to call xen VTPM manager=

-
- 2006-06-23  Mario Strasser <mast@gmx.net>
-     * tpm_startup.c: behaviour of ST_CLEAR and storage of
-diff -uprN tpm_emulator/linux_module.h vtpm/linux_module.h
---- tpm_emulator/linux_module.h    2006-12-08 12:51:29.000000000 -0800
-+++ vtpm/linux_module.h    2007-01-09 14:49:06.000000000 -0800
-@@ -44,18 +44,26 @@
- #define TPM_DEVICE_NAME   "tpm"
- #define TPM_MODULE_NAME   "tpm_emulator"
-
-+/* debug and log output functions */
-+extern int dmi_id;
-+
- #ifdef DEBUG
--#define debug(fmt, ...) printf("TPMD: %s:%d: Debug: " fmt "\n", \
--                        __FILE__, __LINE__, ## __VA_ARGS__)
-+#define debug(fmt, ...) printf("TPMD[%d]: %s:%d: Debug: " fmt "\n", \
-+                        dmi_id, __FILE__, __LINE__, ## __VA_ARGS__)
-+#define debug_nostop(fmt, ...) printf("TPMD[%d]: %s:%d: Debug: " fmt, \=

-+                        dmi_id, __FILE__, __LINE__, ## __VA_ARGS__)
-+#define debug_more(fmt, ...) printf( fmt, ## __VA_ARGS__ )
- #else
- #define debug(fmt, ...)
-+#define debug_nostop(fmt, ...)
-+#define debug_more(fmt, ...)
- #endif
--#define info(fmt, ...)  printf("TPMD: %s:%d: Info: " fmt "\n", \
--                        __FILE__, __LINE__, ## __VA_ARGS__)
--#define error(fmt, ...) printf("TPMD: %s:%d: Error: " fmt "\n", \
--                        __FILE__, __LINE__, ## __VA_ARGS__)
--#define alert(fmt, ...) printf("TPMD: %s:%d: Alert: " fmt "\n", \
--                        __FILE__, __LINE__, ## __VA_ARGS__)
-+#define info(fmt, ...)  printf("TPMD[%d]: %s:%d: Info: " fmt "\n", \
-+                        dmi_id, __FILE__, __LINE__, ## __VA_ARGS__)
-+#define error(fmt, ...) printf("TPMD[%d]: %s:%d: Error: " fmt "\n", \
-+                        dmi_id, __FILE__, __LINE__, ## __VA_ARGS__)
-+#define alert(fmt, ...) printf("TPMD[%d]: %s:%d: Alert: " fmt "\n", \
-+                        dmi_id, __FILE__, __LINE__, ## __VA_ARGS__)
-
- /* memory allocation */
-
-diff -uprN tpm_emulator/Makefile vtpm/Makefile
---- tpm_emulator/Makefile    2006-12-08 12:51:29.000000000 -0800
-+++ vtpm/Makefile    2006-12-13 16:38:52.000000000 -0800
-@@ -7,7 +7,7 @@
- COMPILE_ARCH    ?=3D $(shell uname -m | sed -e s/i.86/x86_32/)
-
- # module settings
--BIN            :=3D tpm_emulator
-+BIN            :=3D vtpmd
- VERSION_MAJOR  :=3D 0
- VERSION_MINOR  :=3D 4
- VERSION_BUILD  :=3D $(shell date +"%s")
-@@ -22,7 +22,7 @@ TOOLS_INSTALL_DIR =3D $(DESTDIR)/usr/bin
-
- CC      :=3D gcc
- CFLAGS  +=3D -g -Wall $(INCLUDE) -DDEBUG
--CFLAGS  +=3D -I. -Itpm
-+CFLAGS  +=3D -I. -Itpm -I../../vtpm_manager/manager
-
- # Is the simulator running in it's own vm?
- #CFLAGS +=3D -DVTPM_MULTI_VM
-@@ -62,7 +62,6 @@ $(BIN):    $(src)/crypto/gmp.h $(src)/crypt
-
- install: $(BIN)
-     $(INSTALL_PROG) $(BIN) $(TOOLS_INSTALL_DIR)
--    @if [ ! -d "/var/tpm" ]; then mkdir /var/tpm; fi
-
- clean:
-     rm -f $(src)/crypto/gmp.h $(src)/crypto/libgmp.a $(OBJS)
-@@ -98,3 +97,4 @@ version:
-     @echo "#endif /* _TPM_VERSION_H_ */" >> $(src)/tpm_version.h
-
- .PHONY: all install clean dist gmp version
-+
-diff -uprN tpm_emulator/tpm/tpm_capability.c vtpm/tpm/tpm_capability.c
---- tpm_emulator/tpm/tpm_capability.c    2006-06-23 03:37:07.000000000
-0700
-+++ vtpm/tpm/tpm_capability.c    2007-01-10 10:00:49.000000000 -0800
-@@ -136,8 +136,18 @@ static TPM_RESULT cap_property(UINT32 su
-
-     case TPM_CAP_PROP_TIS_TIMEOUT:
-       debug("[TPM_CAP_PROP_TIS_TIMEOUT]");
--      /* TODO: TPM_CAP_PROP_TIS_TIMEOUT */
--      return TPM_FAIL;
-+      /* TODO: TPM_CAP_PROP_TIS_TIMEOUT: Measure these values and
determine correct ones */
-+      UINT32 len =3D *respSize =3D 16;
-+      BYTE *ptr =3D *resp =3D tpm_malloc(*respSize);
-+      if (ptr =3D=3D NULL ||
-+          tpm_marshal_UINT32(&ptr, &len, 200000) ||
-+          tpm_marshal_UINT32(&ptr, &len, 200000) ||
-+          tpm_marshal_UINT32(&ptr, &len, 200000) ||
-+          tpm_marshal_UINT32(&ptr, &len, 200000)) {
-+        tpm_free(*resp);
-+        return TPM_FAIL;
-+      }
-+      return TPM_SUCCESS;
-
-     case TPM_CAP_PROP_STARTUP_EFFECT:
-       debug("[TPM_CAP_PROP_STARTUP_EFFECT]");
-@@ -190,7 +200,11 @@ static TPM_RESULT cap_property(UINT32 su
-
-     case TPM_CAP_PROP_DURATION:
-       debug("[TPM_CAP_PROP_DURATION]");
--      /* TODO: TPM_CAP_PROP_DURATION */
-+      /* TODO: TPM_CAP_PROP_DURATION: Measure these values and return
accurate ones */
-+      BYTE dur[]=3D
{0x0,0x0,0x0,0xc,0x0,0x7,0xa1,0x20,0x0,0x1e,0x84,0x80,0x11,0xe1,0xa3,0x0}=
;
-+      *respSize =3D 16;
-+      *resp =3D tpm_malloc(*respSize);
-+      memcpy(*resp,dur,16);
-       return TPM_FAIL;
-
-     case TPM_CAP_PROP_ACTIVE_COUNTER:
-diff -uprN tpm_emulator/tpm/tpm_cmd_handler.c vtpm/tpm/tpm_cmd_handler.c=

---- tpm_emulator/tpm/tpm_cmd_handler.c    2008-02-27 16:35:41.000000000
-0500
-+++ vtpm/tpm/tpm_cmd_handler.c    2008-02-28 14:43:28.000000000 -0500
-@@ -94,12 +94,18 @@ void tpm_compute_out_param_digest(TPM_CO
-   sha1_ctx_t sha1;
-   UINT32 res =3D CPU_TO_BE32(rsp->result);
-   UINT32 ord =3D CPU_TO_BE32(ordinal);
-+  UINT32 offset =3D 0;
-
-   /* compute SHA1 hash */
-   sha1_init(&sha1);
-   sha1_update(&sha1, (BYTE*)&res, 4);
-   sha1_update(&sha1, (BYTE*)&ord, 4);
--  sha1_update(&sha1, rsp->param, rsp->paramSize);
-+  if (ordinal =3D=3D TPM_ORD_LoadKey2) {
-+      offset =3D 4;
-+  }
-+  if (rsp->paramSize - offset > 0) {
-+      sha1_update(&sha1, rsp->param + offset, rsp->paramSize - offset);=

-+  }
-   sha1_final(&sha1, rsp->auth1->digest);
-   if (rsp->auth2 !=3D NULL) memcpy(rsp->auth2->digest,
-     rsp->auth1->digest, sizeof(rsp->auth1->digest));
-diff -uprN tpm_emulator/tpm/tpm_data.c vtpm/tpm/tpm_data.c
---- tpm_emulator/tpm/tpm_data.c    2008-02-27 16:35:41.000000000 -0500
-+++ vtpm/tpm/tpm_data.c    2008-02-27 16:35:40.000000000 -0500
-@@ -1,6 +1,7 @@
- /* Software-Based Trusted Platform Module (TPM) Emulator for Linux
-  * Copyright (C) 2004 Mario Strasser <mast@gmx.net>,
-  *                    Swiss Federal Institute of Technology (ETH) Zuric=
h
-+ * Copyright (C) 2005 INTEL Corp
-  *
-  * This module is free software; you can redistribute it and/or modify
-  * it under the terms of the GNU General Public License as published
-@@ -15,10 +16,15 @@
-  * $Id: tpm_data.c 98 2006-05-07 14:16:29Z hstamer $
-  */
-
-+#include <sys/types.h>
-+#include <sys/stat.h>
-+#include <fcntl.h>
-+#include <unistd.h>
-+
- #include "tpm_emulator.h"
- #include "tpm_structures.h"
- #include "tpm_marshalling.h"
--#include "linux_module.h"
-+#include "vtpm_manager.h"
-
- TPM_DATA tpmData;
-
-@@ -158,45 +164,232 @@ void tpm_release_data(void)
- #include <sys/types.h>
- #include <sys/stat.h>
- #include <fcntl.h>
--#include <unistd.h>
-
--#define TPM_STORAGE_FILE "/var/tpm/tpm_emulator-1.2."
STR(VERSION_MAJOR) "." STR(VERSION_MINOR)
-+ static int vtpm_tx_fh=3D-1, vtpm_rx_fh=3D-1;
-+
-+#ifdef VTPM_MUTLI_VM
-+ #define DEV_FE "/dev/tpm"
-+#else
-+ #define VTPM_RX_FIFO_D  "/var/vtpm/fifos/vtpm_rsp_to_%d.fifo"
-+ #define VTPM_TX_FIFO  "/var/vtpm/fifos/vtpm_cmd_from_all.fifo"
-+
-+ extern int dmi_id;
-+ static char *vtpm_rx_name=3DNULL;
-+#endif
-
- static int write_to_file(uint8_t *data, size_t data_length)
- {
--  int res;
--  int fp;
--  fp =3D open(TPM_STORAGE_FILE, O_WRONLY | O_TRUNC | O_CREAT, S_IRUSR |=

S_IWUSR);
--  res =3D write(fp, data, data_length);
--  close(fp);
--  return (res =3D=3D data_length) ? 0 : -1;
-+  int res, out_data_size, in_header_size;
-+  BYTE *ptr, *out_data, *in_header;
-+  UINT32 result, len, in_rsp_size;
-+  UINT16 tag =3D VTPM_TAG_REQ;
-+  =20
-+  printf("Saving NVM\n");
-+  if (vtpm_tx_fh < 0) {
-+#ifdef VTPM_MUTLI_VM
-+    vtpm_tx_fh =3D open(DEV_FE, O_RDWR);
-+#else
-+    vtpm_tx_fh =3D open(VTPM_TX_FIFO, O_WRONLY);
-+#endif
-+  }
-+
-+  if (vtpm_tx_fh < 0) {
-+        return -1;
-+  }
-+
-+  // Send request to VTPM Manager to encrypt data
-+#ifdef VTPM_MUTLI_VM
-+  out_data_size =3D len =3D VTPM_COMMAND_HEADER_SIZE_CLT + data_length;=

-+#else
-+  out_data_size =3D len =3D VTPM_COMMAND_HEADER_SIZE_SRV + data_length;=

-+#endif
-+=20
-+  out_data =3D ptr =3D (BYTE *) malloc(len);
-+
-+  if (ptr =3D=3D NULL
-+#ifndef VTPM_MUTLI_VM
-+      || tpm_marshal_UINT32(&ptr, &len, dmi_id)
-+#endif
-+      || tpm_marshal_UINT16(&ptr, &len, tag)
-+#ifdef VTPM_MUTLI_VM
-+      || tpm_marshal_UINT32(&ptr, &len, out_data_size)
-+#else
-+      || tpm_marshal_UINT32(&ptr, &len, out_data_size - sizeof(uint32_t=
))
-+#endif=20
-+      || tpm_marshal_UINT32(&ptr, &len, VTPM_ORD_SAVENVM)
-+      || tpm_marshal_BYTE_ARRAY(&ptr, &len, data, data_length)) {
-+    free(out_data);
-+    return -1;
-+  }
-+=20
-+  printf("\tSending SaveNVM Command.\n");
-+  res =3D write(vtpm_tx_fh, out_data, out_data_size);
-+  free(out_data);
-+  if (res !=3D out_data_size) return -1;
-+
-+  if (vtpm_rx_fh < 0) {
-+#ifdef VTPM_MUTLI_VM
-+    vtpm_rx_fh =3D vtpm_tx_fh
-+#else
-+    if (vtpm_rx_name =3D=3D NULL) {
-+      vtpm_rx_name =3D malloc(10 + strlen(VTPM_RX_FIFO_D));
-+      sprintf(vtpm_rx_name, VTPM_RX_FIFO_D, (uint32_t) dmi_id);
-+    }
-+    vtpm_rx_fh =3D open(vtpm_rx_name, O_RDONLY);
-+#endif
-+  }
-+
-+  if (vtpm_rx_fh < 0) {
-+        return -1;
-+  }
-+=20
-+  // Read Header of response so we can get the size & status
-+#ifdef VTPM_MUTLI_VM
-+  in_header_size =3D len =3D VTPM_COMMAND_HEADER_SIZE_CLT;
-+#else
-+  in_header_size =3D len =3D VTPM_COMMAND_HEADER_SIZE_SRV;
-+#endif
-+  in_header =3D ptr =3D malloc(in_header_size);
-+=20
-+  printf("\tReading SaveNVM header.\n");
-+  res =3D read(vtpm_rx_fh, in_header, in_header_size);
-+
-+  if ( (res !=3D in_header_size)
-+#ifndef VTPM_MUTLI_VM
-+       || tpm_unmarshal_UINT32(&ptr, &len, (UINT32*)&dmi_id)
-+#endif
-+       || tpm_unmarshal_UINT16(&ptr, &len, &tag)
-+       || tpm_unmarshal_UINT32(&ptr, &len, &in_rsp_size)
-+       || tpm_unmarshal_UINT32(&ptr, &len, &result) ) {
-+      free(in_header);
-+      return -1;
-+  }
-+  free(in_header);
-+=20
-+  if (result !=3D VTPM_SUCCESS) {
-+      return -1;=20
-+  }
-+
-+#ifdef VTPM_MUTLI_VM
-+  close(vtpm_tx_fh); close(vtpm_rx_fh);
-+#endif
-+    =20
-+  printf("\tFinishing up SaveNVM\n");
-+  return (0);
- }
-
- static int read_from_file(uint8_t **data, size_t *data_length)
- {
--  int res;
--  int fp, file_status;
--  struct stat file_info;
--  fp =3D open(TPM_STORAGE_FILE, O_RDONLY, 0);
--  file_status =3D fstat(fp, &file_info);
--  if (file_status < 0) {
--    close(fp);
--    return -1;
--  }
-+  int res, out_data_size, in_header_size;
-+  uint8_t *ptr, *out_data, *in_header;
-+  UINT16 tag =3D VTPM_TAG_REQ;
-+  UINT32 len, in_rsp_size, result;
-+#ifdef VTPM_MUTLI_VM
-+    int vtpm_rx_fh, vtpm_tx_fh;
-+#endif
-+  =20
-+  printf("Loading NVM.\n");
-+  if (vtpm_tx_fh < 0) {
-+#ifdef VTPM_MUTLI_VM
-+    vtpm_tx_fh =3D open(DEV_FE, O_RDWR);
-+#else
-+    vtpm_tx_fh =3D open(VTPM_TX_FIFO, O_WRONLY);
-+#endif
-+  }
-
--  *data_length =3D file_info.st_size;
--  *data =3D tpm_malloc(*data_length);
--  if (*data =3D=3D NULL) {
--    close(fp);
-+  if (vtpm_tx_fh < 0) {
-+        return -1;
-+  }
-+
-+  // Send request to VTPM Manager to encrypt data
-+#ifdef VTPM_MUTLI_VM
-+  out_data_size =3D len =3D VTPM_COMMAND_HEADER_SIZE_CLT;
-+#else
-+  out_data_size =3D len =3D VTPM_COMMAND_HEADER_SIZE_SRV;
-+#endif
-+  out_data =3D ptr =3D (BYTE *) malloc(len);
-+
-+  if (ptr =3D=3D NULL
-+#ifndef VTPM_MUTLI_VM
-+      || tpm_marshal_UINT32(&ptr, &len, dmi_id)
-+#endif=20
-+      || tpm_marshal_UINT16(&ptr, &len, tag)
-+#ifdef VTPM_MUTLI_VM
-+      || tpm_marshal_UINT32(&ptr, &len, out_data_size)
-+#else
-+      || tpm_marshal_UINT32(&ptr, &len, out_data_size - sizeof(uint32_t=
))
-+#endif
-+      || tpm_marshal_UINT32(&ptr, &len, VTPM_ORD_LOADNVM)) {
-+    free(out_data);
-     return -1;
-   }
--  res =3D read(fp, *data, *data_length);
--  close(fp);
-+
-+  printf("\tSending LoadNVM command\n");
-+  res =3D write(vtpm_tx_fh, out_data, out_data_size);
-+  free(out_data);
-+  if (res !=3D out_data_size) return -1;
-+
-+    if (vtpm_rx_fh < 0) {
-+#ifdef VTPM_MUTLI_VM
-+    vtpm_rx_fh =3D vtpm_tx_fh;
-+#else
-+    if (vtpm_rx_name =3D=3D NULL) {
-+      vtpm_rx_name =3D malloc(10 + strlen(VTPM_RX_FIFO_D));
-+      sprintf(vtpm_rx_name, VTPM_RX_FIFO_D, (uint32_t) dmi_id);
-+    }
-+    vtpm_rx_fh =3D open(vtpm_rx_name, O_RDONLY);
-+#endif
-+  }
-+
-+  if (vtpm_rx_fh < 0) {
-+        return -1;
-+  }
-+=20
-+  // Read Header of response so we can get the size & status
-+#ifdef VTPM_MUTLI_VM
-+  in_header_size =3D len =3D VTPM_COMMAND_HEADER_SIZE_CLT;
-+#else
-+  in_header_size =3D len =3D VTPM_COMMAND_HEADER_SIZE_SRV;
-+#endif
-+  in_header =3D ptr =3D malloc(in_header_size);
-+=20
-+  printf("\tReading LoadNVM header\n");
-+  res =3D read(vtpm_rx_fh, in_header, in_header_size);
-+
-+  if ( (res !=3D in_header_size)
-+#ifndef VTPM_MUTLI_VM
-+       || tpm_unmarshal_UINT32(&ptr, &len, (UINT32*)&dmi_id)
-+#endif
-+       || tpm_unmarshal_UINT16(&ptr, &len, &tag)
-+       || tpm_unmarshal_UINT32(&ptr, &len, &in_rsp_size)
-+       || tpm_unmarshal_UINT32(&ptr, &len, &result) ) {
-+      free(in_header);
-+      return -1;
-+  }
-+  free(in_header);
-+=20
-+  if (result !=3D VTPM_SUCCESS) {
-+      return -1;=20
-+  }
-+
-+  // Read Encrypted data from VTPM Manager
-+  *data_length =3D in_rsp_size - VTPM_COMMAND_HEADER_SIZE_CLT;
-+  *data =3D (uint8_t *) malloc(*data_length);
-+
-+  printf("\tReading clear data from LoadNVM.\n");
-+  res =3D read(vtpm_rx_fh, *data, *data_length);
-+#ifdef VTPM_MUTLI_VM
-+  close(vtpm_rx_fh);close(vtpm_tx_fh);
-+#endif
-+  =20
-+  printf("\tReturing from loading NVM\n");
-   if (res !=3D *data_length) {
--    tpm_free(*data);
--    return -1;
-+      free(*data);
-+      return -1;
-+  } else {
-+      return 0;
-   }
--  return 0;
-+
- }
-
- #else
-diff -uprN tpm_emulator/tpmd.c vtpm/tpmd.c
---- tpm_emulator/tpmd.c    2006-12-08 12:51:29.000000000 -0800
-+++ vtpm/tpmd.c    2007-01-09 14:48:56.000000000 -0800
-@@ -21,12 +21,24 @@
- #include <sys/stat.h>
- #include <fcntl.h>
- #include <sys/time.h>
-+#include <sys/socket.h>
-+#include <sys/un.h>
-+#include <errno.h>
-
- #include "tpm_emulator.h"
-+#include "vtpm_manager.h"
-
--#define TPM_RX_FNAME "/var/tpm/tpm_in.fifo"
--#define TPM_TX_FNAME "/var/tpm/tpm_out.fifo"
-+#ifdef VTPM_MULTI_VM
-+ #define DEV_BE "/dev/vtpm"
-+#else
-+ #define PVM_RX_FIFO_D "/var/vtpm/fifos/tpm_cmd_to_%d.fifo"
-+ #define PVM_TX_FIFO "/var/vtpm/fifos/tpm_rsp_from_all.fifo"
-
-+ #define HVM_RX_FIFO_D "/var/vtpm/socks/%d.socket"
-+#endif
-+
-+ int dmi_id;
-+                      =20
- #define BUFFER_SIZE 2048
-
- static int devurandom=3D0;
-@@ -38,7 +50,7 @@ void get_random_bytes(void *buf, int nby
-   }
-
-   if (read(devurandom, buf, nbytes) !=3D nbytes) {
--      printf("Can't get random number.\n");
-+      error("Can't get random number.\n");
-       exit(-1);
-   }
- }
-@@ -52,105 +64,182 @@ uint64_t tpm_get_ticks(void)
-
- int main(int argc, char **argv)
- {
--  uint8_t in[BUFFER_SIZE], *out;
-+  uint8_t type, in[BUFFER_SIZE], *out, *addressed_out;
-+  char *vtpm_rx_file=3DNULL;
-   uint32_t out_size;
-   int in_size, written;
--  int i;
--  struct stat file_info;
-+  int i, guest_id=3D-1;
-
--  int tpm_tx_fh=3D-1, tpm_rx_fh=3D-1;
-+#ifndef VTPM_MULTI_VM
-+  int sockfd =3D -1;
-+  struct sockaddr_un addr;
-+  struct sockaddr_un client_addr;
-+  unsigned int client_length;
-+
-+#endif
-+
-+  int vtpm_tx_fh=3D-1, vtpm_rx_fh=3D-1;
-+#ifdef VTPM_MULTI_VM
-   if (argc < 2) {
--    printf("Usage: tpmd clear|save|deactivated\n" );
-+    error("Usage: tpmd clear|save|deactivated\n" );
-+#else
-+  if (argc < 4) {
-+    error("Usage: tpmd clear|save|deactivated pvm|hvm vtpmid\n" );
-+#endif
-       return -1;
-   }
-
-+#ifndef VTPM_MULTI_VM
-+  /* setup type of vm */
-+  if (!strcmp(argv[2], "pvm")) {
-+    type =3D VTPM_TYPE_PVM; // Get commands from vTPM Manager through f=
ifo
-+  } else if (!strcmp(argv[2], "hvm")) {
-+    type =3D VTPM_TYPE_HVM; // Get commands from qemu via socket
-+  } else {
-+    error("invalid vTPM type '%s'.\n", argv[2]);
-+  }
-+
-+  dmi_id =3D atoi(argv[3]);
-+
-+  if (type =3D=3D VTPM_TYPE_PVM) {
-+    vtpm_rx_file =3D malloc(10 + strlen(PVM_RX_FIFO_D));
-+    sprintf(vtpm_rx_file, PVM_RX_FIFO_D, (uint32_t) dmi_id);
-+  } else {
-+    vtpm_rx_file =3D malloc(10 + strlen(HVM_RX_FIFO_D));
-+    sprintf(vtpm_rx_file, HVM_RX_FIFO_D, (uint32_t) dmi_id);
-+
-+    if ( (sockfd =3D socket(PF_UNIX,SOCK_STREAM,0)) < 0) {
-+          error("Unable to create socket. errno =3D %d\n", errno);
-+      exit (-1);
-+    }
-+
-+    memset(&addr, 0, sizeof(addr));
-+    addr.sun_family =3D AF_UNIX;
-+    strcpy(addr.sun_path,vtpm_rx_file );
-+    unlink(addr.sun_path);
-+  }
-+#endif
-+
-+#ifdef VTPM_MULTI_VM
-+  info("Initializing tpm state: %s\n", argv[1]);
-+#else
-+  info("Initializing tpm state: %s, type: %s, id: %d\n", argv[1],
argv[2], dmi_id);
-+#endif
-+
-   /* initialize TPM emulator */
-   if (!strcmp(argv[1], "clear")) {
--    printf("Initializing tpm: %s\n", argv[1]);
-     tpm_emulator_init(1);
--  } else if (!strcmp(argv[1], "save")) {
--    printf("Initializing tpm: %s\n", argv[1]);
-+  } else if (!strcmp(argv[1], "save")) {
-     tpm_emulator_init(2);
-   } else if (!strcmp(argv[1], "deactivated")) {
--    printf("Initializing tpm: %s\n", argv[1]);
-     tpm_emulator_init(3);
-   } else {
--    printf("invalid startup mode '%s'; must be 'clear', "
-+    error("invalid startup mode '%s'; must be 'clear', "
-       "'save' (default) or 'deactivated", argv[1]);
-     return -1;
-   }
--
--  if ( stat(TPM_RX_FNAME, &file_info) =3D=3D -1) {
--    if ( mkfifo(TPM_RX_FNAME, S_IWUSR | S_IRUSR ) ) {
--      printf("Failed to create fifo %s.\n", TPM_RX_FNAME);
--      return -1;
--    }
--  }
--
--  if ( stat(TPM_TX_FNAME, &file_info) =3D=3D -1) {
--    if ( mkfifo(TPM_TX_FNAME, S_IWUSR | S_IRUSR ) ) {
--      printf("Failed to create fifo %s.\n", TPM_TX_FNAME);
--      return -1;
--    }
--  }
--
-+=20
-   while (1) {
- abort_command:
--    if (tpm_rx_fh < 0) {
--      tpm_rx_fh =3D open(TPM_RX_FNAME, O_RDONLY);
-+    if (vtpm_rx_fh < 0) {
-+#ifdef VTPM_MUTLI_VM
-+      vtpm_rx_fh =3D open(DEV_BE, O_RDWR);
-+#else
-+      if (type =3D=3D VTPM_TYPE_PVM) {
-+        vtpm_rx_fh =3D open(vtpm_rx_file, O_RDONLY);
-+      } else {
-+        if (bind(sockfd, (struct sockaddr *)&addr, sizeof(addr)) < 0) {=

-+          error("Unable to bind(). errno =3D %d\n", errno);
-+          exit (-1);
-+        }
-+
-+        if (listen(sockfd, 10) <0) {
-+          error("Unable to listen(). errno =3D %d\n", errno);
-+          exit (-1);
-+        }
-+
-+        memset(&client_addr, 0, sizeof(client_addr));
-+        client_length =3D sizeof(client_addr);
-+
-+        vtpm_rx_fh =3D vtpm_tx_fh =3D accept(sockfd, (struct sockaddr
*)&client_addr, &client_length);
-+      }
-+#endif
-     }
-   =20
--    if (tpm_rx_fh < 0) {
--      printf("ERROR: failed to open devices to listen to guest.\n");
-+    if (vtpm_rx_fh < 0) {
-+      error("Failed to open devices to listen to guest.\n");
-       return -1;
-     }
-   =20
--    if (tpm_tx_fh < 0) {
--      tpm_tx_fh =3D open(TPM_TX_FNAME, O_WRONLY);
--    }
--
--    if (tpm_tx_fh < 0) {
--      printf("ERROR: failed to open devices to respond to guest.\n");
--      return -1;
--    }
--
--    in_size =3D read(tpm_rx_fh, in, BUFFER_SIZE);
-+    in_size =3D read(vtpm_rx_fh, in, BUFFER_SIZE);
-     if (in_size < 6) { // Magic size of minium TPM command
--      printf("Recv[%d] to small: 0x", in_size);
-+      info("Recv incomplete command of %d bytes.", in_size);
-       if (in_size <=3D 0) {
--          close(tpm_rx_fh);
--          tpm_rx_fh =3D -1;
-+          close(vtpm_rx_fh);
-+          vtpm_rx_fh =3D -1;
-           goto abort_command;
-       }
-     } else {
--      printf("Recv[%d]: 0x", in_size);
-+      debug_nostop("Recv[%d]: 0x", in_size);
-       for (i=3D0; i< in_size; i++)
--        printf("%x ", in[i]);
--      printf("\n");
-+        debug_more("%x ", in[i]);
-+      debug_more("\n");
-     }
-
--  =20
--    if (tpm_handle_command(in, in_size, &out, &out_size) !=3D 0) {
--        printf("ERROR: Handler Failed.\n");
-+    if (guest_id =3D=3D -1) {
-+        guest_id =3D *((uint32_t *) in);
-+    } else {
-+        if (guest_id !=3D *((uint32_t *) in) ) {
-+            error("WARNING: More than one guest attached\n");
-+        }
-+    }
-+
-+    if (vtpm_tx_fh < 0) {
-+#ifdef VTPM_MUTLI_VM
-+      vtpm_tx_fh =3D open(DEV_BE, O_RDWR);
-+      vtpm_rx_fh =3D vtpm_tx_fh;
-+#else
-+      if (type =3D=3D VTPM_TYPE_PVM) {
-+        vtpm_tx_fh =3D open(PVM_TX_FIFO, O_WRONLY);
-+      } // No need to open the other direction for HVM
-+#endif
-+    }
-+
-+    if (vtpm_tx_fh < 0) {
-+      error("Failed to open devices to respond to guest.\n");
-+      return -1;
-+    }
-+
-+    // Handle the command, but skip the domain id header  =20
-+    if (tpm_handle_command(in + sizeof(uint32_t), in_size -
sizeof(uint32_t), &out, &out_size) !=3D 0) {
-+      error("Handler Failed.\n");
-     }
-
--    written =3D write(tpm_tx_fh, out, out_size);
-+    addressed_out =3D (uint8_t *) tpm_malloc(sizeof(uint32_t) + out_siz=
e);
-+    *(uint32_t *) addressed_out =3D *(uint32_t *) in;
-+    memcpy(addressed_out + sizeof(uint32_t), out, out_size);
-+
-+    written =3D write(vtpm_tx_fh, addressed_out, out_size +
sizeof(uint32_t));
-
--    if (written !=3D out_size ) {
--      printf("ERROR: Part of response not written %d/%d.\nAttempt: ",
written, out_size);
-+    if (written !=3D out_size + sizeof(uint32_t)) {
-+      error("Part of response not written %d/%d.\n", written, out_size)=
;
-     } else {
--      printf("Sent[%Zu]: ", out_size);
-+      debug_nostop("Sent[%Zu]: ", out_size + sizeof(uint32_t));
-+      for (i=3D0; i< out_size+ sizeof(uint32_t); i++)
-+        debug_more("%x ", addressed_out[i]);
-+      debug_more("\n");
-     }
--    for (i=3D0; i< out_size; i++)
--      printf("%x ", out[i]);
--    printf("\n");
-     tpm_free(out);
-+    tpm_free(addressed_out);
-
-   } // loop
-
-   tpm_emulator_shutdown();
-
--  close(tpm_tx_fh);
--  close(tpm_rx_fh);
-+  close(vtpm_tx_fh);
-+#ifndef VTPM_MUTLI_VM
-+  close(vtpm_rx_fh);
-+  free (vtpm_rx_file);
-+#endif
-
- }
--=20
1.7.4.4



--------------ms030704010609040205060800
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIDyjCC
A8YwggMvoAMCAQICBD/xyf0wDQYJKoZIhvcNAQEFBQAwLzELMAkGA1UEBhMCVVMxDzANBgNV
BAoTBkpIVUFQTDEPMA0GA1UECxMGQklTRENBMB4XDTEwMDYxMTE4MjIwNloXDTEzMDYxMTE4
NTIwNlowZjELMAkGA1UEBhMCVVMxDzANBgNVBAoTBkpIVUFQTDEPMA0GA1UECxMGUGVvcGxl
MTUwFgYDVQQLEw9WUE5Hcm91cC1CSVNEQ0EwGwYDVQQDExRNYXR0aGV3IEUgRmlvcmF2YW50
ZTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAnpbwVSP6o1Nb5lcW7dd3yTo9iBJdi7qz
4nANOMFPK7JOy5npKN1iiousl28U/scUJES55gPwAWYJK3uVyQAsA4adgDKi5DoD1UHDQEwp
bY7iHLJeq0NPr4BqYNqnCFPbE6HC8zSJrr4qKn+gVUQT39SIFqdiIPJwZL8FYTRQ/zsCAwEA
AaOCAbYwggGyMAsGA1UdDwQEAwIHgDArBgNVHRAEJDAigA8yMDEwMDYxMTE4MjIwNlqBDzIw
MTIwNzE3MjI1MjA2WjAbBg0rBgEEAbMlCwMBAQEBBAoWCGZpb3JhbWUxMBsGDSsGAQQBsyUL
AwEBAQIEChIIMDAxMDQyNjEwWAYJYIZIAYb6ax4BBEsMSVRoZSBwcml2YXRlIGtleSBjb3Jy
ZXNwb25kaW5nIHRvIHRoaXMgY2VydGlmaWNhdGUgbWF5IGhhdmUgYmVlbiBleHBvcnRlZC4w
KAYDVR0RBCEwH4EdTWF0dGhldy5GaW9yYXZhbnRlQGpodWFwbC5lZHUwUgYDVR0fBEswSTBH
oEWgQ6RBMD8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJU0RD
QTEOMAwGA1UEAxMFQ1JMNTYwHwYDVR0jBBgwFoAUCDUpmxH52EU2CyWmF2EJMB1yqeswHQYD
VR0OBBYEFO6LYxg6r9wHZ+zdQtBHn1dZ/YTNMAkGA1UdEwQCMAAwGQYJKoZIhvZ9B0EABAww
ChsEVjcuMQMCBLAwDQYJKoZIhvcNAQEFBQADgYEAJO9HQh4YNChVLzuZqK5ARJARD8JoujGZ
fdo75quvg2jXFQe2sEjvLnxJZgm/pv8fdZakq48CWwjYHKuvIp7sDjTEsQfo+y7SpN/N2NvJ
WU5SqfK1VgYtNLRRoGJUB5Q1aZ+Dg95g3kqpyfpUMISJL8IKVLtJVfN4fggFVUYZ9wwxggGr
MIIBpwIBATA3MC8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJ
U0RDQQIEP/HJ/TAJBgUrDgMCGgUAoIHLMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ
KoZIhvcNAQkFMQ8XDTEyMDkxNzE3NTI0MFowIwYJKoZIhvcNAQkEMRYEFKc1wjp+kmE0kjMy
K6/oTGjDugLtMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAK
BggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI
KoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEgYAUxbR1IWDOQOj9v4+3GL6p7XkNfXR0AuWT
jBAKO8ihVVIbKPpldN4rvGmXyC27nixOkOB7PmkrAZLLKyVbDLHipIiZ7+fA3WCm2temcqgn
J6MTiX55fIiNnHliWd2n0mxAQDKce51CE+liV25z6Qsr13cuQkIgIKGyWM2cj43jNgAAAAAA
AA==
--------------ms030704010609040205060800--


--===============3101777180007788348==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============3101777180007788348==--


From xen-devel-bounces@lists.xen.org Mon Sep 17 18:07:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 18: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 1TDfif-0004YE-Ar; Mon, 17 Sep 2012 18:06:53 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wdauchy@gmail.com>) id 1TDfid-0004Y9-I3
	for xen-devel@lists.xensource.com; Mon, 17 Sep 2012 18:06:51 +0000
Received: from [85.158.138.51:55195] by server-1.bemta-3.messagelabs.com id
	FB/7C-05884-AB667505; Mon, 17 Sep 2012 18:06:50 +0000
X-Env-Sender: wdauchy@gmail.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1347905208!29225680!1
X-Originating-IP: [209.85.160.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32751 invoked from network); 17 Sep 2012 18:06:50 -0000
Received: from mail-pb0-f43.google.com (HELO mail-pb0-f43.google.com)
	(209.85.160.43)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Sep 2012 18:06:50 -0000
Received: by pbbrq2 with SMTP id rq2so11963253pbb.30
	for <xen-devel@lists.xensource.com>;
	Mon, 17 Sep 2012 11:06:48 -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=tMRkgwN8hflDSeN3f3sYe5ZQk2zYuKnR8dX8TSS3BoA=;
	b=nbMa8UbVV2uW9fHUJg39m4TVPugBiNgW9r9KRpHHsnrMfP9EH5Ir36YhZdBRZNAd7f
	AXpsqdAwCn7NFzV0uIgqR73sbeJ/sZPc/xbPLtY7iBDBbc6/6k3SHygpvZunDtzfTgHP
	F5cggVKo6edHmDD/Of5MCK2U1Y1aC0k1IGYBPpcympJis0FicpSiTBtktEHTg9Y70Opn
	KaarMLZOF4lXvCBNGtUQiCUzujawe6S/XpjljdNiONS6b5GYn1mSGhQ8vEwwlz1OZiJa
	Vred94gpuXVovoMTwtw6TNksKiBX6DdSFKFdSZSAmO6OJSm0VaHSjXfnKka/1Nk0OyQJ
	351w==
Received: by 10.68.193.194 with SMTP id hq2mr23982679pbc.93.1347905207817;
	Mon, 17 Sep 2012 11:06:47 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.68.135.42 with HTTP; Mon, 17 Sep 2012 11:06:26 -0700 (PDT)
In-Reply-To: <1345133009-21941-12-git-send-email-konrad.wilk@oracle.com>
References: <1345133009-21941-1-git-send-email-konrad.wilk@oracle.com>
	<1345133009-21941-12-git-send-email-konrad.wilk@oracle.com>
From: William Dauchy <wdauchy@gmail.com>
Date: Mon, 17 Sep 2012 20:06:26 +0200
Message-ID: <CAJ75kXYG3uPmMhUwB9ivHt0w5gm14aqAynSWQwooWg65xLTzPw@mail.gmail.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org
Subject: Re: [Xen-devel] [PATCH 11/11] xen/mmu: Release just the MFN list,
 not MFN list and part of pagetables.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hello Konrad,

On Thu, Aug 16, 2012 at 6:03 PM, Konrad Rzeszutek Wilk
<konrad.wilk@oracle.com> wrote:
> (XEN) mm.c:908:d0 Error getting mfn 116a83 (pfn 14e2a) from L1 entry 8000000116a83067 for l1e_owner=0, pg_owner=0
> (XEN) mm.c:908:d0 Error getting mfn 4040 (pfn 5555555555555555) from L1 entry 0000000004040601 for l1e_owner=0, pg_owner=0

This is something I also have on my 3.4.x branch. Since then mmu.c has
change a lot; is there an easy fix to make a backport for 3.4.x?

-- 
William

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 17 18:07:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 18: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 1TDfif-0004YE-Ar; Mon, 17 Sep 2012 18:06:53 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wdauchy@gmail.com>) id 1TDfid-0004Y9-I3
	for xen-devel@lists.xensource.com; Mon, 17 Sep 2012 18:06:51 +0000
Received: from [85.158.138.51:55195] by server-1.bemta-3.messagelabs.com id
	FB/7C-05884-AB667505; Mon, 17 Sep 2012 18:06:50 +0000
X-Env-Sender: wdauchy@gmail.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1347905208!29225680!1
X-Originating-IP: [209.85.160.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32751 invoked from network); 17 Sep 2012 18:06:50 -0000
Received: from mail-pb0-f43.google.com (HELO mail-pb0-f43.google.com)
	(209.85.160.43)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Sep 2012 18:06:50 -0000
Received: by pbbrq2 with SMTP id rq2so11963253pbb.30
	for <xen-devel@lists.xensource.com>;
	Mon, 17 Sep 2012 11:06:48 -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=tMRkgwN8hflDSeN3f3sYe5ZQk2zYuKnR8dX8TSS3BoA=;
	b=nbMa8UbVV2uW9fHUJg39m4TVPugBiNgW9r9KRpHHsnrMfP9EH5Ir36YhZdBRZNAd7f
	AXpsqdAwCn7NFzV0uIgqR73sbeJ/sZPc/xbPLtY7iBDBbc6/6k3SHygpvZunDtzfTgHP
	F5cggVKo6edHmDD/Of5MCK2U1Y1aC0k1IGYBPpcympJis0FicpSiTBtktEHTg9Y70Opn
	KaarMLZOF4lXvCBNGtUQiCUzujawe6S/XpjljdNiONS6b5GYn1mSGhQ8vEwwlz1OZiJa
	Vred94gpuXVovoMTwtw6TNksKiBX6DdSFKFdSZSAmO6OJSm0VaHSjXfnKka/1Nk0OyQJ
	351w==
Received: by 10.68.193.194 with SMTP id hq2mr23982679pbc.93.1347905207817;
	Mon, 17 Sep 2012 11:06:47 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.68.135.42 with HTTP; Mon, 17 Sep 2012 11:06:26 -0700 (PDT)
In-Reply-To: <1345133009-21941-12-git-send-email-konrad.wilk@oracle.com>
References: <1345133009-21941-1-git-send-email-konrad.wilk@oracle.com>
	<1345133009-21941-12-git-send-email-konrad.wilk@oracle.com>
From: William Dauchy <wdauchy@gmail.com>
Date: Mon, 17 Sep 2012 20:06:26 +0200
Message-ID: <CAJ75kXYG3uPmMhUwB9ivHt0w5gm14aqAynSWQwooWg65xLTzPw@mail.gmail.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org
Subject: Re: [Xen-devel] [PATCH 11/11] xen/mmu: Release just the MFN list,
 not MFN list and part of pagetables.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hello Konrad,

On Thu, Aug 16, 2012 at 6:03 PM, Konrad Rzeszutek Wilk
<konrad.wilk@oracle.com> wrote:
> (XEN) mm.c:908:d0 Error getting mfn 116a83 (pfn 14e2a) from L1 entry 8000000116a83067 for l1e_owner=0, pg_owner=0
> (XEN) mm.c:908:d0 Error getting mfn 4040 (pfn 5555555555555555) from L1 entry 0000000004040601 for l1e_owner=0, pg_owner=0

This is something I also have on my 3.4.x branch. Since then mmu.c has
change a lot; is there an easy fix to make a backport for 3.4.x?

-- 
William

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 17 18:22:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 18:22:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDfxE-0004qw-53; Mon, 17 Sep 2012 18:21: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 1TDfxB-0004pf-Q7
	for xen-devel@lists.xen.org; Mon, 17 Sep 2012 18:21:54 +0000
Received: from [85.158.139.211:54710] by server-11.bemta-5.messagelabs.com id
	B1/56-24658-14A67505; Mon, 17 Sep 2012 18:21:53 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-3.tower-206.messagelabs.com!1347906110!18903640!3
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzAyMzE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22647 invoked from network); 17 Sep 2012 18:21:52 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-3.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Sep 2012 18:21:52 -0000
X-IronPort-AV: E=Sophos;i="4.80,437,1344211200"; d="scan'208";a="38109665"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Sep 2012 18:21:48 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Mon, 17 Sep 2012 14:21: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 1TDfx5-0000OF-HF;
	Mon, 17 Sep 2012 19:21:47 +0100
From: Anthony PERARD <anthony.perard@citrix.com>
To: Xen Devel <xen-devel@lists.xen.org>
Date: Mon, 17 Sep 2012 19:22:27 +0100
Message-ID: <1347906148-9606-9-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.12
In-Reply-To: <1347906148-9606-1-git-send-email-anthony.perard@citrix.com>
References: <1347906148-9606-1-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Cc: Anthony PERARD <anthony.perard@citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH V2 8/9] libxl_dom: Call the right switch
	logdirty for the right DM.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This patch dispatch the switch logdirty call depending on which device model
version is running.

The call to qemu-xen is synchrone, not like the one to qemu-xen-traditional.

Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
 tools/libxl/libxl_dom.c | 45 ++++++++++++++++++++++++++++++++++++++++++---
 1 file changed, 42 insertions(+), 3 deletions(-)

diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index e1de832..95da18e 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -685,10 +685,10 @@ static void logdirty_init(libxl__logdirty_switch *lds)
     libxl__ev_time_init(&lds->timeout);
 }
 
-void libxl__domain_suspend_common_switch_qemu_logdirty
-                               (int domid, unsigned enable, void *user)
+static void domain_suspend_switch_qemu_xen_traditional_logdirty
+                               (int domid, unsigned enable,
+                                libxl__save_helper_state *shs)
 {
-    libxl__save_helper_state *shs = user;
     libxl__egc *egc = shs->egc;
     libxl__domain_suspend_state *dss = CONTAINER_OF(shs, *dss, shs);
     libxl__logdirty_switch *lds = &dss->logdirty;
@@ -756,6 +756,45 @@ void libxl__domain_suspend_common_switch_qemu_logdirty
     switch_logdirty_done(egc,dss,-1);
 }
 
+static void domain_suspend_switch_qemu_xen_logdirty
+                               (int domid, unsigned enable,
+                                libxl__save_helper_state *shs)
+{
+    libxl__egc *egc = shs->egc;
+    libxl__domain_suspend_state *dss = CONTAINER_OF(shs, *dss, shs);
+    STATE_AO_GC(dss->ao);
+    int rc;
+
+    rc = libxl__qmp_set_global_dirty_log(gc, domid, enable);
+    if (!rc) {
+        libxl__xc_domain_saverestore_async_callback_done(egc, shs, 0);
+    } else {
+        LOG(ERROR,"logdirty switch failed (rc=%d), aborting suspend",rc);
+        libxl__xc_domain_saverestore_async_callback_done(egc, shs, -1);
+    }
+}
+
+void libxl__domain_suspend_common_switch_qemu_logdirty
+                               (int domid, unsigned enable, void *user)
+{
+    libxl__save_helper_state *shs = user;
+    libxl__egc *egc = shs->egc;
+    libxl__domain_suspend_state *dss = CONTAINER_OF(shs, *dss, shs);
+    STATE_AO_GC(dss->ao);
+
+    switch (libxl__device_model_version_running(gc, domid)) {
+    case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL:
+        domain_suspend_switch_qemu_xen_traditional_logdirty(domid, enable, shs);
+        break;
+    case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN:
+        domain_suspend_switch_qemu_xen_logdirty(domid, enable, shs);
+        break;
+    default:
+        LOG(ERROR,"logdirty switch failed"
+            ", no valid device model version found, aborting suspend");
+        libxl__xc_domain_saverestore_async_callback_done(egc, shs, -1);
+    }
+}
 static void switch_logdirty_timeout(libxl__egc *egc, libxl__ev_time *ev,
                                     const struct timeval *requested_abs)
 {
-- 
Anthony PERARD


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 17 18:22:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 18:22:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDfxE-0004qw-53; Mon, 17 Sep 2012 18:21: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 1TDfxB-0004pf-Q7
	for xen-devel@lists.xen.org; Mon, 17 Sep 2012 18:21:54 +0000
Received: from [85.158.139.211:54710] by server-11.bemta-5.messagelabs.com id
	B1/56-24658-14A67505; Mon, 17 Sep 2012 18:21:53 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-3.tower-206.messagelabs.com!1347906110!18903640!3
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzAyMzE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22647 invoked from network); 17 Sep 2012 18:21:52 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-3.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Sep 2012 18:21:52 -0000
X-IronPort-AV: E=Sophos;i="4.80,437,1344211200"; d="scan'208";a="38109665"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Sep 2012 18:21:48 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Mon, 17 Sep 2012 14:21: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 1TDfx5-0000OF-HF;
	Mon, 17 Sep 2012 19:21:47 +0100
From: Anthony PERARD <anthony.perard@citrix.com>
To: Xen Devel <xen-devel@lists.xen.org>
Date: Mon, 17 Sep 2012 19:22:27 +0100
Message-ID: <1347906148-9606-9-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.12
In-Reply-To: <1347906148-9606-1-git-send-email-anthony.perard@citrix.com>
References: <1347906148-9606-1-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Cc: Anthony PERARD <anthony.perard@citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH V2 8/9] libxl_dom: Call the right switch
	logdirty for the right DM.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This patch dispatch the switch logdirty call depending on which device model
version is running.

The call to qemu-xen is synchrone, not like the one to qemu-xen-traditional.

Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
 tools/libxl/libxl_dom.c | 45 ++++++++++++++++++++++++++++++++++++++++++---
 1 file changed, 42 insertions(+), 3 deletions(-)

diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index e1de832..95da18e 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -685,10 +685,10 @@ static void logdirty_init(libxl__logdirty_switch *lds)
     libxl__ev_time_init(&lds->timeout);
 }
 
-void libxl__domain_suspend_common_switch_qemu_logdirty
-                               (int domid, unsigned enable, void *user)
+static void domain_suspend_switch_qemu_xen_traditional_logdirty
+                               (int domid, unsigned enable,
+                                libxl__save_helper_state *shs)
 {
-    libxl__save_helper_state *shs = user;
     libxl__egc *egc = shs->egc;
     libxl__domain_suspend_state *dss = CONTAINER_OF(shs, *dss, shs);
     libxl__logdirty_switch *lds = &dss->logdirty;
@@ -756,6 +756,45 @@ void libxl__domain_suspend_common_switch_qemu_logdirty
     switch_logdirty_done(egc,dss,-1);
 }
 
+static void domain_suspend_switch_qemu_xen_logdirty
+                               (int domid, unsigned enable,
+                                libxl__save_helper_state *shs)
+{
+    libxl__egc *egc = shs->egc;
+    libxl__domain_suspend_state *dss = CONTAINER_OF(shs, *dss, shs);
+    STATE_AO_GC(dss->ao);
+    int rc;
+
+    rc = libxl__qmp_set_global_dirty_log(gc, domid, enable);
+    if (!rc) {
+        libxl__xc_domain_saverestore_async_callback_done(egc, shs, 0);
+    } else {
+        LOG(ERROR,"logdirty switch failed (rc=%d), aborting suspend",rc);
+        libxl__xc_domain_saverestore_async_callback_done(egc, shs, -1);
+    }
+}
+
+void libxl__domain_suspend_common_switch_qemu_logdirty
+                               (int domid, unsigned enable, void *user)
+{
+    libxl__save_helper_state *shs = user;
+    libxl__egc *egc = shs->egc;
+    libxl__domain_suspend_state *dss = CONTAINER_OF(shs, *dss, shs);
+    STATE_AO_GC(dss->ao);
+
+    switch (libxl__device_model_version_running(gc, domid)) {
+    case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL:
+        domain_suspend_switch_qemu_xen_traditional_logdirty(domid, enable, shs);
+        break;
+    case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN:
+        domain_suspend_switch_qemu_xen_logdirty(domid, enable, shs);
+        break;
+    default:
+        LOG(ERROR,"logdirty switch failed"
+            ", no valid device model version found, aborting suspend");
+        libxl__xc_domain_saverestore_async_callback_done(egc, shs, -1);
+    }
+}
 static void switch_logdirty_timeout(libxl__egc *egc, libxl__ev_time *ev,
                                     const struct timeval *requested_abs)
 {
-- 
Anthony PERARD


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 17 18:22:07 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 18:22: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 1TDfxB-0004pz-GE; Mon, 17 Sep 2012 18:21:53 +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 1TDfxA-0004pQ-Eh
	for xen-devel@lists.xen.org; Mon, 17 Sep 2012 18:21:52 +0000
Received: from [85.158.139.211:35713] by server-9.bemta-5.messagelabs.com id
	03/54-20529-F3A67505; Mon, 17 Sep 2012 18:21:51 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-5.tower-206.messagelabs.com!1347906108!18863259!3
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzAyMzE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4237 invoked from network); 17 Sep 2012 18:21:51 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-5.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Sep 2012 18:21:51 -0000
X-IronPort-AV: E=Sophos;i="4.80,437,1344211200"; d="scan'208";a="38109660"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Sep 2012 18:21:47 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Mon, 17 Sep 2012 14:21: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 1TDfx5-0000OF-B7;
	Mon, 17 Sep 2012 19:21:47 +0100
From: Anthony PERARD <anthony.perard@citrix.com>
To: Xen Devel <xen-devel@lists.xen.org>
Date: Mon, 17 Sep 2012 19:22:23 +0100
Message-ID: <1347906148-9606-5-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.12
In-Reply-To: <1347906148-9606-1-git-send-email-anthony.perard@citrix.com>
References: <1347906148-9606-1-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Cc: Anthony PERARD <anthony.perard@citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH V2 4/9] libxl_qmp: Introduces helpers to create
	an argument list.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Those functions will be used to create a "list" of parameters that contain more
than just strings. This list is converted by qmp_send to a string to be sent to
QEMU.

Those functions will be used in the next two patches, so right now there are
not compiled.

Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
 tools/libxl/libxl_qmp.c | 53 +++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 53 insertions(+)

diff --git a/tools/libxl/libxl_qmp.c b/tools/libxl/libxl_qmp.c
index 07a8bd5..1dd5c6c 100644
--- a/tools/libxl/libxl_qmp.c
+++ b/tools/libxl/libxl_qmp.c
@@ -623,6 +623,59 @@ static void qmp_free_handler(libxl__qmp_handler *qmp)
     free(qmp);
 }
 
+#if 0
+/*
+ * QMP Parameters Helpers
+ * Those functions does not use the gc, because of the internal usage of
+ * flexarray that does not support it.
+ * The allocated *param need to be free with libxl__json_object_free(gc, param)
+ */
+static void qmp_parameters_common_add(libxl__gc *gc,
+                                      libxl__json_object **param,
+                                      const char *name,
+                                      libxl__json_object *obj)
+{
+    libxl__json_map_node *arg = NULL;
+
+    if (!*param) {
+        *param = libxl__json_object_alloc(NOGC, JSON_MAP);
+    }
+
+    arg = libxl__zalloc(NOGC, sizeof(*arg));
+
+    arg->map_key = libxl__strdup(NOGC, name);
+    arg->obj = obj;
+
+    flexarray_append((*param)->u.map, arg);
+}
+
+static void qmp_parameters_add_string(libxl__gc *gc,
+                                      libxl__json_object **param,
+                                      const char *name, const char *argument)
+{
+    libxl__json_object *obj;
+
+    obj = libxl__json_object_alloc(NOGC, JSON_STRING);
+    obj->u.string = libxl__strdup(NOGC, argument);
+
+    qmp_parameters_common_add(gc, param, name, obj);
+}
+
+static void qmp_parameters_add_bool(libxl__gc *gc,
+                                    libxl__json_object **param,
+                                    const char *name, bool b)
+{
+    libxl__json_object *obj;
+
+    obj = libxl__json_object_alloc(NOGC, JSON_TRUE);
+    qmp_parameters_common_add(gc, param, name, obj);
+}
+
+#define QMP_PARAMETERS_SPRINTF(gc, args, name, format, ...) \
+    qmp_parameters_add_string(gc, args, name, \
+                              libxl__sprintf(gc, format, __VA_ARGS__))
+#endif
+
 /*
  * API
  */
-- 
Anthony PERARD


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 17 18:22:07 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 18:22: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 1TDfxB-0004pz-GE; Mon, 17 Sep 2012 18:21:53 +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 1TDfxA-0004pQ-Eh
	for xen-devel@lists.xen.org; Mon, 17 Sep 2012 18:21:52 +0000
Received: from [85.158.139.211:35713] by server-9.bemta-5.messagelabs.com id
	03/54-20529-F3A67505; Mon, 17 Sep 2012 18:21:51 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-5.tower-206.messagelabs.com!1347906108!18863259!3
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzAyMzE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4237 invoked from network); 17 Sep 2012 18:21:51 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-5.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Sep 2012 18:21:51 -0000
X-IronPort-AV: E=Sophos;i="4.80,437,1344211200"; d="scan'208";a="38109660"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Sep 2012 18:21:47 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Mon, 17 Sep 2012 14:21: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 1TDfx5-0000OF-B7;
	Mon, 17 Sep 2012 19:21:47 +0100
From: Anthony PERARD <anthony.perard@citrix.com>
To: Xen Devel <xen-devel@lists.xen.org>
Date: Mon, 17 Sep 2012 19:22:23 +0100
Message-ID: <1347906148-9606-5-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.12
In-Reply-To: <1347906148-9606-1-git-send-email-anthony.perard@citrix.com>
References: <1347906148-9606-1-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Cc: Anthony PERARD <anthony.perard@citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH V2 4/9] libxl_qmp: Introduces helpers to create
	an argument list.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Those functions will be used to create a "list" of parameters that contain more
than just strings. This list is converted by qmp_send to a string to be sent to
QEMU.

Those functions will be used in the next two patches, so right now there are
not compiled.

Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
 tools/libxl/libxl_qmp.c | 53 +++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 53 insertions(+)

diff --git a/tools/libxl/libxl_qmp.c b/tools/libxl/libxl_qmp.c
index 07a8bd5..1dd5c6c 100644
--- a/tools/libxl/libxl_qmp.c
+++ b/tools/libxl/libxl_qmp.c
@@ -623,6 +623,59 @@ static void qmp_free_handler(libxl__qmp_handler *qmp)
     free(qmp);
 }
 
+#if 0
+/*
+ * QMP Parameters Helpers
+ * Those functions does not use the gc, because of the internal usage of
+ * flexarray that does not support it.
+ * The allocated *param need to be free with libxl__json_object_free(gc, param)
+ */
+static void qmp_parameters_common_add(libxl__gc *gc,
+                                      libxl__json_object **param,
+                                      const char *name,
+                                      libxl__json_object *obj)
+{
+    libxl__json_map_node *arg = NULL;
+
+    if (!*param) {
+        *param = libxl__json_object_alloc(NOGC, JSON_MAP);
+    }
+
+    arg = libxl__zalloc(NOGC, sizeof(*arg));
+
+    arg->map_key = libxl__strdup(NOGC, name);
+    arg->obj = obj;
+
+    flexarray_append((*param)->u.map, arg);
+}
+
+static void qmp_parameters_add_string(libxl__gc *gc,
+                                      libxl__json_object **param,
+                                      const char *name, const char *argument)
+{
+    libxl__json_object *obj;
+
+    obj = libxl__json_object_alloc(NOGC, JSON_STRING);
+    obj->u.string = libxl__strdup(NOGC, argument);
+
+    qmp_parameters_common_add(gc, param, name, obj);
+}
+
+static void qmp_parameters_add_bool(libxl__gc *gc,
+                                    libxl__json_object **param,
+                                    const char *name, bool b)
+{
+    libxl__json_object *obj;
+
+    obj = libxl__json_object_alloc(NOGC, JSON_TRUE);
+    qmp_parameters_common_add(gc, param, name, obj);
+}
+
+#define QMP_PARAMETERS_SPRINTF(gc, args, name, format, ...) \
+    qmp_parameters_add_string(gc, args, name, \
+                              libxl__sprintf(gc, format, __VA_ARGS__))
+#endif
+
 /*
  * API
  */
-- 
Anthony PERARD


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 17 18:22:07 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 18:22: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 1TDfxF-0004rm-Gb; Mon, 17 Sep 2012 18:21:57 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony.perard@citrix.com>) id 1TDfxC-0004qI-OR
	for xen-devel@lists.xen.org; Mon, 17 Sep 2012 18:21:55 +0000
Received: from [85.158.137.99:35509] by server-6.bemta-3.messagelabs.com id
	A1/A2-29694-14A67505; Mon, 17 Sep 2012 18:21:53 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-3.tower-217.messagelabs.com!1347906111!12971293!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzAyMzE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31183 invoked from network); 17 Sep 2012 18:21:52 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-3.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Sep 2012 18:21:52 -0000
X-IronPort-AV: E=Sophos;i="4.80,437,1344211200"; d="scan'208";a="38109666"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Sep 2012 18:21:48 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Mon, 17 Sep 2012 14:21: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 1TDfx5-0000OF-Cc;
	Mon, 17 Sep 2012 19:21:47 +0100
From: Anthony PERARD <anthony.perard@citrix.com>
To: Xen Devel <xen-devel@lists.xen.org>
Date: Mon, 17 Sep 2012 19:22:24 +0100
Message-ID: <1347906148-9606-6-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.12
In-Reply-To: <1347906148-9606-1-git-send-email-anthony.perard@citrix.com>
References: <1347906148-9606-1-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Cc: Anthony PERARD <anthony.perard@citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH V2 5/9] libxl_qmp: Use qmp_parameters_*
	functions for param list of a QMP command.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
 tools/libxl/libxl_qmp.c | 96 +++++++++++++++++--------------------------------
 1 file changed, 32 insertions(+), 64 deletions(-)

diff --git a/tools/libxl/libxl_qmp.c b/tools/libxl/libxl_qmp.c
index 1dd5c6c..ed67431 100644
--- a/tools/libxl/libxl_qmp.c
+++ b/tools/libxl/libxl_qmp.c
@@ -78,7 +78,7 @@ struct libxl__qmp_handler {
 };
 
 static int qmp_send(libxl__qmp_handler *qmp,
-                    const char *cmd, libxl_key_value_list *args,
+                    const char *cmd, libxl__json_object *args,
                     qmp_callback_t callback, void *opaque,
                     qmp_request_context *context);
 
@@ -502,7 +502,7 @@ static int qmp_next(libxl__gc *gc, libxl__qmp_handler *qmp)
 }
 
 static char *qmp_send_prepare(libxl__gc *gc, libxl__qmp_handler *qmp,
-                              const char *cmd, libxl_key_value_list *args,
+                              const char *cmd, libxl__json_object *args,
                               qmp_callback_t callback, void *opaque,
                               qmp_request_context *context)
 {
@@ -526,7 +526,7 @@ static char *qmp_send_prepare(libxl__gc *gc, libxl__qmp_handler *qmp,
     yajl_gen_integer(hand, ++qmp->last_id_used);
     if (args) {
         libxl__yajl_gen_asciiz(hand, "arguments");
-        libxl_key_value_list_gen_json(hand, args);
+        libxl__json_object_to_yajl_gen(gc, hand, args);
     }
     yajl_gen_map_close(hand);
 
@@ -560,7 +560,7 @@ out:
 }
 
 static int qmp_send(libxl__qmp_handler *qmp,
-                    const char *cmd, libxl_key_value_list *args,
+                    const char *cmd, libxl__json_object *args,
                     qmp_callback_t callback, void *opaque,
                     qmp_request_context *context)
 {
@@ -588,7 +588,7 @@ out:
 }
 
 static int qmp_synchronous_send(libxl__qmp_handler *qmp, const char *cmd,
-                                libxl_key_value_list *args,
+                                libxl__json_object *args,
                                 qmp_callback_t callback, void *opaque,
                                 int ask_timeout)
 {
@@ -623,7 +623,6 @@ static void qmp_free_handler(libxl__qmp_handler *qmp)
     free(qmp);
 }
 
-#if 0
 /*
  * QMP Parameters Helpers
  * Those functions does not use the gc, because of the internal usage of
@@ -661,6 +660,7 @@ static void qmp_parameters_add_string(libxl__gc *gc,
     qmp_parameters_common_add(gc, param, name, obj);
 }
 
+#if 0
 static void qmp_parameters_add_bool(libxl__gc *gc,
                                     libxl__json_object **param,
                                     const char *name, bool b)
@@ -670,11 +670,11 @@ static void qmp_parameters_add_bool(libxl__gc *gc,
     obj = libxl__json_object_alloc(NOGC, JSON_TRUE);
     qmp_parameters_common_add(gc, param, name, obj);
 }
+#endif
 
 #define QMP_PARAMETERS_SPRINTF(gc, args, name, format, ...) \
     qmp_parameters_add_string(gc, args, name, \
                               libxl__sprintf(gc, format, __VA_ARGS__))
-#endif
 
 /*
  * API
@@ -802,8 +802,7 @@ out:
 int libxl__qmp_pci_add(libxl__gc *gc, int domid, libxl_device_pci *pcidev)
 {
     libxl__qmp_handler *qmp = NULL;
-    flexarray_t *parameters = NULL;
-    libxl_key_value_list args = NULL;
+    libxl__json_object *args = NULL;
     char *hostaddr = NULL;
     int rc = 0;
 
@@ -816,31 +815,23 @@ int libxl__qmp_pci_add(libxl__gc *gc, int domid, libxl_device_pci *pcidev)
     if (!hostaddr)
         return -1;
 
-    parameters = flexarray_make(6, 1);
-    flexarray_append_pair(parameters, "driver", "xen-pci-passthrough");
-    flexarray_append_pair(parameters, "id",
-                          libxl__sprintf(gc, PCI_PT_QDEV_ID,
-                                         pcidev->bus, pcidev->dev,
-                                         pcidev->func));
-    flexarray_append_pair(parameters, "hostaddr", hostaddr);
+    qmp_parameters_add_string(gc, &args, "driver", "xen-pci-passthrough");
+    QMP_PARAMETERS_SPRINTF(gc, &args, "id", PCI_PT_QDEV_ID,
+                           pcidev->bus, pcidev->dev, pcidev->func);
+    qmp_parameters_add_string(gc, &args, "hostaddr", hostaddr);
     if (pcidev->vdevfn) {
-        flexarray_append_pair(parameters, "addr",
-                              libxl__sprintf(gc, "%x.%x",
-                                             PCI_SLOT(pcidev->vdevfn),
-                                             PCI_FUNC(pcidev->vdevfn)));
+        QMP_PARAMETERS_SPRINTF(gc, &args, "addr", "%x.%x",
+                               PCI_SLOT(pcidev->vdevfn), PCI_FUNC(pcidev->vdevfn));
     }
-    args = libxl__xs_kvs_of_flexarray(gc, parameters, parameters->count);
-    if (!args)
-        return -1;
 
-    rc = qmp_synchronous_send(qmp, "device_add", &args,
+    rc = qmp_synchronous_send(qmp, "device_add", args,
                               NULL, NULL, qmp->timeout);
     if (rc == 0) {
         rc = qmp_synchronous_send(qmp, "query-pci", NULL,
                                   pci_add_callback, pcidev, qmp->timeout);
     }
 
-    flexarray_free(parameters);
+    libxl__json_object_free(gc, args);
     libxl__qmp_close(qmp);
     return rc;
 }
@@ -848,24 +839,19 @@ int libxl__qmp_pci_add(libxl__gc *gc, int domid, libxl_device_pci *pcidev)
 static int qmp_device_del(libxl__gc *gc, int domid, char *id)
 {
     libxl__qmp_handler *qmp = NULL;
-    flexarray_t *parameters = NULL;
-    libxl_key_value_list args = NULL;
+    libxl__json_object *args = NULL;
     int rc = 0;
 
     qmp = libxl__qmp_initialize(gc, domid);
     if (!qmp)
         return ERROR_FAIL;
 
-    parameters = flexarray_make(2, 1);
-    flexarray_append_pair(parameters, "id", id);
-    args = libxl__xs_kvs_of_flexarray(gc, parameters, parameters->count);
-    if (!args)
-        return ERROR_NOMEM;
+    qmp_parameters_add_string(gc, &args, "id", id);
 
-    rc = qmp_synchronous_send(qmp, "device_del", &args,
+    rc = qmp_synchronous_send(qmp, "device_del", args,
                               NULL, NULL, qmp->timeout);
+    libxl__json_object_free(gc, args);
 
-    flexarray_free(parameters);
     libxl__qmp_close(qmp);
     return rc;
 }
@@ -883,56 +869,38 @@ int libxl__qmp_pci_del(libxl__gc *gc, int domid, libxl_device_pci *pcidev)
 int libxl__qmp_save(libxl__gc *gc, int domid, const char *filename)
 {
     libxl__qmp_handler *qmp = NULL;
-    flexarray_t *parameters = NULL;
-    libxl_key_value_list args = NULL;
+    libxl__json_object *args = NULL;
     int rc = 0;
 
     qmp = libxl__qmp_initialize(gc, domid);
     if (!qmp)
         return ERROR_FAIL;
 
-    parameters = flexarray_make(2, 1);
-    if (!parameters) {
-        rc = ERROR_NOMEM;
-        goto out;
-    }
-    flexarray_append_pair(parameters, "filename", (char *)filename);
-    args = libxl__xs_kvs_of_flexarray(gc, parameters, parameters->count);
-    if (!args) {
-        rc = ERROR_NOMEM;
-        goto out2;
-    }
+    qmp_parameters_add_string(gc, &args, "filename", (char *)filename);
 
-    rc = qmp_synchronous_send(qmp, "xen-save-devices-state", &args,
+    rc = qmp_synchronous_send(qmp, "xen-save-devices-state", args,
                               NULL, NULL, qmp->timeout);
+    libxl__json_object_free(gc, args);
 
-out2:
-    flexarray_free(parameters);
-out:
-    libxl__qmp_close(qmp);
     return rc;
 }
 
 static int qmp_change(libxl__gc *gc, libxl__qmp_handler *qmp,
                       char *device, char *target, char *arg)
 {
-    flexarray_t *parameters = NULL;
-    libxl_key_value_list args = NULL;
+    libxl__json_object *args = NULL;
     int rc = 0;
 
-    parameters = flexarray_make(6, 1);
-    flexarray_append_pair(parameters, "device", device);
-    flexarray_append_pair(parameters, "target", target);
-    if (arg)
-        flexarray_append_pair(parameters, "arg", arg);
-    args = libxl__xs_kvs_of_flexarray(gc, parameters, parameters->count);
-    if (!args)
-        return ERROR_NOMEM;
+    qmp_parameters_add_string(gc, &args, "device", device);
+    qmp_parameters_add_string(gc, &args, "target", target);
+    if (arg) {
+        qmp_parameters_add_string(gc, &args, "arg", arg);
+    }
 
-    rc = qmp_synchronous_send(qmp, "change", &args,
+    rc = qmp_synchronous_send(qmp, "change", args,
                               NULL, NULL, qmp->timeout);
+    libxl__json_object_free(gc, args);
 
-    flexarray_free(parameters);
     return rc;
 }
 
-- 
Anthony PERARD


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 17 18:22:07 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 18:22: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 1TDfxF-0004rm-Gb; Mon, 17 Sep 2012 18:21:57 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony.perard@citrix.com>) id 1TDfxC-0004qI-OR
	for xen-devel@lists.xen.org; Mon, 17 Sep 2012 18:21:55 +0000
Received: from [85.158.137.99:35509] by server-6.bemta-3.messagelabs.com id
	A1/A2-29694-14A67505; Mon, 17 Sep 2012 18:21:53 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-3.tower-217.messagelabs.com!1347906111!12971293!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzAyMzE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31183 invoked from network); 17 Sep 2012 18:21:52 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-3.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Sep 2012 18:21:52 -0000
X-IronPort-AV: E=Sophos;i="4.80,437,1344211200"; d="scan'208";a="38109666"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Sep 2012 18:21:48 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Mon, 17 Sep 2012 14:21: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 1TDfx5-0000OF-Cc;
	Mon, 17 Sep 2012 19:21:47 +0100
From: Anthony PERARD <anthony.perard@citrix.com>
To: Xen Devel <xen-devel@lists.xen.org>
Date: Mon, 17 Sep 2012 19:22:24 +0100
Message-ID: <1347906148-9606-6-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.12
In-Reply-To: <1347906148-9606-1-git-send-email-anthony.perard@citrix.com>
References: <1347906148-9606-1-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Cc: Anthony PERARD <anthony.perard@citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH V2 5/9] libxl_qmp: Use qmp_parameters_*
	functions for param list of a QMP command.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
 tools/libxl/libxl_qmp.c | 96 +++++++++++++++++--------------------------------
 1 file changed, 32 insertions(+), 64 deletions(-)

diff --git a/tools/libxl/libxl_qmp.c b/tools/libxl/libxl_qmp.c
index 1dd5c6c..ed67431 100644
--- a/tools/libxl/libxl_qmp.c
+++ b/tools/libxl/libxl_qmp.c
@@ -78,7 +78,7 @@ struct libxl__qmp_handler {
 };
 
 static int qmp_send(libxl__qmp_handler *qmp,
-                    const char *cmd, libxl_key_value_list *args,
+                    const char *cmd, libxl__json_object *args,
                     qmp_callback_t callback, void *opaque,
                     qmp_request_context *context);
 
@@ -502,7 +502,7 @@ static int qmp_next(libxl__gc *gc, libxl__qmp_handler *qmp)
 }
 
 static char *qmp_send_prepare(libxl__gc *gc, libxl__qmp_handler *qmp,
-                              const char *cmd, libxl_key_value_list *args,
+                              const char *cmd, libxl__json_object *args,
                               qmp_callback_t callback, void *opaque,
                               qmp_request_context *context)
 {
@@ -526,7 +526,7 @@ static char *qmp_send_prepare(libxl__gc *gc, libxl__qmp_handler *qmp,
     yajl_gen_integer(hand, ++qmp->last_id_used);
     if (args) {
         libxl__yajl_gen_asciiz(hand, "arguments");
-        libxl_key_value_list_gen_json(hand, args);
+        libxl__json_object_to_yajl_gen(gc, hand, args);
     }
     yajl_gen_map_close(hand);
 
@@ -560,7 +560,7 @@ out:
 }
 
 static int qmp_send(libxl__qmp_handler *qmp,
-                    const char *cmd, libxl_key_value_list *args,
+                    const char *cmd, libxl__json_object *args,
                     qmp_callback_t callback, void *opaque,
                     qmp_request_context *context)
 {
@@ -588,7 +588,7 @@ out:
 }
 
 static int qmp_synchronous_send(libxl__qmp_handler *qmp, const char *cmd,
-                                libxl_key_value_list *args,
+                                libxl__json_object *args,
                                 qmp_callback_t callback, void *opaque,
                                 int ask_timeout)
 {
@@ -623,7 +623,6 @@ static void qmp_free_handler(libxl__qmp_handler *qmp)
     free(qmp);
 }
 
-#if 0
 /*
  * QMP Parameters Helpers
  * Those functions does not use the gc, because of the internal usage of
@@ -661,6 +660,7 @@ static void qmp_parameters_add_string(libxl__gc *gc,
     qmp_parameters_common_add(gc, param, name, obj);
 }
 
+#if 0
 static void qmp_parameters_add_bool(libxl__gc *gc,
                                     libxl__json_object **param,
                                     const char *name, bool b)
@@ -670,11 +670,11 @@ static void qmp_parameters_add_bool(libxl__gc *gc,
     obj = libxl__json_object_alloc(NOGC, JSON_TRUE);
     qmp_parameters_common_add(gc, param, name, obj);
 }
+#endif
 
 #define QMP_PARAMETERS_SPRINTF(gc, args, name, format, ...) \
     qmp_parameters_add_string(gc, args, name, \
                               libxl__sprintf(gc, format, __VA_ARGS__))
-#endif
 
 /*
  * API
@@ -802,8 +802,7 @@ out:
 int libxl__qmp_pci_add(libxl__gc *gc, int domid, libxl_device_pci *pcidev)
 {
     libxl__qmp_handler *qmp = NULL;
-    flexarray_t *parameters = NULL;
-    libxl_key_value_list args = NULL;
+    libxl__json_object *args = NULL;
     char *hostaddr = NULL;
     int rc = 0;
 
@@ -816,31 +815,23 @@ int libxl__qmp_pci_add(libxl__gc *gc, int domid, libxl_device_pci *pcidev)
     if (!hostaddr)
         return -1;
 
-    parameters = flexarray_make(6, 1);
-    flexarray_append_pair(parameters, "driver", "xen-pci-passthrough");
-    flexarray_append_pair(parameters, "id",
-                          libxl__sprintf(gc, PCI_PT_QDEV_ID,
-                                         pcidev->bus, pcidev->dev,
-                                         pcidev->func));
-    flexarray_append_pair(parameters, "hostaddr", hostaddr);
+    qmp_parameters_add_string(gc, &args, "driver", "xen-pci-passthrough");
+    QMP_PARAMETERS_SPRINTF(gc, &args, "id", PCI_PT_QDEV_ID,
+                           pcidev->bus, pcidev->dev, pcidev->func);
+    qmp_parameters_add_string(gc, &args, "hostaddr", hostaddr);
     if (pcidev->vdevfn) {
-        flexarray_append_pair(parameters, "addr",
-                              libxl__sprintf(gc, "%x.%x",
-                                             PCI_SLOT(pcidev->vdevfn),
-                                             PCI_FUNC(pcidev->vdevfn)));
+        QMP_PARAMETERS_SPRINTF(gc, &args, "addr", "%x.%x",
+                               PCI_SLOT(pcidev->vdevfn), PCI_FUNC(pcidev->vdevfn));
     }
-    args = libxl__xs_kvs_of_flexarray(gc, parameters, parameters->count);
-    if (!args)
-        return -1;
 
-    rc = qmp_synchronous_send(qmp, "device_add", &args,
+    rc = qmp_synchronous_send(qmp, "device_add", args,
                               NULL, NULL, qmp->timeout);
     if (rc == 0) {
         rc = qmp_synchronous_send(qmp, "query-pci", NULL,
                                   pci_add_callback, pcidev, qmp->timeout);
     }
 
-    flexarray_free(parameters);
+    libxl__json_object_free(gc, args);
     libxl__qmp_close(qmp);
     return rc;
 }
@@ -848,24 +839,19 @@ int libxl__qmp_pci_add(libxl__gc *gc, int domid, libxl_device_pci *pcidev)
 static int qmp_device_del(libxl__gc *gc, int domid, char *id)
 {
     libxl__qmp_handler *qmp = NULL;
-    flexarray_t *parameters = NULL;
-    libxl_key_value_list args = NULL;
+    libxl__json_object *args = NULL;
     int rc = 0;
 
     qmp = libxl__qmp_initialize(gc, domid);
     if (!qmp)
         return ERROR_FAIL;
 
-    parameters = flexarray_make(2, 1);
-    flexarray_append_pair(parameters, "id", id);
-    args = libxl__xs_kvs_of_flexarray(gc, parameters, parameters->count);
-    if (!args)
-        return ERROR_NOMEM;
+    qmp_parameters_add_string(gc, &args, "id", id);
 
-    rc = qmp_synchronous_send(qmp, "device_del", &args,
+    rc = qmp_synchronous_send(qmp, "device_del", args,
                               NULL, NULL, qmp->timeout);
+    libxl__json_object_free(gc, args);
 
-    flexarray_free(parameters);
     libxl__qmp_close(qmp);
     return rc;
 }
@@ -883,56 +869,38 @@ int libxl__qmp_pci_del(libxl__gc *gc, int domid, libxl_device_pci *pcidev)
 int libxl__qmp_save(libxl__gc *gc, int domid, const char *filename)
 {
     libxl__qmp_handler *qmp = NULL;
-    flexarray_t *parameters = NULL;
-    libxl_key_value_list args = NULL;
+    libxl__json_object *args = NULL;
     int rc = 0;
 
     qmp = libxl__qmp_initialize(gc, domid);
     if (!qmp)
         return ERROR_FAIL;
 
-    parameters = flexarray_make(2, 1);
-    if (!parameters) {
-        rc = ERROR_NOMEM;
-        goto out;
-    }
-    flexarray_append_pair(parameters, "filename", (char *)filename);
-    args = libxl__xs_kvs_of_flexarray(gc, parameters, parameters->count);
-    if (!args) {
-        rc = ERROR_NOMEM;
-        goto out2;
-    }
+    qmp_parameters_add_string(gc, &args, "filename", (char *)filename);
 
-    rc = qmp_synchronous_send(qmp, "xen-save-devices-state", &args,
+    rc = qmp_synchronous_send(qmp, "xen-save-devices-state", args,
                               NULL, NULL, qmp->timeout);
+    libxl__json_object_free(gc, args);
 
-out2:
-    flexarray_free(parameters);
-out:
-    libxl__qmp_close(qmp);
     return rc;
 }
 
 static int qmp_change(libxl__gc *gc, libxl__qmp_handler *qmp,
                       char *device, char *target, char *arg)
 {
-    flexarray_t *parameters = NULL;
-    libxl_key_value_list args = NULL;
+    libxl__json_object *args = NULL;
     int rc = 0;
 
-    parameters = flexarray_make(6, 1);
-    flexarray_append_pair(parameters, "device", device);
-    flexarray_append_pair(parameters, "target", target);
-    if (arg)
-        flexarray_append_pair(parameters, "arg", arg);
-    args = libxl__xs_kvs_of_flexarray(gc, parameters, parameters->count);
-    if (!args)
-        return ERROR_NOMEM;
+    qmp_parameters_add_string(gc, &args, "device", device);
+    qmp_parameters_add_string(gc, &args, "target", target);
+    if (arg) {
+        qmp_parameters_add_string(gc, &args, "arg", arg);
+    }
 
-    rc = qmp_synchronous_send(qmp, "change", &args,
+    rc = qmp_synchronous_send(qmp, "change", args,
                               NULL, NULL, qmp->timeout);
+    libxl__json_object_free(gc, args);
 
-    flexarray_free(parameters);
     return rc;
 }
 
-- 
Anthony PERARD


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 17 18:22:07 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 18:22: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 1TDfxC-0004qT-ST; Mon, 17 Sep 2012 18:21:54 +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 1TDfxA-0004pV-Q2
	for xen-devel@lists.xen.org; Mon, 17 Sep 2012 18:21:53 +0000
Received: from [85.158.139.211:35729] by server-1.bemta-5.messagelabs.com id
	19/64-32692-04A67505; Mon, 17 Sep 2012 18:21:52 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-3.tower-206.messagelabs.com!1347906110!18903640!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzAyMzE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22626 invoked from network); 17 Sep 2012 18:21:51 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-3.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Sep 2012 18:21:51 -0000
X-IronPort-AV: E=Sophos;i="4.80,437,1344211200"; d="scan'208";a="38109661"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Sep 2012 18:21:48 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Mon, 17 Sep 2012 14:21: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 1TDfx5-0000OF-Ap;
	Mon, 17 Sep 2012 19:21:47 +0100
From: Anthony PERARD <anthony.perard@citrix.com>
To: Xen Devel <xen-devel@lists.xen.org>
Date: Mon, 17 Sep 2012 19:22:22 +0100
Message-ID: <1347906148-9606-4-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.12
In-Reply-To: <1347906148-9606-1-git-send-email-anthony.perard@citrix.com>
References: <1347906148-9606-1-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Cc: Anthony PERARD <anthony.perard@citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH V2 3/9] libxl_json: Introduce
	libxl__json_object_to_yajl_gen.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This function converts a libxl__json_object to yajl by calling every yajl_gen_*
function on a preallocated yajl_gen hand.

This helps to integrate a json_object into an already existing yajl_gen tree.

This function is used in a later patch.

Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
 tools/libxl/libxl_internal.h |  3 +++
 tools/libxl/libxl_json.c     | 63 ++++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 66 insertions(+)

diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 3c2dcaa..9c1482d 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -1527,6 +1527,9 @@ libxl__json_map_node *libxl__json_map_node_get(const libxl__json_object *o,
 _hidden const libxl__json_object *libxl__json_map_get(const char *key,
                                           const libxl__json_object *o,
                                           libxl__json_node_type expected_type);
+_hidden yajl_status libxl__json_object_to_yajl_gen(libxl__gc *gc,
+                                                   yajl_gen hand,
+                                                   libxl__json_object *param);
 _hidden void libxl__json_object_free(libxl__gc *gc, libxl__json_object *obj);
 
 _hidden libxl__json_object *libxl__json_parse(libxl__gc *gc, const char *s);
diff --git a/tools/libxl/libxl_json.c b/tools/libxl/libxl_json.c
index 0539865..40818f2 100644
--- a/tools/libxl/libxl_json.c
+++ b/tools/libxl/libxl_json.c
@@ -376,6 +376,69 @@ const libxl__json_object *libxl__json_map_get(const char *key,
     return NULL;
 }
 
+yajl_status libxl__json_object_to_yajl_gen(libxl__gc *gc,
+                                           yajl_gen hand,
+                                           libxl__json_object *obj)
+{
+    int index = 0;
+    yajl_status rc;
+
+    switch (obj->type) {
+    case JSON_NULL:
+        return yajl_gen_null(hand);
+    case JSON_TRUE:
+        return yajl_gen_bool(hand, true);
+    case JSON_FALSE:
+        return yajl_gen_bool(hand, false);
+    case JSON_INTEGER:
+        return yajl_gen_integer(hand, obj->u.i);
+    case JSON_DOUBLE:
+        return yajl_gen_double(hand, obj->u.d);
+    case JSON_NUMBER:
+        return yajl_gen_number(hand, obj->u.string, strlen(obj->u.string));
+    case JSON_STRING:
+        return libxl__yajl_gen_asciiz(hand, obj->u.string);
+    case JSON_MAP: {
+        libxl__json_map_node *node = NULL;
+
+        rc = yajl_gen_map_open(hand);
+        if (rc != yajl_status_ok)
+            return rc;
+        for (index = 0; index < obj->u.map->count; index++) {
+            if (flexarray_get(obj->u.map, index, (void**)&node) != 0)
+                break;
+
+            rc = libxl__yajl_gen_asciiz(hand, node->map_key);
+            if (rc != yajl_status_ok)
+                return rc;
+            rc = libxl__json_object_to_yajl_gen(gc, hand, node->obj);
+            if (rc != yajl_status_ok)
+                return rc;
+        }
+        return yajl_gen_map_close(hand);
+    }
+    case JSON_ARRAY: {
+        libxl__json_object *node = NULL;
+
+        rc = yajl_gen_array_open(hand);
+        if (rc != yajl_status_ok)
+            return rc;
+        for (index = 0; index < obj->u.array->count; index++) {
+            if (flexarray_get(obj->u.array, index, (void**)&node) != 0)
+                break;
+            rc = libxl__json_object_to_yajl_gen(gc, hand, node);
+            if (rc != yajl_status_ok)
+                return rc;
+        }
+        return yajl_gen_array_close(hand);
+    }
+    case JSON_ERROR:
+    case JSON_ANY:
+    default:
+        return -1;
+    }
+}
+
 
 /*
  * JSON callbacks
-- 
Anthony PERARD


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 17 18:22:07 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 18:22: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 1TDfxC-0004qT-ST; Mon, 17 Sep 2012 18:21:54 +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 1TDfxA-0004pV-Q2
	for xen-devel@lists.xen.org; Mon, 17 Sep 2012 18:21:53 +0000
Received: from [85.158.139.211:35729] by server-1.bemta-5.messagelabs.com id
	19/64-32692-04A67505; Mon, 17 Sep 2012 18:21:52 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-3.tower-206.messagelabs.com!1347906110!18903640!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzAyMzE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22626 invoked from network); 17 Sep 2012 18:21:51 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-3.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Sep 2012 18:21:51 -0000
X-IronPort-AV: E=Sophos;i="4.80,437,1344211200"; d="scan'208";a="38109661"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Sep 2012 18:21:48 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Mon, 17 Sep 2012 14:21: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 1TDfx5-0000OF-Ap;
	Mon, 17 Sep 2012 19:21:47 +0100
From: Anthony PERARD <anthony.perard@citrix.com>
To: Xen Devel <xen-devel@lists.xen.org>
Date: Mon, 17 Sep 2012 19:22:22 +0100
Message-ID: <1347906148-9606-4-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.12
In-Reply-To: <1347906148-9606-1-git-send-email-anthony.perard@citrix.com>
References: <1347906148-9606-1-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Cc: Anthony PERARD <anthony.perard@citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH V2 3/9] libxl_json: Introduce
	libxl__json_object_to_yajl_gen.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This function converts a libxl__json_object to yajl by calling every yajl_gen_*
function on a preallocated yajl_gen hand.

This helps to integrate a json_object into an already existing yajl_gen tree.

This function is used in a later patch.

Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
 tools/libxl/libxl_internal.h |  3 +++
 tools/libxl/libxl_json.c     | 63 ++++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 66 insertions(+)

diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 3c2dcaa..9c1482d 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -1527,6 +1527,9 @@ libxl__json_map_node *libxl__json_map_node_get(const libxl__json_object *o,
 _hidden const libxl__json_object *libxl__json_map_get(const char *key,
                                           const libxl__json_object *o,
                                           libxl__json_node_type expected_type);
+_hidden yajl_status libxl__json_object_to_yajl_gen(libxl__gc *gc,
+                                                   yajl_gen hand,
+                                                   libxl__json_object *param);
 _hidden void libxl__json_object_free(libxl__gc *gc, libxl__json_object *obj);
 
 _hidden libxl__json_object *libxl__json_parse(libxl__gc *gc, const char *s);
diff --git a/tools/libxl/libxl_json.c b/tools/libxl/libxl_json.c
index 0539865..40818f2 100644
--- a/tools/libxl/libxl_json.c
+++ b/tools/libxl/libxl_json.c
@@ -376,6 +376,69 @@ const libxl__json_object *libxl__json_map_get(const char *key,
     return NULL;
 }
 
+yajl_status libxl__json_object_to_yajl_gen(libxl__gc *gc,
+                                           yajl_gen hand,
+                                           libxl__json_object *obj)
+{
+    int index = 0;
+    yajl_status rc;
+
+    switch (obj->type) {
+    case JSON_NULL:
+        return yajl_gen_null(hand);
+    case JSON_TRUE:
+        return yajl_gen_bool(hand, true);
+    case JSON_FALSE:
+        return yajl_gen_bool(hand, false);
+    case JSON_INTEGER:
+        return yajl_gen_integer(hand, obj->u.i);
+    case JSON_DOUBLE:
+        return yajl_gen_double(hand, obj->u.d);
+    case JSON_NUMBER:
+        return yajl_gen_number(hand, obj->u.string, strlen(obj->u.string));
+    case JSON_STRING:
+        return libxl__yajl_gen_asciiz(hand, obj->u.string);
+    case JSON_MAP: {
+        libxl__json_map_node *node = NULL;
+
+        rc = yajl_gen_map_open(hand);
+        if (rc != yajl_status_ok)
+            return rc;
+        for (index = 0; index < obj->u.map->count; index++) {
+            if (flexarray_get(obj->u.map, index, (void**)&node) != 0)
+                break;
+
+            rc = libxl__yajl_gen_asciiz(hand, node->map_key);
+            if (rc != yajl_status_ok)
+                return rc;
+            rc = libxl__json_object_to_yajl_gen(gc, hand, node->obj);
+            if (rc != yajl_status_ok)
+                return rc;
+        }
+        return yajl_gen_map_close(hand);
+    }
+    case JSON_ARRAY: {
+        libxl__json_object *node = NULL;
+
+        rc = yajl_gen_array_open(hand);
+        if (rc != yajl_status_ok)
+            return rc;
+        for (index = 0; index < obj->u.array->count; index++) {
+            if (flexarray_get(obj->u.array, index, (void**)&node) != 0)
+                break;
+            rc = libxl__json_object_to_yajl_gen(gc, hand, node);
+            if (rc != yajl_status_ok)
+                return rc;
+        }
+        return yajl_gen_array_close(hand);
+    }
+    case JSON_ERROR:
+    case JSON_ANY:
+    default:
+        return -1;
+    }
+}
+
 
 /*
  * JSON callbacks
-- 
Anthony PERARD


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 17 18:22:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 18: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 1TDfxD-0004qe-A5; Mon, 17 Sep 2012 18:21:55 +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 1TDfxB-0004pW-4x
	for xen-devel@lists.xen.org; Mon, 17 Sep 2012 18:21:53 +0000
Received: from [85.158.139.211:54686] by server-3.bemta-5.messagelabs.com id
	5D/E4-21836-04A67505; Mon, 17 Sep 2012 18:21:52 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-5.tower-206.messagelabs.com!1347906108!18863259!4
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzAyMzE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4246 invoked from network); 17 Sep 2012 18:21:51 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-5.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Sep 2012 18:21:51 -0000
X-IronPort-AV: E=Sophos;i="4.80,437,1344211200"; d="scan'208";a="38109662"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Sep 2012 18:21:48 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Mon, 17 Sep 2012 14:21: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 1TDfx5-0000OF-8y;
	Mon, 17 Sep 2012 19:21:47 +0100
From: Anthony PERARD <anthony.perard@citrix.com>
To: Xen Devel <xen-devel@lists.xen.org>
Date: Mon, 17 Sep 2012 19:22:20 +0100
Message-ID: <1347906148-9606-2-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.12
In-Reply-To: <1347906148-9606-1-git-send-email-anthony.perard@citrix.com>
References: <1347906148-9606-1-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Cc: Anthony PERARD <anthony.perard@citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH V2 1/9] libxl_json: Use libxl alloc function
	with 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

This patch makes use of the libxl allocation API and removes the check for
allocation failure.

Also we don't use GC with a json_object because this structure use flexarray
and the latter does not use the gc.

Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
 tools/libxl/libxl_json.c | 37 +++++++++++--------------------------
 1 file changed, 11 insertions(+), 26 deletions(-)

diff --git a/tools/libxl/libxl_json.c b/tools/libxl/libxl_json.c
index caa8312..9c3dca2 100644
--- a/tools/libxl/libxl_json.c
+++ b/tools/libxl/libxl_json.c
@@ -210,12 +210,7 @@ static libxl__json_object *json_object_alloc(libxl__gc *gc,
 {
     libxl__json_object *obj;
 
-    obj = calloc(1, sizeof (libxl__json_object));
-    if (obj == NULL) {
-        LIBXL__LOG_ERRNO(libxl__gc_owner(gc), LIBXL__LOG_ERROR,
-                         "Failed to allocate a libxl__json_object");
-        return NULL;
-    }
+    obj = libxl__zalloc(NOGC, sizeof(*obj));
 
     obj->type = type;
 
@@ -393,8 +388,7 @@ static int json_callback_null(void *opaque)
 
     DEBUG_GEN(ctx, null);
 
-    if ((obj = json_object_alloc(ctx->gc, JSON_NULL)) == NULL)
-        return 0;
+    obj = json_object_alloc(ctx->gc, JSON_NULL);
 
     if (json_object_append_to(ctx->gc, obj, ctx->current) == -1) {
         libxl__json_object_free(ctx->gc, obj);
@@ -411,9 +405,8 @@ static int json_callback_boolean(void *opaque, int boolean)
 
     DEBUG_GEN_VALUE(ctx, bool, boolean);
 
-    if ((obj = json_object_alloc(ctx->gc,
-                                 boolean ? JSON_TRUE : JSON_FALSE)) == NULL)
-        return 0;
+    obj = json_object_alloc(ctx->gc,
+                            boolean ? JSON_TRUE : JSON_FALSE);
 
     if (json_object_append_to(ctx->gc, obj, ctx->current) == -1) {
         libxl__json_object_free(ctx->gc, obj);
@@ -448,8 +441,7 @@ static int json_callback_number(void *opaque, const char *s, libxl_yajl_length l
             goto error;
         }
 
-        if ((obj = json_object_alloc(ctx->gc, JSON_DOUBLE)) == NULL)
-            return 0;
+        obj = json_object_alloc(ctx->gc, JSON_DOUBLE);
         obj->u.d = d;
     } else {
         long long i = strtoll(s, NULL, 10);
@@ -458,16 +450,14 @@ static int json_callback_number(void *opaque, const char *s, libxl_yajl_length l
             goto error;
         }
 
-        if ((obj = json_object_alloc(ctx->gc, JSON_INTEGER)) == NULL)
-            return 0;
+        obj = json_object_alloc(ctx->gc, JSON_INTEGER);
         obj->u.i = i;
     }
     goto out;
 
 error:
     /* If the conversion fail, we just store the original string. */
-    if ((obj = json_object_alloc(ctx->gc, JSON_NUMBER)) == NULL)
-        return 0;
+    obj = json_object_alloc(ctx->gc, JSON_NUMBER);
 
     t = malloc(len + 1);
     if (t == NULL) {
@@ -508,10 +498,7 @@ static int json_callback_string(void *opaque, const unsigned char *str,
     strncpy(t, (const char *) str, len);
     t[len] = 0;
 
-    if ((obj = json_object_alloc(ctx->gc, JSON_STRING)) == NULL) {
-        free(t);
-        return 0;
-    }
+    obj = json_object_alloc(ctx->gc, JSON_STRING);
     obj->u.string = t;
 
     if (json_object_append_to(ctx->gc, obj, ctx->current) == -1) {
@@ -573,8 +560,7 @@ static int json_callback_start_map(void *opaque)
 
     DEBUG_GEN(ctx, map_open);
 
-    if ((obj = json_object_alloc(ctx->gc, JSON_MAP)) == NULL)
-        return 0;
+    obj = json_object_alloc(ctx->gc, JSON_MAP);
 
     if (ctx->current) {
         if (json_object_append_to(ctx->gc, obj, ctx->current) == -1) {
@@ -615,8 +601,7 @@ static int json_callback_start_array(void *opaque)
 
     DEBUG_GEN(ctx, array_open);
 
-    if ((obj = json_object_alloc(ctx->gc, JSON_ARRAY)) == NULL)
-        return 0;
+    obj = json_object_alloc(ctx->gc, JSON_ARRAY);
 
     if (ctx->current) {
         if (json_object_append_to(ctx->gc, obj, ctx->current) == -1) {
@@ -681,7 +666,7 @@ libxl__json_object *libxl__json_parse(libxl__gc *gc, const char *s)
     unsigned char *str = NULL;
 
     memset(&yajl_ctx, 0, sizeof (yajl_ctx));
-    yajl_ctx.gc = gc;
+    yajl_ctx.gc = NOGC;
 
     DEBUG_GEN_ALLOC(&yajl_ctx);
 
-- 
Anthony PERARD


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 17 18:22:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 18: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 1TDfxD-0004qe-A5; Mon, 17 Sep 2012 18:21:55 +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 1TDfxB-0004pW-4x
	for xen-devel@lists.xen.org; Mon, 17 Sep 2012 18:21:53 +0000
Received: from [85.158.139.211:54686] by server-3.bemta-5.messagelabs.com id
	5D/E4-21836-04A67505; Mon, 17 Sep 2012 18:21:52 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-5.tower-206.messagelabs.com!1347906108!18863259!4
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzAyMzE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4246 invoked from network); 17 Sep 2012 18:21:51 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-5.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Sep 2012 18:21:51 -0000
X-IronPort-AV: E=Sophos;i="4.80,437,1344211200"; d="scan'208";a="38109662"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Sep 2012 18:21:48 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Mon, 17 Sep 2012 14:21: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 1TDfx5-0000OF-8y;
	Mon, 17 Sep 2012 19:21:47 +0100
From: Anthony PERARD <anthony.perard@citrix.com>
To: Xen Devel <xen-devel@lists.xen.org>
Date: Mon, 17 Sep 2012 19:22:20 +0100
Message-ID: <1347906148-9606-2-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.12
In-Reply-To: <1347906148-9606-1-git-send-email-anthony.perard@citrix.com>
References: <1347906148-9606-1-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Cc: Anthony PERARD <anthony.perard@citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH V2 1/9] libxl_json: Use libxl alloc function
	with 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

This patch makes use of the libxl allocation API and removes the check for
allocation failure.

Also we don't use GC with a json_object because this structure use flexarray
and the latter does not use the gc.

Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
 tools/libxl/libxl_json.c | 37 +++++++++++--------------------------
 1 file changed, 11 insertions(+), 26 deletions(-)

diff --git a/tools/libxl/libxl_json.c b/tools/libxl/libxl_json.c
index caa8312..9c3dca2 100644
--- a/tools/libxl/libxl_json.c
+++ b/tools/libxl/libxl_json.c
@@ -210,12 +210,7 @@ static libxl__json_object *json_object_alloc(libxl__gc *gc,
 {
     libxl__json_object *obj;
 
-    obj = calloc(1, sizeof (libxl__json_object));
-    if (obj == NULL) {
-        LIBXL__LOG_ERRNO(libxl__gc_owner(gc), LIBXL__LOG_ERROR,
-                         "Failed to allocate a libxl__json_object");
-        return NULL;
-    }
+    obj = libxl__zalloc(NOGC, sizeof(*obj));
 
     obj->type = type;
 
@@ -393,8 +388,7 @@ static int json_callback_null(void *opaque)
 
     DEBUG_GEN(ctx, null);
 
-    if ((obj = json_object_alloc(ctx->gc, JSON_NULL)) == NULL)
-        return 0;
+    obj = json_object_alloc(ctx->gc, JSON_NULL);
 
     if (json_object_append_to(ctx->gc, obj, ctx->current) == -1) {
         libxl__json_object_free(ctx->gc, obj);
@@ -411,9 +405,8 @@ static int json_callback_boolean(void *opaque, int boolean)
 
     DEBUG_GEN_VALUE(ctx, bool, boolean);
 
-    if ((obj = json_object_alloc(ctx->gc,
-                                 boolean ? JSON_TRUE : JSON_FALSE)) == NULL)
-        return 0;
+    obj = json_object_alloc(ctx->gc,
+                            boolean ? JSON_TRUE : JSON_FALSE);
 
     if (json_object_append_to(ctx->gc, obj, ctx->current) == -1) {
         libxl__json_object_free(ctx->gc, obj);
@@ -448,8 +441,7 @@ static int json_callback_number(void *opaque, const char *s, libxl_yajl_length l
             goto error;
         }
 
-        if ((obj = json_object_alloc(ctx->gc, JSON_DOUBLE)) == NULL)
-            return 0;
+        obj = json_object_alloc(ctx->gc, JSON_DOUBLE);
         obj->u.d = d;
     } else {
         long long i = strtoll(s, NULL, 10);
@@ -458,16 +450,14 @@ static int json_callback_number(void *opaque, const char *s, libxl_yajl_length l
             goto error;
         }
 
-        if ((obj = json_object_alloc(ctx->gc, JSON_INTEGER)) == NULL)
-            return 0;
+        obj = json_object_alloc(ctx->gc, JSON_INTEGER);
         obj->u.i = i;
     }
     goto out;
 
 error:
     /* If the conversion fail, we just store the original string. */
-    if ((obj = json_object_alloc(ctx->gc, JSON_NUMBER)) == NULL)
-        return 0;
+    obj = json_object_alloc(ctx->gc, JSON_NUMBER);
 
     t = malloc(len + 1);
     if (t == NULL) {
@@ -508,10 +498,7 @@ static int json_callback_string(void *opaque, const unsigned char *str,
     strncpy(t, (const char *) str, len);
     t[len] = 0;
 
-    if ((obj = json_object_alloc(ctx->gc, JSON_STRING)) == NULL) {
-        free(t);
-        return 0;
-    }
+    obj = json_object_alloc(ctx->gc, JSON_STRING);
     obj->u.string = t;
 
     if (json_object_append_to(ctx->gc, obj, ctx->current) == -1) {
@@ -573,8 +560,7 @@ static int json_callback_start_map(void *opaque)
 
     DEBUG_GEN(ctx, map_open);
 
-    if ((obj = json_object_alloc(ctx->gc, JSON_MAP)) == NULL)
-        return 0;
+    obj = json_object_alloc(ctx->gc, JSON_MAP);
 
     if (ctx->current) {
         if (json_object_append_to(ctx->gc, obj, ctx->current) == -1) {
@@ -615,8 +601,7 @@ static int json_callback_start_array(void *opaque)
 
     DEBUG_GEN(ctx, array_open);
 
-    if ((obj = json_object_alloc(ctx->gc, JSON_ARRAY)) == NULL)
-        return 0;
+    obj = json_object_alloc(ctx->gc, JSON_ARRAY);
 
     if (ctx->current) {
         if (json_object_append_to(ctx->gc, obj, ctx->current) == -1) {
@@ -681,7 +666,7 @@ libxl__json_object *libxl__json_parse(libxl__gc *gc, const char *s)
     unsigned char *str = NULL;
 
     memset(&yajl_ctx, 0, sizeof (yajl_ctx));
-    yajl_ctx.gc = gc;
+    yajl_ctx.gc = NOGC;
 
     DEBUG_GEN_ALLOC(&yajl_ctx);
 
-- 
Anthony PERARD


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 17 18:22:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 18: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 1TDfxA-0004pb-OK; Mon, 17 Sep 2012 18:21:52 +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 1TDfx8-0004pK-Te
	for xen-devel@lists.xen.org; Mon, 17 Sep 2012 18:21:51 +0000
Received: from [85.158.139.211:35669] by server-10.bemta-5.messagelabs.com id
	8F/EB-10969-E3A67505; Mon, 17 Sep 2012 18:21:50 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-5.tower-206.messagelabs.com!1347906108!18863259!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzAyMzE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4221 invoked from network); 17 Sep 2012 18:21:49 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-5.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Sep 2012 18:21:49 -0000
X-IronPort-AV: E=Sophos;i="4.80,437,1344211200"; d="scan'208";a="38109658"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Sep 2012 18:21:47 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Mon, 17 Sep 2012 14:21: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 1TDfx5-0000OF-8e;
	Mon, 17 Sep 2012 19:21:47 +0100
From: Anthony PERARD <anthony.perard@citrix.com>
To: Xen Devel <xen-devel@lists.xen.org>
Date: Mon, 17 Sep 2012 19:22:19 +0100
Message-ID: <1347906148-9606-1-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.12
MIME-Version: 1.0
Cc: Anthony PERARD <anthony.perard@citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH V2 0/9] Set dirty log on 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

This patch series enables libxl to set dirty log on QEMU upstream during
migration through a new QMP command.

The success of the call depends on the presence of the specific QMP command
xen-set-global-dirty-log in QEMU. Patches for this command have been sent.

There is several patches that cleanup a bit the libxl_json/qmp codes.

Changes since v1:
  - Use libxl allocation function with NOGC when requiered.
  - No more check of failed allocation.
  - New qmp_run_command function, to factorize the libxl_qmp code.
  - cleanup ...


Anthony PERARD (9):
  libxl_json: Use libxl alloc function with NOGC.
  libxl_json: Export json_object related function.
  libxl_json: Introduce libxl__json_object_to_yajl_gen.
  libxl_qmp: Introduces helpers to create an argument list.
  libxl_qmp: Use qmp_parameters_* functions for param list of a QMP
    command.
  libxl_qmp: Simplify run of single QMP commands.
  libxl_qmp: Introduce libxl__qmp_set_global_dirty_log.
  libxl_dom: Call the right switch logdirty for the right DM.
  libxl: Allow migration with qemu-xen.

 tools/libxl/libxl.c          |   4 -
 tools/libxl/libxl_dom.c      |  45 +++++++++-
 tools/libxl/libxl_internal.h |  13 +++
 tools/libxl/libxl_json.c     | 116 ++++++++++++++++--------
 tools/libxl/libxl_qmp.c      | 204 +++++++++++++++++++++++--------------------
 5 files changed, 247 insertions(+), 135 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 Mon Sep 17 18:22:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 18: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 1TDfxA-0004pb-OK; Mon, 17 Sep 2012 18:21:52 +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 1TDfx8-0004pK-Te
	for xen-devel@lists.xen.org; Mon, 17 Sep 2012 18:21:51 +0000
Received: from [85.158.139.211:35669] by server-10.bemta-5.messagelabs.com id
	8F/EB-10969-E3A67505; Mon, 17 Sep 2012 18:21:50 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-5.tower-206.messagelabs.com!1347906108!18863259!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzAyMzE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4221 invoked from network); 17 Sep 2012 18:21:49 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-5.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Sep 2012 18:21:49 -0000
X-IronPort-AV: E=Sophos;i="4.80,437,1344211200"; d="scan'208";a="38109658"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Sep 2012 18:21:47 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Mon, 17 Sep 2012 14:21: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 1TDfx5-0000OF-8e;
	Mon, 17 Sep 2012 19:21:47 +0100
From: Anthony PERARD <anthony.perard@citrix.com>
To: Xen Devel <xen-devel@lists.xen.org>
Date: Mon, 17 Sep 2012 19:22:19 +0100
Message-ID: <1347906148-9606-1-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.12
MIME-Version: 1.0
Cc: Anthony PERARD <anthony.perard@citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH V2 0/9] Set dirty log on 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

This patch series enables libxl to set dirty log on QEMU upstream during
migration through a new QMP command.

The success of the call depends on the presence of the specific QMP command
xen-set-global-dirty-log in QEMU. Patches for this command have been sent.

There is several patches that cleanup a bit the libxl_json/qmp codes.

Changes since v1:
  - Use libxl allocation function with NOGC when requiered.
  - No more check of failed allocation.
  - New qmp_run_command function, to factorize the libxl_qmp code.
  - cleanup ...


Anthony PERARD (9):
  libxl_json: Use libxl alloc function with NOGC.
  libxl_json: Export json_object related function.
  libxl_json: Introduce libxl__json_object_to_yajl_gen.
  libxl_qmp: Introduces helpers to create an argument list.
  libxl_qmp: Use qmp_parameters_* functions for param list of a QMP
    command.
  libxl_qmp: Simplify run of single QMP commands.
  libxl_qmp: Introduce libxl__qmp_set_global_dirty_log.
  libxl_dom: Call the right switch logdirty for the right DM.
  libxl: Allow migration with qemu-xen.

 tools/libxl/libxl.c          |   4 -
 tools/libxl/libxl_dom.c      |  45 +++++++++-
 tools/libxl/libxl_internal.h |  13 +++
 tools/libxl/libxl_json.c     | 116 ++++++++++++++++--------
 tools/libxl/libxl_qmp.c      | 204 +++++++++++++++++++++++--------------------
 5 files changed, 247 insertions(+), 135 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 Mon Sep 17 18:22:09 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 18:22:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDfxF-0004rX-2p; Mon, 17 Sep 2012 18:21:57 +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 1TDfxC-0004ps-8j
	for xen-devel@lists.xen.org; Mon, 17 Sep 2012 18:21:54 +0000
Received: from [85.158.139.211:41713] by server-5.bemta-5.messagelabs.com id
	29/CF-30514-14A67505; Mon, 17 Sep 2012 18:21:53 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-5.tower-206.messagelabs.com!1347906108!18863259!5
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzAyMzE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4255 invoked from network); 17 Sep 2012 18:21:52 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-5.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Sep 2012 18:21:52 -0000
X-IronPort-AV: E=Sophos;i="4.80,437,1344211200"; d="scan'208";a="38109664"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Sep 2012 18:21:48 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Mon, 17 Sep 2012 14:21: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 1TDfx5-0000OF-EA;
	Mon, 17 Sep 2012 19:21:47 +0100
From: Anthony PERARD <anthony.perard@citrix.com>
To: Xen Devel <xen-devel@lists.xen.org>
Date: Mon, 17 Sep 2012 19:22:25 +0100
Message-ID: <1347906148-9606-7-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.12
In-Reply-To: <1347906148-9606-1-git-send-email-anthony.perard@citrix.com>
References: <1347906148-9606-1-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Cc: Anthony PERARD <anthony.perard@citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH V2 6/9] libxl_qmp: Simplify run of single QMP
	commands.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This new function connects to QEMU, sends the command and disconnects.

Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
 tools/libxl/libxl_qmp.c | 61 ++++++++++++++++++-------------------------------
 1 file changed, 22 insertions(+), 39 deletions(-)

diff --git a/tools/libxl/libxl_qmp.c b/tools/libxl/libxl_qmp.c
index ed67431..aac06c2 100644
--- a/tools/libxl/libxl_qmp.c
+++ b/tools/libxl/libxl_qmp.c
@@ -799,6 +799,23 @@ out:
     return rc;
 }
 
+static int qmp_run_command(libxl__gc *gc, int domid,
+                           const char *cmd, libxl__json_object *args,
+                           qmp_callback_t callback, void *opaque)
+{
+    libxl__qmp_handler *qmp = NULL;
+    int rc = 0;
+
+    qmp = libxl__qmp_initialize(gc, domid);
+    if (!qmp)
+        return ERROR_FAIL;
+
+    rc = qmp_synchronous_send(qmp, cmd, args, callback, opaque, qmp->timeout);
+
+    libxl__qmp_close(qmp);
+    return rc;
+}
+
 int libxl__qmp_pci_add(libxl__gc *gc, int domid, libxl_device_pci *pcidev)
 {
     libxl__qmp_handler *qmp = NULL;
@@ -838,21 +855,14 @@ int libxl__qmp_pci_add(libxl__gc *gc, int domid, libxl_device_pci *pcidev)
 
 static int qmp_device_del(libxl__gc *gc, int domid, char *id)
 {
-    libxl__qmp_handler *qmp = NULL;
     libxl__json_object *args = NULL;
     int rc = 0;
 
-    qmp = libxl__qmp_initialize(gc, domid);
-    if (!qmp)
-        return ERROR_FAIL;
-
     qmp_parameters_add_string(gc, &args, "id", id);
 
-    rc = qmp_synchronous_send(qmp, "device_del", args,
-                              NULL, NULL, qmp->timeout);
+    rc = qmp_run_command(gc, domid, "device_del", args, NULL, NULL);
     libxl__json_object_free(gc, args);
 
-    libxl__qmp_close(qmp);
     return rc;
 }
 
@@ -868,18 +878,13 @@ int libxl__qmp_pci_del(libxl__gc *gc, int domid, libxl_device_pci *pcidev)
 
 int libxl__qmp_save(libxl__gc *gc, int domid, const char *filename)
 {
-    libxl__qmp_handler *qmp = NULL;
     libxl__json_object *args = NULL;
     int rc = 0;
 
-    qmp = libxl__qmp_initialize(gc, domid);
-    if (!qmp)
-        return ERROR_FAIL;
-
     qmp_parameters_add_string(gc, &args, "filename", (char *)filename);
 
-    rc = qmp_synchronous_send(qmp, "xen-save-devices-state", args,
-                              NULL, NULL, qmp->timeout);
+    rc = qmp_run_command(gc, domid, "xen-save-devices-state", args,
+                         NULL, NULL);
     libxl__json_object_free(gc, args);
 
     return rc;
@@ -906,34 +911,12 @@ static int qmp_change(libxl__gc *gc, libxl__qmp_handler *qmp,
 
 int libxl__qmp_stop(libxl__gc *gc, int domid)
 {
-    libxl__qmp_handler *qmp = NULL;
-    int rc = 0;
-
-    qmp = libxl__qmp_initialize(gc, domid);
-    if (!qmp)
-        return ERROR_FAIL;
-
-    rc = qmp_synchronous_send(qmp, "stop", NULL,
-                              NULL, NULL, qmp->timeout);
-
-    libxl__qmp_close(qmp);
-    return rc;
+    return qmp_run_command(gc, domid, "stop", NULL, NULL, NULL);
 }
 
 int libxl__qmp_resume(libxl__gc *gc, int domid)
 {
-    libxl__qmp_handler *qmp = NULL;
-    int rc = 0;
-
-    qmp = libxl__qmp_initialize(gc, domid);
-    if (!qmp)
-        return ERROR_FAIL;
-
-    rc = qmp_synchronous_send(qmp, "cont", NULL,
-                              NULL, NULL, qmp->timeout);
-
-    libxl__qmp_close(qmp);
-    return rc;
+    return qmp_run_command(gc, domid, "cont", NULL, NULL, NULL);
 }
 
 int libxl__qmp_initializations(libxl__gc *gc, uint32_t domid,
-- 
Anthony PERARD


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 17 18:22:09 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 18:22:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDfxF-0004rX-2p; Mon, 17 Sep 2012 18:21:57 +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 1TDfxC-0004ps-8j
	for xen-devel@lists.xen.org; Mon, 17 Sep 2012 18:21:54 +0000
Received: from [85.158.139.211:41713] by server-5.bemta-5.messagelabs.com id
	29/CF-30514-14A67505; Mon, 17 Sep 2012 18:21:53 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-5.tower-206.messagelabs.com!1347906108!18863259!5
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzAyMzE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4255 invoked from network); 17 Sep 2012 18:21:52 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-5.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Sep 2012 18:21:52 -0000
X-IronPort-AV: E=Sophos;i="4.80,437,1344211200"; d="scan'208";a="38109664"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Sep 2012 18:21:48 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Mon, 17 Sep 2012 14:21: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 1TDfx5-0000OF-EA;
	Mon, 17 Sep 2012 19:21:47 +0100
From: Anthony PERARD <anthony.perard@citrix.com>
To: Xen Devel <xen-devel@lists.xen.org>
Date: Mon, 17 Sep 2012 19:22:25 +0100
Message-ID: <1347906148-9606-7-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.12
In-Reply-To: <1347906148-9606-1-git-send-email-anthony.perard@citrix.com>
References: <1347906148-9606-1-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Cc: Anthony PERARD <anthony.perard@citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH V2 6/9] libxl_qmp: Simplify run of single QMP
	commands.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This new function connects to QEMU, sends the command and disconnects.

Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
 tools/libxl/libxl_qmp.c | 61 ++++++++++++++++++-------------------------------
 1 file changed, 22 insertions(+), 39 deletions(-)

diff --git a/tools/libxl/libxl_qmp.c b/tools/libxl/libxl_qmp.c
index ed67431..aac06c2 100644
--- a/tools/libxl/libxl_qmp.c
+++ b/tools/libxl/libxl_qmp.c
@@ -799,6 +799,23 @@ out:
     return rc;
 }
 
+static int qmp_run_command(libxl__gc *gc, int domid,
+                           const char *cmd, libxl__json_object *args,
+                           qmp_callback_t callback, void *opaque)
+{
+    libxl__qmp_handler *qmp = NULL;
+    int rc = 0;
+
+    qmp = libxl__qmp_initialize(gc, domid);
+    if (!qmp)
+        return ERROR_FAIL;
+
+    rc = qmp_synchronous_send(qmp, cmd, args, callback, opaque, qmp->timeout);
+
+    libxl__qmp_close(qmp);
+    return rc;
+}
+
 int libxl__qmp_pci_add(libxl__gc *gc, int domid, libxl_device_pci *pcidev)
 {
     libxl__qmp_handler *qmp = NULL;
@@ -838,21 +855,14 @@ int libxl__qmp_pci_add(libxl__gc *gc, int domid, libxl_device_pci *pcidev)
 
 static int qmp_device_del(libxl__gc *gc, int domid, char *id)
 {
-    libxl__qmp_handler *qmp = NULL;
     libxl__json_object *args = NULL;
     int rc = 0;
 
-    qmp = libxl__qmp_initialize(gc, domid);
-    if (!qmp)
-        return ERROR_FAIL;
-
     qmp_parameters_add_string(gc, &args, "id", id);
 
-    rc = qmp_synchronous_send(qmp, "device_del", args,
-                              NULL, NULL, qmp->timeout);
+    rc = qmp_run_command(gc, domid, "device_del", args, NULL, NULL);
     libxl__json_object_free(gc, args);
 
-    libxl__qmp_close(qmp);
     return rc;
 }
 
@@ -868,18 +878,13 @@ int libxl__qmp_pci_del(libxl__gc *gc, int domid, libxl_device_pci *pcidev)
 
 int libxl__qmp_save(libxl__gc *gc, int domid, const char *filename)
 {
-    libxl__qmp_handler *qmp = NULL;
     libxl__json_object *args = NULL;
     int rc = 0;
 
-    qmp = libxl__qmp_initialize(gc, domid);
-    if (!qmp)
-        return ERROR_FAIL;
-
     qmp_parameters_add_string(gc, &args, "filename", (char *)filename);
 
-    rc = qmp_synchronous_send(qmp, "xen-save-devices-state", args,
-                              NULL, NULL, qmp->timeout);
+    rc = qmp_run_command(gc, domid, "xen-save-devices-state", args,
+                         NULL, NULL);
     libxl__json_object_free(gc, args);
 
     return rc;
@@ -906,34 +911,12 @@ static int qmp_change(libxl__gc *gc, libxl__qmp_handler *qmp,
 
 int libxl__qmp_stop(libxl__gc *gc, int domid)
 {
-    libxl__qmp_handler *qmp = NULL;
-    int rc = 0;
-
-    qmp = libxl__qmp_initialize(gc, domid);
-    if (!qmp)
-        return ERROR_FAIL;
-
-    rc = qmp_synchronous_send(qmp, "stop", NULL,
-                              NULL, NULL, qmp->timeout);
-
-    libxl__qmp_close(qmp);
-    return rc;
+    return qmp_run_command(gc, domid, "stop", NULL, NULL, NULL);
 }
 
 int libxl__qmp_resume(libxl__gc *gc, int domid)
 {
-    libxl__qmp_handler *qmp = NULL;
-    int rc = 0;
-
-    qmp = libxl__qmp_initialize(gc, domid);
-    if (!qmp)
-        return ERROR_FAIL;
-
-    rc = qmp_synchronous_send(qmp, "cont", NULL,
-                              NULL, NULL, qmp->timeout);
-
-    libxl__qmp_close(qmp);
-    return rc;
+    return qmp_run_command(gc, domid, "cont", NULL, NULL, NULL);
 }
 
 int libxl__qmp_initializations(libxl__gc *gc, uint32_t domid,
-- 
Anthony PERARD


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 17 18:22:09 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 18:22:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDfxD-0004qp-Nq; Mon, 17 Sep 2012 18:21:55 +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 1TDfxB-0004pf-AA
	for xen-devel@lists.xen.org; Mon, 17 Sep 2012 18:21:53 +0000
Received: from [85.158.139.211:59763] by server-11.bemta-5.messagelabs.com id
	FE/46-24658-04A67505; Mon, 17 Sep 2012 18:21:52 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-3.tower-206.messagelabs.com!1347906110!18903640!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzAyMzE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22638 invoked from network); 17 Sep 2012 18:21:51 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-3.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Sep 2012 18:21:51 -0000
X-IronPort-AV: E=Sophos;i="4.80,437,1344211200"; d="scan'208";a="38109663"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Sep 2012 18:21:48 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Mon, 17 Sep 2012 14:21: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 1TDfx5-0000OF-Fi;
	Mon, 17 Sep 2012 19:21:47 +0100
From: Anthony PERARD <anthony.perard@citrix.com>
To: Xen Devel <xen-devel@lists.xen.org>
Date: Mon, 17 Sep 2012 19:22:26 +0100
Message-ID: <1347906148-9606-8-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.12
In-Reply-To: <1347906148-9606-1-git-send-email-anthony.perard@citrix.com>
References: <1347906148-9606-1-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Cc: Anthony PERARD <anthony.perard@citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH V2 7/9] libxl_qmp: Introduce
	libxl__qmp_set_global_dirty_log.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This function will enable or disable the global dirty log on QEMU, used during
a migration.

Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
 tools/libxl/libxl_internal.h |  2 ++
 tools/libxl/libxl_qmp.c      | 16 ++++++++++++++--
 2 files changed, 16 insertions(+), 2 deletions(-)

diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 9c1482d..acdeeb2 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -1399,6 +1399,8 @@ _hidden int libxl__qmp_stop(libxl__gc *gc, int domid);
 _hidden int libxl__qmp_resume(libxl__gc *gc, int domid);
 /* Save current QEMU state into fd. */
 _hidden int libxl__qmp_save(libxl__gc *gc, int domid, const char *filename);
+/* Set dirty bitmap logging status */
+_hidden int libxl__qmp_set_global_dirty_log(libxl__gc *gc, int domid, bool enable);
 /* close and free the QMP handler */
 _hidden void libxl__qmp_close(libxl__qmp_handler *qmp);
 /* remove the socket file, if the file has already been removed,
diff --git a/tools/libxl/libxl_qmp.c b/tools/libxl/libxl_qmp.c
index aac06c2..befa11b 100644
--- a/tools/libxl/libxl_qmp.c
+++ b/tools/libxl/libxl_qmp.c
@@ -660,7 +660,6 @@ static void qmp_parameters_add_string(libxl__gc *gc,
     qmp_parameters_common_add(gc, param, name, obj);
 }
 
-#if 0
 static void qmp_parameters_add_bool(libxl__gc *gc,
                                     libxl__json_object **param,
                                     const char *name, bool b)
@@ -670,7 +669,6 @@ static void qmp_parameters_add_bool(libxl__gc *gc,
     obj = libxl__json_object_alloc(NOGC, JSON_TRUE);
     qmp_parameters_common_add(gc, param, name, obj);
 }
-#endif
 
 #define QMP_PARAMETERS_SPRINTF(gc, args, name, format, ...) \
     qmp_parameters_add_string(gc, args, name, \
@@ -919,6 +917,20 @@ int libxl__qmp_resume(libxl__gc *gc, int domid)
     return qmp_run_command(gc, domid, "cont", NULL, NULL, NULL);
 }
 
+int libxl__qmp_set_global_dirty_log(libxl__gc *gc, int domid, bool enable)
+{
+    libxl__json_object *args = NULL;
+    int rc = 0;
+
+    qmp_parameters_add_bool(gc, &args, "enable", enable);
+
+    rc = qmp_run_command(gc, domid, "xen-set-global-dirty-log", args,
+                         NULL, NULL);
+    libxl__json_object_free(gc, args);
+
+    return rc;
+}
+
 int libxl__qmp_initializations(libxl__gc *gc, uint32_t domid,
                                const libxl_domain_config *guest_config)
 {
-- 
Anthony PERARD


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 17 18:22:09 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 18:22:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDfxD-0004qp-Nq; Mon, 17 Sep 2012 18:21:55 +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 1TDfxB-0004pf-AA
	for xen-devel@lists.xen.org; Mon, 17 Sep 2012 18:21:53 +0000
Received: from [85.158.139.211:59763] by server-11.bemta-5.messagelabs.com id
	FE/46-24658-04A67505; Mon, 17 Sep 2012 18:21:52 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-3.tower-206.messagelabs.com!1347906110!18903640!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzAyMzE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22638 invoked from network); 17 Sep 2012 18:21:51 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-3.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Sep 2012 18:21:51 -0000
X-IronPort-AV: E=Sophos;i="4.80,437,1344211200"; d="scan'208";a="38109663"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Sep 2012 18:21:48 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Mon, 17 Sep 2012 14:21: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 1TDfx5-0000OF-Fi;
	Mon, 17 Sep 2012 19:21:47 +0100
From: Anthony PERARD <anthony.perard@citrix.com>
To: Xen Devel <xen-devel@lists.xen.org>
Date: Mon, 17 Sep 2012 19:22:26 +0100
Message-ID: <1347906148-9606-8-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.12
In-Reply-To: <1347906148-9606-1-git-send-email-anthony.perard@citrix.com>
References: <1347906148-9606-1-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Cc: Anthony PERARD <anthony.perard@citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH V2 7/9] libxl_qmp: Introduce
	libxl__qmp_set_global_dirty_log.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This function will enable or disable the global dirty log on QEMU, used during
a migration.

Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
 tools/libxl/libxl_internal.h |  2 ++
 tools/libxl/libxl_qmp.c      | 16 ++++++++++++++--
 2 files changed, 16 insertions(+), 2 deletions(-)

diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 9c1482d..acdeeb2 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -1399,6 +1399,8 @@ _hidden int libxl__qmp_stop(libxl__gc *gc, int domid);
 _hidden int libxl__qmp_resume(libxl__gc *gc, int domid);
 /* Save current QEMU state into fd. */
 _hidden int libxl__qmp_save(libxl__gc *gc, int domid, const char *filename);
+/* Set dirty bitmap logging status */
+_hidden int libxl__qmp_set_global_dirty_log(libxl__gc *gc, int domid, bool enable);
 /* close and free the QMP handler */
 _hidden void libxl__qmp_close(libxl__qmp_handler *qmp);
 /* remove the socket file, if the file has already been removed,
diff --git a/tools/libxl/libxl_qmp.c b/tools/libxl/libxl_qmp.c
index aac06c2..befa11b 100644
--- a/tools/libxl/libxl_qmp.c
+++ b/tools/libxl/libxl_qmp.c
@@ -660,7 +660,6 @@ static void qmp_parameters_add_string(libxl__gc *gc,
     qmp_parameters_common_add(gc, param, name, obj);
 }
 
-#if 0
 static void qmp_parameters_add_bool(libxl__gc *gc,
                                     libxl__json_object **param,
                                     const char *name, bool b)
@@ -670,7 +669,6 @@ static void qmp_parameters_add_bool(libxl__gc *gc,
     obj = libxl__json_object_alloc(NOGC, JSON_TRUE);
     qmp_parameters_common_add(gc, param, name, obj);
 }
-#endif
 
 #define QMP_PARAMETERS_SPRINTF(gc, args, name, format, ...) \
     qmp_parameters_add_string(gc, args, name, \
@@ -919,6 +917,20 @@ int libxl__qmp_resume(libxl__gc *gc, int domid)
     return qmp_run_command(gc, domid, "cont", NULL, NULL, NULL);
 }
 
+int libxl__qmp_set_global_dirty_log(libxl__gc *gc, int domid, bool enable)
+{
+    libxl__json_object *args = NULL;
+    int rc = 0;
+
+    qmp_parameters_add_bool(gc, &args, "enable", enable);
+
+    rc = qmp_run_command(gc, domid, "xen-set-global-dirty-log", args,
+                         NULL, NULL);
+    libxl__json_object_free(gc, args);
+
+    return rc;
+}
+
 int libxl__qmp_initializations(libxl__gc *gc, uint32_t domid,
                                const libxl_domain_config *guest_config)
 {
-- 
Anthony PERARD


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 17 18:22:10 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 18:22: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 1TDfxB-0004pj-46; Mon, 17 Sep 2012 18:21:53 +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 1TDfx9-0004pP-N9
	for xen-devel@lists.xen.org; Mon, 17 Sep 2012 18:21:52 +0000
Received: from [85.158.139.211:59692] by server-7.bemta-5.messagelabs.com id
	8A/64-19703-F3A67505; Mon, 17 Sep 2012 18:21:51 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-5.tower-206.messagelabs.com!1347906108!18863259!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzAyMzE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4229 invoked from network); 17 Sep 2012 18:21:50 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-5.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Sep 2012 18:21:50 -0000
X-IronPort-AV: E=Sophos;i="4.80,437,1344211200"; d="scan'208";a="38109659"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Sep 2012 18:21:47 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Mon, 17 Sep 2012 14:21: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 1TDfx5-0000OF-9G;
	Mon, 17 Sep 2012 19:21:47 +0100
From: Anthony PERARD <anthony.perard@citrix.com>
To: Xen Devel <xen-devel@lists.xen.org>
Date: Mon, 17 Sep 2012 19:22:21 +0100
Message-ID: <1347906148-9606-3-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.12
In-Reply-To: <1347906148-9606-1-git-send-email-anthony.perard@citrix.com>
References: <1347906148-9606-1-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Cc: Anthony PERARD <anthony.perard@citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH V2 2/9] libxl_json: Export json_object related
	function.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Export libxl__json_object_alloc and libxl__json_object_append_to to use them in
a later patch.

Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
 tools/libxl/libxl_internal.h |  8 ++++++++
 tools/libxl/libxl_json.c     | 34 +++++++++++++++++-----------------
 2 files changed, 25 insertions(+), 17 deletions(-)

diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index b6f54ba..3c2dcaa 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -1511,6 +1511,14 @@ static inline long long libxl__json_object_get_integer(const libxl__json_object
         return -1;
 }
 
+/* Objects allocated using this function must be free with
+ * libxl__json_object_free.
+ */
+_hidden libxl__json_object *libxl__json_object_alloc(libxl__gc *gc,
+                                                     libxl__json_node_type type);
+_hidden int libxl__json_object_append_to(libxl__gc *gc,
+                                         libxl__json_object *obj,
+                                         libxl__json_object *dst);
 _hidden libxl__json_object *libxl__json_array_get(const libxl__json_object *o,
                                                   int i);
 _hidden
diff --git a/tools/libxl/libxl_json.c b/tools/libxl/libxl_json.c
index 9c3dca2..0539865 100644
--- a/tools/libxl/libxl_json.c
+++ b/tools/libxl/libxl_json.c
@@ -205,7 +205,7 @@ yajl_gen_status libxl__string_gen_json(yajl_gen hand,
  * libxl__json_object helper functions
  */
 
-static libxl__json_object *json_object_alloc(libxl__gc *gc,
+libxl__json_object *libxl__json_object_alloc(libxl__gc *gc,
                                              libxl__json_node_type type)
 {
     libxl__json_object *obj;
@@ -231,7 +231,7 @@ static libxl__json_object *json_object_alloc(libxl__gc *gc,
     return obj;
 }
 
-static int json_object_append_to(libxl__gc *gc,
+int libxl__json_object_append_to(libxl__gc *gc,
                                  libxl__json_object *obj,
                                  libxl__json_object *dst)
 {
@@ -388,9 +388,9 @@ static int json_callback_null(void *opaque)
 
     DEBUG_GEN(ctx, null);
 
-    obj = json_object_alloc(ctx->gc, JSON_NULL);
+    obj = libxl__json_object_alloc(ctx->gc, JSON_NULL);
 
-    if (json_object_append_to(ctx->gc, obj, ctx->current) == -1) {
+    if (libxl__json_object_append_to(ctx->gc, obj, ctx->current) == -1) {
         libxl__json_object_free(ctx->gc, obj);
         return 0;
     }
@@ -405,10 +405,10 @@ static int json_callback_boolean(void *opaque, int boolean)
 
     DEBUG_GEN_VALUE(ctx, bool, boolean);
 
-    obj = json_object_alloc(ctx->gc,
-                            boolean ? JSON_TRUE : JSON_FALSE);
+    obj = libxl__json_object_alloc(ctx->gc,
+                                   boolean ? JSON_TRUE : JSON_FALSE);
 
-    if (json_object_append_to(ctx->gc, obj, ctx->current) == -1) {
+    if (libxl__json_object_append_to(ctx->gc, obj, ctx->current) == -1) {
         libxl__json_object_free(ctx->gc, obj);
         return 0;
     }
@@ -441,7 +441,7 @@ static int json_callback_number(void *opaque, const char *s, libxl_yajl_length l
             goto error;
         }
 
-        obj = json_object_alloc(ctx->gc, JSON_DOUBLE);
+        obj = libxl__json_object_alloc(ctx->gc, JSON_DOUBLE);
         obj->u.d = d;
     } else {
         long long i = strtoll(s, NULL, 10);
@@ -450,14 +450,14 @@ static int json_callback_number(void *opaque, const char *s, libxl_yajl_length l
             goto error;
         }
 
-        obj = json_object_alloc(ctx->gc, JSON_INTEGER);
+        obj = libxl__json_object_alloc(ctx->gc, JSON_INTEGER);
         obj->u.i = i;
     }
     goto out;
 
 error:
     /* If the conversion fail, we just store the original string. */
-    obj = json_object_alloc(ctx->gc, JSON_NUMBER);
+    obj = libxl__json_object_alloc(ctx->gc, JSON_NUMBER);
 
     t = malloc(len + 1);
     if (t == NULL) {
@@ -471,7 +471,7 @@ error:
     obj->u.string = t;
 
 out:
-    if (json_object_append_to(ctx->gc, obj, ctx->current) == -1) {
+    if (libxl__json_object_append_to(ctx->gc, obj, ctx->current) == -1) {
         libxl__json_object_free(ctx->gc, obj);
         return 0;
     }
@@ -498,10 +498,10 @@ static int json_callback_string(void *opaque, const unsigned char *str,
     strncpy(t, (const char *) str, len);
     t[len] = 0;
 
-    obj = json_object_alloc(ctx->gc, JSON_STRING);
+    obj = libxl__json_object_alloc(ctx->gc, JSON_STRING);
     obj->u.string = t;
 
-    if (json_object_append_to(ctx->gc, obj, ctx->current) == -1) {
+    if (libxl__json_object_append_to(ctx->gc, obj, ctx->current) == -1) {
         libxl__json_object_free(ctx->gc, obj);
         return 0;
     }
@@ -560,10 +560,10 @@ static int json_callback_start_map(void *opaque)
 
     DEBUG_GEN(ctx, map_open);
 
-    obj = json_object_alloc(ctx->gc, JSON_MAP);
+    obj = libxl__json_object_alloc(ctx->gc, JSON_MAP);
 
     if (ctx->current) {
-        if (json_object_append_to(ctx->gc, obj, ctx->current) == -1) {
+        if (libxl__json_object_append_to(ctx->gc, obj, ctx->current) == -1) {
             libxl__json_object_free(ctx->gc, obj);
             return 0;
         }
@@ -601,10 +601,10 @@ static int json_callback_start_array(void *opaque)
 
     DEBUG_GEN(ctx, array_open);
 
-    obj = json_object_alloc(ctx->gc, JSON_ARRAY);
+    obj = libxl__json_object_alloc(ctx->gc, JSON_ARRAY);
 
     if (ctx->current) {
-        if (json_object_append_to(ctx->gc, obj, ctx->current) == -1) {
+        if (libxl__json_object_append_to(ctx->gc, obj, ctx->current) == -1) {
             libxl__json_object_free(ctx->gc, obj);
             return 0;
         }
-- 
Anthony PERARD


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 17 18:22:10 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 18:22: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 1TDfxB-0004pj-46; Mon, 17 Sep 2012 18:21:53 +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 1TDfx9-0004pP-N9
	for xen-devel@lists.xen.org; Mon, 17 Sep 2012 18:21:52 +0000
Received: from [85.158.139.211:59692] by server-7.bemta-5.messagelabs.com id
	8A/64-19703-F3A67505; Mon, 17 Sep 2012 18:21:51 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-5.tower-206.messagelabs.com!1347906108!18863259!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzAyMzE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4229 invoked from network); 17 Sep 2012 18:21:50 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-5.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Sep 2012 18:21:50 -0000
X-IronPort-AV: E=Sophos;i="4.80,437,1344211200"; d="scan'208";a="38109659"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Sep 2012 18:21:47 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Mon, 17 Sep 2012 14:21: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 1TDfx5-0000OF-9G;
	Mon, 17 Sep 2012 19:21:47 +0100
From: Anthony PERARD <anthony.perard@citrix.com>
To: Xen Devel <xen-devel@lists.xen.org>
Date: Mon, 17 Sep 2012 19:22:21 +0100
Message-ID: <1347906148-9606-3-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.12
In-Reply-To: <1347906148-9606-1-git-send-email-anthony.perard@citrix.com>
References: <1347906148-9606-1-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Cc: Anthony PERARD <anthony.perard@citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH V2 2/9] libxl_json: Export json_object related
	function.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Export libxl__json_object_alloc and libxl__json_object_append_to to use them in
a later patch.

Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
 tools/libxl/libxl_internal.h |  8 ++++++++
 tools/libxl/libxl_json.c     | 34 +++++++++++++++++-----------------
 2 files changed, 25 insertions(+), 17 deletions(-)

diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index b6f54ba..3c2dcaa 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -1511,6 +1511,14 @@ static inline long long libxl__json_object_get_integer(const libxl__json_object
         return -1;
 }
 
+/* Objects allocated using this function must be free with
+ * libxl__json_object_free.
+ */
+_hidden libxl__json_object *libxl__json_object_alloc(libxl__gc *gc,
+                                                     libxl__json_node_type type);
+_hidden int libxl__json_object_append_to(libxl__gc *gc,
+                                         libxl__json_object *obj,
+                                         libxl__json_object *dst);
 _hidden libxl__json_object *libxl__json_array_get(const libxl__json_object *o,
                                                   int i);
 _hidden
diff --git a/tools/libxl/libxl_json.c b/tools/libxl/libxl_json.c
index 9c3dca2..0539865 100644
--- a/tools/libxl/libxl_json.c
+++ b/tools/libxl/libxl_json.c
@@ -205,7 +205,7 @@ yajl_gen_status libxl__string_gen_json(yajl_gen hand,
  * libxl__json_object helper functions
  */
 
-static libxl__json_object *json_object_alloc(libxl__gc *gc,
+libxl__json_object *libxl__json_object_alloc(libxl__gc *gc,
                                              libxl__json_node_type type)
 {
     libxl__json_object *obj;
@@ -231,7 +231,7 @@ static libxl__json_object *json_object_alloc(libxl__gc *gc,
     return obj;
 }
 
-static int json_object_append_to(libxl__gc *gc,
+int libxl__json_object_append_to(libxl__gc *gc,
                                  libxl__json_object *obj,
                                  libxl__json_object *dst)
 {
@@ -388,9 +388,9 @@ static int json_callback_null(void *opaque)
 
     DEBUG_GEN(ctx, null);
 
-    obj = json_object_alloc(ctx->gc, JSON_NULL);
+    obj = libxl__json_object_alloc(ctx->gc, JSON_NULL);
 
-    if (json_object_append_to(ctx->gc, obj, ctx->current) == -1) {
+    if (libxl__json_object_append_to(ctx->gc, obj, ctx->current) == -1) {
         libxl__json_object_free(ctx->gc, obj);
         return 0;
     }
@@ -405,10 +405,10 @@ static int json_callback_boolean(void *opaque, int boolean)
 
     DEBUG_GEN_VALUE(ctx, bool, boolean);
 
-    obj = json_object_alloc(ctx->gc,
-                            boolean ? JSON_TRUE : JSON_FALSE);
+    obj = libxl__json_object_alloc(ctx->gc,
+                                   boolean ? JSON_TRUE : JSON_FALSE);
 
-    if (json_object_append_to(ctx->gc, obj, ctx->current) == -1) {
+    if (libxl__json_object_append_to(ctx->gc, obj, ctx->current) == -1) {
         libxl__json_object_free(ctx->gc, obj);
         return 0;
     }
@@ -441,7 +441,7 @@ static int json_callback_number(void *opaque, const char *s, libxl_yajl_length l
             goto error;
         }
 
-        obj = json_object_alloc(ctx->gc, JSON_DOUBLE);
+        obj = libxl__json_object_alloc(ctx->gc, JSON_DOUBLE);
         obj->u.d = d;
     } else {
         long long i = strtoll(s, NULL, 10);
@@ -450,14 +450,14 @@ static int json_callback_number(void *opaque, const char *s, libxl_yajl_length l
             goto error;
         }
 
-        obj = json_object_alloc(ctx->gc, JSON_INTEGER);
+        obj = libxl__json_object_alloc(ctx->gc, JSON_INTEGER);
         obj->u.i = i;
     }
     goto out;
 
 error:
     /* If the conversion fail, we just store the original string. */
-    obj = json_object_alloc(ctx->gc, JSON_NUMBER);
+    obj = libxl__json_object_alloc(ctx->gc, JSON_NUMBER);
 
     t = malloc(len + 1);
     if (t == NULL) {
@@ -471,7 +471,7 @@ error:
     obj->u.string = t;
 
 out:
-    if (json_object_append_to(ctx->gc, obj, ctx->current) == -1) {
+    if (libxl__json_object_append_to(ctx->gc, obj, ctx->current) == -1) {
         libxl__json_object_free(ctx->gc, obj);
         return 0;
     }
@@ -498,10 +498,10 @@ static int json_callback_string(void *opaque, const unsigned char *str,
     strncpy(t, (const char *) str, len);
     t[len] = 0;
 
-    obj = json_object_alloc(ctx->gc, JSON_STRING);
+    obj = libxl__json_object_alloc(ctx->gc, JSON_STRING);
     obj->u.string = t;
 
-    if (json_object_append_to(ctx->gc, obj, ctx->current) == -1) {
+    if (libxl__json_object_append_to(ctx->gc, obj, ctx->current) == -1) {
         libxl__json_object_free(ctx->gc, obj);
         return 0;
     }
@@ -560,10 +560,10 @@ static int json_callback_start_map(void *opaque)
 
     DEBUG_GEN(ctx, map_open);
 
-    obj = json_object_alloc(ctx->gc, JSON_MAP);
+    obj = libxl__json_object_alloc(ctx->gc, JSON_MAP);
 
     if (ctx->current) {
-        if (json_object_append_to(ctx->gc, obj, ctx->current) == -1) {
+        if (libxl__json_object_append_to(ctx->gc, obj, ctx->current) == -1) {
             libxl__json_object_free(ctx->gc, obj);
             return 0;
         }
@@ -601,10 +601,10 @@ static int json_callback_start_array(void *opaque)
 
     DEBUG_GEN(ctx, array_open);
 
-    obj = json_object_alloc(ctx->gc, JSON_ARRAY);
+    obj = libxl__json_object_alloc(ctx->gc, JSON_ARRAY);
 
     if (ctx->current) {
-        if (json_object_append_to(ctx->gc, obj, ctx->current) == -1) {
+        if (libxl__json_object_append_to(ctx->gc, obj, ctx->current) == -1) {
             libxl__json_object_free(ctx->gc, obj);
             return 0;
         }
-- 
Anthony PERARD


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 17 18:22:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 18:22:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDfxE-0004r6-Hh; Mon, 17 Sep 2012 18:21: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 1TDfxB-0004pQ-T8
	for xen-devel@lists.xen.org; Mon, 17 Sep 2012 18:21:54 +0000
Received: from [85.158.139.211:54722] by server-9.bemta-5.messagelabs.com id
	0C/54-20529-14A67505; Mon, 17 Sep 2012 18:21:53 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-5.tower-206.messagelabs.com!1347906108!18863259!6
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzAyMzE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4264 invoked from network); 17 Sep 2012 18:21:53 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-5.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Sep 2012 18:21:53 -0000
X-IronPort-AV: E=Sophos;i="4.80,437,1344211200"; d="scan'208";a="38109667"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Sep 2012 18:21:48 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Mon, 17 Sep 2012 14:21: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 1TDfx5-0000OF-Io;
	Mon, 17 Sep 2012 19:21:47 +0100
From: Anthony PERARD <anthony.perard@citrix.com>
To: Xen Devel <xen-devel@lists.xen.org>
Date: Mon, 17 Sep 2012 19:22:28 +0100
Message-ID: <1347906148-9606-10-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.12
In-Reply-To: <1347906148-9606-1-git-send-email-anthony.perard@citrix.com>
References: <1347906148-9606-1-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Cc: Anthony PERARD <anthony.perard@citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH V2 9/9] libxl: Allow migration with qemu-xen.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
 tools/libxl/libxl.c | 4 ----
 1 file changed, 4 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 0857c48..f08adf3 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -770,10 +770,6 @@ int libxl_domain_suspend(libxl_ctx *ctx, uint32_t domid, int fd, int flags,
     if (type == LIBXL_DOMAIN_TYPE_HVM && flags & LIBXL_SUSPEND_LIVE) {
         switch (libxl__device_model_version_running(gc, domid)) {
         case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN:
-            LOG(ERROR,
-                "cannot live migrate HVM domains with qemu-xen device-model");
-            rc = ERROR_FAIL;
-            goto out_err;
         case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL:
             /* No problem */
             break;
-- 
Anthony PERARD


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 17 18:22:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 18:22:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDfxE-0004r6-Hh; Mon, 17 Sep 2012 18:21: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 1TDfxB-0004pQ-T8
	for xen-devel@lists.xen.org; Mon, 17 Sep 2012 18:21:54 +0000
Received: from [85.158.139.211:54722] by server-9.bemta-5.messagelabs.com id
	0C/54-20529-14A67505; Mon, 17 Sep 2012 18:21:53 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-5.tower-206.messagelabs.com!1347906108!18863259!6
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzAyMzE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4264 invoked from network); 17 Sep 2012 18:21:53 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-5.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Sep 2012 18:21:53 -0000
X-IronPort-AV: E=Sophos;i="4.80,437,1344211200"; d="scan'208";a="38109667"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Sep 2012 18:21:48 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Mon, 17 Sep 2012 14:21: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 1TDfx5-0000OF-Io;
	Mon, 17 Sep 2012 19:21:47 +0100
From: Anthony PERARD <anthony.perard@citrix.com>
To: Xen Devel <xen-devel@lists.xen.org>
Date: Mon, 17 Sep 2012 19:22:28 +0100
Message-ID: <1347906148-9606-10-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.12
In-Reply-To: <1347906148-9606-1-git-send-email-anthony.perard@citrix.com>
References: <1347906148-9606-1-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Cc: Anthony PERARD <anthony.perard@citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH V2 9/9] libxl: Allow migration with qemu-xen.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
 tools/libxl/libxl.c | 4 ----
 1 file changed, 4 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 0857c48..f08adf3 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -770,10 +770,6 @@ int libxl_domain_suspend(libxl_ctx *ctx, uint32_t domid, int fd, int flags,
     if (type == LIBXL_DOMAIN_TYPE_HVM && flags & LIBXL_SUSPEND_LIVE) {
         switch (libxl__device_model_version_running(gc, domid)) {
         case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN:
-            LOG(ERROR,
-                "cannot live migrate HVM domains with qemu-xen device-model");
-            rc = ERROR_FAIL;
-            goto out_err;
         case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL:
             /* No problem */
             break;
-- 
Anthony PERARD


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 17 18:30:06 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 18:30:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDg4y-0006IJ-Mb; Mon, 17 Sep 2012 18:29:56 +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 1TDg4x-0006IE-Oa
	for xen-devel@lists.xensource.com; Mon, 17 Sep 2012 18:29:55 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1347906588!10259406!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzQ1MDU4\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28790 invoked from network); 17 Sep 2012 18:29:49 -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; 17 Sep 2012 18:29:49 -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 q8HITj0I005680
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 17 Sep 2012 18:29:46 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
	q8HITjGc011005
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 17 Sep 2012 18:29:45 GMT
Received: from abhmt114.oracle.com (abhmt114.oracle.com [141.146.116.66])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q8HITi6U010788; Mon, 17 Sep 2012 13:29:44 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 17 Sep 2012 11:29:44 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 46CBF402B4; Mon, 17 Sep 2012 14:18:58 -0400 (EDT)
Date: Mon, 17 Sep 2012 14:18:58 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: William Dauchy <wdauchy@gmail.com>
Message-ID: <20120917181858.GA17720@phenom.dumpdata.com>
References: <1345133009-21941-1-git-send-email-konrad.wilk@oracle.com>
	<1345133009-21941-12-git-send-email-konrad.wilk@oracle.com>
	<CAJ75kXYG3uPmMhUwB9ivHt0w5gm14aqAynSWQwooWg65xLTzPw@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAJ75kXYG3uPmMhUwB9ivHt0w5gm14aqAynSWQwooWg65xLTzPw@mail.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, linux-kernel@vger.kernel.org
Subject: Re: [Xen-devel] [PATCH 11/11] xen/mmu: Release just the MFN list,
 not MFN list and part of pagetables.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Sep 17, 2012 at 08:06:26PM +0200, William Dauchy wrote:
> Hello Konrad,
> 
> On Thu, Aug 16, 2012 at 6:03 PM, Konrad Rzeszutek Wilk
> <konrad.wilk@oracle.com> wrote:
> > (XEN) mm.c:908:d0 Error getting mfn 116a83 (pfn 14e2a) from L1 entry 8000000116a83067 for l1e_owner=0, pg_owner=0
> > (XEN) mm.c:908:d0 Error getting mfn 4040 (pfn 5555555555555555) from L1 entry 0000000004040601 for l1e_owner=0, pg_owner=0
> 
> This is something I also have on my 3.4.x branch. Since then mmu.c has
> change a lot; is there an easy fix to make a backport for 3.4.x?

Uhh, can you open a new email thread with the error you are seeing and
please include the full serial log along with dmidecode pls?

> 
> -- 
> William

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 17 18:30:06 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 18:30:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDg4y-0006IJ-Mb; Mon, 17 Sep 2012 18:29:56 +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 1TDg4x-0006IE-Oa
	for xen-devel@lists.xensource.com; Mon, 17 Sep 2012 18:29:55 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1347906588!10259406!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzQ1MDU4\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28790 invoked from network); 17 Sep 2012 18:29:49 -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; 17 Sep 2012 18:29:49 -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 q8HITj0I005680
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 17 Sep 2012 18:29:46 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
	q8HITjGc011005
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 17 Sep 2012 18:29:45 GMT
Received: from abhmt114.oracle.com (abhmt114.oracle.com [141.146.116.66])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q8HITi6U010788; Mon, 17 Sep 2012 13:29:44 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 17 Sep 2012 11:29:44 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 46CBF402B4; Mon, 17 Sep 2012 14:18:58 -0400 (EDT)
Date: Mon, 17 Sep 2012 14:18:58 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: William Dauchy <wdauchy@gmail.com>
Message-ID: <20120917181858.GA17720@phenom.dumpdata.com>
References: <1345133009-21941-1-git-send-email-konrad.wilk@oracle.com>
	<1345133009-21941-12-git-send-email-konrad.wilk@oracle.com>
	<CAJ75kXYG3uPmMhUwB9ivHt0w5gm14aqAynSWQwooWg65xLTzPw@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAJ75kXYG3uPmMhUwB9ivHt0w5gm14aqAynSWQwooWg65xLTzPw@mail.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, linux-kernel@vger.kernel.org
Subject: Re: [Xen-devel] [PATCH 11/11] xen/mmu: Release just the MFN list,
 not MFN list and part of pagetables.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Sep 17, 2012 at 08:06:26PM +0200, William Dauchy wrote:
> Hello Konrad,
> 
> On Thu, Aug 16, 2012 at 6:03 PM, Konrad Rzeszutek Wilk
> <konrad.wilk@oracle.com> wrote:
> > (XEN) mm.c:908:d0 Error getting mfn 116a83 (pfn 14e2a) from L1 entry 8000000116a83067 for l1e_owner=0, pg_owner=0
> > (XEN) mm.c:908:d0 Error getting mfn 4040 (pfn 5555555555555555) from L1 entry 0000000004040601 for l1e_owner=0, pg_owner=0
> 
> This is something I also have on my 3.4.x branch. Since then mmu.c has
> change a lot; is there an easy fix to make a backport for 3.4.x?

Uhh, can you open a new email thread with the error you are seeing and
please include the full serial log along with dmidecode pls?

> 
> -- 
> William

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 17 19:15:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 19:15:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDgmf-0006kW-Kq; Mon, 17 Sep 2012 19:15:05 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <linux@eikelenboom.it>) id 1TDgmd-0006kR-Rj
	for xen-devel@lists.xen.org; Mon, 17 Sep 2012 19:15:04 +0000
Received: from [85.158.139.83:62305] by server-11.bemta-5.messagelabs.com id
	67/B7-24658-7B677505; Mon, 17 Sep 2012 19:15:03 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-10.tower-182.messagelabs.com!1347909302!31198033!1
X-Originating-IP: [188.40.164.121]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17358 invoked from network); 17 Sep 2012 19:15:02 -0000
Received: from static.121.164.40.188.clients.your-server.de (HELO
	smtp.eikelenboom.it) (188.40.164.121)
	by server-10.tower-182.messagelabs.com with AES256-SHA encrypted SMTP;
	17 Sep 2012 19:15:02 -0000
Received: from 101-67-ftth.onsneteindhoven.nl ([88.159.67.101]:53503
	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 1TDgmy-0005XH-Ux; Mon, 17 Sep 2012 21:15:25 +0200
Date: Mon, 17 Sep 2012 21:14:52 +0200
From: Sander Eikelenboom <linux@eikelenboom.it>
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <83845768.20120917211452@eikelenboom.it>
To: Konrad Rzeszutek Wilk <konrad@kernel.org>
In-Reply-To: <20120913133211.GB17060@localhost.localdomain>
References: <1136369816.20120904183757@eikelenboom.it>
	<20120904163347.GH23361@phenom.dumpdata.com>
	<143844933.20120904191941@eikelenboom.it>
	<CAOvdn6U_yHgtZwv9MWazdLbd3NLq3pwGXnZY5sL2UVBhV_FUoQ@mail.gmail.com>
	<1813712325.20120904213459@eikelenboom.it>
	<048EAD622912254A9DEA24C1734613C18C864C3C5D@FTLPMAILBOX02.citrite.net>
	<20120905140600.GA5844@phenom.dumpdata.com>
	<alpine.DEB.2.02.1209111652590.15568@kaball.uk.xensource.com>
	<1901811929.20120912122848@eikelenboom.it>
	<20120913133211.GB17060@localhost.localdomain>
MIME-Version: 1.0
Cc: Robert Phillips <robert.phillips@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Ben Guthro <ben@guthro.net>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] dom0 linux 3.6.0-rc4,
	crash due to ballooning althoug dom0_mem=X, max:X 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

Thursday, September 13, 2012, 3:32:14 PM, you wrote:

>> > Sander, could you please let me know if it fixes the problem for you?
>> 
>> It does !
>> 
>> Tested-By: Sander Eikelenboom <linux@eikelenboom.it>

> Excellent. Applied. Thx for reporting and testing.

Hi Konrad,

Could it be that i haven't seen a pull request for this one for the 3.6.0 kernel yet ?

--

Sander


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 17 19:15:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 19:15:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDgmf-0006kW-Kq; Mon, 17 Sep 2012 19:15:05 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <linux@eikelenboom.it>) id 1TDgmd-0006kR-Rj
	for xen-devel@lists.xen.org; Mon, 17 Sep 2012 19:15:04 +0000
Received: from [85.158.139.83:62305] by server-11.bemta-5.messagelabs.com id
	67/B7-24658-7B677505; Mon, 17 Sep 2012 19:15:03 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-10.tower-182.messagelabs.com!1347909302!31198033!1
X-Originating-IP: [188.40.164.121]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17358 invoked from network); 17 Sep 2012 19:15:02 -0000
Received: from static.121.164.40.188.clients.your-server.de (HELO
	smtp.eikelenboom.it) (188.40.164.121)
	by server-10.tower-182.messagelabs.com with AES256-SHA encrypted SMTP;
	17 Sep 2012 19:15:02 -0000
Received: from 101-67-ftth.onsneteindhoven.nl ([88.159.67.101]:53503
	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 1TDgmy-0005XH-Ux; Mon, 17 Sep 2012 21:15:25 +0200
Date: Mon, 17 Sep 2012 21:14:52 +0200
From: Sander Eikelenboom <linux@eikelenboom.it>
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <83845768.20120917211452@eikelenboom.it>
To: Konrad Rzeszutek Wilk <konrad@kernel.org>
In-Reply-To: <20120913133211.GB17060@localhost.localdomain>
References: <1136369816.20120904183757@eikelenboom.it>
	<20120904163347.GH23361@phenom.dumpdata.com>
	<143844933.20120904191941@eikelenboom.it>
	<CAOvdn6U_yHgtZwv9MWazdLbd3NLq3pwGXnZY5sL2UVBhV_FUoQ@mail.gmail.com>
	<1813712325.20120904213459@eikelenboom.it>
	<048EAD622912254A9DEA24C1734613C18C864C3C5D@FTLPMAILBOX02.citrite.net>
	<20120905140600.GA5844@phenom.dumpdata.com>
	<alpine.DEB.2.02.1209111652590.15568@kaball.uk.xensource.com>
	<1901811929.20120912122848@eikelenboom.it>
	<20120913133211.GB17060@localhost.localdomain>
MIME-Version: 1.0
Cc: Robert Phillips <robert.phillips@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Ben Guthro <ben@guthro.net>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] dom0 linux 3.6.0-rc4,
	crash due to ballooning althoug dom0_mem=X, max:X 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

Thursday, September 13, 2012, 3:32:14 PM, you wrote:

>> > Sander, could you please let me know if it fixes the problem for you?
>> 
>> It does !
>> 
>> Tested-By: Sander Eikelenboom <linux@eikelenboom.it>

> Excellent. Applied. Thx for reporting and testing.

Hi Konrad,

Could it be that i haven't seen a pull request for this one for the 3.6.0 kernel yet ?

--

Sander


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 17 19:25:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 19:25:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDgwg-0006w2-Ry; Mon, 17 Sep 2012 19:25:26 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ketuzsezr@gmail.com>) id 1TDgwf-0006vx-Ib
	for xen-devel@lists.xen.org; Mon, 17 Sep 2012 19:25:25 +0000
Received: from [85.158.137.99:39267] by server-7.bemta-3.messagelabs.com id
	47/BD-32000-42977505; Mon, 17 Sep 2012 19:25:24 +0000
X-Env-Sender: ketuzsezr@gmail.com
X-Msg-Ref: server-7.tower-217.messagelabs.com!1347909922!13250539!1
X-Originating-IP: [209.85.216.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24261 invoked from network); 17 Sep 2012 19:25:23 -0000
Received: from mail-qc0-f173.google.com (HELO mail-qc0-f173.google.com)
	(209.85.216.173)
	by server-7.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Sep 2012 19:25:23 -0000
Received: by qcab12 with SMTP id b12so6360232qca.32
	for <xen-devel@lists.xen.org>; Mon, 17 Sep 2012 12:25:22 -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=Aa9PnlmAOVweKLZFwexbFg344cEfieRw6K5vQbLIEgQ=;
	b=SAy+ZXL0KdH+fMRLNjKzyYg5/o6nb5375Z8VcQs6UkB3UI13ZIiNaeorqEZ/a0QZ0W
	VcUHNaz2ebeUfYze2dtHOYIF+ZIhk5WbWTzx/sS/ooWzEZ23Z6/7vdYHhO0i/vlGkNIA
	QAjzH7L+XFLkcYGRkwcSa23dbfMRFInIZrPhrxxDRE9kWA+z8RvseYkP45Qw+NaqP/sD
	0k5rmBR2bP3hjfeG4jDhJfZUhoydX+plF1v8gtxAl0D0H16xCbrFh0/3HDhmu/Hj3S0p
	pWGclejPBCEWu7pX9Q+off6NZsbUuOX2wNVQ9A0zpzvyG9M4h2Ai1JLUc3y774kDpSGQ
	ZWYA==
Received: by 10.229.137.21 with SMTP id u21mr7982373qct.142.1347909922080;
	Mon, 17 Sep 2012 12:25:22 -0700 (PDT)
Received: from phenom.dumpdata.com
	(50-195-21-189-static.hfc.comcastbusiness.net. [50.195.21.189])
	by mx.google.com with ESMTPS id y18sm16325845qaa.15.2012.09.17.12.25.20
	(version=TLSv1/SSLv3 cipher=OTHER);
	Mon, 17 Sep 2012 12:25:21 -0700 (PDT)
Date: Mon, 17 Sep 2012 15:14:33 -0400
From: Konrad Rzeszutek Wilk <konrad@kernel.org>
To: Andre Przywara <andre.przywara@amd.com>
Message-ID: <20120917191432.GA18552@phenom.dumpdata.com>
References: <501BC20F.3040205@amd.com>
	<20120803123628.GB10670@andromeda.dapyr.net>
	<20120817142237.GA8467@phenom.dumpdata.com>
	<20120914185822.GA7495@phenom.dumpdata.com>
	<5056D152.2090708@amd.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <5056D152.2090708@amd.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: Konrad Rzeszutek Wilk <konrad@darnok.org>,
	Jeremy Fitzhardinge <jeremy@goop.org>, xen-devel <xen-devel@lists.xen.org>,
	Dario Faggioli <raistlin@linux.it>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] Dom0 crash with old style AMD NUMA detection
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Sep 17, 2012 at 09:29:22AM +0200, Andre Przywara wrote:
> On 09/14/2012 08:58 PM, Konrad Rzeszutek Wilk wrote:
> >>>>[    0.000000] Kernel panic - not syncing: Attempted to kill the idle task!
> >>>>(XEN) Domain 0 crashed: 'noreboot' set - not rebooting.
> >>>>
> >>>>
> >>>>
> >>>>The obvious solution would be to explicitly deny northbridge scanning
> >>>>when running as Dom0, though I am not sure how to implement this without
> >>>>upsetting the other kernel folks about "that crappy Xen thing" again ;-)
> >>>
> >>>Heh.
> >>>Is there a numa=0 option that could be used to override it to turn it
> >>>off?
> >>
> >>Not compile tested.. but was thinking something like this:
> >
> >ping?
> 
> That looks good to me - at least for the time being.

OK, can I've your Tested-by/Acked-by on it pls?

> I just want to check how this interacts with upcoming Dom0 NUMA
> support. It wouldn't be too clever if we deliberately disable NUMA

We can always revert this patch in future versions of Linux.
> and future Xen version will allow us to use it. So let me check if I
> can confine this turn-off to the fallback K8 northbridge reading.

This potentially could work, but I would prefer to not do it for 3.6.

diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c
index a4790bf..b4edce4 100644
--- a/arch/x86/xen/setup.c
+++ b/arch/x86/xen/setup.c
@@ -17,6 +17,7 @@
 #include <asm/e820.h>
 #include <asm/setup.h>
 #include <asm/acpi.h>
+#include <asm/numa.h>
 #include <asm/xen/hypervisor.h>
 #include <asm/xen/hypercall.h>
 
@@ -483,7 +484,32 @@ void __cpuinit xen_enable_sysenter(void)
 	if(ret != 0)
 		setup_clear_cpu_cap(sysenter_feature);
 }
+#ifdef CONFIG_AMD_NUMA
+int __cpuinit xen_amd_k8(void)
+{
+	int num;
+
+	if (boot_cpu_data.x86_vendor != X86_VENDOR_AMD)
+		return -ENOENT;
+
+	for (num = 0; num < 32; num++) {
+		u32 header;
+
+		header = read_pci_config(0, num, 0, 0x00);
+		if (header != (PCI_VENDOR_ID_AMD | (0x1100<<16)) &&
+			header != (PCI_VENDOR_ID_AMD | (0x1200<<16)) &&
+			header != (PCI_VENDOR_ID_AMD | (0x1300<<16)))
+			continue;
 
+		header = read_pci_config(0, num, 1, 0x00);
+		if (header != (PCI_VENDOR_ID_AMD | (0x1101<<16)) &&
+			header != (PCI_VENDOR_ID_AMD | (0x1201<<16)) &&
+			header != (PCI_VENDOR_ID_AMD | (0x1301<<16)))
+			continue;
+		return num;
+	}
+	return -ENOENT;
+#endif
 void __cpuinit xen_enable_syscall(void)
 {
 #ifdef CONFIG_X86_64
@@ -542,4 +568,8 @@ void __init xen_arch_setup(void)
 	disable_cpufreq();
 	WARN_ON(set_pm_idle_to_default());
 	fiddle_vdso();
+#ifdef CONFIG_AMD_NUMA
+	if (xen_amd_k8() >= 0)
+		numa_off=1;
+#endif
 }

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 17 19:25:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 19:25:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDgwg-0006w2-Ry; Mon, 17 Sep 2012 19:25:26 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ketuzsezr@gmail.com>) id 1TDgwf-0006vx-Ib
	for xen-devel@lists.xen.org; Mon, 17 Sep 2012 19:25:25 +0000
Received: from [85.158.137.99:39267] by server-7.bemta-3.messagelabs.com id
	47/BD-32000-42977505; Mon, 17 Sep 2012 19:25:24 +0000
X-Env-Sender: ketuzsezr@gmail.com
X-Msg-Ref: server-7.tower-217.messagelabs.com!1347909922!13250539!1
X-Originating-IP: [209.85.216.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24261 invoked from network); 17 Sep 2012 19:25:23 -0000
Received: from mail-qc0-f173.google.com (HELO mail-qc0-f173.google.com)
	(209.85.216.173)
	by server-7.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Sep 2012 19:25:23 -0000
Received: by qcab12 with SMTP id b12so6360232qca.32
	for <xen-devel@lists.xen.org>; Mon, 17 Sep 2012 12:25:22 -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=Aa9PnlmAOVweKLZFwexbFg344cEfieRw6K5vQbLIEgQ=;
	b=SAy+ZXL0KdH+fMRLNjKzyYg5/o6nb5375Z8VcQs6UkB3UI13ZIiNaeorqEZ/a0QZ0W
	VcUHNaz2ebeUfYze2dtHOYIF+ZIhk5WbWTzx/sS/ooWzEZ23Z6/7vdYHhO0i/vlGkNIA
	QAjzH7L+XFLkcYGRkwcSa23dbfMRFInIZrPhrxxDRE9kWA+z8RvseYkP45Qw+NaqP/sD
	0k5rmBR2bP3hjfeG4jDhJfZUhoydX+plF1v8gtxAl0D0H16xCbrFh0/3HDhmu/Hj3S0p
	pWGclejPBCEWu7pX9Q+off6NZsbUuOX2wNVQ9A0zpzvyG9M4h2Ai1JLUc3y774kDpSGQ
	ZWYA==
Received: by 10.229.137.21 with SMTP id u21mr7982373qct.142.1347909922080;
	Mon, 17 Sep 2012 12:25:22 -0700 (PDT)
Received: from phenom.dumpdata.com
	(50-195-21-189-static.hfc.comcastbusiness.net. [50.195.21.189])
	by mx.google.com with ESMTPS id y18sm16325845qaa.15.2012.09.17.12.25.20
	(version=TLSv1/SSLv3 cipher=OTHER);
	Mon, 17 Sep 2012 12:25:21 -0700 (PDT)
Date: Mon, 17 Sep 2012 15:14:33 -0400
From: Konrad Rzeszutek Wilk <konrad@kernel.org>
To: Andre Przywara <andre.przywara@amd.com>
Message-ID: <20120917191432.GA18552@phenom.dumpdata.com>
References: <501BC20F.3040205@amd.com>
	<20120803123628.GB10670@andromeda.dapyr.net>
	<20120817142237.GA8467@phenom.dumpdata.com>
	<20120914185822.GA7495@phenom.dumpdata.com>
	<5056D152.2090708@amd.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <5056D152.2090708@amd.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: Konrad Rzeszutek Wilk <konrad@darnok.org>,
	Jeremy Fitzhardinge <jeremy@goop.org>, xen-devel <xen-devel@lists.xen.org>,
	Dario Faggioli <raistlin@linux.it>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] Dom0 crash with old style AMD NUMA detection
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Sep 17, 2012 at 09:29:22AM +0200, Andre Przywara wrote:
> On 09/14/2012 08:58 PM, Konrad Rzeszutek Wilk wrote:
> >>>>[    0.000000] Kernel panic - not syncing: Attempted to kill the idle task!
> >>>>(XEN) Domain 0 crashed: 'noreboot' set - not rebooting.
> >>>>
> >>>>
> >>>>
> >>>>The obvious solution would be to explicitly deny northbridge scanning
> >>>>when running as Dom0, though I am not sure how to implement this without
> >>>>upsetting the other kernel folks about "that crappy Xen thing" again ;-)
> >>>
> >>>Heh.
> >>>Is there a numa=0 option that could be used to override it to turn it
> >>>off?
> >>
> >>Not compile tested.. but was thinking something like this:
> >
> >ping?
> 
> That looks good to me - at least for the time being.

OK, can I've your Tested-by/Acked-by on it pls?

> I just want to check how this interacts with upcoming Dom0 NUMA
> support. It wouldn't be too clever if we deliberately disable NUMA

We can always revert this patch in future versions of Linux.
> and future Xen version will allow us to use it. So let me check if I
> can confine this turn-off to the fallback K8 northbridge reading.

This potentially could work, but I would prefer to not do it for 3.6.

diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c
index a4790bf..b4edce4 100644
--- a/arch/x86/xen/setup.c
+++ b/arch/x86/xen/setup.c
@@ -17,6 +17,7 @@
 #include <asm/e820.h>
 #include <asm/setup.h>
 #include <asm/acpi.h>
+#include <asm/numa.h>
 #include <asm/xen/hypervisor.h>
 #include <asm/xen/hypercall.h>
 
@@ -483,7 +484,32 @@ void __cpuinit xen_enable_sysenter(void)
 	if(ret != 0)
 		setup_clear_cpu_cap(sysenter_feature);
 }
+#ifdef CONFIG_AMD_NUMA
+int __cpuinit xen_amd_k8(void)
+{
+	int num;
+
+	if (boot_cpu_data.x86_vendor != X86_VENDOR_AMD)
+		return -ENOENT;
+
+	for (num = 0; num < 32; num++) {
+		u32 header;
+
+		header = read_pci_config(0, num, 0, 0x00);
+		if (header != (PCI_VENDOR_ID_AMD | (0x1100<<16)) &&
+			header != (PCI_VENDOR_ID_AMD | (0x1200<<16)) &&
+			header != (PCI_VENDOR_ID_AMD | (0x1300<<16)))
+			continue;
 
+		header = read_pci_config(0, num, 1, 0x00);
+		if (header != (PCI_VENDOR_ID_AMD | (0x1101<<16)) &&
+			header != (PCI_VENDOR_ID_AMD | (0x1201<<16)) &&
+			header != (PCI_VENDOR_ID_AMD | (0x1301<<16)))
+			continue;
+		return num;
+	}
+	return -ENOENT;
+#endif
 void __cpuinit xen_enable_syscall(void)
 {
 #ifdef CONFIG_X86_64
@@ -542,4 +568,8 @@ void __init xen_arch_setup(void)
 	disable_cpufreq();
 	WARN_ON(set_pm_idle_to_default());
 	fiddle_vdso();
+#ifdef CONFIG_AMD_NUMA
+	if (xen_amd_k8() >= 0)
+		numa_off=1;
+#endif
 }

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 17 19:27:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 19: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 1TDgy1-00070w-Av; Mon, 17 Sep 2012 19:26:49 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ketuzsezr@gmail.com>) id 1TDgy0-00070o-AU
	for xen-devel@lists.xen.org; Mon, 17 Sep 2012 19:26:48 +0000
Received: from [85.158.143.99:25022] by server-3.bemta-4.messagelabs.com id
	13/EB-08232-77977505; Mon, 17 Sep 2012 19:26:47 +0000
X-Env-Sender: ketuzsezr@gmail.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1347910006!30750112!1
X-Originating-IP: [209.85.216.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19613 invoked from network); 17 Sep 2012 19:26:47 -0000
Received: from mail-qc0-f173.google.com (HELO mail-qc0-f173.google.com)
	(209.85.216.173)
	by server-9.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Sep 2012 19:26:47 -0000
Received: by qcab12 with SMTP id b12so6361632qca.32
	for <xen-devel@lists.xen.org>; Mon, 17 Sep 2012 12:26:45 -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:content-transfer-encoding
	:in-reply-to:user-agent;
	bh=zwzWSzS2Saah1RKCKVgnIF3U7nQ3WH9Og+1XjwbD/pM=;
	b=Jf5FLYys0egGpLnc0LulA4HqXIinEQyoQ8IlVTvIWeJ/edNqmXBJsZLPFJZDUmhcxG
	jtaSDjxYlqknZkXpqqB8qldunIy6Kn4TJR8o9CKKQFPNAQGdjDxdZ3Dbs06AybuPiJPf
	NcPSn9r56rEYlfjP9IgVqYGWwG13YTSxf6Lv7HKM+90KuAy4JqBlkQ7wQJhIBTvLFuFM
	q0KVdun5BQiLNe0V0C0wpNpCSkJ9+0ynN5D745OdZqjKcPeCEPeXG26t8AmDjpLgpaO8
	d0DGkWcUvWebeEtbTkWg1WAZlcnjm7C9fcVNtAN5kvB21mDUVdLdAFdNf6vtvtQKp1ts
	T0Ww==
Received: by 10.229.105.205 with SMTP id u13mr8167942qco.9.1347910005728;
	Mon, 17 Sep 2012 12:26:45 -0700 (PDT)
Received: from phenom.dumpdata.com
	(50-195-21-189-static.hfc.comcastbusiness.net. [50.195.21.189])
	by mx.google.com with ESMTPS id gy5sm16335121qab.5.2012.09.17.12.26.44
	(version=TLSv1/SSLv3 cipher=OTHER);
	Mon, 17 Sep 2012 12:26:45 -0700 (PDT)
Date: Mon, 17 Sep 2012 15:15:57 -0400
From: Konrad Rzeszutek Wilk <konrad@kernel.org>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120917191556.GB18552@phenom.dumpdata.com>
References: <20120917113833.GH8912@reaktio.net>
	<50570EA7.8060509@student.chalmers.se>
	<20120917123205.GJ8912@reaktio.net>
	<1347885774.14977.64.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1347885774.14977.64.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: "xen@lists.fedoraproject.org" <xen@lists.fedoraproject.org>,
	Robin Axelsson <gu99roax@student.chalmers.se>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen PCI passthru supported reset methods (d3d0, FLR,
 bus reset, link reset)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="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, Sep 17, 2012 at 01:42:54PM +0100, Ian Campbell wrote:
> On Mon, 2012-09-17 at 13:32 +0100, Pasi K=E4rkk=E4inen wrote:
> > On Mon, Sep 17, 2012 at 01:51:03PM +0200, Robin Axelsson wrote:
> > > =

> > > There is one thing I wonder though when it comes to PCI passthrough:
> > > =

> > > Can Xen reset hardware through the d3d0 in the ACPI interface and/or
> > > through a 'bus reset' or a 'link reset'? Or can it reset hardware
> > > that is marked for passthrough only through FLR?
> > > =

> > > For details see e.g.
> > > http://www.vmware.com/files/pdf/techpaper/vsp_4_vmdirectpath_host.pdf
> > >
> > =

> > I added xen-devel to the CC-list.
> > Hopefully someone there can reply this question.
> =

> With a pvops dom0 Xen resets devices by writing to its "reset" node in
> sysfs so it will reset the device using whatever method the dom0 kernel
> supports for that device.

And if you use Xen PCI-back it has this enabled so you don't even
need the 'reset' functionality.
> =

> The version of Linux I have to hand has, in __pci_dev_reset, calls to
> the following in this order and stops after the first one which
> succeeds:
>       * pci_dev_specific_reset (AKA per device quirks)
>       * pcie_flr
>       * pci_af_flr
>       * pci_pm_reset
>       * pci_parent_bus_reset
> =

> See drivers/pci/pci.c in the kernel for more info.
> =

> IIRC classic Xen kernels had similar code in pciback, although I don't
> know which specific sets of actions or in which order they were tried.
> =

> Ian.
> =

> =

> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
> =


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 17 19:27:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 19: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 1TDgy1-00070w-Av; Mon, 17 Sep 2012 19:26:49 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ketuzsezr@gmail.com>) id 1TDgy0-00070o-AU
	for xen-devel@lists.xen.org; Mon, 17 Sep 2012 19:26:48 +0000
Received: from [85.158.143.99:25022] by server-3.bemta-4.messagelabs.com id
	13/EB-08232-77977505; Mon, 17 Sep 2012 19:26:47 +0000
X-Env-Sender: ketuzsezr@gmail.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1347910006!30750112!1
X-Originating-IP: [209.85.216.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19613 invoked from network); 17 Sep 2012 19:26:47 -0000
Received: from mail-qc0-f173.google.com (HELO mail-qc0-f173.google.com)
	(209.85.216.173)
	by server-9.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Sep 2012 19:26:47 -0000
Received: by qcab12 with SMTP id b12so6361632qca.32
	for <xen-devel@lists.xen.org>; Mon, 17 Sep 2012 12:26:45 -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:content-transfer-encoding
	:in-reply-to:user-agent;
	bh=zwzWSzS2Saah1RKCKVgnIF3U7nQ3WH9Og+1XjwbD/pM=;
	b=Jf5FLYys0egGpLnc0LulA4HqXIinEQyoQ8IlVTvIWeJ/edNqmXBJsZLPFJZDUmhcxG
	jtaSDjxYlqknZkXpqqB8qldunIy6Kn4TJR8o9CKKQFPNAQGdjDxdZ3Dbs06AybuPiJPf
	NcPSn9r56rEYlfjP9IgVqYGWwG13YTSxf6Lv7HKM+90KuAy4JqBlkQ7wQJhIBTvLFuFM
	q0KVdun5BQiLNe0V0C0wpNpCSkJ9+0ynN5D745OdZqjKcPeCEPeXG26t8AmDjpLgpaO8
	d0DGkWcUvWebeEtbTkWg1WAZlcnjm7C9fcVNtAN5kvB21mDUVdLdAFdNf6vtvtQKp1ts
	T0Ww==
Received: by 10.229.105.205 with SMTP id u13mr8167942qco.9.1347910005728;
	Mon, 17 Sep 2012 12:26:45 -0700 (PDT)
Received: from phenom.dumpdata.com
	(50-195-21-189-static.hfc.comcastbusiness.net. [50.195.21.189])
	by mx.google.com with ESMTPS id gy5sm16335121qab.5.2012.09.17.12.26.44
	(version=TLSv1/SSLv3 cipher=OTHER);
	Mon, 17 Sep 2012 12:26:45 -0700 (PDT)
Date: Mon, 17 Sep 2012 15:15:57 -0400
From: Konrad Rzeszutek Wilk <konrad@kernel.org>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120917191556.GB18552@phenom.dumpdata.com>
References: <20120917113833.GH8912@reaktio.net>
	<50570EA7.8060509@student.chalmers.se>
	<20120917123205.GJ8912@reaktio.net>
	<1347885774.14977.64.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1347885774.14977.64.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: "xen@lists.fedoraproject.org" <xen@lists.fedoraproject.org>,
	Robin Axelsson <gu99roax@student.chalmers.se>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen PCI passthru supported reset methods (d3d0, FLR,
 bus reset, link reset)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="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, Sep 17, 2012 at 01:42:54PM +0100, Ian Campbell wrote:
> On Mon, 2012-09-17 at 13:32 +0100, Pasi K=E4rkk=E4inen wrote:
> > On Mon, Sep 17, 2012 at 01:51:03PM +0200, Robin Axelsson wrote:
> > > =

> > > There is one thing I wonder though when it comes to PCI passthrough:
> > > =

> > > Can Xen reset hardware through the d3d0 in the ACPI interface and/or
> > > through a 'bus reset' or a 'link reset'? Or can it reset hardware
> > > that is marked for passthrough only through FLR?
> > > =

> > > For details see e.g.
> > > http://www.vmware.com/files/pdf/techpaper/vsp_4_vmdirectpath_host.pdf
> > >
> > =

> > I added xen-devel to the CC-list.
> > Hopefully someone there can reply this question.
> =

> With a pvops dom0 Xen resets devices by writing to its "reset" node in
> sysfs so it will reset the device using whatever method the dom0 kernel
> supports for that device.

And if you use Xen PCI-back it has this enabled so you don't even
need the 'reset' functionality.
> =

> The version of Linux I have to hand has, in __pci_dev_reset, calls to
> the following in this order and stops after the first one which
> succeeds:
>       * pci_dev_specific_reset (AKA per device quirks)
>       * pcie_flr
>       * pci_af_flr
>       * pci_pm_reset
>       * pci_parent_bus_reset
> =

> See drivers/pci/pci.c in the kernel for more info.
> =

> IIRC classic Xen kernels had similar code in pciback, although I don't
> know which specific sets of actions or in which order they were tried.
> =

> Ian.
> =

> =

> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
> =


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 17 19:34:53 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 19: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 1TDh5W-0007Fs-8G; Mon, 17 Sep 2012 19:34:34 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ketuzsezr@gmail.com>) id 1TDh5V-0007Fi-5F
	for xen-devel@lists.xen.org; Mon, 17 Sep 2012 19:34:33 +0000
X-Env-Sender: ketuzsezr@gmail.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1347910466!9392500!1
X-Originating-IP: [209.85.216.52]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9880 invoked from network); 17 Sep 2012 19:34:27 -0000
Received: from mail-qa0-f52.google.com (HELO mail-qa0-f52.google.com)
	(209.85.216.52)
	by server-3.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Sep 2012 19:34:27 -0000
Received: by qabg14 with SMTP id g14so2170996qab.11
	for <xen-devel@lists.xen.org>; Mon, 17 Sep 2012 12:34:25 -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=RSuQUrAi9u/oLlovCRwmkgf4Hll2YxhohJ6a73mwbNE=;
	b=mDQxmLbEdSkrlQiY+MLfrrCUNUvVR0xf1tfLoqq6wlyhW5mf4td7g8+iHl6DDOSFG7
	3JbUoPXR4uiPCWLP5l6TQnJaGx0xmpPXIxLUBnubHGXxHhPU7fS6NsKUmJCnarxB08qN
	IqxsoJuvnzLZCs9RZJdz/FYtVGvDaJSPOZTSFBUUQp1VFaIiYFg04IS617B6jNz/hUG5
	jusvDK7XT+pTn8zXHF++YQ5gIHKHwiVDOKEdI/CAfFZl0VdjBKXDGMXzGZdjPZpwZu/k
	fnHKjtTNTRaTA++mgZJir4sdH/QygScLKQNno1io0ZQhhofONB1qnxSLIlU8hYRUrC/u
	lhmQ==
Received: by 10.229.137.84 with SMTP id v20mr8092984qct.70.1347910465790;
	Mon, 17 Sep 2012 12:34:25 -0700 (PDT)
Received: from phenom.dumpdata.com
	(50-195-21-189-static.hfc.comcastbusiness.net. [50.195.21.189])
	by mx.google.com with ESMTPS id go9sm16368778qab.21.2012.09.17.12.34.24
	(version=TLSv1/SSLv3 cipher=OTHER);
	Mon, 17 Sep 2012 12:34:25 -0700 (PDT)
Date: Mon, 17 Sep 2012 15:23:37 -0400
From: Konrad Rzeszutek Wilk <konrad@kernel.org>
To: Sander Eikelenboom <linux@eikelenboom.it>, andre.przywara@amd.com
Message-ID: <20120917192336.GC18552@phenom.dumpdata.com>
References: <20120904163347.GH23361@phenom.dumpdata.com>
	<143844933.20120904191941@eikelenboom.it>
	<CAOvdn6U_yHgtZwv9MWazdLbd3NLq3pwGXnZY5sL2UVBhV_FUoQ@mail.gmail.com>
	<1813712325.20120904213459@eikelenboom.it>
	<048EAD622912254A9DEA24C1734613C18C864C3C5D@FTLPMAILBOX02.citrite.net>
	<20120905140600.GA5844@phenom.dumpdata.com>
	<alpine.DEB.2.02.1209111652590.15568@kaball.uk.xensource.com>
	<1901811929.20120912122848@eikelenboom.it>
	<20120913133211.GB17060@localhost.localdomain>
	<83845768.20120917211452@eikelenboom.it>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <83845768.20120917211452@eikelenboom.it>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: Robert Phillips <robert.phillips@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Ben Guthro <ben@guthro.net>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] dom0 linux 3.6.0-rc4,
 crash due to ballooning althoug dom0_mem=X, max:X set
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Sep 17, 2012 at 09:14:52PM +0200, Sander Eikelenboom wrote:
> Thursday, September 13, 2012, 3:32:14 PM, you wrote:
> 
> >> > Sander, could you please let me know if it fixes the problem for you?
> >> 
> >> It does !
> >> 
> >> Tested-By: Sander Eikelenboom <linux@eikelenboom.it>
> 
> > Excellent. Applied. Thx for reporting and testing.
> 
> Hi Konrad,
> 
> Could it be that i haven't seen a pull request for this one for the 3.6.0 kernel yet ?

Correct. I am waiting for Andre Przyrwa to give me heads up on the AMD
NUMA bugfix so I can push two bug-fixes to Linus ASAP.

> 
> --
> 
> Sander
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 17 19:34:53 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 19: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 1TDh5W-0007Fs-8G; Mon, 17 Sep 2012 19:34:34 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ketuzsezr@gmail.com>) id 1TDh5V-0007Fi-5F
	for xen-devel@lists.xen.org; Mon, 17 Sep 2012 19:34:33 +0000
X-Env-Sender: ketuzsezr@gmail.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1347910466!9392500!1
X-Originating-IP: [209.85.216.52]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9880 invoked from network); 17 Sep 2012 19:34:27 -0000
Received: from mail-qa0-f52.google.com (HELO mail-qa0-f52.google.com)
	(209.85.216.52)
	by server-3.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Sep 2012 19:34:27 -0000
Received: by qabg14 with SMTP id g14so2170996qab.11
	for <xen-devel@lists.xen.org>; Mon, 17 Sep 2012 12:34:25 -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=RSuQUrAi9u/oLlovCRwmkgf4Hll2YxhohJ6a73mwbNE=;
	b=mDQxmLbEdSkrlQiY+MLfrrCUNUvVR0xf1tfLoqq6wlyhW5mf4td7g8+iHl6DDOSFG7
	3JbUoPXR4uiPCWLP5l6TQnJaGx0xmpPXIxLUBnubHGXxHhPU7fS6NsKUmJCnarxB08qN
	IqxsoJuvnzLZCs9RZJdz/FYtVGvDaJSPOZTSFBUUQp1VFaIiYFg04IS617B6jNz/hUG5
	jusvDK7XT+pTn8zXHF++YQ5gIHKHwiVDOKEdI/CAfFZl0VdjBKXDGMXzGZdjPZpwZu/k
	fnHKjtTNTRaTA++mgZJir4sdH/QygScLKQNno1io0ZQhhofONB1qnxSLIlU8hYRUrC/u
	lhmQ==
Received: by 10.229.137.84 with SMTP id v20mr8092984qct.70.1347910465790;
	Mon, 17 Sep 2012 12:34:25 -0700 (PDT)
Received: from phenom.dumpdata.com
	(50-195-21-189-static.hfc.comcastbusiness.net. [50.195.21.189])
	by mx.google.com with ESMTPS id go9sm16368778qab.21.2012.09.17.12.34.24
	(version=TLSv1/SSLv3 cipher=OTHER);
	Mon, 17 Sep 2012 12:34:25 -0700 (PDT)
Date: Mon, 17 Sep 2012 15:23:37 -0400
From: Konrad Rzeszutek Wilk <konrad@kernel.org>
To: Sander Eikelenboom <linux@eikelenboom.it>, andre.przywara@amd.com
Message-ID: <20120917192336.GC18552@phenom.dumpdata.com>
References: <20120904163347.GH23361@phenom.dumpdata.com>
	<143844933.20120904191941@eikelenboom.it>
	<CAOvdn6U_yHgtZwv9MWazdLbd3NLq3pwGXnZY5sL2UVBhV_FUoQ@mail.gmail.com>
	<1813712325.20120904213459@eikelenboom.it>
	<048EAD622912254A9DEA24C1734613C18C864C3C5D@FTLPMAILBOX02.citrite.net>
	<20120905140600.GA5844@phenom.dumpdata.com>
	<alpine.DEB.2.02.1209111652590.15568@kaball.uk.xensource.com>
	<1901811929.20120912122848@eikelenboom.it>
	<20120913133211.GB17060@localhost.localdomain>
	<83845768.20120917211452@eikelenboom.it>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <83845768.20120917211452@eikelenboom.it>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: Robert Phillips <robert.phillips@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Ben Guthro <ben@guthro.net>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] dom0 linux 3.6.0-rc4,
 crash due to ballooning althoug dom0_mem=X, max:X set
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Sep 17, 2012 at 09:14:52PM +0200, Sander Eikelenboom wrote:
> Thursday, September 13, 2012, 3:32:14 PM, you wrote:
> 
> >> > Sander, could you please let me know if it fixes the problem for you?
> >> 
> >> It does !
> >> 
> >> Tested-By: Sander Eikelenboom <linux@eikelenboom.it>
> 
> > Excellent. Applied. Thx for reporting and testing.
> 
> Hi Konrad,
> 
> Could it be that i haven't seen a pull request for this one for the 3.6.0 kernel yet ?

Correct. I am waiting for Andre Przyrwa to give me heads up on the AMD
NUMA bugfix so I can push two bug-fixes to Linus ASAP.

> 
> --
> 
> Sander
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 17 20:10:17 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 20: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 1TDhdj-0007aZ-8V; Mon, 17 Sep 2012 20:09:55 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jmarcet@gmail.com>) id 1TDhdh-0007aU-Ch
	for xen-devel@lists.xen.org; Mon, 17 Sep 2012 20:09:53 +0000
Received: from [85.158.138.51:37877] by server-7.bemta-3.messagelabs.com id
	93/AD-32000-09387505; Mon, 17 Sep 2012 20:09:52 +0000
X-Env-Sender: jmarcet@gmail.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1347912590!30896058!1
X-Originating-IP: [209.85.214.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9336 invoked from network); 17 Sep 2012 20:09:51 -0000
Received: from mail-ob0-f173.google.com (HELO mail-ob0-f173.google.com)
	(209.85.214.173)
	by server-2.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Sep 2012 20:09:51 -0000
Received: by obbta14 with SMTP id ta14so11911180obb.32
	for <xen-devel@lists.xen.org>; Mon, 17 Sep 2012 13:09: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:from:date:message-id:subject:to
	:cc:content-type;
	bh=ilwMUbphdku6+6bf1M/1IYb1M/z/4mOyN0rBNGMOSWc=;
	b=EruD63UN86b8DA9OtAbQgENWrw1xSJ+gTEJYTHcyUiXnOaki0rityWMZ8oRSJ73r5A
	guC2LvZa0BiRApRFoj+k+TAseYuoU/wul1D0M81Y5f92bmg8YZSpwfms0fAxZHMltqSE
	NGKNa4V9UJgfIciiyJQ/LK4JnF2bHBI4nQXQefXP1sLHJDACi5A2ub7qPNWvLzLp0hqv
	UI8cHkTjKS2yMV80aFatTDHMaJUFmNhyuYidkAWXJ2u8DBFMP52zJ31hRawa1QEZ1whh
	8PndN+FdHWP0oMNuSBKqOzNNPE5jD4LACV25mUmCJrEtt/amhlmSp8twQgWOqNosyw/O
	8LOg==
Received: by 10.60.8.39 with SMTP id o7mr13210378oea.122.1347912590245; Mon,
	17 Sep 2012 13:09:50 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.60.138.225 with HTTP; Mon, 17 Sep 2012 13:09:29 -0700 (PDT)
In-Reply-To: <20120917142851.GB14012@phenom.dumpdata.com>
References: <CAAnFQG9TZj=SxYK_jxqN=M6L40vL=AZu9EM2tbEffPhkL1s8FA@mail.gmail.com>
	<CACJDEmqdqA6CE9SgLL2QCNmQH1dOX0_4OHfJfzes+G6bEkQ7FA@mail.gmail.com>
	<CAAnFQG-8Fkunv6R8+GCLAH4yQCx4-Nn0zN_Ntsf0wsh5yXeihQ@mail.gmail.com>
	<20120917142851.GB14012@phenom.dumpdata.com>
From: Javier Marcet <jmarcet@gmail.com>
Date: Mon, 17 Sep 2012 22:09:29 +0200
Message-ID: <CAAnFQG9bUUU8OBeKxYh=O3rRrnEPb4r1bPCr-EHWHuUS8shBhA@mail.gmail.com>
To: Konrad Rzeszutek Wilk <konrad@kernel.org>
Cc: Xen Devel Mailing list <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.2.0-rc4 issues with DVB tuner
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Sep 17, 2012 at 4:28 PM, Konrad Rzeszutek Wilk
<konrad@kernel.org> wrote:

>> >> I wonder whether it would work within a DomU with the PCIe tuner
>> >> passed through.
>> >
>> > I've a 4 channel security card passed in and it works nicely. The
>> > trick is that you need 'iommu=soft' on the domU command line.
>>
>> All right. But is it normal that it does not work under the dom0?
>
> No. PV domU and PV dom0 are pretty much the same in the way of handling
> interrupts, ports, etc.
>
> If you crank up the debug level of the kernel (debug loglevel=8) and
> of the driver do you get anything obvious? What about the questions
> I've asked?

Booting with 'debug loglevel=8' as kernel parameters I still get no errors or
warnings anywhere.

I'm out of ideas and I don't have any other PCIe tuner card to try.

It is looking more and more as a cx23885 (the module the card uses) issue.
It is really odd since I you get some data, but just like if there was very
poor reception, more noise than signal.

If you can think of some other way to debug this, I'll try it.


-- 
Javier Marcet <jmarcet@gmail.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 17 20:10:17 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 20: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 1TDhdj-0007aZ-8V; Mon, 17 Sep 2012 20:09:55 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jmarcet@gmail.com>) id 1TDhdh-0007aU-Ch
	for xen-devel@lists.xen.org; Mon, 17 Sep 2012 20:09:53 +0000
Received: from [85.158.138.51:37877] by server-7.bemta-3.messagelabs.com id
	93/AD-32000-09387505; Mon, 17 Sep 2012 20:09:52 +0000
X-Env-Sender: jmarcet@gmail.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1347912590!30896058!1
X-Originating-IP: [209.85.214.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9336 invoked from network); 17 Sep 2012 20:09:51 -0000
Received: from mail-ob0-f173.google.com (HELO mail-ob0-f173.google.com)
	(209.85.214.173)
	by server-2.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Sep 2012 20:09:51 -0000
Received: by obbta14 with SMTP id ta14so11911180obb.32
	for <xen-devel@lists.xen.org>; Mon, 17 Sep 2012 13:09: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:from:date:message-id:subject:to
	:cc:content-type;
	bh=ilwMUbphdku6+6bf1M/1IYb1M/z/4mOyN0rBNGMOSWc=;
	b=EruD63UN86b8DA9OtAbQgENWrw1xSJ+gTEJYTHcyUiXnOaki0rityWMZ8oRSJ73r5A
	guC2LvZa0BiRApRFoj+k+TAseYuoU/wul1D0M81Y5f92bmg8YZSpwfms0fAxZHMltqSE
	NGKNa4V9UJgfIciiyJQ/LK4JnF2bHBI4nQXQefXP1sLHJDACi5A2ub7qPNWvLzLp0hqv
	UI8cHkTjKS2yMV80aFatTDHMaJUFmNhyuYidkAWXJ2u8DBFMP52zJ31hRawa1QEZ1whh
	8PndN+FdHWP0oMNuSBKqOzNNPE5jD4LACV25mUmCJrEtt/amhlmSp8twQgWOqNosyw/O
	8LOg==
Received: by 10.60.8.39 with SMTP id o7mr13210378oea.122.1347912590245; Mon,
	17 Sep 2012 13:09:50 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.60.138.225 with HTTP; Mon, 17 Sep 2012 13:09:29 -0700 (PDT)
In-Reply-To: <20120917142851.GB14012@phenom.dumpdata.com>
References: <CAAnFQG9TZj=SxYK_jxqN=M6L40vL=AZu9EM2tbEffPhkL1s8FA@mail.gmail.com>
	<CACJDEmqdqA6CE9SgLL2QCNmQH1dOX0_4OHfJfzes+G6bEkQ7FA@mail.gmail.com>
	<CAAnFQG-8Fkunv6R8+GCLAH4yQCx4-Nn0zN_Ntsf0wsh5yXeihQ@mail.gmail.com>
	<20120917142851.GB14012@phenom.dumpdata.com>
From: Javier Marcet <jmarcet@gmail.com>
Date: Mon, 17 Sep 2012 22:09:29 +0200
Message-ID: <CAAnFQG9bUUU8OBeKxYh=O3rRrnEPb4r1bPCr-EHWHuUS8shBhA@mail.gmail.com>
To: Konrad Rzeszutek Wilk <konrad@kernel.org>
Cc: Xen Devel Mailing list <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.2.0-rc4 issues with DVB tuner
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Sep 17, 2012 at 4:28 PM, Konrad Rzeszutek Wilk
<konrad@kernel.org> wrote:

>> >> I wonder whether it would work within a DomU with the PCIe tuner
>> >> passed through.
>> >
>> > I've a 4 channel security card passed in and it works nicely. The
>> > trick is that you need 'iommu=soft' on the domU command line.
>>
>> All right. But is it normal that it does not work under the dom0?
>
> No. PV domU and PV dom0 are pretty much the same in the way of handling
> interrupts, ports, etc.
>
> If you crank up the debug level of the kernel (debug loglevel=8) and
> of the driver do you get anything obvious? What about the questions
> I've asked?

Booting with 'debug loglevel=8' as kernel parameters I still get no errors or
warnings anywhere.

I'm out of ideas and I don't have any other PCIe tuner card to try.

It is looking more and more as a cx23885 (the module the card uses) issue.
It is really odd since I you get some data, but just like if there was very
poor reception, more noise than signal.

If you can think of some other way to debug this, I'll try it.


-- 
Javier Marcet <jmarcet@gmail.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 17 20:57:41 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 20:57:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDiNZ-0008Uo-Nq; Mon, 17 Sep 2012 20:57:17 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jmarcet@gmail.com>) id 1TDiNY-0008Uj-5K
	for xen-devel@lists.xen.org; Mon, 17 Sep 2012 20:57:16 +0000
Received: from [85.158.143.35:55198] by server-2.bemta-4.messagelabs.com id
	77/62-06610-BAE87505; Mon, 17 Sep 2012 20:57:15 +0000
X-Env-Sender: jmarcet@gmail.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1347915433!7637651!1
X-Originating-IP: [209.85.214.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 543 invoked from network); 17 Sep 2012 20:57:14 -0000
Received: from mail-ob0-f173.google.com (HELO mail-ob0-f173.google.com)
	(209.85.214.173)
	by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Sep 2012 20:57:14 -0000
Received: by obbta14 with SMTP id ta14so11976027obb.32
	for <xen-devel@lists.xen.org>; Mon, 17 Sep 2012 13:57:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to
	:cc:content-type;
	bh=HHCT0bq2Q/F7f3bUHA8p5zAHRVv4TBecRNevujPGOMA=;
	b=Gl0jxboU5b2ZqT5gYHKJ8p+XWfzw/HN3wc+QS0tqYo8do8LvtpT4AnBOTLqrFFtgdF
	1LqfRyLtpMQ2MNx1cdGC2/6L2oPKMrE5Yuy0zBAsmADhOqib2rhVzsb2w3DYgqGD2Po+
	chU4ZyPLPVFh0YUMKN/7ewTiK6VQpyHD9zl+XimGoz4IEyBK17IOUjVpc7V6+Ineo1NM
	SIP0S9kj8BVS1aKO+AZrQy7Pv2UfjuJAxq32tTRNZXh9OdFi0qPNrVcDfK2Suuno/nj/
	QCCyUZonO6oHDda62sru63TjU+YkZLtr/a6n46RGZhUIt7yEZ6eNrcBRdsbcIygsyTcY
	AHQQ==
Received: by 10.182.177.7 with SMTP id cm7mr13182641obc.17.1347915433289; Mon,
	17 Sep 2012 13:57:13 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.60.138.225 with HTTP; Mon, 17 Sep 2012 13:56:52 -0700 (PDT)
In-Reply-To: <CAAnFQG9bUUU8OBeKxYh=O3rRrnEPb4r1bPCr-EHWHuUS8shBhA@mail.gmail.com>
References: <CAAnFQG9TZj=SxYK_jxqN=M6L40vL=AZu9EM2tbEffPhkL1s8FA@mail.gmail.com>
	<CACJDEmqdqA6CE9SgLL2QCNmQH1dOX0_4OHfJfzes+G6bEkQ7FA@mail.gmail.com>
	<CAAnFQG-8Fkunv6R8+GCLAH4yQCx4-Nn0zN_Ntsf0wsh5yXeihQ@mail.gmail.com>
	<20120917142851.GB14012@phenom.dumpdata.com>
	<CAAnFQG9bUUU8OBeKxYh=O3rRrnEPb4r1bPCr-EHWHuUS8shBhA@mail.gmail.com>
From: Javier Marcet <jmarcet@gmail.com>
Date: Mon, 17 Sep 2012 22:56:52 +0200
Message-ID: <CAAnFQG_VnZOYs3SJvO1Gc8P98kOW=6Wxc7tM_vEF8GiACgeVWg@mail.gmail.com>
To: Konrad Rzeszutek Wilk <konrad@kernel.org>
Cc: Xen Devel Mailing list <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.2.0-rc4 issues with DVB tuner
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Sep 17, 2012 at 10:09 PM, Javier Marcet <jmarcet@gmail.com> wrote:

>>> >> I wonder whether it would work within a DomU with the PCIe tuner
>>> >> passed through.
>>> >
>>> > I've a 4 channel security card passed in and it works nicely. The
>>> > trick is that you need 'iommu=soft' on the domU command line.
>>>
>>> All right. But is it normal that it does not work under the dom0?
>>
>> No. PV domU and PV dom0 are pretty much the same in the way of handling
>> interrupts, ports, etc.
>>
>> If you crank up the debug level of the kernel (debug loglevel=8) and
>> of the driver do you get anything obvious? What about the questions
>> I've asked?
>
> Booting with 'debug loglevel=8' as kernel parameters I still get no errors or
> warnings anywhere.
>
> I'm out of ideas and I don't have any other PCIe tuner card to try.
>
> It is looking more and more as a cx23885 (the module the card uses) issue.
> It is really odd since I you get some data, but just like if there was very
> poor reception, more noise than signal.
>
> If you can think of some other way to debug this, I'll try it.

I've just realized that I have quite a lot of debug options in the dvb
driver. Right
now I have one tuner in use, but when it finishes (or tomorrow) I'll enable some
debug output in the dvb subsystem and the cx23885 module in particular and
see whether I can get some more info.

Even so, if you deem worth checking something else, I'm open to try anything.


-- 
Javier Marcet <jmarcet@gmail.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 17 20:57:41 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 20:57:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDiNZ-0008Uo-Nq; Mon, 17 Sep 2012 20:57:17 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jmarcet@gmail.com>) id 1TDiNY-0008Uj-5K
	for xen-devel@lists.xen.org; Mon, 17 Sep 2012 20:57:16 +0000
Received: from [85.158.143.35:55198] by server-2.bemta-4.messagelabs.com id
	77/62-06610-BAE87505; Mon, 17 Sep 2012 20:57:15 +0000
X-Env-Sender: jmarcet@gmail.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1347915433!7637651!1
X-Originating-IP: [209.85.214.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 543 invoked from network); 17 Sep 2012 20:57:14 -0000
Received: from mail-ob0-f173.google.com (HELO mail-ob0-f173.google.com)
	(209.85.214.173)
	by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Sep 2012 20:57:14 -0000
Received: by obbta14 with SMTP id ta14so11976027obb.32
	for <xen-devel@lists.xen.org>; Mon, 17 Sep 2012 13:57:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to
	:cc:content-type;
	bh=HHCT0bq2Q/F7f3bUHA8p5zAHRVv4TBecRNevujPGOMA=;
	b=Gl0jxboU5b2ZqT5gYHKJ8p+XWfzw/HN3wc+QS0tqYo8do8LvtpT4AnBOTLqrFFtgdF
	1LqfRyLtpMQ2MNx1cdGC2/6L2oPKMrE5Yuy0zBAsmADhOqib2rhVzsb2w3DYgqGD2Po+
	chU4ZyPLPVFh0YUMKN/7ewTiK6VQpyHD9zl+XimGoz4IEyBK17IOUjVpc7V6+Ineo1NM
	SIP0S9kj8BVS1aKO+AZrQy7Pv2UfjuJAxq32tTRNZXh9OdFi0qPNrVcDfK2Suuno/nj/
	QCCyUZonO6oHDda62sru63TjU+YkZLtr/a6n46RGZhUIt7yEZ6eNrcBRdsbcIygsyTcY
	AHQQ==
Received: by 10.182.177.7 with SMTP id cm7mr13182641obc.17.1347915433289; Mon,
	17 Sep 2012 13:57:13 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.60.138.225 with HTTP; Mon, 17 Sep 2012 13:56:52 -0700 (PDT)
In-Reply-To: <CAAnFQG9bUUU8OBeKxYh=O3rRrnEPb4r1bPCr-EHWHuUS8shBhA@mail.gmail.com>
References: <CAAnFQG9TZj=SxYK_jxqN=M6L40vL=AZu9EM2tbEffPhkL1s8FA@mail.gmail.com>
	<CACJDEmqdqA6CE9SgLL2QCNmQH1dOX0_4OHfJfzes+G6bEkQ7FA@mail.gmail.com>
	<CAAnFQG-8Fkunv6R8+GCLAH4yQCx4-Nn0zN_Ntsf0wsh5yXeihQ@mail.gmail.com>
	<20120917142851.GB14012@phenom.dumpdata.com>
	<CAAnFQG9bUUU8OBeKxYh=O3rRrnEPb4r1bPCr-EHWHuUS8shBhA@mail.gmail.com>
From: Javier Marcet <jmarcet@gmail.com>
Date: Mon, 17 Sep 2012 22:56:52 +0200
Message-ID: <CAAnFQG_VnZOYs3SJvO1Gc8P98kOW=6Wxc7tM_vEF8GiACgeVWg@mail.gmail.com>
To: Konrad Rzeszutek Wilk <konrad@kernel.org>
Cc: Xen Devel Mailing list <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.2.0-rc4 issues with DVB tuner
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Sep 17, 2012 at 10:09 PM, Javier Marcet <jmarcet@gmail.com> wrote:

>>> >> I wonder whether it would work within a DomU with the PCIe tuner
>>> >> passed through.
>>> >
>>> > I've a 4 channel security card passed in and it works nicely. The
>>> > trick is that you need 'iommu=soft' on the domU command line.
>>>
>>> All right. But is it normal that it does not work under the dom0?
>>
>> No. PV domU and PV dom0 are pretty much the same in the way of handling
>> interrupts, ports, etc.
>>
>> If you crank up the debug level of the kernel (debug loglevel=8) and
>> of the driver do you get anything obvious? What about the questions
>> I've asked?
>
> Booting with 'debug loglevel=8' as kernel parameters I still get no errors or
> warnings anywhere.
>
> I'm out of ideas and I don't have any other PCIe tuner card to try.
>
> It is looking more and more as a cx23885 (the module the card uses) issue.
> It is really odd since I you get some data, but just like if there was very
> poor reception, more noise than signal.
>
> If you can think of some other way to debug this, I'll try it.

I've just realized that I have quite a lot of debug options in the dvb
driver. Right
now I have one tuner in use, but when it finishes (or tomorrow) I'll enable some
debug output in the dvb subsystem and the cx23885 module in particular and
see whether I can get some more info.

Even so, if you deem worth checking something else, I'm open to try anything.


-- 
Javier Marcet <jmarcet@gmail.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 17 21:18:52 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 21: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 1TDii4-0000JM-Rk; Mon, 17 Sep 2012 21:18:28 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <matthew.fioravante@jhuapl.edu>) id 1TDii2-0000JH-Hf
	for xen-devel@lists.xensource.com; Mon, 17 Sep 2012 21:18:27 +0000
Received: from [85.158.137.99:19225] by server-2.bemta-3.messagelabs.com id
	F0/D4-04862-1A397505; Mon, 17 Sep 2012 21:18:25 +0000
X-Env-Sender: matthew.fioravante@jhuapl.edu
X-Msg-Ref: server-16.tower-217.messagelabs.com!1347916697!18053812!1
X-Originating-IP: [128.244.251.36]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG,
	UNPARSEABLE_RELAY,UPPERCASE_25_50
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3619 invoked from network); 17 Sep 2012 21:18:19 -0000
Received: from pilot.jhuapl.edu (HELO jhuapl.edu) (128.244.251.36)
	by server-16.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 17 Sep 2012 21:18:19 -0000
Received: from ([128.244.207.89])
	by pilot.jhuapl.edu with ESMTP with TLS id 63GHCH1.153073819;
	Mon, 17 Sep 2012 17:18:06 -0400
Message-ID: <50579343.6020106@jhuapl.edu>
Date: Mon, 17 Sep 2012 17:16:51 -0400
From: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:14.0) Gecko/20120714 Thunderbird/14.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>, 
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
X-Enigmail-Version: 1.5a1pre
Subject: [Xen-devel] [PATCH vtpm_manager 1/2] Updates and bug fixes to
	vtpm_manager
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============7207552152192457387=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a cryptographically signed message in MIME format.

--===============7207552152192457387==
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms030402000007090807080904"

This is a cryptographically signed message in MIME format.

--------------ms030402000007090807080904
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

The following patch contains a major set of bug fixes and feature
enhancements to vtpm_manager.

vtpm_manager was previously riddled with memory leaks, race conditions,
IO deadlocks, and other assorted bugs.

This patch fixes numerous bugs in vtpm manager and also adds new
functionality for supporting vtpm stub domains.=20

It adds a new program (vtpmmgrtalk) that is used by the hotplug script
fixes (next patch) to avoid IO deadlocks with pipes.

Finally, it also breaks the compilation of vtpm_manager into separate
static libraries, which are then used later by the vtpmmgrdom stub domain=
=2E

Signed of by: Matthew Fioravante matthew.fioravante@jhuapl.edu

diff --git a/tools/vtpm_manager/Makefile b/tools/vtpm_manager/Makefile
--- a/tools/vtpm_manager/Makefile
+++ b/tools/vtpm_manager/Makefile
@@ -1,9 +1,9 @@
-XEN_ROOT =3D $(CURDIR)/../..
+XEN_ROOT =3D $(realpath ../..)
=20
 # Base definitions and rules
-include $(XEN_ROOT)/tools/vtpm_manager/Rules.mk
+include Rules.mk
=20
-SUBDIRS        =3D crypto tcs util manager migration
+SUBDIRS        =3D crypto tcs util manager migration vtpmmgrtalk vtpmcon=
nd
 OPENSSL_HEADER    =3D /usr/include/openssl/crypto.h
=20
 .PHONY: all clean install
diff --git a/tools/vtpm_manager/README b/tools/vtpm_manager/README
--- a/tools/vtpm_manager/README
+++ b/tools/vtpm_manager/README
@@ -43,9 +43,6 @@ Compile Flags
 LOGGING_MODULES              -> How extensive logging happens
                                 see util/log.h for more info
=20
-VTPM_MULTI_VM                -> Defined: VTPMs run in their own VMs
-                                Not Defined (default): VTPMs are process=
es
-
 # Debugging flags that may disappear without notice in the future
=20
 DUMMY_BACKEND                -> vtpm_manager listens on /tmp/in.fifo and=

@@ -59,6 +56,10 @@ WELL_KNOWN_OWNER_AUTH        -> Rather than randomly
generating the password for
                                 lost. However this has no protection
from malicious app
                                 issuing a TPM_OwnerClear to wipe the TPM=

=20
+VTPM_STUBDOM             -> vtpm_manager runs in vtpm_stubdom mode with
+                vtpm instances running in mini-os domains
+                (see: stubdom/vtpm/README for details)
+
 Requirements
 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
 - xen-unstable
diff --git a/tools/vtpm_manager/Rules.mk b/tools/vtpm_manager/Rules.mk
--- a/tools/vtpm_manager/Rules.mk
+++ b/tools/vtpm_manager/Rules.mk
@@ -6,7 +6,7 @@ include $(XEN_ROOT)/tools/Rules.mk
 #
=20
 # General compiler flags
-CFLAGS    =3D -Werror -g3
+CFLAGS    =3D -Werror -g3 -I.
=20
 # Generic project files
 HDRS    =3D $(wildcard *.h)
@@ -31,18 +31,18 @@ $(OBJS): $(SRCS)
 CFLAGS +=3D -D_GNU_SOURCE
=20
 # Logging Level. See utils/tools.h for usage
-CFLAGS +=3D
-DLOGGING_MODULES=3D"(BITMASK(VTPM_LOG_TCS)|BITMASK(VTPM_LOG_VTSP)|BITMAS=
K(VTPM_LOG_VTPM))"
+#CFLAGS +=3D
-DLOGGING_MODULES=3D"(BITMASK(VTPM_LOG_TCS)|BITMASK(VTPM_LOG_VTSP)|BITMAS=
K(VTPM_LOG_VTPM))"
=20
 # Silent Mode
 #CFLAGS +=3D -DLOGGING_MODULES=3D0x0
-#CFLAGS +=3D -DLOGGING_MODULES=3D0xff
-
-# Use frontend/backend pairs between manager & DMs?
-#CFLAGS +=3D -DVTPM_MULTI_VM
+CFLAGS +=3D -DLOGGING_MODULES=3D0xff
=20
 # vtpm_manager listens on fifo's rather than backend
 #CFLAGS +=3D -DDUMMY_BACKEND
=20
+# Build for use with vtpm-stubdom
+#CFLAGS +=3D -DVTPM_STUBDOM
+
 # TCS talks to fifo's rather than /dev/tpm. TPM Emulator assumed on fifo=
s
 #CFLAGS +=3D -DDUMMY_TPM
=20
@@ -52,8 +52,3 @@ CFLAGS +=3D
-DLOGGING_MODULES=3D"(BITMASK(VTPM_LOG_TCS)|BITMASK(VTPM_LOG_VTSP)|BITMA
 # Fixed OwnerAuth
 #CFLAGS +=3D -DWELL_KNOWN_OWNER_AUTH
=20
-# Include
-CFLAGS +=3D -I$(XEN_ROOT)/tools/vtpm_manager/crypto
-CFLAGS +=3D -I$(XEN_ROOT)/tools/vtpm_manager/util
-CFLAGS +=3D -I$(XEN_ROOT)/tools/vtpm_manager/tcs
-CFLAGS +=3D -I$(XEN_ROOT)/tools/vtpm_manager/manager
diff --git a/tools/vtpm_manager/crypto/Makefile
b/tools/vtpm_manager/crypto/Makefile
--- a/tools/vtpm_manager/crypto/Makefile
+++ b/tools/vtpm_manager/crypto/Makefile
@@ -1,5 +1,9 @@
-XEN_ROOT =3D $(CURDIR)/../../..
-include $(XEN_ROOT)/tools/vtpm_manager/Rules.mk
+XEN_ROOT =3D $(realpath ../../..)
+include ../Rules.mk
+
+CFLAGS +=3D -I../util
+CFLAGS +=3D -I../tcs
+CFLAGS +=3D -I../manager
=20
 BIN        =3D libtcpaCrypto.a
=20
diff --git a/tools/vtpm_manager/crypto/crypto.c
b/tools/vtpm_manager/crypto/crypto.c
--- a/tools/vtpm_manager/crypto/crypto.c
+++ b/tools/vtpm_manager/crypto/crypto.c
@@ -45,6 +45,8 @@
 #include "crypto.h"
 #include "log.h"
=20
+extern const EVP_CIPHER * SYM_CIPHER;
+
 /**
  * Initialize cryptography library
  * @rand: random seed
@@ -83,6 +85,6 @@ void Crypto_GetRandom(void* data, int size) {
   result =3D RAND_pseudo_bytes((BYTE*) data, size);
 =20
   if (result <=3D 0)
-    vtpmlogerror (VTPM_LOG_CRYPTO, "RAND_pseudo_bytes failed: %s\n",
-         ERR_error_string (ERR_get_error(), NULL));
+    vtpmlogerror (VTPM_LOG_CRYPTO, "RAND_pseudo_bytes failed: rc=3D%d
errstr=3D%s\n",
+      result, ERR_error_string (ERR_get_error(), NULL));
 }
diff --git a/tools/vtpm_manager/crypto/crypto.h
b/tools/vtpm_manager/crypto/crypto.h
--- a/tools/vtpm_manager/crypto/crypto.h
+++ b/tools/vtpm_manager/crypto/crypto.h
@@ -76,7 +76,7 @@ typedef struct CRYPTO_INFO {
=20
 void Crypto_Init(const BYTE* rand, int size);
=20
-void Crypto_Exit();
+void Crypto_Exit(void);
=20
 void Crypto_GetRandom(void* data, int size);
=20
@@ -127,6 +127,8 @@ void Crypto_RSABuildCryptoInfoPublic(   /*[IN]*/
UINT32 pubExpSize,
                                         /*[IN]*/ BYTE *modulus,
                                         CRYPTO_INFO* cryptoInfo);
=20
+void Crypto_RSACryptoInfoFree(CRYPTO_INFO* cryptoInfo);
+
 //
 // symmetric pack and unpack operations
 //
diff --git a/tools/vtpm_manager/crypto/rsa.c
b/tools/vtpm_manager/crypto/rsa.c
--- a/tools/vtpm_manager/crypto/rsa.c
+++ b/tools/vtpm_manager/crypto/rsa.c
@@ -149,6 +149,10 @@ void Crypto_RSABuildCryptoInfoPublic(   /*[IN]*/
UINT32 pubExpSize,
 =20
 }
=20
+void Crypto_RSACryptoInfoFree(CRYPTO_INFO* cryptoInfo) {
+   RSA_free(cryptoInfo->keyInfo);
+}
+
 int Crypto_RSAEnc(  CRYPTO_INFO *key,
             UINT32 inDataSize,
             BYTE *inData,
@@ -161,6 +165,7 @@ int Crypto_RSAEnc(  CRYPTO_INFO *key,
   =20
   if (paddedData =3D=3D NULL)
     return -1;
+  memset(paddedData, 0, sizeof(BYTE) * paddedDataSize);
=20
   *outDataSize =3D 0;
 =20
diff --git a/tools/vtpm_manager/crypto/sym_crypto.c
b/tools/vtpm_manager/crypto/sym_crypto.c
--- a/tools/vtpm_manager/crypto/sym_crypto.c
+++ b/tools/vtpm_manager/crypto/sym_crypto.c
@@ -41,8 +41,16 @@
 #include <openssl/rand.h>
=20
 #include "tcg.h"
+#include "log.h"
 #include "sym_crypto.h"
=20
+struct symkey_t {
+  buffer_t key;
+
+  EVP_CIPHER_CTX context;
+  const EVP_CIPHER * cipher;
+};
+
 typedef enum crypt_op_type_t {
   CRYPT_ENCRYPT,
   CRYPT_DECRYPT
@@ -61,19 +69,22 @@ const EVP_CIPHER * SYM_CIPHER =3D NULL;
 const BYTE ZERO_IV[EVP_MAX_IV_LENGTH] =3D {0};
=20
=20
-TPM_RESULT Crypto_symcrypto_initkey (symkey_t * key, const buffer_t*
keybits) {
+TPM_RESULT Crypto_symcrypto_initkey (symkey_t ** key, const buffer_t*
keybits) {
   TPM_RESULT status =3D TPM_SUCCESS;
 =20
-  EVP_CIPHER_CTX_init (&key->context);
+  *key =3D malloc(sizeof(symkey_t));
+
+  EVP_CIPHER_CTX_init (&(*key)->context);
 =20
-  key->cipher =3D SYM_CIPHER;
+  (*key)->cipher =3D SYM_CIPHER;
 =20
-  TPMTRYRETURN( buffer_init_copy (&key->key, keybits));
+  TPMTRYRETURN( buffer_init_copy (&(*key)->key, keybits));
   =20
   goto egress;
 =20
  abort_egress:
-  EVP_CIPHER_CTX_cleanup (&key->context);
+  EVP_CIPHER_CTX_cleanup (&(*key)->context);
+  free(key);
 =20
  egress:
 =20
@@ -82,19 +93,21 @@ TPM_RESULT Crypto_symcrypto_initkey (symkey_t * key,
const buffer_t* keybits) {
=20
=20
=20
-TPM_RESULT Crypto_symcrypto_genkey (symkey_t * key) {
+TPM_RESULT Crypto_symcrypto_genkey (symkey_t ** key) {
   int res;
   TPM_RESULT status =3D TPM_SUCCESS;
+
+  *key =3D malloc(sizeof(symkey_t));
 =20
   // hmm, EVP_CIPHER_CTX_init does not return a value
-  EVP_CIPHER_CTX_init (&key->context);
+  EVP_CIPHER_CTX_init (&(*key)->context);
 =20
-  key->cipher =3D SYM_CIPHER;
+  (*key)->cipher =3D SYM_CIPHER;
 =20
-  TPMTRYRETURN( buffer_init (&key->key,
EVP_CIPHER_key_length(key->cipher), NULL)) ;
+  TPMTRYRETURN( buffer_init (&(*key)->key,
EVP_CIPHER_key_length((*key)->cipher), NULL)) ;
 =20
   // and generate the key material
-  res =3D RAND_pseudo_bytes (key->key.bytes, key->key.size);
+  res =3D RAND_pseudo_bytes ((*key)->key.bytes, (*key)->key.size);
   if (res < 0)
     ERRORDIE (TPM_SHORTRANDOM);
 =20
@@ -102,8 +115,9 @@ TPM_RESULT Crypto_symcrypto_genkey (symkey_t * key) {=

   goto egress;
 =20
  abort_egress:
-  EVP_CIPHER_CTX_cleanup (&key->context);
-  buffer_free (&key->key);
+  EVP_CIPHER_CTX_cleanup (&(*key)->context);
+  buffer_free (&(*key)->key);
+  free(key);
 =20
  egress:
   return status;=20
@@ -119,11 +133,11 @@ TPM_RESULT Crypto_symcrypto_encrypt (symkey_t* key,=

 =20
   buffer_init_const (&iv, EVP_MAX_IV_LENGTH, ZERO_IV);
 =20
-  buffer_init (o_cipher,
-           clear->size +
-           EVP_CIPHER_iv_length(key->cipher) +
-           EVP_CIPHER_block_size (key->cipher),
-                 0);
+  TPMTRYRETURN( buffer_init (o_cipher,
+                  clear->size +
+                  EVP_CIPHER_iv_length(key->cipher) +
+                  EVP_CIPHER_block_size (key->cipher),
+                 0) );
 =20
   // copy the IV into the front
   buffer_copy (o_cipher, &iv);
@@ -139,6 +153,7 @@ TPM_RESULT Crypto_symcrypto_encrypt (symkey_t* key,
   goto egress;
 =20
  abort_egress:
+  buffer_free(o_cipher);
 =20
  egress:
 =20
@@ -170,7 +185,7 @@ TPM_RESULT Crypto_symcrypto_decrypt (symkey_t* key,
 =20
   // and decrypt
   TPMTRYRETURN ( ossl_symcrypto_op (key, &cipher_alias, &iv, o_clear,
CRYPT_DECRYPT) );
-=20
+
   goto egress;
 =20
  abort_egress:
@@ -188,6 +203,8 @@ TPM_RESULT Crypto_symcrypto_freekey (symkey_t * key) =
{
   buffer_free (&key->key);
 =20
   EVP_CIPHER_CTX_cleanup (&key->context);
+
+  free(key);
 =20
   return TPM_SUCCESS;
 }
@@ -235,3 +252,8 @@ TPM_RESULT ossl_symcrypto_op (symkey_t* key,
 =20
   return status;
 }
+
+buffer_t* Crypto_symkey_getkey(symkey_t* key)
+{
+   return &key->key;
+}
diff --git a/tools/vtpm_manager/crypto/sym_crypto.h
b/tools/vtpm_manager/crypto/sym_crypto.h
--- a/tools/vtpm_manager/crypto/sym_crypto.h
+++ b/tools/vtpm_manager/crypto/sym_crypto.h
@@ -40,21 +40,15 @@
 #ifndef _SYM_CRYPTO_H
 #define _SYM_CRYPTO_H
=20
-#include <openssl/evp.h>
 #include "buffer.h"
=20
-typedef struct symkey_t {
-  buffer_t key;
-=20
-  EVP_CIPHER_CTX context;
-  const EVP_CIPHER * cipher;
-} symkey_t;
+typedef struct symkey_t symkey_t;
=20
-extern const EVP_CIPHER * SYM_CIPHER;
+//Allocates a symkey with random bits
+TPM_RESULT Crypto_symcrypto_genkey (symkey_t ** key);
=20
-TPM_RESULT Crypto_symcrypto_genkey (symkey_t * key);
-
-TPM_RESULT Crypto_symcrypto_initkey (symkey_t * key, const buffer_t*
keybits);
+//Allocates a symkey with given keybits
+TPM_RESULT Crypto_symcrypto_initkey (symkey_t ** key, const buffer_t*
keybits);
=20
=20
 // these functions will allocate their output buffers
@@ -66,7 +60,10 @@ TPM_RESULT Crypto_symcrypto_decrypt (symkey_t* key,
                               const buffer_t* cipher,
                               buffer_t* o_clear);
=20
-// only free the internal parts, not the 'key' ptr
+//Frees the symkey
 TPM_RESULT Crypto_symcrypto_freekey (symkey_t * key);
=20
+//Get the raw key byte buffer
+buffer_t* Crypto_symkey_getkey(symkey_t* key);
+
 #endif /* _SYM_CRYPTO_H */
diff --git a/tools/vtpm_manager/manager/Makefile
b/tools/vtpm_manager/manager/Makefile
--- a/tools/vtpm_manager/manager/Makefile
+++ b/tools/vtpm_manager/manager/Makefile
@@ -1,7 +1,18 @@
-XEN_ROOT =3D $(CURDIR)/../../..
-include $(XEN_ROOT)/tools/vtpm_manager/Rules.mk
+XEN_ROOT =3D $(realpath ../../..)
+include ../Rules.mk
+
+CFLAGS +=3D -I../crypto
+CFLAGS +=3D -I../util
+CFLAGS +=3D -I../tcs
+
+
+MAINS         :=3D vtpmd.o
+MGRLIB         :=3D libvtpmmanager.a
+VTSPOBJS    :=3D vtsp.o
+VTSPLIB        :=3D libvtsp.a
+BIN        :=3D vtpm_managerd
+OBJS         :=3D $(filter-out $(MAINS) $(VTSPOBJS), $(OBJS))
=20
-BIN        =3D vtpm_managerd
=20
 .PHONY: all
 all: build
@@ -28,8 +39,14 @@ clean:
 mrproper: clean
     rm -f *~
=20
-$(BIN): $(OBJS)
-    $(CC) $(LDFLAGS) $^ $(LIBS) -o $@
+$(BIN): $(MAINS) $(MGRLIB) $(VTSPLIB)
+    $(CC) $(CFLAGS) $(LDFLAGS) $^ $(LIBS) -o $@
+
+$(VTSPLIB): $(VTSPOBJS)
+    $(AR) rcs $@ $^
+
+$(MGRLIB): $(OBJS)
+    $(AR) rcs $@ $^
=20
 # libraries
 LIBS +=3D ../tcs/libTCS.a ../util/libTCGUtils.a ../crypto/libtcpaCrypto.=
a
diff --git a/tools/vtpm_manager/manager/dmictl.c
b/tools/vtpm_manager/manager/dmictl.c
--- a/tools/vtpm_manager/manager/dmictl.c
+++ b/tools/vtpm_manager/manager/dmictl.c
@@ -40,6 +40,9 @@
 #include <stdio.h>
 #include <unistd.h>
 #include <string.h>
+#include <fcntl.h>
+#include <inttypes.h>
+#include <stdlib.h>
=20
 #include "vtpmpriv.h"
 #include "bsg.h"
@@ -51,6 +54,13 @@
=20
 #define TPM_EMULATOR_PATH "/usr/bin/vtpmd"
=20
+#ifndef VTPM_STUBDOM
+// This is needed to all extra_close_dmi to close this to prevent a
+// broken pipe when no DMIs are left.
+vtpm_ipc_handle_t *g_rx_tpm_ipc_h;
+#endif
+
+
 // if dmi_res is non-null, then return a pointer to new object.
 // Also, this does not fill in the measurements. They should be filled b=
y
 // design dependent code or saveNVM
@@ -81,7 +91,7 @@ TPM_RESULT init_dmi(UINT32 dmi_id, BYTE dmi_type,
VTPM_DMI_RESOURCE **dmi_res) {
=20
   // install into map
   if (!hashtable_insert(vtpm_globals->dmi_map, dmi_id_key, new_dmi)){
-    vtpmlogerror(VTPM_LOG_VTPM, "Failed to insert instance into table.
Aborting.\n", dmi_id);
+    vtpmlogerror(VTPM_LOG_VTPM, "Failed to insert instance %" PRIu32
"into table. Aborting.\n", dmi_id);
     status =3D TPM_FAIL;
     goto abort_egress;
   }
@@ -116,6 +126,161 @@ TPM_RESULT close_dmi(VTPM_DMI_RESOURCE *dmi_res) {
=20
   return (VTPM_Close_DMI_Extra(dmi_res) );
 }
+
+void free_dmi(VTPM_DMI_RESOURCE *dmi_res) {
+   if(dmi_res !=3D NULL) {
+      free(dmi_res->NVMLocation);
+   }
+   free(dmi_res);
+}
+
+TPM_RESULT VTPM_New_DMI_Extra(VTPM_DMI_RESOURCE *dmi_res, BYTE vm_type,
BYTE startup_mode) {
+
+  TPM_RESULT status =3D TPM_SUCCESS;
+#ifndef VTPM_STUBDOM
+  int fh;
+  char dmi_id_str[11]; // UINT32s are up to 10 digits + NULL
+  char *tx_vtpm_name, *tx_tpm_name, *vm_type_string;
+  struct stat file_info;
+
+  if (dmi_res->dmi_id =3D=3D VTPM_CTL_DM) {
+    dmi_res->tx_tpm_ipc_h =3D NULL;
+    dmi_res->rx_tpm_ipc_h =3D NULL;
+    dmi_res->tx_vtpm_ipc_h =3D NULL;
+    dmi_res->rx_vtpm_ipc_h =3D NULL;
+  } else {
+    // Create a pair of fifo pipes
+    dmi_res->rx_tpm_ipc_h =3D NULL;
+    dmi_res->rx_vtpm_ipc_h =3D NULL;
+
+    if ( ((dmi_res->tx_tpm_ipc_h =3D (vtpm_ipc_handle_t *) malloc
(sizeof(vtpm_ipc_handle_t))) =3D=3D NULL ) ||
+         ((dmi_res->tx_vtpm_ipc_h =3D(vtpm_ipc_handle_t *) malloc
(sizeof(vtpm_ipc_handle_t))) =3D=3D NULL ) ||
+         ((tx_tpm_name =3D (char *) malloc(11 +
strlen(VTPM_TX_TPM_FNAME))) =3D=3D NULL ) ||
+         ((tx_vtpm_name =3D(char *) malloc(11 +
strlen(VTPM_TX_VTPM_FNAME))) =3D=3D NULL) ) {
+      status =3DTPM_RESOURCES;
+      goto abort_egress;
+    }
+
+    sprintf(tx_tpm_name, VTPM_TX_TPM_FNAME, (uint32_t) dmi_res->dmi_id);=

+    sprintf(tx_vtpm_name, VTPM_TX_VTPM_FNAME, (uint32_t) dmi_res->dmi_id=
);
+
+    if ( (vtpm_ipc_init(dmi_res->tx_tpm_ipc_h, tx_tpm_name, O_WRONLY |
O_NONBLOCK, TRUE, FALSE) !=3D 0) ||
+         (vtpm_ipc_init(dmi_res->tx_vtpm_ipc_h, tx_vtpm_name, O_WRONLY,
TRUE, FALSE) !=3D 0) ) { //FIXME: O_NONBLOCK?
+      status =3D TPM_IOERROR;
+      goto abort_egress;
+    }
+
+    // Measure DMI
+    // FIXME: This will measure DMI. Until then use a fixed
DMI_Measurement value
+    // Also, this mechanism is specific to 1 VM architecture.
+    /*
+    fh =3D open(TPM_EMULATOR_PATH, O_RDONLY);
+    stat_ret =3D fstat(fh, &file_stat);
+    if (stat_ret =3D=3D 0)
+      dmi_size =3D file_stat.st_size;
+    else {
+      vtpmlogerror(VTPM_LOG_VTPM, "Could not open vtpmd!!\n");
+      status =3D TPM_IOERROR;
+      goto abort_egress;
+    }
+    dmi_buffer
+    */
+    memset(&dmi_res->DMI_measurement, 0xcc, sizeof(TPM_DIGEST));
+
+    if (vm_type =3D=3D VTPM_TYPE_PVM)
+      vm_type_string =3D (BYTE *)&VTPM_TYPE_PVM_STRING;
+    else
+      vm_type_string =3D (BYTE *)&VTPM_TYPE_HVM_STRING;
+
+    // Launch DMI
+    sprintf(dmi_id_str, "%d", (int) dmi_res->dmi_id);
+#ifdef MANUAL_DM_LAUNCH
+    vtpmlogerror(VTPM_LOG_VTPM, "Manually start VTPM with dmi=3D%s
now.\n", dmi_id_str);
+    dmi_res->dmi_pid =3D 0;
+#else
+    pid_t pid =3D fork();
+
+    if (pid =3D=3D -1) {
+      vtpmlogerror(VTPM_LOG_VTPM, "Could not fork to launch vtpm\n");
+      status =3D TPM_RESOURCES;
+      goto abort_egress;
+    } else if (pid =3D=3D 0) {
+      switch (startup_mode) {
+      case TPM_ST_CLEAR:
+        execl (TPM_EMULATOR_PATH, "vtpmd", "clear", vm_type_string,
dmi_id_str, NULL);
+        break;
+      case TPM_ST_STATE:
+        execl (TPM_EMULATOR_PATH, "vtpmd", "save", vm_type_string,
dmi_id_str, NULL);
+        break;
+      case TPM_ST_DEACTIVATED:
+        execl (TPM_EMULATOR_PATH, "vtpmd", "deactivated",
vm_type_string, dmi_id_str, NULL);
+        break;
+      default:
+        status =3D TPM_BAD_PARAMETER;
+        goto abort_egress;
+      }
+
+      // Returning from these at all is an error.
+      vtpmlogerror(VTPM_LOG_VTPM, "Could not exec to launch vtpm\n");
+    } else {
+      dmi_res->dmi_pid =3D pid;
+      vtpmloginfo(VTPM_LOG_VTPM, "Launching DMI on PID =3D %d\n", pid);
+    }
+#endif // MANUAL_DM_LAUNCH
+
+  } // If DMI =3D VTPM_CTL_DM
+    status =3D TPM_SUCCESS;
+#endif
+
+abort_egress:
+    //FIXME: Everything should be freed here
+  return (status);
+}
+
+TPM_RESULT VTPM_Close_DMI_Extra(VTPM_DMI_RESOURCE *dmi_res) {
+  TPM_RESULT status =3D TPM_SUCCESS;
+
+#ifndef VTPM_STUBDOM
+  if (vtpm_globals->connected_dmis =3D=3D 0) {
+    // No more DMI's connected. Close fifo to prevent a broken pipe.
+    // This is hackish. Need to think of another way.
+    vtpm_ipc_close(g_rx_tpm_ipc_h);
+  }
+
+
+  if (dmi_res->dmi_id !=3D VTPM_CTL_DM) {
+    vtpm_ipc_close(dmi_res->tx_tpm_ipc_h);
+    vtpm_ipc_close(dmi_res->tx_vtpm_ipc_h);
+
+    free(dmi_res->tx_tpm_ipc_h->name);
+    free(dmi_res->tx_vtpm_ipc_h->name);
+    free(dmi_res->tx_tpm_ipc_h);
+    free(dmi_res->tx_vtpm_ipc_h);
+
+#ifndef MANUAL_DM_LAUNCH
+    if (dmi_res->dmi_id !=3D VTPM_CTL_DM) {
+      if (dmi_res->dmi_pid !=3D 0) {
+        vtpmloginfo(VTPM_LOG_VTPM, "Killing dmi on pid %d.\n",
dmi_res->dmi_pid);
+        if (kill(dmi_res->dmi_pid, SIGKILL) !=3D0) {
+          vtpmloginfo(VTPM_LOG_VTPM, "DMI on pid %d is already
dead.\n", dmi_res->dmi_pid);
+        } else if (waitpid(dmi_res->dmi_pid, NULL, 0) !=3D
dmi_res->dmi_pid) {
+          vtpmlogerror(VTPM_LOG_VTPM, "DMI on pid %d failed to
stop.\n", dmi_res->dmi_pid);
+          status =3D TPM_FAIL;
+        }
+      } else {
+        vtpmlogerror(VTPM_LOG_VTPM, "Could not kill dmi because it's
pid was 0.\n");
+        status =3D TPM_FAIL;
+      }
+    }
+#endif
+
+  } //endif ! dom0
+#endif
+  return status;
+}
+
+
+
   =20
 TPM_RESULT VTPM_Handle_New_DMI(const buffer_t *param_buf) {
 =20
@@ -254,7 +419,7 @@ TPM_RESULT VTPM_Handle_Delete_DMI( const buffer_t
*param_buf) {
 =20
   // Close DMI first
   TPMTRYRETURN(close_dmi( dmi_res ));
-  free ( dmi_res );
+  free_dmi(dmi_res);
   =20
   status=3DTPM_SUCCESS;  =20
   goto egress;
diff --git a/tools/vtpm_manager/manager/migration.c
b/tools/vtpm_manager/manager/migration.c
--- a/tools/vtpm_manager/manager/migration.c
+++ b/tools/vtpm_manager/manager/migration.c
@@ -40,6 +40,7 @@
 #include <stdio.h>
 #include <unistd.h>
 #include <string.h>
+#include <stdlib.h>
=20
 #include "vtpmpriv.h"
 #include "bsg.h"
@@ -263,7 +264,7 @@ TPM_RESULT VTPM_Handle_Get_Migration_key( const
buffer_t *param_buf,
 TPM_RESULT VTPM_Handle_Load_Migration_key( const buffer_t *param_buf,
                                            buffer_t *result_buf) {
=20
-  TPM_RESULT status=3DTPM_FAIL;
+  TPM_RESULT status=3DTPM_SUCCESS;
   VTPM_MIGKEY_LIST *mig_key;
=20
   vtpmloginfo(VTPM_LOG_VTPM, "Loading Migration Public Key.\n");
@@ -303,5 +304,5 @@ TPM_RESULT VTPM_Handle_Load_Migration_key( const
buffer_t *param_buf,
   free(pubkey_exp_pack.data);
   free(pubkey_mod_pack.data);
=20
-  return TPM_SUCCESS;
+  return status;
 }
diff --git a/tools/vtpm_manager/manager/securestorage.c
b/tools/vtpm_manager/manager/securestorage.c
--- a/tools/vtpm_manager/manager/securestorage.c
+++ b/tools/vtpm_manager/manager/securestorage.c
@@ -42,7 +42,7 @@
 #include <fcntl.h>
 #include <unistd.h>
 #include <string.h>
-
+#include <stdlib.h>
 #include "tcg.h"
 #include "vtpm_manager.h"
 #include "vtpmpriv.h"
@@ -58,7 +58,7 @@ TPM_RESULT envelope_encrypt(const buffer_t     *inbuf,
                             CRYPTO_INFO        *asymkey,
                             buffer_t           *sealed_data) {
   TPM_RESULT status =3D TPM_SUCCESS;
-  symkey_t    symkey;
+  symkey_t    *symkey;
   buffer_t    data_cipher =3D NULL_BUF,
               symkey_cipher =3D NULL_BUF;
 =20
@@ -69,14 +69,14 @@ TPM_RESULT envelope_encrypt(const buffer_t     *inbuf=
,
   for (i=3D0; i< buffer_len(inbuf); i++)
     vtpmloginfomore(VTPM_LOG_VTPM_DEEP, "%x ", inbuf->bytes[i]);
   vtpmloginfomore(VTPM_LOG_VTPM_DEEP, "\n");
-=20
+
   // Generate a sym key and encrypt state with it
   TPMTRY(TPM_ENCRYPT_ERROR, Crypto_symcrypto_genkey (&symkey) );
-  TPMTRY(TPM_ENCRYPT_ERROR, Crypto_symcrypto_encrypt (&symkey, inbuf,
&data_cipher) );
+  TPMTRY(TPM_ENCRYPT_ERROR, Crypto_symcrypto_encrypt (symkey, inbuf,
&data_cipher) );
 =20
   // Encrypt symmetric key
   TPMTRYRETURN( VTSP_Bind(    asymkey,
-                  &symkey.key,
+                  Crypto_symkey_getkey(symkey),
                   &symkey_cipher) );
 =20
   // Create output blob: symkey_size + symkey_cipher +
state_cipher_size + state_cipher
@@ -86,8 +86,9 @@ TPM_RESULT envelope_encrypt(const buffer_t     *inbuf,
 =20
   data_cipher32.size =3D buffer_len(&data_cipher);
   data_cipher32.data =3D data_cipher.bytes;
-=20
+
   TPMTRYRETURN( buffer_init(sealed_data, 2 * sizeof(UINT32) +
symkey_cipher32.size + data_cipher32.size, NULL));
+  memset(sealed_data->bytes, 0, sealed_data->size);
 =20
   BSG_PackList(sealed_data->bytes, 2,
            BSG_TPM_SIZE32_DATA, &symkey_cipher32,
@@ -109,11 +110,37 @@ TPM_RESULT envelope_encrypt(const buffer_t     *inb=
uf,
 =20
   buffer_free ( &data_cipher);
   buffer_free ( &symkey_cipher);
-  Crypto_symcrypto_freekey (&symkey);
+  Crypto_symcrypto_freekey (symkey);
 =20
   return status;
 }
=20
+TPM_RESULT symkey_encrypt(const buffer_t     *inbuf,
+                            CRYPTO_INFO        *asymkey,
+                            buffer_t           *sealed_key) {
+  buffer_t symkey_cipher =3D NULL_BUF;
+  struct pack_constbuf_t symkey_cipher32;
+  TPM_RESULT status =3D TPM_SUCCESS;
+
+  // Encrypt symmetric key
+  TPMTRYRETURN( VTSP_Bind(    asymkey,
+                  inbuf,
+                  &symkey_cipher));
+
+  symkey_cipher32.size =3D buffer_len(&symkey_cipher);
+  symkey_cipher32.data =3D symkey_cipher.bytes;
+
+  TPMTRYRETURN( buffer_init(sealed_key, sizeof(UINT32) +
symkey_cipher32.size, NULL));
+  BSG_PackList(sealed_key->bytes, 1,
+           BSG_TPM_SIZE32_DATA, &symkey_cipher32);
+  goto egress;
+abort_egress:
+egress:
+  buffer_free( &symkey_cipher);
+  return status;
+}
+=20
+
 TPM_RESULT envelope_decrypt(const buffer_t     *cipher,
                             TCS_CONTEXT_HANDLE TCSContext,
                 TPM_HANDLE         keyHandle,
@@ -121,15 +148,13 @@ TPM_RESULT envelope_decrypt(const buffer_t   =20
*cipher,
                             buffer_t           *unsealed_data) {
=20
   TPM_RESULT status =3D TPM_SUCCESS;
-  symkey_t    symkey;
+  symkey_t    *symkey;
   buffer_t    data_cipher =3D NULL_BUF,
               symkey_clear =3D NULL_BUF,
               symkey_cipher =3D NULL_BUF;
-  struct pack_buf_t symkey_cipher32, data_cipher32;
+  struct pack_buf_t symkey_cipher32 =3D NULL_PACK_BUF, data_cipher32 =3D=

NULL_PACK_BUF;
   int i;
=20
-  memset(&symkey, 0, sizeof(symkey_t));
-
   vtpmloginfo(VTPM_LOG_VTPM_DEEP, "Envelope Decrypt Input[%d]: 0x",
buffer_len(cipher) );
   for (i=3D0; i< buffer_len(cipher); i++)
     vtpmloginfomore(VTPM_LOG_VTPM_DEEP, "%x ", cipher->bytes[i]);
@@ -159,7 +184,7 @@ TPM_RESULT envelope_decrypt(const buffer_t     *ciphe=
r,
   Crypto_symcrypto_initkey (&symkey, &symkey_clear);
 =20
   // Decrypt State
-  TPMTRY(TPM_DECRYPT_ERROR, Crypto_symcrypto_decrypt (&symkey,
&data_cipher, unsealed_data) );
+  TPMTRY(TPM_DECRYPT_ERROR, Crypto_symcrypto_decrypt (symkey,
&data_cipher, unsealed_data) );
=20
   vtpmloginfo(VTPM_LOG_VTPM_DEEP, "Envelope Decrypte Output[%d]: 0x",
buffer_len(unsealed_data));
   for (i=3D0; i< buffer_len(unsealed_data); i++)
@@ -175,26 +200,64 @@ TPM_RESULT envelope_decrypt(const buffer_t   =20
*cipher,
   buffer_free ( &data_cipher);
   buffer_free ( &symkey_clear);
   buffer_free ( &symkey_cipher);
-  Crypto_symcrypto_freekey (&symkey);
+  BSG_Destroy(BSG_TPM_SIZE32_DATA, &symkey_cipher32);
+  BSG_Destroy(BSG_TPM_SIZE32_DATA, &data_cipher32);
+  Crypto_symcrypto_freekey (symkey);
+
 =20
   return status;
 }
=20
+TPM_RESULT symkey_decrypt(const buffer_t     *cipher,
+                            TCS_CONTEXT_HANDLE TCSContext,
+                TPM_HANDLE         keyHandle,
+                const TPM_AUTHDATA *key_usage_auth,
+                            buffer_t           *symkey_clear) {
+
+  TPM_RESULT status =3D TPM_SUCCESS;
+  buffer_t    symkey_cipher =3D NULL_BUF;
+  struct pack_buf_t symkey_cipher32 =3D NULL_PACK_BUF;
+
+  BSG_UnpackList(cipher->bytes, 1,
+         BSG_TPM_SIZE32_DATA, &symkey_cipher32);
+=20
+  TPMTRYRETURN( buffer_init_alias_convert (&symkey_cipher,
+                           symkey_cipher32.size,
+                           symkey_cipher32.data) );
+=20
+  // Decrypt Symmetric Key
+  TPMTRYRETURN( VTSP_Unbind(  TCSContext,
+                  keyHandle,
+                  &symkey_cipher,
+                  key_usage_auth,
+                  symkey_clear,
+                  &(vtpm_globals->keyAuth) ) );
+=20
+  goto egress;
+ abort_egress:
+  vtpmlogerror(VTPM_LOG_VTPM, "Failed to decrypt symmetric key
status=3D%d\n.", status);
+=20
+ egress:
+  BSG_Destroy(BSG_TPM_SIZE32_DATA, &symkey_cipher32);
+  return status;
+}
+
 TPM_RESULT VTPM_Handle_Save_NVM(VTPM_DMI_RESOURCE *myDMI,
                 const buffer_t *inbuf,
                 buffer_t *outbuf) {
 =20
   TPM_RESULT status =3D TPM_SUCCESS;
-  int fh;
+  int fh =3D -1;
   long bytes_written;
   buffer_t sealed_NVM =3D NULL_BUF;
-=20
-  vtpmloginfo(VTPM_LOG_VTPM_DEEP, "Saving %d bytes of NVM.\n",
buffer_len(inbuf));
+  const buffer_t* nvmbuf =3D inbuf;
+
+  vtpmloginfo(VTPM_LOG_VTPM_DEEP, "Saving %d bytes of NVM.\n",
buffer_len(nvmbuf));
=20
-  TPMTRYRETURN( envelope_encrypt(inbuf,
+  TPMTRYRETURN( envelope_encrypt(nvmbuf,
                                  &vtpm_globals->storageKey,
                                  &sealed_NVM) );
-                =20
+
   // Write sealed blob off disk from NVMLocation
   // TODO: How to properly return from these. Do we care if we return
failure
   //       after writing the file? We can't get the old one back.
@@ -205,7 +268,6 @@ TPM_RESULT VTPM_Handle_Save_NVM(VTPM_DMI_RESOURCE
*myDMI,
     status =3D TPM_IOERROR;
     goto abort_egress;
   }
-  close(fh);
 =20
   Crypto_SHA1Full (sealed_NVM.bytes, buffer_len(&sealed_NVM), (BYTE *)
&myDMI->NVM_measurement); =20
 =20
@@ -215,6 +277,7 @@ TPM_RESULT VTPM_Handle_Save_NVM(VTPM_DMI_RESOURCE
*myDMI,
   vtpmlogerror(VTPM_LOG_VTPM, "Failed to save NVM\n.");
 =20
  egress:
+  close(fh);
   buffer_free(&sealed_NVM);
   return status;
 }
@@ -229,7 +292,8 @@ TPM_RESULT VTPM_Handle_Load_NVM(VTPM_DMI_RESOURCE
*myDMI,
=20
   buffer_t sealed_NVM =3D NULL_BUF;
   long fh_size;
-  int fh, stat_ret, i;
+  int fh =3D -1;
+  int stat_ret, i;
   struct stat file_stat;
   TPM_DIGEST sealedNVMHash;
  =20
@@ -241,6 +305,7 @@ TPM_RESULT VTPM_Handle_Load_NVM(VTPM_DMI_RESOURCE
*myDMI,
 =20
   //Read sealed blob off disk from NVMLocation
   fh =3D open(myDMI->NVMLocation, O_RDONLY);
+  printf("Filename: %s\n", myDMI->NVMLocation);
   stat_ret =3D fstat(fh, &file_stat);
   if (stat_ret =3D=3D 0)
     fh_size =3D file_stat.st_size;
@@ -254,7 +319,6 @@ TPM_RESULT VTPM_Handle_Load_NVM(VTPM_DMI_RESOURCE
*myDMI,
     status =3D TPM_IOERROR;
     goto abort_egress;
   }
-  close(fh);
 =20
   vtpmloginfo(VTPM_LOG_VTPM_DEEP, "Load_NVMing[%d],\n",
buffer_len(&sealed_NVM));
 =20
@@ -289,14 +353,128 @@ TPM_RESULT VTPM_Handle_Load_NVM(VTPM_DMI_RESOURCE
*myDMI,
 =20
  egress:
   buffer_free( &sealed_NVM );
+  close(fh);
+=20
+  return status;
+}
+
+TPM_RESULT VTPM_Handle_Load_HashKey(VTPM_DMI_RESOURCE *myDMI,
+                const buffer_t    *inbuf,
+                buffer_t          *outbuf) {
+=20
+  TPM_RESULT status =3D TPM_SUCCESS;
+
+  buffer_t sealed_NVM =3D NULL_BUF;
+  long fh_size;
+  int fh =3D -1;
+  int stat_ret, i;
+  struct stat file_stat;
+  TPM_DIGEST sealedNVMHash;
+ =20
+  if (myDMI->NVMLocation =3D=3D NULL) {
+    vtpmlogerror(VTPM_LOG_VTPM, "Unable to load NVM because the file
name NULL.\n");
+    status =3D TPM_AUTHFAIL;
+    goto abort_egress;
+  }
+=20
+  //Read sealed blob off disk from NVMLocation
+  fh =3D open(myDMI->NVMLocation, O_RDONLY);
+  printf("Filename: %s\n", myDMI->NVMLocation);
+  stat_ret =3D fstat(fh, &file_stat);
+  if (stat_ret =3D=3D 0)
+    fh_size =3D file_stat.st_size;
+  else {
+    status =3D TPM_IOERROR;
+    goto abort_egress;
+  }
+=20
+  TPMTRYRETURN( buffer_init( &sealed_NVM, fh_size, NULL) );
+  if (read(fh, sealed_NVM.bytes, buffer_len(&sealed_NVM)) !=3D fh_size) =
{
+    status =3D TPM_IOERROR;
+    goto abort_egress;
+  }
+=20
+  vtpmloginfo(VTPM_LOG_VTPM_DEEP, "Loading %d byte encryption key,\n",
buffer_len(&sealed_NVM));
+=20
+  Crypto_SHA1Full(sealed_NVM.bytes, buffer_len(&sealed_NVM), (BYTE *)
&sealedNVMHash);  =20
+=20
+  // Verify measurement of sealed blob.
+  if (memcmp(&sealedNVMHash, &myDMI->NVM_measurement,
sizeof(TPM_DIGEST)) ) {
+    vtpmlogerror(VTPM_LOG_VTPM, "VTPM LoadKey NVM measurement check
failed.\n");
+    vtpmloginfo(VTPM_LOG_VTPM_DEEP, "Correct hash: ");
+    for (i=3D0; i< sizeof(TPM_DIGEST); i++)
+      vtpmloginfomore(VTPM_LOG_VTPM_DEEP, "%x ",
((BYTE*)&myDMI->NVM_measurement)[i]);
+    vtpmloginfomore(VTPM_LOG_VTPM_DEEP, "\n");
+
+    vtpmloginfo(VTPM_LOG_VTPM_DEEP, "Measured hash: ");
+    for (i=3D0; i< sizeof(TPM_DIGEST); i++)
+      vtpmloginfomore(VTPM_LOG_VTPM_DEEP, "%x ",
((BYTE*)&sealedNVMHash)[i]);
+    vtpmloginfomore(VTPM_LOG_VTPM_DEEP, "\n");
+  =20
+    status =3D TPM_AUTHFAIL;
+    goto abort_egress;
+  }
+=20
+  //Decrypt the key into the output buffer
+  TPMTRYRETURN( symkey_decrypt(&sealed_NVM,
+                                 myDMI->TCSContext,
+                     vtpm_globals->storageKeyHandle,
+                     (const
TPM_AUTHDATA*)&vtpm_globals->storage_key_usage_auth,
+                                 outbuf) );=20
+  goto egress;
+=20
+ abort_egress:
+  vtpmlogerror(VTPM_LOG_VTPM, "Failed to load Key\n.");
+=20
+ egress:
+  buffer_free( &sealed_NVM );
+  close(fh);
+=20
+  return status;
+}
+
+TPM_RESULT VTPM_Handle_Save_HashKey(VTPM_DMI_RESOURCE *myDMI,
+                                 const buffer_t    *inbuf,
+                 buffer_t          *outbuf) {
+  TPM_RESULT status =3D TPM_SUCCESS;
+  int fh =3D -1;
+  long bytes_written;
+  buffer_t sealed_key =3D NULL_BUF;
+=20
+  TPMTRYRETURN( symkey_encrypt(inbuf,
+                                 &vtpm_globals->storageKey,
+                                 &sealed_key) );
+
+  vtpmloginfo(VTPM_LOG_VTPM_DEEP, "Saving %d byte Encryption Key.\n",
buffer_len(inbuf));
+
+  // Write sealed blob off disk from NVMLocation
+  // TODO: How to properly return from these. Do we care if we return
failure
+  //       after writing the file? We can't get the old one back.
+  // TODO: Backup old file and try and recover that way.
+  fh =3D open(myDMI->NVMLocation, O_WRONLY | O_CREAT | O_TRUNC, S_IREAD =
|
S_IWRITE);
+  if ( (bytes_written =3D write(fh, sealed_key.bytes,
buffer_len(&sealed_key) ) !=3D (long) buffer_len(&sealed_key))) {
+    vtpmlogerror(VTPM_LOG_VTPM, "We just overwrote a DMI_NVM and failed
to finish. %ld/%ld bytes.\n", bytes_written, (long)buffer_len(&sealed_key=
));
+    status =3D TPM_IOERROR;
+    goto abort_egress;
+  }
 =20
+  Crypto_SHA1Full (sealed_key.bytes, buffer_len(&sealed_key), (BYTE *)
&myDMI->NVM_measurement); =20
+=20
+  goto egress;
+=20
+ abort_egress:
+  vtpmlogerror(VTPM_LOG_VTPM, "Failed to save Key\n.");
+=20
+ egress:
+  close(fh);
+  buffer_free(&sealed_key);
   return status;
 }
=20
=20
 TPM_RESULT VTPM_SaveManagerData(void) {
   TPM_RESULT status=3DTPM_SUCCESS;
-  int fh, dmis=3D-1;
+  int fh =3D -1, dmis=3D-1;
=20
   BYTE *flat_boot_key=3DNULL, *flat_dmis=3DNULL, *flat_enc=3DNULL;
   buffer_t clear_flat_global=3DNULL_BUF, enc_flat_global=3DNULL_BUF;
@@ -364,6 +542,7 @@ TPM_RESULT VTPM_SaveManagerData(void) {
                                         BSG_TPM_DIGEST,
&dmi_res->DMI_measurement);
=20
     } while (hashtable_iterator_advance(dmi_itr));
+    free(dmi_itr);
   }
=20
   fh =3D open(STATE_FILE, O_WRONLY | O_CREAT, S_IREAD | S_IWRITE);
@@ -389,6 +568,7 @@ TPM_RESULT VTPM_SaveManagerData(void) {
=20
   free(flat_boot_key);
   free(flat_enc);
+  buffer_free(&clear_flat_global);
   buffer_free(&enc_flat_global);
   free(flat_dmis);
   close(fh);
@@ -403,9 +583,10 @@ TPM_RESULT VTPM_LoadManagerData(void) {
   int fh, stat_ret, dmis=3D0;
   long fh_size =3D 0, step_size;
   BYTE *flat_table=3DNULL;
-  buffer_t  unsealed_data, enc_table_abuf;
-  struct pack_buf_t storage_key_pack, boot_key_pack;
-  UINT32 *dmi_id_key, enc_size;
+  buffer_t  unsealed_data =3D NULL_BUF;
+  buffer_t enc_table_abuf;
+  struct pack_buf_t storage_key_pack =3D NULL_PACK_BUF, boot_key_pack =3D=

NULL_PACK_BUF;
+  UINT32 enc_size;
   BYTE vtpm_manager_gen;
=20
   VTPM_DMI_RESOURCE *dmi_res;
@@ -438,9 +619,9 @@ TPM_RESULT VTPM_LoadManagerData(void) {
                               BSG_TPM_SIZE32_DATA, &boot_key_pack,
                               BSG_TYPE_UINT32, &enc_size);
=20
-  TPMTRYRETURN(buffer_init(&vtpm_globals->bootKeyWrap, 0, 0) );
   TPMTRYRETURN(buffer_init_alias_convert(&enc_table_abuf, enc_size,
flat_table + step_size) );
-  TPMTRYRETURN(buffer_append_raw(&vtpm_globals->bootKeyWrap,
boot_key_pack.size, boot_key_pack.data) );
+  TPMTRYRETURN(buffer_init(&vtpm_globals->bootKeyWrap,
boot_key_pack.size, boot_key_pack.data) );
+
=20
   //Load Boot Key
   TPMTRYRETURN( VTSP_LoadKey( vtpm_globals->manager_tcs_handle,
@@ -471,8 +652,8 @@ TPM_RESULT VTPM_LoadManagerData(void) {
                   BSG_TPM_SECRET,   &vtpm_globals->storage_key_usage_aut=
h,
                   BSG_TPM_SIZE32_DATA, &storage_key_pack);
=20
-  TPMTRYRETURN(buffer_init(&vtpm_globals->storageKeyWrap, 0, 0) );
-  TPMTRYRETURN(buffer_append_raw(&vtpm_globals->storageKeyWrap,
storage_key_pack.size, storage_key_pack.data) );
+  TPMTRYRETURN(buffer_init(&vtpm_globals->storageKeyWrap,
storage_key_pack.size, storage_key_pack.data) );
+
=20
   // Per DMI values to be saved
   while ( step_size < fh_size ){
@@ -501,7 +682,10 @@ TPM_RESULT VTPM_LoadManagerData(void) {
  abort_egress:
   vtpmlogerror(VTPM_LOG_VTPM, "Failed to load service data with error =3D=

%s\n", tpm_get_error_name(status));
  egress:
+  BSG_Destroy(BSG_TPM_SIZE32_DATA, &boot_key_pack);
+  BSG_Destroy(BSG_TPM_SIZE32_DATA, &storage_key_pack);
=20
+  buffer_free(&unsealed_data);
   free(flat_table);
   close(fh);
=20
diff --git a/tools/vtpm_manager/manager/vtpm_ipc.c
b/tools/vtpm_manager/manager/vtpm_ipc.c
--- a/tools/vtpm_manager/manager/vtpm_ipc.c
+++ b/tools/vtpm_manager/manager/vtpm_ipc.c
@@ -36,26 +36,49 @@
 //
 // =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
=20
+#include <sys/types.h>
 #include <sys/stat.h>
+#include <fcntl.h>
+#include <unistd.h>
+#include <sys/select.h>
 #include "vtpm_ipc.h"
 #include "vtpmpriv.h"
 #include "log.h"
=20
-int vtpm_ipc_init(vtpm_ipc_handle_t *ipc_h, char* name, int flags, BOOL
create) {
+volatile sig_atomic_t IPC_QUIT_FLAG =3D 0;
+
+const static struct timeval TIMEOUT =3D {
+   .tv_sec =3D 1,
+   .tv_usec =3D 0
+};
+
+int vtpm_ipc_init(vtpm_ipc_handle_t *ipc_h, char* name, int flags, BOOL
create, BOOL preopen) {
+  int rc;
+
   ipc_h->name =3D name;
   ipc_h->flags =3D flags;
   ipc_h->fh =3D VTPM_IPC_CLOSED;
=20
-  if (create)
-    return(vtpm_ipc_create(ipc_h));
-  else
-    return 0;
+  if (create) {
+    if((rc =3D vtpm_ipc_create(ipc_h) !=3D 0)) {
+       return rc;
+    }
+  }
+
+  if(preopen) {
+    ipc_h->fh =3D open(ipc_h->name, ipc_h->flags);
+    if ( ipc_h->fh =3D=3D VTPM_IPC_CLOSED ) {
+       vtpmlogerror(VTPM_LOG_VTPM, "VTPM ERROR: Can't open %s\n",
ipc_h->name);
+       return -1;
+    }
+  }
+  return 0;
+
 }
=20
 // Create the file that needs opening. Used only for FIFOs
 // FYI: This may cause problems in other file IO schemes. We'll see.
 int vtpm_ipc_create(vtpm_ipc_handle_t *ipc_h) {
-  int fh;
   struct stat file_info;
=20
   if ((!ipc_h) || (!ipc_h->name))
@@ -68,8 +91,6 @@ int vtpm_ipc_create(vtpm_ipc_handle_t *ipc_h) {
     }
   }
=20
-  ipc_h->fh =3D VTPM_IPC_CLOSED;
-
   return 0;
 }
=20
@@ -78,6 +99,8 @@ int vtpm_ipc_create(vtpm_ipc_handle_t *ipc_h) {
 int vtpm_ipc_read(vtpm_ipc_handle_t *ipc_h, vtpm_ipc_handle_t
*alt_ipc_h, BYTE *bytes, UINT32 size){
   vtpm_ipc_handle_t *my_ipc_h;
   int result;
+  fd_set fds;
+  struct timeval timeout;
 =20
   if (ipc_h) {
     my_ipc_h =3D ipc_h;
@@ -94,9 +117,19 @@ int vtpm_ipc_read(vtpm_ipc_handle_t *ipc_h,
vtpm_ipc_handle_t *alt_ipc_h, BYTE *
     return -1;
   }
=20
+  FD_ZERO(&fds);
+  while(!FD_ISSET( my_ipc_h->fh, &fds )) {
+     timeout =3D TIMEOUT;
+     if (IPC_QUIT_FLAG) {
+    return -1;
+     }
+     FD_SET(my_ipc_h->fh, &fds);
+     select(my_ipc_h->fh + 1, &fds, NULL, NULL, &timeout);
+  }
+
   result =3D read(my_ipc_h->fh, bytes, size);
   if (result < 0) {
-    my_ipc_h->fh =3D VTPM_IPC_CLOSED;
+     my_ipc_h->fh =3D VTPM_IPC_CLOSED;
   }
=20
   return (result);
@@ -106,6 +139,8 @@ int vtpm_ipc_read(vtpm_ipc_handle_t *ipc_h,
vtpm_ipc_handle_t *alt_ipc_h, BYTE *
 int vtpm_ipc_write(vtpm_ipc_handle_t *ipc_h, vtpm_ipc_handle_t
*alt_ipc_h, BYTE *bytes, UINT32 size) {
   vtpm_ipc_handle_t *my_ipc_h;
   int result;
+  fd_set fds;
+  struct timeval timeout;
=20
   if (ipc_h) {
     my_ipc_h =3D ipc_h;
@@ -122,6 +157,16 @@ int vtpm_ipc_write(vtpm_ipc_handle_t *ipc_h,
vtpm_ipc_handle_t *alt_ipc_h, BYTE
     return -1;
   }
=20
+  FD_ZERO(&fds);
+  while(!FD_ISSET( my_ipc_h->fh, &fds )) {
+     timeout =3D TIMEOUT;
+     if (IPC_QUIT_FLAG) {
+    return -1;
+     }
+     FD_SET(my_ipc_h->fh, &fds);
+     select(my_ipc_h->fh + 1, NULL, &fds, NULL, &timeout);
+  }
+
   result =3D write(my_ipc_h->fh, bytes, size);
   if (result < 0) {
     my_ipc_h->fh =3D VTPM_IPC_CLOSED;
diff --git a/tools/vtpm_manager/manager/vtpm_ipc.h
b/tools/vtpm_manager/manager/vtpm_ipc.h
--- a/tools/vtpm_manager/manager/vtpm_ipc.h
+++ b/tools/vtpm_manager/manager/vtpm_ipc.h
@@ -39,10 +39,14 @@
 #ifndef __VTPM_IO_H__
 #define __VTPM_IO_H__
=20
+#include <signal.h>
+
 #include "tcg.h"
=20
 #define VTPM_IPC_CLOSED -1
=20
+extern volatile sig_atomic_t IPC_QUIT_FLAG;
+
 // Represents an (somewhat) abstracted io handle.
 typedef struct vtpm_ipc_handle_t {
   int fh;              // IO handle.
@@ -53,7 +57,7 @@ typedef struct vtpm_ipc_handle_t {
 } vtpm_ipc_handle_t;
=20
=20
-int vtpm_ipc_init(vtpm_ipc_handle_t *ioh, char* name, int flags, BOOL
create);
+int vtpm_ipc_init(vtpm_ipc_handle_t *ioh, char* name, int flags, BOOL
create, BOOL preopen);
=20
 // Create the file that needs opening. Used only for FIFOs
 // FYI: This may cause problems in other file IO schemes. We'll see.
diff --git a/tools/vtpm_manager/manager/vtpm_lock.c
b/tools/vtpm_manager/manager/vtpm_lock.c
--- a/tools/vtpm_manager/manager/vtpm_lock.c
+++ b/tools/vtpm_manager/manager/vtpm_lock.c
@@ -40,24 +40,24 @@
=20
 static pthread_rwlock_t vtpm_lock;
=20
-void vtpm_lock_init() {
+void vtpm_lock_init(void) {
=20
   pthread_rwlock_init( &vtpm_lock, NULL);
 }
=20
-void vtpm_lock_destroy(){
+void vtpm_lock_destroy(void){
   pthread_rwlock_destroy(&vtpm_lock);
 }
=20
-void vtpm_lock_rdlock(){
+void vtpm_lock_rdlock(void){
   pthread_rwlock_rdlock(&vtpm_lock);
 }
=20
-void vtpm_lock_wrlock(){
+void vtpm_lock_wrlock(void){
   pthread_rwlock_wrlock(&vtpm_lock);
 }
=20
-void vtpm_lock_unlock(){
+void vtpm_lock_unlock(void){
   pthread_rwlock_unlock(&vtpm_lock);
 }
=20
diff --git a/tools/vtpm_manager/manager/vtpm_lock.h
b/tools/vtpm_manager/manager/vtpm_lock.h
--- a/tools/vtpm_manager/manager/vtpm_lock.h
+++ b/tools/vtpm_manager/manager/vtpm_lock.h
@@ -38,11 +38,11 @@
 #ifndef __VTPM_LOCK_H__
 #define __VTPM_LOCK_H__
=20
-void vtpm_lock_init();
-void vtpm_lock_destroy();
+void vtpm_lock_init(void);
+void vtpm_lock_destroy(void);
=20
-void vtpm_lock_rdlock();
-void vtpm_lock_wrlock();
-void vtpm_lock_unlock();
+void vtpm_lock_rdlock(void);
+void vtpm_lock_wrlock(void);
+void vtpm_lock_unlock(void);
=20
 #endif
diff --git a/tools/vtpm_manager/manager/vtpm_manager.c
b/tools/vtpm_manager/manager/vtpm_manager.c
--- a/tools/vtpm_manager/manager/vtpm_manager.c
+++ b/tools/vtpm_manager/manager/vtpm_manager.c
@@ -40,10 +40,12 @@
 #include <stdio.h>
 #include <unistd.h>
 #include <string.h>
+#include <stdlib.h>
=20
 #include "vtpm_manager.h"
 #include "vtpmpriv.h"
 #include "vtsp.h"
+#include "tpmddl.h"
 #include "bsg.h"
 #include "hashtable.h"
 #include "hashtable_itr.h"
@@ -54,8 +56,8 @@
 VTPM_GLOBALS *vtpm_globals=3DNULL;
=20
 // --------------------------- Well Known Auths ------------------------=
--
-const TPM_AUTHDATA SRK_AUTH =3D {0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
0xff, 0xff, 0xff, 0xff,
-                                  0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
0xff, 0xff, 0xff, 0xff};
+const TPM_AUTHDATA SRK_AUTH =3D {0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00,
+                                  0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00};
=20
 #ifdef WELL_KNOWN_OWNER_AUTH
 static BYTE FIXED_OWNER_AUTH[20] =3D  {0xff, 0xff, 0xff, 0xff, 0xff,
0xff, 0xff, 0xff, 0xff, 0xff,
@@ -74,7 +76,6 @@ static int equals32(void *k1, void *k2) {
 }
=20
 // --------------------------- Functions ------------------------------
-
 TPM_RESULT VTPM_Create_Manager(){
 =20
   TPM_RESULT status =3D TPM_SUCCESS;
@@ -104,6 +105,7 @@ TPM_RESULT VTPM_Create_Manager(){
     TPMTRYRETURN(VTSP_DisablePubekRead(vtpm_globals->manager_tcs_handle,=

                                        (const
TPM_AUTHDATA*)&vtpm_globals->owner_usage_auth,=20
                                        &vtpm_globals->keyAuth));   =20
+    Crypto_RSACryptoInfoFree(&ek_cryptoInfo);
   } else {
     vtpmloginfo(VTPM_LOG_VTPM, "Failed to readEK meaning TPM has an
owner. Creating Keys off existing SRK.\n");
   }
@@ -181,7 +183,7 @@ TPM_RESULT VTPM_Create_Manager(){
 }
=20
 ////////////////////////////////////////////////////////////////////////=
///////
-TPM_RESULT VTPM_Init_Manager() {
+TPM_RESULT VTPM_Init_Manager(void) {
   TPM_RESULT status =3D TPM_FAIL, serviceStatus; =20
   BYTE *randomsead;
   UINT32 randomsize=3D256;
@@ -203,6 +205,11 @@ TPM_RESULT VTPM_Init_Manager() {
   vtpm_globals->manager_tcs_handle =3D 0;
=20
   TPMTRYRETURN(TCS_create());
+
+  // Blow away all stale handles left in the tpm
+  if(TDDL_FlushAllResources() !=3D TPM_SUCCESS) {
+     vtpmlogerror(VTPM_LOG_VTPM, "VTPM_FlushResources failed,
continuing anyway..\n");
+  }
 =20
   // Create TCS Context for service
   TPMTRYRETURN( TCS_OpenContext(&vtpm_globals->manager_tcs_handle ) );
@@ -228,7 +235,7 @@ TPM_RESULT VTPM_Init_Manager() {
     TPMTRYRETURN( VTPM_Create_Manager() );  =20
     TPMTRYRETURN( VTPM_SaveManagerData() );
   } else if (serviceStatus !=3D TPM_SUCCESS) {
-    vtpmlogerror(VTPM_LOG_VTPM, "Failed to read existing manager file");=

+    vtpmlogerror(VTPM_LOG_VTPM, "Failed to read existing manager file\n"=
);
     exit(1);
   }
=20
@@ -254,7 +261,7 @@ TPM_RESULT VTPM_Init_Manager() {
 }
=20
 ////////////////////////////////////////////////////////////////////////=
///////

-void VTPM_Stop_Manager() {
+void VTPM_Stop_Manager(void) {
   VTPM_DMI_RESOURCE *dmi_res;
   struct hashtable_itr *dmi_itr;
 =20
@@ -267,7 +274,7 @@ void VTPM_Stop_Manager() {
     close_dmi( dmi_res ); // Not really interested in return code
     =20
     } while (hashtable_iterator_advance(dmi_itr));
-        free (dmi_itr);
+    free (dmi_itr);
   }
 =20
   if ( VTPM_SaveManagerData() !=3D TPM_SUCCESS )
@@ -276,7 +283,21 @@ void VTPM_Stop_Manager() {
   TCS_CloseContext(vtpm_globals->manager_tcs_handle);
   TCS_destroy();
 =20
-  hashtable_destroy(vtpm_globals->dmi_map, 1);
+  if (hashtable_count(vtpm_globals->dmi_map) > 0) {
+    dmi_itr =3D hashtable_iterator(vtpm_globals->dmi_map);
+    do {
+      dmi_res =3D (VTPM_DMI_RESOURCE *) hashtable_iterator_value(dmi_itr=
);
+      free_dmi(dmi_res);
+    } while (hashtable_iterator_advance(dmi_itr));
+    free (dmi_itr);
+  }
+  hashtable_destroy(vtpm_globals->dmi_map, 0);
+
+  /* Cleanup resources */
+  Crypto_RSACryptoInfoFree(&vtpm_globals->bootKey);
+  Crypto_RSACryptoInfoFree(&vtpm_globals->storageKey);
+  buffer_free(&vtpm_globals->bootKeyWrap);
+  buffer_free(&vtpm_globals->storageKeyWrap);
   free(vtpm_globals);
 =20
   Crypto_Exit();
diff --git a/tools/vtpm_manager/manager/vtpm_manager.h
b/tools/vtpm_manager/manager/vtpm_manager.h
--- a/tools/vtpm_manager/manager/vtpm_manager.h
+++ b/tools/vtpm_manager/manager/vtpm_manager.h
@@ -61,6 +61,8 @@
 #define VTPM_ORD_TPMCOMMAND   (VTPM_ORD_BASE + 3) // DMI issues HW TPM
Command
 #define VTPM_ORD_GET_MIG_KEY  (VTPM_ORD_BASE + 4) // Get manager's
migration key
 #define VTPM_ORD_LOAD_MIG_KEY (VTPM_ORD_BASE + 5) // load dest
migration key
+#define VTPM_ORD_SAVEHASHKEY      (VTPM_ORD_BASE + 7) // DMI requests
encryption key for persistent storage
+#define VTPM_ORD_LOADHASHKEY      (VTPM_ORD_BASE + 8) // DMI requests
symkey to be regenerated
=20
 // Priviledged VTPM Commands (From management console)
 #define VTPM_ORD_OPEN         (VTPM_PRIV_BASE + 1) // Creates/reopens DM=
I
@@ -147,4 +149,23 @@ VTPM_TPMCommand
=20
 *********************************************************************/
=20
+#ifndef VTPM_STUBDOM
+#define TPM_EMULATOR_PATH "/usr/bin/vtpmd"
+#endif
+
+#define VTPM_BE_FNAME          "/dev/vtpm"
+#define VTPM_DUMMY_TX_BE_FNAME "/var/vtpm/fifos/dummy_out.fifo"
+#define VTPM_DUMMY_RX_BE_FNAME "/var/vtpm/fifos/dummy_in.fifo"
+#ifndef VTPM_STUBDOM
+#define VTPM_TX_TPM_FNAME      "/var/vtpm/fifos/tpm_cmd_to_%d.fifo"
+#define VTPM_RX_TPM_FNAME      "/var/vtpm/fifos/tpm_rsp_from_all.fifo"
+#define VTPM_TX_VTPM_FNAME     "/var/vtpm/fifos/vtpm_rsp_to_%d.fifo"
+#define VTPM_RX_VTPM_FNAME     "/var/vtpm/fifos/vtpm_cmd_from_all.fifo"
+#endif
+#define VTPM_TX_HP_FNAME       "/var/vtpm/fifos/to_console.fifo"
+#define VTPM_RX_HP_FNAME       "/var/vtpm/fifos/from_console.fifo"
+
+#define VTPM_TYPE_PVM_STRING "pvm"
+#define VTPM_TYPE_HVM_STRING "hvm"
+
 #endif //_VTPM_MANAGER_H_
diff --git a/tools/vtpm_manager/manager/vtpm_manager_handler.c
b/tools/vtpm_manager/manager/vtpm_manager_handler.c
--- a/tools/vtpm_manager/manager/vtpm_manager_handler.c
+++ b/tools/vtpm_manager/manager/vtpm_manager_handler.c
@@ -41,6 +41,8 @@
 #include <unistd.h>
 #include <string.h>
 #include <errno.h>
+#include <signal.h>
+#include <stdlib.h>
=20
 #include "vtpm_manager.h"
 #include "vtpmpriv.h"
@@ -50,26 +52,13 @@
 #include "hashtable_itr.h"
 #include "log.h"
 #include "buffer.h"
+#include "vtpm_manager_handler.h"
=20
 #define vtpmhandlerloginfo(module,fmt,args...) vtpmloginfo (module,
"[%s]: " fmt, thread_name, ##args );
 #define vtpmhandlerloginfomore(module,fmt,args...) vtpmloginfomore
(module, fmt, ##args );
 #define vtpmhandlerlogerror(module,fmt,args...) vtpmlogerror (module,
"[%s]: " fmt, thread_name, ##args );
=20
-// ---------------------- Prototypes -------------------
-TPM_RESULT vtpm_manager_handle_vtpm_cmd(VTPM_DMI_RESOURCE *dmi_res,
-                    TPM_COMMAND_CODE ord,
-                    buffer_t *command_buf,
-                    buffer_t *result_buf,
-                                        BOOL is_priv,
-                                        char *thread_name);
-
-TPM_RESULT vtpm_manager_handle_tpm_cmd(vtpm_ipc_handle_t *tx_ipc_h,
-                                       vtpm_ipc_handle_t *rx_ipc_h,
-                                       VTPM_DMI_RESOURCE *dmi_res,
-                                       BYTE *cmd_header,
-                                       buffer_t *param_buf,
-                                       buffer_t *result_buf,
-                                       char *thread_name);
+volatile sig_atomic_t HANDLER_QUIT_FLAG =3D 0;
=20
 TPM_RESULT VTPM_Manager_Handler( vtpm_ipc_handle_t *tx_ipc_h,
                                  vtpm_ipc_handle_t *rx_ipc_h,
@@ -80,12 +69,13 @@ TPM_RESULT VTPM_Manager_Handler( vtpm_ipc_handle_t
*tx_ipc_h,
                                  char *thread_name) {
   TPM_RESULT      status =3D  TPM_FAIL; // Should never return
   UINT32          dmi, in_param_size, cmd_size, out_param_size,
out_message_size, reply_size;
-  BYTE            *cmd_header=3DNULL, *in_param=3DNULL, *out_message=3DN=
ULL,
*reply;
+  BYTE            *cmd_header=3DNULL, *in_param=3DNULL, *out_header=3DNU=
LL,
*reply;
   buffer_t        *command_buf=3DNULL, *result_buf=3DNULL;
   TPM_TAG         tag;
   TPM_COMMAND_CODE ord;
   VTPM_DMI_RESOURCE *dmi_res;
   int  size_read, size_write, i;
+  int locked;
   BOOL add_header=3DTRUE; // This indicates to prepend a header on
result_buf before sending
 =20
   cmd_header =3D (BYTE *) malloc(VTPM_COMMAND_HEADER_SIZE_SRV);
@@ -93,7 +83,11 @@ TPM_RESULT VTPM_Manager_Handler( vtpm_ipc_handle_t
*tx_ipc_h,
   result_buf =3D (buffer_t *) malloc(sizeof(buffer_t));
=20
   // ------------------------ Main Loop --------------------------------=

-  while(1) {
+  while(!HANDLER_QUIT_FLAG) {
+    locked =3D 0;
+
+    buffer_init(command_buf, 0, NULL);
+    buffer_init(result_buf, 0, NULL);
   =20
     vtpmhandlerloginfo(VTPM_LOG_VTPM, "%s waiting for messages.\n",
thread_name);
=20
@@ -106,7 +100,9 @@ TPM_RESULT VTPM_Manager_Handler( vtpm_ipc_handle_t
*tx_ipc_h,
       for (i=3D0; i<size_read; i++)
     vtpmhandlerloginfomore(VTPM_LOG_VTPM_DEEP, "%x ", cmd_header[i]);
     } else {
-      vtpmhandlerlogerror(VTPM_LOG_VTPM, "%s can't read from ipc.
Errono =3D %d. Aborting... \n", thread_name, errno);
+      if (!IPC_QUIT_FLAG) {
+    vtpmhandlerlogerror(VTPM_LOG_VTPM, "%s can't read from ipc. Errono
=3D %d. Aborting... \n", thread_name, errno);
+      }
       goto abort_command;
     }
=20
@@ -155,6 +151,7 @@ TPM_RESULT VTPM_Manager_Handler( vtpm_ipc_handle_t
*tx_ipc_h,
       vtpmhandlerlogerror(VTPM_LOG_VTPM, "Failed to setup buffers.
Aborting...\n");
       goto abort_command;
     }
+    result_buf->is_owner =3D TRUE;
   =20
     // -------------- Dispatch Commands to Handlers -----------
     if ((tag =3D=3D VTPM_TAG_REQ) && (ord & VTPM_PRIV_MASK)) {
@@ -162,6 +159,7 @@ TPM_RESULT VTPM_Manager_Handler( vtpm_ipc_handle_t
*tx_ipc_h,
     } else {
       vtpm_lock_rdlock();
     }
+    locked =3D 1;
=20
     if ( !(dmi_res =3D (VTPM_DMI_RESOURCE *)
hashtable_search(vtpm_globals->dmi_map, &dmi)) ||
          (!dmi_res->connected) ) {
@@ -174,10 +172,22 @@ TPM_RESULT VTPM_Manager_Handler( vtpm_ipc_handle_t
*tx_ipc_h,
     if (tag =3D=3D VTPM_TAG_REQ) {
   =20
       status =3D vtpm_manager_handle_vtpm_cmd(dmi_res, ord, command_buf,=

result_buf, is_priv, thread_name);
+      result_buf->is_owner =3D TRUE;
=20
     } else { // This is not a VTPM Command at all.
       if (fw_tpm) {
+#ifdef VTPM_STUBDOM
+    /* In stubdom mode, we allow the vtpm domains to send raw tpm
commands down the pipe
+     * They can also just embed their tpm commands inside VTPM commands
if they wish to*/
+
+    /* Stick the header back onto the raw command (minus the dmiid) */
+    buffer_prepend_raw(command_buf, VTPM_COMMAND_HEADER_SIZE_CLT,
cmd_header + sizeof(UINT32));
+    status =3D VTPM_Handle_TPM_Command(dmi_res, command_buf, result_buf)=
;
+#else
+    /* In normal mode, this is used for the guest to forward a raw
command to the vtpm process */
         status =3D vtpm_manager_handle_tpm_cmd(fw_tx_ipc_h, fw_rx_ipc_h,=

dmi_res, cmd_header, command_buf, result_buf, thread_name);
+#endif
+        result_buf->is_owner =3D TRUE;
=20
         // This means calling the DMI failed, not that the cmd failed
in the DMI
         // Since the return will be interpretted by a TPM app, all
errors are IO_ERRORs to the app
@@ -207,36 +217,42 @@ TPM_RESULT VTPM_Manager_Handler( vtpm_ipc_handle_t
*tx_ipc_h,
     // ------------------- Respond to Sender ------------------
=20
     // Errors while handling responses jump here to reply with error
messages
-    // NOTE: Currently there are no recoverable errors in multi-VM
mode. If one
-    //       is added to the code, this ifdef should be removed.
-    //       Also note this is NOT referring to errors in commands, but
rather
-    //       this is about I/O errors and such.
-#ifndef VTPM_MULTI_VM
- abort_with_error:
-#endif
+abort_with_error:
  =20
     if (add_header) {
       // Prepend VTPM header with destination DM stamped
       out_param_size =3D buffer_len(result_buf);
       out_message_size =3D VTPM_COMMAND_HEADER_SIZE_CLT + out_param_size=
;
-      reply_size =3D VTPM_COMMAND_HEADER_SIZE_SRV + out_param_size;
-      out_message =3D (BYTE *) malloc (reply_size);
-      reply =3D out_message;
+      out_header =3D (BYTE *) malloc (VTPM_COMMAND_HEADER_SIZE_SRV);
   =20
-      BSG_PackList(out_message, 4,
+      BSG_PackList(out_header, 4,
            BSG_TYPE_UINT32, (BYTE *) &dmi,
            BSG_TPM_TAG, (BYTE *) &tag,
            BSG_TYPE_UINT32, (BYTE *) &out_message_size,
            BSG_TPM_RESULT, (BYTE *) &status);
   =20
-      if (buffer_len(result_buf) > 0)
-        memcpy(out_message + VTPM_COMMAND_HEADER_SIZE_SRV,
result_buf->bytes, out_param_size);
-      //Note: Send message + dmi_id
+      buffer_prepend_raw(result_buf, VTPM_COMMAND_HEADER_SIZE_SRV,
out_header);
+      free(out_header);
     } else {
-      reply =3D result_buf->bytes;
-      reply_size =3D buffer_len(result_buf);
+#ifdef VTPM_STUBDOM
+       //In stubdom mode, we need to always prepend the dmiid so the
raw command can be returned to the right domain
+       out_header =3D (BYTE*) malloc(sizeof(UINT32));
+       BSG_PackList(out_header, 1,
+         BSG_TYPE_UINT32, (BYTE*) &dmi);
+       buffer_prepend_raw(result_buf, sizeof(UINT32), out_header);
+       free(out_header);
+#endif
     }=20
+    reply =3D result_buf->bytes;
+    reply_size =3D buffer_len(result_buf);
+#ifndef VTPM_STUBDOM
     size_write =3D vtpm_ipc_write(tx_ipc_h, (dmi_res ?
dmi_res->tx_vtpm_ipc_h : NULL), reply, reply_size );
+#else
+    if(reply_size >=3D 4096) {
+       vtpmhandlerlogerror(VTPM_LOG_VTPM, "MESSAGE TOO BIG!!!");
+    }
+    size_write =3D vtpm_ipc_write(tx_ipc_h, NULL, reply, reply_size );
+#endif
     if (size_write > 0) {
       vtpmhandlerloginfo(VTPM_LOG_VTPM_DEEP, "SENT: 0x");
       for (i=3D0; i < reply_size; i++)
@@ -247,7 +263,6 @@ TPM_RESULT VTPM_Manager_Handler( vtpm_ipc_handle_t
*tx_ipc_h,
       vtpmhandlerlogerror(VTPM_LOG_VTPM, "%s had error writing to ipc.
Aborting... \n", thread_name);
       goto abort_command;
     }
-    free(out_message); out_message=3DNULL;
   =20
     if (size_write < (int)reply_size) {
       vtpmhandlerlogerror(VTPM_LOG_VTPM, "%s unable to write full
command to ipc (%d/%d)\n", thread_name, size_write, reply_size);
@@ -264,14 +279,22 @@ TPM_RESULT VTPM_Manager_Handler( vtpm_ipc_handle_t
*tx_ipc_h,
     buffer_free(command_buf);
=20
     // If we have a write lock, save the manager table
-    if ((tag =3D=3D VTPM_TAG_REQ) && (ord & VTPM_PRIV_MASK) &&
+    if (locked && (tag =3D=3D VTPM_TAG_REQ) && (ord & VTPM_PRIV_MASK) &&=

         (VTPM_SaveManagerData() !=3D TPM_SUCCESS) ) {
        vtpmhandlerlogerror(VTPM_LOG_VTPM, "ERROR: Unable to save
manager data.\n");
     }
=20
-    vtpm_lock_unlock();
+    if(locked) {
+       vtpm_lock_unlock();
+    }
     add_header =3D TRUE; // Reset to the default
   } // End while(1)
+
+  free(cmd_header);
+  free(command_buf);
+  free(result_buf);
+
+  vtpmhandlerloginfo(VTPM_LOG_VTPM, "exiting\n", thread_name);
 =20
 }
=20
@@ -313,6 +336,16 @@ TPM_RESULT
vtpm_manager_handle_vtpm_cmd(VTPM_DMI_RESOURCE *dmi_res,
     status =3D VTPM_Handle_Load_Migration_key(command_buf,
                                            result_buf);
     break;
+  case VTPM_ORD_SAVEHASHKEY:
+    status =3D VTPM_Handle_Save_HashKey(dmi_res,
+                     command_buf,
+                   result_buf);
+    break;
+  case VTPM_ORD_LOADHASHKEY:
+    status =3D VTPM_Handle_Load_HashKey(dmi_res,
+                     command_buf,
+                   result_buf);
+    break;
  =20
   default:
     // Privileged handlers can do maintanance
@@ -350,6 +383,7 @@ TPM_RESULT
vtpm_manager_handle_vtpm_cmd(VTPM_DMI_RESOURCE *dmi_res,
   return(status);
 }
     =20
+#ifndef VTPM_STUBDOM
 /////////////////////////////////////////////////////////////////////
 TPM_RESULT vtpm_manager_handle_tpm_cmd(vtpm_ipc_handle_t *tx_ipc_h,
                                        vtpm_ipc_handle_t *rx_ipc_h,
@@ -485,4 +519,5 @@ TPM_RESULT
vtpm_manager_handle_tpm_cmd(vtpm_ipc_handle_t *tx_ipc_h,
=20
   return status;
 }
+#endif
=20
diff --git a/tools/vtpm_manager/manager/vtpm_manager_handler.h
b/tools/vtpm_manager/manager/vtpm_manager_handler.h
--- /dev/null
+++ b/tools/vtpm_manager/manager/vtpm_manager_handler.h
@@ -0,0 +1,21 @@
+#ifndef VTPM_MANAGER_HANDLER_H
+#define VTPM_MANAGER_HANDLER_H
+// ---------------------- Prototypes -------------------
+TPM_RESULT vtpm_manager_handle_vtpm_cmd(VTPM_DMI_RESOURCE *dmi_res,
+                    TPM_COMMAND_CODE ord,
+                    buffer_t *command_buf,
+                    buffer_t *result_buf,
+                                        BOOL is_priv,
+                                        char *thread_name);
+
+#ifndef VTPM_STUBDOM
+TPM_RESULT vtpm_manager_handle_tpm_cmd(vtpm_ipc_handle_t *tx_ipc_h,
+                                       vtpm_ipc_handle_t *rx_ipc_h,
+                                       VTPM_DMI_RESOURCE *dmi_res,
+                                       BYTE *cmd_header,
+                                       buffer_t *param_buf,
+                                       buffer_t *result_buf,
+                                       char *thread_name);
+#endif
+
+#endif
diff --git a/tools/vtpm_manager/manager/vtpmd.c
b/tools/vtpm_manager/manager/vtpmd.c
--- a/tools/vtpm_manager/manager/vtpmd.c
+++ b/tools/vtpm_manager/manager/vtpmd.c
@@ -45,27 +45,13 @@
 #include <signal.h>
 #include <string.h>
 #include <pthread.h>
+#include <stdlib.h>
 #include "vtpm_manager.h"
 #include "vtpmpriv.h"
 #include "tcg.h"
 #include "log.h"
 #include "vtpm_ipc.h"
=20
-#define TPM_EMULATOR_PATH "/usr/bin/vtpmd"
-
-#define VTPM_BE_FNAME          "/dev/vtpm"
-#define VTPM_DUMMY_TX_BE_FNAME "/var/vtpm/fifos/dummy_out.fifo"
-#define VTPM_DUMMY_RX_BE_FNAME "/var/vtpm/fifos/dummy_in.fifo"
-#define VTPM_TX_TPM_FNAME      "/var/vtpm/fifos/tpm_cmd_to_%d.fifo"
-#define VTPM_RX_TPM_FNAME      "/var/vtpm/fifos/tpm_rsp_from_all.fifo"
-#define VTPM_TX_VTPM_FNAME     "/var/vtpm/fifos/vtpm_rsp_to_%d.fifo"
-#define VTPM_RX_VTPM_FNAME     "/var/vtpm/fifos/vtpm_cmd_from_all.fifo"
-#define VTPM_TX_HP_FNAME       "/var/vtpm/fifos/to_console.fifo"
-#define VTPM_RX_HP_FNAME       "/var/vtpm/fifos/from_console.fifo"
-
-#define VTPM_TYPE_PVM_STRING "pvm"
-#define VTPM_TYPE_HVM_STRING "hvm"
-
 struct vtpm_thread_params_s {
   vtpm_ipc_handle_t *tx_ipc_h;
   vtpm_ipc_handle_t *rx_ipc_h;
@@ -76,180 +62,46 @@ struct vtpm_thread_params_s {
   char *thread_name;
 };
=20
+static pthread_t           master_thread;
+static pthread_t           be_thread;
+static pthread_t           hp_thread;
+#ifndef VTPM_STUBDOM
+static pthread_t           dmi_thread;
+#endif
+
+
+#ifndef VTPM_STUBDOM
 // This is needed to all extra_close_dmi to close this to prevent a
 // broken pipe when no DMIs are left.
-static vtpm_ipc_handle_t *g_rx_tpm_ipc_h;
+extern vtpm_ipc_handle_t *g_rx_tpm_ipc_h;
+#endif
=20
 void *vtpm_manager_thread(void *arg_void) {
-  TPM_RESULT *status =3D (TPM_RESULT *) malloc(sizeof(TPM_RESULT) );
   struct vtpm_thread_params_s *arg =3D (struct vtpm_thread_params_s *)
arg_void;
=20
-  *status =3D VTPM_Manager_Handler(arg->tx_ipc_h, arg->rx_ipc_h,
+  VTPM_Manager_Handler(arg->tx_ipc_h, arg->rx_ipc_h,
                                  arg->fw_tpm, arg->fw_tx_ipc_h,
arg->fw_rx_ipc_h,
                                  arg->is_priv, arg->thread_name);
=20
-  return (status);
+  return NULL;
 }
=20
-
-void signal_handler(int reason) {
-  if (pthread_equal(pthread_self(), vtpm_globals->master_pid)) {
-    vtpmloginfo(VTPM_LOG_VTPM, "VTPM Manager shutting down for signal
%d.\n", reason);
-  } else {
-    // For old Linux Thread machines, signals are delivered to each
thread. Deal with them.
-    vtpmloginfo(VTPM_LOG_VTPM, "Child shutting down\n");
-    pthread_exit(NULL);
+void signal_handler(int signal) {
+  if (pthread_equal(pthread_self(), master_thread)) {
+    vtpmloginfo(VTPM_LOG_VTPM, "VTPM Manager shutting down for signal
%s(%d). Please wait..\n", strsignal(signal), signal);
+    HANDLER_QUIT_FLAG =3D IPC_QUIT_FLAG =3D 1;
   }
-
-  VTPM_Stop_Manager();
-  exit(-1);
 }
=20
 struct sigaction ctl_c_handler;
=20
-TPM_RESULT VTPM_New_DMI_Extra(VTPM_DMI_RESOURCE *dmi_res, BYTE vm_type,
BYTE startup_mode) {
-
-  TPM_RESULT status =3D TPM_SUCCESS;
-  int fh;
-  char dmi_id_str[11]; // UINT32s are up to 10 digits + NULL
-  char *tx_vtpm_name, *tx_tpm_name, *vm_type_string;
-  struct stat file_info;
-
-  if (dmi_res->dmi_id =3D=3D VTPM_CTL_DM) {
-    dmi_res->tx_tpm_ipc_h =3D NULL;
-    dmi_res->rx_tpm_ipc_h =3D NULL;
-    dmi_res->tx_vtpm_ipc_h =3D NULL;
-    dmi_res->rx_vtpm_ipc_h =3D NULL;
-  } else {
-    // Create a pair of fifo pipes
-    dmi_res->rx_tpm_ipc_h =3D NULL;
-    dmi_res->rx_vtpm_ipc_h =3D NULL;
-
-    if ( ((dmi_res->tx_tpm_ipc_h =3D (vtpm_ipc_handle_t *) malloc
(sizeof(vtpm_ipc_handle_t))) =3D=3D NULL ) ||
-         ((dmi_res->tx_vtpm_ipc_h =3D(vtpm_ipc_handle_t *) malloc
(sizeof(vtpm_ipc_handle_t))) =3D=3D NULL ) ||
-         ((tx_tpm_name =3D (char *) malloc(11 +
strlen(VTPM_TX_TPM_FNAME))) =3D=3D NULL ) ||
-         ((tx_vtpm_name =3D(char *) malloc(11 +
strlen(VTPM_TX_VTPM_FNAME))) =3D=3D NULL) ) {
-      status =3DTPM_RESOURCES;
-      goto abort_egress;
-    }
-
-    sprintf(tx_tpm_name, VTPM_TX_TPM_FNAME, (uint32_t) dmi_res->dmi_id);=

-    sprintf(tx_vtpm_name, VTPM_TX_VTPM_FNAME, (uint32_t) dmi_res->dmi_id=
);
-
-    if ( (vtpm_ipc_init(dmi_res->tx_tpm_ipc_h, tx_tpm_name, O_WRONLY |
O_NONBLOCK, TRUE) !=3D 0) ||
-         (vtpm_ipc_init(dmi_res->tx_vtpm_ipc_h, tx_vtpm_name, O_WRONLY,
TRUE) !=3D 0) ) { //FIXME: O_NONBLOCK?
-      status =3D TPM_IOERROR;
-      goto abort_egress;
-    }
-
-    // Measure DMI
-    // FIXME: This will measure DMI. Until then use a fixed
DMI_Measurement value
-    // Also, this mechanism is specific to 1 VM architecture.
-    /*
-    fh =3D open(TPM_EMULATOR_PATH, O_RDONLY);
-    stat_ret =3D fstat(fh, &file_stat);
-    if (stat_ret =3D=3D 0)
-      dmi_size =3D file_stat.st_size;
-    else {
-      vtpmlogerror(VTPM_LOG_VTPM, "Could not open vtpmd!!\n");
-      status =3D TPM_IOERROR;
-      goto abort_egress;
-    }
-    dmi_buffer
-    */
-    memset(&dmi_res->DMI_measurement, 0xcc, sizeof(TPM_DIGEST));
-
-    if (vm_type =3D=3D VTPM_TYPE_PVM)
-      vm_type_string =3D (BYTE *)&VTPM_TYPE_PVM_STRING;
-    else
-      vm_type_string =3D (BYTE *)&VTPM_TYPE_HVM_STRING;
-
-    // Launch DMI
-    sprintf(dmi_id_str, "%d", (int) dmi_res->dmi_id);
-#ifdef MANUAL_DM_LAUNCH
-    vtpmlogerror(VTPM_LOG_VTPM, "Manually start VTPM with dmi=3D%s
now.\n", dmi_id_str);
-    dmi_res->dmi_pid =3D 0;
-#else
-    pid_t pid =3D fork();
-
-    if (pid =3D=3D -1) {
-      vtpmlogerror(VTPM_LOG_VTPM, "Could not fork to launch vtpm\n");
-      status =3D TPM_RESOURCES;
-      goto abort_egress;
-    } else if (pid =3D=3D 0) {
-      switch (startup_mode) {
-      case TPM_ST_CLEAR:
-        execl (TPM_EMULATOR_PATH, "vtpmd", "clear", vm_type_string,
dmi_id_str, NULL);
-        break;
-      case TPM_ST_STATE:
-        execl (TPM_EMULATOR_PATH, "vtpmd", "save", vm_type_string,
dmi_id_str, NULL);
-        break;
-      case TPM_ST_DEACTIVATED:
-        execl (TPM_EMULATOR_PATH, "vtpmd", "deactivated",
vm_type_string, dmi_id_str, NULL);
-        break;
-      default:
-        status =3D TPM_BAD_PARAMETER;
-        goto abort_egress;
-      }
-
-      // Returning from these at all is an error.
-      vtpmlogerror(VTPM_LOG_VTPM, "Could not exec to launch vtpm\n");
-    } else {
-      dmi_res->dmi_pid =3D pid;
-      vtpmloginfo(VTPM_LOG_VTPM, "Launching DMI on PID =3D %d\n", pid);
-    }
-#endif // MANUAL_DM_LAUNCH
-
-  } // If DMI =3D VTPM_CTL_DM
-    status =3D TPM_SUCCESS;
-
-abort_egress:
-  return (status);
-}
-
-TPM_RESULT VTPM_Close_DMI_Extra(VTPM_DMI_RESOURCE *dmi_res) {
-  TPM_RESULT status =3D TPM_SUCCESS;
-
-  if (vtpm_globals->connected_dmis =3D=3D 0) {
-    // No more DMI's connected. Close fifo to prevent a broken pipe.
-    // This is hackish. Need to think of another way.
-    vtpm_ipc_close(g_rx_tpm_ipc_h);
-  }
-
-=20
-  if (dmi_res->dmi_id !=3D VTPM_CTL_DM) {
-    vtpm_ipc_close(dmi_res->tx_tpm_ipc_h);
-    vtpm_ipc_close(dmi_res->tx_vtpm_ipc_h);
-
-    free(dmi_res->tx_tpm_ipc_h->name);
-    free(dmi_res->tx_vtpm_ipc_h->name);
-
-#ifndef MANUAL_DM_LAUNCH
-    if (dmi_res->dmi_id !=3D VTPM_CTL_DM) {
-      if (dmi_res->dmi_pid !=3D 0) {
-        vtpmloginfo(VTPM_LOG_VTPM, "Killing dmi on pid %d.\n",
dmi_res->dmi_pid);
-        if (kill(dmi_res->dmi_pid, SIGKILL) !=3D0) {
-          vtpmloginfo(VTPM_LOG_VTPM, "DMI on pid %d is already
dead.\n", dmi_res->dmi_pid);
-        } else if (waitpid(dmi_res->dmi_pid, NULL, 0) !=3D
dmi_res->dmi_pid) {
-          vtpmlogerror(VTPM_LOG_VTPM, "DMI on pid %d failed to
stop.\n", dmi_res->dmi_pid);
-          status =3D TPM_FAIL;
-        }
-      } else {
-        vtpmlogerror(VTPM_LOG_VTPM, "Could not kill dmi because it's
pid was 0.\n");
-        status =3D TPM_FAIL;
-      }
-    }
-#endif
-
-  } //endif ! dom0
-  return status;
-}
-
-
 int main(int argc, char **argv) {
-  vtpm_ipc_handle_t *tx_be_ipc_h, *rx_be_ipc_h, rx_tpm_ipc_h,
rx_vtpm_ipc_h, tx_hp_ipc_h, rx_hp_ipc_h;
-  struct vtpm_thread_params_s be_thread_params, dmi_thread_params,
hp_thread_params;
-  pthread_t be_thread, dmi_thread, hp_thread;
+  vtpm_ipc_handle_t *tx_be_ipc_h, *rx_be_ipc_h, tx_hp_ipc_h, rx_hp_ipc_h=
;
+  struct vtpm_thread_params_s be_thread_params, hp_thread_params;
+#ifndef VTPM_STUBDOM
+  vtpm_ipc_handle_t rx_tpm_ipc_h, rx_vtpm_ipc_h;
+  struct vtpm_thread_params_s dmi_thread_params;
+#endif
=20
 #ifdef DUMMY_BACKEND
   vtpm_ipc_handle_t tx_dummy_ipc_h, rx_dummy_ipc_h;
@@ -258,34 +110,28 @@ int main(int argc, char **argv) {
 #endif
=20
   vtpmloginfo(VTPM_LOG_VTPM, "Starting VTPM.\n");
-
-  // -------------------- Initialize Manager -----------------
-  if (VTPM_Init_Manager() !=3D TPM_SUCCESS) {
-    vtpmlogerror(VTPM_LOG_VTPM, "Closing vtpmd due to error during
startup.\n");
-    return -1;
-  }
-=20
+
   // -------------------- Setup Ctrl+C Handlers --------------
   ctl_c_handler.sa_handler =3D signal_handler;
   sigemptyset(&ctl_c_handler.sa_mask);
   ctl_c_handler.sa_flags =3D 0;  =20
 =20
-  if (sigaction(SIGINT, &ctl_c_handler, NULL) =3D=3D -1)
+  if ((sigaction(SIGINT, &ctl_c_handler, NULL) =3D=3D -1)
+    || (sigaction(SIGQUIT, &ctl_c_handler, NULL) =3D=3D -1)
+    || (sigaction(SIGHUP, &ctl_c_handler, NULL) =3D=3D -1) ) // For easi=
er
debugging with gdb
+  {
     vtpmlogerror(VTPM_LOG_VTPM, "Could not install SIGINT handler.
Ctl+break will not stop manager gently.\n");
+  }
 =20
-  // For easier debuggin with gdb
-  if (sigaction(SIGHUP, &ctl_c_handler, NULL) =3D=3D -1)
-    vtpmlogerror(VTPM_LOG_VTPM, "Could not install SIGHUP handler.
Ctl+break will not stop manager gently.\n");  =20
-=20
+  //Block all signals for child threads
   sigset_t sig_mask;
-  sigemptyset(&sig_mask);
-  sigaddset(&sig_mask, SIGPIPE);
-  sigprocmask(SIG_BLOCK, &sig_mask, NULL);
+  sigfillset(&sig_mask);
+  pthread_sigmask(SIG_SETMASK, &sig_mask, NULL);
 =20
   // ------------------- Set up file ipc structures ----------
 #ifdef DUMMY_BACKEND
-  if ( (vtpm_ipc_init(&tx_dummy_ipc_h, VTPM_DUMMY_TX_BE_FNAME, O_RDWR,
TRUE) !=3D 0) ||
-       (vtpm_ipc_init(&rx_dummy_ipc_h, VTPM_DUMMY_RX_BE_FNAME, O_RDWR,
TRUE) !=3D 0) ) {
+  if ( (vtpm_ipc_init(&tx_dummy_ipc_h, VTPM_DUMMY_TX_BE_FNAME, O_RDWR,
TRUE, FALSE) !=3D 0) ||
+       (vtpm_ipc_init(&rx_dummy_ipc_h, VTPM_DUMMY_RX_BE_FNAME, O_RDWR,
TRUE, FALSE) !=3D 0) ) {
=20
     vtpmlogerror(VTPM_LOG_VTPM, "Unable to create Dummy BE FIFOs.\n");
     exit(-1);
@@ -294,21 +140,29 @@ int main(int argc, char **argv) {
   tx_be_ipc_h =3D &tx_dummy_ipc_h;
   rx_be_ipc_h =3D &rx_dummy_ipc_h;
 #else
-  vtpm_ipc_init(&real_be_ipc_h, VTPM_BE_FNAME, O_RDWR, FALSE);
+  if(vtpm_ipc_init(&real_be_ipc_h, VTPM_BE_FNAME, O_RDWR, FALSE, TRUE)
!=3D 0) {
+     vtpmlogerror(VTPM_LOG_VTPM, "Unable to open backend device "
VTPM_BE_FNAME "\n");
+     exit(-1);
+  }
=20
   tx_be_ipc_h =3D &real_be_ipc_h;
   rx_be_ipc_h =3D &real_be_ipc_h;
 #endif
=20
-  if ( (vtpm_ipc_init(&rx_tpm_ipc_h, VTPM_RX_TPM_FNAME, O_RDONLY, TRUE)
!=3D 0) ||
-       (vtpm_ipc_init(&rx_vtpm_ipc_h, VTPM_RX_VTPM_FNAME, O_RDWR, TRUE)
!=3D 0) || //FIXME: O_RDONLY?
-       (vtpm_ipc_init(&tx_hp_ipc_h,  VTPM_TX_HP_FNAME, O_RDWR, TRUE) !=3D=

0)    ||
-       (vtpm_ipc_init(&rx_hp_ipc_h,  VTPM_RX_HP_FNAME, O_RDWR, TRUE) !=3D=

0) ) {
+  if (
+#ifndef VTPM_STUBDOM
+       (vtpm_ipc_init(&rx_tpm_ipc_h, VTPM_RX_TPM_FNAME, O_RDONLY, TRUE,
FALSE) !=3D 0) ||
+       (vtpm_ipc_init(&rx_vtpm_ipc_h, VTPM_RX_VTPM_FNAME, O_RDWR, TRUE,
FALSE) !=3D 0) || //FIXME: O_RDONLY?
+#endif
+       (vtpm_ipc_init(&tx_hp_ipc_h,  VTPM_TX_HP_FNAME, O_RDWR, TRUE,
TRUE) !=3D 0)    ||
+       (vtpm_ipc_init(&rx_hp_ipc_h,  VTPM_RX_HP_FNAME, O_RDWR, TRUE,
TRUE) !=3D 0) ) {
     vtpmlogerror(VTPM_LOG_VTPM, "Unable to create initial FIFOs.\n");
     exit(-1);
   }
=20
+#ifndef VTPM_STUBDOM
   g_rx_tpm_ipc_h =3D &rx_tpm_ipc_h;
+#endif
=20
   // -------------------- Set up thread params -------------
=20
@@ -316,10 +170,15 @@ int main(int argc, char **argv) {
   be_thread_params.rx_ipc_h =3D rx_be_ipc_h;
   be_thread_params.fw_tpm =3D TRUE;
   be_thread_params.fw_tx_ipc_h =3D NULL;
+#ifndef VTPM_STUBDOM
   be_thread_params.fw_rx_ipc_h =3D &rx_tpm_ipc_h;
+#else
+  be_thread_params.fw_rx_ipc_h =3D NULL;
+#endif
   be_thread_params.is_priv =3D FALSE;
   be_thread_params.thread_name =3D "Backend Listener";
=20
+#ifndef VTPM_STUBDOM
   dmi_thread_params.tx_ipc_h =3D NULL;
   dmi_thread_params.rx_ipc_h =3D &rx_vtpm_ipc_h;
   dmi_thread_params.fw_tpm =3D FALSE;
@@ -327,6 +186,7 @@ int main(int argc, char **argv) {
   dmi_thread_params.fw_rx_ipc_h =3D NULL;
   dmi_thread_params.is_priv =3D FALSE;
   dmi_thread_params.thread_name =3D "VTPM Listener";
+#endif
=20
   hp_thread_params.tx_ipc_h =3D &tx_hp_ipc_h;
   hp_thread_params.rx_ipc_h =3D &rx_hp_ipc_h;
@@ -335,35 +195,51 @@ int main(int argc, char **argv) {
   hp_thread_params.fw_rx_ipc_h =3D NULL;
   hp_thread_params.is_priv =3D TRUE;
   hp_thread_params.thread_name =3D "Hotplug Listener";
+=20
+  // -------------------- Initialize Manager -----------------
+  if (VTPM_Init_Manager() !=3D TPM_SUCCESS) {
+    vtpmlogerror(VTPM_LOG_VTPM, "Closing vtpmd due to error during
startup.\n");
+    return -1;
+  }
+=20
=20
   // --------------------- Launch Threads -----------------
=20
   vtpm_lock_init();
=20
-  vtpm_globals->master_pid =3D pthread_self();
+  master_thread =3D pthread_self();
+
 =20
   if (pthread_create(&be_thread, NULL, vtpm_manager_thread,
&be_thread_params) !=3D 0) {
     vtpmlogerror(VTPM_LOG_VTPM, "Failed to launch BE Thread.\n");
     exit(-1);
   }
 =20
+#ifndef VTPM_STUBDOM
   if (pthread_create(&dmi_thread, NULL, vtpm_manager_thread,
&dmi_thread_params) !=3D 0) {
     vtpmlogerror(VTPM_LOG_VTPM, "Failed to launch DMI Thread.\n");
     exit(-1);
   }
-
+#endif
=20
   if (pthread_create(&hp_thread, NULL, vtpm_manager_thread,
&hp_thread_params) !=3D 0) {
     vtpmlogerror(VTPM_LOG_VTPM, "Failed to launch HP Thread.\n");
     exit(-1);
   }
=20
+  //Turn signals back on for the master thread only
+  sigemptyset(&sig_mask);
+  sigaddset(&sig_mask, SIGPIPE);
+  pthread_sigmask(SIG_SETMASK, &sig_mask, NULL);
+
   //Join the other threads until exit time.
   pthread_join(be_thread, NULL);
+#ifndef VTPM_STUBDOM
   pthread_join(dmi_thread, NULL);
+#endif
   pthread_join(hp_thread, NULL);
=20
-  vtpmlogerror(VTPM_LOG_VTPM, "VTPM Manager shut down unexpectedly.\n");=

+  vtpmloginfo(VTPM_LOG_VTPM, "VTPM Manager shutting down...\n");
=20
   VTPM_Stop_Manager();
   vtpm_lock_destroy();
diff --git a/tools/vtpm_manager/manager/vtpmpriv.h
b/tools/vtpm_manager/manager/vtpmpriv.h
--- a/tools/vtpm_manager/manager/vtpmpriv.h
+++ b/tools/vtpm_manager/manager/vtpmpriv.h
@@ -40,6 +40,8 @@
 #ifndef __VTPMPRIV_H__
 #define __VTPMPRIV_H__
=20
+#include <signal.h>
+
 #include "vtpm_manager.h"
 #include "tcg.h"
 #include "tcs.h"
@@ -54,16 +56,19 @@
 #define DMI_NVM_FILE       "/var/vtpm/vtpm_dm_%d.data"
 #define VTPM_CTL_DM        0
=20
+extern volatile sig_atomic_t HANDLER_QUIT_FLAG;
+
 // ------------------------ Private Structures -----------------------
 typedef struct VTPM_DMI_RESOURCE_T {
+#ifndef VTPM_STUBDOM
   // I/O info for Manager to talk to DMI's and controllers
   vtpm_ipc_handle_t      *tx_vtpm_ipc_h;    // TX VTPM Results to DMI
   vtpm_ipc_handle_t      *rx_vtpm_ipc_h;    // RX VTPM Commands from DMI=

   vtpm_ipc_handle_t      *tx_tpm_ipc_h;     // TX TPM Commands to DMI
   vtpm_ipc_handle_t      *rx_tpm_ipc_h;     // RX TPM Results from DMI
+
+  pid_t                  dmi_pid;
=20
-#ifndef VTPM_MULTI_VM
-  pid_t                 dmi_pid;
 #endif
=20
   // Non-persistent Information
@@ -77,6 +82,9 @@ typedef struct VTPM_DMI_RESOURCE_T {
   BYTE                  dmi_type;
   TPM_DIGEST            NVM_measurement;  // Equal to the SHA1 of the bl=
ob
   TPM_DIGEST            DMI_measurement;  // Correct measurement of the
owning DMI
+
+  char* uuid;
+
 } VTPM_DMI_RESOURCE;
=20
 typedef struct tdVTPM_MIGKEY_LIST {
@@ -89,10 +97,6 @@ typedef struct tdVTPM_MIGKEY_LIST {
=20
 typedef struct tdVTPM_GLOBALS {
   // Non-persistent data
-#ifndef VTPM_MULTI_VM
-  pid_t               master_pid;
-#endif
-
   int                 connected_dmis;     // To close guest_rx when no
dmis are connected
=20
   struct hashtable    *dmi_map;               // Table of all DMI's
known indexed by persistent instance #
@@ -123,8 +127,8 @@ extern VTPM_GLOBALS *vtpm_globals;   // Key info and
DMI states
 extern const TPM_AUTHDATA SRK_AUTH;  // SRK Well Known Auth Value
=20
 // ********************** VTPM Functions *************************
-TPM_RESULT VTPM_Init_Manager(); // Start VTPM Service
-void VTPM_Stop_Manager();  // Stop VTPM Service
+TPM_RESULT VTPM_Init_Manager(void); // Start VTPM Service
+void VTPM_Stop_Manager(void);  // Stop VTPM Service
 TPM_RESULT VTPM_Manager_Handler(vtpm_ipc_handle_t *tx_ipc_h,
                                 vtpm_ipc_handle_t *rx_ipc_h,
                                 BOOL fw_tpm,   // Should forward TPM cmd=
s
@@ -143,6 +147,11 @@ TPM_RESULT VTPM_Handle_Save_NVM(     =20
VTPM_DMI_RESOURCE *myDMI,
                                         const buffer_t *inbuf,
                                         buffer_t *outbuf);
=20
+TPM_RESULT VTPM_Handle_Get_NVM_Size(   VTPM_DMI_RESOURCE *myDMI,
+                                        const buffer_t *inbuf,
+                                        buffer_t *outbuf);
+
+
 TPM_RESULT VTPM_Handle_TPM_Command(    VTPM_DMI_RESOURCE *dmi,
                                         buffer_t *inbuf,
                                         buffer_t *outbuf);
@@ -173,6 +182,9 @@ TPM_RESULT VTPM_Close_DMI_Extra(VTPM_DMI_RESOURCE
*dmi_res);
 TPM_RESULT close_dmi(VTPM_DMI_RESOURCE *dmi_res);
 TPM_RESULT init_dmi(UINT32 dmi_id, BYTE type,  VTPM_DMI_RESOURCE
**dmi_res);
=20
+/* Free's dmi_res and all of it's resources */
+void free_dmi(VTPM_DMI_RESOURCE *dmi_res);
+
 TPM_RESULT envelope_encrypt(const buffer_t     *inbuf,
                              CRYPTO_INFO        *asymkey,
                              buffer_t           *sealed_data);
@@ -183,4 +195,14 @@ TPM_RESULT envelope_decrypt(const buffer_t     *ciph=
er,
                             const TPM_AUTHDATA *key_usage_auth,
                             buffer_t           *unsealed_data);
=20
+TPM_RESULT symkey_encrypt(const buffer_t     *inbuf,
+                            CRYPTO_INFO        *asymkey,
+                            buffer_t           *sealed_key);
+
+TPM_RESULT symkey_decrypt(const buffer_t     *cipher,
+                            TCS_CONTEXT_HANDLE TCSContext,
+                TPM_HANDLE         keyHandle,
+                const TPM_AUTHDATA *key_usage_auth,
+                            buffer_t           *symkey_clear);
+
 #endif // __VTPMPRIV_H__
diff --git a/tools/vtpm_manager/manager/vtsp.c
b/tools/vtpm_manager/manager/vtsp.c
--- a/tools/vtpm_manager/manager/vtsp.c
+++ b/tools/vtpm_manager/manager/vtsp.c
@@ -38,6 +38,7 @@
 // =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
=20
 #include <string.h>
+#include <stdlib.h>
 #include "tcg.h"
 #include "tcs.h"
 #include "bsg.h"
@@ -312,7 +313,7 @@ TPM_RESULT VTSP_TakeOwnership(   const
TCS_CONTEXT_HANDLE hContext,
   TPM_PROTOCOL_ID proto_id =3D TPM_PID_OWNER;
   BYTE *new_srk;
 =20
-  BYTE *paramText;        // Digest to make Auth.
+  BYTE *paramText =3D NULL;        // Digest to make Auth.
   UINT32 paramTextSize;
 =20
   // vars for srkpubkey parameter
@@ -458,7 +459,7 @@ TPM_RESULT VTSP_CreateWrapKey(  const
TCS_CONTEXT_HANDLE hContext,
   vtpmloginfo(VTPM_LOG_VTSP, "Creating new key of type %d.\n", usage);
 =20
   // vars for Calculate encUsageAuth
-  BYTE *paramText;    =20
+  BYTE *paramText =3D NULL;
   UINT32 paramTextSize;
 =20
   // vars for Calculate encUsageAuth
@@ -567,8 +568,7 @@ TPM_RESULT VTSP_CreateWrapKey(  const
TCS_CONTEXT_HANDLE hContext,
                 osapSharedSecret, auth, 0) );
 =20
   // Unpack/return key structure
-  TPMTRYRETURN(buffer_init(pubKeyBuf, 0, 0) );
-  TPMTRYRETURN(buffer_append_raw(pubKeyBuf, newKeyText.size,
newKeyText.data) );
+  TPMTRYRETURN(buffer_init(pubKeyBuf, newKeyText.size, newKeyText.data) =
);
 =20
   goto egress;
 =20
@@ -664,6 +664,7 @@ TPM_RESULT VTSP_LoadKey(const TCS_CONTEXT_HANDLE  =20
hContext,
   =20
     // Destroy rsaKeyParms
     BSG_Destroy(BSG_TPM_RSA_KEY_PARMS, &rsaKeyParms);
+    BSG_Destroy(BSG_TPM_KEY, &newKey);
   =20
     // Set encryption scheme
     cryptoinfo->encScheme =3D CRYPTO_ES_RSAESOAEP_SHA1_MGF1;
@@ -733,8 +734,7 @@ TPM_RESULT VTSP_Unbind( const TCS_CONTEXT_HANDLE  =20
hContext,
                 hContext) );
 =20
   // Unpack/return key structure
-  TPMTRYRETURN(buffer_init(clear_data, 0, 0));
-  TPMTRYRETURN(buffer_append_raw (clear_data, clear_data_size,
clear_data_text) );
+  TPMTRYRETURN(buffer_init(clear_data, clear_data_size, clear_data_text)=
 );
 =20
   goto egress;
 =20
@@ -793,8 +793,7 @@ TPM_RESULT VTSP_Bind(   CRYPTO_INFO *cryptoInfo,
     vtpmlogerror(VTPM_LOG_VTSP, "Enc buffer just overflowed.\n");
   }
 =20
-  buffer_init(outData, 0, NULL);
-  buffer_append_raw(outData, out_tmp_size, out_tmp);
+  buffer_init(outData, out_tmp_size, out_tmp);
 =20
   vtpmloginfo(VTPM_LOG_TXDATA, "Bind Generated[%d] =3D 0x", out_tmp_size=
);
   for(i =3D 0 ; i < out_tmp_size ; i++) {
@@ -1005,8 +1004,6 @@ TPM_RESULT VTSP_SaveState( const
TCS_CONTEXT_HANDLE    hContext) {
=20
   vtpmloginfo(VTPM_LOG_VTSP, "Calling TPM_SaveState.\n");
=20
-  TPM_RESULT status =3D TPM_SUCCESS;
-
   // Call TCS
   return ( TCSP_SaveState ( hContext ) );
=20
@@ -1040,3 +1037,4 @@ TPM_RESULT VTSP_RawTransmit(const
TCS_CONTEXT_HANDLE    hContext,
   free(resultText);
   return status;
 }
+
diff --git a/tools/vtpm_manager/manager/vtsp.h
b/tools/vtpm_manager/manager/vtsp.h
--- a/tools/vtpm_manager/manager/vtsp.h
+++ b/tools/vtpm_manager/manager/vtsp.h
@@ -42,6 +42,7 @@
=20
 #include "tcg.h"
 #include "tcs.h"
+#include "crypto.h"
=20
 #define KEY_BUFFER_SIZE 2048
=20
diff --git a/tools/vtpm_manager/migration/Makefile
b/tools/vtpm_manager/migration/Makefile
--- a/tools/vtpm_manager/migration/Makefile
+++ b/tools/vtpm_manager/migration/Makefile
@@ -1,5 +1,11 @@
-XEN_ROOT =3D $(CURDIR)/../../..
-include $(XEN_ROOT)/tools/vtpm_manager/Rules.mk
+XEN_ROOT =3D $(realpath ../../..)
+include ../Rules.mk
+
+CFLAGS +=3D -I../crypto
+CFLAGS +=3D -I../util
+CFLAGS +=3D -I../tcs
+CFLAGS +=3D -I../manager
+
=20
 VPATH =3D ../manager
=20
@@ -33,10 +39,10 @@ mrproper: clean
     rm -f *~
=20
 $(BIND): $(OBJSD)
-    $(CC) $(LDFLAGS) $^ $(LIBS) -o $@
+    $(CC) $(CFLAGS) $(LDFLAGS) $^ $(LIBS) -o $@
=20
 $(BINC): $(OBJSC)
-    $(CC) $(LDFLAGS) $^ $(LIBS) -o $@
+    $(CC) $(CFLAGS) $(LDFLAGS) $^ $(LIBS) -o $@
=20
 # libraries
 LIBS +=3D ../util/libTCGUtils.a
diff --git a/tools/vtpm_manager/migration/vtpm_manager_if.c
b/tools/vtpm_manager/migration/vtpm_manager_if.c
--- a/tools/vtpm_manager/migration/vtpm_manager_if.c
+++ b/tools/vtpm_manager/migration/vtpm_manager_if.c
@@ -50,15 +50,12 @@
 #include "vtpm_migrator.h"
 #include "vtpm_manager.h"
=20
-#define VTPM_TX_HP_FNAME       "/var/vtpm/fifos/from_console.fifo"
-#define VTPM_RX_HP_FNAME       "/var/vtpm/fifos/to_console.fifo"
-
 static vtpm_ipc_handle_t tx_ipc_h, rx_ipc_h;
=20
 TPM_RESULT vtpm_manager_open(){
=20
-  if ( (vtpm_ipc_init(&tx_ipc_h,  VTPM_TX_HP_FNAME, O_RDWR, TRUE) !=3D 0=
)
||  //FIXME: wronly
-       (vtpm_ipc_init(&rx_ipc_h,  VTPM_RX_HP_FNAME, O_RDWR, TRUE) !=3D 0=
)
) { //FIXME: rdonly
+  if ( (vtpm_ipc_init(&tx_ipc_h,  VTPM_TX_HP_FNAME, O_RDWR, TRUE, TRUE)
!=3D 0) ||  //FIXME: wronly
+       (vtpm_ipc_init(&rx_ipc_h,  VTPM_RX_HP_FNAME, O_RDWR, TRUE, TRUE)
!=3D 0) ) { //FIXME: rdonly
     vtpmlogerror(VTPM_LOG_VTPM, "Unable to connect to vtpm_manager.\n");=

     return TPM_IOERROR;
   }
diff --git a/tools/vtpm_manager/tcs/Makefile
b/tools/vtpm_manager/tcs/Makefile
--- a/tools/vtpm_manager/tcs/Makefile
+++ b/tools/vtpm_manager/tcs/Makefile
@@ -1,5 +1,10 @@
-XEN_ROOT =3D $(CURDIR)/../../..
-include $(XEN_ROOT)/tools/vtpm_manager/Rules.mk
+XEN_ROOT =3D $(realpath ../../..)
+include ../Rules.mk
+
+CFLAGS +=3D -I../crypto
+CFLAGS +=3D -I../util
+CFLAGS +=3D -I../manager
+
=20
 BIN        =3D libTCS.a
=20
diff --git a/tools/vtpm_manager/tcs/contextmgr.c
b/tools/vtpm_manager/tcs/contextmgr.c
--- a/tools/vtpm_manager/tcs/contextmgr.c
+++ b/tools/vtpm_manager/tcs/contextmgr.c
@@ -195,6 +195,7 @@ BOOL DeleteHandleFromList(   TCS_CONTEXT_HANDLE
hContext, // in
=20
 BOOL FreeHandleList(    CONTEXT_HANDLE*     pContextHandle) { // in
   HANDLE_LIST* pCurrentHandle;
+  HANDLE_LIST* pNext;
   BOOL returncode =3D TRUE;
 =20
   vtpmloginfo(VTPM_LOG_TCS_DEEP, "Freeing all handles for context\n");
@@ -205,6 +206,7 @@ BOOL FreeHandleList(    CONTEXT_HANDLE*   =20
pContextHandle) { // in
   pCurrentHandle =3D pContextHandle->pHandleList;
   while (pCurrentHandle !=3D NULL) {
   =20
+    pNext =3D pCurrentHandle->pNextHandle;
     switch (pCurrentHandle->type) {
     case TPM_RT_KEY:
       returncode =3D returncode && !TCSP_EvictKey(pContextHandle->handle=
,
pCurrentHandle->handle);
@@ -216,7 +218,7 @@ BOOL FreeHandleList(    CONTEXT_HANDLE*   =20
pContextHandle) { // in
       returncode =3D FALSE;
     }
   =20
-    pCurrentHandle =3D pCurrentHandle->pNextHandle;
+    pCurrentHandle =3D pNext;
   =20
   }
 =20
diff --git a/tools/vtpm_manager/tcs/tcs.c b/tools/vtpm_manager/tcs/tcs.c
--- a/tools/vtpm_manager/tcs/tcs.c
+++ b/tools/vtpm_manager/tcs/tcs.c
@@ -77,7 +77,7 @@ CONTEXT_HANDLE *LookupContext( TCS_CONTEXT_HANDLE=20
hContext) {
 //
-------------------------------------------------------------------------=
--------
 // Initialization/Uninitialization SubComponent API
 //
-------------------------------------------------------------------------=
--------
-TPM_RESULT TCS_create() {
+TPM_RESULT TCS_create(void) {
   TDDL_RESULT hRes =3D TDDL_E_FAIL;
   TPM_RESULT result =3D TPM_FAIL;
 =20
@@ -101,7 +101,7 @@ TPM_RESULT TCS_create() {
 }
=20
=20
-void TCS_destroy()
+void TCS_destroy(void)
 {
   TCS_m_nCount--;
 =20
@@ -113,14 +113,13 @@ void TCS_destroy()
     TCS_CONTEXT_HANDLE  *hContext;
   =20
     // Close all the TCS contexts. TCS should evict keys based on this
-    if (hashtable_count(context_ht) > 0) {
+    while (hashtable_count(context_ht) > 0) {
       context_itr =3D hashtable_iterator(context_ht);
-      do {
-        hContext =3D (TCS_CONTEXT_HANDLE *)
hashtable_iterator_key(context_itr);
-    if (TCS_CloseContext(*hContext) !=3D TPM_SUCCESS)
-        vtpmlogerror(VTPM_LOG_TCS, "Failed to close context %d
properly.\n", *hContext);
+
+      hContext =3D (TCS_CONTEXT_HANDLE *)
hashtable_iterator_key(context_itr);
+      if (TCS_CloseContext(*hContext) !=3D TPM_SUCCESS)
+        vtpmlogerror(VTPM_LOG_TCS, "Failed to close context %d
properly.\n", *hContext);
     =20
-      } while (hashtable_iterator_advance(context_itr));
       free(context_itr);
     }
     hashtable_destroy(context_ht, 1);
@@ -534,6 +533,10 @@ TPM_RESULT TCSP_TerminateHandle(TCS_CONTEXT_HANDLE
hContext, // in
               BSG_TYPE_UINT32, &handle);
   // fill paramSize again as we now have the correct size
   BSG_Pack(BSG_TYPE_UINT32, &InLength, InBuf+2);
+
+  if (!DeleteHandleFromList(hContext, handle)) {
+    vtpmlogerror(VTPM_LOG_TCS, "KeyHandle not removed from list\n");
+  }
 =20
   // call the TPM driver
   if ((hRes =3D TDDL_TransmitData(InBuf, InLength, OutBuf, &OutLength))
@@ -545,9 +548,6 @@ TPM_RESULT TCSP_TerminateHandle(TCS_CONTEXT_HANDLE
hContext, // in
                BSG_TYPE_UINT32, &paramSize,
                BSG_TPM_COMMAND_CODE, &returnCode);
   =20
-    if (!DeleteHandleFromList(hContext, handle))
-      vtpmlogerror(VTPM_LOG_TCS, "KeyHandle not removed from list\n");
-     =20
   =20
     if (returnCode =3D=3D TPM_SUCCESS && tag =3D=3D TPM_TAG_RSP_COMMAND)=
 {
       // Print debug info
@@ -882,6 +882,7 @@ TPM_RESULT TCSP_CreateWrapKey(TCS_CONTEXT_HANDLE
hContext,   // in
     =20
       memcpy(*prgbKey, tempBuf, *pcKeySize);
     =20
+      BSG_Destroy(BSG_TPM_KEY, &wrappedKey);
       vtpmloginfo(VTPM_LOG_TCS_DEEP, "Received paramSize : %d\n",
paramSize);
     } else
       vtpmlogerror(VTPM_LOG_TCS, "TCSP_CreateWrapKey Failed with return
code %s\n", tpm_get_error_name(returnCode));
@@ -980,6 +981,10 @@ TPM_RESULT TCSP_EvictKey(TCS_CONTEXT_HANDLE
hContext, // in
   BSG_Pack(BSG_TYPE_UINT32, &InLength, InBuf+2);
 =20
   vtpmloginfo(VTPM_LOG_TCS_DEEP, "Sending paramSize =3D %d\n", InLength)=
;
+
+  if (!DeleteHandleFromList(hContext, hKey)) {
+    vtpmlogerror(VTPM_LOG_TCS, "KeyHandle not removed from list\n");
+  }    =20
 =20
   // call the TPM driver
   if ((hRes =3D TDDL_TransmitData(InBuf, InLength, OutBuf, &OutLength))
=3D=3D TDDL_SUCCESS) {
@@ -989,10 +994,6 @@ TPM_RESULT TCSP_EvictKey(TCS_CONTEXT_HANDLE
hContext, // in
                BSG_TYPE_UINT32, &paramSize,
                BSG_TPM_COMMAND_CODE, &returnCode);
   =20
-    if (!DeleteHandleFromList(hContext, hKey)) {
-      vtpmlogerror(VTPM_LOG_TCS, "KeyHandle not removed from list\n");
-    }    =20
-  =20
     if (returnCode =3D=3D TPM_SUCCESS && tag =3D=3D TPM_TAG_RSP_COMMAND)=
 {
       vtpmloginfo(VTPM_LOG_TCS_DEEP, "Received paramSize : %d\n",
paramSize);
     } else {
@@ -1019,7 +1020,7 @@ TPM_RESULT TCSP_GetRandom(TCS_CONTEXT_HANDLE
hContext,  // in
   TDDL_UINT32  OutLength =3D TCPA_MAX_BUFFER_LENGTH;
 =20
   // check input params
-  if (bytesRequested =3D=3D NULL || *randomBytes =3D=3D NULL){
+  if (bytesRequested =3D=3D NULL || randomBytes =3D=3D NULL){
     return TPM_BAD_PARAMETER;
   }
 =20
diff --git a/tools/vtpm_manager/tcs/tcs.h b/tools/vtpm_manager/tcs/tcs.h
--- a/tools/vtpm_manager/tcs/tcs.h
+++ b/tools/vtpm_manager/tcs/tcs.h
@@ -50,8 +50,8 @@
 // Exposed API
 // ------------------------------------------------------------------
=20
-TPM_RESULT TCS_create();
-void TCS_destroy();
+TPM_RESULT TCS_create(void);
+void TCS_destroy(void);
=20
 TPM_RESULT TCS_OpenContext( /* OUT */ TCS_CONTEXT_HANDLE* hContext );
=20
diff --git a/tools/vtpm_manager/tcs/tpmddl.c
b/tools/vtpm_manager/tcs/tpmddl.c
--- /dev/null
+++ b/tools/vtpm_manager/tcs/tpmddl.c
@@ -0,0 +1,168 @@
+/*
+ * Copyright (c) 2010-2012 United States Government, as represented by
+ * the Secretary of Defense.  All rights reserved.
+ *
+ * THIS SOFTWARE AND ITS DOCUMENTATION ARE PROVIDED AS IS AND WITHOUT
+ * ANY EXPRESS OR IMPLIED WARRANTIES WHATSOEVER. ALL WARRANTIES
+ * INCLUDING, BUT NOT LIMITED TO, PERFORMANCE, MERCHANTABILITY, FITNESS
+ * FOR A PARTICULAR  PURPOSE, AND NONINFRINGEMENT ARE HEREBY
+ * DISCLAIMED. USERS ASSUME THE ENTIRE RISK AND LIABILITY OF USING THE
+ * SOFTWARE.
+ */
+
+#include <string.h>
+#include "tpmddl.h"
+#include "tcs.h"
+#include "bsg.h"
+#include "log.h"
+
+#define MIN(X,Y) ((X) < (Y) ? (X) : (Y))
+
+TDDL_RESULT TDDL_GetCapability( TDDL_UINT32 cap,
+      TDDL_UINT32 sub,
+      TDDL_BYTE* buffer,
+      TDDL_UINT32* size)
+{
+   TDDL_RESULT status;
+
+   TPM_TAG tag =3D TPM_TAG_RQU_COMMAND;
+   UINT32 paramsize =3D 22;
+   UINT32 outsize;
+   TPM_COMMAND_CODE ord =3D TPM_ORD_GetCapability;
+   UINT32 subcapsize =3D 4;
+
+   BYTE inbuf[TCPA_MAX_BUFFER_LENGTH];
+   BYTE outbuf[TCPA_MAX_BUFFER_LENGTH];
+
+   int offset;
+
+   BSG_PackList(inbuf, 6,
+     BSG_TPM_TAG, &(tag),
+     BSG_TYPE_UINT32, &(paramsize),
+     BSG_TPM_COMMAND_CODE, &(ord),
+     BSG_TYPE_UINT32, &(cap),
+     BSG_TYPE_UINT32, &(subcapsize),
+     BSG_TYPE_UINT32, &(sub)
+     );
+
+   //Send the command, get the response
+   TPMTRYRETURN(TDDL_TransmitData( inbuf, paramsize, outbuf, &outsize));=

+
+   offset =3D BSG_UnpackList(outbuf, 4,
+     BSG_TPM_TAG, &(tag),
+     BSG_TYPE_UINT32, &(paramsize),
+     BSG_TPM_RESULT, &(status),
+     BSG_TYPE_UINT32, size
+     );
+   if (status !=3D TPM_SUCCESS || tag !=3D TPM_TAG_RSP_COMMAND) {
+      return status;
+   }
+   if(*size >=3D TCPA_MAX_BUFFER_LENGTH - offset) {
+      return TPM_FAIL;
+   }
+   memcpy(buffer, outbuf + offset, *size);
+
+abort_egress:
+   return status;
+}
+
+TDDL_RESULT TDDL_FlushSpecific(TDDL_UINT32 handle, TDDL_UINT32 res) {
+    /* FIXME: Add code here to check if TPM_FlushSpecific is not
supported (on 1.1 only TPMS?)
+    * If this is the case then we need to use TPM_EvictKey for key handl=
es
+    * and TPM_Terminate_Handle/TPM_Reset for auth handles */
+   TDDL_RESULT status;
+
+   TPM_TAG tag =3D TPM_TAG_RQU_COMMAND;
+   UINT32 paramsize =3D 18;
+   TPM_COMMAND_CODE ord =3D TPM_ORD_FlushSpecific;
+
+   BYTE inbuf[TCPA_MAX_BUFFER_LENGTH];
+   BYTE outbuf[TCPA_MAX_BUFFER_LENGTH];
+   UINT32 outsize;
+
+   int offset;
+
+   BSG_PackList(inbuf, 5,
+     BSG_TPM_TAG, &(tag),
+     BSG_TYPE_UINT32, &(paramsize),
+     BSG_TPM_COMMAND_CODE, &(ord),
+     BSG_TPM_HANDLE, &(handle),
+     BSG_TPM_RESOURCE_TYPE, &(res)
+     );
+
+   //Send command
+   TPMTRYRETURN(TDDL_TransmitData( inbuf, paramsize, outbuf, &outsize ))=
;
+
+   offset =3D BSG_UnpackList(outbuf, 4,
+     BSG_TPM_TAG, &(tag),
+     BSG_TYPE_UINT32, &(paramsize),
+     BSG_TPM_RESULT, &(status)
+     );
+
+abort_egress:
+   return status;
+ =20
+}
+
+TDDL_RESULT TDDL_FlushAllResources(void) {
+  TDDL_RESULT status =3D TPM_SUCCESS;
+
+  TDDL_BYTE buf[TCPA_MAX_BUFFER_LENGTH];
+  TDDL_UINT32 bufsiz;
+
+  UINT16 packedsz;
+  int size;
+  UINT32 handle;
+  BYTE* ptr;
+
+  int i, j;
+
+#define RLISTSZ 6
+  TPM_RESOURCE_TYPE reslist[RLISTSZ] =3D { TPM_RT_KEY, TPM_RT_AUTH,
TPM_RT_TRANS, TPM_RT_COUNTER, TPM_RT_DAA_TPM, TPM_RT_CONTEXT };
+
+  //Iterate through each resource type and flush all handles
+  for(i =3D 0; i < RLISTSZ; ++i) {
+     TPM_RESOURCE_TYPE res =3D reslist[i];
+     // Get list of current key handles
+     if((status =3D TDDL_GetCapability( TPM_CAP_HANDLE, res, buf,
&bufsiz)) !=3D TPM_SUCCESS) {
+    //This can happen if the resource type is not supported
+    //If this happens just silently skip the resource type
+    if(status =3D=3D TPM_BAD_MODE) {
+       status =3D TPM_SUCCESS;
+       continue;
+    //Otherwise we just fail
+    } else {
+       TPMTRYRETURN(status);
+    }
+     }
+
+#if 0
+     //DEBUG PRINTOUTS
+     printf("TPM_GetCapability(TPM_CAP_HANDLE, %lu)\n", (unsigned long)
res);
+     for(j =3D 0; j < bufsiz; ++j) {
+    printf("%02X ", buf[j]);
+     }
+     printf("\n");
+#endif
+
+     ptr =3D buf;
+     ptr +=3D BSG_Unpack(BSG_TYPE_UINT16, ptr, &(packedsz));
+     size =3D packedsz;
+
+     //Flush each handle
+     if(size) {
+    vtpmloginfo(VTPM_LOG_VTPM, "Flushing %u handle(s) of type %lu\n",
size, (unsigned long) res);
+    for(j =3D 0; j < size; ++j) {
+       ptr +=3D BSG_Unpack(BSG_TPM_HANDLE, ptr, &(handle));
+       TPMTRYRETURN(TDDL_FlushSpecific(handle, res));
+    }
+     }
+
+  }
+
+  goto egress;
+abort_egress:
+egress:
+  return status;
+}
+
diff --git a/tools/vtpm_manager/tcs/tpmddl.h
b/tools/vtpm_manager/tcs/tpmddl.h
--- a/tools/vtpm_manager/tcs/tpmddl.h
+++ b/tools/vtpm_manager/tcs/tpmddl.h
@@ -50,13 +50,14 @@ typedef unsigned int TDDL_UINT32;
 typedef TDDL_UINT32 TDDL_RESULT;
 typedef unsigned char TDDL_BYTE;
=20
-TDDL_RESULT TDDL_Open();
-void TDDL_Close();
+TDDL_RESULT TDDL_Open(void);
+TDDL_RESULT TDDL_Open_use_fd(int fd);
+void TDDL_Close(void);
 TDDL_RESULT TDDL_TransmitData( TDDL_BYTE* in,
                    TDDL_UINT32 insize,
                    TDDL_BYTE* out,
                    TDDL_UINT32* outsize);
-TDDL_RESULT TDDL_GetStatus();
+TDDL_RESULT TDDL_GetStatus(void);
 TDDL_RESULT TDDL_GetCapability( TDDL_UINT32 cap,
                 TDDL_UINT32 sub,
                 TDDL_BYTE* buffer,
@@ -66,4 +67,10 @@ TDDL_RESULT TDDL_SetCapability( TDDL_UINT32 cap,
                 TDDL_BYTE* buffer,
                 TDDL_UINT32* size);
=20
+TDDL_RESULT TDDL_FlushSpecific(TDDL_UINT32 handle,
+                TDDL_UINT32 res);
+
+TDDL_RESULT TDDL_FlushAllResources(void);
+
+
 #endif // __TPMDDL_H__
diff --git a/tools/vtpm_manager/tcs/transmit.c
b/tools/vtpm_manager/tcs/transmit.c
--- a/tools/vtpm_manager/tcs/transmit.c
+++ b/tools/vtpm_manager/tcs/transmit.c
@@ -104,12 +104,13 @@ TDDL_TransmitData( TDDL_BYTE* in,
   return status;
 }
=20
-TPM_RESULT TDDL_Open() {
+TDDL_RESULT TDDL_Open(void) {
 =20
   TDDL_RESULT status =3D TDDL_SUCCESS;
 =20
+  /* If tpm device is already open just silently return success */
   if (g_TDDL_open)
-    return TPM_FAIL;
+    return TPM_SUCCESS;
=20
 #ifdef DUMMY_TPM=20
   *g_rx_fdp =3D open (TPM_RX_FNAME, O_RDWR);
@@ -117,7 +118,7 @@ TPM_RESULT TDDL_Open() {
=20
   g_tx_fd =3D open (TPM_TX_FNAME, O_RDWR);
   if (g_tx_fd < 0) {
-    vtpmlogerror(VTPM_LOG_TXDATA, "TPM open failed");
+    vtpmlogerror(VTPM_LOG_TXDATA, "TPM open failed\n");
     return TPM_IOERROR;
   }
 =20
@@ -126,7 +127,20 @@ TPM_RESULT TDDL_Open() {
   return status;
 }
=20
-void TDDL_Close() {
+TDDL_RESULT TDDL_Open_use_fd(int fd) {
+   TDDL_RESULT status =3D TDDL_SUCCESS;
+
+   if(g_TDDL_open)
+      return TPM_FAIL;
+
+   g_tx_fd =3D fd;
+
+   g_TDDL_open =3D 1;
+
+   return status;
+}
+
+void TDDL_Close(void) {
   if (! g_TDDL_open)
         return;
=20
diff --git a/tools/vtpm_manager/util/Makefile
b/tools/vtpm_manager/util/Makefile
--- a/tools/vtpm_manager/util/Makefile
+++ b/tools/vtpm_manager/util/Makefile
@@ -1,5 +1,10 @@
-XEN_ROOT =3D $(CURDIR)/../../..
-include $(XEN_ROOT)/tools/vtpm_manager/Rules.mk
+XEN_ROOT =3D $(realpath ../../..)
+include ../Rules.mk
+
+CFLAGS +=3D -I../crypto
+CFLAGS +=3D -I../tcs
+CFLAGS +=3D -I../manager
+
=20
 BIN        =3D libTCGUtils.a
=20
diff --git a/tools/vtpm_manager/util/bsg.c b/tools/vtpm_manager/util/bsg.=
c
--- a/tools/vtpm_manager/util/bsg.c
+++ b/tools/vtpm_manager/util/bsg.c
@@ -41,6 +41,7 @@
 #include <string.h>
 #include <stdarg.h>
 #include <malloc.h>
+#include <stdlib.h>
 #include "tcg.h"
 #include "crypto.h"
 #include "bsg.h"
@@ -317,7 +318,7 @@ static const BSG_Format* find_format (BSG_Type t) {
 // FIXME: should have a function be passed in here which is called if
the test
 // fails. Then the caller can decide what to do: abort, notify, whatever=

 //
-BOOL BSG_static_selfcheck ()
+BOOL BSG_static_selfcheck (void)
 {
   int i;
=20
diff --git a/tools/vtpm_manager/util/bsg.h b/tools/vtpm_manager/util/bsg.=
h
--- a/tools/vtpm_manager/util/bsg.h
+++ b/tools/vtpm_manager/util/bsg.h
@@ -161,6 +161,6 @@ TPM_RESULT BSG_DestroyTuple (int numParams,
pack_tuple_t params[]);
 void BSG_PackConst(BSG_UINT32 val, int size, BSG_BYTE* dst);
 BSG_UINT32 BSG_UnpackConst(const BSG_BYTE* src, int size);
=20
-BOOL BSG_static_selfcheck ();
+BOOL BSG_static_selfcheck (void);
=20
 #endif
diff --git a/tools/vtpm_manager/util/buffer.c
b/tools/vtpm_manager/util/buffer.c
--- a/tools/vtpm_manager/util/buffer.c
+++ b/tools/vtpm_manager/util/buffer.c
@@ -40,6 +40,7 @@
=20
 #include "tcg.h"
 #include "bsg.h"
+#include "log.h"
 #include "buffer.h"
=20
 static TPM_RESULT buffer_priv_realloc (buffer_t * buf, tpm_size_t newsiz=
e);
@@ -51,6 +52,7 @@ static TPM_RESULT buffer_priv_realloc (buffer_t * buf,
tpm_size_t newsize);
 TPM_RESULT buffer_init (buffer_t * buf, tpm_size_t initsize, const
BYTE* initval) {
   if (initsize =3D=3D 0) {
     memset(buf, 0, sizeof(*buf));
+    buf->bytes =3D NULL;
     return TPM_SUCCESS;
   }
 =20
@@ -62,8 +64,11 @@ TPM_RESULT buffer_init (buffer_t * buf, tpm_size_t
initsize, const BYTE* initval
   buf->size =3D initsize;
   buf->alloc_size =3D initsize;
 =20
-  if (initval)
+  if (initval) {
     memcpy (buf->bytes, initval, initsize);
+  } else {
+     memset(buf->bytes, 0, initsize);
+  }
 =20
   buf->is_owner =3D TRUE;
 =20
@@ -190,6 +195,29 @@ TPM_RESULT buffer_append_raw (buffer_t * buf,
tpm_size_t len, const BYTE* bytes)
   return status;
 }
=20
+TPM_RESULT buffer_prepend_raw(buffer_t * buf, tpm_size_t len, const
BYTE* bytes) {
+  TPM_RESULT status =3D TPM_SUCCESS;
+
+  if (buf->alloc_size < buf->size + len) {
+    TPMTRYRETURN( buffer_priv_realloc (buf, buf->size + len) );
+  }
+
+  if(buf->size > 0) {
+    memmove(buf->bytes + len, buf->bytes, buf->size);
+  }
+  memcpy(buf->bytes, bytes, len);
+
+  buf->size +=3D len;
+
+  goto egress;
+
+ abort_egress:
+
+ egress:
+
+  return status;
+}
+
 tpm_size_t buffer_len (const buffer_t* buf) {
   return buf->size;
 }
@@ -199,7 +227,6 @@ TPM_RESULT buffer_free (buffer_t * buf) {
     free (buf->bytes);
     buf->bytes =3D NULL;
     buf->size =3D buf->alloc_size =3D 0;
- =20
   }
 =20
   return TPM_SUCCESS;
@@ -224,3 +251,13 @@ TPM_RESULT buffer_priv_realloc (buffer_t * buf,
tpm_size_t newsize) {
 =20
   return TPM_SUCCESS;
 }
+
+TPM_RESULT buffer_truncate(buffer_t* buf, tpm_size_t len)
+{
+   if(len <=3D buf->size) {
+      buf->size =3D len;
+      return TPM_SUCCESS;
+   }
+
+   return TPM_FAIL;
+}
diff --git a/tools/vtpm_manager/util/buffer.h
b/tools/vtpm_manager/util/buffer.h
--- a/tools/vtpm_manager/util/buffer.h
+++ b/tools/vtpm_manager/util/buffer.h
@@ -92,4 +92,9 @@ TPM_RESULT buffer_free (buffer_t * buf);
=20
 TPM_RESULT buffer_append_raw (buffer_t * buf, tpm_size_t len, const
BYTE* bytes);
=20
+TPM_RESULT buffer_prepend_raw(buffer_t * buf, tpm_size_t len, const
BYTE* bytes);
+
+//Reduce the size of the buffer, if len > buffer size returns an error
+TPM_RESULT buffer_truncate(buffer_t* buf, tpm_size_t len);
+
 #endif // _TOOLS_H_
diff --git a/tools/vtpm_manager/util/hashtable.c
b/tools/vtpm_manager/util/hashtable.c
--- a/tools/vtpm_manager/util/hashtable.c
+++ b/tools/vtpm_manager/util/hashtable.c
@@ -32,12 +32,6 @@
  * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
 */
=20
-/*
- * There are duplicates of this code in:
- *  - tools/xenstore/hashtable.c
- *  - tools/blktap2/drivers/hashtable.c
- */
-
 #include "hashtable.h"
 #include "hashtable_private.h"
 #include <stdlib.h>
diff --git a/tools/vtpm_manager/util/hashtable.h
b/tools/vtpm_manager/util/hashtable.h
--- a/tools/vtpm_manager/util/hashtable.h
+++ b/tools/vtpm_manager/util/hashtable.h
@@ -32,11 +32,6 @@
  * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
 */
=20
-/*
- * There are duplicates of this code in:
- *  - tools/xenstore/hashtable.h
- *  - tools/blktap2/drivers/hashtable.h
- */
=20
 #ifndef __HASHTABLE_CWC22_H__
 #define __HASHTABLE_CWC22_H__
diff --git a/tools/vtpm_manager/util/hashtable_itr.c
b/tools/vtpm_manager/util/hashtable_itr.c
--- a/tools/vtpm_manager/util/hashtable_itr.c
+++ b/tools/vtpm_manager/util/hashtable_itr.c
@@ -32,11 +32,6 @@
  * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
 */
=20
-/*
- * There are duplicates of this code in:
- *  - tools/blktap2/drivers/hashtable_itr.c
- */
-
 #include "hashtable.h"
 #include "hashtable_private.h"
 #include "hashtable_itr.h"
diff --git a/tools/vtpm_manager/util/hashtable_itr.h
b/tools/vtpm_manager/util/hashtable_itr.h
--- a/tools/vtpm_manager/util/hashtable_itr.h
+++ b/tools/vtpm_manager/util/hashtable_itr.h
@@ -32,11 +32,6 @@
  * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
 */
=20
-/*
- * There are duplicates of this code in:
- *  - tools/blktap2/drivers/hashtable_itr.h
- */
-
=20
 #ifndef __HASHTABLE_ITR_CWC22__
 #define __HASHTABLE_ITR_CWC22__
diff --git a/tools/vtpm_manager/util/hashtable_private.h
b/tools/vtpm_manager/util/hashtable_private.h
--- a/tools/vtpm_manager/util/hashtable_private.h
+++ b/tools/vtpm_manager/util/hashtable_private.h
@@ -32,12 +32,6 @@
  * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
 */
=20
-/*
- * There are duplicates of this code in:
- *  - tools/xenstore/hashtable_private.h
- *  - tools/blktap2/drivers/hashtable_private.h
- */
-
 #ifndef __HASHTABLE_PRIVATE_CWC22_H__
 #define __HASHTABLE_PRIVATE_CWC22_H__
=20
diff --git a/tools/vtpm_manager/util/log.c b/tools/vtpm_manager/util/log.=
c
--- a/tools/vtpm_manager/util/log.c
+++ b/tools/vtpm_manager/util/log.c
@@ -38,6 +38,17 @@
 #include "buffer.h"
 #include "tcg.h"
=20
+char *module_names[] =3D { "",
+                                "CRYPTO",
+                                "BSG",
+                                "TXDATA",
+                                "TCS",
+                                "TCS",
+                                "VTSP",
+                                "VTPM",
+                                "VTPM",
+                                "VTSP"
+                              };
 // Helper code for the consts, eg. to produce messages for error codes.
=20
 typedef struct error_code_entry_t {
diff --git a/tools/vtpm_manager/util/log.h b/tools/vtpm_manager/util/log.=
h
--- a/tools/vtpm_manager/util/log.h
+++ b/tools/vtpm_manager/util/log.h
@@ -36,6 +36,8 @@
=20
 #include <stdint.h>             // for uint32_t
 #include <stddef.h>             // for pointer NULL
+#include <stdio.h>
+#include <tcg.h>
=20
 // =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D LOGGING =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
=20
@@ -50,17 +52,7 @@
 #define VTPM_LOG_VTPM_DEEP   8
 #define VTPM_LOG_VTSP_DEEP   9
=20
-static char *module_names[] =3D { "",
-                                "CRYPTO",
-                                "BSG",
-                                "TXDATA",
-                                "TCS",
-                                "TCS",
-                                "VTSP",
-                                "VTPM",
-                                "VTPM",
-                                "VTSP"
-                              };
+extern char *module_names[];
=20
 // Default to standard logging
 #ifndef LOGGING_MODULES
diff --git a/tools/vtpm_manager/util/tcg.h b/tools/vtpm_manager/util/tcg.=
h
--- a/tools/vtpm_manager/util/tcg.h
+++ b/tools/vtpm_manager/util/tcg.h
@@ -197,6 +197,7 @@ typedef struct pack_buf_t {
   UINT32 size;
   BYTE * data;
 } pack_buf_t;
+#define NULL_PACK_BUF {0,0}
=20
 typedef struct pack_constbuf_t {
   UINT32 size;
@@ -295,6 +296,35 @@ typedef struct pack_constbuf_t {
 #define TPM_ORD_LoadKeyContext           (181UL + TPM_PROTECTED_ORDINAL)=

 #define TPM_ORD_SaveAuthContext          (182UL + TPM_PROTECTED_ORDINAL)=

 #define TPM_ORD_LoadAuthContext          (183UL + TPM_PROTECTED_ORDINAL)=

+#define TPM_ORD_SaveContext                      (184UL +
TPM_PROTECTED_ORDINAL)
+#define TPM_ORD_LoadContext                      (185UL +
TPM_PROTECTED_ORDINAL)
+#define TPM_ORD_FlushSpecific                    (186UL +
TPM_PROTECTED_ORDINAL)
+#define TPM_ORD_PCR_Reset                        (200UL +
TPM_PROTECTED_ORDINAL)
+#define TPM_ORD_NV_DefineSpace                   (204UL +
TPM_PROTECTED_ORDINAL)
+#define TPM_ORD_NV_WriteValue                    (205UL +
TPM_PROTECTED_ORDINAL)
+#define TPM_ORD_NV_WriteValueAuth                (206UL +
TPM_PROTECTED_ORDINAL)
+#define TPM_ORD_NV_ReadValue                     (207UL +
TPM_PROTECTED_ORDINAL)
+#define TPM_ORD_NV_ReadValueAuth                 (208UL +
TPM_PROTECTED_ORDINAL)
+#define TPM_ORD_Delegate_UpdateVerification      (209UL +
TPM_PROTECTED_ORDINAL)
+#define TPM_ORD_Delegate_Manage                  (210UL +
TPM_PROTECTED_ORDINAL)
+#define TPM_ORD_Delegate_CreateKeyDelegation     (212UL +
TPM_PROTECTED_ORDINAL)
+#define TPM_ORD_Delegate_CreateOwnerDelegation   (213UL +
TPM_PROTECTED_ORDINAL)
+#define TPM_ORD_Delegate_VerifyDelegation        (214UL +
TPM_PROTECTED_ORDINAL)
+#define TPM_ORD_Delegate_LoadOwnerDelegation     (216UL +
TPM_PROTECTED_ORDINAL)
+#define TPM_ORD_Delegate_ReadAuth                (217UL +
TPM_PROTECTED_ORDINAL)
+#define TPM_ORD_Delegate_ReadTable               (219UL +
TPM_PROTECTED_ORDINAL)
+#define TPM_ORD_CreateCounter                    (220UL +
TPM_PROTECTED_ORDINAL)
+#define TPM_ORD_IncrementCounter                 (221UL +
TPM_PROTECTED_ORDINAL)
+#define TPM_ORD_ReadCounter                      (222UL +
TPM_PROTECTED_ORDINAL)
+#define TPM_ORD_ReleaseCounter                   (223UL +
TPM_PROTECTED_ORDINAL)
+#define TPM_ORD_ReleaseCounterOwner              (224UL +
TPM_PROTECTED_ORDINAL)
+#define TPM_ORD_EstablishTransport               (230UL +
TPM_PROTECTED_ORDINAL)
+#define TPM_ORD_ExecuteTransport                 (231UL +
TPM_PROTECTED_ORDINAL)
+#define TPM_ORD_ReleaseTransportSigned           (232UL +
TPM_PROTECTED_ORDINAL)
+#define TPM_ORD_GetTicks                         (241UL +
TPM_PROTECTED_ORDINAL)
+#define TPM_ORD_TickStampBlob                    (242UL +
TPM_PROTECTED_ORDINAL)
+#define TPM_ORD_MAX                              (256UL +
TPM_PROTECTED_ORDINAL)
+
 #define TSC_ORD_PhysicalPresence         (10UL + TPM_CONNECTION_ORDINAL)=

=20
=20
@@ -419,8 +449,16 @@ typedef struct pack_constbuf_t {
 /// TPM_ResourceTypes
 #define TPM_RT_KEY      0x00000001
 #define TPM_RT_AUTH     0x00000002
+#define TPM_RT_HASH     0x00000003
 #define TPM_RT_TRANS    0x00000004
 #define TPM_RT_CONTEXT  0x00000005
+#define TPM_RT_COUNTER  0x00000006
+#define TPM_RT_DELEGATE 0x00000007
+#define TPM_RT_DAA_TPM  0x00000008
+#define TPM_RT_DAA_V0   0x00000009
+#define TPM_RT_DAA_V1   0x0000000A
+
+
=20
 // TPM_PROTOCOL_ID values
 #define TPM_PID_OIAP 0x0001
@@ -447,6 +485,64 @@ typedef struct pack_constbuf_t {
 #define TPM_SS_RSASSAPKCS1v15_SHA1 0x0002
 #define TPM_SS_RSASSAPKCS1v15_DER 0x0003
=20
+/*
+ * TPM_CAPABILITY_AREA Values for TPM_GetCapability ([TPM_Part2],
Section 21.1)
+ */
+#define TPM_CAP_ORD                     0x00000001
+#define TPM_CAP_ALG                     0x00000002
+#define TPM_CAP_PID                     0x00000003
+#define TPM_CAP_FLAG                    0x00000004
+#define TPM_CAP_PROPERTY                0x00000005
+#define TPM_CAP_VERSION                 0x00000006
+#define TPM_CAP_KEY_HANDLE              0x00000007
+#define TPM_CAP_CHECK_LOADED            0x00000008
+#define TPM_CAP_SYM_MODE                0x00000009
+#define TPM_CAP_KEY_STATUS              0x0000000C
+#define TPM_CAP_NV_LIST                 0x0000000D
+#define TPM_CAP_MFR                     0x00000010
+#define TPM_CAP_NV_INDEX                0x00000011
+#define TPM_CAP_TRANS_ALG               0x00000012
+#define TPM_CAP_HANDLE                  0x00000014
+#define TPM_CAP_TRANS_ES                0x00000015
+#define TPM_CAP_AUTH_ENCRYPT            0x00000017
+#define TPM_CAP_SELECT_SIZE             0x00000018
+#define TPM_CAP_DA_LOGIC                0x00000019
+#define TPM_CAP_VERSION_VAL             0x0000001A
+
+/* subCap definitions ([TPM_Part2], Section 21.2) */
+#define TPM_CAP_PROP_PCR                0x00000101
+#define TPM_CAP_PROP_DIR                0x00000102
+#define TPM_CAP_PROP_MANUFACTURER       0x00000103
+#define TPM_CAP_PROP_KEYS               0x00000104
+#define TPM_CAP_PROP_MIN_COUNTER        0x00000107
+#define TPM_CAP_FLAG_PERMANENT          0x00000108
+#define TPM_CAP_FLAG_VOLATILE           0x00000109
+#define TPM_CAP_PROP_AUTHSESS           0x0000010A
+#define TPM_CAP_PROP_TRANSESS           0x0000010B
+#define TPM_CAP_PROP_COUNTERS           0x0000010C
+#define TPM_CAP_PROP_MAX_AUTHSESS       0x0000010D
+#define TPM_CAP_PROP_MAX_TRANSESS       0x0000010E
+#define TPM_CAP_PROP_MAX_COUNTERS       0x0000010F
+#define TPM_CAP_PROP_MAX_KEYS           0x00000110
+#define TPM_CAP_PROP_OWNER              0x00000111
+#define TPM_CAP_PROP_CONTEXT            0x00000112
+#define TPM_CAP_PROP_MAX_CONTEXT        0x00000113
+#define TPM_CAP_PROP_FAMILYROWS         0x00000114
+#define TPM_CAP_PROP_TIS_TIMEOUT        0x00000115
+#define TPM_CAP_PROP_STARTUP_EFFECT     0x00000116
+#define TPM_CAP_PROP_DELEGATE_ROW       0x00000117
+#define TPM_CAP_PROP_MAX_DAASESS        0x00000119
+#define TPM_CAP_PROP_DAASESS            0x0000011A
+#define TPM_CAP_PROP_CONTEXT_DIST       0x0000011B
+#define TPM_CAP_PROP_DAA_INTERRUPT      0x0000011C
+#define TPM_CAP_PROP_SESSIONS           0x0000011D
+#define TPM_CAP_PROP_MAX_SESSIONS       0x0000011E
+#define TPM_CAP_PROP_CMK_RESTRICTION    0x0000011F
+#define TPM_CAP_PROP_DURATION           0x00000120
+#define TPM_CAP_PROP_ACTIVE_COUNTER     0x00000122
+#define TPM_CAP_PROP_MAX_NV_AVAILABLE   0x00000123
+#define TPM_CAP_PROP_INPUT_BUFFER       0x00000124
+
 // TPM_KEY_USAGE values
 #define TPM_KEY_EK 0x0000
 #define TPM_KEY_SIGNING 0x0010
diff --git a/tools/vtpm_manager/vtpmconnd/Makefile
b/tools/vtpm_manager/vtpmconnd/Makefile
--- /dev/null
+++ b/tools/vtpm_manager/vtpmconnd/Makefile
@@ -0,0 +1,30 @@
+# Copyright (c) 2010-2012 United States Government, as represented by
+# the Secretary of Defense.  All rights reserved.
+#
+# THIS SOFTWARE AND ITS DOCUMENTATION ARE PROVIDED AS IS AND WITHOUT
+# ANY EXPRESS OR IMPLIED WARRANTIES WHATSOEVER. ALL WARRANTIES
+# INCLUDING, BUT NOT LIMITED TO, PERFORMANCE, MERCHANTABILITY, FITNESS
+# FOR A PARTICULAR  PURPOSE, AND NONINFRINGEMENT ARE HEREBY
+# DISCLAIMED. USERS ASSUME THE ENTIRE RISK AND LIABILITY OF USING THE
+# SOFTWARE.
+#
+
+XEN_ROOT =3D $(realpath ../../..)
+include ../Rules.mk
+
+BIN=3Dvtpmconnd
+OBJS=3Dvtpmconnd.o
+CFLAGS=3D-O2 -Wall
+
+all: ${BIN}
+
+${BIN}: ${OBJS}
+    gcc -o $@ $<
+
+install: ${BIN}
+    install -m 0755 ${BIN} $(DESTDIR)$(BINDIR)/$(BIN)
+
+.PHONY: mrproper
+mrproper: clean
+clean:
+    -rm ${BIN} ${OBJS}
diff --git a/tools/vtpm_manager/vtpmconnd/vtpmconnd.c
b/tools/vtpm_manager/vtpmconnd/vtpmconnd.c
--- /dev/null
+++ b/tools/vtpm_manager/vtpmconnd/vtpmconnd.c
@@ -0,0 +1,253 @@
+/*
+ * Copyright (c) 2010-2012 United States Government, as represented by
+ * the Secretary of Defense.  All rights reserved.
+ *
+ * THIS SOFTWARE AND ITS DOCUMENTATION ARE PROVIDED AS IS AND WITHOUT
+ * ANY EXPRESS OR IMPLIED WARRANTIES WHATSOEVER. ALL WARRANTIES
+ * INCLUDING, BUT NOT LIMITED TO, PERFORMANCE, MERCHANTABILITY, FITNESS
+ * FOR A PARTICULAR  PURPOSE, AND NONINFRINGEMENT ARE HEREBY
+ * DISCLAIMED. USERS ASSUME THE ENTIRE RISK AND LIABILITY OF USING THE
+ * SOFTWARE.
+ */
+
+#include <stdio.h>
+#include <string.h>
+#include <errno.h>
+#include <getopt.h>
+#include <stdint.h>
+#include <unistd.h>
+#include <fcntl.h>
+#include <signal.h>
+#include <ctype.h>
+#include "../manager/vtpm_manager.h"
+
+#define VTPM_BE "/dev/vtpm"
+#define TPM_DEV "/dev/tpm0"
+#define MAX_CMD 4096
+#define DEVNULL "/dev/null"
+#define TPM_SUCCESS_RESP "\x00\x00\x00\x00" "\x01\xC1"
"\x00\x00\x00\x00" "\x00\x00\x00\x00"
+#define TPM_SUCCESS_RESPLEN 14
+
+static int quit =3D 0;
+
+struct Opts {
+   const char* vtpmbe;
+   const char* tpmdev;
+   int verbosity;
+   int daemon;
+};
+
+struct Opts opts =3D {
+   .vtpmbe =3D VTPM_BE,
+   .tpmdev =3D TPM_DEV,
+   .verbosity =3D 0,
+   .daemon =3D 1,
+};
+
+void usage(char* argv0) {
+fprintf(stderr, "Usage:\n \
+\t%s [options] [tpm device node]\n\
+\n\
+-h\t\tdisplay usage message\n\
+-v\t\tturn up verbosity level\n\
+-t <FILE>\tuse FILE for tpm device (default " TPM_DEV ")\n\
+-b <FILE>\tset vtpm backend device to FILE (default: " VTPM_BE ")\n\
+-f\t\trun in the foreground\n",
+argv0
+);
+}
+
+void sighandler(int signum) {
+   quit =3D 1;
+}
+
+int main_loop(int vbefd, int tpmfd) {
+   uint8_t buf[MAX_CMD];
+   ssize_t size, wrote;
+   int i;
+
+   while(!quit) {
+      /* Wait for cmd from vtpm_manager */
+      if((size =3D read(vbefd, buf, MAX_CMD)) < 0) {
+     if(errno =3D=3D EFAULT) {
+        if(opts.verbosity > 0) {
+           fprintf(stderr, "read() failed with error: %s, non-fatal\n",
strerror(errno));
+        }
+        continue;
+     }
+     fprintf(stderr,"Error reading from %s, (%s)\n", opts.vtpmbe,
strerror(errno));
+     return 1;
+      }
+      if(opts.verbosity > 0) {
+     printf("\nvtpm_manager req(%ld):", (long) size);
+     for(i =3D 0; i < size; ++i) {
+        printf(" %02X", buf[i]);
+     }
+     printf("\n");
+      }
+    =20
+      if(quit) {
+     break;
+      }
+
+      /* Forward the cmd to the tpm, exclude the dmi id */
+      if((wrote =3D write(tpmfd, buf + 4, size - 4)) !=3D size - 4) {
+     fprintf(stderr,"Error writing to %s, (%s)\n", opts.tpmdev,
strerror(errno));
+     return 1;
+      }
+
+      if(quit) {
+     break;
+      }
+
+      /* Wait for response from tpm */
+      if((size =3D read(tpmfd, buf + 4, MAX_CMD - 4)) < 0) {
+     fprintf(stderr,"Error reading from %s, (%s)\n", opts.tpmdev,
strerror(errno));
+     return 1;
+      }
+      if(opts.verbosity > 0) {
+     printf("tpm resp(%ld):", (long) size);
+     for(i =3D 0; i < size + 4; ++i) {
+        printf(" %02X", buf[i]);
+     }
+     printf("\n");
+      }
+
+      if(quit) {
+     break;
+      }
+    =20
+      /* Send response back to vtpm_manager */
+      if((wrote =3D write(vbefd, buf, size + 4)) !=3D size + 4) {
+     fprintf(stderr, "Error writing to %s, (%s)\n", opts.vtpmbe,
strerror(errno));
+     return 1;
+      }
+   }
+
+   return 0;
+
+}
+
+int main(int argc, char** argv)
+{
+   int rc;
+   int vbefd, tpmfd;
+   int c;
+   int fd =3D -1;
+   struct sigaction sig;
+   pid_t pid;
+
+   /* Do cmdline opts */
+   opterr =3D 0;
+
+   while ((c =3D getopt (argc, argv, "hfvb:t:")) !=3D -1)
+   {
+      switch (c)
+      {
+     case 'h':
+        usage(argv[0]);
+        return 0;
+     case 'f':
+        opts.daemon =3D 0;
+        break;
+     case 'v':
+        ++opts.verbosity;
+        break;
+     case 'b':
+        opts.vtpmbe =3D optarg;
+        break;
+     case 't':
+        opts.tpmdev =3D optarg;
+        break;
+     case '?':
+        if (optopt =3D=3D 'c')
+           fprintf (stderr, "Option -%c requires an argument.\n", optopt=
);
+        else if (isprint (optopt))
+           fprintf (stderr, "Unknown option `-%c'.\n", optopt);
+        else
+           fprintf (stderr,
+             "Unknown option character `\\x%x'.\n",
+             optopt);
+            usage(argv[0]);
+        return 1;
+     default:
+        return 1;
+      }
+   }
+
+   /* DAEMONIZE */
+   if(opts.daemon) {
+      pid =3D fork();
+      if(pid < 0) {
+     fprintf(stderr, "failed to daemonize! fork() failed : %s\n",
strerror(errno));
+     return 1;
+      }
+
+      if (pid > 0) {
+     return 0;
+      }
+   }
+
+
+   /* SIGNAL HANDLING */
+   sig.sa_handler =3D sighandler;
+   sigemptyset(&sig.sa_mask);
+   sig.sa_flags =3D 0;
+
+   sigaction(SIGINT, &sig, NULL);
+   sigaction(SIGQUIT, &sig, NULL);
+   sigaction(SIGTERM, &sig, NULL);
+
+   /* FAKE OUT THE HOTPLUG SYSTEM */
+   /* Whenever hotplug writes a message let it go to dev null */
+   if(remove(VTPM_RX_HP_FNAME) !=3D 0 && errno !=3D ENOENT) {
+      fprintf(stderr, "Unable to remove %s : %s\n", VTPM_RX_HP_FNAME,
strerror(errno));
+      return -1;
+   }
+   if(symlink(DEVNULL, VTPM_RX_HP_FNAME) !=3D 0) {
+      fprintf(stderr, "Unable to create symlink %s -> %s : %s\n",
VTPM_RX_HP_FNAME, DEVNULL, strerror(errno));
+   }
+
+   /* Whenever hotplug tries to read a response, always return success *=
/
+   if(remove(VTPM_TX_HP_FNAME) !=3D 0 && errno !=3D ENOENT) {
+      fprintf(stderr, "Unable to remove %s : %s\n", VTPM_TX_HP_FNAME,
strerror(errno));
+      return -1;
+   }
+   if((fd =3D open(VTPM_TX_HP_FNAME, O_CREAT | O_WRONLY, S_IRUSR |
S_IWUSR)) < 0) {
+      fprintf(stderr, "Unable to open %s for writing : %s\n",
VTPM_TX_HP_FNAME, strerror(errno));
+      return -1;
+   }
+   if(write(fd, TPM_SUCCESS_RESP, TPM_SUCCESS_RESPLEN) !=3D
TPM_SUCCESS_RESPLEN) {
+      fprintf(stderr, "Unable to write to %s : %s\n", VTPM_TX_HP_FNAME,
strerror(errno));
+      return -1;
+   }
+   close(fd);
+   /* HOTPLUG FAKE OUT DONE */
+
+   /* Open the backend and tpm device */
+   if((vbefd =3D open(opts.vtpmbe, O_RDWR)) < 0) {
+      fprintf(stderr, "Unable to open `%s', (%s)\n", opts.vtpmbe,
strerror(errno));
+      return 1;
+   }
+   if((tpmfd =3D open(opts.tpmdev, O_RDWR)) < 0) {
+      fprintf(stderr, "Unable to open `%s', (%s)\n", opts.tpmdev,
strerror(errno));
+      return 1;
+   }
+   if(opts.verbosity > 0) {
+      fprintf(stderr, "Connected to vtpm backend: %s\n", opts.vtpmbe);
+      fprintf(stderr, "Connected to tpm: %s\n", opts.tpmdev);
+   }
+
+   rc =3D main_loop(vbefd, tpmfd);
+
+   close(vbefd);
+   close(tpmfd);
+
+   remove(VTPM_RX_HP_FNAME);
+   remove(VTPM_TX_HP_FNAME);
+
+
+   return rc;
+
+
+}
diff --git a/tools/vtpm_manager/vtpmmgrtalk/Makefile
b/tools/vtpm_manager/vtpmmgrtalk/Makefile
--- /dev/null
+++ b/tools/vtpm_manager/vtpmmgrtalk/Makefile
@@ -0,0 +1,35 @@
+# Copyright (c) 2010-2012 United States Government, as represented by
+# the Secretary of Defense.  All rights reserved.
+#
+# THIS SOFTWARE AND ITS DOCUMENTATION ARE PROVIDED AS IS AND WITHOUT
+# ANY EXPRESS OR IMPLIED WARRANTIES WHATSOEVER. ALL WARRANTIES
+# INCLUDING, BUT NOT LIMITED TO, PERFORMANCE, MERCHANTABILITY, FITNESS
+# FOR A PARTICULAR  PURPOSE, AND NONINFRINGEMENT ARE HEREBY
+# DISCLAIMED. USERS ASSUME THE ENTIRE RISK AND LIABILITY OF USING THE
+# SOFTWARE.
+#
+
+XEN_ROOT =3D $(realpath ../../..)
+include ../Rules.mk
+
+BIN=3Dvtpmmgrtalk
+OBJS=3Dvtpmmgrtalk.o
+CFLAGS=3D-Wall -O2 -g
+CFLAGS +=3D -I../crypto
+CFLAGS +=3D -I../util
+CFLAGS +=3D -I../tcs
+CFLAGS +=3D -I../manager
+
+
+all: ${BIN}
+
+${BIN}: ${OBJS}
+    gcc -o $@ $<
+
+install: all
+    install -m 0755 ${BIN} $(DESTDIR)$(BINDIR)/$(BIN)
+
+.PHONY: mrproper
+mrproper: clean
+clean:
+    rm -f ${BIN} ${OBJS}
diff --git a/tools/vtpm_manager/vtpmmgrtalk/vtpmmgrtalk.c
b/tools/vtpm_manager/vtpmmgrtalk/vtpmmgrtalk.c
--- /dev/null
+++ b/tools/vtpm_manager/vtpmmgrtalk/vtpmmgrtalk.c
@@ -0,0 +1,105 @@
+/*
+ * Copyright (c) 2010-2012 United States Government, as represented by
+ * the Secretary of Defense.  All rights reserved.
+ *
+ * THIS SOFTWARE AND ITS DOCUMENTATION ARE PROVIDED AS IS AND WITHOUT
+ * ANY EXPRESS OR IMPLIED WARRANTIES WHATSOEVER. ALL WARRANTIES
+ * INCLUDING, BUT NOT LIMITED TO, PERFORMANCE, MERCHANTABILITY, FITNESS
+ * FOR A PARTICULAR  PURPOSE, AND NONINFRINGEMENT ARE HEREBY
+ * DISCLAIMED. USERS ASSUME THE ENTIRE RISK AND LIABILITY OF USING THE
+ * SOFTWARE.
+ */
+#include <unistd.h>
+#include <fcntl.h>
+#include <sys/file.h>
+#include <stdio.h>
+#include <errno.h>
+#include <string.h>
+#include <stdint.h>
+
+#include "../manager/vtpm_manager.h"
+
+int main(int argc, char** argv) {
+   int wfd, rfd;
+   uint8_t buf[COMMAND_BUFFER_SIZE];
+   ssize_t size;
+   int i, c;
+   int rc =3D 0;
+
+   const char* wfile =3D VTPM_RX_HP_FNAME;
+   const char* rfile =3D VTPM_TX_HP_FNAME;
+
+   /* Open for writing in non-blocking mode and exit if
+    * the manager is not waiting on the other side */
+   if((wfd =3D open(wfile, O_WRONLY | O_NONBLOCK)) < 0) {
+      fprintf(stderr, "Error opening %s for writing : %s\n",
wfile,strerror(errno));
+      return 1;
+   }
+   /* Set the pipe back to blocking mode */
+   fcntl(wfd, F_SETFL, 0);
+
+   /* Open the read pipe */
+   if((rfd =3D open(rfile, O_RDONLY)) < 0) {
+      close(wfd);
+      fprintf(stderr, "Error opening %s for reading : %s\n",
rfile,strerror(errno));
+      return 1;
+   }
+ =20
+   /*Grab the ASCII hex input from stdin and convert to binary */
+   for(i =3D 0; i < COMMAND_BUFFER_SIZE; ++i) {
+      c =3D scanf("%02hhX", buf + i);
+      if(c =3D=3D EOF) {
+     break;
+      } else if ( c !=3D 1) {
+     fprintf(stderr, "Malformed Input! Use ASCII hex!\n");
+     rc =3D 1;
+     goto quit;
+      }
+   }
+   size =3D i;
+
+   /* Send request to the manager only if a request was actually given *=
/
+   if(size > 0) {
+      /* Lock the pipes for reading/writing */
+      if(flock(wfd, LOCK_EX)) {
+     fprintf(stderr, "Unable to lock %s : %s\n", wfile, strerror(errno))=
;
+     rc =3D 1;
+     goto quit;
+      }
+      if(flock(rfd, LOCK_EX)) {
+     fprintf(stderr, "Unable to lock %s : %s\n", wfile, strerror(errno))=
;
+     rc =3D 1;
+     goto quit;
+      }
+
+      /* Write the binary data to the pipe */
+      if(write(wfd, buf, size) !=3D size) {
+     fprintf(stderr, "Error writing to %s : %s\n", wfile, strerror(errno=
));
+     rc =3D 1;
+     goto quit;
+      }
+
+      /* Read the response from the manager */
+      size =3D read(rfd, buf, COMMAND_BUFFER_SIZE);
+      if(size < 0) {
+     fprintf(stderr, "Error reading %s : %s\n", rfile, strerror(errno));=

+     rc =3D 1;
+     goto quit;
+      }
+      /* Output the hex */
+      for(i =3D 0; i < size; ++i) {
+     printf("%02X", buf[i]);
+      }
+      fprintf(stderr,"\n");
+
+      /* Unlock the pipes */
+      flock(rfd, LOCK_UN);
+      flock(wfd, LOCK_UN);
+   }
+
+   rc =3D 0;
+quit:
+   close(rfd);
+   close(wfd);
+   return rc;
+}



--------------ms030402000007090807080904
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIDyjCC
A8YwggMvoAMCAQICBD/xyf0wDQYJKoZIhvcNAQEFBQAwLzELMAkGA1UEBhMCVVMxDzANBgNV
BAoTBkpIVUFQTDEPMA0GA1UECxMGQklTRENBMB4XDTEwMDYxMTE4MjIwNloXDTEzMDYxMTE4
NTIwNlowZjELMAkGA1UEBhMCVVMxDzANBgNVBAoTBkpIVUFQTDEPMA0GA1UECxMGUGVvcGxl
MTUwFgYDVQQLEw9WUE5Hcm91cC1CSVNEQ0EwGwYDVQQDExRNYXR0aGV3IEUgRmlvcmF2YW50
ZTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAnpbwVSP6o1Nb5lcW7dd3yTo9iBJdi7qz
4nANOMFPK7JOy5npKN1iiousl28U/scUJES55gPwAWYJK3uVyQAsA4adgDKi5DoD1UHDQEwp
bY7iHLJeq0NPr4BqYNqnCFPbE6HC8zSJrr4qKn+gVUQT39SIFqdiIPJwZL8FYTRQ/zsCAwEA
AaOCAbYwggGyMAsGA1UdDwQEAwIHgDArBgNVHRAEJDAigA8yMDEwMDYxMTE4MjIwNlqBDzIw
MTIwNzE3MjI1MjA2WjAbBg0rBgEEAbMlCwMBAQEBBAoWCGZpb3JhbWUxMBsGDSsGAQQBsyUL
AwEBAQIEChIIMDAxMDQyNjEwWAYJYIZIAYb6ax4BBEsMSVRoZSBwcml2YXRlIGtleSBjb3Jy
ZXNwb25kaW5nIHRvIHRoaXMgY2VydGlmaWNhdGUgbWF5IGhhdmUgYmVlbiBleHBvcnRlZC4w
KAYDVR0RBCEwH4EdTWF0dGhldy5GaW9yYXZhbnRlQGpodWFwbC5lZHUwUgYDVR0fBEswSTBH
oEWgQ6RBMD8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJU0RD
QTEOMAwGA1UEAxMFQ1JMNTYwHwYDVR0jBBgwFoAUCDUpmxH52EU2CyWmF2EJMB1yqeswHQYD
VR0OBBYEFO6LYxg6r9wHZ+zdQtBHn1dZ/YTNMAkGA1UdEwQCMAAwGQYJKoZIhvZ9B0EABAww
ChsEVjcuMQMCBLAwDQYJKoZIhvcNAQEFBQADgYEAJO9HQh4YNChVLzuZqK5ARJARD8JoujGZ
fdo75quvg2jXFQe2sEjvLnxJZgm/pv8fdZakq48CWwjYHKuvIp7sDjTEsQfo+y7SpN/N2NvJ
WU5SqfK1VgYtNLRRoGJUB5Q1aZ+Dg95g3kqpyfpUMISJL8IKVLtJVfN4fggFVUYZ9wwxggGr
MIIBpwIBATA3MC8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJ
U0RDQQIEP/HJ/TAJBgUrDgMCGgUAoIHLMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ
KoZIhvcNAQkFMQ8XDTEyMDkxNzIxMTY1MVowIwYJKoZIhvcNAQkEMRYEFGWuQgd9cmNWDW4S
YBUOf4/vmoemMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAK
BggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI
KoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEgYBf4xs58Unzhu7iU+qLUoY78adlX8v0F1DQ
HWTubayhDSNA7ULP64vY7NLQIkReW2+gr5h7M2vwmRsP63LZ72TEaEKG2nf1fjtQI+cbmBMG
zlKFj6BubEeczjXPlXB+fLTKwvmLRNIi8Wa3J/EVvEaFEHAmm9qwBuEgxZfwEyQtdwAAAAAA
AA==
--------------ms030402000007090807080904--


--===============7207552152192457387==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============7207552152192457387==--


From xen-devel-bounces@lists.xen.org Mon Sep 17 21:18:52 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 21: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 1TDii4-0000JM-Rk; Mon, 17 Sep 2012 21:18:28 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <matthew.fioravante@jhuapl.edu>) id 1TDii2-0000JH-Hf
	for xen-devel@lists.xensource.com; Mon, 17 Sep 2012 21:18:27 +0000
Received: from [85.158.137.99:19225] by server-2.bemta-3.messagelabs.com id
	F0/D4-04862-1A397505; Mon, 17 Sep 2012 21:18:25 +0000
X-Env-Sender: matthew.fioravante@jhuapl.edu
X-Msg-Ref: server-16.tower-217.messagelabs.com!1347916697!18053812!1
X-Originating-IP: [128.244.251.36]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG,
	UNPARSEABLE_RELAY,UPPERCASE_25_50
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3619 invoked from network); 17 Sep 2012 21:18:19 -0000
Received: from pilot.jhuapl.edu (HELO jhuapl.edu) (128.244.251.36)
	by server-16.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 17 Sep 2012 21:18:19 -0000
Received: from ([128.244.207.89])
	by pilot.jhuapl.edu with ESMTP with TLS id 63GHCH1.153073819;
	Mon, 17 Sep 2012 17:18:06 -0400
Message-ID: <50579343.6020106@jhuapl.edu>
Date: Mon, 17 Sep 2012 17:16:51 -0400
From: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:14.0) Gecko/20120714 Thunderbird/14.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>, 
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
X-Enigmail-Version: 1.5a1pre
Subject: [Xen-devel] [PATCH vtpm_manager 1/2] Updates and bug fixes to
	vtpm_manager
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============7207552152192457387=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a cryptographically signed message in MIME format.

--===============7207552152192457387==
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms030402000007090807080904"

This is a cryptographically signed message in MIME format.

--------------ms030402000007090807080904
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

The following patch contains a major set of bug fixes and feature
enhancements to vtpm_manager.

vtpm_manager was previously riddled with memory leaks, race conditions,
IO deadlocks, and other assorted bugs.

This patch fixes numerous bugs in vtpm manager and also adds new
functionality for supporting vtpm stub domains.=20

It adds a new program (vtpmmgrtalk) that is used by the hotplug script
fixes (next patch) to avoid IO deadlocks with pipes.

Finally, it also breaks the compilation of vtpm_manager into separate
static libraries, which are then used later by the vtpmmgrdom stub domain=
=2E

Signed of by: Matthew Fioravante matthew.fioravante@jhuapl.edu

diff --git a/tools/vtpm_manager/Makefile b/tools/vtpm_manager/Makefile
--- a/tools/vtpm_manager/Makefile
+++ b/tools/vtpm_manager/Makefile
@@ -1,9 +1,9 @@
-XEN_ROOT =3D $(CURDIR)/../..
+XEN_ROOT =3D $(realpath ../..)
=20
 # Base definitions and rules
-include $(XEN_ROOT)/tools/vtpm_manager/Rules.mk
+include Rules.mk
=20
-SUBDIRS        =3D crypto tcs util manager migration
+SUBDIRS        =3D crypto tcs util manager migration vtpmmgrtalk vtpmcon=
nd
 OPENSSL_HEADER    =3D /usr/include/openssl/crypto.h
=20
 .PHONY: all clean install
diff --git a/tools/vtpm_manager/README b/tools/vtpm_manager/README
--- a/tools/vtpm_manager/README
+++ b/tools/vtpm_manager/README
@@ -43,9 +43,6 @@ Compile Flags
 LOGGING_MODULES              -> How extensive logging happens
                                 see util/log.h for more info
=20
-VTPM_MULTI_VM                -> Defined: VTPMs run in their own VMs
-                                Not Defined (default): VTPMs are process=
es
-
 # Debugging flags that may disappear without notice in the future
=20
 DUMMY_BACKEND                -> vtpm_manager listens on /tmp/in.fifo and=

@@ -59,6 +56,10 @@ WELL_KNOWN_OWNER_AUTH        -> Rather than randomly
generating the password for
                                 lost. However this has no protection
from malicious app
                                 issuing a TPM_OwnerClear to wipe the TPM=

=20
+VTPM_STUBDOM             -> vtpm_manager runs in vtpm_stubdom mode with
+                vtpm instances running in mini-os domains
+                (see: stubdom/vtpm/README for details)
+
 Requirements
 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
 - xen-unstable
diff --git a/tools/vtpm_manager/Rules.mk b/tools/vtpm_manager/Rules.mk
--- a/tools/vtpm_manager/Rules.mk
+++ b/tools/vtpm_manager/Rules.mk
@@ -6,7 +6,7 @@ include $(XEN_ROOT)/tools/Rules.mk
 #
=20
 # General compiler flags
-CFLAGS    =3D -Werror -g3
+CFLAGS    =3D -Werror -g3 -I.
=20
 # Generic project files
 HDRS    =3D $(wildcard *.h)
@@ -31,18 +31,18 @@ $(OBJS): $(SRCS)
 CFLAGS +=3D -D_GNU_SOURCE
=20
 # Logging Level. See utils/tools.h for usage
-CFLAGS +=3D
-DLOGGING_MODULES=3D"(BITMASK(VTPM_LOG_TCS)|BITMASK(VTPM_LOG_VTSP)|BITMAS=
K(VTPM_LOG_VTPM))"
+#CFLAGS +=3D
-DLOGGING_MODULES=3D"(BITMASK(VTPM_LOG_TCS)|BITMASK(VTPM_LOG_VTSP)|BITMAS=
K(VTPM_LOG_VTPM))"
=20
 # Silent Mode
 #CFLAGS +=3D -DLOGGING_MODULES=3D0x0
-#CFLAGS +=3D -DLOGGING_MODULES=3D0xff
-
-# Use frontend/backend pairs between manager & DMs?
-#CFLAGS +=3D -DVTPM_MULTI_VM
+CFLAGS +=3D -DLOGGING_MODULES=3D0xff
=20
 # vtpm_manager listens on fifo's rather than backend
 #CFLAGS +=3D -DDUMMY_BACKEND
=20
+# Build for use with vtpm-stubdom
+#CFLAGS +=3D -DVTPM_STUBDOM
+
 # TCS talks to fifo's rather than /dev/tpm. TPM Emulator assumed on fifo=
s
 #CFLAGS +=3D -DDUMMY_TPM
=20
@@ -52,8 +52,3 @@ CFLAGS +=3D
-DLOGGING_MODULES=3D"(BITMASK(VTPM_LOG_TCS)|BITMASK(VTPM_LOG_VTSP)|BITMA
 # Fixed OwnerAuth
 #CFLAGS +=3D -DWELL_KNOWN_OWNER_AUTH
=20
-# Include
-CFLAGS +=3D -I$(XEN_ROOT)/tools/vtpm_manager/crypto
-CFLAGS +=3D -I$(XEN_ROOT)/tools/vtpm_manager/util
-CFLAGS +=3D -I$(XEN_ROOT)/tools/vtpm_manager/tcs
-CFLAGS +=3D -I$(XEN_ROOT)/tools/vtpm_manager/manager
diff --git a/tools/vtpm_manager/crypto/Makefile
b/tools/vtpm_manager/crypto/Makefile
--- a/tools/vtpm_manager/crypto/Makefile
+++ b/tools/vtpm_manager/crypto/Makefile
@@ -1,5 +1,9 @@
-XEN_ROOT =3D $(CURDIR)/../../..
-include $(XEN_ROOT)/tools/vtpm_manager/Rules.mk
+XEN_ROOT =3D $(realpath ../../..)
+include ../Rules.mk
+
+CFLAGS +=3D -I../util
+CFLAGS +=3D -I../tcs
+CFLAGS +=3D -I../manager
=20
 BIN        =3D libtcpaCrypto.a
=20
diff --git a/tools/vtpm_manager/crypto/crypto.c
b/tools/vtpm_manager/crypto/crypto.c
--- a/tools/vtpm_manager/crypto/crypto.c
+++ b/tools/vtpm_manager/crypto/crypto.c
@@ -45,6 +45,8 @@
 #include "crypto.h"
 #include "log.h"
=20
+extern const EVP_CIPHER * SYM_CIPHER;
+
 /**
  * Initialize cryptography library
  * @rand: random seed
@@ -83,6 +85,6 @@ void Crypto_GetRandom(void* data, int size) {
   result =3D RAND_pseudo_bytes((BYTE*) data, size);
 =20
   if (result <=3D 0)
-    vtpmlogerror (VTPM_LOG_CRYPTO, "RAND_pseudo_bytes failed: %s\n",
-         ERR_error_string (ERR_get_error(), NULL));
+    vtpmlogerror (VTPM_LOG_CRYPTO, "RAND_pseudo_bytes failed: rc=3D%d
errstr=3D%s\n",
+      result, ERR_error_string (ERR_get_error(), NULL));
 }
diff --git a/tools/vtpm_manager/crypto/crypto.h
b/tools/vtpm_manager/crypto/crypto.h
--- a/tools/vtpm_manager/crypto/crypto.h
+++ b/tools/vtpm_manager/crypto/crypto.h
@@ -76,7 +76,7 @@ typedef struct CRYPTO_INFO {
=20
 void Crypto_Init(const BYTE* rand, int size);
=20
-void Crypto_Exit();
+void Crypto_Exit(void);
=20
 void Crypto_GetRandom(void* data, int size);
=20
@@ -127,6 +127,8 @@ void Crypto_RSABuildCryptoInfoPublic(   /*[IN]*/
UINT32 pubExpSize,
                                         /*[IN]*/ BYTE *modulus,
                                         CRYPTO_INFO* cryptoInfo);
=20
+void Crypto_RSACryptoInfoFree(CRYPTO_INFO* cryptoInfo);
+
 //
 // symmetric pack and unpack operations
 //
diff --git a/tools/vtpm_manager/crypto/rsa.c
b/tools/vtpm_manager/crypto/rsa.c
--- a/tools/vtpm_manager/crypto/rsa.c
+++ b/tools/vtpm_manager/crypto/rsa.c
@@ -149,6 +149,10 @@ void Crypto_RSABuildCryptoInfoPublic(   /*[IN]*/
UINT32 pubExpSize,
 =20
 }
=20
+void Crypto_RSACryptoInfoFree(CRYPTO_INFO* cryptoInfo) {
+   RSA_free(cryptoInfo->keyInfo);
+}
+
 int Crypto_RSAEnc(  CRYPTO_INFO *key,
             UINT32 inDataSize,
             BYTE *inData,
@@ -161,6 +165,7 @@ int Crypto_RSAEnc(  CRYPTO_INFO *key,
   =20
   if (paddedData =3D=3D NULL)
     return -1;
+  memset(paddedData, 0, sizeof(BYTE) * paddedDataSize);
=20
   *outDataSize =3D 0;
 =20
diff --git a/tools/vtpm_manager/crypto/sym_crypto.c
b/tools/vtpm_manager/crypto/sym_crypto.c
--- a/tools/vtpm_manager/crypto/sym_crypto.c
+++ b/tools/vtpm_manager/crypto/sym_crypto.c
@@ -41,8 +41,16 @@
 #include <openssl/rand.h>
=20
 #include "tcg.h"
+#include "log.h"
 #include "sym_crypto.h"
=20
+struct symkey_t {
+  buffer_t key;
+
+  EVP_CIPHER_CTX context;
+  const EVP_CIPHER * cipher;
+};
+
 typedef enum crypt_op_type_t {
   CRYPT_ENCRYPT,
   CRYPT_DECRYPT
@@ -61,19 +69,22 @@ const EVP_CIPHER * SYM_CIPHER =3D NULL;
 const BYTE ZERO_IV[EVP_MAX_IV_LENGTH] =3D {0};
=20
=20
-TPM_RESULT Crypto_symcrypto_initkey (symkey_t * key, const buffer_t*
keybits) {
+TPM_RESULT Crypto_symcrypto_initkey (symkey_t ** key, const buffer_t*
keybits) {
   TPM_RESULT status =3D TPM_SUCCESS;
 =20
-  EVP_CIPHER_CTX_init (&key->context);
+  *key =3D malloc(sizeof(symkey_t));
+
+  EVP_CIPHER_CTX_init (&(*key)->context);
 =20
-  key->cipher =3D SYM_CIPHER;
+  (*key)->cipher =3D SYM_CIPHER;
 =20
-  TPMTRYRETURN( buffer_init_copy (&key->key, keybits));
+  TPMTRYRETURN( buffer_init_copy (&(*key)->key, keybits));
   =20
   goto egress;
 =20
  abort_egress:
-  EVP_CIPHER_CTX_cleanup (&key->context);
+  EVP_CIPHER_CTX_cleanup (&(*key)->context);
+  free(key);
 =20
  egress:
 =20
@@ -82,19 +93,21 @@ TPM_RESULT Crypto_symcrypto_initkey (symkey_t * key,
const buffer_t* keybits) {
=20
=20
=20
-TPM_RESULT Crypto_symcrypto_genkey (symkey_t * key) {
+TPM_RESULT Crypto_symcrypto_genkey (symkey_t ** key) {
   int res;
   TPM_RESULT status =3D TPM_SUCCESS;
+
+  *key =3D malloc(sizeof(symkey_t));
 =20
   // hmm, EVP_CIPHER_CTX_init does not return a value
-  EVP_CIPHER_CTX_init (&key->context);
+  EVP_CIPHER_CTX_init (&(*key)->context);
 =20
-  key->cipher =3D SYM_CIPHER;
+  (*key)->cipher =3D SYM_CIPHER;
 =20
-  TPMTRYRETURN( buffer_init (&key->key,
EVP_CIPHER_key_length(key->cipher), NULL)) ;
+  TPMTRYRETURN( buffer_init (&(*key)->key,
EVP_CIPHER_key_length((*key)->cipher), NULL)) ;
 =20
   // and generate the key material
-  res =3D RAND_pseudo_bytes (key->key.bytes, key->key.size);
+  res =3D RAND_pseudo_bytes ((*key)->key.bytes, (*key)->key.size);
   if (res < 0)
     ERRORDIE (TPM_SHORTRANDOM);
 =20
@@ -102,8 +115,9 @@ TPM_RESULT Crypto_symcrypto_genkey (symkey_t * key) {=

   goto egress;
 =20
  abort_egress:
-  EVP_CIPHER_CTX_cleanup (&key->context);
-  buffer_free (&key->key);
+  EVP_CIPHER_CTX_cleanup (&(*key)->context);
+  buffer_free (&(*key)->key);
+  free(key);
 =20
  egress:
   return status;=20
@@ -119,11 +133,11 @@ TPM_RESULT Crypto_symcrypto_encrypt (symkey_t* key,=

 =20
   buffer_init_const (&iv, EVP_MAX_IV_LENGTH, ZERO_IV);
 =20
-  buffer_init (o_cipher,
-           clear->size +
-           EVP_CIPHER_iv_length(key->cipher) +
-           EVP_CIPHER_block_size (key->cipher),
-                 0);
+  TPMTRYRETURN( buffer_init (o_cipher,
+                  clear->size +
+                  EVP_CIPHER_iv_length(key->cipher) +
+                  EVP_CIPHER_block_size (key->cipher),
+                 0) );
 =20
   // copy the IV into the front
   buffer_copy (o_cipher, &iv);
@@ -139,6 +153,7 @@ TPM_RESULT Crypto_symcrypto_encrypt (symkey_t* key,
   goto egress;
 =20
  abort_egress:
+  buffer_free(o_cipher);
 =20
  egress:
 =20
@@ -170,7 +185,7 @@ TPM_RESULT Crypto_symcrypto_decrypt (symkey_t* key,
 =20
   // and decrypt
   TPMTRYRETURN ( ossl_symcrypto_op (key, &cipher_alias, &iv, o_clear,
CRYPT_DECRYPT) );
-=20
+
   goto egress;
 =20
  abort_egress:
@@ -188,6 +203,8 @@ TPM_RESULT Crypto_symcrypto_freekey (symkey_t * key) =
{
   buffer_free (&key->key);
 =20
   EVP_CIPHER_CTX_cleanup (&key->context);
+
+  free(key);
 =20
   return TPM_SUCCESS;
 }
@@ -235,3 +252,8 @@ TPM_RESULT ossl_symcrypto_op (symkey_t* key,
 =20
   return status;
 }
+
+buffer_t* Crypto_symkey_getkey(symkey_t* key)
+{
+   return &key->key;
+}
diff --git a/tools/vtpm_manager/crypto/sym_crypto.h
b/tools/vtpm_manager/crypto/sym_crypto.h
--- a/tools/vtpm_manager/crypto/sym_crypto.h
+++ b/tools/vtpm_manager/crypto/sym_crypto.h
@@ -40,21 +40,15 @@
 #ifndef _SYM_CRYPTO_H
 #define _SYM_CRYPTO_H
=20
-#include <openssl/evp.h>
 #include "buffer.h"
=20
-typedef struct symkey_t {
-  buffer_t key;
-=20
-  EVP_CIPHER_CTX context;
-  const EVP_CIPHER * cipher;
-} symkey_t;
+typedef struct symkey_t symkey_t;
=20
-extern const EVP_CIPHER * SYM_CIPHER;
+//Allocates a symkey with random bits
+TPM_RESULT Crypto_symcrypto_genkey (symkey_t ** key);
=20
-TPM_RESULT Crypto_symcrypto_genkey (symkey_t * key);
-
-TPM_RESULT Crypto_symcrypto_initkey (symkey_t * key, const buffer_t*
keybits);
+//Allocates a symkey with given keybits
+TPM_RESULT Crypto_symcrypto_initkey (symkey_t ** key, const buffer_t*
keybits);
=20
=20
 // these functions will allocate their output buffers
@@ -66,7 +60,10 @@ TPM_RESULT Crypto_symcrypto_decrypt (symkey_t* key,
                               const buffer_t* cipher,
                               buffer_t* o_clear);
=20
-// only free the internal parts, not the 'key' ptr
+//Frees the symkey
 TPM_RESULT Crypto_symcrypto_freekey (symkey_t * key);
=20
+//Get the raw key byte buffer
+buffer_t* Crypto_symkey_getkey(symkey_t* key);
+
 #endif /* _SYM_CRYPTO_H */
diff --git a/tools/vtpm_manager/manager/Makefile
b/tools/vtpm_manager/manager/Makefile
--- a/tools/vtpm_manager/manager/Makefile
+++ b/tools/vtpm_manager/manager/Makefile
@@ -1,7 +1,18 @@
-XEN_ROOT =3D $(CURDIR)/../../..
-include $(XEN_ROOT)/tools/vtpm_manager/Rules.mk
+XEN_ROOT =3D $(realpath ../../..)
+include ../Rules.mk
+
+CFLAGS +=3D -I../crypto
+CFLAGS +=3D -I../util
+CFLAGS +=3D -I../tcs
+
+
+MAINS         :=3D vtpmd.o
+MGRLIB         :=3D libvtpmmanager.a
+VTSPOBJS    :=3D vtsp.o
+VTSPLIB        :=3D libvtsp.a
+BIN        :=3D vtpm_managerd
+OBJS         :=3D $(filter-out $(MAINS) $(VTSPOBJS), $(OBJS))
=20
-BIN        =3D vtpm_managerd
=20
 .PHONY: all
 all: build
@@ -28,8 +39,14 @@ clean:
 mrproper: clean
     rm -f *~
=20
-$(BIN): $(OBJS)
-    $(CC) $(LDFLAGS) $^ $(LIBS) -o $@
+$(BIN): $(MAINS) $(MGRLIB) $(VTSPLIB)
+    $(CC) $(CFLAGS) $(LDFLAGS) $^ $(LIBS) -o $@
+
+$(VTSPLIB): $(VTSPOBJS)
+    $(AR) rcs $@ $^
+
+$(MGRLIB): $(OBJS)
+    $(AR) rcs $@ $^
=20
 # libraries
 LIBS +=3D ../tcs/libTCS.a ../util/libTCGUtils.a ../crypto/libtcpaCrypto.=
a
diff --git a/tools/vtpm_manager/manager/dmictl.c
b/tools/vtpm_manager/manager/dmictl.c
--- a/tools/vtpm_manager/manager/dmictl.c
+++ b/tools/vtpm_manager/manager/dmictl.c
@@ -40,6 +40,9 @@
 #include <stdio.h>
 #include <unistd.h>
 #include <string.h>
+#include <fcntl.h>
+#include <inttypes.h>
+#include <stdlib.h>
=20
 #include "vtpmpriv.h"
 #include "bsg.h"
@@ -51,6 +54,13 @@
=20
 #define TPM_EMULATOR_PATH "/usr/bin/vtpmd"
=20
+#ifndef VTPM_STUBDOM
+// This is needed to all extra_close_dmi to close this to prevent a
+// broken pipe when no DMIs are left.
+vtpm_ipc_handle_t *g_rx_tpm_ipc_h;
+#endif
+
+
 // if dmi_res is non-null, then return a pointer to new object.
 // Also, this does not fill in the measurements. They should be filled b=
y
 // design dependent code or saveNVM
@@ -81,7 +91,7 @@ TPM_RESULT init_dmi(UINT32 dmi_id, BYTE dmi_type,
VTPM_DMI_RESOURCE **dmi_res) {
=20
   // install into map
   if (!hashtable_insert(vtpm_globals->dmi_map, dmi_id_key, new_dmi)){
-    vtpmlogerror(VTPM_LOG_VTPM, "Failed to insert instance into table.
Aborting.\n", dmi_id);
+    vtpmlogerror(VTPM_LOG_VTPM, "Failed to insert instance %" PRIu32
"into table. Aborting.\n", dmi_id);
     status =3D TPM_FAIL;
     goto abort_egress;
   }
@@ -116,6 +126,161 @@ TPM_RESULT close_dmi(VTPM_DMI_RESOURCE *dmi_res) {
=20
   return (VTPM_Close_DMI_Extra(dmi_res) );
 }
+
+void free_dmi(VTPM_DMI_RESOURCE *dmi_res) {
+   if(dmi_res !=3D NULL) {
+      free(dmi_res->NVMLocation);
+   }
+   free(dmi_res);
+}
+
+TPM_RESULT VTPM_New_DMI_Extra(VTPM_DMI_RESOURCE *dmi_res, BYTE vm_type,
BYTE startup_mode) {
+
+  TPM_RESULT status =3D TPM_SUCCESS;
+#ifndef VTPM_STUBDOM
+  int fh;
+  char dmi_id_str[11]; // UINT32s are up to 10 digits + NULL
+  char *tx_vtpm_name, *tx_tpm_name, *vm_type_string;
+  struct stat file_info;
+
+  if (dmi_res->dmi_id =3D=3D VTPM_CTL_DM) {
+    dmi_res->tx_tpm_ipc_h =3D NULL;
+    dmi_res->rx_tpm_ipc_h =3D NULL;
+    dmi_res->tx_vtpm_ipc_h =3D NULL;
+    dmi_res->rx_vtpm_ipc_h =3D NULL;
+  } else {
+    // Create a pair of fifo pipes
+    dmi_res->rx_tpm_ipc_h =3D NULL;
+    dmi_res->rx_vtpm_ipc_h =3D NULL;
+
+    if ( ((dmi_res->tx_tpm_ipc_h =3D (vtpm_ipc_handle_t *) malloc
(sizeof(vtpm_ipc_handle_t))) =3D=3D NULL ) ||
+         ((dmi_res->tx_vtpm_ipc_h =3D(vtpm_ipc_handle_t *) malloc
(sizeof(vtpm_ipc_handle_t))) =3D=3D NULL ) ||
+         ((tx_tpm_name =3D (char *) malloc(11 +
strlen(VTPM_TX_TPM_FNAME))) =3D=3D NULL ) ||
+         ((tx_vtpm_name =3D(char *) malloc(11 +
strlen(VTPM_TX_VTPM_FNAME))) =3D=3D NULL) ) {
+      status =3DTPM_RESOURCES;
+      goto abort_egress;
+    }
+
+    sprintf(tx_tpm_name, VTPM_TX_TPM_FNAME, (uint32_t) dmi_res->dmi_id);=

+    sprintf(tx_vtpm_name, VTPM_TX_VTPM_FNAME, (uint32_t) dmi_res->dmi_id=
);
+
+    if ( (vtpm_ipc_init(dmi_res->tx_tpm_ipc_h, tx_tpm_name, O_WRONLY |
O_NONBLOCK, TRUE, FALSE) !=3D 0) ||
+         (vtpm_ipc_init(dmi_res->tx_vtpm_ipc_h, tx_vtpm_name, O_WRONLY,
TRUE, FALSE) !=3D 0) ) { //FIXME: O_NONBLOCK?
+      status =3D TPM_IOERROR;
+      goto abort_egress;
+    }
+
+    // Measure DMI
+    // FIXME: This will measure DMI. Until then use a fixed
DMI_Measurement value
+    // Also, this mechanism is specific to 1 VM architecture.
+    /*
+    fh =3D open(TPM_EMULATOR_PATH, O_RDONLY);
+    stat_ret =3D fstat(fh, &file_stat);
+    if (stat_ret =3D=3D 0)
+      dmi_size =3D file_stat.st_size;
+    else {
+      vtpmlogerror(VTPM_LOG_VTPM, "Could not open vtpmd!!\n");
+      status =3D TPM_IOERROR;
+      goto abort_egress;
+    }
+    dmi_buffer
+    */
+    memset(&dmi_res->DMI_measurement, 0xcc, sizeof(TPM_DIGEST));
+
+    if (vm_type =3D=3D VTPM_TYPE_PVM)
+      vm_type_string =3D (BYTE *)&VTPM_TYPE_PVM_STRING;
+    else
+      vm_type_string =3D (BYTE *)&VTPM_TYPE_HVM_STRING;
+
+    // Launch DMI
+    sprintf(dmi_id_str, "%d", (int) dmi_res->dmi_id);
+#ifdef MANUAL_DM_LAUNCH
+    vtpmlogerror(VTPM_LOG_VTPM, "Manually start VTPM with dmi=3D%s
now.\n", dmi_id_str);
+    dmi_res->dmi_pid =3D 0;
+#else
+    pid_t pid =3D fork();
+
+    if (pid =3D=3D -1) {
+      vtpmlogerror(VTPM_LOG_VTPM, "Could not fork to launch vtpm\n");
+      status =3D TPM_RESOURCES;
+      goto abort_egress;
+    } else if (pid =3D=3D 0) {
+      switch (startup_mode) {
+      case TPM_ST_CLEAR:
+        execl (TPM_EMULATOR_PATH, "vtpmd", "clear", vm_type_string,
dmi_id_str, NULL);
+        break;
+      case TPM_ST_STATE:
+        execl (TPM_EMULATOR_PATH, "vtpmd", "save", vm_type_string,
dmi_id_str, NULL);
+        break;
+      case TPM_ST_DEACTIVATED:
+        execl (TPM_EMULATOR_PATH, "vtpmd", "deactivated",
vm_type_string, dmi_id_str, NULL);
+        break;
+      default:
+        status =3D TPM_BAD_PARAMETER;
+        goto abort_egress;
+      }
+
+      // Returning from these at all is an error.
+      vtpmlogerror(VTPM_LOG_VTPM, "Could not exec to launch vtpm\n");
+    } else {
+      dmi_res->dmi_pid =3D pid;
+      vtpmloginfo(VTPM_LOG_VTPM, "Launching DMI on PID =3D %d\n", pid);
+    }
+#endif // MANUAL_DM_LAUNCH
+
+  } // If DMI =3D VTPM_CTL_DM
+    status =3D TPM_SUCCESS;
+#endif
+
+abort_egress:
+    //FIXME: Everything should be freed here
+  return (status);
+}
+
+TPM_RESULT VTPM_Close_DMI_Extra(VTPM_DMI_RESOURCE *dmi_res) {
+  TPM_RESULT status =3D TPM_SUCCESS;
+
+#ifndef VTPM_STUBDOM
+  if (vtpm_globals->connected_dmis =3D=3D 0) {
+    // No more DMI's connected. Close fifo to prevent a broken pipe.
+    // This is hackish. Need to think of another way.
+    vtpm_ipc_close(g_rx_tpm_ipc_h);
+  }
+
+
+  if (dmi_res->dmi_id !=3D VTPM_CTL_DM) {
+    vtpm_ipc_close(dmi_res->tx_tpm_ipc_h);
+    vtpm_ipc_close(dmi_res->tx_vtpm_ipc_h);
+
+    free(dmi_res->tx_tpm_ipc_h->name);
+    free(dmi_res->tx_vtpm_ipc_h->name);
+    free(dmi_res->tx_tpm_ipc_h);
+    free(dmi_res->tx_vtpm_ipc_h);
+
+#ifndef MANUAL_DM_LAUNCH
+    if (dmi_res->dmi_id !=3D VTPM_CTL_DM) {
+      if (dmi_res->dmi_pid !=3D 0) {
+        vtpmloginfo(VTPM_LOG_VTPM, "Killing dmi on pid %d.\n",
dmi_res->dmi_pid);
+        if (kill(dmi_res->dmi_pid, SIGKILL) !=3D0) {
+          vtpmloginfo(VTPM_LOG_VTPM, "DMI on pid %d is already
dead.\n", dmi_res->dmi_pid);
+        } else if (waitpid(dmi_res->dmi_pid, NULL, 0) !=3D
dmi_res->dmi_pid) {
+          vtpmlogerror(VTPM_LOG_VTPM, "DMI on pid %d failed to
stop.\n", dmi_res->dmi_pid);
+          status =3D TPM_FAIL;
+        }
+      } else {
+        vtpmlogerror(VTPM_LOG_VTPM, "Could not kill dmi because it's
pid was 0.\n");
+        status =3D TPM_FAIL;
+      }
+    }
+#endif
+
+  } //endif ! dom0
+#endif
+  return status;
+}
+
+
+
   =20
 TPM_RESULT VTPM_Handle_New_DMI(const buffer_t *param_buf) {
 =20
@@ -254,7 +419,7 @@ TPM_RESULT VTPM_Handle_Delete_DMI( const buffer_t
*param_buf) {
 =20
   // Close DMI first
   TPMTRYRETURN(close_dmi( dmi_res ));
-  free ( dmi_res );
+  free_dmi(dmi_res);
   =20
   status=3DTPM_SUCCESS;  =20
   goto egress;
diff --git a/tools/vtpm_manager/manager/migration.c
b/tools/vtpm_manager/manager/migration.c
--- a/tools/vtpm_manager/manager/migration.c
+++ b/tools/vtpm_manager/manager/migration.c
@@ -40,6 +40,7 @@
 #include <stdio.h>
 #include <unistd.h>
 #include <string.h>
+#include <stdlib.h>
=20
 #include "vtpmpriv.h"
 #include "bsg.h"
@@ -263,7 +264,7 @@ TPM_RESULT VTPM_Handle_Get_Migration_key( const
buffer_t *param_buf,
 TPM_RESULT VTPM_Handle_Load_Migration_key( const buffer_t *param_buf,
                                            buffer_t *result_buf) {
=20
-  TPM_RESULT status=3DTPM_FAIL;
+  TPM_RESULT status=3DTPM_SUCCESS;
   VTPM_MIGKEY_LIST *mig_key;
=20
   vtpmloginfo(VTPM_LOG_VTPM, "Loading Migration Public Key.\n");
@@ -303,5 +304,5 @@ TPM_RESULT VTPM_Handle_Load_Migration_key( const
buffer_t *param_buf,
   free(pubkey_exp_pack.data);
   free(pubkey_mod_pack.data);
=20
-  return TPM_SUCCESS;
+  return status;
 }
diff --git a/tools/vtpm_manager/manager/securestorage.c
b/tools/vtpm_manager/manager/securestorage.c
--- a/tools/vtpm_manager/manager/securestorage.c
+++ b/tools/vtpm_manager/manager/securestorage.c
@@ -42,7 +42,7 @@
 #include <fcntl.h>
 #include <unistd.h>
 #include <string.h>
-
+#include <stdlib.h>
 #include "tcg.h"
 #include "vtpm_manager.h"
 #include "vtpmpriv.h"
@@ -58,7 +58,7 @@ TPM_RESULT envelope_encrypt(const buffer_t     *inbuf,
                             CRYPTO_INFO        *asymkey,
                             buffer_t           *sealed_data) {
   TPM_RESULT status =3D TPM_SUCCESS;
-  symkey_t    symkey;
+  symkey_t    *symkey;
   buffer_t    data_cipher =3D NULL_BUF,
               symkey_cipher =3D NULL_BUF;
 =20
@@ -69,14 +69,14 @@ TPM_RESULT envelope_encrypt(const buffer_t     *inbuf=
,
   for (i=3D0; i< buffer_len(inbuf); i++)
     vtpmloginfomore(VTPM_LOG_VTPM_DEEP, "%x ", inbuf->bytes[i]);
   vtpmloginfomore(VTPM_LOG_VTPM_DEEP, "\n");
-=20
+
   // Generate a sym key and encrypt state with it
   TPMTRY(TPM_ENCRYPT_ERROR, Crypto_symcrypto_genkey (&symkey) );
-  TPMTRY(TPM_ENCRYPT_ERROR, Crypto_symcrypto_encrypt (&symkey, inbuf,
&data_cipher) );
+  TPMTRY(TPM_ENCRYPT_ERROR, Crypto_symcrypto_encrypt (symkey, inbuf,
&data_cipher) );
 =20
   // Encrypt symmetric key
   TPMTRYRETURN( VTSP_Bind(    asymkey,
-                  &symkey.key,
+                  Crypto_symkey_getkey(symkey),
                   &symkey_cipher) );
 =20
   // Create output blob: symkey_size + symkey_cipher +
state_cipher_size + state_cipher
@@ -86,8 +86,9 @@ TPM_RESULT envelope_encrypt(const buffer_t     *inbuf,
 =20
   data_cipher32.size =3D buffer_len(&data_cipher);
   data_cipher32.data =3D data_cipher.bytes;
-=20
+
   TPMTRYRETURN( buffer_init(sealed_data, 2 * sizeof(UINT32) +
symkey_cipher32.size + data_cipher32.size, NULL));
+  memset(sealed_data->bytes, 0, sealed_data->size);
 =20
   BSG_PackList(sealed_data->bytes, 2,
            BSG_TPM_SIZE32_DATA, &symkey_cipher32,
@@ -109,11 +110,37 @@ TPM_RESULT envelope_encrypt(const buffer_t     *inb=
uf,
 =20
   buffer_free ( &data_cipher);
   buffer_free ( &symkey_cipher);
-  Crypto_symcrypto_freekey (&symkey);
+  Crypto_symcrypto_freekey (symkey);
 =20
   return status;
 }
=20
+TPM_RESULT symkey_encrypt(const buffer_t     *inbuf,
+                            CRYPTO_INFO        *asymkey,
+                            buffer_t           *sealed_key) {
+  buffer_t symkey_cipher =3D NULL_BUF;
+  struct pack_constbuf_t symkey_cipher32;
+  TPM_RESULT status =3D TPM_SUCCESS;
+
+  // Encrypt symmetric key
+  TPMTRYRETURN( VTSP_Bind(    asymkey,
+                  inbuf,
+                  &symkey_cipher));
+
+  symkey_cipher32.size =3D buffer_len(&symkey_cipher);
+  symkey_cipher32.data =3D symkey_cipher.bytes;
+
+  TPMTRYRETURN( buffer_init(sealed_key, sizeof(UINT32) +
symkey_cipher32.size, NULL));
+  BSG_PackList(sealed_key->bytes, 1,
+           BSG_TPM_SIZE32_DATA, &symkey_cipher32);
+  goto egress;
+abort_egress:
+egress:
+  buffer_free( &symkey_cipher);
+  return status;
+}
+=20
+
 TPM_RESULT envelope_decrypt(const buffer_t     *cipher,
                             TCS_CONTEXT_HANDLE TCSContext,
                 TPM_HANDLE         keyHandle,
@@ -121,15 +148,13 @@ TPM_RESULT envelope_decrypt(const buffer_t   =20
*cipher,
                             buffer_t           *unsealed_data) {
=20
   TPM_RESULT status =3D TPM_SUCCESS;
-  symkey_t    symkey;
+  symkey_t    *symkey;
   buffer_t    data_cipher =3D NULL_BUF,
               symkey_clear =3D NULL_BUF,
               symkey_cipher =3D NULL_BUF;
-  struct pack_buf_t symkey_cipher32, data_cipher32;
+  struct pack_buf_t symkey_cipher32 =3D NULL_PACK_BUF, data_cipher32 =3D=

NULL_PACK_BUF;
   int i;
=20
-  memset(&symkey, 0, sizeof(symkey_t));
-
   vtpmloginfo(VTPM_LOG_VTPM_DEEP, "Envelope Decrypt Input[%d]: 0x",
buffer_len(cipher) );
   for (i=3D0; i< buffer_len(cipher); i++)
     vtpmloginfomore(VTPM_LOG_VTPM_DEEP, "%x ", cipher->bytes[i]);
@@ -159,7 +184,7 @@ TPM_RESULT envelope_decrypt(const buffer_t     *ciphe=
r,
   Crypto_symcrypto_initkey (&symkey, &symkey_clear);
 =20
   // Decrypt State
-  TPMTRY(TPM_DECRYPT_ERROR, Crypto_symcrypto_decrypt (&symkey,
&data_cipher, unsealed_data) );
+  TPMTRY(TPM_DECRYPT_ERROR, Crypto_symcrypto_decrypt (symkey,
&data_cipher, unsealed_data) );
=20
   vtpmloginfo(VTPM_LOG_VTPM_DEEP, "Envelope Decrypte Output[%d]: 0x",
buffer_len(unsealed_data));
   for (i=3D0; i< buffer_len(unsealed_data); i++)
@@ -175,26 +200,64 @@ TPM_RESULT envelope_decrypt(const buffer_t   =20
*cipher,
   buffer_free ( &data_cipher);
   buffer_free ( &symkey_clear);
   buffer_free ( &symkey_cipher);
-  Crypto_symcrypto_freekey (&symkey);
+  BSG_Destroy(BSG_TPM_SIZE32_DATA, &symkey_cipher32);
+  BSG_Destroy(BSG_TPM_SIZE32_DATA, &data_cipher32);
+  Crypto_symcrypto_freekey (symkey);
+
 =20
   return status;
 }
=20
+TPM_RESULT symkey_decrypt(const buffer_t     *cipher,
+                            TCS_CONTEXT_HANDLE TCSContext,
+                TPM_HANDLE         keyHandle,
+                const TPM_AUTHDATA *key_usage_auth,
+                            buffer_t           *symkey_clear) {
+
+  TPM_RESULT status =3D TPM_SUCCESS;
+  buffer_t    symkey_cipher =3D NULL_BUF;
+  struct pack_buf_t symkey_cipher32 =3D NULL_PACK_BUF;
+
+  BSG_UnpackList(cipher->bytes, 1,
+         BSG_TPM_SIZE32_DATA, &symkey_cipher32);
+=20
+  TPMTRYRETURN( buffer_init_alias_convert (&symkey_cipher,
+                           symkey_cipher32.size,
+                           symkey_cipher32.data) );
+=20
+  // Decrypt Symmetric Key
+  TPMTRYRETURN( VTSP_Unbind(  TCSContext,
+                  keyHandle,
+                  &symkey_cipher,
+                  key_usage_auth,
+                  symkey_clear,
+                  &(vtpm_globals->keyAuth) ) );
+=20
+  goto egress;
+ abort_egress:
+  vtpmlogerror(VTPM_LOG_VTPM, "Failed to decrypt symmetric key
status=3D%d\n.", status);
+=20
+ egress:
+  BSG_Destroy(BSG_TPM_SIZE32_DATA, &symkey_cipher32);
+  return status;
+}
+
 TPM_RESULT VTPM_Handle_Save_NVM(VTPM_DMI_RESOURCE *myDMI,
                 const buffer_t *inbuf,
                 buffer_t *outbuf) {
 =20
   TPM_RESULT status =3D TPM_SUCCESS;
-  int fh;
+  int fh =3D -1;
   long bytes_written;
   buffer_t sealed_NVM =3D NULL_BUF;
-=20
-  vtpmloginfo(VTPM_LOG_VTPM_DEEP, "Saving %d bytes of NVM.\n",
buffer_len(inbuf));
+  const buffer_t* nvmbuf =3D inbuf;
+
+  vtpmloginfo(VTPM_LOG_VTPM_DEEP, "Saving %d bytes of NVM.\n",
buffer_len(nvmbuf));
=20
-  TPMTRYRETURN( envelope_encrypt(inbuf,
+  TPMTRYRETURN( envelope_encrypt(nvmbuf,
                                  &vtpm_globals->storageKey,
                                  &sealed_NVM) );
-                =20
+
   // Write sealed blob off disk from NVMLocation
   // TODO: How to properly return from these. Do we care if we return
failure
   //       after writing the file? We can't get the old one back.
@@ -205,7 +268,6 @@ TPM_RESULT VTPM_Handle_Save_NVM(VTPM_DMI_RESOURCE
*myDMI,
     status =3D TPM_IOERROR;
     goto abort_egress;
   }
-  close(fh);
 =20
   Crypto_SHA1Full (sealed_NVM.bytes, buffer_len(&sealed_NVM), (BYTE *)
&myDMI->NVM_measurement); =20
 =20
@@ -215,6 +277,7 @@ TPM_RESULT VTPM_Handle_Save_NVM(VTPM_DMI_RESOURCE
*myDMI,
   vtpmlogerror(VTPM_LOG_VTPM, "Failed to save NVM\n.");
 =20
  egress:
+  close(fh);
   buffer_free(&sealed_NVM);
   return status;
 }
@@ -229,7 +292,8 @@ TPM_RESULT VTPM_Handle_Load_NVM(VTPM_DMI_RESOURCE
*myDMI,
=20
   buffer_t sealed_NVM =3D NULL_BUF;
   long fh_size;
-  int fh, stat_ret, i;
+  int fh =3D -1;
+  int stat_ret, i;
   struct stat file_stat;
   TPM_DIGEST sealedNVMHash;
  =20
@@ -241,6 +305,7 @@ TPM_RESULT VTPM_Handle_Load_NVM(VTPM_DMI_RESOURCE
*myDMI,
 =20
   //Read sealed blob off disk from NVMLocation
   fh =3D open(myDMI->NVMLocation, O_RDONLY);
+  printf("Filename: %s\n", myDMI->NVMLocation);
   stat_ret =3D fstat(fh, &file_stat);
   if (stat_ret =3D=3D 0)
     fh_size =3D file_stat.st_size;
@@ -254,7 +319,6 @@ TPM_RESULT VTPM_Handle_Load_NVM(VTPM_DMI_RESOURCE
*myDMI,
     status =3D TPM_IOERROR;
     goto abort_egress;
   }
-  close(fh);
 =20
   vtpmloginfo(VTPM_LOG_VTPM_DEEP, "Load_NVMing[%d],\n",
buffer_len(&sealed_NVM));
 =20
@@ -289,14 +353,128 @@ TPM_RESULT VTPM_Handle_Load_NVM(VTPM_DMI_RESOURCE
*myDMI,
 =20
  egress:
   buffer_free( &sealed_NVM );
+  close(fh);
+=20
+  return status;
+}
+
+TPM_RESULT VTPM_Handle_Load_HashKey(VTPM_DMI_RESOURCE *myDMI,
+                const buffer_t    *inbuf,
+                buffer_t          *outbuf) {
+=20
+  TPM_RESULT status =3D TPM_SUCCESS;
+
+  buffer_t sealed_NVM =3D NULL_BUF;
+  long fh_size;
+  int fh =3D -1;
+  int stat_ret, i;
+  struct stat file_stat;
+  TPM_DIGEST sealedNVMHash;
+ =20
+  if (myDMI->NVMLocation =3D=3D NULL) {
+    vtpmlogerror(VTPM_LOG_VTPM, "Unable to load NVM because the file
name NULL.\n");
+    status =3D TPM_AUTHFAIL;
+    goto abort_egress;
+  }
+=20
+  //Read sealed blob off disk from NVMLocation
+  fh =3D open(myDMI->NVMLocation, O_RDONLY);
+  printf("Filename: %s\n", myDMI->NVMLocation);
+  stat_ret =3D fstat(fh, &file_stat);
+  if (stat_ret =3D=3D 0)
+    fh_size =3D file_stat.st_size;
+  else {
+    status =3D TPM_IOERROR;
+    goto abort_egress;
+  }
+=20
+  TPMTRYRETURN( buffer_init( &sealed_NVM, fh_size, NULL) );
+  if (read(fh, sealed_NVM.bytes, buffer_len(&sealed_NVM)) !=3D fh_size) =
{
+    status =3D TPM_IOERROR;
+    goto abort_egress;
+  }
+=20
+  vtpmloginfo(VTPM_LOG_VTPM_DEEP, "Loading %d byte encryption key,\n",
buffer_len(&sealed_NVM));
+=20
+  Crypto_SHA1Full(sealed_NVM.bytes, buffer_len(&sealed_NVM), (BYTE *)
&sealedNVMHash);  =20
+=20
+  // Verify measurement of sealed blob.
+  if (memcmp(&sealedNVMHash, &myDMI->NVM_measurement,
sizeof(TPM_DIGEST)) ) {
+    vtpmlogerror(VTPM_LOG_VTPM, "VTPM LoadKey NVM measurement check
failed.\n");
+    vtpmloginfo(VTPM_LOG_VTPM_DEEP, "Correct hash: ");
+    for (i=3D0; i< sizeof(TPM_DIGEST); i++)
+      vtpmloginfomore(VTPM_LOG_VTPM_DEEP, "%x ",
((BYTE*)&myDMI->NVM_measurement)[i]);
+    vtpmloginfomore(VTPM_LOG_VTPM_DEEP, "\n");
+
+    vtpmloginfo(VTPM_LOG_VTPM_DEEP, "Measured hash: ");
+    for (i=3D0; i< sizeof(TPM_DIGEST); i++)
+      vtpmloginfomore(VTPM_LOG_VTPM_DEEP, "%x ",
((BYTE*)&sealedNVMHash)[i]);
+    vtpmloginfomore(VTPM_LOG_VTPM_DEEP, "\n");
+  =20
+    status =3D TPM_AUTHFAIL;
+    goto abort_egress;
+  }
+=20
+  //Decrypt the key into the output buffer
+  TPMTRYRETURN( symkey_decrypt(&sealed_NVM,
+                                 myDMI->TCSContext,
+                     vtpm_globals->storageKeyHandle,
+                     (const
TPM_AUTHDATA*)&vtpm_globals->storage_key_usage_auth,
+                                 outbuf) );=20
+  goto egress;
+=20
+ abort_egress:
+  vtpmlogerror(VTPM_LOG_VTPM, "Failed to load Key\n.");
+=20
+ egress:
+  buffer_free( &sealed_NVM );
+  close(fh);
+=20
+  return status;
+}
+
+TPM_RESULT VTPM_Handle_Save_HashKey(VTPM_DMI_RESOURCE *myDMI,
+                                 const buffer_t    *inbuf,
+                 buffer_t          *outbuf) {
+  TPM_RESULT status =3D TPM_SUCCESS;
+  int fh =3D -1;
+  long bytes_written;
+  buffer_t sealed_key =3D NULL_BUF;
+=20
+  TPMTRYRETURN( symkey_encrypt(inbuf,
+                                 &vtpm_globals->storageKey,
+                                 &sealed_key) );
+
+  vtpmloginfo(VTPM_LOG_VTPM_DEEP, "Saving %d byte Encryption Key.\n",
buffer_len(inbuf));
+
+  // Write sealed blob off disk from NVMLocation
+  // TODO: How to properly return from these. Do we care if we return
failure
+  //       after writing the file? We can't get the old one back.
+  // TODO: Backup old file and try and recover that way.
+  fh =3D open(myDMI->NVMLocation, O_WRONLY | O_CREAT | O_TRUNC, S_IREAD =
|
S_IWRITE);
+  if ( (bytes_written =3D write(fh, sealed_key.bytes,
buffer_len(&sealed_key) ) !=3D (long) buffer_len(&sealed_key))) {
+    vtpmlogerror(VTPM_LOG_VTPM, "We just overwrote a DMI_NVM and failed
to finish. %ld/%ld bytes.\n", bytes_written, (long)buffer_len(&sealed_key=
));
+    status =3D TPM_IOERROR;
+    goto abort_egress;
+  }
 =20
+  Crypto_SHA1Full (sealed_key.bytes, buffer_len(&sealed_key), (BYTE *)
&myDMI->NVM_measurement); =20
+=20
+  goto egress;
+=20
+ abort_egress:
+  vtpmlogerror(VTPM_LOG_VTPM, "Failed to save Key\n.");
+=20
+ egress:
+  close(fh);
+  buffer_free(&sealed_key);
   return status;
 }
=20
=20
 TPM_RESULT VTPM_SaveManagerData(void) {
   TPM_RESULT status=3DTPM_SUCCESS;
-  int fh, dmis=3D-1;
+  int fh =3D -1, dmis=3D-1;
=20
   BYTE *flat_boot_key=3DNULL, *flat_dmis=3DNULL, *flat_enc=3DNULL;
   buffer_t clear_flat_global=3DNULL_BUF, enc_flat_global=3DNULL_BUF;
@@ -364,6 +542,7 @@ TPM_RESULT VTPM_SaveManagerData(void) {
                                         BSG_TPM_DIGEST,
&dmi_res->DMI_measurement);
=20
     } while (hashtable_iterator_advance(dmi_itr));
+    free(dmi_itr);
   }
=20
   fh =3D open(STATE_FILE, O_WRONLY | O_CREAT, S_IREAD | S_IWRITE);
@@ -389,6 +568,7 @@ TPM_RESULT VTPM_SaveManagerData(void) {
=20
   free(flat_boot_key);
   free(flat_enc);
+  buffer_free(&clear_flat_global);
   buffer_free(&enc_flat_global);
   free(flat_dmis);
   close(fh);
@@ -403,9 +583,10 @@ TPM_RESULT VTPM_LoadManagerData(void) {
   int fh, stat_ret, dmis=3D0;
   long fh_size =3D 0, step_size;
   BYTE *flat_table=3DNULL;
-  buffer_t  unsealed_data, enc_table_abuf;
-  struct pack_buf_t storage_key_pack, boot_key_pack;
-  UINT32 *dmi_id_key, enc_size;
+  buffer_t  unsealed_data =3D NULL_BUF;
+  buffer_t enc_table_abuf;
+  struct pack_buf_t storage_key_pack =3D NULL_PACK_BUF, boot_key_pack =3D=

NULL_PACK_BUF;
+  UINT32 enc_size;
   BYTE vtpm_manager_gen;
=20
   VTPM_DMI_RESOURCE *dmi_res;
@@ -438,9 +619,9 @@ TPM_RESULT VTPM_LoadManagerData(void) {
                               BSG_TPM_SIZE32_DATA, &boot_key_pack,
                               BSG_TYPE_UINT32, &enc_size);
=20
-  TPMTRYRETURN(buffer_init(&vtpm_globals->bootKeyWrap, 0, 0) );
   TPMTRYRETURN(buffer_init_alias_convert(&enc_table_abuf, enc_size,
flat_table + step_size) );
-  TPMTRYRETURN(buffer_append_raw(&vtpm_globals->bootKeyWrap,
boot_key_pack.size, boot_key_pack.data) );
+  TPMTRYRETURN(buffer_init(&vtpm_globals->bootKeyWrap,
boot_key_pack.size, boot_key_pack.data) );
+
=20
   //Load Boot Key
   TPMTRYRETURN( VTSP_LoadKey( vtpm_globals->manager_tcs_handle,
@@ -471,8 +652,8 @@ TPM_RESULT VTPM_LoadManagerData(void) {
                   BSG_TPM_SECRET,   &vtpm_globals->storage_key_usage_aut=
h,
                   BSG_TPM_SIZE32_DATA, &storage_key_pack);
=20
-  TPMTRYRETURN(buffer_init(&vtpm_globals->storageKeyWrap, 0, 0) );
-  TPMTRYRETURN(buffer_append_raw(&vtpm_globals->storageKeyWrap,
storage_key_pack.size, storage_key_pack.data) );
+  TPMTRYRETURN(buffer_init(&vtpm_globals->storageKeyWrap,
storage_key_pack.size, storage_key_pack.data) );
+
=20
   // Per DMI values to be saved
   while ( step_size < fh_size ){
@@ -501,7 +682,10 @@ TPM_RESULT VTPM_LoadManagerData(void) {
  abort_egress:
   vtpmlogerror(VTPM_LOG_VTPM, "Failed to load service data with error =3D=

%s\n", tpm_get_error_name(status));
  egress:
+  BSG_Destroy(BSG_TPM_SIZE32_DATA, &boot_key_pack);
+  BSG_Destroy(BSG_TPM_SIZE32_DATA, &storage_key_pack);
=20
+  buffer_free(&unsealed_data);
   free(flat_table);
   close(fh);
=20
diff --git a/tools/vtpm_manager/manager/vtpm_ipc.c
b/tools/vtpm_manager/manager/vtpm_ipc.c
--- a/tools/vtpm_manager/manager/vtpm_ipc.c
+++ b/tools/vtpm_manager/manager/vtpm_ipc.c
@@ -36,26 +36,49 @@
 //
 // =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
=20
+#include <sys/types.h>
 #include <sys/stat.h>
+#include <fcntl.h>
+#include <unistd.h>
+#include <sys/select.h>
 #include "vtpm_ipc.h"
 #include "vtpmpriv.h"
 #include "log.h"
=20
-int vtpm_ipc_init(vtpm_ipc_handle_t *ipc_h, char* name, int flags, BOOL
create) {
+volatile sig_atomic_t IPC_QUIT_FLAG =3D 0;
+
+const static struct timeval TIMEOUT =3D {
+   .tv_sec =3D 1,
+   .tv_usec =3D 0
+};
+
+int vtpm_ipc_init(vtpm_ipc_handle_t *ipc_h, char* name, int flags, BOOL
create, BOOL preopen) {
+  int rc;
+
   ipc_h->name =3D name;
   ipc_h->flags =3D flags;
   ipc_h->fh =3D VTPM_IPC_CLOSED;
=20
-  if (create)
-    return(vtpm_ipc_create(ipc_h));
-  else
-    return 0;
+  if (create) {
+    if((rc =3D vtpm_ipc_create(ipc_h) !=3D 0)) {
+       return rc;
+    }
+  }
+
+  if(preopen) {
+    ipc_h->fh =3D open(ipc_h->name, ipc_h->flags);
+    if ( ipc_h->fh =3D=3D VTPM_IPC_CLOSED ) {
+       vtpmlogerror(VTPM_LOG_VTPM, "VTPM ERROR: Can't open %s\n",
ipc_h->name);
+       return -1;
+    }
+  }
+  return 0;
+
 }
=20
 // Create the file that needs opening. Used only for FIFOs
 // FYI: This may cause problems in other file IO schemes. We'll see.
 int vtpm_ipc_create(vtpm_ipc_handle_t *ipc_h) {
-  int fh;
   struct stat file_info;
=20
   if ((!ipc_h) || (!ipc_h->name))
@@ -68,8 +91,6 @@ int vtpm_ipc_create(vtpm_ipc_handle_t *ipc_h) {
     }
   }
=20
-  ipc_h->fh =3D VTPM_IPC_CLOSED;
-
   return 0;
 }
=20
@@ -78,6 +99,8 @@ int vtpm_ipc_create(vtpm_ipc_handle_t *ipc_h) {
 int vtpm_ipc_read(vtpm_ipc_handle_t *ipc_h, vtpm_ipc_handle_t
*alt_ipc_h, BYTE *bytes, UINT32 size){
   vtpm_ipc_handle_t *my_ipc_h;
   int result;
+  fd_set fds;
+  struct timeval timeout;
 =20
   if (ipc_h) {
     my_ipc_h =3D ipc_h;
@@ -94,9 +117,19 @@ int vtpm_ipc_read(vtpm_ipc_handle_t *ipc_h,
vtpm_ipc_handle_t *alt_ipc_h, BYTE *
     return -1;
   }
=20
+  FD_ZERO(&fds);
+  while(!FD_ISSET( my_ipc_h->fh, &fds )) {
+     timeout =3D TIMEOUT;
+     if (IPC_QUIT_FLAG) {
+    return -1;
+     }
+     FD_SET(my_ipc_h->fh, &fds);
+     select(my_ipc_h->fh + 1, &fds, NULL, NULL, &timeout);
+  }
+
   result =3D read(my_ipc_h->fh, bytes, size);
   if (result < 0) {
-    my_ipc_h->fh =3D VTPM_IPC_CLOSED;
+     my_ipc_h->fh =3D VTPM_IPC_CLOSED;
   }
=20
   return (result);
@@ -106,6 +139,8 @@ int vtpm_ipc_read(vtpm_ipc_handle_t *ipc_h,
vtpm_ipc_handle_t *alt_ipc_h, BYTE *
 int vtpm_ipc_write(vtpm_ipc_handle_t *ipc_h, vtpm_ipc_handle_t
*alt_ipc_h, BYTE *bytes, UINT32 size) {
   vtpm_ipc_handle_t *my_ipc_h;
   int result;
+  fd_set fds;
+  struct timeval timeout;
=20
   if (ipc_h) {
     my_ipc_h =3D ipc_h;
@@ -122,6 +157,16 @@ int vtpm_ipc_write(vtpm_ipc_handle_t *ipc_h,
vtpm_ipc_handle_t *alt_ipc_h, BYTE
     return -1;
   }
=20
+  FD_ZERO(&fds);
+  while(!FD_ISSET( my_ipc_h->fh, &fds )) {
+     timeout =3D TIMEOUT;
+     if (IPC_QUIT_FLAG) {
+    return -1;
+     }
+     FD_SET(my_ipc_h->fh, &fds);
+     select(my_ipc_h->fh + 1, NULL, &fds, NULL, &timeout);
+  }
+
   result =3D write(my_ipc_h->fh, bytes, size);
   if (result < 0) {
     my_ipc_h->fh =3D VTPM_IPC_CLOSED;
diff --git a/tools/vtpm_manager/manager/vtpm_ipc.h
b/tools/vtpm_manager/manager/vtpm_ipc.h
--- a/tools/vtpm_manager/manager/vtpm_ipc.h
+++ b/tools/vtpm_manager/manager/vtpm_ipc.h
@@ -39,10 +39,14 @@
 #ifndef __VTPM_IO_H__
 #define __VTPM_IO_H__
=20
+#include <signal.h>
+
 #include "tcg.h"
=20
 #define VTPM_IPC_CLOSED -1
=20
+extern volatile sig_atomic_t IPC_QUIT_FLAG;
+
 // Represents an (somewhat) abstracted io handle.
 typedef struct vtpm_ipc_handle_t {
   int fh;              // IO handle.
@@ -53,7 +57,7 @@ typedef struct vtpm_ipc_handle_t {
 } vtpm_ipc_handle_t;
=20
=20
-int vtpm_ipc_init(vtpm_ipc_handle_t *ioh, char* name, int flags, BOOL
create);
+int vtpm_ipc_init(vtpm_ipc_handle_t *ioh, char* name, int flags, BOOL
create, BOOL preopen);
=20
 // Create the file that needs opening. Used only for FIFOs
 // FYI: This may cause problems in other file IO schemes. We'll see.
diff --git a/tools/vtpm_manager/manager/vtpm_lock.c
b/tools/vtpm_manager/manager/vtpm_lock.c
--- a/tools/vtpm_manager/manager/vtpm_lock.c
+++ b/tools/vtpm_manager/manager/vtpm_lock.c
@@ -40,24 +40,24 @@
=20
 static pthread_rwlock_t vtpm_lock;
=20
-void vtpm_lock_init() {
+void vtpm_lock_init(void) {
=20
   pthread_rwlock_init( &vtpm_lock, NULL);
 }
=20
-void vtpm_lock_destroy(){
+void vtpm_lock_destroy(void){
   pthread_rwlock_destroy(&vtpm_lock);
 }
=20
-void vtpm_lock_rdlock(){
+void vtpm_lock_rdlock(void){
   pthread_rwlock_rdlock(&vtpm_lock);
 }
=20
-void vtpm_lock_wrlock(){
+void vtpm_lock_wrlock(void){
   pthread_rwlock_wrlock(&vtpm_lock);
 }
=20
-void vtpm_lock_unlock(){
+void vtpm_lock_unlock(void){
   pthread_rwlock_unlock(&vtpm_lock);
 }
=20
diff --git a/tools/vtpm_manager/manager/vtpm_lock.h
b/tools/vtpm_manager/manager/vtpm_lock.h
--- a/tools/vtpm_manager/manager/vtpm_lock.h
+++ b/tools/vtpm_manager/manager/vtpm_lock.h
@@ -38,11 +38,11 @@
 #ifndef __VTPM_LOCK_H__
 #define __VTPM_LOCK_H__
=20
-void vtpm_lock_init();
-void vtpm_lock_destroy();
+void vtpm_lock_init(void);
+void vtpm_lock_destroy(void);
=20
-void vtpm_lock_rdlock();
-void vtpm_lock_wrlock();
-void vtpm_lock_unlock();
+void vtpm_lock_rdlock(void);
+void vtpm_lock_wrlock(void);
+void vtpm_lock_unlock(void);
=20
 #endif
diff --git a/tools/vtpm_manager/manager/vtpm_manager.c
b/tools/vtpm_manager/manager/vtpm_manager.c
--- a/tools/vtpm_manager/manager/vtpm_manager.c
+++ b/tools/vtpm_manager/manager/vtpm_manager.c
@@ -40,10 +40,12 @@
 #include <stdio.h>
 #include <unistd.h>
 #include <string.h>
+#include <stdlib.h>
=20
 #include "vtpm_manager.h"
 #include "vtpmpriv.h"
 #include "vtsp.h"
+#include "tpmddl.h"
 #include "bsg.h"
 #include "hashtable.h"
 #include "hashtable_itr.h"
@@ -54,8 +56,8 @@
 VTPM_GLOBALS *vtpm_globals=3DNULL;
=20
 // --------------------------- Well Known Auths ------------------------=
--
-const TPM_AUTHDATA SRK_AUTH =3D {0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
0xff, 0xff, 0xff, 0xff,
-                                  0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
0xff, 0xff, 0xff, 0xff};
+const TPM_AUTHDATA SRK_AUTH =3D {0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00,
+                                  0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00};
=20
 #ifdef WELL_KNOWN_OWNER_AUTH
 static BYTE FIXED_OWNER_AUTH[20] =3D  {0xff, 0xff, 0xff, 0xff, 0xff,
0xff, 0xff, 0xff, 0xff, 0xff,
@@ -74,7 +76,6 @@ static int equals32(void *k1, void *k2) {
 }
=20
 // --------------------------- Functions ------------------------------
-
 TPM_RESULT VTPM_Create_Manager(){
 =20
   TPM_RESULT status =3D TPM_SUCCESS;
@@ -104,6 +105,7 @@ TPM_RESULT VTPM_Create_Manager(){
     TPMTRYRETURN(VTSP_DisablePubekRead(vtpm_globals->manager_tcs_handle,=

                                        (const
TPM_AUTHDATA*)&vtpm_globals->owner_usage_auth,=20
                                        &vtpm_globals->keyAuth));   =20
+    Crypto_RSACryptoInfoFree(&ek_cryptoInfo);
   } else {
     vtpmloginfo(VTPM_LOG_VTPM, "Failed to readEK meaning TPM has an
owner. Creating Keys off existing SRK.\n");
   }
@@ -181,7 +183,7 @@ TPM_RESULT VTPM_Create_Manager(){
 }
=20
 ////////////////////////////////////////////////////////////////////////=
///////
-TPM_RESULT VTPM_Init_Manager() {
+TPM_RESULT VTPM_Init_Manager(void) {
   TPM_RESULT status =3D TPM_FAIL, serviceStatus; =20
   BYTE *randomsead;
   UINT32 randomsize=3D256;
@@ -203,6 +205,11 @@ TPM_RESULT VTPM_Init_Manager() {
   vtpm_globals->manager_tcs_handle =3D 0;
=20
   TPMTRYRETURN(TCS_create());
+
+  // Blow away all stale handles left in the tpm
+  if(TDDL_FlushAllResources() !=3D TPM_SUCCESS) {
+     vtpmlogerror(VTPM_LOG_VTPM, "VTPM_FlushResources failed,
continuing anyway..\n");
+  }
 =20
   // Create TCS Context for service
   TPMTRYRETURN( TCS_OpenContext(&vtpm_globals->manager_tcs_handle ) );
@@ -228,7 +235,7 @@ TPM_RESULT VTPM_Init_Manager() {
     TPMTRYRETURN( VTPM_Create_Manager() );  =20
     TPMTRYRETURN( VTPM_SaveManagerData() );
   } else if (serviceStatus !=3D TPM_SUCCESS) {
-    vtpmlogerror(VTPM_LOG_VTPM, "Failed to read existing manager file");=

+    vtpmlogerror(VTPM_LOG_VTPM, "Failed to read existing manager file\n"=
);
     exit(1);
   }
=20
@@ -254,7 +261,7 @@ TPM_RESULT VTPM_Init_Manager() {
 }
=20
 ////////////////////////////////////////////////////////////////////////=
///////

-void VTPM_Stop_Manager() {
+void VTPM_Stop_Manager(void) {
   VTPM_DMI_RESOURCE *dmi_res;
   struct hashtable_itr *dmi_itr;
 =20
@@ -267,7 +274,7 @@ void VTPM_Stop_Manager() {
     close_dmi( dmi_res ); // Not really interested in return code
     =20
     } while (hashtable_iterator_advance(dmi_itr));
-        free (dmi_itr);
+    free (dmi_itr);
   }
 =20
   if ( VTPM_SaveManagerData() !=3D TPM_SUCCESS )
@@ -276,7 +283,21 @@ void VTPM_Stop_Manager() {
   TCS_CloseContext(vtpm_globals->manager_tcs_handle);
   TCS_destroy();
 =20
-  hashtable_destroy(vtpm_globals->dmi_map, 1);
+  if (hashtable_count(vtpm_globals->dmi_map) > 0) {
+    dmi_itr =3D hashtable_iterator(vtpm_globals->dmi_map);
+    do {
+      dmi_res =3D (VTPM_DMI_RESOURCE *) hashtable_iterator_value(dmi_itr=
);
+      free_dmi(dmi_res);
+    } while (hashtable_iterator_advance(dmi_itr));
+    free (dmi_itr);
+  }
+  hashtable_destroy(vtpm_globals->dmi_map, 0);
+
+  /* Cleanup resources */
+  Crypto_RSACryptoInfoFree(&vtpm_globals->bootKey);
+  Crypto_RSACryptoInfoFree(&vtpm_globals->storageKey);
+  buffer_free(&vtpm_globals->bootKeyWrap);
+  buffer_free(&vtpm_globals->storageKeyWrap);
   free(vtpm_globals);
 =20
   Crypto_Exit();
diff --git a/tools/vtpm_manager/manager/vtpm_manager.h
b/tools/vtpm_manager/manager/vtpm_manager.h
--- a/tools/vtpm_manager/manager/vtpm_manager.h
+++ b/tools/vtpm_manager/manager/vtpm_manager.h
@@ -61,6 +61,8 @@
 #define VTPM_ORD_TPMCOMMAND   (VTPM_ORD_BASE + 3) // DMI issues HW TPM
Command
 #define VTPM_ORD_GET_MIG_KEY  (VTPM_ORD_BASE + 4) // Get manager's
migration key
 #define VTPM_ORD_LOAD_MIG_KEY (VTPM_ORD_BASE + 5) // load dest
migration key
+#define VTPM_ORD_SAVEHASHKEY      (VTPM_ORD_BASE + 7) // DMI requests
encryption key for persistent storage
+#define VTPM_ORD_LOADHASHKEY      (VTPM_ORD_BASE + 8) // DMI requests
symkey to be regenerated
=20
 // Priviledged VTPM Commands (From management console)
 #define VTPM_ORD_OPEN         (VTPM_PRIV_BASE + 1) // Creates/reopens DM=
I
@@ -147,4 +149,23 @@ VTPM_TPMCommand
=20
 *********************************************************************/
=20
+#ifndef VTPM_STUBDOM
+#define TPM_EMULATOR_PATH "/usr/bin/vtpmd"
+#endif
+
+#define VTPM_BE_FNAME          "/dev/vtpm"
+#define VTPM_DUMMY_TX_BE_FNAME "/var/vtpm/fifos/dummy_out.fifo"
+#define VTPM_DUMMY_RX_BE_FNAME "/var/vtpm/fifos/dummy_in.fifo"
+#ifndef VTPM_STUBDOM
+#define VTPM_TX_TPM_FNAME      "/var/vtpm/fifos/tpm_cmd_to_%d.fifo"
+#define VTPM_RX_TPM_FNAME      "/var/vtpm/fifos/tpm_rsp_from_all.fifo"
+#define VTPM_TX_VTPM_FNAME     "/var/vtpm/fifos/vtpm_rsp_to_%d.fifo"
+#define VTPM_RX_VTPM_FNAME     "/var/vtpm/fifos/vtpm_cmd_from_all.fifo"
+#endif
+#define VTPM_TX_HP_FNAME       "/var/vtpm/fifos/to_console.fifo"
+#define VTPM_RX_HP_FNAME       "/var/vtpm/fifos/from_console.fifo"
+
+#define VTPM_TYPE_PVM_STRING "pvm"
+#define VTPM_TYPE_HVM_STRING "hvm"
+
 #endif //_VTPM_MANAGER_H_
diff --git a/tools/vtpm_manager/manager/vtpm_manager_handler.c
b/tools/vtpm_manager/manager/vtpm_manager_handler.c
--- a/tools/vtpm_manager/manager/vtpm_manager_handler.c
+++ b/tools/vtpm_manager/manager/vtpm_manager_handler.c
@@ -41,6 +41,8 @@
 #include <unistd.h>
 #include <string.h>
 #include <errno.h>
+#include <signal.h>
+#include <stdlib.h>
=20
 #include "vtpm_manager.h"
 #include "vtpmpriv.h"
@@ -50,26 +52,13 @@
 #include "hashtable_itr.h"
 #include "log.h"
 #include "buffer.h"
+#include "vtpm_manager_handler.h"
=20
 #define vtpmhandlerloginfo(module,fmt,args...) vtpmloginfo (module,
"[%s]: " fmt, thread_name, ##args );
 #define vtpmhandlerloginfomore(module,fmt,args...) vtpmloginfomore
(module, fmt, ##args );
 #define vtpmhandlerlogerror(module,fmt,args...) vtpmlogerror (module,
"[%s]: " fmt, thread_name, ##args );
=20
-// ---------------------- Prototypes -------------------
-TPM_RESULT vtpm_manager_handle_vtpm_cmd(VTPM_DMI_RESOURCE *dmi_res,
-                    TPM_COMMAND_CODE ord,
-                    buffer_t *command_buf,
-                    buffer_t *result_buf,
-                                        BOOL is_priv,
-                                        char *thread_name);
-
-TPM_RESULT vtpm_manager_handle_tpm_cmd(vtpm_ipc_handle_t *tx_ipc_h,
-                                       vtpm_ipc_handle_t *rx_ipc_h,
-                                       VTPM_DMI_RESOURCE *dmi_res,
-                                       BYTE *cmd_header,
-                                       buffer_t *param_buf,
-                                       buffer_t *result_buf,
-                                       char *thread_name);
+volatile sig_atomic_t HANDLER_QUIT_FLAG =3D 0;
=20
 TPM_RESULT VTPM_Manager_Handler( vtpm_ipc_handle_t *tx_ipc_h,
                                  vtpm_ipc_handle_t *rx_ipc_h,
@@ -80,12 +69,13 @@ TPM_RESULT VTPM_Manager_Handler( vtpm_ipc_handle_t
*tx_ipc_h,
                                  char *thread_name) {
   TPM_RESULT      status =3D  TPM_FAIL; // Should never return
   UINT32          dmi, in_param_size, cmd_size, out_param_size,
out_message_size, reply_size;
-  BYTE            *cmd_header=3DNULL, *in_param=3DNULL, *out_message=3DN=
ULL,
*reply;
+  BYTE            *cmd_header=3DNULL, *in_param=3DNULL, *out_header=3DNU=
LL,
*reply;
   buffer_t        *command_buf=3DNULL, *result_buf=3DNULL;
   TPM_TAG         tag;
   TPM_COMMAND_CODE ord;
   VTPM_DMI_RESOURCE *dmi_res;
   int  size_read, size_write, i;
+  int locked;
   BOOL add_header=3DTRUE; // This indicates to prepend a header on
result_buf before sending
 =20
   cmd_header =3D (BYTE *) malloc(VTPM_COMMAND_HEADER_SIZE_SRV);
@@ -93,7 +83,11 @@ TPM_RESULT VTPM_Manager_Handler( vtpm_ipc_handle_t
*tx_ipc_h,
   result_buf =3D (buffer_t *) malloc(sizeof(buffer_t));
=20
   // ------------------------ Main Loop --------------------------------=

-  while(1) {
+  while(!HANDLER_QUIT_FLAG) {
+    locked =3D 0;
+
+    buffer_init(command_buf, 0, NULL);
+    buffer_init(result_buf, 0, NULL);
   =20
     vtpmhandlerloginfo(VTPM_LOG_VTPM, "%s waiting for messages.\n",
thread_name);
=20
@@ -106,7 +100,9 @@ TPM_RESULT VTPM_Manager_Handler( vtpm_ipc_handle_t
*tx_ipc_h,
       for (i=3D0; i<size_read; i++)
     vtpmhandlerloginfomore(VTPM_LOG_VTPM_DEEP, "%x ", cmd_header[i]);
     } else {
-      vtpmhandlerlogerror(VTPM_LOG_VTPM, "%s can't read from ipc.
Errono =3D %d. Aborting... \n", thread_name, errno);
+      if (!IPC_QUIT_FLAG) {
+    vtpmhandlerlogerror(VTPM_LOG_VTPM, "%s can't read from ipc. Errono
=3D %d. Aborting... \n", thread_name, errno);
+      }
       goto abort_command;
     }
=20
@@ -155,6 +151,7 @@ TPM_RESULT VTPM_Manager_Handler( vtpm_ipc_handle_t
*tx_ipc_h,
       vtpmhandlerlogerror(VTPM_LOG_VTPM, "Failed to setup buffers.
Aborting...\n");
       goto abort_command;
     }
+    result_buf->is_owner =3D TRUE;
   =20
     // -------------- Dispatch Commands to Handlers -----------
     if ((tag =3D=3D VTPM_TAG_REQ) && (ord & VTPM_PRIV_MASK)) {
@@ -162,6 +159,7 @@ TPM_RESULT VTPM_Manager_Handler( vtpm_ipc_handle_t
*tx_ipc_h,
     } else {
       vtpm_lock_rdlock();
     }
+    locked =3D 1;
=20
     if ( !(dmi_res =3D (VTPM_DMI_RESOURCE *)
hashtable_search(vtpm_globals->dmi_map, &dmi)) ||
          (!dmi_res->connected) ) {
@@ -174,10 +172,22 @@ TPM_RESULT VTPM_Manager_Handler( vtpm_ipc_handle_t
*tx_ipc_h,
     if (tag =3D=3D VTPM_TAG_REQ) {
   =20
       status =3D vtpm_manager_handle_vtpm_cmd(dmi_res, ord, command_buf,=

result_buf, is_priv, thread_name);
+      result_buf->is_owner =3D TRUE;
=20
     } else { // This is not a VTPM Command at all.
       if (fw_tpm) {
+#ifdef VTPM_STUBDOM
+    /* In stubdom mode, we allow the vtpm domains to send raw tpm
commands down the pipe
+     * They can also just embed their tpm commands inside VTPM commands
if they wish to*/
+
+    /* Stick the header back onto the raw command (minus the dmiid) */
+    buffer_prepend_raw(command_buf, VTPM_COMMAND_HEADER_SIZE_CLT,
cmd_header + sizeof(UINT32));
+    status =3D VTPM_Handle_TPM_Command(dmi_res, command_buf, result_buf)=
;
+#else
+    /* In normal mode, this is used for the guest to forward a raw
command to the vtpm process */
         status =3D vtpm_manager_handle_tpm_cmd(fw_tx_ipc_h, fw_rx_ipc_h,=

dmi_res, cmd_header, command_buf, result_buf, thread_name);
+#endif
+        result_buf->is_owner =3D TRUE;
=20
         // This means calling the DMI failed, not that the cmd failed
in the DMI
         // Since the return will be interpretted by a TPM app, all
errors are IO_ERRORs to the app
@@ -207,36 +217,42 @@ TPM_RESULT VTPM_Manager_Handler( vtpm_ipc_handle_t
*tx_ipc_h,
     // ------------------- Respond to Sender ------------------
=20
     // Errors while handling responses jump here to reply with error
messages
-    // NOTE: Currently there are no recoverable errors in multi-VM
mode. If one
-    //       is added to the code, this ifdef should be removed.
-    //       Also note this is NOT referring to errors in commands, but
rather
-    //       this is about I/O errors and such.
-#ifndef VTPM_MULTI_VM
- abort_with_error:
-#endif
+abort_with_error:
  =20
     if (add_header) {
       // Prepend VTPM header with destination DM stamped
       out_param_size =3D buffer_len(result_buf);
       out_message_size =3D VTPM_COMMAND_HEADER_SIZE_CLT + out_param_size=
;
-      reply_size =3D VTPM_COMMAND_HEADER_SIZE_SRV + out_param_size;
-      out_message =3D (BYTE *) malloc (reply_size);
-      reply =3D out_message;
+      out_header =3D (BYTE *) malloc (VTPM_COMMAND_HEADER_SIZE_SRV);
   =20
-      BSG_PackList(out_message, 4,
+      BSG_PackList(out_header, 4,
            BSG_TYPE_UINT32, (BYTE *) &dmi,
            BSG_TPM_TAG, (BYTE *) &tag,
            BSG_TYPE_UINT32, (BYTE *) &out_message_size,
            BSG_TPM_RESULT, (BYTE *) &status);
   =20
-      if (buffer_len(result_buf) > 0)
-        memcpy(out_message + VTPM_COMMAND_HEADER_SIZE_SRV,
result_buf->bytes, out_param_size);
-      //Note: Send message + dmi_id
+      buffer_prepend_raw(result_buf, VTPM_COMMAND_HEADER_SIZE_SRV,
out_header);
+      free(out_header);
     } else {
-      reply =3D result_buf->bytes;
-      reply_size =3D buffer_len(result_buf);
+#ifdef VTPM_STUBDOM
+       //In stubdom mode, we need to always prepend the dmiid so the
raw command can be returned to the right domain
+       out_header =3D (BYTE*) malloc(sizeof(UINT32));
+       BSG_PackList(out_header, 1,
+         BSG_TYPE_UINT32, (BYTE*) &dmi);
+       buffer_prepend_raw(result_buf, sizeof(UINT32), out_header);
+       free(out_header);
+#endif
     }=20
+    reply =3D result_buf->bytes;
+    reply_size =3D buffer_len(result_buf);
+#ifndef VTPM_STUBDOM
     size_write =3D vtpm_ipc_write(tx_ipc_h, (dmi_res ?
dmi_res->tx_vtpm_ipc_h : NULL), reply, reply_size );
+#else
+    if(reply_size >=3D 4096) {
+       vtpmhandlerlogerror(VTPM_LOG_VTPM, "MESSAGE TOO BIG!!!");
+    }
+    size_write =3D vtpm_ipc_write(tx_ipc_h, NULL, reply, reply_size );
+#endif
     if (size_write > 0) {
       vtpmhandlerloginfo(VTPM_LOG_VTPM_DEEP, "SENT: 0x");
       for (i=3D0; i < reply_size; i++)
@@ -247,7 +263,6 @@ TPM_RESULT VTPM_Manager_Handler( vtpm_ipc_handle_t
*tx_ipc_h,
       vtpmhandlerlogerror(VTPM_LOG_VTPM, "%s had error writing to ipc.
Aborting... \n", thread_name);
       goto abort_command;
     }
-    free(out_message); out_message=3DNULL;
   =20
     if (size_write < (int)reply_size) {
       vtpmhandlerlogerror(VTPM_LOG_VTPM, "%s unable to write full
command to ipc (%d/%d)\n", thread_name, size_write, reply_size);
@@ -264,14 +279,22 @@ TPM_RESULT VTPM_Manager_Handler( vtpm_ipc_handle_t
*tx_ipc_h,
     buffer_free(command_buf);
=20
     // If we have a write lock, save the manager table
-    if ((tag =3D=3D VTPM_TAG_REQ) && (ord & VTPM_PRIV_MASK) &&
+    if (locked && (tag =3D=3D VTPM_TAG_REQ) && (ord & VTPM_PRIV_MASK) &&=

         (VTPM_SaveManagerData() !=3D TPM_SUCCESS) ) {
        vtpmhandlerlogerror(VTPM_LOG_VTPM, "ERROR: Unable to save
manager data.\n");
     }
=20
-    vtpm_lock_unlock();
+    if(locked) {
+       vtpm_lock_unlock();
+    }
     add_header =3D TRUE; // Reset to the default
   } // End while(1)
+
+  free(cmd_header);
+  free(command_buf);
+  free(result_buf);
+
+  vtpmhandlerloginfo(VTPM_LOG_VTPM, "exiting\n", thread_name);
 =20
 }
=20
@@ -313,6 +336,16 @@ TPM_RESULT
vtpm_manager_handle_vtpm_cmd(VTPM_DMI_RESOURCE *dmi_res,
     status =3D VTPM_Handle_Load_Migration_key(command_buf,
                                            result_buf);
     break;
+  case VTPM_ORD_SAVEHASHKEY:
+    status =3D VTPM_Handle_Save_HashKey(dmi_res,
+                     command_buf,
+                   result_buf);
+    break;
+  case VTPM_ORD_LOADHASHKEY:
+    status =3D VTPM_Handle_Load_HashKey(dmi_res,
+                     command_buf,
+                   result_buf);
+    break;
  =20
   default:
     // Privileged handlers can do maintanance
@@ -350,6 +383,7 @@ TPM_RESULT
vtpm_manager_handle_vtpm_cmd(VTPM_DMI_RESOURCE *dmi_res,
   return(status);
 }
     =20
+#ifndef VTPM_STUBDOM
 /////////////////////////////////////////////////////////////////////
 TPM_RESULT vtpm_manager_handle_tpm_cmd(vtpm_ipc_handle_t *tx_ipc_h,
                                        vtpm_ipc_handle_t *rx_ipc_h,
@@ -485,4 +519,5 @@ TPM_RESULT
vtpm_manager_handle_tpm_cmd(vtpm_ipc_handle_t *tx_ipc_h,
=20
   return status;
 }
+#endif
=20
diff --git a/tools/vtpm_manager/manager/vtpm_manager_handler.h
b/tools/vtpm_manager/manager/vtpm_manager_handler.h
--- /dev/null
+++ b/tools/vtpm_manager/manager/vtpm_manager_handler.h
@@ -0,0 +1,21 @@
+#ifndef VTPM_MANAGER_HANDLER_H
+#define VTPM_MANAGER_HANDLER_H
+// ---------------------- Prototypes -------------------
+TPM_RESULT vtpm_manager_handle_vtpm_cmd(VTPM_DMI_RESOURCE *dmi_res,
+                    TPM_COMMAND_CODE ord,
+                    buffer_t *command_buf,
+                    buffer_t *result_buf,
+                                        BOOL is_priv,
+                                        char *thread_name);
+
+#ifndef VTPM_STUBDOM
+TPM_RESULT vtpm_manager_handle_tpm_cmd(vtpm_ipc_handle_t *tx_ipc_h,
+                                       vtpm_ipc_handle_t *rx_ipc_h,
+                                       VTPM_DMI_RESOURCE *dmi_res,
+                                       BYTE *cmd_header,
+                                       buffer_t *param_buf,
+                                       buffer_t *result_buf,
+                                       char *thread_name);
+#endif
+
+#endif
diff --git a/tools/vtpm_manager/manager/vtpmd.c
b/tools/vtpm_manager/manager/vtpmd.c
--- a/tools/vtpm_manager/manager/vtpmd.c
+++ b/tools/vtpm_manager/manager/vtpmd.c
@@ -45,27 +45,13 @@
 #include <signal.h>
 #include <string.h>
 #include <pthread.h>
+#include <stdlib.h>
 #include "vtpm_manager.h"
 #include "vtpmpriv.h"
 #include "tcg.h"
 #include "log.h"
 #include "vtpm_ipc.h"
=20
-#define TPM_EMULATOR_PATH "/usr/bin/vtpmd"
-
-#define VTPM_BE_FNAME          "/dev/vtpm"
-#define VTPM_DUMMY_TX_BE_FNAME "/var/vtpm/fifos/dummy_out.fifo"
-#define VTPM_DUMMY_RX_BE_FNAME "/var/vtpm/fifos/dummy_in.fifo"
-#define VTPM_TX_TPM_FNAME      "/var/vtpm/fifos/tpm_cmd_to_%d.fifo"
-#define VTPM_RX_TPM_FNAME      "/var/vtpm/fifos/tpm_rsp_from_all.fifo"
-#define VTPM_TX_VTPM_FNAME     "/var/vtpm/fifos/vtpm_rsp_to_%d.fifo"
-#define VTPM_RX_VTPM_FNAME     "/var/vtpm/fifos/vtpm_cmd_from_all.fifo"
-#define VTPM_TX_HP_FNAME       "/var/vtpm/fifos/to_console.fifo"
-#define VTPM_RX_HP_FNAME       "/var/vtpm/fifos/from_console.fifo"
-
-#define VTPM_TYPE_PVM_STRING "pvm"
-#define VTPM_TYPE_HVM_STRING "hvm"
-
 struct vtpm_thread_params_s {
   vtpm_ipc_handle_t *tx_ipc_h;
   vtpm_ipc_handle_t *rx_ipc_h;
@@ -76,180 +62,46 @@ struct vtpm_thread_params_s {
   char *thread_name;
 };
=20
+static pthread_t           master_thread;
+static pthread_t           be_thread;
+static pthread_t           hp_thread;
+#ifndef VTPM_STUBDOM
+static pthread_t           dmi_thread;
+#endif
+
+
+#ifndef VTPM_STUBDOM
 // This is needed to all extra_close_dmi to close this to prevent a
 // broken pipe when no DMIs are left.
-static vtpm_ipc_handle_t *g_rx_tpm_ipc_h;
+extern vtpm_ipc_handle_t *g_rx_tpm_ipc_h;
+#endif
=20
 void *vtpm_manager_thread(void *arg_void) {
-  TPM_RESULT *status =3D (TPM_RESULT *) malloc(sizeof(TPM_RESULT) );
   struct vtpm_thread_params_s *arg =3D (struct vtpm_thread_params_s *)
arg_void;
=20
-  *status =3D VTPM_Manager_Handler(arg->tx_ipc_h, arg->rx_ipc_h,
+  VTPM_Manager_Handler(arg->tx_ipc_h, arg->rx_ipc_h,
                                  arg->fw_tpm, arg->fw_tx_ipc_h,
arg->fw_rx_ipc_h,
                                  arg->is_priv, arg->thread_name);
=20
-  return (status);
+  return NULL;
 }
=20
-
-void signal_handler(int reason) {
-  if (pthread_equal(pthread_self(), vtpm_globals->master_pid)) {
-    vtpmloginfo(VTPM_LOG_VTPM, "VTPM Manager shutting down for signal
%d.\n", reason);
-  } else {
-    // For old Linux Thread machines, signals are delivered to each
thread. Deal with them.
-    vtpmloginfo(VTPM_LOG_VTPM, "Child shutting down\n");
-    pthread_exit(NULL);
+void signal_handler(int signal) {
+  if (pthread_equal(pthread_self(), master_thread)) {
+    vtpmloginfo(VTPM_LOG_VTPM, "VTPM Manager shutting down for signal
%s(%d). Please wait..\n", strsignal(signal), signal);
+    HANDLER_QUIT_FLAG =3D IPC_QUIT_FLAG =3D 1;
   }
-
-  VTPM_Stop_Manager();
-  exit(-1);
 }
=20
 struct sigaction ctl_c_handler;
=20
-TPM_RESULT VTPM_New_DMI_Extra(VTPM_DMI_RESOURCE *dmi_res, BYTE vm_type,
BYTE startup_mode) {
-
-  TPM_RESULT status =3D TPM_SUCCESS;
-  int fh;
-  char dmi_id_str[11]; // UINT32s are up to 10 digits + NULL
-  char *tx_vtpm_name, *tx_tpm_name, *vm_type_string;
-  struct stat file_info;
-
-  if (dmi_res->dmi_id =3D=3D VTPM_CTL_DM) {
-    dmi_res->tx_tpm_ipc_h =3D NULL;
-    dmi_res->rx_tpm_ipc_h =3D NULL;
-    dmi_res->tx_vtpm_ipc_h =3D NULL;
-    dmi_res->rx_vtpm_ipc_h =3D NULL;
-  } else {
-    // Create a pair of fifo pipes
-    dmi_res->rx_tpm_ipc_h =3D NULL;
-    dmi_res->rx_vtpm_ipc_h =3D NULL;
-
-    if ( ((dmi_res->tx_tpm_ipc_h =3D (vtpm_ipc_handle_t *) malloc
(sizeof(vtpm_ipc_handle_t))) =3D=3D NULL ) ||
-         ((dmi_res->tx_vtpm_ipc_h =3D(vtpm_ipc_handle_t *) malloc
(sizeof(vtpm_ipc_handle_t))) =3D=3D NULL ) ||
-         ((tx_tpm_name =3D (char *) malloc(11 +
strlen(VTPM_TX_TPM_FNAME))) =3D=3D NULL ) ||
-         ((tx_vtpm_name =3D(char *) malloc(11 +
strlen(VTPM_TX_VTPM_FNAME))) =3D=3D NULL) ) {
-      status =3DTPM_RESOURCES;
-      goto abort_egress;
-    }
-
-    sprintf(tx_tpm_name, VTPM_TX_TPM_FNAME, (uint32_t) dmi_res->dmi_id);=

-    sprintf(tx_vtpm_name, VTPM_TX_VTPM_FNAME, (uint32_t) dmi_res->dmi_id=
);
-
-    if ( (vtpm_ipc_init(dmi_res->tx_tpm_ipc_h, tx_tpm_name, O_WRONLY |
O_NONBLOCK, TRUE) !=3D 0) ||
-         (vtpm_ipc_init(dmi_res->tx_vtpm_ipc_h, tx_vtpm_name, O_WRONLY,
TRUE) !=3D 0) ) { //FIXME: O_NONBLOCK?
-      status =3D TPM_IOERROR;
-      goto abort_egress;
-    }
-
-    // Measure DMI
-    // FIXME: This will measure DMI. Until then use a fixed
DMI_Measurement value
-    // Also, this mechanism is specific to 1 VM architecture.
-    /*
-    fh =3D open(TPM_EMULATOR_PATH, O_RDONLY);
-    stat_ret =3D fstat(fh, &file_stat);
-    if (stat_ret =3D=3D 0)
-      dmi_size =3D file_stat.st_size;
-    else {
-      vtpmlogerror(VTPM_LOG_VTPM, "Could not open vtpmd!!\n");
-      status =3D TPM_IOERROR;
-      goto abort_egress;
-    }
-    dmi_buffer
-    */
-    memset(&dmi_res->DMI_measurement, 0xcc, sizeof(TPM_DIGEST));
-
-    if (vm_type =3D=3D VTPM_TYPE_PVM)
-      vm_type_string =3D (BYTE *)&VTPM_TYPE_PVM_STRING;
-    else
-      vm_type_string =3D (BYTE *)&VTPM_TYPE_HVM_STRING;
-
-    // Launch DMI
-    sprintf(dmi_id_str, "%d", (int) dmi_res->dmi_id);
-#ifdef MANUAL_DM_LAUNCH
-    vtpmlogerror(VTPM_LOG_VTPM, "Manually start VTPM with dmi=3D%s
now.\n", dmi_id_str);
-    dmi_res->dmi_pid =3D 0;
-#else
-    pid_t pid =3D fork();
-
-    if (pid =3D=3D -1) {
-      vtpmlogerror(VTPM_LOG_VTPM, "Could not fork to launch vtpm\n");
-      status =3D TPM_RESOURCES;
-      goto abort_egress;
-    } else if (pid =3D=3D 0) {
-      switch (startup_mode) {
-      case TPM_ST_CLEAR:
-        execl (TPM_EMULATOR_PATH, "vtpmd", "clear", vm_type_string,
dmi_id_str, NULL);
-        break;
-      case TPM_ST_STATE:
-        execl (TPM_EMULATOR_PATH, "vtpmd", "save", vm_type_string,
dmi_id_str, NULL);
-        break;
-      case TPM_ST_DEACTIVATED:
-        execl (TPM_EMULATOR_PATH, "vtpmd", "deactivated",
vm_type_string, dmi_id_str, NULL);
-        break;
-      default:
-        status =3D TPM_BAD_PARAMETER;
-        goto abort_egress;
-      }
-
-      // Returning from these at all is an error.
-      vtpmlogerror(VTPM_LOG_VTPM, "Could not exec to launch vtpm\n");
-    } else {
-      dmi_res->dmi_pid =3D pid;
-      vtpmloginfo(VTPM_LOG_VTPM, "Launching DMI on PID =3D %d\n", pid);
-    }
-#endif // MANUAL_DM_LAUNCH
-
-  } // If DMI =3D VTPM_CTL_DM
-    status =3D TPM_SUCCESS;
-
-abort_egress:
-  return (status);
-}
-
-TPM_RESULT VTPM_Close_DMI_Extra(VTPM_DMI_RESOURCE *dmi_res) {
-  TPM_RESULT status =3D TPM_SUCCESS;
-
-  if (vtpm_globals->connected_dmis =3D=3D 0) {
-    // No more DMI's connected. Close fifo to prevent a broken pipe.
-    // This is hackish. Need to think of another way.
-    vtpm_ipc_close(g_rx_tpm_ipc_h);
-  }
-
-=20
-  if (dmi_res->dmi_id !=3D VTPM_CTL_DM) {
-    vtpm_ipc_close(dmi_res->tx_tpm_ipc_h);
-    vtpm_ipc_close(dmi_res->tx_vtpm_ipc_h);
-
-    free(dmi_res->tx_tpm_ipc_h->name);
-    free(dmi_res->tx_vtpm_ipc_h->name);
-
-#ifndef MANUAL_DM_LAUNCH
-    if (dmi_res->dmi_id !=3D VTPM_CTL_DM) {
-      if (dmi_res->dmi_pid !=3D 0) {
-        vtpmloginfo(VTPM_LOG_VTPM, "Killing dmi on pid %d.\n",
dmi_res->dmi_pid);
-        if (kill(dmi_res->dmi_pid, SIGKILL) !=3D0) {
-          vtpmloginfo(VTPM_LOG_VTPM, "DMI on pid %d is already
dead.\n", dmi_res->dmi_pid);
-        } else if (waitpid(dmi_res->dmi_pid, NULL, 0) !=3D
dmi_res->dmi_pid) {
-          vtpmlogerror(VTPM_LOG_VTPM, "DMI on pid %d failed to
stop.\n", dmi_res->dmi_pid);
-          status =3D TPM_FAIL;
-        }
-      } else {
-        vtpmlogerror(VTPM_LOG_VTPM, "Could not kill dmi because it's
pid was 0.\n");
-        status =3D TPM_FAIL;
-      }
-    }
-#endif
-
-  } //endif ! dom0
-  return status;
-}
-
-
 int main(int argc, char **argv) {
-  vtpm_ipc_handle_t *tx_be_ipc_h, *rx_be_ipc_h, rx_tpm_ipc_h,
rx_vtpm_ipc_h, tx_hp_ipc_h, rx_hp_ipc_h;
-  struct vtpm_thread_params_s be_thread_params, dmi_thread_params,
hp_thread_params;
-  pthread_t be_thread, dmi_thread, hp_thread;
+  vtpm_ipc_handle_t *tx_be_ipc_h, *rx_be_ipc_h, tx_hp_ipc_h, rx_hp_ipc_h=
;
+  struct vtpm_thread_params_s be_thread_params, hp_thread_params;
+#ifndef VTPM_STUBDOM
+  vtpm_ipc_handle_t rx_tpm_ipc_h, rx_vtpm_ipc_h;
+  struct vtpm_thread_params_s dmi_thread_params;
+#endif
=20
 #ifdef DUMMY_BACKEND
   vtpm_ipc_handle_t tx_dummy_ipc_h, rx_dummy_ipc_h;
@@ -258,34 +110,28 @@ int main(int argc, char **argv) {
 #endif
=20
   vtpmloginfo(VTPM_LOG_VTPM, "Starting VTPM.\n");
-
-  // -------------------- Initialize Manager -----------------
-  if (VTPM_Init_Manager() !=3D TPM_SUCCESS) {
-    vtpmlogerror(VTPM_LOG_VTPM, "Closing vtpmd due to error during
startup.\n");
-    return -1;
-  }
-=20
+
   // -------------------- Setup Ctrl+C Handlers --------------
   ctl_c_handler.sa_handler =3D signal_handler;
   sigemptyset(&ctl_c_handler.sa_mask);
   ctl_c_handler.sa_flags =3D 0;  =20
 =20
-  if (sigaction(SIGINT, &ctl_c_handler, NULL) =3D=3D -1)
+  if ((sigaction(SIGINT, &ctl_c_handler, NULL) =3D=3D -1)
+    || (sigaction(SIGQUIT, &ctl_c_handler, NULL) =3D=3D -1)
+    || (sigaction(SIGHUP, &ctl_c_handler, NULL) =3D=3D -1) ) // For easi=
er
debugging with gdb
+  {
     vtpmlogerror(VTPM_LOG_VTPM, "Could not install SIGINT handler.
Ctl+break will not stop manager gently.\n");
+  }
 =20
-  // For easier debuggin with gdb
-  if (sigaction(SIGHUP, &ctl_c_handler, NULL) =3D=3D -1)
-    vtpmlogerror(VTPM_LOG_VTPM, "Could not install SIGHUP handler.
Ctl+break will not stop manager gently.\n");  =20
-=20
+  //Block all signals for child threads
   sigset_t sig_mask;
-  sigemptyset(&sig_mask);
-  sigaddset(&sig_mask, SIGPIPE);
-  sigprocmask(SIG_BLOCK, &sig_mask, NULL);
+  sigfillset(&sig_mask);
+  pthread_sigmask(SIG_SETMASK, &sig_mask, NULL);
 =20
   // ------------------- Set up file ipc structures ----------
 #ifdef DUMMY_BACKEND
-  if ( (vtpm_ipc_init(&tx_dummy_ipc_h, VTPM_DUMMY_TX_BE_FNAME, O_RDWR,
TRUE) !=3D 0) ||
-       (vtpm_ipc_init(&rx_dummy_ipc_h, VTPM_DUMMY_RX_BE_FNAME, O_RDWR,
TRUE) !=3D 0) ) {
+  if ( (vtpm_ipc_init(&tx_dummy_ipc_h, VTPM_DUMMY_TX_BE_FNAME, O_RDWR,
TRUE, FALSE) !=3D 0) ||
+       (vtpm_ipc_init(&rx_dummy_ipc_h, VTPM_DUMMY_RX_BE_FNAME, O_RDWR,
TRUE, FALSE) !=3D 0) ) {
=20
     vtpmlogerror(VTPM_LOG_VTPM, "Unable to create Dummy BE FIFOs.\n");
     exit(-1);
@@ -294,21 +140,29 @@ int main(int argc, char **argv) {
   tx_be_ipc_h =3D &tx_dummy_ipc_h;
   rx_be_ipc_h =3D &rx_dummy_ipc_h;
 #else
-  vtpm_ipc_init(&real_be_ipc_h, VTPM_BE_FNAME, O_RDWR, FALSE);
+  if(vtpm_ipc_init(&real_be_ipc_h, VTPM_BE_FNAME, O_RDWR, FALSE, TRUE)
!=3D 0) {
+     vtpmlogerror(VTPM_LOG_VTPM, "Unable to open backend device "
VTPM_BE_FNAME "\n");
+     exit(-1);
+  }
=20
   tx_be_ipc_h =3D &real_be_ipc_h;
   rx_be_ipc_h =3D &real_be_ipc_h;
 #endif
=20
-  if ( (vtpm_ipc_init(&rx_tpm_ipc_h, VTPM_RX_TPM_FNAME, O_RDONLY, TRUE)
!=3D 0) ||
-       (vtpm_ipc_init(&rx_vtpm_ipc_h, VTPM_RX_VTPM_FNAME, O_RDWR, TRUE)
!=3D 0) || //FIXME: O_RDONLY?
-       (vtpm_ipc_init(&tx_hp_ipc_h,  VTPM_TX_HP_FNAME, O_RDWR, TRUE) !=3D=

0)    ||
-       (vtpm_ipc_init(&rx_hp_ipc_h,  VTPM_RX_HP_FNAME, O_RDWR, TRUE) !=3D=

0) ) {
+  if (
+#ifndef VTPM_STUBDOM
+       (vtpm_ipc_init(&rx_tpm_ipc_h, VTPM_RX_TPM_FNAME, O_RDONLY, TRUE,
FALSE) !=3D 0) ||
+       (vtpm_ipc_init(&rx_vtpm_ipc_h, VTPM_RX_VTPM_FNAME, O_RDWR, TRUE,
FALSE) !=3D 0) || //FIXME: O_RDONLY?
+#endif
+       (vtpm_ipc_init(&tx_hp_ipc_h,  VTPM_TX_HP_FNAME, O_RDWR, TRUE,
TRUE) !=3D 0)    ||
+       (vtpm_ipc_init(&rx_hp_ipc_h,  VTPM_RX_HP_FNAME, O_RDWR, TRUE,
TRUE) !=3D 0) ) {
     vtpmlogerror(VTPM_LOG_VTPM, "Unable to create initial FIFOs.\n");
     exit(-1);
   }
=20
+#ifndef VTPM_STUBDOM
   g_rx_tpm_ipc_h =3D &rx_tpm_ipc_h;
+#endif
=20
   // -------------------- Set up thread params -------------
=20
@@ -316,10 +170,15 @@ int main(int argc, char **argv) {
   be_thread_params.rx_ipc_h =3D rx_be_ipc_h;
   be_thread_params.fw_tpm =3D TRUE;
   be_thread_params.fw_tx_ipc_h =3D NULL;
+#ifndef VTPM_STUBDOM
   be_thread_params.fw_rx_ipc_h =3D &rx_tpm_ipc_h;
+#else
+  be_thread_params.fw_rx_ipc_h =3D NULL;
+#endif
   be_thread_params.is_priv =3D FALSE;
   be_thread_params.thread_name =3D "Backend Listener";
=20
+#ifndef VTPM_STUBDOM
   dmi_thread_params.tx_ipc_h =3D NULL;
   dmi_thread_params.rx_ipc_h =3D &rx_vtpm_ipc_h;
   dmi_thread_params.fw_tpm =3D FALSE;
@@ -327,6 +186,7 @@ int main(int argc, char **argv) {
   dmi_thread_params.fw_rx_ipc_h =3D NULL;
   dmi_thread_params.is_priv =3D FALSE;
   dmi_thread_params.thread_name =3D "VTPM Listener";
+#endif
=20
   hp_thread_params.tx_ipc_h =3D &tx_hp_ipc_h;
   hp_thread_params.rx_ipc_h =3D &rx_hp_ipc_h;
@@ -335,35 +195,51 @@ int main(int argc, char **argv) {
   hp_thread_params.fw_rx_ipc_h =3D NULL;
   hp_thread_params.is_priv =3D TRUE;
   hp_thread_params.thread_name =3D "Hotplug Listener";
+=20
+  // -------------------- Initialize Manager -----------------
+  if (VTPM_Init_Manager() !=3D TPM_SUCCESS) {
+    vtpmlogerror(VTPM_LOG_VTPM, "Closing vtpmd due to error during
startup.\n");
+    return -1;
+  }
+=20
=20
   // --------------------- Launch Threads -----------------
=20
   vtpm_lock_init();
=20
-  vtpm_globals->master_pid =3D pthread_self();
+  master_thread =3D pthread_self();
+
 =20
   if (pthread_create(&be_thread, NULL, vtpm_manager_thread,
&be_thread_params) !=3D 0) {
     vtpmlogerror(VTPM_LOG_VTPM, "Failed to launch BE Thread.\n");
     exit(-1);
   }
 =20
+#ifndef VTPM_STUBDOM
   if (pthread_create(&dmi_thread, NULL, vtpm_manager_thread,
&dmi_thread_params) !=3D 0) {
     vtpmlogerror(VTPM_LOG_VTPM, "Failed to launch DMI Thread.\n");
     exit(-1);
   }
-
+#endif
=20
   if (pthread_create(&hp_thread, NULL, vtpm_manager_thread,
&hp_thread_params) !=3D 0) {
     vtpmlogerror(VTPM_LOG_VTPM, "Failed to launch HP Thread.\n");
     exit(-1);
   }
=20
+  //Turn signals back on for the master thread only
+  sigemptyset(&sig_mask);
+  sigaddset(&sig_mask, SIGPIPE);
+  pthread_sigmask(SIG_SETMASK, &sig_mask, NULL);
+
   //Join the other threads until exit time.
   pthread_join(be_thread, NULL);
+#ifndef VTPM_STUBDOM
   pthread_join(dmi_thread, NULL);
+#endif
   pthread_join(hp_thread, NULL);
=20
-  vtpmlogerror(VTPM_LOG_VTPM, "VTPM Manager shut down unexpectedly.\n");=

+  vtpmloginfo(VTPM_LOG_VTPM, "VTPM Manager shutting down...\n");
=20
   VTPM_Stop_Manager();
   vtpm_lock_destroy();
diff --git a/tools/vtpm_manager/manager/vtpmpriv.h
b/tools/vtpm_manager/manager/vtpmpriv.h
--- a/tools/vtpm_manager/manager/vtpmpriv.h
+++ b/tools/vtpm_manager/manager/vtpmpriv.h
@@ -40,6 +40,8 @@
 #ifndef __VTPMPRIV_H__
 #define __VTPMPRIV_H__
=20
+#include <signal.h>
+
 #include "vtpm_manager.h"
 #include "tcg.h"
 #include "tcs.h"
@@ -54,16 +56,19 @@
 #define DMI_NVM_FILE       "/var/vtpm/vtpm_dm_%d.data"
 #define VTPM_CTL_DM        0
=20
+extern volatile sig_atomic_t HANDLER_QUIT_FLAG;
+
 // ------------------------ Private Structures -----------------------
 typedef struct VTPM_DMI_RESOURCE_T {
+#ifndef VTPM_STUBDOM
   // I/O info for Manager to talk to DMI's and controllers
   vtpm_ipc_handle_t      *tx_vtpm_ipc_h;    // TX VTPM Results to DMI
   vtpm_ipc_handle_t      *rx_vtpm_ipc_h;    // RX VTPM Commands from DMI=

   vtpm_ipc_handle_t      *tx_tpm_ipc_h;     // TX TPM Commands to DMI
   vtpm_ipc_handle_t      *rx_tpm_ipc_h;     // RX TPM Results from DMI
+
+  pid_t                  dmi_pid;
=20
-#ifndef VTPM_MULTI_VM
-  pid_t                 dmi_pid;
 #endif
=20
   // Non-persistent Information
@@ -77,6 +82,9 @@ typedef struct VTPM_DMI_RESOURCE_T {
   BYTE                  dmi_type;
   TPM_DIGEST            NVM_measurement;  // Equal to the SHA1 of the bl=
ob
   TPM_DIGEST            DMI_measurement;  // Correct measurement of the
owning DMI
+
+  char* uuid;
+
 } VTPM_DMI_RESOURCE;
=20
 typedef struct tdVTPM_MIGKEY_LIST {
@@ -89,10 +97,6 @@ typedef struct tdVTPM_MIGKEY_LIST {
=20
 typedef struct tdVTPM_GLOBALS {
   // Non-persistent data
-#ifndef VTPM_MULTI_VM
-  pid_t               master_pid;
-#endif
-
   int                 connected_dmis;     // To close guest_rx when no
dmis are connected
=20
   struct hashtable    *dmi_map;               // Table of all DMI's
known indexed by persistent instance #
@@ -123,8 +127,8 @@ extern VTPM_GLOBALS *vtpm_globals;   // Key info and
DMI states
 extern const TPM_AUTHDATA SRK_AUTH;  // SRK Well Known Auth Value
=20
 // ********************** VTPM Functions *************************
-TPM_RESULT VTPM_Init_Manager(); // Start VTPM Service
-void VTPM_Stop_Manager();  // Stop VTPM Service
+TPM_RESULT VTPM_Init_Manager(void); // Start VTPM Service
+void VTPM_Stop_Manager(void);  // Stop VTPM Service
 TPM_RESULT VTPM_Manager_Handler(vtpm_ipc_handle_t *tx_ipc_h,
                                 vtpm_ipc_handle_t *rx_ipc_h,
                                 BOOL fw_tpm,   // Should forward TPM cmd=
s
@@ -143,6 +147,11 @@ TPM_RESULT VTPM_Handle_Save_NVM(     =20
VTPM_DMI_RESOURCE *myDMI,
                                         const buffer_t *inbuf,
                                         buffer_t *outbuf);
=20
+TPM_RESULT VTPM_Handle_Get_NVM_Size(   VTPM_DMI_RESOURCE *myDMI,
+                                        const buffer_t *inbuf,
+                                        buffer_t *outbuf);
+
+
 TPM_RESULT VTPM_Handle_TPM_Command(    VTPM_DMI_RESOURCE *dmi,
                                         buffer_t *inbuf,
                                         buffer_t *outbuf);
@@ -173,6 +182,9 @@ TPM_RESULT VTPM_Close_DMI_Extra(VTPM_DMI_RESOURCE
*dmi_res);
 TPM_RESULT close_dmi(VTPM_DMI_RESOURCE *dmi_res);
 TPM_RESULT init_dmi(UINT32 dmi_id, BYTE type,  VTPM_DMI_RESOURCE
**dmi_res);
=20
+/* Free's dmi_res and all of it's resources */
+void free_dmi(VTPM_DMI_RESOURCE *dmi_res);
+
 TPM_RESULT envelope_encrypt(const buffer_t     *inbuf,
                              CRYPTO_INFO        *asymkey,
                              buffer_t           *sealed_data);
@@ -183,4 +195,14 @@ TPM_RESULT envelope_decrypt(const buffer_t     *ciph=
er,
                             const TPM_AUTHDATA *key_usage_auth,
                             buffer_t           *unsealed_data);
=20
+TPM_RESULT symkey_encrypt(const buffer_t     *inbuf,
+                            CRYPTO_INFO        *asymkey,
+                            buffer_t           *sealed_key);
+
+TPM_RESULT symkey_decrypt(const buffer_t     *cipher,
+                            TCS_CONTEXT_HANDLE TCSContext,
+                TPM_HANDLE         keyHandle,
+                const TPM_AUTHDATA *key_usage_auth,
+                            buffer_t           *symkey_clear);
+
 #endif // __VTPMPRIV_H__
diff --git a/tools/vtpm_manager/manager/vtsp.c
b/tools/vtpm_manager/manager/vtsp.c
--- a/tools/vtpm_manager/manager/vtsp.c
+++ b/tools/vtpm_manager/manager/vtsp.c
@@ -38,6 +38,7 @@
 // =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
=20
 #include <string.h>
+#include <stdlib.h>
 #include "tcg.h"
 #include "tcs.h"
 #include "bsg.h"
@@ -312,7 +313,7 @@ TPM_RESULT VTSP_TakeOwnership(   const
TCS_CONTEXT_HANDLE hContext,
   TPM_PROTOCOL_ID proto_id =3D TPM_PID_OWNER;
   BYTE *new_srk;
 =20
-  BYTE *paramText;        // Digest to make Auth.
+  BYTE *paramText =3D NULL;        // Digest to make Auth.
   UINT32 paramTextSize;
 =20
   // vars for srkpubkey parameter
@@ -458,7 +459,7 @@ TPM_RESULT VTSP_CreateWrapKey(  const
TCS_CONTEXT_HANDLE hContext,
   vtpmloginfo(VTPM_LOG_VTSP, "Creating new key of type %d.\n", usage);
 =20
   // vars for Calculate encUsageAuth
-  BYTE *paramText;    =20
+  BYTE *paramText =3D NULL;
   UINT32 paramTextSize;
 =20
   // vars for Calculate encUsageAuth
@@ -567,8 +568,7 @@ TPM_RESULT VTSP_CreateWrapKey(  const
TCS_CONTEXT_HANDLE hContext,
                 osapSharedSecret, auth, 0) );
 =20
   // Unpack/return key structure
-  TPMTRYRETURN(buffer_init(pubKeyBuf, 0, 0) );
-  TPMTRYRETURN(buffer_append_raw(pubKeyBuf, newKeyText.size,
newKeyText.data) );
+  TPMTRYRETURN(buffer_init(pubKeyBuf, newKeyText.size, newKeyText.data) =
);
 =20
   goto egress;
 =20
@@ -664,6 +664,7 @@ TPM_RESULT VTSP_LoadKey(const TCS_CONTEXT_HANDLE  =20
hContext,
   =20
     // Destroy rsaKeyParms
     BSG_Destroy(BSG_TPM_RSA_KEY_PARMS, &rsaKeyParms);
+    BSG_Destroy(BSG_TPM_KEY, &newKey);
   =20
     // Set encryption scheme
     cryptoinfo->encScheme =3D CRYPTO_ES_RSAESOAEP_SHA1_MGF1;
@@ -733,8 +734,7 @@ TPM_RESULT VTSP_Unbind( const TCS_CONTEXT_HANDLE  =20
hContext,
                 hContext) );
 =20
   // Unpack/return key structure
-  TPMTRYRETURN(buffer_init(clear_data, 0, 0));
-  TPMTRYRETURN(buffer_append_raw (clear_data, clear_data_size,
clear_data_text) );
+  TPMTRYRETURN(buffer_init(clear_data, clear_data_size, clear_data_text)=
 );
 =20
   goto egress;
 =20
@@ -793,8 +793,7 @@ TPM_RESULT VTSP_Bind(   CRYPTO_INFO *cryptoInfo,
     vtpmlogerror(VTPM_LOG_VTSP, "Enc buffer just overflowed.\n");
   }
 =20
-  buffer_init(outData, 0, NULL);
-  buffer_append_raw(outData, out_tmp_size, out_tmp);
+  buffer_init(outData, out_tmp_size, out_tmp);
 =20
   vtpmloginfo(VTPM_LOG_TXDATA, "Bind Generated[%d] =3D 0x", out_tmp_size=
);
   for(i =3D 0 ; i < out_tmp_size ; i++) {
@@ -1005,8 +1004,6 @@ TPM_RESULT VTSP_SaveState( const
TCS_CONTEXT_HANDLE    hContext) {
=20
   vtpmloginfo(VTPM_LOG_VTSP, "Calling TPM_SaveState.\n");
=20
-  TPM_RESULT status =3D TPM_SUCCESS;
-
   // Call TCS
   return ( TCSP_SaveState ( hContext ) );
=20
@@ -1040,3 +1037,4 @@ TPM_RESULT VTSP_RawTransmit(const
TCS_CONTEXT_HANDLE    hContext,
   free(resultText);
   return status;
 }
+
diff --git a/tools/vtpm_manager/manager/vtsp.h
b/tools/vtpm_manager/manager/vtsp.h
--- a/tools/vtpm_manager/manager/vtsp.h
+++ b/tools/vtpm_manager/manager/vtsp.h
@@ -42,6 +42,7 @@
=20
 #include "tcg.h"
 #include "tcs.h"
+#include "crypto.h"
=20
 #define KEY_BUFFER_SIZE 2048
=20
diff --git a/tools/vtpm_manager/migration/Makefile
b/tools/vtpm_manager/migration/Makefile
--- a/tools/vtpm_manager/migration/Makefile
+++ b/tools/vtpm_manager/migration/Makefile
@@ -1,5 +1,11 @@
-XEN_ROOT =3D $(CURDIR)/../../..
-include $(XEN_ROOT)/tools/vtpm_manager/Rules.mk
+XEN_ROOT =3D $(realpath ../../..)
+include ../Rules.mk
+
+CFLAGS +=3D -I../crypto
+CFLAGS +=3D -I../util
+CFLAGS +=3D -I../tcs
+CFLAGS +=3D -I../manager
+
=20
 VPATH =3D ../manager
=20
@@ -33,10 +39,10 @@ mrproper: clean
     rm -f *~
=20
 $(BIND): $(OBJSD)
-    $(CC) $(LDFLAGS) $^ $(LIBS) -o $@
+    $(CC) $(CFLAGS) $(LDFLAGS) $^ $(LIBS) -o $@
=20
 $(BINC): $(OBJSC)
-    $(CC) $(LDFLAGS) $^ $(LIBS) -o $@
+    $(CC) $(CFLAGS) $(LDFLAGS) $^ $(LIBS) -o $@
=20
 # libraries
 LIBS +=3D ../util/libTCGUtils.a
diff --git a/tools/vtpm_manager/migration/vtpm_manager_if.c
b/tools/vtpm_manager/migration/vtpm_manager_if.c
--- a/tools/vtpm_manager/migration/vtpm_manager_if.c
+++ b/tools/vtpm_manager/migration/vtpm_manager_if.c
@@ -50,15 +50,12 @@
 #include "vtpm_migrator.h"
 #include "vtpm_manager.h"
=20
-#define VTPM_TX_HP_FNAME       "/var/vtpm/fifos/from_console.fifo"
-#define VTPM_RX_HP_FNAME       "/var/vtpm/fifos/to_console.fifo"
-
 static vtpm_ipc_handle_t tx_ipc_h, rx_ipc_h;
=20
 TPM_RESULT vtpm_manager_open(){
=20
-  if ( (vtpm_ipc_init(&tx_ipc_h,  VTPM_TX_HP_FNAME, O_RDWR, TRUE) !=3D 0=
)
||  //FIXME: wronly
-       (vtpm_ipc_init(&rx_ipc_h,  VTPM_RX_HP_FNAME, O_RDWR, TRUE) !=3D 0=
)
) { //FIXME: rdonly
+  if ( (vtpm_ipc_init(&tx_ipc_h,  VTPM_TX_HP_FNAME, O_RDWR, TRUE, TRUE)
!=3D 0) ||  //FIXME: wronly
+       (vtpm_ipc_init(&rx_ipc_h,  VTPM_RX_HP_FNAME, O_RDWR, TRUE, TRUE)
!=3D 0) ) { //FIXME: rdonly
     vtpmlogerror(VTPM_LOG_VTPM, "Unable to connect to vtpm_manager.\n");=

     return TPM_IOERROR;
   }
diff --git a/tools/vtpm_manager/tcs/Makefile
b/tools/vtpm_manager/tcs/Makefile
--- a/tools/vtpm_manager/tcs/Makefile
+++ b/tools/vtpm_manager/tcs/Makefile
@@ -1,5 +1,10 @@
-XEN_ROOT =3D $(CURDIR)/../../..
-include $(XEN_ROOT)/tools/vtpm_manager/Rules.mk
+XEN_ROOT =3D $(realpath ../../..)
+include ../Rules.mk
+
+CFLAGS +=3D -I../crypto
+CFLAGS +=3D -I../util
+CFLAGS +=3D -I../manager
+
=20
 BIN        =3D libTCS.a
=20
diff --git a/tools/vtpm_manager/tcs/contextmgr.c
b/tools/vtpm_manager/tcs/contextmgr.c
--- a/tools/vtpm_manager/tcs/contextmgr.c
+++ b/tools/vtpm_manager/tcs/contextmgr.c
@@ -195,6 +195,7 @@ BOOL DeleteHandleFromList(   TCS_CONTEXT_HANDLE
hContext, // in
=20
 BOOL FreeHandleList(    CONTEXT_HANDLE*     pContextHandle) { // in
   HANDLE_LIST* pCurrentHandle;
+  HANDLE_LIST* pNext;
   BOOL returncode =3D TRUE;
 =20
   vtpmloginfo(VTPM_LOG_TCS_DEEP, "Freeing all handles for context\n");
@@ -205,6 +206,7 @@ BOOL FreeHandleList(    CONTEXT_HANDLE*   =20
pContextHandle) { // in
   pCurrentHandle =3D pContextHandle->pHandleList;
   while (pCurrentHandle !=3D NULL) {
   =20
+    pNext =3D pCurrentHandle->pNextHandle;
     switch (pCurrentHandle->type) {
     case TPM_RT_KEY:
       returncode =3D returncode && !TCSP_EvictKey(pContextHandle->handle=
,
pCurrentHandle->handle);
@@ -216,7 +218,7 @@ BOOL FreeHandleList(    CONTEXT_HANDLE*   =20
pContextHandle) { // in
       returncode =3D FALSE;
     }
   =20
-    pCurrentHandle =3D pCurrentHandle->pNextHandle;
+    pCurrentHandle =3D pNext;
   =20
   }
 =20
diff --git a/tools/vtpm_manager/tcs/tcs.c b/tools/vtpm_manager/tcs/tcs.c
--- a/tools/vtpm_manager/tcs/tcs.c
+++ b/tools/vtpm_manager/tcs/tcs.c
@@ -77,7 +77,7 @@ CONTEXT_HANDLE *LookupContext( TCS_CONTEXT_HANDLE=20
hContext) {
 //
-------------------------------------------------------------------------=
--------
 // Initialization/Uninitialization SubComponent API
 //
-------------------------------------------------------------------------=
--------
-TPM_RESULT TCS_create() {
+TPM_RESULT TCS_create(void) {
   TDDL_RESULT hRes =3D TDDL_E_FAIL;
   TPM_RESULT result =3D TPM_FAIL;
 =20
@@ -101,7 +101,7 @@ TPM_RESULT TCS_create() {
 }
=20
=20
-void TCS_destroy()
+void TCS_destroy(void)
 {
   TCS_m_nCount--;
 =20
@@ -113,14 +113,13 @@ void TCS_destroy()
     TCS_CONTEXT_HANDLE  *hContext;
   =20
     // Close all the TCS contexts. TCS should evict keys based on this
-    if (hashtable_count(context_ht) > 0) {
+    while (hashtable_count(context_ht) > 0) {
       context_itr =3D hashtable_iterator(context_ht);
-      do {
-        hContext =3D (TCS_CONTEXT_HANDLE *)
hashtable_iterator_key(context_itr);
-    if (TCS_CloseContext(*hContext) !=3D TPM_SUCCESS)
-        vtpmlogerror(VTPM_LOG_TCS, "Failed to close context %d
properly.\n", *hContext);
+
+      hContext =3D (TCS_CONTEXT_HANDLE *)
hashtable_iterator_key(context_itr);
+      if (TCS_CloseContext(*hContext) !=3D TPM_SUCCESS)
+        vtpmlogerror(VTPM_LOG_TCS, "Failed to close context %d
properly.\n", *hContext);
     =20
-      } while (hashtable_iterator_advance(context_itr));
       free(context_itr);
     }
     hashtable_destroy(context_ht, 1);
@@ -534,6 +533,10 @@ TPM_RESULT TCSP_TerminateHandle(TCS_CONTEXT_HANDLE
hContext, // in
               BSG_TYPE_UINT32, &handle);
   // fill paramSize again as we now have the correct size
   BSG_Pack(BSG_TYPE_UINT32, &InLength, InBuf+2);
+
+  if (!DeleteHandleFromList(hContext, handle)) {
+    vtpmlogerror(VTPM_LOG_TCS, "KeyHandle not removed from list\n");
+  }
 =20
   // call the TPM driver
   if ((hRes =3D TDDL_TransmitData(InBuf, InLength, OutBuf, &OutLength))
@@ -545,9 +548,6 @@ TPM_RESULT TCSP_TerminateHandle(TCS_CONTEXT_HANDLE
hContext, // in
                BSG_TYPE_UINT32, &paramSize,
                BSG_TPM_COMMAND_CODE, &returnCode);
   =20
-    if (!DeleteHandleFromList(hContext, handle))
-      vtpmlogerror(VTPM_LOG_TCS, "KeyHandle not removed from list\n");
-     =20
   =20
     if (returnCode =3D=3D TPM_SUCCESS && tag =3D=3D TPM_TAG_RSP_COMMAND)=
 {
       // Print debug info
@@ -882,6 +882,7 @@ TPM_RESULT TCSP_CreateWrapKey(TCS_CONTEXT_HANDLE
hContext,   // in
     =20
       memcpy(*prgbKey, tempBuf, *pcKeySize);
     =20
+      BSG_Destroy(BSG_TPM_KEY, &wrappedKey);
       vtpmloginfo(VTPM_LOG_TCS_DEEP, "Received paramSize : %d\n",
paramSize);
     } else
       vtpmlogerror(VTPM_LOG_TCS, "TCSP_CreateWrapKey Failed with return
code %s\n", tpm_get_error_name(returnCode));
@@ -980,6 +981,10 @@ TPM_RESULT TCSP_EvictKey(TCS_CONTEXT_HANDLE
hContext, // in
   BSG_Pack(BSG_TYPE_UINT32, &InLength, InBuf+2);
 =20
   vtpmloginfo(VTPM_LOG_TCS_DEEP, "Sending paramSize =3D %d\n", InLength)=
;
+
+  if (!DeleteHandleFromList(hContext, hKey)) {
+    vtpmlogerror(VTPM_LOG_TCS, "KeyHandle not removed from list\n");
+  }    =20
 =20
   // call the TPM driver
   if ((hRes =3D TDDL_TransmitData(InBuf, InLength, OutBuf, &OutLength))
=3D=3D TDDL_SUCCESS) {
@@ -989,10 +994,6 @@ TPM_RESULT TCSP_EvictKey(TCS_CONTEXT_HANDLE
hContext, // in
                BSG_TYPE_UINT32, &paramSize,
                BSG_TPM_COMMAND_CODE, &returnCode);
   =20
-    if (!DeleteHandleFromList(hContext, hKey)) {
-      vtpmlogerror(VTPM_LOG_TCS, "KeyHandle not removed from list\n");
-    }    =20
-  =20
     if (returnCode =3D=3D TPM_SUCCESS && tag =3D=3D TPM_TAG_RSP_COMMAND)=
 {
       vtpmloginfo(VTPM_LOG_TCS_DEEP, "Received paramSize : %d\n",
paramSize);
     } else {
@@ -1019,7 +1020,7 @@ TPM_RESULT TCSP_GetRandom(TCS_CONTEXT_HANDLE
hContext,  // in
   TDDL_UINT32  OutLength =3D TCPA_MAX_BUFFER_LENGTH;
 =20
   // check input params
-  if (bytesRequested =3D=3D NULL || *randomBytes =3D=3D NULL){
+  if (bytesRequested =3D=3D NULL || randomBytes =3D=3D NULL){
     return TPM_BAD_PARAMETER;
   }
 =20
diff --git a/tools/vtpm_manager/tcs/tcs.h b/tools/vtpm_manager/tcs/tcs.h
--- a/tools/vtpm_manager/tcs/tcs.h
+++ b/tools/vtpm_manager/tcs/tcs.h
@@ -50,8 +50,8 @@
 // Exposed API
 // ------------------------------------------------------------------
=20
-TPM_RESULT TCS_create();
-void TCS_destroy();
+TPM_RESULT TCS_create(void);
+void TCS_destroy(void);
=20
 TPM_RESULT TCS_OpenContext( /* OUT */ TCS_CONTEXT_HANDLE* hContext );
=20
diff --git a/tools/vtpm_manager/tcs/tpmddl.c
b/tools/vtpm_manager/tcs/tpmddl.c
--- /dev/null
+++ b/tools/vtpm_manager/tcs/tpmddl.c
@@ -0,0 +1,168 @@
+/*
+ * Copyright (c) 2010-2012 United States Government, as represented by
+ * the Secretary of Defense.  All rights reserved.
+ *
+ * THIS SOFTWARE AND ITS DOCUMENTATION ARE PROVIDED AS IS AND WITHOUT
+ * ANY EXPRESS OR IMPLIED WARRANTIES WHATSOEVER. ALL WARRANTIES
+ * INCLUDING, BUT NOT LIMITED TO, PERFORMANCE, MERCHANTABILITY, FITNESS
+ * FOR A PARTICULAR  PURPOSE, AND NONINFRINGEMENT ARE HEREBY
+ * DISCLAIMED. USERS ASSUME THE ENTIRE RISK AND LIABILITY OF USING THE
+ * SOFTWARE.
+ */
+
+#include <string.h>
+#include "tpmddl.h"
+#include "tcs.h"
+#include "bsg.h"
+#include "log.h"
+
+#define MIN(X,Y) ((X) < (Y) ? (X) : (Y))
+
+TDDL_RESULT TDDL_GetCapability( TDDL_UINT32 cap,
+      TDDL_UINT32 sub,
+      TDDL_BYTE* buffer,
+      TDDL_UINT32* size)
+{
+   TDDL_RESULT status;
+
+   TPM_TAG tag =3D TPM_TAG_RQU_COMMAND;
+   UINT32 paramsize =3D 22;
+   UINT32 outsize;
+   TPM_COMMAND_CODE ord =3D TPM_ORD_GetCapability;
+   UINT32 subcapsize =3D 4;
+
+   BYTE inbuf[TCPA_MAX_BUFFER_LENGTH];
+   BYTE outbuf[TCPA_MAX_BUFFER_LENGTH];
+
+   int offset;
+
+   BSG_PackList(inbuf, 6,
+     BSG_TPM_TAG, &(tag),
+     BSG_TYPE_UINT32, &(paramsize),
+     BSG_TPM_COMMAND_CODE, &(ord),
+     BSG_TYPE_UINT32, &(cap),
+     BSG_TYPE_UINT32, &(subcapsize),
+     BSG_TYPE_UINT32, &(sub)
+     );
+
+   //Send the command, get the response
+   TPMTRYRETURN(TDDL_TransmitData( inbuf, paramsize, outbuf, &outsize));=

+
+   offset =3D BSG_UnpackList(outbuf, 4,
+     BSG_TPM_TAG, &(tag),
+     BSG_TYPE_UINT32, &(paramsize),
+     BSG_TPM_RESULT, &(status),
+     BSG_TYPE_UINT32, size
+     );
+   if (status !=3D TPM_SUCCESS || tag !=3D TPM_TAG_RSP_COMMAND) {
+      return status;
+   }
+   if(*size >=3D TCPA_MAX_BUFFER_LENGTH - offset) {
+      return TPM_FAIL;
+   }
+   memcpy(buffer, outbuf + offset, *size);
+
+abort_egress:
+   return status;
+}
+
+TDDL_RESULT TDDL_FlushSpecific(TDDL_UINT32 handle, TDDL_UINT32 res) {
+    /* FIXME: Add code here to check if TPM_FlushSpecific is not
supported (on 1.1 only TPMS?)
+    * If this is the case then we need to use TPM_EvictKey for key handl=
es
+    * and TPM_Terminate_Handle/TPM_Reset for auth handles */
+   TDDL_RESULT status;
+
+   TPM_TAG tag =3D TPM_TAG_RQU_COMMAND;
+   UINT32 paramsize =3D 18;
+   TPM_COMMAND_CODE ord =3D TPM_ORD_FlushSpecific;
+
+   BYTE inbuf[TCPA_MAX_BUFFER_LENGTH];
+   BYTE outbuf[TCPA_MAX_BUFFER_LENGTH];
+   UINT32 outsize;
+
+   int offset;
+
+   BSG_PackList(inbuf, 5,
+     BSG_TPM_TAG, &(tag),
+     BSG_TYPE_UINT32, &(paramsize),
+     BSG_TPM_COMMAND_CODE, &(ord),
+     BSG_TPM_HANDLE, &(handle),
+     BSG_TPM_RESOURCE_TYPE, &(res)
+     );
+
+   //Send command
+   TPMTRYRETURN(TDDL_TransmitData( inbuf, paramsize, outbuf, &outsize ))=
;
+
+   offset =3D BSG_UnpackList(outbuf, 4,
+     BSG_TPM_TAG, &(tag),
+     BSG_TYPE_UINT32, &(paramsize),
+     BSG_TPM_RESULT, &(status)
+     );
+
+abort_egress:
+   return status;
+ =20
+}
+
+TDDL_RESULT TDDL_FlushAllResources(void) {
+  TDDL_RESULT status =3D TPM_SUCCESS;
+
+  TDDL_BYTE buf[TCPA_MAX_BUFFER_LENGTH];
+  TDDL_UINT32 bufsiz;
+
+  UINT16 packedsz;
+  int size;
+  UINT32 handle;
+  BYTE* ptr;
+
+  int i, j;
+
+#define RLISTSZ 6
+  TPM_RESOURCE_TYPE reslist[RLISTSZ] =3D { TPM_RT_KEY, TPM_RT_AUTH,
TPM_RT_TRANS, TPM_RT_COUNTER, TPM_RT_DAA_TPM, TPM_RT_CONTEXT };
+
+  //Iterate through each resource type and flush all handles
+  for(i =3D 0; i < RLISTSZ; ++i) {
+     TPM_RESOURCE_TYPE res =3D reslist[i];
+     // Get list of current key handles
+     if((status =3D TDDL_GetCapability( TPM_CAP_HANDLE, res, buf,
&bufsiz)) !=3D TPM_SUCCESS) {
+    //This can happen if the resource type is not supported
+    //If this happens just silently skip the resource type
+    if(status =3D=3D TPM_BAD_MODE) {
+       status =3D TPM_SUCCESS;
+       continue;
+    //Otherwise we just fail
+    } else {
+       TPMTRYRETURN(status);
+    }
+     }
+
+#if 0
+     //DEBUG PRINTOUTS
+     printf("TPM_GetCapability(TPM_CAP_HANDLE, %lu)\n", (unsigned long)
res);
+     for(j =3D 0; j < bufsiz; ++j) {
+    printf("%02X ", buf[j]);
+     }
+     printf("\n");
+#endif
+
+     ptr =3D buf;
+     ptr +=3D BSG_Unpack(BSG_TYPE_UINT16, ptr, &(packedsz));
+     size =3D packedsz;
+
+     //Flush each handle
+     if(size) {
+    vtpmloginfo(VTPM_LOG_VTPM, "Flushing %u handle(s) of type %lu\n",
size, (unsigned long) res);
+    for(j =3D 0; j < size; ++j) {
+       ptr +=3D BSG_Unpack(BSG_TPM_HANDLE, ptr, &(handle));
+       TPMTRYRETURN(TDDL_FlushSpecific(handle, res));
+    }
+     }
+
+  }
+
+  goto egress;
+abort_egress:
+egress:
+  return status;
+}
+
diff --git a/tools/vtpm_manager/tcs/tpmddl.h
b/tools/vtpm_manager/tcs/tpmddl.h
--- a/tools/vtpm_manager/tcs/tpmddl.h
+++ b/tools/vtpm_manager/tcs/tpmddl.h
@@ -50,13 +50,14 @@ typedef unsigned int TDDL_UINT32;
 typedef TDDL_UINT32 TDDL_RESULT;
 typedef unsigned char TDDL_BYTE;
=20
-TDDL_RESULT TDDL_Open();
-void TDDL_Close();
+TDDL_RESULT TDDL_Open(void);
+TDDL_RESULT TDDL_Open_use_fd(int fd);
+void TDDL_Close(void);
 TDDL_RESULT TDDL_TransmitData( TDDL_BYTE* in,
                    TDDL_UINT32 insize,
                    TDDL_BYTE* out,
                    TDDL_UINT32* outsize);
-TDDL_RESULT TDDL_GetStatus();
+TDDL_RESULT TDDL_GetStatus(void);
 TDDL_RESULT TDDL_GetCapability( TDDL_UINT32 cap,
                 TDDL_UINT32 sub,
                 TDDL_BYTE* buffer,
@@ -66,4 +67,10 @@ TDDL_RESULT TDDL_SetCapability( TDDL_UINT32 cap,
                 TDDL_BYTE* buffer,
                 TDDL_UINT32* size);
=20
+TDDL_RESULT TDDL_FlushSpecific(TDDL_UINT32 handle,
+                TDDL_UINT32 res);
+
+TDDL_RESULT TDDL_FlushAllResources(void);
+
+
 #endif // __TPMDDL_H__
diff --git a/tools/vtpm_manager/tcs/transmit.c
b/tools/vtpm_manager/tcs/transmit.c
--- a/tools/vtpm_manager/tcs/transmit.c
+++ b/tools/vtpm_manager/tcs/transmit.c
@@ -104,12 +104,13 @@ TDDL_TransmitData( TDDL_BYTE* in,
   return status;
 }
=20
-TPM_RESULT TDDL_Open() {
+TDDL_RESULT TDDL_Open(void) {
 =20
   TDDL_RESULT status =3D TDDL_SUCCESS;
 =20
+  /* If tpm device is already open just silently return success */
   if (g_TDDL_open)
-    return TPM_FAIL;
+    return TPM_SUCCESS;
=20
 #ifdef DUMMY_TPM=20
   *g_rx_fdp =3D open (TPM_RX_FNAME, O_RDWR);
@@ -117,7 +118,7 @@ TPM_RESULT TDDL_Open() {
=20
   g_tx_fd =3D open (TPM_TX_FNAME, O_RDWR);
   if (g_tx_fd < 0) {
-    vtpmlogerror(VTPM_LOG_TXDATA, "TPM open failed");
+    vtpmlogerror(VTPM_LOG_TXDATA, "TPM open failed\n");
     return TPM_IOERROR;
   }
 =20
@@ -126,7 +127,20 @@ TPM_RESULT TDDL_Open() {
   return status;
 }
=20
-void TDDL_Close() {
+TDDL_RESULT TDDL_Open_use_fd(int fd) {
+   TDDL_RESULT status =3D TDDL_SUCCESS;
+
+   if(g_TDDL_open)
+      return TPM_FAIL;
+
+   g_tx_fd =3D fd;
+
+   g_TDDL_open =3D 1;
+
+   return status;
+}
+
+void TDDL_Close(void) {
   if (! g_TDDL_open)
         return;
=20
diff --git a/tools/vtpm_manager/util/Makefile
b/tools/vtpm_manager/util/Makefile
--- a/tools/vtpm_manager/util/Makefile
+++ b/tools/vtpm_manager/util/Makefile
@@ -1,5 +1,10 @@
-XEN_ROOT =3D $(CURDIR)/../../..
-include $(XEN_ROOT)/tools/vtpm_manager/Rules.mk
+XEN_ROOT =3D $(realpath ../../..)
+include ../Rules.mk
+
+CFLAGS +=3D -I../crypto
+CFLAGS +=3D -I../tcs
+CFLAGS +=3D -I../manager
+
=20
 BIN        =3D libTCGUtils.a
=20
diff --git a/tools/vtpm_manager/util/bsg.c b/tools/vtpm_manager/util/bsg.=
c
--- a/tools/vtpm_manager/util/bsg.c
+++ b/tools/vtpm_manager/util/bsg.c
@@ -41,6 +41,7 @@
 #include <string.h>
 #include <stdarg.h>
 #include <malloc.h>
+#include <stdlib.h>
 #include "tcg.h"
 #include "crypto.h"
 #include "bsg.h"
@@ -317,7 +318,7 @@ static const BSG_Format* find_format (BSG_Type t) {
 // FIXME: should have a function be passed in here which is called if
the test
 // fails. Then the caller can decide what to do: abort, notify, whatever=

 //
-BOOL BSG_static_selfcheck ()
+BOOL BSG_static_selfcheck (void)
 {
   int i;
=20
diff --git a/tools/vtpm_manager/util/bsg.h b/tools/vtpm_manager/util/bsg.=
h
--- a/tools/vtpm_manager/util/bsg.h
+++ b/tools/vtpm_manager/util/bsg.h
@@ -161,6 +161,6 @@ TPM_RESULT BSG_DestroyTuple (int numParams,
pack_tuple_t params[]);
 void BSG_PackConst(BSG_UINT32 val, int size, BSG_BYTE* dst);
 BSG_UINT32 BSG_UnpackConst(const BSG_BYTE* src, int size);
=20
-BOOL BSG_static_selfcheck ();
+BOOL BSG_static_selfcheck (void);
=20
 #endif
diff --git a/tools/vtpm_manager/util/buffer.c
b/tools/vtpm_manager/util/buffer.c
--- a/tools/vtpm_manager/util/buffer.c
+++ b/tools/vtpm_manager/util/buffer.c
@@ -40,6 +40,7 @@
=20
 #include "tcg.h"
 #include "bsg.h"
+#include "log.h"
 #include "buffer.h"
=20
 static TPM_RESULT buffer_priv_realloc (buffer_t * buf, tpm_size_t newsiz=
e);
@@ -51,6 +52,7 @@ static TPM_RESULT buffer_priv_realloc (buffer_t * buf,
tpm_size_t newsize);
 TPM_RESULT buffer_init (buffer_t * buf, tpm_size_t initsize, const
BYTE* initval) {
   if (initsize =3D=3D 0) {
     memset(buf, 0, sizeof(*buf));
+    buf->bytes =3D NULL;
     return TPM_SUCCESS;
   }
 =20
@@ -62,8 +64,11 @@ TPM_RESULT buffer_init (buffer_t * buf, tpm_size_t
initsize, const BYTE* initval
   buf->size =3D initsize;
   buf->alloc_size =3D initsize;
 =20
-  if (initval)
+  if (initval) {
     memcpy (buf->bytes, initval, initsize);
+  } else {
+     memset(buf->bytes, 0, initsize);
+  }
 =20
   buf->is_owner =3D TRUE;
 =20
@@ -190,6 +195,29 @@ TPM_RESULT buffer_append_raw (buffer_t * buf,
tpm_size_t len, const BYTE* bytes)
   return status;
 }
=20
+TPM_RESULT buffer_prepend_raw(buffer_t * buf, tpm_size_t len, const
BYTE* bytes) {
+  TPM_RESULT status =3D TPM_SUCCESS;
+
+  if (buf->alloc_size < buf->size + len) {
+    TPMTRYRETURN( buffer_priv_realloc (buf, buf->size + len) );
+  }
+
+  if(buf->size > 0) {
+    memmove(buf->bytes + len, buf->bytes, buf->size);
+  }
+  memcpy(buf->bytes, bytes, len);
+
+  buf->size +=3D len;
+
+  goto egress;
+
+ abort_egress:
+
+ egress:
+
+  return status;
+}
+
 tpm_size_t buffer_len (const buffer_t* buf) {
   return buf->size;
 }
@@ -199,7 +227,6 @@ TPM_RESULT buffer_free (buffer_t * buf) {
     free (buf->bytes);
     buf->bytes =3D NULL;
     buf->size =3D buf->alloc_size =3D 0;
- =20
   }
 =20
   return TPM_SUCCESS;
@@ -224,3 +251,13 @@ TPM_RESULT buffer_priv_realloc (buffer_t * buf,
tpm_size_t newsize) {
 =20
   return TPM_SUCCESS;
 }
+
+TPM_RESULT buffer_truncate(buffer_t* buf, tpm_size_t len)
+{
+   if(len <=3D buf->size) {
+      buf->size =3D len;
+      return TPM_SUCCESS;
+   }
+
+   return TPM_FAIL;
+}
diff --git a/tools/vtpm_manager/util/buffer.h
b/tools/vtpm_manager/util/buffer.h
--- a/tools/vtpm_manager/util/buffer.h
+++ b/tools/vtpm_manager/util/buffer.h
@@ -92,4 +92,9 @@ TPM_RESULT buffer_free (buffer_t * buf);
=20
 TPM_RESULT buffer_append_raw (buffer_t * buf, tpm_size_t len, const
BYTE* bytes);
=20
+TPM_RESULT buffer_prepend_raw(buffer_t * buf, tpm_size_t len, const
BYTE* bytes);
+
+//Reduce the size of the buffer, if len > buffer size returns an error
+TPM_RESULT buffer_truncate(buffer_t* buf, tpm_size_t len);
+
 #endif // _TOOLS_H_
diff --git a/tools/vtpm_manager/util/hashtable.c
b/tools/vtpm_manager/util/hashtable.c
--- a/tools/vtpm_manager/util/hashtable.c
+++ b/tools/vtpm_manager/util/hashtable.c
@@ -32,12 +32,6 @@
  * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
 */
=20
-/*
- * There are duplicates of this code in:
- *  - tools/xenstore/hashtable.c
- *  - tools/blktap2/drivers/hashtable.c
- */
-
 #include "hashtable.h"
 #include "hashtable_private.h"
 #include <stdlib.h>
diff --git a/tools/vtpm_manager/util/hashtable.h
b/tools/vtpm_manager/util/hashtable.h
--- a/tools/vtpm_manager/util/hashtable.h
+++ b/tools/vtpm_manager/util/hashtable.h
@@ -32,11 +32,6 @@
  * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
 */
=20
-/*
- * There are duplicates of this code in:
- *  - tools/xenstore/hashtable.h
- *  - tools/blktap2/drivers/hashtable.h
- */
=20
 #ifndef __HASHTABLE_CWC22_H__
 #define __HASHTABLE_CWC22_H__
diff --git a/tools/vtpm_manager/util/hashtable_itr.c
b/tools/vtpm_manager/util/hashtable_itr.c
--- a/tools/vtpm_manager/util/hashtable_itr.c
+++ b/tools/vtpm_manager/util/hashtable_itr.c
@@ -32,11 +32,6 @@
  * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
 */
=20
-/*
- * There are duplicates of this code in:
- *  - tools/blktap2/drivers/hashtable_itr.c
- */
-
 #include "hashtable.h"
 #include "hashtable_private.h"
 #include "hashtable_itr.h"
diff --git a/tools/vtpm_manager/util/hashtable_itr.h
b/tools/vtpm_manager/util/hashtable_itr.h
--- a/tools/vtpm_manager/util/hashtable_itr.h
+++ b/tools/vtpm_manager/util/hashtable_itr.h
@@ -32,11 +32,6 @@
  * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
 */
=20
-/*
- * There are duplicates of this code in:
- *  - tools/blktap2/drivers/hashtable_itr.h
- */
-
=20
 #ifndef __HASHTABLE_ITR_CWC22__
 #define __HASHTABLE_ITR_CWC22__
diff --git a/tools/vtpm_manager/util/hashtable_private.h
b/tools/vtpm_manager/util/hashtable_private.h
--- a/tools/vtpm_manager/util/hashtable_private.h
+++ b/tools/vtpm_manager/util/hashtable_private.h
@@ -32,12 +32,6 @@
  * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
 */
=20
-/*
- * There are duplicates of this code in:
- *  - tools/xenstore/hashtable_private.h
- *  - tools/blktap2/drivers/hashtable_private.h
- */
-
 #ifndef __HASHTABLE_PRIVATE_CWC22_H__
 #define __HASHTABLE_PRIVATE_CWC22_H__
=20
diff --git a/tools/vtpm_manager/util/log.c b/tools/vtpm_manager/util/log.=
c
--- a/tools/vtpm_manager/util/log.c
+++ b/tools/vtpm_manager/util/log.c
@@ -38,6 +38,17 @@
 #include "buffer.h"
 #include "tcg.h"
=20
+char *module_names[] =3D { "",
+                                "CRYPTO",
+                                "BSG",
+                                "TXDATA",
+                                "TCS",
+                                "TCS",
+                                "VTSP",
+                                "VTPM",
+                                "VTPM",
+                                "VTSP"
+                              };
 // Helper code for the consts, eg. to produce messages for error codes.
=20
 typedef struct error_code_entry_t {
diff --git a/tools/vtpm_manager/util/log.h b/tools/vtpm_manager/util/log.=
h
--- a/tools/vtpm_manager/util/log.h
+++ b/tools/vtpm_manager/util/log.h
@@ -36,6 +36,8 @@
=20
 #include <stdint.h>             // for uint32_t
 #include <stddef.h>             // for pointer NULL
+#include <stdio.h>
+#include <tcg.h>
=20
 // =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D LOGGING =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
=20
@@ -50,17 +52,7 @@
 #define VTPM_LOG_VTPM_DEEP   8
 #define VTPM_LOG_VTSP_DEEP   9
=20
-static char *module_names[] =3D { "",
-                                "CRYPTO",
-                                "BSG",
-                                "TXDATA",
-                                "TCS",
-                                "TCS",
-                                "VTSP",
-                                "VTPM",
-                                "VTPM",
-                                "VTSP"
-                              };
+extern char *module_names[];
=20
 // Default to standard logging
 #ifndef LOGGING_MODULES
diff --git a/tools/vtpm_manager/util/tcg.h b/tools/vtpm_manager/util/tcg.=
h
--- a/tools/vtpm_manager/util/tcg.h
+++ b/tools/vtpm_manager/util/tcg.h
@@ -197,6 +197,7 @@ typedef struct pack_buf_t {
   UINT32 size;
   BYTE * data;
 } pack_buf_t;
+#define NULL_PACK_BUF {0,0}
=20
 typedef struct pack_constbuf_t {
   UINT32 size;
@@ -295,6 +296,35 @@ typedef struct pack_constbuf_t {
 #define TPM_ORD_LoadKeyContext           (181UL + TPM_PROTECTED_ORDINAL)=

 #define TPM_ORD_SaveAuthContext          (182UL + TPM_PROTECTED_ORDINAL)=

 #define TPM_ORD_LoadAuthContext          (183UL + TPM_PROTECTED_ORDINAL)=

+#define TPM_ORD_SaveContext                      (184UL +
TPM_PROTECTED_ORDINAL)
+#define TPM_ORD_LoadContext                      (185UL +
TPM_PROTECTED_ORDINAL)
+#define TPM_ORD_FlushSpecific                    (186UL +
TPM_PROTECTED_ORDINAL)
+#define TPM_ORD_PCR_Reset                        (200UL +
TPM_PROTECTED_ORDINAL)
+#define TPM_ORD_NV_DefineSpace                   (204UL +
TPM_PROTECTED_ORDINAL)
+#define TPM_ORD_NV_WriteValue                    (205UL +
TPM_PROTECTED_ORDINAL)
+#define TPM_ORD_NV_WriteValueAuth                (206UL +
TPM_PROTECTED_ORDINAL)
+#define TPM_ORD_NV_ReadValue                     (207UL +
TPM_PROTECTED_ORDINAL)
+#define TPM_ORD_NV_ReadValueAuth                 (208UL +
TPM_PROTECTED_ORDINAL)
+#define TPM_ORD_Delegate_UpdateVerification      (209UL +
TPM_PROTECTED_ORDINAL)
+#define TPM_ORD_Delegate_Manage                  (210UL +
TPM_PROTECTED_ORDINAL)
+#define TPM_ORD_Delegate_CreateKeyDelegation     (212UL +
TPM_PROTECTED_ORDINAL)
+#define TPM_ORD_Delegate_CreateOwnerDelegation   (213UL +
TPM_PROTECTED_ORDINAL)
+#define TPM_ORD_Delegate_VerifyDelegation        (214UL +
TPM_PROTECTED_ORDINAL)
+#define TPM_ORD_Delegate_LoadOwnerDelegation     (216UL +
TPM_PROTECTED_ORDINAL)
+#define TPM_ORD_Delegate_ReadAuth                (217UL +
TPM_PROTECTED_ORDINAL)
+#define TPM_ORD_Delegate_ReadTable               (219UL +
TPM_PROTECTED_ORDINAL)
+#define TPM_ORD_CreateCounter                    (220UL +
TPM_PROTECTED_ORDINAL)
+#define TPM_ORD_IncrementCounter                 (221UL +
TPM_PROTECTED_ORDINAL)
+#define TPM_ORD_ReadCounter                      (222UL +
TPM_PROTECTED_ORDINAL)
+#define TPM_ORD_ReleaseCounter                   (223UL +
TPM_PROTECTED_ORDINAL)
+#define TPM_ORD_ReleaseCounterOwner              (224UL +
TPM_PROTECTED_ORDINAL)
+#define TPM_ORD_EstablishTransport               (230UL +
TPM_PROTECTED_ORDINAL)
+#define TPM_ORD_ExecuteTransport                 (231UL +
TPM_PROTECTED_ORDINAL)
+#define TPM_ORD_ReleaseTransportSigned           (232UL +
TPM_PROTECTED_ORDINAL)
+#define TPM_ORD_GetTicks                         (241UL +
TPM_PROTECTED_ORDINAL)
+#define TPM_ORD_TickStampBlob                    (242UL +
TPM_PROTECTED_ORDINAL)
+#define TPM_ORD_MAX                              (256UL +
TPM_PROTECTED_ORDINAL)
+
 #define TSC_ORD_PhysicalPresence         (10UL + TPM_CONNECTION_ORDINAL)=

=20
=20
@@ -419,8 +449,16 @@ typedef struct pack_constbuf_t {
 /// TPM_ResourceTypes
 #define TPM_RT_KEY      0x00000001
 #define TPM_RT_AUTH     0x00000002
+#define TPM_RT_HASH     0x00000003
 #define TPM_RT_TRANS    0x00000004
 #define TPM_RT_CONTEXT  0x00000005
+#define TPM_RT_COUNTER  0x00000006
+#define TPM_RT_DELEGATE 0x00000007
+#define TPM_RT_DAA_TPM  0x00000008
+#define TPM_RT_DAA_V0   0x00000009
+#define TPM_RT_DAA_V1   0x0000000A
+
+
=20
 // TPM_PROTOCOL_ID values
 #define TPM_PID_OIAP 0x0001
@@ -447,6 +485,64 @@ typedef struct pack_constbuf_t {
 #define TPM_SS_RSASSAPKCS1v15_SHA1 0x0002
 #define TPM_SS_RSASSAPKCS1v15_DER 0x0003
=20
+/*
+ * TPM_CAPABILITY_AREA Values for TPM_GetCapability ([TPM_Part2],
Section 21.1)
+ */
+#define TPM_CAP_ORD                     0x00000001
+#define TPM_CAP_ALG                     0x00000002
+#define TPM_CAP_PID                     0x00000003
+#define TPM_CAP_FLAG                    0x00000004
+#define TPM_CAP_PROPERTY                0x00000005
+#define TPM_CAP_VERSION                 0x00000006
+#define TPM_CAP_KEY_HANDLE              0x00000007
+#define TPM_CAP_CHECK_LOADED            0x00000008
+#define TPM_CAP_SYM_MODE                0x00000009
+#define TPM_CAP_KEY_STATUS              0x0000000C
+#define TPM_CAP_NV_LIST                 0x0000000D
+#define TPM_CAP_MFR                     0x00000010
+#define TPM_CAP_NV_INDEX                0x00000011
+#define TPM_CAP_TRANS_ALG               0x00000012
+#define TPM_CAP_HANDLE                  0x00000014
+#define TPM_CAP_TRANS_ES                0x00000015
+#define TPM_CAP_AUTH_ENCRYPT            0x00000017
+#define TPM_CAP_SELECT_SIZE             0x00000018
+#define TPM_CAP_DA_LOGIC                0x00000019
+#define TPM_CAP_VERSION_VAL             0x0000001A
+
+/* subCap definitions ([TPM_Part2], Section 21.2) */
+#define TPM_CAP_PROP_PCR                0x00000101
+#define TPM_CAP_PROP_DIR                0x00000102
+#define TPM_CAP_PROP_MANUFACTURER       0x00000103
+#define TPM_CAP_PROP_KEYS               0x00000104
+#define TPM_CAP_PROP_MIN_COUNTER        0x00000107
+#define TPM_CAP_FLAG_PERMANENT          0x00000108
+#define TPM_CAP_FLAG_VOLATILE           0x00000109
+#define TPM_CAP_PROP_AUTHSESS           0x0000010A
+#define TPM_CAP_PROP_TRANSESS           0x0000010B
+#define TPM_CAP_PROP_COUNTERS           0x0000010C
+#define TPM_CAP_PROP_MAX_AUTHSESS       0x0000010D
+#define TPM_CAP_PROP_MAX_TRANSESS       0x0000010E
+#define TPM_CAP_PROP_MAX_COUNTERS       0x0000010F
+#define TPM_CAP_PROP_MAX_KEYS           0x00000110
+#define TPM_CAP_PROP_OWNER              0x00000111
+#define TPM_CAP_PROP_CONTEXT            0x00000112
+#define TPM_CAP_PROP_MAX_CONTEXT        0x00000113
+#define TPM_CAP_PROP_FAMILYROWS         0x00000114
+#define TPM_CAP_PROP_TIS_TIMEOUT        0x00000115
+#define TPM_CAP_PROP_STARTUP_EFFECT     0x00000116
+#define TPM_CAP_PROP_DELEGATE_ROW       0x00000117
+#define TPM_CAP_PROP_MAX_DAASESS        0x00000119
+#define TPM_CAP_PROP_DAASESS            0x0000011A
+#define TPM_CAP_PROP_CONTEXT_DIST       0x0000011B
+#define TPM_CAP_PROP_DAA_INTERRUPT      0x0000011C
+#define TPM_CAP_PROP_SESSIONS           0x0000011D
+#define TPM_CAP_PROP_MAX_SESSIONS       0x0000011E
+#define TPM_CAP_PROP_CMK_RESTRICTION    0x0000011F
+#define TPM_CAP_PROP_DURATION           0x00000120
+#define TPM_CAP_PROP_ACTIVE_COUNTER     0x00000122
+#define TPM_CAP_PROP_MAX_NV_AVAILABLE   0x00000123
+#define TPM_CAP_PROP_INPUT_BUFFER       0x00000124
+
 // TPM_KEY_USAGE values
 #define TPM_KEY_EK 0x0000
 #define TPM_KEY_SIGNING 0x0010
diff --git a/tools/vtpm_manager/vtpmconnd/Makefile
b/tools/vtpm_manager/vtpmconnd/Makefile
--- /dev/null
+++ b/tools/vtpm_manager/vtpmconnd/Makefile
@@ -0,0 +1,30 @@
+# Copyright (c) 2010-2012 United States Government, as represented by
+# the Secretary of Defense.  All rights reserved.
+#
+# THIS SOFTWARE AND ITS DOCUMENTATION ARE PROVIDED AS IS AND WITHOUT
+# ANY EXPRESS OR IMPLIED WARRANTIES WHATSOEVER. ALL WARRANTIES
+# INCLUDING, BUT NOT LIMITED TO, PERFORMANCE, MERCHANTABILITY, FITNESS
+# FOR A PARTICULAR  PURPOSE, AND NONINFRINGEMENT ARE HEREBY
+# DISCLAIMED. USERS ASSUME THE ENTIRE RISK AND LIABILITY OF USING THE
+# SOFTWARE.
+#
+
+XEN_ROOT =3D $(realpath ../../..)
+include ../Rules.mk
+
+BIN=3Dvtpmconnd
+OBJS=3Dvtpmconnd.o
+CFLAGS=3D-O2 -Wall
+
+all: ${BIN}
+
+${BIN}: ${OBJS}
+    gcc -o $@ $<
+
+install: ${BIN}
+    install -m 0755 ${BIN} $(DESTDIR)$(BINDIR)/$(BIN)
+
+.PHONY: mrproper
+mrproper: clean
+clean:
+    -rm ${BIN} ${OBJS}
diff --git a/tools/vtpm_manager/vtpmconnd/vtpmconnd.c
b/tools/vtpm_manager/vtpmconnd/vtpmconnd.c
--- /dev/null
+++ b/tools/vtpm_manager/vtpmconnd/vtpmconnd.c
@@ -0,0 +1,253 @@
+/*
+ * Copyright (c) 2010-2012 United States Government, as represented by
+ * the Secretary of Defense.  All rights reserved.
+ *
+ * THIS SOFTWARE AND ITS DOCUMENTATION ARE PROVIDED AS IS AND WITHOUT
+ * ANY EXPRESS OR IMPLIED WARRANTIES WHATSOEVER. ALL WARRANTIES
+ * INCLUDING, BUT NOT LIMITED TO, PERFORMANCE, MERCHANTABILITY, FITNESS
+ * FOR A PARTICULAR  PURPOSE, AND NONINFRINGEMENT ARE HEREBY
+ * DISCLAIMED. USERS ASSUME THE ENTIRE RISK AND LIABILITY OF USING THE
+ * SOFTWARE.
+ */
+
+#include <stdio.h>
+#include <string.h>
+#include <errno.h>
+#include <getopt.h>
+#include <stdint.h>
+#include <unistd.h>
+#include <fcntl.h>
+#include <signal.h>
+#include <ctype.h>
+#include "../manager/vtpm_manager.h"
+
+#define VTPM_BE "/dev/vtpm"
+#define TPM_DEV "/dev/tpm0"
+#define MAX_CMD 4096
+#define DEVNULL "/dev/null"
+#define TPM_SUCCESS_RESP "\x00\x00\x00\x00" "\x01\xC1"
"\x00\x00\x00\x00" "\x00\x00\x00\x00"
+#define TPM_SUCCESS_RESPLEN 14
+
+static int quit =3D 0;
+
+struct Opts {
+   const char* vtpmbe;
+   const char* tpmdev;
+   int verbosity;
+   int daemon;
+};
+
+struct Opts opts =3D {
+   .vtpmbe =3D VTPM_BE,
+   .tpmdev =3D TPM_DEV,
+   .verbosity =3D 0,
+   .daemon =3D 1,
+};
+
+void usage(char* argv0) {
+fprintf(stderr, "Usage:\n \
+\t%s [options] [tpm device node]\n\
+\n\
+-h\t\tdisplay usage message\n\
+-v\t\tturn up verbosity level\n\
+-t <FILE>\tuse FILE for tpm device (default " TPM_DEV ")\n\
+-b <FILE>\tset vtpm backend device to FILE (default: " VTPM_BE ")\n\
+-f\t\trun in the foreground\n",
+argv0
+);
+}
+
+void sighandler(int signum) {
+   quit =3D 1;
+}
+
+int main_loop(int vbefd, int tpmfd) {
+   uint8_t buf[MAX_CMD];
+   ssize_t size, wrote;
+   int i;
+
+   while(!quit) {
+      /* Wait for cmd from vtpm_manager */
+      if((size =3D read(vbefd, buf, MAX_CMD)) < 0) {
+     if(errno =3D=3D EFAULT) {
+        if(opts.verbosity > 0) {
+           fprintf(stderr, "read() failed with error: %s, non-fatal\n",
strerror(errno));
+        }
+        continue;
+     }
+     fprintf(stderr,"Error reading from %s, (%s)\n", opts.vtpmbe,
strerror(errno));
+     return 1;
+      }
+      if(opts.verbosity > 0) {
+     printf("\nvtpm_manager req(%ld):", (long) size);
+     for(i =3D 0; i < size; ++i) {
+        printf(" %02X", buf[i]);
+     }
+     printf("\n");
+      }
+    =20
+      if(quit) {
+     break;
+      }
+
+      /* Forward the cmd to the tpm, exclude the dmi id */
+      if((wrote =3D write(tpmfd, buf + 4, size - 4)) !=3D size - 4) {
+     fprintf(stderr,"Error writing to %s, (%s)\n", opts.tpmdev,
strerror(errno));
+     return 1;
+      }
+
+      if(quit) {
+     break;
+      }
+
+      /* Wait for response from tpm */
+      if((size =3D read(tpmfd, buf + 4, MAX_CMD - 4)) < 0) {
+     fprintf(stderr,"Error reading from %s, (%s)\n", opts.tpmdev,
strerror(errno));
+     return 1;
+      }
+      if(opts.verbosity > 0) {
+     printf("tpm resp(%ld):", (long) size);
+     for(i =3D 0; i < size + 4; ++i) {
+        printf(" %02X", buf[i]);
+     }
+     printf("\n");
+      }
+
+      if(quit) {
+     break;
+      }
+    =20
+      /* Send response back to vtpm_manager */
+      if((wrote =3D write(vbefd, buf, size + 4)) !=3D size + 4) {
+     fprintf(stderr, "Error writing to %s, (%s)\n", opts.vtpmbe,
strerror(errno));
+     return 1;
+      }
+   }
+
+   return 0;
+
+}
+
+int main(int argc, char** argv)
+{
+   int rc;
+   int vbefd, tpmfd;
+   int c;
+   int fd =3D -1;
+   struct sigaction sig;
+   pid_t pid;
+
+   /* Do cmdline opts */
+   opterr =3D 0;
+
+   while ((c =3D getopt (argc, argv, "hfvb:t:")) !=3D -1)
+   {
+      switch (c)
+      {
+     case 'h':
+        usage(argv[0]);
+        return 0;
+     case 'f':
+        opts.daemon =3D 0;
+        break;
+     case 'v':
+        ++opts.verbosity;
+        break;
+     case 'b':
+        opts.vtpmbe =3D optarg;
+        break;
+     case 't':
+        opts.tpmdev =3D optarg;
+        break;
+     case '?':
+        if (optopt =3D=3D 'c')
+           fprintf (stderr, "Option -%c requires an argument.\n", optopt=
);
+        else if (isprint (optopt))
+           fprintf (stderr, "Unknown option `-%c'.\n", optopt);
+        else
+           fprintf (stderr,
+             "Unknown option character `\\x%x'.\n",
+             optopt);
+            usage(argv[0]);
+        return 1;
+     default:
+        return 1;
+      }
+   }
+
+   /* DAEMONIZE */
+   if(opts.daemon) {
+      pid =3D fork();
+      if(pid < 0) {
+     fprintf(stderr, "failed to daemonize! fork() failed : %s\n",
strerror(errno));
+     return 1;
+      }
+
+      if (pid > 0) {
+     return 0;
+      }
+   }
+
+
+   /* SIGNAL HANDLING */
+   sig.sa_handler =3D sighandler;
+   sigemptyset(&sig.sa_mask);
+   sig.sa_flags =3D 0;
+
+   sigaction(SIGINT, &sig, NULL);
+   sigaction(SIGQUIT, &sig, NULL);
+   sigaction(SIGTERM, &sig, NULL);
+
+   /* FAKE OUT THE HOTPLUG SYSTEM */
+   /* Whenever hotplug writes a message let it go to dev null */
+   if(remove(VTPM_RX_HP_FNAME) !=3D 0 && errno !=3D ENOENT) {
+      fprintf(stderr, "Unable to remove %s : %s\n", VTPM_RX_HP_FNAME,
strerror(errno));
+      return -1;
+   }
+   if(symlink(DEVNULL, VTPM_RX_HP_FNAME) !=3D 0) {
+      fprintf(stderr, "Unable to create symlink %s -> %s : %s\n",
VTPM_RX_HP_FNAME, DEVNULL, strerror(errno));
+   }
+
+   /* Whenever hotplug tries to read a response, always return success *=
/
+   if(remove(VTPM_TX_HP_FNAME) !=3D 0 && errno !=3D ENOENT) {
+      fprintf(stderr, "Unable to remove %s : %s\n", VTPM_TX_HP_FNAME,
strerror(errno));
+      return -1;
+   }
+   if((fd =3D open(VTPM_TX_HP_FNAME, O_CREAT | O_WRONLY, S_IRUSR |
S_IWUSR)) < 0) {
+      fprintf(stderr, "Unable to open %s for writing : %s\n",
VTPM_TX_HP_FNAME, strerror(errno));
+      return -1;
+   }
+   if(write(fd, TPM_SUCCESS_RESP, TPM_SUCCESS_RESPLEN) !=3D
TPM_SUCCESS_RESPLEN) {
+      fprintf(stderr, "Unable to write to %s : %s\n", VTPM_TX_HP_FNAME,
strerror(errno));
+      return -1;
+   }
+   close(fd);
+   /* HOTPLUG FAKE OUT DONE */
+
+   /* Open the backend and tpm device */
+   if((vbefd =3D open(opts.vtpmbe, O_RDWR)) < 0) {
+      fprintf(stderr, "Unable to open `%s', (%s)\n", opts.vtpmbe,
strerror(errno));
+      return 1;
+   }
+   if((tpmfd =3D open(opts.tpmdev, O_RDWR)) < 0) {
+      fprintf(stderr, "Unable to open `%s', (%s)\n", opts.tpmdev,
strerror(errno));
+      return 1;
+   }
+   if(opts.verbosity > 0) {
+      fprintf(stderr, "Connected to vtpm backend: %s\n", opts.vtpmbe);
+      fprintf(stderr, "Connected to tpm: %s\n", opts.tpmdev);
+   }
+
+   rc =3D main_loop(vbefd, tpmfd);
+
+   close(vbefd);
+   close(tpmfd);
+
+   remove(VTPM_RX_HP_FNAME);
+   remove(VTPM_TX_HP_FNAME);
+
+
+   return rc;
+
+
+}
diff --git a/tools/vtpm_manager/vtpmmgrtalk/Makefile
b/tools/vtpm_manager/vtpmmgrtalk/Makefile
--- /dev/null
+++ b/tools/vtpm_manager/vtpmmgrtalk/Makefile
@@ -0,0 +1,35 @@
+# Copyright (c) 2010-2012 United States Government, as represented by
+# the Secretary of Defense.  All rights reserved.
+#
+# THIS SOFTWARE AND ITS DOCUMENTATION ARE PROVIDED AS IS AND WITHOUT
+# ANY EXPRESS OR IMPLIED WARRANTIES WHATSOEVER. ALL WARRANTIES
+# INCLUDING, BUT NOT LIMITED TO, PERFORMANCE, MERCHANTABILITY, FITNESS
+# FOR A PARTICULAR  PURPOSE, AND NONINFRINGEMENT ARE HEREBY
+# DISCLAIMED. USERS ASSUME THE ENTIRE RISK AND LIABILITY OF USING THE
+# SOFTWARE.
+#
+
+XEN_ROOT =3D $(realpath ../../..)
+include ../Rules.mk
+
+BIN=3Dvtpmmgrtalk
+OBJS=3Dvtpmmgrtalk.o
+CFLAGS=3D-Wall -O2 -g
+CFLAGS +=3D -I../crypto
+CFLAGS +=3D -I../util
+CFLAGS +=3D -I../tcs
+CFLAGS +=3D -I../manager
+
+
+all: ${BIN}
+
+${BIN}: ${OBJS}
+    gcc -o $@ $<
+
+install: all
+    install -m 0755 ${BIN} $(DESTDIR)$(BINDIR)/$(BIN)
+
+.PHONY: mrproper
+mrproper: clean
+clean:
+    rm -f ${BIN} ${OBJS}
diff --git a/tools/vtpm_manager/vtpmmgrtalk/vtpmmgrtalk.c
b/tools/vtpm_manager/vtpmmgrtalk/vtpmmgrtalk.c
--- /dev/null
+++ b/tools/vtpm_manager/vtpmmgrtalk/vtpmmgrtalk.c
@@ -0,0 +1,105 @@
+/*
+ * Copyright (c) 2010-2012 United States Government, as represented by
+ * the Secretary of Defense.  All rights reserved.
+ *
+ * THIS SOFTWARE AND ITS DOCUMENTATION ARE PROVIDED AS IS AND WITHOUT
+ * ANY EXPRESS OR IMPLIED WARRANTIES WHATSOEVER. ALL WARRANTIES
+ * INCLUDING, BUT NOT LIMITED TO, PERFORMANCE, MERCHANTABILITY, FITNESS
+ * FOR A PARTICULAR  PURPOSE, AND NONINFRINGEMENT ARE HEREBY
+ * DISCLAIMED. USERS ASSUME THE ENTIRE RISK AND LIABILITY OF USING THE
+ * SOFTWARE.
+ */
+#include <unistd.h>
+#include <fcntl.h>
+#include <sys/file.h>
+#include <stdio.h>
+#include <errno.h>
+#include <string.h>
+#include <stdint.h>
+
+#include "../manager/vtpm_manager.h"
+
+int main(int argc, char** argv) {
+   int wfd, rfd;
+   uint8_t buf[COMMAND_BUFFER_SIZE];
+   ssize_t size;
+   int i, c;
+   int rc =3D 0;
+
+   const char* wfile =3D VTPM_RX_HP_FNAME;
+   const char* rfile =3D VTPM_TX_HP_FNAME;
+
+   /* Open for writing in non-blocking mode and exit if
+    * the manager is not waiting on the other side */
+   if((wfd =3D open(wfile, O_WRONLY | O_NONBLOCK)) < 0) {
+      fprintf(stderr, "Error opening %s for writing : %s\n",
wfile,strerror(errno));
+      return 1;
+   }
+   /* Set the pipe back to blocking mode */
+   fcntl(wfd, F_SETFL, 0);
+
+   /* Open the read pipe */
+   if((rfd =3D open(rfile, O_RDONLY)) < 0) {
+      close(wfd);
+      fprintf(stderr, "Error opening %s for reading : %s\n",
rfile,strerror(errno));
+      return 1;
+   }
+ =20
+   /*Grab the ASCII hex input from stdin and convert to binary */
+   for(i =3D 0; i < COMMAND_BUFFER_SIZE; ++i) {
+      c =3D scanf("%02hhX", buf + i);
+      if(c =3D=3D EOF) {
+     break;
+      } else if ( c !=3D 1) {
+     fprintf(stderr, "Malformed Input! Use ASCII hex!\n");
+     rc =3D 1;
+     goto quit;
+      }
+   }
+   size =3D i;
+
+   /* Send request to the manager only if a request was actually given *=
/
+   if(size > 0) {
+      /* Lock the pipes for reading/writing */
+      if(flock(wfd, LOCK_EX)) {
+     fprintf(stderr, "Unable to lock %s : %s\n", wfile, strerror(errno))=
;
+     rc =3D 1;
+     goto quit;
+      }
+      if(flock(rfd, LOCK_EX)) {
+     fprintf(stderr, "Unable to lock %s : %s\n", wfile, strerror(errno))=
;
+     rc =3D 1;
+     goto quit;
+      }
+
+      /* Write the binary data to the pipe */
+      if(write(wfd, buf, size) !=3D size) {
+     fprintf(stderr, "Error writing to %s : %s\n", wfile, strerror(errno=
));
+     rc =3D 1;
+     goto quit;
+      }
+
+      /* Read the response from the manager */
+      size =3D read(rfd, buf, COMMAND_BUFFER_SIZE);
+      if(size < 0) {
+     fprintf(stderr, "Error reading %s : %s\n", rfile, strerror(errno));=

+     rc =3D 1;
+     goto quit;
+      }
+      /* Output the hex */
+      for(i =3D 0; i < size; ++i) {
+     printf("%02X", buf[i]);
+      }
+      fprintf(stderr,"\n");
+
+      /* Unlock the pipes */
+      flock(rfd, LOCK_UN);
+      flock(wfd, LOCK_UN);
+   }
+
+   rc =3D 0;
+quit:
+   close(rfd);
+   close(wfd);
+   return rc;
+}



--------------ms030402000007090807080904
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIDyjCC
A8YwggMvoAMCAQICBD/xyf0wDQYJKoZIhvcNAQEFBQAwLzELMAkGA1UEBhMCVVMxDzANBgNV
BAoTBkpIVUFQTDEPMA0GA1UECxMGQklTRENBMB4XDTEwMDYxMTE4MjIwNloXDTEzMDYxMTE4
NTIwNlowZjELMAkGA1UEBhMCVVMxDzANBgNVBAoTBkpIVUFQTDEPMA0GA1UECxMGUGVvcGxl
MTUwFgYDVQQLEw9WUE5Hcm91cC1CSVNEQ0EwGwYDVQQDExRNYXR0aGV3IEUgRmlvcmF2YW50
ZTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAnpbwVSP6o1Nb5lcW7dd3yTo9iBJdi7qz
4nANOMFPK7JOy5npKN1iiousl28U/scUJES55gPwAWYJK3uVyQAsA4adgDKi5DoD1UHDQEwp
bY7iHLJeq0NPr4BqYNqnCFPbE6HC8zSJrr4qKn+gVUQT39SIFqdiIPJwZL8FYTRQ/zsCAwEA
AaOCAbYwggGyMAsGA1UdDwQEAwIHgDArBgNVHRAEJDAigA8yMDEwMDYxMTE4MjIwNlqBDzIw
MTIwNzE3MjI1MjA2WjAbBg0rBgEEAbMlCwMBAQEBBAoWCGZpb3JhbWUxMBsGDSsGAQQBsyUL
AwEBAQIEChIIMDAxMDQyNjEwWAYJYIZIAYb6ax4BBEsMSVRoZSBwcml2YXRlIGtleSBjb3Jy
ZXNwb25kaW5nIHRvIHRoaXMgY2VydGlmaWNhdGUgbWF5IGhhdmUgYmVlbiBleHBvcnRlZC4w
KAYDVR0RBCEwH4EdTWF0dGhldy5GaW9yYXZhbnRlQGpodWFwbC5lZHUwUgYDVR0fBEswSTBH
oEWgQ6RBMD8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJU0RD
QTEOMAwGA1UEAxMFQ1JMNTYwHwYDVR0jBBgwFoAUCDUpmxH52EU2CyWmF2EJMB1yqeswHQYD
VR0OBBYEFO6LYxg6r9wHZ+zdQtBHn1dZ/YTNMAkGA1UdEwQCMAAwGQYJKoZIhvZ9B0EABAww
ChsEVjcuMQMCBLAwDQYJKoZIhvcNAQEFBQADgYEAJO9HQh4YNChVLzuZqK5ARJARD8JoujGZ
fdo75quvg2jXFQe2sEjvLnxJZgm/pv8fdZakq48CWwjYHKuvIp7sDjTEsQfo+y7SpN/N2NvJ
WU5SqfK1VgYtNLRRoGJUB5Q1aZ+Dg95g3kqpyfpUMISJL8IKVLtJVfN4fggFVUYZ9wwxggGr
MIIBpwIBATA3MC8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJ
U0RDQQIEP/HJ/TAJBgUrDgMCGgUAoIHLMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ
KoZIhvcNAQkFMQ8XDTEyMDkxNzIxMTY1MVowIwYJKoZIhvcNAQkEMRYEFGWuQgd9cmNWDW4S
YBUOf4/vmoemMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAK
BggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI
KoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEgYBf4xs58Unzhu7iU+qLUoY78adlX8v0F1DQ
HWTubayhDSNA7ULP64vY7NLQIkReW2+gr5h7M2vwmRsP63LZ72TEaEKG2nf1fjtQI+cbmBMG
zlKFj6BubEeczjXPlXB+fLTKwvmLRNIi8Wa3J/EVvEaFEHAmm9qwBuEgxZfwEyQtdwAAAAAA
AA==
--------------ms030402000007090807080904--


--===============7207552152192457387==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============7207552152192457387==--


From xen-devel-bounces@lists.xen.org Mon Sep 17 21:21:31 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 21:21: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 1TDiki-0000Qh-P6; Mon, 17 Sep 2012 21:21:12 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <matthew.fioravante@jhuapl.edu>) id 1TDikh-0000Qb-FJ
	for xen-devel@lists.xensource.com; Mon, 17 Sep 2012 21:21:11 +0000
Received: from [85.158.143.99:13284] by server-3.bemta-4.messagelabs.com id
	CA/6E-08232-64497505; Mon, 17 Sep 2012 21:21:10 +0000
X-Env-Sender: matthew.fioravante@jhuapl.edu
X-Msg-Ref: server-4.tower-216.messagelabs.com!1347916868!25440821!1
X-Originating-IP: [128.244.251.36]
X-SpamReason: No, hits=0.0 required=7.0 tests=UNPARSEABLE_RELAY
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31092 invoked from network); 17 Sep 2012 21:21:09 -0000
Received: from pilot.jhuapl.edu (HELO jhuapl.edu) (128.244.251.36)
	by server-4.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 17 Sep 2012 21:21:09 -0000
Received: from ([128.244.207.89])
	by pilot.jhuapl.edu with ESMTP with TLS id 63GHCH1.153073999;
	Mon, 17 Sep 2012 17:21:03 -0400
Message-ID: <505793F4.40301@jhuapl.edu>
Date: Mon, 17 Sep 2012 17:19:48 -0400
From: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:14.0) Gecko/20120714 Thunderbird/14.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>, 
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
X-Enigmail-Version: 1.5a1pre
Subject: [Xen-devel] [PATCH vtpm_manager 2/2] Fixes to vtpm 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: multipart/mixed; boundary="===============2116482348316400441=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a cryptographically signed message in MIME format.

--===============2116482348316400441==
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms010201030809000204000104"

This is a cryptographically signed message in MIME format.

--------------ms010201030809000204000104
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

This patch fixes IO deadlocks in the vtpm hotplug scripts

Signed off by: Matthew Fioravante matthew.fioravante@jhuapl.edu


diff --git a/tools/hotplug/Linux/vtpm b/tools/hotplug/Linux/vtpm
--- a/tools/hotplug/Linux/vtpm
+++ b/tools/hotplug/Linux/vtpm
@@ -1,22 +1,18 @@
 #!/bin/bash
=20
+export PATH=3D$PATH:/usr/sbin:/sbin
+
 dir=3D$(dirname "$0")
 . "$dir/vtpm-hotplug-common.sh"
=20
-vtpm_fatal_error=3D0
-
 case "$command" in
   add)
     vtpm_create_instance
+    success
   ;;
   remove)
     vtpm_remove_instance
+    success
   ;;
 esac
=20
-if [ $vtpm_fatal_error -eq 0 ]; then
-    log debug "Successful vTPM operation '$command'."
-    success
-else
-    fatal "Error while executing vTPM operation '$command'."
-fi
diff --git a/tools/hotplug/Linux/vtpm-common.sh
b/tools/hotplug/Linux/vtpm-common.sh
--- a/tools/hotplug/Linux/vtpm-common.sh
+++ b/tools/hotplug/Linux/vtpm-common.sh
@@ -98,7 +98,7 @@ function vtpmdb_is_free_instancenum () {
         avail=3D0
     else
         instances=3D$(cat $VTPMDB |                \
-                   awk                          \
+                   gawk                          \
                    '{                            \
                        if (1 !=3D index($1,"#")) { \
                          printf("%s ",$2);       \
@@ -120,7 +120,7 @@ function vtpmdb_is_free_instancenum () {
 function vtpmdb_get_free_instancenum () {
     local ctr instances don found
     instances=3D$(cat $VTPMDB |                \
-               awk                          \
+               gawk                          \
                '{                            \
                    if (1 !=3D index($1,"#")) { \
                      printf("%s ",$2);       \
@@ -174,7 +174,7 @@ function vtpmdb_validate_entry () {
     inst=3D$2
=20
     res=3D$(cat $VTPMDB |            \
-         awk -vvmname=3D$vmname     \
+         gawk -vvmname=3D$vmname     \
               -vinst=3D$inst         \
          '{                        \
              if ( 1 =3D=3D index($1,"#")) {\
@@ -209,7 +209,7 @@ function vtpmdb_remove_entry () {
     VTPMDB_TMP=3D"$VTPMDB".tmp
=20
     $(cat $VTPMDB |            \
-     awk -vvmname=3D$vmname     \
+     gawk -vvmname=3D$vmname     \
      '{                        \
         if ( $1 !=3D vmname ) {  \
           print $0;            \
@@ -276,12 +276,10 @@ function vtpm_create_instance () {
=20
         vtpm_create $instance
=20
-        if [ $vtpm_fatal_error -eq 0 ]; then
-            if [ "$uuid" !=3D "" ]; then
-                vtpmdb_add_instance $uuid $instance
-            else
-                vtpmdb_add_instance $domname $instance
-            fi
+        if [ "$uuid" !=3D "" ]; then
+            vtpmdb_add_instance $uuid $instance
+        else
+            vtpmdb_add_instance $domname $instance
         fi
     else
         if [ "$reason" =3D=3D "resume" ]; then
@@ -290,7 +288,6 @@ function vtpm_create_instance () {
             vtpm_start $instance
         fi
     fi
-
     release_lock vtpmdb
=20
     xenstore_write $XENBUS_PATH/instance $instance
@@ -322,8 +319,8 @@ function vtpm_remove_instance () {
     if [ "$instance" !=3D "0" ]; then
         vtpm_suspend $instance
     fi
-
     release_lock vtpmdb
+
 }
=20
=20
@@ -350,13 +347,13 @@ function vtpm_delete_instance () {
 function vtpm_isLocalAddress() {
     local addr res
     addr=3D$(ping $1 -c 1 |  \
-           awk '{ print substr($3,2,length($3)-2); exit }')
+           gawk '{ print substr($3,2,length($3)-2); exit }')
     if [ "$addr" =3D=3D "" ]; then
         echo "-1"
         return
     fi
     res=3D$(ifconfig | grep "inet addr" |  \
-         awk -vaddr=3D$addr               \
+         gawk -vaddr=3D$addr               \
          '{                              \
             if ( addr =3D=3D substr($2, 6)) {\
               print "1";                 \
diff --git a/tools/hotplug/Linux/vtpm-delete
b/tools/hotplug/Linux/vtpm-delete
--- a/tools/hotplug/Linux/vtpm-delete
+++ b/tools/hotplug/Linux/vtpm-delete
@@ -5,6 +5,8 @@
 # or
 # vtpm-delete --vmname <vm name>
=20
+export PATH=3D$PATH:/usr/sbin:/sbin
+
 dir=3D$(dirname "$0")
 . "$dir/vtpm-common.sh"
=20
diff --git a/tools/hotplug/Linux/vtpm-impl b/tools/hotplug/Linux/vtpm-imp=
l
--- a/tools/hotplug/Linux/vtpm-impl
+++ b/tools/hotplug/Linux/vtpm-impl
@@ -32,14 +32,16 @@
 # OF THE POSSIBILITY OF SUCH DAMAGE.
 # =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
=20
-#            |        SRC        |    TAG  |      CMD SIZE     |      =20
ORD       |mtype|strt
-TPM_CMD_OPEN=3D\\x00\\x00\\x00\\x00\\x01\\xc1\\x00\\x00\\x00\\x11\\x01\\=
x00\\x00\\x01\\x01\\x01
-TPM_CMD_RESM=3D\\x00\\x00\\x00\\x00\\x01\\xc1\\x00\\x00\\x00\\x11\\x01\\=
x00\\x00\\x01\\x01\\x02
-TPM_CMD_CLOS=3D\\x00\\x00\\x00\\x00\\x01\\xc1\\x00\\x00\\x00\\x0e\\x01\\=
x00\\x00\\x02
-TPM_CMD_DELE=3D\\x00\\x00\\x00\\x00\\x01\\xc1\\x00\\x00\\x00\\x0e\\x01\\=
x00\\x00\\x03
+export PATH=3D$PATH:/usr/sbin:/sbin
=20
-TPM_TYPE_PVM=3D\\x01
-TPM_TYPE_HVM=3D\\x02
+#             | SRC  |TAG| CMD SZ|| ORD  |mtype|strt
+TPM_CMD_OPEN=3D"0000000001C100000011010000010101"
+TPM_CMD_RESM=3D"0000000001C100000011010000010102"
+TPM_CMD_CLOS=3D"0000000001C10000000E01000002"
+TPM_CMD_DELE=3D"0000000001C10000000E01000003"
+
+TPM_TYPE_PVM=3D01
+TPM_TYPE_HVM=3D02
=20
 TPM_SUCCESS=3D00000000
=20
@@ -70,24 +72,19 @@ function vtpm_manager_cmd() {
  local inst=3D$2;
  local inst_bin=3D$(hex32_to_bin $inst);
=20
- claim_lock vtpm_mgr
-
- #send cmd to vtpm_manager
- printf "$cmd$inst_bin" > $TX_VTPM_MANAGER
-
- #recv response
- set +e
- local resp_hex=3D`dd skip=3D10 bs=3D1 count=3D4 if=3D$RX_VTPM_MANAGER 2=
>
/dev/null | xxd -ps`
- set -e
+ local resp_hex
+ #send cmd to vtpm_manager and get response
+ if ! resp_hex=3D`echo "$cmd$(str_to_hex32 $inst)" | vtpmmgrtalk `; then=

+   release_lock vtpmdb
+   fatal "Error communicating with vTPM Manager"
+ fi
=20
- release_lock vtpm_mgr
+ resp_hex=3D`echo $resp_hex | cut -b 21-`
=20
  #return whether the command was successful
- if [ $resp_hex -ne $TPM_SUCCESS ]; then
-   vtpm_fatal_error=3D1
-   false
-  else
-   true
+ if [ "$resp_hex" !=3D "$TPM_SUCCESS" ]; then
+   release_lock vtpmdb
+   fatal "vTPM Manager returned failure code $resp_hex"
  fi
 }
=20
@@ -142,13 +139,8 @@ function vtpm_suspend() {
=20
 function vtpm_delete() {
  local inst=3D$1
- if $(vtpm_manager_cmd $TPM_CMD_DELE $inst); then
-   rm -f /var/vtpm/vtpm_dm_$1.data
-   true
- else
-   vtpm_fatal_error=3D1
-   false
- fi
+ $(vtpm_manager_cmd $TPM_CMD_DELE $inst)
+ rm -f /var/vtpm/vtpm_dm_$1.data
 }
=20
 # Perform a migration step. This function differentiates between migrati=
on
diff --git a/tools/python/xen/xend/server/tpmif.py
b/tools/python/xen/xend/server/tpmif.py
--- a/tools/python/xen/xend/server/tpmif.py
+++ b/tools/python/xen/xend/server/tpmif.py
@@ -44,6 +44,22 @@ class TPMifController(DevController):
         DevController.__init__(self, vm)
=20
=20
+    def createDevice(self, config):
+        #Disable hotplug scripts if backend is not dom0
+        import xen.xend.XendDomain
+        xd =3D xen.xend.XendDomain.instance()
+        backdom_name =3D config.get('backend')
+        if backdom_name is None:
+            backdom =3D xen.xend.XendDomain.DOM0_ID
+        else:
+            bd =3D xd.domain_lookup_nr(backdom_name)
+            backdom =3D bd.getDomid()
+
+    if backdom !=3D xen.xend.XendDomain.DOM0_ID:
+       self.hotplug =3D False
+
+        return DevController.createDevice(self, config)
+
     def getDeviceDetails(self, config):
         """@see DevController.getDeviceDetails"""
=20




--------------ms010201030809000204000104
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIDyjCC
A8YwggMvoAMCAQICBD/xyf0wDQYJKoZIhvcNAQEFBQAwLzELMAkGA1UEBhMCVVMxDzANBgNV
BAoTBkpIVUFQTDEPMA0GA1UECxMGQklTRENBMB4XDTEwMDYxMTE4MjIwNloXDTEzMDYxMTE4
NTIwNlowZjELMAkGA1UEBhMCVVMxDzANBgNVBAoTBkpIVUFQTDEPMA0GA1UECxMGUGVvcGxl
MTUwFgYDVQQLEw9WUE5Hcm91cC1CSVNEQ0EwGwYDVQQDExRNYXR0aGV3IEUgRmlvcmF2YW50
ZTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAnpbwVSP6o1Nb5lcW7dd3yTo9iBJdi7qz
4nANOMFPK7JOy5npKN1iiousl28U/scUJES55gPwAWYJK3uVyQAsA4adgDKi5DoD1UHDQEwp
bY7iHLJeq0NPr4BqYNqnCFPbE6HC8zSJrr4qKn+gVUQT39SIFqdiIPJwZL8FYTRQ/zsCAwEA
AaOCAbYwggGyMAsGA1UdDwQEAwIHgDArBgNVHRAEJDAigA8yMDEwMDYxMTE4MjIwNlqBDzIw
MTIwNzE3MjI1MjA2WjAbBg0rBgEEAbMlCwMBAQEBBAoWCGZpb3JhbWUxMBsGDSsGAQQBsyUL
AwEBAQIEChIIMDAxMDQyNjEwWAYJYIZIAYb6ax4BBEsMSVRoZSBwcml2YXRlIGtleSBjb3Jy
ZXNwb25kaW5nIHRvIHRoaXMgY2VydGlmaWNhdGUgbWF5IGhhdmUgYmVlbiBleHBvcnRlZC4w
KAYDVR0RBCEwH4EdTWF0dGhldy5GaW9yYXZhbnRlQGpodWFwbC5lZHUwUgYDVR0fBEswSTBH
oEWgQ6RBMD8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJU0RD
QTEOMAwGA1UEAxMFQ1JMNTYwHwYDVR0jBBgwFoAUCDUpmxH52EU2CyWmF2EJMB1yqeswHQYD
VR0OBBYEFO6LYxg6r9wHZ+zdQtBHn1dZ/YTNMAkGA1UdEwQCMAAwGQYJKoZIhvZ9B0EABAww
ChsEVjcuMQMCBLAwDQYJKoZIhvcNAQEFBQADgYEAJO9HQh4YNChVLzuZqK5ARJARD8JoujGZ
fdo75quvg2jXFQe2sEjvLnxJZgm/pv8fdZakq48CWwjYHKuvIp7sDjTEsQfo+y7SpN/N2NvJ
WU5SqfK1VgYtNLRRoGJUB5Q1aZ+Dg95g3kqpyfpUMISJL8IKVLtJVfN4fggFVUYZ9wwxggGr
MIIBpwIBATA3MC8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJ
U0RDQQIEP/HJ/TAJBgUrDgMCGgUAoIHLMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ
KoZIhvcNAQkFMQ8XDTEyMDkxNzIxMTk0OFowIwYJKoZIhvcNAQkEMRYEFEiI92OoqoMbnwli
7ye/HVuYwcrYMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAK
BggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI
KoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEgYCHbn22opsgN8e5dPQjcuADsn9KAX9FbZy+
FdksgvxBFlJGsjIj5KO+E9a3wNpDHy5kkMFsLxU1MKE7LscRbSQyl37qofj+OfubdeXjJc52
DbGGMYw9bIlfP6LuKJTBpnZSZCqjb5DO+UG9zyBv9wRIFjrSMn0Y1YDxGNYGRAw4JwAAAAAA
AA==
--------------ms010201030809000204000104--


--===============2116482348316400441==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============2116482348316400441==--


From xen-devel-bounces@lists.xen.org Mon Sep 17 21:21:31 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 21:21: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 1TDiki-0000Qh-P6; Mon, 17 Sep 2012 21:21:12 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <matthew.fioravante@jhuapl.edu>) id 1TDikh-0000Qb-FJ
	for xen-devel@lists.xensource.com; Mon, 17 Sep 2012 21:21:11 +0000
Received: from [85.158.143.99:13284] by server-3.bemta-4.messagelabs.com id
	CA/6E-08232-64497505; Mon, 17 Sep 2012 21:21:10 +0000
X-Env-Sender: matthew.fioravante@jhuapl.edu
X-Msg-Ref: server-4.tower-216.messagelabs.com!1347916868!25440821!1
X-Originating-IP: [128.244.251.36]
X-SpamReason: No, hits=0.0 required=7.0 tests=UNPARSEABLE_RELAY
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31092 invoked from network); 17 Sep 2012 21:21:09 -0000
Received: from pilot.jhuapl.edu (HELO jhuapl.edu) (128.244.251.36)
	by server-4.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 17 Sep 2012 21:21:09 -0000
Received: from ([128.244.207.89])
	by pilot.jhuapl.edu with ESMTP with TLS id 63GHCH1.153073999;
	Mon, 17 Sep 2012 17:21:03 -0400
Message-ID: <505793F4.40301@jhuapl.edu>
Date: Mon, 17 Sep 2012 17:19:48 -0400
From: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:14.0) Gecko/20120714 Thunderbird/14.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>, 
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
X-Enigmail-Version: 1.5a1pre
Subject: [Xen-devel] [PATCH vtpm_manager 2/2] Fixes to vtpm 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: multipart/mixed; boundary="===============2116482348316400441=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a cryptographically signed message in MIME format.

--===============2116482348316400441==
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms010201030809000204000104"

This is a cryptographically signed message in MIME format.

--------------ms010201030809000204000104
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

This patch fixes IO deadlocks in the vtpm hotplug scripts

Signed off by: Matthew Fioravante matthew.fioravante@jhuapl.edu


diff --git a/tools/hotplug/Linux/vtpm b/tools/hotplug/Linux/vtpm
--- a/tools/hotplug/Linux/vtpm
+++ b/tools/hotplug/Linux/vtpm
@@ -1,22 +1,18 @@
 #!/bin/bash
=20
+export PATH=3D$PATH:/usr/sbin:/sbin
+
 dir=3D$(dirname "$0")
 . "$dir/vtpm-hotplug-common.sh"
=20
-vtpm_fatal_error=3D0
-
 case "$command" in
   add)
     vtpm_create_instance
+    success
   ;;
   remove)
     vtpm_remove_instance
+    success
   ;;
 esac
=20
-if [ $vtpm_fatal_error -eq 0 ]; then
-    log debug "Successful vTPM operation '$command'."
-    success
-else
-    fatal "Error while executing vTPM operation '$command'."
-fi
diff --git a/tools/hotplug/Linux/vtpm-common.sh
b/tools/hotplug/Linux/vtpm-common.sh
--- a/tools/hotplug/Linux/vtpm-common.sh
+++ b/tools/hotplug/Linux/vtpm-common.sh
@@ -98,7 +98,7 @@ function vtpmdb_is_free_instancenum () {
         avail=3D0
     else
         instances=3D$(cat $VTPMDB |                \
-                   awk                          \
+                   gawk                          \
                    '{                            \
                        if (1 !=3D index($1,"#")) { \
                          printf("%s ",$2);       \
@@ -120,7 +120,7 @@ function vtpmdb_is_free_instancenum () {
 function vtpmdb_get_free_instancenum () {
     local ctr instances don found
     instances=3D$(cat $VTPMDB |                \
-               awk                          \
+               gawk                          \
                '{                            \
                    if (1 !=3D index($1,"#")) { \
                      printf("%s ",$2);       \
@@ -174,7 +174,7 @@ function vtpmdb_validate_entry () {
     inst=3D$2
=20
     res=3D$(cat $VTPMDB |            \
-         awk -vvmname=3D$vmname     \
+         gawk -vvmname=3D$vmname     \
               -vinst=3D$inst         \
          '{                        \
              if ( 1 =3D=3D index($1,"#")) {\
@@ -209,7 +209,7 @@ function vtpmdb_remove_entry () {
     VTPMDB_TMP=3D"$VTPMDB".tmp
=20
     $(cat $VTPMDB |            \
-     awk -vvmname=3D$vmname     \
+     gawk -vvmname=3D$vmname     \
      '{                        \
         if ( $1 !=3D vmname ) {  \
           print $0;            \
@@ -276,12 +276,10 @@ function vtpm_create_instance () {
=20
         vtpm_create $instance
=20
-        if [ $vtpm_fatal_error -eq 0 ]; then
-            if [ "$uuid" !=3D "" ]; then
-                vtpmdb_add_instance $uuid $instance
-            else
-                vtpmdb_add_instance $domname $instance
-            fi
+        if [ "$uuid" !=3D "" ]; then
+            vtpmdb_add_instance $uuid $instance
+        else
+            vtpmdb_add_instance $domname $instance
         fi
     else
         if [ "$reason" =3D=3D "resume" ]; then
@@ -290,7 +288,6 @@ function vtpm_create_instance () {
             vtpm_start $instance
         fi
     fi
-
     release_lock vtpmdb
=20
     xenstore_write $XENBUS_PATH/instance $instance
@@ -322,8 +319,8 @@ function vtpm_remove_instance () {
     if [ "$instance" !=3D "0" ]; then
         vtpm_suspend $instance
     fi
-
     release_lock vtpmdb
+
 }
=20
=20
@@ -350,13 +347,13 @@ function vtpm_delete_instance () {
 function vtpm_isLocalAddress() {
     local addr res
     addr=3D$(ping $1 -c 1 |  \
-           awk '{ print substr($3,2,length($3)-2); exit }')
+           gawk '{ print substr($3,2,length($3)-2); exit }')
     if [ "$addr" =3D=3D "" ]; then
         echo "-1"
         return
     fi
     res=3D$(ifconfig | grep "inet addr" |  \
-         awk -vaddr=3D$addr               \
+         gawk -vaddr=3D$addr               \
          '{                              \
             if ( addr =3D=3D substr($2, 6)) {\
               print "1";                 \
diff --git a/tools/hotplug/Linux/vtpm-delete
b/tools/hotplug/Linux/vtpm-delete
--- a/tools/hotplug/Linux/vtpm-delete
+++ b/tools/hotplug/Linux/vtpm-delete
@@ -5,6 +5,8 @@
 # or
 # vtpm-delete --vmname <vm name>
=20
+export PATH=3D$PATH:/usr/sbin:/sbin
+
 dir=3D$(dirname "$0")
 . "$dir/vtpm-common.sh"
=20
diff --git a/tools/hotplug/Linux/vtpm-impl b/tools/hotplug/Linux/vtpm-imp=
l
--- a/tools/hotplug/Linux/vtpm-impl
+++ b/tools/hotplug/Linux/vtpm-impl
@@ -32,14 +32,16 @@
 # OF THE POSSIBILITY OF SUCH DAMAGE.
 # =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
=20
-#            |        SRC        |    TAG  |      CMD SIZE     |      =20
ORD       |mtype|strt
-TPM_CMD_OPEN=3D\\x00\\x00\\x00\\x00\\x01\\xc1\\x00\\x00\\x00\\x11\\x01\\=
x00\\x00\\x01\\x01\\x01
-TPM_CMD_RESM=3D\\x00\\x00\\x00\\x00\\x01\\xc1\\x00\\x00\\x00\\x11\\x01\\=
x00\\x00\\x01\\x01\\x02
-TPM_CMD_CLOS=3D\\x00\\x00\\x00\\x00\\x01\\xc1\\x00\\x00\\x00\\x0e\\x01\\=
x00\\x00\\x02
-TPM_CMD_DELE=3D\\x00\\x00\\x00\\x00\\x01\\xc1\\x00\\x00\\x00\\x0e\\x01\\=
x00\\x00\\x03
+export PATH=3D$PATH:/usr/sbin:/sbin
=20
-TPM_TYPE_PVM=3D\\x01
-TPM_TYPE_HVM=3D\\x02
+#             | SRC  |TAG| CMD SZ|| ORD  |mtype|strt
+TPM_CMD_OPEN=3D"0000000001C100000011010000010101"
+TPM_CMD_RESM=3D"0000000001C100000011010000010102"
+TPM_CMD_CLOS=3D"0000000001C10000000E01000002"
+TPM_CMD_DELE=3D"0000000001C10000000E01000003"
+
+TPM_TYPE_PVM=3D01
+TPM_TYPE_HVM=3D02
=20
 TPM_SUCCESS=3D00000000
=20
@@ -70,24 +72,19 @@ function vtpm_manager_cmd() {
  local inst=3D$2;
  local inst_bin=3D$(hex32_to_bin $inst);
=20
- claim_lock vtpm_mgr
-
- #send cmd to vtpm_manager
- printf "$cmd$inst_bin" > $TX_VTPM_MANAGER
-
- #recv response
- set +e
- local resp_hex=3D`dd skip=3D10 bs=3D1 count=3D4 if=3D$RX_VTPM_MANAGER 2=
>
/dev/null | xxd -ps`
- set -e
+ local resp_hex
+ #send cmd to vtpm_manager and get response
+ if ! resp_hex=3D`echo "$cmd$(str_to_hex32 $inst)" | vtpmmgrtalk `; then=

+   release_lock vtpmdb
+   fatal "Error communicating with vTPM Manager"
+ fi
=20
- release_lock vtpm_mgr
+ resp_hex=3D`echo $resp_hex | cut -b 21-`
=20
  #return whether the command was successful
- if [ $resp_hex -ne $TPM_SUCCESS ]; then
-   vtpm_fatal_error=3D1
-   false
-  else
-   true
+ if [ "$resp_hex" !=3D "$TPM_SUCCESS" ]; then
+   release_lock vtpmdb
+   fatal "vTPM Manager returned failure code $resp_hex"
  fi
 }
=20
@@ -142,13 +139,8 @@ function vtpm_suspend() {
=20
 function vtpm_delete() {
  local inst=3D$1
- if $(vtpm_manager_cmd $TPM_CMD_DELE $inst); then
-   rm -f /var/vtpm/vtpm_dm_$1.data
-   true
- else
-   vtpm_fatal_error=3D1
-   false
- fi
+ $(vtpm_manager_cmd $TPM_CMD_DELE $inst)
+ rm -f /var/vtpm/vtpm_dm_$1.data
 }
=20
 # Perform a migration step. This function differentiates between migrati=
on
diff --git a/tools/python/xen/xend/server/tpmif.py
b/tools/python/xen/xend/server/tpmif.py
--- a/tools/python/xen/xend/server/tpmif.py
+++ b/tools/python/xen/xend/server/tpmif.py
@@ -44,6 +44,22 @@ class TPMifController(DevController):
         DevController.__init__(self, vm)
=20
=20
+    def createDevice(self, config):
+        #Disable hotplug scripts if backend is not dom0
+        import xen.xend.XendDomain
+        xd =3D xen.xend.XendDomain.instance()
+        backdom_name =3D config.get('backend')
+        if backdom_name is None:
+            backdom =3D xen.xend.XendDomain.DOM0_ID
+        else:
+            bd =3D xd.domain_lookup_nr(backdom_name)
+            backdom =3D bd.getDomid()
+
+    if backdom !=3D xen.xend.XendDomain.DOM0_ID:
+       self.hotplug =3D False
+
+        return DevController.createDevice(self, config)
+
     def getDeviceDetails(self, config):
         """@see DevController.getDeviceDetails"""
=20




--------------ms010201030809000204000104
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIDyjCC
A8YwggMvoAMCAQICBD/xyf0wDQYJKoZIhvcNAQEFBQAwLzELMAkGA1UEBhMCVVMxDzANBgNV
BAoTBkpIVUFQTDEPMA0GA1UECxMGQklTRENBMB4XDTEwMDYxMTE4MjIwNloXDTEzMDYxMTE4
NTIwNlowZjELMAkGA1UEBhMCVVMxDzANBgNVBAoTBkpIVUFQTDEPMA0GA1UECxMGUGVvcGxl
MTUwFgYDVQQLEw9WUE5Hcm91cC1CSVNEQ0EwGwYDVQQDExRNYXR0aGV3IEUgRmlvcmF2YW50
ZTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAnpbwVSP6o1Nb5lcW7dd3yTo9iBJdi7qz
4nANOMFPK7JOy5npKN1iiousl28U/scUJES55gPwAWYJK3uVyQAsA4adgDKi5DoD1UHDQEwp
bY7iHLJeq0NPr4BqYNqnCFPbE6HC8zSJrr4qKn+gVUQT39SIFqdiIPJwZL8FYTRQ/zsCAwEA
AaOCAbYwggGyMAsGA1UdDwQEAwIHgDArBgNVHRAEJDAigA8yMDEwMDYxMTE4MjIwNlqBDzIw
MTIwNzE3MjI1MjA2WjAbBg0rBgEEAbMlCwMBAQEBBAoWCGZpb3JhbWUxMBsGDSsGAQQBsyUL
AwEBAQIEChIIMDAxMDQyNjEwWAYJYIZIAYb6ax4BBEsMSVRoZSBwcml2YXRlIGtleSBjb3Jy
ZXNwb25kaW5nIHRvIHRoaXMgY2VydGlmaWNhdGUgbWF5IGhhdmUgYmVlbiBleHBvcnRlZC4w
KAYDVR0RBCEwH4EdTWF0dGhldy5GaW9yYXZhbnRlQGpodWFwbC5lZHUwUgYDVR0fBEswSTBH
oEWgQ6RBMD8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJU0RD
QTEOMAwGA1UEAxMFQ1JMNTYwHwYDVR0jBBgwFoAUCDUpmxH52EU2CyWmF2EJMB1yqeswHQYD
VR0OBBYEFO6LYxg6r9wHZ+zdQtBHn1dZ/YTNMAkGA1UdEwQCMAAwGQYJKoZIhvZ9B0EABAww
ChsEVjcuMQMCBLAwDQYJKoZIhvcNAQEFBQADgYEAJO9HQh4YNChVLzuZqK5ARJARD8JoujGZ
fdo75quvg2jXFQe2sEjvLnxJZgm/pv8fdZakq48CWwjYHKuvIp7sDjTEsQfo+y7SpN/N2NvJ
WU5SqfK1VgYtNLRRoGJUB5Q1aZ+Dg95g3kqpyfpUMISJL8IKVLtJVfN4fggFVUYZ9wwxggGr
MIIBpwIBATA3MC8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJ
U0RDQQIEP/HJ/TAJBgUrDgMCGgUAoIHLMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ
KoZIhvcNAQkFMQ8XDTEyMDkxNzIxMTk0OFowIwYJKoZIhvcNAQkEMRYEFEiI92OoqoMbnwli
7ye/HVuYwcrYMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAK
BggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI
KoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEgYCHbn22opsgN8e5dPQjcuADsn9KAX9FbZy+
FdksgvxBFlJGsjIj5KO+E9a3wNpDHy5kkMFsLxU1MKE7LscRbSQyl37qofj+OfubdeXjJc52
DbGGMYw9bIlfP6LuKJTBpnZSZCqjb5DO+UG9zyBv9wRIFjrSMn0Y1YDxGNYGRAw4JwAAAAAA
AA==
--------------ms010201030809000204000104--


--===============2116482348316400441==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============2116482348316400441==--


From xen-devel-bounces@lists.xen.org Mon Sep 17 21:30:48 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 21:30:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDitd-0000dZ-QM; Mon, 17 Sep 2012 21:30:25 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dan.magenheimer@oracle.com>) id 1TDitc-0000dU-PR
	for xen-devel@lists.xen.org; Mon, 17 Sep 2012 21:30:25 +0000
X-Env-Sender: dan.magenheimer@oracle.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1347917416!4402879!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDc1NTA4Mg==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27385 invoked from network); 17 Sep 2012 21:30:18 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-15.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 17 Sep 2012 21:30:18 -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 q8HLUDZN006977
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 17 Sep 2012 21:30:14 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
	q8HLUDUn010152
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 17 Sep 2012 21:30:13 GMT
Received: from abhmt116.oracle.com (abhmt116.oracle.com [141.146.116.68])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q8HLUC6N022834; Mon, 17 Sep 2012 16:30:12 -0500
MIME-Version: 1.0
Message-ID: <2c017aa7-5a0a-4c9e-96ea-53abb9fa45c1@default>
Date: Mon, 17 Sep 2012 14:30:08 -0700 (PDT)
From: Dan Magenheimer <dan.magenheimer@oracle.com>
To: Daniel De Graaf <dgdegra@tycho.nsa.gov>, xen-devel@lists.xen.org
References: <<1347895425-17959-1-git-send-email-dgdegra@tycho.nsa.gov>>
	<<1347895425-17959-23-git-send-email-dgdegra@tycho.nsa.gov>>
In-Reply-To: <<1347895425-17959-23-git-send-email-dgdegra@tycho.nsa.gov>>
X-Priority: 3
X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.7  (607090) [OL
	12.0.6661.5003 (x86)]
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: Dan Magenheimer <dan.magenheimer@oracle.com>, keir@xen.org
Subject: Re: [Xen-devel] [PATCH 22/23] tmem: add XSM hooks
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


> From: Daniel De Graaf [mailto:dgdegra@tycho.nsa.gov]
> Sent: Monday, September 17, 2012 9:24 AM
> To: xen-devel@lists.xen.org
> Cc: dgdegra@tycho.nsa.gov; keir@xen.org; Dan Magenheimer
> Subject: [PATCH 22/23] tmem: add XSM hooks
> 
> This adds a pair of XSM hooks for tmem operations: xsm_tmem_op which
> controls any use of tmem, and xsm_tmem_control which allows use of the
> TMEM_CONTROL operations. By default, all domains can use tmem while only
> IS_PRIV domains can use control operations.
> 
> Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
> Cc: Dan Magenheimer <dan.magenheimer@oracle.com>

Bearing in mind that I am not very familiar with the XSM code,
this patch looks sane to me.

Acked-by: Dan Magenheimer <dan.magenheimer@oracle.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 17 21:30:48 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 21:30:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDitd-0000dZ-QM; Mon, 17 Sep 2012 21:30:25 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dan.magenheimer@oracle.com>) id 1TDitc-0000dU-PR
	for xen-devel@lists.xen.org; Mon, 17 Sep 2012 21:30:25 +0000
X-Env-Sender: dan.magenheimer@oracle.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1347917416!4402879!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDc1NTA4Mg==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27385 invoked from network); 17 Sep 2012 21:30:18 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-15.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 17 Sep 2012 21:30:18 -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 q8HLUDZN006977
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 17 Sep 2012 21:30:14 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
	q8HLUDUn010152
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 17 Sep 2012 21:30:13 GMT
Received: from abhmt116.oracle.com (abhmt116.oracle.com [141.146.116.68])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q8HLUC6N022834; Mon, 17 Sep 2012 16:30:12 -0500
MIME-Version: 1.0
Message-ID: <2c017aa7-5a0a-4c9e-96ea-53abb9fa45c1@default>
Date: Mon, 17 Sep 2012 14:30:08 -0700 (PDT)
From: Dan Magenheimer <dan.magenheimer@oracle.com>
To: Daniel De Graaf <dgdegra@tycho.nsa.gov>, xen-devel@lists.xen.org
References: <<1347895425-17959-1-git-send-email-dgdegra@tycho.nsa.gov>>
	<<1347895425-17959-23-git-send-email-dgdegra@tycho.nsa.gov>>
In-Reply-To: <<1347895425-17959-23-git-send-email-dgdegra@tycho.nsa.gov>>
X-Priority: 3
X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.7  (607090) [OL
	12.0.6661.5003 (x86)]
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: Dan Magenheimer <dan.magenheimer@oracle.com>, keir@xen.org
Subject: Re: [Xen-devel] [PATCH 22/23] tmem: add XSM hooks
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


> From: Daniel De Graaf [mailto:dgdegra@tycho.nsa.gov]
> Sent: Monday, September 17, 2012 9:24 AM
> To: xen-devel@lists.xen.org
> Cc: dgdegra@tycho.nsa.gov; keir@xen.org; Dan Magenheimer
> Subject: [PATCH 22/23] tmem: add XSM hooks
> 
> This adds a pair of XSM hooks for tmem operations: xsm_tmem_op which
> controls any use of tmem, and xsm_tmem_control which allows use of the
> TMEM_CONTROL operations. By default, all domains can use tmem while only
> IS_PRIV domains can use control operations.
> 
> Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
> Cc: Dan Magenheimer <dan.magenheimer@oracle.com>

Bearing in mind that I am not very familiar with the XSM code,
this patch looks sane to me.

Acked-by: Dan Magenheimer <dan.magenheimer@oracle.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 17 21:49:56 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 21:49:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDjCE-0000pX-Js; Mon, 17 Sep 2012 21:49:38 +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 1TDjCC-0000pS-Tt
	for xen-devel@lists.xensource.com; Mon, 17 Sep 2012 21:49:37 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1347918570!10273282!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDk2NDU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15507 invoked from network); 17 Sep 2012 21:49:30 -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;
	17 Sep 2012 21:49:30 -0000
X-IronPort-AV: E=Sophos;i="4.80,438,1344211200"; d="scan'208";a="14591182"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Sep 2012 21:49: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.279.1; Mon, 17 Sep 2012 22:49: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 1TDjC5-00062W-5O;
	Mon, 17 Sep 2012 21:49:29 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1TDjC4-0007vH-RK;
	Mon, 17 Sep 2012 22:49:28 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-13799-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Mon, 17 Sep 2012 22:49:28 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13799: 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 13799 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13799/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore            fail   like 13791
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail like 13791
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail like 13791

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  3bf63fcfacd1
baseline version:
 xen                  12fa949b9060

------------------------------------------------------------
People who touched revisions under test:
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Keir Fraser <keir@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-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-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-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-amd64-amd64-xl-win                                      fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=xen-unstable
+ revision=3bf63fcfacd1
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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 3bf63fcfacd1
+ branch=xen-unstable
+ revision=3bf63fcfacd1
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-unstable
+ '[' xxen = xlinux ']'
+ linuxbranch=linux
+ : master
+ : tested/2.6.39.x
+ . ap-common
++ : xen@xenbits.xensource.com
++ : http://xenbits.xen.org/hg/staging/xen-unstable.hg
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : xen@xenbits.xensource.com:git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.xen-unstable
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-unstable.git
++ : daily-cron.xen-unstable
+ TREE_LINUX=xen@xenbits.xensource.com:git/linux-pvops.git
+ TREE_QEMU_UPSTREAM=xen@xenbits.xensource.com:git/qemu-upstream-unstable.git
+ info_linux_tree xen-unstable
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/xen-unstable.hg
+ hg push -r 3bf63fcfacd1 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 21 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 Mon Sep 17 21:49:56 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 21:49:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDjCE-0000pX-Js; Mon, 17 Sep 2012 21:49:38 +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 1TDjCC-0000pS-Tt
	for xen-devel@lists.xensource.com; Mon, 17 Sep 2012 21:49:37 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1347918570!10273282!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDk2NDU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15507 invoked from network); 17 Sep 2012 21:49:30 -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;
	17 Sep 2012 21:49:30 -0000
X-IronPort-AV: E=Sophos;i="4.80,438,1344211200"; d="scan'208";a="14591182"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Sep 2012 21:49: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.279.1; Mon, 17 Sep 2012 22:49: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 1TDjC5-00062W-5O;
	Mon, 17 Sep 2012 21:49:29 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1TDjC4-0007vH-RK;
	Mon, 17 Sep 2012 22:49:28 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-13799-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Mon, 17 Sep 2012 22:49:28 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13799: 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 13799 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13799/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore            fail   like 13791
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail like 13791
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail like 13791

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  3bf63fcfacd1
baseline version:
 xen                  12fa949b9060

------------------------------------------------------------
People who touched revisions under test:
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Keir Fraser <keir@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-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-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-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-amd64-amd64-xl-win                                      fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=xen-unstable
+ revision=3bf63fcfacd1
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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 3bf63fcfacd1
+ branch=xen-unstable
+ revision=3bf63fcfacd1
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-unstable
+ '[' xxen = xlinux ']'
+ linuxbranch=linux
+ : master
+ : tested/2.6.39.x
+ . ap-common
++ : xen@xenbits.xensource.com
++ : http://xenbits.xen.org/hg/staging/xen-unstable.hg
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : xen@xenbits.xensource.com:git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.xen-unstable
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-unstable.git
++ : daily-cron.xen-unstable
+ TREE_LINUX=xen@xenbits.xensource.com:git/linux-pvops.git
+ TREE_QEMU_UPSTREAM=xen@xenbits.xensource.com:git/qemu-upstream-unstable.git
+ info_linux_tree xen-unstable
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/xen-unstable.hg
+ hg push -r 3bf63fcfacd1 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 21 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 Mon Sep 17 21:54:34 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 21: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 1TDjGi-0000xE-AH; Mon, 17 Sep 2012 21:54:16 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <matthew.fioravante@jhuapl.edu>) id 1TDjGg-0000x7-OI
	for xen-devel@lists.xensource.com; Mon, 17 Sep 2012 21:54:14 +0000
Received: from [85.158.143.35:41573] by server-1.bemta-4.messagelabs.com id
	B2/40-12504-60C97505; Mon, 17 Sep 2012 21:54:14 +0000
X-Env-Sender: matthew.fioravante@jhuapl.edu
X-Msg-Ref: server-15.tower-21.messagelabs.com!1347918850!13993615!1
X-Originating-IP: [128.244.251.36]
X-SpamReason: No, hits=0.0 required=7.0 tests=UNPARSEABLE_RELAY
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22983 invoked from network); 17 Sep 2012 21:54:12 -0000
Received: from pilot.jhuapl.edu (HELO jhuapl.edu) (128.244.251.36)
	by server-15.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 17 Sep 2012 21:54:12 -0000
Received: from ([128.244.207.89])
	by pilot.jhuapl.edu with ESMTP with TLS id 63GHCH1.153075448;
	Mon, 17 Sep 2012 17:53:53 -0400
Message-ID: <50579BA6.1080503@jhuapl.edu>
Date: Mon, 17 Sep 2012 17:52:38 -0400
From: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120827 Thunderbird/15.0
MIME-Version: 1.0
To: Samuel Thibault <samuel.thibault@ens-lyon.org>, 
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
X-Enigmail-Version: 1.4.4
Subject: [Xen-devel] [PATCH mini-os enhancements for vtpm 1/8]
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============6574303224203968757=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a cryptographically signed message in MIME format.

--===============6574303224203968757==
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms070109030402080509080000"

This is a cryptographically signed message in MIME format.

--------------ms070109030402080509080000
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

This patch adds iowritexx() and ioreadxx() functions for interacting
with hardware memory to mini-os. The functions are available in a header
iorw.h

Signed off by Matthew Fioravante: matthew.fioravante@jhuapl.edu

diff --git a/extras/mini-os/arch/ia64/iorw.c
b/extras/mini-os/arch/ia64/iorw.c
--- /dev/null
+++ b/extras/mini-os/arch/ia64/iorw.c
@@ -0,0 +1,22 @@
+#include <mini-os/iorw.h>
+#include <mini-os/console.h>
+
+void iowrite8(volatile void* addr, uint8_t val)
+{
+   printk("iorw not implemented!!\n");
+}
+void iowrite32(volatile void* addr, uint32_t val)
+{
+   printk("iorw not implemented!!\n");
+}
+
+uint8_t ioread8(volatile void* addr)
+{
+   printk("iorw not implemented!!\n");
+   return 0;
+}
+uint32_t ioread32(volatile void* addr)
+{
+   printk("iorw not implemented!!\n");
+   return 0;
+}
diff --git a/extras/mini-os/arch/x86/iorw.c b/extras/mini-os/arch/x86/ior=
w.c
--- /dev/null
+++ b/extras/mini-os/arch/x86/iorw.c
@@ -0,0 +1,19 @@
+#include <mini-os/iorw.h>
+
+void iowrite8(volatile void* addr, uint8_t val)
+{
+   *((volatile uint8_t*)addr) =3D val;
+}
+void iowrite32(volatile void* addr, uint32_t val)
+{
+   *((volatile uint32_t*)addr) =3D val;
+}
+
+uint8_t ioread8(volatile void* addr)
+{
+   return *((volatile uint8_t*) addr);
+}
+uint32_t ioread32(volatile void* addr)
+{
+   return *((volatile uint32_t*) addr);
+}
diff --git a/extras/mini-os/include/iorw.h b/extras/mini-os/include/iorw.=
h
--- /dev/null
+++ b/extras/mini-os/include/iorw.h
@@ -0,0 +1,12 @@
+#ifndef MINIOS_IORW_H
+#define MINIOS_IORW_H
+
+#include <mini-os/types.h>
+
+void iowrite8(volatile void* addr, uint8_t val);
+void iowrite32(volatile void* addr, uint32_t val);
+
+uint8_t ioread8(volatile void* addr);
+uint32_t ioread32(volatile void* addr);
+
+#endif



--------------ms070109030402080509080000
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIDyjCC
A8YwggMvoAMCAQICBD/xyf0wDQYJKoZIhvcNAQEFBQAwLzELMAkGA1UEBhMCVVMxDzANBgNV
BAoTBkpIVUFQTDEPMA0GA1UECxMGQklTRENBMB4XDTEwMDYxMTE4MjIwNloXDTEzMDYxMTE4
NTIwNlowZjELMAkGA1UEBhMCVVMxDzANBgNVBAoTBkpIVUFQTDEPMA0GA1UECxMGUGVvcGxl
MTUwFgYDVQQLEw9WUE5Hcm91cC1CSVNEQ0EwGwYDVQQDExRNYXR0aGV3IEUgRmlvcmF2YW50
ZTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAnpbwVSP6o1Nb5lcW7dd3yTo9iBJdi7qz
4nANOMFPK7JOy5npKN1iiousl28U/scUJES55gPwAWYJK3uVyQAsA4adgDKi5DoD1UHDQEwp
bY7iHLJeq0NPr4BqYNqnCFPbE6HC8zSJrr4qKn+gVUQT39SIFqdiIPJwZL8FYTRQ/zsCAwEA
AaOCAbYwggGyMAsGA1UdDwQEAwIHgDArBgNVHRAEJDAigA8yMDEwMDYxMTE4MjIwNlqBDzIw
MTIwNzE3MjI1MjA2WjAbBg0rBgEEAbMlCwMBAQEBBAoWCGZpb3JhbWUxMBsGDSsGAQQBsyUL
AwEBAQIEChIIMDAxMDQyNjEwWAYJYIZIAYb6ax4BBEsMSVRoZSBwcml2YXRlIGtleSBjb3Jy
ZXNwb25kaW5nIHRvIHRoaXMgY2VydGlmaWNhdGUgbWF5IGhhdmUgYmVlbiBleHBvcnRlZC4w
KAYDVR0RBCEwH4EdTWF0dGhldy5GaW9yYXZhbnRlQGpodWFwbC5lZHUwUgYDVR0fBEswSTBH
oEWgQ6RBMD8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJU0RD
QTEOMAwGA1UEAxMFQ1JMNTYwHwYDVR0jBBgwFoAUCDUpmxH52EU2CyWmF2EJMB1yqeswHQYD
VR0OBBYEFO6LYxg6r9wHZ+zdQtBHn1dZ/YTNMAkGA1UdEwQCMAAwGQYJKoZIhvZ9B0EABAww
ChsEVjcuMQMCBLAwDQYJKoZIhvcNAQEFBQADgYEAJO9HQh4YNChVLzuZqK5ARJARD8JoujGZ
fdo75quvg2jXFQe2sEjvLnxJZgm/pv8fdZakq48CWwjYHKuvIp7sDjTEsQfo+y7SpN/N2NvJ
WU5SqfK1VgYtNLRRoGJUB5Q1aZ+Dg95g3kqpyfpUMISJL8IKVLtJVfN4fggFVUYZ9wwxggGr
MIIBpwIBATA3MC8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJ
U0RDQQIEP/HJ/TAJBgUrDgMCGgUAoIHLMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ
KoZIhvcNAQkFMQ8XDTEyMDkxNzIxNTIzOFowIwYJKoZIhvcNAQkEMRYEFE6QEkSgyLyXtsSX
GuniukiIUEftMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAK
BggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI
KoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEgYBpPRdd6mf7aMQpTVl0oZV31tgHQzANa2lJ
hSo7jMaXteYYMb+1R6U+l4IMP7sLq6NNoh9JufGomcrtc6QgAYwcFC/QEWs04H25YANf5fRR
T2z+a3xoK8oRYK6O4EYwa0RY/WK0PR0ZfyaDLmd1Az4h+8+1ScUPnmiX4s0eefYT6AAAAAAA
AA==
--------------ms070109030402080509080000--


--===============6574303224203968757==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============6574303224203968757==--


From xen-devel-bounces@lists.xen.org Mon Sep 17 21:54:34 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 21: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 1TDjGi-0000xE-AH; Mon, 17 Sep 2012 21:54:16 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <matthew.fioravante@jhuapl.edu>) id 1TDjGg-0000x7-OI
	for xen-devel@lists.xensource.com; Mon, 17 Sep 2012 21:54:14 +0000
Received: from [85.158.143.35:41573] by server-1.bemta-4.messagelabs.com id
	B2/40-12504-60C97505; Mon, 17 Sep 2012 21:54:14 +0000
X-Env-Sender: matthew.fioravante@jhuapl.edu
X-Msg-Ref: server-15.tower-21.messagelabs.com!1347918850!13993615!1
X-Originating-IP: [128.244.251.36]
X-SpamReason: No, hits=0.0 required=7.0 tests=UNPARSEABLE_RELAY
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22983 invoked from network); 17 Sep 2012 21:54:12 -0000
Received: from pilot.jhuapl.edu (HELO jhuapl.edu) (128.244.251.36)
	by server-15.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 17 Sep 2012 21:54:12 -0000
Received: from ([128.244.207.89])
	by pilot.jhuapl.edu with ESMTP with TLS id 63GHCH1.153075448;
	Mon, 17 Sep 2012 17:53:53 -0400
Message-ID: <50579BA6.1080503@jhuapl.edu>
Date: Mon, 17 Sep 2012 17:52:38 -0400
From: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120827 Thunderbird/15.0
MIME-Version: 1.0
To: Samuel Thibault <samuel.thibault@ens-lyon.org>, 
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
X-Enigmail-Version: 1.4.4
Subject: [Xen-devel] [PATCH mini-os enhancements for vtpm 1/8]
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============6574303224203968757=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a cryptographically signed message in MIME format.

--===============6574303224203968757==
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms070109030402080509080000"

This is a cryptographically signed message in MIME format.

--------------ms070109030402080509080000
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

This patch adds iowritexx() and ioreadxx() functions for interacting
with hardware memory to mini-os. The functions are available in a header
iorw.h

Signed off by Matthew Fioravante: matthew.fioravante@jhuapl.edu

diff --git a/extras/mini-os/arch/ia64/iorw.c
b/extras/mini-os/arch/ia64/iorw.c
--- /dev/null
+++ b/extras/mini-os/arch/ia64/iorw.c
@@ -0,0 +1,22 @@
+#include <mini-os/iorw.h>
+#include <mini-os/console.h>
+
+void iowrite8(volatile void* addr, uint8_t val)
+{
+   printk("iorw not implemented!!\n");
+}
+void iowrite32(volatile void* addr, uint32_t val)
+{
+   printk("iorw not implemented!!\n");
+}
+
+uint8_t ioread8(volatile void* addr)
+{
+   printk("iorw not implemented!!\n");
+   return 0;
+}
+uint32_t ioread32(volatile void* addr)
+{
+   printk("iorw not implemented!!\n");
+   return 0;
+}
diff --git a/extras/mini-os/arch/x86/iorw.c b/extras/mini-os/arch/x86/ior=
w.c
--- /dev/null
+++ b/extras/mini-os/arch/x86/iorw.c
@@ -0,0 +1,19 @@
+#include <mini-os/iorw.h>
+
+void iowrite8(volatile void* addr, uint8_t val)
+{
+   *((volatile uint8_t*)addr) =3D val;
+}
+void iowrite32(volatile void* addr, uint32_t val)
+{
+   *((volatile uint32_t*)addr) =3D val;
+}
+
+uint8_t ioread8(volatile void* addr)
+{
+   return *((volatile uint8_t*) addr);
+}
+uint32_t ioread32(volatile void* addr)
+{
+   return *((volatile uint32_t*) addr);
+}
diff --git a/extras/mini-os/include/iorw.h b/extras/mini-os/include/iorw.=
h
--- /dev/null
+++ b/extras/mini-os/include/iorw.h
@@ -0,0 +1,12 @@
+#ifndef MINIOS_IORW_H
+#define MINIOS_IORW_H
+
+#include <mini-os/types.h>
+
+void iowrite8(volatile void* addr, uint8_t val);
+void iowrite32(volatile void* addr, uint32_t val);
+
+uint8_t ioread8(volatile void* addr);
+uint32_t ioread32(volatile void* addr);
+
+#endif



--------------ms070109030402080509080000
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIDyjCC
A8YwggMvoAMCAQICBD/xyf0wDQYJKoZIhvcNAQEFBQAwLzELMAkGA1UEBhMCVVMxDzANBgNV
BAoTBkpIVUFQTDEPMA0GA1UECxMGQklTRENBMB4XDTEwMDYxMTE4MjIwNloXDTEzMDYxMTE4
NTIwNlowZjELMAkGA1UEBhMCVVMxDzANBgNVBAoTBkpIVUFQTDEPMA0GA1UECxMGUGVvcGxl
MTUwFgYDVQQLEw9WUE5Hcm91cC1CSVNEQ0EwGwYDVQQDExRNYXR0aGV3IEUgRmlvcmF2YW50
ZTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAnpbwVSP6o1Nb5lcW7dd3yTo9iBJdi7qz
4nANOMFPK7JOy5npKN1iiousl28U/scUJES55gPwAWYJK3uVyQAsA4adgDKi5DoD1UHDQEwp
bY7iHLJeq0NPr4BqYNqnCFPbE6HC8zSJrr4qKn+gVUQT39SIFqdiIPJwZL8FYTRQ/zsCAwEA
AaOCAbYwggGyMAsGA1UdDwQEAwIHgDArBgNVHRAEJDAigA8yMDEwMDYxMTE4MjIwNlqBDzIw
MTIwNzE3MjI1MjA2WjAbBg0rBgEEAbMlCwMBAQEBBAoWCGZpb3JhbWUxMBsGDSsGAQQBsyUL
AwEBAQIEChIIMDAxMDQyNjEwWAYJYIZIAYb6ax4BBEsMSVRoZSBwcml2YXRlIGtleSBjb3Jy
ZXNwb25kaW5nIHRvIHRoaXMgY2VydGlmaWNhdGUgbWF5IGhhdmUgYmVlbiBleHBvcnRlZC4w
KAYDVR0RBCEwH4EdTWF0dGhldy5GaW9yYXZhbnRlQGpodWFwbC5lZHUwUgYDVR0fBEswSTBH
oEWgQ6RBMD8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJU0RD
QTEOMAwGA1UEAxMFQ1JMNTYwHwYDVR0jBBgwFoAUCDUpmxH52EU2CyWmF2EJMB1yqeswHQYD
VR0OBBYEFO6LYxg6r9wHZ+zdQtBHn1dZ/YTNMAkGA1UdEwQCMAAwGQYJKoZIhvZ9B0EABAww
ChsEVjcuMQMCBLAwDQYJKoZIhvcNAQEFBQADgYEAJO9HQh4YNChVLzuZqK5ARJARD8JoujGZ
fdo75quvg2jXFQe2sEjvLnxJZgm/pv8fdZakq48CWwjYHKuvIp7sDjTEsQfo+y7SpN/N2NvJ
WU5SqfK1VgYtNLRRoGJUB5Q1aZ+Dg95g3kqpyfpUMISJL8IKVLtJVfN4fggFVUYZ9wwxggGr
MIIBpwIBATA3MC8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJ
U0RDQQIEP/HJ/TAJBgUrDgMCGgUAoIHLMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ
KoZIhvcNAQkFMQ8XDTEyMDkxNzIxNTIzOFowIwYJKoZIhvcNAQkEMRYEFE6QEkSgyLyXtsSX
GuniukiIUEftMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAK
BggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI
KoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEgYBpPRdd6mf7aMQpTVl0oZV31tgHQzANa2lJ
hSo7jMaXteYYMb+1R6U+l4IMP7sLq6NNoh9JufGomcrtc6QgAYwcFC/QEWs04H25YANf5fRR
T2z+a3xoK8oRYK6O4EYwa0RY/WK0PR0ZfyaDLmd1Az4h+8+1ScUPnmiX4s0eefYT6AAAAAAA
AA==
--------------ms070109030402080509080000--


--===============6574303224203968757==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============6574303224203968757==--


From xen-devel-bounces@lists.xen.org Mon Sep 17 21:57:33 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 21:57:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDjJe-0001Mi-29; Mon, 17 Sep 2012 21:57:18 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <matthew.fioravante@jhuapl.edu>) id 1TDjJc-0001Mb-Ho
	for xen-devel@lists.xensource.com; Mon, 17 Sep 2012 21:57:16 +0000
Received: from [85.158.139.211:35775] by server-5.bemta-5.messagelabs.com id
	6B/5D-30514-BBC97505; Mon, 17 Sep 2012 21:57:15 +0000
X-Env-Sender: matthew.fioravante@jhuapl.edu
X-Msg-Ref: server-4.tower-206.messagelabs.com!1347919033!18943471!1
X-Originating-IP: [128.244.251.36]
X-SpamReason: No, hits=1.4 required=7.0 tests=INFO_TLD,UNPARSEABLE_RELAY
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11061 invoked from network); 17 Sep 2012 21:57:14 -0000
Received: from pilot.jhuapl.edu (HELO jhuapl.edu) (128.244.251.36)
	by server-4.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 17 Sep 2012 21:57:14 -0000
Received: from ([128.244.207.89])
	by pilot.jhuapl.edu with ESMTP with TLS id 63GHCH1.153075553;
	Mon, 17 Sep 2012 17:56:58 -0400
Message-ID: <50579C5F.5040004@jhuapl.edu>
Date: Mon, 17 Sep 2012 17:55:43 -0400
From: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120827 Thunderbird/15.0
MIME-Version: 1.0
To: Samuel Thibault <samuel.thibault@ens-lyon.org>, 
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
X-Enigmail-Version: 1.4.4
Subject: [Xen-devel] [PATCH mini-os enhancements for vtpm 2/8] add posix io
	to blkfront
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============6453934534774364880=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a cryptographically signed message in MIME format.

--===============6453934534774364880==
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms030904070101060306020108"

This is a cryptographically signed message in MIME format.

--------------ms030904070101060306020108
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

This patch adds posix io support (read,write,lseek) to block devices
using blkfront


Signed off by Matthew Fioravante matthew.fioravante@jhuapl.edu

diff --git a/extras/mini-os/blkfront.c b/extras/mini-os/blkfront.c
--- a/extras/mini-os/blkfront.c
+++ b/extras/mini-os/blkfront.c
@@ -392,6 +392,7 @@ void blkfront_aio(struct blkfront_aiocb *aiocbp, int
write)
 static void blkfront_aio_cb(struct blkfront_aiocb *aiocbp, int ret)
 {
     aiocbp->data =3D (void*) 1;
+    aiocbp->aio_cb =3D NULL;
 }
=20
 void blkfront_io(struct blkfront_aiocb *aiocbp, int write)
@@ -547,9 +548,150 @@ moretodo:
 #ifdef HAVE_LIBC
 int blkfront_open(struct blkfront_dev *dev)
 {
+    /* Silently prevent multiple opens */
+    if(dev->fd !=3D -1) {
+       return dev->fd;
+    }
     dev->fd =3D alloc_fd(FTYPE_BLK);
     printk("blk_open(%s) -> %d\n", dev->nodename, dev->fd);
     files[dev->fd].blk.dev =3D dev;
+    files[dev->fd].blk.offset =3D 0;
     return dev->fd;
 }
+
+int blkfront_posix_rwop(int fd, uint8_t* buf, size_t count, int write)
+{
+   struct blkfront_dev* dev =3D files[fd].blk.dev;
+   off_t offset =3D files[fd].blk.offset;
+   struct blkfront_aiocb aiocb;
+   unsigned long long disksize =3D dev->info.sectors * dev->info.sector_=
size;
+   unsigned int blocksize =3D dev->info.sector_size;
+
+   int blknum;
+   int blkoff;
+   size_t bytes;
+   int rc =3D 0;
+   int alignedbuf =3D 0;
+   uint8_t* copybuf =3D NULL;
+
+   /* RW 0 bytes is just a NOP */
+   if(count =3D=3D 0) {
+      return 0;
+   }
+   /* Check for NULL buffer */
+   if( buf =3D=3D NULL ) {
+      errno =3D EFAULT;
+      return -1;
+   }
+
+   /* Write mode checks */
+   if(write) {
+      /*Make sure we have write permission */
+      if(dev->info.info & VDISK_READONLY || (dev->info.mode !=3D O_RDWR =

&& dev->info.mode !=3D  O_WRONLY)) {
+         errno =3D EACCES;
+         return -1;
+      }
+      /*Make sure disk is big enough for this write */
+      if(offset + count > disksize) {
+         errno =3D ENOSPC;
+         return -1;
+      }
+   }
+   /* Read mode checks */
+   else
+   {
+      /*If the requested read is bigger than the disk, just
+       * read as much as we can until the end */
+      if(offset + count > disksize) {
+         count =3D offset >=3D disksize ? 0 : disksize - offset;
+      }
+   }
+   /* Determine which block to start at and which offset inside of it */=

+   blknum =3D offset / blocksize;
+   blkoff =3D offset % blocksize;
+
+   /* Optimization: We need to check if buf is aligned to the sector siz=
e.
+    * This is somewhat tricky code. We have to add the blocksize -
block offset
+    * because the first block may be a partial block and then for every
subsequent
+    * block rw the buffer will be offset.*/
+   if(!((uintptr_t) (buf +(blocksize -  blkoff)) &
(dev->info.sector_size-1))) {
+      alignedbuf =3D 1;
+   }
+
+   /* Setup aiocb block object */
+   aiocb.aio_dev =3D dev;
+   aiocb.aio_nbytes =3D blocksize;
+   aiocb.aio_offset =3D blknum * blocksize;
+   aiocb.aio_cb =3D NULL;
+   aiocb.data =3D NULL;
+
+   /* If our buffer is unaligned or its aligned but we will need to rw
a partial block
+    * then a copy will have to be done */
+   if(!alignedbuf || blkoff !=3D 0 || count % blocksize !=3D 0) {
+      copybuf =3D _xmalloc(blocksize, dev->info.sector_size);
+   }
+
+   rc =3D count;
+   while(count > 0) {
+      /* determine how many bytes to read/write from/to the current
block buffer */
+      bytes =3D count > (blocksize - blkoff) ? blocksize - blkoff : coun=
t;
+
+      /* read operation */
+      if(!write) {
+         if (alignedbuf && bytes >=3D blocksize) {
+            /* If aligned and were reading a whole block, just read
right into buf */
+            aiocb.aio_buf =3D buf;
+            blkfront_read(&aiocb);
+         } else {
+            /* If not then we have to do a copy */
+            aiocb.aio_buf =3D copybuf;
+            blkfront_read(&aiocb);
+            memcpy(buf, &copybuf[blkoff], bytes);
+         }
+      }
+      /* Write operation */
+      else {
+         if(alignedbuf && bytes >=3D blocksize) {
+            /* If aligned and were writing a whole block, just write
directly from buf */
+            aiocb.aio_buf =3D buf;
+            blkfront_write(&aiocb);
+         } else {
+            /* If not then we have to do a copy. */
+            aiocb.aio_buf =3D copybuf;
+            /* If we're writing a partial block, we need to read the
current contents first
+             * so we don't overwrite the extra bits with garbage */
+            if(blkoff !=3D 0 || bytes < blocksize) {
+               blkfront_read(&aiocb);
+            }
+            memcpy(&copybuf[blkoff], buf, bytes);
+            blkfront_write(&aiocb);
+         }
+      }
+      /* Will start at beginning of all remaining blocks */
+      blkoff =3D 0;
+
+      /* Increment counters and continue */
+      count -=3D bytes;
+      buf +=3D bytes;
+      aiocb.aio_offset +=3D blocksize;
+   }
+
+   free(copybuf);
+   files[fd].blk.offset +=3D rc;
+   return rc;
+
+}
+
+int blkfront_posix_fstat(int fd, struct stat* buf)
+{
+   struct blkfront_dev* dev =3D files[fd].blk.dev;
+
+   buf->st_mode =3D dev->info.mode;
+   buf->st_uid =3D 0;
+   buf->st_gid =3D 0;
+   buf->st_size =3D dev->info.sectors * dev->info.sector_size;
+   buf->st_atime =3D buf->st_mtime =3D buf->st_ctime =3D time(NULL);
+
+   return 0;
+}
 #endif
diff --git a/extras/mini-os/include/blkfront.h
b/extras/mini-os/include/blkfront.h
--- a/extras/mini-os/include/blkfront.h
+++ b/extras/mini-os/include/blkfront.h
@@ -28,7 +28,17 @@ struct blkfront_info
 };
 struct blkfront_dev *init_blkfront(char *nodename, struct blkfront_info
*info);
 #ifdef HAVE_LIBC
+#include <sys/stat.h>
+/* POSIX IO functions:
+ * use blkfront_open() to get a file descriptor to the block device
+ * Don't use the other blkfront posix functions here directly, instead u=
se
+ * read(), write(), lseek() and fstat() on the file descriptor
+ */
 int blkfront_open(struct blkfront_dev *dev);
+int blkfront_posix_rwop(int fd, uint8_t* buf, size_t count, int write);
+#define blkfront_posix_write(fd, buf, count) blkfront_posix_rwop(fd,
(uint8_t*)buf, count, 1)
+#define blkfront_posix_read(fd, buf, count) blkfront_posix_rwop(fd,
(uint8_t*)buf, count, 0)
+int blkfront_posix_fstat(int fd, struct stat* buf);
 #endif
 void blkfront_aio(struct blkfront_aiocb *aiocbp, int write);
 #define blkfront_aio_read(aiocbp) blkfront_aio(aiocbp, 0)
diff --git a/extras/mini-os/include/lib.h b/extras/mini-os/include/lib.h
--- a/extras/mini-os/include/lib.h
+++ b/extras/mini-os/include/lib.h
@@ -174,6 +174,7 @@ extern struct file {
     } tap;
     struct {
         struct blkfront_dev *dev;
+            off_t offset;
     } blk;
     struct {
         struct kbdfront_dev *dev;
diff --git a/extras/mini-os/lib/sys.c b/extras/mini-os/lib/sys.c
--- a/extras/mini-os/lib/sys.c
+++ b/extras/mini-os/lib/sys.c
@@ -289,6 +289,11 @@ int read(int fd, void *buf, size_t nbytes)
         return ret * sizeof(union xenfb_in_event);
         }
 #endif
+#ifdef CONFIG_BLKFRONT
+        case FTYPE_BLK: {
+        return blkfront_posix_read(fd, buf, nbytes);
+        }
+#endif
     default:
         break;
     }
@@ -321,6 +326,10 @@ int write(int fd, const void *buf, size_t nbytes)
         netfront_xmit(files[fd].tap.dev, (void*) buf, nbytes);
         return nbytes;
 #endif
+#ifdef CONFIG_BLKFRONT
+    case FTYPE_BLK:
+        return blkfront_posix_write(fd, buf, nbytes);
+#endif
     default:
         break;
     }
@@ -331,8 +340,37 @@ int write(int fd, const void *buf, size_t nbytes)
=20
 off_t lseek(int fd, off_t offset, int whence)
 {
-    errno =3D ESPIPE;
-    return (off_t) -1;
+    switch(files[fd].type) {
+#ifdef CONFIG_BLKFRONT
+       case FTYPE_BLK:
+      switch (whence) {
+         case SEEK_SET:
+        files[fd].file.offset =3D offset;
+        break;
+         case SEEK_CUR:
+        files[fd].file.offset +=3D offset;
+        break;
+         case SEEK_END:
+        {
+           struct stat st;
+           int ret;
+           ret =3D fstat(fd, &st);
+           if (ret)
+              return -1;
+           files[fd].file.offset =3D st.st_size + offset;
+           break;
+        }
+         default:
+        errno =3D EINVAL;
+        return -1;
+      }
+      return files[fd].file.offset;
+      break;
+#endif
+       default: /* Not implemented on this FTYPE */
+      errno =3D ESPIPE;
+      return (off_t) -1;
+    }
 }
=20
 int fsync(int fd) {
@@ -445,6 +483,10 @@ int fstat(int fd, struct stat *buf)
         buf->st_ctime =3D time(NULL);
         return 0;
     }
+#ifdef CONFIG_BLKFRONT
+    case FTYPE_BLK:
+       return blkfront_posix_fstat(fd, buf);
+#endif
     default:
         break;
     }



--------------ms030904070101060306020108
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIDyjCC
A8YwggMvoAMCAQICBD/xyf0wDQYJKoZIhvcNAQEFBQAwLzELMAkGA1UEBhMCVVMxDzANBgNV
BAoTBkpIVUFQTDEPMA0GA1UECxMGQklTRENBMB4XDTEwMDYxMTE4MjIwNloXDTEzMDYxMTE4
NTIwNlowZjELMAkGA1UEBhMCVVMxDzANBgNVBAoTBkpIVUFQTDEPMA0GA1UECxMGUGVvcGxl
MTUwFgYDVQQLEw9WUE5Hcm91cC1CSVNEQ0EwGwYDVQQDExRNYXR0aGV3IEUgRmlvcmF2YW50
ZTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAnpbwVSP6o1Nb5lcW7dd3yTo9iBJdi7qz
4nANOMFPK7JOy5npKN1iiousl28U/scUJES55gPwAWYJK3uVyQAsA4adgDKi5DoD1UHDQEwp
bY7iHLJeq0NPr4BqYNqnCFPbE6HC8zSJrr4qKn+gVUQT39SIFqdiIPJwZL8FYTRQ/zsCAwEA
AaOCAbYwggGyMAsGA1UdDwQEAwIHgDArBgNVHRAEJDAigA8yMDEwMDYxMTE4MjIwNlqBDzIw
MTIwNzE3MjI1MjA2WjAbBg0rBgEEAbMlCwMBAQEBBAoWCGZpb3JhbWUxMBsGDSsGAQQBsyUL
AwEBAQIEChIIMDAxMDQyNjEwWAYJYIZIAYb6ax4BBEsMSVRoZSBwcml2YXRlIGtleSBjb3Jy
ZXNwb25kaW5nIHRvIHRoaXMgY2VydGlmaWNhdGUgbWF5IGhhdmUgYmVlbiBleHBvcnRlZC4w
KAYDVR0RBCEwH4EdTWF0dGhldy5GaW9yYXZhbnRlQGpodWFwbC5lZHUwUgYDVR0fBEswSTBH
oEWgQ6RBMD8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJU0RD
QTEOMAwGA1UEAxMFQ1JMNTYwHwYDVR0jBBgwFoAUCDUpmxH52EU2CyWmF2EJMB1yqeswHQYD
VR0OBBYEFO6LYxg6r9wHZ+zdQtBHn1dZ/YTNMAkGA1UdEwQCMAAwGQYJKoZIhvZ9B0EABAww
ChsEVjcuMQMCBLAwDQYJKoZIhvcNAQEFBQADgYEAJO9HQh4YNChVLzuZqK5ARJARD8JoujGZ
fdo75quvg2jXFQe2sEjvLnxJZgm/pv8fdZakq48CWwjYHKuvIp7sDjTEsQfo+y7SpN/N2NvJ
WU5SqfK1VgYtNLRRoGJUB5Q1aZ+Dg95g3kqpyfpUMISJL8IKVLtJVfN4fggFVUYZ9wwxggGr
MIIBpwIBATA3MC8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJ
U0RDQQIEP/HJ/TAJBgUrDgMCGgUAoIHLMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ
KoZIhvcNAQkFMQ8XDTEyMDkxNzIxNTU0M1owIwYJKoZIhvcNAQkEMRYEFDvEVJ+7mr9gWF47
Pl6XCN7hsc/6MGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAK
BggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI
KoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEgYCOw5U4S79Ne/L0S2QV6bOkbuIPhe1B2rRG
y7u16x6C8b8TJKKDoVHlJeFDvuUdVeS7hK5eTkYom2BDl6xt/+6JYoQm7nkLbBhQG1hElGCy
1P2m9WyF/oul4khcKGONe9UazxdH4JRG4MYwEHHR8aSX4995Dx4MtzK/scz7d5LnAQAAAAAA
AA==
--------------ms030904070101060306020108--


--===============6453934534774364880==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============6453934534774364880==--


From xen-devel-bounces@lists.xen.org Mon Sep 17 21:57:33 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 21:57:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDjJe-0001Mi-29; Mon, 17 Sep 2012 21:57:18 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <matthew.fioravante@jhuapl.edu>) id 1TDjJc-0001Mb-Ho
	for xen-devel@lists.xensource.com; Mon, 17 Sep 2012 21:57:16 +0000
Received: from [85.158.139.211:35775] by server-5.bemta-5.messagelabs.com id
	6B/5D-30514-BBC97505; Mon, 17 Sep 2012 21:57:15 +0000
X-Env-Sender: matthew.fioravante@jhuapl.edu
X-Msg-Ref: server-4.tower-206.messagelabs.com!1347919033!18943471!1
X-Originating-IP: [128.244.251.36]
X-SpamReason: No, hits=1.4 required=7.0 tests=INFO_TLD,UNPARSEABLE_RELAY
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11061 invoked from network); 17 Sep 2012 21:57:14 -0000
Received: from pilot.jhuapl.edu (HELO jhuapl.edu) (128.244.251.36)
	by server-4.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 17 Sep 2012 21:57:14 -0000
Received: from ([128.244.207.89])
	by pilot.jhuapl.edu with ESMTP with TLS id 63GHCH1.153075553;
	Mon, 17 Sep 2012 17:56:58 -0400
Message-ID: <50579C5F.5040004@jhuapl.edu>
Date: Mon, 17 Sep 2012 17:55:43 -0400
From: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120827 Thunderbird/15.0
MIME-Version: 1.0
To: Samuel Thibault <samuel.thibault@ens-lyon.org>, 
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
X-Enigmail-Version: 1.4.4
Subject: [Xen-devel] [PATCH mini-os enhancements for vtpm 2/8] add posix io
	to blkfront
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============6453934534774364880=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a cryptographically signed message in MIME format.

--===============6453934534774364880==
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms030904070101060306020108"

This is a cryptographically signed message in MIME format.

--------------ms030904070101060306020108
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

This patch adds posix io support (read,write,lseek) to block devices
using blkfront


Signed off by Matthew Fioravante matthew.fioravante@jhuapl.edu

diff --git a/extras/mini-os/blkfront.c b/extras/mini-os/blkfront.c
--- a/extras/mini-os/blkfront.c
+++ b/extras/mini-os/blkfront.c
@@ -392,6 +392,7 @@ void blkfront_aio(struct blkfront_aiocb *aiocbp, int
write)
 static void blkfront_aio_cb(struct blkfront_aiocb *aiocbp, int ret)
 {
     aiocbp->data =3D (void*) 1;
+    aiocbp->aio_cb =3D NULL;
 }
=20
 void blkfront_io(struct blkfront_aiocb *aiocbp, int write)
@@ -547,9 +548,150 @@ moretodo:
 #ifdef HAVE_LIBC
 int blkfront_open(struct blkfront_dev *dev)
 {
+    /* Silently prevent multiple opens */
+    if(dev->fd !=3D -1) {
+       return dev->fd;
+    }
     dev->fd =3D alloc_fd(FTYPE_BLK);
     printk("blk_open(%s) -> %d\n", dev->nodename, dev->fd);
     files[dev->fd].blk.dev =3D dev;
+    files[dev->fd].blk.offset =3D 0;
     return dev->fd;
 }
+
+int blkfront_posix_rwop(int fd, uint8_t* buf, size_t count, int write)
+{
+   struct blkfront_dev* dev =3D files[fd].blk.dev;
+   off_t offset =3D files[fd].blk.offset;
+   struct blkfront_aiocb aiocb;
+   unsigned long long disksize =3D dev->info.sectors * dev->info.sector_=
size;
+   unsigned int blocksize =3D dev->info.sector_size;
+
+   int blknum;
+   int blkoff;
+   size_t bytes;
+   int rc =3D 0;
+   int alignedbuf =3D 0;
+   uint8_t* copybuf =3D NULL;
+
+   /* RW 0 bytes is just a NOP */
+   if(count =3D=3D 0) {
+      return 0;
+   }
+   /* Check for NULL buffer */
+   if( buf =3D=3D NULL ) {
+      errno =3D EFAULT;
+      return -1;
+   }
+
+   /* Write mode checks */
+   if(write) {
+      /*Make sure we have write permission */
+      if(dev->info.info & VDISK_READONLY || (dev->info.mode !=3D O_RDWR =

&& dev->info.mode !=3D  O_WRONLY)) {
+         errno =3D EACCES;
+         return -1;
+      }
+      /*Make sure disk is big enough for this write */
+      if(offset + count > disksize) {
+         errno =3D ENOSPC;
+         return -1;
+      }
+   }
+   /* Read mode checks */
+   else
+   {
+      /*If the requested read is bigger than the disk, just
+       * read as much as we can until the end */
+      if(offset + count > disksize) {
+         count =3D offset >=3D disksize ? 0 : disksize - offset;
+      }
+   }
+   /* Determine which block to start at and which offset inside of it */=

+   blknum =3D offset / blocksize;
+   blkoff =3D offset % blocksize;
+
+   /* Optimization: We need to check if buf is aligned to the sector siz=
e.
+    * This is somewhat tricky code. We have to add the blocksize -
block offset
+    * because the first block may be a partial block and then for every
subsequent
+    * block rw the buffer will be offset.*/
+   if(!((uintptr_t) (buf +(blocksize -  blkoff)) &
(dev->info.sector_size-1))) {
+      alignedbuf =3D 1;
+   }
+
+   /* Setup aiocb block object */
+   aiocb.aio_dev =3D dev;
+   aiocb.aio_nbytes =3D blocksize;
+   aiocb.aio_offset =3D blknum * blocksize;
+   aiocb.aio_cb =3D NULL;
+   aiocb.data =3D NULL;
+
+   /* If our buffer is unaligned or its aligned but we will need to rw
a partial block
+    * then a copy will have to be done */
+   if(!alignedbuf || blkoff !=3D 0 || count % blocksize !=3D 0) {
+      copybuf =3D _xmalloc(blocksize, dev->info.sector_size);
+   }
+
+   rc =3D count;
+   while(count > 0) {
+      /* determine how many bytes to read/write from/to the current
block buffer */
+      bytes =3D count > (blocksize - blkoff) ? blocksize - blkoff : coun=
t;
+
+      /* read operation */
+      if(!write) {
+         if (alignedbuf && bytes >=3D blocksize) {
+            /* If aligned and were reading a whole block, just read
right into buf */
+            aiocb.aio_buf =3D buf;
+            blkfront_read(&aiocb);
+         } else {
+            /* If not then we have to do a copy */
+            aiocb.aio_buf =3D copybuf;
+            blkfront_read(&aiocb);
+            memcpy(buf, &copybuf[blkoff], bytes);
+         }
+      }
+      /* Write operation */
+      else {
+         if(alignedbuf && bytes >=3D blocksize) {
+            /* If aligned and were writing a whole block, just write
directly from buf */
+            aiocb.aio_buf =3D buf;
+            blkfront_write(&aiocb);
+         } else {
+            /* If not then we have to do a copy. */
+            aiocb.aio_buf =3D copybuf;
+            /* If we're writing a partial block, we need to read the
current contents first
+             * so we don't overwrite the extra bits with garbage */
+            if(blkoff !=3D 0 || bytes < blocksize) {
+               blkfront_read(&aiocb);
+            }
+            memcpy(&copybuf[blkoff], buf, bytes);
+            blkfront_write(&aiocb);
+         }
+      }
+      /* Will start at beginning of all remaining blocks */
+      blkoff =3D 0;
+
+      /* Increment counters and continue */
+      count -=3D bytes;
+      buf +=3D bytes;
+      aiocb.aio_offset +=3D blocksize;
+   }
+
+   free(copybuf);
+   files[fd].blk.offset +=3D rc;
+   return rc;
+
+}
+
+int blkfront_posix_fstat(int fd, struct stat* buf)
+{
+   struct blkfront_dev* dev =3D files[fd].blk.dev;
+
+   buf->st_mode =3D dev->info.mode;
+   buf->st_uid =3D 0;
+   buf->st_gid =3D 0;
+   buf->st_size =3D dev->info.sectors * dev->info.sector_size;
+   buf->st_atime =3D buf->st_mtime =3D buf->st_ctime =3D time(NULL);
+
+   return 0;
+}
 #endif
diff --git a/extras/mini-os/include/blkfront.h
b/extras/mini-os/include/blkfront.h
--- a/extras/mini-os/include/blkfront.h
+++ b/extras/mini-os/include/blkfront.h
@@ -28,7 +28,17 @@ struct blkfront_info
 };
 struct blkfront_dev *init_blkfront(char *nodename, struct blkfront_info
*info);
 #ifdef HAVE_LIBC
+#include <sys/stat.h>
+/* POSIX IO functions:
+ * use blkfront_open() to get a file descriptor to the block device
+ * Don't use the other blkfront posix functions here directly, instead u=
se
+ * read(), write(), lseek() and fstat() on the file descriptor
+ */
 int blkfront_open(struct blkfront_dev *dev);
+int blkfront_posix_rwop(int fd, uint8_t* buf, size_t count, int write);
+#define blkfront_posix_write(fd, buf, count) blkfront_posix_rwop(fd,
(uint8_t*)buf, count, 1)
+#define blkfront_posix_read(fd, buf, count) blkfront_posix_rwop(fd,
(uint8_t*)buf, count, 0)
+int blkfront_posix_fstat(int fd, struct stat* buf);
 #endif
 void blkfront_aio(struct blkfront_aiocb *aiocbp, int write);
 #define blkfront_aio_read(aiocbp) blkfront_aio(aiocbp, 0)
diff --git a/extras/mini-os/include/lib.h b/extras/mini-os/include/lib.h
--- a/extras/mini-os/include/lib.h
+++ b/extras/mini-os/include/lib.h
@@ -174,6 +174,7 @@ extern struct file {
     } tap;
     struct {
         struct blkfront_dev *dev;
+            off_t offset;
     } blk;
     struct {
         struct kbdfront_dev *dev;
diff --git a/extras/mini-os/lib/sys.c b/extras/mini-os/lib/sys.c
--- a/extras/mini-os/lib/sys.c
+++ b/extras/mini-os/lib/sys.c
@@ -289,6 +289,11 @@ int read(int fd, void *buf, size_t nbytes)
         return ret * sizeof(union xenfb_in_event);
         }
 #endif
+#ifdef CONFIG_BLKFRONT
+        case FTYPE_BLK: {
+        return blkfront_posix_read(fd, buf, nbytes);
+        }
+#endif
     default:
         break;
     }
@@ -321,6 +326,10 @@ int write(int fd, const void *buf, size_t nbytes)
         netfront_xmit(files[fd].tap.dev, (void*) buf, nbytes);
         return nbytes;
 #endif
+#ifdef CONFIG_BLKFRONT
+    case FTYPE_BLK:
+        return blkfront_posix_write(fd, buf, nbytes);
+#endif
     default:
         break;
     }
@@ -331,8 +340,37 @@ int write(int fd, const void *buf, size_t nbytes)
=20
 off_t lseek(int fd, off_t offset, int whence)
 {
-    errno =3D ESPIPE;
-    return (off_t) -1;
+    switch(files[fd].type) {
+#ifdef CONFIG_BLKFRONT
+       case FTYPE_BLK:
+      switch (whence) {
+         case SEEK_SET:
+        files[fd].file.offset =3D offset;
+        break;
+         case SEEK_CUR:
+        files[fd].file.offset +=3D offset;
+        break;
+         case SEEK_END:
+        {
+           struct stat st;
+           int ret;
+           ret =3D fstat(fd, &st);
+           if (ret)
+              return -1;
+           files[fd].file.offset =3D st.st_size + offset;
+           break;
+        }
+         default:
+        errno =3D EINVAL;
+        return -1;
+      }
+      return files[fd].file.offset;
+      break;
+#endif
+       default: /* Not implemented on this FTYPE */
+      errno =3D ESPIPE;
+      return (off_t) -1;
+    }
 }
=20
 int fsync(int fd) {
@@ -445,6 +483,10 @@ int fstat(int fd, struct stat *buf)
         buf->st_ctime =3D time(NULL);
         return 0;
     }
+#ifdef CONFIG_BLKFRONT
+    case FTYPE_BLK:
+       return blkfront_posix_fstat(fd, buf);
+#endif
     default:
         break;
     }



--------------ms030904070101060306020108
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIDyjCC
A8YwggMvoAMCAQICBD/xyf0wDQYJKoZIhvcNAQEFBQAwLzELMAkGA1UEBhMCVVMxDzANBgNV
BAoTBkpIVUFQTDEPMA0GA1UECxMGQklTRENBMB4XDTEwMDYxMTE4MjIwNloXDTEzMDYxMTE4
NTIwNlowZjELMAkGA1UEBhMCVVMxDzANBgNVBAoTBkpIVUFQTDEPMA0GA1UECxMGUGVvcGxl
MTUwFgYDVQQLEw9WUE5Hcm91cC1CSVNEQ0EwGwYDVQQDExRNYXR0aGV3IEUgRmlvcmF2YW50
ZTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAnpbwVSP6o1Nb5lcW7dd3yTo9iBJdi7qz
4nANOMFPK7JOy5npKN1iiousl28U/scUJES55gPwAWYJK3uVyQAsA4adgDKi5DoD1UHDQEwp
bY7iHLJeq0NPr4BqYNqnCFPbE6HC8zSJrr4qKn+gVUQT39SIFqdiIPJwZL8FYTRQ/zsCAwEA
AaOCAbYwggGyMAsGA1UdDwQEAwIHgDArBgNVHRAEJDAigA8yMDEwMDYxMTE4MjIwNlqBDzIw
MTIwNzE3MjI1MjA2WjAbBg0rBgEEAbMlCwMBAQEBBAoWCGZpb3JhbWUxMBsGDSsGAQQBsyUL
AwEBAQIEChIIMDAxMDQyNjEwWAYJYIZIAYb6ax4BBEsMSVRoZSBwcml2YXRlIGtleSBjb3Jy
ZXNwb25kaW5nIHRvIHRoaXMgY2VydGlmaWNhdGUgbWF5IGhhdmUgYmVlbiBleHBvcnRlZC4w
KAYDVR0RBCEwH4EdTWF0dGhldy5GaW9yYXZhbnRlQGpodWFwbC5lZHUwUgYDVR0fBEswSTBH
oEWgQ6RBMD8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJU0RD
QTEOMAwGA1UEAxMFQ1JMNTYwHwYDVR0jBBgwFoAUCDUpmxH52EU2CyWmF2EJMB1yqeswHQYD
VR0OBBYEFO6LYxg6r9wHZ+zdQtBHn1dZ/YTNMAkGA1UdEwQCMAAwGQYJKoZIhvZ9B0EABAww
ChsEVjcuMQMCBLAwDQYJKoZIhvcNAQEFBQADgYEAJO9HQh4YNChVLzuZqK5ARJARD8JoujGZ
fdo75quvg2jXFQe2sEjvLnxJZgm/pv8fdZakq48CWwjYHKuvIp7sDjTEsQfo+y7SpN/N2NvJ
WU5SqfK1VgYtNLRRoGJUB5Q1aZ+Dg95g3kqpyfpUMISJL8IKVLtJVfN4fggFVUYZ9wwxggGr
MIIBpwIBATA3MC8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJ
U0RDQQIEP/HJ/TAJBgUrDgMCGgUAoIHLMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ
KoZIhvcNAQkFMQ8XDTEyMDkxNzIxNTU0M1owIwYJKoZIhvcNAQkEMRYEFDvEVJ+7mr9gWF47
Pl6XCN7hsc/6MGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAK
BggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI
KoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEgYCOw5U4S79Ne/L0S2QV6bOkbuIPhe1B2rRG
y7u16x6C8b8TJKKDoVHlJeFDvuUdVeS7hK5eTkYom2BDl6xt/+6JYoQm7nkLbBhQG1hElGCy
1P2m9WyF/oul4khcKGONe9UazxdH4JRG4MYwEHHR8aSX4995Dx4MtzK/scz7d5LnAQAAAAAA
AA==
--------------ms030904070101060306020108--


--===============6453934534774364880==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============6453934534774364880==--


From xen-devel-bounces@lists.xen.org Mon Sep 17 21:58:58 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 21: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 1TDjL3-0001SY-Hu; Mon, 17 Sep 2012 21:58:45 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <matthew.fioravante@jhuapl.edu>) id 1TDjL1-0001SM-QL
	for xen-devel@lists.xensource.com; Mon, 17 Sep 2012 21:58:44 +0000
Received: from [85.158.138.51:11656] by server-12.bemta-3.messagelabs.com id
	7A/17-10384-31D97505; Mon, 17 Sep 2012 21:58:43 +0000
X-Env-Sender: matthew.fioravante@jhuapl.edu
X-Msg-Ref: server-16.tower-174.messagelabs.com!1347919120!30845645!1
X-Originating-IP: [128.244.251.36]
X-SpamReason: No, hits=0.0 required=7.0 tests=UNPARSEABLE_RELAY
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16634 invoked from network); 17 Sep 2012 21:58:41 -0000
Received: from pilot.jhuapl.edu (HELO jhuapl.edu) (128.244.251.36)
	by server-16.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 17 Sep 2012 21:58:41 -0000
Received: from ([128.244.207.89])
	by pilot.jhuapl.edu with ESMTP with TLS id 63GHCH1.153075615;
	Mon, 17 Sep 2012 17:58:26 -0400
Message-ID: <50579CB7.1010707@jhuapl.edu>
Date: Mon, 17 Sep 2012 17:57:11 -0400
From: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120827 Thunderbird/15.0
MIME-Version: 1.0
To: Samuel Thibault <samuel.thibault@ens-lyon.org>, 
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
X-Enigmail-Version: 1.4.4
Subject: [Xen-devel] [PATCH mini-os enhancements for vtpm 3/8] add endian
	support to mini-os
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============7085357906659809616=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a cryptographically signed message in MIME format.

--===============7085357906659809616==
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms070602050804030406000602"

This is a cryptographically signed message in MIME format.

--------------ms070602050804030406000602
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

This patch addes byte swapping macros and endian support to mini-os

Signed off by: Matthew Fioravante matthew.fioravante@jhuapl.edu

diff --git a/extras/mini-os/include/byteorder.h
b/extras/mini-os/include/byteorder.h
--- /dev/null
+++ b/extras/mini-os/include/byteorder.h
@@ -0,0 +1,36 @@
+#ifndef MINIOS_BYTEORDER_H
+#define MINIOS_BYTEORDER_H
+
+#include <mini-os/byteswap.h>
+#include <mini-os/endian.h>
+
+#if __BYTE_ORDER =3D=3D __LITTLE_ENDIAN
+#define be16_to_cpu(v) bswap_16(v)
+#define be32_to_cpu(v) bswap_32(v)
+#define be64_to_cpu(v) bswap_64(v)
+
+#define le16_to_cpu(v) (v)
+#define le32_to_cpu(v) (v)
+#define le64_to_cpu(v) (v)
+
+#else /*__BIG_ENDIAN*/
+#define be16_to_cpu(v) (v)
+#define be32_to_cpu(v) (v)
+#define be64_to_cpu(v) (v)
+
+#define le16_to_cpu(v) bswap_16(v)
+#define le32_to_cpu(v) bswap_32(v)
+#define le64_to_cpu(v) bswap_64(v)
+
+#endif
+
+#define cpu_to_be16(v) be16_to_cpu(v)
+#define cpu_to_be32(v) be32_to_cpu(v)
+#define cpu_to_be64(v) be64_to_cpu(v)
+
+#define cpu_to_le16(v) le16_to_cpu(v)
+#define cpu_to_le32(v) le32_to_cpu(v)
+#define cpu_to_le64(v) le64_to_cpu(v)
+
+
+#endif
diff --git a/extras/mini-os/include/byteswap.h
b/extras/mini-os/include/byteswap.h
--- a/extras/mini-os/include/byteswap.h
+++ b/extras/mini-os/include/byteswap.h
@@ -4,30 +4,36 @@
 /* Unfortunately not provided by newlib.  */
=20
 #include <mini-os/types.h>
-static inline uint16_t bswap_16(uint16_t x)
-{
-    return
-    ((((x) & 0xff00) >> 8) | (((x) & 0xff) << 8));
-}
-
-static inline uint32_t bswap_32(uint32_t x)
-{
-    return
-    ((((x) & 0xff000000) >> 24) | (((x) & 0x00ff0000) >>  8) |
-     (((x) & 0x0000ff00) <<  8) | (((x) & 0x000000ff) << 24));
-}
-
-static inline uint64_t bswap_64(uint64_t x)
-{
-    return
-    ((((x) & 0xff00000000000000ULL) >> 56) |
-     (((x) & 0x00ff000000000000ULL) >> 40) |
-     (((x) & 0x0000ff0000000000ULL) >> 24) |
-     (((x) & 0x000000ff00000000ULL) >>  8) |
-     (((x) & 0x00000000ff000000ULL) <<  8) |
-     (((x) & 0x0000000000ff0000ULL) << 24) |
-     (((x) & 0x000000000000ff00ULL) << 40) |
-     (((x) & 0x00000000000000ffULL) << 56));
-}
+
+#define bswap_16(x) ((uint16_t)(                         \
+             (((uint16_t)(x) & (uint16_t)0x00ffU) << 8)
|                  \
+             (((uint16_t)(x) & (uint16_t)0xff00U) >> 8)))
+
+/* Use gcc optimized versions if they exist */
+#if __GNUC__ > 4 || (__GNUC__ =3D=3D 4 && __GNUC_MINOR__ >=3D 3)
+#define bswap_32(v) __builtin_bswap32(v)
+#define bswap_64(v) __builtin_bswap64(v)
+#else
+
+#define bswap_32(x) ((uint32_t)(                         \
+             (((uint32_t)(x) & (uint32_t)0x000000ffUL) << 24)
|            \
+             (((uint32_t)(x) & (uint32_t)0x0000ff00UL) <<  8)
|            \
+             (((uint32_t)(x) & (uint32_t)0x00ff0000UL) >>  8)
|            \
+             (((uint32_t)(x) & (uint32_t)0xff000000UL) >> 24)))
+
+#define bswap_64(x) ((uint64_t)(                         \
+             (((uint64_t)(x) & (uint64_t)0x00000000000000ffULL) << 56)
|   \
+             (((uint64_t)(x) & (uint64_t)0x000000000000ff00ULL) << 40)
|   \
+             (((uint64_t)(x) & (uint64_t)0x0000000000ff0000ULL) << 24)
|   \
+             (((uint64_t)(x) & (uint64_t)0x00000000ff000000ULL) <<  8)
|   \
+             (((uint64_t)(x) & (uint64_t)0x000000ff00000000ULL) >>  8)
|   \
+             (((uint64_t)(x) & (uint64_t)0x0000ff0000000000ULL) >> 24)
|   \
+             (((uint64_t)(x) & (uint64_t)0x00ff000000000000ULL) >> 40)
|   \
+             (((uint64_t)(x) & (uint64_t)0xff00000000000000ULL) >> 56)))=

+
+#endif
+
+
+
=20
 #endif /* _BYTESWAP_H */
diff --git a/extras/mini-os/include/endian.h
b/extras/mini-os/include/endian.h
--- /dev/null
+++ b/extras/mini-os/include/endian.h
@@ -0,0 +1,15 @@
+#ifndef    _ENDIAN_H_
+#define    _ENDIAN_H_
+
+#define    __LITTLE_ENDIAN    1234
+#define    __BIG_ENDIAN    4321
+#define    __PDP_ENDIAN    3412
+
+#define ARCH_ENDIAN_H
+/* This will define __BYTE_ORDER for the current arch */
+#include <arch_endian.h>
+#undef ARCH_ENDIAN_H
+
+#include <arch_wordsize.h>
+
+#endif    /* endian.h */
diff --git a/extras/mini-os/include/ia64/arch_endian.h
b/extras/mini-os/include/ia64/arch_endian.h
--- /dev/null
+++ b/extras/mini-os/include/ia64/arch_endian.h
@@ -0,0 +1,7 @@
+#ifndef    ARCH_ENDIAN_H
+#error "Do not include arch_endian by itself, include endian.h"
+#else
+
+#define __BYTE_ORDER __LITTLE_ENDIAN
+
+#endif
diff --git a/extras/mini-os/include/ia64/arch_wordsize.h
b/extras/mini-os/include/ia64/arch_wordsize.h
--- /dev/null
+++ b/extras/mini-os/include/ia64/arch_wordsize.h
@@ -0,0 +1 @@
+#define __WORDSIZE 64
diff --git a/extras/mini-os/include/x86/arch_endian.h
b/extras/mini-os/include/x86/arch_endian.h
--- /dev/null
+++ b/extras/mini-os/include/x86/arch_endian.h
@@ -0,0 +1,7 @@
+#ifndef    ARCH_ENDIAN_H
+#error "Do not include arch_endian by itself, include endian.h"
+#else
+
+#define __BYTE_ORDER __LITTLE_ENDIAN
+
+#endif
diff --git a/extras/mini-os/include/x86/x86_32/arch_wordsize.h
b/extras/mini-os/include/x86/x86_32/arch_wordsize.h
--- /dev/null
+++ b/extras/mini-os/include/x86/x86_32/arch_wordsize.h
@@ -0,0 +1 @@
+#define __WORDSIZE 32
diff --git a/extras/mini-os/include/x86/x86_64/arch_wordsize.h
b/extras/mini-os/include/x86/x86_64/arch_wordsize.h
--- /dev/null
+++ b/extras/mini-os/include/x86/x86_64/arch_wordsize.h
@@ -0,0 +1,2 @@
+#define __WORDSIZE 64
+#define __WORDSIZE_COMPAT32 1




--------------ms070602050804030406000602
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIDyjCC
A8YwggMvoAMCAQICBD/xyf0wDQYJKoZIhvcNAQEFBQAwLzELMAkGA1UEBhMCVVMxDzANBgNV
BAoTBkpIVUFQTDEPMA0GA1UECxMGQklTRENBMB4XDTEwMDYxMTE4MjIwNloXDTEzMDYxMTE4
NTIwNlowZjELMAkGA1UEBhMCVVMxDzANBgNVBAoTBkpIVUFQTDEPMA0GA1UECxMGUGVvcGxl
MTUwFgYDVQQLEw9WUE5Hcm91cC1CSVNEQ0EwGwYDVQQDExRNYXR0aGV3IEUgRmlvcmF2YW50
ZTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAnpbwVSP6o1Nb5lcW7dd3yTo9iBJdi7qz
4nANOMFPK7JOy5npKN1iiousl28U/scUJES55gPwAWYJK3uVyQAsA4adgDKi5DoD1UHDQEwp
bY7iHLJeq0NPr4BqYNqnCFPbE6HC8zSJrr4qKn+gVUQT39SIFqdiIPJwZL8FYTRQ/zsCAwEA
AaOCAbYwggGyMAsGA1UdDwQEAwIHgDArBgNVHRAEJDAigA8yMDEwMDYxMTE4MjIwNlqBDzIw
MTIwNzE3MjI1MjA2WjAbBg0rBgEEAbMlCwMBAQEBBAoWCGZpb3JhbWUxMBsGDSsGAQQBsyUL
AwEBAQIEChIIMDAxMDQyNjEwWAYJYIZIAYb6ax4BBEsMSVRoZSBwcml2YXRlIGtleSBjb3Jy
ZXNwb25kaW5nIHRvIHRoaXMgY2VydGlmaWNhdGUgbWF5IGhhdmUgYmVlbiBleHBvcnRlZC4w
KAYDVR0RBCEwH4EdTWF0dGhldy5GaW9yYXZhbnRlQGpodWFwbC5lZHUwUgYDVR0fBEswSTBH
oEWgQ6RBMD8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJU0RD
QTEOMAwGA1UEAxMFQ1JMNTYwHwYDVR0jBBgwFoAUCDUpmxH52EU2CyWmF2EJMB1yqeswHQYD
VR0OBBYEFO6LYxg6r9wHZ+zdQtBHn1dZ/YTNMAkGA1UdEwQCMAAwGQYJKoZIhvZ9B0EABAww
ChsEVjcuMQMCBLAwDQYJKoZIhvcNAQEFBQADgYEAJO9HQh4YNChVLzuZqK5ARJARD8JoujGZ
fdo75quvg2jXFQe2sEjvLnxJZgm/pv8fdZakq48CWwjYHKuvIp7sDjTEsQfo+y7SpN/N2NvJ
WU5SqfK1VgYtNLRRoGJUB5Q1aZ+Dg95g3kqpyfpUMISJL8IKVLtJVfN4fggFVUYZ9wwxggGr
MIIBpwIBATA3MC8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJ
U0RDQQIEP/HJ/TAJBgUrDgMCGgUAoIHLMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ
KoZIhvcNAQkFMQ8XDTEyMDkxNzIxNTcxMVowIwYJKoZIhvcNAQkEMRYEFDFnFmcOtKFqnrbP
aCH+sr/bQF4xMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAK
BggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI
KoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEgYAqblOP2cx9G6BI1vdDLUVHeo0C74TMyLrP
dT556ICer89ge8gWVIqC6sihsxZOmJ5NnFJB3uqT4654Smeu1eloktAYLxWO3UhKZ0TyEOy4
sYggNBqo9Tr2/dCEqyFeHZEqoNFnlMZ6cv4ylCw51ZlYzFsyZ7pCqTR95804NuaMDwAAAAAA
AA==
--------------ms070602050804030406000602--


--===============7085357906659809616==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============7085357906659809616==--


From xen-devel-bounces@lists.xen.org Mon Sep 17 21:58:58 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 21: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 1TDjL3-0001SY-Hu; Mon, 17 Sep 2012 21:58:45 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <matthew.fioravante@jhuapl.edu>) id 1TDjL1-0001SM-QL
	for xen-devel@lists.xensource.com; Mon, 17 Sep 2012 21:58:44 +0000
Received: from [85.158.138.51:11656] by server-12.bemta-3.messagelabs.com id
	7A/17-10384-31D97505; Mon, 17 Sep 2012 21:58:43 +0000
X-Env-Sender: matthew.fioravante@jhuapl.edu
X-Msg-Ref: server-16.tower-174.messagelabs.com!1347919120!30845645!1
X-Originating-IP: [128.244.251.36]
X-SpamReason: No, hits=0.0 required=7.0 tests=UNPARSEABLE_RELAY
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16634 invoked from network); 17 Sep 2012 21:58:41 -0000
Received: from pilot.jhuapl.edu (HELO jhuapl.edu) (128.244.251.36)
	by server-16.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 17 Sep 2012 21:58:41 -0000
Received: from ([128.244.207.89])
	by pilot.jhuapl.edu with ESMTP with TLS id 63GHCH1.153075615;
	Mon, 17 Sep 2012 17:58:26 -0400
Message-ID: <50579CB7.1010707@jhuapl.edu>
Date: Mon, 17 Sep 2012 17:57:11 -0400
From: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120827 Thunderbird/15.0
MIME-Version: 1.0
To: Samuel Thibault <samuel.thibault@ens-lyon.org>, 
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
X-Enigmail-Version: 1.4.4
Subject: [Xen-devel] [PATCH mini-os enhancements for vtpm 3/8] add endian
	support to mini-os
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============7085357906659809616=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a cryptographically signed message in MIME format.

--===============7085357906659809616==
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms070602050804030406000602"

This is a cryptographically signed message in MIME format.

--------------ms070602050804030406000602
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

This patch addes byte swapping macros and endian support to mini-os

Signed off by: Matthew Fioravante matthew.fioravante@jhuapl.edu

diff --git a/extras/mini-os/include/byteorder.h
b/extras/mini-os/include/byteorder.h
--- /dev/null
+++ b/extras/mini-os/include/byteorder.h
@@ -0,0 +1,36 @@
+#ifndef MINIOS_BYTEORDER_H
+#define MINIOS_BYTEORDER_H
+
+#include <mini-os/byteswap.h>
+#include <mini-os/endian.h>
+
+#if __BYTE_ORDER =3D=3D __LITTLE_ENDIAN
+#define be16_to_cpu(v) bswap_16(v)
+#define be32_to_cpu(v) bswap_32(v)
+#define be64_to_cpu(v) bswap_64(v)
+
+#define le16_to_cpu(v) (v)
+#define le32_to_cpu(v) (v)
+#define le64_to_cpu(v) (v)
+
+#else /*__BIG_ENDIAN*/
+#define be16_to_cpu(v) (v)
+#define be32_to_cpu(v) (v)
+#define be64_to_cpu(v) (v)
+
+#define le16_to_cpu(v) bswap_16(v)
+#define le32_to_cpu(v) bswap_32(v)
+#define le64_to_cpu(v) bswap_64(v)
+
+#endif
+
+#define cpu_to_be16(v) be16_to_cpu(v)
+#define cpu_to_be32(v) be32_to_cpu(v)
+#define cpu_to_be64(v) be64_to_cpu(v)
+
+#define cpu_to_le16(v) le16_to_cpu(v)
+#define cpu_to_le32(v) le32_to_cpu(v)
+#define cpu_to_le64(v) le64_to_cpu(v)
+
+
+#endif
diff --git a/extras/mini-os/include/byteswap.h
b/extras/mini-os/include/byteswap.h
--- a/extras/mini-os/include/byteswap.h
+++ b/extras/mini-os/include/byteswap.h
@@ -4,30 +4,36 @@
 /* Unfortunately not provided by newlib.  */
=20
 #include <mini-os/types.h>
-static inline uint16_t bswap_16(uint16_t x)
-{
-    return
-    ((((x) & 0xff00) >> 8) | (((x) & 0xff) << 8));
-}
-
-static inline uint32_t bswap_32(uint32_t x)
-{
-    return
-    ((((x) & 0xff000000) >> 24) | (((x) & 0x00ff0000) >>  8) |
-     (((x) & 0x0000ff00) <<  8) | (((x) & 0x000000ff) << 24));
-}
-
-static inline uint64_t bswap_64(uint64_t x)
-{
-    return
-    ((((x) & 0xff00000000000000ULL) >> 56) |
-     (((x) & 0x00ff000000000000ULL) >> 40) |
-     (((x) & 0x0000ff0000000000ULL) >> 24) |
-     (((x) & 0x000000ff00000000ULL) >>  8) |
-     (((x) & 0x00000000ff000000ULL) <<  8) |
-     (((x) & 0x0000000000ff0000ULL) << 24) |
-     (((x) & 0x000000000000ff00ULL) << 40) |
-     (((x) & 0x00000000000000ffULL) << 56));
-}
+
+#define bswap_16(x) ((uint16_t)(                         \
+             (((uint16_t)(x) & (uint16_t)0x00ffU) << 8)
|                  \
+             (((uint16_t)(x) & (uint16_t)0xff00U) >> 8)))
+
+/* Use gcc optimized versions if they exist */
+#if __GNUC__ > 4 || (__GNUC__ =3D=3D 4 && __GNUC_MINOR__ >=3D 3)
+#define bswap_32(v) __builtin_bswap32(v)
+#define bswap_64(v) __builtin_bswap64(v)
+#else
+
+#define bswap_32(x) ((uint32_t)(                         \
+             (((uint32_t)(x) & (uint32_t)0x000000ffUL) << 24)
|            \
+             (((uint32_t)(x) & (uint32_t)0x0000ff00UL) <<  8)
|            \
+             (((uint32_t)(x) & (uint32_t)0x00ff0000UL) >>  8)
|            \
+             (((uint32_t)(x) & (uint32_t)0xff000000UL) >> 24)))
+
+#define bswap_64(x) ((uint64_t)(                         \
+             (((uint64_t)(x) & (uint64_t)0x00000000000000ffULL) << 56)
|   \
+             (((uint64_t)(x) & (uint64_t)0x000000000000ff00ULL) << 40)
|   \
+             (((uint64_t)(x) & (uint64_t)0x0000000000ff0000ULL) << 24)
|   \
+             (((uint64_t)(x) & (uint64_t)0x00000000ff000000ULL) <<  8)
|   \
+             (((uint64_t)(x) & (uint64_t)0x000000ff00000000ULL) >>  8)
|   \
+             (((uint64_t)(x) & (uint64_t)0x0000ff0000000000ULL) >> 24)
|   \
+             (((uint64_t)(x) & (uint64_t)0x00ff000000000000ULL) >> 40)
|   \
+             (((uint64_t)(x) & (uint64_t)0xff00000000000000ULL) >> 56)))=

+
+#endif
+
+
+
=20
 #endif /* _BYTESWAP_H */
diff --git a/extras/mini-os/include/endian.h
b/extras/mini-os/include/endian.h
--- /dev/null
+++ b/extras/mini-os/include/endian.h
@@ -0,0 +1,15 @@
+#ifndef    _ENDIAN_H_
+#define    _ENDIAN_H_
+
+#define    __LITTLE_ENDIAN    1234
+#define    __BIG_ENDIAN    4321
+#define    __PDP_ENDIAN    3412
+
+#define ARCH_ENDIAN_H
+/* This will define __BYTE_ORDER for the current arch */
+#include <arch_endian.h>
+#undef ARCH_ENDIAN_H
+
+#include <arch_wordsize.h>
+
+#endif    /* endian.h */
diff --git a/extras/mini-os/include/ia64/arch_endian.h
b/extras/mini-os/include/ia64/arch_endian.h
--- /dev/null
+++ b/extras/mini-os/include/ia64/arch_endian.h
@@ -0,0 +1,7 @@
+#ifndef    ARCH_ENDIAN_H
+#error "Do not include arch_endian by itself, include endian.h"
+#else
+
+#define __BYTE_ORDER __LITTLE_ENDIAN
+
+#endif
diff --git a/extras/mini-os/include/ia64/arch_wordsize.h
b/extras/mini-os/include/ia64/arch_wordsize.h
--- /dev/null
+++ b/extras/mini-os/include/ia64/arch_wordsize.h
@@ -0,0 +1 @@
+#define __WORDSIZE 64
diff --git a/extras/mini-os/include/x86/arch_endian.h
b/extras/mini-os/include/x86/arch_endian.h
--- /dev/null
+++ b/extras/mini-os/include/x86/arch_endian.h
@@ -0,0 +1,7 @@
+#ifndef    ARCH_ENDIAN_H
+#error "Do not include arch_endian by itself, include endian.h"
+#else
+
+#define __BYTE_ORDER __LITTLE_ENDIAN
+
+#endif
diff --git a/extras/mini-os/include/x86/x86_32/arch_wordsize.h
b/extras/mini-os/include/x86/x86_32/arch_wordsize.h
--- /dev/null
+++ b/extras/mini-os/include/x86/x86_32/arch_wordsize.h
@@ -0,0 +1 @@
+#define __WORDSIZE 32
diff --git a/extras/mini-os/include/x86/x86_64/arch_wordsize.h
b/extras/mini-os/include/x86/x86_64/arch_wordsize.h
--- /dev/null
+++ b/extras/mini-os/include/x86/x86_64/arch_wordsize.h
@@ -0,0 +1,2 @@
+#define __WORDSIZE 64
+#define __WORDSIZE_COMPAT32 1




--------------ms070602050804030406000602
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIDyjCC
A8YwggMvoAMCAQICBD/xyf0wDQYJKoZIhvcNAQEFBQAwLzELMAkGA1UEBhMCVVMxDzANBgNV
BAoTBkpIVUFQTDEPMA0GA1UECxMGQklTRENBMB4XDTEwMDYxMTE4MjIwNloXDTEzMDYxMTE4
NTIwNlowZjELMAkGA1UEBhMCVVMxDzANBgNVBAoTBkpIVUFQTDEPMA0GA1UECxMGUGVvcGxl
MTUwFgYDVQQLEw9WUE5Hcm91cC1CSVNEQ0EwGwYDVQQDExRNYXR0aGV3IEUgRmlvcmF2YW50
ZTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAnpbwVSP6o1Nb5lcW7dd3yTo9iBJdi7qz
4nANOMFPK7JOy5npKN1iiousl28U/scUJES55gPwAWYJK3uVyQAsA4adgDKi5DoD1UHDQEwp
bY7iHLJeq0NPr4BqYNqnCFPbE6HC8zSJrr4qKn+gVUQT39SIFqdiIPJwZL8FYTRQ/zsCAwEA
AaOCAbYwggGyMAsGA1UdDwQEAwIHgDArBgNVHRAEJDAigA8yMDEwMDYxMTE4MjIwNlqBDzIw
MTIwNzE3MjI1MjA2WjAbBg0rBgEEAbMlCwMBAQEBBAoWCGZpb3JhbWUxMBsGDSsGAQQBsyUL
AwEBAQIEChIIMDAxMDQyNjEwWAYJYIZIAYb6ax4BBEsMSVRoZSBwcml2YXRlIGtleSBjb3Jy
ZXNwb25kaW5nIHRvIHRoaXMgY2VydGlmaWNhdGUgbWF5IGhhdmUgYmVlbiBleHBvcnRlZC4w
KAYDVR0RBCEwH4EdTWF0dGhldy5GaW9yYXZhbnRlQGpodWFwbC5lZHUwUgYDVR0fBEswSTBH
oEWgQ6RBMD8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJU0RD
QTEOMAwGA1UEAxMFQ1JMNTYwHwYDVR0jBBgwFoAUCDUpmxH52EU2CyWmF2EJMB1yqeswHQYD
VR0OBBYEFO6LYxg6r9wHZ+zdQtBHn1dZ/YTNMAkGA1UdEwQCMAAwGQYJKoZIhvZ9B0EABAww
ChsEVjcuMQMCBLAwDQYJKoZIhvcNAQEFBQADgYEAJO9HQh4YNChVLzuZqK5ARJARD8JoujGZ
fdo75quvg2jXFQe2sEjvLnxJZgm/pv8fdZakq48CWwjYHKuvIp7sDjTEsQfo+y7SpN/N2NvJ
WU5SqfK1VgYtNLRRoGJUB5Q1aZ+Dg95g3kqpyfpUMISJL8IKVLtJVfN4fggFVUYZ9wwxggGr
MIIBpwIBATA3MC8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJ
U0RDQQIEP/HJ/TAJBgUrDgMCGgUAoIHLMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ
KoZIhvcNAQkFMQ8XDTEyMDkxNzIxNTcxMVowIwYJKoZIhvcNAQkEMRYEFDFnFmcOtKFqnrbP
aCH+sr/bQF4xMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAK
BggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI
KoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEgYAqblOP2cx9G6BI1vdDLUVHeo0C74TMyLrP
dT556ICer89ge8gWVIqC6sihsxZOmJ5NnFJB3uqT4654Smeu1eloktAYLxWO3UhKZ0TyEOy4
sYggNBqo9Tr2/dCEqyFeHZEqoNFnlMZ6cv4ylCw51ZlYzFsyZ7pCqTR95804NuaMDwAAAAAA
AA==
--------------ms070602050804030406000602--


--===============7085357906659809616==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============7085357906659809616==--


From xen-devel-bounces@lists.xen.org Mon Sep 17 22:00:21 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 22:00:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDjMM-0001b8-1a; Mon, 17 Sep 2012 22:00:06 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <matthew.fioravante@jhuapl.edu>) id 1TDjMK-0001b1-BQ
	for xen-devel@lists.xensource.com; Mon, 17 Sep 2012 22:00:04 +0000
Received: from [85.158.137.99:32962] by server-3.bemta-3.messagelabs.com id
	4D/F5-21322-36D97505; Mon, 17 Sep 2012 22:00:03 +0000
X-Env-Sender: matthew.fioravante@jhuapl.edu
X-Msg-Ref: server-2.tower-217.messagelabs.com!1347919201!17938702!1
X-Originating-IP: [128.244.251.36]
X-SpamReason: No, hits=0.0 required=7.0 tests=UNPARSEABLE_RELAY
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7329 invoked from network); 17 Sep 2012 22:00:02 -0000
Received: from pilot.jhuapl.edu (HELO jhuapl.edu) (128.244.251.36)
	by server-2.tower-217.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 17 Sep 2012 22:00:02 -0000
Received: from ([128.244.207.89])
	by pilot.jhuapl.edu with ESMTP with TLS id 63GHCH1.153075650;
	Mon, 17 Sep 2012 17:59:46 -0400
Message-ID: <50579D07.3030007@jhuapl.edu>
Date: Mon, 17 Sep 2012 17:58:31 -0400
From: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120827 Thunderbird/15.0
MIME-Version: 1.0
To: Samuel Thibault <samuel.thibault@ens-lyon.org>, 
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
X-Enigmail-Version: 1.4.4
Subject: [Xen-devel] [PATCH mini-os enhancements for vtpm 4/8] disable
	mfn_is_ram
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============2559462095349427433=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a cryptographically signed message in MIME format.

--===============2559462095349427433==
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms090605070103090501030000"

This is a cryptographically signed message in MIME format.

--------------ms090605070103090501030000
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

This patch disables the mfn_is_ram check in mini-os. The current check
is insufficient and fails on some systems with larger than 4gb memory.


diff --git a/extras/mini-os/arch/x86/mm.c b/extras/mini-os/arch/x86/mm.c
--- a/extras/mini-os/arch/x86/mm.c
+++ b/extras/mini-os/arch/x86/mm.c
@@ -850,6 +850,8 @@ unsigned long alloc_contig_pages(int order, unsigned
int addr_bits)
 static long system_ram_end_mfn;
 int mfn_is_ram(unsigned long mfn)
 {
+   /* This is broken on systems with large ammounts of ram. Always
return 0 for now */
+    return 0;
     /* very crude check if a given MFN is memory or not. Probably should=

      * make this a little more sophisticated ;) */
     return (mfn <=3D system_ram_end_mfn) ? 1 : 0;


--------------ms090605070103090501030000
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIDyjCC
A8YwggMvoAMCAQICBD/xyf0wDQYJKoZIhvcNAQEFBQAwLzELMAkGA1UEBhMCVVMxDzANBgNV
BAoTBkpIVUFQTDEPMA0GA1UECxMGQklTRENBMB4XDTEwMDYxMTE4MjIwNloXDTEzMDYxMTE4
NTIwNlowZjELMAkGA1UEBhMCVVMxDzANBgNVBAoTBkpIVUFQTDEPMA0GA1UECxMGUGVvcGxl
MTUwFgYDVQQLEw9WUE5Hcm91cC1CSVNEQ0EwGwYDVQQDExRNYXR0aGV3IEUgRmlvcmF2YW50
ZTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAnpbwVSP6o1Nb5lcW7dd3yTo9iBJdi7qz
4nANOMFPK7JOy5npKN1iiousl28U/scUJES55gPwAWYJK3uVyQAsA4adgDKi5DoD1UHDQEwp
bY7iHLJeq0NPr4BqYNqnCFPbE6HC8zSJrr4qKn+gVUQT39SIFqdiIPJwZL8FYTRQ/zsCAwEA
AaOCAbYwggGyMAsGA1UdDwQEAwIHgDArBgNVHRAEJDAigA8yMDEwMDYxMTE4MjIwNlqBDzIw
MTIwNzE3MjI1MjA2WjAbBg0rBgEEAbMlCwMBAQEBBAoWCGZpb3JhbWUxMBsGDSsGAQQBsyUL
AwEBAQIEChIIMDAxMDQyNjEwWAYJYIZIAYb6ax4BBEsMSVRoZSBwcml2YXRlIGtleSBjb3Jy
ZXNwb25kaW5nIHRvIHRoaXMgY2VydGlmaWNhdGUgbWF5IGhhdmUgYmVlbiBleHBvcnRlZC4w
KAYDVR0RBCEwH4EdTWF0dGhldy5GaW9yYXZhbnRlQGpodWFwbC5lZHUwUgYDVR0fBEswSTBH
oEWgQ6RBMD8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJU0RD
QTEOMAwGA1UEAxMFQ1JMNTYwHwYDVR0jBBgwFoAUCDUpmxH52EU2CyWmF2EJMB1yqeswHQYD
VR0OBBYEFO6LYxg6r9wHZ+zdQtBHn1dZ/YTNMAkGA1UdEwQCMAAwGQYJKoZIhvZ9B0EABAww
ChsEVjcuMQMCBLAwDQYJKoZIhvcNAQEFBQADgYEAJO9HQh4YNChVLzuZqK5ARJARD8JoujGZ
fdo75quvg2jXFQe2sEjvLnxJZgm/pv8fdZakq48CWwjYHKuvIp7sDjTEsQfo+y7SpN/N2NvJ
WU5SqfK1VgYtNLRRoGJUB5Q1aZ+Dg95g3kqpyfpUMISJL8IKVLtJVfN4fggFVUYZ9wwxggGr
MIIBpwIBATA3MC8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJ
U0RDQQIEP/HJ/TAJBgUrDgMCGgUAoIHLMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ
KoZIhvcNAQkFMQ8XDTEyMDkxNzIxNTgzMVowIwYJKoZIhvcNAQkEMRYEFCYJrdJNvPMF7bZS
Cs5Av8Cp+vBbMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAK
BggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI
KoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEgYCLcvb55kNaE5eRoDXySRiGFxPlz846vUJw
Yj2sq55Qsg2DjfEQlrFsyO/6bGMsCAYieA957l02rqYi3ncu0XWhEjxhaGwTNEhvtx3urWd0
0+ZoCHDTpYGVGSw637XXbj1EjJPps1gqjJncyOTM6V1pESxxNIp6dfJGxpecGcxK7QAAAAAA
AA==
--------------ms090605070103090501030000--


--===============2559462095349427433==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============2559462095349427433==--


From xen-devel-bounces@lists.xen.org Mon Sep 17 22:00:21 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 22:00:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDjMM-0001b8-1a; Mon, 17 Sep 2012 22:00:06 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <matthew.fioravante@jhuapl.edu>) id 1TDjMK-0001b1-BQ
	for xen-devel@lists.xensource.com; Mon, 17 Sep 2012 22:00:04 +0000
Received: from [85.158.137.99:32962] by server-3.bemta-3.messagelabs.com id
	4D/F5-21322-36D97505; Mon, 17 Sep 2012 22:00:03 +0000
X-Env-Sender: matthew.fioravante@jhuapl.edu
X-Msg-Ref: server-2.tower-217.messagelabs.com!1347919201!17938702!1
X-Originating-IP: [128.244.251.36]
X-SpamReason: No, hits=0.0 required=7.0 tests=UNPARSEABLE_RELAY
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7329 invoked from network); 17 Sep 2012 22:00:02 -0000
Received: from pilot.jhuapl.edu (HELO jhuapl.edu) (128.244.251.36)
	by server-2.tower-217.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 17 Sep 2012 22:00:02 -0000
Received: from ([128.244.207.89])
	by pilot.jhuapl.edu with ESMTP with TLS id 63GHCH1.153075650;
	Mon, 17 Sep 2012 17:59:46 -0400
Message-ID: <50579D07.3030007@jhuapl.edu>
Date: Mon, 17 Sep 2012 17:58:31 -0400
From: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120827 Thunderbird/15.0
MIME-Version: 1.0
To: Samuel Thibault <samuel.thibault@ens-lyon.org>, 
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
X-Enigmail-Version: 1.4.4
Subject: [Xen-devel] [PATCH mini-os enhancements for vtpm 4/8] disable
	mfn_is_ram
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============2559462095349427433=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a cryptographically signed message in MIME format.

--===============2559462095349427433==
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms090605070103090501030000"

This is a cryptographically signed message in MIME format.

--------------ms090605070103090501030000
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

This patch disables the mfn_is_ram check in mini-os. The current check
is insufficient and fails on some systems with larger than 4gb memory.


diff --git a/extras/mini-os/arch/x86/mm.c b/extras/mini-os/arch/x86/mm.c
--- a/extras/mini-os/arch/x86/mm.c
+++ b/extras/mini-os/arch/x86/mm.c
@@ -850,6 +850,8 @@ unsigned long alloc_contig_pages(int order, unsigned
int addr_bits)
 static long system_ram_end_mfn;
 int mfn_is_ram(unsigned long mfn)
 {
+   /* This is broken on systems with large ammounts of ram. Always
return 0 for now */
+    return 0;
     /* very crude check if a given MFN is memory or not. Probably should=

      * make this a little more sophisticated ;) */
     return (mfn <=3D system_ram_end_mfn) ? 1 : 0;


--------------ms090605070103090501030000
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIDyjCC
A8YwggMvoAMCAQICBD/xyf0wDQYJKoZIhvcNAQEFBQAwLzELMAkGA1UEBhMCVVMxDzANBgNV
BAoTBkpIVUFQTDEPMA0GA1UECxMGQklTRENBMB4XDTEwMDYxMTE4MjIwNloXDTEzMDYxMTE4
NTIwNlowZjELMAkGA1UEBhMCVVMxDzANBgNVBAoTBkpIVUFQTDEPMA0GA1UECxMGUGVvcGxl
MTUwFgYDVQQLEw9WUE5Hcm91cC1CSVNEQ0EwGwYDVQQDExRNYXR0aGV3IEUgRmlvcmF2YW50
ZTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAnpbwVSP6o1Nb5lcW7dd3yTo9iBJdi7qz
4nANOMFPK7JOy5npKN1iiousl28U/scUJES55gPwAWYJK3uVyQAsA4adgDKi5DoD1UHDQEwp
bY7iHLJeq0NPr4BqYNqnCFPbE6HC8zSJrr4qKn+gVUQT39SIFqdiIPJwZL8FYTRQ/zsCAwEA
AaOCAbYwggGyMAsGA1UdDwQEAwIHgDArBgNVHRAEJDAigA8yMDEwMDYxMTE4MjIwNlqBDzIw
MTIwNzE3MjI1MjA2WjAbBg0rBgEEAbMlCwMBAQEBBAoWCGZpb3JhbWUxMBsGDSsGAQQBsyUL
AwEBAQIEChIIMDAxMDQyNjEwWAYJYIZIAYb6ax4BBEsMSVRoZSBwcml2YXRlIGtleSBjb3Jy
ZXNwb25kaW5nIHRvIHRoaXMgY2VydGlmaWNhdGUgbWF5IGhhdmUgYmVlbiBleHBvcnRlZC4w
KAYDVR0RBCEwH4EdTWF0dGhldy5GaW9yYXZhbnRlQGpodWFwbC5lZHUwUgYDVR0fBEswSTBH
oEWgQ6RBMD8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJU0RD
QTEOMAwGA1UEAxMFQ1JMNTYwHwYDVR0jBBgwFoAUCDUpmxH52EU2CyWmF2EJMB1yqeswHQYD
VR0OBBYEFO6LYxg6r9wHZ+zdQtBHn1dZ/YTNMAkGA1UdEwQCMAAwGQYJKoZIhvZ9B0EABAww
ChsEVjcuMQMCBLAwDQYJKoZIhvcNAQEFBQADgYEAJO9HQh4YNChVLzuZqK5ARJARD8JoujGZ
fdo75quvg2jXFQe2sEjvLnxJZgm/pv8fdZakq48CWwjYHKuvIp7sDjTEsQfo+y7SpN/N2NvJ
WU5SqfK1VgYtNLRRoGJUB5Q1aZ+Dg95g3kqpyfpUMISJL8IKVLtJVfN4fggFVUYZ9wwxggGr
MIIBpwIBATA3MC8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJ
U0RDQQIEP/HJ/TAJBgUrDgMCGgUAoIHLMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ
KoZIhvcNAQkFMQ8XDTEyMDkxNzIxNTgzMVowIwYJKoZIhvcNAQkEMRYEFCYJrdJNvPMF7bZS
Cs5Av8Cp+vBbMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAK
BggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI
KoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEgYCLcvb55kNaE5eRoDXySRiGFxPlz846vUJw
Yj2sq55Qsg2DjfEQlrFsyO/6bGMsCAYieA957l02rqYi3ncu0XWhEjxhaGwTNEhvtx3urWd0
0+ZoCHDTpYGVGSw637XXbj1EjJPps1gqjJncyOTM6V1pESxxNIp6dfJGxpecGcxK7QAAAAAA
AA==
--------------ms090605070103090501030000--


--===============2559462095349427433==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============2559462095349427433==--


From xen-devel-bounces@lists.xen.org Mon Sep 17 22:02:17 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 22:02:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDjOH-0001lV-IY; Mon, 17 Sep 2012 22:02:05 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <matthew.fioravante@jhuapl.edu>) id 1TDjOG-0001lG-4x
	for xen-devel@lists.xensource.com; Mon, 17 Sep 2012 22:02:04 +0000
Received: from [85.158.139.83:10254] by server-3.bemta-5.messagelabs.com id
	27/B5-21836-BDD97505; Mon, 17 Sep 2012 22:02:03 +0000
X-Env-Sender: matthew.fioravante@jhuapl.edu
X-Msg-Ref: server-14.tower-182.messagelabs.com!1347919321!26657236!1
X-Originating-IP: [128.244.251.36]
X-SpamReason: No, hits=0.0 required=7.0 tests=UNPARSEABLE_RELAY
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32427 invoked from network); 17 Sep 2012 22:02:02 -0000
Received: from pilot.jhuapl.edu (HELO jhuapl.edu) (128.244.251.36)
	by server-14.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 17 Sep 2012 22:02:02 -0000
Received: from ([128.244.207.89])
	by pilot.jhuapl.edu with ESMTP with TLS id 63GHCH1.153075792;
	Mon, 17 Sep 2012 18:01:46 -0400
Message-ID: <50579D7F.7030100@jhuapl.edu>
Date: Mon, 17 Sep 2012 18:00:31 -0400
From: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120827 Thunderbird/15.0
MIME-Version: 1.0
To: Samuel Thibault <samuel.thibault@ens-lyon.org>, 
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
X-Enigmail-Version: 1.4.4
Subject: [Xen-devel] [PATCH mini-os enhancements for vtpm 5/8] add CONFIG_XC
	to mini-os
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============9126189459777269867=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a cryptographically signed message in MIME format.

--===============9126189459777269867==
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms080504080107020709010107"

This is a cryptographically signed message in MIME format.

--------------ms080504080107020709010107
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

This patch adds a CONFIG_XC option to mini-os, to allow conditional
support for libxc for mini-os domains.


Signed off by: Matthew Fioravante matthew.fioravante@jhuapl.edu

diff --git a/extras/mini-os/Makefile b/extras/mini-os/Makefile
--- a/extras/mini-os/Makefile
+++ b/extras/mini-os/Makefile
@@ -27,6 +27,7 @@ CONFIG_FBFRONT ?=3D y
 CONFIG_KBDFRONT ?=3D y
 CONFIG_CONSFRONT ?=3D y
 CONFIG_XENBUS ?=3D y
+CONFIG_XC ?=3Dy
 CONFIG_LWIP ?=3D $(lwip)
=20
 # Export config items as compiler directives
diff --git a/extras/mini-os/lib/sys.c b/extras/mini-os/lib/sys.c
--- a/extras/mini-os/lib/sys.c
+++ b/extras/mini-os/lib/sys.c
@@ -397,6 +397,7 @@ int close(int fd)
         return res;
     }
 #endif
+#ifdef CONFIG_XC
     case FTYPE_XC:
         minios_interface_close_fd(fd);
         return 0;
@@ -406,6 +407,7 @@ int close(int fd)
     case FTYPE_GNTMAP:
         minios_gnttab_close_fd(fd);
         return 0;
+#endif
 #ifdef CONFIG_NETFRONT
     case FTYPE_TAP:
         shutdown_netfront(files[fd].tap.dev);
@@ -1195,10 +1197,13 @@ void *mmap(void *start, size_t length, int prot,
int flags, int fd, off_t offset
=20
     if (fd =3D=3D -1)
         return map_zero(n, 1);
+#ifdef CONFIG_XC
     else if (files[fd].type =3D=3D FTYPE_XC) {
         unsigned long zero =3D 0;
         return map_frames_ex(&zero, n, 0, 0, 1, DOMID_SELF, NULL, 0);
-    } else if (files[fd].type =3D=3D FTYPE_MEM) {
+    }
+#endif
+    else if (files[fd].type =3D=3D FTYPE_MEM) {
         unsigned long first_mfn =3D offset >> PAGE_SHIFT;
         return map_frames_ex(&first_mfn, n, 0, 1, 1, DOMID_IO, NULL,
_PAGE_PRESENT|_PAGE_RW);
     } else ASSERT(0);
--=20
1.7.4.4



--------------ms080504080107020709010107
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIDyjCC
A8YwggMvoAMCAQICBD/xyf0wDQYJKoZIhvcNAQEFBQAwLzELMAkGA1UEBhMCVVMxDzANBgNV
BAoTBkpIVUFQTDEPMA0GA1UECxMGQklTRENBMB4XDTEwMDYxMTE4MjIwNloXDTEzMDYxMTE4
NTIwNlowZjELMAkGA1UEBhMCVVMxDzANBgNVBAoTBkpIVUFQTDEPMA0GA1UECxMGUGVvcGxl
MTUwFgYDVQQLEw9WUE5Hcm91cC1CSVNEQ0EwGwYDVQQDExRNYXR0aGV3IEUgRmlvcmF2YW50
ZTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAnpbwVSP6o1Nb5lcW7dd3yTo9iBJdi7qz
4nANOMFPK7JOy5npKN1iiousl28U/scUJES55gPwAWYJK3uVyQAsA4adgDKi5DoD1UHDQEwp
bY7iHLJeq0NPr4BqYNqnCFPbE6HC8zSJrr4qKn+gVUQT39SIFqdiIPJwZL8FYTRQ/zsCAwEA
AaOCAbYwggGyMAsGA1UdDwQEAwIHgDArBgNVHRAEJDAigA8yMDEwMDYxMTE4MjIwNlqBDzIw
MTIwNzE3MjI1MjA2WjAbBg0rBgEEAbMlCwMBAQEBBAoWCGZpb3JhbWUxMBsGDSsGAQQBsyUL
AwEBAQIEChIIMDAxMDQyNjEwWAYJYIZIAYb6ax4BBEsMSVRoZSBwcml2YXRlIGtleSBjb3Jy
ZXNwb25kaW5nIHRvIHRoaXMgY2VydGlmaWNhdGUgbWF5IGhhdmUgYmVlbiBleHBvcnRlZC4w
KAYDVR0RBCEwH4EdTWF0dGhldy5GaW9yYXZhbnRlQGpodWFwbC5lZHUwUgYDVR0fBEswSTBH
oEWgQ6RBMD8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJU0RD
QTEOMAwGA1UEAxMFQ1JMNTYwHwYDVR0jBBgwFoAUCDUpmxH52EU2CyWmF2EJMB1yqeswHQYD
VR0OBBYEFO6LYxg6r9wHZ+zdQtBHn1dZ/YTNMAkGA1UdEwQCMAAwGQYJKoZIhvZ9B0EABAww
ChsEVjcuMQMCBLAwDQYJKoZIhvcNAQEFBQADgYEAJO9HQh4YNChVLzuZqK5ARJARD8JoujGZ
fdo75quvg2jXFQe2sEjvLnxJZgm/pv8fdZakq48CWwjYHKuvIp7sDjTEsQfo+y7SpN/N2NvJ
WU5SqfK1VgYtNLRRoGJUB5Q1aZ+Dg95g3kqpyfpUMISJL8IKVLtJVfN4fggFVUYZ9wwxggGr
MIIBpwIBATA3MC8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJ
U0RDQQIEP/HJ/TAJBgUrDgMCGgUAoIHLMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ
KoZIhvcNAQkFMQ8XDTEyMDkxNzIyMDAzMVowIwYJKoZIhvcNAQkEMRYEFGvHtrloVieSv4U2
qa0Z1wlhj/URMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAK
BggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI
KoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEgYAy1byJcr9B/eUNfWUEEvdvwrQYV4vDn6iR
UBgg0Ghsly0J2uysE2hJUa+UQedb5sGMunbsg4kW+BRsW9ktQ66PSR2iKi0PVawlEvFRkk6R
tknQxb+WdPIFIsMEdh+6s8ma84SHySMosujmbILHM0iXCDTHF+VZXt+IusEkZyZAOgAAAAAA
AA==
--------------ms080504080107020709010107--


--===============9126189459777269867==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============9126189459777269867==--


From xen-devel-bounces@lists.xen.org Mon Sep 17 22:02:17 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 22:02:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDjOH-0001lV-IY; Mon, 17 Sep 2012 22:02:05 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <matthew.fioravante@jhuapl.edu>) id 1TDjOG-0001lG-4x
	for xen-devel@lists.xensource.com; Mon, 17 Sep 2012 22:02:04 +0000
Received: from [85.158.139.83:10254] by server-3.bemta-5.messagelabs.com id
	27/B5-21836-BDD97505; Mon, 17 Sep 2012 22:02:03 +0000
X-Env-Sender: matthew.fioravante@jhuapl.edu
X-Msg-Ref: server-14.tower-182.messagelabs.com!1347919321!26657236!1
X-Originating-IP: [128.244.251.36]
X-SpamReason: No, hits=0.0 required=7.0 tests=UNPARSEABLE_RELAY
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32427 invoked from network); 17 Sep 2012 22:02:02 -0000
Received: from pilot.jhuapl.edu (HELO jhuapl.edu) (128.244.251.36)
	by server-14.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 17 Sep 2012 22:02:02 -0000
Received: from ([128.244.207.89])
	by pilot.jhuapl.edu with ESMTP with TLS id 63GHCH1.153075792;
	Mon, 17 Sep 2012 18:01:46 -0400
Message-ID: <50579D7F.7030100@jhuapl.edu>
Date: Mon, 17 Sep 2012 18:00:31 -0400
From: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120827 Thunderbird/15.0
MIME-Version: 1.0
To: Samuel Thibault <samuel.thibault@ens-lyon.org>, 
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
X-Enigmail-Version: 1.4.4
Subject: [Xen-devel] [PATCH mini-os enhancements for vtpm 5/8] add CONFIG_XC
	to mini-os
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============9126189459777269867=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a cryptographically signed message in MIME format.

--===============9126189459777269867==
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms080504080107020709010107"

This is a cryptographically signed message in MIME format.

--------------ms080504080107020709010107
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

This patch adds a CONFIG_XC option to mini-os, to allow conditional
support for libxc for mini-os domains.


Signed off by: Matthew Fioravante matthew.fioravante@jhuapl.edu

diff --git a/extras/mini-os/Makefile b/extras/mini-os/Makefile
--- a/extras/mini-os/Makefile
+++ b/extras/mini-os/Makefile
@@ -27,6 +27,7 @@ CONFIG_FBFRONT ?=3D y
 CONFIG_KBDFRONT ?=3D y
 CONFIG_CONSFRONT ?=3D y
 CONFIG_XENBUS ?=3D y
+CONFIG_XC ?=3Dy
 CONFIG_LWIP ?=3D $(lwip)
=20
 # Export config items as compiler directives
diff --git a/extras/mini-os/lib/sys.c b/extras/mini-os/lib/sys.c
--- a/extras/mini-os/lib/sys.c
+++ b/extras/mini-os/lib/sys.c
@@ -397,6 +397,7 @@ int close(int fd)
         return res;
     }
 #endif
+#ifdef CONFIG_XC
     case FTYPE_XC:
         minios_interface_close_fd(fd);
         return 0;
@@ -406,6 +407,7 @@ int close(int fd)
     case FTYPE_GNTMAP:
         minios_gnttab_close_fd(fd);
         return 0;
+#endif
 #ifdef CONFIG_NETFRONT
     case FTYPE_TAP:
         shutdown_netfront(files[fd].tap.dev);
@@ -1195,10 +1197,13 @@ void *mmap(void *start, size_t length, int prot,
int flags, int fd, off_t offset
=20
     if (fd =3D=3D -1)
         return map_zero(n, 1);
+#ifdef CONFIG_XC
     else if (files[fd].type =3D=3D FTYPE_XC) {
         unsigned long zero =3D 0;
         return map_frames_ex(&zero, n, 0, 0, 1, DOMID_SELF, NULL, 0);
-    } else if (files[fd].type =3D=3D FTYPE_MEM) {
+    }
+#endif
+    else if (files[fd].type =3D=3D FTYPE_MEM) {
         unsigned long first_mfn =3D offset >> PAGE_SHIFT;
         return map_frames_ex(&first_mfn, n, 0, 1, 1, DOMID_IO, NULL,
_PAGE_PRESENT|_PAGE_RW);
     } else ASSERT(0);
--=20
1.7.4.4



--------------ms080504080107020709010107
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIDyjCC
A8YwggMvoAMCAQICBD/xyf0wDQYJKoZIhvcNAQEFBQAwLzELMAkGA1UEBhMCVVMxDzANBgNV
BAoTBkpIVUFQTDEPMA0GA1UECxMGQklTRENBMB4XDTEwMDYxMTE4MjIwNloXDTEzMDYxMTE4
NTIwNlowZjELMAkGA1UEBhMCVVMxDzANBgNVBAoTBkpIVUFQTDEPMA0GA1UECxMGUGVvcGxl
MTUwFgYDVQQLEw9WUE5Hcm91cC1CSVNEQ0EwGwYDVQQDExRNYXR0aGV3IEUgRmlvcmF2YW50
ZTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAnpbwVSP6o1Nb5lcW7dd3yTo9iBJdi7qz
4nANOMFPK7JOy5npKN1iiousl28U/scUJES55gPwAWYJK3uVyQAsA4adgDKi5DoD1UHDQEwp
bY7iHLJeq0NPr4BqYNqnCFPbE6HC8zSJrr4qKn+gVUQT39SIFqdiIPJwZL8FYTRQ/zsCAwEA
AaOCAbYwggGyMAsGA1UdDwQEAwIHgDArBgNVHRAEJDAigA8yMDEwMDYxMTE4MjIwNlqBDzIw
MTIwNzE3MjI1MjA2WjAbBg0rBgEEAbMlCwMBAQEBBAoWCGZpb3JhbWUxMBsGDSsGAQQBsyUL
AwEBAQIEChIIMDAxMDQyNjEwWAYJYIZIAYb6ax4BBEsMSVRoZSBwcml2YXRlIGtleSBjb3Jy
ZXNwb25kaW5nIHRvIHRoaXMgY2VydGlmaWNhdGUgbWF5IGhhdmUgYmVlbiBleHBvcnRlZC4w
KAYDVR0RBCEwH4EdTWF0dGhldy5GaW9yYXZhbnRlQGpodWFwbC5lZHUwUgYDVR0fBEswSTBH
oEWgQ6RBMD8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJU0RD
QTEOMAwGA1UEAxMFQ1JMNTYwHwYDVR0jBBgwFoAUCDUpmxH52EU2CyWmF2EJMB1yqeswHQYD
VR0OBBYEFO6LYxg6r9wHZ+zdQtBHn1dZ/YTNMAkGA1UdEwQCMAAwGQYJKoZIhvZ9B0EABAww
ChsEVjcuMQMCBLAwDQYJKoZIhvcNAQEFBQADgYEAJO9HQh4YNChVLzuZqK5ARJARD8JoujGZ
fdo75quvg2jXFQe2sEjvLnxJZgm/pv8fdZakq48CWwjYHKuvIp7sDjTEsQfo+y7SpN/N2NvJ
WU5SqfK1VgYtNLRRoGJUB5Q1aZ+Dg95g3kqpyfpUMISJL8IKVLtJVfN4fggFVUYZ9wwxggGr
MIIBpwIBATA3MC8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJ
U0RDQQIEP/HJ/TAJBgUrDgMCGgUAoIHLMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ
KoZIhvcNAQkFMQ8XDTEyMDkxNzIyMDAzMVowIwYJKoZIhvcNAQkEMRYEFGvHtrloVieSv4U2
qa0Z1wlhj/URMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAK
BggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI
KoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEgYAy1byJcr9B/eUNfWUEEvdvwrQYV4vDn6iR
UBgg0Ghsly0J2uysE2hJUa+UQedb5sGMunbsg4kW+BRsW9ktQ66PSR2iKi0PVawlEvFRkk6R
tknQxb+WdPIFIsMEdh+6s8ma84SHySMosujmbILHM0iXCDTHF+VZXt+IusEkZyZAOgAAAAAA
AA==
--------------ms080504080107020709010107--


--===============9126189459777269867==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============9126189459777269867==--


From xen-devel-bounces@lists.xen.org Mon Sep 17 22:04:56 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 22:04:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDjQr-00020H-B5; Mon, 17 Sep 2012 22:04:45 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <matthew.fioravante@jhuapl.edu>) id 1TDjQp-000208-Ss
	for xen-devel@lists.xensource.com; Mon, 17 Sep 2012 22:04:44 +0000
Received: from [85.158.143.35:5653] by server-2.bemta-4.messagelabs.com id
	18/3B-06610-B7E97505; Mon, 17 Sep 2012 22:04:43 +0000
X-Env-Sender: matthew.fioravante@jhuapl.edu
X-Msg-Ref: server-3.tower-21.messagelabs.com!1347919480!14095210!1
X-Originating-IP: [128.244.251.36]
X-SpamReason: No, hits=0.0 required=7.0 tests=UNPARSEABLE_RELAY
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26654 invoked from network); 17 Sep 2012 22:04:41 -0000
Received: from pilot.jhuapl.edu (HELO jhuapl.edu) (128.244.251.36)
	by server-3.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 17 Sep 2012 22:04:41 -0000
Received: from ([128.244.207.89])
	by pilot.jhuapl.edu with ESMTP with TLS id 63GHCH1.153075920;
	Mon, 17 Sep 2012 18:04:23 -0400
Message-ID: <50579E1C.2000701@jhuapl.edu>
Date: Mon, 17 Sep 2012 18:03:08 -0400
From: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120827 Thunderbird/15.0
MIME-Version: 1.0
To: Samuel Thibault <samuel.thibault@ens-lyon.org>, 
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
X-Enigmail-Version: 1.4.4
Subject: [Xen-devel] [PATCH mini-os enhancements for vtpm 6/8] add select()
	to sys/time.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: multipart/mixed; boundary="===============7248893205354732295=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a cryptographically signed message in MIME format.

--===============7248893205354732295==
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms030709050101000406000508"

This is a cryptographically signed message in MIME format.

--------------ms030709050101000406000508
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

This patch adds the select function to sys/time.h when HAVE_LIBC is
defined, which is according to standard. (see the select() manpage)


Signed of by: Matthew Fioravante matthew.fioravante@jhuapl.edu

diff --git a/extras/mini-os/include/sys/time.h
b/extras/mini-os/include/sys/time.h
--- a/extras/mini-os/include/sys/time.h
+++ b/extras/mini-os/include/sys/time.h
@@ -22,6 +22,7 @@
=20
 #ifdef HAVE_LIBC
 #include_next <sys/time.h>
+
 #else
 struct timespec {
     time_t      tv_sec;
@@ -37,6 +38,10 @@ struct timeval {
 };
=20
 int      gettimeofday(struct timeval *tv, void *tz);
+
+#endif
+#ifdef HAVE_LIBC
+#include <sys/select.h>
 #endif
=20
 #endif /* _MINIOS_SYS_TIME_H_ */
--=20
1.7.4.4



--------------ms030709050101000406000508
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIDyjCC
A8YwggMvoAMCAQICBD/xyf0wDQYJKoZIhvcNAQEFBQAwLzELMAkGA1UEBhMCVVMxDzANBgNV
BAoTBkpIVUFQTDEPMA0GA1UECxMGQklTRENBMB4XDTEwMDYxMTE4MjIwNloXDTEzMDYxMTE4
NTIwNlowZjELMAkGA1UEBhMCVVMxDzANBgNVBAoTBkpIVUFQTDEPMA0GA1UECxMGUGVvcGxl
MTUwFgYDVQQLEw9WUE5Hcm91cC1CSVNEQ0EwGwYDVQQDExRNYXR0aGV3IEUgRmlvcmF2YW50
ZTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAnpbwVSP6o1Nb5lcW7dd3yTo9iBJdi7qz
4nANOMFPK7JOy5npKN1iiousl28U/scUJES55gPwAWYJK3uVyQAsA4adgDKi5DoD1UHDQEwp
bY7iHLJeq0NPr4BqYNqnCFPbE6HC8zSJrr4qKn+gVUQT39SIFqdiIPJwZL8FYTRQ/zsCAwEA
AaOCAbYwggGyMAsGA1UdDwQEAwIHgDArBgNVHRAEJDAigA8yMDEwMDYxMTE4MjIwNlqBDzIw
MTIwNzE3MjI1MjA2WjAbBg0rBgEEAbMlCwMBAQEBBAoWCGZpb3JhbWUxMBsGDSsGAQQBsyUL
AwEBAQIEChIIMDAxMDQyNjEwWAYJYIZIAYb6ax4BBEsMSVRoZSBwcml2YXRlIGtleSBjb3Jy
ZXNwb25kaW5nIHRvIHRoaXMgY2VydGlmaWNhdGUgbWF5IGhhdmUgYmVlbiBleHBvcnRlZC4w
KAYDVR0RBCEwH4EdTWF0dGhldy5GaW9yYXZhbnRlQGpodWFwbC5lZHUwUgYDVR0fBEswSTBH
oEWgQ6RBMD8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJU0RD
QTEOMAwGA1UEAxMFQ1JMNTYwHwYDVR0jBBgwFoAUCDUpmxH52EU2CyWmF2EJMB1yqeswHQYD
VR0OBBYEFO6LYxg6r9wHZ+zdQtBHn1dZ/YTNMAkGA1UdEwQCMAAwGQYJKoZIhvZ9B0EABAww
ChsEVjcuMQMCBLAwDQYJKoZIhvcNAQEFBQADgYEAJO9HQh4YNChVLzuZqK5ARJARD8JoujGZ
fdo75quvg2jXFQe2sEjvLnxJZgm/pv8fdZakq48CWwjYHKuvIp7sDjTEsQfo+y7SpN/N2NvJ
WU5SqfK1VgYtNLRRoGJUB5Q1aZ+Dg95g3kqpyfpUMISJL8IKVLtJVfN4fggFVUYZ9wwxggGr
MIIBpwIBATA3MC8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJ
U0RDQQIEP/HJ/TAJBgUrDgMCGgUAoIHLMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ
KoZIhvcNAQkFMQ8XDTEyMDkxNzIyMDMwOFowIwYJKoZIhvcNAQkEMRYEFEs98McxCI271Q5M
hZrn/9O4NaaeMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAK
BggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI
KoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEgYBTENA/Kwn3T6BpKE7OLj6K8pk7enNX5QqY
j/mbck+7QPikr0ghVai0z/QuO85fB5+ZwDzLxnpoEW7o8yPcDM5KMA/GTIwKAZIS6VMJappB
bODCMXVIO+0cqFOv3GZh8aJyymYOi/Kd0NNXMRiAll98bNXTQKBUqjBlphQ/COvQfQAAAAAA
AA==
--------------ms030709050101000406000508--


--===============7248893205354732295==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============7248893205354732295==--


From xen-devel-bounces@lists.xen.org Mon Sep 17 22:04:56 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 22:04:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDjQr-00020H-B5; Mon, 17 Sep 2012 22:04:45 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <matthew.fioravante@jhuapl.edu>) id 1TDjQp-000208-Ss
	for xen-devel@lists.xensource.com; Mon, 17 Sep 2012 22:04:44 +0000
Received: from [85.158.143.35:5653] by server-2.bemta-4.messagelabs.com id
	18/3B-06610-B7E97505; Mon, 17 Sep 2012 22:04:43 +0000
X-Env-Sender: matthew.fioravante@jhuapl.edu
X-Msg-Ref: server-3.tower-21.messagelabs.com!1347919480!14095210!1
X-Originating-IP: [128.244.251.36]
X-SpamReason: No, hits=0.0 required=7.0 tests=UNPARSEABLE_RELAY
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26654 invoked from network); 17 Sep 2012 22:04:41 -0000
Received: from pilot.jhuapl.edu (HELO jhuapl.edu) (128.244.251.36)
	by server-3.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 17 Sep 2012 22:04:41 -0000
Received: from ([128.244.207.89])
	by pilot.jhuapl.edu with ESMTP with TLS id 63GHCH1.153075920;
	Mon, 17 Sep 2012 18:04:23 -0400
Message-ID: <50579E1C.2000701@jhuapl.edu>
Date: Mon, 17 Sep 2012 18:03:08 -0400
From: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120827 Thunderbird/15.0
MIME-Version: 1.0
To: Samuel Thibault <samuel.thibault@ens-lyon.org>, 
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
X-Enigmail-Version: 1.4.4
Subject: [Xen-devel] [PATCH mini-os enhancements for vtpm 6/8] add select()
	to sys/time.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: multipart/mixed; boundary="===============7248893205354732295=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a cryptographically signed message in MIME format.

--===============7248893205354732295==
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms030709050101000406000508"

This is a cryptographically signed message in MIME format.

--------------ms030709050101000406000508
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

This patch adds the select function to sys/time.h when HAVE_LIBC is
defined, which is according to standard. (see the select() manpage)


Signed of by: Matthew Fioravante matthew.fioravante@jhuapl.edu

diff --git a/extras/mini-os/include/sys/time.h
b/extras/mini-os/include/sys/time.h
--- a/extras/mini-os/include/sys/time.h
+++ b/extras/mini-os/include/sys/time.h
@@ -22,6 +22,7 @@
=20
 #ifdef HAVE_LIBC
 #include_next <sys/time.h>
+
 #else
 struct timespec {
     time_t      tv_sec;
@@ -37,6 +38,10 @@ struct timeval {
 };
=20
 int      gettimeofday(struct timeval *tv, void *tz);
+
+#endif
+#ifdef HAVE_LIBC
+#include <sys/select.h>
 #endif
=20
 #endif /* _MINIOS_SYS_TIME_H_ */
--=20
1.7.4.4



--------------ms030709050101000406000508
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIDyjCC
A8YwggMvoAMCAQICBD/xyf0wDQYJKoZIhvcNAQEFBQAwLzELMAkGA1UEBhMCVVMxDzANBgNV
BAoTBkpIVUFQTDEPMA0GA1UECxMGQklTRENBMB4XDTEwMDYxMTE4MjIwNloXDTEzMDYxMTE4
NTIwNlowZjELMAkGA1UEBhMCVVMxDzANBgNVBAoTBkpIVUFQTDEPMA0GA1UECxMGUGVvcGxl
MTUwFgYDVQQLEw9WUE5Hcm91cC1CSVNEQ0EwGwYDVQQDExRNYXR0aGV3IEUgRmlvcmF2YW50
ZTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAnpbwVSP6o1Nb5lcW7dd3yTo9iBJdi7qz
4nANOMFPK7JOy5npKN1iiousl28U/scUJES55gPwAWYJK3uVyQAsA4adgDKi5DoD1UHDQEwp
bY7iHLJeq0NPr4BqYNqnCFPbE6HC8zSJrr4qKn+gVUQT39SIFqdiIPJwZL8FYTRQ/zsCAwEA
AaOCAbYwggGyMAsGA1UdDwQEAwIHgDArBgNVHRAEJDAigA8yMDEwMDYxMTE4MjIwNlqBDzIw
MTIwNzE3MjI1MjA2WjAbBg0rBgEEAbMlCwMBAQEBBAoWCGZpb3JhbWUxMBsGDSsGAQQBsyUL
AwEBAQIEChIIMDAxMDQyNjEwWAYJYIZIAYb6ax4BBEsMSVRoZSBwcml2YXRlIGtleSBjb3Jy
ZXNwb25kaW5nIHRvIHRoaXMgY2VydGlmaWNhdGUgbWF5IGhhdmUgYmVlbiBleHBvcnRlZC4w
KAYDVR0RBCEwH4EdTWF0dGhldy5GaW9yYXZhbnRlQGpodWFwbC5lZHUwUgYDVR0fBEswSTBH
oEWgQ6RBMD8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJU0RD
QTEOMAwGA1UEAxMFQ1JMNTYwHwYDVR0jBBgwFoAUCDUpmxH52EU2CyWmF2EJMB1yqeswHQYD
VR0OBBYEFO6LYxg6r9wHZ+zdQtBHn1dZ/YTNMAkGA1UdEwQCMAAwGQYJKoZIhvZ9B0EABAww
ChsEVjcuMQMCBLAwDQYJKoZIhvcNAQEFBQADgYEAJO9HQh4YNChVLzuZqK5ARJARD8JoujGZ
fdo75quvg2jXFQe2sEjvLnxJZgm/pv8fdZakq48CWwjYHKuvIp7sDjTEsQfo+y7SpN/N2NvJ
WU5SqfK1VgYtNLRRoGJUB5Q1aZ+Dg95g3kqpyfpUMISJL8IKVLtJVfN4fggFVUYZ9wwxggGr
MIIBpwIBATA3MC8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJ
U0RDQQIEP/HJ/TAJBgUrDgMCGgUAoIHLMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ
KoZIhvcNAQkFMQ8XDTEyMDkxNzIyMDMwOFowIwYJKoZIhvcNAQkEMRYEFEs98McxCI271Q5M
hZrn/9O4NaaeMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAK
BggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI
KoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEgYBTENA/Kwn3T6BpKE7OLj6K8pk7enNX5QqY
j/mbck+7QPikr0ghVai0z/QuO85fB5+ZwDzLxnpoEW7o8yPcDM5KMA/GTIwKAZIS6VMJappB
bODCMXVIO+0cqFOv3GZh8aJyymYOi/Kd0NNXMRiAll98bNXTQKBUqjBlphQ/COvQfQAAAAAA
AA==
--------------ms030709050101000406000508--


--===============7248893205354732295==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============7248893205354732295==--


From xen-devel-bounces@lists.xen.org Mon Sep 17 22:06:46 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 22:06: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 1TDjSd-00027V-RY; Mon, 17 Sep 2012 22:06:35 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <matthew.fioravante@jhuapl.edu>) id 1TDjSc-00027M-2S
	for xen-devel@lists.xensource.com; Mon, 17 Sep 2012 22:06:34 +0000
Received: from [85.158.138.51:29470] by server-1.bemta-3.messagelabs.com id
	C7/23-05884-9EE97505; Mon, 17 Sep 2012 22:06:33 +0000
X-Env-Sender: matthew.fioravante@jhuapl.edu
X-Msg-Ref: server-4.tower-174.messagelabs.com!1347919591!30430052!1
X-Originating-IP: [128.244.251.36]
X-SpamReason: No, hits=0.0 required=7.0 tests=UNPARSEABLE_RELAY
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21510 invoked from network); 17 Sep 2012 22:06:32 -0000
Received: from pilot.jhuapl.edu (HELO jhuapl.edu) (128.244.251.36)
	by server-4.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 17 Sep 2012 22:06:32 -0000
Received: from ([128.244.207.89])
	by pilot.jhuapl.edu with ESMTP with TLS id 63GHCH1.153075996;
	Mon, 17 Sep 2012 18:06:02 -0400
Message-ID: <50579E7F.1050803@jhuapl.edu>
Date: Mon, 17 Sep 2012 18:04:47 -0400
From: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120827 Thunderbird/15.0
MIME-Version: 1.0
To: Samuel Thibault <samuel.thibault@ens-lyon.org>, 
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
X-Enigmail-Version: 1.4.4
Subject: [Xen-devel] [PATCH mini-os enhancements for vtpm 7/8] add floating
 point and sse to mini-os
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============8466739330782170640=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a cryptographically signed message in MIME format.

--===============8466739330782170640==
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms060100070804070005000708"

This is a cryptographically signed message in MIME format.

--------------ms060100070804070005000708
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

This patch adds floating point and sse support to mini-os by
initializing the floating point unit and the see unit during domain boot =
up.


Signed of by: Matthew Fioravante matthew.fioravante@jhuapl.edu

diff --git a/extras/mini-os/arch/x86/setup.c
b/extras/mini-os/arch/x86/setup.c
--- a/extras/mini-os/arch/x86/setup.c
+++ b/extras/mini-os/arch/x86/setup.c
@@ -74,9 +74,28 @@ shared_info_t *map_shared_info(unsigned long pa)
     return (shared_info_t *)shared_info;
 }
=20
+static inline void fpu_init(void) {
+    asm volatile("fninit");
+}
+
+#ifdef __SSE__
+static inline void sse_init(void) {
+    unsigned long status =3D 0x1f80;
+    asm volatile("ldmxcsr %0" : : "m" (status));
+}
+#else
+#define sse_init()
+#endif
+
 void
 arch_init(start_info_t *si)
 {
+    /*Initialize floating point unit */
+        fpu_init();
+
+        /* Initialize SSE */
+        sse_init();
+
     /* Copy the start_info struct to a globally-accessible area. */
     /* WARN: don't do printk before here, it uses information from
        shared_info. Use xprintk instead. */
@@ -99,6 +118,7 @@ arch_init(start_info_t *si)
         (unsigned long)failsafe_callback, 0);
 #endif
=20
+
 }
=20
 void



--------------ms060100070804070005000708
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIDyjCC
A8YwggMvoAMCAQICBD/xyf0wDQYJKoZIhvcNAQEFBQAwLzELMAkGA1UEBhMCVVMxDzANBgNV
BAoTBkpIVUFQTDEPMA0GA1UECxMGQklTRENBMB4XDTEwMDYxMTE4MjIwNloXDTEzMDYxMTE4
NTIwNlowZjELMAkGA1UEBhMCVVMxDzANBgNVBAoTBkpIVUFQTDEPMA0GA1UECxMGUGVvcGxl
MTUwFgYDVQQLEw9WUE5Hcm91cC1CSVNEQ0EwGwYDVQQDExRNYXR0aGV3IEUgRmlvcmF2YW50
ZTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAnpbwVSP6o1Nb5lcW7dd3yTo9iBJdi7qz
4nANOMFPK7JOy5npKN1iiousl28U/scUJES55gPwAWYJK3uVyQAsA4adgDKi5DoD1UHDQEwp
bY7iHLJeq0NPr4BqYNqnCFPbE6HC8zSJrr4qKn+gVUQT39SIFqdiIPJwZL8FYTRQ/zsCAwEA
AaOCAbYwggGyMAsGA1UdDwQEAwIHgDArBgNVHRAEJDAigA8yMDEwMDYxMTE4MjIwNlqBDzIw
MTIwNzE3MjI1MjA2WjAbBg0rBgEEAbMlCwMBAQEBBAoWCGZpb3JhbWUxMBsGDSsGAQQBsyUL
AwEBAQIEChIIMDAxMDQyNjEwWAYJYIZIAYb6ax4BBEsMSVRoZSBwcml2YXRlIGtleSBjb3Jy
ZXNwb25kaW5nIHRvIHRoaXMgY2VydGlmaWNhdGUgbWF5IGhhdmUgYmVlbiBleHBvcnRlZC4w
KAYDVR0RBCEwH4EdTWF0dGhldy5GaW9yYXZhbnRlQGpodWFwbC5lZHUwUgYDVR0fBEswSTBH
oEWgQ6RBMD8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJU0RD
QTEOMAwGA1UEAxMFQ1JMNTYwHwYDVR0jBBgwFoAUCDUpmxH52EU2CyWmF2EJMB1yqeswHQYD
VR0OBBYEFO6LYxg6r9wHZ+zdQtBHn1dZ/YTNMAkGA1UdEwQCMAAwGQYJKoZIhvZ9B0EABAww
ChsEVjcuMQMCBLAwDQYJKoZIhvcNAQEFBQADgYEAJO9HQh4YNChVLzuZqK5ARJARD8JoujGZ
fdo75quvg2jXFQe2sEjvLnxJZgm/pv8fdZakq48CWwjYHKuvIp7sDjTEsQfo+y7SpN/N2NvJ
WU5SqfK1VgYtNLRRoGJUB5Q1aZ+Dg95g3kqpyfpUMISJL8IKVLtJVfN4fggFVUYZ9wwxggGr
MIIBpwIBATA3MC8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJ
U0RDQQIEP/HJ/TAJBgUrDgMCGgUAoIHLMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ
KoZIhvcNAQkFMQ8XDTEyMDkxNzIyMDQ0N1owIwYJKoZIhvcNAQkEMRYEFO6df9elfd5pH624
zV3hFL8lOwAiMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAK
BggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI
KoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEgYBLwXCM/FgtuwJoeIaaYlVO3ckk4Gt70g1g
338NkN1jZM6p7mHGjlNq/KkvK9zbdmc7BS3l5MEIEmjDFAx8Xxv3Y0UKgGUcU9Qt7E+TKjC2
u3j3SkhcVHfoWu/EhDC+9/Cw2Brf7tDCyDo13L635DU6aNZAnNNQZquDuxJvRS/FxQAAAAAA
AA==
--------------ms060100070804070005000708--


--===============8466739330782170640==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============8466739330782170640==--


From xen-devel-bounces@lists.xen.org Mon Sep 17 22:06:46 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 22:06: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 1TDjSd-00027V-RY; Mon, 17 Sep 2012 22:06:35 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <matthew.fioravante@jhuapl.edu>) id 1TDjSc-00027M-2S
	for xen-devel@lists.xensource.com; Mon, 17 Sep 2012 22:06:34 +0000
Received: from [85.158.138.51:29470] by server-1.bemta-3.messagelabs.com id
	C7/23-05884-9EE97505; Mon, 17 Sep 2012 22:06:33 +0000
X-Env-Sender: matthew.fioravante@jhuapl.edu
X-Msg-Ref: server-4.tower-174.messagelabs.com!1347919591!30430052!1
X-Originating-IP: [128.244.251.36]
X-SpamReason: No, hits=0.0 required=7.0 tests=UNPARSEABLE_RELAY
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21510 invoked from network); 17 Sep 2012 22:06:32 -0000
Received: from pilot.jhuapl.edu (HELO jhuapl.edu) (128.244.251.36)
	by server-4.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 17 Sep 2012 22:06:32 -0000
Received: from ([128.244.207.89])
	by pilot.jhuapl.edu with ESMTP with TLS id 63GHCH1.153075996;
	Mon, 17 Sep 2012 18:06:02 -0400
Message-ID: <50579E7F.1050803@jhuapl.edu>
Date: Mon, 17 Sep 2012 18:04:47 -0400
From: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120827 Thunderbird/15.0
MIME-Version: 1.0
To: Samuel Thibault <samuel.thibault@ens-lyon.org>, 
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
X-Enigmail-Version: 1.4.4
Subject: [Xen-devel] [PATCH mini-os enhancements for vtpm 7/8] add floating
 point and sse to mini-os
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============8466739330782170640=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a cryptographically signed message in MIME format.

--===============8466739330782170640==
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms060100070804070005000708"

This is a cryptographically signed message in MIME format.

--------------ms060100070804070005000708
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

This patch adds floating point and sse support to mini-os by
initializing the floating point unit and the see unit during domain boot =
up.


Signed of by: Matthew Fioravante matthew.fioravante@jhuapl.edu

diff --git a/extras/mini-os/arch/x86/setup.c
b/extras/mini-os/arch/x86/setup.c
--- a/extras/mini-os/arch/x86/setup.c
+++ b/extras/mini-os/arch/x86/setup.c
@@ -74,9 +74,28 @@ shared_info_t *map_shared_info(unsigned long pa)
     return (shared_info_t *)shared_info;
 }
=20
+static inline void fpu_init(void) {
+    asm volatile("fninit");
+}
+
+#ifdef __SSE__
+static inline void sse_init(void) {
+    unsigned long status =3D 0x1f80;
+    asm volatile("ldmxcsr %0" : : "m" (status));
+}
+#else
+#define sse_init()
+#endif
+
 void
 arch_init(start_info_t *si)
 {
+    /*Initialize floating point unit */
+        fpu_init();
+
+        /* Initialize SSE */
+        sse_init();
+
     /* Copy the start_info struct to a globally-accessible area. */
     /* WARN: don't do printk before here, it uses information from
        shared_info. Use xprintk instead. */
@@ -99,6 +118,7 @@ arch_init(start_info_t *si)
         (unsigned long)failsafe_callback, 0);
 #endif
=20
+
 }
=20
 void



--------------ms060100070804070005000708
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIDyjCC
A8YwggMvoAMCAQICBD/xyf0wDQYJKoZIhvcNAQEFBQAwLzELMAkGA1UEBhMCVVMxDzANBgNV
BAoTBkpIVUFQTDEPMA0GA1UECxMGQklTRENBMB4XDTEwMDYxMTE4MjIwNloXDTEzMDYxMTE4
NTIwNlowZjELMAkGA1UEBhMCVVMxDzANBgNVBAoTBkpIVUFQTDEPMA0GA1UECxMGUGVvcGxl
MTUwFgYDVQQLEw9WUE5Hcm91cC1CSVNEQ0EwGwYDVQQDExRNYXR0aGV3IEUgRmlvcmF2YW50
ZTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAnpbwVSP6o1Nb5lcW7dd3yTo9iBJdi7qz
4nANOMFPK7JOy5npKN1iiousl28U/scUJES55gPwAWYJK3uVyQAsA4adgDKi5DoD1UHDQEwp
bY7iHLJeq0NPr4BqYNqnCFPbE6HC8zSJrr4qKn+gVUQT39SIFqdiIPJwZL8FYTRQ/zsCAwEA
AaOCAbYwggGyMAsGA1UdDwQEAwIHgDArBgNVHRAEJDAigA8yMDEwMDYxMTE4MjIwNlqBDzIw
MTIwNzE3MjI1MjA2WjAbBg0rBgEEAbMlCwMBAQEBBAoWCGZpb3JhbWUxMBsGDSsGAQQBsyUL
AwEBAQIEChIIMDAxMDQyNjEwWAYJYIZIAYb6ax4BBEsMSVRoZSBwcml2YXRlIGtleSBjb3Jy
ZXNwb25kaW5nIHRvIHRoaXMgY2VydGlmaWNhdGUgbWF5IGhhdmUgYmVlbiBleHBvcnRlZC4w
KAYDVR0RBCEwH4EdTWF0dGhldy5GaW9yYXZhbnRlQGpodWFwbC5lZHUwUgYDVR0fBEswSTBH
oEWgQ6RBMD8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJU0RD
QTEOMAwGA1UEAxMFQ1JMNTYwHwYDVR0jBBgwFoAUCDUpmxH52EU2CyWmF2EJMB1yqeswHQYD
VR0OBBYEFO6LYxg6r9wHZ+zdQtBHn1dZ/YTNMAkGA1UdEwQCMAAwGQYJKoZIhvZ9B0EABAww
ChsEVjcuMQMCBLAwDQYJKoZIhvcNAQEFBQADgYEAJO9HQh4YNChVLzuZqK5ARJARD8JoujGZ
fdo75quvg2jXFQe2sEjvLnxJZgm/pv8fdZakq48CWwjYHKuvIp7sDjTEsQfo+y7SpN/N2NvJ
WU5SqfK1VgYtNLRRoGJUB5Q1aZ+Dg95g3kqpyfpUMISJL8IKVLtJVfN4fggFVUYZ9wwxggGr
MIIBpwIBATA3MC8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJ
U0RDQQIEP/HJ/TAJBgUrDgMCGgUAoIHLMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ
KoZIhvcNAQkFMQ8XDTEyMDkxNzIyMDQ0N1owIwYJKoZIhvcNAQkEMRYEFO6df9elfd5pH624
zV3hFL8lOwAiMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAK
BggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI
KoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEgYBLwXCM/FgtuwJoeIaaYlVO3ckk4Gt70g1g
338NkN1jZM6p7mHGjlNq/KkvK9zbdmc7BS3l5MEIEmjDFAx8Xxv3Y0UKgGUcU9Qt7E+TKjC2
u3j3SkhcVHfoWu/EhDC+9/Cw2Brf7tDCyDo13L635DU6aNZAnNNQZquDuxJvRS/FxQAAAAAA
AA==
--------------ms060100070804070005000708--


--===============8466739330782170640==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============8466739330782170640==--


From xen-devel-bounces@lists.xen.org Mon Sep 17 22:10:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 22:10:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDjVw-0002JE-GZ; Mon, 17 Sep 2012 22:10:00 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <matthew.fioravante@jhuapl.edu>) id 1TDjVt-0002J5-NL
	for xen-devel@lists.xensource.com; Mon, 17 Sep 2012 22:09:58 +0000
Received: from [85.158.139.211:21339] by server-1.bemta-5.messagelabs.com id
	A6/5B-32692-4BF97505; Mon, 17 Sep 2012 22:09:56 +0000
X-Env-Sender: matthew.fioravante@jhuapl.edu
X-Msg-Ref: server-5.tower-206.messagelabs.com!1347919790!18879156!1
X-Originating-IP: [128.244.251.36]
X-SpamReason: No, hits=0.0 required=7.0 tests=UNPARSEABLE_RELAY
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20631 invoked from network); 17 Sep 2012 22:09:51 -0000
Received: from pilot.jhuapl.edu (HELO jhuapl.edu) (128.244.251.36)
	by server-5.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 17 Sep 2012 22:09:51 -0000
Received: from ([128.244.207.89])
	by pilot.jhuapl.edu with ESMTP with TLS id 63GHCH1.153076130;
	Mon, 17 Sep 2012 18:09:34 -0400
Message-ID: <50579F53.4070302@jhuapl.edu>
Date: Mon, 17 Sep 2012 18:08:19 -0400
From: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120827 Thunderbird/15.0
MIME-Version: 1.0
To: Samuel Thibault <samuel.thibault@ens-lyon.org>, 
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
X-Enigmail-Version: 1.4.4
Subject: [Xen-devel] [PATCH mini-os enhancements for vtpm 8/8] Add 3 tpm
	drivers to mini-os
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1797525133642965968=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a cryptographically signed message in MIME format.

--===============1797525133642965968==
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms000807020403040901070008"

This is a cryptographically signed message in MIME format.

--------------ms000807020403040901070008
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

This patch adds 3 new drivers to mini-os.

tpmfront - paravirtualized tpm frontend driver
tpmback - paravirtualized tpm backend driver
tpm_tis - hardware tpm driver

Unfortunately these drivers were derived from GPL licensed linux kernel
drivers so they must carry the GPL license. However, since mini-os now
supports conditional compilation, hopefully these drivers can be
included into the xen tree and conditionally removed from non-gpl
projects. By default they are disabled in the makefile.

Signed off by: Matthew Fioravante matthew.fioravante@jhuapl.edu

diff --git a/extras/mini-os/Makefile b/extras/mini-os/Makefile
--- a/extras/mini-os/Makefile
+++ b/extras/mini-os/Makefile
@@ -22,6 +22,9 @@ CONFIG_QEMU_XS_ARGS ?=3D n
 CONFIG_TEST ?=3D n
 CONFIG_PCIFRONT ?=3D n
 CONFIG_BLKFRONT ?=3D y
+CONFIG_TPMFRONT ?=3D n
+CONFIG_TPM_TIS ?=3D n
+CONFIG_TPMBACK ?=3D n
 CONFIG_NETFRONT ?=3D y
 CONFIG_FBFRONT ?=3D y
 CONFIG_KBDFRONT ?=3D y
@@ -36,6 +39,9 @@ flags-$(CONFIG_SPARSE_BSS) +=3D -DCONFIG_SPARSE_BSS
 flags-$(CONFIG_QEMU_XS_ARGS) +=3D -DCONFIG_QEMU_XS_ARGS
 flags-$(CONFIG_PCIFRONT) +=3D -DCONFIG_PCIFRONT
 flags-$(CONFIG_BLKFRONT) +=3D -DCONFIG_BLKFRONT
+flags-$(CONFIG_TPMFRONT) +=3D -DCONFIG_TPMFRONT
+flags-$(CONFIG_TPM_TIS) +=3D -DCONFIG_TPM_TIS
+flags-$(CONFIG_TPMBACK) +=3D -DCONFIG_TPMBACK
 flags-$(CONFIG_NETFRONT) +=3D -DCONFIG_NETFRONT
 flags-$(CONFIG_KBDFRONT) +=3D -DCONFIG_KBDFRONT
 flags-$(CONFIG_FBFRONT) +=3D -DCONFIG_FBFRONT
@@ -67,6 +73,9 @@ TARGET :=3D mini-os
 SUBDIRS :=3D lib xenbus console
=20
 src-$(CONFIG_BLKFRONT) +=3D blkfront.c
+src-$(CONFIG_TPMFRONT) +=3D tpmfront.c
+src-$(CONFIG_TPM_TIS) +=3D tpm_tis.c
+src-$(CONFIG_TPMBACK) +=3D tpmback.c
 src-y +=3D daytime.c
 src-y +=3D events.c
 src-$(CONFIG_FBFRONT) +=3D fbfront.c
diff --git a/extras/mini-os/include/lib.h b/extras/mini-os/include/lib.h
--- a/extras/mini-os/include/lib.h
+++ b/extras/mini-os/include/lib.h
@@ -142,6 +142,8 @@ enum fd_type {
     FTYPE_FB,
     FTYPE_MEM,
     FTYPE_SAVEFILE,
+    FTYPE_TPMFRONT,
+    FTYPE_TPM_TIS,
 };
=20
 LIST_HEAD(evtchn_port_list, evtchn_port_info);
@@ -185,6 +187,20 @@ extern struct file {
     struct {
         struct consfront_dev *dev;
     } cons;
+#ifdef CONFIG_TPMFRONT
+    struct {
+       struct tpmfront_dev *dev;
+       int respgot;
+       off_t offset;
+    } tpmfront;
+#endif
+#ifdef CONFIG_TPM_TIS
+    struct {
+       struct tpm_chip *dev;
+       int respgot;
+       off_t offset;
+    } tpm_tis;
+#endif
 #ifdef CONFIG_XENBUS
         struct {
             /* To each xenbus FD is associated a queue of watch events
for this
diff --git a/extras/mini-os/include/tpm_tis.h
b/extras/mini-os/include/tpm_tis.h
--- /dev/null
+++ b/extras/mini-os/include/tpm_tis.h
@@ -0,0 +1,63 @@
+/*
+ * Copyright (c) 2010-2012 United States Government, as represented by
+ * the Secretary of Defense.  All rights reserved.
+ *
+ * This driver 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 3 of the License, or
+ * (at your option) any later version.
+ *
+ * This driver is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program.  If not, see <http://www.gnu.org/licenses/>.=

+ *
+ * Based upon the files:
+ *  drivers/char/tpm/tpm_tis.c
+ *  drivers/char/tpm/tpm.c
+ * from the Linux kernel, which are Copyright (C) 2006 IBM Corporation
+ */
+#ifndef TPM_TIS_H
+#define TPM_TIS_H
+
+#include <mini-os/types.h>
+#include <mini-os/byteorder.h>
+
+#define TPM_TIS_EN_LOCL0 1
+#define TPM_TIS_EN_LOCL1 (1 << 1)
+#define TPM_TIS_EN_LOCL2 (1 << 2)
+#define TPM_TIS_EN_LOCL3 (1 << 3)
+#define TPM_TIS_EN_LOCL4 (1 << 4)
+#define TPM_TIS_EN_LOCLALL (TPM_TIS_EN_LOCL0 | TPM_TIS_EN_LOCL1  |
TPM_TIS_EN_LOCL2 | TPM_TIS_EN_LOCL3 | TPM_TIS_EN_LOCL4)
+#define TPM_TIS_LOCL_INT_TO_FLAG(x) (1 << x)
+#define TPM_BASEADDR 0xFED40000
+#define TPM_PROBE_IRQ 0xFFFF
+
+struct tpm_chip;
+
+struct tpm_chip* init_tpm_tis(unsigned long baseaddr, int localities,
unsigned int irq);
+void shutdown_tpm_tis(struct tpm_chip* tpm);
+
+int tpm_tis_request_locality(struct tpm_chip* tpm, int locality);
+int tpm_tis_cmd(struct tpm_chip* tpm, uint8_t* req, size_t reqlen,
uint8_t** resp, size_t* resplen);
+
+#ifdef HAVE_LIBC
+#include <sys/stat.h>
+#include <fcntl.h>
+/* POSIX IO functions:
+ * use tpm_tis_open() to get a file descriptor to the tpm device
+ * use write() on the fd to send a command to the backend. You must
+ * include the entire command in a single call to write().
+ * use read() on the fd to read the response. You can use
+ * fstat() to get the size of the response and lseek() to seek on it.
+ */
+int tpm_tis_open(struct tpm_chip* tpm);
+int tpm_tis_posix_read(int fd, uint8_t* buf, size_t count);
+int tpm_tis_posix_write(int fd, const uint8_t* buf, size_t count);
+int tpm_tis_posix_fstat(int fd, struct stat* buf);
+#endif
+
+#endif
diff --git a/extras/mini-os/include/tpmback.h
b/extras/mini-os/include/tpmback.h
--- /dev/null
+++ b/extras/mini-os/include/tpmback.h
@@ -0,0 +1,95 @@
+/*
+ * Copyright (c) 2010-2012 United States Government, as represented by
+ * the Secretary of Defense.  All rights reserved.
+ *
+ * This driver 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 3 of the License, or
+ * (at your option) any later version.
+ *
+ * This driver is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program.  If not, see <http://www.gnu.org/licenses/>.=

+ *
+ * Based upon the files:
+ *  drivers/xen/tpmbk.c
+ * from the Linux kernel, which are Copyright (C) 2006 IBM Corporation
+ */
+#include <xen/io/tpmif.h>
+#include <xen/io/xenbus.h>
+#include <mini-os/types.h>
+#include <xen/xen.h>
+#ifndef TPMBACK_H
+#define TPMBACK_H
+
+struct tpmcmd {
+   domid_t domid;        /* Domid of the frontend */
+   unsigned int handle;    /* Handle of the frontend */
+   char* uuid;            /* uuid of the tpm interface - allocated
internally, dont free it */
+
+   unsigned int req_len;        /* Size of the command in buf - set by
tpmback driver */
+   uint8_t* req;            /* tpm command bits, allocated by driver,
DON'T FREE IT */
+   unsigned int resp_len;    /* Size of the outgoing command,
+                   you set this before passing the cmd object to
tpmback_resp */
+   uint8_t* resp;        /* Buffer for response - YOU MUST ALLOCATE IT,
YOU MUST ALSO FREE IT */
+};
+typedef struct tpmcmd tpmcmd_t;
+
+/* Initialize the tpm backend driver
+ * @exclusive_domname - This is NULL terminated list of vtpm uuid
strings. If this list
+ *             is non-empty, then only frontend domains with vtpm
uuid's matching
+ *             entries in this list will be allowed to connect.
+ *             Other connections will be immediatly closed.
+ *             Set this argument to NULL to allow any vtpm to connect.
+ */
+void init_tpmback(char** exclusive_uuids);
+/* Shutdown tpm backend driver */
+void shutdown_tpmback(void);
+
+/* Blocks until a tpm command is sent from any front end.
+ * Returns a pointer to the tpm command to handle.
+ * Do not try to free this pointer or the req buffer
+ * This function will return NULL if the tpm backend driver
+ * is shutdown or any other error occurs */
+tpmcmd_t* tpmback_req_any(void);
+
+/* Blocks until a tpm command from the frontend at domid/handle
+ * is sent.
+ * Returns NULL if domid/handle is not connected, tpmback is
+ * shutdown or shutting down, or if there is an error
+ */
+tpmcmd_t* tpmback_req(domid_t domid, unsigned int handle);
+
+/* Send the response to the tpm command back to the frontend
+ * This function will free the tpmcmd object, but you must free the resp=

+ * buffer yourself */
+void tpmback_resp(tpmcmd_t* tpmcmd);
+
+/* Waits for the first frontend to connect and then sets domid and
handle appropriately.
+ * If one or more frontends are already connected, this will set domid
and handle to one
+ * of them arbitrarily. The main use for this function is to wait until
a single
+ * frontend connection has occured.
+ * returns 0 on success, non-zero on failure */
+int tpmback_wait_for_frontend_connect(domid_t *domid, unsigned int
*handle);
+
+/* returns the number of frontends connected */
+int tpmback_num_frontends(void);
+
+/* Returns the uuid of the specified frontend, NULL on error */
+char* tpmback_get_uuid(domid_t domid, unsigned int handle);
+
+/* Specify a function to call when a new tpm device connects */
+void tpmback_set_open_callback(void (*cb)(domid_t, unsigned int));
+
+/* Specify a function to call when a tpm device disconnects */
+void tpmback_set_close_callback(void (*cb)(domid_t, unsigned int));
+
+//Not Implemented
+void tpmback_set_suspend_callback(void (*cb)(domid_t, unsigned int));
+void tpmback_set_resume_callback(void (*cb)(domid_t, unsigned int));
+
+#endif
diff --git a/extras/mini-os/include/tpmfront.h
b/extras/mini-os/include/tpmfront.h
--- /dev/null
+++ b/extras/mini-os/include/tpmfront.h
@@ -0,0 +1,94 @@
+/*
+ * Copyright (c) 2010-2012 United States Government, as represented by
+ * the Secretary of Defense.  All rights reserved.
+ *
+ * This driver 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 3 of the License, or
+ * (at your option) any later version.
+ *
+ * This driver is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program.  If not, see <http://www.gnu.org/licenses/>.=

+ *
+ * Based upon the files:
+ *  drivers/char/tpm/tpm_vtpm.c
+ *  drivers/char/tpm/tpm_xen.c
+ * from the Linux kernel, which are Copyright (C) 2006 IBM Corporation
+ */
+#ifndef TPMFRONT_H
+#define TPMFRONT_H
+
+#include <mini-os/types.h>
+#include <mini-os/os.h>
+#include <mini-os/events.h>
+#include <mini-os/wait.h>
+#include <xen/xen.h>
+#include <xen/io/xenbus.h>
+#include <xen/io/tpmif.h>
+
+struct tpmfront_dev {
+   grant_ref_t ring_ref;
+   evtchn_port_t evtchn;
+
+   tpmif_tx_interface_t* tx;
+
+   void** pages;
+
+   domid_t bedomid;
+   char* nodename;
+   char* bepath;
+
+   XenbusState state;
+
+   uint8_t waiting;
+   struct wait_queue_head waitq;
+
+   uint8_t* respbuf;
+   size_t resplen;
+
+#ifdef HAVE_LIBC
+   int fd;
+#endif
+
+};
+
+
+/*Initialize frontend */
+struct tpmfront_dev* init_tpmfront(const char* nodename);
+/*Shutdown frontend */
+void shutdown_tpmfront(struct tpmfront_dev* dev);
+
+/* Send a tpm command to the backend and wait for the response
+ *
+ * @dev - frontend device
+ * @req - request buffer
+ * @reqlen - length of request buffer
+ * @resp - *resp will be set to internal response buffer, don't free
it! Value is undefined on error
+ * @resplen - *resplen will be set to the length of the response. Value
is undefined on error
+ *
+ * returns 0 on success, non zero on failure.
+ * */
+int tpmfront_cmd(struct tpmfront_dev* dev, uint8_t* req, size_t reqlen,
uint8_t** resp, size_t* resplen);
+
+#ifdef HAVE_LIBC
+#include <sys/stat.h>
+/* POSIX IO functions:
+ * use tpmfront_open() to get a file descriptor to the tpm device
+ * use write() on the fd to send a command to the backend. You must
+ * include the entire command in a single call to write().
+ * use read() on the fd to read the response. You can use
+ * fstat() to get the size of the response and lseek() to seek on it.
+ */
+int tpmfront_open(struct tpmfront_dev* dev);
+int tpmfront_posix_read(int fd, uint8_t* buf, size_t count);
+int tpmfront_posix_write(int fd, const uint8_t* buf, size_t count);
+int tpmfront_posix_fstat(int fd, struct stat* buf);
+#endif
+
+
+#endif
diff --git a/extras/mini-os/lib/sys.c b/extras/mini-os/lib/sys.c
--- a/extras/mini-os/lib/sys.c
+++ b/extras/mini-os/lib/sys.c
@@ -27,6 +27,8 @@
 #include <netfront.h>
 #include <blkfront.h>
 #include <fbfront.h>
+#include <tpmfront.h>
+#include <tpm_tis.h>
 #include <xenbus.h>
 #include <xenstore.h>
=20
@@ -294,6 +296,16 @@ int read(int fd, void *buf, size_t nbytes)
         return blkfront_posix_read(fd, buf, nbytes);
         }
 #endif
+#ifdef CONFIG_TPMFRONT
+        case FTYPE_TPMFRONT: {
+        return tpmfront_posix_read(fd, buf, nbytes);
+        }
+#endif
+#ifdef CONFIG_TPM_TIS
+        case FTYPE_TPM_TIS: {
+        return tpm_tis_posix_read(fd, buf, nbytes);
+        }
+#endif
     default:
         break;
     }
@@ -330,6 +342,14 @@ int write(int fd, const void *buf, size_t nbytes)
     case FTYPE_BLK:
         return blkfront_posix_write(fd, buf, nbytes);
 #endif
+#ifdef CONFIG_TPMFRONT
+    case FTYPE_TPMFRONT:
+        return tpmfront_posix_write(fd, buf, nbytes);
+#endif
+#ifdef CONFIG_TPM_TIS
+    case FTYPE_TPM_TIS:
+        return tpm_tis_posix_write(fd, buf, nbytes);
+#endif
     default:
         break;
     }
@@ -341,8 +361,16 @@ int write(int fd, const void *buf, size_t nbytes)
 off_t lseek(int fd, off_t offset, int whence)
 {
     switch(files[fd].type) {
+#if defined(CONFIG_BLKFRONT) || defined(CONFIG_TPMFRONT) ||
defined(CONFIG_TPM_TIS)
 #ifdef CONFIG_BLKFRONT
        case FTYPE_BLK:
+#endif
+#ifdef CONFIG_TPMFRNT
+       case FTYPE_TPMFRONT:
+#endif
+#ifdef CONFIG_TPM_TIS
+       case FTYPE_TPM_TIS:
+#endif
       switch (whence) {
          case SEEK_SET:
         files[fd].file.offset =3D offset;
@@ -420,6 +448,18 @@ int close(int fd)
         files[fd].type =3D FTYPE_NONE;
         return 0;
 #endif
+#ifdef CONFIG_TPMFRONT
+    case FTYPE_TPMFRONT:
+            shutdown_tpmfront(files[fd].tpmfront.dev);
+        files[fd].type =3D FTYPE_NONE;
+        return 0;
+#endif
+#ifdef CONFIG_TPM_TIS
+    case FTYPE_TPM_TIS:
+            shutdown_tpm_tis(files[fd].tpm_tis.dev);
+        files[fd].type =3D FTYPE_NONE;
+        return 0;
+#endif
 #ifdef CONFIG_KBDFRONT
     case FTYPE_KBD:
             shutdown_kbdfront(files[fd].kbd.dev);
@@ -489,6 +529,14 @@ int fstat(int fd, struct stat *buf)
     case FTYPE_BLK:
        return blkfront_posix_fstat(fd, buf);
 #endif
+#ifdef CONFIG_TPMFRONT
+    case FTYPE_TPMFRONT:
+       return tpmfront_posix_fstat(fd, buf);
+#endif
+#ifdef CONFIG_TPM_TIS
+    case FTYPE_TPM_TIS:
+       return tpm_tis_posix_fstat(fd, buf);
+#endif
     default:
         break;
     }
diff --git a/extras/mini-os/tpm_tis.c b/extras/mini-os/tpm_tis.c
--- /dev/null
+++ b/extras/mini-os/tpm_tis.c
@@ -0,0 +1,1344 @@
+/*
+ * Copyright (c) 2010-2012 United States Government, as represented by
+ * the Secretary of Defense.  All rights reserved.
+ *
+ * This driver 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 3 of the License, or
+ * (at your option) any later version.
+ *
+ * This driver is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program.  If not, see <http://www.gnu.org/licenses/>.=

+ *
+ * Based upon the files:
+ *  drivers/char/tpm/tpm_tis.c
+ *  drivers/char/tpm/tpm.c
+ * from the Linux kernel, which are Copyright (C) 2006 IBM Corporation
+ */
+#include <mini-os/ioremap.h>
+#include <mini-os/iorw.h>
+#include <mini-os/tpm_tis.h>
+#include <mini-os/os.h>
+#include <mini-os/sched.h>
+#include <mini-os/byteorder.h>
+#include <mini-os/events.h>
+#include <mini-os/wait.h>
+#include <mini-os/xmalloc.h>
+#include <errno.h>
+#include <stdbool.h>
+
+#ifndef min
+    #define min( a, b ) ( ((a) < (b)) ? (a) : (b) )
+#endif
+
+#define TPM_HEADER_SIZE 10
+
+#define TPM_BUFSIZE 2048
+
+struct tpm_input_header {
+        uint16_t  tag;
+        uint32_t  length;
+        uint32_t  ordinal;
+}__attribute__((packed));
+
+struct tpm_output_header {
+        uint16_t  tag;
+        uint32_t  length;
+        uint32_t  return_code;
+}__attribute__((packed));
+
+struct  stclear_flags_t {
+        uint16_t  tag;
+        uint8_t      deactivated;
+        uint8_t      disableForceClear;
+        uint8_t      physicalPresence;
+        uint8_t      physicalPresenceLock;
+        uint8_t      bGlobalLock;
+}__attribute__((packed));
+
+struct  tpm_version_t {
+        uint8_t      Major;
+        uint8_t      Minor;
+        uint8_t      revMajor;
+        uint8_t      revMinor;
+}__attribute__((packed));
+
+struct  tpm_version_1_2_t {
+        uint16_t  tag;
+        uint8_t      Major;
+        uint8_t      Minor;
+        uint8_t      revMajor;
+        uint8_t      revMinor;
+}__attribute__((packed));
+
+struct  timeout_t {
+        uint32_t  a;
+        uint32_t  b;
+        uint32_t  c;
+        uint32_t  d;
+}__attribute__((packed));
+
+struct duration_t {
+        uint32_t  tpm_short;
+        uint32_t  tpm_medium;
+        uint32_t  tpm_long;
+}__attribute__((packed));
+
+struct permanent_flags_t {
+        uint16_t  tag;
+        uint8_t      disable;
+        uint8_t      ownership;
+        uint8_t      deactivated;
+        uint8_t      readPubek;
+        uint8_t      disableOwnerClear;
+        uint8_t      allowMaintenance;
+        uint8_t      physicalPresenceLifetimeLock;
+        uint8_t      physicalPresenceHWEnable;
+        uint8_t      physicalPresenceCMDEnable;
+        uint8_t      CEKPUsed;
+        uint8_t      TPMpost;
+        uint8_t      TPMpostLock;
+        uint8_t      FIPS;
+        uint8_t      operator;
+        uint8_t      enableRevokeEK;
+        uint8_t      nvLocked;
+        uint8_t      readSRKPub;
+        uint8_t      tpmEstablished;
+        uint8_t      maintenanceDone;
+        uint8_t      disableFullDALogicInfo;
+}__attribute__((packed));
+
+typedef union {
+        struct  permanent_flags_t perm_flags;
+        struct  stclear_flags_t stclear_flags;
+        bool    owned;
+        uint32_t  num_pcrs;
+        struct  tpm_version_t   tpm_version;
+        struct  tpm_version_1_2_t tpm_version_1_2;
+        uint32_t  manufacturer_id;
+        struct timeout_t  timeout;
+        struct duration_t duration;
+} cap_t;
+
+struct  tpm_getcap_params_in {
+        uint32_t  cap;
+        uint32_t  subcap_size;
+        uint32_t  subcap;
+}__attribute__((packed));
+
+struct  tpm_getcap_params_out {
+        uint32_t  cap_size;
+        cap_t   cap;
+}__attribute__((packed));
+
+struct  tpm_readpubek_params_out {
+        uint8_t      algorithm[4];
+        uint8_t      encscheme[2];
+        uint8_t      sigscheme[2];
+        uint32_t  paramsize;
+        uint8_t      parameters[12]; /*assuming RSA*/
+        uint32_t  keysize;
+        uint8_t      modulus[256];
+        uint8_t      checksum[20];
+}__attribute__((packed));
+
+typedef union {
+        struct  tpm_input_header in;
+        struct  tpm_output_header out;
+} tpm_cmd_header;
+
+#define TPM_DIGEST_SIZE 20
+struct tpm_pcrread_out {
+        uint8_t      pcr_result[TPM_DIGEST_SIZE];
+}__attribute__((packed));
+
+struct tpm_pcrread_in {
+        uint32_t  pcr_idx;
+}__attribute__((packed));
+
+struct tpm_pcrextend_in {
+        uint32_t  pcr_idx;
+        uint8_t      hash[TPM_DIGEST_SIZE];
+}__attribute__((packed));
+
+typedef union {
+        struct  tpm_getcap_params_out getcap_out;
+        struct  tpm_readpubek_params_out readpubek_out;
+        uint8_t      readpubek_out_buffer[sizeof(struct
tpm_readpubek_params_out)];
+        struct  tpm_getcap_params_in getcap_in;
+        struct  tpm_pcrread_in  pcrread_in;
+        struct  tpm_pcrread_out pcrread_out;
+        struct  tpm_pcrextend_in pcrextend_in;
+} tpm_cmd_params;
+
+struct tpm_cmd_t {
+        tpm_cmd_header  header;
+        tpm_cmd_params  params;
+}__attribute__((packed));
+
+
+enum tpm_duration {
+   TPM_SHORT =3D 0,
+   TPM_MEDIUM =3D 1,
+   TPM_LONG =3D 2,
+   TPM_UNDEFINED,
+};
+
+#define TPM_MAX_ORDINAL 243
+#define TPM_MAX_PROTECTED_ORDINAL 12
+#define TPM_PROTECTED_ORDINAL_MASK 0xFF
+
+extern const uint8_t
tpm_protected_ordinal_duration[TPM_MAX_PROTECTED_ORDINAL];
+extern const uint8_t tpm_ordinal_duration[TPM_MAX_ORDINAL];
+
+#define TPM_DIGEST_SIZE 20
+#define TPM_ERROR_SIZE 10
+#define TPM_RET_CODE_IDX 6
+
+/* tpm_capabilities */
+#define TPM_CAP_FLAG cpu_to_be32(4)
+#define TPM_CAP_PROP cpu_to_be32(5)
+#define CAP_VERSION_1_1 cpu_to_be32(0x06)
+#define CAP_VERSION_1_2 cpu_to_be32(0x1A)
+
+/* tpm_sub_capabilities */
+#define TPM_CAP_PROP_PCR cpu_to_be32(0x101)
+#define TPM_CAP_PROP_MANUFACTURER cpu_to_be32(0x103)
+#define TPM_CAP_FLAG_PERM cpu_to_be32(0x108)
+#define TPM_CAP_FLAG_VOL cpu_to_be32(0x109)
+#define TPM_CAP_PROP_OWNER cpu_to_be32(0x111)
+#define TPM_CAP_PROP_TIS_TIMEOUT cpu_to_be32(0x115)
+#define TPM_CAP_PROP_TIS_DURATION cpu_to_be32(0x120)
+
+
+#define TPM_INTERNAL_RESULT_SIZE 200
+#define TPM_TAG_RQU_COMMAND cpu_to_be16(193)
+#define TPM_ORD_GET_CAP cpu_to_be32(101)
+
+extern const struct tpm_input_header tpm_getcap_header;
+
+
+
+const uint8_t tpm_protected_ordinal_duration[TPM_MAX_PROTECTED_ORDINAL] =
=3D {
+   TPM_UNDEFINED,          /* 0 */
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,          /* 5 */
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_SHORT,              /* 10 */
+   TPM_SHORT,
+};
+
+const uint8_t tpm_ordinal_duration[TPM_MAX_ORDINAL] =3D {
+   TPM_UNDEFINED,          /* 0 */
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,          /* 5 */
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_SHORT,              /* 10 */
+   TPM_SHORT,
+   TPM_MEDIUM,
+   TPM_LONG,
+   TPM_LONG,
+   TPM_MEDIUM,             /* 15 */
+   TPM_SHORT,
+   TPM_SHORT,
+   TPM_MEDIUM,
+   TPM_LONG,
+   TPM_SHORT,              /* 20 */
+   TPM_SHORT,
+   TPM_MEDIUM,
+   TPM_MEDIUM,
+   TPM_MEDIUM,
+   TPM_SHORT,              /* 25 */
+   TPM_SHORT,
+   TPM_MEDIUM,
+   TPM_SHORT,
+   TPM_SHORT,
+   TPM_MEDIUM,             /* 30 */
+   TPM_LONG,
+   TPM_MEDIUM,
+   TPM_SHORT,
+   TPM_SHORT,
+   TPM_SHORT,              /* 35 */
+   TPM_MEDIUM,
+   TPM_MEDIUM,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_MEDIUM,             /* 40 */
+   TPM_LONG,
+   TPM_MEDIUM,
+   TPM_SHORT,
+   TPM_SHORT,
+   TPM_SHORT,              /* 45 */
+   TPM_SHORT,
+   TPM_SHORT,
+   TPM_SHORT,
+   TPM_LONG,
+   TPM_MEDIUM,             /* 50 */
+   TPM_MEDIUM,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,          /* 55 */
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_MEDIUM,             /* 60 */
+   TPM_MEDIUM,
+   TPM_MEDIUM,
+   TPM_SHORT,
+   TPM_SHORT,
+   TPM_MEDIUM,             /* 65 */
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_SHORT,              /* 70 */
+   TPM_SHORT,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,          /* 75 */
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_LONG,               /* 80 */
+   TPM_UNDEFINED,
+   TPM_MEDIUM,
+   TPM_LONG,
+   TPM_SHORT,
+   TPM_UNDEFINED,          /* 85 */
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_SHORT,              /* 90 */
+   TPM_SHORT,
+   TPM_SHORT,
+   TPM_SHORT,
+   TPM_SHORT,
+   TPM_UNDEFINED,          /* 95 */
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_MEDIUM,             /* 100 */
+   TPM_SHORT,
+   TPM_SHORT,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,          /* 105 */
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_SHORT,              /* 110 */
+   TPM_SHORT,
+   TPM_SHORT,
+   TPM_SHORT,
+   TPM_SHORT,
+   TPM_SHORT,              /* 115 */
+   TPM_SHORT,
+   TPM_SHORT,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_LONG,               /* 120 */
+   TPM_LONG,
+   TPM_MEDIUM,
+   TPM_UNDEFINED,
+   TPM_SHORT,
+   TPM_SHORT,              /* 125 */
+   TPM_SHORT,
+   TPM_LONG,
+   TPM_SHORT,
+   TPM_SHORT,
+   TPM_SHORT,              /* 130 */
+   TPM_MEDIUM,
+   TPM_UNDEFINED,
+   TPM_SHORT,
+   TPM_MEDIUM,
+   TPM_UNDEFINED,          /* 135 */
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_SHORT,              /* 140 */
+   TPM_SHORT,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,          /* 145 */
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_SHORT,              /* 150 */
+   TPM_MEDIUM,
+   TPM_MEDIUM,
+   TPM_SHORT,
+   TPM_SHORT,
+   TPM_UNDEFINED,          /* 155 */
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_SHORT,              /* 160 */
+   TPM_SHORT,
+   TPM_SHORT,
+   TPM_SHORT,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,          /* 165 */
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_LONG,               /* 170 */
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,          /* 175 */
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_MEDIUM,             /* 180 */
+   TPM_SHORT,
+   TPM_MEDIUM,
+   TPM_MEDIUM,
+   TPM_MEDIUM,
+   TPM_MEDIUM,             /* 185 */
+   TPM_SHORT,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,          /* 190 */
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,          /* 195 */
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_SHORT,              /* 200 */
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_SHORT,
+   TPM_SHORT,              /* 205 */
+   TPM_SHORT,
+   TPM_SHORT,
+   TPM_SHORT,
+   TPM_SHORT,
+   TPM_MEDIUM,             /* 210 */
+   TPM_UNDEFINED,
+   TPM_MEDIUM,
+   TPM_MEDIUM,
+   TPM_MEDIUM,
+   TPM_UNDEFINED,          /* 215 */
+   TPM_MEDIUM,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_SHORT,
+   TPM_SHORT,              /* 220 */
+   TPM_SHORT,
+   TPM_SHORT,
+   TPM_SHORT,
+   TPM_SHORT,
+   TPM_UNDEFINED,          /* 225 */
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_SHORT,              /* 230 */
+   TPM_LONG,
+   TPM_MEDIUM,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,          /* 235 */
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_SHORT,              /* 240 */
+   TPM_UNDEFINED,
+   TPM_MEDIUM,
+};
+
+const struct tpm_input_header tpm_getcap_header =3D {
+        .tag =3D TPM_TAG_RQU_COMMAND,
+        .length =3D cpu_to_be32(22),
+        .ordinal =3D TPM_ORD_GET_CAP
+};
+
+
+enum tis_access {
+   TPM_ACCESS_VALID =3D 0x80,
+   TPM_ACCESS_ACTIVE_LOCALITY =3D 0x20,    /* (R) */
+   TPM_ACCESS_RELINQUISH_LOCALITY =3D 0x20,/* (W) */
+   TPM_ACCESS_REQUEST_PENDING =3D 0x04,    /* (W) */
+   TPM_ACCESS_REQUEST_USE =3D 0x02,    /* (W) */
+};
+
+enum tis_status {
+   TPM_STS_VALID =3D 0x80,        /* (R) */
+   TPM_STS_COMMAND_READY =3D 0x40,    /* (R) */
+   TPM_STS_DATA_AVAIL =3D 0x10,        /* (R) */
+   TPM_STS_DATA_EXPECT =3D 0x08,        /* (R) */
+   TPM_STS_GO =3D 0x20,            /* (W) */
+};
+
+enum tis_int_flags {
+   TPM_GLOBAL_INT_ENABLE =3D 0x80000000,
+   TPM_INTF_BURST_COUNT_STATIC =3D 0x100,
+   TPM_INTF_CMD_READY_INT =3D 0x080,
+   TPM_INTF_INT_EDGE_FALLING =3D 0x040,
+   TPM_INTF_INT_EDGE_RISING =3D 0x020,
+   TPM_INTF_INT_LEVEL_LOW =3D 0x010,
+   TPM_INTF_INT_LEVEL_HIGH =3D 0x008,
+   TPM_INTF_LOCALITY_CHANGE_INT =3D 0x004,
+   TPM_INTF_STS_VALID_INT =3D 0x002,
+   TPM_INTF_DATA_AVAIL_INT =3D 0x001,
+};
+
+enum tis_defaults {
+   TIS_MEM_BASE =3D 0xFED40000,
+   TIS_MEM_LEN  =3D 0x5000,
+   TIS_SHORT_TIMEOUT =3D 750, /*ms*/
+   TIS_LONG_TIMEOUT =3D 2000, /*2 sec */
+};
+
+#define TPM_TIMEOUT 5
+
+#define TPM_ACCESS(t, l)                   (((uint8_t*)t->pages[l]) +
0x0000)
+#define TPM_INT_ENABLE(t, l)             =20
((uint32_t*)(((uint8_t*)t->pages[l]) + 0x0008))
+#define TPM_INT_VECTOR(t, l)               (((uint8_t*)t->pages[l]) +
0x000C)
+#define TPM_INT_STATUS(t, l)               (((uint8_t*)t->pages[l]) +
0x0010)
+#define TPM_INTF_CAPS(t, l)              =20
((uint32_t*)(((uint8_t*)t->pages[l]) + 0x0014))
+#define TPM_STS(t, l)                    =20
((uint8_t*)(((uint8_t*)t->pages[l]) + 0x0018))
+#define TPM_DATA_FIFO(t, l)                (((uint8_t*)t->pages[l]) +
0x0024)
+
+#define TPM_DID_VID(t, l)                =20
((uint32_t*)(((uint8_t*)t->pages[l]) + 0x0F00))
+#define TPM_RID(t, l)                      (((uint8_t*)t->pages[l]) +
0x0F04)
+
+struct tpm_chip {
+   int enabled_localities;
+   int locality;
+   unsigned long baseaddr;
+   uint8_t* pages[5];
+   int did, vid, rid;
+
+   uint8_t data_buffer[TPM_BUFSIZE];
+   int data_len;
+
+   s_time_t timeout_a, timeout_b, timeout_c, timeout_d;
+   s_time_t duration[3];
+
+#ifdef HAVE_LIBC
+   int fd;
+#endif
+
+   unsigned int irq;
+   struct wait_queue_head read_queue;
+   struct wait_queue_head int_queue;
+};
+
+
+static void __init_tpm_chip(struct tpm_chip* tpm) {
+   tpm->enabled_localities =3D TPM_TIS_EN_LOCLALL;
+   tpm->locality =3D -1;
+   tpm->baseaddr =3D 0;
+   tpm->pages[0] =3D tpm->pages[1] =3D tpm->pages[2] =3D tpm->pages[3] =3D=

tpm->pages[4] =3D NULL;
+   tpm->vid =3D 0;
+   tpm->did =3D 0;
+   tpm->irq =3D 0;
+   init_waitqueue_head(&tpm->read_queue);
+   init_waitqueue_head(&tpm->int_queue);
+
+   tpm->data_len =3D -1;
+
+#ifdef HAVE_LIBC
+   tpm->fd =3D -1;
+#endif
+}
+
+/*
+ * Returns max number of nsecs to wait
+ */
+s_time_t tpm_calc_ordinal_duration(struct tpm_chip *chip,
+      uint32_t ordinal)
+{
+   int duration_idx =3D TPM_UNDEFINED;
+   s_time_t duration =3D 0;
+
+   if (ordinal < TPM_MAX_ORDINAL)
+      duration_idx =3D tpm_ordinal_duration[ordinal];
+   else if ((ordinal & TPM_PROTECTED_ORDINAL_MASK) <
+     TPM_MAX_PROTECTED_ORDINAL)
+      duration_idx =3D
+     tpm_protected_ordinal_duration[ordinal &
+     TPM_PROTECTED_ORDINAL_MASK];
+
+   if (duration_idx !=3D TPM_UNDEFINED) {
+      duration =3D chip->duration[duration_idx];
+   }
+
+   if (duration <=3D 0) {
+      return SECONDS(120);
+   }
+   else
+   {
+      return duration;
+   }
+}
+
+
+static int locality_enabled(struct tpm_chip* tpm, int l) {
+   return tpm->enabled_localities & (1 << l);
+}
+
+static int check_locality(struct tpm_chip* tpm, int l) {
+   if(locality_enabled(tpm, l) && (ioread8(TPM_ACCESS(tpm, l)) &
+        (TPM_ACCESS_ACTIVE_LOCALITY | TPM_ACCESS_VALID)) =3D=3D
+     (TPM_ACCESS_ACTIVE_LOCALITY | TPM_ACCESS_VALID)) {
+      return l;
+   }
+   return -1;
+}
+
+void release_locality(struct tpm_chip* tpm, int l, int force)
+{
+   if (locality_enabled(tpm, l) && (force || (ioread8(TPM_ACCESS(tpm, l)=
) &
+           (TPM_ACCESS_REQUEST_PENDING | TPM_ACCESS_VALID)) =3D=3D
+        (TPM_ACCESS_REQUEST_PENDING | TPM_ACCESS_VALID))) {
+      iowrite8(TPM_ACCESS(tpm, l), TPM_ACCESS_RELINQUISH_LOCALITY);
+   }
+}
+
+int tpm_tis_request_locality(struct tpm_chip* tpm, int l) {
+
+   s_time_t stop;
+   /*Make sure locality is valid */
+   if(!locality_enabled(tpm, l)) {
+      printk("tpm_tis_change_locality() Tried to change to locality %d,
but it is disabled or invalid!\n", l);
+      return -1;
+   }
+   /* Check if we already have the current locality */
+   if(check_locality(tpm, l) >=3D 0) {
+      return tpm->locality =3D l;
+   }
+   /* Set the new locality*/
+   iowrite8(TPM_ACCESS(tpm, l), TPM_ACCESS_REQUEST_USE);
+
+   if(tpm->irq) {
+      /* Wait for interrupt */
+      wait_event_deadline(tpm->int_queue, (check_locality(tpm, l) >=3D
0), NOW() + tpm->timeout_a);
+
+      /* FIXME: Handle timeout event, should return error in that case *=
/
+      return l;
+   } else {
+      /* Wait for burstcount */
+      stop =3D NOW() + tpm->timeout_a;
+      do {
+     if(check_locality(tpm, l) >=3D 0) {
+        return tpm->locality =3D l;
+     }
+     msleep(TPM_TIMEOUT);
+      } while(NOW() < stop);
+   }
+
+   printk("REQ LOCALITY FAILURE\n");
+   return -1;
+}
+
+static uint8_t tpm_tis_status(struct tpm_chip* tpm) {
+   return ioread8(TPM_STS(tpm, tpm->locality));
+}
+
+/* This causes the current command to be aborted */
+static void tpm_tis_ready(struct tpm_chip* tpm) {
+   iowrite8(TPM_STS(tpm, tpm->locality), TPM_STS_COMMAND_READY);
+}
+#define tpm_tis_cancel_cmd(v) tpm_tis_ready(v)
+
+static int get_burstcount(struct tpm_chip* tpm) {
+   s_time_t stop;
+   int burstcnt;
+
+   stop =3D NOW() + tpm->timeout_d;
+   do {
+      burstcnt =3D ioread8((TPM_STS(tpm, tpm->locality) + 1));
+      burstcnt +=3D ioread8(TPM_STS(tpm, tpm->locality) + 2) << 8;
+
+      if (burstcnt) {
+     return burstcnt;
+      }
+      msleep(TPM_TIMEOUT);
+   } while(NOW() < stop);
+   return -EBUSY;
+}
+
+static int wait_for_stat(struct tpm_chip* tpm, uint8_t mask,
+      unsigned long timeout, struct wait_queue_head* queue) {
+   s_time_t stop;
+   uint8_t status;
+
+   status =3D tpm_tis_status(tpm);
+   if((status & mask) =3D=3D mask) {
+      return 0;
+   }
+
+   if(tpm->irq) {
+      wait_event_deadline(*queue, ((tpm_tis_status(tpm) & mask) =3D=3D
mask), timeout);
+      /* FIXME: Check for timeout and return -ETIME */
+      return 0;
+   } else {
+      stop =3D NOW() + timeout;
+      do {
+     msleep(TPM_TIMEOUT);
+     status =3D tpm_tis_status(tpm);
+     if((status & mask) =3D=3D mask)
+        return 0;
+      } while( NOW() < stop);
+   }
+   return -ETIME;
+}
+
+static int recv_data(struct tpm_chip* tpm, uint8_t* buf, size_t count) {=

+   int size =3D 0;
+   int burstcnt;
+   while( size < count &&
+     wait_for_stat(tpm,
+        TPM_STS_DATA_AVAIL | TPM_STS_VALID,
+        tpm->timeout_c,
+        &tpm->read_queue)
+     =3D=3D 0) {
+      burstcnt =3D get_burstcount(tpm);
+      for(; burstcnt > 0 && size < count; --burstcnt)
+      {
+     buf[size++] =3D ioread8(TPM_DATA_FIFO(tpm, tpm->locality));
+      }
+   }
+   return size;
+}
+
+int tpm_tis_recv(struct tpm_chip* tpm, uint8_t* buf, size_t count) {
+   int size =3D 0;
+   int expected, status;
+
+   if (count < TPM_HEADER_SIZE) {
+      size =3D -EIO;
+      goto out;
+   }
+
+   /* read first 10 bytes, including tag, paramsize, and result */
+   if((size =3D
+        recv_data(tpm, buf, TPM_HEADER_SIZE)) < TPM_HEADER_SIZE) {
+      printk("Error reading tpm cmd header\n");
+      goto out;
+   }
+
+   expected =3D be32_to_cpu(*((uint32_t*)(buf + 2)));
+   if(expected > count) {
+      size =3D -EIO;
+      goto out;
+   }
+
+   if((size +=3D recv_data(tpm, & buf[TPM_HEADER_SIZE],
+           expected - TPM_HEADER_SIZE)) < expected) {
+      printk("Unable to read rest of tpm command size=3D%d
expected=3D%d\n", size, expected);
+      size =3D -ETIME;
+      goto out;
+   }
+
+   wait_for_stat(tpm, TPM_STS_VALID, tpm->timeout_c, &tpm->int_queue);
+   status =3D tpm_tis_status(tpm);
+   if(status & TPM_STS_DATA_AVAIL) {
+      printk("Error: left over data\n");
+      size =3D -EIO;
+      goto out;
+   }
+
+out:
+   tpm_tis_ready(tpm);
+   release_locality(tpm, tpm->locality, 0);
+   return size;
+}
+int tpm_tis_send(struct tpm_chip* tpm, uint8_t* buf, size_t len) {
+   int rc;
+   int status, burstcnt =3D 0;
+   int count =3D 0;
+   uint32_t ordinal;
+
+   if(tpm_tis_request_locality(tpm, tpm->locality) < 0) {
+      return -EBUSY;
+   }
+
+   status =3D tpm_tis_status(tpm);
+   if((status & TPM_STS_COMMAND_READY) =3D=3D 0) {
+      tpm_tis_ready(tpm);
+      if(wait_for_stat(tpm, TPM_STS_COMMAND_READY, tpm->timeout_b,
&tpm->int_queue) < 0) {
+     rc =3D -ETIME;
+     goto out_err;
+      }
+   }
+
+   while(count < len - 1) {
+      burstcnt =3D get_burstcount(tpm);
+      for(;burstcnt > 0 && count < len -1; --burstcnt) {
+     iowrite8(TPM_DATA_FIFO(tpm, tpm->locality), buf[count++]);
+      }
+
+      wait_for_stat(tpm, TPM_STS_VALID, tpm->timeout_c, &tpm->int_queue)=
;
+      status =3D tpm_tis_status(tpm);
+      if((status & TPM_STS_DATA_EXPECT) =3D=3D 0) {
+     rc =3D -EIO;
+     goto out_err;
+      }
+   }
+
+   /*Write last byte*/
+   iowrite8(TPM_DATA_FIFO(tpm, tpm->locality), buf[count]);
+   wait_for_stat(tpm, TPM_STS_VALID, tpm->timeout_c, &tpm->read_queue);
+   status =3D tpm_tis_status(tpm);
+   if((status & TPM_STS_DATA_EXPECT) !=3D 0) {
+      rc =3D -EIO;
+      goto out_err;
+   }
+
+   /*go and do it*/
+   iowrite8(TPM_STS(tpm, tpm->locality), TPM_STS_GO);
+
+   if(tpm->irq) {
+      /*Wait for interrupt */
+      ordinal =3D be32_to_cpu(*(buf + 6));
+      if(wait_for_stat(tpm,
+           TPM_STS_DATA_AVAIL | TPM_STS_VALID,
+           tpm_calc_ordinal_duration(tpm, ordinal),
+           &tpm->read_queue) < 0) {
+     rc =3D -ETIME;
+     goto out_err;
+      }
+   }
+#ifdef HAVE_LIBC
+   if(tpm->fd >=3D 0) {
+      files[tpm->fd].read =3D 0;
+      files[tpm->fd].tpm_tis.respgot =3D 0;
+      files[tpm->fd].tpm_tis.offset =3D 0;
+   }
+#endif
+   return len;
+
+out_err:
+   tpm_tis_ready(tpm);
+   release_locality(tpm, tpm->locality, 0);
+   return rc;
+}
+
+static void tpm_tis_irq_handler(evtchn_port_t port, struct pt_regs
*regs, void* data)
+{
+   struct tpm_chip* tpm =3D data;
+   uint32_t interrupt;
+   int i;
+
+   interrupt =3D ioread32(TPM_INT_STATUS(tpm, tpm->locality));
+   if(interrupt =3D=3D 0) {
+      return;
+   }
+
+   if(interrupt & TPM_INTF_DATA_AVAIL_INT) {
+      wake_up(&tpm->read_queue);
+   }
+   if(interrupt & TPM_INTF_LOCALITY_CHANGE_INT) {
+      for(i =3D 0; i < 5; ++i) {
+     if(check_locality(tpm, i) >=3D 0) {
+        break;
+     }
+      }
+   }
+   if(interrupt & (TPM_INTF_LOCALITY_CHANGE_INT | TPM_INTF_STS_VALID_INT=
 |
+        TPM_INTF_CMD_READY_INT)) {
+      wake_up(&tpm->int_queue);
+   }
+
+   /* Clear interrupts handled with TPM_EOI */
+   iowrite32(TPM_INT_STATUS(tpm, tpm->locality), interrupt);
+   ioread32(TPM_INT_STATUS(tpm, tpm->locality));
+   return;
+}
+
+/*
+ * Internal kernel interface to transmit TPM commands
+ */
+static ssize_t tpm_transmit(struct tpm_chip *chip, const uint8_t *buf,
+      size_t bufsiz)
+{
+   ssize_t rc;
+   uint32_t count, ordinal;
+   s_time_t stop;
+
+   count =3D be32_to_cpu(*((uint32_t *) (buf + 2)));
+   ordinal =3D be32_to_cpu(*((uint32_t *) (buf + 6)));
+   if (count =3D=3D 0)
+      return -ENODATA;
+   if (count > bufsiz) {
+      printk("Error: invalid count value %x %zx \n", count, bufsiz);
+      return -E2BIG;
+   }
+
+   //down(&chip->tpm_mutex);
+
+   if ((rc =3D tpm_tis_send(chip, (uint8_t *) buf, count)) < 0) {
+      printk("tpm_transmit: tpm_send: error %zd\n", rc);
+      goto out;
+   }
+
+   if (chip->irq)
+      goto out_recv;
+
+   stop =3D NOW() + tpm_calc_ordinal_duration(chip, ordinal);
+   do {
+      uint8_t status =3D tpm_tis_status(chip);
+      if ((status & (TPM_STS_DATA_AVAIL | TPM_STS_VALID)) =3D=3D
+        (TPM_STS_DATA_AVAIL | TPM_STS_VALID))
+     goto out_recv;
+
+      if ((status =3D=3D TPM_STS_COMMAND_READY)) {
+     printk("TPM Error: Operation Canceled\n");
+     rc =3D -ECANCELED;
+     goto out;
+      }
+
+      msleep(TPM_TIMEOUT);    /* CHECK */
+      rmb();
+   } while (NOW() < stop);
+
+   /* Cancel the command */
+   tpm_tis_cancel_cmd(chip);
+   printk("TPM Operation Timed out\n");
+   rc =3D -ETIME;
+   goto out;
+
+out_recv:
+   if((rc =3D tpm_tis_recv(chip, (uint8_t *) buf, bufsiz)) < 0) {
+      printk("tpm_transmit: tpm_recv: error %d\n", rc);
+   }
+out:
+   //up(&chip->tpm_mutex);
+   return rc;
+}
+
+static ssize_t transmit_cmd(struct tpm_chip *chip, struct tpm_cmd_t *cmd=
,
+                            int len, const char *desc)
+{
+        int err;
+
+        len =3D tpm_transmit(chip,(uint8_t *) cmd, len);
+        if (len <  0)
+                return len;
+        if (len =3D=3D TPM_ERROR_SIZE) {
+                err =3D be32_to_cpu(cmd->header.out.return_code);
+                printk("A TPM error (%d) occurred %s\n", err, desc);
+                return err;
+        }
+        return 0;
+}
+
+void tpm_get_timeouts(struct tpm_chip *chip)
+{
+   struct tpm_cmd_t tpm_cmd;
+   struct timeout_t *timeout_cap;
+   struct duration_t *duration_cap;
+   ssize_t rc;
+   uint32_t timeout;
+
+   tpm_cmd.header.in =3D tpm_getcap_header;
+   tpm_cmd.params.getcap_in.cap =3D TPM_CAP_PROP;
+   tpm_cmd.params.getcap_in.subcap_size =3D cpu_to_be32(4);
+   tpm_cmd.params.getcap_in.subcap =3D TPM_CAP_PROP_TIS_TIMEOUT;
+
+   if((rc =3D transmit_cmd(chip, &tpm_cmd, TPM_INTERNAL_RESULT_SIZE,
+     "attempting to determine the timeouts")) !=3D 0) {
+      printk("transmit failed %d\n", rc);
+      goto duration;
+   }
+
+   if (be32_to_cpu(tpm_cmd.params.getcap_out.cap_size)
+     !=3D 4 * sizeof(uint32_t)) {
+      printk("Out len check failure %lu \n",
be32_to_cpu(tpm_cmd.header.out.length));
+      goto duration;
+   }
+
+   timeout_cap =3D &tpm_cmd.params.getcap_out.cap.timeout;
+   /* Don't overwrite default if value is 0 */
+   timeout =3D be32_to_cpu(timeout_cap->a);
+   if (timeout)
+      chip->timeout_a =3D MICROSECS(timeout); /*Convert to msec */
+   timeout =3D be32_to_cpu(timeout_cap->b);
+   if (timeout)
+      chip->timeout_b =3D MICROSECS(timeout); /*Convert to msec */
+   timeout =3D be32_to_cpu(timeout_cap->c);
+   if (timeout)
+      chip->timeout_c =3D MICROSECS(timeout); /*Convert to msec */
+   timeout =3D be32_to_cpu(timeout_cap->d);
+   if (timeout)
+      chip->timeout_d =3D MICROSECS(timeout); /*Convert to msec */
+
+duration:
+   tpm_cmd.header.in =3D tpm_getcap_header;
+   tpm_cmd.params.getcap_in.cap =3D TPM_CAP_PROP;
+   tpm_cmd.params.getcap_in.subcap_size =3D cpu_to_be32(4);
+   tpm_cmd.params.getcap_in.subcap =3D TPM_CAP_PROP_TIS_DURATION;
+
+   if((rc =3D transmit_cmd(chip, &tpm_cmd, TPM_INTERNAL_RESULT_SIZE,
+     "attempting to determine the durations")) < 0) {
+      return;
+   }
+
+   if (be32_to_cpu(tpm_cmd.params.getcap_out.cap_size)
+     !=3D 3 * sizeof(uint32_t)) {
+      return;
+   }
+        duration_cap =3D &tpm_cmd.params.getcap_out.cap.duration;
+        chip->duration[TPM_SHORT] =3D be32_to_cpu(duration_cap->tpm_shor=
t);
+        /* The Broadcom BCM0102 chipset in a Dell Latitude D820 gets
the above
+         * value wrong and apparently reports msecs rather than usecs.
So we
+         * fix up the resulting too-small TPM_SHORT value to make
things work.
+         */
+        if (chip->duration[TPM_SHORT] < 10) {
+       chip->duration[TPM_SHORT] =3D MILLISECS(chip->duration[TPM_SHORT]=
);
+    } else {
+       chip->duration[TPM_SHORT] =3D MICROSECS(chip->duration[TPM_SHORT]=
);
+    }
+
+        chip->duration[TPM_MEDIUM] =3D
MICROSECS(be32_to_cpu(duration_cap->tpm_medium));
+        chip->duration[TPM_LONG] =3D
MICROSECS(be32_to_cpu(duration_cap->tpm_long));
+}
+
+
+
+void tpm_continue_selftest(struct tpm_chip* chip) {
+   uint8_t data[] =3D {
+      0, 193,                 /* TPM_TAG_RQU_COMMAND */
+      0, 0, 0, 10,            /* length */
+      0, 0, 0, 83,            /* TPM_ORD_GetCapability */
+   };
+
+   tpm_transmit(chip, data, sizeof(data));
+}
+
+ssize_t tpm_getcap(struct tpm_chip *chip, uint32_t subcap_id, cap_t *cap=
,
+                   const char *desc)
+{
+        struct tpm_cmd_t tpm_cmd;
+        int rc;
+
+        tpm_cmd.header.in =3D tpm_getcap_header;
+        if (subcap_id =3D=3D CAP_VERSION_1_1 || subcap_id =3D=3D CAP_VER=
SION_1_2) {
+                tpm_cmd.params.getcap_in.cap =3D subcap_id;
+                /*subcap field not necessary */
+                tpm_cmd.params.getcap_in.subcap_size =3D cpu_to_be32(0);=

+                tpm_cmd.header.in.length -=3D cpu_to_be32(sizeof(uint32_=
t));
+        } else {
+                if (subcap_id =3D=3D TPM_CAP_FLAG_PERM ||
+                    subcap_id =3D=3D TPM_CAP_FLAG_VOL)
+                        tpm_cmd.params.getcap_in.cap =3D TPM_CAP_FLAG;
+                else
+                        tpm_cmd.params.getcap_in.cap =3D TPM_CAP_PROP;
+                tpm_cmd.params.getcap_in.subcap_size =3D cpu_to_be32(4);=

+                tpm_cmd.params.getcap_in.subcap =3D subcap_id;
+        }
+        rc =3D transmit_cmd(chip, &tpm_cmd, TPM_INTERNAL_RESULT_SIZE, de=
sc);
+        if (!rc)
+                *cap =3D tpm_cmd.params.getcap_out.cap;
+        return rc;
+}
+
+
+struct tpm_chip* init_tpm_tis(unsigned long baseaddr, int localities,
unsigned int irq)
+{
+   int i;
+   unsigned long addr;
+   struct tpm_chip* tpm =3D NULL;
+   uint32_t didvid;
+   uint32_t intfcaps;
+   uint32_t intmask;
+
+   printk("=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Init TPM TIS Driver =3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D\n");
+
+   /*Sanity check the localities input */
+   if(localities & ~TPM_TIS_EN_LOCLALL) {
+      printk("init_tpm_tis() Invalid locality specification! %X\n",
localities);
+      goto abort_egress;
+   }
+
+   printk("IOMEM Machine Base Address: %lX\n", baseaddr);
+
+   /* Create the tpm data structure */
+   tpm =3D malloc(sizeof(struct tpm_chip));
+   __init_tpm_chip(tpm);
+
+   /* Set the enabled localities - if 0 we leave default as all enabled =
*/
+   if(localities !=3D 0) {
+      tpm->enabled_localities =3D localities;
+   }
+   printk("Enabled Localities: ");
+   for(i =3D 0; i < 5; ++i) {
+      if(locality_enabled(tpm, i)) {
+     printk("%d ", i);
+      }
+   }
+   printk("\n");
+
+   /* Set the base machine address */
+   tpm->baseaddr =3D baseaddr;
+
+   /* Set default timeouts */
+   tpm->timeout_a =3D MILLISECS(TIS_SHORT_TIMEOUT);
+   tpm->timeout_b =3D MILLISECS(TIS_LONG_TIMEOUT);
+   tpm->timeout_c =3D MILLISECS(TIS_SHORT_TIMEOUT);
+   tpm->timeout_d =3D MILLISECS(TIS_SHORT_TIMEOUT);
+
+   /*Map the mmio pages */
+   addr =3D tpm->baseaddr;
+   for(i =3D 0; i < 5; ++i) {
+      if(locality_enabled(tpm, i)) {
+     /* Map the page in now */
+     if((tpm->pages[i] =3D ioremap_nocache(addr, PAGE_SIZE)) =3D=3D NULL=
) {
+        printk("Unable to map iomem page a address %p\n", addr);
+        goto abort_egress;
+     }
+
+     /* Set default locality to the first enabled one */
+     if (tpm->locality < 0) {
+        if(tpm_tis_request_locality(tpm, i) < 0) {
+           printk("Unable to request locality %d??\n", i);
+           goto abort_egress;
+        }
+     }
+      }
+      addr +=3D PAGE_SIZE;
+   }
+
+
+   /* Get the vendor and device ids */
+   didvid =3D ioread32(TPM_DID_VID(tpm, tpm->locality));
+   tpm->did =3D didvid >> 16;
+   tpm->vid =3D didvid & 0xFFFF;
+
+
+   /* Get the revision id */
+   tpm->rid =3D ioread8(TPM_RID(tpm, tpm->locality));
+
+   printk("1.2 TPM (device-id=3D0x%X vendor-id =3D %X rev-id =3D %X)\n",=

tpm->did, tpm->vid, tpm->rid);
+
+   intfcaps =3D ioread32(TPM_INTF_CAPS(tpm, tpm->locality));
+   printk("TPM interface capabilities (0x%x):\n", intfcaps);
+   if (intfcaps & TPM_INTF_BURST_COUNT_STATIC)
+      printk("\tBurst Count Static\n");
+   if (intfcaps & TPM_INTF_CMD_READY_INT)
+      printk("\tCommand Ready Int Support\n");
+   if (intfcaps & TPM_INTF_INT_EDGE_FALLING)
+      printk("\tInterrupt Edge Falling\n");
+   if (intfcaps & TPM_INTF_INT_EDGE_RISING)
+      printk("\tInterrupt Edge Rising\n");
+   if (intfcaps & TPM_INTF_INT_LEVEL_LOW)
+      printk("\tInterrupt Level Low\n");
+   if (intfcaps & TPM_INTF_INT_LEVEL_HIGH)
+      printk("\tInterrupt Level High\n");
+   if (intfcaps & TPM_INTF_LOCALITY_CHANGE_INT)
+      printk("\tLocality Change Int Support\n");
+   if (intfcaps & TPM_INTF_STS_VALID_INT)
+      printk("\tSts Valid Int Support\n");
+   if (intfcaps & TPM_INTF_DATA_AVAIL_INT)
+      printk("\tData Avail Int Support\n");
+
+   /*Interupt setup */
+   intmask =3D ioread32(TPM_INT_ENABLE(tpm, tpm->locality));
+
+   intmask |=3D TPM_INTF_CMD_READY_INT
+      | TPM_INTF_LOCALITY_CHANGE_INT | TPM_INTF_DATA_AVAIL_INT
+      | TPM_INTF_STS_VALID_INT;
+
+   iowrite32(TPM_INT_ENABLE(tpm, tpm->locality), intmask);
+
+   /*If interupts are enabled, handle it */
+   if(irq) {
+      if(irq !=3D TPM_PROBE_IRQ) {
+     tpm->irq =3D irq;
+      } else {
+     /*FIXME add irq probing feature later */
+     printk("IRQ probing not implemented\n");
+      }
+   }
+
+   if(tpm->irq) {
+      iowrite8(TPM_INT_VECTOR(tpm, tpm->locality), tpm->irq);
+
+      if(bind_pirq(tpm->irq, 1, tpm_tis_irq_handler, tpm) !=3D 0) {
+     printk("Unabled to request irq: %u for use\n", tpm->irq);
+     printk("Will use polling mode\n");
+     tpm->irq =3D 0;
+      } else {
+     /* Clear all existing */
+     iowrite32(TPM_INT_STATUS(tpm, tpm->locality),
ioread32(TPM_INT_STATUS(tpm, tpm->locality)));
+
+     /* Turn on interrupts */
+     iowrite32(TPM_INT_ENABLE(tpm, tpm->locality), intmask |
TPM_GLOBAL_INT_ENABLE);
+      }
+   }
+
+   tpm_get_timeouts(tpm);
+   tpm_continue_selftest(tpm);
+
+
+   return tpm;
+abort_egress:
+   if(tpm !=3D NULL) {
+      shutdown_tpm_tis(tpm);
+   }
+   return NULL;
+}
+
+void shutdown_tpm_tis(struct tpm_chip* tpm){
+   int i;
+
+   printk("Shutting down tpm_tis device\n");
+
+   iowrite32(TPM_INT_ENABLE(tpm, tpm->locality), ~TPM_GLOBAL_INT_ENABLE)=
;
+
+   /*Unmap all of the mmio pages */
+   for(i =3D 0; i < 5; ++i) {
+      if(tpm->pages[i] !=3D NULL) {
+     iounmap(tpm->pages[i], PAGE_SIZE);
+     tpm->pages[i] =3D NULL;
+      }
+   }
+   free(tpm);
+   return;
+}
+
+
+int tpm_tis_cmd(struct tpm_chip* tpm, uint8_t* req, size_t reqlen,
uint8_t** resp, size_t* resplen)
+{
+   if(tpm->locality < 0) {
+      printk("tpm_tis_cmd() failed! locality not set!\n");
+      return -1;
+   }
+   if(reqlen > TPM_BUFSIZE) {
+      reqlen =3D TPM_BUFSIZE;
+   }
+   memcpy(tpm->data_buffer, req, reqlen);
+   *resplen =3D tpm_transmit(tpm, tpm->data_buffer, TPM_BUFSIZE);
+
+   *resp =3D malloc(*resplen);
+   memcpy(*resp, tpm->data_buffer, *resplen);
+   return 0;
+}
+
+#ifdef HAVE_LIBC
+int tpm_tis_open(struct tpm_chip* tpm)
+{
+   /* Silently prevent multiple opens */
+   if(tpm->fd !=3D -1) {
+      return tpm->fd;
+   }
+
+   tpm->fd =3D alloc_fd(FTYPE_TPM_TIS);
+   printk("tpm_tis_open() -> %d\n", tpm->fd);
+   files[tpm->fd].tpm_tis.dev =3D tpm;
+   files[tpm->fd].tpm_tis.offset =3D 0;
+   files[tpm->fd].tpm_tis.respgot =3D 0;
+   return tpm->fd;
+}
+
+int tpm_tis_posix_write(int fd, const uint8_t* buf, size_t count)
+{
+   struct tpm_chip* tpm;
+   tpm =3D files[fd].tpm_tis.dev;
+
+   if(tpm->locality < 0) {
+      printk("tpm_tis_posix_write() failed! locality not set!\n");
+      errno =3D EINPROGRESS;
+      return -1;
+   }
+   if(count =3D=3D 0) {
+      return 0;
+   }
+
+   /* Return an error if we are already processing a command */
+   if(count > TPM_BUFSIZE) {
+      count =3D TPM_BUFSIZE;
+   }
+   /* Send the command now */
+   memcpy(tpm->data_buffer, buf, count);
+   if((tpm->data_len =3D tpm_transmit(tpm, tpm->data_buffer,
TPM_BUFSIZE)) < 0) {
+      errno =3D EIO;
+      return -1;
+   }
+   return count;
+}
+
+int tpm_tis_posix_read(int fd, uint8_t* buf, size_t count)
+{
+   int rc;
+   struct tpm_chip* tpm;
+   tpm =3D files[fd].tpm_tis.dev;
+
+   if(count =3D=3D 0) {
+      return 0;
+   }
+
+   /* If there is no tpm resp to read, return EIO */
+   if(tpm->data_len < 0) {
+      errno =3D EIO;
+      return -1;
+   }
+
+
+   /* Handle EOF case */
+   if(files[fd].tpm_tis.offset >=3D tpm->data_len) {
+      rc =3D 0;
+   } else {
+      rc =3D min(tpm->data_len - files[fd].tpm_tis.offset, count);
+      memcpy(buf, tpm->data_buffer + files[fd].tpm_tis.offset, rc);
+   }
+   files[fd].tpm_tis.offset +=3D rc;
+   /* Reset the data pending flag */
+   return rc;
+}
+int tpm_tis_posix_fstat(int fd, struct stat* buf)
+{
+   struct tpm_chip* tpm;
+   tpm =3D files[fd].tpm_tis.dev;
+
+   buf->st_mode =3D O_RDWR;
+   buf->st_uid =3D 0;
+   buf->st_gid =3D 0;
+   buf->st_size =3D be32_to_cpu(*((uint32_t*)(tpm->data_buffer + 2)));
+   buf->st_atime =3D buf->st_mtime =3D buf->st_ctime =3D time(NULL);
+   return 0;
+}
+
+
+#endif
diff --git a/extras/mini-os/tpmback.c b/extras/mini-os/tpmback.c
--- /dev/null
+++ b/extras/mini-os/tpmback.c
@@ -0,0 +1,1114 @@
+/*
+ * Copyright (c) 2010-2012 United States Government, as represented by
+ * the Secretary of Defense.  All rights reserved.
+ *
+ * This driver 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 3 of the License, or
+ * (at your option) any later version.
+ *
+ * This driver is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program.  If not, see <http://www.gnu.org/licenses/>.=

+ *
+ * Based upon the files:
+ *  drivers/xen/tpmbk.c
+ * from the Linux kernel, which are Copyright (C) 2006 IBM Corporation
+ */
+#include <mini-os/os.h>
+#include <mini-os/xenbus.h>
+#include <mini-os/events.h>
+#include <errno.h>
+#include <mini-os/gnttab.h>
+#include <xen/io/xenbus.h>
+#include <xen/io/tpmif.h>
+#include <xen/io/protocols.h>
+#include <mini-os/xmalloc.h>
+#include <time.h>
+#include <mini-os/tpmback.h>
+#include <mini-os/lib.h>
+#include <fcntl.h>
+#include <mini-os/mm.h>
+#include <mini-os/posix/sys/mman.h>
+#include <mini-os/semaphore.h>
+#include <mini-os/wait.h>
+
+
+#ifndef HAVE_LIBC
+#define strtoul simple_strtoul
+#endif
+
+//#define TPMBACK_PRINT_DEBUG
+#ifdef TPMBACK_PRINT_DEBUG
+#define TPMBACK_DEBUG(fmt,...) printk("Tpmback:Debug("__FILE__":%d) "
fmt, __LINE__, ##__VA_ARGS__)
+#define TPMBACK_DEBUG_MORE(fmt,...) printk(fmt, ##__VA_ARGS__)
+#else
+#define TPMBACK_DEBUG(fmt,...)
+#endif
+#define TPMBACK_ERR(fmt,...) printk("Tpmback:Error " fmt, ##__VA_ARGS__)=

+#define TPMBACK_LOG(fmt,...) printk("Tpmback:Info " fmt, ##__VA_ARGS__)
+
+#define min(a,b) (((a) < (b)) ? (a) : (b))
+
+/* Default size of the tpmif array at initialization */
+#define DEF_ARRAY_SIZE 1
+
+/* tpmif and tpmdev flags */
+#define TPMIF_CLOSED 1
+#define TPMIF_REQ_READY 2
+
+struct tpmif {
+   domid_t domid;
+   unsigned int handle;
+
+   char* fe_path;
+   char* fe_state_path;
+
+   /* Locally bound event channel*/
+   evtchn_port_t evtchn;
+
+   /* Shared page */
+   tpmif_tx_interface_t* tx;
+
+   /* pointer to TPMIF_RX_RING_SIZE pages */
+   void** pages;
+
+   enum xenbus_state state;
+   enum { DISCONNECTED, DISCONNECTING, CONNECTED } status;
+
+   char* uuid;
+
+   /* state flags */
+   int flags;
+};
+typedef struct tpmif tpmif_t;
+
+struct tpmback_dev {
+
+   tpmif_t** tpmlist;
+   unsigned long num_tpms;
+   unsigned long num_alloc;
+
+   struct gntmap map;
+
+   /* True if at least one tpmif has a request to be handled */
+   int flags;
+
+   /* exclusive domains, see init_tpmback comment in tpmback.h */
+   char** exclusive_uuids;
+
+   xenbus_event_queue events;
+
+   /* Callbacks */
+   void (*open_callback)(domid_t, unsigned int);
+   void (*close_callback)(domid_t, unsigned int);
+   void (*suspend_callback)(domid_t, unsigned int);
+   void (*resume_callback)(domid_t, unsigned int);
+};
+typedef struct tpmback_dev tpmback_dev_t;
+
+enum { EV_NONE, EV_NEWFE, EV_STCHNG } tpm_ev_enum;
+
+/* Global objects */
+static struct thread* eventthread =3D NULL;
+static tpmback_dev_t gtpmdev =3D {
+   .tpmlist =3D NULL,
+   .num_tpms =3D 0,
+   .num_alloc =3D 0,
+   .flags =3D TPMIF_CLOSED,
+   .events =3D NULL,
+   .open_callback =3D NULL,
+   .close_callback =3D NULL,
+   .suspend_callback =3D NULL,
+   .resume_callback =3D NULL,
+};
+struct wait_queue_head waitq;
+int globalinit =3D 0;
+
+/************************************
+ * TPMIF SORTED ARRAY FUNCTIONS
+ * tpmback_dev_t.tpmlist is a sorted array, sorted by domid and then
handle number
+ * Duplicates are not allowed
+ * **********************************/
+
+inline void tpmif_req_ready(tpmif_t* tpmif) {
+   tpmif->flags |=3D TPMIF_REQ_READY;
+   gtpmdev.flags |=3D TPMIF_REQ_READY;
+}
+
+inline void tpmdev_check_req(void) {
+   int i;
+   int flags;
+   local_irq_save(flags);
+   for(i =3D 0; i < gtpmdev.num_tpms; ++i) {
+      if(gtpmdev.tpmlist[i]->flags & TPMIF_REQ_READY) {
+     gtpmdev.flags |=3D TPMIF_REQ_READY;
+     local_irq_restore(flags);
+     return;
+      }
+   }
+   gtpmdev.flags &=3D ~TPMIF_REQ_READY;
+   local_irq_restore(flags);
+}
+
+inline void tpmif_req_finished(tpmif_t* tpmif) {
+   tpmif->flags &=3D ~TPMIF_REQ_READY;
+   tpmdev_check_req();
+}
+
+int __get_tpmif_index(int st, int n, domid_t domid, unsigned int handle)=

+{
+   int i =3D st + n /2;
+   tpmif_t* tmp;
+
+   if( n <=3D 0 )
+      return -1;
+
+   tmp =3D gtpmdev.tpmlist[i];
+   if(domid =3D=3D tmp->domid && tmp->handle =3D=3D handle) {
+      return i;
+   } else if ( (domid < tmp->domid) ||
+     (domid =3D=3D tmp->domid && handle < tmp->handle)) {
+      return __get_tpmif_index(st, n/2, domid, handle);
+   } else {
+      return __get_tpmif_index(i + 1, n/2 - ((n +1) % 2), domid, handle)=
;
+   }
+}
+
+/* Returns the array index of the tpmif domid/handle. Returns -1 if no
such tpmif exists */
+int get_tpmif_index(domid_t domid, unsigned int handle)
+{
+   int flags;
+   int index;
+   local_irq_save(flags);
+   index =3D __get_tpmif_index(0, gtpmdev.num_tpms, domid, handle);
+   local_irq_restore(flags);
+   return index;
+}
+
+/* Returns the tpmif domid/handle or NULL if none exists */
+tpmif_t* get_tpmif(domid_t domid, unsigned int handle)
+{
+   int flags;
+   int i;
+   tpmif_t* ret;
+   local_irq_save(flags);
+   i =3D get_tpmif_index(domid, handle);
+   if (i < 0) {
+      ret =3D NULL;
+   } else {
+      ret =3D gtpmdev.tpmlist[i];
+   }
+   local_irq_restore(flags);
+   return ret;
+}
+
+/* Remove the given tpmif. Returns 0 if it was removed, -1 if it was
not removed */
+int remove_tpmif(tpmif_t* tpmif)
+{
+   int i, j;
+   char* err;
+   int flags;
+   local_irq_save(flags);
+
+   /* Find the index in the array if it exists */
+   i =3D get_tpmif_index(tpmif->domid, tpmif->handle);
+   if (i < 0) {
+      goto error;
+   }
+
+   /* Remove the interface from the list */
+   for(j =3D i; j < gtpmdev.num_tpms - 1; ++j) {
+      gtpmdev.tpmlist[j] =3D gtpmdev.tpmlist[j+1];
+   }
+   gtpmdev.tpmlist[j] =3D NULL;
+   --gtpmdev.num_tpms;
+
+   /* If removed tpm was the only ready tpm, then we need to check and
turn off the ready flag */
+   tpmdev_check_req();
+
+   local_irq_restore(flags);
+
+   /* Stop listening for events on this tpm interface */
+   if((err =3D xenbus_unwatch_path_token(XBT_NIL, tpmif->fe_state_path,
tpmif->fe_state_path))) {
+      TPMBACK_ERR("Unable to unwatch path token `%s' Error was %s
Ignoring..\n", tpmif->fe_state_path, err);
+      free(err);
+   }
+
+   return 0;
+error:
+   local_irq_restore(flags);
+   return -1;
+}
+
+/* Insert tpmif into dev->tpmlist. Returns 0 on success and non zero on
error.
+ * It is an error to insert a tpmif with the same domid and handle
+ * number
+ * as something already in the list */
+int insert_tpmif(tpmif_t* tpmif)
+{
+   int flags;
+   unsigned int i, j;
+   tpmif_t* tmp;
+   char* err;
+
+   local_irq_save(flags);
+
+   /*Check if we need to allocate more space */
+   if (gtpmdev.num_tpms =3D=3D gtpmdev.num_alloc) {
+      gtpmdev.num_alloc *=3D 2;
+      gtpmdev.tpmlist =3D realloc(gtpmdev.tpmlist, gtpmdev.num_alloc);
+   }
+
+   /*Find where to put the new interface */
+   for(i =3D 0; i < gtpmdev.num_tpms; ++i)
+   {
+      tmp =3D gtpmdev.tpmlist[i];
+      if(tpmif->domid =3D=3D tmp->domid && tpmif->handle =3D=3D tmp->han=
dle) {
+     TPMBACK_ERR("Tried to insert duplicate tpm interface %u/%u\n",
(unsigned int) tpmif->domid, tpmif->handle);
+     goto error;
+      }
+      if((tpmif->domid < tmp->domid) ||
+        (tpmif->domid =3D=3D tmp->domid && tpmif->handle < tmp->handle))=
 {
+     break;
+      }
+   }
+
+   /*Shift all the tpm pointers past i down one */
+   for(j =3D gtpmdev.num_tpms; j > i; --j) {
+      gtpmdev.tpmlist[j] =3D gtpmdev.tpmlist[j-1];
+   }
+
+   /*Add the new interface */
+   gtpmdev.tpmlist[i] =3D tpmif;
+   ++gtpmdev.num_tpms;
+
+   /*Should not be needed, anything inserted with ready flag is
probably an error */
+   tpmdev_check_req();
+
+   local_irq_restore(flags);
+
+   /*Listen for state changes on the new interface */
+   if((err =3D xenbus_watch_path_token(XBT_NIL, tpmif->fe_state_path,
tpmif->fe_state_path, &gtpmdev.events)))
+   {
+      /* if we got an error here we should carefully remove the
interface and then return */
+      TPMBACK_ERR("Unable to watch path token `%s' Error was %s\n",
tpmif->fe_state_path, err);
+      free(err);
+      remove_tpmif(tpmif);
+      goto error_post_irq;
+   }
+
+   return 0;
+error:
+   local_irq_restore(flags);
+error_post_irq:
+   return -1;
+}
+
+
+/*****************
+ * CHANGE BACKEND STATE
+ * *****************/
+/*Attempts to change the backend state in xenstore
+ * returns 0 on success and non-zero on error */
+int tpmif_change_state(tpmif_t* tpmif, enum xenbus_state state)
+{
+   char path[512];
+   char *value;
+   char *err;
+   enum xenbus_state readst;
+   TPMBACK_DEBUG("Backend state change %u/%u from=3D%d to=3D%d\n",
(unsigned int) tpmif->domid, tpmif->handle, tpmif->state, state);
+   if (tpmif->state =3D=3D state)
+      return 0;
+
+   snprintf(path, 512, "backend/vtpm/%u/%u/state", (unsigned int)
tpmif->domid, tpmif->handle);
+
+   if((err =3D xenbus_read(XBT_NIL, path, &value))) {
+      TPMBACK_ERR("Unable to read backend state %s, error was %s\n",
path, err);
+      free(err);
+      return -1;
+   }
+   if(sscanf(value, "%d", &readst) !=3D 1) {
+      TPMBACK_ERR("Non integer value (%s) in %s ??\n", value, path);
+      free(value);
+      return -1;
+   }
+   free(value);
+
+   /* It's possible that the backend state got updated by hotplug or
something else behind our back */
+   if(readst !=3D tpmif->state) {
+      TPMBACK_DEBUG("tpm interface state was %d but xenstore state was
%d!\n", tpmif->state, readst);
+      tpmif->state =3D readst;
+   }
+
+   /*If if the state isnt changing, then we dont update xenstore b/c we
dont want to fire extraneous events */
+   if(tpmif->state =3D=3D state) {
+      return 0;
+   }
+
+   /*update xenstore*/
+   snprintf(path, 512, "backend/vtpm/%u/%u", (unsigned int)
tpmif->domid, tpmif->handle);
+   if((err =3D xenbus_printf(XBT_NIL, path, "state", "%u", state))) {
+      TPMBACK_ERR("Error writing to xenstore %s, error was %s new
state=3D%d\n", path, err, state);
+      free(err);
+      return -1;
+   }
+
+   tpmif->state =3D state;
+
+   return 0;
+}
+/**********************************
+ * TPMIF CREATION AND DELETION
+ * *******************************/
+inline tpmif_t* __init_tpmif(domid_t domid, unsigned int handle)
+{
+   tpmif_t* tpmif;
+   tpmif =3D malloc(sizeof(*tpmif));
+   tpmif->domid =3D domid;
+   tpmif->handle =3D handle;
+   tpmif->fe_path =3D NULL;
+   tpmif->fe_state_path =3D NULL;
+   tpmif->state =3D XenbusStateInitialising;
+   tpmif->status =3D DISCONNECTED;
+   tpmif->tx =3D NULL;
+   tpmif->pages =3D NULL;
+   tpmif->flags =3D 0;
+   tpmif->uuid =3D NULL;
+   return tpmif;
+}
+
+void __free_tpmif(tpmif_t* tpmif)
+{
+   if(tpmif->pages) {
+      free(tpmif->pages);
+   }
+   if(tpmif->fe_path) {
+      free(tpmif->fe_path);
+   }
+   if(tpmif->fe_state_path) {
+      free(tpmif->fe_state_path);
+   }
+   if(tpmif->uuid) {
+      free(tpmif->uuid);
+   }
+   free(tpmif);
+}
+/* Creates a new tpm interface, adds it to the sorted array and returns =
it.
+ * returns NULL on error
+ * If the tpm interface already exists, it is returned*/
+tpmif_t* new_tpmif(domid_t domid, unsigned int handle)
+{
+   tpmif_t* tpmif;
+   char* err;
+   char path[512];
+
+   /* Make sure we haven't already created this tpm
+    * Double events can occur */
+   if((tpmif =3D get_tpmif(domid, handle)) !=3D NULL) {
+      return tpmif;
+   }
+
+   tpmif =3D __init_tpmif(domid, handle);
+
+   /* Get the uuid from xenstore */
+   snprintf(path, 512, "backend/vtpm/%u/%u/uuid", (unsigned int) domid,
handle);
+   if((err =3D xenbus_read(XBT_NIL, path, &tpmif->uuid))) {
+      TPMBACK_ERR("Error reading %s, Error =3D %s\n", path, err);
+      free(err);
+      goto error;
+   }
+
+   /* Do the exclusive uuid check now */
+   if(gtpmdev.exclusive_uuids !=3D NULL) {
+      char** ptr;
+
+      /* Check that its in the whitelist */
+      for(ptr =3D gtpmdev.exclusive_uuids; *ptr !=3D NULL; ++ptr) {
+     if(!strcmp(tpmif->uuid, *ptr)) {
+        break;
+     }
+      }
+      /* If *ptr =3D=3D NULL then we went through the whole list without=
 a
match, so close the connection */
+      if(*ptr =3D=3D NULL) {
+     tpmif_change_state(tpmif, XenbusStateClosed);
+     TPMBACK_ERR("Frontend %u/%u tried to connect with invalid
uuid=3D%s\n", (unsigned int) domid, handle, tpmif->uuid);
+     goto error;
+      }
+   }
+
+   /* allocate pages to be used for shared mapping */
+   if((tpmif->pages =3D malloc(sizeof(void*) * TPMIF_TX_RING_SIZE)) =3D=3D=

NULL) {
+      goto error;
+   }
+   memset(tpmif->pages, 0, sizeof(void*) * TPMIF_TX_RING_SIZE);
+
+   if(tpmif_change_state(tpmif, XenbusStateInitWait)) {
+      goto error;
+   }
+
+   snprintf(path, 512, "backend/vtpm/%u/%u/frontend", (unsigned int)
domid, handle);
+   if((err =3D xenbus_read(XBT_NIL, path, &tpmif->fe_path))) {
+      TPMBACK_ERR("Error creating new tpm instance xenbus_read(%s),
Error =3D %s", path, err);
+      free(err);
+      goto error;
+   }
+
+   /*Set the state path */
+   tpmif->fe_state_path =3D malloc(strlen(tpmif->fe_path) + 7);
+   strcpy(tpmif->fe_state_path, tpmif->fe_path);
+   strcat(tpmif->fe_state_path, "/state");
+
+   if(insert_tpmif(tpmif)) {
+      goto error;
+   }
+   TPMBACK_DEBUG("New tpmif %u/%u\n", (unsigned int) tpmif->domid,
tpmif->handle);
+   /* Do the callback now */
+   if(gtpmdev.open_callback) {
+      gtpmdev.open_callback(tpmif->domid, tpmif->handle);
+   }
+   return tpmif;
+error:
+   __free_tpmif(tpmif);
+   return NULL;
+
+}
+
+/* Removes tpmif from dev->tpmlist and frees it's memory usage */
+void free_tpmif(tpmif_t* tpmif)
+{
+   char* err;
+   char path[512];
+   TPMBACK_DEBUG("Free tpmif %u/%u\n", (unsigned int) tpmif->domid,
tpmif->handle);
+   if(tpmif->flags & TPMIF_CLOSED) {
+      TPMBACK_ERR("Tried to free an instance twice! Theres a bug
somewhere!\n");
+      BUG();
+   }
+   tpmif->flags =3D TPMIF_CLOSED;
+
+   tpmif_change_state(tpmif, XenbusStateClosing);
+
+   /* Unmap share page and unbind event channel */
+   if(tpmif->status =3D=3D CONNECTED) {
+      tpmif->status =3D DISCONNECTING;
+      mask_evtchn(tpmif->evtchn);
+
+      if(gntmap_munmap(&gtpmdev.map, (unsigned long)tpmif->tx, 1)) {
+     TPMBACK_ERR("%u/%u Error occured while trying to unmap shared
page\n", (unsigned int) tpmif->domid, tpmif->handle);
+      }
+
+      unbind_evtchn(tpmif->evtchn);
+   }
+   tpmif->status =3D DISCONNECTED;
+   tpmif_change_state(tpmif, XenbusStateClosed);
+
+   /* Do the callback now */
+   if(gtpmdev.close_callback) {
+      gtpmdev.close_callback(tpmif->domid, tpmif->handle);
+   }
+
+   /* remove from array */
+   remove_tpmif(tpmif);
+
+   /* Wake up anyone possibly waiting on this interface and let them
exit */
+   wake_up(&waitq);
+   schedule();
+
+   /* Remove the old xenbus entries */
+   snprintf(path, 512, "backend/vtpm/%u/%u", (unsigned int)
tpmif->domid, tpmif->handle);
+   if((err =3D xenbus_rm(XBT_NIL, path))) {
+      TPMBACK_ERR("Error cleaning up xenbus entries path=3D%s
error=3D%s\n", path, err);
+      free(err);
+   }
+
+   TPMBACK_LOG("Frontend %u/%u disconnected\n", (unsigned int)
tpmif->domid, tpmif->handle);
+
+   /* free memory */
+   __free_tpmif(tpmif);
+
+}
+
+/**********************
+ * REMAINING TPMBACK FUNCTIONS
+ * ********************/
+
+/*Event channel handler */
+void tpmback_handler(evtchn_port_t port, struct pt_regs *regs, void *dat=
a)
+{
+   tpmif_t* tpmif =3D (tpmif_t*) data;
+   tpmif_tx_request_t* tx =3D &tpmif->tx->ring[0].req;
+   /* Throw away 0 size events, these can trigger from event channel
unmasking */
+   if(tx->size =3D=3D 0)
+      return;
+
+   TPMBACK_DEBUG("EVENT CHANNEL FIRE %u/%u\n", (unsigned int)
tpmif->domid, tpmif->handle);
+   tpmif_req_ready(tpmif);
+   wake_up(&waitq);
+
+}
+
+/* Connect to frontend */
+int connect_fe(tpmif_t* tpmif)
+{
+   char path[512];
+   char* err, *value;
+   uint32_t domid;
+   grant_ref_t ringref;
+   evtchn_port_t evtchn;
+
+   /* If already connected then quit */
+   if (tpmif->status =3D=3D CONNECTED) {
+      TPMBACK_DEBUG("%u/%u tried to connect while it was already
connected?\n", (unsigned int) tpmif->domid, tpmif->handle);
+      return 0;
+   }
+
+   /* Fetch the grant reference */
+   snprintf(path, 512, "%s/ring-ref", tpmif->fe_path);
+   if((err =3D xenbus_read(XBT_NIL, path, &value))) {
+      TPMBACK_ERR("Error creating new tpm instance xenbus_read(%s)
Error =3D %s", path, err);
+      free(err);
+      return -1;
+   }
+   if(sscanf(value, "%d", &ringref) !=3D 1) {
+      TPMBACK_ERR("Non integer value (%s) in %s ??\n", value, path);
+      free(value);
+      return -1;
+   }
+   free(value);
+
+
+   /* Fetch the event channel*/
+   snprintf(path, 512, "%s/event-channel", tpmif->fe_path);
+   if((err =3D xenbus_read(XBT_NIL, path, &value))) {
+      TPMBACK_ERR("Error creating new tpm instance xenbus_read(%s)
Error =3D %s", path, err);
+      free(err);
+      return -1;
+   }
+   if(sscanf(value, "%d", &evtchn) !=3D 1) {
+      TPMBACK_ERR("Non integer value (%s) in %s ??\n", value, path);
+      free(value);
+      return -1;
+   }
+   free(value);
+
+   domid =3D tpmif->domid;
+   if((tpmif->tx =3D gntmap_map_grant_refs(&gtpmdev.map, 1, &domid, 0,
&ringref, PROT_READ | PROT_WRITE)) =3D=3D NULL) {
+      TPMBACK_ERR("Failed to map grant reference %u/%u\n", (unsigned
int) tpmif->domid, tpmif->handle);
+      return -1;
+   }
+   memset(tpmif->tx, 0, PAGE_SIZE);
+
+   /*Bind the event channel */
+   if((evtchn_bind_interdomain(tpmif->domid, evtchn, tpmback_handler,
tpmif, &tpmif->evtchn)))
+   {
+      TPMBACK_ERR("%u/%u Unable to bind to interdomain event
channel!\n", (unsigned int) tpmif->domid, tpmif->handle);
+      goto error_post_map;
+   }
+   unmask_evtchn(tpmif->evtchn);
+
+   /* Write the ready flag and change status to connected */
+   snprintf(path, 512, "backend/vtpm/%u/%u", (unsigned int)
tpmif->domid, tpmif->handle);
+   if((err =3D xenbus_printf(XBT_NIL, path, "ready", "%u", 1))) {
+      TPMBACK_ERR("%u/%u Unable to write ready flag on connect_fe()\n",
(unsigned int) tpmif->domid, tpmif->handle);
+      free(err);
+      goto error_post_evtchn;
+   }
+   tpmif->status =3D CONNECTED;
+   if((tpmif_change_state(tpmif, XenbusStateConnected))){
+      goto error_post_evtchn;
+   }
+
+   TPMBACK_LOG("Frontend %u/%u connected\n", (unsigned int)
tpmif->domid, tpmif->handle);
+
+   return 0;
+error_post_evtchn:
+   mask_evtchn(tpmif->evtchn);
+   unbind_evtchn(tpmif->evtchn);
+error_post_map:
+   gntmap_munmap(&gtpmdev.map, (unsigned long)tpmif->tx, 1);
+   return -1;
+}
+
+static int frontend_changed(tpmif_t* tpmif)
+{
+   int state =3D xenbus_read_integer(tpmif->fe_state_path);
+   if(state < 0) {
+      state =3D XenbusStateUnknown;
+   }
+
+   TPMBACK_DEBUG("Frontend %u/%u state changed to %d\n", (unsigned int)
tpmif->domid, tpmif->handle, state);
+
+   switch (state) {
+      case XenbusStateInitialising:
+      case XenbusStateInitialised:
+     break;
+
+      case XenbusStateConnected:
+     if(connect_fe(tpmif)) {
+        TPMBACK_ERR("Failed to connect to front end %u/%u\n", (unsigned
int) tpmif->domid, tpmif->handle);
+        tpmif_change_state(tpmif, XenbusStateClosed);
+        return -1;
+     }
+     break;
+
+      case XenbusStateClosing:
+     tpmif_change_state(tpmif, XenbusStateClosing);
+     break;
+
+      case XenbusStateUnknown: /* keep it here */
+      case XenbusStateClosed:
+     free_tpmif(tpmif);
+     break;
+
+      default:
+     TPMBACK_DEBUG("BAD STATE CHANGE %u/%u state =3D %d for tpmif\n",
(unsigned int) tpmif->domid, tpmif->handle, state);
+     return -1;
+   }
+   return 0;
+}
+
+
+/* parses the string that comes out of xenbus_watch_wait_return. */
+static int parse_eventstr(const char* evstr, domid_t* domid, unsigned
int* handle)
+{
+   int ret;
+   char cmd[40];
+   char* err;
+   char* value;
+   unsigned int udomid =3D 0;
+   tpmif_t* tpmif;
+   /* First check for new frontends, this occurs when
/backend/vtpm/<domid>/<handle> gets created. Note we what the sscanf to
fail on the last %s */
+   if (sscanf(evstr, "backend/vtpm/%u/%u/%40s", &udomid, handle, cmd)
=3D=3D 2) {
+      *domid =3D udomid;
+      /* Make sure the entry exists, if this event triggers because the
entry dissapeared then ignore it */
+      if((err =3D xenbus_read(XBT_NIL, evstr, &value))) {
+     free(err);
+     return EV_NONE;
+      }
+      free(value);
+      /* Make sure the tpmif entry does not already exist, this should
not happen */
+      if((tpmif =3D get_tpmif(*domid, *handle)) !=3D NULL) {
+     TPMBACK_DEBUG("Duplicate tpm entries! %u %u\n", tpmif->domid,
tpmif->handle);
+     return EV_NONE;
+      }
+      return EV_NEWFE;
+   } else if((ret =3D sscanf(evstr,
"/local/domain/%u/device/vtpm/%u/%40s", &udomid, handle, cmd)) =3D=3D 3) =
{
+      *domid =3D udomid;
+      if (!strcmp(cmd, "state"))
+     return EV_STCHNG;
+   }
+   return EV_NONE;
+}
+
+void handle_backend_event(char* evstr) {
+   tpmif_t* tpmif;
+   domid_t domid;
+   unsigned int handle;
+   int event;
+
+   TPMBACK_DEBUG("Xenbus Event: %s\n", evstr);
+
+   event =3D parse_eventstr(evstr, &domid, &handle);
+
+   switch(event) {
+      case EV_NEWFE:
+     if(new_tpmif(domid, handle) =3D=3D NULL) {
+        TPMBACK_ERR("Failed to create new tpm instance %u/%u\n",
(unsigned int) domid, handle);
+     }
+     wake_up(&waitq);
+     break;
+      case EV_STCHNG:
+     if((tpmif =3D get_tpmif(domid, handle))) {
+        frontend_changed(tpmif);
+     } else {
+        TPMBACK_DEBUG("Event Received for non-existant tpm!
instance=3D%u/%u xenbus_event=3D%s\n", (unsigned int) domid, handle, evst=
r);
+     }
+     break;
+   }
+}
+
+/* Runs through the given path and creates events recursively
+ * for all of its children.
+ * @path - xenstore path to scan */
+static void generate_backend_events(const char* path)
+{
+   char* err;
+   int i, len;
+   char **dirs;
+   char *entry;
+
+   if((err =3D xenbus_ls(XBT_NIL, path, &dirs)) !=3D NULL) {
+      free(err);
+      return;
+   }
+
+   for(i =3D 0; dirs[i] !=3D NULL; ++i) {
+      len =3D strlen(path) + strlen(dirs[i]) + 2;
+      entry =3D malloc(len);
+      snprintf(entry, len, "%s/%s", path, dirs[i]);
+
+      /* Generate and handle event for the entry itself */
+      handle_backend_event(entry);
+
+      /* Do children */
+      generate_backend_events(entry);
+
+      /* Cleanup */
+      free(entry);
+      free(dirs[i]);
+   }
+   free(dirs);
+   return;
+}
+
+char* tpmback_get_uuid(domid_t domid, unsigned int handle)
+{
+   tpmif_t* tpmif;
+   if((tpmif =3D get_tpmif(domid, handle)) =3D=3D NULL) {
+      TPMBACK_DEBUG("get_uuid() failed, %u/%u is an invalid
frontend\n", (unsigned int) domid, handle);
+      return NULL;
+   }
+
+   return tpmif->uuid;
+}
+
+void tpmback_set_open_callback(void (*cb)(domid_t, unsigned int))
+{
+   gtpmdev.open_callback =3D cb;
+}
+void tpmback_set_close_callback(void (*cb)(domid_t, unsigned int))
+{
+   gtpmdev.close_callback =3D cb;
+}
+void tpmback_set_suspend_callback(void (*cb)(domid_t, unsigned int))
+{
+   gtpmdev.suspend_callback =3D cb;
+}
+void tpmback_set_resume_callback(void (*cb)(domid_t, unsigned int))
+{
+   gtpmdev.resume_callback =3D cb;
+}
+
+static void event_listener(void)
+{
+   const char* bepath =3D "backend/vtpm";
+   char **path;
+   char* err;
+
+   /* Setup the backend device watch */
+   if((err =3D xenbus_watch_path_token(XBT_NIL, bepath, bepath,
&gtpmdev.events)) !=3D NULL) {
+      TPMBACK_ERR("xenbus_watch_path_token(%s) failed with error
%s!\n", bepath, err);
+      free(err);
+      goto egress;
+   }
+
+   /* Check for any frontends that connected before we set the watch.
+    * This is almost guaranteed to happen if both domains are started
+    * immediatly one after the other.
+    * We do this by manually generating events on everything in the back=
end
+    * path */
+   generate_backend_events(bepath);
+
+   /* Wait and listen for changes in frontend connections */
+   while(1) {
+      path =3D xenbus_wait_for_watch_return(&gtpmdev.events);
+
+      /*If quit flag was set then exit */
+      if(gtpmdev.flags & TPMIF_CLOSED) {
+     TPMBACK_DEBUG("listener thread got quit event. Exiting..\n");
+     free(path);
+     break;
+      }
+      handle_backend_event(*path);
+      free(path);
+
+   }
+
+   if((err =3D xenbus_unwatch_path_token(XBT_NIL, bepath, bepath)) !=3D =
NULL) {
+      free(err);
+   }
+egress:
+   return;
+}
+
+void event_thread(void* p) {
+   event_listener();
+}
+
+void init_tpmback(char** exclusive_uuids)
+{
+   if(!globalinit) {
+      init_waitqueue_head(&waitq);
+      globalinit =3D 1;
+   }
+   printk("=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Init TPM BACK =3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D\n");
+   gtpmdev.tpmlist =3D malloc(sizeof(tpmif_t*) * DEF_ARRAY_SIZE);
+   gtpmdev.num_alloc =3D DEF_ARRAY_SIZE;
+   gtpmdev.num_tpms =3D 0;
+   gtpmdev.flags =3D 0;
+   gtpmdev.exclusive_uuids =3D exclusive_uuids;
+
+   gtpmdev.open_callback =3D gtpmdev.close_callback =3D NULL;
+   gtpmdev.suspend_callback =3D gtpmdev.resume_callback =3D NULL;
+
+   eventthread =3D create_thread("tpmback-listener", event_thread, NULL)=
;
+
+}
+
+void shutdown_tpmback(void)
+{
+   /* Disable callbacks */
+   gtpmdev.open_callback =3D gtpmdev.close_callback =3D NULL;
+   gtpmdev.suspend_callback =3D gtpmdev.resume_callback =3D NULL;
+
+   TPMBACK_LOG("Shutting down tpm backend\n");
+   /* Set the quit flag */
+   gtpmdev.flags =3D TPMIF_CLOSED;
+
+   //printk("num tpms is %d\n", gtpmdev.num_tpms);
+   /*Free all backend instances */
+   while(gtpmdev.num_tpms) {
+      free_tpmif(gtpmdev.tpmlist[0]);
+   }
+   free(gtpmdev.tpmlist);
+   gtpmdev.tpmlist =3D NULL;
+   gtpmdev.num_alloc =3D 0;
+
+   /* Wake up anyone possibly waiting on the device and let them exit */=

+   wake_up(&waitq);
+   schedule();
+}
+
+inline void init_tpmcmd(tpmcmd_t* tpmcmd, domid_t domid, unsigned int
handle, char* uuid)
+{
+   tpmcmd->domid =3D domid;
+   tpmcmd->handle =3D handle;
+   tpmcmd->uuid =3D uuid;
+   tpmcmd->req =3D NULL;
+   tpmcmd->req_len =3D 0;
+   tpmcmd->resp =3D NULL;
+   tpmcmd->resp_len =3D 0;
+}
+
+tpmcmd_t* get_request(tpmif_t* tpmif) {
+   tpmcmd_t* cmd;
+   tpmif_tx_request_t* tx;
+   int offset;
+   int tocopy;
+   int i;
+   uint32_t domid;
+   int flags;
+
+   local_irq_save(flags);
+
+   /* Allocate the cmd object to hold the data */
+   if((cmd =3D malloc(sizeof(*cmd))) =3D=3D NULL) {
+      goto error;
+   }
+   init_tpmcmd(cmd, tpmif->domid, tpmif->handle, tpmif->uuid);
+
+   tx =3D &tpmif->tx->ring[0].req;
+   cmd->req_len =3D tx->size;
+   /* Allocate the buffer */
+   if(cmd->req_len) {
+      if((cmd->req =3D malloc(cmd->req_len)) =3D=3D NULL) {
+     goto error;
+      }
+   }
+   /* Copy the bits from the shared pages */
+   offset =3D 0;
+   for(i =3D 0; i < TPMIF_TX_RING_SIZE && offset < cmd->req_len; ++i) {
+      tx =3D &tpmif->tx->ring[i].req;
+
+      /* Map the page with the data */
+      domid =3D (uint32_t)tpmif->domid;
+      if((tpmif->pages[i] =3D gntmap_map_grant_refs(&gtpmdev.map, 1,
&domid, 0, &tx->ref, PROT_READ)) =3D=3D NULL) {
+     TPMBACK_ERR("%u/%u Unable to map shared page during read!\n",
(unsigned int) tpmif->domid, tpmif->handle);
+     goto error;
+      }
+
+      /* do the copy now */
+      tocopy =3D min(cmd->req_len - offset, PAGE_SIZE);
+      memcpy(&cmd->req[offset], tpmif->pages[i], tocopy);
+      offset +=3D tocopy;
+
+      /* release the page */
+      gntmap_munmap(&gtpmdev.map, (unsigned long)tpmif->pages[i], 1);
+
+   }
+
+#ifdef TPMBACK_PRINT_DEBUG
+   TPMBACK_DEBUG("Received Tpm Command from %u/%u of size %u",
(unsigned int) tpmif->domid, tpmif->handle, cmd->req_len);
+   for(i =3D 0; i < cmd->req_len; ++i) {
+      if (!(i % 30)) {
+     TPMBACK_DEBUG_MORE("\n");
+      }
+      TPMBACK_DEBUG_MORE("%02hhX ", cmd->req[i]);
+   }
+   TPMBACK_DEBUG_MORE("\n\n");
+#endif
+
+   local_irq_restore(flags);
+   return cmd;
+error:
+   if(cmd !=3D NULL) {
+      if (cmd->req !=3D NULL) {
+     free(cmd->req);
+     cmd->req =3D NULL;
+      }
+      free(cmd);
+      cmd =3D NULL;
+   }
+   local_irq_restore(flags);
+   return NULL;
+
+}
+
+void send_response(tpmcmd_t* cmd, tpmif_t* tpmif)
+{
+   tpmif_tx_request_t* tx;
+   int offset;
+   int i;
+   uint32_t domid;
+   int tocopy;
+   int flags;
+
+   local_irq_save(flags);
+
+   tx =3D &tpmif->tx->ring[0].req;
+   tx->size =3D cmd->resp_len;
+
+   offset =3D 0;
+   for(i =3D 0; i < TPMIF_TX_RING_SIZE && offset < cmd->resp_len; ++i) {=

+      tx =3D &tpmif->tx->ring[i].req;
+
+      /* Map the page with the data */
+      domid =3D (uint32_t)tpmif->domid;
+      if((tpmif->pages[i] =3D gntmap_map_grant_refs(&gtpmdev.map, 1,
&domid, 0, &tx->ref, PROT_WRITE)) =3D=3D NULL) {
+     TPMBACK_ERR("%u/%u Unable to map shared page during write!\n",
(unsigned int) tpmif->domid, tpmif->handle);
+     goto error;
+      }
+
+      /* do the copy now */
+      tocopy =3D min(cmd->resp_len - offset, PAGE_SIZE);
+      memcpy(tpmif->pages[i], &cmd->resp[offset], tocopy);
+      offset +=3D tocopy;
+
+      /* release the page */
+      gntmap_munmap(&gtpmdev.map, (unsigned long)tpmif->pages[i], 1);
+
+   }
+
+#ifdef TPMBACK_PRINT_DEBUG
+   TPMBACK_DEBUG("Sent response to %u/%u of size %u", (unsigned int)
tpmif->domid, tpmif->handle, cmd->resp_len);
+   for(i =3D 0; i < cmd->resp_len; ++i) {
+      if (!(i % 30)) {
+     TPMBACK_DEBUG_MORE("\n");
+      }
+      TPMBACK_DEBUG_MORE("%02hhX ", cmd->resp[i]);
+   }
+   TPMBACK_DEBUG_MORE("\n\n");
+#endif
+   /* clear the ready flag and send the event channel notice to the
frontend */
+   tpmif_req_finished(tpmif);
+   notify_remote_via_evtchn(tpmif->evtchn);
+error:
+   local_irq_restore(flags);
+   return;
+}
+
+tpmcmd_t* tpmback_req_any(void)
+{
+   int i;
+   /* Block until something has a request */
+   wait_event(waitq, (gtpmdev.flags & (TPMIF_REQ_READY | TPMIF_CLOSED)))=
;
+
+   /* Check if were shutting down */
+   if(gtpmdev.flags & TPMIF_CLOSED) {
+      /* if something was waiting for us to give up the queue so it can
shutdown, let it finish */
+      schedule();
+      return NULL;
+   }
+
+   for(i =3D 0; i < gtpmdev.num_tpms; ++i) {
+      if(gtpmdev.tpmlist[i]->flags & TPMIF_REQ_READY) {
+     return get_request(gtpmdev.tpmlist[i]);
+      }
+   }
+
+   TPMBACK_ERR("backend request ready flag was set but no interfaces
were actually ready\n");
+   return NULL;
+}
+
+tpmcmd_t* tpmback_req(domid_t domid, unsigned int handle)
+{
+   tpmif_t* tpmif;
+   tpmif =3D get_tpmif(domid, handle);
+   if(tpmif =3D=3D NULL) {
+      return NULL;
+   }
+
+   wait_event(waitq, (tpmif->flags & (TPMIF_REQ_READY | TPMIF_CLOSED)
|| gtpmdev.flags & TPMIF_CLOSED));
+
+   /* Check if were shutting down */
+   if(tpmif->flags & TPMIF_CLOSED || gtpmdev.flags & TPMIF_CLOSED) {
+      /* if something was waiting for us to give up the queue so it can
free this instance, let it finish */
+      schedule();
+      return NULL;
+   }
+
+   return get_request(tpmif);
+}
+
+void tpmback_resp(tpmcmd_t* tpmcmd)
+{
+   tpmif_t* tpmif;
+
+   /* Get the associated interface, if it doesnt exist then just quit */=

+   tpmif =3D get_tpmif(tpmcmd->domid, tpmcmd->handle);
+   if(tpmif =3D=3D NULL) {
+      TPMBACK_ERR("Tried to send a reponse to non existant frontend
%u/%u\n", (unsigned int) tpmcmd->domid, tpmcmd->handle);
+      goto end;
+   }
+
+   if(!(tpmif->flags & TPMIF_REQ_READY)) {
+      TPMBACK_ERR("Tried to send response to a frontend that was not
waiting for one %u/%u\n", (unsigned int) tpmcmd->domid, tpmcmd->handle);
+      goto end;
+   }
+
+   /* Send response to frontend */
+   send_response(tpmcmd, tpmif);
+
+end:
+   if(tpmcmd->req !=3D NULL) {
+      free(tpmcmd->req);
+   }
+   free(tpmcmd);
+   return;
+}
+
+int tpmback_wait_for_frontend_connect(domid_t *domid, unsigned int *hand=
le)
+{
+   tpmif_t* tpmif;
+   int flags;
+   wait_event(waitq, ((gtpmdev.num_tpms > 0) || gtpmdev.flags &
TPMIF_CLOSED));
+   if(gtpmdev.flags & TPMIF_CLOSED) {
+      return -1;
+   }
+   local_irq_save(flags);
+   tpmif =3D gtpmdev.tpmlist[0];
+   *domid =3D tpmif->domid;
+   *handle =3D tpmif->handle;
+   local_irq_restore(flags);
+
+   return 0;
+}
+
+int tpmback_num_frontends(void)
+{
+   return gtpmdev.num_tpms;
+}
diff --git a/extras/mini-os/tpmfront.c b/extras/mini-os/tpmfront.c
--- /dev/null
+++ b/extras/mini-os/tpmfront.c
@@ -0,0 +1,606 @@
+/*
+ * Copyright (c) 2010-2012 United States Government, as represented by
+ * the Secretary of Defense.  All rights reserved.
+ *
+ * This driver 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 3 of the License, or
+ * (at your option) any later version.
+ *
+ * This driver is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program.  If not, see <http://www.gnu.org/licenses/>.=

+ *
+ * Based upon the files:
+ *  drivers/char/tpm/tpm_vtpm.c
+ *  drivers/char/tpm/tpm_xen.c
+ * from the Linux kernel, which are Copyright (C) 2006 IBM Corporation
+ */
+#include <mini-os/os.h>
+#include <mini-os/xenbus.h>
+#include <mini-os/xmalloc.h>
+#include <mini-os/events.h>
+#include <mini-os/wait.h>
+#include <mini-os/gnttab.h>
+#include <xen/io/xenbus.h>
+#include <xen/io/tpmif.h>
+#include <mini-os/tpmfront.h>
+#include <fcntl.h>
+
+//#define TPMFRONT_PRINT_DEBUG
+#ifdef TPMFRONT_PRINT_DEBUG
+#define TPMFRONT_DEBUG(fmt,...) printk("Tpmfront:Debug("__FILE__":%d) "
fmt, __LINE__, ##__VA_ARGS__)
+#define TPMFRONT_DEBUG_MORE(fmt,...) printk(fmt, ##__VA_ARGS__)
+#else
+#define TPMFRONT_DEBUG(fmt,...)
+#endif
+#define TPMFRONT_ERR(fmt,...) printk("Tpmfront:Error " fmt, ##__VA_ARGS_=
_)
+#define TPMFRONT_LOG(fmt,...) printk("Tpmfront:Info " fmt, ##__VA_ARGS__=
)
+
+#define min(a,b) (((a) < (b)) ? (a) : (b))
+
+void tpmfront_handler(evtchn_port_t port, struct pt_regs *regs, void
*data) {
+   struct tpmfront_dev* dev =3D (struct tpmfront_dev*) data;
+   /*If we get a response when we didnt make a request, just ignore it *=
/
+   if(!dev->waiting) {
+      return;
+   }
+
+   dev->waiting =3D 0;
+#ifdef HAVE_LIBC
+   if(dev->fd >=3D 0) {
+      files[dev->fd].read =3D 1;
+   }
+#endif
+   wake_up(&dev->waitq);
+}
+
+static int publish_xenbus(struct tpmfront_dev* dev) {
+   xenbus_transaction_t xbt;
+   int retry;
+   char* err;
+   /* Write the grant reference and event channel to xenstore */
+again:
+   if((err =3D xenbus_transaction_start(&xbt))) {
+      TPMFRONT_ERR("Unable to start xenbus transaction, error was
%s\n", err);
+      free(err);
+      return -1;
+   }
+
+   if((err =3D xenbus_printf(xbt, dev->nodename, "ring-ref", "%u",
(unsigned int) dev->ring_ref))) {
+      TPMFRONT_ERR("Unable to write %s/ring-ref, error was %s\n",
dev->nodename, err);
+      free(err);
+      goto abort_transaction;
+   }
+
+   if((err =3D xenbus_printf(xbt, dev->nodename, "event-channel", "%u",
(unsigned int) dev->evtchn))) {
+      TPMFRONT_ERR("Unable to write %s/event-channel, error was %s\n",
dev->nodename, err);
+      free(err);
+      goto abort_transaction;
+   }
+
+   if((err =3D xenbus_transaction_end(xbt, 0, &retry))) {
+      TPMFRONT_ERR("Unable to complete xenbus transaction, error was
%s\n", err);
+      free(err);
+      return -1;
+   }
+   if(retry) {
+      goto again;
+   }
+
+   return 0;
+abort_transaction:
+   if((err =3D xenbus_transaction_end(xbt, 1, &retry))) {
+      free(err);
+   }
+   return -1;
+}
+
+static int wait_for_backend_connect(xenbus_event_queue* events, char* pa=
th)
+{
+   int state;
+
+   TPMFRONT_LOG("Waiting for backend connection..\n");
+   /* Wait for the backend to connect */
+   while(1) {
+      state =3D xenbus_read_integer(path);
+      if ( state < 0)
+     state =3D XenbusStateUnknown;
+      switch(state) {
+     /* Bad states, we quit with error */
+     case XenbusStateUnknown:
+     case XenbusStateClosing:
+     case XenbusStateClosed:
+        TPMFRONT_ERR("Unable to connect to backend\n");
+        return -1;
+     /* If backend is connected then break out of loop */
+     case XenbusStateConnected:
+        TPMFRONT_LOG("Backend Connected\n");
+        return 0;
+     default:
+        xenbus_wait_for_watch(events);
+      }
+   }
+
+}
+
+static int wait_for_backend_closed(xenbus_event_queue* events, char* pat=
h)
+{
+   int state;
+
+   TPMFRONT_LOG("Waiting for backend to close..\n");
+   while(1) {
+      state =3D xenbus_read_integer(path);
+      if ( state < 0)
+     state =3D XenbusStateUnknown;
+      switch(state) {
+     case XenbusStateUnknown:
+        TPMFRONT_ERR("Backend Unknown state, forcing shutdown\n");
+        return -1;
+     case XenbusStateClosed:
+        TPMFRONT_LOG("Backend Closed\n");
+        return 0;
+     default:
+        xenbus_wait_for_watch(events);
+      }
+   }
+
+}
+
+static int wait_for_backend_state_changed(struct tpmfront_dev* dev,
XenbusState state) {
+   char* err;
+   int ret =3D 0;
+   xenbus_event_queue events =3D NULL;
+   char path[512];
+
+   snprintf(path, 512, "%s/state", dev->bepath);
+   /*Setup the watch to wait for the backend */
+   if((err =3D xenbus_watch_path_token(XBT_NIL, path, path, &events))) {=

+      TPMFRONT_ERR("Could not set a watch on %s, error was %s\n", path,
err);
+      free(err);
+      return -1;
+   }
+
+   /* Do the actual wait loop now */
+   switch(state) {
+      case XenbusStateConnected:
+     ret =3D wait_for_backend_connect(&events, path);
+     break;
+      case XenbusStateClosed:
+     ret =3D wait_for_backend_closed(&events, path);
+     break;
+      default:
+     break;
+   }
+
+   if((err =3D xenbus_unwatch_path_token(XBT_NIL, path, path))) {
+      TPMFRONT_ERR("Unable to unwatch %s, error was %s, ignoring..\n",
path, err);
+      free(err);
+   }
+   return ret;
+}
+
+static int tpmfront_connect(struct tpmfront_dev* dev)
+{
+   char* err;
+   /* Create shared page */
+   dev->tx =3D (tpmif_tx_interface_t*) alloc_page();
+   if(dev->tx =3D=3D NULL) {
+      TPMFRONT_ERR("Unable to allocate page for shared memory\n");
+      goto error;
+   }
+   memset(dev->tx, 0, PAGE_SIZE);
+   dev->ring_ref =3D gnttab_grant_access(dev->bedomid,
virt_to_mfn(dev->tx), 0);
+   TPMFRONT_DEBUG("grant ref is %lu\n", (unsigned long) dev->ring_ref);
+
+   /*Create event channel */
+   if(evtchn_alloc_unbound(dev->bedomid, tpmfront_handler, dev,
&dev->evtchn)) {
+      TPMFRONT_ERR("Unable to allocate event channel\n");
+      goto error_postmap;
+   }
+   unmask_evtchn(dev->evtchn);
+   TPMFRONT_DEBUG("event channel is %lu\n", (unsigned long) dev->evtchn)=
;
+
+   /* Write the entries to xenstore */
+   if(publish_xenbus(dev)) {
+      goto error_postevtchn;
+   }
+
+   /* Change state to connected */
+   dev->state =3D XenbusStateConnected;
+
+   /* Tell the backend that we are ready */
+   if((err =3D xenbus_printf(XBT_NIL, dev->nodename, "state", "%u",
dev->state))) {
+      TPMFRONT_ERR("Unable to write to xenstore %s/state, value=3D%u",
dev->nodename, XenbusStateConnected);
+      free(err);
+      goto error;
+   }
+
+   return 0;
+error_postevtchn:
+      mask_evtchn(dev->evtchn);
+      unbind_evtchn(dev->evtchn);
+error_postmap:
+      gnttab_end_access(dev->ring_ref);
+      free_page(dev->tx);
+error:
+   return -1;
+}
+
+struct tpmfront_dev* init_tpmfront(const char* _nodename)
+{
+   struct tpmfront_dev* dev;
+   const char* nodename;
+   char path[512];
+   char* value, *err;
+   unsigned long long ival;
+   int i;
+
+   printk("=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Init TPM Front =3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D\n");
+
+   dev =3D malloc(sizeof(struct tpmfront_dev));
+   memset(dev, 0, sizeof(struct tpmfront_dev));
+
+#ifdef HAVE_LIBC
+   dev->fd =3D -1;
+#endif
+
+   nodename =3D _nodename ? _nodename : "device/vtpm/0";
+   dev->nodename =3D strdup(nodename);
+
+   init_waitqueue_head(&dev->waitq);
+
+   /* Get backend domid */
+   snprintf(path, 512, "%s/backend-id", dev->nodename);
+   if((err =3D xenbus_read(XBT_NIL, path, &value))) {
+      TPMFRONT_ERR("Unable to read %s during tpmfront initialization!
error =3D %s\n", path, err);
+      free(err);
+      goto error;
+   }
+   if(sscanf(value, "%llu", &ival) !=3D 1) {
+      TPMFRONT_ERR("%s has non-integer value (%s)\n", path, value);
+      free(value);
+      goto error;
+   }
+   free(value);
+   dev->bedomid =3D ival;
+
+   /* Get backend xenstore path */
+   snprintf(path, 512, "%s/backend", dev->nodename);
+   if((err =3D xenbus_read(XBT_NIL, path, &dev->bepath))) {
+      TPMFRONT_ERR("Unable to read %s during tpmfront initialization!
error =3D %s\n", path, err);
+      free(err);
+      goto error;
+   }
+
+   /* Create and publish grant reference and event channel */
+   if (tpmfront_connect(dev)) {
+      goto error;
+   }
+
+   /* Wait for backend to connect */
+   if( wait_for_backend_state_changed(dev, XenbusStateConnected)) {
+      goto error;
+   }
+
+   /* Allocate pages that will contain the messages */
+   dev->pages =3D malloc(sizeof(void*) * TPMIF_TX_RING_SIZE);
+   if(dev->pages =3D=3D NULL) {
+      goto error;
+   }
+   memset(dev->pages, 0, sizeof(void*) * TPMIF_TX_RING_SIZE);
+   for(i =3D 0; i < TPMIF_TX_RING_SIZE; ++i) {
+      dev->pages[i] =3D (void*)alloc_page();
+      if(dev->pages[i] =3D=3D NULL) {
+     goto error;
+      }
+   }
+
+   TPMFRONT_LOG("Initialization Completed successfully\n");
+
+   return dev;
+
+error:
+   shutdown_tpmfront(dev);
+   return NULL;
+}
+void shutdown_tpmfront(struct tpmfront_dev* dev)
+{
+   char* err;
+   char path[512];
+   int i;
+   tpmif_tx_request_t* tx;
+   if(dev =3D=3D NULL) {
+      return;
+   }
+   TPMFRONT_LOG("Shutting down tpmfront\n");
+   /* disconnect */
+   if(dev->state =3D=3D XenbusStateConnected) {
+      dev->state =3D XenbusStateClosing;
+      //FIXME: Transaction for this?
+      /* Tell backend we are closing */
+      if((err =3D xenbus_printf(XBT_NIL, dev->nodename, "state", "%u",
(unsigned int) dev->state))) {
+     free(err);
+      }
+
+      /* Clean up xenstore entries */
+      snprintf(path, 512, "%s/event-channel", dev->nodename);
+      if((err =3D xenbus_rm(XBT_NIL, path))) {
+     free(err);
+      }
+      snprintf(path, 512, "%s/ring-ref", dev->nodename);
+      if((err =3D xenbus_rm(XBT_NIL, path))) {
+     free(err);
+      }
+
+      /* Tell backend we are closed */
+      dev->state =3D XenbusStateClosed;
+      if((err =3D xenbus_printf(XBT_NIL, dev->nodename, "state", "%u",
(unsigned int) dev->state))) {
+     TPMFRONT_ERR("Unable to write to %s, error was %s", dev->nodename,
err);
+     free(err);
+      }
+
+      /* Wait for the backend to close and unmap shared pages, ignore
any errors */
+      wait_for_backend_state_changed(dev, XenbusStateClosed);
+
+      /* Cleanup any shared pages */
+      if(dev->pages) {
+     for(i =3D 0; i < TPMIF_TX_RING_SIZE; ++i) {
+        if(dev->pages[i]) {
+           tx =3D &dev->tx->ring[i].req;
+           if(tx->ref !=3D 0) {
+          gnttab_end_access(tx->ref);
+           }
+           free_page(dev->pages[i]);
+        }
+     }
+     free(dev->pages);
+      }
+
+      /* Close event channel and unmap shared page */
+      mask_evtchn(dev->evtchn);
+      unbind_evtchn(dev->evtchn);
+      gnttab_end_access(dev->ring_ref);
+
+      free_page(dev->tx);
+
+   }
+
+   /* Cleanup memory usage */
+   if(dev->respbuf) {
+      free(dev->respbuf);
+   }
+   if(dev->bepath) {
+      free(dev->bepath);
+   }
+   if(dev->nodename) {
+      free(dev->nodename);
+   }
+   free(dev);
+}
+
+int tpmfront_send(struct tpmfront_dev* dev, const uint8_t* msg, size_t
length)
+{
+   int i;
+   tpmif_tx_request_t* tx =3D NULL;
+   /* Error Checking */
+   if(dev =3D=3D NULL || dev->state !=3D XenbusStateConnected) {
+      TPMFRONT_ERR("Tried to send message through disconnected
frontend\n");
+      return -1;
+   }
+
+#ifdef TPMFRONT_PRINT_DEBUG
+   TPMFRONT_DEBUG("Sending Msg to backend size=3D%u", (unsigned int) len=
gth);
+   for(i =3D 0; i < length; ++i) {
+      if(!(i % 30)) {
+     TPMFRONT_DEBUG_MORE("\n");
+      }
+      TPMFRONT_DEBUG_MORE("%02X ", msg[i]);
+   }
+   TPMFRONT_DEBUG_MORE("\n");
+#endif
+
+   /* Copy to shared pages now */
+   for(i =3D 0; length > 0 && i < TPMIF_TX_RING_SIZE; ++i) {
+      /* Share the page */
+      tx =3D &dev->tx->ring[i].req;
+      tx->unused =3D 0;
+      tx->addr =3D virt_to_mach(dev->pages[i]);
+      tx->ref =3D gnttab_grant_access(dev->bedomid,
virt_to_mfn(dev->pages[i]), 0);
+      /* Copy the bits to the page */
+      tx->size =3D length > PAGE_SIZE ? PAGE_SIZE : length;
+      memcpy(dev->pages[i], &msg[i * PAGE_SIZE], tx->size);
+
+      /* Update counters */
+      length -=3D tx->size;
+   }
+   dev->waiting =3D 1;
+   dev->resplen =3D 0;
+#ifdef HAVE_LIBC
+   if(dev->fd >=3D 0) {
+      files[dev->fd].read =3D 0;
+      files[dev->fd].tpmfront.respgot =3D 0;
+      files[dev->fd].tpmfront.offset =3D 0;
+   }
+#endif
+   notify_remote_via_evtchn(dev->evtchn);
+   return 0;
+}
+int tpmfront_recv(struct tpmfront_dev* dev, uint8_t** msg, size_t *lengt=
h)
+{
+   tpmif_tx_request_t* tx;
+   int i;
+   if(dev =3D=3D NULL || dev->state !=3D XenbusStateConnected) {
+      TPMFRONT_ERR("Tried to receive message from disconnected
frontend\n");
+      return -1;
+   }
+   /*Wait for the response */
+   wait_event(dev->waitq, (!dev->waiting));
+
+   /* Initialize */
+   *msg =3D NULL;
+   *length =3D 0;
+
+   /* special case, just quit */
+   tx =3D &dev->tx->ring[0].req;
+   if(tx->size =3D=3D 0 ) {
+       goto quit;
+   }
+   /* Get the total size */
+   tx =3D &dev->tx->ring[0].req;
+   for(i =3D 0; i < TPMIF_TX_RING_SIZE && tx->size > 0; ++i) {
+      tx =3D &dev->tx->ring[i].req;
+      *length +=3D tx->size;
+   }
+   /* Alloc the buffer */
+   if(dev->respbuf) {
+      free(dev->respbuf);
+   }
+   *msg =3D dev->respbuf =3D malloc(*length);
+   dev->resplen =3D *length;
+   /* Copy the bits */
+   tx =3D &dev->tx->ring[0].req;
+   for(i =3D 0; i < TPMIF_TX_RING_SIZE && tx->size > 0; ++i) {
+      tx =3D &dev->tx->ring[i].req;
+      memcpy(&(*msg)[i * PAGE_SIZE], dev->pages[i], tx->size);
+      gnttab_end_access(tx->ref);
+      tx->ref =3D 0;
+   }
+#ifdef TPMFRONT_PRINT_DEBUG
+   TPMFRONT_DEBUG("Received response from backend size=3D%u", (unsigned
int) *length);
+   for(i =3D 0; i < *length; ++i) {
+      if(!(i % 30)) {
+     TPMFRONT_DEBUG_MORE("\n");
+      }
+      TPMFRONT_DEBUG_MORE("%02X ", (*msg)[i]);
+   }
+   TPMFRONT_DEBUG_MORE("\n");
+#endif
+#ifdef HAVE_LIBC
+   if(dev->fd >=3D 0) {
+      files[dev->fd].tpmfront.respgot =3D 1;
+   }
+#endif
+quit:
+   return 0;
+}
+
+int tpmfront_cmd(struct tpmfront_dev* dev, uint8_t* req, size_t reqlen,
uint8_t** resp, size_t* resplen)
+{
+   int rc;
+   if((rc =3D tpmfront_send(dev, req, reqlen))) {
+      return rc;
+   }
+   if((rc =3D tpmfront_recv(dev, resp, resplen))) {
+      return rc;
+   }
+
+   return 0;
+}
+
+#ifdef HAVE_LIBC
+#include <errno.h>
+int tpmfront_open(struct tpmfront_dev* dev)
+{
+   /* Silently prevent multiple opens */
+   if(dev->fd !=3D -1) {
+      return dev->fd;
+   }
+
+   dev->fd =3D alloc_fd(FTYPE_TPMFRONT);
+   printk("tpmfront_open(%s) -> %d\n", dev->nodename, dev->fd);
+   files[dev->fd].tpmfront.dev =3D dev;
+   files[dev->fd].tpmfront.offset =3D 0;
+   files[dev->fd].tpmfront.respgot =3D 0;
+   return dev->fd;
+}
+
+int tpmfront_posix_write(int fd, const uint8_t* buf, size_t count)
+{
+   int rc;
+   struct tpmfront_dev* dev;
+   dev =3D files[fd].tpmfront.dev;
+
+   if(count =3D=3D 0) {
+      return 0;
+   }
+
+   /* Return an error if we are already processing a command */
+   if(dev->waiting) {
+      errno =3D EINPROGRESS;
+      return -1;
+   }
+   /* Send the command now */
+   if((rc =3D tpmfront_send(dev, buf, count)) !=3D 0) {
+      errno =3D EIO;
+      return -1;
+   }
+   return count;
+}
+
+int tpmfront_posix_read(int fd, uint8_t* buf, size_t count)
+{
+   int rc;
+   uint8_t* dummybuf;
+   size_t dummysz;
+   struct tpmfront_dev* dev;
+
+   dev =3D files[fd].tpmfront.dev;
+
+   if(count =3D=3D 0) {
+      return 0;
+   }
+
+   /* get the response if we haven't already */
+   if(files[dev->fd].tpmfront.respgot =3D=3D 0) {
+      if ((rc =3D tpmfront_recv(dev, &dummybuf, &dummysz)) !=3D 0) {
+     errno =3D EIO;
+     return -1;
+      }
+   }
+
+   /* handle EOF case */
+   if(files[dev->fd].tpmfront.offset >=3D dev->resplen) {
+      return 0;
+   }
+
+   /* Compute the number of bytes and do the copy operation */
+   if((rc =3D min(count, dev->resplen - files[dev->fd].tpmfront.offset))=

!=3D 0) {
+      memcpy(buf, dev->respbuf + files[dev->fd].tpmfront.offset, rc);
+      files[dev->fd].tpmfront.offset +=3D rc;
+   }
+
+   return rc;
+}
+
+int tpmfront_posix_fstat(int fd, struct stat* buf)
+{
+   uint8_t* dummybuf;
+   size_t dummysz;
+   int rc;
+   struct tpmfront_dev* dev =3D files[fd].tpmfront.dev;
+
+   /* If we have a response waiting, then read it now from the backend
+    * so we can get its length*/
+   if(dev->waiting || (files[dev->fd].read =3D=3D 1 &&
!files[dev->fd].tpmfront.respgot)) {
+      if ((rc =3D tpmfront_recv(dev, &dummybuf, &dummysz)) !=3D 0) {
+     errno =3D EIO;
+     return -1;
+      }
+   }
+
+   buf->st_mode =3D O_RDWR;
+   buf->st_uid =3D 0;
+   buf->st_gid =3D 0;
+   buf->st_size =3D dev->resplen;
+   buf->st_atime =3D buf->st_mtime =3D buf->st_ctime =3D time(NULL);
+
+   return 0;
+}
+
+
+#endif
--=20
1.7.4.4



--------------ms000807020403040901070008
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIDyjCC
A8YwggMvoAMCAQICBD/xyf0wDQYJKoZIhvcNAQEFBQAwLzELMAkGA1UEBhMCVVMxDzANBgNV
BAoTBkpIVUFQTDEPMA0GA1UECxMGQklTRENBMB4XDTEwMDYxMTE4MjIwNloXDTEzMDYxMTE4
NTIwNlowZjELMAkGA1UEBhMCVVMxDzANBgNVBAoTBkpIVUFQTDEPMA0GA1UECxMGUGVvcGxl
MTUwFgYDVQQLEw9WUE5Hcm91cC1CSVNEQ0EwGwYDVQQDExRNYXR0aGV3IEUgRmlvcmF2YW50
ZTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAnpbwVSP6o1Nb5lcW7dd3yTo9iBJdi7qz
4nANOMFPK7JOy5npKN1iiousl28U/scUJES55gPwAWYJK3uVyQAsA4adgDKi5DoD1UHDQEwp
bY7iHLJeq0NPr4BqYNqnCFPbE6HC8zSJrr4qKn+gVUQT39SIFqdiIPJwZL8FYTRQ/zsCAwEA
AaOCAbYwggGyMAsGA1UdDwQEAwIHgDArBgNVHRAEJDAigA8yMDEwMDYxMTE4MjIwNlqBDzIw
MTIwNzE3MjI1MjA2WjAbBg0rBgEEAbMlCwMBAQEBBAoWCGZpb3JhbWUxMBsGDSsGAQQBsyUL
AwEBAQIEChIIMDAxMDQyNjEwWAYJYIZIAYb6ax4BBEsMSVRoZSBwcml2YXRlIGtleSBjb3Jy
ZXNwb25kaW5nIHRvIHRoaXMgY2VydGlmaWNhdGUgbWF5IGhhdmUgYmVlbiBleHBvcnRlZC4w
KAYDVR0RBCEwH4EdTWF0dGhldy5GaW9yYXZhbnRlQGpodWFwbC5lZHUwUgYDVR0fBEswSTBH
oEWgQ6RBMD8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJU0RD
QTEOMAwGA1UEAxMFQ1JMNTYwHwYDVR0jBBgwFoAUCDUpmxH52EU2CyWmF2EJMB1yqeswHQYD
VR0OBBYEFO6LYxg6r9wHZ+zdQtBHn1dZ/YTNMAkGA1UdEwQCMAAwGQYJKoZIhvZ9B0EABAww
ChsEVjcuMQMCBLAwDQYJKoZIhvcNAQEFBQADgYEAJO9HQh4YNChVLzuZqK5ARJARD8JoujGZ
fdo75quvg2jXFQe2sEjvLnxJZgm/pv8fdZakq48CWwjYHKuvIp7sDjTEsQfo+y7SpN/N2NvJ
WU5SqfK1VgYtNLRRoGJUB5Q1aZ+Dg95g3kqpyfpUMISJL8IKVLtJVfN4fggFVUYZ9wwxggGr
MIIBpwIBATA3MC8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJ
U0RDQQIEP/HJ/TAJBgUrDgMCGgUAoIHLMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ
KoZIhvcNAQkFMQ8XDTEyMDkxNzIyMDgxOVowIwYJKoZIhvcNAQkEMRYEFCDvhxuQEgNUeeUl
ajtCUA7B9EP9MGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAK
BggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI
KoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEgYBTWXnYBBP3DDaeaEjEniS+F1l4cND3Xhpn
VSDM42NXxjpxYsH7l/CZ/6r25411s/Svilj7Vd9i63+0x79J2g9iJtK4BqSsVOJP2dVavsBW
mCrcAsU61sRLRMa7KpxZeIaVdR35NPgJnmBASkssl+G1ypkSbAeQ/UyDZ2QI5+zpTQAAAAAA
AA==
--------------ms000807020403040901070008--


--===============1797525133642965968==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============1797525133642965968==--


From xen-devel-bounces@lists.xen.org Mon Sep 17 22:10:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 22:10:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDjVw-0002JE-GZ; Mon, 17 Sep 2012 22:10:00 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <matthew.fioravante@jhuapl.edu>) id 1TDjVt-0002J5-NL
	for xen-devel@lists.xensource.com; Mon, 17 Sep 2012 22:09:58 +0000
Received: from [85.158.139.211:21339] by server-1.bemta-5.messagelabs.com id
	A6/5B-32692-4BF97505; Mon, 17 Sep 2012 22:09:56 +0000
X-Env-Sender: matthew.fioravante@jhuapl.edu
X-Msg-Ref: server-5.tower-206.messagelabs.com!1347919790!18879156!1
X-Originating-IP: [128.244.251.36]
X-SpamReason: No, hits=0.0 required=7.0 tests=UNPARSEABLE_RELAY
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20631 invoked from network); 17 Sep 2012 22:09:51 -0000
Received: from pilot.jhuapl.edu (HELO jhuapl.edu) (128.244.251.36)
	by server-5.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 17 Sep 2012 22:09:51 -0000
Received: from ([128.244.207.89])
	by pilot.jhuapl.edu with ESMTP with TLS id 63GHCH1.153076130;
	Mon, 17 Sep 2012 18:09:34 -0400
Message-ID: <50579F53.4070302@jhuapl.edu>
Date: Mon, 17 Sep 2012 18:08:19 -0400
From: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120827 Thunderbird/15.0
MIME-Version: 1.0
To: Samuel Thibault <samuel.thibault@ens-lyon.org>, 
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
X-Enigmail-Version: 1.4.4
Subject: [Xen-devel] [PATCH mini-os enhancements for vtpm 8/8] Add 3 tpm
	drivers to mini-os
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1797525133642965968=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a cryptographically signed message in MIME format.

--===============1797525133642965968==
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms000807020403040901070008"

This is a cryptographically signed message in MIME format.

--------------ms000807020403040901070008
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

This patch adds 3 new drivers to mini-os.

tpmfront - paravirtualized tpm frontend driver
tpmback - paravirtualized tpm backend driver
tpm_tis - hardware tpm driver

Unfortunately these drivers were derived from GPL licensed linux kernel
drivers so they must carry the GPL license. However, since mini-os now
supports conditional compilation, hopefully these drivers can be
included into the xen tree and conditionally removed from non-gpl
projects. By default they are disabled in the makefile.

Signed off by: Matthew Fioravante matthew.fioravante@jhuapl.edu

diff --git a/extras/mini-os/Makefile b/extras/mini-os/Makefile
--- a/extras/mini-os/Makefile
+++ b/extras/mini-os/Makefile
@@ -22,6 +22,9 @@ CONFIG_QEMU_XS_ARGS ?=3D n
 CONFIG_TEST ?=3D n
 CONFIG_PCIFRONT ?=3D n
 CONFIG_BLKFRONT ?=3D y
+CONFIG_TPMFRONT ?=3D n
+CONFIG_TPM_TIS ?=3D n
+CONFIG_TPMBACK ?=3D n
 CONFIG_NETFRONT ?=3D y
 CONFIG_FBFRONT ?=3D y
 CONFIG_KBDFRONT ?=3D y
@@ -36,6 +39,9 @@ flags-$(CONFIG_SPARSE_BSS) +=3D -DCONFIG_SPARSE_BSS
 flags-$(CONFIG_QEMU_XS_ARGS) +=3D -DCONFIG_QEMU_XS_ARGS
 flags-$(CONFIG_PCIFRONT) +=3D -DCONFIG_PCIFRONT
 flags-$(CONFIG_BLKFRONT) +=3D -DCONFIG_BLKFRONT
+flags-$(CONFIG_TPMFRONT) +=3D -DCONFIG_TPMFRONT
+flags-$(CONFIG_TPM_TIS) +=3D -DCONFIG_TPM_TIS
+flags-$(CONFIG_TPMBACK) +=3D -DCONFIG_TPMBACK
 flags-$(CONFIG_NETFRONT) +=3D -DCONFIG_NETFRONT
 flags-$(CONFIG_KBDFRONT) +=3D -DCONFIG_KBDFRONT
 flags-$(CONFIG_FBFRONT) +=3D -DCONFIG_FBFRONT
@@ -67,6 +73,9 @@ TARGET :=3D mini-os
 SUBDIRS :=3D lib xenbus console
=20
 src-$(CONFIG_BLKFRONT) +=3D blkfront.c
+src-$(CONFIG_TPMFRONT) +=3D tpmfront.c
+src-$(CONFIG_TPM_TIS) +=3D tpm_tis.c
+src-$(CONFIG_TPMBACK) +=3D tpmback.c
 src-y +=3D daytime.c
 src-y +=3D events.c
 src-$(CONFIG_FBFRONT) +=3D fbfront.c
diff --git a/extras/mini-os/include/lib.h b/extras/mini-os/include/lib.h
--- a/extras/mini-os/include/lib.h
+++ b/extras/mini-os/include/lib.h
@@ -142,6 +142,8 @@ enum fd_type {
     FTYPE_FB,
     FTYPE_MEM,
     FTYPE_SAVEFILE,
+    FTYPE_TPMFRONT,
+    FTYPE_TPM_TIS,
 };
=20
 LIST_HEAD(evtchn_port_list, evtchn_port_info);
@@ -185,6 +187,20 @@ extern struct file {
     struct {
         struct consfront_dev *dev;
     } cons;
+#ifdef CONFIG_TPMFRONT
+    struct {
+       struct tpmfront_dev *dev;
+       int respgot;
+       off_t offset;
+    } tpmfront;
+#endif
+#ifdef CONFIG_TPM_TIS
+    struct {
+       struct tpm_chip *dev;
+       int respgot;
+       off_t offset;
+    } tpm_tis;
+#endif
 #ifdef CONFIG_XENBUS
         struct {
             /* To each xenbus FD is associated a queue of watch events
for this
diff --git a/extras/mini-os/include/tpm_tis.h
b/extras/mini-os/include/tpm_tis.h
--- /dev/null
+++ b/extras/mini-os/include/tpm_tis.h
@@ -0,0 +1,63 @@
+/*
+ * Copyright (c) 2010-2012 United States Government, as represented by
+ * the Secretary of Defense.  All rights reserved.
+ *
+ * This driver 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 3 of the License, or
+ * (at your option) any later version.
+ *
+ * This driver is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program.  If not, see <http://www.gnu.org/licenses/>.=

+ *
+ * Based upon the files:
+ *  drivers/char/tpm/tpm_tis.c
+ *  drivers/char/tpm/tpm.c
+ * from the Linux kernel, which are Copyright (C) 2006 IBM Corporation
+ */
+#ifndef TPM_TIS_H
+#define TPM_TIS_H
+
+#include <mini-os/types.h>
+#include <mini-os/byteorder.h>
+
+#define TPM_TIS_EN_LOCL0 1
+#define TPM_TIS_EN_LOCL1 (1 << 1)
+#define TPM_TIS_EN_LOCL2 (1 << 2)
+#define TPM_TIS_EN_LOCL3 (1 << 3)
+#define TPM_TIS_EN_LOCL4 (1 << 4)
+#define TPM_TIS_EN_LOCLALL (TPM_TIS_EN_LOCL0 | TPM_TIS_EN_LOCL1  |
TPM_TIS_EN_LOCL2 | TPM_TIS_EN_LOCL3 | TPM_TIS_EN_LOCL4)
+#define TPM_TIS_LOCL_INT_TO_FLAG(x) (1 << x)
+#define TPM_BASEADDR 0xFED40000
+#define TPM_PROBE_IRQ 0xFFFF
+
+struct tpm_chip;
+
+struct tpm_chip* init_tpm_tis(unsigned long baseaddr, int localities,
unsigned int irq);
+void shutdown_tpm_tis(struct tpm_chip* tpm);
+
+int tpm_tis_request_locality(struct tpm_chip* tpm, int locality);
+int tpm_tis_cmd(struct tpm_chip* tpm, uint8_t* req, size_t reqlen,
uint8_t** resp, size_t* resplen);
+
+#ifdef HAVE_LIBC
+#include <sys/stat.h>
+#include <fcntl.h>
+/* POSIX IO functions:
+ * use tpm_tis_open() to get a file descriptor to the tpm device
+ * use write() on the fd to send a command to the backend. You must
+ * include the entire command in a single call to write().
+ * use read() on the fd to read the response. You can use
+ * fstat() to get the size of the response and lseek() to seek on it.
+ */
+int tpm_tis_open(struct tpm_chip* tpm);
+int tpm_tis_posix_read(int fd, uint8_t* buf, size_t count);
+int tpm_tis_posix_write(int fd, const uint8_t* buf, size_t count);
+int tpm_tis_posix_fstat(int fd, struct stat* buf);
+#endif
+
+#endif
diff --git a/extras/mini-os/include/tpmback.h
b/extras/mini-os/include/tpmback.h
--- /dev/null
+++ b/extras/mini-os/include/tpmback.h
@@ -0,0 +1,95 @@
+/*
+ * Copyright (c) 2010-2012 United States Government, as represented by
+ * the Secretary of Defense.  All rights reserved.
+ *
+ * This driver 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 3 of the License, or
+ * (at your option) any later version.
+ *
+ * This driver is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program.  If not, see <http://www.gnu.org/licenses/>.=

+ *
+ * Based upon the files:
+ *  drivers/xen/tpmbk.c
+ * from the Linux kernel, which are Copyright (C) 2006 IBM Corporation
+ */
+#include <xen/io/tpmif.h>
+#include <xen/io/xenbus.h>
+#include <mini-os/types.h>
+#include <xen/xen.h>
+#ifndef TPMBACK_H
+#define TPMBACK_H
+
+struct tpmcmd {
+   domid_t domid;        /* Domid of the frontend */
+   unsigned int handle;    /* Handle of the frontend */
+   char* uuid;            /* uuid of the tpm interface - allocated
internally, dont free it */
+
+   unsigned int req_len;        /* Size of the command in buf - set by
tpmback driver */
+   uint8_t* req;            /* tpm command bits, allocated by driver,
DON'T FREE IT */
+   unsigned int resp_len;    /* Size of the outgoing command,
+                   you set this before passing the cmd object to
tpmback_resp */
+   uint8_t* resp;        /* Buffer for response - YOU MUST ALLOCATE IT,
YOU MUST ALSO FREE IT */
+};
+typedef struct tpmcmd tpmcmd_t;
+
+/* Initialize the tpm backend driver
+ * @exclusive_domname - This is NULL terminated list of vtpm uuid
strings. If this list
+ *             is non-empty, then only frontend domains with vtpm
uuid's matching
+ *             entries in this list will be allowed to connect.
+ *             Other connections will be immediatly closed.
+ *             Set this argument to NULL to allow any vtpm to connect.
+ */
+void init_tpmback(char** exclusive_uuids);
+/* Shutdown tpm backend driver */
+void shutdown_tpmback(void);
+
+/* Blocks until a tpm command is sent from any front end.
+ * Returns a pointer to the tpm command to handle.
+ * Do not try to free this pointer or the req buffer
+ * This function will return NULL if the tpm backend driver
+ * is shutdown or any other error occurs */
+tpmcmd_t* tpmback_req_any(void);
+
+/* Blocks until a tpm command from the frontend at domid/handle
+ * is sent.
+ * Returns NULL if domid/handle is not connected, tpmback is
+ * shutdown or shutting down, or if there is an error
+ */
+tpmcmd_t* tpmback_req(domid_t domid, unsigned int handle);
+
+/* Send the response to the tpm command back to the frontend
+ * This function will free the tpmcmd object, but you must free the resp=

+ * buffer yourself */
+void tpmback_resp(tpmcmd_t* tpmcmd);
+
+/* Waits for the first frontend to connect and then sets domid and
handle appropriately.
+ * If one or more frontends are already connected, this will set domid
and handle to one
+ * of them arbitrarily. The main use for this function is to wait until
a single
+ * frontend connection has occured.
+ * returns 0 on success, non-zero on failure */
+int tpmback_wait_for_frontend_connect(domid_t *domid, unsigned int
*handle);
+
+/* returns the number of frontends connected */
+int tpmback_num_frontends(void);
+
+/* Returns the uuid of the specified frontend, NULL on error */
+char* tpmback_get_uuid(domid_t domid, unsigned int handle);
+
+/* Specify a function to call when a new tpm device connects */
+void tpmback_set_open_callback(void (*cb)(domid_t, unsigned int));
+
+/* Specify a function to call when a tpm device disconnects */
+void tpmback_set_close_callback(void (*cb)(domid_t, unsigned int));
+
+//Not Implemented
+void tpmback_set_suspend_callback(void (*cb)(domid_t, unsigned int));
+void tpmback_set_resume_callback(void (*cb)(domid_t, unsigned int));
+
+#endif
diff --git a/extras/mini-os/include/tpmfront.h
b/extras/mini-os/include/tpmfront.h
--- /dev/null
+++ b/extras/mini-os/include/tpmfront.h
@@ -0,0 +1,94 @@
+/*
+ * Copyright (c) 2010-2012 United States Government, as represented by
+ * the Secretary of Defense.  All rights reserved.
+ *
+ * This driver 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 3 of the License, or
+ * (at your option) any later version.
+ *
+ * This driver is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program.  If not, see <http://www.gnu.org/licenses/>.=

+ *
+ * Based upon the files:
+ *  drivers/char/tpm/tpm_vtpm.c
+ *  drivers/char/tpm/tpm_xen.c
+ * from the Linux kernel, which are Copyright (C) 2006 IBM Corporation
+ */
+#ifndef TPMFRONT_H
+#define TPMFRONT_H
+
+#include <mini-os/types.h>
+#include <mini-os/os.h>
+#include <mini-os/events.h>
+#include <mini-os/wait.h>
+#include <xen/xen.h>
+#include <xen/io/xenbus.h>
+#include <xen/io/tpmif.h>
+
+struct tpmfront_dev {
+   grant_ref_t ring_ref;
+   evtchn_port_t evtchn;
+
+   tpmif_tx_interface_t* tx;
+
+   void** pages;
+
+   domid_t bedomid;
+   char* nodename;
+   char* bepath;
+
+   XenbusState state;
+
+   uint8_t waiting;
+   struct wait_queue_head waitq;
+
+   uint8_t* respbuf;
+   size_t resplen;
+
+#ifdef HAVE_LIBC
+   int fd;
+#endif
+
+};
+
+
+/*Initialize frontend */
+struct tpmfront_dev* init_tpmfront(const char* nodename);
+/*Shutdown frontend */
+void shutdown_tpmfront(struct tpmfront_dev* dev);
+
+/* Send a tpm command to the backend and wait for the response
+ *
+ * @dev - frontend device
+ * @req - request buffer
+ * @reqlen - length of request buffer
+ * @resp - *resp will be set to internal response buffer, don't free
it! Value is undefined on error
+ * @resplen - *resplen will be set to the length of the response. Value
is undefined on error
+ *
+ * returns 0 on success, non zero on failure.
+ * */
+int tpmfront_cmd(struct tpmfront_dev* dev, uint8_t* req, size_t reqlen,
uint8_t** resp, size_t* resplen);
+
+#ifdef HAVE_LIBC
+#include <sys/stat.h>
+/* POSIX IO functions:
+ * use tpmfront_open() to get a file descriptor to the tpm device
+ * use write() on the fd to send a command to the backend. You must
+ * include the entire command in a single call to write().
+ * use read() on the fd to read the response. You can use
+ * fstat() to get the size of the response and lseek() to seek on it.
+ */
+int tpmfront_open(struct tpmfront_dev* dev);
+int tpmfront_posix_read(int fd, uint8_t* buf, size_t count);
+int tpmfront_posix_write(int fd, const uint8_t* buf, size_t count);
+int tpmfront_posix_fstat(int fd, struct stat* buf);
+#endif
+
+
+#endif
diff --git a/extras/mini-os/lib/sys.c b/extras/mini-os/lib/sys.c
--- a/extras/mini-os/lib/sys.c
+++ b/extras/mini-os/lib/sys.c
@@ -27,6 +27,8 @@
 #include <netfront.h>
 #include <blkfront.h>
 #include <fbfront.h>
+#include <tpmfront.h>
+#include <tpm_tis.h>
 #include <xenbus.h>
 #include <xenstore.h>
=20
@@ -294,6 +296,16 @@ int read(int fd, void *buf, size_t nbytes)
         return blkfront_posix_read(fd, buf, nbytes);
         }
 #endif
+#ifdef CONFIG_TPMFRONT
+        case FTYPE_TPMFRONT: {
+        return tpmfront_posix_read(fd, buf, nbytes);
+        }
+#endif
+#ifdef CONFIG_TPM_TIS
+        case FTYPE_TPM_TIS: {
+        return tpm_tis_posix_read(fd, buf, nbytes);
+        }
+#endif
     default:
         break;
     }
@@ -330,6 +342,14 @@ int write(int fd, const void *buf, size_t nbytes)
     case FTYPE_BLK:
         return blkfront_posix_write(fd, buf, nbytes);
 #endif
+#ifdef CONFIG_TPMFRONT
+    case FTYPE_TPMFRONT:
+        return tpmfront_posix_write(fd, buf, nbytes);
+#endif
+#ifdef CONFIG_TPM_TIS
+    case FTYPE_TPM_TIS:
+        return tpm_tis_posix_write(fd, buf, nbytes);
+#endif
     default:
         break;
     }
@@ -341,8 +361,16 @@ int write(int fd, const void *buf, size_t nbytes)
 off_t lseek(int fd, off_t offset, int whence)
 {
     switch(files[fd].type) {
+#if defined(CONFIG_BLKFRONT) || defined(CONFIG_TPMFRONT) ||
defined(CONFIG_TPM_TIS)
 #ifdef CONFIG_BLKFRONT
        case FTYPE_BLK:
+#endif
+#ifdef CONFIG_TPMFRNT
+       case FTYPE_TPMFRONT:
+#endif
+#ifdef CONFIG_TPM_TIS
+       case FTYPE_TPM_TIS:
+#endif
       switch (whence) {
          case SEEK_SET:
         files[fd].file.offset =3D offset;
@@ -420,6 +448,18 @@ int close(int fd)
         files[fd].type =3D FTYPE_NONE;
         return 0;
 #endif
+#ifdef CONFIG_TPMFRONT
+    case FTYPE_TPMFRONT:
+            shutdown_tpmfront(files[fd].tpmfront.dev);
+        files[fd].type =3D FTYPE_NONE;
+        return 0;
+#endif
+#ifdef CONFIG_TPM_TIS
+    case FTYPE_TPM_TIS:
+            shutdown_tpm_tis(files[fd].tpm_tis.dev);
+        files[fd].type =3D FTYPE_NONE;
+        return 0;
+#endif
 #ifdef CONFIG_KBDFRONT
     case FTYPE_KBD:
             shutdown_kbdfront(files[fd].kbd.dev);
@@ -489,6 +529,14 @@ int fstat(int fd, struct stat *buf)
     case FTYPE_BLK:
        return blkfront_posix_fstat(fd, buf);
 #endif
+#ifdef CONFIG_TPMFRONT
+    case FTYPE_TPMFRONT:
+       return tpmfront_posix_fstat(fd, buf);
+#endif
+#ifdef CONFIG_TPM_TIS
+    case FTYPE_TPM_TIS:
+       return tpm_tis_posix_fstat(fd, buf);
+#endif
     default:
         break;
     }
diff --git a/extras/mini-os/tpm_tis.c b/extras/mini-os/tpm_tis.c
--- /dev/null
+++ b/extras/mini-os/tpm_tis.c
@@ -0,0 +1,1344 @@
+/*
+ * Copyright (c) 2010-2012 United States Government, as represented by
+ * the Secretary of Defense.  All rights reserved.
+ *
+ * This driver 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 3 of the License, or
+ * (at your option) any later version.
+ *
+ * This driver is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program.  If not, see <http://www.gnu.org/licenses/>.=

+ *
+ * Based upon the files:
+ *  drivers/char/tpm/tpm_tis.c
+ *  drivers/char/tpm/tpm.c
+ * from the Linux kernel, which are Copyright (C) 2006 IBM Corporation
+ */
+#include <mini-os/ioremap.h>
+#include <mini-os/iorw.h>
+#include <mini-os/tpm_tis.h>
+#include <mini-os/os.h>
+#include <mini-os/sched.h>
+#include <mini-os/byteorder.h>
+#include <mini-os/events.h>
+#include <mini-os/wait.h>
+#include <mini-os/xmalloc.h>
+#include <errno.h>
+#include <stdbool.h>
+
+#ifndef min
+    #define min( a, b ) ( ((a) < (b)) ? (a) : (b) )
+#endif
+
+#define TPM_HEADER_SIZE 10
+
+#define TPM_BUFSIZE 2048
+
+struct tpm_input_header {
+        uint16_t  tag;
+        uint32_t  length;
+        uint32_t  ordinal;
+}__attribute__((packed));
+
+struct tpm_output_header {
+        uint16_t  tag;
+        uint32_t  length;
+        uint32_t  return_code;
+}__attribute__((packed));
+
+struct  stclear_flags_t {
+        uint16_t  tag;
+        uint8_t      deactivated;
+        uint8_t      disableForceClear;
+        uint8_t      physicalPresence;
+        uint8_t      physicalPresenceLock;
+        uint8_t      bGlobalLock;
+}__attribute__((packed));
+
+struct  tpm_version_t {
+        uint8_t      Major;
+        uint8_t      Minor;
+        uint8_t      revMajor;
+        uint8_t      revMinor;
+}__attribute__((packed));
+
+struct  tpm_version_1_2_t {
+        uint16_t  tag;
+        uint8_t      Major;
+        uint8_t      Minor;
+        uint8_t      revMajor;
+        uint8_t      revMinor;
+}__attribute__((packed));
+
+struct  timeout_t {
+        uint32_t  a;
+        uint32_t  b;
+        uint32_t  c;
+        uint32_t  d;
+}__attribute__((packed));
+
+struct duration_t {
+        uint32_t  tpm_short;
+        uint32_t  tpm_medium;
+        uint32_t  tpm_long;
+}__attribute__((packed));
+
+struct permanent_flags_t {
+        uint16_t  tag;
+        uint8_t      disable;
+        uint8_t      ownership;
+        uint8_t      deactivated;
+        uint8_t      readPubek;
+        uint8_t      disableOwnerClear;
+        uint8_t      allowMaintenance;
+        uint8_t      physicalPresenceLifetimeLock;
+        uint8_t      physicalPresenceHWEnable;
+        uint8_t      physicalPresenceCMDEnable;
+        uint8_t      CEKPUsed;
+        uint8_t      TPMpost;
+        uint8_t      TPMpostLock;
+        uint8_t      FIPS;
+        uint8_t      operator;
+        uint8_t      enableRevokeEK;
+        uint8_t      nvLocked;
+        uint8_t      readSRKPub;
+        uint8_t      tpmEstablished;
+        uint8_t      maintenanceDone;
+        uint8_t      disableFullDALogicInfo;
+}__attribute__((packed));
+
+typedef union {
+        struct  permanent_flags_t perm_flags;
+        struct  stclear_flags_t stclear_flags;
+        bool    owned;
+        uint32_t  num_pcrs;
+        struct  tpm_version_t   tpm_version;
+        struct  tpm_version_1_2_t tpm_version_1_2;
+        uint32_t  manufacturer_id;
+        struct timeout_t  timeout;
+        struct duration_t duration;
+} cap_t;
+
+struct  tpm_getcap_params_in {
+        uint32_t  cap;
+        uint32_t  subcap_size;
+        uint32_t  subcap;
+}__attribute__((packed));
+
+struct  tpm_getcap_params_out {
+        uint32_t  cap_size;
+        cap_t   cap;
+}__attribute__((packed));
+
+struct  tpm_readpubek_params_out {
+        uint8_t      algorithm[4];
+        uint8_t      encscheme[2];
+        uint8_t      sigscheme[2];
+        uint32_t  paramsize;
+        uint8_t      parameters[12]; /*assuming RSA*/
+        uint32_t  keysize;
+        uint8_t      modulus[256];
+        uint8_t      checksum[20];
+}__attribute__((packed));
+
+typedef union {
+        struct  tpm_input_header in;
+        struct  tpm_output_header out;
+} tpm_cmd_header;
+
+#define TPM_DIGEST_SIZE 20
+struct tpm_pcrread_out {
+        uint8_t      pcr_result[TPM_DIGEST_SIZE];
+}__attribute__((packed));
+
+struct tpm_pcrread_in {
+        uint32_t  pcr_idx;
+}__attribute__((packed));
+
+struct tpm_pcrextend_in {
+        uint32_t  pcr_idx;
+        uint8_t      hash[TPM_DIGEST_SIZE];
+}__attribute__((packed));
+
+typedef union {
+        struct  tpm_getcap_params_out getcap_out;
+        struct  tpm_readpubek_params_out readpubek_out;
+        uint8_t      readpubek_out_buffer[sizeof(struct
tpm_readpubek_params_out)];
+        struct  tpm_getcap_params_in getcap_in;
+        struct  tpm_pcrread_in  pcrread_in;
+        struct  tpm_pcrread_out pcrread_out;
+        struct  tpm_pcrextend_in pcrextend_in;
+} tpm_cmd_params;
+
+struct tpm_cmd_t {
+        tpm_cmd_header  header;
+        tpm_cmd_params  params;
+}__attribute__((packed));
+
+
+enum tpm_duration {
+   TPM_SHORT =3D 0,
+   TPM_MEDIUM =3D 1,
+   TPM_LONG =3D 2,
+   TPM_UNDEFINED,
+};
+
+#define TPM_MAX_ORDINAL 243
+#define TPM_MAX_PROTECTED_ORDINAL 12
+#define TPM_PROTECTED_ORDINAL_MASK 0xFF
+
+extern const uint8_t
tpm_protected_ordinal_duration[TPM_MAX_PROTECTED_ORDINAL];
+extern const uint8_t tpm_ordinal_duration[TPM_MAX_ORDINAL];
+
+#define TPM_DIGEST_SIZE 20
+#define TPM_ERROR_SIZE 10
+#define TPM_RET_CODE_IDX 6
+
+/* tpm_capabilities */
+#define TPM_CAP_FLAG cpu_to_be32(4)
+#define TPM_CAP_PROP cpu_to_be32(5)
+#define CAP_VERSION_1_1 cpu_to_be32(0x06)
+#define CAP_VERSION_1_2 cpu_to_be32(0x1A)
+
+/* tpm_sub_capabilities */
+#define TPM_CAP_PROP_PCR cpu_to_be32(0x101)
+#define TPM_CAP_PROP_MANUFACTURER cpu_to_be32(0x103)
+#define TPM_CAP_FLAG_PERM cpu_to_be32(0x108)
+#define TPM_CAP_FLAG_VOL cpu_to_be32(0x109)
+#define TPM_CAP_PROP_OWNER cpu_to_be32(0x111)
+#define TPM_CAP_PROP_TIS_TIMEOUT cpu_to_be32(0x115)
+#define TPM_CAP_PROP_TIS_DURATION cpu_to_be32(0x120)
+
+
+#define TPM_INTERNAL_RESULT_SIZE 200
+#define TPM_TAG_RQU_COMMAND cpu_to_be16(193)
+#define TPM_ORD_GET_CAP cpu_to_be32(101)
+
+extern const struct tpm_input_header tpm_getcap_header;
+
+
+
+const uint8_t tpm_protected_ordinal_duration[TPM_MAX_PROTECTED_ORDINAL] =
=3D {
+   TPM_UNDEFINED,          /* 0 */
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,          /* 5 */
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_SHORT,              /* 10 */
+   TPM_SHORT,
+};
+
+const uint8_t tpm_ordinal_duration[TPM_MAX_ORDINAL] =3D {
+   TPM_UNDEFINED,          /* 0 */
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,          /* 5 */
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_SHORT,              /* 10 */
+   TPM_SHORT,
+   TPM_MEDIUM,
+   TPM_LONG,
+   TPM_LONG,
+   TPM_MEDIUM,             /* 15 */
+   TPM_SHORT,
+   TPM_SHORT,
+   TPM_MEDIUM,
+   TPM_LONG,
+   TPM_SHORT,              /* 20 */
+   TPM_SHORT,
+   TPM_MEDIUM,
+   TPM_MEDIUM,
+   TPM_MEDIUM,
+   TPM_SHORT,              /* 25 */
+   TPM_SHORT,
+   TPM_MEDIUM,
+   TPM_SHORT,
+   TPM_SHORT,
+   TPM_MEDIUM,             /* 30 */
+   TPM_LONG,
+   TPM_MEDIUM,
+   TPM_SHORT,
+   TPM_SHORT,
+   TPM_SHORT,              /* 35 */
+   TPM_MEDIUM,
+   TPM_MEDIUM,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_MEDIUM,             /* 40 */
+   TPM_LONG,
+   TPM_MEDIUM,
+   TPM_SHORT,
+   TPM_SHORT,
+   TPM_SHORT,              /* 45 */
+   TPM_SHORT,
+   TPM_SHORT,
+   TPM_SHORT,
+   TPM_LONG,
+   TPM_MEDIUM,             /* 50 */
+   TPM_MEDIUM,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,          /* 55 */
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_MEDIUM,             /* 60 */
+   TPM_MEDIUM,
+   TPM_MEDIUM,
+   TPM_SHORT,
+   TPM_SHORT,
+   TPM_MEDIUM,             /* 65 */
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_SHORT,              /* 70 */
+   TPM_SHORT,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,          /* 75 */
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_LONG,               /* 80 */
+   TPM_UNDEFINED,
+   TPM_MEDIUM,
+   TPM_LONG,
+   TPM_SHORT,
+   TPM_UNDEFINED,          /* 85 */
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_SHORT,              /* 90 */
+   TPM_SHORT,
+   TPM_SHORT,
+   TPM_SHORT,
+   TPM_SHORT,
+   TPM_UNDEFINED,          /* 95 */
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_MEDIUM,             /* 100 */
+   TPM_SHORT,
+   TPM_SHORT,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,          /* 105 */
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_SHORT,              /* 110 */
+   TPM_SHORT,
+   TPM_SHORT,
+   TPM_SHORT,
+   TPM_SHORT,
+   TPM_SHORT,              /* 115 */
+   TPM_SHORT,
+   TPM_SHORT,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_LONG,               /* 120 */
+   TPM_LONG,
+   TPM_MEDIUM,
+   TPM_UNDEFINED,
+   TPM_SHORT,
+   TPM_SHORT,              /* 125 */
+   TPM_SHORT,
+   TPM_LONG,
+   TPM_SHORT,
+   TPM_SHORT,
+   TPM_SHORT,              /* 130 */
+   TPM_MEDIUM,
+   TPM_UNDEFINED,
+   TPM_SHORT,
+   TPM_MEDIUM,
+   TPM_UNDEFINED,          /* 135 */
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_SHORT,              /* 140 */
+   TPM_SHORT,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,          /* 145 */
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_SHORT,              /* 150 */
+   TPM_MEDIUM,
+   TPM_MEDIUM,
+   TPM_SHORT,
+   TPM_SHORT,
+   TPM_UNDEFINED,          /* 155 */
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_SHORT,              /* 160 */
+   TPM_SHORT,
+   TPM_SHORT,
+   TPM_SHORT,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,          /* 165 */
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_LONG,               /* 170 */
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,          /* 175 */
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_MEDIUM,             /* 180 */
+   TPM_SHORT,
+   TPM_MEDIUM,
+   TPM_MEDIUM,
+   TPM_MEDIUM,
+   TPM_MEDIUM,             /* 185 */
+   TPM_SHORT,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,          /* 190 */
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,          /* 195 */
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_SHORT,              /* 200 */
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_SHORT,
+   TPM_SHORT,              /* 205 */
+   TPM_SHORT,
+   TPM_SHORT,
+   TPM_SHORT,
+   TPM_SHORT,
+   TPM_MEDIUM,             /* 210 */
+   TPM_UNDEFINED,
+   TPM_MEDIUM,
+   TPM_MEDIUM,
+   TPM_MEDIUM,
+   TPM_UNDEFINED,          /* 215 */
+   TPM_MEDIUM,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_SHORT,
+   TPM_SHORT,              /* 220 */
+   TPM_SHORT,
+   TPM_SHORT,
+   TPM_SHORT,
+   TPM_SHORT,
+   TPM_UNDEFINED,          /* 225 */
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_SHORT,              /* 230 */
+   TPM_LONG,
+   TPM_MEDIUM,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,          /* 235 */
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_SHORT,              /* 240 */
+   TPM_UNDEFINED,
+   TPM_MEDIUM,
+};
+
+const struct tpm_input_header tpm_getcap_header =3D {
+        .tag =3D TPM_TAG_RQU_COMMAND,
+        .length =3D cpu_to_be32(22),
+        .ordinal =3D TPM_ORD_GET_CAP
+};
+
+
+enum tis_access {
+   TPM_ACCESS_VALID =3D 0x80,
+   TPM_ACCESS_ACTIVE_LOCALITY =3D 0x20,    /* (R) */
+   TPM_ACCESS_RELINQUISH_LOCALITY =3D 0x20,/* (W) */
+   TPM_ACCESS_REQUEST_PENDING =3D 0x04,    /* (W) */
+   TPM_ACCESS_REQUEST_USE =3D 0x02,    /* (W) */
+};
+
+enum tis_status {
+   TPM_STS_VALID =3D 0x80,        /* (R) */
+   TPM_STS_COMMAND_READY =3D 0x40,    /* (R) */
+   TPM_STS_DATA_AVAIL =3D 0x10,        /* (R) */
+   TPM_STS_DATA_EXPECT =3D 0x08,        /* (R) */
+   TPM_STS_GO =3D 0x20,            /* (W) */
+};
+
+enum tis_int_flags {
+   TPM_GLOBAL_INT_ENABLE =3D 0x80000000,
+   TPM_INTF_BURST_COUNT_STATIC =3D 0x100,
+   TPM_INTF_CMD_READY_INT =3D 0x080,
+   TPM_INTF_INT_EDGE_FALLING =3D 0x040,
+   TPM_INTF_INT_EDGE_RISING =3D 0x020,
+   TPM_INTF_INT_LEVEL_LOW =3D 0x010,
+   TPM_INTF_INT_LEVEL_HIGH =3D 0x008,
+   TPM_INTF_LOCALITY_CHANGE_INT =3D 0x004,
+   TPM_INTF_STS_VALID_INT =3D 0x002,
+   TPM_INTF_DATA_AVAIL_INT =3D 0x001,
+};
+
+enum tis_defaults {
+   TIS_MEM_BASE =3D 0xFED40000,
+   TIS_MEM_LEN  =3D 0x5000,
+   TIS_SHORT_TIMEOUT =3D 750, /*ms*/
+   TIS_LONG_TIMEOUT =3D 2000, /*2 sec */
+};
+
+#define TPM_TIMEOUT 5
+
+#define TPM_ACCESS(t, l)                   (((uint8_t*)t->pages[l]) +
0x0000)
+#define TPM_INT_ENABLE(t, l)             =20
((uint32_t*)(((uint8_t*)t->pages[l]) + 0x0008))
+#define TPM_INT_VECTOR(t, l)               (((uint8_t*)t->pages[l]) +
0x000C)
+#define TPM_INT_STATUS(t, l)               (((uint8_t*)t->pages[l]) +
0x0010)
+#define TPM_INTF_CAPS(t, l)              =20
((uint32_t*)(((uint8_t*)t->pages[l]) + 0x0014))
+#define TPM_STS(t, l)                    =20
((uint8_t*)(((uint8_t*)t->pages[l]) + 0x0018))
+#define TPM_DATA_FIFO(t, l)                (((uint8_t*)t->pages[l]) +
0x0024)
+
+#define TPM_DID_VID(t, l)                =20
((uint32_t*)(((uint8_t*)t->pages[l]) + 0x0F00))
+#define TPM_RID(t, l)                      (((uint8_t*)t->pages[l]) +
0x0F04)
+
+struct tpm_chip {
+   int enabled_localities;
+   int locality;
+   unsigned long baseaddr;
+   uint8_t* pages[5];
+   int did, vid, rid;
+
+   uint8_t data_buffer[TPM_BUFSIZE];
+   int data_len;
+
+   s_time_t timeout_a, timeout_b, timeout_c, timeout_d;
+   s_time_t duration[3];
+
+#ifdef HAVE_LIBC
+   int fd;
+#endif
+
+   unsigned int irq;
+   struct wait_queue_head read_queue;
+   struct wait_queue_head int_queue;
+};
+
+
+static void __init_tpm_chip(struct tpm_chip* tpm) {
+   tpm->enabled_localities =3D TPM_TIS_EN_LOCLALL;
+   tpm->locality =3D -1;
+   tpm->baseaddr =3D 0;
+   tpm->pages[0] =3D tpm->pages[1] =3D tpm->pages[2] =3D tpm->pages[3] =3D=

tpm->pages[4] =3D NULL;
+   tpm->vid =3D 0;
+   tpm->did =3D 0;
+   tpm->irq =3D 0;
+   init_waitqueue_head(&tpm->read_queue);
+   init_waitqueue_head(&tpm->int_queue);
+
+   tpm->data_len =3D -1;
+
+#ifdef HAVE_LIBC
+   tpm->fd =3D -1;
+#endif
+}
+
+/*
+ * Returns max number of nsecs to wait
+ */
+s_time_t tpm_calc_ordinal_duration(struct tpm_chip *chip,
+      uint32_t ordinal)
+{
+   int duration_idx =3D TPM_UNDEFINED;
+   s_time_t duration =3D 0;
+
+   if (ordinal < TPM_MAX_ORDINAL)
+      duration_idx =3D tpm_ordinal_duration[ordinal];
+   else if ((ordinal & TPM_PROTECTED_ORDINAL_MASK) <
+     TPM_MAX_PROTECTED_ORDINAL)
+      duration_idx =3D
+     tpm_protected_ordinal_duration[ordinal &
+     TPM_PROTECTED_ORDINAL_MASK];
+
+   if (duration_idx !=3D TPM_UNDEFINED) {
+      duration =3D chip->duration[duration_idx];
+   }
+
+   if (duration <=3D 0) {
+      return SECONDS(120);
+   }
+   else
+   {
+      return duration;
+   }
+}
+
+
+static int locality_enabled(struct tpm_chip* tpm, int l) {
+   return tpm->enabled_localities & (1 << l);
+}
+
+static int check_locality(struct tpm_chip* tpm, int l) {
+   if(locality_enabled(tpm, l) && (ioread8(TPM_ACCESS(tpm, l)) &
+        (TPM_ACCESS_ACTIVE_LOCALITY | TPM_ACCESS_VALID)) =3D=3D
+     (TPM_ACCESS_ACTIVE_LOCALITY | TPM_ACCESS_VALID)) {
+      return l;
+   }
+   return -1;
+}
+
+void release_locality(struct tpm_chip* tpm, int l, int force)
+{
+   if (locality_enabled(tpm, l) && (force || (ioread8(TPM_ACCESS(tpm, l)=
) &
+           (TPM_ACCESS_REQUEST_PENDING | TPM_ACCESS_VALID)) =3D=3D
+        (TPM_ACCESS_REQUEST_PENDING | TPM_ACCESS_VALID))) {
+      iowrite8(TPM_ACCESS(tpm, l), TPM_ACCESS_RELINQUISH_LOCALITY);
+   }
+}
+
+int tpm_tis_request_locality(struct tpm_chip* tpm, int l) {
+
+   s_time_t stop;
+   /*Make sure locality is valid */
+   if(!locality_enabled(tpm, l)) {
+      printk("tpm_tis_change_locality() Tried to change to locality %d,
but it is disabled or invalid!\n", l);
+      return -1;
+   }
+   /* Check if we already have the current locality */
+   if(check_locality(tpm, l) >=3D 0) {
+      return tpm->locality =3D l;
+   }
+   /* Set the new locality*/
+   iowrite8(TPM_ACCESS(tpm, l), TPM_ACCESS_REQUEST_USE);
+
+   if(tpm->irq) {
+      /* Wait for interrupt */
+      wait_event_deadline(tpm->int_queue, (check_locality(tpm, l) >=3D
0), NOW() + tpm->timeout_a);
+
+      /* FIXME: Handle timeout event, should return error in that case *=
/
+      return l;
+   } else {
+      /* Wait for burstcount */
+      stop =3D NOW() + tpm->timeout_a;
+      do {
+     if(check_locality(tpm, l) >=3D 0) {
+        return tpm->locality =3D l;
+     }
+     msleep(TPM_TIMEOUT);
+      } while(NOW() < stop);
+   }
+
+   printk("REQ LOCALITY FAILURE\n");
+   return -1;
+}
+
+static uint8_t tpm_tis_status(struct tpm_chip* tpm) {
+   return ioread8(TPM_STS(tpm, tpm->locality));
+}
+
+/* This causes the current command to be aborted */
+static void tpm_tis_ready(struct tpm_chip* tpm) {
+   iowrite8(TPM_STS(tpm, tpm->locality), TPM_STS_COMMAND_READY);
+}
+#define tpm_tis_cancel_cmd(v) tpm_tis_ready(v)
+
+static int get_burstcount(struct tpm_chip* tpm) {
+   s_time_t stop;
+   int burstcnt;
+
+   stop =3D NOW() + tpm->timeout_d;
+   do {
+      burstcnt =3D ioread8((TPM_STS(tpm, tpm->locality) + 1));
+      burstcnt +=3D ioread8(TPM_STS(tpm, tpm->locality) + 2) << 8;
+
+      if (burstcnt) {
+     return burstcnt;
+      }
+      msleep(TPM_TIMEOUT);
+   } while(NOW() < stop);
+   return -EBUSY;
+}
+
+static int wait_for_stat(struct tpm_chip* tpm, uint8_t mask,
+      unsigned long timeout, struct wait_queue_head* queue) {
+   s_time_t stop;
+   uint8_t status;
+
+   status =3D tpm_tis_status(tpm);
+   if((status & mask) =3D=3D mask) {
+      return 0;
+   }
+
+   if(tpm->irq) {
+      wait_event_deadline(*queue, ((tpm_tis_status(tpm) & mask) =3D=3D
mask), timeout);
+      /* FIXME: Check for timeout and return -ETIME */
+      return 0;
+   } else {
+      stop =3D NOW() + timeout;
+      do {
+     msleep(TPM_TIMEOUT);
+     status =3D tpm_tis_status(tpm);
+     if((status & mask) =3D=3D mask)
+        return 0;
+      } while( NOW() < stop);
+   }
+   return -ETIME;
+}
+
+static int recv_data(struct tpm_chip* tpm, uint8_t* buf, size_t count) {=

+   int size =3D 0;
+   int burstcnt;
+   while( size < count &&
+     wait_for_stat(tpm,
+        TPM_STS_DATA_AVAIL | TPM_STS_VALID,
+        tpm->timeout_c,
+        &tpm->read_queue)
+     =3D=3D 0) {
+      burstcnt =3D get_burstcount(tpm);
+      for(; burstcnt > 0 && size < count; --burstcnt)
+      {
+     buf[size++] =3D ioread8(TPM_DATA_FIFO(tpm, tpm->locality));
+      }
+   }
+   return size;
+}
+
+int tpm_tis_recv(struct tpm_chip* tpm, uint8_t* buf, size_t count) {
+   int size =3D 0;
+   int expected, status;
+
+   if (count < TPM_HEADER_SIZE) {
+      size =3D -EIO;
+      goto out;
+   }
+
+   /* read first 10 bytes, including tag, paramsize, and result */
+   if((size =3D
+        recv_data(tpm, buf, TPM_HEADER_SIZE)) < TPM_HEADER_SIZE) {
+      printk("Error reading tpm cmd header\n");
+      goto out;
+   }
+
+   expected =3D be32_to_cpu(*((uint32_t*)(buf + 2)));
+   if(expected > count) {
+      size =3D -EIO;
+      goto out;
+   }
+
+   if((size +=3D recv_data(tpm, & buf[TPM_HEADER_SIZE],
+           expected - TPM_HEADER_SIZE)) < expected) {
+      printk("Unable to read rest of tpm command size=3D%d
expected=3D%d\n", size, expected);
+      size =3D -ETIME;
+      goto out;
+   }
+
+   wait_for_stat(tpm, TPM_STS_VALID, tpm->timeout_c, &tpm->int_queue);
+   status =3D tpm_tis_status(tpm);
+   if(status & TPM_STS_DATA_AVAIL) {
+      printk("Error: left over data\n");
+      size =3D -EIO;
+      goto out;
+   }
+
+out:
+   tpm_tis_ready(tpm);
+   release_locality(tpm, tpm->locality, 0);
+   return size;
+}
+int tpm_tis_send(struct tpm_chip* tpm, uint8_t* buf, size_t len) {
+   int rc;
+   int status, burstcnt =3D 0;
+   int count =3D 0;
+   uint32_t ordinal;
+
+   if(tpm_tis_request_locality(tpm, tpm->locality) < 0) {
+      return -EBUSY;
+   }
+
+   status =3D tpm_tis_status(tpm);
+   if((status & TPM_STS_COMMAND_READY) =3D=3D 0) {
+      tpm_tis_ready(tpm);
+      if(wait_for_stat(tpm, TPM_STS_COMMAND_READY, tpm->timeout_b,
&tpm->int_queue) < 0) {
+     rc =3D -ETIME;
+     goto out_err;
+      }
+   }
+
+   while(count < len - 1) {
+      burstcnt =3D get_burstcount(tpm);
+      for(;burstcnt > 0 && count < len -1; --burstcnt) {
+     iowrite8(TPM_DATA_FIFO(tpm, tpm->locality), buf[count++]);
+      }
+
+      wait_for_stat(tpm, TPM_STS_VALID, tpm->timeout_c, &tpm->int_queue)=
;
+      status =3D tpm_tis_status(tpm);
+      if((status & TPM_STS_DATA_EXPECT) =3D=3D 0) {
+     rc =3D -EIO;
+     goto out_err;
+      }
+   }
+
+   /*Write last byte*/
+   iowrite8(TPM_DATA_FIFO(tpm, tpm->locality), buf[count]);
+   wait_for_stat(tpm, TPM_STS_VALID, tpm->timeout_c, &tpm->read_queue);
+   status =3D tpm_tis_status(tpm);
+   if((status & TPM_STS_DATA_EXPECT) !=3D 0) {
+      rc =3D -EIO;
+      goto out_err;
+   }
+
+   /*go and do it*/
+   iowrite8(TPM_STS(tpm, tpm->locality), TPM_STS_GO);
+
+   if(tpm->irq) {
+      /*Wait for interrupt */
+      ordinal =3D be32_to_cpu(*(buf + 6));
+      if(wait_for_stat(tpm,
+           TPM_STS_DATA_AVAIL | TPM_STS_VALID,
+           tpm_calc_ordinal_duration(tpm, ordinal),
+           &tpm->read_queue) < 0) {
+     rc =3D -ETIME;
+     goto out_err;
+      }
+   }
+#ifdef HAVE_LIBC
+   if(tpm->fd >=3D 0) {
+      files[tpm->fd].read =3D 0;
+      files[tpm->fd].tpm_tis.respgot =3D 0;
+      files[tpm->fd].tpm_tis.offset =3D 0;
+   }
+#endif
+   return len;
+
+out_err:
+   tpm_tis_ready(tpm);
+   release_locality(tpm, tpm->locality, 0);
+   return rc;
+}
+
+static void tpm_tis_irq_handler(evtchn_port_t port, struct pt_regs
*regs, void* data)
+{
+   struct tpm_chip* tpm =3D data;
+   uint32_t interrupt;
+   int i;
+
+   interrupt =3D ioread32(TPM_INT_STATUS(tpm, tpm->locality));
+   if(interrupt =3D=3D 0) {
+      return;
+   }
+
+   if(interrupt & TPM_INTF_DATA_AVAIL_INT) {
+      wake_up(&tpm->read_queue);
+   }
+   if(interrupt & TPM_INTF_LOCALITY_CHANGE_INT) {
+      for(i =3D 0; i < 5; ++i) {
+     if(check_locality(tpm, i) >=3D 0) {
+        break;
+     }
+      }
+   }
+   if(interrupt & (TPM_INTF_LOCALITY_CHANGE_INT | TPM_INTF_STS_VALID_INT=
 |
+        TPM_INTF_CMD_READY_INT)) {
+      wake_up(&tpm->int_queue);
+   }
+
+   /* Clear interrupts handled with TPM_EOI */
+   iowrite32(TPM_INT_STATUS(tpm, tpm->locality), interrupt);
+   ioread32(TPM_INT_STATUS(tpm, tpm->locality));
+   return;
+}
+
+/*
+ * Internal kernel interface to transmit TPM commands
+ */
+static ssize_t tpm_transmit(struct tpm_chip *chip, const uint8_t *buf,
+      size_t bufsiz)
+{
+   ssize_t rc;
+   uint32_t count, ordinal;
+   s_time_t stop;
+
+   count =3D be32_to_cpu(*((uint32_t *) (buf + 2)));
+   ordinal =3D be32_to_cpu(*((uint32_t *) (buf + 6)));
+   if (count =3D=3D 0)
+      return -ENODATA;
+   if (count > bufsiz) {
+      printk("Error: invalid count value %x %zx \n", count, bufsiz);
+      return -E2BIG;
+   }
+
+   //down(&chip->tpm_mutex);
+
+   if ((rc =3D tpm_tis_send(chip, (uint8_t *) buf, count)) < 0) {
+      printk("tpm_transmit: tpm_send: error %zd\n", rc);
+      goto out;
+   }
+
+   if (chip->irq)
+      goto out_recv;
+
+   stop =3D NOW() + tpm_calc_ordinal_duration(chip, ordinal);
+   do {
+      uint8_t status =3D tpm_tis_status(chip);
+      if ((status & (TPM_STS_DATA_AVAIL | TPM_STS_VALID)) =3D=3D
+        (TPM_STS_DATA_AVAIL | TPM_STS_VALID))
+     goto out_recv;
+
+      if ((status =3D=3D TPM_STS_COMMAND_READY)) {
+     printk("TPM Error: Operation Canceled\n");
+     rc =3D -ECANCELED;
+     goto out;
+      }
+
+      msleep(TPM_TIMEOUT);    /* CHECK */
+      rmb();
+   } while (NOW() < stop);
+
+   /* Cancel the command */
+   tpm_tis_cancel_cmd(chip);
+   printk("TPM Operation Timed out\n");
+   rc =3D -ETIME;
+   goto out;
+
+out_recv:
+   if((rc =3D tpm_tis_recv(chip, (uint8_t *) buf, bufsiz)) < 0) {
+      printk("tpm_transmit: tpm_recv: error %d\n", rc);
+   }
+out:
+   //up(&chip->tpm_mutex);
+   return rc;
+}
+
+static ssize_t transmit_cmd(struct tpm_chip *chip, struct tpm_cmd_t *cmd=
,
+                            int len, const char *desc)
+{
+        int err;
+
+        len =3D tpm_transmit(chip,(uint8_t *) cmd, len);
+        if (len <  0)
+                return len;
+        if (len =3D=3D TPM_ERROR_SIZE) {
+                err =3D be32_to_cpu(cmd->header.out.return_code);
+                printk("A TPM error (%d) occurred %s\n", err, desc);
+                return err;
+        }
+        return 0;
+}
+
+void tpm_get_timeouts(struct tpm_chip *chip)
+{
+   struct tpm_cmd_t tpm_cmd;
+   struct timeout_t *timeout_cap;
+   struct duration_t *duration_cap;
+   ssize_t rc;
+   uint32_t timeout;
+
+   tpm_cmd.header.in =3D tpm_getcap_header;
+   tpm_cmd.params.getcap_in.cap =3D TPM_CAP_PROP;
+   tpm_cmd.params.getcap_in.subcap_size =3D cpu_to_be32(4);
+   tpm_cmd.params.getcap_in.subcap =3D TPM_CAP_PROP_TIS_TIMEOUT;
+
+   if((rc =3D transmit_cmd(chip, &tpm_cmd, TPM_INTERNAL_RESULT_SIZE,
+     "attempting to determine the timeouts")) !=3D 0) {
+      printk("transmit failed %d\n", rc);
+      goto duration;
+   }
+
+   if (be32_to_cpu(tpm_cmd.params.getcap_out.cap_size)
+     !=3D 4 * sizeof(uint32_t)) {
+      printk("Out len check failure %lu \n",
be32_to_cpu(tpm_cmd.header.out.length));
+      goto duration;
+   }
+
+   timeout_cap =3D &tpm_cmd.params.getcap_out.cap.timeout;
+   /* Don't overwrite default if value is 0 */
+   timeout =3D be32_to_cpu(timeout_cap->a);
+   if (timeout)
+      chip->timeout_a =3D MICROSECS(timeout); /*Convert to msec */
+   timeout =3D be32_to_cpu(timeout_cap->b);
+   if (timeout)
+      chip->timeout_b =3D MICROSECS(timeout); /*Convert to msec */
+   timeout =3D be32_to_cpu(timeout_cap->c);
+   if (timeout)
+      chip->timeout_c =3D MICROSECS(timeout); /*Convert to msec */
+   timeout =3D be32_to_cpu(timeout_cap->d);
+   if (timeout)
+      chip->timeout_d =3D MICROSECS(timeout); /*Convert to msec */
+
+duration:
+   tpm_cmd.header.in =3D tpm_getcap_header;
+   tpm_cmd.params.getcap_in.cap =3D TPM_CAP_PROP;
+   tpm_cmd.params.getcap_in.subcap_size =3D cpu_to_be32(4);
+   tpm_cmd.params.getcap_in.subcap =3D TPM_CAP_PROP_TIS_DURATION;
+
+   if((rc =3D transmit_cmd(chip, &tpm_cmd, TPM_INTERNAL_RESULT_SIZE,
+     "attempting to determine the durations")) < 0) {
+      return;
+   }
+
+   if (be32_to_cpu(tpm_cmd.params.getcap_out.cap_size)
+     !=3D 3 * sizeof(uint32_t)) {
+      return;
+   }
+        duration_cap =3D &tpm_cmd.params.getcap_out.cap.duration;
+        chip->duration[TPM_SHORT] =3D be32_to_cpu(duration_cap->tpm_shor=
t);
+        /* The Broadcom BCM0102 chipset in a Dell Latitude D820 gets
the above
+         * value wrong and apparently reports msecs rather than usecs.
So we
+         * fix up the resulting too-small TPM_SHORT value to make
things work.
+         */
+        if (chip->duration[TPM_SHORT] < 10) {
+       chip->duration[TPM_SHORT] =3D MILLISECS(chip->duration[TPM_SHORT]=
);
+    } else {
+       chip->duration[TPM_SHORT] =3D MICROSECS(chip->duration[TPM_SHORT]=
);
+    }
+
+        chip->duration[TPM_MEDIUM] =3D
MICROSECS(be32_to_cpu(duration_cap->tpm_medium));
+        chip->duration[TPM_LONG] =3D
MICROSECS(be32_to_cpu(duration_cap->tpm_long));
+}
+
+
+
+void tpm_continue_selftest(struct tpm_chip* chip) {
+   uint8_t data[] =3D {
+      0, 193,                 /* TPM_TAG_RQU_COMMAND */
+      0, 0, 0, 10,            /* length */
+      0, 0, 0, 83,            /* TPM_ORD_GetCapability */
+   };
+
+   tpm_transmit(chip, data, sizeof(data));
+}
+
+ssize_t tpm_getcap(struct tpm_chip *chip, uint32_t subcap_id, cap_t *cap=
,
+                   const char *desc)
+{
+        struct tpm_cmd_t tpm_cmd;
+        int rc;
+
+        tpm_cmd.header.in =3D tpm_getcap_header;
+        if (subcap_id =3D=3D CAP_VERSION_1_1 || subcap_id =3D=3D CAP_VER=
SION_1_2) {
+                tpm_cmd.params.getcap_in.cap =3D subcap_id;
+                /*subcap field not necessary */
+                tpm_cmd.params.getcap_in.subcap_size =3D cpu_to_be32(0);=

+                tpm_cmd.header.in.length -=3D cpu_to_be32(sizeof(uint32_=
t));
+        } else {
+                if (subcap_id =3D=3D TPM_CAP_FLAG_PERM ||
+                    subcap_id =3D=3D TPM_CAP_FLAG_VOL)
+                        tpm_cmd.params.getcap_in.cap =3D TPM_CAP_FLAG;
+                else
+                        tpm_cmd.params.getcap_in.cap =3D TPM_CAP_PROP;
+                tpm_cmd.params.getcap_in.subcap_size =3D cpu_to_be32(4);=

+                tpm_cmd.params.getcap_in.subcap =3D subcap_id;
+        }
+        rc =3D transmit_cmd(chip, &tpm_cmd, TPM_INTERNAL_RESULT_SIZE, de=
sc);
+        if (!rc)
+                *cap =3D tpm_cmd.params.getcap_out.cap;
+        return rc;
+}
+
+
+struct tpm_chip* init_tpm_tis(unsigned long baseaddr, int localities,
unsigned int irq)
+{
+   int i;
+   unsigned long addr;
+   struct tpm_chip* tpm =3D NULL;
+   uint32_t didvid;
+   uint32_t intfcaps;
+   uint32_t intmask;
+
+   printk("=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Init TPM TIS Driver =3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D\n");
+
+   /*Sanity check the localities input */
+   if(localities & ~TPM_TIS_EN_LOCLALL) {
+      printk("init_tpm_tis() Invalid locality specification! %X\n",
localities);
+      goto abort_egress;
+   }
+
+   printk("IOMEM Machine Base Address: %lX\n", baseaddr);
+
+   /* Create the tpm data structure */
+   tpm =3D malloc(sizeof(struct tpm_chip));
+   __init_tpm_chip(tpm);
+
+   /* Set the enabled localities - if 0 we leave default as all enabled =
*/
+   if(localities !=3D 0) {
+      tpm->enabled_localities =3D localities;
+   }
+   printk("Enabled Localities: ");
+   for(i =3D 0; i < 5; ++i) {
+      if(locality_enabled(tpm, i)) {
+     printk("%d ", i);
+      }
+   }
+   printk("\n");
+
+   /* Set the base machine address */
+   tpm->baseaddr =3D baseaddr;
+
+   /* Set default timeouts */
+   tpm->timeout_a =3D MILLISECS(TIS_SHORT_TIMEOUT);
+   tpm->timeout_b =3D MILLISECS(TIS_LONG_TIMEOUT);
+   tpm->timeout_c =3D MILLISECS(TIS_SHORT_TIMEOUT);
+   tpm->timeout_d =3D MILLISECS(TIS_SHORT_TIMEOUT);
+
+   /*Map the mmio pages */
+   addr =3D tpm->baseaddr;
+   for(i =3D 0; i < 5; ++i) {
+      if(locality_enabled(tpm, i)) {
+     /* Map the page in now */
+     if((tpm->pages[i] =3D ioremap_nocache(addr, PAGE_SIZE)) =3D=3D NULL=
) {
+        printk("Unable to map iomem page a address %p\n", addr);
+        goto abort_egress;
+     }
+
+     /* Set default locality to the first enabled one */
+     if (tpm->locality < 0) {
+        if(tpm_tis_request_locality(tpm, i) < 0) {
+           printk("Unable to request locality %d??\n", i);
+           goto abort_egress;
+        }
+     }
+      }
+      addr +=3D PAGE_SIZE;
+   }
+
+
+   /* Get the vendor and device ids */
+   didvid =3D ioread32(TPM_DID_VID(tpm, tpm->locality));
+   tpm->did =3D didvid >> 16;
+   tpm->vid =3D didvid & 0xFFFF;
+
+
+   /* Get the revision id */
+   tpm->rid =3D ioread8(TPM_RID(tpm, tpm->locality));
+
+   printk("1.2 TPM (device-id=3D0x%X vendor-id =3D %X rev-id =3D %X)\n",=

tpm->did, tpm->vid, tpm->rid);
+
+   intfcaps =3D ioread32(TPM_INTF_CAPS(tpm, tpm->locality));
+   printk("TPM interface capabilities (0x%x):\n", intfcaps);
+   if (intfcaps & TPM_INTF_BURST_COUNT_STATIC)
+      printk("\tBurst Count Static\n");
+   if (intfcaps & TPM_INTF_CMD_READY_INT)
+      printk("\tCommand Ready Int Support\n");
+   if (intfcaps & TPM_INTF_INT_EDGE_FALLING)
+      printk("\tInterrupt Edge Falling\n");
+   if (intfcaps & TPM_INTF_INT_EDGE_RISING)
+      printk("\tInterrupt Edge Rising\n");
+   if (intfcaps & TPM_INTF_INT_LEVEL_LOW)
+      printk("\tInterrupt Level Low\n");
+   if (intfcaps & TPM_INTF_INT_LEVEL_HIGH)
+      printk("\tInterrupt Level High\n");
+   if (intfcaps & TPM_INTF_LOCALITY_CHANGE_INT)
+      printk("\tLocality Change Int Support\n");
+   if (intfcaps & TPM_INTF_STS_VALID_INT)
+      printk("\tSts Valid Int Support\n");
+   if (intfcaps & TPM_INTF_DATA_AVAIL_INT)
+      printk("\tData Avail Int Support\n");
+
+   /*Interupt setup */
+   intmask =3D ioread32(TPM_INT_ENABLE(tpm, tpm->locality));
+
+   intmask |=3D TPM_INTF_CMD_READY_INT
+      | TPM_INTF_LOCALITY_CHANGE_INT | TPM_INTF_DATA_AVAIL_INT
+      | TPM_INTF_STS_VALID_INT;
+
+   iowrite32(TPM_INT_ENABLE(tpm, tpm->locality), intmask);
+
+   /*If interupts are enabled, handle it */
+   if(irq) {
+      if(irq !=3D TPM_PROBE_IRQ) {
+     tpm->irq =3D irq;
+      } else {
+     /*FIXME add irq probing feature later */
+     printk("IRQ probing not implemented\n");
+      }
+   }
+
+   if(tpm->irq) {
+      iowrite8(TPM_INT_VECTOR(tpm, tpm->locality), tpm->irq);
+
+      if(bind_pirq(tpm->irq, 1, tpm_tis_irq_handler, tpm) !=3D 0) {
+     printk("Unabled to request irq: %u for use\n", tpm->irq);
+     printk("Will use polling mode\n");
+     tpm->irq =3D 0;
+      } else {
+     /* Clear all existing */
+     iowrite32(TPM_INT_STATUS(tpm, tpm->locality),
ioread32(TPM_INT_STATUS(tpm, tpm->locality)));
+
+     /* Turn on interrupts */
+     iowrite32(TPM_INT_ENABLE(tpm, tpm->locality), intmask |
TPM_GLOBAL_INT_ENABLE);
+      }
+   }
+
+   tpm_get_timeouts(tpm);
+   tpm_continue_selftest(tpm);
+
+
+   return tpm;
+abort_egress:
+   if(tpm !=3D NULL) {
+      shutdown_tpm_tis(tpm);
+   }
+   return NULL;
+}
+
+void shutdown_tpm_tis(struct tpm_chip* tpm){
+   int i;
+
+   printk("Shutting down tpm_tis device\n");
+
+   iowrite32(TPM_INT_ENABLE(tpm, tpm->locality), ~TPM_GLOBAL_INT_ENABLE)=
;
+
+   /*Unmap all of the mmio pages */
+   for(i =3D 0; i < 5; ++i) {
+      if(tpm->pages[i] !=3D NULL) {
+     iounmap(tpm->pages[i], PAGE_SIZE);
+     tpm->pages[i] =3D NULL;
+      }
+   }
+   free(tpm);
+   return;
+}
+
+
+int tpm_tis_cmd(struct tpm_chip* tpm, uint8_t* req, size_t reqlen,
uint8_t** resp, size_t* resplen)
+{
+   if(tpm->locality < 0) {
+      printk("tpm_tis_cmd() failed! locality not set!\n");
+      return -1;
+   }
+   if(reqlen > TPM_BUFSIZE) {
+      reqlen =3D TPM_BUFSIZE;
+   }
+   memcpy(tpm->data_buffer, req, reqlen);
+   *resplen =3D tpm_transmit(tpm, tpm->data_buffer, TPM_BUFSIZE);
+
+   *resp =3D malloc(*resplen);
+   memcpy(*resp, tpm->data_buffer, *resplen);
+   return 0;
+}
+
+#ifdef HAVE_LIBC
+int tpm_tis_open(struct tpm_chip* tpm)
+{
+   /* Silently prevent multiple opens */
+   if(tpm->fd !=3D -1) {
+      return tpm->fd;
+   }
+
+   tpm->fd =3D alloc_fd(FTYPE_TPM_TIS);
+   printk("tpm_tis_open() -> %d\n", tpm->fd);
+   files[tpm->fd].tpm_tis.dev =3D tpm;
+   files[tpm->fd].tpm_tis.offset =3D 0;
+   files[tpm->fd].tpm_tis.respgot =3D 0;
+   return tpm->fd;
+}
+
+int tpm_tis_posix_write(int fd, const uint8_t* buf, size_t count)
+{
+   struct tpm_chip* tpm;
+   tpm =3D files[fd].tpm_tis.dev;
+
+   if(tpm->locality < 0) {
+      printk("tpm_tis_posix_write() failed! locality not set!\n");
+      errno =3D EINPROGRESS;
+      return -1;
+   }
+   if(count =3D=3D 0) {
+      return 0;
+   }
+
+   /* Return an error if we are already processing a command */
+   if(count > TPM_BUFSIZE) {
+      count =3D TPM_BUFSIZE;
+   }
+   /* Send the command now */
+   memcpy(tpm->data_buffer, buf, count);
+   if((tpm->data_len =3D tpm_transmit(tpm, tpm->data_buffer,
TPM_BUFSIZE)) < 0) {
+      errno =3D EIO;
+      return -1;
+   }
+   return count;
+}
+
+int tpm_tis_posix_read(int fd, uint8_t* buf, size_t count)
+{
+   int rc;
+   struct tpm_chip* tpm;
+   tpm =3D files[fd].tpm_tis.dev;
+
+   if(count =3D=3D 0) {
+      return 0;
+   }
+
+   /* If there is no tpm resp to read, return EIO */
+   if(tpm->data_len < 0) {
+      errno =3D EIO;
+      return -1;
+   }
+
+
+   /* Handle EOF case */
+   if(files[fd].tpm_tis.offset >=3D tpm->data_len) {
+      rc =3D 0;
+   } else {
+      rc =3D min(tpm->data_len - files[fd].tpm_tis.offset, count);
+      memcpy(buf, tpm->data_buffer + files[fd].tpm_tis.offset, rc);
+   }
+   files[fd].tpm_tis.offset +=3D rc;
+   /* Reset the data pending flag */
+   return rc;
+}
+int tpm_tis_posix_fstat(int fd, struct stat* buf)
+{
+   struct tpm_chip* tpm;
+   tpm =3D files[fd].tpm_tis.dev;
+
+   buf->st_mode =3D O_RDWR;
+   buf->st_uid =3D 0;
+   buf->st_gid =3D 0;
+   buf->st_size =3D be32_to_cpu(*((uint32_t*)(tpm->data_buffer + 2)));
+   buf->st_atime =3D buf->st_mtime =3D buf->st_ctime =3D time(NULL);
+   return 0;
+}
+
+
+#endif
diff --git a/extras/mini-os/tpmback.c b/extras/mini-os/tpmback.c
--- /dev/null
+++ b/extras/mini-os/tpmback.c
@@ -0,0 +1,1114 @@
+/*
+ * Copyright (c) 2010-2012 United States Government, as represented by
+ * the Secretary of Defense.  All rights reserved.
+ *
+ * This driver 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 3 of the License, or
+ * (at your option) any later version.
+ *
+ * This driver is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program.  If not, see <http://www.gnu.org/licenses/>.=

+ *
+ * Based upon the files:
+ *  drivers/xen/tpmbk.c
+ * from the Linux kernel, which are Copyright (C) 2006 IBM Corporation
+ */
+#include <mini-os/os.h>
+#include <mini-os/xenbus.h>
+#include <mini-os/events.h>
+#include <errno.h>
+#include <mini-os/gnttab.h>
+#include <xen/io/xenbus.h>
+#include <xen/io/tpmif.h>
+#include <xen/io/protocols.h>
+#include <mini-os/xmalloc.h>
+#include <time.h>
+#include <mini-os/tpmback.h>
+#include <mini-os/lib.h>
+#include <fcntl.h>
+#include <mini-os/mm.h>
+#include <mini-os/posix/sys/mman.h>
+#include <mini-os/semaphore.h>
+#include <mini-os/wait.h>
+
+
+#ifndef HAVE_LIBC
+#define strtoul simple_strtoul
+#endif
+
+//#define TPMBACK_PRINT_DEBUG
+#ifdef TPMBACK_PRINT_DEBUG
+#define TPMBACK_DEBUG(fmt,...) printk("Tpmback:Debug("__FILE__":%d) "
fmt, __LINE__, ##__VA_ARGS__)
+#define TPMBACK_DEBUG_MORE(fmt,...) printk(fmt, ##__VA_ARGS__)
+#else
+#define TPMBACK_DEBUG(fmt,...)
+#endif
+#define TPMBACK_ERR(fmt,...) printk("Tpmback:Error " fmt, ##__VA_ARGS__)=

+#define TPMBACK_LOG(fmt,...) printk("Tpmback:Info " fmt, ##__VA_ARGS__)
+
+#define min(a,b) (((a) < (b)) ? (a) : (b))
+
+/* Default size of the tpmif array at initialization */
+#define DEF_ARRAY_SIZE 1
+
+/* tpmif and tpmdev flags */
+#define TPMIF_CLOSED 1
+#define TPMIF_REQ_READY 2
+
+struct tpmif {
+   domid_t domid;
+   unsigned int handle;
+
+   char* fe_path;
+   char* fe_state_path;
+
+   /* Locally bound event channel*/
+   evtchn_port_t evtchn;
+
+   /* Shared page */
+   tpmif_tx_interface_t* tx;
+
+   /* pointer to TPMIF_RX_RING_SIZE pages */
+   void** pages;
+
+   enum xenbus_state state;
+   enum { DISCONNECTED, DISCONNECTING, CONNECTED } status;
+
+   char* uuid;
+
+   /* state flags */
+   int flags;
+};
+typedef struct tpmif tpmif_t;
+
+struct tpmback_dev {
+
+   tpmif_t** tpmlist;
+   unsigned long num_tpms;
+   unsigned long num_alloc;
+
+   struct gntmap map;
+
+   /* True if at least one tpmif has a request to be handled */
+   int flags;
+
+   /* exclusive domains, see init_tpmback comment in tpmback.h */
+   char** exclusive_uuids;
+
+   xenbus_event_queue events;
+
+   /* Callbacks */
+   void (*open_callback)(domid_t, unsigned int);
+   void (*close_callback)(domid_t, unsigned int);
+   void (*suspend_callback)(domid_t, unsigned int);
+   void (*resume_callback)(domid_t, unsigned int);
+};
+typedef struct tpmback_dev tpmback_dev_t;
+
+enum { EV_NONE, EV_NEWFE, EV_STCHNG } tpm_ev_enum;
+
+/* Global objects */
+static struct thread* eventthread =3D NULL;
+static tpmback_dev_t gtpmdev =3D {
+   .tpmlist =3D NULL,
+   .num_tpms =3D 0,
+   .num_alloc =3D 0,
+   .flags =3D TPMIF_CLOSED,
+   .events =3D NULL,
+   .open_callback =3D NULL,
+   .close_callback =3D NULL,
+   .suspend_callback =3D NULL,
+   .resume_callback =3D NULL,
+};
+struct wait_queue_head waitq;
+int globalinit =3D 0;
+
+/************************************
+ * TPMIF SORTED ARRAY FUNCTIONS
+ * tpmback_dev_t.tpmlist is a sorted array, sorted by domid and then
handle number
+ * Duplicates are not allowed
+ * **********************************/
+
+inline void tpmif_req_ready(tpmif_t* tpmif) {
+   tpmif->flags |=3D TPMIF_REQ_READY;
+   gtpmdev.flags |=3D TPMIF_REQ_READY;
+}
+
+inline void tpmdev_check_req(void) {
+   int i;
+   int flags;
+   local_irq_save(flags);
+   for(i =3D 0; i < gtpmdev.num_tpms; ++i) {
+      if(gtpmdev.tpmlist[i]->flags & TPMIF_REQ_READY) {
+     gtpmdev.flags |=3D TPMIF_REQ_READY;
+     local_irq_restore(flags);
+     return;
+      }
+   }
+   gtpmdev.flags &=3D ~TPMIF_REQ_READY;
+   local_irq_restore(flags);
+}
+
+inline void tpmif_req_finished(tpmif_t* tpmif) {
+   tpmif->flags &=3D ~TPMIF_REQ_READY;
+   tpmdev_check_req();
+}
+
+int __get_tpmif_index(int st, int n, domid_t domid, unsigned int handle)=

+{
+   int i =3D st + n /2;
+   tpmif_t* tmp;
+
+   if( n <=3D 0 )
+      return -1;
+
+   tmp =3D gtpmdev.tpmlist[i];
+   if(domid =3D=3D tmp->domid && tmp->handle =3D=3D handle) {
+      return i;
+   } else if ( (domid < tmp->domid) ||
+     (domid =3D=3D tmp->domid && handle < tmp->handle)) {
+      return __get_tpmif_index(st, n/2, domid, handle);
+   } else {
+      return __get_tpmif_index(i + 1, n/2 - ((n +1) % 2), domid, handle)=
;
+   }
+}
+
+/* Returns the array index of the tpmif domid/handle. Returns -1 if no
such tpmif exists */
+int get_tpmif_index(domid_t domid, unsigned int handle)
+{
+   int flags;
+   int index;
+   local_irq_save(flags);
+   index =3D __get_tpmif_index(0, gtpmdev.num_tpms, domid, handle);
+   local_irq_restore(flags);
+   return index;
+}
+
+/* Returns the tpmif domid/handle or NULL if none exists */
+tpmif_t* get_tpmif(domid_t domid, unsigned int handle)
+{
+   int flags;
+   int i;
+   tpmif_t* ret;
+   local_irq_save(flags);
+   i =3D get_tpmif_index(domid, handle);
+   if (i < 0) {
+      ret =3D NULL;
+   } else {
+      ret =3D gtpmdev.tpmlist[i];
+   }
+   local_irq_restore(flags);
+   return ret;
+}
+
+/* Remove the given tpmif. Returns 0 if it was removed, -1 if it was
not removed */
+int remove_tpmif(tpmif_t* tpmif)
+{
+   int i, j;
+   char* err;
+   int flags;
+   local_irq_save(flags);
+
+   /* Find the index in the array if it exists */
+   i =3D get_tpmif_index(tpmif->domid, tpmif->handle);
+   if (i < 0) {
+      goto error;
+   }
+
+   /* Remove the interface from the list */
+   for(j =3D i; j < gtpmdev.num_tpms - 1; ++j) {
+      gtpmdev.tpmlist[j] =3D gtpmdev.tpmlist[j+1];
+   }
+   gtpmdev.tpmlist[j] =3D NULL;
+   --gtpmdev.num_tpms;
+
+   /* If removed tpm was the only ready tpm, then we need to check and
turn off the ready flag */
+   tpmdev_check_req();
+
+   local_irq_restore(flags);
+
+   /* Stop listening for events on this tpm interface */
+   if((err =3D xenbus_unwatch_path_token(XBT_NIL, tpmif->fe_state_path,
tpmif->fe_state_path))) {
+      TPMBACK_ERR("Unable to unwatch path token `%s' Error was %s
Ignoring..\n", tpmif->fe_state_path, err);
+      free(err);
+   }
+
+   return 0;
+error:
+   local_irq_restore(flags);
+   return -1;
+}
+
+/* Insert tpmif into dev->tpmlist. Returns 0 on success and non zero on
error.
+ * It is an error to insert a tpmif with the same domid and handle
+ * number
+ * as something already in the list */
+int insert_tpmif(tpmif_t* tpmif)
+{
+   int flags;
+   unsigned int i, j;
+   tpmif_t* tmp;
+   char* err;
+
+   local_irq_save(flags);
+
+   /*Check if we need to allocate more space */
+   if (gtpmdev.num_tpms =3D=3D gtpmdev.num_alloc) {
+      gtpmdev.num_alloc *=3D 2;
+      gtpmdev.tpmlist =3D realloc(gtpmdev.tpmlist, gtpmdev.num_alloc);
+   }
+
+   /*Find where to put the new interface */
+   for(i =3D 0; i < gtpmdev.num_tpms; ++i)
+   {
+      tmp =3D gtpmdev.tpmlist[i];
+      if(tpmif->domid =3D=3D tmp->domid && tpmif->handle =3D=3D tmp->han=
dle) {
+     TPMBACK_ERR("Tried to insert duplicate tpm interface %u/%u\n",
(unsigned int) tpmif->domid, tpmif->handle);
+     goto error;
+      }
+      if((tpmif->domid < tmp->domid) ||
+        (tpmif->domid =3D=3D tmp->domid && tpmif->handle < tmp->handle))=
 {
+     break;
+      }
+   }
+
+   /*Shift all the tpm pointers past i down one */
+   for(j =3D gtpmdev.num_tpms; j > i; --j) {
+      gtpmdev.tpmlist[j] =3D gtpmdev.tpmlist[j-1];
+   }
+
+   /*Add the new interface */
+   gtpmdev.tpmlist[i] =3D tpmif;
+   ++gtpmdev.num_tpms;
+
+   /*Should not be needed, anything inserted with ready flag is
probably an error */
+   tpmdev_check_req();
+
+   local_irq_restore(flags);
+
+   /*Listen for state changes on the new interface */
+   if((err =3D xenbus_watch_path_token(XBT_NIL, tpmif->fe_state_path,
tpmif->fe_state_path, &gtpmdev.events)))
+   {
+      /* if we got an error here we should carefully remove the
interface and then return */
+      TPMBACK_ERR("Unable to watch path token `%s' Error was %s\n",
tpmif->fe_state_path, err);
+      free(err);
+      remove_tpmif(tpmif);
+      goto error_post_irq;
+   }
+
+   return 0;
+error:
+   local_irq_restore(flags);
+error_post_irq:
+   return -1;
+}
+
+
+/*****************
+ * CHANGE BACKEND STATE
+ * *****************/
+/*Attempts to change the backend state in xenstore
+ * returns 0 on success and non-zero on error */
+int tpmif_change_state(tpmif_t* tpmif, enum xenbus_state state)
+{
+   char path[512];
+   char *value;
+   char *err;
+   enum xenbus_state readst;
+   TPMBACK_DEBUG("Backend state change %u/%u from=3D%d to=3D%d\n",
(unsigned int) tpmif->domid, tpmif->handle, tpmif->state, state);
+   if (tpmif->state =3D=3D state)
+      return 0;
+
+   snprintf(path, 512, "backend/vtpm/%u/%u/state", (unsigned int)
tpmif->domid, tpmif->handle);
+
+   if((err =3D xenbus_read(XBT_NIL, path, &value))) {
+      TPMBACK_ERR("Unable to read backend state %s, error was %s\n",
path, err);
+      free(err);
+      return -1;
+   }
+   if(sscanf(value, "%d", &readst) !=3D 1) {
+      TPMBACK_ERR("Non integer value (%s) in %s ??\n", value, path);
+      free(value);
+      return -1;
+   }
+   free(value);
+
+   /* It's possible that the backend state got updated by hotplug or
something else behind our back */
+   if(readst !=3D tpmif->state) {
+      TPMBACK_DEBUG("tpm interface state was %d but xenstore state was
%d!\n", tpmif->state, readst);
+      tpmif->state =3D readst;
+   }
+
+   /*If if the state isnt changing, then we dont update xenstore b/c we
dont want to fire extraneous events */
+   if(tpmif->state =3D=3D state) {
+      return 0;
+   }
+
+   /*update xenstore*/
+   snprintf(path, 512, "backend/vtpm/%u/%u", (unsigned int)
tpmif->domid, tpmif->handle);
+   if((err =3D xenbus_printf(XBT_NIL, path, "state", "%u", state))) {
+      TPMBACK_ERR("Error writing to xenstore %s, error was %s new
state=3D%d\n", path, err, state);
+      free(err);
+      return -1;
+   }
+
+   tpmif->state =3D state;
+
+   return 0;
+}
+/**********************************
+ * TPMIF CREATION AND DELETION
+ * *******************************/
+inline tpmif_t* __init_tpmif(domid_t domid, unsigned int handle)
+{
+   tpmif_t* tpmif;
+   tpmif =3D malloc(sizeof(*tpmif));
+   tpmif->domid =3D domid;
+   tpmif->handle =3D handle;
+   tpmif->fe_path =3D NULL;
+   tpmif->fe_state_path =3D NULL;
+   tpmif->state =3D XenbusStateInitialising;
+   tpmif->status =3D DISCONNECTED;
+   tpmif->tx =3D NULL;
+   tpmif->pages =3D NULL;
+   tpmif->flags =3D 0;
+   tpmif->uuid =3D NULL;
+   return tpmif;
+}
+
+void __free_tpmif(tpmif_t* tpmif)
+{
+   if(tpmif->pages) {
+      free(tpmif->pages);
+   }
+   if(tpmif->fe_path) {
+      free(tpmif->fe_path);
+   }
+   if(tpmif->fe_state_path) {
+      free(tpmif->fe_state_path);
+   }
+   if(tpmif->uuid) {
+      free(tpmif->uuid);
+   }
+   free(tpmif);
+}
+/* Creates a new tpm interface, adds it to the sorted array and returns =
it.
+ * returns NULL on error
+ * If the tpm interface already exists, it is returned*/
+tpmif_t* new_tpmif(domid_t domid, unsigned int handle)
+{
+   tpmif_t* tpmif;
+   char* err;
+   char path[512];
+
+   /* Make sure we haven't already created this tpm
+    * Double events can occur */
+   if((tpmif =3D get_tpmif(domid, handle)) !=3D NULL) {
+      return tpmif;
+   }
+
+   tpmif =3D __init_tpmif(domid, handle);
+
+   /* Get the uuid from xenstore */
+   snprintf(path, 512, "backend/vtpm/%u/%u/uuid", (unsigned int) domid,
handle);
+   if((err =3D xenbus_read(XBT_NIL, path, &tpmif->uuid))) {
+      TPMBACK_ERR("Error reading %s, Error =3D %s\n", path, err);
+      free(err);
+      goto error;
+   }
+
+   /* Do the exclusive uuid check now */
+   if(gtpmdev.exclusive_uuids !=3D NULL) {
+      char** ptr;
+
+      /* Check that its in the whitelist */
+      for(ptr =3D gtpmdev.exclusive_uuids; *ptr !=3D NULL; ++ptr) {
+     if(!strcmp(tpmif->uuid, *ptr)) {
+        break;
+     }
+      }
+      /* If *ptr =3D=3D NULL then we went through the whole list without=
 a
match, so close the connection */
+      if(*ptr =3D=3D NULL) {
+     tpmif_change_state(tpmif, XenbusStateClosed);
+     TPMBACK_ERR("Frontend %u/%u tried to connect with invalid
uuid=3D%s\n", (unsigned int) domid, handle, tpmif->uuid);
+     goto error;
+      }
+   }
+
+   /* allocate pages to be used for shared mapping */
+   if((tpmif->pages =3D malloc(sizeof(void*) * TPMIF_TX_RING_SIZE)) =3D=3D=

NULL) {
+      goto error;
+   }
+   memset(tpmif->pages, 0, sizeof(void*) * TPMIF_TX_RING_SIZE);
+
+   if(tpmif_change_state(tpmif, XenbusStateInitWait)) {
+      goto error;
+   }
+
+   snprintf(path, 512, "backend/vtpm/%u/%u/frontend", (unsigned int)
domid, handle);
+   if((err =3D xenbus_read(XBT_NIL, path, &tpmif->fe_path))) {
+      TPMBACK_ERR("Error creating new tpm instance xenbus_read(%s),
Error =3D %s", path, err);
+      free(err);
+      goto error;
+   }
+
+   /*Set the state path */
+   tpmif->fe_state_path =3D malloc(strlen(tpmif->fe_path) + 7);
+   strcpy(tpmif->fe_state_path, tpmif->fe_path);
+   strcat(tpmif->fe_state_path, "/state");
+
+   if(insert_tpmif(tpmif)) {
+      goto error;
+   }
+   TPMBACK_DEBUG("New tpmif %u/%u\n", (unsigned int) tpmif->domid,
tpmif->handle);
+   /* Do the callback now */
+   if(gtpmdev.open_callback) {
+      gtpmdev.open_callback(tpmif->domid, tpmif->handle);
+   }
+   return tpmif;
+error:
+   __free_tpmif(tpmif);
+   return NULL;
+
+}
+
+/* Removes tpmif from dev->tpmlist and frees it's memory usage */
+void free_tpmif(tpmif_t* tpmif)
+{
+   char* err;
+   char path[512];
+   TPMBACK_DEBUG("Free tpmif %u/%u\n", (unsigned int) tpmif->domid,
tpmif->handle);
+   if(tpmif->flags & TPMIF_CLOSED) {
+      TPMBACK_ERR("Tried to free an instance twice! Theres a bug
somewhere!\n");
+      BUG();
+   }
+   tpmif->flags =3D TPMIF_CLOSED;
+
+   tpmif_change_state(tpmif, XenbusStateClosing);
+
+   /* Unmap share page and unbind event channel */
+   if(tpmif->status =3D=3D CONNECTED) {
+      tpmif->status =3D DISCONNECTING;
+      mask_evtchn(tpmif->evtchn);
+
+      if(gntmap_munmap(&gtpmdev.map, (unsigned long)tpmif->tx, 1)) {
+     TPMBACK_ERR("%u/%u Error occured while trying to unmap shared
page\n", (unsigned int) tpmif->domid, tpmif->handle);
+      }
+
+      unbind_evtchn(tpmif->evtchn);
+   }
+   tpmif->status =3D DISCONNECTED;
+   tpmif_change_state(tpmif, XenbusStateClosed);
+
+   /* Do the callback now */
+   if(gtpmdev.close_callback) {
+      gtpmdev.close_callback(tpmif->domid, tpmif->handle);
+   }
+
+   /* remove from array */
+   remove_tpmif(tpmif);
+
+   /* Wake up anyone possibly waiting on this interface and let them
exit */
+   wake_up(&waitq);
+   schedule();
+
+   /* Remove the old xenbus entries */
+   snprintf(path, 512, "backend/vtpm/%u/%u", (unsigned int)
tpmif->domid, tpmif->handle);
+   if((err =3D xenbus_rm(XBT_NIL, path))) {
+      TPMBACK_ERR("Error cleaning up xenbus entries path=3D%s
error=3D%s\n", path, err);
+      free(err);
+   }
+
+   TPMBACK_LOG("Frontend %u/%u disconnected\n", (unsigned int)
tpmif->domid, tpmif->handle);
+
+   /* free memory */
+   __free_tpmif(tpmif);
+
+}
+
+/**********************
+ * REMAINING TPMBACK FUNCTIONS
+ * ********************/
+
+/*Event channel handler */
+void tpmback_handler(evtchn_port_t port, struct pt_regs *regs, void *dat=
a)
+{
+   tpmif_t* tpmif =3D (tpmif_t*) data;
+   tpmif_tx_request_t* tx =3D &tpmif->tx->ring[0].req;
+   /* Throw away 0 size events, these can trigger from event channel
unmasking */
+   if(tx->size =3D=3D 0)
+      return;
+
+   TPMBACK_DEBUG("EVENT CHANNEL FIRE %u/%u\n", (unsigned int)
tpmif->domid, tpmif->handle);
+   tpmif_req_ready(tpmif);
+   wake_up(&waitq);
+
+}
+
+/* Connect to frontend */
+int connect_fe(tpmif_t* tpmif)
+{
+   char path[512];
+   char* err, *value;
+   uint32_t domid;
+   grant_ref_t ringref;
+   evtchn_port_t evtchn;
+
+   /* If already connected then quit */
+   if (tpmif->status =3D=3D CONNECTED) {
+      TPMBACK_DEBUG("%u/%u tried to connect while it was already
connected?\n", (unsigned int) tpmif->domid, tpmif->handle);
+      return 0;
+   }
+
+   /* Fetch the grant reference */
+   snprintf(path, 512, "%s/ring-ref", tpmif->fe_path);
+   if((err =3D xenbus_read(XBT_NIL, path, &value))) {
+      TPMBACK_ERR("Error creating new tpm instance xenbus_read(%s)
Error =3D %s", path, err);
+      free(err);
+      return -1;
+   }
+   if(sscanf(value, "%d", &ringref) !=3D 1) {
+      TPMBACK_ERR("Non integer value (%s) in %s ??\n", value, path);
+      free(value);
+      return -1;
+   }
+   free(value);
+
+
+   /* Fetch the event channel*/
+   snprintf(path, 512, "%s/event-channel", tpmif->fe_path);
+   if((err =3D xenbus_read(XBT_NIL, path, &value))) {
+      TPMBACK_ERR("Error creating new tpm instance xenbus_read(%s)
Error =3D %s", path, err);
+      free(err);
+      return -1;
+   }
+   if(sscanf(value, "%d", &evtchn) !=3D 1) {
+      TPMBACK_ERR("Non integer value (%s) in %s ??\n", value, path);
+      free(value);
+      return -1;
+   }
+   free(value);
+
+   domid =3D tpmif->domid;
+   if((tpmif->tx =3D gntmap_map_grant_refs(&gtpmdev.map, 1, &domid, 0,
&ringref, PROT_READ | PROT_WRITE)) =3D=3D NULL) {
+      TPMBACK_ERR("Failed to map grant reference %u/%u\n", (unsigned
int) tpmif->domid, tpmif->handle);
+      return -1;
+   }
+   memset(tpmif->tx, 0, PAGE_SIZE);
+
+   /*Bind the event channel */
+   if((evtchn_bind_interdomain(tpmif->domid, evtchn, tpmback_handler,
tpmif, &tpmif->evtchn)))
+   {
+      TPMBACK_ERR("%u/%u Unable to bind to interdomain event
channel!\n", (unsigned int) tpmif->domid, tpmif->handle);
+      goto error_post_map;
+   }
+   unmask_evtchn(tpmif->evtchn);
+
+   /* Write the ready flag and change status to connected */
+   snprintf(path, 512, "backend/vtpm/%u/%u", (unsigned int)
tpmif->domid, tpmif->handle);
+   if((err =3D xenbus_printf(XBT_NIL, path, "ready", "%u", 1))) {
+      TPMBACK_ERR("%u/%u Unable to write ready flag on connect_fe()\n",
(unsigned int) tpmif->domid, tpmif->handle);
+      free(err);
+      goto error_post_evtchn;
+   }
+   tpmif->status =3D CONNECTED;
+   if((tpmif_change_state(tpmif, XenbusStateConnected))){
+      goto error_post_evtchn;
+   }
+
+   TPMBACK_LOG("Frontend %u/%u connected\n", (unsigned int)
tpmif->domid, tpmif->handle);
+
+   return 0;
+error_post_evtchn:
+   mask_evtchn(tpmif->evtchn);
+   unbind_evtchn(tpmif->evtchn);
+error_post_map:
+   gntmap_munmap(&gtpmdev.map, (unsigned long)tpmif->tx, 1);
+   return -1;
+}
+
+static int frontend_changed(tpmif_t* tpmif)
+{
+   int state =3D xenbus_read_integer(tpmif->fe_state_path);
+   if(state < 0) {
+      state =3D XenbusStateUnknown;
+   }
+
+   TPMBACK_DEBUG("Frontend %u/%u state changed to %d\n", (unsigned int)
tpmif->domid, tpmif->handle, state);
+
+   switch (state) {
+      case XenbusStateInitialising:
+      case XenbusStateInitialised:
+     break;
+
+      case XenbusStateConnected:
+     if(connect_fe(tpmif)) {
+        TPMBACK_ERR("Failed to connect to front end %u/%u\n", (unsigned
int) tpmif->domid, tpmif->handle);
+        tpmif_change_state(tpmif, XenbusStateClosed);
+        return -1;
+     }
+     break;
+
+      case XenbusStateClosing:
+     tpmif_change_state(tpmif, XenbusStateClosing);
+     break;
+
+      case XenbusStateUnknown: /* keep it here */
+      case XenbusStateClosed:
+     free_tpmif(tpmif);
+     break;
+
+      default:
+     TPMBACK_DEBUG("BAD STATE CHANGE %u/%u state =3D %d for tpmif\n",
(unsigned int) tpmif->domid, tpmif->handle, state);
+     return -1;
+   }
+   return 0;
+}
+
+
+/* parses the string that comes out of xenbus_watch_wait_return. */
+static int parse_eventstr(const char* evstr, domid_t* domid, unsigned
int* handle)
+{
+   int ret;
+   char cmd[40];
+   char* err;
+   char* value;
+   unsigned int udomid =3D 0;
+   tpmif_t* tpmif;
+   /* First check for new frontends, this occurs when
/backend/vtpm/<domid>/<handle> gets created. Note we what the sscanf to
fail on the last %s */
+   if (sscanf(evstr, "backend/vtpm/%u/%u/%40s", &udomid, handle, cmd)
=3D=3D 2) {
+      *domid =3D udomid;
+      /* Make sure the entry exists, if this event triggers because the
entry dissapeared then ignore it */
+      if((err =3D xenbus_read(XBT_NIL, evstr, &value))) {
+     free(err);
+     return EV_NONE;
+      }
+      free(value);
+      /* Make sure the tpmif entry does not already exist, this should
not happen */
+      if((tpmif =3D get_tpmif(*domid, *handle)) !=3D NULL) {
+     TPMBACK_DEBUG("Duplicate tpm entries! %u %u\n", tpmif->domid,
tpmif->handle);
+     return EV_NONE;
+      }
+      return EV_NEWFE;
+   } else if((ret =3D sscanf(evstr,
"/local/domain/%u/device/vtpm/%u/%40s", &udomid, handle, cmd)) =3D=3D 3) =
{
+      *domid =3D udomid;
+      if (!strcmp(cmd, "state"))
+     return EV_STCHNG;
+   }
+   return EV_NONE;
+}
+
+void handle_backend_event(char* evstr) {
+   tpmif_t* tpmif;
+   domid_t domid;
+   unsigned int handle;
+   int event;
+
+   TPMBACK_DEBUG("Xenbus Event: %s\n", evstr);
+
+   event =3D parse_eventstr(evstr, &domid, &handle);
+
+   switch(event) {
+      case EV_NEWFE:
+     if(new_tpmif(domid, handle) =3D=3D NULL) {
+        TPMBACK_ERR("Failed to create new tpm instance %u/%u\n",
(unsigned int) domid, handle);
+     }
+     wake_up(&waitq);
+     break;
+      case EV_STCHNG:
+     if((tpmif =3D get_tpmif(domid, handle))) {
+        frontend_changed(tpmif);
+     } else {
+        TPMBACK_DEBUG("Event Received for non-existant tpm!
instance=3D%u/%u xenbus_event=3D%s\n", (unsigned int) domid, handle, evst=
r);
+     }
+     break;
+   }
+}
+
+/* Runs through the given path and creates events recursively
+ * for all of its children.
+ * @path - xenstore path to scan */
+static void generate_backend_events(const char* path)
+{
+   char* err;
+   int i, len;
+   char **dirs;
+   char *entry;
+
+   if((err =3D xenbus_ls(XBT_NIL, path, &dirs)) !=3D NULL) {
+      free(err);
+      return;
+   }
+
+   for(i =3D 0; dirs[i] !=3D NULL; ++i) {
+      len =3D strlen(path) + strlen(dirs[i]) + 2;
+      entry =3D malloc(len);
+      snprintf(entry, len, "%s/%s", path, dirs[i]);
+
+      /* Generate and handle event for the entry itself */
+      handle_backend_event(entry);
+
+      /* Do children */
+      generate_backend_events(entry);
+
+      /* Cleanup */
+      free(entry);
+      free(dirs[i]);
+   }
+   free(dirs);
+   return;
+}
+
+char* tpmback_get_uuid(domid_t domid, unsigned int handle)
+{
+   tpmif_t* tpmif;
+   if((tpmif =3D get_tpmif(domid, handle)) =3D=3D NULL) {
+      TPMBACK_DEBUG("get_uuid() failed, %u/%u is an invalid
frontend\n", (unsigned int) domid, handle);
+      return NULL;
+   }
+
+   return tpmif->uuid;
+}
+
+void tpmback_set_open_callback(void (*cb)(domid_t, unsigned int))
+{
+   gtpmdev.open_callback =3D cb;
+}
+void tpmback_set_close_callback(void (*cb)(domid_t, unsigned int))
+{
+   gtpmdev.close_callback =3D cb;
+}
+void tpmback_set_suspend_callback(void (*cb)(domid_t, unsigned int))
+{
+   gtpmdev.suspend_callback =3D cb;
+}
+void tpmback_set_resume_callback(void (*cb)(domid_t, unsigned int))
+{
+   gtpmdev.resume_callback =3D cb;
+}
+
+static void event_listener(void)
+{
+   const char* bepath =3D "backend/vtpm";
+   char **path;
+   char* err;
+
+   /* Setup the backend device watch */
+   if((err =3D xenbus_watch_path_token(XBT_NIL, bepath, bepath,
&gtpmdev.events)) !=3D NULL) {
+      TPMBACK_ERR("xenbus_watch_path_token(%s) failed with error
%s!\n", bepath, err);
+      free(err);
+      goto egress;
+   }
+
+   /* Check for any frontends that connected before we set the watch.
+    * This is almost guaranteed to happen if both domains are started
+    * immediatly one after the other.
+    * We do this by manually generating events on everything in the back=
end
+    * path */
+   generate_backend_events(bepath);
+
+   /* Wait and listen for changes in frontend connections */
+   while(1) {
+      path =3D xenbus_wait_for_watch_return(&gtpmdev.events);
+
+      /*If quit flag was set then exit */
+      if(gtpmdev.flags & TPMIF_CLOSED) {
+     TPMBACK_DEBUG("listener thread got quit event. Exiting..\n");
+     free(path);
+     break;
+      }
+      handle_backend_event(*path);
+      free(path);
+
+   }
+
+   if((err =3D xenbus_unwatch_path_token(XBT_NIL, bepath, bepath)) !=3D =
NULL) {
+      free(err);
+   }
+egress:
+   return;
+}
+
+void event_thread(void* p) {
+   event_listener();
+}
+
+void init_tpmback(char** exclusive_uuids)
+{
+   if(!globalinit) {
+      init_waitqueue_head(&waitq);
+      globalinit =3D 1;
+   }
+   printk("=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Init TPM BACK =3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D\n");
+   gtpmdev.tpmlist =3D malloc(sizeof(tpmif_t*) * DEF_ARRAY_SIZE);
+   gtpmdev.num_alloc =3D DEF_ARRAY_SIZE;
+   gtpmdev.num_tpms =3D 0;
+   gtpmdev.flags =3D 0;
+   gtpmdev.exclusive_uuids =3D exclusive_uuids;
+
+   gtpmdev.open_callback =3D gtpmdev.close_callback =3D NULL;
+   gtpmdev.suspend_callback =3D gtpmdev.resume_callback =3D NULL;
+
+   eventthread =3D create_thread("tpmback-listener", event_thread, NULL)=
;
+
+}
+
+void shutdown_tpmback(void)
+{
+   /* Disable callbacks */
+   gtpmdev.open_callback =3D gtpmdev.close_callback =3D NULL;
+   gtpmdev.suspend_callback =3D gtpmdev.resume_callback =3D NULL;
+
+   TPMBACK_LOG("Shutting down tpm backend\n");
+   /* Set the quit flag */
+   gtpmdev.flags =3D TPMIF_CLOSED;
+
+   //printk("num tpms is %d\n", gtpmdev.num_tpms);
+   /*Free all backend instances */
+   while(gtpmdev.num_tpms) {
+      free_tpmif(gtpmdev.tpmlist[0]);
+   }
+   free(gtpmdev.tpmlist);
+   gtpmdev.tpmlist =3D NULL;
+   gtpmdev.num_alloc =3D 0;
+
+   /* Wake up anyone possibly waiting on the device and let them exit */=

+   wake_up(&waitq);
+   schedule();
+}
+
+inline void init_tpmcmd(tpmcmd_t* tpmcmd, domid_t domid, unsigned int
handle, char* uuid)
+{
+   tpmcmd->domid =3D domid;
+   tpmcmd->handle =3D handle;
+   tpmcmd->uuid =3D uuid;
+   tpmcmd->req =3D NULL;
+   tpmcmd->req_len =3D 0;
+   tpmcmd->resp =3D NULL;
+   tpmcmd->resp_len =3D 0;
+}
+
+tpmcmd_t* get_request(tpmif_t* tpmif) {
+   tpmcmd_t* cmd;
+   tpmif_tx_request_t* tx;
+   int offset;
+   int tocopy;
+   int i;
+   uint32_t domid;
+   int flags;
+
+   local_irq_save(flags);
+
+   /* Allocate the cmd object to hold the data */
+   if((cmd =3D malloc(sizeof(*cmd))) =3D=3D NULL) {
+      goto error;
+   }
+   init_tpmcmd(cmd, tpmif->domid, tpmif->handle, tpmif->uuid);
+
+   tx =3D &tpmif->tx->ring[0].req;
+   cmd->req_len =3D tx->size;
+   /* Allocate the buffer */
+   if(cmd->req_len) {
+      if((cmd->req =3D malloc(cmd->req_len)) =3D=3D NULL) {
+     goto error;
+      }
+   }
+   /* Copy the bits from the shared pages */
+   offset =3D 0;
+   for(i =3D 0; i < TPMIF_TX_RING_SIZE && offset < cmd->req_len; ++i) {
+      tx =3D &tpmif->tx->ring[i].req;
+
+      /* Map the page with the data */
+      domid =3D (uint32_t)tpmif->domid;
+      if((tpmif->pages[i] =3D gntmap_map_grant_refs(&gtpmdev.map, 1,
&domid, 0, &tx->ref, PROT_READ)) =3D=3D NULL) {
+     TPMBACK_ERR("%u/%u Unable to map shared page during read!\n",
(unsigned int) tpmif->domid, tpmif->handle);
+     goto error;
+      }
+
+      /* do the copy now */
+      tocopy =3D min(cmd->req_len - offset, PAGE_SIZE);
+      memcpy(&cmd->req[offset], tpmif->pages[i], tocopy);
+      offset +=3D tocopy;
+
+      /* release the page */
+      gntmap_munmap(&gtpmdev.map, (unsigned long)tpmif->pages[i], 1);
+
+   }
+
+#ifdef TPMBACK_PRINT_DEBUG
+   TPMBACK_DEBUG("Received Tpm Command from %u/%u of size %u",
(unsigned int) tpmif->domid, tpmif->handle, cmd->req_len);
+   for(i =3D 0; i < cmd->req_len; ++i) {
+      if (!(i % 30)) {
+     TPMBACK_DEBUG_MORE("\n");
+      }
+      TPMBACK_DEBUG_MORE("%02hhX ", cmd->req[i]);
+   }
+   TPMBACK_DEBUG_MORE("\n\n");
+#endif
+
+   local_irq_restore(flags);
+   return cmd;
+error:
+   if(cmd !=3D NULL) {
+      if (cmd->req !=3D NULL) {
+     free(cmd->req);
+     cmd->req =3D NULL;
+      }
+      free(cmd);
+      cmd =3D NULL;
+   }
+   local_irq_restore(flags);
+   return NULL;
+
+}
+
+void send_response(tpmcmd_t* cmd, tpmif_t* tpmif)
+{
+   tpmif_tx_request_t* tx;
+   int offset;
+   int i;
+   uint32_t domid;
+   int tocopy;
+   int flags;
+
+   local_irq_save(flags);
+
+   tx =3D &tpmif->tx->ring[0].req;
+   tx->size =3D cmd->resp_len;
+
+   offset =3D 0;
+   for(i =3D 0; i < TPMIF_TX_RING_SIZE && offset < cmd->resp_len; ++i) {=

+      tx =3D &tpmif->tx->ring[i].req;
+
+      /* Map the page with the data */
+      domid =3D (uint32_t)tpmif->domid;
+      if((tpmif->pages[i] =3D gntmap_map_grant_refs(&gtpmdev.map, 1,
&domid, 0, &tx->ref, PROT_WRITE)) =3D=3D NULL) {
+     TPMBACK_ERR("%u/%u Unable to map shared page during write!\n",
(unsigned int) tpmif->domid, tpmif->handle);
+     goto error;
+      }
+
+      /* do the copy now */
+      tocopy =3D min(cmd->resp_len - offset, PAGE_SIZE);
+      memcpy(tpmif->pages[i], &cmd->resp[offset], tocopy);
+      offset +=3D tocopy;
+
+      /* release the page */
+      gntmap_munmap(&gtpmdev.map, (unsigned long)tpmif->pages[i], 1);
+
+   }
+
+#ifdef TPMBACK_PRINT_DEBUG
+   TPMBACK_DEBUG("Sent response to %u/%u of size %u", (unsigned int)
tpmif->domid, tpmif->handle, cmd->resp_len);
+   for(i =3D 0; i < cmd->resp_len; ++i) {
+      if (!(i % 30)) {
+     TPMBACK_DEBUG_MORE("\n");
+      }
+      TPMBACK_DEBUG_MORE("%02hhX ", cmd->resp[i]);
+   }
+   TPMBACK_DEBUG_MORE("\n\n");
+#endif
+   /* clear the ready flag and send the event channel notice to the
frontend */
+   tpmif_req_finished(tpmif);
+   notify_remote_via_evtchn(tpmif->evtchn);
+error:
+   local_irq_restore(flags);
+   return;
+}
+
+tpmcmd_t* tpmback_req_any(void)
+{
+   int i;
+   /* Block until something has a request */
+   wait_event(waitq, (gtpmdev.flags & (TPMIF_REQ_READY | TPMIF_CLOSED)))=
;
+
+   /* Check if were shutting down */
+   if(gtpmdev.flags & TPMIF_CLOSED) {
+      /* if something was waiting for us to give up the queue so it can
shutdown, let it finish */
+      schedule();
+      return NULL;
+   }
+
+   for(i =3D 0; i < gtpmdev.num_tpms; ++i) {
+      if(gtpmdev.tpmlist[i]->flags & TPMIF_REQ_READY) {
+     return get_request(gtpmdev.tpmlist[i]);
+      }
+   }
+
+   TPMBACK_ERR("backend request ready flag was set but no interfaces
were actually ready\n");
+   return NULL;
+}
+
+tpmcmd_t* tpmback_req(domid_t domid, unsigned int handle)
+{
+   tpmif_t* tpmif;
+   tpmif =3D get_tpmif(domid, handle);
+   if(tpmif =3D=3D NULL) {
+      return NULL;
+   }
+
+   wait_event(waitq, (tpmif->flags & (TPMIF_REQ_READY | TPMIF_CLOSED)
|| gtpmdev.flags & TPMIF_CLOSED));
+
+   /* Check if were shutting down */
+   if(tpmif->flags & TPMIF_CLOSED || gtpmdev.flags & TPMIF_CLOSED) {
+      /* if something was waiting for us to give up the queue so it can
free this instance, let it finish */
+      schedule();
+      return NULL;
+   }
+
+   return get_request(tpmif);
+}
+
+void tpmback_resp(tpmcmd_t* tpmcmd)
+{
+   tpmif_t* tpmif;
+
+   /* Get the associated interface, if it doesnt exist then just quit */=

+   tpmif =3D get_tpmif(tpmcmd->domid, tpmcmd->handle);
+   if(tpmif =3D=3D NULL) {
+      TPMBACK_ERR("Tried to send a reponse to non existant frontend
%u/%u\n", (unsigned int) tpmcmd->domid, tpmcmd->handle);
+      goto end;
+   }
+
+   if(!(tpmif->flags & TPMIF_REQ_READY)) {
+      TPMBACK_ERR("Tried to send response to a frontend that was not
waiting for one %u/%u\n", (unsigned int) tpmcmd->domid, tpmcmd->handle);
+      goto end;
+   }
+
+   /* Send response to frontend */
+   send_response(tpmcmd, tpmif);
+
+end:
+   if(tpmcmd->req !=3D NULL) {
+      free(tpmcmd->req);
+   }
+   free(tpmcmd);
+   return;
+}
+
+int tpmback_wait_for_frontend_connect(domid_t *domid, unsigned int *hand=
le)
+{
+   tpmif_t* tpmif;
+   int flags;
+   wait_event(waitq, ((gtpmdev.num_tpms > 0) || gtpmdev.flags &
TPMIF_CLOSED));
+   if(gtpmdev.flags & TPMIF_CLOSED) {
+      return -1;
+   }
+   local_irq_save(flags);
+   tpmif =3D gtpmdev.tpmlist[0];
+   *domid =3D tpmif->domid;
+   *handle =3D tpmif->handle;
+   local_irq_restore(flags);
+
+   return 0;
+}
+
+int tpmback_num_frontends(void)
+{
+   return gtpmdev.num_tpms;
+}
diff --git a/extras/mini-os/tpmfront.c b/extras/mini-os/tpmfront.c
--- /dev/null
+++ b/extras/mini-os/tpmfront.c
@@ -0,0 +1,606 @@
+/*
+ * Copyright (c) 2010-2012 United States Government, as represented by
+ * the Secretary of Defense.  All rights reserved.
+ *
+ * This driver 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 3 of the License, or
+ * (at your option) any later version.
+ *
+ * This driver is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program.  If not, see <http://www.gnu.org/licenses/>.=

+ *
+ * Based upon the files:
+ *  drivers/char/tpm/tpm_vtpm.c
+ *  drivers/char/tpm/tpm_xen.c
+ * from the Linux kernel, which are Copyright (C) 2006 IBM Corporation
+ */
+#include <mini-os/os.h>
+#include <mini-os/xenbus.h>
+#include <mini-os/xmalloc.h>
+#include <mini-os/events.h>
+#include <mini-os/wait.h>
+#include <mini-os/gnttab.h>
+#include <xen/io/xenbus.h>
+#include <xen/io/tpmif.h>
+#include <mini-os/tpmfront.h>
+#include <fcntl.h>
+
+//#define TPMFRONT_PRINT_DEBUG
+#ifdef TPMFRONT_PRINT_DEBUG
+#define TPMFRONT_DEBUG(fmt,...) printk("Tpmfront:Debug("__FILE__":%d) "
fmt, __LINE__, ##__VA_ARGS__)
+#define TPMFRONT_DEBUG_MORE(fmt,...) printk(fmt, ##__VA_ARGS__)
+#else
+#define TPMFRONT_DEBUG(fmt,...)
+#endif
+#define TPMFRONT_ERR(fmt,...) printk("Tpmfront:Error " fmt, ##__VA_ARGS_=
_)
+#define TPMFRONT_LOG(fmt,...) printk("Tpmfront:Info " fmt, ##__VA_ARGS__=
)
+
+#define min(a,b) (((a) < (b)) ? (a) : (b))
+
+void tpmfront_handler(evtchn_port_t port, struct pt_regs *regs, void
*data) {
+   struct tpmfront_dev* dev =3D (struct tpmfront_dev*) data;
+   /*If we get a response when we didnt make a request, just ignore it *=
/
+   if(!dev->waiting) {
+      return;
+   }
+
+   dev->waiting =3D 0;
+#ifdef HAVE_LIBC
+   if(dev->fd >=3D 0) {
+      files[dev->fd].read =3D 1;
+   }
+#endif
+   wake_up(&dev->waitq);
+}
+
+static int publish_xenbus(struct tpmfront_dev* dev) {
+   xenbus_transaction_t xbt;
+   int retry;
+   char* err;
+   /* Write the grant reference and event channel to xenstore */
+again:
+   if((err =3D xenbus_transaction_start(&xbt))) {
+      TPMFRONT_ERR("Unable to start xenbus transaction, error was
%s\n", err);
+      free(err);
+      return -1;
+   }
+
+   if((err =3D xenbus_printf(xbt, dev->nodename, "ring-ref", "%u",
(unsigned int) dev->ring_ref))) {
+      TPMFRONT_ERR("Unable to write %s/ring-ref, error was %s\n",
dev->nodename, err);
+      free(err);
+      goto abort_transaction;
+   }
+
+   if((err =3D xenbus_printf(xbt, dev->nodename, "event-channel", "%u",
(unsigned int) dev->evtchn))) {
+      TPMFRONT_ERR("Unable to write %s/event-channel, error was %s\n",
dev->nodename, err);
+      free(err);
+      goto abort_transaction;
+   }
+
+   if((err =3D xenbus_transaction_end(xbt, 0, &retry))) {
+      TPMFRONT_ERR("Unable to complete xenbus transaction, error was
%s\n", err);
+      free(err);
+      return -1;
+   }
+   if(retry) {
+      goto again;
+   }
+
+   return 0;
+abort_transaction:
+   if((err =3D xenbus_transaction_end(xbt, 1, &retry))) {
+      free(err);
+   }
+   return -1;
+}
+
+static int wait_for_backend_connect(xenbus_event_queue* events, char* pa=
th)
+{
+   int state;
+
+   TPMFRONT_LOG("Waiting for backend connection..\n");
+   /* Wait for the backend to connect */
+   while(1) {
+      state =3D xenbus_read_integer(path);
+      if ( state < 0)
+     state =3D XenbusStateUnknown;
+      switch(state) {
+     /* Bad states, we quit with error */
+     case XenbusStateUnknown:
+     case XenbusStateClosing:
+     case XenbusStateClosed:
+        TPMFRONT_ERR("Unable to connect to backend\n");
+        return -1;
+     /* If backend is connected then break out of loop */
+     case XenbusStateConnected:
+        TPMFRONT_LOG("Backend Connected\n");
+        return 0;
+     default:
+        xenbus_wait_for_watch(events);
+      }
+   }
+
+}
+
+static int wait_for_backend_closed(xenbus_event_queue* events, char* pat=
h)
+{
+   int state;
+
+   TPMFRONT_LOG("Waiting for backend to close..\n");
+   while(1) {
+      state =3D xenbus_read_integer(path);
+      if ( state < 0)
+     state =3D XenbusStateUnknown;
+      switch(state) {
+     case XenbusStateUnknown:
+        TPMFRONT_ERR("Backend Unknown state, forcing shutdown\n");
+        return -1;
+     case XenbusStateClosed:
+        TPMFRONT_LOG("Backend Closed\n");
+        return 0;
+     default:
+        xenbus_wait_for_watch(events);
+      }
+   }
+
+}
+
+static int wait_for_backend_state_changed(struct tpmfront_dev* dev,
XenbusState state) {
+   char* err;
+   int ret =3D 0;
+   xenbus_event_queue events =3D NULL;
+   char path[512];
+
+   snprintf(path, 512, "%s/state", dev->bepath);
+   /*Setup the watch to wait for the backend */
+   if((err =3D xenbus_watch_path_token(XBT_NIL, path, path, &events))) {=

+      TPMFRONT_ERR("Could not set a watch on %s, error was %s\n", path,
err);
+      free(err);
+      return -1;
+   }
+
+   /* Do the actual wait loop now */
+   switch(state) {
+      case XenbusStateConnected:
+     ret =3D wait_for_backend_connect(&events, path);
+     break;
+      case XenbusStateClosed:
+     ret =3D wait_for_backend_closed(&events, path);
+     break;
+      default:
+     break;
+   }
+
+   if((err =3D xenbus_unwatch_path_token(XBT_NIL, path, path))) {
+      TPMFRONT_ERR("Unable to unwatch %s, error was %s, ignoring..\n",
path, err);
+      free(err);
+   }
+   return ret;
+}
+
+static int tpmfront_connect(struct tpmfront_dev* dev)
+{
+   char* err;
+   /* Create shared page */
+   dev->tx =3D (tpmif_tx_interface_t*) alloc_page();
+   if(dev->tx =3D=3D NULL) {
+      TPMFRONT_ERR("Unable to allocate page for shared memory\n");
+      goto error;
+   }
+   memset(dev->tx, 0, PAGE_SIZE);
+   dev->ring_ref =3D gnttab_grant_access(dev->bedomid,
virt_to_mfn(dev->tx), 0);
+   TPMFRONT_DEBUG("grant ref is %lu\n", (unsigned long) dev->ring_ref);
+
+   /*Create event channel */
+   if(evtchn_alloc_unbound(dev->bedomid, tpmfront_handler, dev,
&dev->evtchn)) {
+      TPMFRONT_ERR("Unable to allocate event channel\n");
+      goto error_postmap;
+   }
+   unmask_evtchn(dev->evtchn);
+   TPMFRONT_DEBUG("event channel is %lu\n", (unsigned long) dev->evtchn)=
;
+
+   /* Write the entries to xenstore */
+   if(publish_xenbus(dev)) {
+      goto error_postevtchn;
+   }
+
+   /* Change state to connected */
+   dev->state =3D XenbusStateConnected;
+
+   /* Tell the backend that we are ready */
+   if((err =3D xenbus_printf(XBT_NIL, dev->nodename, "state", "%u",
dev->state))) {
+      TPMFRONT_ERR("Unable to write to xenstore %s/state, value=3D%u",
dev->nodename, XenbusStateConnected);
+      free(err);
+      goto error;
+   }
+
+   return 0;
+error_postevtchn:
+      mask_evtchn(dev->evtchn);
+      unbind_evtchn(dev->evtchn);
+error_postmap:
+      gnttab_end_access(dev->ring_ref);
+      free_page(dev->tx);
+error:
+   return -1;
+}
+
+struct tpmfront_dev* init_tpmfront(const char* _nodename)
+{
+   struct tpmfront_dev* dev;
+   const char* nodename;
+   char path[512];
+   char* value, *err;
+   unsigned long long ival;
+   int i;
+
+   printk("=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Init TPM Front =3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D\n");
+
+   dev =3D malloc(sizeof(struct tpmfront_dev));
+   memset(dev, 0, sizeof(struct tpmfront_dev));
+
+#ifdef HAVE_LIBC
+   dev->fd =3D -1;
+#endif
+
+   nodename =3D _nodename ? _nodename : "device/vtpm/0";
+   dev->nodename =3D strdup(nodename);
+
+   init_waitqueue_head(&dev->waitq);
+
+   /* Get backend domid */
+   snprintf(path, 512, "%s/backend-id", dev->nodename);
+   if((err =3D xenbus_read(XBT_NIL, path, &value))) {
+      TPMFRONT_ERR("Unable to read %s during tpmfront initialization!
error =3D %s\n", path, err);
+      free(err);
+      goto error;
+   }
+   if(sscanf(value, "%llu", &ival) !=3D 1) {
+      TPMFRONT_ERR("%s has non-integer value (%s)\n", path, value);
+      free(value);
+      goto error;
+   }
+   free(value);
+   dev->bedomid =3D ival;
+
+   /* Get backend xenstore path */
+   snprintf(path, 512, "%s/backend", dev->nodename);
+   if((err =3D xenbus_read(XBT_NIL, path, &dev->bepath))) {
+      TPMFRONT_ERR("Unable to read %s during tpmfront initialization!
error =3D %s\n", path, err);
+      free(err);
+      goto error;
+   }
+
+   /* Create and publish grant reference and event channel */
+   if (tpmfront_connect(dev)) {
+      goto error;
+   }
+
+   /* Wait for backend to connect */
+   if( wait_for_backend_state_changed(dev, XenbusStateConnected)) {
+      goto error;
+   }
+
+   /* Allocate pages that will contain the messages */
+   dev->pages =3D malloc(sizeof(void*) * TPMIF_TX_RING_SIZE);
+   if(dev->pages =3D=3D NULL) {
+      goto error;
+   }
+   memset(dev->pages, 0, sizeof(void*) * TPMIF_TX_RING_SIZE);
+   for(i =3D 0; i < TPMIF_TX_RING_SIZE; ++i) {
+      dev->pages[i] =3D (void*)alloc_page();
+      if(dev->pages[i] =3D=3D NULL) {
+     goto error;
+      }
+   }
+
+   TPMFRONT_LOG("Initialization Completed successfully\n");
+
+   return dev;
+
+error:
+   shutdown_tpmfront(dev);
+   return NULL;
+}
+void shutdown_tpmfront(struct tpmfront_dev* dev)
+{
+   char* err;
+   char path[512];
+   int i;
+   tpmif_tx_request_t* tx;
+   if(dev =3D=3D NULL) {
+      return;
+   }
+   TPMFRONT_LOG("Shutting down tpmfront\n");
+   /* disconnect */
+   if(dev->state =3D=3D XenbusStateConnected) {
+      dev->state =3D XenbusStateClosing;
+      //FIXME: Transaction for this?
+      /* Tell backend we are closing */
+      if((err =3D xenbus_printf(XBT_NIL, dev->nodename, "state", "%u",
(unsigned int) dev->state))) {
+     free(err);
+      }
+
+      /* Clean up xenstore entries */
+      snprintf(path, 512, "%s/event-channel", dev->nodename);
+      if((err =3D xenbus_rm(XBT_NIL, path))) {
+     free(err);
+      }
+      snprintf(path, 512, "%s/ring-ref", dev->nodename);
+      if((err =3D xenbus_rm(XBT_NIL, path))) {
+     free(err);
+      }
+
+      /* Tell backend we are closed */
+      dev->state =3D XenbusStateClosed;
+      if((err =3D xenbus_printf(XBT_NIL, dev->nodename, "state", "%u",
(unsigned int) dev->state))) {
+     TPMFRONT_ERR("Unable to write to %s, error was %s", dev->nodename,
err);
+     free(err);
+      }
+
+      /* Wait for the backend to close and unmap shared pages, ignore
any errors */
+      wait_for_backend_state_changed(dev, XenbusStateClosed);
+
+      /* Cleanup any shared pages */
+      if(dev->pages) {
+     for(i =3D 0; i < TPMIF_TX_RING_SIZE; ++i) {
+        if(dev->pages[i]) {
+           tx =3D &dev->tx->ring[i].req;
+           if(tx->ref !=3D 0) {
+          gnttab_end_access(tx->ref);
+           }
+           free_page(dev->pages[i]);
+        }
+     }
+     free(dev->pages);
+      }
+
+      /* Close event channel and unmap shared page */
+      mask_evtchn(dev->evtchn);
+      unbind_evtchn(dev->evtchn);
+      gnttab_end_access(dev->ring_ref);
+
+      free_page(dev->tx);
+
+   }
+
+   /* Cleanup memory usage */
+   if(dev->respbuf) {
+      free(dev->respbuf);
+   }
+   if(dev->bepath) {
+      free(dev->bepath);
+   }
+   if(dev->nodename) {
+      free(dev->nodename);
+   }
+   free(dev);
+}
+
+int tpmfront_send(struct tpmfront_dev* dev, const uint8_t* msg, size_t
length)
+{
+   int i;
+   tpmif_tx_request_t* tx =3D NULL;
+   /* Error Checking */
+   if(dev =3D=3D NULL || dev->state !=3D XenbusStateConnected) {
+      TPMFRONT_ERR("Tried to send message through disconnected
frontend\n");
+      return -1;
+   }
+
+#ifdef TPMFRONT_PRINT_DEBUG
+   TPMFRONT_DEBUG("Sending Msg to backend size=3D%u", (unsigned int) len=
gth);
+   for(i =3D 0; i < length; ++i) {
+      if(!(i % 30)) {
+     TPMFRONT_DEBUG_MORE("\n");
+      }
+      TPMFRONT_DEBUG_MORE("%02X ", msg[i]);
+   }
+   TPMFRONT_DEBUG_MORE("\n");
+#endif
+
+   /* Copy to shared pages now */
+   for(i =3D 0; length > 0 && i < TPMIF_TX_RING_SIZE; ++i) {
+      /* Share the page */
+      tx =3D &dev->tx->ring[i].req;
+      tx->unused =3D 0;
+      tx->addr =3D virt_to_mach(dev->pages[i]);
+      tx->ref =3D gnttab_grant_access(dev->bedomid,
virt_to_mfn(dev->pages[i]), 0);
+      /* Copy the bits to the page */
+      tx->size =3D length > PAGE_SIZE ? PAGE_SIZE : length;
+      memcpy(dev->pages[i], &msg[i * PAGE_SIZE], tx->size);
+
+      /* Update counters */
+      length -=3D tx->size;
+   }
+   dev->waiting =3D 1;
+   dev->resplen =3D 0;
+#ifdef HAVE_LIBC
+   if(dev->fd >=3D 0) {
+      files[dev->fd].read =3D 0;
+      files[dev->fd].tpmfront.respgot =3D 0;
+      files[dev->fd].tpmfront.offset =3D 0;
+   }
+#endif
+   notify_remote_via_evtchn(dev->evtchn);
+   return 0;
+}
+int tpmfront_recv(struct tpmfront_dev* dev, uint8_t** msg, size_t *lengt=
h)
+{
+   tpmif_tx_request_t* tx;
+   int i;
+   if(dev =3D=3D NULL || dev->state !=3D XenbusStateConnected) {
+      TPMFRONT_ERR("Tried to receive message from disconnected
frontend\n");
+      return -1;
+   }
+   /*Wait for the response */
+   wait_event(dev->waitq, (!dev->waiting));
+
+   /* Initialize */
+   *msg =3D NULL;
+   *length =3D 0;
+
+   /* special case, just quit */
+   tx =3D &dev->tx->ring[0].req;
+   if(tx->size =3D=3D 0 ) {
+       goto quit;
+   }
+   /* Get the total size */
+   tx =3D &dev->tx->ring[0].req;
+   for(i =3D 0; i < TPMIF_TX_RING_SIZE && tx->size > 0; ++i) {
+      tx =3D &dev->tx->ring[i].req;
+      *length +=3D tx->size;
+   }
+   /* Alloc the buffer */
+   if(dev->respbuf) {
+      free(dev->respbuf);
+   }
+   *msg =3D dev->respbuf =3D malloc(*length);
+   dev->resplen =3D *length;
+   /* Copy the bits */
+   tx =3D &dev->tx->ring[0].req;
+   for(i =3D 0; i < TPMIF_TX_RING_SIZE && tx->size > 0; ++i) {
+      tx =3D &dev->tx->ring[i].req;
+      memcpy(&(*msg)[i * PAGE_SIZE], dev->pages[i], tx->size);
+      gnttab_end_access(tx->ref);
+      tx->ref =3D 0;
+   }
+#ifdef TPMFRONT_PRINT_DEBUG
+   TPMFRONT_DEBUG("Received response from backend size=3D%u", (unsigned
int) *length);
+   for(i =3D 0; i < *length; ++i) {
+      if(!(i % 30)) {
+     TPMFRONT_DEBUG_MORE("\n");
+      }
+      TPMFRONT_DEBUG_MORE("%02X ", (*msg)[i]);
+   }
+   TPMFRONT_DEBUG_MORE("\n");
+#endif
+#ifdef HAVE_LIBC
+   if(dev->fd >=3D 0) {
+      files[dev->fd].tpmfront.respgot =3D 1;
+   }
+#endif
+quit:
+   return 0;
+}
+
+int tpmfront_cmd(struct tpmfront_dev* dev, uint8_t* req, size_t reqlen,
uint8_t** resp, size_t* resplen)
+{
+   int rc;
+   if((rc =3D tpmfront_send(dev, req, reqlen))) {
+      return rc;
+   }
+   if((rc =3D tpmfront_recv(dev, resp, resplen))) {
+      return rc;
+   }
+
+   return 0;
+}
+
+#ifdef HAVE_LIBC
+#include <errno.h>
+int tpmfront_open(struct tpmfront_dev* dev)
+{
+   /* Silently prevent multiple opens */
+   if(dev->fd !=3D -1) {
+      return dev->fd;
+   }
+
+   dev->fd =3D alloc_fd(FTYPE_TPMFRONT);
+   printk("tpmfront_open(%s) -> %d\n", dev->nodename, dev->fd);
+   files[dev->fd].tpmfront.dev =3D dev;
+   files[dev->fd].tpmfront.offset =3D 0;
+   files[dev->fd].tpmfront.respgot =3D 0;
+   return dev->fd;
+}
+
+int tpmfront_posix_write(int fd, const uint8_t* buf, size_t count)
+{
+   int rc;
+   struct tpmfront_dev* dev;
+   dev =3D files[fd].tpmfront.dev;
+
+   if(count =3D=3D 0) {
+      return 0;
+   }
+
+   /* Return an error if we are already processing a command */
+   if(dev->waiting) {
+      errno =3D EINPROGRESS;
+      return -1;
+   }
+   /* Send the command now */
+   if((rc =3D tpmfront_send(dev, buf, count)) !=3D 0) {
+      errno =3D EIO;
+      return -1;
+   }
+   return count;
+}
+
+int tpmfront_posix_read(int fd, uint8_t* buf, size_t count)
+{
+   int rc;
+   uint8_t* dummybuf;
+   size_t dummysz;
+   struct tpmfront_dev* dev;
+
+   dev =3D files[fd].tpmfront.dev;
+
+   if(count =3D=3D 0) {
+      return 0;
+   }
+
+   /* get the response if we haven't already */
+   if(files[dev->fd].tpmfront.respgot =3D=3D 0) {
+      if ((rc =3D tpmfront_recv(dev, &dummybuf, &dummysz)) !=3D 0) {
+     errno =3D EIO;
+     return -1;
+      }
+   }
+
+   /* handle EOF case */
+   if(files[dev->fd].tpmfront.offset >=3D dev->resplen) {
+      return 0;
+   }
+
+   /* Compute the number of bytes and do the copy operation */
+   if((rc =3D min(count, dev->resplen - files[dev->fd].tpmfront.offset))=

!=3D 0) {
+      memcpy(buf, dev->respbuf + files[dev->fd].tpmfront.offset, rc);
+      files[dev->fd].tpmfront.offset +=3D rc;
+   }
+
+   return rc;
+}
+
+int tpmfront_posix_fstat(int fd, struct stat* buf)
+{
+   uint8_t* dummybuf;
+   size_t dummysz;
+   int rc;
+   struct tpmfront_dev* dev =3D files[fd].tpmfront.dev;
+
+   /* If we have a response waiting, then read it now from the backend
+    * so we can get its length*/
+   if(dev->waiting || (files[dev->fd].read =3D=3D 1 &&
!files[dev->fd].tpmfront.respgot)) {
+      if ((rc =3D tpmfront_recv(dev, &dummybuf, &dummysz)) !=3D 0) {
+     errno =3D EIO;
+     return -1;
+      }
+   }
+
+   buf->st_mode =3D O_RDWR;
+   buf->st_uid =3D 0;
+   buf->st_gid =3D 0;
+   buf->st_size =3D dev->resplen;
+   buf->st_atime =3D buf->st_mtime =3D buf->st_ctime =3D time(NULL);
+
+   return 0;
+}
+
+
+#endif
--=20
1.7.4.4



--------------ms000807020403040901070008
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIDyjCC
A8YwggMvoAMCAQICBD/xyf0wDQYJKoZIhvcNAQEFBQAwLzELMAkGA1UEBhMCVVMxDzANBgNV
BAoTBkpIVUFQTDEPMA0GA1UECxMGQklTRENBMB4XDTEwMDYxMTE4MjIwNloXDTEzMDYxMTE4
NTIwNlowZjELMAkGA1UEBhMCVVMxDzANBgNVBAoTBkpIVUFQTDEPMA0GA1UECxMGUGVvcGxl
MTUwFgYDVQQLEw9WUE5Hcm91cC1CSVNEQ0EwGwYDVQQDExRNYXR0aGV3IEUgRmlvcmF2YW50
ZTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAnpbwVSP6o1Nb5lcW7dd3yTo9iBJdi7qz
4nANOMFPK7JOy5npKN1iiousl28U/scUJES55gPwAWYJK3uVyQAsA4adgDKi5DoD1UHDQEwp
bY7iHLJeq0NPr4BqYNqnCFPbE6HC8zSJrr4qKn+gVUQT39SIFqdiIPJwZL8FYTRQ/zsCAwEA
AaOCAbYwggGyMAsGA1UdDwQEAwIHgDArBgNVHRAEJDAigA8yMDEwMDYxMTE4MjIwNlqBDzIw
MTIwNzE3MjI1MjA2WjAbBg0rBgEEAbMlCwMBAQEBBAoWCGZpb3JhbWUxMBsGDSsGAQQBsyUL
AwEBAQIEChIIMDAxMDQyNjEwWAYJYIZIAYb6ax4BBEsMSVRoZSBwcml2YXRlIGtleSBjb3Jy
ZXNwb25kaW5nIHRvIHRoaXMgY2VydGlmaWNhdGUgbWF5IGhhdmUgYmVlbiBleHBvcnRlZC4w
KAYDVR0RBCEwH4EdTWF0dGhldy5GaW9yYXZhbnRlQGpodWFwbC5lZHUwUgYDVR0fBEswSTBH
oEWgQ6RBMD8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJU0RD
QTEOMAwGA1UEAxMFQ1JMNTYwHwYDVR0jBBgwFoAUCDUpmxH52EU2CyWmF2EJMB1yqeswHQYD
VR0OBBYEFO6LYxg6r9wHZ+zdQtBHn1dZ/YTNMAkGA1UdEwQCMAAwGQYJKoZIhvZ9B0EABAww
ChsEVjcuMQMCBLAwDQYJKoZIhvcNAQEFBQADgYEAJO9HQh4YNChVLzuZqK5ARJARD8JoujGZ
fdo75quvg2jXFQe2sEjvLnxJZgm/pv8fdZakq48CWwjYHKuvIp7sDjTEsQfo+y7SpN/N2NvJ
WU5SqfK1VgYtNLRRoGJUB5Q1aZ+Dg95g3kqpyfpUMISJL8IKVLtJVfN4fggFVUYZ9wwxggGr
MIIBpwIBATA3MC8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJ
U0RDQQIEP/HJ/TAJBgUrDgMCGgUAoIHLMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ
KoZIhvcNAQkFMQ8XDTEyMDkxNzIyMDgxOVowIwYJKoZIhvcNAQkEMRYEFCDvhxuQEgNUeeUl
ajtCUA7B9EP9MGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAK
BggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI
KoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEgYBTWXnYBBP3DDaeaEjEniS+F1l4cND3Xhpn
VSDM42NXxjpxYsH7l/CZ/6r25411s/Svilj7Vd9i63+0x79J2g9iJtK4BqSsVOJP2dVavsBW
mCrcAsU61sRLRMa7KpxZeIaVdR35NPgJnmBASkssl+G1ypkSbAeQ/UyDZ2QI5+zpTQAAAAAA
AA==
--------------ms000807020403040901070008--


--===============1797525133642965968==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============1797525133642965968==--


From xen-devel-bounces@lists.xen.org Mon Sep 17 22:12:25 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 22: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 1TDjY7-0002RH-Dh; Mon, 17 Sep 2012 22:12:15 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <samuel.thibault@ens-lyon.org>) id 1TDjY5-0002RC-BT
	for xen-devel@lists.xensource.com; Mon, 17 Sep 2012 22:12:13 +0000
Received: from [85.158.137.99:15926] by server-1.bemta-3.messagelabs.com id
	A9/46-05884-C30A7505; Mon, 17 Sep 2012 22:12:12 +0000
X-Env-Sender: samuel.thibault@ens-lyon.org
X-Msg-Ref: server-6.tower-217.messagelabs.com!1347919931!12920769!1
X-Originating-IP: [140.77.166.68]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11998 invoked from network); 17 Sep 2012 22:12:12 -0000
Received: from toccata.ens-lyon.org (HELO toccata.ens-lyon.org) (140.77.166.68)
	by server-6.tower-217.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 17 Sep 2012 22:12:12 -0000
Received: from localhost (localhost [127.0.0.1])
	by toccata.ens-lyon.org (Postfix) with ESMTP id 3D40C84098;
	Tue, 18 Sep 2012 00:12:11 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at toccata.ens-lyon.org
Received: from toccata.ens-lyon.org ([127.0.0.1])
	by localhost (toccata.ens-lyon.org [127.0.0.1]) (amavisd-new,
	port 10024)
	with ESMTP id LLWuPUOVe+KQ; Tue, 18 Sep 2012 00:12:11 +0200 (CEST)
Received: from type.ipv6 (youpi.is-a-geek.org [80.67.176.89])
	(using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits))
	(No client certificate requested)
	by toccata.ens-lyon.org (Postfix) with ESMTPSA id E369184096;
	Tue, 18 Sep 2012 00:12:10 +0200 (CEST)
Received: from samy by type.ipv6 with local (Exim 4.80)
	(envelope-from <samuel.thibault@ens-lyon.org>)
	id 1TDjY1-0003sQ-Nw; Tue, 18 Sep 2012 00:12:09 +0200
Date: Tue, 18 Sep 2012 00:12:09 +0200
From: Samuel Thibault <samuel.thibault@ens-lyon.org>
To: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
Message-ID: <20120917221209.GH5110@type.youpi.perso.aquilenet.fr>
Mail-Followup-To: Samuel Thibault <samuel.thibault@ens-lyon.org>,
	Matthew Fioravante <matthew.fioravante@jhuapl.edu>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
References: <50579CB7.1010707@jhuapl.edu>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <50579CB7.1010707@jhuapl.edu>
User-Agent: Mutt/1.5.21+34 (58baf7c9f32f) (2010-12-30)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH mini-os enhancements for vtpm 3/8] add
 endian support to mini-os
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Matthew Fioravante, le Mon 17 Sep 2012 17:57:11 -0400, a =E9crit :
> diff --git a/extras/mini-os/include/byteorder.h
> b/extras/mini-os/include/byteorder.h
> --- /dev/null
> +++ b/extras/mini-os/include/byteorder.h

Ok.

> -static inline uint16_t bswap_16(uint16_t x)
> -{
> -    return
> -    ((((x) & 0xff00) >> 8) | (((x) & 0xff) << 8));
> -}
> -
> +#define bswap_16(x) ((uint16_t)(                         \
> +             (((uint16_t)(x) & (uint16_t)0x00ffU) << 8)
> |                  \
> +             (((uint16_t)(x) & (uint16_t)0xff00U) >> 8)))

Why replacing the inline with a macro?  AIUI, inlines provide the same
efficiency while providing some minimal type checking (and safety
against things like bswap_16(x++).

> diff --git a/extras/mini-os/include/endian.h
> diff --git a/extras/mini-os/include/ia64/arch_endian.h
> diff --git a/extras/mini-os/include/ia64/arch_wordsize.h
> diff --git a/extras/mini-os/include/x86/arch_endian.h
> diff --git a/extras/mini-os/include/x86/x86_32/arch_wordsize.h
> diff --git a/extras/mini-os/include/x86/x86_64/arch_wordsize.h

Ok.

Samuel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 17 22:12:25 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 22: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 1TDjY7-0002RH-Dh; Mon, 17 Sep 2012 22:12:15 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <samuel.thibault@ens-lyon.org>) id 1TDjY5-0002RC-BT
	for xen-devel@lists.xensource.com; Mon, 17 Sep 2012 22:12:13 +0000
Received: from [85.158.137.99:15926] by server-1.bemta-3.messagelabs.com id
	A9/46-05884-C30A7505; Mon, 17 Sep 2012 22:12:12 +0000
X-Env-Sender: samuel.thibault@ens-lyon.org
X-Msg-Ref: server-6.tower-217.messagelabs.com!1347919931!12920769!1
X-Originating-IP: [140.77.166.68]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11998 invoked from network); 17 Sep 2012 22:12:12 -0000
Received: from toccata.ens-lyon.org (HELO toccata.ens-lyon.org) (140.77.166.68)
	by server-6.tower-217.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 17 Sep 2012 22:12:12 -0000
Received: from localhost (localhost [127.0.0.1])
	by toccata.ens-lyon.org (Postfix) with ESMTP id 3D40C84098;
	Tue, 18 Sep 2012 00:12:11 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at toccata.ens-lyon.org
Received: from toccata.ens-lyon.org ([127.0.0.1])
	by localhost (toccata.ens-lyon.org [127.0.0.1]) (amavisd-new,
	port 10024)
	with ESMTP id LLWuPUOVe+KQ; Tue, 18 Sep 2012 00:12:11 +0200 (CEST)
Received: from type.ipv6 (youpi.is-a-geek.org [80.67.176.89])
	(using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits))
	(No client certificate requested)
	by toccata.ens-lyon.org (Postfix) with ESMTPSA id E369184096;
	Tue, 18 Sep 2012 00:12:10 +0200 (CEST)
Received: from samy by type.ipv6 with local (Exim 4.80)
	(envelope-from <samuel.thibault@ens-lyon.org>)
	id 1TDjY1-0003sQ-Nw; Tue, 18 Sep 2012 00:12:09 +0200
Date: Tue, 18 Sep 2012 00:12:09 +0200
From: Samuel Thibault <samuel.thibault@ens-lyon.org>
To: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
Message-ID: <20120917221209.GH5110@type.youpi.perso.aquilenet.fr>
Mail-Followup-To: Samuel Thibault <samuel.thibault@ens-lyon.org>,
	Matthew Fioravante <matthew.fioravante@jhuapl.edu>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
References: <50579CB7.1010707@jhuapl.edu>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <50579CB7.1010707@jhuapl.edu>
User-Agent: Mutt/1.5.21+34 (58baf7c9f32f) (2010-12-30)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH mini-os enhancements for vtpm 3/8] add
 endian support to mini-os
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Matthew Fioravante, le Mon 17 Sep 2012 17:57:11 -0400, a =E9crit :
> diff --git a/extras/mini-os/include/byteorder.h
> b/extras/mini-os/include/byteorder.h
> --- /dev/null
> +++ b/extras/mini-os/include/byteorder.h

Ok.

> -static inline uint16_t bswap_16(uint16_t x)
> -{
> -    return
> -    ((((x) & 0xff00) >> 8) | (((x) & 0xff) << 8));
> -}
> -
> +#define bswap_16(x) ((uint16_t)(                         \
> +             (((uint16_t)(x) & (uint16_t)0x00ffU) << 8)
> |                  \
> +             (((uint16_t)(x) & (uint16_t)0xff00U) >> 8)))

Why replacing the inline with a macro?  AIUI, inlines provide the same
efficiency while providing some minimal type checking (and safety
against things like bswap_16(x++).

> diff --git a/extras/mini-os/include/endian.h
> diff --git a/extras/mini-os/include/ia64/arch_endian.h
> diff --git a/extras/mini-os/include/ia64/arch_wordsize.h
> diff --git a/extras/mini-os/include/x86/arch_endian.h
> diff --git a/extras/mini-os/include/x86/x86_32/arch_wordsize.h
> diff --git a/extras/mini-os/include/x86/x86_64/arch_wordsize.h

Ok.

Samuel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 17 22:14:10 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 22: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 1TDjZo-0002Xy-UA; Mon, 17 Sep 2012 22:14:00 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <samuel.thibault@ens-lyon.org>) id 1TDjZn-0002Xt-JM
	for xen-devel@lists.xensource.com; Mon, 17 Sep 2012 22:13:59 +0000
Received: from [85.158.137.99:22548] by server-12.bemta-3.messagelabs.com id
	79/20-10384-6A0A7505; Mon, 17 Sep 2012 22:13:58 +0000
X-Env-Sender: samuel.thibault@ens-lyon.org
X-Msg-Ref: server-9.tower-217.messagelabs.com!1347920037!14891753!1
X-Originating-IP: [140.77.166.68]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22059 invoked from network); 17 Sep 2012 22:13:58 -0000
Received: from toccata.ens-lyon.fr (HELO toccata.ens-lyon.org) (140.77.166.68)
	by server-9.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 17 Sep 2012 22:13:58 -0000
Received: from localhost (localhost [127.0.0.1])
	by toccata.ens-lyon.org (Postfix) with ESMTP id DAFF584098;
	Tue, 18 Sep 2012 00:13:57 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at toccata.ens-lyon.org
Received: from toccata.ens-lyon.org ([127.0.0.1])
	by localhost (toccata.ens-lyon.org [127.0.0.1]) (amavisd-new,
	port 10024)
	with ESMTP id its+0KzwUKcl; Tue, 18 Sep 2012 00:13:57 +0200 (CEST)
Received: from type.ipv6 (youpi.is-a-geek.org [80.67.176.89])
	(using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits))
	(No client certificate requested)
	by toccata.ens-lyon.org (Postfix) with ESMTPSA id 9A7D584096;
	Tue, 18 Sep 2012 00:13:57 +0200 (CEST)
Received: from samy by type.ipv6 with local (Exim 4.80)
	(envelope-from <samuel.thibault@ens-lyon.org>)
	id 1TDjZk-0003vk-HJ; Tue, 18 Sep 2012 00:13:56 +0200
Date: Tue, 18 Sep 2012 00:13:56 +0200
From: Samuel Thibault <samuel.thibault@ens-lyon.org>
To: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
Message-ID: <20120917221356.GI5110@type.youpi.perso.aquilenet.fr>
Mail-Followup-To: Samuel Thibault <samuel.thibault@ens-lyon.org>,
	Matthew Fioravante <matthew.fioravante@jhuapl.edu>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
References: <50579D07.3030007@jhuapl.edu>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <50579D07.3030007@jhuapl.edu>
User-Agent: Mutt/1.5.21+34 (58baf7c9f32f) (2010-12-30)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH mini-os enhancements for vtpm 4/8] disable
	mfn_is_ram
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Matthew Fioravante, le Mon 17 Sep 2012 17:58:31 -0400, a =E9crit :
> This patch disables the mfn_is_ram check in mini-os. The current check
> is insufficient and fails on some systems with larger than 4gb memory.

And it is only used for checks, not for actual decisions.

Acked-by: Samuel Thibault <samuel.thibault@ens-lyon.org>

Samuel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 17 22:14:10 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 22: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 1TDjZo-0002Xy-UA; Mon, 17 Sep 2012 22:14:00 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <samuel.thibault@ens-lyon.org>) id 1TDjZn-0002Xt-JM
	for xen-devel@lists.xensource.com; Mon, 17 Sep 2012 22:13:59 +0000
Received: from [85.158.137.99:22548] by server-12.bemta-3.messagelabs.com id
	79/20-10384-6A0A7505; Mon, 17 Sep 2012 22:13:58 +0000
X-Env-Sender: samuel.thibault@ens-lyon.org
X-Msg-Ref: server-9.tower-217.messagelabs.com!1347920037!14891753!1
X-Originating-IP: [140.77.166.68]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22059 invoked from network); 17 Sep 2012 22:13:58 -0000
Received: from toccata.ens-lyon.fr (HELO toccata.ens-lyon.org) (140.77.166.68)
	by server-9.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 17 Sep 2012 22:13:58 -0000
Received: from localhost (localhost [127.0.0.1])
	by toccata.ens-lyon.org (Postfix) with ESMTP id DAFF584098;
	Tue, 18 Sep 2012 00:13:57 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at toccata.ens-lyon.org
Received: from toccata.ens-lyon.org ([127.0.0.1])
	by localhost (toccata.ens-lyon.org [127.0.0.1]) (amavisd-new,
	port 10024)
	with ESMTP id its+0KzwUKcl; Tue, 18 Sep 2012 00:13:57 +0200 (CEST)
Received: from type.ipv6 (youpi.is-a-geek.org [80.67.176.89])
	(using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits))
	(No client certificate requested)
	by toccata.ens-lyon.org (Postfix) with ESMTPSA id 9A7D584096;
	Tue, 18 Sep 2012 00:13:57 +0200 (CEST)
Received: from samy by type.ipv6 with local (Exim 4.80)
	(envelope-from <samuel.thibault@ens-lyon.org>)
	id 1TDjZk-0003vk-HJ; Tue, 18 Sep 2012 00:13:56 +0200
Date: Tue, 18 Sep 2012 00:13:56 +0200
From: Samuel Thibault <samuel.thibault@ens-lyon.org>
To: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
Message-ID: <20120917221356.GI5110@type.youpi.perso.aquilenet.fr>
Mail-Followup-To: Samuel Thibault <samuel.thibault@ens-lyon.org>,
	Matthew Fioravante <matthew.fioravante@jhuapl.edu>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
References: <50579D07.3030007@jhuapl.edu>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <50579D07.3030007@jhuapl.edu>
User-Agent: Mutt/1.5.21+34 (58baf7c9f32f) (2010-12-30)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH mini-os enhancements for vtpm 4/8] disable
	mfn_is_ram
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Matthew Fioravante, le Mon 17 Sep 2012 17:58:31 -0400, a =E9crit :
> This patch disables the mfn_is_ram check in mini-os. The current check
> is insufficient and fails on some systems with larger than 4gb memory.

And it is only used for checks, not for actual decisions.

Acked-by: Samuel Thibault <samuel.thibault@ens-lyon.org>

Samuel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 17 22:17:29 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 22: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 1TDjd2-0002kh-IN; Mon, 17 Sep 2012 22:17:20 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <samuel.thibault@ens-lyon.org>) id 1TDjd1-0002kZ-4r
	for xen-devel@lists.xensource.com; Mon, 17 Sep 2012 22:17:19 +0000
Received: from [85.158.143.99:53187] by server-2.bemta-4.messagelabs.com id
	92/EE-06610-E61A7505; Mon, 17 Sep 2012 22:17:18 +0000
X-Env-Sender: samuel.thibault@ens-lyon.org
X-Msg-Ref: server-4.tower-216.messagelabs.com!1347920237!25444570!1
X-Originating-IP: [140.77.166.68]
X-SpamReason: No, hits=0.0 required=7.0 tests=UPPERCASE_25_50
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4096 invoked from network); 17 Sep 2012 22:17:17 -0000
Received: from toccata.ens-lyon.org (HELO toccata.ens-lyon.org) (140.77.166.68)
	by server-4.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 17 Sep 2012 22:17:17 -0000
Received: from localhost (localhost [127.0.0.1])
	by toccata.ens-lyon.org (Postfix) with ESMTP id C109784095;
	Tue, 18 Sep 2012 00:17:16 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at toccata.ens-lyon.org
Received: from toccata.ens-lyon.org ([127.0.0.1])
	by localhost (toccata.ens-lyon.org [127.0.0.1]) (amavisd-new,
	port 10024)
	with ESMTP id vSGQvYx1RygW; Tue, 18 Sep 2012 00:17:16 +0200 (CEST)
Received: from type.ipv6 (youpi.is-a-geek.org [80.67.176.89])
	(using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits))
	(No client certificate requested)
	by toccata.ens-lyon.org (Postfix) with ESMTPSA id 7A8B884081;
	Tue, 18 Sep 2012 00:17:16 +0200 (CEST)
Received: from samy by type.ipv6 with local (Exim 4.80)
	(envelope-from <samuel.thibault@ens-lyon.org>)
	id 1TDjcx-00041q-Bl; Tue, 18 Sep 2012 00:17:15 +0200
Date: Tue, 18 Sep 2012 00:17:15 +0200
From: Samuel Thibault <samuel.thibault@ens-lyon.org>
To: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
Message-ID: <20120917221715.GJ5110@type.youpi.perso.aquilenet.fr>
Mail-Followup-To: Samuel Thibault <samuel.thibault@ens-lyon.org>,
	Matthew Fioravante <matthew.fioravante@jhuapl.edu>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
References: <50579D7F.7030100@jhuapl.edu>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <50579D7F.7030100@jhuapl.edu>
User-Agent: Mutt/1.5.21+34 (58baf7c9f32f) (2010-12-30)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH mini-os enhancements for vtpm 5/8] add
 CONFIG_XC to mini-os
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Matthew Fioravante, le Mon 17 Sep 2012 18:00:31 -0400, a =E9crit :
> diff --git a/extras/mini-os/Makefile b/extras/mini-os/Makefile
> --- a/extras/mini-os/Makefile
> +++ b/extras/mini-os/Makefile
> @@ -27,6 +27,7 @@ CONFIG_FBFRONT ?=3D y
>  CONFIG_KBDFRONT ?=3D y
>  CONFIG_CONSFRONT ?=3D y
>  CONFIG_XENBUS ?=3D y
> +CONFIG_XC ?=3Dy
>  CONFIG_LWIP ?=3D $(lwip)
>  =

>  # Export config items as compiler directives

Maybe it'd be safer to also disable =


APP_LDLIBS +=3D -L$(XEN_ROOT)/stubdom/libxc-$(XEN_TARGET_ARCH) -whole-archi=
ve -lxenguest -lxenctrl -no-whole-archive

in that case?

Apart from that,

Acked-by: Samuel Thibault <samuel.thibault@ens-lyon.org>

Samuel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 17 22:17:29 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 22: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 1TDjd2-0002kh-IN; Mon, 17 Sep 2012 22:17:20 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <samuel.thibault@ens-lyon.org>) id 1TDjd1-0002kZ-4r
	for xen-devel@lists.xensource.com; Mon, 17 Sep 2012 22:17:19 +0000
Received: from [85.158.143.99:53187] by server-2.bemta-4.messagelabs.com id
	92/EE-06610-E61A7505; Mon, 17 Sep 2012 22:17:18 +0000
X-Env-Sender: samuel.thibault@ens-lyon.org
X-Msg-Ref: server-4.tower-216.messagelabs.com!1347920237!25444570!1
X-Originating-IP: [140.77.166.68]
X-SpamReason: No, hits=0.0 required=7.0 tests=UPPERCASE_25_50
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4096 invoked from network); 17 Sep 2012 22:17:17 -0000
Received: from toccata.ens-lyon.org (HELO toccata.ens-lyon.org) (140.77.166.68)
	by server-4.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 17 Sep 2012 22:17:17 -0000
Received: from localhost (localhost [127.0.0.1])
	by toccata.ens-lyon.org (Postfix) with ESMTP id C109784095;
	Tue, 18 Sep 2012 00:17:16 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at toccata.ens-lyon.org
Received: from toccata.ens-lyon.org ([127.0.0.1])
	by localhost (toccata.ens-lyon.org [127.0.0.1]) (amavisd-new,
	port 10024)
	with ESMTP id vSGQvYx1RygW; Tue, 18 Sep 2012 00:17:16 +0200 (CEST)
Received: from type.ipv6 (youpi.is-a-geek.org [80.67.176.89])
	(using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits))
	(No client certificate requested)
	by toccata.ens-lyon.org (Postfix) with ESMTPSA id 7A8B884081;
	Tue, 18 Sep 2012 00:17:16 +0200 (CEST)
Received: from samy by type.ipv6 with local (Exim 4.80)
	(envelope-from <samuel.thibault@ens-lyon.org>)
	id 1TDjcx-00041q-Bl; Tue, 18 Sep 2012 00:17:15 +0200
Date: Tue, 18 Sep 2012 00:17:15 +0200
From: Samuel Thibault <samuel.thibault@ens-lyon.org>
To: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
Message-ID: <20120917221715.GJ5110@type.youpi.perso.aquilenet.fr>
Mail-Followup-To: Samuel Thibault <samuel.thibault@ens-lyon.org>,
	Matthew Fioravante <matthew.fioravante@jhuapl.edu>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
References: <50579D7F.7030100@jhuapl.edu>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <50579D7F.7030100@jhuapl.edu>
User-Agent: Mutt/1.5.21+34 (58baf7c9f32f) (2010-12-30)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH mini-os enhancements for vtpm 5/8] add
 CONFIG_XC to mini-os
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Matthew Fioravante, le Mon 17 Sep 2012 18:00:31 -0400, a =E9crit :
> diff --git a/extras/mini-os/Makefile b/extras/mini-os/Makefile
> --- a/extras/mini-os/Makefile
> +++ b/extras/mini-os/Makefile
> @@ -27,6 +27,7 @@ CONFIG_FBFRONT ?=3D y
>  CONFIG_KBDFRONT ?=3D y
>  CONFIG_CONSFRONT ?=3D y
>  CONFIG_XENBUS ?=3D y
> +CONFIG_XC ?=3Dy
>  CONFIG_LWIP ?=3D $(lwip)
>  =

>  # Export config items as compiler directives

Maybe it'd be safer to also disable =


APP_LDLIBS +=3D -L$(XEN_ROOT)/stubdom/libxc-$(XEN_TARGET_ARCH) -whole-archi=
ve -lxenguest -lxenctrl -no-whole-archive

in that case?

Apart from that,

Acked-by: Samuel Thibault <samuel.thibault@ens-lyon.org>

Samuel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 17 22:18:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 22:18: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 1TDjdx-0002pl-0j; Mon, 17 Sep 2012 22:18:17 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <samuel.thibault@ens-lyon.org>) id 1TDjdv-0002pY-JR
	for xen-devel@lists.xensource.com; Mon, 17 Sep 2012 22:18:15 +0000
Received: from [85.158.138.51:53920] by server-3.bemta-3.messagelabs.com id
	10/B0-21322-6A1A7505; Mon, 17 Sep 2012 22:18:14 +0000
X-Env-Sender: samuel.thibault@ens-lyon.org
X-Msg-Ref: server-11.tower-174.messagelabs.com!1347920293!30914759!1
X-Originating-IP: [140.77.166.68]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11191 invoked from network); 17 Sep 2012 22:18:14 -0000
Received: from toccata.ens-lyon.org (HELO toccata.ens-lyon.org) (140.77.166.68)
	by server-11.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 17 Sep 2012 22:18:14 -0000
Received: from localhost (localhost [127.0.0.1])
	by toccata.ens-lyon.org (Postfix) with ESMTP id DD9DF84095;
	Tue, 18 Sep 2012 00:18:12 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at toccata.ens-lyon.org
Received: from toccata.ens-lyon.org ([127.0.0.1])
	by localhost (toccata.ens-lyon.org [127.0.0.1]) (amavisd-new,
	port 10024)
	with ESMTP id S3LSD9WDjDEn; Tue, 18 Sep 2012 00:18:12 +0200 (CEST)
Received: from type.ipv6 (youpi.is-a-geek.org [80.67.176.89])
	(using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits))
	(No client certificate requested)
	by toccata.ens-lyon.org (Postfix) with ESMTPSA id 8747084081;
	Tue, 18 Sep 2012 00:18:12 +0200 (CEST)
Received: from samy by type.ipv6 with local (Exim 4.80)
	(envelope-from <samuel.thibault@ens-lyon.org>)
	id 1TDjdr-00042f-C9; Tue, 18 Sep 2012 00:18:11 +0200
Date: Tue, 18 Sep 2012 00:18:11 +0200
From: Samuel Thibault <samuel.thibault@ens-lyon.org>
To: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
Message-ID: <20120917221811.GL5110@type.youpi.perso.aquilenet.fr>
Mail-Followup-To: Samuel Thibault <samuel.thibault@ens-lyon.org>,
	Matthew Fioravante <matthew.fioravante@jhuapl.edu>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
References: <50579E1C.2000701@jhuapl.edu>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <50579E1C.2000701@jhuapl.edu>
User-Agent: Mutt/1.5.21+34 (58baf7c9f32f) (2010-12-30)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH mini-os enhancements for vtpm 6/8] add
 select() to sys/time.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="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Matthew Fioravante, le Mon 17 Sep 2012 18:03:08 -0400, a =E9crit :
> This patch adds the select function to sys/time.h when HAVE_LIBC is
> defined, which is according to standard. (see the select() manpage)
> =

> =

> Signed of by: Matthew Fioravante matthew.fioravante@jhuapl.edu

Acked-by: Samuel Thibault <samuel.thibault@ens-lyon.org>

Samuel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 17 22:18:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 22:18: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 1TDjdx-0002pl-0j; Mon, 17 Sep 2012 22:18:17 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <samuel.thibault@ens-lyon.org>) id 1TDjdv-0002pY-JR
	for xen-devel@lists.xensource.com; Mon, 17 Sep 2012 22:18:15 +0000
Received: from [85.158.138.51:53920] by server-3.bemta-3.messagelabs.com id
	10/B0-21322-6A1A7505; Mon, 17 Sep 2012 22:18:14 +0000
X-Env-Sender: samuel.thibault@ens-lyon.org
X-Msg-Ref: server-11.tower-174.messagelabs.com!1347920293!30914759!1
X-Originating-IP: [140.77.166.68]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11191 invoked from network); 17 Sep 2012 22:18:14 -0000
Received: from toccata.ens-lyon.org (HELO toccata.ens-lyon.org) (140.77.166.68)
	by server-11.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 17 Sep 2012 22:18:14 -0000
Received: from localhost (localhost [127.0.0.1])
	by toccata.ens-lyon.org (Postfix) with ESMTP id DD9DF84095;
	Tue, 18 Sep 2012 00:18:12 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at toccata.ens-lyon.org
Received: from toccata.ens-lyon.org ([127.0.0.1])
	by localhost (toccata.ens-lyon.org [127.0.0.1]) (amavisd-new,
	port 10024)
	with ESMTP id S3LSD9WDjDEn; Tue, 18 Sep 2012 00:18:12 +0200 (CEST)
Received: from type.ipv6 (youpi.is-a-geek.org [80.67.176.89])
	(using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits))
	(No client certificate requested)
	by toccata.ens-lyon.org (Postfix) with ESMTPSA id 8747084081;
	Tue, 18 Sep 2012 00:18:12 +0200 (CEST)
Received: from samy by type.ipv6 with local (Exim 4.80)
	(envelope-from <samuel.thibault@ens-lyon.org>)
	id 1TDjdr-00042f-C9; Tue, 18 Sep 2012 00:18:11 +0200
Date: Tue, 18 Sep 2012 00:18:11 +0200
From: Samuel Thibault <samuel.thibault@ens-lyon.org>
To: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
Message-ID: <20120917221811.GL5110@type.youpi.perso.aquilenet.fr>
Mail-Followup-To: Samuel Thibault <samuel.thibault@ens-lyon.org>,
	Matthew Fioravante <matthew.fioravante@jhuapl.edu>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
References: <50579E1C.2000701@jhuapl.edu>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <50579E1C.2000701@jhuapl.edu>
User-Agent: Mutt/1.5.21+34 (58baf7c9f32f) (2010-12-30)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH mini-os enhancements for vtpm 6/8] add
 select() to sys/time.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="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Matthew Fioravante, le Mon 17 Sep 2012 18:03:08 -0400, a =E9crit :
> This patch adds the select function to sys/time.h when HAVE_LIBC is
> defined, which is according to standard. (see the select() manpage)
> =

> =

> Signed of by: Matthew Fioravante matthew.fioravante@jhuapl.edu

Acked-by: Samuel Thibault <samuel.thibault@ens-lyon.org>

Samuel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 17 22:20:50 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 22:20:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDjgH-0002zm-II; Mon, 17 Sep 2012 22:20:41 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <samuel.thibault@ens-lyon.org>) id 1TDjgG-0002ze-9p
	for xen-devel@lists.xensource.com; Mon, 17 Sep 2012 22:20:40 +0000
Received: from [85.158.143.99:58149] by server-3.bemta-4.messagelabs.com id
	95/92-08232-732A7505; Mon, 17 Sep 2012 22:20:39 +0000
X-Env-Sender: samuel.thibault@ens-lyon.org
X-Msg-Ref: server-2.tower-216.messagelabs.com!1347920438!22535277!1
X-Originating-IP: [140.77.166.68]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15023 invoked from network); 17 Sep 2012 22:20:39 -0000
Received: from toccata.ens-lyon.fr (HELO toccata.ens-lyon.org) (140.77.166.68)
	by server-2.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 17 Sep 2012 22:20:39 -0000
Received: from localhost (localhost [127.0.0.1])
	by toccata.ens-lyon.org (Postfix) with ESMTP id B139684095;
	Tue, 18 Sep 2012 00:20:38 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at toccata.ens-lyon.org
Received: from toccata.ens-lyon.org ([127.0.0.1])
	by localhost (toccata.ens-lyon.org [127.0.0.1]) (amavisd-new,
	port 10024)
	with ESMTP id vY1nN3Pe0jDY; Tue, 18 Sep 2012 00:20:38 +0200 (CEST)
Received: from type.ipv6 (youpi.is-a-geek.org [80.67.176.89])
	(using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits))
	(No client certificate requested)
	by toccata.ens-lyon.org (Postfix) with ESMTPSA id 6D70D84081;
	Tue, 18 Sep 2012 00:20:38 +0200 (CEST)
Received: from samy by type.ipv6 with local (Exim 4.80)
	(envelope-from <samuel.thibault@ens-lyon.org>)
	id 1TDjgD-00045V-83; Tue, 18 Sep 2012 00:20:37 +0200
Date: Tue, 18 Sep 2012 00:20:37 +0200
From: Samuel Thibault <samuel.thibault@ens-lyon.org>
To: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
Message-ID: <20120917222037.GM5110@type.youpi.perso.aquilenet.fr>
Mail-Followup-To: Samuel Thibault <samuel.thibault@ens-lyon.org>,
	Matthew Fioravante <matthew.fioravante@jhuapl.edu>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
References: <50579E7F.1050803@jhuapl.edu>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <50579E7F.1050803@jhuapl.edu>
User-Agent: Mutt/1.5.21+34 (58baf7c9f32f) (2010-12-30)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH mini-os enhancements for vtpm 7/8] add
 floating point and sse to mini-os
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Matthew Fioravante, le Mon 17 Sep 2012 18:04:47 -0400, a =E9crit :
> This patch adds floating point and sse support to mini-os by
> initializing the floating point unit and the see unit during domain boot =
up.
> =

> =

> Signed of by: Matthew Fioravante matthew.fioravante@jhuapl.edu

I don't remember: does xen support optimizing out FPU context switch
when a domain does not use the FPU?  It might be useful to make FPU
initialization optional in that case, to keep context switch faster.
Apart from that,

Acked-by: Samuel Thibault <samuel.thibault@ens-lyon.org>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 17 22:20:50 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 22:20:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDjgH-0002zm-II; Mon, 17 Sep 2012 22:20:41 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <samuel.thibault@ens-lyon.org>) id 1TDjgG-0002ze-9p
	for xen-devel@lists.xensource.com; Mon, 17 Sep 2012 22:20:40 +0000
Received: from [85.158.143.99:58149] by server-3.bemta-4.messagelabs.com id
	95/92-08232-732A7505; Mon, 17 Sep 2012 22:20:39 +0000
X-Env-Sender: samuel.thibault@ens-lyon.org
X-Msg-Ref: server-2.tower-216.messagelabs.com!1347920438!22535277!1
X-Originating-IP: [140.77.166.68]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15023 invoked from network); 17 Sep 2012 22:20:39 -0000
Received: from toccata.ens-lyon.fr (HELO toccata.ens-lyon.org) (140.77.166.68)
	by server-2.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 17 Sep 2012 22:20:39 -0000
Received: from localhost (localhost [127.0.0.1])
	by toccata.ens-lyon.org (Postfix) with ESMTP id B139684095;
	Tue, 18 Sep 2012 00:20:38 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at toccata.ens-lyon.org
Received: from toccata.ens-lyon.org ([127.0.0.1])
	by localhost (toccata.ens-lyon.org [127.0.0.1]) (amavisd-new,
	port 10024)
	with ESMTP id vY1nN3Pe0jDY; Tue, 18 Sep 2012 00:20:38 +0200 (CEST)
Received: from type.ipv6 (youpi.is-a-geek.org [80.67.176.89])
	(using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits))
	(No client certificate requested)
	by toccata.ens-lyon.org (Postfix) with ESMTPSA id 6D70D84081;
	Tue, 18 Sep 2012 00:20:38 +0200 (CEST)
Received: from samy by type.ipv6 with local (Exim 4.80)
	(envelope-from <samuel.thibault@ens-lyon.org>)
	id 1TDjgD-00045V-83; Tue, 18 Sep 2012 00:20:37 +0200
Date: Tue, 18 Sep 2012 00:20:37 +0200
From: Samuel Thibault <samuel.thibault@ens-lyon.org>
To: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
Message-ID: <20120917222037.GM5110@type.youpi.perso.aquilenet.fr>
Mail-Followup-To: Samuel Thibault <samuel.thibault@ens-lyon.org>,
	Matthew Fioravante <matthew.fioravante@jhuapl.edu>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
References: <50579E7F.1050803@jhuapl.edu>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <50579E7F.1050803@jhuapl.edu>
User-Agent: Mutt/1.5.21+34 (58baf7c9f32f) (2010-12-30)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH mini-os enhancements for vtpm 7/8] add
 floating point and sse to mini-os
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Matthew Fioravante, le Mon 17 Sep 2012 18:04:47 -0400, a =E9crit :
> This patch adds floating point and sse support to mini-os by
> initializing the floating point unit and the see unit during domain boot =
up.
> =

> =

> Signed of by: Matthew Fioravante matthew.fioravante@jhuapl.edu

I don't remember: does xen support optimizing out FPU context switch
when a domain does not use the FPU?  It might be useful to make FPU
initialization optional in that case, to keep context switch faster.
Apart from that,

Acked-by: Samuel Thibault <samuel.thibault@ens-lyon.org>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 17 22:21:48 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 22:21:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDjhB-00036M-0A; Mon, 17 Sep 2012 22:21:37 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dan.magenheimer@oracle.com>) id 1TDjhA-00035t-C2
	for xen-devel@lists.xen.org; Mon, 17 Sep 2012 22:21:36 +0000
X-Env-Sender: dan.magenheimer@oracle.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1347920487!7977790!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDc1NTA4Mg==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27590 invoked from network); 17 Sep 2012 22:21:29 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-5.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 17 Sep 2012 22:21: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 q8HMLOiZ016925
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 17 Sep 2012 22:21:25 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q8HMLOLj022123
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 17 Sep 2012 22:21:24 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
	q8HMLL0c021816; Mon, 17 Sep 2012 17:21:21 -0500
MIME-Version: 1.0
Message-ID: <782ba841-7dcc-4343-a12a-d3e2fc33792f@default>
Date: Mon, 17 Sep 2012 15:21:18 -0700 (PDT)
From: Dan Magenheimer <dan.magenheimer@oracle.com>
To: Zhenzhong Duan <zhenzhong.duan@oracle.com>, Jan Beulich <JBeulich@suse.com>
References: <504764270200007800098DE1@nat28.tlf.novell.com>
	<504A01790200007800099C52@nat28.tlf.novell.com>
	<504F1412020000780009A750@nat28.tlf.novell.com>
	<504F01D6.3050903@oracle.com>
	<504F23B2020000780009A79B@nat28.tlf.novell.com>
	<504F0C0C.6020804@oracle.com>
	<504F2DD8020000780009A85B@nat28.tlf.novell.com>
	<504F26F0.20600@oracle.com>
In-Reply-To: <504F26F0.20600@oracle.com>
X-Priority: 3
X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.7  (607090) [OL
	12.0.6661.5003 (x86)]
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: Ian Campbell <ian.campbell@citrix.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Ping: [PATCH 09/11,
	v2] tmem: reduce severity of log messages
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

PiBGcm9tOiB6aGVuemhvbmcuZHVhbgo+IFNlbnQ6IFR1ZXNkYXksIFNlcHRlbWJlciAxMSwgMjAx
MiA1OjU3IEFNCj4gVG86IEphbiBCZXVsaWNoCj4gQ2M6IElhbiBDYW1wYmVsbDsgeGVuLWRldmVs
OyBEYW4gTWFnZW5oZWltZXIKPiBTdWJqZWN0OiBSZTogUGluZzogW1BBVENIIDA5LzExLCB2Ml0g
dG1lbTogcmVkdWNlIHNldmVyaXR5IG9mIGxvZyBtZXNzYWdlcwo+IAo+IAo+IAo+IOS6jiAyMDEy
LTA5LTExIDE4OjI2LCBKYW4gQmV1bGljaCDlhpnpgZM6Cj4gPj4+PiBPbiAxMS4wOS4xMiBhdCAx
MjowMSwgRHVhblpoZW56aG9uZzx6aGVuemhvbmcuZHVhbkBvcmFjbGUuY29tPiAgd3JvdGU6Cj4g
Pj4gSmFuIEJldWxpY2ggd3JvdGU6Cj4gPj4+Pj4+IE9uIDExLjA5LjEyIGF0IDExOjE4LCBEdWFu
Wmhlbnpob25nPHpoZW56aG9uZy5kdWFuQG9yYWNsZS5jb20+ICB3cm90ZToKPiA+Pj4+Pj4KPiA+
Pj4+IERhbiBpcyBvZmZsaW5lIHJlY2VudGx5Lgo+ID4+Pj4gV2hhdCBhYm91dCAncHJpbnRrKCJ0
bWVtX3JlbGlucXVpc2hfcGFnZTogZmFpbGluZyBvcmRlcj0lZFxuIiwgb3JkZXIpJywKPiA+Pj4+
IG1vcmUgbGlrZSBhICBndWVzdCBsZXZlbCBtc2cuCj4gPj4+Pgo+ID4+PiBUaGF0J3MgZGViYXRh
YmxlLCBidXQgdGhlIG1lc3NhZ2UgaXMgZW5hYmxlZCBmb3IgZGVidWcgYnVpbGRzCj4gPj4+IG9u
bHkgYW55d2F5LiBDb3VsZCBiZSBtYWtlIFhFTkxPR19ERUJVRywgYnV0IHRoYXQgd291bGQKPiA+
Pj4gcmVxdWlyZSB5ZXQgYW5vdGhlciBoZWxwZXIgaW4gdG1lbV94ZW4uaC4gSSdkIHdhbnQgdG8g
bGVhdmUKPiA+Pj4gdGhpcyBhbG9uZSBmb3IgdGhlIG1vbWVudC4KPiA+PiBPay4KPiA+PiB6ZHVh
bgo+ID4gSXMgdGhhdCBhbiBhY2sgb24gdGhlIHBhdGNoIHRoZW4/Cj4gSG9wZSBEYW4gZG9uJ3Qg
aGF2ZSBvdGhlciBzdWdnZXN0aW9uLgo+IAo+IEFja2VkLWJ5OiBaaGVuemhvbmcgRHVhbiA8emhl
bnpob25nLmR1YW5Ab3JhY2xlLmNvbT4KCkxvb2tzIGdvb2QgdG8gbWUgdG9vLgoKQWNrZWQtYnk6
IERhbiBNYWdlbmhlaW1lciA8ZGFuLm1hZ2VuaGVpbWVyQG9yYWNsZS5jb20+CgpfX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpYZW4tZGV2ZWwgbWFpbGluZyBs
aXN0Clhlbi1kZXZlbEBsaXN0cy54ZW4ub3JnCmh0dHA6Ly9saXN0cy54ZW4ub3JnL3hlbi1kZXZl
bAo=

From xen-devel-bounces@lists.xen.org Mon Sep 17 22:21:48 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 22:21:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDjhB-00036M-0A; Mon, 17 Sep 2012 22:21:37 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dan.magenheimer@oracle.com>) id 1TDjhA-00035t-C2
	for xen-devel@lists.xen.org; Mon, 17 Sep 2012 22:21:36 +0000
X-Env-Sender: dan.magenheimer@oracle.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1347920487!7977790!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDc1NTA4Mg==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27590 invoked from network); 17 Sep 2012 22:21:29 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-5.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 17 Sep 2012 22:21: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 q8HMLOiZ016925
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 17 Sep 2012 22:21:25 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q8HMLOLj022123
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 17 Sep 2012 22:21:24 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
	q8HMLL0c021816; Mon, 17 Sep 2012 17:21:21 -0500
MIME-Version: 1.0
Message-ID: <782ba841-7dcc-4343-a12a-d3e2fc33792f@default>
Date: Mon, 17 Sep 2012 15:21:18 -0700 (PDT)
From: Dan Magenheimer <dan.magenheimer@oracle.com>
To: Zhenzhong Duan <zhenzhong.duan@oracle.com>, Jan Beulich <JBeulich@suse.com>
References: <504764270200007800098DE1@nat28.tlf.novell.com>
	<504A01790200007800099C52@nat28.tlf.novell.com>
	<504F1412020000780009A750@nat28.tlf.novell.com>
	<504F01D6.3050903@oracle.com>
	<504F23B2020000780009A79B@nat28.tlf.novell.com>
	<504F0C0C.6020804@oracle.com>
	<504F2DD8020000780009A85B@nat28.tlf.novell.com>
	<504F26F0.20600@oracle.com>
In-Reply-To: <504F26F0.20600@oracle.com>
X-Priority: 3
X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.7  (607090) [OL
	12.0.6661.5003 (x86)]
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: Ian Campbell <ian.campbell@citrix.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Ping: [PATCH 09/11,
	v2] tmem: reduce severity of log messages
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

PiBGcm9tOiB6aGVuemhvbmcuZHVhbgo+IFNlbnQ6IFR1ZXNkYXksIFNlcHRlbWJlciAxMSwgMjAx
MiA1OjU3IEFNCj4gVG86IEphbiBCZXVsaWNoCj4gQ2M6IElhbiBDYW1wYmVsbDsgeGVuLWRldmVs
OyBEYW4gTWFnZW5oZWltZXIKPiBTdWJqZWN0OiBSZTogUGluZzogW1BBVENIIDA5LzExLCB2Ml0g
dG1lbTogcmVkdWNlIHNldmVyaXR5IG9mIGxvZyBtZXNzYWdlcwo+IAo+IAo+IAo+IOS6jiAyMDEy
LTA5LTExIDE4OjI2LCBKYW4gQmV1bGljaCDlhpnpgZM6Cj4gPj4+PiBPbiAxMS4wOS4xMiBhdCAx
MjowMSwgRHVhblpoZW56aG9uZzx6aGVuemhvbmcuZHVhbkBvcmFjbGUuY29tPiAgd3JvdGU6Cj4g
Pj4gSmFuIEJldWxpY2ggd3JvdGU6Cj4gPj4+Pj4+IE9uIDExLjA5LjEyIGF0IDExOjE4LCBEdWFu
Wmhlbnpob25nPHpoZW56aG9uZy5kdWFuQG9yYWNsZS5jb20+ICB3cm90ZToKPiA+Pj4+Pj4KPiA+
Pj4+IERhbiBpcyBvZmZsaW5lIHJlY2VudGx5Lgo+ID4+Pj4gV2hhdCBhYm91dCAncHJpbnRrKCJ0
bWVtX3JlbGlucXVpc2hfcGFnZTogZmFpbGluZyBvcmRlcj0lZFxuIiwgb3JkZXIpJywKPiA+Pj4+
IG1vcmUgbGlrZSBhICBndWVzdCBsZXZlbCBtc2cuCj4gPj4+Pgo+ID4+PiBUaGF0J3MgZGViYXRh
YmxlLCBidXQgdGhlIG1lc3NhZ2UgaXMgZW5hYmxlZCBmb3IgZGVidWcgYnVpbGRzCj4gPj4+IG9u
bHkgYW55d2F5LiBDb3VsZCBiZSBtYWtlIFhFTkxPR19ERUJVRywgYnV0IHRoYXQgd291bGQKPiA+
Pj4gcmVxdWlyZSB5ZXQgYW5vdGhlciBoZWxwZXIgaW4gdG1lbV94ZW4uaC4gSSdkIHdhbnQgdG8g
bGVhdmUKPiA+Pj4gdGhpcyBhbG9uZSBmb3IgdGhlIG1vbWVudC4KPiA+PiBPay4KPiA+PiB6ZHVh
bgo+ID4gSXMgdGhhdCBhbiBhY2sgb24gdGhlIHBhdGNoIHRoZW4/Cj4gSG9wZSBEYW4gZG9uJ3Qg
aGF2ZSBvdGhlciBzdWdnZXN0aW9uLgo+IAo+IEFja2VkLWJ5OiBaaGVuemhvbmcgRHVhbiA8emhl
bnpob25nLmR1YW5Ab3JhY2xlLmNvbT4KCkxvb2tzIGdvb2QgdG8gbWUgdG9vLgoKQWNrZWQtYnk6
IERhbiBNYWdlbmhlaW1lciA8ZGFuLm1hZ2VuaGVpbWVyQG9yYWNsZS5jb20+CgpfX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpYZW4tZGV2ZWwgbWFpbGluZyBs
aXN0Clhlbi1kZXZlbEBsaXN0cy54ZW4ub3JnCmh0dHA6Ly9saXN0cy54ZW4ub3JnL3hlbi1kZXZl
bAo=

From xen-devel-bounces@lists.xen.org Mon Sep 17 22:23:40 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 22:23:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDjj2-0003GW-HC; Mon, 17 Sep 2012 22:23:32 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <samuel.thibault@ens-lyon.org>) id 1TDjj1-0003GN-5c
	for xen-devel@lists.xensource.com; Mon, 17 Sep 2012 22:23:31 +0000
Received: from [85.158.138.51:5488] by server-7.bemta-3.messagelabs.com id
	A5/BF-32000-2E2A7505; Mon, 17 Sep 2012 22:23:30 +0000
X-Env-Sender: samuel.thibault@ens-lyon.org
X-Msg-Ref: server-12.tower-174.messagelabs.com!1347920609!22996247!1
X-Originating-IP: [140.77.166.68]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11011 invoked from network); 17 Sep 2012 22:23:29 -0000
Received: from toccata.ens-lyon.fr (HELO toccata.ens-lyon.org) (140.77.166.68)
	by server-12.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 17 Sep 2012 22:23:29 -0000
Received: from localhost (localhost [127.0.0.1])
	by toccata.ens-lyon.org (Postfix) with ESMTP id 72F088408C;
	Tue, 18 Sep 2012 00:23:29 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at toccata.ens-lyon.org
Received: from toccata.ens-lyon.org ([127.0.0.1])
	by localhost (toccata.ens-lyon.org [127.0.0.1]) (amavisd-new,
	port 10024)
	with ESMTP id 0tN3BB1cxGlv; Tue, 18 Sep 2012 00:23:29 +0200 (CEST)
Received: from type.ipv6 (youpi.is-a-geek.org [80.67.176.89])
	(using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits))
	(No client certificate requested)
	by toccata.ens-lyon.org (Postfix) with ESMTPSA id 2DEE084081;
	Tue, 18 Sep 2012 00:23:29 +0200 (CEST)
Received: from samy by type.ipv6 with local (Exim 4.80)
	(envelope-from <samuel.thibault@ens-lyon.org>)
	id 1TDjiy-00047m-2o; Tue, 18 Sep 2012 00:23:28 +0200
Date: Tue, 18 Sep 2012 00:23:28 +0200
From: Samuel Thibault <samuel.thibault@ens-lyon.org>
To: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
Message-ID: <20120917222328.GN5110@type.youpi.perso.aquilenet.fr>
Mail-Followup-To: Samuel Thibault <samuel.thibault@ens-lyon.org>,
	Matthew Fioravante <matthew.fioravante@jhuapl.edu>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
References: <50579BA6.1080503@jhuapl.edu>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <50579BA6.1080503@jhuapl.edu>
User-Agent: Mutt/1.5.21+34 (58baf7c9f32f) (2010-12-30)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH mini-os enhancements for vtpm 1/8]
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Matthew Fioravante, le Mon 17 Sep 2012 17:52:38 -0400, a =E9crit :
> b/extras/mini-os/arch/ia64/iorw.c

> +void iowrite8(volatile void* addr, uint8_t val)
> +{
> +   printk("iorw not implemented!!\n");

Maybe even crash?  Such things can be overlooked.

> +#include <mini-os/types.h>
> +
> +void iowrite8(volatile void* addr, uint8_t val);
> +void iowrite32(volatile void* addr, uint32_t val);
> +
> +uint8_t ioread8(volatile void* addr);
> +uint32_t ioread32(volatile void* addr);

I'd say while you are at it, add 16 and 64 variants.

Samuel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 17 22:23:40 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 22:23:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDjj2-0003GW-HC; Mon, 17 Sep 2012 22:23:32 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <samuel.thibault@ens-lyon.org>) id 1TDjj1-0003GN-5c
	for xen-devel@lists.xensource.com; Mon, 17 Sep 2012 22:23:31 +0000
Received: from [85.158.138.51:5488] by server-7.bemta-3.messagelabs.com id
	A5/BF-32000-2E2A7505; Mon, 17 Sep 2012 22:23:30 +0000
X-Env-Sender: samuel.thibault@ens-lyon.org
X-Msg-Ref: server-12.tower-174.messagelabs.com!1347920609!22996247!1
X-Originating-IP: [140.77.166.68]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11011 invoked from network); 17 Sep 2012 22:23:29 -0000
Received: from toccata.ens-lyon.fr (HELO toccata.ens-lyon.org) (140.77.166.68)
	by server-12.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 17 Sep 2012 22:23:29 -0000
Received: from localhost (localhost [127.0.0.1])
	by toccata.ens-lyon.org (Postfix) with ESMTP id 72F088408C;
	Tue, 18 Sep 2012 00:23:29 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at toccata.ens-lyon.org
Received: from toccata.ens-lyon.org ([127.0.0.1])
	by localhost (toccata.ens-lyon.org [127.0.0.1]) (amavisd-new,
	port 10024)
	with ESMTP id 0tN3BB1cxGlv; Tue, 18 Sep 2012 00:23:29 +0200 (CEST)
Received: from type.ipv6 (youpi.is-a-geek.org [80.67.176.89])
	(using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits))
	(No client certificate requested)
	by toccata.ens-lyon.org (Postfix) with ESMTPSA id 2DEE084081;
	Tue, 18 Sep 2012 00:23:29 +0200 (CEST)
Received: from samy by type.ipv6 with local (Exim 4.80)
	(envelope-from <samuel.thibault@ens-lyon.org>)
	id 1TDjiy-00047m-2o; Tue, 18 Sep 2012 00:23:28 +0200
Date: Tue, 18 Sep 2012 00:23:28 +0200
From: Samuel Thibault <samuel.thibault@ens-lyon.org>
To: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
Message-ID: <20120917222328.GN5110@type.youpi.perso.aquilenet.fr>
Mail-Followup-To: Samuel Thibault <samuel.thibault@ens-lyon.org>,
	Matthew Fioravante <matthew.fioravante@jhuapl.edu>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
References: <50579BA6.1080503@jhuapl.edu>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <50579BA6.1080503@jhuapl.edu>
User-Agent: Mutt/1.5.21+34 (58baf7c9f32f) (2010-12-30)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH mini-os enhancements for vtpm 1/8]
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Matthew Fioravante, le Mon 17 Sep 2012 17:52:38 -0400, a =E9crit :
> b/extras/mini-os/arch/ia64/iorw.c

> +void iowrite8(volatile void* addr, uint8_t val)
> +{
> +   printk("iorw not implemented!!\n");

Maybe even crash?  Such things can be overlooked.

> +#include <mini-os/types.h>
> +
> +void iowrite8(volatile void* addr, uint8_t val);
> +void iowrite32(volatile void* addr, uint32_t val);
> +
> +uint8_t ioread8(volatile void* addr);
> +uint32_t ioread32(volatile void* addr);

I'd say while you are at it, add 16 and 64 variants.

Samuel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 17 22:46:39 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 22: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 1TDk5B-0003YZ-Jk; Mon, 17 Sep 2012 22:46:25 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <samuel.thibault@ens-lyon.org>) id 1TDk59-0003YU-TM
	for xen-devel@lists.xensource.com; Mon, 17 Sep 2012 22:46:24 +0000
Received: from [85.158.137.99:2921] by server-7.bemta-3.messagelabs.com id
	6A/0B-32000-F38A7505; Mon, 17 Sep 2012 22:46:23 +0000
X-Env-Sender: samuel.thibault@ens-lyon.org
X-Msg-Ref: server-9.tower-217.messagelabs.com!1347921981!14893950!1
X-Originating-IP: [140.77.166.68]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29567 invoked from network); 17 Sep 2012 22:46:21 -0000
Received: from toccata.ens-lyon.org (HELO toccata.ens-lyon.org) (140.77.166.68)
	by server-9.tower-217.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 17 Sep 2012 22:46:21 -0000
Received: from localhost (localhost [127.0.0.1])
	by toccata.ens-lyon.org (Postfix) with ESMTP id 2F5E684095;
	Tue, 18 Sep 2012 00:46:21 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at toccata.ens-lyon.org
Received: from toccata.ens-lyon.org ([127.0.0.1])
	by localhost (toccata.ens-lyon.org [127.0.0.1]) (amavisd-new,
	port 10024)
	with ESMTP id UWQKTJwZIdGp; Tue, 18 Sep 2012 00:46:21 +0200 (CEST)
Received: from type.ipv6 (youpi.is-a-geek.org [80.67.176.89])
	(using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits))
	(No client certificate requested)
	by toccata.ens-lyon.org (Postfix) with ESMTPSA id D683E84093;
	Tue, 18 Sep 2012 00:46:20 +0200 (CEST)
Received: from samy by type.ipv6 with local (Exim 4.80)
	(envelope-from <samuel.thibault@ens-lyon.org>)
	id 1TDk55-0004Ko-L8; Tue, 18 Sep 2012 00:46:19 +0200
Date: Tue, 18 Sep 2012 00:46:19 +0200
From: Samuel Thibault <samuel.thibault@ens-lyon.org>
To: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
Message-ID: <20120917224619.GO5110@type.youpi.perso.aquilenet.fr>
Mail-Followup-To: Samuel Thibault <samuel.thibault@ens-lyon.org>,
	Matthew Fioravante <matthew.fioravante@jhuapl.edu>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
References: <50579C5F.5040004@jhuapl.edu>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <50579C5F.5040004@jhuapl.edu>
User-Agent: Mutt/1.5.21+34 (58baf7c9f32f) (2010-12-30)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH mini-os enhancements for vtpm 2/8] add posix
 io to blkfront
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Matthew Fioravante, le Mon 17 Sep 2012 17:55:43 -0400, a =E9crit :
> +   /* Read mode checks */
> +   else
> +   {
> +      /*If the requested read is bigger than the disk, just
> +       * read as much as we can until the end */
> +      if(offset + count > disksize) {
> +         count =3D offset >=3D disksize ? 0 : disksize - offset;
> +      }
> +   }

Perhaps return 0 here already instead of just setting count to 0?

> +
> +   /* Setup aiocb block object */
> +   aiocb.aio_dev =3D dev;
> +   aiocb.aio_nbytes =3D blocksize;
> +   aiocb.aio_offset =3D blknum * blocksize;
> +   aiocb.aio_cb =3D NULL;
> +   aiocb.data =3D NULL;
> +
> +   /* If our buffer is unaligned or its aligned but we will need to rw
> a partial block
> +    * then a copy will have to be done */
> +   if(!alignedbuf || blkoff !=3D 0 || count % blocksize !=3D 0) {
> +      copybuf =3D _xmalloc(blocksize, dev->info.sector_size);
> +   }
> +
> +   rc =3D count;
> +   while(count > 0) {
> +      /* determine how many bytes to read/write from/to the current
> block buffer */
> +      bytes =3D count > (blocksize - blkoff) ? blocksize - blkoff : coun=
t;

Mmm. Optimizing the non-aligned case would make the code
tricky, but shouldn't optimizing the aligned case at least
a little bit not too hard? i.e. set bytes to max(count,
BLKIF_MAX_SEGMENTS_PER_REQUEST*PAGE_SIZE); in the optimized case? That'd
get much better 44KiB transfers instead of one sector at a time.

Ideally we should even push a series of aio requests, but that's a lot
less easy since you need to know how many requests you can afford.

Apart from that,

Acked-by: Samuel Thibault <samuel.thibault@ens-lyon.org>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 17 22:46:39 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 22: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 1TDk5B-0003YZ-Jk; Mon, 17 Sep 2012 22:46:25 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <samuel.thibault@ens-lyon.org>) id 1TDk59-0003YU-TM
	for xen-devel@lists.xensource.com; Mon, 17 Sep 2012 22:46:24 +0000
Received: from [85.158.137.99:2921] by server-7.bemta-3.messagelabs.com id
	6A/0B-32000-F38A7505; Mon, 17 Sep 2012 22:46:23 +0000
X-Env-Sender: samuel.thibault@ens-lyon.org
X-Msg-Ref: server-9.tower-217.messagelabs.com!1347921981!14893950!1
X-Originating-IP: [140.77.166.68]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29567 invoked from network); 17 Sep 2012 22:46:21 -0000
Received: from toccata.ens-lyon.org (HELO toccata.ens-lyon.org) (140.77.166.68)
	by server-9.tower-217.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 17 Sep 2012 22:46:21 -0000
Received: from localhost (localhost [127.0.0.1])
	by toccata.ens-lyon.org (Postfix) with ESMTP id 2F5E684095;
	Tue, 18 Sep 2012 00:46:21 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at toccata.ens-lyon.org
Received: from toccata.ens-lyon.org ([127.0.0.1])
	by localhost (toccata.ens-lyon.org [127.0.0.1]) (amavisd-new,
	port 10024)
	with ESMTP id UWQKTJwZIdGp; Tue, 18 Sep 2012 00:46:21 +0200 (CEST)
Received: from type.ipv6 (youpi.is-a-geek.org [80.67.176.89])
	(using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits))
	(No client certificate requested)
	by toccata.ens-lyon.org (Postfix) with ESMTPSA id D683E84093;
	Tue, 18 Sep 2012 00:46:20 +0200 (CEST)
Received: from samy by type.ipv6 with local (Exim 4.80)
	(envelope-from <samuel.thibault@ens-lyon.org>)
	id 1TDk55-0004Ko-L8; Tue, 18 Sep 2012 00:46:19 +0200
Date: Tue, 18 Sep 2012 00:46:19 +0200
From: Samuel Thibault <samuel.thibault@ens-lyon.org>
To: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
Message-ID: <20120917224619.GO5110@type.youpi.perso.aquilenet.fr>
Mail-Followup-To: Samuel Thibault <samuel.thibault@ens-lyon.org>,
	Matthew Fioravante <matthew.fioravante@jhuapl.edu>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
References: <50579C5F.5040004@jhuapl.edu>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <50579C5F.5040004@jhuapl.edu>
User-Agent: Mutt/1.5.21+34 (58baf7c9f32f) (2010-12-30)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH mini-os enhancements for vtpm 2/8] add posix
 io to blkfront
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Matthew Fioravante, le Mon 17 Sep 2012 17:55:43 -0400, a =E9crit :
> +   /* Read mode checks */
> +   else
> +   {
> +      /*If the requested read is bigger than the disk, just
> +       * read as much as we can until the end */
> +      if(offset + count > disksize) {
> +         count =3D offset >=3D disksize ? 0 : disksize - offset;
> +      }
> +   }

Perhaps return 0 here already instead of just setting count to 0?

> +
> +   /* Setup aiocb block object */
> +   aiocb.aio_dev =3D dev;
> +   aiocb.aio_nbytes =3D blocksize;
> +   aiocb.aio_offset =3D blknum * blocksize;
> +   aiocb.aio_cb =3D NULL;
> +   aiocb.data =3D NULL;
> +
> +   /* If our buffer is unaligned or its aligned but we will need to rw
> a partial block
> +    * then a copy will have to be done */
> +   if(!alignedbuf || blkoff !=3D 0 || count % blocksize !=3D 0) {
> +      copybuf =3D _xmalloc(blocksize, dev->info.sector_size);
> +   }
> +
> +   rc =3D count;
> +   while(count > 0) {
> +      /* determine how many bytes to read/write from/to the current
> block buffer */
> +      bytes =3D count > (blocksize - blkoff) ? blocksize - blkoff : coun=
t;

Mmm. Optimizing the non-aligned case would make the code
tricky, but shouldn't optimizing the aligned case at least
a little bit not too hard? i.e. set bytes to max(count,
BLKIF_MAX_SEGMENTS_PER_REQUEST*PAGE_SIZE); in the optimized case? That'd
get much better 44KiB transfers instead of one sector at a time.

Ideally we should even push a series of aio requests, but that's a lot
less easy since you need to know how many requests you can afford.

Apart from that,

Acked-by: Samuel Thibault <samuel.thibault@ens-lyon.org>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 17 22:53:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 22:53:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDkBN-0003k2-J2; Mon, 17 Sep 2012 22:52:49 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <samuel.thibault@ens-lyon.org>) id 1TDkBM-0003jx-Nc
	for xen-devel@lists.xensource.com; Mon, 17 Sep 2012 22:52:48 +0000
Received: from [85.158.137.99:26985] by server-3.bemta-3.messagelabs.com id
	BD/31-21322-FB9A7505; Mon, 17 Sep 2012 22:52:47 +0000
X-Env-Sender: samuel.thibault@ens-lyon.org
X-Msg-Ref: server-12.tower-217.messagelabs.com!1347922367!14925676!1
X-Originating-IP: [140.77.166.68]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28500 invoked from network); 17 Sep 2012 22:52:47 -0000
Received: from toccata.ens-lyon.fr (HELO toccata.ens-lyon.org) (140.77.166.68)
	by server-12.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 17 Sep 2012 22:52:47 -0000
Received: from localhost (localhost [127.0.0.1])
	by toccata.ens-lyon.org (Postfix) with ESMTP id 0053084095;
	Tue, 18 Sep 2012 00:52:47 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at toccata.ens-lyon.org
Received: from toccata.ens-lyon.org ([127.0.0.1])
	by localhost (toccata.ens-lyon.org [127.0.0.1]) (amavisd-new,
	port 10024)
	with ESMTP id F95mwCAPzWUD; Tue, 18 Sep 2012 00:52:46 +0200 (CEST)
Received: from type.ipv6 (youpi.is-a-geek.org [80.67.176.89])
	(using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits))
	(No client certificate requested)
	by toccata.ens-lyon.org (Postfix) with ESMTPSA id B4DF784093;
	Tue, 18 Sep 2012 00:52:46 +0200 (CEST)
Received: from samy by type.ipv6 with local (Exim 4.80)
	(envelope-from <samuel.thibault@ens-lyon.org>)
	id 1TDkBJ-0004Ph-IA; Tue, 18 Sep 2012 00:52:45 +0200
Date: Tue, 18 Sep 2012 00:52:45 +0200
From: Samuel Thibault <samuel.thibault@ens-lyon.org>
To: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
Message-ID: <20120917225245.GP5110@type.youpi.perso.aquilenet.fr>
Mail-Followup-To: Samuel Thibault <samuel.thibault@ens-lyon.org>,
	Matthew Fioravante <matthew.fioravante@jhuapl.edu>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
References: <50579F53.4070302@jhuapl.edu>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <50579F53.4070302@jhuapl.edu>
User-Agent: Mutt/1.5.21+34 (58baf7c9f32f) (2010-12-30)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH mini-os enhancements for vtpm 8/8] Add 3 tpm
 drivers to mini-os
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hello,

I can not review this since I don't know much about TPM, but the
principle seems sound.

Samuel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 17 22:53:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 22:53:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDkBN-0003k2-J2; Mon, 17 Sep 2012 22:52:49 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <samuel.thibault@ens-lyon.org>) id 1TDkBM-0003jx-Nc
	for xen-devel@lists.xensource.com; Mon, 17 Sep 2012 22:52:48 +0000
Received: from [85.158.137.99:26985] by server-3.bemta-3.messagelabs.com id
	BD/31-21322-FB9A7505; Mon, 17 Sep 2012 22:52:47 +0000
X-Env-Sender: samuel.thibault@ens-lyon.org
X-Msg-Ref: server-12.tower-217.messagelabs.com!1347922367!14925676!1
X-Originating-IP: [140.77.166.68]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28500 invoked from network); 17 Sep 2012 22:52:47 -0000
Received: from toccata.ens-lyon.fr (HELO toccata.ens-lyon.org) (140.77.166.68)
	by server-12.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 17 Sep 2012 22:52:47 -0000
Received: from localhost (localhost [127.0.0.1])
	by toccata.ens-lyon.org (Postfix) with ESMTP id 0053084095;
	Tue, 18 Sep 2012 00:52:47 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at toccata.ens-lyon.org
Received: from toccata.ens-lyon.org ([127.0.0.1])
	by localhost (toccata.ens-lyon.org [127.0.0.1]) (amavisd-new,
	port 10024)
	with ESMTP id F95mwCAPzWUD; Tue, 18 Sep 2012 00:52:46 +0200 (CEST)
Received: from type.ipv6 (youpi.is-a-geek.org [80.67.176.89])
	(using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits))
	(No client certificate requested)
	by toccata.ens-lyon.org (Postfix) with ESMTPSA id B4DF784093;
	Tue, 18 Sep 2012 00:52:46 +0200 (CEST)
Received: from samy by type.ipv6 with local (Exim 4.80)
	(envelope-from <samuel.thibault@ens-lyon.org>)
	id 1TDkBJ-0004Ph-IA; Tue, 18 Sep 2012 00:52:45 +0200
Date: Tue, 18 Sep 2012 00:52:45 +0200
From: Samuel Thibault <samuel.thibault@ens-lyon.org>
To: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
Message-ID: <20120917225245.GP5110@type.youpi.perso.aquilenet.fr>
Mail-Followup-To: Samuel Thibault <samuel.thibault@ens-lyon.org>,
	Matthew Fioravante <matthew.fioravante@jhuapl.edu>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
References: <50579F53.4070302@jhuapl.edu>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <50579F53.4070302@jhuapl.edu>
User-Agent: Mutt/1.5.21+34 (58baf7c9f32f) (2010-12-30)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH mini-os enhancements for vtpm 8/8] Add 3 tpm
 drivers to mini-os
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hello,

I can not review this since I don't know much about TPM, but the
principle seems sound.

Samuel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 17 23:01:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 23:01:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDkJB-0003vQ-Hp; Mon, 17 Sep 2012 23:00:53 +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 1TDkJA-0003vL-D4
	for xen-devel@lists.xen.org; Mon, 17 Sep 2012 23:00:52 +0000
Received: from [85.158.139.83:44086] by server-5.bemta-5.messagelabs.com id
	C3/EA-30514-1ABA7505; Mon, 17 Sep 2012 23:00:49 +0000
X-Env-Sender: nathan@gt.net
X-Msg-Ref: server-15.tower-182.messagelabs.com!1347922847!28737845!1
X-Originating-IP: [208.70.244.21]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1688 invoked from network); 17 Sep 2012 23:00:48 -0000
Received: from gossamer.nmsrv.com (HELO gossamer.nmsrv.com) (208.70.244.21)
	by server-15.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 17 Sep 2012 23:00:48 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gt.net; h=message-id:date
	:from:mime-version:to:subject:content-type
	:content-transfer-encoding; s=mail; bh=/WD/mAbXXu6UbGbcsSjdNOeHR
	sI=; b=RQaQTbyQ3ZQ0uIAebQVyvomFZSiEg9vGX9kc4PJK+R+KzYw3MtUyHrOaD
	fKD3BNTLnnHOMFuV6rb3DlIUUDjfAiysTzwqbN3Ved6GqTqx1m2Z70DtsNA+6eVj
	sDIS+a/5YX9QvB4XEiTx/MhgONmQAlQP831/LWrWesmmYCOMqw=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gt.net; h=message-id:date
	:from:mime-version:to:subject:content-type
	:content-transfer-encoding; q=dns; s=mail; b=wnVsut7Z8+yoCJ80fKx
	F8x4oH+J1qyvCUa14BlRqdbgMf18Mg+iMW9wwHA/hdNE1E50NyatPwl5QUkURgUg
	GUB6v0IbSAAxWqGjF319Ibc8BaXVZZAcuUZy2F9A29OIQPkrd3+AXbRLWu9Bo3BU
	Hp6cyBSFkVb5f4HBOPG0UOcg=
Received: (qmail 13872 invoked from network); 17 Sep 2012 23:00:45 -0000
X-AntiVirus: Clean
Received: from gateway.gossamer-threads.com (HELO ?192.168.1.152?)
	(nathan@gt.net@208.70.247.145)
	by gossamer.nmsrv.com with ESMTPSA (DHE-RSA-CAMELLIA256-SHA encrypted);
	17 Sep 2012 23:00:45 -0000
Message-ID: <5057AB8D.3040200@gt.net>
Date: Mon, 17 Sep 2012 16:00:29 -0700
From: Nathan March <nathan@gt.net>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:15.0) Gecko/20120907 Thunderbird/15.0.1
MIME-Version: 1.0
To: xen-devel@lists.xen.org
Subject: [Xen-devel] VM spontaneously losing network on 10gig 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-Transfer-Encoding: 7bit
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,

Having a very strange problem where a VM's bridge will spontaneously 
stop bridging traffic. This only seems to occur on our 10gig interfaces 
(intel x540 on ixgbe driver, mtu 9000), which are 2x links bonded into 
bond0, then broken down into pvlan462/pvlan463/etc before being bridged 
with the DomU's. Everything works great at first but several hours after 
starting a large rsync traffic stops crossing the bridge. Once it's 
stopped working it only affects that single VM on that single interface. 
Other VM's on the same dom0 still have access to the same affected vlan.

Layout is Nexenta NFS ---> 2x arista 10gig switches --> intel x540-t2 
(ixgbe) on dom0 --802.3ad--> bond0 --vconfig--> vlan 462 --bridged--> 
pvlan 462 / vif4.1 / vif6.1.
Dom0 is running kernel 3.2.28 w/ xen 4.1.3, domU is kernel 2.6.32.27

xen3 ~ # brctl show
bridge name     bridge id               STP enabled     interfaces
vlan462         8000.a0369f0eac2c       no              pvlan462
                                                         vif4.1
                                                         vif6.1
vlan463         8000.a0369f0eac2c       no              pvlan463
                                                         vif5.1

Once it breaks, doing a tcpdump inside the vm or on the dom0 against the 
vif show the same arp traffic from the VM (looking for the nfs server), 
but nothing incoming to the VM at all. Tcpdumping on the parent bridge 
shows the traffic as normal and other VMs on this bridge have regular 
access still, only the single vif is affected.

I've tried toggling net.bridge.bridge-nf-call-(arp|ip|ip6)tables off and 
it didn't seem to make a difference (also flushed all ip/eb/arptables 
rules just in case).

It takes me several hours to reproduce just by copying data and I 
haven't managed to figure out a nice small test case yet or what 
triggers the break. Considering I've found one bug in ixgbe already 
(reported + fixed!) I suspect the 10gig driver, but seems like this 
problem would come from either xen or bridging. This feels like a xen 
net back/front issue?

Any ideas? Or suggestions on where to start looking?

Thanks!

- Nathan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 17 23:01:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 23:01:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDkJB-0003vQ-Hp; Mon, 17 Sep 2012 23:00:53 +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 1TDkJA-0003vL-D4
	for xen-devel@lists.xen.org; Mon, 17 Sep 2012 23:00:52 +0000
Received: from [85.158.139.83:44086] by server-5.bemta-5.messagelabs.com id
	C3/EA-30514-1ABA7505; Mon, 17 Sep 2012 23:00:49 +0000
X-Env-Sender: nathan@gt.net
X-Msg-Ref: server-15.tower-182.messagelabs.com!1347922847!28737845!1
X-Originating-IP: [208.70.244.21]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1688 invoked from network); 17 Sep 2012 23:00:48 -0000
Received: from gossamer.nmsrv.com (HELO gossamer.nmsrv.com) (208.70.244.21)
	by server-15.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 17 Sep 2012 23:00:48 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gt.net; h=message-id:date
	:from:mime-version:to:subject:content-type
	:content-transfer-encoding; s=mail; bh=/WD/mAbXXu6UbGbcsSjdNOeHR
	sI=; b=RQaQTbyQ3ZQ0uIAebQVyvomFZSiEg9vGX9kc4PJK+R+KzYw3MtUyHrOaD
	fKD3BNTLnnHOMFuV6rb3DlIUUDjfAiysTzwqbN3Ved6GqTqx1m2Z70DtsNA+6eVj
	sDIS+a/5YX9QvB4XEiTx/MhgONmQAlQP831/LWrWesmmYCOMqw=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gt.net; h=message-id:date
	:from:mime-version:to:subject:content-type
	:content-transfer-encoding; q=dns; s=mail; b=wnVsut7Z8+yoCJ80fKx
	F8x4oH+J1qyvCUa14BlRqdbgMf18Mg+iMW9wwHA/hdNE1E50NyatPwl5QUkURgUg
	GUB6v0IbSAAxWqGjF319Ibc8BaXVZZAcuUZy2F9A29OIQPkrd3+AXbRLWu9Bo3BU
	Hp6cyBSFkVb5f4HBOPG0UOcg=
Received: (qmail 13872 invoked from network); 17 Sep 2012 23:00:45 -0000
X-AntiVirus: Clean
Received: from gateway.gossamer-threads.com (HELO ?192.168.1.152?)
	(nathan@gt.net@208.70.247.145)
	by gossamer.nmsrv.com with ESMTPSA (DHE-RSA-CAMELLIA256-SHA encrypted);
	17 Sep 2012 23:00:45 -0000
Message-ID: <5057AB8D.3040200@gt.net>
Date: Mon, 17 Sep 2012 16:00:29 -0700
From: Nathan March <nathan@gt.net>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:15.0) Gecko/20120907 Thunderbird/15.0.1
MIME-Version: 1.0
To: xen-devel@lists.xen.org
Subject: [Xen-devel] VM spontaneously losing network on 10gig 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-Transfer-Encoding: 7bit
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,

Having a very strange problem where a VM's bridge will spontaneously 
stop bridging traffic. This only seems to occur on our 10gig interfaces 
(intel x540 on ixgbe driver, mtu 9000), which are 2x links bonded into 
bond0, then broken down into pvlan462/pvlan463/etc before being bridged 
with the DomU's. Everything works great at first but several hours after 
starting a large rsync traffic stops crossing the bridge. Once it's 
stopped working it only affects that single VM on that single interface. 
Other VM's on the same dom0 still have access to the same affected vlan.

Layout is Nexenta NFS ---> 2x arista 10gig switches --> intel x540-t2 
(ixgbe) on dom0 --802.3ad--> bond0 --vconfig--> vlan 462 --bridged--> 
pvlan 462 / vif4.1 / vif6.1.
Dom0 is running kernel 3.2.28 w/ xen 4.1.3, domU is kernel 2.6.32.27

xen3 ~ # brctl show
bridge name     bridge id               STP enabled     interfaces
vlan462         8000.a0369f0eac2c       no              pvlan462
                                                         vif4.1
                                                         vif6.1
vlan463         8000.a0369f0eac2c       no              pvlan463
                                                         vif5.1

Once it breaks, doing a tcpdump inside the vm or on the dom0 against the 
vif show the same arp traffic from the VM (looking for the nfs server), 
but nothing incoming to the VM at all. Tcpdumping on the parent bridge 
shows the traffic as normal and other VMs on this bridge have regular 
access still, only the single vif is affected.

I've tried toggling net.bridge.bridge-nf-call-(arp|ip|ip6)tables off and 
it didn't seem to make a difference (also flushed all ip/eb/arptables 
rules just in case).

It takes me several hours to reproduce just by copying data and I 
haven't managed to figure out a nice small test case yet or what 
triggers the break. Considering I've found one bug in ixgbe already 
(reported + fixed!) I suspect the 10gig driver, but seems like this 
problem would come from either xen or bridging. This feels like a xen 
net back/front issue?

Any ideas? Or suggestions on where to start looking?

Thanks!

- Nathan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 17 23:19:19 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 23: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 1TDkah-00048M-7i; Mon, 17 Sep 2012 23:18:59 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dongxiao.xu@intel.com>) id 1TDkaf-00048H-Q4
	for xen-devel@lists.xensource.com; Mon, 17 Sep 2012 23:18:58 +0000
Received: from [85.158.139.211:18233] by server-7.bemta-5.messagelabs.com id
	31/5F-19703-0EFA7505; Mon, 17 Sep 2012 23:18:56 +0000
X-Env-Sender: dongxiao.xu@intel.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1347923932!18476014!1
X-Originating-IP: [192.55.52.88]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjg4ID0+IDMyMTQxNw==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 934 invoked from network); 17 Sep 2012 23:18:53 -0000
Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88)
	by server-7.tower-206.messagelabs.com with SMTP;
	17 Sep 2012 23:18:53 -0000
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
	by fmsmga101.fm.intel.com with ESMTP; 17 Sep 2012 16:18:51 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.80,439,1344236400"; d="scan'208";a="223254430"
Received: from fmsmsx107.amr.corp.intel.com ([10.19.9.54])
	by fmsmga001.fm.intel.com with ESMTP; 17 Sep 2012 16:18:51 -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; Mon, 17 Sep 2012 16:18:51 -0700
Received: from shsmsx102.ccr.corp.intel.com ([169.254.2.92]) by
	SHSMSX101.ccr.corp.intel.com ([169.254.1.239]) with mapi id
	14.01.0355.002; Tue, 18 Sep 2012 07:18:49 +0800
From: "Xu, Dongxiao" <dongxiao.xu@intel.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Thread-Topic: [PATCH 0/2] QEMU/xen: simplify cpu_ioreq_pio and cpu_ioreq_move
Thread-Index: AQHNj37nrC2EMMU5rkWKB1zpuoG7XpePNh6g
Date: Mon, 17 Sep 2012 23:18:49 +0000
Message-ID: <40776A41FC278F40B59438AD47D147A90FE40092@SHSMSX102.ccr.corp.intel.com>
References: <alpine.DEB.2.02.1209101842150.15568@kaball.uk.xensource.com>
In-Reply-To: <alpine.DEB.2.02.1209101842150.15568@kaball.uk.xensource.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: "Keir Fraser <keir@xen.org> \(keir@xen.org\)" <keir@xen.org>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>
Subject: Re: [Xen-devel] [PATCH 0/2] QEMU/xen: simplify cpu_ioreq_pio and
	cpu_ioreq_move
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 Stefano,

Is these patches merged with Xen 4.2? I didn't see them in the upstream.
The uint/int fix is critical to fix the nested guest boot issue.

Thanks,
Dongxiao

> -----Original Message-----
> From: Stefano Stabellini [mailto:stefano.stabellini@eu.citrix.com]
> Sent: Tuesday, September 11, 2012 2:05 AM
> To: xen-devel@lists.xensource.com
> Cc: Xu, Dongxiao; Ian Jackson; qemu-devel@nongnu.org; Stefano Stabellini
> Subject: [PATCH 0/2] QEMU/xen: simplify cpu_ioreq_pio and cpu_ioreq_move
> 
> Hi all,
> after reviewing the patch "fix multiply issue for int and uint types"
> with Ian Jackson, we realized that cpu_ioreq_pio and cpu_ioreq_move are in
> much need for a simplification as well as removal of a possible integer overflow.
> 
> This patch series tries to accomplish both switching to two new helper
> functions and using a more obvious arithmetic. Doing so it should also fix the
> original problem that Dongxiao was experiencing. The C language can be a
> nasty backstabber when signed and unsigned integers are involved.
> 
> The current patch series if for qemu-xen-traditional but if the patches are
> deemed correct I'll submit an equivalent set for QEMU upstream (with the
> appropriate code style changes).
> 
> 
> 
> Stefano Stabellini (2):
>       i should be uint32_t rather than int
>       introduce read_physical_offset and write_physical_offset
> 
>  i386-dm/helper2.c |   66
> +++++++++++++++++++++++++++++++++-------------------
>  1 files changed, 42 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 Mon Sep 17 23:19:19 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 23: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 1TDkah-00048M-7i; Mon, 17 Sep 2012 23:18:59 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dongxiao.xu@intel.com>) id 1TDkaf-00048H-Q4
	for xen-devel@lists.xensource.com; Mon, 17 Sep 2012 23:18:58 +0000
Received: from [85.158.139.211:18233] by server-7.bemta-5.messagelabs.com id
	31/5F-19703-0EFA7505; Mon, 17 Sep 2012 23:18:56 +0000
X-Env-Sender: dongxiao.xu@intel.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1347923932!18476014!1
X-Originating-IP: [192.55.52.88]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjg4ID0+IDMyMTQxNw==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 934 invoked from network); 17 Sep 2012 23:18:53 -0000
Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88)
	by server-7.tower-206.messagelabs.com with SMTP;
	17 Sep 2012 23:18:53 -0000
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
	by fmsmga101.fm.intel.com with ESMTP; 17 Sep 2012 16:18:51 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.80,439,1344236400"; d="scan'208";a="223254430"
Received: from fmsmsx107.amr.corp.intel.com ([10.19.9.54])
	by fmsmga001.fm.intel.com with ESMTP; 17 Sep 2012 16:18:51 -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; Mon, 17 Sep 2012 16:18:51 -0700
Received: from shsmsx102.ccr.corp.intel.com ([169.254.2.92]) by
	SHSMSX101.ccr.corp.intel.com ([169.254.1.239]) with mapi id
	14.01.0355.002; Tue, 18 Sep 2012 07:18:49 +0800
From: "Xu, Dongxiao" <dongxiao.xu@intel.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Thread-Topic: [PATCH 0/2] QEMU/xen: simplify cpu_ioreq_pio and cpu_ioreq_move
Thread-Index: AQHNj37nrC2EMMU5rkWKB1zpuoG7XpePNh6g
Date: Mon, 17 Sep 2012 23:18:49 +0000
Message-ID: <40776A41FC278F40B59438AD47D147A90FE40092@SHSMSX102.ccr.corp.intel.com>
References: <alpine.DEB.2.02.1209101842150.15568@kaball.uk.xensource.com>
In-Reply-To: <alpine.DEB.2.02.1209101842150.15568@kaball.uk.xensource.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: "Keir Fraser <keir@xen.org> \(keir@xen.org\)" <keir@xen.org>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>
Subject: Re: [Xen-devel] [PATCH 0/2] QEMU/xen: simplify cpu_ioreq_pio and
	cpu_ioreq_move
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 Stefano,

Is these patches merged with Xen 4.2? I didn't see them in the upstream.
The uint/int fix is critical to fix the nested guest boot issue.

Thanks,
Dongxiao

> -----Original Message-----
> From: Stefano Stabellini [mailto:stefano.stabellini@eu.citrix.com]
> Sent: Tuesday, September 11, 2012 2:05 AM
> To: xen-devel@lists.xensource.com
> Cc: Xu, Dongxiao; Ian Jackson; qemu-devel@nongnu.org; Stefano Stabellini
> Subject: [PATCH 0/2] QEMU/xen: simplify cpu_ioreq_pio and cpu_ioreq_move
> 
> Hi all,
> after reviewing the patch "fix multiply issue for int and uint types"
> with Ian Jackson, we realized that cpu_ioreq_pio and cpu_ioreq_move are in
> much need for a simplification as well as removal of a possible integer overflow.
> 
> This patch series tries to accomplish both switching to two new helper
> functions and using a more obvious arithmetic. Doing so it should also fix the
> original problem that Dongxiao was experiencing. The C language can be a
> nasty backstabber when signed and unsigned integers are involved.
> 
> The current patch series if for qemu-xen-traditional but if the patches are
> deemed correct I'll submit an equivalent set for QEMU upstream (with the
> appropriate code style changes).
> 
> 
> 
> Stefano Stabellini (2):
>       i should be uint32_t rather than int
>       introduce read_physical_offset and write_physical_offset
> 
>  i386-dm/helper2.c |   66
> +++++++++++++++++++++++++++++++++-------------------
>  1 files changed, 42 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 Mon Sep 17 23:51:34 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 23:51:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDl5o-0004Lv-VB; Mon, 17 Sep 2012 23:51:08 +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 1TDl5n-0004Lq-M3
	for Xen-devel@lists.xensource.com; Mon, 17 Sep 2012 23:51:08 +0000
Received: from [85.158.137.99:15632] by server-8.bemta-3.messagelabs.com id
	62/12-24700-A67B7505; Mon, 17 Sep 2012 23:51:06 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-13.tower-217.messagelabs.com!1347925864!18082822!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzQ1MDU4\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31420 invoked from network); 17 Sep 2012 23:51:05 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-13.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 17 Sep 2012 23:51:05 -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 q8HNp06O023657
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 17 Sep 2012 23:51:01 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
	q8HNp0BE006805
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 17 Sep 2012 23:51:00 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
	q8HNp07c030298; Mon, 17 Sep 2012 18:51:00 -0500
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 17 Sep 2012 16:50:59 -0700
Date: Mon, 17 Sep 2012 16:50:58 -0700
From: Mukesh Rathor <mukesh.rathor@oracle.com>
To: Mukesh Rathor <mukesh.rathor@oracle.com>
Message-ID: <20120917165058.686ad295@mantra.us.oracle.com>
In-Reply-To: <20120913173420.22b09c90@mantra.us.oracle.com>
References: <20120815180716.0049bffe@mantra.us.oracle.com>
	<1347372623.5305.170.camel@zakaz.uk.xensource.com>
	<20120912181910.6b0b9d2b@mantra.us.oracle.com>
	<1347536266.24226.97.camel@zakaz.uk.xensource.com>
	<20120913173420.22b09c90@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_/+jFOV+feCm6gc.MLEl3bALy"
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: "Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [RFC PATCH 8/8]: PVH: privcmd 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>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--MP_/+jFOV+feCm6gc.MLEl3bALy
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

On Thu, 13 Sep 2012 17:34:20 -0700
Mukesh Rathor <mukesh.rathor@oracle.com> wrote:

> On Thu, 13 Sep 2012 12:37:46 +0100
> Ian Campbell <Ian.Campbell@citrix.com> wrote:
> 
> > On Thu, 2012-09-13 at 02:19 +0100, Mukesh Rathor wrote:
> > > On Tue, 11 Sep 2012 15:10:23 +0100
> > > 
> > I think using vm_private within a subsystem/layer is ok, what I
> > think we should avoid is having layers pass data back and forth in
> > that field.
> 
> Ah I see your point. Ok, let me play around a bit see what I can do.

Hey Ian,

I played around a bit with privcmd, but not a whole lot can be done. I
did change things around a bit to make the APIs more symmetric and hide
vm_private_data from mmu.c. Please take a look. Unless major objections,
I'd like to resubmit all linux patches asap.

thanks,
Mukesh


--MP_/+jFOV+feCm6gc.MLEl3bALy
Content-Type: text/x-c++src
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename=privcmd.c

/******************************************************************************
 * privcmd.c
 *
 * Interface to privileged domain-0 commands.
 *
 * Copyright (c) 2002-2004, K A Fraser, B Dragovic
 */

#include <linux/kernel.h>
#include <linux/module.h>
#include <linux/sched.h>
#include <linux/slab.h>
#include <linux/string.h>
#include <linux/errno.h>
#include <linux/mm.h>
#include <linux/mman.h>
#include <linux/uaccess.h>
#include <linux/swap.h>
#include <linux/highmem.h>
#include <linux/pagemap.h>
#include <linux/seq_file.h>
#include <linux/miscdevice.h>

#include <asm/pgalloc.h>
#include <asm/pgtable.h>
#include <asm/tlb.h>
#include <asm/xen/hypervisor.h>
#include <asm/xen/hypercall.h>

#include <xen/xen.h>
#include <xen/privcmd.h>
#include <xen/interface/xen.h>
#include <xen/features.h>
#include <xen/page.h>
#include <xen/xen-ops.h>
#include <xen/balloon.h>

#include "privcmd.h"

MODULE_LICENSE("GPL");

#ifndef HAVE_ARCH_PRIVCMD_MMAP
static int privcmd_enforce_singleshot_mapping(struct vm_area_struct *vma);
#endif

static long privcmd_ioctl_hypercall(void __user *udata)
{
	struct privcmd_hypercall hypercall;
	long ret;

	if (copy_from_user(&hypercall, udata, sizeof(hypercall)))
		return -EFAULT;

	ret = privcmd_call(hypercall.op,
			   hypercall.arg[0], hypercall.arg[1],
			   hypercall.arg[2], hypercall.arg[3],
			   hypercall.arg[4]);

	return ret;
}

static void free_page_list(struct list_head *pages)
{
	struct page *p, *n;

	list_for_each_entry_safe(p, n, pages, lru)
		__free_page(p);

	INIT_LIST_HEAD(pages);
}

/*
 * Given an array of items in userspace, return a list of pages
 * containing the data.  If copying fails, either because of memory
 * allocation failure or a problem reading user memory, return an
 * error code; its up to the caller to dispose of any partial list.
 */
static int gather_array(struct list_head *pagelist,
			unsigned nelem, size_t size,
			void __user *data)
{
	unsigned pageidx;
	void *pagedata;
	int ret;

	if (size > PAGE_SIZE)
		return 0;

	pageidx = PAGE_SIZE;
	pagedata = NULL;	/* quiet, gcc */
	while (nelem--) {
		if (pageidx > PAGE_SIZE-size) {
			struct page *page = alloc_page(GFP_KERNEL);

			ret = -ENOMEM;
			if (page == NULL)
				goto fail;

			pagedata = page_address(page);

			list_add_tail(&page->lru, pagelist);
			pageidx = 0;
		}

		ret = -EFAULT;
		if (copy_from_user(pagedata + pageidx, data, size))
			goto fail;

		data += size;
		pageidx += size;
	}

	ret = 0;

fail:
	return ret;
}

/*
 * Call function "fn" on each element of the array fragmented
 * over a list of pages.
 */
static int traverse_pages(unsigned nelem, size_t size,
			  struct list_head *pos,
			  int (*fn)(void *data, void *state),
			  void *state)
{
	void *pagedata;
	unsigned pageidx;
	int ret = 0;

	BUG_ON(size > PAGE_SIZE);

	pageidx = PAGE_SIZE;
	pagedata = NULL;	/* hush, gcc */

	while (nelem--) {
		if (pageidx > PAGE_SIZE-size) {
			struct page *page;
			pos = pos->next;
			page = list_entry(pos, struct page, lru);
			pagedata = page_address(page);
			pageidx = 0;
		}

		ret = (*fn)(pagedata + pageidx, state);
		if (ret)
			break;
		pageidx += size;
	}

	return ret;
}

struct mmap_mfn_state {
	unsigned long va;
	struct vm_area_struct *vma;
	domid_t domain;
};

static int mmap_mfn_range(void *data, void *state)
{
	struct privcmd_mmap_entry *msg = data;
	struct mmap_mfn_state *st = state;
	struct vm_area_struct *vma = st->vma;
	int rc;

	/* Do not allow range to wrap the address space. */
	if ((msg->npages > (LONG_MAX >> PAGE_SHIFT)) ||
	    ((unsigned long)(msg->npages << PAGE_SHIFT) >= -st->va))
		return -EINVAL;

	/* Range chunks must be contiguous in va space. */
	if ((msg->va != st->va) ||
	    ((msg->va+(msg->npages<<PAGE_SHIFT)) > vma->vm_end))
		return -EINVAL;

	rc = xen_remap_domain_mfn_range(vma,
					msg->va & PAGE_MASK,
					msg->mfn, msg->npages,
					vma->vm_page_prot,
					st->domain, NULL);
	if (rc < 0)
		return rc;

	st->va += msg->npages << PAGE_SHIFT;

	return 0;
}

static long privcmd_ioctl_mmap(void __user *udata)
{
	struct privcmd_mmap mmapcmd;
	struct mm_struct *mm = current->mm;
	struct vm_area_struct *vma;
	int rc;
	LIST_HEAD(pagelist);
	struct mmap_mfn_state state;

	if (!xen_initial_domain())
		return -EPERM;

	/* PVH: TBD/FIXME. For now we only support privcmd_ioctl_mmap_batch */
	if (xen_pv_domain() && xen_feature(XENFEAT_auto_translated_physmap))
		return -ENOSYS;

	if (copy_from_user(&mmapcmd, udata, sizeof(mmapcmd)))
		return -EFAULT;

	rc = gather_array(&pagelist,
			  mmapcmd.num, sizeof(struct privcmd_mmap_entry),
			  mmapcmd.entry);

	if (rc || list_empty(&pagelist))
		goto out;

	down_write(&mm->mmap_sem);

	{
		struct page *page = list_first_entry(&pagelist,
						     struct page, lru);
		struct privcmd_mmap_entry *msg = page_address(page);

		vma = find_vma(mm, msg->va);
		rc = -EINVAL;

		if (!vma || (msg->va != vma->vm_start) ||
		    !privcmd_enforce_singleshot_mapping(vma))
			goto out_up;
	}

	state.va = vma->vm_start;
	state.vma = vma;
	state.domain = mmapcmd.dom;

	rc = traverse_pages(mmapcmd.num, sizeof(struct privcmd_mmap_entry),
			    &pagelist,
			    mmap_mfn_range, &state);


out_up:
	up_write(&mm->mmap_sem);

out:
	free_page_list(&pagelist);

	return rc;
}

struct mmap_batch_state {
	domid_t domain;
	unsigned long va;
	struct vm_area_struct *vma;
	int err;

	xen_pfn_t __user *user;
};

/* PVH dom0 fyi: if domU being created is PV, then mfn is mfn(addr on bus). If 
 * it's PVH then mfn is pfn (input to HAP). */
static int mmap_batch_fn(void *data, void *state)
{
	xen_pfn_t *mfnp = data;
	struct mmap_batch_state *st = state;
	struct xen_pvh_pfn_info *pvhp = st->vma ? st->vma->vm_private_data 
						: NULL;

	if (xen_remap_domain_mfn_range(st->vma, st->va & PAGE_MASK, *mfnp, 1,
				       st->vma->vm_page_prot, st->domain, 
				       pvhp) < 0) {
		*mfnp |= 0xf0000000U;
		st->err++;
	}
	st->va += PAGE_SIZE;

	return 0;
}

static int mmap_return_errors(void *data, void *state)
{
	xen_pfn_t *mfnp = data;
	struct mmap_batch_state *st = state;

	return put_user(*mfnp, st->user++);
}

/* Allocate pfns that are then mapped with gmfns from foreign domid. Update
 * the vma with the page info to use later.
 * Returns: 0 if success, otherwise -errno
 */ 
static int pvh_privcmd_resv_pfns(struct vm_area_struct *vma, int numpgs)
{
	int rc;
	struct xen_pvh_pfn_info *pvhp;

	pvhp = kzalloc(sizeof(struct xen_pvh_pfn_info), GFP_KERNEL);
	if (pvhp == NULL)
		return -ENOMEM;

	pvhp->pi_paga = kcalloc(numpgs, sizeof(pvhp->pi_paga[0]), GFP_KERNEL);
	if (pvhp->pi_paga == NULL) {
		kfree(pvhp);
		return -ENOMEM;
	}

	rc = alloc_xenballooned_pages(numpgs, pvhp->pi_paga, 0);
	if (rc != 0) {
		pr_warn("%s Could not alloc %d pfns rc:%d\n", __FUNCTION__, 
			numpgs, rc);
		kfree(pvhp->pi_paga);
		kfree(pvhp);
		return -ENOMEM;
	}
	pvhp->pi_num_pgs = numpgs;
	BUG_ON(vma->vm_private_data != (void *)1);
	vma->vm_private_data = pvhp;

	return 0;
}

static struct vm_operations_struct privcmd_vm_ops;

static long privcmd_ioctl_mmap_batch(void __user *udata)
{
	int ret;
	struct privcmd_mmapbatch m;
	struct mm_struct *mm = current->mm;
	struct vm_area_struct *vma;
	unsigned long nr_pages;
	LIST_HEAD(pagelist);
	struct mmap_batch_state state;

	if (!xen_initial_domain())
		return -EPERM;

	if (copy_from_user(&m, udata, sizeof(m)))
		return -EFAULT;

	nr_pages = m.num;
	if ((m.num <= 0) || (nr_pages > (LONG_MAX >> PAGE_SHIFT)))
		return -EINVAL;

	ret = gather_array(&pagelist, m.num, sizeof(xen_pfn_t),
			   m.arr);

	if (ret || list_empty(&pagelist))
		goto out;

	down_write(&mm->mmap_sem);

	vma = find_vma(mm, m.addr);
	ret = -EINVAL;
	if (!vma ||
	    vma->vm_ops != &privcmd_vm_ops ||
	    (m.addr != vma->vm_start) ||
	    ((m.addr + (nr_pages << PAGE_SHIFT)) != vma->vm_end) ||
	    !privcmd_enforce_singleshot_mapping(vma)) {
		up_write(&mm->mmap_sem);
		goto out;
	}

	if (xen_pv_domain() && xen_feature(XENFEAT_auto_translated_physmap)) {
		if ((ret=pvh_privcmd_resv_pfns(vma, m.num))) {
			up_write(&mm->mmap_sem);
			goto out;
		}
	}
	state.domain = m.dom;
	state.vma = vma;
	state.va = m.addr;
	state.err = 0;

	ret = traverse_pages(m.num, sizeof(xen_pfn_t),
			     &pagelist, mmap_batch_fn, &state);

	up_write(&mm->mmap_sem);

	if (state.err > 0) {
		state.user = m.arr;
		ret = traverse_pages(m.num, sizeof(xen_pfn_t),
			       &pagelist,
			       mmap_return_errors, &state);
	}

out:
	free_page_list(&pagelist);

	return ret;
}

static long privcmd_ioctl(struct file *file,
			  unsigned int cmd, unsigned long data)
{
	int ret = -ENOSYS;
	void __user *udata = (void __user *) data;

	switch (cmd) {
	case IOCTL_PRIVCMD_HYPERCALL:
		ret = privcmd_ioctl_hypercall(udata);
		break;

	case IOCTL_PRIVCMD_MMAP:
		ret = privcmd_ioctl_mmap(udata);
		break;

	case IOCTL_PRIVCMD_MMAPBATCH:
		ret = privcmd_ioctl_mmap_batch(udata);
		break;

	default:
		ret = -EINVAL;
		break;
	}

	return ret;
}

static void privcmd_close(struct vm_area_struct *vma)
{
	int count;
	struct xen_pvh_pfn_info *pvhp = vma ? vma->vm_private_data : NULL;

	if (!xen_pv_domain()  || !pvhp ||
	    !xen_feature(XENFEAT_auto_translated_physmap))
		return;

	count = xen_unmap_domain_mfn_range(vma, pvhp);
	while (count--)
		free_xenballooned_pages(1, &pvhp->pi_paga[count]);
	kfree(pvhp->pi_paga);
	kfree(pvhp);
}

static int privcmd_fault(struct vm_area_struct *vma, struct vm_fault *vmf)
{
	printk(KERN_DEBUG "privcmd_fault: vma=%p %lx-%lx, pgoff=%lx, uv=%p\n",
	       vma, vma->vm_start, vma->vm_end,
	       vmf->pgoff, vmf->virtual_address);

	return VM_FAULT_SIGBUS;
}

static struct vm_operations_struct privcmd_vm_ops = {
	.close = privcmd_close,
	.fault = privcmd_fault
};

static int privcmd_mmap(struct file *file, struct vm_area_struct *vma)
{
	/* DONTCOPY is essential for Xen because copy_page_range doesn't know
	 * how to recreate these mappings */
	vma->vm_flags |= VM_RESERVED | VM_IO | VM_DONTCOPY | VM_PFNMAP;
	vma->vm_ops = &privcmd_vm_ops;
	vma->vm_private_data = NULL;

	return 0;
}

static int privcmd_enforce_singleshot_mapping(struct vm_area_struct *vma)
{
	return (xchg(&vma->vm_private_data, (void *)1) == NULL);
}

const struct file_operations xen_privcmd_fops = {
	.owner = THIS_MODULE,
	.unlocked_ioctl = privcmd_ioctl,
	.mmap = privcmd_mmap,
};
EXPORT_SYMBOL_GPL(xen_privcmd_fops);

static struct miscdevice privcmd_dev = {
	.minor = MISC_DYNAMIC_MINOR,
	.name = "xen/privcmd",
	.fops = &xen_privcmd_fops,
};

static int __init privcmd_init(void)
{
	int err;

	if (!xen_domain())
		return -ENODEV;

	err = misc_register(&privcmd_dev);
	if (err != 0) {
		printk(KERN_ERR "Could not register Xen privcmd device\n");
		return err;
	}
	return 0;
}

static void __exit privcmd_exit(void)
{
	misc_deregister(&privcmd_dev);
}

module_init(privcmd_init);
module_exit(privcmd_exit);

--MP_/+jFOV+feCm6gc.MLEl3bALy
Content-Type: text/x-c++src
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename=mmu.c

/*
 * Xen mmu operations
 *
 * This file contains the various mmu fetch and update operations.
 * The most important job they must perform is the mapping between the
 * domain's pfn and the overall machine mfns.
 *
 * Xen allows guests to directly update the pagetable, in a controlled
 * fashion.  In other words, the guest modifies the same pagetable
 * that the CPU actually uses, which eliminates the overhead of having
 * a separate shadow pagetable.
 *
 * In order to allow this, it falls on the guest domain to map its
 * notion of a "physical" pfn - which is just a domain-local linear
 * address - into a real "machine address" which the CPU's MMU can
 * use.
 *
 * A pgd_t/pmd_t/pte_t will typically contain an mfn, and so can be
 * inserted directly into the pagetable.  When creating a new
 * pte/pmd/pgd, it converts the passed pfn into an mfn.  Conversely,
 * when reading the content back with __(pgd|pmd|pte)_val, it converts
 * the mfn back into a pfn.
 *
 * The other constraint is that all pages which make up a pagetable
 * must be mapped read-only in the guest.  This prevents uncontrolled
 * guest updates to the pagetable.  Xen strictly enforces this, and
 * will disallow any pagetable update which will end up mapping a
 * pagetable page RW, and will disallow using any writable page as a
 * pagetable.
 *
 * Naively, when loading %cr3 with the base of a new pagetable, Xen
 * would need to validate the whole pagetable before going on.
 * Naturally, this is quite slow.  The solution is to "pin" a
 * pagetable, which enforces all the constraints on the pagetable even
 * when it is not actively in use.  This menas that Xen can be assured
 * that it is still valid when you do load it into %cr3, and doesn't
 * need to revalidate it.
 *
 * Jeremy Fitzhardinge <jeremy@xensource.com>, XenSource Inc, 2007
 */
#include <linux/sched.h>
#include <linux/highmem.h>
#include <linux/debugfs.h>
#include <linux/bug.h>
#include <linux/vmalloc.h>
#include <linux/module.h>
#include <linux/gfp.h>
#include <linux/memblock.h>
#include <linux/seq_file.h>

#include <trace/events/xen.h>

#include <asm/pgtable.h>
#include <asm/tlbflush.h>
#include <asm/fixmap.h>
#include <asm/mmu_context.h>
#include <asm/setup.h>
#include <asm/paravirt.h>
#include <asm/e820.h>
#include <asm/linkage.h>
#include <asm/page.h>
#include <asm/init.h>
#include <asm/pat.h>
#include <asm/smp.h>

#include <asm/xen/hypercall.h>
#include <asm/xen/hypervisor.h>

#include <xen/xen.h>
#include <xen/page.h>
#include <xen/interface/xen.h>
#include <xen/interface/hvm/hvm_op.h>
#include <xen/interface/version.h>
#include <xen/interface/memory.h>
#include <xen/hvc-console.h>
#include <xen/balloon.h>

#include "multicalls.h"
#include "mmu.h"
#include "debugfs.h"

/*
 * Protects atomic reservation decrease/increase against concurrent increases.
 * Also protects non-atomic updates of current_pages and balloon lists.
 */
DEFINE_SPINLOCK(xen_reservation_lock);

/*
 * Identity map, in addition to plain kernel map.  This needs to be
 * large enough to allocate page table pages to allocate the rest.
 * Each page can map 2MB.
 */
#define LEVEL1_IDENT_ENTRIES	(PTRS_PER_PTE * 4)
static RESERVE_BRK_ARRAY(pte_t, level1_ident_pgt, LEVEL1_IDENT_ENTRIES);

#ifdef CONFIG_X86_64
/* l3 pud for userspace vsyscall mapping */
static pud_t level3_user_vsyscall[PTRS_PER_PUD] __page_aligned_bss;
#endif /* CONFIG_X86_64 */

/*
 * Note about cr3 (pagetable base) values:
 *
 * xen_cr3 contains the current logical cr3 value; it contains the
 * last set cr3.  This may not be the current effective cr3, because
 * its update may be being lazily deferred.  However, a vcpu looking
 * at its own cr3 can use this value knowing that it everything will
 * be self-consistent.
 *
 * xen_current_cr3 contains the actual vcpu cr3; it is set once the
 * hypercall to set the vcpu cr3 is complete (so it may be a little
 * out of date, but it will never be set early).  If one vcpu is
 * looking at another vcpu's cr3 value, it should use this variable.
 */
DEFINE_PER_CPU(unsigned long, xen_cr3);	 /* cr3 stored as physaddr */
DEFINE_PER_CPU(unsigned long, xen_current_cr3);	 /* actual vcpu cr3 */


/*
 * Just beyond the highest usermode address.  STACK_TOP_MAX has a
 * redzone above it, so round it up to a PGD boundary.
 */
#define USER_LIMIT	((STACK_TOP_MAX + PGDIR_SIZE - 1) & PGDIR_MASK)

unsigned long arbitrary_virt_to_mfn(void *vaddr)
{
	xmaddr_t maddr = arbitrary_virt_to_machine(vaddr);

	return PFN_DOWN(maddr.maddr);
}

xmaddr_t arbitrary_virt_to_machine(void *vaddr)
{
	unsigned long address = (unsigned long)vaddr;
	unsigned int level;
	pte_t *pte;
	unsigned offset;

	/*
	 * if the PFN is in the linear mapped vaddr range, we can just use
	 * the (quick) virt_to_machine() p2m lookup
	 */
	if (virt_addr_valid(vaddr))
		return virt_to_machine(vaddr);

	/* otherwise we have to do a (slower) full page-table walk */

	pte = lookup_address(address, &level);
	BUG_ON(pte == NULL);
	offset = address & ~PAGE_MASK;
	return XMADDR(((phys_addr_t)pte_mfn(*pte) << PAGE_SHIFT) + offset);
}
EXPORT_SYMBOL_GPL(arbitrary_virt_to_machine);

void make_lowmem_page_readonly(void *vaddr)
{
	pte_t *pte, ptev;
	unsigned long address = (unsigned long)vaddr;
	unsigned int level;

	pte = lookup_address(address, &level);
	if (pte == NULL)
		return;		/* vaddr missing */

	ptev = pte_wrprotect(*pte);

	if (HYPERVISOR_update_va_mapping(address, ptev, 0))
		BUG();
}

void make_lowmem_page_readwrite(void *vaddr)
{
	pte_t *pte, ptev;
	unsigned long address = (unsigned long)vaddr;
	unsigned int level;

	pte = lookup_address(address, &level);
	if (pte == NULL)
		return;		/* vaddr missing */

	ptev = pte_mkwrite(*pte);

	if (HYPERVISOR_update_va_mapping(address, ptev, 0))
		BUG();
}


static bool xen_page_pinned(void *ptr)
{
	struct page *page = virt_to_page(ptr);

	return PagePinned(page);
}

void xen_set_domain_pte(pte_t *ptep, pte_t pteval, unsigned domid)
{
	struct multicall_space mcs;
	struct mmu_update *u;

	trace_xen_mmu_set_domain_pte(ptep, pteval, domid);

	mcs = xen_mc_entry(sizeof(*u));
	u = mcs.args;

	/* ptep might be kmapped when using 32-bit HIGHPTE */
	u->ptr = virt_to_machine(ptep).maddr;
	u->val = pte_val_ma(pteval);

	MULTI_mmu_update(mcs.mc, mcs.args, 1, NULL, domid);

	xen_mc_issue(PARAVIRT_LAZY_MMU);
}
EXPORT_SYMBOL_GPL(xen_set_domain_pte);

static void xen_extend_mmu_update(const struct mmu_update *update)
{
	struct multicall_space mcs;
	struct mmu_update *u;

	mcs = xen_mc_extend_args(__HYPERVISOR_mmu_update, sizeof(*u));

	if (mcs.mc != NULL) {
		mcs.mc->args[1]++;
	} else {
		mcs = __xen_mc_entry(sizeof(*u));
		MULTI_mmu_update(mcs.mc, mcs.args, 1, NULL, DOMID_SELF);
	}

	u = mcs.args;
	*u = *update;
}

static void xen_extend_mmuext_op(const struct mmuext_op *op)
{
	struct multicall_space mcs;
	struct mmuext_op *u;

	mcs = xen_mc_extend_args(__HYPERVISOR_mmuext_op, sizeof(*u));

	if (mcs.mc != NULL) {
		mcs.mc->args[1]++;
	} else {
		mcs = __xen_mc_entry(sizeof(*u));
		MULTI_mmuext_op(mcs.mc, mcs.args, 1, NULL, DOMID_SELF);
	}

	u = mcs.args;
	*u = *op;
}

static void xen_set_pmd_hyper(pmd_t *ptr, pmd_t val)
{
	struct mmu_update u;

	preempt_disable();

	xen_mc_batch();

	/* ptr may be ioremapped for 64-bit pagetable setup */
	u.ptr = arbitrary_virt_to_machine(ptr).maddr;
	u.val = pmd_val_ma(val);
	xen_extend_mmu_update(&u);

	xen_mc_issue(PARAVIRT_LAZY_MMU);

	preempt_enable();
}

static void xen_set_pmd(pmd_t *ptr, pmd_t val)
{
	trace_xen_mmu_set_pmd(ptr, val);

	/* If page is not pinned, we can just update the entry
	   directly */
	if (!xen_page_pinned(ptr)) {
		*ptr = val;
		return;
	}

	xen_set_pmd_hyper(ptr, val);
}

/*
 * Associate a virtual page frame with a given physical page frame
 * and protection flags for that frame.
 */
void set_pte_mfn(unsigned long vaddr, unsigned long mfn, pgprot_t flags)
{
	set_pte_vaddr(vaddr, mfn_pte(mfn, flags));
}

static bool xen_batched_set_pte(pte_t *ptep, pte_t pteval)
{
	struct mmu_update u;

	if (paravirt_get_lazy_mode() != PARAVIRT_LAZY_MMU)
		return false;

	xen_mc_batch();

	u.ptr = virt_to_machine(ptep).maddr | MMU_NORMAL_PT_UPDATE;
	u.val = pte_val_ma(pteval);
	xen_extend_mmu_update(&u);

	xen_mc_issue(PARAVIRT_LAZY_MMU);

	return true;
}

static inline void __xen_set_pte(pte_t *ptep, pte_t 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)
{
	trace_xen_mmu_set_pte(ptep, pteval);
	__xen_set_pte(ptep, pteval);
}

void xen_set_clr_mmio_pvh_pte(unsigned long pfn, unsigned long mfn, 
			      int nr_mfns, int add_mapping)
{
	struct physdev_map_iomem iomem;

	iomem.first_gfn = pfn;
	iomem.first_mfn = mfn;
	iomem.nr_mfns = nr_mfns;
	iomem.add_mapping = add_mapping;

	if (HYPERVISOR_physdev_op(PHYSDEVOP_pvh_map_iomem, &iomem))
		BUG();
}

static void xen_dom0pvh_set_pte_at(struct mm_struct *mm, unsigned long addr,
		    		   pte_t *ptep, pte_t pteval)
{
	native_set_pte(ptep, pteval);
}

static void xen_set_pte_at(struct mm_struct *mm, unsigned long addr,
		    pte_t *ptep, pte_t pteval)
{
	trace_xen_mmu_set_pte_at(mm, addr, ptep, pteval);
	__xen_set_pte(ptep, pteval);
}

pte_t xen_ptep_modify_prot_start(struct mm_struct *mm,
				 unsigned long addr, pte_t *ptep)
{
	/* Just return the pte as-is.  We preserve the bits on commit */
	trace_xen_mmu_ptep_modify_prot_start(mm, addr, ptep, *ptep);
	return *ptep;
}

void xen_ptep_modify_prot_commit(struct mm_struct *mm, unsigned long addr,
				 pte_t *ptep, pte_t pte)
{
	struct mmu_update u;

	trace_xen_mmu_ptep_modify_prot_commit(mm, addr, ptep, pte);
	xen_mc_batch();

	u.ptr = virt_to_machine(ptep).maddr | MMU_PT_UPDATE_PRESERVE_AD;
	u.val = pte_val_ma(pte);
	xen_extend_mmu_update(&u);

	xen_mc_issue(PARAVIRT_LAZY_MMU);
}

/* Assume pteval_t is equivalent to all the other *val_t types. */
static pteval_t pte_mfn_to_pfn(pteval_t val)
{
	if (val & _PAGE_PRESENT) {
		unsigned long mfn = (val & PTE_PFN_MASK) >> PAGE_SHIFT;
		unsigned long pfn = mfn_to_pfn(mfn);

		pteval_t flags = val & PTE_FLAGS_MASK;
		if (unlikely(pfn == ~0))
			val = flags & ~_PAGE_PRESENT;
		else
			val = ((pteval_t)pfn << PAGE_SHIFT) | flags;
	}

	return val;
}

static pteval_t pte_pfn_to_mfn(pteval_t val)
{
	if (val & _PAGE_PRESENT) {
		unsigned long pfn = (val & PTE_PFN_MASK) >> PAGE_SHIFT;
		pteval_t flags = val & PTE_FLAGS_MASK;
		unsigned long mfn;

		if (!xen_feature(XENFEAT_auto_translated_physmap))
			mfn = get_phys_to_machine(pfn);
		else
			mfn = pfn;
		/*
		 * If there's no mfn for the pfn, then just create an
		 * empty non-present pte.  Unfortunately this loses
		 * information about the original pfn, so
		 * pte_mfn_to_pfn is asymmetric.
		 */
		if (unlikely(mfn == INVALID_P2M_ENTRY)) {
			mfn = 0;
			flags = 0;
		} else {
			/*
			 * Paramount to do this test _after_ the
			 * INVALID_P2M_ENTRY as INVALID_P2M_ENTRY &
			 * IDENTITY_FRAME_BIT resolves to true.
			 */
			mfn &= ~FOREIGN_FRAME_BIT;
			if (mfn & IDENTITY_FRAME_BIT) {
				mfn &= ~IDENTITY_FRAME_BIT;
				flags |= _PAGE_IOMAP;
			}
		}
		val = ((pteval_t)mfn << PAGE_SHIFT) | flags;
	}

	return val;
}

static pteval_t iomap_pte(pteval_t val)
{
	if (val & _PAGE_PRESENT) {
		unsigned long pfn = (val & PTE_PFN_MASK) >> PAGE_SHIFT;
		pteval_t flags = val & PTE_FLAGS_MASK;

		/* We assume the pte frame number is a MFN, so
		   just use it as-is. */
		val = ((pteval_t)pfn << PAGE_SHIFT) | flags;
	}

	return val;
}

static pteval_t xen_pte_val(pte_t pte)
{
	pteval_t pteval = pte.pte;
#if 0
	/* If this is a WC pte, convert back from Xen WC to Linux WC */
	if ((pteval & (_PAGE_PAT | _PAGE_PCD | _PAGE_PWT)) == _PAGE_PAT) {
		WARN_ON(!pat_enabled);
		pteval = (pteval & ~_PAGE_PAT) | _PAGE_PWT;
	}
#endif
	if (xen_initial_domain() && (pteval & _PAGE_IOMAP))
		return pteval;

	return pte_mfn_to_pfn(pteval);
}
PV_CALLEE_SAVE_REGS_THUNK(xen_pte_val);

static pgdval_t xen_pgd_val(pgd_t pgd)
{
	return pte_mfn_to_pfn(pgd.pgd);
}
PV_CALLEE_SAVE_REGS_THUNK(xen_pgd_val);

/*
 * Xen's PAT setup is part of its ABI, though I assume entries 6 & 7
 * are reserved for now, to correspond to the Intel-reserved PAT
 * types.
 *
 * We expect Linux's PAT set as follows:
 *
 * Idx  PTE flags        Linux    Xen    Default
 * 0                     WB       WB     WB
 * 1            PWT      WC       WT     WT
 * 2        PCD          UC-      UC-    UC-
 * 3        PCD PWT      UC       UC     UC
 * 4    PAT              WB       WC     WB
 * 5    PAT     PWT      WC       WP     WT
 * 6    PAT PCD          UC-      UC     UC-
 * 7    PAT PCD PWT      UC       UC     UC
 */

void xen_set_pat(u64 pat)
{
	/* We expect Linux to use a PAT setting of
	 * UC UC- WC WB (ignoring the PAT flag) */
	WARN_ON(pat != 0x0007010600070106ull);
}

static pte_t xen_make_pte(pteval_t pte)
{
	phys_addr_t addr = (pte & PTE_PFN_MASK);
#if 0
	/* If Linux is trying to set a WC pte, then map to the Xen WC.
	 * If _PAGE_PAT is set, then it probably means it is really
	 * _PAGE_PSE, so avoid fiddling with the PAT mapping and hope
	 * things work out OK...
	 *
	 * (We should never see kernel mappings with _PAGE_PSE set,
	 * but we could see hugetlbfs mappings, I think.).
	 */
	if (pat_enabled && !WARN_ON(pte & _PAGE_PAT)) {
		if ((pte & (_PAGE_PCD | _PAGE_PWT)) == _PAGE_PWT)
			pte = (pte & ~(_PAGE_PCD | _PAGE_PWT)) | _PAGE_PAT;
	}
#endif
	/*
	 * Unprivileged domains are allowed to do IOMAPpings for
	 * PCI passthrough, but not map ISA space.  The ISA
	 * mappings are just dummy local mappings to keep other
	 * parts of the kernel happy.
	 */
	if (unlikely(pte & _PAGE_IOMAP) &&
	    (xen_initial_domain() || addr >= ISA_END_ADDRESS)) {
		pte = iomap_pte(pte);
	} else {
		pte &= ~_PAGE_IOMAP;
		pte = pte_pfn_to_mfn(pte);
	}

	return native_make_pte(pte);
}
PV_CALLEE_SAVE_REGS_THUNK(xen_make_pte);

static pgd_t xen_make_pgd(pgdval_t pgd)
{
	pgd = pte_pfn_to_mfn(pgd);
	return native_make_pgd(pgd);
}
PV_CALLEE_SAVE_REGS_THUNK(xen_make_pgd);

static pmdval_t xen_pmd_val(pmd_t pmd)
{
	return pte_mfn_to_pfn(pmd.pmd);
}
PV_CALLEE_SAVE_REGS_THUNK(xen_pmd_val);

static void xen_set_pud_hyper(pud_t *ptr, pud_t val)
{
	struct mmu_update u;

	preempt_disable();

	xen_mc_batch();

	/* ptr may be ioremapped for 64-bit pagetable setup */
	u.ptr = arbitrary_virt_to_machine(ptr).maddr;
	u.val = pud_val_ma(val);
	xen_extend_mmu_update(&u);

	xen_mc_issue(PARAVIRT_LAZY_MMU);

	preempt_enable();
}

static void xen_set_pud(pud_t *ptr, pud_t val)
{
	trace_xen_mmu_set_pud(ptr, val);

	/* If page is not pinned, we can just update the entry
	   directly */
	if (!xen_page_pinned(ptr)) {
		*ptr = val;
		return;
	}

	xen_set_pud_hyper(ptr, val);
}

#ifdef CONFIG_X86_PAE
static void xen_set_pte_atomic(pte_t *ptep, pte_t pte)
{
	trace_xen_mmu_set_pte_atomic(ptep, pte);
	set_64bit((u64 *)ptep, native_pte_val(pte));
}

static void xen_pte_clear(struct mm_struct *mm, unsigned long addr, pte_t *ptep)
{
	trace_xen_mmu_pte_clear(mm, addr, ptep);
	if (!xen_batched_set_pte(ptep, native_make_pte(0)))
		native_pte_clear(mm, addr, ptep);
}

static void xen_pmd_clear(pmd_t *pmdp)
{
	trace_xen_mmu_pmd_clear(pmdp);
	set_pmd(pmdp, __pmd(0));
}
#endif	/* CONFIG_X86_PAE */

static pmd_t xen_make_pmd(pmdval_t pmd)
{
	pmd = pte_pfn_to_mfn(pmd);
	return native_make_pmd(pmd);
}
PV_CALLEE_SAVE_REGS_THUNK(xen_make_pmd);

#if PAGETABLE_LEVELS == 4
static pudval_t xen_pud_val(pud_t pud)
{
	return pte_mfn_to_pfn(pud.pud);
}
PV_CALLEE_SAVE_REGS_THUNK(xen_pud_val);

static pud_t xen_make_pud(pudval_t pud)
{
	pud = pte_pfn_to_mfn(pud);

	return native_make_pud(pud);
}
PV_CALLEE_SAVE_REGS_THUNK(xen_make_pud);

static pgd_t *xen_get_user_pgd(pgd_t *pgd)
{
	pgd_t *pgd_page = (pgd_t *)(((unsigned long)pgd) & PAGE_MASK);
	unsigned offset = pgd - pgd_page;
	pgd_t *user_ptr = NULL;

	if (offset < pgd_index(USER_LIMIT)) {
		struct page *page = virt_to_page(pgd_page);
		user_ptr = (pgd_t *)page->private;
		if (user_ptr)
			user_ptr += offset;
	}

	return user_ptr;
}

static void __xen_set_pgd_hyper(pgd_t *ptr, pgd_t val)
{
	struct mmu_update u;

	u.ptr = virt_to_machine(ptr).maddr;
	u.val = pgd_val_ma(val);
	xen_extend_mmu_update(&u);
}

/*
 * Raw hypercall-based set_pgd, intended for in early boot before
 * there's a page structure.  This implies:
 *  1. The only existing pagetable is the kernel's
 *  2. It is always pinned
 *  3. It has no user pagetable attached to it
 */
static void __init xen_set_pgd_hyper(pgd_t *ptr, pgd_t val)
{
	preempt_disable();

	xen_mc_batch();

	__xen_set_pgd_hyper(ptr, val);

	xen_mc_issue(PARAVIRT_LAZY_MMU);

	preempt_enable();
}

static void xen_set_pgd(pgd_t *ptr, pgd_t val)
{
	pgd_t *user_ptr = xen_get_user_pgd(ptr);

	trace_xen_mmu_set_pgd(ptr, user_ptr, val);

	/* If page is not pinned, we can just update the entry
	   directly */
	if (!xen_page_pinned(ptr)) {
		*ptr = val;
		if (user_ptr) {
			WARN_ON(xen_page_pinned(user_ptr));
			*user_ptr = val;
		}
		return;
	}

	/* If it's pinned, then we can at least batch the kernel and
	   user updates together. */
	xen_mc_batch();

	__xen_set_pgd_hyper(ptr, val);
	if (user_ptr)
		__xen_set_pgd_hyper(user_ptr, val);

	xen_mc_issue(PARAVIRT_LAZY_MMU);
}
#endif	/* PAGETABLE_LEVELS == 4 */

/*
 * (Yet another) pagetable walker.  This one is intended for pinning a
 * pagetable.  This means that it walks a pagetable and calls the
 * callback function on each page it finds making up the page table,
 * at every level.  It walks the entire pagetable, but it only bothers
 * pinning pte pages which are below limit.  In the normal case this
 * will be STACK_TOP_MAX, but at boot we need to pin up to
 * FIXADDR_TOP.
 *
 * For 32-bit the important bit is that we don't pin beyond there,
 * because then we start getting into Xen's ptes.
 *
 * For 64-bit, we must skip the Xen hole in the middle of the address
 * space, just after the big x86-64 virtual hole.
 */
static int __xen_pgd_walk(struct mm_struct *mm, pgd_t *pgd,
			  int (*func)(struct mm_struct *mm, struct page *,
				      enum pt_level),
			  unsigned long limit)
{
	int flush = 0;
	unsigned hole_low, hole_high;
	unsigned pgdidx_limit, pudidx_limit, pmdidx_limit;
	unsigned pgdidx, pudidx, pmdidx;

	/* The limit is the last byte to be touched */
	limit--;
	BUG_ON(limit >= FIXADDR_TOP);

	if (xen_feature(XENFEAT_auto_translated_physmap))
		return 0;

	/*
	 * 64-bit has a great big hole in the middle of the address
	 * space, which contains the Xen mappings.  On 32-bit these
	 * will end up making a zero-sized hole and so is a no-op.
	 */
	hole_low = pgd_index(USER_LIMIT);
	hole_high = pgd_index(PAGE_OFFSET);

	pgdidx_limit = pgd_index(limit);
#if PTRS_PER_PUD > 1
	pudidx_limit = pud_index(limit);
#else
	pudidx_limit = 0;
#endif
#if PTRS_PER_PMD > 1
	pmdidx_limit = pmd_index(limit);
#else
	pmdidx_limit = 0;
#endif

	for (pgdidx = 0; pgdidx <= pgdidx_limit; pgdidx++) {
		pud_t *pud;

		if (pgdidx >= hole_low && pgdidx < hole_high)
			continue;

		if (!pgd_val(pgd[pgdidx]))
			continue;

		pud = pud_offset(&pgd[pgdidx], 0);

		if (PTRS_PER_PUD > 1) /* not folded */
			flush |= (*func)(mm, virt_to_page(pud), PT_PUD);

		for (pudidx = 0; pudidx < PTRS_PER_PUD; pudidx++) {
			pmd_t *pmd;

			if (pgdidx == pgdidx_limit &&
			    pudidx > pudidx_limit)
				goto out;

			if (pud_none(pud[pudidx]))
				continue;

			pmd = pmd_offset(&pud[pudidx], 0);

			if (PTRS_PER_PMD > 1) /* not folded */
				flush |= (*func)(mm, virt_to_page(pmd), PT_PMD);

			for (pmdidx = 0; pmdidx < PTRS_PER_PMD; pmdidx++) {
				struct page *pte;

				if (pgdidx == pgdidx_limit &&
				    pudidx == pudidx_limit &&
				    pmdidx > pmdidx_limit)
					goto out;

				if (pmd_none(pmd[pmdidx]))
					continue;

				pte = pmd_page(pmd[pmdidx]);
				flush |= (*func)(mm, pte, PT_PTE);
			}
		}
	}

out:
	/* Do the top level last, so that the callbacks can use it as
	   a cue to do final things like tlb flushes. */
	flush |= (*func)(mm, virt_to_page(pgd), PT_PGD);

	return flush;
}

static int xen_pgd_walk(struct mm_struct *mm,
			int (*func)(struct mm_struct *mm, struct page *,
				    enum pt_level),
			unsigned long limit)
{
	return __xen_pgd_walk(mm, mm->pgd, func, limit);
}

/* If we're using split pte locks, then take the page's lock and
   return a pointer to it.  Otherwise return NULL. */
static spinlock_t *xen_pte_lock(struct page *page, struct mm_struct *mm)
{
	spinlock_t *ptl = NULL;

#if USE_SPLIT_PTLOCKS
	ptl = __pte_lockptr(page);
	spin_lock_nest_lock(ptl, &mm->page_table_lock);
#endif

	return ptl;
}

static void xen_pte_unlock(void *v)
{
	spinlock_t *ptl = v;
	spin_unlock(ptl);
}

static void xen_do_pin(unsigned level, unsigned long pfn)
{
	struct mmuext_op op;

	op.cmd = level;
	op.arg1.mfn = pfn_to_mfn(pfn);

	xen_extend_mmuext_op(&op);
}

static int xen_pin_page(struct mm_struct *mm, struct page *page,
			enum pt_level level)
{
	unsigned pgfl = TestSetPagePinned(page);
	int flush;

	if (pgfl)
		flush = 0;		/* already pinned */
	else if (PageHighMem(page))
		/* kmaps need flushing if we found an unpinned
		   highpage */
		flush = 1;
	else {
		void *pt = lowmem_page_address(page);
		unsigned long pfn = page_to_pfn(page);
		struct multicall_space mcs = __xen_mc_entry(0);
		spinlock_t *ptl;

		flush = 0;

		/*
		 * We need to hold the pagetable lock between the time
		 * we make the pagetable RO and when we actually pin
		 * it.  If we don't, then other users may come in and
		 * attempt to update the pagetable by writing it,
		 * which will fail because the memory is RO but not
		 * pinned, so Xen won't do the trap'n'emulate.
		 *
		 * If we're using split pte locks, we can't hold the
		 * entire pagetable's worth of locks during the
		 * traverse, because we may wrap the preempt count (8
		 * bits).  The solution is to mark RO and pin each PTE
		 * page while holding the lock.  This means the number
		 * of locks we end up holding is never more than a
		 * batch size (~32 entries, at present).
		 *
		 * If we're not using split pte locks, we needn't pin
		 * the PTE pages independently, because we're
		 * protected by the overall pagetable lock.
		 */
		ptl = NULL;
		if (level == PT_PTE)
			ptl = xen_pte_lock(page, mm);

		MULTI_update_va_mapping(mcs.mc, (unsigned long)pt,
					pfn_pte(pfn, PAGE_KERNEL_RO),
					level == PT_PGD ? UVMF_TLB_FLUSH : 0);

		if (ptl) {
			xen_do_pin(MMUEXT_PIN_L1_TABLE, pfn);

			/* Queue a deferred unlock for when this batch
			   is completed. */
			xen_mc_callback(xen_pte_unlock, ptl);
		}
	}

	return flush;
}

/* This is called just after a mm has been created, but it has not
   been used yet.  We need to make sure that its pagetable is all
   read-only, and can be pinned. */
static void __xen_pgd_pin(struct mm_struct *mm, pgd_t *pgd)
{
	trace_xen_mmu_pgd_pin(mm, pgd);

	xen_mc_batch();

	if (__xen_pgd_walk(mm, pgd, xen_pin_page, USER_LIMIT)) {
		/* re-enable interrupts for flushing */
		xen_mc_issue(0);

		kmap_flush_unused();

		xen_mc_batch();
	}

#ifdef CONFIG_X86_64
	{
		pgd_t *user_pgd = xen_get_user_pgd(pgd);

		xen_do_pin(MMUEXT_PIN_L4_TABLE, PFN_DOWN(__pa(pgd)));

		if (user_pgd) {
			xen_pin_page(mm, virt_to_page(user_pgd), PT_PGD);
			xen_do_pin(MMUEXT_PIN_L4_TABLE,
				   PFN_DOWN(__pa(user_pgd)));
		}
	}
#else /* CONFIG_X86_32 */
#ifdef CONFIG_X86_PAE
	/* Need to make sure unshared kernel PMD is pinnable */
	xen_pin_page(mm, pgd_page(pgd[pgd_index(TASK_SIZE)]),
		     PT_PMD);
#endif
	xen_do_pin(MMUEXT_PIN_L3_TABLE, PFN_DOWN(__pa(pgd)));
#endif /* CONFIG_X86_64 */
	xen_mc_issue(0);
}

static void xen_pgd_pin(struct mm_struct *mm)
{
	__xen_pgd_pin(mm, mm->pgd);
}

/*
 * On save, we need to pin all pagetables to make sure they get their
 * mfns turned into pfns.  Search the list for any unpinned pgds and pin
 * them (unpinned pgds are not currently in use, probably because the
 * process is under construction or destruction).
 *
 * Expected to be called in stop_machine() ("equivalent to taking
 * every spinlock in the system"), so the locking doesn't really
 * matter all that much.
 */
void xen_mm_pin_all(void)
{
	struct page *page;

	spin_lock(&pgd_lock);

	list_for_each_entry(page, &pgd_list, lru) {
		if (!PagePinned(page)) {
			__xen_pgd_pin(&init_mm, (pgd_t *)page_address(page));
			SetPageSavePinned(page);
		}
	}

	spin_unlock(&pgd_lock);
}

/*
 * The init_mm pagetable is really pinned as soon as its created, but
 * that's before we have page structures to store the bits.  So do all
 * the book-keeping now.
 */
static int __init xen_mark_pinned(struct mm_struct *mm, struct page *page,
				  enum pt_level level)
{
	SetPagePinned(page);
	return 0;
}

static void __init xen_mark_init_mm_pinned(void)
{
	xen_pgd_walk(&init_mm, xen_mark_pinned, FIXADDR_TOP);
}

static int xen_unpin_page(struct mm_struct *mm, struct page *page,
			  enum pt_level level)
{
	unsigned pgfl = TestClearPagePinned(page);

	if (pgfl && !PageHighMem(page)) {
		void *pt = lowmem_page_address(page);
		unsigned long pfn = page_to_pfn(page);
		spinlock_t *ptl = NULL;
		struct multicall_space mcs;

		/*
		 * Do the converse to pin_page.  If we're using split
		 * pte locks, we must be holding the lock for while
		 * the pte page is unpinned but still RO to prevent
		 * concurrent updates from seeing it in this
		 * partially-pinned state.
		 */
		if (level == PT_PTE) {
			ptl = xen_pte_lock(page, mm);

			if (ptl)
				xen_do_pin(MMUEXT_UNPIN_TABLE, pfn);
		}

		mcs = __xen_mc_entry(0);

		MULTI_update_va_mapping(mcs.mc, (unsigned long)pt,
					pfn_pte(pfn, PAGE_KERNEL),
					level == PT_PGD ? UVMF_TLB_FLUSH : 0);

		if (ptl) {
			/* unlock when batch completed */
			xen_mc_callback(xen_pte_unlock, ptl);
		}
	}

	return 0;		/* never need to flush on unpin */
}

/* Release a pagetables pages back as normal RW */
static void __xen_pgd_unpin(struct mm_struct *mm, pgd_t *pgd)
{
	trace_xen_mmu_pgd_unpin(mm, pgd);

	xen_mc_batch();

	xen_do_pin(MMUEXT_UNPIN_TABLE, PFN_DOWN(__pa(pgd)));

#ifdef CONFIG_X86_64
	{
		pgd_t *user_pgd = xen_get_user_pgd(pgd);

		if (user_pgd) {
			xen_do_pin(MMUEXT_UNPIN_TABLE,
				   PFN_DOWN(__pa(user_pgd)));
			xen_unpin_page(mm, virt_to_page(user_pgd), PT_PGD);
		}
	}
#endif

#ifdef CONFIG_X86_PAE
	/* Need to make sure unshared kernel PMD is unpinned */
	xen_unpin_page(mm, pgd_page(pgd[pgd_index(TASK_SIZE)]),
		       PT_PMD);
#endif

	__xen_pgd_walk(mm, pgd, xen_unpin_page, USER_LIMIT);

	xen_mc_issue(0);
}

static void xen_pgd_unpin(struct mm_struct *mm)
{
	__xen_pgd_unpin(mm, mm->pgd);
}

/*
 * On resume, undo any pinning done at save, so that the rest of the
 * kernel doesn't see any unexpected pinned pagetables.
 */
void xen_mm_unpin_all(void)
{
	struct page *page;

	spin_lock(&pgd_lock);

	list_for_each_entry(page, &pgd_list, lru) {
		if (PageSavePinned(page)) {
			BUG_ON(!PagePinned(page));
			__xen_pgd_unpin(&init_mm, (pgd_t *)page_address(page));
			ClearPageSavePinned(page);
		}
	}

	spin_unlock(&pgd_lock);
}

static void xen_activate_mm(struct mm_struct *prev, struct mm_struct *next)
{
	spin_lock(&next->page_table_lock);
	xen_pgd_pin(next);
	spin_unlock(&next->page_table_lock);
}

static void xen_dup_mmap(struct mm_struct *oldmm, struct mm_struct *mm)
{
	spin_lock(&mm->page_table_lock);
	xen_pgd_pin(mm);
	spin_unlock(&mm->page_table_lock);
}


#ifdef CONFIG_SMP
/* Another cpu may still have their %cr3 pointing at the pagetable, so
   we need to repoint it somewhere else before we can unpin it. */
static void drop_other_mm_ref(void *info)
{
	struct mm_struct *mm = info;
	struct mm_struct *active_mm;

	active_mm = this_cpu_read(cpu_tlbstate.active_mm);

	if (active_mm == mm && this_cpu_read(cpu_tlbstate.state) != TLBSTATE_OK)
		leave_mm(smp_processor_id());

	/* If this cpu still has a stale cr3 reference, then make sure
	   it has been flushed. */
	if (this_cpu_read(xen_current_cr3) == __pa(mm->pgd))
		load_cr3(swapper_pg_dir);
}

static void xen_drop_mm_ref(struct mm_struct *mm)
{
	cpumask_var_t mask;
	unsigned cpu;

	if (current->active_mm == mm) {
		if (current->mm == mm)
			load_cr3(swapper_pg_dir);
		else
			leave_mm(smp_processor_id());
	}

	/* Get the "official" set of cpus referring to our pagetable. */
	if (!alloc_cpumask_var(&mask, GFP_ATOMIC)) {
		for_each_online_cpu(cpu) {
			if (!cpumask_test_cpu(cpu, mm_cpumask(mm))
			    && per_cpu(xen_current_cr3, cpu) != __pa(mm->pgd))
				continue;
			smp_call_function_single(cpu, drop_other_mm_ref, mm, 1);
		}
		return;
	}
	cpumask_copy(mask, mm_cpumask(mm));

	/* It's possible that a vcpu may have a stale reference to our
	   cr3, because its in lazy mode, and it hasn't yet flushed
	   its set of pending hypercalls yet.  In this case, we can
	   look at its actual current cr3 value, and force it to flush
	   if needed. */
	for_each_online_cpu(cpu) {
		if (per_cpu(xen_current_cr3, cpu) == __pa(mm->pgd))
			cpumask_set_cpu(cpu, mask);
	}

	if (!cpumask_empty(mask))
		smp_call_function_many(mask, drop_other_mm_ref, mm, 1);
	free_cpumask_var(mask);
}
#else
static void xen_drop_mm_ref(struct mm_struct *mm)
{
	if (current->active_mm == mm)
		load_cr3(swapper_pg_dir);
}
#endif

/*
 * While a process runs, Xen pins its pagetables, which means that the
 * hypervisor forces it to be read-only, and it controls all updates
 * to it.  This means that all pagetable updates have to go via the
 * hypervisor, which is moderately expensive.
 *
 * Since we're pulling the pagetable down, we switch to use init_mm,
 * unpin old process pagetable and mark it all read-write, which
 * allows further operations on it to be simple memory accesses.
 *
 * The only subtle point is that another CPU may be still using the
 * pagetable because of lazy tlb flushing.  This means we need need to
 * switch all CPUs off this pagetable before we can unpin it.
 */
static void xen_exit_mmap(struct mm_struct *mm)
{
	get_cpu();		/* make sure we don't move around */
	xen_drop_mm_ref(mm);
	put_cpu();

	spin_lock(&mm->page_table_lock);

	/* pgd may not be pinned in the error exit path of execve */
	if (xen_page_pinned(mm->pgd))
		xen_pgd_unpin(mm);

	spin_unlock(&mm->page_table_lock);
}

static void __init xen_pagetable_setup_start(pgd_t *base)
{
}

static __init void xen_mapping_pagetable_reserve(u64 start, u64 end)
{
	/* reserve the range used */
	native_pagetable_reserve(start, end);

	/* set as RW the rest */
	printk(KERN_DEBUG "xen: setting RW the range %llx - %llx\n", end,
			PFN_PHYS(pgt_buf_top));
	while (end < PFN_PHYS(pgt_buf_top)) {
		make_lowmem_page_readwrite(__va(end));
		end += PAGE_SIZE;
	}
}

static void xen_post_allocator_init(void);

static void __init xen_pagetable_setup_done(pgd_t *base)
{
	xen_setup_shared_info();

	if (xen_feature(XENFEAT_auto_translated_physmap))
		return;

	xen_post_allocator_init();
}

static void xen_write_cr2(unsigned long cr2)
{
	this_cpu_read(xen_vcpu)->arch.cr2 = cr2;
}

static unsigned long xen_read_cr2(void)
{
	return this_cpu_read(xen_vcpu)->arch.cr2;
}

unsigned long xen_read_cr2_direct(void)
{
	return this_cpu_read(xen_vcpu_info.arch.cr2);
}

static void xen_flush_tlb(void)
{
	struct mmuext_op *op;
	struct multicall_space mcs;

	trace_xen_mmu_flush_tlb(0);

	preempt_disable();

	mcs = xen_mc_entry(sizeof(*op));

	op = mcs.args;
	op->cmd = MMUEXT_TLB_FLUSH_LOCAL;
	MULTI_mmuext_op(mcs.mc, op, 1, NULL, DOMID_SELF);

	xen_mc_issue(PARAVIRT_LAZY_MMU);

	preempt_enable();
}

static void xen_flush_tlb_single(unsigned long addr)
{
	struct mmuext_op *op;
	struct multicall_space mcs;

	trace_xen_mmu_flush_tlb_single(addr);

	preempt_disable();

	mcs = xen_mc_entry(sizeof(*op));
	op = mcs.args;
	op->cmd = MMUEXT_INVLPG_LOCAL;
	op->arg1.linear_addr = addr & PAGE_MASK;
	MULTI_mmuext_op(mcs.mc, op, 1, NULL, DOMID_SELF);

	xen_mc_issue(PARAVIRT_LAZY_MMU);

	preempt_enable();
}

static void xen_flush_tlb_others(const struct cpumask *cpus,
				 struct mm_struct *mm, unsigned long start,
				 unsigned long end)
{
	struct {
		struct mmuext_op op;
#ifdef CONFIG_SMP
		DECLARE_BITMAP(mask, num_processors);
#else
		DECLARE_BITMAP(mask, NR_CPUS);
#endif
	} *args;
	struct multicall_space mcs;

	trace_xen_mmu_flush_tlb_others(cpus, mm, start, end);

	if (cpumask_empty(cpus))
		return;		/* nothing to do */

	mcs = xen_mc_entry(sizeof(*args));
	args = mcs.args;
	args->op.arg2.vcpumask = to_cpumask(args->mask);

	/* Remove us, and any offline CPUS. */
	cpumask_and(to_cpumask(args->mask), cpus, cpu_online_mask);
	cpumask_clear_cpu(smp_processor_id(), to_cpumask(args->mask));

	args->op.cmd = MMUEXT_TLB_FLUSH_MULTI;
	if (start != TLB_FLUSH_ALL && (end - start) <= PAGE_SIZE) {
		args->op.cmd = MMUEXT_INVLPG_MULTI;
		args->op.arg1.linear_addr = start;
	}

	MULTI_mmuext_op(mcs.mc, &args->op, 1, NULL, DOMID_SELF);

	xen_mc_issue(PARAVIRT_LAZY_MMU);
}

static unsigned long xen_read_cr3(void)
{
	return this_cpu_read(xen_cr3);
}

static void set_current_cr3(void *v)
{
	this_cpu_write(xen_current_cr3, (unsigned long)v);
}

static void __xen_write_cr3(bool kernel, unsigned long cr3)
{
	struct mmuext_op op;
	unsigned long mfn;

	trace_xen_mmu_write_cr3(kernel, cr3);

	if (cr3)
		mfn = pfn_to_mfn(PFN_DOWN(cr3));
	else
		mfn = 0;

	WARN_ON(mfn == 0 && kernel);

	op.cmd = kernel ? MMUEXT_NEW_BASEPTR : MMUEXT_NEW_USER_BASEPTR;
	op.arg1.mfn = mfn;

	xen_extend_mmuext_op(&op);

	if (kernel) {
		this_cpu_write(xen_cr3, cr3);

		/* Update xen_current_cr3 once the batch has actually
		   been submitted. */
		xen_mc_callback(set_current_cr3, (void *)cr3);
	}
}

static void xen_write_cr3(unsigned long cr3)
{
	BUG_ON(preemptible());

	xen_mc_batch();  /* disables interrupts */

	/* Update while interrupts are disabled, so its atomic with
	   respect to ipis */
	this_cpu_write(xen_cr3, cr3);

	__xen_write_cr3(true, cr3);

#ifdef CONFIG_X86_64
	{
		pgd_t *user_pgd = xen_get_user_pgd(__va(cr3));
		if (user_pgd)
			__xen_write_cr3(false, __pa(user_pgd));
		else
			__xen_write_cr3(false, 0);
	}
#endif

	xen_mc_issue(PARAVIRT_LAZY_CPU);  /* interrupts restored */
}

static int xen_pgd_alloc(struct mm_struct *mm)
{
	pgd_t *pgd = mm->pgd;
	int ret = 0;

	BUG_ON(PagePinned(virt_to_page(pgd)));

#ifdef CONFIG_X86_64
	{
		struct page *page = virt_to_page(pgd);
		pgd_t *user_pgd;

		BUG_ON(page->private != 0);

		ret = -ENOMEM;

		user_pgd = (pgd_t *)__get_free_page(GFP_KERNEL | __GFP_ZERO);
		page->private = (unsigned long)user_pgd;

		if (user_pgd != NULL) {
			user_pgd[pgd_index(VSYSCALL_START)] =
				__pgd(__pa(level3_user_vsyscall) | _PAGE_TABLE);
			ret = 0;
		}

		BUG_ON(PagePinned(virt_to_page(xen_get_user_pgd(pgd))));
	}
#endif

	return ret;
}

static void xen_pgd_free(struct mm_struct *mm, pgd_t *pgd)
{
#ifdef CONFIG_X86_64
	pgd_t *user_pgd = xen_get_user_pgd(pgd);

	if (user_pgd)
		free_page((unsigned long)user_pgd);
#endif
}

#ifdef CONFIG_X86_32
static pte_t __init mask_rw_pte(pte_t *ptep, pte_t pte)
{
	/* If there's an existing pte, then don't allow _PAGE_RW to be set */
	if (pte_val_ma(*ptep) & _PAGE_PRESENT)
		pte = __pte_ma(((pte_val_ma(*ptep) & _PAGE_RW) | ~_PAGE_RW) &
			       pte_val_ma(pte));

	return pte;
}
#else /* CONFIG_X86_64 */
static pte_t __init mask_rw_pte(pte_t *ptep, pte_t pte)
{
	unsigned long pfn = pte_pfn(pte);

	/*
	 * If the new pfn is within the range of the newly allocated
	 * kernel pagetable, and it isn't being mapped into an
	 * early_ioremap fixmap slot as a freshly allocated page, make sure
	 * it is RO.
	 */
	if (((!is_early_ioremap_ptep(ptep) &&
			pfn >= pgt_buf_start && pfn < pgt_buf_top)) ||
			(is_early_ioremap_ptep(ptep) && pfn != (pgt_buf_end - 1)))
		pte = pte_wrprotect(pte);

	return pte;
}
#endif /* CONFIG_X86_64 */

/*
 * Init-time set_pte while constructing initial pagetables, which
 * doesn't allow RO page table pages to be remapped RW.
 *
 * If there is no MFN for this PFN then this page is initially
 * ballooned out so clear the PTE (as in decrease_reservation() in
 * drivers/xen/balloon.c).
 *
 * Many of these PTE updates are done on unpinned and writable pages
 * and doing a hypercall for these is unnecessary and expensive.  At
 * this point it is not possible to tell if a page is pinned or not,
 * so always write the PTE directly and rely on Xen trapping and
 * emulating any updates as necessary.
 */
static void __init xen_set_pte_init(pte_t *ptep, pte_t pte)
{
	if (pte_mfn(pte) != INVALID_P2M_ENTRY)
		pte = mask_rw_pte(ptep, pte);
	else
		pte = __pte_ma(0);

	native_set_pte(ptep, pte);
}

static noinline void pin_pagetable_pfn(unsigned cmd, unsigned long pfn)
{
	struct mmuext_op op;

	if (xen_feature(XENFEAT_writable_page_tables))
		return;

	op.cmd = cmd;
	op.arg1.mfn = pfn_to_mfn(pfn);
	if (HYPERVISOR_mmuext_op(&op, 1, NULL, DOMID_SELF))
		BUG();
}

/* Early in boot, while setting up the initial pagetable, assume
   everything is pinned. */
static void __init xen_alloc_pte_init(struct mm_struct *mm, unsigned long pfn)
{
#ifdef CONFIG_FLATMEM
	BUG_ON(mem_map);	/* should only be used early */
#endif
	make_lowmem_page_readonly(__va(PFN_PHYS(pfn)));
	pin_pagetable_pfn(MMUEXT_PIN_L1_TABLE, pfn);
}

/* Used for pmd and pud */
static void __init xen_alloc_pmd_init(struct mm_struct *mm, unsigned long pfn)
{
#ifdef CONFIG_FLATMEM
	BUG_ON(mem_map);	/* should only be used early */
#endif
	make_lowmem_page_readonly(__va(PFN_PHYS(pfn)));
}

/* Early release_pte assumes that all pts are pinned, since there's
   only init_mm and anything attached to that is pinned. */
static void __init xen_release_pte_init(unsigned long pfn)
{
	pin_pagetable_pfn(MMUEXT_UNPIN_TABLE, pfn);
	make_lowmem_page_readwrite(__va(PFN_PHYS(pfn)));
}

static void __init xen_release_pmd_init(unsigned long pfn)
{
	make_lowmem_page_readwrite(__va(PFN_PHYS(pfn)));
}

static inline void __pin_pagetable_pfn(unsigned cmd, unsigned long pfn)
{
	struct multicall_space mcs;
	struct mmuext_op *op;

	mcs = __xen_mc_entry(sizeof(*op));
	op = mcs.args;
	op->cmd = cmd;
	op->arg1.mfn = pfn_to_mfn(pfn);

	MULTI_mmuext_op(mcs.mc, mcs.args, 1, NULL, DOMID_SELF);
}

static inline void __set_pfn_prot(unsigned long pfn, pgprot_t prot)
{
	struct multicall_space mcs;
	unsigned long addr = (unsigned long)__va(pfn << PAGE_SHIFT);

	mcs = __xen_mc_entry(0);
	MULTI_update_va_mapping(mcs.mc, (unsigned long)addr,
				pfn_pte(pfn, prot), 0);
}

/* This needs to make sure the new pte page is pinned iff its being
   attached to a pinned pagetable. */
static inline void xen_alloc_ptpage(struct mm_struct *mm, unsigned long pfn,
				    unsigned level)
{
	bool pinned = PagePinned(virt_to_page(mm->pgd));

	trace_xen_mmu_alloc_ptpage(mm, pfn, level, pinned);

	if (pinned) {
		struct page *page = pfn_to_page(pfn);

		SetPagePinned(page);

		if (!PageHighMem(page)) {
			xen_mc_batch();

			__set_pfn_prot(pfn, PAGE_KERNEL_RO);

			if (level == PT_PTE && USE_SPLIT_PTLOCKS)
				__pin_pagetable_pfn(MMUEXT_PIN_L1_TABLE, pfn);

			xen_mc_issue(PARAVIRT_LAZY_MMU);
		} else {
			/* make sure there are no stray mappings of
			   this page */
			kmap_flush_unused();
		}
	}
}

static void xen_alloc_pte(struct mm_struct *mm, unsigned long pfn)
{
	xen_alloc_ptpage(mm, pfn, PT_PTE);
}

static void xen_alloc_pmd(struct mm_struct *mm, unsigned long pfn)
{
	xen_alloc_ptpage(mm, pfn, PT_PMD);
}

/* This should never happen until we're OK to use struct page */
static inline void xen_release_ptpage(unsigned long pfn, unsigned level)
{
	struct page *page = pfn_to_page(pfn);
	bool pinned = PagePinned(page);

	trace_xen_mmu_release_ptpage(pfn, level, pinned);

	if (pinned) {
		if (!PageHighMem(page)) {
			xen_mc_batch();

			if (level == PT_PTE && USE_SPLIT_PTLOCKS)
				__pin_pagetable_pfn(MMUEXT_UNPIN_TABLE, pfn);

			__set_pfn_prot(pfn, PAGE_KERNEL);

			xen_mc_issue(PARAVIRT_LAZY_MMU);
		}
		ClearPagePinned(page);
	}
}

static void xen_release_pte(unsigned long pfn)
{
	xen_release_ptpage(pfn, PT_PTE);
}

static void xen_release_pmd(unsigned long pfn)
{
	xen_release_ptpage(pfn, PT_PMD);
}

#if PAGETABLE_LEVELS == 4
static void xen_alloc_pud(struct mm_struct *mm, unsigned long pfn)
{
	xen_alloc_ptpage(mm, pfn, PT_PUD);
}

static void xen_release_pud(unsigned long pfn)
{
	xen_release_ptpage(pfn, PT_PUD);
}
#endif

void __init xen_reserve_top(void)
{
#ifdef CONFIG_X86_32
	unsigned long top = HYPERVISOR_VIRT_START;
	struct xen_platform_parameters pp;

	if (HYPERVISOR_xen_version(XENVER_platform_parameters, &pp) == 0)
		top = pp.virt_start;

	reserve_top_address(-top);
#endif	/* CONFIG_X86_32 */
}

/*
 * Like __va(), but returns address in the kernel mapping (which is
 * all we have until the physical memory mapping has been set up.
 */
static void *__ka(phys_addr_t paddr)
{
#ifdef CONFIG_X86_64
	return (void *)(paddr + __START_KERNEL_map);
#else
	return __va(paddr);
#endif
}

/* Convert a machine address to physical address */
static unsigned long m2p(phys_addr_t maddr)
{
	phys_addr_t paddr;

	maddr &= PTE_PFN_MASK;
	paddr = mfn_to_pfn(maddr >> PAGE_SHIFT) << PAGE_SHIFT;

	return paddr;
}

/* Convert a machine address to kernel virtual */
static void *m2v(phys_addr_t maddr)
{
	return __ka(m2p(maddr));
}

/* Set the page permissions on an identity-mapped pages */
static void set_page_prot(void *addr, pgprot_t prot)
{
	unsigned long pfn = __pa(addr) >> PAGE_SHIFT;
	pte_t pte = pfn_pte(pfn, prot);

	/* recall for PVH, page tables are native. */
	if (xen_feature(XENFEAT_auto_translated_physmap))
		return;

	if (HYPERVISOR_update_va_mapping((unsigned long)addr, pte, 0))
		BUG();
}

static void __init xen_map_identity_early(pmd_t *pmd, unsigned long max_pfn)
{
	unsigned pmdidx, pteidx;
	unsigned ident_pte;
	unsigned long pfn;

	level1_ident_pgt = extend_brk(sizeof(pte_t) * LEVEL1_IDENT_ENTRIES,
				      PAGE_SIZE);

	ident_pte = 0;
	pfn = 0;
	for (pmdidx = 0; pmdidx < PTRS_PER_PMD && pfn < max_pfn; pmdidx++) {
		pte_t *pte_page;

		/* Reuse or allocate a page of ptes */
		if (pmd_present(pmd[pmdidx]))
			pte_page = m2v(pmd[pmdidx].pmd);
		else {
			/* Check for free pte pages */
			if (ident_pte == LEVEL1_IDENT_ENTRIES)
				break;

			pte_page = &level1_ident_pgt[ident_pte];
			ident_pte += PTRS_PER_PTE;

			pmd[pmdidx] = __pmd(__pa(pte_page) | _PAGE_TABLE);
		}

		/* Install mappings */
		for (pteidx = 0; pteidx < PTRS_PER_PTE; pteidx++, pfn++) {
			pte_t pte;

#ifdef CONFIG_X86_32
			if (pfn > max_pfn_mapped)
				max_pfn_mapped = pfn;
#endif

			if (!pte_none(pte_page[pteidx]))
				continue;

			pte = pfn_pte(pfn, PAGE_KERNEL_EXEC);
			pte_page[pteidx] = pte;
		}
	}

	for (pteidx = 0; pteidx < ident_pte; pteidx += PTRS_PER_PTE)
		set_page_prot(&level1_ident_pgt[pteidx], PAGE_KERNEL_RO);

	set_page_prot(pmd, PAGE_KERNEL_RO);
}

void __init xen_setup_machphys_mapping(void)
{
	struct xen_machphys_mapping mapping;

	if (HYPERVISOR_memory_op(XENMEM_machphys_mapping, &mapping) == 0) {
		machine_to_phys_mapping = (unsigned long *)mapping.v_start;
		machine_to_phys_nr = mapping.max_mfn + 1;
	} else {
		machine_to_phys_nr = MACH2PHYS_NR_ENTRIES;
	}
#ifdef CONFIG_X86_32
	WARN_ON((machine_to_phys_mapping + (machine_to_phys_nr - 1))
		< machine_to_phys_mapping);
#endif
}

#ifdef CONFIG_X86_64
static void convert_pfn_mfn(void *v)
{
	pte_t *pte = v;
	int i;

	if (xen_feature(XENFEAT_auto_translated_physmap))
		return;

	/* All levels are converted the same way, so just treat them
	   as ptes. */
	for (i = 0; i < PTRS_PER_PTE; i++)
		pte[i] = xen_make_pte(pte[i].pte);
}

/*
 * Set up the initial kernel pagetable.
 *
 * We can construct this by grafting the Xen provided pagetable into
 * head_64.S's preconstructed pagetables.  We copy the Xen L2's into
 * level2_ident_pgt, level2_kernel_pgt and level2_fixmap_pgt.  This
 * means that only the kernel has a physical mapping to start with -
 * but that's enough to get __va working.  We need to fill in the rest
 * of the physical mapping once some sort of allocator has been set
 * up.
 * NOTE: for PVH, the page tables are native.
 */
pgd_t * __init xen_setup_kernel_pagetable(pgd_t *pgd,
					 unsigned long max_pfn)
{
	pud_t *l3;
	pmd_t *l2;

	/* max_pfn_mapped is the last pfn mapped in the initial memory
	 * mappings. Considering that on Xen after the kernel mappings we
	 * have the mappings of some pages that don't exist in pfn space, we
	 * set max_pfn_mapped to the last real pfn mapped. */
	max_pfn_mapped = PFN_DOWN(__pa(xen_start_info->mfn_list));

	/* Zap identity mapping */
	init_level4_pgt[0] = __pgd(0);

	/* Pre-constructed entries are in pfn, so convert to mfn */
	convert_pfn_mfn(init_level4_pgt);
	convert_pfn_mfn(level3_ident_pgt);
	convert_pfn_mfn(level3_kernel_pgt);

	l3 = m2v(pgd[pgd_index(__START_KERNEL_map)].pgd);
	l2 = m2v(l3[pud_index(__START_KERNEL_map)].pud);

	memcpy(level2_ident_pgt, l2, sizeof(pmd_t) * PTRS_PER_PMD);
	memcpy(level2_kernel_pgt, l2, sizeof(pmd_t) * PTRS_PER_PMD);

	l3 = m2v(pgd[pgd_index(__START_KERNEL_map + PMD_SIZE)].pgd);
	l2 = m2v(l3[pud_index(__START_KERNEL_map + PMD_SIZE)].pud);
	memcpy(level2_fixmap_pgt, l2, sizeof(pmd_t) * PTRS_PER_PMD);

	/* Set up identity map */
	xen_map_identity_early(level2_ident_pgt, max_pfn);

	/* Make pagetable pieces RO */
	set_page_prot(init_level4_pgt, PAGE_KERNEL_RO);
	set_page_prot(level3_ident_pgt, PAGE_KERNEL_RO);
	set_page_prot(level3_kernel_pgt, PAGE_KERNEL_RO);
	set_page_prot(level3_user_vsyscall, PAGE_KERNEL_RO);
	set_page_prot(level2_kernel_pgt, PAGE_KERNEL_RO);
	set_page_prot(level2_fixmap_pgt, PAGE_KERNEL_RO);

	/* Pin down new L4 */
	pin_pagetable_pfn(MMUEXT_PIN_L4_TABLE,
		  	PFN_DOWN(__pa_symbol(init_level4_pgt)));

	/* Unpin Xen-provided one */
	pin_pagetable_pfn(MMUEXT_UNPIN_TABLE, PFN_DOWN(__pa(pgd)));

	/* Switch over */
	pgd = init_level4_pgt;

	/*
	 * At this stage there can be no user pgd, and no page
	 * structure to attach it to, so make sure we just set kernel
	 * pgd.
	 */
	if (xen_feature(XENFEAT_writable_page_tables)) {
		native_write_cr3(__pa(pgd));
	} else {
		xen_mc_batch();
		__xen_write_cr3(true, __pa(pgd));
		xen_mc_issue(PARAVIRT_LAZY_CPU);
	}

	memblock_reserve(__pa(xen_start_info->pt_base),
			 xen_start_info->nr_pt_frames * PAGE_SIZE);

	return pgd;
}
#else	/* !CONFIG_X86_64 */
static RESERVE_BRK_ARRAY(pmd_t, initial_kernel_pmd, PTRS_PER_PMD);
static RESERVE_BRK_ARRAY(pmd_t, swapper_kernel_pmd, PTRS_PER_PMD);

static void __init xen_write_cr3_init(unsigned long cr3)
{
	unsigned long pfn = PFN_DOWN(__pa(swapper_pg_dir));

	BUG_ON(read_cr3() != __pa(initial_page_table));
	BUG_ON(cr3 != __pa(swapper_pg_dir));

	/*
	 * We are switching to swapper_pg_dir for the first time (from
	 * initial_page_table) and therefore need to mark that page
	 * read-only and then pin it.
	 *
	 * Xen disallows sharing of kernel PMDs for PAE
	 * guests. Therefore we must copy the kernel PMD from
	 * initial_page_table into a new kernel PMD to be used in
	 * swapper_pg_dir.
	 */
	swapper_kernel_pmd =
		extend_brk(sizeof(pmd_t) * PTRS_PER_PMD, PAGE_SIZE);
	memcpy(swapper_kernel_pmd, initial_kernel_pmd,
	       sizeof(pmd_t) * PTRS_PER_PMD);
	swapper_pg_dir[KERNEL_PGD_BOUNDARY] =
		__pgd(__pa(swapper_kernel_pmd) | _PAGE_PRESENT);
	set_page_prot(swapper_kernel_pmd, PAGE_KERNEL_RO);

	set_page_prot(swapper_pg_dir, PAGE_KERNEL_RO);
	xen_write_cr3(cr3);
	pin_pagetable_pfn(MMUEXT_PIN_L3_TABLE, pfn);

	pin_pagetable_pfn(MMUEXT_UNPIN_TABLE,
			  PFN_DOWN(__pa(initial_page_table)));
	set_page_prot(initial_page_table, PAGE_KERNEL);
	set_page_prot(initial_kernel_pmd, PAGE_KERNEL);

	pv_mmu_ops.write_cr3 = &xen_write_cr3;
}

pgd_t * __init xen_setup_kernel_pagetable(pgd_t *pgd,
					 unsigned long max_pfn)
{
	pmd_t *kernel_pmd;

	initial_kernel_pmd =
		extend_brk(sizeof(pmd_t) * PTRS_PER_PMD, PAGE_SIZE);

	max_pfn_mapped = PFN_DOWN(__pa(xen_start_info->pt_base) +
				  xen_start_info->nr_pt_frames * PAGE_SIZE +
				  512*1024);

	kernel_pmd = m2v(pgd[KERNEL_PGD_BOUNDARY].pgd);
	memcpy(initial_kernel_pmd, kernel_pmd, sizeof(pmd_t) * PTRS_PER_PMD);

	xen_map_identity_early(initial_kernel_pmd, max_pfn);

	memcpy(initial_page_table, pgd, sizeof(pgd_t) * PTRS_PER_PGD);
	initial_page_table[KERNEL_PGD_BOUNDARY] =
		__pgd(__pa(initial_kernel_pmd) | _PAGE_PRESENT);

	set_page_prot(initial_kernel_pmd, PAGE_KERNEL_RO);
	set_page_prot(initial_page_table, PAGE_KERNEL_RO);
	set_page_prot(empty_zero_page, PAGE_KERNEL_RO);

	pin_pagetable_pfn(MMUEXT_UNPIN_TABLE, PFN_DOWN(__pa(pgd)));

	pin_pagetable_pfn(MMUEXT_PIN_L3_TABLE,
			  PFN_DOWN(__pa(initial_page_table)));
	xen_write_cr3(__pa(initial_page_table));

	memblock_reserve(__pa(xen_start_info->pt_base),
			 xen_start_info->nr_pt_frames * PAGE_SIZE);

	return initial_page_table;
}
#endif	/* CONFIG_X86_64 */

static unsigned char dummy_mapping[PAGE_SIZE] __page_aligned_bss;

static void xen_set_fixmap(unsigned idx, phys_addr_t phys, pgprot_t prot)
{
	pte_t pte;

	phys >>= PAGE_SHIFT;

	switch (idx) {
	case FIX_BTMAP_END ... FIX_BTMAP_BEGIN:
#ifdef CONFIG_X86_F00F_BUG
	case FIX_F00F_IDT:
#endif
#ifdef CONFIG_X86_32
	case FIX_WP_TEST:
	case FIX_VDSO:
# ifdef CONFIG_HIGHMEM
	case FIX_KMAP_BEGIN ... FIX_KMAP_END:
# endif
#else
	case VSYSCALL_LAST_PAGE ... VSYSCALL_FIRST_PAGE:
	case VVAR_PAGE:
#endif
	case FIX_TEXT_POKE0:
	case FIX_TEXT_POKE1:
		/* All local page mappings */
		pte = pfn_pte(phys, prot);
		break;

#ifdef CONFIG_X86_LOCAL_APIC
	case FIX_APIC_BASE:	/* maps dummy local APIC */
		pte = pfn_pte(PFN_DOWN(__pa(dummy_mapping)), PAGE_KERNEL);
		break;
#endif

#ifdef CONFIG_X86_IO_APIC
	case FIX_IO_APIC_BASE_0 ... FIX_IO_APIC_BASE_END:
		/*
		 * We just don't map the IO APIC - all access is via
		 * hypercalls.  Keep the address in the pte for reference.
		 */
		pte = pfn_pte(PFN_DOWN(__pa(dummy_mapping)), PAGE_KERNEL);
		break;
#endif

	case FIX_PARAVIRT_BOOTMAP:
		/* This is an MFN, but it isn't an IO mapping from the
		   IO domain */
		pte = mfn_pte(phys, prot);
		break;

	default:
		/* By default, set_fixmap is used for hardware mappings */
		pte = mfn_pte(phys, __pgprot(pgprot_val(prot) | _PAGE_IOMAP));
		break;
	}

	__native_set_fixmap(idx, pte);

#ifdef CONFIG_X86_64
	/* Replicate changes to map the vsyscall page into the user
	   pagetable vsyscall mapping. */
	if ((idx >= VSYSCALL_LAST_PAGE && idx <= VSYSCALL_FIRST_PAGE) ||
	    idx == VVAR_PAGE) {
		unsigned long vaddr = __fix_to_virt(idx);
		set_pte_vaddr_pud(level3_user_vsyscall, vaddr, pte);
	}
#endif
}

static void __init xen_post_allocator_init(void)
{
	pv_mmu_ops.set_pte = xen_set_pte;
	pv_mmu_ops.set_pmd = xen_set_pmd;
	pv_mmu_ops.set_pud = xen_set_pud;
#if PAGETABLE_LEVELS == 4
	pv_mmu_ops.set_pgd = xen_set_pgd;
#endif

	/* This will work as long as patching hasn't happened yet
	   (which it hasn't) */
	pv_mmu_ops.alloc_pte = xen_alloc_pte;
	pv_mmu_ops.alloc_pmd = xen_alloc_pmd;
	pv_mmu_ops.release_pte = xen_release_pte;
	pv_mmu_ops.release_pmd = xen_release_pmd;
#if PAGETABLE_LEVELS == 4
	pv_mmu_ops.alloc_pud = xen_alloc_pud;
	pv_mmu_ops.release_pud = xen_release_pud;
#endif

#ifdef CONFIG_X86_64
	SetPagePinned(virt_to_page(level3_user_vsyscall));
#endif
	xen_mark_init_mm_pinned();
}

static void xen_leave_lazy_mmu(void)
{
	preempt_disable();
	xen_mc_flush();
	paravirt_leave_lazy_mmu();
	preempt_enable();
}

static const struct pv_mmu_ops xen_mmu_ops __initconst = {
	.read_cr2 = xen_read_cr2,
	.write_cr2 = xen_write_cr2,

	.read_cr3 = xen_read_cr3,
#ifdef CONFIG_X86_32
	.write_cr3 = xen_write_cr3_init,
#else
	.write_cr3 = xen_write_cr3,
#endif

	.flush_tlb_user = xen_flush_tlb,
	.flush_tlb_kernel = xen_flush_tlb,
	.flush_tlb_single = xen_flush_tlb_single,
	.flush_tlb_others = xen_flush_tlb_others,

	.pte_update = paravirt_nop,
	.pte_update_defer = paravirt_nop,

	.pgd_alloc = xen_pgd_alloc,
	.pgd_free = xen_pgd_free,

	.alloc_pte = xen_alloc_pte_init,
	.release_pte = xen_release_pte_init,
	.alloc_pmd = xen_alloc_pmd_init,
	.release_pmd = xen_release_pmd_init,

	.set_pte = xen_set_pte_init,
	.set_pte_at = xen_set_pte_at,
	.set_pmd = xen_set_pmd_hyper,

	.ptep_modify_prot_start = __ptep_modify_prot_start,
	.ptep_modify_prot_commit = __ptep_modify_prot_commit,

	.pte_val = PV_CALLEE_SAVE(xen_pte_val),
	.pgd_val = PV_CALLEE_SAVE(xen_pgd_val),

	.make_pte = PV_CALLEE_SAVE(xen_make_pte),
	.make_pgd = PV_CALLEE_SAVE(xen_make_pgd),

#ifdef CONFIG_X86_PAE
	.set_pte_atomic = xen_set_pte_atomic,
	.pte_clear = xen_pte_clear,
	.pmd_clear = xen_pmd_clear,
#endif	/* CONFIG_X86_PAE */
	.set_pud = xen_set_pud_hyper,

	.make_pmd = PV_CALLEE_SAVE(xen_make_pmd),
	.pmd_val = PV_CALLEE_SAVE(xen_pmd_val),

#if PAGETABLE_LEVELS == 4
	.pud_val = PV_CALLEE_SAVE(xen_pud_val),
	.make_pud = PV_CALLEE_SAVE(xen_make_pud),
	.set_pgd = xen_set_pgd_hyper,

	.alloc_pud = xen_alloc_pmd_init,
	.release_pud = xen_release_pmd_init,
#endif	/* PAGETABLE_LEVELS == 4 */

	.activate_mm = xen_activate_mm,
	.dup_mmap = xen_dup_mmap,
	.exit_mmap = xen_exit_mmap,

	.lazy_mode = {
		.enter = paravirt_enter_lazy_mmu,
		.leave = xen_leave_lazy_mmu,
	},

	.set_fixmap = xen_set_fixmap,
};

void __init xen_init_mmu_ops(void)
{
	x86_init.paging.pagetable_setup_done = xen_pagetable_setup_done;

	if (xen_feature(XENFEAT_auto_translated_physmap)) {
		pv_mmu_ops.flush_tlb_others = xen_flush_tlb_others;

		/* set_pte* for PCI devices to map iomem. */
		if (xen_initial_domain()) {
			pv_mmu_ops.set_pte = native_set_pte;
			pv_mmu_ops.set_pte_at = xen_dom0pvh_set_pte_at;
		}
		return;
	}

	x86_init.mapping.pagetable_reserve = xen_mapping_pagetable_reserve;
	x86_init.paging.pagetable_setup_start = xen_pagetable_setup_start;
	pv_mmu_ops = xen_mmu_ops;

	memset(dummy_mapping, 0xff, PAGE_SIZE);
}

/* Protected by xen_reservation_lock. */
#define MAX_CONTIG_ORDER 9 /* 2MB */
static unsigned long discontig_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,
				unsigned long *in_frames,
				unsigned long *out_frames)
{
	int i;
	struct multicall_space mcs;

	xen_mc_batch();
	for (i = 0; i < (1UL<<order); i++, vaddr += PAGE_SIZE) {
		mcs = __xen_mc_entry(0);

		if (in_frames)
			in_frames[i] = virt_to_mfn(vaddr);

		MULTI_update_va_mapping(mcs.mc, vaddr, VOID_PTE, 0);
		__set_phys_to_machine(virt_to_pfn(vaddr), INVALID_P2M_ENTRY);

		if (out_frames)
			out_frames[i] = virt_to_pfn(vaddr);
	}
	xen_mc_issue(0);
}

/*
 * Update the pfn-to-mfn mappings for a virtual address range, either to
 * point to an array of mfns, or contiguously from a single starting
 * mfn.
 */
static void xen_remap_exchanged_ptes(unsigned long vaddr, int order,
				     unsigned long *mfns,
				     unsigned long first_mfn)
{
	unsigned i, limit;
	unsigned long mfn;

	xen_mc_batch();

	limit = 1u << order;
	for (i = 0; i < limit; i++, vaddr += PAGE_SIZE) {
		struct multicall_space mcs;
		unsigned flags;

		mcs = __xen_mc_entry(0);
		if (mfns)
			mfn = mfns[i];
		else
			mfn = first_mfn + i;

		if (i < (limit - 1))
			flags = 0;
		else {
			if (order == 0)
				flags = UVMF_INVLPG | UVMF_ALL;
			else
				flags = UVMF_TLB_FLUSH | UVMF_ALL;
		}

		MULTI_update_va_mapping(mcs.mc, vaddr,
				mfn_pte(mfn, PAGE_KERNEL), flags);

		set_phys_to_machine(virt_to_pfn(vaddr), mfn);
	}

	xen_mc_issue(0);
}

/*
 * Perform the hypercall to exchange a region of our pfns to point to
 * memory with the required contiguous alignment.  Takes the pfns as
 * input, and populates mfns as output.
 *
 * Returns a success code indicating whether the hypervisor was able to
 * satisfy the request or not.
 */
static int xen_exchange_memory(unsigned long extents_in, unsigned int order_in,
			       unsigned long *pfns_in,
			       unsigned long extents_out,
			       unsigned int order_out,
			       unsigned long *mfns_out,
			       unsigned int address_bits)
{
	long rc;
	int success;

	struct xen_memory_exchange exchange = {
		.in = {
			.nr_extents   = extents_in,
			.extent_order = order_in,
			.extent_start = pfns_in,
			.domid        = DOMID_SELF
		},
		.out = {
			.nr_extents   = extents_out,
			.extent_order = order_out,
			.extent_start = mfns_out,
			.address_bits = address_bits,
			.domid        = DOMID_SELF
		}
	};

	BUG_ON(extents_in << order_in != extents_out << order_out);

	rc = HYPERVISOR_memory_op(XENMEM_exchange, &exchange);
	success = (exchange.nr_exchanged == extents_in);

	BUG_ON(!success && ((exchange.nr_exchanged != 0) || (rc == 0)));
	BUG_ON(success && (rc != 0));

	return success;
}

int xen_create_contiguous_region(unsigned long vstart, unsigned int order,
				 unsigned int address_bits)
{
	unsigned long *in_frames = discontig_frames, out_frame;
	unsigned long  flags;
	int            success;

	/*
	 * Currently an auto-translated guest will not perform I/O, nor will
	 * it require PAE page directories below 4GB. Therefore any calls to
	 * this function are redundant and can be ignored.
	 */

	if (xen_feature(XENFEAT_auto_translated_physmap))
		return 0;

	if (unlikely(order > MAX_CONTIG_ORDER))
		return -ENOMEM;

	memset((void *) vstart, 0, PAGE_SIZE << order);

	spin_lock_irqsave(&xen_reservation_lock, flags);

	/* 1. Zap current PTEs, remembering MFNs. */
	xen_zap_pfn_range(vstart, order, in_frames, NULL);

	/* 2. Get a new contiguous memory extent. */
	out_frame = virt_to_pfn(vstart);
	success = xen_exchange_memory(1UL << order, 0, in_frames,
				      1, order, &out_frame,
				      address_bits);

	/* 3. Map the new extent in place of old pages. */
	if (success)
		xen_remap_exchanged_ptes(vstart, order, NULL, out_frame);
	else
		xen_remap_exchanged_ptes(vstart, order, in_frames, 0);

	spin_unlock_irqrestore(&xen_reservation_lock, flags);

	return success ? 0 : -ENOMEM;
}
EXPORT_SYMBOL_GPL(xen_create_contiguous_region);

void xen_destroy_contiguous_region(unsigned long vstart, unsigned int order)
{
	unsigned long *out_frames = discontig_frames, in_frame;
	unsigned long  flags;
	int success;

	if (xen_feature(XENFEAT_auto_translated_physmap))
		return;

	if (unlikely(order > MAX_CONTIG_ORDER))
		return;

	memset((void *) vstart, 0, PAGE_SIZE << order);

	spin_lock_irqsave(&xen_reservation_lock, flags);

	/* 1. Find start MFN of contiguous extent. */
	in_frame = virt_to_mfn(vstart);

	/* 2. Zap current PTEs. */
	xen_zap_pfn_range(vstart, order, NULL, out_frames);

	/* 3. Do the exchange for non-contiguous MFNs. */
	success = xen_exchange_memory(1, order, &in_frame, 1UL << order,
					0, out_frames, 0);

	/* 4. Map new pages in place of old pages. */
	if (success)
		xen_remap_exchanged_ptes(vstart, order, out_frames, 0);
	else
		xen_remap_exchanged_ptes(vstart, order, NULL, in_frame);

	spin_unlock_irqrestore(&xen_reservation_lock, flags);
}
EXPORT_SYMBOL_GPL(xen_destroy_contiguous_region);

#ifdef CONFIG_XEN_PVHVM
static void xen_hvm_exit_mmap(struct mm_struct *mm)
{
	struct xen_hvm_pagetable_dying a;
	int rc;

	a.domid = DOMID_SELF;
	a.gpa = __pa(mm->pgd);
	rc = HYPERVISOR_hvm_op(HVMOP_pagetable_dying, &a);
	WARN_ON_ONCE(rc < 0);
}

static int is_pagetable_dying_supported(void)
{
	struct xen_hvm_pagetable_dying a;
	int rc = 0;

	a.domid = DOMID_SELF;
	a.gpa = 0x00;
	rc = HYPERVISOR_hvm_op(HVMOP_pagetable_dying, &a);
	if (rc < 0) {
		printk(KERN_DEBUG "HVMOP_pagetable_dying not supported\n");
		return 0;
	}
	return 1;
}

void __init xen_hvm_init_mmu_ops(void)
{
	if (is_pagetable_dying_supported())
		pv_mmu_ops.exit_mmap = xen_hvm_exit_mmap;
}
#endif

/* Map foreign gmfn, fgmfn, to local pfn, lpfn. This for the user space 
 * creating new guest on PVH dom0 and needs to map domU pages. Called from
 * exported function, so no need to export this.
 */
static noinline int pvh_add_to_xen_p2m(unsigned long lpfn, unsigned long fgmfn,
			      unsigned int domid)
{
	int rc;
	struct xen_add_to_physmap xatp = { .foreign_domid = domid };

	xatp.gpfn = lpfn;
	xatp.idx = fgmfn;
	xatp.domid = DOMID_SELF;
	xatp.space = XENMAPSPACE_gmfn_foreign;
	rc = HYPERVISOR_memory_op(XENMEM_add_to_physmap, &xatp);
	if (rc)
		pr_warn("d0: Failed to map pfn to mfn rc:%d pfn:%lx mfn:%lx\n", 
			rc, lpfn, fgmfn); 
	return rc;
}

int pvh_rem_xen_p2m(unsigned long spfn, int count)
{
	struct xen_remove_from_physmap xrp;
	int i, rc;

	for (i=0; i < count; i++) {
		xrp.domid = DOMID_SELF;
		xrp.gpfn = spfn+i;
		rc = HYPERVISOR_memory_op(XENMEM_remove_from_physmap, &xrp);
		if (rc) {
			pr_warn("Failed to unmap pfn:%lx rc:%d done:%d\n",
				spfn+i, rc, i);
			return 1;
		}
	}
	return 0;
}
EXPORT_SYMBOL_GPL(pvh_rem_xen_p2m);

struct pvh_remap_data {
	unsigned long fgmfn;		/* foreign domain's gmfn */
	pgprot_t prot;
	domid_t  domid;
	struct xen_pvh_pfn_info *pvhinfop;
};

static noinline int pvh_map_pte_fn(pte_t *ptep, pgtable_t token, unsigned long addr, 
			void *data)
{
	int rc;
	struct pvh_remap_data *remapp = data;
	struct xen_pvh_pfn_info *pvhp = remapp->pvhinfop;
	unsigned long pfn = page_to_pfn(pvhp->pi_paga[pvhp->pi_next_todo++]);
	pte_t pteval = pte_mkspecial(pfn_pte(pfn, remapp->prot));

	if ((rc=pvh_add_to_xen_p2m(pfn, remapp->fgmfn, remapp->domid)))
		return rc;
	native_set_pte(ptep, pteval);

	return 0;
}

/* The only caller at moment passes one gmfn at a time.
 * PVH TBD/FIXME: expand this in future to honor batch requests.
 */
static noinline int pvh_remap_gmfn_range(struct vm_area_struct *vma,
				unsigned long addr, unsigned long mfn, int nr,
				pgprot_t prot, unsigned domid,
				struct xen_pvh_pfn_info *pvhp)
{
	int err;
	struct pvh_remap_data pvhdata;

	if (nr > 1)
		return -EINVAL;

	pvhdata.fgmfn = mfn;
	pvhdata.prot = prot;
	pvhdata.domid = domid;
	pvhdata.pvhinfop = pvhp;
	err = apply_to_page_range(vma->vm_mm, addr, nr << PAGE_SHIFT,
				  pvh_map_pte_fn, &pvhdata);
	flush_tlb_all();
	return err;
}

#define REMAP_BATCH_SIZE 16

struct remap_data {
	unsigned long mfn;
	pgprot_t prot;
	struct mmu_update *mmu_update;
};

static int remap_area_mfn_pte_fn(pte_t *ptep, pgtable_t token,
				 unsigned long addr, void *data)
{
	struct remap_data *rmd = data;
	pte_t pte = pte_mkspecial(pfn_pte(rmd->mfn++, rmd->prot));

	rmd->mmu_update->ptr = virt_to_machine(ptep).maddr;
	rmd->mmu_update->val = pte_val_ma(pte);
	rmd->mmu_update++;

	return 0;
}

int xen_remap_domain_mfn_range(struct vm_area_struct *vma,
			       unsigned long addr,
			       unsigned long mfn, int nr,
			       pgprot_t prot, unsigned domid,
			       struct xen_pvh_pfn_info *pvhp)

{
	struct remap_data rmd;
	struct mmu_update mmu_update[REMAP_BATCH_SIZE];
	int batch;
	unsigned long range;
	int err = 0;

	prot = __pgprot(pgprot_val(prot) | _PAGE_IOMAP);

	BUG_ON(!((vma->vm_flags & (VM_PFNMAP | VM_RESERVED | VM_IO)) ==
				(VM_PFNMAP | VM_RESERVED | VM_IO)));

	if (xen_feature(XENFEAT_auto_translated_physmap)) {
		/* We need to update the local page tables and the xen HAP */
		return pvh_remap_gmfn_range(vma, addr, mfn, nr, prot, domid,
					    pvhp);
	}

	rmd.mfn = mfn;
	rmd.prot = prot;

	while (nr) {
		batch = min(REMAP_BATCH_SIZE, nr);
		range = (unsigned long)batch << PAGE_SHIFT;

		rmd.mmu_update = mmu_update;
		err = apply_to_page_range(vma->vm_mm, addr, range,
					  remap_area_mfn_pte_fn, &rmd);
		if (err)
			goto out;

		err = -EFAULT;
		if (HYPERVISOR_mmu_update(mmu_update, batch, NULL, domid) < 0)
			goto out;

		nr -= batch;
		addr += range;
	}

	err = 0;
out:

	flush_tlb_all();

	return err;
}
EXPORT_SYMBOL_GPL(xen_remap_domain_mfn_range);

/* Returns: Number of pages unmapped */
int xen_unmap_domain_mfn_range(struct vm_area_struct *vma,
			       struct xen_pvh_pfn_info *pvhp)
{
	int count = 0;

	if (!pvhp || !xen_feature(XENFEAT_auto_translated_physmap))
		return 0;

	while (pvhp->pi_next_todo--) {
		unsigned long pfn;

		/* the mmu has already cleaned up the process mmu resources at
		 * this point (lookup_address will return NULL). */
		pfn = page_to_pfn(pvhp->pi_paga[pvhp->pi_next_todo]);
		pvh_rem_xen_p2m(pfn, 1);
		count++;
	}
	flush_tlb_all();
	return count;
}
EXPORT_SYMBOL_GPL(xen_unmap_domain_mfn_range);

--MP_/+jFOV+feCm6gc.MLEl3bALy
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 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_/+jFOV+feCm6gc.MLEl3bALy--


From xen-devel-bounces@lists.xen.org Mon Sep 17 23:51:34 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 17 Sep 2012 23:51:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDl5o-0004Lv-VB; Mon, 17 Sep 2012 23:51:08 +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 1TDl5n-0004Lq-M3
	for Xen-devel@lists.xensource.com; Mon, 17 Sep 2012 23:51:08 +0000
Received: from [85.158.137.99:15632] by server-8.bemta-3.messagelabs.com id
	62/12-24700-A67B7505; Mon, 17 Sep 2012 23:51:06 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-13.tower-217.messagelabs.com!1347925864!18082822!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzQ1MDU4\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31420 invoked from network); 17 Sep 2012 23:51:05 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-13.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 17 Sep 2012 23:51:05 -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 q8HNp06O023657
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 17 Sep 2012 23:51:01 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
	q8HNp0BE006805
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 17 Sep 2012 23:51:00 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
	q8HNp07c030298; Mon, 17 Sep 2012 18:51:00 -0500
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 17 Sep 2012 16:50:59 -0700
Date: Mon, 17 Sep 2012 16:50:58 -0700
From: Mukesh Rathor <mukesh.rathor@oracle.com>
To: Mukesh Rathor <mukesh.rathor@oracle.com>
Message-ID: <20120917165058.686ad295@mantra.us.oracle.com>
In-Reply-To: <20120913173420.22b09c90@mantra.us.oracle.com>
References: <20120815180716.0049bffe@mantra.us.oracle.com>
	<1347372623.5305.170.camel@zakaz.uk.xensource.com>
	<20120912181910.6b0b9d2b@mantra.us.oracle.com>
	<1347536266.24226.97.camel@zakaz.uk.xensource.com>
	<20120913173420.22b09c90@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_/+jFOV+feCm6gc.MLEl3bALy"
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: "Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [RFC PATCH 8/8]: PVH: privcmd 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>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--MP_/+jFOV+feCm6gc.MLEl3bALy
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

On Thu, 13 Sep 2012 17:34:20 -0700
Mukesh Rathor <mukesh.rathor@oracle.com> wrote:

> On Thu, 13 Sep 2012 12:37:46 +0100
> Ian Campbell <Ian.Campbell@citrix.com> wrote:
> 
> > On Thu, 2012-09-13 at 02:19 +0100, Mukesh Rathor wrote:
> > > On Tue, 11 Sep 2012 15:10:23 +0100
> > > 
> > I think using vm_private within a subsystem/layer is ok, what I
> > think we should avoid is having layers pass data back and forth in
> > that field.
> 
> Ah I see your point. Ok, let me play around a bit see what I can do.

Hey Ian,

I played around a bit with privcmd, but not a whole lot can be done. I
did change things around a bit to make the APIs more symmetric and hide
vm_private_data from mmu.c. Please take a look. Unless major objections,
I'd like to resubmit all linux patches asap.

thanks,
Mukesh


--MP_/+jFOV+feCm6gc.MLEl3bALy
Content-Type: text/x-c++src
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename=privcmd.c

/******************************************************************************
 * privcmd.c
 *
 * Interface to privileged domain-0 commands.
 *
 * Copyright (c) 2002-2004, K A Fraser, B Dragovic
 */

#include <linux/kernel.h>
#include <linux/module.h>
#include <linux/sched.h>
#include <linux/slab.h>
#include <linux/string.h>
#include <linux/errno.h>
#include <linux/mm.h>
#include <linux/mman.h>
#include <linux/uaccess.h>
#include <linux/swap.h>
#include <linux/highmem.h>
#include <linux/pagemap.h>
#include <linux/seq_file.h>
#include <linux/miscdevice.h>

#include <asm/pgalloc.h>
#include <asm/pgtable.h>
#include <asm/tlb.h>
#include <asm/xen/hypervisor.h>
#include <asm/xen/hypercall.h>

#include <xen/xen.h>
#include <xen/privcmd.h>
#include <xen/interface/xen.h>
#include <xen/features.h>
#include <xen/page.h>
#include <xen/xen-ops.h>
#include <xen/balloon.h>

#include "privcmd.h"

MODULE_LICENSE("GPL");

#ifndef HAVE_ARCH_PRIVCMD_MMAP
static int privcmd_enforce_singleshot_mapping(struct vm_area_struct *vma);
#endif

static long privcmd_ioctl_hypercall(void __user *udata)
{
	struct privcmd_hypercall hypercall;
	long ret;

	if (copy_from_user(&hypercall, udata, sizeof(hypercall)))
		return -EFAULT;

	ret = privcmd_call(hypercall.op,
			   hypercall.arg[0], hypercall.arg[1],
			   hypercall.arg[2], hypercall.arg[3],
			   hypercall.arg[4]);

	return ret;
}

static void free_page_list(struct list_head *pages)
{
	struct page *p, *n;

	list_for_each_entry_safe(p, n, pages, lru)
		__free_page(p);

	INIT_LIST_HEAD(pages);
}

/*
 * Given an array of items in userspace, return a list of pages
 * containing the data.  If copying fails, either because of memory
 * allocation failure or a problem reading user memory, return an
 * error code; its up to the caller to dispose of any partial list.
 */
static int gather_array(struct list_head *pagelist,
			unsigned nelem, size_t size,
			void __user *data)
{
	unsigned pageidx;
	void *pagedata;
	int ret;

	if (size > PAGE_SIZE)
		return 0;

	pageidx = PAGE_SIZE;
	pagedata = NULL;	/* quiet, gcc */
	while (nelem--) {
		if (pageidx > PAGE_SIZE-size) {
			struct page *page = alloc_page(GFP_KERNEL);

			ret = -ENOMEM;
			if (page == NULL)
				goto fail;

			pagedata = page_address(page);

			list_add_tail(&page->lru, pagelist);
			pageidx = 0;
		}

		ret = -EFAULT;
		if (copy_from_user(pagedata + pageidx, data, size))
			goto fail;

		data += size;
		pageidx += size;
	}

	ret = 0;

fail:
	return ret;
}

/*
 * Call function "fn" on each element of the array fragmented
 * over a list of pages.
 */
static int traverse_pages(unsigned nelem, size_t size,
			  struct list_head *pos,
			  int (*fn)(void *data, void *state),
			  void *state)
{
	void *pagedata;
	unsigned pageidx;
	int ret = 0;

	BUG_ON(size > PAGE_SIZE);

	pageidx = PAGE_SIZE;
	pagedata = NULL;	/* hush, gcc */

	while (nelem--) {
		if (pageidx > PAGE_SIZE-size) {
			struct page *page;
			pos = pos->next;
			page = list_entry(pos, struct page, lru);
			pagedata = page_address(page);
			pageidx = 0;
		}

		ret = (*fn)(pagedata + pageidx, state);
		if (ret)
			break;
		pageidx += size;
	}

	return ret;
}

struct mmap_mfn_state {
	unsigned long va;
	struct vm_area_struct *vma;
	domid_t domain;
};

static int mmap_mfn_range(void *data, void *state)
{
	struct privcmd_mmap_entry *msg = data;
	struct mmap_mfn_state *st = state;
	struct vm_area_struct *vma = st->vma;
	int rc;

	/* Do not allow range to wrap the address space. */
	if ((msg->npages > (LONG_MAX >> PAGE_SHIFT)) ||
	    ((unsigned long)(msg->npages << PAGE_SHIFT) >= -st->va))
		return -EINVAL;

	/* Range chunks must be contiguous in va space. */
	if ((msg->va != st->va) ||
	    ((msg->va+(msg->npages<<PAGE_SHIFT)) > vma->vm_end))
		return -EINVAL;

	rc = xen_remap_domain_mfn_range(vma,
					msg->va & PAGE_MASK,
					msg->mfn, msg->npages,
					vma->vm_page_prot,
					st->domain, NULL);
	if (rc < 0)
		return rc;

	st->va += msg->npages << PAGE_SHIFT;

	return 0;
}

static long privcmd_ioctl_mmap(void __user *udata)
{
	struct privcmd_mmap mmapcmd;
	struct mm_struct *mm = current->mm;
	struct vm_area_struct *vma;
	int rc;
	LIST_HEAD(pagelist);
	struct mmap_mfn_state state;

	if (!xen_initial_domain())
		return -EPERM;

	/* PVH: TBD/FIXME. For now we only support privcmd_ioctl_mmap_batch */
	if (xen_pv_domain() && xen_feature(XENFEAT_auto_translated_physmap))
		return -ENOSYS;

	if (copy_from_user(&mmapcmd, udata, sizeof(mmapcmd)))
		return -EFAULT;

	rc = gather_array(&pagelist,
			  mmapcmd.num, sizeof(struct privcmd_mmap_entry),
			  mmapcmd.entry);

	if (rc || list_empty(&pagelist))
		goto out;

	down_write(&mm->mmap_sem);

	{
		struct page *page = list_first_entry(&pagelist,
						     struct page, lru);
		struct privcmd_mmap_entry *msg = page_address(page);

		vma = find_vma(mm, msg->va);
		rc = -EINVAL;

		if (!vma || (msg->va != vma->vm_start) ||
		    !privcmd_enforce_singleshot_mapping(vma))
			goto out_up;
	}

	state.va = vma->vm_start;
	state.vma = vma;
	state.domain = mmapcmd.dom;

	rc = traverse_pages(mmapcmd.num, sizeof(struct privcmd_mmap_entry),
			    &pagelist,
			    mmap_mfn_range, &state);


out_up:
	up_write(&mm->mmap_sem);

out:
	free_page_list(&pagelist);

	return rc;
}

struct mmap_batch_state {
	domid_t domain;
	unsigned long va;
	struct vm_area_struct *vma;
	int err;

	xen_pfn_t __user *user;
};

/* PVH dom0 fyi: if domU being created is PV, then mfn is mfn(addr on bus). If 
 * it's PVH then mfn is pfn (input to HAP). */
static int mmap_batch_fn(void *data, void *state)
{
	xen_pfn_t *mfnp = data;
	struct mmap_batch_state *st = state;
	struct xen_pvh_pfn_info *pvhp = st->vma ? st->vma->vm_private_data 
						: NULL;

	if (xen_remap_domain_mfn_range(st->vma, st->va & PAGE_MASK, *mfnp, 1,
				       st->vma->vm_page_prot, st->domain, 
				       pvhp) < 0) {
		*mfnp |= 0xf0000000U;
		st->err++;
	}
	st->va += PAGE_SIZE;

	return 0;
}

static int mmap_return_errors(void *data, void *state)
{
	xen_pfn_t *mfnp = data;
	struct mmap_batch_state *st = state;

	return put_user(*mfnp, st->user++);
}

/* Allocate pfns that are then mapped with gmfns from foreign domid. Update
 * the vma with the page info to use later.
 * Returns: 0 if success, otherwise -errno
 */ 
static int pvh_privcmd_resv_pfns(struct vm_area_struct *vma, int numpgs)
{
	int rc;
	struct xen_pvh_pfn_info *pvhp;

	pvhp = kzalloc(sizeof(struct xen_pvh_pfn_info), GFP_KERNEL);
	if (pvhp == NULL)
		return -ENOMEM;

	pvhp->pi_paga = kcalloc(numpgs, sizeof(pvhp->pi_paga[0]), GFP_KERNEL);
	if (pvhp->pi_paga == NULL) {
		kfree(pvhp);
		return -ENOMEM;
	}

	rc = alloc_xenballooned_pages(numpgs, pvhp->pi_paga, 0);
	if (rc != 0) {
		pr_warn("%s Could not alloc %d pfns rc:%d\n", __FUNCTION__, 
			numpgs, rc);
		kfree(pvhp->pi_paga);
		kfree(pvhp);
		return -ENOMEM;
	}
	pvhp->pi_num_pgs = numpgs;
	BUG_ON(vma->vm_private_data != (void *)1);
	vma->vm_private_data = pvhp;

	return 0;
}

static struct vm_operations_struct privcmd_vm_ops;

static long privcmd_ioctl_mmap_batch(void __user *udata)
{
	int ret;
	struct privcmd_mmapbatch m;
	struct mm_struct *mm = current->mm;
	struct vm_area_struct *vma;
	unsigned long nr_pages;
	LIST_HEAD(pagelist);
	struct mmap_batch_state state;

	if (!xen_initial_domain())
		return -EPERM;

	if (copy_from_user(&m, udata, sizeof(m)))
		return -EFAULT;

	nr_pages = m.num;
	if ((m.num <= 0) || (nr_pages > (LONG_MAX >> PAGE_SHIFT)))
		return -EINVAL;

	ret = gather_array(&pagelist, m.num, sizeof(xen_pfn_t),
			   m.arr);

	if (ret || list_empty(&pagelist))
		goto out;

	down_write(&mm->mmap_sem);

	vma = find_vma(mm, m.addr);
	ret = -EINVAL;
	if (!vma ||
	    vma->vm_ops != &privcmd_vm_ops ||
	    (m.addr != vma->vm_start) ||
	    ((m.addr + (nr_pages << PAGE_SHIFT)) != vma->vm_end) ||
	    !privcmd_enforce_singleshot_mapping(vma)) {
		up_write(&mm->mmap_sem);
		goto out;
	}

	if (xen_pv_domain() && xen_feature(XENFEAT_auto_translated_physmap)) {
		if ((ret=pvh_privcmd_resv_pfns(vma, m.num))) {
			up_write(&mm->mmap_sem);
			goto out;
		}
	}
	state.domain = m.dom;
	state.vma = vma;
	state.va = m.addr;
	state.err = 0;

	ret = traverse_pages(m.num, sizeof(xen_pfn_t),
			     &pagelist, mmap_batch_fn, &state);

	up_write(&mm->mmap_sem);

	if (state.err > 0) {
		state.user = m.arr;
		ret = traverse_pages(m.num, sizeof(xen_pfn_t),
			       &pagelist,
			       mmap_return_errors, &state);
	}

out:
	free_page_list(&pagelist);

	return ret;
}

static long privcmd_ioctl(struct file *file,
			  unsigned int cmd, unsigned long data)
{
	int ret = -ENOSYS;
	void __user *udata = (void __user *) data;

	switch (cmd) {
	case IOCTL_PRIVCMD_HYPERCALL:
		ret = privcmd_ioctl_hypercall(udata);
		break;

	case IOCTL_PRIVCMD_MMAP:
		ret = privcmd_ioctl_mmap(udata);
		break;

	case IOCTL_PRIVCMD_MMAPBATCH:
		ret = privcmd_ioctl_mmap_batch(udata);
		break;

	default:
		ret = -EINVAL;
		break;
	}

	return ret;
}

static void privcmd_close(struct vm_area_struct *vma)
{
	int count;
	struct xen_pvh_pfn_info *pvhp = vma ? vma->vm_private_data : NULL;

	if (!xen_pv_domain()  || !pvhp ||
	    !xen_feature(XENFEAT_auto_translated_physmap))
		return;

	count = xen_unmap_domain_mfn_range(vma, pvhp);
	while (count--)
		free_xenballooned_pages(1, &pvhp->pi_paga[count]);
	kfree(pvhp->pi_paga);
	kfree(pvhp);
}

static int privcmd_fault(struct vm_area_struct *vma, struct vm_fault *vmf)
{
	printk(KERN_DEBUG "privcmd_fault: vma=%p %lx-%lx, pgoff=%lx, uv=%p\n",
	       vma, vma->vm_start, vma->vm_end,
	       vmf->pgoff, vmf->virtual_address);

	return VM_FAULT_SIGBUS;
}

static struct vm_operations_struct privcmd_vm_ops = {
	.close = privcmd_close,
	.fault = privcmd_fault
};

static int privcmd_mmap(struct file *file, struct vm_area_struct *vma)
{
	/* DONTCOPY is essential for Xen because copy_page_range doesn't know
	 * how to recreate these mappings */
	vma->vm_flags |= VM_RESERVED | VM_IO | VM_DONTCOPY | VM_PFNMAP;
	vma->vm_ops = &privcmd_vm_ops;
	vma->vm_private_data = NULL;

	return 0;
}

static int privcmd_enforce_singleshot_mapping(struct vm_area_struct *vma)
{
	return (xchg(&vma->vm_private_data, (void *)1) == NULL);
}

const struct file_operations xen_privcmd_fops = {
	.owner = THIS_MODULE,
	.unlocked_ioctl = privcmd_ioctl,
	.mmap = privcmd_mmap,
};
EXPORT_SYMBOL_GPL(xen_privcmd_fops);

static struct miscdevice privcmd_dev = {
	.minor = MISC_DYNAMIC_MINOR,
	.name = "xen/privcmd",
	.fops = &xen_privcmd_fops,
};

static int __init privcmd_init(void)
{
	int err;

	if (!xen_domain())
		return -ENODEV;

	err = misc_register(&privcmd_dev);
	if (err != 0) {
		printk(KERN_ERR "Could not register Xen privcmd device\n");
		return err;
	}
	return 0;
}

static void __exit privcmd_exit(void)
{
	misc_deregister(&privcmd_dev);
}

module_init(privcmd_init);
module_exit(privcmd_exit);

--MP_/+jFOV+feCm6gc.MLEl3bALy
Content-Type: text/x-c++src
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename=mmu.c

/*
 * Xen mmu operations
 *
 * This file contains the various mmu fetch and update operations.
 * The most important job they must perform is the mapping between the
 * domain's pfn and the overall machine mfns.
 *
 * Xen allows guests to directly update the pagetable, in a controlled
 * fashion.  In other words, the guest modifies the same pagetable
 * that the CPU actually uses, which eliminates the overhead of having
 * a separate shadow pagetable.
 *
 * In order to allow this, it falls on the guest domain to map its
 * notion of a "physical" pfn - which is just a domain-local linear
 * address - into a real "machine address" which the CPU's MMU can
 * use.
 *
 * A pgd_t/pmd_t/pte_t will typically contain an mfn, and so can be
 * inserted directly into the pagetable.  When creating a new
 * pte/pmd/pgd, it converts the passed pfn into an mfn.  Conversely,
 * when reading the content back with __(pgd|pmd|pte)_val, it converts
 * the mfn back into a pfn.
 *
 * The other constraint is that all pages which make up a pagetable
 * must be mapped read-only in the guest.  This prevents uncontrolled
 * guest updates to the pagetable.  Xen strictly enforces this, and
 * will disallow any pagetable update which will end up mapping a
 * pagetable page RW, and will disallow using any writable page as a
 * pagetable.
 *
 * Naively, when loading %cr3 with the base of a new pagetable, Xen
 * would need to validate the whole pagetable before going on.
 * Naturally, this is quite slow.  The solution is to "pin" a
 * pagetable, which enforces all the constraints on the pagetable even
 * when it is not actively in use.  This menas that Xen can be assured
 * that it is still valid when you do load it into %cr3, and doesn't
 * need to revalidate it.
 *
 * Jeremy Fitzhardinge <jeremy@xensource.com>, XenSource Inc, 2007
 */
#include <linux/sched.h>
#include <linux/highmem.h>
#include <linux/debugfs.h>
#include <linux/bug.h>
#include <linux/vmalloc.h>
#include <linux/module.h>
#include <linux/gfp.h>
#include <linux/memblock.h>
#include <linux/seq_file.h>

#include <trace/events/xen.h>

#include <asm/pgtable.h>
#include <asm/tlbflush.h>
#include <asm/fixmap.h>
#include <asm/mmu_context.h>
#include <asm/setup.h>
#include <asm/paravirt.h>
#include <asm/e820.h>
#include <asm/linkage.h>
#include <asm/page.h>
#include <asm/init.h>
#include <asm/pat.h>
#include <asm/smp.h>

#include <asm/xen/hypercall.h>
#include <asm/xen/hypervisor.h>

#include <xen/xen.h>
#include <xen/page.h>
#include <xen/interface/xen.h>
#include <xen/interface/hvm/hvm_op.h>
#include <xen/interface/version.h>
#include <xen/interface/memory.h>
#include <xen/hvc-console.h>
#include <xen/balloon.h>

#include "multicalls.h"
#include "mmu.h"
#include "debugfs.h"

/*
 * Protects atomic reservation decrease/increase against concurrent increases.
 * Also protects non-atomic updates of current_pages and balloon lists.
 */
DEFINE_SPINLOCK(xen_reservation_lock);

/*
 * Identity map, in addition to plain kernel map.  This needs to be
 * large enough to allocate page table pages to allocate the rest.
 * Each page can map 2MB.
 */
#define LEVEL1_IDENT_ENTRIES	(PTRS_PER_PTE * 4)
static RESERVE_BRK_ARRAY(pte_t, level1_ident_pgt, LEVEL1_IDENT_ENTRIES);

#ifdef CONFIG_X86_64
/* l3 pud for userspace vsyscall mapping */
static pud_t level3_user_vsyscall[PTRS_PER_PUD] __page_aligned_bss;
#endif /* CONFIG_X86_64 */

/*
 * Note about cr3 (pagetable base) values:
 *
 * xen_cr3 contains the current logical cr3 value; it contains the
 * last set cr3.  This may not be the current effective cr3, because
 * its update may be being lazily deferred.  However, a vcpu looking
 * at its own cr3 can use this value knowing that it everything will
 * be self-consistent.
 *
 * xen_current_cr3 contains the actual vcpu cr3; it is set once the
 * hypercall to set the vcpu cr3 is complete (so it may be a little
 * out of date, but it will never be set early).  If one vcpu is
 * looking at another vcpu's cr3 value, it should use this variable.
 */
DEFINE_PER_CPU(unsigned long, xen_cr3);	 /* cr3 stored as physaddr */
DEFINE_PER_CPU(unsigned long, xen_current_cr3);	 /* actual vcpu cr3 */


/*
 * Just beyond the highest usermode address.  STACK_TOP_MAX has a
 * redzone above it, so round it up to a PGD boundary.
 */
#define USER_LIMIT	((STACK_TOP_MAX + PGDIR_SIZE - 1) & PGDIR_MASK)

unsigned long arbitrary_virt_to_mfn(void *vaddr)
{
	xmaddr_t maddr = arbitrary_virt_to_machine(vaddr);

	return PFN_DOWN(maddr.maddr);
}

xmaddr_t arbitrary_virt_to_machine(void *vaddr)
{
	unsigned long address = (unsigned long)vaddr;
	unsigned int level;
	pte_t *pte;
	unsigned offset;

	/*
	 * if the PFN is in the linear mapped vaddr range, we can just use
	 * the (quick) virt_to_machine() p2m lookup
	 */
	if (virt_addr_valid(vaddr))
		return virt_to_machine(vaddr);

	/* otherwise we have to do a (slower) full page-table walk */

	pte = lookup_address(address, &level);
	BUG_ON(pte == NULL);
	offset = address & ~PAGE_MASK;
	return XMADDR(((phys_addr_t)pte_mfn(*pte) << PAGE_SHIFT) + offset);
}
EXPORT_SYMBOL_GPL(arbitrary_virt_to_machine);

void make_lowmem_page_readonly(void *vaddr)
{
	pte_t *pte, ptev;
	unsigned long address = (unsigned long)vaddr;
	unsigned int level;

	pte = lookup_address(address, &level);
	if (pte == NULL)
		return;		/* vaddr missing */

	ptev = pte_wrprotect(*pte);

	if (HYPERVISOR_update_va_mapping(address, ptev, 0))
		BUG();
}

void make_lowmem_page_readwrite(void *vaddr)
{
	pte_t *pte, ptev;
	unsigned long address = (unsigned long)vaddr;
	unsigned int level;

	pte = lookup_address(address, &level);
	if (pte == NULL)
		return;		/* vaddr missing */

	ptev = pte_mkwrite(*pte);

	if (HYPERVISOR_update_va_mapping(address, ptev, 0))
		BUG();
}


static bool xen_page_pinned(void *ptr)
{
	struct page *page = virt_to_page(ptr);

	return PagePinned(page);
}

void xen_set_domain_pte(pte_t *ptep, pte_t pteval, unsigned domid)
{
	struct multicall_space mcs;
	struct mmu_update *u;

	trace_xen_mmu_set_domain_pte(ptep, pteval, domid);

	mcs = xen_mc_entry(sizeof(*u));
	u = mcs.args;

	/* ptep might be kmapped when using 32-bit HIGHPTE */
	u->ptr = virt_to_machine(ptep).maddr;
	u->val = pte_val_ma(pteval);

	MULTI_mmu_update(mcs.mc, mcs.args, 1, NULL, domid);

	xen_mc_issue(PARAVIRT_LAZY_MMU);
}
EXPORT_SYMBOL_GPL(xen_set_domain_pte);

static void xen_extend_mmu_update(const struct mmu_update *update)
{
	struct multicall_space mcs;
	struct mmu_update *u;

	mcs = xen_mc_extend_args(__HYPERVISOR_mmu_update, sizeof(*u));

	if (mcs.mc != NULL) {
		mcs.mc->args[1]++;
	} else {
		mcs = __xen_mc_entry(sizeof(*u));
		MULTI_mmu_update(mcs.mc, mcs.args, 1, NULL, DOMID_SELF);
	}

	u = mcs.args;
	*u = *update;
}

static void xen_extend_mmuext_op(const struct mmuext_op *op)
{
	struct multicall_space mcs;
	struct mmuext_op *u;

	mcs = xen_mc_extend_args(__HYPERVISOR_mmuext_op, sizeof(*u));

	if (mcs.mc != NULL) {
		mcs.mc->args[1]++;
	} else {
		mcs = __xen_mc_entry(sizeof(*u));
		MULTI_mmuext_op(mcs.mc, mcs.args, 1, NULL, DOMID_SELF);
	}

	u = mcs.args;
	*u = *op;
}

static void xen_set_pmd_hyper(pmd_t *ptr, pmd_t val)
{
	struct mmu_update u;

	preempt_disable();

	xen_mc_batch();

	/* ptr may be ioremapped for 64-bit pagetable setup */
	u.ptr = arbitrary_virt_to_machine(ptr).maddr;
	u.val = pmd_val_ma(val);
	xen_extend_mmu_update(&u);

	xen_mc_issue(PARAVIRT_LAZY_MMU);

	preempt_enable();
}

static void xen_set_pmd(pmd_t *ptr, pmd_t val)
{
	trace_xen_mmu_set_pmd(ptr, val);

	/* If page is not pinned, we can just update the entry
	   directly */
	if (!xen_page_pinned(ptr)) {
		*ptr = val;
		return;
	}

	xen_set_pmd_hyper(ptr, val);
}

/*
 * Associate a virtual page frame with a given physical page frame
 * and protection flags for that frame.
 */
void set_pte_mfn(unsigned long vaddr, unsigned long mfn, pgprot_t flags)
{
	set_pte_vaddr(vaddr, mfn_pte(mfn, flags));
}

static bool xen_batched_set_pte(pte_t *ptep, pte_t pteval)
{
	struct mmu_update u;

	if (paravirt_get_lazy_mode() != PARAVIRT_LAZY_MMU)
		return false;

	xen_mc_batch();

	u.ptr = virt_to_machine(ptep).maddr | MMU_NORMAL_PT_UPDATE;
	u.val = pte_val_ma(pteval);
	xen_extend_mmu_update(&u);

	xen_mc_issue(PARAVIRT_LAZY_MMU);

	return true;
}

static inline void __xen_set_pte(pte_t *ptep, pte_t 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)
{
	trace_xen_mmu_set_pte(ptep, pteval);
	__xen_set_pte(ptep, pteval);
}

void xen_set_clr_mmio_pvh_pte(unsigned long pfn, unsigned long mfn, 
			      int nr_mfns, int add_mapping)
{
	struct physdev_map_iomem iomem;

	iomem.first_gfn = pfn;
	iomem.first_mfn = mfn;
	iomem.nr_mfns = nr_mfns;
	iomem.add_mapping = add_mapping;

	if (HYPERVISOR_physdev_op(PHYSDEVOP_pvh_map_iomem, &iomem))
		BUG();
}

static void xen_dom0pvh_set_pte_at(struct mm_struct *mm, unsigned long addr,
		    		   pte_t *ptep, pte_t pteval)
{
	native_set_pte(ptep, pteval);
}

static void xen_set_pte_at(struct mm_struct *mm, unsigned long addr,
		    pte_t *ptep, pte_t pteval)
{
	trace_xen_mmu_set_pte_at(mm, addr, ptep, pteval);
	__xen_set_pte(ptep, pteval);
}

pte_t xen_ptep_modify_prot_start(struct mm_struct *mm,
				 unsigned long addr, pte_t *ptep)
{
	/* Just return the pte as-is.  We preserve the bits on commit */
	trace_xen_mmu_ptep_modify_prot_start(mm, addr, ptep, *ptep);
	return *ptep;
}

void xen_ptep_modify_prot_commit(struct mm_struct *mm, unsigned long addr,
				 pte_t *ptep, pte_t pte)
{
	struct mmu_update u;

	trace_xen_mmu_ptep_modify_prot_commit(mm, addr, ptep, pte);
	xen_mc_batch();

	u.ptr = virt_to_machine(ptep).maddr | MMU_PT_UPDATE_PRESERVE_AD;
	u.val = pte_val_ma(pte);
	xen_extend_mmu_update(&u);

	xen_mc_issue(PARAVIRT_LAZY_MMU);
}

/* Assume pteval_t is equivalent to all the other *val_t types. */
static pteval_t pte_mfn_to_pfn(pteval_t val)
{
	if (val & _PAGE_PRESENT) {
		unsigned long mfn = (val & PTE_PFN_MASK) >> PAGE_SHIFT;
		unsigned long pfn = mfn_to_pfn(mfn);

		pteval_t flags = val & PTE_FLAGS_MASK;
		if (unlikely(pfn == ~0))
			val = flags & ~_PAGE_PRESENT;
		else
			val = ((pteval_t)pfn << PAGE_SHIFT) | flags;
	}

	return val;
}

static pteval_t pte_pfn_to_mfn(pteval_t val)
{
	if (val & _PAGE_PRESENT) {
		unsigned long pfn = (val & PTE_PFN_MASK) >> PAGE_SHIFT;
		pteval_t flags = val & PTE_FLAGS_MASK;
		unsigned long mfn;

		if (!xen_feature(XENFEAT_auto_translated_physmap))
			mfn = get_phys_to_machine(pfn);
		else
			mfn = pfn;
		/*
		 * If there's no mfn for the pfn, then just create an
		 * empty non-present pte.  Unfortunately this loses
		 * information about the original pfn, so
		 * pte_mfn_to_pfn is asymmetric.
		 */
		if (unlikely(mfn == INVALID_P2M_ENTRY)) {
			mfn = 0;
			flags = 0;
		} else {
			/*
			 * Paramount to do this test _after_ the
			 * INVALID_P2M_ENTRY as INVALID_P2M_ENTRY &
			 * IDENTITY_FRAME_BIT resolves to true.
			 */
			mfn &= ~FOREIGN_FRAME_BIT;
			if (mfn & IDENTITY_FRAME_BIT) {
				mfn &= ~IDENTITY_FRAME_BIT;
				flags |= _PAGE_IOMAP;
			}
		}
		val = ((pteval_t)mfn << PAGE_SHIFT) | flags;
	}

	return val;
}

static pteval_t iomap_pte(pteval_t val)
{
	if (val & _PAGE_PRESENT) {
		unsigned long pfn = (val & PTE_PFN_MASK) >> PAGE_SHIFT;
		pteval_t flags = val & PTE_FLAGS_MASK;

		/* We assume the pte frame number is a MFN, so
		   just use it as-is. */
		val = ((pteval_t)pfn << PAGE_SHIFT) | flags;
	}

	return val;
}

static pteval_t xen_pte_val(pte_t pte)
{
	pteval_t pteval = pte.pte;
#if 0
	/* If this is a WC pte, convert back from Xen WC to Linux WC */
	if ((pteval & (_PAGE_PAT | _PAGE_PCD | _PAGE_PWT)) == _PAGE_PAT) {
		WARN_ON(!pat_enabled);
		pteval = (pteval & ~_PAGE_PAT) | _PAGE_PWT;
	}
#endif
	if (xen_initial_domain() && (pteval & _PAGE_IOMAP))
		return pteval;

	return pte_mfn_to_pfn(pteval);
}
PV_CALLEE_SAVE_REGS_THUNK(xen_pte_val);

static pgdval_t xen_pgd_val(pgd_t pgd)
{
	return pte_mfn_to_pfn(pgd.pgd);
}
PV_CALLEE_SAVE_REGS_THUNK(xen_pgd_val);

/*
 * Xen's PAT setup is part of its ABI, though I assume entries 6 & 7
 * are reserved for now, to correspond to the Intel-reserved PAT
 * types.
 *
 * We expect Linux's PAT set as follows:
 *
 * Idx  PTE flags        Linux    Xen    Default
 * 0                     WB       WB     WB
 * 1            PWT      WC       WT     WT
 * 2        PCD          UC-      UC-    UC-
 * 3        PCD PWT      UC       UC     UC
 * 4    PAT              WB       WC     WB
 * 5    PAT     PWT      WC       WP     WT
 * 6    PAT PCD          UC-      UC     UC-
 * 7    PAT PCD PWT      UC       UC     UC
 */

void xen_set_pat(u64 pat)
{
	/* We expect Linux to use a PAT setting of
	 * UC UC- WC WB (ignoring the PAT flag) */
	WARN_ON(pat != 0x0007010600070106ull);
}

static pte_t xen_make_pte(pteval_t pte)
{
	phys_addr_t addr = (pte & PTE_PFN_MASK);
#if 0
	/* If Linux is trying to set a WC pte, then map to the Xen WC.
	 * If _PAGE_PAT is set, then it probably means it is really
	 * _PAGE_PSE, so avoid fiddling with the PAT mapping and hope
	 * things work out OK...
	 *
	 * (We should never see kernel mappings with _PAGE_PSE set,
	 * but we could see hugetlbfs mappings, I think.).
	 */
	if (pat_enabled && !WARN_ON(pte & _PAGE_PAT)) {
		if ((pte & (_PAGE_PCD | _PAGE_PWT)) == _PAGE_PWT)
			pte = (pte & ~(_PAGE_PCD | _PAGE_PWT)) | _PAGE_PAT;
	}
#endif
	/*
	 * Unprivileged domains are allowed to do IOMAPpings for
	 * PCI passthrough, but not map ISA space.  The ISA
	 * mappings are just dummy local mappings to keep other
	 * parts of the kernel happy.
	 */
	if (unlikely(pte & _PAGE_IOMAP) &&
	    (xen_initial_domain() || addr >= ISA_END_ADDRESS)) {
		pte = iomap_pte(pte);
	} else {
		pte &= ~_PAGE_IOMAP;
		pte = pte_pfn_to_mfn(pte);
	}

	return native_make_pte(pte);
}
PV_CALLEE_SAVE_REGS_THUNK(xen_make_pte);

static pgd_t xen_make_pgd(pgdval_t pgd)
{
	pgd = pte_pfn_to_mfn(pgd);
	return native_make_pgd(pgd);
}
PV_CALLEE_SAVE_REGS_THUNK(xen_make_pgd);

static pmdval_t xen_pmd_val(pmd_t pmd)
{
	return pte_mfn_to_pfn(pmd.pmd);
}
PV_CALLEE_SAVE_REGS_THUNK(xen_pmd_val);

static void xen_set_pud_hyper(pud_t *ptr, pud_t val)
{
	struct mmu_update u;

	preempt_disable();

	xen_mc_batch();

	/* ptr may be ioremapped for 64-bit pagetable setup */
	u.ptr = arbitrary_virt_to_machine(ptr).maddr;
	u.val = pud_val_ma(val);
	xen_extend_mmu_update(&u);

	xen_mc_issue(PARAVIRT_LAZY_MMU);

	preempt_enable();
}

static void xen_set_pud(pud_t *ptr, pud_t val)
{
	trace_xen_mmu_set_pud(ptr, val);

	/* If page is not pinned, we can just update the entry
	   directly */
	if (!xen_page_pinned(ptr)) {
		*ptr = val;
		return;
	}

	xen_set_pud_hyper(ptr, val);
}

#ifdef CONFIG_X86_PAE
static void xen_set_pte_atomic(pte_t *ptep, pte_t pte)
{
	trace_xen_mmu_set_pte_atomic(ptep, pte);
	set_64bit((u64 *)ptep, native_pte_val(pte));
}

static void xen_pte_clear(struct mm_struct *mm, unsigned long addr, pte_t *ptep)
{
	trace_xen_mmu_pte_clear(mm, addr, ptep);
	if (!xen_batched_set_pte(ptep, native_make_pte(0)))
		native_pte_clear(mm, addr, ptep);
}

static void xen_pmd_clear(pmd_t *pmdp)
{
	trace_xen_mmu_pmd_clear(pmdp);
	set_pmd(pmdp, __pmd(0));
}
#endif	/* CONFIG_X86_PAE */

static pmd_t xen_make_pmd(pmdval_t pmd)
{
	pmd = pte_pfn_to_mfn(pmd);
	return native_make_pmd(pmd);
}
PV_CALLEE_SAVE_REGS_THUNK(xen_make_pmd);

#if PAGETABLE_LEVELS == 4
static pudval_t xen_pud_val(pud_t pud)
{
	return pte_mfn_to_pfn(pud.pud);
}
PV_CALLEE_SAVE_REGS_THUNK(xen_pud_val);

static pud_t xen_make_pud(pudval_t pud)
{
	pud = pte_pfn_to_mfn(pud);

	return native_make_pud(pud);
}
PV_CALLEE_SAVE_REGS_THUNK(xen_make_pud);

static pgd_t *xen_get_user_pgd(pgd_t *pgd)
{
	pgd_t *pgd_page = (pgd_t *)(((unsigned long)pgd) & PAGE_MASK);
	unsigned offset = pgd - pgd_page;
	pgd_t *user_ptr = NULL;

	if (offset < pgd_index(USER_LIMIT)) {
		struct page *page = virt_to_page(pgd_page);
		user_ptr = (pgd_t *)page->private;
		if (user_ptr)
			user_ptr += offset;
	}

	return user_ptr;
}

static void __xen_set_pgd_hyper(pgd_t *ptr, pgd_t val)
{
	struct mmu_update u;

	u.ptr = virt_to_machine(ptr).maddr;
	u.val = pgd_val_ma(val);
	xen_extend_mmu_update(&u);
}

/*
 * Raw hypercall-based set_pgd, intended for in early boot before
 * there's a page structure.  This implies:
 *  1. The only existing pagetable is the kernel's
 *  2. It is always pinned
 *  3. It has no user pagetable attached to it
 */
static void __init xen_set_pgd_hyper(pgd_t *ptr, pgd_t val)
{
	preempt_disable();

	xen_mc_batch();

	__xen_set_pgd_hyper(ptr, val);

	xen_mc_issue(PARAVIRT_LAZY_MMU);

	preempt_enable();
}

static void xen_set_pgd(pgd_t *ptr, pgd_t val)
{
	pgd_t *user_ptr = xen_get_user_pgd(ptr);

	trace_xen_mmu_set_pgd(ptr, user_ptr, val);

	/* If page is not pinned, we can just update the entry
	   directly */
	if (!xen_page_pinned(ptr)) {
		*ptr = val;
		if (user_ptr) {
			WARN_ON(xen_page_pinned(user_ptr));
			*user_ptr = val;
		}
		return;
	}

	/* If it's pinned, then we can at least batch the kernel and
	   user updates together. */
	xen_mc_batch();

	__xen_set_pgd_hyper(ptr, val);
	if (user_ptr)
		__xen_set_pgd_hyper(user_ptr, val);

	xen_mc_issue(PARAVIRT_LAZY_MMU);
}
#endif	/* PAGETABLE_LEVELS == 4 */

/*
 * (Yet another) pagetable walker.  This one is intended for pinning a
 * pagetable.  This means that it walks a pagetable and calls the
 * callback function on each page it finds making up the page table,
 * at every level.  It walks the entire pagetable, but it only bothers
 * pinning pte pages which are below limit.  In the normal case this
 * will be STACK_TOP_MAX, but at boot we need to pin up to
 * FIXADDR_TOP.
 *
 * For 32-bit the important bit is that we don't pin beyond there,
 * because then we start getting into Xen's ptes.
 *
 * For 64-bit, we must skip the Xen hole in the middle of the address
 * space, just after the big x86-64 virtual hole.
 */
static int __xen_pgd_walk(struct mm_struct *mm, pgd_t *pgd,
			  int (*func)(struct mm_struct *mm, struct page *,
				      enum pt_level),
			  unsigned long limit)
{
	int flush = 0;
	unsigned hole_low, hole_high;
	unsigned pgdidx_limit, pudidx_limit, pmdidx_limit;
	unsigned pgdidx, pudidx, pmdidx;

	/* The limit is the last byte to be touched */
	limit--;
	BUG_ON(limit >= FIXADDR_TOP);

	if (xen_feature(XENFEAT_auto_translated_physmap))
		return 0;

	/*
	 * 64-bit has a great big hole in the middle of the address
	 * space, which contains the Xen mappings.  On 32-bit these
	 * will end up making a zero-sized hole and so is a no-op.
	 */
	hole_low = pgd_index(USER_LIMIT);
	hole_high = pgd_index(PAGE_OFFSET);

	pgdidx_limit = pgd_index(limit);
#if PTRS_PER_PUD > 1
	pudidx_limit = pud_index(limit);
#else
	pudidx_limit = 0;
#endif
#if PTRS_PER_PMD > 1
	pmdidx_limit = pmd_index(limit);
#else
	pmdidx_limit = 0;
#endif

	for (pgdidx = 0; pgdidx <= pgdidx_limit; pgdidx++) {
		pud_t *pud;

		if (pgdidx >= hole_low && pgdidx < hole_high)
			continue;

		if (!pgd_val(pgd[pgdidx]))
			continue;

		pud = pud_offset(&pgd[pgdidx], 0);

		if (PTRS_PER_PUD > 1) /* not folded */
			flush |= (*func)(mm, virt_to_page(pud), PT_PUD);

		for (pudidx = 0; pudidx < PTRS_PER_PUD; pudidx++) {
			pmd_t *pmd;

			if (pgdidx == pgdidx_limit &&
			    pudidx > pudidx_limit)
				goto out;

			if (pud_none(pud[pudidx]))
				continue;

			pmd = pmd_offset(&pud[pudidx], 0);

			if (PTRS_PER_PMD > 1) /* not folded */
				flush |= (*func)(mm, virt_to_page(pmd), PT_PMD);

			for (pmdidx = 0; pmdidx < PTRS_PER_PMD; pmdidx++) {
				struct page *pte;

				if (pgdidx == pgdidx_limit &&
				    pudidx == pudidx_limit &&
				    pmdidx > pmdidx_limit)
					goto out;

				if (pmd_none(pmd[pmdidx]))
					continue;

				pte = pmd_page(pmd[pmdidx]);
				flush |= (*func)(mm, pte, PT_PTE);
			}
		}
	}

out:
	/* Do the top level last, so that the callbacks can use it as
	   a cue to do final things like tlb flushes. */
	flush |= (*func)(mm, virt_to_page(pgd), PT_PGD);

	return flush;
}

static int xen_pgd_walk(struct mm_struct *mm,
			int (*func)(struct mm_struct *mm, struct page *,
				    enum pt_level),
			unsigned long limit)
{
	return __xen_pgd_walk(mm, mm->pgd, func, limit);
}

/* If we're using split pte locks, then take the page's lock and
   return a pointer to it.  Otherwise return NULL. */
static spinlock_t *xen_pte_lock(struct page *page, struct mm_struct *mm)
{
	spinlock_t *ptl = NULL;

#if USE_SPLIT_PTLOCKS
	ptl = __pte_lockptr(page);
	spin_lock_nest_lock(ptl, &mm->page_table_lock);
#endif

	return ptl;
}

static void xen_pte_unlock(void *v)
{
	spinlock_t *ptl = v;
	spin_unlock(ptl);
}

static void xen_do_pin(unsigned level, unsigned long pfn)
{
	struct mmuext_op op;

	op.cmd = level;
	op.arg1.mfn = pfn_to_mfn(pfn);

	xen_extend_mmuext_op(&op);
}

static int xen_pin_page(struct mm_struct *mm, struct page *page,
			enum pt_level level)
{
	unsigned pgfl = TestSetPagePinned(page);
	int flush;

	if (pgfl)
		flush = 0;		/* already pinned */
	else if (PageHighMem(page))
		/* kmaps need flushing if we found an unpinned
		   highpage */
		flush = 1;
	else {
		void *pt = lowmem_page_address(page);
		unsigned long pfn = page_to_pfn(page);
		struct multicall_space mcs = __xen_mc_entry(0);
		spinlock_t *ptl;

		flush = 0;

		/*
		 * We need to hold the pagetable lock between the time
		 * we make the pagetable RO and when we actually pin
		 * it.  If we don't, then other users may come in and
		 * attempt to update the pagetable by writing it,
		 * which will fail because the memory is RO but not
		 * pinned, so Xen won't do the trap'n'emulate.
		 *
		 * If we're using split pte locks, we can't hold the
		 * entire pagetable's worth of locks during the
		 * traverse, because we may wrap the preempt count (8
		 * bits).  The solution is to mark RO and pin each PTE
		 * page while holding the lock.  This means the number
		 * of locks we end up holding is never more than a
		 * batch size (~32 entries, at present).
		 *
		 * If we're not using split pte locks, we needn't pin
		 * the PTE pages independently, because we're
		 * protected by the overall pagetable lock.
		 */
		ptl = NULL;
		if (level == PT_PTE)
			ptl = xen_pte_lock(page, mm);

		MULTI_update_va_mapping(mcs.mc, (unsigned long)pt,
					pfn_pte(pfn, PAGE_KERNEL_RO),
					level == PT_PGD ? UVMF_TLB_FLUSH : 0);

		if (ptl) {
			xen_do_pin(MMUEXT_PIN_L1_TABLE, pfn);

			/* Queue a deferred unlock for when this batch
			   is completed. */
			xen_mc_callback(xen_pte_unlock, ptl);
		}
	}

	return flush;
}

/* This is called just after a mm has been created, but it has not
   been used yet.  We need to make sure that its pagetable is all
   read-only, and can be pinned. */
static void __xen_pgd_pin(struct mm_struct *mm, pgd_t *pgd)
{
	trace_xen_mmu_pgd_pin(mm, pgd);

	xen_mc_batch();

	if (__xen_pgd_walk(mm, pgd, xen_pin_page, USER_LIMIT)) {
		/* re-enable interrupts for flushing */
		xen_mc_issue(0);

		kmap_flush_unused();

		xen_mc_batch();
	}

#ifdef CONFIG_X86_64
	{
		pgd_t *user_pgd = xen_get_user_pgd(pgd);

		xen_do_pin(MMUEXT_PIN_L4_TABLE, PFN_DOWN(__pa(pgd)));

		if (user_pgd) {
			xen_pin_page(mm, virt_to_page(user_pgd), PT_PGD);
			xen_do_pin(MMUEXT_PIN_L4_TABLE,
				   PFN_DOWN(__pa(user_pgd)));
		}
	}
#else /* CONFIG_X86_32 */
#ifdef CONFIG_X86_PAE
	/* Need to make sure unshared kernel PMD is pinnable */
	xen_pin_page(mm, pgd_page(pgd[pgd_index(TASK_SIZE)]),
		     PT_PMD);
#endif
	xen_do_pin(MMUEXT_PIN_L3_TABLE, PFN_DOWN(__pa(pgd)));
#endif /* CONFIG_X86_64 */
	xen_mc_issue(0);
}

static void xen_pgd_pin(struct mm_struct *mm)
{
	__xen_pgd_pin(mm, mm->pgd);
}

/*
 * On save, we need to pin all pagetables to make sure they get their
 * mfns turned into pfns.  Search the list for any unpinned pgds and pin
 * them (unpinned pgds are not currently in use, probably because the
 * process is under construction or destruction).
 *
 * Expected to be called in stop_machine() ("equivalent to taking
 * every spinlock in the system"), so the locking doesn't really
 * matter all that much.
 */
void xen_mm_pin_all(void)
{
	struct page *page;

	spin_lock(&pgd_lock);

	list_for_each_entry(page, &pgd_list, lru) {
		if (!PagePinned(page)) {
			__xen_pgd_pin(&init_mm, (pgd_t *)page_address(page));
			SetPageSavePinned(page);
		}
	}

	spin_unlock(&pgd_lock);
}

/*
 * The init_mm pagetable is really pinned as soon as its created, but
 * that's before we have page structures to store the bits.  So do all
 * the book-keeping now.
 */
static int __init xen_mark_pinned(struct mm_struct *mm, struct page *page,
				  enum pt_level level)
{
	SetPagePinned(page);
	return 0;
}

static void __init xen_mark_init_mm_pinned(void)
{
	xen_pgd_walk(&init_mm, xen_mark_pinned, FIXADDR_TOP);
}

static int xen_unpin_page(struct mm_struct *mm, struct page *page,
			  enum pt_level level)
{
	unsigned pgfl = TestClearPagePinned(page);

	if (pgfl && !PageHighMem(page)) {
		void *pt = lowmem_page_address(page);
		unsigned long pfn = page_to_pfn(page);
		spinlock_t *ptl = NULL;
		struct multicall_space mcs;

		/*
		 * Do the converse to pin_page.  If we're using split
		 * pte locks, we must be holding the lock for while
		 * the pte page is unpinned but still RO to prevent
		 * concurrent updates from seeing it in this
		 * partially-pinned state.
		 */
		if (level == PT_PTE) {
			ptl = xen_pte_lock(page, mm);

			if (ptl)
				xen_do_pin(MMUEXT_UNPIN_TABLE, pfn);
		}

		mcs = __xen_mc_entry(0);

		MULTI_update_va_mapping(mcs.mc, (unsigned long)pt,
					pfn_pte(pfn, PAGE_KERNEL),
					level == PT_PGD ? UVMF_TLB_FLUSH : 0);

		if (ptl) {
			/* unlock when batch completed */
			xen_mc_callback(xen_pte_unlock, ptl);
		}
	}

	return 0;		/* never need to flush on unpin */
}

/* Release a pagetables pages back as normal RW */
static void __xen_pgd_unpin(struct mm_struct *mm, pgd_t *pgd)
{
	trace_xen_mmu_pgd_unpin(mm, pgd);

	xen_mc_batch();

	xen_do_pin(MMUEXT_UNPIN_TABLE, PFN_DOWN(__pa(pgd)));

#ifdef CONFIG_X86_64
	{
		pgd_t *user_pgd = xen_get_user_pgd(pgd);

		if (user_pgd) {
			xen_do_pin(MMUEXT_UNPIN_TABLE,
				   PFN_DOWN(__pa(user_pgd)));
			xen_unpin_page(mm, virt_to_page(user_pgd), PT_PGD);
		}
	}
#endif

#ifdef CONFIG_X86_PAE
	/* Need to make sure unshared kernel PMD is unpinned */
	xen_unpin_page(mm, pgd_page(pgd[pgd_index(TASK_SIZE)]),
		       PT_PMD);
#endif

	__xen_pgd_walk(mm, pgd, xen_unpin_page, USER_LIMIT);

	xen_mc_issue(0);
}

static void xen_pgd_unpin(struct mm_struct *mm)
{
	__xen_pgd_unpin(mm, mm->pgd);
}

/*
 * On resume, undo any pinning done at save, so that the rest of the
 * kernel doesn't see any unexpected pinned pagetables.
 */
void xen_mm_unpin_all(void)
{
	struct page *page;

	spin_lock(&pgd_lock);

	list_for_each_entry(page, &pgd_list, lru) {
		if (PageSavePinned(page)) {
			BUG_ON(!PagePinned(page));
			__xen_pgd_unpin(&init_mm, (pgd_t *)page_address(page));
			ClearPageSavePinned(page);
		}
	}

	spin_unlock(&pgd_lock);
}

static void xen_activate_mm(struct mm_struct *prev, struct mm_struct *next)
{
	spin_lock(&next->page_table_lock);
	xen_pgd_pin(next);
	spin_unlock(&next->page_table_lock);
}

static void xen_dup_mmap(struct mm_struct *oldmm, struct mm_struct *mm)
{
	spin_lock(&mm->page_table_lock);
	xen_pgd_pin(mm);
	spin_unlock(&mm->page_table_lock);
}


#ifdef CONFIG_SMP
/* Another cpu may still have their %cr3 pointing at the pagetable, so
   we need to repoint it somewhere else before we can unpin it. */
static void drop_other_mm_ref(void *info)
{
	struct mm_struct *mm = info;
	struct mm_struct *active_mm;

	active_mm = this_cpu_read(cpu_tlbstate.active_mm);

	if (active_mm == mm && this_cpu_read(cpu_tlbstate.state) != TLBSTATE_OK)
		leave_mm(smp_processor_id());

	/* If this cpu still has a stale cr3 reference, then make sure
	   it has been flushed. */
	if (this_cpu_read(xen_current_cr3) == __pa(mm->pgd))
		load_cr3(swapper_pg_dir);
}

static void xen_drop_mm_ref(struct mm_struct *mm)
{
	cpumask_var_t mask;
	unsigned cpu;

	if (current->active_mm == mm) {
		if (current->mm == mm)
			load_cr3(swapper_pg_dir);
		else
			leave_mm(smp_processor_id());
	}

	/* Get the "official" set of cpus referring to our pagetable. */
	if (!alloc_cpumask_var(&mask, GFP_ATOMIC)) {
		for_each_online_cpu(cpu) {
			if (!cpumask_test_cpu(cpu, mm_cpumask(mm))
			    && per_cpu(xen_current_cr3, cpu) != __pa(mm->pgd))
				continue;
			smp_call_function_single(cpu, drop_other_mm_ref, mm, 1);
		}
		return;
	}
	cpumask_copy(mask, mm_cpumask(mm));

	/* It's possible that a vcpu may have a stale reference to our
	   cr3, because its in lazy mode, and it hasn't yet flushed
	   its set of pending hypercalls yet.  In this case, we can
	   look at its actual current cr3 value, and force it to flush
	   if needed. */
	for_each_online_cpu(cpu) {
		if (per_cpu(xen_current_cr3, cpu) == __pa(mm->pgd))
			cpumask_set_cpu(cpu, mask);
	}

	if (!cpumask_empty(mask))
		smp_call_function_many(mask, drop_other_mm_ref, mm, 1);
	free_cpumask_var(mask);
}
#else
static void xen_drop_mm_ref(struct mm_struct *mm)
{
	if (current->active_mm == mm)
		load_cr3(swapper_pg_dir);
}
#endif

/*
 * While a process runs, Xen pins its pagetables, which means that the
 * hypervisor forces it to be read-only, and it controls all updates
 * to it.  This means that all pagetable updates have to go via the
 * hypervisor, which is moderately expensive.
 *
 * Since we're pulling the pagetable down, we switch to use init_mm,
 * unpin old process pagetable and mark it all read-write, which
 * allows further operations on it to be simple memory accesses.
 *
 * The only subtle point is that another CPU may be still using the
 * pagetable because of lazy tlb flushing.  This means we need need to
 * switch all CPUs off this pagetable before we can unpin it.
 */
static void xen_exit_mmap(struct mm_struct *mm)
{
	get_cpu();		/* make sure we don't move around */
	xen_drop_mm_ref(mm);
	put_cpu();

	spin_lock(&mm->page_table_lock);

	/* pgd may not be pinned in the error exit path of execve */
	if (xen_page_pinned(mm->pgd))
		xen_pgd_unpin(mm);

	spin_unlock(&mm->page_table_lock);
}

static void __init xen_pagetable_setup_start(pgd_t *base)
{
}

static __init void xen_mapping_pagetable_reserve(u64 start, u64 end)
{
	/* reserve the range used */
	native_pagetable_reserve(start, end);

	/* set as RW the rest */
	printk(KERN_DEBUG "xen: setting RW the range %llx - %llx\n", end,
			PFN_PHYS(pgt_buf_top));
	while (end < PFN_PHYS(pgt_buf_top)) {
		make_lowmem_page_readwrite(__va(end));
		end += PAGE_SIZE;
	}
}

static void xen_post_allocator_init(void);

static void __init xen_pagetable_setup_done(pgd_t *base)
{
	xen_setup_shared_info();

	if (xen_feature(XENFEAT_auto_translated_physmap))
		return;

	xen_post_allocator_init();
}

static void xen_write_cr2(unsigned long cr2)
{
	this_cpu_read(xen_vcpu)->arch.cr2 = cr2;
}

static unsigned long xen_read_cr2(void)
{
	return this_cpu_read(xen_vcpu)->arch.cr2;
}

unsigned long xen_read_cr2_direct(void)
{
	return this_cpu_read(xen_vcpu_info.arch.cr2);
}

static void xen_flush_tlb(void)
{
	struct mmuext_op *op;
	struct multicall_space mcs;

	trace_xen_mmu_flush_tlb(0);

	preempt_disable();

	mcs = xen_mc_entry(sizeof(*op));

	op = mcs.args;
	op->cmd = MMUEXT_TLB_FLUSH_LOCAL;
	MULTI_mmuext_op(mcs.mc, op, 1, NULL, DOMID_SELF);

	xen_mc_issue(PARAVIRT_LAZY_MMU);

	preempt_enable();
}

static void xen_flush_tlb_single(unsigned long addr)
{
	struct mmuext_op *op;
	struct multicall_space mcs;

	trace_xen_mmu_flush_tlb_single(addr);

	preempt_disable();

	mcs = xen_mc_entry(sizeof(*op));
	op = mcs.args;
	op->cmd = MMUEXT_INVLPG_LOCAL;
	op->arg1.linear_addr = addr & PAGE_MASK;
	MULTI_mmuext_op(mcs.mc, op, 1, NULL, DOMID_SELF);

	xen_mc_issue(PARAVIRT_LAZY_MMU);

	preempt_enable();
}

static void xen_flush_tlb_others(const struct cpumask *cpus,
				 struct mm_struct *mm, unsigned long start,
				 unsigned long end)
{
	struct {
		struct mmuext_op op;
#ifdef CONFIG_SMP
		DECLARE_BITMAP(mask, num_processors);
#else
		DECLARE_BITMAP(mask, NR_CPUS);
#endif
	} *args;
	struct multicall_space mcs;

	trace_xen_mmu_flush_tlb_others(cpus, mm, start, end);

	if (cpumask_empty(cpus))
		return;		/* nothing to do */

	mcs = xen_mc_entry(sizeof(*args));
	args = mcs.args;
	args->op.arg2.vcpumask = to_cpumask(args->mask);

	/* Remove us, and any offline CPUS. */
	cpumask_and(to_cpumask(args->mask), cpus, cpu_online_mask);
	cpumask_clear_cpu(smp_processor_id(), to_cpumask(args->mask));

	args->op.cmd = MMUEXT_TLB_FLUSH_MULTI;
	if (start != TLB_FLUSH_ALL && (end - start) <= PAGE_SIZE) {
		args->op.cmd = MMUEXT_INVLPG_MULTI;
		args->op.arg1.linear_addr = start;
	}

	MULTI_mmuext_op(mcs.mc, &args->op, 1, NULL, DOMID_SELF);

	xen_mc_issue(PARAVIRT_LAZY_MMU);
}

static unsigned long xen_read_cr3(void)
{
	return this_cpu_read(xen_cr3);
}

static void set_current_cr3(void *v)
{
	this_cpu_write(xen_current_cr3, (unsigned long)v);
}

static void __xen_write_cr3(bool kernel, unsigned long cr3)
{
	struct mmuext_op op;
	unsigned long mfn;

	trace_xen_mmu_write_cr3(kernel, cr3);

	if (cr3)
		mfn = pfn_to_mfn(PFN_DOWN(cr3));
	else
		mfn = 0;

	WARN_ON(mfn == 0 && kernel);

	op.cmd = kernel ? MMUEXT_NEW_BASEPTR : MMUEXT_NEW_USER_BASEPTR;
	op.arg1.mfn = mfn;

	xen_extend_mmuext_op(&op);

	if (kernel) {
		this_cpu_write(xen_cr3, cr3);

		/* Update xen_current_cr3 once the batch has actually
		   been submitted. */
		xen_mc_callback(set_current_cr3, (void *)cr3);
	}
}

static void xen_write_cr3(unsigned long cr3)
{
	BUG_ON(preemptible());

	xen_mc_batch();  /* disables interrupts */

	/* Update while interrupts are disabled, so its atomic with
	   respect to ipis */
	this_cpu_write(xen_cr3, cr3);

	__xen_write_cr3(true, cr3);

#ifdef CONFIG_X86_64
	{
		pgd_t *user_pgd = xen_get_user_pgd(__va(cr3));
		if (user_pgd)
			__xen_write_cr3(false, __pa(user_pgd));
		else
			__xen_write_cr3(false, 0);
	}
#endif

	xen_mc_issue(PARAVIRT_LAZY_CPU);  /* interrupts restored */
}

static int xen_pgd_alloc(struct mm_struct *mm)
{
	pgd_t *pgd = mm->pgd;
	int ret = 0;

	BUG_ON(PagePinned(virt_to_page(pgd)));

#ifdef CONFIG_X86_64
	{
		struct page *page = virt_to_page(pgd);
		pgd_t *user_pgd;

		BUG_ON(page->private != 0);

		ret = -ENOMEM;

		user_pgd = (pgd_t *)__get_free_page(GFP_KERNEL | __GFP_ZERO);
		page->private = (unsigned long)user_pgd;

		if (user_pgd != NULL) {
			user_pgd[pgd_index(VSYSCALL_START)] =
				__pgd(__pa(level3_user_vsyscall) | _PAGE_TABLE);
			ret = 0;
		}

		BUG_ON(PagePinned(virt_to_page(xen_get_user_pgd(pgd))));
	}
#endif

	return ret;
}

static void xen_pgd_free(struct mm_struct *mm, pgd_t *pgd)
{
#ifdef CONFIG_X86_64
	pgd_t *user_pgd = xen_get_user_pgd(pgd);

	if (user_pgd)
		free_page((unsigned long)user_pgd);
#endif
}

#ifdef CONFIG_X86_32
static pte_t __init mask_rw_pte(pte_t *ptep, pte_t pte)
{
	/* If there's an existing pte, then don't allow _PAGE_RW to be set */
	if (pte_val_ma(*ptep) & _PAGE_PRESENT)
		pte = __pte_ma(((pte_val_ma(*ptep) & _PAGE_RW) | ~_PAGE_RW) &
			       pte_val_ma(pte));

	return pte;
}
#else /* CONFIG_X86_64 */
static pte_t __init mask_rw_pte(pte_t *ptep, pte_t pte)
{
	unsigned long pfn = pte_pfn(pte);

	/*
	 * If the new pfn is within the range of the newly allocated
	 * kernel pagetable, and it isn't being mapped into an
	 * early_ioremap fixmap slot as a freshly allocated page, make sure
	 * it is RO.
	 */
	if (((!is_early_ioremap_ptep(ptep) &&
			pfn >= pgt_buf_start && pfn < pgt_buf_top)) ||
			(is_early_ioremap_ptep(ptep) && pfn != (pgt_buf_end - 1)))
		pte = pte_wrprotect(pte);

	return pte;
}
#endif /* CONFIG_X86_64 */

/*
 * Init-time set_pte while constructing initial pagetables, which
 * doesn't allow RO page table pages to be remapped RW.
 *
 * If there is no MFN for this PFN then this page is initially
 * ballooned out so clear the PTE (as in decrease_reservation() in
 * drivers/xen/balloon.c).
 *
 * Many of these PTE updates are done on unpinned and writable pages
 * and doing a hypercall for these is unnecessary and expensive.  At
 * this point it is not possible to tell if a page is pinned or not,
 * so always write the PTE directly and rely on Xen trapping and
 * emulating any updates as necessary.
 */
static void __init xen_set_pte_init(pte_t *ptep, pte_t pte)
{
	if (pte_mfn(pte) != INVALID_P2M_ENTRY)
		pte = mask_rw_pte(ptep, pte);
	else
		pte = __pte_ma(0);

	native_set_pte(ptep, pte);
}

static noinline void pin_pagetable_pfn(unsigned cmd, unsigned long pfn)
{
	struct mmuext_op op;

	if (xen_feature(XENFEAT_writable_page_tables))
		return;

	op.cmd = cmd;
	op.arg1.mfn = pfn_to_mfn(pfn);
	if (HYPERVISOR_mmuext_op(&op, 1, NULL, DOMID_SELF))
		BUG();
}

/* Early in boot, while setting up the initial pagetable, assume
   everything is pinned. */
static void __init xen_alloc_pte_init(struct mm_struct *mm, unsigned long pfn)
{
#ifdef CONFIG_FLATMEM
	BUG_ON(mem_map);	/* should only be used early */
#endif
	make_lowmem_page_readonly(__va(PFN_PHYS(pfn)));
	pin_pagetable_pfn(MMUEXT_PIN_L1_TABLE, pfn);
}

/* Used for pmd and pud */
static void __init xen_alloc_pmd_init(struct mm_struct *mm, unsigned long pfn)
{
#ifdef CONFIG_FLATMEM
	BUG_ON(mem_map);	/* should only be used early */
#endif
	make_lowmem_page_readonly(__va(PFN_PHYS(pfn)));
}

/* Early release_pte assumes that all pts are pinned, since there's
   only init_mm and anything attached to that is pinned. */
static void __init xen_release_pte_init(unsigned long pfn)
{
	pin_pagetable_pfn(MMUEXT_UNPIN_TABLE, pfn);
	make_lowmem_page_readwrite(__va(PFN_PHYS(pfn)));
}

static void __init xen_release_pmd_init(unsigned long pfn)
{
	make_lowmem_page_readwrite(__va(PFN_PHYS(pfn)));
}

static inline void __pin_pagetable_pfn(unsigned cmd, unsigned long pfn)
{
	struct multicall_space mcs;
	struct mmuext_op *op;

	mcs = __xen_mc_entry(sizeof(*op));
	op = mcs.args;
	op->cmd = cmd;
	op->arg1.mfn = pfn_to_mfn(pfn);

	MULTI_mmuext_op(mcs.mc, mcs.args, 1, NULL, DOMID_SELF);
}

static inline void __set_pfn_prot(unsigned long pfn, pgprot_t prot)
{
	struct multicall_space mcs;
	unsigned long addr = (unsigned long)__va(pfn << PAGE_SHIFT);

	mcs = __xen_mc_entry(0);
	MULTI_update_va_mapping(mcs.mc, (unsigned long)addr,
				pfn_pte(pfn, prot), 0);
}

/* This needs to make sure the new pte page is pinned iff its being
   attached to a pinned pagetable. */
static inline void xen_alloc_ptpage(struct mm_struct *mm, unsigned long pfn,
				    unsigned level)
{
	bool pinned = PagePinned(virt_to_page(mm->pgd));

	trace_xen_mmu_alloc_ptpage(mm, pfn, level, pinned);

	if (pinned) {
		struct page *page = pfn_to_page(pfn);

		SetPagePinned(page);

		if (!PageHighMem(page)) {
			xen_mc_batch();

			__set_pfn_prot(pfn, PAGE_KERNEL_RO);

			if (level == PT_PTE && USE_SPLIT_PTLOCKS)
				__pin_pagetable_pfn(MMUEXT_PIN_L1_TABLE, pfn);

			xen_mc_issue(PARAVIRT_LAZY_MMU);
		} else {
			/* make sure there are no stray mappings of
			   this page */
			kmap_flush_unused();
		}
	}
}

static void xen_alloc_pte(struct mm_struct *mm, unsigned long pfn)
{
	xen_alloc_ptpage(mm, pfn, PT_PTE);
}

static void xen_alloc_pmd(struct mm_struct *mm, unsigned long pfn)
{
	xen_alloc_ptpage(mm, pfn, PT_PMD);
}

/* This should never happen until we're OK to use struct page */
static inline void xen_release_ptpage(unsigned long pfn, unsigned level)
{
	struct page *page = pfn_to_page(pfn);
	bool pinned = PagePinned(page);

	trace_xen_mmu_release_ptpage(pfn, level, pinned);

	if (pinned) {
		if (!PageHighMem(page)) {
			xen_mc_batch();

			if (level == PT_PTE && USE_SPLIT_PTLOCKS)
				__pin_pagetable_pfn(MMUEXT_UNPIN_TABLE, pfn);

			__set_pfn_prot(pfn, PAGE_KERNEL);

			xen_mc_issue(PARAVIRT_LAZY_MMU);
		}
		ClearPagePinned(page);
	}
}

static void xen_release_pte(unsigned long pfn)
{
	xen_release_ptpage(pfn, PT_PTE);
}

static void xen_release_pmd(unsigned long pfn)
{
	xen_release_ptpage(pfn, PT_PMD);
}

#if PAGETABLE_LEVELS == 4
static void xen_alloc_pud(struct mm_struct *mm, unsigned long pfn)
{
	xen_alloc_ptpage(mm, pfn, PT_PUD);
}

static void xen_release_pud(unsigned long pfn)
{
	xen_release_ptpage(pfn, PT_PUD);
}
#endif

void __init xen_reserve_top(void)
{
#ifdef CONFIG_X86_32
	unsigned long top = HYPERVISOR_VIRT_START;
	struct xen_platform_parameters pp;

	if (HYPERVISOR_xen_version(XENVER_platform_parameters, &pp) == 0)
		top = pp.virt_start;

	reserve_top_address(-top);
#endif	/* CONFIG_X86_32 */
}

/*
 * Like __va(), but returns address in the kernel mapping (which is
 * all we have until the physical memory mapping has been set up.
 */
static void *__ka(phys_addr_t paddr)
{
#ifdef CONFIG_X86_64
	return (void *)(paddr + __START_KERNEL_map);
#else
	return __va(paddr);
#endif
}

/* Convert a machine address to physical address */
static unsigned long m2p(phys_addr_t maddr)
{
	phys_addr_t paddr;

	maddr &= PTE_PFN_MASK;
	paddr = mfn_to_pfn(maddr >> PAGE_SHIFT) << PAGE_SHIFT;

	return paddr;
}

/* Convert a machine address to kernel virtual */
static void *m2v(phys_addr_t maddr)
{
	return __ka(m2p(maddr));
}

/* Set the page permissions on an identity-mapped pages */
static void set_page_prot(void *addr, pgprot_t prot)
{
	unsigned long pfn = __pa(addr) >> PAGE_SHIFT;
	pte_t pte = pfn_pte(pfn, prot);

	/* recall for PVH, page tables are native. */
	if (xen_feature(XENFEAT_auto_translated_physmap))
		return;

	if (HYPERVISOR_update_va_mapping((unsigned long)addr, pte, 0))
		BUG();
}

static void __init xen_map_identity_early(pmd_t *pmd, unsigned long max_pfn)
{
	unsigned pmdidx, pteidx;
	unsigned ident_pte;
	unsigned long pfn;

	level1_ident_pgt = extend_brk(sizeof(pte_t) * LEVEL1_IDENT_ENTRIES,
				      PAGE_SIZE);

	ident_pte = 0;
	pfn = 0;
	for (pmdidx = 0; pmdidx < PTRS_PER_PMD && pfn < max_pfn; pmdidx++) {
		pte_t *pte_page;

		/* Reuse or allocate a page of ptes */
		if (pmd_present(pmd[pmdidx]))
			pte_page = m2v(pmd[pmdidx].pmd);
		else {
			/* Check for free pte pages */
			if (ident_pte == LEVEL1_IDENT_ENTRIES)
				break;

			pte_page = &level1_ident_pgt[ident_pte];
			ident_pte += PTRS_PER_PTE;

			pmd[pmdidx] = __pmd(__pa(pte_page) | _PAGE_TABLE);
		}

		/* Install mappings */
		for (pteidx = 0; pteidx < PTRS_PER_PTE; pteidx++, pfn++) {
			pte_t pte;

#ifdef CONFIG_X86_32
			if (pfn > max_pfn_mapped)
				max_pfn_mapped = pfn;
#endif

			if (!pte_none(pte_page[pteidx]))
				continue;

			pte = pfn_pte(pfn, PAGE_KERNEL_EXEC);
			pte_page[pteidx] = pte;
		}
	}

	for (pteidx = 0; pteidx < ident_pte; pteidx += PTRS_PER_PTE)
		set_page_prot(&level1_ident_pgt[pteidx], PAGE_KERNEL_RO);

	set_page_prot(pmd, PAGE_KERNEL_RO);
}

void __init xen_setup_machphys_mapping(void)
{
	struct xen_machphys_mapping mapping;

	if (HYPERVISOR_memory_op(XENMEM_machphys_mapping, &mapping) == 0) {
		machine_to_phys_mapping = (unsigned long *)mapping.v_start;
		machine_to_phys_nr = mapping.max_mfn + 1;
	} else {
		machine_to_phys_nr = MACH2PHYS_NR_ENTRIES;
	}
#ifdef CONFIG_X86_32
	WARN_ON((machine_to_phys_mapping + (machine_to_phys_nr - 1))
		< machine_to_phys_mapping);
#endif
}

#ifdef CONFIG_X86_64
static void convert_pfn_mfn(void *v)
{
	pte_t *pte = v;
	int i;

	if (xen_feature(XENFEAT_auto_translated_physmap))
		return;

	/* All levels are converted the same way, so just treat them
	   as ptes. */
	for (i = 0; i < PTRS_PER_PTE; i++)
		pte[i] = xen_make_pte(pte[i].pte);
}

/*
 * Set up the initial kernel pagetable.
 *
 * We can construct this by grafting the Xen provided pagetable into
 * head_64.S's preconstructed pagetables.  We copy the Xen L2's into
 * level2_ident_pgt, level2_kernel_pgt and level2_fixmap_pgt.  This
 * means that only the kernel has a physical mapping to start with -
 * but that's enough to get __va working.  We need to fill in the rest
 * of the physical mapping once some sort of allocator has been set
 * up.
 * NOTE: for PVH, the page tables are native.
 */
pgd_t * __init xen_setup_kernel_pagetable(pgd_t *pgd,
					 unsigned long max_pfn)
{
	pud_t *l3;
	pmd_t *l2;

	/* max_pfn_mapped is the last pfn mapped in the initial memory
	 * mappings. Considering that on Xen after the kernel mappings we
	 * have the mappings of some pages that don't exist in pfn space, we
	 * set max_pfn_mapped to the last real pfn mapped. */
	max_pfn_mapped = PFN_DOWN(__pa(xen_start_info->mfn_list));

	/* Zap identity mapping */
	init_level4_pgt[0] = __pgd(0);

	/* Pre-constructed entries are in pfn, so convert to mfn */
	convert_pfn_mfn(init_level4_pgt);
	convert_pfn_mfn(level3_ident_pgt);
	convert_pfn_mfn(level3_kernel_pgt);

	l3 = m2v(pgd[pgd_index(__START_KERNEL_map)].pgd);
	l2 = m2v(l3[pud_index(__START_KERNEL_map)].pud);

	memcpy(level2_ident_pgt, l2, sizeof(pmd_t) * PTRS_PER_PMD);
	memcpy(level2_kernel_pgt, l2, sizeof(pmd_t) * PTRS_PER_PMD);

	l3 = m2v(pgd[pgd_index(__START_KERNEL_map + PMD_SIZE)].pgd);
	l2 = m2v(l3[pud_index(__START_KERNEL_map + PMD_SIZE)].pud);
	memcpy(level2_fixmap_pgt, l2, sizeof(pmd_t) * PTRS_PER_PMD);

	/* Set up identity map */
	xen_map_identity_early(level2_ident_pgt, max_pfn);

	/* Make pagetable pieces RO */
	set_page_prot(init_level4_pgt, PAGE_KERNEL_RO);
	set_page_prot(level3_ident_pgt, PAGE_KERNEL_RO);
	set_page_prot(level3_kernel_pgt, PAGE_KERNEL_RO);
	set_page_prot(level3_user_vsyscall, PAGE_KERNEL_RO);
	set_page_prot(level2_kernel_pgt, PAGE_KERNEL_RO);
	set_page_prot(level2_fixmap_pgt, PAGE_KERNEL_RO);

	/* Pin down new L4 */
	pin_pagetable_pfn(MMUEXT_PIN_L4_TABLE,
		  	PFN_DOWN(__pa_symbol(init_level4_pgt)));

	/* Unpin Xen-provided one */
	pin_pagetable_pfn(MMUEXT_UNPIN_TABLE, PFN_DOWN(__pa(pgd)));

	/* Switch over */
	pgd = init_level4_pgt;

	/*
	 * At this stage there can be no user pgd, and no page
	 * structure to attach it to, so make sure we just set kernel
	 * pgd.
	 */
	if (xen_feature(XENFEAT_writable_page_tables)) {
		native_write_cr3(__pa(pgd));
	} else {
		xen_mc_batch();
		__xen_write_cr3(true, __pa(pgd));
		xen_mc_issue(PARAVIRT_LAZY_CPU);
	}

	memblock_reserve(__pa(xen_start_info->pt_base),
			 xen_start_info->nr_pt_frames * PAGE_SIZE);

	return pgd;
}
#else	/* !CONFIG_X86_64 */
static RESERVE_BRK_ARRAY(pmd_t, initial_kernel_pmd, PTRS_PER_PMD);
static RESERVE_BRK_ARRAY(pmd_t, swapper_kernel_pmd, PTRS_PER_PMD);

static void __init xen_write_cr3_init(unsigned long cr3)
{
	unsigned long pfn = PFN_DOWN(__pa(swapper_pg_dir));

	BUG_ON(read_cr3() != __pa(initial_page_table));
	BUG_ON(cr3 != __pa(swapper_pg_dir));

	/*
	 * We are switching to swapper_pg_dir for the first time (from
	 * initial_page_table) and therefore need to mark that page
	 * read-only and then pin it.
	 *
	 * Xen disallows sharing of kernel PMDs for PAE
	 * guests. Therefore we must copy the kernel PMD from
	 * initial_page_table into a new kernel PMD to be used in
	 * swapper_pg_dir.
	 */
	swapper_kernel_pmd =
		extend_brk(sizeof(pmd_t) * PTRS_PER_PMD, PAGE_SIZE);
	memcpy(swapper_kernel_pmd, initial_kernel_pmd,
	       sizeof(pmd_t) * PTRS_PER_PMD);
	swapper_pg_dir[KERNEL_PGD_BOUNDARY] =
		__pgd(__pa(swapper_kernel_pmd) | _PAGE_PRESENT);
	set_page_prot(swapper_kernel_pmd, PAGE_KERNEL_RO);

	set_page_prot(swapper_pg_dir, PAGE_KERNEL_RO);
	xen_write_cr3(cr3);
	pin_pagetable_pfn(MMUEXT_PIN_L3_TABLE, pfn);

	pin_pagetable_pfn(MMUEXT_UNPIN_TABLE,
			  PFN_DOWN(__pa(initial_page_table)));
	set_page_prot(initial_page_table, PAGE_KERNEL);
	set_page_prot(initial_kernel_pmd, PAGE_KERNEL);

	pv_mmu_ops.write_cr3 = &xen_write_cr3;
}

pgd_t * __init xen_setup_kernel_pagetable(pgd_t *pgd,
					 unsigned long max_pfn)
{
	pmd_t *kernel_pmd;

	initial_kernel_pmd =
		extend_brk(sizeof(pmd_t) * PTRS_PER_PMD, PAGE_SIZE);

	max_pfn_mapped = PFN_DOWN(__pa(xen_start_info->pt_base) +
				  xen_start_info->nr_pt_frames * PAGE_SIZE +
				  512*1024);

	kernel_pmd = m2v(pgd[KERNEL_PGD_BOUNDARY].pgd);
	memcpy(initial_kernel_pmd, kernel_pmd, sizeof(pmd_t) * PTRS_PER_PMD);

	xen_map_identity_early(initial_kernel_pmd, max_pfn);

	memcpy(initial_page_table, pgd, sizeof(pgd_t) * PTRS_PER_PGD);
	initial_page_table[KERNEL_PGD_BOUNDARY] =
		__pgd(__pa(initial_kernel_pmd) | _PAGE_PRESENT);

	set_page_prot(initial_kernel_pmd, PAGE_KERNEL_RO);
	set_page_prot(initial_page_table, PAGE_KERNEL_RO);
	set_page_prot(empty_zero_page, PAGE_KERNEL_RO);

	pin_pagetable_pfn(MMUEXT_UNPIN_TABLE, PFN_DOWN(__pa(pgd)));

	pin_pagetable_pfn(MMUEXT_PIN_L3_TABLE,
			  PFN_DOWN(__pa(initial_page_table)));
	xen_write_cr3(__pa(initial_page_table));

	memblock_reserve(__pa(xen_start_info->pt_base),
			 xen_start_info->nr_pt_frames * PAGE_SIZE);

	return initial_page_table;
}
#endif	/* CONFIG_X86_64 */

static unsigned char dummy_mapping[PAGE_SIZE] __page_aligned_bss;

static void xen_set_fixmap(unsigned idx, phys_addr_t phys, pgprot_t prot)
{
	pte_t pte;

	phys >>= PAGE_SHIFT;

	switch (idx) {
	case FIX_BTMAP_END ... FIX_BTMAP_BEGIN:
#ifdef CONFIG_X86_F00F_BUG
	case FIX_F00F_IDT:
#endif
#ifdef CONFIG_X86_32
	case FIX_WP_TEST:
	case FIX_VDSO:
# ifdef CONFIG_HIGHMEM
	case FIX_KMAP_BEGIN ... FIX_KMAP_END:
# endif
#else
	case VSYSCALL_LAST_PAGE ... VSYSCALL_FIRST_PAGE:
	case VVAR_PAGE:
#endif
	case FIX_TEXT_POKE0:
	case FIX_TEXT_POKE1:
		/* All local page mappings */
		pte = pfn_pte(phys, prot);
		break;

#ifdef CONFIG_X86_LOCAL_APIC
	case FIX_APIC_BASE:	/* maps dummy local APIC */
		pte = pfn_pte(PFN_DOWN(__pa(dummy_mapping)), PAGE_KERNEL);
		break;
#endif

#ifdef CONFIG_X86_IO_APIC
	case FIX_IO_APIC_BASE_0 ... FIX_IO_APIC_BASE_END:
		/*
		 * We just don't map the IO APIC - all access is via
		 * hypercalls.  Keep the address in the pte for reference.
		 */
		pte = pfn_pte(PFN_DOWN(__pa(dummy_mapping)), PAGE_KERNEL);
		break;
#endif

	case FIX_PARAVIRT_BOOTMAP:
		/* This is an MFN, but it isn't an IO mapping from the
		   IO domain */
		pte = mfn_pte(phys, prot);
		break;

	default:
		/* By default, set_fixmap is used for hardware mappings */
		pte = mfn_pte(phys, __pgprot(pgprot_val(prot) | _PAGE_IOMAP));
		break;
	}

	__native_set_fixmap(idx, pte);

#ifdef CONFIG_X86_64
	/* Replicate changes to map the vsyscall page into the user
	   pagetable vsyscall mapping. */
	if ((idx >= VSYSCALL_LAST_PAGE && idx <= VSYSCALL_FIRST_PAGE) ||
	    idx == VVAR_PAGE) {
		unsigned long vaddr = __fix_to_virt(idx);
		set_pte_vaddr_pud(level3_user_vsyscall, vaddr, pte);
	}
#endif
}

static void __init xen_post_allocator_init(void)
{
	pv_mmu_ops.set_pte = xen_set_pte;
	pv_mmu_ops.set_pmd = xen_set_pmd;
	pv_mmu_ops.set_pud = xen_set_pud;
#if PAGETABLE_LEVELS == 4
	pv_mmu_ops.set_pgd = xen_set_pgd;
#endif

	/* This will work as long as patching hasn't happened yet
	   (which it hasn't) */
	pv_mmu_ops.alloc_pte = xen_alloc_pte;
	pv_mmu_ops.alloc_pmd = xen_alloc_pmd;
	pv_mmu_ops.release_pte = xen_release_pte;
	pv_mmu_ops.release_pmd = xen_release_pmd;
#if PAGETABLE_LEVELS == 4
	pv_mmu_ops.alloc_pud = xen_alloc_pud;
	pv_mmu_ops.release_pud = xen_release_pud;
#endif

#ifdef CONFIG_X86_64
	SetPagePinned(virt_to_page(level3_user_vsyscall));
#endif
	xen_mark_init_mm_pinned();
}

static void xen_leave_lazy_mmu(void)
{
	preempt_disable();
	xen_mc_flush();
	paravirt_leave_lazy_mmu();
	preempt_enable();
}

static const struct pv_mmu_ops xen_mmu_ops __initconst = {
	.read_cr2 = xen_read_cr2,
	.write_cr2 = xen_write_cr2,

	.read_cr3 = xen_read_cr3,
#ifdef CONFIG_X86_32
	.write_cr3 = xen_write_cr3_init,
#else
	.write_cr3 = xen_write_cr3,
#endif

	.flush_tlb_user = xen_flush_tlb,
	.flush_tlb_kernel = xen_flush_tlb,
	.flush_tlb_single = xen_flush_tlb_single,
	.flush_tlb_others = xen_flush_tlb_others,

	.pte_update = paravirt_nop,
	.pte_update_defer = paravirt_nop,

	.pgd_alloc = xen_pgd_alloc,
	.pgd_free = xen_pgd_free,

	.alloc_pte = xen_alloc_pte_init,
	.release_pte = xen_release_pte_init,
	.alloc_pmd = xen_alloc_pmd_init,
	.release_pmd = xen_release_pmd_init,

	.set_pte = xen_set_pte_init,
	.set_pte_at = xen_set_pte_at,
	.set_pmd = xen_set_pmd_hyper,

	.ptep_modify_prot_start = __ptep_modify_prot_start,
	.ptep_modify_prot_commit = __ptep_modify_prot_commit,

	.pte_val = PV_CALLEE_SAVE(xen_pte_val),
	.pgd_val = PV_CALLEE_SAVE(xen_pgd_val),

	.make_pte = PV_CALLEE_SAVE(xen_make_pte),
	.make_pgd = PV_CALLEE_SAVE(xen_make_pgd),

#ifdef CONFIG_X86_PAE
	.set_pte_atomic = xen_set_pte_atomic,
	.pte_clear = xen_pte_clear,
	.pmd_clear = xen_pmd_clear,
#endif	/* CONFIG_X86_PAE */
	.set_pud = xen_set_pud_hyper,

	.make_pmd = PV_CALLEE_SAVE(xen_make_pmd),
	.pmd_val = PV_CALLEE_SAVE(xen_pmd_val),

#if PAGETABLE_LEVELS == 4
	.pud_val = PV_CALLEE_SAVE(xen_pud_val),
	.make_pud = PV_CALLEE_SAVE(xen_make_pud),
	.set_pgd = xen_set_pgd_hyper,

	.alloc_pud = xen_alloc_pmd_init,
	.release_pud = xen_release_pmd_init,
#endif	/* PAGETABLE_LEVELS == 4 */

	.activate_mm = xen_activate_mm,
	.dup_mmap = xen_dup_mmap,
	.exit_mmap = xen_exit_mmap,

	.lazy_mode = {
		.enter = paravirt_enter_lazy_mmu,
		.leave = xen_leave_lazy_mmu,
	},

	.set_fixmap = xen_set_fixmap,
};

void __init xen_init_mmu_ops(void)
{
	x86_init.paging.pagetable_setup_done = xen_pagetable_setup_done;

	if (xen_feature(XENFEAT_auto_translated_physmap)) {
		pv_mmu_ops.flush_tlb_others = xen_flush_tlb_others;

		/* set_pte* for PCI devices to map iomem. */
		if (xen_initial_domain()) {
			pv_mmu_ops.set_pte = native_set_pte;
			pv_mmu_ops.set_pte_at = xen_dom0pvh_set_pte_at;
		}
		return;
	}

	x86_init.mapping.pagetable_reserve = xen_mapping_pagetable_reserve;
	x86_init.paging.pagetable_setup_start = xen_pagetable_setup_start;
	pv_mmu_ops = xen_mmu_ops;

	memset(dummy_mapping, 0xff, PAGE_SIZE);
}

/* Protected by xen_reservation_lock. */
#define MAX_CONTIG_ORDER 9 /* 2MB */
static unsigned long discontig_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,
				unsigned long *in_frames,
				unsigned long *out_frames)
{
	int i;
	struct multicall_space mcs;

	xen_mc_batch();
	for (i = 0; i < (1UL<<order); i++, vaddr += PAGE_SIZE) {
		mcs = __xen_mc_entry(0);

		if (in_frames)
			in_frames[i] = virt_to_mfn(vaddr);

		MULTI_update_va_mapping(mcs.mc, vaddr, VOID_PTE, 0);
		__set_phys_to_machine(virt_to_pfn(vaddr), INVALID_P2M_ENTRY);

		if (out_frames)
			out_frames[i] = virt_to_pfn(vaddr);
	}
	xen_mc_issue(0);
}

/*
 * Update the pfn-to-mfn mappings for a virtual address range, either to
 * point to an array of mfns, or contiguously from a single starting
 * mfn.
 */
static void xen_remap_exchanged_ptes(unsigned long vaddr, int order,
				     unsigned long *mfns,
				     unsigned long first_mfn)
{
	unsigned i, limit;
	unsigned long mfn;

	xen_mc_batch();

	limit = 1u << order;
	for (i = 0; i < limit; i++, vaddr += PAGE_SIZE) {
		struct multicall_space mcs;
		unsigned flags;

		mcs = __xen_mc_entry(0);
		if (mfns)
			mfn = mfns[i];
		else
			mfn = first_mfn + i;

		if (i < (limit - 1))
			flags = 0;
		else {
			if (order == 0)
				flags = UVMF_INVLPG | UVMF_ALL;
			else
				flags = UVMF_TLB_FLUSH | UVMF_ALL;
		}

		MULTI_update_va_mapping(mcs.mc, vaddr,
				mfn_pte(mfn, PAGE_KERNEL), flags);

		set_phys_to_machine(virt_to_pfn(vaddr), mfn);
	}

	xen_mc_issue(0);
}

/*
 * Perform the hypercall to exchange a region of our pfns to point to
 * memory with the required contiguous alignment.  Takes the pfns as
 * input, and populates mfns as output.
 *
 * Returns a success code indicating whether the hypervisor was able to
 * satisfy the request or not.
 */
static int xen_exchange_memory(unsigned long extents_in, unsigned int order_in,
			       unsigned long *pfns_in,
			       unsigned long extents_out,
			       unsigned int order_out,
			       unsigned long *mfns_out,
			       unsigned int address_bits)
{
	long rc;
	int success;

	struct xen_memory_exchange exchange = {
		.in = {
			.nr_extents   = extents_in,
			.extent_order = order_in,
			.extent_start = pfns_in,
			.domid        = DOMID_SELF
		},
		.out = {
			.nr_extents   = extents_out,
			.extent_order = order_out,
			.extent_start = mfns_out,
			.address_bits = address_bits,
			.domid        = DOMID_SELF
		}
	};

	BUG_ON(extents_in << order_in != extents_out << order_out);

	rc = HYPERVISOR_memory_op(XENMEM_exchange, &exchange);
	success = (exchange.nr_exchanged == extents_in);

	BUG_ON(!success && ((exchange.nr_exchanged != 0) || (rc == 0)));
	BUG_ON(success && (rc != 0));

	return success;
}

int xen_create_contiguous_region(unsigned long vstart, unsigned int order,
				 unsigned int address_bits)
{
	unsigned long *in_frames = discontig_frames, out_frame;
	unsigned long  flags;
	int            success;

	/*
	 * Currently an auto-translated guest will not perform I/O, nor will
	 * it require PAE page directories below 4GB. Therefore any calls to
	 * this function are redundant and can be ignored.
	 */

	if (xen_feature(XENFEAT_auto_translated_physmap))
		return 0;

	if (unlikely(order > MAX_CONTIG_ORDER))
		return -ENOMEM;

	memset((void *) vstart, 0, PAGE_SIZE << order);

	spin_lock_irqsave(&xen_reservation_lock, flags);

	/* 1. Zap current PTEs, remembering MFNs. */
	xen_zap_pfn_range(vstart, order, in_frames, NULL);

	/* 2. Get a new contiguous memory extent. */
	out_frame = virt_to_pfn(vstart);
	success = xen_exchange_memory(1UL << order, 0, in_frames,
				      1, order, &out_frame,
				      address_bits);

	/* 3. Map the new extent in place of old pages. */
	if (success)
		xen_remap_exchanged_ptes(vstart, order, NULL, out_frame);
	else
		xen_remap_exchanged_ptes(vstart, order, in_frames, 0);

	spin_unlock_irqrestore(&xen_reservation_lock, flags);

	return success ? 0 : -ENOMEM;
}
EXPORT_SYMBOL_GPL(xen_create_contiguous_region);

void xen_destroy_contiguous_region(unsigned long vstart, unsigned int order)
{
	unsigned long *out_frames = discontig_frames, in_frame;
	unsigned long  flags;
	int success;

	if (xen_feature(XENFEAT_auto_translated_physmap))
		return;

	if (unlikely(order > MAX_CONTIG_ORDER))
		return;

	memset((void *) vstart, 0, PAGE_SIZE << order);

	spin_lock_irqsave(&xen_reservation_lock, flags);

	/* 1. Find start MFN of contiguous extent. */
	in_frame = virt_to_mfn(vstart);

	/* 2. Zap current PTEs. */
	xen_zap_pfn_range(vstart, order, NULL, out_frames);

	/* 3. Do the exchange for non-contiguous MFNs. */
	success = xen_exchange_memory(1, order, &in_frame, 1UL << order,
					0, out_frames, 0);

	/* 4. Map new pages in place of old pages. */
	if (success)
		xen_remap_exchanged_ptes(vstart, order, out_frames, 0);
	else
		xen_remap_exchanged_ptes(vstart, order, NULL, in_frame);

	spin_unlock_irqrestore(&xen_reservation_lock, flags);
}
EXPORT_SYMBOL_GPL(xen_destroy_contiguous_region);

#ifdef CONFIG_XEN_PVHVM
static void xen_hvm_exit_mmap(struct mm_struct *mm)
{
	struct xen_hvm_pagetable_dying a;
	int rc;

	a.domid = DOMID_SELF;
	a.gpa = __pa(mm->pgd);
	rc = HYPERVISOR_hvm_op(HVMOP_pagetable_dying, &a);
	WARN_ON_ONCE(rc < 0);
}

static int is_pagetable_dying_supported(void)
{
	struct xen_hvm_pagetable_dying a;
	int rc = 0;

	a.domid = DOMID_SELF;
	a.gpa = 0x00;
	rc = HYPERVISOR_hvm_op(HVMOP_pagetable_dying, &a);
	if (rc < 0) {
		printk(KERN_DEBUG "HVMOP_pagetable_dying not supported\n");
		return 0;
	}
	return 1;
}

void __init xen_hvm_init_mmu_ops(void)
{
	if (is_pagetable_dying_supported())
		pv_mmu_ops.exit_mmap = xen_hvm_exit_mmap;
}
#endif

/* Map foreign gmfn, fgmfn, to local pfn, lpfn. This for the user space 
 * creating new guest on PVH dom0 and needs to map domU pages. Called from
 * exported function, so no need to export this.
 */
static noinline int pvh_add_to_xen_p2m(unsigned long lpfn, unsigned long fgmfn,
			      unsigned int domid)
{
	int rc;
	struct xen_add_to_physmap xatp = { .foreign_domid = domid };

	xatp.gpfn = lpfn;
	xatp.idx = fgmfn;
	xatp.domid = DOMID_SELF;
	xatp.space = XENMAPSPACE_gmfn_foreign;
	rc = HYPERVISOR_memory_op(XENMEM_add_to_physmap, &xatp);
	if (rc)
		pr_warn("d0: Failed to map pfn to mfn rc:%d pfn:%lx mfn:%lx\n", 
			rc, lpfn, fgmfn); 
	return rc;
}

int pvh_rem_xen_p2m(unsigned long spfn, int count)
{
	struct xen_remove_from_physmap xrp;
	int i, rc;

	for (i=0; i < count; i++) {
		xrp.domid = DOMID_SELF;
		xrp.gpfn = spfn+i;
		rc = HYPERVISOR_memory_op(XENMEM_remove_from_physmap, &xrp);
		if (rc) {
			pr_warn("Failed to unmap pfn:%lx rc:%d done:%d\n",
				spfn+i, rc, i);
			return 1;
		}
	}
	return 0;
}
EXPORT_SYMBOL_GPL(pvh_rem_xen_p2m);

struct pvh_remap_data {
	unsigned long fgmfn;		/* foreign domain's gmfn */
	pgprot_t prot;
	domid_t  domid;
	struct xen_pvh_pfn_info *pvhinfop;
};

static noinline int pvh_map_pte_fn(pte_t *ptep, pgtable_t token, unsigned long addr, 
			void *data)
{
	int rc;
	struct pvh_remap_data *remapp = data;
	struct xen_pvh_pfn_info *pvhp = remapp->pvhinfop;
	unsigned long pfn = page_to_pfn(pvhp->pi_paga[pvhp->pi_next_todo++]);
	pte_t pteval = pte_mkspecial(pfn_pte(pfn, remapp->prot));

	if ((rc=pvh_add_to_xen_p2m(pfn, remapp->fgmfn, remapp->domid)))
		return rc;
	native_set_pte(ptep, pteval);

	return 0;
}

/* The only caller at moment passes one gmfn at a time.
 * PVH TBD/FIXME: expand this in future to honor batch requests.
 */
static noinline int pvh_remap_gmfn_range(struct vm_area_struct *vma,
				unsigned long addr, unsigned long mfn, int nr,
				pgprot_t prot, unsigned domid,
				struct xen_pvh_pfn_info *pvhp)
{
	int err;
	struct pvh_remap_data pvhdata;

	if (nr > 1)
		return -EINVAL;

	pvhdata.fgmfn = mfn;
	pvhdata.prot = prot;
	pvhdata.domid = domid;
	pvhdata.pvhinfop = pvhp;
	err = apply_to_page_range(vma->vm_mm, addr, nr << PAGE_SHIFT,
				  pvh_map_pte_fn, &pvhdata);
	flush_tlb_all();
	return err;
}

#define REMAP_BATCH_SIZE 16

struct remap_data {
	unsigned long mfn;
	pgprot_t prot;
	struct mmu_update *mmu_update;
};

static int remap_area_mfn_pte_fn(pte_t *ptep, pgtable_t token,
				 unsigned long addr, void *data)
{
	struct remap_data *rmd = data;
	pte_t pte = pte_mkspecial(pfn_pte(rmd->mfn++, rmd->prot));

	rmd->mmu_update->ptr = virt_to_machine(ptep).maddr;
	rmd->mmu_update->val = pte_val_ma(pte);
	rmd->mmu_update++;

	return 0;
}

int xen_remap_domain_mfn_range(struct vm_area_struct *vma,
			       unsigned long addr,
			       unsigned long mfn, int nr,
			       pgprot_t prot, unsigned domid,
			       struct xen_pvh_pfn_info *pvhp)

{
	struct remap_data rmd;
	struct mmu_update mmu_update[REMAP_BATCH_SIZE];
	int batch;
	unsigned long range;
	int err = 0;

	prot = __pgprot(pgprot_val(prot) | _PAGE_IOMAP);

	BUG_ON(!((vma->vm_flags & (VM_PFNMAP | VM_RESERVED | VM_IO)) ==
				(VM_PFNMAP | VM_RESERVED | VM_IO)));

	if (xen_feature(XENFEAT_auto_translated_physmap)) {
		/* We need to update the local page tables and the xen HAP */
		return pvh_remap_gmfn_range(vma, addr, mfn, nr, prot, domid,
					    pvhp);
	}

	rmd.mfn = mfn;
	rmd.prot = prot;

	while (nr) {
		batch = min(REMAP_BATCH_SIZE, nr);
		range = (unsigned long)batch << PAGE_SHIFT;

		rmd.mmu_update = mmu_update;
		err = apply_to_page_range(vma->vm_mm, addr, range,
					  remap_area_mfn_pte_fn, &rmd);
		if (err)
			goto out;

		err = -EFAULT;
		if (HYPERVISOR_mmu_update(mmu_update, batch, NULL, domid) < 0)
			goto out;

		nr -= batch;
		addr += range;
	}

	err = 0;
out:

	flush_tlb_all();

	return err;
}
EXPORT_SYMBOL_GPL(xen_remap_domain_mfn_range);

/* Returns: Number of pages unmapped */
int xen_unmap_domain_mfn_range(struct vm_area_struct *vma,
			       struct xen_pvh_pfn_info *pvhp)
{
	int count = 0;

	if (!pvhp || !xen_feature(XENFEAT_auto_translated_physmap))
		return 0;

	while (pvhp->pi_next_todo--) {
		unsigned long pfn;

		/* the mmu has already cleaned up the process mmu resources at
		 * this point (lookup_address will return NULL). */
		pfn = page_to_pfn(pvhp->pi_paga[pvhp->pi_next_todo]);
		pvh_rem_xen_p2m(pfn, 1);
		count++;
	}
	flush_tlb_all();
	return count;
}
EXPORT_SYMBOL_GPL(xen_unmap_domain_mfn_range);

--MP_/+jFOV+feCm6gc.MLEl3bALy
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 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_/+jFOV+feCm6gc.MLEl3bALy--


From xen-devel-bounces@lists.xen.org Tue Sep 18 00:03:53 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Sep 2012 00:03:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDlHk-0004yZ-GG; Tue, 18 Sep 2012 00:03:28 +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 1TDlHj-0004yU-A1
	for xen-devel@lists.xensource.com; Tue, 18 Sep 2012 00:03:27 +0000
Received: from [85.158.138.51:38965] by server-6.bemta-3.messagelabs.com id
	E5/19-29694-E4AB7505; Tue, 18 Sep 2012 00:03:26 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-11.tower-174.messagelabs.com!1347926605!30921138!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12222 invoked from network); 18 Sep 2012 00:03:25 -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; 18 Sep 2012 00:03:25 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1TDlHe-000K87-99; Tue, 18 Sep 2012 00:03:22 +0000
Date: Tue, 18 Sep 2012 01:03:22 +0100
From: Tim Deegan <tim@xen.org>
To: Samuel Thibault <samuel.thibault@ens-lyon.org>,
	Matthew Fioravante <matthew.fioravante@jhuapl.edu>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Message-ID: <20120918000322.GB74365@ocelot.phlegethon.org>
References: <50579E7F.1050803@jhuapl.edu>
	<20120917222037.GM5110@type.youpi.perso.aquilenet.fr>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120917222037.GM5110@type.youpi.perso.aquilenet.fr>
User-Agent: Mutt/1.4.2.1i
Subject: Re: [Xen-devel] [PATCH mini-os enhancements for vtpm 7/8] add
	floating point and sse to mini-os
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At 00:20 +0200 on 18 Sep (1347927637), Samuel Thibault wrote:
> Matthew Fioravante, le Mon 17 Sep 2012 18:04:47 -0400, a =E9crit :
> > This patch adds floating point and sse support to mini-os by
> > initializing the floating point unit and the see unit during domain boo=
t up.
> > =

> > =

> > Signed of by: Matthew Fioravante matthew.fioravante@jhuapl.edu
> =

> I don't remember: does xen support optimizing out FPU context switch
> when a domain does not use the FPU? =


Yes, but using the FPU once at boot shouldn't interfere with that.

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 18 00:03:53 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Sep 2012 00:03:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDlHk-0004yZ-GG; Tue, 18 Sep 2012 00:03:28 +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 1TDlHj-0004yU-A1
	for xen-devel@lists.xensource.com; Tue, 18 Sep 2012 00:03:27 +0000
Received: from [85.158.138.51:38965] by server-6.bemta-3.messagelabs.com id
	E5/19-29694-E4AB7505; Tue, 18 Sep 2012 00:03:26 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-11.tower-174.messagelabs.com!1347926605!30921138!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12222 invoked from network); 18 Sep 2012 00:03:25 -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; 18 Sep 2012 00:03:25 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1TDlHe-000K87-99; Tue, 18 Sep 2012 00:03:22 +0000
Date: Tue, 18 Sep 2012 01:03:22 +0100
From: Tim Deegan <tim@xen.org>
To: Samuel Thibault <samuel.thibault@ens-lyon.org>,
	Matthew Fioravante <matthew.fioravante@jhuapl.edu>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Message-ID: <20120918000322.GB74365@ocelot.phlegethon.org>
References: <50579E7F.1050803@jhuapl.edu>
	<20120917222037.GM5110@type.youpi.perso.aquilenet.fr>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120917222037.GM5110@type.youpi.perso.aquilenet.fr>
User-Agent: Mutt/1.4.2.1i
Subject: Re: [Xen-devel] [PATCH mini-os enhancements for vtpm 7/8] add
	floating point and sse to mini-os
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At 00:20 +0200 on 18 Sep (1347927637), Samuel Thibault wrote:
> Matthew Fioravante, le Mon 17 Sep 2012 18:04:47 -0400, a =E9crit :
> > This patch adds floating point and sse support to mini-os by
> > initializing the floating point unit and the see unit during domain boo=
t up.
> > =

> > =

> > Signed of by: Matthew Fioravante matthew.fioravante@jhuapl.edu
> =

> I don't remember: does xen support optimizing out FPU context switch
> when a domain does not use the FPU? =


Yes, but using the FPU once at boot shouldn't interfere with that.

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 18 00:09:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Sep 2012 00:09:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDlMp-00058I-8d; Tue, 18 Sep 2012 00:08:43 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jmarcet@gmail.com>) id 1TDlMn-000588-KZ
	for xen-devel@lists.xen.org; Tue, 18 Sep 2012 00:08:41 +0000
Received: from [85.158.138.51:61580] by server-1.bemta-3.messagelabs.com id
	D2/A3-05884-88BB7505; Tue, 18 Sep 2012 00:08:40 +0000
X-Env-Sender: jmarcet@gmail.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1347926918!23002883!1
X-Originating-IP: [209.85.219.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32067 invoked from network); 18 Sep 2012 00:08:39 -0000
Received: from mail-oa0-f45.google.com (HELO mail-oa0-f45.google.com)
	(209.85.219.45)
	by server-12.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Sep 2012 00:08:39 -0000
Received: by oagn12 with SMTP id n12so6757923oag.32
	for <xen-devel@lists.xen.org>; Mon, 17 Sep 2012 17:08:38 -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=Zvha42reopzpHRU4QrlynBpCZuKsZ9T5mwBuYOEnyRA=;
	b=vVlJFVgVqhV1GCLsuopIFOi15WTuKnNShF2VBYWKGmEG5AtPk04hFA8qG7AYLfU10Y
	BHdK9u66SQZyNXEEQbw+a8yxNYZKbYOyw+arsR5TEy0REJqW0Zl5ZnVcaj348i3fi4Gc
	X/FVmDnKk98nxxutxtBfTgSHlMUDYNkBz5+Q493y7xRxvwXOacLSUGh/Ryn9xPJTZM10
	8VvlafQQy8FcJyzTGieTGSMMw/ZvfhkOQJqM5aBPRP2VQK4a/fDPYJaxj+1CzNAA3Xsg
	FHwEZAKM6TZTN8p4JZblLP8t+JUjeKEAG/f5dviCRogfK5MyTpKZNochu6mh1ynLzla0
	zF1w==
Received: by 10.60.22.66 with SMTP id b2mr2031397oef.116.1347926917788; Mon,
	17 Sep 2012 17:08:37 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.60.138.225 with HTTP; Mon, 17 Sep 2012 17:08:17 -0700 (PDT)
In-Reply-To: <CAAnFQG_VnZOYs3SJvO1Gc8P98kOW=6Wxc7tM_vEF8GiACgeVWg@mail.gmail.com>
References: <CAAnFQG9TZj=SxYK_jxqN=M6L40vL=AZu9EM2tbEffPhkL1s8FA@mail.gmail.com>
	<CACJDEmqdqA6CE9SgLL2QCNmQH1dOX0_4OHfJfzes+G6bEkQ7FA@mail.gmail.com>
	<CAAnFQG-8Fkunv6R8+GCLAH4yQCx4-Nn0zN_Ntsf0wsh5yXeihQ@mail.gmail.com>
	<20120917142851.GB14012@phenom.dumpdata.com>
	<CAAnFQG9bUUU8OBeKxYh=O3rRrnEPb4r1bPCr-EHWHuUS8shBhA@mail.gmail.com>
	<CAAnFQG_VnZOYs3SJvO1Gc8P98kOW=6Wxc7tM_vEF8GiACgeVWg@mail.gmail.com>
From: Javier Marcet <jmarcet@gmail.com>
Date: Tue, 18 Sep 2012 02:08:17 +0200
Message-ID: <CAAnFQG9s=Yh4od18q8xDOD7ukA4uurxCKWiLrULFkP66Zc+iPg@mail.gmail.com>
To: Konrad Rzeszutek Wilk <konrad@kernel.org>
Cc: Xen Devel Mailing list <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.2.0-rc4 issues with DVB tuner
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Sep 17, 2012 at 10:56 PM, Javier Marcet <jmarcet@gmail.com> wrote:

Still nothing. Not even enabling the debug options within the DVB
subsystem I get
anything which doesn't look perfectly normal, exactly like when it's
working fine.

I have just posted a message on the linux media mailing list looking
for some help
from the dvb maintainers.


-- 
Javier Marcet <jmarcet@gmail.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 18 00:09:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Sep 2012 00:09:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDlMp-00058I-8d; Tue, 18 Sep 2012 00:08:43 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jmarcet@gmail.com>) id 1TDlMn-000588-KZ
	for xen-devel@lists.xen.org; Tue, 18 Sep 2012 00:08:41 +0000
Received: from [85.158.138.51:61580] by server-1.bemta-3.messagelabs.com id
	D2/A3-05884-88BB7505; Tue, 18 Sep 2012 00:08:40 +0000
X-Env-Sender: jmarcet@gmail.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1347926918!23002883!1
X-Originating-IP: [209.85.219.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32067 invoked from network); 18 Sep 2012 00:08:39 -0000
Received: from mail-oa0-f45.google.com (HELO mail-oa0-f45.google.com)
	(209.85.219.45)
	by server-12.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Sep 2012 00:08:39 -0000
Received: by oagn12 with SMTP id n12so6757923oag.32
	for <xen-devel@lists.xen.org>; Mon, 17 Sep 2012 17:08:38 -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=Zvha42reopzpHRU4QrlynBpCZuKsZ9T5mwBuYOEnyRA=;
	b=vVlJFVgVqhV1GCLsuopIFOi15WTuKnNShF2VBYWKGmEG5AtPk04hFA8qG7AYLfU10Y
	BHdK9u66SQZyNXEEQbw+a8yxNYZKbYOyw+arsR5TEy0REJqW0Zl5ZnVcaj348i3fi4Gc
	X/FVmDnKk98nxxutxtBfTgSHlMUDYNkBz5+Q493y7xRxvwXOacLSUGh/Ryn9xPJTZM10
	8VvlafQQy8FcJyzTGieTGSMMw/ZvfhkOQJqM5aBPRP2VQK4a/fDPYJaxj+1CzNAA3Xsg
	FHwEZAKM6TZTN8p4JZblLP8t+JUjeKEAG/f5dviCRogfK5MyTpKZNochu6mh1ynLzla0
	zF1w==
Received: by 10.60.22.66 with SMTP id b2mr2031397oef.116.1347926917788; Mon,
	17 Sep 2012 17:08:37 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.60.138.225 with HTTP; Mon, 17 Sep 2012 17:08:17 -0700 (PDT)
In-Reply-To: <CAAnFQG_VnZOYs3SJvO1Gc8P98kOW=6Wxc7tM_vEF8GiACgeVWg@mail.gmail.com>
References: <CAAnFQG9TZj=SxYK_jxqN=M6L40vL=AZu9EM2tbEffPhkL1s8FA@mail.gmail.com>
	<CACJDEmqdqA6CE9SgLL2QCNmQH1dOX0_4OHfJfzes+G6bEkQ7FA@mail.gmail.com>
	<CAAnFQG-8Fkunv6R8+GCLAH4yQCx4-Nn0zN_Ntsf0wsh5yXeihQ@mail.gmail.com>
	<20120917142851.GB14012@phenom.dumpdata.com>
	<CAAnFQG9bUUU8OBeKxYh=O3rRrnEPb4r1bPCr-EHWHuUS8shBhA@mail.gmail.com>
	<CAAnFQG_VnZOYs3SJvO1Gc8P98kOW=6Wxc7tM_vEF8GiACgeVWg@mail.gmail.com>
From: Javier Marcet <jmarcet@gmail.com>
Date: Tue, 18 Sep 2012 02:08:17 +0200
Message-ID: <CAAnFQG9s=Yh4od18q8xDOD7ukA4uurxCKWiLrULFkP66Zc+iPg@mail.gmail.com>
To: Konrad Rzeszutek Wilk <konrad@kernel.org>
Cc: Xen Devel Mailing list <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.2.0-rc4 issues with DVB tuner
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Sep 17, 2012 at 10:56 PM, Javier Marcet <jmarcet@gmail.com> wrote:

Still nothing. Not even enabling the debug options within the DVB
subsystem I get
anything which doesn't look perfectly normal, exactly like when it's
working fine.

I have just posted a message on the linux media mailing list looking
for some help
from the dvb maintainers.


-- 
Javier Marcet <jmarcet@gmail.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 18 00:11:36 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Sep 2012 00:11: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 1TDlPK-0005F7-QY; Tue, 18 Sep 2012 00:11:18 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <samuel.thibault@ens-lyon.org>) id 1TDlPJ-0005Ep-Mq
	for xen-devel@lists.xensource.com; Tue, 18 Sep 2012 00:11:17 +0000
X-Env-Sender: samuel.thibault@ens-lyon.org
X-Msg-Ref: server-7.tower-27.messagelabs.com!1347927070!3687262!1
X-Originating-IP: [140.77.166.68]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14159 invoked from network); 18 Sep 2012 00:11:10 -0000
Received: from toccata.ens-lyon.fr (HELO toccata.ens-lyon.org) (140.77.166.68)
	by server-7.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 18 Sep 2012 00:11:10 -0000
Received: from localhost (localhost [127.0.0.1])
	by toccata.ens-lyon.org (Postfix) with ESMTP id E8E2684095;
	Tue, 18 Sep 2012 02:11:09 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at toccata.ens-lyon.org
Received: from toccata.ens-lyon.org ([127.0.0.1])
	by localhost (toccata.ens-lyon.org [127.0.0.1]) (amavisd-new,
	port 10024)
	with ESMTP id rrlAsvpaA9sK; Tue, 18 Sep 2012 02:11:09 +0200 (CEST)
Received: from type.ipv6 (youpi.is-a-geek.org [80.67.176.89])
	(using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits))
	(No client certificate requested)
	by toccata.ens-lyon.org (Postfix) with ESMTPSA id 4AF8984093;
	Tue, 18 Sep 2012 02:11:09 +0200 (CEST)
Received: from samy by type.ipv6 with local (Exim 4.80)
	(envelope-from <samuel.thibault@ens-lyon.org>)
	id 1TDlP5-0005kt-9u; Tue, 18 Sep 2012 02:11:03 +0200
Date: Tue, 18 Sep 2012 02:11:03 +0200
From: Samuel Thibault <samuel.thibault@ens-lyon.org>
To: Tim Deegan <tim@xen.org>
Message-ID: <20120918001103.GD5110@type.youpi.perso.aquilenet.fr>
Mail-Followup-To: Samuel Thibault <samuel.thibault@ens-lyon.org>,
	Tim Deegan <tim@xen.org>,
	Matthew Fioravante <matthew.fioravante@jhuapl.edu>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
References: <50579E7F.1050803@jhuapl.edu>
	<20120917222037.GM5110@type.youpi.perso.aquilenet.fr>
	<20120918000322.GB74365@ocelot.phlegethon.org>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120918000322.GB74365@ocelot.phlegethon.org>
User-Agent: Mutt/1.5.21+34 (58baf7c9f32f) (2010-12-30)
Cc: Matthew Fioravante <matthew.fioravante@jhuapl.edu>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH mini-os enhancements for vtpm 7/8] add
 floating point and sse to mini-os
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Tim Deegan, le Tue 18 Sep 2012 01:03:22 +0100, a =E9crit :
> At 00:20 +0200 on 18 Sep (1347927637), Samuel Thibault wrote:
> > Matthew Fioravante, le Mon 17 Sep 2012 18:04:47 -0400, a =E9crit :
> > > This patch adds floating point and sse support to mini-os by
> > > initializing the floating point unit and the see unit during domain b=
oot up.
> > > =

> > > =

> > > Signed of by: Matthew Fioravante matthew.fioravante@jhuapl.edu
> > =

> > I don't remember: does xen support optimizing out FPU context switch
> > when a domain does not use the FPU? =

> =

> Yes, but using the FPU once at boot shouldn't interfere with that.

Ah, right, the initialize context isn't restored until FPU is really
used.  Then it's all OK.

Samuel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 18 00:11:36 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Sep 2012 00:11: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 1TDlPK-0005F7-QY; Tue, 18 Sep 2012 00:11:18 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <samuel.thibault@ens-lyon.org>) id 1TDlPJ-0005Ep-Mq
	for xen-devel@lists.xensource.com; Tue, 18 Sep 2012 00:11:17 +0000
X-Env-Sender: samuel.thibault@ens-lyon.org
X-Msg-Ref: server-7.tower-27.messagelabs.com!1347927070!3687262!1
X-Originating-IP: [140.77.166.68]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14159 invoked from network); 18 Sep 2012 00:11:10 -0000
Received: from toccata.ens-lyon.fr (HELO toccata.ens-lyon.org) (140.77.166.68)
	by server-7.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 18 Sep 2012 00:11:10 -0000
Received: from localhost (localhost [127.0.0.1])
	by toccata.ens-lyon.org (Postfix) with ESMTP id E8E2684095;
	Tue, 18 Sep 2012 02:11:09 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at toccata.ens-lyon.org
Received: from toccata.ens-lyon.org ([127.0.0.1])
	by localhost (toccata.ens-lyon.org [127.0.0.1]) (amavisd-new,
	port 10024)
	with ESMTP id rrlAsvpaA9sK; Tue, 18 Sep 2012 02:11:09 +0200 (CEST)
Received: from type.ipv6 (youpi.is-a-geek.org [80.67.176.89])
	(using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits))
	(No client certificate requested)
	by toccata.ens-lyon.org (Postfix) with ESMTPSA id 4AF8984093;
	Tue, 18 Sep 2012 02:11:09 +0200 (CEST)
Received: from samy by type.ipv6 with local (Exim 4.80)
	(envelope-from <samuel.thibault@ens-lyon.org>)
	id 1TDlP5-0005kt-9u; Tue, 18 Sep 2012 02:11:03 +0200
Date: Tue, 18 Sep 2012 02:11:03 +0200
From: Samuel Thibault <samuel.thibault@ens-lyon.org>
To: Tim Deegan <tim@xen.org>
Message-ID: <20120918001103.GD5110@type.youpi.perso.aquilenet.fr>
Mail-Followup-To: Samuel Thibault <samuel.thibault@ens-lyon.org>,
	Tim Deegan <tim@xen.org>,
	Matthew Fioravante <matthew.fioravante@jhuapl.edu>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
References: <50579E7F.1050803@jhuapl.edu>
	<20120917222037.GM5110@type.youpi.perso.aquilenet.fr>
	<20120918000322.GB74365@ocelot.phlegethon.org>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120918000322.GB74365@ocelot.phlegethon.org>
User-Agent: Mutt/1.5.21+34 (58baf7c9f32f) (2010-12-30)
Cc: Matthew Fioravante <matthew.fioravante@jhuapl.edu>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH mini-os enhancements for vtpm 7/8] add
 floating point and sse to mini-os
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Tim Deegan, le Tue 18 Sep 2012 01:03:22 +0100, a =E9crit :
> At 00:20 +0200 on 18 Sep (1347927637), Samuel Thibault wrote:
> > Matthew Fioravante, le Mon 17 Sep 2012 18:04:47 -0400, a =E9crit :
> > > This patch adds floating point and sse support to mini-os by
> > > initializing the floating point unit and the see unit during domain b=
oot up.
> > > =

> > > =

> > > Signed of by: Matthew Fioravante matthew.fioravante@jhuapl.edu
> > =

> > I don't remember: does xen support optimizing out FPU context switch
> > when a domain does not use the FPU? =

> =

> Yes, but using the FPU once at boot shouldn't interfere with that.

Ah, right, the initialize context isn't restored until FPU is really
used.  Then it's all OK.

Samuel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 18 00:46:49 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Sep 2012 00:46: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 1TDlxI-0005WH-OS; Tue, 18 Sep 2012 00:46:24 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <yang.z.zhang@intel.com>) id 1TDlxH-0005WC-L6
	for xen-devel@lists.xen.org; Tue, 18 Sep 2012 00:46:23 +0000
Received: from [85.158.143.35:4117] by server-1.bemta-4.messagelabs.com id
	AC/BA-12504-F54C7505; Tue, 18 Sep 2012 00:46:23 +0000
X-Env-Sender: yang.z.zhang@intel.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1347929181!16218016!1
X-Originating-IP: [134.134.136.24]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjQgPT4gMzQzNDYz\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 769 invoked from network); 18 Sep 2012 00:46:22 -0000
Received: from mga09.intel.com (HELO mga09.intel.com) (134.134.136.24)
	by server-16.tower-21.messagelabs.com with SMTP;
	18 Sep 2012 00:46:22 -0000
Received: from orsmga001.jf.intel.com ([10.7.209.18])
	by orsmga102.jf.intel.com with ESMTP; 17 Sep 2012 17:46:10 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.80,439,1344236400"; d="scan'208";a="194149554"
Received: from fmsmsx108.amr.corp.intel.com ([10.19.9.228])
	by orsmga001.jf.intel.com with ESMTP; 17 Sep 2012 17:46:20 -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; Mon, 17 Sep 2012 17: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; Mon, 17 Sep 2012 17:46:19 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.239]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.175]) with mapi id
	14.01.0355.002; Tue, 18 Sep 2012 08:46:18 +0800
From: "Zhang, Yang Z" <yang.z.zhang@intel.com>
To: "Zhang, Yang Z" <yang.z.zhang@intel.com>, "Zhou, Chao"
	<chao.zhou@intel.com>, Ian Campbell <Ian.Campbell@citrix.com>, Stefano
	Stabellini <Stefano.Stabellini@eu.citrix.com>
Thread-Topic: [Xen-devel] error when pass through device to guest	with
	qemu-xen-dir-remote
Thread-Index: AQHNhACBIcVJkHzSNEKAhiEtlfNv7JeE2OOwgAqM3WA=
Date: Tue, 18 Sep 2012 00:46:17 +0000
Message-ID: <A9667DDFB95DB7438FA9D7D576C3D87E258EF6@SHSMSX101.ccr.corp.intel.com>
References: <A9667DDFB95DB7438FA9D7D576C3D87E203D54@SHSMSX101.ccr.corp.intel.com>
	<alpine.DEB.2.02.1208031122170.4645@kaball.uk.xensource.com>
	<1343990187.21372.48.camel@zakaz.uk.xensource.com>
	<40352EBA8B4DF841A9907B883F22B59B0FDBCE1E@SHSMSX102.ccr.corp.intel.com>
	<40352EBA8B4DF841A9907B883F22B59B0FDD25C7@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: Anthony Perard <anthony.perard@citrix.com>, "Shan,
	Haitao" <haitao.shan@intel.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] error when pass through device to
	guest	with	qemu-xen-dir-remote
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 wrote on 2012-09-11:
>  wrote on August 09, 2012 2:49 PM To: Ian Campbell; Stefano Stabellini:
>> I rebuild the upstream QEMU according to the wiki, but device static
>> assignment doesn't work, no lspci output in guest. However hotplug &
>> unplug works fine.
>> 
>> -----Original Message----- From: xen-devel-bounces@lists.xen.org
>> [mailto:xen-devel-bounces@lists.xen.org] On Behalf Of Ian Campbell Sent:
>> Friday, August 03, 2012 6:36 PM To: Stefano Stabellini Cc: Zhang, Yang
>> Z; Anthony Perard; xen-devel Subject: Re: [Xen-devel] error when pass
>> through device to guest with qemu-xen-dir-remote
>> 
>> On Fri, 2012-08-03 at 11:29 +0100, Stefano Stabellini wrote:
>>> On Fri, 3 Aug 2012, Zhang, Yang Z wrote:
>>>> When create guest with device assigned, it shows the error and the
>>>> device wasn't able to work inside guest: libxl: error:
>>>> libxl_qmp.c:288:qmp_handle_error_response: received an error message
>>>> from QMP server: Parameter 'driver' expects a driver name
>>>> 
>>>> It only fails with qemu-xen-dir-remote(Is this tree more close to
>>>> upstream qemu?). I don't see the error with the traditional Qemu. I
>>>> also tried qemu-upstream, but it fails when I try to enable pci
>>>> pass-through
>> for xen. I think Anthony's patch to add pci pass-through support for Xen is
>> accepted by qemu-upstream, am I right?
>>> 
>>> Yes, it was accepted, but it is present only in upstream QEMU (from
>>> git://git.qemu.org/qemu.git), not the tree we are currently using in
>>> xen-unstable for development
>>> (git://xenbits.xensource.com/qemu-upstream-unstable.git).
>>> Make sure you are using the right tree!
>> 
>> http://wiki.xen.org/wiki/QEMU_Upstream has some notes on how to use the
>> upstream qemu tree instead of our stable branch of upstream.
>> 
>>> 
>>> Anthony is currently on vacation and is going to be back in about a
>>> week.
>>> 
>>>> Another question:
>>>> Now I am trying to add some features (relevant to pass through device) to
>> Qemu, which tree should I use? Since traditional qemu is great
>> different from qemu-upstream, it is too old to develop patch base on
>> it. But besides the old one, I cannot find a working qemu.
>>> 
>>> You should use upstream QEMU, I am going to rebase our tree on that
>>> early on in the 4.3 release cycle.
> 
> Hi Anthony
> 
> I found the issue is caused by PV driver. Since RHEL6 integrated PV driver by
> default, when booting rhel6 as guest, it will load the PV driver and write the xen
> platform device to notify qemu to unplug all NICs including the pass through
> device. This definitely is wrong. We only need to unplug the emulator device, and
> leave pass through device.

Hi Anthony,

Any comments for this?

Best regards,
Yang



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 18 00:46:49 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Sep 2012 00:46: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 1TDlxI-0005WH-OS; Tue, 18 Sep 2012 00:46:24 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <yang.z.zhang@intel.com>) id 1TDlxH-0005WC-L6
	for xen-devel@lists.xen.org; Tue, 18 Sep 2012 00:46:23 +0000
Received: from [85.158.143.35:4117] by server-1.bemta-4.messagelabs.com id
	AC/BA-12504-F54C7505; Tue, 18 Sep 2012 00:46:23 +0000
X-Env-Sender: yang.z.zhang@intel.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1347929181!16218016!1
X-Originating-IP: [134.134.136.24]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjQgPT4gMzQzNDYz\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 769 invoked from network); 18 Sep 2012 00:46:22 -0000
Received: from mga09.intel.com (HELO mga09.intel.com) (134.134.136.24)
	by server-16.tower-21.messagelabs.com with SMTP;
	18 Sep 2012 00:46:22 -0000
Received: from orsmga001.jf.intel.com ([10.7.209.18])
	by orsmga102.jf.intel.com with ESMTP; 17 Sep 2012 17:46:10 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.80,439,1344236400"; d="scan'208";a="194149554"
Received: from fmsmsx108.amr.corp.intel.com ([10.19.9.228])
	by orsmga001.jf.intel.com with ESMTP; 17 Sep 2012 17:46:20 -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; Mon, 17 Sep 2012 17: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; Mon, 17 Sep 2012 17:46:19 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.239]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.175]) with mapi id
	14.01.0355.002; Tue, 18 Sep 2012 08:46:18 +0800
From: "Zhang, Yang Z" <yang.z.zhang@intel.com>
To: "Zhang, Yang Z" <yang.z.zhang@intel.com>, "Zhou, Chao"
	<chao.zhou@intel.com>, Ian Campbell <Ian.Campbell@citrix.com>, Stefano
	Stabellini <Stefano.Stabellini@eu.citrix.com>
Thread-Topic: [Xen-devel] error when pass through device to guest	with
	qemu-xen-dir-remote
Thread-Index: AQHNhACBIcVJkHzSNEKAhiEtlfNv7JeE2OOwgAqM3WA=
Date: Tue, 18 Sep 2012 00:46:17 +0000
Message-ID: <A9667DDFB95DB7438FA9D7D576C3D87E258EF6@SHSMSX101.ccr.corp.intel.com>
References: <A9667DDFB95DB7438FA9D7D576C3D87E203D54@SHSMSX101.ccr.corp.intel.com>
	<alpine.DEB.2.02.1208031122170.4645@kaball.uk.xensource.com>
	<1343990187.21372.48.camel@zakaz.uk.xensource.com>
	<40352EBA8B4DF841A9907B883F22B59B0FDBCE1E@SHSMSX102.ccr.corp.intel.com>
	<40352EBA8B4DF841A9907B883F22B59B0FDD25C7@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: Anthony Perard <anthony.perard@citrix.com>, "Shan,
	Haitao" <haitao.shan@intel.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] error when pass through device to
	guest	with	qemu-xen-dir-remote
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 wrote on 2012-09-11:
>  wrote on August 09, 2012 2:49 PM To: Ian Campbell; Stefano Stabellini:
>> I rebuild the upstream QEMU according to the wiki, but device static
>> assignment doesn't work, no lspci output in guest. However hotplug &
>> unplug works fine.
>> 
>> -----Original Message----- From: xen-devel-bounces@lists.xen.org
>> [mailto:xen-devel-bounces@lists.xen.org] On Behalf Of Ian Campbell Sent:
>> Friday, August 03, 2012 6:36 PM To: Stefano Stabellini Cc: Zhang, Yang
>> Z; Anthony Perard; xen-devel Subject: Re: [Xen-devel] error when pass
>> through device to guest with qemu-xen-dir-remote
>> 
>> On Fri, 2012-08-03 at 11:29 +0100, Stefano Stabellini wrote:
>>> On Fri, 3 Aug 2012, Zhang, Yang Z wrote:
>>>> When create guest with device assigned, it shows the error and the
>>>> device wasn't able to work inside guest: libxl: error:
>>>> libxl_qmp.c:288:qmp_handle_error_response: received an error message
>>>> from QMP server: Parameter 'driver' expects a driver name
>>>> 
>>>> It only fails with qemu-xen-dir-remote(Is this tree more close to
>>>> upstream qemu?). I don't see the error with the traditional Qemu. I
>>>> also tried qemu-upstream, but it fails when I try to enable pci
>>>> pass-through
>> for xen. I think Anthony's patch to add pci pass-through support for Xen is
>> accepted by qemu-upstream, am I right?
>>> 
>>> Yes, it was accepted, but it is present only in upstream QEMU (from
>>> git://git.qemu.org/qemu.git), not the tree we are currently using in
>>> xen-unstable for development
>>> (git://xenbits.xensource.com/qemu-upstream-unstable.git).
>>> Make sure you are using the right tree!
>> 
>> http://wiki.xen.org/wiki/QEMU_Upstream has some notes on how to use the
>> upstream qemu tree instead of our stable branch of upstream.
>> 
>>> 
>>> Anthony is currently on vacation and is going to be back in about a
>>> week.
>>> 
>>>> Another question:
>>>> Now I am trying to add some features (relevant to pass through device) to
>> Qemu, which tree should I use? Since traditional qemu is great
>> different from qemu-upstream, it is too old to develop patch base on
>> it. But besides the old one, I cannot find a working qemu.
>>> 
>>> You should use upstream QEMU, I am going to rebase our tree on that
>>> early on in the 4.3 release cycle.
> 
> Hi Anthony
> 
> I found the issue is caused by PV driver. Since RHEL6 integrated PV driver by
> default, when booting rhel6 as guest, it will load the PV driver and write the xen
> platform device to notify qemu to unplug all NICs including the pass through
> device. This definitely is wrong. We only need to unplug the emulator device, and
> leave pass through device.

Hi Anthony,

Any comments for this?

Best regards,
Yang



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 18 01:16:23 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Sep 2012 01:16: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 1TDmPq-00017h-9a; Tue, 18 Sep 2012 01:15:54 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <horms@verge.net.au>) id 1TDmPo-00017c-CT
	for xen-devel@lists.xensource.com; Tue, 18 Sep 2012 01:15:52 +0000
Received: from [85.158.143.99:43210] by server-1.bemta-4.messagelabs.com id
	80/95-12504-74BC7505; Tue, 18 Sep 2012 01:15:51 +0000
X-Env-Sender: horms@verge.net.au
X-Msg-Ref: server-4.tower-216.messagelabs.com!1347930949!25455950!1
X-Originating-IP: [202.4.237.240]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8780 invoked from network); 18 Sep 2012 01:15:50 -0000
Received: from kirsty.vergenet.net (HELO kirsty.vergenet.net) (202.4.237.240)
	by server-4.tower-216.messagelabs.com with SMTP;
	18 Sep 2012 01:15:50 -0000
Received: from ayumi.akashicho.tokyo.vergenet.net
	(p6117-ipbfp1901kobeminato.hyogo.ocn.ne.jp [114.172.117.117])
	by kirsty.vergenet.net (Postfix) with ESMTP id 0A00C25BE60;
	Tue, 18 Sep 2012 11:15:48 +1000 (EST)
Received: by ayumi.akashicho.tokyo.vergenet.net (Postfix, from userid 7100)
	id B39EFEDE5B0; Tue, 18 Sep 2012 10:15:43 +0900 (JST)
Date: Tue, 18 Sep 2012 10:15:43 +0900
From: Simon Horman <horms@verge.net.au>
To: Daniel Kiper <daniel.kiper@oracle.com>
Message-ID: <20120918011543.GA28305@verge.net.au>
References: <ff6ec2d4-fe0b-4c2e-8547-567e887355d3@default>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <ff6ec2d4-fe0b-4c2e-8547-567e887355d3@default>
Organisation: Horms Solutions Ltd.
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: olaf@aepfle.de, xen-devel@lists.xensource.com, konrad.wilk@oracle.com,
	andrew.cooper3@citrix.com, kexec@lists.infradead.org,
	ptesarik@suse.cz, jbeulich@suse.com
Subject: Re: [Xen-devel] [PATCH 0/7] kdump: Xen 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, Sep 14, 2012 at 06:01:53AM -0700, Daniel Kiper wrote:
> Hi Simon,
> 
> > do these relate to the changes that you were discussing
> > with Petr Tesarik in July?
> 
> No. They are independent of vmcoreinfo patch.

Thanks, all applied to the kexec-tools tree on kernel.org.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 18 01:16:23 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Sep 2012 01:16: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 1TDmPq-00017h-9a; Tue, 18 Sep 2012 01:15:54 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <horms@verge.net.au>) id 1TDmPo-00017c-CT
	for xen-devel@lists.xensource.com; Tue, 18 Sep 2012 01:15:52 +0000
Received: from [85.158.143.99:43210] by server-1.bemta-4.messagelabs.com id
	80/95-12504-74BC7505; Tue, 18 Sep 2012 01:15:51 +0000
X-Env-Sender: horms@verge.net.au
X-Msg-Ref: server-4.tower-216.messagelabs.com!1347930949!25455950!1
X-Originating-IP: [202.4.237.240]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8780 invoked from network); 18 Sep 2012 01:15:50 -0000
Received: from kirsty.vergenet.net (HELO kirsty.vergenet.net) (202.4.237.240)
	by server-4.tower-216.messagelabs.com with SMTP;
	18 Sep 2012 01:15:50 -0000
Received: from ayumi.akashicho.tokyo.vergenet.net
	(p6117-ipbfp1901kobeminato.hyogo.ocn.ne.jp [114.172.117.117])
	by kirsty.vergenet.net (Postfix) with ESMTP id 0A00C25BE60;
	Tue, 18 Sep 2012 11:15:48 +1000 (EST)
Received: by ayumi.akashicho.tokyo.vergenet.net (Postfix, from userid 7100)
	id B39EFEDE5B0; Tue, 18 Sep 2012 10:15:43 +0900 (JST)
Date: Tue, 18 Sep 2012 10:15:43 +0900
From: Simon Horman <horms@verge.net.au>
To: Daniel Kiper <daniel.kiper@oracle.com>
Message-ID: <20120918011543.GA28305@verge.net.au>
References: <ff6ec2d4-fe0b-4c2e-8547-567e887355d3@default>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <ff6ec2d4-fe0b-4c2e-8547-567e887355d3@default>
Organisation: Horms Solutions Ltd.
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: olaf@aepfle.de, xen-devel@lists.xensource.com, konrad.wilk@oracle.com,
	andrew.cooper3@citrix.com, kexec@lists.infradead.org,
	ptesarik@suse.cz, jbeulich@suse.com
Subject: Re: [Xen-devel] [PATCH 0/7] kdump: Xen 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, Sep 14, 2012 at 06:01:53AM -0700, Daniel Kiper wrote:
> Hi Simon,
> 
> > do these relate to the changes that you were discussing
> > with Petr Tesarik in July?
> 
> No. They are independent of vmcoreinfo patch.

Thanks, all applied to the kexec-tools tree on kernel.org.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 18 01:36:31 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Sep 2012 01:36:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDmjU-0001sV-E1; Tue, 18 Sep 2012 01:36: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 1TDmjS-0001sM-Vn
	for xen-devel@lists.xensource.com; Tue, 18 Sep 2012 01:36:11 +0000
Received: from [85.158.139.211:57242] by server-5.bemta-5.messagelabs.com id
	42/E0-30514-800D7505; Tue, 18 Sep 2012 01:36:08 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-206.messagelabs.com!1347932167!18932241!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDk2NzI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22154 invoked from network); 18 Sep 2012 01:36:07 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Sep 2012 01:36:07 -0000
X-IronPort-AV: E=Sophos;i="4.80,439,1344211200"; d="scan'208";a="14593023"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Sep 2012 01:36: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.279.1; Tue, 18 Sep 2012 02:36: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 1TDmjN-0007RN-Od;
	Tue, 18 Sep 2012 01:36:05 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1TDmjN-0004DQ-95;
	Tue, 18 Sep 2012 02:36:05 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-13800-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Tue, 18 Sep 2012 02:36:05 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.2-testing test] 13800: 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 13800 xen-4.2-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13800/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore            fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-i386-i386-xl-qemuu-winxpsp3  9 guest-localmigrate         fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             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-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  357bd4bb2950
baseline version:
 xen                  4027d31caeb0

------------------------------------------------------------
People who touched revisions under test:
------------------------------------------------------------

jobs:
 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                                 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                                     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-4.2-testing
+ revision=357bd4bb2950
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push xen-4.2-testing 357bd4bb2950
+ branch=xen-4.2-testing
+ revision=357bd4bb2950
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-4.2-testing
+ '[' xxen = xlinux ']'
+ linuxbranch=linux
+ : master
+ : tested/2.6.39.x
+ . ap-common
++ : xen@xenbits.xensource.com
++ : http://xenbits.xen.org/hg/staging/xen-4.2-testing.hg
++ : git://xenbits.xen.org/staging/qemu-xen-4.2-testing.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : xen@xenbits.xensource.com:git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.xen-4.2-testing
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-4.2-testing.git
++ : daily-cron.xen-4.2-testing
+ TREE_LINUX=xen@xenbits.xensource.com:git/linux-pvops.git
+ TREE_QEMU_UPSTREAM=xen@xenbits.xensource.com:git/qemu-upstream-4.2-testing.git
+ info_linux_tree xen-4.2-testing
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/xen-4.2-testing.hg
+ hg push -r 357bd4bb2950 ssh://xen@xenbits.xensource.com/HG/xen-4.2-testing.hg
pushing to ssh://xen@xenbits.xensource.com/HG/xen-4.2-testing.hg
searching for changes
remote: adding changesets
remote: adding manifests
remote: adding file changes
remote: added 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 Sep 18 01:36:31 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Sep 2012 01:36:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDmjU-0001sV-E1; Tue, 18 Sep 2012 01:36: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 1TDmjS-0001sM-Vn
	for xen-devel@lists.xensource.com; Tue, 18 Sep 2012 01:36:11 +0000
Received: from [85.158.139.211:57242] by server-5.bemta-5.messagelabs.com id
	42/E0-30514-800D7505; Tue, 18 Sep 2012 01:36:08 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-206.messagelabs.com!1347932167!18932241!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDk2NzI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22154 invoked from network); 18 Sep 2012 01:36:07 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Sep 2012 01:36:07 -0000
X-IronPort-AV: E=Sophos;i="4.80,439,1344211200"; d="scan'208";a="14593023"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Sep 2012 01:36: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.279.1; Tue, 18 Sep 2012 02:36: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 1TDmjN-0007RN-Od;
	Tue, 18 Sep 2012 01:36:05 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1TDmjN-0004DQ-95;
	Tue, 18 Sep 2012 02:36:05 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-13800-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Tue, 18 Sep 2012 02:36:05 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.2-testing test] 13800: 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 13800 xen-4.2-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13800/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore            fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-i386-i386-xl-qemuu-winxpsp3  9 guest-localmigrate         fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             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-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  357bd4bb2950
baseline version:
 xen                  4027d31caeb0

------------------------------------------------------------
People who touched revisions under test:
------------------------------------------------------------

jobs:
 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                                 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                                     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-4.2-testing
+ revision=357bd4bb2950
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push xen-4.2-testing 357bd4bb2950
+ branch=xen-4.2-testing
+ revision=357bd4bb2950
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-4.2-testing
+ '[' xxen = xlinux ']'
+ linuxbranch=linux
+ : master
+ : tested/2.6.39.x
+ . ap-common
++ : xen@xenbits.xensource.com
++ : http://xenbits.xen.org/hg/staging/xen-4.2-testing.hg
++ : git://xenbits.xen.org/staging/qemu-xen-4.2-testing.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : xen@xenbits.xensource.com:git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.xen-4.2-testing
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-4.2-testing.git
++ : daily-cron.xen-4.2-testing
+ TREE_LINUX=xen@xenbits.xensource.com:git/linux-pvops.git
+ TREE_QEMU_UPSTREAM=xen@xenbits.xensource.com:git/qemu-upstream-4.2-testing.git
+ info_linux_tree xen-4.2-testing
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/xen-4.2-testing.hg
+ hg push -r 357bd4bb2950 ssh://xen@xenbits.xensource.com/HG/xen-4.2-testing.hg
pushing to ssh://xen@xenbits.xensource.com/HG/xen-4.2-testing.hg
searching for changes
remote: adding changesets
remote: adding manifests
remote: adding file changes
remote: added 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 Sep 18 02:59:39 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Sep 2012 02: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 1TDo1l-0002hL-UG; Tue, 18 Sep 2012 02:59:09 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <robherring2@gmail.com>) id 1TDo1k-0002hD-1D
	for xen-devel@lists.xensource.com; Tue, 18 Sep 2012 02:59:08 +0000
Received: from [85.158.139.83:39504] by server-7.bemta-5.messagelabs.com id
	BF/93-19703-A73E7505; Tue, 18 Sep 2012 02:59:06 +0000
X-Env-Sender: robherring2@gmail.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1347937144!26418803!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-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23674 invoked from network); 18 Sep 2012 02:59:06 -0000
Received: from mail-ob0-f171.google.com (HELO mail-ob0-f171.google.com)
	(209.85.214.171)
	by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Sep 2012 02:59:06 -0000
Received: by obqv19 with SMTP id v19so13265995obq.30
	for <xen-devel@lists.xensource.com>;
	Mon, 17 Sep 2012 19:59:04 -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=GBFHrInyDNSHCmfG+MiLGK2ZlDEJANfyesTWwoZpLTU=;
	b=iquLRBm03XaRT2q6bXl1juETHb4hHk1Wfv5B0OowGicK8AthCs6fqeJMSWtslLOABO
	3HVlD8SyuUZmuAP7+gPjPqoN1L5LjZGMx5kYGeBxudocjYlVJrrgsz0caVFZQU7A9YCC
	tcopASRcIe7U34gT0meEzSqpnKOW6ci1qyzleVZ6zEoPkp09RmEu8lc5ldLwZgQ4z/96
	Pdu6B42mES6EvrX5Na3NueSOKyGKaSGnWLoby8BlnzgK9EPe3965wl97wPqSV35YAi6i
	YXljK+2fTSfAeDqhsxJZHwMtOKM5GyJH4QoGmIYhkh/hVez26uwS+hvY52HYACof/w9a
	FB/Q==
Received: by 10.60.1.106 with SMTP id 10mr14015459oel.84.1347937144562;
	Mon, 17 Sep 2012 19:59:04 -0700 (PDT)
Received: from [192.168.1.103] (65-36-73-129.dyn.grandenetworks.net.
	[65.36.73.129])
	by mx.google.com with ESMTPS id k3sm12955284obw.4.2012.09.17.19.59.02
	(version=SSLv3 cipher=OTHER); Mon, 17 Sep 2012 19:59:03 -0700 (PDT)
Message-ID: <5057E375.2050103@gmail.com>
Date: Mon, 17 Sep 2012 21:59:01 -0500
From: Rob Herring <robherring2@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:14.0) Gecko/20120714 Thunderbird/14.0
MIME-Version: 1.0
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.02.1209171215490.29232@kaball.uk.xensource.com>
	<1347903543-2135-6-git-send-email-stefano.stabellini@eu.citrix.com>
In-Reply-To: <1347903543-2135-6-git-send-email-stefano.stabellini@eu.citrix.com>
Cc: Dave Martin <dave.martin@linaro.org>, xen-devel@lists.xensource.com,
	linaro-dev@lists.linaro.org, Ian.Campbell@citrix.com,
	arnd@arndb.de, konrad.wilk@oracle.com,
	devicetree-discuss@lists.ozlabs.org, tim@xen.org,
	linux-kernel@vger.kernel.org,
	David Vrabel <david.vrabel@citrix.com>, linux@arm.linux.org.uk,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [Xen-devel] [PATCH v5 06/17] docs: Xen ARM DT bindings
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 09/17/2012 12:38 PM, Stefano Stabellini wrote:
> Add a doc to describe the Xen ARM device tree bindings
> 
> 
> Changes in v5:
> 
> - add a comment about the size of the grant table memory region;
> - add a comment about the required presence of a GIC node;
> - specify that the described properties are part of a top-level
> "hypervisor" node;
> - specify #address-cells and #size-cells for the example.
> 
> 
> Changes in v4:
> 
> - "xen,xen" should be last as it is less specific;
> - update reg property using 2 address-cells and 2 size-cells.
> 
> 
> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> CC: devicetree-discuss@lists.ozlabs.org
> CC: David Vrabel <david.vrabel@citrix.com>
> CC: Rob Herring <robherring2@gmail.com>
> CC: Dave Martin <dave.martin@linaro.org>

This is so minimal now and it doesn't seem to have any overlap with kvm, so:

Acked-by: Rob Herring <rob.herring@calxeda.com>

> ---
>  Documentation/devicetree/bindings/arm/xen.txt |   25 +++++++++++++++++++++++++
>  1 files changed, 25 insertions(+), 0 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/arm/xen.txt
> 
> diff --git a/Documentation/devicetree/bindings/arm/xen.txt b/Documentation/devicetree/bindings/arm/xen.txt
> new file mode 100644
> index 0000000..0f7b9c2
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/arm/xen.txt
> @@ -0,0 +1,25 @@
> +* Xen hypervisor device tree bindings
> +
> +Xen ARM virtual platforms shall have a top-level "hypervisor" node with
> +the following properties:
> +
> +- compatible:
> +	compatible = "xen,xen-<version>", "xen,xen";
> +  where <version> is the version of the Xen ABI of the platform.
> +
> +- reg: specifies the base physical address and size of a region in
> +  memory where the grant table should be mapped to, using an
> +  HYPERVISOR_memory_op hypercall. The memory region is large enough to map
> +  the whole grant table (it is larger or equal to gnttab_max_grant_frames()).
> +
> +- interrupts: the interrupt used by Xen to inject event notifications.
> +  A GIC node is also required.
> +
> +
> +Example (assuming #address-cells = <2> and #size-cells = <2>):
> +
> +hypervisor {
> +	compatible = "xen,xen-4.3", "xen,xen";
> +	reg = <0 0xb0000000 0 0x20000>;
> +	interrupts = <1 15 0xf08>;
> +};
> 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 18 02:59:39 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Sep 2012 02: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 1TDo1l-0002hL-UG; Tue, 18 Sep 2012 02:59:09 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <robherring2@gmail.com>) id 1TDo1k-0002hD-1D
	for xen-devel@lists.xensource.com; Tue, 18 Sep 2012 02:59:08 +0000
Received: from [85.158.139.83:39504] by server-7.bemta-5.messagelabs.com id
	BF/93-19703-A73E7505; Tue, 18 Sep 2012 02:59:06 +0000
X-Env-Sender: robherring2@gmail.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1347937144!26418803!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-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23674 invoked from network); 18 Sep 2012 02:59:06 -0000
Received: from mail-ob0-f171.google.com (HELO mail-ob0-f171.google.com)
	(209.85.214.171)
	by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Sep 2012 02:59:06 -0000
Received: by obqv19 with SMTP id v19so13265995obq.30
	for <xen-devel@lists.xensource.com>;
	Mon, 17 Sep 2012 19:59:04 -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=GBFHrInyDNSHCmfG+MiLGK2ZlDEJANfyesTWwoZpLTU=;
	b=iquLRBm03XaRT2q6bXl1juETHb4hHk1Wfv5B0OowGicK8AthCs6fqeJMSWtslLOABO
	3HVlD8SyuUZmuAP7+gPjPqoN1L5LjZGMx5kYGeBxudocjYlVJrrgsz0caVFZQU7A9YCC
	tcopASRcIe7U34gT0meEzSqpnKOW6ci1qyzleVZ6zEoPkp09RmEu8lc5ldLwZgQ4z/96
	Pdu6B42mES6EvrX5Na3NueSOKyGKaSGnWLoby8BlnzgK9EPe3965wl97wPqSV35YAi6i
	YXljK+2fTSfAeDqhsxJZHwMtOKM5GyJH4QoGmIYhkh/hVez26uwS+hvY52HYACof/w9a
	FB/Q==
Received: by 10.60.1.106 with SMTP id 10mr14015459oel.84.1347937144562;
	Mon, 17 Sep 2012 19:59:04 -0700 (PDT)
Received: from [192.168.1.103] (65-36-73-129.dyn.grandenetworks.net.
	[65.36.73.129])
	by mx.google.com with ESMTPS id k3sm12955284obw.4.2012.09.17.19.59.02
	(version=SSLv3 cipher=OTHER); Mon, 17 Sep 2012 19:59:03 -0700 (PDT)
Message-ID: <5057E375.2050103@gmail.com>
Date: Mon, 17 Sep 2012 21:59:01 -0500
From: Rob Herring <robherring2@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:14.0) Gecko/20120714 Thunderbird/14.0
MIME-Version: 1.0
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.02.1209171215490.29232@kaball.uk.xensource.com>
	<1347903543-2135-6-git-send-email-stefano.stabellini@eu.citrix.com>
In-Reply-To: <1347903543-2135-6-git-send-email-stefano.stabellini@eu.citrix.com>
Cc: Dave Martin <dave.martin@linaro.org>, xen-devel@lists.xensource.com,
	linaro-dev@lists.linaro.org, Ian.Campbell@citrix.com,
	arnd@arndb.de, konrad.wilk@oracle.com,
	devicetree-discuss@lists.ozlabs.org, tim@xen.org,
	linux-kernel@vger.kernel.org,
	David Vrabel <david.vrabel@citrix.com>, linux@arm.linux.org.uk,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [Xen-devel] [PATCH v5 06/17] docs: Xen ARM DT bindings
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 09/17/2012 12:38 PM, Stefano Stabellini wrote:
> Add a doc to describe the Xen ARM device tree bindings
> 
> 
> Changes in v5:
> 
> - add a comment about the size of the grant table memory region;
> - add a comment about the required presence of a GIC node;
> - specify that the described properties are part of a top-level
> "hypervisor" node;
> - specify #address-cells and #size-cells for the example.
> 
> 
> Changes in v4:
> 
> - "xen,xen" should be last as it is less specific;
> - update reg property using 2 address-cells and 2 size-cells.
> 
> 
> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> CC: devicetree-discuss@lists.ozlabs.org
> CC: David Vrabel <david.vrabel@citrix.com>
> CC: Rob Herring <robherring2@gmail.com>
> CC: Dave Martin <dave.martin@linaro.org>

This is so minimal now and it doesn't seem to have any overlap with kvm, so:

Acked-by: Rob Herring <rob.herring@calxeda.com>

> ---
>  Documentation/devicetree/bindings/arm/xen.txt |   25 +++++++++++++++++++++++++
>  1 files changed, 25 insertions(+), 0 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/arm/xen.txt
> 
> diff --git a/Documentation/devicetree/bindings/arm/xen.txt b/Documentation/devicetree/bindings/arm/xen.txt
> new file mode 100644
> index 0000000..0f7b9c2
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/arm/xen.txt
> @@ -0,0 +1,25 @@
> +* Xen hypervisor device tree bindings
> +
> +Xen ARM virtual platforms shall have a top-level "hypervisor" node with
> +the following properties:
> +
> +- compatible:
> +	compatible = "xen,xen-<version>", "xen,xen";
> +  where <version> is the version of the Xen ABI of the platform.
> +
> +- reg: specifies the base physical address and size of a region in
> +  memory where the grant table should be mapped to, using an
> +  HYPERVISOR_memory_op hypercall. The memory region is large enough to map
> +  the whole grant table (it is larger or equal to gnttab_max_grant_frames()).
> +
> +- interrupts: the interrupt used by Xen to inject event notifications.
> +  A GIC node is also required.
> +
> +
> +Example (assuming #address-cells = <2> and #size-cells = <2>):
> +
> +hypervisor {
> +	compatible = "xen,xen-4.3", "xen,xen";
> +	reg = <0 0xb0000000 0 0x20000>;
> +	interrupts = <1 15 0xf08>;
> +};
> 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 18 03:39:42 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Sep 2012 03:39:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDoeZ-00030s-Dq; Tue, 18 Sep 2012 03: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 1TDoeX-00030n-Pm
	for xen-devel@lists.xensource.com; Tue, 18 Sep 2012 03:39:14 +0000
Received: from [85.158.143.35:61350] by server-3.bemta-4.messagelabs.com id
	32/30-08232-1ECE7505; Tue, 18 Sep 2012 03:39:13 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1347939551!12873217!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDk2NzI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4725 invoked from network); 18 Sep 2012 03:39:12 -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;
	18 Sep 2012 03:39:12 -0000
X-IronPort-AV: E=Sophos;i="4.80,439,1344211200"; d="scan'208";a="14593760"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Sep 2012 03:39: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.279.1; Tue, 18 Sep 2012 04:39: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 1TDoeU-000852-Sr;
	Tue, 18 Sep 2012 03:39:10 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1TDoeU-0001RV-Rn;
	Tue, 18 Sep 2012 04:39:10 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-13801-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Tue, 18 Sep 2012 04:39:10 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13801: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 13801 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13801/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-win7-amd64 12 guest-localmigrate/x10  fail REGR. vs. 13799

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore            fail   like 13799
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail like 13799
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail like 13799

Tests which did not succeed, but are not blocking:
 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-win         16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  d1c3375c3f11
baseline version:
 xen                  3bf63fcfacd1

------------------------------------------------------------
People who touched revisions under test:
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  Christoph Egger <Christoph.Egger@amd.com>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Gang Wei <gang.wei@intel.com>
  Ian Campbell <ian.campbell@citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Jiongxi Li <jiongxi.li@intel.com>
  Keir Fraser <keir@xen.org>
  Steven Maresca <steve@zentific.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-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-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-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-amd64-amd64-xl-win                                      fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
changeset:   25925:d1c3375c3f11
tag:         tip
user:        Daniel De Graaf <dgdegra@tycho.nsa.gov>
date:        Mon Sep 17 21:12:21 2012 +0100
    
    xsm/flask: add domain relabel support
    
    This adds the ability to change a domain's XSM label after creation.
    The new label will be used for all future access checks; however,
    existing event channels and memory mappings will remain valid even if
    their creation would be denied by the new label.
    
    With appropriate security policy and hooks in the domain builder, this
    can be used to create domains that the domain builder does not have
    access to after building. It can also be used to allow a domain to
    drop privileges - for example, prior to launching a user-supplied
    kernel loaded by a pv-grub stubdom.
    
    Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   25924:383f0b427494
user:        Daniel De Graaf <dgdegra@tycho.nsa.gov>
date:        Mon Sep 17 21:10:39 2012 +0100
    
    xsm/flask: remove unneeded create_sid field
    
    This field was only used to populate the ssid of dom0, which can be
    handled explicitly in the domain creation hook. This also removes the
    unnecessary permission check on the creation of dom0.
    
    Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   25923:6804e9092670
user:        Daniel De Graaf <dgdegra@tycho.nsa.gov>
date:        Mon Sep 17 21:10:07 2012 +0100
    
    xsm/flask: remove inherited class attributes
    
    The ability to declare common permission blocks shared across multiple
    classes is not currently used in Xen. Currently, support for this
    feature is broken in the header generation scripts, and it is not
    expected that this feature will be used in the future, so remove the
    dead code.
    
    Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   25922:c2578dd96b83
user:        Jiongxi Li <jiongxi.li@intel.com>
date:        Mon Sep 17 21:06:02 2012 +0100
    
    xen: add virtual x2apic support for apicv
    
    basically to benefit from apicv, we need clear MSR bitmap for
    corresponding x2apic MSRs:
      0x800 - 0x8ff: no read intercept for apicv register virtualization
      TPR,EOI,SELF-IPI: no write intercept for virtual interrupt
        delivery
    
    Signed-off-by: Jiongxi Li <jiongxi.li@intel.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   25921:713b8849b11a
user:        Jiongxi Li <jiongxi.li@intel.com>
date:        Mon Sep 17 21:05:11 2012 +0100
    
    xen: enable Virtual-interrupt delivery
    
    Virtual interrupt delivery avoids Xen to inject vAPIC interrupts
    manually, which is fully taken care of by the hardware. This needs
    some special awareness into existing interrupr injection path:
    For pending interrupt from vLAPIC, instead of direct injection, we may
    need update architecture specific indicators before resuming to guest.
    Before returning to guest, RVI should be updated if any pending IRRs
    EOI exit bitmap controls whether an EOI write should cause VM-Exit. If
    set, a trap-like induced EOI VM-Exit is triggered. The approach here
    is to manipulate EOI exit bitmap based on value of TMR. Level
    triggered irq requires a hook in vLAPIC EOI write, so that vIOAPIC EOI
    is triggered and emulated
    
    Signed-off-by: Gang Wei <gang.wei@intel.com>
    Signed-off-by: Yang Zhang <yang.z.zhang@intel.com>
    Signed-off-by: Jiongxi Li <jiongxi.li@intel.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   25920:ec60de627945
user:        Jiongxi Li <jiongxi.li@intel.com>
date:        Mon Sep 17 21:04:08 2012 +0100
    
    xen: enable APIC-Register Virtualization
    
    Add APIC register virtualization support
     - APIC read doesn't cause VM-Exit
     - APIC write becomes trap-like
    
    Signed-off-by: Gang Wei <gang.wei@intel.com>
    Signed-off-by: Yang Zhang <yang.z.zhang@intel.com>
    Signed-off-by: Jiongxi Li <jiongxi.li@intel.com>
    
    
changeset:   25919:62de66cec48a
user:        Christoph Egger <Christoph.Egger@amd.com>
date:        Mon Sep 17 17:57:24 2012 +0100
    
    MCE: use new common mce handler on AMD CPUs
    
    Factor common machine check handler out of intel specific code
    and move it into common files.
    Replace old common mce handler with new one and use it on AMD CPUs.
    No functional changes on Intel side.
    While here fix some whitespace nits and comments.
    
    Signed-off-by: Christoph Egger <Christoph.Egger@amd.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   25918:7ab899e46347
user:        Steven Maresca <steve@zentific.com>
date:        Mon Sep 17 17:55:12 2012 +0100
    
    mem_event: fix regression affecting CR3, CR4 memory events
    
    This is a patch repairing a regression in code previously functional
    in 4.1.x. It appears that, during some refactoring work, calls to
    hvm_memory_event_cr3 and hvm_memory_event_cr4 were lost.
    
    These functions were originally called in mov_to_cr() of vmx.c, but
    the commit  http://xenbits.xen.org/hg/xen-unstable.hg/rev/1276926e3795
    abstracted the original code into generic functions up a level in
    hvm.c, dropping these calls in the process.
    
    Signed-off-by: Steven Maresca <steve@zentific.com>
    Acked-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
    Acked-by: Tim Deegan <tim@xen.org>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   25917:5ba70e030b47
user:        Andres Lagar-Cavilla <andres@lagarcavilla.org>
date:        Mon Sep 17 17:51:57 2012 +0100
    
    Extra check in grant table code for mapping of shared frame
    
    Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   25916:3bf63fcfacd1
user:        Ian Campbell <ian.campbell@citrix.com>
date:        Mon Sep 17 11:17:05 2012 +0100
    
    tools: drop ia64 only foreign structs from headers
    
    Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
    Acked-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    Committed-by: Ian Campbell <ian.campbell@citrix.com>
    
    
(qemu changes not included)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 18 03:39:42 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Sep 2012 03:39:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDoeZ-00030s-Dq; Tue, 18 Sep 2012 03: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 1TDoeX-00030n-Pm
	for xen-devel@lists.xensource.com; Tue, 18 Sep 2012 03:39:14 +0000
Received: from [85.158.143.35:61350] by server-3.bemta-4.messagelabs.com id
	32/30-08232-1ECE7505; Tue, 18 Sep 2012 03:39:13 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1347939551!12873217!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDk2NzI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4725 invoked from network); 18 Sep 2012 03:39:12 -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;
	18 Sep 2012 03:39:12 -0000
X-IronPort-AV: E=Sophos;i="4.80,439,1344211200"; d="scan'208";a="14593760"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Sep 2012 03:39: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.279.1; Tue, 18 Sep 2012 04:39: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 1TDoeU-000852-Sr;
	Tue, 18 Sep 2012 03:39:10 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1TDoeU-0001RV-Rn;
	Tue, 18 Sep 2012 04:39:10 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-13801-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Tue, 18 Sep 2012 04:39:10 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13801: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 13801 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13801/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-win7-amd64 12 guest-localmigrate/x10  fail REGR. vs. 13799

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore            fail   like 13799
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail like 13799
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail like 13799

Tests which did not succeed, but are not blocking:
 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-win         16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  d1c3375c3f11
baseline version:
 xen                  3bf63fcfacd1

------------------------------------------------------------
People who touched revisions under test:
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  Christoph Egger <Christoph.Egger@amd.com>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Gang Wei <gang.wei@intel.com>
  Ian Campbell <ian.campbell@citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Jiongxi Li <jiongxi.li@intel.com>
  Keir Fraser <keir@xen.org>
  Steven Maresca <steve@zentific.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-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-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-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-amd64-amd64-xl-win                                      fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
changeset:   25925:d1c3375c3f11
tag:         tip
user:        Daniel De Graaf <dgdegra@tycho.nsa.gov>
date:        Mon Sep 17 21:12:21 2012 +0100
    
    xsm/flask: add domain relabel support
    
    This adds the ability to change a domain's XSM label after creation.
    The new label will be used for all future access checks; however,
    existing event channels and memory mappings will remain valid even if
    their creation would be denied by the new label.
    
    With appropriate security policy and hooks in the domain builder, this
    can be used to create domains that the domain builder does not have
    access to after building. It can also be used to allow a domain to
    drop privileges - for example, prior to launching a user-supplied
    kernel loaded by a pv-grub stubdom.
    
    Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   25924:383f0b427494
user:        Daniel De Graaf <dgdegra@tycho.nsa.gov>
date:        Mon Sep 17 21:10:39 2012 +0100
    
    xsm/flask: remove unneeded create_sid field
    
    This field was only used to populate the ssid of dom0, which can be
    handled explicitly in the domain creation hook. This also removes the
    unnecessary permission check on the creation of dom0.
    
    Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   25923:6804e9092670
user:        Daniel De Graaf <dgdegra@tycho.nsa.gov>
date:        Mon Sep 17 21:10:07 2012 +0100
    
    xsm/flask: remove inherited class attributes
    
    The ability to declare common permission blocks shared across multiple
    classes is not currently used in Xen. Currently, support for this
    feature is broken in the header generation scripts, and it is not
    expected that this feature will be used in the future, so remove the
    dead code.
    
    Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   25922:c2578dd96b83
user:        Jiongxi Li <jiongxi.li@intel.com>
date:        Mon Sep 17 21:06:02 2012 +0100
    
    xen: add virtual x2apic support for apicv
    
    basically to benefit from apicv, we need clear MSR bitmap for
    corresponding x2apic MSRs:
      0x800 - 0x8ff: no read intercept for apicv register virtualization
      TPR,EOI,SELF-IPI: no write intercept for virtual interrupt
        delivery
    
    Signed-off-by: Jiongxi Li <jiongxi.li@intel.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   25921:713b8849b11a
user:        Jiongxi Li <jiongxi.li@intel.com>
date:        Mon Sep 17 21:05:11 2012 +0100
    
    xen: enable Virtual-interrupt delivery
    
    Virtual interrupt delivery avoids Xen to inject vAPIC interrupts
    manually, which is fully taken care of by the hardware. This needs
    some special awareness into existing interrupr injection path:
    For pending interrupt from vLAPIC, instead of direct injection, we may
    need update architecture specific indicators before resuming to guest.
    Before returning to guest, RVI should be updated if any pending IRRs
    EOI exit bitmap controls whether an EOI write should cause VM-Exit. If
    set, a trap-like induced EOI VM-Exit is triggered. The approach here
    is to manipulate EOI exit bitmap based on value of TMR. Level
    triggered irq requires a hook in vLAPIC EOI write, so that vIOAPIC EOI
    is triggered and emulated
    
    Signed-off-by: Gang Wei <gang.wei@intel.com>
    Signed-off-by: Yang Zhang <yang.z.zhang@intel.com>
    Signed-off-by: Jiongxi Li <jiongxi.li@intel.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   25920:ec60de627945
user:        Jiongxi Li <jiongxi.li@intel.com>
date:        Mon Sep 17 21:04:08 2012 +0100
    
    xen: enable APIC-Register Virtualization
    
    Add APIC register virtualization support
     - APIC read doesn't cause VM-Exit
     - APIC write becomes trap-like
    
    Signed-off-by: Gang Wei <gang.wei@intel.com>
    Signed-off-by: Yang Zhang <yang.z.zhang@intel.com>
    Signed-off-by: Jiongxi Li <jiongxi.li@intel.com>
    
    
changeset:   25919:62de66cec48a
user:        Christoph Egger <Christoph.Egger@amd.com>
date:        Mon Sep 17 17:57:24 2012 +0100
    
    MCE: use new common mce handler on AMD CPUs
    
    Factor common machine check handler out of intel specific code
    and move it into common files.
    Replace old common mce handler with new one and use it on AMD CPUs.
    No functional changes on Intel side.
    While here fix some whitespace nits and comments.
    
    Signed-off-by: Christoph Egger <Christoph.Egger@amd.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   25918:7ab899e46347
user:        Steven Maresca <steve@zentific.com>
date:        Mon Sep 17 17:55:12 2012 +0100
    
    mem_event: fix regression affecting CR3, CR4 memory events
    
    This is a patch repairing a regression in code previously functional
    in 4.1.x. It appears that, during some refactoring work, calls to
    hvm_memory_event_cr3 and hvm_memory_event_cr4 were lost.
    
    These functions were originally called in mov_to_cr() of vmx.c, but
    the commit  http://xenbits.xen.org/hg/xen-unstable.hg/rev/1276926e3795
    abstracted the original code into generic functions up a level in
    hvm.c, dropping these calls in the process.
    
    Signed-off-by: Steven Maresca <steve@zentific.com>
    Acked-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
    Acked-by: Tim Deegan <tim@xen.org>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   25917:5ba70e030b47
user:        Andres Lagar-Cavilla <andres@lagarcavilla.org>
date:        Mon Sep 17 17:51:57 2012 +0100
    
    Extra check in grant table code for mapping of shared frame
    
    Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   25916:3bf63fcfacd1
user:        Ian Campbell <ian.campbell@citrix.com>
date:        Mon Sep 17 11:17:05 2012 +0100
    
    tools: drop ia64 only foreign structs from headers
    
    Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
    Acked-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    Committed-by: Ian Campbell <ian.campbell@citrix.com>
    
    
(qemu changes not included)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 18 05:25:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Sep 2012 05: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 1TDqJD-0003fa-Hi; Tue, 18 Sep 2012 05:25:19 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ShengGe.Ding@amd.com>) id 1TDqJC-0003fV-OW
	for xen-devel@lists.xen.org; Tue, 18 Sep 2012 05:25:19 +0000
Received: from [85.158.143.99:30324] by server-3.bemta-4.messagelabs.com id
	BA/DC-08232-DB508505; Tue, 18 Sep 2012 05:25:17 +0000
X-Env-Sender: ShengGe.Ding@amd.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1347945915!23229300!1
X-Originating-IP: [216.32.180.14]
X-SpamReason: No, hits=0.0 required=7.0 tests=HTML_MESSAGE
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21905 invoked from network); 18 Sep 2012 05:25:16 -0000
Received: from va3ehsobe004.messaging.microsoft.com (HELO
	va3outboundpool.messaging.microsoft.com) (216.32.180.14)
	by server-11.tower-216.messagelabs.com with AES128-SHA encrypted SMTP;
	18 Sep 2012 05:25:16 -0000
Received: from mail55-va3-R.bigfish.com (10.7.14.236) by
	VA3EHSOBE009.bigfish.com (10.7.40.29) with Microsoft SMTP Server id
	14.1.225.23; Tue, 18 Sep 2012 05:25:14 +0000
Received: from mail55-va3 (localhost [127.0.0.1])	by mail55-va3-R.bigfish.com
	(Postfix) with ESMTP id 81C2326011E	for <xen-devel@lists.xen.org>;
	Tue, 18 Sep 2012 05:25:14 +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(zz9371Ic85fh103dKd6eah14ffId6f1izz1202h1d1ah1d2ahzz17326ah8275bh8275dhz2dh668h839hd25hf0ah107ah1288h12a5h12bdh1155h)
Received: from mail55-va3 (localhost.localdomain [127.0.0.1]) by mail55-va3
	(MessageSwitch) id 134794591354538_32221;
	Tue, 18 Sep 2012 05:25:13 +0000 (UTC)
Received: from VA3EHSMHS021.bigfish.com (unknown [10.7.14.243])	by
	mail55-va3.bigfish.com (Postfix) with ESMTP id 0813D4E0045	for
	<xen-devel@lists.xen.org>; Tue, 18 Sep 2012 05:25:13 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	VA3EHSMHS021.bigfish.com (10.7.99.31) with Microsoft SMTP Server id
	14.1.225.23; Tue, 18 Sep 2012 05:25:12 +0000
X-WSS-ID: 0MAJ5PZ-01-8UW-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 22C2110280BB	for <xen-devel@lists.xen.org>;
	Tue, 18 Sep 2012 00:25:10 -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;
	Tue, 18 Sep 2012 00:25:11 -0500
Received: from SCYBEXDAG04.amd.com (10.34.11.14) by sausexdag06.amd.com
	(163.181.55.7) with Microsoft SMTP Server (TLS) id 14.1.323.3;
	Tue, 18 Sep 2012 00:25:11 -0500
Received: from SCYBEXDAG03.amd.com ([169.254.3.3]) by SCYBEXDAG04.amd.com
	([169.254.4.88]) with mapi id 14.01.0323.003;
	Tue, 18 Sep 2012 13:25:08 +0800
From: "Ding, ShengGe" <ShengGe.Ding@amd.com>
To: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Thread-Topic: dom0 crashes while domain_pause in NPF handler
Thread-Index: Ac2Ug2IAr2Bf1LiASnmtzqjgJoXf9gA1xXGA
Date: Tue, 18 Sep 2012 05:25:07 +0000
Message-ID: <4DEE49724F3FA0438F8949D4497F451A05620D7B@SCYBEXDAG03.amd.com>
Accept-Language: zh-CN, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.237.74.37]
MIME-Version: 1.0
X-OriginatorOrg: amd.com
Subject: Re: [Xen-devel] dom0 crashes while domain_pause in NPF handler
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0217375389065048360=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============0217375389065048360==
Content-Language: en-US
Content-Type: multipart/alternative;
	boundary="_000_4DEE49724F3FA0438F8949D4497F451A05620D7BSCYBEXDAG03amdc_"

--_000_4DEE49724F3FA0438F8949D4497F451A05620D7BSCYBEXDAG03amdc_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi all,

I checked the domain_id again and I'm sure the paused domain is domU.
But the crashing seems like dom0 is paused, then whole system is killed and=
 reboots.

In Nested page fault handler, hypervisor get the VCPU via current macro and=
 this VCPU is bound to domU(the domain_id is so).
I'm really confused, how does dom0 crash if I pause domU here? Maybe this i=
s a logic issue of hypervisor, the same codes could run well in old version=
.

Best regards,
ShengGe

From: Ding, ShengGe
Sent: Monday, September 17, 2012 11:20 AM
To: 'xen-devel@lists.xen.org'
Subject: dom0 crashes while domain_pause in NPF handler

Hi all,

I ran into trouble on nested page fault handling.

I removed p2m entries of passthrough type via clear_mmio_p2m_entry() to unm=
ap mmio space of passthough HW.
Then the nested page fault of physical mmio space can be trapped and the do=
mU can be paused here via domain_pause().

These are fine in xen-4.1.1 with debian patch(ubuntu).
But while I try to port them to xen-unstable version, the dom0 crashes.

The paused domain is absolutely domU. Is there any new restriction in NPF h=
andler in unstable version?

Thanks!
ShengGe

--_000_4DEE49724F3FA0438F8949D4497F451A05620D7BSCYBEXDAG03amdc_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:=
//www.w3.org/TR/REC-html40">
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"=
>
<meta name=3D"Generator" content=3D"Microsoft Word 12 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
	{font-family:SimSun;
	panose-1:2 1 6 0 3 1 1 1 1 1;}
@font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
	{font-family:Consolas;
	panose-1:2 11 6 9 2 2 4 3 2 4;}
@font-face
	{font-family:SimSun;
	panose-1:2 1 6 0 3 1 1 1 1 1;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal;
	font-family:"Calibri","sans-serif";
	color:windowtext;}
span.EmailStyle18
	{mso-style-type:personal-reply;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-size:10.0pt;}
@page WordSection1
	{size:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;}
div.WordSection1
	{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang=3D"EN-US" link=3D"blue" vlink=3D"purple">
<div class=3D"WordSection1">
<p class=3D"MsoNormal"><span style=3D"color:#1F497D">Hi all,<o:p></o:p></sp=
an></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D"><o:p>&nbsp;</o:p></spa=
n></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D">I checked the domain_i=
d again and I&#8217;m sure the paused domain is domU.<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D">But the crashing seems=
 like dom0 is paused, then whole system is killed and reboots.<o:p></o:p></=
span></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D"><o:p>&nbsp;</o:p></spa=
n></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D">In Nested page fault h=
andler, hypervisor get the VCPU via
</span><span style=3D"font-family:Consolas;color:#1F497D">current</span><sp=
an style=3D"color:#1F497D"> macro and this VCPU is bound to domU(the domain=
_id is so).<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D">I&#8217;m really confu=
sed, how does dom0 crash if I pause domU here? Maybe this is a logic issue =
of hypervisor, the same codes could run well in old version.<o:p></o:p></sp=
an></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D"><o:p>&nbsp;</o:p></spa=
n></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D">Best regards,<o:p></o:=
p></span></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D">ShengGe<o:p></o:p></sp=
an></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D"><o:p>&nbsp;</o:p></spa=
n></p>
<div>
<div style=3D"border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in =
0in 0in">
<p class=3D"MsoNormal"><b><span style=3D"font-size:10.0pt;font-family:&quot=
;Tahoma&quot;,&quot;sans-serif&quot;">From:</span></b><span style=3D"font-s=
ize:10.0pt;font-family:&quot;Tahoma&quot;,&quot;sans-serif&quot;"> Ding, Sh=
engGe
<br>
<b>Sent:</b> Monday, September 17, 2012 11:20 AM<br>
<b>To:</b> 'xen-devel@lists.xen.org'<br>
<b>Subject:</b> dom0 crashes while domain_pause in NPF handler<o:p></o:p></=
span></p>
</div>
</div>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal">Hi all,<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal">I ran into trouble on nested page fault handling.<o:=
p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal">I removed p2m entries of passthrough type via clear_=
mmio_p2m_entry() to unmap mmio space of passthough HW.<o:p></o:p></p>
<p class=3D"MsoNormal">Then the nested page fault of physical mmio space ca=
n be trapped and the domU can be paused here via domain_pause().<o:p></o:p>=
</p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal">These are fine in xen-4.1.1 with debian patch(ubuntu=
). <o:p>
</o:p></p>
<p class=3D"MsoNormal">But while I try to port them to xen-unstable version=
, the dom0 crashes.<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal">The paused domain is absolutely domU. Is there any n=
ew restriction in NPF handler in unstable version?<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal">Thanks!<o:p></o:p></p>
<p class=3D"MsoNormal">ShengGe<o:p></o:p></p>
</div>
</body>
</html>

--_000_4DEE49724F3FA0438F8949D4497F451A05620D7BSCYBEXDAG03amdc_--


--===============0217375389065048360==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============0217375389065048360==--


From xen-devel-bounces@lists.xen.org Tue Sep 18 05:25:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Sep 2012 05: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 1TDqJD-0003fa-Hi; Tue, 18 Sep 2012 05:25:19 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ShengGe.Ding@amd.com>) id 1TDqJC-0003fV-OW
	for xen-devel@lists.xen.org; Tue, 18 Sep 2012 05:25:19 +0000
Received: from [85.158.143.99:30324] by server-3.bemta-4.messagelabs.com id
	BA/DC-08232-DB508505; Tue, 18 Sep 2012 05:25:17 +0000
X-Env-Sender: ShengGe.Ding@amd.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1347945915!23229300!1
X-Originating-IP: [216.32.180.14]
X-SpamReason: No, hits=0.0 required=7.0 tests=HTML_MESSAGE
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21905 invoked from network); 18 Sep 2012 05:25:16 -0000
Received: from va3ehsobe004.messaging.microsoft.com (HELO
	va3outboundpool.messaging.microsoft.com) (216.32.180.14)
	by server-11.tower-216.messagelabs.com with AES128-SHA encrypted SMTP;
	18 Sep 2012 05:25:16 -0000
Received: from mail55-va3-R.bigfish.com (10.7.14.236) by
	VA3EHSOBE009.bigfish.com (10.7.40.29) with Microsoft SMTP Server id
	14.1.225.23; Tue, 18 Sep 2012 05:25:14 +0000
Received: from mail55-va3 (localhost [127.0.0.1])	by mail55-va3-R.bigfish.com
	(Postfix) with ESMTP id 81C2326011E	for <xen-devel@lists.xen.org>;
	Tue, 18 Sep 2012 05:25:14 +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(zz9371Ic85fh103dKd6eah14ffId6f1izz1202h1d1ah1d2ahzz17326ah8275bh8275dhz2dh668h839hd25hf0ah107ah1288h12a5h12bdh1155h)
Received: from mail55-va3 (localhost.localdomain [127.0.0.1]) by mail55-va3
	(MessageSwitch) id 134794591354538_32221;
	Tue, 18 Sep 2012 05:25:13 +0000 (UTC)
Received: from VA3EHSMHS021.bigfish.com (unknown [10.7.14.243])	by
	mail55-va3.bigfish.com (Postfix) with ESMTP id 0813D4E0045	for
	<xen-devel@lists.xen.org>; Tue, 18 Sep 2012 05:25:13 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	VA3EHSMHS021.bigfish.com (10.7.99.31) with Microsoft SMTP Server id
	14.1.225.23; Tue, 18 Sep 2012 05:25:12 +0000
X-WSS-ID: 0MAJ5PZ-01-8UW-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 22C2110280BB	for <xen-devel@lists.xen.org>;
	Tue, 18 Sep 2012 00:25:10 -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;
	Tue, 18 Sep 2012 00:25:11 -0500
Received: from SCYBEXDAG04.amd.com (10.34.11.14) by sausexdag06.amd.com
	(163.181.55.7) with Microsoft SMTP Server (TLS) id 14.1.323.3;
	Tue, 18 Sep 2012 00:25:11 -0500
Received: from SCYBEXDAG03.amd.com ([169.254.3.3]) by SCYBEXDAG04.amd.com
	([169.254.4.88]) with mapi id 14.01.0323.003;
	Tue, 18 Sep 2012 13:25:08 +0800
From: "Ding, ShengGe" <ShengGe.Ding@amd.com>
To: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Thread-Topic: dom0 crashes while domain_pause in NPF handler
Thread-Index: Ac2Ug2IAr2Bf1LiASnmtzqjgJoXf9gA1xXGA
Date: Tue, 18 Sep 2012 05:25:07 +0000
Message-ID: <4DEE49724F3FA0438F8949D4497F451A05620D7B@SCYBEXDAG03.amd.com>
Accept-Language: zh-CN, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.237.74.37]
MIME-Version: 1.0
X-OriginatorOrg: amd.com
Subject: Re: [Xen-devel] dom0 crashes while domain_pause in NPF handler
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0217375389065048360=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============0217375389065048360==
Content-Language: en-US
Content-Type: multipart/alternative;
	boundary="_000_4DEE49724F3FA0438F8949D4497F451A05620D7BSCYBEXDAG03amdc_"

--_000_4DEE49724F3FA0438F8949D4497F451A05620D7BSCYBEXDAG03amdc_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi all,

I checked the domain_id again and I'm sure the paused domain is domU.
But the crashing seems like dom0 is paused, then whole system is killed and=
 reboots.

In Nested page fault handler, hypervisor get the VCPU via current macro and=
 this VCPU is bound to domU(the domain_id is so).
I'm really confused, how does dom0 crash if I pause domU here? Maybe this i=
s a logic issue of hypervisor, the same codes could run well in old version=
.

Best regards,
ShengGe

From: Ding, ShengGe
Sent: Monday, September 17, 2012 11:20 AM
To: 'xen-devel@lists.xen.org'
Subject: dom0 crashes while domain_pause in NPF handler

Hi all,

I ran into trouble on nested page fault handling.

I removed p2m entries of passthrough type via clear_mmio_p2m_entry() to unm=
ap mmio space of passthough HW.
Then the nested page fault of physical mmio space can be trapped and the do=
mU can be paused here via domain_pause().

These are fine in xen-4.1.1 with debian patch(ubuntu).
But while I try to port them to xen-unstable version, the dom0 crashes.

The paused domain is absolutely domU. Is there any new restriction in NPF h=
andler in unstable version?

Thanks!
ShengGe

--_000_4DEE49724F3FA0438F8949D4497F451A05620D7BSCYBEXDAG03amdc_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:=
//www.w3.org/TR/REC-html40">
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"=
>
<meta name=3D"Generator" content=3D"Microsoft Word 12 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
	{font-family:SimSun;
	panose-1:2 1 6 0 3 1 1 1 1 1;}
@font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
	{font-family:Consolas;
	panose-1:2 11 6 9 2 2 4 3 2 4;}
@font-face
	{font-family:SimSun;
	panose-1:2 1 6 0 3 1 1 1 1 1;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal;
	font-family:"Calibri","sans-serif";
	color:windowtext;}
span.EmailStyle18
	{mso-style-type:personal-reply;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-size:10.0pt;}
@page WordSection1
	{size:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;}
div.WordSection1
	{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang=3D"EN-US" link=3D"blue" vlink=3D"purple">
<div class=3D"WordSection1">
<p class=3D"MsoNormal"><span style=3D"color:#1F497D">Hi all,<o:p></o:p></sp=
an></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D"><o:p>&nbsp;</o:p></spa=
n></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D">I checked the domain_i=
d again and I&#8217;m sure the paused domain is domU.<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D">But the crashing seems=
 like dom0 is paused, then whole system is killed and reboots.<o:p></o:p></=
span></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D"><o:p>&nbsp;</o:p></spa=
n></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D">In Nested page fault h=
andler, hypervisor get the VCPU via
</span><span style=3D"font-family:Consolas;color:#1F497D">current</span><sp=
an style=3D"color:#1F497D"> macro and this VCPU is bound to domU(the domain=
_id is so).<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D">I&#8217;m really confu=
sed, how does dom0 crash if I pause domU here? Maybe this is a logic issue =
of hypervisor, the same codes could run well in old version.<o:p></o:p></sp=
an></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D"><o:p>&nbsp;</o:p></spa=
n></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D">Best regards,<o:p></o:=
p></span></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D">ShengGe<o:p></o:p></sp=
an></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D"><o:p>&nbsp;</o:p></spa=
n></p>
<div>
<div style=3D"border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in =
0in 0in">
<p class=3D"MsoNormal"><b><span style=3D"font-size:10.0pt;font-family:&quot=
;Tahoma&quot;,&quot;sans-serif&quot;">From:</span></b><span style=3D"font-s=
ize:10.0pt;font-family:&quot;Tahoma&quot;,&quot;sans-serif&quot;"> Ding, Sh=
engGe
<br>
<b>Sent:</b> Monday, September 17, 2012 11:20 AM<br>
<b>To:</b> 'xen-devel@lists.xen.org'<br>
<b>Subject:</b> dom0 crashes while domain_pause in NPF handler<o:p></o:p></=
span></p>
</div>
</div>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal">Hi all,<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal">I ran into trouble on nested page fault handling.<o:=
p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal">I removed p2m entries of passthrough type via clear_=
mmio_p2m_entry() to unmap mmio space of passthough HW.<o:p></o:p></p>
<p class=3D"MsoNormal">Then the nested page fault of physical mmio space ca=
n be trapped and the domU can be paused here via domain_pause().<o:p></o:p>=
</p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal">These are fine in xen-4.1.1 with debian patch(ubuntu=
). <o:p>
</o:p></p>
<p class=3D"MsoNormal">But while I try to port them to xen-unstable version=
, the dom0 crashes.<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal">The paused domain is absolutely domU. Is there any n=
ew restriction in NPF handler in unstable version?<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal">Thanks!<o:p></o:p></p>
<p class=3D"MsoNormal">ShengGe<o:p></o:p></p>
</div>
</body>
</html>

--_000_4DEE49724F3FA0438F8949D4497F451A05620D7BSCYBEXDAG03amdc_--


--===============0217375389065048360==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============0217375389065048360==--


From xen-devel-bounces@lists.xen.org Tue Sep 18 07:21:55 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Sep 2012 07: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 1TDs7X-0004fK-H2; Tue, 18 Sep 2012 07:21:23 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1TDs7V-0004fF-O8
	for xen-devel@lists.xensource.com; Tue, 18 Sep 2012 07:21:21 +0000
Received: from [85.158.137.99:55862] by server-11.bemta-3.messagelabs.com id
	83/9B-30250-0F028505; Tue, 18 Sep 2012 07:21:20 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-217.messagelabs.com!1347952879!12962336!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDk2NzI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3458 invoked from network); 18 Sep 2012 07:21:20 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Sep 2012 07:21:20 -0000
X-IronPort-AV: E=Sophos;i="4.80,441,1344211200"; d="scan'208";a="14596153"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Sep 2012 07:21: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.279.1;
	Tue, 18 Sep 2012 08:21:19 +0100
Message-ID: <1347952878.25803.76.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
Date: Tue, 18 Sep 2012 08:21:18 +0100
In-Reply-To: <50579E7F.1050803@jhuapl.edu>
References: <50579E7F.1050803@jhuapl.edu>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Samuel Thibault <samuel.thibault@ens-lyon.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH mini-os enhancements for vtpm 7/8] add
 floating point and sse to mini-os
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2012-09-17 at 23:04 +0100, Matthew Fioravante wrote:
> This patch adds floating point and sse support to mini-os by
> initializing the floating point unit and the see unit during domain boot up.
> 
> 
> Signed of by: Matthew Fioravante matthew.fioravante@jhuapl.edu
> 
> diff --git a/extras/mini-os/arch/x86/setup.c
> b/extras/mini-os/arch/x86/setup.c
> --- a/extras/mini-os/arch/x86/setup.c
> +++ b/extras/mini-os/arch/x86/setup.c
> @@ -74,9 +74,28 @@ shared_info_t *map_shared_info(unsigned long pa)
>      return (shared_info_t *)shared_info;
>  }
>  
> +static inline void fpu_init(void) {
> +    asm volatile("fninit");
> +}
> +
> +#ifdef __SSE__

How and when is this symbol defined?

> +static inline void sse_init(void) {
> +    unsigned long status = 0x1f80;
> +    asm volatile("ldmxcsr %0" : : "m" (status));
> +}
> +#else
> +#define sse_init()
> +#endif
> +
>  void
>  arch_init(start_info_t *si)
>  {
> +    /*Initialize floating point unit */
> +        fpu_init();
> +
> +        /* Initialize SSE */
> +        sse_init();

The indentation here is a bit suspect.

> +
>      /* Copy the start_info struct to a globally-accessible area. */
>      /* WARN: don't do printk before here, it uses information from
>         shared_info. Use xprintk instead. */
> @@ -99,6 +118,7 @@ arch_init(start_info_t *si)
>          (unsigned long)failsafe_callback, 0);
>  #endif
>  
> +
>  }
>  
>  void
> 
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 18 07:21:55 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Sep 2012 07: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 1TDs7X-0004fK-H2; Tue, 18 Sep 2012 07:21:23 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1TDs7V-0004fF-O8
	for xen-devel@lists.xensource.com; Tue, 18 Sep 2012 07:21:21 +0000
Received: from [85.158.137.99:55862] by server-11.bemta-3.messagelabs.com id
	83/9B-30250-0F028505; Tue, 18 Sep 2012 07:21:20 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-217.messagelabs.com!1347952879!12962336!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDk2NzI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3458 invoked from network); 18 Sep 2012 07:21:20 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Sep 2012 07:21:20 -0000
X-IronPort-AV: E=Sophos;i="4.80,441,1344211200"; d="scan'208";a="14596153"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Sep 2012 07:21: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.279.1;
	Tue, 18 Sep 2012 08:21:19 +0100
Message-ID: <1347952878.25803.76.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
Date: Tue, 18 Sep 2012 08:21:18 +0100
In-Reply-To: <50579E7F.1050803@jhuapl.edu>
References: <50579E7F.1050803@jhuapl.edu>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Samuel Thibault <samuel.thibault@ens-lyon.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH mini-os enhancements for vtpm 7/8] add
 floating point and sse to mini-os
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2012-09-17 at 23:04 +0100, Matthew Fioravante wrote:
> This patch adds floating point and sse support to mini-os by
> initializing the floating point unit and the see unit during domain boot up.
> 
> 
> Signed of by: Matthew Fioravante matthew.fioravante@jhuapl.edu
> 
> diff --git a/extras/mini-os/arch/x86/setup.c
> b/extras/mini-os/arch/x86/setup.c
> --- a/extras/mini-os/arch/x86/setup.c
> +++ b/extras/mini-os/arch/x86/setup.c
> @@ -74,9 +74,28 @@ shared_info_t *map_shared_info(unsigned long pa)
>      return (shared_info_t *)shared_info;
>  }
>  
> +static inline void fpu_init(void) {
> +    asm volatile("fninit");
> +}
> +
> +#ifdef __SSE__

How and when is this symbol defined?

> +static inline void sse_init(void) {
> +    unsigned long status = 0x1f80;
> +    asm volatile("ldmxcsr %0" : : "m" (status));
> +}
> +#else
> +#define sse_init()
> +#endif
> +
>  void
>  arch_init(start_info_t *si)
>  {
> +    /*Initialize floating point unit */
> +        fpu_init();
> +
> +        /* Initialize SSE */
> +        sse_init();

The indentation here is a bit suspect.

> +
>      /* Copy the start_info struct to a globally-accessible area. */
>      /* WARN: don't do printk before here, it uses information from
>         shared_info. Use xprintk instead. */
> @@ -99,6 +118,7 @@ arch_init(start_info_t *si)
>          (unsigned long)failsafe_callback, 0);
>  #endif
>  
> +
>  }
>  
>  void
> 
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 18 07:22:30 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Sep 2012 07: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 1TDs8B-0004hM-Ug; Tue, 18 Sep 2012 07:22: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 1TDs8A-0004h9-JK
	for xen-devel@lists.xen.org; Tue, 18 Sep 2012 07:22:02 +0000
Received: from [85.158.143.35:64740] by server-2.bemta-4.messagelabs.com id
	A9/7A-06610-91128505; Tue, 18 Sep 2012 07:22:01 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1347952920!14140568!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2354 invoked from network); 18 Sep 2012 07:22:01 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-3.tower-21.messagelabs.com with SMTP;
	18 Sep 2012 07:22:01 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 18 Sep 2012 08:22:00 +0100
Message-Id: <50583D35020000780009BFB0@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 18 Sep 2012 08:21:57 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Daniel De Graaf" <dgdegra@tycho.nsa.gov>
References: <1347895425-17959-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1347895425-17959-20-git-send-email-dgdegra@tycho.nsa.gov>
In-Reply-To: <1347895425-17959-20-git-send-email-dgdegra@tycho.nsa.gov>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Tim Deegan <tim@xen.org>, keir@xen.org, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 19/23] arch/x86: check remote MMIO remap
 permissions
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 17.09.12 at 17:23, Daniel De Graaf <dgdegra@tycho.nsa.gov> wrote:
> --- a/xen/arch/x86/mm.c
> +++ b/xen/arch/x86/mm.c
> @@ -754,6 +754,18 @@ get_page_from_l1e(
>              return -EINVAL;
>          }
>  
> +        if ( pg_owner != curr->domain &&
> +             !iomem_access_permitted(curr->domain, mfn, mfn) )

On a second (or third?) look, I don't think this is right - the current
domain doesn't matter here at all. What does matter is who's page
tables the mapping is to be put in (i.e. l1e_owner), which of course
in certain cases ends up being the current domain.

Jan

> +        {
> +            if ( mfn != (PADDR_MASK >> PAGE_SHIFT) ) /* INVALID_MFN? */
> +            {
> +                MEM_LOG("Domain %u attempted to map I/O space %08lx in domain %u",
> +                        curr->domain->domain_id, mfn, pg_owner->domain_id);
> +                return -EPERM;
> +            }
> +            return -EINVAL;
> +        }
> +
>          if ( !(l1f & _PAGE_RW) ||
>               !rangeset_contains_singleton(mmio_ro_ranges, mfn) )
>              return 0;
> -- 
> 1.7.11.4




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 18 07:22:30 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Sep 2012 07: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 1TDs8B-0004hM-Ug; Tue, 18 Sep 2012 07:22: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 1TDs8A-0004h9-JK
	for xen-devel@lists.xen.org; Tue, 18 Sep 2012 07:22:02 +0000
Received: from [85.158.143.35:64740] by server-2.bemta-4.messagelabs.com id
	A9/7A-06610-91128505; Tue, 18 Sep 2012 07:22:01 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1347952920!14140568!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2354 invoked from network); 18 Sep 2012 07:22:01 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-3.tower-21.messagelabs.com with SMTP;
	18 Sep 2012 07:22:01 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 18 Sep 2012 08:22:00 +0100
Message-Id: <50583D35020000780009BFB0@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 18 Sep 2012 08:21:57 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Daniel De Graaf" <dgdegra@tycho.nsa.gov>
References: <1347895425-17959-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1347895425-17959-20-git-send-email-dgdegra@tycho.nsa.gov>
In-Reply-To: <1347895425-17959-20-git-send-email-dgdegra@tycho.nsa.gov>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Tim Deegan <tim@xen.org>, keir@xen.org, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 19/23] arch/x86: check remote MMIO remap
 permissions
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 17.09.12 at 17:23, Daniel De Graaf <dgdegra@tycho.nsa.gov> wrote:
> --- a/xen/arch/x86/mm.c
> +++ b/xen/arch/x86/mm.c
> @@ -754,6 +754,18 @@ get_page_from_l1e(
>              return -EINVAL;
>          }
>  
> +        if ( pg_owner != curr->domain &&
> +             !iomem_access_permitted(curr->domain, mfn, mfn) )

On a second (or third?) look, I don't think this is right - the current
domain doesn't matter here at all. What does matter is who's page
tables the mapping is to be put in (i.e. l1e_owner), which of course
in certain cases ends up being the current domain.

Jan

> +        {
> +            if ( mfn != (PADDR_MASK >> PAGE_SHIFT) ) /* INVALID_MFN? */
> +            {
> +                MEM_LOG("Domain %u attempted to map I/O space %08lx in domain %u",
> +                        curr->domain->domain_id, mfn, pg_owner->domain_id);
> +                return -EPERM;
> +            }
> +            return -EINVAL;
> +        }
> +
>          if ( !(l1f & _PAGE_RW) ||
>               !rangeset_contains_singleton(mmio_ro_ranges, mfn) )
>              return 0;
> -- 
> 1.7.11.4




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 18 07:23:56 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Sep 2012 07:23:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDs9Z-0004pF-Iv; Tue, 18 Sep 2012 07:23:29 +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 1TDs9X-0004oi-Pz
	for xen-devel@lists.xensource.com; Tue, 18 Sep 2012 07:23:28 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1347953001!2106536!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDk2NzI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15137 invoked from network); 18 Sep 2012 07:23:21 -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;
	18 Sep 2012 07:23:21 -0000
X-IronPort-AV: E=Sophos;i="4.80,441,1344211200"; d="scan'208";a="14596206"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Sep 2012 07:23:21 +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.279.1;
	Tue, 18 Sep 2012 08:23:21 +0100
Message-ID: <1347953000.25803.77.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
Date: Tue, 18 Sep 2012 08:23:20 +0100
In-Reply-To: <50579BA6.1080503@jhuapl.edu>
References: <50579BA6.1080503@jhuapl.edu>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Samuel Thibault <samuel.thibault@ens-lyon.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH mini-os enhancements for vtpm 1/8]
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2012-09-17 at 22:52 +0100, Matthew Fioravante wrote:
> This patch adds iowritexx() and ioreadxx() functions for interacting
> with hardware memory to mini-os. The functions are available in a header
> iorw.h
> 
> Signed off by Matthew Fioravante: matthew.fioravante@jhuapl.edu
> 
> diff --git a/extras/mini-os/arch/ia64/iorw.c
> b/extras/mini-os/arch/ia64/iorw.c
> --- /dev/null
> +++ b/extras/mini-os/arch/ia64/iorw.c

The last vestiges of ia64 support have now been removed from the tree,
so there is no need for this change any more.

If you spot any other ia64 bits as you go through please feel free to
remove or report them.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 18 07:23:56 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Sep 2012 07:23:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDs9Z-0004pF-Iv; Tue, 18 Sep 2012 07:23:29 +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 1TDs9X-0004oi-Pz
	for xen-devel@lists.xensource.com; Tue, 18 Sep 2012 07:23:28 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1347953001!2106536!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDk2NzI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15137 invoked from network); 18 Sep 2012 07:23:21 -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;
	18 Sep 2012 07:23:21 -0000
X-IronPort-AV: E=Sophos;i="4.80,441,1344211200"; d="scan'208";a="14596206"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Sep 2012 07:23:21 +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.279.1;
	Tue, 18 Sep 2012 08:23:21 +0100
Message-ID: <1347953000.25803.77.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
Date: Tue, 18 Sep 2012 08:23:20 +0100
In-Reply-To: <50579BA6.1080503@jhuapl.edu>
References: <50579BA6.1080503@jhuapl.edu>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Samuel Thibault <samuel.thibault@ens-lyon.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH mini-os enhancements for vtpm 1/8]
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2012-09-17 at 22:52 +0100, Matthew Fioravante wrote:
> This patch adds iowritexx() and ioreadxx() functions for interacting
> with hardware memory to mini-os. The functions are available in a header
> iorw.h
> 
> Signed off by Matthew Fioravante: matthew.fioravante@jhuapl.edu
> 
> diff --git a/extras/mini-os/arch/ia64/iorw.c
> b/extras/mini-os/arch/ia64/iorw.c
> --- /dev/null
> +++ b/extras/mini-os/arch/ia64/iorw.c

The last vestiges of ia64 support have now been removed from the tree,
so there is no need for this change any more.

If you spot any other ia64 bits as you go through please feel free to
remove or report them.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 18 07:28:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Sep 2012 07:28:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDsDt-00055h-9W; Tue, 18 Sep 2012 07:27:57 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1TDsDr-00055Y-Bv
	for xen-devel@lists.xensource.com; Tue, 18 Sep 2012 07:27:55 +0000
Received: from [85.158.137.99:62646] by server-6.bemta-3.messagelabs.com id
	AB/05-29694-A7228505; Tue, 18 Sep 2012 07:27:54 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-217.messagelabs.com!1347953273!18100967!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDk2NzI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23018 invoked from network); 18 Sep 2012 07:27:54 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Sep 2012 07:27:54 -0000
X-IronPort-AV: E=Sophos;i="4.80,441,1344211200"; d="scan'208";a="14596319"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Sep 2012 07:27:53 +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.279.1;
	Tue, 18 Sep 2012 08:27:53 +0100
Message-ID: <1347953273.25803.80.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
Date: Tue, 18 Sep 2012 08:27:53 +0100
In-Reply-To: <50579C5F.5040004@jhuapl.edu>
References: <50579C5F.5040004@jhuapl.edu>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Samuel Thibault <samuel.thibault@ens-lyon.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH mini-os enhancements for vtpm 2/8] add posix
 io to blkfront
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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/extras/mini-os/include/lib.h b/extras/mini-os/include/lib.h
> --- a/extras/mini-os/include/lib.h
> +++ b/extras/mini-os/include/lib.h
> @@ -174,6 +174,7 @@ extern struct file {
>      } tap;
>      struct {
>          struct blkfront_dev *dev;
> +            off_t offset;

In indentation here and in several other places in this patch is all
over the place. Please try and stick to the prevailing style (tabs vs
spaces, numbers of them, brace placement etc) in the surrounding code.

>      } blk;
>      struct {
>          struct kbdfront_dev *dev;
> diff --git a/extras/mini-os/lib/sys.c b/extras/mini-os/lib/sys.c
> --- a/extras/mini-os/lib/sys.c
> +++ b/extras/mini-os/lib/sys.c
> @@ -289,6 +289,11 @@ int read(int fd, void *buf, size_t nbytes)
>          return ret * sizeof(union xenfb_in_event);
>          }
>  #endif
> +#ifdef CONFIG_BLKFRONT
> +        case FTYPE_BLK: {
> +        return blkfront_posix_read(fd, buf, nbytes);
> +        }
> +#endif
>      default:
>          break;
>      }
> @@ -321,6 +326,10 @@ int write(int fd, const void *buf, size_t nbytes)
>          netfront_xmit(files[fd].tap.dev, (void*) buf, nbytes);
>          return nbytes;
>  #endif
> +#ifdef CONFIG_BLKFRONT
> +    case FTYPE_BLK:
> +        return blkfront_posix_write(fd, buf, nbytes);
> +#endif
>      default:
>          break;
>      }
> @@ -331,8 +340,37 @@ int write(int fd, const void *buf, size_t nbytes)
>  
>  off_t lseek(int fd, off_t offset, int whence)
>  {
> -    errno = ESPIPE;
> -    return (off_t) -1;
> +    switch(files[fd].type) {
> +#ifdef CONFIG_BLKFRONT

The whitespace in the rest of this hunk is particularly confused.

> +       case FTYPE_BLK:
> +      switch (whence) {
> +         case SEEK_SET:
> +        files[fd].file.offset = offset;
> +        break;
> +         case SEEK_CUR:
> +        files[fd].file.offset += offset;
> +        break;
> +         case SEEK_END:
> +        {
> +           struct stat st;
> +           int ret;
> +           ret = fstat(fd, &st);
> +           if (ret)
> +              return -1;
> +           files[fd].file.offset = st.st_size + offset;
> +           break;
> +        }
> +         default:
> +        errno = EINVAL;
> +        return -1;
> +      }
> +      return files[fd].file.offset;
> +      break;
> +#endif
> +       default: /* Not implemented on this FTYPE */
> +      errno = ESPIPE;
> +      return (off_t) -1;
> +    }
>  }
>  
>  int fsync(int fd) {
> @@ -445,6 +483,10 @@ int fstat(int fd, struct stat *buf)
>          buf->st_ctime = time(NULL);
>          return 0;
>      }
> +#ifdef CONFIG_BLKFRONT
> +    case FTYPE_BLK:
> +       return blkfront_posix_fstat(fd, buf);
> +#endif
>      default:
>          break;
>      }
> 
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 18 07:28:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Sep 2012 07:28:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDsDt-00055h-9W; Tue, 18 Sep 2012 07:27:57 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1TDsDr-00055Y-Bv
	for xen-devel@lists.xensource.com; Tue, 18 Sep 2012 07:27:55 +0000
Received: from [85.158.137.99:62646] by server-6.bemta-3.messagelabs.com id
	AB/05-29694-A7228505; Tue, 18 Sep 2012 07:27:54 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-217.messagelabs.com!1347953273!18100967!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDk2NzI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23018 invoked from network); 18 Sep 2012 07:27:54 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Sep 2012 07:27:54 -0000
X-IronPort-AV: E=Sophos;i="4.80,441,1344211200"; d="scan'208";a="14596319"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Sep 2012 07:27:53 +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.279.1;
	Tue, 18 Sep 2012 08:27:53 +0100
Message-ID: <1347953273.25803.80.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
Date: Tue, 18 Sep 2012 08:27:53 +0100
In-Reply-To: <50579C5F.5040004@jhuapl.edu>
References: <50579C5F.5040004@jhuapl.edu>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Samuel Thibault <samuel.thibault@ens-lyon.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH mini-os enhancements for vtpm 2/8] add posix
 io to blkfront
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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/extras/mini-os/include/lib.h b/extras/mini-os/include/lib.h
> --- a/extras/mini-os/include/lib.h
> +++ b/extras/mini-os/include/lib.h
> @@ -174,6 +174,7 @@ extern struct file {
>      } tap;
>      struct {
>          struct blkfront_dev *dev;
> +            off_t offset;

In indentation here and in several other places in this patch is all
over the place. Please try and stick to the prevailing style (tabs vs
spaces, numbers of them, brace placement etc) in the surrounding code.

>      } blk;
>      struct {
>          struct kbdfront_dev *dev;
> diff --git a/extras/mini-os/lib/sys.c b/extras/mini-os/lib/sys.c
> --- a/extras/mini-os/lib/sys.c
> +++ b/extras/mini-os/lib/sys.c
> @@ -289,6 +289,11 @@ int read(int fd, void *buf, size_t nbytes)
>          return ret * sizeof(union xenfb_in_event);
>          }
>  #endif
> +#ifdef CONFIG_BLKFRONT
> +        case FTYPE_BLK: {
> +        return blkfront_posix_read(fd, buf, nbytes);
> +        }
> +#endif
>      default:
>          break;
>      }
> @@ -321,6 +326,10 @@ int write(int fd, const void *buf, size_t nbytes)
>          netfront_xmit(files[fd].tap.dev, (void*) buf, nbytes);
>          return nbytes;
>  #endif
> +#ifdef CONFIG_BLKFRONT
> +    case FTYPE_BLK:
> +        return blkfront_posix_write(fd, buf, nbytes);
> +#endif
>      default:
>          break;
>      }
> @@ -331,8 +340,37 @@ int write(int fd, const void *buf, size_t nbytes)
>  
>  off_t lseek(int fd, off_t offset, int whence)
>  {
> -    errno = ESPIPE;
> -    return (off_t) -1;
> +    switch(files[fd].type) {
> +#ifdef CONFIG_BLKFRONT

The whitespace in the rest of this hunk is particularly confused.

> +       case FTYPE_BLK:
> +      switch (whence) {
> +         case SEEK_SET:
> +        files[fd].file.offset = offset;
> +        break;
> +         case SEEK_CUR:
> +        files[fd].file.offset += offset;
> +        break;
> +         case SEEK_END:
> +        {
> +           struct stat st;
> +           int ret;
> +           ret = fstat(fd, &st);
> +           if (ret)
> +              return -1;
> +           files[fd].file.offset = st.st_size + offset;
> +           break;
> +        }
> +         default:
> +        errno = EINVAL;
> +        return -1;
> +      }
> +      return files[fd].file.offset;
> +      break;
> +#endif
> +       default: /* Not implemented on this FTYPE */
> +      errno = ESPIPE;
> +      return (off_t) -1;
> +    }
>  }
>  
>  int fsync(int fd) {
> @@ -445,6 +483,10 @@ int fstat(int fd, struct stat *buf)
>          buf->st_ctime = time(NULL);
>          return 0;
>      }
> +#ifdef CONFIG_BLKFRONT
> +    case FTYPE_BLK:
> +       return blkfront_posix_fstat(fd, buf);
> +#endif
>      default:
>          break;
>      }
> 
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 18 07:31:11 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Sep 2012 07: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 1TDsGk-0005DA-SM; Tue, 18 Sep 2012 07:30:54 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1TDsGk-0005D2-5R
	for xen-devel@lists.xensource.com; Tue, 18 Sep 2012 07:30:54 +0000
Received: from [85.158.137.99:52900] by server-6.bemta-3.messagelabs.com id
	FA/E9-29694-D2328505; Tue, 18 Sep 2012 07:30:53 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-217.messagelabs.com!1347953451!16902130!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDk2NzI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12778 invoked from network); 18 Sep 2012 07:30:51 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Sep 2012 07:30:51 -0000
X-IronPort-AV: E=Sophos;i="4.80,441,1344211200"; d="scan'208";a="14596416"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Sep 2012 07:30: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.279.1;
	Tue, 18 Sep 2012 08:30:51 +0100
Message-ID: <1347953450.25803.82.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Samuel Thibault <samuel.thibault@ens-lyon.org>
Date: Tue, 18 Sep 2012 08:30:50 +0100
In-Reply-To: <20120917221356.GI5110@type.youpi.perso.aquilenet.fr>
References: <50579D07.3030007@jhuapl.edu>
	<20120917221356.GI5110@type.youpi.perso.aquilenet.fr>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Matthew Fioravante <matthew.fioravante@jhuapl.edu>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH mini-os enhancements for vtpm 4/8] disable
 mfn_is_ram
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="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, 2012-09-17 at 23:13 +0100, Samuel Thibault wrote:
> Matthew Fioravante, le Mon 17 Sep 2012 17:58:31 -0400, a =E9crit :
> > This patch disables the mfn_is_ram check in mini-os. The current check
> > is insufficient and fails on some systems with larger than 4gb memory.

How does it fail? What are the symptoms? What are the inputs to this
function which cause it to fail?

> And it is only used for checks, not for actual decisions.

It's made completely useless here though, why not either fix it or
remove it altogether?

There's certainly no reason to leave the dead code after the return
statement.

> =

> Acked-by: Samuel Thibault <samuel.thibault@ens-lyon.org>
> =

> Samuel
> =

> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Sep 18 07:31:11 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Sep 2012 07: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 1TDsGk-0005DA-SM; Tue, 18 Sep 2012 07:30:54 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1TDsGk-0005D2-5R
	for xen-devel@lists.xensource.com; Tue, 18 Sep 2012 07:30:54 +0000
Received: from [85.158.137.99:52900] by server-6.bemta-3.messagelabs.com id
	FA/E9-29694-D2328505; Tue, 18 Sep 2012 07:30:53 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-217.messagelabs.com!1347953451!16902130!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDk2NzI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12778 invoked from network); 18 Sep 2012 07:30:51 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Sep 2012 07:30:51 -0000
X-IronPort-AV: E=Sophos;i="4.80,441,1344211200"; d="scan'208";a="14596416"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Sep 2012 07:30: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.279.1;
	Tue, 18 Sep 2012 08:30:51 +0100
Message-ID: <1347953450.25803.82.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Samuel Thibault <samuel.thibault@ens-lyon.org>
Date: Tue, 18 Sep 2012 08:30:50 +0100
In-Reply-To: <20120917221356.GI5110@type.youpi.perso.aquilenet.fr>
References: <50579D07.3030007@jhuapl.edu>
	<20120917221356.GI5110@type.youpi.perso.aquilenet.fr>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Matthew Fioravante <matthew.fioravante@jhuapl.edu>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH mini-os enhancements for vtpm 4/8] disable
 mfn_is_ram
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="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, 2012-09-17 at 23:13 +0100, Samuel Thibault wrote:
> Matthew Fioravante, le Mon 17 Sep 2012 17:58:31 -0400, a =E9crit :
> > This patch disables the mfn_is_ram check in mini-os. The current check
> > is insufficient and fails on some systems with larger than 4gb memory.

How does it fail? What are the symptoms? What are the inputs to this
function which cause it to fail?

> And it is only used for checks, not for actual decisions.

It's made completely useless here though, why not either fix it or
remove it altogether?

There's certainly no reason to leave the dead code after the return
statement.

> =

> Acked-by: Samuel Thibault <samuel.thibault@ens-lyon.org>
> =

> Samuel
> =

> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Sep 18 07:31:36 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Sep 2012 07:31:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDsH9-0005Fb-9n; Tue, 18 Sep 2012 07:31:19 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <samuel.thibault@ens-lyon.org>) id 1TDsH8-0005FL-Al
	for xen-devel@lists.xensource.com; Tue, 18 Sep 2012 07:31:18 +0000
Received: from [85.158.139.83:47219] by server-1.bemta-5.messagelabs.com id
	C8/AA-32692-54328505; Tue, 18 Sep 2012 07:31:17 +0000
X-Env-Sender: samuel.thibault@ens-lyon.org
X-Msg-Ref: server-6.tower-182.messagelabs.com!1347953476!27084703!1
X-Originating-IP: [140.77.166.68]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31328 invoked from network); 18 Sep 2012 07:31:17 -0000
Received: from toccata.ens-lyon.org (HELO toccata.ens-lyon.org) (140.77.166.68)
	by server-6.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 18 Sep 2012 07:31:17 -0000
Received: from localhost (localhost [127.0.0.1])
	by toccata.ens-lyon.org (Postfix) with ESMTP id 51C4C8408C;
	Tue, 18 Sep 2012 09:31:16 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at toccata.ens-lyon.org
Received: from toccata.ens-lyon.org ([127.0.0.1])
	by localhost (toccata.ens-lyon.org [127.0.0.1]) (amavisd-new,
	port 10024)
	with ESMTP id v6TimA7mhs4w; Tue, 18 Sep 2012 09:31:16 +0200 (CEST)
Received: from type.ipv6 (youpi.is-a-geek.org [80.67.176.89])
	(using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits))
	(No client certificate requested)
	by toccata.ens-lyon.org (Postfix) with ESMTPSA id 0375B84084;
	Tue, 18 Sep 2012 09:31:16 +0200 (CEST)
Received: from samy by type.ipv6 with local (Exim 4.80)
	(envelope-from <samuel.thibault@ens-lyon.org>)
	id 1TDsH4-0004en-LK; Tue, 18 Sep 2012 09:31:14 +0200
Date: Tue, 18 Sep 2012 09:31:14 +0200
From: Samuel Thibault <samuel.thibault@ens-lyon.org>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120918073114.GE5110@type.youpi.perso.aquilenet.fr>
Mail-Followup-To: Samuel Thibault <samuel.thibault@ens-lyon.org>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Matthew Fioravante <matthew.fioravante@jhuapl.edu>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
References: <50579E7F.1050803@jhuapl.edu>
	<1347952878.25803.76.camel@dagon.hellion.org.uk>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1347952878.25803.76.camel@dagon.hellion.org.uk>
User-Agent: Mutt/1.5.21+34 (58baf7c9f32f) (2010-12-30)
Cc: Matthew Fioravante <matthew.fioravante@jhuapl.edu>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH mini-os enhancements for vtpm 7/8] add
 floating point and sse to mini-os
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell, le Tue 18 Sep 2012 08:21:18 +0100, a =E9crit :
> On Mon, 2012-09-17 at 23:04 +0100, Matthew Fioravante wrote:
> > This patch adds floating point and sse support to mini-os by
> > initializing the floating point unit and the see unit during domain boo=
t up.
> > =

> > =

> > Signed of by: Matthew Fioravante matthew.fioravante@jhuapl.edu
> > =

> > diff --git a/extras/mini-os/arch/x86/setup.c
> > b/extras/mini-os/arch/x86/setup.c
> > --- a/extras/mini-os/arch/x86/setup.c
> > +++ b/extras/mini-os/arch/x86/setup.c
> > @@ -74,9 +74,28 @@ shared_info_t *map_shared_info(unsigned long pa)
> >      return (shared_info_t *)shared_info;
> >  }
> >  =

> > +static inline void fpu_init(void) {
> > +    asm volatile("fninit");
> > +}
> > +
> > +#ifdef __SSE__
> =

> How and when is this symbol defined?

This is defined by the compiler if some -msse is enabled. This is the
default on i686/x86_64 at least.

Samuel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 18 07:31:36 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Sep 2012 07:31:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDsH9-0005Fb-9n; Tue, 18 Sep 2012 07:31:19 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <samuel.thibault@ens-lyon.org>) id 1TDsH8-0005FL-Al
	for xen-devel@lists.xensource.com; Tue, 18 Sep 2012 07:31:18 +0000
Received: from [85.158.139.83:47219] by server-1.bemta-5.messagelabs.com id
	C8/AA-32692-54328505; Tue, 18 Sep 2012 07:31:17 +0000
X-Env-Sender: samuel.thibault@ens-lyon.org
X-Msg-Ref: server-6.tower-182.messagelabs.com!1347953476!27084703!1
X-Originating-IP: [140.77.166.68]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31328 invoked from network); 18 Sep 2012 07:31:17 -0000
Received: from toccata.ens-lyon.org (HELO toccata.ens-lyon.org) (140.77.166.68)
	by server-6.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 18 Sep 2012 07:31:17 -0000
Received: from localhost (localhost [127.0.0.1])
	by toccata.ens-lyon.org (Postfix) with ESMTP id 51C4C8408C;
	Tue, 18 Sep 2012 09:31:16 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at toccata.ens-lyon.org
Received: from toccata.ens-lyon.org ([127.0.0.1])
	by localhost (toccata.ens-lyon.org [127.0.0.1]) (amavisd-new,
	port 10024)
	with ESMTP id v6TimA7mhs4w; Tue, 18 Sep 2012 09:31:16 +0200 (CEST)
Received: from type.ipv6 (youpi.is-a-geek.org [80.67.176.89])
	(using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits))
	(No client certificate requested)
	by toccata.ens-lyon.org (Postfix) with ESMTPSA id 0375B84084;
	Tue, 18 Sep 2012 09:31:16 +0200 (CEST)
Received: from samy by type.ipv6 with local (Exim 4.80)
	(envelope-from <samuel.thibault@ens-lyon.org>)
	id 1TDsH4-0004en-LK; Tue, 18 Sep 2012 09:31:14 +0200
Date: Tue, 18 Sep 2012 09:31:14 +0200
From: Samuel Thibault <samuel.thibault@ens-lyon.org>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120918073114.GE5110@type.youpi.perso.aquilenet.fr>
Mail-Followup-To: Samuel Thibault <samuel.thibault@ens-lyon.org>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Matthew Fioravante <matthew.fioravante@jhuapl.edu>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
References: <50579E7F.1050803@jhuapl.edu>
	<1347952878.25803.76.camel@dagon.hellion.org.uk>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1347952878.25803.76.camel@dagon.hellion.org.uk>
User-Agent: Mutt/1.5.21+34 (58baf7c9f32f) (2010-12-30)
Cc: Matthew Fioravante <matthew.fioravante@jhuapl.edu>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH mini-os enhancements for vtpm 7/8] add
 floating point and sse to mini-os
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell, le Tue 18 Sep 2012 08:21:18 +0100, a =E9crit :
> On Mon, 2012-09-17 at 23:04 +0100, Matthew Fioravante wrote:
> > This patch adds floating point and sse support to mini-os by
> > initializing the floating point unit and the see unit during domain boo=
t up.
> > =

> > =

> > Signed of by: Matthew Fioravante matthew.fioravante@jhuapl.edu
> > =

> > diff --git a/extras/mini-os/arch/x86/setup.c
> > b/extras/mini-os/arch/x86/setup.c
> > --- a/extras/mini-os/arch/x86/setup.c
> > +++ b/extras/mini-os/arch/x86/setup.c
> > @@ -74,9 +74,28 @@ shared_info_t *map_shared_info(unsigned long pa)
> >      return (shared_info_t *)shared_info;
> >  }
> >  =

> > +static inline void fpu_init(void) {
> > +    asm volatile("fninit");
> > +}
> > +
> > +#ifdef __SSE__
> =

> How and when is this symbol defined?

This is defined by the compiler if some -msse is enabled. This is the
default on i686/x86_64 at least.

Samuel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 18 07:33:02 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Sep 2012 07: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 1TDsIa-0005PZ-Pl; Tue, 18 Sep 2012 07:32: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 1TDsIZ-0005P8-4l
	for Xen-devel@lists.xensource.com; Tue, 18 Sep 2012 07:32:47 +0000
Received: from [85.158.143.35:63138] by server-3.bemta-4.messagelabs.com id
	5A/2E-08232-E9328505; Tue, 18 Sep 2012 07:32:46 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1347953564!14142621!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDk2NzI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13926 invoked from network); 18 Sep 2012 07:32: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;
	18 Sep 2012 07:32:44 -0000
X-IronPort-AV: E=Sophos;i="4.80,441,1344211200"; d="scan'208";a="14596448"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Sep 2012 07:32: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.279.1;
	Tue, 18 Sep 2012 08:32:40 +0100
Message-ID: <1347953559.25803.83.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Mukesh Rathor <mukesh.rathor@oracle.com>
Date: Tue, 18 Sep 2012 08:32:39 +0100
In-Reply-To: <20120917165058.686ad295@mantra.us.oracle.com>
References: <20120815180716.0049bffe@mantra.us.oracle.com>
	<1347372623.5305.170.camel@zakaz.uk.xensource.com>
	<20120912181910.6b0b9d2b@mantra.us.oracle.com>
	<1347536266.24226.97.camel@zakaz.uk.xensource.com>
	<20120913173420.22b09c90@mantra.us.oracle.com>
	<20120917165058.686ad295@mantra.us.oracle.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [RFC PATCH 8/8]: PVH: privcmd changes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-09-18 at 00:50 +0100, Mukesh Rathor wrote:
> On Thu, 13 Sep 2012 17:34:20 -0700
> Mukesh Rathor <mukesh.rathor@oracle.com> wrote:
> 
> > On Thu, 13 Sep 2012 12:37:46 +0100
> > Ian Campbell <Ian.Campbell@citrix.com> wrote:
> > 
> > > On Thu, 2012-09-13 at 02:19 +0100, Mukesh Rathor wrote:
> > > > On Tue, 11 Sep 2012 15:10:23 +0100
> > > > 
> > > I think using vm_private within a subsystem/layer is ok, what I
> > > think we should avoid is having layers pass data back and forth in
> > > that field.
> > 
> > Ah I see your point. Ok, let me play around a bit see what I can do.
> 
> Hey Ian,
> 
> I played around a bit with privcmd, but not a whole lot can be done. I
> did change things around a bit to make the APIs more symmetric and hide
> vm_private_data from mmu.c. Please take a look. Unless major objections,
> I'd like to resubmit all linux patches asap.

It's pretty hard to review complete .c files rather than diffs. I think
you can/should just go ahead and resubmit the latest patches.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 18 07:33:02 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Sep 2012 07: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 1TDsIa-0005PZ-Pl; Tue, 18 Sep 2012 07:32: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 1TDsIZ-0005P8-4l
	for Xen-devel@lists.xensource.com; Tue, 18 Sep 2012 07:32:47 +0000
Received: from [85.158.143.35:63138] by server-3.bemta-4.messagelabs.com id
	5A/2E-08232-E9328505; Tue, 18 Sep 2012 07:32:46 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1347953564!14142621!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDk2NzI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13926 invoked from network); 18 Sep 2012 07:32: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;
	18 Sep 2012 07:32:44 -0000
X-IronPort-AV: E=Sophos;i="4.80,441,1344211200"; d="scan'208";a="14596448"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Sep 2012 07:32: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.279.1;
	Tue, 18 Sep 2012 08:32:40 +0100
Message-ID: <1347953559.25803.83.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Mukesh Rathor <mukesh.rathor@oracle.com>
Date: Tue, 18 Sep 2012 08:32:39 +0100
In-Reply-To: <20120917165058.686ad295@mantra.us.oracle.com>
References: <20120815180716.0049bffe@mantra.us.oracle.com>
	<1347372623.5305.170.camel@zakaz.uk.xensource.com>
	<20120912181910.6b0b9d2b@mantra.us.oracle.com>
	<1347536266.24226.97.camel@zakaz.uk.xensource.com>
	<20120913173420.22b09c90@mantra.us.oracle.com>
	<20120917165058.686ad295@mantra.us.oracle.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [RFC PATCH 8/8]: PVH: privcmd changes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-09-18 at 00:50 +0100, Mukesh Rathor wrote:
> On Thu, 13 Sep 2012 17:34:20 -0700
> Mukesh Rathor <mukesh.rathor@oracle.com> wrote:
> 
> > On Thu, 13 Sep 2012 12:37:46 +0100
> > Ian Campbell <Ian.Campbell@citrix.com> wrote:
> > 
> > > On Thu, 2012-09-13 at 02:19 +0100, Mukesh Rathor wrote:
> > > > On Tue, 11 Sep 2012 15:10:23 +0100
> > > > 
> > > I think using vm_private within a subsystem/layer is ok, what I
> > > think we should avoid is having layers pass data back and forth in
> > > that field.
> > 
> > Ah I see your point. Ok, let me play around a bit see what I can do.
> 
> Hey Ian,
> 
> I played around a bit with privcmd, but not a whole lot can be done. I
> did change things around a bit to make the APIs more symmetric and hide
> vm_private_data from mmu.c. Please take a look. Unless major objections,
> I'd like to resubmit all linux patches asap.

It's pretty hard to review complete .c files rather than diffs. I think
you can/should just go ahead and resubmit the latest patches.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 18 07:34:54 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Sep 2012 07:34:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDsKP-0005cE-9s; Tue, 18 Sep 2012 07:34:41 +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 1TDsKN-0005bz-G1
	for xen-devel@lists.xensource.com; Tue, 18 Sep 2012 07:34:39 +0000
Received: from [85.158.139.83:12606] by server-4.bemta-5.messagelabs.com id
	40/CD-23042-E0428505; Tue, 18 Sep 2012 07:34:38 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1347953668!30641441!1
X-Originating-IP: [74.125.83.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20055 invoked from network); 18 Sep 2012 07:34:28 -0000
Received: from mail-ee0-f43.google.com (HELO mail-ee0-f43.google.com)
	(74.125.83.43)
	by server-5.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Sep 2012 07:34:28 -0000
Received: by eekd4 with SMTP id d4so3853939eek.30
	for <xen-devel@lists.xensource.com>;
	Tue, 18 Sep 2012 00:34:28 -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=qzwNw9pBaTpg1gS/IICok8ic0Zrw0U54IDExozOi8b8=;
	b=mzXM1pkriEG1lBRvHCWy9YxqJrvllu/rfvk2LX+BF3oNCxsPIp8eIfOQsKRDWbohj9
	LRgIf1Em3FB8CHvZI3zsk7Ixfnc4yz0BFZtw4//BxyuCedl1n7nZcbqOouFBbxUvJI+7
	vXv8iNzl5cTFIfafRBNmit1IH+nb4vC8TR8jzWtOCv6EP/3DwFIfktLXaLP9RMLfOdkl
	/DHRcIyUm1jq3WeiSIgKiKJwhcMwHz+bYE2pa6gzb1zz0Pbq0KNK8OSHufIX7I2P7Wis
	M6PenwNWjRU8oT7+awpnsWgUqPTNi9MOncfCrSIdLCg7em+0gyp2D/BQeGftUsxkn4wh
	8B6Q==
Received: by 10.14.221.197 with SMTP id r45mr16308603eep.41.1347953668186;
	Tue, 18 Sep 2012 00:34:28 -0700 (PDT)
Received: from [192.168.1.3] (host86-183-251-65.range86-183.btcentralplus.com.
	[86.183.251.65])
	by mx.google.com with ESMTPS id i41sm33922327eem.7.2012.09.18.00.34.26
	(version=SSLv3 cipher=OTHER); Tue, 18 Sep 2012 00:34:27 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.33.0.120411
Date: Tue, 18 Sep 2012 08:34:20 +0100
From: Keir Fraser <keir@xen.org>
To: Matthew Fioravante <matthew.fioravante@jhuapl.edu>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Message-ID: <CC7DE28C.4C4CD%keir@xen.org>
Thread-Topic: [Xen-devel] [PATCH vtpm_manager 1/2] Updates and bug fixes to
	vtpm_manager
Thread-Index: Ac2VcAQG8qNTCi4VkUiHS0LoAz8jlA==
In-Reply-To: <50579343.6020106@jhuapl.edu>
Mime-version: 1.0
Subject: Re: [Xen-devel] [PATCH vtpm_manager 1/2] Updates and bug fixes to
 vtpm_manager
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 17/09/2012 22:16, "Matthew Fioravante" <matthew.fioravante@jhuapl.edu>
wrote:

> The following patch contains a major set of bug fixes and feature
> enhancements to vtpm_manager.
> 
> vtpm_manager was previously riddled with memory leaks, race conditions,
> IO deadlocks, and other assorted bugs.
> 
> This patch fixes numerous bugs in vtpm manager and also adds new
> functionality for supporting vtpm stub domains.
> 
> It adds a new program (vtpmmgrtalk) that is used by the hotplug script
> fixes (next patch) to avoid IO deadlocks with pipes.
> 
> Finally, it also breaks the compilation of vtpm_manager into separate
> static libraries, which are then used later by the vtpmmgrdom stub domain.
> 
> Signed of by: Matthew Fioravante matthew.fioravante@jhuapl.edu

Your email client has line-wrapped your patches. Please fix and re-send.

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 18 07:34:54 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Sep 2012 07:34:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDsKP-0005cE-9s; Tue, 18 Sep 2012 07:34:41 +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 1TDsKN-0005bz-G1
	for xen-devel@lists.xensource.com; Tue, 18 Sep 2012 07:34:39 +0000
Received: from [85.158.139.83:12606] by server-4.bemta-5.messagelabs.com id
	40/CD-23042-E0428505; Tue, 18 Sep 2012 07:34:38 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1347953668!30641441!1
X-Originating-IP: [74.125.83.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20055 invoked from network); 18 Sep 2012 07:34:28 -0000
Received: from mail-ee0-f43.google.com (HELO mail-ee0-f43.google.com)
	(74.125.83.43)
	by server-5.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Sep 2012 07:34:28 -0000
Received: by eekd4 with SMTP id d4so3853939eek.30
	for <xen-devel@lists.xensource.com>;
	Tue, 18 Sep 2012 00:34:28 -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=qzwNw9pBaTpg1gS/IICok8ic0Zrw0U54IDExozOi8b8=;
	b=mzXM1pkriEG1lBRvHCWy9YxqJrvllu/rfvk2LX+BF3oNCxsPIp8eIfOQsKRDWbohj9
	LRgIf1Em3FB8CHvZI3zsk7Ixfnc4yz0BFZtw4//BxyuCedl1n7nZcbqOouFBbxUvJI+7
	vXv8iNzl5cTFIfafRBNmit1IH+nb4vC8TR8jzWtOCv6EP/3DwFIfktLXaLP9RMLfOdkl
	/DHRcIyUm1jq3WeiSIgKiKJwhcMwHz+bYE2pa6gzb1zz0Pbq0KNK8OSHufIX7I2P7Wis
	M6PenwNWjRU8oT7+awpnsWgUqPTNi9MOncfCrSIdLCg7em+0gyp2D/BQeGftUsxkn4wh
	8B6Q==
Received: by 10.14.221.197 with SMTP id r45mr16308603eep.41.1347953668186;
	Tue, 18 Sep 2012 00:34:28 -0700 (PDT)
Received: from [192.168.1.3] (host86-183-251-65.range86-183.btcentralplus.com.
	[86.183.251.65])
	by mx.google.com with ESMTPS id i41sm33922327eem.7.2012.09.18.00.34.26
	(version=SSLv3 cipher=OTHER); Tue, 18 Sep 2012 00:34:27 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.33.0.120411
Date: Tue, 18 Sep 2012 08:34:20 +0100
From: Keir Fraser <keir@xen.org>
To: Matthew Fioravante <matthew.fioravante@jhuapl.edu>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Message-ID: <CC7DE28C.4C4CD%keir@xen.org>
Thread-Topic: [Xen-devel] [PATCH vtpm_manager 1/2] Updates and bug fixes to
	vtpm_manager
Thread-Index: Ac2VcAQG8qNTCi4VkUiHS0LoAz8jlA==
In-Reply-To: <50579343.6020106@jhuapl.edu>
Mime-version: 1.0
Subject: Re: [Xen-devel] [PATCH vtpm_manager 1/2] Updates and bug fixes to
 vtpm_manager
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 17/09/2012 22:16, "Matthew Fioravante" <matthew.fioravante@jhuapl.edu>
wrote:

> The following patch contains a major set of bug fixes and feature
> enhancements to vtpm_manager.
> 
> vtpm_manager was previously riddled with memory leaks, race conditions,
> IO deadlocks, and other assorted bugs.
> 
> This patch fixes numerous bugs in vtpm manager and also adds new
> functionality for supporting vtpm stub domains.
> 
> It adds a new program (vtpmmgrtalk) that is used by the hotplug script
> fixes (next patch) to avoid IO deadlocks with pipes.
> 
> Finally, it also breaks the compilation of vtpm_manager into separate
> static libraries, which are then used later by the vtpmmgrdom stub domain.
> 
> Signed of by: Matthew Fioravante matthew.fioravante@jhuapl.edu

Your email client has line-wrapped your patches. Please fix and re-send.

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 18 07:38:39 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Sep 2012 07: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 1TDsO2-0005pX-Ut; Tue, 18 Sep 2012 07:38:26 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1TDsO1-0005pS-Cg
	for xen-devel@lists.xensource.com; Tue, 18 Sep 2012 07:38:25 +0000
Received: from [85.158.143.99:17138] by server-3.bemta-4.messagelabs.com id
	15/C6-08232-0F428505; Tue, 18 Sep 2012 07:38:24 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1347953904!30802418!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDk2NzI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26340 invoked from network); 18 Sep 2012 07:38:24 -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;
	18 Sep 2012 07:38:24 -0000
X-IronPort-AV: E=Sophos;i="4.80,441,1344211200"; d="scan'208";a="14596568"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Sep 2012 07:38:24 +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.279.1;
	Tue, 18 Sep 2012 08:38:23 +0100
Message-ID: <1347953903.25803.88.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Samuel Thibault <samuel.thibault@ens-lyon.org>
Date: Tue, 18 Sep 2012 08:38:23 +0100
In-Reply-To: <20120918073114.GE5110@type.youpi.perso.aquilenet.fr>
References: <50579E7F.1050803@jhuapl.edu>
	<1347952878.25803.76.camel@dagon.hellion.org.uk>
	<20120918073114.GE5110@type.youpi.perso.aquilenet.fr>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Matthew Fioravante <matthew.fioravante@jhuapl.edu>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH mini-os enhancements for vtpm 7/8] add
 floating point and sse to mini-os
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-09-18 at 08:31 +0100, Samuel Thibault wrote:
> Ian Campbell, le Tue 18 Sep 2012 08:21:18 +0100, a =E9crit :
> > On Mon, 2012-09-17 at 23:04 +0100, Matthew Fioravante wrote:
> > > This patch adds floating point and sse support to mini-os by
> > > initializing the floating point unit and the see unit during domain b=
oot up.
> > > =

> > > =

> > > Signed of by: Matthew Fioravante matthew.fioravante@jhuapl.edu
> > > =

> > > diff --git a/extras/mini-os/arch/x86/setup.c
> > > b/extras/mini-os/arch/x86/setup.c
> > > --- a/extras/mini-os/arch/x86/setup.c
> > > +++ b/extras/mini-os/arch/x86/setup.c
> > > @@ -74,9 +74,28 @@ shared_info_t *map_shared_info(unsigned long pa)
> > >      return (shared_info_t *)shared_info;
> > >  }
> > >  =

> > > +static inline void fpu_init(void) {
> > > +    asm volatile("fninit");
> > > +}
> > > +
> > > +#ifdef __SSE__
> > =

> > How and when is this symbol defined?
> =

> This is defined by the compiler if some -msse is enabled. This is the
> default on i686/x86_64 at least.

Do we support processors/compilers without SSE or conversely do we
require SSE support?

It sounds like either we need a runtime test or the compile time test is
unnecessary.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 18 07:38:39 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Sep 2012 07: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 1TDsO2-0005pX-Ut; Tue, 18 Sep 2012 07:38:26 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1TDsO1-0005pS-Cg
	for xen-devel@lists.xensource.com; Tue, 18 Sep 2012 07:38:25 +0000
Received: from [85.158.143.99:17138] by server-3.bemta-4.messagelabs.com id
	15/C6-08232-0F428505; Tue, 18 Sep 2012 07:38:24 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1347953904!30802418!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDk2NzI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26340 invoked from network); 18 Sep 2012 07:38:24 -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;
	18 Sep 2012 07:38:24 -0000
X-IronPort-AV: E=Sophos;i="4.80,441,1344211200"; d="scan'208";a="14596568"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Sep 2012 07:38:24 +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.279.1;
	Tue, 18 Sep 2012 08:38:23 +0100
Message-ID: <1347953903.25803.88.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Samuel Thibault <samuel.thibault@ens-lyon.org>
Date: Tue, 18 Sep 2012 08:38:23 +0100
In-Reply-To: <20120918073114.GE5110@type.youpi.perso.aquilenet.fr>
References: <50579E7F.1050803@jhuapl.edu>
	<1347952878.25803.76.camel@dagon.hellion.org.uk>
	<20120918073114.GE5110@type.youpi.perso.aquilenet.fr>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Matthew Fioravante <matthew.fioravante@jhuapl.edu>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH mini-os enhancements for vtpm 7/8] add
 floating point and sse to mini-os
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-09-18 at 08:31 +0100, Samuel Thibault wrote:
> Ian Campbell, le Tue 18 Sep 2012 08:21:18 +0100, a =E9crit :
> > On Mon, 2012-09-17 at 23:04 +0100, Matthew Fioravante wrote:
> > > This patch adds floating point and sse support to mini-os by
> > > initializing the floating point unit and the see unit during domain b=
oot up.
> > > =

> > > =

> > > Signed of by: Matthew Fioravante matthew.fioravante@jhuapl.edu
> > > =

> > > diff --git a/extras/mini-os/arch/x86/setup.c
> > > b/extras/mini-os/arch/x86/setup.c
> > > --- a/extras/mini-os/arch/x86/setup.c
> > > +++ b/extras/mini-os/arch/x86/setup.c
> > > @@ -74,9 +74,28 @@ shared_info_t *map_shared_info(unsigned long pa)
> > >      return (shared_info_t *)shared_info;
> > >  }
> > >  =

> > > +static inline void fpu_init(void) {
> > > +    asm volatile("fninit");
> > > +}
> > > +
> > > +#ifdef __SSE__
> > =

> > How and when is this symbol defined?
> =

> This is defined by the compiler if some -msse is enabled. This is the
> default on i686/x86_64 at least.

Do we support processors/compilers without SSE or conversely do we
require SSE support?

It sounds like either we need a runtime test or the compile time test is
unnecessary.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 18 07:39:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Sep 2012 07:39:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDsOQ-0005s2-C2; Tue, 18 Sep 2012 07:38:50 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1TDsOP-0005rn-00
	for xen-devel@lists.xensource.com; Tue, 18 Sep 2012 07:38:49 +0000
Received: from [85.158.137.99:65458] by server-11.bemta-3.messagelabs.com id
	FD/B1-30250-80528505; Tue, 18 Sep 2012 07:38:48 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-217.messagelabs.com!1347953927!12742470!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDk2NzI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4635 invoked from network); 18 Sep 2012 07:38:47 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Sep 2012 07:38:47 -0000
X-IronPort-AV: E=Sophos;i="4.80,441,1344211200"; d="scan'208";a="14596578"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Sep 2012 07:38:47 +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.279.1;
	Tue, 18 Sep 2012 08:38:47 +0100
Message-ID: <1347953926.25803.89.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
Date: Tue, 18 Sep 2012 08:38:46 +0100
In-Reply-To: <50576368.3070007@jhuapl.edu>
References: <50576368.3070007@jhuapl.edu>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] Upgrade vtpmd to berlios version 0.7.4
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2012-09-17 at 18:52 +0100, Matthew Fioravante wrote:
> What will follow soon are updates to vtpmd, vtpm_manager, xm, xl,
> mini-os, and new vtpm and vtpm manager stub domains.

No need to update xm any more, it is deprecated in 4.2.

Who or what is/are Berlios? Are they (actively) maintaining the vTPM?

Perhaps we should consider making this stuff an external dependency
rather than importing it into our code base? This could be done either
as a simple dependency (i.e. require vtpm to be installed before
building) or as a repo cloned during build (like how we handle qemu and
seabios etc).

> The first patch I'd like to submit upgrades vtpmd to version 0.7.4
> 
> This patch does the following:
> -add checks to configure to check for cmake (required by berlios 0.7.4)

Is the model with cmake that it is required on all the end systems
building the project (like make), or is it only needed on the project
maintainer's system (like autoconf/make)?

> -removes all of the 0.5.1 patches
> -adds a single patch for 0.7.4
> -cleans up the makefile, should work for parallel make (avoiding
> version.h discussion from august 2012)
> -builds vtpmd to use berlios 0.7.4
> -Remoed the tpm_emualtor build option. berlios itself provides a kernel
> module if you want to use it in dom0 to emulate the physical tpm.

Is there going to be an associated documentation update/refresh?

> 
> Signed of by: Matthew Fioravante matthew.fioravante@jhuapl.edu

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 18 07:39:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Sep 2012 07:39:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDsOQ-0005s2-C2; Tue, 18 Sep 2012 07:38:50 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1TDsOP-0005rn-00
	for xen-devel@lists.xensource.com; Tue, 18 Sep 2012 07:38:49 +0000
Received: from [85.158.137.99:65458] by server-11.bemta-3.messagelabs.com id
	FD/B1-30250-80528505; Tue, 18 Sep 2012 07:38:48 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-217.messagelabs.com!1347953927!12742470!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDk2NzI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4635 invoked from network); 18 Sep 2012 07:38:47 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Sep 2012 07:38:47 -0000
X-IronPort-AV: E=Sophos;i="4.80,441,1344211200"; d="scan'208";a="14596578"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Sep 2012 07:38:47 +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.279.1;
	Tue, 18 Sep 2012 08:38:47 +0100
Message-ID: <1347953926.25803.89.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
Date: Tue, 18 Sep 2012 08:38:46 +0100
In-Reply-To: <50576368.3070007@jhuapl.edu>
References: <50576368.3070007@jhuapl.edu>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] Upgrade vtpmd to berlios version 0.7.4
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2012-09-17 at 18:52 +0100, Matthew Fioravante wrote:
> What will follow soon are updates to vtpmd, vtpm_manager, xm, xl,
> mini-os, and new vtpm and vtpm manager stub domains.

No need to update xm any more, it is deprecated in 4.2.

Who or what is/are Berlios? Are they (actively) maintaining the vTPM?

Perhaps we should consider making this stuff an external dependency
rather than importing it into our code base? This could be done either
as a simple dependency (i.e. require vtpm to be installed before
building) or as a repo cloned during build (like how we handle qemu and
seabios etc).

> The first patch I'd like to submit upgrades vtpmd to version 0.7.4
> 
> This patch does the following:
> -add checks to configure to check for cmake (required by berlios 0.7.4)

Is the model with cmake that it is required on all the end systems
building the project (like make), or is it only needed on the project
maintainer's system (like autoconf/make)?

> -removes all of the 0.5.1 patches
> -adds a single patch for 0.7.4
> -cleans up the makefile, should work for parallel make (avoiding
> version.h discussion from august 2012)
> -builds vtpmd to use berlios 0.7.4
> -Remoed the tpm_emualtor build option. berlios itself provides a kernel
> module if you want to use it in dom0 to emulate the physical tpm.

Is there going to be an associated documentation update/refresh?

> 
> Signed of by: Matthew Fioravante matthew.fioravante@jhuapl.edu

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 18 07:43:32 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Sep 2012 07: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 1TDsSo-00069H-9H; Tue, 18 Sep 2012 07:43: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 1TDsSm-000697-E8
	for xen-devel@lists.xensource.com; Tue, 18 Sep 2012 07:43:20 +0000
Received: from [85.158.143.99:41278] by server-3.bemta-4.messagelabs.com id
	7A/ED-08232-71628505; Tue, 18 Sep 2012 07:43:19 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1347954199!30803074!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDk2NzI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5891 invoked from network); 18 Sep 2012 07:43:19 -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;
	18 Sep 2012 07:43:19 -0000
X-IronPort-AV: E=Sophos;i="4.80,441,1344211200"; d="scan'208";a="14596669"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Sep 2012 07:43: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.279.1;
	Tue, 18 Sep 2012 08:43:18 +0100
Message-ID: <1347954198.25803.92.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
Date: Tue, 18 Sep 2012 08:43:18 +0100
In-Reply-To: <505793F4.40301@jhuapl.edu>
References: <505793F4.40301@jhuapl.edu>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH vtpm_manager 2/2] Fixes to vtpm 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

On Mon, 2012-09-17 at 22:19 +0100, Matthew Fioravante wrote:
> This patch fixes IO deadlocks in the vtpm hotplug scripts

Is the switch from awk to gawk a part of this? How?

IIRC we deliberately switched from using gawk specific features to allow
e.g. mawk to be used. If there is some gawk specific construct used here
it would be better to recast it in more portable terms IMHO.

> - set -e
> + local resp_hex
> + #send cmd to vtpm_manager and get response
> + if ! resp_hex=`echo "$cmd$(str_to_hex32 $inst)" | vtpmmgrtalk `; then

Is this really the command/control interface provided by VTPM? Can we
not work with upstream to define something more usable?

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 18 07:43:32 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Sep 2012 07: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 1TDsSo-00069H-9H; Tue, 18 Sep 2012 07:43: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 1TDsSm-000697-E8
	for xen-devel@lists.xensource.com; Tue, 18 Sep 2012 07:43:20 +0000
Received: from [85.158.143.99:41278] by server-3.bemta-4.messagelabs.com id
	7A/ED-08232-71628505; Tue, 18 Sep 2012 07:43:19 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1347954199!30803074!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDk2NzI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5891 invoked from network); 18 Sep 2012 07:43:19 -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;
	18 Sep 2012 07:43:19 -0000
X-IronPort-AV: E=Sophos;i="4.80,441,1344211200"; d="scan'208";a="14596669"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Sep 2012 07:43: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.279.1;
	Tue, 18 Sep 2012 08:43:18 +0100
Message-ID: <1347954198.25803.92.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
Date: Tue, 18 Sep 2012 08:43:18 +0100
In-Reply-To: <505793F4.40301@jhuapl.edu>
References: <505793F4.40301@jhuapl.edu>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH vtpm_manager 2/2] Fixes to vtpm 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

On Mon, 2012-09-17 at 22:19 +0100, Matthew Fioravante wrote:
> This patch fixes IO deadlocks in the vtpm hotplug scripts

Is the switch from awk to gawk a part of this? How?

IIRC we deliberately switched from using gawk specific features to allow
e.g. mawk to be used. If there is some gawk specific construct used here
it would be better to recast it in more portable terms IMHO.

> - set -e
> + local resp_hex
> + #send cmd to vtpm_manager and get response
> + if ! resp_hex=`echo "$cmd$(str_to_hex32 $inst)" | vtpmmgrtalk `; then

Is this really the command/control interface provided by VTPM? Can we
not work with upstream to define something more usable?

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 18 07:43:55 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Sep 2012 07: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 1TDsT9-0006BZ-Mm; Tue, 18 Sep 2012 07:43:43 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <samuel.thibault@ens-lyon.org>) id 1TDsT8-0006BQ-OC
	for xen-devel@lists.xensource.com; Tue, 18 Sep 2012 07:43:42 +0000
Received: from [85.158.139.83:18071] by server-11.bemta-5.messagelabs.com id
	06/FC-24658-E2628505; Tue, 18 Sep 2012 07:43:42 +0000
X-Env-Sender: samuel.thibault@ens-lyon.org
X-Msg-Ref: server-2.tower-182.messagelabs.com!1347954221!28128582!1
X-Originating-IP: [140.77.166.68]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8603 invoked from network); 18 Sep 2012 07:43:41 -0000
Received: from toccata.ens-lyon.fr (HELO toccata.ens-lyon.org) (140.77.166.68)
	by server-2.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 18 Sep 2012 07:43:41 -0000
Received: from localhost (localhost [127.0.0.1])
	by toccata.ens-lyon.org (Postfix) with ESMTP id E123F8408C;
	Tue, 18 Sep 2012 09:43:40 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at toccata.ens-lyon.org
Received: from toccata.ens-lyon.org ([127.0.0.1])
	by localhost (toccata.ens-lyon.org [127.0.0.1]) (amavisd-new,
	port 10024)
	with ESMTP id G5udnyYUVgrP; Tue, 18 Sep 2012 09:43:40 +0200 (CEST)
Received: from type.ipv6 (youpi.is-a-geek.org [80.67.176.89])
	(using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits))
	(No client certificate requested)
	by toccata.ens-lyon.org (Postfix) with ESMTPSA id 99B1084084;
	Tue, 18 Sep 2012 09:43:40 +0200 (CEST)
Received: from samy by type.ipv6 with local (Exim 4.80)
	(envelope-from <samuel.thibault@ens-lyon.org>)
	id 1TDsT5-0004nn-DT; Tue, 18 Sep 2012 09:43:39 +0200
Date: Tue, 18 Sep 2012 09:43:39 +0200
From: Samuel Thibault <samuel.thibault@ens-lyon.org>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120918074339.GF5110@type.youpi.perso.aquilenet.fr>
Mail-Followup-To: Samuel Thibault <samuel.thibault@ens-lyon.org>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Matthew Fioravante <matthew.fioravante@jhuapl.edu>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
References: <50579D07.3030007@jhuapl.edu>
	<20120917221356.GI5110@type.youpi.perso.aquilenet.fr>
	<1347953450.25803.82.camel@dagon.hellion.org.uk>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1347953450.25803.82.camel@dagon.hellion.org.uk>
User-Agent: Mutt/1.5.21+34 (58baf7c9f32f) (2010-12-30)
Cc: Matthew Fioravante <matthew.fioravante@jhuapl.edu>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH mini-os enhancements for vtpm 4/8] disable
 mfn_is_ram
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell, le Tue 18 Sep 2012 08:30:50 +0100, a =E9crit :
> On Mon, 2012-09-17 at 23:13 +0100, Samuel Thibault wrote:
> > Matthew Fioravante, le Mon 17 Sep 2012 17:58:31 -0400, a =E9crit :
> > > This patch disables the mfn_is_ram check in mini-os. The current check
> > > is insufficient and fails on some systems with larger than 4gb memory.
> =

> How does it fail?

When there is more than 4gb memory, there is IO memory between e.g. 3gb
and 4gb, which will be considered as RAM.

> > And it is only used for checks, not for actual decisions.
> =

> It's made completely useless here though, why not either fix it or
> remove it altogether?

We can probably just remove the check in __do_ioremap, which AFAIK is
the only call.

Samuel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 18 07:43:55 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Sep 2012 07: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 1TDsT9-0006BZ-Mm; Tue, 18 Sep 2012 07:43:43 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <samuel.thibault@ens-lyon.org>) id 1TDsT8-0006BQ-OC
	for xen-devel@lists.xensource.com; Tue, 18 Sep 2012 07:43:42 +0000
Received: from [85.158.139.83:18071] by server-11.bemta-5.messagelabs.com id
	06/FC-24658-E2628505; Tue, 18 Sep 2012 07:43:42 +0000
X-Env-Sender: samuel.thibault@ens-lyon.org
X-Msg-Ref: server-2.tower-182.messagelabs.com!1347954221!28128582!1
X-Originating-IP: [140.77.166.68]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8603 invoked from network); 18 Sep 2012 07:43:41 -0000
Received: from toccata.ens-lyon.fr (HELO toccata.ens-lyon.org) (140.77.166.68)
	by server-2.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 18 Sep 2012 07:43:41 -0000
Received: from localhost (localhost [127.0.0.1])
	by toccata.ens-lyon.org (Postfix) with ESMTP id E123F8408C;
	Tue, 18 Sep 2012 09:43:40 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at toccata.ens-lyon.org
Received: from toccata.ens-lyon.org ([127.0.0.1])
	by localhost (toccata.ens-lyon.org [127.0.0.1]) (amavisd-new,
	port 10024)
	with ESMTP id G5udnyYUVgrP; Tue, 18 Sep 2012 09:43:40 +0200 (CEST)
Received: from type.ipv6 (youpi.is-a-geek.org [80.67.176.89])
	(using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits))
	(No client certificate requested)
	by toccata.ens-lyon.org (Postfix) with ESMTPSA id 99B1084084;
	Tue, 18 Sep 2012 09:43:40 +0200 (CEST)
Received: from samy by type.ipv6 with local (Exim 4.80)
	(envelope-from <samuel.thibault@ens-lyon.org>)
	id 1TDsT5-0004nn-DT; Tue, 18 Sep 2012 09:43:39 +0200
Date: Tue, 18 Sep 2012 09:43:39 +0200
From: Samuel Thibault <samuel.thibault@ens-lyon.org>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120918074339.GF5110@type.youpi.perso.aquilenet.fr>
Mail-Followup-To: Samuel Thibault <samuel.thibault@ens-lyon.org>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Matthew Fioravante <matthew.fioravante@jhuapl.edu>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
References: <50579D07.3030007@jhuapl.edu>
	<20120917221356.GI5110@type.youpi.perso.aquilenet.fr>
	<1347953450.25803.82.camel@dagon.hellion.org.uk>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1347953450.25803.82.camel@dagon.hellion.org.uk>
User-Agent: Mutt/1.5.21+34 (58baf7c9f32f) (2010-12-30)
Cc: Matthew Fioravante <matthew.fioravante@jhuapl.edu>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH mini-os enhancements for vtpm 4/8] disable
 mfn_is_ram
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell, le Tue 18 Sep 2012 08:30:50 +0100, a =E9crit :
> On Mon, 2012-09-17 at 23:13 +0100, Samuel Thibault wrote:
> > Matthew Fioravante, le Mon 17 Sep 2012 17:58:31 -0400, a =E9crit :
> > > This patch disables the mfn_is_ram check in mini-os. The current check
> > > is insufficient and fails on some systems with larger than 4gb memory.
> =

> How does it fail?

When there is more than 4gb memory, there is IO memory between e.g. 3gb
and 4gb, which will be considered as RAM.

> > And it is only used for checks, not for actual decisions.
> =

> It's made completely useless here though, why not either fix it or
> remove it altogether?

We can probably just remove the check in __do_ioremap, which AFAIK is
the only call.

Samuel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 18 07:46:42 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Sep 2012 07:46:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDsVu-0006YM-3o; Tue, 18 Sep 2012 07:46:34 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1TDsVs-0006Y2-V8
	for xen-devel@lists.xen.org; Tue, 18 Sep 2012 07:46:33 +0000
Received: from [85.158.139.83:20432] by server-9.bemta-5.messagelabs.com id
	83/E1-20529-8D628505; Tue, 18 Sep 2012 07:46:32 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1347954391!30958857!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDk2NzI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13037 invoked from network); 18 Sep 2012 07:46:31 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Sep 2012 07:46:31 -0000
X-IronPort-AV: E=Sophos;i="4.80,441,1344211200"; d="scan'208";a="14596743"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Sep 2012 07:46:31 +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.279.1;
	Tue, 18 Sep 2012 08:46:31 +0100
Message-ID: <1347954390.25803.95.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Matt Wilson <msw@amazon.com>
Date: Tue, 18 Sep 2012 08:46:30 +0100
In-Reply-To: <20120917170814.GA22382@u002268147cd4502c336d.ant.amazon.com>
References: <patchbomb.1346992557@u002268147cd4502c336d.ant.amazon.com>
	<3b3582f4dc423daa8040.1346992558@u002268147cd4502c336d.ant.amazon.com>
	<1347874964.14977.34.camel@zakaz.uk.xensource.com>
	<20120917170814.GA22382@u002268147cd4502c336d.ant.amazon.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 1 of 2 v3] tools: check for documentation
 generation tools at configure 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 Mon, 2012-09-17 at 18:08 +0100, Matt Wilson wrote:
> On Mon, Sep 17, 2012 at 10:42:44AM +0100, Ian Campbell wrote:
> >         configure: error: in `/home/xendocs/cronjobs/working/docs/unstable/tree/tools':
> >         configure: error: no acceptable C compiler found in $PATH
> >         See `config.log' for more details
> > 
> > Which is a bit annoying if all you wanted was to build docs. I'm not
> > sure I really want to advocate putting gcc on xenbits. I suppose I could
> > put a dummy shell script in $PATH.
> 
> ./configure is probably going to need a compiler that produces
> executables.

True.

> 
> > AIUI autoconf allows you to define that a configure script calls a
> > sub-configure script. Could we use this at the toplevel to call both
> > tools/configure and a new docs/configure? Then my docs scripts could
> > just call docs/configure?
> 
> This sounds like a better idea.
> 
> > FWIW the unrelated issue was:
> >         $ make -C docs/ clean
> >         /bin/sh: gcc: not found
> >         /bin/sh: arithmetic expression: expecting primary: ""
> > which I think is down to the gcc version check in Config.mk.
> 
> While we're discussing expanding the coverage of ./configure, I
> wonder: what (if any) is the resistance to requiring ./configure to
> build the xen/ tree?

The hypervisor maintainers were pretty much unanimously against it.

There's some discussion in the archives around the time autoconf was
added and even a patch (applied and now reverted IIRC) to do as you
suggest.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 18 07:46:42 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Sep 2012 07:46:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDsVu-0006YM-3o; Tue, 18 Sep 2012 07:46:34 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1TDsVs-0006Y2-V8
	for xen-devel@lists.xen.org; Tue, 18 Sep 2012 07:46:33 +0000
Received: from [85.158.139.83:20432] by server-9.bemta-5.messagelabs.com id
	83/E1-20529-8D628505; Tue, 18 Sep 2012 07:46:32 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1347954391!30958857!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDk2NzI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13037 invoked from network); 18 Sep 2012 07:46:31 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Sep 2012 07:46:31 -0000
X-IronPort-AV: E=Sophos;i="4.80,441,1344211200"; d="scan'208";a="14596743"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Sep 2012 07:46:31 +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.279.1;
	Tue, 18 Sep 2012 08:46:31 +0100
Message-ID: <1347954390.25803.95.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Matt Wilson <msw@amazon.com>
Date: Tue, 18 Sep 2012 08:46:30 +0100
In-Reply-To: <20120917170814.GA22382@u002268147cd4502c336d.ant.amazon.com>
References: <patchbomb.1346992557@u002268147cd4502c336d.ant.amazon.com>
	<3b3582f4dc423daa8040.1346992558@u002268147cd4502c336d.ant.amazon.com>
	<1347874964.14977.34.camel@zakaz.uk.xensource.com>
	<20120917170814.GA22382@u002268147cd4502c336d.ant.amazon.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 1 of 2 v3] tools: check for documentation
 generation tools at configure 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 Mon, 2012-09-17 at 18:08 +0100, Matt Wilson wrote:
> On Mon, Sep 17, 2012 at 10:42:44AM +0100, Ian Campbell wrote:
> >         configure: error: in `/home/xendocs/cronjobs/working/docs/unstable/tree/tools':
> >         configure: error: no acceptable C compiler found in $PATH
> >         See `config.log' for more details
> > 
> > Which is a bit annoying if all you wanted was to build docs. I'm not
> > sure I really want to advocate putting gcc on xenbits. I suppose I could
> > put a dummy shell script in $PATH.
> 
> ./configure is probably going to need a compiler that produces
> executables.

True.

> 
> > AIUI autoconf allows you to define that a configure script calls a
> > sub-configure script. Could we use this at the toplevel to call both
> > tools/configure and a new docs/configure? Then my docs scripts could
> > just call docs/configure?
> 
> This sounds like a better idea.
> 
> > FWIW the unrelated issue was:
> >         $ make -C docs/ clean
> >         /bin/sh: gcc: not found
> >         /bin/sh: arithmetic expression: expecting primary: ""
> > which I think is down to the gcc version check in Config.mk.
> 
> While we're discussing expanding the coverage of ./configure, I
> wonder: what (if any) is the resistance to requiring ./configure to
> build the xen/ tree?

The hypervisor maintainers were pretty much unanimously against it.

There's some discussion in the archives around the time autoconf was
added and even a patch (applied and now reverted IIRC) to do as you
suggest.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 18 07:47:59 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Sep 2012 07: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 1TDsX8-0006jv-Jn; Tue, 18 Sep 2012 07:47:50 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <samuel.thibault@ens-lyon.org>) id 1TDsX6-0006jY-R6
	for xen-devel@lists.xensource.com; Tue, 18 Sep 2012 07:47:49 +0000
Received: from [85.158.139.211:43912] by server-10.bemta-5.messagelabs.com id
	33/4C-10969-42728505; Tue, 18 Sep 2012 07:47:48 +0000
X-Env-Sender: samuel.thibault@ens-lyon.org
X-Msg-Ref: server-6.tower-206.messagelabs.com!1347954467!18976593!1
X-Originating-IP: [140.77.166.68]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7082 invoked from network); 18 Sep 2012 07:47:47 -0000
Received: from toccata.ens-lyon.fr (HELO toccata.ens-lyon.org) (140.77.166.68)
	by server-6.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 18 Sep 2012 07:47:47 -0000
Received: from localhost (localhost [127.0.0.1])
	by toccata.ens-lyon.org (Postfix) with ESMTP id D29558408C;
	Tue, 18 Sep 2012 09:47:46 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at toccata.ens-lyon.org
Received: from toccata.ens-lyon.org ([127.0.0.1])
	by localhost (toccata.ens-lyon.org [127.0.0.1]) (amavisd-new,
	port 10024)
	with ESMTP id YTvTUl-GoJwn; Tue, 18 Sep 2012 09:47:46 +0200 (CEST)
Received: from type.ipv6 (youpi.is-a-geek.org [80.67.176.89])
	(using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits))
	(No client certificate requested)
	by toccata.ens-lyon.org (Postfix) with ESMTPSA id 7248D84088;
	Tue, 18 Sep 2012 09:47:46 +0200 (CEST)
Received: from samy by type.ipv6 with local (Exim 4.80)
	(envelope-from <samuel.thibault@ens-lyon.org>)
	id 1TDsX3-0004rl-5J; Tue, 18 Sep 2012 09:47:45 +0200
Date: Tue, 18 Sep 2012 09:47:45 +0200
From: Samuel Thibault <samuel.thibault@ens-lyon.org>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120918074745.GG5110@type.youpi.perso.aquilenet.fr>
Mail-Followup-To: Samuel Thibault <samuel.thibault@ens-lyon.org>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Matthew Fioravante <matthew.fioravante@jhuapl.edu>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
References: <50579E7F.1050803@jhuapl.edu>
	<1347952878.25803.76.camel@dagon.hellion.org.uk>
	<20120918073114.GE5110@type.youpi.perso.aquilenet.fr>
	<1347953903.25803.88.camel@dagon.hellion.org.uk>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1347953903.25803.88.camel@dagon.hellion.org.uk>
User-Agent: Mutt/1.5.21+34 (58baf7c9f32f) (2010-12-30)
Cc: Matthew Fioravante <matthew.fioravante@jhuapl.edu>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH mini-os enhancements for vtpm 7/8] add
 floating point and sse to mini-os
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell, le Tue 18 Sep 2012 08:38:23 +0100, a =E9crit :
> On Tue, 2012-09-18 at 08:31 +0100, Samuel Thibault wrote:
> > Ian Campbell, le Tue 18 Sep 2012 08:21:18 +0100, a =E9crit :
> > > On Mon, 2012-09-17 at 23:04 +0100, Matthew Fioravante wrote:
> > > > This patch adds floating point and sse support to mini-os by
> > > > initializing the floating point unit and the see unit during domain=
 boot up.
> > > > =

> > > > =

> > > > Signed of by: Matthew Fioravante matthew.fioravante@jhuapl.edu
> > > > =

> > > > diff --git a/extras/mini-os/arch/x86/setup.c
> > > > b/extras/mini-os/arch/x86/setup.c
> > > > --- a/extras/mini-os/arch/x86/setup.c
> > > > +++ b/extras/mini-os/arch/x86/setup.c
> > > > @@ -74,9 +74,28 @@ shared_info_t *map_shared_info(unsigned long pa)
> > > >      return (shared_info_t *)shared_info;
> > > >  }
> > > >  =

> > > > +static inline void fpu_init(void) {
> > > > +    asm volatile("fninit");
> > > > +}
> > > > +
> > > > +#ifdef __SSE__
> > > =

> > > How and when is this symbol defined?
> > =

> > This is defined by the compiler if some -msse is enabled. This is the
> > default on i686/x86_64 at least.
> =

> Do we support processors/compilers without SSE or conversely do we
> require SSE support?
> =

> It sounds like either we need a runtime test or the compile time test is
> unnecessary.

If the code is compiled with -msse (and thus __SSE__ defined), the
compiler itself can emit sse code, so a runtime test will not be enough
to avoid a crash on a non-sse machine.

The compile test is however not strictly needed since the code is
provided in assembly. And it might be useful to enable sse anyway in
case some -msse code gets pulled. IIRC we only support SSE machines, but
I'm not 100% sure.

Samuel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 18 07:47:59 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Sep 2012 07: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 1TDsX8-0006jv-Jn; Tue, 18 Sep 2012 07:47:50 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <samuel.thibault@ens-lyon.org>) id 1TDsX6-0006jY-R6
	for xen-devel@lists.xensource.com; Tue, 18 Sep 2012 07:47:49 +0000
Received: from [85.158.139.211:43912] by server-10.bemta-5.messagelabs.com id
	33/4C-10969-42728505; Tue, 18 Sep 2012 07:47:48 +0000
X-Env-Sender: samuel.thibault@ens-lyon.org
X-Msg-Ref: server-6.tower-206.messagelabs.com!1347954467!18976593!1
X-Originating-IP: [140.77.166.68]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7082 invoked from network); 18 Sep 2012 07:47:47 -0000
Received: from toccata.ens-lyon.fr (HELO toccata.ens-lyon.org) (140.77.166.68)
	by server-6.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 18 Sep 2012 07:47:47 -0000
Received: from localhost (localhost [127.0.0.1])
	by toccata.ens-lyon.org (Postfix) with ESMTP id D29558408C;
	Tue, 18 Sep 2012 09:47:46 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at toccata.ens-lyon.org
Received: from toccata.ens-lyon.org ([127.0.0.1])
	by localhost (toccata.ens-lyon.org [127.0.0.1]) (amavisd-new,
	port 10024)
	with ESMTP id YTvTUl-GoJwn; Tue, 18 Sep 2012 09:47:46 +0200 (CEST)
Received: from type.ipv6 (youpi.is-a-geek.org [80.67.176.89])
	(using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits))
	(No client certificate requested)
	by toccata.ens-lyon.org (Postfix) with ESMTPSA id 7248D84088;
	Tue, 18 Sep 2012 09:47:46 +0200 (CEST)
Received: from samy by type.ipv6 with local (Exim 4.80)
	(envelope-from <samuel.thibault@ens-lyon.org>)
	id 1TDsX3-0004rl-5J; Tue, 18 Sep 2012 09:47:45 +0200
Date: Tue, 18 Sep 2012 09:47:45 +0200
From: Samuel Thibault <samuel.thibault@ens-lyon.org>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120918074745.GG5110@type.youpi.perso.aquilenet.fr>
Mail-Followup-To: Samuel Thibault <samuel.thibault@ens-lyon.org>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Matthew Fioravante <matthew.fioravante@jhuapl.edu>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
References: <50579E7F.1050803@jhuapl.edu>
	<1347952878.25803.76.camel@dagon.hellion.org.uk>
	<20120918073114.GE5110@type.youpi.perso.aquilenet.fr>
	<1347953903.25803.88.camel@dagon.hellion.org.uk>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1347953903.25803.88.camel@dagon.hellion.org.uk>
User-Agent: Mutt/1.5.21+34 (58baf7c9f32f) (2010-12-30)
Cc: Matthew Fioravante <matthew.fioravante@jhuapl.edu>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH mini-os enhancements for vtpm 7/8] add
 floating point and sse to mini-os
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell, le Tue 18 Sep 2012 08:38:23 +0100, a =E9crit :
> On Tue, 2012-09-18 at 08:31 +0100, Samuel Thibault wrote:
> > Ian Campbell, le Tue 18 Sep 2012 08:21:18 +0100, a =E9crit :
> > > On Mon, 2012-09-17 at 23:04 +0100, Matthew Fioravante wrote:
> > > > This patch adds floating point and sse support to mini-os by
> > > > initializing the floating point unit and the see unit during domain=
 boot up.
> > > > =

> > > > =

> > > > Signed of by: Matthew Fioravante matthew.fioravante@jhuapl.edu
> > > > =

> > > > diff --git a/extras/mini-os/arch/x86/setup.c
> > > > b/extras/mini-os/arch/x86/setup.c
> > > > --- a/extras/mini-os/arch/x86/setup.c
> > > > +++ b/extras/mini-os/arch/x86/setup.c
> > > > @@ -74,9 +74,28 @@ shared_info_t *map_shared_info(unsigned long pa)
> > > >      return (shared_info_t *)shared_info;
> > > >  }
> > > >  =

> > > > +static inline void fpu_init(void) {
> > > > +    asm volatile("fninit");
> > > > +}
> > > > +
> > > > +#ifdef __SSE__
> > > =

> > > How and when is this symbol defined?
> > =

> > This is defined by the compiler if some -msse is enabled. This is the
> > default on i686/x86_64 at least.
> =

> Do we support processors/compilers without SSE or conversely do we
> require SSE support?
> =

> It sounds like either we need a runtime test or the compile time test is
> unnecessary.

If the code is compiled with -msse (and thus __SSE__ defined), the
compiler itself can emit sse code, so a runtime test will not be enough
to avoid a crash on a non-sse machine.

The compile test is however not strictly needed since the code is
provided in assembly. And it might be useful to enable sse anyway in
case some -msse code gets pulled. IIRC we only support SSE machines, but
I'm not 100% sure.

Samuel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 18 08:19:01 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Sep 2012 08:19: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 1TDt15-0007hB-At; Tue, 18 Sep 2012 08:18: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 1TDt14-0007h5-2a
	for xen-devel@lists.xensource.com; Tue, 18 Sep 2012 08:18:46 +0000
Received: from [85.158.143.35:49643] by server-3.bemta-4.messagelabs.com id
	B0/D8-08232-56E28505; Tue, 18 Sep 2012 08:18:45 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1347956322!15480551!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDk2NzI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23030 invoked from network); 18 Sep 2012 08:18:42 -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;
	18 Sep 2012 08:18:42 -0000
X-IronPort-AV: E=Sophos;i="4.80,441,1344211200"; d="scan'208";a="14597652"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Sep 2012 08:17: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.279.1; Tue, 18 Sep 2012 09:17: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 1TDt0H-0001oM-Ii;
	Tue, 18 Sep 2012 08:17:57 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1TDt0H-00078Q-I3;
	Tue, 18 Sep 2012 09:17:57 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-13802-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Tue, 18 Sep 2012 09:17:57 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13802: 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 13802 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13802/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore            fail   like 13799
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail like 13799
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail like 13799

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  d1c3375c3f11
baseline version:
 xen                  3bf63fcfacd1

------------------------------------------------------------
People who touched revisions under test:
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  Christoph Egger <Christoph.Egger@amd.com>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Gang Wei <gang.wei@intel.com>
  Ian Campbell <ian.campbell@citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Jiongxi Li <jiongxi.li@intel.com>
  Keir Fraser <keir@xen.org>
  Steven Maresca <steve@zentific.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-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-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-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-amd64-amd64-xl-win                                      fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=xen-unstable
+ revision=d1c3375c3f11
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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 d1c3375c3f11
+ branch=xen-unstable
+ revision=d1c3375c3f11
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-unstable
+ '[' xxen = xlinux ']'
+ linuxbranch=linux
+ : master
+ : tested/2.6.39.x
+ . ap-common
++ : xen@xenbits.xensource.com
++ : http://xenbits.xen.org/hg/staging/xen-unstable.hg
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : xen@xenbits.xensource.com:git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.xen-unstable
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-unstable.git
++ : daily-cron.xen-unstable
+ TREE_LINUX=xen@xenbits.xensource.com:git/linux-pvops.git
+ TREE_QEMU_UPSTREAM=xen@xenbits.xensource.com:git/qemu-upstream-unstable.git
+ info_linux_tree xen-unstable
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/xen-unstable.hg
+ hg push -r d1c3375c3f11 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 9 changesets with 46 changes to 35 files

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 18 08:19:01 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Sep 2012 08:19: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 1TDt15-0007hB-At; Tue, 18 Sep 2012 08:18: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 1TDt14-0007h5-2a
	for xen-devel@lists.xensource.com; Tue, 18 Sep 2012 08:18:46 +0000
Received: from [85.158.143.35:49643] by server-3.bemta-4.messagelabs.com id
	B0/D8-08232-56E28505; Tue, 18 Sep 2012 08:18:45 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1347956322!15480551!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDk2NzI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23030 invoked from network); 18 Sep 2012 08:18:42 -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;
	18 Sep 2012 08:18:42 -0000
X-IronPort-AV: E=Sophos;i="4.80,441,1344211200"; d="scan'208";a="14597652"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Sep 2012 08:17: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.279.1; Tue, 18 Sep 2012 09:17: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 1TDt0H-0001oM-Ii;
	Tue, 18 Sep 2012 08:17:57 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1TDt0H-00078Q-I3;
	Tue, 18 Sep 2012 09:17:57 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-13802-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Tue, 18 Sep 2012 09:17:57 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13802: 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 13802 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13802/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore            fail   like 13799
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail like 13799
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail like 13799

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  d1c3375c3f11
baseline version:
 xen                  3bf63fcfacd1

------------------------------------------------------------
People who touched revisions under test:
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  Christoph Egger <Christoph.Egger@amd.com>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Gang Wei <gang.wei@intel.com>
  Ian Campbell <ian.campbell@citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Jiongxi Li <jiongxi.li@intel.com>
  Keir Fraser <keir@xen.org>
  Steven Maresca <steve@zentific.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-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-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-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-amd64-amd64-xl-win                                      fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=xen-unstable
+ revision=d1c3375c3f11
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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 d1c3375c3f11
+ branch=xen-unstable
+ revision=d1c3375c3f11
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-unstable
+ '[' xxen = xlinux ']'
+ linuxbranch=linux
+ : master
+ : tested/2.6.39.x
+ . ap-common
++ : xen@xenbits.xensource.com
++ : http://xenbits.xen.org/hg/staging/xen-unstable.hg
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : xen@xenbits.xensource.com:git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.xen-unstable
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-unstable.git
++ : daily-cron.xen-unstable
+ TREE_LINUX=xen@xenbits.xensource.com:git/linux-pvops.git
+ TREE_QEMU_UPSTREAM=xen@xenbits.xensource.com:git/qemu-upstream-unstable.git
+ info_linux_tree xen-unstable
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/xen-unstable.hg
+ hg push -r d1c3375c3f11 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 9 changesets with 46 changes to 35 files

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 18 08:25:25 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Sep 2012 08: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 1TDt7E-00088H-7I; Tue, 18 Sep 2012 08:25:08 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wdauchy@gmail.com>) id 1TDt7D-00088A-4S
	for xen-devel@lists.xensource.com; Tue, 18 Sep 2012 08:25:07 +0000
Received: from [85.158.139.211:11833] by server-9.bemta-5.messagelabs.com id
	3A/DC-20529-2EF28505; Tue, 18 Sep 2012 08:25:06 +0000
X-Env-Sender: wdauchy@gmail.com
X-Msg-Ref: server-8.tower-206.messagelabs.com!1347956702!18956350!1
X-Originating-IP: [209.85.160.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30371 invoked from network); 18 Sep 2012 08:25:04 -0000
Received: from mail-pb0-f43.google.com (HELO mail-pb0-f43.google.com)
	(209.85.160.43)
	by server-8.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Sep 2012 08:25:04 -0000
Received: by pbbrq2 with SMTP id rq2so13478100pbb.30
	for <xen-devel@lists.xensource.com>;
	Tue, 18 Sep 2012 01:25:02 -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:cc:content-type;
	bh=k0j9XVBV1O+saiX1Es0vLCmBvbIf0casgGalSOWZSlI=;
	b=E3ExTHGCYGJc9+y0CMetdmZczsJGgV7Zjq8n8UjDrg6SqJN48Gr3chyBmrzpLOl1A6
	IGHA6+wb+JhGO88jK0z+V4pdT3CPNqLB8MCYWJM2SyNQ8hWE0BBkevIWeFL/9jih9BYv
	/Cg6gtGv3V19eI949NqReEK6X7bIty9ioZkvlfK50UOsHpDOWMqb+BqrdeamXHBPv7Fj
	VuijnM737YsBbwsey5Ouq+x77akTZazJgaoroUvfFOFX8vp35rbVNVXNRTJA2o6yuVQP
	RJxcrI6jSborLJQAUA3Yd9lze/MPL7th3TYOk6yaBRh4jcxz06oCUNBtUO2on6Y415Ai
	xiwg==
Received: by 10.68.224.161 with SMTP id rd1mr28111400pbc.133.1347956702547;
	Tue, 18 Sep 2012 01:25:02 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.68.135.42 with HTTP; Tue, 18 Sep 2012 01:24:42 -0700 (PDT)
From: William Dauchy <wdauchy@gmail.com>
Date: Tue, 18 Sep 2012 10:24:42 +0200
Message-ID: <CAJ75kXZm-BqWdL2O41XkSE1VCdd4ruW=+CqDmR1b3=701RnXmw@mail.gmail.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: xen-devel@lists.xensource.com
Subject: [Xen-devel] Error getting mfn
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hello,

I'm getting many "Error getting mfn" on a xen4.1.3 with dom0 3.4.11 x86_32.
I thought it could be related to
xen/mmu: Release just the MFN list, not MFN list and part of pagetables.
http://git.kernel.org/?p=linux/kernel/git/konrad/xen.git;a=commit;h=785f62314984ea3af9dd830b020289ba2509ae69

(XEN) Freed 212kB init memory.
(XEN) mm.c:908:d0 Error getting mfn 2009b (pfn 5555555555555555) from
L1 entry 000000002009b023 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn 2009c (pfn 5555555555555555) from
L1 entry 000000002009c023 for l1e_owner=0, pg_owner=0
[...]
(XEN) mm.c:908:d0 Error getting mfn c32116 (pfn 5555555555555555) from
L1 entry 8000000c32116063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32117 (pfn 5555555555555555) from
L1 entry 8000000c32117063 for l1e_owner=0, pg_owner=0
(XEN) ../physdev.c:171: dom0: wrong map_pirq type 3

Any hint?

Regards,
-- 
William

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 18 08:25:25 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Sep 2012 08: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 1TDt7E-00088H-7I; Tue, 18 Sep 2012 08:25:08 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wdauchy@gmail.com>) id 1TDt7D-00088A-4S
	for xen-devel@lists.xensource.com; Tue, 18 Sep 2012 08:25:07 +0000
Received: from [85.158.139.211:11833] by server-9.bemta-5.messagelabs.com id
	3A/DC-20529-2EF28505; Tue, 18 Sep 2012 08:25:06 +0000
X-Env-Sender: wdauchy@gmail.com
X-Msg-Ref: server-8.tower-206.messagelabs.com!1347956702!18956350!1
X-Originating-IP: [209.85.160.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30371 invoked from network); 18 Sep 2012 08:25:04 -0000
Received: from mail-pb0-f43.google.com (HELO mail-pb0-f43.google.com)
	(209.85.160.43)
	by server-8.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Sep 2012 08:25:04 -0000
Received: by pbbrq2 with SMTP id rq2so13478100pbb.30
	for <xen-devel@lists.xensource.com>;
	Tue, 18 Sep 2012 01:25:02 -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:cc:content-type;
	bh=k0j9XVBV1O+saiX1Es0vLCmBvbIf0casgGalSOWZSlI=;
	b=E3ExTHGCYGJc9+y0CMetdmZczsJGgV7Zjq8n8UjDrg6SqJN48Gr3chyBmrzpLOl1A6
	IGHA6+wb+JhGO88jK0z+V4pdT3CPNqLB8MCYWJM2SyNQ8hWE0BBkevIWeFL/9jih9BYv
	/Cg6gtGv3V19eI949NqReEK6X7bIty9ioZkvlfK50UOsHpDOWMqb+BqrdeamXHBPv7Fj
	VuijnM737YsBbwsey5Ouq+x77akTZazJgaoroUvfFOFX8vp35rbVNVXNRTJA2o6yuVQP
	RJxcrI6jSborLJQAUA3Yd9lze/MPL7th3TYOk6yaBRh4jcxz06oCUNBtUO2on6Y415Ai
	xiwg==
Received: by 10.68.224.161 with SMTP id rd1mr28111400pbc.133.1347956702547;
	Tue, 18 Sep 2012 01:25:02 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.68.135.42 with HTTP; Tue, 18 Sep 2012 01:24:42 -0700 (PDT)
From: William Dauchy <wdauchy@gmail.com>
Date: Tue, 18 Sep 2012 10:24:42 +0200
Message-ID: <CAJ75kXZm-BqWdL2O41XkSE1VCdd4ruW=+CqDmR1b3=701RnXmw@mail.gmail.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: xen-devel@lists.xensource.com
Subject: [Xen-devel] Error getting mfn
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hello,

I'm getting many "Error getting mfn" on a xen4.1.3 with dom0 3.4.11 x86_32.
I thought it could be related to
xen/mmu: Release just the MFN list, not MFN list and part of pagetables.
http://git.kernel.org/?p=linux/kernel/git/konrad/xen.git;a=commit;h=785f62314984ea3af9dd830b020289ba2509ae69

(XEN) Freed 212kB init memory.
(XEN) mm.c:908:d0 Error getting mfn 2009b (pfn 5555555555555555) from
L1 entry 000000002009b023 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn 2009c (pfn 5555555555555555) from
L1 entry 000000002009c023 for l1e_owner=0, pg_owner=0
[...]
(XEN) mm.c:908:d0 Error getting mfn c32116 (pfn 5555555555555555) from
L1 entry 8000000c32116063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32117 (pfn 5555555555555555) from
L1 entry 8000000c32117063 for l1e_owner=0, pg_owner=0
(XEN) ../physdev.c:171: dom0: wrong map_pirq type 3

Any hint?

Regards,
-- 
William

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 18 08:42:29 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Sep 2012 08: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 1TDtNg-0008NN-2m; Tue, 18 Sep 2012 08:42:08 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jmarcet@gmail.com>) id 1TDtNe-0008NI-TQ
	for xen-devel@lists.xen.org; Tue, 18 Sep 2012 08:42:07 +0000
Received: from [85.158.139.83:48042] by server-11.bemta-5.messagelabs.com id
	FA/A1-24658-BD338505; Tue, 18 Sep 2012 08:42:03 +0000
X-Env-Sender: jmarcet@gmail.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1347957718!28140324!1
X-Originating-IP: [209.85.219.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13928 invoked from network); 18 Sep 2012 08:41:59 -0000
Received: from mail-oa0-f45.google.com (HELO mail-oa0-f45.google.com)
	(209.85.219.45)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Sep 2012 08:41:59 -0000
Received: by oagn12 with SMTP id n12so7228644oag.32
	for <xen-devel@lists.xen.org>; Tue, 18 Sep 2012 01:41:57 -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=dWX2E0t5Nvmzlz8DR/NkLH4UqBV8srhI0SLg1rcClUM=;
	b=Mupw/RmBS1UXu77amNpAPMQ332FI1GTJHgf/8YRRJbA7bn2nZu9ivPlc/HVEr2Epep
	4amvsl67AsUpdrOIojV4zIK4EN2mkPYZObsnhKXqt4qGG/6t2yYCbn/nrE5EssbLizKl
	+1ZumUNV7gwG0kdtMY0/fnEY0RrZCMxDTQMhSAWPYxZ2jt/9/SSXiLMqHmlXzi7mEFJ6
	zUVxtS2EQU8Tdm233k4b/cRfqaeMw1JIs1AiHnIJ9F5rNoi7V8t/nVNETV0spNUIGwkI
	SI3ogd1FJJ66kSNOfR0zO7YDRNbNWdix69IQCYm/6qdDRrAIgwVdcayqK1Bv8N2Orghf
	fsFg==
Received: by 10.60.22.103 with SMTP id c7mr13995660oef.75.1347957717747; Tue,
	18 Sep 2012 01:41:57 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.60.138.225 with HTTP; Tue, 18 Sep 2012 01:41:37 -0700 (PDT)
In-Reply-To: <CAAnFQG9s=Yh4od18q8xDOD7ukA4uurxCKWiLrULFkP66Zc+iPg@mail.gmail.com>
References: <CAAnFQG9TZj=SxYK_jxqN=M6L40vL=AZu9EM2tbEffPhkL1s8FA@mail.gmail.com>
	<CACJDEmqdqA6CE9SgLL2QCNmQH1dOX0_4OHfJfzes+G6bEkQ7FA@mail.gmail.com>
	<CAAnFQG-8Fkunv6R8+GCLAH4yQCx4-Nn0zN_Ntsf0wsh5yXeihQ@mail.gmail.com>
	<20120917142851.GB14012@phenom.dumpdata.com>
	<CAAnFQG9bUUU8OBeKxYh=O3rRrnEPb4r1bPCr-EHWHuUS8shBhA@mail.gmail.com>
	<CAAnFQG_VnZOYs3SJvO1Gc8P98kOW=6Wxc7tM_vEF8GiACgeVWg@mail.gmail.com>
	<CAAnFQG9s=Yh4od18q8xDOD7ukA4uurxCKWiLrULFkP66Zc+iPg@mail.gmail.com>
From: Javier Marcet <jmarcet@gmail.com>
Date: Tue, 18 Sep 2012 10:41:37 +0200
Message-ID: <CAAnFQG9PuzRLSsCS8m_0VUeV+ZaCwK3zsbinxtuFBfdSihJknw@mail.gmail.com>
To: Konrad Rzeszutek Wilk <konrad@kernel.org>
Cc: Xen Devel Mailing list <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.2.0-rc4 issues with DVB tuner
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gVHVlLCBTZXAgMTgsIDIwMTIgYXQgMjowOCBBTSwgSmF2aWVyIE1hcmNldCA8am1hcmNldEBn
bWFpbC5jb20+IHdyb3RlOgoKSGksCgo+IFN0aWxsIG5vdGhpbmcuIE5vdCBldmVuIGVuYWJsaW5n
IHRoZSBkZWJ1ZyBvcHRpb25zIHdpdGhpbiB0aGUgRFZCCj4gc3Vic3lzdGVtIEkgZ2V0Cj4gYW55
dGhpbmcgd2hpY2ggZG9lc24ndCBsb29rIHBlcmZlY3RseSBub3JtYWwsIGV4YWN0bHkgbGlrZSB3
aGVuIGl0J3MKPiB3b3JraW5nIGZpbmUuCj4KPiBJIGhhdmUganVzdCBwb3N0ZWQgYSBtZXNzYWdl
IG9uIHRoZSBsaW51eCBtZWRpYSBtYWlsaW5nIGxpc3QgbG9va2luZwo+IGZvciBzb21lIGhlbHAK
PiBmcm9tIHRoZSBkdmIgbWFpbnRhaW5lcnMuCgpJIGhhdmUgc29tZSBuZXdzIGZyb20gdGhlIGxp
bnV4LW1lZGlhIG1haWxpbmcgbGlzdC4gVGhlcmUsIERldmluIEhlaXRtdWVsbGVyLApzYWlkIHRo
aXM6CgoiIiIKPiBJbml0aWFsbHkgSSB0aG91Z2h0IFhlbiB3b3VsZCBiZSB0aGUgY2F1c2Ugb2Yg
dGhlIHByb2JsZW0sIGJ1dCBhZnRlcgo+IGhhdmluZyB3cml0dGVuIG9uCj4gdGhlIFhlbiBkZXZl
bG9wbWVudCBtYWlsaW5nIGxpc3QgYW5kIHRhbGtlZCBhYm91dCBpdCB3aXRoIGEgY291cGxlCj4g
ZGV2ZWxvcGVycywgaXQgaXNuJ3QKPiB2ZXJ5IGNsZWFyIHdoZXJlIHRoZSBwcm9ibGVtIGlzLiBT
byBmYXIgSSBoYXZlbid0IGJlZW4gYWJsZSB0byBnZXQgdGhlCj4gc21hbGxlc3Qgd2FybmluZwo+
IG9yIGVycm9yLgoKVGhpcyBpcyBhIHZlcnkgY29tbW9uIHByb2JsZW0gd2hlbiBhdHRlbXB0aW5n
IHRvIHVzZSBhbnkgUENJL1BDSWUKdHVuZXIgdW5kZXIgYSBoeXBlcnZpc29yLiAgRXNzZW50aWFs
bHkgdGhlIGlzc3VlIGlzIGFsbCBvZiB0aGUKdmlydHVhbGl6YXRpb24gc29sdXRpb25zIHByb3Zp
ZGUgdmVyeSBwb29yIGludGVycnVwdCBsYXRlbmN5LCB3aGljaApyZXN1bHRzIGluIHRoZSBkYXRh
IGJlaW5nIGxvc3QuCgpEZXZpY2VzIGRlbGl2ZXJpbmcgYSBoaWdoIGJpdHJhdGUgc3RyZWFtIG9m
IGRhdGEgaW4gcmVhbHRpbWUgYXJlIG11Y2gKbW9yZSBsaWtlbHkgZm9yIHRoaXMgcHJvYmxlbSB0
byBiZSB2aXNpYmxlIHNpbmNlIHN1Y2ggZGV2aWNlcyBoYXZlCnZlcnkgbGl0dGxlIGJ1ZmZlcmlu
ZyAoaXQncyBub3QgbGlrZSBhIGhhcmQgZHJpdmUgY29udHJvbGxlciB3aGVyZSBpdApjYW4ganVz
dCBkZWxpdmVyIHRoZSBkYXRhIHNsb3dlcikuICBUaGUgcHJvYmxlbSBpcyBub3Qgc3BlY2lmaWMg
dG8gdGhlCmN4MjM4ODUgLSBwcmV0dHkgbXVjaCBhbGwgb2YgdGhlIFBDSS9QQ0llIGJyaWRnZXMg
dXNlZCBpbiB0dW5lciBjYXJkcwp3b3JrIHRoaXMgd2F5LCBhbmQgdGhleSBjYW5ub3QgcmVhbGx5
IGJlIGJsYW1lZCBmb3IgZXhwZWN0aW5nIHRvIHJ1bgppbiBhbiBlbnZpcm9ubWVudCB3aXRoIHJl
YWxseSBjcmFwcHkgaW50ZXJydXB0IGxhdGVuY3kuCgpJIHdvbid0IGdvIGFzIGZhciBhcyB0byBz
YXksICJhYmFuZG9uIGFsbCBob3BlIiwgYnV0IHlvdSdyZSBub3QgcmVhbGx5Cmxpa2VseSB0byBm
aW5kIGFueSBoZWxwIGluIHRoaXMgZm9ydW0uCiIiIgoKV2hhdCBJIGRvbsK0dCB1bmRlcnN0YW5k
IGlzIGhvdyBncmFwaGljcyBwYXNzIHRocm91Z2ggZXZlbiB3b3JrcwphbmQgYSB0dW5lciBjYXJk
IGhhcyBwcm9ibGVtcyBkdWUgdG8gdGhlIGludHJvZHVjZWQgbGF0ZW5jaWVzIGluIHRoZQpJUlFz
LgoKRG8geW91IGhhdmUgYW55IG1vcmUgaW5mbyBhYm91dCB0aGlzPwoKCi0tIApKYXZpZXIgTWFy
Y2V0IDxqbWFyY2V0QGdtYWlsLmNvbT4KCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhl
bi5vcmcKaHR0cDovL2xpc3RzLnhlbi5vcmcveGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Tue Sep 18 08:42:29 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Sep 2012 08: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 1TDtNg-0008NN-2m; Tue, 18 Sep 2012 08:42:08 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jmarcet@gmail.com>) id 1TDtNe-0008NI-TQ
	for xen-devel@lists.xen.org; Tue, 18 Sep 2012 08:42:07 +0000
Received: from [85.158.139.83:48042] by server-11.bemta-5.messagelabs.com id
	FA/A1-24658-BD338505; Tue, 18 Sep 2012 08:42:03 +0000
X-Env-Sender: jmarcet@gmail.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1347957718!28140324!1
X-Originating-IP: [209.85.219.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13928 invoked from network); 18 Sep 2012 08:41:59 -0000
Received: from mail-oa0-f45.google.com (HELO mail-oa0-f45.google.com)
	(209.85.219.45)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Sep 2012 08:41:59 -0000
Received: by oagn12 with SMTP id n12so7228644oag.32
	for <xen-devel@lists.xen.org>; Tue, 18 Sep 2012 01:41:57 -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=dWX2E0t5Nvmzlz8DR/NkLH4UqBV8srhI0SLg1rcClUM=;
	b=Mupw/RmBS1UXu77amNpAPMQ332FI1GTJHgf/8YRRJbA7bn2nZu9ivPlc/HVEr2Epep
	4amvsl67AsUpdrOIojV4zIK4EN2mkPYZObsnhKXqt4qGG/6t2yYCbn/nrE5EssbLizKl
	+1ZumUNV7gwG0kdtMY0/fnEY0RrZCMxDTQMhSAWPYxZ2jt/9/SSXiLMqHmlXzi7mEFJ6
	zUVxtS2EQU8Tdm233k4b/cRfqaeMw1JIs1AiHnIJ9F5rNoi7V8t/nVNETV0spNUIGwkI
	SI3ogd1FJJ66kSNOfR0zO7YDRNbNWdix69IQCYm/6qdDRrAIgwVdcayqK1Bv8N2Orghf
	fsFg==
Received: by 10.60.22.103 with SMTP id c7mr13995660oef.75.1347957717747; Tue,
	18 Sep 2012 01:41:57 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.60.138.225 with HTTP; Tue, 18 Sep 2012 01:41:37 -0700 (PDT)
In-Reply-To: <CAAnFQG9s=Yh4od18q8xDOD7ukA4uurxCKWiLrULFkP66Zc+iPg@mail.gmail.com>
References: <CAAnFQG9TZj=SxYK_jxqN=M6L40vL=AZu9EM2tbEffPhkL1s8FA@mail.gmail.com>
	<CACJDEmqdqA6CE9SgLL2QCNmQH1dOX0_4OHfJfzes+G6bEkQ7FA@mail.gmail.com>
	<CAAnFQG-8Fkunv6R8+GCLAH4yQCx4-Nn0zN_Ntsf0wsh5yXeihQ@mail.gmail.com>
	<20120917142851.GB14012@phenom.dumpdata.com>
	<CAAnFQG9bUUU8OBeKxYh=O3rRrnEPb4r1bPCr-EHWHuUS8shBhA@mail.gmail.com>
	<CAAnFQG_VnZOYs3SJvO1Gc8P98kOW=6Wxc7tM_vEF8GiACgeVWg@mail.gmail.com>
	<CAAnFQG9s=Yh4od18q8xDOD7ukA4uurxCKWiLrULFkP66Zc+iPg@mail.gmail.com>
From: Javier Marcet <jmarcet@gmail.com>
Date: Tue, 18 Sep 2012 10:41:37 +0200
Message-ID: <CAAnFQG9PuzRLSsCS8m_0VUeV+ZaCwK3zsbinxtuFBfdSihJknw@mail.gmail.com>
To: Konrad Rzeszutek Wilk <konrad@kernel.org>
Cc: Xen Devel Mailing list <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.2.0-rc4 issues with DVB tuner
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gVHVlLCBTZXAgMTgsIDIwMTIgYXQgMjowOCBBTSwgSmF2aWVyIE1hcmNldCA8am1hcmNldEBn
bWFpbC5jb20+IHdyb3RlOgoKSGksCgo+IFN0aWxsIG5vdGhpbmcuIE5vdCBldmVuIGVuYWJsaW5n
IHRoZSBkZWJ1ZyBvcHRpb25zIHdpdGhpbiB0aGUgRFZCCj4gc3Vic3lzdGVtIEkgZ2V0Cj4gYW55
dGhpbmcgd2hpY2ggZG9lc24ndCBsb29rIHBlcmZlY3RseSBub3JtYWwsIGV4YWN0bHkgbGlrZSB3
aGVuIGl0J3MKPiB3b3JraW5nIGZpbmUuCj4KPiBJIGhhdmUganVzdCBwb3N0ZWQgYSBtZXNzYWdl
IG9uIHRoZSBsaW51eCBtZWRpYSBtYWlsaW5nIGxpc3QgbG9va2luZwo+IGZvciBzb21lIGhlbHAK
PiBmcm9tIHRoZSBkdmIgbWFpbnRhaW5lcnMuCgpJIGhhdmUgc29tZSBuZXdzIGZyb20gdGhlIGxp
bnV4LW1lZGlhIG1haWxpbmcgbGlzdC4gVGhlcmUsIERldmluIEhlaXRtdWVsbGVyLApzYWlkIHRo
aXM6CgoiIiIKPiBJbml0aWFsbHkgSSB0aG91Z2h0IFhlbiB3b3VsZCBiZSB0aGUgY2F1c2Ugb2Yg
dGhlIHByb2JsZW0sIGJ1dCBhZnRlcgo+IGhhdmluZyB3cml0dGVuIG9uCj4gdGhlIFhlbiBkZXZl
bG9wbWVudCBtYWlsaW5nIGxpc3QgYW5kIHRhbGtlZCBhYm91dCBpdCB3aXRoIGEgY291cGxlCj4g
ZGV2ZWxvcGVycywgaXQgaXNuJ3QKPiB2ZXJ5IGNsZWFyIHdoZXJlIHRoZSBwcm9ibGVtIGlzLiBT
byBmYXIgSSBoYXZlbid0IGJlZW4gYWJsZSB0byBnZXQgdGhlCj4gc21hbGxlc3Qgd2FybmluZwo+
IG9yIGVycm9yLgoKVGhpcyBpcyBhIHZlcnkgY29tbW9uIHByb2JsZW0gd2hlbiBhdHRlbXB0aW5n
IHRvIHVzZSBhbnkgUENJL1BDSWUKdHVuZXIgdW5kZXIgYSBoeXBlcnZpc29yLiAgRXNzZW50aWFs
bHkgdGhlIGlzc3VlIGlzIGFsbCBvZiB0aGUKdmlydHVhbGl6YXRpb24gc29sdXRpb25zIHByb3Zp
ZGUgdmVyeSBwb29yIGludGVycnVwdCBsYXRlbmN5LCB3aGljaApyZXN1bHRzIGluIHRoZSBkYXRh
IGJlaW5nIGxvc3QuCgpEZXZpY2VzIGRlbGl2ZXJpbmcgYSBoaWdoIGJpdHJhdGUgc3RyZWFtIG9m
IGRhdGEgaW4gcmVhbHRpbWUgYXJlIG11Y2gKbW9yZSBsaWtlbHkgZm9yIHRoaXMgcHJvYmxlbSB0
byBiZSB2aXNpYmxlIHNpbmNlIHN1Y2ggZGV2aWNlcyBoYXZlCnZlcnkgbGl0dGxlIGJ1ZmZlcmlu
ZyAoaXQncyBub3QgbGlrZSBhIGhhcmQgZHJpdmUgY29udHJvbGxlciB3aGVyZSBpdApjYW4ganVz
dCBkZWxpdmVyIHRoZSBkYXRhIHNsb3dlcikuICBUaGUgcHJvYmxlbSBpcyBub3Qgc3BlY2lmaWMg
dG8gdGhlCmN4MjM4ODUgLSBwcmV0dHkgbXVjaCBhbGwgb2YgdGhlIFBDSS9QQ0llIGJyaWRnZXMg
dXNlZCBpbiB0dW5lciBjYXJkcwp3b3JrIHRoaXMgd2F5LCBhbmQgdGhleSBjYW5ub3QgcmVhbGx5
IGJlIGJsYW1lZCBmb3IgZXhwZWN0aW5nIHRvIHJ1bgppbiBhbiBlbnZpcm9ubWVudCB3aXRoIHJl
YWxseSBjcmFwcHkgaW50ZXJydXB0IGxhdGVuY3kuCgpJIHdvbid0IGdvIGFzIGZhciBhcyB0byBz
YXksICJhYmFuZG9uIGFsbCBob3BlIiwgYnV0IHlvdSdyZSBub3QgcmVhbGx5Cmxpa2VseSB0byBm
aW5kIGFueSBoZWxwIGluIHRoaXMgZm9ydW0uCiIiIgoKV2hhdCBJIGRvbsK0dCB1bmRlcnN0YW5k
IGlzIGhvdyBncmFwaGljcyBwYXNzIHRocm91Z2ggZXZlbiB3b3JrcwphbmQgYSB0dW5lciBjYXJk
IGhhcyBwcm9ibGVtcyBkdWUgdG8gdGhlIGludHJvZHVjZWQgbGF0ZW5jaWVzIGluIHRoZQpJUlFz
LgoKRG8geW91IGhhdmUgYW55IG1vcmUgaW5mbyBhYm91dCB0aGlzPwoKCi0tIApKYXZpZXIgTWFy
Y2V0IDxqbWFyY2V0QGdtYWlsLmNvbT4KCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhl
bi5vcmcKaHR0cDovL2xpc3RzLnhlbi5vcmcveGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Tue Sep 18 08:57:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Sep 2012 08: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 1TDtcS-00008U-Ob; Tue, 18 Sep 2012 08:57:24 +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 1TDtcR-00008P-4B
	for xen-devel@lists.xen.org; Tue, 18 Sep 2012 08:57:23 +0000
Received: from [85.158.137.99:48594] by server-10.bemta-3.messagelabs.com id
	07/71-10411-27738505; Tue, 18 Sep 2012 08:57:22 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-2.tower-217.messagelabs.com!1347958641!17997765!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-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9737 invoked from network); 18 Sep 2012 08:57:21 -0000
Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com)
	(74.125.83.45)
	by server-2.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Sep 2012 08:57:21 -0000
Received: by eeke53 with SMTP id e53so3975158eek.32
	for <xen-devel@lists.xen.org>; Tue, 18 Sep 2012 01:57:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=9jISTfByLRw/Jr3DHzCugX6nbqAxwlqzE0PbSpeZENA=;
	b=MYm6UNwaWGYot5MsWlXWaNIuBbmiD+1FFHVkkD7CiYpCvWcg/Yo3v78lo13GHaDUOJ
	64qZX1S139O3CTF3w1jMAadcrNiOpmqZ85gLee39rx5TH7bKJwy6qIwlFaNdd7HS1MB8
	r4ZCTojAvLMbehdNEu+WmelUf89maoyikxRJnJuGTKLIaYnwJXEi6nX0zaDQTMi85Krz
	yGdoG1LHrlrlJVDRM74pr+3jykkVkQd45ZQMEGTBkEXfZ3ZPT16gfGIcsq/eg5e6am8J
	wCUF4RemKbQEik5M1aAtYDGSquQKRkhyT2pNAwsO+m99kGL7ImyJx3RpwPN4oRlZ+d0B
	nzZw==
Received: by 10.14.221.197 with SMTP id r45mr16582794eep.41.1347958641530;
	Tue, 18 Sep 2012 01:57:21 -0700 (PDT)
Received: from [192.168.1.69] (host86-183-251-65.range86-183.btcentralplus.com.
	[86.183.251.65])
	by mx.google.com with ESMTPS id h2sm34496063eeo.3.2012.09.18.01.57.16
	(version=SSLv3 cipher=OTHER); Tue, 18 Sep 2012 01:57:20 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Tue, 18 Sep 2012 09:57:11 +0100
From: Keir Fraser <keir.xen@gmail.com>
To: Javier Marcet <jmarcet@gmail.com>,
	Konrad Rzeszutek Wilk <konrad@kernel.org>
Message-ID: <CC7DF5F7.3F018%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] Xen 4.2.0-rc4 issues with DVB tuner
Thread-Index: Ac2Ve5b4jU46tPTYzE2Twy0umC4hMg==
In-Reply-To: <CAAnFQG9PuzRLSsCS8m_0VUeV+ZaCwK3zsbinxtuFBfdSihJknw@mail.gmail.com>
Mime-version: 1.0
Cc: Xen Devel Mailing list <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.2.0-rc4 issues with DVB tuner
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="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/09/2012 09:41, "Javier Marcet" <jmarcet@gmail.com> wrote:

> What I don=B4t understand is how graphics pass through even works
and a tuner
> card has problems due to the introduced latencies in the
IRQs.

Do you have
> any more info about this?

In this respect sound is harder than graphics. Try pinning your dom0 to a
CPU core, and set affinities on other domains so that dom0 does not compete
for the core with any other domains.

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 18 08:57:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Sep 2012 08: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 1TDtcS-00008U-Ob; Tue, 18 Sep 2012 08:57:24 +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 1TDtcR-00008P-4B
	for xen-devel@lists.xen.org; Tue, 18 Sep 2012 08:57:23 +0000
Received: from [85.158.137.99:48594] by server-10.bemta-3.messagelabs.com id
	07/71-10411-27738505; Tue, 18 Sep 2012 08:57:22 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-2.tower-217.messagelabs.com!1347958641!17997765!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-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9737 invoked from network); 18 Sep 2012 08:57:21 -0000
Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com)
	(74.125.83.45)
	by server-2.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Sep 2012 08:57:21 -0000
Received: by eeke53 with SMTP id e53so3975158eek.32
	for <xen-devel@lists.xen.org>; Tue, 18 Sep 2012 01:57:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=9jISTfByLRw/Jr3DHzCugX6nbqAxwlqzE0PbSpeZENA=;
	b=MYm6UNwaWGYot5MsWlXWaNIuBbmiD+1FFHVkkD7CiYpCvWcg/Yo3v78lo13GHaDUOJ
	64qZX1S139O3CTF3w1jMAadcrNiOpmqZ85gLee39rx5TH7bKJwy6qIwlFaNdd7HS1MB8
	r4ZCTojAvLMbehdNEu+WmelUf89maoyikxRJnJuGTKLIaYnwJXEi6nX0zaDQTMi85Krz
	yGdoG1LHrlrlJVDRM74pr+3jykkVkQd45ZQMEGTBkEXfZ3ZPT16gfGIcsq/eg5e6am8J
	wCUF4RemKbQEik5M1aAtYDGSquQKRkhyT2pNAwsO+m99kGL7ImyJx3RpwPN4oRlZ+d0B
	nzZw==
Received: by 10.14.221.197 with SMTP id r45mr16582794eep.41.1347958641530;
	Tue, 18 Sep 2012 01:57:21 -0700 (PDT)
Received: from [192.168.1.69] (host86-183-251-65.range86-183.btcentralplus.com.
	[86.183.251.65])
	by mx.google.com with ESMTPS id h2sm34496063eeo.3.2012.09.18.01.57.16
	(version=SSLv3 cipher=OTHER); Tue, 18 Sep 2012 01:57:20 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Tue, 18 Sep 2012 09:57:11 +0100
From: Keir Fraser <keir.xen@gmail.com>
To: Javier Marcet <jmarcet@gmail.com>,
	Konrad Rzeszutek Wilk <konrad@kernel.org>
Message-ID: <CC7DF5F7.3F018%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] Xen 4.2.0-rc4 issues with DVB tuner
Thread-Index: Ac2Ve5b4jU46tPTYzE2Twy0umC4hMg==
In-Reply-To: <CAAnFQG9PuzRLSsCS8m_0VUeV+ZaCwK3zsbinxtuFBfdSihJknw@mail.gmail.com>
Mime-version: 1.0
Cc: Xen Devel Mailing list <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.2.0-rc4 issues with DVB tuner
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="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/09/2012 09:41, "Javier Marcet" <jmarcet@gmail.com> wrote:

> What I don=B4t understand is how graphics pass through even works
and a tuner
> card has problems due to the introduced latencies in the
IRQs.

Do you have
> any more info about this?

In this respect sound is harder than graphics. Try pinning your dom0 to a
CPU core, and set affinities on other domains so that dom0 does not compete
for the core with any other domains.

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 18 09:50:17 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Sep 2012 09:50:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDuRA-0000Z0-HM; Tue, 18 Sep 2012 09:49: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 1TDuR8-0000Ys-QJ
	for xen-devel@lists.xen.org; Tue, 18 Sep 2012 09:49:46 +0000
Received: from [85.158.143.99:37652] by server-1.bemta-4.messagelabs.com id
	15/B1-12504-9B348505; Tue, 18 Sep 2012 09:49:45 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1347961785!25509972!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDk5MjE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30044 invoked from network); 18 Sep 2012 09:49:45 -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;
	18 Sep 2012 09:49:45 -0000
X-IronPort-AV: E=Sophos;i="4.80,442,1344211200"; d="scan'208";a="14601044"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Sep 2012 09:49: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.279.1; Tue, 18 Sep 2012 10:49: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
	1TDuR6-0002UL-Qy; Tue, 18 Sep 2012 09:49:44 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1TDuR6-0001Gm-Lr;
	Tue, 18 Sep 2012 10:49:44 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20568.17336.548944.617682@mariner.uk.xensource.com>
Date: Tue, 18 Sep 2012 10:49:44 +0100
To: Matt Wilson <msw@amazon.com>
In-Reply-To: <20120917170814.GA22382@u002268147cd4502c336d.ant.amazon.com>
References: <patchbomb.1346992557@u002268147cd4502c336d.ant.amazon.com>
	<3b3582f4dc423daa8040.1346992558@u002268147cd4502c336d.ant.amazon.com>
	<1347874964.14977.34.camel@zakaz.uk.xensource.com>
	<20120917170814.GA22382@u002268147cd4502c336d.ant.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" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 1 of 2 v3] tools: check for documentation
 generation tools at configure 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

Matt Wilson writes ("Re: [PATCH 1 of 2 v3] tools: check for documentation generation tools at configure time"):
> On Mon, Sep 17, 2012 at 10:42:44AM +0100, Ian Campbell wrote:
> >         configure: error: in `/home/xendocs/cronjobs/working/docs/unstable/tree/tools':
> >         configure: error: no acceptable C compiler found in $PATH
> >         See `config.log' for more details
> > 
> > Which is a bit annoying if all you wanted was to build docs. I'm not
> > sure I really want to advocate putting gcc on xenbits. I suppose I could
> > put a dummy shell script in $PATH.
> 
> ./configure is probably going to need a compiler that produces
> executables.

Not necessarily.  If we don't ask for AC_CC or whatever it is, it
shouldn't.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 18 09:50:17 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Sep 2012 09:50:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDuRA-0000Z0-HM; Tue, 18 Sep 2012 09:49: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 1TDuR8-0000Ys-QJ
	for xen-devel@lists.xen.org; Tue, 18 Sep 2012 09:49:46 +0000
Received: from [85.158.143.99:37652] by server-1.bemta-4.messagelabs.com id
	15/B1-12504-9B348505; Tue, 18 Sep 2012 09:49:45 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1347961785!25509972!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDk5MjE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30044 invoked from network); 18 Sep 2012 09:49:45 -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;
	18 Sep 2012 09:49:45 -0000
X-IronPort-AV: E=Sophos;i="4.80,442,1344211200"; d="scan'208";a="14601044"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Sep 2012 09:49: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.279.1; Tue, 18 Sep 2012 10:49: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
	1TDuR6-0002UL-Qy; Tue, 18 Sep 2012 09:49:44 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1TDuR6-0001Gm-Lr;
	Tue, 18 Sep 2012 10:49:44 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20568.17336.548944.617682@mariner.uk.xensource.com>
Date: Tue, 18 Sep 2012 10:49:44 +0100
To: Matt Wilson <msw@amazon.com>
In-Reply-To: <20120917170814.GA22382@u002268147cd4502c336d.ant.amazon.com>
References: <patchbomb.1346992557@u002268147cd4502c336d.ant.amazon.com>
	<3b3582f4dc423daa8040.1346992558@u002268147cd4502c336d.ant.amazon.com>
	<1347874964.14977.34.camel@zakaz.uk.xensource.com>
	<20120917170814.GA22382@u002268147cd4502c336d.ant.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" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 1 of 2 v3] tools: check for documentation
 generation tools at configure 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

Matt Wilson writes ("Re: [PATCH 1 of 2 v3] tools: check for documentation generation tools at configure time"):
> On Mon, Sep 17, 2012 at 10:42:44AM +0100, Ian Campbell wrote:
> >         configure: error: in `/home/xendocs/cronjobs/working/docs/unstable/tree/tools':
> >         configure: error: no acceptable C compiler found in $PATH
> >         See `config.log' for more details
> > 
> > Which is a bit annoying if all you wanted was to build docs. I'm not
> > sure I really want to advocate putting gcc on xenbits. I suppose I could
> > put a dummy shell script in $PATH.
> 
> ./configure is probably going to need a compiler that produces
> executables.

Not necessarily.  If we don't ask for AC_CC or whatever it is, it
shouldn't.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 18 10:00:56 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Sep 2012 10: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 1TDubb-0000mX-LV; Tue, 18 Sep 2012 10:00:35 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andre.Przywara@amd.com>) id 1TDuba-0000mS-3O
	for xen-devel@lists.xen.org; Tue, 18 Sep 2012 10:00:34 +0000
X-Env-Sender: Andre.Przywara@amd.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1347962421!10864708!1
X-Originating-IP: [216.32.180.14]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14608 invoked from network); 18 Sep 2012 10:00:22 -0000
Received: from va3ehsobe004.messaging.microsoft.com (HELO
	va3outboundpool.messaging.microsoft.com) (216.32.180.14)
	by server-4.tower-27.messagelabs.com with AES128-SHA encrypted SMTP;
	18 Sep 2012 10:00:22 -0000
Received: from mail136-va3-R.bigfish.com (10.7.14.247) by
	VA3EHSOBE004.bigfish.com (10.7.40.24) with Microsoft SMTP Server id
	14.1.225.23; Tue, 18 Sep 2012 10:00:21 +0000
Received: from mail136-va3 (localhost [127.0.0.1])	by
	mail136-va3-R.bigfish.com (Postfix) with ESMTP id 5D7D04A0270;
	Tue, 18 Sep 2012 10:00:21 +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: -2
X-BigFish: VPS-2(z551bizbb2dI98dI9371I1432Id6f1izz1202h1d1ah1d2ahzzz2dh668h839hd25he5bhf0ah107ah1288h12a5h12a9h12bdh1155h)
Received: from mail136-va3 (localhost.localdomain [127.0.0.1]) by mail136-va3
	(MessageSwitch) id 1347962419453779_18914;
	Tue, 18 Sep 2012 10:00:19 +0000 (UTC)
Received: from VA3EHSMHS026.bigfish.com (unknown [10.7.14.252])	by
	mail136-va3.bigfish.com (Postfix) with ESMTP id 69F053A0046;
	Tue, 18 Sep 2012 10:00:19 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	VA3EHSMHS026.bigfish.com (10.7.99.36) with Microsoft SMTP Server id
	14.1.225.23; Tue, 18 Sep 2012 10:00:18 +0000
X-WSS-ID: 0MAJIGH-01-5RV-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 26E1710280BE;	Tue, 18 Sep 2012 05:00:17 -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;
	Tue, 18 Sep 2012 05:00:18 -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;
	Tue, 18 Sep 2012 05:00:16 -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; Tue, 18 Sep 2012
	06:00:16 -0400
Received: from mail.osrc.amd.com (aluminium.osrc.amd.com [165.204.15.141])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id F288F49C69F;
	Tue, 18 Sep 2012 11:00:13 +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 B7E821C8002; Tue, 18 Sep 2012
	12:00:13 +0200 (CEST)
Message-ID: <5058458D.7030603@amd.com>
Date: Tue, 18 Sep 2012 11:57:33 +0200
From: Andre Przywara <andre.przywara@amd.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:13.0) Gecko/20120615 Thunderbird/13.0.1
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk <konrad@kernel.org>
References: <501BC20F.3040205@amd.com>
	<20120803123628.GB10670@andromeda.dapyr.net>
	<20120817142237.GA8467@phenom.dumpdata.com>
	<20120914185822.GA7495@phenom.dumpdata.com>
	<5056D152.2090708@amd.com>
	<20120917191432.GA18552@phenom.dumpdata.com>
In-Reply-To: <20120917191432.GA18552@phenom.dumpdata.com>
X-OriginatorOrg: amd.com
Cc: Konrad Rzeszutek Wilk <konrad@darnok.org>,
	Jeremy Fitzhardinge <jeremy@goop.org>, xen-devel <xen-devel@lists.xen.org>,
	Dario Faggioli <raistlin@linux.it>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] Dom0 crash with old style AMD NUMA detection
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 09/17/2012 09:14 PM, Konrad Rzeszutek Wilk wrote:
> On Mon, Sep 17, 2012 at 09:29:22AM +0200, Andre Przywara wrote:
>> On 09/14/2012 08:58 PM, Konrad Rzeszutek Wilk wrote:
>>>>>> [    0.000000] Kernel panic - not syncing: Attempted to kill the idle task!
>>>>>> (XEN) Domain 0 crashed: 'noreboot' set - not rebooting.
>>>>>>
>>>>>>
>>>>>>
>>>>>> The obvious solution would be to explicitly deny northbridge scanning
>>>>>> when running as Dom0, though I am not sure how to implement this without
>>>>>> upsetting the other kernel folks about "that crappy Xen thing" again ;-)
>>>>>
>>>>> Heh.
>>>>> Is there a numa=0 option that could be used to override it to turn it
>>>>> off?
>>>>
>>>> Not compile tested.. but was thinking something like this:
>>>
>>> ping?
>>
>> That looks good to me - at least for the time being.
>
> OK, can I've your Tested-by/Acked-by on it pls?
>
>> I just want to check how this interacts with upcoming Dom0 NUMA
>> support. It wouldn't be too clever if we deliberately disable NUMA
>
> We can always revert this patch in future versions of Linux.

I don't like this idea. Then we have Linux kernel up to 3.5 working and 
say from 3.8 on again, but 3.6 and 3.7 cannot use NUMA. That would be 
pretty unfortunate.

I haven't checked back with Dario, but I'd suspect that we use ACPI for 
injecting NUMA topology into Dom0. Even if not, a general "numa=off" for 
Dom0 is too much of a sledgehammer for me.

>> and future Xen version will allow us to use it. So let me check if I
>> can confine this turn-off to the fallback K8 northbridge reading.
>
> This potentially could work, but I would prefer to not do it for 3.6.

Mmh, I don't get the idea of your patch below. One can always read the 
NUMA topology from the AMD northbridge, but this is deprecated if favor 
of ACPI. The amdtopology.c stuff was only there to enable NUMA for very 
early Opterons, where BIOSes didn't provide (sane) SRAT tables.
Though we disallow ACPI for NUMA on Dom0, this northbridge scanning 
unfortunately "shines through" the virtualization, actually revealing 
the system's NUMA topology, which is usually much different from Dom0's one.

So instead I want to do more something like this:

diff --git a/arch/x86/include/asm/numa.h b/arch/x86/include/asm/numa.h
index bfacd2c..7811c0d 100644
--- a/arch/x86/include/asm/numa.h
+++ b/arch/x86/include/asm/numa.h
@@ -20,6 +20,8 @@

  extern int numa_off;

+extern bool deny_amd_nb_numa_scan;
+
  /*
   * __apicid_to_node[] stores the raw mapping between physical apicid and
   * node and is used to initialize cpu_to_node mapping.
diff --git a/arch/x86/mm/amdtopology.c b/arch/x86/mm/amdtopology.c
index 5247d01..f223a67 100644
--- a/arch/x86/mm/amdtopology.c
+++ b/arch/x86/mm/amdtopology.c
@@ -29,6 +29,8 @@

  static unsigned char __initdata nodeids[8];

+bool deny_amd_nb_numa_scan = 0;
+
  static __init int find_northbridge(void)
  {
  	int num;
@@ -78,6 +80,9 @@ int __init amd_numa_init(void)
  	u32 nodeid, reg;
  	unsigned int bits, cores, apicid_base;

+	if (deny_amd_nb_numa_scan)
+		return -ENOENT;
+
  	if (!early_pci_allowed())
  		return -EINVAL;

diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c
index d11ca11..6db63c0 100644
--- a/arch/x86/xen/setup.c
+++ b/arch/x86/xen/setup.c
@@ -532,6 +532,8 @@ void __init xen_arch_setup(void)
  	}
  #endif

+	deny_amd_nb_numa_scan = 1;
+
  	memcpy(boot_command_line, xen_start_info->cmd_line,
  	       MAX_GUEST_CMDLINE > COMMAND_LINE_SIZE ?
  	       COMMAND_LINE_SIZE : MAX_GUEST_CMDLINE);

This would just turn off this one kind of NUMA discovery for Dom0.
The patch is admittedly a bit rough (not sure about the proper placement 
into #ifdef's, for instance) and not well tested yet.
Also one could think about using a more general variable name to cover 
other hardware things in the future that Dom0 shouldn't use.
So this isn't something still for 3.6, probably not even for 3.7.

What about if we drop the patch for this problem at all for 3.6 and 
recommend "numa=off" as a workaround? This is much less sticky than a 
kernel patch and could appear in the Xen wiki, for instance.
After all this isn't a strict regression (appears with every 3.x kernel, 
AFAICT).
Most of the time the northbridge scanning will yield bogus results, so 
the kernel eventually discards it, but sometimes it seems to slip 
through and causes trouble.
Also it does not trigger on newer (Bulldozer) class CPUs, since we 
deliberately avoided adding the new northbridge PCI-ID for this routine.

Regards,
Andre.

>
> diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c
> index a4790bf..b4edce4 100644
> --- a/arch/x86/xen/setup.c
> +++ b/arch/x86/xen/setup.c
> @@ -17,6 +17,7 @@
>   #include <asm/e820.h>
>   #include <asm/setup.h>
>   #include <asm/acpi.h>
> +#include <asm/numa.h>
>   #include <asm/xen/hypervisor.h>
>   #include <asm/xen/hypercall.h>
>
> @@ -483,7 +484,32 @@ void __cpuinit xen_enable_sysenter(void)
>   	if(ret != 0)
>   		setup_clear_cpu_cap(sysenter_feature);
>   }
> +#ifdef CONFIG_AMD_NUMA
> +int __cpuinit xen_amd_k8(void)
> +{
> +	int num;
> +
> +	if (boot_cpu_data.x86_vendor != X86_VENDOR_AMD)
> +		return -ENOENT;
> +
> +	for (num = 0; num < 32; num++) {
> +		u32 header;
> +
> +		header = read_pci_config(0, num, 0, 0x00);
> +		if (header != (PCI_VENDOR_ID_AMD | (0x1100<<16)) &&
> +			header != (PCI_VENDOR_ID_AMD | (0x1200<<16)) &&
> +			header != (PCI_VENDOR_ID_AMD | (0x1300<<16)))
> +			continue;
>
> +		header = read_pci_config(0, num, 1, 0x00);
> +		if (header != (PCI_VENDOR_ID_AMD | (0x1101<<16)) &&
> +			header != (PCI_VENDOR_ID_AMD | (0x1201<<16)) &&
> +			header != (PCI_VENDOR_ID_AMD | (0x1301<<16)))
> +			continue;
> +		return num;
> +	}
> +	return -ENOENT;
> +#endif
>   void __cpuinit xen_enable_syscall(void)
>   {
>   #ifdef CONFIG_X86_64
> @@ -542,4 +568,8 @@ void __init xen_arch_setup(void)
>   	disable_cpufreq();
>   	WARN_ON(set_pm_idle_to_default());
>   	fiddle_vdso();
> +#ifdef CONFIG_AMD_NUMA
> +	if (xen_amd_k8() >= 0)
> +		numa_off=1;
> +#endif
>   }
>



-- 
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 Tue Sep 18 10:00:56 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Sep 2012 10: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 1TDubb-0000mX-LV; Tue, 18 Sep 2012 10:00:35 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andre.Przywara@amd.com>) id 1TDuba-0000mS-3O
	for xen-devel@lists.xen.org; Tue, 18 Sep 2012 10:00:34 +0000
X-Env-Sender: Andre.Przywara@amd.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1347962421!10864708!1
X-Originating-IP: [216.32.180.14]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14608 invoked from network); 18 Sep 2012 10:00:22 -0000
Received: from va3ehsobe004.messaging.microsoft.com (HELO
	va3outboundpool.messaging.microsoft.com) (216.32.180.14)
	by server-4.tower-27.messagelabs.com with AES128-SHA encrypted SMTP;
	18 Sep 2012 10:00:22 -0000
Received: from mail136-va3-R.bigfish.com (10.7.14.247) by
	VA3EHSOBE004.bigfish.com (10.7.40.24) with Microsoft SMTP Server id
	14.1.225.23; Tue, 18 Sep 2012 10:00:21 +0000
Received: from mail136-va3 (localhost [127.0.0.1])	by
	mail136-va3-R.bigfish.com (Postfix) with ESMTP id 5D7D04A0270;
	Tue, 18 Sep 2012 10:00:21 +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: -2
X-BigFish: VPS-2(z551bizbb2dI98dI9371I1432Id6f1izz1202h1d1ah1d2ahzzz2dh668h839hd25he5bhf0ah107ah1288h12a5h12a9h12bdh1155h)
Received: from mail136-va3 (localhost.localdomain [127.0.0.1]) by mail136-va3
	(MessageSwitch) id 1347962419453779_18914;
	Tue, 18 Sep 2012 10:00:19 +0000 (UTC)
Received: from VA3EHSMHS026.bigfish.com (unknown [10.7.14.252])	by
	mail136-va3.bigfish.com (Postfix) with ESMTP id 69F053A0046;
	Tue, 18 Sep 2012 10:00:19 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	VA3EHSMHS026.bigfish.com (10.7.99.36) with Microsoft SMTP Server id
	14.1.225.23; Tue, 18 Sep 2012 10:00:18 +0000
X-WSS-ID: 0MAJIGH-01-5RV-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 26E1710280BE;	Tue, 18 Sep 2012 05:00:17 -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;
	Tue, 18 Sep 2012 05:00:18 -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;
	Tue, 18 Sep 2012 05:00:16 -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; Tue, 18 Sep 2012
	06:00:16 -0400
Received: from mail.osrc.amd.com (aluminium.osrc.amd.com [165.204.15.141])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id F288F49C69F;
	Tue, 18 Sep 2012 11:00:13 +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 B7E821C8002; Tue, 18 Sep 2012
	12:00:13 +0200 (CEST)
Message-ID: <5058458D.7030603@amd.com>
Date: Tue, 18 Sep 2012 11:57:33 +0200
From: Andre Przywara <andre.przywara@amd.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:13.0) Gecko/20120615 Thunderbird/13.0.1
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk <konrad@kernel.org>
References: <501BC20F.3040205@amd.com>
	<20120803123628.GB10670@andromeda.dapyr.net>
	<20120817142237.GA8467@phenom.dumpdata.com>
	<20120914185822.GA7495@phenom.dumpdata.com>
	<5056D152.2090708@amd.com>
	<20120917191432.GA18552@phenom.dumpdata.com>
In-Reply-To: <20120917191432.GA18552@phenom.dumpdata.com>
X-OriginatorOrg: amd.com
Cc: Konrad Rzeszutek Wilk <konrad@darnok.org>,
	Jeremy Fitzhardinge <jeremy@goop.org>, xen-devel <xen-devel@lists.xen.org>,
	Dario Faggioli <raistlin@linux.it>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] Dom0 crash with old style AMD NUMA detection
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 09/17/2012 09:14 PM, Konrad Rzeszutek Wilk wrote:
> On Mon, Sep 17, 2012 at 09:29:22AM +0200, Andre Przywara wrote:
>> On 09/14/2012 08:58 PM, Konrad Rzeszutek Wilk wrote:
>>>>>> [    0.000000] Kernel panic - not syncing: Attempted to kill the idle task!
>>>>>> (XEN) Domain 0 crashed: 'noreboot' set - not rebooting.
>>>>>>
>>>>>>
>>>>>>
>>>>>> The obvious solution would be to explicitly deny northbridge scanning
>>>>>> when running as Dom0, though I am not sure how to implement this without
>>>>>> upsetting the other kernel folks about "that crappy Xen thing" again ;-)
>>>>>
>>>>> Heh.
>>>>> Is there a numa=0 option that could be used to override it to turn it
>>>>> off?
>>>>
>>>> Not compile tested.. but was thinking something like this:
>>>
>>> ping?
>>
>> That looks good to me - at least for the time being.
>
> OK, can I've your Tested-by/Acked-by on it pls?
>
>> I just want to check how this interacts with upcoming Dom0 NUMA
>> support. It wouldn't be too clever if we deliberately disable NUMA
>
> We can always revert this patch in future versions of Linux.

I don't like this idea. Then we have Linux kernel up to 3.5 working and 
say from 3.8 on again, but 3.6 and 3.7 cannot use NUMA. That would be 
pretty unfortunate.

I haven't checked back with Dario, but I'd suspect that we use ACPI for 
injecting NUMA topology into Dom0. Even if not, a general "numa=off" for 
Dom0 is too much of a sledgehammer for me.

>> and future Xen version will allow us to use it. So let me check if I
>> can confine this turn-off to the fallback K8 northbridge reading.
>
> This potentially could work, but I would prefer to not do it for 3.6.

Mmh, I don't get the idea of your patch below. One can always read the 
NUMA topology from the AMD northbridge, but this is deprecated if favor 
of ACPI. The amdtopology.c stuff was only there to enable NUMA for very 
early Opterons, where BIOSes didn't provide (sane) SRAT tables.
Though we disallow ACPI for NUMA on Dom0, this northbridge scanning 
unfortunately "shines through" the virtualization, actually revealing 
the system's NUMA topology, which is usually much different from Dom0's one.

So instead I want to do more something like this:

diff --git a/arch/x86/include/asm/numa.h b/arch/x86/include/asm/numa.h
index bfacd2c..7811c0d 100644
--- a/arch/x86/include/asm/numa.h
+++ b/arch/x86/include/asm/numa.h
@@ -20,6 +20,8 @@

  extern int numa_off;

+extern bool deny_amd_nb_numa_scan;
+
  /*
   * __apicid_to_node[] stores the raw mapping between physical apicid and
   * node and is used to initialize cpu_to_node mapping.
diff --git a/arch/x86/mm/amdtopology.c b/arch/x86/mm/amdtopology.c
index 5247d01..f223a67 100644
--- a/arch/x86/mm/amdtopology.c
+++ b/arch/x86/mm/amdtopology.c
@@ -29,6 +29,8 @@

  static unsigned char __initdata nodeids[8];

+bool deny_amd_nb_numa_scan = 0;
+
  static __init int find_northbridge(void)
  {
  	int num;
@@ -78,6 +80,9 @@ int __init amd_numa_init(void)
  	u32 nodeid, reg;
  	unsigned int bits, cores, apicid_base;

+	if (deny_amd_nb_numa_scan)
+		return -ENOENT;
+
  	if (!early_pci_allowed())
  		return -EINVAL;

diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c
index d11ca11..6db63c0 100644
--- a/arch/x86/xen/setup.c
+++ b/arch/x86/xen/setup.c
@@ -532,6 +532,8 @@ void __init xen_arch_setup(void)
  	}
  #endif

+	deny_amd_nb_numa_scan = 1;
+
  	memcpy(boot_command_line, xen_start_info->cmd_line,
  	       MAX_GUEST_CMDLINE > COMMAND_LINE_SIZE ?
  	       COMMAND_LINE_SIZE : MAX_GUEST_CMDLINE);

This would just turn off this one kind of NUMA discovery for Dom0.
The patch is admittedly a bit rough (not sure about the proper placement 
into #ifdef's, for instance) and not well tested yet.
Also one could think about using a more general variable name to cover 
other hardware things in the future that Dom0 shouldn't use.
So this isn't something still for 3.6, probably not even for 3.7.

What about if we drop the patch for this problem at all for 3.6 and 
recommend "numa=off" as a workaround? This is much less sticky than a 
kernel patch and could appear in the Xen wiki, for instance.
After all this isn't a strict regression (appears with every 3.x kernel, 
AFAICT).
Most of the time the northbridge scanning will yield bogus results, so 
the kernel eventually discards it, but sometimes it seems to slip 
through and causes trouble.
Also it does not trigger on newer (Bulldozer) class CPUs, since we 
deliberately avoided adding the new northbridge PCI-ID for this routine.

Regards,
Andre.

>
> diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c
> index a4790bf..b4edce4 100644
> --- a/arch/x86/xen/setup.c
> +++ b/arch/x86/xen/setup.c
> @@ -17,6 +17,7 @@
>   #include <asm/e820.h>
>   #include <asm/setup.h>
>   #include <asm/acpi.h>
> +#include <asm/numa.h>
>   #include <asm/xen/hypervisor.h>
>   #include <asm/xen/hypercall.h>
>
> @@ -483,7 +484,32 @@ void __cpuinit xen_enable_sysenter(void)
>   	if(ret != 0)
>   		setup_clear_cpu_cap(sysenter_feature);
>   }
> +#ifdef CONFIG_AMD_NUMA
> +int __cpuinit xen_amd_k8(void)
> +{
> +	int num;
> +
> +	if (boot_cpu_data.x86_vendor != X86_VENDOR_AMD)
> +		return -ENOENT;
> +
> +	for (num = 0; num < 32; num++) {
> +		u32 header;
> +
> +		header = read_pci_config(0, num, 0, 0x00);
> +		if (header != (PCI_VENDOR_ID_AMD | (0x1100<<16)) &&
> +			header != (PCI_VENDOR_ID_AMD | (0x1200<<16)) &&
> +			header != (PCI_VENDOR_ID_AMD | (0x1300<<16)))
> +			continue;
>
> +		header = read_pci_config(0, num, 1, 0x00);
> +		if (header != (PCI_VENDOR_ID_AMD | (0x1101<<16)) &&
> +			header != (PCI_VENDOR_ID_AMD | (0x1201<<16)) &&
> +			header != (PCI_VENDOR_ID_AMD | (0x1301<<16)))
> +			continue;
> +		return num;
> +	}
> +	return -ENOENT;
> +#endif
>   void __cpuinit xen_enable_syscall(void)
>   {
>   #ifdef CONFIG_X86_64
> @@ -542,4 +568,8 @@ void __init xen_arch_setup(void)
>   	disable_cpufreq();
>   	WARN_ON(set_pm_idle_to_default());
>   	fiddle_vdso();
> +#ifdef CONFIG_AMD_NUMA
> +	if (xen_amd_k8() >= 0)
> +		numa_off=1;
> +#endif
>   }
>



-- 
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 Tue Sep 18 10:25:36 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Sep 2012 10:25:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDuzN-000152-0u; Tue, 18 Sep 2012 10:25:09 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1TDuzL-00014x-Fp
	for xen-devel@lists.xensource.com; Tue, 18 Sep 2012 10:25:07 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1347963900!11420693!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDk5MjE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30499 invoked from network); 18 Sep 2012 10:25:01 -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;
	18 Sep 2012 10:25:01 -0000
X-IronPort-AV: E=Sophos;i="4.80,442,1344211200"; d="scan'208";a="14602074"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Sep 2012 10:25:00 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Tue, 18 Sep 2012 11:25:00 +0100
Date: Tue, 18 Sep 2012 11:24:14 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: "Xu, Dongxiao" <dongxiao.xu@intel.com>
In-Reply-To: <40776A41FC278F40B59438AD47D147A90FE40092@SHSMSX102.ccr.corp.intel.com>
Message-ID: <alpine.DEB.2.02.1209181123280.29232@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1209101842150.15568@kaball.uk.xensource.com>
	<40776A41FC278F40B59438AD47D147A90FE40092@SHSMSX102.ccr.corp.intel.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: "Keir \(Xen.org\)" <keir@xen.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 0/2] QEMU/xen: simplify cpu_ioreq_pio and
 cpu_ioreq_move
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 18 Sep 2012, Xu, Dongxiao wrote:
> Hi Stefano,
> 
> Is these patches merged with Xen 4.2? I didn't see them in the upstream.
> The uint/int fix is critical to fix the nested guest boot issue.

They are not. Ian decided that he wanted to merge a different version of
them.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 18 10:25:36 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Sep 2012 10:25:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDuzN-000152-0u; Tue, 18 Sep 2012 10:25:09 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1TDuzL-00014x-Fp
	for xen-devel@lists.xensource.com; Tue, 18 Sep 2012 10:25:07 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1347963900!11420693!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDk5MjE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30499 invoked from network); 18 Sep 2012 10:25:01 -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;
	18 Sep 2012 10:25:01 -0000
X-IronPort-AV: E=Sophos;i="4.80,442,1344211200"; d="scan'208";a="14602074"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Sep 2012 10:25:00 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Tue, 18 Sep 2012 11:25:00 +0100
Date: Tue, 18 Sep 2012 11:24:14 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: "Xu, Dongxiao" <dongxiao.xu@intel.com>
In-Reply-To: <40776A41FC278F40B59438AD47D147A90FE40092@SHSMSX102.ccr.corp.intel.com>
Message-ID: <alpine.DEB.2.02.1209181123280.29232@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1209101842150.15568@kaball.uk.xensource.com>
	<40776A41FC278F40B59438AD47D147A90FE40092@SHSMSX102.ccr.corp.intel.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: "Keir \(Xen.org\)" <keir@xen.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 0/2] QEMU/xen: simplify cpu_ioreq_pio and
 cpu_ioreq_move
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 18 Sep 2012, Xu, Dongxiao wrote:
> Hi Stefano,
> 
> Is these patches merged with Xen 4.2? I didn't see them in the upstream.
> The uint/int fix is critical to fix the nested guest boot issue.

They are not. Ian decided that he wanted to merge a different version of
them.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 18 10:30:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Sep 2012 10:30:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDv3o-0001Co-O6; Tue, 18 Sep 2012 10:29:44 +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 1TDv3m-0001Ch-QX
	for xen-devel@lists.xen.org; Tue, 18 Sep 2012 10:29:43 +0000
Received: from [85.158.139.211:61480] by server-2.bemta-5.messagelabs.com id
	6B/45-11456-61D48505; Tue, 18 Sep 2012 10:29:42 +0000
X-Env-Sender: Christoph.Egger@amd.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1347964179!18543671!1
X-Originating-IP: [216.32.181.183]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25148 invoked from network); 18 Sep 2012 10:29:40 -0000
Received: from ch1ehsobe003.messaging.microsoft.com (HELO
	ch1outboundpool.messaging.microsoft.com) (216.32.181.183)
	by server-7.tower-206.messagelabs.com with AES128-SHA encrypted SMTP;
	18 Sep 2012 10:29:40 -0000
Received: from mail43-ch1-R.bigfish.com (10.43.68.246) by
	CH1EHSOBE002.bigfish.com (10.43.70.52) with Microsoft SMTP Server id
	14.1.225.23; Tue, 18 Sep 2012 10:29:38 +0000
Received: from mail43-ch1 (localhost [127.0.0.1])	by mail43-ch1-R.bigfish.com
	(Postfix) with ESMTP id B1D9BC02EC	for <xen-devel@lists.xen.org>;
	Tue, 18 Sep 2012 10:29:38 +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(zzc85fhc85dhzz1202h1d1ah1d2ahzz8275bhz2dh668h839hd25he5bhf0ah107ah1288h12a5h12bdh34h1155h)
Received: from mail43-ch1 (localhost.localdomain [127.0.0.1]) by mail43-ch1
	(MessageSwitch) id 1347964176480528_28292;
	Tue, 18 Sep 2012 10:29:36 +0000 (UTC)
Received: from CH1EHSMHS040.bigfish.com (snatpool2.int.messaging.microsoft.com
	[10.43.68.232])	by mail43-ch1.bigfish.com (Postfix) with ESMTP id
	63531480048
	for <xen-devel@lists.xen.org>; Tue, 18 Sep 2012 10:29:36 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	CH1EHSMHS040.bigfish.com (10.43.69.249) with Microsoft SMTP Server id
	14.1.225.23; Tue, 18 Sep 2012 10:29:35 +0000
X-WSS-ID: 0MAJJT9-02-CML-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 212E0C80F1	for <xen-devel@lists.xen.org>; Tue, 18 Sep 2012
	05:29:32 -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;
	Tue, 18 Sep 2012 05:29:41 -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;
	Tue, 18 Sep 2012 05:29:32 -0500
Received: from rhodium.osrc.amd.com (165.204.15.173) by storexhtp02.amd.com
	(172.24.4.4) with Microsoft SMTP Server id 8.3.213.0; Tue, 18 Sep 2012
	06:29:31 -0400
Message-ID: <50584D0A.9060108@amd.com>
Date: Tue, 18 Sep 2012 12:29:30 +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="------------000502070207040100090601"
X-OriginatorOrg: amd.com
Subject: [Xen-devel] [PATCH] vMCE: Add AMD 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

--------------000502070207040100090601
Content-Type: text/plain; charset="ISO-8859-15"
Content-Transfer-Encoding: 7bit


Add vMCE support to AMD.
Add vmce namespace to Intel specific vMCE MSR functions.
Move vMCE prototypes from mce.h to vmce.h

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
Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen
Registergericht Muenchen, HRB Nr. 43632

--------------000502070207040100090601
Content-Type: text/plain; charset="us-ascii"; name="xen_vmce.diff"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="xen_vmce.diff"
Content-Description: xen_vmce.diff

# User Christoph Egger
# Date 1347954757 -7200
Add vMCE support to AMD.
Add vmce namespace to Intel specific vMCE MSR functions.
Move vMCE prototypes from mce.h to vmce.h

Signed-off-by: Christoph Egger <Christoph.Egger@amd.com>

diff -r fc4140ec1d59 -r 77837828f6c3 xen/arch/x86/cpu/mcheck/amd_f10.c
--- a/xen/arch/x86/cpu/mcheck/amd_f10.c
+++ b/xen/arch/x86/cpu/mcheck/amd_f10.c
@@ -104,3 +104,40 @@ enum mcheck_type amd_f10_mcheck_init(str
 
 	return mcheck_amd_famXX;
 }
+
+/* amd specific MCA MSR */
+int vmce_amd_wrmsr(struct vcpu *v, uint32_t msr, uint64_t val)
+{
+        int ret = 0;
+
+        switch (msr) {
+        case MSR_F10_MC4_MISC1:
+        case MSR_F10_MC4_MISC2:
+        case MSR_F10_MC4_MISC3:
+                break;
+        default:
+                mce_printk(MCE_QUIET, "Guest writes unhandled MSR 0x%x\n", msr);
+                ret = 1;
+                break;
+        }
+
+        return ret;
+}
+
+int vmce_amd_rdmsr(const struct vcpu *v, uint32_t msr, uint64_t *val)
+{
+        int ret = 0;
+
+        switch (msr) {
+        case MSR_F10_MC4_MISC1:
+        case MSR_F10_MC4_MISC2:
+        case MSR_F10_MC4_MISC3:
+                break;
+        default:
+                mce_printk(MCE_QUIET, "Guest reads unhandled MSR 0x%x\n", msr);
+                ret = 1;
+                break;
+        }
+
+        return ret;
+}
diff -r fc4140ec1d59 -r 77837828f6c3 xen/arch/x86/cpu/mcheck/amd_nonfatal.c
--- a/xen/arch/x86/cpu/mcheck/amd_nonfatal.c
+++ b/xen/arch/x86/cpu/mcheck/amd_nonfatal.c
@@ -64,6 +64,7 @@
 #include <asm/msr.h>
 
 #include "mce.h"
+#include "vmce.h"
 
 static struct timer mce_timer;
 
diff -r fc4140ec1d59 -r 77837828f6c3 xen/arch/x86/cpu/mcheck/mce.c
--- a/xen/arch/x86/cpu/mcheck/mce.c
+++ b/xen/arch/x86/cpu/mcheck/mce.c
@@ -25,6 +25,7 @@
 #include "mce.h"
 #include "barrier.h"
 #include "util.h"
+#include "vmce.h"
 
 bool_t __read_mostly mce_disabled;
 invbool_param("mce", mce_disabled);
diff -r fc4140ec1d59 -r 77837828f6c3 xen/arch/x86/cpu/mcheck/mce.h
--- a/xen/arch/x86/cpu/mcheck/mce.h
+++ b/xen/arch/x86/cpu/mcheck/mce.h
@@ -49,15 +49,9 @@ void intel_mcheck_timer(struct cpuinfo_x
 void mce_intel_feature_init(struct cpuinfo_x86 *c);
 void amd_nonfatal_mcheck_init(struct cpuinfo_x86 *c);
 
-int is_vmce_ready(struct mcinfo_bank *bank, struct domain *d);
-int unmmap_broken_page(struct domain *d, mfn_t mfn, unsigned long gfn);
-
-u64 mce_cap_init(void);
+uint64_t mce_cap_init(void);
 extern unsigned int firstbank;
 
-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);
-
 struct mcinfo_extended *intel_get_extended_msrs(
     struct mcinfo_global *mig, struct mc_info *mi);
 
@@ -69,9 +63,6 @@ void mc_panic(char *s);
 void x86_mc_get_cpu_info(unsigned, uint32_t *, uint16_t *, uint16_t *,
 			 uint32_t *, uint32_t *, uint32_t *, uint32_t *);
 
-#define dom0_vmce_enabled() (dom0 && dom0->max_vcpus && dom0->vcpu[0] \
-	&& guest_enabled_event(dom0->vcpu[0], VIRQ_MCA))
-
 /* Register a handler for machine check exceptions. */
 typedef void (*x86_mce_vector_t)(struct cpu_user_regs *, long);
 extern void x86_mce_vector_register(x86_mce_vector_t);
@@ -166,12 +157,6 @@ void *x86_mcinfo_add(struct mc_info *mi,
 void *x86_mcinfo_reserve(struct mc_info *mi, int size);
 void x86_mcinfo_dump(struct mc_info *mi);
 
-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);
-
 static inline int mce_vendor_bank_msr(const struct vcpu *v, uint32_t msr)
 {
     switch (boot_cpu_data.x86_vendor) {
diff -r fc4140ec1d59 -r 77837828f6c3 xen/arch/x86/cpu/mcheck/mce_intel.c
--- a/xen/arch/x86/cpu/mcheck/mce_intel.c
+++ b/xen/arch/x86/cpu/mcheck/mce_intel.c
@@ -18,6 +18,7 @@
 #include "x86_mca.h"
 #include "barrier.h"
 #include "util.h"
+#include "vmce.h"
 
 DEFINE_PER_CPU(struct mca_banks *, mce_banks_owned);
 DEFINE_PER_CPU(struct mca_banks *, no_cmci_banks);
@@ -980,7 +981,7 @@ enum mcheck_type intel_mcheck_init(struc
 }
 
 /* intel specific MCA MSR */
-int intel_mce_wrmsr(struct vcpu *v, uint32_t msr, uint64_t val)
+int vmce_intel_wrmsr(struct vcpu *v, uint32_t msr, uint64_t val)
 {
     int ret = 0;
 
@@ -995,7 +996,7 @@ int intel_mce_wrmsr(struct vcpu *v, uint
     return ret;
 }
 
-int intel_mce_rdmsr(const struct vcpu *v, uint32_t msr, uint64_t *val)
+int vmce_intel_rdmsr(const struct vcpu *v, uint32_t msr, uint64_t *val)
 {
     int ret = 0;
 
diff -r fc4140ec1d59 -r 77837828f6c3 xen/arch/x86/cpu/mcheck/non-fatal.c
--- a/xen/arch/x86/cpu/mcheck/non-fatal.c
+++ b/xen/arch/x86/cpu/mcheck/non-fatal.c
@@ -21,6 +21,7 @@
 #include <asm/msr.h>
 
 #include "mce.h"
+#include "vmce.h"
 
 DEFINE_PER_CPU(struct mca_banks *, poll_bankmask);
 static struct timer mce_timer;
diff -r fc4140ec1d59 -r 77837828f6c3 xen/arch/x86/cpu/mcheck/vmce.c
--- a/xen/arch/x86/cpu/mcheck/vmce.c
+++ b/xen/arch/x86/cpu/mcheck/vmce.c
@@ -16,8 +16,10 @@
 #include <asm/system.h>
 #include <asm/msr.h>
 #include <asm/p2m.h>
+
 #include "mce.h"
 #include "x86_mca.h"
+#include "vmce.h"
 
 /*
  * Emulate 2 banks for guest
@@ -27,7 +29,7 @@
  * Bank1: used to transfer error info to guest
  */
 #define GUEST_BANK_NUM 2
-#define GUEST_MCG_CAP (MCG_TES_P | MCG_SER_P | GUEST_BANK_NUM)
+#define GUEST_MCG_CAP (GUEST_BANK_NUM)
 
 #define dom_vmce(x)   ((x)->arch.vmca_msrs)
 
@@ -138,7 +140,10 @@ static int bank_mce_rdmsr(const struct v
         switch ( boot_cpu_data.x86_vendor )
         {
         case X86_VENDOR_INTEL:
-            ret = intel_mce_rdmsr(v, msr, val);
+            ret = vmce_intel_rdmsr(v, msr, val);
+            break;
+        case X86_VENDOR_AMD:
+            ret = vmce_amd_rdmsr(v, msr, val);
             break;
         default:
             ret = 0;
@@ -193,7 +198,7 @@ int vmce_rdmsr(uint32_t msr, uint64_t *v
     return ret;
 }
 
-static int bank_mce_wrmsr(struct vcpu *v, u32 msr, u64 val)
+static int bank_mce_wrmsr(struct vcpu *v, uint32_t msr, uint64_t val)
 {
     int ret = 1;
     unsigned int bank = (msr - MSR_IA32_MC0_CTL) / 4;
@@ -266,7 +271,10 @@ static int bank_mce_wrmsr(struct vcpu *v
         switch ( boot_cpu_data.x86_vendor )
         {
         case X86_VENDOR_INTEL:
-            ret = intel_mce_wrmsr(v, msr, val);
+            ret = vmce_intel_wrmsr(v, msr, val);
+            break;
+        case X86_VENDOR_AMD:
+            ret = vmce_amd_wrmsr(v, msr, val);
             break;
         default:
             ret = 0;
@@ -283,7 +291,7 @@ static int bank_mce_wrmsr(struct vcpu *v
  * = 0: Not handled, should be handled by other components
  * > 0: Success
  */
-int vmce_wrmsr(u32 msr, u64 val)
+int vmce_wrmsr(uint32_t msr, uint64_t val)
 {
     struct vcpu *cur = current;
     struct bank_entry *entry = NULL;
diff -r fc4140ec1d59 -r 77837828f6c3 xen/arch/x86/cpu/mcheck/vmce.h
--- /dev/null
+++ b/xen/arch/x86/cpu/mcheck/vmce.h
@@ -0,0 +1,25 @@
+#ifndef _MCHECK_VMCE_H
+#define _MCHECK_VMCE_H
+
+#include "x86_mca.h"
+
+int vmce_init(struct cpuinfo_x86 *c);
+
+#define dom0_vmce_enabled() (dom0 && dom0->max_vcpus && dom0->vcpu[0] \
+        && guest_enabled_event(dom0->vcpu[0], VIRQ_MCA))
+
+int is_vmce_ready(struct mcinfo_bank *bank, struct domain *d);
+int unmmap_broken_page(struct domain *d, mfn_t mfn, unsigned long gfn);
+
+int vmce_intel_rdmsr(const struct vcpu *, uint32_t msr, uint64_t *val);
+int vmce_intel_wrmsr(struct vcpu *, uint32_t msr, uint64_t val);
+int vmce_amd_rdmsr(const struct vcpu *, uint32_t msr, uint64_t *val);
+int vmce_amd_wrmsr(struct vcpu *, uint32_t msr, uint64_t val);
+
+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);
+
+#endif

--------------000502070207040100090601
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--------------000502070207040100090601--


From xen-devel-bounces@lists.xen.org Tue Sep 18 10:30:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Sep 2012 10:30:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDv3o-0001Co-O6; Tue, 18 Sep 2012 10:29:44 +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 1TDv3m-0001Ch-QX
	for xen-devel@lists.xen.org; Tue, 18 Sep 2012 10:29:43 +0000
Received: from [85.158.139.211:61480] by server-2.bemta-5.messagelabs.com id
	6B/45-11456-61D48505; Tue, 18 Sep 2012 10:29:42 +0000
X-Env-Sender: Christoph.Egger@amd.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1347964179!18543671!1
X-Originating-IP: [216.32.181.183]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25148 invoked from network); 18 Sep 2012 10:29:40 -0000
Received: from ch1ehsobe003.messaging.microsoft.com (HELO
	ch1outboundpool.messaging.microsoft.com) (216.32.181.183)
	by server-7.tower-206.messagelabs.com with AES128-SHA encrypted SMTP;
	18 Sep 2012 10:29:40 -0000
Received: from mail43-ch1-R.bigfish.com (10.43.68.246) by
	CH1EHSOBE002.bigfish.com (10.43.70.52) with Microsoft SMTP Server id
	14.1.225.23; Tue, 18 Sep 2012 10:29:38 +0000
Received: from mail43-ch1 (localhost [127.0.0.1])	by mail43-ch1-R.bigfish.com
	(Postfix) with ESMTP id B1D9BC02EC	for <xen-devel@lists.xen.org>;
	Tue, 18 Sep 2012 10:29:38 +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(zzc85fhc85dhzz1202h1d1ah1d2ahzz8275bhz2dh668h839hd25he5bhf0ah107ah1288h12a5h12bdh34h1155h)
Received: from mail43-ch1 (localhost.localdomain [127.0.0.1]) by mail43-ch1
	(MessageSwitch) id 1347964176480528_28292;
	Tue, 18 Sep 2012 10:29:36 +0000 (UTC)
Received: from CH1EHSMHS040.bigfish.com (snatpool2.int.messaging.microsoft.com
	[10.43.68.232])	by mail43-ch1.bigfish.com (Postfix) with ESMTP id
	63531480048
	for <xen-devel@lists.xen.org>; Tue, 18 Sep 2012 10:29:36 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	CH1EHSMHS040.bigfish.com (10.43.69.249) with Microsoft SMTP Server id
	14.1.225.23; Tue, 18 Sep 2012 10:29:35 +0000
X-WSS-ID: 0MAJJT9-02-CML-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 212E0C80F1	for <xen-devel@lists.xen.org>; Tue, 18 Sep 2012
	05:29:32 -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;
	Tue, 18 Sep 2012 05:29:41 -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;
	Tue, 18 Sep 2012 05:29:32 -0500
Received: from rhodium.osrc.amd.com (165.204.15.173) by storexhtp02.amd.com
	(172.24.4.4) with Microsoft SMTP Server id 8.3.213.0; Tue, 18 Sep 2012
	06:29:31 -0400
Message-ID: <50584D0A.9060108@amd.com>
Date: Tue, 18 Sep 2012 12:29:30 +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="------------000502070207040100090601"
X-OriginatorOrg: amd.com
Subject: [Xen-devel] [PATCH] vMCE: Add AMD 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

--------------000502070207040100090601
Content-Type: text/plain; charset="ISO-8859-15"
Content-Transfer-Encoding: 7bit


Add vMCE support to AMD.
Add vmce namespace to Intel specific vMCE MSR functions.
Move vMCE prototypes from mce.h to vmce.h

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
Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen
Registergericht Muenchen, HRB Nr. 43632

--------------000502070207040100090601
Content-Type: text/plain; charset="us-ascii"; name="xen_vmce.diff"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="xen_vmce.diff"
Content-Description: xen_vmce.diff

# User Christoph Egger
# Date 1347954757 -7200
Add vMCE support to AMD.
Add vmce namespace to Intel specific vMCE MSR functions.
Move vMCE prototypes from mce.h to vmce.h

Signed-off-by: Christoph Egger <Christoph.Egger@amd.com>

diff -r fc4140ec1d59 -r 77837828f6c3 xen/arch/x86/cpu/mcheck/amd_f10.c
--- a/xen/arch/x86/cpu/mcheck/amd_f10.c
+++ b/xen/arch/x86/cpu/mcheck/amd_f10.c
@@ -104,3 +104,40 @@ enum mcheck_type amd_f10_mcheck_init(str
 
 	return mcheck_amd_famXX;
 }
+
+/* amd specific MCA MSR */
+int vmce_amd_wrmsr(struct vcpu *v, uint32_t msr, uint64_t val)
+{
+        int ret = 0;
+
+        switch (msr) {
+        case MSR_F10_MC4_MISC1:
+        case MSR_F10_MC4_MISC2:
+        case MSR_F10_MC4_MISC3:
+                break;
+        default:
+                mce_printk(MCE_QUIET, "Guest writes unhandled MSR 0x%x\n", msr);
+                ret = 1;
+                break;
+        }
+
+        return ret;
+}
+
+int vmce_amd_rdmsr(const struct vcpu *v, uint32_t msr, uint64_t *val)
+{
+        int ret = 0;
+
+        switch (msr) {
+        case MSR_F10_MC4_MISC1:
+        case MSR_F10_MC4_MISC2:
+        case MSR_F10_MC4_MISC3:
+                break;
+        default:
+                mce_printk(MCE_QUIET, "Guest reads unhandled MSR 0x%x\n", msr);
+                ret = 1;
+                break;
+        }
+
+        return ret;
+}
diff -r fc4140ec1d59 -r 77837828f6c3 xen/arch/x86/cpu/mcheck/amd_nonfatal.c
--- a/xen/arch/x86/cpu/mcheck/amd_nonfatal.c
+++ b/xen/arch/x86/cpu/mcheck/amd_nonfatal.c
@@ -64,6 +64,7 @@
 #include <asm/msr.h>
 
 #include "mce.h"
+#include "vmce.h"
 
 static struct timer mce_timer;
 
diff -r fc4140ec1d59 -r 77837828f6c3 xen/arch/x86/cpu/mcheck/mce.c
--- a/xen/arch/x86/cpu/mcheck/mce.c
+++ b/xen/arch/x86/cpu/mcheck/mce.c
@@ -25,6 +25,7 @@
 #include "mce.h"
 #include "barrier.h"
 #include "util.h"
+#include "vmce.h"
 
 bool_t __read_mostly mce_disabled;
 invbool_param("mce", mce_disabled);
diff -r fc4140ec1d59 -r 77837828f6c3 xen/arch/x86/cpu/mcheck/mce.h
--- a/xen/arch/x86/cpu/mcheck/mce.h
+++ b/xen/arch/x86/cpu/mcheck/mce.h
@@ -49,15 +49,9 @@ void intel_mcheck_timer(struct cpuinfo_x
 void mce_intel_feature_init(struct cpuinfo_x86 *c);
 void amd_nonfatal_mcheck_init(struct cpuinfo_x86 *c);
 
-int is_vmce_ready(struct mcinfo_bank *bank, struct domain *d);
-int unmmap_broken_page(struct domain *d, mfn_t mfn, unsigned long gfn);
-
-u64 mce_cap_init(void);
+uint64_t mce_cap_init(void);
 extern unsigned int firstbank;
 
-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);
-
 struct mcinfo_extended *intel_get_extended_msrs(
     struct mcinfo_global *mig, struct mc_info *mi);
 
@@ -69,9 +63,6 @@ void mc_panic(char *s);
 void x86_mc_get_cpu_info(unsigned, uint32_t *, uint16_t *, uint16_t *,
 			 uint32_t *, uint32_t *, uint32_t *, uint32_t *);
 
-#define dom0_vmce_enabled() (dom0 && dom0->max_vcpus && dom0->vcpu[0] \
-	&& guest_enabled_event(dom0->vcpu[0], VIRQ_MCA))
-
 /* Register a handler for machine check exceptions. */
 typedef void (*x86_mce_vector_t)(struct cpu_user_regs *, long);
 extern void x86_mce_vector_register(x86_mce_vector_t);
@@ -166,12 +157,6 @@ void *x86_mcinfo_add(struct mc_info *mi,
 void *x86_mcinfo_reserve(struct mc_info *mi, int size);
 void x86_mcinfo_dump(struct mc_info *mi);
 
-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);
-
 static inline int mce_vendor_bank_msr(const struct vcpu *v, uint32_t msr)
 {
     switch (boot_cpu_data.x86_vendor) {
diff -r fc4140ec1d59 -r 77837828f6c3 xen/arch/x86/cpu/mcheck/mce_intel.c
--- a/xen/arch/x86/cpu/mcheck/mce_intel.c
+++ b/xen/arch/x86/cpu/mcheck/mce_intel.c
@@ -18,6 +18,7 @@
 #include "x86_mca.h"
 #include "barrier.h"
 #include "util.h"
+#include "vmce.h"
 
 DEFINE_PER_CPU(struct mca_banks *, mce_banks_owned);
 DEFINE_PER_CPU(struct mca_banks *, no_cmci_banks);
@@ -980,7 +981,7 @@ enum mcheck_type intel_mcheck_init(struc
 }
 
 /* intel specific MCA MSR */
-int intel_mce_wrmsr(struct vcpu *v, uint32_t msr, uint64_t val)
+int vmce_intel_wrmsr(struct vcpu *v, uint32_t msr, uint64_t val)
 {
     int ret = 0;
 
@@ -995,7 +996,7 @@ int intel_mce_wrmsr(struct vcpu *v, uint
     return ret;
 }
 
-int intel_mce_rdmsr(const struct vcpu *v, uint32_t msr, uint64_t *val)
+int vmce_intel_rdmsr(const struct vcpu *v, uint32_t msr, uint64_t *val)
 {
     int ret = 0;
 
diff -r fc4140ec1d59 -r 77837828f6c3 xen/arch/x86/cpu/mcheck/non-fatal.c
--- a/xen/arch/x86/cpu/mcheck/non-fatal.c
+++ b/xen/arch/x86/cpu/mcheck/non-fatal.c
@@ -21,6 +21,7 @@
 #include <asm/msr.h>
 
 #include "mce.h"
+#include "vmce.h"
 
 DEFINE_PER_CPU(struct mca_banks *, poll_bankmask);
 static struct timer mce_timer;
diff -r fc4140ec1d59 -r 77837828f6c3 xen/arch/x86/cpu/mcheck/vmce.c
--- a/xen/arch/x86/cpu/mcheck/vmce.c
+++ b/xen/arch/x86/cpu/mcheck/vmce.c
@@ -16,8 +16,10 @@
 #include <asm/system.h>
 #include <asm/msr.h>
 #include <asm/p2m.h>
+
 #include "mce.h"
 #include "x86_mca.h"
+#include "vmce.h"
 
 /*
  * Emulate 2 banks for guest
@@ -27,7 +29,7 @@
  * Bank1: used to transfer error info to guest
  */
 #define GUEST_BANK_NUM 2
-#define GUEST_MCG_CAP (MCG_TES_P | MCG_SER_P | GUEST_BANK_NUM)
+#define GUEST_MCG_CAP (GUEST_BANK_NUM)
 
 #define dom_vmce(x)   ((x)->arch.vmca_msrs)
 
@@ -138,7 +140,10 @@ static int bank_mce_rdmsr(const struct v
         switch ( boot_cpu_data.x86_vendor )
         {
         case X86_VENDOR_INTEL:
-            ret = intel_mce_rdmsr(v, msr, val);
+            ret = vmce_intel_rdmsr(v, msr, val);
+            break;
+        case X86_VENDOR_AMD:
+            ret = vmce_amd_rdmsr(v, msr, val);
             break;
         default:
             ret = 0;
@@ -193,7 +198,7 @@ int vmce_rdmsr(uint32_t msr, uint64_t *v
     return ret;
 }
 
-static int bank_mce_wrmsr(struct vcpu *v, u32 msr, u64 val)
+static int bank_mce_wrmsr(struct vcpu *v, uint32_t msr, uint64_t val)
 {
     int ret = 1;
     unsigned int bank = (msr - MSR_IA32_MC0_CTL) / 4;
@@ -266,7 +271,10 @@ static int bank_mce_wrmsr(struct vcpu *v
         switch ( boot_cpu_data.x86_vendor )
         {
         case X86_VENDOR_INTEL:
-            ret = intel_mce_wrmsr(v, msr, val);
+            ret = vmce_intel_wrmsr(v, msr, val);
+            break;
+        case X86_VENDOR_AMD:
+            ret = vmce_amd_wrmsr(v, msr, val);
             break;
         default:
             ret = 0;
@@ -283,7 +291,7 @@ static int bank_mce_wrmsr(struct vcpu *v
  * = 0: Not handled, should be handled by other components
  * > 0: Success
  */
-int vmce_wrmsr(u32 msr, u64 val)
+int vmce_wrmsr(uint32_t msr, uint64_t val)
 {
     struct vcpu *cur = current;
     struct bank_entry *entry = NULL;
diff -r fc4140ec1d59 -r 77837828f6c3 xen/arch/x86/cpu/mcheck/vmce.h
--- /dev/null
+++ b/xen/arch/x86/cpu/mcheck/vmce.h
@@ -0,0 +1,25 @@
+#ifndef _MCHECK_VMCE_H
+#define _MCHECK_VMCE_H
+
+#include "x86_mca.h"
+
+int vmce_init(struct cpuinfo_x86 *c);
+
+#define dom0_vmce_enabled() (dom0 && dom0->max_vcpus && dom0->vcpu[0] \
+        && guest_enabled_event(dom0->vcpu[0], VIRQ_MCA))
+
+int is_vmce_ready(struct mcinfo_bank *bank, struct domain *d);
+int unmmap_broken_page(struct domain *d, mfn_t mfn, unsigned long gfn);
+
+int vmce_intel_rdmsr(const struct vcpu *, uint32_t msr, uint64_t *val);
+int vmce_intel_wrmsr(struct vcpu *, uint32_t msr, uint64_t val);
+int vmce_amd_rdmsr(const struct vcpu *, uint32_t msr, uint64_t *val);
+int vmce_amd_wrmsr(struct vcpu *, uint32_t msr, uint64_t val);
+
+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);
+
+#endif

--------------000502070207040100090601
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--------------000502070207040100090601--


From xen-devel-bounces@lists.xen.org Tue Sep 18 10:50:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Sep 2012 10:50: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 1TDvNN-0001V2-QH; Tue, 18 Sep 2012 10:49:57 +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 1TDvNL-0001Ux-LL
	for xen-devel@lists.xen.org; Tue, 18 Sep 2012 10:49:56 +0000
Received: from [85.158.139.83:56054] by server-11.bemta-5.messagelabs.com id
	8B/50-24658-2D158505; Tue, 18 Sep 2012 10:49:54 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1347965392!30996476!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNzU0NzY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32501 invoked from network); 18 Sep 2012 10:49:54 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-3.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Sep 2012 10:49:54 -0000
X-IronPort-AV: E=Sophos;i="4.80,442,1344211200"; d="scan'208";a="208395795"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Sep 2012 10:49:52 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1;
	Tue, 18 Sep 2012 06:49:51 -0400
Received: from [10.80.3.61]	by ukmail1.uk.xensource.com with esmtp (Exim 4.69)
	(envelope-from <anthony.perard@citrix.com>)	id 1TDvNH-0006zq-Id;
	Tue, 18 Sep 2012 11:49:51 +0100
Message-ID: <505851CF.2090000@citrix.com>
Date: Tue, 18 Sep 2012 11:49:51 +0100
From: Anthony PERARD <anthony.perard@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120910 Thunderbird/15.0.1
MIME-Version: 1.0
To: "Zhang, Yang Z" <yang.z.zhang@intel.com>
References: <A9667DDFB95DB7438FA9D7D576C3D87E203D54@SHSMSX101.ccr.corp.intel.com>
	<alpine.DEB.2.02.1208031122170.4645@kaball.uk.xensource.com>
	<1343990187.21372.48.camel@zakaz.uk.xensource.com>
	<40352EBA8B4DF841A9907B883F22B59B0FDBCE1E@SHSMSX102.ccr.corp.intel.com>
	<40352EBA8B4DF841A9907B883F22B59B0FDD25C7@SHSMSX102.ccr.corp.intel.com>
	<A9667DDFB95DB7438FA9D7D576C3D87E258EF6@SHSMSX101.ccr.corp.intel.com>
In-Reply-To: <A9667DDFB95DB7438FA9D7D576C3D87E258EF6@SHSMSX101.ccr.corp.intel.com>
Cc: xen-devel <xen-devel@lists.xen.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>, "Shan,
	Haitao" <haitao.shan@intel.com>, "Zhou, Chao" <chao.zhou@intel.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] error when pass through device to	guest	with
	qemu-xen-dir-remote
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 09/18/2012 01:46 AM, Zhang, Yang Z wrote:
> Zhang, Yang Z wrote on 2012-09-11:
>>   wrote on August 09, 2012 2:49 PM To: Ian Campbell; Stefano Stabellini:
>>> I rebuild the upstream QEMU according to the wiki, but device static
>>> assignment doesn't work, no lspci output in guest. However hotplug &
>>> unplug works fine.
>>>
>>> -----Original Message----- From: xen-devel-bounces@lists.xen.org
>>> [mailto:xen-devel-bounces@lists.xen.org] On Behalf Of Ian Campbell Sent:
>>> Friday, August 03, 2012 6:36 PM To: Stefano Stabellini Cc: Zhang, Yang
>>> Z; Anthony Perard; xen-devel Subject: Re: [Xen-devel] error when pass
>>> through device to guest with qemu-xen-dir-remote
>>>
>>> On Fri, 2012-08-03 at 11:29 +0100, Stefano Stabellini wrote:
>>>> On Fri, 3 Aug 2012, Zhang, Yang Z wrote:
>>>>> When create guest with device assigned, it shows the error and the
>>>>> device wasn't able to work inside guest: libxl: error:
>>>>> libxl_qmp.c:288:qmp_handle_error_response: received an error message
>>>>> from QMP server: Parameter 'driver' expects a driver name
>>>>>
>>>>> It only fails with qemu-xen-dir-remote(Is this tree more close to
>>>>> upstream qemu?). I don't see the error with the traditional Qemu. I
>>>>> also tried qemu-upstream, but it fails when I try to enable pci
>>>>> pass-through
>>> for xen. I think Anthony's patch to add pci pass-through support for Xen is
>>> accepted by qemu-upstream, am I right?
>>>>
>>>> Yes, it was accepted, but it is present only in upstream QEMU (from
>>>> git://git.qemu.org/qemu.git), not the tree we are currently using in
>>>> xen-unstable for development
>>>> (git://xenbits.xensource.com/qemu-upstream-unstable.git).
>>>> Make sure you are using the right tree!
>>>
>>> http://wiki.xen.org/wiki/QEMU_Upstream has some notes on how to use the
>>> upstream qemu tree instead of our stable branch of upstream.
>>>
>>>>
>>>> Anthony is currently on vacation and is going to be back in about a
>>>> week.
>>>>
>>>>> Another question:
>>>>> Now I am trying to add some features (relevant to pass through device) to
>>> Qemu, which tree should I use? Since traditional qemu is great
>>> different from qemu-upstream, it is too old to develop patch base on
>>> it. But besides the old one, I cannot find a working qemu.
>>>>
>>>> You should use upstream QEMU, I am going to rebase our tree on that
>>>> early on in the 4.3 release cycle.
>>
>> Hi Anthony
>>
>> I found the issue is caused by PV driver. Since RHEL6 integrated PV driver by
>> default, when booting rhel6 as guest, it will load the PV driver and write the xen
>> platform device to notify qemu to unplug all NICs including the pass through
>> device. This definitely is wrong. We only need to unplug the emulator device, and
>> leave pass through device.
>
> Hi Anthony,
>
> Any comments for this?

Hi,

So, we'll have to add a check in the unplug code of qemu to ignore 
passthrough devices.

Here is a patches, I did not test it.

diff --git a/hw/xen_platform.c b/hw/xen_platform.c
index 0d6c2ff..2d3978e 100644
--- a/hw/xen_platform.c
+++ b/hw/xen_platform.c
@@ -85,8 +85,10 @@ static void log_writeb ...

  static void unplug_nic(PCIBus *b, PCIDevice *d, void *o)
  {
+    /* We have to ignore passthrough devices */
      if (pci_get_word(d->config + PCI_CLASS_DEVICE) ==
-            PCI_CLASS_NETWORK_ETHERNET) {
+            PCI_CLASS_NETWORK_ETHERNET
+        && strcmp(d->name, "xen-pci-passthrough") != 0) {
          qdev_free(&d->qdev);
      }
  }


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 Tue Sep 18 10:50:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Sep 2012 10:50: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 1TDvNN-0001V2-QH; Tue, 18 Sep 2012 10:49:57 +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 1TDvNL-0001Ux-LL
	for xen-devel@lists.xen.org; Tue, 18 Sep 2012 10:49:56 +0000
Received: from [85.158.139.83:56054] by server-11.bemta-5.messagelabs.com id
	8B/50-24658-2D158505; Tue, 18 Sep 2012 10:49:54 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1347965392!30996476!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNzU0NzY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32501 invoked from network); 18 Sep 2012 10:49:54 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-3.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Sep 2012 10:49:54 -0000
X-IronPort-AV: E=Sophos;i="4.80,442,1344211200"; d="scan'208";a="208395795"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Sep 2012 10:49:52 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1;
	Tue, 18 Sep 2012 06:49:51 -0400
Received: from [10.80.3.61]	by ukmail1.uk.xensource.com with esmtp (Exim 4.69)
	(envelope-from <anthony.perard@citrix.com>)	id 1TDvNH-0006zq-Id;
	Tue, 18 Sep 2012 11:49:51 +0100
Message-ID: <505851CF.2090000@citrix.com>
Date: Tue, 18 Sep 2012 11:49:51 +0100
From: Anthony PERARD <anthony.perard@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120910 Thunderbird/15.0.1
MIME-Version: 1.0
To: "Zhang, Yang Z" <yang.z.zhang@intel.com>
References: <A9667DDFB95DB7438FA9D7D576C3D87E203D54@SHSMSX101.ccr.corp.intel.com>
	<alpine.DEB.2.02.1208031122170.4645@kaball.uk.xensource.com>
	<1343990187.21372.48.camel@zakaz.uk.xensource.com>
	<40352EBA8B4DF841A9907B883F22B59B0FDBCE1E@SHSMSX102.ccr.corp.intel.com>
	<40352EBA8B4DF841A9907B883F22B59B0FDD25C7@SHSMSX102.ccr.corp.intel.com>
	<A9667DDFB95DB7438FA9D7D576C3D87E258EF6@SHSMSX101.ccr.corp.intel.com>
In-Reply-To: <A9667DDFB95DB7438FA9D7D576C3D87E258EF6@SHSMSX101.ccr.corp.intel.com>
Cc: xen-devel <xen-devel@lists.xen.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>, "Shan,
	Haitao" <haitao.shan@intel.com>, "Zhou, Chao" <chao.zhou@intel.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] error when pass through device to	guest	with
	qemu-xen-dir-remote
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 09/18/2012 01:46 AM, Zhang, Yang Z wrote:
> Zhang, Yang Z wrote on 2012-09-11:
>>   wrote on August 09, 2012 2:49 PM To: Ian Campbell; Stefano Stabellini:
>>> I rebuild the upstream QEMU according to the wiki, but device static
>>> assignment doesn't work, no lspci output in guest. However hotplug &
>>> unplug works fine.
>>>
>>> -----Original Message----- From: xen-devel-bounces@lists.xen.org
>>> [mailto:xen-devel-bounces@lists.xen.org] On Behalf Of Ian Campbell Sent:
>>> Friday, August 03, 2012 6:36 PM To: Stefano Stabellini Cc: Zhang, Yang
>>> Z; Anthony Perard; xen-devel Subject: Re: [Xen-devel] error when pass
>>> through device to guest with qemu-xen-dir-remote
>>>
>>> On Fri, 2012-08-03 at 11:29 +0100, Stefano Stabellini wrote:
>>>> On Fri, 3 Aug 2012, Zhang, Yang Z wrote:
>>>>> When create guest with device assigned, it shows the error and the
>>>>> device wasn't able to work inside guest: libxl: error:
>>>>> libxl_qmp.c:288:qmp_handle_error_response: received an error message
>>>>> from QMP server: Parameter 'driver' expects a driver name
>>>>>
>>>>> It only fails with qemu-xen-dir-remote(Is this tree more close to
>>>>> upstream qemu?). I don't see the error with the traditional Qemu. I
>>>>> also tried qemu-upstream, but it fails when I try to enable pci
>>>>> pass-through
>>> for xen. I think Anthony's patch to add pci pass-through support for Xen is
>>> accepted by qemu-upstream, am I right?
>>>>
>>>> Yes, it was accepted, but it is present only in upstream QEMU (from
>>>> git://git.qemu.org/qemu.git), not the tree we are currently using in
>>>> xen-unstable for development
>>>> (git://xenbits.xensource.com/qemu-upstream-unstable.git).
>>>> Make sure you are using the right tree!
>>>
>>> http://wiki.xen.org/wiki/QEMU_Upstream has some notes on how to use the
>>> upstream qemu tree instead of our stable branch of upstream.
>>>
>>>>
>>>> Anthony is currently on vacation and is going to be back in about a
>>>> week.
>>>>
>>>>> Another question:
>>>>> Now I am trying to add some features (relevant to pass through device) to
>>> Qemu, which tree should I use? Since traditional qemu is great
>>> different from qemu-upstream, it is too old to develop patch base on
>>> it. But besides the old one, I cannot find a working qemu.
>>>>
>>>> You should use upstream QEMU, I am going to rebase our tree on that
>>>> early on in the 4.3 release cycle.
>>
>> Hi Anthony
>>
>> I found the issue is caused by PV driver. Since RHEL6 integrated PV driver by
>> default, when booting rhel6 as guest, it will load the PV driver and write the xen
>> platform device to notify qemu to unplug all NICs including the pass through
>> device. This definitely is wrong. We only need to unplug the emulator device, and
>> leave pass through device.
>
> Hi Anthony,
>
> Any comments for this?

Hi,

So, we'll have to add a check in the unplug code of qemu to ignore 
passthrough devices.

Here is a patches, I did not test it.

diff --git a/hw/xen_platform.c b/hw/xen_platform.c
index 0d6c2ff..2d3978e 100644
--- a/hw/xen_platform.c
+++ b/hw/xen_platform.c
@@ -85,8 +85,10 @@ static void log_writeb ...

  static void unplug_nic(PCIBus *b, PCIDevice *d, void *o)
  {
+    /* We have to ignore passthrough devices */
      if (pci_get_word(d->config + PCI_CLASS_DEVICE) ==
-            PCI_CLASS_NETWORK_ETHERNET) {
+            PCI_CLASS_NETWORK_ETHERNET
+        && strcmp(d->name, "xen-pci-passthrough") != 0) {
          qdev_free(&d->qdev);
      }
  }


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 Tue Sep 18 10:52:48 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Sep 2012 10:52:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDvPo-0001aX-C4; Tue, 18 Sep 2012 10:52:28 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jmarcet@gmail.com>) id 1TDvPn-0001aP-B9
	for xen-devel@lists.xen.org; Tue, 18 Sep 2012 10:52:27 +0000
Received: from [85.158.143.99:11942] by server-1.bemta-4.messagelabs.com id
	38/CE-12504-A6258505; Tue, 18 Sep 2012 10:52:26 +0000
X-Env-Sender: jmarcet@gmail.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1347965541!21191262!1
X-Originating-IP: [209.85.219.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7491 invoked from network); 18 Sep 2012 10:52:26 -0000
Received: from mail-oa0-f45.google.com (HELO mail-oa0-f45.google.com)
	(209.85.219.45)
	by server-14.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Sep 2012 10:52:26 -0000
Received: by oagn12 with SMTP id n12so7365956oag.32
	for <xen-devel@lists.xen.org>; Tue, 18 Sep 2012 03:52: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=qF+Jn2Bxox1JSf1KqmJ37wsBsI6c2nZKC9Ir2OereyU=;
	b=UddgNsMQsqeq5adWcPR74sfX3XU65BxGc4g36YK+m4stOC/0s6DdbGCPIgqEplwT2E
	GdaVFxmZcAf1Qz1zIb9SH9o7dzgIWYJdwFjz82Xb9aUVP4uNmVrLPQ9gG+RBe3zmJdur
	QLa20mOozp4K2M6gqF64z650bZ1PB9so3ckaaam8/1QoBOJqEZtgPYJVJrjZeIm/XEmZ
	Rag2BgtoErRgJ8CK22BdtsHdipQIx3Ofpt/VtKSrKfehiMUbs8BAPOp9DsxKLyS2gW2q
	lnAAwab6wSQDxvK0q6iO5XGqNGXcPEIq7ODbrqwiehH9FI0DJAhWOh6BIs6UoaREnGdq
	GdyQ==
Received: by 10.182.44.74 with SMTP id c10mr14824035obm.29.1347965541499; Tue,
	18 Sep 2012 03:52:21 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.60.138.225 with HTTP; Tue, 18 Sep 2012 03:52:01 -0700 (PDT)
In-Reply-To: <CC7DF5F7.3F018%keir.xen@gmail.com>
References: <CAAnFQG9PuzRLSsCS8m_0VUeV+ZaCwK3zsbinxtuFBfdSihJknw@mail.gmail.com>
	<CC7DF5F7.3F018%keir.xen@gmail.com>
From: Javier Marcet <jmarcet@gmail.com>
Date: Tue, 18 Sep 2012 12:52:01 +0200
Message-ID: <CAAnFQG96=Fm5jLqvaqxd6nf2fDAeL6t7drxqkqXzvZHYDOKaDQ@mail.gmail.com>
To: Keir Fraser <keir.xen@gmail.com>
Cc: Konrad Rzeszutek Wilk <konrad@kernel.org>,
	Xen Devel Mailing list <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.2.0-rc4 issues with DVB tuner
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gVHVlLCBTZXAgMTgsIDIwMTIgYXQgMTA6NTcgQU0sIEtlaXIgRnJhc2VyIDxrZWlyLnhlbkBn
bWFpbC5jb20+IHdyb3RlOgoKPj4gV2hhdCBJIGRvbsK0dCB1bmRlcnN0YW5kIGlzIGhvdyBncmFw
aGljcyBwYXNzIHRocm91Z2ggZXZlbiB3b3Jrcwo+IGFuZCBhIHR1bmVyCj4+IGNhcmQgaGFzIHBy
b2JsZW1zIGR1ZSB0byB0aGUgaW50cm9kdWNlZCBsYXRlbmNpZXMgaW4gdGhlCj4gSVJRcy4KPgo+
IERvIHlvdSBoYXZlCj4+IGFueSBtb3JlIGluZm8gYWJvdXQgdGhpcz8KPgo+IEluIHRoaXMgcmVz
cGVjdCBzb3VuZCBpcyBoYXJkZXIgdGhhbiBncmFwaGljcy4gVHJ5IHBpbm5pbmcgeW91ciBkb20w
IHRvIGEKPiBDUFUgY29yZSwgYW5kIHNldCBhZmZpbml0aWVzIG9uIG90aGVyIGRvbWFpbnMgc28g
dGhhdCBkb20wIGRvZXMgbm90IGNvbXBldGUKPiBmb3IgdGhlIGNvcmUgd2l0aCBhbnkgb3RoZXIg
ZG9tYWlucy4KCkFsbCByaWdodCwgSSBjYW4gdHJ5IHRoYXQuIEhvd2V2ZXIsIHRoZSBwcm9ibGVt
IGhhcHBlbnMgd2l0aG91dCBhbnkKZG9tVSBydW5uaW5nLCBqdXN0CnRoZSBkb20wLiBEbyB5b3Ug
c3RpbGwgdGhpbmsgdGhhdCBwaW5uaW5nIHRvIGEgY3B1IGNvcmUgb3Igc2V0dGluZwphZmZpbml0
aWVzIGNhbiBoZWxwPwoKCi0tIApKYXZpZXIgTWFyY2V0IDxqbWFyY2V0QGdtYWlsLmNvbT4KCl9f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fClhlbi1kZXZlbCBt
YWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbi5vcmcKaHR0cDovL2xpc3RzLnhlbi5vcmcv
eGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Tue Sep 18 10:52:48 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Sep 2012 10:52:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDvPo-0001aX-C4; Tue, 18 Sep 2012 10:52:28 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jmarcet@gmail.com>) id 1TDvPn-0001aP-B9
	for xen-devel@lists.xen.org; Tue, 18 Sep 2012 10:52:27 +0000
Received: from [85.158.143.99:11942] by server-1.bemta-4.messagelabs.com id
	38/CE-12504-A6258505; Tue, 18 Sep 2012 10:52:26 +0000
X-Env-Sender: jmarcet@gmail.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1347965541!21191262!1
X-Originating-IP: [209.85.219.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7491 invoked from network); 18 Sep 2012 10:52:26 -0000
Received: from mail-oa0-f45.google.com (HELO mail-oa0-f45.google.com)
	(209.85.219.45)
	by server-14.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Sep 2012 10:52:26 -0000
Received: by oagn12 with SMTP id n12so7365956oag.32
	for <xen-devel@lists.xen.org>; Tue, 18 Sep 2012 03:52: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=qF+Jn2Bxox1JSf1KqmJ37wsBsI6c2nZKC9Ir2OereyU=;
	b=UddgNsMQsqeq5adWcPR74sfX3XU65BxGc4g36YK+m4stOC/0s6DdbGCPIgqEplwT2E
	GdaVFxmZcAf1Qz1zIb9SH9o7dzgIWYJdwFjz82Xb9aUVP4uNmVrLPQ9gG+RBe3zmJdur
	QLa20mOozp4K2M6gqF64z650bZ1PB9so3ckaaam8/1QoBOJqEZtgPYJVJrjZeIm/XEmZ
	Rag2BgtoErRgJ8CK22BdtsHdipQIx3Ofpt/VtKSrKfehiMUbs8BAPOp9DsxKLyS2gW2q
	lnAAwab6wSQDxvK0q6iO5XGqNGXcPEIq7ODbrqwiehH9FI0DJAhWOh6BIs6UoaREnGdq
	GdyQ==
Received: by 10.182.44.74 with SMTP id c10mr14824035obm.29.1347965541499; Tue,
	18 Sep 2012 03:52:21 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.60.138.225 with HTTP; Tue, 18 Sep 2012 03:52:01 -0700 (PDT)
In-Reply-To: <CC7DF5F7.3F018%keir.xen@gmail.com>
References: <CAAnFQG9PuzRLSsCS8m_0VUeV+ZaCwK3zsbinxtuFBfdSihJknw@mail.gmail.com>
	<CC7DF5F7.3F018%keir.xen@gmail.com>
From: Javier Marcet <jmarcet@gmail.com>
Date: Tue, 18 Sep 2012 12:52:01 +0200
Message-ID: <CAAnFQG96=Fm5jLqvaqxd6nf2fDAeL6t7drxqkqXzvZHYDOKaDQ@mail.gmail.com>
To: Keir Fraser <keir.xen@gmail.com>
Cc: Konrad Rzeszutek Wilk <konrad@kernel.org>,
	Xen Devel Mailing list <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.2.0-rc4 issues with DVB tuner
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gVHVlLCBTZXAgMTgsIDIwMTIgYXQgMTA6NTcgQU0sIEtlaXIgRnJhc2VyIDxrZWlyLnhlbkBn
bWFpbC5jb20+IHdyb3RlOgoKPj4gV2hhdCBJIGRvbsK0dCB1bmRlcnN0YW5kIGlzIGhvdyBncmFw
aGljcyBwYXNzIHRocm91Z2ggZXZlbiB3b3Jrcwo+IGFuZCBhIHR1bmVyCj4+IGNhcmQgaGFzIHBy
b2JsZW1zIGR1ZSB0byB0aGUgaW50cm9kdWNlZCBsYXRlbmNpZXMgaW4gdGhlCj4gSVJRcy4KPgo+
IERvIHlvdSBoYXZlCj4+IGFueSBtb3JlIGluZm8gYWJvdXQgdGhpcz8KPgo+IEluIHRoaXMgcmVz
cGVjdCBzb3VuZCBpcyBoYXJkZXIgdGhhbiBncmFwaGljcy4gVHJ5IHBpbm5pbmcgeW91ciBkb20w
IHRvIGEKPiBDUFUgY29yZSwgYW5kIHNldCBhZmZpbml0aWVzIG9uIG90aGVyIGRvbWFpbnMgc28g
dGhhdCBkb20wIGRvZXMgbm90IGNvbXBldGUKPiBmb3IgdGhlIGNvcmUgd2l0aCBhbnkgb3RoZXIg
ZG9tYWlucy4KCkFsbCByaWdodCwgSSBjYW4gdHJ5IHRoYXQuIEhvd2V2ZXIsIHRoZSBwcm9ibGVt
IGhhcHBlbnMgd2l0aG91dCBhbnkKZG9tVSBydW5uaW5nLCBqdXN0CnRoZSBkb20wLiBEbyB5b3Ug
c3RpbGwgdGhpbmsgdGhhdCBwaW5uaW5nIHRvIGEgY3B1IGNvcmUgb3Igc2V0dGluZwphZmZpbml0
aWVzIGNhbiBoZWxwPwoKCi0tIApKYXZpZXIgTWFyY2V0IDxqbWFyY2V0QGdtYWlsLmNvbT4KCl9f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fClhlbi1kZXZlbCBt
YWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbi5vcmcKaHR0cDovL2xpc3RzLnhlbi5vcmcv
eGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Tue Sep 18 10:55:53 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Sep 2012 10:55:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDvSp-0001jc-Ut; Tue, 18 Sep 2012 10:55:35 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <lukas@laukamp.me>) id 1TDvSo-0001jW-Kv
	for xen-devel@lists.xen.org; Tue, 18 Sep 2012 10:55:34 +0000
Received: from [85.158.143.99:28419] by server-1.bemta-4.messagelabs.com id
	F3/E3-12504-52358505; Tue, 18 Sep 2012 10:55:33 +0000
X-Env-Sender: lukas@laukamp.me
X-Msg-Ref: server-11.tower-216.messagelabs.com!1347965732!23280095!1
X-Originating-IP: [5.9.218.245]
X-SpamReason: No, hits=0.2 required=7.0 tests=RCVD_ILLEGAL_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5082 invoked from network); 18 Sep 2012 10:55:32 -0000
Received: from mailer0.lippux.de (HELO mailer0.lippux.de) (5.9.218.245)
	by server-11.tower-216.messagelabs.com with SMTP;
	18 Sep 2012 10:55:32 -0000
Received: from localhost (localhost [127.0.0.1])
	by mailer0.lippux.de (Postfix) with ESMTP id E4084421F1E
	for <xen-devel@lists.xen.org>; Tue, 18 Sep 2012 12:55:31 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at mailer0.lippux.de
Received: from mailer0.lippux.de ([127.0.0.1])
	by localhost (mailer0.lippux.de [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id H6RSnPsi2r4M for <xen-devel@lists.xen.org>;
	Tue, 18 Sep 2012 12:55:31 +0200 (CEST)
Received: by mailer0.lippux.de (Postfix, from userid 33)
	id 9EAA7421F20; Tue, 18 Sep 2012 12:55:31 +0200 (CEST)
To: <xen-devel@lists.xen.org>
X-PHP-Originating-Script: 0:main.inc
MIME-Version: 1.0
Date: Tue, 18 Sep 2012 12:55:31 +0200
From: Lukas Laukamp <lukas@laukamp.me>
Message-ID: <b83b0a91d6f2612e2942f37270c8da21@laukamp.me>
X-Sender: lukas@laukamp.me
User-Agent: Roundcube Webmail/0.7.1
Subject: [Xen-devel] [User-Question] Xen 4.2 compilation hangs at stubdom
	directory
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
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 all,

I know that here is not the best place to ask such a question but I 
think that it's eventualy a problem of the source.

I want to create deb packages of Xen 4.2 for Ubuntu 12.04 LTS. So I 
created an build environment with pbuilder, installed all dependencies 
and startet the compilation of Xen.

So now the problem is that the compilation hangs without any reason in 
the stubdom directory. So there is no error output or something like 
this, it simply hangs and don't continue.

As compiler I use GCC 4.6, with debhelper I created the Debian rules 
files and I used the dist target.

Is this a known issue or is it a problem of my configuration? Would be 
greate to get help, Xen 4.2 is a real milestone and I can only say "Go 
on guys, good work".

Best Regards

P.S. Sorry for my bad english

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 18 10:55:53 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Sep 2012 10:55:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDvSp-0001jc-Ut; Tue, 18 Sep 2012 10:55:35 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <lukas@laukamp.me>) id 1TDvSo-0001jW-Kv
	for xen-devel@lists.xen.org; Tue, 18 Sep 2012 10:55:34 +0000
Received: from [85.158.143.99:28419] by server-1.bemta-4.messagelabs.com id
	F3/E3-12504-52358505; Tue, 18 Sep 2012 10:55:33 +0000
X-Env-Sender: lukas@laukamp.me
X-Msg-Ref: server-11.tower-216.messagelabs.com!1347965732!23280095!1
X-Originating-IP: [5.9.218.245]
X-SpamReason: No, hits=0.2 required=7.0 tests=RCVD_ILLEGAL_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5082 invoked from network); 18 Sep 2012 10:55:32 -0000
Received: from mailer0.lippux.de (HELO mailer0.lippux.de) (5.9.218.245)
	by server-11.tower-216.messagelabs.com with SMTP;
	18 Sep 2012 10:55:32 -0000
Received: from localhost (localhost [127.0.0.1])
	by mailer0.lippux.de (Postfix) with ESMTP id E4084421F1E
	for <xen-devel@lists.xen.org>; Tue, 18 Sep 2012 12:55:31 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at mailer0.lippux.de
Received: from mailer0.lippux.de ([127.0.0.1])
	by localhost (mailer0.lippux.de [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id H6RSnPsi2r4M for <xen-devel@lists.xen.org>;
	Tue, 18 Sep 2012 12:55:31 +0200 (CEST)
Received: by mailer0.lippux.de (Postfix, from userid 33)
	id 9EAA7421F20; Tue, 18 Sep 2012 12:55:31 +0200 (CEST)
To: <xen-devel@lists.xen.org>
X-PHP-Originating-Script: 0:main.inc
MIME-Version: 1.0
Date: Tue, 18 Sep 2012 12:55:31 +0200
From: Lukas Laukamp <lukas@laukamp.me>
Message-ID: <b83b0a91d6f2612e2942f37270c8da21@laukamp.me>
X-Sender: lukas@laukamp.me
User-Agent: Roundcube Webmail/0.7.1
Subject: [Xen-devel] [User-Question] Xen 4.2 compilation hangs at stubdom
	directory
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
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 all,

I know that here is not the best place to ask such a question but I 
think that it's eventualy a problem of the source.

I want to create deb packages of Xen 4.2 for Ubuntu 12.04 LTS. So I 
created an build environment with pbuilder, installed all dependencies 
and startet the compilation of Xen.

So now the problem is that the compilation hangs without any reason in 
the stubdom directory. So there is no error output or something like 
this, it simply hangs and don't continue.

As compiler I use GCC 4.6, with debhelper I created the Debian rules 
files and I used the dist target.

Is this a known issue or is it a problem of my configuration? Would be 
greate to get help, Xen 4.2 is a real milestone and I can only say "Go 
on guys, good work".

Best Regards

P.S. Sorry for my bad english

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 18 11:10:11 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Sep 2012 11:10:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDvgf-00022C-Am; Tue, 18 Sep 2012 11:09:53 +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 1TDvgd-000227-L2
	for xen-devel@lists.xen.org; Tue, 18 Sep 2012 11:09:51 +0000
Received: from [85.158.139.211:60156] by server-11.bemta-5.messagelabs.com id
	3B/BC-24658-E7658505; Tue, 18 Sep 2012 11:09:50 +0000
X-Env-Sender: james.harper@bendigoit.com.au
X-Msg-Ref: server-10.tower-206.messagelabs.com!1347966587!18978003!1
X-Originating-IP: [203.16.207.99]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14829 invoked from network); 18 Sep 2012 11:09:50 -0000
Received: from smtp2.bendigoit.com.au (HELO smtp2.bendigoit.com.au)
	(203.16.207.99)
	by server-10.tower-206.messagelabs.com with AES256-SHA encrypted SMTP;
	18 Sep 2012 11:09:50 -0000
Received: from [2001:388:e000:712:a5ca:4fd3:14f:ad5d]
	(helo=BITCOM1.int.sbss.com.au)
	by smtp2.bendigoit.com.au with esmtp (Exim 4.72)
	(envelope-from <james.harper@bendigoit.com.au>) id 1TDvgW-0002ni-OR
	for xen-devel@lists.xen.org; Tue, 18 Sep 2012 21:09:44 +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 id
	14.01.0379.000; Tue, 18 Sep 2012 21:09:44 +1000
From: James Harper <james.harper@bendigoit.com.au>
To: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Thread-Topic: xen domu core dump memory
Thread-Index: Ac2VjeAZllKvsV2+QLqk5sJb54nKkg==
Date: Tue, 18 Sep 2012 11:09:44 +0000
Message-ID: <6035A0D088A63A46850C3988ED045A4B29BA36FF@BITCOM1.int.sbss.com.au>
Accept-Language: en-AU, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [172.16.3.132]
x-tm-as-product-ver: SMEX-10.2.0.2087-7.000.1014-19190.006
x-tm-as-result: No--24.253300-0.000000-31
x-tm-as-user-approved-sender: Yes
x-tm-as-user-blocked-sender: No
MIME-Version: 1.0
X-Really-From-Bendigo-IT: magichashvalue
Subject: [Xen-devel] xen domu core dump memory
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

In the .xen_pages section of a core dump, is the layout of pages 1:1 with DomU "physical" memory, or are there holes?

Thanks

James


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 18 11:10:11 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Sep 2012 11:10:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDvgf-00022C-Am; Tue, 18 Sep 2012 11:09:53 +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 1TDvgd-000227-L2
	for xen-devel@lists.xen.org; Tue, 18 Sep 2012 11:09:51 +0000
Received: from [85.158.139.211:60156] by server-11.bemta-5.messagelabs.com id
	3B/BC-24658-E7658505; Tue, 18 Sep 2012 11:09:50 +0000
X-Env-Sender: james.harper@bendigoit.com.au
X-Msg-Ref: server-10.tower-206.messagelabs.com!1347966587!18978003!1
X-Originating-IP: [203.16.207.99]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14829 invoked from network); 18 Sep 2012 11:09:50 -0000
Received: from smtp2.bendigoit.com.au (HELO smtp2.bendigoit.com.au)
	(203.16.207.99)
	by server-10.tower-206.messagelabs.com with AES256-SHA encrypted SMTP;
	18 Sep 2012 11:09:50 -0000
Received: from [2001:388:e000:712:a5ca:4fd3:14f:ad5d]
	(helo=BITCOM1.int.sbss.com.au)
	by smtp2.bendigoit.com.au with esmtp (Exim 4.72)
	(envelope-from <james.harper@bendigoit.com.au>) id 1TDvgW-0002ni-OR
	for xen-devel@lists.xen.org; Tue, 18 Sep 2012 21:09:44 +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 id
	14.01.0379.000; Tue, 18 Sep 2012 21:09:44 +1000
From: James Harper <james.harper@bendigoit.com.au>
To: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Thread-Topic: xen domu core dump memory
Thread-Index: Ac2VjeAZllKvsV2+QLqk5sJb54nKkg==
Date: Tue, 18 Sep 2012 11:09:44 +0000
Message-ID: <6035A0D088A63A46850C3988ED045A4B29BA36FF@BITCOM1.int.sbss.com.au>
Accept-Language: en-AU, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [172.16.3.132]
x-tm-as-product-ver: SMEX-10.2.0.2087-7.000.1014-19190.006
x-tm-as-result: No--24.253300-0.000000-31
x-tm-as-user-approved-sender: Yes
x-tm-as-user-blocked-sender: No
MIME-Version: 1.0
X-Really-From-Bendigo-IT: magichashvalue
Subject: [Xen-devel] xen domu core dump memory
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

In the .xen_pages section of a core dump, is the layout of pages 1:1 with DomU "physical" memory, or are there holes?

Thanks

James


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 18 11:23:28 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Sep 2012 11: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 1TDvtS-0002CQ-O9; Tue, 18 Sep 2012 11:23:06 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1TDvtR-0002CL-TZ
	for xen-devel@lists.xen.org; Tue, 18 Sep 2012 11:23:06 +0000
Received: from [85.158.143.35:25263] by server-3.bemta-4.messagelabs.com id
	F0/53-08232-99958505; Tue, 18 Sep 2012 11:23:05 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1347967384!7038358!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22669 invoked from network); 18 Sep 2012 11:23:04 -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;
	18 Sep 2012 11:23:04 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 18 Sep 2012 12:23:32 +0100
Message-Id: <505875B6020000780009C01D@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 18 Sep 2012 12:23:02 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: <gregkh@linuxfoundation.org>,
	"Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>,
	<stern@rowland.harvard.edu>
Mime-Version: 1.0
Content-Disposition: inline
Cc: linux-usb@vger.kernel.org, xen-devel <xen-devel@lists.xen.org>
Subject: [Xen-devel] [PATCH] EHCI/Xen: propagate controller reset
 information to 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

Just like for the in-tree early console debug port driver, the
hypervisor - when using a debug port based console - also needs to be
told about controller resets, so it can suppress using and then
re-initialize the debug port accordingly.

Other than the in-tree driver, the hypervisor driver actually cares
about doing this only for the device where the debug is port actually
in use, i.e. it needs to be told the coordinates of the device being
reset (quite obviously, leveraging the addition done for that would
likely benefit the in-tree driver too).

Signed-off-by: Jan Beulich <jbeulich@suse.com>

---
 drivers/usb/early/ehci-dbgp.c   |   17 ++++++++++----
 drivers/usb/host/ehci-hcd.c     |    4 +--
 drivers/usb/host/ehci-hub.c     |    4 +--
 drivers/xen/Makefile            |    2 -
 drivers/xen/dbgp.c              |   48 ++++++++++++++++++++++++++++++++++++++++
 include/linux/usb/ehci_def.h    |   29 +++++++++++++++++++-----
 include/xen/interface/physdev.h |   16 +++++++++++++
 7 files changed, 105 insertions(+), 15 deletions(-)

--- 3.6-rc6/drivers/usb/early/ehci-dbgp.c
+++ 3.6-rc6-xen-ehci-dbgp/drivers/usb/early/ehci-dbgp.c
@@ -491,7 +491,7 @@ static int ehci_wait_for_port(int port);
  * Return -ENODEV for any general failure
  * Return -EIO if wait for port fails
  */
-int dbgp_external_startup(void)
+static int _dbgp_external_startup(void)
 {
 	int devnum;
 	struct usb_debug_descriptor dbgp_desc;
@@ -613,6 +613,11 @@ err:
 		goto try_again;
 	return -ENODEV;
 }
+
+int dbgp_external_startup(struct usb_hcd *hcd)
+{
+	return xen_dbgp_external_startup(hcd) ?: _dbgp_external_startup();
+}
 EXPORT_SYMBOL_GPL(dbgp_external_startup);
 
 static int ehci_reset_port(int port)
@@ -804,7 +809,7 @@ try_next_port:
 		dbgp_ehci_status("ehci skip - already configured");
 	}
 
-	ret = dbgp_external_startup();
+	ret = _dbgp_external_startup();
 	if (ret == -EIO)
 		goto next_debug_port;
 
@@ -934,7 +939,7 @@ static void early_dbgp_write(struct cons
 		ctrl = readl(&ehci_debug->control);
 		if (!(ctrl & DBGP_ENABLED)) {
 			dbgp_not_safe = 1;
-			dbgp_external_startup();
+			_dbgp_external_startup();
 		} else {
 			cmd |= CMD_RUN;
 			writel(cmd, &ehci_regs->command);
@@ -974,10 +979,14 @@ struct console early_dbgp_console = {
 	.index =	-1,
 };
 
-int dbgp_reset_prep(void)
+int dbgp_reset_prep(struct usb_hcd *hcd)
 {
+	int ret = xen_dbgp_reset_prep(hcd);
 	u32 ctrl;
 
+	if (ret)
+		return ret;
+
 	dbgp_not_safe = 1;
 	if (!ehci_debug)
 		return 0;
--- 3.6-rc6/drivers/usb/host/ehci-hcd.c
+++ 3.6-rc6-xen-ehci-dbgp/drivers/usb/host/ehci-hcd.c
@@ -228,7 +228,7 @@ static int ehci_reset (struct ehci_hcd *
 
 	/* If the EHCI debug controller is active, special care must be
 	 * taken before and after a host controller reset */
-	if (ehci->debug && !dbgp_reset_prep())
+	if (ehci->debug && !dbgp_reset_prep(ehci_to_hcd(ehci)))
 		ehci->debug = NULL;
 
 	command |= CMD_RESET;
@@ -251,7 +251,7 @@ static int ehci_reset (struct ehci_hcd *
 		tdi_reset (ehci);
 
 	if (ehci->debug)
-		dbgp_external_startup();
+		dbgp_external_startup(ehci_to_hcd(ehci));
 
 	ehci->port_c_suspend = ehci->suspended_ports =
 			ehci->resuming_ports = 0;
--- 3.6-rc6/drivers/usb/host/ehci-hub.c
+++ 3.6-rc6-xen-ehci-dbgp/drivers/usb/host/ehci-hub.c
@@ -353,10 +353,10 @@ static int ehci_bus_resume (struct usb_h
 		goto shutdown;
 
 	if (unlikely(ehci->debug)) {
-		if (!dbgp_reset_prep())
+		if (!dbgp_reset_prep(hcd))
 			ehci->debug = NULL;
 		else
-			dbgp_external_startup();
+			dbgp_external_startup(hcd);
 	}
 
 	/* Ideally and we've got a real resume here, and no port's power
--- 3.6-rc6/drivers/xen/Makefile
+++ 3.6-rc6-xen-ehci-dbgp/drivers/xen/Makefile
@@ -18,7 +18,7 @@ obj-$(CONFIG_XEN_PVHVM)			+= platform-pc
 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_DOM0)			+= pci.o dbgp.o acpi.o
 obj-$(CONFIG_XEN_MCE_LOG)		+= mcelog.o
 obj-$(CONFIG_XEN_PCIDEV_BACKEND)	+= xen-pciback/
 obj-$(CONFIG_XEN_PRIVCMD)		+= xen-privcmd.o
--- /home/jbeulich/tmp/linux-3.6-rc6/drivers/xen/dbgp.c	1970-01-01 01:00:00.000000000 +0100
+++ 3.6-rc6-xen-ehci-dbgp/drivers/xen/dbgp.c
@@ -0,0 +1,48 @@
+#include <linux/pci.h>
+#include <linux/usb.h>
+#include <linux/usb/ehci_def.h>
+#include <linux/usb/hcd.h>
+#include <asm/xen/hypercall.h>
+#include <xen/interface/physdev.h>
+#include <xen/xen.h>
+
+static int xen_dbgp_op(struct usb_hcd *hcd, int op)
+{
+	const struct device *ctrlr = hcd_to_bus(hcd)->controller;
+	struct physdev_dbgp_op dbgp;
+
+	if (!xen_initial_domain())
+		return 0;
+
+	dbgp.op = op;
+
+#ifdef CONFIG_PCI
+	if (ctrlr->bus == &pci_bus_type) {
+		const struct pci_dev *pdev = to_pci_dev(ctrlr);
+
+		dbgp.u.pci.seg = pci_domain_nr(pdev->bus);
+		dbgp.u.pci.bus = pdev->bus->number;
+		dbgp.u.pci.devfn = pdev->devfn;
+		dbgp.bus = PHYSDEVOP_DBGP_BUS_PCI;
+	} else
+#endif
+		dbgp.bus = PHYSDEVOP_DBGP_BUS_UNKNOWN;
+
+	return HYPERVISOR_physdev_op(PHYSDEVOP_dbgp_op, &dbgp);
+}
+
+int xen_dbgp_reset_prep(struct usb_hcd *hcd)
+{
+	return xen_dbgp_op(hcd, PHYSDEVOP_DBGP_RESET_PREPARE);
+}
+
+int xen_dbgp_external_startup(struct usb_hcd *hcd)
+{
+	return xen_dbgp_op(hcd, PHYSDEVOP_DBGP_RESET_DONE);
+}
+
+#ifndef CONFIG_EARLY_PRINTK_DBGP
+#include <linux/export.h>
+EXPORT_SYMBOL_GPL(xen_dbgp_reset_prep);
+EXPORT_SYMBOL_GPL(xen_dbgp_external_startup);
+#endif
--- 3.6-rc6/include/linux/usb/ehci_def.h
+++ 3.6-rc6-xen-ehci-dbgp/include/linux/usb/ehci_def.h
@@ -221,18 +221,35 @@ extern int __init early_dbgp_init(char *
 extern struct console early_dbgp_console;
 #endif /* CONFIG_EARLY_PRINTK_DBGP */
 
+struct usb_hcd;
+
+#ifdef CONFIG_XEN_DOM0
+extern int xen_dbgp_reset_prep(struct usb_hcd *);
+extern int xen_dbgp_external_startup(struct usb_hcd *);
+#else
+static inline int xen_dbgp_reset_prep(struct usb_hcd *hcd)
+{
+	return 1; /* Shouldn't this be 0? */
+}
+
+static inline int xen_dbgp_external_startup(struct usb_hcd *hcd)
+{
+	return -1;
+}
+#endif
+
 #ifdef CONFIG_EARLY_PRINTK_DBGP
 /* Call backs from ehci host driver to ehci debug driver */
-extern int dbgp_external_startup(void);
-extern int dbgp_reset_prep(void);
+extern int dbgp_external_startup(struct usb_hcd *);
+extern int dbgp_reset_prep(struct usb_hcd *hcd);
 #else
-static inline int dbgp_reset_prep(void)
+static inline int dbgp_reset_prep(struct usb_hcd *hcd)
 {
-	return 1;
+	return xen_dbgp_reset_prep(hcd);
 }
-static inline int dbgp_external_startup(void)
+static inline int dbgp_external_startup(struct usb_hcd *hcd)
 {
-	return -1;
+	return xen_dbgp_external_startup(hcd);
 }
 #endif
 
--- 3.6-rc6/include/xen/interface/physdev.h
+++ 3.6-rc6-xen-ehci-dbgp/include/xen/interface/physdev.h
@@ -258,6 +258,22 @@ struct physdev_pci_device {
     uint8_t devfn;
 };
 
+#define PHYSDEVOP_DBGP_RESET_PREPARE    1
+#define PHYSDEVOP_DBGP_RESET_DONE       2
+
+#define PHYSDEVOP_DBGP_BUS_UNKNOWN      0
+#define PHYSDEVOP_DBGP_BUS_PCI          1
+
+#define PHYSDEVOP_dbgp_op               29
+struct physdev_dbgp_op {
+    /* IN */
+    uint8_t op;
+    uint8_t bus;
+    union {
+        struct physdev_pci_device pci;
+    } u;
+};
+
 /*
  * Notify that some PIRQ-bound event channels have been unmasked.
  * ** This command is obsolete since interface version 0x00030202 and is **



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 18 11:23:28 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Sep 2012 11: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 1TDvtS-0002CQ-O9; Tue, 18 Sep 2012 11:23:06 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1TDvtR-0002CL-TZ
	for xen-devel@lists.xen.org; Tue, 18 Sep 2012 11:23:06 +0000
Received: from [85.158.143.35:25263] by server-3.bemta-4.messagelabs.com id
	F0/53-08232-99958505; Tue, 18 Sep 2012 11:23:05 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1347967384!7038358!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22669 invoked from network); 18 Sep 2012 11:23:04 -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;
	18 Sep 2012 11:23:04 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 18 Sep 2012 12:23:32 +0100
Message-Id: <505875B6020000780009C01D@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 18 Sep 2012 12:23:02 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: <gregkh@linuxfoundation.org>,
	"Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>,
	<stern@rowland.harvard.edu>
Mime-Version: 1.0
Content-Disposition: inline
Cc: linux-usb@vger.kernel.org, xen-devel <xen-devel@lists.xen.org>
Subject: [Xen-devel] [PATCH] EHCI/Xen: propagate controller reset
 information to 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

Just like for the in-tree early console debug port driver, the
hypervisor - when using a debug port based console - also needs to be
told about controller resets, so it can suppress using and then
re-initialize the debug port accordingly.

Other than the in-tree driver, the hypervisor driver actually cares
about doing this only for the device where the debug is port actually
in use, i.e. it needs to be told the coordinates of the device being
reset (quite obviously, leveraging the addition done for that would
likely benefit the in-tree driver too).

Signed-off-by: Jan Beulich <jbeulich@suse.com>

---
 drivers/usb/early/ehci-dbgp.c   |   17 ++++++++++----
 drivers/usb/host/ehci-hcd.c     |    4 +--
 drivers/usb/host/ehci-hub.c     |    4 +--
 drivers/xen/Makefile            |    2 -
 drivers/xen/dbgp.c              |   48 ++++++++++++++++++++++++++++++++++++++++
 include/linux/usb/ehci_def.h    |   29 +++++++++++++++++++-----
 include/xen/interface/physdev.h |   16 +++++++++++++
 7 files changed, 105 insertions(+), 15 deletions(-)

--- 3.6-rc6/drivers/usb/early/ehci-dbgp.c
+++ 3.6-rc6-xen-ehci-dbgp/drivers/usb/early/ehci-dbgp.c
@@ -491,7 +491,7 @@ static int ehci_wait_for_port(int port);
  * Return -ENODEV for any general failure
  * Return -EIO if wait for port fails
  */
-int dbgp_external_startup(void)
+static int _dbgp_external_startup(void)
 {
 	int devnum;
 	struct usb_debug_descriptor dbgp_desc;
@@ -613,6 +613,11 @@ err:
 		goto try_again;
 	return -ENODEV;
 }
+
+int dbgp_external_startup(struct usb_hcd *hcd)
+{
+	return xen_dbgp_external_startup(hcd) ?: _dbgp_external_startup();
+}
 EXPORT_SYMBOL_GPL(dbgp_external_startup);
 
 static int ehci_reset_port(int port)
@@ -804,7 +809,7 @@ try_next_port:
 		dbgp_ehci_status("ehci skip - already configured");
 	}
 
-	ret = dbgp_external_startup();
+	ret = _dbgp_external_startup();
 	if (ret == -EIO)
 		goto next_debug_port;
 
@@ -934,7 +939,7 @@ static void early_dbgp_write(struct cons
 		ctrl = readl(&ehci_debug->control);
 		if (!(ctrl & DBGP_ENABLED)) {
 			dbgp_not_safe = 1;
-			dbgp_external_startup();
+			_dbgp_external_startup();
 		} else {
 			cmd |= CMD_RUN;
 			writel(cmd, &ehci_regs->command);
@@ -974,10 +979,14 @@ struct console early_dbgp_console = {
 	.index =	-1,
 };
 
-int dbgp_reset_prep(void)
+int dbgp_reset_prep(struct usb_hcd *hcd)
 {
+	int ret = xen_dbgp_reset_prep(hcd);
 	u32 ctrl;
 
+	if (ret)
+		return ret;
+
 	dbgp_not_safe = 1;
 	if (!ehci_debug)
 		return 0;
--- 3.6-rc6/drivers/usb/host/ehci-hcd.c
+++ 3.6-rc6-xen-ehci-dbgp/drivers/usb/host/ehci-hcd.c
@@ -228,7 +228,7 @@ static int ehci_reset (struct ehci_hcd *
 
 	/* If the EHCI debug controller is active, special care must be
 	 * taken before and after a host controller reset */
-	if (ehci->debug && !dbgp_reset_prep())
+	if (ehci->debug && !dbgp_reset_prep(ehci_to_hcd(ehci)))
 		ehci->debug = NULL;
 
 	command |= CMD_RESET;
@@ -251,7 +251,7 @@ static int ehci_reset (struct ehci_hcd *
 		tdi_reset (ehci);
 
 	if (ehci->debug)
-		dbgp_external_startup();
+		dbgp_external_startup(ehci_to_hcd(ehci));
 
 	ehci->port_c_suspend = ehci->suspended_ports =
 			ehci->resuming_ports = 0;
--- 3.6-rc6/drivers/usb/host/ehci-hub.c
+++ 3.6-rc6-xen-ehci-dbgp/drivers/usb/host/ehci-hub.c
@@ -353,10 +353,10 @@ static int ehci_bus_resume (struct usb_h
 		goto shutdown;
 
 	if (unlikely(ehci->debug)) {
-		if (!dbgp_reset_prep())
+		if (!dbgp_reset_prep(hcd))
 			ehci->debug = NULL;
 		else
-			dbgp_external_startup();
+			dbgp_external_startup(hcd);
 	}
 
 	/* Ideally and we've got a real resume here, and no port's power
--- 3.6-rc6/drivers/xen/Makefile
+++ 3.6-rc6-xen-ehci-dbgp/drivers/xen/Makefile
@@ -18,7 +18,7 @@ obj-$(CONFIG_XEN_PVHVM)			+= platform-pc
 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_DOM0)			+= pci.o dbgp.o acpi.o
 obj-$(CONFIG_XEN_MCE_LOG)		+= mcelog.o
 obj-$(CONFIG_XEN_PCIDEV_BACKEND)	+= xen-pciback/
 obj-$(CONFIG_XEN_PRIVCMD)		+= xen-privcmd.o
--- /home/jbeulich/tmp/linux-3.6-rc6/drivers/xen/dbgp.c	1970-01-01 01:00:00.000000000 +0100
+++ 3.6-rc6-xen-ehci-dbgp/drivers/xen/dbgp.c
@@ -0,0 +1,48 @@
+#include <linux/pci.h>
+#include <linux/usb.h>
+#include <linux/usb/ehci_def.h>
+#include <linux/usb/hcd.h>
+#include <asm/xen/hypercall.h>
+#include <xen/interface/physdev.h>
+#include <xen/xen.h>
+
+static int xen_dbgp_op(struct usb_hcd *hcd, int op)
+{
+	const struct device *ctrlr = hcd_to_bus(hcd)->controller;
+	struct physdev_dbgp_op dbgp;
+
+	if (!xen_initial_domain())
+		return 0;
+
+	dbgp.op = op;
+
+#ifdef CONFIG_PCI
+	if (ctrlr->bus == &pci_bus_type) {
+		const struct pci_dev *pdev = to_pci_dev(ctrlr);
+
+		dbgp.u.pci.seg = pci_domain_nr(pdev->bus);
+		dbgp.u.pci.bus = pdev->bus->number;
+		dbgp.u.pci.devfn = pdev->devfn;
+		dbgp.bus = PHYSDEVOP_DBGP_BUS_PCI;
+	} else
+#endif
+		dbgp.bus = PHYSDEVOP_DBGP_BUS_UNKNOWN;
+
+	return HYPERVISOR_physdev_op(PHYSDEVOP_dbgp_op, &dbgp);
+}
+
+int xen_dbgp_reset_prep(struct usb_hcd *hcd)
+{
+	return xen_dbgp_op(hcd, PHYSDEVOP_DBGP_RESET_PREPARE);
+}
+
+int xen_dbgp_external_startup(struct usb_hcd *hcd)
+{
+	return xen_dbgp_op(hcd, PHYSDEVOP_DBGP_RESET_DONE);
+}
+
+#ifndef CONFIG_EARLY_PRINTK_DBGP
+#include <linux/export.h>
+EXPORT_SYMBOL_GPL(xen_dbgp_reset_prep);
+EXPORT_SYMBOL_GPL(xen_dbgp_external_startup);
+#endif
--- 3.6-rc6/include/linux/usb/ehci_def.h
+++ 3.6-rc6-xen-ehci-dbgp/include/linux/usb/ehci_def.h
@@ -221,18 +221,35 @@ extern int __init early_dbgp_init(char *
 extern struct console early_dbgp_console;
 #endif /* CONFIG_EARLY_PRINTK_DBGP */
 
+struct usb_hcd;
+
+#ifdef CONFIG_XEN_DOM0
+extern int xen_dbgp_reset_prep(struct usb_hcd *);
+extern int xen_dbgp_external_startup(struct usb_hcd *);
+#else
+static inline int xen_dbgp_reset_prep(struct usb_hcd *hcd)
+{
+	return 1; /* Shouldn't this be 0? */
+}
+
+static inline int xen_dbgp_external_startup(struct usb_hcd *hcd)
+{
+	return -1;
+}
+#endif
+
 #ifdef CONFIG_EARLY_PRINTK_DBGP
 /* Call backs from ehci host driver to ehci debug driver */
-extern int dbgp_external_startup(void);
-extern int dbgp_reset_prep(void);
+extern int dbgp_external_startup(struct usb_hcd *);
+extern int dbgp_reset_prep(struct usb_hcd *hcd);
 #else
-static inline int dbgp_reset_prep(void)
+static inline int dbgp_reset_prep(struct usb_hcd *hcd)
 {
-	return 1;
+	return xen_dbgp_reset_prep(hcd);
 }
-static inline int dbgp_external_startup(void)
+static inline int dbgp_external_startup(struct usb_hcd *hcd)
 {
-	return -1;
+	return xen_dbgp_external_startup(hcd);
 }
 #endif
 
--- 3.6-rc6/include/xen/interface/physdev.h
+++ 3.6-rc6-xen-ehci-dbgp/include/xen/interface/physdev.h
@@ -258,6 +258,22 @@ struct physdev_pci_device {
     uint8_t devfn;
 };
 
+#define PHYSDEVOP_DBGP_RESET_PREPARE    1
+#define PHYSDEVOP_DBGP_RESET_DONE       2
+
+#define PHYSDEVOP_DBGP_BUS_UNKNOWN      0
+#define PHYSDEVOP_DBGP_BUS_PCI          1
+
+#define PHYSDEVOP_dbgp_op               29
+struct physdev_dbgp_op {
+    /* IN */
+    uint8_t op;
+    uint8_t bus;
+    union {
+        struct physdev_pci_device pci;
+    } u;
+};
+
 /*
  * Notify that some PIRQ-bound event channels have been unmasked.
  * ** This command is obsolete since interface version 0x00030202 and is **



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 18 11:29:30 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Sep 2012 11:29: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 1TDvzH-0002Lw-Jq; Tue, 18 Sep 2012 11:29:07 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1TDvzG-0002Lq-9M
	for xen-devel@lists.xen.org; Tue, 18 Sep 2012 11:29:06 +0000
Received: from [85.158.143.35:3359] by server-2.bemta-4.messagelabs.com id
	5E/35-06610-10B58505; Tue, 18 Sep 2012 11:29:05 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1347967744!7736736!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17796 invoked from network); 18 Sep 2012 11:29:04 -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;
	18 Sep 2012 11:29:04 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 18 Sep 2012 12:29:38 +0100
Message-Id: <5058771F020000780009C025@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 18 Sep 2012 12:29:03 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: linux-kernel@vger.kernel.org, xen-devel <xen-devel@lists.xen.org>
Subject: [Xen-devel] [PATCH] xen-pciback: support wild cards in slot
	specifications
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Particularly for hiding sets of SR-IOV devices, specifying them all
individually is rather cumbersome. Therefore, allow function and slot
numbers to be replaced by a wildcard character ('*').

Unfortunately this gets complicated by the in-kernel sscanf()
implementation not being really standard conformant - matching of
plain text tails cannot be checked by the caller (a patch to overcome
this will be sent shortly, and a follow-up patch for simplifying the
code is planned to be sent when that fixed went upstream).

Signed-off-by: Jan Beulich <jbeulich@suse.com>

---
 drivers/xen/xen-pciback/pci_stub.c |   89 ++++++++++++++++++++++++++++++++++---
 1 file changed, 82 insertions(+), 7 deletions(-)

--- 3.6-rc6/drivers/xen/xen-pciback/pci_stub.c
+++ 3.6-rc6-xen-pciback-wildcard/drivers/xen/xen-pciback/pci_stub.c
@@ -897,17 +897,41 @@ static inline int str_to_slot(const char
 			      int *slot, int *func)
 {
 	int err;
+	char wc = '*';
 
 	err = sscanf(buf, " %x:%x:%x.%x", domain, bus, slot, func);
-	if (err == 4)
+	switch (err) {
+	case 3:
+		*func = -1;
+		err = sscanf(buf, " %x:%x:%x.%c", domain, bus, slot, &wc);
+		break;
+	case 2:
+		*slot = *func = -1;
+		err = sscanf(buf, " %x:%x:*.%c", domain, bus, &wc);
+		if (err >= 2)
+			++err;
+		break;
+	}
+	if (err == 4 && wc == '*')
 		return 0;
 	else if (err < 0)
 		return -EINVAL;
 
 	/* try again without domain */
 	*domain = 0;
+	wc = '*';
 	err = sscanf(buf, " %x:%x.%x", bus, slot, func);
-	if (err == 3)
+	switch (err) {
+	case 2:
+		*func = -1;
+		err = sscanf(buf, " %x:%x.%c", bus, slot, &wc);
+		break;
+	case 1:
+		*slot = *func = -1;
+		err = sscanf(buf, " %x:*.%c", bus, &wc) + 1;
+		break;
+	}
+	if (err == 3 && wc == '*')
 		return 0;
 
 	return -EINVAL;
@@ -930,6 +954,19 @@ static int pcistub_device_id_add(int dom
 {
 	struct pcistub_device_id *pci_dev_id;
 	unsigned long flags;
+	int rc = 0;
+
+	if (slot < 0) {
+		for (slot = 0; !rc && slot < 32; ++slot)
+			rc = pcistub_device_id_add(domain, bus, slot, func);
+		return rc;
+	}
+
+	if (func < 0) {
+		for (func = 0; !rc && func < 8; ++func)
+			rc = pcistub_device_id_add(domain, bus, slot, func);
+		return rc;
+	}
 
 	pci_dev_id = kmalloc(sizeof(*pci_dev_id), GFP_KERNEL);
 	if (!pci_dev_id)
@@ -952,15 +989,15 @@ static int pcistub_device_id_add(int dom
 static int pcistub_device_id_remove(int domain, int bus, int slot, int func)
 {
 	struct pcistub_device_id *pci_dev_id, *t;
-	int devfn = PCI_DEVFN(slot, func);
 	int err = -ENOENT;
 	unsigned long flags;
 
 	spin_lock_irqsave(&device_ids_lock, flags);
 	list_for_each_entry_safe(pci_dev_id, t, &pcistub_device_ids,
 				 slot_list) {
-		if (pci_dev_id->domain == domain
-		    && pci_dev_id->bus == bus && pci_dev_id->devfn == devfn) {
+		if (pci_dev_id->domain == domain && pci_dev_id->bus == bus
+		    && (slot < 0 || PCI_SLOT(pci_dev_id->devfn) == slot)
+		    && (func < 0 || PCI_FUNC(pci_dev_id->devfn) == func)) {
 			/* Don't break; here because it's possible the same
 			 * slot could be in the list more than once
 			 */
@@ -1216,6 +1253,10 @@ static ssize_t permissive_add(struct dev
 	err = str_to_slot(buf, &domain, &bus, &slot, &func);
 	if (err)
 		goto out;
+	if (slot < 0 || func < 0) {
+		err = -EINVAL;
+		goto out;
+	}
 	psdev = pcistub_device_find(domain, bus, slot, func);
 	if (!psdev) {
 		err = -ENODEV;
@@ -1297,17 +1338,51 @@ static int __init pcistub_init(void)
 
 	if (pci_devs_to_hide && *pci_devs_to_hide) {
 		do {
+			char wc = '*';
+
 			parsed = 0;
 
 			err = sscanf(pci_devs_to_hide + pos,
 				     " (%x:%x:%x.%x) %n",
 				     &domain, &bus, &slot, &func, &parsed);
-			if (err != 4) {
+			switch (err) {
+			case 3:
+				func = -1;
+				err = sscanf(pci_devs_to_hide + pos,
+					     " (%x:%x:%x.%c) %n",
+					     &domain, &bus, &slot, &wc,
+					     &parsed);
+				break;
+			case 2:
+				slot = func = -1;
+				err = sscanf(pci_devs_to_hide + pos,
+					     " (%x:%x:*.%c) %n",
+					     &domain, &bus, &wc, &parsed) + 1;
+				break;
+			}
+
+			if (err != 4 || wc != '*') {
 				domain = 0;
+				wc = '*';
 				err = sscanf(pci_devs_to_hide + pos,
 					     " (%x:%x.%x) %n",
 					     &bus, &slot, &func, &parsed);
-				if (err != 3)
+				switch (err) {
+				case 2:
+					func = -1;
+					err = sscanf(pci_devs_to_hide + pos,
+						     " (%x:%x.%c) %n",
+						     &bus, &slot, &wc,
+						     &parsed);
+					break;
+				case 1:
+					slot = func = -1;
+					err = sscanf(pci_devs_to_hide + pos,
+						     " (%x:*.%c) %n",
+						     &bus, &wc, &parsed) + 1;
+					break;
+				}
+				if (err != 3 || wc != '*')
 					goto parse_error;
 			}
 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 18 11:29:30 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Sep 2012 11:29: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 1TDvzH-0002Lw-Jq; Tue, 18 Sep 2012 11:29:07 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1TDvzG-0002Lq-9M
	for xen-devel@lists.xen.org; Tue, 18 Sep 2012 11:29:06 +0000
Received: from [85.158.143.35:3359] by server-2.bemta-4.messagelabs.com id
	5E/35-06610-10B58505; Tue, 18 Sep 2012 11:29:05 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1347967744!7736736!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17796 invoked from network); 18 Sep 2012 11:29:04 -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;
	18 Sep 2012 11:29:04 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 18 Sep 2012 12:29:38 +0100
Message-Id: <5058771F020000780009C025@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 18 Sep 2012 12:29:03 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: linux-kernel@vger.kernel.org, xen-devel <xen-devel@lists.xen.org>
Subject: [Xen-devel] [PATCH] xen-pciback: support wild cards in slot
	specifications
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Particularly for hiding sets of SR-IOV devices, specifying them all
individually is rather cumbersome. Therefore, allow function and slot
numbers to be replaced by a wildcard character ('*').

Unfortunately this gets complicated by the in-kernel sscanf()
implementation not being really standard conformant - matching of
plain text tails cannot be checked by the caller (a patch to overcome
this will be sent shortly, and a follow-up patch for simplifying the
code is planned to be sent when that fixed went upstream).

Signed-off-by: Jan Beulich <jbeulich@suse.com>

---
 drivers/xen/xen-pciback/pci_stub.c |   89 ++++++++++++++++++++++++++++++++++---
 1 file changed, 82 insertions(+), 7 deletions(-)

--- 3.6-rc6/drivers/xen/xen-pciback/pci_stub.c
+++ 3.6-rc6-xen-pciback-wildcard/drivers/xen/xen-pciback/pci_stub.c
@@ -897,17 +897,41 @@ static inline int str_to_slot(const char
 			      int *slot, int *func)
 {
 	int err;
+	char wc = '*';
 
 	err = sscanf(buf, " %x:%x:%x.%x", domain, bus, slot, func);
-	if (err == 4)
+	switch (err) {
+	case 3:
+		*func = -1;
+		err = sscanf(buf, " %x:%x:%x.%c", domain, bus, slot, &wc);
+		break;
+	case 2:
+		*slot = *func = -1;
+		err = sscanf(buf, " %x:%x:*.%c", domain, bus, &wc);
+		if (err >= 2)
+			++err;
+		break;
+	}
+	if (err == 4 && wc == '*')
 		return 0;
 	else if (err < 0)
 		return -EINVAL;
 
 	/* try again without domain */
 	*domain = 0;
+	wc = '*';
 	err = sscanf(buf, " %x:%x.%x", bus, slot, func);
-	if (err == 3)
+	switch (err) {
+	case 2:
+		*func = -1;
+		err = sscanf(buf, " %x:%x.%c", bus, slot, &wc);
+		break;
+	case 1:
+		*slot = *func = -1;
+		err = sscanf(buf, " %x:*.%c", bus, &wc) + 1;
+		break;
+	}
+	if (err == 3 && wc == '*')
 		return 0;
 
 	return -EINVAL;
@@ -930,6 +954,19 @@ static int pcistub_device_id_add(int dom
 {
 	struct pcistub_device_id *pci_dev_id;
 	unsigned long flags;
+	int rc = 0;
+
+	if (slot < 0) {
+		for (slot = 0; !rc && slot < 32; ++slot)
+			rc = pcistub_device_id_add(domain, bus, slot, func);
+		return rc;
+	}
+
+	if (func < 0) {
+		for (func = 0; !rc && func < 8; ++func)
+			rc = pcistub_device_id_add(domain, bus, slot, func);
+		return rc;
+	}
 
 	pci_dev_id = kmalloc(sizeof(*pci_dev_id), GFP_KERNEL);
 	if (!pci_dev_id)
@@ -952,15 +989,15 @@ static int pcistub_device_id_add(int dom
 static int pcistub_device_id_remove(int domain, int bus, int slot, int func)
 {
 	struct pcistub_device_id *pci_dev_id, *t;
-	int devfn = PCI_DEVFN(slot, func);
 	int err = -ENOENT;
 	unsigned long flags;
 
 	spin_lock_irqsave(&device_ids_lock, flags);
 	list_for_each_entry_safe(pci_dev_id, t, &pcistub_device_ids,
 				 slot_list) {
-		if (pci_dev_id->domain == domain
-		    && pci_dev_id->bus == bus && pci_dev_id->devfn == devfn) {
+		if (pci_dev_id->domain == domain && pci_dev_id->bus == bus
+		    && (slot < 0 || PCI_SLOT(pci_dev_id->devfn) == slot)
+		    && (func < 0 || PCI_FUNC(pci_dev_id->devfn) == func)) {
 			/* Don't break; here because it's possible the same
 			 * slot could be in the list more than once
 			 */
@@ -1216,6 +1253,10 @@ static ssize_t permissive_add(struct dev
 	err = str_to_slot(buf, &domain, &bus, &slot, &func);
 	if (err)
 		goto out;
+	if (slot < 0 || func < 0) {
+		err = -EINVAL;
+		goto out;
+	}
 	psdev = pcistub_device_find(domain, bus, slot, func);
 	if (!psdev) {
 		err = -ENODEV;
@@ -1297,17 +1338,51 @@ static int __init pcistub_init(void)
 
 	if (pci_devs_to_hide && *pci_devs_to_hide) {
 		do {
+			char wc = '*';
+
 			parsed = 0;
 
 			err = sscanf(pci_devs_to_hide + pos,
 				     " (%x:%x:%x.%x) %n",
 				     &domain, &bus, &slot, &func, &parsed);
-			if (err != 4) {
+			switch (err) {
+			case 3:
+				func = -1;
+				err = sscanf(pci_devs_to_hide + pos,
+					     " (%x:%x:%x.%c) %n",
+					     &domain, &bus, &slot, &wc,
+					     &parsed);
+				break;
+			case 2:
+				slot = func = -1;
+				err = sscanf(pci_devs_to_hide + pos,
+					     " (%x:%x:*.%c) %n",
+					     &domain, &bus, &wc, &parsed) + 1;
+				break;
+			}
+
+			if (err != 4 || wc != '*') {
 				domain = 0;
+				wc = '*';
 				err = sscanf(pci_devs_to_hide + pos,
 					     " (%x:%x.%x) %n",
 					     &bus, &slot, &func, &parsed);
-				if (err != 3)
+				switch (err) {
+				case 2:
+					func = -1;
+					err = sscanf(pci_devs_to_hide + pos,
+						     " (%x:%x.%c) %n",
+						     &bus, &slot, &wc,
+						     &parsed);
+					break;
+				case 1:
+					slot = func = -1;
+					err = sscanf(pci_devs_to_hide + pos,
+						     " (%x:*.%c) %n",
+						     &bus, &wc, &parsed) + 1;
+					break;
+				}
+				if (err != 3 || wc != '*')
 					goto parse_error;
 			}
 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 18 11:39:35 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Sep 2012 11:39:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDw96-0002bP-Uq; Tue, 18 Sep 2012 11:39:16 +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 1TDw94-0002bK-Ng
	for xen-devel@lists.xen.org; Tue, 18 Sep 2012 11:39:14 +0000
Received: from [85.158.143.35:47401] by server-2.bemta-4.messagelabs.com id
	59/15-06610-16D58505; Tue, 18 Sep 2012 11:39:13 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-15.tower-21.messagelabs.com!1347968353!14088310!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA1MDY0MDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29676 invoked from network); 18 Sep 2012 11:39:13 -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; 18 Sep 2012 11:39:13 -0000
X-Originating-Ip: [194.89.68.22]
Received: from ydin.reaktio.net (reaktio.net [194.89.68.22])
	by smtp.tele.fi (Postfix) with ESMTP id E26732572;
	Tue, 18 Sep 2012 14:39:11 +0300 (EEST)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id 899752005D; Tue, 18 Sep 2012 14:39:11 +0300 (EEST)
Date: Tue, 18 Sep 2012 14:39:11 +0300
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: Robin Axelsson <gu99roax@student.chalmers.se>
Message-ID: <20120918113911.GM8912@reaktio.net>
References: <20120917113833.GH8912@reaktio.net>
	<50570EA7.8060509@student.chalmers.se>
	<20120917123205.GJ8912@reaktio.net>
	<1347885774.14977.64.camel@zakaz.uk.xensource.com>
	<20120917191556.GB18552@phenom.dumpdata.com>
	<505858C3.9080303@student.chalmers.se>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <505858C3.9080303@student.chalmers.se>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: Konrad Rzeszutek Wilk <konrad@kernel.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"xen@lists.fedoraproject.org" <xen@lists.fedoraproject.org>
Subject: Re: [Xen-devel] Xen PCI passthru supported reset methods (d3d0, FLR,
 bus reset, link reset)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Sep 18, 2012 at 01:19:31PM +0200, Robin Axelsson wrote:
> >>With a pvops dom0 Xen resets devices by writing to its "reset" node in
> >>sysfs so it will reset the device using whatever method the dom0 kernel
> >>supports for that device.
> >And if you use Xen PCI-back it has this enabled so you don't even
> >need the 'reset' functionality.
> >>The version of Linux I have to hand has, in __pci_dev_reset, calls to
> >>the following in this order and stops after the first one which
> >>succeeds:
> >>       * pci_dev_specific_reset (AKA per device quirks)
> >>       * pcie_flr
> >>       * pci_af_flr
> >>       * pci_pm_reset
> >>       * pci_parent_bus_reset
> >>
> >>See drivers/pci/pci.c in the kernel for more info.
> >>
> >>IIRC classic Xen kernels had similar code in pciback, although I don't
> >>know which specific sets of actions or in which order they were tried.
> >>
> >>Ian.
> >>
> >
> That sounds like great news, that means that FLR is not a
> requirement to successfully pass through hardware without errors, as
> is stated in the VTdHowTo page. So it seems that the VTdHowTo page
> needs to be updated with this information.
>

Do you want to update the wiki page? :)

-- Pasi

 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 18 11:39:35 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Sep 2012 11:39:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDw96-0002bP-Uq; Tue, 18 Sep 2012 11:39:16 +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 1TDw94-0002bK-Ng
	for xen-devel@lists.xen.org; Tue, 18 Sep 2012 11:39:14 +0000
Received: from [85.158.143.35:47401] by server-2.bemta-4.messagelabs.com id
	59/15-06610-16D58505; Tue, 18 Sep 2012 11:39:13 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-15.tower-21.messagelabs.com!1347968353!14088310!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA1MDY0MDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29676 invoked from network); 18 Sep 2012 11:39:13 -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; 18 Sep 2012 11:39:13 -0000
X-Originating-Ip: [194.89.68.22]
Received: from ydin.reaktio.net (reaktio.net [194.89.68.22])
	by smtp.tele.fi (Postfix) with ESMTP id E26732572;
	Tue, 18 Sep 2012 14:39:11 +0300 (EEST)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id 899752005D; Tue, 18 Sep 2012 14:39:11 +0300 (EEST)
Date: Tue, 18 Sep 2012 14:39:11 +0300
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: Robin Axelsson <gu99roax@student.chalmers.se>
Message-ID: <20120918113911.GM8912@reaktio.net>
References: <20120917113833.GH8912@reaktio.net>
	<50570EA7.8060509@student.chalmers.se>
	<20120917123205.GJ8912@reaktio.net>
	<1347885774.14977.64.camel@zakaz.uk.xensource.com>
	<20120917191556.GB18552@phenom.dumpdata.com>
	<505858C3.9080303@student.chalmers.se>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <505858C3.9080303@student.chalmers.se>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: Konrad Rzeszutek Wilk <konrad@kernel.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"xen@lists.fedoraproject.org" <xen@lists.fedoraproject.org>
Subject: Re: [Xen-devel] Xen PCI passthru supported reset methods (d3d0, FLR,
 bus reset, link reset)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Sep 18, 2012 at 01:19:31PM +0200, Robin Axelsson wrote:
> >>With a pvops dom0 Xen resets devices by writing to its "reset" node in
> >>sysfs so it will reset the device using whatever method the dom0 kernel
> >>supports for that device.
> >And if you use Xen PCI-back it has this enabled so you don't even
> >need the 'reset' functionality.
> >>The version of Linux I have to hand has, in __pci_dev_reset, calls to
> >>the following in this order and stops after the first one which
> >>succeeds:
> >>       * pci_dev_specific_reset (AKA per device quirks)
> >>       * pcie_flr
> >>       * pci_af_flr
> >>       * pci_pm_reset
> >>       * pci_parent_bus_reset
> >>
> >>See drivers/pci/pci.c in the kernel for more info.
> >>
> >>IIRC classic Xen kernels had similar code in pciback, although I don't
> >>know which specific sets of actions or in which order they were tried.
> >>
> >>Ian.
> >>
> >
> That sounds like great news, that means that FLR is not a
> requirement to successfully pass through hardware without errors, as
> is stated in the VTdHowTo page. So it seems that the VTdHowTo page
> needs to be updated with this information.
>

Do you want to update the wiki page? :)

-- Pasi

 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 18 12:07:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Sep 2012 12:07: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 1TDwZp-00032D-UO; Tue, 18 Sep 2012 12:06:53 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <gu99roax@student.chalmers.se>) id 1TDvq9-0002Bi-Hj
	for xen-devel@lists.xen.org; Tue, 18 Sep 2012 11:19:41 +0000
Received: from [85.158.143.99:62645] by server-3.bemta-4.messagelabs.com id
	B8/3E-08232-CC858505; Tue, 18 Sep 2012 11:19:40 +0000
X-Env-Sender: gu99roax@student.chalmers.se
X-Msg-Ref: server-8.tower-216.messagelabs.com!1347967180!21028138!1
X-Originating-IP: [213.199.154.140]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24254 invoked from network); 18 Sep 2012 11:19:40 -0000
Received: from db3ehsobe002.messaging.microsoft.com (HELO
	db3outboundpool.messaging.microsoft.com) (213.199.154.140)
	by server-8.tower-216.messagelabs.com with AES128-SHA encrypted SMTP;
	18 Sep 2012 11:19:40 -0000
Received: from mail25-db3-R.bigfish.com (10.3.81.242) by
	DB3EHSOBE002.bigfish.com (10.3.84.22) with Microsoft SMTP Server id
	14.1.225.23; Tue, 18 Sep 2012 11:19:39 +0000
Received: from mail25-db3 (localhost [127.0.0.1])	by mail25-db3-R.bigfish.com
	(Postfix) with ESMTP id 9DA534C023C;
	Tue, 18 Sep 2012 11:19:39 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:207.46.4.203; KIP:(null); UIP:(null); IPV:NLI;
	H:SN2PRD0102HT006.prod.exchangelabs.com; RD:none; EFVD:NLI
X-SpamScore: -1
X-BigFish: PS-1(zz98dIc89bh936eI1432Id6f1izz1d18h1202h1d1ah1d2ah1082kzz17326ah8275bh8275dh5eeeKz2dh2a8h668h839h8e2h8e3hd25hf0ah107ah10d2h1288h12a5h12a9h12bdhbe9i1155h)
Received: from mail25-db3 (localhost.localdomain [127.0.0.1]) by mail25-db3
	(MessageSwitch) id 1347967177451556_11893;
	Tue, 18 Sep 2012 11:19:37 +0000 (UTC)
Received: from DB3EHSMHS010.bigfish.com (unknown [10.3.81.253])	by
	mail25-db3.bigfish.com (Postfix) with ESMTP id 61773260055;
	Tue, 18 Sep 2012 11:19:37 +0000 (UTC)
Received: from SN2PRD0102HT006.prod.exchangelabs.com (207.46.4.203) by
	DB3EHSMHS010.bigfish.com (10.3.87.110) with Microsoft SMTP Server (TLS)
	id 14.1.225.23; Tue, 18 Sep 2012 11:19:37 +0000
Received: from [10.40.137.93] (217.208.204.161) by pod51000.outlook.com
	(10.27.51.84) with Microsoft SMTP Server (TLS) id 14.15.108.4;
	Tue, 18 Sep 2012 11:19:35 +0000
Message-ID: <505858C3.9080303@student.chalmers.se>
Date: Tue, 18 Sep 2012 13:19:31 +0200
From: Robin Axelsson <gu99roax@student.chalmers.se>
User-Agent: Mozilla/5.0 (Windows NT 5.2; WOW64;
	rv:9.0) Gecko/20111222 Thunderbird/9.0.1
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk <konrad@kernel.org>
References: <20120917113833.GH8912@reaktio.net>
	<50570EA7.8060509@student.chalmers.se>
	<20120917123205.GJ8912@reaktio.net>
	<1347885774.14977.64.camel@zakaz.uk.xensource.com>
	<20120917191556.GB18552@phenom.dumpdata.com>
In-Reply-To: <20120917191556.GB18552@phenom.dumpdata.com>
X-Originating-IP: [217.208.204.161]
X-OriginatorOrg: student.chalmers.se
X-Mailman-Approved-At: Tue, 18 Sep 2012 12:06:52 +0000
Cc: "xen@lists.fedoraproject.org" <xen@lists.fedoraproject.org>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen PCI passthru supported reset methods (d3d0, FLR,
 bus reset, link reset)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: gu99roax@student.chalmers.se
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
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 2012-09-17 21:15, Konrad Rzeszutek Wilk wrote:
> On Mon, Sep 17, 2012 at 01:42:54PM +0100, Ian Campbell wrote:
>> On Mon, 2012-09-17 at 13:32 +0100, Pasi K=E4rkk=E4inen wrote:
>>> On Mon, Sep 17, 2012 at 01:51:03PM +0200, Robin Axelsson wrote:
>>>> There is one thing I wonder though when it comes to PCI passthrough:
>>>>
>>>> Can Xen reset hardware through the d3d0 in the ACPI interface and/or
>>>> through a 'bus reset' or a 'link reset'? Or can it reset hardware
>>>> that is marked for passthrough only through FLR?
>>>>
>>>> For details see e.g.
>>>> http://www.vmware.com/files/pdf/techpaper/vsp_4_vmdirectpath_host.pdf
>>>>
>>> I added xen-devel to the CC-list.
>>> Hopefully someone there can reply this question.
>> With a pvops dom0 Xen resets devices by writing to its "reset" node in
>> sysfs so it will reset the device using whatever method the dom0 kernel
>> supports for that device.
> And if you use Xen PCI-back it has this enabled so you don't even
> need the 'reset' functionality.
>> The version of Linux I have to hand has, in __pci_dev_reset, calls to
>> the following in this order and stops after the first one which
>> succeeds:
>>        * pci_dev_specific_reset (AKA per device quirks)
>>        * pcie_flr
>>        * pci_af_flr
>>        * pci_pm_reset
>>        * pci_parent_bus_reset
>>
>> See drivers/pci/pci.c in the kernel for more info.
>>
>> IIRC classic Xen kernels had similar code in pciback, although I don't
>> know which specific sets of actions or in which order they were tried.
>>
>> Ian.
>>
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xen.org
>> http://lists.xen.org/xen-devel
>>
> .
>
That sounds like great news, that means that FLR is not a requirement to =

successfully pass through hardware without errors, as is stated in the =

VTdHowTo page. So it seems that the VTdHowTo page needs to be updated =

with this information.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 18 12:07:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Sep 2012 12:07: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 1TDwZp-00032D-UO; Tue, 18 Sep 2012 12:06:53 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <gu99roax@student.chalmers.se>) id 1TDvq9-0002Bi-Hj
	for xen-devel@lists.xen.org; Tue, 18 Sep 2012 11:19:41 +0000
Received: from [85.158.143.99:62645] by server-3.bemta-4.messagelabs.com id
	B8/3E-08232-CC858505; Tue, 18 Sep 2012 11:19:40 +0000
X-Env-Sender: gu99roax@student.chalmers.se
X-Msg-Ref: server-8.tower-216.messagelabs.com!1347967180!21028138!1
X-Originating-IP: [213.199.154.140]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24254 invoked from network); 18 Sep 2012 11:19:40 -0000
Received: from db3ehsobe002.messaging.microsoft.com (HELO
	db3outboundpool.messaging.microsoft.com) (213.199.154.140)
	by server-8.tower-216.messagelabs.com with AES128-SHA encrypted SMTP;
	18 Sep 2012 11:19:40 -0000
Received: from mail25-db3-R.bigfish.com (10.3.81.242) by
	DB3EHSOBE002.bigfish.com (10.3.84.22) with Microsoft SMTP Server id
	14.1.225.23; Tue, 18 Sep 2012 11:19:39 +0000
Received: from mail25-db3 (localhost [127.0.0.1])	by mail25-db3-R.bigfish.com
	(Postfix) with ESMTP id 9DA534C023C;
	Tue, 18 Sep 2012 11:19:39 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:207.46.4.203; KIP:(null); UIP:(null); IPV:NLI;
	H:SN2PRD0102HT006.prod.exchangelabs.com; RD:none; EFVD:NLI
X-SpamScore: -1
X-BigFish: PS-1(zz98dIc89bh936eI1432Id6f1izz1d18h1202h1d1ah1d2ah1082kzz17326ah8275bh8275dh5eeeKz2dh2a8h668h839h8e2h8e3hd25hf0ah107ah10d2h1288h12a5h12a9h12bdhbe9i1155h)
Received: from mail25-db3 (localhost.localdomain [127.0.0.1]) by mail25-db3
	(MessageSwitch) id 1347967177451556_11893;
	Tue, 18 Sep 2012 11:19:37 +0000 (UTC)
Received: from DB3EHSMHS010.bigfish.com (unknown [10.3.81.253])	by
	mail25-db3.bigfish.com (Postfix) with ESMTP id 61773260055;
	Tue, 18 Sep 2012 11:19:37 +0000 (UTC)
Received: from SN2PRD0102HT006.prod.exchangelabs.com (207.46.4.203) by
	DB3EHSMHS010.bigfish.com (10.3.87.110) with Microsoft SMTP Server (TLS)
	id 14.1.225.23; Tue, 18 Sep 2012 11:19:37 +0000
Received: from [10.40.137.93] (217.208.204.161) by pod51000.outlook.com
	(10.27.51.84) with Microsoft SMTP Server (TLS) id 14.15.108.4;
	Tue, 18 Sep 2012 11:19:35 +0000
Message-ID: <505858C3.9080303@student.chalmers.se>
Date: Tue, 18 Sep 2012 13:19:31 +0200
From: Robin Axelsson <gu99roax@student.chalmers.se>
User-Agent: Mozilla/5.0 (Windows NT 5.2; WOW64;
	rv:9.0) Gecko/20111222 Thunderbird/9.0.1
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk <konrad@kernel.org>
References: <20120917113833.GH8912@reaktio.net>
	<50570EA7.8060509@student.chalmers.se>
	<20120917123205.GJ8912@reaktio.net>
	<1347885774.14977.64.camel@zakaz.uk.xensource.com>
	<20120917191556.GB18552@phenom.dumpdata.com>
In-Reply-To: <20120917191556.GB18552@phenom.dumpdata.com>
X-Originating-IP: [217.208.204.161]
X-OriginatorOrg: student.chalmers.se
X-Mailman-Approved-At: Tue, 18 Sep 2012 12:06:52 +0000
Cc: "xen@lists.fedoraproject.org" <xen@lists.fedoraproject.org>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen PCI passthru supported reset methods (d3d0, FLR,
 bus reset, link reset)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: gu99roax@student.chalmers.se
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
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 2012-09-17 21:15, Konrad Rzeszutek Wilk wrote:
> On Mon, Sep 17, 2012 at 01:42:54PM +0100, Ian Campbell wrote:
>> On Mon, 2012-09-17 at 13:32 +0100, Pasi K=E4rkk=E4inen wrote:
>>> On Mon, Sep 17, 2012 at 01:51:03PM +0200, Robin Axelsson wrote:
>>>> There is one thing I wonder though when it comes to PCI passthrough:
>>>>
>>>> Can Xen reset hardware through the d3d0 in the ACPI interface and/or
>>>> through a 'bus reset' or a 'link reset'? Or can it reset hardware
>>>> that is marked for passthrough only through FLR?
>>>>
>>>> For details see e.g.
>>>> http://www.vmware.com/files/pdf/techpaper/vsp_4_vmdirectpath_host.pdf
>>>>
>>> I added xen-devel to the CC-list.
>>> Hopefully someone there can reply this question.
>> With a pvops dom0 Xen resets devices by writing to its "reset" node in
>> sysfs so it will reset the device using whatever method the dom0 kernel
>> supports for that device.
> And if you use Xen PCI-back it has this enabled so you don't even
> need the 'reset' functionality.
>> The version of Linux I have to hand has, in __pci_dev_reset, calls to
>> the following in this order and stops after the first one which
>> succeeds:
>>        * pci_dev_specific_reset (AKA per device quirks)
>>        * pcie_flr
>>        * pci_af_flr
>>        * pci_pm_reset
>>        * pci_parent_bus_reset
>>
>> See drivers/pci/pci.c in the kernel for more info.
>>
>> IIRC classic Xen kernels had similar code in pciback, although I don't
>> know which specific sets of actions or in which order they were tried.
>>
>> Ian.
>>
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xen.org
>> http://lists.xen.org/xen-devel
>>
> .
>
That sounds like great news, that means that FLR is not a requirement to =

successfully pass through hardware without errors, as is stated in the =

VTdHowTo page. So it seems that the VTdHowTo page needs to be updated =

with this information.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 18 12:35:19 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Sep 2012 12:35:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDx0t-0003rH-HR; Tue, 18 Sep 2012 12:34:51 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <arnd@arndb.de>) id 1TDx0s-0003rB-HJ
	for xen-devel@lists.xensource.com; Tue, 18 Sep 2012 12:34:50 +0000
Received: from [85.158.139.83:55101] by server-5.bemta-5.messagelabs.com id
	C7/3A-30514-96A68505; Tue, 18 Sep 2012 12:34:49 +0000
X-Env-Sender: arnd@arndb.de
X-Msg-Ref: server-14.tower-182.messagelabs.com!1347971688!26764699!1
X-Originating-IP: [212.227.126.171]
X-SpamReason: No, hits=0.5 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiAyMTIuMjI3LjEyNi4xNzEgPT4gNjg0MTE=\n,sa_preprocessor: 
	QmFkIElQOiAyMTIuMjI3LjEyNi4xNzEgPT4gNjg0MTE=\n,BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2679 invoked from network); 18 Sep 2012 12:34:48 -0000
Received: from moutng.kundenserver.de (HELO moutng.kundenserver.de)
	(212.227.126.171) by server-14.tower-182.messagelabs.com with SMTP;
	18 Sep 2012 12:34:48 -0000
Received: from klappe2.localnet (deibp9eh1--blueice3n2.emea.ibm.com
	[195.212.29.180])
	by mrelayeu.kundenserver.de (node=mreu4) with ESMTP (Nemesis)
	id 0MCT7F-1TMzZ80o1R-008xf4; Tue, 18 Sep 2012 14:34:31 +0200
From: Arnd Bergmann <arnd@arndb.de>
To: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Date: Tue, 18 Sep 2012 12:34:29 +0000
User-Agent: KMail/1.12.2 (Linux/3.5.0; KDE/4.3.2; x86_64; ; )
References: <alpine.DEB.2.02.1209171215490.29232@kaball.uk.xensource.com>
In-Reply-To: <alpine.DEB.2.02.1209171215490.29232@kaball.uk.xensource.com>
MIME-Version: 1.0
Message-Id: <201209181234.29557.arnd@arndb.de>
X-Provags-ID: V02:K0:bcMTw+7UhK/ACDTwV5qA3ZZHptjq/o/6VKOclcPohqU
	HQ4eEYiFzFJ6Vcclkk0ycZj9Ft2OdkfJdHKm60IHK8mDDj4HSl
	JL4CpovXoiZh8Chskt0Ejt1hF+8BX0Jxh6k+ZriO5WJke3NdJc
	tCQZf1bK/Q+sAdVVQY/HGxvPdPk6KBLWy/qhled3PwdLBrFRud
	89miQ7zCprpkSLwa9HHKG/XtUoFAAv7fwPJ6n9K+QylLEdtRgt
	tglroBjozQqLkIYAA1AqsZNIp02JcUSFEgaWTJp6E/SqCE/Zau
	1IlmJGTAQx+Qtx6DLKbV/xLK2/kU21tUpEf5bwz8OORHspFJre
	FQ5LMtfZRuLGLcXORCW4=
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linaro-dev@lists.linaro.org" <linaro-dev@lists.linaro.org>,
	Ian Campbell <Ian.Campbell@citrix.com>, Pawel Moll <pawel.moll@arm.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"Tim \(Xen.org\)" <tim@xen.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Russell King - ARM Linux <linux@arm.linux.org.uk>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Xen-devel] [PATCH v5 00/17] Introduce Xen support on ARM
	(based on 3.6-rc5)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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 17 September 2012, Stefano Stabellini wrote:

> I am also attaching to this email the dts'es that I am currently using
> for dom0 and domU: vexpress-v2p-ca15-tc1.dts (that includes
> vexpress-v2m-rs1-rtsm.dtsi) is the dts used for dom0 and it is passed to
> Linux by Xen, while vexpress-virt.dts is the dts used for other domUs
> and it is appended in binary form to the guest kernel image. I am not
> sure where they are supposed to live yet, so I am just attaching them
> here so that people can actually try out this series if they want to.

You can submit the dts files separately so we can include them in
the arm-soc tree. Pawel Moll is handling vexpress related changes these
days, so it would be reasonable if he included them in a pull request.
 
> The patch series has been rebased on Konrad's stable/for-linus-3.7
> branch.
> 
> Arnd, Russell, what do you think about this series? If you are OK with
> it, to whom should I submit it?

I have no objections to your patches from this series. IMHO they should
be submitted through the Xen tree, but it would be good to have an Ack
from Russell.

	Arnd

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 18 12:35:19 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Sep 2012 12:35:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDx0t-0003rH-HR; Tue, 18 Sep 2012 12:34:51 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <arnd@arndb.de>) id 1TDx0s-0003rB-HJ
	for xen-devel@lists.xensource.com; Tue, 18 Sep 2012 12:34:50 +0000
Received: from [85.158.139.83:55101] by server-5.bemta-5.messagelabs.com id
	C7/3A-30514-96A68505; Tue, 18 Sep 2012 12:34:49 +0000
X-Env-Sender: arnd@arndb.de
X-Msg-Ref: server-14.tower-182.messagelabs.com!1347971688!26764699!1
X-Originating-IP: [212.227.126.171]
X-SpamReason: No, hits=0.5 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiAyMTIuMjI3LjEyNi4xNzEgPT4gNjg0MTE=\n,sa_preprocessor: 
	QmFkIElQOiAyMTIuMjI3LjEyNi4xNzEgPT4gNjg0MTE=\n,BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2679 invoked from network); 18 Sep 2012 12:34:48 -0000
Received: from moutng.kundenserver.de (HELO moutng.kundenserver.de)
	(212.227.126.171) by server-14.tower-182.messagelabs.com with SMTP;
	18 Sep 2012 12:34:48 -0000
Received: from klappe2.localnet (deibp9eh1--blueice3n2.emea.ibm.com
	[195.212.29.180])
	by mrelayeu.kundenserver.de (node=mreu4) with ESMTP (Nemesis)
	id 0MCT7F-1TMzZ80o1R-008xf4; Tue, 18 Sep 2012 14:34:31 +0200
From: Arnd Bergmann <arnd@arndb.de>
To: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Date: Tue, 18 Sep 2012 12:34:29 +0000
User-Agent: KMail/1.12.2 (Linux/3.5.0; KDE/4.3.2; x86_64; ; )
References: <alpine.DEB.2.02.1209171215490.29232@kaball.uk.xensource.com>
In-Reply-To: <alpine.DEB.2.02.1209171215490.29232@kaball.uk.xensource.com>
MIME-Version: 1.0
Message-Id: <201209181234.29557.arnd@arndb.de>
X-Provags-ID: V02:K0:bcMTw+7UhK/ACDTwV5qA3ZZHptjq/o/6VKOclcPohqU
	HQ4eEYiFzFJ6Vcclkk0ycZj9Ft2OdkfJdHKm60IHK8mDDj4HSl
	JL4CpovXoiZh8Chskt0Ejt1hF+8BX0Jxh6k+ZriO5WJke3NdJc
	tCQZf1bK/Q+sAdVVQY/HGxvPdPk6KBLWy/qhled3PwdLBrFRud
	89miQ7zCprpkSLwa9HHKG/XtUoFAAv7fwPJ6n9K+QylLEdtRgt
	tglroBjozQqLkIYAA1AqsZNIp02JcUSFEgaWTJp6E/SqCE/Zau
	1IlmJGTAQx+Qtx6DLKbV/xLK2/kU21tUpEf5bwz8OORHspFJre
	FQ5LMtfZRuLGLcXORCW4=
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linaro-dev@lists.linaro.org" <linaro-dev@lists.linaro.org>,
	Ian Campbell <Ian.Campbell@citrix.com>, Pawel Moll <pawel.moll@arm.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"Tim \(Xen.org\)" <tim@xen.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Russell King - ARM Linux <linux@arm.linux.org.uk>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Xen-devel] [PATCH v5 00/17] Introduce Xen support on ARM
	(based on 3.6-rc5)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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 17 September 2012, Stefano Stabellini wrote:

> I am also attaching to this email the dts'es that I am currently using
> for dom0 and domU: vexpress-v2p-ca15-tc1.dts (that includes
> vexpress-v2m-rs1-rtsm.dtsi) is the dts used for dom0 and it is passed to
> Linux by Xen, while vexpress-virt.dts is the dts used for other domUs
> and it is appended in binary form to the guest kernel image. I am not
> sure where they are supposed to live yet, so I am just attaching them
> here so that people can actually try out this series if they want to.

You can submit the dts files separately so we can include them in
the arm-soc tree. Pawel Moll is handling vexpress related changes these
days, so it would be reasonable if he included them in a pull request.
 
> The patch series has been rebased on Konrad's stable/for-linus-3.7
> branch.
> 
> Arnd, Russell, what do you think about this series? If you are OK with
> it, to whom should I submit it?

I have no objections to your patches from this series. IMHO they should
be submitted through the Xen tree, but it would be good to have an Ack
from Russell.

	Arnd

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 18 13:11:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Sep 2012 13:11:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDxZb-000523-D7; Tue, 18 Sep 2012 13:10:43 +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 1TDxZa-00051w-4g
	for xen-devel@lists.xensource.com; Tue, 18 Sep 2012 13:10:42 +0000
Received: from [85.158.139.83:55336] by server-4.bemta-5.messagelabs.com id
	8C/15-23042-1D278505; Tue, 18 Sep 2012 13:10:41 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1347973839!16953415!1
X-Originating-IP: [134.134.136.24]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjQgPT4gMzQzODE1\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17277 invoked from network); 18 Sep 2012 13:10:40 -0000
Received: from mga09.intel.com (HELO mga09.intel.com) (134.134.136.24)
	by server-8.tower-182.messagelabs.com with SMTP;
	18 Sep 2012 13:10:40 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga102.jf.intel.com with ESMTP; 18 Sep 2012 06:10:27 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.80,442,1344236400"; d="scan'208";a="206966060"
Received: from fmsmsx108.amr.corp.intel.com ([10.19.9.228])
	by orsmga002.jf.intel.com with ESMTP; 18 Sep 2012 06:10:38 -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; Tue, 18 Sep 2012 06:10:37 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.239]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.175]) with mapi id
	14.01.0355.002; Tue, 18 Sep 2012 21:10:36 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: Jan Beulich <JBeulich@suse.com>, "xen-devel@lists.xensource.com"
	<xen-devel@lists.xensource.com>
Thread-Topic: [PATCH 0/5] Xen vMCE
Thread-Index: Ac2Vnv0gCv7kkud2QzCfAuRzPwCVpA==
Date: Tue, 18 Sep 2012 13:10:36 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC829233532F3D4@SHSMSX101.ccr.corp.intel.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: "keir@xen.org" <keir@xen.org>,
	"Ian.Campbell@citrix.com" <Ian.Campbell@citrix.com>
Subject: [Xen-devel] [PATCH 0/5] Xen vMCE
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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,

These patches are updated per your comments before Xen 4.2 release.

Thanks,
Jinsong
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 18 13:11:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Sep 2012 13:11:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDxZb-000523-D7; Tue, 18 Sep 2012 13:10:43 +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 1TDxZa-00051w-4g
	for xen-devel@lists.xensource.com; Tue, 18 Sep 2012 13:10:42 +0000
Received: from [85.158.139.83:55336] by server-4.bemta-5.messagelabs.com id
	8C/15-23042-1D278505; Tue, 18 Sep 2012 13:10:41 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1347973839!16953415!1
X-Originating-IP: [134.134.136.24]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjQgPT4gMzQzODE1\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17277 invoked from network); 18 Sep 2012 13:10:40 -0000
Received: from mga09.intel.com (HELO mga09.intel.com) (134.134.136.24)
	by server-8.tower-182.messagelabs.com with SMTP;
	18 Sep 2012 13:10:40 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga102.jf.intel.com with ESMTP; 18 Sep 2012 06:10:27 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.80,442,1344236400"; d="scan'208";a="206966060"
Received: from fmsmsx108.amr.corp.intel.com ([10.19.9.228])
	by orsmga002.jf.intel.com with ESMTP; 18 Sep 2012 06:10:38 -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; Tue, 18 Sep 2012 06:10:37 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.239]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.175]) with mapi id
	14.01.0355.002; Tue, 18 Sep 2012 21:10:36 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: Jan Beulich <JBeulich@suse.com>, "xen-devel@lists.xensource.com"
	<xen-devel@lists.xensource.com>
Thread-Topic: [PATCH 0/5] Xen vMCE
Thread-Index: Ac2Vnv0gCv7kkud2QzCfAuRzPwCVpA==
Date: Tue, 18 Sep 2012 13:10:36 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC829233532F3D4@SHSMSX101.ccr.corp.intel.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: "keir@xen.org" <keir@xen.org>,
	"Ian.Campbell@citrix.com" <Ian.Campbell@citrix.com>
Subject: [Xen-devel] [PATCH 0/5] Xen vMCE
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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,

These patches are updated per your comments before Xen 4.2 release.

Thanks,
Jinsong
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 18 13:12:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Sep 2012 13:12:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDxbH-000585-U0; Tue, 18 Sep 2012 13:12:27 +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 1TDxbF-00057v-DQ
	for xen-devel@lists.xensource.com; Tue, 18 Sep 2012 13:12:25 +0000
Received: from [85.158.143.99:8822] by server-3.bemta-4.messagelabs.com id
	7D/5B-08232-83378505; Tue, 18 Sep 2012 13:12:24 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1347973937!22632830!1
X-Originating-IP: [143.182.124.21]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMjEgPT4gMjAzODcx\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26483 invoked from network); 18 Sep 2012 13:12:18 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (143.182.124.21)
	by server-2.tower-216.messagelabs.com with SMTP;
	18 Sep 2012 13:12:18 -0000
Received: from azsmga002.ch.intel.com ([10.2.17.35])
	by azsmga101.ch.intel.com with ESMTP; 18 Sep 2012 06:12:16 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.80,442,1344236400"; d="scan'208";a="146301776"
Received: from fmsmsx104.amr.corp.intel.com ([10.19.9.35])
	by AZSMGA002.ch.intel.com with ESMTP; 18 Sep 2012 06:12:15 -0700
Received: from fmsmsx101.amr.corp.intel.com (10.19.9.52) by
	FMSMSX104.amr.corp.intel.com (10.19.9.35) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Tue, 18 Sep 2012 06:12:14 -0700
Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by
	FMSMSX101.amr.corp.intel.com (10.19.9.52) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Tue, 18 Sep 2012 06:12:14 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.239]) by
	SHSMSX102.ccr.corp.intel.com ([169.254.2.92]) with mapi id
	14.01.0355.002; Tue, 18 Sep 2012 21:12:12 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: Jan Beulich <JBeulich@suse.com>, "xen-devel@lists.xensource.com"
	<xen-devel@lists.xensource.com>
Thread-Topic: [PATCH 1/5] Xen/MCE: vMCE emulation
Thread-Index: Ac2VnzbyiO3Wwe1zTg+unZlXP7YDVQ==
Date: Tue, 18 Sep 2012 13:12:12 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC829233532F3E2@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_DE8DF0795D48FD4CA783C40EC829233532F3E2SHSMSX101ccrcorpi_"
MIME-Version: 1.0
Cc: "keir@xen.org" <keir@xen.org>,
	"Ian.Campbell@citrix.com" <Ian.Campbell@citrix.com>
Subject: [Xen-devel] [PATCH 1/5] Xen/MCE: vMCE emulation
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--_002_DE8DF0795D48FD4CA783C40EC829233532F3E2SHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Xen/MCE: vMCE emulation

This patch provides virtual MCE support to guest. It emulates a simple
and clean MCE MSRs interface to guest by faking caps to guest if needed
and masking caps if unnecessary:
1. Providing a well-defined MCG_CAP to guest, filter out un-necessary caps =
and provide only guest needed caps;
2. Disabling MCG_CTL to avoid model specific;
3. Sticking all 1's to MCi_CTL to guest to avoid model specific;
4. Enabling CMCI cap but never really inject to guest to prevent polling pe=
riodically;
5. Masking MSCOD field of MCi_STATUS to avoid model specific;
6. Keeping natural semantics by per-vcpu instead of per-domain variables;
7. Using bank1 and reserving bank0 to work around 'bank0 quirk' of some ver=
y old processors;
8. Cleaning some vMCE# injection logic which shared by Intel and AMD but us=
eless under new vMCE implement;
9. Keeping compatilbe w/ old xen version which has been backported to SLES1=
1 SP2, so that old vMCE would not blocked when migrate to new vMCE;

Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>

diff -r fbd9e864c047 xen/arch/x86/cpu/mcheck/mce.h
--- a/xen/arch/x86/cpu/mcheck/mce.h	Mon Sep 17 18:02:59 2012 +0800
+++ b/xen/arch/x86/cpu/mcheck/mce.h	Tue Sep 18 22:39:10 2012 +0800
@@ -168,13 +168,12 @@
 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
 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_MCx_CTL2(v->arch.mcg_cap & MCG_CAP_COUNT) )
+         msr < MSR_IA32_MCx_CTL2(v->arch.vmce.mcg_cap & MCG_CAP_COUNT) )
           return 1;
     return 0;
 }
@@ -182,7 +181,7 @@
 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(v->arch.mcg_cap & MCG_CAP_COUNT)) ||
+         msr < MSR_IA32_MCx_CTL(v->arch.vmce.mcg_cap & MCG_CAP_COUNT)) ||
          mce_vendor_bank_msr(v, msr) )
         return 1;
     return 0;
diff -r fbd9e864c047 xen/arch/x86/cpu/mcheck/mce_intel.c
--- a/xen/arch/x86/cpu/mcheck/mce_intel.c	Mon Sep 17 18:02:59 2012 +0800
+++ b/xen/arch/x86/cpu/mcheck/mce_intel.c	Tue Sep 18 22:39:10 2012 +0800
@@ -1300,14 +1300,15 @@
 /* intel specific MCA MSR */
 int intel_mce_wrmsr(struct vcpu *v, uint32_t msr, uint64_t val)
 {
+    unsigned int bank =3D msr - MSR_IA32_MC0_CTL2;
     int ret =3D 0;
=20
-    if ( msr >=3D MSR_IA32_MC0_CTL2 &&
-         msr < MSR_IA32_MCx_CTL2(v->arch.mcg_cap & MCG_CAP_COUNT) )
+    if ( bank < GUEST_MC_BANK_NUM )
     {
-        mce_printk(MCE_QUIET, "We have disabled CMCI capability, "
-                 "Guest should not write this MSR!\n");
-         ret =3D 1;
+        v->arch.vmce.bank[bank].mci_ctl2 =3D val;
+        mce_printk(MCE_VERBOSE, "MCE: wr MC%u_CTL2 %"PRIx64"\n",
+                   bank, val);
+        ret =3D 1;
     }
=20
     return ret;
@@ -1315,13 +1316,14 @@
=20
 int intel_mce_rdmsr(const struct vcpu *v, uint32_t msr, uint64_t *val)
 {
+    unsigned int bank =3D msr - MSR_IA32_MC0_CTL2;
     int ret =3D 0;
=20
-    if ( msr >=3D MSR_IA32_MC0_CTL2 &&
-         msr < MSR_IA32_MCx_CTL2(v->arch.mcg_cap & MCG_CAP_COUNT) )
+    if ( bank < GUEST_MC_BANK_NUM )
     {
-        mce_printk(MCE_QUIET, "We have disabled CMCI capability, "
-                 "Guest should not read this MSR!\n");
+        *val =3D v->arch.vmce.bank[bank].mci_ctl2;
+        mce_printk(MCE_VERBOSE, "MCE: rdmsr MC%u_CTL2 0x%"PRIx64"\n",
+                   bank, *val);
         ret =3D 1;
     }
=20
diff -r fbd9e864c047 xen/arch/x86/cpu/mcheck/vmce.c
--- a/xen/arch/x86/cpu/mcheck/vmce.c	Mon Sep 17 18:02:59 2012 +0800
+++ b/xen/arch/x86/cpu/mcheck/vmce.c	Tue Sep 18 22:39:10 2012 +0800
@@ -1,5 +1,22 @@
 /*
- * vmce.c - virtual MCE support
+ * vmce.c - provide software emulated vMCE support to guest
+ *
+ * Copyright (C) 2010, 2011 Jiang, Yunhong <yunhong.jiang@intel.com>
+ * Copyright (C) 2012, 2013 Liu, Jinsong <jinsong.liu@intel.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * 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  U=
SA
  */
=20
 #include <xen/init.h>
@@ -19,67 +36,55 @@
 #include "mce.h"
 #include "x86_mca.h"
=20
-/*
- * Emulate 2 banks for guest
- * Bank0: reserved for 'bank0 quirk' occur at some very old processors:
- *   1). Intel cpu whose family-model value < 06-1A;
- *   2). AMD K7
- * Bank1: used to transfer error info to guest
- */
-#define GUEST_BANK_NUM 2
-#define GUEST_MCG_CAP (MCG_TES_P | MCG_SER_P | GUEST_BANK_NUM)
-
-#define dom_vmce(x)   ((x)->arch.vmca_msrs)
-
-int vmce_init_msr(struct domain *d)
-{
-    dom_vmce(d) =3D xmalloc(struct domain_mca_msrs);
-    if ( !dom_vmce(d) )
-        return -ENOMEM;
-
-    dom_vmce(d)->mcg_status =3D 0x0;
-    dom_vmce(d)->nr_injection =3D 0;
-
-    INIT_LIST_HEAD(&dom_vmce(d)->impact_header);
-    spin_lock_init(&dom_vmce(d)->lock);
-
-    return 0;
-}
-
-void vmce_destroy_msr(struct domain *d)
-{
-    if ( !dom_vmce(d) )
-        return;
-    xfree(dom_vmce(d));
-    dom_vmce(d) =3D NULL;
-}
-
 void vmce_init_vcpu(struct vcpu *v)
 {
-    v->arch.mcg_cap =3D GUEST_MCG_CAP;
+    int i;
+
+    /* global MCA MSRs init */
+    if ( boot_cpu_data.x86_vendor =3D=3D X86_VENDOR_INTEL )
+        v->arch.vmce.mcg_cap =3D INTEL_GUEST_MCG_CAP;
+    else
+        v->arch.vmce.mcg_cap =3D AMD_GUEST_MCG_CAP;
+
+    v->arch.vmce.mcg_status =3D 0;
+
+    /* per-bank MCA MSRs init */
+    for ( i =3D 0; i < GUEST_MC_BANK_NUM; i++ )
+        memset(&v->arch.vmce.bank[i], 0, sizeof(struct vmce_bank));
+
+    spin_lock_init(&v->arch.vmce.lock);
 }
=20
 int vmce_restore_vcpu(struct vcpu *v, uint64_t caps)
 {
-    if ( caps & ~GUEST_MCG_CAP & ~MCG_CAP_COUNT & ~MCG_CTL_P )
+    uint64_t guest_mcg_cap;
+
+    if ( boot_cpu_data.x86_vendor =3D=3D X86_VENDOR_INTEL )
+        guest_mcg_cap =3D INTEL_GUEST_MCG_CAP;
+    else
+        guest_mcg_cap =3D AMD_GUEST_MCG_CAP;
+
+    if ( caps & ~guest_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, GUEST_MCG_CAP & ~MCG_CAP_COUNT);
+                v->vcpu_id, guest_mcg_cap & ~MCG_CAP_COUNT);
         return -EPERM;
     }
=20
-    v->arch.mcg_cap =3D caps;
+    v->arch.vmce.mcg_cap =3D caps;
     return 0;
 }
=20
-static int bank_mce_rdmsr(const struct vcpu *v, uint32_t msr, uint64_t *va=
l)
+/*
+ * For historic version reason, bank number may greater than GUEST_MC_BANK=
_NUM,
+ * when migratie from old vMCE version to new vMCE.
+ */
+static int bank_mce_rdmsr(struct vcpu *v, uint32_t msr, uint64_t *val)
 {
     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
     *val =3D 0;
=20
@@ -92,46 +97,33 @@
                    bank, *val);
         break;
     case MSR_IA32_MC0_STATUS:
-        /* Only error bank is read. Non-error banks simply return. */
-        if ( !list_empty(&vmce->impact_header) )
+        if ( bank < GUEST_MC_BANK_NUM )
         {
-            entry =3D list_entry(vmce->impact_header.next,
-                               struct bank_entry, list);
-            if ( entry->bank =3D=3D bank )
-            {
-                *val =3D entry->mci_status;
+            *val =3D v->arch.vmce.bank[bank].mci_status;
+            if ( *val )
                 mce_printk(MCE_VERBOSE,
-                           "MCE: rd MC%u_STATUS in vMCE# context "
-                           "value 0x%"PRIx64"\n", bank, *val);
-            }
+                           "MCE: rdmsr MC%u_STATUS in vMCE# context "
+                           "0x%"PRIx64"\n", bank, *val);
         }
         break;
     case MSR_IA32_MC0_ADDR:
-        if ( !list_empty(&vmce->impact_header) )
+        if ( bank < GUEST_MC_BANK_NUM )
         {
-            entry =3D list_entry(vmce->impact_header.next,
-                               struct bank_entry, list);
-            if ( entry->bank =3D=3D bank )
-            {
-                *val =3D entry->mci_addr;
+            *val =3D v->arch.vmce.bank[bank].mci_addr;
+            if ( *val )
                 mce_printk(MCE_VERBOSE,
                            "MCE: rdmsr MC%u_ADDR in vMCE# context "
                            "0x%"PRIx64"\n", bank, *val);
-            }
         }
         break;
     case MSR_IA32_MC0_MISC:
-        if ( !list_empty(&vmce->impact_header) )
+        if ( bank < GUEST_MC_BANK_NUM )
         {
-            entry =3D list_entry(vmce->impact_header.next,
-                               struct bank_entry, list);
-            if ( entry->bank =3D=3D bank )
-            {
-                *val =3D entry->mci_misc;
+            *val =3D v->arch.vmce.bank[bank].mci_misc;
+            if ( *val )
                 mce_printk(MCE_VERBOSE,
-                           "MCE: rd MC%u_MISC in vMCE# context "
+                           "MCE: rdmsr MC%u_MISC in vMCE# context "
                            "0x%"PRIx64"\n", bank, *val);
-            }
         }
         break;
     default:
@@ -157,56 +149,50 @@
  */
 int vmce_rdmsr(uint32_t msr, uint64_t *val)
 {
-    const struct vcpu *cur =3D current;
-    struct domain_mca_msrs *vmce =3D dom_vmce(cur->domain);
+    struct vcpu *cur =3D current;
     int ret =3D 1;
=20
     *val =3D 0;
=20
-    spin_lock(&vmce->lock);
+    spin_lock(&cur->arch.vmce.lock);
=20
     switch ( msr )
     {
     case MSR_IA32_MCG_STATUS:
-        *val =3D vmce->mcg_status;
+        *val =3D cur->arch.vmce.mcg_status;
         if (*val)
             mce_printk(MCE_VERBOSE,
                        "MCE: rdmsr MCG_STATUS 0x%"PRIx64"\n", *val);
         break;
     case MSR_IA32_MCG_CAP:
-        *val =3D cur->arch.mcg_cap;
-        mce_printk(MCE_VERBOSE, "MCE: rdmsr MCG_CAP 0x%"PRIx64"\n",
-                   *val);
+        *val =3D cur->arch.vmce.mcg_cap;
+        mce_printk(MCE_VERBOSE, "MCE: rdmsr MCG_CAP 0x%"PRIx64"\n", *val);
         break;
     case MSR_IA32_MCG_CTL:
-        /* Stick all 1's when CTL support, and 0's when no CTL support */
-        if ( cur->arch.mcg_cap & MCG_CTL_P )
-            *val =3D ~0ULL;
-        mce_printk(MCE_VERBOSE, "MCE: rdmsr MCG_CTL 0x%"PRIx64"\n", *val);
+        if ( cur->arch.vmce.mcg_cap & MCG_CTL_P )
+        {
+            *val =3D ~0UL;
+            mce_printk(MCE_VERBOSE, "MCE: rdmsr MCG_CTL 0x%"PRIx64"\n", *v=
al);
+        }
         break;
     default:
         ret =3D mce_bank_msr(cur, msr) ? bank_mce_rdmsr(cur, msr, val) : 0=
;
         break;
     }
=20
-    spin_unlock(&vmce->lock);
+    spin_unlock(&cur->arch.vmce.lock);
+
     return ret;
 }
=20
+/*
+ * For historic version reason, bank number may greater than GUEST_MC_BANK=
_NUM,
+ * when migratie from old vMCE version to new vMCE.
+ */
 static int bank_mce_wrmsr(struct vcpu *v, u32 msr, u64 val)
 {
     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;
-
-    /* Give the first entry of the list, it corresponds to current
-     * vMCE# injection. When vMCE# is finished processing by the
-     * the guest, this node will be deleted.
-     * Only error bank is written. Non-error banks simply return.
-     */
-    if ( !list_empty(&vmce->impact_header) )
-        entry =3D list_entry(vmce->impact_header.next, struct bank_entry, =
list);
=20
     switch ( msr & (MSR_IA32_MC0_CTL | 3) )
     {
@@ -217,50 +203,46 @@
          */
         break;
     case MSR_IA32_MC0_STATUS:
-        if ( entry && (entry->bank =3D=3D bank) )
+        if ( val )
         {
-            entry->mci_status =3D val;
-            mce_printk(MCE_VERBOSE,
-                       "MCE: wr MC%u_STATUS %"PRIx64" in vMCE#\n",
+            mce_printk(MCE_QUIET,
+                       "MCE: wr MC%u_STATUS w/ non-zero cause #GP\n", bank=
);
+            ret =3D -1;
+        }
+        if ( bank < GUEST_MC_BANK_NUM )
+        {
+            v->arch.vmce.bank[bank].mci_status =3D val;
+            mce_printk(MCE_VERBOSE, "MCE: wr MC%u_STATUS %"PRIx64"\n",
                        bank, val);
         }
-        else
-            mce_printk(MCE_VERBOSE,
-                       "MCE: wr MC%u_STATUS %"PRIx64"\n", bank, val);
         break;
     case MSR_IA32_MC0_ADDR:
-        if ( !~val )
+        if ( val )
         {
             mce_printk(MCE_QUIET,
-                       "MCE: wr MC%u_ADDR with all 1s will cause #GP\n", b=
ank);
+                       "MCE: wr MC%u_ADDR w/ non-zero cause #GP\n", bank);
             ret =3D -1;
         }
-        else if ( entry && (entry->bank =3D=3D bank) )
+        else if ( bank < GUEST_MC_BANK_NUM )
         {
-            entry->mci_addr =3D val;
-            mce_printk(MCE_VERBOSE,
-                       "MCE: wr MC%u_ADDR %"PRIx64" in vMCE#\n", bank, val=
);
-        }
-        else
+            v->arch.vmce.bank[bank].mci_addr =3D val;
             mce_printk(MCE_VERBOSE,
                        "MCE: wr MC%u_ADDR %"PRIx64"\n", bank, val);
+        }
         break;
     case MSR_IA32_MC0_MISC:
-        if ( !~val )
+        if ( val )
         {
             mce_printk(MCE_QUIET,
-                       "MCE: wr MC%u_MISC with all 1s will cause #GP\n", b=
ank);
+                       "MCE: wr MC%u_MISC w/ non-zero cause #GP\n", bank);
             ret =3D -1;
         }
-        else if ( entry && (entry->bank =3D=3D bank) )
+        else if ( bank < GUEST_MC_BANK_NUM )
         {
-            entry->mci_misc =3D val;
-            mce_printk(MCE_VERBOSE,
-                       "MCE: wr MC%u_MISC %"PRIx64" in vMCE#\n", bank, val=
);
-        }
-        else
+            v->arch.vmce.bank[bank].mci_misc =3D val;
             mce_printk(MCE_VERBOSE,
                        "MCE: wr MC%u_MISC %"PRIx64"\n", bank, val);
+        }
         break;
     default:
         switch ( boot_cpu_data.x86_vendor )
@@ -286,52 +268,33 @@
 int vmce_wrmsr(u32 msr, u64 val)
 {
     struct vcpu *cur =3D current;
-    struct bank_entry *entry =3D NULL;
-    struct domain_mca_msrs *vmce =3D dom_vmce(cur->domain);
     int ret =3D 1;
=20
-    spin_lock(&vmce->lock);
+    spin_lock(&cur->arch.vmce.lock);
=20
     switch ( msr )
     {
     case MSR_IA32_MCG_CTL:
+        /* If MCG_CTL exist then stick to all 1's. If not exist then ignor=
e */
         break;
     case MSR_IA32_MCG_STATUS:
-        vmce->mcg_status =3D val;
+        cur->arch.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 ( is_hvm_vcpu(cur) && (vmce->nr_injection > 0) )
-        {
-            vmce->nr_injection--; /* Should be 0 */
-            if ( !list_empty(&vmce->impact_header) )
-            {
-                entry =3D list_entry(vmce->impact_header.next,
-                                   struct bank_entry, list);
-                if ( entry->mci_status & MCi_STATUS_VAL )
-                    mce_printk(MCE_QUIET, "MCE: MCi_STATUS MSR should have=
 "
-                               "been cleared before write MCG_STATUS MSR\n=
");
-
-                mce_printk(MCE_QUIET, "MCE: Delete HVM last injection "
-                           "Node, nr_injection %u\n",
-                           vmce->nr_injection);
-                list_del(&entry->list);
-                xfree(entry);
-            }
-            else
-                mce_printk(MCE_QUIET, "MCE: Not found HVM guest"
-                           " last injection Node, something Wrong!\n");
-        }
         break;
     case MSR_IA32_MCG_CAP:
-        mce_printk(MCE_QUIET, "MCE: MCG_CAP is read-only\n");
-        ret =3D -1;
+        /*
+         * According to Intel SDM, IA32_MCG_CAP is a read-only register,
+         * the effect of writing to the IA32_MCG_CAP is undefined. Here we
+         * treat writing as 'write not change'. Guest would not surprise.
+         */
+        mce_printk(MCE_QUIET, "MCE: MCG_CAP is read only and write not cha=
nge\n");
         break;
     default:
         ret =3D mce_bank_msr(cur, msr) ? bank_mce_wrmsr(cur, msr, val) : 0=
;
         break;
     }
=20
-    spin_unlock(&vmce->lock);
+    spin_unlock(&cur->arch.vmce.lock);
     return ret;
 }
=20
@@ -342,7 +305,7 @@
=20
     for_each_vcpu( d, v ) {
         struct hvm_vmce_vcpu ctxt =3D {
-            .caps =3D v->arch.mcg_cap
+            .caps =3D v->arch.vmce.mcg_cap
         };
=20
         err =3D hvm_save_entry(VMCE_VCPU, v->vcpu_id, h, &ctxt);
@@ -422,93 +385,38 @@
     return 0;
 }
=20
-/* 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
- * virtualization. When one vMCE# injection is finished processing
- * processed by guest, the corresponding node will be deleted.
- * This node list is for GUEST vMCE# MSRS virtualization.
- */
-static struct bank_entry* alloc_bank_entry(void)
+int fill_vmsr_data(struct mcinfo_bank *mc_bank, struct domain *d,
+                   uint64_t gstatus)
 {
-    struct bank_entry *entry;
+    struct vcpu *v =3D d->vcpu[0];
=20
-    entry =3D xzalloc(struct bank_entry);
-    if ( entry =3D=3D NULL )
-    {
-        printk(KERN_ERR "MCE: malloc bank_entry failed\n");
-        return NULL;
-    }
-
-    INIT_LIST_HEAD(&entry->list);
-    return entry;
-}
-
-/* Fill error bank info for #vMCE injection and GUEST vMCE#
- * MSR virtualization data
- * 1) Log down how many nr_injections of the impacted.
- * 2) Copy MCE# error bank to impacted DOM node list,
- *    for vMCE# MSRs virtualization
- */
-int fill_vmsr_data(struct mcinfo_bank *mc_bank, struct domain *d,
-                   uint64_t gstatus) {
-    struct bank_entry *entry;
-
-    /* This error bank impacts one domain, we need to fill domain related
-     * data for vMCE MSRs virtualization and vMCE# injection */
     if ( mc_bank->mc_domid !=3D (uint16_t)~0 )
     {
-        /* For HVM guest, Only when first vMCE is consumed by HVM guest
-         * successfully, will we generete another node and inject another =
vMCE.
-         */
-        if ( d->is_hvm && (dom_vmce(d)->nr_injection > 0) )
+        if ( v->arch.vmce.mcg_status & MCG_STATUS_MCIP )
         {
-            mce_printk(MCE_QUIET, "MCE: HVM guest has not handled previous=
"
+            mce_printk(MCE_QUIET, "MCE: guest has not handled previous"
                        " vMCE yet!\n");
             return -1;
         }
=20
-        entry =3D alloc_bank_entry();
-        if ( entry =3D=3D NULL )
-            return -1;
+        spin_lock(&v->arch.vmce.lock);
=20
-        entry->mci_status =3D mc_bank->mc_status;
-        entry->mci_addr =3D mc_bank->mc_addr;
-        entry->mci_misc =3D mc_bank->mc_misc;
-        entry->bank =3D mc_bank->mc_bank;
+        v->arch.vmce.mcg_status =3D gstatus;
+        /*
+         * 1. Skip bank 0 to avoid 'bank 0 quirk' of old processors
+         * 2. Filter MCi_STATUS MSCOD model specific error code to guest
+         */
+        v->arch.vmce.bank[1].mci_status =3D mc_bank->mc_status &
+                                              MCi_STATUS_MSCOD_MASK;
+        v->arch.vmce.bank[1].mci_addr =3D mc_bank->mc_addr;
+        v->arch.vmce.bank[1].mci_misc =3D mc_bank->mc_misc;
=20
-        spin_lock(&dom_vmce(d)->lock);
-        /* New error Node, insert to the tail of the per_dom data */
-        list_add_tail(&entry->list, &dom_vmce(d)->impact_header);
-        /* Fill MSR global status */
-        dom_vmce(d)->mcg_status =3D gstatus;
-        /* New node impact the domain, need another vMCE# injection*/
-        dom_vmce(d)->nr_injection++;
-        spin_unlock(&dom_vmce(d)->lock);
-
-        mce_printk(MCE_VERBOSE,"MCE: Found error @[BANK%d "
-                   "status %"PRIx64" addr %"PRIx64" domid %d]\n ",
-                   mc_bank->mc_bank, mc_bank->mc_status, mc_bank->mc_addr,
-                   mc_bank->mc_domid);
+        spin_unlock(&v->arch.vmce.lock);
     }
=20
     return 0;
 }
=20
-#if 0 /* currently unused */
-int vmce_domain_inject(
-    struct mcinfo_bank *bank, struct domain *d, struct mcinfo_global *glob=
al)
-{
-    int ret;
-
-    ret =3D fill_vmsr_data(bank, d, global->mc_gstatus);
-    if ( ret < 0 )
-        return ret;
-
-    return inject_vmce(d);
-}
-#endif
-
 static int is_hvm_vmce_ready(struct mcinfo_bank *bank, struct domain *d)
 {
     struct vcpu *v;
diff -r fbd9e864c047 xen/arch/x86/domain.c
--- a/xen/arch/x86/domain.c	Mon Sep 17 18:02:59 2012 +0800
+++ b/xen/arch/x86/domain.c	Tue Sep 18 22:39:10 2012 +0800
@@ -571,9 +571,6 @@
=20
         if ( (rc =3D iommu_domain_init(d)) !=3D 0 )
             goto fail;
-
-        /* For Guest vMCE MSRs virtualization */
-        vmce_init_msr(d);
     }
=20
     if ( is_hvm_domain(d) )
@@ -600,7 +597,6 @@
=20
  fail:
     d->is_dying =3D DOMDYING_dead;
-    vmce_destroy_msr(d);
     cleanup_domain_irq_mapping(d);
     free_xenheap_page(d->shared_info);
     if ( paging_initialised )
@@ -623,7 +619,6 @@
     else
         xfree(d->arch.pv_domain.e820);
=20
-    vmce_destroy_msr(d);
     free_domain_pirqs(d);
     if ( !is_idle_domain(d) )
         iommu_domain_destroy(d);
diff -r fbd9e864c047 xen/arch/x86/domctl.c
--- a/xen/arch/x86/domctl.c	Mon Sep 17 18:02:59 2012 +0800
+++ b/xen/arch/x86/domctl.c	Tue Sep 18 22:39:10 2012 +0800
@@ -1024,7 +1024,7 @@
                 evc->syscall32_callback_eip    =3D 0;
                 evc->syscall32_disables_events =3D 0;
             }
-            evc->mcg_cap =3D v->arch.mcg_cap;
+            evc->mcg_cap =3D v->arch.vmce.mcg_cap;
         }
         else
         {
diff -r fbd9e864c047 xen/arch/x86/traps.c
--- a/xen/arch/x86/traps.c	Mon Sep 17 18:02:59 2012 +0800
+++ b/xen/arch/x86/traps.c	Tue Sep 18 22:39:10 2012 +0800
@@ -3133,50 +3133,6 @@
                 break;
     ASSERT(trap <=3D VCPU_TRAP_LAST);
=20
-    /* inject vMCE to PV_Guest including DOM0. */
-    if ( trap =3D=3D VCPU_TRAP_MCE )
-    {
-        gdprintk(XENLOG_DEBUG, "MCE: Return from vMCE# trap!\n");
-        if ( curr->vcpu_id =3D=3D 0 )
-        {
-            struct domain *d =3D curr->domain;
-
-            if ( !d->arch.vmca_msrs->nr_injection )
-            {
-                printk(XENLOG_WARNING "MCE: ret from vMCE#, "
-                       "no injection node\n");
-                goto end;
-            }
-
-            d->arch.vmca_msrs->nr_injection--;
-            if ( !list_empty(&d->arch.vmca_msrs->impact_header) )
-            {
-                struct bank_entry *entry;
-
-                entry =3D list_entry(d->arch.vmca_msrs->impact_header.next=
,
-                                   struct bank_entry, list);
-                gdprintk(XENLOG_DEBUG, "MCE: delete last injection node\n"=
);
-                list_del(&entry->list);
-            }
-            else
-                printk(XENLOG_ERR "MCE: didn't found last injection node\n=
");
-
-            /* further injection */
-            if ( d->arch.vmca_msrs->nr_injection > 0 &&
-                 guest_has_trap_callback(d, 0, TRAP_machine_check) &&
-                 !test_and_set_bool(curr->mce_pending) )
-            {
-                int cpu =3D smp_processor_id();
-
-                cpumask_copy(curr->cpu_affinity_tmp, curr->cpu_affinity);
-                printk(XENLOG_DEBUG "MCE: CPU%d set affinity, old %d\n",
-                       cpu, curr->processor);
-                vcpu_set_affinity(curr, cpumask_of(cpu));
-            }
-        }
-    }
-
-end:
     /* Restore previous asynchronous exception mask. */
     curr->async_exception_mask =3D curr->async_exception_state(trap).old_m=
ask;
 }
diff -r fbd9e864c047 xen/include/asm-x86/domain.h
--- a/xen/include/asm-x86/domain.h	Mon Sep 17 18:02:59 2012 +0800
+++ b/xen/include/asm-x86/domain.h	Tue Sep 18 22:39:10 2012 +0800
@@ -296,9 +296,6 @@
=20
     struct PITState vpit;
=20
-    /* For Guest vMCA handling */
-    struct domain_mca_msrs *vmca_msrs;
-
     /* TSC management (emulation, pv, scaling, stats) */
     int tsc_mode;            /* see include/asm-x86/time.h */
     bool_t vtsc;             /* tsc is emulated (may change after migrate)=
 */
@@ -438,8 +435,8 @@
      * and thus should be saved/restored. */
     bool_t nonlazy_xstate_used;
=20
-    uint64_t mcg_cap;
-   =20
+    struct vmce vmce;
+
     struct paging_vcpu paging;
=20
     uint32_t gdbsx_vcpu_event;
diff -r fbd9e864c047 xen/include/asm-x86/mce.h
--- a/xen/include/asm-x86/mce.h	Mon Sep 17 18:02:59 2012 +0800
+++ b/xen/include/asm-x86/mce.h	Tue Sep 18 22:39:10 2012 +0800
@@ -3,28 +3,50 @@
 #ifndef _XEN_X86_MCE_H
 #define _XEN_X86_MCE_H
=20
-/* This entry is for recording bank nodes for the impacted domain,
- * put into impact_header list. */
-struct bank_entry {
-    struct list_head list;
-    uint16_t bank;
+/*
+ * Emulalte 2 banks for guest
+ * Bank0: reserved for 'bank0 quirk' occur at some very old processors:
+ *   1). Intel cpu whose family-model value < 06-1A;
+ *   2). AMD K7
+ * Bank1: used to transfer error info to guest
+ */
+#define GUEST_MC_BANK_NUM 2
+
+/*
+ * MCG_SER_P:  software error recovery supported
+ * MCG_TES_P:  to avoid MCi_status bit56:53 model specific
+ * MCG_CMCI_P: expose CMCI capability but never really inject it to guest,
+ *             for sake of performance since guest not polling periodicall=
y
+ */
+#define INTEL_GUEST_MCG_CAP (MCG_SER_P |	\
+                             MCG_TES_P |	\
+                             MCG_CMCI_P |	\
+                             GUEST_MC_BANK_NUM)
+
+#define AMD_GUEST_MCG_CAP (MCG_SER_P |		\
+                           GUEST_MC_BANK_NUM)
+
+/* Filter MSCOD model specific error code to guest */
+#define MCi_STATUS_MSCOD_MASK (~(0xffffULL << 16))
+
+/* No mci_ctl since it stick all 1's */
+struct vmce_bank {
     uint64_t mci_status;
     uint64_t mci_addr;
     uint64_t mci_misc;
+    uint64_t mci_ctl2;
 };
=20
-struct domain_mca_msrs
-{
-    /* Guest should not change below values after DOM boot up */
+/* No mcg_ctl since it not expose to guest */
+struct vmce {
+    uint64_t mcg_cap;
     uint64_t mcg_status;
-    uint16_t nr_injection;
-    struct list_head impact_header;
+    struct vmce_bank bank[GUEST_MC_BANK_NUM];
+
     spinlock_t lock;
 };
=20
 /* 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);=

--_002_DE8DF0795D48FD4CA783C40EC829233532F3E2SHSMSX101ccrcorpi_
Content-Type: application/octet-stream; name="1_vmce_emulation.patch"
Content-Description: 1_vmce_emulation.patch
Content-Disposition: attachment; filename="1_vmce_emulation.patch";
	size=27202; creation-date="Tue, 18 Sep 2012 13:04:35 GMT";
	modification-date="Tue, 18 Sep 2012 20:46:56 GMT"
Content-Transfer-Encoding: base64

WGVuL01DRTogdk1DRSBlbXVsYXRpb24KClRoaXMgcGF0Y2ggcHJvdmlkZXMgdmlydHVhbCBNQ0Ug
c3VwcG9ydCB0byBndWVzdC4gSXQgZW11bGF0ZXMgYSBzaW1wbGUKYW5kIGNsZWFuIE1DRSBNU1Jz
IGludGVyZmFjZSB0byBndWVzdCBieSBmYWtpbmcgY2FwcyB0byBndWVzdCBpZiBuZWVkZWQKYW5k
IG1hc2tpbmcgY2FwcyBpZiB1bm5lY2Vzc2FyeToKMS4gUHJvdmlkaW5nIGEgd2VsbC1kZWZpbmVk
IE1DR19DQVAgdG8gZ3Vlc3QsIGZpbHRlciBvdXQgdW4tbmVjZXNzYXJ5IGNhcHMgYW5kIHByb3Zp
ZGUgb25seSBndWVzdCBuZWVkZWQgY2FwczsKMi4gRGlzYWJsaW5nIE1DR19DVEwgdG8gYXZvaWQg
bW9kZWwgc3BlY2lmaWM7CjMuIFN0aWNraW5nIGFsbCAxJ3MgdG8gTUNpX0NUTCB0byBndWVzdCB0
byBhdm9pZCBtb2RlbCBzcGVjaWZpYzsKNC4gRW5hYmxpbmcgQ01DSSBjYXAgYnV0IG5ldmVyIHJl
YWxseSBpbmplY3QgdG8gZ3Vlc3QgdG8gcHJldmVudCBwb2xsaW5nIHBlcmlvZGljYWxseTsKNS4g
TWFza2luZyBNU0NPRCBmaWVsZCBvZiBNQ2lfU1RBVFVTIHRvIGF2b2lkIG1vZGVsIHNwZWNpZmlj
Owo2LiBLZWVwaW5nIG5hdHVyYWwgc2VtYW50aWNzIGJ5IHBlci12Y3B1IGluc3RlYWQgb2YgcGVy
LWRvbWFpbiB2YXJpYWJsZXM7CjcuIFVzaW5nIGJhbmsxIGFuZCByZXNlcnZpbmcgYmFuazAgdG8g
d29yayBhcm91bmQgJ2JhbmswIHF1aXJrJyBvZiBzb21lIHZlcnkgb2xkIHByb2Nlc3NvcnM7Cjgu
IENsZWFuaW5nIHNvbWUgdk1DRSMgaW5qZWN0aW9uIGxvZ2ljIHdoaWNoIHNoYXJlZCBieSBJbnRl
bCBhbmQgQU1EIGJ1dCB1c2VsZXNzIHVuZGVyIG5ldyB2TUNFIGltcGxlbWVudDsKOS4gS2VlcGlu
ZyBjb21wYXRpbGJlIHcvIG9sZCB4ZW4gdmVyc2lvbiB3aGljaCBoYXMgYmVlbiBiYWNrcG9ydGVk
IHRvIFNMRVMxMSBTUDIsIHNvIHRoYXQgb2xkIHZNQ0Ugd291bGQgbm90IGJsb2NrZWQgd2hlbiBt
aWdyYXRlIHRvIG5ldyB2TUNFOwoKU2lnbmVkLW9mZi1ieTogTGl1LCBKaW5zb25nIDxqaW5zb25n
LmxpdUBpbnRlbC5jb20+CgpkaWZmIC1yIGZiZDllODY0YzA0NyB4ZW4vYXJjaC94ODYvY3B1L21j
aGVjay9tY2UuaAotLS0gYS94ZW4vYXJjaC94ODYvY3B1L21jaGVjay9tY2UuaAlNb24gU2VwIDE3
IDE4OjAyOjU5IDIwMTIgKzA4MDAKKysrIGIveGVuL2FyY2gveDg2L2NwdS9tY2hlY2svbWNlLmgJ
VHVlIFNlcCAxOCAyMjozOToxMCAyMDEyICswODAwCkBAIC0xNjgsMTMgKzE2OCwxMiBAQAogaW50
IGZpbGxfdm1zcl9kYXRhKHN0cnVjdCBtY2luZm9fYmFuayAqbWNfYmFuaywgc3RydWN0IGRvbWFp
biAqZCwKICAgICAgICAgdWludDY0X3QgZ3N0YXR1cyk7CiBpbnQgaW5qZWN0X3ZtY2Uoc3RydWN0
IGRvbWFpbiAqZCk7Ci1pbnQgdm1jZV9kb21haW5faW5qZWN0KHN0cnVjdCBtY2luZm9fYmFuayAq
YmFuaywgc3RydWN0IGRvbWFpbiAqZCwgc3RydWN0IG1jaW5mb19nbG9iYWwgKmdsb2JhbCk7CiAK
IHN0YXRpYyBpbmxpbmUgaW50IG1jZV92ZW5kb3JfYmFua19tc3IoY29uc3Qgc3RydWN0IHZjcHUg
KnYsIHVpbnQzMl90IG1zcikKIHsKICAgICBpZiAoIGJvb3RfY3B1X2RhdGEueDg2X3ZlbmRvciA9
PSBYODZfVkVORE9SX0lOVEVMICYmCiAgICAgICAgICBtc3IgPj0gTVNSX0lBMzJfTUMwX0NUTDIg
JiYKLSAgICAgICAgIG1zciA8IE1TUl9JQTMyX01DeF9DVEwyKHYtPmFyY2gubWNnX2NhcCAmIE1D
R19DQVBfQ09VTlQpICkKKyAgICAgICAgIG1zciA8IE1TUl9JQTMyX01DeF9DVEwyKHYtPmFyY2gu
dm1jZS5tY2dfY2FwICYgTUNHX0NBUF9DT1VOVCkgKQogICAgICAgICAgIHJldHVybiAxOwogICAg
IHJldHVybiAwOwogfQpAQCAtMTgyLDcgKzE4MSw3IEBACiBzdGF0aWMgaW5saW5lIGludCBtY2Vf
YmFua19tc3IoY29uc3Qgc3RydWN0IHZjcHUgKnYsIHVpbnQzMl90IG1zcikKIHsKICAgICBpZiAo
IChtc3IgPj0gTVNSX0lBMzJfTUMwX0NUTCAmJgotICAgICAgICAgIG1zciA8IE1TUl9JQTMyX01D
eF9DVEwodi0+YXJjaC5tY2dfY2FwICYgTUNHX0NBUF9DT1VOVCkpIHx8CisgICAgICAgICBtc3Ig
PCBNU1JfSUEzMl9NQ3hfQ1RMKHYtPmFyY2gudm1jZS5tY2dfY2FwICYgTUNHX0NBUF9DT1VOVCkp
IHx8CiAgICAgICAgICBtY2VfdmVuZG9yX2JhbmtfbXNyKHYsIG1zcikgKQogICAgICAgICByZXR1
cm4gMTsKICAgICByZXR1cm4gMDsKZGlmZiAtciBmYmQ5ZTg2NGMwNDcgeGVuL2FyY2gveDg2L2Nw
dS9tY2hlY2svbWNlX2ludGVsLmMKLS0tIGEveGVuL2FyY2gveDg2L2NwdS9tY2hlY2svbWNlX2lu
dGVsLmMJTW9uIFNlcCAxNyAxODowMjo1OSAyMDEyICswODAwCisrKyBiL3hlbi9hcmNoL3g4Ni9j
cHUvbWNoZWNrL21jZV9pbnRlbC5jCVR1ZSBTZXAgMTggMjI6Mzk6MTAgMjAxMiArMDgwMApAQCAt
MTMwMCwxNCArMTMwMCwxNSBAQAogLyogaW50ZWwgc3BlY2lmaWMgTUNBIE1TUiAqLwogaW50IGlu
dGVsX21jZV93cm1zcihzdHJ1Y3QgdmNwdSAqdiwgdWludDMyX3QgbXNyLCB1aW50NjRfdCB2YWwp
CiB7CisgICAgdW5zaWduZWQgaW50IGJhbmsgPSBtc3IgLSBNU1JfSUEzMl9NQzBfQ1RMMjsKICAg
ICBpbnQgcmV0ID0gMDsKIAotICAgIGlmICggbXNyID49IE1TUl9JQTMyX01DMF9DVEwyICYmCi0g
ICAgICAgICBtc3IgPCBNU1JfSUEzMl9NQ3hfQ1RMMih2LT5hcmNoLm1jZ19jYXAgJiBNQ0dfQ0FQ
X0NPVU5UKSApCisgICAgaWYgKCBiYW5rIDwgR1VFU1RfTUNfQkFOS19OVU0gKQogICAgIHsKLSAg
ICAgICAgbWNlX3ByaW50ayhNQ0VfUVVJRVQsICJXZSBoYXZlIGRpc2FibGVkIENNQ0kgY2FwYWJp
bGl0eSwgIgotICAgICAgICAgICAgICAgICAiR3Vlc3Qgc2hvdWxkIG5vdCB3cml0ZSB0aGlzIE1T
UiFcbiIpOwotICAgICAgICAgcmV0ID0gMTsKKyAgICAgICAgdi0+YXJjaC52bWNlLmJhbmtbYmFu
a10ubWNpX2N0bDIgPSB2YWw7CisgICAgICAgIG1jZV9wcmludGsoTUNFX1ZFUkJPU0UsICJNQ0U6
IHdyIE1DJXVfQ1RMMiAlIlBSSXg2NCJcbiIsCisgICAgICAgICAgICAgICAgICAgYmFuaywgdmFs
KTsKKyAgICAgICAgcmV0ID0gMTsKICAgICB9CiAKICAgICByZXR1cm4gcmV0OwpAQCAtMTMxNSwx
MyArMTMxNiwxNCBAQAogCiBpbnQgaW50ZWxfbWNlX3JkbXNyKGNvbnN0IHN0cnVjdCB2Y3B1ICp2
LCB1aW50MzJfdCBtc3IsIHVpbnQ2NF90ICp2YWwpCiB7CisgICAgdW5zaWduZWQgaW50IGJhbmsg
PSBtc3IgLSBNU1JfSUEzMl9NQzBfQ1RMMjsKICAgICBpbnQgcmV0ID0gMDsKIAotICAgIGlmICgg
bXNyID49IE1TUl9JQTMyX01DMF9DVEwyICYmCi0gICAgICAgICBtc3IgPCBNU1JfSUEzMl9NQ3hf
Q1RMMih2LT5hcmNoLm1jZ19jYXAgJiBNQ0dfQ0FQX0NPVU5UKSApCisgICAgaWYgKCBiYW5rIDwg
R1VFU1RfTUNfQkFOS19OVU0gKQogICAgIHsKLSAgICAgICAgbWNlX3ByaW50ayhNQ0VfUVVJRVQs
ICJXZSBoYXZlIGRpc2FibGVkIENNQ0kgY2FwYWJpbGl0eSwgIgotICAgICAgICAgICAgICAgICAi
R3Vlc3Qgc2hvdWxkIG5vdCByZWFkIHRoaXMgTVNSIVxuIik7CisgICAgICAgICp2YWwgPSB2LT5h
cmNoLnZtY2UuYmFua1tiYW5rXS5tY2lfY3RsMjsKKyAgICAgICAgbWNlX3ByaW50ayhNQ0VfVkVS
Qk9TRSwgIk1DRTogcmRtc3IgTUMldV9DVEwyIDB4JSJQUkl4NjQiXG4iLAorICAgICAgICAgICAg
ICAgICAgIGJhbmssICp2YWwpOwogICAgICAgICByZXQgPSAxOwogICAgIH0KIApkaWZmIC1yIGZi
ZDllODY0YzA0NyB4ZW4vYXJjaC94ODYvY3B1L21jaGVjay92bWNlLmMKLS0tIGEveGVuL2FyY2gv
eDg2L2NwdS9tY2hlY2svdm1jZS5jCU1vbiBTZXAgMTcgMTg6MDI6NTkgMjAxMiArMDgwMAorKysg
Yi94ZW4vYXJjaC94ODYvY3B1L21jaGVjay92bWNlLmMJVHVlIFNlcCAxOCAyMjozOToxMCAyMDEy
ICswODAwCkBAIC0xLDUgKzEsMjIgQEAKIC8qCi0gKiB2bWNlLmMgLSB2aXJ0dWFsIE1DRSBzdXBw
b3J0CisgKiB2bWNlLmMgLSBwcm92aWRlIHNvZnR3YXJlIGVtdWxhdGVkIHZNQ0Ugc3VwcG9ydCB0
byBndWVzdAorICoKKyAqIENvcHlyaWdodCAoQykgMjAxMCwgMjAxMSBKaWFuZywgWXVuaG9uZyA8
eXVuaG9uZy5qaWFuZ0BpbnRlbC5jb20+CisgKiBDb3B5cmlnaHQgKEMpIDIwMTIsIDIwMTMgTGl1
LCBKaW5zb25nIDxqaW5zb25nLmxpdUBpbnRlbC5jb20+CisgKgorICogVGhpcyBwcm9ncmFtIGlz
IGZyZWUgc29mdHdhcmU7IHlvdSBjYW4gcmVkaXN0cmlidXRlIGl0IGFuZC9vciBtb2RpZnkKKyAq
IGl0IHVuZGVyIHRoZSB0ZXJtcyBvZiB0aGUgR05VIEdlbmVyYWwgUHVibGljIExpY2Vuc2UgYXMg
cHVibGlzaGVkIGJ5CisgKiB0aGUgRnJlZSBTb2Z0d2FyZSBGb3VuZGF0aW9uOyBlaXRoZXIgdmVy
c2lvbiAyIG9mIHRoZSBMaWNlbnNlLCBvcgorICogKGF0IHlvdXIgb3B0aW9uKSBhbnkgbGF0ZXIg
dmVyc2lvbi4KKyAqCisgKiBUaGlzIHByb2dyYW0gaXMgZGlzdHJpYnV0ZWQgaW4gdGhlIGhvcGUg
dGhhdCBpdCB3aWxsIGJlIHVzZWZ1bCwKKyAqIGJ1dCBXSVRIT1VUIEFOWSBXQVJSQU5UWTsgd2l0
aG91dCBldmVuIHRoZSBpbXBsaWVkIHdhcnJhbnR5IG9mCisgKiBNRVJDSEFOVEFCSUxJVFkgb3Ig
RklUTkVTUyBGT1IgQSBQQVJUSUNVTEFSIFBVUlBPU0UuICBTZWUgdGhlCisgKiBHTlUgR2VuZXJh
bCBQdWJsaWMgTGljZW5zZSBmb3IgbW9yZSBkZXRhaWxzLgorICoKKyAqIFlvdSBzaG91bGQgaGF2
ZSByZWNlaXZlZCBhIGNvcHkgb2YgdGhlIEdOVSBHZW5lcmFsIFB1YmxpYyBMaWNlbnNlCisgKiBh
bG9uZyB3aXRoIHRoaXMgcHJvZ3JhbTsgaWYgbm90LCB3cml0ZSB0byB0aGUgRnJlZSBTb2Z0d2Fy
ZQorICogRm91bmRhdGlvbiwgSW5jLiwgNTkgVGVtcGxlIFBsYWNlLCBTdWl0ZSAzMzAsIEJvc3Rv
biwgTUEgIDAyMTExLTEzMDcgIFVTQQogICovCiAKICNpbmNsdWRlIDx4ZW4vaW5pdC5oPgpAQCAt
MTksNjcgKzM2LDU1IEBACiAjaW5jbHVkZSAibWNlLmgiCiAjaW5jbHVkZSAieDg2X21jYS5oIgog
Ci0vKgotICogRW11bGF0ZSAyIGJhbmtzIGZvciBndWVzdAotICogQmFuazA6IHJlc2VydmVkIGZv
ciAnYmFuazAgcXVpcmsnIG9jY3VyIGF0IHNvbWUgdmVyeSBvbGQgcHJvY2Vzc29yczoKLSAqICAg
MSkuIEludGVsIGNwdSB3aG9zZSBmYW1pbHktbW9kZWwgdmFsdWUgPCAwNi0xQTsKLSAqICAgMiku
IEFNRCBLNwotICogQmFuazE6IHVzZWQgdG8gdHJhbnNmZXIgZXJyb3IgaW5mbyB0byBndWVzdAot
ICovCi0jZGVmaW5lIEdVRVNUX0JBTktfTlVNIDIKLSNkZWZpbmUgR1VFU1RfTUNHX0NBUCAoTUNH
X1RFU19QIHwgTUNHX1NFUl9QIHwgR1VFU1RfQkFOS19OVU0pCi0KLSNkZWZpbmUgZG9tX3ZtY2Uo
eCkgICAoKHgpLT5hcmNoLnZtY2FfbXNycykKLQotaW50IHZtY2VfaW5pdF9tc3Ioc3RydWN0IGRv
bWFpbiAqZCkKLXsKLSAgICBkb21fdm1jZShkKSA9IHhtYWxsb2Moc3RydWN0IGRvbWFpbl9tY2Ff
bXNycyk7Ci0gICAgaWYgKCAhZG9tX3ZtY2UoZCkgKQotICAgICAgICByZXR1cm4gLUVOT01FTTsK
LQotICAgIGRvbV92bWNlKGQpLT5tY2dfc3RhdHVzID0gMHgwOwotICAgIGRvbV92bWNlKGQpLT5u
cl9pbmplY3Rpb24gPSAwOwotCi0gICAgSU5JVF9MSVNUX0hFQUQoJmRvbV92bWNlKGQpLT5pbXBh
Y3RfaGVhZGVyKTsKLSAgICBzcGluX2xvY2tfaW5pdCgmZG9tX3ZtY2UoZCktPmxvY2spOwotCi0g
ICAgcmV0dXJuIDA7Ci19Ci0KLXZvaWQgdm1jZV9kZXN0cm95X21zcihzdHJ1Y3QgZG9tYWluICpk
KQotewotICAgIGlmICggIWRvbV92bWNlKGQpICkKLSAgICAgICAgcmV0dXJuOwotICAgIHhmcmVl
KGRvbV92bWNlKGQpKTsKLSAgICBkb21fdm1jZShkKSA9IE5VTEw7Ci19Ci0KIHZvaWQgdm1jZV9p
bml0X3ZjcHUoc3RydWN0IHZjcHUgKnYpCiB7Ci0gICAgdi0+YXJjaC5tY2dfY2FwID0gR1VFU1Rf
TUNHX0NBUDsKKyAgICBpbnQgaTsKKworICAgIC8qIGdsb2JhbCBNQ0EgTVNScyBpbml0ICovCisg
ICAgaWYgKCBib290X2NwdV9kYXRhLng4Nl92ZW5kb3IgPT0gWDg2X1ZFTkRPUl9JTlRFTCApCisg
ICAgICAgIHYtPmFyY2gudm1jZS5tY2dfY2FwID0gSU5URUxfR1VFU1RfTUNHX0NBUDsKKyAgICBl
bHNlCisgICAgICAgIHYtPmFyY2gudm1jZS5tY2dfY2FwID0gQU1EX0dVRVNUX01DR19DQVA7CisK
KyAgICB2LT5hcmNoLnZtY2UubWNnX3N0YXR1cyA9IDA7CisKKyAgICAvKiBwZXItYmFuayBNQ0Eg
TVNScyBpbml0ICovCisgICAgZm9yICggaSA9IDA7IGkgPCBHVUVTVF9NQ19CQU5LX05VTTsgaSsr
ICkKKyAgICAgICAgbWVtc2V0KCZ2LT5hcmNoLnZtY2UuYmFua1tpXSwgMCwgc2l6ZW9mKHN0cnVj
dCB2bWNlX2JhbmspKTsKKworICAgIHNwaW5fbG9ja19pbml0KCZ2LT5hcmNoLnZtY2UubG9jayk7
CiB9CiAKIGludCB2bWNlX3Jlc3RvcmVfdmNwdShzdHJ1Y3QgdmNwdSAqdiwgdWludDY0X3QgY2Fw
cykKIHsKLSAgICBpZiAoIGNhcHMgJiB+R1VFU1RfTUNHX0NBUCAmIH5NQ0dfQ0FQX0NPVU5UICYg
fk1DR19DVExfUCApCisgICAgdWludDY0X3QgZ3Vlc3RfbWNnX2NhcDsKKworICAgIGlmICggYm9v
dF9jcHVfZGF0YS54ODZfdmVuZG9yID09IFg4Nl9WRU5ET1JfSU5URUwgKQorICAgICAgICBndWVz
dF9tY2dfY2FwID0gSU5URUxfR1VFU1RfTUNHX0NBUDsKKyAgICBlbHNlCisgICAgICAgIGd1ZXN0
X21jZ19jYXAgPSBBTURfR1VFU1RfTUNHX0NBUDsKKworICAgIGlmICggY2FwcyAmIH5ndWVzdF9t
Y2dfY2FwICYgfk1DR19DQVBfQ09VTlQgJiB+TUNHX0NUTF9QICkKICAgICB7CiAgICAgICAgIGRw
cmludGsoWEVOTE9HX0dfRVJSLCAiJXMgcmVzdG9yZTogdW5zdXBwb3J0ZWQgTUNBIGNhcGFiaWxp
dGllcyIKICAgICAgICAgICAgICAgICAiICUjIiBQUkl4NjQgIiBmb3IgZCVkOnYldSAoc3VwcG9y
dGVkOiAlI0x4KVxuIiwKICAgICAgICAgICAgICAgICBpc19odm1fdmNwdSh2KSA/ICJIVk0iIDog
IlBWIiwgY2Fwcywgdi0+ZG9tYWluLT5kb21haW5faWQsCi0gICAgICAgICAgICAgICAgdi0+dmNw
dV9pZCwgR1VFU1RfTUNHX0NBUCAmIH5NQ0dfQ0FQX0NPVU5UKTsKKyAgICAgICAgICAgICAgICB2
LT52Y3B1X2lkLCBndWVzdF9tY2dfY2FwICYgfk1DR19DQVBfQ09VTlQpOwogICAgICAgICByZXR1
cm4gLUVQRVJNOwogICAgIH0KIAotICAgIHYtPmFyY2gubWNnX2NhcCA9IGNhcHM7CisgICAgdi0+
YXJjaC52bWNlLm1jZ19jYXAgPSBjYXBzOwogICAgIHJldHVybiAwOwogfQogCi1zdGF0aWMgaW50
IGJhbmtfbWNlX3JkbXNyKGNvbnN0IHN0cnVjdCB2Y3B1ICp2LCB1aW50MzJfdCBtc3IsIHVpbnQ2
NF90ICp2YWwpCisvKgorICogRm9yIGhpc3RvcmljIHZlcnNpb24gcmVhc29uLCBiYW5rIG51bWJl
ciBtYXkgZ3JlYXRlciB0aGFuIEdVRVNUX01DX0JBTktfTlVNLAorICogd2hlbiBtaWdyYXRpZSBm
cm9tIG9sZCB2TUNFIHZlcnNpb24gdG8gbmV3IHZNQ0UuCisgKi8KK3N0YXRpYyBpbnQgYmFua19t
Y2VfcmRtc3Ioc3RydWN0IHZjcHUgKnYsIHVpbnQzMl90IG1zciwgdWludDY0X3QgKnZhbCkKIHsK
ICAgICBpbnQgcmV0ID0gMTsKICAgICB1bnNpZ25lZCBpbnQgYmFuayA9IChtc3IgLSBNU1JfSUEz
Ml9NQzBfQ1RMKSAvIDQ7Ci0gICAgc3RydWN0IGRvbWFpbl9tY2FfbXNycyAqdm1jZSA9IGRvbV92
bWNlKHYtPmRvbWFpbik7Ci0gICAgc3RydWN0IGJhbmtfZW50cnkgKmVudHJ5OwogCiAgICAgKnZh
bCA9IDA7CiAKQEAgLTkyLDQ2ICs5NywzMyBAQAogICAgICAgICAgICAgICAgICAgIGJhbmssICp2
YWwpOwogICAgICAgICBicmVhazsKICAgICBjYXNlIE1TUl9JQTMyX01DMF9TVEFUVVM6Ci0gICAg
ICAgIC8qIE9ubHkgZXJyb3IgYmFuayBpcyByZWFkLiBOb24tZXJyb3IgYmFua3Mgc2ltcGx5IHJl
dHVybi4gKi8KLSAgICAgICAgaWYgKCAhbGlzdF9lbXB0eSgmdm1jZS0+aW1wYWN0X2hlYWRlcikg
KQorICAgICAgICBpZiAoIGJhbmsgPCBHVUVTVF9NQ19CQU5LX05VTSApCiAgICAgICAgIHsKLSAg
ICAgICAgICAgIGVudHJ5ID0gbGlzdF9lbnRyeSh2bWNlLT5pbXBhY3RfaGVhZGVyLm5leHQsCi0g
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgc3RydWN0IGJhbmtfZW50cnksIGxpc3QpOwot
ICAgICAgICAgICAgaWYgKCBlbnRyeS0+YmFuayA9PSBiYW5rICkKLSAgICAgICAgICAgIHsKLSAg
ICAgICAgICAgICAgICAqdmFsID0gZW50cnktPm1jaV9zdGF0dXM7CisgICAgICAgICAgICAqdmFs
ID0gdi0+YXJjaC52bWNlLmJhbmtbYmFua10ubWNpX3N0YXR1czsKKyAgICAgICAgICAgIGlmICgg
KnZhbCApCiAgICAgICAgICAgICAgICAgbWNlX3ByaW50ayhNQ0VfVkVSQk9TRSwKLSAgICAgICAg
ICAgICAgICAgICAgICAgICAgICJNQ0U6IHJkIE1DJXVfU1RBVFVTIGluIHZNQ0UjIGNvbnRleHQg
IgotICAgICAgICAgICAgICAgICAgICAgICAgICAgInZhbHVlIDB4JSJQUkl4NjQiXG4iLCBiYW5r
LCAqdmFsKTsKLSAgICAgICAgICAgIH0KKyAgICAgICAgICAgICAgICAgICAgICAgICAgICJNQ0U6
IHJkbXNyIE1DJXVfU1RBVFVTIGluIHZNQ0UjIGNvbnRleHQgIgorICAgICAgICAgICAgICAgICAg
ICAgICAgICAgIjB4JSJQUkl4NjQiXG4iLCBiYW5rLCAqdmFsKTsKICAgICAgICAgfQogICAgICAg
ICBicmVhazsKICAgICBjYXNlIE1TUl9JQTMyX01DMF9BRERSOgotICAgICAgICBpZiAoICFsaXN0
X2VtcHR5KCZ2bWNlLT5pbXBhY3RfaGVhZGVyKSApCisgICAgICAgIGlmICggYmFuayA8IEdVRVNU
X01DX0JBTktfTlVNICkKICAgICAgICAgewotICAgICAgICAgICAgZW50cnkgPSBsaXN0X2VudHJ5
KHZtY2UtPmltcGFjdF9oZWFkZXIubmV4dCwKLSAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICBzdHJ1Y3QgYmFua19lbnRyeSwgbGlzdCk7Ci0gICAgICAgICAgICBpZiAoIGVudHJ5LT5iYW5r
ID09IGJhbmsgKQotICAgICAgICAgICAgewotICAgICAgICAgICAgICAgICp2YWwgPSBlbnRyeS0+
bWNpX2FkZHI7CisgICAgICAgICAgICAqdmFsID0gdi0+YXJjaC52bWNlLmJhbmtbYmFua10ubWNp
X2FkZHI7CisgICAgICAgICAgICBpZiAoICp2YWwgKQogICAgICAgICAgICAgICAgIG1jZV9wcmlu
dGsoTUNFX1ZFUkJPU0UsCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAiTUNFOiByZG1zciBN
QyV1X0FERFIgaW4gdk1DRSMgY29udGV4dCAiCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAi
MHglIlBSSXg2NCJcbiIsIGJhbmssICp2YWwpOwotICAgICAgICAgICAgfQogICAgICAgICB9CiAg
ICAgICAgIGJyZWFrOwogICAgIGNhc2UgTVNSX0lBMzJfTUMwX01JU0M6Ci0gICAgICAgIGlmICgg
IWxpc3RfZW1wdHkoJnZtY2UtPmltcGFjdF9oZWFkZXIpICkKKyAgICAgICAgaWYgKCBiYW5rIDwg
R1VFU1RfTUNfQkFOS19OVU0gKQogICAgICAgICB7Ci0gICAgICAgICAgICBlbnRyeSA9IGxpc3Rf
ZW50cnkodm1jZS0+aW1wYWN0X2hlYWRlci5uZXh0LAotICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgIHN0cnVjdCBiYW5rX2VudHJ5LCBsaXN0KTsKLSAgICAgICAgICAgIGlmICggZW50cnkt
PmJhbmsgPT0gYmFuayApCi0gICAgICAgICAgICB7Ci0gICAgICAgICAgICAgICAgKnZhbCA9IGVu
dHJ5LT5tY2lfbWlzYzsKKyAgICAgICAgICAgICp2YWwgPSB2LT5hcmNoLnZtY2UuYmFua1tiYW5r
XS5tY2lfbWlzYzsKKyAgICAgICAgICAgIGlmICggKnZhbCApCiAgICAgICAgICAgICAgICAgbWNl
X3ByaW50ayhNQ0VfVkVSQk9TRSwKLSAgICAgICAgICAgICAgICAgICAgICAgICAgICJNQ0U6IHJk
IE1DJXVfTUlTQyBpbiB2TUNFIyBjb250ZXh0ICIKKyAgICAgICAgICAgICAgICAgICAgICAgICAg
ICJNQ0U6IHJkbXNyIE1DJXVfTUlTQyBpbiB2TUNFIyBjb250ZXh0ICIKICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICIweCUiUFJJeDY0IlxuIiwgYmFuaywgKnZhbCk7Ci0gICAgICAgICAgICB9
CiAgICAgICAgIH0KICAgICAgICAgYnJlYWs7CiAgICAgZGVmYXVsdDoKQEAgLTE1Nyw1NiArMTQ5
LDUwIEBACiAgKi8KIGludCB2bWNlX3JkbXNyKHVpbnQzMl90IG1zciwgdWludDY0X3QgKnZhbCkK
IHsKLSAgICBjb25zdCBzdHJ1Y3QgdmNwdSAqY3VyID0gY3VycmVudDsKLSAgICBzdHJ1Y3QgZG9t
YWluX21jYV9tc3JzICp2bWNlID0gZG9tX3ZtY2UoY3VyLT5kb21haW4pOworICAgIHN0cnVjdCB2
Y3B1ICpjdXIgPSBjdXJyZW50OwogICAgIGludCByZXQgPSAxOwogCiAgICAgKnZhbCA9IDA7CiAK
LSAgICBzcGluX2xvY2soJnZtY2UtPmxvY2spOworICAgIHNwaW5fbG9jaygmY3VyLT5hcmNoLnZt
Y2UubG9jayk7CiAKICAgICBzd2l0Y2ggKCBtc3IgKQogICAgIHsKICAgICBjYXNlIE1TUl9JQTMy
X01DR19TVEFUVVM6Ci0gICAgICAgICp2YWwgPSB2bWNlLT5tY2dfc3RhdHVzOworICAgICAgICAq
dmFsID0gY3VyLT5hcmNoLnZtY2UubWNnX3N0YXR1czsKICAgICAgICAgaWYgKCp2YWwpCiAgICAg
ICAgICAgICBtY2VfcHJpbnRrKE1DRV9WRVJCT1NFLAogICAgICAgICAgICAgICAgICAgICAgICAi
TUNFOiByZG1zciBNQ0dfU1RBVFVTIDB4JSJQUkl4NjQiXG4iLCAqdmFsKTsKICAgICAgICAgYnJl
YWs7CiAgICAgY2FzZSBNU1JfSUEzMl9NQ0dfQ0FQOgotICAgICAgICAqdmFsID0gY3VyLT5hcmNo
Lm1jZ19jYXA7Ci0gICAgICAgIG1jZV9wcmludGsoTUNFX1ZFUkJPU0UsICJNQ0U6IHJkbXNyIE1D
R19DQVAgMHglIlBSSXg2NCJcbiIsCi0gICAgICAgICAgICAgICAgICAgKnZhbCk7CisgICAgICAg
ICp2YWwgPSBjdXItPmFyY2gudm1jZS5tY2dfY2FwOworICAgICAgICBtY2VfcHJpbnRrKE1DRV9W
RVJCT1NFLCAiTUNFOiByZG1zciBNQ0dfQ0FQIDB4JSJQUkl4NjQiXG4iLCAqdmFsKTsKICAgICAg
ICAgYnJlYWs7CiAgICAgY2FzZSBNU1JfSUEzMl9NQ0dfQ1RMOgotICAgICAgICAvKiBTdGljayBh
bGwgMSdzIHdoZW4gQ1RMIHN1cHBvcnQsIGFuZCAwJ3Mgd2hlbiBubyBDVEwgc3VwcG9ydCAqLwot
ICAgICAgICBpZiAoIGN1ci0+YXJjaC5tY2dfY2FwICYgTUNHX0NUTF9QICkKLSAgICAgICAgICAg
ICp2YWwgPSB+MFVMTDsKLSAgICAgICAgbWNlX3ByaW50ayhNQ0VfVkVSQk9TRSwgIk1DRTogcmRt
c3IgTUNHX0NUTCAweCUiUFJJeDY0IlxuIiwgKnZhbCk7CisgICAgICAgIGlmICggY3VyLT5hcmNo
LnZtY2UubWNnX2NhcCAmIE1DR19DVExfUCApCisgICAgICAgIHsKKyAgICAgICAgICAgICp2YWwg
PSB+MFVMOworICAgICAgICAgICAgbWNlX3ByaW50ayhNQ0VfVkVSQk9TRSwgIk1DRTogcmRtc3Ig
TUNHX0NUTCAweCUiUFJJeDY0IlxuIiwgKnZhbCk7CisgICAgICAgIH0KICAgICAgICAgYnJlYWs7
CiAgICAgZGVmYXVsdDoKICAgICAgICAgcmV0ID0gbWNlX2JhbmtfbXNyKGN1ciwgbXNyKSA/IGJh
bmtfbWNlX3JkbXNyKGN1ciwgbXNyLCB2YWwpIDogMDsKICAgICAgICAgYnJlYWs7CiAgICAgfQog
Ci0gICAgc3Bpbl91bmxvY2soJnZtY2UtPmxvY2spOworICAgIHNwaW5fdW5sb2NrKCZjdXItPmFy
Y2gudm1jZS5sb2NrKTsKKwogICAgIHJldHVybiByZXQ7CiB9CiAKKy8qCisgKiBGb3IgaGlzdG9y
aWMgdmVyc2lvbiByZWFzb24sIGJhbmsgbnVtYmVyIG1heSBncmVhdGVyIHRoYW4gR1VFU1RfTUNf
QkFOS19OVU0sCisgKiB3aGVuIG1pZ3JhdGllIGZyb20gb2xkIHZNQ0UgdmVyc2lvbiB0byBuZXcg
dk1DRS4KKyAqLwogc3RhdGljIGludCBiYW5rX21jZV93cm1zcihzdHJ1Y3QgdmNwdSAqdiwgdTMy
IG1zciwgdTY0IHZhbCkKIHsKICAgICBpbnQgcmV0ID0gMTsKICAgICB1bnNpZ25lZCBpbnQgYmFu
ayA9IChtc3IgLSBNU1JfSUEzMl9NQzBfQ1RMKSAvIDQ7Ci0gICAgc3RydWN0IGRvbWFpbl9tY2Ff
bXNycyAqdm1jZSA9IGRvbV92bWNlKHYtPmRvbWFpbik7Ci0gICAgc3RydWN0IGJhbmtfZW50cnkg
KmVudHJ5ID0gTlVMTDsKLQotICAgIC8qIEdpdmUgdGhlIGZpcnN0IGVudHJ5IG9mIHRoZSBsaXN0
LCBpdCBjb3JyZXNwb25kcyB0byBjdXJyZW50Ci0gICAgICogdk1DRSMgaW5qZWN0aW9uLiBXaGVu
IHZNQ0UjIGlzIGZpbmlzaGVkIHByb2Nlc3NpbmcgYnkgdGhlCi0gICAgICogdGhlIGd1ZXN0LCB0
aGlzIG5vZGUgd2lsbCBiZSBkZWxldGVkLgotICAgICAqIE9ubHkgZXJyb3IgYmFuayBpcyB3cml0
dGVuLiBOb24tZXJyb3IgYmFua3Mgc2ltcGx5IHJldHVybi4KLSAgICAgKi8KLSAgICBpZiAoICFs
aXN0X2VtcHR5KCZ2bWNlLT5pbXBhY3RfaGVhZGVyKSApCi0gICAgICAgIGVudHJ5ID0gbGlzdF9l
bnRyeSh2bWNlLT5pbXBhY3RfaGVhZGVyLm5leHQsIHN0cnVjdCBiYW5rX2VudHJ5LCBsaXN0KTsK
IAogICAgIHN3aXRjaCAoIG1zciAmIChNU1JfSUEzMl9NQzBfQ1RMIHwgMykgKQogICAgIHsKQEAg
LTIxNyw1MCArMjAzLDQ2IEBACiAgICAgICAgICAqLwogICAgICAgICBicmVhazsKICAgICBjYXNl
IE1TUl9JQTMyX01DMF9TVEFUVVM6Ci0gICAgICAgIGlmICggZW50cnkgJiYgKGVudHJ5LT5iYW5r
ID09IGJhbmspICkKKyAgICAgICAgaWYgKCB2YWwgKQogICAgICAgICB7Ci0gICAgICAgICAgICBl
bnRyeS0+bWNpX3N0YXR1cyA9IHZhbDsKLSAgICAgICAgICAgIG1jZV9wcmludGsoTUNFX1ZFUkJP
U0UsCi0gICAgICAgICAgICAgICAgICAgICAgICJNQ0U6IHdyIE1DJXVfU1RBVFVTICUiUFJJeDY0
IiBpbiB2TUNFI1xuIiwKKyAgICAgICAgICAgIG1jZV9wcmludGsoTUNFX1FVSUVULAorICAgICAg
ICAgICAgICAgICAgICAgICAiTUNFOiB3ciBNQyV1X1NUQVRVUyB3LyBub24temVybyBjYXVzZSAj
R1BcbiIsIGJhbmspOworICAgICAgICAgICAgcmV0ID0gLTE7CisgICAgICAgIH0KKyAgICAgICAg
aWYgKCBiYW5rIDwgR1VFU1RfTUNfQkFOS19OVU0gKQorICAgICAgICB7CisgICAgICAgICAgICB2
LT5hcmNoLnZtY2UuYmFua1tiYW5rXS5tY2lfc3RhdHVzID0gdmFsOworICAgICAgICAgICAgbWNl
X3ByaW50ayhNQ0VfVkVSQk9TRSwgIk1DRTogd3IgTUMldV9TVEFUVVMgJSJQUkl4NjQiXG4iLAog
ICAgICAgICAgICAgICAgICAgICAgICBiYW5rLCB2YWwpOwogICAgICAgICB9Ci0gICAgICAgIGVs
c2UKLSAgICAgICAgICAgIG1jZV9wcmludGsoTUNFX1ZFUkJPU0UsCi0gICAgICAgICAgICAgICAg
ICAgICAgICJNQ0U6IHdyIE1DJXVfU1RBVFVTICUiUFJJeDY0IlxuIiwgYmFuaywgdmFsKTsKICAg
ICAgICAgYnJlYWs7CiAgICAgY2FzZSBNU1JfSUEzMl9NQzBfQUREUjoKLSAgICAgICAgaWYgKCAh
fnZhbCApCisgICAgICAgIGlmICggdmFsICkKICAgICAgICAgewogICAgICAgICAgICAgbWNlX3By
aW50ayhNQ0VfUVVJRVQsCi0gICAgICAgICAgICAgICAgICAgICAgICJNQ0U6IHdyIE1DJXVfQURE
UiB3aXRoIGFsbCAxcyB3aWxsIGNhdXNlICNHUFxuIiwgYmFuayk7CisgICAgICAgICAgICAgICAg
ICAgICAgICJNQ0U6IHdyIE1DJXVfQUREUiB3LyBub24temVybyBjYXVzZSAjR1BcbiIsIGJhbmsp
OwogICAgICAgICAgICAgcmV0ID0gLTE7CiAgICAgICAgIH0KLSAgICAgICAgZWxzZSBpZiAoIGVu
dHJ5ICYmIChlbnRyeS0+YmFuayA9PSBiYW5rKSApCisgICAgICAgIGVsc2UgaWYgKCBiYW5rIDwg
R1VFU1RfTUNfQkFOS19OVU0gKQogICAgICAgICB7Ci0gICAgICAgICAgICBlbnRyeS0+bWNpX2Fk
ZHIgPSB2YWw7Ci0gICAgICAgICAgICBtY2VfcHJpbnRrKE1DRV9WRVJCT1NFLAotICAgICAgICAg
ICAgICAgICAgICAgICAiTUNFOiB3ciBNQyV1X0FERFIgJSJQUkl4NjQiIGluIHZNQ0UjXG4iLCBi
YW5rLCB2YWwpOwotICAgICAgICB9Ci0gICAgICAgIGVsc2UKKyAgICAgICAgICAgIHYtPmFyY2gu
dm1jZS5iYW5rW2JhbmtdLm1jaV9hZGRyID0gdmFsOwogICAgICAgICAgICAgbWNlX3ByaW50ayhN
Q0VfVkVSQk9TRSwKICAgICAgICAgICAgICAgICAgICAgICAgIk1DRTogd3IgTUMldV9BRERSICUi
UFJJeDY0IlxuIiwgYmFuaywgdmFsKTsKKyAgICAgICAgfQogICAgICAgICBicmVhazsKICAgICBj
YXNlIE1TUl9JQTMyX01DMF9NSVNDOgotICAgICAgICBpZiAoICF+dmFsICkKKyAgICAgICAgaWYg
KCB2YWwgKQogICAgICAgICB7CiAgICAgICAgICAgICBtY2VfcHJpbnRrKE1DRV9RVUlFVCwKLSAg
ICAgICAgICAgICAgICAgICAgICAgIk1DRTogd3IgTUMldV9NSVNDIHdpdGggYWxsIDFzIHdpbGwg
Y2F1c2UgI0dQXG4iLCBiYW5rKTsKKyAgICAgICAgICAgICAgICAgICAgICAgIk1DRTogd3IgTUMl
dV9NSVNDIHcvIG5vbi16ZXJvIGNhdXNlICNHUFxuIiwgYmFuayk7CiAgICAgICAgICAgICByZXQg
PSAtMTsKICAgICAgICAgfQotICAgICAgICBlbHNlIGlmICggZW50cnkgJiYgKGVudHJ5LT5iYW5r
ID09IGJhbmspICkKKyAgICAgICAgZWxzZSBpZiAoIGJhbmsgPCBHVUVTVF9NQ19CQU5LX05VTSAp
CiAgICAgICAgIHsKLSAgICAgICAgICAgIGVudHJ5LT5tY2lfbWlzYyA9IHZhbDsKLSAgICAgICAg
ICAgIG1jZV9wcmludGsoTUNFX1ZFUkJPU0UsCi0gICAgICAgICAgICAgICAgICAgICAgICJNQ0U6
IHdyIE1DJXVfTUlTQyAlIlBSSXg2NCIgaW4gdk1DRSNcbiIsIGJhbmssIHZhbCk7Ci0gICAgICAg
IH0KLSAgICAgICAgZWxzZQorICAgICAgICAgICAgdi0+YXJjaC52bWNlLmJhbmtbYmFua10ubWNp
X21pc2MgPSB2YWw7CiAgICAgICAgICAgICBtY2VfcHJpbnRrKE1DRV9WRVJCT1NFLAogICAgICAg
ICAgICAgICAgICAgICAgICAiTUNFOiB3ciBNQyV1X01JU0MgJSJQUkl4NjQiXG4iLCBiYW5rLCB2
YWwpOworICAgICAgICB9CiAgICAgICAgIGJyZWFrOwogICAgIGRlZmF1bHQ6CiAgICAgICAgIHN3
aXRjaCAoIGJvb3RfY3B1X2RhdGEueDg2X3ZlbmRvciApCkBAIC0yODYsNTIgKzI2OCwzMyBAQAog
aW50IHZtY2Vfd3Jtc3IodTMyIG1zciwgdTY0IHZhbCkKIHsKICAgICBzdHJ1Y3QgdmNwdSAqY3Vy
ID0gY3VycmVudDsKLSAgICBzdHJ1Y3QgYmFua19lbnRyeSAqZW50cnkgPSBOVUxMOwotICAgIHN0
cnVjdCBkb21haW5fbWNhX21zcnMgKnZtY2UgPSBkb21fdm1jZShjdXItPmRvbWFpbik7CiAgICAg
aW50IHJldCA9IDE7CiAKLSAgICBzcGluX2xvY2soJnZtY2UtPmxvY2spOworICAgIHNwaW5fbG9j
aygmY3VyLT5hcmNoLnZtY2UubG9jayk7CiAKICAgICBzd2l0Y2ggKCBtc3IgKQogICAgIHsKICAg
ICBjYXNlIE1TUl9JQTMyX01DR19DVEw6CisgICAgICAgIC8qIElmIE1DR19DVEwgZXhpc3QgdGhl
biBzdGljayB0byBhbGwgMSdzLiBJZiBub3QgZXhpc3QgdGhlbiBpZ25vcmUgKi8KICAgICAgICAg
YnJlYWs7CiAgICAgY2FzZSBNU1JfSUEzMl9NQ0dfU1RBVFVTOgotICAgICAgICB2bWNlLT5tY2df
c3RhdHVzID0gdmFsOworICAgICAgICBjdXItPmFyY2gudm1jZS5tY2dfc3RhdHVzID0gdmFsOwog
ICAgICAgICBtY2VfcHJpbnRrKE1DRV9WRVJCT1NFLCAiTUNFOiB3cm1zciBNQ0dfU1RBVFVTICUi
UFJJeDY0IlxuIiwgdmFsKTsKLSAgICAgICAgLyogRm9yIEhWTSBndWVzdCwgdGhpcyBpcyB0aGUg
cG9pbnQgZm9yIGRlbGV0aW5nIHZNQ0UgaW5qZWN0aW9uIG5vZGUgKi8KLSAgICAgICAgaWYgKCBp
c19odm1fdmNwdShjdXIpICYmICh2bWNlLT5ucl9pbmplY3Rpb24gPiAwKSApCi0gICAgICAgIHsK
LSAgICAgICAgICAgIHZtY2UtPm5yX2luamVjdGlvbi0tOyAvKiBTaG91bGQgYmUgMCAqLwotICAg
ICAgICAgICAgaWYgKCAhbGlzdF9lbXB0eSgmdm1jZS0+aW1wYWN0X2hlYWRlcikgKQotICAgICAg
ICAgICAgewotICAgICAgICAgICAgICAgIGVudHJ5ID0gbGlzdF9lbnRyeSh2bWNlLT5pbXBhY3Rf
aGVhZGVyLm5leHQsCi0gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHN0cnVjdCBi
YW5rX2VudHJ5LCBsaXN0KTsKLSAgICAgICAgICAgICAgICBpZiAoIGVudHJ5LT5tY2lfc3RhdHVz
ICYgTUNpX1NUQVRVU19WQUwgKQotICAgICAgICAgICAgICAgICAgICBtY2VfcHJpbnRrKE1DRV9R
VUlFVCwgIk1DRTogTUNpX1NUQVRVUyBNU1Igc2hvdWxkIGhhdmUgIgotICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICJiZWVuIGNsZWFyZWQgYmVmb3JlIHdyaXRlIE1DR19TVEFUVVMgTVNS
XG4iKTsKLQotICAgICAgICAgICAgICAgIG1jZV9wcmludGsoTUNFX1FVSUVULCAiTUNFOiBEZWxl
dGUgSFZNIGxhc3QgaW5qZWN0aW9uICIKLSAgICAgICAgICAgICAgICAgICAgICAgICAgICJOb2Rl
LCBucl9pbmplY3Rpb24gJXVcbiIsCi0gICAgICAgICAgICAgICAgICAgICAgICAgICB2bWNlLT5u
cl9pbmplY3Rpb24pOwotICAgICAgICAgICAgICAgIGxpc3RfZGVsKCZlbnRyeS0+bGlzdCk7Ci0g
ICAgICAgICAgICAgICAgeGZyZWUoZW50cnkpOwotICAgICAgICAgICAgfQotICAgICAgICAgICAg
ZWxzZQotICAgICAgICAgICAgICAgIG1jZV9wcmludGsoTUNFX1FVSUVULCAiTUNFOiBOb3QgZm91
bmQgSFZNIGd1ZXN0IgotICAgICAgICAgICAgICAgICAgICAgICAgICAgIiBsYXN0IGluamVjdGlv
biBOb2RlLCBzb21ldGhpbmcgV3JvbmchXG4iKTsKLSAgICAgICAgfQogICAgICAgICBicmVhazsK
ICAgICBjYXNlIE1TUl9JQTMyX01DR19DQVA6Ci0gICAgICAgIG1jZV9wcmludGsoTUNFX1FVSUVU
LCAiTUNFOiBNQ0dfQ0FQIGlzIHJlYWQtb25seVxuIik7Ci0gICAgICAgIHJldCA9IC0xOworICAg
ICAgICAvKgorICAgICAgICAgKiBBY2NvcmRpbmcgdG8gSW50ZWwgU0RNLCBJQTMyX01DR19DQVAg
aXMgYSByZWFkLW9ubHkgcmVnaXN0ZXIsCisgICAgICAgICAqIHRoZSBlZmZlY3Qgb2Ygd3JpdGlu
ZyB0byB0aGUgSUEzMl9NQ0dfQ0FQIGlzIHVuZGVmaW5lZC4gSGVyZSB3ZQorICAgICAgICAgKiB0
cmVhdCB3cml0aW5nIGFzICd3cml0ZSBub3QgY2hhbmdlJy4gR3Vlc3Qgd291bGQgbm90IHN1cnBy
aXNlLgorICAgICAgICAgKi8KKyAgICAgICAgbWNlX3ByaW50ayhNQ0VfUVVJRVQsICJNQ0U6IE1D
R19DQVAgaXMgcmVhZCBvbmx5IGFuZCB3cml0ZSBub3QgY2hhbmdlXG4iKTsKICAgICAgICAgYnJl
YWs7CiAgICAgZGVmYXVsdDoKICAgICAgICAgcmV0ID0gbWNlX2JhbmtfbXNyKGN1ciwgbXNyKSA/
IGJhbmtfbWNlX3dybXNyKGN1ciwgbXNyLCB2YWwpIDogMDsKICAgICAgICAgYnJlYWs7CiAgICAg
fQogCi0gICAgc3Bpbl91bmxvY2soJnZtY2UtPmxvY2spOworICAgIHNwaW5fdW5sb2NrKCZjdXIt
PmFyY2gudm1jZS5sb2NrKTsKICAgICByZXR1cm4gcmV0OwogfQogCkBAIC0zNDIsNyArMzA1LDcg
QEAKIAogICAgIGZvcl9lYWNoX3ZjcHUoIGQsIHYgKSB7CiAgICAgICAgIHN0cnVjdCBodm1fdm1j
ZV92Y3B1IGN0eHQgPSB7Ci0gICAgICAgICAgICAuY2FwcyA9IHYtPmFyY2gubWNnX2NhcAorICAg
ICAgICAgICAgLmNhcHMgPSB2LT5hcmNoLnZtY2UubWNnX2NhcAogICAgICAgICB9OwogCiAgICAg
ICAgIGVyciA9IGh2bV9zYXZlX2VudHJ5KFZNQ0VfVkNQVSwgdi0+dmNwdV9pZCwgaCwgJmN0eHQp
OwpAQCAtNDIyLDkzICszODUsMzggQEAKICAgICByZXR1cm4gMDsKIH0KIAotLyogVGhpcyBub2Rl
IGxpc3QgcmVjb3JkcyBlcnJvcnMgaW1wYWN0aW5nIGEgZG9tYWluLiB3aGVuIG9uZQotICogTUNF
IyBoYXBwZW5zLCBvbmUgZXJyb3IgYmFuayBpbXBhY3RzIGEgZG9tYWluLiBUaGlzIGVycm9yIG5v
ZGUKLSAqIHdpbGwgYmUgaW5zZXJ0ZWQgdG8gdGhlIHRhaWwgb2YgdGhlIHBlcl9kb20gZGF0YSBm
b3Igdk1DRSMgTVNSCi0gKiB2aXJ0dWFsaXphdGlvbi4gV2hlbiBvbmUgdk1DRSMgaW5qZWN0aW9u
IGlzIGZpbmlzaGVkIHByb2Nlc3NpbmcKLSAqIHByb2Nlc3NlZCBieSBndWVzdCwgdGhlIGNvcnJl
c3BvbmRpbmcgbm9kZSB3aWxsIGJlIGRlbGV0ZWQuCi0gKiBUaGlzIG5vZGUgbGlzdCBpcyBmb3Ig
R1VFU1Qgdk1DRSMgTVNSUyB2aXJ0dWFsaXphdGlvbi4KLSAqLwotc3RhdGljIHN0cnVjdCBiYW5r
X2VudHJ5KiBhbGxvY19iYW5rX2VudHJ5KHZvaWQpCitpbnQgZmlsbF92bXNyX2RhdGEoc3RydWN0
IG1jaW5mb19iYW5rICptY19iYW5rLCBzdHJ1Y3QgZG9tYWluICpkLAorICAgICAgICAgICAgICAg
ICAgIHVpbnQ2NF90IGdzdGF0dXMpCiB7Ci0gICAgc3RydWN0IGJhbmtfZW50cnkgKmVudHJ5Owor
ICAgIHN0cnVjdCB2Y3B1ICp2ID0gZC0+dmNwdVswXTsKIAotICAgIGVudHJ5ID0geHphbGxvYyhz
dHJ1Y3QgYmFua19lbnRyeSk7Ci0gICAgaWYgKCBlbnRyeSA9PSBOVUxMICkKLSAgICB7Ci0gICAg
ICAgIHByaW50ayhLRVJOX0VSUiAiTUNFOiBtYWxsb2MgYmFua19lbnRyeSBmYWlsZWRcbiIpOwot
ICAgICAgICByZXR1cm4gTlVMTDsKLSAgICB9Ci0KLSAgICBJTklUX0xJU1RfSEVBRCgmZW50cnkt
Pmxpc3QpOwotICAgIHJldHVybiBlbnRyeTsKLX0KLQotLyogRmlsbCBlcnJvciBiYW5rIGluZm8g
Zm9yICN2TUNFIGluamVjdGlvbiBhbmQgR1VFU1Qgdk1DRSMKLSAqIE1TUiB2aXJ0dWFsaXphdGlv
biBkYXRhCi0gKiAxKSBMb2cgZG93biBob3cgbWFueSBucl9pbmplY3Rpb25zIG9mIHRoZSBpbXBh
Y3RlZC4KLSAqIDIpIENvcHkgTUNFIyBlcnJvciBiYW5rIHRvIGltcGFjdGVkIERPTSBub2RlIGxp
c3QsCi0gKiAgICBmb3Igdk1DRSMgTVNScyB2aXJ0dWFsaXphdGlvbgotICovCi1pbnQgZmlsbF92
bXNyX2RhdGEoc3RydWN0IG1jaW5mb19iYW5rICptY19iYW5rLCBzdHJ1Y3QgZG9tYWluICpkLAot
ICAgICAgICAgICAgICAgICAgIHVpbnQ2NF90IGdzdGF0dXMpIHsKLSAgICBzdHJ1Y3QgYmFua19l
bnRyeSAqZW50cnk7Ci0KLSAgICAvKiBUaGlzIGVycm9yIGJhbmsgaW1wYWN0cyBvbmUgZG9tYWlu
LCB3ZSBuZWVkIHRvIGZpbGwgZG9tYWluIHJlbGF0ZWQKLSAgICAgKiBkYXRhIGZvciB2TUNFIE1T
UnMgdmlydHVhbGl6YXRpb24gYW5kIHZNQ0UjIGluamVjdGlvbiAqLwogICAgIGlmICggbWNfYmFu
ay0+bWNfZG9taWQgIT0gKHVpbnQxNl90KX4wICkKICAgICB7Ci0gICAgICAgIC8qIEZvciBIVk0g
Z3Vlc3QsIE9ubHkgd2hlbiBmaXJzdCB2TUNFIGlzIGNvbnN1bWVkIGJ5IEhWTSBndWVzdAotICAg
ICAgICAgKiBzdWNjZXNzZnVsbHksIHdpbGwgd2UgZ2VuZXJldGUgYW5vdGhlciBub2RlIGFuZCBp
bmplY3QgYW5vdGhlciB2TUNFLgotICAgICAgICAgKi8KLSAgICAgICAgaWYgKCBkLT5pc19odm0g
JiYgKGRvbV92bWNlKGQpLT5ucl9pbmplY3Rpb24gPiAwKSApCisgICAgICAgIGlmICggdi0+YXJj
aC52bWNlLm1jZ19zdGF0dXMgJiBNQ0dfU1RBVFVTX01DSVAgKQogICAgICAgICB7Ci0gICAgICAg
ICAgICBtY2VfcHJpbnRrKE1DRV9RVUlFVCwgIk1DRTogSFZNIGd1ZXN0IGhhcyBub3QgaGFuZGxl
ZCBwcmV2aW91cyIKKyAgICAgICAgICAgIG1jZV9wcmludGsoTUNFX1FVSUVULCAiTUNFOiBndWVz
dCBoYXMgbm90IGhhbmRsZWQgcHJldmlvdXMiCiAgICAgICAgICAgICAgICAgICAgICAgICIgdk1D
RSB5ZXQhXG4iKTsKICAgICAgICAgICAgIHJldHVybiAtMTsKICAgICAgICAgfQogCi0gICAgICAg
IGVudHJ5ID0gYWxsb2NfYmFua19lbnRyeSgpOwotICAgICAgICBpZiAoIGVudHJ5ID09IE5VTEwg
KQotICAgICAgICAgICAgcmV0dXJuIC0xOworICAgICAgICBzcGluX2xvY2soJnYtPmFyY2gudm1j
ZS5sb2NrKTsKIAotICAgICAgICBlbnRyeS0+bWNpX3N0YXR1cyA9IG1jX2JhbmstPm1jX3N0YXR1
czsKLSAgICAgICAgZW50cnktPm1jaV9hZGRyID0gbWNfYmFuay0+bWNfYWRkcjsKLSAgICAgICAg
ZW50cnktPm1jaV9taXNjID0gbWNfYmFuay0+bWNfbWlzYzsKLSAgICAgICAgZW50cnktPmJhbmsg
PSBtY19iYW5rLT5tY19iYW5rOworICAgICAgICB2LT5hcmNoLnZtY2UubWNnX3N0YXR1cyA9IGdz
dGF0dXM7CisgICAgICAgIC8qCisgICAgICAgICAqIDEuIFNraXAgYmFuayAwIHRvIGF2b2lkICdi
YW5rIDAgcXVpcmsnIG9mIG9sZCBwcm9jZXNzb3JzCisgICAgICAgICAqIDIuIEZpbHRlciBNQ2lf
U1RBVFVTIE1TQ09EIG1vZGVsIHNwZWNpZmljIGVycm9yIGNvZGUgdG8gZ3Vlc3QKKyAgICAgICAg
ICovCisgICAgICAgIHYtPmFyY2gudm1jZS5iYW5rWzFdLm1jaV9zdGF0dXMgPSBtY19iYW5rLT5t
Y19zdGF0dXMgJgorICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
IE1DaV9TVEFUVVNfTVNDT0RfTUFTSzsKKyAgICAgICAgdi0+YXJjaC52bWNlLmJhbmtbMV0ubWNp
X2FkZHIgPSBtY19iYW5rLT5tY19hZGRyOworICAgICAgICB2LT5hcmNoLnZtY2UuYmFua1sxXS5t
Y2lfbWlzYyA9IG1jX2JhbmstPm1jX21pc2M7CiAKLSAgICAgICAgc3Bpbl9sb2NrKCZkb21fdm1j
ZShkKS0+bG9jayk7Ci0gICAgICAgIC8qIE5ldyBlcnJvciBOb2RlLCBpbnNlcnQgdG8gdGhlIHRh
aWwgb2YgdGhlIHBlcl9kb20gZGF0YSAqLwotICAgICAgICBsaXN0X2FkZF90YWlsKCZlbnRyeS0+
bGlzdCwgJmRvbV92bWNlKGQpLT5pbXBhY3RfaGVhZGVyKTsKLSAgICAgICAgLyogRmlsbCBNU1Ig
Z2xvYmFsIHN0YXR1cyAqLwotICAgICAgICBkb21fdm1jZShkKS0+bWNnX3N0YXR1cyA9IGdzdGF0
dXM7Ci0gICAgICAgIC8qIE5ldyBub2RlIGltcGFjdCB0aGUgZG9tYWluLCBuZWVkIGFub3RoZXIg
dk1DRSMgaW5qZWN0aW9uKi8KLSAgICAgICAgZG9tX3ZtY2UoZCktPm5yX2luamVjdGlvbisrOwot
ICAgICAgICBzcGluX3VubG9jaygmZG9tX3ZtY2UoZCktPmxvY2spOwotCi0gICAgICAgIG1jZV9w
cmludGsoTUNFX1ZFUkJPU0UsIk1DRTogRm91bmQgZXJyb3IgQFtCQU5LJWQgIgotICAgICAgICAg
ICAgICAgICAgICJzdGF0dXMgJSJQUkl4NjQiIGFkZHIgJSJQUkl4NjQiIGRvbWlkICVkXVxuICIs
Ci0gICAgICAgICAgICAgICAgICAgbWNfYmFuay0+bWNfYmFuaywgbWNfYmFuay0+bWNfc3RhdHVz
LCBtY19iYW5rLT5tY19hZGRyLAotICAgICAgICAgICAgICAgICAgIG1jX2JhbmstPm1jX2RvbWlk
KTsKKyAgICAgICAgc3Bpbl91bmxvY2soJnYtPmFyY2gudm1jZS5sb2NrKTsKICAgICB9CiAKICAg
ICByZXR1cm4gMDsKIH0KIAotI2lmIDAgLyogY3VycmVudGx5IHVudXNlZCAqLwotaW50IHZtY2Vf
ZG9tYWluX2luamVjdCgKLSAgICBzdHJ1Y3QgbWNpbmZvX2JhbmsgKmJhbmssIHN0cnVjdCBkb21h
aW4gKmQsIHN0cnVjdCBtY2luZm9fZ2xvYmFsICpnbG9iYWwpCi17Ci0gICAgaW50IHJldDsKLQot
ICAgIHJldCA9IGZpbGxfdm1zcl9kYXRhKGJhbmssIGQsIGdsb2JhbC0+bWNfZ3N0YXR1cyk7Ci0g
ICAgaWYgKCByZXQgPCAwICkKLSAgICAgICAgcmV0dXJuIHJldDsKLQotICAgIHJldHVybiBpbmpl
Y3Rfdm1jZShkKTsKLX0KLSNlbmRpZgotCiBzdGF0aWMgaW50IGlzX2h2bV92bWNlX3JlYWR5KHN0
cnVjdCBtY2luZm9fYmFuayAqYmFuaywgc3RydWN0IGRvbWFpbiAqZCkKIHsKICAgICBzdHJ1Y3Qg
dmNwdSAqdjsKZGlmZiAtciBmYmQ5ZTg2NGMwNDcgeGVuL2FyY2gveDg2L2RvbWFpbi5jCi0tLSBh
L3hlbi9hcmNoL3g4Ni9kb21haW4uYwlNb24gU2VwIDE3IDE4OjAyOjU5IDIwMTIgKzA4MDAKKysr
IGIveGVuL2FyY2gveDg2L2RvbWFpbi5jCVR1ZSBTZXAgMTggMjI6Mzk6MTAgMjAxMiArMDgwMApA
QCAtNTcxLDkgKzU3MSw2IEBACiAKICAgICAgICAgaWYgKCAocmMgPSBpb21tdV9kb21haW5faW5p
dChkKSkgIT0gMCApCiAgICAgICAgICAgICBnb3RvIGZhaWw7Ci0KLSAgICAgICAgLyogRm9yIEd1
ZXN0IHZNQ0UgTVNScyB2aXJ0dWFsaXphdGlvbiAqLwotICAgICAgICB2bWNlX2luaXRfbXNyKGQp
OwogICAgIH0KIAogICAgIGlmICggaXNfaHZtX2RvbWFpbihkKSApCkBAIC02MDAsNyArNTk3LDYg
QEAKIAogIGZhaWw6CiAgICAgZC0+aXNfZHlpbmcgPSBET01EWUlOR19kZWFkOwotICAgIHZtY2Vf
ZGVzdHJveV9tc3IoZCk7CiAgICAgY2xlYW51cF9kb21haW5faXJxX21hcHBpbmcoZCk7CiAgICAg
ZnJlZV94ZW5oZWFwX3BhZ2UoZC0+c2hhcmVkX2luZm8pOwogICAgIGlmICggcGFnaW5nX2luaXRp
YWxpc2VkICkKQEAgLTYyMyw3ICs2MTksNiBAQAogICAgIGVsc2UKICAgICAgICAgeGZyZWUoZC0+
YXJjaC5wdl9kb21haW4uZTgyMCk7CiAKLSAgICB2bWNlX2Rlc3Ryb3lfbXNyKGQpOwogICAgIGZy
ZWVfZG9tYWluX3BpcnFzKGQpOwogICAgIGlmICggIWlzX2lkbGVfZG9tYWluKGQpICkKICAgICAg
ICAgaW9tbXVfZG9tYWluX2Rlc3Ryb3koZCk7CmRpZmYgLXIgZmJkOWU4NjRjMDQ3IHhlbi9hcmNo
L3g4Ni9kb21jdGwuYwotLS0gYS94ZW4vYXJjaC94ODYvZG9tY3RsLmMJTW9uIFNlcCAxNyAxODow
Mjo1OSAyMDEyICswODAwCisrKyBiL3hlbi9hcmNoL3g4Ni9kb21jdGwuYwlUdWUgU2VwIDE4IDIy
OjM5OjEwIDIwMTIgKzA4MDAKQEAgLTEwMjQsNyArMTAyNCw3IEBACiAgICAgICAgICAgICAgICAg
ZXZjLT5zeXNjYWxsMzJfY2FsbGJhY2tfZWlwICAgID0gMDsKICAgICAgICAgICAgICAgICBldmMt
PnN5c2NhbGwzMl9kaXNhYmxlc19ldmVudHMgPSAwOwogICAgICAgICAgICAgfQotICAgICAgICAg
ICAgZXZjLT5tY2dfY2FwID0gdi0+YXJjaC5tY2dfY2FwOworICAgICAgICAgICAgZXZjLT5tY2df
Y2FwID0gdi0+YXJjaC52bWNlLm1jZ19jYXA7CiAgICAgICAgIH0KICAgICAgICAgZWxzZQogICAg
ICAgICB7CmRpZmYgLXIgZmJkOWU4NjRjMDQ3IHhlbi9hcmNoL3g4Ni90cmFwcy5jCi0tLSBhL3hl
bi9hcmNoL3g4Ni90cmFwcy5jCU1vbiBTZXAgMTcgMTg6MDI6NTkgMjAxMiArMDgwMAorKysgYi94
ZW4vYXJjaC94ODYvdHJhcHMuYwlUdWUgU2VwIDE4IDIyOjM5OjEwIDIwMTIgKzA4MDAKQEAgLTMx
MzMsNTAgKzMxMzMsNiBAQAogICAgICAgICAgICAgICAgIGJyZWFrOwogICAgIEFTU0VSVCh0cmFw
IDw9IFZDUFVfVFJBUF9MQVNUKTsKIAotICAgIC8qIGluamVjdCB2TUNFIHRvIFBWX0d1ZXN0IGlu
Y2x1ZGluZyBET00wLiAqLwotICAgIGlmICggdHJhcCA9PSBWQ1BVX1RSQVBfTUNFICkKLSAgICB7
Ci0gICAgICAgIGdkcHJpbnRrKFhFTkxPR19ERUJVRywgIk1DRTogUmV0dXJuIGZyb20gdk1DRSMg
dHJhcCFcbiIpOwotICAgICAgICBpZiAoIGN1cnItPnZjcHVfaWQgPT0gMCApCi0gICAgICAgIHsK
LSAgICAgICAgICAgIHN0cnVjdCBkb21haW4gKmQgPSBjdXJyLT5kb21haW47Ci0KLSAgICAgICAg
ICAgIGlmICggIWQtPmFyY2gudm1jYV9tc3JzLT5ucl9pbmplY3Rpb24gKQotICAgICAgICAgICAg
ewotICAgICAgICAgICAgICAgIHByaW50ayhYRU5MT0dfV0FSTklORyAiTUNFOiByZXQgZnJvbSB2
TUNFIywgIgotICAgICAgICAgICAgICAgICAgICAgICAibm8gaW5qZWN0aW9uIG5vZGVcbiIpOwot
ICAgICAgICAgICAgICAgIGdvdG8gZW5kOwotICAgICAgICAgICAgfQotCi0gICAgICAgICAgICBk
LT5hcmNoLnZtY2FfbXNycy0+bnJfaW5qZWN0aW9uLS07Ci0gICAgICAgICAgICBpZiAoICFsaXN0
X2VtcHR5KCZkLT5hcmNoLnZtY2FfbXNycy0+aW1wYWN0X2hlYWRlcikgKQotICAgICAgICAgICAg
ewotICAgICAgICAgICAgICAgIHN0cnVjdCBiYW5rX2VudHJ5ICplbnRyeTsKLQotICAgICAgICAg
ICAgICAgIGVudHJ5ID0gbGlzdF9lbnRyeShkLT5hcmNoLnZtY2FfbXNycy0+aW1wYWN0X2hlYWRl
ci5uZXh0LAotICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBzdHJ1Y3QgYmFua19l
bnRyeSwgbGlzdCk7Ci0gICAgICAgICAgICAgICAgZ2RwcmludGsoWEVOTE9HX0RFQlVHLCAiTUNF
OiBkZWxldGUgbGFzdCBpbmplY3Rpb24gbm9kZVxuIik7Ci0gICAgICAgICAgICAgICAgbGlzdF9k
ZWwoJmVudHJ5LT5saXN0KTsKLSAgICAgICAgICAgIH0KLSAgICAgICAgICAgIGVsc2UKLSAgICAg
ICAgICAgICAgICBwcmludGsoWEVOTE9HX0VSUiAiTUNFOiBkaWRuJ3QgZm91bmQgbGFzdCBpbmpl
Y3Rpb24gbm9kZVxuIik7Ci0KLSAgICAgICAgICAgIC8qIGZ1cnRoZXIgaW5qZWN0aW9uICovCi0g
ICAgICAgICAgICBpZiAoIGQtPmFyY2gudm1jYV9tc3JzLT5ucl9pbmplY3Rpb24gPiAwICYmCi0g
ICAgICAgICAgICAgICAgIGd1ZXN0X2hhc190cmFwX2NhbGxiYWNrKGQsIDAsIFRSQVBfbWFjaGlu
ZV9jaGVjaykgJiYKLSAgICAgICAgICAgICAgICAgIXRlc3RfYW5kX3NldF9ib29sKGN1cnItPm1j
ZV9wZW5kaW5nKSApCi0gICAgICAgICAgICB7Ci0gICAgICAgICAgICAgICAgaW50IGNwdSA9IHNt
cF9wcm9jZXNzb3JfaWQoKTsKLQotICAgICAgICAgICAgICAgIGNwdW1hc2tfY29weShjdXJyLT5j
cHVfYWZmaW5pdHlfdG1wLCBjdXJyLT5jcHVfYWZmaW5pdHkpOwotICAgICAgICAgICAgICAgIHBy
aW50ayhYRU5MT0dfREVCVUcgIk1DRTogQ1BVJWQgc2V0IGFmZmluaXR5LCBvbGQgJWRcbiIsCi0g
ICAgICAgICAgICAgICAgICAgICAgIGNwdSwgY3Vyci0+cHJvY2Vzc29yKTsKLSAgICAgICAgICAg
ICAgICB2Y3B1X3NldF9hZmZpbml0eShjdXJyLCBjcHVtYXNrX29mKGNwdSkpOwotICAgICAgICAg
ICAgfQotICAgICAgICB9Ci0gICAgfQotCi1lbmQ6CiAgICAgLyogUmVzdG9yZSBwcmV2aW91cyBh
c3luY2hyb25vdXMgZXhjZXB0aW9uIG1hc2suICovCiAgICAgY3Vyci0+YXN5bmNfZXhjZXB0aW9u
X21hc2sgPSBjdXJyLT5hc3luY19leGNlcHRpb25fc3RhdGUodHJhcCkub2xkX21hc2s7CiB9CmRp
ZmYgLXIgZmJkOWU4NjRjMDQ3IHhlbi9pbmNsdWRlL2FzbS14ODYvZG9tYWluLmgKLS0tIGEveGVu
L2luY2x1ZGUvYXNtLXg4Ni9kb21haW4uaAlNb24gU2VwIDE3IDE4OjAyOjU5IDIwMTIgKzA4MDAK
KysrIGIveGVuL2luY2x1ZGUvYXNtLXg4Ni9kb21haW4uaAlUdWUgU2VwIDE4IDIyOjM5OjEwIDIw
MTIgKzA4MDAKQEAgLTI5Niw5ICsyOTYsNiBAQAogCiAgICAgc3RydWN0IFBJVFN0YXRlIHZwaXQ7
CiAKLSAgICAvKiBGb3IgR3Vlc3Qgdk1DQSBoYW5kbGluZyAqLwotICAgIHN0cnVjdCBkb21haW5f
bWNhX21zcnMgKnZtY2FfbXNyczsKLQogICAgIC8qIFRTQyBtYW5hZ2VtZW50IChlbXVsYXRpb24s
IHB2LCBzY2FsaW5nLCBzdGF0cykgKi8KICAgICBpbnQgdHNjX21vZGU7ICAgICAgICAgICAgLyog
c2VlIGluY2x1ZGUvYXNtLXg4Ni90aW1lLmggKi8KICAgICBib29sX3QgdnRzYzsgICAgICAgICAg
ICAgLyogdHNjIGlzIGVtdWxhdGVkIChtYXkgY2hhbmdlIGFmdGVyIG1pZ3JhdGUpICovCkBAIC00
MzgsOCArNDM1LDggQEAKICAgICAgKiBhbmQgdGh1cyBzaG91bGQgYmUgc2F2ZWQvcmVzdG9yZWQu
ICovCiAgICAgYm9vbF90IG5vbmxhenlfeHN0YXRlX3VzZWQ7CiAKLSAgICB1aW50NjRfdCBtY2df
Y2FwOwotICAgIAorICAgIHN0cnVjdCB2bWNlIHZtY2U7CisKICAgICBzdHJ1Y3QgcGFnaW5nX3Zj
cHUgcGFnaW5nOwogCiAgICAgdWludDMyX3QgZ2Ric3hfdmNwdV9ldmVudDsKZGlmZiAtciBmYmQ5
ZTg2NGMwNDcgeGVuL2luY2x1ZGUvYXNtLXg4Ni9tY2UuaAotLS0gYS94ZW4vaW5jbHVkZS9hc20t
eDg2L21jZS5oCU1vbiBTZXAgMTcgMTg6MDI6NTkgMjAxMiArMDgwMAorKysgYi94ZW4vaW5jbHVk
ZS9hc20teDg2L21jZS5oCVR1ZSBTZXAgMTggMjI6Mzk6MTAgMjAxMiArMDgwMApAQCAtMywyOCAr
Myw1MCBAQAogI2lmbmRlZiBfWEVOX1g4Nl9NQ0VfSAogI2RlZmluZSBfWEVOX1g4Nl9NQ0VfSAog
Ci0vKiBUaGlzIGVudHJ5IGlzIGZvciByZWNvcmRpbmcgYmFuayBub2RlcyBmb3IgdGhlIGltcGFj
dGVkIGRvbWFpbiwKLSAqIHB1dCBpbnRvIGltcGFjdF9oZWFkZXIgbGlzdC4gKi8KLXN0cnVjdCBi
YW5rX2VudHJ5IHsKLSAgICBzdHJ1Y3QgbGlzdF9oZWFkIGxpc3Q7Ci0gICAgdWludDE2X3QgYmFu
azsKKy8qCisgKiBFbXVsYWx0ZSAyIGJhbmtzIGZvciBndWVzdAorICogQmFuazA6IHJlc2VydmVk
IGZvciAnYmFuazAgcXVpcmsnIG9jY3VyIGF0IHNvbWUgdmVyeSBvbGQgcHJvY2Vzc29yczoKKyAq
ICAgMSkuIEludGVsIGNwdSB3aG9zZSBmYW1pbHktbW9kZWwgdmFsdWUgPCAwNi0xQTsKKyAqICAg
MikuIEFNRCBLNworICogQmFuazE6IHVzZWQgdG8gdHJhbnNmZXIgZXJyb3IgaW5mbyB0byBndWVz
dAorICovCisjZGVmaW5lIEdVRVNUX01DX0JBTktfTlVNIDIKKworLyoKKyAqIE1DR19TRVJfUDog
IHNvZnR3YXJlIGVycm9yIHJlY292ZXJ5IHN1cHBvcnRlZAorICogTUNHX1RFU19QOiAgdG8gYXZv
aWQgTUNpX3N0YXR1cyBiaXQ1Njo1MyBtb2RlbCBzcGVjaWZpYworICogTUNHX0NNQ0lfUDogZXhw
b3NlIENNQ0kgY2FwYWJpbGl0eSBidXQgbmV2ZXIgcmVhbGx5IGluamVjdCBpdCB0byBndWVzdCwK
KyAqICAgICAgICAgICAgIGZvciBzYWtlIG9mIHBlcmZvcm1hbmNlIHNpbmNlIGd1ZXN0IG5vdCBw
b2xsaW5nIHBlcmlvZGljYWxseQorICovCisjZGVmaW5lIElOVEVMX0dVRVNUX01DR19DQVAgKE1D
R19TRVJfUCB8CVwKKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgTUNHX1RFU19QIHwJXAor
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBNQ0dfQ01DSV9QIHwJXAorICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICBHVUVTVF9NQ19CQU5LX05VTSkKKworI2RlZmluZSBBTURfR1VFU1Rf
TUNHX0NBUCAoTUNHX1NFUl9QIHwJCVwKKyAgICAgICAgICAgICAgICAgICAgICAgICAgIEdVRVNU
X01DX0JBTktfTlVNKQorCisvKiBGaWx0ZXIgTVNDT0QgbW9kZWwgc3BlY2lmaWMgZXJyb3IgY29k
ZSB0byBndWVzdCAqLworI2RlZmluZSBNQ2lfU1RBVFVTX01TQ09EX01BU0sgKH4oMHhmZmZmVUxM
IDw8IDE2KSkKKworLyogTm8gbWNpX2N0bCBzaW5jZSBpdCBzdGljayBhbGwgMSdzICovCitzdHJ1
Y3Qgdm1jZV9iYW5rIHsKICAgICB1aW50NjRfdCBtY2lfc3RhdHVzOwogICAgIHVpbnQ2NF90IG1j
aV9hZGRyOwogICAgIHVpbnQ2NF90IG1jaV9taXNjOworICAgIHVpbnQ2NF90IG1jaV9jdGwyOwog
fTsKIAotc3RydWN0IGRvbWFpbl9tY2FfbXNycwotewotICAgIC8qIEd1ZXN0IHNob3VsZCBub3Qg
Y2hhbmdlIGJlbG93IHZhbHVlcyBhZnRlciBET00gYm9vdCB1cCAqLworLyogTm8gbWNnX2N0bCBz
aW5jZSBpdCBub3QgZXhwb3NlIHRvIGd1ZXN0ICovCitzdHJ1Y3Qgdm1jZSB7CisgICAgdWludDY0
X3QgbWNnX2NhcDsKICAgICB1aW50NjRfdCBtY2dfc3RhdHVzOwotICAgIHVpbnQxNl90IG5yX2lu
amVjdGlvbjsKLSAgICBzdHJ1Y3QgbGlzdF9oZWFkIGltcGFjdF9oZWFkZXI7CisgICAgc3RydWN0
IHZtY2VfYmFuayBiYW5rW0dVRVNUX01DX0JBTktfTlVNXTsKKwogICAgIHNwaW5sb2NrX3QgbG9j
azsKIH07CiAKIC8qIEd1ZXN0IHZNQ0UgTVNScyB2aXJ0dWFsaXphdGlvbiAqLwotZXh0ZXJuIGlu
dCB2bWNlX2luaXRfbXNyKHN0cnVjdCBkb21haW4gKmQpOwotZXh0ZXJuIHZvaWQgdm1jZV9kZXN0
cm95X21zcihzdHJ1Y3QgZG9tYWluICpkKTsKIGV4dGVybiB2b2lkIHZtY2VfaW5pdF92Y3B1KHN0
cnVjdCB2Y3B1ICopOwogZXh0ZXJuIGludCB2bWNlX3Jlc3RvcmVfdmNwdShzdHJ1Y3QgdmNwdSAq
LCB1aW50NjRfdCBjYXBzKTsKIGV4dGVybiBpbnQgdm1jZV93cm1zcih1aW50MzJfdCBtc3IsIHVp
bnQ2NF90IHZhbCk7Cg==

--_002_DE8DF0795D48FD4CA783C40EC829233532F3E2SHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 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_DE8DF0795D48FD4CA783C40EC829233532F3E2SHSMSX101ccrcorpi_--


From xen-devel-bounces@lists.xen.org Tue Sep 18 13:12:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Sep 2012 13:12:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDxbH-000585-U0; Tue, 18 Sep 2012 13:12:27 +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 1TDxbF-00057v-DQ
	for xen-devel@lists.xensource.com; Tue, 18 Sep 2012 13:12:25 +0000
Received: from [85.158.143.99:8822] by server-3.bemta-4.messagelabs.com id
	7D/5B-08232-83378505; Tue, 18 Sep 2012 13:12:24 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1347973937!22632830!1
X-Originating-IP: [143.182.124.21]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMjEgPT4gMjAzODcx\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26483 invoked from network); 18 Sep 2012 13:12:18 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (143.182.124.21)
	by server-2.tower-216.messagelabs.com with SMTP;
	18 Sep 2012 13:12:18 -0000
Received: from azsmga002.ch.intel.com ([10.2.17.35])
	by azsmga101.ch.intel.com with ESMTP; 18 Sep 2012 06:12:16 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.80,442,1344236400"; d="scan'208";a="146301776"
Received: from fmsmsx104.amr.corp.intel.com ([10.19.9.35])
	by AZSMGA002.ch.intel.com with ESMTP; 18 Sep 2012 06:12:15 -0700
Received: from fmsmsx101.amr.corp.intel.com (10.19.9.52) by
	FMSMSX104.amr.corp.intel.com (10.19.9.35) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Tue, 18 Sep 2012 06:12:14 -0700
Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by
	FMSMSX101.amr.corp.intel.com (10.19.9.52) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Tue, 18 Sep 2012 06:12:14 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.239]) by
	SHSMSX102.ccr.corp.intel.com ([169.254.2.92]) with mapi id
	14.01.0355.002; Tue, 18 Sep 2012 21:12:12 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: Jan Beulich <JBeulich@suse.com>, "xen-devel@lists.xensource.com"
	<xen-devel@lists.xensource.com>
Thread-Topic: [PATCH 1/5] Xen/MCE: vMCE emulation
Thread-Index: Ac2VnzbyiO3Wwe1zTg+unZlXP7YDVQ==
Date: Tue, 18 Sep 2012 13:12:12 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC829233532F3E2@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_DE8DF0795D48FD4CA783C40EC829233532F3E2SHSMSX101ccrcorpi_"
MIME-Version: 1.0
Cc: "keir@xen.org" <keir@xen.org>,
	"Ian.Campbell@citrix.com" <Ian.Campbell@citrix.com>
Subject: [Xen-devel] [PATCH 1/5] Xen/MCE: vMCE emulation
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--_002_DE8DF0795D48FD4CA783C40EC829233532F3E2SHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Xen/MCE: vMCE emulation

This patch provides virtual MCE support to guest. It emulates a simple
and clean MCE MSRs interface to guest by faking caps to guest if needed
and masking caps if unnecessary:
1. Providing a well-defined MCG_CAP to guest, filter out un-necessary caps =
and provide only guest needed caps;
2. Disabling MCG_CTL to avoid model specific;
3. Sticking all 1's to MCi_CTL to guest to avoid model specific;
4. Enabling CMCI cap but never really inject to guest to prevent polling pe=
riodically;
5. Masking MSCOD field of MCi_STATUS to avoid model specific;
6. Keeping natural semantics by per-vcpu instead of per-domain variables;
7. Using bank1 and reserving bank0 to work around 'bank0 quirk' of some ver=
y old processors;
8. Cleaning some vMCE# injection logic which shared by Intel and AMD but us=
eless under new vMCE implement;
9. Keeping compatilbe w/ old xen version which has been backported to SLES1=
1 SP2, so that old vMCE would not blocked when migrate to new vMCE;

Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>

diff -r fbd9e864c047 xen/arch/x86/cpu/mcheck/mce.h
--- a/xen/arch/x86/cpu/mcheck/mce.h	Mon Sep 17 18:02:59 2012 +0800
+++ b/xen/arch/x86/cpu/mcheck/mce.h	Tue Sep 18 22:39:10 2012 +0800
@@ -168,13 +168,12 @@
 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
 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_MCx_CTL2(v->arch.mcg_cap & MCG_CAP_COUNT) )
+         msr < MSR_IA32_MCx_CTL2(v->arch.vmce.mcg_cap & MCG_CAP_COUNT) )
           return 1;
     return 0;
 }
@@ -182,7 +181,7 @@
 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(v->arch.mcg_cap & MCG_CAP_COUNT)) ||
+         msr < MSR_IA32_MCx_CTL(v->arch.vmce.mcg_cap & MCG_CAP_COUNT)) ||
          mce_vendor_bank_msr(v, msr) )
         return 1;
     return 0;
diff -r fbd9e864c047 xen/arch/x86/cpu/mcheck/mce_intel.c
--- a/xen/arch/x86/cpu/mcheck/mce_intel.c	Mon Sep 17 18:02:59 2012 +0800
+++ b/xen/arch/x86/cpu/mcheck/mce_intel.c	Tue Sep 18 22:39:10 2012 +0800
@@ -1300,14 +1300,15 @@
 /* intel specific MCA MSR */
 int intel_mce_wrmsr(struct vcpu *v, uint32_t msr, uint64_t val)
 {
+    unsigned int bank =3D msr - MSR_IA32_MC0_CTL2;
     int ret =3D 0;
=20
-    if ( msr >=3D MSR_IA32_MC0_CTL2 &&
-         msr < MSR_IA32_MCx_CTL2(v->arch.mcg_cap & MCG_CAP_COUNT) )
+    if ( bank < GUEST_MC_BANK_NUM )
     {
-        mce_printk(MCE_QUIET, "We have disabled CMCI capability, "
-                 "Guest should not write this MSR!\n");
-         ret =3D 1;
+        v->arch.vmce.bank[bank].mci_ctl2 =3D val;
+        mce_printk(MCE_VERBOSE, "MCE: wr MC%u_CTL2 %"PRIx64"\n",
+                   bank, val);
+        ret =3D 1;
     }
=20
     return ret;
@@ -1315,13 +1316,14 @@
=20
 int intel_mce_rdmsr(const struct vcpu *v, uint32_t msr, uint64_t *val)
 {
+    unsigned int bank =3D msr - MSR_IA32_MC0_CTL2;
     int ret =3D 0;
=20
-    if ( msr >=3D MSR_IA32_MC0_CTL2 &&
-         msr < MSR_IA32_MCx_CTL2(v->arch.mcg_cap & MCG_CAP_COUNT) )
+    if ( bank < GUEST_MC_BANK_NUM )
     {
-        mce_printk(MCE_QUIET, "We have disabled CMCI capability, "
-                 "Guest should not read this MSR!\n");
+        *val =3D v->arch.vmce.bank[bank].mci_ctl2;
+        mce_printk(MCE_VERBOSE, "MCE: rdmsr MC%u_CTL2 0x%"PRIx64"\n",
+                   bank, *val);
         ret =3D 1;
     }
=20
diff -r fbd9e864c047 xen/arch/x86/cpu/mcheck/vmce.c
--- a/xen/arch/x86/cpu/mcheck/vmce.c	Mon Sep 17 18:02:59 2012 +0800
+++ b/xen/arch/x86/cpu/mcheck/vmce.c	Tue Sep 18 22:39:10 2012 +0800
@@ -1,5 +1,22 @@
 /*
- * vmce.c - virtual MCE support
+ * vmce.c - provide software emulated vMCE support to guest
+ *
+ * Copyright (C) 2010, 2011 Jiang, Yunhong <yunhong.jiang@intel.com>
+ * Copyright (C) 2012, 2013 Liu, Jinsong <jinsong.liu@intel.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * 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  U=
SA
  */
=20
 #include <xen/init.h>
@@ -19,67 +36,55 @@
 #include "mce.h"
 #include "x86_mca.h"
=20
-/*
- * Emulate 2 banks for guest
- * Bank0: reserved for 'bank0 quirk' occur at some very old processors:
- *   1). Intel cpu whose family-model value < 06-1A;
- *   2). AMD K7
- * Bank1: used to transfer error info to guest
- */
-#define GUEST_BANK_NUM 2
-#define GUEST_MCG_CAP (MCG_TES_P | MCG_SER_P | GUEST_BANK_NUM)
-
-#define dom_vmce(x)   ((x)->arch.vmca_msrs)
-
-int vmce_init_msr(struct domain *d)
-{
-    dom_vmce(d) =3D xmalloc(struct domain_mca_msrs);
-    if ( !dom_vmce(d) )
-        return -ENOMEM;
-
-    dom_vmce(d)->mcg_status =3D 0x0;
-    dom_vmce(d)->nr_injection =3D 0;
-
-    INIT_LIST_HEAD(&dom_vmce(d)->impact_header);
-    spin_lock_init(&dom_vmce(d)->lock);
-
-    return 0;
-}
-
-void vmce_destroy_msr(struct domain *d)
-{
-    if ( !dom_vmce(d) )
-        return;
-    xfree(dom_vmce(d));
-    dom_vmce(d) =3D NULL;
-}
-
 void vmce_init_vcpu(struct vcpu *v)
 {
-    v->arch.mcg_cap =3D GUEST_MCG_CAP;
+    int i;
+
+    /* global MCA MSRs init */
+    if ( boot_cpu_data.x86_vendor =3D=3D X86_VENDOR_INTEL )
+        v->arch.vmce.mcg_cap =3D INTEL_GUEST_MCG_CAP;
+    else
+        v->arch.vmce.mcg_cap =3D AMD_GUEST_MCG_CAP;
+
+    v->arch.vmce.mcg_status =3D 0;
+
+    /* per-bank MCA MSRs init */
+    for ( i =3D 0; i < GUEST_MC_BANK_NUM; i++ )
+        memset(&v->arch.vmce.bank[i], 0, sizeof(struct vmce_bank));
+
+    spin_lock_init(&v->arch.vmce.lock);
 }
=20
 int vmce_restore_vcpu(struct vcpu *v, uint64_t caps)
 {
-    if ( caps & ~GUEST_MCG_CAP & ~MCG_CAP_COUNT & ~MCG_CTL_P )
+    uint64_t guest_mcg_cap;
+
+    if ( boot_cpu_data.x86_vendor =3D=3D X86_VENDOR_INTEL )
+        guest_mcg_cap =3D INTEL_GUEST_MCG_CAP;
+    else
+        guest_mcg_cap =3D AMD_GUEST_MCG_CAP;
+
+    if ( caps & ~guest_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, GUEST_MCG_CAP & ~MCG_CAP_COUNT);
+                v->vcpu_id, guest_mcg_cap & ~MCG_CAP_COUNT);
         return -EPERM;
     }
=20
-    v->arch.mcg_cap =3D caps;
+    v->arch.vmce.mcg_cap =3D caps;
     return 0;
 }
=20
-static int bank_mce_rdmsr(const struct vcpu *v, uint32_t msr, uint64_t *va=
l)
+/*
+ * For historic version reason, bank number may greater than GUEST_MC_BANK=
_NUM,
+ * when migratie from old vMCE version to new vMCE.
+ */
+static int bank_mce_rdmsr(struct vcpu *v, uint32_t msr, uint64_t *val)
 {
     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
     *val =3D 0;
=20
@@ -92,46 +97,33 @@
                    bank, *val);
         break;
     case MSR_IA32_MC0_STATUS:
-        /* Only error bank is read. Non-error banks simply return. */
-        if ( !list_empty(&vmce->impact_header) )
+        if ( bank < GUEST_MC_BANK_NUM )
         {
-            entry =3D list_entry(vmce->impact_header.next,
-                               struct bank_entry, list);
-            if ( entry->bank =3D=3D bank )
-            {
-                *val =3D entry->mci_status;
+            *val =3D v->arch.vmce.bank[bank].mci_status;
+            if ( *val )
                 mce_printk(MCE_VERBOSE,
-                           "MCE: rd MC%u_STATUS in vMCE# context "
-                           "value 0x%"PRIx64"\n", bank, *val);
-            }
+                           "MCE: rdmsr MC%u_STATUS in vMCE# context "
+                           "0x%"PRIx64"\n", bank, *val);
         }
         break;
     case MSR_IA32_MC0_ADDR:
-        if ( !list_empty(&vmce->impact_header) )
+        if ( bank < GUEST_MC_BANK_NUM )
         {
-            entry =3D list_entry(vmce->impact_header.next,
-                               struct bank_entry, list);
-            if ( entry->bank =3D=3D bank )
-            {
-                *val =3D entry->mci_addr;
+            *val =3D v->arch.vmce.bank[bank].mci_addr;
+            if ( *val )
                 mce_printk(MCE_VERBOSE,
                            "MCE: rdmsr MC%u_ADDR in vMCE# context "
                            "0x%"PRIx64"\n", bank, *val);
-            }
         }
         break;
     case MSR_IA32_MC0_MISC:
-        if ( !list_empty(&vmce->impact_header) )
+        if ( bank < GUEST_MC_BANK_NUM )
         {
-            entry =3D list_entry(vmce->impact_header.next,
-                               struct bank_entry, list);
-            if ( entry->bank =3D=3D bank )
-            {
-                *val =3D entry->mci_misc;
+            *val =3D v->arch.vmce.bank[bank].mci_misc;
+            if ( *val )
                 mce_printk(MCE_VERBOSE,
-                           "MCE: rd MC%u_MISC in vMCE# context "
+                           "MCE: rdmsr MC%u_MISC in vMCE# context "
                            "0x%"PRIx64"\n", bank, *val);
-            }
         }
         break;
     default:
@@ -157,56 +149,50 @@
  */
 int vmce_rdmsr(uint32_t msr, uint64_t *val)
 {
-    const struct vcpu *cur =3D current;
-    struct domain_mca_msrs *vmce =3D dom_vmce(cur->domain);
+    struct vcpu *cur =3D current;
     int ret =3D 1;
=20
     *val =3D 0;
=20
-    spin_lock(&vmce->lock);
+    spin_lock(&cur->arch.vmce.lock);
=20
     switch ( msr )
     {
     case MSR_IA32_MCG_STATUS:
-        *val =3D vmce->mcg_status;
+        *val =3D cur->arch.vmce.mcg_status;
         if (*val)
             mce_printk(MCE_VERBOSE,
                        "MCE: rdmsr MCG_STATUS 0x%"PRIx64"\n", *val);
         break;
     case MSR_IA32_MCG_CAP:
-        *val =3D cur->arch.mcg_cap;
-        mce_printk(MCE_VERBOSE, "MCE: rdmsr MCG_CAP 0x%"PRIx64"\n",
-                   *val);
+        *val =3D cur->arch.vmce.mcg_cap;
+        mce_printk(MCE_VERBOSE, "MCE: rdmsr MCG_CAP 0x%"PRIx64"\n", *val);
         break;
     case MSR_IA32_MCG_CTL:
-        /* Stick all 1's when CTL support, and 0's when no CTL support */
-        if ( cur->arch.mcg_cap & MCG_CTL_P )
-            *val =3D ~0ULL;
-        mce_printk(MCE_VERBOSE, "MCE: rdmsr MCG_CTL 0x%"PRIx64"\n", *val);
+        if ( cur->arch.vmce.mcg_cap & MCG_CTL_P )
+        {
+            *val =3D ~0UL;
+            mce_printk(MCE_VERBOSE, "MCE: rdmsr MCG_CTL 0x%"PRIx64"\n", *v=
al);
+        }
         break;
     default:
         ret =3D mce_bank_msr(cur, msr) ? bank_mce_rdmsr(cur, msr, val) : 0=
;
         break;
     }
=20
-    spin_unlock(&vmce->lock);
+    spin_unlock(&cur->arch.vmce.lock);
+
     return ret;
 }
=20
+/*
+ * For historic version reason, bank number may greater than GUEST_MC_BANK=
_NUM,
+ * when migratie from old vMCE version to new vMCE.
+ */
 static int bank_mce_wrmsr(struct vcpu *v, u32 msr, u64 val)
 {
     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;
-
-    /* Give the first entry of the list, it corresponds to current
-     * vMCE# injection. When vMCE# is finished processing by the
-     * the guest, this node will be deleted.
-     * Only error bank is written. Non-error banks simply return.
-     */
-    if ( !list_empty(&vmce->impact_header) )
-        entry =3D list_entry(vmce->impact_header.next, struct bank_entry, =
list);
=20
     switch ( msr & (MSR_IA32_MC0_CTL | 3) )
     {
@@ -217,50 +203,46 @@
          */
         break;
     case MSR_IA32_MC0_STATUS:
-        if ( entry && (entry->bank =3D=3D bank) )
+        if ( val )
         {
-            entry->mci_status =3D val;
-            mce_printk(MCE_VERBOSE,
-                       "MCE: wr MC%u_STATUS %"PRIx64" in vMCE#\n",
+            mce_printk(MCE_QUIET,
+                       "MCE: wr MC%u_STATUS w/ non-zero cause #GP\n", bank=
);
+            ret =3D -1;
+        }
+        if ( bank < GUEST_MC_BANK_NUM )
+        {
+            v->arch.vmce.bank[bank].mci_status =3D val;
+            mce_printk(MCE_VERBOSE, "MCE: wr MC%u_STATUS %"PRIx64"\n",
                        bank, val);
         }
-        else
-            mce_printk(MCE_VERBOSE,
-                       "MCE: wr MC%u_STATUS %"PRIx64"\n", bank, val);
         break;
     case MSR_IA32_MC0_ADDR:
-        if ( !~val )
+        if ( val )
         {
             mce_printk(MCE_QUIET,
-                       "MCE: wr MC%u_ADDR with all 1s will cause #GP\n", b=
ank);
+                       "MCE: wr MC%u_ADDR w/ non-zero cause #GP\n", bank);
             ret =3D -1;
         }
-        else if ( entry && (entry->bank =3D=3D bank) )
+        else if ( bank < GUEST_MC_BANK_NUM )
         {
-            entry->mci_addr =3D val;
-            mce_printk(MCE_VERBOSE,
-                       "MCE: wr MC%u_ADDR %"PRIx64" in vMCE#\n", bank, val=
);
-        }
-        else
+            v->arch.vmce.bank[bank].mci_addr =3D val;
             mce_printk(MCE_VERBOSE,
                        "MCE: wr MC%u_ADDR %"PRIx64"\n", bank, val);
+        }
         break;
     case MSR_IA32_MC0_MISC:
-        if ( !~val )
+        if ( val )
         {
             mce_printk(MCE_QUIET,
-                       "MCE: wr MC%u_MISC with all 1s will cause #GP\n", b=
ank);
+                       "MCE: wr MC%u_MISC w/ non-zero cause #GP\n", bank);
             ret =3D -1;
         }
-        else if ( entry && (entry->bank =3D=3D bank) )
+        else if ( bank < GUEST_MC_BANK_NUM )
         {
-            entry->mci_misc =3D val;
-            mce_printk(MCE_VERBOSE,
-                       "MCE: wr MC%u_MISC %"PRIx64" in vMCE#\n", bank, val=
);
-        }
-        else
+            v->arch.vmce.bank[bank].mci_misc =3D val;
             mce_printk(MCE_VERBOSE,
                        "MCE: wr MC%u_MISC %"PRIx64"\n", bank, val);
+        }
         break;
     default:
         switch ( boot_cpu_data.x86_vendor )
@@ -286,52 +268,33 @@
 int vmce_wrmsr(u32 msr, u64 val)
 {
     struct vcpu *cur =3D current;
-    struct bank_entry *entry =3D NULL;
-    struct domain_mca_msrs *vmce =3D dom_vmce(cur->domain);
     int ret =3D 1;
=20
-    spin_lock(&vmce->lock);
+    spin_lock(&cur->arch.vmce.lock);
=20
     switch ( msr )
     {
     case MSR_IA32_MCG_CTL:
+        /* If MCG_CTL exist then stick to all 1's. If not exist then ignor=
e */
         break;
     case MSR_IA32_MCG_STATUS:
-        vmce->mcg_status =3D val;
+        cur->arch.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 ( is_hvm_vcpu(cur) && (vmce->nr_injection > 0) )
-        {
-            vmce->nr_injection--; /* Should be 0 */
-            if ( !list_empty(&vmce->impact_header) )
-            {
-                entry =3D list_entry(vmce->impact_header.next,
-                                   struct bank_entry, list);
-                if ( entry->mci_status & MCi_STATUS_VAL )
-                    mce_printk(MCE_QUIET, "MCE: MCi_STATUS MSR should have=
 "
-                               "been cleared before write MCG_STATUS MSR\n=
");
-
-                mce_printk(MCE_QUIET, "MCE: Delete HVM last injection "
-                           "Node, nr_injection %u\n",
-                           vmce->nr_injection);
-                list_del(&entry->list);
-                xfree(entry);
-            }
-            else
-                mce_printk(MCE_QUIET, "MCE: Not found HVM guest"
-                           " last injection Node, something Wrong!\n");
-        }
         break;
     case MSR_IA32_MCG_CAP:
-        mce_printk(MCE_QUIET, "MCE: MCG_CAP is read-only\n");
-        ret =3D -1;
+        /*
+         * According to Intel SDM, IA32_MCG_CAP is a read-only register,
+         * the effect of writing to the IA32_MCG_CAP is undefined. Here we
+         * treat writing as 'write not change'. Guest would not surprise.
+         */
+        mce_printk(MCE_QUIET, "MCE: MCG_CAP is read only and write not cha=
nge\n");
         break;
     default:
         ret =3D mce_bank_msr(cur, msr) ? bank_mce_wrmsr(cur, msr, val) : 0=
;
         break;
     }
=20
-    spin_unlock(&vmce->lock);
+    spin_unlock(&cur->arch.vmce.lock);
     return ret;
 }
=20
@@ -342,7 +305,7 @@
=20
     for_each_vcpu( d, v ) {
         struct hvm_vmce_vcpu ctxt =3D {
-            .caps =3D v->arch.mcg_cap
+            .caps =3D v->arch.vmce.mcg_cap
         };
=20
         err =3D hvm_save_entry(VMCE_VCPU, v->vcpu_id, h, &ctxt);
@@ -422,93 +385,38 @@
     return 0;
 }
=20
-/* 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
- * virtualization. When one vMCE# injection is finished processing
- * processed by guest, the corresponding node will be deleted.
- * This node list is for GUEST vMCE# MSRS virtualization.
- */
-static struct bank_entry* alloc_bank_entry(void)
+int fill_vmsr_data(struct mcinfo_bank *mc_bank, struct domain *d,
+                   uint64_t gstatus)
 {
-    struct bank_entry *entry;
+    struct vcpu *v =3D d->vcpu[0];
=20
-    entry =3D xzalloc(struct bank_entry);
-    if ( entry =3D=3D NULL )
-    {
-        printk(KERN_ERR "MCE: malloc bank_entry failed\n");
-        return NULL;
-    }
-
-    INIT_LIST_HEAD(&entry->list);
-    return entry;
-}
-
-/* Fill error bank info for #vMCE injection and GUEST vMCE#
- * MSR virtualization data
- * 1) Log down how many nr_injections of the impacted.
- * 2) Copy MCE# error bank to impacted DOM node list,
- *    for vMCE# MSRs virtualization
- */
-int fill_vmsr_data(struct mcinfo_bank *mc_bank, struct domain *d,
-                   uint64_t gstatus) {
-    struct bank_entry *entry;
-
-    /* This error bank impacts one domain, we need to fill domain related
-     * data for vMCE MSRs virtualization and vMCE# injection */
     if ( mc_bank->mc_domid !=3D (uint16_t)~0 )
     {
-        /* For HVM guest, Only when first vMCE is consumed by HVM guest
-         * successfully, will we generete another node and inject another =
vMCE.
-         */
-        if ( d->is_hvm && (dom_vmce(d)->nr_injection > 0) )
+        if ( v->arch.vmce.mcg_status & MCG_STATUS_MCIP )
         {
-            mce_printk(MCE_QUIET, "MCE: HVM guest has not handled previous=
"
+            mce_printk(MCE_QUIET, "MCE: guest has not handled previous"
                        " vMCE yet!\n");
             return -1;
         }
=20
-        entry =3D alloc_bank_entry();
-        if ( entry =3D=3D NULL )
-            return -1;
+        spin_lock(&v->arch.vmce.lock);
=20
-        entry->mci_status =3D mc_bank->mc_status;
-        entry->mci_addr =3D mc_bank->mc_addr;
-        entry->mci_misc =3D mc_bank->mc_misc;
-        entry->bank =3D mc_bank->mc_bank;
+        v->arch.vmce.mcg_status =3D gstatus;
+        /*
+         * 1. Skip bank 0 to avoid 'bank 0 quirk' of old processors
+         * 2. Filter MCi_STATUS MSCOD model specific error code to guest
+         */
+        v->arch.vmce.bank[1].mci_status =3D mc_bank->mc_status &
+                                              MCi_STATUS_MSCOD_MASK;
+        v->arch.vmce.bank[1].mci_addr =3D mc_bank->mc_addr;
+        v->arch.vmce.bank[1].mci_misc =3D mc_bank->mc_misc;
=20
-        spin_lock(&dom_vmce(d)->lock);
-        /* New error Node, insert to the tail of the per_dom data */
-        list_add_tail(&entry->list, &dom_vmce(d)->impact_header);
-        /* Fill MSR global status */
-        dom_vmce(d)->mcg_status =3D gstatus;
-        /* New node impact the domain, need another vMCE# injection*/
-        dom_vmce(d)->nr_injection++;
-        spin_unlock(&dom_vmce(d)->lock);
-
-        mce_printk(MCE_VERBOSE,"MCE: Found error @[BANK%d "
-                   "status %"PRIx64" addr %"PRIx64" domid %d]\n ",
-                   mc_bank->mc_bank, mc_bank->mc_status, mc_bank->mc_addr,
-                   mc_bank->mc_domid);
+        spin_unlock(&v->arch.vmce.lock);
     }
=20
     return 0;
 }
=20
-#if 0 /* currently unused */
-int vmce_domain_inject(
-    struct mcinfo_bank *bank, struct domain *d, struct mcinfo_global *glob=
al)
-{
-    int ret;
-
-    ret =3D fill_vmsr_data(bank, d, global->mc_gstatus);
-    if ( ret < 0 )
-        return ret;
-
-    return inject_vmce(d);
-}
-#endif
-
 static int is_hvm_vmce_ready(struct mcinfo_bank *bank, struct domain *d)
 {
     struct vcpu *v;
diff -r fbd9e864c047 xen/arch/x86/domain.c
--- a/xen/arch/x86/domain.c	Mon Sep 17 18:02:59 2012 +0800
+++ b/xen/arch/x86/domain.c	Tue Sep 18 22:39:10 2012 +0800
@@ -571,9 +571,6 @@
=20
         if ( (rc =3D iommu_domain_init(d)) !=3D 0 )
             goto fail;
-
-        /* For Guest vMCE MSRs virtualization */
-        vmce_init_msr(d);
     }
=20
     if ( is_hvm_domain(d) )
@@ -600,7 +597,6 @@
=20
  fail:
     d->is_dying =3D DOMDYING_dead;
-    vmce_destroy_msr(d);
     cleanup_domain_irq_mapping(d);
     free_xenheap_page(d->shared_info);
     if ( paging_initialised )
@@ -623,7 +619,6 @@
     else
         xfree(d->arch.pv_domain.e820);
=20
-    vmce_destroy_msr(d);
     free_domain_pirqs(d);
     if ( !is_idle_domain(d) )
         iommu_domain_destroy(d);
diff -r fbd9e864c047 xen/arch/x86/domctl.c
--- a/xen/arch/x86/domctl.c	Mon Sep 17 18:02:59 2012 +0800
+++ b/xen/arch/x86/domctl.c	Tue Sep 18 22:39:10 2012 +0800
@@ -1024,7 +1024,7 @@
                 evc->syscall32_callback_eip    =3D 0;
                 evc->syscall32_disables_events =3D 0;
             }
-            evc->mcg_cap =3D v->arch.mcg_cap;
+            evc->mcg_cap =3D v->arch.vmce.mcg_cap;
         }
         else
         {
diff -r fbd9e864c047 xen/arch/x86/traps.c
--- a/xen/arch/x86/traps.c	Mon Sep 17 18:02:59 2012 +0800
+++ b/xen/arch/x86/traps.c	Tue Sep 18 22:39:10 2012 +0800
@@ -3133,50 +3133,6 @@
                 break;
     ASSERT(trap <=3D VCPU_TRAP_LAST);
=20
-    /* inject vMCE to PV_Guest including DOM0. */
-    if ( trap =3D=3D VCPU_TRAP_MCE )
-    {
-        gdprintk(XENLOG_DEBUG, "MCE: Return from vMCE# trap!\n");
-        if ( curr->vcpu_id =3D=3D 0 )
-        {
-            struct domain *d =3D curr->domain;
-
-            if ( !d->arch.vmca_msrs->nr_injection )
-            {
-                printk(XENLOG_WARNING "MCE: ret from vMCE#, "
-                       "no injection node\n");
-                goto end;
-            }
-
-            d->arch.vmca_msrs->nr_injection--;
-            if ( !list_empty(&d->arch.vmca_msrs->impact_header) )
-            {
-                struct bank_entry *entry;
-
-                entry =3D list_entry(d->arch.vmca_msrs->impact_header.next=
,
-                                   struct bank_entry, list);
-                gdprintk(XENLOG_DEBUG, "MCE: delete last injection node\n"=
);
-                list_del(&entry->list);
-            }
-            else
-                printk(XENLOG_ERR "MCE: didn't found last injection node\n=
");
-
-            /* further injection */
-            if ( d->arch.vmca_msrs->nr_injection > 0 &&
-                 guest_has_trap_callback(d, 0, TRAP_machine_check) &&
-                 !test_and_set_bool(curr->mce_pending) )
-            {
-                int cpu =3D smp_processor_id();
-
-                cpumask_copy(curr->cpu_affinity_tmp, curr->cpu_affinity);
-                printk(XENLOG_DEBUG "MCE: CPU%d set affinity, old %d\n",
-                       cpu, curr->processor);
-                vcpu_set_affinity(curr, cpumask_of(cpu));
-            }
-        }
-    }
-
-end:
     /* Restore previous asynchronous exception mask. */
     curr->async_exception_mask =3D curr->async_exception_state(trap).old_m=
ask;
 }
diff -r fbd9e864c047 xen/include/asm-x86/domain.h
--- a/xen/include/asm-x86/domain.h	Mon Sep 17 18:02:59 2012 +0800
+++ b/xen/include/asm-x86/domain.h	Tue Sep 18 22:39:10 2012 +0800
@@ -296,9 +296,6 @@
=20
     struct PITState vpit;
=20
-    /* For Guest vMCA handling */
-    struct domain_mca_msrs *vmca_msrs;
-
     /* TSC management (emulation, pv, scaling, stats) */
     int tsc_mode;            /* see include/asm-x86/time.h */
     bool_t vtsc;             /* tsc is emulated (may change after migrate)=
 */
@@ -438,8 +435,8 @@
      * and thus should be saved/restored. */
     bool_t nonlazy_xstate_used;
=20
-    uint64_t mcg_cap;
-   =20
+    struct vmce vmce;
+
     struct paging_vcpu paging;
=20
     uint32_t gdbsx_vcpu_event;
diff -r fbd9e864c047 xen/include/asm-x86/mce.h
--- a/xen/include/asm-x86/mce.h	Mon Sep 17 18:02:59 2012 +0800
+++ b/xen/include/asm-x86/mce.h	Tue Sep 18 22:39:10 2012 +0800
@@ -3,28 +3,50 @@
 #ifndef _XEN_X86_MCE_H
 #define _XEN_X86_MCE_H
=20
-/* This entry is for recording bank nodes for the impacted domain,
- * put into impact_header list. */
-struct bank_entry {
-    struct list_head list;
-    uint16_t bank;
+/*
+ * Emulalte 2 banks for guest
+ * Bank0: reserved for 'bank0 quirk' occur at some very old processors:
+ *   1). Intel cpu whose family-model value < 06-1A;
+ *   2). AMD K7
+ * Bank1: used to transfer error info to guest
+ */
+#define GUEST_MC_BANK_NUM 2
+
+/*
+ * MCG_SER_P:  software error recovery supported
+ * MCG_TES_P:  to avoid MCi_status bit56:53 model specific
+ * MCG_CMCI_P: expose CMCI capability but never really inject it to guest,
+ *             for sake of performance since guest not polling periodicall=
y
+ */
+#define INTEL_GUEST_MCG_CAP (MCG_SER_P |	\
+                             MCG_TES_P |	\
+                             MCG_CMCI_P |	\
+                             GUEST_MC_BANK_NUM)
+
+#define AMD_GUEST_MCG_CAP (MCG_SER_P |		\
+                           GUEST_MC_BANK_NUM)
+
+/* Filter MSCOD model specific error code to guest */
+#define MCi_STATUS_MSCOD_MASK (~(0xffffULL << 16))
+
+/* No mci_ctl since it stick all 1's */
+struct vmce_bank {
     uint64_t mci_status;
     uint64_t mci_addr;
     uint64_t mci_misc;
+    uint64_t mci_ctl2;
 };
=20
-struct domain_mca_msrs
-{
-    /* Guest should not change below values after DOM boot up */
+/* No mcg_ctl since it not expose to guest */
+struct vmce {
+    uint64_t mcg_cap;
     uint64_t mcg_status;
-    uint16_t nr_injection;
-    struct list_head impact_header;
+    struct vmce_bank bank[GUEST_MC_BANK_NUM];
+
     spinlock_t lock;
 };
=20
 /* 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);=

--_002_DE8DF0795D48FD4CA783C40EC829233532F3E2SHSMSX101ccrcorpi_
Content-Type: application/octet-stream; name="1_vmce_emulation.patch"
Content-Description: 1_vmce_emulation.patch
Content-Disposition: attachment; filename="1_vmce_emulation.patch";
	size=27202; creation-date="Tue, 18 Sep 2012 13:04:35 GMT";
	modification-date="Tue, 18 Sep 2012 20:46:56 GMT"
Content-Transfer-Encoding: base64

WGVuL01DRTogdk1DRSBlbXVsYXRpb24KClRoaXMgcGF0Y2ggcHJvdmlkZXMgdmlydHVhbCBNQ0Ug
c3VwcG9ydCB0byBndWVzdC4gSXQgZW11bGF0ZXMgYSBzaW1wbGUKYW5kIGNsZWFuIE1DRSBNU1Jz
IGludGVyZmFjZSB0byBndWVzdCBieSBmYWtpbmcgY2FwcyB0byBndWVzdCBpZiBuZWVkZWQKYW5k
IG1hc2tpbmcgY2FwcyBpZiB1bm5lY2Vzc2FyeToKMS4gUHJvdmlkaW5nIGEgd2VsbC1kZWZpbmVk
IE1DR19DQVAgdG8gZ3Vlc3QsIGZpbHRlciBvdXQgdW4tbmVjZXNzYXJ5IGNhcHMgYW5kIHByb3Zp
ZGUgb25seSBndWVzdCBuZWVkZWQgY2FwczsKMi4gRGlzYWJsaW5nIE1DR19DVEwgdG8gYXZvaWQg
bW9kZWwgc3BlY2lmaWM7CjMuIFN0aWNraW5nIGFsbCAxJ3MgdG8gTUNpX0NUTCB0byBndWVzdCB0
byBhdm9pZCBtb2RlbCBzcGVjaWZpYzsKNC4gRW5hYmxpbmcgQ01DSSBjYXAgYnV0IG5ldmVyIHJl
YWxseSBpbmplY3QgdG8gZ3Vlc3QgdG8gcHJldmVudCBwb2xsaW5nIHBlcmlvZGljYWxseTsKNS4g
TWFza2luZyBNU0NPRCBmaWVsZCBvZiBNQ2lfU1RBVFVTIHRvIGF2b2lkIG1vZGVsIHNwZWNpZmlj
Owo2LiBLZWVwaW5nIG5hdHVyYWwgc2VtYW50aWNzIGJ5IHBlci12Y3B1IGluc3RlYWQgb2YgcGVy
LWRvbWFpbiB2YXJpYWJsZXM7CjcuIFVzaW5nIGJhbmsxIGFuZCByZXNlcnZpbmcgYmFuazAgdG8g
d29yayBhcm91bmQgJ2JhbmswIHF1aXJrJyBvZiBzb21lIHZlcnkgb2xkIHByb2Nlc3NvcnM7Cjgu
IENsZWFuaW5nIHNvbWUgdk1DRSMgaW5qZWN0aW9uIGxvZ2ljIHdoaWNoIHNoYXJlZCBieSBJbnRl
bCBhbmQgQU1EIGJ1dCB1c2VsZXNzIHVuZGVyIG5ldyB2TUNFIGltcGxlbWVudDsKOS4gS2VlcGlu
ZyBjb21wYXRpbGJlIHcvIG9sZCB4ZW4gdmVyc2lvbiB3aGljaCBoYXMgYmVlbiBiYWNrcG9ydGVk
IHRvIFNMRVMxMSBTUDIsIHNvIHRoYXQgb2xkIHZNQ0Ugd291bGQgbm90IGJsb2NrZWQgd2hlbiBt
aWdyYXRlIHRvIG5ldyB2TUNFOwoKU2lnbmVkLW9mZi1ieTogTGl1LCBKaW5zb25nIDxqaW5zb25n
LmxpdUBpbnRlbC5jb20+CgpkaWZmIC1yIGZiZDllODY0YzA0NyB4ZW4vYXJjaC94ODYvY3B1L21j
aGVjay9tY2UuaAotLS0gYS94ZW4vYXJjaC94ODYvY3B1L21jaGVjay9tY2UuaAlNb24gU2VwIDE3
IDE4OjAyOjU5IDIwMTIgKzA4MDAKKysrIGIveGVuL2FyY2gveDg2L2NwdS9tY2hlY2svbWNlLmgJ
VHVlIFNlcCAxOCAyMjozOToxMCAyMDEyICswODAwCkBAIC0xNjgsMTMgKzE2OCwxMiBAQAogaW50
IGZpbGxfdm1zcl9kYXRhKHN0cnVjdCBtY2luZm9fYmFuayAqbWNfYmFuaywgc3RydWN0IGRvbWFp
biAqZCwKICAgICAgICAgdWludDY0X3QgZ3N0YXR1cyk7CiBpbnQgaW5qZWN0X3ZtY2Uoc3RydWN0
IGRvbWFpbiAqZCk7Ci1pbnQgdm1jZV9kb21haW5faW5qZWN0KHN0cnVjdCBtY2luZm9fYmFuayAq
YmFuaywgc3RydWN0IGRvbWFpbiAqZCwgc3RydWN0IG1jaW5mb19nbG9iYWwgKmdsb2JhbCk7CiAK
IHN0YXRpYyBpbmxpbmUgaW50IG1jZV92ZW5kb3JfYmFua19tc3IoY29uc3Qgc3RydWN0IHZjcHUg
KnYsIHVpbnQzMl90IG1zcikKIHsKICAgICBpZiAoIGJvb3RfY3B1X2RhdGEueDg2X3ZlbmRvciA9
PSBYODZfVkVORE9SX0lOVEVMICYmCiAgICAgICAgICBtc3IgPj0gTVNSX0lBMzJfTUMwX0NUTDIg
JiYKLSAgICAgICAgIG1zciA8IE1TUl9JQTMyX01DeF9DVEwyKHYtPmFyY2gubWNnX2NhcCAmIE1D
R19DQVBfQ09VTlQpICkKKyAgICAgICAgIG1zciA8IE1TUl9JQTMyX01DeF9DVEwyKHYtPmFyY2gu
dm1jZS5tY2dfY2FwICYgTUNHX0NBUF9DT1VOVCkgKQogICAgICAgICAgIHJldHVybiAxOwogICAg
IHJldHVybiAwOwogfQpAQCAtMTgyLDcgKzE4MSw3IEBACiBzdGF0aWMgaW5saW5lIGludCBtY2Vf
YmFua19tc3IoY29uc3Qgc3RydWN0IHZjcHUgKnYsIHVpbnQzMl90IG1zcikKIHsKICAgICBpZiAo
IChtc3IgPj0gTVNSX0lBMzJfTUMwX0NUTCAmJgotICAgICAgICAgIG1zciA8IE1TUl9JQTMyX01D
eF9DVEwodi0+YXJjaC5tY2dfY2FwICYgTUNHX0NBUF9DT1VOVCkpIHx8CisgICAgICAgICBtc3Ig
PCBNU1JfSUEzMl9NQ3hfQ1RMKHYtPmFyY2gudm1jZS5tY2dfY2FwICYgTUNHX0NBUF9DT1VOVCkp
IHx8CiAgICAgICAgICBtY2VfdmVuZG9yX2JhbmtfbXNyKHYsIG1zcikgKQogICAgICAgICByZXR1
cm4gMTsKICAgICByZXR1cm4gMDsKZGlmZiAtciBmYmQ5ZTg2NGMwNDcgeGVuL2FyY2gveDg2L2Nw
dS9tY2hlY2svbWNlX2ludGVsLmMKLS0tIGEveGVuL2FyY2gveDg2L2NwdS9tY2hlY2svbWNlX2lu
dGVsLmMJTW9uIFNlcCAxNyAxODowMjo1OSAyMDEyICswODAwCisrKyBiL3hlbi9hcmNoL3g4Ni9j
cHUvbWNoZWNrL21jZV9pbnRlbC5jCVR1ZSBTZXAgMTggMjI6Mzk6MTAgMjAxMiArMDgwMApAQCAt
MTMwMCwxNCArMTMwMCwxNSBAQAogLyogaW50ZWwgc3BlY2lmaWMgTUNBIE1TUiAqLwogaW50IGlu
dGVsX21jZV93cm1zcihzdHJ1Y3QgdmNwdSAqdiwgdWludDMyX3QgbXNyLCB1aW50NjRfdCB2YWwp
CiB7CisgICAgdW5zaWduZWQgaW50IGJhbmsgPSBtc3IgLSBNU1JfSUEzMl9NQzBfQ1RMMjsKICAg
ICBpbnQgcmV0ID0gMDsKIAotICAgIGlmICggbXNyID49IE1TUl9JQTMyX01DMF9DVEwyICYmCi0g
ICAgICAgICBtc3IgPCBNU1JfSUEzMl9NQ3hfQ1RMMih2LT5hcmNoLm1jZ19jYXAgJiBNQ0dfQ0FQ
X0NPVU5UKSApCisgICAgaWYgKCBiYW5rIDwgR1VFU1RfTUNfQkFOS19OVU0gKQogICAgIHsKLSAg
ICAgICAgbWNlX3ByaW50ayhNQ0VfUVVJRVQsICJXZSBoYXZlIGRpc2FibGVkIENNQ0kgY2FwYWJp
bGl0eSwgIgotICAgICAgICAgICAgICAgICAiR3Vlc3Qgc2hvdWxkIG5vdCB3cml0ZSB0aGlzIE1T
UiFcbiIpOwotICAgICAgICAgcmV0ID0gMTsKKyAgICAgICAgdi0+YXJjaC52bWNlLmJhbmtbYmFu
a10ubWNpX2N0bDIgPSB2YWw7CisgICAgICAgIG1jZV9wcmludGsoTUNFX1ZFUkJPU0UsICJNQ0U6
IHdyIE1DJXVfQ1RMMiAlIlBSSXg2NCJcbiIsCisgICAgICAgICAgICAgICAgICAgYmFuaywgdmFs
KTsKKyAgICAgICAgcmV0ID0gMTsKICAgICB9CiAKICAgICByZXR1cm4gcmV0OwpAQCAtMTMxNSwx
MyArMTMxNiwxNCBAQAogCiBpbnQgaW50ZWxfbWNlX3JkbXNyKGNvbnN0IHN0cnVjdCB2Y3B1ICp2
LCB1aW50MzJfdCBtc3IsIHVpbnQ2NF90ICp2YWwpCiB7CisgICAgdW5zaWduZWQgaW50IGJhbmsg
PSBtc3IgLSBNU1JfSUEzMl9NQzBfQ1RMMjsKICAgICBpbnQgcmV0ID0gMDsKIAotICAgIGlmICgg
bXNyID49IE1TUl9JQTMyX01DMF9DVEwyICYmCi0gICAgICAgICBtc3IgPCBNU1JfSUEzMl9NQ3hf
Q1RMMih2LT5hcmNoLm1jZ19jYXAgJiBNQ0dfQ0FQX0NPVU5UKSApCisgICAgaWYgKCBiYW5rIDwg
R1VFU1RfTUNfQkFOS19OVU0gKQogICAgIHsKLSAgICAgICAgbWNlX3ByaW50ayhNQ0VfUVVJRVQs
ICJXZSBoYXZlIGRpc2FibGVkIENNQ0kgY2FwYWJpbGl0eSwgIgotICAgICAgICAgICAgICAgICAi
R3Vlc3Qgc2hvdWxkIG5vdCByZWFkIHRoaXMgTVNSIVxuIik7CisgICAgICAgICp2YWwgPSB2LT5h
cmNoLnZtY2UuYmFua1tiYW5rXS5tY2lfY3RsMjsKKyAgICAgICAgbWNlX3ByaW50ayhNQ0VfVkVS
Qk9TRSwgIk1DRTogcmRtc3IgTUMldV9DVEwyIDB4JSJQUkl4NjQiXG4iLAorICAgICAgICAgICAg
ICAgICAgIGJhbmssICp2YWwpOwogICAgICAgICByZXQgPSAxOwogICAgIH0KIApkaWZmIC1yIGZi
ZDllODY0YzA0NyB4ZW4vYXJjaC94ODYvY3B1L21jaGVjay92bWNlLmMKLS0tIGEveGVuL2FyY2gv
eDg2L2NwdS9tY2hlY2svdm1jZS5jCU1vbiBTZXAgMTcgMTg6MDI6NTkgMjAxMiArMDgwMAorKysg
Yi94ZW4vYXJjaC94ODYvY3B1L21jaGVjay92bWNlLmMJVHVlIFNlcCAxOCAyMjozOToxMCAyMDEy
ICswODAwCkBAIC0xLDUgKzEsMjIgQEAKIC8qCi0gKiB2bWNlLmMgLSB2aXJ0dWFsIE1DRSBzdXBw
b3J0CisgKiB2bWNlLmMgLSBwcm92aWRlIHNvZnR3YXJlIGVtdWxhdGVkIHZNQ0Ugc3VwcG9ydCB0
byBndWVzdAorICoKKyAqIENvcHlyaWdodCAoQykgMjAxMCwgMjAxMSBKaWFuZywgWXVuaG9uZyA8
eXVuaG9uZy5qaWFuZ0BpbnRlbC5jb20+CisgKiBDb3B5cmlnaHQgKEMpIDIwMTIsIDIwMTMgTGl1
LCBKaW5zb25nIDxqaW5zb25nLmxpdUBpbnRlbC5jb20+CisgKgorICogVGhpcyBwcm9ncmFtIGlz
IGZyZWUgc29mdHdhcmU7IHlvdSBjYW4gcmVkaXN0cmlidXRlIGl0IGFuZC9vciBtb2RpZnkKKyAq
IGl0IHVuZGVyIHRoZSB0ZXJtcyBvZiB0aGUgR05VIEdlbmVyYWwgUHVibGljIExpY2Vuc2UgYXMg
cHVibGlzaGVkIGJ5CisgKiB0aGUgRnJlZSBTb2Z0d2FyZSBGb3VuZGF0aW9uOyBlaXRoZXIgdmVy
c2lvbiAyIG9mIHRoZSBMaWNlbnNlLCBvcgorICogKGF0IHlvdXIgb3B0aW9uKSBhbnkgbGF0ZXIg
dmVyc2lvbi4KKyAqCisgKiBUaGlzIHByb2dyYW0gaXMgZGlzdHJpYnV0ZWQgaW4gdGhlIGhvcGUg
dGhhdCBpdCB3aWxsIGJlIHVzZWZ1bCwKKyAqIGJ1dCBXSVRIT1VUIEFOWSBXQVJSQU5UWTsgd2l0
aG91dCBldmVuIHRoZSBpbXBsaWVkIHdhcnJhbnR5IG9mCisgKiBNRVJDSEFOVEFCSUxJVFkgb3Ig
RklUTkVTUyBGT1IgQSBQQVJUSUNVTEFSIFBVUlBPU0UuICBTZWUgdGhlCisgKiBHTlUgR2VuZXJh
bCBQdWJsaWMgTGljZW5zZSBmb3IgbW9yZSBkZXRhaWxzLgorICoKKyAqIFlvdSBzaG91bGQgaGF2
ZSByZWNlaXZlZCBhIGNvcHkgb2YgdGhlIEdOVSBHZW5lcmFsIFB1YmxpYyBMaWNlbnNlCisgKiBh
bG9uZyB3aXRoIHRoaXMgcHJvZ3JhbTsgaWYgbm90LCB3cml0ZSB0byB0aGUgRnJlZSBTb2Z0d2Fy
ZQorICogRm91bmRhdGlvbiwgSW5jLiwgNTkgVGVtcGxlIFBsYWNlLCBTdWl0ZSAzMzAsIEJvc3Rv
biwgTUEgIDAyMTExLTEzMDcgIFVTQQogICovCiAKICNpbmNsdWRlIDx4ZW4vaW5pdC5oPgpAQCAt
MTksNjcgKzM2LDU1IEBACiAjaW5jbHVkZSAibWNlLmgiCiAjaW5jbHVkZSAieDg2X21jYS5oIgog
Ci0vKgotICogRW11bGF0ZSAyIGJhbmtzIGZvciBndWVzdAotICogQmFuazA6IHJlc2VydmVkIGZv
ciAnYmFuazAgcXVpcmsnIG9jY3VyIGF0IHNvbWUgdmVyeSBvbGQgcHJvY2Vzc29yczoKLSAqICAg
MSkuIEludGVsIGNwdSB3aG9zZSBmYW1pbHktbW9kZWwgdmFsdWUgPCAwNi0xQTsKLSAqICAgMiku
IEFNRCBLNwotICogQmFuazE6IHVzZWQgdG8gdHJhbnNmZXIgZXJyb3IgaW5mbyB0byBndWVzdAot
ICovCi0jZGVmaW5lIEdVRVNUX0JBTktfTlVNIDIKLSNkZWZpbmUgR1VFU1RfTUNHX0NBUCAoTUNH
X1RFU19QIHwgTUNHX1NFUl9QIHwgR1VFU1RfQkFOS19OVU0pCi0KLSNkZWZpbmUgZG9tX3ZtY2Uo
eCkgICAoKHgpLT5hcmNoLnZtY2FfbXNycykKLQotaW50IHZtY2VfaW5pdF9tc3Ioc3RydWN0IGRv
bWFpbiAqZCkKLXsKLSAgICBkb21fdm1jZShkKSA9IHhtYWxsb2Moc3RydWN0IGRvbWFpbl9tY2Ff
bXNycyk7Ci0gICAgaWYgKCAhZG9tX3ZtY2UoZCkgKQotICAgICAgICByZXR1cm4gLUVOT01FTTsK
LQotICAgIGRvbV92bWNlKGQpLT5tY2dfc3RhdHVzID0gMHgwOwotICAgIGRvbV92bWNlKGQpLT5u
cl9pbmplY3Rpb24gPSAwOwotCi0gICAgSU5JVF9MSVNUX0hFQUQoJmRvbV92bWNlKGQpLT5pbXBh
Y3RfaGVhZGVyKTsKLSAgICBzcGluX2xvY2tfaW5pdCgmZG9tX3ZtY2UoZCktPmxvY2spOwotCi0g
ICAgcmV0dXJuIDA7Ci19Ci0KLXZvaWQgdm1jZV9kZXN0cm95X21zcihzdHJ1Y3QgZG9tYWluICpk
KQotewotICAgIGlmICggIWRvbV92bWNlKGQpICkKLSAgICAgICAgcmV0dXJuOwotICAgIHhmcmVl
KGRvbV92bWNlKGQpKTsKLSAgICBkb21fdm1jZShkKSA9IE5VTEw7Ci19Ci0KIHZvaWQgdm1jZV9p
bml0X3ZjcHUoc3RydWN0IHZjcHUgKnYpCiB7Ci0gICAgdi0+YXJjaC5tY2dfY2FwID0gR1VFU1Rf
TUNHX0NBUDsKKyAgICBpbnQgaTsKKworICAgIC8qIGdsb2JhbCBNQ0EgTVNScyBpbml0ICovCisg
ICAgaWYgKCBib290X2NwdV9kYXRhLng4Nl92ZW5kb3IgPT0gWDg2X1ZFTkRPUl9JTlRFTCApCisg
ICAgICAgIHYtPmFyY2gudm1jZS5tY2dfY2FwID0gSU5URUxfR1VFU1RfTUNHX0NBUDsKKyAgICBl
bHNlCisgICAgICAgIHYtPmFyY2gudm1jZS5tY2dfY2FwID0gQU1EX0dVRVNUX01DR19DQVA7CisK
KyAgICB2LT5hcmNoLnZtY2UubWNnX3N0YXR1cyA9IDA7CisKKyAgICAvKiBwZXItYmFuayBNQ0Eg
TVNScyBpbml0ICovCisgICAgZm9yICggaSA9IDA7IGkgPCBHVUVTVF9NQ19CQU5LX05VTTsgaSsr
ICkKKyAgICAgICAgbWVtc2V0KCZ2LT5hcmNoLnZtY2UuYmFua1tpXSwgMCwgc2l6ZW9mKHN0cnVj
dCB2bWNlX2JhbmspKTsKKworICAgIHNwaW5fbG9ja19pbml0KCZ2LT5hcmNoLnZtY2UubG9jayk7
CiB9CiAKIGludCB2bWNlX3Jlc3RvcmVfdmNwdShzdHJ1Y3QgdmNwdSAqdiwgdWludDY0X3QgY2Fw
cykKIHsKLSAgICBpZiAoIGNhcHMgJiB+R1VFU1RfTUNHX0NBUCAmIH5NQ0dfQ0FQX0NPVU5UICYg
fk1DR19DVExfUCApCisgICAgdWludDY0X3QgZ3Vlc3RfbWNnX2NhcDsKKworICAgIGlmICggYm9v
dF9jcHVfZGF0YS54ODZfdmVuZG9yID09IFg4Nl9WRU5ET1JfSU5URUwgKQorICAgICAgICBndWVz
dF9tY2dfY2FwID0gSU5URUxfR1VFU1RfTUNHX0NBUDsKKyAgICBlbHNlCisgICAgICAgIGd1ZXN0
X21jZ19jYXAgPSBBTURfR1VFU1RfTUNHX0NBUDsKKworICAgIGlmICggY2FwcyAmIH5ndWVzdF9t
Y2dfY2FwICYgfk1DR19DQVBfQ09VTlQgJiB+TUNHX0NUTF9QICkKICAgICB7CiAgICAgICAgIGRw
cmludGsoWEVOTE9HX0dfRVJSLCAiJXMgcmVzdG9yZTogdW5zdXBwb3J0ZWQgTUNBIGNhcGFiaWxp
dGllcyIKICAgICAgICAgICAgICAgICAiICUjIiBQUkl4NjQgIiBmb3IgZCVkOnYldSAoc3VwcG9y
dGVkOiAlI0x4KVxuIiwKICAgICAgICAgICAgICAgICBpc19odm1fdmNwdSh2KSA/ICJIVk0iIDog
IlBWIiwgY2Fwcywgdi0+ZG9tYWluLT5kb21haW5faWQsCi0gICAgICAgICAgICAgICAgdi0+dmNw
dV9pZCwgR1VFU1RfTUNHX0NBUCAmIH5NQ0dfQ0FQX0NPVU5UKTsKKyAgICAgICAgICAgICAgICB2
LT52Y3B1X2lkLCBndWVzdF9tY2dfY2FwICYgfk1DR19DQVBfQ09VTlQpOwogICAgICAgICByZXR1
cm4gLUVQRVJNOwogICAgIH0KIAotICAgIHYtPmFyY2gubWNnX2NhcCA9IGNhcHM7CisgICAgdi0+
YXJjaC52bWNlLm1jZ19jYXAgPSBjYXBzOwogICAgIHJldHVybiAwOwogfQogCi1zdGF0aWMgaW50
IGJhbmtfbWNlX3JkbXNyKGNvbnN0IHN0cnVjdCB2Y3B1ICp2LCB1aW50MzJfdCBtc3IsIHVpbnQ2
NF90ICp2YWwpCisvKgorICogRm9yIGhpc3RvcmljIHZlcnNpb24gcmVhc29uLCBiYW5rIG51bWJl
ciBtYXkgZ3JlYXRlciB0aGFuIEdVRVNUX01DX0JBTktfTlVNLAorICogd2hlbiBtaWdyYXRpZSBm
cm9tIG9sZCB2TUNFIHZlcnNpb24gdG8gbmV3IHZNQ0UuCisgKi8KK3N0YXRpYyBpbnQgYmFua19t
Y2VfcmRtc3Ioc3RydWN0IHZjcHUgKnYsIHVpbnQzMl90IG1zciwgdWludDY0X3QgKnZhbCkKIHsK
ICAgICBpbnQgcmV0ID0gMTsKICAgICB1bnNpZ25lZCBpbnQgYmFuayA9IChtc3IgLSBNU1JfSUEz
Ml9NQzBfQ1RMKSAvIDQ7Ci0gICAgc3RydWN0IGRvbWFpbl9tY2FfbXNycyAqdm1jZSA9IGRvbV92
bWNlKHYtPmRvbWFpbik7Ci0gICAgc3RydWN0IGJhbmtfZW50cnkgKmVudHJ5OwogCiAgICAgKnZh
bCA9IDA7CiAKQEAgLTkyLDQ2ICs5NywzMyBAQAogICAgICAgICAgICAgICAgICAgIGJhbmssICp2
YWwpOwogICAgICAgICBicmVhazsKICAgICBjYXNlIE1TUl9JQTMyX01DMF9TVEFUVVM6Ci0gICAg
ICAgIC8qIE9ubHkgZXJyb3IgYmFuayBpcyByZWFkLiBOb24tZXJyb3IgYmFua3Mgc2ltcGx5IHJl
dHVybi4gKi8KLSAgICAgICAgaWYgKCAhbGlzdF9lbXB0eSgmdm1jZS0+aW1wYWN0X2hlYWRlcikg
KQorICAgICAgICBpZiAoIGJhbmsgPCBHVUVTVF9NQ19CQU5LX05VTSApCiAgICAgICAgIHsKLSAg
ICAgICAgICAgIGVudHJ5ID0gbGlzdF9lbnRyeSh2bWNlLT5pbXBhY3RfaGVhZGVyLm5leHQsCi0g
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgc3RydWN0IGJhbmtfZW50cnksIGxpc3QpOwot
ICAgICAgICAgICAgaWYgKCBlbnRyeS0+YmFuayA9PSBiYW5rICkKLSAgICAgICAgICAgIHsKLSAg
ICAgICAgICAgICAgICAqdmFsID0gZW50cnktPm1jaV9zdGF0dXM7CisgICAgICAgICAgICAqdmFs
ID0gdi0+YXJjaC52bWNlLmJhbmtbYmFua10ubWNpX3N0YXR1czsKKyAgICAgICAgICAgIGlmICgg
KnZhbCApCiAgICAgICAgICAgICAgICAgbWNlX3ByaW50ayhNQ0VfVkVSQk9TRSwKLSAgICAgICAg
ICAgICAgICAgICAgICAgICAgICJNQ0U6IHJkIE1DJXVfU1RBVFVTIGluIHZNQ0UjIGNvbnRleHQg
IgotICAgICAgICAgICAgICAgICAgICAgICAgICAgInZhbHVlIDB4JSJQUkl4NjQiXG4iLCBiYW5r
LCAqdmFsKTsKLSAgICAgICAgICAgIH0KKyAgICAgICAgICAgICAgICAgICAgICAgICAgICJNQ0U6
IHJkbXNyIE1DJXVfU1RBVFVTIGluIHZNQ0UjIGNvbnRleHQgIgorICAgICAgICAgICAgICAgICAg
ICAgICAgICAgIjB4JSJQUkl4NjQiXG4iLCBiYW5rLCAqdmFsKTsKICAgICAgICAgfQogICAgICAg
ICBicmVhazsKICAgICBjYXNlIE1TUl9JQTMyX01DMF9BRERSOgotICAgICAgICBpZiAoICFsaXN0
X2VtcHR5KCZ2bWNlLT5pbXBhY3RfaGVhZGVyKSApCisgICAgICAgIGlmICggYmFuayA8IEdVRVNU
X01DX0JBTktfTlVNICkKICAgICAgICAgewotICAgICAgICAgICAgZW50cnkgPSBsaXN0X2VudHJ5
KHZtY2UtPmltcGFjdF9oZWFkZXIubmV4dCwKLSAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICBzdHJ1Y3QgYmFua19lbnRyeSwgbGlzdCk7Ci0gICAgICAgICAgICBpZiAoIGVudHJ5LT5iYW5r
ID09IGJhbmsgKQotICAgICAgICAgICAgewotICAgICAgICAgICAgICAgICp2YWwgPSBlbnRyeS0+
bWNpX2FkZHI7CisgICAgICAgICAgICAqdmFsID0gdi0+YXJjaC52bWNlLmJhbmtbYmFua10ubWNp
X2FkZHI7CisgICAgICAgICAgICBpZiAoICp2YWwgKQogICAgICAgICAgICAgICAgIG1jZV9wcmlu
dGsoTUNFX1ZFUkJPU0UsCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAiTUNFOiByZG1zciBN
QyV1X0FERFIgaW4gdk1DRSMgY29udGV4dCAiCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAi
MHglIlBSSXg2NCJcbiIsIGJhbmssICp2YWwpOwotICAgICAgICAgICAgfQogICAgICAgICB9CiAg
ICAgICAgIGJyZWFrOwogICAgIGNhc2UgTVNSX0lBMzJfTUMwX01JU0M6Ci0gICAgICAgIGlmICgg
IWxpc3RfZW1wdHkoJnZtY2UtPmltcGFjdF9oZWFkZXIpICkKKyAgICAgICAgaWYgKCBiYW5rIDwg
R1VFU1RfTUNfQkFOS19OVU0gKQogICAgICAgICB7Ci0gICAgICAgICAgICBlbnRyeSA9IGxpc3Rf
ZW50cnkodm1jZS0+aW1wYWN0X2hlYWRlci5uZXh0LAotICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgIHN0cnVjdCBiYW5rX2VudHJ5LCBsaXN0KTsKLSAgICAgICAgICAgIGlmICggZW50cnkt
PmJhbmsgPT0gYmFuayApCi0gICAgICAgICAgICB7Ci0gICAgICAgICAgICAgICAgKnZhbCA9IGVu
dHJ5LT5tY2lfbWlzYzsKKyAgICAgICAgICAgICp2YWwgPSB2LT5hcmNoLnZtY2UuYmFua1tiYW5r
XS5tY2lfbWlzYzsKKyAgICAgICAgICAgIGlmICggKnZhbCApCiAgICAgICAgICAgICAgICAgbWNl
X3ByaW50ayhNQ0VfVkVSQk9TRSwKLSAgICAgICAgICAgICAgICAgICAgICAgICAgICJNQ0U6IHJk
IE1DJXVfTUlTQyBpbiB2TUNFIyBjb250ZXh0ICIKKyAgICAgICAgICAgICAgICAgICAgICAgICAg
ICJNQ0U6IHJkbXNyIE1DJXVfTUlTQyBpbiB2TUNFIyBjb250ZXh0ICIKICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICIweCUiUFJJeDY0IlxuIiwgYmFuaywgKnZhbCk7Ci0gICAgICAgICAgICB9
CiAgICAgICAgIH0KICAgICAgICAgYnJlYWs7CiAgICAgZGVmYXVsdDoKQEAgLTE1Nyw1NiArMTQ5
LDUwIEBACiAgKi8KIGludCB2bWNlX3JkbXNyKHVpbnQzMl90IG1zciwgdWludDY0X3QgKnZhbCkK
IHsKLSAgICBjb25zdCBzdHJ1Y3QgdmNwdSAqY3VyID0gY3VycmVudDsKLSAgICBzdHJ1Y3QgZG9t
YWluX21jYV9tc3JzICp2bWNlID0gZG9tX3ZtY2UoY3VyLT5kb21haW4pOworICAgIHN0cnVjdCB2
Y3B1ICpjdXIgPSBjdXJyZW50OwogICAgIGludCByZXQgPSAxOwogCiAgICAgKnZhbCA9IDA7CiAK
LSAgICBzcGluX2xvY2soJnZtY2UtPmxvY2spOworICAgIHNwaW5fbG9jaygmY3VyLT5hcmNoLnZt
Y2UubG9jayk7CiAKICAgICBzd2l0Y2ggKCBtc3IgKQogICAgIHsKICAgICBjYXNlIE1TUl9JQTMy
X01DR19TVEFUVVM6Ci0gICAgICAgICp2YWwgPSB2bWNlLT5tY2dfc3RhdHVzOworICAgICAgICAq
dmFsID0gY3VyLT5hcmNoLnZtY2UubWNnX3N0YXR1czsKICAgICAgICAgaWYgKCp2YWwpCiAgICAg
ICAgICAgICBtY2VfcHJpbnRrKE1DRV9WRVJCT1NFLAogICAgICAgICAgICAgICAgICAgICAgICAi
TUNFOiByZG1zciBNQ0dfU1RBVFVTIDB4JSJQUkl4NjQiXG4iLCAqdmFsKTsKICAgICAgICAgYnJl
YWs7CiAgICAgY2FzZSBNU1JfSUEzMl9NQ0dfQ0FQOgotICAgICAgICAqdmFsID0gY3VyLT5hcmNo
Lm1jZ19jYXA7Ci0gICAgICAgIG1jZV9wcmludGsoTUNFX1ZFUkJPU0UsICJNQ0U6IHJkbXNyIE1D
R19DQVAgMHglIlBSSXg2NCJcbiIsCi0gICAgICAgICAgICAgICAgICAgKnZhbCk7CisgICAgICAg
ICp2YWwgPSBjdXItPmFyY2gudm1jZS5tY2dfY2FwOworICAgICAgICBtY2VfcHJpbnRrKE1DRV9W
RVJCT1NFLCAiTUNFOiByZG1zciBNQ0dfQ0FQIDB4JSJQUkl4NjQiXG4iLCAqdmFsKTsKICAgICAg
ICAgYnJlYWs7CiAgICAgY2FzZSBNU1JfSUEzMl9NQ0dfQ1RMOgotICAgICAgICAvKiBTdGljayBh
bGwgMSdzIHdoZW4gQ1RMIHN1cHBvcnQsIGFuZCAwJ3Mgd2hlbiBubyBDVEwgc3VwcG9ydCAqLwot
ICAgICAgICBpZiAoIGN1ci0+YXJjaC5tY2dfY2FwICYgTUNHX0NUTF9QICkKLSAgICAgICAgICAg
ICp2YWwgPSB+MFVMTDsKLSAgICAgICAgbWNlX3ByaW50ayhNQ0VfVkVSQk9TRSwgIk1DRTogcmRt
c3IgTUNHX0NUTCAweCUiUFJJeDY0IlxuIiwgKnZhbCk7CisgICAgICAgIGlmICggY3VyLT5hcmNo
LnZtY2UubWNnX2NhcCAmIE1DR19DVExfUCApCisgICAgICAgIHsKKyAgICAgICAgICAgICp2YWwg
PSB+MFVMOworICAgICAgICAgICAgbWNlX3ByaW50ayhNQ0VfVkVSQk9TRSwgIk1DRTogcmRtc3Ig
TUNHX0NUTCAweCUiUFJJeDY0IlxuIiwgKnZhbCk7CisgICAgICAgIH0KICAgICAgICAgYnJlYWs7
CiAgICAgZGVmYXVsdDoKICAgICAgICAgcmV0ID0gbWNlX2JhbmtfbXNyKGN1ciwgbXNyKSA/IGJh
bmtfbWNlX3JkbXNyKGN1ciwgbXNyLCB2YWwpIDogMDsKICAgICAgICAgYnJlYWs7CiAgICAgfQog
Ci0gICAgc3Bpbl91bmxvY2soJnZtY2UtPmxvY2spOworICAgIHNwaW5fdW5sb2NrKCZjdXItPmFy
Y2gudm1jZS5sb2NrKTsKKwogICAgIHJldHVybiByZXQ7CiB9CiAKKy8qCisgKiBGb3IgaGlzdG9y
aWMgdmVyc2lvbiByZWFzb24sIGJhbmsgbnVtYmVyIG1heSBncmVhdGVyIHRoYW4gR1VFU1RfTUNf
QkFOS19OVU0sCisgKiB3aGVuIG1pZ3JhdGllIGZyb20gb2xkIHZNQ0UgdmVyc2lvbiB0byBuZXcg
dk1DRS4KKyAqLwogc3RhdGljIGludCBiYW5rX21jZV93cm1zcihzdHJ1Y3QgdmNwdSAqdiwgdTMy
IG1zciwgdTY0IHZhbCkKIHsKICAgICBpbnQgcmV0ID0gMTsKICAgICB1bnNpZ25lZCBpbnQgYmFu
ayA9IChtc3IgLSBNU1JfSUEzMl9NQzBfQ1RMKSAvIDQ7Ci0gICAgc3RydWN0IGRvbWFpbl9tY2Ff
bXNycyAqdm1jZSA9IGRvbV92bWNlKHYtPmRvbWFpbik7Ci0gICAgc3RydWN0IGJhbmtfZW50cnkg
KmVudHJ5ID0gTlVMTDsKLQotICAgIC8qIEdpdmUgdGhlIGZpcnN0IGVudHJ5IG9mIHRoZSBsaXN0
LCBpdCBjb3JyZXNwb25kcyB0byBjdXJyZW50Ci0gICAgICogdk1DRSMgaW5qZWN0aW9uLiBXaGVu
IHZNQ0UjIGlzIGZpbmlzaGVkIHByb2Nlc3NpbmcgYnkgdGhlCi0gICAgICogdGhlIGd1ZXN0LCB0
aGlzIG5vZGUgd2lsbCBiZSBkZWxldGVkLgotICAgICAqIE9ubHkgZXJyb3IgYmFuayBpcyB3cml0
dGVuLiBOb24tZXJyb3IgYmFua3Mgc2ltcGx5IHJldHVybi4KLSAgICAgKi8KLSAgICBpZiAoICFs
aXN0X2VtcHR5KCZ2bWNlLT5pbXBhY3RfaGVhZGVyKSApCi0gICAgICAgIGVudHJ5ID0gbGlzdF9l
bnRyeSh2bWNlLT5pbXBhY3RfaGVhZGVyLm5leHQsIHN0cnVjdCBiYW5rX2VudHJ5LCBsaXN0KTsK
IAogICAgIHN3aXRjaCAoIG1zciAmIChNU1JfSUEzMl9NQzBfQ1RMIHwgMykgKQogICAgIHsKQEAg
LTIxNyw1MCArMjAzLDQ2IEBACiAgICAgICAgICAqLwogICAgICAgICBicmVhazsKICAgICBjYXNl
IE1TUl9JQTMyX01DMF9TVEFUVVM6Ci0gICAgICAgIGlmICggZW50cnkgJiYgKGVudHJ5LT5iYW5r
ID09IGJhbmspICkKKyAgICAgICAgaWYgKCB2YWwgKQogICAgICAgICB7Ci0gICAgICAgICAgICBl
bnRyeS0+bWNpX3N0YXR1cyA9IHZhbDsKLSAgICAgICAgICAgIG1jZV9wcmludGsoTUNFX1ZFUkJP
U0UsCi0gICAgICAgICAgICAgICAgICAgICAgICJNQ0U6IHdyIE1DJXVfU1RBVFVTICUiUFJJeDY0
IiBpbiB2TUNFI1xuIiwKKyAgICAgICAgICAgIG1jZV9wcmludGsoTUNFX1FVSUVULAorICAgICAg
ICAgICAgICAgICAgICAgICAiTUNFOiB3ciBNQyV1X1NUQVRVUyB3LyBub24temVybyBjYXVzZSAj
R1BcbiIsIGJhbmspOworICAgICAgICAgICAgcmV0ID0gLTE7CisgICAgICAgIH0KKyAgICAgICAg
aWYgKCBiYW5rIDwgR1VFU1RfTUNfQkFOS19OVU0gKQorICAgICAgICB7CisgICAgICAgICAgICB2
LT5hcmNoLnZtY2UuYmFua1tiYW5rXS5tY2lfc3RhdHVzID0gdmFsOworICAgICAgICAgICAgbWNl
X3ByaW50ayhNQ0VfVkVSQk9TRSwgIk1DRTogd3IgTUMldV9TVEFUVVMgJSJQUkl4NjQiXG4iLAog
ICAgICAgICAgICAgICAgICAgICAgICBiYW5rLCB2YWwpOwogICAgICAgICB9Ci0gICAgICAgIGVs
c2UKLSAgICAgICAgICAgIG1jZV9wcmludGsoTUNFX1ZFUkJPU0UsCi0gICAgICAgICAgICAgICAg
ICAgICAgICJNQ0U6IHdyIE1DJXVfU1RBVFVTICUiUFJJeDY0IlxuIiwgYmFuaywgdmFsKTsKICAg
ICAgICAgYnJlYWs7CiAgICAgY2FzZSBNU1JfSUEzMl9NQzBfQUREUjoKLSAgICAgICAgaWYgKCAh
fnZhbCApCisgICAgICAgIGlmICggdmFsICkKICAgICAgICAgewogICAgICAgICAgICAgbWNlX3By
aW50ayhNQ0VfUVVJRVQsCi0gICAgICAgICAgICAgICAgICAgICAgICJNQ0U6IHdyIE1DJXVfQURE
UiB3aXRoIGFsbCAxcyB3aWxsIGNhdXNlICNHUFxuIiwgYmFuayk7CisgICAgICAgICAgICAgICAg
ICAgICAgICJNQ0U6IHdyIE1DJXVfQUREUiB3LyBub24temVybyBjYXVzZSAjR1BcbiIsIGJhbmsp
OwogICAgICAgICAgICAgcmV0ID0gLTE7CiAgICAgICAgIH0KLSAgICAgICAgZWxzZSBpZiAoIGVu
dHJ5ICYmIChlbnRyeS0+YmFuayA9PSBiYW5rKSApCisgICAgICAgIGVsc2UgaWYgKCBiYW5rIDwg
R1VFU1RfTUNfQkFOS19OVU0gKQogICAgICAgICB7Ci0gICAgICAgICAgICBlbnRyeS0+bWNpX2Fk
ZHIgPSB2YWw7Ci0gICAgICAgICAgICBtY2VfcHJpbnRrKE1DRV9WRVJCT1NFLAotICAgICAgICAg
ICAgICAgICAgICAgICAiTUNFOiB3ciBNQyV1X0FERFIgJSJQUkl4NjQiIGluIHZNQ0UjXG4iLCBi
YW5rLCB2YWwpOwotICAgICAgICB9Ci0gICAgICAgIGVsc2UKKyAgICAgICAgICAgIHYtPmFyY2gu
dm1jZS5iYW5rW2JhbmtdLm1jaV9hZGRyID0gdmFsOwogICAgICAgICAgICAgbWNlX3ByaW50ayhN
Q0VfVkVSQk9TRSwKICAgICAgICAgICAgICAgICAgICAgICAgIk1DRTogd3IgTUMldV9BRERSICUi
UFJJeDY0IlxuIiwgYmFuaywgdmFsKTsKKyAgICAgICAgfQogICAgICAgICBicmVhazsKICAgICBj
YXNlIE1TUl9JQTMyX01DMF9NSVNDOgotICAgICAgICBpZiAoICF+dmFsICkKKyAgICAgICAgaWYg
KCB2YWwgKQogICAgICAgICB7CiAgICAgICAgICAgICBtY2VfcHJpbnRrKE1DRV9RVUlFVCwKLSAg
ICAgICAgICAgICAgICAgICAgICAgIk1DRTogd3IgTUMldV9NSVNDIHdpdGggYWxsIDFzIHdpbGwg
Y2F1c2UgI0dQXG4iLCBiYW5rKTsKKyAgICAgICAgICAgICAgICAgICAgICAgIk1DRTogd3IgTUMl
dV9NSVNDIHcvIG5vbi16ZXJvIGNhdXNlICNHUFxuIiwgYmFuayk7CiAgICAgICAgICAgICByZXQg
PSAtMTsKICAgICAgICAgfQotICAgICAgICBlbHNlIGlmICggZW50cnkgJiYgKGVudHJ5LT5iYW5r
ID09IGJhbmspICkKKyAgICAgICAgZWxzZSBpZiAoIGJhbmsgPCBHVUVTVF9NQ19CQU5LX05VTSAp
CiAgICAgICAgIHsKLSAgICAgICAgICAgIGVudHJ5LT5tY2lfbWlzYyA9IHZhbDsKLSAgICAgICAg
ICAgIG1jZV9wcmludGsoTUNFX1ZFUkJPU0UsCi0gICAgICAgICAgICAgICAgICAgICAgICJNQ0U6
IHdyIE1DJXVfTUlTQyAlIlBSSXg2NCIgaW4gdk1DRSNcbiIsIGJhbmssIHZhbCk7Ci0gICAgICAg
IH0KLSAgICAgICAgZWxzZQorICAgICAgICAgICAgdi0+YXJjaC52bWNlLmJhbmtbYmFua10ubWNp
X21pc2MgPSB2YWw7CiAgICAgICAgICAgICBtY2VfcHJpbnRrKE1DRV9WRVJCT1NFLAogICAgICAg
ICAgICAgICAgICAgICAgICAiTUNFOiB3ciBNQyV1X01JU0MgJSJQUkl4NjQiXG4iLCBiYW5rLCB2
YWwpOworICAgICAgICB9CiAgICAgICAgIGJyZWFrOwogICAgIGRlZmF1bHQ6CiAgICAgICAgIHN3
aXRjaCAoIGJvb3RfY3B1X2RhdGEueDg2X3ZlbmRvciApCkBAIC0yODYsNTIgKzI2OCwzMyBAQAog
aW50IHZtY2Vfd3Jtc3IodTMyIG1zciwgdTY0IHZhbCkKIHsKICAgICBzdHJ1Y3QgdmNwdSAqY3Vy
ID0gY3VycmVudDsKLSAgICBzdHJ1Y3QgYmFua19lbnRyeSAqZW50cnkgPSBOVUxMOwotICAgIHN0
cnVjdCBkb21haW5fbWNhX21zcnMgKnZtY2UgPSBkb21fdm1jZShjdXItPmRvbWFpbik7CiAgICAg
aW50IHJldCA9IDE7CiAKLSAgICBzcGluX2xvY2soJnZtY2UtPmxvY2spOworICAgIHNwaW5fbG9j
aygmY3VyLT5hcmNoLnZtY2UubG9jayk7CiAKICAgICBzd2l0Y2ggKCBtc3IgKQogICAgIHsKICAg
ICBjYXNlIE1TUl9JQTMyX01DR19DVEw6CisgICAgICAgIC8qIElmIE1DR19DVEwgZXhpc3QgdGhl
biBzdGljayB0byBhbGwgMSdzLiBJZiBub3QgZXhpc3QgdGhlbiBpZ25vcmUgKi8KICAgICAgICAg
YnJlYWs7CiAgICAgY2FzZSBNU1JfSUEzMl9NQ0dfU1RBVFVTOgotICAgICAgICB2bWNlLT5tY2df
c3RhdHVzID0gdmFsOworICAgICAgICBjdXItPmFyY2gudm1jZS5tY2dfc3RhdHVzID0gdmFsOwog
ICAgICAgICBtY2VfcHJpbnRrKE1DRV9WRVJCT1NFLCAiTUNFOiB3cm1zciBNQ0dfU1RBVFVTICUi
UFJJeDY0IlxuIiwgdmFsKTsKLSAgICAgICAgLyogRm9yIEhWTSBndWVzdCwgdGhpcyBpcyB0aGUg
cG9pbnQgZm9yIGRlbGV0aW5nIHZNQ0UgaW5qZWN0aW9uIG5vZGUgKi8KLSAgICAgICAgaWYgKCBp
c19odm1fdmNwdShjdXIpICYmICh2bWNlLT5ucl9pbmplY3Rpb24gPiAwKSApCi0gICAgICAgIHsK
LSAgICAgICAgICAgIHZtY2UtPm5yX2luamVjdGlvbi0tOyAvKiBTaG91bGQgYmUgMCAqLwotICAg
ICAgICAgICAgaWYgKCAhbGlzdF9lbXB0eSgmdm1jZS0+aW1wYWN0X2hlYWRlcikgKQotICAgICAg
ICAgICAgewotICAgICAgICAgICAgICAgIGVudHJ5ID0gbGlzdF9lbnRyeSh2bWNlLT5pbXBhY3Rf
aGVhZGVyLm5leHQsCi0gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHN0cnVjdCBi
YW5rX2VudHJ5LCBsaXN0KTsKLSAgICAgICAgICAgICAgICBpZiAoIGVudHJ5LT5tY2lfc3RhdHVz
ICYgTUNpX1NUQVRVU19WQUwgKQotICAgICAgICAgICAgICAgICAgICBtY2VfcHJpbnRrKE1DRV9R
VUlFVCwgIk1DRTogTUNpX1NUQVRVUyBNU1Igc2hvdWxkIGhhdmUgIgotICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICJiZWVuIGNsZWFyZWQgYmVmb3JlIHdyaXRlIE1DR19TVEFUVVMgTVNS
XG4iKTsKLQotICAgICAgICAgICAgICAgIG1jZV9wcmludGsoTUNFX1FVSUVULCAiTUNFOiBEZWxl
dGUgSFZNIGxhc3QgaW5qZWN0aW9uICIKLSAgICAgICAgICAgICAgICAgICAgICAgICAgICJOb2Rl
LCBucl9pbmplY3Rpb24gJXVcbiIsCi0gICAgICAgICAgICAgICAgICAgICAgICAgICB2bWNlLT5u
cl9pbmplY3Rpb24pOwotICAgICAgICAgICAgICAgIGxpc3RfZGVsKCZlbnRyeS0+bGlzdCk7Ci0g
ICAgICAgICAgICAgICAgeGZyZWUoZW50cnkpOwotICAgICAgICAgICAgfQotICAgICAgICAgICAg
ZWxzZQotICAgICAgICAgICAgICAgIG1jZV9wcmludGsoTUNFX1FVSUVULCAiTUNFOiBOb3QgZm91
bmQgSFZNIGd1ZXN0IgotICAgICAgICAgICAgICAgICAgICAgICAgICAgIiBsYXN0IGluamVjdGlv
biBOb2RlLCBzb21ldGhpbmcgV3JvbmchXG4iKTsKLSAgICAgICAgfQogICAgICAgICBicmVhazsK
ICAgICBjYXNlIE1TUl9JQTMyX01DR19DQVA6Ci0gICAgICAgIG1jZV9wcmludGsoTUNFX1FVSUVU
LCAiTUNFOiBNQ0dfQ0FQIGlzIHJlYWQtb25seVxuIik7Ci0gICAgICAgIHJldCA9IC0xOworICAg
ICAgICAvKgorICAgICAgICAgKiBBY2NvcmRpbmcgdG8gSW50ZWwgU0RNLCBJQTMyX01DR19DQVAg
aXMgYSByZWFkLW9ubHkgcmVnaXN0ZXIsCisgICAgICAgICAqIHRoZSBlZmZlY3Qgb2Ygd3JpdGlu
ZyB0byB0aGUgSUEzMl9NQ0dfQ0FQIGlzIHVuZGVmaW5lZC4gSGVyZSB3ZQorICAgICAgICAgKiB0
cmVhdCB3cml0aW5nIGFzICd3cml0ZSBub3QgY2hhbmdlJy4gR3Vlc3Qgd291bGQgbm90IHN1cnBy
aXNlLgorICAgICAgICAgKi8KKyAgICAgICAgbWNlX3ByaW50ayhNQ0VfUVVJRVQsICJNQ0U6IE1D
R19DQVAgaXMgcmVhZCBvbmx5IGFuZCB3cml0ZSBub3QgY2hhbmdlXG4iKTsKICAgICAgICAgYnJl
YWs7CiAgICAgZGVmYXVsdDoKICAgICAgICAgcmV0ID0gbWNlX2JhbmtfbXNyKGN1ciwgbXNyKSA/
IGJhbmtfbWNlX3dybXNyKGN1ciwgbXNyLCB2YWwpIDogMDsKICAgICAgICAgYnJlYWs7CiAgICAg
fQogCi0gICAgc3Bpbl91bmxvY2soJnZtY2UtPmxvY2spOworICAgIHNwaW5fdW5sb2NrKCZjdXIt
PmFyY2gudm1jZS5sb2NrKTsKICAgICByZXR1cm4gcmV0OwogfQogCkBAIC0zNDIsNyArMzA1LDcg
QEAKIAogICAgIGZvcl9lYWNoX3ZjcHUoIGQsIHYgKSB7CiAgICAgICAgIHN0cnVjdCBodm1fdm1j
ZV92Y3B1IGN0eHQgPSB7Ci0gICAgICAgICAgICAuY2FwcyA9IHYtPmFyY2gubWNnX2NhcAorICAg
ICAgICAgICAgLmNhcHMgPSB2LT5hcmNoLnZtY2UubWNnX2NhcAogICAgICAgICB9OwogCiAgICAg
ICAgIGVyciA9IGh2bV9zYXZlX2VudHJ5KFZNQ0VfVkNQVSwgdi0+dmNwdV9pZCwgaCwgJmN0eHQp
OwpAQCAtNDIyLDkzICszODUsMzggQEAKICAgICByZXR1cm4gMDsKIH0KIAotLyogVGhpcyBub2Rl
IGxpc3QgcmVjb3JkcyBlcnJvcnMgaW1wYWN0aW5nIGEgZG9tYWluLiB3aGVuIG9uZQotICogTUNF
IyBoYXBwZW5zLCBvbmUgZXJyb3IgYmFuayBpbXBhY3RzIGEgZG9tYWluLiBUaGlzIGVycm9yIG5v
ZGUKLSAqIHdpbGwgYmUgaW5zZXJ0ZWQgdG8gdGhlIHRhaWwgb2YgdGhlIHBlcl9kb20gZGF0YSBm
b3Igdk1DRSMgTVNSCi0gKiB2aXJ0dWFsaXphdGlvbi4gV2hlbiBvbmUgdk1DRSMgaW5qZWN0aW9u
IGlzIGZpbmlzaGVkIHByb2Nlc3NpbmcKLSAqIHByb2Nlc3NlZCBieSBndWVzdCwgdGhlIGNvcnJl
c3BvbmRpbmcgbm9kZSB3aWxsIGJlIGRlbGV0ZWQuCi0gKiBUaGlzIG5vZGUgbGlzdCBpcyBmb3Ig
R1VFU1Qgdk1DRSMgTVNSUyB2aXJ0dWFsaXphdGlvbi4KLSAqLwotc3RhdGljIHN0cnVjdCBiYW5r
X2VudHJ5KiBhbGxvY19iYW5rX2VudHJ5KHZvaWQpCitpbnQgZmlsbF92bXNyX2RhdGEoc3RydWN0
IG1jaW5mb19iYW5rICptY19iYW5rLCBzdHJ1Y3QgZG9tYWluICpkLAorICAgICAgICAgICAgICAg
ICAgIHVpbnQ2NF90IGdzdGF0dXMpCiB7Ci0gICAgc3RydWN0IGJhbmtfZW50cnkgKmVudHJ5Owor
ICAgIHN0cnVjdCB2Y3B1ICp2ID0gZC0+dmNwdVswXTsKIAotICAgIGVudHJ5ID0geHphbGxvYyhz
dHJ1Y3QgYmFua19lbnRyeSk7Ci0gICAgaWYgKCBlbnRyeSA9PSBOVUxMICkKLSAgICB7Ci0gICAg
ICAgIHByaW50ayhLRVJOX0VSUiAiTUNFOiBtYWxsb2MgYmFua19lbnRyeSBmYWlsZWRcbiIpOwot
ICAgICAgICByZXR1cm4gTlVMTDsKLSAgICB9Ci0KLSAgICBJTklUX0xJU1RfSEVBRCgmZW50cnkt
Pmxpc3QpOwotICAgIHJldHVybiBlbnRyeTsKLX0KLQotLyogRmlsbCBlcnJvciBiYW5rIGluZm8g
Zm9yICN2TUNFIGluamVjdGlvbiBhbmQgR1VFU1Qgdk1DRSMKLSAqIE1TUiB2aXJ0dWFsaXphdGlv
biBkYXRhCi0gKiAxKSBMb2cgZG93biBob3cgbWFueSBucl9pbmplY3Rpb25zIG9mIHRoZSBpbXBh
Y3RlZC4KLSAqIDIpIENvcHkgTUNFIyBlcnJvciBiYW5rIHRvIGltcGFjdGVkIERPTSBub2RlIGxp
c3QsCi0gKiAgICBmb3Igdk1DRSMgTVNScyB2aXJ0dWFsaXphdGlvbgotICovCi1pbnQgZmlsbF92
bXNyX2RhdGEoc3RydWN0IG1jaW5mb19iYW5rICptY19iYW5rLCBzdHJ1Y3QgZG9tYWluICpkLAot
ICAgICAgICAgICAgICAgICAgIHVpbnQ2NF90IGdzdGF0dXMpIHsKLSAgICBzdHJ1Y3QgYmFua19l
bnRyeSAqZW50cnk7Ci0KLSAgICAvKiBUaGlzIGVycm9yIGJhbmsgaW1wYWN0cyBvbmUgZG9tYWlu
LCB3ZSBuZWVkIHRvIGZpbGwgZG9tYWluIHJlbGF0ZWQKLSAgICAgKiBkYXRhIGZvciB2TUNFIE1T
UnMgdmlydHVhbGl6YXRpb24gYW5kIHZNQ0UjIGluamVjdGlvbiAqLwogICAgIGlmICggbWNfYmFu
ay0+bWNfZG9taWQgIT0gKHVpbnQxNl90KX4wICkKICAgICB7Ci0gICAgICAgIC8qIEZvciBIVk0g
Z3Vlc3QsIE9ubHkgd2hlbiBmaXJzdCB2TUNFIGlzIGNvbnN1bWVkIGJ5IEhWTSBndWVzdAotICAg
ICAgICAgKiBzdWNjZXNzZnVsbHksIHdpbGwgd2UgZ2VuZXJldGUgYW5vdGhlciBub2RlIGFuZCBp
bmplY3QgYW5vdGhlciB2TUNFLgotICAgICAgICAgKi8KLSAgICAgICAgaWYgKCBkLT5pc19odm0g
JiYgKGRvbV92bWNlKGQpLT5ucl9pbmplY3Rpb24gPiAwKSApCisgICAgICAgIGlmICggdi0+YXJj
aC52bWNlLm1jZ19zdGF0dXMgJiBNQ0dfU1RBVFVTX01DSVAgKQogICAgICAgICB7Ci0gICAgICAg
ICAgICBtY2VfcHJpbnRrKE1DRV9RVUlFVCwgIk1DRTogSFZNIGd1ZXN0IGhhcyBub3QgaGFuZGxl
ZCBwcmV2aW91cyIKKyAgICAgICAgICAgIG1jZV9wcmludGsoTUNFX1FVSUVULCAiTUNFOiBndWVz
dCBoYXMgbm90IGhhbmRsZWQgcHJldmlvdXMiCiAgICAgICAgICAgICAgICAgICAgICAgICIgdk1D
RSB5ZXQhXG4iKTsKICAgICAgICAgICAgIHJldHVybiAtMTsKICAgICAgICAgfQogCi0gICAgICAg
IGVudHJ5ID0gYWxsb2NfYmFua19lbnRyeSgpOwotICAgICAgICBpZiAoIGVudHJ5ID09IE5VTEwg
KQotICAgICAgICAgICAgcmV0dXJuIC0xOworICAgICAgICBzcGluX2xvY2soJnYtPmFyY2gudm1j
ZS5sb2NrKTsKIAotICAgICAgICBlbnRyeS0+bWNpX3N0YXR1cyA9IG1jX2JhbmstPm1jX3N0YXR1
czsKLSAgICAgICAgZW50cnktPm1jaV9hZGRyID0gbWNfYmFuay0+bWNfYWRkcjsKLSAgICAgICAg
ZW50cnktPm1jaV9taXNjID0gbWNfYmFuay0+bWNfbWlzYzsKLSAgICAgICAgZW50cnktPmJhbmsg
PSBtY19iYW5rLT5tY19iYW5rOworICAgICAgICB2LT5hcmNoLnZtY2UubWNnX3N0YXR1cyA9IGdz
dGF0dXM7CisgICAgICAgIC8qCisgICAgICAgICAqIDEuIFNraXAgYmFuayAwIHRvIGF2b2lkICdi
YW5rIDAgcXVpcmsnIG9mIG9sZCBwcm9jZXNzb3JzCisgICAgICAgICAqIDIuIEZpbHRlciBNQ2lf
U1RBVFVTIE1TQ09EIG1vZGVsIHNwZWNpZmljIGVycm9yIGNvZGUgdG8gZ3Vlc3QKKyAgICAgICAg
ICovCisgICAgICAgIHYtPmFyY2gudm1jZS5iYW5rWzFdLm1jaV9zdGF0dXMgPSBtY19iYW5rLT5t
Y19zdGF0dXMgJgorICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
IE1DaV9TVEFUVVNfTVNDT0RfTUFTSzsKKyAgICAgICAgdi0+YXJjaC52bWNlLmJhbmtbMV0ubWNp
X2FkZHIgPSBtY19iYW5rLT5tY19hZGRyOworICAgICAgICB2LT5hcmNoLnZtY2UuYmFua1sxXS5t
Y2lfbWlzYyA9IG1jX2JhbmstPm1jX21pc2M7CiAKLSAgICAgICAgc3Bpbl9sb2NrKCZkb21fdm1j
ZShkKS0+bG9jayk7Ci0gICAgICAgIC8qIE5ldyBlcnJvciBOb2RlLCBpbnNlcnQgdG8gdGhlIHRh
aWwgb2YgdGhlIHBlcl9kb20gZGF0YSAqLwotICAgICAgICBsaXN0X2FkZF90YWlsKCZlbnRyeS0+
bGlzdCwgJmRvbV92bWNlKGQpLT5pbXBhY3RfaGVhZGVyKTsKLSAgICAgICAgLyogRmlsbCBNU1Ig
Z2xvYmFsIHN0YXR1cyAqLwotICAgICAgICBkb21fdm1jZShkKS0+bWNnX3N0YXR1cyA9IGdzdGF0
dXM7Ci0gICAgICAgIC8qIE5ldyBub2RlIGltcGFjdCB0aGUgZG9tYWluLCBuZWVkIGFub3RoZXIg
dk1DRSMgaW5qZWN0aW9uKi8KLSAgICAgICAgZG9tX3ZtY2UoZCktPm5yX2luamVjdGlvbisrOwot
ICAgICAgICBzcGluX3VubG9jaygmZG9tX3ZtY2UoZCktPmxvY2spOwotCi0gICAgICAgIG1jZV9w
cmludGsoTUNFX1ZFUkJPU0UsIk1DRTogRm91bmQgZXJyb3IgQFtCQU5LJWQgIgotICAgICAgICAg
ICAgICAgICAgICJzdGF0dXMgJSJQUkl4NjQiIGFkZHIgJSJQUkl4NjQiIGRvbWlkICVkXVxuICIs
Ci0gICAgICAgICAgICAgICAgICAgbWNfYmFuay0+bWNfYmFuaywgbWNfYmFuay0+bWNfc3RhdHVz
LCBtY19iYW5rLT5tY19hZGRyLAotICAgICAgICAgICAgICAgICAgIG1jX2JhbmstPm1jX2RvbWlk
KTsKKyAgICAgICAgc3Bpbl91bmxvY2soJnYtPmFyY2gudm1jZS5sb2NrKTsKICAgICB9CiAKICAg
ICByZXR1cm4gMDsKIH0KIAotI2lmIDAgLyogY3VycmVudGx5IHVudXNlZCAqLwotaW50IHZtY2Vf
ZG9tYWluX2luamVjdCgKLSAgICBzdHJ1Y3QgbWNpbmZvX2JhbmsgKmJhbmssIHN0cnVjdCBkb21h
aW4gKmQsIHN0cnVjdCBtY2luZm9fZ2xvYmFsICpnbG9iYWwpCi17Ci0gICAgaW50IHJldDsKLQot
ICAgIHJldCA9IGZpbGxfdm1zcl9kYXRhKGJhbmssIGQsIGdsb2JhbC0+bWNfZ3N0YXR1cyk7Ci0g
ICAgaWYgKCByZXQgPCAwICkKLSAgICAgICAgcmV0dXJuIHJldDsKLQotICAgIHJldHVybiBpbmpl
Y3Rfdm1jZShkKTsKLX0KLSNlbmRpZgotCiBzdGF0aWMgaW50IGlzX2h2bV92bWNlX3JlYWR5KHN0
cnVjdCBtY2luZm9fYmFuayAqYmFuaywgc3RydWN0IGRvbWFpbiAqZCkKIHsKICAgICBzdHJ1Y3Qg
dmNwdSAqdjsKZGlmZiAtciBmYmQ5ZTg2NGMwNDcgeGVuL2FyY2gveDg2L2RvbWFpbi5jCi0tLSBh
L3hlbi9hcmNoL3g4Ni9kb21haW4uYwlNb24gU2VwIDE3IDE4OjAyOjU5IDIwMTIgKzA4MDAKKysr
IGIveGVuL2FyY2gveDg2L2RvbWFpbi5jCVR1ZSBTZXAgMTggMjI6Mzk6MTAgMjAxMiArMDgwMApA
QCAtNTcxLDkgKzU3MSw2IEBACiAKICAgICAgICAgaWYgKCAocmMgPSBpb21tdV9kb21haW5faW5p
dChkKSkgIT0gMCApCiAgICAgICAgICAgICBnb3RvIGZhaWw7Ci0KLSAgICAgICAgLyogRm9yIEd1
ZXN0IHZNQ0UgTVNScyB2aXJ0dWFsaXphdGlvbiAqLwotICAgICAgICB2bWNlX2luaXRfbXNyKGQp
OwogICAgIH0KIAogICAgIGlmICggaXNfaHZtX2RvbWFpbihkKSApCkBAIC02MDAsNyArNTk3LDYg
QEAKIAogIGZhaWw6CiAgICAgZC0+aXNfZHlpbmcgPSBET01EWUlOR19kZWFkOwotICAgIHZtY2Vf
ZGVzdHJveV9tc3IoZCk7CiAgICAgY2xlYW51cF9kb21haW5faXJxX21hcHBpbmcoZCk7CiAgICAg
ZnJlZV94ZW5oZWFwX3BhZ2UoZC0+c2hhcmVkX2luZm8pOwogICAgIGlmICggcGFnaW5nX2luaXRp
YWxpc2VkICkKQEAgLTYyMyw3ICs2MTksNiBAQAogICAgIGVsc2UKICAgICAgICAgeGZyZWUoZC0+
YXJjaC5wdl9kb21haW4uZTgyMCk7CiAKLSAgICB2bWNlX2Rlc3Ryb3lfbXNyKGQpOwogICAgIGZy
ZWVfZG9tYWluX3BpcnFzKGQpOwogICAgIGlmICggIWlzX2lkbGVfZG9tYWluKGQpICkKICAgICAg
ICAgaW9tbXVfZG9tYWluX2Rlc3Ryb3koZCk7CmRpZmYgLXIgZmJkOWU4NjRjMDQ3IHhlbi9hcmNo
L3g4Ni9kb21jdGwuYwotLS0gYS94ZW4vYXJjaC94ODYvZG9tY3RsLmMJTW9uIFNlcCAxNyAxODow
Mjo1OSAyMDEyICswODAwCisrKyBiL3hlbi9hcmNoL3g4Ni9kb21jdGwuYwlUdWUgU2VwIDE4IDIy
OjM5OjEwIDIwMTIgKzA4MDAKQEAgLTEwMjQsNyArMTAyNCw3IEBACiAgICAgICAgICAgICAgICAg
ZXZjLT5zeXNjYWxsMzJfY2FsbGJhY2tfZWlwICAgID0gMDsKICAgICAgICAgICAgICAgICBldmMt
PnN5c2NhbGwzMl9kaXNhYmxlc19ldmVudHMgPSAwOwogICAgICAgICAgICAgfQotICAgICAgICAg
ICAgZXZjLT5tY2dfY2FwID0gdi0+YXJjaC5tY2dfY2FwOworICAgICAgICAgICAgZXZjLT5tY2df
Y2FwID0gdi0+YXJjaC52bWNlLm1jZ19jYXA7CiAgICAgICAgIH0KICAgICAgICAgZWxzZQogICAg
ICAgICB7CmRpZmYgLXIgZmJkOWU4NjRjMDQ3IHhlbi9hcmNoL3g4Ni90cmFwcy5jCi0tLSBhL3hl
bi9hcmNoL3g4Ni90cmFwcy5jCU1vbiBTZXAgMTcgMTg6MDI6NTkgMjAxMiArMDgwMAorKysgYi94
ZW4vYXJjaC94ODYvdHJhcHMuYwlUdWUgU2VwIDE4IDIyOjM5OjEwIDIwMTIgKzA4MDAKQEAgLTMx
MzMsNTAgKzMxMzMsNiBAQAogICAgICAgICAgICAgICAgIGJyZWFrOwogICAgIEFTU0VSVCh0cmFw
IDw9IFZDUFVfVFJBUF9MQVNUKTsKIAotICAgIC8qIGluamVjdCB2TUNFIHRvIFBWX0d1ZXN0IGlu
Y2x1ZGluZyBET00wLiAqLwotICAgIGlmICggdHJhcCA9PSBWQ1BVX1RSQVBfTUNFICkKLSAgICB7
Ci0gICAgICAgIGdkcHJpbnRrKFhFTkxPR19ERUJVRywgIk1DRTogUmV0dXJuIGZyb20gdk1DRSMg
dHJhcCFcbiIpOwotICAgICAgICBpZiAoIGN1cnItPnZjcHVfaWQgPT0gMCApCi0gICAgICAgIHsK
LSAgICAgICAgICAgIHN0cnVjdCBkb21haW4gKmQgPSBjdXJyLT5kb21haW47Ci0KLSAgICAgICAg
ICAgIGlmICggIWQtPmFyY2gudm1jYV9tc3JzLT5ucl9pbmplY3Rpb24gKQotICAgICAgICAgICAg
ewotICAgICAgICAgICAgICAgIHByaW50ayhYRU5MT0dfV0FSTklORyAiTUNFOiByZXQgZnJvbSB2
TUNFIywgIgotICAgICAgICAgICAgICAgICAgICAgICAibm8gaW5qZWN0aW9uIG5vZGVcbiIpOwot
ICAgICAgICAgICAgICAgIGdvdG8gZW5kOwotICAgICAgICAgICAgfQotCi0gICAgICAgICAgICBk
LT5hcmNoLnZtY2FfbXNycy0+bnJfaW5qZWN0aW9uLS07Ci0gICAgICAgICAgICBpZiAoICFsaXN0
X2VtcHR5KCZkLT5hcmNoLnZtY2FfbXNycy0+aW1wYWN0X2hlYWRlcikgKQotICAgICAgICAgICAg
ewotICAgICAgICAgICAgICAgIHN0cnVjdCBiYW5rX2VudHJ5ICplbnRyeTsKLQotICAgICAgICAg
ICAgICAgIGVudHJ5ID0gbGlzdF9lbnRyeShkLT5hcmNoLnZtY2FfbXNycy0+aW1wYWN0X2hlYWRl
ci5uZXh0LAotICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBzdHJ1Y3QgYmFua19l
bnRyeSwgbGlzdCk7Ci0gICAgICAgICAgICAgICAgZ2RwcmludGsoWEVOTE9HX0RFQlVHLCAiTUNF
OiBkZWxldGUgbGFzdCBpbmplY3Rpb24gbm9kZVxuIik7Ci0gICAgICAgICAgICAgICAgbGlzdF9k
ZWwoJmVudHJ5LT5saXN0KTsKLSAgICAgICAgICAgIH0KLSAgICAgICAgICAgIGVsc2UKLSAgICAg
ICAgICAgICAgICBwcmludGsoWEVOTE9HX0VSUiAiTUNFOiBkaWRuJ3QgZm91bmQgbGFzdCBpbmpl
Y3Rpb24gbm9kZVxuIik7Ci0KLSAgICAgICAgICAgIC8qIGZ1cnRoZXIgaW5qZWN0aW9uICovCi0g
ICAgICAgICAgICBpZiAoIGQtPmFyY2gudm1jYV9tc3JzLT5ucl9pbmplY3Rpb24gPiAwICYmCi0g
ICAgICAgICAgICAgICAgIGd1ZXN0X2hhc190cmFwX2NhbGxiYWNrKGQsIDAsIFRSQVBfbWFjaGlu
ZV9jaGVjaykgJiYKLSAgICAgICAgICAgICAgICAgIXRlc3RfYW5kX3NldF9ib29sKGN1cnItPm1j
ZV9wZW5kaW5nKSApCi0gICAgICAgICAgICB7Ci0gICAgICAgICAgICAgICAgaW50IGNwdSA9IHNt
cF9wcm9jZXNzb3JfaWQoKTsKLQotICAgICAgICAgICAgICAgIGNwdW1hc2tfY29weShjdXJyLT5j
cHVfYWZmaW5pdHlfdG1wLCBjdXJyLT5jcHVfYWZmaW5pdHkpOwotICAgICAgICAgICAgICAgIHBy
aW50ayhYRU5MT0dfREVCVUcgIk1DRTogQ1BVJWQgc2V0IGFmZmluaXR5LCBvbGQgJWRcbiIsCi0g
ICAgICAgICAgICAgICAgICAgICAgIGNwdSwgY3Vyci0+cHJvY2Vzc29yKTsKLSAgICAgICAgICAg
ICAgICB2Y3B1X3NldF9hZmZpbml0eShjdXJyLCBjcHVtYXNrX29mKGNwdSkpOwotICAgICAgICAg
ICAgfQotICAgICAgICB9Ci0gICAgfQotCi1lbmQ6CiAgICAgLyogUmVzdG9yZSBwcmV2aW91cyBh
c3luY2hyb25vdXMgZXhjZXB0aW9uIG1hc2suICovCiAgICAgY3Vyci0+YXN5bmNfZXhjZXB0aW9u
X21hc2sgPSBjdXJyLT5hc3luY19leGNlcHRpb25fc3RhdGUodHJhcCkub2xkX21hc2s7CiB9CmRp
ZmYgLXIgZmJkOWU4NjRjMDQ3IHhlbi9pbmNsdWRlL2FzbS14ODYvZG9tYWluLmgKLS0tIGEveGVu
L2luY2x1ZGUvYXNtLXg4Ni9kb21haW4uaAlNb24gU2VwIDE3IDE4OjAyOjU5IDIwMTIgKzA4MDAK
KysrIGIveGVuL2luY2x1ZGUvYXNtLXg4Ni9kb21haW4uaAlUdWUgU2VwIDE4IDIyOjM5OjEwIDIw
MTIgKzA4MDAKQEAgLTI5Niw5ICsyOTYsNiBAQAogCiAgICAgc3RydWN0IFBJVFN0YXRlIHZwaXQ7
CiAKLSAgICAvKiBGb3IgR3Vlc3Qgdk1DQSBoYW5kbGluZyAqLwotICAgIHN0cnVjdCBkb21haW5f
bWNhX21zcnMgKnZtY2FfbXNyczsKLQogICAgIC8qIFRTQyBtYW5hZ2VtZW50IChlbXVsYXRpb24s
IHB2LCBzY2FsaW5nLCBzdGF0cykgKi8KICAgICBpbnQgdHNjX21vZGU7ICAgICAgICAgICAgLyog
c2VlIGluY2x1ZGUvYXNtLXg4Ni90aW1lLmggKi8KICAgICBib29sX3QgdnRzYzsgICAgICAgICAg
ICAgLyogdHNjIGlzIGVtdWxhdGVkIChtYXkgY2hhbmdlIGFmdGVyIG1pZ3JhdGUpICovCkBAIC00
MzgsOCArNDM1LDggQEAKICAgICAgKiBhbmQgdGh1cyBzaG91bGQgYmUgc2F2ZWQvcmVzdG9yZWQu
ICovCiAgICAgYm9vbF90IG5vbmxhenlfeHN0YXRlX3VzZWQ7CiAKLSAgICB1aW50NjRfdCBtY2df
Y2FwOwotICAgIAorICAgIHN0cnVjdCB2bWNlIHZtY2U7CisKICAgICBzdHJ1Y3QgcGFnaW5nX3Zj
cHUgcGFnaW5nOwogCiAgICAgdWludDMyX3QgZ2Ric3hfdmNwdV9ldmVudDsKZGlmZiAtciBmYmQ5
ZTg2NGMwNDcgeGVuL2luY2x1ZGUvYXNtLXg4Ni9tY2UuaAotLS0gYS94ZW4vaW5jbHVkZS9hc20t
eDg2L21jZS5oCU1vbiBTZXAgMTcgMTg6MDI6NTkgMjAxMiArMDgwMAorKysgYi94ZW4vaW5jbHVk
ZS9hc20teDg2L21jZS5oCVR1ZSBTZXAgMTggMjI6Mzk6MTAgMjAxMiArMDgwMApAQCAtMywyOCAr
Myw1MCBAQAogI2lmbmRlZiBfWEVOX1g4Nl9NQ0VfSAogI2RlZmluZSBfWEVOX1g4Nl9NQ0VfSAog
Ci0vKiBUaGlzIGVudHJ5IGlzIGZvciByZWNvcmRpbmcgYmFuayBub2RlcyBmb3IgdGhlIGltcGFj
dGVkIGRvbWFpbiwKLSAqIHB1dCBpbnRvIGltcGFjdF9oZWFkZXIgbGlzdC4gKi8KLXN0cnVjdCBi
YW5rX2VudHJ5IHsKLSAgICBzdHJ1Y3QgbGlzdF9oZWFkIGxpc3Q7Ci0gICAgdWludDE2X3QgYmFu
azsKKy8qCisgKiBFbXVsYWx0ZSAyIGJhbmtzIGZvciBndWVzdAorICogQmFuazA6IHJlc2VydmVk
IGZvciAnYmFuazAgcXVpcmsnIG9jY3VyIGF0IHNvbWUgdmVyeSBvbGQgcHJvY2Vzc29yczoKKyAq
ICAgMSkuIEludGVsIGNwdSB3aG9zZSBmYW1pbHktbW9kZWwgdmFsdWUgPCAwNi0xQTsKKyAqICAg
MikuIEFNRCBLNworICogQmFuazE6IHVzZWQgdG8gdHJhbnNmZXIgZXJyb3IgaW5mbyB0byBndWVz
dAorICovCisjZGVmaW5lIEdVRVNUX01DX0JBTktfTlVNIDIKKworLyoKKyAqIE1DR19TRVJfUDog
IHNvZnR3YXJlIGVycm9yIHJlY292ZXJ5IHN1cHBvcnRlZAorICogTUNHX1RFU19QOiAgdG8gYXZv
aWQgTUNpX3N0YXR1cyBiaXQ1Njo1MyBtb2RlbCBzcGVjaWZpYworICogTUNHX0NNQ0lfUDogZXhw
b3NlIENNQ0kgY2FwYWJpbGl0eSBidXQgbmV2ZXIgcmVhbGx5IGluamVjdCBpdCB0byBndWVzdCwK
KyAqICAgICAgICAgICAgIGZvciBzYWtlIG9mIHBlcmZvcm1hbmNlIHNpbmNlIGd1ZXN0IG5vdCBw
b2xsaW5nIHBlcmlvZGljYWxseQorICovCisjZGVmaW5lIElOVEVMX0dVRVNUX01DR19DQVAgKE1D
R19TRVJfUCB8CVwKKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgTUNHX1RFU19QIHwJXAor
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBNQ0dfQ01DSV9QIHwJXAorICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICBHVUVTVF9NQ19CQU5LX05VTSkKKworI2RlZmluZSBBTURfR1VFU1Rf
TUNHX0NBUCAoTUNHX1NFUl9QIHwJCVwKKyAgICAgICAgICAgICAgICAgICAgICAgICAgIEdVRVNU
X01DX0JBTktfTlVNKQorCisvKiBGaWx0ZXIgTVNDT0QgbW9kZWwgc3BlY2lmaWMgZXJyb3IgY29k
ZSB0byBndWVzdCAqLworI2RlZmluZSBNQ2lfU1RBVFVTX01TQ09EX01BU0sgKH4oMHhmZmZmVUxM
IDw8IDE2KSkKKworLyogTm8gbWNpX2N0bCBzaW5jZSBpdCBzdGljayBhbGwgMSdzICovCitzdHJ1
Y3Qgdm1jZV9iYW5rIHsKICAgICB1aW50NjRfdCBtY2lfc3RhdHVzOwogICAgIHVpbnQ2NF90IG1j
aV9hZGRyOwogICAgIHVpbnQ2NF90IG1jaV9taXNjOworICAgIHVpbnQ2NF90IG1jaV9jdGwyOwog
fTsKIAotc3RydWN0IGRvbWFpbl9tY2FfbXNycwotewotICAgIC8qIEd1ZXN0IHNob3VsZCBub3Qg
Y2hhbmdlIGJlbG93IHZhbHVlcyBhZnRlciBET00gYm9vdCB1cCAqLworLyogTm8gbWNnX2N0bCBz
aW5jZSBpdCBub3QgZXhwb3NlIHRvIGd1ZXN0ICovCitzdHJ1Y3Qgdm1jZSB7CisgICAgdWludDY0
X3QgbWNnX2NhcDsKICAgICB1aW50NjRfdCBtY2dfc3RhdHVzOwotICAgIHVpbnQxNl90IG5yX2lu
amVjdGlvbjsKLSAgICBzdHJ1Y3QgbGlzdF9oZWFkIGltcGFjdF9oZWFkZXI7CisgICAgc3RydWN0
IHZtY2VfYmFuayBiYW5rW0dVRVNUX01DX0JBTktfTlVNXTsKKwogICAgIHNwaW5sb2NrX3QgbG9j
azsKIH07CiAKIC8qIEd1ZXN0IHZNQ0UgTVNScyB2aXJ0dWFsaXphdGlvbiAqLwotZXh0ZXJuIGlu
dCB2bWNlX2luaXRfbXNyKHN0cnVjdCBkb21haW4gKmQpOwotZXh0ZXJuIHZvaWQgdm1jZV9kZXN0
cm95X21zcihzdHJ1Y3QgZG9tYWluICpkKTsKIGV4dGVybiB2b2lkIHZtY2VfaW5pdF92Y3B1KHN0
cnVjdCB2Y3B1ICopOwogZXh0ZXJuIGludCB2bWNlX3Jlc3RvcmVfdmNwdShzdHJ1Y3QgdmNwdSAq
LCB1aW50NjRfdCBjYXBzKTsKIGV4dGVybiBpbnQgdm1jZV93cm1zcih1aW50MzJfdCBtc3IsIHVp
bnQ2NF90IHZhbCk7Cg==

--_002_DE8DF0795D48FD4CA783C40EC829233532F3E2SHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 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_DE8DF0795D48FD4CA783C40EC829233532F3E2SHSMSX101ccrcorpi_--


From xen-devel-bounces@lists.xen.org Tue Sep 18 13:14:29 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Sep 2012 13:14:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDxcz-0005IY-LC; Tue, 18 Sep 2012 13:14:13 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jinsong.liu@intel.com>) id 1TDxcx-0005IC-QF
	for xen-devel@lists.xensource.com; Tue, 18 Sep 2012 13:14:12 +0000
Received: from [85.158.137.99:64210] by server-12.bemta-3.messagelabs.com id
	6D/3E-10384-3A378505; Tue, 18 Sep 2012 13:14:11 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-13.tower-217.messagelabs.com!1347974049!18179947!1
X-Originating-IP: [134.134.136.20]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjAgPT4gMjk5NTk2\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30670 invoked from network); 18 Sep 2012 13:14:09 -0000
Received: from mga02.intel.com (HELO mga02.intel.com) (134.134.136.20)
	by server-13.tower-217.messagelabs.com with SMTP;
	18 Sep 2012 13:14:09 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga101.jf.intel.com with ESMTP; 18 Sep 2012 06:14:08 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.80,442,1344236400"; d="scan'208";a="206967420"
Received: from fmsmsx106.amr.corp.intel.com ([10.19.9.37])
	by orsmga002.jf.intel.com with ESMTP; 18 Sep 2012 06:14:07 -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, 18 Sep 2012 06:14:07 -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; Tue, 18 Sep 2012 06:14:07 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.239]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.175]) with mapi id
	14.01.0355.002; Tue, 18 Sep 2012 21:14:05 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: Jan Beulich <JBeulich@suse.com>, "xen-devel@lists.xensource.com"
	<xen-devel@lists.xensource.com>
Thread-Topic: [PATCH 2/5] Xen/MCE: vMCE injection
Thread-Index: Ac2Vn3o8F+calZQiQdes1pO9ZErXcw==
Date: Tue, 18 Sep 2012 13:14:04 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC829233532F3F8@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_DE8DF0795D48FD4CA783C40EC829233532F3F8SHSMSX101ccrcorpi_"
MIME-Version: 1.0
Cc: "keir@xen.org" <keir@xen.org>,
	"Ian.Campbell@citrix.com" <Ian.Campbell@citrix.com>
Subject: [Xen-devel] [PATCH 2/5] Xen/MCE: vMCE injection
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--_002_DE8DF0795D48FD4CA783C40EC829233532F3F8SHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Xen/MCE: vMCE injection

In our test for win8 guest mce, we find a bug 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.

Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>

diff -r 133664c6bfb4 xen/arch/x86/cpu/mcheck/vmce.c
--- a/xen/arch/x86/cpu/mcheck/vmce.c	Tue Sep 18 22:39:11 2012 +0800
+++ b/xen/arch/x86/cpu/mcheck/vmce.c	Tue Sep 18 23:46:38 2012 +0800
@@ -340,48 +340,27 @@
=20
 int inject_vmce(struct domain *d)
 {
-    int cpu =3D smp_processor_id();
+    struct vcpu *v;
=20
-    /* PV guest and HVM guest have different vMCE# injection methods. */
-    if ( !test_and_set_bool(d->vcpu[0]->mce_pending) )
+    /* inject vMCE to all vcpus */
+    for_each_vcpu(d, v)
     {
-        if ( d->is_hvm )
+        if ( !test_and_set_bool(v->mce_pending) &&
+            ((d->is_hvm) ||
+                guest_has_trap_callback(d, v->vcpu_id, TRAP_machine_check)=
) )
         {
-            mce_printk(MCE_VERBOSE, "MCE: inject vMCE to HVM DOM %d\n",
-                       d->domain_id);
-            vcpu_kick(d->vcpu[0]);
+            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_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);
-            }
+            mce_printk(MCE_QUIET, "Fail to inject vMCE to dom%d vcpu%d\n",
+                       d->domain_id, v->vcpu_id);
+            return -1;
         }
     }
-    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;
 }
 =

--_002_DE8DF0795D48FD4CA783C40EC829233532F3F8SHSMSX101ccrcorpi_
Content-Type: application/octet-stream; name="2_vmce_injection.patch"
Content-Description: 2_vmce_injection.patch
Content-Disposition: attachment; filename="2_vmce_injection.patch"; size=2793;
	creation-date="Tue, 18 Sep 2012 13:04:35 GMT";
	modification-date="Tue, 18 Sep 2012 20:50:12 GMT"
Content-Transfer-Encoding: base64

WGVuL01DRTogdk1DRSBpbmplY3Rpb24KCkluIG91ciB0ZXN0IGZvciB3aW44IGd1ZXN0IG1jZSwg
d2UgZmluZCBhIGJ1ZyB0aGF0IG5vIG1hdHRlciB3aGF0IFNSQU8vU1JBUgplcnJvciB4ZW4gaW5q
ZWN0IHRvIHdpbjggZ3Vlc3QsIGl0IGFsd2F5cyByZWJvb3QuCgpUaGUgcm9vdCBjYXVzZSBpcywg
Y3VycmVudCBYZW4gdk1DRSBsb2dpYyBpbmplY3Qgdk1DRSMgb25seSB0byB2Y3B1MCwgdGhpcyBp
cwpub3QgY29ycmVjdCBmb3IgSW50ZWwgTUNFIChVbmRlciBJbnRlbCBhcmNoLCBoL3cgZ2VuZXJh
dGUgTUNFIyB0byBhbGwgQ1BVcykuCgpUaGlzIHBhdGNoIGZpeCB2TUNFIGluamVjdGlvbiBidWcs
IGluamVjdGluZyB2TUNFIyB0byBhbGwgdmNwdXMuCgpTaWduZWQtb2ZmLWJ5OiBMaXUsIEppbnNv
bmcgPGppbnNvbmcubGl1QGludGVsLmNvbT4KCmRpZmYgLXIgMTMzNjY0YzZiZmI0IHhlbi9hcmNo
L3g4Ni9jcHUvbWNoZWNrL3ZtY2UuYwotLS0gYS94ZW4vYXJjaC94ODYvY3B1L21jaGVjay92bWNl
LmMJVHVlIFNlcCAxOCAyMjozOToxMSAyMDEyICswODAwCisrKyBiL3hlbi9hcmNoL3g4Ni9jcHUv
bWNoZWNrL3ZtY2UuYwlUdWUgU2VwIDE4IDIzOjQ2OjM4IDIwMTIgKzA4MDAKQEAgLTM0MCw0OCAr
MzQwLDI3IEBACiAKIGludCBpbmplY3Rfdm1jZShzdHJ1Y3QgZG9tYWluICpkKQogewotICAgIGlu
dCBjcHUgPSBzbXBfcHJvY2Vzc29yX2lkKCk7CisgICAgc3RydWN0IHZjcHUgKnY7CiAKLSAgICAv
KiBQViBndWVzdCBhbmQgSFZNIGd1ZXN0IGhhdmUgZGlmZmVyZW50IHZNQ0UjIGluamVjdGlvbiBt
ZXRob2RzLiAqLwotICAgIGlmICggIXRlc3RfYW5kX3NldF9ib29sKGQtPnZjcHVbMF0tPm1jZV9w
ZW5kaW5nKSApCisgICAgLyogaW5qZWN0IHZNQ0UgdG8gYWxsIHZjcHVzICovCisgICAgZm9yX2Vh
Y2hfdmNwdShkLCB2KQogICAgIHsKLSAgICAgICAgaWYgKCBkLT5pc19odm0gKQorICAgICAgICBp
ZiAoICF0ZXN0X2FuZF9zZXRfYm9vbCh2LT5tY2VfcGVuZGluZykgJiYKKyAgICAgICAgICAgICgo
ZC0+aXNfaHZtKSB8fAorICAgICAgICAgICAgICAgIGd1ZXN0X2hhc190cmFwX2NhbGxiYWNrKGQs
IHYtPnZjcHVfaWQsIFRSQVBfbWFjaGluZV9jaGVjaykpICkKICAgICAgICAgewotICAgICAgICAg
ICAgbWNlX3ByaW50ayhNQ0VfVkVSQk9TRSwgIk1DRTogaW5qZWN0IHZNQ0UgdG8gSFZNIERPTSAl
ZFxuIiwKLSAgICAgICAgICAgICAgICAgICAgICAgZC0+ZG9tYWluX2lkKTsKLSAgICAgICAgICAg
IHZjcHVfa2ljayhkLT52Y3B1WzBdKTsKKyAgICAgICAgICAgIG1jZV9wcmludGsoTUNFX1ZFUkJP
U0UsICJNQ0U6IGluamVjdCB2TUNFIHRvIGRvbSVkIHZjcHUlZFxuIiwKKyAgICAgICAgICAgICAg
ICAgICAgICAgZC0+ZG9tYWluX2lkLCB2LT52Y3B1X2lkKTsKKyAgICAgICAgICAgIHZjcHVfa2lj
ayh2KTsKICAgICAgICAgfQogICAgICAgICBlbHNlCiAgICAgICAgIHsKLSAgICAgICAgICAgIG1j
ZV9wcmludGsoTUNFX1ZFUkJPU0UsICJNQ0U6IGluamVjdCB2TUNFIHRvIFBWIERPTSVkXG4iLAot
ICAgICAgICAgICAgICAgICAgICAgICBkLT5kb21haW5faWQpOwotICAgICAgICAgICAgaWYgKCBn
dWVzdF9oYXNfdHJhcF9jYWxsYmFjayhkLCAwLCBUUkFQX21hY2hpbmVfY2hlY2spICkKLSAgICAg
ICAgICAgIHsKLSAgICAgICAgICAgICAgICBjcHVtYXNrX2NvcHkoZC0+dmNwdVswXS0+Y3B1X2Fm
ZmluaXR5X3RtcCwKLSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgZC0+dmNwdVswXS0+Y3B1
X2FmZmluaXR5KTsKLSAgICAgICAgICAgICAgICBtY2VfcHJpbnRrKE1DRV9WRVJCT1NFLCAiTUNF
OiBDUFUlZCBzZXQgYWZmaW5pdHksIG9sZCAlZFxuIiwKLSAgICAgICAgICAgICAgICAgICAgICAg
ICAgIGNwdSwgZC0+dmNwdVswXS0+cHJvY2Vzc29yKTsKLSAgICAgICAgICAgICAgICB2Y3B1X3Nl
dF9hZmZpbml0eShkLT52Y3B1WzBdLCBjcHVtYXNrX29mKGNwdSkpOwotICAgICAgICAgICAgICAg
IHZjcHVfa2ljayhkLT52Y3B1WzBdKTsKLSAgICAgICAgICAgIH0KLSAgICAgICAgICAgIGVsc2UK
LSAgICAgICAgICAgIHsKLSAgICAgICAgICAgICAgICBtY2VfcHJpbnRrKE1DRV9WRVJCT1NFLAot
ICAgICAgICAgICAgICAgICAgICAgICAgICAgIk1DRTogS2lsbCBQViBndWVzdCB3aXRoIE5vIE1D
RSBoYW5kbGVyXG4iKTsKLSAgICAgICAgICAgICAgICBkb21haW5fY3Jhc2goZCk7Ci0gICAgICAg
ICAgICB9CisgICAgICAgICAgICBtY2VfcHJpbnRrKE1DRV9RVUlFVCwgIkZhaWwgdG8gaW5qZWN0
IHZNQ0UgdG8gZG9tJWQgdmNwdSVkXG4iLAorICAgICAgICAgICAgICAgICAgICAgICBkLT5kb21h
aW5faWQsIHYtPnZjcHVfaWQpOworICAgICAgICAgICAgcmV0dXJuIC0xOwogICAgICAgICB9CiAg
ICAgfQotICAgIGVsc2UKLSAgICB7Ci0gICAgICAgIC8qIG5ldyB2TUNFIGNvbWVzIHdoaWxlIGZp
cnN0IG9uZSBoYXMgbm90IGJlZW4gaW5qZWN0ZWQgeWV0LAotICAgICAgICAgKiBpbiB0aGlzIGNh
c2UsIGluamVjdCBmYWlsLiBbV2UgY2FuJ3QgbG9zZSB0aGlzIHZNQ0UgZm9yCi0gICAgICAgICAq
IHRoZSBtY2Ugbm9kZSdzIGNvbnNpc3RlbmN5XS4KLSAgICAgICAgICovCi0gICAgICAgIG1jZV9w
cmludGsoTUNFX1FVSUVULCAiVGhlcmUncyBhIHBlbmRpbmcgdk1DRSB3YWl0aW5nIHRvIGJlIGlu
amVjdGVkICIKLSAgICAgICAgICAgICAgICAgICAiIHRvIHRoaXMgRE9NJWQhXG4iLCBkLT5kb21h
aW5faWQpOwotICAgICAgICByZXR1cm4gLTE7Ci0gICAgfQorCiAgICAgcmV0dXJuIDA7CiB9CiAK

--_002_DE8DF0795D48FD4CA783C40EC829233532F3F8SHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 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_DE8DF0795D48FD4CA783C40EC829233532F3F8SHSMSX101ccrcorpi_--


From xen-devel-bounces@lists.xen.org Tue Sep 18 13:14:29 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Sep 2012 13:14:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDxcz-0005IY-LC; Tue, 18 Sep 2012 13:14:13 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jinsong.liu@intel.com>) id 1TDxcx-0005IC-QF
	for xen-devel@lists.xensource.com; Tue, 18 Sep 2012 13:14:12 +0000
Received: from [85.158.137.99:64210] by server-12.bemta-3.messagelabs.com id
	6D/3E-10384-3A378505; Tue, 18 Sep 2012 13:14:11 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-13.tower-217.messagelabs.com!1347974049!18179947!1
X-Originating-IP: [134.134.136.20]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjAgPT4gMjk5NTk2\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30670 invoked from network); 18 Sep 2012 13:14:09 -0000
Received: from mga02.intel.com (HELO mga02.intel.com) (134.134.136.20)
	by server-13.tower-217.messagelabs.com with SMTP;
	18 Sep 2012 13:14:09 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga101.jf.intel.com with ESMTP; 18 Sep 2012 06:14:08 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.80,442,1344236400"; d="scan'208";a="206967420"
Received: from fmsmsx106.amr.corp.intel.com ([10.19.9.37])
	by orsmga002.jf.intel.com with ESMTP; 18 Sep 2012 06:14:07 -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, 18 Sep 2012 06:14:07 -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; Tue, 18 Sep 2012 06:14:07 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.239]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.175]) with mapi id
	14.01.0355.002; Tue, 18 Sep 2012 21:14:05 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: Jan Beulich <JBeulich@suse.com>, "xen-devel@lists.xensource.com"
	<xen-devel@lists.xensource.com>
Thread-Topic: [PATCH 2/5] Xen/MCE: vMCE injection
Thread-Index: Ac2Vn3o8F+calZQiQdes1pO9ZErXcw==
Date: Tue, 18 Sep 2012 13:14:04 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC829233532F3F8@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_DE8DF0795D48FD4CA783C40EC829233532F3F8SHSMSX101ccrcorpi_"
MIME-Version: 1.0
Cc: "keir@xen.org" <keir@xen.org>,
	"Ian.Campbell@citrix.com" <Ian.Campbell@citrix.com>
Subject: [Xen-devel] [PATCH 2/5] Xen/MCE: vMCE injection
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--_002_DE8DF0795D48FD4CA783C40EC829233532F3F8SHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Xen/MCE: vMCE injection

In our test for win8 guest mce, we find a bug 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.

Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>

diff -r 133664c6bfb4 xen/arch/x86/cpu/mcheck/vmce.c
--- a/xen/arch/x86/cpu/mcheck/vmce.c	Tue Sep 18 22:39:11 2012 +0800
+++ b/xen/arch/x86/cpu/mcheck/vmce.c	Tue Sep 18 23:46:38 2012 +0800
@@ -340,48 +340,27 @@
=20
 int inject_vmce(struct domain *d)
 {
-    int cpu =3D smp_processor_id();
+    struct vcpu *v;
=20
-    /* PV guest and HVM guest have different vMCE# injection methods. */
-    if ( !test_and_set_bool(d->vcpu[0]->mce_pending) )
+    /* inject vMCE to all vcpus */
+    for_each_vcpu(d, v)
     {
-        if ( d->is_hvm )
+        if ( !test_and_set_bool(v->mce_pending) &&
+            ((d->is_hvm) ||
+                guest_has_trap_callback(d, v->vcpu_id, TRAP_machine_check)=
) )
         {
-            mce_printk(MCE_VERBOSE, "MCE: inject vMCE to HVM DOM %d\n",
-                       d->domain_id);
-            vcpu_kick(d->vcpu[0]);
+            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_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);
-            }
+            mce_printk(MCE_QUIET, "Fail to inject vMCE to dom%d vcpu%d\n",
+                       d->domain_id, v->vcpu_id);
+            return -1;
         }
     }
-    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;
 }
 =

--_002_DE8DF0795D48FD4CA783C40EC829233532F3F8SHSMSX101ccrcorpi_
Content-Type: application/octet-stream; name="2_vmce_injection.patch"
Content-Description: 2_vmce_injection.patch
Content-Disposition: attachment; filename="2_vmce_injection.patch"; size=2793;
	creation-date="Tue, 18 Sep 2012 13:04:35 GMT";
	modification-date="Tue, 18 Sep 2012 20:50:12 GMT"
Content-Transfer-Encoding: base64

WGVuL01DRTogdk1DRSBpbmplY3Rpb24KCkluIG91ciB0ZXN0IGZvciB3aW44IGd1ZXN0IG1jZSwg
d2UgZmluZCBhIGJ1ZyB0aGF0IG5vIG1hdHRlciB3aGF0IFNSQU8vU1JBUgplcnJvciB4ZW4gaW5q
ZWN0IHRvIHdpbjggZ3Vlc3QsIGl0IGFsd2F5cyByZWJvb3QuCgpUaGUgcm9vdCBjYXVzZSBpcywg
Y3VycmVudCBYZW4gdk1DRSBsb2dpYyBpbmplY3Qgdk1DRSMgb25seSB0byB2Y3B1MCwgdGhpcyBp
cwpub3QgY29ycmVjdCBmb3IgSW50ZWwgTUNFIChVbmRlciBJbnRlbCBhcmNoLCBoL3cgZ2VuZXJh
dGUgTUNFIyB0byBhbGwgQ1BVcykuCgpUaGlzIHBhdGNoIGZpeCB2TUNFIGluamVjdGlvbiBidWcs
IGluamVjdGluZyB2TUNFIyB0byBhbGwgdmNwdXMuCgpTaWduZWQtb2ZmLWJ5OiBMaXUsIEppbnNv
bmcgPGppbnNvbmcubGl1QGludGVsLmNvbT4KCmRpZmYgLXIgMTMzNjY0YzZiZmI0IHhlbi9hcmNo
L3g4Ni9jcHUvbWNoZWNrL3ZtY2UuYwotLS0gYS94ZW4vYXJjaC94ODYvY3B1L21jaGVjay92bWNl
LmMJVHVlIFNlcCAxOCAyMjozOToxMSAyMDEyICswODAwCisrKyBiL3hlbi9hcmNoL3g4Ni9jcHUv
bWNoZWNrL3ZtY2UuYwlUdWUgU2VwIDE4IDIzOjQ2OjM4IDIwMTIgKzA4MDAKQEAgLTM0MCw0OCAr
MzQwLDI3IEBACiAKIGludCBpbmplY3Rfdm1jZShzdHJ1Y3QgZG9tYWluICpkKQogewotICAgIGlu
dCBjcHUgPSBzbXBfcHJvY2Vzc29yX2lkKCk7CisgICAgc3RydWN0IHZjcHUgKnY7CiAKLSAgICAv
KiBQViBndWVzdCBhbmQgSFZNIGd1ZXN0IGhhdmUgZGlmZmVyZW50IHZNQ0UjIGluamVjdGlvbiBt
ZXRob2RzLiAqLwotICAgIGlmICggIXRlc3RfYW5kX3NldF9ib29sKGQtPnZjcHVbMF0tPm1jZV9w
ZW5kaW5nKSApCisgICAgLyogaW5qZWN0IHZNQ0UgdG8gYWxsIHZjcHVzICovCisgICAgZm9yX2Vh
Y2hfdmNwdShkLCB2KQogICAgIHsKLSAgICAgICAgaWYgKCBkLT5pc19odm0gKQorICAgICAgICBp
ZiAoICF0ZXN0X2FuZF9zZXRfYm9vbCh2LT5tY2VfcGVuZGluZykgJiYKKyAgICAgICAgICAgICgo
ZC0+aXNfaHZtKSB8fAorICAgICAgICAgICAgICAgIGd1ZXN0X2hhc190cmFwX2NhbGxiYWNrKGQs
IHYtPnZjcHVfaWQsIFRSQVBfbWFjaGluZV9jaGVjaykpICkKICAgICAgICAgewotICAgICAgICAg
ICAgbWNlX3ByaW50ayhNQ0VfVkVSQk9TRSwgIk1DRTogaW5qZWN0IHZNQ0UgdG8gSFZNIERPTSAl
ZFxuIiwKLSAgICAgICAgICAgICAgICAgICAgICAgZC0+ZG9tYWluX2lkKTsKLSAgICAgICAgICAg
IHZjcHVfa2ljayhkLT52Y3B1WzBdKTsKKyAgICAgICAgICAgIG1jZV9wcmludGsoTUNFX1ZFUkJP
U0UsICJNQ0U6IGluamVjdCB2TUNFIHRvIGRvbSVkIHZjcHUlZFxuIiwKKyAgICAgICAgICAgICAg
ICAgICAgICAgZC0+ZG9tYWluX2lkLCB2LT52Y3B1X2lkKTsKKyAgICAgICAgICAgIHZjcHVfa2lj
ayh2KTsKICAgICAgICAgfQogICAgICAgICBlbHNlCiAgICAgICAgIHsKLSAgICAgICAgICAgIG1j
ZV9wcmludGsoTUNFX1ZFUkJPU0UsICJNQ0U6IGluamVjdCB2TUNFIHRvIFBWIERPTSVkXG4iLAot
ICAgICAgICAgICAgICAgICAgICAgICBkLT5kb21haW5faWQpOwotICAgICAgICAgICAgaWYgKCBn
dWVzdF9oYXNfdHJhcF9jYWxsYmFjayhkLCAwLCBUUkFQX21hY2hpbmVfY2hlY2spICkKLSAgICAg
ICAgICAgIHsKLSAgICAgICAgICAgICAgICBjcHVtYXNrX2NvcHkoZC0+dmNwdVswXS0+Y3B1X2Fm
ZmluaXR5X3RtcCwKLSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgZC0+dmNwdVswXS0+Y3B1
X2FmZmluaXR5KTsKLSAgICAgICAgICAgICAgICBtY2VfcHJpbnRrKE1DRV9WRVJCT1NFLCAiTUNF
OiBDUFUlZCBzZXQgYWZmaW5pdHksIG9sZCAlZFxuIiwKLSAgICAgICAgICAgICAgICAgICAgICAg
ICAgIGNwdSwgZC0+dmNwdVswXS0+cHJvY2Vzc29yKTsKLSAgICAgICAgICAgICAgICB2Y3B1X3Nl
dF9hZmZpbml0eShkLT52Y3B1WzBdLCBjcHVtYXNrX29mKGNwdSkpOwotICAgICAgICAgICAgICAg
IHZjcHVfa2ljayhkLT52Y3B1WzBdKTsKLSAgICAgICAgICAgIH0KLSAgICAgICAgICAgIGVsc2UK
LSAgICAgICAgICAgIHsKLSAgICAgICAgICAgICAgICBtY2VfcHJpbnRrKE1DRV9WRVJCT1NFLAot
ICAgICAgICAgICAgICAgICAgICAgICAgICAgIk1DRTogS2lsbCBQViBndWVzdCB3aXRoIE5vIE1D
RSBoYW5kbGVyXG4iKTsKLSAgICAgICAgICAgICAgICBkb21haW5fY3Jhc2goZCk7Ci0gICAgICAg
ICAgICB9CisgICAgICAgICAgICBtY2VfcHJpbnRrKE1DRV9RVUlFVCwgIkZhaWwgdG8gaW5qZWN0
IHZNQ0UgdG8gZG9tJWQgdmNwdSVkXG4iLAorICAgICAgICAgICAgICAgICAgICAgICBkLT5kb21h
aW5faWQsIHYtPnZjcHVfaWQpOworICAgICAgICAgICAgcmV0dXJuIC0xOwogICAgICAgICB9CiAg
ICAgfQotICAgIGVsc2UKLSAgICB7Ci0gICAgICAgIC8qIG5ldyB2TUNFIGNvbWVzIHdoaWxlIGZp
cnN0IG9uZSBoYXMgbm90IGJlZW4gaW5qZWN0ZWQgeWV0LAotICAgICAgICAgKiBpbiB0aGlzIGNh
c2UsIGluamVjdCBmYWlsLiBbV2UgY2FuJ3QgbG9zZSB0aGlzIHZNQ0UgZm9yCi0gICAgICAgICAq
IHRoZSBtY2Ugbm9kZSdzIGNvbnNpc3RlbmN5XS4KLSAgICAgICAgICovCi0gICAgICAgIG1jZV9w
cmludGsoTUNFX1FVSUVULCAiVGhlcmUncyBhIHBlbmRpbmcgdk1DRSB3YWl0aW5nIHRvIGJlIGlu
amVjdGVkICIKLSAgICAgICAgICAgICAgICAgICAiIHRvIHRoaXMgRE9NJWQhXG4iLCBkLT5kb21h
aW5faWQpOwotICAgICAgICByZXR1cm4gLTE7Ci0gICAgfQorCiAgICAgcmV0dXJuIDA7CiB9CiAK

--_002_DE8DF0795D48FD4CA783C40EC829233532F3F8SHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 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_DE8DF0795D48FD4CA783C40EC829233532F3F8SHSMSX101ccrcorpi_--


From xen-devel-bounces@lists.xen.org Tue Sep 18 13:16:11 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Sep 2012 13:16:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDxeg-0005a9-QT; Tue, 18 Sep 2012 13:15:58 +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 1TDxef-0005Zo-JR
	for xen-devel@lists.xensource.com; Tue, 18 Sep 2012 13:15:58 +0000
Received: from [85.158.137.99:32882] by server-6.bemta-3.messagelabs.com id
	73/F0-29694-C0478505; Tue, 18 Sep 2012 13:15:56 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-5.tower-217.messagelabs.com!1347974153!13414427!1
X-Originating-IP: [192.55.52.88]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjg4ID0+IDMyMTY5MA==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17488 invoked from network); 18 Sep 2012 13:15:53 -0000
Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88)
	by server-5.tower-217.messagelabs.com with SMTP;
	18 Sep 2012 13:15:53 -0000
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
	by fmsmga101.fm.intel.com with ESMTP; 18 Sep 2012 06:15:52 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.80,442,1344236400"; d="scan'208";a="223479567"
Received: from fmsmsx105.amr.corp.intel.com ([10.19.9.36])
	by fmsmga001.fm.intel.com with ESMTP; 18 Sep 2012 06:15:52 -0700
Received: from fmsmsx153.amr.corp.intel.com (10.19.17.7) by
	FMSMSX105.amr.corp.intel.com (10.19.9.36) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Tue, 18 Sep 2012 06:15:51 -0700
Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by
	FMSMSX153.amr.corp.intel.com (10.19.17.7) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Tue, 18 Sep 2012 06:15:51 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.239]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.175]) with mapi id
	14.01.0355.002; Tue, 18 Sep 2012 21:15:36 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: Jan Beulich <JBeulich@suse.com>, "xen-devel@lists.xensource.com"
	<xen-devel@lists.xensource.com>
Thread-Topic: [PATCH 3/5] Xen/MCE: vMCE save and restore
Thread-Index: Ac2Vn7Bbnc+wGo+PTT+vCgnAuQIHXA==
Date: Tue, 18 Sep 2012 13:15:35 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC829233532F41B@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_DE8DF0795D48FD4CA783C40EC829233532F41BSHSMSX101ccrcorpi_"
MIME-Version: 1.0
Cc: "keir@xen.org" <keir@xen.org>,
	"Ian.Campbell@citrix.com" <Ian.Campbell@citrix.com>
Subject: [Xen-devel] [PATCH 3/5] Xen/MCE: vMCE save and restore
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<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_DE8DF0795D48FD4CA783C40EC829233532F41BSHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Xen/MCE: vMCE save and restore

This patch provide vMCE save/restore when migration.
1. MCG_CAP is well-defined. However, considering future cap extension, we k=
eep save/restore logic that Jan implement at c/s 24887;
2. MCi_CTL2 initialized by guestos when booting, so need save/restore other=
wise guest would surprise;
3. Other MSRs do not need save/restore since they are either error-related =
and pointless to save/restore, or, unified among all vMCE platform;

Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>

diff -r 1c7eae1e7d67 tools/misc/xen-hvmctx.c
--- a/tools/misc/xen-hvmctx.c	Tue Sep 18 23:46:39 2012 +0800
+++ b/tools/misc/xen-hvmctx.c	Wed Sep 19 01:21:18 2012 +0800
@@ -388,6 +388,8 @@
     HVM_SAVE_TYPE(VMCE_VCPU) p;
     READ(p);
     printf("    VMCE_VCPU: caps %" PRIx64 "\n", p.caps);
+    printf("    VMCE_VCPU: bank0 mci_ctl2 %" PRIx64 "\n", p.mci_ctl2_bank0=
);
+    printf("    VMCE_VCPU: bank1 mci_ctl2 %" PRIx64 "\n", p.mci_ctl2_bank1=
);
 }
=20
 int main(int argc, char **argv)
diff -r 1c7eae1e7d67 xen/arch/x86/cpu/mcheck/vmce.c
--- a/xen/arch/x86/cpu/mcheck/vmce.c	Tue Sep 18 23:46:39 2012 +0800
+++ b/xen/arch/x86/cpu/mcheck/vmce.c	Wed Sep 19 01:21:18 2012 +0800
@@ -55,9 +55,10 @@
     spin_lock_init(&v->arch.vmce.lock);
 }
=20
-int vmce_restore_vcpu(struct vcpu *v, uint64_t caps)
+int vmce_restore_vcpu(struct vcpu *v, struct hvm_vmce_vcpu *ctxt)
 {
     uint64_t guest_mcg_cap;
+    uint64_t caps =3D ctxt->caps;
=20
     if ( boot_cpu_data.x86_vendor =3D=3D X86_VENDOR_INTEL )
         guest_mcg_cap =3D INTEL_GUEST_MCG_CAP;
@@ -74,6 +75,9 @@
     }
=20
     v->arch.vmce.mcg_cap =3D caps;
+    v->arch.vmce.bank[0].mci_ctl2 =3D ctxt->mci_ctl2_bank0;
+    v->arch.vmce.bank[1].mci_ctl2 =3D ctxt->mci_ctl2_bank1;
+
     return 0;
 }
=20
@@ -305,7 +309,9 @@
=20
     for_each_vcpu( d, v ) {
         struct hvm_vmce_vcpu ctxt =3D {
-            .caps =3D v->arch.vmce.mcg_cap
+            .caps =3D v->arch.vmce.mcg_cap,
+            .mci_ctl2_bank0 =3D v->arch.vmce.bank[0].mci_ctl2,
+            .mci_ctl2_bank1 =3D v->arch.vmce.bank[1].mci_ctl2
         };
=20
         err =3D hvm_save_entry(VMCE_VCPU, v->vcpu_id, h, &ctxt);
@@ -330,9 +336,9 @@
         err =3D -EINVAL;
     }
     else
-        err =3D hvm_load_entry(VMCE_VCPU, h, &ctxt);
+        err =3D hvm_load_entry_zeroextend(VMCE_VCPU, h, &ctxt);
=20
-    return err ?: vmce_restore_vcpu(v, ctxt.caps);
+    return err ?: vmce_restore_vcpu(v, &ctxt);
 }
=20
 HVM_REGISTER_SAVE_RESTORE(VMCE_VCPU, vmce_save_vcpu_ctxt,
diff -r 1c7eae1e7d67 xen/arch/x86/domctl.c
--- a/xen/arch/x86/domctl.c	Tue Sep 18 23:46:39 2012 +0800
+++ b/xen/arch/x86/domctl.c	Wed Sep 19 01:21:18 2012 +0800
@@ -1024,12 +1024,14 @@
                 evc->syscall32_callback_eip    =3D 0;
                 evc->syscall32_disables_events =3D 0;
             }
-            evc->mcg_cap =3D v->arch.vmce.mcg_cap;
+            evc->vmce.caps =3D v->arch.vmce.mcg_cap;
+            evc->vmce.mci_ctl2_bank0 =3D v->arch.vmce.bank[0].mci_ctl2;
+            evc->vmce.mci_ctl2_bank1 =3D v->arch.vmce.bank[1].mci_ctl2;
         }
         else
         {
             ret =3D -EINVAL;
-            if ( evc->size < offsetof(typeof(*evc), mcg_cap) )
+            if ( evc->size < offsetof(typeof(*evc), vmce) )
                 goto ext_vcpucontext_out;
             if ( !is_hvm_domain(d) )
             {
@@ -1059,9 +1061,9 @@
                  evc->syscall32_callback_eip )
                 goto ext_vcpucontext_out;
=20
-            if ( evc->size >=3D offsetof(typeof(*evc), mcg_cap) +
-                              sizeof(evc->mcg_cap) )
-                ret =3D vmce_restore_vcpu(v, evc->mcg_cap);
+            if ( evc->size >=3D offsetof(typeof(*evc), vmce) +
+                              sizeof(evc->vmce) );
+                ret =3D vmce_restore_vcpu(v, &evc->vmce);
         }
=20
         ret =3D 0;
diff -r 1c7eae1e7d67 xen/include/asm-x86/mce.h
--- a/xen/include/asm-x86/mce.h	Tue Sep 18 23:46:39 2012 +0800
+++ b/xen/include/asm-x86/mce.h	Wed Sep 19 01:21:18 2012 +0800
@@ -48,7 +48,7 @@
=20
 /* Guest vMCE MSRs virtualization */
 extern void vmce_init_vcpu(struct vcpu *);
-extern int vmce_restore_vcpu(struct vcpu *, uint64_t caps);
+extern int vmce_restore_vcpu(struct vcpu *, struct hvm_vmce_vcpu *ctxt);
 extern int vmce_wrmsr(uint32_t msr, uint64_t val);
 extern int vmce_rdmsr(uint32_t msr, uint64_t *val);
=20
diff -r 1c7eae1e7d67 xen/include/public/arch-x86/hvm/save.h
--- a/xen/include/public/arch-x86/hvm/save.h	Tue Sep 18 23:46:39 2012 +0800
+++ b/xen/include/public/arch-x86/hvm/save.h	Wed Sep 19 01:21:18 2012 +0800
@@ -577,6 +577,8 @@
=20
 struct hvm_vmce_vcpu {
     uint64_t caps;
+    uint64_t mci_ctl2_bank0;
+    uint64_t mci_ctl2_bank1;
 };
=20
 DECLARE_HVM_SAVE_TYPE(VMCE_VCPU, 18, struct hvm_vmce_vcpu);
diff -r 1c7eae1e7d67 xen/include/public/domctl.h
--- a/xen/include/public/domctl.h	Tue Sep 18 23:46:39 2012 +0800
+++ b/xen/include/public/domctl.h	Wed Sep 19 01:21:18 2012 +0800
@@ -32,6 +32,7 @@
 #error "domctl operations are intended for use by node control tools only"
 #endif
=20
+#include <xen/hvm/save.h>
 #include "xen.h"
 #include "grant_table.h"
=20
@@ -564,7 +565,7 @@
     uint16_t         sysenter_callback_cs;
     uint8_t          syscall32_disables_events;
     uint8_t          sysenter_disables_events;
-    uint64_aligned_t mcg_cap;
+    struct hvm_vmce_vcpu vmce;
 #endif
 };
 typedef struct xen_domctl_ext_vcpucontext xen_domctl_ext_vcpucontext_t;=

--_002_DE8DF0795D48FD4CA783C40EC829233532F41BSHSMSX101ccrcorpi_
Content-Type: application/octet-stream; name="3_vmce_save_restore.patch"
Content-Description: 3_vmce_save_restore.patch
Content-Disposition: attachment; filename="3_vmce_save_restore.patch";
	size=5381; creation-date="Tue, 18 Sep 2012 13:04:35 GMT";
	modification-date="Tue, 18 Sep 2012 20:51:34 GMT"
Content-Transfer-Encoding: base64

WGVuL01DRTogdk1DRSBzYXZlIGFuZCByZXN0b3JlCgpUaGlzIHBhdGNoIHByb3ZpZGUgdk1DRSBz
YXZlL3Jlc3RvcmUgd2hlbiBtaWdyYXRpb24uCjEuIE1DR19DQVAgaXMgd2VsbC1kZWZpbmVkLiBI
b3dldmVyLCBjb25zaWRlcmluZyBmdXR1cmUgY2FwIGV4dGVuc2lvbiwgd2Uga2VlcCBzYXZlL3Jl
c3RvcmUgbG9naWMgdGhhdCBKYW4gaW1wbGVtZW50IGF0IGMvcyAyNDg4NzsKMi4gTUNpX0NUTDIg
aW5pdGlhbGl6ZWQgYnkgZ3Vlc3RvcyB3aGVuIGJvb3RpbmcsIHNvIG5lZWQgc2F2ZS9yZXN0b3Jl
IG90aGVyd2lzZSBndWVzdCB3b3VsZCBzdXJwcmlzZTsKMy4gT3RoZXIgTVNScyBkbyBub3QgbmVl
ZCBzYXZlL3Jlc3RvcmUgc2luY2UgdGhleSBhcmUgZWl0aGVyIGVycm9yLXJlbGF0ZWQgYW5kIHBv
aW50bGVzcyB0byBzYXZlL3Jlc3RvcmUsIG9yLCB1bmlmaWVkIGFtb25nIGFsbCB2TUNFIHBsYXRm
b3JtOwoKU2lnbmVkLW9mZi1ieTogTGl1LCBKaW5zb25nIDxqaW5zb25nLmxpdUBpbnRlbC5jb20+
CgpkaWZmIC1yIDFjN2VhZTFlN2Q2NyB0b29scy9taXNjL3hlbi1odm1jdHguYwotLS0gYS90b29s
cy9taXNjL3hlbi1odm1jdHguYwlUdWUgU2VwIDE4IDIzOjQ2OjM5IDIwMTIgKzA4MDAKKysrIGIv
dG9vbHMvbWlzYy94ZW4taHZtY3R4LmMJV2VkIFNlcCAxOSAwMToyMToxOCAyMDEyICswODAwCkBA
IC0zODgsNiArMzg4LDggQEAKICAgICBIVk1fU0FWRV9UWVBFKFZNQ0VfVkNQVSkgcDsKICAgICBS
RUFEKHApOwogICAgIHByaW50ZigiICAgIFZNQ0VfVkNQVTogY2FwcyAlIiBQUkl4NjQgIlxuIiwg
cC5jYXBzKTsKKyAgICBwcmludGYoIiAgICBWTUNFX1ZDUFU6IGJhbmswIG1jaV9jdGwyICUiIFBS
SXg2NCAiXG4iLCBwLm1jaV9jdGwyX2JhbmswKTsKKyAgICBwcmludGYoIiAgICBWTUNFX1ZDUFU6
IGJhbmsxIG1jaV9jdGwyICUiIFBSSXg2NCAiXG4iLCBwLm1jaV9jdGwyX2JhbmsxKTsKIH0KIAog
aW50IG1haW4oaW50IGFyZ2MsIGNoYXIgKiphcmd2KQpkaWZmIC1yIDFjN2VhZTFlN2Q2NyB4ZW4v
YXJjaC94ODYvY3B1L21jaGVjay92bWNlLmMKLS0tIGEveGVuL2FyY2gveDg2L2NwdS9tY2hlY2sv
dm1jZS5jCVR1ZSBTZXAgMTggMjM6NDY6MzkgMjAxMiArMDgwMAorKysgYi94ZW4vYXJjaC94ODYv
Y3B1L21jaGVjay92bWNlLmMJV2VkIFNlcCAxOSAwMToyMToxOCAyMDEyICswODAwCkBAIC01NSw5
ICs1NSwxMCBAQAogICAgIHNwaW5fbG9ja19pbml0KCZ2LT5hcmNoLnZtY2UubG9jayk7CiB9CiAK
LWludCB2bWNlX3Jlc3RvcmVfdmNwdShzdHJ1Y3QgdmNwdSAqdiwgdWludDY0X3QgY2FwcykKK2lu
dCB2bWNlX3Jlc3RvcmVfdmNwdShzdHJ1Y3QgdmNwdSAqdiwgc3RydWN0IGh2bV92bWNlX3ZjcHUg
KmN0eHQpCiB7CiAgICAgdWludDY0X3QgZ3Vlc3RfbWNnX2NhcDsKKyAgICB1aW50NjRfdCBjYXBz
ID0gY3R4dC0+Y2FwczsKIAogICAgIGlmICggYm9vdF9jcHVfZGF0YS54ODZfdmVuZG9yID09IFg4
Nl9WRU5ET1JfSU5URUwgKQogICAgICAgICBndWVzdF9tY2dfY2FwID0gSU5URUxfR1VFU1RfTUNH
X0NBUDsKQEAgLTc0LDYgKzc1LDkgQEAKICAgICB9CiAKICAgICB2LT5hcmNoLnZtY2UubWNnX2Nh
cCA9IGNhcHM7CisgICAgdi0+YXJjaC52bWNlLmJhbmtbMF0ubWNpX2N0bDIgPSBjdHh0LT5tY2lf
Y3RsMl9iYW5rMDsKKyAgICB2LT5hcmNoLnZtY2UuYmFua1sxXS5tY2lfY3RsMiA9IGN0eHQtPm1j
aV9jdGwyX2JhbmsxOworCiAgICAgcmV0dXJuIDA7CiB9CiAKQEAgLTMwNSw3ICszMDksOSBAQAog
CiAgICAgZm9yX2VhY2hfdmNwdSggZCwgdiApIHsKICAgICAgICAgc3RydWN0IGh2bV92bWNlX3Zj
cHUgY3R4dCA9IHsKLSAgICAgICAgICAgIC5jYXBzID0gdi0+YXJjaC52bWNlLm1jZ19jYXAKKyAg
ICAgICAgICAgIC5jYXBzID0gdi0+YXJjaC52bWNlLm1jZ19jYXAsCisgICAgICAgICAgICAubWNp
X2N0bDJfYmFuazAgPSB2LT5hcmNoLnZtY2UuYmFua1swXS5tY2lfY3RsMiwKKyAgICAgICAgICAg
IC5tY2lfY3RsMl9iYW5rMSA9IHYtPmFyY2gudm1jZS5iYW5rWzFdLm1jaV9jdGwyCiAgICAgICAg
IH07CiAKICAgICAgICAgZXJyID0gaHZtX3NhdmVfZW50cnkoVk1DRV9WQ1BVLCB2LT52Y3B1X2lk
LCBoLCAmY3R4dCk7CkBAIC0zMzAsOSArMzM2LDkgQEAKICAgICAgICAgZXJyID0gLUVJTlZBTDsK
ICAgICB9CiAgICAgZWxzZQotICAgICAgICBlcnIgPSBodm1fbG9hZF9lbnRyeShWTUNFX1ZDUFUs
IGgsICZjdHh0KTsKKyAgICAgICAgZXJyID0gaHZtX2xvYWRfZW50cnlfemVyb2V4dGVuZChWTUNF
X1ZDUFUsIGgsICZjdHh0KTsKIAotICAgIHJldHVybiBlcnIgPzogdm1jZV9yZXN0b3JlX3ZjcHUo
diwgY3R4dC5jYXBzKTsKKyAgICByZXR1cm4gZXJyID86IHZtY2VfcmVzdG9yZV92Y3B1KHYsICZj
dHh0KTsKIH0KIAogSFZNX1JFR0lTVEVSX1NBVkVfUkVTVE9SRShWTUNFX1ZDUFUsIHZtY2Vfc2F2
ZV92Y3B1X2N0eHQsCmRpZmYgLXIgMWM3ZWFlMWU3ZDY3IHhlbi9hcmNoL3g4Ni9kb21jdGwuYwot
LS0gYS94ZW4vYXJjaC94ODYvZG9tY3RsLmMJVHVlIFNlcCAxOCAyMzo0NjozOSAyMDEyICswODAw
CisrKyBiL3hlbi9hcmNoL3g4Ni9kb21jdGwuYwlXZWQgU2VwIDE5IDAxOjIxOjE4IDIwMTIgKzA4
MDAKQEAgLTEwMjQsMTIgKzEwMjQsMTQgQEAKICAgICAgICAgICAgICAgICBldmMtPnN5c2NhbGwz
Ml9jYWxsYmFja19laXAgICAgPSAwOwogICAgICAgICAgICAgICAgIGV2Yy0+c3lzY2FsbDMyX2Rp
c2FibGVzX2V2ZW50cyA9IDA7CiAgICAgICAgICAgICB9Ci0gICAgICAgICAgICBldmMtPm1jZ19j
YXAgPSB2LT5hcmNoLnZtY2UubWNnX2NhcDsKKyAgICAgICAgICAgIGV2Yy0+dm1jZS5jYXBzID0g
di0+YXJjaC52bWNlLm1jZ19jYXA7CisgICAgICAgICAgICBldmMtPnZtY2UubWNpX2N0bDJfYmFu
azAgPSB2LT5hcmNoLnZtY2UuYmFua1swXS5tY2lfY3RsMjsKKyAgICAgICAgICAgIGV2Yy0+dm1j
ZS5tY2lfY3RsMl9iYW5rMSA9IHYtPmFyY2gudm1jZS5iYW5rWzFdLm1jaV9jdGwyOwogICAgICAg
ICB9CiAgICAgICAgIGVsc2UKICAgICAgICAgewogICAgICAgICAgICAgcmV0ID0gLUVJTlZBTDsK
LSAgICAgICAgICAgIGlmICggZXZjLT5zaXplIDwgb2Zmc2V0b2YodHlwZW9mKCpldmMpLCBtY2df
Y2FwKSApCisgICAgICAgICAgICBpZiAoIGV2Yy0+c2l6ZSA8IG9mZnNldG9mKHR5cGVvZigqZXZj
KSwgdm1jZSkgKQogICAgICAgICAgICAgICAgIGdvdG8gZXh0X3ZjcHVjb250ZXh0X291dDsKICAg
ICAgICAgICAgIGlmICggIWlzX2h2bV9kb21haW4oZCkgKQogICAgICAgICAgICAgewpAQCAtMTA1
OSw5ICsxMDYxLDkgQEAKICAgICAgICAgICAgICAgICAgZXZjLT5zeXNjYWxsMzJfY2FsbGJhY2tf
ZWlwICkKICAgICAgICAgICAgICAgICBnb3RvIGV4dF92Y3B1Y29udGV4dF9vdXQ7CiAKLSAgICAg
ICAgICAgIGlmICggZXZjLT5zaXplID49IG9mZnNldG9mKHR5cGVvZigqZXZjKSwgbWNnX2NhcCkg
KwotICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgc2l6ZW9mKGV2Yy0+bWNnX2NhcCkgKQot
ICAgICAgICAgICAgICAgIHJldCA9IHZtY2VfcmVzdG9yZV92Y3B1KHYsIGV2Yy0+bWNnX2NhcCk7
CisgICAgICAgICAgICBpZiAoIGV2Yy0+c2l6ZSA+PSBvZmZzZXRvZih0eXBlb2YoKmV2YyksIHZt
Y2UpICsKKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHNpemVvZihldmMtPnZtY2UpICk7
CisgICAgICAgICAgICAgICAgcmV0ID0gdm1jZV9yZXN0b3JlX3ZjcHUodiwgJmV2Yy0+dm1jZSk7
CiAgICAgICAgIH0KIAogICAgICAgICByZXQgPSAwOwpkaWZmIC1yIDFjN2VhZTFlN2Q2NyB4ZW4v
aW5jbHVkZS9hc20teDg2L21jZS5oCi0tLSBhL3hlbi9pbmNsdWRlL2FzbS14ODYvbWNlLmgJVHVl
IFNlcCAxOCAyMzo0NjozOSAyMDEyICswODAwCisrKyBiL3hlbi9pbmNsdWRlL2FzbS14ODYvbWNl
LmgJV2VkIFNlcCAxOSAwMToyMToxOCAyMDEyICswODAwCkBAIC00OCw3ICs0OCw3IEBACiAKIC8q
IEd1ZXN0IHZNQ0UgTVNScyB2aXJ0dWFsaXphdGlvbiAqLwogZXh0ZXJuIHZvaWQgdm1jZV9pbml0
X3ZjcHUoc3RydWN0IHZjcHUgKik7Ci1leHRlcm4gaW50IHZtY2VfcmVzdG9yZV92Y3B1KHN0cnVj
dCB2Y3B1ICosIHVpbnQ2NF90IGNhcHMpOworZXh0ZXJuIGludCB2bWNlX3Jlc3RvcmVfdmNwdShz
dHJ1Y3QgdmNwdSAqLCBzdHJ1Y3QgaHZtX3ZtY2VfdmNwdSAqY3R4dCk7CiBleHRlcm4gaW50IHZt
Y2Vfd3Jtc3IodWludDMyX3QgbXNyLCB1aW50NjRfdCB2YWwpOwogZXh0ZXJuIGludCB2bWNlX3Jk
bXNyKHVpbnQzMl90IG1zciwgdWludDY0X3QgKnZhbCk7CiAKZGlmZiAtciAxYzdlYWUxZTdkNjcg
eGVuL2luY2x1ZGUvcHVibGljL2FyY2gteDg2L2h2bS9zYXZlLmgKLS0tIGEveGVuL2luY2x1ZGUv
cHVibGljL2FyY2gteDg2L2h2bS9zYXZlLmgJVHVlIFNlcCAxOCAyMzo0NjozOSAyMDEyICswODAw
CisrKyBiL3hlbi9pbmNsdWRlL3B1YmxpYy9hcmNoLXg4Ni9odm0vc2F2ZS5oCVdlZCBTZXAgMTkg
MDE6MjE6MTggMjAxMiArMDgwMApAQCAtNTc3LDYgKzU3Nyw4IEBACiAKIHN0cnVjdCBodm1fdm1j
ZV92Y3B1IHsKICAgICB1aW50NjRfdCBjYXBzOworICAgIHVpbnQ2NF90IG1jaV9jdGwyX2Jhbmsw
OworICAgIHVpbnQ2NF90IG1jaV9jdGwyX2JhbmsxOwogfTsKIAogREVDTEFSRV9IVk1fU0FWRV9U
WVBFKFZNQ0VfVkNQVSwgMTgsIHN0cnVjdCBodm1fdm1jZV92Y3B1KTsKZGlmZiAtciAxYzdlYWUx
ZTdkNjcgeGVuL2luY2x1ZGUvcHVibGljL2RvbWN0bC5oCi0tLSBhL3hlbi9pbmNsdWRlL3B1Ymxp
Yy9kb21jdGwuaAlUdWUgU2VwIDE4IDIzOjQ2OjM5IDIwMTIgKzA4MDAKKysrIGIveGVuL2luY2x1
ZGUvcHVibGljL2RvbWN0bC5oCVdlZCBTZXAgMTkgMDE6MjE6MTggMjAxMiArMDgwMApAQCAtMzIs
NiArMzIsNyBAQAogI2Vycm9yICJkb21jdGwgb3BlcmF0aW9ucyBhcmUgaW50ZW5kZWQgZm9yIHVz
ZSBieSBub2RlIGNvbnRyb2wgdG9vbHMgb25seSIKICNlbmRpZgogCisjaW5jbHVkZSA8eGVuL2h2
bS9zYXZlLmg+CiAjaW5jbHVkZSAieGVuLmgiCiAjaW5jbHVkZSAiZ3JhbnRfdGFibGUuaCIKIApA
QCAtNTY0LDcgKzU2NSw3IEBACiAgICAgdWludDE2X3QgICAgICAgICBzeXNlbnRlcl9jYWxsYmFj
a19jczsKICAgICB1aW50OF90ICAgICAgICAgIHN5c2NhbGwzMl9kaXNhYmxlc19ldmVudHM7CiAg
ICAgdWludDhfdCAgICAgICAgICBzeXNlbnRlcl9kaXNhYmxlc19ldmVudHM7Ci0gICAgdWludDY0
X2FsaWduZWRfdCBtY2dfY2FwOworICAgIHN0cnVjdCBodm1fdm1jZV92Y3B1IHZtY2U7CiAjZW5k
aWYKIH07CiB0eXBlZGVmIHN0cnVjdCB4ZW5fZG9tY3RsX2V4dF92Y3B1Y29udGV4dCB4ZW5fZG9t
Y3RsX2V4dF92Y3B1Y29udGV4dF90Owo=

--_002_DE8DF0795D48FD4CA783C40EC829233532F41BSHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 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_DE8DF0795D48FD4CA783C40EC829233532F41BSHSMSX101ccrcorpi_--


From xen-devel-bounces@lists.xen.org Tue Sep 18 13:16:11 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Sep 2012 13:16:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDxeg-0005a9-QT; Tue, 18 Sep 2012 13:15:58 +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 1TDxef-0005Zo-JR
	for xen-devel@lists.xensource.com; Tue, 18 Sep 2012 13:15:58 +0000
Received: from [85.158.137.99:32882] by server-6.bemta-3.messagelabs.com id
	73/F0-29694-C0478505; Tue, 18 Sep 2012 13:15:56 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-5.tower-217.messagelabs.com!1347974153!13414427!1
X-Originating-IP: [192.55.52.88]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjg4ID0+IDMyMTY5MA==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17488 invoked from network); 18 Sep 2012 13:15:53 -0000
Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88)
	by server-5.tower-217.messagelabs.com with SMTP;
	18 Sep 2012 13:15:53 -0000
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
	by fmsmga101.fm.intel.com with ESMTP; 18 Sep 2012 06:15:52 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.80,442,1344236400"; d="scan'208";a="223479567"
Received: from fmsmsx105.amr.corp.intel.com ([10.19.9.36])
	by fmsmga001.fm.intel.com with ESMTP; 18 Sep 2012 06:15:52 -0700
Received: from fmsmsx153.amr.corp.intel.com (10.19.17.7) by
	FMSMSX105.amr.corp.intel.com (10.19.9.36) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Tue, 18 Sep 2012 06:15:51 -0700
Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by
	FMSMSX153.amr.corp.intel.com (10.19.17.7) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Tue, 18 Sep 2012 06:15:51 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.239]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.175]) with mapi id
	14.01.0355.002; Tue, 18 Sep 2012 21:15:36 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: Jan Beulich <JBeulich@suse.com>, "xen-devel@lists.xensource.com"
	<xen-devel@lists.xensource.com>
Thread-Topic: [PATCH 3/5] Xen/MCE: vMCE save and restore
Thread-Index: Ac2Vn7Bbnc+wGo+PTT+vCgnAuQIHXA==
Date: Tue, 18 Sep 2012 13:15:35 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC829233532F41B@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_DE8DF0795D48FD4CA783C40EC829233532F41BSHSMSX101ccrcorpi_"
MIME-Version: 1.0
Cc: "keir@xen.org" <keir@xen.org>,
	"Ian.Campbell@citrix.com" <Ian.Campbell@citrix.com>
Subject: [Xen-devel] [PATCH 3/5] Xen/MCE: vMCE save and restore
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<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_DE8DF0795D48FD4CA783C40EC829233532F41BSHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Xen/MCE: vMCE save and restore

This patch provide vMCE save/restore when migration.
1. MCG_CAP is well-defined. However, considering future cap extension, we k=
eep save/restore logic that Jan implement at c/s 24887;
2. MCi_CTL2 initialized by guestos when booting, so need save/restore other=
wise guest would surprise;
3. Other MSRs do not need save/restore since they are either error-related =
and pointless to save/restore, or, unified among all vMCE platform;

Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>

diff -r 1c7eae1e7d67 tools/misc/xen-hvmctx.c
--- a/tools/misc/xen-hvmctx.c	Tue Sep 18 23:46:39 2012 +0800
+++ b/tools/misc/xen-hvmctx.c	Wed Sep 19 01:21:18 2012 +0800
@@ -388,6 +388,8 @@
     HVM_SAVE_TYPE(VMCE_VCPU) p;
     READ(p);
     printf("    VMCE_VCPU: caps %" PRIx64 "\n", p.caps);
+    printf("    VMCE_VCPU: bank0 mci_ctl2 %" PRIx64 "\n", p.mci_ctl2_bank0=
);
+    printf("    VMCE_VCPU: bank1 mci_ctl2 %" PRIx64 "\n", p.mci_ctl2_bank1=
);
 }
=20
 int main(int argc, char **argv)
diff -r 1c7eae1e7d67 xen/arch/x86/cpu/mcheck/vmce.c
--- a/xen/arch/x86/cpu/mcheck/vmce.c	Tue Sep 18 23:46:39 2012 +0800
+++ b/xen/arch/x86/cpu/mcheck/vmce.c	Wed Sep 19 01:21:18 2012 +0800
@@ -55,9 +55,10 @@
     spin_lock_init(&v->arch.vmce.lock);
 }
=20
-int vmce_restore_vcpu(struct vcpu *v, uint64_t caps)
+int vmce_restore_vcpu(struct vcpu *v, struct hvm_vmce_vcpu *ctxt)
 {
     uint64_t guest_mcg_cap;
+    uint64_t caps =3D ctxt->caps;
=20
     if ( boot_cpu_data.x86_vendor =3D=3D X86_VENDOR_INTEL )
         guest_mcg_cap =3D INTEL_GUEST_MCG_CAP;
@@ -74,6 +75,9 @@
     }
=20
     v->arch.vmce.mcg_cap =3D caps;
+    v->arch.vmce.bank[0].mci_ctl2 =3D ctxt->mci_ctl2_bank0;
+    v->arch.vmce.bank[1].mci_ctl2 =3D ctxt->mci_ctl2_bank1;
+
     return 0;
 }
=20
@@ -305,7 +309,9 @@
=20
     for_each_vcpu( d, v ) {
         struct hvm_vmce_vcpu ctxt =3D {
-            .caps =3D v->arch.vmce.mcg_cap
+            .caps =3D v->arch.vmce.mcg_cap,
+            .mci_ctl2_bank0 =3D v->arch.vmce.bank[0].mci_ctl2,
+            .mci_ctl2_bank1 =3D v->arch.vmce.bank[1].mci_ctl2
         };
=20
         err =3D hvm_save_entry(VMCE_VCPU, v->vcpu_id, h, &ctxt);
@@ -330,9 +336,9 @@
         err =3D -EINVAL;
     }
     else
-        err =3D hvm_load_entry(VMCE_VCPU, h, &ctxt);
+        err =3D hvm_load_entry_zeroextend(VMCE_VCPU, h, &ctxt);
=20
-    return err ?: vmce_restore_vcpu(v, ctxt.caps);
+    return err ?: vmce_restore_vcpu(v, &ctxt);
 }
=20
 HVM_REGISTER_SAVE_RESTORE(VMCE_VCPU, vmce_save_vcpu_ctxt,
diff -r 1c7eae1e7d67 xen/arch/x86/domctl.c
--- a/xen/arch/x86/domctl.c	Tue Sep 18 23:46:39 2012 +0800
+++ b/xen/arch/x86/domctl.c	Wed Sep 19 01:21:18 2012 +0800
@@ -1024,12 +1024,14 @@
                 evc->syscall32_callback_eip    =3D 0;
                 evc->syscall32_disables_events =3D 0;
             }
-            evc->mcg_cap =3D v->arch.vmce.mcg_cap;
+            evc->vmce.caps =3D v->arch.vmce.mcg_cap;
+            evc->vmce.mci_ctl2_bank0 =3D v->arch.vmce.bank[0].mci_ctl2;
+            evc->vmce.mci_ctl2_bank1 =3D v->arch.vmce.bank[1].mci_ctl2;
         }
         else
         {
             ret =3D -EINVAL;
-            if ( evc->size < offsetof(typeof(*evc), mcg_cap) )
+            if ( evc->size < offsetof(typeof(*evc), vmce) )
                 goto ext_vcpucontext_out;
             if ( !is_hvm_domain(d) )
             {
@@ -1059,9 +1061,9 @@
                  evc->syscall32_callback_eip )
                 goto ext_vcpucontext_out;
=20
-            if ( evc->size >=3D offsetof(typeof(*evc), mcg_cap) +
-                              sizeof(evc->mcg_cap) )
-                ret =3D vmce_restore_vcpu(v, evc->mcg_cap);
+            if ( evc->size >=3D offsetof(typeof(*evc), vmce) +
+                              sizeof(evc->vmce) );
+                ret =3D vmce_restore_vcpu(v, &evc->vmce);
         }
=20
         ret =3D 0;
diff -r 1c7eae1e7d67 xen/include/asm-x86/mce.h
--- a/xen/include/asm-x86/mce.h	Tue Sep 18 23:46:39 2012 +0800
+++ b/xen/include/asm-x86/mce.h	Wed Sep 19 01:21:18 2012 +0800
@@ -48,7 +48,7 @@
=20
 /* Guest vMCE MSRs virtualization */
 extern void vmce_init_vcpu(struct vcpu *);
-extern int vmce_restore_vcpu(struct vcpu *, uint64_t caps);
+extern int vmce_restore_vcpu(struct vcpu *, struct hvm_vmce_vcpu *ctxt);
 extern int vmce_wrmsr(uint32_t msr, uint64_t val);
 extern int vmce_rdmsr(uint32_t msr, uint64_t *val);
=20
diff -r 1c7eae1e7d67 xen/include/public/arch-x86/hvm/save.h
--- a/xen/include/public/arch-x86/hvm/save.h	Tue Sep 18 23:46:39 2012 +0800
+++ b/xen/include/public/arch-x86/hvm/save.h	Wed Sep 19 01:21:18 2012 +0800
@@ -577,6 +577,8 @@
=20
 struct hvm_vmce_vcpu {
     uint64_t caps;
+    uint64_t mci_ctl2_bank0;
+    uint64_t mci_ctl2_bank1;
 };
=20
 DECLARE_HVM_SAVE_TYPE(VMCE_VCPU, 18, struct hvm_vmce_vcpu);
diff -r 1c7eae1e7d67 xen/include/public/domctl.h
--- a/xen/include/public/domctl.h	Tue Sep 18 23:46:39 2012 +0800
+++ b/xen/include/public/domctl.h	Wed Sep 19 01:21:18 2012 +0800
@@ -32,6 +32,7 @@
 #error "domctl operations are intended for use by node control tools only"
 #endif
=20
+#include <xen/hvm/save.h>
 #include "xen.h"
 #include "grant_table.h"
=20
@@ -564,7 +565,7 @@
     uint16_t         sysenter_callback_cs;
     uint8_t          syscall32_disables_events;
     uint8_t          sysenter_disables_events;
-    uint64_aligned_t mcg_cap;
+    struct hvm_vmce_vcpu vmce;
 #endif
 };
 typedef struct xen_domctl_ext_vcpucontext xen_domctl_ext_vcpucontext_t;=

--_002_DE8DF0795D48FD4CA783C40EC829233532F41BSHSMSX101ccrcorpi_
Content-Type: application/octet-stream; name="3_vmce_save_restore.patch"
Content-Description: 3_vmce_save_restore.patch
Content-Disposition: attachment; filename="3_vmce_save_restore.patch";
	size=5381; creation-date="Tue, 18 Sep 2012 13:04:35 GMT";
	modification-date="Tue, 18 Sep 2012 20:51:34 GMT"
Content-Transfer-Encoding: base64

WGVuL01DRTogdk1DRSBzYXZlIGFuZCByZXN0b3JlCgpUaGlzIHBhdGNoIHByb3ZpZGUgdk1DRSBz
YXZlL3Jlc3RvcmUgd2hlbiBtaWdyYXRpb24uCjEuIE1DR19DQVAgaXMgd2VsbC1kZWZpbmVkLiBI
b3dldmVyLCBjb25zaWRlcmluZyBmdXR1cmUgY2FwIGV4dGVuc2lvbiwgd2Uga2VlcCBzYXZlL3Jl
c3RvcmUgbG9naWMgdGhhdCBKYW4gaW1wbGVtZW50IGF0IGMvcyAyNDg4NzsKMi4gTUNpX0NUTDIg
aW5pdGlhbGl6ZWQgYnkgZ3Vlc3RvcyB3aGVuIGJvb3RpbmcsIHNvIG5lZWQgc2F2ZS9yZXN0b3Jl
IG90aGVyd2lzZSBndWVzdCB3b3VsZCBzdXJwcmlzZTsKMy4gT3RoZXIgTVNScyBkbyBub3QgbmVl
ZCBzYXZlL3Jlc3RvcmUgc2luY2UgdGhleSBhcmUgZWl0aGVyIGVycm9yLXJlbGF0ZWQgYW5kIHBv
aW50bGVzcyB0byBzYXZlL3Jlc3RvcmUsIG9yLCB1bmlmaWVkIGFtb25nIGFsbCB2TUNFIHBsYXRm
b3JtOwoKU2lnbmVkLW9mZi1ieTogTGl1LCBKaW5zb25nIDxqaW5zb25nLmxpdUBpbnRlbC5jb20+
CgpkaWZmIC1yIDFjN2VhZTFlN2Q2NyB0b29scy9taXNjL3hlbi1odm1jdHguYwotLS0gYS90b29s
cy9taXNjL3hlbi1odm1jdHguYwlUdWUgU2VwIDE4IDIzOjQ2OjM5IDIwMTIgKzA4MDAKKysrIGIv
dG9vbHMvbWlzYy94ZW4taHZtY3R4LmMJV2VkIFNlcCAxOSAwMToyMToxOCAyMDEyICswODAwCkBA
IC0zODgsNiArMzg4LDggQEAKICAgICBIVk1fU0FWRV9UWVBFKFZNQ0VfVkNQVSkgcDsKICAgICBS
RUFEKHApOwogICAgIHByaW50ZigiICAgIFZNQ0VfVkNQVTogY2FwcyAlIiBQUkl4NjQgIlxuIiwg
cC5jYXBzKTsKKyAgICBwcmludGYoIiAgICBWTUNFX1ZDUFU6IGJhbmswIG1jaV9jdGwyICUiIFBS
SXg2NCAiXG4iLCBwLm1jaV9jdGwyX2JhbmswKTsKKyAgICBwcmludGYoIiAgICBWTUNFX1ZDUFU6
IGJhbmsxIG1jaV9jdGwyICUiIFBSSXg2NCAiXG4iLCBwLm1jaV9jdGwyX2JhbmsxKTsKIH0KIAog
aW50IG1haW4oaW50IGFyZ2MsIGNoYXIgKiphcmd2KQpkaWZmIC1yIDFjN2VhZTFlN2Q2NyB4ZW4v
YXJjaC94ODYvY3B1L21jaGVjay92bWNlLmMKLS0tIGEveGVuL2FyY2gveDg2L2NwdS9tY2hlY2sv
dm1jZS5jCVR1ZSBTZXAgMTggMjM6NDY6MzkgMjAxMiArMDgwMAorKysgYi94ZW4vYXJjaC94ODYv
Y3B1L21jaGVjay92bWNlLmMJV2VkIFNlcCAxOSAwMToyMToxOCAyMDEyICswODAwCkBAIC01NSw5
ICs1NSwxMCBAQAogICAgIHNwaW5fbG9ja19pbml0KCZ2LT5hcmNoLnZtY2UubG9jayk7CiB9CiAK
LWludCB2bWNlX3Jlc3RvcmVfdmNwdShzdHJ1Y3QgdmNwdSAqdiwgdWludDY0X3QgY2FwcykKK2lu
dCB2bWNlX3Jlc3RvcmVfdmNwdShzdHJ1Y3QgdmNwdSAqdiwgc3RydWN0IGh2bV92bWNlX3ZjcHUg
KmN0eHQpCiB7CiAgICAgdWludDY0X3QgZ3Vlc3RfbWNnX2NhcDsKKyAgICB1aW50NjRfdCBjYXBz
ID0gY3R4dC0+Y2FwczsKIAogICAgIGlmICggYm9vdF9jcHVfZGF0YS54ODZfdmVuZG9yID09IFg4
Nl9WRU5ET1JfSU5URUwgKQogICAgICAgICBndWVzdF9tY2dfY2FwID0gSU5URUxfR1VFU1RfTUNH
X0NBUDsKQEAgLTc0LDYgKzc1LDkgQEAKICAgICB9CiAKICAgICB2LT5hcmNoLnZtY2UubWNnX2Nh
cCA9IGNhcHM7CisgICAgdi0+YXJjaC52bWNlLmJhbmtbMF0ubWNpX2N0bDIgPSBjdHh0LT5tY2lf
Y3RsMl9iYW5rMDsKKyAgICB2LT5hcmNoLnZtY2UuYmFua1sxXS5tY2lfY3RsMiA9IGN0eHQtPm1j
aV9jdGwyX2JhbmsxOworCiAgICAgcmV0dXJuIDA7CiB9CiAKQEAgLTMwNSw3ICszMDksOSBAQAog
CiAgICAgZm9yX2VhY2hfdmNwdSggZCwgdiApIHsKICAgICAgICAgc3RydWN0IGh2bV92bWNlX3Zj
cHUgY3R4dCA9IHsKLSAgICAgICAgICAgIC5jYXBzID0gdi0+YXJjaC52bWNlLm1jZ19jYXAKKyAg
ICAgICAgICAgIC5jYXBzID0gdi0+YXJjaC52bWNlLm1jZ19jYXAsCisgICAgICAgICAgICAubWNp
X2N0bDJfYmFuazAgPSB2LT5hcmNoLnZtY2UuYmFua1swXS5tY2lfY3RsMiwKKyAgICAgICAgICAg
IC5tY2lfY3RsMl9iYW5rMSA9IHYtPmFyY2gudm1jZS5iYW5rWzFdLm1jaV9jdGwyCiAgICAgICAg
IH07CiAKICAgICAgICAgZXJyID0gaHZtX3NhdmVfZW50cnkoVk1DRV9WQ1BVLCB2LT52Y3B1X2lk
LCBoLCAmY3R4dCk7CkBAIC0zMzAsOSArMzM2LDkgQEAKICAgICAgICAgZXJyID0gLUVJTlZBTDsK
ICAgICB9CiAgICAgZWxzZQotICAgICAgICBlcnIgPSBodm1fbG9hZF9lbnRyeShWTUNFX1ZDUFUs
IGgsICZjdHh0KTsKKyAgICAgICAgZXJyID0gaHZtX2xvYWRfZW50cnlfemVyb2V4dGVuZChWTUNF
X1ZDUFUsIGgsICZjdHh0KTsKIAotICAgIHJldHVybiBlcnIgPzogdm1jZV9yZXN0b3JlX3ZjcHUo
diwgY3R4dC5jYXBzKTsKKyAgICByZXR1cm4gZXJyID86IHZtY2VfcmVzdG9yZV92Y3B1KHYsICZj
dHh0KTsKIH0KIAogSFZNX1JFR0lTVEVSX1NBVkVfUkVTVE9SRShWTUNFX1ZDUFUsIHZtY2Vfc2F2
ZV92Y3B1X2N0eHQsCmRpZmYgLXIgMWM3ZWFlMWU3ZDY3IHhlbi9hcmNoL3g4Ni9kb21jdGwuYwot
LS0gYS94ZW4vYXJjaC94ODYvZG9tY3RsLmMJVHVlIFNlcCAxOCAyMzo0NjozOSAyMDEyICswODAw
CisrKyBiL3hlbi9hcmNoL3g4Ni9kb21jdGwuYwlXZWQgU2VwIDE5IDAxOjIxOjE4IDIwMTIgKzA4
MDAKQEAgLTEwMjQsMTIgKzEwMjQsMTQgQEAKICAgICAgICAgICAgICAgICBldmMtPnN5c2NhbGwz
Ml9jYWxsYmFja19laXAgICAgPSAwOwogICAgICAgICAgICAgICAgIGV2Yy0+c3lzY2FsbDMyX2Rp
c2FibGVzX2V2ZW50cyA9IDA7CiAgICAgICAgICAgICB9Ci0gICAgICAgICAgICBldmMtPm1jZ19j
YXAgPSB2LT5hcmNoLnZtY2UubWNnX2NhcDsKKyAgICAgICAgICAgIGV2Yy0+dm1jZS5jYXBzID0g
di0+YXJjaC52bWNlLm1jZ19jYXA7CisgICAgICAgICAgICBldmMtPnZtY2UubWNpX2N0bDJfYmFu
azAgPSB2LT5hcmNoLnZtY2UuYmFua1swXS5tY2lfY3RsMjsKKyAgICAgICAgICAgIGV2Yy0+dm1j
ZS5tY2lfY3RsMl9iYW5rMSA9IHYtPmFyY2gudm1jZS5iYW5rWzFdLm1jaV9jdGwyOwogICAgICAg
ICB9CiAgICAgICAgIGVsc2UKICAgICAgICAgewogICAgICAgICAgICAgcmV0ID0gLUVJTlZBTDsK
LSAgICAgICAgICAgIGlmICggZXZjLT5zaXplIDwgb2Zmc2V0b2YodHlwZW9mKCpldmMpLCBtY2df
Y2FwKSApCisgICAgICAgICAgICBpZiAoIGV2Yy0+c2l6ZSA8IG9mZnNldG9mKHR5cGVvZigqZXZj
KSwgdm1jZSkgKQogICAgICAgICAgICAgICAgIGdvdG8gZXh0X3ZjcHVjb250ZXh0X291dDsKICAg
ICAgICAgICAgIGlmICggIWlzX2h2bV9kb21haW4oZCkgKQogICAgICAgICAgICAgewpAQCAtMTA1
OSw5ICsxMDYxLDkgQEAKICAgICAgICAgICAgICAgICAgZXZjLT5zeXNjYWxsMzJfY2FsbGJhY2tf
ZWlwICkKICAgICAgICAgICAgICAgICBnb3RvIGV4dF92Y3B1Y29udGV4dF9vdXQ7CiAKLSAgICAg
ICAgICAgIGlmICggZXZjLT5zaXplID49IG9mZnNldG9mKHR5cGVvZigqZXZjKSwgbWNnX2NhcCkg
KwotICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgc2l6ZW9mKGV2Yy0+bWNnX2NhcCkgKQot
ICAgICAgICAgICAgICAgIHJldCA9IHZtY2VfcmVzdG9yZV92Y3B1KHYsIGV2Yy0+bWNnX2NhcCk7
CisgICAgICAgICAgICBpZiAoIGV2Yy0+c2l6ZSA+PSBvZmZzZXRvZih0eXBlb2YoKmV2YyksIHZt
Y2UpICsKKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHNpemVvZihldmMtPnZtY2UpICk7
CisgICAgICAgICAgICAgICAgcmV0ID0gdm1jZV9yZXN0b3JlX3ZjcHUodiwgJmV2Yy0+dm1jZSk7
CiAgICAgICAgIH0KIAogICAgICAgICByZXQgPSAwOwpkaWZmIC1yIDFjN2VhZTFlN2Q2NyB4ZW4v
aW5jbHVkZS9hc20teDg2L21jZS5oCi0tLSBhL3hlbi9pbmNsdWRlL2FzbS14ODYvbWNlLmgJVHVl
IFNlcCAxOCAyMzo0NjozOSAyMDEyICswODAwCisrKyBiL3hlbi9pbmNsdWRlL2FzbS14ODYvbWNl
LmgJV2VkIFNlcCAxOSAwMToyMToxOCAyMDEyICswODAwCkBAIC00OCw3ICs0OCw3IEBACiAKIC8q
IEd1ZXN0IHZNQ0UgTVNScyB2aXJ0dWFsaXphdGlvbiAqLwogZXh0ZXJuIHZvaWQgdm1jZV9pbml0
X3ZjcHUoc3RydWN0IHZjcHUgKik7Ci1leHRlcm4gaW50IHZtY2VfcmVzdG9yZV92Y3B1KHN0cnVj
dCB2Y3B1ICosIHVpbnQ2NF90IGNhcHMpOworZXh0ZXJuIGludCB2bWNlX3Jlc3RvcmVfdmNwdShz
dHJ1Y3QgdmNwdSAqLCBzdHJ1Y3QgaHZtX3ZtY2VfdmNwdSAqY3R4dCk7CiBleHRlcm4gaW50IHZt
Y2Vfd3Jtc3IodWludDMyX3QgbXNyLCB1aW50NjRfdCB2YWwpOwogZXh0ZXJuIGludCB2bWNlX3Jk
bXNyKHVpbnQzMl90IG1zciwgdWludDY0X3QgKnZhbCk7CiAKZGlmZiAtciAxYzdlYWUxZTdkNjcg
eGVuL2luY2x1ZGUvcHVibGljL2FyY2gteDg2L2h2bS9zYXZlLmgKLS0tIGEveGVuL2luY2x1ZGUv
cHVibGljL2FyY2gteDg2L2h2bS9zYXZlLmgJVHVlIFNlcCAxOCAyMzo0NjozOSAyMDEyICswODAw
CisrKyBiL3hlbi9pbmNsdWRlL3B1YmxpYy9hcmNoLXg4Ni9odm0vc2F2ZS5oCVdlZCBTZXAgMTkg
MDE6MjE6MTggMjAxMiArMDgwMApAQCAtNTc3LDYgKzU3Nyw4IEBACiAKIHN0cnVjdCBodm1fdm1j
ZV92Y3B1IHsKICAgICB1aW50NjRfdCBjYXBzOworICAgIHVpbnQ2NF90IG1jaV9jdGwyX2Jhbmsw
OworICAgIHVpbnQ2NF90IG1jaV9jdGwyX2JhbmsxOwogfTsKIAogREVDTEFSRV9IVk1fU0FWRV9U
WVBFKFZNQ0VfVkNQVSwgMTgsIHN0cnVjdCBodm1fdm1jZV92Y3B1KTsKZGlmZiAtciAxYzdlYWUx
ZTdkNjcgeGVuL2luY2x1ZGUvcHVibGljL2RvbWN0bC5oCi0tLSBhL3hlbi9pbmNsdWRlL3B1Ymxp
Yy9kb21jdGwuaAlUdWUgU2VwIDE4IDIzOjQ2OjM5IDIwMTIgKzA4MDAKKysrIGIveGVuL2luY2x1
ZGUvcHVibGljL2RvbWN0bC5oCVdlZCBTZXAgMTkgMDE6MjE6MTggMjAxMiArMDgwMApAQCAtMzIs
NiArMzIsNyBAQAogI2Vycm9yICJkb21jdGwgb3BlcmF0aW9ucyBhcmUgaW50ZW5kZWQgZm9yIHVz
ZSBieSBub2RlIGNvbnRyb2wgdG9vbHMgb25seSIKICNlbmRpZgogCisjaW5jbHVkZSA8eGVuL2h2
bS9zYXZlLmg+CiAjaW5jbHVkZSAieGVuLmgiCiAjaW5jbHVkZSAiZ3JhbnRfdGFibGUuaCIKIApA
QCAtNTY0LDcgKzU2NSw3IEBACiAgICAgdWludDE2X3QgICAgICAgICBzeXNlbnRlcl9jYWxsYmFj
a19jczsKICAgICB1aW50OF90ICAgICAgICAgIHN5c2NhbGwzMl9kaXNhYmxlc19ldmVudHM7CiAg
ICAgdWludDhfdCAgICAgICAgICBzeXNlbnRlcl9kaXNhYmxlc19ldmVudHM7Ci0gICAgdWludDY0
X2FsaWduZWRfdCBtY2dfY2FwOworICAgIHN0cnVjdCBodm1fdm1jZV92Y3B1IHZtY2U7CiAjZW5k
aWYKIH07CiB0eXBlZGVmIHN0cnVjdCB4ZW5fZG9tY3RsX2V4dF92Y3B1Y29udGV4dCB4ZW5fZG9t
Y3RsX2V4dF92Y3B1Y29udGV4dF90Owo=

--_002_DE8DF0795D48FD4CA783C40EC829233532F41BSHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 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_DE8DF0795D48FD4CA783C40EC829233532F41BSHSMSX101ccrcorpi_--


From xen-devel-bounces@lists.xen.org Tue Sep 18 13:17:52 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Sep 2012 13:17:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDxgH-0005pS-BD; Tue, 18 Sep 2012 13:17:37 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <jinsong.liu@intel.com>) id 1TDxgF-0005oO-CX
	for xen-devel@lists.xensource.com; Tue, 18 Sep 2012 13:17:35 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1347974220!4500314!1
X-Originating-IP: [192.55.52.93]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjkzID0+IDM0NTMyNA==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22211 invoked from network); 18 Sep 2012 13:17:08 -0000
Received: from mga11.intel.com (HELO mga11.intel.com) (192.55.52.93)
	by server-15.tower-27.messagelabs.com with SMTP;
	18 Sep 2012 13:17:08 -0000
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
	by fmsmga102.fm.intel.com with ESMTP; 18 Sep 2012 06:16:59 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.80,442,1344236400"; d="scan'208";a="223479878"
Received: from fmsmsx105.amr.corp.intel.com ([10.19.9.36])
	by fmsmga001.fm.intel.com with ESMTP; 18 Sep 2012 06:16:59 -0700
Received: from fmsmsx153.amr.corp.intel.com (10.19.17.7) by
	FMSMSX105.amr.corp.intel.com (10.19.9.36) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Tue, 18 Sep 2012 06:16:59 -0700
Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by
	FMSMSX153.amr.corp.intel.com (10.19.17.7) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Tue, 18 Sep 2012 06:16:58 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.239]) by
	SHSMSX102.ccr.corp.intel.com ([169.254.2.92]) with mapi id
	14.01.0355.002; Tue, 18 Sep 2012 21:16:56 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: Jan Beulich <JBeulich@suse.com>, "xen-devel@lists.xensource.com"
	<xen-devel@lists.xensource.com>
Thread-Topic: [PATCH 4/5] Xen/MCE: Abort live migration when vMCE occur
Thread-Index: Ac2Vn+AzgkeMiMH0SpOJxeXzjtng6A==
Date: Tue, 18 Sep 2012 13:16:56 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC829233532F43A@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_DE8DF0795D48FD4CA783C40EC829233532F43ASHSMSX101ccrcorpi_"
MIME-Version: 1.0
Cc: "keir@xen.org" <keir@xen.org>,
	"Ian.Campbell@citrix.com" <Ian.Campbell@citrix.com>
Subject: [Xen-devel] [PATCH 4/5] Xen/MCE: Abort live migration when vMCE
	occur
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--_002_DE8DF0795D48FD4CA783C40EC829233532F43ASHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Xen/MCE: Abort live migration when vMCE occur

This patch monitor the critical area of live migration (from vMCE point of =
view,
the copypages stage of migration is the critical area while other areas are=
 not).

If a vMCE occur at the critical area of live migration, abort and try migra=
tion later.

Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>

diff -r f843ac6f93c9 tools/libxc/xc_domain.c
--- a/tools/libxc/xc_domain.c	Wed Sep 19 01:21:18 2012 +0800
+++ b/tools/libxc/xc_domain.c	Wed Sep 19 03:31:30 2012 +0800
@@ -283,6 +283,37 @@
     return ret;
 }
=20
+/* Start vmce monitor */
+int xc_domain_vmce_monitor_strat(xc_interface *xch,
+                                 uint32_t domid)
+{
+    int ret;
+    DECLARE_DOMCTL;
+
+    domctl.cmd =3D XEN_DOMCTL_vmce_monitor_start;
+    domctl.domain =3D (domid_t)domid;
+    ret =3D do_domctl(xch, &domctl);
+
+    return ret ? -1 : 0;
+}
+
+/* End vmce monitor */
+int xc_domain_vmce_monitor_end(xc_interface *xch,
+                               uint32_t domid,
+                               signed char *vmce_while_monitor)
+{
+    int ret;
+    DECLARE_DOMCTL;
+
+    domctl.cmd =3D XEN_DOMCTL_vmce_monitor_end;
+    domctl.domain =3D (domid_t)domid;
+    ret =3D do_domctl(xch, &domctl);
+    if ( !ret )
+        *vmce_while_monitor =3D domctl.u.vmce_monitor.vmce_while_monitor;
+
+    return ret ? -1 : 0;
+}
+
 /* get info from hvm guest for save */
 int xc_domain_hvm_getcontext(xc_interface *xch,
                              uint32_t domid,
diff -r f843ac6f93c9 tools/libxc/xc_domain_save.c
--- a/tools/libxc/xc_domain_save.c	Wed Sep 19 01:21:18 2012 +0800
+++ b/tools/libxc/xc_domain_save.c	Wed Sep 19 03:31:30 2012 +0800
@@ -895,6 +895,8 @@
      */
     int compressing =3D 0;
=20
+    signed char vmce_while_monitor =3D 0;
+
     int completed =3D 0;
=20
     if ( hvm && !callbacks->switch_qemu_logdirty )
@@ -1109,6 +1111,12 @@
         goto out;
     }
=20
+    if ( xc_domain_vmce_monitor_strat(xch, dom) )
+    {
+        PERROR("Error when start vmce monitor\n");
+        goto out;
+    }
+
   copypages:
 #define wrexact(fd, buf, len) write_buffer(xch, last_iter, ob, (fd), (buf)=
, (len))
 #define wruncached(fd, live, buf, len) write_uncached(xch, last_iter, ob, =
(fd), (buf), (len))
@@ -1571,6 +1579,17 @@
=20
     DPRINTF("All memory is saved\n");
=20
+    if ( xc_domain_vmce_monitor_end(xch, dom, &vmce_while_monitor) )
+    {
+        PERROR("Error when end vmce monitor\n");
+        goto out;
+    }
+    else if ( vmce_while_monitor =3D=3D -1 )
+    {
+        fprintf(stderr, "vMCE occurred, abort this time and try later.\n")=
;
+        goto out;
+    }
+
     /* After last_iter, buffer the rest of pagebuf & tailbuf data into a
      * separate output buffer and flush it after the compressed page chunk=
s.
      */
diff -r f843ac6f93c9 tools/libxc/xenctrl.h
--- a/tools/libxc/xenctrl.h	Wed Sep 19 01:21:18 2012 +0800
+++ b/tools/libxc/xenctrl.h	Wed Sep 19 03:31:30 2012 +0800
@@ -571,6 +571,26 @@
                           xc_domaininfo_t *info);
=20
 /**
+ * This function start monitor vmce event.
+ * @parm xch a handle to an open hypervisor interface
+ * @parm domid the domain id monitored
+ * @return 0 on success, -1 on failure
+ */
+int xc_domain_vmce_monitor_strat(xc_interface *xch,
+                                 uint32_t domid);
+
+/**
+ * This function end monitor vmce event
+ * @parm xch a handle to an open hypervisor interface
+ * @parm domid the domain id monitored
+ * @parm vmce_while_migrate a pointer return whether vMCE occur when migra=
te=20
+ * @return 0 on success, -1 on failure
+ */
+int xc_domain_vmce_monitor_end(xc_interface *xch,
+                               uint32_t domid,
+                               signed char *vmce_while_monitor);
+
+/**
  * This function returns information about the context of a hvm domain
  * @parm xch a handle to an open hypervisor interface
  * @parm domid the domain to get information from
diff -r f843ac6f93c9 xen/arch/x86/cpu/mcheck/mce_intel.c
--- a/xen/arch/x86/cpu/mcheck/mce_intel.c	Wed Sep 19 01:21:18 2012 +0800
+++ b/xen/arch/x86/cpu/mcheck/mce_intel.c	Wed Sep 19 03:31:30 2012 +0800
@@ -596,6 +596,12 @@
                     goto vmce_failed;
                 }
=20
+                if ( unlikely(d->arch.vmce_monitor) )
+                {
+                    /* vMCE occur when guest migration */
+                    d->arch.vmce_monitor =3D -1;
+                }
+
                 /* We will inject vMCE to DOMU*/
                 if ( inject_vmce(d) < 0 )
                 {
diff -r f843ac6f93c9 xen/arch/x86/domctl.c
--- a/xen/arch/x86/domctl.c	Wed Sep 19 01:21:18 2012 +0800
+++ b/xen/arch/x86/domctl.c	Wed Sep 19 03:31:30 2012 +0800
@@ -1514,6 +1514,40 @@
     }
     break;
=20
+    case XEN_DOMCTL_vmce_monitor_start:
+    {
+        struct domain *d;
+
+        d =3D rcu_lock_domain_by_id(domctl->domain);
+        if ( d !=3D NULL )
+        {
+            d->arch.vmce_monitor =3D 1;
+            rcu_unlock_domain(d);
+        }
+        else
+            ret =3D -ESRCH;
+    }
+    break;
+
+    case XEN_DOMCTL_vmce_monitor_end:
+    {
+        struct domain *d;
+
+        d =3D rcu_lock_domain_by_id(domctl->domain);
+        if ( d !=3D NULL)
+        {
+            domctl->u.vmce_monitor.vmce_while_monitor =3D
+                                      d->arch.vmce_monitor;
+            d->arch.vmce_monitor =3D 0;
+            rcu_unlock_domain(d);
+            if ( copy_to_guest(u_domctl, domctl, 1) )
+                ret =3D -EFAULT;
+        }
+        else
+            ret =3D -ESRCH;
+    }
+    break;
+
     default:
         ret =3D iommu_do_domctl(domctl, u_domctl);
         break;
diff -r f843ac6f93c9 xen/include/asm-x86/domain.h
--- a/xen/include/asm-x86/domain.h	Wed Sep 19 01:21:18 2012 +0800
+++ b/xen/include/asm-x86/domain.h	Wed Sep 19 03:31:30 2012 +0800
@@ -279,6 +279,11 @@
     bool_t has_32bit_shinfo;
     /* Domain cannot handle spurious page faults? */
     bool_t suppress_spurious_page_faults;
+    /* Monitoring guest memory copy of migration
+     * =3D 0 - not monitoring
+     * > 0 - monitoring
+     * < 0 - vMCE occurred while monitoring */
+    s8 vmce_monitor;
=20
     /* Continuable domain_relinquish_resources(). */
     enum {
diff -r f843ac6f93c9 xen/include/public/domctl.h
--- a/xen/include/public/domctl.h	Wed Sep 19 01:21:18 2012 +0800
+++ b/xen/include/public/domctl.h	Wed Sep 19 03:31:30 2012 +0800
@@ -828,6 +828,12 @@
 typedef struct xen_domctl_set_access_required xen_domctl_set_access_requir=
ed_t;
 DEFINE_XEN_GUEST_HANDLE(xen_domctl_set_access_required_t);
=20
+struct xen_domctl_vmce_monitor {
+    signed char vmce_while_monitor;
+};
+typedef struct xen_domctl_vmce_monitor xen_domctl_vmce_monitor_t;
+DEFINE_XEN_GUEST_HANDLE(xen_domctl_vmce_monitor_t);
+
 struct xen_domctl {
     uint32_t cmd;
 #define XEN_DOMCTL_createdomain                   1
@@ -893,6 +899,8 @@
 #define XEN_DOMCTL_set_access_required           64
 #define XEN_DOMCTL_audit_p2m                     65
 #define XEN_DOMCTL_set_virq_handler              66
+#define XEN_DOMCTL_vmce_monitor_start            67
+#define XEN_DOMCTL_vmce_monitor_end              68
 #define XEN_DOMCTL_gdbsx_guestmemio            1000
 #define XEN_DOMCTL_gdbsx_pausevcpu             1001
 #define XEN_DOMCTL_gdbsx_unpausevcpu           1002
@@ -947,6 +955,7 @@
         struct xen_domctl_set_access_required access_required;
         struct xen_domctl_audit_p2m         audit_p2m;
         struct xen_domctl_set_virq_handler  set_virq_handler;
+        struct xen_domctl_vmce_monitor      vmce_monitor;
         struct xen_domctl_gdbsx_memio       gdbsx_guest_memio;
         struct xen_domctl_gdbsx_pauseunp_vcpu gdbsx_pauseunp_vcpu;
         struct xen_domctl_gdbsx_domstatus   gdbsx_domstatus;=

--_002_DE8DF0795D48FD4CA783C40EC829233532F43ASHSMSX101ccrcorpi_
Content-Type: application/octet-stream; name="4_vmce_when_migrate.patch"
Content-Description: 4_vmce_when_migrate.patch
Content-Disposition: attachment; filename="4_vmce_when_migrate.patch";
	size=7729; creation-date="Tue, 18 Sep 2012 13:04:35 GMT";
	modification-date="Tue, 18 Sep 2012 19:31:30 GMT"
Content-Transfer-Encoding: base64

WGVuL01DRTogQWJvcnQgbGl2ZSBtaWdyYXRpb24gd2hlbiB2TUNFIG9jY3VyCgpUaGlzIHBhdGNo
IG1vbml0b3IgdGhlIGNyaXRpY2FsIGFyZWEgb2YgbGl2ZSBtaWdyYXRpb24gKGZyb20gdk1DRSBw
b2ludCBvZiB2aWV3LAp0aGUgY29weXBhZ2VzIHN0YWdlIG9mIG1pZ3JhdGlvbiBpcyB0aGUgY3Jp
dGljYWwgYXJlYSB3aGlsZSBvdGhlciBhcmVhcyBhcmUgbm90KS4KCklmIGEgdk1DRSBvY2N1ciBh
dCB0aGUgY3JpdGljYWwgYXJlYSBvZiBsaXZlIG1pZ3JhdGlvbiwgYWJvcnQgYW5kIHRyeSBtaWdy
YXRpb24gbGF0ZXIuCgpTaWduZWQtb2ZmLWJ5OiBMaXUsIEppbnNvbmcgPGppbnNvbmcubGl1QGlu
dGVsLmNvbT4KCmRpZmYgLXIgZjg0M2FjNmY5M2M5IHRvb2xzL2xpYnhjL3hjX2RvbWFpbi5jCi0t
LSBhL3Rvb2xzL2xpYnhjL3hjX2RvbWFpbi5jCVdlZCBTZXAgMTkgMDE6MjE6MTggMjAxMiArMDgw
MAorKysgYi90b29scy9saWJ4Yy94Y19kb21haW4uYwlXZWQgU2VwIDE5IDAzOjMxOjMwIDIwMTIg
KzA4MDAKQEAgLTI4Myw2ICsyODMsMzcgQEAKICAgICByZXR1cm4gcmV0OwogfQogCisvKiBTdGFy
dCB2bWNlIG1vbml0b3IgKi8KK2ludCB4Y19kb21haW5fdm1jZV9tb25pdG9yX3N0cmF0KHhjX2lu
dGVyZmFjZSAqeGNoLAorICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgdWludDMyX3Qg
ZG9taWQpCit7CisgICAgaW50IHJldDsKKyAgICBERUNMQVJFX0RPTUNUTDsKKworICAgIGRvbWN0
bC5jbWQgPSBYRU5fRE9NQ1RMX3ZtY2VfbW9uaXRvcl9zdGFydDsKKyAgICBkb21jdGwuZG9tYWlu
ID0gKGRvbWlkX3QpZG9taWQ7CisgICAgcmV0ID0gZG9fZG9tY3RsKHhjaCwgJmRvbWN0bCk7CisK
KyAgICByZXR1cm4gcmV0ID8gLTEgOiAwOworfQorCisvKiBFbmQgdm1jZSBtb25pdG9yICovCitp
bnQgeGNfZG9tYWluX3ZtY2VfbW9uaXRvcl9lbmQoeGNfaW50ZXJmYWNlICp4Y2gsCisgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgdWludDMyX3QgZG9taWQsCisgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgc2lnbmVkIGNoYXIgKnZtY2Vfd2hpbGVfbW9uaXRvcikKK3sKKyAgICBp
bnQgcmV0OworICAgIERFQ0xBUkVfRE9NQ1RMOworCisgICAgZG9tY3RsLmNtZCA9IFhFTl9ET01D
VExfdm1jZV9tb25pdG9yX2VuZDsKKyAgICBkb21jdGwuZG9tYWluID0gKGRvbWlkX3QpZG9taWQ7
CisgICAgcmV0ID0gZG9fZG9tY3RsKHhjaCwgJmRvbWN0bCk7CisgICAgaWYgKCAhcmV0ICkKKyAg
ICAgICAgKnZtY2Vfd2hpbGVfbW9uaXRvciA9IGRvbWN0bC51LnZtY2VfbW9uaXRvci52bWNlX3do
aWxlX21vbml0b3I7CisKKyAgICByZXR1cm4gcmV0ID8gLTEgOiAwOworfQorCiAvKiBnZXQgaW5m
byBmcm9tIGh2bSBndWVzdCBmb3Igc2F2ZSAqLwogaW50IHhjX2RvbWFpbl9odm1fZ2V0Y29udGV4
dCh4Y19pbnRlcmZhY2UgKnhjaCwKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgdWludDMy
X3QgZG9taWQsCmRpZmYgLXIgZjg0M2FjNmY5M2M5IHRvb2xzL2xpYnhjL3hjX2RvbWFpbl9zYXZl
LmMKLS0tIGEvdG9vbHMvbGlieGMveGNfZG9tYWluX3NhdmUuYwlXZWQgU2VwIDE5IDAxOjIxOjE4
IDIwMTIgKzA4MDAKKysrIGIvdG9vbHMvbGlieGMveGNfZG9tYWluX3NhdmUuYwlXZWQgU2VwIDE5
IDAzOjMxOjMwIDIwMTIgKzA4MDAKQEAgLTg5NSw2ICs4OTUsOCBAQAogICAgICAqLwogICAgIGlu
dCBjb21wcmVzc2luZyA9IDA7CiAKKyAgICBzaWduZWQgY2hhciB2bWNlX3doaWxlX21vbml0b3Ig
PSAwOworCiAgICAgaW50IGNvbXBsZXRlZCA9IDA7CiAKICAgICBpZiAoIGh2bSAmJiAhY2FsbGJh
Y2tzLT5zd2l0Y2hfcWVtdV9sb2dkaXJ0eSApCkBAIC0xMTA5LDYgKzExMTEsMTIgQEAKICAgICAg
ICAgZ290byBvdXQ7CiAgICAgfQogCisgICAgaWYgKCB4Y19kb21haW5fdm1jZV9tb25pdG9yX3N0
cmF0KHhjaCwgZG9tKSApCisgICAgeworICAgICAgICBQRVJST1IoIkVycm9yIHdoZW4gc3RhcnQg
dm1jZSBtb25pdG9yXG4iKTsKKyAgICAgICAgZ290byBvdXQ7CisgICAgfQorCiAgIGNvcHlwYWdl
czoKICNkZWZpbmUgd3JleGFjdChmZCwgYnVmLCBsZW4pIHdyaXRlX2J1ZmZlcih4Y2gsIGxhc3Rf
aXRlciwgb2IsIChmZCksIChidWYpLCAobGVuKSkKICNkZWZpbmUgd3J1bmNhY2hlZChmZCwgbGl2
ZSwgYnVmLCBsZW4pIHdyaXRlX3VuY2FjaGVkKHhjaCwgbGFzdF9pdGVyLCBvYiwgKGZkKSwgKGJ1
ZiksIChsZW4pKQpAQCAtMTU3MSw2ICsxNTc5LDE3IEBACiAKICAgICBEUFJJTlRGKCJBbGwgbWVt
b3J5IGlzIHNhdmVkXG4iKTsKIAorICAgIGlmICggeGNfZG9tYWluX3ZtY2VfbW9uaXRvcl9lbmQo
eGNoLCBkb20sICZ2bWNlX3doaWxlX21vbml0b3IpICkKKyAgICB7CisgICAgICAgIFBFUlJPUigi
RXJyb3Igd2hlbiBlbmQgdm1jZSBtb25pdG9yXG4iKTsKKyAgICAgICAgZ290byBvdXQ7CisgICAg
fQorICAgIGVsc2UgaWYgKCB2bWNlX3doaWxlX21vbml0b3IgPT0gLTEgKQorICAgIHsKKyAgICAg
ICAgZnByaW50ZihzdGRlcnIsICJ2TUNFIG9jY3VycmVkLCBhYm9ydCB0aGlzIHRpbWUgYW5kIHRy
eSBsYXRlci5cbiIpOworICAgICAgICBnb3RvIG91dDsKKyAgICB9CisKICAgICAvKiBBZnRlciBs
YXN0X2l0ZXIsIGJ1ZmZlciB0aGUgcmVzdCBvZiBwYWdlYnVmICYgdGFpbGJ1ZiBkYXRhIGludG8g
YQogICAgICAqIHNlcGFyYXRlIG91dHB1dCBidWZmZXIgYW5kIGZsdXNoIGl0IGFmdGVyIHRoZSBj
b21wcmVzc2VkIHBhZ2UgY2h1bmtzLgogICAgICAqLwpkaWZmIC1yIGY4NDNhYzZmOTNjOSB0b29s
cy9saWJ4Yy94ZW5jdHJsLmgKLS0tIGEvdG9vbHMvbGlieGMveGVuY3RybC5oCVdlZCBTZXAgMTkg
MDE6MjE6MTggMjAxMiArMDgwMAorKysgYi90b29scy9saWJ4Yy94ZW5jdHJsLmgJV2VkIFNlcCAx
OSAwMzozMTozMCAyMDEyICswODAwCkBAIC01NzEsNiArNTcxLDI2IEBACiAgICAgICAgICAgICAg
ICAgICAgICAgICAgIHhjX2RvbWFpbmluZm9fdCAqaW5mbyk7CiAKIC8qKgorICogVGhpcyBmdW5j
dGlvbiBzdGFydCBtb25pdG9yIHZtY2UgZXZlbnQuCisgKiBAcGFybSB4Y2ggYSBoYW5kbGUgdG8g
YW4gb3BlbiBoeXBlcnZpc29yIGludGVyZmFjZQorICogQHBhcm0gZG9taWQgdGhlIGRvbWFpbiBp
ZCBtb25pdG9yZWQKKyAqIEByZXR1cm4gMCBvbiBzdWNjZXNzLCAtMSBvbiBmYWlsdXJlCisgKi8K
K2ludCB4Y19kb21haW5fdm1jZV9tb25pdG9yX3N0cmF0KHhjX2ludGVyZmFjZSAqeGNoLAorICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgdWludDMyX3QgZG9taWQpOworCisvKioKKyAq
IFRoaXMgZnVuY3Rpb24gZW5kIG1vbml0b3Igdm1jZSBldmVudAorICogQHBhcm0geGNoIGEgaGFu
ZGxlIHRvIGFuIG9wZW4gaHlwZXJ2aXNvciBpbnRlcmZhY2UKKyAqIEBwYXJtIGRvbWlkIHRoZSBk
b21haW4gaWQgbW9uaXRvcmVkCisgKiBAcGFybSB2bWNlX3doaWxlX21pZ3JhdGUgYSBwb2ludGVy
IHJldHVybiB3aGV0aGVyIHZNQ0Ugb2NjdXIgd2hlbiBtaWdyYXRlIAorICogQHJldHVybiAwIG9u
IHN1Y2Nlc3MsIC0xIG9uIGZhaWx1cmUKKyAqLworaW50IHhjX2RvbWFpbl92bWNlX21vbml0b3Jf
ZW5kKHhjX2ludGVyZmFjZSAqeGNoLAorICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHVp
bnQzMl90IGRvbWlkLAorICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHNpZ25lZCBjaGFy
ICp2bWNlX3doaWxlX21vbml0b3IpOworCisvKioKICAqIFRoaXMgZnVuY3Rpb24gcmV0dXJucyBp
bmZvcm1hdGlvbiBhYm91dCB0aGUgY29udGV4dCBvZiBhIGh2bSBkb21haW4KICAqIEBwYXJtIHhj
aCBhIGhhbmRsZSB0byBhbiBvcGVuIGh5cGVydmlzb3IgaW50ZXJmYWNlCiAgKiBAcGFybSBkb21p
ZCB0aGUgZG9tYWluIHRvIGdldCBpbmZvcm1hdGlvbiBmcm9tCmRpZmYgLXIgZjg0M2FjNmY5M2M5
IHhlbi9hcmNoL3g4Ni9jcHUvbWNoZWNrL21jZV9pbnRlbC5jCi0tLSBhL3hlbi9hcmNoL3g4Ni9j
cHUvbWNoZWNrL21jZV9pbnRlbC5jCVdlZCBTZXAgMTkgMDE6MjE6MTggMjAxMiArMDgwMAorKysg
Yi94ZW4vYXJjaC94ODYvY3B1L21jaGVjay9tY2VfaW50ZWwuYwlXZWQgU2VwIDE5IDAzOjMxOjMw
IDIwMTIgKzA4MDAKQEAgLTU5Niw2ICs1OTYsMTIgQEAKICAgICAgICAgICAgICAgICAgICAgZ290
byB2bWNlX2ZhaWxlZDsKICAgICAgICAgICAgICAgICB9CiAKKyAgICAgICAgICAgICAgICBpZiAo
IHVubGlrZWx5KGQtPmFyY2gudm1jZV9tb25pdG9yKSApCisgICAgICAgICAgICAgICAgeworICAg
ICAgICAgICAgICAgICAgICAvKiB2TUNFIG9jY3VyIHdoZW4gZ3Vlc3QgbWlncmF0aW9uICovCisg
ICAgICAgICAgICAgICAgICAgIGQtPmFyY2gudm1jZV9tb25pdG9yID0gLTE7CisgICAgICAgICAg
ICAgICAgfQorCiAgICAgICAgICAgICAgICAgLyogV2Ugd2lsbCBpbmplY3Qgdk1DRSB0byBET01V
Ki8KICAgICAgICAgICAgICAgICBpZiAoIGluamVjdF92bWNlKGQpIDwgMCApCiAgICAgICAgICAg
ICAgICAgewpkaWZmIC1yIGY4NDNhYzZmOTNjOSB4ZW4vYXJjaC94ODYvZG9tY3RsLmMKLS0tIGEv
eGVuL2FyY2gveDg2L2RvbWN0bC5jCVdlZCBTZXAgMTkgMDE6MjE6MTggMjAxMiArMDgwMAorKysg
Yi94ZW4vYXJjaC94ODYvZG9tY3RsLmMJV2VkIFNlcCAxOSAwMzozMTozMCAyMDEyICswODAwCkBA
IC0xNTE0LDYgKzE1MTQsNDAgQEAKICAgICB9CiAgICAgYnJlYWs7CiAKKyAgICBjYXNlIFhFTl9E
T01DVExfdm1jZV9tb25pdG9yX3N0YXJ0OgorICAgIHsKKyAgICAgICAgc3RydWN0IGRvbWFpbiAq
ZDsKKworICAgICAgICBkID0gcmN1X2xvY2tfZG9tYWluX2J5X2lkKGRvbWN0bC0+ZG9tYWluKTsK
KyAgICAgICAgaWYgKCBkICE9IE5VTEwgKQorICAgICAgICB7CisgICAgICAgICAgICBkLT5hcmNo
LnZtY2VfbW9uaXRvciA9IDE7CisgICAgICAgICAgICByY3VfdW5sb2NrX2RvbWFpbihkKTsKKyAg
ICAgICAgfQorICAgICAgICBlbHNlCisgICAgICAgICAgICByZXQgPSAtRVNSQ0g7CisgICAgfQor
ICAgIGJyZWFrOworCisgICAgY2FzZSBYRU5fRE9NQ1RMX3ZtY2VfbW9uaXRvcl9lbmQ6CisgICAg
eworICAgICAgICBzdHJ1Y3QgZG9tYWluICpkOworCisgICAgICAgIGQgPSByY3VfbG9ja19kb21h
aW5fYnlfaWQoZG9tY3RsLT5kb21haW4pOworICAgICAgICBpZiAoIGQgIT0gTlVMTCkKKyAgICAg
ICAgeworICAgICAgICAgICAgZG9tY3RsLT51LnZtY2VfbW9uaXRvci52bWNlX3doaWxlX21vbml0
b3IgPQorICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBkLT5hcmNoLnZtY2Vf
bW9uaXRvcjsKKyAgICAgICAgICAgIGQtPmFyY2gudm1jZV9tb25pdG9yID0gMDsKKyAgICAgICAg
ICAgIHJjdV91bmxvY2tfZG9tYWluKGQpOworICAgICAgICAgICAgaWYgKCBjb3B5X3RvX2d1ZXN0
KHVfZG9tY3RsLCBkb21jdGwsIDEpICkKKyAgICAgICAgICAgICAgICByZXQgPSAtRUZBVUxUOwor
ICAgICAgICB9CisgICAgICAgIGVsc2UKKyAgICAgICAgICAgIHJldCA9IC1FU1JDSDsKKyAgICB9
CisgICAgYnJlYWs7CisKICAgICBkZWZhdWx0OgogICAgICAgICByZXQgPSBpb21tdV9kb19kb21j
dGwoZG9tY3RsLCB1X2RvbWN0bCk7CiAgICAgICAgIGJyZWFrOwpkaWZmIC1yIGY4NDNhYzZmOTNj
OSB4ZW4vaW5jbHVkZS9hc20teDg2L2RvbWFpbi5oCi0tLSBhL3hlbi9pbmNsdWRlL2FzbS14ODYv
ZG9tYWluLmgJV2VkIFNlcCAxOSAwMToyMToxOCAyMDEyICswODAwCisrKyBiL3hlbi9pbmNsdWRl
L2FzbS14ODYvZG9tYWluLmgJV2VkIFNlcCAxOSAwMzozMTozMCAyMDEyICswODAwCkBAIC0yNzks
NiArMjc5LDExIEBACiAgICAgYm9vbF90IGhhc18zMmJpdF9zaGluZm87CiAgICAgLyogRG9tYWlu
IGNhbm5vdCBoYW5kbGUgc3B1cmlvdXMgcGFnZSBmYXVsdHM/ICovCiAgICAgYm9vbF90IHN1cHBy
ZXNzX3NwdXJpb3VzX3BhZ2VfZmF1bHRzOworICAgIC8qIE1vbml0b3JpbmcgZ3Vlc3QgbWVtb3J5
IGNvcHkgb2YgbWlncmF0aW9uCisgICAgICogPSAwIC0gbm90IG1vbml0b3JpbmcKKyAgICAgKiA+
IDAgLSBtb25pdG9yaW5nCisgICAgICogPCAwIC0gdk1DRSBvY2N1cnJlZCB3aGlsZSBtb25pdG9y
aW5nICovCisgICAgczggdm1jZV9tb25pdG9yOwogCiAgICAgLyogQ29udGludWFibGUgZG9tYWlu
X3JlbGlucXVpc2hfcmVzb3VyY2VzKCkuICovCiAgICAgZW51bSB7CmRpZmYgLXIgZjg0M2FjNmY5
M2M5IHhlbi9pbmNsdWRlL3B1YmxpYy9kb21jdGwuaAotLS0gYS94ZW4vaW5jbHVkZS9wdWJsaWMv
ZG9tY3RsLmgJV2VkIFNlcCAxOSAwMToyMToxOCAyMDEyICswODAwCisrKyBiL3hlbi9pbmNsdWRl
L3B1YmxpYy9kb21jdGwuaAlXZWQgU2VwIDE5IDAzOjMxOjMwIDIwMTIgKzA4MDAKQEAgLTgyOCw2
ICs4MjgsMTIgQEAKIHR5cGVkZWYgc3RydWN0IHhlbl9kb21jdGxfc2V0X2FjY2Vzc19yZXF1aXJl
ZCB4ZW5fZG9tY3RsX3NldF9hY2Nlc3NfcmVxdWlyZWRfdDsKIERFRklORV9YRU5fR1VFU1RfSEFO
RExFKHhlbl9kb21jdGxfc2V0X2FjY2Vzc19yZXF1aXJlZF90KTsKIAorc3RydWN0IHhlbl9kb21j
dGxfdm1jZV9tb25pdG9yIHsKKyAgICBzaWduZWQgY2hhciB2bWNlX3doaWxlX21vbml0b3I7Cit9
OwordHlwZWRlZiBzdHJ1Y3QgeGVuX2RvbWN0bF92bWNlX21vbml0b3IgeGVuX2RvbWN0bF92bWNl
X21vbml0b3JfdDsKK0RFRklORV9YRU5fR1VFU1RfSEFORExFKHhlbl9kb21jdGxfdm1jZV9tb25p
dG9yX3QpOworCiBzdHJ1Y3QgeGVuX2RvbWN0bCB7CiAgICAgdWludDMyX3QgY21kOwogI2RlZmlu
ZSBYRU5fRE9NQ1RMX2NyZWF0ZWRvbWFpbiAgICAgICAgICAgICAgICAgICAxCkBAIC04OTMsNiAr
ODk5LDggQEAKICNkZWZpbmUgWEVOX0RPTUNUTF9zZXRfYWNjZXNzX3JlcXVpcmVkICAgICAgICAg
ICA2NAogI2RlZmluZSBYRU5fRE9NQ1RMX2F1ZGl0X3AybSAgICAgICAgICAgICAgICAgICAgIDY1
CiAjZGVmaW5lIFhFTl9ET01DVExfc2V0X3ZpcnFfaGFuZGxlciAgICAgICAgICAgICAgNjYKKyNk
ZWZpbmUgWEVOX0RPTUNUTF92bWNlX21vbml0b3Jfc3RhcnQgICAgICAgICAgICA2NworI2RlZmlu
ZSBYRU5fRE9NQ1RMX3ZtY2VfbW9uaXRvcl9lbmQgICAgICAgICAgICAgIDY4CiAjZGVmaW5lIFhF
Tl9ET01DVExfZ2Ric3hfZ3Vlc3RtZW1pbyAgICAgICAgICAgIDEwMDAKICNkZWZpbmUgWEVOX0RP
TUNUTF9nZGJzeF9wYXVzZXZjcHUgICAgICAgICAgICAgMTAwMQogI2RlZmluZSBYRU5fRE9NQ1RM
X2dkYnN4X3VucGF1c2V2Y3B1ICAgICAgICAgICAxMDAyCkBAIC05NDcsNiArOTU1LDcgQEAKICAg
ICAgICAgc3RydWN0IHhlbl9kb21jdGxfc2V0X2FjY2Vzc19yZXF1aXJlZCBhY2Nlc3NfcmVxdWly
ZWQ7CiAgICAgICAgIHN0cnVjdCB4ZW5fZG9tY3RsX2F1ZGl0X3AybSAgICAgICAgIGF1ZGl0X3Ay
bTsKICAgICAgICAgc3RydWN0IHhlbl9kb21jdGxfc2V0X3ZpcnFfaGFuZGxlciAgc2V0X3ZpcnFf
aGFuZGxlcjsKKyAgICAgICAgc3RydWN0IHhlbl9kb21jdGxfdm1jZV9tb25pdG9yICAgICAgdm1j
ZV9tb25pdG9yOwogICAgICAgICBzdHJ1Y3QgeGVuX2RvbWN0bF9nZGJzeF9tZW1pbyAgICAgICBn
ZGJzeF9ndWVzdF9tZW1pbzsKICAgICAgICAgc3RydWN0IHhlbl9kb21jdGxfZ2Ric3hfcGF1c2V1
bnBfdmNwdSBnZGJzeF9wYXVzZXVucF92Y3B1OwogICAgICAgICBzdHJ1Y3QgeGVuX2RvbWN0bF9n
ZGJzeF9kb21zdGF0dXMgICBnZGJzeF9kb21zdGF0dXM7Cg==

--_002_DE8DF0795D48FD4CA783C40EC829233532F43ASHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 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_DE8DF0795D48FD4CA783C40EC829233532F43ASHSMSX101ccrcorpi_--


From xen-devel-bounces@lists.xen.org Tue Sep 18 13:17:52 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Sep 2012 13:17:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDxgH-0005pS-BD; Tue, 18 Sep 2012 13:17:37 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <jinsong.liu@intel.com>) id 1TDxgF-0005oO-CX
	for xen-devel@lists.xensource.com; Tue, 18 Sep 2012 13:17:35 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1347974220!4500314!1
X-Originating-IP: [192.55.52.93]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjkzID0+IDM0NTMyNA==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22211 invoked from network); 18 Sep 2012 13:17:08 -0000
Received: from mga11.intel.com (HELO mga11.intel.com) (192.55.52.93)
	by server-15.tower-27.messagelabs.com with SMTP;
	18 Sep 2012 13:17:08 -0000
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
	by fmsmga102.fm.intel.com with ESMTP; 18 Sep 2012 06:16:59 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.80,442,1344236400"; d="scan'208";a="223479878"
Received: from fmsmsx105.amr.corp.intel.com ([10.19.9.36])
	by fmsmga001.fm.intel.com with ESMTP; 18 Sep 2012 06:16:59 -0700
Received: from fmsmsx153.amr.corp.intel.com (10.19.17.7) by
	FMSMSX105.amr.corp.intel.com (10.19.9.36) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Tue, 18 Sep 2012 06:16:59 -0700
Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by
	FMSMSX153.amr.corp.intel.com (10.19.17.7) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Tue, 18 Sep 2012 06:16:58 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.239]) by
	SHSMSX102.ccr.corp.intel.com ([169.254.2.92]) with mapi id
	14.01.0355.002; Tue, 18 Sep 2012 21:16:56 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: Jan Beulich <JBeulich@suse.com>, "xen-devel@lists.xensource.com"
	<xen-devel@lists.xensource.com>
Thread-Topic: [PATCH 4/5] Xen/MCE: Abort live migration when vMCE occur
Thread-Index: Ac2Vn+AzgkeMiMH0SpOJxeXzjtng6A==
Date: Tue, 18 Sep 2012 13:16:56 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC829233532F43A@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_DE8DF0795D48FD4CA783C40EC829233532F43ASHSMSX101ccrcorpi_"
MIME-Version: 1.0
Cc: "keir@xen.org" <keir@xen.org>,
	"Ian.Campbell@citrix.com" <Ian.Campbell@citrix.com>
Subject: [Xen-devel] [PATCH 4/5] Xen/MCE: Abort live migration when vMCE
	occur
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--_002_DE8DF0795D48FD4CA783C40EC829233532F43ASHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Xen/MCE: Abort live migration when vMCE occur

This patch monitor the critical area of live migration (from vMCE point of =
view,
the copypages stage of migration is the critical area while other areas are=
 not).

If a vMCE occur at the critical area of live migration, abort and try migra=
tion later.

Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>

diff -r f843ac6f93c9 tools/libxc/xc_domain.c
--- a/tools/libxc/xc_domain.c	Wed Sep 19 01:21:18 2012 +0800
+++ b/tools/libxc/xc_domain.c	Wed Sep 19 03:31:30 2012 +0800
@@ -283,6 +283,37 @@
     return ret;
 }
=20
+/* Start vmce monitor */
+int xc_domain_vmce_monitor_strat(xc_interface *xch,
+                                 uint32_t domid)
+{
+    int ret;
+    DECLARE_DOMCTL;
+
+    domctl.cmd =3D XEN_DOMCTL_vmce_monitor_start;
+    domctl.domain =3D (domid_t)domid;
+    ret =3D do_domctl(xch, &domctl);
+
+    return ret ? -1 : 0;
+}
+
+/* End vmce monitor */
+int xc_domain_vmce_monitor_end(xc_interface *xch,
+                               uint32_t domid,
+                               signed char *vmce_while_monitor)
+{
+    int ret;
+    DECLARE_DOMCTL;
+
+    domctl.cmd =3D XEN_DOMCTL_vmce_monitor_end;
+    domctl.domain =3D (domid_t)domid;
+    ret =3D do_domctl(xch, &domctl);
+    if ( !ret )
+        *vmce_while_monitor =3D domctl.u.vmce_monitor.vmce_while_monitor;
+
+    return ret ? -1 : 0;
+}
+
 /* get info from hvm guest for save */
 int xc_domain_hvm_getcontext(xc_interface *xch,
                              uint32_t domid,
diff -r f843ac6f93c9 tools/libxc/xc_domain_save.c
--- a/tools/libxc/xc_domain_save.c	Wed Sep 19 01:21:18 2012 +0800
+++ b/tools/libxc/xc_domain_save.c	Wed Sep 19 03:31:30 2012 +0800
@@ -895,6 +895,8 @@
      */
     int compressing =3D 0;
=20
+    signed char vmce_while_monitor =3D 0;
+
     int completed =3D 0;
=20
     if ( hvm && !callbacks->switch_qemu_logdirty )
@@ -1109,6 +1111,12 @@
         goto out;
     }
=20
+    if ( xc_domain_vmce_monitor_strat(xch, dom) )
+    {
+        PERROR("Error when start vmce monitor\n");
+        goto out;
+    }
+
   copypages:
 #define wrexact(fd, buf, len) write_buffer(xch, last_iter, ob, (fd), (buf)=
, (len))
 #define wruncached(fd, live, buf, len) write_uncached(xch, last_iter, ob, =
(fd), (buf), (len))
@@ -1571,6 +1579,17 @@
=20
     DPRINTF("All memory is saved\n");
=20
+    if ( xc_domain_vmce_monitor_end(xch, dom, &vmce_while_monitor) )
+    {
+        PERROR("Error when end vmce monitor\n");
+        goto out;
+    }
+    else if ( vmce_while_monitor =3D=3D -1 )
+    {
+        fprintf(stderr, "vMCE occurred, abort this time and try later.\n")=
;
+        goto out;
+    }
+
     /* After last_iter, buffer the rest of pagebuf & tailbuf data into a
      * separate output buffer and flush it after the compressed page chunk=
s.
      */
diff -r f843ac6f93c9 tools/libxc/xenctrl.h
--- a/tools/libxc/xenctrl.h	Wed Sep 19 01:21:18 2012 +0800
+++ b/tools/libxc/xenctrl.h	Wed Sep 19 03:31:30 2012 +0800
@@ -571,6 +571,26 @@
                           xc_domaininfo_t *info);
=20
 /**
+ * This function start monitor vmce event.
+ * @parm xch a handle to an open hypervisor interface
+ * @parm domid the domain id monitored
+ * @return 0 on success, -1 on failure
+ */
+int xc_domain_vmce_monitor_strat(xc_interface *xch,
+                                 uint32_t domid);
+
+/**
+ * This function end monitor vmce event
+ * @parm xch a handle to an open hypervisor interface
+ * @parm domid the domain id monitored
+ * @parm vmce_while_migrate a pointer return whether vMCE occur when migra=
te=20
+ * @return 0 on success, -1 on failure
+ */
+int xc_domain_vmce_monitor_end(xc_interface *xch,
+                               uint32_t domid,
+                               signed char *vmce_while_monitor);
+
+/**
  * This function returns information about the context of a hvm domain
  * @parm xch a handle to an open hypervisor interface
  * @parm domid the domain to get information from
diff -r f843ac6f93c9 xen/arch/x86/cpu/mcheck/mce_intel.c
--- a/xen/arch/x86/cpu/mcheck/mce_intel.c	Wed Sep 19 01:21:18 2012 +0800
+++ b/xen/arch/x86/cpu/mcheck/mce_intel.c	Wed Sep 19 03:31:30 2012 +0800
@@ -596,6 +596,12 @@
                     goto vmce_failed;
                 }
=20
+                if ( unlikely(d->arch.vmce_monitor) )
+                {
+                    /* vMCE occur when guest migration */
+                    d->arch.vmce_monitor =3D -1;
+                }
+
                 /* We will inject vMCE to DOMU*/
                 if ( inject_vmce(d) < 0 )
                 {
diff -r f843ac6f93c9 xen/arch/x86/domctl.c
--- a/xen/arch/x86/domctl.c	Wed Sep 19 01:21:18 2012 +0800
+++ b/xen/arch/x86/domctl.c	Wed Sep 19 03:31:30 2012 +0800
@@ -1514,6 +1514,40 @@
     }
     break;
=20
+    case XEN_DOMCTL_vmce_monitor_start:
+    {
+        struct domain *d;
+
+        d =3D rcu_lock_domain_by_id(domctl->domain);
+        if ( d !=3D NULL )
+        {
+            d->arch.vmce_monitor =3D 1;
+            rcu_unlock_domain(d);
+        }
+        else
+            ret =3D -ESRCH;
+    }
+    break;
+
+    case XEN_DOMCTL_vmce_monitor_end:
+    {
+        struct domain *d;
+
+        d =3D rcu_lock_domain_by_id(domctl->domain);
+        if ( d !=3D NULL)
+        {
+            domctl->u.vmce_monitor.vmce_while_monitor =3D
+                                      d->arch.vmce_monitor;
+            d->arch.vmce_monitor =3D 0;
+            rcu_unlock_domain(d);
+            if ( copy_to_guest(u_domctl, domctl, 1) )
+                ret =3D -EFAULT;
+        }
+        else
+            ret =3D -ESRCH;
+    }
+    break;
+
     default:
         ret =3D iommu_do_domctl(domctl, u_domctl);
         break;
diff -r f843ac6f93c9 xen/include/asm-x86/domain.h
--- a/xen/include/asm-x86/domain.h	Wed Sep 19 01:21:18 2012 +0800
+++ b/xen/include/asm-x86/domain.h	Wed Sep 19 03:31:30 2012 +0800
@@ -279,6 +279,11 @@
     bool_t has_32bit_shinfo;
     /* Domain cannot handle spurious page faults? */
     bool_t suppress_spurious_page_faults;
+    /* Monitoring guest memory copy of migration
+     * =3D 0 - not monitoring
+     * > 0 - monitoring
+     * < 0 - vMCE occurred while monitoring */
+    s8 vmce_monitor;
=20
     /* Continuable domain_relinquish_resources(). */
     enum {
diff -r f843ac6f93c9 xen/include/public/domctl.h
--- a/xen/include/public/domctl.h	Wed Sep 19 01:21:18 2012 +0800
+++ b/xen/include/public/domctl.h	Wed Sep 19 03:31:30 2012 +0800
@@ -828,6 +828,12 @@
 typedef struct xen_domctl_set_access_required xen_domctl_set_access_requir=
ed_t;
 DEFINE_XEN_GUEST_HANDLE(xen_domctl_set_access_required_t);
=20
+struct xen_domctl_vmce_monitor {
+    signed char vmce_while_monitor;
+};
+typedef struct xen_domctl_vmce_monitor xen_domctl_vmce_monitor_t;
+DEFINE_XEN_GUEST_HANDLE(xen_domctl_vmce_monitor_t);
+
 struct xen_domctl {
     uint32_t cmd;
 #define XEN_DOMCTL_createdomain                   1
@@ -893,6 +899,8 @@
 #define XEN_DOMCTL_set_access_required           64
 #define XEN_DOMCTL_audit_p2m                     65
 #define XEN_DOMCTL_set_virq_handler              66
+#define XEN_DOMCTL_vmce_monitor_start            67
+#define XEN_DOMCTL_vmce_monitor_end              68
 #define XEN_DOMCTL_gdbsx_guestmemio            1000
 #define XEN_DOMCTL_gdbsx_pausevcpu             1001
 #define XEN_DOMCTL_gdbsx_unpausevcpu           1002
@@ -947,6 +955,7 @@
         struct xen_domctl_set_access_required access_required;
         struct xen_domctl_audit_p2m         audit_p2m;
         struct xen_domctl_set_virq_handler  set_virq_handler;
+        struct xen_domctl_vmce_monitor      vmce_monitor;
         struct xen_domctl_gdbsx_memio       gdbsx_guest_memio;
         struct xen_domctl_gdbsx_pauseunp_vcpu gdbsx_pauseunp_vcpu;
         struct xen_domctl_gdbsx_domstatus   gdbsx_domstatus;=

--_002_DE8DF0795D48FD4CA783C40EC829233532F43ASHSMSX101ccrcorpi_
Content-Type: application/octet-stream; name="4_vmce_when_migrate.patch"
Content-Description: 4_vmce_when_migrate.patch
Content-Disposition: attachment; filename="4_vmce_when_migrate.patch";
	size=7729; creation-date="Tue, 18 Sep 2012 13:04:35 GMT";
	modification-date="Tue, 18 Sep 2012 19:31:30 GMT"
Content-Transfer-Encoding: base64

WGVuL01DRTogQWJvcnQgbGl2ZSBtaWdyYXRpb24gd2hlbiB2TUNFIG9jY3VyCgpUaGlzIHBhdGNo
IG1vbml0b3IgdGhlIGNyaXRpY2FsIGFyZWEgb2YgbGl2ZSBtaWdyYXRpb24gKGZyb20gdk1DRSBw
b2ludCBvZiB2aWV3LAp0aGUgY29weXBhZ2VzIHN0YWdlIG9mIG1pZ3JhdGlvbiBpcyB0aGUgY3Jp
dGljYWwgYXJlYSB3aGlsZSBvdGhlciBhcmVhcyBhcmUgbm90KS4KCklmIGEgdk1DRSBvY2N1ciBh
dCB0aGUgY3JpdGljYWwgYXJlYSBvZiBsaXZlIG1pZ3JhdGlvbiwgYWJvcnQgYW5kIHRyeSBtaWdy
YXRpb24gbGF0ZXIuCgpTaWduZWQtb2ZmLWJ5OiBMaXUsIEppbnNvbmcgPGppbnNvbmcubGl1QGlu
dGVsLmNvbT4KCmRpZmYgLXIgZjg0M2FjNmY5M2M5IHRvb2xzL2xpYnhjL3hjX2RvbWFpbi5jCi0t
LSBhL3Rvb2xzL2xpYnhjL3hjX2RvbWFpbi5jCVdlZCBTZXAgMTkgMDE6MjE6MTggMjAxMiArMDgw
MAorKysgYi90b29scy9saWJ4Yy94Y19kb21haW4uYwlXZWQgU2VwIDE5IDAzOjMxOjMwIDIwMTIg
KzA4MDAKQEAgLTI4Myw2ICsyODMsMzcgQEAKICAgICByZXR1cm4gcmV0OwogfQogCisvKiBTdGFy
dCB2bWNlIG1vbml0b3IgKi8KK2ludCB4Y19kb21haW5fdm1jZV9tb25pdG9yX3N0cmF0KHhjX2lu
dGVyZmFjZSAqeGNoLAorICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgdWludDMyX3Qg
ZG9taWQpCit7CisgICAgaW50IHJldDsKKyAgICBERUNMQVJFX0RPTUNUTDsKKworICAgIGRvbWN0
bC5jbWQgPSBYRU5fRE9NQ1RMX3ZtY2VfbW9uaXRvcl9zdGFydDsKKyAgICBkb21jdGwuZG9tYWlu
ID0gKGRvbWlkX3QpZG9taWQ7CisgICAgcmV0ID0gZG9fZG9tY3RsKHhjaCwgJmRvbWN0bCk7CisK
KyAgICByZXR1cm4gcmV0ID8gLTEgOiAwOworfQorCisvKiBFbmQgdm1jZSBtb25pdG9yICovCitp
bnQgeGNfZG9tYWluX3ZtY2VfbW9uaXRvcl9lbmQoeGNfaW50ZXJmYWNlICp4Y2gsCisgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgdWludDMyX3QgZG9taWQsCisgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgc2lnbmVkIGNoYXIgKnZtY2Vfd2hpbGVfbW9uaXRvcikKK3sKKyAgICBp
bnQgcmV0OworICAgIERFQ0xBUkVfRE9NQ1RMOworCisgICAgZG9tY3RsLmNtZCA9IFhFTl9ET01D
VExfdm1jZV9tb25pdG9yX2VuZDsKKyAgICBkb21jdGwuZG9tYWluID0gKGRvbWlkX3QpZG9taWQ7
CisgICAgcmV0ID0gZG9fZG9tY3RsKHhjaCwgJmRvbWN0bCk7CisgICAgaWYgKCAhcmV0ICkKKyAg
ICAgICAgKnZtY2Vfd2hpbGVfbW9uaXRvciA9IGRvbWN0bC51LnZtY2VfbW9uaXRvci52bWNlX3do
aWxlX21vbml0b3I7CisKKyAgICByZXR1cm4gcmV0ID8gLTEgOiAwOworfQorCiAvKiBnZXQgaW5m
byBmcm9tIGh2bSBndWVzdCBmb3Igc2F2ZSAqLwogaW50IHhjX2RvbWFpbl9odm1fZ2V0Y29udGV4
dCh4Y19pbnRlcmZhY2UgKnhjaCwKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgdWludDMy
X3QgZG9taWQsCmRpZmYgLXIgZjg0M2FjNmY5M2M5IHRvb2xzL2xpYnhjL3hjX2RvbWFpbl9zYXZl
LmMKLS0tIGEvdG9vbHMvbGlieGMveGNfZG9tYWluX3NhdmUuYwlXZWQgU2VwIDE5IDAxOjIxOjE4
IDIwMTIgKzA4MDAKKysrIGIvdG9vbHMvbGlieGMveGNfZG9tYWluX3NhdmUuYwlXZWQgU2VwIDE5
IDAzOjMxOjMwIDIwMTIgKzA4MDAKQEAgLTg5NSw2ICs4OTUsOCBAQAogICAgICAqLwogICAgIGlu
dCBjb21wcmVzc2luZyA9IDA7CiAKKyAgICBzaWduZWQgY2hhciB2bWNlX3doaWxlX21vbml0b3Ig
PSAwOworCiAgICAgaW50IGNvbXBsZXRlZCA9IDA7CiAKICAgICBpZiAoIGh2bSAmJiAhY2FsbGJh
Y2tzLT5zd2l0Y2hfcWVtdV9sb2dkaXJ0eSApCkBAIC0xMTA5LDYgKzExMTEsMTIgQEAKICAgICAg
ICAgZ290byBvdXQ7CiAgICAgfQogCisgICAgaWYgKCB4Y19kb21haW5fdm1jZV9tb25pdG9yX3N0
cmF0KHhjaCwgZG9tKSApCisgICAgeworICAgICAgICBQRVJST1IoIkVycm9yIHdoZW4gc3RhcnQg
dm1jZSBtb25pdG9yXG4iKTsKKyAgICAgICAgZ290byBvdXQ7CisgICAgfQorCiAgIGNvcHlwYWdl
czoKICNkZWZpbmUgd3JleGFjdChmZCwgYnVmLCBsZW4pIHdyaXRlX2J1ZmZlcih4Y2gsIGxhc3Rf
aXRlciwgb2IsIChmZCksIChidWYpLCAobGVuKSkKICNkZWZpbmUgd3J1bmNhY2hlZChmZCwgbGl2
ZSwgYnVmLCBsZW4pIHdyaXRlX3VuY2FjaGVkKHhjaCwgbGFzdF9pdGVyLCBvYiwgKGZkKSwgKGJ1
ZiksIChsZW4pKQpAQCAtMTU3MSw2ICsxNTc5LDE3IEBACiAKICAgICBEUFJJTlRGKCJBbGwgbWVt
b3J5IGlzIHNhdmVkXG4iKTsKIAorICAgIGlmICggeGNfZG9tYWluX3ZtY2VfbW9uaXRvcl9lbmQo
eGNoLCBkb20sICZ2bWNlX3doaWxlX21vbml0b3IpICkKKyAgICB7CisgICAgICAgIFBFUlJPUigi
RXJyb3Igd2hlbiBlbmQgdm1jZSBtb25pdG9yXG4iKTsKKyAgICAgICAgZ290byBvdXQ7CisgICAg
fQorICAgIGVsc2UgaWYgKCB2bWNlX3doaWxlX21vbml0b3IgPT0gLTEgKQorICAgIHsKKyAgICAg
ICAgZnByaW50ZihzdGRlcnIsICJ2TUNFIG9jY3VycmVkLCBhYm9ydCB0aGlzIHRpbWUgYW5kIHRy
eSBsYXRlci5cbiIpOworICAgICAgICBnb3RvIG91dDsKKyAgICB9CisKICAgICAvKiBBZnRlciBs
YXN0X2l0ZXIsIGJ1ZmZlciB0aGUgcmVzdCBvZiBwYWdlYnVmICYgdGFpbGJ1ZiBkYXRhIGludG8g
YQogICAgICAqIHNlcGFyYXRlIG91dHB1dCBidWZmZXIgYW5kIGZsdXNoIGl0IGFmdGVyIHRoZSBj
b21wcmVzc2VkIHBhZ2UgY2h1bmtzLgogICAgICAqLwpkaWZmIC1yIGY4NDNhYzZmOTNjOSB0b29s
cy9saWJ4Yy94ZW5jdHJsLmgKLS0tIGEvdG9vbHMvbGlieGMveGVuY3RybC5oCVdlZCBTZXAgMTkg
MDE6MjE6MTggMjAxMiArMDgwMAorKysgYi90b29scy9saWJ4Yy94ZW5jdHJsLmgJV2VkIFNlcCAx
OSAwMzozMTozMCAyMDEyICswODAwCkBAIC01NzEsNiArNTcxLDI2IEBACiAgICAgICAgICAgICAg
ICAgICAgICAgICAgIHhjX2RvbWFpbmluZm9fdCAqaW5mbyk7CiAKIC8qKgorICogVGhpcyBmdW5j
dGlvbiBzdGFydCBtb25pdG9yIHZtY2UgZXZlbnQuCisgKiBAcGFybSB4Y2ggYSBoYW5kbGUgdG8g
YW4gb3BlbiBoeXBlcnZpc29yIGludGVyZmFjZQorICogQHBhcm0gZG9taWQgdGhlIGRvbWFpbiBp
ZCBtb25pdG9yZWQKKyAqIEByZXR1cm4gMCBvbiBzdWNjZXNzLCAtMSBvbiBmYWlsdXJlCisgKi8K
K2ludCB4Y19kb21haW5fdm1jZV9tb25pdG9yX3N0cmF0KHhjX2ludGVyZmFjZSAqeGNoLAorICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgdWludDMyX3QgZG9taWQpOworCisvKioKKyAq
IFRoaXMgZnVuY3Rpb24gZW5kIG1vbml0b3Igdm1jZSBldmVudAorICogQHBhcm0geGNoIGEgaGFu
ZGxlIHRvIGFuIG9wZW4gaHlwZXJ2aXNvciBpbnRlcmZhY2UKKyAqIEBwYXJtIGRvbWlkIHRoZSBk
b21haW4gaWQgbW9uaXRvcmVkCisgKiBAcGFybSB2bWNlX3doaWxlX21pZ3JhdGUgYSBwb2ludGVy
IHJldHVybiB3aGV0aGVyIHZNQ0Ugb2NjdXIgd2hlbiBtaWdyYXRlIAorICogQHJldHVybiAwIG9u
IHN1Y2Nlc3MsIC0xIG9uIGZhaWx1cmUKKyAqLworaW50IHhjX2RvbWFpbl92bWNlX21vbml0b3Jf
ZW5kKHhjX2ludGVyZmFjZSAqeGNoLAorICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHVp
bnQzMl90IGRvbWlkLAorICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHNpZ25lZCBjaGFy
ICp2bWNlX3doaWxlX21vbml0b3IpOworCisvKioKICAqIFRoaXMgZnVuY3Rpb24gcmV0dXJucyBp
bmZvcm1hdGlvbiBhYm91dCB0aGUgY29udGV4dCBvZiBhIGh2bSBkb21haW4KICAqIEBwYXJtIHhj
aCBhIGhhbmRsZSB0byBhbiBvcGVuIGh5cGVydmlzb3IgaW50ZXJmYWNlCiAgKiBAcGFybSBkb21p
ZCB0aGUgZG9tYWluIHRvIGdldCBpbmZvcm1hdGlvbiBmcm9tCmRpZmYgLXIgZjg0M2FjNmY5M2M5
IHhlbi9hcmNoL3g4Ni9jcHUvbWNoZWNrL21jZV9pbnRlbC5jCi0tLSBhL3hlbi9hcmNoL3g4Ni9j
cHUvbWNoZWNrL21jZV9pbnRlbC5jCVdlZCBTZXAgMTkgMDE6MjE6MTggMjAxMiArMDgwMAorKysg
Yi94ZW4vYXJjaC94ODYvY3B1L21jaGVjay9tY2VfaW50ZWwuYwlXZWQgU2VwIDE5IDAzOjMxOjMw
IDIwMTIgKzA4MDAKQEAgLTU5Niw2ICs1OTYsMTIgQEAKICAgICAgICAgICAgICAgICAgICAgZ290
byB2bWNlX2ZhaWxlZDsKICAgICAgICAgICAgICAgICB9CiAKKyAgICAgICAgICAgICAgICBpZiAo
IHVubGlrZWx5KGQtPmFyY2gudm1jZV9tb25pdG9yKSApCisgICAgICAgICAgICAgICAgeworICAg
ICAgICAgICAgICAgICAgICAvKiB2TUNFIG9jY3VyIHdoZW4gZ3Vlc3QgbWlncmF0aW9uICovCisg
ICAgICAgICAgICAgICAgICAgIGQtPmFyY2gudm1jZV9tb25pdG9yID0gLTE7CisgICAgICAgICAg
ICAgICAgfQorCiAgICAgICAgICAgICAgICAgLyogV2Ugd2lsbCBpbmplY3Qgdk1DRSB0byBET01V
Ki8KICAgICAgICAgICAgICAgICBpZiAoIGluamVjdF92bWNlKGQpIDwgMCApCiAgICAgICAgICAg
ICAgICAgewpkaWZmIC1yIGY4NDNhYzZmOTNjOSB4ZW4vYXJjaC94ODYvZG9tY3RsLmMKLS0tIGEv
eGVuL2FyY2gveDg2L2RvbWN0bC5jCVdlZCBTZXAgMTkgMDE6MjE6MTggMjAxMiArMDgwMAorKysg
Yi94ZW4vYXJjaC94ODYvZG9tY3RsLmMJV2VkIFNlcCAxOSAwMzozMTozMCAyMDEyICswODAwCkBA
IC0xNTE0LDYgKzE1MTQsNDAgQEAKICAgICB9CiAgICAgYnJlYWs7CiAKKyAgICBjYXNlIFhFTl9E
T01DVExfdm1jZV9tb25pdG9yX3N0YXJ0OgorICAgIHsKKyAgICAgICAgc3RydWN0IGRvbWFpbiAq
ZDsKKworICAgICAgICBkID0gcmN1X2xvY2tfZG9tYWluX2J5X2lkKGRvbWN0bC0+ZG9tYWluKTsK
KyAgICAgICAgaWYgKCBkICE9IE5VTEwgKQorICAgICAgICB7CisgICAgICAgICAgICBkLT5hcmNo
LnZtY2VfbW9uaXRvciA9IDE7CisgICAgICAgICAgICByY3VfdW5sb2NrX2RvbWFpbihkKTsKKyAg
ICAgICAgfQorICAgICAgICBlbHNlCisgICAgICAgICAgICByZXQgPSAtRVNSQ0g7CisgICAgfQor
ICAgIGJyZWFrOworCisgICAgY2FzZSBYRU5fRE9NQ1RMX3ZtY2VfbW9uaXRvcl9lbmQ6CisgICAg
eworICAgICAgICBzdHJ1Y3QgZG9tYWluICpkOworCisgICAgICAgIGQgPSByY3VfbG9ja19kb21h
aW5fYnlfaWQoZG9tY3RsLT5kb21haW4pOworICAgICAgICBpZiAoIGQgIT0gTlVMTCkKKyAgICAg
ICAgeworICAgICAgICAgICAgZG9tY3RsLT51LnZtY2VfbW9uaXRvci52bWNlX3doaWxlX21vbml0
b3IgPQorICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBkLT5hcmNoLnZtY2Vf
bW9uaXRvcjsKKyAgICAgICAgICAgIGQtPmFyY2gudm1jZV9tb25pdG9yID0gMDsKKyAgICAgICAg
ICAgIHJjdV91bmxvY2tfZG9tYWluKGQpOworICAgICAgICAgICAgaWYgKCBjb3B5X3RvX2d1ZXN0
KHVfZG9tY3RsLCBkb21jdGwsIDEpICkKKyAgICAgICAgICAgICAgICByZXQgPSAtRUZBVUxUOwor
ICAgICAgICB9CisgICAgICAgIGVsc2UKKyAgICAgICAgICAgIHJldCA9IC1FU1JDSDsKKyAgICB9
CisgICAgYnJlYWs7CisKICAgICBkZWZhdWx0OgogICAgICAgICByZXQgPSBpb21tdV9kb19kb21j
dGwoZG9tY3RsLCB1X2RvbWN0bCk7CiAgICAgICAgIGJyZWFrOwpkaWZmIC1yIGY4NDNhYzZmOTNj
OSB4ZW4vaW5jbHVkZS9hc20teDg2L2RvbWFpbi5oCi0tLSBhL3hlbi9pbmNsdWRlL2FzbS14ODYv
ZG9tYWluLmgJV2VkIFNlcCAxOSAwMToyMToxOCAyMDEyICswODAwCisrKyBiL3hlbi9pbmNsdWRl
L2FzbS14ODYvZG9tYWluLmgJV2VkIFNlcCAxOSAwMzozMTozMCAyMDEyICswODAwCkBAIC0yNzks
NiArMjc5LDExIEBACiAgICAgYm9vbF90IGhhc18zMmJpdF9zaGluZm87CiAgICAgLyogRG9tYWlu
IGNhbm5vdCBoYW5kbGUgc3B1cmlvdXMgcGFnZSBmYXVsdHM/ICovCiAgICAgYm9vbF90IHN1cHBy
ZXNzX3NwdXJpb3VzX3BhZ2VfZmF1bHRzOworICAgIC8qIE1vbml0b3JpbmcgZ3Vlc3QgbWVtb3J5
IGNvcHkgb2YgbWlncmF0aW9uCisgICAgICogPSAwIC0gbm90IG1vbml0b3JpbmcKKyAgICAgKiA+
IDAgLSBtb25pdG9yaW5nCisgICAgICogPCAwIC0gdk1DRSBvY2N1cnJlZCB3aGlsZSBtb25pdG9y
aW5nICovCisgICAgczggdm1jZV9tb25pdG9yOwogCiAgICAgLyogQ29udGludWFibGUgZG9tYWlu
X3JlbGlucXVpc2hfcmVzb3VyY2VzKCkuICovCiAgICAgZW51bSB7CmRpZmYgLXIgZjg0M2FjNmY5
M2M5IHhlbi9pbmNsdWRlL3B1YmxpYy9kb21jdGwuaAotLS0gYS94ZW4vaW5jbHVkZS9wdWJsaWMv
ZG9tY3RsLmgJV2VkIFNlcCAxOSAwMToyMToxOCAyMDEyICswODAwCisrKyBiL3hlbi9pbmNsdWRl
L3B1YmxpYy9kb21jdGwuaAlXZWQgU2VwIDE5IDAzOjMxOjMwIDIwMTIgKzA4MDAKQEAgLTgyOCw2
ICs4MjgsMTIgQEAKIHR5cGVkZWYgc3RydWN0IHhlbl9kb21jdGxfc2V0X2FjY2Vzc19yZXF1aXJl
ZCB4ZW5fZG9tY3RsX3NldF9hY2Nlc3NfcmVxdWlyZWRfdDsKIERFRklORV9YRU5fR1VFU1RfSEFO
RExFKHhlbl9kb21jdGxfc2V0X2FjY2Vzc19yZXF1aXJlZF90KTsKIAorc3RydWN0IHhlbl9kb21j
dGxfdm1jZV9tb25pdG9yIHsKKyAgICBzaWduZWQgY2hhciB2bWNlX3doaWxlX21vbml0b3I7Cit9
OwordHlwZWRlZiBzdHJ1Y3QgeGVuX2RvbWN0bF92bWNlX21vbml0b3IgeGVuX2RvbWN0bF92bWNl
X21vbml0b3JfdDsKK0RFRklORV9YRU5fR1VFU1RfSEFORExFKHhlbl9kb21jdGxfdm1jZV9tb25p
dG9yX3QpOworCiBzdHJ1Y3QgeGVuX2RvbWN0bCB7CiAgICAgdWludDMyX3QgY21kOwogI2RlZmlu
ZSBYRU5fRE9NQ1RMX2NyZWF0ZWRvbWFpbiAgICAgICAgICAgICAgICAgICAxCkBAIC04OTMsNiAr
ODk5LDggQEAKICNkZWZpbmUgWEVOX0RPTUNUTF9zZXRfYWNjZXNzX3JlcXVpcmVkICAgICAgICAg
ICA2NAogI2RlZmluZSBYRU5fRE9NQ1RMX2F1ZGl0X3AybSAgICAgICAgICAgICAgICAgICAgIDY1
CiAjZGVmaW5lIFhFTl9ET01DVExfc2V0X3ZpcnFfaGFuZGxlciAgICAgICAgICAgICAgNjYKKyNk
ZWZpbmUgWEVOX0RPTUNUTF92bWNlX21vbml0b3Jfc3RhcnQgICAgICAgICAgICA2NworI2RlZmlu
ZSBYRU5fRE9NQ1RMX3ZtY2VfbW9uaXRvcl9lbmQgICAgICAgICAgICAgIDY4CiAjZGVmaW5lIFhF
Tl9ET01DVExfZ2Ric3hfZ3Vlc3RtZW1pbyAgICAgICAgICAgIDEwMDAKICNkZWZpbmUgWEVOX0RP
TUNUTF9nZGJzeF9wYXVzZXZjcHUgICAgICAgICAgICAgMTAwMQogI2RlZmluZSBYRU5fRE9NQ1RM
X2dkYnN4X3VucGF1c2V2Y3B1ICAgICAgICAgICAxMDAyCkBAIC05NDcsNiArOTU1LDcgQEAKICAg
ICAgICAgc3RydWN0IHhlbl9kb21jdGxfc2V0X2FjY2Vzc19yZXF1aXJlZCBhY2Nlc3NfcmVxdWly
ZWQ7CiAgICAgICAgIHN0cnVjdCB4ZW5fZG9tY3RsX2F1ZGl0X3AybSAgICAgICAgIGF1ZGl0X3Ay
bTsKICAgICAgICAgc3RydWN0IHhlbl9kb21jdGxfc2V0X3ZpcnFfaGFuZGxlciAgc2V0X3ZpcnFf
aGFuZGxlcjsKKyAgICAgICAgc3RydWN0IHhlbl9kb21jdGxfdm1jZV9tb25pdG9yICAgICAgdm1j
ZV9tb25pdG9yOwogICAgICAgICBzdHJ1Y3QgeGVuX2RvbWN0bF9nZGJzeF9tZW1pbyAgICAgICBn
ZGJzeF9ndWVzdF9tZW1pbzsKICAgICAgICAgc3RydWN0IHhlbl9kb21jdGxfZ2Ric3hfcGF1c2V1
bnBfdmNwdSBnZGJzeF9wYXVzZXVucF92Y3B1OwogICAgICAgICBzdHJ1Y3QgeGVuX2RvbWN0bF9n
ZGJzeF9kb21zdGF0dXMgICBnZGJzeF9kb21zdGF0dXM7Cg==

--_002_DE8DF0795D48FD4CA783C40EC829233532F43ASHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 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_DE8DF0795D48FD4CA783C40EC829233532F43ASHSMSX101ccrcorpi_--


From xen-devel-bounces@lists.xen.org Tue Sep 18 13:18:34 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Sep 2012 13:18:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDxh0-0005xl-Vk; Tue, 18 Sep 2012 13:18:22 +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 1TDxgz-0005xU-8U
	for xen-devel@lists.xensource.com; Tue, 18 Sep 2012 13:18:21 +0000
Received: from [85.158.143.99:39977] by server-1.bemta-4.messagelabs.com id
	1E/FD-12504-C9478505; Tue, 18 Sep 2012 13:18:20 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1347974298!21047481!1
X-Originating-IP: [134.134.136.20]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjAgPT4gMjk5NTk2\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16439 invoked from network); 18 Sep 2012 13:18:18 -0000
Received: from mga02.intel.com (HELO mga02.intel.com) (134.134.136.20)
	by server-8.tower-216.messagelabs.com with SMTP;
	18 Sep 2012 13:18:18 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga101.jf.intel.com with ESMTP; 18 Sep 2012 06:18:17 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.80,442,1344236400"; d="scan'208";a="206969750"
Received: from fmsmsx106.amr.corp.intel.com ([10.19.9.37])
	by orsmga002.jf.intel.com with ESMTP; 18 Sep 2012 06:18:17 -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; Tue, 18 Sep 2012 06:18:16 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.239]) by
	SHSMSX102.ccr.corp.intel.com ([169.254.2.92]) with mapi id
	14.01.0355.002; Tue, 18 Sep 2012 21:18:14 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: Jan Beulich <JBeulich@suse.com>, "xen-devel@lists.xensource.com"
	<xen-devel@lists.xensource.com>
Thread-Topic: [PATCH 5/5] X86/vMCE: guest broken page handling when migration
Thread-Index: Ac2VoA7ttrocVu+MQEqEans0Ia15+Q==
Date: Tue, 18 Sep 2012 13:18:14 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC829233532F451@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_DE8DF0795D48FD4CA783C40EC829233532F451SHSMSX101ccrcorpi_"
MIME-Version: 1.0
Cc: "keir@xen.org" <keir@xen.org>,
	"Ian.Campbell@citrix.com" <Ian.Campbell@citrix.com>
Subject: [Xen-devel] [PATCH 5/5] X86/vMCE: guest broken page handling when
	migration
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--_002_DE8DF0795D48FD4CA783C40EC829233532F451SHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

X86/vMCE: guest broken page handling when migration

This patch is used to handle guest broken page when migration.

At sender, the broken page would not be mapped, and the error page
content would not be copied to target, otherwise it may trigger more
serious error (i.e. SRAR error). While its pfn_type and pfn number
would be transferred to target so that target take appropriate action.

At target, it would set p2m as p2m_ram_broken for broken page, so that
if guest access the broken page again, it would kill guest as expected.

Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>

diff -r a1d106d1aec8 tools/libxc/xc_domain.c
--- a/tools/libxc/xc_domain.c	Wed Sep 19 03:31:31 2012 +0800
+++ b/tools/libxc/xc_domain.c	Wed Sep 19 04:22:26 2012 +0800
@@ -314,6 +314,22 @@
     return ret ? -1 : 0;
 }
=20
+/* set broken page p2m */
+int xc_set_broken_page_p2m(xc_interface *xch,
+                           uint32_t domid,
+                           unsigned long pfn)
+{
+    int ret;
+    DECLARE_DOMCTL;
+
+    domctl.cmd =3D XEN_DOMCTL_set_broken_page_p2m;
+    domctl.domain =3D (domid_t)domid;
+    domctl.u.set_broken_page_p2m.pfn =3D pfn;
+    ret =3D do_domctl(xch, &domctl);
+
+    return ret ? -1 : 0;
+}
+
 /* get info from hvm guest for save */
 int xc_domain_hvm_getcontext(xc_interface *xch,
                              uint32_t domid,
diff -r a1d106d1aec8 tools/libxc/xc_domain_restore.c
--- a/tools/libxc/xc_domain_restore.c	Wed Sep 19 03:31:31 2012 +0800
+++ b/tools/libxc/xc_domain_restore.c	Wed Sep 19 04:22:26 2012 +0800
@@ -962,9 +962,15 @@
=20
     countpages =3D count;
     for (i =3D oldcount; i < buf->nr_pages; ++i)
-        if ((buf->pfn_types[i] & XEN_DOMCTL_PFINFO_LTAB_MASK) =3D=3D XEN_D=
OMCTL_PFINFO_XTAB
-            ||(buf->pfn_types[i] & XEN_DOMCTL_PFINFO_LTAB_MASK) =3D=3D XEN=
_DOMCTL_PFINFO_XALLOC)
+    {
+        unsigned long pagetype;
+
+        pagetype =3D buf->pfn_types[i] & XEN_DOMCTL_PFINFO_LTAB_MASK;
+        if ( pagetype =3D=3D XEN_DOMCTL_PFINFO_XTAB ||
+             pagetype =3D=3D XEN_DOMCTL_PFINFO_BROKEN ||
+             pagetype =3D=3D XEN_DOMCTL_PFINFO_XALLOC )
             --countpages;
+    }
=20
     if (!countpages)
         return count;
@@ -1200,6 +1206,17 @@
             /* a bogus/unmapped/allocate-only page: skip it */
             continue;
=20
+        if ( pagetype =3D=3D XEN_DOMCTL_PFINFO_BROKEN )
+        {
+            if ( xc_set_broken_page_p2m(xch, dom, pfn) )
+            {
+                ERROR("Set p2m for broken page fail, "
+                      "dom=3D%d, pfn=3D%lx\n", dom, pfn);
+                goto err_mapped;
+            }
+            continue;
+        }
+
         if (pfn_err[i])
         {
             ERROR("unexpected PFN mapping failure pfn %lx map_mfn %lx p2m_=
mfn %lx",
diff -r a1d106d1aec8 tools/libxc/xc_domain_save.c
--- a/tools/libxc/xc_domain_save.c	Wed Sep 19 03:31:31 2012 +0800
+++ b/tools/libxc/xc_domain_save.c	Wed Sep 19 04:22:26 2012 +0800
@@ -1285,6 +1285,13 @@
                 if ( !hvm )
                     gmfn =3D pfn_to_mfn(gmfn);
=20
+                if ( pfn_type[j] =3D=3D XEN_DOMCTL_PFINFO_BROKEN )
+                {
+                    pfn_type[j] |=3D pfn_batch[j];
+                    ++run;
+                    continue;
+                }
+
                 if ( pfn_err[j] )
                 {
                     if ( pfn_type[j] =3D=3D XEN_DOMCTL_PFINFO_XTAB )
@@ -1379,8 +1386,12 @@
                     }
                 }
=20
-                /* skip pages that aren't present or are alloc-only */
+                /*
+                 * skip pages that aren't present,
+                 * or are broken, or are alloc-only
+                 */
                 if ( pagetype =3D=3D XEN_DOMCTL_PFINFO_XTAB
+                    || pagetype =3D=3D XEN_DOMCTL_PFINFO_BROKEN
                     || pagetype =3D=3D XEN_DOMCTL_PFINFO_XALLOC )
                     continue;
=20
diff -r a1d106d1aec8 tools/libxc/xenctrl.h
--- a/tools/libxc/xenctrl.h	Wed Sep 19 03:31:31 2012 +0800
+++ b/tools/libxc/xenctrl.h	Wed Sep 19 04:22:26 2012 +0800
@@ -591,6 +591,17 @@
                                signed char *vmce_while_monitor);
=20
 /**
+ * This function set p2m for broken page
+ * &parm xch a handle to an open hypervisor interface
+ * @parm domid the domain id which broken page belong to
+ * @parm pfn the pfn number of the broken page
+ * @return 0 on success, -1 on failure
+ */
+int xc_set_broken_page_p2m(xc_interface *xch,
+                           uint32_t domid,
+                           unsigned long pfn);
+
+/**
  * This function returns information about the context of a hvm domain
  * @parm xch a handle to an open hypervisor interface
  * @parm domid the domain to get information from
diff -r a1d106d1aec8 xen/arch/x86/domctl.c
--- a/xen/arch/x86/domctl.c	Wed Sep 19 03:31:31 2012 +0800
+++ b/xen/arch/x86/domctl.c	Wed Sep 19 04:22:26 2012 +0800
@@ -209,12 +209,18 @@
                 for ( j =3D 0; j < k; j++ )
                 {
                     unsigned long type =3D 0;
+                    p2m_type_t t;
=20
-                    page =3D get_page_from_gfn(d, arr[j], NULL, P2M_ALLOC)=
;
+                    page =3D get_page_from_gfn(d, arr[j], &t, P2M_ALLOC);
=20
                     if ( unlikely(!page) ||
                          unlikely(is_xen_heap_page(page)) )
-                        type =3D XEN_DOMCTL_PFINFO_XTAB;
+                    {
+                        if ( p2m_is_broken(t) )
+                            type =3D XEN_DOMCTL_PFINFO_BROKEN;
+                        else
+                            type =3D XEN_DOMCTL_PFINFO_XTAB;
+                    }
                     else
                     {
                         switch( page->u.inuse.type_info & PGT_type_mask )
@@ -235,6 +241,9 @@
=20
                         if ( page->u.inuse.type_info & PGT_pinned )
                             type |=3D XEN_DOMCTL_PFINFO_LPINTAB;
+
+                        if ( page->count_info & PGC_broken )
+                            type =3D XEN_DOMCTL_PFINFO_BROKEN;
                     }
=20
                     if ( page )
@@ -1548,6 +1557,28 @@
     }
     break;
=20
+    case XEN_DOMCTL_set_broken_page_p2m:
+    {
+        struct domain *d;
+        p2m_type_t pt;
+        unsigned long pfn;
+
+        d =3D rcu_lock_domain_by_id(domctl->domain);
+        if ( d !=3D NULL )
+        {
+            pfn =3D domctl->u.set_broken_page_p2m.pfn;
+
+            get_gfn_query(d, pfn, &pt);
+            p2m_change_type(d, pfn, pt, p2m_ram_broken);
+            put_gfn(d, pfn);
+
+            rcu_unlock_domain(d);
+        }
+        else
+            ret =3D -ESRCH;
+    }
+    break;
+
     default:
         ret =3D iommu_do_domctl(domctl, u_domctl);
         break;
diff -r a1d106d1aec8 xen/include/public/domctl.h
--- a/xen/include/public/domctl.h	Wed Sep 19 03:31:31 2012 +0800
+++ b/xen/include/public/domctl.h	Wed Sep 19 04:22:26 2012 +0800
@@ -136,6 +136,7 @@
 #define XEN_DOMCTL_PFINFO_LPINTAB (0x1U<<31)
 #define XEN_DOMCTL_PFINFO_XTAB    (0xfU<<28) /* invalid page */
 #define XEN_DOMCTL_PFINFO_XALLOC  (0xeU<<28) /* allocate-only page */
+#define XEN_DOMCTL_PFINFO_BROKEN  (0xdU<<28) /* broken page */
 #define XEN_DOMCTL_PFINFO_PAGEDTAB (0x8U<<28)
 #define XEN_DOMCTL_PFINFO_LTAB_MASK (0xfU<<28)
=20
@@ -834,6 +835,12 @@
 typedef struct xen_domctl_vmce_monitor xen_domctl_vmce_monitor_t;
 DEFINE_XEN_GUEST_HANDLE(xen_domctl_vmce_monitor_t);
=20
+struct xen_domctl_set_broken_page_p2m {
+    uint64_t pfn;
+};
+typedef struct xen_domctl_set_broken_page_p2m xen_domctl_set_broken_page_p=
2m_t;
+DEFINE_XEN_GUEST_HANDLE(xen_domctl_set_broken_page_p2m_t);
+
 struct xen_domctl {
     uint32_t cmd;
 #define XEN_DOMCTL_createdomain                   1
@@ -901,6 +908,7 @@
 #define XEN_DOMCTL_set_virq_handler              66
 #define XEN_DOMCTL_vmce_monitor_start            67
 #define XEN_DOMCTL_vmce_monitor_end              68
+#define XEN_DOMCTL_set_broken_page_p2m           69
 #define XEN_DOMCTL_gdbsx_guestmemio            1000
 #define XEN_DOMCTL_gdbsx_pausevcpu             1001
 #define XEN_DOMCTL_gdbsx_unpausevcpu           1002
@@ -957,6 +965,7 @@
         struct xen_domctl_set_virq_handler  set_virq_handler;
         struct xen_domctl_vmce_monitor      vmce_monitor;
         struct xen_domctl_gdbsx_memio       gdbsx_guest_memio;
+        struct xen_domctl_set_broken_page_p2m set_broken_page_p2m;
         struct xen_domctl_gdbsx_pauseunp_vcpu gdbsx_pauseunp_vcpu;
         struct xen_domctl_gdbsx_domstatus   gdbsx_domstatus;
         uint8_t                             pad[128];=

--_002_DE8DF0795D48FD4CA783C40EC829233532F451SHSMSX101ccrcorpi_
Content-Type: application/octet-stream;
	name="5_vmce_migration_pfntype_broken.patch"
Content-Description: 5_vmce_migration_pfntype_broken.patch
Content-Disposition: attachment;
	filename="5_vmce_migration_pfntype_broken.patch"; size=8499;
	creation-date="Tue, 18 Sep 2012 13:04:35 GMT";
	modification-date="Tue, 18 Sep 2012 20:55:04 GMT"
Content-Transfer-Encoding: base64

WDg2L3ZNQ0U6IGd1ZXN0IGJyb2tlbiBwYWdlIGhhbmRsaW5nIHdoZW4gbWlncmF0aW9uCgpUaGlz
IHBhdGNoIGlzIHVzZWQgdG8gaGFuZGxlIGd1ZXN0IGJyb2tlbiBwYWdlIHdoZW4gbWlncmF0aW9u
LgoKQXQgc2VuZGVyLCB0aGUgYnJva2VuIHBhZ2Ugd291bGQgbm90IGJlIG1hcHBlZCwgYW5kIHRo
ZSBlcnJvciBwYWdlCmNvbnRlbnQgd291bGQgbm90IGJlIGNvcGllZCB0byB0YXJnZXQsIG90aGVy
d2lzZSBpdCBtYXkgdHJpZ2dlciBtb3JlCnNlcmlvdXMgZXJyb3IgKGkuZS4gU1JBUiBlcnJvciku
IFdoaWxlIGl0cyBwZm5fdHlwZSBhbmQgcGZuIG51bWJlcgp3b3VsZCBiZSB0cmFuc2ZlcnJlZCB0
byB0YXJnZXQgc28gdGhhdCB0YXJnZXQgdGFrZSBhcHByb3ByaWF0ZSBhY3Rpb24uCgpBdCB0YXJn
ZXQsIGl0IHdvdWxkIHNldCBwMm0gYXMgcDJtX3JhbV9icm9rZW4gZm9yIGJyb2tlbiBwYWdlLCBz
byB0aGF0CmlmIGd1ZXN0IGFjY2VzcyB0aGUgYnJva2VuIHBhZ2UgYWdhaW4sIGl0IHdvdWxkIGtp
bGwgZ3Vlc3QgYXMgZXhwZWN0ZWQuCgpTaWduZWQtb2ZmLWJ5OiBMaXUsIEppbnNvbmcgPGppbnNv
bmcubGl1QGludGVsLmNvbT4KCmRpZmYgLXIgYTFkMTA2ZDFhZWM4IHRvb2xzL2xpYnhjL3hjX2Rv
bWFpbi5jCi0tLSBhL3Rvb2xzL2xpYnhjL3hjX2RvbWFpbi5jCVdlZCBTZXAgMTkgMDM6MzE6MzEg
MjAxMiArMDgwMAorKysgYi90b29scy9saWJ4Yy94Y19kb21haW4uYwlXZWQgU2VwIDE5IDA0OjIy
OjI2IDIwMTIgKzA4MDAKQEAgLTMxNCw2ICszMTQsMjIgQEAKICAgICByZXR1cm4gcmV0ID8gLTEg
OiAwOwogfQogCisvKiBzZXQgYnJva2VuIHBhZ2UgcDJtICovCitpbnQgeGNfc2V0X2Jyb2tlbl9w
YWdlX3AybSh4Y19pbnRlcmZhY2UgKnhjaCwKKyAgICAgICAgICAgICAgICAgICAgICAgICAgIHVp
bnQzMl90IGRvbWlkLAorICAgICAgICAgICAgICAgICAgICAgICAgICAgdW5zaWduZWQgbG9uZyBw
Zm4pCit7CisgICAgaW50IHJldDsKKyAgICBERUNMQVJFX0RPTUNUTDsKKworICAgIGRvbWN0bC5j
bWQgPSBYRU5fRE9NQ1RMX3NldF9icm9rZW5fcGFnZV9wMm07CisgICAgZG9tY3RsLmRvbWFpbiA9
IChkb21pZF90KWRvbWlkOworICAgIGRvbWN0bC51LnNldF9icm9rZW5fcGFnZV9wMm0ucGZuID0g
cGZuOworICAgIHJldCA9IGRvX2RvbWN0bCh4Y2gsICZkb21jdGwpOworCisgICAgcmV0dXJuIHJl
dCA/IC0xIDogMDsKK30KKwogLyogZ2V0IGluZm8gZnJvbSBodm0gZ3Vlc3QgZm9yIHNhdmUgKi8K
IGludCB4Y19kb21haW5faHZtX2dldGNvbnRleHQoeGNfaW50ZXJmYWNlICp4Y2gsCiAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgIHVpbnQzMl90IGRvbWlkLApkaWZmIC1yIGExZDEwNmQxYWVj
OCB0b29scy9saWJ4Yy94Y19kb21haW5fcmVzdG9yZS5jCi0tLSBhL3Rvb2xzL2xpYnhjL3hjX2Rv
bWFpbl9yZXN0b3JlLmMJV2VkIFNlcCAxOSAwMzozMTozMSAyMDEyICswODAwCisrKyBiL3Rvb2xz
L2xpYnhjL3hjX2RvbWFpbl9yZXN0b3JlLmMJV2VkIFNlcCAxOSAwNDoyMjoyNiAyMDEyICswODAw
CkBAIC05NjIsOSArOTYyLDE1IEBACiAKICAgICBjb3VudHBhZ2VzID0gY291bnQ7CiAgICAgZm9y
IChpID0gb2xkY291bnQ7IGkgPCBidWYtPm5yX3BhZ2VzOyArK2kpCi0gICAgICAgIGlmICgoYnVm
LT5wZm5fdHlwZXNbaV0gJiBYRU5fRE9NQ1RMX1BGSU5GT19MVEFCX01BU0spID09IFhFTl9ET01D
VExfUEZJTkZPX1hUQUIKLSAgICAgICAgICAgIHx8KGJ1Zi0+cGZuX3R5cGVzW2ldICYgWEVOX0RP
TUNUTF9QRklORk9fTFRBQl9NQVNLKSA9PSBYRU5fRE9NQ1RMX1BGSU5GT19YQUxMT0MpCisgICAg
eworICAgICAgICB1bnNpZ25lZCBsb25nIHBhZ2V0eXBlOworCisgICAgICAgIHBhZ2V0eXBlID0g
YnVmLT5wZm5fdHlwZXNbaV0gJiBYRU5fRE9NQ1RMX1BGSU5GT19MVEFCX01BU0s7CisgICAgICAg
IGlmICggcGFnZXR5cGUgPT0gWEVOX0RPTUNUTF9QRklORk9fWFRBQiB8fAorICAgICAgICAgICAg
IHBhZ2V0eXBlID09IFhFTl9ET01DVExfUEZJTkZPX0JST0tFTiB8fAorICAgICAgICAgICAgIHBh
Z2V0eXBlID09IFhFTl9ET01DVExfUEZJTkZPX1hBTExPQyApCiAgICAgICAgICAgICAtLWNvdW50
cGFnZXM7CisgICAgfQogCiAgICAgaWYgKCFjb3VudHBhZ2VzKQogICAgICAgICByZXR1cm4gY291
bnQ7CkBAIC0xMjAwLDYgKzEyMDYsMTcgQEAKICAgICAgICAgICAgIC8qIGEgYm9ndXMvdW5tYXBw
ZWQvYWxsb2NhdGUtb25seSBwYWdlOiBza2lwIGl0ICovCiAgICAgICAgICAgICBjb250aW51ZTsK
IAorICAgICAgICBpZiAoIHBhZ2V0eXBlID09IFhFTl9ET01DVExfUEZJTkZPX0JST0tFTiApCisg
ICAgICAgIHsKKyAgICAgICAgICAgIGlmICggeGNfc2V0X2Jyb2tlbl9wYWdlX3AybSh4Y2gsIGRv
bSwgcGZuKSApCisgICAgICAgICAgICB7CisgICAgICAgICAgICAgICAgRVJST1IoIlNldCBwMm0g
Zm9yIGJyb2tlbiBwYWdlIGZhaWwsICIKKyAgICAgICAgICAgICAgICAgICAgICAiZG9tPSVkLCBw
Zm49JWx4XG4iLCBkb20sIHBmbik7CisgICAgICAgICAgICAgICAgZ290byBlcnJfbWFwcGVkOwor
ICAgICAgICAgICAgfQorICAgICAgICAgICAgY29udGludWU7CisgICAgICAgIH0KKwogICAgICAg
ICBpZiAocGZuX2VycltpXSkKICAgICAgICAgewogICAgICAgICAgICAgRVJST1IoInVuZXhwZWN0
ZWQgUEZOIG1hcHBpbmcgZmFpbHVyZSBwZm4gJWx4IG1hcF9tZm4gJWx4IHAybV9tZm4gJWx4IiwK
ZGlmZiAtciBhMWQxMDZkMWFlYzggdG9vbHMvbGlieGMveGNfZG9tYWluX3NhdmUuYwotLS0gYS90
b29scy9saWJ4Yy94Y19kb21haW5fc2F2ZS5jCVdlZCBTZXAgMTkgMDM6MzE6MzEgMjAxMiArMDgw
MAorKysgYi90b29scy9saWJ4Yy94Y19kb21haW5fc2F2ZS5jCVdlZCBTZXAgMTkgMDQ6MjI6MjYg
MjAxMiArMDgwMApAQCAtMTI4NSw2ICsxMjg1LDEzIEBACiAgICAgICAgICAgICAgICAgaWYgKCAh
aHZtICkKICAgICAgICAgICAgICAgICAgICAgZ21mbiA9IHBmbl90b19tZm4oZ21mbik7CiAKKyAg
ICAgICAgICAgICAgICBpZiAoIHBmbl90eXBlW2pdID09IFhFTl9ET01DVExfUEZJTkZPX0JST0tF
TiApCisgICAgICAgICAgICAgICAgeworICAgICAgICAgICAgICAgICAgICBwZm5fdHlwZVtqXSB8
PSBwZm5fYmF0Y2hbal07CisgICAgICAgICAgICAgICAgICAgICsrcnVuOworICAgICAgICAgICAg
ICAgICAgICBjb250aW51ZTsKKyAgICAgICAgICAgICAgICB9CisKICAgICAgICAgICAgICAgICBp
ZiAoIHBmbl9lcnJbal0gKQogICAgICAgICAgICAgICAgIHsKICAgICAgICAgICAgICAgICAgICAg
aWYgKCBwZm5fdHlwZVtqXSA9PSBYRU5fRE9NQ1RMX1BGSU5GT19YVEFCICkKQEAgLTEzNzksOCAr
MTM4NiwxMiBAQAogICAgICAgICAgICAgICAgICAgICB9CiAgICAgICAgICAgICAgICAgfQogCi0g
ICAgICAgICAgICAgICAgLyogc2tpcCBwYWdlcyB0aGF0IGFyZW4ndCBwcmVzZW50IG9yIGFyZSBh
bGxvYy1vbmx5ICovCisgICAgICAgICAgICAgICAgLyoKKyAgICAgICAgICAgICAgICAgKiBza2lw
IHBhZ2VzIHRoYXQgYXJlbid0IHByZXNlbnQsCisgICAgICAgICAgICAgICAgICogb3IgYXJlIGJy
b2tlbiwgb3IgYXJlIGFsbG9jLW9ubHkKKyAgICAgICAgICAgICAgICAgKi8KICAgICAgICAgICAg
ICAgICBpZiAoIHBhZ2V0eXBlID09IFhFTl9ET01DVExfUEZJTkZPX1hUQUIKKyAgICAgICAgICAg
ICAgICAgICAgfHwgcGFnZXR5cGUgPT0gWEVOX0RPTUNUTF9QRklORk9fQlJPS0VOCiAgICAgICAg
ICAgICAgICAgICAgIHx8IHBhZ2V0eXBlID09IFhFTl9ET01DVExfUEZJTkZPX1hBTExPQyApCiAg
ICAgICAgICAgICAgICAgICAgIGNvbnRpbnVlOwogCmRpZmYgLXIgYTFkMTA2ZDFhZWM4IHRvb2xz
L2xpYnhjL3hlbmN0cmwuaAotLS0gYS90b29scy9saWJ4Yy94ZW5jdHJsLmgJV2VkIFNlcCAxOSAw
MzozMTozMSAyMDEyICswODAwCisrKyBiL3Rvb2xzL2xpYnhjL3hlbmN0cmwuaAlXZWQgU2VwIDE5
IDA0OjIyOjI2IDIwMTIgKzA4MDAKQEAgLTU5MSw2ICs1OTEsMTcgQEAKICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICBzaWduZWQgY2hhciAqdm1jZV93aGlsZV9tb25pdG9yKTsKIAogLyoq
CisgKiBUaGlzIGZ1bmN0aW9uIHNldCBwMm0gZm9yIGJyb2tlbiBwYWdlCisgKiAmcGFybSB4Y2gg
YSBoYW5kbGUgdG8gYW4gb3BlbiBoeXBlcnZpc29yIGludGVyZmFjZQorICogQHBhcm0gZG9taWQg
dGhlIGRvbWFpbiBpZCB3aGljaCBicm9rZW4gcGFnZSBiZWxvbmcgdG8KKyAqIEBwYXJtIHBmbiB0
aGUgcGZuIG51bWJlciBvZiB0aGUgYnJva2VuIHBhZ2UKKyAqIEByZXR1cm4gMCBvbiBzdWNjZXNz
LCAtMSBvbiBmYWlsdXJlCisgKi8KK2ludCB4Y19zZXRfYnJva2VuX3BhZ2VfcDJtKHhjX2ludGVy
ZmFjZSAqeGNoLAorICAgICAgICAgICAgICAgICAgICAgICAgICAgdWludDMyX3QgZG9taWQsCisg
ICAgICAgICAgICAgICAgICAgICAgICAgICB1bnNpZ25lZCBsb25nIHBmbik7CisKKy8qKgogICog
VGhpcyBmdW5jdGlvbiByZXR1cm5zIGluZm9ybWF0aW9uIGFib3V0IHRoZSBjb250ZXh0IG9mIGEg
aHZtIGRvbWFpbgogICogQHBhcm0geGNoIGEgaGFuZGxlIHRvIGFuIG9wZW4gaHlwZXJ2aXNvciBp
bnRlcmZhY2UKICAqIEBwYXJtIGRvbWlkIHRoZSBkb21haW4gdG8gZ2V0IGluZm9ybWF0aW9uIGZy
b20KZGlmZiAtciBhMWQxMDZkMWFlYzggeGVuL2FyY2gveDg2L2RvbWN0bC5jCi0tLSBhL3hlbi9h
cmNoL3g4Ni9kb21jdGwuYwlXZWQgU2VwIDE5IDAzOjMxOjMxIDIwMTIgKzA4MDAKKysrIGIveGVu
L2FyY2gveDg2L2RvbWN0bC5jCVdlZCBTZXAgMTkgMDQ6MjI6MjYgMjAxMiArMDgwMApAQCAtMjA5
LDEyICsyMDksMTggQEAKICAgICAgICAgICAgICAgICBmb3IgKCBqID0gMDsgaiA8IGs7IGorKyAp
CiAgICAgICAgICAgICAgICAgewogICAgICAgICAgICAgICAgICAgICB1bnNpZ25lZCBsb25nIHR5
cGUgPSAwOworICAgICAgICAgICAgICAgICAgICBwMm1fdHlwZV90IHQ7CiAKLSAgICAgICAgICAg
ICAgICAgICAgcGFnZSA9IGdldF9wYWdlX2Zyb21fZ2ZuKGQsIGFycltqXSwgTlVMTCwgUDJNX0FM
TE9DKTsKKyAgICAgICAgICAgICAgICAgICAgcGFnZSA9IGdldF9wYWdlX2Zyb21fZ2ZuKGQsIGFy
cltqXSwgJnQsIFAyTV9BTExPQyk7CiAKICAgICAgICAgICAgICAgICAgICAgaWYgKCB1bmxpa2Vs
eSghcGFnZSkgfHwKICAgICAgICAgICAgICAgICAgICAgICAgICB1bmxpa2VseShpc194ZW5faGVh
cF9wYWdlKHBhZ2UpKSApCi0gICAgICAgICAgICAgICAgICAgICAgICB0eXBlID0gWEVOX0RPTUNU
TF9QRklORk9fWFRBQjsKKyAgICAgICAgICAgICAgICAgICAgeworICAgICAgICAgICAgICAgICAg
ICAgICAgaWYgKCBwMm1faXNfYnJva2VuKHQpICkKKyAgICAgICAgICAgICAgICAgICAgICAgICAg
ICB0eXBlID0gWEVOX0RPTUNUTF9QRklORk9fQlJPS0VOOworICAgICAgICAgICAgICAgICAgICAg
ICAgZWxzZQorICAgICAgICAgICAgICAgICAgICAgICAgICAgIHR5cGUgPSBYRU5fRE9NQ1RMX1BG
SU5GT19YVEFCOworICAgICAgICAgICAgICAgICAgICB9CiAgICAgICAgICAgICAgICAgICAgIGVs
c2UKICAgICAgICAgICAgICAgICAgICAgewogICAgICAgICAgICAgICAgICAgICAgICAgc3dpdGNo
KCBwYWdlLT51LmludXNlLnR5cGVfaW5mbyAmIFBHVF90eXBlX21hc2sgKQpAQCAtMjM1LDYgKzI0
MSw5IEBACiAKICAgICAgICAgICAgICAgICAgICAgICAgIGlmICggcGFnZS0+dS5pbnVzZS50eXBl
X2luZm8gJiBQR1RfcGlubmVkICkKICAgICAgICAgICAgICAgICAgICAgICAgICAgICB0eXBlIHw9
IFhFTl9ET01DVExfUEZJTkZPX0xQSU5UQUI7CisKKyAgICAgICAgICAgICAgICAgICAgICAgIGlm
ICggcGFnZS0+Y291bnRfaW5mbyAmIFBHQ19icm9rZW4gKQorICAgICAgICAgICAgICAgICAgICAg
ICAgICAgIHR5cGUgPSBYRU5fRE9NQ1RMX1BGSU5GT19CUk9LRU47CiAgICAgICAgICAgICAgICAg
ICAgIH0KIAogICAgICAgICAgICAgICAgICAgICBpZiAoIHBhZ2UgKQpAQCAtMTU0OCw2ICsxNTU3
LDI4IEBACiAgICAgfQogICAgIGJyZWFrOwogCisgICAgY2FzZSBYRU5fRE9NQ1RMX3NldF9icm9r
ZW5fcGFnZV9wMm06CisgICAgeworICAgICAgICBzdHJ1Y3QgZG9tYWluICpkOworICAgICAgICBw
Mm1fdHlwZV90IHB0OworICAgICAgICB1bnNpZ25lZCBsb25nIHBmbjsKKworICAgICAgICBkID0g
cmN1X2xvY2tfZG9tYWluX2J5X2lkKGRvbWN0bC0+ZG9tYWluKTsKKyAgICAgICAgaWYgKCBkICE9
IE5VTEwgKQorICAgICAgICB7CisgICAgICAgICAgICBwZm4gPSBkb21jdGwtPnUuc2V0X2Jyb2tl
bl9wYWdlX3AybS5wZm47CisKKyAgICAgICAgICAgIGdldF9nZm5fcXVlcnkoZCwgcGZuLCAmcHQp
OworICAgICAgICAgICAgcDJtX2NoYW5nZV90eXBlKGQsIHBmbiwgcHQsIHAybV9yYW1fYnJva2Vu
KTsKKyAgICAgICAgICAgIHB1dF9nZm4oZCwgcGZuKTsKKworICAgICAgICAgICAgcmN1X3VubG9j
a19kb21haW4oZCk7CisgICAgICAgIH0KKyAgICAgICAgZWxzZQorICAgICAgICAgICAgcmV0ID0g
LUVTUkNIOworICAgIH0KKyAgICBicmVhazsKKwogICAgIGRlZmF1bHQ6CiAgICAgICAgIHJldCA9
IGlvbW11X2RvX2RvbWN0bChkb21jdGwsIHVfZG9tY3RsKTsKICAgICAgICAgYnJlYWs7CmRpZmYg
LXIgYTFkMTA2ZDFhZWM4IHhlbi9pbmNsdWRlL3B1YmxpYy9kb21jdGwuaAotLS0gYS94ZW4vaW5j
bHVkZS9wdWJsaWMvZG9tY3RsLmgJV2VkIFNlcCAxOSAwMzozMTozMSAyMDEyICswODAwCisrKyBi
L3hlbi9pbmNsdWRlL3B1YmxpYy9kb21jdGwuaAlXZWQgU2VwIDE5IDA0OjIyOjI2IDIwMTIgKzA4
MDAKQEAgLTEzNiw2ICsxMzYsNyBAQAogI2RlZmluZSBYRU5fRE9NQ1RMX1BGSU5GT19MUElOVEFC
ICgweDFVPDwzMSkKICNkZWZpbmUgWEVOX0RPTUNUTF9QRklORk9fWFRBQiAgICAoMHhmVTw8Mjgp
IC8qIGludmFsaWQgcGFnZSAqLwogI2RlZmluZSBYRU5fRE9NQ1RMX1BGSU5GT19YQUxMT0MgICgw
eGVVPDwyOCkgLyogYWxsb2NhdGUtb25seSBwYWdlICovCisjZGVmaW5lIFhFTl9ET01DVExfUEZJ
TkZPX0JST0tFTiAgKDB4ZFU8PDI4KSAvKiBicm9rZW4gcGFnZSAqLwogI2RlZmluZSBYRU5fRE9N
Q1RMX1BGSU5GT19QQUdFRFRBQiAoMHg4VTw8MjgpCiAjZGVmaW5lIFhFTl9ET01DVExfUEZJTkZP
X0xUQUJfTUFTSyAoMHhmVTw8MjgpCiAKQEAgLTgzNCw2ICs4MzUsMTIgQEAKIHR5cGVkZWYgc3Ry
dWN0IHhlbl9kb21jdGxfdm1jZV9tb25pdG9yIHhlbl9kb21jdGxfdm1jZV9tb25pdG9yX3Q7CiBE
RUZJTkVfWEVOX0dVRVNUX0hBTkRMRSh4ZW5fZG9tY3RsX3ZtY2VfbW9uaXRvcl90KTsKIAorc3Ry
dWN0IHhlbl9kb21jdGxfc2V0X2Jyb2tlbl9wYWdlX3AybSB7CisgICAgdWludDY0X3QgcGZuOwor
fTsKK3R5cGVkZWYgc3RydWN0IHhlbl9kb21jdGxfc2V0X2Jyb2tlbl9wYWdlX3AybSB4ZW5fZG9t
Y3RsX3NldF9icm9rZW5fcGFnZV9wMm1fdDsKK0RFRklORV9YRU5fR1VFU1RfSEFORExFKHhlbl9k
b21jdGxfc2V0X2Jyb2tlbl9wYWdlX3AybV90KTsKKwogc3RydWN0IHhlbl9kb21jdGwgewogICAg
IHVpbnQzMl90IGNtZDsKICNkZWZpbmUgWEVOX0RPTUNUTF9jcmVhdGVkb21haW4gICAgICAgICAg
ICAgICAgICAgMQpAQCAtOTAxLDYgKzkwOCw3IEBACiAjZGVmaW5lIFhFTl9ET01DVExfc2V0X3Zp
cnFfaGFuZGxlciAgICAgICAgICAgICAgNjYKICNkZWZpbmUgWEVOX0RPTUNUTF92bWNlX21vbml0
b3Jfc3RhcnQgICAgICAgICAgICA2NwogI2RlZmluZSBYRU5fRE9NQ1RMX3ZtY2VfbW9uaXRvcl9l
bmQgICAgICAgICAgICAgIDY4CisjZGVmaW5lIFhFTl9ET01DVExfc2V0X2Jyb2tlbl9wYWdlX3Ay
bSAgICAgICAgICAgNjkKICNkZWZpbmUgWEVOX0RPTUNUTF9nZGJzeF9ndWVzdG1lbWlvICAgICAg
ICAgICAgMTAwMAogI2RlZmluZSBYRU5fRE9NQ1RMX2dkYnN4X3BhdXNldmNwdSAgICAgICAgICAg
ICAxMDAxCiAjZGVmaW5lIFhFTl9ET01DVExfZ2Ric3hfdW5wYXVzZXZjcHUgICAgICAgICAgIDEw
MDIKQEAgLTk1Nyw2ICs5NjUsNyBAQAogICAgICAgICBzdHJ1Y3QgeGVuX2RvbWN0bF9zZXRfdmly
cV9oYW5kbGVyICBzZXRfdmlycV9oYW5kbGVyOwogICAgICAgICBzdHJ1Y3QgeGVuX2RvbWN0bF92
bWNlX21vbml0b3IgICAgICB2bWNlX21vbml0b3I7CiAgICAgICAgIHN0cnVjdCB4ZW5fZG9tY3Rs
X2dkYnN4X21lbWlvICAgICAgIGdkYnN4X2d1ZXN0X21lbWlvOworICAgICAgICBzdHJ1Y3QgeGVu
X2RvbWN0bF9zZXRfYnJva2VuX3BhZ2VfcDJtIHNldF9icm9rZW5fcGFnZV9wMm07CiAgICAgICAg
IHN0cnVjdCB4ZW5fZG9tY3RsX2dkYnN4X3BhdXNldW5wX3ZjcHUgZ2Ric3hfcGF1c2V1bnBfdmNw
dTsKICAgICAgICAgc3RydWN0IHhlbl9kb21jdGxfZ2Ric3hfZG9tc3RhdHVzICAgZ2Ric3hfZG9t
c3RhdHVzOwogICAgICAgICB1aW50OF90ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBwYWRb
MTI4XTsK

--_002_DE8DF0795D48FD4CA783C40EC829233532F451SHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 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_DE8DF0795D48FD4CA783C40EC829233532F451SHSMSX101ccrcorpi_--


From xen-devel-bounces@lists.xen.org Tue Sep 18 13:18:34 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Sep 2012 13:18:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDxh0-0005xl-Vk; Tue, 18 Sep 2012 13:18:22 +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 1TDxgz-0005xU-8U
	for xen-devel@lists.xensource.com; Tue, 18 Sep 2012 13:18:21 +0000
Received: from [85.158.143.99:39977] by server-1.bemta-4.messagelabs.com id
	1E/FD-12504-C9478505; Tue, 18 Sep 2012 13:18:20 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1347974298!21047481!1
X-Originating-IP: [134.134.136.20]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjAgPT4gMjk5NTk2\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16439 invoked from network); 18 Sep 2012 13:18:18 -0000
Received: from mga02.intel.com (HELO mga02.intel.com) (134.134.136.20)
	by server-8.tower-216.messagelabs.com with SMTP;
	18 Sep 2012 13:18:18 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga101.jf.intel.com with ESMTP; 18 Sep 2012 06:18:17 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.80,442,1344236400"; d="scan'208";a="206969750"
Received: from fmsmsx106.amr.corp.intel.com ([10.19.9.37])
	by orsmga002.jf.intel.com with ESMTP; 18 Sep 2012 06:18:17 -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; Tue, 18 Sep 2012 06:18:16 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.239]) by
	SHSMSX102.ccr.corp.intel.com ([169.254.2.92]) with mapi id
	14.01.0355.002; Tue, 18 Sep 2012 21:18:14 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: Jan Beulich <JBeulich@suse.com>, "xen-devel@lists.xensource.com"
	<xen-devel@lists.xensource.com>
Thread-Topic: [PATCH 5/5] X86/vMCE: guest broken page handling when migration
Thread-Index: Ac2VoA7ttrocVu+MQEqEans0Ia15+Q==
Date: Tue, 18 Sep 2012 13:18:14 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC829233532F451@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_DE8DF0795D48FD4CA783C40EC829233532F451SHSMSX101ccrcorpi_"
MIME-Version: 1.0
Cc: "keir@xen.org" <keir@xen.org>,
	"Ian.Campbell@citrix.com" <Ian.Campbell@citrix.com>
Subject: [Xen-devel] [PATCH 5/5] X86/vMCE: guest broken page handling when
	migration
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--_002_DE8DF0795D48FD4CA783C40EC829233532F451SHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

X86/vMCE: guest broken page handling when migration

This patch is used to handle guest broken page when migration.

At sender, the broken page would not be mapped, and the error page
content would not be copied to target, otherwise it may trigger more
serious error (i.e. SRAR error). While its pfn_type and pfn number
would be transferred to target so that target take appropriate action.

At target, it would set p2m as p2m_ram_broken for broken page, so that
if guest access the broken page again, it would kill guest as expected.

Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>

diff -r a1d106d1aec8 tools/libxc/xc_domain.c
--- a/tools/libxc/xc_domain.c	Wed Sep 19 03:31:31 2012 +0800
+++ b/tools/libxc/xc_domain.c	Wed Sep 19 04:22:26 2012 +0800
@@ -314,6 +314,22 @@
     return ret ? -1 : 0;
 }
=20
+/* set broken page p2m */
+int xc_set_broken_page_p2m(xc_interface *xch,
+                           uint32_t domid,
+                           unsigned long pfn)
+{
+    int ret;
+    DECLARE_DOMCTL;
+
+    domctl.cmd =3D XEN_DOMCTL_set_broken_page_p2m;
+    domctl.domain =3D (domid_t)domid;
+    domctl.u.set_broken_page_p2m.pfn =3D pfn;
+    ret =3D do_domctl(xch, &domctl);
+
+    return ret ? -1 : 0;
+}
+
 /* get info from hvm guest for save */
 int xc_domain_hvm_getcontext(xc_interface *xch,
                              uint32_t domid,
diff -r a1d106d1aec8 tools/libxc/xc_domain_restore.c
--- a/tools/libxc/xc_domain_restore.c	Wed Sep 19 03:31:31 2012 +0800
+++ b/tools/libxc/xc_domain_restore.c	Wed Sep 19 04:22:26 2012 +0800
@@ -962,9 +962,15 @@
=20
     countpages =3D count;
     for (i =3D oldcount; i < buf->nr_pages; ++i)
-        if ((buf->pfn_types[i] & XEN_DOMCTL_PFINFO_LTAB_MASK) =3D=3D XEN_D=
OMCTL_PFINFO_XTAB
-            ||(buf->pfn_types[i] & XEN_DOMCTL_PFINFO_LTAB_MASK) =3D=3D XEN=
_DOMCTL_PFINFO_XALLOC)
+    {
+        unsigned long pagetype;
+
+        pagetype =3D buf->pfn_types[i] & XEN_DOMCTL_PFINFO_LTAB_MASK;
+        if ( pagetype =3D=3D XEN_DOMCTL_PFINFO_XTAB ||
+             pagetype =3D=3D XEN_DOMCTL_PFINFO_BROKEN ||
+             pagetype =3D=3D XEN_DOMCTL_PFINFO_XALLOC )
             --countpages;
+    }
=20
     if (!countpages)
         return count;
@@ -1200,6 +1206,17 @@
             /* a bogus/unmapped/allocate-only page: skip it */
             continue;
=20
+        if ( pagetype =3D=3D XEN_DOMCTL_PFINFO_BROKEN )
+        {
+            if ( xc_set_broken_page_p2m(xch, dom, pfn) )
+            {
+                ERROR("Set p2m for broken page fail, "
+                      "dom=3D%d, pfn=3D%lx\n", dom, pfn);
+                goto err_mapped;
+            }
+            continue;
+        }
+
         if (pfn_err[i])
         {
             ERROR("unexpected PFN mapping failure pfn %lx map_mfn %lx p2m_=
mfn %lx",
diff -r a1d106d1aec8 tools/libxc/xc_domain_save.c
--- a/tools/libxc/xc_domain_save.c	Wed Sep 19 03:31:31 2012 +0800
+++ b/tools/libxc/xc_domain_save.c	Wed Sep 19 04:22:26 2012 +0800
@@ -1285,6 +1285,13 @@
                 if ( !hvm )
                     gmfn =3D pfn_to_mfn(gmfn);
=20
+                if ( pfn_type[j] =3D=3D XEN_DOMCTL_PFINFO_BROKEN )
+                {
+                    pfn_type[j] |=3D pfn_batch[j];
+                    ++run;
+                    continue;
+                }
+
                 if ( pfn_err[j] )
                 {
                     if ( pfn_type[j] =3D=3D XEN_DOMCTL_PFINFO_XTAB )
@@ -1379,8 +1386,12 @@
                     }
                 }
=20
-                /* skip pages that aren't present or are alloc-only */
+                /*
+                 * skip pages that aren't present,
+                 * or are broken, or are alloc-only
+                 */
                 if ( pagetype =3D=3D XEN_DOMCTL_PFINFO_XTAB
+                    || pagetype =3D=3D XEN_DOMCTL_PFINFO_BROKEN
                     || pagetype =3D=3D XEN_DOMCTL_PFINFO_XALLOC )
                     continue;
=20
diff -r a1d106d1aec8 tools/libxc/xenctrl.h
--- a/tools/libxc/xenctrl.h	Wed Sep 19 03:31:31 2012 +0800
+++ b/tools/libxc/xenctrl.h	Wed Sep 19 04:22:26 2012 +0800
@@ -591,6 +591,17 @@
                                signed char *vmce_while_monitor);
=20
 /**
+ * This function set p2m for broken page
+ * &parm xch a handle to an open hypervisor interface
+ * @parm domid the domain id which broken page belong to
+ * @parm pfn the pfn number of the broken page
+ * @return 0 on success, -1 on failure
+ */
+int xc_set_broken_page_p2m(xc_interface *xch,
+                           uint32_t domid,
+                           unsigned long pfn);
+
+/**
  * This function returns information about the context of a hvm domain
  * @parm xch a handle to an open hypervisor interface
  * @parm domid the domain to get information from
diff -r a1d106d1aec8 xen/arch/x86/domctl.c
--- a/xen/arch/x86/domctl.c	Wed Sep 19 03:31:31 2012 +0800
+++ b/xen/arch/x86/domctl.c	Wed Sep 19 04:22:26 2012 +0800
@@ -209,12 +209,18 @@
                 for ( j =3D 0; j < k; j++ )
                 {
                     unsigned long type =3D 0;
+                    p2m_type_t t;
=20
-                    page =3D get_page_from_gfn(d, arr[j], NULL, P2M_ALLOC)=
;
+                    page =3D get_page_from_gfn(d, arr[j], &t, P2M_ALLOC);
=20
                     if ( unlikely(!page) ||
                          unlikely(is_xen_heap_page(page)) )
-                        type =3D XEN_DOMCTL_PFINFO_XTAB;
+                    {
+                        if ( p2m_is_broken(t) )
+                            type =3D XEN_DOMCTL_PFINFO_BROKEN;
+                        else
+                            type =3D XEN_DOMCTL_PFINFO_XTAB;
+                    }
                     else
                     {
                         switch( page->u.inuse.type_info & PGT_type_mask )
@@ -235,6 +241,9 @@
=20
                         if ( page->u.inuse.type_info & PGT_pinned )
                             type |=3D XEN_DOMCTL_PFINFO_LPINTAB;
+
+                        if ( page->count_info & PGC_broken )
+                            type =3D XEN_DOMCTL_PFINFO_BROKEN;
                     }
=20
                     if ( page )
@@ -1548,6 +1557,28 @@
     }
     break;
=20
+    case XEN_DOMCTL_set_broken_page_p2m:
+    {
+        struct domain *d;
+        p2m_type_t pt;
+        unsigned long pfn;
+
+        d =3D rcu_lock_domain_by_id(domctl->domain);
+        if ( d !=3D NULL )
+        {
+            pfn =3D domctl->u.set_broken_page_p2m.pfn;
+
+            get_gfn_query(d, pfn, &pt);
+            p2m_change_type(d, pfn, pt, p2m_ram_broken);
+            put_gfn(d, pfn);
+
+            rcu_unlock_domain(d);
+        }
+        else
+            ret =3D -ESRCH;
+    }
+    break;
+
     default:
         ret =3D iommu_do_domctl(domctl, u_domctl);
         break;
diff -r a1d106d1aec8 xen/include/public/domctl.h
--- a/xen/include/public/domctl.h	Wed Sep 19 03:31:31 2012 +0800
+++ b/xen/include/public/domctl.h	Wed Sep 19 04:22:26 2012 +0800
@@ -136,6 +136,7 @@
 #define XEN_DOMCTL_PFINFO_LPINTAB (0x1U<<31)
 #define XEN_DOMCTL_PFINFO_XTAB    (0xfU<<28) /* invalid page */
 #define XEN_DOMCTL_PFINFO_XALLOC  (0xeU<<28) /* allocate-only page */
+#define XEN_DOMCTL_PFINFO_BROKEN  (0xdU<<28) /* broken page */
 #define XEN_DOMCTL_PFINFO_PAGEDTAB (0x8U<<28)
 #define XEN_DOMCTL_PFINFO_LTAB_MASK (0xfU<<28)
=20
@@ -834,6 +835,12 @@
 typedef struct xen_domctl_vmce_monitor xen_domctl_vmce_monitor_t;
 DEFINE_XEN_GUEST_HANDLE(xen_domctl_vmce_monitor_t);
=20
+struct xen_domctl_set_broken_page_p2m {
+    uint64_t pfn;
+};
+typedef struct xen_domctl_set_broken_page_p2m xen_domctl_set_broken_page_p=
2m_t;
+DEFINE_XEN_GUEST_HANDLE(xen_domctl_set_broken_page_p2m_t);
+
 struct xen_domctl {
     uint32_t cmd;
 #define XEN_DOMCTL_createdomain                   1
@@ -901,6 +908,7 @@
 #define XEN_DOMCTL_set_virq_handler              66
 #define XEN_DOMCTL_vmce_monitor_start            67
 #define XEN_DOMCTL_vmce_monitor_end              68
+#define XEN_DOMCTL_set_broken_page_p2m           69
 #define XEN_DOMCTL_gdbsx_guestmemio            1000
 #define XEN_DOMCTL_gdbsx_pausevcpu             1001
 #define XEN_DOMCTL_gdbsx_unpausevcpu           1002
@@ -957,6 +965,7 @@
         struct xen_domctl_set_virq_handler  set_virq_handler;
         struct xen_domctl_vmce_monitor      vmce_monitor;
         struct xen_domctl_gdbsx_memio       gdbsx_guest_memio;
+        struct xen_domctl_set_broken_page_p2m set_broken_page_p2m;
         struct xen_domctl_gdbsx_pauseunp_vcpu gdbsx_pauseunp_vcpu;
         struct xen_domctl_gdbsx_domstatus   gdbsx_domstatus;
         uint8_t                             pad[128];=

--_002_DE8DF0795D48FD4CA783C40EC829233532F451SHSMSX101ccrcorpi_
Content-Type: application/octet-stream;
	name="5_vmce_migration_pfntype_broken.patch"
Content-Description: 5_vmce_migration_pfntype_broken.patch
Content-Disposition: attachment;
	filename="5_vmce_migration_pfntype_broken.patch"; size=8499;
	creation-date="Tue, 18 Sep 2012 13:04:35 GMT";
	modification-date="Tue, 18 Sep 2012 20:55:04 GMT"
Content-Transfer-Encoding: base64

WDg2L3ZNQ0U6IGd1ZXN0IGJyb2tlbiBwYWdlIGhhbmRsaW5nIHdoZW4gbWlncmF0aW9uCgpUaGlz
IHBhdGNoIGlzIHVzZWQgdG8gaGFuZGxlIGd1ZXN0IGJyb2tlbiBwYWdlIHdoZW4gbWlncmF0aW9u
LgoKQXQgc2VuZGVyLCB0aGUgYnJva2VuIHBhZ2Ugd291bGQgbm90IGJlIG1hcHBlZCwgYW5kIHRo
ZSBlcnJvciBwYWdlCmNvbnRlbnQgd291bGQgbm90IGJlIGNvcGllZCB0byB0YXJnZXQsIG90aGVy
d2lzZSBpdCBtYXkgdHJpZ2dlciBtb3JlCnNlcmlvdXMgZXJyb3IgKGkuZS4gU1JBUiBlcnJvciku
IFdoaWxlIGl0cyBwZm5fdHlwZSBhbmQgcGZuIG51bWJlcgp3b3VsZCBiZSB0cmFuc2ZlcnJlZCB0
byB0YXJnZXQgc28gdGhhdCB0YXJnZXQgdGFrZSBhcHByb3ByaWF0ZSBhY3Rpb24uCgpBdCB0YXJn
ZXQsIGl0IHdvdWxkIHNldCBwMm0gYXMgcDJtX3JhbV9icm9rZW4gZm9yIGJyb2tlbiBwYWdlLCBz
byB0aGF0CmlmIGd1ZXN0IGFjY2VzcyB0aGUgYnJva2VuIHBhZ2UgYWdhaW4sIGl0IHdvdWxkIGtp
bGwgZ3Vlc3QgYXMgZXhwZWN0ZWQuCgpTaWduZWQtb2ZmLWJ5OiBMaXUsIEppbnNvbmcgPGppbnNv
bmcubGl1QGludGVsLmNvbT4KCmRpZmYgLXIgYTFkMTA2ZDFhZWM4IHRvb2xzL2xpYnhjL3hjX2Rv
bWFpbi5jCi0tLSBhL3Rvb2xzL2xpYnhjL3hjX2RvbWFpbi5jCVdlZCBTZXAgMTkgMDM6MzE6MzEg
MjAxMiArMDgwMAorKysgYi90b29scy9saWJ4Yy94Y19kb21haW4uYwlXZWQgU2VwIDE5IDA0OjIy
OjI2IDIwMTIgKzA4MDAKQEAgLTMxNCw2ICszMTQsMjIgQEAKICAgICByZXR1cm4gcmV0ID8gLTEg
OiAwOwogfQogCisvKiBzZXQgYnJva2VuIHBhZ2UgcDJtICovCitpbnQgeGNfc2V0X2Jyb2tlbl9w
YWdlX3AybSh4Y19pbnRlcmZhY2UgKnhjaCwKKyAgICAgICAgICAgICAgICAgICAgICAgICAgIHVp
bnQzMl90IGRvbWlkLAorICAgICAgICAgICAgICAgICAgICAgICAgICAgdW5zaWduZWQgbG9uZyBw
Zm4pCit7CisgICAgaW50IHJldDsKKyAgICBERUNMQVJFX0RPTUNUTDsKKworICAgIGRvbWN0bC5j
bWQgPSBYRU5fRE9NQ1RMX3NldF9icm9rZW5fcGFnZV9wMm07CisgICAgZG9tY3RsLmRvbWFpbiA9
IChkb21pZF90KWRvbWlkOworICAgIGRvbWN0bC51LnNldF9icm9rZW5fcGFnZV9wMm0ucGZuID0g
cGZuOworICAgIHJldCA9IGRvX2RvbWN0bCh4Y2gsICZkb21jdGwpOworCisgICAgcmV0dXJuIHJl
dCA/IC0xIDogMDsKK30KKwogLyogZ2V0IGluZm8gZnJvbSBodm0gZ3Vlc3QgZm9yIHNhdmUgKi8K
IGludCB4Y19kb21haW5faHZtX2dldGNvbnRleHQoeGNfaW50ZXJmYWNlICp4Y2gsCiAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgIHVpbnQzMl90IGRvbWlkLApkaWZmIC1yIGExZDEwNmQxYWVj
OCB0b29scy9saWJ4Yy94Y19kb21haW5fcmVzdG9yZS5jCi0tLSBhL3Rvb2xzL2xpYnhjL3hjX2Rv
bWFpbl9yZXN0b3JlLmMJV2VkIFNlcCAxOSAwMzozMTozMSAyMDEyICswODAwCisrKyBiL3Rvb2xz
L2xpYnhjL3hjX2RvbWFpbl9yZXN0b3JlLmMJV2VkIFNlcCAxOSAwNDoyMjoyNiAyMDEyICswODAw
CkBAIC05NjIsOSArOTYyLDE1IEBACiAKICAgICBjb3VudHBhZ2VzID0gY291bnQ7CiAgICAgZm9y
IChpID0gb2xkY291bnQ7IGkgPCBidWYtPm5yX3BhZ2VzOyArK2kpCi0gICAgICAgIGlmICgoYnVm
LT5wZm5fdHlwZXNbaV0gJiBYRU5fRE9NQ1RMX1BGSU5GT19MVEFCX01BU0spID09IFhFTl9ET01D
VExfUEZJTkZPX1hUQUIKLSAgICAgICAgICAgIHx8KGJ1Zi0+cGZuX3R5cGVzW2ldICYgWEVOX0RP
TUNUTF9QRklORk9fTFRBQl9NQVNLKSA9PSBYRU5fRE9NQ1RMX1BGSU5GT19YQUxMT0MpCisgICAg
eworICAgICAgICB1bnNpZ25lZCBsb25nIHBhZ2V0eXBlOworCisgICAgICAgIHBhZ2V0eXBlID0g
YnVmLT5wZm5fdHlwZXNbaV0gJiBYRU5fRE9NQ1RMX1BGSU5GT19MVEFCX01BU0s7CisgICAgICAg
IGlmICggcGFnZXR5cGUgPT0gWEVOX0RPTUNUTF9QRklORk9fWFRBQiB8fAorICAgICAgICAgICAg
IHBhZ2V0eXBlID09IFhFTl9ET01DVExfUEZJTkZPX0JST0tFTiB8fAorICAgICAgICAgICAgIHBh
Z2V0eXBlID09IFhFTl9ET01DVExfUEZJTkZPX1hBTExPQyApCiAgICAgICAgICAgICAtLWNvdW50
cGFnZXM7CisgICAgfQogCiAgICAgaWYgKCFjb3VudHBhZ2VzKQogICAgICAgICByZXR1cm4gY291
bnQ7CkBAIC0xMjAwLDYgKzEyMDYsMTcgQEAKICAgICAgICAgICAgIC8qIGEgYm9ndXMvdW5tYXBw
ZWQvYWxsb2NhdGUtb25seSBwYWdlOiBza2lwIGl0ICovCiAgICAgICAgICAgICBjb250aW51ZTsK
IAorICAgICAgICBpZiAoIHBhZ2V0eXBlID09IFhFTl9ET01DVExfUEZJTkZPX0JST0tFTiApCisg
ICAgICAgIHsKKyAgICAgICAgICAgIGlmICggeGNfc2V0X2Jyb2tlbl9wYWdlX3AybSh4Y2gsIGRv
bSwgcGZuKSApCisgICAgICAgICAgICB7CisgICAgICAgICAgICAgICAgRVJST1IoIlNldCBwMm0g
Zm9yIGJyb2tlbiBwYWdlIGZhaWwsICIKKyAgICAgICAgICAgICAgICAgICAgICAiZG9tPSVkLCBw
Zm49JWx4XG4iLCBkb20sIHBmbik7CisgICAgICAgICAgICAgICAgZ290byBlcnJfbWFwcGVkOwor
ICAgICAgICAgICAgfQorICAgICAgICAgICAgY29udGludWU7CisgICAgICAgIH0KKwogICAgICAg
ICBpZiAocGZuX2VycltpXSkKICAgICAgICAgewogICAgICAgICAgICAgRVJST1IoInVuZXhwZWN0
ZWQgUEZOIG1hcHBpbmcgZmFpbHVyZSBwZm4gJWx4IG1hcF9tZm4gJWx4IHAybV9tZm4gJWx4IiwK
ZGlmZiAtciBhMWQxMDZkMWFlYzggdG9vbHMvbGlieGMveGNfZG9tYWluX3NhdmUuYwotLS0gYS90
b29scy9saWJ4Yy94Y19kb21haW5fc2F2ZS5jCVdlZCBTZXAgMTkgMDM6MzE6MzEgMjAxMiArMDgw
MAorKysgYi90b29scy9saWJ4Yy94Y19kb21haW5fc2F2ZS5jCVdlZCBTZXAgMTkgMDQ6MjI6MjYg
MjAxMiArMDgwMApAQCAtMTI4NSw2ICsxMjg1LDEzIEBACiAgICAgICAgICAgICAgICAgaWYgKCAh
aHZtICkKICAgICAgICAgICAgICAgICAgICAgZ21mbiA9IHBmbl90b19tZm4oZ21mbik7CiAKKyAg
ICAgICAgICAgICAgICBpZiAoIHBmbl90eXBlW2pdID09IFhFTl9ET01DVExfUEZJTkZPX0JST0tF
TiApCisgICAgICAgICAgICAgICAgeworICAgICAgICAgICAgICAgICAgICBwZm5fdHlwZVtqXSB8
PSBwZm5fYmF0Y2hbal07CisgICAgICAgICAgICAgICAgICAgICsrcnVuOworICAgICAgICAgICAg
ICAgICAgICBjb250aW51ZTsKKyAgICAgICAgICAgICAgICB9CisKICAgICAgICAgICAgICAgICBp
ZiAoIHBmbl9lcnJbal0gKQogICAgICAgICAgICAgICAgIHsKICAgICAgICAgICAgICAgICAgICAg
aWYgKCBwZm5fdHlwZVtqXSA9PSBYRU5fRE9NQ1RMX1BGSU5GT19YVEFCICkKQEAgLTEzNzksOCAr
MTM4NiwxMiBAQAogICAgICAgICAgICAgICAgICAgICB9CiAgICAgICAgICAgICAgICAgfQogCi0g
ICAgICAgICAgICAgICAgLyogc2tpcCBwYWdlcyB0aGF0IGFyZW4ndCBwcmVzZW50IG9yIGFyZSBh
bGxvYy1vbmx5ICovCisgICAgICAgICAgICAgICAgLyoKKyAgICAgICAgICAgICAgICAgKiBza2lw
IHBhZ2VzIHRoYXQgYXJlbid0IHByZXNlbnQsCisgICAgICAgICAgICAgICAgICogb3IgYXJlIGJy
b2tlbiwgb3IgYXJlIGFsbG9jLW9ubHkKKyAgICAgICAgICAgICAgICAgKi8KICAgICAgICAgICAg
ICAgICBpZiAoIHBhZ2V0eXBlID09IFhFTl9ET01DVExfUEZJTkZPX1hUQUIKKyAgICAgICAgICAg
ICAgICAgICAgfHwgcGFnZXR5cGUgPT0gWEVOX0RPTUNUTF9QRklORk9fQlJPS0VOCiAgICAgICAg
ICAgICAgICAgICAgIHx8IHBhZ2V0eXBlID09IFhFTl9ET01DVExfUEZJTkZPX1hBTExPQyApCiAg
ICAgICAgICAgICAgICAgICAgIGNvbnRpbnVlOwogCmRpZmYgLXIgYTFkMTA2ZDFhZWM4IHRvb2xz
L2xpYnhjL3hlbmN0cmwuaAotLS0gYS90b29scy9saWJ4Yy94ZW5jdHJsLmgJV2VkIFNlcCAxOSAw
MzozMTozMSAyMDEyICswODAwCisrKyBiL3Rvb2xzL2xpYnhjL3hlbmN0cmwuaAlXZWQgU2VwIDE5
IDA0OjIyOjI2IDIwMTIgKzA4MDAKQEAgLTU5MSw2ICs1OTEsMTcgQEAKICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICBzaWduZWQgY2hhciAqdm1jZV93aGlsZV9tb25pdG9yKTsKIAogLyoq
CisgKiBUaGlzIGZ1bmN0aW9uIHNldCBwMm0gZm9yIGJyb2tlbiBwYWdlCisgKiAmcGFybSB4Y2gg
YSBoYW5kbGUgdG8gYW4gb3BlbiBoeXBlcnZpc29yIGludGVyZmFjZQorICogQHBhcm0gZG9taWQg
dGhlIGRvbWFpbiBpZCB3aGljaCBicm9rZW4gcGFnZSBiZWxvbmcgdG8KKyAqIEBwYXJtIHBmbiB0
aGUgcGZuIG51bWJlciBvZiB0aGUgYnJva2VuIHBhZ2UKKyAqIEByZXR1cm4gMCBvbiBzdWNjZXNz
LCAtMSBvbiBmYWlsdXJlCisgKi8KK2ludCB4Y19zZXRfYnJva2VuX3BhZ2VfcDJtKHhjX2ludGVy
ZmFjZSAqeGNoLAorICAgICAgICAgICAgICAgICAgICAgICAgICAgdWludDMyX3QgZG9taWQsCisg
ICAgICAgICAgICAgICAgICAgICAgICAgICB1bnNpZ25lZCBsb25nIHBmbik7CisKKy8qKgogICog
VGhpcyBmdW5jdGlvbiByZXR1cm5zIGluZm9ybWF0aW9uIGFib3V0IHRoZSBjb250ZXh0IG9mIGEg
aHZtIGRvbWFpbgogICogQHBhcm0geGNoIGEgaGFuZGxlIHRvIGFuIG9wZW4gaHlwZXJ2aXNvciBp
bnRlcmZhY2UKICAqIEBwYXJtIGRvbWlkIHRoZSBkb21haW4gdG8gZ2V0IGluZm9ybWF0aW9uIGZy
b20KZGlmZiAtciBhMWQxMDZkMWFlYzggeGVuL2FyY2gveDg2L2RvbWN0bC5jCi0tLSBhL3hlbi9h
cmNoL3g4Ni9kb21jdGwuYwlXZWQgU2VwIDE5IDAzOjMxOjMxIDIwMTIgKzA4MDAKKysrIGIveGVu
L2FyY2gveDg2L2RvbWN0bC5jCVdlZCBTZXAgMTkgMDQ6MjI6MjYgMjAxMiArMDgwMApAQCAtMjA5
LDEyICsyMDksMTggQEAKICAgICAgICAgICAgICAgICBmb3IgKCBqID0gMDsgaiA8IGs7IGorKyAp
CiAgICAgICAgICAgICAgICAgewogICAgICAgICAgICAgICAgICAgICB1bnNpZ25lZCBsb25nIHR5
cGUgPSAwOworICAgICAgICAgICAgICAgICAgICBwMm1fdHlwZV90IHQ7CiAKLSAgICAgICAgICAg
ICAgICAgICAgcGFnZSA9IGdldF9wYWdlX2Zyb21fZ2ZuKGQsIGFycltqXSwgTlVMTCwgUDJNX0FM
TE9DKTsKKyAgICAgICAgICAgICAgICAgICAgcGFnZSA9IGdldF9wYWdlX2Zyb21fZ2ZuKGQsIGFy
cltqXSwgJnQsIFAyTV9BTExPQyk7CiAKICAgICAgICAgICAgICAgICAgICAgaWYgKCB1bmxpa2Vs
eSghcGFnZSkgfHwKICAgICAgICAgICAgICAgICAgICAgICAgICB1bmxpa2VseShpc194ZW5faGVh
cF9wYWdlKHBhZ2UpKSApCi0gICAgICAgICAgICAgICAgICAgICAgICB0eXBlID0gWEVOX0RPTUNU
TF9QRklORk9fWFRBQjsKKyAgICAgICAgICAgICAgICAgICAgeworICAgICAgICAgICAgICAgICAg
ICAgICAgaWYgKCBwMm1faXNfYnJva2VuKHQpICkKKyAgICAgICAgICAgICAgICAgICAgICAgICAg
ICB0eXBlID0gWEVOX0RPTUNUTF9QRklORk9fQlJPS0VOOworICAgICAgICAgICAgICAgICAgICAg
ICAgZWxzZQorICAgICAgICAgICAgICAgICAgICAgICAgICAgIHR5cGUgPSBYRU5fRE9NQ1RMX1BG
SU5GT19YVEFCOworICAgICAgICAgICAgICAgICAgICB9CiAgICAgICAgICAgICAgICAgICAgIGVs
c2UKICAgICAgICAgICAgICAgICAgICAgewogICAgICAgICAgICAgICAgICAgICAgICAgc3dpdGNo
KCBwYWdlLT51LmludXNlLnR5cGVfaW5mbyAmIFBHVF90eXBlX21hc2sgKQpAQCAtMjM1LDYgKzI0
MSw5IEBACiAKICAgICAgICAgICAgICAgICAgICAgICAgIGlmICggcGFnZS0+dS5pbnVzZS50eXBl
X2luZm8gJiBQR1RfcGlubmVkICkKICAgICAgICAgICAgICAgICAgICAgICAgICAgICB0eXBlIHw9
IFhFTl9ET01DVExfUEZJTkZPX0xQSU5UQUI7CisKKyAgICAgICAgICAgICAgICAgICAgICAgIGlm
ICggcGFnZS0+Y291bnRfaW5mbyAmIFBHQ19icm9rZW4gKQorICAgICAgICAgICAgICAgICAgICAg
ICAgICAgIHR5cGUgPSBYRU5fRE9NQ1RMX1BGSU5GT19CUk9LRU47CiAgICAgICAgICAgICAgICAg
ICAgIH0KIAogICAgICAgICAgICAgICAgICAgICBpZiAoIHBhZ2UgKQpAQCAtMTU0OCw2ICsxNTU3
LDI4IEBACiAgICAgfQogICAgIGJyZWFrOwogCisgICAgY2FzZSBYRU5fRE9NQ1RMX3NldF9icm9r
ZW5fcGFnZV9wMm06CisgICAgeworICAgICAgICBzdHJ1Y3QgZG9tYWluICpkOworICAgICAgICBw
Mm1fdHlwZV90IHB0OworICAgICAgICB1bnNpZ25lZCBsb25nIHBmbjsKKworICAgICAgICBkID0g
cmN1X2xvY2tfZG9tYWluX2J5X2lkKGRvbWN0bC0+ZG9tYWluKTsKKyAgICAgICAgaWYgKCBkICE9
IE5VTEwgKQorICAgICAgICB7CisgICAgICAgICAgICBwZm4gPSBkb21jdGwtPnUuc2V0X2Jyb2tl
bl9wYWdlX3AybS5wZm47CisKKyAgICAgICAgICAgIGdldF9nZm5fcXVlcnkoZCwgcGZuLCAmcHQp
OworICAgICAgICAgICAgcDJtX2NoYW5nZV90eXBlKGQsIHBmbiwgcHQsIHAybV9yYW1fYnJva2Vu
KTsKKyAgICAgICAgICAgIHB1dF9nZm4oZCwgcGZuKTsKKworICAgICAgICAgICAgcmN1X3VubG9j
a19kb21haW4oZCk7CisgICAgICAgIH0KKyAgICAgICAgZWxzZQorICAgICAgICAgICAgcmV0ID0g
LUVTUkNIOworICAgIH0KKyAgICBicmVhazsKKwogICAgIGRlZmF1bHQ6CiAgICAgICAgIHJldCA9
IGlvbW11X2RvX2RvbWN0bChkb21jdGwsIHVfZG9tY3RsKTsKICAgICAgICAgYnJlYWs7CmRpZmYg
LXIgYTFkMTA2ZDFhZWM4IHhlbi9pbmNsdWRlL3B1YmxpYy9kb21jdGwuaAotLS0gYS94ZW4vaW5j
bHVkZS9wdWJsaWMvZG9tY3RsLmgJV2VkIFNlcCAxOSAwMzozMTozMSAyMDEyICswODAwCisrKyBi
L3hlbi9pbmNsdWRlL3B1YmxpYy9kb21jdGwuaAlXZWQgU2VwIDE5IDA0OjIyOjI2IDIwMTIgKzA4
MDAKQEAgLTEzNiw2ICsxMzYsNyBAQAogI2RlZmluZSBYRU5fRE9NQ1RMX1BGSU5GT19MUElOVEFC
ICgweDFVPDwzMSkKICNkZWZpbmUgWEVOX0RPTUNUTF9QRklORk9fWFRBQiAgICAoMHhmVTw8Mjgp
IC8qIGludmFsaWQgcGFnZSAqLwogI2RlZmluZSBYRU5fRE9NQ1RMX1BGSU5GT19YQUxMT0MgICgw
eGVVPDwyOCkgLyogYWxsb2NhdGUtb25seSBwYWdlICovCisjZGVmaW5lIFhFTl9ET01DVExfUEZJ
TkZPX0JST0tFTiAgKDB4ZFU8PDI4KSAvKiBicm9rZW4gcGFnZSAqLwogI2RlZmluZSBYRU5fRE9N
Q1RMX1BGSU5GT19QQUdFRFRBQiAoMHg4VTw8MjgpCiAjZGVmaW5lIFhFTl9ET01DVExfUEZJTkZP
X0xUQUJfTUFTSyAoMHhmVTw8MjgpCiAKQEAgLTgzNCw2ICs4MzUsMTIgQEAKIHR5cGVkZWYgc3Ry
dWN0IHhlbl9kb21jdGxfdm1jZV9tb25pdG9yIHhlbl9kb21jdGxfdm1jZV9tb25pdG9yX3Q7CiBE
RUZJTkVfWEVOX0dVRVNUX0hBTkRMRSh4ZW5fZG9tY3RsX3ZtY2VfbW9uaXRvcl90KTsKIAorc3Ry
dWN0IHhlbl9kb21jdGxfc2V0X2Jyb2tlbl9wYWdlX3AybSB7CisgICAgdWludDY0X3QgcGZuOwor
fTsKK3R5cGVkZWYgc3RydWN0IHhlbl9kb21jdGxfc2V0X2Jyb2tlbl9wYWdlX3AybSB4ZW5fZG9t
Y3RsX3NldF9icm9rZW5fcGFnZV9wMm1fdDsKK0RFRklORV9YRU5fR1VFU1RfSEFORExFKHhlbl9k
b21jdGxfc2V0X2Jyb2tlbl9wYWdlX3AybV90KTsKKwogc3RydWN0IHhlbl9kb21jdGwgewogICAg
IHVpbnQzMl90IGNtZDsKICNkZWZpbmUgWEVOX0RPTUNUTF9jcmVhdGVkb21haW4gICAgICAgICAg
ICAgICAgICAgMQpAQCAtOTAxLDYgKzkwOCw3IEBACiAjZGVmaW5lIFhFTl9ET01DVExfc2V0X3Zp
cnFfaGFuZGxlciAgICAgICAgICAgICAgNjYKICNkZWZpbmUgWEVOX0RPTUNUTF92bWNlX21vbml0
b3Jfc3RhcnQgICAgICAgICAgICA2NwogI2RlZmluZSBYRU5fRE9NQ1RMX3ZtY2VfbW9uaXRvcl9l
bmQgICAgICAgICAgICAgIDY4CisjZGVmaW5lIFhFTl9ET01DVExfc2V0X2Jyb2tlbl9wYWdlX3Ay
bSAgICAgICAgICAgNjkKICNkZWZpbmUgWEVOX0RPTUNUTF9nZGJzeF9ndWVzdG1lbWlvICAgICAg
ICAgICAgMTAwMAogI2RlZmluZSBYRU5fRE9NQ1RMX2dkYnN4X3BhdXNldmNwdSAgICAgICAgICAg
ICAxMDAxCiAjZGVmaW5lIFhFTl9ET01DVExfZ2Ric3hfdW5wYXVzZXZjcHUgICAgICAgICAgIDEw
MDIKQEAgLTk1Nyw2ICs5NjUsNyBAQAogICAgICAgICBzdHJ1Y3QgeGVuX2RvbWN0bF9zZXRfdmly
cV9oYW5kbGVyICBzZXRfdmlycV9oYW5kbGVyOwogICAgICAgICBzdHJ1Y3QgeGVuX2RvbWN0bF92
bWNlX21vbml0b3IgICAgICB2bWNlX21vbml0b3I7CiAgICAgICAgIHN0cnVjdCB4ZW5fZG9tY3Rs
X2dkYnN4X21lbWlvICAgICAgIGdkYnN4X2d1ZXN0X21lbWlvOworICAgICAgICBzdHJ1Y3QgeGVu
X2RvbWN0bF9zZXRfYnJva2VuX3BhZ2VfcDJtIHNldF9icm9rZW5fcGFnZV9wMm07CiAgICAgICAg
IHN0cnVjdCB4ZW5fZG9tY3RsX2dkYnN4X3BhdXNldW5wX3ZjcHUgZ2Ric3hfcGF1c2V1bnBfdmNw
dTsKICAgICAgICAgc3RydWN0IHhlbl9kb21jdGxfZ2Ric3hfZG9tc3RhdHVzICAgZ2Ric3hfZG9t
c3RhdHVzOwogICAgICAgICB1aW50OF90ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBwYWRb
MTI4XTsK

--_002_DE8DF0795D48FD4CA783C40EC829233532F451SHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 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_DE8DF0795D48FD4CA783C40EC829233532F451SHSMSX101ccrcorpi_--


From xen-devel-bounces@lists.xen.org Tue Sep 18 13:41:00 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Sep 2012 13:41:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDy2c-0006rh-Oj; Tue, 18 Sep 2012 13:40: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 1TDy2b-0006rc-0O
	for xen-devel@lists.xensource.com; Tue, 18 Sep 2012 13:40:41 +0000
Received: from [85.158.139.211:54318] by server-5.bemta-5.messagelabs.com id
	99/3D-30514-8D978505; Tue, 18 Sep 2012 13:40:40 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-206.messagelabs.com!1347975638!19007870!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDk5MjE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24516 invoked from network); 18 Sep 2012 13:40:39 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Sep 2012 13:40:39 -0000
X-IronPort-AV: E=Sophos;i="4.80,442,1344211200"; d="scan'208";a="14607815"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Sep 2012 13:40: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.279.1; Tue, 18 Sep 2012 14:40: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 1TDy1y-00057I-Qw;
	Tue, 18 Sep 2012 13:40:02 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1TDy1y-0006Dx-9U;
	Tue, 18 Sep 2012 14:40:02 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-13805-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Tue, 18 Sep 2012 14:40:02 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13805: 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 13805 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13805/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore            fail   like 13802
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail like 13802
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail like 13802

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  d1c3375c3f11
baseline version:
 xen                  d1c3375c3f11

jobs:
 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-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-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-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-amd64-amd64-xl-win                                      fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Published tested tree is already up to date.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 18 13:41:00 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Sep 2012 13:41:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDy2c-0006rh-Oj; Tue, 18 Sep 2012 13:40: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 1TDy2b-0006rc-0O
	for xen-devel@lists.xensource.com; Tue, 18 Sep 2012 13:40:41 +0000
Received: from [85.158.139.211:54318] by server-5.bemta-5.messagelabs.com id
	99/3D-30514-8D978505; Tue, 18 Sep 2012 13:40:40 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-206.messagelabs.com!1347975638!19007870!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDk5MjE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24516 invoked from network); 18 Sep 2012 13:40:39 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Sep 2012 13:40:39 -0000
X-IronPort-AV: E=Sophos;i="4.80,442,1344211200"; d="scan'208";a="14607815"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Sep 2012 13:40: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.279.1; Tue, 18 Sep 2012 14:40: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 1TDy1y-00057I-Qw;
	Tue, 18 Sep 2012 13:40:02 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1TDy1y-0006Dx-9U;
	Tue, 18 Sep 2012 14:40:02 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-13805-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Tue, 18 Sep 2012 14:40:02 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13805: 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 13805 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13805/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore            fail   like 13802
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail like 13802
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail like 13802

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  d1c3375c3f11
baseline version:
 xen                  d1c3375c3f11

jobs:
 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-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-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-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-amd64-amd64-xl-win                                      fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Published tested tree is already up to date.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 18 13:48:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Sep 2012 13:48:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDy9U-00074T-LT; Tue, 18 Sep 2012 13:47: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 1TDy9T-00074M-Cg
	for xen-devel@lists.xensource.com; Tue, 18 Sep 2012 13:47:47 +0000
Received: from [85.158.138.51:15573] by server-3.bemta-3.messagelabs.com id
	35/E3-21322-28B78505; Tue, 18 Sep 2012 13:47:46 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1347976064!22162063!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzQ3OTcz\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15929 invoked from network); 18 Sep 2012 13:47:45 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-7.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 18 Sep 2012 13:47:45 -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 q8IDleUL011004
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 18 Sep 2012 13:47: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
	q8IDldNE011728
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 18 Sep 2012 13:47:40 GMT
Received: from abhmt105.oracle.com (abhmt105.oracle.com [141.146.116.57])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q8IDldbi032642; Tue, 18 Sep 2012 08:47:39 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 18 Sep 2012 06:47:39 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 0891B402B8; Tue, 18 Sep 2012 09:36:51 -0400 (EDT)
Date: Tue, 18 Sep 2012 09:36:50 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: William Dauchy <wdauchy@gmail.com>
Message-ID: <20120918133650.GC12053@phenom.dumpdata.com>
References: <CAJ75kXZm-BqWdL2O41XkSE1VCdd4ruW=+CqDmR1b3=701RnXmw@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAJ75kXZm-BqWdL2O41XkSE1VCdd4ruW=+CqDmR1b3=701RnXmw@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
Subject: Re: [Xen-devel] Error getting mfn
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Sep 18, 2012 at 10:24:42AM +0200, William Dauchy wrote:
> Hello,
> 
> I'm getting many "Error getting mfn" on a xen4.1.3 with dom0 3.4.11 x86_32.

You need to provide more. The full serial log please, and also the
.config.

Since this is 32-bit, I wonder if you are hitting the CONFIG_NUMA issue...
but I think you reported it some time ago and did you try the fix?

> I thought it could be related to
> xen/mmu: Release just the MFN list, not MFN list and part of pagetables.
> http://git.kernel.org/?p=linux/kernel/git/konrad/xen.git;a=commit;h=785f62314984ea3af9dd830b020289ba2509ae69

That shouldn't be it - b/c the URL you mentioned is for the set of patches
that are destined for v3.7.

> 
> (XEN) Freed 212kB init memory.
> (XEN) mm.c:908:d0 Error getting mfn 2009b (pfn 5555555555555555) from
> L1 entry 000000002009b023 for l1e_owner=0, pg_owner=0
> (XEN) mm.c:908:d0 Error getting mfn 2009c (pfn 5555555555555555) from
> L1 entry 000000002009c023 for l1e_owner=0, pg_owner=0
> [...]
> (XEN) mm.c:908:d0 Error getting mfn c32116 (pfn 5555555555555555) from
> L1 entry 8000000c32116063 for l1e_owner=0, pg_owner=0
> (XEN) mm.c:908:d0 Error getting mfn c32117 (pfn 5555555555555555) from
> L1 entry 8000000c32117063 for l1e_owner=0, pg_owner=0

Please use 'sync_console loglvl=all dom0_max_vcpus=1 console=com1 com1=xxxxx' and on the Linux command line:
'console=hvc0 debug loglevel=8"

> (XEN) ../physdev.c:171: dom0: wrong map_pirq type 3
> 
> Any hint?
> 
> Regards,
> -- 
> William

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 18 13:48:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Sep 2012 13:48:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDy9U-00074T-LT; Tue, 18 Sep 2012 13:47: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 1TDy9T-00074M-Cg
	for xen-devel@lists.xensource.com; Tue, 18 Sep 2012 13:47:47 +0000
Received: from [85.158.138.51:15573] by server-3.bemta-3.messagelabs.com id
	35/E3-21322-28B78505; Tue, 18 Sep 2012 13:47:46 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1347976064!22162063!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzQ3OTcz\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15929 invoked from network); 18 Sep 2012 13:47:45 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-7.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 18 Sep 2012 13:47:45 -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 q8IDleUL011004
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 18 Sep 2012 13:47: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
	q8IDldNE011728
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 18 Sep 2012 13:47:40 GMT
Received: from abhmt105.oracle.com (abhmt105.oracle.com [141.146.116.57])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q8IDldbi032642; Tue, 18 Sep 2012 08:47:39 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 18 Sep 2012 06:47:39 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 0891B402B8; Tue, 18 Sep 2012 09:36:51 -0400 (EDT)
Date: Tue, 18 Sep 2012 09:36:50 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: William Dauchy <wdauchy@gmail.com>
Message-ID: <20120918133650.GC12053@phenom.dumpdata.com>
References: <CAJ75kXZm-BqWdL2O41XkSE1VCdd4ruW=+CqDmR1b3=701RnXmw@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAJ75kXZm-BqWdL2O41XkSE1VCdd4ruW=+CqDmR1b3=701RnXmw@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
Subject: Re: [Xen-devel] Error getting mfn
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Sep 18, 2012 at 10:24:42AM +0200, William Dauchy wrote:
> Hello,
> 
> I'm getting many "Error getting mfn" on a xen4.1.3 with dom0 3.4.11 x86_32.

You need to provide more. The full serial log please, and also the
.config.

Since this is 32-bit, I wonder if you are hitting the CONFIG_NUMA issue...
but I think you reported it some time ago and did you try the fix?

> I thought it could be related to
> xen/mmu: Release just the MFN list, not MFN list and part of pagetables.
> http://git.kernel.org/?p=linux/kernel/git/konrad/xen.git;a=commit;h=785f62314984ea3af9dd830b020289ba2509ae69

That shouldn't be it - b/c the URL you mentioned is for the set of patches
that are destined for v3.7.

> 
> (XEN) Freed 212kB init memory.
> (XEN) mm.c:908:d0 Error getting mfn 2009b (pfn 5555555555555555) from
> L1 entry 000000002009b023 for l1e_owner=0, pg_owner=0
> (XEN) mm.c:908:d0 Error getting mfn 2009c (pfn 5555555555555555) from
> L1 entry 000000002009c023 for l1e_owner=0, pg_owner=0
> [...]
> (XEN) mm.c:908:d0 Error getting mfn c32116 (pfn 5555555555555555) from
> L1 entry 8000000c32116063 for l1e_owner=0, pg_owner=0
> (XEN) mm.c:908:d0 Error getting mfn c32117 (pfn 5555555555555555) from
> L1 entry 8000000c32117063 for l1e_owner=0, pg_owner=0

Please use 'sync_console loglvl=all dom0_max_vcpus=1 console=com1 com1=xxxxx' and on the Linux command line:
'console=hvc0 debug loglevel=8"

> (XEN) ../physdev.c:171: dom0: wrong map_pirq type 3
> 
> Any hint?
> 
> Regards,
> -- 
> William

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 18 13:56:53 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Sep 2012 13:56:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDyHz-0007Uy-FP; Tue, 18 Sep 2012 13:56:35 +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 1TDyHy-0007Up-4V
	for xen-devel@lists.xen.org; Tue, 18 Sep 2012 13:56:34 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1347976586!2171257!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDc1Nzk4OQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19359 invoked from network); 18 Sep 2012 13:56:28 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-11.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 18 Sep 2012 13:56:28 -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 q8IDtpPJ023034
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 18 Sep 2012 13:55:53 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
	q8IDtnXJ004299
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 18 Sep 2012 13:55:50 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
	q8IDtkmo010525; Tue, 18 Sep 2012 08:55:48 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 18 Sep 2012 06:55:46 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id EEF86402B8; Tue, 18 Sep 2012 09:44:57 -0400 (EDT)
Date: Tue, 18 Sep 2012 09:44:57 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Andre Przywara <andre.przywara@amd.com>
Message-ID: <20120918134457.GE12053@phenom.dumpdata.com>
References: <501BC20F.3040205@amd.com>
	<20120803123628.GB10670@andromeda.dapyr.net>
	<20120817142237.GA8467@phenom.dumpdata.com>
	<20120914185822.GA7495@phenom.dumpdata.com>
	<5056D152.2090708@amd.com>
	<20120917191432.GA18552@phenom.dumpdata.com>
	<5058458D.7030603@amd.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <5058458D.7030603@amd.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: Konrad Rzeszutek Wilk <konrad@kernel.org>,
	Jeremy Fitzhardinge <jeremy@goop.org>, xen-devel <xen-devel@lists.xen.org>,
	Dario Faggioli <raistlin@linux.it>,
	Konrad Rzeszutek Wilk <konrad@darnok.org>
Subject: Re: [Xen-devel] Dom0 crash with old style AMD NUMA detection
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Sep 18, 2012 at 11:57:33AM +0200, Andre Przywara wrote:
> On 09/17/2012 09:14 PM, Konrad Rzeszutek Wilk wrote:
> >On Mon, Sep 17, 2012 at 09:29:22AM +0200, Andre Przywara wrote:
> >>On 09/14/2012 08:58 PM, Konrad Rzeszutek Wilk wrote:
> >>>>>>[    0.000000] Kernel panic - not syncing: Attempted to kill the idle task!
> >>>>>>(XEN) Domain 0 crashed: 'noreboot' set - not rebooting.
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>The obvious solution would be to explicitly deny northbridge scanning
> >>>>>>when running as Dom0, though I am not sure how to implement this without
> >>>>>>upsetting the other kernel folks about "that crappy Xen thing" again ;-)
> >>>>>
> >>>>>Heh.
> >>>>>Is there a numa=0 option that could be used to override it to turn it
> >>>>>off?
> >>>>
> >>>>Not compile tested.. but was thinking something like this:
> >>>
> >>>ping?
> >>
> >>That looks good to me - at least for the time being.
> >
> >OK, can I've your Tested-by/Acked-by on it pls?
> >
> >>I just want to check how this interacts with upcoming Dom0 NUMA
> >>support. It wouldn't be too clever if we deliberately disable NUMA
> >
> >We can always revert this patch in future versions of Linux.
> 
> I don't like this idea. Then we have Linux kernel up to 3.5 working
> and say from 3.8 on again, but 3.6 and 3.7 cannot use NUMA. That
> would be pretty unfortunate.

Huh? v3.5 working? But it never worked? I would say turn off the NUMA
detection (keep in mind it still will set up the dummy NUMA stuff)
until there are some PV NUMA capability and then we can revert it.

> 
> I haven't checked back with Dario, but I'd suspect that we use ACPI
> for injecting NUMA topology into Dom0. Even if not, a general
> "numa=off" for Dom0 is too much of a sledgehammer for me.

How would you inject it in Dom0? It s a PV guest so the hypervisor would
have to tweak the SRAT/SLIT tables. That is not going to happen
in the very short term.. And I don't recall seeing any patches, so
the dom0 NUMA support is right now non-existent?

> 
> >>and future Xen version will allow us to use it. So let me check if I
> >>can confine this turn-off to the fallback K8 northbridge reading.
> >
> >This potentially could work, but I would prefer to not do it for 3.6.
> 
> Mmh, I don't get the idea of your patch below. One can always read
> the NUMA topology from the AMD northbridge, but this is deprecated
> if favor of ACPI. The amdtopology.c stuff was only there to enable
> NUMA for very early Opterons, where BIOSes didn't provide (sane)
> SRAT tables.
> Though we disallow ACPI for NUMA on Dom0, this northbridge scanning
> unfortunately "shines through" the virtualization, actually
> revealing the system's NUMA topology, which is usually much
> different from Dom0's one.

Right, but isn't that what you found broke? It wasn't ACPI NUMA
but the old-style K8 northbridge information? That is what we are
trying to fix.

> 
> So instead I want to do more something like this:
> 
> diff --git a/arch/x86/include/asm/numa.h b/arch/x86/include/asm/numa.h
> index bfacd2c..7811c0d 100644
> --- a/arch/x86/include/asm/numa.h
> +++ b/arch/x86/include/asm/numa.h
> @@ -20,6 +20,8 @@
> 
>  extern int numa_off;
> 
> +extern bool deny_amd_nb_numa_scan;
> +
>  /*
>   * __apicid_to_node[] stores the raw mapping between physical apicid and
>   * node and is used to initialize cpu_to_node mapping.
> diff --git a/arch/x86/mm/amdtopology.c b/arch/x86/mm/amdtopology.c
> index 5247d01..f223a67 100644
> --- a/arch/x86/mm/amdtopology.c
> +++ b/arch/x86/mm/amdtopology.c
> @@ -29,6 +29,8 @@
> 
>  static unsigned char __initdata nodeids[8];
> 
> +bool deny_amd_nb_numa_scan = 0;
> +
>  static __init int find_northbridge(void)
>  {
>  	int num;
> @@ -78,6 +80,9 @@ int __init amd_numa_init(void)
>  	u32 nodeid, reg;
>  	unsigned int bits, cores, apicid_base;
> 
> +	if (deny_amd_nb_numa_scan)
> +		return -ENOENT;
> +
>  	if (!early_pci_allowed())
>  		return -EINVAL;
> 
> diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c
> index d11ca11..6db63c0 100644
> --- a/arch/x86/xen/setup.c
> +++ b/arch/x86/xen/setup.c
> @@ -532,6 +532,8 @@ void __init xen_arch_setup(void)
>  	}
>  #endif
> 
> +	deny_amd_nb_numa_scan = 1;
> +
>  	memcpy(boot_command_line, xen_start_info->cmd_line,
>  	       MAX_GUEST_CMDLINE > COMMAND_LINE_SIZE ?
>  	       COMMAND_LINE_SIZE : MAX_GUEST_CMDLINE);
> 
> This would just turn off this one kind of NUMA discovery for Dom0.
> The patch is admittedly a bit rough (not sure about the proper
> placement into #ifdef's, for instance) and not well tested yet.
> Also one could think about using a more general variable name to
> cover other hardware things in the future that Dom0 shouldn't use.
> So this isn't something still for 3.6, probably not even for 3.7.
> 
> What about if we drop the patch for this problem at all for 3.6 and
> recommend "numa=off" as a workaround? This is much less sticky than
> a kernel patch and could appear in the Xen wiki, for instance.

I hate workarounds. People end up using them forever and they get
codified.

> After all this isn't a strict regression (appears with every 3.x
> kernel, AFAICT).
> Most of the time the northbridge scanning will yield bogus results,
> so the kernel eventually discards it, but sometimes it seems to slip
> through and causes trouble.
> Also it does not trigger on newer (Bulldozer) class CPUs, since we
> deliberately avoided adding the new northbridge PCI-ID for this
> routine.

Right, you end up using the ACPI NUMA in them.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 18 13:56:53 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Sep 2012 13:56:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDyHz-0007Uy-FP; Tue, 18 Sep 2012 13:56:35 +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 1TDyHy-0007Up-4V
	for xen-devel@lists.xen.org; Tue, 18 Sep 2012 13:56:34 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1347976586!2171257!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDc1Nzk4OQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19359 invoked from network); 18 Sep 2012 13:56:28 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-11.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 18 Sep 2012 13:56:28 -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 q8IDtpPJ023034
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 18 Sep 2012 13:55:53 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
	q8IDtnXJ004299
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 18 Sep 2012 13:55:50 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
	q8IDtkmo010525; Tue, 18 Sep 2012 08:55:48 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 18 Sep 2012 06:55:46 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id EEF86402B8; Tue, 18 Sep 2012 09:44:57 -0400 (EDT)
Date: Tue, 18 Sep 2012 09:44:57 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Andre Przywara <andre.przywara@amd.com>
Message-ID: <20120918134457.GE12053@phenom.dumpdata.com>
References: <501BC20F.3040205@amd.com>
	<20120803123628.GB10670@andromeda.dapyr.net>
	<20120817142237.GA8467@phenom.dumpdata.com>
	<20120914185822.GA7495@phenom.dumpdata.com>
	<5056D152.2090708@amd.com>
	<20120917191432.GA18552@phenom.dumpdata.com>
	<5058458D.7030603@amd.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <5058458D.7030603@amd.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: Konrad Rzeszutek Wilk <konrad@kernel.org>,
	Jeremy Fitzhardinge <jeremy@goop.org>, xen-devel <xen-devel@lists.xen.org>,
	Dario Faggioli <raistlin@linux.it>,
	Konrad Rzeszutek Wilk <konrad@darnok.org>
Subject: Re: [Xen-devel] Dom0 crash with old style AMD NUMA detection
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Sep 18, 2012 at 11:57:33AM +0200, Andre Przywara wrote:
> On 09/17/2012 09:14 PM, Konrad Rzeszutek Wilk wrote:
> >On Mon, Sep 17, 2012 at 09:29:22AM +0200, Andre Przywara wrote:
> >>On 09/14/2012 08:58 PM, Konrad Rzeszutek Wilk wrote:
> >>>>>>[    0.000000] Kernel panic - not syncing: Attempted to kill the idle task!
> >>>>>>(XEN) Domain 0 crashed: 'noreboot' set - not rebooting.
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>The obvious solution would be to explicitly deny northbridge scanning
> >>>>>>when running as Dom0, though I am not sure how to implement this without
> >>>>>>upsetting the other kernel folks about "that crappy Xen thing" again ;-)
> >>>>>
> >>>>>Heh.
> >>>>>Is there a numa=0 option that could be used to override it to turn it
> >>>>>off?
> >>>>
> >>>>Not compile tested.. but was thinking something like this:
> >>>
> >>>ping?
> >>
> >>That looks good to me - at least for the time being.
> >
> >OK, can I've your Tested-by/Acked-by on it pls?
> >
> >>I just want to check how this interacts with upcoming Dom0 NUMA
> >>support. It wouldn't be too clever if we deliberately disable NUMA
> >
> >We can always revert this patch in future versions of Linux.
> 
> I don't like this idea. Then we have Linux kernel up to 3.5 working
> and say from 3.8 on again, but 3.6 and 3.7 cannot use NUMA. That
> would be pretty unfortunate.

Huh? v3.5 working? But it never worked? I would say turn off the NUMA
detection (keep in mind it still will set up the dummy NUMA stuff)
until there are some PV NUMA capability and then we can revert it.

> 
> I haven't checked back with Dario, but I'd suspect that we use ACPI
> for injecting NUMA topology into Dom0. Even if not, a general
> "numa=off" for Dom0 is too much of a sledgehammer for me.

How would you inject it in Dom0? It s a PV guest so the hypervisor would
have to tweak the SRAT/SLIT tables. That is not going to happen
in the very short term.. And I don't recall seeing any patches, so
the dom0 NUMA support is right now non-existent?

> 
> >>and future Xen version will allow us to use it. So let me check if I
> >>can confine this turn-off to the fallback K8 northbridge reading.
> >
> >This potentially could work, but I would prefer to not do it for 3.6.
> 
> Mmh, I don't get the idea of your patch below. One can always read
> the NUMA topology from the AMD northbridge, but this is deprecated
> if favor of ACPI. The amdtopology.c stuff was only there to enable
> NUMA for very early Opterons, where BIOSes didn't provide (sane)
> SRAT tables.
> Though we disallow ACPI for NUMA on Dom0, this northbridge scanning
> unfortunately "shines through" the virtualization, actually
> revealing the system's NUMA topology, which is usually much
> different from Dom0's one.

Right, but isn't that what you found broke? It wasn't ACPI NUMA
but the old-style K8 northbridge information? That is what we are
trying to fix.

> 
> So instead I want to do more something like this:
> 
> diff --git a/arch/x86/include/asm/numa.h b/arch/x86/include/asm/numa.h
> index bfacd2c..7811c0d 100644
> --- a/arch/x86/include/asm/numa.h
> +++ b/arch/x86/include/asm/numa.h
> @@ -20,6 +20,8 @@
> 
>  extern int numa_off;
> 
> +extern bool deny_amd_nb_numa_scan;
> +
>  /*
>   * __apicid_to_node[] stores the raw mapping between physical apicid and
>   * node and is used to initialize cpu_to_node mapping.
> diff --git a/arch/x86/mm/amdtopology.c b/arch/x86/mm/amdtopology.c
> index 5247d01..f223a67 100644
> --- a/arch/x86/mm/amdtopology.c
> +++ b/arch/x86/mm/amdtopology.c
> @@ -29,6 +29,8 @@
> 
>  static unsigned char __initdata nodeids[8];
> 
> +bool deny_amd_nb_numa_scan = 0;
> +
>  static __init int find_northbridge(void)
>  {
>  	int num;
> @@ -78,6 +80,9 @@ int __init amd_numa_init(void)
>  	u32 nodeid, reg;
>  	unsigned int bits, cores, apicid_base;
> 
> +	if (deny_amd_nb_numa_scan)
> +		return -ENOENT;
> +
>  	if (!early_pci_allowed())
>  		return -EINVAL;
> 
> diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c
> index d11ca11..6db63c0 100644
> --- a/arch/x86/xen/setup.c
> +++ b/arch/x86/xen/setup.c
> @@ -532,6 +532,8 @@ void __init xen_arch_setup(void)
>  	}
>  #endif
> 
> +	deny_amd_nb_numa_scan = 1;
> +
>  	memcpy(boot_command_line, xen_start_info->cmd_line,
>  	       MAX_GUEST_CMDLINE > COMMAND_LINE_SIZE ?
>  	       COMMAND_LINE_SIZE : MAX_GUEST_CMDLINE);
> 
> This would just turn off this one kind of NUMA discovery for Dom0.
> The patch is admittedly a bit rough (not sure about the proper
> placement into #ifdef's, for instance) and not well tested yet.
> Also one could think about using a more general variable name to
> cover other hardware things in the future that Dom0 shouldn't use.
> So this isn't something still for 3.6, probably not even for 3.7.
> 
> What about if we drop the patch for this problem at all for 3.6 and
> recommend "numa=off" as a workaround? This is much less sticky than
> a kernel patch and could appear in the Xen wiki, for instance.

I hate workarounds. People end up using them forever and they get
codified.

> After all this isn't a strict regression (appears with every 3.x
> kernel, AFAICT).
> Most of the time the northbridge scanning will yield bogus results,
> so the kernel eventually discards it, but sometimes it seems to slip
> through and causes trouble.
> Also it does not trigger on newer (Bulldozer) class CPUs, since we
> deliberately avoided adding the new northbridge PCI-ID for this
> routine.

Right, you end up using the ACPI NUMA in them.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 18 13:58:09 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Sep 2012 13:58:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDyJG-0007Zy-UO; Tue, 18 Sep 2012 13:57:54 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1TDyJF-0007Zk-FU
	for xen-devel@lists.xensource.com; Tue, 18 Sep 2012 13:57:53 +0000
Received: from [85.158.143.99:45045] by server-3.bemta-4.messagelabs.com id
	AE/1D-08232-0ED78505; Tue, 18 Sep 2012 13:57:52 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1347976672!30867040!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDk5MjE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22827 invoked from network); 18 Sep 2012 13:57:52 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Sep 2012 13:57:52 -0000
X-IronPort-AV: E=Sophos;i="4.80,442,1344211200"; d="scan'208";a="14608418"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Sep 2012 13:57: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.279.1; Tue, 18 Sep 2012 14:57:52 +0100
Date: Tue, 18 Sep 2012 14:57:05 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Arnd Bergmann <arnd@arndb.de>
In-Reply-To: <201209181234.29557.arnd@arndb.de>
Message-ID: <alpine.DEB.2.02.1209181450570.29232@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1209171215490.29232@kaball.uk.xensource.com>
	<201209181234.29557.arnd@arndb.de>
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>,
	"linaro-dev@lists.linaro.org" <linaro-dev@lists.linaro.org>,
	Ian Campbell <Ian.Campbell@citrix.com>, Pawel Moll <pawel.moll@arm.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"Tim \(Xen.org\)" <tim@xen.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Russell King - ARM Linux <linux@arm.linux.org.uk>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Xen-devel] [PATCH v5 00/17] Introduce Xen support on ARM
 (based on 3.6-rc5)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 18 Sep 2012, Arnd Bergmann wrote:
> On Monday 17 September 2012, Stefano Stabellini wrote:
> 
> > I am also attaching to this email the dts'es that I am currently using
> > for dom0 and domU: vexpress-v2p-ca15-tc1.dts (that includes
> > vexpress-v2m-rs1-rtsm.dtsi) is the dts used for dom0 and it is passed to
> > Linux by Xen, while vexpress-virt.dts is the dts used for other domUs
> > and it is appended in binary form to the guest kernel image. I am not
> > sure where they are supposed to live yet, so I am just attaching them
> > here so that people can actually try out this series if they want to.
> 
> You can submit the dts files separately so we can include them in
> the arm-soc tree. Pawel Moll is handling vexpress related changes these
> days, so it would be reasonable if he included them in a pull request.

OK, I'll submit them as a patch series separately.


> > The patch series has been rebased on Konrad's stable/for-linus-3.7
> > branch.
> > 
> > Arnd, Russell, what do you think about this series? If you are OK with
> > it, to whom should I submit it?
> 
> I have no objections to your patches from this series. IMHO they should
> be submitted through the Xen tree,
    
Konrad, are you happy to carry this series in your tree?


>but it would be good to have an Ack from Russell.

Indeed

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 18 13:58:09 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Sep 2012 13:58:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDyJG-0007Zy-UO; Tue, 18 Sep 2012 13:57:54 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1TDyJF-0007Zk-FU
	for xen-devel@lists.xensource.com; Tue, 18 Sep 2012 13:57:53 +0000
Received: from [85.158.143.99:45045] by server-3.bemta-4.messagelabs.com id
	AE/1D-08232-0ED78505; Tue, 18 Sep 2012 13:57:52 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1347976672!30867040!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDk5MjE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22827 invoked from network); 18 Sep 2012 13:57:52 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Sep 2012 13:57:52 -0000
X-IronPort-AV: E=Sophos;i="4.80,442,1344211200"; d="scan'208";a="14608418"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Sep 2012 13:57: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.279.1; Tue, 18 Sep 2012 14:57:52 +0100
Date: Tue, 18 Sep 2012 14:57:05 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Arnd Bergmann <arnd@arndb.de>
In-Reply-To: <201209181234.29557.arnd@arndb.de>
Message-ID: <alpine.DEB.2.02.1209181450570.29232@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1209171215490.29232@kaball.uk.xensource.com>
	<201209181234.29557.arnd@arndb.de>
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>,
	"linaro-dev@lists.linaro.org" <linaro-dev@lists.linaro.org>,
	Ian Campbell <Ian.Campbell@citrix.com>, Pawel Moll <pawel.moll@arm.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"Tim \(Xen.org\)" <tim@xen.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Russell King - ARM Linux <linux@arm.linux.org.uk>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Xen-devel] [PATCH v5 00/17] Introduce Xen support on ARM
 (based on 3.6-rc5)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 18 Sep 2012, Arnd Bergmann wrote:
> On Monday 17 September 2012, Stefano Stabellini wrote:
> 
> > I am also attaching to this email the dts'es that I am currently using
> > for dom0 and domU: vexpress-v2p-ca15-tc1.dts (that includes
> > vexpress-v2m-rs1-rtsm.dtsi) is the dts used for dom0 and it is passed to
> > Linux by Xen, while vexpress-virt.dts is the dts used for other domUs
> > and it is appended in binary form to the guest kernel image. I am not
> > sure where they are supposed to live yet, so I am just attaching them
> > here so that people can actually try out this series if they want to.
> 
> You can submit the dts files separately so we can include them in
> the arm-soc tree. Pawel Moll is handling vexpress related changes these
> days, so it would be reasonable if he included them in a pull request.

OK, I'll submit them as a patch series separately.


> > The patch series has been rebased on Konrad's stable/for-linus-3.7
> > branch.
> > 
> > Arnd, Russell, what do you think about this series? If you are OK with
> > it, to whom should I submit it?
> 
> I have no objections to your patches from this series. IMHO they should
> be submitted through the Xen tree,
    
Konrad, are you happy to carry this series in your tree?


>but it would be good to have an Ack from Russell.

Indeed

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 18 14:05:00 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Sep 2012 14:05: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 1TDyPt-00080A-Q1; Tue, 18 Sep 2012 14:04:45 +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 1TDyPs-000805-99
	for xen-devel@lists.xensource.com; Tue, 18 Sep 2012 14:04:44 +0000
Received: from [85.158.139.211:38563] by server-3.bemta-5.messagelabs.com id
	7B/87-21836-B7F78505; Tue, 18 Sep 2012 14:04:43 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-16.tower-206.messagelabs.com!1347977081!19070252!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDc1Nzk4OQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12692 invoked from network); 18 Sep 2012 14:04:42 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-16.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 18 Sep 2012 14:04:42 -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 q8IE4JZJ001788
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 18 Sep 2012 14:04:20 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
	q8IE4IVG028411
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 18 Sep 2012 14:04:18 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
	q8IE4HN3015694; Tue, 18 Sep 2012 09:04:17 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 18 Sep 2012 07:04:17 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 75E86402C0; Tue, 18 Sep 2012 09:53:28 -0400 (EDT)
Date: Tue, 18 Sep 2012 09:53:28 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Arnd Bergmann <arnd@arndb.de>, linux@arm.linux.org.uk
Message-ID: <20120918135328.GG12053@phenom.dumpdata.com>
References: <alpine.DEB.2.02.1209171215490.29232@kaball.uk.xensource.com>
	<201209181234.29557.arnd@arndb.de>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <201209181234.29557.arnd@arndb.de>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linaro-dev@lists.linaro.org" <linaro-dev@lists.linaro.org>,
	Ian Campbell <Ian.Campbell@citrix.com>, Pawel Moll <pawel.moll@arm.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"Tim \(Xen.org\)" <tim@xen.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Russell King - ARM Linux <linux@arm.linux.org.uk>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Xen-devel] [PATCH v5 00/17] Introduce Xen support on ARM
	(based on 3.6-rc5)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Sep 18, 2012 at 12:34:29PM +0000, Arnd Bergmann wrote:
> On Monday 17 September 2012, Stefano Stabellini wrote:
> 
> > I am also attaching to this email the dts'es that I am currently using
> > for dom0 and domU: vexpress-v2p-ca15-tc1.dts (that includes
> > vexpress-v2m-rs1-rtsm.dtsi) is the dts used for dom0 and it is passed to
> > Linux by Xen, while vexpress-virt.dts is the dts used for other domUs
> > and it is appended in binary form to the guest kernel image. I am not
> > sure where they are supposed to live yet, so I am just attaching them
> > here so that people can actually try out this series if they want to.
> 
> You can submit the dts files separately so we can include them in
> the arm-soc tree. Pawel Moll is handling vexpress related changes these
> days, so it would be reasonable if he included them in a pull request.
>  
> > The patch series has been rebased on Konrad's stable/for-linus-3.7
> > branch.
> > 
> > Arnd, Russell, what do you think about this series? If you are OK with
> > it, to whom should I submit it?
> 
> I have no objections to your patches from this series. IMHO they should
> be submitted through the Xen tree, but it would be good to have an Ack
> from Russell.

OK, I can do that.

How do we get Russell to look at these patches? Bribes? Ship him some
beer/wine to be delievered to his office?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 18 14:05:00 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Sep 2012 14:05: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 1TDyPt-00080A-Q1; Tue, 18 Sep 2012 14:04:45 +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 1TDyPs-000805-99
	for xen-devel@lists.xensource.com; Tue, 18 Sep 2012 14:04:44 +0000
Received: from [85.158.139.211:38563] by server-3.bemta-5.messagelabs.com id
	7B/87-21836-B7F78505; Tue, 18 Sep 2012 14:04:43 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-16.tower-206.messagelabs.com!1347977081!19070252!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDc1Nzk4OQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12692 invoked from network); 18 Sep 2012 14:04:42 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-16.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 18 Sep 2012 14:04:42 -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 q8IE4JZJ001788
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 18 Sep 2012 14:04:20 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
	q8IE4IVG028411
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 18 Sep 2012 14:04:18 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
	q8IE4HN3015694; Tue, 18 Sep 2012 09:04:17 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 18 Sep 2012 07:04:17 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 75E86402C0; Tue, 18 Sep 2012 09:53:28 -0400 (EDT)
Date: Tue, 18 Sep 2012 09:53:28 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Arnd Bergmann <arnd@arndb.de>, linux@arm.linux.org.uk
Message-ID: <20120918135328.GG12053@phenom.dumpdata.com>
References: <alpine.DEB.2.02.1209171215490.29232@kaball.uk.xensource.com>
	<201209181234.29557.arnd@arndb.de>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <201209181234.29557.arnd@arndb.de>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linaro-dev@lists.linaro.org" <linaro-dev@lists.linaro.org>,
	Ian Campbell <Ian.Campbell@citrix.com>, Pawel Moll <pawel.moll@arm.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"Tim \(Xen.org\)" <tim@xen.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Russell King - ARM Linux <linux@arm.linux.org.uk>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Xen-devel] [PATCH v5 00/17] Introduce Xen support on ARM
	(based on 3.6-rc5)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Sep 18, 2012 at 12:34:29PM +0000, Arnd Bergmann wrote:
> On Monday 17 September 2012, Stefano Stabellini wrote:
> 
> > I am also attaching to this email the dts'es that I am currently using
> > for dom0 and domU: vexpress-v2p-ca15-tc1.dts (that includes
> > vexpress-v2m-rs1-rtsm.dtsi) is the dts used for dom0 and it is passed to
> > Linux by Xen, while vexpress-virt.dts is the dts used for other domUs
> > and it is appended in binary form to the guest kernel image. I am not
> > sure where they are supposed to live yet, so I am just attaching them
> > here so that people can actually try out this series if they want to.
> 
> You can submit the dts files separately so we can include them in
> the arm-soc tree. Pawel Moll is handling vexpress related changes these
> days, so it would be reasonable if he included them in a pull request.
>  
> > The patch series has been rebased on Konrad's stable/for-linus-3.7
> > branch.
> > 
> > Arnd, Russell, what do you think about this series? If you are OK with
> > it, to whom should I submit it?
> 
> I have no objections to your patches from this series. IMHO they should
> be submitted through the Xen tree, but it would be good to have an Ack
> from Russell.

OK, I can do that.

How do we get Russell to look at these patches? Bribes? Ship him some
beer/wine to be delievered to his office?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 18 14:09:44 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Sep 2012 14: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 1TDyUV-0008CZ-Gx; Tue, 18 Sep 2012 14:09:31 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1TDyUU-0008CS-Ct
	for xen-devel@lists.xen.org; Tue, 18 Sep 2012 14:09:30 +0000
Received: from [85.158.139.83:8223] by server-4.bemta-5.messagelabs.com id
	A7/CC-23042-99088505; Tue, 18 Sep 2012 14:09:29 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-6.tower-182.messagelabs.com!1347977368!27165974!1
X-Originating-IP: [63.239.67.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32205 invoked from network); 18 Sep 2012 14:09:28 -0000
Received: from emvm-gh1-uea09.nsa.gov (HELO nsa.gov) (63.239.67.10)
	by server-6.tower-182.messagelabs.com with SMTP;
	18 Sep 2012 14:09:28 -0000
X-TM-IMSS-Message-ID: <5861b0200013e752@nsa.gov>
Received: from tarius.tycho.ncsc.mil ([144.51.3.1]) by nsa.gov
	([63.239.67.10]) with ESMTP (TREND IMSS SMTP Service 7.1) id
	5861b0200013e752 ; Tue, 18 Sep 2012 10:11:02 -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 q8IE98N0003677; 
	Tue, 18 Sep 2012 10:09:08 -0400
Message-ID: <50588084.3090300@tycho.nsa.gov>
Date: Tue, 18 Sep 2012 10:09:08 -0400
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Organization: National Security Agency
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120828 Thunderbird/15.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <1347895425-17959-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1347895425-17959-20-git-send-email-dgdegra@tycho.nsa.gov>
	<50583D35020000780009BFB0@nat28.tlf.novell.com>
In-Reply-To: <50583D35020000780009BFB0@nat28.tlf.novell.com>
Cc: Tim Deegan <tim@xen.org>, keir@xen.org, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 19/23] arch/x86: check remote MMIO remap
	permissions
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 09/18/2012 03:21 AM, Jan Beulich wrote:
>>>> On 17.09.12 at 17:23, Daniel De Graaf <dgdegra@tycho.nsa.gov> wrote:
>> --- a/xen/arch/x86/mm.c
>> +++ b/xen/arch/x86/mm.c
>> @@ -754,6 +754,18 @@ get_page_from_l1e(
>>              return -EINVAL;
>>          }
>>  
>> +        if ( pg_owner != curr->domain &&
>> +             !iomem_access_permitted(curr->domain, mfn, mfn) )
> 
> On a second (or third?) look, I don't think this is right - the current
> domain doesn't matter here at all. What does matter is who's page
> tables the mapping is to be put in (i.e. l1e_owner), which of course
> in certain cases ends up being the current domain.
> 
> Jan

Ignoring current->domain allows a malicious domain with access to
remotely manipulate page tables to create a device mapping where the
target domain doesn't expect one. Except, now that I've said that ... 
any domain with the ability to change another domain's page tables
almost certainly can control execution in that target domain, so that
attack doesn't get you anywhere you couldn't already go.

Checking the page table owner for iomem access is useful here, I'll 
change the patch to do that. 

>> +        {
>> +            if ( mfn != (PADDR_MASK >> PAGE_SHIFT) ) /* INVALID_MFN? */
>> +            {
>> +                MEM_LOG("Domain %u attempted to map I/O space %08lx in domain %u",
>> +                        curr->domain->domain_id, mfn, pg_owner->domain_id);
>> +                return -EPERM;
>> +            }
>> +            return -EINVAL;
>> +        }
>> +
>>          if ( !(l1f & _PAGE_RW) ||
>>               !rangeset_contains_singleton(mmio_ro_ranges, mfn) )
>>              return 0;
>> -- 
>> 1.7.11.4

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 18 14:09:44 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Sep 2012 14: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 1TDyUV-0008CZ-Gx; Tue, 18 Sep 2012 14:09:31 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1TDyUU-0008CS-Ct
	for xen-devel@lists.xen.org; Tue, 18 Sep 2012 14:09:30 +0000
Received: from [85.158.139.83:8223] by server-4.bemta-5.messagelabs.com id
	A7/CC-23042-99088505; Tue, 18 Sep 2012 14:09:29 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-6.tower-182.messagelabs.com!1347977368!27165974!1
X-Originating-IP: [63.239.67.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32205 invoked from network); 18 Sep 2012 14:09:28 -0000
Received: from emvm-gh1-uea09.nsa.gov (HELO nsa.gov) (63.239.67.10)
	by server-6.tower-182.messagelabs.com with SMTP;
	18 Sep 2012 14:09:28 -0000
X-TM-IMSS-Message-ID: <5861b0200013e752@nsa.gov>
Received: from tarius.tycho.ncsc.mil ([144.51.3.1]) by nsa.gov
	([63.239.67.10]) with ESMTP (TREND IMSS SMTP Service 7.1) id
	5861b0200013e752 ; Tue, 18 Sep 2012 10:11:02 -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 q8IE98N0003677; 
	Tue, 18 Sep 2012 10:09:08 -0400
Message-ID: <50588084.3090300@tycho.nsa.gov>
Date: Tue, 18 Sep 2012 10:09:08 -0400
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Organization: National Security Agency
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120828 Thunderbird/15.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <1347895425-17959-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1347895425-17959-20-git-send-email-dgdegra@tycho.nsa.gov>
	<50583D35020000780009BFB0@nat28.tlf.novell.com>
In-Reply-To: <50583D35020000780009BFB0@nat28.tlf.novell.com>
Cc: Tim Deegan <tim@xen.org>, keir@xen.org, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 19/23] arch/x86: check remote MMIO remap
	permissions
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 09/18/2012 03:21 AM, Jan Beulich wrote:
>>>> On 17.09.12 at 17:23, Daniel De Graaf <dgdegra@tycho.nsa.gov> wrote:
>> --- a/xen/arch/x86/mm.c
>> +++ b/xen/arch/x86/mm.c
>> @@ -754,6 +754,18 @@ get_page_from_l1e(
>>              return -EINVAL;
>>          }
>>  
>> +        if ( pg_owner != curr->domain &&
>> +             !iomem_access_permitted(curr->domain, mfn, mfn) )
> 
> On a second (or third?) look, I don't think this is right - the current
> domain doesn't matter here at all. What does matter is who's page
> tables the mapping is to be put in (i.e. l1e_owner), which of course
> in certain cases ends up being the current domain.
> 
> Jan

Ignoring current->domain allows a malicious domain with access to
remotely manipulate page tables to create a device mapping where the
target domain doesn't expect one. Except, now that I've said that ... 
any domain with the ability to change another domain's page tables
almost certainly can control execution in that target domain, so that
attack doesn't get you anywhere you couldn't already go.

Checking the page table owner for iomem access is useful here, I'll 
change the patch to do that. 

>> +        {
>> +            if ( mfn != (PADDR_MASK >> PAGE_SHIFT) ) /* INVALID_MFN? */
>> +            {
>> +                MEM_LOG("Domain %u attempted to map I/O space %08lx in domain %u",
>> +                        curr->domain->domain_id, mfn, pg_owner->domain_id);
>> +                return -EPERM;
>> +            }
>> +            return -EINVAL;
>> +        }
>> +
>>          if ( !(l1f & _PAGE_RW) ||
>>               !rangeset_contains_singleton(mmio_ro_ranges, mfn) )
>>              return 0;
>> -- 
>> 1.7.11.4

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 18 14:25:00 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Sep 2012 14:25:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDyj8-0008Nk-29; Tue, 18 Sep 2012 14:24:38 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <stern+505e1c76@rowland.harvard.edu>)
	id 1TDyj6-0008Nf-6v
	for xen-devel@lists.xen.org; Tue, 18 Sep 2012 14:24:36 +0000
Received: from [85.158.139.211:16574] by server-11.bemta-5.messagelabs.com id
	70/8E-24658-32488505; Tue, 18 Sep 2012 14:24:35 +0000
X-Env-Sender: stern+505e1c76@rowland.harvard.edu
X-Msg-Ref: server-8.tower-206.messagelabs.com!1347978274!19015064!1
X-Originating-IP: [192.131.102.54]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17861 invoked from network); 18 Sep 2012 14:24:34 -0000
Received: from iolanthe.rowland.org (HELO iolanthe.rowland.org)
	(192.131.102.54) by server-8.tower-206.messagelabs.com with SMTP;
	18 Sep 2012 14:24:34 -0000
Received: (qmail 2037 invoked by uid 2102); 18 Sep 2012 10:24:32 -0400
Received: from localhost (sendmail-bs@127.0.0.1)
	by localhost with SMTP; 18 Sep 2012 10:24:32 -0400
Date: Tue, 18 Sep 2012 10:24:32 -0400 (EDT)
From: Alan Stern <stern@rowland.harvard.edu>
X-X-Sender: stern@iolanthe.rowland.org
To: Jan Beulich <JBeulich@suse.com>
In-Reply-To: <505875B6020000780009C01D@nat28.tlf.novell.com>
Message-ID: <Pine.LNX.4.44L0.1209181023510.2000-100000@iolanthe.rowland.org>
MIME-Version: 1.0
Cc: gregkh@linuxfoundation.org, xen-devel <xen-devel@lists.xen.org>,
	linux-usb@vger.kernel.org, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH] EHCI/Xen: propagate controller reset
 information to hypervisor
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 18 Sep 2012, Jan Beulich wrote:

> Just like for the in-tree early console debug port driver, the
> hypervisor - when using a debug port based console - also needs to be
> told about controller resets, so it can suppress using and then
> re-initialize the debug port accordingly.
> 
> Other than the in-tree driver, the hypervisor driver actually cares
> about doing this only for the device where the debug is port actually
> in use, i.e. it needs to be told the coordinates of the device being
> reset (quite obviously, leveraging the addition done for that would
> likely benefit the in-tree driver too).
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

For the ehci-hcd parts:

Acked-by: Alan Stern <stern@rowland.harvard.edu>


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 18 14:25:00 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Sep 2012 14:25:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDyj8-0008Nk-29; Tue, 18 Sep 2012 14:24:38 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <stern+505e1c76@rowland.harvard.edu>)
	id 1TDyj6-0008Nf-6v
	for xen-devel@lists.xen.org; Tue, 18 Sep 2012 14:24:36 +0000
Received: from [85.158.139.211:16574] by server-11.bemta-5.messagelabs.com id
	70/8E-24658-32488505; Tue, 18 Sep 2012 14:24:35 +0000
X-Env-Sender: stern+505e1c76@rowland.harvard.edu
X-Msg-Ref: server-8.tower-206.messagelabs.com!1347978274!19015064!1
X-Originating-IP: [192.131.102.54]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17861 invoked from network); 18 Sep 2012 14:24:34 -0000
Received: from iolanthe.rowland.org (HELO iolanthe.rowland.org)
	(192.131.102.54) by server-8.tower-206.messagelabs.com with SMTP;
	18 Sep 2012 14:24:34 -0000
Received: (qmail 2037 invoked by uid 2102); 18 Sep 2012 10:24:32 -0400
Received: from localhost (sendmail-bs@127.0.0.1)
	by localhost with SMTP; 18 Sep 2012 10:24:32 -0400
Date: Tue, 18 Sep 2012 10:24:32 -0400 (EDT)
From: Alan Stern <stern@rowland.harvard.edu>
X-X-Sender: stern@iolanthe.rowland.org
To: Jan Beulich <JBeulich@suse.com>
In-Reply-To: <505875B6020000780009C01D@nat28.tlf.novell.com>
Message-ID: <Pine.LNX.4.44L0.1209181023510.2000-100000@iolanthe.rowland.org>
MIME-Version: 1.0
Cc: gregkh@linuxfoundation.org, xen-devel <xen-devel@lists.xen.org>,
	linux-usb@vger.kernel.org, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH] EHCI/Xen: propagate controller reset
 information to hypervisor
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 18 Sep 2012, Jan Beulich wrote:

> Just like for the in-tree early console debug port driver, the
> hypervisor - when using a debug port based console - also needs to be
> told about controller resets, so it can suppress using and then
> re-initialize the debug port accordingly.
> 
> Other than the in-tree driver, the hypervisor driver actually cares
> about doing this only for the device where the debug is port actually
> in use, i.e. it needs to be told the coordinates of the device being
> reset (quite obviously, leveraging the addition done for that would
> likely benefit the in-tree driver too).
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

For the ehci-hcd parts:

Acked-by: Alan Stern <stern@rowland.harvard.edu>


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 18 14:26:54 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Sep 2012 14: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 1TDyl0-0008SQ-JW; Tue, 18 Sep 2012 14:26:34 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <netwiz@crc.id.au>) id 1TDykz-0008SI-AQ
	for xen-devel@lists.xen.org; Tue, 18 Sep 2012 14:26:33 +0000
Received: from [85.158.139.211:27029] by server-9.bemta-5.messagelabs.com id
	6A/1F-20529-89488505; Tue, 18 Sep 2012 14:26:32 +0000
X-Env-Sender: netwiz@crc.id.au
X-Msg-Ref: server-8.tower-206.messagelabs.com!1347978389!19015438!1
X-Originating-IP: [203.56.246.92]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_8,
	spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25329 invoked from network); 18 Sep 2012 14:26:30 -0000
Received: from mail.crc.id.au (HELO mail.crc.id.au) (203.56.246.92)
	by server-8.tower-206.messagelabs.com with SMTP;
	18 Sep 2012 14:26:30 -0000
Received: from [IPv6:2002:cb38:f71b:2:f182:71ef:6e1c:e882] (unknown
	[IPv6:2002:cb38:f71b:2:f182:71ef:6e1c:e882])
	by mail.crc.id.au (Postfix) with ESMTPSA id E9952B2
	for <xen-devel@lists.xen.org>; Wed, 19 Sep 2012 00:26:25 +1000 (EST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=crc.id.au; s=default;
	t=1347978385; bh=+nFFugSN6q+7xQl1xW/miJV78lHJqu63Mz4uGJPva6I=;
	h=Date:From:To:Subject;
	b=Tf6XINrQplsm0Fi20xrHimGkFvj8c28owy1gskV4synjQhbUk2aroAKtvW7asJU24
	Loa4lC/TxllZ5FYVGNe8JSw2HP+g1Uf+sh757Q6YHgM12vwgiod8I7oncok1OuaysI
	YGJOt1UyHy/pXgUjII9rsRuzyGDhdyQOJcutLvKE=
Message-ID: <50588493.7080908@crc.id.au>
Date: Wed, 19 Sep 2012 00:26:27 +1000
From: Steven Haigh <netwiz@crc.id.au>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:15.0) Gecko/20120907 Thunderbird/15.0.1
MIME-Version: 1.0
To: xen-devel@lists.xen.org
Subject: [Xen-devel] Packaging Xen 4.2.0
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi all,

I'm trying to update my RPMs of 4.1.3 to work with 4.2.0, but I'm having 
some interesting problems with the packaging side of things.

in 4.1.3, xenpaging was being built as /usr/sbin/xenpaging, however in 
4.2.0 it is being built as /usr/lib/xen/bin/xenpaging.

I'm currently using the following configure options in my .spec:
./configure --libdir=/%{_libdir} --prefix=/usr --bindir=/%{_bindir} 
--sbindir=/%{_sbindir}

This is expanding to:
./configure --libdir=/usr/lib64 --prefix=/usr --bindir=/usr/bin 
--sbindir=/usr/sbin

So, I'm wondering how xenpaging is getting that path info - however I do 
see a lot of what seem to be hard coded references to 
/usr/lib/xen/bin/xenpaging with a quick grep around the source.

A penny for peoples thoughts?

-- 
Steven Haigh

Email: netwiz@crc.id.au
Web: http://www.crc.id.au
Phone: (03) 9001 6090 - 0412 935 897
Fax: (03) 8338 0299

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 18 14:26:54 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Sep 2012 14: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 1TDyl0-0008SQ-JW; Tue, 18 Sep 2012 14:26:34 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <netwiz@crc.id.au>) id 1TDykz-0008SI-AQ
	for xen-devel@lists.xen.org; Tue, 18 Sep 2012 14:26:33 +0000
Received: from [85.158.139.211:27029] by server-9.bemta-5.messagelabs.com id
	6A/1F-20529-89488505; Tue, 18 Sep 2012 14:26:32 +0000
X-Env-Sender: netwiz@crc.id.au
X-Msg-Ref: server-8.tower-206.messagelabs.com!1347978389!19015438!1
X-Originating-IP: [203.56.246.92]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_8,
	spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25329 invoked from network); 18 Sep 2012 14:26:30 -0000
Received: from mail.crc.id.au (HELO mail.crc.id.au) (203.56.246.92)
	by server-8.tower-206.messagelabs.com with SMTP;
	18 Sep 2012 14:26:30 -0000
Received: from [IPv6:2002:cb38:f71b:2:f182:71ef:6e1c:e882] (unknown
	[IPv6:2002:cb38:f71b:2:f182:71ef:6e1c:e882])
	by mail.crc.id.au (Postfix) with ESMTPSA id E9952B2
	for <xen-devel@lists.xen.org>; Wed, 19 Sep 2012 00:26:25 +1000 (EST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=crc.id.au; s=default;
	t=1347978385; bh=+nFFugSN6q+7xQl1xW/miJV78lHJqu63Mz4uGJPva6I=;
	h=Date:From:To:Subject;
	b=Tf6XINrQplsm0Fi20xrHimGkFvj8c28owy1gskV4synjQhbUk2aroAKtvW7asJU24
	Loa4lC/TxllZ5FYVGNe8JSw2HP+g1Uf+sh757Q6YHgM12vwgiod8I7oncok1OuaysI
	YGJOt1UyHy/pXgUjII9rsRuzyGDhdyQOJcutLvKE=
Message-ID: <50588493.7080908@crc.id.au>
Date: Wed, 19 Sep 2012 00:26:27 +1000
From: Steven Haigh <netwiz@crc.id.au>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:15.0) Gecko/20120907 Thunderbird/15.0.1
MIME-Version: 1.0
To: xen-devel@lists.xen.org
Subject: [Xen-devel] Packaging Xen 4.2.0
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi all,

I'm trying to update my RPMs of 4.1.3 to work with 4.2.0, but I'm having 
some interesting problems with the packaging side of things.

in 4.1.3, xenpaging was being built as /usr/sbin/xenpaging, however in 
4.2.0 it is being built as /usr/lib/xen/bin/xenpaging.

I'm currently using the following configure options in my .spec:
./configure --libdir=/%{_libdir} --prefix=/usr --bindir=/%{_bindir} 
--sbindir=/%{_sbindir}

This is expanding to:
./configure --libdir=/usr/lib64 --prefix=/usr --bindir=/usr/bin 
--sbindir=/usr/sbin

So, I'm wondering how xenpaging is getting that path info - however I do 
see a lot of what seem to be hard coded references to 
/usr/lib/xen/bin/xenpaging with a quick grep around the source.

A penny for peoples thoughts?

-- 
Steven Haigh

Email: netwiz@crc.id.au
Web: http://www.crc.id.au
Phone: (03) 9001 6090 - 0412 935 897
Fax: (03) 8338 0299

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 18 14:29:01 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Sep 2012 14:29: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 1TDyn7-00008e-4A; Tue, 18 Sep 2012 14:28:45 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <netwiz@crc.id.au>) id 1TDyn5-00008X-B9
	for xen-devel@lists.xen.org; Tue, 18 Sep 2012 14:28:43 +0000
Received: from [85.158.137.99:38386] by server-4.bemta-3.messagelabs.com id
	2B/BF-24831-A1588505; Tue, 18 Sep 2012 14:28:42 +0000
X-Env-Sender: netwiz@crc.id.au
X-Msg-Ref: server-3.tower-217.messagelabs.com!1347978511!13107378!1
X-Originating-IP: [203.56.246.92]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_8,
	spamassassin: ,
	async_handler: YXN5bmNfZGVsYXk6IDcwNDE2NDQgKHRpbWVvdXQp\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7976 invoked from network); 18 Sep 2012 14:28:32 -0000
Received: from mail.crc.id.au (HELO mail.crc.id.au) (203.56.246.92)
	by server-3.tower-217.messagelabs.com with SMTP;
	18 Sep 2012 14:28:32 -0000
Received: from [IPv6:2002:cb38:f71b:2:f182:71ef:6e1c:e882] (unknown
	[IPv6:2002:cb38:f71b:2:f182:71ef:6e1c:e882])
	by mail.crc.id.au (Postfix) with ESMTPSA id A5538B2
	for <xen-devel@lists.xen.org>; Wed, 19 Sep 2012 00:28:29 +1000 (EST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=crc.id.au; s=default;
	t=1347978509; bh=mSmi1ISKFpkbYeF03I34a9/Jg1KHA5Zg9P0ZD3oJayo=;
	h=Date:From:To:Subject;
	b=EDQMKgbXh3QFN5n54cRWo+hUhA08ZSeu6cmwrS31T+y6P3yX5zHIzsPJTFyOcnuFs
	5eGN2DlAj7wXm/YZ1jsicThFJBCZVJ8ZvkPWukeOccAbpI9Dy/sokX93Q2lAZupL0T
	6zJNGqBM9riaaj2Km3gbegJ1P18RVv9GgdKyyxwo=
Message-ID: <5058850F.6000800@crc.id.au>
Date: Wed, 19 Sep 2012 00:28:31 +1000
From: Steven Haigh <netwiz@crc.id.au>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:15.0) Gecko/20120907 Thunderbird/15.0.1
MIME-Version: 1.0
To: xen-devel@lists.xen.org
Subject: [Xen-devel] Problems building qemu-xen-dir tools
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
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,

I've noticed I have had to apply the following patch to get tools to 
compile properly under an EL6 environment:

--- xen-4.2.0.orig/tools/Makefile       2012-09-17 20:21:18.000000000 +1000
+++ xen-4.2.0/tools/Makefile   2012-09-18 18:55:09.989148544 +1000
@@ -187,6 +187,7 @@ subdir-all-qemu-xen-dir: qemu-xen-dir-fi
      source=.; \
     fi; \
     cd qemu-xen-dir; \
+   env -u CFLAGS \
     $$source/configure --enable-xen --target-list=i386-softmmu \
      --source-path=$$source \
      --extra-cflags="-I$(XEN_ROOT)/tools/include \

Without this, the build fails due to incompatible CFLAGS.

-- 
Steven Haigh

Email: netwiz@crc.id.au
Web: http://www.crc.id.au
Phone: (03) 9001 6090 - 0412 935 897
Fax: (03) 8338 0299

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 18 14:29:01 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Sep 2012 14:29: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 1TDyn7-00008e-4A; Tue, 18 Sep 2012 14:28:45 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <netwiz@crc.id.au>) id 1TDyn5-00008X-B9
	for xen-devel@lists.xen.org; Tue, 18 Sep 2012 14:28:43 +0000
Received: from [85.158.137.99:38386] by server-4.bemta-3.messagelabs.com id
	2B/BF-24831-A1588505; Tue, 18 Sep 2012 14:28:42 +0000
X-Env-Sender: netwiz@crc.id.au
X-Msg-Ref: server-3.tower-217.messagelabs.com!1347978511!13107378!1
X-Originating-IP: [203.56.246.92]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_8,
	spamassassin: ,
	async_handler: YXN5bmNfZGVsYXk6IDcwNDE2NDQgKHRpbWVvdXQp\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7976 invoked from network); 18 Sep 2012 14:28:32 -0000
Received: from mail.crc.id.au (HELO mail.crc.id.au) (203.56.246.92)
	by server-3.tower-217.messagelabs.com with SMTP;
	18 Sep 2012 14:28:32 -0000
Received: from [IPv6:2002:cb38:f71b:2:f182:71ef:6e1c:e882] (unknown
	[IPv6:2002:cb38:f71b:2:f182:71ef:6e1c:e882])
	by mail.crc.id.au (Postfix) with ESMTPSA id A5538B2
	for <xen-devel@lists.xen.org>; Wed, 19 Sep 2012 00:28:29 +1000 (EST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=crc.id.au; s=default;
	t=1347978509; bh=mSmi1ISKFpkbYeF03I34a9/Jg1KHA5Zg9P0ZD3oJayo=;
	h=Date:From:To:Subject;
	b=EDQMKgbXh3QFN5n54cRWo+hUhA08ZSeu6cmwrS31T+y6P3yX5zHIzsPJTFyOcnuFs
	5eGN2DlAj7wXm/YZ1jsicThFJBCZVJ8ZvkPWukeOccAbpI9Dy/sokX93Q2lAZupL0T
	6zJNGqBM9riaaj2Km3gbegJ1P18RVv9GgdKyyxwo=
Message-ID: <5058850F.6000800@crc.id.au>
Date: Wed, 19 Sep 2012 00:28:31 +1000
From: Steven Haigh <netwiz@crc.id.au>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:15.0) Gecko/20120907 Thunderbird/15.0.1
MIME-Version: 1.0
To: xen-devel@lists.xen.org
Subject: [Xen-devel] Problems building qemu-xen-dir tools
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
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,

I've noticed I have had to apply the following patch to get tools to 
compile properly under an EL6 environment:

--- xen-4.2.0.orig/tools/Makefile       2012-09-17 20:21:18.000000000 +1000
+++ xen-4.2.0/tools/Makefile   2012-09-18 18:55:09.989148544 +1000
@@ -187,6 +187,7 @@ subdir-all-qemu-xen-dir: qemu-xen-dir-fi
      source=.; \
     fi; \
     cd qemu-xen-dir; \
+   env -u CFLAGS \
     $$source/configure --enable-xen --target-list=i386-softmmu \
      --source-path=$$source \
      --extra-cflags="-I$(XEN_ROOT)/tools/include \

Without this, the build fails due to incompatible CFLAGS.

-- 
Steven Haigh

Email: netwiz@crc.id.au
Web: http://www.crc.id.au
Phone: (03) 9001 6090 - 0412 935 897
Fax: (03) 8338 0299

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 18 14:31:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Sep 2012 14:31:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDyp6-0000Jm-RX; Tue, 18 Sep 2012 14:30:48 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <navinjpatel336@gmail.com>) id 1TDyp5-0000Ja-Mr
	for xen-devel@lists.xen.org; Tue, 18 Sep 2012 14:30:47 +0000
Received: from [85.158.139.83:45356] by server-11.bemta-5.messagelabs.com id
	7C/79-24658-69588505; Tue, 18 Sep 2012 14:30:46 +0000
X-Env-Sender: navinjpatel336@gmail.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1347978644!30893097!1
X-Originating-IP: [209.85.214.173]
X-SpamReason: No, hits=2.0 required=7.0 tests=HTML_40_50,HTML_MESSAGE,
	MAILTO_TO_SPAM_ADDR,ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,USERPASS,
	spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20781 invoked from network); 18 Sep 2012 14:30:46 -0000
Received: from mail-ob0-f173.google.com (HELO mail-ob0-f173.google.com)
	(209.85.214.173)
	by server-12.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Sep 2012 14:30:46 -0000
Received: by obbta14 with SMTP id ta14so13184943obb.32
	for <xen-devel@lists.xen.org>; Tue, 18 Sep 2012 07:30:44 -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=amIzq7iQrYsTmvs0vZQTDBYN5SNaTbIwLLGFiBMqPps=;
	b=KtoKYw+I2LxAcPJH8luv/RU77MSk2yZgzQjg6hveXy3fgrlz7Sew1VNcHsahcPcyDN
	ABWlX3lET5Ye/e0YsKE9GEDnZvBBQcuI0KcvvwYXjrHPrbFH1eCnRiSp7CPklzEBWAcJ
	PSuYmBTTdQb+R99/mbg9Efq6LlBFWKYEdhzGnmBQxYAWrj8ce2KyRQJgnxHLiO9Nq+UN
	ix2DDDkI7C0TXQqMw3hh3bhZabMM4JtWXIcAGXvfWd/Vt1GMGAMqeamPzof9iQO78pmo
	FTGU+SQp9/zmogZuMUC3Cr64PChqN0riJnSd0RMP0USfHVXBznNm5WQcaMempkdxQ2Fw
	vnlg==
MIME-Version: 1.0
Received: by 10.60.170.47 with SMTP id aj15mr96587oec.29.1347978644394; Tue,
	18 Sep 2012 07:30:44 -0700 (PDT)
Received: by 10.76.117.73 with HTTP; Tue, 18 Sep 2012 07:30:44 -0700 (PDT)
In-Reply-To: <CC7BDB1E.4BE20%keir@xen.org>
References: <CALEYbrhhLsnx_o2kezp+WbR553iwkHRPO7MQ5Nxi27n-ZovvVA@mail.gmail.com>
	<CC7BDB1E.4BE20%keir@xen.org>
Date: Tue, 18 Sep 2012 10:30:44 -0400
Message-ID: <CALEYbrjgyeFH2WO5SgL0RyYFQqq1YnLQGFuBn+v-SzTQREGi_A@mail.gmail.com>
From: Navin Patel <navinjpatel336@gmail.com>
To: Keir Fraser <keir@xen.org>
Cc: Steven Maresca <steve@zentific.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] 4.2.0-rc4 bug: memory events for CR3 register are
 broken (working in 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: multipart/mixed; boundary="===============8175586529263857930=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============8175586529263857930==
Content-Type: multipart/alternative; boundary=bcaec54c522843913204c9fabce8

--bcaec54c522843913204c9fabce8
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

Keir,

On Sun, Sep 16, 2012 at 2:38 PM, Keir Fraser <keir@xen.org> wrote:

>  Keep an eye on xen-unstable and make sure the patch, or equivalent, goes
> in in the next week or two. Once it=92s in you can request it be backport=
ed.
>
>  -- Keir
>
>
> On 16/09/2012 19:35, "Navin Patel" <navinjpatel336@gmail.com> wrote:
>
> Keir and Steven,
>
> Thank you for your work. The proposed patch solved the bug!
>
> After 4.2.0 is officially released this week, I very much hope that this
> patch is backported to the 4.2.0 tree. Several distributions like Debian
> are already building upon 4.2.0 and will not wait for 4.2.1, and without
> the patch being backported, researchers like me will not be able to use t=
he
> supported Xen from package repository.  We can compile from source, but i=
f
> we have a supported version it is better for everyone. (And it is such a
> simple patch! )
>
> Is this something I can request in formal manner?
>
>  Now that this patch is in xen-unstable.hg, I would like to request that
it be backported to 4.2.0 as we discussed.

Thank you!

Navin

--bcaec54c522843913204c9fabce8
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

Keir,<br><br><div class=3D"gmail_quote">On Sun, Sep 16, 2012 at 2:38 PM, Ke=
ir Fraser <span dir=3D"ltr">&lt;<a href=3D"mailto:keir@xen.org" target=3D"_=
blank">keir@xen.org</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quo=
te" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"=
>




<div>
<font face=3D"Calibri, Verdana, Helvetica, Arial"><span style=3D"font-size:=
11pt">Keep an eye on xen-unstable and make sure the patch, or equivalent, g=
oes in in the next week or two. Once it=92s in you can request it be backpo=
rted.<span class=3D"HOEnZb"><font color=3D"#888888"><br>

<br>
=A0-- Keir</font></span><div class=3D"im"><br>
<br>
On 16/09/2012 19:35, &quot;Navin Patel&quot; &lt;<a href=3D"http://navinjpa=
tel336@gmail.com" target=3D"_blank">navinjpatel336@gmail.com</a>&gt; wrote:=
<br>
<br>
</div></span></font><div class=3D"im"><blockquote><font face=3D"Calibri, Ve=
rdana, Helvetica, Arial"><span style=3D"font-size:11pt">Keir and Steven, <b=
r>
<br>
Thank you for your work. The proposed patch solved the bug! <br>
<br>
After 4.2.0 is officially released this week, I very much hope that this pa=
tch is backported to the 4.2.0 tree. Several distributions like Debian are =
already building upon 4.2.0 and will not wait for 4.2.1, and without the pa=
tch being backported, researchers like me will not be able to use the suppo=
rted Xen from package repository.=A0 We can compile from source, but if we =
have a supported version it is better for everyone. (And it is such a simpl=
e patch! )<br>

<br>
Is this something I can request in formal manner?<br>
</span></font></blockquote>
</div></div>


</blockquote></div>Now that this patch is in xen-unstable.hg, I would like =
to request that it be backported to 4.2.0 as we discussed.<br><br>Thank you=
!<br><br>Navin<br>

--bcaec54c522843913204c9fabce8--


--===============8175586529263857930==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============8175586529263857930==--


From xen-devel-bounces@lists.xen.org Tue Sep 18 14:31:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Sep 2012 14:31:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDyp6-0000Jm-RX; Tue, 18 Sep 2012 14:30:48 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <navinjpatel336@gmail.com>) id 1TDyp5-0000Ja-Mr
	for xen-devel@lists.xen.org; Tue, 18 Sep 2012 14:30:47 +0000
Received: from [85.158.139.83:45356] by server-11.bemta-5.messagelabs.com id
	7C/79-24658-69588505; Tue, 18 Sep 2012 14:30:46 +0000
X-Env-Sender: navinjpatel336@gmail.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1347978644!30893097!1
X-Originating-IP: [209.85.214.173]
X-SpamReason: No, hits=2.0 required=7.0 tests=HTML_40_50,HTML_MESSAGE,
	MAILTO_TO_SPAM_ADDR,ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,USERPASS,
	spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20781 invoked from network); 18 Sep 2012 14:30:46 -0000
Received: from mail-ob0-f173.google.com (HELO mail-ob0-f173.google.com)
	(209.85.214.173)
	by server-12.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Sep 2012 14:30:46 -0000
Received: by obbta14 with SMTP id ta14so13184943obb.32
	for <xen-devel@lists.xen.org>; Tue, 18 Sep 2012 07:30:44 -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=amIzq7iQrYsTmvs0vZQTDBYN5SNaTbIwLLGFiBMqPps=;
	b=KtoKYw+I2LxAcPJH8luv/RU77MSk2yZgzQjg6hveXy3fgrlz7Sew1VNcHsahcPcyDN
	ABWlX3lET5Ye/e0YsKE9GEDnZvBBQcuI0KcvvwYXjrHPrbFH1eCnRiSp7CPklzEBWAcJ
	PSuYmBTTdQb+R99/mbg9Efq6LlBFWKYEdhzGnmBQxYAWrj8ce2KyRQJgnxHLiO9Nq+UN
	ix2DDDkI7C0TXQqMw3hh3bhZabMM4JtWXIcAGXvfWd/Vt1GMGAMqeamPzof9iQO78pmo
	FTGU+SQp9/zmogZuMUC3Cr64PChqN0riJnSd0RMP0USfHVXBznNm5WQcaMempkdxQ2Fw
	vnlg==
MIME-Version: 1.0
Received: by 10.60.170.47 with SMTP id aj15mr96587oec.29.1347978644394; Tue,
	18 Sep 2012 07:30:44 -0700 (PDT)
Received: by 10.76.117.73 with HTTP; Tue, 18 Sep 2012 07:30:44 -0700 (PDT)
In-Reply-To: <CC7BDB1E.4BE20%keir@xen.org>
References: <CALEYbrhhLsnx_o2kezp+WbR553iwkHRPO7MQ5Nxi27n-ZovvVA@mail.gmail.com>
	<CC7BDB1E.4BE20%keir@xen.org>
Date: Tue, 18 Sep 2012 10:30:44 -0400
Message-ID: <CALEYbrjgyeFH2WO5SgL0RyYFQqq1YnLQGFuBn+v-SzTQREGi_A@mail.gmail.com>
From: Navin Patel <navinjpatel336@gmail.com>
To: Keir Fraser <keir@xen.org>
Cc: Steven Maresca <steve@zentific.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] 4.2.0-rc4 bug: memory events for CR3 register are
 broken (working in 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: multipart/mixed; boundary="===============8175586529263857930=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============8175586529263857930==
Content-Type: multipart/alternative; boundary=bcaec54c522843913204c9fabce8

--bcaec54c522843913204c9fabce8
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

Keir,

On Sun, Sep 16, 2012 at 2:38 PM, Keir Fraser <keir@xen.org> wrote:

>  Keep an eye on xen-unstable and make sure the patch, or equivalent, goes
> in in the next week or two. Once it=92s in you can request it be backport=
ed.
>
>  -- Keir
>
>
> On 16/09/2012 19:35, "Navin Patel" <navinjpatel336@gmail.com> wrote:
>
> Keir and Steven,
>
> Thank you for your work. The proposed patch solved the bug!
>
> After 4.2.0 is officially released this week, I very much hope that this
> patch is backported to the 4.2.0 tree. Several distributions like Debian
> are already building upon 4.2.0 and will not wait for 4.2.1, and without
> the patch being backported, researchers like me will not be able to use t=
he
> supported Xen from package repository.  We can compile from source, but i=
f
> we have a supported version it is better for everyone. (And it is such a
> simple patch! )
>
> Is this something I can request in formal manner?
>
>  Now that this patch is in xen-unstable.hg, I would like to request that
it be backported to 4.2.0 as we discussed.

Thank you!

Navin

--bcaec54c522843913204c9fabce8
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

Keir,<br><br><div class=3D"gmail_quote">On Sun, Sep 16, 2012 at 2:38 PM, Ke=
ir Fraser <span dir=3D"ltr">&lt;<a href=3D"mailto:keir@xen.org" target=3D"_=
blank">keir@xen.org</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quo=
te" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"=
>




<div>
<font face=3D"Calibri, Verdana, Helvetica, Arial"><span style=3D"font-size:=
11pt">Keep an eye on xen-unstable and make sure the patch, or equivalent, g=
oes in in the next week or two. Once it=92s in you can request it be backpo=
rted.<span class=3D"HOEnZb"><font color=3D"#888888"><br>

<br>
=A0-- Keir</font></span><div class=3D"im"><br>
<br>
On 16/09/2012 19:35, &quot;Navin Patel&quot; &lt;<a href=3D"http://navinjpa=
tel336@gmail.com" target=3D"_blank">navinjpatel336@gmail.com</a>&gt; wrote:=
<br>
<br>
</div></span></font><div class=3D"im"><blockquote><font face=3D"Calibri, Ve=
rdana, Helvetica, Arial"><span style=3D"font-size:11pt">Keir and Steven, <b=
r>
<br>
Thank you for your work. The proposed patch solved the bug! <br>
<br>
After 4.2.0 is officially released this week, I very much hope that this pa=
tch is backported to the 4.2.0 tree. Several distributions like Debian are =
already building upon 4.2.0 and will not wait for 4.2.1, and without the pa=
tch being backported, researchers like me will not be able to use the suppo=
rted Xen from package repository.=A0 We can compile from source, but if we =
have a supported version it is better for everyone. (And it is such a simpl=
e patch! )<br>

<br>
Is this something I can request in formal manner?<br>
</span></font></blockquote>
</div></div>


</blockquote></div>Now that this patch is in xen-unstable.hg, I would like =
to request that it be backported to 4.2.0 as we discussed.<br><br>Thank you=
!<br><br>Navin<br>

--bcaec54c522843913204c9fabce8--


--===============8175586529263857930==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============8175586529263857930==--


From xen-devel-bounces@lists.xen.org Tue Sep 18 14:33:45 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Sep 2012 14: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 1TDyrj-0000bd-Dl; Tue, 18 Sep 2012 14:33:31 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1TDyri-0000bW-Nm
	for xen-devel@lists.xen.org; Tue, 18 Sep 2012 14:33:30 +0000
Received: from [85.158.139.83:60649] by server-10.bemta-5.messagelabs.com id
	2B/62-10969-93688505; Tue, 18 Sep 2012 14:33:29 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-10.tower-182.messagelabs.com!1347978809!31341928!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiA0MTY2ODc=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiA0MTY2ODc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27430 invoked from network); 18 Sep 2012 14:33:29 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-10.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 18 Sep 2012 14:33:29 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFGhi0PEj9t
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-088-110.pools.arcor-ip.net [88.65.88.110])
	by smtp.strato.de (josoe mo27) (RZmta 30.14 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id k00b44o8IDdAuB ;
	Tue, 18 Sep 2012 16:33:28 +0200 (CEST)
Received: by probook.site (Postfix, from userid 1000)
	id 0E4F31863E; Tue, 18 Sep 2012 16:33:27 +0200 (CEST)
Date: Tue, 18 Sep 2012 16:33:27 +0200
From: Olaf Hering <olaf@aepfle.de>
To: Steven Haigh <netwiz@crc.id.au>
Message-ID: <20120918143327.GA7115@aepfle.de>
References: <50588493.7080908@crc.id.au>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <50588493.7080908@crc.id.au>
User-Agent: Mutt/1.5.21.rev5555 (2012-07-20)
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Packaging Xen 4.2.0
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Sep 19, Steven Haigh wrote:

> A penny for peoples thoughts?

xenpaging is a private helper, similar to qemu-dm. Its currently not
integrated into xend or libxl.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 18 14:33:45 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Sep 2012 14: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 1TDyrj-0000bd-Dl; Tue, 18 Sep 2012 14:33:31 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1TDyri-0000bW-Nm
	for xen-devel@lists.xen.org; Tue, 18 Sep 2012 14:33:30 +0000
Received: from [85.158.139.83:60649] by server-10.bemta-5.messagelabs.com id
	2B/62-10969-93688505; Tue, 18 Sep 2012 14:33:29 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-10.tower-182.messagelabs.com!1347978809!31341928!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiA0MTY2ODc=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiA0MTY2ODc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27430 invoked from network); 18 Sep 2012 14:33:29 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-10.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 18 Sep 2012 14:33:29 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFGhi0PEj9t
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-088-110.pools.arcor-ip.net [88.65.88.110])
	by smtp.strato.de (josoe mo27) (RZmta 30.14 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id k00b44o8IDdAuB ;
	Tue, 18 Sep 2012 16:33:28 +0200 (CEST)
Received: by probook.site (Postfix, from userid 1000)
	id 0E4F31863E; Tue, 18 Sep 2012 16:33:27 +0200 (CEST)
Date: Tue, 18 Sep 2012 16:33:27 +0200
From: Olaf Hering <olaf@aepfle.de>
To: Steven Haigh <netwiz@crc.id.au>
Message-ID: <20120918143327.GA7115@aepfle.de>
References: <50588493.7080908@crc.id.au>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <50588493.7080908@crc.id.au>
User-Agent: Mutt/1.5.21.rev5555 (2012-07-20)
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Packaging Xen 4.2.0
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Sep 19, Steven Haigh wrote:

> A penny for peoples thoughts?

xenpaging is a private helper, similar to qemu-dm. Its currently not
integrated into xend or libxl.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 18 14:34:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Sep 2012 14:34: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 1TDysE-0000fe-S8; Tue, 18 Sep 2012 14:34:02 +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 1TDysD-0000fI-6O
	for xen-devel@lists.xen.org; Tue, 18 Sep 2012 14:34:01 +0000
Received: from [85.158.143.99:45584] by server-1.bemta-4.messagelabs.com id
	CE/C1-12504-85688505; Tue, 18 Sep 2012 14:34:00 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-9.tower-216.messagelabs.com!1347978839!30873402!1
X-Originating-IP: [188.40.164.121]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19050 invoked from network); 18 Sep 2012 14:34:00 -0000
Received: from static.121.164.40.188.clients.your-server.de (HELO
	smtp.eikelenboom.it) (188.40.164.121)
	by server-9.tower-216.messagelabs.com with AES256-SHA encrypted SMTP;
	18 Sep 2012 14:34:00 -0000
Received: from 101-67-ftth.onsneteindhoven.nl ([88.159.67.101]:55436
	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 1TDysc-0005uB-Uw; Tue, 18 Sep 2012 16:34:27 +0200
Date: Tue, 18 Sep 2012 16:33:49 +0200
From: Sander Eikelenboom <linux@eikelenboom.it>
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <1777522677.20120918163349@eikelenboom.it>
To: Javier Marcet <jmarcet@gmail.com>
In-Reply-To: <CAAnFQG96=Fm5jLqvaqxd6nf2fDAeL6t7drxqkqXzvZHYDOKaDQ@mail.gmail.com>
References: <CAAnFQG9PuzRLSsCS8m_0VUeV+ZaCwK3zsbinxtuFBfdSihJknw@mail.gmail.com>
	<CC7DF5F7.3F018%keir.xen@gmail.com>
	<CAAnFQG96=Fm5jLqvaqxd6nf2fDAeL6t7drxqkqXzvZHYDOKaDQ@mail.gmail.com>
MIME-Version: 1.0
Cc: Konrad Rzeszutek Wilk <konrad@kernel.org>, Keir Fraser <keir.xen@gmail.com>,
	Xen Devel Mailing list <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.2.0-rc4 issues with DVB tuner
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

DQpUdWVzZGF5LCBTZXB0ZW1iZXIgMTgsIDIwMTIsIDEyOjUyOjAxIFBNLCB5b3Ugd3JvdGU6Cgo+
IE9uIFR1ZSwgU2VwIDE4LCAyMDEyIGF0IDEwOjU3IEFNLCBLZWlyIEZyYXNlciA8a2Vpci54ZW5A
Z21haWwuY29tPiB3cm90ZToKCj4+PiBXaGF0IEkgZG9uwrR0IHVuZGVyc3RhbmQgaXMgaG93IGdy
YXBoaWNzIHBhc3MgdGhyb3VnaCBldmVuIHdvcmtzCj4+IGFuZCBhIHR1bmVyCj4+PiBjYXJkIGhh
cyBwcm9ibGVtcyBkdWUgdG8gdGhlIGludHJvZHVjZWQgbGF0ZW5jaWVzIGluIHRoZQo+PiBJUlFz
Lgo+Pgo+PiBEbyB5b3UgaGF2ZQo+Pj4gYW55IG1vcmUgaW5mbyBhYm91dCB0aGlzPwo+Pgo+PiBJ
biB0aGlzIHJlc3BlY3Qgc291bmQgaXMgaGFyZGVyIHRoYW4gZ3JhcGhpY3MuIFRyeSBwaW5uaW5n
IHlvdXIgZG9tMCB0byBhCj4+IENQVSBjb3JlLCBhbmQgc2V0IGFmZmluaXRpZXMgb24gb3RoZXIg
ZG9tYWlucyBzbyB0aGF0IGRvbTAgZG9lcyBub3QgY29tcGV0ZQo+PiBmb3IgdGhlIGNvcmUgd2l0
aCBhbnkgb3RoZXIgZG9tYWlucy4KCj4gQWxsIHJpZ2h0LCBJIGNhbiB0cnkgdGhhdC4gSG93ZXZl
ciwgdGhlIHByb2JsZW0gaGFwcGVucyB3aXRob3V0IGFueQo+IGRvbVUgcnVubmluZywganVzdAo+
IHRoZSBkb20wLiBEbyB5b3Ugc3RpbGwgdGhpbmsgdGhhdCBwaW5uaW5nIHRvIGEgY3B1IGNvcmUg
b3Igc2V0dGluZwo+IGFmZmluaXRpZXMgY2FuIGhlbHA/CgpJIGhhdmVuJ3QgZm9sbG93ZWQgdGhl
IHRocmVhZCBjbG9zZWx5LCBidXQgYXJlIHlvdSBzdXJlIHRoZSBkZXZpY2Ugd29ya3MgT0sgb24g
YmFyZW1ldGFsIChsaW51eCB3aXRob3V0IHhlbikgPwpJZiB5b3UgaGF2ZSBwcm9ibGVtcyBpbiBk
b20wIGl0IHNlZW1zIGl0IGhhc24ndCBnb3QgbXVjaCB0byBkbyB3aXRoIHBhc3N0aHJvdWdoID8K
Ci0tClNhbmRlcgoKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbi5vcmcKaHR0cDov
L2xpc3RzLnhlbi5vcmcveGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Tue Sep 18 14:34:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Sep 2012 14:34: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 1TDysE-0000fe-S8; Tue, 18 Sep 2012 14:34:02 +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 1TDysD-0000fI-6O
	for xen-devel@lists.xen.org; Tue, 18 Sep 2012 14:34:01 +0000
Received: from [85.158.143.99:45584] by server-1.bemta-4.messagelabs.com id
	CE/C1-12504-85688505; Tue, 18 Sep 2012 14:34:00 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-9.tower-216.messagelabs.com!1347978839!30873402!1
X-Originating-IP: [188.40.164.121]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19050 invoked from network); 18 Sep 2012 14:34:00 -0000
Received: from static.121.164.40.188.clients.your-server.de (HELO
	smtp.eikelenboom.it) (188.40.164.121)
	by server-9.tower-216.messagelabs.com with AES256-SHA encrypted SMTP;
	18 Sep 2012 14:34:00 -0000
Received: from 101-67-ftth.onsneteindhoven.nl ([88.159.67.101]:55436
	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 1TDysc-0005uB-Uw; Tue, 18 Sep 2012 16:34:27 +0200
Date: Tue, 18 Sep 2012 16:33:49 +0200
From: Sander Eikelenboom <linux@eikelenboom.it>
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <1777522677.20120918163349@eikelenboom.it>
To: Javier Marcet <jmarcet@gmail.com>
In-Reply-To: <CAAnFQG96=Fm5jLqvaqxd6nf2fDAeL6t7drxqkqXzvZHYDOKaDQ@mail.gmail.com>
References: <CAAnFQG9PuzRLSsCS8m_0VUeV+ZaCwK3zsbinxtuFBfdSihJknw@mail.gmail.com>
	<CC7DF5F7.3F018%keir.xen@gmail.com>
	<CAAnFQG96=Fm5jLqvaqxd6nf2fDAeL6t7drxqkqXzvZHYDOKaDQ@mail.gmail.com>
MIME-Version: 1.0
Cc: Konrad Rzeszutek Wilk <konrad@kernel.org>, Keir Fraser <keir.xen@gmail.com>,
	Xen Devel Mailing list <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.2.0-rc4 issues with DVB tuner
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

DQpUdWVzZGF5LCBTZXB0ZW1iZXIgMTgsIDIwMTIsIDEyOjUyOjAxIFBNLCB5b3Ugd3JvdGU6Cgo+
IE9uIFR1ZSwgU2VwIDE4LCAyMDEyIGF0IDEwOjU3IEFNLCBLZWlyIEZyYXNlciA8a2Vpci54ZW5A
Z21haWwuY29tPiB3cm90ZToKCj4+PiBXaGF0IEkgZG9uwrR0IHVuZGVyc3RhbmQgaXMgaG93IGdy
YXBoaWNzIHBhc3MgdGhyb3VnaCBldmVuIHdvcmtzCj4+IGFuZCBhIHR1bmVyCj4+PiBjYXJkIGhh
cyBwcm9ibGVtcyBkdWUgdG8gdGhlIGludHJvZHVjZWQgbGF0ZW5jaWVzIGluIHRoZQo+PiBJUlFz
Lgo+Pgo+PiBEbyB5b3UgaGF2ZQo+Pj4gYW55IG1vcmUgaW5mbyBhYm91dCB0aGlzPwo+Pgo+PiBJ
biB0aGlzIHJlc3BlY3Qgc291bmQgaXMgaGFyZGVyIHRoYW4gZ3JhcGhpY3MuIFRyeSBwaW5uaW5n
IHlvdXIgZG9tMCB0byBhCj4+IENQVSBjb3JlLCBhbmQgc2V0IGFmZmluaXRpZXMgb24gb3RoZXIg
ZG9tYWlucyBzbyB0aGF0IGRvbTAgZG9lcyBub3QgY29tcGV0ZQo+PiBmb3IgdGhlIGNvcmUgd2l0
aCBhbnkgb3RoZXIgZG9tYWlucy4KCj4gQWxsIHJpZ2h0LCBJIGNhbiB0cnkgdGhhdC4gSG93ZXZl
ciwgdGhlIHByb2JsZW0gaGFwcGVucyB3aXRob3V0IGFueQo+IGRvbVUgcnVubmluZywganVzdAo+
IHRoZSBkb20wLiBEbyB5b3Ugc3RpbGwgdGhpbmsgdGhhdCBwaW5uaW5nIHRvIGEgY3B1IGNvcmUg
b3Igc2V0dGluZwo+IGFmZmluaXRpZXMgY2FuIGhlbHA/CgpJIGhhdmVuJ3QgZm9sbG93ZWQgdGhl
IHRocmVhZCBjbG9zZWx5LCBidXQgYXJlIHlvdSBzdXJlIHRoZSBkZXZpY2Ugd29ya3MgT0sgb24g
YmFyZW1ldGFsIChsaW51eCB3aXRob3V0IHhlbikgPwpJZiB5b3UgaGF2ZSBwcm9ibGVtcyBpbiBk
b20wIGl0IHNlZW1zIGl0IGhhc24ndCBnb3QgbXVjaCB0byBkbyB3aXRoIHBhc3N0aHJvdWdoID8K
Ci0tClNhbmRlcgoKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbi5vcmcKaHR0cDov
L2xpc3RzLnhlbi5vcmcveGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Tue Sep 18 14:35:35 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Sep 2012 14:35:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDytV-0000o8-Bq; Tue, 18 Sep 2012 14:35:21 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1TDytT-0000ny-IO
	for xen-devel@lists.xen.org; Tue, 18 Sep 2012 14:35:19 +0000
Received: from [85.158.137.99:47495] by server-6.bemta-3.messagelabs.com id
	85/17-29694-6A688505; Tue, 18 Sep 2012 14:35:18 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-6.tower-217.messagelabs.com!1347978917!13035744!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiA0MTY2ODc=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiA0MTY2ODc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6119 invoked from network); 18 Sep 2012 14:35:18 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-6.tower-217.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 18 Sep 2012 14:35:18 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFGhi0PEj9t
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-088-110.pools.arcor-ip.net [88.65.88.110])
	by smtp.strato.de (josoe mo1) (RZmta 30.14 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id e001efo8IDtHld ;
	Tue, 18 Sep 2012 16:35:17 +0200 (CEST)
Received: by probook.site (Postfix, from userid 1000)
	id 0DFB31863E; Tue, 18 Sep 2012 16:35:16 +0200 (CEST)
Date: Tue, 18 Sep 2012 16:35:16 +0200
From: Olaf Hering <olaf@aepfle.de>
To: Steven Haigh <netwiz@crc.id.au>
Message-ID: <20120918143516.GA7170@aepfle.de>
References: <5058850F.6000800@crc.id.au>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <5058850F.6000800@crc.id.au>
User-Agent: Mutt/1.5.21.rev5555 (2012-07-20)
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Problems building qemu-xen-dir tools
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Sep 19, Steven Haigh wrote:

> Without this, the build fails due to incompatible CFLAGS.

CFLAGS must not be in environment, otherwise make will append its own
CFLAGS to that environment variable and pass it on to qemu. qemu itself
is not ready for things like -std=gnu99.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 18 14:35:35 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Sep 2012 14:35:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDytV-0000o8-Bq; Tue, 18 Sep 2012 14:35:21 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1TDytT-0000ny-IO
	for xen-devel@lists.xen.org; Tue, 18 Sep 2012 14:35:19 +0000
Received: from [85.158.137.99:47495] by server-6.bemta-3.messagelabs.com id
	85/17-29694-6A688505; Tue, 18 Sep 2012 14:35:18 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-6.tower-217.messagelabs.com!1347978917!13035744!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiA0MTY2ODc=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiA0MTY2ODc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6119 invoked from network); 18 Sep 2012 14:35:18 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-6.tower-217.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 18 Sep 2012 14:35:18 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFGhi0PEj9t
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-088-110.pools.arcor-ip.net [88.65.88.110])
	by smtp.strato.de (josoe mo1) (RZmta 30.14 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id e001efo8IDtHld ;
	Tue, 18 Sep 2012 16:35:17 +0200 (CEST)
Received: by probook.site (Postfix, from userid 1000)
	id 0DFB31863E; Tue, 18 Sep 2012 16:35:16 +0200 (CEST)
Date: Tue, 18 Sep 2012 16:35:16 +0200
From: Olaf Hering <olaf@aepfle.de>
To: Steven Haigh <netwiz@crc.id.au>
Message-ID: <20120918143516.GA7170@aepfle.de>
References: <5058850F.6000800@crc.id.au>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <5058850F.6000800@crc.id.au>
User-Agent: Mutt/1.5.21.rev5555 (2012-07-20)
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Problems building qemu-xen-dir tools
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Sep 19, Steven Haigh wrote:

> Without this, the build fails due to incompatible CFLAGS.

CFLAGS must not be in environment, otherwise make will append its own
CFLAGS to that environment variable and pass it on to qemu. qemu itself
is not ready for things like -std=gnu99.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 18 14:42:44 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Sep 2012 14:42:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDz0R-00016L-Dj; Tue, 18 Sep 2012 14:42:31 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <roger.pau@citrix.com>) id 1TDz0Q-00016G-Mm
	for xen-devel@lists.xen.org; Tue, 18 Sep 2012 14:42:30 +0000
Received: from [85.158.143.35:33420] by server-3.bemta-4.messagelabs.com id
	74/1B-08232-55888505; Tue, 18 Sep 2012 14:42:29 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1347979349!16337390!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDk5MjE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12724 invoked from network); 18 Sep 2012 14:42:29 -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;
	18 Sep 2012 14:42:29 -0000
X-IronPort-AV: E=Sophos;i="4.80,442,1344211200"; d="scan'208";a="14609960"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Sep 2012 14:42:28 +0000
Received: from Roger-2.local (10.31.3.235) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Tue, 18 Sep 2012 15:42:28 +0100
Message-ID: <50588852.2000809@citrix.com>
Date: Tue, 18 Sep 2012 16:42:26 +0200
From: Roger Pau Monne <roger.pau@citrix.com>
User-Agent: Postbox 3.0.5 (Macintosh/20120826)
MIME-Version: 1.0
To: Lukas Laukamp <lukas@laukamp.me>
References: <b83b0a91d6f2612e2942f37270c8da21@laukamp.me>
In-Reply-To: <b83b0a91d6f2612e2942f37270c8da21@laukamp.me>
X-Enigmail-Version: 1.2.2
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [User-Question] Xen 4.2 compilation hangs at
 stubdom directory
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Lukas Laukamp wrote:
> Hello all,
> 
> I know that here is not the best place to ask such a question but I 
> think that it's eventualy a problem of the source.
> 
> I want to create deb packages of Xen 4.2 for Ubuntu 12.04 LTS. So I 
> created an build environment with pbuilder, installed all dependencies 
> and startet the compilation of Xen.
> 
> So now the problem is that the compilation hangs without any reason in 
> the stubdom directory. So there is no error output or something like 
> this, it simply hangs and don't continue.

I had some problems when trying to compile the stubdoms using make 3.82,
Olaf also had the same problem and sent the following fix, which works
for me:

http://lists.xen.org/archives/html/xen-devel/2012-08/msg00985.html

Can you try if applying that patch solves your problems?

> As compiler I use GCC 4.6, with debhelper I created the Debian rules 
> files and I used the dist target.
> 
> Is this a known issue or is it a problem of my configuration? Would be 
> greate to get help, Xen 4.2 is a real milestone and I can only say "Go 
> on guys, good work".
> 
> Best Regards
> 
> P.S. Sorry for my bad english
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Sep 18 14:42:44 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Sep 2012 14:42:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDz0R-00016L-Dj; Tue, 18 Sep 2012 14:42:31 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <roger.pau@citrix.com>) id 1TDz0Q-00016G-Mm
	for xen-devel@lists.xen.org; Tue, 18 Sep 2012 14:42:30 +0000
Received: from [85.158.143.35:33420] by server-3.bemta-4.messagelabs.com id
	74/1B-08232-55888505; Tue, 18 Sep 2012 14:42:29 +0000
X-Env-Sender: roger.pau@citrix.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1347979349!16337390!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDk5MjE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12724 invoked from network); 18 Sep 2012 14:42:29 -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;
	18 Sep 2012 14:42:29 -0000
X-IronPort-AV: E=Sophos;i="4.80,442,1344211200"; d="scan'208";a="14609960"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Sep 2012 14:42:28 +0000
Received: from Roger-2.local (10.31.3.235) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Tue, 18 Sep 2012 15:42:28 +0100
Message-ID: <50588852.2000809@citrix.com>
Date: Tue, 18 Sep 2012 16:42:26 +0200
From: Roger Pau Monne <roger.pau@citrix.com>
User-Agent: Postbox 3.0.5 (Macintosh/20120826)
MIME-Version: 1.0
To: Lukas Laukamp <lukas@laukamp.me>
References: <b83b0a91d6f2612e2942f37270c8da21@laukamp.me>
In-Reply-To: <b83b0a91d6f2612e2942f37270c8da21@laukamp.me>
X-Enigmail-Version: 1.2.2
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [User-Question] Xen 4.2 compilation hangs at
 stubdom directory
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Lukas Laukamp wrote:
> Hello all,
> 
> I know that here is not the best place to ask such a question but I 
> think that it's eventualy a problem of the source.
> 
> I want to create deb packages of Xen 4.2 for Ubuntu 12.04 LTS. So I 
> created an build environment with pbuilder, installed all dependencies 
> and startet the compilation of Xen.
> 
> So now the problem is that the compilation hangs without any reason in 
> the stubdom directory. So there is no error output or something like 
> this, it simply hangs and don't continue.

I had some problems when trying to compile the stubdoms using make 3.82,
Olaf also had the same problem and sent the following fix, which works
for me:

http://lists.xen.org/archives/html/xen-devel/2012-08/msg00985.html

Can you try if applying that patch solves your problems?

> As compiler I use GCC 4.6, with debhelper I created the Debian rules 
> files and I used the dist target.
> 
> Is this a known issue or is it a problem of my configuration? Would be 
> greate to get help, Xen 4.2 is a real milestone and I can only say "Go 
> on guys, good work".
> 
> Best Regards
> 
> P.S. Sorry for my bad english
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Sep 18 14:49:29 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Sep 2012 14:49:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDz6w-0001Fi-9w; Tue, 18 Sep 2012 14:49:14 +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 1TDz6u-0001Fc-JU
	for xen-devel@lists.xensource.com; Tue, 18 Sep 2012 14:49:12 +0000
Received: from [85.158.139.83:59117] by server-3.bemta-5.messagelabs.com id
	B4/AC-21836-7E988505; Tue, 18 Sep 2012 14:49:11 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1347979749!30394993!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDc1Nzk4OQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30169 invoked from network); 18 Sep 2012 14:49: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; 18 Sep 2012 14:49:11 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q8IEmjhm027728
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 18 Sep 2012 14:48:45 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
	q8IEmhWG007292
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 18 Sep 2012 14:48:44 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
	q8IEmh1w024081; Tue, 18 Sep 2012 09:48:43 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 18 Sep 2012 07:48:43 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 46896402C0; Tue, 18 Sep 2012 10:37:51 -0400 (EDT)
Date: Tue, 18 Sep 2012 10:37:51 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20120918143751.GA19332@phenom.dumpdata.com>
References: <alpine.DEB.2.02.1209171215490.29232@kaball.uk.xensource.com>
	<201209181234.29557.arnd@arndb.de>
	<alpine.DEB.2.02.1209181450570.29232@kaball.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <alpine.DEB.2.02.1209181450570.29232@kaball.uk.xensource.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linaro-dev@lists.linaro.org" <linaro-dev@lists.linaro.org>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Arnd Bergmann <arnd@arndb.de>, "Tim \(Xen.org\)" <tim@xen.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Pawel Moll <pawel.moll@arm.com>,
	Russell King - ARM Linux <linux@arm.linux.org.uk>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Xen-devel] [PATCH v5 00/17] Introduce Xen support on ARM
	(based on 3.6-rc5)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Sep 18, 2012 at 02:57:05PM +0100, Stefano Stabellini wrote:
> On Tue, 18 Sep 2012, Arnd Bergmann wrote:
> > On Monday 17 September 2012, Stefano Stabellini wrote:
> > 
> > > I am also attaching to this email the dts'es that I am currently using
> > > for dom0 and domU: vexpress-v2p-ca15-tc1.dts (that includes
> > > vexpress-v2m-rs1-rtsm.dtsi) is the dts used for dom0 and it is passed to
> > > Linux by Xen, while vexpress-virt.dts is the dts used for other domUs
> > > and it is appended in binary form to the guest kernel image. I am not
> > > sure where they are supposed to live yet, so I am just attaching them
> > > here so that people can actually try out this series if they want to.
> > 
> > You can submit the dts files separately so we can include them in
> > the arm-soc tree. Pawel Moll is handling vexpress related changes these
> > days, so it would be reasonable if he included them in a pull request.
> 
> OK, I'll submit them as a patch series separately.
> 
> 
> > > The patch series has been rebased on Konrad's stable/for-linus-3.7
> > > branch.
> > > 
> > > Arnd, Russell, what do you think about this series? If you are OK with
> > > it, to whom should I submit it?
> > 
> > I have no objections to your patches from this series. IMHO they should
> > be submitted through the Xen tree,
>     
> Konrad, are you happy to carry this series in your tree?

Yes.
> 
> 
> >but it would be good to have an Ack from Russell.
> 
> Indeed

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 18 14:49:29 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Sep 2012 14:49:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDz6w-0001Fi-9w; Tue, 18 Sep 2012 14:49:14 +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 1TDz6u-0001Fc-JU
	for xen-devel@lists.xensource.com; Tue, 18 Sep 2012 14:49:12 +0000
Received: from [85.158.139.83:59117] by server-3.bemta-5.messagelabs.com id
	B4/AC-21836-7E988505; Tue, 18 Sep 2012 14:49:11 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1347979749!30394993!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDc1Nzk4OQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30169 invoked from network); 18 Sep 2012 14:49: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; 18 Sep 2012 14:49:11 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q8IEmjhm027728
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 18 Sep 2012 14:48:45 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
	q8IEmhWG007292
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 18 Sep 2012 14:48:44 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
	q8IEmh1w024081; Tue, 18 Sep 2012 09:48:43 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 18 Sep 2012 07:48:43 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 46896402C0; Tue, 18 Sep 2012 10:37:51 -0400 (EDT)
Date: Tue, 18 Sep 2012 10:37:51 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20120918143751.GA19332@phenom.dumpdata.com>
References: <alpine.DEB.2.02.1209171215490.29232@kaball.uk.xensource.com>
	<201209181234.29557.arnd@arndb.de>
	<alpine.DEB.2.02.1209181450570.29232@kaball.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <alpine.DEB.2.02.1209181450570.29232@kaball.uk.xensource.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linaro-dev@lists.linaro.org" <linaro-dev@lists.linaro.org>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Arnd Bergmann <arnd@arndb.de>, "Tim \(Xen.org\)" <tim@xen.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Pawel Moll <pawel.moll@arm.com>,
	Russell King - ARM Linux <linux@arm.linux.org.uk>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Xen-devel] [PATCH v5 00/17] Introduce Xen support on ARM
	(based on 3.6-rc5)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Sep 18, 2012 at 02:57:05PM +0100, Stefano Stabellini wrote:
> On Tue, 18 Sep 2012, Arnd Bergmann wrote:
> > On Monday 17 September 2012, Stefano Stabellini wrote:
> > 
> > > I am also attaching to this email the dts'es that I am currently using
> > > for dom0 and domU: vexpress-v2p-ca15-tc1.dts (that includes
> > > vexpress-v2m-rs1-rtsm.dtsi) is the dts used for dom0 and it is passed to
> > > Linux by Xen, while vexpress-virt.dts is the dts used for other domUs
> > > and it is appended in binary form to the guest kernel image. I am not
> > > sure where they are supposed to live yet, so I am just attaching them
> > > here so that people can actually try out this series if they want to.
> > 
> > You can submit the dts files separately so we can include them in
> > the arm-soc tree. Pawel Moll is handling vexpress related changes these
> > days, so it would be reasonable if he included them in a pull request.
> 
> OK, I'll submit them as a patch series separately.
> 
> 
> > > The patch series has been rebased on Konrad's stable/for-linus-3.7
> > > branch.
> > > 
> > > Arnd, Russell, what do you think about this series? If you are OK with
> > > it, to whom should I submit it?
> > 
> > I have no objections to your patches from this series. IMHO they should
> > be submitted through the Xen tree,
>     
> Konrad, are you happy to carry this series in your tree?

Yes.
> 
> 
> >but it would be good to have an Ack from Russell.
> 
> Indeed

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 18 14:50:45 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Sep 2012 14:50:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDz8A-0001Km-Qk; Tue, 18 Sep 2012 14:50:30 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dave.martin@linaro.org>) id 1TDz88-0001KP-MZ
	for xen-devel@lists.xensource.com; Tue, 18 Sep 2012 14:50:28 +0000
Received: from [85.158.139.83:7336] by server-9.bemta-5.messagelabs.com id
	E7/08-20529-33A88505; Tue, 18 Sep 2012 14:50:27 +0000
X-Env-Sender: dave.martin@linaro.org
X-Msg-Ref: server-9.tower-182.messagelabs.com!1347979827!30395214!1
X-Originating-IP: [74.125.83.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2505 invoked from network); 18 Sep 2012 14:50:27 -0000
Received: from mail-ee0-f43.google.com (HELO mail-ee0-f43.google.com)
	(74.125.83.43)
	by server-9.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Sep 2012 14:50:27 -0000
Received: by eekd4 with SMTP id d4so4099172eek.30
	for <xen-devel@lists.xensource.com>;
	Tue, 18 Sep 2012 07:50:26 -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=+cYAl8PsLQfKfGTFxb298PTfCDDlOjrSjVhqwPquOHE=;
	b=b3F1BwDQneVAWKv3BcrlsDuTNUrgvwysPdvfFCWjp5v7YQAn1XfPAZjPCLFlgZQkze
	nShmZ8te1vaX3n5Ki4hRaJMuT+qz8jC+aI9L70ymqULWl6LRajjf6tHrvXII+OKw1qRS
	W2J+EkPvWlV8Ka7TmGFWEKMVWpLSjTi6PQU0M5KF/vpuaj9Ato5g/fUWcpOeeFJJHU2Z
	C4EXxsLyvK0SHKswZJMimoHwQNA7n00EkGrAdE9Imo9hzpdckDrNLv5X6sU7lVZ8X/rr
	L8TxwT5jsaKR6qfcNOF6ZRh2fNtMJ8dN6NqDlRmw4Dcqa8E/+kkvcC9IkIXP5QT4SbRJ
	glLw==
Received: by 10.14.172.129 with SMTP id t1mr77735eel.34.1347979826701;
	Tue, 18 Sep 2012 07:50:26 -0700 (PDT)
Received: from linaro.org (fw-lnat.cambridge.arm.com. [217.140.96.63])
	by mx.google.com with ESMTPS id y1sm36945944eel.0.2012.09.18.07.50.24
	(version=SSLv3 cipher=OTHER); Tue, 18 Sep 2012 07:50:25 -0700 (PDT)
Date: Tue, 18 Sep 2012 15:50:18 +0100
From: Dave Martin <dave.martin@linaro.org>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20120918145012.GA2110@linaro.org>
References: <alpine.DEB.2.02.1209141145150.29232@kaball.uk.xensource.com>
	<1347621207-11294-6-git-send-email-stefano.stabellini@eu.citrix.com>
	<20120914130151.GH25249@phenom.dumpdata.com>
	<alpine.DEB.2.02.1209141514590.29232@kaball.uk.xensource.com>
	<50572692.1090805@gmail.com>
	<alpine.DEB.2.02.1209171508470.29232@kaball.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <alpine.DEB.2.02.1209171508470.29232@kaball.uk.xensource.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Gm-Message-State: ALoCoQlJh2U8XklfQnOvZ32GDxkPM3o7YIbnNF/v9GWFECG3jiYI1slcA63DriY70Zcx5A1ZSTme
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linux@arm.linux.org.uk" <linux@arm.linux.org.uk>,
	Ian Campbell <Ian.Campbell@citrix.com>, "arnd@arndb.de" <arnd@arndb.de>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"catalin.marinas@arm.com" <catalin.marinas@arm.com>,
	"devicetree-discuss@lists.ozlabs.org"
	<devicetree-discuss@lists.ozlabs.org>, "Tim \(Xen.org\)" <tim@xen.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Rob Herring <robherring2@gmail.com>,
	David Vrabel <david.vrabel@citrix.com>,
	"linaro-dev@lists.linaro.org" <linaro-dev@lists.linaro.org>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Xen-devel] [PATCH v4 06/24] docs: Xen ARM DT bindings
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Sep 17, 2012 at 03:12:11PM +0100, Stefano Stabellini wrote:
> On Mon, 17 Sep 2012, Rob Herring wrote:
> > On 09/14/2012 09:26 AM, Stefano Stabellini wrote:
> > > On Fri, 14 Sep 2012, Konrad Rzeszutek Wilk wrote:
> > >> On Fri, Sep 14, 2012 at 12:13:08PM +0100, Stefano Stabellini wrote:
> > >>> Add a doc to describe the Xen ARM device tree bindings
> > >>>
> > >>>
> > >>> Changes in v4:
> > >>>
> > >>> - "xen,xen" should be last as it is less specific;
> > >>> - update reg property using 2 address-cells and 2 size-cells.
> > >>>
> > >>>
> > >>> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> > >>> CC: devicetree-discuss@lists.ozlabs.org
> > >>> CC: David Vrabel <david.vrabel@citrix.com>
> > >>> CC: Rob Herring <robherring2@gmail.com>
> > >>> CC: Dave Martin <dave.martin@linaro.org>
> > >>> ---
> > >>>  Documentation/devicetree/bindings/arm/xen.txt |   22 ++++++++++++++++++++++
> > >>>  1 files changed, 22 insertions(+), 0 deletions(-)
> > >>>  create mode 100644 Documentation/devicetree/bindings/arm/xen.txt
> > >>>
> > >>> diff --git a/Documentation/devicetree/bindings/arm/xen.txt b/Documentation/devicetree/bindings/arm/xen.txt
> > >>> new file mode 100644
> > >>> index 0000000..1f8f7d4
> > >>> --- /dev/null
> > >>> +++ b/Documentation/devicetree/bindings/arm/xen.txt
> > >>> @@ -0,0 +1,22 @@
> > >>> +* Xen hypervisor device tree bindings
> > >>> +
> > >>> +Xen ARM virtual platforms shall have the following properties:
> > >>> +
> > 
> > State that they are part of top-level "hypervisor" node.
> 
> OK
> 
> 
> > >>> +- compatible:
> > >>> +	compatible = "xen,xen-<version>", "xen,xen";
> > >>> +  where <version> is the version of the Xen ABI of the platform.
> > >>> +
> > >>> +- reg: specifies the base physical address and size of a region in
> > >>> +  memory where the grant table should be mapped to, using an
> > >>> +  HYPERVISOR_memory_op hypercall. 
> > >>> +
> > >>> +- interrupts: the interrupt used by Xen to inject event notifications.
> > >>
> > >> Its singular here.. but in the example its plurar. What if you use
> > >> multiple of the same number ("16 0xf")?
> > > 
> > > The "interrupts" property in the example below is a standard property to
> > > describe interrupts. We just happen to declare only one interrupt.
> > > 
> > > From the device tree point of view it would be possible to declare more
> > > than one interrupt here, but Xen only supports one really.
> > > 
> > > Regarding the three cells used in the example (<1 15 0xf08>), they have
> > > a specific meaning in the GIC context:
> > > 
> > > """
> > >   The 1st cell is the interrupt type; 0 for SPI interrupts, 1 for PPI
> > >   interrupts.
> > > 
> > >   The 2nd cell contains the interrupt number for the interrupt type.
> > >   SPI interrupts are in the range [0-987].  PPI interrupts are in the
> > >   range [0-15].
> > > 
> > >   The 3rd cell is the flags, encoded as follows:
> > > 	bits[3:0] trigger type and level flags.
> > > 		1 = low-to-high edge triggered
> > > 		2 = high-to-low edge triggered
> > > 		4 = active high level-sensitive
> > > 		8 = active low level-sensitive
> > > 	bits[15:8] PPI interrupt cpu mask.  Each bit corresponds to each of
> > > 	the 8 possible cpus attached to the GIC.  A bit set to '1' indicated
> > > 	the interrupt is wired to that CPU.  Only valid for PPI interrupts.
> > > """
> > > 
> > > So <1 15 0xf08> means the last PPI.
> > 
> > Since it is a PPI, it is handled differently than a normal interrupt.
> > That is fine, but you should somehow state that a GIC node is also required.
> 
> Yes, good idea
> 
> 
> > >>> +
> > >>> +
> > >>> +Example:
> > >>> +
> > >>> +hypervisor {
> > >>> +	compatible = "xen,xen-4.3", "xen,xen";
> > >>> +	reg = <0 0xb0000000 0 0x20000>;
> > >>
> > >> So two grant tables?
> > >>
> > >> Hm, physical address is zero, and the size is 0xbignumber?
> > >> Or is the '0' denotating a seperator of arguments, so it is
> > >> 0xb000.. for physical address and 0x20000 for size?
> > > 
> > > from http://devicetree.org/Device_Tree_Usage:
> > > 
> > > "Each addressable device gets a reg which is a list of tuples in the
> > > form reg = <address1 length1 [address2 length2] [address3 length3] ...
> > > Each tuple represents an address range used by the device. Each address
> > > value is a list of one or more 32 bit integers called cells. Similarly,
> > > the length value can either be a list of cells, or empty."
> > > 
> > > In this case the address is: [0 0xb0000000], that means
> > > 0x00000000b0000000, and the length is [0 0x20000], that means
> > > 0x0000000000020000.
> > 
> > But the size depends on #size-cells and #address-cells. I would expect
> > those to be 1 for a 32-bit guest.
>  
> I was looking at the Versatile Express DTS (vexpress-v2p-ca15-tc1.dts)
> that on Linux v3.6-rc5 has:
> 
> #address-cells = <2>;
> #size-cells = <2>;

Some core tiles on vexpress use physical addresses beyond 4G.  But many
32-bit platforms (including some supporting the virtualization extensions)
may not.  There's no reason for such platforms to set these properties to
<2>.

> What should I use for the example in this doc?

Looking at other files in Documentation/device-tree/bindings/, it looks
like the common  example configuration is for #address-cells and
#size-cells to be 1.

So, assuming that those are 1 is probably best for examples.

You could state this explicitly for good measure, but the need to
expand reg properties (and other related properties) to match the parent
bus #address-cells and #size-cells is a standard device-tree concept, so
I think it doesn't make sense to describe the implications in detail on
a per-binding basis.

Cheers
---Dave

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 18 14:50:45 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Sep 2012 14:50:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDz8A-0001Km-Qk; Tue, 18 Sep 2012 14:50:30 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dave.martin@linaro.org>) id 1TDz88-0001KP-MZ
	for xen-devel@lists.xensource.com; Tue, 18 Sep 2012 14:50:28 +0000
Received: from [85.158.139.83:7336] by server-9.bemta-5.messagelabs.com id
	E7/08-20529-33A88505; Tue, 18 Sep 2012 14:50:27 +0000
X-Env-Sender: dave.martin@linaro.org
X-Msg-Ref: server-9.tower-182.messagelabs.com!1347979827!30395214!1
X-Originating-IP: [74.125.83.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2505 invoked from network); 18 Sep 2012 14:50:27 -0000
Received: from mail-ee0-f43.google.com (HELO mail-ee0-f43.google.com)
	(74.125.83.43)
	by server-9.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Sep 2012 14:50:27 -0000
Received: by eekd4 with SMTP id d4so4099172eek.30
	for <xen-devel@lists.xensource.com>;
	Tue, 18 Sep 2012 07:50:26 -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=+cYAl8PsLQfKfGTFxb298PTfCDDlOjrSjVhqwPquOHE=;
	b=b3F1BwDQneVAWKv3BcrlsDuTNUrgvwysPdvfFCWjp5v7YQAn1XfPAZjPCLFlgZQkze
	nShmZ8te1vaX3n5Ki4hRaJMuT+qz8jC+aI9L70ymqULWl6LRajjf6tHrvXII+OKw1qRS
	W2J+EkPvWlV8Ka7TmGFWEKMVWpLSjTi6PQU0M5KF/vpuaj9Ato5g/fUWcpOeeFJJHU2Z
	C4EXxsLyvK0SHKswZJMimoHwQNA7n00EkGrAdE9Imo9hzpdckDrNLv5X6sU7lVZ8X/rr
	L8TxwT5jsaKR6qfcNOF6ZRh2fNtMJ8dN6NqDlRmw4Dcqa8E/+kkvcC9IkIXP5QT4SbRJ
	glLw==
Received: by 10.14.172.129 with SMTP id t1mr77735eel.34.1347979826701;
	Tue, 18 Sep 2012 07:50:26 -0700 (PDT)
Received: from linaro.org (fw-lnat.cambridge.arm.com. [217.140.96.63])
	by mx.google.com with ESMTPS id y1sm36945944eel.0.2012.09.18.07.50.24
	(version=SSLv3 cipher=OTHER); Tue, 18 Sep 2012 07:50:25 -0700 (PDT)
Date: Tue, 18 Sep 2012 15:50:18 +0100
From: Dave Martin <dave.martin@linaro.org>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20120918145012.GA2110@linaro.org>
References: <alpine.DEB.2.02.1209141145150.29232@kaball.uk.xensource.com>
	<1347621207-11294-6-git-send-email-stefano.stabellini@eu.citrix.com>
	<20120914130151.GH25249@phenom.dumpdata.com>
	<alpine.DEB.2.02.1209141514590.29232@kaball.uk.xensource.com>
	<50572692.1090805@gmail.com>
	<alpine.DEB.2.02.1209171508470.29232@kaball.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <alpine.DEB.2.02.1209171508470.29232@kaball.uk.xensource.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Gm-Message-State: ALoCoQlJh2U8XklfQnOvZ32GDxkPM3o7YIbnNF/v9GWFECG3jiYI1slcA63DriY70Zcx5A1ZSTme
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linux@arm.linux.org.uk" <linux@arm.linux.org.uk>,
	Ian Campbell <Ian.Campbell@citrix.com>, "arnd@arndb.de" <arnd@arndb.de>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"catalin.marinas@arm.com" <catalin.marinas@arm.com>,
	"devicetree-discuss@lists.ozlabs.org"
	<devicetree-discuss@lists.ozlabs.org>, "Tim \(Xen.org\)" <tim@xen.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Rob Herring <robherring2@gmail.com>,
	David Vrabel <david.vrabel@citrix.com>,
	"linaro-dev@lists.linaro.org" <linaro-dev@lists.linaro.org>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Xen-devel] [PATCH v4 06/24] docs: Xen ARM DT bindings
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Sep 17, 2012 at 03:12:11PM +0100, Stefano Stabellini wrote:
> On Mon, 17 Sep 2012, Rob Herring wrote:
> > On 09/14/2012 09:26 AM, Stefano Stabellini wrote:
> > > On Fri, 14 Sep 2012, Konrad Rzeszutek Wilk wrote:
> > >> On Fri, Sep 14, 2012 at 12:13:08PM +0100, Stefano Stabellini wrote:
> > >>> Add a doc to describe the Xen ARM device tree bindings
> > >>>
> > >>>
> > >>> Changes in v4:
> > >>>
> > >>> - "xen,xen" should be last as it is less specific;
> > >>> - update reg property using 2 address-cells and 2 size-cells.
> > >>>
> > >>>
> > >>> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> > >>> CC: devicetree-discuss@lists.ozlabs.org
> > >>> CC: David Vrabel <david.vrabel@citrix.com>
> > >>> CC: Rob Herring <robherring2@gmail.com>
> > >>> CC: Dave Martin <dave.martin@linaro.org>
> > >>> ---
> > >>>  Documentation/devicetree/bindings/arm/xen.txt |   22 ++++++++++++++++++++++
> > >>>  1 files changed, 22 insertions(+), 0 deletions(-)
> > >>>  create mode 100644 Documentation/devicetree/bindings/arm/xen.txt
> > >>>
> > >>> diff --git a/Documentation/devicetree/bindings/arm/xen.txt b/Documentation/devicetree/bindings/arm/xen.txt
> > >>> new file mode 100644
> > >>> index 0000000..1f8f7d4
> > >>> --- /dev/null
> > >>> +++ b/Documentation/devicetree/bindings/arm/xen.txt
> > >>> @@ -0,0 +1,22 @@
> > >>> +* Xen hypervisor device tree bindings
> > >>> +
> > >>> +Xen ARM virtual platforms shall have the following properties:
> > >>> +
> > 
> > State that they are part of top-level "hypervisor" node.
> 
> OK
> 
> 
> > >>> +- compatible:
> > >>> +	compatible = "xen,xen-<version>", "xen,xen";
> > >>> +  where <version> is the version of the Xen ABI of the platform.
> > >>> +
> > >>> +- reg: specifies the base physical address and size of a region in
> > >>> +  memory where the grant table should be mapped to, using an
> > >>> +  HYPERVISOR_memory_op hypercall. 
> > >>> +
> > >>> +- interrupts: the interrupt used by Xen to inject event notifications.
> > >>
> > >> Its singular here.. but in the example its plurar. What if you use
> > >> multiple of the same number ("16 0xf")?
> > > 
> > > The "interrupts" property in the example below is a standard property to
> > > describe interrupts. We just happen to declare only one interrupt.
> > > 
> > > From the device tree point of view it would be possible to declare more
> > > than one interrupt here, but Xen only supports one really.
> > > 
> > > Regarding the three cells used in the example (<1 15 0xf08>), they have
> > > a specific meaning in the GIC context:
> > > 
> > > """
> > >   The 1st cell is the interrupt type; 0 for SPI interrupts, 1 for PPI
> > >   interrupts.
> > > 
> > >   The 2nd cell contains the interrupt number for the interrupt type.
> > >   SPI interrupts are in the range [0-987].  PPI interrupts are in the
> > >   range [0-15].
> > > 
> > >   The 3rd cell is the flags, encoded as follows:
> > > 	bits[3:0] trigger type and level flags.
> > > 		1 = low-to-high edge triggered
> > > 		2 = high-to-low edge triggered
> > > 		4 = active high level-sensitive
> > > 		8 = active low level-sensitive
> > > 	bits[15:8] PPI interrupt cpu mask.  Each bit corresponds to each of
> > > 	the 8 possible cpus attached to the GIC.  A bit set to '1' indicated
> > > 	the interrupt is wired to that CPU.  Only valid for PPI interrupts.
> > > """
> > > 
> > > So <1 15 0xf08> means the last PPI.
> > 
> > Since it is a PPI, it is handled differently than a normal interrupt.
> > That is fine, but you should somehow state that a GIC node is also required.
> 
> Yes, good idea
> 
> 
> > >>> +
> > >>> +
> > >>> +Example:
> > >>> +
> > >>> +hypervisor {
> > >>> +	compatible = "xen,xen-4.3", "xen,xen";
> > >>> +	reg = <0 0xb0000000 0 0x20000>;
> > >>
> > >> So two grant tables?
> > >>
> > >> Hm, physical address is zero, and the size is 0xbignumber?
> > >> Or is the '0' denotating a seperator of arguments, so it is
> > >> 0xb000.. for physical address and 0x20000 for size?
> > > 
> > > from http://devicetree.org/Device_Tree_Usage:
> > > 
> > > "Each addressable device gets a reg which is a list of tuples in the
> > > form reg = <address1 length1 [address2 length2] [address3 length3] ...
> > > Each tuple represents an address range used by the device. Each address
> > > value is a list of one or more 32 bit integers called cells. Similarly,
> > > the length value can either be a list of cells, or empty."
> > > 
> > > In this case the address is: [0 0xb0000000], that means
> > > 0x00000000b0000000, and the length is [0 0x20000], that means
> > > 0x0000000000020000.
> > 
> > But the size depends on #size-cells and #address-cells. I would expect
> > those to be 1 for a 32-bit guest.
>  
> I was looking at the Versatile Express DTS (vexpress-v2p-ca15-tc1.dts)
> that on Linux v3.6-rc5 has:
> 
> #address-cells = <2>;
> #size-cells = <2>;

Some core tiles on vexpress use physical addresses beyond 4G.  But many
32-bit platforms (including some supporting the virtualization extensions)
may not.  There's no reason for such platforms to set these properties to
<2>.

> What should I use for the example in this doc?

Looking at other files in Documentation/device-tree/bindings/, it looks
like the common  example configuration is for #address-cells and
#size-cells to be 1.

So, assuming that those are 1 is probably best for examples.

You could state this explicitly for good measure, but the need to
expand reg properties (and other related properties) to match the parent
bus #address-cells and #size-cells is a standard device-tree concept, so
I think it doesn't make sense to describe the implications in detail on
a per-binding basis.

Cheers
---Dave

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 18 14:50:53 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Sep 2012 14:50:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDz8O-0001NY-DX; Tue, 18 Sep 2012 14:50:44 +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 1TDz8N-0001NF-Cm
	for xen-devel@lists.xen.org; Tue, 18 Sep 2012 14:50:43 +0000
Received: from [85.158.139.83:10513] by server-7.bemta-5.messagelabs.com id
	ED/27-19703-24A88505; Tue, 18 Sep 2012 14:50:42 +0000
X-Env-Sender: Andre.Przywara@amd.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1347979838!30522895!1
X-Originating-IP: [213.199.154.141]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17314 invoked from network); 18 Sep 2012 14:50:41 -0000
Received: from db3ehsobe003.messaging.microsoft.com (HELO
	db3outboundpool.messaging.microsoft.com) (213.199.154.141)
	by server-13.tower-182.messagelabs.com with AES128-SHA encrypted SMTP;
	18 Sep 2012 14:50:41 -0000
Received: from mail48-db3-R.bigfish.com (10.3.81.230) by
	DB3EHSOBE007.bigfish.com (10.3.84.27) with Microsoft SMTP Server id
	14.1.225.23; Tue, 18 Sep 2012 14:50:38 +0000
Received: from mail48-db3 (localhost [127.0.0.1])	by mail48-db3-R.bigfish.com
	(Postfix) with ESMTP id 54CBC140177;
	Tue, 18 Sep 2012 14:50:38 +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: -2
X-BigFish: VPS-2(z551bizbb2dI98dI9371I1432Id6f1izz1202h1d1ah1d2ahzzz2dh668h839hd25he5bhf0ah107ah1288h12a5h12a9h12bdh1155h)
Received: from mail48-db3 (localhost.localdomain [127.0.0.1]) by mail48-db3
	(MessageSwitch) id 1347979819846092_31422;
	Tue, 18 Sep 2012 14:50:19 +0000 (UTC)
Received: from DB3EHSMHS018.bigfish.com (unknown [10.3.81.227])	by
	mail48-db3.bigfish.com (Postfix) with ESMTP id C88912A031A;
	Tue, 18 Sep 2012 14:50:19 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	DB3EHSMHS018.bigfish.com (10.3.87.118) with Microsoft SMTP Server id
	14.1.225.23; Tue, 18 Sep 2012 14:50:16 +0000
X-WSS-ID: 0MAJVVQ-01-DKV-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 2F9511028119;	Tue, 18 Sep 2012 09:50:13 -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;
	Tue, 18 Sep 2012 09:50: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;
	Tue, 18 Sep 2012 09:50:12 -0500
Received: from [165.204.16.96] (165.204.16.96) by storexhtp02.amd.com
	(172.24.4.4) with Microsoft SMTP Server id 8.3.213.0; Tue, 18 Sep 2012
	10:50:11 -0400
Message-ID: <5058A646.5060909@amd.com>
Date: Tue, 18 Sep 2012 18:50:14 +0200
From: Andre Przywara <andre.przywara@amd.com>
Organization: AMD
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:13.0) Gecko/20120615 Thunderbird/13.0.1
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
References: <501BC20F.3040205@amd.com>
	<20120803123628.GB10670@andromeda.dapyr.net>
	<20120817142237.GA8467@phenom.dumpdata.com>
	<20120914185822.GA7495@phenom.dumpdata.com>
	<5056D152.2090708@amd.com>
	<20120917191432.GA18552@phenom.dumpdata.com>
	<5058458D.7030603@amd.com>
	<20120918134457.GE12053@phenom.dumpdata.com>
In-Reply-To: <20120918134457.GE12053@phenom.dumpdata.com>
X-OriginatorOrg: amd.com
Cc: Konrad Rzeszutek Wilk <konrad@kernel.org>,
	Jeremy Fitzhardinge <jeremy@goop.org>, xen-devel <xen-devel@lists.xen.org>,
	Dario Faggioli <raistlin@linux.it>,
	Konrad Rzeszutek Wilk <konrad@darnok.org>
Subject: Re: [Xen-devel] Dom0 crash with old style AMD NUMA detection
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 09/18/2012 03:44 PM, Konrad Rzeszutek Wilk wrote:
> On Tue, Sep 18, 2012 at 11:57:33AM +0200, Andre Przywara wrote:
>> On 09/17/2012 09:14 PM, Konrad Rzeszutek Wilk wrote:
>>> On Mon, Sep 17, 2012 at 09:29:22AM +0200, Andre Przywara wrote:
>>>> On 09/14/2012 08:58 PM, Konrad Rzeszutek Wilk wrote:
>>>>>>>> [    0.000000] Kernel panic - not syncing: Attempted to kill the idle task!
>>>>>>>> (XEN) Domain 0 crashed: 'noreboot' set - not rebooting.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> The obvious solution would be to explicitly deny northbridge scanning
>>>>>>>> when running as Dom0, though I am not sure how to implement this without
>>>>>>>> upsetting the other kernel folks about "that crappy Xen thing" again ;-)
>>>>>>>
>>>>>>> Heh.
>>>>>>> Is there a numa=0 option that could be used to override it to turn it
>>>>>>> off?
>>>>>>
>>>>>> Not compile tested.. but was thinking something like this:
>>>>>
>>>>> ping?
>>>>
>>>> That looks good to me - at least for the time being.
>>>
>>> OK, can I've your Tested-by/Acked-by on it pls?
>>>
>>>> I just want to check how this interacts with upcoming Dom0 NUMA
>>>> support. It wouldn't be too clever if we deliberately disable NUMA
>>>
>>> We can always revert this patch in future versions of Linux.
>>
>> I don't like this idea. Then we have Linux kernel up to 3.5 working
>> and say from 3.8 on again, but 3.6 and 3.7 cannot use NUMA. That
>> would be pretty unfortunate.
>
> Huh? v3.5 working? But it never worked? I would say turn off the NUMA
> detection (keep in mind it still will set up the dummy NUMA stuff)
> until there are some PV NUMA capability and then we can revert it.

I was under the impression that somehow the Dom0 NUMA would be made 
compatible, using some of the existing discovery mechanisms. So we would 
enable the hypervisor, and Dom0 would just magically start working. I am 
probably rooted too much in the HVM world ;-)

>>
>> I haven't checked back with Dario, but I'd suspect that we use ACPI
>> for injecting NUMA topology into Dom0. Even if not, a general
>> "numa=off" for Dom0 is too much of a sledgehammer for me.
>
> How would you inject it in Dom0? It s a PV guest so the hypervisor would
> have to tweak the SRAT/SLIT tables. That is not going to happen
> in the very short term.. And I don't recall seeing any patches, so
> the dom0 NUMA support is right now non-existent?

Right, I just don't wanted to slam the door deliberately. Thinking more 
about this, we probably need some kind of PV enablement in Dom0, even if 
we could somehow use the ACPI tables (and thus the ACPI parsing code).
If this is the case, we could at the same time remove this "force numa 
off" patch.

I am almost convinced by now.
Just waiting for Dario's opinion for a few more hours and will send my 
final opinion later today. If you cannot wait, tell me.


Andre.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 18 14:50:53 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Sep 2012 14:50:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDz8O-0001NY-DX; Tue, 18 Sep 2012 14:50:44 +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 1TDz8N-0001NF-Cm
	for xen-devel@lists.xen.org; Tue, 18 Sep 2012 14:50:43 +0000
Received: from [85.158.139.83:10513] by server-7.bemta-5.messagelabs.com id
	ED/27-19703-24A88505; Tue, 18 Sep 2012 14:50:42 +0000
X-Env-Sender: Andre.Przywara@amd.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1347979838!30522895!1
X-Originating-IP: [213.199.154.141]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17314 invoked from network); 18 Sep 2012 14:50:41 -0000
Received: from db3ehsobe003.messaging.microsoft.com (HELO
	db3outboundpool.messaging.microsoft.com) (213.199.154.141)
	by server-13.tower-182.messagelabs.com with AES128-SHA encrypted SMTP;
	18 Sep 2012 14:50:41 -0000
Received: from mail48-db3-R.bigfish.com (10.3.81.230) by
	DB3EHSOBE007.bigfish.com (10.3.84.27) with Microsoft SMTP Server id
	14.1.225.23; Tue, 18 Sep 2012 14:50:38 +0000
Received: from mail48-db3 (localhost [127.0.0.1])	by mail48-db3-R.bigfish.com
	(Postfix) with ESMTP id 54CBC140177;
	Tue, 18 Sep 2012 14:50:38 +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: -2
X-BigFish: VPS-2(z551bizbb2dI98dI9371I1432Id6f1izz1202h1d1ah1d2ahzzz2dh668h839hd25he5bhf0ah107ah1288h12a5h12a9h12bdh1155h)
Received: from mail48-db3 (localhost.localdomain [127.0.0.1]) by mail48-db3
	(MessageSwitch) id 1347979819846092_31422;
	Tue, 18 Sep 2012 14:50:19 +0000 (UTC)
Received: from DB3EHSMHS018.bigfish.com (unknown [10.3.81.227])	by
	mail48-db3.bigfish.com (Postfix) with ESMTP id C88912A031A;
	Tue, 18 Sep 2012 14:50:19 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	DB3EHSMHS018.bigfish.com (10.3.87.118) with Microsoft SMTP Server id
	14.1.225.23; Tue, 18 Sep 2012 14:50:16 +0000
X-WSS-ID: 0MAJVVQ-01-DKV-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 2F9511028119;	Tue, 18 Sep 2012 09:50:13 -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;
	Tue, 18 Sep 2012 09:50: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;
	Tue, 18 Sep 2012 09:50:12 -0500
Received: from [165.204.16.96] (165.204.16.96) by storexhtp02.amd.com
	(172.24.4.4) with Microsoft SMTP Server id 8.3.213.0; Tue, 18 Sep 2012
	10:50:11 -0400
Message-ID: <5058A646.5060909@amd.com>
Date: Tue, 18 Sep 2012 18:50:14 +0200
From: Andre Przywara <andre.przywara@amd.com>
Organization: AMD
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:13.0) Gecko/20120615 Thunderbird/13.0.1
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
References: <501BC20F.3040205@amd.com>
	<20120803123628.GB10670@andromeda.dapyr.net>
	<20120817142237.GA8467@phenom.dumpdata.com>
	<20120914185822.GA7495@phenom.dumpdata.com>
	<5056D152.2090708@amd.com>
	<20120917191432.GA18552@phenom.dumpdata.com>
	<5058458D.7030603@amd.com>
	<20120918134457.GE12053@phenom.dumpdata.com>
In-Reply-To: <20120918134457.GE12053@phenom.dumpdata.com>
X-OriginatorOrg: amd.com
Cc: Konrad Rzeszutek Wilk <konrad@kernel.org>,
	Jeremy Fitzhardinge <jeremy@goop.org>, xen-devel <xen-devel@lists.xen.org>,
	Dario Faggioli <raistlin@linux.it>,
	Konrad Rzeszutek Wilk <konrad@darnok.org>
Subject: Re: [Xen-devel] Dom0 crash with old style AMD NUMA detection
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 09/18/2012 03:44 PM, Konrad Rzeszutek Wilk wrote:
> On Tue, Sep 18, 2012 at 11:57:33AM +0200, Andre Przywara wrote:
>> On 09/17/2012 09:14 PM, Konrad Rzeszutek Wilk wrote:
>>> On Mon, Sep 17, 2012 at 09:29:22AM +0200, Andre Przywara wrote:
>>>> On 09/14/2012 08:58 PM, Konrad Rzeszutek Wilk wrote:
>>>>>>>> [    0.000000] Kernel panic - not syncing: Attempted to kill the idle task!
>>>>>>>> (XEN) Domain 0 crashed: 'noreboot' set - not rebooting.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> The obvious solution would be to explicitly deny northbridge scanning
>>>>>>>> when running as Dom0, though I am not sure how to implement this without
>>>>>>>> upsetting the other kernel folks about "that crappy Xen thing" again ;-)
>>>>>>>
>>>>>>> Heh.
>>>>>>> Is there a numa=0 option that could be used to override it to turn it
>>>>>>> off?
>>>>>>
>>>>>> Not compile tested.. but was thinking something like this:
>>>>>
>>>>> ping?
>>>>
>>>> That looks good to me - at least for the time being.
>>>
>>> OK, can I've your Tested-by/Acked-by on it pls?
>>>
>>>> I just want to check how this interacts with upcoming Dom0 NUMA
>>>> support. It wouldn't be too clever if we deliberately disable NUMA
>>>
>>> We can always revert this patch in future versions of Linux.
>>
>> I don't like this idea. Then we have Linux kernel up to 3.5 working
>> and say from 3.8 on again, but 3.6 and 3.7 cannot use NUMA. That
>> would be pretty unfortunate.
>
> Huh? v3.5 working? But it never worked? I would say turn off the NUMA
> detection (keep in mind it still will set up the dummy NUMA stuff)
> until there are some PV NUMA capability and then we can revert it.

I was under the impression that somehow the Dom0 NUMA would be made 
compatible, using some of the existing discovery mechanisms. So we would 
enable the hypervisor, and Dom0 would just magically start working. I am 
probably rooted too much in the HVM world ;-)

>>
>> I haven't checked back with Dario, but I'd suspect that we use ACPI
>> for injecting NUMA topology into Dom0. Even if not, a general
>> "numa=off" for Dom0 is too much of a sledgehammer for me.
>
> How would you inject it in Dom0? It s a PV guest so the hypervisor would
> have to tweak the SRAT/SLIT tables. That is not going to happen
> in the very short term.. And I don't recall seeing any patches, so
> the dom0 NUMA support is right now non-existent?

Right, I just don't wanted to slam the door deliberately. Thinking more 
about this, we probably need some kind of PV enablement in Dom0, even if 
we could somehow use the ACPI tables (and thus the ACPI parsing code).
If this is the case, we could at the same time remove this "force numa 
off" patch.

I am almost convinced by now.
Just waiting for Dario's opinion for a few more hours and will send my 
final opinion later today. If you cannot wait, tell me.


Andre.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 18 14:53:45 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Sep 2012 14: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 1TDzB7-0001eN-4Q; Tue, 18 Sep 2012 14:53:33 +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 1TDzB5-0001e5-E8
	for xen-devel@lists.xen.org; Tue, 18 Sep 2012 14:53:31 +0000
Received: from [85.158.139.83:8784] by server-4.bemta-5.messagelabs.com id
	20/5F-23042-8EA88505; Tue, 18 Sep 2012 14:53:28 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1347980005!23844074!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzQ3OTcz\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9783 invoked from network); 18 Sep 2012 14:53:27 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-11.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 18 Sep 2012 14:53:27 -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 q8IErMhf032106
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 18 Sep 2012 14:53:23 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
	q8IErMas025720
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 18 Sep 2012 14:53:22 GMT
Received: from abhmt107.oracle.com (abhmt107.oracle.com [141.146.116.59])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q8IErKrq028105; Tue, 18 Sep 2012 09:53:20 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 18 Sep 2012 07:53:19 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id E5CB5402C0; Tue, 18 Sep 2012 10:42:30 -0400 (EDT)
Date: Tue, 18 Sep 2012 10:42:30 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20120918144230.GC19332@phenom.dumpdata.com>
References: <505875B6020000780009C01D@nat28.tlf.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <505875B6020000780009C01D@nat28.tlf.novell.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: gregkh@linuxfoundation.org, linux-usb@vger.kernel.org,
	stern@rowland.harvard.edu, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] EHCI/Xen: propagate controller reset
 information to hypervisor
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Sep 18, 2012 at 12:23:02PM +0100, Jan Beulich wrote:
> Just like for the in-tree early console debug port driver, the
> hypervisor - when using a debug port based console - also needs to be
> told about controller resets, so it can suppress using and then
> re-initialize the debug port accordingly.
> 
> Other than the in-tree driver, the hypervisor driver actually cares
> about doing this only for the device where the debug is port actually
> in use, i.e. it needs to be told the coordinates of the device being
> reset (quite obviously, leveraging the addition done for that would
> likely benefit the in-tree driver too).
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

on the *xen* parts.

> 
> ---
>  drivers/usb/early/ehci-dbgp.c   |   17 ++++++++++----
>  drivers/usb/host/ehci-hcd.c     |    4 +--
>  drivers/usb/host/ehci-hub.c     |    4 +--
>  drivers/xen/Makefile            |    2 -
>  drivers/xen/dbgp.c              |   48 ++++++++++++++++++++++++++++++++++++++++
>  include/linux/usb/ehci_def.h    |   29 +++++++++++++++++++-----
>  include/xen/interface/physdev.h |   16 +++++++++++++
>  7 files changed, 105 insertions(+), 15 deletions(-)
> 
> --- 3.6-rc6/drivers/usb/early/ehci-dbgp.c
> +++ 3.6-rc6-xen-ehci-dbgp/drivers/usb/early/ehci-dbgp.c
> @@ -491,7 +491,7 @@ static int ehci_wait_for_port(int port);
>   * Return -ENODEV for any general failure
>   * Return -EIO if wait for port fails
>   */
> -int dbgp_external_startup(void)
> +static int _dbgp_external_startup(void)
>  {
>  	int devnum;
>  	struct usb_debug_descriptor dbgp_desc;
> @@ -613,6 +613,11 @@ err:
>  		goto try_again;
>  	return -ENODEV;
>  }
> +
> +int dbgp_external_startup(struct usb_hcd *hcd)
> +{
> +	return xen_dbgp_external_startup(hcd) ?: _dbgp_external_startup();
> +}
>  EXPORT_SYMBOL_GPL(dbgp_external_startup);
>  
>  static int ehci_reset_port(int port)
> @@ -804,7 +809,7 @@ try_next_port:
>  		dbgp_ehci_status("ehci skip - already configured");
>  	}
>  
> -	ret = dbgp_external_startup();
> +	ret = _dbgp_external_startup();
>  	if (ret == -EIO)
>  		goto next_debug_port;
>  
> @@ -934,7 +939,7 @@ static void early_dbgp_write(struct cons
>  		ctrl = readl(&ehci_debug->control);
>  		if (!(ctrl & DBGP_ENABLED)) {
>  			dbgp_not_safe = 1;
> -			dbgp_external_startup();
> +			_dbgp_external_startup();
>  		} else {
>  			cmd |= CMD_RUN;
>  			writel(cmd, &ehci_regs->command);
> @@ -974,10 +979,14 @@ struct console early_dbgp_console = {
>  	.index =	-1,
>  };
>  
> -int dbgp_reset_prep(void)
> +int dbgp_reset_prep(struct usb_hcd *hcd)
>  {
> +	int ret = xen_dbgp_reset_prep(hcd);
>  	u32 ctrl;
>  
> +	if (ret)
> +		return ret;
> +
>  	dbgp_not_safe = 1;
>  	if (!ehci_debug)
>  		return 0;
> --- 3.6-rc6/drivers/usb/host/ehci-hcd.c
> +++ 3.6-rc6-xen-ehci-dbgp/drivers/usb/host/ehci-hcd.c
> @@ -228,7 +228,7 @@ static int ehci_reset (struct ehci_hcd *
>  
>  	/* If the EHCI debug controller is active, special care must be
>  	 * taken before and after a host controller reset */
> -	if (ehci->debug && !dbgp_reset_prep())
> +	if (ehci->debug && !dbgp_reset_prep(ehci_to_hcd(ehci)))
>  		ehci->debug = NULL;
>  
>  	command |= CMD_RESET;
> @@ -251,7 +251,7 @@ static int ehci_reset (struct ehci_hcd *
>  		tdi_reset (ehci);
>  
>  	if (ehci->debug)
> -		dbgp_external_startup();
> +		dbgp_external_startup(ehci_to_hcd(ehci));
>  
>  	ehci->port_c_suspend = ehci->suspended_ports =
>  			ehci->resuming_ports = 0;
> --- 3.6-rc6/drivers/usb/host/ehci-hub.c
> +++ 3.6-rc6-xen-ehci-dbgp/drivers/usb/host/ehci-hub.c
> @@ -353,10 +353,10 @@ static int ehci_bus_resume (struct usb_h
>  		goto shutdown;
>  
>  	if (unlikely(ehci->debug)) {
> -		if (!dbgp_reset_prep())
> +		if (!dbgp_reset_prep(hcd))
>  			ehci->debug = NULL;
>  		else
> -			dbgp_external_startup();
> +			dbgp_external_startup(hcd);
>  	}
>  
>  	/* Ideally and we've got a real resume here, and no port's power
> --- 3.6-rc6/drivers/xen/Makefile
> +++ 3.6-rc6-xen-ehci-dbgp/drivers/xen/Makefile
> @@ -18,7 +18,7 @@ obj-$(CONFIG_XEN_PVHVM)			+= platform-pc
>  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_DOM0)			+= pci.o dbgp.o acpi.o
>  obj-$(CONFIG_XEN_MCE_LOG)		+= mcelog.o
>  obj-$(CONFIG_XEN_PCIDEV_BACKEND)	+= xen-pciback/
>  obj-$(CONFIG_XEN_PRIVCMD)		+= xen-privcmd.o
> --- /home/jbeulich/tmp/linux-3.6-rc6/drivers/xen/dbgp.c	1970-01-01 01:00:00.000000000 +0100
> +++ 3.6-rc6-xen-ehci-dbgp/drivers/xen/dbgp.c
> @@ -0,0 +1,48 @@
> +#include <linux/pci.h>
> +#include <linux/usb.h>
> +#include <linux/usb/ehci_def.h>
> +#include <linux/usb/hcd.h>
> +#include <asm/xen/hypercall.h>
> +#include <xen/interface/physdev.h>
> +#include <xen/xen.h>
> +
> +static int xen_dbgp_op(struct usb_hcd *hcd, int op)
> +{
> +	const struct device *ctrlr = hcd_to_bus(hcd)->controller;
> +	struct physdev_dbgp_op dbgp;
> +
> +	if (!xen_initial_domain())
> +		return 0;
> +
> +	dbgp.op = op;
> +
> +#ifdef CONFIG_PCI
> +	if (ctrlr->bus == &pci_bus_type) {
> +		const struct pci_dev *pdev = to_pci_dev(ctrlr);
> +
> +		dbgp.u.pci.seg = pci_domain_nr(pdev->bus);
> +		dbgp.u.pci.bus = pdev->bus->number;
> +		dbgp.u.pci.devfn = pdev->devfn;
> +		dbgp.bus = PHYSDEVOP_DBGP_BUS_PCI;
> +	} else
> +#endif
> +		dbgp.bus = PHYSDEVOP_DBGP_BUS_UNKNOWN;
> +
> +	return HYPERVISOR_physdev_op(PHYSDEVOP_dbgp_op, &dbgp);
> +}
> +
> +int xen_dbgp_reset_prep(struct usb_hcd *hcd)
> +{
> +	return xen_dbgp_op(hcd, PHYSDEVOP_DBGP_RESET_PREPARE);
> +}
> +
> +int xen_dbgp_external_startup(struct usb_hcd *hcd)
> +{
> +	return xen_dbgp_op(hcd, PHYSDEVOP_DBGP_RESET_DONE);
> +}
> +
> +#ifndef CONFIG_EARLY_PRINTK_DBGP
> +#include <linux/export.h>
> +EXPORT_SYMBOL_GPL(xen_dbgp_reset_prep);
> +EXPORT_SYMBOL_GPL(xen_dbgp_external_startup);
> +#endif
> --- 3.6-rc6/include/linux/usb/ehci_def.h
> +++ 3.6-rc6-xen-ehci-dbgp/include/linux/usb/ehci_def.h
> @@ -221,18 +221,35 @@ extern int __init early_dbgp_init(char *
>  extern struct console early_dbgp_console;
>  #endif /* CONFIG_EARLY_PRINTK_DBGP */
>  
> +struct usb_hcd;
> +
> +#ifdef CONFIG_XEN_DOM0
> +extern int xen_dbgp_reset_prep(struct usb_hcd *);
> +extern int xen_dbgp_external_startup(struct usb_hcd *);
> +#else
> +static inline int xen_dbgp_reset_prep(struct usb_hcd *hcd)
> +{
> +	return 1; /* Shouldn't this be 0? */
> +}
> +
> +static inline int xen_dbgp_external_startup(struct usb_hcd *hcd)
> +{
> +	return -1;
> +}
> +#endif
> +
>  #ifdef CONFIG_EARLY_PRINTK_DBGP
>  /* Call backs from ehci host driver to ehci debug driver */
> -extern int dbgp_external_startup(void);
> -extern int dbgp_reset_prep(void);
> +extern int dbgp_external_startup(struct usb_hcd *);
> +extern int dbgp_reset_prep(struct usb_hcd *hcd);
>  #else
> -static inline int dbgp_reset_prep(void)
> +static inline int dbgp_reset_prep(struct usb_hcd *hcd)
>  {
> -	return 1;
> +	return xen_dbgp_reset_prep(hcd);
>  }
> -static inline int dbgp_external_startup(void)
> +static inline int dbgp_external_startup(struct usb_hcd *hcd)
>  {
> -	return -1;
> +	return xen_dbgp_external_startup(hcd);
>  }
>  #endif
>  
> --- 3.6-rc6/include/xen/interface/physdev.h
> +++ 3.6-rc6-xen-ehci-dbgp/include/xen/interface/physdev.h
> @@ -258,6 +258,22 @@ struct physdev_pci_device {
>      uint8_t devfn;
>  };
>  
> +#define PHYSDEVOP_DBGP_RESET_PREPARE    1
> +#define PHYSDEVOP_DBGP_RESET_DONE       2
> +
> +#define PHYSDEVOP_DBGP_BUS_UNKNOWN      0
> +#define PHYSDEVOP_DBGP_BUS_PCI          1
> +
> +#define PHYSDEVOP_dbgp_op               29
> +struct physdev_dbgp_op {
> +    /* IN */
> +    uint8_t op;
> +    uint8_t bus;
> +    union {
> +        struct physdev_pci_device pci;
> +    } u;
> +};
> +
>  /*
>   * Notify that some PIRQ-bound event channels have been unmasked.
>   * ** This command is obsolete since interface version 0x00030202 and is **
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 18 14:53:45 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Sep 2012 14: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 1TDzB7-0001eN-4Q; Tue, 18 Sep 2012 14:53:33 +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 1TDzB5-0001e5-E8
	for xen-devel@lists.xen.org; Tue, 18 Sep 2012 14:53:31 +0000
Received: from [85.158.139.83:8784] by server-4.bemta-5.messagelabs.com id
	20/5F-23042-8EA88505; Tue, 18 Sep 2012 14:53:28 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1347980005!23844074!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzQ3OTcz\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9783 invoked from network); 18 Sep 2012 14:53:27 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-11.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 18 Sep 2012 14:53:27 -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 q8IErMhf032106
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 18 Sep 2012 14:53:23 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
	q8IErMas025720
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 18 Sep 2012 14:53:22 GMT
Received: from abhmt107.oracle.com (abhmt107.oracle.com [141.146.116.59])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q8IErKrq028105; Tue, 18 Sep 2012 09:53:20 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 18 Sep 2012 07:53:19 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id E5CB5402C0; Tue, 18 Sep 2012 10:42:30 -0400 (EDT)
Date: Tue, 18 Sep 2012 10:42:30 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20120918144230.GC19332@phenom.dumpdata.com>
References: <505875B6020000780009C01D@nat28.tlf.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <505875B6020000780009C01D@nat28.tlf.novell.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: gregkh@linuxfoundation.org, linux-usb@vger.kernel.org,
	stern@rowland.harvard.edu, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] EHCI/Xen: propagate controller reset
 information to hypervisor
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Sep 18, 2012 at 12:23:02PM +0100, Jan Beulich wrote:
> Just like for the in-tree early console debug port driver, the
> hypervisor - when using a debug port based console - also needs to be
> told about controller resets, so it can suppress using and then
> re-initialize the debug port accordingly.
> 
> Other than the in-tree driver, the hypervisor driver actually cares
> about doing this only for the device where the debug is port actually
> in use, i.e. it needs to be told the coordinates of the device being
> reset (quite obviously, leveraging the addition done for that would
> likely benefit the in-tree driver too).
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

on the *xen* parts.

> 
> ---
>  drivers/usb/early/ehci-dbgp.c   |   17 ++++++++++----
>  drivers/usb/host/ehci-hcd.c     |    4 +--
>  drivers/usb/host/ehci-hub.c     |    4 +--
>  drivers/xen/Makefile            |    2 -
>  drivers/xen/dbgp.c              |   48 ++++++++++++++++++++++++++++++++++++++++
>  include/linux/usb/ehci_def.h    |   29 +++++++++++++++++++-----
>  include/xen/interface/physdev.h |   16 +++++++++++++
>  7 files changed, 105 insertions(+), 15 deletions(-)
> 
> --- 3.6-rc6/drivers/usb/early/ehci-dbgp.c
> +++ 3.6-rc6-xen-ehci-dbgp/drivers/usb/early/ehci-dbgp.c
> @@ -491,7 +491,7 @@ static int ehci_wait_for_port(int port);
>   * Return -ENODEV for any general failure
>   * Return -EIO if wait for port fails
>   */
> -int dbgp_external_startup(void)
> +static int _dbgp_external_startup(void)
>  {
>  	int devnum;
>  	struct usb_debug_descriptor dbgp_desc;
> @@ -613,6 +613,11 @@ err:
>  		goto try_again;
>  	return -ENODEV;
>  }
> +
> +int dbgp_external_startup(struct usb_hcd *hcd)
> +{
> +	return xen_dbgp_external_startup(hcd) ?: _dbgp_external_startup();
> +}
>  EXPORT_SYMBOL_GPL(dbgp_external_startup);
>  
>  static int ehci_reset_port(int port)
> @@ -804,7 +809,7 @@ try_next_port:
>  		dbgp_ehci_status("ehci skip - already configured");
>  	}
>  
> -	ret = dbgp_external_startup();
> +	ret = _dbgp_external_startup();
>  	if (ret == -EIO)
>  		goto next_debug_port;
>  
> @@ -934,7 +939,7 @@ static void early_dbgp_write(struct cons
>  		ctrl = readl(&ehci_debug->control);
>  		if (!(ctrl & DBGP_ENABLED)) {
>  			dbgp_not_safe = 1;
> -			dbgp_external_startup();
> +			_dbgp_external_startup();
>  		} else {
>  			cmd |= CMD_RUN;
>  			writel(cmd, &ehci_regs->command);
> @@ -974,10 +979,14 @@ struct console early_dbgp_console = {
>  	.index =	-1,
>  };
>  
> -int dbgp_reset_prep(void)
> +int dbgp_reset_prep(struct usb_hcd *hcd)
>  {
> +	int ret = xen_dbgp_reset_prep(hcd);
>  	u32 ctrl;
>  
> +	if (ret)
> +		return ret;
> +
>  	dbgp_not_safe = 1;
>  	if (!ehci_debug)
>  		return 0;
> --- 3.6-rc6/drivers/usb/host/ehci-hcd.c
> +++ 3.6-rc6-xen-ehci-dbgp/drivers/usb/host/ehci-hcd.c
> @@ -228,7 +228,7 @@ static int ehci_reset (struct ehci_hcd *
>  
>  	/* If the EHCI debug controller is active, special care must be
>  	 * taken before and after a host controller reset */
> -	if (ehci->debug && !dbgp_reset_prep())
> +	if (ehci->debug && !dbgp_reset_prep(ehci_to_hcd(ehci)))
>  		ehci->debug = NULL;
>  
>  	command |= CMD_RESET;
> @@ -251,7 +251,7 @@ static int ehci_reset (struct ehci_hcd *
>  		tdi_reset (ehci);
>  
>  	if (ehci->debug)
> -		dbgp_external_startup();
> +		dbgp_external_startup(ehci_to_hcd(ehci));
>  
>  	ehci->port_c_suspend = ehci->suspended_ports =
>  			ehci->resuming_ports = 0;
> --- 3.6-rc6/drivers/usb/host/ehci-hub.c
> +++ 3.6-rc6-xen-ehci-dbgp/drivers/usb/host/ehci-hub.c
> @@ -353,10 +353,10 @@ static int ehci_bus_resume (struct usb_h
>  		goto shutdown;
>  
>  	if (unlikely(ehci->debug)) {
> -		if (!dbgp_reset_prep())
> +		if (!dbgp_reset_prep(hcd))
>  			ehci->debug = NULL;
>  		else
> -			dbgp_external_startup();
> +			dbgp_external_startup(hcd);
>  	}
>  
>  	/* Ideally and we've got a real resume here, and no port's power
> --- 3.6-rc6/drivers/xen/Makefile
> +++ 3.6-rc6-xen-ehci-dbgp/drivers/xen/Makefile
> @@ -18,7 +18,7 @@ obj-$(CONFIG_XEN_PVHVM)			+= platform-pc
>  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_DOM0)			+= pci.o dbgp.o acpi.o
>  obj-$(CONFIG_XEN_MCE_LOG)		+= mcelog.o
>  obj-$(CONFIG_XEN_PCIDEV_BACKEND)	+= xen-pciback/
>  obj-$(CONFIG_XEN_PRIVCMD)		+= xen-privcmd.o
> --- /home/jbeulich/tmp/linux-3.6-rc6/drivers/xen/dbgp.c	1970-01-01 01:00:00.000000000 +0100
> +++ 3.6-rc6-xen-ehci-dbgp/drivers/xen/dbgp.c
> @@ -0,0 +1,48 @@
> +#include <linux/pci.h>
> +#include <linux/usb.h>
> +#include <linux/usb/ehci_def.h>
> +#include <linux/usb/hcd.h>
> +#include <asm/xen/hypercall.h>
> +#include <xen/interface/physdev.h>
> +#include <xen/xen.h>
> +
> +static int xen_dbgp_op(struct usb_hcd *hcd, int op)
> +{
> +	const struct device *ctrlr = hcd_to_bus(hcd)->controller;
> +	struct physdev_dbgp_op dbgp;
> +
> +	if (!xen_initial_domain())
> +		return 0;
> +
> +	dbgp.op = op;
> +
> +#ifdef CONFIG_PCI
> +	if (ctrlr->bus == &pci_bus_type) {
> +		const struct pci_dev *pdev = to_pci_dev(ctrlr);
> +
> +		dbgp.u.pci.seg = pci_domain_nr(pdev->bus);
> +		dbgp.u.pci.bus = pdev->bus->number;
> +		dbgp.u.pci.devfn = pdev->devfn;
> +		dbgp.bus = PHYSDEVOP_DBGP_BUS_PCI;
> +	} else
> +#endif
> +		dbgp.bus = PHYSDEVOP_DBGP_BUS_UNKNOWN;
> +
> +	return HYPERVISOR_physdev_op(PHYSDEVOP_dbgp_op, &dbgp);
> +}
> +
> +int xen_dbgp_reset_prep(struct usb_hcd *hcd)
> +{
> +	return xen_dbgp_op(hcd, PHYSDEVOP_DBGP_RESET_PREPARE);
> +}
> +
> +int xen_dbgp_external_startup(struct usb_hcd *hcd)
> +{
> +	return xen_dbgp_op(hcd, PHYSDEVOP_DBGP_RESET_DONE);
> +}
> +
> +#ifndef CONFIG_EARLY_PRINTK_DBGP
> +#include <linux/export.h>
> +EXPORT_SYMBOL_GPL(xen_dbgp_reset_prep);
> +EXPORT_SYMBOL_GPL(xen_dbgp_external_startup);
> +#endif
> --- 3.6-rc6/include/linux/usb/ehci_def.h
> +++ 3.6-rc6-xen-ehci-dbgp/include/linux/usb/ehci_def.h
> @@ -221,18 +221,35 @@ extern int __init early_dbgp_init(char *
>  extern struct console early_dbgp_console;
>  #endif /* CONFIG_EARLY_PRINTK_DBGP */
>  
> +struct usb_hcd;
> +
> +#ifdef CONFIG_XEN_DOM0
> +extern int xen_dbgp_reset_prep(struct usb_hcd *);
> +extern int xen_dbgp_external_startup(struct usb_hcd *);
> +#else
> +static inline int xen_dbgp_reset_prep(struct usb_hcd *hcd)
> +{
> +	return 1; /* Shouldn't this be 0? */
> +}
> +
> +static inline int xen_dbgp_external_startup(struct usb_hcd *hcd)
> +{
> +	return -1;
> +}
> +#endif
> +
>  #ifdef CONFIG_EARLY_PRINTK_DBGP
>  /* Call backs from ehci host driver to ehci debug driver */
> -extern int dbgp_external_startup(void);
> -extern int dbgp_reset_prep(void);
> +extern int dbgp_external_startup(struct usb_hcd *);
> +extern int dbgp_reset_prep(struct usb_hcd *hcd);
>  #else
> -static inline int dbgp_reset_prep(void)
> +static inline int dbgp_reset_prep(struct usb_hcd *hcd)
>  {
> -	return 1;
> +	return xen_dbgp_reset_prep(hcd);
>  }
> -static inline int dbgp_external_startup(void)
> +static inline int dbgp_external_startup(struct usb_hcd *hcd)
>  {
> -	return -1;
> +	return xen_dbgp_external_startup(hcd);
>  }
>  #endif
>  
> --- 3.6-rc6/include/xen/interface/physdev.h
> +++ 3.6-rc6-xen-ehci-dbgp/include/xen/interface/physdev.h
> @@ -258,6 +258,22 @@ struct physdev_pci_device {
>      uint8_t devfn;
>  };
>  
> +#define PHYSDEVOP_DBGP_RESET_PREPARE    1
> +#define PHYSDEVOP_DBGP_RESET_DONE       2
> +
> +#define PHYSDEVOP_DBGP_BUS_UNKNOWN      0
> +#define PHYSDEVOP_DBGP_BUS_PCI          1
> +
> +#define PHYSDEVOP_dbgp_op               29
> +struct physdev_dbgp_op {
> +    /* IN */
> +    uint8_t op;
> +    uint8_t bus;
> +    union {
> +        struct physdev_pci_device pci;
> +    } u;
> +};
> +
>  /*
>   * Notify that some PIRQ-bound event channels have been unmasked.
>   * ** This command is obsolete since interface version 0x00030202 and is **
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 18 14:57:58 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Sep 2012 14: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 1TDzFE-0001s5-Qq; Tue, 18 Sep 2012 14:57:48 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <netwiz@crc.id.au>) id 1TDzFD-0001ro-67
	for xen-devel@lists.xen.org; Tue, 18 Sep 2012 14:57:47 +0000
X-Env-Sender: netwiz@crc.id.au
X-Msg-Ref: server-14.tower-27.messagelabs.com!1347980259!4489206!1
X-Originating-IP: [203.56.246.92]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_8,
	spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1430 invoked from network); 18 Sep 2012 14:57:39 -0000
Received: from mail.crc.id.au (HELO mail.crc.id.au) (203.56.246.92)
	by server-14.tower-27.messagelabs.com with SMTP;
	18 Sep 2012 14:57:39 -0000
Received: from [IPv6:2002:cb38:f71b:2:f182:71ef:6e1c:e882] (unknown
	[IPv6:2002:cb38:f71b:2:f182:71ef:6e1c:e882])
	by mail.crc.id.au (Postfix) with ESMTPSA id 355EFB2
	for <xen-devel@lists.xen.org>; Wed, 19 Sep 2012 00:57:36 +1000 (EST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=crc.id.au; s=default;
	t=1347980256; bh=5TRA5m8hHJuz9a3wZYX9qu9rFl8DpKwFQ0ylfZQAAT4=;
	h=Date:From:To:Subject:References:In-Reply-To;
	b=n/l7uoHZWbYNCutCNxmcyVijgPSRAfw2gnzlYcKLwTvnw8ugqMipElyOCzcITqo2L
	YCjMVnRKjazdTpZRpbwlqrdKTWonpqLsFyTkexQ69s/++oGmTsJ/fiSeiRMPMCLfUG
	0f7SZj5HqZsRHFS8vnRT2ltW6kRCWsOGf2DzR52Q=
Message-ID: <50588BE1.3050004@crc.id.au>
Date: Wed, 19 Sep 2012 00:57:37 +1000
From: Steven Haigh <netwiz@crc.id.au>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:15.0) Gecko/20120907 Thunderbird/15.0.1
MIME-Version: 1.0
To: xen-devel@lists.xen.org
References: <50588493.7080908@crc.id.au> <20120918143327.GA7115@aepfle.de>
In-Reply-To: <20120918143327.GA7115@aepfle.de>
Subject: Re: [Xen-devel] Packaging Xen 4.2.0
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 19/09/2012 12:33 AM, Olaf Hering wrote:
> On Wed, Sep 19, Steven Haigh wrote:
>
>> A penny for peoples thoughts?
>
> xenpaging is a private helper, similar to qemu-dm. Its currently not
> integrated into xend or libxl.

Thanks, but shouldn't it be installed under --libdir? In my case, 
/usr/lib64 as per the configure? I'm still a bit confused as to why it 
ended up in /usr/lib/xen/bin.

Especially when configure is called with:
--libdir=/usr/lib64 --prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin

-- 
Steven Haigh

Email: netwiz@crc.id.au
Web: http://www.crc.id.au
Phone: (03) 9001 6090 - 0412 935 897
Fax: (03) 8338 0299

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 18 14:57:58 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Sep 2012 14: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 1TDzFE-0001s5-Qq; Tue, 18 Sep 2012 14:57:48 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <netwiz@crc.id.au>) id 1TDzFD-0001ro-67
	for xen-devel@lists.xen.org; Tue, 18 Sep 2012 14:57:47 +0000
X-Env-Sender: netwiz@crc.id.au
X-Msg-Ref: server-14.tower-27.messagelabs.com!1347980259!4489206!1
X-Originating-IP: [203.56.246.92]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_8,
	spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1430 invoked from network); 18 Sep 2012 14:57:39 -0000
Received: from mail.crc.id.au (HELO mail.crc.id.au) (203.56.246.92)
	by server-14.tower-27.messagelabs.com with SMTP;
	18 Sep 2012 14:57:39 -0000
Received: from [IPv6:2002:cb38:f71b:2:f182:71ef:6e1c:e882] (unknown
	[IPv6:2002:cb38:f71b:2:f182:71ef:6e1c:e882])
	by mail.crc.id.au (Postfix) with ESMTPSA id 355EFB2
	for <xen-devel@lists.xen.org>; Wed, 19 Sep 2012 00:57:36 +1000 (EST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=crc.id.au; s=default;
	t=1347980256; bh=5TRA5m8hHJuz9a3wZYX9qu9rFl8DpKwFQ0ylfZQAAT4=;
	h=Date:From:To:Subject:References:In-Reply-To;
	b=n/l7uoHZWbYNCutCNxmcyVijgPSRAfw2gnzlYcKLwTvnw8ugqMipElyOCzcITqo2L
	YCjMVnRKjazdTpZRpbwlqrdKTWonpqLsFyTkexQ69s/++oGmTsJ/fiSeiRMPMCLfUG
	0f7SZj5HqZsRHFS8vnRT2ltW6kRCWsOGf2DzR52Q=
Message-ID: <50588BE1.3050004@crc.id.au>
Date: Wed, 19 Sep 2012 00:57:37 +1000
From: Steven Haigh <netwiz@crc.id.au>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:15.0) Gecko/20120907 Thunderbird/15.0.1
MIME-Version: 1.0
To: xen-devel@lists.xen.org
References: <50588493.7080908@crc.id.au> <20120918143327.GA7115@aepfle.de>
In-Reply-To: <20120918143327.GA7115@aepfle.de>
Subject: Re: [Xen-devel] Packaging Xen 4.2.0
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 19/09/2012 12:33 AM, Olaf Hering wrote:
> On Wed, Sep 19, Steven Haigh wrote:
>
>> A penny for peoples thoughts?
>
> xenpaging is a private helper, similar to qemu-dm. Its currently not
> integrated into xend or libxl.

Thanks, but shouldn't it be installed under --libdir? In my case, 
/usr/lib64 as per the configure? I'm still a bit confused as to why it 
ended up in /usr/lib/xen/bin.

Especially when configure is called with:
--libdir=/usr/lib64 --prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin

-- 
Steven Haigh

Email: netwiz@crc.id.au
Web: http://www.crc.id.au
Phone: (03) 9001 6090 - 0412 935 897
Fax: (03) 8338 0299

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 18 15:06:10 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Sep 2012 15:06:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDzN5-0002Ca-VT; Tue, 18 Sep 2012 15:05:55 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1TDzN4-0002CV-Ef
	for xen-devel@lists.xen.org; Tue, 18 Sep 2012 15:05:54 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-5.tower-27.messagelabs.com!1347980747!8090399!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiA0MTY2ODc=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiA0MTY2ODc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19217 invoked from network); 18 Sep 2012 15:05:48 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-5.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 18 Sep 2012 15:05:48 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFGhi0PEj9t
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-088-110.pools.arcor-ip.net [88.65.88.110])
	by smtp.strato.de (joses mo12) (RZmta 30.14 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id N025b3o8IF3t3s ;
	Tue, 18 Sep 2012 17:05:47 +0200 (CEST)
Received: by probook.site (Postfix, from userid 1000)
	id 02C2D1863E; Tue, 18 Sep 2012 17:05:46 +0200 (CEST)
Date: Tue, 18 Sep 2012 17:05:46 +0200
From: Olaf Hering <olaf@aepfle.de>
To: Steven Haigh <netwiz@crc.id.au>
Message-ID: <20120918150546.GA10607@aepfle.de>
References: <50588493.7080908@crc.id.au> <20120918143327.GA7115@aepfle.de>
	<50588BE1.3050004@crc.id.au>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <50588BE1.3050004@crc.id.au>
User-Agent: Mutt/1.5.21.rev5555 (2012-07-20)
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Packaging Xen 4.2.0
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Sep 19, Steven Haigh wrote:

> Thanks, but shouldn't it be installed under --libdir? In my case, /usr/lib64
> as per the configure? I'm still a bit confused as to why it ended up in
> /usr/lib/xen/bin.
> 
> Especially when configure is called with:
> --libdir=/usr/lib64 --prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin

tools/xenpaging/Makefile uses LIBEXEC.
libexec defaults to /usr/lib/xen/bin, --libexec=/usr/lib64/xen/bin or
similar may work.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 18 15:06:10 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Sep 2012 15:06:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDzN5-0002Ca-VT; Tue, 18 Sep 2012 15:05:55 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1TDzN4-0002CV-Ef
	for xen-devel@lists.xen.org; Tue, 18 Sep 2012 15:05:54 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-5.tower-27.messagelabs.com!1347980747!8090399!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiA0MTY2ODc=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiA0MTY2ODc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19217 invoked from network); 18 Sep 2012 15:05:48 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-5.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 18 Sep 2012 15:05:48 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFGhi0PEj9t
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-088-110.pools.arcor-ip.net [88.65.88.110])
	by smtp.strato.de (joses mo12) (RZmta 30.14 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id N025b3o8IF3t3s ;
	Tue, 18 Sep 2012 17:05:47 +0200 (CEST)
Received: by probook.site (Postfix, from userid 1000)
	id 02C2D1863E; Tue, 18 Sep 2012 17:05:46 +0200 (CEST)
Date: Tue, 18 Sep 2012 17:05:46 +0200
From: Olaf Hering <olaf@aepfle.de>
To: Steven Haigh <netwiz@crc.id.au>
Message-ID: <20120918150546.GA10607@aepfle.de>
References: <50588493.7080908@crc.id.au> <20120918143327.GA7115@aepfle.de>
	<50588BE1.3050004@crc.id.au>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <50588BE1.3050004@crc.id.au>
User-Agent: Mutt/1.5.21.rev5555 (2012-07-20)
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Packaging Xen 4.2.0
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Sep 19, Steven Haigh wrote:

> Thanks, but shouldn't it be installed under --libdir? In my case, /usr/lib64
> as per the configure? I'm still a bit confused as to why it ended up in
> /usr/lib/xen/bin.
> 
> Especially when configure is called with:
> --libdir=/usr/lib64 --prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin

tools/xenpaging/Makefile uses LIBEXEC.
libexec defaults to /usr/lib/xen/bin, --libexec=/usr/lib64/xen/bin or
similar may work.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 18 15:07:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Sep 2012 15:07:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDzNz-0002Fr-D9; Tue, 18 Sep 2012 15:06:51 +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 1TDzNx-0002Fl-K9
	for xen-devel@lists.xen.org; Tue, 18 Sep 2012 15:06:49 +0000
Received: from [85.158.137.99:3589] by server-2.bemta-3.messagelabs.com id
	33/02-04862-80E88505; Tue, 18 Sep 2012 15:06:48 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-6.tower-217.messagelabs.com!1347980806!13040726!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDc1Nzk4OQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31766 invoked from network); 18 Sep 2012 15:06:47 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-6.tower-217.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 18 Sep 2012 15:06:47 -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 q8IF6G7U018619
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 18 Sep 2012 15:06:16 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
	q8IF6FJB015916
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 18 Sep 2012 15:06:15 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
	q8IF6D9S020938; Tue, 18 Sep 2012 10:06:13 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 18 Sep 2012 08:06:13 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 3C6AD402C0; Tue, 18 Sep 2012 10:55:24 -0400 (EDT)
Date: Tue, 18 Sep 2012 10:55:24 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Andre Przywara <andre.przywara@amd.com>
Message-ID: <20120918145524.GA19790@phenom.dumpdata.com>
References: <501BC20F.3040205@amd.com>
	<20120803123628.GB10670@andromeda.dapyr.net>
	<20120817142237.GA8467@phenom.dumpdata.com>
	<20120914185822.GA7495@phenom.dumpdata.com>
	<5056D152.2090708@amd.com>
	<20120917191432.GA18552@phenom.dumpdata.com>
	<5058458D.7030603@amd.com>
	<20120918134457.GE12053@phenom.dumpdata.com>
	<5058A646.5060909@amd.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <5058A646.5060909@amd.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: Konrad Rzeszutek Wilk <konrad@kernel.org>,
	Jeremy Fitzhardinge <jeremy@goop.org>, xen-devel <xen-devel@lists.xen.org>,
	Dario Faggioli <raistlin@linux.it>,
	Konrad Rzeszutek Wilk <konrad@darnok.org>
Subject: Re: [Xen-devel] Dom0 crash with old style AMD NUMA detection
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Sep 18, 2012 at 06:50:14PM +0200, Andre Przywara wrote:
> On 09/18/2012 03:44 PM, Konrad Rzeszutek Wilk wrote:
> >On Tue, Sep 18, 2012 at 11:57:33AM +0200, Andre Przywara wrote:
> >>On 09/17/2012 09:14 PM, Konrad Rzeszutek Wilk wrote:
> >>>On Mon, Sep 17, 2012 at 09:29:22AM +0200, Andre Przywara wrote:
> >>>>On 09/14/2012 08:58 PM, Konrad Rzeszutek Wilk wrote:
> >>>>>>>>[    0.000000] Kernel panic - not syncing: Attempted to kill the idle task!
> >>>>>>>>(XEN) Domain 0 crashed: 'noreboot' set - not rebooting.
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>The obvious solution would be to explicitly deny northbridge scanning
> >>>>>>>>when running as Dom0, though I am not sure how to implement this without
> >>>>>>>>upsetting the other kernel folks about "that crappy Xen thing" again ;-)
> >>>>>>>
> >>>>>>>Heh.
> >>>>>>>Is there a numa=0 option that could be used to override it to turn it
> >>>>>>>off?
> >>>>>>
> >>>>>>Not compile tested.. but was thinking something like this:
> >>>>>
> >>>>>ping?
> >>>>
> >>>>That looks good to me - at least for the time being.
> >>>
> >>>OK, can I've your Tested-by/Acked-by on it pls?
> >>>
> >>>>I just want to check how this interacts with upcoming Dom0 NUMA
> >>>>support. It wouldn't be too clever if we deliberately disable NUMA
> >>>
> >>>We can always revert this patch in future versions of Linux.
> >>
> >>I don't like this idea. Then we have Linux kernel up to 3.5 working
> >>and say from 3.8 on again, but 3.6 and 3.7 cannot use NUMA. That
> >>would be pretty unfortunate.
> >
> >Huh? v3.5 working? But it never worked? I would say turn off the NUMA
> >detection (keep in mind it still will set up the dummy NUMA stuff)
> >until there are some PV NUMA capability and then we can revert it.
> 
> I was under the impression that somehow the Dom0 NUMA would be made
> compatible, using some of the existing discovery mechanisms. So we
> would enable the hypervisor, and Dom0 would just magically start
> working. I am probably rooted too much in the HVM world ;-)
> 
> >>
> >>I haven't checked back with Dario, but I'd suspect that we use ACPI
> >>for injecting NUMA topology into Dom0. Even if not, a general
> >>"numa=off" for Dom0 is too much of a sledgehammer for me.
> >
> >How would you inject it in Dom0? It s a PV guest so the hypervisor would
> >have to tweak the SRAT/SLIT tables. That is not going to happen
> >in the very short term.. And I don't recall seeing any patches, so
> >the dom0 NUMA support is right now non-existent?
> 
> Right, I just don't wanted to slam the door deliberately. Thinking
> more about this, we probably need some kind of PV enablement in
> Dom0, even if we could somehow use the ACPI tables (and thus the
> ACPI parsing code).
> If this is the case, we could at the same time remove this "force
> numa off" patch.
> 
> I am almost convinced by now.
> Just waiting for Dario's opinion for a few more hours and will send
> my final opinion later today. If you cannot wait, tell me.

Couple of days is OK with me. My deadline is Friday as I would like
to send a git pull to Linus and include this patch if it makes sense.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 18 15:07:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Sep 2012 15:07:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDzNz-0002Fr-D9; Tue, 18 Sep 2012 15:06:51 +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 1TDzNx-0002Fl-K9
	for xen-devel@lists.xen.org; Tue, 18 Sep 2012 15:06:49 +0000
Received: from [85.158.137.99:3589] by server-2.bemta-3.messagelabs.com id
	33/02-04862-80E88505; Tue, 18 Sep 2012 15:06:48 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-6.tower-217.messagelabs.com!1347980806!13040726!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDc1Nzk4OQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31766 invoked from network); 18 Sep 2012 15:06:47 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-6.tower-217.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 18 Sep 2012 15:06:47 -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 q8IF6G7U018619
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 18 Sep 2012 15:06:16 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
	q8IF6FJB015916
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 18 Sep 2012 15:06:15 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
	q8IF6D9S020938; Tue, 18 Sep 2012 10:06:13 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 18 Sep 2012 08:06:13 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 3C6AD402C0; Tue, 18 Sep 2012 10:55:24 -0400 (EDT)
Date: Tue, 18 Sep 2012 10:55:24 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Andre Przywara <andre.przywara@amd.com>
Message-ID: <20120918145524.GA19790@phenom.dumpdata.com>
References: <501BC20F.3040205@amd.com>
	<20120803123628.GB10670@andromeda.dapyr.net>
	<20120817142237.GA8467@phenom.dumpdata.com>
	<20120914185822.GA7495@phenom.dumpdata.com>
	<5056D152.2090708@amd.com>
	<20120917191432.GA18552@phenom.dumpdata.com>
	<5058458D.7030603@amd.com>
	<20120918134457.GE12053@phenom.dumpdata.com>
	<5058A646.5060909@amd.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <5058A646.5060909@amd.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: Konrad Rzeszutek Wilk <konrad@kernel.org>,
	Jeremy Fitzhardinge <jeremy@goop.org>, xen-devel <xen-devel@lists.xen.org>,
	Dario Faggioli <raistlin@linux.it>,
	Konrad Rzeszutek Wilk <konrad@darnok.org>
Subject: Re: [Xen-devel] Dom0 crash with old style AMD NUMA detection
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Sep 18, 2012 at 06:50:14PM +0200, Andre Przywara wrote:
> On 09/18/2012 03:44 PM, Konrad Rzeszutek Wilk wrote:
> >On Tue, Sep 18, 2012 at 11:57:33AM +0200, Andre Przywara wrote:
> >>On 09/17/2012 09:14 PM, Konrad Rzeszutek Wilk wrote:
> >>>On Mon, Sep 17, 2012 at 09:29:22AM +0200, Andre Przywara wrote:
> >>>>On 09/14/2012 08:58 PM, Konrad Rzeszutek Wilk wrote:
> >>>>>>>>[    0.000000] Kernel panic - not syncing: Attempted to kill the idle task!
> >>>>>>>>(XEN) Domain 0 crashed: 'noreboot' set - not rebooting.
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>The obvious solution would be to explicitly deny northbridge scanning
> >>>>>>>>when running as Dom0, though I am not sure how to implement this without
> >>>>>>>>upsetting the other kernel folks about "that crappy Xen thing" again ;-)
> >>>>>>>
> >>>>>>>Heh.
> >>>>>>>Is there a numa=0 option that could be used to override it to turn it
> >>>>>>>off?
> >>>>>>
> >>>>>>Not compile tested.. but was thinking something like this:
> >>>>>
> >>>>>ping?
> >>>>
> >>>>That looks good to me - at least for the time being.
> >>>
> >>>OK, can I've your Tested-by/Acked-by on it pls?
> >>>
> >>>>I just want to check how this interacts with upcoming Dom0 NUMA
> >>>>support. It wouldn't be too clever if we deliberately disable NUMA
> >>>
> >>>We can always revert this patch in future versions of Linux.
> >>
> >>I don't like this idea. Then we have Linux kernel up to 3.5 working
> >>and say from 3.8 on again, but 3.6 and 3.7 cannot use NUMA. That
> >>would be pretty unfortunate.
> >
> >Huh? v3.5 working? But it never worked? I would say turn off the NUMA
> >detection (keep in mind it still will set up the dummy NUMA stuff)
> >until there are some PV NUMA capability and then we can revert it.
> 
> I was under the impression that somehow the Dom0 NUMA would be made
> compatible, using some of the existing discovery mechanisms. So we
> would enable the hypervisor, and Dom0 would just magically start
> working. I am probably rooted too much in the HVM world ;-)
> 
> >>
> >>I haven't checked back with Dario, but I'd suspect that we use ACPI
> >>for injecting NUMA topology into Dom0. Even if not, a general
> >>"numa=off" for Dom0 is too much of a sledgehammer for me.
> >
> >How would you inject it in Dom0? It s a PV guest so the hypervisor would
> >have to tweak the SRAT/SLIT tables. That is not going to happen
> >in the very short term.. And I don't recall seeing any patches, so
> >the dom0 NUMA support is right now non-existent?
> 
> Right, I just don't wanted to slam the door deliberately. Thinking
> more about this, we probably need some kind of PV enablement in
> Dom0, even if we could somehow use the ACPI tables (and thus the
> ACPI parsing code).
> If this is the case, we could at the same time remove this "force
> numa off" patch.
> 
> I am almost convinced by now.
> Just waiting for Dario's opinion for a few more hours and will send
> my final opinion later today. If you cannot wait, tell me.

Couple of days is OK with me. My deadline is Friday as I would like
to send a git pull to Linus and include this patch if it makes sense.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 18 15:07:11 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Sep 2012 15:07:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDzO5-0002Gq-VY; Tue, 18 Sep 2012 15:06:57 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <gregkh@linuxfoundation.org>) id 1TDzO4-0002GK-F9
	for xen-devel@lists.xen.org; Tue, 18 Sep 2012 15:06:56 +0000
Received: from [85.158.138.51:55004] by server-4.bemta-3.messagelabs.com id
	18/4D-24831-D0E88505; Tue, 18 Sep 2012 15:06:53 +0000
X-Env-Sender: gregkh@linuxfoundation.org
X-Msg-Ref: server-7.tower-174.messagelabs.com!1347980813!22175579!1
X-Originating-IP: [209.85.212.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3856 invoked from network); 18 Sep 2012 15:06:53 -0000
Received: from mail-wi0-f173.google.com (HELO mail-wi0-f173.google.com)
	(209.85.212.173)
	by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Sep 2012 15:06:53 -0000
Received: by wibhm6 with SMTP id hm6so3409422wib.14
	for <xen-devel@lists.xen.org>; Tue, 18 Sep 2012 08:06:52 -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=kNgYdgqGXQHfT7aOKcUBA+Rge0tMBHDnPL5kH7UpsDQ=;
	b=FICpZcQ++qNMjhEcUuw82RLb/8MVZ6UVXG4gXb5S71e4DT33dFhqH9ymDkRRMwiYso
	IJoYjAxCZb0i+MKoZIC0QKlCc8h1kEaMSIS50yXjVH86Bdr66i3Dxp8edrXK30TC/g6Z
	w+mudVHtMIfEAG2xRc+8u2tFSFTJf/klGyztgRn0bpFgREbl8YKQwHAir8Pc7V2Pqn+z
	6HX/xLcGD/tCwiTR1ZOn3JnMAJGqLZFnGWfey+9X8oDanJf2Ay+moe4x6WG6E23XMBtS
	Obl52z1rc937Fq+N8+R0Pa+q5nU/T6jBdmxlIINkN9iKaF0PjSW738XeIFtGooSPVAn6
	W3Kw==
Received: by 10.216.241.198 with SMTP id g48mr36646wer.164.1347980812836;
	Tue, 18 Sep 2012 08:06:52 -0700 (PDT)
Received: from localhost (pakora.collabora.co.uk. [93.93.133.71])
	by mx.google.com with ESMTPS id dp8sm32282727wib.3.2012.09.18.08.06.51
	(version=TLSv1/SSLv3 cipher=OTHER);
	Tue, 18 Sep 2012 08:06:51 -0700 (PDT)
Date: Tue, 18 Sep 2012 16:06:49 +0100
From: Greg KH <gregkh@linuxfoundation.org>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Message-ID: <20120918150649.GA24798@kroah.com>
References: <505875B6020000780009C01D@nat28.tlf.novell.com>
	<20120918144230.GC19332@phenom.dumpdata.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120918144230.GC19332@phenom.dumpdata.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Gm-Message-State: ALoCoQnWqQ4+sHm7cwEwhB6JAPtRMpuCqOn96FoJLmgNLVfNxOwWUaw0QwJ0eKrqVCoM8YKT0V3v
Cc: linux-usb@vger.kernel.org, stern@rowland.harvard.edu,
	Jan Beulich <JBeulich@suse.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] EHCI/Xen: propagate controller reset
 information to hypervisor
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Sep 18, 2012 at 10:42:30AM -0400, Konrad Rzeszutek Wilk wrote:
> On Tue, Sep 18, 2012 at 12:23:02PM +0100, Jan Beulich wrote:
> > Just like for the in-tree early console debug port driver, the
> > hypervisor - when using a debug port based console - also needs to be
> > told about controller resets, so it can suppress using and then
> > re-initialize the debug port accordingly.
> > 
> > Other than the in-tree driver, the hypervisor driver actually cares
> > about doing this only for the device where the debug is port actually
> > in use, i.e. it needs to be told the coordinates of the device being
> > reset (quite obviously, leveraging the addition done for that would
> > likely benefit the in-tree driver too).
> > 
> > Signed-off-by: Jan Beulich <jbeulich@suse.com>
> 
> Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> 
> on the *xen* parts.

So, I'm guessing this should go in through the USB tree?  If there are
no objections, I'll do that.

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 Tue Sep 18 15:07:11 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Sep 2012 15:07:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDzO5-0002Gq-VY; Tue, 18 Sep 2012 15:06:57 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <gregkh@linuxfoundation.org>) id 1TDzO4-0002GK-F9
	for xen-devel@lists.xen.org; Tue, 18 Sep 2012 15:06:56 +0000
Received: from [85.158.138.51:55004] by server-4.bemta-3.messagelabs.com id
	18/4D-24831-D0E88505; Tue, 18 Sep 2012 15:06:53 +0000
X-Env-Sender: gregkh@linuxfoundation.org
X-Msg-Ref: server-7.tower-174.messagelabs.com!1347980813!22175579!1
X-Originating-IP: [209.85.212.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3856 invoked from network); 18 Sep 2012 15:06:53 -0000
Received: from mail-wi0-f173.google.com (HELO mail-wi0-f173.google.com)
	(209.85.212.173)
	by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Sep 2012 15:06:53 -0000
Received: by wibhm6 with SMTP id hm6so3409422wib.14
	for <xen-devel@lists.xen.org>; Tue, 18 Sep 2012 08:06:52 -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=kNgYdgqGXQHfT7aOKcUBA+Rge0tMBHDnPL5kH7UpsDQ=;
	b=FICpZcQ++qNMjhEcUuw82RLb/8MVZ6UVXG4gXb5S71e4DT33dFhqH9ymDkRRMwiYso
	IJoYjAxCZb0i+MKoZIC0QKlCc8h1kEaMSIS50yXjVH86Bdr66i3Dxp8edrXK30TC/g6Z
	w+mudVHtMIfEAG2xRc+8u2tFSFTJf/klGyztgRn0bpFgREbl8YKQwHAir8Pc7V2Pqn+z
	6HX/xLcGD/tCwiTR1ZOn3JnMAJGqLZFnGWfey+9X8oDanJf2Ay+moe4x6WG6E23XMBtS
	Obl52z1rc937Fq+N8+R0Pa+q5nU/T6jBdmxlIINkN9iKaF0PjSW738XeIFtGooSPVAn6
	W3Kw==
Received: by 10.216.241.198 with SMTP id g48mr36646wer.164.1347980812836;
	Tue, 18 Sep 2012 08:06:52 -0700 (PDT)
Received: from localhost (pakora.collabora.co.uk. [93.93.133.71])
	by mx.google.com with ESMTPS id dp8sm32282727wib.3.2012.09.18.08.06.51
	(version=TLSv1/SSLv3 cipher=OTHER);
	Tue, 18 Sep 2012 08:06:51 -0700 (PDT)
Date: Tue, 18 Sep 2012 16:06:49 +0100
From: Greg KH <gregkh@linuxfoundation.org>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Message-ID: <20120918150649.GA24798@kroah.com>
References: <505875B6020000780009C01D@nat28.tlf.novell.com>
	<20120918144230.GC19332@phenom.dumpdata.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120918144230.GC19332@phenom.dumpdata.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Gm-Message-State: ALoCoQnWqQ4+sHm7cwEwhB6JAPtRMpuCqOn96FoJLmgNLVfNxOwWUaw0QwJ0eKrqVCoM8YKT0V3v
Cc: linux-usb@vger.kernel.org, stern@rowland.harvard.edu,
	Jan Beulich <JBeulich@suse.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] EHCI/Xen: propagate controller reset
 information to hypervisor
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Sep 18, 2012 at 10:42:30AM -0400, Konrad Rzeszutek Wilk wrote:
> On Tue, Sep 18, 2012 at 12:23:02PM +0100, Jan Beulich wrote:
> > Just like for the in-tree early console debug port driver, the
> > hypervisor - when using a debug port based console - also needs to be
> > told about controller resets, so it can suppress using and then
> > re-initialize the debug port accordingly.
> > 
> > Other than the in-tree driver, the hypervisor driver actually cares
> > about doing this only for the device where the debug is port actually
> > in use, i.e. it needs to be told the coordinates of the device being
> > reset (quite obviously, leveraging the addition done for that would
> > likely benefit the in-tree driver too).
> > 
> > Signed-off-by: Jan Beulich <jbeulich@suse.com>
> 
> Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> 
> on the *xen* parts.

So, I'm guessing this should go in through the USB tree?  If there are
no objections, I'll do that.

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 Tue Sep 18 15:13:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Sep 2012 15:13:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDzTo-0002eW-RI; Tue, 18 Sep 2012 15:12:52 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jmarcet@gmail.com>) id 1TDzTn-0002eR-Dh
	for xen-devel@lists.xen.org; Tue, 18 Sep 2012 15:12:51 +0000
Received: from [85.158.143.99:39641] by server-2.bemta-4.messagelabs.com id
	65/93-06610-27F88505; Tue, 18 Sep 2012 15:12:50 +0000
X-Env-Sender: jmarcet@gmail.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1347981168!29939746!1
X-Originating-IP: [209.85.219.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29316 invoked from network); 18 Sep 2012 15:12:50 -0000
Received: from mail-oa0-f45.google.com (HELO mail-oa0-f45.google.com)
	(209.85.219.45)
	by server-13.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Sep 2012 15:12:50 -0000
Received: by oagn12 with SMTP id n12so7737418oag.32
	for <xen-devel@lists.xen.org>; Tue, 18 Sep 2012 08:12:48 -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=C6awr7yxuBrLVFfHSye0Bnc0lNrmvrbN3bN0uM6KUTI=;
	b=T7kG5NiR2Bm2NxpXpMprW0O1m1UBpIMMxmiRxmZaQ6mwJF4UK16AKTqy34lu/NP0NI
	a1jA9eOddoRyioypfgP+aH+Svbw7Ta6TYZFn3CWUW1aSQvGKtgXx6VRYQHB/oe9a6DkG
	JO5mN5ElopIl0PFkhznE+vB3pW/VBxojPtU1U5LOU0lle8T53Lqm/giRcDBblxTj4xsu
	YCVRn7kNUlTwlxMe18WiFIoJgEdvNEIz4ibi6k8kGf/gsRVzuOYPtvOyLEFZa+2DAlEU
	FZXupmsvahqEobaeoAF8RY1mPMSAhV3TlDlUPPOCbt8/B2cDZGuAIUYhXKdE3HKXHnpV
	Gpxw==
Received: by 10.182.174.68 with SMTP id bq4mr187931obc.53.1347981168439; Tue,
	18 Sep 2012 08:12:48 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.60.138.225 with HTTP; Tue, 18 Sep 2012 08:12:28 -0700 (PDT)
In-Reply-To: <1777522677.20120918163349@eikelenboom.it>
References: <CAAnFQG9PuzRLSsCS8m_0VUeV+ZaCwK3zsbinxtuFBfdSihJknw@mail.gmail.com>
	<CC7DF5F7.3F018%keir.xen@gmail.com>
	<CAAnFQG96=Fm5jLqvaqxd6nf2fDAeL6t7drxqkqXzvZHYDOKaDQ@mail.gmail.com>
	<1777522677.20120918163349@eikelenboom.it>
From: Javier Marcet <jmarcet@gmail.com>
Date: Tue, 18 Sep 2012 17:12:28 +0200
Message-ID: <CAAnFQG_wqxutZmR62UhNb-dKQUakYvBrzHEnmMZTv3RkgUeRbg@mail.gmail.com>
To: Sander Eikelenboom <linux@eikelenboom.it>
Cc: Konrad Rzeszutek Wilk <konrad@kernel.org>, Keir Fraser <keir.xen@gmail.com>,
	Xen Devel Mailing list <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.2.0-rc4 issues with DVB tuner
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gVHVlLCBTZXAgMTgsIDIwMTIgYXQgNDozMyBQTSwgU2FuZGVyIEVpa2VsZW5ib29tCjxsaW51
eEBlaWtlbGVuYm9vbS5pdD4gd3JvdGU6Cgo+Pj4+IFdoYXQgSSBkb27CtHQgdW5kZXJzdGFuZCBp
cyBob3cgZ3JhcGhpY3MgcGFzcyB0aHJvdWdoIGV2ZW4gd29ya3MKPj4+IGFuZCBhIHR1bmVyCj4+
Pj4gY2FyZCBoYXMgcHJvYmxlbXMgZHVlIHRvIHRoZSBpbnRyb2R1Y2VkIGxhdGVuY2llcyBpbiB0
aGUKPj4+IElSUXMuCj4+Pgo+Pj4gRG8geW91IGhhdmUKPj4+PiBhbnkgbW9yZSBpbmZvIGFib3V0
IHRoaXM/Cj4+Pgo+Pj4gSW4gdGhpcyByZXNwZWN0IHNvdW5kIGlzIGhhcmRlciB0aGFuIGdyYXBo
aWNzLiBUcnkgcGlubmluZyB5b3VyIGRvbTAgdG8gYQo+Pj4gQ1BVIGNvcmUsIGFuZCBzZXQgYWZm
aW5pdGllcyBvbiBvdGhlciBkb21haW5zIHNvIHRoYXQgZG9tMCBkb2VzIG5vdCBjb21wZXRlCj4+
PiBmb3IgdGhlIGNvcmUgd2l0aCBhbnkgb3RoZXIgZG9tYWlucy4KPgo+PiBBbGwgcmlnaHQsIEkg
Y2FuIHRyeSB0aGF0LiBIb3dldmVyLCB0aGUgcHJvYmxlbSBoYXBwZW5zIHdpdGhvdXQgYW55Cj4+
IGRvbVUgcnVubmluZywganVzdAo+PiB0aGUgZG9tMC4gRG8geW91IHN0aWxsIHRoaW5rIHRoYXQg
cGlubmluZyB0byBhIGNwdSBjb3JlIG9yIHNldHRpbmcKPj4gYWZmaW5pdGllcyBjYW4gaGVscD8K
Pgo+IEkgaGF2ZW4ndCBmb2xsb3dlZCB0aGUgdGhyZWFkIGNsb3NlbHksIGJ1dCBhcmUgeW91IHN1
cmUgdGhlIGRldmljZSB3b3JrcyBPSyBvbiBiYXJlbWV0YWwgKGxpbnV4IHdpdGhvdXQgeGVuKSA/
Cj4gSWYgeW91IGhhdmUgcHJvYmxlbXMgaW4gZG9tMCBpdCBzZWVtcyBpdCBoYXNuJ3QgZ290IG11
Y2ggdG8gZG8gd2l0aCBwYXNzdGhyb3VnaCA/CgpZb3UgYXJlIHJpZ2h0LCBJIGhhdmVuwrR0IHJl
YWNoZWQgdGhlIHBvaW50IG9mIHRyeWluZyB0byBwYXNzdGhyb3VnaCBpdAp0byBhIGRvbVUuCgpJ
wrRtIHN1cmUgdGhlIGRldmljZSB3b3JrcyBmaW5lIG9uIGJhcmUgbWV0YWwuIEkgaGF2ZSBpdCB3
b3JraW5nIG9uIGFuCkhUUEMgd2hpY2ggbWFrZXMgMi0zCnJlY29yZGluZ3MgcGVyIGRheSwgd2l0
aG91dCBpc3N1ZXMuCgpPbiB0aGUgbGludXggbWVkaWEgbWFpbGluZyBsaXN0IEkgd2FzIHNhaWQg
dGhpcyBwcm9ibGVtIHdhcyBjb21tb24Kd2l0aCBhbGwgdHVuZXIgY2FyZHMsCm1vcmUgZ2VuZXJh
bGx5IHdpdGggYW55IGNhcmQgd2hpY2ggZ2VuZXJhdGVzIGxvdHMgb2YgaW50ZXJydXB0aW9ucyBh
bmQKdGhhdCBJIHNob3VsZCBiZXR0ZXIKZm9yZ2V0IGFib3V0IGl0LgoKCi0tIApKYXZpZXIgTWFy
Y2V0IDxqbWFyY2V0QGdtYWlsLmNvbT4KCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhl
bi5vcmcKaHR0cDovL2xpc3RzLnhlbi5vcmcveGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Tue Sep 18 15:13:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Sep 2012 15:13:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDzTo-0002eW-RI; Tue, 18 Sep 2012 15:12:52 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jmarcet@gmail.com>) id 1TDzTn-0002eR-Dh
	for xen-devel@lists.xen.org; Tue, 18 Sep 2012 15:12:51 +0000
Received: from [85.158.143.99:39641] by server-2.bemta-4.messagelabs.com id
	65/93-06610-27F88505; Tue, 18 Sep 2012 15:12:50 +0000
X-Env-Sender: jmarcet@gmail.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1347981168!29939746!1
X-Originating-IP: [209.85.219.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29316 invoked from network); 18 Sep 2012 15:12:50 -0000
Received: from mail-oa0-f45.google.com (HELO mail-oa0-f45.google.com)
	(209.85.219.45)
	by server-13.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Sep 2012 15:12:50 -0000
Received: by oagn12 with SMTP id n12so7737418oag.32
	for <xen-devel@lists.xen.org>; Tue, 18 Sep 2012 08:12:48 -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=C6awr7yxuBrLVFfHSye0Bnc0lNrmvrbN3bN0uM6KUTI=;
	b=T7kG5NiR2Bm2NxpXpMprW0O1m1UBpIMMxmiRxmZaQ6mwJF4UK16AKTqy34lu/NP0NI
	a1jA9eOddoRyioypfgP+aH+Svbw7Ta6TYZFn3CWUW1aSQvGKtgXx6VRYQHB/oe9a6DkG
	JO5mN5ElopIl0PFkhznE+vB3pW/VBxojPtU1U5LOU0lle8T53Lqm/giRcDBblxTj4xsu
	YCVRn7kNUlTwlxMe18WiFIoJgEdvNEIz4ibi6k8kGf/gsRVzuOYPtvOyLEFZa+2DAlEU
	FZXupmsvahqEobaeoAF8RY1mPMSAhV3TlDlUPPOCbt8/B2cDZGuAIUYhXKdE3HKXHnpV
	Gpxw==
Received: by 10.182.174.68 with SMTP id bq4mr187931obc.53.1347981168439; Tue,
	18 Sep 2012 08:12:48 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.60.138.225 with HTTP; Tue, 18 Sep 2012 08:12:28 -0700 (PDT)
In-Reply-To: <1777522677.20120918163349@eikelenboom.it>
References: <CAAnFQG9PuzRLSsCS8m_0VUeV+ZaCwK3zsbinxtuFBfdSihJknw@mail.gmail.com>
	<CC7DF5F7.3F018%keir.xen@gmail.com>
	<CAAnFQG96=Fm5jLqvaqxd6nf2fDAeL6t7drxqkqXzvZHYDOKaDQ@mail.gmail.com>
	<1777522677.20120918163349@eikelenboom.it>
From: Javier Marcet <jmarcet@gmail.com>
Date: Tue, 18 Sep 2012 17:12:28 +0200
Message-ID: <CAAnFQG_wqxutZmR62UhNb-dKQUakYvBrzHEnmMZTv3RkgUeRbg@mail.gmail.com>
To: Sander Eikelenboom <linux@eikelenboom.it>
Cc: Konrad Rzeszutek Wilk <konrad@kernel.org>, Keir Fraser <keir.xen@gmail.com>,
	Xen Devel Mailing list <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.2.0-rc4 issues with DVB tuner
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gVHVlLCBTZXAgMTgsIDIwMTIgYXQgNDozMyBQTSwgU2FuZGVyIEVpa2VsZW5ib29tCjxsaW51
eEBlaWtlbGVuYm9vbS5pdD4gd3JvdGU6Cgo+Pj4+IFdoYXQgSSBkb27CtHQgdW5kZXJzdGFuZCBp
cyBob3cgZ3JhcGhpY3MgcGFzcyB0aHJvdWdoIGV2ZW4gd29ya3MKPj4+IGFuZCBhIHR1bmVyCj4+
Pj4gY2FyZCBoYXMgcHJvYmxlbXMgZHVlIHRvIHRoZSBpbnRyb2R1Y2VkIGxhdGVuY2llcyBpbiB0
aGUKPj4+IElSUXMuCj4+Pgo+Pj4gRG8geW91IGhhdmUKPj4+PiBhbnkgbW9yZSBpbmZvIGFib3V0
IHRoaXM/Cj4+Pgo+Pj4gSW4gdGhpcyByZXNwZWN0IHNvdW5kIGlzIGhhcmRlciB0aGFuIGdyYXBo
aWNzLiBUcnkgcGlubmluZyB5b3VyIGRvbTAgdG8gYQo+Pj4gQ1BVIGNvcmUsIGFuZCBzZXQgYWZm
aW5pdGllcyBvbiBvdGhlciBkb21haW5zIHNvIHRoYXQgZG9tMCBkb2VzIG5vdCBjb21wZXRlCj4+
PiBmb3IgdGhlIGNvcmUgd2l0aCBhbnkgb3RoZXIgZG9tYWlucy4KPgo+PiBBbGwgcmlnaHQsIEkg
Y2FuIHRyeSB0aGF0LiBIb3dldmVyLCB0aGUgcHJvYmxlbSBoYXBwZW5zIHdpdGhvdXQgYW55Cj4+
IGRvbVUgcnVubmluZywganVzdAo+PiB0aGUgZG9tMC4gRG8geW91IHN0aWxsIHRoaW5rIHRoYXQg
cGlubmluZyB0byBhIGNwdSBjb3JlIG9yIHNldHRpbmcKPj4gYWZmaW5pdGllcyBjYW4gaGVscD8K
Pgo+IEkgaGF2ZW4ndCBmb2xsb3dlZCB0aGUgdGhyZWFkIGNsb3NlbHksIGJ1dCBhcmUgeW91IHN1
cmUgdGhlIGRldmljZSB3b3JrcyBPSyBvbiBiYXJlbWV0YWwgKGxpbnV4IHdpdGhvdXQgeGVuKSA/
Cj4gSWYgeW91IGhhdmUgcHJvYmxlbXMgaW4gZG9tMCBpdCBzZWVtcyBpdCBoYXNuJ3QgZ290IG11
Y2ggdG8gZG8gd2l0aCBwYXNzdGhyb3VnaCA/CgpZb3UgYXJlIHJpZ2h0LCBJIGhhdmVuwrR0IHJl
YWNoZWQgdGhlIHBvaW50IG9mIHRyeWluZyB0byBwYXNzdGhyb3VnaCBpdAp0byBhIGRvbVUuCgpJ
wrRtIHN1cmUgdGhlIGRldmljZSB3b3JrcyBmaW5lIG9uIGJhcmUgbWV0YWwuIEkgaGF2ZSBpdCB3
b3JraW5nIG9uIGFuCkhUUEMgd2hpY2ggbWFrZXMgMi0zCnJlY29yZGluZ3MgcGVyIGRheSwgd2l0
aG91dCBpc3N1ZXMuCgpPbiB0aGUgbGludXggbWVkaWEgbWFpbGluZyBsaXN0IEkgd2FzIHNhaWQg
dGhpcyBwcm9ibGVtIHdhcyBjb21tb24Kd2l0aCBhbGwgdHVuZXIgY2FyZHMsCm1vcmUgZ2VuZXJh
bGx5IHdpdGggYW55IGNhcmQgd2hpY2ggZ2VuZXJhdGVzIGxvdHMgb2YgaW50ZXJydXB0aW9ucyBh
bmQKdGhhdCBJIHNob3VsZCBiZXR0ZXIKZm9yZ2V0IGFib3V0IGl0LgoKCi0tIApKYXZpZXIgTWFy
Y2V0IDxqbWFyY2V0QGdtYWlsLmNvbT4KCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhl
bi5vcmcKaHR0cDovL2xpc3RzLnhlbi5vcmcveGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Tue Sep 18 15:19:39 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Sep 2012 15: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 1TDzaA-0002ps-Mk; Tue, 18 Sep 2012 15:19:26 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1TDza9-0002pn-1N
	for xen-devel@lists.xen.org; Tue, 18 Sep 2012 15:19:25 +0000
Received: from [85.158.138.51:13252] by server-4.bemta-3.messagelabs.com id
	E6/06-24831-CF098505; Tue, 18 Sep 2012 15:19:24 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1347981562!22968279!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1063 invoked from network); 18 Sep 2012 15:19:23 -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 Sep 2012 15:19:23 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 18 Sep 2012 16:19:22 +0100
Message-Id: <5058AD19020000780009C079@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 18 Sep 2012 16:19:21 +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] x86/ACPI: fix error indication from
 acpi_parse_madt_lapic_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

If the legacy APIC invocation of acpi_table_parse_madt() succeeds but
the x2APIC counterpart fails, this is regarded as failure by the
function, yet its return value would indicate success.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/arch/x86/acpi/boot.c
+++ b/xen/arch/x86/acpi/boot.c
@@ -452,7 +452,7 @@ static int __init acpi_parse_madt_lapic_
 	} else if (count < 0 || x2count < 0) {
 		printk(KERN_ERR PREFIX "Error parsing LAPIC entry\n");
 		/* TBD: Cleanup to allow fallback to MPS */
-		return count;
+		return count < 0 ? count : x2count;
 	}
 
 	count =
@@ -464,7 +464,7 @@ static int __init acpi_parse_madt_lapic_
 	if (count < 0 || x2count < 0) {
 		printk(KERN_ERR PREFIX "Error parsing LAPIC NMI entry\n");
 		/* TBD: Cleanup to allow fallback to MPS */
-		return count;
+		return count < 0 ? count : x2count;
 	}
 	return 0;
 }




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 18 15:19:39 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Sep 2012 15: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 1TDzaA-0002ps-Mk; Tue, 18 Sep 2012 15:19:26 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1TDza9-0002pn-1N
	for xen-devel@lists.xen.org; Tue, 18 Sep 2012 15:19:25 +0000
Received: from [85.158.138.51:13252] by server-4.bemta-3.messagelabs.com id
	E6/06-24831-CF098505; Tue, 18 Sep 2012 15:19:24 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1347981562!22968279!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1063 invoked from network); 18 Sep 2012 15:19:23 -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 Sep 2012 15:19:23 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 18 Sep 2012 16:19:22 +0100
Message-Id: <5058AD19020000780009C079@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 18 Sep 2012 16:19:21 +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] x86/ACPI: fix error indication from
 acpi_parse_madt_lapic_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

If the legacy APIC invocation of acpi_table_parse_madt() succeeds but
the x2APIC counterpart fails, this is regarded as failure by the
function, yet its return value would indicate success.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/arch/x86/acpi/boot.c
+++ b/xen/arch/x86/acpi/boot.c
@@ -452,7 +452,7 @@ static int __init acpi_parse_madt_lapic_
 	} else if (count < 0 || x2count < 0) {
 		printk(KERN_ERR PREFIX "Error parsing LAPIC entry\n");
 		/* TBD: Cleanup to allow fallback to MPS */
-		return count;
+		return count < 0 ? count : x2count;
 	}
 
 	count =
@@ -464,7 +464,7 @@ static int __init acpi_parse_madt_lapic_
 	if (count < 0 || x2count < 0) {
 		printk(KERN_ERR PREFIX "Error parsing LAPIC NMI entry\n");
 		/* TBD: Cleanup to allow fallback to MPS */
-		return count;
+		return count < 0 ? count : x2count;
 	}
 	return 0;
 }




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 18 15:25:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Sep 2012 15:25:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDzfO-0002yF-F7; Tue, 18 Sep 2012 15:24: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 1TDzfN-0002yA-8T
	for xen-devel@lists.xen.org; Tue, 18 Sep 2012 15:24:49 +0000
Received: from [85.158.137.99:21868] by server-12.bemta-3.messagelabs.com id
	63/F2-10384-04298505; Tue, 18 Sep 2012 15:24:48 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-3.tower-217.messagelabs.com!1347981887!13116120!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21509 invoked from network); 18 Sep 2012 15:24:47 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-3.tower-217.messagelabs.com with SMTP;
	18 Sep 2012 15:24:47 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 18 Sep 2012 16:24:47 +0100
Message-Id: <5058AE5E020000780009C07D@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 18 Sep 2012 16:24:46 +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] x86: properly check XEN_DOMCTL_ioport_mapping
 arguments for invalid range
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

In particular, the case of "np" being a very large value wasn't handled
correctly. The range start checks also were off by one (except that in
practice, when "np" is properly range checked, this would still have
been caught by the range end checks).

Also, is a GFN wrap in XEN_DOMCTL_memory_mapping really okay?

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/arch/x86/domctl.c
+++ b/xen/arch/x86/domctl.c
@@ -884,7 +884,7 @@ long arch_do_domctl(
         int found = 0;
 
         ret = -EINVAL;
-        if ( (np == 0) || (fgp > MAX_IOPORTS) || (fmp > MAX_IOPORTS) ||
+        if ( ((fgp | fmp | (np - 1)) >= MAX_IOPORTS) ||
             ((fgp + np) > MAX_IOPORTS) || ((fmp + np) > MAX_IOPORTS) )
         {
             printk(XENLOG_G_ERR




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 18 15:25:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Sep 2012 15:25:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDzfO-0002yF-F7; Tue, 18 Sep 2012 15:24: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 1TDzfN-0002yA-8T
	for xen-devel@lists.xen.org; Tue, 18 Sep 2012 15:24:49 +0000
Received: from [85.158.137.99:21868] by server-12.bemta-3.messagelabs.com id
	63/F2-10384-04298505; Tue, 18 Sep 2012 15:24:48 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-3.tower-217.messagelabs.com!1347981887!13116120!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21509 invoked from network); 18 Sep 2012 15:24:47 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-3.tower-217.messagelabs.com with SMTP;
	18 Sep 2012 15:24:47 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 18 Sep 2012 16:24:47 +0100
Message-Id: <5058AE5E020000780009C07D@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 18 Sep 2012 16:24:46 +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] x86: properly check XEN_DOMCTL_ioport_mapping
 arguments for invalid range
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

In particular, the case of "np" being a very large value wasn't handled
correctly. The range start checks also were off by one (except that in
practice, when "np" is properly range checked, this would still have
been caught by the range end checks).

Also, is a GFN wrap in XEN_DOMCTL_memory_mapping really okay?

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/arch/x86/domctl.c
+++ b/xen/arch/x86/domctl.c
@@ -884,7 +884,7 @@ long arch_do_domctl(
         int found = 0;
 
         ret = -EINVAL;
-        if ( (np == 0) || (fgp > MAX_IOPORTS) || (fmp > MAX_IOPORTS) ||
+        if ( ((fgp | fmp | (np - 1)) >= MAX_IOPORTS) ||
             ((fgp + np) > MAX_IOPORTS) || ((fmp + np) > MAX_IOPORTS) )
         {
             printk(XENLOG_G_ERR




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 18 15:26:33 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Sep 2012 15:26:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDzgp-00033i-UZ; Tue, 18 Sep 2012 15:26:19 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1TDzgo-00033Z-88
	for xen-devel@lists.xen.org; Tue, 18 Sep 2012 15:26:18 +0000
Received: from [85.158.139.83:38392] by server-2.bemta-5.messagelabs.com id
	63/F2-11456-99298505; Tue, 18 Sep 2012 15:26:17 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1347981975!30902921!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDc1Nzk4OQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1880 invoked from network); 18 Sep 2012 15:26:16 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-12.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 18 Sep 2012 15:26:16 -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 q8IFQ9rS017718
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 18 Sep 2012 15:26:10 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q8IFQ81a002843
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 18 Sep 2012 15:26:09 GMT
Received: from abhmt103.oracle.com (abhmt103.oracle.com [141.146.116.55])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q8IFQ8L8005569; Tue, 18 Sep 2012 10:26:08 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 18 Sep 2012 08:26:08 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 7B635402EF; Tue, 18 Sep 2012 11:15:19 -0400 (EDT)
Date: Tue, 18 Sep 2012 11:15:19 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Greg KH <gregkh@linuxfoundation.org>
Message-ID: <20120918151519.GB30940@phenom.dumpdata.com>
References: <505875B6020000780009C01D@nat28.tlf.novell.com>
	<20120918144230.GC19332@phenom.dumpdata.com>
	<20120918150649.GA24798@kroah.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120918150649.GA24798@kroah.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: linux-usb@vger.kernel.org, stern@rowland.harvard.edu,
	Jan Beulich <JBeulich@suse.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] EHCI/Xen: propagate controller reset
 information to hypervisor
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Sep 18, 2012 at 04:06:49PM +0100, Greg KH wrote:
> On Tue, Sep 18, 2012 at 10:42:30AM -0400, Konrad Rzeszutek Wilk wrote:
> > On Tue, Sep 18, 2012 at 12:23:02PM +0100, Jan Beulich wrote:
> > > Just like for the in-tree early console debug port driver, the
> > > hypervisor - when using a debug port based console - also needs to be
> > > told about controller resets, so it can suppress using and then
> > > re-initialize the debug port accordingly.
> > > 
> > > Other than the in-tree driver, the hypervisor driver actually cares
> > > about doing this only for the device where the debug is port actually
> > > in use, i.e. it needs to be told the coordinates of the device being
> > > reset (quite obviously, leveraging the addition done for that would
> > > likely benefit the in-tree driver too).
> > > 
> > > Signed-off-by: Jan Beulich <jbeulich@suse.com>
> > 
> > Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> > 
> > on the *xen* parts.
> 
> So, I'm guessing this should go in through the USB tree?  If there are
> no objections, I'll do that.

No objections. Thank you.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 18 15:26:33 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Sep 2012 15:26:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDzgp-00033i-UZ; Tue, 18 Sep 2012 15:26:19 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1TDzgo-00033Z-88
	for xen-devel@lists.xen.org; Tue, 18 Sep 2012 15:26:18 +0000
Received: from [85.158.139.83:38392] by server-2.bemta-5.messagelabs.com id
	63/F2-11456-99298505; Tue, 18 Sep 2012 15:26:17 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1347981975!30902921!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDc1Nzk4OQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1880 invoked from network); 18 Sep 2012 15:26:16 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-12.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 18 Sep 2012 15:26:16 -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 q8IFQ9rS017718
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 18 Sep 2012 15:26:10 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q8IFQ81a002843
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 18 Sep 2012 15:26:09 GMT
Received: from abhmt103.oracle.com (abhmt103.oracle.com [141.146.116.55])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q8IFQ8L8005569; Tue, 18 Sep 2012 10:26:08 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 18 Sep 2012 08:26:08 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 7B635402EF; Tue, 18 Sep 2012 11:15:19 -0400 (EDT)
Date: Tue, 18 Sep 2012 11:15:19 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Greg KH <gregkh@linuxfoundation.org>
Message-ID: <20120918151519.GB30940@phenom.dumpdata.com>
References: <505875B6020000780009C01D@nat28.tlf.novell.com>
	<20120918144230.GC19332@phenom.dumpdata.com>
	<20120918150649.GA24798@kroah.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120918150649.GA24798@kroah.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: linux-usb@vger.kernel.org, stern@rowland.harvard.edu,
	Jan Beulich <JBeulich@suse.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] EHCI/Xen: propagate controller reset
 information to hypervisor
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Sep 18, 2012 at 04:06:49PM +0100, Greg KH wrote:
> On Tue, Sep 18, 2012 at 10:42:30AM -0400, Konrad Rzeszutek Wilk wrote:
> > On Tue, Sep 18, 2012 at 12:23:02PM +0100, Jan Beulich wrote:
> > > Just like for the in-tree early console debug port driver, the
> > > hypervisor - when using a debug port based console - also needs to be
> > > told about controller resets, so it can suppress using and then
> > > re-initialize the debug port accordingly.
> > > 
> > > Other than the in-tree driver, the hypervisor driver actually cares
> > > about doing this only for the device where the debug is port actually
> > > in use, i.e. it needs to be told the coordinates of the device being
> > > reset (quite obviously, leveraging the addition done for that would
> > > likely benefit the in-tree driver too).
> > > 
> > > Signed-off-by: Jan Beulich <jbeulich@suse.com>
> > 
> > Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> > 
> > on the *xen* parts.
> 
> So, I'm guessing this should go in through the USB tree?  If there are
> no objections, I'll do that.

No objections. Thank you.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 18 15:26:44 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Sep 2012 15:26:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDzh3-000357-BA; Tue, 18 Sep 2012 15:26:33 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1TDzh2-00034r-H4
	for xen-devel@lists.xen.org; Tue, 18 Sep 2012 15:26:32 +0000
Received: from [85.158.143.99:30569] by server-3.bemta-4.messagelabs.com id
	04/EE-08232-7A298505; Tue, 18 Sep 2012 15:26:31 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1347981990!19618101!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19621 invoked from network); 18 Sep 2012 15:26:30 -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;
	18 Sep 2012 15:26:30 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 18 Sep 2012 16:26:30 +0100
Message-Id: <5058AEC6020000780009C081@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 18 Sep 2012 16:26:30 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part447541B6.0__="
Subject: [Xen-devel] [PATCH] ACPI: move tables.c fully into .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>
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.

--=__Part447541B6.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

The only non-init item was the space reserved for the initial tables,
but we can as well dynamically allocate that array.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/drivers/acpi/Makefile
+++ b/xen/drivers/acpi/Makefile
@@ -2,7 +2,7 @@ subdir-y +=3D tables
 subdir-y +=3D utilities
 subdir-$(x86) +=3D apei
=20
-obj-y +=3D tables.o
+obj-bin-y +=3D tables.init.o
 obj-y +=3D numa.o
 obj-y +=3D osl.o
 obj-y +=3D pmstat.o
--- a/xen/drivers/acpi/tables.c
+++ b/xen/drivers/acpi/tables.c
@@ -25,6 +25,8 @@
=20
 #include <xen/init.h>
 #include <xen/kernel.h>
+#include <xen/mm.h>
+#include <xen/pfn.h>
 #include <xen/smp.h>
 #include <xen/string.h>
 #include <xen/types.h>
@@ -41,8 +43,6 @@ mps_inti_flags_polarity[] =3D { "dfl", "hi
 static const char *__initdata
 mps_inti_flags_trigger[] =3D { "dfl", "edge", "res", "level" };
=20
-static struct acpi_table_desc initial_tables[ACPI_MAX_TABLES];
-
 static int acpi_apic_instance __initdata;
=20
 void __init acpi_table_print_madt_entry(struct acpi_subtable_header =
*header)
@@ -324,6 +324,11 @@ static void __init check_multiple_madt(v
=20
 int __init acpi_table_init(void)
 {
+	struct acpi_table_desc *initial_tables =3D
+		mfn_to_virt(alloc_boot_pages(PFN_UP(ACPI_MAX_TABLES *
+						    sizeof(*initial_tables)=
),
+					     1));
+
 	acpi_initialize_tables(initial_tables, ACPI_MAX_TABLES, 0);
 	check_multiple_madt();
 	return 0;




--=__Part447541B6.0__=
Content-Type: text/plain; name="ACPI-tables-init.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="ACPI-tables-init.patch"

ACPI: move tables.c fully into .init.*=0A=0AThe only non-init item was the =
space reserved for the initial tables,=0Abut we can as well dynamically =
allocate that array.=0A=0ASigned-off-by: Jan Beulich <jbeulich@suse.com>=0A=
=0A--- a/xen/drivers/acpi/Makefile=0A+++ b/xen/drivers/acpi/Makefile=0A@@ =
-2,7 +2,7 @@ subdir-y +=3D tables=0A subdir-y +=3D utilities=0A subdir-$(x8=
6) +=3D apei=0A =0A-obj-y +=3D tables.o=0A+obj-bin-y +=3D tables.init.o=0A =
obj-y +=3D numa.o=0A obj-y +=3D osl.o=0A obj-y +=3D pmstat.o=0A--- =
a/xen/drivers/acpi/tables.c=0A+++ b/xen/drivers/acpi/tables.c=0A@@ -25,6 =
+25,8 @@=0A =0A #include <xen/init.h>=0A #include <xen/kernel.h>=0A+#includ=
e <xen/mm.h>=0A+#include <xen/pfn.h>=0A #include <xen/smp.h>=0A #include =
<xen/string.h>=0A #include <xen/types.h>=0A@@ -41,8 +43,6 @@ mps_inti_flags=
_polarity[] =3D { "dfl", "hi=0A static const char *__initdata=0A mps_inti_f=
lags_trigger[] =3D { "dfl", "edge", "res", "level" };=0A =0A-static struct =
acpi_table_desc initial_tables[ACPI_MAX_TABLES];=0A-=0A static int =
acpi_apic_instance __initdata;=0A =0A void __init acpi_table_print_madt_ent=
ry(struct acpi_subtable_header *header)=0A@@ -324,6 +324,11 @@ static void =
__init check_multiple_madt(v=0A =0A int __init acpi_table_init(void)=0A =
{=0A+	struct acpi_table_desc *initial_tables =3D=0A+		mfn_to_virt=
(alloc_boot_pages(PFN_UP(ACPI_MAX_TABLES *=0A+					=
	    sizeof(*initial_tables)),=0A+					=
     1));=0A+=0A 	acpi_initialize_tables(initial_tables, ACPI_MAX_TAB=
LES, 0);=0A 	check_multiple_madt();=0A 	return 0;=0A
--=__Part447541B6.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

--=__Part447541B6.0__=--


From xen-devel-bounces@lists.xen.org Tue Sep 18 15:26:44 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Sep 2012 15:26:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDzh3-000357-BA; Tue, 18 Sep 2012 15:26:33 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1TDzh2-00034r-H4
	for xen-devel@lists.xen.org; Tue, 18 Sep 2012 15:26:32 +0000
Received: from [85.158.143.99:30569] by server-3.bemta-4.messagelabs.com id
	04/EE-08232-7A298505; Tue, 18 Sep 2012 15:26:31 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1347981990!19618101!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19621 invoked from network); 18 Sep 2012 15:26:30 -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;
	18 Sep 2012 15:26:30 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 18 Sep 2012 16:26:30 +0100
Message-Id: <5058AEC6020000780009C081@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 18 Sep 2012 16:26:30 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part447541B6.0__="
Subject: [Xen-devel] [PATCH] ACPI: move tables.c fully into .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>
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.

--=__Part447541B6.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

The only non-init item was the space reserved for the initial tables,
but we can as well dynamically allocate that array.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/drivers/acpi/Makefile
+++ b/xen/drivers/acpi/Makefile
@@ -2,7 +2,7 @@ subdir-y +=3D tables
 subdir-y +=3D utilities
 subdir-$(x86) +=3D apei
=20
-obj-y +=3D tables.o
+obj-bin-y +=3D tables.init.o
 obj-y +=3D numa.o
 obj-y +=3D osl.o
 obj-y +=3D pmstat.o
--- a/xen/drivers/acpi/tables.c
+++ b/xen/drivers/acpi/tables.c
@@ -25,6 +25,8 @@
=20
 #include <xen/init.h>
 #include <xen/kernel.h>
+#include <xen/mm.h>
+#include <xen/pfn.h>
 #include <xen/smp.h>
 #include <xen/string.h>
 #include <xen/types.h>
@@ -41,8 +43,6 @@ mps_inti_flags_polarity[] =3D { "dfl", "hi
 static const char *__initdata
 mps_inti_flags_trigger[] =3D { "dfl", "edge", "res", "level" };
=20
-static struct acpi_table_desc initial_tables[ACPI_MAX_TABLES];
-
 static int acpi_apic_instance __initdata;
=20
 void __init acpi_table_print_madt_entry(struct acpi_subtable_header =
*header)
@@ -324,6 +324,11 @@ static void __init check_multiple_madt(v
=20
 int __init acpi_table_init(void)
 {
+	struct acpi_table_desc *initial_tables =3D
+		mfn_to_virt(alloc_boot_pages(PFN_UP(ACPI_MAX_TABLES *
+						    sizeof(*initial_tables)=
),
+					     1));
+
 	acpi_initialize_tables(initial_tables, ACPI_MAX_TABLES, 0);
 	check_multiple_madt();
 	return 0;




--=__Part447541B6.0__=
Content-Type: text/plain; name="ACPI-tables-init.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="ACPI-tables-init.patch"

ACPI: move tables.c fully into .init.*=0A=0AThe only non-init item was the =
space reserved for the initial tables,=0Abut we can as well dynamically =
allocate that array.=0A=0ASigned-off-by: Jan Beulich <jbeulich@suse.com>=0A=
=0A--- a/xen/drivers/acpi/Makefile=0A+++ b/xen/drivers/acpi/Makefile=0A@@ =
-2,7 +2,7 @@ subdir-y +=3D tables=0A subdir-y +=3D utilities=0A subdir-$(x8=
6) +=3D apei=0A =0A-obj-y +=3D tables.o=0A+obj-bin-y +=3D tables.init.o=0A =
obj-y +=3D numa.o=0A obj-y +=3D osl.o=0A obj-y +=3D pmstat.o=0A--- =
a/xen/drivers/acpi/tables.c=0A+++ b/xen/drivers/acpi/tables.c=0A@@ -25,6 =
+25,8 @@=0A =0A #include <xen/init.h>=0A #include <xen/kernel.h>=0A+#includ=
e <xen/mm.h>=0A+#include <xen/pfn.h>=0A #include <xen/smp.h>=0A #include =
<xen/string.h>=0A #include <xen/types.h>=0A@@ -41,8 +43,6 @@ mps_inti_flags=
_polarity[] =3D { "dfl", "hi=0A static const char *__initdata=0A mps_inti_f=
lags_trigger[] =3D { "dfl", "edge", "res", "level" };=0A =0A-static struct =
acpi_table_desc initial_tables[ACPI_MAX_TABLES];=0A-=0A static int =
acpi_apic_instance __initdata;=0A =0A void __init acpi_table_print_madt_ent=
ry(struct acpi_subtable_header *header)=0A@@ -324,6 +324,11 @@ static void =
__init check_multiple_madt(v=0A =0A int __init acpi_table_init(void)=0A =
{=0A+	struct acpi_table_desc *initial_tables =3D=0A+		mfn_to_virt=
(alloc_boot_pages(PFN_UP(ACPI_MAX_TABLES *=0A+					=
	    sizeof(*initial_tables)),=0A+					=
     1));=0A+=0A 	acpi_initialize_tables(initial_tables, ACPI_MAX_TAB=
LES, 0);=0A 	check_multiple_madt();=0A 	return 0;=0A
--=__Part447541B6.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

--=__Part447541B6.0__=--


From xen-devel-bounces@lists.xen.org Tue Sep 18 15:30:18 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Sep 2012 15:30:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDzkW-0003NF-26; Tue, 18 Sep 2012 15:30:08 +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 1TDzkU-0003N3-MK
	for xen-devel@lists.xensource.com; Tue, 18 Sep 2012 15:30:07 +0000
Received: from [85.158.143.35:49032] by server-1.bemta-4.messagelabs.com id
	C5/05-12504-E7398505; Tue, 18 Sep 2012 15:30:06 +0000
X-Env-Sender: Christoph.Egger@amd.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1347982203!7781313!1
X-Originating-IP: [216.32.180.16]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 537 invoked from network); 18 Sep 2012 15:30:04 -0000
Received: from va3ehsobe006.messaging.microsoft.com (HELO
	va3outboundpool.messaging.microsoft.com) (216.32.180.16)
	by server-9.tower-21.messagelabs.com with AES128-SHA encrypted SMTP;
	18 Sep 2012 15:30:04 -0000
Received: from mail83-va3-R.bigfish.com (10.7.14.239) by
	VA3EHSOBE012.bigfish.com (10.7.40.62) with Microsoft SMTP Server id
	14.1.225.23; Tue, 18 Sep 2012 15:30:03 +0000
Received: from mail83-va3 (localhost [127.0.0.1])	by mail83-va3-R.bigfish.com
	(Postfix) with ESMTP id 3226C3C00A9;
	Tue, 18 Sep 2012 15:30:03 +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: -2
X-BigFish: VPS-2(zzbb2dI98dI1432Id6f1izz1202h1d1ah1d2ahzz8275bhz2dh668h839he5bhf0ah107ah1288h12a5h12a9h12bdh1155h)
Received: from mail83-va3 (localhost.localdomain [127.0.0.1]) by mail83-va3
	(MessageSwitch) id 134798220196004_14202;
	Tue, 18 Sep 2012 15:30:01 +0000 (UTC)
Received: from VA3EHSMHS010.bigfish.com (unknown [10.7.14.237])	by
	mail83-va3.bigfish.com (Postfix) with ESMTP id 09B3C60045;
	Tue, 18 Sep 2012 15:30:01 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	VA3EHSMHS010.bigfish.com (10.7.99.20) with Microsoft SMTP Server id
	14.1.225.23; Tue, 18 Sep 2012 15:29:59 +0000
X-WSS-ID: 0MAJXPV-02-5MU-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 2EC89FCC001;	Tue, 18 Sep 2012 10:29:54 -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, 18 Sep 2012 10:29:57 -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, 18 Sep 2012 10:29:55 -0500
Received: from rhodium.osrc.amd.com (165.204.15.173) by storexhtp02.amd.com
	(172.24.4.4) with Microsoft SMTP Server id 8.3.213.0; Tue, 18 Sep 2012
	11:29:54 -0400
Message-ID: <50589370.8050605@amd.com>
Date: Tue, 18 Sep 2012 17:29: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: "Liu, Jinsong" <jinsong.liu@intel.com>
References: <DE8DF0795D48FD4CA783C40EC829233532F43A@SHSMSX101.ccr.corp.intel.com>
In-Reply-To: <DE8DF0795D48FD4CA783C40EC829233532F43A@SHSMSX101.ccr.corp.intel.com>
X-OriginatorOrg: amd.com
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"keir@xen.org" <keir@xen.org>,
	"Ian.Campbell@citrix.com" <Ian.Campbell@citrix.com>,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH 4/5] Xen/MCE: Abort live migration when vMCE
 occur
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


Does this patch still apply after c/s 25919:62de66cec48a?

Christoph


On 09/18/12 15:16, Liu, Jinsong wrote:

> Xen/MCE: Abort live migration when vMCE occur
> 
> This patch monitor the critical area of live migration (from vMCE point of view,
> the copypages stage of migration is the critical area while other areas are not).
> 
> If a vMCE occur at the critical area of live migration, abort and try migration later.
> 
> Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>
> 
> diff -r f843ac6f93c9 tools/libxc/xc_domain.c
> --- a/tools/libxc/xc_domain.c	Wed Sep 19 01:21:18 2012 +0800
> +++ b/tools/libxc/xc_domain.c	Wed Sep 19 03:31:30 2012 +0800
> @@ -283,6 +283,37 @@
>      return ret;
>  }
>  
> +/* Start vmce monitor */
> +int xc_domain_vmce_monitor_strat(xc_interface *xch,
> +                                 uint32_t domid)
> +{
> +    int ret;
> +    DECLARE_DOMCTL;
> +
> +    domctl.cmd = XEN_DOMCTL_vmce_monitor_start;
> +    domctl.domain = (domid_t)domid;
> +    ret = do_domctl(xch, &domctl);
> +
> +    return ret ? -1 : 0;
> +}
> +
> +/* End vmce monitor */
> +int xc_domain_vmce_monitor_end(xc_interface *xch,
> +                               uint32_t domid,
> +                               signed char *vmce_while_monitor)
> +{
> +    int ret;
> +    DECLARE_DOMCTL;
> +
> +    domctl.cmd = XEN_DOMCTL_vmce_monitor_end;
> +    domctl.domain = (domid_t)domid;
> +    ret = do_domctl(xch, &domctl);
> +    if ( !ret )
> +        *vmce_while_monitor = domctl.u.vmce_monitor.vmce_while_monitor;
> +
> +    return ret ? -1 : 0;
> +}
> +
>  /* get info from hvm guest for save */
>  int xc_domain_hvm_getcontext(xc_interface *xch,
>                               uint32_t domid,
> diff -r f843ac6f93c9 tools/libxc/xc_domain_save.c
> --- a/tools/libxc/xc_domain_save.c	Wed Sep 19 01:21:18 2012 +0800
> +++ b/tools/libxc/xc_domain_save.c	Wed Sep 19 03:31:30 2012 +0800
> @@ -895,6 +895,8 @@
>       */
>      int compressing = 0;
>  
> +    signed char vmce_while_monitor = 0;
> +
>      int completed = 0;
>  
>      if ( hvm && !callbacks->switch_qemu_logdirty )
> @@ -1109,6 +1111,12 @@
>          goto out;
>      }
>  
> +    if ( xc_domain_vmce_monitor_strat(xch, dom) )
> +    {
> +        PERROR("Error when start vmce monitor\n");
> +        goto out;
> +    }
> +
>    copypages:
>  #define wrexact(fd, buf, len) write_buffer(xch, last_iter, ob, (fd), (buf), (len))
>  #define wruncached(fd, live, buf, len) write_uncached(xch, last_iter, ob, (fd), (buf), (len))
> @@ -1571,6 +1579,17 @@
>  
>      DPRINTF("All memory is saved\n");
>  
> +    if ( xc_domain_vmce_monitor_end(xch, dom, &vmce_while_monitor) )
> +    {
> +        PERROR("Error when end vmce monitor\n");
> +        goto out;
> +    }
> +    else if ( vmce_while_monitor == -1 )
> +    {
> +        fprintf(stderr, "vMCE occurred, abort this time and try later.\n");
> +        goto out;
> +    }
> +
>      /* After last_iter, buffer the rest of pagebuf & tailbuf data into a
>       * separate output buffer and flush it after the compressed page chunks.
>       */
> diff -r f843ac6f93c9 tools/libxc/xenctrl.h
> --- a/tools/libxc/xenctrl.h	Wed Sep 19 01:21:18 2012 +0800
> +++ b/tools/libxc/xenctrl.h	Wed Sep 19 03:31:30 2012 +0800
> @@ -571,6 +571,26 @@
>                            xc_domaininfo_t *info);
>  
>  /**
> + * This function start monitor vmce event.
> + * @parm xch a handle to an open hypervisor interface
> + * @parm domid the domain id monitored
> + * @return 0 on success, -1 on failure
> + */
> +int xc_domain_vmce_monitor_strat(xc_interface *xch,
> +                                 uint32_t domid);
> +
> +/**
> + * This function end monitor vmce event
> + * @parm xch a handle to an open hypervisor interface
> + * @parm domid the domain id monitored
> + * @parm vmce_while_migrate a pointer return whether vMCE occur when migrate 
> + * @return 0 on success, -1 on failure
> + */
> +int xc_domain_vmce_monitor_end(xc_interface *xch,
> +                               uint32_t domid,
> +                               signed char *vmce_while_monitor);
> +
> +/**
>   * This function returns information about the context of a hvm domain
>   * @parm xch a handle to an open hypervisor interface
>   * @parm domid the domain to get information from
> diff -r f843ac6f93c9 xen/arch/x86/cpu/mcheck/mce_intel.c
> --- a/xen/arch/x86/cpu/mcheck/mce_intel.c	Wed Sep 19 01:21:18 2012 +0800
> +++ b/xen/arch/x86/cpu/mcheck/mce_intel.c	Wed Sep 19 03:31:30 2012 +0800
> @@ -596,6 +596,12 @@
>                      goto vmce_failed;
>                  }
>  
> +                if ( unlikely(d->arch.vmce_monitor) )
> +                {
> +                    /* vMCE occur when guest migration */
> +                    d->arch.vmce_monitor = -1;
> +                }
> +
>                  /* We will inject vMCE to DOMU*/
>                  if ( inject_vmce(d) < 0 )
>                  {
> diff -r f843ac6f93c9 xen/arch/x86/domctl.c
> --- a/xen/arch/x86/domctl.c	Wed Sep 19 01:21:18 2012 +0800
> +++ b/xen/arch/x86/domctl.c	Wed Sep 19 03:31:30 2012 +0800
> @@ -1514,6 +1514,40 @@
>      }
>      break;
>  
> +    case XEN_DOMCTL_vmce_monitor_start:
> +    {
> +        struct domain *d;
> +
> +        d = rcu_lock_domain_by_id(domctl->domain);
> +        if ( d != NULL )
> +        {
> +            d->arch.vmce_monitor = 1;
> +            rcu_unlock_domain(d);
> +        }
> +        else
> +            ret = -ESRCH;
> +    }
> +    break;
> +
> +    case XEN_DOMCTL_vmce_monitor_end:
> +    {
> +        struct domain *d;
> +
> +        d = rcu_lock_domain_by_id(domctl->domain);
> +        if ( d != NULL)
> +        {
> +            domctl->u.vmce_monitor.vmce_while_monitor =
> +                                      d->arch.vmce_monitor;
> +            d->arch.vmce_monitor = 0;
> +            rcu_unlock_domain(d);
> +            if ( copy_to_guest(u_domctl, domctl, 1) )
> +                ret = -EFAULT;
> +        }
> +        else
> +            ret = -ESRCH;
> +    }
> +    break;
> +
>      default:
>          ret = iommu_do_domctl(domctl, u_domctl);
>          break;
> diff -r f843ac6f93c9 xen/include/asm-x86/domain.h
> --- a/xen/include/asm-x86/domain.h	Wed Sep 19 01:21:18 2012 +0800
> +++ b/xen/include/asm-x86/domain.h	Wed Sep 19 03:31:30 2012 +0800
> @@ -279,6 +279,11 @@
>      bool_t has_32bit_shinfo;
>      /* Domain cannot handle spurious page faults? */
>      bool_t suppress_spurious_page_faults;
> +    /* Monitoring guest memory copy of migration
> +     * = 0 - not monitoring
> +     * > 0 - monitoring
> +     * < 0 - vMCE occurred while monitoring */
> +    s8 vmce_monitor;
>  
>      /* Continuable domain_relinquish_resources(). */
>      enum {
> diff -r f843ac6f93c9 xen/include/public/domctl.h
> --- a/xen/include/public/domctl.h	Wed Sep 19 01:21:18 2012 +0800
> +++ b/xen/include/public/domctl.h	Wed Sep 19 03:31:30 2012 +0800
> @@ -828,6 +828,12 @@
>  typedef struct xen_domctl_set_access_required xen_domctl_set_access_required_t;
>  DEFINE_XEN_GUEST_HANDLE(xen_domctl_set_access_required_t);
>  
> +struct xen_domctl_vmce_monitor {
> +    signed char vmce_while_monitor;
> +};
> +typedef struct xen_domctl_vmce_monitor xen_domctl_vmce_monitor_t;
> +DEFINE_XEN_GUEST_HANDLE(xen_domctl_vmce_monitor_t);
> +
>  struct xen_domctl {
>      uint32_t cmd;
>  #define XEN_DOMCTL_createdomain                   1
> @@ -893,6 +899,8 @@
>  #define XEN_DOMCTL_set_access_required           64
>  #define XEN_DOMCTL_audit_p2m                     65
>  #define XEN_DOMCTL_set_virq_handler              66
> +#define XEN_DOMCTL_vmce_monitor_start            67
> +#define XEN_DOMCTL_vmce_monitor_end              68
>  #define XEN_DOMCTL_gdbsx_guestmemio            1000
>  #define XEN_DOMCTL_gdbsx_pausevcpu             1001
>  #define XEN_DOMCTL_gdbsx_unpausevcpu           1002
> @@ -947,6 +955,7 @@
>          struct xen_domctl_set_access_required access_required;
>          struct xen_domctl_audit_p2m         audit_p2m;
>          struct xen_domctl_set_virq_handler  set_virq_handler;
> +        struct xen_domctl_vmce_monitor      vmce_monitor;
>          struct xen_domctl_gdbsx_memio       gdbsx_guest_memio;
>          struct xen_domctl_gdbsx_pauseunp_vcpu gdbsx_pauseunp_vcpu;
>          struct xen_domctl_gdbsx_domstatus   gdbsx_domstatus;



-- 
---to satisfy European Law for business letters:
Advanced Micro Devices GmbH
Einsteinring 24, 85689 Dornach b. Muenchen
Geschaeftsfuehrer: Alberto Bozzo
Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen
Registergericht Muenchen, HRB Nr. 43632


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 18 15:30:18 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Sep 2012 15:30:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDzkW-0003NF-26; Tue, 18 Sep 2012 15:30:08 +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 1TDzkU-0003N3-MK
	for xen-devel@lists.xensource.com; Tue, 18 Sep 2012 15:30:07 +0000
Received: from [85.158.143.35:49032] by server-1.bemta-4.messagelabs.com id
	C5/05-12504-E7398505; Tue, 18 Sep 2012 15:30:06 +0000
X-Env-Sender: Christoph.Egger@amd.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1347982203!7781313!1
X-Originating-IP: [216.32.180.16]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 537 invoked from network); 18 Sep 2012 15:30:04 -0000
Received: from va3ehsobe006.messaging.microsoft.com (HELO
	va3outboundpool.messaging.microsoft.com) (216.32.180.16)
	by server-9.tower-21.messagelabs.com with AES128-SHA encrypted SMTP;
	18 Sep 2012 15:30:04 -0000
Received: from mail83-va3-R.bigfish.com (10.7.14.239) by
	VA3EHSOBE012.bigfish.com (10.7.40.62) with Microsoft SMTP Server id
	14.1.225.23; Tue, 18 Sep 2012 15:30:03 +0000
Received: from mail83-va3 (localhost [127.0.0.1])	by mail83-va3-R.bigfish.com
	(Postfix) with ESMTP id 3226C3C00A9;
	Tue, 18 Sep 2012 15:30:03 +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: -2
X-BigFish: VPS-2(zzbb2dI98dI1432Id6f1izz1202h1d1ah1d2ahzz8275bhz2dh668h839he5bhf0ah107ah1288h12a5h12a9h12bdh1155h)
Received: from mail83-va3 (localhost.localdomain [127.0.0.1]) by mail83-va3
	(MessageSwitch) id 134798220196004_14202;
	Tue, 18 Sep 2012 15:30:01 +0000 (UTC)
Received: from VA3EHSMHS010.bigfish.com (unknown [10.7.14.237])	by
	mail83-va3.bigfish.com (Postfix) with ESMTP id 09B3C60045;
	Tue, 18 Sep 2012 15:30:01 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	VA3EHSMHS010.bigfish.com (10.7.99.20) with Microsoft SMTP Server id
	14.1.225.23; Tue, 18 Sep 2012 15:29:59 +0000
X-WSS-ID: 0MAJXPV-02-5MU-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 2EC89FCC001;	Tue, 18 Sep 2012 10:29:54 -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, 18 Sep 2012 10:29:57 -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, 18 Sep 2012 10:29:55 -0500
Received: from rhodium.osrc.amd.com (165.204.15.173) by storexhtp02.amd.com
	(172.24.4.4) with Microsoft SMTP Server id 8.3.213.0; Tue, 18 Sep 2012
	11:29:54 -0400
Message-ID: <50589370.8050605@amd.com>
Date: Tue, 18 Sep 2012 17:29: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: "Liu, Jinsong" <jinsong.liu@intel.com>
References: <DE8DF0795D48FD4CA783C40EC829233532F43A@SHSMSX101.ccr.corp.intel.com>
In-Reply-To: <DE8DF0795D48FD4CA783C40EC829233532F43A@SHSMSX101.ccr.corp.intel.com>
X-OriginatorOrg: amd.com
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"keir@xen.org" <keir@xen.org>,
	"Ian.Campbell@citrix.com" <Ian.Campbell@citrix.com>,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH 4/5] Xen/MCE: Abort live migration when vMCE
 occur
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


Does this patch still apply after c/s 25919:62de66cec48a?

Christoph


On 09/18/12 15:16, Liu, Jinsong wrote:

> Xen/MCE: Abort live migration when vMCE occur
> 
> This patch monitor the critical area of live migration (from vMCE point of view,
> the copypages stage of migration is the critical area while other areas are not).
> 
> If a vMCE occur at the critical area of live migration, abort and try migration later.
> 
> Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>
> 
> diff -r f843ac6f93c9 tools/libxc/xc_domain.c
> --- a/tools/libxc/xc_domain.c	Wed Sep 19 01:21:18 2012 +0800
> +++ b/tools/libxc/xc_domain.c	Wed Sep 19 03:31:30 2012 +0800
> @@ -283,6 +283,37 @@
>      return ret;
>  }
>  
> +/* Start vmce monitor */
> +int xc_domain_vmce_monitor_strat(xc_interface *xch,
> +                                 uint32_t domid)
> +{
> +    int ret;
> +    DECLARE_DOMCTL;
> +
> +    domctl.cmd = XEN_DOMCTL_vmce_monitor_start;
> +    domctl.domain = (domid_t)domid;
> +    ret = do_domctl(xch, &domctl);
> +
> +    return ret ? -1 : 0;
> +}
> +
> +/* End vmce monitor */
> +int xc_domain_vmce_monitor_end(xc_interface *xch,
> +                               uint32_t domid,
> +                               signed char *vmce_while_monitor)
> +{
> +    int ret;
> +    DECLARE_DOMCTL;
> +
> +    domctl.cmd = XEN_DOMCTL_vmce_monitor_end;
> +    domctl.domain = (domid_t)domid;
> +    ret = do_domctl(xch, &domctl);
> +    if ( !ret )
> +        *vmce_while_monitor = domctl.u.vmce_monitor.vmce_while_monitor;
> +
> +    return ret ? -1 : 0;
> +}
> +
>  /* get info from hvm guest for save */
>  int xc_domain_hvm_getcontext(xc_interface *xch,
>                               uint32_t domid,
> diff -r f843ac6f93c9 tools/libxc/xc_domain_save.c
> --- a/tools/libxc/xc_domain_save.c	Wed Sep 19 01:21:18 2012 +0800
> +++ b/tools/libxc/xc_domain_save.c	Wed Sep 19 03:31:30 2012 +0800
> @@ -895,6 +895,8 @@
>       */
>      int compressing = 0;
>  
> +    signed char vmce_while_monitor = 0;
> +
>      int completed = 0;
>  
>      if ( hvm && !callbacks->switch_qemu_logdirty )
> @@ -1109,6 +1111,12 @@
>          goto out;
>      }
>  
> +    if ( xc_domain_vmce_monitor_strat(xch, dom) )
> +    {
> +        PERROR("Error when start vmce monitor\n");
> +        goto out;
> +    }
> +
>    copypages:
>  #define wrexact(fd, buf, len) write_buffer(xch, last_iter, ob, (fd), (buf), (len))
>  #define wruncached(fd, live, buf, len) write_uncached(xch, last_iter, ob, (fd), (buf), (len))
> @@ -1571,6 +1579,17 @@
>  
>      DPRINTF("All memory is saved\n");
>  
> +    if ( xc_domain_vmce_monitor_end(xch, dom, &vmce_while_monitor) )
> +    {
> +        PERROR("Error when end vmce monitor\n");
> +        goto out;
> +    }
> +    else if ( vmce_while_monitor == -1 )
> +    {
> +        fprintf(stderr, "vMCE occurred, abort this time and try later.\n");
> +        goto out;
> +    }
> +
>      /* After last_iter, buffer the rest of pagebuf & tailbuf data into a
>       * separate output buffer and flush it after the compressed page chunks.
>       */
> diff -r f843ac6f93c9 tools/libxc/xenctrl.h
> --- a/tools/libxc/xenctrl.h	Wed Sep 19 01:21:18 2012 +0800
> +++ b/tools/libxc/xenctrl.h	Wed Sep 19 03:31:30 2012 +0800
> @@ -571,6 +571,26 @@
>                            xc_domaininfo_t *info);
>  
>  /**
> + * This function start monitor vmce event.
> + * @parm xch a handle to an open hypervisor interface
> + * @parm domid the domain id monitored
> + * @return 0 on success, -1 on failure
> + */
> +int xc_domain_vmce_monitor_strat(xc_interface *xch,
> +                                 uint32_t domid);
> +
> +/**
> + * This function end monitor vmce event
> + * @parm xch a handle to an open hypervisor interface
> + * @parm domid the domain id monitored
> + * @parm vmce_while_migrate a pointer return whether vMCE occur when migrate 
> + * @return 0 on success, -1 on failure
> + */
> +int xc_domain_vmce_monitor_end(xc_interface *xch,
> +                               uint32_t domid,
> +                               signed char *vmce_while_monitor);
> +
> +/**
>   * This function returns information about the context of a hvm domain
>   * @parm xch a handle to an open hypervisor interface
>   * @parm domid the domain to get information from
> diff -r f843ac6f93c9 xen/arch/x86/cpu/mcheck/mce_intel.c
> --- a/xen/arch/x86/cpu/mcheck/mce_intel.c	Wed Sep 19 01:21:18 2012 +0800
> +++ b/xen/arch/x86/cpu/mcheck/mce_intel.c	Wed Sep 19 03:31:30 2012 +0800
> @@ -596,6 +596,12 @@
>                      goto vmce_failed;
>                  }
>  
> +                if ( unlikely(d->arch.vmce_monitor) )
> +                {
> +                    /* vMCE occur when guest migration */
> +                    d->arch.vmce_monitor = -1;
> +                }
> +
>                  /* We will inject vMCE to DOMU*/
>                  if ( inject_vmce(d) < 0 )
>                  {
> diff -r f843ac6f93c9 xen/arch/x86/domctl.c
> --- a/xen/arch/x86/domctl.c	Wed Sep 19 01:21:18 2012 +0800
> +++ b/xen/arch/x86/domctl.c	Wed Sep 19 03:31:30 2012 +0800
> @@ -1514,6 +1514,40 @@
>      }
>      break;
>  
> +    case XEN_DOMCTL_vmce_monitor_start:
> +    {
> +        struct domain *d;
> +
> +        d = rcu_lock_domain_by_id(domctl->domain);
> +        if ( d != NULL )
> +        {
> +            d->arch.vmce_monitor = 1;
> +            rcu_unlock_domain(d);
> +        }
> +        else
> +            ret = -ESRCH;
> +    }
> +    break;
> +
> +    case XEN_DOMCTL_vmce_monitor_end:
> +    {
> +        struct domain *d;
> +
> +        d = rcu_lock_domain_by_id(domctl->domain);
> +        if ( d != NULL)
> +        {
> +            domctl->u.vmce_monitor.vmce_while_monitor =
> +                                      d->arch.vmce_monitor;
> +            d->arch.vmce_monitor = 0;
> +            rcu_unlock_domain(d);
> +            if ( copy_to_guest(u_domctl, domctl, 1) )
> +                ret = -EFAULT;
> +        }
> +        else
> +            ret = -ESRCH;
> +    }
> +    break;
> +
>      default:
>          ret = iommu_do_domctl(domctl, u_domctl);
>          break;
> diff -r f843ac6f93c9 xen/include/asm-x86/domain.h
> --- a/xen/include/asm-x86/domain.h	Wed Sep 19 01:21:18 2012 +0800
> +++ b/xen/include/asm-x86/domain.h	Wed Sep 19 03:31:30 2012 +0800
> @@ -279,6 +279,11 @@
>      bool_t has_32bit_shinfo;
>      /* Domain cannot handle spurious page faults? */
>      bool_t suppress_spurious_page_faults;
> +    /* Monitoring guest memory copy of migration
> +     * = 0 - not monitoring
> +     * > 0 - monitoring
> +     * < 0 - vMCE occurred while monitoring */
> +    s8 vmce_monitor;
>  
>      /* Continuable domain_relinquish_resources(). */
>      enum {
> diff -r f843ac6f93c9 xen/include/public/domctl.h
> --- a/xen/include/public/domctl.h	Wed Sep 19 01:21:18 2012 +0800
> +++ b/xen/include/public/domctl.h	Wed Sep 19 03:31:30 2012 +0800
> @@ -828,6 +828,12 @@
>  typedef struct xen_domctl_set_access_required xen_domctl_set_access_required_t;
>  DEFINE_XEN_GUEST_HANDLE(xen_domctl_set_access_required_t);
>  
> +struct xen_domctl_vmce_monitor {
> +    signed char vmce_while_monitor;
> +};
> +typedef struct xen_domctl_vmce_monitor xen_domctl_vmce_monitor_t;
> +DEFINE_XEN_GUEST_HANDLE(xen_domctl_vmce_monitor_t);
> +
>  struct xen_domctl {
>      uint32_t cmd;
>  #define XEN_DOMCTL_createdomain                   1
> @@ -893,6 +899,8 @@
>  #define XEN_DOMCTL_set_access_required           64
>  #define XEN_DOMCTL_audit_p2m                     65
>  #define XEN_DOMCTL_set_virq_handler              66
> +#define XEN_DOMCTL_vmce_monitor_start            67
> +#define XEN_DOMCTL_vmce_monitor_end              68
>  #define XEN_DOMCTL_gdbsx_guestmemio            1000
>  #define XEN_DOMCTL_gdbsx_pausevcpu             1001
>  #define XEN_DOMCTL_gdbsx_unpausevcpu           1002
> @@ -947,6 +955,7 @@
>          struct xen_domctl_set_access_required access_required;
>          struct xen_domctl_audit_p2m         audit_p2m;
>          struct xen_domctl_set_virq_handler  set_virq_handler;
> +        struct xen_domctl_vmce_monitor      vmce_monitor;
>          struct xen_domctl_gdbsx_memio       gdbsx_guest_memio;
>          struct xen_domctl_gdbsx_pauseunp_vcpu gdbsx_pauseunp_vcpu;
>          struct xen_domctl_gdbsx_domstatus   gdbsx_domstatus;



-- 
---to satisfy European Law for business letters:
Advanced Micro Devices GmbH
Einsteinring 24, 85689 Dornach b. Muenchen
Geschaeftsfuehrer: Alberto Bozzo
Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen
Registergericht Muenchen, HRB Nr. 43632


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 18 15:30:59 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Sep 2012 15: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 1TDzlA-0003S0-L8; Tue, 18 Sep 2012 15:30:48 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <lukas@laukamp.me>) id 1TDzl9-0003Rn-PV
	for xen-devel@lists.xen.org; Tue, 18 Sep 2012 15:30:47 +0000
Received: from [85.158.143.35:32811] by server-3.bemta-4.messagelabs.com id
	14/45-08232-7A398505; Tue, 18 Sep 2012 15:30:47 +0000
X-Env-Sender: lukas@laukamp.me
X-Msg-Ref: server-10.tower-21.messagelabs.com!1347982245!10714739!1
X-Originating-IP: [5.9.218.245]
X-SpamReason: No, hits=0.2 required=7.0 tests=RCVD_ILLEGAL_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22521 invoked from network); 18 Sep 2012 15:30:45 -0000
Received: from mailer0.lippux.de (HELO mailer0.lippux.de) (5.9.218.245)
	by server-10.tower-21.messagelabs.com with SMTP;
	18 Sep 2012 15:30:45 -0000
Received: from localhost (localhost [127.0.0.1])
	by mailer0.lippux.de (Postfix) with ESMTP id 58C9D421FB8;
	Tue, 18 Sep 2012 17:30:45 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at mailer0.lippux.de
Received: from mailer0.lippux.de ([127.0.0.1])
	by localhost (mailer0.lippux.de [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id P3TJRiqcwmwr; Tue, 18 Sep 2012 17:30:44 +0200 (CEST)
Received: by mailer0.lippux.de (Postfix, from userid 33)
	id E38CB421FBA; Tue, 18 Sep 2012 17:30:44 +0200 (CEST)
To: Roger Pau Monne <roger.pau@citrix.com>
X-PHP-Originating-Script: 0:main.inc
MIME-Version: 1.0
Date: Tue, 18 Sep 2012 17:30:44 +0200
From: Lukas Laukamp <lukas@laukamp.me>
In-Reply-To: <50588852.2000809@citrix.com>
References: <b83b0a91d6f2612e2942f37270c8da21@laukamp.me>
	<50588852.2000809@citrix.com>
Message-ID: <8adfa05b91d5a8116454b319a07374f6@laukamp.me>
X-Sender: lukas@laukamp.me
User-Agent: Roundcube Webmail/0.7.1
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [User-Question] Xen 4.2 compilation hangs at
	stubdom directory
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
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 18.09.2012 16:42, schrieb Roger Pau Monne:
> Lukas Laukamp wrote:
>> Hello all,
>>
>> I know that here is not the best place to ask such a question but I
>> think that it's eventualy a problem of the source.
>>
>> I want to create deb packages of Xen 4.2 for Ubuntu 12.04 LTS. So I
>> created an build environment with pbuilder, installed all 
>> dependencies
>> and startet the compilation of Xen.
>>
>> So now the problem is that the compilation hangs without any reason 
>> in
>> the stubdom directory. So there is no error output or something like
>> this, it simply hangs and don't continue.
> I had some problems when trying to compile the stubdoms using make 
> 3.82,
> Olaf also had the same problem and sent the following fix, which 
> works
> for me:
>
> http://lists.xen.org/archives/html/xen-devel/2012-08/msg00985.html
>
> Can you try if applying that patch solves your problems?
>
>> As compiler I use GCC 4.6, with debhelper I created the Debian rules
>> files and I used the dist target.
>>
>> Is this a known issue or is it a problem of my configuration? Would 
>> be
>> greate to get help, Xen 4.2 is a real milestone and I can only say 
>> "Go
>> on guys, good work".
>>
>> Best Regards
>>
>> P.S. Sorry for my bad english
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xen.org
>> http://lists.xen.org/xen-devel
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
Hello Roger,

first I want to thank you for your fast response. I tried this patch 
but in the pbuilder environment it also don't work. So I tested the 
compilation directly on Ubuntu without a pbuilder environment and this 
worked very fine. I think it's a pbuilder related problem. I know that 
there is a pbuilder variant which uses qemu instead of simply schroots. 
I think it could be a problem of the environment which pbuilder creates.

The compilation directly on the system succeeded and I could boot Xen 
4.2 with all features the hardware supports.

I will see if I can test the pbuilder with qemu backend.

Best Regards


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 18 15:30:59 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Sep 2012 15: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 1TDzlA-0003S0-L8; Tue, 18 Sep 2012 15:30:48 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <lukas@laukamp.me>) id 1TDzl9-0003Rn-PV
	for xen-devel@lists.xen.org; Tue, 18 Sep 2012 15:30:47 +0000
Received: from [85.158.143.35:32811] by server-3.bemta-4.messagelabs.com id
	14/45-08232-7A398505; Tue, 18 Sep 2012 15:30:47 +0000
X-Env-Sender: lukas@laukamp.me
X-Msg-Ref: server-10.tower-21.messagelabs.com!1347982245!10714739!1
X-Originating-IP: [5.9.218.245]
X-SpamReason: No, hits=0.2 required=7.0 tests=RCVD_ILLEGAL_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22521 invoked from network); 18 Sep 2012 15:30:45 -0000
Received: from mailer0.lippux.de (HELO mailer0.lippux.de) (5.9.218.245)
	by server-10.tower-21.messagelabs.com with SMTP;
	18 Sep 2012 15:30:45 -0000
Received: from localhost (localhost [127.0.0.1])
	by mailer0.lippux.de (Postfix) with ESMTP id 58C9D421FB8;
	Tue, 18 Sep 2012 17:30:45 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at mailer0.lippux.de
Received: from mailer0.lippux.de ([127.0.0.1])
	by localhost (mailer0.lippux.de [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id P3TJRiqcwmwr; Tue, 18 Sep 2012 17:30:44 +0200 (CEST)
Received: by mailer0.lippux.de (Postfix, from userid 33)
	id E38CB421FBA; Tue, 18 Sep 2012 17:30:44 +0200 (CEST)
To: Roger Pau Monne <roger.pau@citrix.com>
X-PHP-Originating-Script: 0:main.inc
MIME-Version: 1.0
Date: Tue, 18 Sep 2012 17:30:44 +0200
From: Lukas Laukamp <lukas@laukamp.me>
In-Reply-To: <50588852.2000809@citrix.com>
References: <b83b0a91d6f2612e2942f37270c8da21@laukamp.me>
	<50588852.2000809@citrix.com>
Message-ID: <8adfa05b91d5a8116454b319a07374f6@laukamp.me>
X-Sender: lukas@laukamp.me
User-Agent: Roundcube Webmail/0.7.1
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [User-Question] Xen 4.2 compilation hangs at
	stubdom directory
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
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 18.09.2012 16:42, schrieb Roger Pau Monne:
> Lukas Laukamp wrote:
>> Hello all,
>>
>> I know that here is not the best place to ask such a question but I
>> think that it's eventualy a problem of the source.
>>
>> I want to create deb packages of Xen 4.2 for Ubuntu 12.04 LTS. So I
>> created an build environment with pbuilder, installed all 
>> dependencies
>> and startet the compilation of Xen.
>>
>> So now the problem is that the compilation hangs without any reason 
>> in
>> the stubdom directory. So there is no error output or something like
>> this, it simply hangs and don't continue.
> I had some problems when trying to compile the stubdoms using make 
> 3.82,
> Olaf also had the same problem and sent the following fix, which 
> works
> for me:
>
> http://lists.xen.org/archives/html/xen-devel/2012-08/msg00985.html
>
> Can you try if applying that patch solves your problems?
>
>> As compiler I use GCC 4.6, with debhelper I created the Debian rules
>> files and I used the dist target.
>>
>> Is this a known issue or is it a problem of my configuration? Would 
>> be
>> greate to get help, Xen 4.2 is a real milestone and I can only say 
>> "Go
>> on guys, good work".
>>
>> Best Regards
>>
>> P.S. Sorry for my bad english
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xen.org
>> http://lists.xen.org/xen-devel
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
Hello Roger,

first I want to thank you for your fast response. I tried this patch 
but in the pbuilder environment it also don't work. So I tested the 
compilation directly on Ubuntu without a pbuilder environment and this 
worked very fine. I think it's a pbuilder related problem. I know that 
there is a pbuilder variant which uses qemu instead of simply schroots. 
I think it could be a problem of the environment which pbuilder creates.

The compilation directly on the system succeeded and I could boot Xen 
4.2 with all features the hardware supports.

I will see if I can test the pbuilder with qemu backend.

Best Regards


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 18 15:38:55 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Sep 2012 15:38:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDzso-0003sD-T5; Tue, 18 Sep 2012 15:38: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 1TDzso-0003s8-0f
	for xen-devel@lists.xensource.com; Tue, 18 Sep 2012 15:38:42 +0000
Received: from [85.158.143.99:45409] by server-2.bemta-4.messagelabs.com id
	00/A7-06610-18598505; Tue, 18 Sep 2012 15:38:41 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1347982720!30841337!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDk5MjE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6203 invoked from network); 18 Sep 2012 15:38:40 -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 Sep 2012 15:38:40 -0000
X-IronPort-AV: E=Sophos;i="4.80,442,1344211200"; d="scan'208";a="14611505"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Sep 2012 15:38: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.279.1; Tue, 18 Sep 2012 16:38:34 +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 1TDzsf-0007go-Hb;
	Tue, 18 Sep 2012 15:38:33 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1TDzsf-0006L5-ES;
	Tue, 18 Sep 2012 16:38:33 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-13806-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Tue, 18 Sep 2012 16:38:33 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [qemu-upstream-4.2-testing test] 13806: 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 13806 qemu-upstream-4.2-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13806/

Failures :-/ but no regressions.

Tests which did not succeed,
including tests which could not be run:
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  9 guest-localmigrate fail never pass
 test-amd64-i386-xl-qemuu-win-vcpus1  9 guest-localmigrate      fail never pass
 test-amd64-amd64-qemuu-win   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64  9 guest-localmigrate      fail never pass
 test-i386-i386-qemuu-win     16 leak-check/check             fail   never pass
 test-i386-i386-xl-qemuu-win   9 guest-localmigrate           fail   never pass
 test-amd64-i386-qemuu-win-vcpus1 16 leak-check/check           fail never pass
 test-amd64-i386-xend-qemuu-winxpsp3 16 leak-check/check        fail never pass
 test-amd64-amd64-xl-qemuu-win  9 guest-localmigrate           fail  never pass
 test-amd64-i386-qemuu-win    16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail never pass
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass


jobs:
 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                           pass    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-win-vcpus1                             fail    
 test-amd64-i386-xl-qemuu-win-vcpus1                          fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-amd64-qemuu-win                                   fail    
 test-amd64-i386-qemuu-win                                    fail    
 test-i386-i386-qemuu-win                                     fail    
 test-amd64-amd64-xl-qemuu-win                                fail    
 test-i386-i386-xl-qemuu-win                                  fail    
 test-amd64-i386-xend-qemuu-winxpsp3                          fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 18 15:38:55 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Sep 2012 15:38:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDzso-0003sD-T5; Tue, 18 Sep 2012 15:38: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 1TDzso-0003s8-0f
	for xen-devel@lists.xensource.com; Tue, 18 Sep 2012 15:38:42 +0000
Received: from [85.158.143.99:45409] by server-2.bemta-4.messagelabs.com id
	00/A7-06610-18598505; Tue, 18 Sep 2012 15:38:41 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1347982720!30841337!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDk5MjE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6203 invoked from network); 18 Sep 2012 15:38:40 -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 Sep 2012 15:38:40 -0000
X-IronPort-AV: E=Sophos;i="4.80,442,1344211200"; d="scan'208";a="14611505"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Sep 2012 15:38: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.279.1; Tue, 18 Sep 2012 16:38:34 +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 1TDzsf-0007go-Hb;
	Tue, 18 Sep 2012 15:38:33 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1TDzsf-0006L5-ES;
	Tue, 18 Sep 2012 16:38:33 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-13806-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Tue, 18 Sep 2012 16:38:33 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [qemu-upstream-4.2-testing test] 13806: 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 13806 qemu-upstream-4.2-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13806/

Failures :-/ but no regressions.

Tests which did not succeed,
including tests which could not be run:
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  9 guest-localmigrate fail never pass
 test-amd64-i386-xl-qemuu-win-vcpus1  9 guest-localmigrate      fail never pass
 test-amd64-amd64-qemuu-win   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64  9 guest-localmigrate      fail never pass
 test-i386-i386-qemuu-win     16 leak-check/check             fail   never pass
 test-i386-i386-xl-qemuu-win   9 guest-localmigrate           fail   never pass
 test-amd64-i386-qemuu-win-vcpus1 16 leak-check/check           fail never pass
 test-amd64-i386-xend-qemuu-winxpsp3 16 leak-check/check        fail never pass
 test-amd64-amd64-xl-qemuu-win  9 guest-localmigrate           fail  never pass
 test-amd64-i386-qemuu-win    16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail never pass
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass


jobs:
 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                           pass    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-win-vcpus1                             fail    
 test-amd64-i386-xl-qemuu-win-vcpus1                          fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-amd64-qemuu-win                                   fail    
 test-amd64-i386-qemuu-win                                    fail    
 test-i386-i386-qemuu-win                                     fail    
 test-amd64-amd64-xl-qemuu-win                                fail    
 test-i386-i386-xl-qemuu-win                                  fail    
 test-amd64-i386-xend-qemuu-winxpsp3                          fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 18 15:39:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Sep 2012 15:39:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDzsx-0003sd-9T; Tue, 18 Sep 2012 15:38:51 +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 1TDzsv-0003sV-MB
	for xen-devel@lists.xen.org; Tue, 18 Sep 2012 15:38:49 +0000
Received: from [85.158.137.99:40306] by server-9.bemta-3.messagelabs.com id
	51/CB-15390-88598505; Tue, 18 Sep 2012 15:38:48 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-15.tower-217.messagelabs.com!1347982728!15819999!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-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28937 invoked from network); 18 Sep 2012 15:38:48 -0000
Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com)
	(74.125.83.45)
	by server-15.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Sep 2012 15:38:48 -0000
Received: by eeke53 with SMTP id e53so4205145eek.32
	for <xen-devel@lists.xen.org>; Tue, 18 Sep 2012 08:38:48 -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=LLnaJWKrlIeuEm7EZmNw45lH6w3cRPVe2B86JhjvOfk=;
	b=dTsuLOM51xN7arVkSHMloKr3gm+eXrYYaejVCAi01K6WZuI0CkkwnUtLwX+dqNM+rC
	Y/XHAf1rpuNreb4hKteUK+9GaGXgVkptWaLqt48gIC+was87p9tewjSYi4UwgukuecPy
	m3AttQvrnPXrX6V36SMdw+24/xQqFtdZ6Mw37RDIn4DpYBexz91PRXZCPjDZn0kZ1AE3
	EzLhAihCGOxlrQIPVqx39dHvrJO1GJ2KJYzR1aD34ci6uLiuOTrvRJnK1gsncI1RijEf
	XpraAdhVNcvhoFwnalHMkAYDvLoJGaPtnLKFaCW8tZCa6B4GljFgc5zUczXSxdKIEMy5
	uR3g==
Received: by 10.14.221.197 with SMTP id r45mr278631eep.41.1347982728068;
	Tue, 18 Sep 2012 08:38:48 -0700 (PDT)
Received: from [192.168.1.69] (host86-183-251-65.range86-183.btcentralplus.com.
	[86.183.251.65])
	by mx.google.com with ESMTPS id k49sm37262923een.4.2012.09.18.08.38.46
	(version=SSLv3 cipher=OTHER); Tue, 18 Sep 2012 08:38:47 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Tue, 18 Sep 2012 16:38:44 +0100
From: Keir Fraser <keir.xen@gmail.com>
To: Jan Beulich <JBeulich@suse.com>,
	xen-devel <xen-devel@lists.xen.org>
Message-ID: <CC7E5414.3F132%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [PATCH] x86/ACPI: fix error indication from
	acpi_parse_madt_lapic_entries()
Thread-Index: Ac2Vs6+Euy/Vv0By5EO/sGokILimxw==
In-Reply-To: <5058AD19020000780009C079@nat28.tlf.novell.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] [PATCH] x86/ACPI: fix error indication from
 acpi_parse_madt_lapic_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 18/09/2012 16:19, "Jan Beulich" <JBeulich@suse.com> wrote:

> If the legacy APIC invocation of acpi_table_parse_madt() succeeds but
> the x2APIC counterpart fails, this is regarded as failure by the
> function, yet its return value would indicate success.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Acked-by: Keir Fraser <keir@xen.org>

> --- a/xen/arch/x86/acpi/boot.c
> +++ b/xen/arch/x86/acpi/boot.c
> @@ -452,7 +452,7 @@ static int __init acpi_parse_madt_lapic_
> } else if (count < 0 || x2count < 0) {
> printk(KERN_ERR PREFIX "Error parsing LAPIC entry\n");
> /* TBD: Cleanup to allow fallback to MPS */
> -  return count;
> +  return count < 0 ? count : x2count;
> }
>  
> count =
> @@ -464,7 +464,7 @@ static int __init acpi_parse_madt_lapic_
> if (count < 0 || x2count < 0) {
> printk(KERN_ERR PREFIX "Error parsing LAPIC NMI entry\n");
> /* TBD: Cleanup to allow fallback to MPS */
> -  return count;
> +  return count < 0 ? count : x2count;
> }
> return 0;
>  }
> 
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 18 15:39:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Sep 2012 15:39:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDzsx-0003sd-9T; Tue, 18 Sep 2012 15:38:51 +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 1TDzsv-0003sV-MB
	for xen-devel@lists.xen.org; Tue, 18 Sep 2012 15:38:49 +0000
Received: from [85.158.137.99:40306] by server-9.bemta-3.messagelabs.com id
	51/CB-15390-88598505; Tue, 18 Sep 2012 15:38:48 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-15.tower-217.messagelabs.com!1347982728!15819999!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-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28937 invoked from network); 18 Sep 2012 15:38:48 -0000
Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com)
	(74.125.83.45)
	by server-15.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Sep 2012 15:38:48 -0000
Received: by eeke53 with SMTP id e53so4205145eek.32
	for <xen-devel@lists.xen.org>; Tue, 18 Sep 2012 08:38:48 -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=LLnaJWKrlIeuEm7EZmNw45lH6w3cRPVe2B86JhjvOfk=;
	b=dTsuLOM51xN7arVkSHMloKr3gm+eXrYYaejVCAi01K6WZuI0CkkwnUtLwX+dqNM+rC
	Y/XHAf1rpuNreb4hKteUK+9GaGXgVkptWaLqt48gIC+was87p9tewjSYi4UwgukuecPy
	m3AttQvrnPXrX6V36SMdw+24/xQqFtdZ6Mw37RDIn4DpYBexz91PRXZCPjDZn0kZ1AE3
	EzLhAihCGOxlrQIPVqx39dHvrJO1GJ2KJYzR1aD34ci6uLiuOTrvRJnK1gsncI1RijEf
	XpraAdhVNcvhoFwnalHMkAYDvLoJGaPtnLKFaCW8tZCa6B4GljFgc5zUczXSxdKIEMy5
	uR3g==
Received: by 10.14.221.197 with SMTP id r45mr278631eep.41.1347982728068;
	Tue, 18 Sep 2012 08:38:48 -0700 (PDT)
Received: from [192.168.1.69] (host86-183-251-65.range86-183.btcentralplus.com.
	[86.183.251.65])
	by mx.google.com with ESMTPS id k49sm37262923een.4.2012.09.18.08.38.46
	(version=SSLv3 cipher=OTHER); Tue, 18 Sep 2012 08:38:47 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Tue, 18 Sep 2012 16:38:44 +0100
From: Keir Fraser <keir.xen@gmail.com>
To: Jan Beulich <JBeulich@suse.com>,
	xen-devel <xen-devel@lists.xen.org>
Message-ID: <CC7E5414.3F132%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [PATCH] x86/ACPI: fix error indication from
	acpi_parse_madt_lapic_entries()
Thread-Index: Ac2Vs6+Euy/Vv0By5EO/sGokILimxw==
In-Reply-To: <5058AD19020000780009C079@nat28.tlf.novell.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] [PATCH] x86/ACPI: fix error indication from
 acpi_parse_madt_lapic_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 18/09/2012 16:19, "Jan Beulich" <JBeulich@suse.com> wrote:

> If the legacy APIC invocation of acpi_table_parse_madt() succeeds but
> the x2APIC counterpart fails, this is regarded as failure by the
> function, yet its return value would indicate success.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Acked-by: Keir Fraser <keir@xen.org>

> --- a/xen/arch/x86/acpi/boot.c
> +++ b/xen/arch/x86/acpi/boot.c
> @@ -452,7 +452,7 @@ static int __init acpi_parse_madt_lapic_
> } else if (count < 0 || x2count < 0) {
> printk(KERN_ERR PREFIX "Error parsing LAPIC entry\n");
> /* TBD: Cleanup to allow fallback to MPS */
> -  return count;
> +  return count < 0 ? count : x2count;
> }
>  
> count =
> @@ -464,7 +464,7 @@ static int __init acpi_parse_madt_lapic_
> if (count < 0 || x2count < 0) {
> printk(KERN_ERR PREFIX "Error parsing LAPIC NMI entry\n");
> /* TBD: Cleanup to allow fallback to MPS */
> -  return count;
> +  return count < 0 ? count : x2count;
> }
> return 0;
>  }
> 
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 18 15:40:23 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Sep 2012 15:40:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDzuE-00040n-Oj; Tue, 18 Sep 2012 15:40:10 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1TDzuC-00040D-P3
	for xen-devel@lists.xen.org; Tue, 18 Sep 2012 15:40:09 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1347982802!4522097!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-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6068 invoked from network); 18 Sep 2012 15:40:02 -0000
Received: from mail-ey0-f173.google.com (HELO mail-ey0-f173.google.com)
	(209.85.215.173)
	by server-15.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Sep 2012 15:40:02 -0000
Received: by eaac13 with SMTP id c13so2955159eaa.32
	for <xen-devel@lists.xen.org>; Tue, 18 Sep 2012 08:40: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:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=H98mCgu7fItIe2N3OXZgcYN20REJLdU/YuR9sZP4P1c=;
	b=VzAelndqOAGVv+qkJFpDtiDPmX7PAh100iHiWc5we1fGol/v0uwXSejNlt68NU8HIr
	JTCjEib/+iXdX97Mit+M5c7HrruWLyXIEL3WqCRnbrQ5rmXPan2lVTAZNtSBrGL7C+EG
	CTAfuW8EtpnFn8HUeI/VeXw2klklRG2TrsQ/f7OAAhX4+LTX9EheWw9jrNC1exBmivd9
	eDrmCFOU3HvdOT0BjZnHOqHbnUvxbPyemxA68L7/3c1EXfWWf3N0okzbB0V48ja3/pcj
	jWGdWSa/6cvV5vXOllVfRm5dZStjuXGfiZ3MNH0H6lre3Ty9R+M9EW83pvPnTxSEIirM
	ntHQ==
Received: by 10.14.172.193 with SMTP id t41mr323727eel.25.1347982802315;
	Tue, 18 Sep 2012 08:40:02 -0700 (PDT)
Received: from [192.168.1.69] (host86-183-251-65.range86-183.btcentralplus.com.
	[86.183.251.65])
	by mx.google.com with ESMTPS id h42sm37268103eem.5.2012.09.18.08.40.00
	(version=SSLv3 cipher=OTHER); Tue, 18 Sep 2012 08:40:01 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Tue, 18 Sep 2012 16:39:58 +0100
From: Keir Fraser <keir.xen@gmail.com>
To: Jan Beulich <JBeulich@suse.com>,
	xen-devel <xen-devel@lists.xen.org>
Message-ID: <CC7E545E.3F133%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [PATCH] x86: properly check
	XEN_DOMCTL_ioport_mapping arguments for invalid range
Thread-Index: Ac2Vs9ugS1hhkqxbxEq3Iwh3acw0pw==
In-Reply-To: <5058AE5E020000780009C07D@nat28.tlf.novell.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] [PATCH] x86: properly check
 XEN_DOMCTL_ioport_mapping arguments for invalid range
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 18/09/2012 16:24, "Jan Beulich" <JBeulich@suse.com> wrote:

> In particular, the case of "np" being a very large value wasn't handled
> correctly. The range start checks also were off by one (except that in
> practice, when "np" is properly range checked, this would still have
> been caught by the range end checks).
> 
> Also, is a GFN wrap in XEN_DOMCTL_memory_mapping really okay?

Probably worth fixing?

> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Acked-by: Keir Fraser <keir@xen.org>

> --- a/xen/arch/x86/domctl.c
> +++ b/xen/arch/x86/domctl.c
> @@ -884,7 +884,7 @@ long arch_do_domctl(
>          int found = 0;
>  
>          ret = -EINVAL;
> -        if ( (np == 0) || (fgp > MAX_IOPORTS) || (fmp > MAX_IOPORTS) ||
> +        if ( ((fgp | fmp | (np - 1)) >= MAX_IOPORTS) ||
>              ((fgp + np) > MAX_IOPORTS) || ((fmp + np) > MAX_IOPORTS) )
>          {
>              printk(XENLOG_G_ERR
> 
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Sep 18 15:40:23 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Sep 2012 15:40:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TDzuE-00040n-Oj; Tue, 18 Sep 2012 15:40:10 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1TDzuC-00040D-P3
	for xen-devel@lists.xen.org; Tue, 18 Sep 2012 15:40:09 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1347982802!4522097!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-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6068 invoked from network); 18 Sep 2012 15:40:02 -0000
Received: from mail-ey0-f173.google.com (HELO mail-ey0-f173.google.com)
	(209.85.215.173)
	by server-15.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Sep 2012 15:40:02 -0000
Received: by eaac13 with SMTP id c13so2955159eaa.32
	for <xen-devel@lists.xen.org>; Tue, 18 Sep 2012 08:40: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:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=H98mCgu7fItIe2N3OXZgcYN20REJLdU/YuR9sZP4P1c=;
	b=VzAelndqOAGVv+qkJFpDtiDPmX7PAh100iHiWc5we1fGol/v0uwXSejNlt68NU8HIr
	JTCjEib/+iXdX97Mit+M5c7HrruWLyXIEL3WqCRnbrQ5rmXPan2lVTAZNtSBrGL7C+EG
	CTAfuW8EtpnFn8HUeI/VeXw2klklRG2TrsQ/f7OAAhX4+LTX9EheWw9jrNC1exBmivd9
	eDrmCFOU3HvdOT0BjZnHOqHbnUvxbPyemxA68L7/3c1EXfWWf3N0okzbB0V48ja3/pcj
	jWGdWSa/6cvV5vXOllVfRm5dZStjuXGfiZ3MNH0H6lre3Ty9R+M9EW83pvPnTxSEIirM
	ntHQ==
Received: by 10.14.172.193 with SMTP id t41mr323727eel.25.1347982802315;
	Tue, 18 Sep 2012 08:40:02 -0700 (PDT)
Received: from [192.168.1.69] (host86-183-251-65.range86-183.btcentralplus.com.
	[86.183.251.65])
	by mx.google.com with ESMTPS id h42sm37268103eem.5.2012.09.18.08.40.00
	(version=SSLv3 cipher=OTHER); Tue, 18 Sep 2012 08:40:01 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Tue, 18 Sep 2012 16:39:58 +0100
From: Keir Fraser <keir.xen@gmail.com>
To: Jan Beulich <JBeulich@suse.com>,
	xen-devel <xen-devel@lists.xen.org>
Message-ID: <CC7E545E.3F133%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [PATCH] x86: properly check
	XEN_DOMCTL_ioport_mapping arguments for invalid range
Thread-Index: Ac2Vs9ugS1hhkqxbxEq3Iwh3acw0pw==
In-Reply-To: <5058AE5E020000780009C07D@nat28.tlf.novell.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] [PATCH] x86: properly check
 XEN_DOMCTL_ioport_mapping arguments for invalid range
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 18/09/2012 16:24, "Jan Beulich" <JBeulich@suse.com> wrote:

> In particular, the case of "np" being a very large value wasn't handled
> correctly. The range start checks also were off by one (except that in
> practice, when "np" is properly range checked, this would still have
> been caught by the range end checks).
> 
> Also, is a GFN wrap in XEN_DOMCTL_memory_mapping really okay?

Probably worth fixing?

> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Acked-by: Keir Fraser <keir@xen.org>

> --- a/xen/arch/x86/domctl.c
> +++ b/xen/arch/x86/domctl.c
> @@ -884,7 +884,7 @@ long arch_do_domctl(
>          int found = 0;
>  
>          ret = -EINVAL;
> -        if ( (np == 0) || (fgp > MAX_IOPORTS) || (fmp > MAX_IOPORTS) ||
> +        if ( ((fgp | fmp | (np - 1)) >= MAX_IOPORTS) ||
>              ((fgp + np) > MAX_IOPORTS) || ((fmp + np) > MAX_IOPORTS) )
>          {
>              printk(XENLOG_G_ERR
> 
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Sep 18 15:43:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Sep 2012 15: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 1TDzwt-0004E6-HL; Tue, 18 Sep 2012 15:42: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 1TDzwr-0004Ds-Q0
	for xen-devel@lists.xen.org; Tue, 18 Sep 2012 15:42:54 +0000
Received: from [85.158.139.83:31235] by server-11.bemta-5.messagelabs.com id
	F5/86-24658-C7698505; Tue, 18 Sep 2012 15:42:52 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1347982972!28223191!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-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23416 invoked from network); 18 Sep 2012 15:42:52 -0000
Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com)
	(74.125.83.45)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Sep 2012 15:42:52 -0000
Received: by eeke53 with SMTP id e53so4207696eek.32
	for <xen-devel@lists.xen.org>; Tue, 18 Sep 2012 08:42:52 -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=e5h2RtGHcFEi5pe/vrfMOnVCZLx7UokgjLffVov0agw=;
	b=AmcCjKIUj1hAuO04vZEJL/+bm0kJCHHt5cpOlwlFfNxNpBYDVSoWwk+kHGzquPs2OZ
	bbCSZTyCZyPic+D6I7Qdcl2fpdLDWmV6xikgu0YV6laDDRy1or3QEPY3p3pn5tRGMK/I
	gRLi7e1sg0wJv2n4p4hfeo8HCWCQbcW6GrbsRm2f8Rhw9ApjZTtVG/7Uug1yzs2+wc0o
	QXFZrGSzsEEJHy/gLlHm/+qxR34B2+XLOXG12l8samBuhl88QrTJZhAF2bmbhzFpXxCL
	L3BulPiMn6KvVMSuHZOVz+SJ3N03dldYfC+KHwNefUQcQH6ABTWoNXWP+x/fKqdoRLC0
	SXmQ==
Received: by 10.14.179.137 with SMTP id h9mr311255eem.22.1347982972116;
	Tue, 18 Sep 2012 08:42:52 -0700 (PDT)
Received: from [192.168.1.69] (host86-183-251-65.range86-183.btcentralplus.com.
	[86.183.251.65])
	by mx.google.com with ESMTPS id u8sm37250288eel.11.2012.09.18.08.42.49
	(version=SSLv3 cipher=OTHER); Tue, 18 Sep 2012 08:42:51 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Tue, 18 Sep 2012 16:42:47 +0100
From: Keir Fraser <keir.xen@gmail.com>
To: Jan Beulich <JBeulich@suse.com>,
	xen-devel <xen-devel@lists.xen.org>
Message-ID: <CC7E5507.3F134%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [PATCH] ACPI: move tables.c fully into .init.*
Thread-Index: Ac2VtEBbgjFN19F1jUKzA64ETMACEg==
In-Reply-To: <5058AEC6020000780009C081@nat28.tlf.novell.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] [PATCH] ACPI: move tables.c fully into .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 18/09/2012 16:26, "Jan Beulich" <JBeulich@suse.com> wrote:

> The only non-init item was the space reserved for the initial tables,
> but we can as well dynamically allocate that array.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Really worthwhile, versus having to round up the initial_tables[] allocation
to a whole number of pages?

> --- a/xen/drivers/acpi/Makefile
> +++ b/xen/drivers/acpi/Makefile
> @@ -2,7 +2,7 @@ subdir-y += tables
>  subdir-y += utilities
>  subdir-$(x86) += apei
>  
> -obj-y += tables.o
> +obj-bin-y += tables.init.o
>  obj-y += numa.o
>  obj-y += osl.o
>  obj-y += pmstat.o
> --- a/xen/drivers/acpi/tables.c
> +++ b/xen/drivers/acpi/tables.c
> @@ -25,6 +25,8 @@
>  
>  #include <xen/init.h>
>  #include <xen/kernel.h>
> +#include <xen/mm.h>
> +#include <xen/pfn.h>
>  #include <xen/smp.h>
>  #include <xen/string.h>
>  #include <xen/types.h>
> @@ -41,8 +43,6 @@ mps_inti_flags_polarity[] = { "dfl", "hi
>  static const char *__initdata
>  mps_inti_flags_trigger[] = { "dfl", "edge", "res", "level" };
>  
> -static struct acpi_table_desc initial_tables[ACPI_MAX_TABLES];
> -
>  static int acpi_apic_instance __initdata;
>  
>  void __init acpi_table_print_madt_entry(struct acpi_subtable_header *header)
> @@ -324,6 +324,11 @@ static void __init check_multiple_madt(v
>  
>  int __init acpi_table_init(void)
>  {
> + struct acpi_table_desc *initial_tables =
> +  mfn_to_virt(alloc_boot_pages(PFN_UP(ACPI_MAX_TABLES *
> +          sizeof(*initial_tables)),
> +          1));
> +
> acpi_initialize_tables(initial_tables, ACPI_MAX_TABLES, 0);
> check_multiple_madt();
> return 0;
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 18 15:43:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Sep 2012 15: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 1TDzwt-0004E6-HL; Tue, 18 Sep 2012 15:42: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 1TDzwr-0004Ds-Q0
	for xen-devel@lists.xen.org; Tue, 18 Sep 2012 15:42:54 +0000
Received: from [85.158.139.83:31235] by server-11.bemta-5.messagelabs.com id
	F5/86-24658-C7698505; Tue, 18 Sep 2012 15:42:52 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1347982972!28223191!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-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23416 invoked from network); 18 Sep 2012 15:42:52 -0000
Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com)
	(74.125.83.45)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Sep 2012 15:42:52 -0000
Received: by eeke53 with SMTP id e53so4207696eek.32
	for <xen-devel@lists.xen.org>; Tue, 18 Sep 2012 08:42:52 -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=e5h2RtGHcFEi5pe/vrfMOnVCZLx7UokgjLffVov0agw=;
	b=AmcCjKIUj1hAuO04vZEJL/+bm0kJCHHt5cpOlwlFfNxNpBYDVSoWwk+kHGzquPs2OZ
	bbCSZTyCZyPic+D6I7Qdcl2fpdLDWmV6xikgu0YV6laDDRy1or3QEPY3p3pn5tRGMK/I
	gRLi7e1sg0wJv2n4p4hfeo8HCWCQbcW6GrbsRm2f8Rhw9ApjZTtVG/7Uug1yzs2+wc0o
	QXFZrGSzsEEJHy/gLlHm/+qxR34B2+XLOXG12l8samBuhl88QrTJZhAF2bmbhzFpXxCL
	L3BulPiMn6KvVMSuHZOVz+SJ3N03dldYfC+KHwNefUQcQH6ABTWoNXWP+x/fKqdoRLC0
	SXmQ==
Received: by 10.14.179.137 with SMTP id h9mr311255eem.22.1347982972116;
	Tue, 18 Sep 2012 08:42:52 -0700 (PDT)
Received: from [192.168.1.69] (host86-183-251-65.range86-183.btcentralplus.com.
	[86.183.251.65])
	by mx.google.com with ESMTPS id u8sm37250288eel.11.2012.09.18.08.42.49
	(version=SSLv3 cipher=OTHER); Tue, 18 Sep 2012 08:42:51 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Tue, 18 Sep 2012 16:42:47 +0100
From: Keir Fraser <keir.xen@gmail.com>
To: Jan Beulich <JBeulich@suse.com>,
	xen-devel <xen-devel@lists.xen.org>
Message-ID: <CC7E5507.3F134%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [PATCH] ACPI: move tables.c fully into .init.*
Thread-Index: Ac2VtEBbgjFN19F1jUKzA64ETMACEg==
In-Reply-To: <5058AEC6020000780009C081@nat28.tlf.novell.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] [PATCH] ACPI: move tables.c fully into .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 18/09/2012 16:26, "Jan Beulich" <JBeulich@suse.com> wrote:

> The only non-init item was the space reserved for the initial tables,
> but we can as well dynamically allocate that array.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Really worthwhile, versus having to round up the initial_tables[] allocation
to a whole number of pages?

> --- a/xen/drivers/acpi/Makefile
> +++ b/xen/drivers/acpi/Makefile
> @@ -2,7 +2,7 @@ subdir-y += tables
>  subdir-y += utilities
>  subdir-$(x86) += apei
>  
> -obj-y += tables.o
> +obj-bin-y += tables.init.o
>  obj-y += numa.o
>  obj-y += osl.o
>  obj-y += pmstat.o
> --- a/xen/drivers/acpi/tables.c
> +++ b/xen/drivers/acpi/tables.c
> @@ -25,6 +25,8 @@
>  
>  #include <xen/init.h>
>  #include <xen/kernel.h>
> +#include <xen/mm.h>
> +#include <xen/pfn.h>
>  #include <xen/smp.h>
>  #include <xen/string.h>
>  #include <xen/types.h>
> @@ -41,8 +43,6 @@ mps_inti_flags_polarity[] = { "dfl", "hi
>  static const char *__initdata
>  mps_inti_flags_trigger[] = { "dfl", "edge", "res", "level" };
>  
> -static struct acpi_table_desc initial_tables[ACPI_MAX_TABLES];
> -
>  static int acpi_apic_instance __initdata;
>  
>  void __init acpi_table_print_madt_entry(struct acpi_subtable_header *header)
> @@ -324,6 +324,11 @@ static void __init check_multiple_madt(v
>  
>  int __init acpi_table_init(void)
>  {
> + struct acpi_table_desc *initial_tables =
> +  mfn_to_virt(alloc_boot_pages(PFN_UP(ACPI_MAX_TABLES *
> +          sizeof(*initial_tables)),
> +          1));
> +
> acpi_initialize_tables(initial_tables, ACPI_MAX_TABLES, 0);
> check_multiple_madt();
> return 0;
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 18 16:00:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Sep 2012 16:00:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TE0DI-0004VO-EQ; Tue, 18 Sep 2012 15:59: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 1TE0DG-0004VI-Fq
	for xen-devel@lists.xen.org; Tue, 18 Sep 2012 15:59:50 +0000
Received: from [85.158.138.51:6720] by server-4.bemta-3.messagelabs.com id
	E3/9E-24831-57A98505; Tue, 18 Sep 2012 15:59:49 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1347983988!31030077!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 695 invoked from network); 18 Sep 2012 15:59:48 -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;
	18 Sep 2012 15:59:48 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 18 Sep 2012 16:59:48 +0100
Message-Id: <5058B695020000780009C090@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 18 Sep 2012 16:59:49 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part9FAE9A65.0__="
Subject: [Xen-devel] [PATCH] x86: remove open-coded IO-APIC RTE reads/writes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

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.

--=__Part9FAE9A65.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

This improves readability, not the least through doing away with a
couple of ugly casts.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/arch/x86/io_apic.c
+++ b/xen/arch/x86/io_apic.c
@@ -225,9 +225,8 @@ void __ioapic_write_entry(
 {
     void (*write)(unsigned int, unsigned int, unsigned int)
         =3D raw ? __io_apic_write : io_apic_write;
-    union entry_union eu =3D {{0, 0}};
+    union entry_union eu =3D { .entry =3D e };
=20
-    eu.entry =3D e;
     (*write)(apic, 0x11 + 2*pin, eu.w2);
     (*write)(apic, 0x10 + 2*pin, eu.w1);
 }
@@ -2384,8 +2383,7 @@ int ioapic_guest_write(unsigned long phy
     SET_DEST(rte.dest.dest32, rte.dest.logical.logical_dest,
              cpu_mask_to_apicid(desc->arch.cpu_mask));
=20
-    io_apic_write(apic, 0x10 + 2 * pin, *(((int *)&rte) + 0));
-    io_apic_write(apic, 0x11 + 2 * pin, *(((int *)&rte) + 1));
+    __ioapic_write_entry(apic, pin, 0, rte);
    =20
     spin_unlock_irqrestore(&ioapic_lock, flags);
=20
@@ -2414,7 +2412,6 @@ void dump_ioapic_irq_info(void)
     struct irq_pin_list *entry;
     struct IO_APIC_route_entry rte;
     unsigned int irq, pin, printed =3D 0;
-    unsigned long flags;
=20
     if ( !irq_2_pin )
         return;
@@ -2436,10 +2433,7 @@ void dump_ioapic_irq_info(void)
=20
             printk("      Apic 0x%02x, Pin %2d: ", entry->apic, pin);
=20
-            spin_lock_irqsave(&ioapic_lock, flags);
-            *(((int *)&rte) + 0) =3D io_apic_read(entry->apic, 0x10 + 2 * =
pin);
-            *(((int *)&rte) + 1) =3D io_apic_read(entry->apic, 0x11 + 2 * =
pin);
-            spin_unlock_irqrestore(&ioapic_lock, flags);
+            rte =3D ioapic_read_entry(entry->apic, pin, 0);
=20
             printk("vec=3D%02x delivery=3D%-5s dest=3D%c status=3D%d "
                    "polarity=3D%d irr=3D%d trig=3D%c mask=3D%d dest_id:%d\=
n",




--=__Part9FAE9A65.0__=
Content-Type: text/plain; name="x86-ioapic-rw-entry.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="x86-ioapic-rw-entry.patch"

x86: remove open-coded IO-APIC RTE reads/writes=0A=0AThis improves =
readability, not the least through doing away with a=0Acouple of ugly =
casts.=0A=0ASigned-off-by: Jan Beulich <jbeulich@suse.com>=0A=0A--- =
a/xen/arch/x86/io_apic.c=0A+++ b/xen/arch/x86/io_apic.c=0A@@ -225,9 +225,8 =
@@ void __ioapic_write_entry(=0A {=0A     void (*write)(unsigned int, =
unsigned int, unsigned int)=0A         =3D raw ? __io_apic_write : =
io_apic_write;=0A-    union entry_union eu =3D {{0, 0}};=0A+    union =
entry_union eu =3D { .entry =3D e };=0A =0A-    eu.entry =3D e;=0A     =
(*write)(apic, 0x11 + 2*pin, eu.w2);=0A     (*write)(apic, 0x10 + 2*pin, =
eu.w1);=0A }=0A@@ -2384,8 +2383,7 @@ int ioapic_guest_write(unsigned long =
phy=0A     SET_DEST(rte.dest.dest32, rte.dest.logical.logical_dest,=0A     =
         cpu_mask_to_apicid(desc->arch.cpu_mask));=0A =0A-    io_apic_write=
(apic, 0x10 + 2 * pin, *(((int *)&rte) + 0));=0A-    io_apic_write(apic, =
0x11 + 2 * pin, *(((int *)&rte) + 1));=0A+    __ioapic_write_entry(apic, =
pin, 0, rte);=0A     =0A     spin_unlock_irqrestore(&ioapic_lock, =
flags);=0A =0A@@ -2414,7 +2412,6 @@ void dump_ioapic_irq_info(void)=0A     =
struct irq_pin_list *entry;=0A     struct IO_APIC_route_entry rte;=0A     =
unsigned int irq, pin, printed =3D 0;=0A-    unsigned long flags;=0A =0A   =
  if ( !irq_2_pin )=0A         return;=0A@@ -2436,10 +2433,7 @@ void =
dump_ioapic_irq_info(void)=0A =0A             printk("      Apic 0x%02x, =
Pin %2d: ", entry->apic, pin);=0A =0A-            spin_lock_irqsave(&ioapic=
_lock, flags);=0A-            *(((int *)&rte) + 0) =3D io_apic_read(entry->=
apic, 0x10 + 2 * pin);=0A-            *(((int *)&rte) + 1) =3D io_apic_read=
(entry->apic, 0x11 + 2 * pin);=0A-            spin_unlock_irqrestore(&ioapi=
c_lock, flags);=0A+            rte =3D ioapic_read_entry(entry->apic, pin, =
0);=0A =0A             printk("vec=3D%02x delivery=3D%-5s dest=3D%c =
status=3D%d "=0A                    "polarity=3D%d irr=3D%d trig=3D%c =
mask=3D%d dest_id:%d\n",=0A
--=__Part9FAE9A65.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

--=__Part9FAE9A65.0__=--


From xen-devel-bounces@lists.xen.org Tue Sep 18 16:00:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Sep 2012 16:00:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TE0DI-0004VO-EQ; Tue, 18 Sep 2012 15:59: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 1TE0DG-0004VI-Fq
	for xen-devel@lists.xen.org; Tue, 18 Sep 2012 15:59:50 +0000
Received: from [85.158.138.51:6720] by server-4.bemta-3.messagelabs.com id
	E3/9E-24831-57A98505; Tue, 18 Sep 2012 15:59:49 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1347983988!31030077!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 695 invoked from network); 18 Sep 2012 15:59:48 -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;
	18 Sep 2012 15:59:48 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 18 Sep 2012 16:59:48 +0100
Message-Id: <5058B695020000780009C090@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 18 Sep 2012 16:59:49 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part9FAE9A65.0__="
Subject: [Xen-devel] [PATCH] x86: remove open-coded IO-APIC RTE reads/writes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

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.

--=__Part9FAE9A65.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

This improves readability, not the least through doing away with a
couple of ugly casts.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/arch/x86/io_apic.c
+++ b/xen/arch/x86/io_apic.c
@@ -225,9 +225,8 @@ void __ioapic_write_entry(
 {
     void (*write)(unsigned int, unsigned int, unsigned int)
         =3D raw ? __io_apic_write : io_apic_write;
-    union entry_union eu =3D {{0, 0}};
+    union entry_union eu =3D { .entry =3D e };
=20
-    eu.entry =3D e;
     (*write)(apic, 0x11 + 2*pin, eu.w2);
     (*write)(apic, 0x10 + 2*pin, eu.w1);
 }
@@ -2384,8 +2383,7 @@ int ioapic_guest_write(unsigned long phy
     SET_DEST(rte.dest.dest32, rte.dest.logical.logical_dest,
              cpu_mask_to_apicid(desc->arch.cpu_mask));
=20
-    io_apic_write(apic, 0x10 + 2 * pin, *(((int *)&rte) + 0));
-    io_apic_write(apic, 0x11 + 2 * pin, *(((int *)&rte) + 1));
+    __ioapic_write_entry(apic, pin, 0, rte);
    =20
     spin_unlock_irqrestore(&ioapic_lock, flags);
=20
@@ -2414,7 +2412,6 @@ void dump_ioapic_irq_info(void)
     struct irq_pin_list *entry;
     struct IO_APIC_route_entry rte;
     unsigned int irq, pin, printed =3D 0;
-    unsigned long flags;
=20
     if ( !irq_2_pin )
         return;
@@ -2436,10 +2433,7 @@ void dump_ioapic_irq_info(void)
=20
             printk("      Apic 0x%02x, Pin %2d: ", entry->apic, pin);
=20
-            spin_lock_irqsave(&ioapic_lock, flags);
-            *(((int *)&rte) + 0) =3D io_apic_read(entry->apic, 0x10 + 2 * =
pin);
-            *(((int *)&rte) + 1) =3D io_apic_read(entry->apic, 0x11 + 2 * =
pin);
-            spin_unlock_irqrestore(&ioapic_lock, flags);
+            rte =3D ioapic_read_entry(entry->apic, pin, 0);
=20
             printk("vec=3D%02x delivery=3D%-5s dest=3D%c status=3D%d "
                    "polarity=3D%d irr=3D%d trig=3D%c mask=3D%d dest_id:%d\=
n",




--=__Part9FAE9A65.0__=
Content-Type: text/plain; name="x86-ioapic-rw-entry.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="x86-ioapic-rw-entry.patch"

x86: remove open-coded IO-APIC RTE reads/writes=0A=0AThis improves =
readability, not the least through doing away with a=0Acouple of ugly =
casts.=0A=0ASigned-off-by: Jan Beulich <jbeulich@suse.com>=0A=0A--- =
a/xen/arch/x86/io_apic.c=0A+++ b/xen/arch/x86/io_apic.c=0A@@ -225,9 +225,8 =
@@ void __ioapic_write_entry(=0A {=0A     void (*write)(unsigned int, =
unsigned int, unsigned int)=0A         =3D raw ? __io_apic_write : =
io_apic_write;=0A-    union entry_union eu =3D {{0, 0}};=0A+    union =
entry_union eu =3D { .entry =3D e };=0A =0A-    eu.entry =3D e;=0A     =
(*write)(apic, 0x11 + 2*pin, eu.w2);=0A     (*write)(apic, 0x10 + 2*pin, =
eu.w1);=0A }=0A@@ -2384,8 +2383,7 @@ int ioapic_guest_write(unsigned long =
phy=0A     SET_DEST(rte.dest.dest32, rte.dest.logical.logical_dest,=0A     =
         cpu_mask_to_apicid(desc->arch.cpu_mask));=0A =0A-    io_apic_write=
(apic, 0x10 + 2 * pin, *(((int *)&rte) + 0));=0A-    io_apic_write(apic, =
0x11 + 2 * pin, *(((int *)&rte) + 1));=0A+    __ioapic_write_entry(apic, =
pin, 0, rte);=0A     =0A     spin_unlock_irqrestore(&ioapic_lock, =
flags);=0A =0A@@ -2414,7 +2412,6 @@ void dump_ioapic_irq_info(void)=0A     =
struct irq_pin_list *entry;=0A     struct IO_APIC_route_entry rte;=0A     =
unsigned int irq, pin, printed =3D 0;=0A-    unsigned long flags;=0A =0A   =
  if ( !irq_2_pin )=0A         return;=0A@@ -2436,10 +2433,7 @@ void =
dump_ioapic_irq_info(void)=0A =0A             printk("      Apic 0x%02x, =
Pin %2d: ", entry->apic, pin);=0A =0A-            spin_lock_irqsave(&ioapic=
_lock, flags);=0A-            *(((int *)&rte) + 0) =3D io_apic_read(entry->=
apic, 0x10 + 2 * pin);=0A-            *(((int *)&rte) + 1) =3D io_apic_read=
(entry->apic, 0x11 + 2 * pin);=0A-            spin_unlock_irqrestore(&ioapi=
c_lock, flags);=0A+            rte =3D ioapic_read_entry(entry->apic, pin, =
0);=0A =0A             printk("vec=3D%02x delivery=3D%-5s dest=3D%c =
status=3D%d "=0A                    "polarity=3D%d irr=3D%d trig=3D%c =
mask=3D%d dest_id:%d\n",=0A
--=__Part9FAE9A65.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

--=__Part9FAE9A65.0__=--


From xen-devel-bounces@lists.xen.org Tue Sep 18 16:09:00 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Sep 2012 16:09:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TE0Ls-00059O-Fg; Tue, 18 Sep 2012 16:08:44 +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 1TE0Lr-00059J-JZ
	for xen-devel@lists.xen.org; Tue, 18 Sep 2012 16:08:43 +0000
Received: from [85.158.143.35:36635] by server-3.bemta-4.messagelabs.com id
	A1/38-08232-A8C98505; Tue, 18 Sep 2012 16:08:42 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-6.tower-21.messagelabs.com!1347984519!18823112!1
X-Originating-IP: [188.40.164.121]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3176 invoked from network); 18 Sep 2012 16:08:39 -0000
Received: from static.121.164.40.188.clients.your-server.de (HELO
	smtp.eikelenboom.it) (188.40.164.121)
	by server-6.tower-21.messagelabs.com with AES256-SHA encrypted SMTP;
	18 Sep 2012 16:08:39 -0000
Received: from 101-67-ftth.onsneteindhoven.nl ([88.159.67.101]:57021
	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 1TE0MD-0006RM-Fj; Tue, 18 Sep 2012 18:09:05 +0200
Date: Tue, 18 Sep 2012 18:08:28 +0200
From: Sander Eikelenboom <linux@eikelenboom.it>
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <1674920873.20120918180828@eikelenboom.it>
To: Javier Marcet <jmarcet@gmail.com>
In-Reply-To: <CAAnFQG_wqxutZmR62UhNb-dKQUakYvBrzHEnmMZTv3RkgUeRbg@mail.gmail.com>
References: <CAAnFQG9PuzRLSsCS8m_0VUeV+ZaCwK3zsbinxtuFBfdSihJknw@mail.gmail.com>
	<CC7DF5F7.3F018%keir.xen@gmail.com>
	<CAAnFQG96=Fm5jLqvaqxd6nf2fDAeL6t7drxqkqXzvZHYDOKaDQ@mail.gmail.com>
	<1777522677.20120918163349@eikelenboom.it>
	<CAAnFQG_wqxutZmR62UhNb-dKQUakYvBrzHEnmMZTv3RkgUeRbg@mail.gmail.com>
MIME-Version: 1.0
Cc: Konrad Rzeszutek Wilk <konrad@kernel.org>, Keir Fraser <keir.xen@gmail.com>,
	Xen Devel Mailing list <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.2.0-rc4 issues with DVB tuner
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

DQpUdWVzZGF5LCBTZXB0ZW1iZXIgMTgsIDIwMTIsIDU6MTI6MjggUE0sIHlvdSB3cm90ZToKCj4g
T24gVHVlLCBTZXAgMTgsIDIwMTIgYXQgNDozMyBQTSwgU2FuZGVyIEVpa2VsZW5ib29tCj4gPGxp
bnV4QGVpa2VsZW5ib29tLml0PiB3cm90ZToKCj4+Pj4+IFdoYXQgSSBkb27CtHQgdW5kZXJzdGFu
ZCBpcyBob3cgZ3JhcGhpY3MgcGFzcyB0aHJvdWdoIGV2ZW4gd29ya3MKPj4+PiBhbmQgYSB0dW5l
cgo+Pj4+PiBjYXJkIGhhcyBwcm9ibGVtcyBkdWUgdG8gdGhlIGludHJvZHVjZWQgbGF0ZW5jaWVz
IGluIHRoZQo+Pj4+IElSUXMuCj4+Pj4KPj4+PiBEbyB5b3UgaGF2ZQo+Pj4+PiBhbnkgbW9yZSBp
bmZvIGFib3V0IHRoaXM/Cj4+Pj4KPj4+PiBJbiB0aGlzIHJlc3BlY3Qgc291bmQgaXMgaGFyZGVy
IHRoYW4gZ3JhcGhpY3MuIFRyeSBwaW5uaW5nIHlvdXIgZG9tMCB0byBhCj4+Pj4gQ1BVIGNvcmUs
IGFuZCBzZXQgYWZmaW5pdGllcyBvbiBvdGhlciBkb21haW5zIHNvIHRoYXQgZG9tMCBkb2VzIG5v
dCBjb21wZXRlCj4+Pj4gZm9yIHRoZSBjb3JlIHdpdGggYW55IG90aGVyIGRvbWFpbnMuCj4+Cj4+
PiBBbGwgcmlnaHQsIEkgY2FuIHRyeSB0aGF0LiBIb3dldmVyLCB0aGUgcHJvYmxlbSBoYXBwZW5z
IHdpdGhvdXQgYW55Cj4+PiBkb21VIHJ1bm5pbmcsIGp1c3QKPj4+IHRoZSBkb20wLiBEbyB5b3Ug
c3RpbGwgdGhpbmsgdGhhdCBwaW5uaW5nIHRvIGEgY3B1IGNvcmUgb3Igc2V0dGluZwo+Pj4gYWZm
aW5pdGllcyBjYW4gaGVscD8KPj4KPj4gSSBoYXZlbid0IGZvbGxvd2VkIHRoZSB0aHJlYWQgY2xv
c2VseSwgYnV0IGFyZSB5b3Ugc3VyZSB0aGUgZGV2aWNlIHdvcmtzIE9LIG9uIGJhcmVtZXRhbCAo
bGludXggd2l0aG91dCB4ZW4pID8KPj4gSWYgeW91IGhhdmUgcHJvYmxlbXMgaW4gZG9tMCBpdCBz
ZWVtcyBpdCBoYXNuJ3QgZ290IG11Y2ggdG8gZG8gd2l0aCBwYXNzdGhyb3VnaCA/Cgo+IFlvdSBh
cmUgcmlnaHQsIEkgaGF2ZW7CtHQgcmVhY2hlZCB0aGUgcG9pbnQgb2YgdHJ5aW5nIHRvIHBhc3N0
aHJvdWdoIGl0Cj4gdG8gYSBkb21VLgoKPiBJwrRtIHN1cmUgdGhlIGRldmljZSB3b3JrcyBmaW5l
IG9uIGJhcmUgbWV0YWwuIEkgaGF2ZSBpdCB3b3JraW5nIG9uIGFuCj4gSFRQQyB3aGljaCBtYWtl
cyAyLTMKPiByZWNvcmRpbmdzIHBlciBkYXksIHdpdGhvdXQgaXNzdWVzLgoKQnV0IHRoYXQgaXMg
YSBkaWZmZXJlbnQgbWFjaGluZSwgYnV0IHdpdGggdGhlIHNhbWUgY2FyZCA/CklmIHRoYXQncyBy
aWdodCBpdCB3b3VsZCBhbHNvIHRyeSBiYXJlbWV0YWwgZmlyc3Qgb24gdGhlIHNhbWUgbWFjaGlu
ZSBhbmQgY2FyZCB5b3UgYXJlIHRyeWluZyB0byBnZXQgaXQgdG8gd29yayB3aXRoIHhlbi4KCj4g
T24gdGhlIGxpbnV4IG1lZGlhIG1haWxpbmcgbGlzdCBJIHdhcyBzYWlkIHRoaXMgcHJvYmxlbSB3
YXMgY29tbW9uCj4gd2l0aCBhbGwgdHVuZXIgY2FyZHMsCj4gbW9yZSBnZW5lcmFsbHkgd2l0aCBh
bnkgY2FyZCB3aGljaCBnZW5lcmF0ZXMgbG90cyBvZiBpbnRlcnJ1cHRpb25zIGFuZAo+IHRoYXQg
SSBzaG91bGQgYmV0dGVyCj4gZm9yZ2V0IGFib3V0IGl0LgoKSG1tIHRoYXQncyBhIHF1aXRlIHN0
YW5kYXJkIGFuc3dlciBmb3Igbm90IHN0YW5kYXJkIGNhc2VzIDotKQoKSSBoYXZlIGFuZCBoYXZl
IGhhZCBtdWx0aXBsZSBkZXZpY2VzIHBhc3NlZCB0aHJvdWdoLCBhbmQgaXQncyB3b3JraW5nIHF1
aXRlIGdvb2QsIHNvdW5kIGNhcmQsIGEgYW5hbG9nIHR2IHR1bmVyIGFuZCBhIDggY2hhbm5lbCBk
dnIgY2FyZC4KClNpbmNlIGl0J3MgYSBEVkIgY2FyZCwgaSdtIGFsc28gd29uZGVyaW5nIG9uIHdo
YXQgcmVzb2x1dGlvbiB5b3UgYXJlIHRyeWluZyB0byBncmFiIHZpZGVvLCBwZXJoYXBzIGZpcnN0
IHRyeSBpdCBvbiBhIHF1aXRlIGxvdyByZXNvbHV0aW9uIChyZXF1aXJpbmcgbGVzcyB0aHJvdWdo
cHV0IGFuZCBwcm9jZXNzaW5nIHBvd2VyKSwgYW5kIGlmIHlvdSBhcmUgdHJ5aW5nIHRvIHRyYW5z
Y29kZSBzdHVmZiBkaXJlY3RseS4KCi0tClNhbmRlcgoKCgpfX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fXwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZl
bEBsaXN0cy54ZW4ub3JnCmh0dHA6Ly9saXN0cy54ZW4ub3JnL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xen.org Tue Sep 18 16:09:00 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Sep 2012 16:09:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TE0Ls-00059O-Fg; Tue, 18 Sep 2012 16:08:44 +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 1TE0Lr-00059J-JZ
	for xen-devel@lists.xen.org; Tue, 18 Sep 2012 16:08:43 +0000
Received: from [85.158.143.35:36635] by server-3.bemta-4.messagelabs.com id
	A1/38-08232-A8C98505; Tue, 18 Sep 2012 16:08:42 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-6.tower-21.messagelabs.com!1347984519!18823112!1
X-Originating-IP: [188.40.164.121]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3176 invoked from network); 18 Sep 2012 16:08:39 -0000
Received: from static.121.164.40.188.clients.your-server.de (HELO
	smtp.eikelenboom.it) (188.40.164.121)
	by server-6.tower-21.messagelabs.com with AES256-SHA encrypted SMTP;
	18 Sep 2012 16:08:39 -0000
Received: from 101-67-ftth.onsneteindhoven.nl ([88.159.67.101]:57021
	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 1TE0MD-0006RM-Fj; Tue, 18 Sep 2012 18:09:05 +0200
Date: Tue, 18 Sep 2012 18:08:28 +0200
From: Sander Eikelenboom <linux@eikelenboom.it>
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <1674920873.20120918180828@eikelenboom.it>
To: Javier Marcet <jmarcet@gmail.com>
In-Reply-To: <CAAnFQG_wqxutZmR62UhNb-dKQUakYvBrzHEnmMZTv3RkgUeRbg@mail.gmail.com>
References: <CAAnFQG9PuzRLSsCS8m_0VUeV+ZaCwK3zsbinxtuFBfdSihJknw@mail.gmail.com>
	<CC7DF5F7.3F018%keir.xen@gmail.com>
	<CAAnFQG96=Fm5jLqvaqxd6nf2fDAeL6t7drxqkqXzvZHYDOKaDQ@mail.gmail.com>
	<1777522677.20120918163349@eikelenboom.it>
	<CAAnFQG_wqxutZmR62UhNb-dKQUakYvBrzHEnmMZTv3RkgUeRbg@mail.gmail.com>
MIME-Version: 1.0
Cc: Konrad Rzeszutek Wilk <konrad@kernel.org>, Keir Fraser <keir.xen@gmail.com>,
	Xen Devel Mailing list <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.2.0-rc4 issues with DVB tuner
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

DQpUdWVzZGF5LCBTZXB0ZW1iZXIgMTgsIDIwMTIsIDU6MTI6MjggUE0sIHlvdSB3cm90ZToKCj4g
T24gVHVlLCBTZXAgMTgsIDIwMTIgYXQgNDozMyBQTSwgU2FuZGVyIEVpa2VsZW5ib29tCj4gPGxp
bnV4QGVpa2VsZW5ib29tLml0PiB3cm90ZToKCj4+Pj4+IFdoYXQgSSBkb27CtHQgdW5kZXJzdGFu
ZCBpcyBob3cgZ3JhcGhpY3MgcGFzcyB0aHJvdWdoIGV2ZW4gd29ya3MKPj4+PiBhbmQgYSB0dW5l
cgo+Pj4+PiBjYXJkIGhhcyBwcm9ibGVtcyBkdWUgdG8gdGhlIGludHJvZHVjZWQgbGF0ZW5jaWVz
IGluIHRoZQo+Pj4+IElSUXMuCj4+Pj4KPj4+PiBEbyB5b3UgaGF2ZQo+Pj4+PiBhbnkgbW9yZSBp
bmZvIGFib3V0IHRoaXM/Cj4+Pj4KPj4+PiBJbiB0aGlzIHJlc3BlY3Qgc291bmQgaXMgaGFyZGVy
IHRoYW4gZ3JhcGhpY3MuIFRyeSBwaW5uaW5nIHlvdXIgZG9tMCB0byBhCj4+Pj4gQ1BVIGNvcmUs
IGFuZCBzZXQgYWZmaW5pdGllcyBvbiBvdGhlciBkb21haW5zIHNvIHRoYXQgZG9tMCBkb2VzIG5v
dCBjb21wZXRlCj4+Pj4gZm9yIHRoZSBjb3JlIHdpdGggYW55IG90aGVyIGRvbWFpbnMuCj4+Cj4+
PiBBbGwgcmlnaHQsIEkgY2FuIHRyeSB0aGF0LiBIb3dldmVyLCB0aGUgcHJvYmxlbSBoYXBwZW5z
IHdpdGhvdXQgYW55Cj4+PiBkb21VIHJ1bm5pbmcsIGp1c3QKPj4+IHRoZSBkb20wLiBEbyB5b3Ug
c3RpbGwgdGhpbmsgdGhhdCBwaW5uaW5nIHRvIGEgY3B1IGNvcmUgb3Igc2V0dGluZwo+Pj4gYWZm
aW5pdGllcyBjYW4gaGVscD8KPj4KPj4gSSBoYXZlbid0IGZvbGxvd2VkIHRoZSB0aHJlYWQgY2xv
c2VseSwgYnV0IGFyZSB5b3Ugc3VyZSB0aGUgZGV2aWNlIHdvcmtzIE9LIG9uIGJhcmVtZXRhbCAo
bGludXggd2l0aG91dCB4ZW4pID8KPj4gSWYgeW91IGhhdmUgcHJvYmxlbXMgaW4gZG9tMCBpdCBz
ZWVtcyBpdCBoYXNuJ3QgZ290IG11Y2ggdG8gZG8gd2l0aCBwYXNzdGhyb3VnaCA/Cgo+IFlvdSBh
cmUgcmlnaHQsIEkgaGF2ZW7CtHQgcmVhY2hlZCB0aGUgcG9pbnQgb2YgdHJ5aW5nIHRvIHBhc3N0
aHJvdWdoIGl0Cj4gdG8gYSBkb21VLgoKPiBJwrRtIHN1cmUgdGhlIGRldmljZSB3b3JrcyBmaW5l
IG9uIGJhcmUgbWV0YWwuIEkgaGF2ZSBpdCB3b3JraW5nIG9uIGFuCj4gSFRQQyB3aGljaCBtYWtl
cyAyLTMKPiByZWNvcmRpbmdzIHBlciBkYXksIHdpdGhvdXQgaXNzdWVzLgoKQnV0IHRoYXQgaXMg
YSBkaWZmZXJlbnQgbWFjaGluZSwgYnV0IHdpdGggdGhlIHNhbWUgY2FyZCA/CklmIHRoYXQncyBy
aWdodCBpdCB3b3VsZCBhbHNvIHRyeSBiYXJlbWV0YWwgZmlyc3Qgb24gdGhlIHNhbWUgbWFjaGlu
ZSBhbmQgY2FyZCB5b3UgYXJlIHRyeWluZyB0byBnZXQgaXQgdG8gd29yayB3aXRoIHhlbi4KCj4g
T24gdGhlIGxpbnV4IG1lZGlhIG1haWxpbmcgbGlzdCBJIHdhcyBzYWlkIHRoaXMgcHJvYmxlbSB3
YXMgY29tbW9uCj4gd2l0aCBhbGwgdHVuZXIgY2FyZHMsCj4gbW9yZSBnZW5lcmFsbHkgd2l0aCBh
bnkgY2FyZCB3aGljaCBnZW5lcmF0ZXMgbG90cyBvZiBpbnRlcnJ1cHRpb25zIGFuZAo+IHRoYXQg
SSBzaG91bGQgYmV0dGVyCj4gZm9yZ2V0IGFib3V0IGl0LgoKSG1tIHRoYXQncyBhIHF1aXRlIHN0
YW5kYXJkIGFuc3dlciBmb3Igbm90IHN0YW5kYXJkIGNhc2VzIDotKQoKSSBoYXZlIGFuZCBoYXZl
IGhhZCBtdWx0aXBsZSBkZXZpY2VzIHBhc3NlZCB0aHJvdWdoLCBhbmQgaXQncyB3b3JraW5nIHF1
aXRlIGdvb2QsIHNvdW5kIGNhcmQsIGEgYW5hbG9nIHR2IHR1bmVyIGFuZCBhIDggY2hhbm5lbCBk
dnIgY2FyZC4KClNpbmNlIGl0J3MgYSBEVkIgY2FyZCwgaSdtIGFsc28gd29uZGVyaW5nIG9uIHdo
YXQgcmVzb2x1dGlvbiB5b3UgYXJlIHRyeWluZyB0byBncmFiIHZpZGVvLCBwZXJoYXBzIGZpcnN0
IHRyeSBpdCBvbiBhIHF1aXRlIGxvdyByZXNvbHV0aW9uIChyZXF1aXJpbmcgbGVzcyB0aHJvdWdo
cHV0IGFuZCBwcm9jZXNzaW5nIHBvd2VyKSwgYW5kIGlmIHlvdSBhcmUgdHJ5aW5nIHRvIHRyYW5z
Y29kZSBzdHVmZiBkaXJlY3RseS4KCi0tClNhbmRlcgoKCgpfX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fXwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZl
bEBsaXN0cy54ZW4ub3JnCmh0dHA6Ly9saXN0cy54ZW4ub3JnL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xen.org Tue Sep 18 16:23:35 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Sep 2012 16:23: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 1TE0a1-0005N3-5O; Tue, 18 Sep 2012 16:23:21 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jmarcet@gmail.com>) id 1TE0Zz-0005My-Be
	for xen-devel@lists.xen.org; Tue, 18 Sep 2012 16:23:19 +0000
X-Env-Sender: jmarcet@gmail.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1347985391!8100869!1
X-Originating-IP: [209.85.219.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26257 invoked from network); 18 Sep 2012 16:23:13 -0000
Received: from mail-oa0-f45.google.com (HELO mail-oa0-f45.google.com)
	(209.85.219.45)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Sep 2012 16:23:13 -0000
Received: by oagn12 with SMTP id n12so34251oag.32
	for <xen-devel@lists.xen.org>; Tue, 18 Sep 2012 09:23:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to
	:cc:content-type:content-transfer-encoding;
	bh=c3mx8/owmJtHjdR9icG4tQfME7nGzcvYfRwxW2j2M4U=;
	b=CahbGMNhqGxdmmyl//4G0w2so7ymZ6vvIP9vVKJWnbV/1o64vFC2OdTPWhjcXN6BUD
	0SHsAWWskgy2Kx3a09tB1SB1q/Pubx4UoL5VjUKQAwfoGCiEC0MxlWg4EmEe3nlqSK+E
	nl/hCav0tbKjQHDtf6yMrS49NKgaiwIDq5o8AlJjZ+/JcI6R8mLhvdIUYmbF85l8p+RX
	TMbZad7P1HsRrMr4TtEKLV0ZxDQGDv497y3LCDonO2pNHNonr92sPLoFqIuRe51eAFQa
	TLVabKm1SDkHple7HUy0JsJGtEaBf3nJb9GV8kEC1p5WLPz3i9Sja/BDtpRtFEk3wmBV
	Vc2g==
Received: by 10.182.172.74 with SMTP id ba10mr489634obc.83.1347985391478; Tue,
	18 Sep 2012 09:23:11 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.60.138.225 with HTTP; Tue, 18 Sep 2012 09:22:51 -0700 (PDT)
In-Reply-To: <1674920873.20120918180828@eikelenboom.it>
References: <CAAnFQG9PuzRLSsCS8m_0VUeV+ZaCwK3zsbinxtuFBfdSihJknw@mail.gmail.com>
	<CC7DF5F7.3F018%keir.xen@gmail.com>
	<CAAnFQG96=Fm5jLqvaqxd6nf2fDAeL6t7drxqkqXzvZHYDOKaDQ@mail.gmail.com>
	<1777522677.20120918163349@eikelenboom.it>
	<CAAnFQG_wqxutZmR62UhNb-dKQUakYvBrzHEnmMZTv3RkgUeRbg@mail.gmail.com>
	<1674920873.20120918180828@eikelenboom.it>
From: Javier Marcet <jmarcet@gmail.com>
Date: Tue, 18 Sep 2012 18:22:51 +0200
Message-ID: <CAAnFQG81Y65xi2tnGtNyL5ZMSQ1V8ZsGiAD2XohOdDEUwKvA8w@mail.gmail.com>
To: Sander Eikelenboom <linux@eikelenboom.it>
Cc: Konrad Rzeszutek Wilk <konrad@kernel.org>, Keir Fraser <keir.xen@gmail.com>,
	Xen Devel Mailing list <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.2.0-rc4 issues with DVB tuner
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gVHVlLCBTZXAgMTgsIDIwMTIgYXQgNjowOCBQTSwgU2FuZGVyIEVpa2VsZW5ib29tCjxsaW51
eEBlaWtlbGVuYm9vbS5pdD4gd3JvdGU6Cgo+Pj4+Pj4gV2hhdCBJIGRvbsK0dCB1bmRlcnN0YW5k
IGlzIGhvdyBncmFwaGljcyBwYXNzIHRocm91Z2ggZXZlbiB3b3Jrcwo+Pj4+PiBhbmQgYSB0dW5l
cgo+Pj4+Pj4gY2FyZCBoYXMgcHJvYmxlbXMgZHVlIHRvIHRoZSBpbnRyb2R1Y2VkIGxhdGVuY2ll
cyBpbiB0aGUKPj4+Pj4gSVJRcy4KPj4+Pj4KPj4+Pj4gRG8geW91IGhhdmUKPj4+Pj4+IGFueSBt
b3JlIGluZm8gYWJvdXQgdGhpcz8KPj4+Pj4KPj4+Pj4gSW4gdGhpcyByZXNwZWN0IHNvdW5kIGlz
IGhhcmRlciB0aGFuIGdyYXBoaWNzLiBUcnkgcGlubmluZyB5b3VyIGRvbTAgdG8gYQo+Pj4+PiBD
UFUgY29yZSwgYW5kIHNldCBhZmZpbml0aWVzIG9uIG90aGVyIGRvbWFpbnMgc28gdGhhdCBkb20w
IGRvZXMgbm90IGNvbXBldGUKPj4+Pj4gZm9yIHRoZSBjb3JlIHdpdGggYW55IG90aGVyIGRvbWFp
bnMuCj4+Pgo+Pj4+IEFsbCByaWdodCwgSSBjYW4gdHJ5IHRoYXQuIEhvd2V2ZXIsIHRoZSBwcm9i
bGVtIGhhcHBlbnMgd2l0aG91dCBhbnkKPj4+PiBkb21VIHJ1bm5pbmcsIGp1c3QKPj4+PiB0aGUg
ZG9tMC4gRG8geW91IHN0aWxsIHRoaW5rIHRoYXQgcGlubmluZyB0byBhIGNwdSBjb3JlIG9yIHNl
dHRpbmcKPj4+PiBhZmZpbml0aWVzIGNhbiBoZWxwPwo+Pj4KPj4+IEkgaGF2ZW4ndCBmb2xsb3dl
ZCB0aGUgdGhyZWFkIGNsb3NlbHksIGJ1dCBhcmUgeW91IHN1cmUgdGhlIGRldmljZSB3b3JrcyBP
SyBvbiBiYXJlbWV0YWwgKGxpbnV4IHdpdGhvdXQgeGVuKSA/Cj4+PiBJZiB5b3UgaGF2ZSBwcm9i
bGVtcyBpbiBkb20wIGl0IHNlZW1zIGl0IGhhc24ndCBnb3QgbXVjaCB0byBkbyB3aXRoIHBhc3N0
aHJvdWdoID8KPgo+PiBZb3UgYXJlIHJpZ2h0LCBJIGhhdmVuwrR0IHJlYWNoZWQgdGhlIHBvaW50
IG9mIHRyeWluZyB0byBwYXNzdGhyb3VnaCBpdAo+PiB0byBhIGRvbVUuCj4KPj4gScK0bSBzdXJl
IHRoZSBkZXZpY2Ugd29ya3MgZmluZSBvbiBiYXJlIG1ldGFsLiBJIGhhdmUgaXQgd29ya2luZyBv
biBhbgo+PiBIVFBDIHdoaWNoIG1ha2VzIDItMwo+PiByZWNvcmRpbmdzIHBlciBkYXksIHdpdGhv
dXQgaXNzdWVzLgo+Cj4gQnV0IHRoYXQgaXMgYSBkaWZmZXJlbnQgbWFjaGluZSwgYnV0IHdpdGgg
dGhlIHNhbWUgY2FyZCA/Cj4gSWYgdGhhdCdzIHJpZ2h0IGl0IHdvdWxkIGFsc28gdHJ5IGJhcmVt
ZXRhbCBmaXJzdCBvbiB0aGUgc2FtZSBtYWNoaW5lIGFuZCBjYXJkIHlvdSBhcmUgdHJ5aW5nIHRv
IGdldCBpdCB0byB3b3JrIHdpdGggeGVuLgoKTm8sIGl0IGlzIHRoZSBzYW1lIG1hY2hpbmUuIEl0
IGlzIHdvcmtpbmcgYXMgYW4gSFRQQywgTkFTLCB3ZWIgYW5kIGZ0cApzZXJ2ZXIgcmlnaHQgbm93
LgpJIHJlY2VudGx5IHVwZ3JhZGVkIHRoZSBDUFUgdG8gYmUgYWJsZSB0byBhZGQgdmlydHVhbGl6
YXRpb24gYXMgd2VsbC4KCj4+IE9uIHRoZSBsaW51eCBtZWRpYSBtYWlsaW5nIGxpc3QgSSB3YXMg
c2FpZCB0aGlzIHByb2JsZW0gd2FzIGNvbW1vbgo+PiB3aXRoIGFsbCB0dW5lciBjYXJkcywKPj4g
bW9yZSBnZW5lcmFsbHkgd2l0aCBhbnkgY2FyZCB3aGljaCBnZW5lcmF0ZXMgbG90cyBvZiBpbnRl
cnJ1cHRpb25zIGFuZAo+PiB0aGF0IEkgc2hvdWxkIGJldHRlcgo+PiBmb3JnZXQgYWJvdXQgaXQu
Cj4KPiBIbW0gdGhhdCdzIGEgcXVpdGUgc3RhbmRhcmQgYW5zd2VyIGZvciBub3Qgc3RhbmRhcmQg
Y2FzZXMgOi0pCgpZZXMsIEkgZ3Vlc3Mgc28uIFdoYXQgd2FzIGNsZWFyIGlzIHRoYXQgdGhlIGxp
bnV4IG1lZGlhIGRldnMgYXJlIG5vdApnb2luZyB0byBoZWxwIHRvbyBtdWNoIHdpdGggdGhpcy4K
Cj4gSSBoYXZlIGFuZCBoYXZlIGhhZCBtdWx0aXBsZSBkZXZpY2VzIHBhc3NlZCB0aHJvdWdoLCBh
bmQgaXQncyB3b3JraW5nIHF1aXRlIGdvb2QsIHNvdW5kIGNhcmQsIGEgYW5hbG9nIHR2IHR1bmVy
IGFuZCBhIDggY2hhbm5lbCBkdnIgY2FyZC4KClNvIGZhciBJIGhhdmUgc3VjY2Vzc2Z1bGx5IHBh
c3NlZCB0aHJvdWdoIGFuIEFTTWVkaWEgU0FUQSBjb250cm9sbGVyCndoaWNoIHNlZW1lZCB0byB3
b3JrIGFsbCByaWdodC4gVGhhdCB3YXMgd2l0aCBLVk0gYW5kIGEgV2luZG93cyA3Cmd1ZXN0LCB0
aG91Z2guIFRyeWluZyB0byBwYXNzIHRocm91Z2ggdGhlIHNhbWUgRFZCIGNhcmQgKHdoaWNoIGhh
cyB0d28KdHVuZXJzKSBkaWRuJ3QgZXhhY3RseSB3b3JrLiBJdCBzaG93cyB1cCBhcyB0d28gUENJ
ZSBkZXZpY2VzLiBPbiBvbmUKb2YgdGhlbSBJIGNhbiBpbnN0YWxsIHRoZSBkcml2ZXIgYW5kIGdp
dmVzIG5vIGVycm9ycy4gT24gdGhlIG90aGVyIG9uZQpJIGNhbid0IGV2ZW4gaW5zdGFsbCB0aGUg
ZHJpdmVyLgoKQW55aG93LCBJIGNvdWxkIG5vdCB0dW5lIGFueSBjaGFubmVsIGFsdGhvdWdoIEkn
bSBub3Qgc3VyZSB0aGUKc29mdHdhcmUgcHJvdmlkZWQgYnkgVGVycmF0ZWMgd2FzIHRoZSBiZXN0
IHRvIHRyeS4KCj4gU2luY2UgaXQncyBhIERWQiBjYXJkLCBpJ20gYWxzbyB3b25kZXJpbmcgb24g
d2hhdCByZXNvbHV0aW9uIHlvdSBhcmUgdHJ5aW5nIHRvIGdyYWIgdmlkZW8sIHBlcmhhcHMgZmly
c3QgdHJ5IGl0IG9uIGEgcXVpdGUgbG93IHJlc29sdXRpb24gKHJlcXVpcmluZyBsZXNzIHRocm91
Z2hwdXQgYW5kIHByb2Nlc3NpbmcgcG93ZXIpLCBhbmQgaWYgeW91IGFyZSB0cnlpbmcgdG8gdHJh
bnNjb2RlIHN0dWZmIGRpcmVjdGx5LgoKSG1tLCBhbGwgdGhlIHRlc3RzIEkgaGF2ZSBkb25lLCBv
bmNlIGl0IHdhcyBjbGVhciBJIGNvdWxkIG5vdCB1c2UgdmRyCnNpbmNlIGl0IGRpZG4ndCByZWNl
aXZlIGRhdGEsIGhhcyBiZWVuIHdpdGggJ21wbGF5ZXIgLWR1bXBzdHJlYW0nIG9uIGEKU0QgY2hh
bm5lbC4gSS1tIHByZXR0eSBjZXJ0YWluIHRoYXQgaXQgZG9lc24ndCBnbyBvdmVyIHRoZSAybWJw
cy4gSQpnZXQgc29tZSBkYXRhIGJ1dCBhcyBtcGVnIHN0cmVhbSBpdCBpcyBjb21wbGV0ZWx5IGJy
b2tlbi4KCgotLSAKSmF2aWVyIE1hcmNldCA8am1hcmNldEBnbWFpbC5jb20+CgpfX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpYZW4tZGV2ZWwgbWFpbGluZyBs
aXN0Clhlbi1kZXZlbEBsaXN0cy54ZW4ub3JnCmh0dHA6Ly9saXN0cy54ZW4ub3JnL3hlbi1kZXZl
bAo=

From xen-devel-bounces@lists.xen.org Tue Sep 18 16:23:35 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Sep 2012 16:23: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 1TE0a1-0005N3-5O; Tue, 18 Sep 2012 16:23:21 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jmarcet@gmail.com>) id 1TE0Zz-0005My-Be
	for xen-devel@lists.xen.org; Tue, 18 Sep 2012 16:23:19 +0000
X-Env-Sender: jmarcet@gmail.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1347985391!8100869!1
X-Originating-IP: [209.85.219.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26257 invoked from network); 18 Sep 2012 16:23:13 -0000
Received: from mail-oa0-f45.google.com (HELO mail-oa0-f45.google.com)
	(209.85.219.45)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Sep 2012 16:23:13 -0000
Received: by oagn12 with SMTP id n12so34251oag.32
	for <xen-devel@lists.xen.org>; Tue, 18 Sep 2012 09:23:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to
	:cc:content-type:content-transfer-encoding;
	bh=c3mx8/owmJtHjdR9icG4tQfME7nGzcvYfRwxW2j2M4U=;
	b=CahbGMNhqGxdmmyl//4G0w2so7ymZ6vvIP9vVKJWnbV/1o64vFC2OdTPWhjcXN6BUD
	0SHsAWWskgy2Kx3a09tB1SB1q/Pubx4UoL5VjUKQAwfoGCiEC0MxlWg4EmEe3nlqSK+E
	nl/hCav0tbKjQHDtf6yMrS49NKgaiwIDq5o8AlJjZ+/JcI6R8mLhvdIUYmbF85l8p+RX
	TMbZad7P1HsRrMr4TtEKLV0ZxDQGDv497y3LCDonO2pNHNonr92sPLoFqIuRe51eAFQa
	TLVabKm1SDkHple7HUy0JsJGtEaBf3nJb9GV8kEC1p5WLPz3i9Sja/BDtpRtFEk3wmBV
	Vc2g==
Received: by 10.182.172.74 with SMTP id ba10mr489634obc.83.1347985391478; Tue,
	18 Sep 2012 09:23:11 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.60.138.225 with HTTP; Tue, 18 Sep 2012 09:22:51 -0700 (PDT)
In-Reply-To: <1674920873.20120918180828@eikelenboom.it>
References: <CAAnFQG9PuzRLSsCS8m_0VUeV+ZaCwK3zsbinxtuFBfdSihJknw@mail.gmail.com>
	<CC7DF5F7.3F018%keir.xen@gmail.com>
	<CAAnFQG96=Fm5jLqvaqxd6nf2fDAeL6t7drxqkqXzvZHYDOKaDQ@mail.gmail.com>
	<1777522677.20120918163349@eikelenboom.it>
	<CAAnFQG_wqxutZmR62UhNb-dKQUakYvBrzHEnmMZTv3RkgUeRbg@mail.gmail.com>
	<1674920873.20120918180828@eikelenboom.it>
From: Javier Marcet <jmarcet@gmail.com>
Date: Tue, 18 Sep 2012 18:22:51 +0200
Message-ID: <CAAnFQG81Y65xi2tnGtNyL5ZMSQ1V8ZsGiAD2XohOdDEUwKvA8w@mail.gmail.com>
To: Sander Eikelenboom <linux@eikelenboom.it>
Cc: Konrad Rzeszutek Wilk <konrad@kernel.org>, Keir Fraser <keir.xen@gmail.com>,
	Xen Devel Mailing list <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.2.0-rc4 issues with DVB tuner
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gVHVlLCBTZXAgMTgsIDIwMTIgYXQgNjowOCBQTSwgU2FuZGVyIEVpa2VsZW5ib29tCjxsaW51
eEBlaWtlbGVuYm9vbS5pdD4gd3JvdGU6Cgo+Pj4+Pj4gV2hhdCBJIGRvbsK0dCB1bmRlcnN0YW5k
IGlzIGhvdyBncmFwaGljcyBwYXNzIHRocm91Z2ggZXZlbiB3b3Jrcwo+Pj4+PiBhbmQgYSB0dW5l
cgo+Pj4+Pj4gY2FyZCBoYXMgcHJvYmxlbXMgZHVlIHRvIHRoZSBpbnRyb2R1Y2VkIGxhdGVuY2ll
cyBpbiB0aGUKPj4+Pj4gSVJRcy4KPj4+Pj4KPj4+Pj4gRG8geW91IGhhdmUKPj4+Pj4+IGFueSBt
b3JlIGluZm8gYWJvdXQgdGhpcz8KPj4+Pj4KPj4+Pj4gSW4gdGhpcyByZXNwZWN0IHNvdW5kIGlz
IGhhcmRlciB0aGFuIGdyYXBoaWNzLiBUcnkgcGlubmluZyB5b3VyIGRvbTAgdG8gYQo+Pj4+PiBD
UFUgY29yZSwgYW5kIHNldCBhZmZpbml0aWVzIG9uIG90aGVyIGRvbWFpbnMgc28gdGhhdCBkb20w
IGRvZXMgbm90IGNvbXBldGUKPj4+Pj4gZm9yIHRoZSBjb3JlIHdpdGggYW55IG90aGVyIGRvbWFp
bnMuCj4+Pgo+Pj4+IEFsbCByaWdodCwgSSBjYW4gdHJ5IHRoYXQuIEhvd2V2ZXIsIHRoZSBwcm9i
bGVtIGhhcHBlbnMgd2l0aG91dCBhbnkKPj4+PiBkb21VIHJ1bm5pbmcsIGp1c3QKPj4+PiB0aGUg
ZG9tMC4gRG8geW91IHN0aWxsIHRoaW5rIHRoYXQgcGlubmluZyB0byBhIGNwdSBjb3JlIG9yIHNl
dHRpbmcKPj4+PiBhZmZpbml0aWVzIGNhbiBoZWxwPwo+Pj4KPj4+IEkgaGF2ZW4ndCBmb2xsb3dl
ZCB0aGUgdGhyZWFkIGNsb3NlbHksIGJ1dCBhcmUgeW91IHN1cmUgdGhlIGRldmljZSB3b3JrcyBP
SyBvbiBiYXJlbWV0YWwgKGxpbnV4IHdpdGhvdXQgeGVuKSA/Cj4+PiBJZiB5b3UgaGF2ZSBwcm9i
bGVtcyBpbiBkb20wIGl0IHNlZW1zIGl0IGhhc24ndCBnb3QgbXVjaCB0byBkbyB3aXRoIHBhc3N0
aHJvdWdoID8KPgo+PiBZb3UgYXJlIHJpZ2h0LCBJIGhhdmVuwrR0IHJlYWNoZWQgdGhlIHBvaW50
IG9mIHRyeWluZyB0byBwYXNzdGhyb3VnaCBpdAo+PiB0byBhIGRvbVUuCj4KPj4gScK0bSBzdXJl
IHRoZSBkZXZpY2Ugd29ya3MgZmluZSBvbiBiYXJlIG1ldGFsLiBJIGhhdmUgaXQgd29ya2luZyBv
biBhbgo+PiBIVFBDIHdoaWNoIG1ha2VzIDItMwo+PiByZWNvcmRpbmdzIHBlciBkYXksIHdpdGhv
dXQgaXNzdWVzLgo+Cj4gQnV0IHRoYXQgaXMgYSBkaWZmZXJlbnQgbWFjaGluZSwgYnV0IHdpdGgg
dGhlIHNhbWUgY2FyZCA/Cj4gSWYgdGhhdCdzIHJpZ2h0IGl0IHdvdWxkIGFsc28gdHJ5IGJhcmVt
ZXRhbCBmaXJzdCBvbiB0aGUgc2FtZSBtYWNoaW5lIGFuZCBjYXJkIHlvdSBhcmUgdHJ5aW5nIHRv
IGdldCBpdCB0byB3b3JrIHdpdGggeGVuLgoKTm8sIGl0IGlzIHRoZSBzYW1lIG1hY2hpbmUuIEl0
IGlzIHdvcmtpbmcgYXMgYW4gSFRQQywgTkFTLCB3ZWIgYW5kIGZ0cApzZXJ2ZXIgcmlnaHQgbm93
LgpJIHJlY2VudGx5IHVwZ3JhZGVkIHRoZSBDUFUgdG8gYmUgYWJsZSB0byBhZGQgdmlydHVhbGl6
YXRpb24gYXMgd2VsbC4KCj4+IE9uIHRoZSBsaW51eCBtZWRpYSBtYWlsaW5nIGxpc3QgSSB3YXMg
c2FpZCB0aGlzIHByb2JsZW0gd2FzIGNvbW1vbgo+PiB3aXRoIGFsbCB0dW5lciBjYXJkcywKPj4g
bW9yZSBnZW5lcmFsbHkgd2l0aCBhbnkgY2FyZCB3aGljaCBnZW5lcmF0ZXMgbG90cyBvZiBpbnRl
cnJ1cHRpb25zIGFuZAo+PiB0aGF0IEkgc2hvdWxkIGJldHRlcgo+PiBmb3JnZXQgYWJvdXQgaXQu
Cj4KPiBIbW0gdGhhdCdzIGEgcXVpdGUgc3RhbmRhcmQgYW5zd2VyIGZvciBub3Qgc3RhbmRhcmQg
Y2FzZXMgOi0pCgpZZXMsIEkgZ3Vlc3Mgc28uIFdoYXQgd2FzIGNsZWFyIGlzIHRoYXQgdGhlIGxp
bnV4IG1lZGlhIGRldnMgYXJlIG5vdApnb2luZyB0byBoZWxwIHRvbyBtdWNoIHdpdGggdGhpcy4K
Cj4gSSBoYXZlIGFuZCBoYXZlIGhhZCBtdWx0aXBsZSBkZXZpY2VzIHBhc3NlZCB0aHJvdWdoLCBh
bmQgaXQncyB3b3JraW5nIHF1aXRlIGdvb2QsIHNvdW5kIGNhcmQsIGEgYW5hbG9nIHR2IHR1bmVy
IGFuZCBhIDggY2hhbm5lbCBkdnIgY2FyZC4KClNvIGZhciBJIGhhdmUgc3VjY2Vzc2Z1bGx5IHBh
c3NlZCB0aHJvdWdoIGFuIEFTTWVkaWEgU0FUQSBjb250cm9sbGVyCndoaWNoIHNlZW1lZCB0byB3
b3JrIGFsbCByaWdodC4gVGhhdCB3YXMgd2l0aCBLVk0gYW5kIGEgV2luZG93cyA3Cmd1ZXN0LCB0
aG91Z2guIFRyeWluZyB0byBwYXNzIHRocm91Z2ggdGhlIHNhbWUgRFZCIGNhcmQgKHdoaWNoIGhh
cyB0d28KdHVuZXJzKSBkaWRuJ3QgZXhhY3RseSB3b3JrLiBJdCBzaG93cyB1cCBhcyB0d28gUENJ
ZSBkZXZpY2VzLiBPbiBvbmUKb2YgdGhlbSBJIGNhbiBpbnN0YWxsIHRoZSBkcml2ZXIgYW5kIGdp
dmVzIG5vIGVycm9ycy4gT24gdGhlIG90aGVyIG9uZQpJIGNhbid0IGV2ZW4gaW5zdGFsbCB0aGUg
ZHJpdmVyLgoKQW55aG93LCBJIGNvdWxkIG5vdCB0dW5lIGFueSBjaGFubmVsIGFsdGhvdWdoIEkn
bSBub3Qgc3VyZSB0aGUKc29mdHdhcmUgcHJvdmlkZWQgYnkgVGVycmF0ZWMgd2FzIHRoZSBiZXN0
IHRvIHRyeS4KCj4gU2luY2UgaXQncyBhIERWQiBjYXJkLCBpJ20gYWxzbyB3b25kZXJpbmcgb24g
d2hhdCByZXNvbHV0aW9uIHlvdSBhcmUgdHJ5aW5nIHRvIGdyYWIgdmlkZW8sIHBlcmhhcHMgZmly
c3QgdHJ5IGl0IG9uIGEgcXVpdGUgbG93IHJlc29sdXRpb24gKHJlcXVpcmluZyBsZXNzIHRocm91
Z2hwdXQgYW5kIHByb2Nlc3NpbmcgcG93ZXIpLCBhbmQgaWYgeW91IGFyZSB0cnlpbmcgdG8gdHJh
bnNjb2RlIHN0dWZmIGRpcmVjdGx5LgoKSG1tLCBhbGwgdGhlIHRlc3RzIEkgaGF2ZSBkb25lLCBv
bmNlIGl0IHdhcyBjbGVhciBJIGNvdWxkIG5vdCB1c2UgdmRyCnNpbmNlIGl0IGRpZG4ndCByZWNl
aXZlIGRhdGEsIGhhcyBiZWVuIHdpdGggJ21wbGF5ZXIgLWR1bXBzdHJlYW0nIG9uIGEKU0QgY2hh
bm5lbC4gSS1tIHByZXR0eSBjZXJ0YWluIHRoYXQgaXQgZG9lc24ndCBnbyBvdmVyIHRoZSAybWJw
cy4gSQpnZXQgc29tZSBkYXRhIGJ1dCBhcyBtcGVnIHN0cmVhbSBpdCBpcyBjb21wbGV0ZWx5IGJy
b2tlbi4KCgotLSAKSmF2aWVyIE1hcmNldCA8am1hcmNldEBnbWFpbC5jb20+CgpfX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpYZW4tZGV2ZWwgbWFpbGluZyBs
aXN0Clhlbi1kZXZlbEBsaXN0cy54ZW4ub3JnCmh0dHA6Ly9saXN0cy54ZW4ub3JnL3hlbi1kZXZl
bAo=

From xen-devel-bounces@lists.xen.org Tue Sep 18 16:37:09 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Sep 2012 16:37:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TE0n5-0005fk-H3; Tue, 18 Sep 2012 16:36:51 +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 1TE0n4-0005fd-0s
	for xen-devel@lists.xen.org; Tue, 18 Sep 2012 16:36:50 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1347986202!10085405!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDc1Nzk4OQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27823 invoked from network); 18 Sep 2012 16:36:43 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-16.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 18 Sep 2012 16:36:43 -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 q8IGae8r014357
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 18 Sep 2012 16:36:40 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
	q8IGadgs016730
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 18 Sep 2012 16:36:39 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
	q8IGadrY022820; Tue, 18 Sep 2012 11:36:39 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 18 Sep 2012 09:36:39 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 955D8402EC; Tue, 18 Sep 2012 12:25:50 -0400 (EDT)
Date: Tue, 18 Sep 2012 12:25:50 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20120918162550.GA1558@phenom.dumpdata.com>
References: <5058771F020000780009C025@nat28.tlf.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <5058771F020000780009C025@nat28.tlf.novell.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: linux-kernel@vger.kernel.org, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] xen-pciback: support wild cards in slot
	specifications
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Sep 18, 2012 at 12:29:03PM +0100, Jan Beulich wrote:
> Particularly for hiding sets of SR-IOV devices, specifying them all
> individually is rather cumbersome. Therefore, allow function and slot
> numbers to be replaced by a wildcard character ('*').
> 
> Unfortunately this gets complicated by the in-kernel sscanf()
> implementation not being really standard conformant - matching of
> plain text tails cannot be checked by the caller (a patch to overcome
> this will be sent shortly, and a follow-up patch for simplifying the
> code is planned to be sent when that fixed went upstream).

applied for 3.7
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> 
> ---
>  drivers/xen/xen-pciback/pci_stub.c |   89 ++++++++++++++++++++++++++++++++++---
>  1 file changed, 82 insertions(+), 7 deletions(-)
> 
> --- 3.6-rc6/drivers/xen/xen-pciback/pci_stub.c
> +++ 3.6-rc6-xen-pciback-wildcard/drivers/xen/xen-pciback/pci_stub.c
> @@ -897,17 +897,41 @@ static inline int str_to_slot(const char
>  			      int *slot, int *func)
>  {
>  	int err;
> +	char wc = '*';
>  
>  	err = sscanf(buf, " %x:%x:%x.%x", domain, bus, slot, func);
> -	if (err == 4)
> +	switch (err) {
> +	case 3:
> +		*func = -1;
> +		err = sscanf(buf, " %x:%x:%x.%c", domain, bus, slot, &wc);
> +		break;
> +	case 2:
> +		*slot = *func = -1;
> +		err = sscanf(buf, " %x:%x:*.%c", domain, bus, &wc);
> +		if (err >= 2)
> +			++err;
> +		break;
> +	}
> +	if (err == 4 && wc == '*')
>  		return 0;
>  	else if (err < 0)
>  		return -EINVAL;
>  
>  	/* try again without domain */
>  	*domain = 0;
> +	wc = '*';
>  	err = sscanf(buf, " %x:%x.%x", bus, slot, func);
> -	if (err == 3)
> +	switch (err) {
> +	case 2:
> +		*func = -1;
> +		err = sscanf(buf, " %x:%x.%c", bus, slot, &wc);
> +		break;
> +	case 1:
> +		*slot = *func = -1;
> +		err = sscanf(buf, " %x:*.%c", bus, &wc) + 1;
> +		break;
> +	}
> +	if (err == 3 && wc == '*')
>  		return 0;
>  
>  	return -EINVAL;
> @@ -930,6 +954,19 @@ static int pcistub_device_id_add(int dom
>  {
>  	struct pcistub_device_id *pci_dev_id;
>  	unsigned long flags;
> +	int rc = 0;
> +
> +	if (slot < 0) {
> +		for (slot = 0; !rc && slot < 32; ++slot)
> +			rc = pcistub_device_id_add(domain, bus, slot, func);
> +		return rc;
> +	}
> +
> +	if (func < 0) {
> +		for (func = 0; !rc && func < 8; ++func)
> +			rc = pcistub_device_id_add(domain, bus, slot, func);
> +		return rc;
> +	}
>  
>  	pci_dev_id = kmalloc(sizeof(*pci_dev_id), GFP_KERNEL);
>  	if (!pci_dev_id)
> @@ -952,15 +989,15 @@ static int pcistub_device_id_add(int dom
>  static int pcistub_device_id_remove(int domain, int bus, int slot, int func)
>  {
>  	struct pcistub_device_id *pci_dev_id, *t;
> -	int devfn = PCI_DEVFN(slot, func);
>  	int err = -ENOENT;
>  	unsigned long flags;
>  
>  	spin_lock_irqsave(&device_ids_lock, flags);
>  	list_for_each_entry_safe(pci_dev_id, t, &pcistub_device_ids,
>  				 slot_list) {
> -		if (pci_dev_id->domain == domain
> -		    && pci_dev_id->bus == bus && pci_dev_id->devfn == devfn) {
> +		if (pci_dev_id->domain == domain && pci_dev_id->bus == bus
> +		    && (slot < 0 || PCI_SLOT(pci_dev_id->devfn) == slot)
> +		    && (func < 0 || PCI_FUNC(pci_dev_id->devfn) == func)) {
>  			/* Don't break; here because it's possible the same
>  			 * slot could be in the list more than once
>  			 */
> @@ -1216,6 +1253,10 @@ static ssize_t permissive_add(struct dev
>  	err = str_to_slot(buf, &domain, &bus, &slot, &func);
>  	if (err)
>  		goto out;
> +	if (slot < 0 || func < 0) {
> +		err = -EINVAL;
> +		goto out;
> +	}
>  	psdev = pcistub_device_find(domain, bus, slot, func);
>  	if (!psdev) {
>  		err = -ENODEV;
> @@ -1297,17 +1338,51 @@ static int __init pcistub_init(void)
>  
>  	if (pci_devs_to_hide && *pci_devs_to_hide) {
>  		do {
> +			char wc = '*';
> +
>  			parsed = 0;
>  
>  			err = sscanf(pci_devs_to_hide + pos,
>  				     " (%x:%x:%x.%x) %n",
>  				     &domain, &bus, &slot, &func, &parsed);
> -			if (err != 4) {
> +			switch (err) {
> +			case 3:
> +				func = -1;
> +				err = sscanf(pci_devs_to_hide + pos,
> +					     " (%x:%x:%x.%c) %n",
> +					     &domain, &bus, &slot, &wc,
> +					     &parsed);
> +				break;
> +			case 2:
> +				slot = func = -1;
> +				err = sscanf(pci_devs_to_hide + pos,
> +					     " (%x:%x:*.%c) %n",
> +					     &domain, &bus, &wc, &parsed) + 1;
> +				break;
> +			}
> +
> +			if (err != 4 || wc != '*') {
>  				domain = 0;
> +				wc = '*';
>  				err = sscanf(pci_devs_to_hide + pos,
>  					     " (%x:%x.%x) %n",
>  					     &bus, &slot, &func, &parsed);
> -				if (err != 3)
> +				switch (err) {
> +				case 2:
> +					func = -1;
> +					err = sscanf(pci_devs_to_hide + pos,
> +						     " (%x:%x.%c) %n",
> +						     &bus, &slot, &wc,
> +						     &parsed);
> +					break;
> +				case 1:
> +					slot = func = -1;
> +					err = sscanf(pci_devs_to_hide + pos,
> +						     " (%x:*.%c) %n",
> +						     &bus, &wc, &parsed) + 1;
> +					break;
> +				}
> +				if (err != 3 || wc != '*')
>  					goto parse_error;
>  			}
>  
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 18 16:37:09 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Sep 2012 16:37:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TE0n5-0005fk-H3; Tue, 18 Sep 2012 16:36:51 +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 1TE0n4-0005fd-0s
	for xen-devel@lists.xen.org; Tue, 18 Sep 2012 16:36:50 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1347986202!10085405!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDc1Nzk4OQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27823 invoked from network); 18 Sep 2012 16:36:43 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-16.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 18 Sep 2012 16:36:43 -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 q8IGae8r014357
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 18 Sep 2012 16:36:40 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
	q8IGadgs016730
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 18 Sep 2012 16:36:39 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
	q8IGadrY022820; Tue, 18 Sep 2012 11:36:39 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 18 Sep 2012 09:36:39 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 955D8402EC; Tue, 18 Sep 2012 12:25:50 -0400 (EDT)
Date: Tue, 18 Sep 2012 12:25:50 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20120918162550.GA1558@phenom.dumpdata.com>
References: <5058771F020000780009C025@nat28.tlf.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <5058771F020000780009C025@nat28.tlf.novell.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: linux-kernel@vger.kernel.org, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] xen-pciback: support wild cards in slot
	specifications
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Sep 18, 2012 at 12:29:03PM +0100, Jan Beulich wrote:
> Particularly for hiding sets of SR-IOV devices, specifying them all
> individually is rather cumbersome. Therefore, allow function and slot
> numbers to be replaced by a wildcard character ('*').
> 
> Unfortunately this gets complicated by the in-kernel sscanf()
> implementation not being really standard conformant - matching of
> plain text tails cannot be checked by the caller (a patch to overcome
> this will be sent shortly, and a follow-up patch for simplifying the
> code is planned to be sent when that fixed went upstream).

applied for 3.7
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> 
> ---
>  drivers/xen/xen-pciback/pci_stub.c |   89 ++++++++++++++++++++++++++++++++++---
>  1 file changed, 82 insertions(+), 7 deletions(-)
> 
> --- 3.6-rc6/drivers/xen/xen-pciback/pci_stub.c
> +++ 3.6-rc6-xen-pciback-wildcard/drivers/xen/xen-pciback/pci_stub.c
> @@ -897,17 +897,41 @@ static inline int str_to_slot(const char
>  			      int *slot, int *func)
>  {
>  	int err;
> +	char wc = '*';
>  
>  	err = sscanf(buf, " %x:%x:%x.%x", domain, bus, slot, func);
> -	if (err == 4)
> +	switch (err) {
> +	case 3:
> +		*func = -1;
> +		err = sscanf(buf, " %x:%x:%x.%c", domain, bus, slot, &wc);
> +		break;
> +	case 2:
> +		*slot = *func = -1;
> +		err = sscanf(buf, " %x:%x:*.%c", domain, bus, &wc);
> +		if (err >= 2)
> +			++err;
> +		break;
> +	}
> +	if (err == 4 && wc == '*')
>  		return 0;
>  	else if (err < 0)
>  		return -EINVAL;
>  
>  	/* try again without domain */
>  	*domain = 0;
> +	wc = '*';
>  	err = sscanf(buf, " %x:%x.%x", bus, slot, func);
> -	if (err == 3)
> +	switch (err) {
> +	case 2:
> +		*func = -1;
> +		err = sscanf(buf, " %x:%x.%c", bus, slot, &wc);
> +		break;
> +	case 1:
> +		*slot = *func = -1;
> +		err = sscanf(buf, " %x:*.%c", bus, &wc) + 1;
> +		break;
> +	}
> +	if (err == 3 && wc == '*')
>  		return 0;
>  
>  	return -EINVAL;
> @@ -930,6 +954,19 @@ static int pcistub_device_id_add(int dom
>  {
>  	struct pcistub_device_id *pci_dev_id;
>  	unsigned long flags;
> +	int rc = 0;
> +
> +	if (slot < 0) {
> +		for (slot = 0; !rc && slot < 32; ++slot)
> +			rc = pcistub_device_id_add(domain, bus, slot, func);
> +		return rc;
> +	}
> +
> +	if (func < 0) {
> +		for (func = 0; !rc && func < 8; ++func)
> +			rc = pcistub_device_id_add(domain, bus, slot, func);
> +		return rc;
> +	}
>  
>  	pci_dev_id = kmalloc(sizeof(*pci_dev_id), GFP_KERNEL);
>  	if (!pci_dev_id)
> @@ -952,15 +989,15 @@ static int pcistub_device_id_add(int dom
>  static int pcistub_device_id_remove(int domain, int bus, int slot, int func)
>  {
>  	struct pcistub_device_id *pci_dev_id, *t;
> -	int devfn = PCI_DEVFN(slot, func);
>  	int err = -ENOENT;
>  	unsigned long flags;
>  
>  	spin_lock_irqsave(&device_ids_lock, flags);
>  	list_for_each_entry_safe(pci_dev_id, t, &pcistub_device_ids,
>  				 slot_list) {
> -		if (pci_dev_id->domain == domain
> -		    && pci_dev_id->bus == bus && pci_dev_id->devfn == devfn) {
> +		if (pci_dev_id->domain == domain && pci_dev_id->bus == bus
> +		    && (slot < 0 || PCI_SLOT(pci_dev_id->devfn) == slot)
> +		    && (func < 0 || PCI_FUNC(pci_dev_id->devfn) == func)) {
>  			/* Don't break; here because it's possible the same
>  			 * slot could be in the list more than once
>  			 */
> @@ -1216,6 +1253,10 @@ static ssize_t permissive_add(struct dev
>  	err = str_to_slot(buf, &domain, &bus, &slot, &func);
>  	if (err)
>  		goto out;
> +	if (slot < 0 || func < 0) {
> +		err = -EINVAL;
> +		goto out;
> +	}
>  	psdev = pcistub_device_find(domain, bus, slot, func);
>  	if (!psdev) {
>  		err = -ENODEV;
> @@ -1297,17 +1338,51 @@ static int __init pcistub_init(void)
>  
>  	if (pci_devs_to_hide && *pci_devs_to_hide) {
>  		do {
> +			char wc = '*';
> +
>  			parsed = 0;
>  
>  			err = sscanf(pci_devs_to_hide + pos,
>  				     " (%x:%x:%x.%x) %n",
>  				     &domain, &bus, &slot, &func, &parsed);
> -			if (err != 4) {
> +			switch (err) {
> +			case 3:
> +				func = -1;
> +				err = sscanf(pci_devs_to_hide + pos,
> +					     " (%x:%x:%x.%c) %n",
> +					     &domain, &bus, &slot, &wc,
> +					     &parsed);
> +				break;
> +			case 2:
> +				slot = func = -1;
> +				err = sscanf(pci_devs_to_hide + pos,
> +					     " (%x:%x:*.%c) %n",
> +					     &domain, &bus, &wc, &parsed) + 1;
> +				break;
> +			}
> +
> +			if (err != 4 || wc != '*') {
>  				domain = 0;
> +				wc = '*';
>  				err = sscanf(pci_devs_to_hide + pos,
>  					     " (%x:%x.%x) %n",
>  					     &bus, &slot, &func, &parsed);
> -				if (err != 3)
> +				switch (err) {
> +				case 2:
> +					func = -1;
> +					err = sscanf(pci_devs_to_hide + pos,
> +						     " (%x:%x.%c) %n",
> +						     &bus, &slot, &wc,
> +						     &parsed);
> +					break;
> +				case 1:
> +					slot = func = -1;
> +					err = sscanf(pci_devs_to_hide + pos,
> +						     " (%x:*.%c) %n",
> +						     &bus, &wc, &parsed) + 1;
> +					break;
> +				}
> +				if (err != 3 || wc != '*')
>  					goto parse_error;
>  			}
>  
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 18 17:01:02 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Sep 2012 17:01: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 1TE1A6-0005yU-Rc; Tue, 18 Sep 2012 17:00:38 +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 1TE1A5-0005yP-EL
	for xen-devel@lists.xen.org; Tue, 18 Sep 2012 17:00:37 +0000
Received: from [85.158.143.35:34063] by server-3.bemta-4.messagelabs.com id
	E5/2B-08232-4B8A8505; Tue, 18 Sep 2012 17:00:36 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1347987634!7094451!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-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32486 invoked from network); 18 Sep 2012 17:00:34 -0000
Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com)
	(74.125.83.45)
	by server-4.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Sep 2012 17:00:34 -0000
Received: by eeke53 with SMTP id e53so30904eek.32
	for <xen-devel@lists.xen.org>; Tue, 18 Sep 2012 10:00:34 -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=sIo3cfh3ccYlpNVh5vckjz/W78st2oDqYXS/0wKTeeo=;
	b=ly+L4DXZDHDdCBkablRZSvi8LjYXb9Bl4kaTYFdQ7CuhaNXao463nh6liKPVG7U4JT
	8go0qMeHLEbv/LRSbCKbCW+DQF6P3wRGsyQyqO5EiMlFoCymngo5fG2aCWcrYpECZO86
	a9uoWgndsaF6GfG29wBiF/o5yOQuCMQuPL/3VOTFUwDjwyRFMLqmOxOiDuZHFmRwhMIK
	6u7zcqJjayGwZIBR5Z7NljQUuLs9pnkYoIG2+ZJDXDJQp5u0x+GnjglZ5sqrkgQNMBdz
	HS4GwvofnszF2JrzKHhYodQl6vsKu8JmBaj7b/Nh7JJNwmu8v4F7JwETElcVAhudCXe+
	SjGg==
Received: by 10.14.178.6 with SMTP id e6mr102546eem.36.1347987634515;
	Tue, 18 Sep 2012 10:00:34 -0700 (PDT)
Received: from [192.168.1.69] (host86-183-251-65.range86-183.btcentralplus.com.
	[86.183.251.65])
	by mx.google.com with ESMTPS id k49sm304202een.4.2012.09.18.10.00.32
	(version=SSLv3 cipher=OTHER); Tue, 18 Sep 2012 10:00:33 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Tue, 18 Sep 2012 18:00:31 +0100
From: Keir Fraser <keir.xen@gmail.com>
To: Jan Beulich <JBeulich@suse.com>,
	xen-devel <xen-devel@lists.xen.org>
Message-ID: <CC7E673F.3F141%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [PATCH] x86: remove open-coded IO-APIC RTE
	reads/writes
Thread-Index: Ac2VvxxRPXO2xdh/e0yAZ2QpTcnMgw==
In-Reply-To: <5058B695020000780009C090@nat28.tlf.novell.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] [PATCH] x86: remove open-coded IO-APIC RTE
 reads/writes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 18/09/2012 16:59, "Jan Beulich" <JBeulich@suse.com> wrote:

> This improves readability, not the least through doing away with a
> couple of ugly casts.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Acked-by: Keir Fraser <keir@xen.org>

> --- a/xen/arch/x86/io_apic.c
> +++ b/xen/arch/x86/io_apic.c
> @@ -225,9 +225,8 @@ void __ioapic_write_entry(
>  {
>      void (*write)(unsigned int, unsigned int, unsigned int)
>          = raw ? __io_apic_write : io_apic_write;
> -    union entry_union eu = {{0, 0}};
> +    union entry_union eu = { .entry = e };
>  
> -    eu.entry = e;
>      (*write)(apic, 0x11 + 2*pin, eu.w2);
>      (*write)(apic, 0x10 + 2*pin, eu.w1);
>  }
> @@ -2384,8 +2383,7 @@ int ioapic_guest_write(unsigned long phy
>      SET_DEST(rte.dest.dest32, rte.dest.logical.logical_dest,
>               cpu_mask_to_apicid(desc->arch.cpu_mask));
>  
> -    io_apic_write(apic, 0x10 + 2 * pin, *(((int *)&rte) + 0));
> -    io_apic_write(apic, 0x11 + 2 * pin, *(((int *)&rte) + 1));
> +    __ioapic_write_entry(apic, pin, 0, rte);
>      
>      spin_unlock_irqrestore(&ioapic_lock, flags);
>  
> @@ -2414,7 +2412,6 @@ void dump_ioapic_irq_info(void)
>      struct irq_pin_list *entry;
>      struct IO_APIC_route_entry rte;
>      unsigned int irq, pin, printed = 0;
> -    unsigned long flags;
>  
>      if ( !irq_2_pin )
>          return;
> @@ -2436,10 +2433,7 @@ void dump_ioapic_irq_info(void)
>  
>              printk("      Apic 0x%02x, Pin %2d: ", entry->apic, pin);
>  
> -            spin_lock_irqsave(&ioapic_lock, flags);
> -            *(((int *)&rte) + 0) = io_apic_read(entry->apic, 0x10 + 2 * pin);
> -            *(((int *)&rte) + 1) = io_apic_read(entry->apic, 0x11 + 2 * pin);
> -            spin_unlock_irqrestore(&ioapic_lock, flags);
> +            rte = ioapic_read_entry(entry->apic, pin, 0);
>  
>              printk("vec=%02x delivery=%-5s dest=%c status=%d "
>                     "polarity=%d irr=%d trig=%c mask=%d dest_id:%d\n",
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Sep 18 17:01:02 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Sep 2012 17:01: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 1TE1A6-0005yU-Rc; Tue, 18 Sep 2012 17:00:38 +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 1TE1A5-0005yP-EL
	for xen-devel@lists.xen.org; Tue, 18 Sep 2012 17:00:37 +0000
Received: from [85.158.143.35:34063] by server-3.bemta-4.messagelabs.com id
	E5/2B-08232-4B8A8505; Tue, 18 Sep 2012 17:00:36 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1347987634!7094451!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-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32486 invoked from network); 18 Sep 2012 17:00:34 -0000
Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com)
	(74.125.83.45)
	by server-4.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Sep 2012 17:00:34 -0000
Received: by eeke53 with SMTP id e53so30904eek.32
	for <xen-devel@lists.xen.org>; Tue, 18 Sep 2012 10:00:34 -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=sIo3cfh3ccYlpNVh5vckjz/W78st2oDqYXS/0wKTeeo=;
	b=ly+L4DXZDHDdCBkablRZSvi8LjYXb9Bl4kaTYFdQ7CuhaNXao463nh6liKPVG7U4JT
	8go0qMeHLEbv/LRSbCKbCW+DQF6P3wRGsyQyqO5EiMlFoCymngo5fG2aCWcrYpECZO86
	a9uoWgndsaF6GfG29wBiF/o5yOQuCMQuPL/3VOTFUwDjwyRFMLqmOxOiDuZHFmRwhMIK
	6u7zcqJjayGwZIBR5Z7NljQUuLs9pnkYoIG2+ZJDXDJQp5u0x+GnjglZ5sqrkgQNMBdz
	HS4GwvofnszF2JrzKHhYodQl6vsKu8JmBaj7b/Nh7JJNwmu8v4F7JwETElcVAhudCXe+
	SjGg==
Received: by 10.14.178.6 with SMTP id e6mr102546eem.36.1347987634515;
	Tue, 18 Sep 2012 10:00:34 -0700 (PDT)
Received: from [192.168.1.69] (host86-183-251-65.range86-183.btcentralplus.com.
	[86.183.251.65])
	by mx.google.com with ESMTPS id k49sm304202een.4.2012.09.18.10.00.32
	(version=SSLv3 cipher=OTHER); Tue, 18 Sep 2012 10:00:33 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Tue, 18 Sep 2012 18:00:31 +0100
From: Keir Fraser <keir.xen@gmail.com>
To: Jan Beulich <JBeulich@suse.com>,
	xen-devel <xen-devel@lists.xen.org>
Message-ID: <CC7E673F.3F141%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [PATCH] x86: remove open-coded IO-APIC RTE
	reads/writes
Thread-Index: Ac2VvxxRPXO2xdh/e0yAZ2QpTcnMgw==
In-Reply-To: <5058B695020000780009C090@nat28.tlf.novell.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] [PATCH] x86: remove open-coded IO-APIC RTE
 reads/writes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 18/09/2012 16:59, "Jan Beulich" <JBeulich@suse.com> wrote:

> This improves readability, not the least through doing away with a
> couple of ugly casts.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Acked-by: Keir Fraser <keir@xen.org>

> --- a/xen/arch/x86/io_apic.c
> +++ b/xen/arch/x86/io_apic.c
> @@ -225,9 +225,8 @@ void __ioapic_write_entry(
>  {
>      void (*write)(unsigned int, unsigned int, unsigned int)
>          = raw ? __io_apic_write : io_apic_write;
> -    union entry_union eu = {{0, 0}};
> +    union entry_union eu = { .entry = e };
>  
> -    eu.entry = e;
>      (*write)(apic, 0x11 + 2*pin, eu.w2);
>      (*write)(apic, 0x10 + 2*pin, eu.w1);
>  }
> @@ -2384,8 +2383,7 @@ int ioapic_guest_write(unsigned long phy
>      SET_DEST(rte.dest.dest32, rte.dest.logical.logical_dest,
>               cpu_mask_to_apicid(desc->arch.cpu_mask));
>  
> -    io_apic_write(apic, 0x10 + 2 * pin, *(((int *)&rte) + 0));
> -    io_apic_write(apic, 0x11 + 2 * pin, *(((int *)&rte) + 1));
> +    __ioapic_write_entry(apic, pin, 0, rte);
>      
>      spin_unlock_irqrestore(&ioapic_lock, flags);
>  
> @@ -2414,7 +2412,6 @@ void dump_ioapic_irq_info(void)
>      struct irq_pin_list *entry;
>      struct IO_APIC_route_entry rte;
>      unsigned int irq, pin, printed = 0;
> -    unsigned long flags;
>  
>      if ( !irq_2_pin )
>          return;
> @@ -2436,10 +2433,7 @@ void dump_ioapic_irq_info(void)
>  
>              printk("      Apic 0x%02x, Pin %2d: ", entry->apic, pin);
>  
> -            spin_lock_irqsave(&ioapic_lock, flags);
> -            *(((int *)&rte) + 0) = io_apic_read(entry->apic, 0x10 + 2 * pin);
> -            *(((int *)&rte) + 1) = io_apic_read(entry->apic, 0x11 + 2 * pin);
> -            spin_unlock_irqrestore(&ioapic_lock, flags);
> +            rte = ioapic_read_entry(entry->apic, pin, 0);
>  
>              printk("vec=%02x delivery=%-5s dest=%c status=%d "
>                     "polarity=%d irr=%d trig=%c mask=%d dest_id:%d\n",
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Sep 18 17:04:07 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Sep 2012 17: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 1TE1D7-00064Z-Ej; Tue, 18 Sep 2012 17:03: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 1TE1D5-00064S-RN
	for xen-devel@lists.xen.org; Tue, 18 Sep 2012 17:03:44 +0000
Received: from [85.158.139.83:60957] by server-2.bemta-5.messagelabs.com id
	CA/0C-11456-F69A8505; Tue, 18 Sep 2012 17:03:43 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-5.tower-182.messagelabs.com!1347987822!30745902!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24950 invoked from network); 18 Sep 2012 17:03:42 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-5.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 18 Sep 2012 17:03:42 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1TE1Cy-000Mgv-Ph; Tue, 18 Sep 2012 17:03:36 +0000
Date: Tue, 18 Sep 2012 18:03:36 +0100
From: Tim Deegan <tim@xen.org>
To: Matt Wilson <msw@amazon.com>
Message-ID: <20120918170336.GA86732@ocelot.phlegethon.org>
References: <patchbomb.1346992557@u002268147cd4502c336d.ant.amazon.com>
	<3b3582f4dc423daa8040.1346992558@u002268147cd4502c336d.ant.amazon.com>
	<1347874964.14977.34.camel@zakaz.uk.xensource.com>
	<20120917170814.GA22382@u002268147cd4502c336d.ant.amazon.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120917170814.GA22382@u002268147cd4502c336d.ant.amazon.com>
User-Agent: Mutt/1.4.2.1i
Cc: 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 1 of 2 v3] tools: check for documentation
	generation tools at configure 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

At 10:08 -0700 on 17 Sep (1347876501), Matt Wilson wrote:
> While we're discussing expanding the coverage of ./configure, I
> wonder: what (if any) is the resistance to requiring ./configure to
> build the xen/ tree?

There's nothing in the hypervisor build that needs to be adjusted to
match the run-time userspace.  So if you're a hypervisor maintainer it
just introduces all the charming idiosyncracies of autotools without
providing any benefit.  E.g., this:

 checking for yajl_alloc in -lyajl... no
 configure: error: Could not find yajl

should not stop me building Xen.  Also, as I said before, autoconf is
the thin end of a slippery wedge: the answer to any autotools problem is
always more autotools, and I choose to make my stand here rather than
have the argument later about why we shouldn't be using libtool. :)

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 18 17:04:07 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Sep 2012 17: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 1TE1D7-00064Z-Ej; Tue, 18 Sep 2012 17:03: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 1TE1D5-00064S-RN
	for xen-devel@lists.xen.org; Tue, 18 Sep 2012 17:03:44 +0000
Received: from [85.158.139.83:60957] by server-2.bemta-5.messagelabs.com id
	CA/0C-11456-F69A8505; Tue, 18 Sep 2012 17:03:43 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-5.tower-182.messagelabs.com!1347987822!30745902!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24950 invoked from network); 18 Sep 2012 17:03:42 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-5.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 18 Sep 2012 17:03:42 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1TE1Cy-000Mgv-Ph; Tue, 18 Sep 2012 17:03:36 +0000
Date: Tue, 18 Sep 2012 18:03:36 +0100
From: Tim Deegan <tim@xen.org>
To: Matt Wilson <msw@amazon.com>
Message-ID: <20120918170336.GA86732@ocelot.phlegethon.org>
References: <patchbomb.1346992557@u002268147cd4502c336d.ant.amazon.com>
	<3b3582f4dc423daa8040.1346992558@u002268147cd4502c336d.ant.amazon.com>
	<1347874964.14977.34.camel@zakaz.uk.xensource.com>
	<20120917170814.GA22382@u002268147cd4502c336d.ant.amazon.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120917170814.GA22382@u002268147cd4502c336d.ant.amazon.com>
User-Agent: Mutt/1.4.2.1i
Cc: 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 1 of 2 v3] tools: check for documentation
	generation tools at configure 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

At 10:08 -0700 on 17 Sep (1347876501), Matt Wilson wrote:
> While we're discussing expanding the coverage of ./configure, I
> wonder: what (if any) is the resistance to requiring ./configure to
> build the xen/ tree?

There's nothing in the hypervisor build that needs to be adjusted to
match the run-time userspace.  So if you're a hypervisor maintainer it
just introduces all the charming idiosyncracies of autotools without
providing any benefit.  E.g., this:

 checking for yajl_alloc in -lyajl... no
 configure: error: Could not find yajl

should not stop me building Xen.  Also, as I said before, autoconf is
the thin end of a slippery wedge: the answer to any autotools problem is
always more autotools, and I choose to make my stand here rather than
have the argument later about why we shouldn't be using libtool. :)

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 18 17:28:43 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Sep 2012 17:28:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TE1ax-0006Rd-LY; Tue, 18 Sep 2012 17:28:23 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ketuzsezr@gmail.com>) id 1TE1av-0006RY-SW
	for xen-devel@lists.xen.org; Tue, 18 Sep 2012 17:28:22 +0000
Received: from [85.158.139.211:32550] by server-10.bemta-5.messagelabs.com id
	E2/1B-10969-53FA8505; Tue, 18 Sep 2012 17:28:21 +0000
X-Env-Sender: ketuzsezr@gmail.com
X-Msg-Ref: server-12.tower-206.messagelabs.com!1347989299!18058891!1
X-Originating-IP: [209.85.216.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9232 invoked from network); 18 Sep 2012 17:28:20 -0000
Received: from mail-qa0-f45.google.com (HELO mail-qa0-f45.google.com)
	(209.85.216.45)
	by server-12.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Sep 2012 17:28:20 -0000
Received: by qadc10 with SMTP id c10so3085021qad.11
	for <xen-devel@lists.xen.org>; Tue, 18 Sep 2012 10:28:19 -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:content-transfer-encoding
	:in-reply-to:user-agent;
	bh=43SbIdeCopyUCreL7TYlj93m8/v0z5agh8Sc0pJ4tr4=;
	b=RlP3/oAfubReovTx96opSD7QgR0EFkDmp3pXwj7cA/x5ll1LbzxL0gp0cAZgpSZOxI
	YIVKny5GpJFHtfpQJDOV5GZSQx0P3wwaZbSADl/fs8kZJkKNgxeH7hYtQ2/novoWWGV/
	JNXipXAqPvvvKIPOsfC0j+W6psGw/1vHJR+qSHZRI16d0wKH2D8J9AtoghkVJ8Qi88fa
	tFw8ZdwSqWKNqYghHENOi0B8dlAX+znFmjV8LqgpiTb4JDeyBFN/Fll2GnWtEeRUc26x
	Ox9qU0Iwe3ghYd2X6nK6FHQKMlTrE+i0DtEf3MBuRxyUTuA+qWzrSo8pXhhV5/YJhtzT
	JVqw==
Received: by 10.224.191.130 with SMTP id dm2mr937777qab.98.1347989299093;
	Tue, 18 Sep 2012 10:28:19 -0700 (PDT)
Received: from phenom.dumpdata.com
	(50-195-21-189-static.hfc.comcastbusiness.net. [50.195.21.189])
	by mx.google.com with ESMTPS id ha5sm656807qab.1.2012.09.18.10.28.17
	(version=TLSv1/SSLv3 cipher=OTHER);
	Tue, 18 Sep 2012 10:28:18 -0700 (PDT)
Date: Tue, 18 Sep 2012 13:17:28 -0400
From: Konrad Rzeszutek Wilk <konrad@kernel.org>
To: Javier Marcet <jmarcet@gmail.com>
Message-ID: <20120918171725.GA14462@phenom.dumpdata.com>
References: <CAAnFQG9TZj=SxYK_jxqN=M6L40vL=AZu9EM2tbEffPhkL1s8FA@mail.gmail.com>
	<CACJDEmqdqA6CE9SgLL2QCNmQH1dOX0_4OHfJfzes+G6bEkQ7FA@mail.gmail.com>
	<CAAnFQG-8Fkunv6R8+GCLAH4yQCx4-Nn0zN_Ntsf0wsh5yXeihQ@mail.gmail.com>
	<20120917142851.GB14012@phenom.dumpdata.com>
	<CAAnFQG9bUUU8OBeKxYh=O3rRrnEPb4r1bPCr-EHWHuUS8shBhA@mail.gmail.com>
	<CAAnFQG_VnZOYs3SJvO1Gc8P98kOW=6Wxc7tM_vEF8GiACgeVWg@mail.gmail.com>
	<CAAnFQG9s=Yh4od18q8xDOD7ukA4uurxCKWiLrULFkP66Zc+iPg@mail.gmail.com>
	<CAAnFQG9PuzRLSsCS8m_0VUeV+ZaCwK3zsbinxtuFBfdSihJknw@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAAnFQG9PuzRLSsCS8m_0VUeV+ZaCwK3zsbinxtuFBfdSihJknw@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: Xen Devel Mailing list <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.2.0-rc4 issues with DVB tuner
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="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, Sep 18, 2012 at 10:41:37AM +0200, Javier Marcet wrote:
> On Tue, Sep 18, 2012 at 2:08 AM, Javier Marcet <jmarcet@gmail.com> wrote:
> =

> Hi,
> =

> > Still nothing. Not even enabling the debug options within the DVB
> > subsystem I get
> > anything which doesn't look perfectly normal, exactly like when it's
> > working fine.
> >
> > I have just posted a message on the linux media mailing list looking
> > for some help
> > from the dvb maintainers.
> =

> I have some news from the linux-media mailing list. There, Devin Heitmuel=
ler,
> said this:
> =

> """
> > Initially I thought Xen would be the cause of the problem, but after
> > having written on
> > the Xen development mailing list and talked about it with a couple
> > developers, it isn't
> > very clear where the problem is. So far I haven't been able to get the
> > smallest warning
> > or error.
> =

> This is a very common problem when attempting to use any PCI/PCIe
> tuner under a hypervisor.  Essentially the issue is all of the
> virtualization solutions provide very poor interrupt latency, which
> results in the data being lost.
> =

> Devices delivering a high bitrate stream of data in realtime are much
> more likely for this problem to be visible since such devices have
> very little buffering (it's not like a hard drive controller where it
> can just deliver the data slower).  The problem is not specific to the
> cx23885 - pretty much all of the PCI/PCIe bridges used in tuner cards
> work this way, and they cannot really be blamed for expecting to run
> in an environment with really crappy interrupt latency.
> =

> I won't go as far as to say, "abandon all hope", but you're not really
> likely to find any help in this forum.
> """

Not sure about the interrupt latency. If you run this little program
http://darnok.org/xen/read_interrupts.c
when capturing in both dom0 and in baremetal are the rate about the
same?
> =

> What I don=B4t understand is how graphics pass through even works
> and a tuner card has problems due to the introduced latencies in the
> IRQs.

The latency is very very miniscule. One could actually verify that this
is a problem by inserting said latency in the driver so that under
baremetal the latency would show up.

But the other issue is that if the data is being lost you would at least
get some. So the buffers ought to have "something" in them? Maybe that
depends on what compression you use on the coder? If you jus do YUV420
or the RGB variants and just do a simple 'cat /dev/vide0 > /tmp/file'
does the output contain anything? Or is just a blob of empty data?

> =

> Do you have any more info about this?

The other issue could be related to the vmalloc_32 being in usage
and not using the DMA API.

I recall posting a patch for this .. Ah:
http://lists.xen.org/archives/html/xen-devel/2012-01/msg01927.html

Perhaps this is the issue?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 18 17:28:43 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Sep 2012 17:28:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TE1ax-0006Rd-LY; Tue, 18 Sep 2012 17:28:23 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ketuzsezr@gmail.com>) id 1TE1av-0006RY-SW
	for xen-devel@lists.xen.org; Tue, 18 Sep 2012 17:28:22 +0000
Received: from [85.158.139.211:32550] by server-10.bemta-5.messagelabs.com id
	E2/1B-10969-53FA8505; Tue, 18 Sep 2012 17:28:21 +0000
X-Env-Sender: ketuzsezr@gmail.com
X-Msg-Ref: server-12.tower-206.messagelabs.com!1347989299!18058891!1
X-Originating-IP: [209.85.216.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9232 invoked from network); 18 Sep 2012 17:28:20 -0000
Received: from mail-qa0-f45.google.com (HELO mail-qa0-f45.google.com)
	(209.85.216.45)
	by server-12.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Sep 2012 17:28:20 -0000
Received: by qadc10 with SMTP id c10so3085021qad.11
	for <xen-devel@lists.xen.org>; Tue, 18 Sep 2012 10:28:19 -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:content-transfer-encoding
	:in-reply-to:user-agent;
	bh=43SbIdeCopyUCreL7TYlj93m8/v0z5agh8Sc0pJ4tr4=;
	b=RlP3/oAfubReovTx96opSD7QgR0EFkDmp3pXwj7cA/x5ll1LbzxL0gp0cAZgpSZOxI
	YIVKny5GpJFHtfpQJDOV5GZSQx0P3wwaZbSADl/fs8kZJkKNgxeH7hYtQ2/novoWWGV/
	JNXipXAqPvvvKIPOsfC0j+W6psGw/1vHJR+qSHZRI16d0wKH2D8J9AtoghkVJ8Qi88fa
	tFw8ZdwSqWKNqYghHENOi0B8dlAX+znFmjV8LqgpiTb4JDeyBFN/Fll2GnWtEeRUc26x
	Ox9qU0Iwe3ghYd2X6nK6FHQKMlTrE+i0DtEf3MBuRxyUTuA+qWzrSo8pXhhV5/YJhtzT
	JVqw==
Received: by 10.224.191.130 with SMTP id dm2mr937777qab.98.1347989299093;
	Tue, 18 Sep 2012 10:28:19 -0700 (PDT)
Received: from phenom.dumpdata.com
	(50-195-21-189-static.hfc.comcastbusiness.net. [50.195.21.189])
	by mx.google.com with ESMTPS id ha5sm656807qab.1.2012.09.18.10.28.17
	(version=TLSv1/SSLv3 cipher=OTHER);
	Tue, 18 Sep 2012 10:28:18 -0700 (PDT)
Date: Tue, 18 Sep 2012 13:17:28 -0400
From: Konrad Rzeszutek Wilk <konrad@kernel.org>
To: Javier Marcet <jmarcet@gmail.com>
Message-ID: <20120918171725.GA14462@phenom.dumpdata.com>
References: <CAAnFQG9TZj=SxYK_jxqN=M6L40vL=AZu9EM2tbEffPhkL1s8FA@mail.gmail.com>
	<CACJDEmqdqA6CE9SgLL2QCNmQH1dOX0_4OHfJfzes+G6bEkQ7FA@mail.gmail.com>
	<CAAnFQG-8Fkunv6R8+GCLAH4yQCx4-Nn0zN_Ntsf0wsh5yXeihQ@mail.gmail.com>
	<20120917142851.GB14012@phenom.dumpdata.com>
	<CAAnFQG9bUUU8OBeKxYh=O3rRrnEPb4r1bPCr-EHWHuUS8shBhA@mail.gmail.com>
	<CAAnFQG_VnZOYs3SJvO1Gc8P98kOW=6Wxc7tM_vEF8GiACgeVWg@mail.gmail.com>
	<CAAnFQG9s=Yh4od18q8xDOD7ukA4uurxCKWiLrULFkP66Zc+iPg@mail.gmail.com>
	<CAAnFQG9PuzRLSsCS8m_0VUeV+ZaCwK3zsbinxtuFBfdSihJknw@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAAnFQG9PuzRLSsCS8m_0VUeV+ZaCwK3zsbinxtuFBfdSihJknw@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: Xen Devel Mailing list <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.2.0-rc4 issues with DVB tuner
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="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, Sep 18, 2012 at 10:41:37AM +0200, Javier Marcet wrote:
> On Tue, Sep 18, 2012 at 2:08 AM, Javier Marcet <jmarcet@gmail.com> wrote:
> =

> Hi,
> =

> > Still nothing. Not even enabling the debug options within the DVB
> > subsystem I get
> > anything which doesn't look perfectly normal, exactly like when it's
> > working fine.
> >
> > I have just posted a message on the linux media mailing list looking
> > for some help
> > from the dvb maintainers.
> =

> I have some news from the linux-media mailing list. There, Devin Heitmuel=
ler,
> said this:
> =

> """
> > Initially I thought Xen would be the cause of the problem, but after
> > having written on
> > the Xen development mailing list and talked about it with a couple
> > developers, it isn't
> > very clear where the problem is. So far I haven't been able to get the
> > smallest warning
> > or error.
> =

> This is a very common problem when attempting to use any PCI/PCIe
> tuner under a hypervisor.  Essentially the issue is all of the
> virtualization solutions provide very poor interrupt latency, which
> results in the data being lost.
> =

> Devices delivering a high bitrate stream of data in realtime are much
> more likely for this problem to be visible since such devices have
> very little buffering (it's not like a hard drive controller where it
> can just deliver the data slower).  The problem is not specific to the
> cx23885 - pretty much all of the PCI/PCIe bridges used in tuner cards
> work this way, and they cannot really be blamed for expecting to run
> in an environment with really crappy interrupt latency.
> =

> I won't go as far as to say, "abandon all hope", but you're not really
> likely to find any help in this forum.
> """

Not sure about the interrupt latency. If you run this little program
http://darnok.org/xen/read_interrupts.c
when capturing in both dom0 and in baremetal are the rate about the
same?
> =

> What I don=B4t understand is how graphics pass through even works
> and a tuner card has problems due to the introduced latencies in the
> IRQs.

The latency is very very miniscule. One could actually verify that this
is a problem by inserting said latency in the driver so that under
baremetal the latency would show up.

But the other issue is that if the data is being lost you would at least
get some. So the buffers ought to have "something" in them? Maybe that
depends on what compression you use on the coder? If you jus do YUV420
or the RGB variants and just do a simple 'cat /dev/vide0 > /tmp/file'
does the output contain anything? Or is just a blob of empty data?

> =

> Do you have any more info about this?

The other issue could be related to the vmalloc_32 being in usage
and not using the DMA API.

I recall posting a patch for this .. Ah:
http://lists.xen.org/archives/html/xen-devel/2012-01/msg01927.html

Perhaps this is the issue?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 18 17:35:51 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Sep 2012 17:35: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 1TE1hp-0006kB-IX; Tue, 18 Sep 2012 17:35:29 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <matthew.fioravante@jhuapl.edu>) id 1TE1hn-0006js-NI
	for xen-devel@lists.xensource.com; Tue, 18 Sep 2012 17:35:28 +0000
X-Env-Sender: matthew.fioravante@jhuapl.edu
X-Msg-Ref: server-5.tower-27.messagelabs.com!1347989719!8107635!1
X-Originating-IP: [128.244.251.36]
X-SpamReason: No, hits=0.1 required=7.0 tests=HTML_30_40,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_23,UNPARSEABLE_RELAY,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32133 invoked from network); 18 Sep 2012 17:35:20 -0000
Received: from pilot.jhuapl.edu (HELO jhuapl.edu) (128.244.251.36)
	by server-5.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 18 Sep 2012 17:35:20 -0000
Received: from ([128.244.207.89])
	by pilot.jhuapl.edu with ESMTP with TLS id 63GHCH1.153145993;
	Tue, 18 Sep 2012 13:35:03 -0400
Message-ID: <5058B07C.1070404@jhuapl.edu>
Date: Tue, 18 Sep 2012 13:33:48 -0400
From: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120827 Thunderbird/15.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <50576368.3070007@jhuapl.edu>
	<1347953926.25803.89.camel@dagon.hellion.org.uk>
In-Reply-To: <1347953926.25803.89.camel@dagon.hellion.org.uk>
X-Enigmail-Version: 1.4.4
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] Upgrade vtpmd to berlios version 0.7.4
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============6271241676353502840=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a cryptographically signed message in MIME format.

--===============6271241676353502840==
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms050601030502070606050109"

This is a cryptographically signed message in MIME format.

--------------ms050601030502070606050109
Content-Type: multipart/alternative;
 boundary="------------010702040904090502060006"

This is a multi-part message in MIME format.
--------------010702040904090502060006
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On 09/18/2012 03:38 AM, Ian Campbell wrote:
> On Mon, 2012-09-17 at 18:52 +0100, Matthew Fioravante wrote:
>> What will follow soon are updates to vtpmd, vtpm_manager, xm, xl,
>> mini-os, and new vtpm and vtpm manager stub domains.
> No need to update xm any more, it is deprecated in 4.2.
I have just one small patch for xm coming. You can decide if you want to
accept or not. Its a small addition.
>
> Who or what is/are Berlios? Are they (actively) maintaining the vTPM?
The berlios tpm emulator is what vtpm is based off of.
http://tpm-emulator.berlios.de/

Essentially vtpmd and vtpm-stubdom (coming in a patch) are just small
patches for the tpm emulator to allow it to run in the vtpm framework.
The older version of the emulator required more invasive patching. The
newer one lets you set some function pointers to override functionality
such as saving and loading to disk, making it much easier and simpler to
modify it to become a vtpm.
>
> Perhaps we should consider making this stuff an external dependency
> rather than importing it into our code base? This could be done either
> as a simple dependency (i.e. require vtpm to be installed before
> building) or as a repo cloned during build (like how we handle qemu and=

> seabios etc).
>
This might be workable. The vtpm system has 2 mini-so stubdoms and 3
mini-os tpm drivers. Does mini-os/stubdom have a nice way of building
stuff out of tree? It doesn't appear so at the moment. The whole stubdom
setup is basically one large monolithic makefile. vtpm domains also
require building openssl, polarssl, and libgmp in the stubdom cross root.=


Should the tpm drivers should be included in mini-os for potential use
by other projects or also kept in their own separate tree? They are GPL
drivers so maybe out of tree makes more sense.

vtpmd and vtpm_managerdom (deprecated, the old way of running vtpms as
processes in dom0, instead of separate domains) could easily be moved
out of tree. They are just binaries installed on the system.

vtpm support for xm/xl probably has to stay in xen. Unless someone plans
on making a plugin architecture for xl. There are also the hotplug
scripts, but those go away with xl.

>> The first patch I'd like to submit upgrades vtpmd to version 0.7.4
>>
>> This patch does the following:
>> -add checks to configure to check for cmake (required by berlios 0.7.4=
)
> Is the model with cmake that it is required on all the end systems
> building the project (like make), or is it only needed on the project
> maintainer's system (like autoconf/make)?
Its the equivalent of running a configure script, so its needed on end
systems. Also you have to download and patch the tpm emulator before
running cmake, so if we did want to avoid its usage on end systems we
would have to ship the entire source code of the patched emulator.
>
>> -removes all of the 0.5.1 patches
>> -adds a single patch for 0.7.4
>> -cleans up the makefile, should work for parallel make (avoiding
>> version.h discussion from august 2012)
>> -builds vtpmd to use berlios 0.7.4
>> -Remoed the tpm_emualtor build option. berlios itself provides a kerne=
l
>> module if you want to use it in dom0 to emulate the physical tpm.
> Is there going to be an associated documentation update/refresh?
Right now I don't have a formal doc but I want to write one. I'm looking
into getting some time to do this.
>
>> Signed of by: Matthew Fioravante matthew.fioravante@jhuapl.edu
> Ian.
>


--------------010702040904090502060006
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">
    <div class=3D"moz-cite-prefix">On 09/18/2012 03:38 AM, Ian Campbell
      wrote:<br>
    </div>
    <blockquote
      cite=3D"mid:1347953926.25803.89.camel@dagon.hellion.org.uk"
      type=3D"cite">
      <pre wrap=3D"">On Mon, 2012-09-17 at 18:52 +0100, Matthew Fioravant=
e wrote:
</pre>
      <blockquote type=3D"cite">
        <pre wrap=3D"">What will follow soon are updates to vtpmd, vtpm_m=
anager, xm, xl,
mini-os, and new vtpm and vtpm manager stub domains.
</pre>
      </blockquote>
      <pre wrap=3D"">
No need to update xm any more, it is deprecated in 4.2.</pre>
    </blockquote>
    I have just one small patch for xm coming. You can decide if you
    want to accept or not. Its a small addition.<br>
    <blockquote
      cite=3D"mid:1347953926.25803.89.camel@dagon.hellion.org.uk"
      type=3D"cite">
      <pre wrap=3D"">

Who or what is/are Berlios? Are they (actively) maintaining the vTPM?</pr=
e>
    </blockquote>
    The berlios tpm emulator is what vtpm is based off of.<br>
    <meta http-equiv=3D"content-type" content=3D"text/html;
      charset=3DISO-8859-1">
    <a href=3D"http://tpm-emulator.berlios.de/">http://tpm-emulator.berli=
os.de/</a><br>
    <br>
    Essentially vtpmd and vtpm-stubdom (coming in a patch) are just
    small patches for the tpm emulator to allow it to run in the vtpm
    framework. The older version of the emulator required more invasive
    patching. The newer one lets you set some function pointers to
    override functionality such as saving and loading to disk, making it
    much easier and simpler to modify it to become a vtpm.<br>
    <blockquote
      cite=3D"mid:1347953926.25803.89.camel@dagon.hellion.org.uk"
      type=3D"cite">
      <pre wrap=3D"">

Perhaps we should consider making this stuff an external dependency
rather than importing it into our code base? This could be done either
as a simple dependency (i.e. require vtpm to be installed before
building) or as a repo cloned during build (like how we handle qemu and
seabios etc).

</pre>
    </blockquote>
    This might be workable. The vtpm system has 2 mini-so stubdoms and 3
    mini-os tpm drivers. Does mini-os/stubdom have a nice way of
    building stuff out of tree? It doesn't appear so at the moment. The
    whole stubdom setup is basically one large monolithic makefile. vtpm
    domains also require building openssl, polarssl, and libgmp in the
    stubdom cross root.<br>
    <br>
    Should the tpm drivers should be included in mini-os for potential
    use by other projects or also kept in their own separate tree? They
    are GPL drivers so maybe out of tree makes more sense.<br>
    <br>
    vtpmd and vtpm_managerdom (deprecated, the old way of running vtpms
    as processes in dom0, instead of separate domains) could easily be
    moved out of tree. They are just binaries installed on the system.<br=
>
    <br>
    vtpm support for xm/xl probably has to stay in xen. Unless someone
    plans on making a plugin architecture for xl. There are also the
    hotplug scripts, but those go away with xl.<br>
    <br>
    <blockquote
      cite=3D"mid:1347953926.25803.89.camel@dagon.hellion.org.uk"
      type=3D"cite">
      <blockquote type=3D"cite">
        <pre wrap=3D"">The first patch I'd like to submit upgrades vtpmd =
to version 0.7.4

This patch does the following:
-add checks to configure to check for cmake (required by berlios 0.7.4)
</pre>
      </blockquote>
      <pre wrap=3D"">
Is the model with cmake that it is required on all the end systems
building the project (like make), or is it only needed on the project
maintainer's system (like autoconf/make)?</pre>
    </blockquote>
    Its the equivalent of running a configure script, so its needed on
    end systems. Also you have to download and patch the tpm emulator
    before running cmake, so if we did want to avoid its usage on end
    systems we would have to ship the entire source code of the patched
    emulator.<br>
    <blockquote
      cite=3D"mid:1347953926.25803.89.camel@dagon.hellion.org.uk"
      type=3D"cite">
      <pre wrap=3D"">

</pre>
      <blockquote type=3D"cite">
        <pre wrap=3D"">-removes all of the 0.5.1 patches
-adds a single patch for 0.7.4
-cleans up the makefile, should work for parallel make (avoiding
version.h discussion from august 2012)
-builds vtpmd to use berlios 0.7.4
-Remoed the tpm_emualtor build option. berlios itself provides a kernel
module if you want to use it in dom0 to emulate the physical tpm.
</pre>
      </blockquote>
      <pre wrap=3D"">
Is there going to be an associated documentation update/refresh?</pre>
    </blockquote>
    Right now I don't have a formal doc but I want to write one. I'm
    looking into getting some time to do this.<br>
    <blockquote
      cite=3D"mid:1347953926.25803.89.camel@dagon.hellion.org.uk"
      type=3D"cite">
      <pre wrap=3D"">

</pre>
      <blockquote type=3D"cite">
        <pre wrap=3D"">
Signed of by: Matthew Fioravante <a class=3D"moz-txt-link-abbreviated" hr=
ef=3D"mailto:matthew.fioravante@jhuapl.edu">matthew.fioravante@jhuapl.edu=
</a>
</pre>
      </blockquote>
      <pre wrap=3D"">
Ian.

</pre>
    </blockquote>
    <br>
  </body>
</html>

--------------010702040904090502060006--

--------------ms050601030502070606050109
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIDyjCC
A8YwggMvoAMCAQICBD/xyf0wDQYJKoZIhvcNAQEFBQAwLzELMAkGA1UEBhMCVVMxDzANBgNV
BAoTBkpIVUFQTDEPMA0GA1UECxMGQklTRENBMB4XDTEwMDYxMTE4MjIwNloXDTEzMDYxMTE4
NTIwNlowZjELMAkGA1UEBhMCVVMxDzANBgNVBAoTBkpIVUFQTDEPMA0GA1UECxMGUGVvcGxl
MTUwFgYDVQQLEw9WUE5Hcm91cC1CSVNEQ0EwGwYDVQQDExRNYXR0aGV3IEUgRmlvcmF2YW50
ZTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAnpbwVSP6o1Nb5lcW7dd3yTo9iBJdi7qz
4nANOMFPK7JOy5npKN1iiousl28U/scUJES55gPwAWYJK3uVyQAsA4adgDKi5DoD1UHDQEwp
bY7iHLJeq0NPr4BqYNqnCFPbE6HC8zSJrr4qKn+gVUQT39SIFqdiIPJwZL8FYTRQ/zsCAwEA
AaOCAbYwggGyMAsGA1UdDwQEAwIHgDArBgNVHRAEJDAigA8yMDEwMDYxMTE4MjIwNlqBDzIw
MTIwNzE3MjI1MjA2WjAbBg0rBgEEAbMlCwMBAQEBBAoWCGZpb3JhbWUxMBsGDSsGAQQBsyUL
AwEBAQIEChIIMDAxMDQyNjEwWAYJYIZIAYb6ax4BBEsMSVRoZSBwcml2YXRlIGtleSBjb3Jy
ZXNwb25kaW5nIHRvIHRoaXMgY2VydGlmaWNhdGUgbWF5IGhhdmUgYmVlbiBleHBvcnRlZC4w
KAYDVR0RBCEwH4EdTWF0dGhldy5GaW9yYXZhbnRlQGpodWFwbC5lZHUwUgYDVR0fBEswSTBH
oEWgQ6RBMD8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJU0RD
QTEOMAwGA1UEAxMFQ1JMNTYwHwYDVR0jBBgwFoAUCDUpmxH52EU2CyWmF2EJMB1yqeswHQYD
VR0OBBYEFO6LYxg6r9wHZ+zdQtBHn1dZ/YTNMAkGA1UdEwQCMAAwGQYJKoZIhvZ9B0EABAww
ChsEVjcuMQMCBLAwDQYJKoZIhvcNAQEFBQADgYEAJO9HQh4YNChVLzuZqK5ARJARD8JoujGZ
fdo75quvg2jXFQe2sEjvLnxJZgm/pv8fdZakq48CWwjYHKuvIp7sDjTEsQfo+y7SpN/N2NvJ
WU5SqfK1VgYtNLRRoGJUB5Q1aZ+Dg95g3kqpyfpUMISJL8IKVLtJVfN4fggFVUYZ9wwxggGr
MIIBpwIBATA3MC8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJ
U0RDQQIEP/HJ/TAJBgUrDgMCGgUAoIHLMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ
KoZIhvcNAQkFMQ8XDTEyMDkxODE3MzM0OFowIwYJKoZIhvcNAQkEMRYEFMeGK1UGWXEmHJoC
sunoiQlCqoHzMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAK
BggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI
KoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEgYAly748IwYjEetIdEZMOHsgUxY4M04LIPcc
6hDSgvDR2QfoEbOWTDWLP4OE3b2YYwo3q0qlfPRvvDDm9SORi9vFVXeKxevgKFCoJenn6adI
mtDp4PLfqVdmjyZWddGFjS9bfiqbqz31Je0OqahVbH1fW5ZxRRnl0JI9ALWJx660hgAAAAAA
AA==
--------------ms050601030502070606050109--


--===============6271241676353502840==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============6271241676353502840==--


From xen-devel-bounces@lists.xen.org Tue Sep 18 17:35:51 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Sep 2012 17:35: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 1TE1hp-0006kB-IX; Tue, 18 Sep 2012 17:35:29 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <matthew.fioravante@jhuapl.edu>) id 1TE1hn-0006js-NI
	for xen-devel@lists.xensource.com; Tue, 18 Sep 2012 17:35:28 +0000
X-Env-Sender: matthew.fioravante@jhuapl.edu
X-Msg-Ref: server-5.tower-27.messagelabs.com!1347989719!8107635!1
X-Originating-IP: [128.244.251.36]
X-SpamReason: No, hits=0.1 required=7.0 tests=HTML_30_40,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_23,UNPARSEABLE_RELAY,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32133 invoked from network); 18 Sep 2012 17:35:20 -0000
Received: from pilot.jhuapl.edu (HELO jhuapl.edu) (128.244.251.36)
	by server-5.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 18 Sep 2012 17:35:20 -0000
Received: from ([128.244.207.89])
	by pilot.jhuapl.edu with ESMTP with TLS id 63GHCH1.153145993;
	Tue, 18 Sep 2012 13:35:03 -0400
Message-ID: <5058B07C.1070404@jhuapl.edu>
Date: Tue, 18 Sep 2012 13:33:48 -0400
From: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120827 Thunderbird/15.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <50576368.3070007@jhuapl.edu>
	<1347953926.25803.89.camel@dagon.hellion.org.uk>
In-Reply-To: <1347953926.25803.89.camel@dagon.hellion.org.uk>
X-Enigmail-Version: 1.4.4
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] Upgrade vtpmd to berlios version 0.7.4
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============6271241676353502840=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a cryptographically signed message in MIME format.

--===============6271241676353502840==
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms050601030502070606050109"

This is a cryptographically signed message in MIME format.

--------------ms050601030502070606050109
Content-Type: multipart/alternative;
 boundary="------------010702040904090502060006"

This is a multi-part message in MIME format.
--------------010702040904090502060006
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On 09/18/2012 03:38 AM, Ian Campbell wrote:
> On Mon, 2012-09-17 at 18:52 +0100, Matthew Fioravante wrote:
>> What will follow soon are updates to vtpmd, vtpm_manager, xm, xl,
>> mini-os, and new vtpm and vtpm manager stub domains.
> No need to update xm any more, it is deprecated in 4.2.
I have just one small patch for xm coming. You can decide if you want to
accept or not. Its a small addition.
>
> Who or what is/are Berlios? Are they (actively) maintaining the vTPM?
The berlios tpm emulator is what vtpm is based off of.
http://tpm-emulator.berlios.de/

Essentially vtpmd and vtpm-stubdom (coming in a patch) are just small
patches for the tpm emulator to allow it to run in the vtpm framework.
The older version of the emulator required more invasive patching. The
newer one lets you set some function pointers to override functionality
such as saving and loading to disk, making it much easier and simpler to
modify it to become a vtpm.
>
> Perhaps we should consider making this stuff an external dependency
> rather than importing it into our code base? This could be done either
> as a simple dependency (i.e. require vtpm to be installed before
> building) or as a repo cloned during build (like how we handle qemu and=

> seabios etc).
>
This might be workable. The vtpm system has 2 mini-so stubdoms and 3
mini-os tpm drivers. Does mini-os/stubdom have a nice way of building
stuff out of tree? It doesn't appear so at the moment. The whole stubdom
setup is basically one large monolithic makefile. vtpm domains also
require building openssl, polarssl, and libgmp in the stubdom cross root.=


Should the tpm drivers should be included in mini-os for potential use
by other projects or also kept in their own separate tree? They are GPL
drivers so maybe out of tree makes more sense.

vtpmd and vtpm_managerdom (deprecated, the old way of running vtpms as
processes in dom0, instead of separate domains) could easily be moved
out of tree. They are just binaries installed on the system.

vtpm support for xm/xl probably has to stay in xen. Unless someone plans
on making a plugin architecture for xl. There are also the hotplug
scripts, but those go away with xl.

>> The first patch I'd like to submit upgrades vtpmd to version 0.7.4
>>
>> This patch does the following:
>> -add checks to configure to check for cmake (required by berlios 0.7.4=
)
> Is the model with cmake that it is required on all the end systems
> building the project (like make), or is it only needed on the project
> maintainer's system (like autoconf/make)?
Its the equivalent of running a configure script, so its needed on end
systems. Also you have to download and patch the tpm emulator before
running cmake, so if we did want to avoid its usage on end systems we
would have to ship the entire source code of the patched emulator.
>
>> -removes all of the 0.5.1 patches
>> -adds a single patch for 0.7.4
>> -cleans up the makefile, should work for parallel make (avoiding
>> version.h discussion from august 2012)
>> -builds vtpmd to use berlios 0.7.4
>> -Remoed the tpm_emualtor build option. berlios itself provides a kerne=
l
>> module if you want to use it in dom0 to emulate the physical tpm.
> Is there going to be an associated documentation update/refresh?
Right now I don't have a formal doc but I want to write one. I'm looking
into getting some time to do this.
>
>> Signed of by: Matthew Fioravante matthew.fioravante@jhuapl.edu
> Ian.
>


--------------010702040904090502060006
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">
    <div class=3D"moz-cite-prefix">On 09/18/2012 03:38 AM, Ian Campbell
      wrote:<br>
    </div>
    <blockquote
      cite=3D"mid:1347953926.25803.89.camel@dagon.hellion.org.uk"
      type=3D"cite">
      <pre wrap=3D"">On Mon, 2012-09-17 at 18:52 +0100, Matthew Fioravant=
e wrote:
</pre>
      <blockquote type=3D"cite">
        <pre wrap=3D"">What will follow soon are updates to vtpmd, vtpm_m=
anager, xm, xl,
mini-os, and new vtpm and vtpm manager stub domains.
</pre>
      </blockquote>
      <pre wrap=3D"">
No need to update xm any more, it is deprecated in 4.2.</pre>
    </blockquote>
    I have just one small patch for xm coming. You can decide if you
    want to accept or not. Its a small addition.<br>
    <blockquote
      cite=3D"mid:1347953926.25803.89.camel@dagon.hellion.org.uk"
      type=3D"cite">
      <pre wrap=3D"">

Who or what is/are Berlios? Are they (actively) maintaining the vTPM?</pr=
e>
    </blockquote>
    The berlios tpm emulator is what vtpm is based off of.<br>
    <meta http-equiv=3D"content-type" content=3D"text/html;
      charset=3DISO-8859-1">
    <a href=3D"http://tpm-emulator.berlios.de/">http://tpm-emulator.berli=
os.de/</a><br>
    <br>
    Essentially vtpmd and vtpm-stubdom (coming in a patch) are just
    small patches for the tpm emulator to allow it to run in the vtpm
    framework. The older version of the emulator required more invasive
    patching. The newer one lets you set some function pointers to
    override functionality such as saving and loading to disk, making it
    much easier and simpler to modify it to become a vtpm.<br>
    <blockquote
      cite=3D"mid:1347953926.25803.89.camel@dagon.hellion.org.uk"
      type=3D"cite">
      <pre wrap=3D"">

Perhaps we should consider making this stuff an external dependency
rather than importing it into our code base? This could be done either
as a simple dependency (i.e. require vtpm to be installed before
building) or as a repo cloned during build (like how we handle qemu and
seabios etc).

</pre>
    </blockquote>
    This might be workable. The vtpm system has 2 mini-so stubdoms and 3
    mini-os tpm drivers. Does mini-os/stubdom have a nice way of
    building stuff out of tree? It doesn't appear so at the moment. The
    whole stubdom setup is basically one large monolithic makefile. vtpm
    domains also require building openssl, polarssl, and libgmp in the
    stubdom cross root.<br>
    <br>
    Should the tpm drivers should be included in mini-os for potential
    use by other projects or also kept in their own separate tree? They
    are GPL drivers so maybe out of tree makes more sense.<br>
    <br>
    vtpmd and vtpm_managerdom (deprecated, the old way of running vtpms
    as processes in dom0, instead of separate domains) could easily be
    moved out of tree. They are just binaries installed on the system.<br=
>
    <br>
    vtpm support for xm/xl probably has to stay in xen. Unless someone
    plans on making a plugin architecture for xl. There are also the
    hotplug scripts, but those go away with xl.<br>
    <br>
    <blockquote
      cite=3D"mid:1347953926.25803.89.camel@dagon.hellion.org.uk"
      type=3D"cite">
      <blockquote type=3D"cite">
        <pre wrap=3D"">The first patch I'd like to submit upgrades vtpmd =
to version 0.7.4

This patch does the following:
-add checks to configure to check for cmake (required by berlios 0.7.4)
</pre>
      </blockquote>
      <pre wrap=3D"">
Is the model with cmake that it is required on all the end systems
building the project (like make), or is it only needed on the project
maintainer's system (like autoconf/make)?</pre>
    </blockquote>
    Its the equivalent of running a configure script, so its needed on
    end systems. Also you have to download and patch the tpm emulator
    before running cmake, so if we did want to avoid its usage on end
    systems we would have to ship the entire source code of the patched
    emulator.<br>
    <blockquote
      cite=3D"mid:1347953926.25803.89.camel@dagon.hellion.org.uk"
      type=3D"cite">
      <pre wrap=3D"">

</pre>
      <blockquote type=3D"cite">
        <pre wrap=3D"">-removes all of the 0.5.1 patches
-adds a single patch for 0.7.4
-cleans up the makefile, should work for parallel make (avoiding
version.h discussion from august 2012)
-builds vtpmd to use berlios 0.7.4
-Remoed the tpm_emualtor build option. berlios itself provides a kernel
module if you want to use it in dom0 to emulate the physical tpm.
</pre>
      </blockquote>
      <pre wrap=3D"">
Is there going to be an associated documentation update/refresh?</pre>
    </blockquote>
    Right now I don't have a formal doc but I want to write one. I'm
    looking into getting some time to do this.<br>
    <blockquote
      cite=3D"mid:1347953926.25803.89.camel@dagon.hellion.org.uk"
      type=3D"cite">
      <pre wrap=3D"">

</pre>
      <blockquote type=3D"cite">
        <pre wrap=3D"">
Signed of by: Matthew Fioravante <a class=3D"moz-txt-link-abbreviated" hr=
ef=3D"mailto:matthew.fioravante@jhuapl.edu">matthew.fioravante@jhuapl.edu=
</a>
</pre>
      </blockquote>
      <pre wrap=3D"">
Ian.

</pre>
    </blockquote>
    <br>
  </body>
</html>

--------------010702040904090502060006--

--------------ms050601030502070606050109
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIDyjCC
A8YwggMvoAMCAQICBD/xyf0wDQYJKoZIhvcNAQEFBQAwLzELMAkGA1UEBhMCVVMxDzANBgNV
BAoTBkpIVUFQTDEPMA0GA1UECxMGQklTRENBMB4XDTEwMDYxMTE4MjIwNloXDTEzMDYxMTE4
NTIwNlowZjELMAkGA1UEBhMCVVMxDzANBgNVBAoTBkpIVUFQTDEPMA0GA1UECxMGUGVvcGxl
MTUwFgYDVQQLEw9WUE5Hcm91cC1CSVNEQ0EwGwYDVQQDExRNYXR0aGV3IEUgRmlvcmF2YW50
ZTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAnpbwVSP6o1Nb5lcW7dd3yTo9iBJdi7qz
4nANOMFPK7JOy5npKN1iiousl28U/scUJES55gPwAWYJK3uVyQAsA4adgDKi5DoD1UHDQEwp
bY7iHLJeq0NPr4BqYNqnCFPbE6HC8zSJrr4qKn+gVUQT39SIFqdiIPJwZL8FYTRQ/zsCAwEA
AaOCAbYwggGyMAsGA1UdDwQEAwIHgDArBgNVHRAEJDAigA8yMDEwMDYxMTE4MjIwNlqBDzIw
MTIwNzE3MjI1MjA2WjAbBg0rBgEEAbMlCwMBAQEBBAoWCGZpb3JhbWUxMBsGDSsGAQQBsyUL
AwEBAQIEChIIMDAxMDQyNjEwWAYJYIZIAYb6ax4BBEsMSVRoZSBwcml2YXRlIGtleSBjb3Jy
ZXNwb25kaW5nIHRvIHRoaXMgY2VydGlmaWNhdGUgbWF5IGhhdmUgYmVlbiBleHBvcnRlZC4w
KAYDVR0RBCEwH4EdTWF0dGhldy5GaW9yYXZhbnRlQGpodWFwbC5lZHUwUgYDVR0fBEswSTBH
oEWgQ6RBMD8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJU0RD
QTEOMAwGA1UEAxMFQ1JMNTYwHwYDVR0jBBgwFoAUCDUpmxH52EU2CyWmF2EJMB1yqeswHQYD
VR0OBBYEFO6LYxg6r9wHZ+zdQtBHn1dZ/YTNMAkGA1UdEwQCMAAwGQYJKoZIhvZ9B0EABAww
ChsEVjcuMQMCBLAwDQYJKoZIhvcNAQEFBQADgYEAJO9HQh4YNChVLzuZqK5ARJARD8JoujGZ
fdo75quvg2jXFQe2sEjvLnxJZgm/pv8fdZakq48CWwjYHKuvIp7sDjTEsQfo+y7SpN/N2NvJ
WU5SqfK1VgYtNLRRoGJUB5Q1aZ+Dg95g3kqpyfpUMISJL8IKVLtJVfN4fggFVUYZ9wwxggGr
MIIBpwIBATA3MC8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJ
U0RDQQIEP/HJ/TAJBgUrDgMCGgUAoIHLMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ
KoZIhvcNAQkFMQ8XDTEyMDkxODE3MzM0OFowIwYJKoZIhvcNAQkEMRYEFMeGK1UGWXEmHJoC
sunoiQlCqoHzMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAK
BggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI
KoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEgYAly748IwYjEetIdEZMOHsgUxY4M04LIPcc
6hDSgvDR2QfoEbOWTDWLP4OE3b2YYwo3q0qlfPRvvDDm9SORi9vFVXeKxevgKFCoJenn6adI
mtDp4PLfqVdmjyZWddGFjS9bfiqbqz31Je0OqahVbH1fW5ZxRRnl0JI9ALWJx660hgAAAAAA
AA==
--------------ms050601030502070606050109--


--===============6271241676353502840==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============6271241676353502840==--


From xen-devel-bounces@lists.xen.org Tue Sep 18 17:43:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Sep 2012 17:43:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TE1ok-0006vR-K5; Tue, 18 Sep 2012 17:42:38 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <matthew.fioravante@jhuapl.edu>) id 1TE1oj-0006vM-SS
	for xen-devel@lists.xensource.com; Tue, 18 Sep 2012 17:42:38 +0000
Received: from [85.158.143.99:16205] by server-3.bemta-4.messagelabs.com id
	CB/98-08232-D82B8505; Tue, 18 Sep 2012 17:42:37 +0000
X-Env-Sender: matthew.fioravante@jhuapl.edu
X-Msg-Ref: server-2.tower-216.messagelabs.com!1347990155!22670392!1
X-Originating-IP: [128.244.251.36]
X-SpamReason: No, hits=0.0 required=7.0 tests=UNPARSEABLE_RELAY
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21216 invoked from network); 18 Sep 2012 17:42:36 -0000
Received: from pilot.jhuapl.edu (HELO jhuapl.edu) (128.244.251.36)
	by server-2.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 18 Sep 2012 17:42:36 -0000
Received: from ([128.244.207.89])
	by pilot.jhuapl.edu with ESMTP with TLS id 63GHCH1.153146788;
	Tue, 18 Sep 2012 13:41:30 -0400
Message-ID: <5058B1FF.8080301@jhuapl.edu>
Date: Tue, 18 Sep 2012 13:40:15 -0400
From: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120827 Thunderbird/15.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <505793F4.40301@jhuapl.edu>
	<1347954198.25803.92.camel@dagon.hellion.org.uk>
In-Reply-To: <1347954198.25803.92.camel@dagon.hellion.org.uk>
X-Enigmail-Version: 1.4.4
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH vtpm_manager 2/2] Fixes to vtpm 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: multipart/mixed; boundary="===============8555135743231083351=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a cryptographically signed message in MIME format.

--===============8555135743231083351==
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms020504020002000103070808"

This is a cryptographically signed message in MIME format.

--------------ms020504020002000103070808
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On 09/18/2012 03:43 AM, Ian Campbell wrote:
> On Mon, 2012-09-17 at 22:19 +0100, Matthew Fioravante wrote:
>> This patch fixes IO deadlocks in the vtpm hotplug scripts
> Is the switch from awk to gawk a part of this? How?
>
> IIRC we deliberately switched from using gawk specific features to allo=
w
> e.g. mawk to be used. If there is some gawk specific construct used her=
e
> it would be better to recast it in more portable terms IMHO.
I'll test and get back to you on this.
>
>> - set -e
>> + local resp_hex
>> + #send cmd to vtpm_manager and get response
>> + if ! resp_hex=3D`echo "$cmd$(str_to_hex32 $inst)" | vtpmmgrtalk `; t=
hen
> Is this really the command/control interface provided by VTPM? Can we
> not work with upstream to define something more usable?
Unfortunately xen itself is the upstream for vtpm_manager. The
vtpm_manager code is full of bugs and actually needs a complete rewrite.
The amount of careless memory leaks and other bugs I found when trying
to use it were pretty astounding. The first manager patch fixes most of
the ones I could find to get the manager to work properly.

The managers current form in the xen tree is actually pretty unusable.
I don't have time to rewrite the manager, but what I'm offering here is
at least a huge improvement over the old code.
>
> Ian.
>



--------------ms020504020002000103070808
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIDyjCC
A8YwggMvoAMCAQICBD/xyf0wDQYJKoZIhvcNAQEFBQAwLzELMAkGA1UEBhMCVVMxDzANBgNV
BAoTBkpIVUFQTDEPMA0GA1UECxMGQklTRENBMB4XDTEwMDYxMTE4MjIwNloXDTEzMDYxMTE4
NTIwNlowZjELMAkGA1UEBhMCVVMxDzANBgNVBAoTBkpIVUFQTDEPMA0GA1UECxMGUGVvcGxl
MTUwFgYDVQQLEw9WUE5Hcm91cC1CSVNEQ0EwGwYDVQQDExRNYXR0aGV3IEUgRmlvcmF2YW50
ZTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAnpbwVSP6o1Nb5lcW7dd3yTo9iBJdi7qz
4nANOMFPK7JOy5npKN1iiousl28U/scUJES55gPwAWYJK3uVyQAsA4adgDKi5DoD1UHDQEwp
bY7iHLJeq0NPr4BqYNqnCFPbE6HC8zSJrr4qKn+gVUQT39SIFqdiIPJwZL8FYTRQ/zsCAwEA
AaOCAbYwggGyMAsGA1UdDwQEAwIHgDArBgNVHRAEJDAigA8yMDEwMDYxMTE4MjIwNlqBDzIw
MTIwNzE3MjI1MjA2WjAbBg0rBgEEAbMlCwMBAQEBBAoWCGZpb3JhbWUxMBsGDSsGAQQBsyUL
AwEBAQIEChIIMDAxMDQyNjEwWAYJYIZIAYb6ax4BBEsMSVRoZSBwcml2YXRlIGtleSBjb3Jy
ZXNwb25kaW5nIHRvIHRoaXMgY2VydGlmaWNhdGUgbWF5IGhhdmUgYmVlbiBleHBvcnRlZC4w
KAYDVR0RBCEwH4EdTWF0dGhldy5GaW9yYXZhbnRlQGpodWFwbC5lZHUwUgYDVR0fBEswSTBH
oEWgQ6RBMD8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJU0RD
QTEOMAwGA1UEAxMFQ1JMNTYwHwYDVR0jBBgwFoAUCDUpmxH52EU2CyWmF2EJMB1yqeswHQYD
VR0OBBYEFO6LYxg6r9wHZ+zdQtBHn1dZ/YTNMAkGA1UdEwQCMAAwGQYJKoZIhvZ9B0EABAww
ChsEVjcuMQMCBLAwDQYJKoZIhvcNAQEFBQADgYEAJO9HQh4YNChVLzuZqK5ARJARD8JoujGZ
fdo75quvg2jXFQe2sEjvLnxJZgm/pv8fdZakq48CWwjYHKuvIp7sDjTEsQfo+y7SpN/N2NvJ
WU5SqfK1VgYtNLRRoGJUB5Q1aZ+Dg95g3kqpyfpUMISJL8IKVLtJVfN4fggFVUYZ9wwxggGr
MIIBpwIBATA3MC8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJ
U0RDQQIEP/HJ/TAJBgUrDgMCGgUAoIHLMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ
KoZIhvcNAQkFMQ8XDTEyMDkxODE3NDAxNVowIwYJKoZIhvcNAQkEMRYEFOfnE4J6b1tJPTzt
FgC7xwfj+IiFMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAK
BggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI
KoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEgYB+ap3fsmsjmb8wk5cMWWJxLGPeN39uxDF/
aZIKy6X3ocl8IvdDHRMUDbyvyXLnptlZReU3Eq4//6ZaSHZRQC6IHZj1gb7BeGmVS8Y++V/W
eX7MhtkGESvi1eZwkp2EfFzi5hCajKcMRJsYBm6dctGmWHe7MxUwZz71+j+7otK5BwAAAAAA
AA==
--------------ms020504020002000103070808--


--===============8555135743231083351==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============8555135743231083351==--


From xen-devel-bounces@lists.xen.org Tue Sep 18 17:43:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Sep 2012 17:43:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TE1ok-0006vR-K5; Tue, 18 Sep 2012 17:42:38 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <matthew.fioravante@jhuapl.edu>) id 1TE1oj-0006vM-SS
	for xen-devel@lists.xensource.com; Tue, 18 Sep 2012 17:42:38 +0000
Received: from [85.158.143.99:16205] by server-3.bemta-4.messagelabs.com id
	CB/98-08232-D82B8505; Tue, 18 Sep 2012 17:42:37 +0000
X-Env-Sender: matthew.fioravante@jhuapl.edu
X-Msg-Ref: server-2.tower-216.messagelabs.com!1347990155!22670392!1
X-Originating-IP: [128.244.251.36]
X-SpamReason: No, hits=0.0 required=7.0 tests=UNPARSEABLE_RELAY
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21216 invoked from network); 18 Sep 2012 17:42:36 -0000
Received: from pilot.jhuapl.edu (HELO jhuapl.edu) (128.244.251.36)
	by server-2.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 18 Sep 2012 17:42:36 -0000
Received: from ([128.244.207.89])
	by pilot.jhuapl.edu with ESMTP with TLS id 63GHCH1.153146788;
	Tue, 18 Sep 2012 13:41:30 -0400
Message-ID: <5058B1FF.8080301@jhuapl.edu>
Date: Tue, 18 Sep 2012 13:40:15 -0400
From: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120827 Thunderbird/15.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <505793F4.40301@jhuapl.edu>
	<1347954198.25803.92.camel@dagon.hellion.org.uk>
In-Reply-To: <1347954198.25803.92.camel@dagon.hellion.org.uk>
X-Enigmail-Version: 1.4.4
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH vtpm_manager 2/2] Fixes to vtpm 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: multipart/mixed; boundary="===============8555135743231083351=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a cryptographically signed message in MIME format.

--===============8555135743231083351==
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms020504020002000103070808"

This is a cryptographically signed message in MIME format.

--------------ms020504020002000103070808
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On 09/18/2012 03:43 AM, Ian Campbell wrote:
> On Mon, 2012-09-17 at 22:19 +0100, Matthew Fioravante wrote:
>> This patch fixes IO deadlocks in the vtpm hotplug scripts
> Is the switch from awk to gawk a part of this? How?
>
> IIRC we deliberately switched from using gawk specific features to allo=
w
> e.g. mawk to be used. If there is some gawk specific construct used her=
e
> it would be better to recast it in more portable terms IMHO.
I'll test and get back to you on this.
>
>> - set -e
>> + local resp_hex
>> + #send cmd to vtpm_manager and get response
>> + if ! resp_hex=3D`echo "$cmd$(str_to_hex32 $inst)" | vtpmmgrtalk `; t=
hen
> Is this really the command/control interface provided by VTPM? Can we
> not work with upstream to define something more usable?
Unfortunately xen itself is the upstream for vtpm_manager. The
vtpm_manager code is full of bugs and actually needs a complete rewrite.
The amount of careless memory leaks and other bugs I found when trying
to use it were pretty astounding. The first manager patch fixes most of
the ones I could find to get the manager to work properly.

The managers current form in the xen tree is actually pretty unusable.
I don't have time to rewrite the manager, but what I'm offering here is
at least a huge improvement over the old code.
>
> Ian.
>



--------------ms020504020002000103070808
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIDyjCC
A8YwggMvoAMCAQICBD/xyf0wDQYJKoZIhvcNAQEFBQAwLzELMAkGA1UEBhMCVVMxDzANBgNV
BAoTBkpIVUFQTDEPMA0GA1UECxMGQklTRENBMB4XDTEwMDYxMTE4MjIwNloXDTEzMDYxMTE4
NTIwNlowZjELMAkGA1UEBhMCVVMxDzANBgNVBAoTBkpIVUFQTDEPMA0GA1UECxMGUGVvcGxl
MTUwFgYDVQQLEw9WUE5Hcm91cC1CSVNEQ0EwGwYDVQQDExRNYXR0aGV3IEUgRmlvcmF2YW50
ZTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAnpbwVSP6o1Nb5lcW7dd3yTo9iBJdi7qz
4nANOMFPK7JOy5npKN1iiousl28U/scUJES55gPwAWYJK3uVyQAsA4adgDKi5DoD1UHDQEwp
bY7iHLJeq0NPr4BqYNqnCFPbE6HC8zSJrr4qKn+gVUQT39SIFqdiIPJwZL8FYTRQ/zsCAwEA
AaOCAbYwggGyMAsGA1UdDwQEAwIHgDArBgNVHRAEJDAigA8yMDEwMDYxMTE4MjIwNlqBDzIw
MTIwNzE3MjI1MjA2WjAbBg0rBgEEAbMlCwMBAQEBBAoWCGZpb3JhbWUxMBsGDSsGAQQBsyUL
AwEBAQIEChIIMDAxMDQyNjEwWAYJYIZIAYb6ax4BBEsMSVRoZSBwcml2YXRlIGtleSBjb3Jy
ZXNwb25kaW5nIHRvIHRoaXMgY2VydGlmaWNhdGUgbWF5IGhhdmUgYmVlbiBleHBvcnRlZC4w
KAYDVR0RBCEwH4EdTWF0dGhldy5GaW9yYXZhbnRlQGpodWFwbC5lZHUwUgYDVR0fBEswSTBH
oEWgQ6RBMD8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJU0RD
QTEOMAwGA1UEAxMFQ1JMNTYwHwYDVR0jBBgwFoAUCDUpmxH52EU2CyWmF2EJMB1yqeswHQYD
VR0OBBYEFO6LYxg6r9wHZ+zdQtBHn1dZ/YTNMAkGA1UdEwQCMAAwGQYJKoZIhvZ9B0EABAww
ChsEVjcuMQMCBLAwDQYJKoZIhvcNAQEFBQADgYEAJO9HQh4YNChVLzuZqK5ARJARD8JoujGZ
fdo75quvg2jXFQe2sEjvLnxJZgm/pv8fdZakq48CWwjYHKuvIp7sDjTEsQfo+y7SpN/N2NvJ
WU5SqfK1VgYtNLRRoGJUB5Q1aZ+Dg95g3kqpyfpUMISJL8IKVLtJVfN4fggFVUYZ9wwxggGr
MIIBpwIBATA3MC8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJ
U0RDQQIEP/HJ/TAJBgUrDgMCGgUAoIHLMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ
KoZIhvcNAQkFMQ8XDTEyMDkxODE3NDAxNVowIwYJKoZIhvcNAQkEMRYEFOfnE4J6b1tJPTzt
FgC7xwfj+IiFMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAK
BggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI
KoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEgYB+ap3fsmsjmb8wk5cMWWJxLGPeN39uxDF/
aZIKy6X3ocl8IvdDHRMUDbyvyXLnptlZReU3Eq4//6ZaSHZRQC6IHZj1gb7BeGmVS8Y++V/W
eX7MhtkGESvi1eZwkp2EfFzi5hCajKcMRJsYBm6dctGmWHe7MxUwZz71+j+7otK5BwAAAAAA
AA==
--------------ms020504020002000103070808--


--===============8555135743231083351==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============8555135743231083351==--


From xen-devel-bounces@lists.xen.org Tue Sep 18 17:47:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Sep 2012 17:47:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TE1sh-00073o-9W; Tue, 18 Sep 2012 17:46:43 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <matthew.fioravante@jhuapl.edu>) id 1TE1sg-00073i-6m
	for xen-devel@lists.xensource.com; Tue, 18 Sep 2012 17:46:42 +0000
Received: from [85.158.143.99:24269] by server-3.bemta-4.messagelabs.com id
	62/EA-08232-183B8505; Tue, 18 Sep 2012 17:46:41 +0000
X-Env-Sender: matthew.fioravante@jhuapl.edu
X-Msg-Ref: server-15.tower-216.messagelabs.com!1347990399!30855104!1
X-Originating-IP: [128.244.251.36]
X-SpamReason: No, hits=0.0 required=7.0 tests=UNPARSEABLE_RELAY
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3347 invoked from network); 18 Sep 2012 17:46:40 -0000
Received: from pilot.jhuapl.edu (HELO jhuapl.edu) (128.244.251.36)
	by server-15.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 18 Sep 2012 17:46:40 -0000
Received: from ([128.244.207.89])
	by pilot.jhuapl.edu with ESMTP with TLS id 63GHCH1.153147353;
	Tue, 18 Sep 2012 13:46:23 -0400
Message-ID: <5058B324.9090802@jhuapl.edu>
Date: Tue, 18 Sep 2012 13:45:08 -0400
From: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120827 Thunderbird/15.0
MIME-Version: 1.0
To: Samuel Thibault <samuel.thibault@ens-lyon.org>, 
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
References: <50579CB7.1010707@jhuapl.edu>
	<20120917221209.GH5110@type.youpi.perso.aquilenet.fr>
In-Reply-To: <20120917221209.GH5110@type.youpi.perso.aquilenet.fr>
X-Enigmail-Version: 1.4.4
Subject: Re: [Xen-devel] [PATCH mini-os enhancements for vtpm 3/8] add
 endian support to mini-os
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============5376601629790655582=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a cryptographically signed message in MIME format.

--===============5376601629790655582==
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms070300000300040804080906"

This is a cryptographically signed message in MIME format.

--------------ms070300000300040804080906
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable



On 09/17/2012 06:12 PM, Samuel Thibault wrote:
> Matthew Fioravante, le Mon 17 Sep 2012 17:57:11 -0400, a =E9crit :
>> diff --git a/extras/mini-os/include/byteorder.h
>> b/extras/mini-os/include/byteorder.h
>> --- /dev/null
>> +++ b/extras/mini-os/include/byteorder.h
> Ok.
>
>> -static inline uint16_t bswap_16(uint16_t x)
>> -{
>> -    return
>> -    ((((x) & 0xff00) >> 8) | (((x) & 0xff) << 8));
>> -}
>> -
>> +#define bswap_16(x) ((uint16_t)(                         \
>> +             (((uint16_t)(x) & (uint16_t)0x00ffU) << 8)
>> |                  \
>> +             (((uint16_t)(x) & (uint16_t)0xff00U) >> 8)))
> Why replacing the inline with a macro?  AIUI, inlines provide the same
> efficiency while providing some minimal type checking (and safety
> against things like bswap_16(x++).
With a macro you can do this:

const uint16_t foo =3D bswap_16(4000);

Not possible with inline. From what I've seen in other system heads
(linux in particular), they tend to be implemented as macros or compiler
builtins.
>
>> diff --git a/extras/mini-os/include/endian.h
>> diff --git a/extras/mini-os/include/ia64/arch_endian.h
>> diff --git a/extras/mini-os/include/ia64/arch_wordsize.h
>> diff --git a/extras/mini-os/include/x86/arch_endian.h
>> diff --git a/extras/mini-os/include/x86/x86_32/arch_wordsize.h
>> diff --git a/extras/mini-os/include/x86/x86_64/arch_wordsize.h
> Ok.
>
> Samuel



--------------ms070300000300040804080906
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIDyjCC
A8YwggMvoAMCAQICBD/xyf0wDQYJKoZIhvcNAQEFBQAwLzELMAkGA1UEBhMCVVMxDzANBgNV
BAoTBkpIVUFQTDEPMA0GA1UECxMGQklTRENBMB4XDTEwMDYxMTE4MjIwNloXDTEzMDYxMTE4
NTIwNlowZjELMAkGA1UEBhMCVVMxDzANBgNVBAoTBkpIVUFQTDEPMA0GA1UECxMGUGVvcGxl
MTUwFgYDVQQLEw9WUE5Hcm91cC1CSVNEQ0EwGwYDVQQDExRNYXR0aGV3IEUgRmlvcmF2YW50
ZTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAnpbwVSP6o1Nb5lcW7dd3yTo9iBJdi7qz
4nANOMFPK7JOy5npKN1iiousl28U/scUJES55gPwAWYJK3uVyQAsA4adgDKi5DoD1UHDQEwp
bY7iHLJeq0NPr4BqYNqnCFPbE6HC8zSJrr4qKn+gVUQT39SIFqdiIPJwZL8FYTRQ/zsCAwEA
AaOCAbYwggGyMAsGA1UdDwQEAwIHgDArBgNVHRAEJDAigA8yMDEwMDYxMTE4MjIwNlqBDzIw
MTIwNzE3MjI1MjA2WjAbBg0rBgEEAbMlCwMBAQEBBAoWCGZpb3JhbWUxMBsGDSsGAQQBsyUL
AwEBAQIEChIIMDAxMDQyNjEwWAYJYIZIAYb6ax4BBEsMSVRoZSBwcml2YXRlIGtleSBjb3Jy
ZXNwb25kaW5nIHRvIHRoaXMgY2VydGlmaWNhdGUgbWF5IGhhdmUgYmVlbiBleHBvcnRlZC4w
KAYDVR0RBCEwH4EdTWF0dGhldy5GaW9yYXZhbnRlQGpodWFwbC5lZHUwUgYDVR0fBEswSTBH
oEWgQ6RBMD8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJU0RD
QTEOMAwGA1UEAxMFQ1JMNTYwHwYDVR0jBBgwFoAUCDUpmxH52EU2CyWmF2EJMB1yqeswHQYD
VR0OBBYEFO6LYxg6r9wHZ+zdQtBHn1dZ/YTNMAkGA1UdEwQCMAAwGQYJKoZIhvZ9B0EABAww
ChsEVjcuMQMCBLAwDQYJKoZIhvcNAQEFBQADgYEAJO9HQh4YNChVLzuZqK5ARJARD8JoujGZ
fdo75quvg2jXFQe2sEjvLnxJZgm/pv8fdZakq48CWwjYHKuvIp7sDjTEsQfo+y7SpN/N2NvJ
WU5SqfK1VgYtNLRRoGJUB5Q1aZ+Dg95g3kqpyfpUMISJL8IKVLtJVfN4fggFVUYZ9wwxggGr
MIIBpwIBATA3MC8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJ
U0RDQQIEP/HJ/TAJBgUrDgMCGgUAoIHLMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ
KoZIhvcNAQkFMQ8XDTEyMDkxODE3NDUwOFowIwYJKoZIhvcNAQkEMRYEFEQaZfRLm+yVGL7b
Mz0XQ1ywMu0KMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAK
BggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI
KoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEgYA+sCytbccxcA3lDUmaey8scPDqrGeaX9vO
aQMCLfNSFb9srweKFzM5eFNs2R9iI2rYfzagdC8PuvvqxXqbFP2dkP+JkCbObHrG/Eq5RGWQ
SWyNldVVc5rlwZPlEGQzoEnoYgCnfbD79WgwO6UwlopTJwz1Icr+2yRGbrShvdDY0gAAAAAA
AA==
--------------ms070300000300040804080906--


--===============5376601629790655582==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============5376601629790655582==--


From xen-devel-bounces@lists.xen.org Tue Sep 18 17:47:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Sep 2012 17:47:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TE1sh-00073o-9W; Tue, 18 Sep 2012 17:46:43 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <matthew.fioravante@jhuapl.edu>) id 1TE1sg-00073i-6m
	for xen-devel@lists.xensource.com; Tue, 18 Sep 2012 17:46:42 +0000
Received: from [85.158.143.99:24269] by server-3.bemta-4.messagelabs.com id
	62/EA-08232-183B8505; Tue, 18 Sep 2012 17:46:41 +0000
X-Env-Sender: matthew.fioravante@jhuapl.edu
X-Msg-Ref: server-15.tower-216.messagelabs.com!1347990399!30855104!1
X-Originating-IP: [128.244.251.36]
X-SpamReason: No, hits=0.0 required=7.0 tests=UNPARSEABLE_RELAY
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3347 invoked from network); 18 Sep 2012 17:46:40 -0000
Received: from pilot.jhuapl.edu (HELO jhuapl.edu) (128.244.251.36)
	by server-15.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 18 Sep 2012 17:46:40 -0000
Received: from ([128.244.207.89])
	by pilot.jhuapl.edu with ESMTP with TLS id 63GHCH1.153147353;
	Tue, 18 Sep 2012 13:46:23 -0400
Message-ID: <5058B324.9090802@jhuapl.edu>
Date: Tue, 18 Sep 2012 13:45:08 -0400
From: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120827 Thunderbird/15.0
MIME-Version: 1.0
To: Samuel Thibault <samuel.thibault@ens-lyon.org>, 
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
References: <50579CB7.1010707@jhuapl.edu>
	<20120917221209.GH5110@type.youpi.perso.aquilenet.fr>
In-Reply-To: <20120917221209.GH5110@type.youpi.perso.aquilenet.fr>
X-Enigmail-Version: 1.4.4
Subject: Re: [Xen-devel] [PATCH mini-os enhancements for vtpm 3/8] add
 endian support to mini-os
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============5376601629790655582=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a cryptographically signed message in MIME format.

--===============5376601629790655582==
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms070300000300040804080906"

This is a cryptographically signed message in MIME format.

--------------ms070300000300040804080906
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable



On 09/17/2012 06:12 PM, Samuel Thibault wrote:
> Matthew Fioravante, le Mon 17 Sep 2012 17:57:11 -0400, a =E9crit :
>> diff --git a/extras/mini-os/include/byteorder.h
>> b/extras/mini-os/include/byteorder.h
>> --- /dev/null
>> +++ b/extras/mini-os/include/byteorder.h
> Ok.
>
>> -static inline uint16_t bswap_16(uint16_t x)
>> -{
>> -    return
>> -    ((((x) & 0xff00) >> 8) | (((x) & 0xff) << 8));
>> -}
>> -
>> +#define bswap_16(x) ((uint16_t)(                         \
>> +             (((uint16_t)(x) & (uint16_t)0x00ffU) << 8)
>> |                  \
>> +             (((uint16_t)(x) & (uint16_t)0xff00U) >> 8)))
> Why replacing the inline with a macro?  AIUI, inlines provide the same
> efficiency while providing some minimal type checking (and safety
> against things like bswap_16(x++).
With a macro you can do this:

const uint16_t foo =3D bswap_16(4000);

Not possible with inline. From what I've seen in other system heads
(linux in particular), they tend to be implemented as macros or compiler
builtins.
>
>> diff --git a/extras/mini-os/include/endian.h
>> diff --git a/extras/mini-os/include/ia64/arch_endian.h
>> diff --git a/extras/mini-os/include/ia64/arch_wordsize.h
>> diff --git a/extras/mini-os/include/x86/arch_endian.h
>> diff --git a/extras/mini-os/include/x86/x86_32/arch_wordsize.h
>> diff --git a/extras/mini-os/include/x86/x86_64/arch_wordsize.h
> Ok.
>
> Samuel



--------------ms070300000300040804080906
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIDyjCC
A8YwggMvoAMCAQICBD/xyf0wDQYJKoZIhvcNAQEFBQAwLzELMAkGA1UEBhMCVVMxDzANBgNV
BAoTBkpIVUFQTDEPMA0GA1UECxMGQklTRENBMB4XDTEwMDYxMTE4MjIwNloXDTEzMDYxMTE4
NTIwNlowZjELMAkGA1UEBhMCVVMxDzANBgNVBAoTBkpIVUFQTDEPMA0GA1UECxMGUGVvcGxl
MTUwFgYDVQQLEw9WUE5Hcm91cC1CSVNEQ0EwGwYDVQQDExRNYXR0aGV3IEUgRmlvcmF2YW50
ZTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAnpbwVSP6o1Nb5lcW7dd3yTo9iBJdi7qz
4nANOMFPK7JOy5npKN1iiousl28U/scUJES55gPwAWYJK3uVyQAsA4adgDKi5DoD1UHDQEwp
bY7iHLJeq0NPr4BqYNqnCFPbE6HC8zSJrr4qKn+gVUQT39SIFqdiIPJwZL8FYTRQ/zsCAwEA
AaOCAbYwggGyMAsGA1UdDwQEAwIHgDArBgNVHRAEJDAigA8yMDEwMDYxMTE4MjIwNlqBDzIw
MTIwNzE3MjI1MjA2WjAbBg0rBgEEAbMlCwMBAQEBBAoWCGZpb3JhbWUxMBsGDSsGAQQBsyUL
AwEBAQIEChIIMDAxMDQyNjEwWAYJYIZIAYb6ax4BBEsMSVRoZSBwcml2YXRlIGtleSBjb3Jy
ZXNwb25kaW5nIHRvIHRoaXMgY2VydGlmaWNhdGUgbWF5IGhhdmUgYmVlbiBleHBvcnRlZC4w
KAYDVR0RBCEwH4EdTWF0dGhldy5GaW9yYXZhbnRlQGpodWFwbC5lZHUwUgYDVR0fBEswSTBH
oEWgQ6RBMD8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJU0RD
QTEOMAwGA1UEAxMFQ1JMNTYwHwYDVR0jBBgwFoAUCDUpmxH52EU2CyWmF2EJMB1yqeswHQYD
VR0OBBYEFO6LYxg6r9wHZ+zdQtBHn1dZ/YTNMAkGA1UdEwQCMAAwGQYJKoZIhvZ9B0EABAww
ChsEVjcuMQMCBLAwDQYJKoZIhvcNAQEFBQADgYEAJO9HQh4YNChVLzuZqK5ARJARD8JoujGZ
fdo75quvg2jXFQe2sEjvLnxJZgm/pv8fdZakq48CWwjYHKuvIp7sDjTEsQfo+y7SpN/N2NvJ
WU5SqfK1VgYtNLRRoGJUB5Q1aZ+Dg95g3kqpyfpUMISJL8IKVLtJVfN4fggFVUYZ9wwxggGr
MIIBpwIBATA3MC8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJ
U0RDQQIEP/HJ/TAJBgUrDgMCGgUAoIHLMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ
KoZIhvcNAQkFMQ8XDTEyMDkxODE3NDUwOFowIwYJKoZIhvcNAQkEMRYEFEQaZfRLm+yVGL7b
Mz0XQ1ywMu0KMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAK
BggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI
KoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEgYA+sCytbccxcA3lDUmaey8scPDqrGeaX9vO
aQMCLfNSFb9srweKFzM5eFNs2R9iI2rYfzagdC8PuvvqxXqbFP2dkP+JkCbObHrG/Eq5RGWQ
SWyNldVVc5rlwZPlEGQzoEnoYgCnfbD79WgwO6UwlopTJwz1Icr+2yRGbrShvdDY0gAAAAAA
AA==
--------------ms070300000300040804080906--


--===============5376601629790655582==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============5376601629790655582==--


From xen-devel-bounces@lists.xen.org Tue Sep 18 17:49:18 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Sep 2012 17: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 1TE1uv-0007Ai-RH; Tue, 18 Sep 2012 17:49:01 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <gu99roax@student.chalmers.se>) id 1TDzK2-00023q-Dv
	for xen-devel@lists.xen.org; Tue, 18 Sep 2012 15:02:46 +0000
Received: from [85.158.139.211:11129] by server-4.bemta-5.messagelabs.com id
	A7/A8-23042-51D88505; Tue, 18 Sep 2012 15:02:45 +0000
X-Env-Sender: gu99roax@student.chalmers.se
X-Msg-Ref: server-12.tower-206.messagelabs.com!1347980563!18041059!1
X-Originating-IP: [216.32.181.185]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19308 invoked from network); 18 Sep 2012 15:02:44 -0000
Received: from ch1ehsobe005.messaging.microsoft.com (HELO
	ch1outboundpool.messaging.microsoft.com) (216.32.181.185)
	by server-12.tower-206.messagelabs.com with AES128-SHA encrypted SMTP;
	18 Sep 2012 15:02:44 -0000
Received: from mail58-ch1-R.bigfish.com (10.43.68.245) by
	CH1EHSOBE013.bigfish.com (10.43.70.63) with Microsoft SMTP Server id
	14.1.225.23; Tue, 18 Sep 2012 15:02:43 +0000
Received: from mail58-ch1 (localhost [127.0.0.1])	by mail58-ch1-R.bigfish.com
	(Postfix) with ESMTP id F3C5C3E010B;
	Tue, 18 Sep 2012 15:02:42 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:207.46.4.203; KIP:(null); UIP:(null); IPV:NLI;
	H:SN2PRD0102HT010.prod.exchangelabs.com; RD:none; EFVD:NLI
X-SpamScore: 2
X-BigFish: PS2(zz98dIc89bh936eI1432Id6f1izz1d18h1202h1d1ah1d2ah1082kzzz2dh2a8h668h839h8e2h8e3hd25hf0ah107ah10d2h1288h12a5h12a9h12bdhbe9i1155h)
Received: from mail58-ch1 (localhost.localdomain [127.0.0.1]) by mail58-ch1
	(MessageSwitch) id 1347980560996771_5126;
	Tue, 18 Sep 2012 15:02:40 +0000 (UTC)
Received: from CH1EHSMHS041.bigfish.com (snatpool2.int.messaging.microsoft.com
	[10.43.68.236])	by mail58-ch1.bigfish.com (Postfix) with ESMTP id
	EFD821E017D;	Tue, 18 Sep 2012 15:02:40 +0000 (UTC)
Received: from SN2PRD0102HT010.prod.exchangelabs.com (207.46.4.203) by
	CH1EHSMHS041.bigfish.com (10.43.69.250) with Microsoft SMTP Server
	(TLS) id 14.1.225.23; Tue, 18 Sep 2012 15:02:39 +0000
Received: from [10.40.137.93] (217.208.204.161) by pod51000.outlook.com
	(10.27.51.88) with Microsoft SMTP Server (TLS) id 14.15.108.4;
	Tue, 18 Sep 2012 15:02:38 +0000
Message-ID: <50588D0A.1020802@student.chalmers.se>
Date: Tue, 18 Sep 2012 17:02:34 +0200
From: Robin Axelsson <gu99roax@student.chalmers.se>
User-Agent: Mozilla/5.0 (Windows NT 5.2; WOW64;
	rv:9.0) Gecko/20111222 Thunderbird/9.0.1
MIME-Version: 1.0
To: =?ISO-8859-1?Q?Pasi_K=E4rkk=E4inen?= <pasik@iki.fi>
References: <20120917113833.GH8912@reaktio.net>
	<50570EA7.8060509@student.chalmers.se>
	<20120917123205.GJ8912@reaktio.net>
	<1347885774.14977.64.camel@zakaz.uk.xensource.com>
	<20120917191556.GB18552@phenom.dumpdata.com>
	<505858C3.9080303@student.chalmers.se>
	<20120918113911.GM8912@reaktio.net>
In-Reply-To: <20120918113911.GM8912@reaktio.net>
X-Originating-IP: [217.208.204.161]
X-OriginatorOrg: student.chalmers.se
X-Mailman-Approved-At: Tue, 18 Sep 2012 17:49:00 +0000
Cc: Konrad Rzeszutek Wilk <konrad@kernel.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"xen@lists.fedoraproject.org" <xen@lists.fedoraproject.org>
Subject: Re: [Xen-devel] Xen PCI passthru supported reset methods (d3d0, FLR,
 bus reset, link reset)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: gu99roax@student.chalmers.se
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
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 2012-09-18 13:39, Pasi K=E4rkk=E4inen wrote:
> On Tue, Sep 18, 2012 at 01:19:31PM +0200, Robin Axelsson wrote:
>>>> With a pvops dom0 Xen resets devices by writing to its "reset" node in
>>>> sysfs so it will reset the device using whatever method the dom0 kernel
>>>> supports for that device.
>>> And if you use Xen PCI-back it has this enabled so you don't even
>>> need the 'reset' functionality.
>>>> The version of Linux I have to hand has, in __pci_dev_reset, calls to
>>>> the following in this order and stops after the first one which
>>>> succeeds:
>>>>        * pci_dev_specific_reset (AKA per device quirks)
>>>>        * pcie_flr
>>>>        * pci_af_flr
>>>>        * pci_pm_reset
>>>>        * pci_parent_bus_reset
>>>>
>>>> See drivers/pci/pci.c in the kernel for more info.
>>>>
>>>> IIRC classic Xen kernels had similar code in pciback, although I don't
>>>> know which specific sets of actions or in which order they were tried.
>>>>
>>>> Ian.
>>>>
>> That sounds like great news, that means that FLR is not a
>> requirement to successfully pass through hardware without errors, as
>> is stated in the VTdHowTo page. So it seems that the VTdHowTo page
>> needs to be updated with this information.
>>
> Do you want to update the wiki page? :)
>
> -- Pasi
>
>
>
> .
>

I wouldn't mind updating the Wiki but I don't have the authority and =

perhaps not the knowledge.

Before announcing "official" support for non-FLR hardware I think some =

testing or testimonials would be in place. When I was experimenting with =

IOMMU on a server a little over half a year ago right before sending it =

out for regular use, the xen pciback drivers were not properly rolled =

out on the paravirt ops kernel. But this probably has improved by then =

and I do happen to have IOMMU capable hardware available for testing =

once again.

* When reading into the pci.c code I think I understand the  "pcie_flr" =

and  "pci_pm_reset" methods/functions but I don't 100% understand the =

other functions used above to reset hardware. I guess I could figure =

that "pci_parent_bus_reset" trigs a bus reset, but I can't tell the =

difference between "pci_dev_specific_reset" and "pcie_flr" or what 'af' =

means in "pci_af_flr".

* Another thing that I've always been wondering is whether d3d0 trigs a =

reset in hardware that takes power from an auxiliary input and don't =

rely on the power provided by the PCI bus (such as GPUs and some =

soundcards such as the Asus Xonar Essence STX). I read about a guy who =

managed to pass through a non-FLR radeon card to a windows guest by =

using the "Safe remove" feature in the Windows domU which perhaps =

trigged a d3d0 reset through the ACPI framework somehow. Here's what he =

wrote:

"I've never had Xen throw errors at me regarding FLR for the 5850, but =

some recent experience suggests that FLR doesn't quite behave correctly =

when it's initiated by pciback... really screwy stuff. There have been a =

lot of threads between me and a few other people on the Xen-Users =

mailing list regarding the issue of PCI passthrough for Radeon 5XXX and =

6XXX series cards to Windows HVM guests.

Radeon cards seem to work properly when they're being used after they're =

first used by a DomU following a restart of Dom0, then suffer =

performance problems if DomU is rebooted and Dom0 is not. The solution =

is to use the Windows "Safe Remove" feature on the video card. That =

forces a proper FLR (for some reason) and makes it work right.

Aside from that, I can't get the 5850 to coexist with the GPLPV =

package.... and I wish I knew why. It just BSODs every time. :("

He wrote this about 4 months ago so some things may have changed since then.

So unless more information is divulged in this matter, at least the Wiki =

could be updated with an honorable mention of these other reset methods =

instead of just saying that non-FLR hardware is a no-go for PCI passthrough.

Robin.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 18 17:49:18 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Sep 2012 17: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 1TE1uv-0007Ai-RH; Tue, 18 Sep 2012 17:49:01 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <gu99roax@student.chalmers.se>) id 1TDzK2-00023q-Dv
	for xen-devel@lists.xen.org; Tue, 18 Sep 2012 15:02:46 +0000
Received: from [85.158.139.211:11129] by server-4.bemta-5.messagelabs.com id
	A7/A8-23042-51D88505; Tue, 18 Sep 2012 15:02:45 +0000
X-Env-Sender: gu99roax@student.chalmers.se
X-Msg-Ref: server-12.tower-206.messagelabs.com!1347980563!18041059!1
X-Originating-IP: [216.32.181.185]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19308 invoked from network); 18 Sep 2012 15:02:44 -0000
Received: from ch1ehsobe005.messaging.microsoft.com (HELO
	ch1outboundpool.messaging.microsoft.com) (216.32.181.185)
	by server-12.tower-206.messagelabs.com with AES128-SHA encrypted SMTP;
	18 Sep 2012 15:02:44 -0000
Received: from mail58-ch1-R.bigfish.com (10.43.68.245) by
	CH1EHSOBE013.bigfish.com (10.43.70.63) with Microsoft SMTP Server id
	14.1.225.23; Tue, 18 Sep 2012 15:02:43 +0000
Received: from mail58-ch1 (localhost [127.0.0.1])	by mail58-ch1-R.bigfish.com
	(Postfix) with ESMTP id F3C5C3E010B;
	Tue, 18 Sep 2012 15:02:42 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:207.46.4.203; KIP:(null); UIP:(null); IPV:NLI;
	H:SN2PRD0102HT010.prod.exchangelabs.com; RD:none; EFVD:NLI
X-SpamScore: 2
X-BigFish: PS2(zz98dIc89bh936eI1432Id6f1izz1d18h1202h1d1ah1d2ah1082kzzz2dh2a8h668h839h8e2h8e3hd25hf0ah107ah10d2h1288h12a5h12a9h12bdhbe9i1155h)
Received: from mail58-ch1 (localhost.localdomain [127.0.0.1]) by mail58-ch1
	(MessageSwitch) id 1347980560996771_5126;
	Tue, 18 Sep 2012 15:02:40 +0000 (UTC)
Received: from CH1EHSMHS041.bigfish.com (snatpool2.int.messaging.microsoft.com
	[10.43.68.236])	by mail58-ch1.bigfish.com (Postfix) with ESMTP id
	EFD821E017D;	Tue, 18 Sep 2012 15:02:40 +0000 (UTC)
Received: from SN2PRD0102HT010.prod.exchangelabs.com (207.46.4.203) by
	CH1EHSMHS041.bigfish.com (10.43.69.250) with Microsoft SMTP Server
	(TLS) id 14.1.225.23; Tue, 18 Sep 2012 15:02:39 +0000
Received: from [10.40.137.93] (217.208.204.161) by pod51000.outlook.com
	(10.27.51.88) with Microsoft SMTP Server (TLS) id 14.15.108.4;
	Tue, 18 Sep 2012 15:02:38 +0000
Message-ID: <50588D0A.1020802@student.chalmers.se>
Date: Tue, 18 Sep 2012 17:02:34 +0200
From: Robin Axelsson <gu99roax@student.chalmers.se>
User-Agent: Mozilla/5.0 (Windows NT 5.2; WOW64;
	rv:9.0) Gecko/20111222 Thunderbird/9.0.1
MIME-Version: 1.0
To: =?ISO-8859-1?Q?Pasi_K=E4rkk=E4inen?= <pasik@iki.fi>
References: <20120917113833.GH8912@reaktio.net>
	<50570EA7.8060509@student.chalmers.se>
	<20120917123205.GJ8912@reaktio.net>
	<1347885774.14977.64.camel@zakaz.uk.xensource.com>
	<20120917191556.GB18552@phenom.dumpdata.com>
	<505858C3.9080303@student.chalmers.se>
	<20120918113911.GM8912@reaktio.net>
In-Reply-To: <20120918113911.GM8912@reaktio.net>
X-Originating-IP: [217.208.204.161]
X-OriginatorOrg: student.chalmers.se
X-Mailman-Approved-At: Tue, 18 Sep 2012 17:49:00 +0000
Cc: Konrad Rzeszutek Wilk <konrad@kernel.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"xen@lists.fedoraproject.org" <xen@lists.fedoraproject.org>
Subject: Re: [Xen-devel] Xen PCI passthru supported reset methods (d3d0, FLR,
 bus reset, link reset)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: gu99roax@student.chalmers.se
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
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 2012-09-18 13:39, Pasi K=E4rkk=E4inen wrote:
> On Tue, Sep 18, 2012 at 01:19:31PM +0200, Robin Axelsson wrote:
>>>> With a pvops dom0 Xen resets devices by writing to its "reset" node in
>>>> sysfs so it will reset the device using whatever method the dom0 kernel
>>>> supports for that device.
>>> And if you use Xen PCI-back it has this enabled so you don't even
>>> need the 'reset' functionality.
>>>> The version of Linux I have to hand has, in __pci_dev_reset, calls to
>>>> the following in this order and stops after the first one which
>>>> succeeds:
>>>>        * pci_dev_specific_reset (AKA per device quirks)
>>>>        * pcie_flr
>>>>        * pci_af_flr
>>>>        * pci_pm_reset
>>>>        * pci_parent_bus_reset
>>>>
>>>> See drivers/pci/pci.c in the kernel for more info.
>>>>
>>>> IIRC classic Xen kernels had similar code in pciback, although I don't
>>>> know which specific sets of actions or in which order they were tried.
>>>>
>>>> Ian.
>>>>
>> That sounds like great news, that means that FLR is not a
>> requirement to successfully pass through hardware without errors, as
>> is stated in the VTdHowTo page. So it seems that the VTdHowTo page
>> needs to be updated with this information.
>>
> Do you want to update the wiki page? :)
>
> -- Pasi
>
>
>
> .
>

I wouldn't mind updating the Wiki but I don't have the authority and =

perhaps not the knowledge.

Before announcing "official" support for non-FLR hardware I think some =

testing or testimonials would be in place. When I was experimenting with =

IOMMU on a server a little over half a year ago right before sending it =

out for regular use, the xen pciback drivers were not properly rolled =

out on the paravirt ops kernel. But this probably has improved by then =

and I do happen to have IOMMU capable hardware available for testing =

once again.

* When reading into the pci.c code I think I understand the  "pcie_flr" =

and  "pci_pm_reset" methods/functions but I don't 100% understand the =

other functions used above to reset hardware. I guess I could figure =

that "pci_parent_bus_reset" trigs a bus reset, but I can't tell the =

difference between "pci_dev_specific_reset" and "pcie_flr" or what 'af' =

means in "pci_af_flr".

* Another thing that I've always been wondering is whether d3d0 trigs a =

reset in hardware that takes power from an auxiliary input and don't =

rely on the power provided by the PCI bus (such as GPUs and some =

soundcards such as the Asus Xonar Essence STX). I read about a guy who =

managed to pass through a non-FLR radeon card to a windows guest by =

using the "Safe remove" feature in the Windows domU which perhaps =

trigged a d3d0 reset through the ACPI framework somehow. Here's what he =

wrote:

"I've never had Xen throw errors at me regarding FLR for the 5850, but =

some recent experience suggests that FLR doesn't quite behave correctly =

when it's initiated by pciback... really screwy stuff. There have been a =

lot of threads between me and a few other people on the Xen-Users =

mailing list regarding the issue of PCI passthrough for Radeon 5XXX and =

6XXX series cards to Windows HVM guests.

Radeon cards seem to work properly when they're being used after they're =

first used by a DomU following a restart of Dom0, then suffer =

performance problems if DomU is rebooted and Dom0 is not. The solution =

is to use the Windows "Safe Remove" feature on the video card. That =

forces a proper FLR (for some reason) and makes it work right.

Aside from that, I can't get the 5850 to coexist with the GPLPV =

package.... and I wish I knew why. It just BSODs every time. :("

He wrote this about 4 months ago so some things may have changed since then.

So unless more information is divulged in this matter, at least the Wiki =

could be updated with an honorable mention of these other reset methods =

instead of just saying that non-FLR hardware is a no-go for PCI passthrough.

Robin.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 18 17:53:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Sep 2012 17:53:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TE1ya-0007Lj-Q3; Tue, 18 Sep 2012 17:52:48 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <samuel.thibault@ens-lyon.org>) id 1TE1yZ-0007Le-BG
	for xen-devel@lists.xensource.com; Tue, 18 Sep 2012 17:52:47 +0000
Received: from [85.158.139.211:41690] by server-10.bemta-5.messagelabs.com id
	AE/AD-10969-EE4B8505; Tue, 18 Sep 2012 17:52:46 +0000
X-Env-Sender: samuel.thibault@ens-lyon.org
X-Msg-Ref: server-10.tower-206.messagelabs.com!1347990765!19033830!1
X-Originating-IP: [140.77.166.68]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16878 invoked from network); 18 Sep 2012 17:52:46 -0000
Received: from toccata.ens-lyon.org (HELO toccata.ens-lyon.org) (140.77.166.68)
	by server-10.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 18 Sep 2012 17:52:46 -0000
Received: from localhost (localhost [127.0.0.1])
	by toccata.ens-lyon.org (Postfix) with ESMTP id 2EEFF8409A;
	Tue, 18 Sep 2012 19:52:44 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at toccata.ens-lyon.org
Received: from toccata.ens-lyon.org ([127.0.0.1])
	by localhost (toccata.ens-lyon.org [127.0.0.1]) (amavisd-new,
	port 10024)
	with ESMTP id u7HLfJBgKQ56; Tue, 18 Sep 2012 19:52:44 +0200 (CEST)
Received: from type.ipv6 (youpi.is-a-geek.org [80.67.176.89])
	(using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits))
	(No client certificate requested)
	by toccata.ens-lyon.org (Postfix) with ESMTPSA id C690C84099;
	Tue, 18 Sep 2012 19:52:42 +0200 (CEST)
Received: from samy by type.ipv6 with local (Exim 4.80)
	(envelope-from <samuel.thibault@ens-lyon.org>)
	id 1TE1yP-0001xF-Si; Tue, 18 Sep 2012 19:52:37 +0200
Date: Tue, 18 Sep 2012 19:52:37 +0200
From: Samuel Thibault <samuel.thibault@ens-lyon.org>
To: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
Message-ID: <20120918175237.GC5021@type.youpi.perso.aquilenet.fr>
Mail-Followup-To: Samuel Thibault <samuel.thibault@ens-lyon.org>,
	Matthew Fioravante <matthew.fioravante@jhuapl.edu>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
References: <50579CB7.1010707@jhuapl.edu>
	<20120917221209.GH5110@type.youpi.perso.aquilenet.fr>
	<5058B324.9090802@jhuapl.edu>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <5058B324.9090802@jhuapl.edu>
User-Agent: Mutt/1.5.21+34 (58baf7c9f32f) (2010-12-30)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH mini-os enhancements for vtpm 3/8] add
 endian support to mini-os
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Matthew Fioravante, le Tue 18 Sep 2012 13:45:08 -0400, a =E9crit :
> With a macro you can do this:
> =

> const uint16_t foo =3D bswap_16(4000);

Ok, then

Acked-by: Samuel Thibault <samuel.thibault@ens-lyon.org>

Samuel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 18 17:53:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Sep 2012 17:53:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TE1ya-0007Lj-Q3; Tue, 18 Sep 2012 17:52:48 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <samuel.thibault@ens-lyon.org>) id 1TE1yZ-0007Le-BG
	for xen-devel@lists.xensource.com; Tue, 18 Sep 2012 17:52:47 +0000
Received: from [85.158.139.211:41690] by server-10.bemta-5.messagelabs.com id
	AE/AD-10969-EE4B8505; Tue, 18 Sep 2012 17:52:46 +0000
X-Env-Sender: samuel.thibault@ens-lyon.org
X-Msg-Ref: server-10.tower-206.messagelabs.com!1347990765!19033830!1
X-Originating-IP: [140.77.166.68]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16878 invoked from network); 18 Sep 2012 17:52:46 -0000
Received: from toccata.ens-lyon.org (HELO toccata.ens-lyon.org) (140.77.166.68)
	by server-10.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 18 Sep 2012 17:52:46 -0000
Received: from localhost (localhost [127.0.0.1])
	by toccata.ens-lyon.org (Postfix) with ESMTP id 2EEFF8409A;
	Tue, 18 Sep 2012 19:52:44 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at toccata.ens-lyon.org
Received: from toccata.ens-lyon.org ([127.0.0.1])
	by localhost (toccata.ens-lyon.org [127.0.0.1]) (amavisd-new,
	port 10024)
	with ESMTP id u7HLfJBgKQ56; Tue, 18 Sep 2012 19:52:44 +0200 (CEST)
Received: from type.ipv6 (youpi.is-a-geek.org [80.67.176.89])
	(using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits))
	(No client certificate requested)
	by toccata.ens-lyon.org (Postfix) with ESMTPSA id C690C84099;
	Tue, 18 Sep 2012 19:52:42 +0200 (CEST)
Received: from samy by type.ipv6 with local (Exim 4.80)
	(envelope-from <samuel.thibault@ens-lyon.org>)
	id 1TE1yP-0001xF-Si; Tue, 18 Sep 2012 19:52:37 +0200
Date: Tue, 18 Sep 2012 19:52:37 +0200
From: Samuel Thibault <samuel.thibault@ens-lyon.org>
To: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
Message-ID: <20120918175237.GC5021@type.youpi.perso.aquilenet.fr>
Mail-Followup-To: Samuel Thibault <samuel.thibault@ens-lyon.org>,
	Matthew Fioravante <matthew.fioravante@jhuapl.edu>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
References: <50579CB7.1010707@jhuapl.edu>
	<20120917221209.GH5110@type.youpi.perso.aquilenet.fr>
	<5058B324.9090802@jhuapl.edu>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <5058B324.9090802@jhuapl.edu>
User-Agent: Mutt/1.5.21+34 (58baf7c9f32f) (2010-12-30)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH mini-os enhancements for vtpm 3/8] add
 endian support to mini-os
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Matthew Fioravante, le Tue 18 Sep 2012 13:45:08 -0400, a =E9crit :
> With a macro you can do this:
> =

> const uint16_t foo =3D bswap_16(4000);

Ok, then

Acked-by: Samuel Thibault <samuel.thibault@ens-lyon.org>

Samuel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 18 17:58:02 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Sep 2012 17: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 1TE23P-0007Va-I7; Tue, 18 Sep 2012 17:57:47 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <matthew.fioravante@jhuapl.edu>) id 1TE23O-0007VS-0G
	for xen-devel@lists.xensource.com; Tue, 18 Sep 2012 17:57:46 +0000
Received: from [85.158.139.83:29565] by server-12.bemta-5.messagelabs.com id
	91/2E-22167-916B8505; Tue, 18 Sep 2012 17:57:45 +0000
X-Env-Sender: matthew.fioravante@jhuapl.edu
X-Msg-Ref: server-15.tower-182.messagelabs.com!1347991063!28890559!1
X-Originating-IP: [128.244.251.36]
X-SpamReason: No, hits=0.0 required=7.0 tests=UNPARSEABLE_RELAY
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29656 invoked from network); 18 Sep 2012 17:57:44 -0000
Received: from pilot.jhuapl.edu (HELO jhuapl.edu) (128.244.251.36)
	by server-15.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 18 Sep 2012 17:57:44 -0000
Received: from ([128.244.207.89])
	by pilot.jhuapl.edu with ESMTP with TLS id 63GHCH1.153148530;
	Tue, 18 Sep 2012 13:57:25 -0400
Message-ID: <5058B5BA.3000408@jhuapl.edu>
Date: Tue, 18 Sep 2012 13:56:10 -0400
From: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120827 Thunderbird/15.0
MIME-Version: 1.0
To: Samuel Thibault <samuel.thibault@ens-lyon.org>, 
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
References: <50579BA6.1080503@jhuapl.edu>
	<20120917222328.GN5110@type.youpi.perso.aquilenet.fr>
In-Reply-To: <20120917222328.GN5110@type.youpi.perso.aquilenet.fr>
X-Enigmail-Version: 1.4.4
Subject: Re: [Xen-devel] [PATCH mini-os enhancements for vtpm 1/8]
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1824228950091041598=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a cryptographically signed message in MIME format.

--===============1824228950091041598==
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms000202080400020804000201"

This is a cryptographically signed message in MIME format.

--------------ms000202080400020804000201
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On 09/17/2012 06:23 PM, Samuel Thibault wrote:
> Matthew Fioravante, le Mon 17 Sep 2012 17:52:38 -0400, a =E9crit :
>> b/extras/mini-os/arch/ia64/iorw.c
>> +void iowrite8(volatile void* addr, uint8_t val)
>> +{
>> +   printk("iorw not implemented!!\n");
> Maybe even crash?  Such things can be overlooked.
I agree.
>> +#include <mini-os/types.h>
>> +
>> +void iowrite8(volatile void* addr, uint8_t val);
>> +void iowrite32(volatile void* addr, uint32_t val);
>> +
>> +uint8_t ioread8(volatile void* addr);
>> +uint32_t ioread32(volatile void* addr);
> I'd say while you are at it, add 16 and 64 variants.
Included below
>
> Samuel

New patch.

Signed off by: Matthew Fioravante matthew.fioravante@jhuapl.edu

diff --git a/extras/mini-os/arch/ia64/iorw.c
b/extras/mini-os/arch/ia64/iorw.c
--- /dev/null
+++ b/extras/mini-os/arch/ia64/iorw.c
@@ -0,0 +1,48 @@
+#include <mini-os/iorw.h>
+#include <mini-os/console.h>
+
+void iowrite8(volatile void* addr, uint8_t val)
+{
+   printk("iorw not implemented!!\n");
+   BUG();
+}
+void iowrite16(volatile void* addr, uint16_t val)
+{
+   printk("iorw not implemented!!\n");
+   BUG();
+}
+void iowrite32(volatile void* addr, uint32_t val)
+{
+   printk("iorw not implemented!!\n");
+   BUG();
+}
+void iowrite64(volatile void* addr, uint64_t val)
+{
+   printk("iorw not implemented!!\n");
+   BUG();
+}
+
+uint8_t ioread8(volatile void* addr)
+{
+   printk("iorw not implemented!!\n");
+   BUG();
+   return 0;
+}
+uint16_t ioread16(volatile void* addr)
+{
+   printk("iorw not implemented!!\n");
+   BUG();
+   return 0;
+}
+uint32_t ioread32(volatile void* addr)
+{
+   printk("iorw not implemented!!\n");
+   BUG();
+   return 0;
+}
+uint64_t ioread64(volatile void* addr)
+{
+   printk("iorw not implemented!!\n");
+   BUG();
+   return 0;
+}
diff --git a/extras/mini-os/arch/x86/iorw.c b/extras/mini-os/arch/x86/ior=
w.c
--- /dev/null
+++ b/extras/mini-os/arch/x86/iorw.c
@@ -0,0 +1,35 @@
+#include <mini-os/iorw.h>
+
+void iowrite8(volatile void* addr, uint8_t val)
+{
+   *((volatile uint8_t*)addr) =3D val;
+}
+void iowrite16(volatile void* addr, uint16_t val)
+{
+   *((volatile uint16_t*)addr) =3D val;
+}
+void iowrite32(volatile void* addr, uint32_t val)
+{
+   *((volatile uint32_t*)addr) =3D val;
+}
+void iowrite64(volatile void* addr, uint64_t val)
+{
+   *((volatile uint64_t*)addr) =3D val;
+}
+
+uint8_t ioread8(volatile void* addr)
+{
+   return *((volatile uint8_t*) addr);
+}
+uint16_t ioread16(volatile void* addr)
+{
+   return *((volatile uint16_t*) addr);
+}
+uint32_t ioread32(volatile void* addr)
+{
+   return *((volatile uint32_t*) addr);
+}
+uint64_t ioread64(volatile void* addr)
+{
+   return *((volatile uint64_t*) addr);
+}
diff --git a/extras/mini-os/include/iorw.h b/extras/mini-os/include/iorw.=
h
--- /dev/null
+++ b/extras/mini-os/include/iorw.h
@@ -0,0 +1,16 @@
+#ifndef MINIOS_IORW_H
+#define MINIOS_IORW_H
+
+#include <mini-os/types.h>
+
+void iowrite8(volatile void* addr, uint8_t val);
+void iowrite16(volatile void* addr, uint16_t val);
+void iowrite32(volatile void* addr, uint32_t val);
+void iowrite64(volatile void* addr, uint64_t val);
+
+uint8_t ioread8(volatile void* addr);
+uint16_t ioread16(volatile void* addr);
+uint32_t ioread32(volatile void* addr);
+uint64_t ioread64(volatile void* addr);
+
+#endif



--------------ms000202080400020804000201
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIDyjCC
A8YwggMvoAMCAQICBD/xyf0wDQYJKoZIhvcNAQEFBQAwLzELMAkGA1UEBhMCVVMxDzANBgNV
BAoTBkpIVUFQTDEPMA0GA1UECxMGQklTRENBMB4XDTEwMDYxMTE4MjIwNloXDTEzMDYxMTE4
NTIwNlowZjELMAkGA1UEBhMCVVMxDzANBgNVBAoTBkpIVUFQTDEPMA0GA1UECxMGUGVvcGxl
MTUwFgYDVQQLEw9WUE5Hcm91cC1CSVNEQ0EwGwYDVQQDExRNYXR0aGV3IEUgRmlvcmF2YW50
ZTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAnpbwVSP6o1Nb5lcW7dd3yTo9iBJdi7qz
4nANOMFPK7JOy5npKN1iiousl28U/scUJES55gPwAWYJK3uVyQAsA4adgDKi5DoD1UHDQEwp
bY7iHLJeq0NPr4BqYNqnCFPbE6HC8zSJrr4qKn+gVUQT39SIFqdiIPJwZL8FYTRQ/zsCAwEA
AaOCAbYwggGyMAsGA1UdDwQEAwIHgDArBgNVHRAEJDAigA8yMDEwMDYxMTE4MjIwNlqBDzIw
MTIwNzE3MjI1MjA2WjAbBg0rBgEEAbMlCwMBAQEBBAoWCGZpb3JhbWUxMBsGDSsGAQQBsyUL
AwEBAQIEChIIMDAxMDQyNjEwWAYJYIZIAYb6ax4BBEsMSVRoZSBwcml2YXRlIGtleSBjb3Jy
ZXNwb25kaW5nIHRvIHRoaXMgY2VydGlmaWNhdGUgbWF5IGhhdmUgYmVlbiBleHBvcnRlZC4w
KAYDVR0RBCEwH4EdTWF0dGhldy5GaW9yYXZhbnRlQGpodWFwbC5lZHUwUgYDVR0fBEswSTBH
oEWgQ6RBMD8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJU0RD
QTEOMAwGA1UEAxMFQ1JMNTYwHwYDVR0jBBgwFoAUCDUpmxH52EU2CyWmF2EJMB1yqeswHQYD
VR0OBBYEFO6LYxg6r9wHZ+zdQtBHn1dZ/YTNMAkGA1UdEwQCMAAwGQYJKoZIhvZ9B0EABAww
ChsEVjcuMQMCBLAwDQYJKoZIhvcNAQEFBQADgYEAJO9HQh4YNChVLzuZqK5ARJARD8JoujGZ
fdo75quvg2jXFQe2sEjvLnxJZgm/pv8fdZakq48CWwjYHKuvIp7sDjTEsQfo+y7SpN/N2NvJ
WU5SqfK1VgYtNLRRoGJUB5Q1aZ+Dg95g3kqpyfpUMISJL8IKVLtJVfN4fggFVUYZ9wwxggGr
MIIBpwIBATA3MC8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJ
U0RDQQIEP/HJ/TAJBgUrDgMCGgUAoIHLMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ
KoZIhvcNAQkFMQ8XDTEyMDkxODE3NTYxMFowIwYJKoZIhvcNAQkEMRYEFOzMvD7qTGDRXWaB
4sWUijV7gAktMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAK
BggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI
KoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEgYBhz+0iAfccbxMPZLXQbF2iIFZaTDbmUHlS
XIN5IYRE6G6mKQ+z0NBvhQ0nAVF3Fb29FKehKqxhfnvPbISeL1fef2o5973ex5MdVwPjBz3y
W0oqC49irpTAspwXsif2bIosZWhdIbgeoU/xP69rXWDVqciLX8CeKa1EduFtg86D5QAAAAAA
AA==
--------------ms000202080400020804000201--


--===============1824228950091041598==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============1824228950091041598==--


From xen-devel-bounces@lists.xen.org Tue Sep 18 17:58:02 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Sep 2012 17: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 1TE23P-0007Va-I7; Tue, 18 Sep 2012 17:57:47 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <matthew.fioravante@jhuapl.edu>) id 1TE23O-0007VS-0G
	for xen-devel@lists.xensource.com; Tue, 18 Sep 2012 17:57:46 +0000
Received: from [85.158.139.83:29565] by server-12.bemta-5.messagelabs.com id
	91/2E-22167-916B8505; Tue, 18 Sep 2012 17:57:45 +0000
X-Env-Sender: matthew.fioravante@jhuapl.edu
X-Msg-Ref: server-15.tower-182.messagelabs.com!1347991063!28890559!1
X-Originating-IP: [128.244.251.36]
X-SpamReason: No, hits=0.0 required=7.0 tests=UNPARSEABLE_RELAY
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29656 invoked from network); 18 Sep 2012 17:57:44 -0000
Received: from pilot.jhuapl.edu (HELO jhuapl.edu) (128.244.251.36)
	by server-15.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 18 Sep 2012 17:57:44 -0000
Received: from ([128.244.207.89])
	by pilot.jhuapl.edu with ESMTP with TLS id 63GHCH1.153148530;
	Tue, 18 Sep 2012 13:57:25 -0400
Message-ID: <5058B5BA.3000408@jhuapl.edu>
Date: Tue, 18 Sep 2012 13:56:10 -0400
From: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120827 Thunderbird/15.0
MIME-Version: 1.0
To: Samuel Thibault <samuel.thibault@ens-lyon.org>, 
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
References: <50579BA6.1080503@jhuapl.edu>
	<20120917222328.GN5110@type.youpi.perso.aquilenet.fr>
In-Reply-To: <20120917222328.GN5110@type.youpi.perso.aquilenet.fr>
X-Enigmail-Version: 1.4.4
Subject: Re: [Xen-devel] [PATCH mini-os enhancements for vtpm 1/8]
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1824228950091041598=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a cryptographically signed message in MIME format.

--===============1824228950091041598==
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms000202080400020804000201"

This is a cryptographically signed message in MIME format.

--------------ms000202080400020804000201
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On 09/17/2012 06:23 PM, Samuel Thibault wrote:
> Matthew Fioravante, le Mon 17 Sep 2012 17:52:38 -0400, a =E9crit :
>> b/extras/mini-os/arch/ia64/iorw.c
>> +void iowrite8(volatile void* addr, uint8_t val)
>> +{
>> +   printk("iorw not implemented!!\n");
> Maybe even crash?  Such things can be overlooked.
I agree.
>> +#include <mini-os/types.h>
>> +
>> +void iowrite8(volatile void* addr, uint8_t val);
>> +void iowrite32(volatile void* addr, uint32_t val);
>> +
>> +uint8_t ioread8(volatile void* addr);
>> +uint32_t ioread32(volatile void* addr);
> I'd say while you are at it, add 16 and 64 variants.
Included below
>
> Samuel

New patch.

Signed off by: Matthew Fioravante matthew.fioravante@jhuapl.edu

diff --git a/extras/mini-os/arch/ia64/iorw.c
b/extras/mini-os/arch/ia64/iorw.c
--- /dev/null
+++ b/extras/mini-os/arch/ia64/iorw.c
@@ -0,0 +1,48 @@
+#include <mini-os/iorw.h>
+#include <mini-os/console.h>
+
+void iowrite8(volatile void* addr, uint8_t val)
+{
+   printk("iorw not implemented!!\n");
+   BUG();
+}
+void iowrite16(volatile void* addr, uint16_t val)
+{
+   printk("iorw not implemented!!\n");
+   BUG();
+}
+void iowrite32(volatile void* addr, uint32_t val)
+{
+   printk("iorw not implemented!!\n");
+   BUG();
+}
+void iowrite64(volatile void* addr, uint64_t val)
+{
+   printk("iorw not implemented!!\n");
+   BUG();
+}
+
+uint8_t ioread8(volatile void* addr)
+{
+   printk("iorw not implemented!!\n");
+   BUG();
+   return 0;
+}
+uint16_t ioread16(volatile void* addr)
+{
+   printk("iorw not implemented!!\n");
+   BUG();
+   return 0;
+}
+uint32_t ioread32(volatile void* addr)
+{
+   printk("iorw not implemented!!\n");
+   BUG();
+   return 0;
+}
+uint64_t ioread64(volatile void* addr)
+{
+   printk("iorw not implemented!!\n");
+   BUG();
+   return 0;
+}
diff --git a/extras/mini-os/arch/x86/iorw.c b/extras/mini-os/arch/x86/ior=
w.c
--- /dev/null
+++ b/extras/mini-os/arch/x86/iorw.c
@@ -0,0 +1,35 @@
+#include <mini-os/iorw.h>
+
+void iowrite8(volatile void* addr, uint8_t val)
+{
+   *((volatile uint8_t*)addr) =3D val;
+}
+void iowrite16(volatile void* addr, uint16_t val)
+{
+   *((volatile uint16_t*)addr) =3D val;
+}
+void iowrite32(volatile void* addr, uint32_t val)
+{
+   *((volatile uint32_t*)addr) =3D val;
+}
+void iowrite64(volatile void* addr, uint64_t val)
+{
+   *((volatile uint64_t*)addr) =3D val;
+}
+
+uint8_t ioread8(volatile void* addr)
+{
+   return *((volatile uint8_t*) addr);
+}
+uint16_t ioread16(volatile void* addr)
+{
+   return *((volatile uint16_t*) addr);
+}
+uint32_t ioread32(volatile void* addr)
+{
+   return *((volatile uint32_t*) addr);
+}
+uint64_t ioread64(volatile void* addr)
+{
+   return *((volatile uint64_t*) addr);
+}
diff --git a/extras/mini-os/include/iorw.h b/extras/mini-os/include/iorw.=
h
--- /dev/null
+++ b/extras/mini-os/include/iorw.h
@@ -0,0 +1,16 @@
+#ifndef MINIOS_IORW_H
+#define MINIOS_IORW_H
+
+#include <mini-os/types.h>
+
+void iowrite8(volatile void* addr, uint8_t val);
+void iowrite16(volatile void* addr, uint16_t val);
+void iowrite32(volatile void* addr, uint32_t val);
+void iowrite64(volatile void* addr, uint64_t val);
+
+uint8_t ioread8(volatile void* addr);
+uint16_t ioread16(volatile void* addr);
+uint32_t ioread32(volatile void* addr);
+uint64_t ioread64(volatile void* addr);
+
+#endif



--------------ms000202080400020804000201
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIDyjCC
A8YwggMvoAMCAQICBD/xyf0wDQYJKoZIhvcNAQEFBQAwLzELMAkGA1UEBhMCVVMxDzANBgNV
BAoTBkpIVUFQTDEPMA0GA1UECxMGQklTRENBMB4XDTEwMDYxMTE4MjIwNloXDTEzMDYxMTE4
NTIwNlowZjELMAkGA1UEBhMCVVMxDzANBgNVBAoTBkpIVUFQTDEPMA0GA1UECxMGUGVvcGxl
MTUwFgYDVQQLEw9WUE5Hcm91cC1CSVNEQ0EwGwYDVQQDExRNYXR0aGV3IEUgRmlvcmF2YW50
ZTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAnpbwVSP6o1Nb5lcW7dd3yTo9iBJdi7qz
4nANOMFPK7JOy5npKN1iiousl28U/scUJES55gPwAWYJK3uVyQAsA4adgDKi5DoD1UHDQEwp
bY7iHLJeq0NPr4BqYNqnCFPbE6HC8zSJrr4qKn+gVUQT39SIFqdiIPJwZL8FYTRQ/zsCAwEA
AaOCAbYwggGyMAsGA1UdDwQEAwIHgDArBgNVHRAEJDAigA8yMDEwMDYxMTE4MjIwNlqBDzIw
MTIwNzE3MjI1MjA2WjAbBg0rBgEEAbMlCwMBAQEBBAoWCGZpb3JhbWUxMBsGDSsGAQQBsyUL
AwEBAQIEChIIMDAxMDQyNjEwWAYJYIZIAYb6ax4BBEsMSVRoZSBwcml2YXRlIGtleSBjb3Jy
ZXNwb25kaW5nIHRvIHRoaXMgY2VydGlmaWNhdGUgbWF5IGhhdmUgYmVlbiBleHBvcnRlZC4w
KAYDVR0RBCEwH4EdTWF0dGhldy5GaW9yYXZhbnRlQGpodWFwbC5lZHUwUgYDVR0fBEswSTBH
oEWgQ6RBMD8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJU0RD
QTEOMAwGA1UEAxMFQ1JMNTYwHwYDVR0jBBgwFoAUCDUpmxH52EU2CyWmF2EJMB1yqeswHQYD
VR0OBBYEFO6LYxg6r9wHZ+zdQtBHn1dZ/YTNMAkGA1UdEwQCMAAwGQYJKoZIhvZ9B0EABAww
ChsEVjcuMQMCBLAwDQYJKoZIhvcNAQEFBQADgYEAJO9HQh4YNChVLzuZqK5ARJARD8JoujGZ
fdo75quvg2jXFQe2sEjvLnxJZgm/pv8fdZakq48CWwjYHKuvIp7sDjTEsQfo+y7SpN/N2NvJ
WU5SqfK1VgYtNLRRoGJUB5Q1aZ+Dg95g3kqpyfpUMISJL8IKVLtJVfN4fggFVUYZ9wwxggGr
MIIBpwIBATA3MC8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJ
U0RDQQIEP/HJ/TAJBgUrDgMCGgUAoIHLMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ
KoZIhvcNAQkFMQ8XDTEyMDkxODE3NTYxMFowIwYJKoZIhvcNAQkEMRYEFOzMvD7qTGDRXWaB
4sWUijV7gAktMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAK
BggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI
KoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEgYBhz+0iAfccbxMPZLXQbF2iIFZaTDbmUHlS
XIN5IYRE6G6mKQ+z0NBvhQ0nAVF3Fb29FKehKqxhfnvPbISeL1fef2o5973ex5MdVwPjBz3y
W0oqC49irpTAspwXsif2bIosZWhdIbgeoU/xP69rXWDVqciLX8CeKa1EduFtg86D5QAAAAAA
AA==
--------------ms000202080400020804000201--


--===============1824228950091041598==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============1824228950091041598==--


From xen-devel-bounces@lists.xen.org Tue Sep 18 18:08:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Sep 2012 18:08: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 1TE2D0-0007sr-Rz; Tue, 18 Sep 2012 18:07:42 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <samuel.thibault@ens-lyon.org>) id 1TE2D0-0007sm-4t
	for xen-devel@lists.xensource.com; Tue, 18 Sep 2012 18:07:42 +0000
Received: from [85.158.139.83:6385] by server-3.bemta-5.messagelabs.com id
	CF/96-21836-D68B8505; Tue, 18 Sep 2012 18:07:41 +0000
X-Env-Sender: samuel.thibault@ens-lyon.org
X-Msg-Ref: server-15.tower-182.messagelabs.com!1347991659!28891450!1
X-Originating-IP: [140.77.166.68]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19404 invoked from network); 18 Sep 2012 18:07:40 -0000
Received: from toccata.ens-lyon.fr (HELO toccata.ens-lyon.org) (140.77.166.68)
	by server-15.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 18 Sep 2012 18:07:40 -0000
Received: from localhost (localhost [127.0.0.1])
	by toccata.ens-lyon.org (Postfix) with ESMTP id AA81484098;
	Tue, 18 Sep 2012 20:07:38 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at toccata.ens-lyon.org
Received: from toccata.ens-lyon.org ([127.0.0.1])
	by localhost (toccata.ens-lyon.org [127.0.0.1]) (amavisd-new,
	port 10024)
	with ESMTP id 70jNZV8opxu5; Tue, 18 Sep 2012 20:07:38 +0200 (CEST)
Received: from type.ipv6 (youpi.is-a-geek.org [80.67.176.89])
	(using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits))
	(No client certificate requested)
	by toccata.ens-lyon.org (Postfix) with ESMTPSA id E705084093;
	Tue, 18 Sep 2012 20:07:37 +0200 (CEST)
Received: from samy by type.ipv6 with local (Exim 4.80)
	(envelope-from <samuel.thibault@ens-lyon.org>)
	id 1TE2Cp-00028J-Mc; Tue, 18 Sep 2012 20:07:31 +0200
Date: Tue, 18 Sep 2012 20:07:31 +0200
From: Samuel Thibault <samuel.thibault@ens-lyon.org>
To: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
Message-ID: <20120918180731.GD5021@type.youpi.perso.aquilenet.fr>
Mail-Followup-To: Samuel Thibault <samuel.thibault@ens-lyon.org>,
	Matthew Fioravante <matthew.fioravante@jhuapl.edu>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
References: <50579BA6.1080503@jhuapl.edu>
	<20120917222328.GN5110@type.youpi.perso.aquilenet.fr>
	<5058B5BA.3000408@jhuapl.edu>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <5058B5BA.3000408@jhuapl.edu>
User-Agent: Mutt/1.5.21+34 (58baf7c9f32f) (2010-12-30)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH mini-os enhancements for vtpm 1/8]
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Matthew Fioravante, le Tue 18 Sep 2012 13:56:10 -0400, a =E9crit :
> New patch.
> =

> Signed off by: Matthew Fioravante matthew.fioravante@jhuapl.edu

Acked-by: Samuel Thibault <samuel.thibault@ens-lyon.org>

> diff --git a/extras/mini-os/arch/ia64/iorw.c
> b/extras/mini-os/arch/ia64/iorw.c
> --- /dev/null
> +++ b/extras/mini-os/arch/ia64/iorw.c
> @@ -0,0 +1,48 @@
> +#include <mini-os/iorw.h>
> +#include <mini-os/console.h>
> +
> +void iowrite8(volatile void* addr, uint8_t val)
> +{
> +   printk("iorw not implemented!!\n");
> +   BUG();
> +}
> +void iowrite16(volatile void* addr, uint16_t val)
> +{
> +   printk("iorw not implemented!!\n");
> +   BUG();
> +}
> +void iowrite32(volatile void* addr, uint32_t val)
> +{
> +   printk("iorw not implemented!!\n");
> +   BUG();
> +}
> +void iowrite64(volatile void* addr, uint64_t val)
> +{
> +   printk("iorw not implemented!!\n");
> +   BUG();
> +}
> +
> +uint8_t ioread8(volatile void* addr)
> +{
> +   printk("iorw not implemented!!\n");
> +   BUG();
> +   return 0;
> +}
> +uint16_t ioread16(volatile void* addr)
> +{
> +   printk("iorw not implemented!!\n");
> +   BUG();
> +   return 0;
> +}
> +uint32_t ioread32(volatile void* addr)
> +{
> +   printk("iorw not implemented!!\n");
> +   BUG();
> +   return 0;
> +}
> +uint64_t ioread64(volatile void* addr)
> +{
> +   printk("iorw not implemented!!\n");
> +   BUG();
> +   return 0;
> +}
> diff --git a/extras/mini-os/arch/x86/iorw.c b/extras/mini-os/arch/x86/ior=
w.c
> --- /dev/null
> +++ b/extras/mini-os/arch/x86/iorw.c
> @@ -0,0 +1,35 @@
> +#include <mini-os/iorw.h>
> +
> +void iowrite8(volatile void* addr, uint8_t val)
> +{
> +   *((volatile uint8_t*)addr) =3D val;
> +}
> +void iowrite16(volatile void* addr, uint16_t val)
> +{
> +   *((volatile uint16_t*)addr) =3D val;
> +}
> +void iowrite32(volatile void* addr, uint32_t val)
> +{
> +   *((volatile uint32_t*)addr) =3D val;
> +}
> +void iowrite64(volatile void* addr, uint64_t val)
> +{
> +   *((volatile uint64_t*)addr) =3D val;
> +}
> +
> +uint8_t ioread8(volatile void* addr)
> +{
> +   return *((volatile uint8_t*) addr);
> +}
> +uint16_t ioread16(volatile void* addr)
> +{
> +   return *((volatile uint16_t*) addr);
> +}
> +uint32_t ioread32(volatile void* addr)
> +{
> +   return *((volatile uint32_t*) addr);
> +}
> +uint64_t ioread64(volatile void* addr)
> +{
> +   return *((volatile uint64_t*) addr);
> +}
> diff --git a/extras/mini-os/include/iorw.h b/extras/mini-os/include/iorw.h
> --- /dev/null
> +++ b/extras/mini-os/include/iorw.h
> @@ -0,0 +1,16 @@
> +#ifndef MINIOS_IORW_H
> +#define MINIOS_IORW_H
> +
> +#include <mini-os/types.h>
> +
> +void iowrite8(volatile void* addr, uint8_t val);
> +void iowrite16(volatile void* addr, uint16_t val);
> +void iowrite32(volatile void* addr, uint32_t val);
> +void iowrite64(volatile void* addr, uint64_t val);
> +
> +uint8_t ioread8(volatile void* addr);
> +uint16_t ioread16(volatile void* addr);
> +uint32_t ioread32(volatile void* addr);
> +uint64_t ioread64(volatile void* addr);
> +
> +#endif
> =

> =




-- =

Samuel
#ifndef I_WISH_WORLD_WERE_PERFECT
/* It is not :-( All the routers (except for Linux) return only
...
 -+- linux/net/ipv4/ipip.c -+-

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 18 18:08:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Sep 2012 18:08: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 1TE2D0-0007sr-Rz; Tue, 18 Sep 2012 18:07:42 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <samuel.thibault@ens-lyon.org>) id 1TE2D0-0007sm-4t
	for xen-devel@lists.xensource.com; Tue, 18 Sep 2012 18:07:42 +0000
Received: from [85.158.139.83:6385] by server-3.bemta-5.messagelabs.com id
	CF/96-21836-D68B8505; Tue, 18 Sep 2012 18:07:41 +0000
X-Env-Sender: samuel.thibault@ens-lyon.org
X-Msg-Ref: server-15.tower-182.messagelabs.com!1347991659!28891450!1
X-Originating-IP: [140.77.166.68]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19404 invoked from network); 18 Sep 2012 18:07:40 -0000
Received: from toccata.ens-lyon.fr (HELO toccata.ens-lyon.org) (140.77.166.68)
	by server-15.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 18 Sep 2012 18:07:40 -0000
Received: from localhost (localhost [127.0.0.1])
	by toccata.ens-lyon.org (Postfix) with ESMTP id AA81484098;
	Tue, 18 Sep 2012 20:07:38 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at toccata.ens-lyon.org
Received: from toccata.ens-lyon.org ([127.0.0.1])
	by localhost (toccata.ens-lyon.org [127.0.0.1]) (amavisd-new,
	port 10024)
	with ESMTP id 70jNZV8opxu5; Tue, 18 Sep 2012 20:07:38 +0200 (CEST)
Received: from type.ipv6 (youpi.is-a-geek.org [80.67.176.89])
	(using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits))
	(No client certificate requested)
	by toccata.ens-lyon.org (Postfix) with ESMTPSA id E705084093;
	Tue, 18 Sep 2012 20:07:37 +0200 (CEST)
Received: from samy by type.ipv6 with local (Exim 4.80)
	(envelope-from <samuel.thibault@ens-lyon.org>)
	id 1TE2Cp-00028J-Mc; Tue, 18 Sep 2012 20:07:31 +0200
Date: Tue, 18 Sep 2012 20:07:31 +0200
From: Samuel Thibault <samuel.thibault@ens-lyon.org>
To: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
Message-ID: <20120918180731.GD5021@type.youpi.perso.aquilenet.fr>
Mail-Followup-To: Samuel Thibault <samuel.thibault@ens-lyon.org>,
	Matthew Fioravante <matthew.fioravante@jhuapl.edu>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
References: <50579BA6.1080503@jhuapl.edu>
	<20120917222328.GN5110@type.youpi.perso.aquilenet.fr>
	<5058B5BA.3000408@jhuapl.edu>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <5058B5BA.3000408@jhuapl.edu>
User-Agent: Mutt/1.5.21+34 (58baf7c9f32f) (2010-12-30)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH mini-os enhancements for vtpm 1/8]
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Matthew Fioravante, le Tue 18 Sep 2012 13:56:10 -0400, a =E9crit :
> New patch.
> =

> Signed off by: Matthew Fioravante matthew.fioravante@jhuapl.edu

Acked-by: Samuel Thibault <samuel.thibault@ens-lyon.org>

> diff --git a/extras/mini-os/arch/ia64/iorw.c
> b/extras/mini-os/arch/ia64/iorw.c
> --- /dev/null
> +++ b/extras/mini-os/arch/ia64/iorw.c
> @@ -0,0 +1,48 @@
> +#include <mini-os/iorw.h>
> +#include <mini-os/console.h>
> +
> +void iowrite8(volatile void* addr, uint8_t val)
> +{
> +   printk("iorw not implemented!!\n");
> +   BUG();
> +}
> +void iowrite16(volatile void* addr, uint16_t val)
> +{
> +   printk("iorw not implemented!!\n");
> +   BUG();
> +}
> +void iowrite32(volatile void* addr, uint32_t val)
> +{
> +   printk("iorw not implemented!!\n");
> +   BUG();
> +}
> +void iowrite64(volatile void* addr, uint64_t val)
> +{
> +   printk("iorw not implemented!!\n");
> +   BUG();
> +}
> +
> +uint8_t ioread8(volatile void* addr)
> +{
> +   printk("iorw not implemented!!\n");
> +   BUG();
> +   return 0;
> +}
> +uint16_t ioread16(volatile void* addr)
> +{
> +   printk("iorw not implemented!!\n");
> +   BUG();
> +   return 0;
> +}
> +uint32_t ioread32(volatile void* addr)
> +{
> +   printk("iorw not implemented!!\n");
> +   BUG();
> +   return 0;
> +}
> +uint64_t ioread64(volatile void* addr)
> +{
> +   printk("iorw not implemented!!\n");
> +   BUG();
> +   return 0;
> +}
> diff --git a/extras/mini-os/arch/x86/iorw.c b/extras/mini-os/arch/x86/ior=
w.c
> --- /dev/null
> +++ b/extras/mini-os/arch/x86/iorw.c
> @@ -0,0 +1,35 @@
> +#include <mini-os/iorw.h>
> +
> +void iowrite8(volatile void* addr, uint8_t val)
> +{
> +   *((volatile uint8_t*)addr) =3D val;
> +}
> +void iowrite16(volatile void* addr, uint16_t val)
> +{
> +   *((volatile uint16_t*)addr) =3D val;
> +}
> +void iowrite32(volatile void* addr, uint32_t val)
> +{
> +   *((volatile uint32_t*)addr) =3D val;
> +}
> +void iowrite64(volatile void* addr, uint64_t val)
> +{
> +   *((volatile uint64_t*)addr) =3D val;
> +}
> +
> +uint8_t ioread8(volatile void* addr)
> +{
> +   return *((volatile uint8_t*) addr);
> +}
> +uint16_t ioread16(volatile void* addr)
> +{
> +   return *((volatile uint16_t*) addr);
> +}
> +uint32_t ioread32(volatile void* addr)
> +{
> +   return *((volatile uint32_t*) addr);
> +}
> +uint64_t ioread64(volatile void* addr)
> +{
> +   return *((volatile uint64_t*) addr);
> +}
> diff --git a/extras/mini-os/include/iorw.h b/extras/mini-os/include/iorw.h
> --- /dev/null
> +++ b/extras/mini-os/include/iorw.h
> @@ -0,0 +1,16 @@
> +#ifndef MINIOS_IORW_H
> +#define MINIOS_IORW_H
> +
> +#include <mini-os/types.h>
> +
> +void iowrite8(volatile void* addr, uint8_t val);
> +void iowrite16(volatile void* addr, uint16_t val);
> +void iowrite32(volatile void* addr, uint32_t val);
> +void iowrite64(volatile void* addr, uint64_t val);
> +
> +uint8_t ioread8(volatile void* addr);
> +uint16_t ioread16(volatile void* addr);
> +uint32_t ioread32(volatile void* addr);
> +uint64_t ioread64(volatile void* addr);
> +
> +#endif
> =

> =




-- =

Samuel
#ifndef I_WISH_WORLD_WERE_PERFECT
/* It is not :-( All the routers (except for Linux) return only
...
 -+- linux/net/ipv4/ipip.c -+-

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 18 18:11:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Sep 2012 18: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 1TE2GB-0007zT-FN; Tue, 18 Sep 2012 18:10:59 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <matthew.fioravante@jhuapl.edu>) id 1TE2G9-0007zK-Lf
	for xen-devel@lists.xensource.com; Tue, 18 Sep 2012 18:10:57 +0000
Received: from [85.158.138.51:55337] by server-11.bemta-3.messagelabs.com id
	2E/53-30250-039B8505; Tue, 18 Sep 2012 18:10:56 +0000
X-Env-Sender: matthew.fioravante@jhuapl.edu
X-Msg-Ref: server-13.tower-174.messagelabs.com!1347991854!12391330!1
X-Originating-IP: [128.244.251.36]
X-SpamReason: No, hits=0.0 required=7.0 tests=UNPARSEABLE_RELAY
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26685 invoked from network); 18 Sep 2012 18:10:55 -0000
Received: from pilot.jhuapl.edu (HELO jhuapl.edu) (128.244.251.36)
	by server-13.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 18 Sep 2012 18:10:55 -0000
Received: from ([128.244.207.89])
	by pilot.jhuapl.edu with ESMTP with TLS id 63GHCH1.153150431;
	Tue, 18 Sep 2012 14:10:47 -0400
Message-ID: <5058B8DB.5040109@jhuapl.edu>
Date: Tue, 18 Sep 2012 14:09:31 -0400
From: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120827 Thunderbird/15.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>, 
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
X-Enigmail-Version: 1.4.4
Subject: [Xen-devel] [PATCH xm/xl enhancements for vptm 1/6] xl make devid a
	libxl 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: multipart/mixed; boundary="===============1293133164239552894=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a cryptographically signed message in MIME format.

--===============1293133164239552894==
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms040306070808000000020105"

This is a cryptographically signed message in MIME format.

--------------ms040306070808000000020105
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Previously device ids in libxl were treated as integers meaning they
were being initialized to 0, which is a valid device id. This patch
makes devid its own type in libxl and initializes it to -1, an invalid
value.

Signed off by Matthew Fioravante matthew.fioravante@jhuapl.edu

diff --git a/tools/libxl/gentest.py b/tools/libxl/gentest.py
--- a/tools/libxl/gentest.py
+++ b/tools/libxl/gentest.py
@@ -48,7 +48,7 @@ def gen_rand_init(ty, v, indent =3D "    ", parent =3D =
None):
                                         passby=3Didl.PASS_BY_REFERENCE))=

     elif ty.typename in ["libxl_uuid", "libxl_mac", "libxl_hwcap"]:
         s +=3D "rand_bytes((uint8_t *)%s, sizeof(*%s));\n" % (v,v)
-    elif ty.typename in ["libxl_domid"] or isinstance(ty, idl.Number):
+    elif ty.typename in ["libxl_domid", "libxl_devid"] or
isinstance(ty, idl.Number):
         s +=3D "%s =3D rand() %% (sizeof(%s)*8);\n" % \
              (ty.pass_arg(v, parent is None),
               ty.pass_arg(v, parent is None))
diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -299,6 +299,7 @@ void libxl_cpuid_dispose(libxl_cpuid_policy_list
*cpuid_list);
 #define LIBXL_PCI_FUNC_ALL (~0U)
=20
 typedef uint32_t libxl_domid;
+typedef int libxl_devid;
=20
 /*
  * Formatting Enumerations.
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
@@ -8,6 +8,7 @@ namespace("libxl_")
 libxl_defbool =3D Builtin("defbool", passby=3DPASS_BY_REFERENCE)
=20
 libxl_domid =3D Builtin("domid", json_fn =3D "yajl_gen_integer",
autogenerate_json =3D False)
+libxl_devid =3D Builtin("devid", json_fn =3D "yajl_gen_integer",
autogenerate_json =3D False, signed =3D True, init_val=3D"-1")
 libxl_uuid =3D Builtin("uuid", passby=3DPASS_BY_REFERENCE)
 libxl_mac =3D Builtin("mac", passby=3DPASS_BY_REFERENCE)
 libxl_cpumap =3D Builtin("cpumap", dispose_fn=3D"libxl_cpumap_dispose",
passby=3DPASS_BY_REFERENCE)
@@ -318,7 +319,7 @@ libxl_domain_build_info =3D Struct("domain_build_info=
",[
=20
 libxl_device_vfb =3D Struct("device_vfb", [
     ("backend_domid", libxl_domid),
-    ("devid",         integer),
+    ("devid",         libxl_devid),
     ("vnc",           libxl_vnc_info),
     ("sdl",           libxl_sdl_info),
     # set keyboard layout, default is en-us keyboard
@@ -327,7 +328,7 @@ libxl_device_vfb =3D Struct("device_vfb", [
=20
 libxl_device_vkb =3D Struct("device_vkb", [
     ("backend_domid", libxl_domid),
-    ("devid", integer),
+    ("devid", libxl_devid),
     ])
=20
 libxl_device_disk =3D Struct("device_disk", [
@@ -344,7 +345,7 @@ libxl_device_disk =3D Struct("device_disk", [
=20
 libxl_device_nic =3D Struct("device_nic", [
     ("backend_domid", libxl_domid),
-    ("devid", integer),
+    ("devid", libxl_devid),
     ("mtu", integer),
     ("model", string),
     ("mac", libxl_mac),
@@ -374,7 +375,7 @@ libxl_diskinfo =3D Struct("diskinfo", [
     ("backend_id", uint32),
     ("frontend", string),
     ("frontend_id", uint32),
-    ("devid", integer),
+    ("devid", libxl_devid),
     ("state", integer),
     ("evtch", integer),
     ("rref", integer),
@@ -385,7 +386,7 @@ libxl_nicinfo =3D Struct("nicinfo", [
     ("backend_id", uint32),
     ("frontend", string),
     ("frontend_id", uint32),
-    ("devid", integer),
+    ("devid", libxl_devid),
     ("state", integer),
     ("evtch", integer),
     ("rref_tx", integer),
diff --git a/tools/ocaml/libs/xc/xenctrl.ml b/tools/ocaml/libs/xc/xenctrl=
=2Eml
--- a/tools/ocaml/libs/xc/xenctrl.ml
+++ b/tools/ocaml/libs/xc/xenctrl.ml
@@ -16,6 +16,7 @@
=20
 (** *)
 type domid =3D int
+type devid =3D int
=20
 (* ** xenctrl.h ** *)
=20
diff --git a/tools/ocaml/libs/xc/xenctrl.mli
b/tools/ocaml/libs/xc/xenctrl.mli
--- a/tools/ocaml/libs/xc/xenctrl.mli
+++ b/tools/ocaml/libs/xc/xenctrl.mli
@@ -15,6 +15,7 @@
  *)
=20
 type domid =3D int
+type devid =3D int
 type vcpuinfo =3D {
   online : bool;
   blocked : bool;
diff --git a/tools/ocaml/libs/xl/genwrap.py b/tools/ocaml/libs/xl/genwrap=
=2Epy
--- a/tools/ocaml/libs/xl/genwrap.py
+++ b/tools/ocaml/libs/xl/genwrap.py
@@ -10,6 +10,7 @@ builtins =3D {
     "int":                  ("int",                    "%(c)s =3D
Int_val(%(o)s)",            "Val_int(%(c)s)"  ),
     "char *":               ("string",                 "%(c)s =3D
dup_String_val(gc, %(o)s)", "caml_copy_string(%(c)s)"),
     "libxl_domid":          ("domid",                  "%(c)s =3D
Int_val(%(o)s)",            "Val_int(%(c)s)"  ),
+    "libxl_devid":          ("devid",                  "%(c)s =3D
Int_val(%(o)s)",            "Val_int(%(c)s)"  ),
     "libxl_defbool":        ("bool option",            "%(c)s =3D
Defbool_val(%(o)s)",        "Val_defbool(%(c)s)" ),
     "libxl_uuid":           ("int array",              "Uuid_val(gc,
lg, &%(c)s, %(o)s)",   "Val_uuid(&%(c)s)"),
     "libxl_key_value_list": ("(string * string) list",
None,                                None),
@@ -41,8 +42,8 @@ def stub_fn_name(ty, name):
     return "stub_xl_%s_%s" % (ty.rawname,name)
   =20
 def ocaml_type_of(ty):
-    if ty.rawname =3D=3D "domid":
-        return "domid"
+    if ty.rawname in ["domid","devid"]:
+        return ty.rawname
     elif isinstance(ty,idl.UInt):
         if ty.width in [8, 16]:
             # handle as ints
diff --git a/tools/ocaml/libs/xl/xenlight.ml.in
b/tools/ocaml/libs/xl/xenlight.ml.in
--- a/tools/ocaml/libs/xl/xenlight.ml.in
+++ b/tools/ocaml/libs/xl/xenlight.ml.in
@@ -16,6 +16,7 @@
 exception Error of string
=20
 type domid =3D int
+type devid =3D int
=20
 (* @@LIBXL_TYPES@@ *)
=20
diff --git a/tools/ocaml/libs/xl/xenlight.mli.in
b/tools/ocaml/libs/xl/xenlight.mli.in
--- a/tools/ocaml/libs/xl/xenlight.mli.in
+++ b/tools/ocaml/libs/xl/xenlight.mli.in
@@ -16,6 +16,7 @@
 exception Error of string
=20
 type domid =3D int
+type devid =3D int
=20
 (* @@LIBXL_TYPES@@ *)
=20
diff --git a/tools/ocaml/libs/xs/xs.ml b/tools/ocaml/libs/xs/xs.ml
--- a/tools/ocaml/libs/xs/xs.ml
+++ b/tools/ocaml/libs/xs/xs.ml
@@ -17,6 +17,7 @@
 type perms =3D Xsraw.perms
 type con =3D Xsraw.con
 type domid =3D int
+type devid =3D int
=20
 type xsh =3D
 {
diff --git a/tools/ocaml/libs/xs/xs.mli b/tools/ocaml/libs/xs/xs.mli
--- a/tools/ocaml/libs/xs/xs.mli
+++ b/tools/ocaml/libs/xs/xs.mli
@@ -27,6 +27,7 @@ exception Failed_to_connect
 type perms =3D Xsraw.perms
=20
 type domid =3D int
+type devid =3D int
 type con
=20
 type xsh =3D {
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
@@ -281,6 +281,11 @@ int attrib__libxl_domid_set(PyObject *v,
libxl_domid *domid) {
     return 0;
 }
=20
+int attrib__libxl_devid_set(PyObject *v, libxl_devid *devid) {
+   *devid =3D PyInt_AsLong(v);
+   return 0;
+}
+
 int attrib__struct_in_addr_set(PyObject *v, struct in_addr *pptr)
 {
     PyErr_SetString(PyExc_NotImplementedError, "Setting in_addr");
@@ -342,6 +347,10 @@ PyObject *attrib__libxl_domid_get(libxl_domid *domid=
) {
     return PyInt_FromLong(*domid);
 }
=20
+PyObject *attrib__libxl_devid_get(libxl_devid *devid) {
+    return PyInt_FromLong(*devid);
+}
+
 PyObject *attrib__struct_in_addr_get(struct in_addr *pptr)
 {
     PyErr_SetString(PyExc_NotImplementedError, "Getting in_addr");
--=20
1.7.4.4



--------------ms040306070808000000020105
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIDyjCC
A8YwggMvoAMCAQICBD/xyf0wDQYJKoZIhvcNAQEFBQAwLzELMAkGA1UEBhMCVVMxDzANBgNV
BAoTBkpIVUFQTDEPMA0GA1UECxMGQklTRENBMB4XDTEwMDYxMTE4MjIwNloXDTEzMDYxMTE4
NTIwNlowZjELMAkGA1UEBhMCVVMxDzANBgNVBAoTBkpIVUFQTDEPMA0GA1UECxMGUGVvcGxl
MTUwFgYDVQQLEw9WUE5Hcm91cC1CSVNEQ0EwGwYDVQQDExRNYXR0aGV3IEUgRmlvcmF2YW50
ZTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAnpbwVSP6o1Nb5lcW7dd3yTo9iBJdi7qz
4nANOMFPK7JOy5npKN1iiousl28U/scUJES55gPwAWYJK3uVyQAsA4adgDKi5DoD1UHDQEwp
bY7iHLJeq0NPr4BqYNqnCFPbE6HC8zSJrr4qKn+gVUQT39SIFqdiIPJwZL8FYTRQ/zsCAwEA
AaOCAbYwggGyMAsGA1UdDwQEAwIHgDArBgNVHRAEJDAigA8yMDEwMDYxMTE4MjIwNlqBDzIw
MTIwNzE3MjI1MjA2WjAbBg0rBgEEAbMlCwMBAQEBBAoWCGZpb3JhbWUxMBsGDSsGAQQBsyUL
AwEBAQIEChIIMDAxMDQyNjEwWAYJYIZIAYb6ax4BBEsMSVRoZSBwcml2YXRlIGtleSBjb3Jy
ZXNwb25kaW5nIHRvIHRoaXMgY2VydGlmaWNhdGUgbWF5IGhhdmUgYmVlbiBleHBvcnRlZC4w
KAYDVR0RBCEwH4EdTWF0dGhldy5GaW9yYXZhbnRlQGpodWFwbC5lZHUwUgYDVR0fBEswSTBH
oEWgQ6RBMD8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJU0RD
QTEOMAwGA1UEAxMFQ1JMNTYwHwYDVR0jBBgwFoAUCDUpmxH52EU2CyWmF2EJMB1yqeswHQYD
VR0OBBYEFO6LYxg6r9wHZ+zdQtBHn1dZ/YTNMAkGA1UdEwQCMAAwGQYJKoZIhvZ9B0EABAww
ChsEVjcuMQMCBLAwDQYJKoZIhvcNAQEFBQADgYEAJO9HQh4YNChVLzuZqK5ARJARD8JoujGZ
fdo75quvg2jXFQe2sEjvLnxJZgm/pv8fdZakq48CWwjYHKuvIp7sDjTEsQfo+y7SpN/N2NvJ
WU5SqfK1VgYtNLRRoGJUB5Q1aZ+Dg95g3kqpyfpUMISJL8IKVLtJVfN4fggFVUYZ9wwxggGr
MIIBpwIBATA3MC8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJ
U0RDQQIEP/HJ/TAJBgUrDgMCGgUAoIHLMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ
KoZIhvcNAQkFMQ8XDTEyMDkxODE4MDkzMVowIwYJKoZIhvcNAQkEMRYEFCbUDSqniEtrH2AB
/3fYYG1xJN2zMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAK
BggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI
KoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEgYBXcKGMJ7ATCg6DkasTqPPH68S6Jcqadzeb
6ZQtxKfWCP93PUbUHSG78P7TgvlcJvoXtrhlTMGxLYf3qv+sr+n2U315mtYZGHIIiqasZz9z
y6jyH7XzqTMkSHE6/7mgP2KycHNJfVyiF3AqbNeEc4AaYYSV4FUwaY9Ljl4fInXH8QAAAAAA
AA==
--------------ms040306070808000000020105--


--===============1293133164239552894==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============1293133164239552894==--


From xen-devel-bounces@lists.xen.org Tue Sep 18 18:11:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Sep 2012 18: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 1TE2GB-0007zT-FN; Tue, 18 Sep 2012 18:10:59 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <matthew.fioravante@jhuapl.edu>) id 1TE2G9-0007zK-Lf
	for xen-devel@lists.xensource.com; Tue, 18 Sep 2012 18:10:57 +0000
Received: from [85.158.138.51:55337] by server-11.bemta-3.messagelabs.com id
	2E/53-30250-039B8505; Tue, 18 Sep 2012 18:10:56 +0000
X-Env-Sender: matthew.fioravante@jhuapl.edu
X-Msg-Ref: server-13.tower-174.messagelabs.com!1347991854!12391330!1
X-Originating-IP: [128.244.251.36]
X-SpamReason: No, hits=0.0 required=7.0 tests=UNPARSEABLE_RELAY
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26685 invoked from network); 18 Sep 2012 18:10:55 -0000
Received: from pilot.jhuapl.edu (HELO jhuapl.edu) (128.244.251.36)
	by server-13.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 18 Sep 2012 18:10:55 -0000
Received: from ([128.244.207.89])
	by pilot.jhuapl.edu with ESMTP with TLS id 63GHCH1.153150431;
	Tue, 18 Sep 2012 14:10:47 -0400
Message-ID: <5058B8DB.5040109@jhuapl.edu>
Date: Tue, 18 Sep 2012 14:09:31 -0400
From: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120827 Thunderbird/15.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>, 
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
X-Enigmail-Version: 1.4.4
Subject: [Xen-devel] [PATCH xm/xl enhancements for vptm 1/6] xl make devid a
	libxl 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: multipart/mixed; boundary="===============1293133164239552894=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a cryptographically signed message in MIME format.

--===============1293133164239552894==
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms040306070808000000020105"

This is a cryptographically signed message in MIME format.

--------------ms040306070808000000020105
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Previously device ids in libxl were treated as integers meaning they
were being initialized to 0, which is a valid device id. This patch
makes devid its own type in libxl and initializes it to -1, an invalid
value.

Signed off by Matthew Fioravante matthew.fioravante@jhuapl.edu

diff --git a/tools/libxl/gentest.py b/tools/libxl/gentest.py
--- a/tools/libxl/gentest.py
+++ b/tools/libxl/gentest.py
@@ -48,7 +48,7 @@ def gen_rand_init(ty, v, indent =3D "    ", parent =3D =
None):
                                         passby=3Didl.PASS_BY_REFERENCE))=

     elif ty.typename in ["libxl_uuid", "libxl_mac", "libxl_hwcap"]:
         s +=3D "rand_bytes((uint8_t *)%s, sizeof(*%s));\n" % (v,v)
-    elif ty.typename in ["libxl_domid"] or isinstance(ty, idl.Number):
+    elif ty.typename in ["libxl_domid", "libxl_devid"] or
isinstance(ty, idl.Number):
         s +=3D "%s =3D rand() %% (sizeof(%s)*8);\n" % \
              (ty.pass_arg(v, parent is None),
               ty.pass_arg(v, parent is None))
diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -299,6 +299,7 @@ void libxl_cpuid_dispose(libxl_cpuid_policy_list
*cpuid_list);
 #define LIBXL_PCI_FUNC_ALL (~0U)
=20
 typedef uint32_t libxl_domid;
+typedef int libxl_devid;
=20
 /*
  * Formatting Enumerations.
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
@@ -8,6 +8,7 @@ namespace("libxl_")
 libxl_defbool =3D Builtin("defbool", passby=3DPASS_BY_REFERENCE)
=20
 libxl_domid =3D Builtin("domid", json_fn =3D "yajl_gen_integer",
autogenerate_json =3D False)
+libxl_devid =3D Builtin("devid", json_fn =3D "yajl_gen_integer",
autogenerate_json =3D False, signed =3D True, init_val=3D"-1")
 libxl_uuid =3D Builtin("uuid", passby=3DPASS_BY_REFERENCE)
 libxl_mac =3D Builtin("mac", passby=3DPASS_BY_REFERENCE)
 libxl_cpumap =3D Builtin("cpumap", dispose_fn=3D"libxl_cpumap_dispose",
passby=3DPASS_BY_REFERENCE)
@@ -318,7 +319,7 @@ libxl_domain_build_info =3D Struct("domain_build_info=
",[
=20
 libxl_device_vfb =3D Struct("device_vfb", [
     ("backend_domid", libxl_domid),
-    ("devid",         integer),
+    ("devid",         libxl_devid),
     ("vnc",           libxl_vnc_info),
     ("sdl",           libxl_sdl_info),
     # set keyboard layout, default is en-us keyboard
@@ -327,7 +328,7 @@ libxl_device_vfb =3D Struct("device_vfb", [
=20
 libxl_device_vkb =3D Struct("device_vkb", [
     ("backend_domid", libxl_domid),
-    ("devid", integer),
+    ("devid", libxl_devid),
     ])
=20
 libxl_device_disk =3D Struct("device_disk", [
@@ -344,7 +345,7 @@ libxl_device_disk =3D Struct("device_disk", [
=20
 libxl_device_nic =3D Struct("device_nic", [
     ("backend_domid", libxl_domid),
-    ("devid", integer),
+    ("devid", libxl_devid),
     ("mtu", integer),
     ("model", string),
     ("mac", libxl_mac),
@@ -374,7 +375,7 @@ libxl_diskinfo =3D Struct("diskinfo", [
     ("backend_id", uint32),
     ("frontend", string),
     ("frontend_id", uint32),
-    ("devid", integer),
+    ("devid", libxl_devid),
     ("state", integer),
     ("evtch", integer),
     ("rref", integer),
@@ -385,7 +386,7 @@ libxl_nicinfo =3D Struct("nicinfo", [
     ("backend_id", uint32),
     ("frontend", string),
     ("frontend_id", uint32),
-    ("devid", integer),
+    ("devid", libxl_devid),
     ("state", integer),
     ("evtch", integer),
     ("rref_tx", integer),
diff --git a/tools/ocaml/libs/xc/xenctrl.ml b/tools/ocaml/libs/xc/xenctrl=
=2Eml
--- a/tools/ocaml/libs/xc/xenctrl.ml
+++ b/tools/ocaml/libs/xc/xenctrl.ml
@@ -16,6 +16,7 @@
=20
 (** *)
 type domid =3D int
+type devid =3D int
=20
 (* ** xenctrl.h ** *)
=20
diff --git a/tools/ocaml/libs/xc/xenctrl.mli
b/tools/ocaml/libs/xc/xenctrl.mli
--- a/tools/ocaml/libs/xc/xenctrl.mli
+++ b/tools/ocaml/libs/xc/xenctrl.mli
@@ -15,6 +15,7 @@
  *)
=20
 type domid =3D int
+type devid =3D int
 type vcpuinfo =3D {
   online : bool;
   blocked : bool;
diff --git a/tools/ocaml/libs/xl/genwrap.py b/tools/ocaml/libs/xl/genwrap=
=2Epy
--- a/tools/ocaml/libs/xl/genwrap.py
+++ b/tools/ocaml/libs/xl/genwrap.py
@@ -10,6 +10,7 @@ builtins =3D {
     "int":                  ("int",                    "%(c)s =3D
Int_val(%(o)s)",            "Val_int(%(c)s)"  ),
     "char *":               ("string",                 "%(c)s =3D
dup_String_val(gc, %(o)s)", "caml_copy_string(%(c)s)"),
     "libxl_domid":          ("domid",                  "%(c)s =3D
Int_val(%(o)s)",            "Val_int(%(c)s)"  ),
+    "libxl_devid":          ("devid",                  "%(c)s =3D
Int_val(%(o)s)",            "Val_int(%(c)s)"  ),
     "libxl_defbool":        ("bool option",            "%(c)s =3D
Defbool_val(%(o)s)",        "Val_defbool(%(c)s)" ),
     "libxl_uuid":           ("int array",              "Uuid_val(gc,
lg, &%(c)s, %(o)s)",   "Val_uuid(&%(c)s)"),
     "libxl_key_value_list": ("(string * string) list",
None,                                None),
@@ -41,8 +42,8 @@ def stub_fn_name(ty, name):
     return "stub_xl_%s_%s" % (ty.rawname,name)
   =20
 def ocaml_type_of(ty):
-    if ty.rawname =3D=3D "domid":
-        return "domid"
+    if ty.rawname in ["domid","devid"]:
+        return ty.rawname
     elif isinstance(ty,idl.UInt):
         if ty.width in [8, 16]:
             # handle as ints
diff --git a/tools/ocaml/libs/xl/xenlight.ml.in
b/tools/ocaml/libs/xl/xenlight.ml.in
--- a/tools/ocaml/libs/xl/xenlight.ml.in
+++ b/tools/ocaml/libs/xl/xenlight.ml.in
@@ -16,6 +16,7 @@
 exception Error of string
=20
 type domid =3D int
+type devid =3D int
=20
 (* @@LIBXL_TYPES@@ *)
=20
diff --git a/tools/ocaml/libs/xl/xenlight.mli.in
b/tools/ocaml/libs/xl/xenlight.mli.in
--- a/tools/ocaml/libs/xl/xenlight.mli.in
+++ b/tools/ocaml/libs/xl/xenlight.mli.in
@@ -16,6 +16,7 @@
 exception Error of string
=20
 type domid =3D int
+type devid =3D int
=20
 (* @@LIBXL_TYPES@@ *)
=20
diff --git a/tools/ocaml/libs/xs/xs.ml b/tools/ocaml/libs/xs/xs.ml
--- a/tools/ocaml/libs/xs/xs.ml
+++ b/tools/ocaml/libs/xs/xs.ml
@@ -17,6 +17,7 @@
 type perms =3D Xsraw.perms
 type con =3D Xsraw.con
 type domid =3D int
+type devid =3D int
=20
 type xsh =3D
 {
diff --git a/tools/ocaml/libs/xs/xs.mli b/tools/ocaml/libs/xs/xs.mli
--- a/tools/ocaml/libs/xs/xs.mli
+++ b/tools/ocaml/libs/xs/xs.mli
@@ -27,6 +27,7 @@ exception Failed_to_connect
 type perms =3D Xsraw.perms
=20
 type domid =3D int
+type devid =3D int
 type con
=20
 type xsh =3D {
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
@@ -281,6 +281,11 @@ int attrib__libxl_domid_set(PyObject *v,
libxl_domid *domid) {
     return 0;
 }
=20
+int attrib__libxl_devid_set(PyObject *v, libxl_devid *devid) {
+   *devid =3D PyInt_AsLong(v);
+   return 0;
+}
+
 int attrib__struct_in_addr_set(PyObject *v, struct in_addr *pptr)
 {
     PyErr_SetString(PyExc_NotImplementedError, "Setting in_addr");
@@ -342,6 +347,10 @@ PyObject *attrib__libxl_domid_get(libxl_domid *domid=
) {
     return PyInt_FromLong(*domid);
 }
=20
+PyObject *attrib__libxl_devid_get(libxl_devid *devid) {
+    return PyInt_FromLong(*devid);
+}
+
 PyObject *attrib__struct_in_addr_get(struct in_addr *pptr)
 {
     PyErr_SetString(PyExc_NotImplementedError, "Getting in_addr");
--=20
1.7.4.4



--------------ms040306070808000000020105
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIDyjCC
A8YwggMvoAMCAQICBD/xyf0wDQYJKoZIhvcNAQEFBQAwLzELMAkGA1UEBhMCVVMxDzANBgNV
BAoTBkpIVUFQTDEPMA0GA1UECxMGQklTRENBMB4XDTEwMDYxMTE4MjIwNloXDTEzMDYxMTE4
NTIwNlowZjELMAkGA1UEBhMCVVMxDzANBgNVBAoTBkpIVUFQTDEPMA0GA1UECxMGUGVvcGxl
MTUwFgYDVQQLEw9WUE5Hcm91cC1CSVNEQ0EwGwYDVQQDExRNYXR0aGV3IEUgRmlvcmF2YW50
ZTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAnpbwVSP6o1Nb5lcW7dd3yTo9iBJdi7qz
4nANOMFPK7JOy5npKN1iiousl28U/scUJES55gPwAWYJK3uVyQAsA4adgDKi5DoD1UHDQEwp
bY7iHLJeq0NPr4BqYNqnCFPbE6HC8zSJrr4qKn+gVUQT39SIFqdiIPJwZL8FYTRQ/zsCAwEA
AaOCAbYwggGyMAsGA1UdDwQEAwIHgDArBgNVHRAEJDAigA8yMDEwMDYxMTE4MjIwNlqBDzIw
MTIwNzE3MjI1MjA2WjAbBg0rBgEEAbMlCwMBAQEBBAoWCGZpb3JhbWUxMBsGDSsGAQQBsyUL
AwEBAQIEChIIMDAxMDQyNjEwWAYJYIZIAYb6ax4BBEsMSVRoZSBwcml2YXRlIGtleSBjb3Jy
ZXNwb25kaW5nIHRvIHRoaXMgY2VydGlmaWNhdGUgbWF5IGhhdmUgYmVlbiBleHBvcnRlZC4w
KAYDVR0RBCEwH4EdTWF0dGhldy5GaW9yYXZhbnRlQGpodWFwbC5lZHUwUgYDVR0fBEswSTBH
oEWgQ6RBMD8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJU0RD
QTEOMAwGA1UEAxMFQ1JMNTYwHwYDVR0jBBgwFoAUCDUpmxH52EU2CyWmF2EJMB1yqeswHQYD
VR0OBBYEFO6LYxg6r9wHZ+zdQtBHn1dZ/YTNMAkGA1UdEwQCMAAwGQYJKoZIhvZ9B0EABAww
ChsEVjcuMQMCBLAwDQYJKoZIhvcNAQEFBQADgYEAJO9HQh4YNChVLzuZqK5ARJARD8JoujGZ
fdo75quvg2jXFQe2sEjvLnxJZgm/pv8fdZakq48CWwjYHKuvIp7sDjTEsQfo+y7SpN/N2NvJ
WU5SqfK1VgYtNLRRoGJUB5Q1aZ+Dg95g3kqpyfpUMISJL8IKVLtJVfN4fggFVUYZ9wwxggGr
MIIBpwIBATA3MC8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJ
U0RDQQIEP/HJ/TAJBgUrDgMCGgUAoIHLMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ
KoZIhvcNAQkFMQ8XDTEyMDkxODE4MDkzMVowIwYJKoZIhvcNAQkEMRYEFCbUDSqniEtrH2AB
/3fYYG1xJN2zMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAK
BggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI
KoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEgYBXcKGMJ7ATCg6DkasTqPPH68S6Jcqadzeb
6ZQtxKfWCP93PUbUHSG78P7TgvlcJvoXtrhlTMGxLYf3qv+sr+n2U315mtYZGHIIiqasZz9z
y6jyH7XzqTMkSHE6/7mgP2KycHNJfVyiF3AqbNeEc4AaYYSV4FUwaY9Ljl4fInXH8QAAAAAA
AA==
--------------ms040306070808000000020105--


--===============1293133164239552894==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============1293133164239552894==--


From xen-devel-bounces@lists.xen.org Tue Sep 18 18:13:35 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Sep 2012 18:13:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TE2IR-000872-27; Tue, 18 Sep 2012 18:13:19 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <matthew.fioravante@jhuapl.edu>) id 1TE2IP-00086v-1f
	for xen-devel@lists.xensource.com; Tue, 18 Sep 2012 18:13:17 +0000
Received: from [85.158.137.99:25494] by server-5.bemta-3.messagelabs.com id
	15/61-13133-CB9B8505; Tue, 18 Sep 2012 18:13:16 +0000
X-Env-Sender: matthew.fioravante@jhuapl.edu
X-Msg-Ref: server-3.tower-217.messagelabs.com!1347991992!13133603!1
X-Originating-IP: [128.244.251.36]
X-SpamReason: No, hits=0.0 required=7.0 tests=UNPARSEABLE_RELAY
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6485 invoked from network); 18 Sep 2012 18:13:13 -0000
Received: from pilot.jhuapl.edu (HELO jhuapl.edu) (128.244.251.36)
	by server-3.tower-217.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 18 Sep 2012 18:13:13 -0000
Received: from ([128.244.207.89])
	by pilot.jhuapl.edu with ESMTP with TLS id 63GHCH1.153150672;
	Tue, 18 Sep 2012 14:13:09 -0400
Message-ID: <5058B969.4020503@jhuapl.edu>
Date: Tue, 18 Sep 2012 14:11:53 -0400
From: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120827 Thunderbird/15.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>, 
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
X-Enigmail-Version: 1.4.4
Subject: [Xen-devel] [PATCH xm/xl enhancements for vptm 2/6] add vtpm
	support to libxl
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============5264763171101467337=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a cryptographically signed message in MIME format.

--===============5264763171101467337==
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms090908050706050506080700"

This is a cryptographically signed message in MIME format.

--------------ms090908050706050506080700
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

This patch adds vtpm support to libxl. It adds vtpm parsing to config
files and 3 new xl commands:
vtpm-attach
vtpm-detach
vtpm-list

Signed off by: Matthew Fioravante matthew.fioravante@jhuapl.edu

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -2027,6 +2027,274 @@ int libxl__device_disk_local_detach(libxl__gc
*gc, libxl_device_disk *disk)
 }
=20
 /***********************************************************************=
*******/
+int libxl__device_vtpm_setdefault(libxl__gc *gc, libxl_device_vtpm *vtpm=
)
+{
+   if(libxl_uuid_is_nil(&vtpm->uuid)) {
+      libxl_uuid_generate(&vtpm->uuid);
+   }
+   return 0;
+}
+
+static int libxl__device_from_vtpm(libxl__gc *gc, uint32_t domid,
+                                   libxl_device_vtpm *vtpm,
+                                   libxl__device *device)
+{
+   device->backend_devid   =3D vtpm->devid;
+   device->backend_domid   =3D vtpm->backend_domid;
+   device->backend_kind    =3D LIBXL__DEVICE_KIND_VTPM;
+   device->devid           =3D vtpm->devid;
+   device->domid           =3D domid;
+   device->kind            =3D LIBXL__DEVICE_KIND_VTPM;
+
+   return 0;
+}
+
+int libxl_device_vtpm_add(libxl_ctx *ctx, uint32_t domid,
libxl_device_vtpm *vtpm)
+{
+    GC_INIT(ctx);
+    flexarray_t *front;
+    flexarray_t *back;
+    libxl__device device;
+    char *dompath, **l;
+    unsigned int nb, rc;
+
+    rc =3D libxl__device_vtpm_setdefault(gc, vtpm);
+    if (rc) goto out;
+
+    front =3D flexarray_make(16, 1);
+    if (!front) {
+        rc =3D ERROR_NOMEM;
+        goto out;
+    }
+    back =3D flexarray_make(16, 1);
+    if (!back) {
+        rc =3D ERROR_NOMEM;
+        goto out;
+    }
+
+    if(vtpm->devid =3D=3D -1) {
+        if (!(dompath =3D libxl__xs_get_dompath(gc, domid))) {
+            rc =3D ERROR_FAIL;
+            goto out_free;
+        }
+        l =3D libxl__xs_directory(gc, XBT_NULL, libxl__sprintf(gc,
"%s/device/vtpm", dompath), &nb);
+        if(l =3D=3D NULL || nb =3D=3D 0) {
+            vtpm->devid =3D 0;
+        } else {
+            vtpm->devid =3D strtoul(l[nb - 1], NULL, 10) + 1;
+        }
+    }
+
+    rc =3D libxl__device_from_vtpm(gc, domid, vtpm, &device);
+    if ( rc !=3D 0 ) goto out_free;
+
+    flexarray_append(back, "frontend-id");
+    flexarray_append(back, libxl__sprintf(gc, "%d", domid));
+    flexarray_append(back, "online");
+    flexarray_append(back, "1");
+    flexarray_append(back, "state");
+    flexarray_append(back, libxl__sprintf(gc, "%d", 1));
+
+    flexarray_append(back, "uuid");
+    flexarray_append(back, libxl__sprintf(gc, LIBXL_UUID_FMT,
LIBXL_UUID_BYTES(vtpm->uuid)));
+    flexarray_append(back, "instance"); /* MAYBE CAN GET RID OF THIS */
+    flexarray_append(back, "0");
+    flexarray_append(back, "pref_instance"); /* MAYBE CAN GET RID OF
THIS */
+    flexarray_append(back, "0");
+    flexarray_append(back, "resume");
+    flexarray_append(back, "False");
+    flexarray_append(back, "ready"); /* MAYBE CAN GET RID OF THIS */
+    flexarray_append(back, "1");
+
+    flexarray_append(front, "backend-id");
+    flexarray_append(front, libxl__sprintf(gc, "%d", vtpm->backend_domid=
));
+    flexarray_append(front, "state");
+    flexarray_append(front, libxl__sprintf(gc, "%d", 1));
+    flexarray_append(front, "handle");
+    flexarray_append(front, libxl__sprintf(gc, "%d", vtpm->devid));
+
+    libxl__device_generic_add(gc, XBT_NULL, &device,
+                             libxl__xs_kvs_of_flexarray(gc, back,
back->count),
+                             libxl__xs_kvs_of_flexarray(gc, front,
front->count));
+
+    rc =3D 0;
+out_free:
+    flexarray_free(back);
+    flexarray_free(front);
+out:
+    GC_FREE;
+    return rc;
+}
+
+int libxl_device_vtpm_remove(libxl_ctx *ctx, uint32_t domid,
+                             libxl_device_vtpm *vtpm,
+                             const libxl_asyncop_how *ao_how)
+{
+    AO_CREATE(ctx, domid, ao_how);
+    libxl__device device;
+    int rc;
+
+    rc =3D libxl__device_from_vtpm(gc, domid, vtpm, &device);
+    if (rc !=3D 0) goto out;
+
+    rc =3D libxl__initiate_device_remove(egc, ao, &device);
+    if (rc) goto out;
+
+    return AO_INPROGRESS;
+
+out:
+    return AO_ABORT(rc);
+}
+
+int libxl_device_vtpm_destroy(libxl_ctx *ctx, uint32_t domid,
+                                   libxl_device_vtpm *vtpm)
+{
+   GC_INIT(ctx);
+   libxl__device device;
+   int rc;
+
+   rc =3D libxl__device_from_vtpm(gc, domid, vtpm, &device);
+   if (rc !=3D 0) goto out;
+
+   rc =3D libxl__device_destroy(gc, &device);
+out:
+   GC_FREE;
+   return rc;
+}
+
+static void libxl__device_vtpm_from_xs_fe(libxl__gc *gc,
+                                          const char* fe_path,
+                                          libxl_device_vtpm *vtpm)
+{
+   char* tmp;
+
+   memset(vtpm, 0, sizeof(*vtpm));
+   tmp =3D libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/handle",
fe_path));
+   if (tmp) {
+      vtpm->devid =3D atoi(tmp);
+   }
+   tmp =3D libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc,
"%s/backend-id", fe_path));
+   if(tmp) {
+      vtpm->backend_domid =3D atoi(tmp);
+   }
+   tmp =3D libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/uuid",
fe_path));
+   if(tmp) {
+      libxl_uuid_from_string(&(vtpm->uuid), tmp);
+   }
+}
+
+libxl_device_vtpm *libxl_device_vtpm_list(libxl_ctx *ctx, uint32_t
domid, int *num)
+{
+    GC_INIT(ctx);
+
+    libxl_device_vtpm* vtpms =3D NULL;
+    char* fe_path =3D NULL;
+    char** dir =3D NULL;
+    unsigned int ndirs =3D 0;
+
+    *num =3D 0;
+
+    fe_path =3D libxl__sprintf(gc, "%s/device/vtpm",
libxl__xs_get_dompath(gc, domid));
+    dir =3D libxl__xs_directory(gc, XBT_NULL, fe_path, &ndirs);
+    if(dir) {
+       vtpms =3D malloc(sizeof(*vtpms) * ndirs);
+       libxl_device_vtpm* vtpm;
+       libxl_device_vtpm* end =3D vtpms + ndirs;
+       for(vtpm =3D vtpms; vtpm < end; ++vtpm, ++dir) {
+          const char* path =3D libxl__sprintf(gc, "%s/%s", fe_path, *dir=
);
+          libxl__device_vtpm_from_xs_fe(gc, path, vtpm);
+       }
+    }
+    *num =3D ndirs;
+
+    GC_FREE;
+    return vtpms;
+}
+
+int libxl_device_vtpm_getinfo(libxl_ctx *ctx, uint32_t domid,
+                               libxl_device_vtpm *vtpm, libxl_vtpminfo
*vtpminfo)
+{
+    GC_INIT(ctx);
+    char *dompath, *vtpmpath;
+    char *val;
+    int rc =3D 0;
+  =20
+    libxl_vtpminfo_init(vtpminfo);
+    dompath =3D libxl__xs_get_dompath(gc, domid);
+    vtpminfo->devid =3D vtpm->devid;
+
+    vtpmpath =3D libxl__sprintf(gc, "%s/device/vtpm/%d", dompath,
vtpminfo->devid);
+    vtpminfo->backend =3D xs_read(ctx->xsh, XBT_NULL,
+                                libxl__sprintf(gc, "%s/backend",
vtpmpath), NULL);
+    if (!vtpminfo->backend) {
+        goto err;
+    }
+    if(!libxl__xs_read(gc, XBT_NULL, vtpminfo->backend)) {
+       goto err;
+    }
+
+    val =3D libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc,
"%s/backend-id", vtpmpath));
+    vtpminfo->backend_id =3D val ? strtoul(val, NULL, 10) : -1;
+    val =3D libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/state",
vtpmpath));
+    vtpminfo->state =3D val ? strtoul(val, NULL, 10) : -1;
+    val =3D libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc,
"%s/event-channel", vtpmpath));
+    vtpminfo->evtch =3D val ? strtoul(val, NULL, 10) : -1;
+    val =3D libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc,
"%s/ring-ref", vtpmpath));
+    vtpminfo->rref =3D val ? strtoul(val, NULL, 10) : -1;
+    vtpminfo->frontend =3D xs_read(ctx->xsh, XBT_NULL,
+                                 libxl__sprintf(gc, "%s/frontend",
vtpminfo->backend), NULL);
+    val =3D libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc,
"%s/frontend-id", vtpminfo->backend));
+    vtpminfo->frontend_id =3D val ? strtoul(val, NULL, 10) : -1;
+
+    val =3D libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/uuid",
vtpminfo->backend));
+    if(val =3D=3D NULL) {
+       LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "%s/uuid does not exist!\n",
vtpminfo->backend);
+       goto err;
+    }
+    if(libxl_uuid_from_string(&(vtpminfo->uuid), val)) {
+       LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "%s/uuid is a malformed uuid??
(%s) Probably a bug!\n", vtpminfo->backend, val);
+       goto err;
+    }
+
+    goto exit;
+err:
+    rc =3D ERROR_FAIL;
+exit:
+    GC_FREE;
+    return rc;
+}
+
+int libxl_devid_to_device_vtpm(libxl_ctx *ctx, uint32_t domid,
+                              int devid, libxl_device_vtpm *vtpm)
+{
+    libxl_device_vtpm *vtpms;
+    int nb, i;
+    int rc;
+
+    vtpms =3D libxl_device_vtpm_list(ctx, domid, &nb);
+    if (!vtpms)
+        return ERROR_FAIL;
+
+    memset(vtpm, 0, sizeof (libxl_device_vtpm));
+    rc =3D 1;
+    for (i =3D 0; i < nb; ++i) {
+        if(devid =3D=3D vtpms[i].devid) {
+            vtpm->backend_domid =3D vtpms[i].backend_domid;
+            vtpm->devid =3D vtpms[i].devid;
+            libxl_uuid_copy(&vtpm->uuid, &vtpms[i].uuid);
+            rc =3D 0;
+            break;
+        }
+    }
+
+    for (i=3D0; i<nb; i++)
+        libxl_device_vtpm_dispose(&vtpms[i]);
+    free(vtpms);
+    return rc;
+}
+
+
+/***********************************************************************=
*******/
=20
 int libxl__device_nic_setdefault(libxl__gc *gc, libxl_device_nic *nic)
 {
diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -477,13 +477,14 @@ typedef struct {
     libxl_domain_create_info c_info;
     libxl_domain_build_info b_info;
=20
-    int num_disks, num_vifs, num_pcidevs, num_vfbs, num_vkbs;
+    int num_disks, num_vifs, num_pcidevs, num_vfbs, num_vkbs, num_vtpms;=

=20
     libxl_device_disk *disks;
     libxl_device_nic *vifs;
     libxl_device_pci *pcidevs;
     libxl_device_vfb *vfbs;
     libxl_device_vkb *vkbs;
+    libxl_device_vtpm *vtpms;
=20
     libxl_action_on_shutdown on_poweroff;
     libxl_action_on_shutdown on_reboot;
@@ -679,6 +680,16 @@ 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,
                               libxl_device_nic *nic, libxl_nicinfo
*nicinfo);
=20
+/* Virtual TPMs */
+int libxl_device_vtpm_add(libxl_ctx *ctx, uint32_t domid,
libxl_device_vtpm *vtpm);
+int libxl_device_vtpm_remove(libxl_ctx *ctx, uint32_t domid,
+                            libxl_device_vtpm *vtpm,
+                            const libxl_asyncop_how *ao_how);
+int libxl_device_vtpm_destroy(libxl_ctx *ctx, uint32_t domid,
libxl_device_vtpm *vtpm);
+libxl_device_vtpm *libxl_device_vtpm_list(libxl_ctx *ctx, uint32_t
domid, int *num);
+int libxl_device_vtpm_getinfo(libxl_ctx *ctx, uint32_t domid,
+                               libxl_device_vtpm *vtpm, libxl_vtpminfo
*vtpminfo);
+
 /* Keyboard */
 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,
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
@@ -54,6 +54,10 @@ void libxl_domain_config_dispose(libxl_domain_config
*d_config)
         libxl_device_vkb_dispose(&d_config->vkbs[i]);
     free(d_config->vkbs);
=20
+    for (i=3D0; i<d_config->num_vtpms; i++)
+       libxl_device_vtpm_dispose(&d_config->vtpms[i]);
+    free(d_config->vtpms);
+
     libxl_domain_create_info_dispose(&d_config->c_info);
     libxl_domain_build_info_dispose(&d_config->b_info);
 }
@@ -732,6 +736,15 @@ static void domcreate_bootloader_done(libxl__egc *eg=
c,
             goto error_out;
         }
     }
+    for (i =3D 0; i < d_config->num_vtpms; i++) {
+       ret =3D libxl_device_vtpm_add(ctx, domid, &d_config->vtpms[i]);
+       if (ret) {
+          LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
+                      "cannot add vtpm %d to domain: %d", i, ret);
+          ret =3D ERROR_FAIL;
+          goto error_out;
+       }
+    }
     switch (d_config->c_info.type) {
     case LIBXL_DOMAIN_TYPE_HVM:
     {
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
@@ -811,6 +811,11 @@ retry_transaction:
         if (ret)
             goto out_free;
     }
+    for (i =3D 0; i < dm_config->num_vtpms; i++) {
+        ret =3D libxl_device_vtpm_add(ctx, dm_domid, &dm_config->vtpms[i=
]);
+        if (ret)
+            goto out_free;
+    }
     ret =3D libxl_device_vfb_add(ctx, dm_domid, &dm_config->vfbs[0]);
     if (ret)
         goto out_free;
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
@@ -844,6 +844,7 @@ _hidden int
libxl__domain_build_info_setdefault(libxl__gc *gc,
 _hidden int libxl__device_disk_setdefault(libxl__gc *gc,
                                           libxl_device_disk *disk);
 _hidden int libxl__device_nic_setdefault(libxl__gc *gc,
libxl_device_nic *nic);
+_hidden int libxl__device_vtpm_setdefault(libxl__gc *gc,
libxl_device_vtpm *vtpm);
 _hidden int libxl__device_vfb_setdefault(libxl__gc *gc,
libxl_device_vfb *vfb);
 _hidden int libxl__device_vkb_setdefault(libxl__gc *gc,
libxl_device_vkb *vkb);
 _hidden int libxl__device_pci_setdefault(libxl__gc *gc,
libxl_device_pci *pci);
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
@@ -370,6 +370,12 @@ libxl_device_pci =3D Struct("device_pci", [
     ("permissive", bool),
     ])
=20
+libxl_device_vtpm =3D Struct("device_vtpm", [
+    ("backend_domid",    libxl_domid),
+    ("devid",            libxl_devid),
+    ("uuid",             libxl_uuid),
+])
+
 libxl_diskinfo =3D Struct("diskinfo", [
     ("backend", string),
     ("backend_id", uint32),
@@ -393,6 +399,18 @@ libxl_nicinfo =3D Struct("nicinfo", [
     ("rref_rx", integer),
     ], dir=3DDIR_OUT)
=20
+libxl_vtpminfo =3D Struct("vtpminfo", [
+    ("backend", string),
+    ("backend_id", uint32),
+    ("frontend", string),
+    ("frontend_id", uint32),
+    ("devid", libxl_devid),
+    ("state", integer),
+    ("evtch", integer),
+    ("rref", integer),
+    ("uuid", libxl_uuid),
+    ], dir=3DDIR_OUT)
+
 libxl_vcpuinfo =3D Struct("vcpuinfo", [
     ("vcpuid", uint32),
     ("cpu", uint32),
diff --git a/tools/libxl/libxl_types_internal.idl
b/tools/libxl/libxl_types_internal.idl
--- a/tools/libxl/libxl_types_internal.idl
+++ b/tools/libxl/libxl_types_internal.idl
@@ -19,6 +19,7 @@ libxl__device_kind =3D Enumeration("device_kind", [
     (5, "VFB"),
     (6, "VKBD"),
     (7, "CONSOLE"),
+    (8, "VTPM"),
     ])
=20
 libxl__console_backend =3D Enumeration("console_backend", [
diff --git a/tools/libxl/libxl_utils.c b/tools/libxl/libxl_utils.c
--- a/tools/libxl/libxl_utils.c
+++ b/tools/libxl/libxl_utils.c
@@ -454,6 +454,35 @@ int libxl_pipe(libxl_ctx *ctx, int pipes[2])
     return 0;
 }
=20
+int libxl_uuid_to_device_vtpm(libxl_ctx *ctx, uint32_t domid,
+                            libxl_uuid* uuid, libxl_device_vtpm *vtpm)
+{
+    libxl_device_vtpm *vtpms;
+    int nb, i;
+    int rc;
+
+    vtpms =3D libxl_device_vtpm_list(ctx, domid, &nb);
+    if (!vtpms)
+        return ERROR_FAIL;
+
+    memset(vtpm, 0, sizeof (libxl_device_vtpm));
+    rc =3D 1;
+    for (i =3D 0; i < nb; ++i) {
+        if(!libxl_uuid_compare(uuid, &vtpms[i].uuid)) {
+            vtpm->backend_domid =3D vtpms[i].backend_domid;
+            vtpm->devid =3D vtpms[i].devid;
+            libxl_uuid_copy(&vtpm->uuid, &vtpms[i].uuid);
+            rc =3D 0;
+            break;
+        }
+    }
+
+    for (i=3D0; i<nb; i++)
+        libxl_device_vtpm_dispose(&vtpms[i]);
+    free(vtpms);
+    return rc;
+}
+
 int libxl_mac_to_device_nic(libxl_ctx *ctx, uint32_t domid,
                             const char *mac, libxl_device_nic *nic)
 {
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,6 +63,11 @@ int libxl_devid_to_device_nic(libxl_ctx *ctx,
uint32_t domid, int devid,
 int libxl_vdev_to_device_disk(libxl_ctx *ctx, uint32_t domid, const
char *vdev,
                                libxl_device_disk *disk);
=20
+int libxl_uuid_to_device_vtpm(libxl_ctx *ctx, uint32_t domid,
+                               libxl_uuid *uuid, libxl_device_vtpm *vtpm=
);
+int libxl_devid_to_device_vtpm(libxl_ctx *ctx, uint32_t domid,
+                               int devid, libxl_device_vtpm *vtpm);
+
 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);
diff --git a/tools/libxl/xl.h b/tools/libxl/xl.h
--- a/tools/libxl/xl.h
+++ b/tools/libxl/xl.h
@@ -79,6 +79,9 @@ int main_networkdetach(int argc, char **argv);
 int main_blockattach(int argc, char **argv);
 int main_blocklist(int argc, char **argv);
 int main_blockdetach(int argc, char **argv);
+int main_vtpmattach(int argc, char **argv);
+int main_vtpmlist(int argc, char **argv);
+int main_vtpmdetach(int argc, char **argv);
 int main_uptime(int argc, char **argv);
 int main_tmem_list(int argc, char **argv);
 int main_tmem_freeze(int argc, char **argv);
diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -560,7 +560,7 @@ static void parse_config_data(const char *config_sour=
ce,
     const char *buf;
     long l;
     XLU_Config *config;
-    XLU_ConfigList *cpus, *vbds, *nics, *pcis, *cvfbs, *cpuids;
+    XLU_ConfigList *cpus, *vbds, *nics, *pcis, *cvfbs, *cpuids, *vtpms;
     int pci_power_mgmt =3D 0;
     int pci_msitranslate =3D 1;
     int pci_permissive =3D 0;
@@ -911,6 +911,47 @@ static void parse_config_data(const char
*config_source,
         }
     }
=20
+    if (!xlu_cfg_get_list(config, "vtpm", &vtpms, 0, 0)) {
+        d_config->num_vtpms =3D 0;
+        d_config->vtpms =3D NULL;
+        while ((buf =3D xlu_cfg_get_listitem (vtpms,
d_config->num_vtpms)) !=3D NULL) {
+            libxl_device_vtpm *vtpm;
+            char * buf2 =3D strdup(buf);
+            char *p, *p2;
+
+            d_config->vtpms =3D (libxl_device_vtpm *)
realloc(d_config->vtpms, sizeof(libxl_device_vtpm) *
(d_config->num_vtpms+1));
+            vtpm =3D d_config->vtpms + d_config->num_vtpms;
+            libxl_device_vtpm_init(vtpm);
+            vtpm->devid =3D d_config->num_vtpms;
+
+            p =3D strtok(buf2, ",");
+            if (!p)
+                goto skip_vtpm;
+            do {
+                while(*p =3D=3D ' ')
+                    ++p;
+                if ((p2 =3D strchr(p, '=3D')) =3D=3D NULL)
+                    break;
+                *p2 =3D '\0';
+                if (!strcmp(p, "backend")) {
+                    if(domain_qualifier_to_domid(p2 + 1,
&(vtpm->backend_domid), 0))
+                    {
+                        fprintf(stderr, "Specified backend domain does
not exist, defaulting to Dom0\n");
+                        vtpm->backend_domid =3D 0;
+                    }
+                } else if(!strcmp(p, "uuid")) {
+                    if( libxl_uuid_from_string(&vtpm->uuid, p2 + 1) ) {
+                        fprintf(stderr, "Failed to parse vtpm UUID:
%s\n", p2 + 1);
+                        exit(1);
+                    }
+                }
+            } while ((p =3D strtok(NULL, ",")) !=3D NULL);
+skip_vtpm:
+            free(buf2);
+            d_config->num_vtpms++;
+        }
+    }
+
     if (!xlu_cfg_get_list (config, "vif", &nics, 0, 0)) {
         d_config->num_vifs =3D 0;
         d_config->vifs =3D NULL;
@@ -936,7 +977,7 @@ static void parse_config_data(const char *config_sour=
ce,
=20
             p =3D strtok(buf2, ",");
             if (!p)
-                goto skip;
+                goto skip_nic;
             do {
                 while (*p =3D=3D ' ')
                     p++;
@@ -993,7 +1034,7 @@ static void parse_config_data(const char
*config_source,
                     fprintf(stderr, "the accel parameter for vifs is
currently not supported\n");
                 }
             } while ((p =3D strtok(NULL, ",")) !=3D NULL);
-skip:
+skip_nic:
             free(buf2);
             d_config->num_vifs++;
         }
@@ -5361,6 +5402,136 @@ int main_blockdetach(int argc, char **argv)
     return 0;
 }
=20
+int main_vtpmattach(int argc, char **argv)
+{
+    int opt;
+    libxl_device_vtpm vtpm;
+    char *oparg;
+    unsigned int val;
+
+    if ((opt =3D def_getopt(argc, argv, "", "vtpm-attach", 1)) !=3D -1)
+        return opt;
+
+    if (argc-optind > 3) {
+        help("vtpm-attach");
+        return 0;
+    }
+
+    if (domain_qualifier_to_domid(argv[optind], &domid, 0) < 0) {
+        fprintf(stderr, "%s is an invalid domain identifier\n",
argv[optind]);
+        return 1;
+    }
+    libxl_device_vtpm_init(&vtpm);
+    for (argv +=3D optind+1, argc -=3D optind+1; argc > 0; ++argv, --arg=
c) {
+        if (MATCH_OPTION("uuid", *argv, oparg)) {
+            if(libxl_uuid_from_string(&(vtpm.uuid), oparg)) {
+                fprintf(stderr, "Invalid uuid specified (%s)\n", oparg);=

+                return 1;
+            }
+        } else if (MATCH_OPTION("backend", *argv, oparg)) {
+            if(domain_qualifier_to_domid(oparg, &val, 0)) {
+                fprintf(stderr, "Specified backend domain does not
exist, defaulting to Dom0\n");
+                val =3D 0;
+            }
+            vtpm.backend_domid =3D val;
+        } else {
+            fprintf(stderr, "unrecognized argument `%s'\n", *argv);
+            return 1;
+        }
+    }
+
+    if(dryrun_only) {
+       char* json =3D libxl_device_vtpm_to_json(ctx, &vtpm);
+       printf("vtpm: %s\n", json);
+       free(json);
+       libxl_device_vtpm_dispose(&vtpm);
+       if (ferror(stdout) || fflush(stdout)) { perror("stdout");
exit(-1); }
+       return 0;
+    }
+
+    if (libxl_device_vtpm_add(ctx, domid, &vtpm)) {
+        fprintf(stderr, "libxl_device_vtpm_add failed.\n");
+        return 1;
+    }
+    libxl_device_vtpm_dispose(&vtpm);
+    return 0;
+}
+
+int main_vtpmlist(int argc, char **argv)
+{
+    int opt;
+    libxl_device_vtpm *vtpms;
+    libxl_vtpminfo vtpminfo;
+    int nb, i;
+
+    if ((opt =3D def_getopt(argc, argv, "", "vtpm-list", 0)) !=3D -1)
+        return opt;
+
+    /*      Idx  BE   UUID   Hdl  Sta  evch rref  BE-path */
+    printf("%-3s %-2s %-36s %-6s %-5s %-6s %-5s %-30s\n",
+           "Idx", "BE", "Uuid", "handle", "state", "evt-ch",
"ring-ref", "BE-path");
+    for (argv +=3D optind, argc -=3D optind; argc > 0; --argc, ++argv) {=

+        if (domain_qualifier_to_domid(*argv, &domid, 0) < 0) {
+            fprintf(stderr, "%s is an invalid domain identifier\n", *arg=
v);
+            continue;
+        }
+        if (!(vtpms =3D libxl_device_vtpm_list(ctx, domid, &nb))) {
+            continue;
+        }
+        for (i =3D 0; i < nb; ++i) {
+           if(!libxl_device_vtpm_getinfo(ctx, domid, &vtpms[i],
&vtpminfo)) {
+              /* Idx BE */
+              printf("%-3d %-2d ", vtpminfo.devid, vtpminfo.backend_id);=

+              /* MAC */
+              printf(LIBXL_UUID_FMT, LIBXL_UUID_BYTES(vtpminfo.uuid));
+              /* Hdl  Sta  evch txr/rxr  BE-path */
+              printf(" %6d %5d %6d %8d %-30s\n",
+                    vtpminfo.devid, vtpminfo.state, vtpminfo.evtch,
+                    vtpminfo.rref, vtpminfo.backend);
+              libxl_vtpminfo_dispose(&vtpminfo);
+           }
+           libxl_device_vtpm_dispose(&vtpms[i]);
+        }
+        free(vtpms);
+    }
+    return 0;
+}
+
+int main_vtpmdetach(int argc, char **argv)
+{
+    int opt;
+    libxl_device_vtpm vtpm;
+    libxl_uuid uuid;
+
+    if ((opt =3D def_getopt(argc, argv, "", "vtpm-detach", 2)) !=3D -1)
+        return opt;
+
+    if (domain_qualifier_to_domid(argv[optind], &domid, 0) < 0) {
+        fprintf(stderr, "%s is an invalid domain identifier\n",
argv[optind]);
+        return 1;
+    }
+
+    if ( libxl_uuid_from_string(&uuid, argv[optind+1])) {
+        if (libxl_devid_to_device_vtpm(ctx, domid,
atoi(argv[optind+1]), &vtpm)) {
+            fprintf(stderr, "Unknown device %s.\n", argv[optind+1]);
+            return 1;
+        }
+    } else {
+        if (libxl_uuid_to_device_vtpm(ctx, domid, &uuid, &vtpm)) {
+            fprintf(stderr, "Unknown device %s.\n", argv[optind+1]);
+            return 1;
+        }
+    }
+    if (libxl_device_vtpm_remove(ctx, domid, &vtpm, 0)) {
+        fprintf(stderr, "libxl_device_vtpm_del failed.\n");
+        return 1;
+    }
+    libxl_device_vtpm_dispose(&vtpm);
+    return 0;
+}
+
+
+
 static char *uptime_to_string(unsigned long time, int short_mode)
 {
     int sec, min, hour, day;
diff --git a/tools/libxl/xl_cmdtable.c b/tools/libxl/xl_cmdtable.c
--- a/tools/libxl/xl_cmdtable.c
+++ b/tools/libxl/xl_cmdtable.c
@@ -338,6 +338,21 @@ struct cmd_spec cmd_table[] =3D {
       "Destroy a domain's virtual block device",
       "<Domain> <DevId>",
     },
+    { "vtpm-attach",
+      &main_vtpmattach, 0, 1,
+      "Create a new virtual TPM device",
+      "<Domain> [uuid=3D<uuid>] [backend=3D<BackDomain>]",
+    },
+    { "vtpm-list",
+      &main_vtpmlist, 0, 0,
+      "List virtual TPM devices for a domain",
+      "<Domain(s)>",
+    },
+    { "vtpm-detach",
+      &main_vtpmdetach, 0, 1,
+      "Destroy a domain's virtual TPM device",
+      "<Domain> <DevId|uuid>",
+    },
     { "uptime",
       &main_uptime, 0, 0,
       "Print uptime for all/some domains",
--=20
1.7.4.4



--------------ms090908050706050506080700
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIDyjCC
A8YwggMvoAMCAQICBD/xyf0wDQYJKoZIhvcNAQEFBQAwLzELMAkGA1UEBhMCVVMxDzANBgNV
BAoTBkpIVUFQTDEPMA0GA1UECxMGQklTRENBMB4XDTEwMDYxMTE4MjIwNloXDTEzMDYxMTE4
NTIwNlowZjELMAkGA1UEBhMCVVMxDzANBgNVBAoTBkpIVUFQTDEPMA0GA1UECxMGUGVvcGxl
MTUwFgYDVQQLEw9WUE5Hcm91cC1CSVNEQ0EwGwYDVQQDExRNYXR0aGV3IEUgRmlvcmF2YW50
ZTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAnpbwVSP6o1Nb5lcW7dd3yTo9iBJdi7qz
4nANOMFPK7JOy5npKN1iiousl28U/scUJES55gPwAWYJK3uVyQAsA4adgDKi5DoD1UHDQEwp
bY7iHLJeq0NPr4BqYNqnCFPbE6HC8zSJrr4qKn+gVUQT39SIFqdiIPJwZL8FYTRQ/zsCAwEA
AaOCAbYwggGyMAsGA1UdDwQEAwIHgDArBgNVHRAEJDAigA8yMDEwMDYxMTE4MjIwNlqBDzIw
MTIwNzE3MjI1MjA2WjAbBg0rBgEEAbMlCwMBAQEBBAoWCGZpb3JhbWUxMBsGDSsGAQQBsyUL
AwEBAQIEChIIMDAxMDQyNjEwWAYJYIZIAYb6ax4BBEsMSVRoZSBwcml2YXRlIGtleSBjb3Jy
ZXNwb25kaW5nIHRvIHRoaXMgY2VydGlmaWNhdGUgbWF5IGhhdmUgYmVlbiBleHBvcnRlZC4w
KAYDVR0RBCEwH4EdTWF0dGhldy5GaW9yYXZhbnRlQGpodWFwbC5lZHUwUgYDVR0fBEswSTBH
oEWgQ6RBMD8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJU0RD
QTEOMAwGA1UEAxMFQ1JMNTYwHwYDVR0jBBgwFoAUCDUpmxH52EU2CyWmF2EJMB1yqeswHQYD
VR0OBBYEFO6LYxg6r9wHZ+zdQtBHn1dZ/YTNMAkGA1UdEwQCMAAwGQYJKoZIhvZ9B0EABAww
ChsEVjcuMQMCBLAwDQYJKoZIhvcNAQEFBQADgYEAJO9HQh4YNChVLzuZqK5ARJARD8JoujGZ
fdo75quvg2jXFQe2sEjvLnxJZgm/pv8fdZakq48CWwjYHKuvIp7sDjTEsQfo+y7SpN/N2NvJ
WU5SqfK1VgYtNLRRoGJUB5Q1aZ+Dg95g3kqpyfpUMISJL8IKVLtJVfN4fggFVUYZ9wwxggGr
MIIBpwIBATA3MC8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJ
U0RDQQIEP/HJ/TAJBgUrDgMCGgUAoIHLMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ
KoZIhvcNAQkFMQ8XDTEyMDkxODE4MTE1M1owIwYJKoZIhvcNAQkEMRYEFGsxHA3TTz2TYdF5
5GXNJ3YoDxj4MGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAK
BggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI
KoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEgYBhrWRdmIJGMfKigv9KZPpvh0vxnlemkIGe
OT6wIWRo6HhWo6m1lTsvcux04iRknR3IEC/L1jQwRPyTerhge2cLVZ9WvwiMxScKukHsDqYz
CKm8E/Rs/L9af5WJSo7dI5RMCp292cSkguI8Vt9XCc7YirBdQJEsZpZsR2f1mVo+IAAAAAAA
AA==
--------------ms090908050706050506080700--


--===============5264763171101467337==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============5264763171101467337==--


From xen-devel-bounces@lists.xen.org Tue Sep 18 18:13:35 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Sep 2012 18:13:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TE2IR-000872-27; Tue, 18 Sep 2012 18:13:19 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <matthew.fioravante@jhuapl.edu>) id 1TE2IP-00086v-1f
	for xen-devel@lists.xensource.com; Tue, 18 Sep 2012 18:13:17 +0000
Received: from [85.158.137.99:25494] by server-5.bemta-3.messagelabs.com id
	15/61-13133-CB9B8505; Tue, 18 Sep 2012 18:13:16 +0000
X-Env-Sender: matthew.fioravante@jhuapl.edu
X-Msg-Ref: server-3.tower-217.messagelabs.com!1347991992!13133603!1
X-Originating-IP: [128.244.251.36]
X-SpamReason: No, hits=0.0 required=7.0 tests=UNPARSEABLE_RELAY
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6485 invoked from network); 18 Sep 2012 18:13:13 -0000
Received: from pilot.jhuapl.edu (HELO jhuapl.edu) (128.244.251.36)
	by server-3.tower-217.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 18 Sep 2012 18:13:13 -0000
Received: from ([128.244.207.89])
	by pilot.jhuapl.edu with ESMTP with TLS id 63GHCH1.153150672;
	Tue, 18 Sep 2012 14:13:09 -0400
Message-ID: <5058B969.4020503@jhuapl.edu>
Date: Tue, 18 Sep 2012 14:11:53 -0400
From: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120827 Thunderbird/15.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>, 
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
X-Enigmail-Version: 1.4.4
Subject: [Xen-devel] [PATCH xm/xl enhancements for vptm 2/6] add vtpm
	support to libxl
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============5264763171101467337=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a cryptographically signed message in MIME format.

--===============5264763171101467337==
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms090908050706050506080700"

This is a cryptographically signed message in MIME format.

--------------ms090908050706050506080700
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

This patch adds vtpm support to libxl. It adds vtpm parsing to config
files and 3 new xl commands:
vtpm-attach
vtpm-detach
vtpm-list

Signed off by: Matthew Fioravante matthew.fioravante@jhuapl.edu

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -2027,6 +2027,274 @@ int libxl__device_disk_local_detach(libxl__gc
*gc, libxl_device_disk *disk)
 }
=20
 /***********************************************************************=
*******/
+int libxl__device_vtpm_setdefault(libxl__gc *gc, libxl_device_vtpm *vtpm=
)
+{
+   if(libxl_uuid_is_nil(&vtpm->uuid)) {
+      libxl_uuid_generate(&vtpm->uuid);
+   }
+   return 0;
+}
+
+static int libxl__device_from_vtpm(libxl__gc *gc, uint32_t domid,
+                                   libxl_device_vtpm *vtpm,
+                                   libxl__device *device)
+{
+   device->backend_devid   =3D vtpm->devid;
+   device->backend_domid   =3D vtpm->backend_domid;
+   device->backend_kind    =3D LIBXL__DEVICE_KIND_VTPM;
+   device->devid           =3D vtpm->devid;
+   device->domid           =3D domid;
+   device->kind            =3D LIBXL__DEVICE_KIND_VTPM;
+
+   return 0;
+}
+
+int libxl_device_vtpm_add(libxl_ctx *ctx, uint32_t domid,
libxl_device_vtpm *vtpm)
+{
+    GC_INIT(ctx);
+    flexarray_t *front;
+    flexarray_t *back;
+    libxl__device device;
+    char *dompath, **l;
+    unsigned int nb, rc;
+
+    rc =3D libxl__device_vtpm_setdefault(gc, vtpm);
+    if (rc) goto out;
+
+    front =3D flexarray_make(16, 1);
+    if (!front) {
+        rc =3D ERROR_NOMEM;
+        goto out;
+    }
+    back =3D flexarray_make(16, 1);
+    if (!back) {
+        rc =3D ERROR_NOMEM;
+        goto out;
+    }
+
+    if(vtpm->devid =3D=3D -1) {
+        if (!(dompath =3D libxl__xs_get_dompath(gc, domid))) {
+            rc =3D ERROR_FAIL;
+            goto out_free;
+        }
+        l =3D libxl__xs_directory(gc, XBT_NULL, libxl__sprintf(gc,
"%s/device/vtpm", dompath), &nb);
+        if(l =3D=3D NULL || nb =3D=3D 0) {
+            vtpm->devid =3D 0;
+        } else {
+            vtpm->devid =3D strtoul(l[nb - 1], NULL, 10) + 1;
+        }
+    }
+
+    rc =3D libxl__device_from_vtpm(gc, domid, vtpm, &device);
+    if ( rc !=3D 0 ) goto out_free;
+
+    flexarray_append(back, "frontend-id");
+    flexarray_append(back, libxl__sprintf(gc, "%d", domid));
+    flexarray_append(back, "online");
+    flexarray_append(back, "1");
+    flexarray_append(back, "state");
+    flexarray_append(back, libxl__sprintf(gc, "%d", 1));
+
+    flexarray_append(back, "uuid");
+    flexarray_append(back, libxl__sprintf(gc, LIBXL_UUID_FMT,
LIBXL_UUID_BYTES(vtpm->uuid)));
+    flexarray_append(back, "instance"); /* MAYBE CAN GET RID OF THIS */
+    flexarray_append(back, "0");
+    flexarray_append(back, "pref_instance"); /* MAYBE CAN GET RID OF
THIS */
+    flexarray_append(back, "0");
+    flexarray_append(back, "resume");
+    flexarray_append(back, "False");
+    flexarray_append(back, "ready"); /* MAYBE CAN GET RID OF THIS */
+    flexarray_append(back, "1");
+
+    flexarray_append(front, "backend-id");
+    flexarray_append(front, libxl__sprintf(gc, "%d", vtpm->backend_domid=
));
+    flexarray_append(front, "state");
+    flexarray_append(front, libxl__sprintf(gc, "%d", 1));
+    flexarray_append(front, "handle");
+    flexarray_append(front, libxl__sprintf(gc, "%d", vtpm->devid));
+
+    libxl__device_generic_add(gc, XBT_NULL, &device,
+                             libxl__xs_kvs_of_flexarray(gc, back,
back->count),
+                             libxl__xs_kvs_of_flexarray(gc, front,
front->count));
+
+    rc =3D 0;
+out_free:
+    flexarray_free(back);
+    flexarray_free(front);
+out:
+    GC_FREE;
+    return rc;
+}
+
+int libxl_device_vtpm_remove(libxl_ctx *ctx, uint32_t domid,
+                             libxl_device_vtpm *vtpm,
+                             const libxl_asyncop_how *ao_how)
+{
+    AO_CREATE(ctx, domid, ao_how);
+    libxl__device device;
+    int rc;
+
+    rc =3D libxl__device_from_vtpm(gc, domid, vtpm, &device);
+    if (rc !=3D 0) goto out;
+
+    rc =3D libxl__initiate_device_remove(egc, ao, &device);
+    if (rc) goto out;
+
+    return AO_INPROGRESS;
+
+out:
+    return AO_ABORT(rc);
+}
+
+int libxl_device_vtpm_destroy(libxl_ctx *ctx, uint32_t domid,
+                                   libxl_device_vtpm *vtpm)
+{
+   GC_INIT(ctx);
+   libxl__device device;
+   int rc;
+
+   rc =3D libxl__device_from_vtpm(gc, domid, vtpm, &device);
+   if (rc !=3D 0) goto out;
+
+   rc =3D libxl__device_destroy(gc, &device);
+out:
+   GC_FREE;
+   return rc;
+}
+
+static void libxl__device_vtpm_from_xs_fe(libxl__gc *gc,
+                                          const char* fe_path,
+                                          libxl_device_vtpm *vtpm)
+{
+   char* tmp;
+
+   memset(vtpm, 0, sizeof(*vtpm));
+   tmp =3D libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/handle",
fe_path));
+   if (tmp) {
+      vtpm->devid =3D atoi(tmp);
+   }
+   tmp =3D libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc,
"%s/backend-id", fe_path));
+   if(tmp) {
+      vtpm->backend_domid =3D atoi(tmp);
+   }
+   tmp =3D libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/uuid",
fe_path));
+   if(tmp) {
+      libxl_uuid_from_string(&(vtpm->uuid), tmp);
+   }
+}
+
+libxl_device_vtpm *libxl_device_vtpm_list(libxl_ctx *ctx, uint32_t
domid, int *num)
+{
+    GC_INIT(ctx);
+
+    libxl_device_vtpm* vtpms =3D NULL;
+    char* fe_path =3D NULL;
+    char** dir =3D NULL;
+    unsigned int ndirs =3D 0;
+
+    *num =3D 0;
+
+    fe_path =3D libxl__sprintf(gc, "%s/device/vtpm",
libxl__xs_get_dompath(gc, domid));
+    dir =3D libxl__xs_directory(gc, XBT_NULL, fe_path, &ndirs);
+    if(dir) {
+       vtpms =3D malloc(sizeof(*vtpms) * ndirs);
+       libxl_device_vtpm* vtpm;
+       libxl_device_vtpm* end =3D vtpms + ndirs;
+       for(vtpm =3D vtpms; vtpm < end; ++vtpm, ++dir) {
+          const char* path =3D libxl__sprintf(gc, "%s/%s", fe_path, *dir=
);
+          libxl__device_vtpm_from_xs_fe(gc, path, vtpm);
+       }
+    }
+    *num =3D ndirs;
+
+    GC_FREE;
+    return vtpms;
+}
+
+int libxl_device_vtpm_getinfo(libxl_ctx *ctx, uint32_t domid,
+                               libxl_device_vtpm *vtpm, libxl_vtpminfo
*vtpminfo)
+{
+    GC_INIT(ctx);
+    char *dompath, *vtpmpath;
+    char *val;
+    int rc =3D 0;
+  =20
+    libxl_vtpminfo_init(vtpminfo);
+    dompath =3D libxl__xs_get_dompath(gc, domid);
+    vtpminfo->devid =3D vtpm->devid;
+
+    vtpmpath =3D libxl__sprintf(gc, "%s/device/vtpm/%d", dompath,
vtpminfo->devid);
+    vtpminfo->backend =3D xs_read(ctx->xsh, XBT_NULL,
+                                libxl__sprintf(gc, "%s/backend",
vtpmpath), NULL);
+    if (!vtpminfo->backend) {
+        goto err;
+    }
+    if(!libxl__xs_read(gc, XBT_NULL, vtpminfo->backend)) {
+       goto err;
+    }
+
+    val =3D libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc,
"%s/backend-id", vtpmpath));
+    vtpminfo->backend_id =3D val ? strtoul(val, NULL, 10) : -1;
+    val =3D libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/state",
vtpmpath));
+    vtpminfo->state =3D val ? strtoul(val, NULL, 10) : -1;
+    val =3D libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc,
"%s/event-channel", vtpmpath));
+    vtpminfo->evtch =3D val ? strtoul(val, NULL, 10) : -1;
+    val =3D libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc,
"%s/ring-ref", vtpmpath));
+    vtpminfo->rref =3D val ? strtoul(val, NULL, 10) : -1;
+    vtpminfo->frontend =3D xs_read(ctx->xsh, XBT_NULL,
+                                 libxl__sprintf(gc, "%s/frontend",
vtpminfo->backend), NULL);
+    val =3D libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc,
"%s/frontend-id", vtpminfo->backend));
+    vtpminfo->frontend_id =3D val ? strtoul(val, NULL, 10) : -1;
+
+    val =3D libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/uuid",
vtpminfo->backend));
+    if(val =3D=3D NULL) {
+       LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "%s/uuid does not exist!\n",
vtpminfo->backend);
+       goto err;
+    }
+    if(libxl_uuid_from_string(&(vtpminfo->uuid), val)) {
+       LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "%s/uuid is a malformed uuid??
(%s) Probably a bug!\n", vtpminfo->backend, val);
+       goto err;
+    }
+
+    goto exit;
+err:
+    rc =3D ERROR_FAIL;
+exit:
+    GC_FREE;
+    return rc;
+}
+
+int libxl_devid_to_device_vtpm(libxl_ctx *ctx, uint32_t domid,
+                              int devid, libxl_device_vtpm *vtpm)
+{
+    libxl_device_vtpm *vtpms;
+    int nb, i;
+    int rc;
+
+    vtpms =3D libxl_device_vtpm_list(ctx, domid, &nb);
+    if (!vtpms)
+        return ERROR_FAIL;
+
+    memset(vtpm, 0, sizeof (libxl_device_vtpm));
+    rc =3D 1;
+    for (i =3D 0; i < nb; ++i) {
+        if(devid =3D=3D vtpms[i].devid) {
+            vtpm->backend_domid =3D vtpms[i].backend_domid;
+            vtpm->devid =3D vtpms[i].devid;
+            libxl_uuid_copy(&vtpm->uuid, &vtpms[i].uuid);
+            rc =3D 0;
+            break;
+        }
+    }
+
+    for (i=3D0; i<nb; i++)
+        libxl_device_vtpm_dispose(&vtpms[i]);
+    free(vtpms);
+    return rc;
+}
+
+
+/***********************************************************************=
*******/
=20
 int libxl__device_nic_setdefault(libxl__gc *gc, libxl_device_nic *nic)
 {
diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -477,13 +477,14 @@ typedef struct {
     libxl_domain_create_info c_info;
     libxl_domain_build_info b_info;
=20
-    int num_disks, num_vifs, num_pcidevs, num_vfbs, num_vkbs;
+    int num_disks, num_vifs, num_pcidevs, num_vfbs, num_vkbs, num_vtpms;=

=20
     libxl_device_disk *disks;
     libxl_device_nic *vifs;
     libxl_device_pci *pcidevs;
     libxl_device_vfb *vfbs;
     libxl_device_vkb *vkbs;
+    libxl_device_vtpm *vtpms;
=20
     libxl_action_on_shutdown on_poweroff;
     libxl_action_on_shutdown on_reboot;
@@ -679,6 +680,16 @@ 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,
                               libxl_device_nic *nic, libxl_nicinfo
*nicinfo);
=20
+/* Virtual TPMs */
+int libxl_device_vtpm_add(libxl_ctx *ctx, uint32_t domid,
libxl_device_vtpm *vtpm);
+int libxl_device_vtpm_remove(libxl_ctx *ctx, uint32_t domid,
+                            libxl_device_vtpm *vtpm,
+                            const libxl_asyncop_how *ao_how);
+int libxl_device_vtpm_destroy(libxl_ctx *ctx, uint32_t domid,
libxl_device_vtpm *vtpm);
+libxl_device_vtpm *libxl_device_vtpm_list(libxl_ctx *ctx, uint32_t
domid, int *num);
+int libxl_device_vtpm_getinfo(libxl_ctx *ctx, uint32_t domid,
+                               libxl_device_vtpm *vtpm, libxl_vtpminfo
*vtpminfo);
+
 /* Keyboard */
 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,
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
@@ -54,6 +54,10 @@ void libxl_domain_config_dispose(libxl_domain_config
*d_config)
         libxl_device_vkb_dispose(&d_config->vkbs[i]);
     free(d_config->vkbs);
=20
+    for (i=3D0; i<d_config->num_vtpms; i++)
+       libxl_device_vtpm_dispose(&d_config->vtpms[i]);
+    free(d_config->vtpms);
+
     libxl_domain_create_info_dispose(&d_config->c_info);
     libxl_domain_build_info_dispose(&d_config->b_info);
 }
@@ -732,6 +736,15 @@ static void domcreate_bootloader_done(libxl__egc *eg=
c,
             goto error_out;
         }
     }
+    for (i =3D 0; i < d_config->num_vtpms; i++) {
+       ret =3D libxl_device_vtpm_add(ctx, domid, &d_config->vtpms[i]);
+       if (ret) {
+          LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
+                      "cannot add vtpm %d to domain: %d", i, ret);
+          ret =3D ERROR_FAIL;
+          goto error_out;
+       }
+    }
     switch (d_config->c_info.type) {
     case LIBXL_DOMAIN_TYPE_HVM:
     {
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
@@ -811,6 +811,11 @@ retry_transaction:
         if (ret)
             goto out_free;
     }
+    for (i =3D 0; i < dm_config->num_vtpms; i++) {
+        ret =3D libxl_device_vtpm_add(ctx, dm_domid, &dm_config->vtpms[i=
]);
+        if (ret)
+            goto out_free;
+    }
     ret =3D libxl_device_vfb_add(ctx, dm_domid, &dm_config->vfbs[0]);
     if (ret)
         goto out_free;
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
@@ -844,6 +844,7 @@ _hidden int
libxl__domain_build_info_setdefault(libxl__gc *gc,
 _hidden int libxl__device_disk_setdefault(libxl__gc *gc,
                                           libxl_device_disk *disk);
 _hidden int libxl__device_nic_setdefault(libxl__gc *gc,
libxl_device_nic *nic);
+_hidden int libxl__device_vtpm_setdefault(libxl__gc *gc,
libxl_device_vtpm *vtpm);
 _hidden int libxl__device_vfb_setdefault(libxl__gc *gc,
libxl_device_vfb *vfb);
 _hidden int libxl__device_vkb_setdefault(libxl__gc *gc,
libxl_device_vkb *vkb);
 _hidden int libxl__device_pci_setdefault(libxl__gc *gc,
libxl_device_pci *pci);
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
@@ -370,6 +370,12 @@ libxl_device_pci =3D Struct("device_pci", [
     ("permissive", bool),
     ])
=20
+libxl_device_vtpm =3D Struct("device_vtpm", [
+    ("backend_domid",    libxl_domid),
+    ("devid",            libxl_devid),
+    ("uuid",             libxl_uuid),
+])
+
 libxl_diskinfo =3D Struct("diskinfo", [
     ("backend", string),
     ("backend_id", uint32),
@@ -393,6 +399,18 @@ libxl_nicinfo =3D Struct("nicinfo", [
     ("rref_rx", integer),
     ], dir=3DDIR_OUT)
=20
+libxl_vtpminfo =3D Struct("vtpminfo", [
+    ("backend", string),
+    ("backend_id", uint32),
+    ("frontend", string),
+    ("frontend_id", uint32),
+    ("devid", libxl_devid),
+    ("state", integer),
+    ("evtch", integer),
+    ("rref", integer),
+    ("uuid", libxl_uuid),
+    ], dir=3DDIR_OUT)
+
 libxl_vcpuinfo =3D Struct("vcpuinfo", [
     ("vcpuid", uint32),
     ("cpu", uint32),
diff --git a/tools/libxl/libxl_types_internal.idl
b/tools/libxl/libxl_types_internal.idl
--- a/tools/libxl/libxl_types_internal.idl
+++ b/tools/libxl/libxl_types_internal.idl
@@ -19,6 +19,7 @@ libxl__device_kind =3D Enumeration("device_kind", [
     (5, "VFB"),
     (6, "VKBD"),
     (7, "CONSOLE"),
+    (8, "VTPM"),
     ])
=20
 libxl__console_backend =3D Enumeration("console_backend", [
diff --git a/tools/libxl/libxl_utils.c b/tools/libxl/libxl_utils.c
--- a/tools/libxl/libxl_utils.c
+++ b/tools/libxl/libxl_utils.c
@@ -454,6 +454,35 @@ int libxl_pipe(libxl_ctx *ctx, int pipes[2])
     return 0;
 }
=20
+int libxl_uuid_to_device_vtpm(libxl_ctx *ctx, uint32_t domid,
+                            libxl_uuid* uuid, libxl_device_vtpm *vtpm)
+{
+    libxl_device_vtpm *vtpms;
+    int nb, i;
+    int rc;
+
+    vtpms =3D libxl_device_vtpm_list(ctx, domid, &nb);
+    if (!vtpms)
+        return ERROR_FAIL;
+
+    memset(vtpm, 0, sizeof (libxl_device_vtpm));
+    rc =3D 1;
+    for (i =3D 0; i < nb; ++i) {
+        if(!libxl_uuid_compare(uuid, &vtpms[i].uuid)) {
+            vtpm->backend_domid =3D vtpms[i].backend_domid;
+            vtpm->devid =3D vtpms[i].devid;
+            libxl_uuid_copy(&vtpm->uuid, &vtpms[i].uuid);
+            rc =3D 0;
+            break;
+        }
+    }
+
+    for (i=3D0; i<nb; i++)
+        libxl_device_vtpm_dispose(&vtpms[i]);
+    free(vtpms);
+    return rc;
+}
+
 int libxl_mac_to_device_nic(libxl_ctx *ctx, uint32_t domid,
                             const char *mac, libxl_device_nic *nic)
 {
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,6 +63,11 @@ int libxl_devid_to_device_nic(libxl_ctx *ctx,
uint32_t domid, int devid,
 int libxl_vdev_to_device_disk(libxl_ctx *ctx, uint32_t domid, const
char *vdev,
                                libxl_device_disk *disk);
=20
+int libxl_uuid_to_device_vtpm(libxl_ctx *ctx, uint32_t domid,
+                               libxl_uuid *uuid, libxl_device_vtpm *vtpm=
);
+int libxl_devid_to_device_vtpm(libxl_ctx *ctx, uint32_t domid,
+                               int devid, libxl_device_vtpm *vtpm);
+
 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);
diff --git a/tools/libxl/xl.h b/tools/libxl/xl.h
--- a/tools/libxl/xl.h
+++ b/tools/libxl/xl.h
@@ -79,6 +79,9 @@ int main_networkdetach(int argc, char **argv);
 int main_blockattach(int argc, char **argv);
 int main_blocklist(int argc, char **argv);
 int main_blockdetach(int argc, char **argv);
+int main_vtpmattach(int argc, char **argv);
+int main_vtpmlist(int argc, char **argv);
+int main_vtpmdetach(int argc, char **argv);
 int main_uptime(int argc, char **argv);
 int main_tmem_list(int argc, char **argv);
 int main_tmem_freeze(int argc, char **argv);
diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -560,7 +560,7 @@ static void parse_config_data(const char *config_sour=
ce,
     const char *buf;
     long l;
     XLU_Config *config;
-    XLU_ConfigList *cpus, *vbds, *nics, *pcis, *cvfbs, *cpuids;
+    XLU_ConfigList *cpus, *vbds, *nics, *pcis, *cvfbs, *cpuids, *vtpms;
     int pci_power_mgmt =3D 0;
     int pci_msitranslate =3D 1;
     int pci_permissive =3D 0;
@@ -911,6 +911,47 @@ static void parse_config_data(const char
*config_source,
         }
     }
=20
+    if (!xlu_cfg_get_list(config, "vtpm", &vtpms, 0, 0)) {
+        d_config->num_vtpms =3D 0;
+        d_config->vtpms =3D NULL;
+        while ((buf =3D xlu_cfg_get_listitem (vtpms,
d_config->num_vtpms)) !=3D NULL) {
+            libxl_device_vtpm *vtpm;
+            char * buf2 =3D strdup(buf);
+            char *p, *p2;
+
+            d_config->vtpms =3D (libxl_device_vtpm *)
realloc(d_config->vtpms, sizeof(libxl_device_vtpm) *
(d_config->num_vtpms+1));
+            vtpm =3D d_config->vtpms + d_config->num_vtpms;
+            libxl_device_vtpm_init(vtpm);
+            vtpm->devid =3D d_config->num_vtpms;
+
+            p =3D strtok(buf2, ",");
+            if (!p)
+                goto skip_vtpm;
+            do {
+                while(*p =3D=3D ' ')
+                    ++p;
+                if ((p2 =3D strchr(p, '=3D')) =3D=3D NULL)
+                    break;
+                *p2 =3D '\0';
+                if (!strcmp(p, "backend")) {
+                    if(domain_qualifier_to_domid(p2 + 1,
&(vtpm->backend_domid), 0))
+                    {
+                        fprintf(stderr, "Specified backend domain does
not exist, defaulting to Dom0\n");
+                        vtpm->backend_domid =3D 0;
+                    }
+                } else if(!strcmp(p, "uuid")) {
+                    if( libxl_uuid_from_string(&vtpm->uuid, p2 + 1) ) {
+                        fprintf(stderr, "Failed to parse vtpm UUID:
%s\n", p2 + 1);
+                        exit(1);
+                    }
+                }
+            } while ((p =3D strtok(NULL, ",")) !=3D NULL);
+skip_vtpm:
+            free(buf2);
+            d_config->num_vtpms++;
+        }
+    }
+
     if (!xlu_cfg_get_list (config, "vif", &nics, 0, 0)) {
         d_config->num_vifs =3D 0;
         d_config->vifs =3D NULL;
@@ -936,7 +977,7 @@ static void parse_config_data(const char *config_sour=
ce,
=20
             p =3D strtok(buf2, ",");
             if (!p)
-                goto skip;
+                goto skip_nic;
             do {
                 while (*p =3D=3D ' ')
                     p++;
@@ -993,7 +1034,7 @@ static void parse_config_data(const char
*config_source,
                     fprintf(stderr, "the accel parameter for vifs is
currently not supported\n");
                 }
             } while ((p =3D strtok(NULL, ",")) !=3D NULL);
-skip:
+skip_nic:
             free(buf2);
             d_config->num_vifs++;
         }
@@ -5361,6 +5402,136 @@ int main_blockdetach(int argc, char **argv)
     return 0;
 }
=20
+int main_vtpmattach(int argc, char **argv)
+{
+    int opt;
+    libxl_device_vtpm vtpm;
+    char *oparg;
+    unsigned int val;
+
+    if ((opt =3D def_getopt(argc, argv, "", "vtpm-attach", 1)) !=3D -1)
+        return opt;
+
+    if (argc-optind > 3) {
+        help("vtpm-attach");
+        return 0;
+    }
+
+    if (domain_qualifier_to_domid(argv[optind], &domid, 0) < 0) {
+        fprintf(stderr, "%s is an invalid domain identifier\n",
argv[optind]);
+        return 1;
+    }
+    libxl_device_vtpm_init(&vtpm);
+    for (argv +=3D optind+1, argc -=3D optind+1; argc > 0; ++argv, --arg=
c) {
+        if (MATCH_OPTION("uuid", *argv, oparg)) {
+            if(libxl_uuid_from_string(&(vtpm.uuid), oparg)) {
+                fprintf(stderr, "Invalid uuid specified (%s)\n", oparg);=

+                return 1;
+            }
+        } else if (MATCH_OPTION("backend", *argv, oparg)) {
+            if(domain_qualifier_to_domid(oparg, &val, 0)) {
+                fprintf(stderr, "Specified backend domain does not
exist, defaulting to Dom0\n");
+                val =3D 0;
+            }
+            vtpm.backend_domid =3D val;
+        } else {
+            fprintf(stderr, "unrecognized argument `%s'\n", *argv);
+            return 1;
+        }
+    }
+
+    if(dryrun_only) {
+       char* json =3D libxl_device_vtpm_to_json(ctx, &vtpm);
+       printf("vtpm: %s\n", json);
+       free(json);
+       libxl_device_vtpm_dispose(&vtpm);
+       if (ferror(stdout) || fflush(stdout)) { perror("stdout");
exit(-1); }
+       return 0;
+    }
+
+    if (libxl_device_vtpm_add(ctx, domid, &vtpm)) {
+        fprintf(stderr, "libxl_device_vtpm_add failed.\n");
+        return 1;
+    }
+    libxl_device_vtpm_dispose(&vtpm);
+    return 0;
+}
+
+int main_vtpmlist(int argc, char **argv)
+{
+    int opt;
+    libxl_device_vtpm *vtpms;
+    libxl_vtpminfo vtpminfo;
+    int nb, i;
+
+    if ((opt =3D def_getopt(argc, argv, "", "vtpm-list", 0)) !=3D -1)
+        return opt;
+
+    /*      Idx  BE   UUID   Hdl  Sta  evch rref  BE-path */
+    printf("%-3s %-2s %-36s %-6s %-5s %-6s %-5s %-30s\n",
+           "Idx", "BE", "Uuid", "handle", "state", "evt-ch",
"ring-ref", "BE-path");
+    for (argv +=3D optind, argc -=3D optind; argc > 0; --argc, ++argv) {=

+        if (domain_qualifier_to_domid(*argv, &domid, 0) < 0) {
+            fprintf(stderr, "%s is an invalid domain identifier\n", *arg=
v);
+            continue;
+        }
+        if (!(vtpms =3D libxl_device_vtpm_list(ctx, domid, &nb))) {
+            continue;
+        }
+        for (i =3D 0; i < nb; ++i) {
+           if(!libxl_device_vtpm_getinfo(ctx, domid, &vtpms[i],
&vtpminfo)) {
+              /* Idx BE */
+              printf("%-3d %-2d ", vtpminfo.devid, vtpminfo.backend_id);=

+              /* MAC */
+              printf(LIBXL_UUID_FMT, LIBXL_UUID_BYTES(vtpminfo.uuid));
+              /* Hdl  Sta  evch txr/rxr  BE-path */
+              printf(" %6d %5d %6d %8d %-30s\n",
+                    vtpminfo.devid, vtpminfo.state, vtpminfo.evtch,
+                    vtpminfo.rref, vtpminfo.backend);
+              libxl_vtpminfo_dispose(&vtpminfo);
+           }
+           libxl_device_vtpm_dispose(&vtpms[i]);
+        }
+        free(vtpms);
+    }
+    return 0;
+}
+
+int main_vtpmdetach(int argc, char **argv)
+{
+    int opt;
+    libxl_device_vtpm vtpm;
+    libxl_uuid uuid;
+
+    if ((opt =3D def_getopt(argc, argv, "", "vtpm-detach", 2)) !=3D -1)
+        return opt;
+
+    if (domain_qualifier_to_domid(argv[optind], &domid, 0) < 0) {
+        fprintf(stderr, "%s is an invalid domain identifier\n",
argv[optind]);
+        return 1;
+    }
+
+    if ( libxl_uuid_from_string(&uuid, argv[optind+1])) {
+        if (libxl_devid_to_device_vtpm(ctx, domid,
atoi(argv[optind+1]), &vtpm)) {
+            fprintf(stderr, "Unknown device %s.\n", argv[optind+1]);
+            return 1;
+        }
+    } else {
+        if (libxl_uuid_to_device_vtpm(ctx, domid, &uuid, &vtpm)) {
+            fprintf(stderr, "Unknown device %s.\n", argv[optind+1]);
+            return 1;
+        }
+    }
+    if (libxl_device_vtpm_remove(ctx, domid, &vtpm, 0)) {
+        fprintf(stderr, "libxl_device_vtpm_del failed.\n");
+        return 1;
+    }
+    libxl_device_vtpm_dispose(&vtpm);
+    return 0;
+}
+
+
+
 static char *uptime_to_string(unsigned long time, int short_mode)
 {
     int sec, min, hour, day;
diff --git a/tools/libxl/xl_cmdtable.c b/tools/libxl/xl_cmdtable.c
--- a/tools/libxl/xl_cmdtable.c
+++ b/tools/libxl/xl_cmdtable.c
@@ -338,6 +338,21 @@ struct cmd_spec cmd_table[] =3D {
       "Destroy a domain's virtual block device",
       "<Domain> <DevId>",
     },
+    { "vtpm-attach",
+      &main_vtpmattach, 0, 1,
+      "Create a new virtual TPM device",
+      "<Domain> [uuid=3D<uuid>] [backend=3D<BackDomain>]",
+    },
+    { "vtpm-list",
+      &main_vtpmlist, 0, 0,
+      "List virtual TPM devices for a domain",
+      "<Domain(s)>",
+    },
+    { "vtpm-detach",
+      &main_vtpmdetach, 0, 1,
+      "Destroy a domain's virtual TPM device",
+      "<Domain> <DevId|uuid>",
+    },
     { "uptime",
       &main_uptime, 0, 0,
       "Print uptime for all/some domains",
--=20
1.7.4.4



--------------ms090908050706050506080700
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIDyjCC
A8YwggMvoAMCAQICBD/xyf0wDQYJKoZIhvcNAQEFBQAwLzELMAkGA1UEBhMCVVMxDzANBgNV
BAoTBkpIVUFQTDEPMA0GA1UECxMGQklTRENBMB4XDTEwMDYxMTE4MjIwNloXDTEzMDYxMTE4
NTIwNlowZjELMAkGA1UEBhMCVVMxDzANBgNVBAoTBkpIVUFQTDEPMA0GA1UECxMGUGVvcGxl
MTUwFgYDVQQLEw9WUE5Hcm91cC1CSVNEQ0EwGwYDVQQDExRNYXR0aGV3IEUgRmlvcmF2YW50
ZTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAnpbwVSP6o1Nb5lcW7dd3yTo9iBJdi7qz
4nANOMFPK7JOy5npKN1iiousl28U/scUJES55gPwAWYJK3uVyQAsA4adgDKi5DoD1UHDQEwp
bY7iHLJeq0NPr4BqYNqnCFPbE6HC8zSJrr4qKn+gVUQT39SIFqdiIPJwZL8FYTRQ/zsCAwEA
AaOCAbYwggGyMAsGA1UdDwQEAwIHgDArBgNVHRAEJDAigA8yMDEwMDYxMTE4MjIwNlqBDzIw
MTIwNzE3MjI1MjA2WjAbBg0rBgEEAbMlCwMBAQEBBAoWCGZpb3JhbWUxMBsGDSsGAQQBsyUL
AwEBAQIEChIIMDAxMDQyNjEwWAYJYIZIAYb6ax4BBEsMSVRoZSBwcml2YXRlIGtleSBjb3Jy
ZXNwb25kaW5nIHRvIHRoaXMgY2VydGlmaWNhdGUgbWF5IGhhdmUgYmVlbiBleHBvcnRlZC4w
KAYDVR0RBCEwH4EdTWF0dGhldy5GaW9yYXZhbnRlQGpodWFwbC5lZHUwUgYDVR0fBEswSTBH
oEWgQ6RBMD8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJU0RD
QTEOMAwGA1UEAxMFQ1JMNTYwHwYDVR0jBBgwFoAUCDUpmxH52EU2CyWmF2EJMB1yqeswHQYD
VR0OBBYEFO6LYxg6r9wHZ+zdQtBHn1dZ/YTNMAkGA1UdEwQCMAAwGQYJKoZIhvZ9B0EABAww
ChsEVjcuMQMCBLAwDQYJKoZIhvcNAQEFBQADgYEAJO9HQh4YNChVLzuZqK5ARJARD8JoujGZ
fdo75quvg2jXFQe2sEjvLnxJZgm/pv8fdZakq48CWwjYHKuvIp7sDjTEsQfo+y7SpN/N2NvJ
WU5SqfK1VgYtNLRRoGJUB5Q1aZ+Dg95g3kqpyfpUMISJL8IKVLtJVfN4fggFVUYZ9wwxggGr
MIIBpwIBATA3MC8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJ
U0RDQQIEP/HJ/TAJBgUrDgMCGgUAoIHLMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ
KoZIhvcNAQkFMQ8XDTEyMDkxODE4MTE1M1owIwYJKoZIhvcNAQkEMRYEFGsxHA3TTz2TYdF5
5GXNJ3YoDxj4MGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAK
BggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI
KoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEgYBhrWRdmIJGMfKigv9KZPpvh0vxnlemkIGe
OT6wIWRo6HhWo6m1lTsvcux04iRknR3IEC/L1jQwRPyTerhge2cLVZ9WvwiMxScKukHsDqYz
CKm8E/Rs/L9af5WJSo7dI5RMCp292cSkguI8Vt9XCc7YirBdQJEsZpZsR2f1mVo+IAAAAAAA
AA==
--------------ms090908050706050506080700--


--===============5264763171101467337==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============5264763171101467337==--


From xen-devel-bounces@lists.xen.org Tue Sep 18 18:16:49 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Sep 2012 18:16:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TE2Lc-0008Io-Tq; Tue, 18 Sep 2012 18:16:36 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <matthew.fioravante@jhuapl.edu>) id 1TE2Lb-0008IU-Hs
	for xen-devel@lists.xensource.com; Tue, 18 Sep 2012 18:16:35 +0000
X-Env-Sender: matthew.fioravante@jhuapl.edu
X-Msg-Ref: server-5.tower-27.messagelabs.com!1347992187!8111154!1
X-Originating-IP: [128.244.251.36]
X-SpamReason: No, hits=0.0 required=7.0 tests=UNPARSEABLE_RELAY
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2156 invoked from network); 18 Sep 2012 18:16:28 -0000
Received: from pilot.jhuapl.edu (HELO jhuapl.edu) (128.244.251.36)
	by server-5.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 18 Sep 2012 18:16:28 -0000
Received: from ([128.244.207.89])
	by pilot.jhuapl.edu with ESMTP with TLS id 63GHCH1.153151006;
	Tue, 18 Sep 2012 14:16:23 -0400
Message-ID: <5058BA2C.7090804@jhuapl.edu>
Date: Tue, 18 Sep 2012 14:15:08 -0400
From: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120827 Thunderbird/15.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>, 
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
X-Enigmail-Version: 1.4.4
Subject: [Xen-devel] [PATCH xm/xl enhancements for vptm 3/6] add iomem
	option to 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: multipart/mixed; boundary="===============2893780515245479195=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a cryptographically signed message in MIME format.

--===============2893780515245479195==
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms090405020308050803020002"

This is a cryptographically signed message in MIME format.

--------------ms090405020308050803020002
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

This patch adds a new option for xen config files for directly mapping
hardware io memory into a vm.

iomem=3D['pagenum,size',..]

Where pagenum is the page number and size is the number of page.
example (for a tpm:
iomem=3D['fed40,5']

Signed off by Matthew Fioravante matthew.fioravante@jhuapl.edu

diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -477,7 +477,7 @@ typedef struct {
     libxl_domain_create_info c_info;
     libxl_domain_build_info b_info;
=20
-    int num_disks, num_vifs, num_pcidevs, num_vfbs, num_vkbs, num_vtpms;=

+    int num_disks, num_vifs, num_pcidevs, num_vfbs, num_vkbs,
num_vtpms, num_iorngs;
=20
     libxl_device_disk *disks;
     libxl_device_nic *vifs;
@@ -485,6 +485,7 @@ typedef struct {
     libxl_device_vfb *vfbs;
     libxl_device_vkb *vkbs;
     libxl_device_vtpm *vtpms;
+    libxl_iomem_range *iorngs;
=20
     libxl_action_on_shutdown on_poweroff;
     libxl_action_on_shutdown on_reboot;
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
@@ -58,6 +58,10 @@ void libxl_domain_config_dispose(libxl_domain_config
*d_config)
        libxl_device_vtpm_dispose(&d_config->vtpms[i]);
     free(d_config->vtpms);
=20
+    for (i=3D0; i<d_config->num_iorngs; i++)
+       libxl_iomem_range_dispose(&d_config->iorngs[i]);
+    free(d_config->iorngs);
+
     libxl_domain_create_info_dispose(&d_config->c_info);
     libxl_domain_build_info_dispose(&d_config->b_info);
 }
@@ -718,6 +722,15 @@ static void domcreate_bootloader_done(libxl__egc *eg=
c,
=20
     store_libxl_entry(gc, domid, &d_config->b_info);
=20
+    for (i =3D 0; i < d_config->num_iorngs; i++) {
+        ret =3D xc_domain_iomem_permission(ctx->xch, domid,
d_config->iorngs[i].start, d_config->iorngs[i].length,
d_config->iorngs[i].allow);
+        if (ret) {
+            LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
+                       "cannot add iomem range %d to domain: %d", i, ret=
);
+            ret =3D ERROR_FAIL;
+            goto error_out;
+        }
+    }
     for (i =3D 0; i < d_config->num_disks; i++) {
         ret =3D libxl_device_disk_add(ctx, domid, &d_config->disks[i]);
         if (ret) {
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
@@ -317,6 +317,12 @@ libxl_domain_build_info =3D Struct("domain_build_inf=
o",[
     ], dir=3DDIR_IN
 )
=20
+libxl_iomem_range =3D Struct("iomem_range", [
+    ("start", uint64),
+    ("length", uint64),
+    ("allow", bool),
+]);
+
 libxl_device_vfb =3D Struct("device_vfb", [
     ("backend_domid", libxl_domid),
     ("devid",         libxl_devid),
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
@@ -560,7 +560,7 @@ static void parse_config_data(const char *config_sour=
ce,
     const char *buf;
     long l;
     XLU_Config *config;
-    XLU_ConfigList *cpus, *vbds, *nics, *pcis, *cvfbs, *cpuids, *vtpms;
+    XLU_ConfigList *cpus, *vbds, *nics, *pcis, *cvfbs, *cpuids, *vtpms,
*iomems;
     int pci_power_mgmt =3D 0;
     int pci_msitranslate =3D 1;
     int pci_permissive =3D 0;
@@ -1145,6 +1145,42 @@ skip_vfb:
             libxl_defbool_set(&b_info->u.pv.e820_host, true);
     }
=20
+    if(!xlu_cfg_get_list(config, "iomem", &iomems, 0, 0)) {
+       int i;
+       for(i =3D0; (buf =3D xlu_cfg_get_listitem(iomems, i)) !=3D NULL; =
++i) {
+          libxl_iomem_range *iorng;
+          char* buf2 =3D strdup(buf);
+          char *st, *len, *al;
+
+          d_config->iorngs =3D realloc(d_config->iorngs,
sizeof(libxl_iomem_range) * (d_config->num_iorngs + 1));
+          iorng =3D d_config->iorngs + d_config->num_iorngs;
+
+          libxl_iomem_range_init(iorng);
+
+          st =3D strtok(buf2, ",");
+          len =3D strtok(NULL, ",");
+          al =3D strtok(NULL, ",");
+
+          if(st =3D=3D NULL || len =3D=3D NULL ||
+                sscanf(st, "%" PRIx64, &iorng->start) !=3D 1 ||
+                sscanf(len, "%" PRIu64, &iorng->length) !=3D 1 ||
+                (al !=3D NULL && ((al[0] !=3D '1' && al[0] !=3D '0') || =
al[1]
!=3D '\0'))
+            ) {
+             fprintf(stderr, "Malformed iomem specification!\n");
+             free(buf2);
+             exit(1);
+          }
+          if(al !=3D NULL) {
+             iorng->allow =3D al[0] - '0';
+          } else {
+             iorng->allow =3D 1;
+          }
+
+          free(buf2);
+          d_config->num_iorngs++;
+       }
+    }
+
     switch (xlu_cfg_get_list(config, "cpuid", &cpuids, 0, 1)) {
     case 0:
         {
--=20
1.7.4.4



--------------ms090405020308050803020002
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIDyjCC
A8YwggMvoAMCAQICBD/xyf0wDQYJKoZIhvcNAQEFBQAwLzELMAkGA1UEBhMCVVMxDzANBgNV
BAoTBkpIVUFQTDEPMA0GA1UECxMGQklTRENBMB4XDTEwMDYxMTE4MjIwNloXDTEzMDYxMTE4
NTIwNlowZjELMAkGA1UEBhMCVVMxDzANBgNVBAoTBkpIVUFQTDEPMA0GA1UECxMGUGVvcGxl
MTUwFgYDVQQLEw9WUE5Hcm91cC1CSVNEQ0EwGwYDVQQDExRNYXR0aGV3IEUgRmlvcmF2YW50
ZTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAnpbwVSP6o1Nb5lcW7dd3yTo9iBJdi7qz
4nANOMFPK7JOy5npKN1iiousl28U/scUJES55gPwAWYJK3uVyQAsA4adgDKi5DoD1UHDQEwp
bY7iHLJeq0NPr4BqYNqnCFPbE6HC8zSJrr4qKn+gVUQT39SIFqdiIPJwZL8FYTRQ/zsCAwEA
AaOCAbYwggGyMAsGA1UdDwQEAwIHgDArBgNVHRAEJDAigA8yMDEwMDYxMTE4MjIwNlqBDzIw
MTIwNzE3MjI1MjA2WjAbBg0rBgEEAbMlCwMBAQEBBAoWCGZpb3JhbWUxMBsGDSsGAQQBsyUL
AwEBAQIEChIIMDAxMDQyNjEwWAYJYIZIAYb6ax4BBEsMSVRoZSBwcml2YXRlIGtleSBjb3Jy
ZXNwb25kaW5nIHRvIHRoaXMgY2VydGlmaWNhdGUgbWF5IGhhdmUgYmVlbiBleHBvcnRlZC4w
KAYDVR0RBCEwH4EdTWF0dGhldy5GaW9yYXZhbnRlQGpodWFwbC5lZHUwUgYDVR0fBEswSTBH
oEWgQ6RBMD8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJU0RD
QTEOMAwGA1UEAxMFQ1JMNTYwHwYDVR0jBBgwFoAUCDUpmxH52EU2CyWmF2EJMB1yqeswHQYD
VR0OBBYEFO6LYxg6r9wHZ+zdQtBHn1dZ/YTNMAkGA1UdEwQCMAAwGQYJKoZIhvZ9B0EABAww
ChsEVjcuMQMCBLAwDQYJKoZIhvcNAQEFBQADgYEAJO9HQh4YNChVLzuZqK5ARJARD8JoujGZ
fdo75quvg2jXFQe2sEjvLnxJZgm/pv8fdZakq48CWwjYHKuvIp7sDjTEsQfo+y7SpN/N2NvJ
WU5SqfK1VgYtNLRRoGJUB5Q1aZ+Dg95g3kqpyfpUMISJL8IKVLtJVfN4fggFVUYZ9wwxggGr
MIIBpwIBATA3MC8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJ
U0RDQQIEP/HJ/TAJBgUrDgMCGgUAoIHLMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ
KoZIhvcNAQkFMQ8XDTEyMDkxODE4MTUwOFowIwYJKoZIhvcNAQkEMRYEFLaQfpZ2WFsc0JEU
StZQDtHNy1tEMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAK
BggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI
KoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEgYCCuHA4v4bt4taY4Q2txn27dQW7qKv2r1ks
AqO7bFXGMRoE4WpCzdOnDL2uGrUlHu+dtCbkSX4WrwgUpFS4V5Sajq3rgwH7tp3OT0YJ5ULR
ESz13u6ajQHIxFB7NmM0D7WSfKUkW376o2sE793sb6AvPsX2BWMIZV+WHd92PZ/HOQAAAAAA
AA==
--------------ms090405020308050803020002--


--===============2893780515245479195==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============2893780515245479195==--


From xen-devel-bounces@lists.xen.org Tue Sep 18 18:16:49 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Sep 2012 18:16:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TE2Lc-0008Io-Tq; Tue, 18 Sep 2012 18:16:36 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <matthew.fioravante@jhuapl.edu>) id 1TE2Lb-0008IU-Hs
	for xen-devel@lists.xensource.com; Tue, 18 Sep 2012 18:16:35 +0000
X-Env-Sender: matthew.fioravante@jhuapl.edu
X-Msg-Ref: server-5.tower-27.messagelabs.com!1347992187!8111154!1
X-Originating-IP: [128.244.251.36]
X-SpamReason: No, hits=0.0 required=7.0 tests=UNPARSEABLE_RELAY
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2156 invoked from network); 18 Sep 2012 18:16:28 -0000
Received: from pilot.jhuapl.edu (HELO jhuapl.edu) (128.244.251.36)
	by server-5.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 18 Sep 2012 18:16:28 -0000
Received: from ([128.244.207.89])
	by pilot.jhuapl.edu with ESMTP with TLS id 63GHCH1.153151006;
	Tue, 18 Sep 2012 14:16:23 -0400
Message-ID: <5058BA2C.7090804@jhuapl.edu>
Date: Tue, 18 Sep 2012 14:15:08 -0400
From: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120827 Thunderbird/15.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>, 
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
X-Enigmail-Version: 1.4.4
Subject: [Xen-devel] [PATCH xm/xl enhancements for vptm 3/6] add iomem
	option to 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: multipart/mixed; boundary="===============2893780515245479195=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a cryptographically signed message in MIME format.

--===============2893780515245479195==
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms090405020308050803020002"

This is a cryptographically signed message in MIME format.

--------------ms090405020308050803020002
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

This patch adds a new option for xen config files for directly mapping
hardware io memory into a vm.

iomem=3D['pagenum,size',..]

Where pagenum is the page number and size is the number of page.
example (for a tpm:
iomem=3D['fed40,5']

Signed off by Matthew Fioravante matthew.fioravante@jhuapl.edu

diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -477,7 +477,7 @@ typedef struct {
     libxl_domain_create_info c_info;
     libxl_domain_build_info b_info;
=20
-    int num_disks, num_vifs, num_pcidevs, num_vfbs, num_vkbs, num_vtpms;=

+    int num_disks, num_vifs, num_pcidevs, num_vfbs, num_vkbs,
num_vtpms, num_iorngs;
=20
     libxl_device_disk *disks;
     libxl_device_nic *vifs;
@@ -485,6 +485,7 @@ typedef struct {
     libxl_device_vfb *vfbs;
     libxl_device_vkb *vkbs;
     libxl_device_vtpm *vtpms;
+    libxl_iomem_range *iorngs;
=20
     libxl_action_on_shutdown on_poweroff;
     libxl_action_on_shutdown on_reboot;
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
@@ -58,6 +58,10 @@ void libxl_domain_config_dispose(libxl_domain_config
*d_config)
        libxl_device_vtpm_dispose(&d_config->vtpms[i]);
     free(d_config->vtpms);
=20
+    for (i=3D0; i<d_config->num_iorngs; i++)
+       libxl_iomem_range_dispose(&d_config->iorngs[i]);
+    free(d_config->iorngs);
+
     libxl_domain_create_info_dispose(&d_config->c_info);
     libxl_domain_build_info_dispose(&d_config->b_info);
 }
@@ -718,6 +722,15 @@ static void domcreate_bootloader_done(libxl__egc *eg=
c,
=20
     store_libxl_entry(gc, domid, &d_config->b_info);
=20
+    for (i =3D 0; i < d_config->num_iorngs; i++) {
+        ret =3D xc_domain_iomem_permission(ctx->xch, domid,
d_config->iorngs[i].start, d_config->iorngs[i].length,
d_config->iorngs[i].allow);
+        if (ret) {
+            LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
+                       "cannot add iomem range %d to domain: %d", i, ret=
);
+            ret =3D ERROR_FAIL;
+            goto error_out;
+        }
+    }
     for (i =3D 0; i < d_config->num_disks; i++) {
         ret =3D libxl_device_disk_add(ctx, domid, &d_config->disks[i]);
         if (ret) {
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
@@ -317,6 +317,12 @@ libxl_domain_build_info =3D Struct("domain_build_inf=
o",[
     ], dir=3DDIR_IN
 )
=20
+libxl_iomem_range =3D Struct("iomem_range", [
+    ("start", uint64),
+    ("length", uint64),
+    ("allow", bool),
+]);
+
 libxl_device_vfb =3D Struct("device_vfb", [
     ("backend_domid", libxl_domid),
     ("devid",         libxl_devid),
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
@@ -560,7 +560,7 @@ static void parse_config_data(const char *config_sour=
ce,
     const char *buf;
     long l;
     XLU_Config *config;
-    XLU_ConfigList *cpus, *vbds, *nics, *pcis, *cvfbs, *cpuids, *vtpms;
+    XLU_ConfigList *cpus, *vbds, *nics, *pcis, *cvfbs, *cpuids, *vtpms,
*iomems;
     int pci_power_mgmt =3D 0;
     int pci_msitranslate =3D 1;
     int pci_permissive =3D 0;
@@ -1145,6 +1145,42 @@ skip_vfb:
             libxl_defbool_set(&b_info->u.pv.e820_host, true);
     }
=20
+    if(!xlu_cfg_get_list(config, "iomem", &iomems, 0, 0)) {
+       int i;
+       for(i =3D0; (buf =3D xlu_cfg_get_listitem(iomems, i)) !=3D NULL; =
++i) {
+          libxl_iomem_range *iorng;
+          char* buf2 =3D strdup(buf);
+          char *st, *len, *al;
+
+          d_config->iorngs =3D realloc(d_config->iorngs,
sizeof(libxl_iomem_range) * (d_config->num_iorngs + 1));
+          iorng =3D d_config->iorngs + d_config->num_iorngs;
+
+          libxl_iomem_range_init(iorng);
+
+          st =3D strtok(buf2, ",");
+          len =3D strtok(NULL, ",");
+          al =3D strtok(NULL, ",");
+
+          if(st =3D=3D NULL || len =3D=3D NULL ||
+                sscanf(st, "%" PRIx64, &iorng->start) !=3D 1 ||
+                sscanf(len, "%" PRIu64, &iorng->length) !=3D 1 ||
+                (al !=3D NULL && ((al[0] !=3D '1' && al[0] !=3D '0') || =
al[1]
!=3D '\0'))
+            ) {
+             fprintf(stderr, "Malformed iomem specification!\n");
+             free(buf2);
+             exit(1);
+          }
+          if(al !=3D NULL) {
+             iorng->allow =3D al[0] - '0';
+          } else {
+             iorng->allow =3D 1;
+          }
+
+          free(buf2);
+          d_config->num_iorngs++;
+       }
+    }
+
     switch (xlu_cfg_get_list(config, "cpuid", &cpuids, 0, 1)) {
     case 0:
         {
--=20
1.7.4.4



--------------ms090405020308050803020002
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIDyjCC
A8YwggMvoAMCAQICBD/xyf0wDQYJKoZIhvcNAQEFBQAwLzELMAkGA1UEBhMCVVMxDzANBgNV
BAoTBkpIVUFQTDEPMA0GA1UECxMGQklTRENBMB4XDTEwMDYxMTE4MjIwNloXDTEzMDYxMTE4
NTIwNlowZjELMAkGA1UEBhMCVVMxDzANBgNVBAoTBkpIVUFQTDEPMA0GA1UECxMGUGVvcGxl
MTUwFgYDVQQLEw9WUE5Hcm91cC1CSVNEQ0EwGwYDVQQDExRNYXR0aGV3IEUgRmlvcmF2YW50
ZTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAnpbwVSP6o1Nb5lcW7dd3yTo9iBJdi7qz
4nANOMFPK7JOy5npKN1iiousl28U/scUJES55gPwAWYJK3uVyQAsA4adgDKi5DoD1UHDQEwp
bY7iHLJeq0NPr4BqYNqnCFPbE6HC8zSJrr4qKn+gVUQT39SIFqdiIPJwZL8FYTRQ/zsCAwEA
AaOCAbYwggGyMAsGA1UdDwQEAwIHgDArBgNVHRAEJDAigA8yMDEwMDYxMTE4MjIwNlqBDzIw
MTIwNzE3MjI1MjA2WjAbBg0rBgEEAbMlCwMBAQEBBAoWCGZpb3JhbWUxMBsGDSsGAQQBsyUL
AwEBAQIEChIIMDAxMDQyNjEwWAYJYIZIAYb6ax4BBEsMSVRoZSBwcml2YXRlIGtleSBjb3Jy
ZXNwb25kaW5nIHRvIHRoaXMgY2VydGlmaWNhdGUgbWF5IGhhdmUgYmVlbiBleHBvcnRlZC4w
KAYDVR0RBCEwH4EdTWF0dGhldy5GaW9yYXZhbnRlQGpodWFwbC5lZHUwUgYDVR0fBEswSTBH
oEWgQ6RBMD8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJU0RD
QTEOMAwGA1UEAxMFQ1JMNTYwHwYDVR0jBBgwFoAUCDUpmxH52EU2CyWmF2EJMB1yqeswHQYD
VR0OBBYEFO6LYxg6r9wHZ+zdQtBHn1dZ/YTNMAkGA1UdEwQCMAAwGQYJKoZIhvZ9B0EABAww
ChsEVjcuMQMCBLAwDQYJKoZIhvcNAQEFBQADgYEAJO9HQh4YNChVLzuZqK5ARJARD8JoujGZ
fdo75quvg2jXFQe2sEjvLnxJZgm/pv8fdZakq48CWwjYHKuvIp7sDjTEsQfo+y7SpN/N2NvJ
WU5SqfK1VgYtNLRRoGJUB5Q1aZ+Dg95g3kqpyfpUMISJL8IKVLtJVfN4fggFVUYZ9wwxggGr
MIIBpwIBATA3MC8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJ
U0RDQQIEP/HJ/TAJBgUrDgMCGgUAoIHLMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ
KoZIhvcNAQkFMQ8XDTEyMDkxODE4MTUwOFowIwYJKoZIhvcNAQkEMRYEFLaQfpZ2WFsc0JEU
StZQDtHNy1tEMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAK
BggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI
KoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEgYCCuHA4v4bt4taY4Q2txn27dQW7qKv2r1ks
AqO7bFXGMRoE4WpCzdOnDL2uGrUlHu+dtCbkSX4WrwgUpFS4V5Sajq3rgwH7tp3OT0YJ5ULR
ESz13u6ajQHIxFB7NmM0D7WSfKUkW376o2sE793sb6AvPsX2BWMIZV+WHd92PZ/HOQAAAAAA
AA==
--------------ms090405020308050803020002--


--===============2893780515245479195==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============2893780515245479195==--


From xen-devel-bounces@lists.xen.org Tue Sep 18 18:19:32 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Sep 2012 18:19:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TE2OD-0008SR-HF; Tue, 18 Sep 2012 18:19:17 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <matthew.fioravante@jhuapl.edu>) id 1TE2OC-0008SH-H0
	for xen-devel@lists.xensource.com; Tue, 18 Sep 2012 18:19:16 +0000
Received: from [85.158.143.99:43026] by server-2.bemta-4.messagelabs.com id
	02/F5-06610-32BB8505; Tue, 18 Sep 2012 18:19:15 +0000
X-Env-Sender: matthew.fioravante@jhuapl.edu
X-Msg-Ref: server-10.tower-216.messagelabs.com!1347992353!24449179!1
X-Originating-IP: [128.244.251.36]
X-SpamReason: No, hits=0.0 required=7.0 tests=UNPARSEABLE_RELAY
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18753 invoked from network); 18 Sep 2012 18:19:14 -0000
Received: from pilot.jhuapl.edu (HELO jhuapl.edu) (128.244.251.36)
	by server-10.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 18 Sep 2012 18:19:14 -0000
Received: from ([128.244.207.89])
	by pilot.jhuapl.edu with ESMTP with TLS id 63GHCH1.153151362;
	Tue, 18 Sep 2012 14:19:07 -0400
Message-ID: <5058BACF.6030903@jhuapl.edu>
Date: Tue, 18 Sep 2012 14:17:51 -0400
From: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120827 Thunderbird/15.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>, 
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
X-Enigmail-Version: 1.4.4
Subject: [Xen-devel] [PATCH xm/xl enhancements for vptm 4/6] xl add irq
	support
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1148898623856142616=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a cryptographically signed message in MIME format.

--===============1148898623856142616==
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms020004030705070200000307"

This is a cryptographically signed message in MIME format.

--------------ms020004030705070200000307
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

This patch adds support for mapping irqs into virtual machines. The
syntax is

irq =3D [irqnum,allow]


Signed off by Matthew Fioravante matthew.fioravante@jhuapl.edu

diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -477,7 +477,7 @@ typedef struct {
     libxl_domain_create_info c_info;
     libxl_domain_build_info b_info;
=20
-    int num_disks, num_vifs, num_pcidevs, num_vfbs, num_vkbs,
num_vtpms, num_iorngs;
+    int num_disks, num_vifs, num_pcidevs, num_vfbs, num_vkbs,
num_vtpms, num_iorngs, num_irqs;
=20
     libxl_device_disk *disks;
     libxl_device_nic *vifs;
@@ -486,6 +486,7 @@ typedef struct {
     libxl_device_vkb *vkbs;
     libxl_device_vtpm *vtpms;
     libxl_iomem_range *iorngs;
+    libxl_irq         *irqs;
=20
     libxl_action_on_shutdown on_poweroff;
     libxl_action_on_shutdown on_reboot;
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
@@ -62,6 +62,10 @@ void libxl_domain_config_dispose(libxl_domain_config
*d_config)
        libxl_iomem_range_dispose(&d_config->iorngs[i]);
     free(d_config->iorngs);
=20
+    for (i=3D0; i<d_config->num_irqs; i++)
+       libxl_irq_dispose(&d_config->irqs[i]);
+    free(d_config->irqs);
+
     libxl_domain_create_info_dispose(&d_config->c_info);
     libxl_domain_build_info_dispose(&d_config->b_info);
 }
@@ -731,6 +735,15 @@ static void domcreate_bootloader_done(libxl__egc *eg=
c,
             goto error_out;
         }
     }
+    for (i =3D 0; i < d_config->num_irqs; i++) {
+        ret =3D xc_domain_irq_permission(ctx->xch, domid,
d_config->irqs[i].irq, d_config->irqs[i].allow);
+        if (ret) {
+            LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
+                       "cannot add irq %d to domain: %d", i, ret);
+            ret =3D ERROR_FAIL;
+            goto error_out;
+        }
+    }
     for (i =3D 0; i < d_config->num_disks; i++) {
         ret =3D libxl_device_disk_add(ctx, domid, &d_config->disks[i]);
         if (ret) {
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
@@ -323,6 +323,11 @@ libxl_iomem_range =3D Struct("iomem_range", [
     ("allow", bool),
 ]);
=20
+libxl_irq =3D Struct("irq", [
+    ("irq", uint32),
+    ("allow", bool),
+])
+
 libxl_device_vfb =3D Struct("device_vfb", [
     ("backend_domid", libxl_domid),
     ("devid",         libxl_devid),
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
@@ -560,7 +560,7 @@ static void parse_config_data(const char *config_sour=
ce,
     const char *buf;
     long l;
     XLU_Config *config;
-    XLU_ConfigList *cpus, *vbds, *nics, *pcis, *cvfbs, *cpuids, *vtpms,
*iomems;
+    XLU_ConfigList *cpus, *vbds, *nics, *pcis, *cvfbs, *cpuids, *vtpms,
*iomems, *irqs;
     int pci_power_mgmt =3D 0;
     int pci_msitranslate =3D 1;
     int pci_permissive =3D 0;
@@ -1181,6 +1181,39 @@ skip_vfb:
        }
     }
=20
+    if(!xlu_cfg_get_list(config, "irq", &irqs, 0, 0)) {
+       int i;
+       for(i =3D 0; (buf =3D xlu_cfg_get_listitem(irqs, i)) !=3D NULL; +=
+i) {
+          libxl_irq* irq;
+          char* buf2 =3D strdup(buf);
+          char* irqstr, *al;
+
+          d_config->irqs =3D realloc(d_config->irqs, sizeof(libxl_irq) *=

(d_config->num_irqs + 1));
+          irq =3D d_config->irqs + d_config->num_irqs;
+
+          libxl_irq_init(irq);
+
+          irqstr =3D strtok(buf2, ",");
+          al =3D strtok(NULL, ",");
+
+          if(irqstr =3D=3D NULL ||
+                sscanf(irqstr, "%" PRIu32, &irq->irq) !=3D 1 ||
+                (al !=3D NULL && ((al[0] !=3D '1' && al[0] !=3D '0') || =
al[1]
!=3D '\0'))
+            ) {
+             fprintf(stderr, "Malformed irq specification!\n");
+             free(buf2);
+             exit(1);
+          }
+          if(al !=3D NULL) {
+             irq->allow =3D al[0] - '0';
+          } else {
+             irq->allow =3D 1;
+          }
+          free(buf2);
+          d_config->num_irqs++;
+       }
+    }
+
     switch (xlu_cfg_get_list(config, "cpuid", &cpuids, 0, 1)) {
     case 0:
         {



--------------ms020004030705070200000307
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIDyjCC
A8YwggMvoAMCAQICBD/xyf0wDQYJKoZIhvcNAQEFBQAwLzELMAkGA1UEBhMCVVMxDzANBgNV
BAoTBkpIVUFQTDEPMA0GA1UECxMGQklTRENBMB4XDTEwMDYxMTE4MjIwNloXDTEzMDYxMTE4
NTIwNlowZjELMAkGA1UEBhMCVVMxDzANBgNVBAoTBkpIVUFQTDEPMA0GA1UECxMGUGVvcGxl
MTUwFgYDVQQLEw9WUE5Hcm91cC1CSVNEQ0EwGwYDVQQDExRNYXR0aGV3IEUgRmlvcmF2YW50
ZTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAnpbwVSP6o1Nb5lcW7dd3yTo9iBJdi7qz
4nANOMFPK7JOy5npKN1iiousl28U/scUJES55gPwAWYJK3uVyQAsA4adgDKi5DoD1UHDQEwp
bY7iHLJeq0NPr4BqYNqnCFPbE6HC8zSJrr4qKn+gVUQT39SIFqdiIPJwZL8FYTRQ/zsCAwEA
AaOCAbYwggGyMAsGA1UdDwQEAwIHgDArBgNVHRAEJDAigA8yMDEwMDYxMTE4MjIwNlqBDzIw
MTIwNzE3MjI1MjA2WjAbBg0rBgEEAbMlCwMBAQEBBAoWCGZpb3JhbWUxMBsGDSsGAQQBsyUL
AwEBAQIEChIIMDAxMDQyNjEwWAYJYIZIAYb6ax4BBEsMSVRoZSBwcml2YXRlIGtleSBjb3Jy
ZXNwb25kaW5nIHRvIHRoaXMgY2VydGlmaWNhdGUgbWF5IGhhdmUgYmVlbiBleHBvcnRlZC4w
KAYDVR0RBCEwH4EdTWF0dGhldy5GaW9yYXZhbnRlQGpodWFwbC5lZHUwUgYDVR0fBEswSTBH
oEWgQ6RBMD8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJU0RD
QTEOMAwGA1UEAxMFQ1JMNTYwHwYDVR0jBBgwFoAUCDUpmxH52EU2CyWmF2EJMB1yqeswHQYD
VR0OBBYEFO6LYxg6r9wHZ+zdQtBHn1dZ/YTNMAkGA1UdEwQCMAAwGQYJKoZIhvZ9B0EABAww
ChsEVjcuMQMCBLAwDQYJKoZIhvcNAQEFBQADgYEAJO9HQh4YNChVLzuZqK5ARJARD8JoujGZ
fdo75quvg2jXFQe2sEjvLnxJZgm/pv8fdZakq48CWwjYHKuvIp7sDjTEsQfo+y7SpN/N2NvJ
WU5SqfK1VgYtNLRRoGJUB5Q1aZ+Dg95g3kqpyfpUMISJL8IKVLtJVfN4fggFVUYZ9wwxggGr
MIIBpwIBATA3MC8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJ
U0RDQQIEP/HJ/TAJBgUrDgMCGgUAoIHLMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ
KoZIhvcNAQkFMQ8XDTEyMDkxODE4MTc1MVowIwYJKoZIhvcNAQkEMRYEFO6PtBJn4pDlGt+W
7MRLDolQwUYdMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAK
BggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI
KoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEgYBKhi5nIyKehrvxK91lG9F7NEV6WVyQ4gfF
WsU6fw3gzApD5AafYTJY98gIUIPqBJWr10khoCov6SnBELyvZJnhnbhpjiB3jMg3hGTrz/4l
m8Ba1gCs/JMYdIbVG3rYtqkBCP52PXKvXGg6VG/pNmbItYWPvM2CEBNjj6SrSlksQAAAAAAA
AA==
--------------ms020004030705070200000307--


--===============1148898623856142616==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============1148898623856142616==--


From xen-devel-bounces@lists.xen.org Tue Sep 18 18:19:32 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Sep 2012 18:19:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TE2OD-0008SR-HF; Tue, 18 Sep 2012 18:19:17 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <matthew.fioravante@jhuapl.edu>) id 1TE2OC-0008SH-H0
	for xen-devel@lists.xensource.com; Tue, 18 Sep 2012 18:19:16 +0000
Received: from [85.158.143.99:43026] by server-2.bemta-4.messagelabs.com id
	02/F5-06610-32BB8505; Tue, 18 Sep 2012 18:19:15 +0000
X-Env-Sender: matthew.fioravante@jhuapl.edu
X-Msg-Ref: server-10.tower-216.messagelabs.com!1347992353!24449179!1
X-Originating-IP: [128.244.251.36]
X-SpamReason: No, hits=0.0 required=7.0 tests=UNPARSEABLE_RELAY
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18753 invoked from network); 18 Sep 2012 18:19:14 -0000
Received: from pilot.jhuapl.edu (HELO jhuapl.edu) (128.244.251.36)
	by server-10.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 18 Sep 2012 18:19:14 -0000
Received: from ([128.244.207.89])
	by pilot.jhuapl.edu with ESMTP with TLS id 63GHCH1.153151362;
	Tue, 18 Sep 2012 14:19:07 -0400
Message-ID: <5058BACF.6030903@jhuapl.edu>
Date: Tue, 18 Sep 2012 14:17:51 -0400
From: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120827 Thunderbird/15.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>, 
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
X-Enigmail-Version: 1.4.4
Subject: [Xen-devel] [PATCH xm/xl enhancements for vptm 4/6] xl add irq
	support
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1148898623856142616=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a cryptographically signed message in MIME format.

--===============1148898623856142616==
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms020004030705070200000307"

This is a cryptographically signed message in MIME format.

--------------ms020004030705070200000307
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

This patch adds support for mapping irqs into virtual machines. The
syntax is

irq =3D [irqnum,allow]


Signed off by Matthew Fioravante matthew.fioravante@jhuapl.edu

diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -477,7 +477,7 @@ typedef struct {
     libxl_domain_create_info c_info;
     libxl_domain_build_info b_info;
=20
-    int num_disks, num_vifs, num_pcidevs, num_vfbs, num_vkbs,
num_vtpms, num_iorngs;
+    int num_disks, num_vifs, num_pcidevs, num_vfbs, num_vkbs,
num_vtpms, num_iorngs, num_irqs;
=20
     libxl_device_disk *disks;
     libxl_device_nic *vifs;
@@ -486,6 +486,7 @@ typedef struct {
     libxl_device_vkb *vkbs;
     libxl_device_vtpm *vtpms;
     libxl_iomem_range *iorngs;
+    libxl_irq         *irqs;
=20
     libxl_action_on_shutdown on_poweroff;
     libxl_action_on_shutdown on_reboot;
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
@@ -62,6 +62,10 @@ void libxl_domain_config_dispose(libxl_domain_config
*d_config)
        libxl_iomem_range_dispose(&d_config->iorngs[i]);
     free(d_config->iorngs);
=20
+    for (i=3D0; i<d_config->num_irqs; i++)
+       libxl_irq_dispose(&d_config->irqs[i]);
+    free(d_config->irqs);
+
     libxl_domain_create_info_dispose(&d_config->c_info);
     libxl_domain_build_info_dispose(&d_config->b_info);
 }
@@ -731,6 +735,15 @@ static void domcreate_bootloader_done(libxl__egc *eg=
c,
             goto error_out;
         }
     }
+    for (i =3D 0; i < d_config->num_irqs; i++) {
+        ret =3D xc_domain_irq_permission(ctx->xch, domid,
d_config->irqs[i].irq, d_config->irqs[i].allow);
+        if (ret) {
+            LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
+                       "cannot add irq %d to domain: %d", i, ret);
+            ret =3D ERROR_FAIL;
+            goto error_out;
+        }
+    }
     for (i =3D 0; i < d_config->num_disks; i++) {
         ret =3D libxl_device_disk_add(ctx, domid, &d_config->disks[i]);
         if (ret) {
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
@@ -323,6 +323,11 @@ libxl_iomem_range =3D Struct("iomem_range", [
     ("allow", bool),
 ]);
=20
+libxl_irq =3D Struct("irq", [
+    ("irq", uint32),
+    ("allow", bool),
+])
+
 libxl_device_vfb =3D Struct("device_vfb", [
     ("backend_domid", libxl_domid),
     ("devid",         libxl_devid),
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
@@ -560,7 +560,7 @@ static void parse_config_data(const char *config_sour=
ce,
     const char *buf;
     long l;
     XLU_Config *config;
-    XLU_ConfigList *cpus, *vbds, *nics, *pcis, *cvfbs, *cpuids, *vtpms,
*iomems;
+    XLU_ConfigList *cpus, *vbds, *nics, *pcis, *cvfbs, *cpuids, *vtpms,
*iomems, *irqs;
     int pci_power_mgmt =3D 0;
     int pci_msitranslate =3D 1;
     int pci_permissive =3D 0;
@@ -1181,6 +1181,39 @@ skip_vfb:
        }
     }
=20
+    if(!xlu_cfg_get_list(config, "irq", &irqs, 0, 0)) {
+       int i;
+       for(i =3D 0; (buf =3D xlu_cfg_get_listitem(irqs, i)) !=3D NULL; +=
+i) {
+          libxl_irq* irq;
+          char* buf2 =3D strdup(buf);
+          char* irqstr, *al;
+
+          d_config->irqs =3D realloc(d_config->irqs, sizeof(libxl_irq) *=

(d_config->num_irqs + 1));
+          irq =3D d_config->irqs + d_config->num_irqs;
+
+          libxl_irq_init(irq);
+
+          irqstr =3D strtok(buf2, ",");
+          al =3D strtok(NULL, ",");
+
+          if(irqstr =3D=3D NULL ||
+                sscanf(irqstr, "%" PRIu32, &irq->irq) !=3D 1 ||
+                (al !=3D NULL && ((al[0] !=3D '1' && al[0] !=3D '0') || =
al[1]
!=3D '\0'))
+            ) {
+             fprintf(stderr, "Malformed irq specification!\n");
+             free(buf2);
+             exit(1);
+          }
+          if(al !=3D NULL) {
+             irq->allow =3D al[0] - '0';
+          } else {
+             irq->allow =3D 1;
+          }
+          free(buf2);
+          d_config->num_irqs++;
+       }
+    }
+
     switch (xlu_cfg_get_list(config, "cpuid", &cpuids, 0, 1)) {
     case 0:
         {



--------------ms020004030705070200000307
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIDyjCC
A8YwggMvoAMCAQICBD/xyf0wDQYJKoZIhvcNAQEFBQAwLzELMAkGA1UEBhMCVVMxDzANBgNV
BAoTBkpIVUFQTDEPMA0GA1UECxMGQklTRENBMB4XDTEwMDYxMTE4MjIwNloXDTEzMDYxMTE4
NTIwNlowZjELMAkGA1UEBhMCVVMxDzANBgNVBAoTBkpIVUFQTDEPMA0GA1UECxMGUGVvcGxl
MTUwFgYDVQQLEw9WUE5Hcm91cC1CSVNEQ0EwGwYDVQQDExRNYXR0aGV3IEUgRmlvcmF2YW50
ZTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAnpbwVSP6o1Nb5lcW7dd3yTo9iBJdi7qz
4nANOMFPK7JOy5npKN1iiousl28U/scUJES55gPwAWYJK3uVyQAsA4adgDKi5DoD1UHDQEwp
bY7iHLJeq0NPr4BqYNqnCFPbE6HC8zSJrr4qKn+gVUQT39SIFqdiIPJwZL8FYTRQ/zsCAwEA
AaOCAbYwggGyMAsGA1UdDwQEAwIHgDArBgNVHRAEJDAigA8yMDEwMDYxMTE4MjIwNlqBDzIw
MTIwNzE3MjI1MjA2WjAbBg0rBgEEAbMlCwMBAQEBBAoWCGZpb3JhbWUxMBsGDSsGAQQBsyUL
AwEBAQIEChIIMDAxMDQyNjEwWAYJYIZIAYb6ax4BBEsMSVRoZSBwcml2YXRlIGtleSBjb3Jy
ZXNwb25kaW5nIHRvIHRoaXMgY2VydGlmaWNhdGUgbWF5IGhhdmUgYmVlbiBleHBvcnRlZC4w
KAYDVR0RBCEwH4EdTWF0dGhldy5GaW9yYXZhbnRlQGpodWFwbC5lZHUwUgYDVR0fBEswSTBH
oEWgQ6RBMD8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJU0RD
QTEOMAwGA1UEAxMFQ1JMNTYwHwYDVR0jBBgwFoAUCDUpmxH52EU2CyWmF2EJMB1yqeswHQYD
VR0OBBYEFO6LYxg6r9wHZ+zdQtBHn1dZ/YTNMAkGA1UdEwQCMAAwGQYJKoZIhvZ9B0EABAww
ChsEVjcuMQMCBLAwDQYJKoZIhvcNAQEFBQADgYEAJO9HQh4YNChVLzuZqK5ARJARD8JoujGZ
fdo75quvg2jXFQe2sEjvLnxJZgm/pv8fdZakq48CWwjYHKuvIp7sDjTEsQfo+y7SpN/N2NvJ
WU5SqfK1VgYtNLRRoGJUB5Q1aZ+Dg95g3kqpyfpUMISJL8IKVLtJVfN4fggFVUYZ9wwxggGr
MIIBpwIBATA3MC8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJ
U0RDQQIEP/HJ/TAJBgUrDgMCGgUAoIHLMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ
KoZIhvcNAQkFMQ8XDTEyMDkxODE4MTc1MVowIwYJKoZIhvcNAQkEMRYEFO6PtBJn4pDlGt+W
7MRLDolQwUYdMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAK
BggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI
KoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEgYBKhi5nIyKehrvxK91lG9F7NEV6WVyQ4gfF
WsU6fw3gzApD5AafYTJY98gIUIPqBJWr10khoCov6SnBELyvZJnhnbhpjiB3jMg3hGTrz/4l
m8Ba1gCs/JMYdIbVG3rYtqkBCP52PXKvXGg6VG/pNmbItYWPvM2CEBNjj6SrSlksQAAAAAAA
AA==
--------------ms020004030705070200000307--


--===============1148898623856142616==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============1148898623856142616==--


From xen-devel-bounces@lists.xen.org Tue Sep 18 18:22:02 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Sep 2012 18: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 1TE2Qi-0000A0-3p; Tue, 18 Sep 2012 18:21:52 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <matthew.fioravante@jhuapl.edu>) id 1TE2Qg-00009r-QY
	for xen-devel@lists.xensource.com; Tue, 18 Sep 2012 18:21:51 +0000
Received: from [85.158.143.35:11709] by server-2.bemta-4.messagelabs.com id
	21/67-06610-EBBB8505; Tue, 18 Sep 2012 18:21:50 +0000
X-Env-Sender: matthew.fioravante@jhuapl.edu
X-Msg-Ref: server-13.tower-21.messagelabs.com!1347992506!17467242!1
X-Originating-IP: [128.244.251.36]
X-SpamReason: No, hits=0.0 required=7.0 tests=UNPARSEABLE_RELAY
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3830 invoked from network); 18 Sep 2012 18:21:47 -0000
Received: from pilot.jhuapl.edu (HELO jhuapl.edu) (128.244.251.36)
	by server-13.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 18 Sep 2012 18:21:47 -0000
Received: from ([128.244.207.89])
	by pilot.jhuapl.edu with ESMTP with TLS id 63GHCH1.153151636;
	Tue, 18 Sep 2012 14:21:39 -0400
Message-ID: <5058BB68.5090504@jhuapl.edu>
Date: Tue, 18 Sep 2012 14:20:24 -0400
From: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120827 Thunderbird/15.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>, 
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
X-Enigmail-Version: 1.4.4
Subject: [Xen-devel] [PATCH xm/xl enhancements for vptm 5/6] add ioport
	support to libxl
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============5776196528701638710=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a cryptographically signed message in MIME format.

--===============5776196528701638710==
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms030107040307060301080107"

This is a cryptographically signed message in MIME format.

--------------ms030107040307060301080107
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

This patch adds support for mapping ioports to vms using xl, similar to
the function in xm.

Signed of by Matthew Fioravante matthew.fioravante@jhuapl.edu

diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -477,7 +477,7 @@ typedef struct {
     libxl_domain_create_info c_info;
     libxl_domain_build_info b_info;
=20
-    int num_disks, num_vifs, num_pcidevs, num_vfbs, num_vkbs,
num_vtpms, num_iorngs, num_irqs;
+    int num_disks, num_vifs, num_pcidevs, num_vfbs, num_vkbs,
num_vtpms, num_iorngs, num_irqs, num_ioports;
=20
     libxl_device_disk *disks;
     libxl_device_nic *vifs;
@@ -487,6 +487,7 @@ typedef struct {
     libxl_device_vtpm *vtpms;
     libxl_iomem_range *iorngs;
     libxl_irq         *irqs;
+    libxl_ioport_range *ioports;
=20
     libxl_action_on_shutdown on_poweroff;
     libxl_action_on_shutdown on_reboot;
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
@@ -66,6 +66,10 @@ void libxl_domain_config_dispose(libxl_domain_config
*d_config)
        libxl_irq_dispose(&d_config->irqs[i]);
     free(d_config->irqs);
=20
+    for (i=3D0; i<d_config->num_ioports; i++)
+       libxl_ioport_range_dispose(&d_config->ioports[i]);
+    free(d_config->ioports);
+
     libxl_domain_create_info_dispose(&d_config->c_info);
     libxl_domain_build_info_dispose(&d_config->b_info);
 }
@@ -744,6 +748,16 @@ static void domcreate_bootloader_done(libxl__egc *eg=
c,
             goto error_out;
         }
     }
+    for (i =3D 0; i < d_config->num_ioports; i++) {
+       printf("PORT %d %d %d\n", d_config->ioports[i].start,
d_config->ioports[i].nr_ports, d_config->ioports[i].allow);
+        ret =3D xc_domain_ioport_permission(ctx->xch, domid,
d_config->ioports[i].start, d_config->ioports[i].nr_ports,
d_config->ioports[i].allow);
+        if (ret) {
+            LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
+                       "cannot add ioport %d to domain: %d", i, ret);
+            ret =3D ERROR_FAIL;
+            goto error_out;
+        }
+    }
     for (i =3D 0; i < d_config->num_disks; i++) {
         ret =3D libxl_device_disk_add(ctx, domid, &d_config->disks[i]);
         if (ret) {
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
@@ -328,6 +328,13 @@ libxl_irq =3D Struct("irq", [
     ("allow", bool),
 ])
=20
+libxl_ioport_range =3D Struct("ioport_range", [
+    ("start", uint32),
+    ("nr_ports", uint32),
+    ("allow", bool),
+]);
+
+
 libxl_device_vfb =3D Struct("device_vfb", [
     ("backend_domid", libxl_domid),
     ("devid",         libxl_devid),
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
@@ -560,7 +560,7 @@ static void parse_config_data(const char *config_sour=
ce,
     const char *buf;
     long l;
     XLU_Config *config;
-    XLU_ConfigList *cpus, *vbds, *nics, *pcis, *cvfbs, *cpuids, *vtpms,
*iomems, *irqs;
+    XLU_ConfigList *cpus, *vbds, *nics, *pcis, *cvfbs, *cpuids, *vtpms,
*iomems, *irqs, *ioports;
     int pci_power_mgmt =3D 0;
     int pci_msitranslate =3D 1;
     int pci_permissive =3D 0;
@@ -1214,6 +1214,44 @@ skip_vfb:
        }
     }
=20
+    if(!xlu_cfg_get_list(config, "ioport", &ioports, 0, 0)) {
+       int i;
+       for(i =3D0; (buf =3D xlu_cfg_get_listitem(ioports, i)) !=3D NULL;=
 ++i) {
+          libxl_ioport_range* ioport;
+          char* buf2 =3D strdup(buf);
+          char *st, *len, *al;
+
+          d_config->ioports =3D realloc(d_config->ioports,
sizeof(libxl_ioport_range) * (d_config->num_ioports + 1));
+          ioport =3D d_config->ioports + d_config->num_ioports;
+
+          libxl_ioport_range_init(ioport);
+
+          st =3D strtok(buf2, ",");
+          len =3D strtok(NULL, ",");
+          al =3D strtok(NULL, ",");
+
+          if(st =3D=3D NULL || len =3D=3D NULL ||
+                sscanf(st, "%" PRIu32, &ioport->start) !=3D 1 ||
+                sscanf(len, "%" PRIu32, &ioport->nr_ports) !=3D 1 ||
+                (al !=3D NULL && ((al[0] !=3D '1' && al[0] !=3D '0') || =
al[1]
!=3D '\0'))
+            ) {
+             fprintf(stderr, "Malformed ioport specification!\n");
+             free(buf2);
+             exit(1);
+          }
+          if(al !=3D NULL) {
+             ioport->allow =3D al[0] - '0';
+          } else {
+             ioport->allow =3D 1;
+          }
+
+          free(buf2);
+          d_config->num_ioports++;
+       }
+    }
+
+
+
     switch (xlu_cfg_get_list(config, "cpuid", &cpuids, 0, 1)) {
     case 0:
         {


--------------ms030107040307060301080107
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIDyjCC
A8YwggMvoAMCAQICBD/xyf0wDQYJKoZIhvcNAQEFBQAwLzELMAkGA1UEBhMCVVMxDzANBgNV
BAoTBkpIVUFQTDEPMA0GA1UECxMGQklTRENBMB4XDTEwMDYxMTE4MjIwNloXDTEzMDYxMTE4
NTIwNlowZjELMAkGA1UEBhMCVVMxDzANBgNVBAoTBkpIVUFQTDEPMA0GA1UECxMGUGVvcGxl
MTUwFgYDVQQLEw9WUE5Hcm91cC1CSVNEQ0EwGwYDVQQDExRNYXR0aGV3IEUgRmlvcmF2YW50
ZTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAnpbwVSP6o1Nb5lcW7dd3yTo9iBJdi7qz
4nANOMFPK7JOy5npKN1iiousl28U/scUJES55gPwAWYJK3uVyQAsA4adgDKi5DoD1UHDQEwp
bY7iHLJeq0NPr4BqYNqnCFPbE6HC8zSJrr4qKn+gVUQT39SIFqdiIPJwZL8FYTRQ/zsCAwEA
AaOCAbYwggGyMAsGA1UdDwQEAwIHgDArBgNVHRAEJDAigA8yMDEwMDYxMTE4MjIwNlqBDzIw
MTIwNzE3MjI1MjA2WjAbBg0rBgEEAbMlCwMBAQEBBAoWCGZpb3JhbWUxMBsGDSsGAQQBsyUL
AwEBAQIEChIIMDAxMDQyNjEwWAYJYIZIAYb6ax4BBEsMSVRoZSBwcml2YXRlIGtleSBjb3Jy
ZXNwb25kaW5nIHRvIHRoaXMgY2VydGlmaWNhdGUgbWF5IGhhdmUgYmVlbiBleHBvcnRlZC4w
KAYDVR0RBCEwH4EdTWF0dGhldy5GaW9yYXZhbnRlQGpodWFwbC5lZHUwUgYDVR0fBEswSTBH
oEWgQ6RBMD8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJU0RD
QTEOMAwGA1UEAxMFQ1JMNTYwHwYDVR0jBBgwFoAUCDUpmxH52EU2CyWmF2EJMB1yqeswHQYD
VR0OBBYEFO6LYxg6r9wHZ+zdQtBHn1dZ/YTNMAkGA1UdEwQCMAAwGQYJKoZIhvZ9B0EABAww
ChsEVjcuMQMCBLAwDQYJKoZIhvcNAQEFBQADgYEAJO9HQh4YNChVLzuZqK5ARJARD8JoujGZ
fdo75quvg2jXFQe2sEjvLnxJZgm/pv8fdZakq48CWwjYHKuvIp7sDjTEsQfo+y7SpN/N2NvJ
WU5SqfK1VgYtNLRRoGJUB5Q1aZ+Dg95g3kqpyfpUMISJL8IKVLtJVfN4fggFVUYZ9wwxggGr
MIIBpwIBATA3MC8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJ
U0RDQQIEP/HJ/TAJBgUrDgMCGgUAoIHLMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ
KoZIhvcNAQkFMQ8XDTEyMDkxODE4MjAyNFowIwYJKoZIhvcNAQkEMRYEFBpXw9v2ViamU4mY
DWVSuKTByG06MGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAK
BggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI
KoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEgYAcfWMA2E4AFGQ3WJZDQzs5LpNzDXXlMd2X
MKuP3BIurKMPcfHKu/qctdRV34CtsWO7pBJeFMKClI2IFUnorjjWdylWOD0aPcFf1+4DWY4d
vDROG0UCmo5xpqntwZiSIJVYdvUKn9nw2YlYz9EERLn39Z0ynz7F6p8Y3a9B0BuJCgAAAAAA
AA==
--------------ms030107040307060301080107--


--===============5776196528701638710==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============5776196528701638710==--


From xen-devel-bounces@lists.xen.org Tue Sep 18 18:22:02 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Sep 2012 18: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 1TE2Qi-0000A0-3p; Tue, 18 Sep 2012 18:21:52 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <matthew.fioravante@jhuapl.edu>) id 1TE2Qg-00009r-QY
	for xen-devel@lists.xensource.com; Tue, 18 Sep 2012 18:21:51 +0000
Received: from [85.158.143.35:11709] by server-2.bemta-4.messagelabs.com id
	21/67-06610-EBBB8505; Tue, 18 Sep 2012 18:21:50 +0000
X-Env-Sender: matthew.fioravante@jhuapl.edu
X-Msg-Ref: server-13.tower-21.messagelabs.com!1347992506!17467242!1
X-Originating-IP: [128.244.251.36]
X-SpamReason: No, hits=0.0 required=7.0 tests=UNPARSEABLE_RELAY
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3830 invoked from network); 18 Sep 2012 18:21:47 -0000
Received: from pilot.jhuapl.edu (HELO jhuapl.edu) (128.244.251.36)
	by server-13.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 18 Sep 2012 18:21:47 -0000
Received: from ([128.244.207.89])
	by pilot.jhuapl.edu with ESMTP with TLS id 63GHCH1.153151636;
	Tue, 18 Sep 2012 14:21:39 -0400
Message-ID: <5058BB68.5090504@jhuapl.edu>
Date: Tue, 18 Sep 2012 14:20:24 -0400
From: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120827 Thunderbird/15.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>, 
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
X-Enigmail-Version: 1.4.4
Subject: [Xen-devel] [PATCH xm/xl enhancements for vptm 5/6] add ioport
	support to libxl
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============5776196528701638710=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a cryptographically signed message in MIME format.

--===============5776196528701638710==
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms030107040307060301080107"

This is a cryptographically signed message in MIME format.

--------------ms030107040307060301080107
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

This patch adds support for mapping ioports to vms using xl, similar to
the function in xm.

Signed of by Matthew Fioravante matthew.fioravante@jhuapl.edu

diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -477,7 +477,7 @@ typedef struct {
     libxl_domain_create_info c_info;
     libxl_domain_build_info b_info;
=20
-    int num_disks, num_vifs, num_pcidevs, num_vfbs, num_vkbs,
num_vtpms, num_iorngs, num_irqs;
+    int num_disks, num_vifs, num_pcidevs, num_vfbs, num_vkbs,
num_vtpms, num_iorngs, num_irqs, num_ioports;
=20
     libxl_device_disk *disks;
     libxl_device_nic *vifs;
@@ -487,6 +487,7 @@ typedef struct {
     libxl_device_vtpm *vtpms;
     libxl_iomem_range *iorngs;
     libxl_irq         *irqs;
+    libxl_ioport_range *ioports;
=20
     libxl_action_on_shutdown on_poweroff;
     libxl_action_on_shutdown on_reboot;
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
@@ -66,6 +66,10 @@ void libxl_domain_config_dispose(libxl_domain_config
*d_config)
        libxl_irq_dispose(&d_config->irqs[i]);
     free(d_config->irqs);
=20
+    for (i=3D0; i<d_config->num_ioports; i++)
+       libxl_ioport_range_dispose(&d_config->ioports[i]);
+    free(d_config->ioports);
+
     libxl_domain_create_info_dispose(&d_config->c_info);
     libxl_domain_build_info_dispose(&d_config->b_info);
 }
@@ -744,6 +748,16 @@ static void domcreate_bootloader_done(libxl__egc *eg=
c,
             goto error_out;
         }
     }
+    for (i =3D 0; i < d_config->num_ioports; i++) {
+       printf("PORT %d %d %d\n", d_config->ioports[i].start,
d_config->ioports[i].nr_ports, d_config->ioports[i].allow);
+        ret =3D xc_domain_ioport_permission(ctx->xch, domid,
d_config->ioports[i].start, d_config->ioports[i].nr_ports,
d_config->ioports[i].allow);
+        if (ret) {
+            LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
+                       "cannot add ioport %d to domain: %d", i, ret);
+            ret =3D ERROR_FAIL;
+            goto error_out;
+        }
+    }
     for (i =3D 0; i < d_config->num_disks; i++) {
         ret =3D libxl_device_disk_add(ctx, domid, &d_config->disks[i]);
         if (ret) {
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
@@ -328,6 +328,13 @@ libxl_irq =3D Struct("irq", [
     ("allow", bool),
 ])
=20
+libxl_ioport_range =3D Struct("ioport_range", [
+    ("start", uint32),
+    ("nr_ports", uint32),
+    ("allow", bool),
+]);
+
+
 libxl_device_vfb =3D Struct("device_vfb", [
     ("backend_domid", libxl_domid),
     ("devid",         libxl_devid),
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
@@ -560,7 +560,7 @@ static void parse_config_data(const char *config_sour=
ce,
     const char *buf;
     long l;
     XLU_Config *config;
-    XLU_ConfigList *cpus, *vbds, *nics, *pcis, *cvfbs, *cpuids, *vtpms,
*iomems, *irqs;
+    XLU_ConfigList *cpus, *vbds, *nics, *pcis, *cvfbs, *cpuids, *vtpms,
*iomems, *irqs, *ioports;
     int pci_power_mgmt =3D 0;
     int pci_msitranslate =3D 1;
     int pci_permissive =3D 0;
@@ -1214,6 +1214,44 @@ skip_vfb:
        }
     }
=20
+    if(!xlu_cfg_get_list(config, "ioport", &ioports, 0, 0)) {
+       int i;
+       for(i =3D0; (buf =3D xlu_cfg_get_listitem(ioports, i)) !=3D NULL;=
 ++i) {
+          libxl_ioport_range* ioport;
+          char* buf2 =3D strdup(buf);
+          char *st, *len, *al;
+
+          d_config->ioports =3D realloc(d_config->ioports,
sizeof(libxl_ioport_range) * (d_config->num_ioports + 1));
+          ioport =3D d_config->ioports + d_config->num_ioports;
+
+          libxl_ioport_range_init(ioport);
+
+          st =3D strtok(buf2, ",");
+          len =3D strtok(NULL, ",");
+          al =3D strtok(NULL, ",");
+
+          if(st =3D=3D NULL || len =3D=3D NULL ||
+                sscanf(st, "%" PRIu32, &ioport->start) !=3D 1 ||
+                sscanf(len, "%" PRIu32, &ioport->nr_ports) !=3D 1 ||
+                (al !=3D NULL && ((al[0] !=3D '1' && al[0] !=3D '0') || =
al[1]
!=3D '\0'))
+            ) {
+             fprintf(stderr, "Malformed ioport specification!\n");
+             free(buf2);
+             exit(1);
+          }
+          if(al !=3D NULL) {
+             ioport->allow =3D al[0] - '0';
+          } else {
+             ioport->allow =3D 1;
+          }
+
+          free(buf2);
+          d_config->num_ioports++;
+       }
+    }
+
+
+
     switch (xlu_cfg_get_list(config, "cpuid", &cpuids, 0, 1)) {
     case 0:
         {


--------------ms030107040307060301080107
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIDyjCC
A8YwggMvoAMCAQICBD/xyf0wDQYJKoZIhvcNAQEFBQAwLzELMAkGA1UEBhMCVVMxDzANBgNV
BAoTBkpIVUFQTDEPMA0GA1UECxMGQklTRENBMB4XDTEwMDYxMTE4MjIwNloXDTEzMDYxMTE4
NTIwNlowZjELMAkGA1UEBhMCVVMxDzANBgNVBAoTBkpIVUFQTDEPMA0GA1UECxMGUGVvcGxl
MTUwFgYDVQQLEw9WUE5Hcm91cC1CSVNEQ0EwGwYDVQQDExRNYXR0aGV3IEUgRmlvcmF2YW50
ZTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAnpbwVSP6o1Nb5lcW7dd3yTo9iBJdi7qz
4nANOMFPK7JOy5npKN1iiousl28U/scUJES55gPwAWYJK3uVyQAsA4adgDKi5DoD1UHDQEwp
bY7iHLJeq0NPr4BqYNqnCFPbE6HC8zSJrr4qKn+gVUQT39SIFqdiIPJwZL8FYTRQ/zsCAwEA
AaOCAbYwggGyMAsGA1UdDwQEAwIHgDArBgNVHRAEJDAigA8yMDEwMDYxMTE4MjIwNlqBDzIw
MTIwNzE3MjI1MjA2WjAbBg0rBgEEAbMlCwMBAQEBBAoWCGZpb3JhbWUxMBsGDSsGAQQBsyUL
AwEBAQIEChIIMDAxMDQyNjEwWAYJYIZIAYb6ax4BBEsMSVRoZSBwcml2YXRlIGtleSBjb3Jy
ZXNwb25kaW5nIHRvIHRoaXMgY2VydGlmaWNhdGUgbWF5IGhhdmUgYmVlbiBleHBvcnRlZC4w
KAYDVR0RBCEwH4EdTWF0dGhldy5GaW9yYXZhbnRlQGpodWFwbC5lZHUwUgYDVR0fBEswSTBH
oEWgQ6RBMD8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJU0RD
QTEOMAwGA1UEAxMFQ1JMNTYwHwYDVR0jBBgwFoAUCDUpmxH52EU2CyWmF2EJMB1yqeswHQYD
VR0OBBYEFO6LYxg6r9wHZ+zdQtBHn1dZ/YTNMAkGA1UdEwQCMAAwGQYJKoZIhvZ9B0EABAww
ChsEVjcuMQMCBLAwDQYJKoZIhvcNAQEFBQADgYEAJO9HQh4YNChVLzuZqK5ARJARD8JoujGZ
fdo75quvg2jXFQe2sEjvLnxJZgm/pv8fdZakq48CWwjYHKuvIp7sDjTEsQfo+y7SpN/N2NvJ
WU5SqfK1VgYtNLRRoGJUB5Q1aZ+Dg95g3kqpyfpUMISJL8IKVLtJVfN4fggFVUYZ9wwxggGr
MIIBpwIBATA3MC8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJ
U0RDQQIEP/HJ/TAJBgUrDgMCGgUAoIHLMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ
KoZIhvcNAQkFMQ8XDTEyMDkxODE4MjAyNFowIwYJKoZIhvcNAQkEMRYEFBpXw9v2ViamU4mY
DWVSuKTByG06MGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAK
BggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI
KoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEgYAcfWMA2E4AFGQ3WJZDQzs5LpNzDXXlMd2X
MKuP3BIurKMPcfHKu/qctdRV34CtsWO7pBJeFMKClI2IFUnorjjWdylWOD0aPcFf1+4DWY4d
vDROG0UCmo5xpqntwZiSIJVYdvUKn9nw2YlYz9EERLn39Z0ynz7F6p8Y3a9B0BuJCgAAAAAA
AA==
--------------ms030107040307060301080107--


--===============5776196528701638710==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============5776196528701638710==--


From xen-devel-bounces@lists.xen.org Tue Sep 18 18:24:09 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Sep 2012 18:24:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TE2Sj-0000I2-Lo; Tue, 18 Sep 2012 18:23:57 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <matthew.fioravante@jhuapl.edu>) id 1TE2Sh-0000Hr-4x
	for xen-devel@lists.xensource.com; Tue, 18 Sep 2012 18:23:55 +0000
Received: from [85.158.137.99:58009] by server-10.bemta-3.messagelabs.com id
	A7/A4-10411-A3CB8505; Tue, 18 Sep 2012 18:23:54 +0000
X-Env-Sender: matthew.fioravante@jhuapl.edu
X-Msg-Ref: server-15.tower-217.messagelabs.com!1347992632!15836609!1
X-Originating-IP: [128.244.251.36]
X-SpamReason: No, hits=0.0 required=7.0 tests=UNPARSEABLE_RELAY
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7952 invoked from network); 18 Sep 2012 18:23:53 -0000
Received: from pilot.jhuapl.edu (HELO jhuapl.edu) (128.244.251.36)
	by server-15.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 18 Sep 2012 18:23:53 -0000
Received: from ([128.244.207.89])
	by pilot.jhuapl.edu with ESMTP with TLS id 63GHCH1.153151914;
	Tue, 18 Sep 2012 14:23:47 -0400
Message-ID: <5058BBE7.8070607@jhuapl.edu>
Date: Tue, 18 Sep 2012 14:22:31 -0400
From: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120827 Thunderbird/15.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>, 
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
X-Enigmail-Version: 1.4.4
Subject: [Xen-devel] [PATCH xm/xl enhancements for vptm 6/6] add iomem
	feature to xm
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============2883952936382868964=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a cryptographically signed message in MIME format.

--===============2883952936382868964==
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms040300050604030608050805"

This is a cryptographically signed message in MIME format.

--------------ms040300050604030608050805
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

This adds the iomem feature from patch 3 to xm as well.


Signed off by Matthew Fioravante matthew.fioravante@jhuapl.edu

diff --git a/tools/python/xen/xend/XendDevices.py
b/tools/python/xen/xend/XendDevices.py
--- a/tools/python/xen/xend/XendDevices.py
+++ b/tools/python/xen/xend/XendDevices.py
@@ -19,7 +19,7 @@
 # A collection of DevControllers
 #
=20
-from xen.xend.server import blkif, netif, tpmif, pciif, iopif, irqif,
vfbif, vscsiif, netif2, vusbif
+from xen.xend.server import blkif, netif, tpmif, pciif, iopif, irqif,
iomemif, vfbif, vscsiif, netif2, vusbif
 from xen.xend.server.BlktapController import BlktapController,
Blktap2Controller
 from xen.xend.server.ConsoleController import ConsoleController
=20
@@ -42,6 +42,7 @@ class XendDevices:
         'pci': pciif.PciController,
         'ioports': iopif.IOPortsController,
         'irq': irqif.IRQController,
+        'iomem': iomemif.IOMEMController,
         'tap': BlktapController,
         'tap2': Blktap2Controller,
         'vfb': vfbif.VfbifController,
diff --git a/tools/python/xen/xend/server/iomemif.py
b/tools/python/xen/xend/server/iomemif.py
--- /dev/null
+++ b/tools/python/xen/xend/server/iomemif.py
@@ -0,0 +1,103 @@
+#=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
+# 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 Pub=
lic
+# License as published by the Free Software Foundation.
+#
+# 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., 59 Temple Place, Suite 330, Boston, MA  02111-1307  =
USA
+#=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
+# Copyright (C) 2004, 2005 Mike Wray <mike.wray@hp.com>
+# Copyright (C) 2005 XenSource Ltd
+# Copyright (C) 2005 Jody Belka
+#=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
+
+
+import types
+
+import xen.lowlevel.xc
+
+from xen.xend.XendError import VmError
+
+from xen.xend.server.DevController import DevController
+
+
+xc =3D xen.lowlevel.xc.xc()
+
+
+def parse_iomemaddr(val):
+    """Parse an iomem address
+    """
+    if isinstance(val, types.StringType):
+        radix =3D 10
+        if val.startswith('0x') or val.startswith('0X'):
+            radix =3D 16
+        v =3D int(val, radix)
+    else:
+        v =3D val
+    return v
+
+
+class IOMEMController(DevController):
+
+    valid_cfg =3D ['mfn', 'nmfns', 'enable']
+
+    def __init__(self, vm):
+        DevController.__init__(self, vm)
+
+    def getDeviceConfiguration(self, devid, transaction =3D None):
+        result =3D DevController.getDeviceConfiguration(self, devid,
transaction)
+        if transaction is None:
+            devinfo =3D self.readBackend(devid, *self.valid_cfg)
+        else:
+            devinfo =3D self.readBackendTxn(transaction, devid,
*self.valid_cfg)
+        config =3D dict(zip(self.valid_cfg, devinfo))
+        config =3D dict([(key, val) for key, val in config.items()
+                       if val !=3D None])
+        return config
+
+    def getDeviceDetails(self, config):
+        """@see DevController.getDeviceDetails"""
+
+        def get_param(field):
+            try:
+                val =3D config.get(field)
+
+                if not val:
+                    raise VmError('iomem: Missing %s config setting' %
field)
+
+                return parse_iomemaddr(val)
+            except:
+                raise VmError('iomem: Invalid config setting %s: %s' %
+                              (field, val))
+     =20
+        mfn =3D get_param('mfn')
+        nmfns =3D get_param('nmfns')
+        enable =3D get_param('enable')
+
+    if nmfns <=3D 0:
+        raise VmError('iomem: invalid number of mfns: %s' % str(nmfns))
+    #FIXME: Bounds check for max iomem range??
+
+        rc =3D xc.domain_iomem_permission(domid        =3D self.getDomid=
(),
+                                         first_pfn    =3D mfn,
+                     nr_pfns      =3D nmfns,
+                                         allow_access =3D enable)
+
+        if rc < 0:
+            #todo non-fatal
+            raise VmError(
+                'iomem: Failed to configure memory mapped i/o range:
%s,%s' %
+                (str(mfn), str(nmfns)))
+
+        back =3D dict([(k, config[k]) for k in self.valid_cfg if k in
config])
+        return (self.allocateDeviceID(), back, {})
+
+    def waitForDevice(self, devid):
+        # don't wait for hotplug
+        return
diff --git a/tools/python/xen/xm/create.py b/tools/python/xen/xm/create.p=
y
--- a/tools/python/xen/xm/create.py
+++ b/tools/python/xen/xm/create.py
@@ -378,6 +378,14 @@ gopts.var('irq', val=3D'IRQ',
          For example 'irq=3D7'.
          This option may be repeated to add more than one IRQ.""")
=20
+gopts.var('iomem', val=3D'MFN,NMFNS,ENABLE',
+          fn=3Dappend_value, default=3D[],
+          use=3D"""Allow access to memory mapped IO pages, using the
given params.
+     For example 'iomem=3De4df0,5,1', to allow access to 5 pages startin=
g
+     at page number 0xe4df0. The first arg is in hex, the second in
decimal.
+         The last argument is a 1 or 0, to either enable or disable the
memory region.
+     This option may be repeated to add more than one memory range""")
+
 gopts.var('vfb',
val=3D"vnc=3D1,sdl=3D1,vncunused=3D1,vncdisplay=3DN,vnclisten=3DADDR,disp=
lay=3DDISPLAY,xauthority=3DXAUTHORITY,vncpasswd=3DPASSWORD,opengl=3D1,key=
map=3DFILE,serial=3DFILE,monitor=3DFILE",
           fn=3Dappend_value, default=3D[],
           use=3D"""Make the domain a framebuffer backend.
@@ -947,6 +955,13 @@ def configure_irq(config_devs, vals):
         config_irq =3D ['irq', ['irq', irq]]
         config_devs.append(['device', config_irq])
=20
+def configure_iomem(config_devs, vals):
+    """Create the config for iomem.
+    """
+    for (mfn, nmfns, enable) in vals.iomem:
+        config_iomem =3D ['iomem', ['mfn', mfn], ['nmfns', nmfns],
['enable', enable]]
+    config_devs.append(['device', config_iomem])
+
 def configure_vfbs(config_devs, vals):
     for f in vals.vfb:
         d =3D comma_sep_kv_to_dict(f)
@@ -1191,6 +1206,7 @@ def make_config(vals):
     configure_vscsis(config_devs, vals)
     configure_vusbs(config_devs, vals)
     configure_ioports(config_devs, vals)
+    configure_iomem(config_devs, vals)
     configure_irq(config_devs, vals)
     configure_vifs(config_devs, vals)
     configure_vtpm(config_devs, vals)
@@ -1307,6 +1323,18 @@ def preprocess_irq(vals):
         irq.append(d)
     vals.irq =3D irq
=20
+def preprocess_iomem(vals):
+    if not vals.iomem: return
+    iomem =3D []
+    for v in vals.iomem:
+        d =3D v.split(',')
+    if len(d) < 1 or len(d) > 3:
+       err('Invalid iomem range specifier: ' + v)
+    #Add hex specifier to the page number
+    d[0] =3D '0x' + d[0]
+    iomem.append(d)
+    vals.iomem =3D iomem
+
 def preprocess_vtpm(vals):
     if not vals.vtpm: return
     vtpms =3D []
@@ -1398,6 +1426,7 @@ def preprocess(vals):
     preprocess_pci(vals)
     preprocess_vscsi(vals)
     preprocess_ioports(vals)
+    preprocess_iomem(vals)
     preprocess_ip(vals)
     preprocess_irq(vals)
     preprocess_nfs(vals)



--------------ms040300050604030608050805
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIDyjCC
A8YwggMvoAMCAQICBD/xyf0wDQYJKoZIhvcNAQEFBQAwLzELMAkGA1UEBhMCVVMxDzANBgNV
BAoTBkpIVUFQTDEPMA0GA1UECxMGQklTRENBMB4XDTEwMDYxMTE4MjIwNloXDTEzMDYxMTE4
NTIwNlowZjELMAkGA1UEBhMCVVMxDzANBgNVBAoTBkpIVUFQTDEPMA0GA1UECxMGUGVvcGxl
MTUwFgYDVQQLEw9WUE5Hcm91cC1CSVNEQ0EwGwYDVQQDExRNYXR0aGV3IEUgRmlvcmF2YW50
ZTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAnpbwVSP6o1Nb5lcW7dd3yTo9iBJdi7qz
4nANOMFPK7JOy5npKN1iiousl28U/scUJES55gPwAWYJK3uVyQAsA4adgDKi5DoD1UHDQEwp
bY7iHLJeq0NPr4BqYNqnCFPbE6HC8zSJrr4qKn+gVUQT39SIFqdiIPJwZL8FYTRQ/zsCAwEA
AaOCAbYwggGyMAsGA1UdDwQEAwIHgDArBgNVHRAEJDAigA8yMDEwMDYxMTE4MjIwNlqBDzIw
MTIwNzE3MjI1MjA2WjAbBg0rBgEEAbMlCwMBAQEBBAoWCGZpb3JhbWUxMBsGDSsGAQQBsyUL
AwEBAQIEChIIMDAxMDQyNjEwWAYJYIZIAYb6ax4BBEsMSVRoZSBwcml2YXRlIGtleSBjb3Jy
ZXNwb25kaW5nIHRvIHRoaXMgY2VydGlmaWNhdGUgbWF5IGhhdmUgYmVlbiBleHBvcnRlZC4w
KAYDVR0RBCEwH4EdTWF0dGhldy5GaW9yYXZhbnRlQGpodWFwbC5lZHUwUgYDVR0fBEswSTBH
oEWgQ6RBMD8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJU0RD
QTEOMAwGA1UEAxMFQ1JMNTYwHwYDVR0jBBgwFoAUCDUpmxH52EU2CyWmF2EJMB1yqeswHQYD
VR0OBBYEFO6LYxg6r9wHZ+zdQtBHn1dZ/YTNMAkGA1UdEwQCMAAwGQYJKoZIhvZ9B0EABAww
ChsEVjcuMQMCBLAwDQYJKoZIhvcNAQEFBQADgYEAJO9HQh4YNChVLzuZqK5ARJARD8JoujGZ
fdo75quvg2jXFQe2sEjvLnxJZgm/pv8fdZakq48CWwjYHKuvIp7sDjTEsQfo+y7SpN/N2NvJ
WU5SqfK1VgYtNLRRoGJUB5Q1aZ+Dg95g3kqpyfpUMISJL8IKVLtJVfN4fggFVUYZ9wwxggGr
MIIBpwIBATA3MC8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJ
U0RDQQIEP/HJ/TAJBgUrDgMCGgUAoIHLMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ
KoZIhvcNAQkFMQ8XDTEyMDkxODE4MjIzMVowIwYJKoZIhvcNAQkEMRYEFCX98tEn/Coqoknr
//5yklzmabFCMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAK
BggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI
KoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEgYBjFHETcM6k1Pwsr8rtdUCCFAMa+5eDDey0
xMUwjEgkQ1g48eudouoTWNqHpA4ll3ZKcXkO2drX7IVPRNO196Zh0uypG2I1cNSUxXPY7egE
kiygev3jrOcDb3/oYlLzNjnBEGyS5I0/Xxa9w0zIHYTkGOM6QzfxFy99Ne0/le/POwAAAAAA
AA==
--------------ms040300050604030608050805--


--===============2883952936382868964==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============2883952936382868964==--


From xen-devel-bounces@lists.xen.org Tue Sep 18 18:24:09 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Sep 2012 18:24:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TE2Sj-0000I2-Lo; Tue, 18 Sep 2012 18:23:57 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <matthew.fioravante@jhuapl.edu>) id 1TE2Sh-0000Hr-4x
	for xen-devel@lists.xensource.com; Tue, 18 Sep 2012 18:23:55 +0000
Received: from [85.158.137.99:58009] by server-10.bemta-3.messagelabs.com id
	A7/A4-10411-A3CB8505; Tue, 18 Sep 2012 18:23:54 +0000
X-Env-Sender: matthew.fioravante@jhuapl.edu
X-Msg-Ref: server-15.tower-217.messagelabs.com!1347992632!15836609!1
X-Originating-IP: [128.244.251.36]
X-SpamReason: No, hits=0.0 required=7.0 tests=UNPARSEABLE_RELAY
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7952 invoked from network); 18 Sep 2012 18:23:53 -0000
Received: from pilot.jhuapl.edu (HELO jhuapl.edu) (128.244.251.36)
	by server-15.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 18 Sep 2012 18:23:53 -0000
Received: from ([128.244.207.89])
	by pilot.jhuapl.edu with ESMTP with TLS id 63GHCH1.153151914;
	Tue, 18 Sep 2012 14:23:47 -0400
Message-ID: <5058BBE7.8070607@jhuapl.edu>
Date: Tue, 18 Sep 2012 14:22:31 -0400
From: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120827 Thunderbird/15.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>, 
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
X-Enigmail-Version: 1.4.4
Subject: [Xen-devel] [PATCH xm/xl enhancements for vptm 6/6] add iomem
	feature to xm
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============2883952936382868964=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a cryptographically signed message in MIME format.

--===============2883952936382868964==
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms040300050604030608050805"

This is a cryptographically signed message in MIME format.

--------------ms040300050604030608050805
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

This adds the iomem feature from patch 3 to xm as well.


Signed off by Matthew Fioravante matthew.fioravante@jhuapl.edu

diff --git a/tools/python/xen/xend/XendDevices.py
b/tools/python/xen/xend/XendDevices.py
--- a/tools/python/xen/xend/XendDevices.py
+++ b/tools/python/xen/xend/XendDevices.py
@@ -19,7 +19,7 @@
 # A collection of DevControllers
 #
=20
-from xen.xend.server import blkif, netif, tpmif, pciif, iopif, irqif,
vfbif, vscsiif, netif2, vusbif
+from xen.xend.server import blkif, netif, tpmif, pciif, iopif, irqif,
iomemif, vfbif, vscsiif, netif2, vusbif
 from xen.xend.server.BlktapController import BlktapController,
Blktap2Controller
 from xen.xend.server.ConsoleController import ConsoleController
=20
@@ -42,6 +42,7 @@ class XendDevices:
         'pci': pciif.PciController,
         'ioports': iopif.IOPortsController,
         'irq': irqif.IRQController,
+        'iomem': iomemif.IOMEMController,
         'tap': BlktapController,
         'tap2': Blktap2Controller,
         'vfb': vfbif.VfbifController,
diff --git a/tools/python/xen/xend/server/iomemif.py
b/tools/python/xen/xend/server/iomemif.py
--- /dev/null
+++ b/tools/python/xen/xend/server/iomemif.py
@@ -0,0 +1,103 @@
+#=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
+# 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 Pub=
lic
+# License as published by the Free Software Foundation.
+#
+# 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., 59 Temple Place, Suite 330, Boston, MA  02111-1307  =
USA
+#=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
+# Copyright (C) 2004, 2005 Mike Wray <mike.wray@hp.com>
+# Copyright (C) 2005 XenSource Ltd
+# Copyright (C) 2005 Jody Belka
+#=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
+
+
+import types
+
+import xen.lowlevel.xc
+
+from xen.xend.XendError import VmError
+
+from xen.xend.server.DevController import DevController
+
+
+xc =3D xen.lowlevel.xc.xc()
+
+
+def parse_iomemaddr(val):
+    """Parse an iomem address
+    """
+    if isinstance(val, types.StringType):
+        radix =3D 10
+        if val.startswith('0x') or val.startswith('0X'):
+            radix =3D 16
+        v =3D int(val, radix)
+    else:
+        v =3D val
+    return v
+
+
+class IOMEMController(DevController):
+
+    valid_cfg =3D ['mfn', 'nmfns', 'enable']
+
+    def __init__(self, vm):
+        DevController.__init__(self, vm)
+
+    def getDeviceConfiguration(self, devid, transaction =3D None):
+        result =3D DevController.getDeviceConfiguration(self, devid,
transaction)
+        if transaction is None:
+            devinfo =3D self.readBackend(devid, *self.valid_cfg)
+        else:
+            devinfo =3D self.readBackendTxn(transaction, devid,
*self.valid_cfg)
+        config =3D dict(zip(self.valid_cfg, devinfo))
+        config =3D dict([(key, val) for key, val in config.items()
+                       if val !=3D None])
+        return config
+
+    def getDeviceDetails(self, config):
+        """@see DevController.getDeviceDetails"""
+
+        def get_param(field):
+            try:
+                val =3D config.get(field)
+
+                if not val:
+                    raise VmError('iomem: Missing %s config setting' %
field)
+
+                return parse_iomemaddr(val)
+            except:
+                raise VmError('iomem: Invalid config setting %s: %s' %
+                              (field, val))
+     =20
+        mfn =3D get_param('mfn')
+        nmfns =3D get_param('nmfns')
+        enable =3D get_param('enable')
+
+    if nmfns <=3D 0:
+        raise VmError('iomem: invalid number of mfns: %s' % str(nmfns))
+    #FIXME: Bounds check for max iomem range??
+
+        rc =3D xc.domain_iomem_permission(domid        =3D self.getDomid=
(),
+                                         first_pfn    =3D mfn,
+                     nr_pfns      =3D nmfns,
+                                         allow_access =3D enable)
+
+        if rc < 0:
+            #todo non-fatal
+            raise VmError(
+                'iomem: Failed to configure memory mapped i/o range:
%s,%s' %
+                (str(mfn), str(nmfns)))
+
+        back =3D dict([(k, config[k]) for k in self.valid_cfg if k in
config])
+        return (self.allocateDeviceID(), back, {})
+
+    def waitForDevice(self, devid):
+        # don't wait for hotplug
+        return
diff --git a/tools/python/xen/xm/create.py b/tools/python/xen/xm/create.p=
y
--- a/tools/python/xen/xm/create.py
+++ b/tools/python/xen/xm/create.py
@@ -378,6 +378,14 @@ gopts.var('irq', val=3D'IRQ',
          For example 'irq=3D7'.
          This option may be repeated to add more than one IRQ.""")
=20
+gopts.var('iomem', val=3D'MFN,NMFNS,ENABLE',
+          fn=3Dappend_value, default=3D[],
+          use=3D"""Allow access to memory mapped IO pages, using the
given params.
+     For example 'iomem=3De4df0,5,1', to allow access to 5 pages startin=
g
+     at page number 0xe4df0. The first arg is in hex, the second in
decimal.
+         The last argument is a 1 or 0, to either enable or disable the
memory region.
+     This option may be repeated to add more than one memory range""")
+
 gopts.var('vfb',
val=3D"vnc=3D1,sdl=3D1,vncunused=3D1,vncdisplay=3DN,vnclisten=3DADDR,disp=
lay=3DDISPLAY,xauthority=3DXAUTHORITY,vncpasswd=3DPASSWORD,opengl=3D1,key=
map=3DFILE,serial=3DFILE,monitor=3DFILE",
           fn=3Dappend_value, default=3D[],
           use=3D"""Make the domain a framebuffer backend.
@@ -947,6 +955,13 @@ def configure_irq(config_devs, vals):
         config_irq =3D ['irq', ['irq', irq]]
         config_devs.append(['device', config_irq])
=20
+def configure_iomem(config_devs, vals):
+    """Create the config for iomem.
+    """
+    for (mfn, nmfns, enable) in vals.iomem:
+        config_iomem =3D ['iomem', ['mfn', mfn], ['nmfns', nmfns],
['enable', enable]]
+    config_devs.append(['device', config_iomem])
+
 def configure_vfbs(config_devs, vals):
     for f in vals.vfb:
         d =3D comma_sep_kv_to_dict(f)
@@ -1191,6 +1206,7 @@ def make_config(vals):
     configure_vscsis(config_devs, vals)
     configure_vusbs(config_devs, vals)
     configure_ioports(config_devs, vals)
+    configure_iomem(config_devs, vals)
     configure_irq(config_devs, vals)
     configure_vifs(config_devs, vals)
     configure_vtpm(config_devs, vals)
@@ -1307,6 +1323,18 @@ def preprocess_irq(vals):
         irq.append(d)
     vals.irq =3D irq
=20
+def preprocess_iomem(vals):
+    if not vals.iomem: return
+    iomem =3D []
+    for v in vals.iomem:
+        d =3D v.split(',')
+    if len(d) < 1 or len(d) > 3:
+       err('Invalid iomem range specifier: ' + v)
+    #Add hex specifier to the page number
+    d[0] =3D '0x' + d[0]
+    iomem.append(d)
+    vals.iomem =3D iomem
+
 def preprocess_vtpm(vals):
     if not vals.vtpm: return
     vtpms =3D []
@@ -1398,6 +1426,7 @@ def preprocess(vals):
     preprocess_pci(vals)
     preprocess_vscsi(vals)
     preprocess_ioports(vals)
+    preprocess_iomem(vals)
     preprocess_ip(vals)
     preprocess_irq(vals)
     preprocess_nfs(vals)



--------------ms040300050604030608050805
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIDyjCC
A8YwggMvoAMCAQICBD/xyf0wDQYJKoZIhvcNAQEFBQAwLzELMAkGA1UEBhMCVVMxDzANBgNV
BAoTBkpIVUFQTDEPMA0GA1UECxMGQklTRENBMB4XDTEwMDYxMTE4MjIwNloXDTEzMDYxMTE4
NTIwNlowZjELMAkGA1UEBhMCVVMxDzANBgNVBAoTBkpIVUFQTDEPMA0GA1UECxMGUGVvcGxl
MTUwFgYDVQQLEw9WUE5Hcm91cC1CSVNEQ0EwGwYDVQQDExRNYXR0aGV3IEUgRmlvcmF2YW50
ZTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAnpbwVSP6o1Nb5lcW7dd3yTo9iBJdi7qz
4nANOMFPK7JOy5npKN1iiousl28U/scUJES55gPwAWYJK3uVyQAsA4adgDKi5DoD1UHDQEwp
bY7iHLJeq0NPr4BqYNqnCFPbE6HC8zSJrr4qKn+gVUQT39SIFqdiIPJwZL8FYTRQ/zsCAwEA
AaOCAbYwggGyMAsGA1UdDwQEAwIHgDArBgNVHRAEJDAigA8yMDEwMDYxMTE4MjIwNlqBDzIw
MTIwNzE3MjI1MjA2WjAbBg0rBgEEAbMlCwMBAQEBBAoWCGZpb3JhbWUxMBsGDSsGAQQBsyUL
AwEBAQIEChIIMDAxMDQyNjEwWAYJYIZIAYb6ax4BBEsMSVRoZSBwcml2YXRlIGtleSBjb3Jy
ZXNwb25kaW5nIHRvIHRoaXMgY2VydGlmaWNhdGUgbWF5IGhhdmUgYmVlbiBleHBvcnRlZC4w
KAYDVR0RBCEwH4EdTWF0dGhldy5GaW9yYXZhbnRlQGpodWFwbC5lZHUwUgYDVR0fBEswSTBH
oEWgQ6RBMD8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJU0RD
QTEOMAwGA1UEAxMFQ1JMNTYwHwYDVR0jBBgwFoAUCDUpmxH52EU2CyWmF2EJMB1yqeswHQYD
VR0OBBYEFO6LYxg6r9wHZ+zdQtBHn1dZ/YTNMAkGA1UdEwQCMAAwGQYJKoZIhvZ9B0EABAww
ChsEVjcuMQMCBLAwDQYJKoZIhvcNAQEFBQADgYEAJO9HQh4YNChVLzuZqK5ARJARD8JoujGZ
fdo75quvg2jXFQe2sEjvLnxJZgm/pv8fdZakq48CWwjYHKuvIp7sDjTEsQfo+y7SpN/N2NvJ
WU5SqfK1VgYtNLRRoGJUB5Q1aZ+Dg95g3kqpyfpUMISJL8IKVLtJVfN4fggFVUYZ9wwxggGr
MIIBpwIBATA3MC8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJ
U0RDQQIEP/HJ/TAJBgUrDgMCGgUAoIHLMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ
KoZIhvcNAQkFMQ8XDTEyMDkxODE4MjIzMVowIwYJKoZIhvcNAQkEMRYEFCX98tEn/Coqoknr
//5yklzmabFCMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAK
BggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI
KoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEgYBjFHETcM6k1Pwsr8rtdUCCFAMa+5eDDey0
xMUwjEgkQ1g48eudouoTWNqHpA4ll3ZKcXkO2drX7IVPRNO196Zh0uypG2I1cNSUxXPY7egE
kiygev3jrOcDb3/oYlLzNjnBEGyS5I0/Xxa9w0zIHYTkGOM6QzfxFy99Ne0/le/POwAAAAAA
AA==
--------------ms040300050604030608050805--


--===============2883952936382868964==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============2883952936382868964==--


From xen-devel-bounces@lists.xen.org Tue Sep 18 18:25:52 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Sep 2012 18: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 1TE2UR-0000SA-GH; Tue, 18 Sep 2012 18:25:43 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <matthew.fioravante@jhuapl.edu>) id 1TE2UQ-0000S0-JE
	for xen-devel@lists.xensource.com; Tue, 18 Sep 2012 18:25:42 +0000
Received: from [85.158.138.51:43667] by server-6.bemta-3.messagelabs.com id
	F5/47-29694-5ACB8505; Tue, 18 Sep 2012 18:25:41 +0000
X-Env-Sender: matthew.fioravante@jhuapl.edu
X-Msg-Ref: server-10.tower-174.messagelabs.com!1347992738!23463812!1
X-Originating-IP: [128.244.251.36]
X-SpamReason: No, hits=0.0 required=7.0 tests=UNPARSEABLE_RELAY
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23370 invoked from network); 18 Sep 2012 18:25:39 -0000
Received: from pilot.jhuapl.edu (HELO jhuapl.edu) (128.244.251.36)
	by server-10.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 18 Sep 2012 18:25:39 -0000
Received: from ([128.244.207.89])
	by pilot.jhuapl.edu with ESMTP with TLS id 63GHCH1.153152069;
	Tue, 18 Sep 2012 14:25:22 -0400
Message-ID: <5058BC47.8070907@jhuapl.edu>
Date: Tue, 18 Sep 2012 14:24:07 -0400
From: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120827 Thunderbird/15.0
MIME-Version: 1.0
To: Samuel Thibault <samuel.thibault@ens-lyon.org>, 
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
References: <50579F53.4070302@jhuapl.edu>
	<20120917225245.GP5110@type.youpi.perso.aquilenet.fr>
In-Reply-To: <20120917225245.GP5110@type.youpi.perso.aquilenet.fr>
X-Enigmail-Version: 1.4.4
Subject: Re: [Xen-devel] [PATCH mini-os enhancements for vtpm 8/8] Add 3 tpm
 drivers to mini-os
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1967698519395305277=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a cryptographically signed message in MIME format.

--===============1967698519395305277==
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms070704060500000507080102"

This is a cryptographically signed message in MIME format.

--------------ms070704060500000507080102
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Is there anyone on the dev list that is familiar enough to review it?

I can tell you we have been using all 3 of these drivers internally for
about 2 years now without issue. All of them are basically ports of the
linux drivers to mini-os.

On 09/17/2012 06:52 PM, Samuel Thibault wrote:
> Hello,
>
> I can not review this since I don't know much about TPM, but the
> principle seems sound.
>
> Samuel



--------------ms070704060500000507080102
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIDyjCC
A8YwggMvoAMCAQICBD/xyf0wDQYJKoZIhvcNAQEFBQAwLzELMAkGA1UEBhMCVVMxDzANBgNV
BAoTBkpIVUFQTDEPMA0GA1UECxMGQklTRENBMB4XDTEwMDYxMTE4MjIwNloXDTEzMDYxMTE4
NTIwNlowZjELMAkGA1UEBhMCVVMxDzANBgNVBAoTBkpIVUFQTDEPMA0GA1UECxMGUGVvcGxl
MTUwFgYDVQQLEw9WUE5Hcm91cC1CSVNEQ0EwGwYDVQQDExRNYXR0aGV3IEUgRmlvcmF2YW50
ZTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAnpbwVSP6o1Nb5lcW7dd3yTo9iBJdi7qz
4nANOMFPK7JOy5npKN1iiousl28U/scUJES55gPwAWYJK3uVyQAsA4adgDKi5DoD1UHDQEwp
bY7iHLJeq0NPr4BqYNqnCFPbE6HC8zSJrr4qKn+gVUQT39SIFqdiIPJwZL8FYTRQ/zsCAwEA
AaOCAbYwggGyMAsGA1UdDwQEAwIHgDArBgNVHRAEJDAigA8yMDEwMDYxMTE4MjIwNlqBDzIw
MTIwNzE3MjI1MjA2WjAbBg0rBgEEAbMlCwMBAQEBBAoWCGZpb3JhbWUxMBsGDSsGAQQBsyUL
AwEBAQIEChIIMDAxMDQyNjEwWAYJYIZIAYb6ax4BBEsMSVRoZSBwcml2YXRlIGtleSBjb3Jy
ZXNwb25kaW5nIHRvIHRoaXMgY2VydGlmaWNhdGUgbWF5IGhhdmUgYmVlbiBleHBvcnRlZC4w
KAYDVR0RBCEwH4EdTWF0dGhldy5GaW9yYXZhbnRlQGpodWFwbC5lZHUwUgYDVR0fBEswSTBH
oEWgQ6RBMD8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJU0RD
QTEOMAwGA1UEAxMFQ1JMNTYwHwYDVR0jBBgwFoAUCDUpmxH52EU2CyWmF2EJMB1yqeswHQYD
VR0OBBYEFO6LYxg6r9wHZ+zdQtBHn1dZ/YTNMAkGA1UdEwQCMAAwGQYJKoZIhvZ9B0EABAww
ChsEVjcuMQMCBLAwDQYJKoZIhvcNAQEFBQADgYEAJO9HQh4YNChVLzuZqK5ARJARD8JoujGZ
fdo75quvg2jXFQe2sEjvLnxJZgm/pv8fdZakq48CWwjYHKuvIp7sDjTEsQfo+y7SpN/N2NvJ
WU5SqfK1VgYtNLRRoGJUB5Q1aZ+Dg95g3kqpyfpUMISJL8IKVLtJVfN4fggFVUYZ9wwxggGr
MIIBpwIBATA3MC8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJ
U0RDQQIEP/HJ/TAJBgUrDgMCGgUAoIHLMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ
KoZIhvcNAQkFMQ8XDTEyMDkxODE4MjQwN1owIwYJKoZIhvcNAQkEMRYEFHTvHBkNH22YDMxP
BoJAdg7E/byUMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAK
BggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI
KoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEgYB0U3u3l51ZTVadmhJknsCbPxAzKIVJZae8
Vt+TY8bnsLk1MED3RPwacjOxKXu3UldCQ9wSYsH/vlfWYa9R6pkUkQQo35pK3PnrBEwlDuY/
mAiSxmO+CY2io/dUBSjLsntLNCxePv+VZxqux4E4PPUs8q+Q0FeRKWpeZY3ijr6w9QAAAAAA
AA==
--------------ms070704060500000507080102--


--===============1967698519395305277==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============1967698519395305277==--


From xen-devel-bounces@lists.xen.org Tue Sep 18 18:25:52 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Sep 2012 18: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 1TE2UR-0000SA-GH; Tue, 18 Sep 2012 18:25:43 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <matthew.fioravante@jhuapl.edu>) id 1TE2UQ-0000S0-JE
	for xen-devel@lists.xensource.com; Tue, 18 Sep 2012 18:25:42 +0000
Received: from [85.158.138.51:43667] by server-6.bemta-3.messagelabs.com id
	F5/47-29694-5ACB8505; Tue, 18 Sep 2012 18:25:41 +0000
X-Env-Sender: matthew.fioravante@jhuapl.edu
X-Msg-Ref: server-10.tower-174.messagelabs.com!1347992738!23463812!1
X-Originating-IP: [128.244.251.36]
X-SpamReason: No, hits=0.0 required=7.0 tests=UNPARSEABLE_RELAY
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23370 invoked from network); 18 Sep 2012 18:25:39 -0000
Received: from pilot.jhuapl.edu (HELO jhuapl.edu) (128.244.251.36)
	by server-10.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 18 Sep 2012 18:25:39 -0000
Received: from ([128.244.207.89])
	by pilot.jhuapl.edu with ESMTP with TLS id 63GHCH1.153152069;
	Tue, 18 Sep 2012 14:25:22 -0400
Message-ID: <5058BC47.8070907@jhuapl.edu>
Date: Tue, 18 Sep 2012 14:24:07 -0400
From: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120827 Thunderbird/15.0
MIME-Version: 1.0
To: Samuel Thibault <samuel.thibault@ens-lyon.org>, 
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
References: <50579F53.4070302@jhuapl.edu>
	<20120917225245.GP5110@type.youpi.perso.aquilenet.fr>
In-Reply-To: <20120917225245.GP5110@type.youpi.perso.aquilenet.fr>
X-Enigmail-Version: 1.4.4
Subject: Re: [Xen-devel] [PATCH mini-os enhancements for vtpm 8/8] Add 3 tpm
 drivers to mini-os
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1967698519395305277=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a cryptographically signed message in MIME format.

--===============1967698519395305277==
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms070704060500000507080102"

This is a cryptographically signed message in MIME format.

--------------ms070704060500000507080102
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Is there anyone on the dev list that is familiar enough to review it?

I can tell you we have been using all 3 of these drivers internally for
about 2 years now without issue. All of them are basically ports of the
linux drivers to mini-os.

On 09/17/2012 06:52 PM, Samuel Thibault wrote:
> Hello,
>
> I can not review this since I don't know much about TPM, but the
> principle seems sound.
>
> Samuel



--------------ms070704060500000507080102
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIDyjCC
A8YwggMvoAMCAQICBD/xyf0wDQYJKoZIhvcNAQEFBQAwLzELMAkGA1UEBhMCVVMxDzANBgNV
BAoTBkpIVUFQTDEPMA0GA1UECxMGQklTRENBMB4XDTEwMDYxMTE4MjIwNloXDTEzMDYxMTE4
NTIwNlowZjELMAkGA1UEBhMCVVMxDzANBgNVBAoTBkpIVUFQTDEPMA0GA1UECxMGUGVvcGxl
MTUwFgYDVQQLEw9WUE5Hcm91cC1CSVNEQ0EwGwYDVQQDExRNYXR0aGV3IEUgRmlvcmF2YW50
ZTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAnpbwVSP6o1Nb5lcW7dd3yTo9iBJdi7qz
4nANOMFPK7JOy5npKN1iiousl28U/scUJES55gPwAWYJK3uVyQAsA4adgDKi5DoD1UHDQEwp
bY7iHLJeq0NPr4BqYNqnCFPbE6HC8zSJrr4qKn+gVUQT39SIFqdiIPJwZL8FYTRQ/zsCAwEA
AaOCAbYwggGyMAsGA1UdDwQEAwIHgDArBgNVHRAEJDAigA8yMDEwMDYxMTE4MjIwNlqBDzIw
MTIwNzE3MjI1MjA2WjAbBg0rBgEEAbMlCwMBAQEBBAoWCGZpb3JhbWUxMBsGDSsGAQQBsyUL
AwEBAQIEChIIMDAxMDQyNjEwWAYJYIZIAYb6ax4BBEsMSVRoZSBwcml2YXRlIGtleSBjb3Jy
ZXNwb25kaW5nIHRvIHRoaXMgY2VydGlmaWNhdGUgbWF5IGhhdmUgYmVlbiBleHBvcnRlZC4w
KAYDVR0RBCEwH4EdTWF0dGhldy5GaW9yYXZhbnRlQGpodWFwbC5lZHUwUgYDVR0fBEswSTBH
oEWgQ6RBMD8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJU0RD
QTEOMAwGA1UEAxMFQ1JMNTYwHwYDVR0jBBgwFoAUCDUpmxH52EU2CyWmF2EJMB1yqeswHQYD
VR0OBBYEFO6LYxg6r9wHZ+zdQtBHn1dZ/YTNMAkGA1UdEwQCMAAwGQYJKoZIhvZ9B0EABAww
ChsEVjcuMQMCBLAwDQYJKoZIhvcNAQEFBQADgYEAJO9HQh4YNChVLzuZqK5ARJARD8JoujGZ
fdo75quvg2jXFQe2sEjvLnxJZgm/pv8fdZakq48CWwjYHKuvIp7sDjTEsQfo+y7SpN/N2NvJ
WU5SqfK1VgYtNLRRoGJUB5Q1aZ+Dg95g3kqpyfpUMISJL8IKVLtJVfN4fggFVUYZ9wwxggGr
MIIBpwIBATA3MC8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJ
U0RDQQIEP/HJ/TAJBgUrDgMCGgUAoIHLMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ
KoZIhvcNAQkFMQ8XDTEyMDkxODE4MjQwN1owIwYJKoZIhvcNAQkEMRYEFHTvHBkNH22YDMxP
BoJAdg7E/byUMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAK
BggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI
KoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEgYB0U3u3l51ZTVadmhJknsCbPxAzKIVJZae8
Vt+TY8bnsLk1MED3RPwacjOxKXu3UldCQ9wSYsH/vlfWYa9R6pkUkQQo35pK3PnrBEwlDuY/
mAiSxmO+CY2io/dUBSjLsntLNCxePv+VZxqux4E4PPUs8q+Q0FeRKWpeZY3ijr6w9QAAAAAA
AA==
--------------ms070704060500000507080102--


--===============1967698519395305277==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============1967698519395305277==--


From xen-devel-bounces@lists.xen.org Tue Sep 18 18:27:06 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Sep 2012 18:27:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TE2Vd-0000ZZ-Vy; Tue, 18 Sep 2012 18:26:57 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jmarcet@gmail.com>) id 1TE2Vc-0000ZM-Do
	for xen-devel@lists.xen.org; Tue, 18 Sep 2012 18:26:56 +0000
Received: from [85.158.139.83:18085] by server-6.bemta-5.messagelabs.com id
	D3/BD-21336-FECB8505; Tue, 18 Sep 2012 18:26:55 +0000
X-Env-Sender: jmarcet@gmail.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1347992813!31074244!1
X-Originating-IP: [209.85.214.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-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27477 invoked from network); 18 Sep 2012 18:26:54 -0000
Received: from mail-ob0-f173.google.com (HELO mail-ob0-f173.google.com)
	(209.85.214.173)
	by server-3.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Sep 2012 18:26:54 -0000
Received: by obbta14 with SMTP id ta14so223835obb.32
	for <xen-devel@lists.xen.org>; Tue, 18 Sep 2012 11:26: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:from:date:message-id:subject:to
	:cc:content-type:content-transfer-encoding;
	bh=Yo6+/asOPD1uFB8BHEhLPBBRvnSgiZgYarYqbmShuPQ=;
	b=zqA6MVTvdziGUf8kR1o5WA14IcptiKoFU/znos+bqWa/DQj6wwZSHWOCt3dRvqhA28
	5kpWyeHy/j4LjUDxN2tMHu0pXOVMhlzEHFco8DPcHmvw+LDkfovWFfHoobF+gTmTtPiV
	KWk0m3tOwaFbHcGLgaUh1lZeqaEfS3K8bNdfjFceLXobl3IdA0IPP5SnwfgZdOF28jE9
	y7qTbXONKjsOj8/YuswJ1yG0tDbGadmfkY/SNIa52jU8tYz71QCySeYvahjzqSHbWLYI
	5ydawRUCLIie9yd6UyudHG/B15SWd8THxhPceBCA/hZENSYHeO1SV4AQUpd+jlvOQ0WZ
	J4Dg==
Received: by 10.182.174.68 with SMTP id bq4mr1045971obc.53.1347992813225; Tue,
	18 Sep 2012 11:26:53 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.60.138.225 with HTTP; Tue, 18 Sep 2012 11:26:33 -0700 (PDT)
In-Reply-To: <20120918171725.GA14462@phenom.dumpdata.com>
References: <CAAnFQG9TZj=SxYK_jxqN=M6L40vL=AZu9EM2tbEffPhkL1s8FA@mail.gmail.com>
	<CACJDEmqdqA6CE9SgLL2QCNmQH1dOX0_4OHfJfzes+G6bEkQ7FA@mail.gmail.com>
	<CAAnFQG-8Fkunv6R8+GCLAH4yQCx4-Nn0zN_Ntsf0wsh5yXeihQ@mail.gmail.com>
	<20120917142851.GB14012@phenom.dumpdata.com>
	<CAAnFQG9bUUU8OBeKxYh=O3rRrnEPb4r1bPCr-EHWHuUS8shBhA@mail.gmail.com>
	<CAAnFQG_VnZOYs3SJvO1Gc8P98kOW=6Wxc7tM_vEF8GiACgeVWg@mail.gmail.com>
	<CAAnFQG9s=Yh4od18q8xDOD7ukA4uurxCKWiLrULFkP66Zc+iPg@mail.gmail.com>
	<CAAnFQG9PuzRLSsCS8m_0VUeV+ZaCwK3zsbinxtuFBfdSihJknw@mail.gmail.com>
	<20120918171725.GA14462@phenom.dumpdata.com>
From: Javier Marcet <jmarcet@gmail.com>
Date: Tue, 18 Sep 2012 20:26:33 +0200
Message-ID: <CAAnFQG_so_XmsWPPnzLOi=0nWB8d3Xos--L8=F4NZmoJ+9rLWg@mail.gmail.com>
To: Konrad Rzeszutek Wilk <konrad@kernel.org>
Cc: Xen Devel Mailing list <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.2.0-rc4 issues with DVB tuner
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gVHVlLCBTZXAgMTgsIDIwMTIgYXQgNzoxNyBQTSwgS29ucmFkIFJ6ZXN6dXRlayBXaWxrCjxr
b25yYWRAa2VybmVsLm9yZz4gd3JvdGU6Cgo+PiBJIGhhdmUgc29tZSBuZXdzIGZyb20gdGhlIGxp
bnV4LW1lZGlhIG1haWxpbmcgbGlzdC4gVGhlcmUsIERldmluIEhlaXRtdWVsbGVyLAo+PiBzYWlk
IHRoaXM6Cj4+Cj4+ICIiIgo+PiA+IEluaXRpYWxseSBJIHRob3VnaHQgWGVuIHdvdWxkIGJlIHRo
ZSBjYXVzZSBvZiB0aGUgcHJvYmxlbSwgYnV0IGFmdGVyCj4+ID4gaGF2aW5nIHdyaXR0ZW4gb24K
Pj4gPiB0aGUgWGVuIGRldmVsb3BtZW50IG1haWxpbmcgbGlzdCBhbmQgdGFsa2VkIGFib3V0IGl0
IHdpdGggYSBjb3VwbGUKPj4gPiBkZXZlbG9wZXJzLCBpdCBpc24ndAo+PiA+IHZlcnkgY2xlYXIg
d2hlcmUgdGhlIHByb2JsZW0gaXMuIFNvIGZhciBJIGhhdmVuJ3QgYmVlbiBhYmxlIHRvIGdldCB0
aGUKPj4gPiBzbWFsbGVzdCB3YXJuaW5nCj4+ID4gb3IgZXJyb3IuCj4+Cj4+IFRoaXMgaXMgYSB2
ZXJ5IGNvbW1vbiBwcm9ibGVtIHdoZW4gYXR0ZW1wdGluZyB0byB1c2UgYW55IFBDSS9QQ0llCj4+
IHR1bmVyIHVuZGVyIGEgaHlwZXJ2aXNvci4gIEVzc2VudGlhbGx5IHRoZSBpc3N1ZSBpcyBhbGwg
b2YgdGhlCj4+IHZpcnR1YWxpemF0aW9uIHNvbHV0aW9ucyBwcm92aWRlIHZlcnkgcG9vciBpbnRl
cnJ1cHQgbGF0ZW5jeSwgd2hpY2gKPj4gcmVzdWx0cyBpbiB0aGUgZGF0YSBiZWluZyBsb3N0Lgo+
Pgo+PiBEZXZpY2VzIGRlbGl2ZXJpbmcgYSBoaWdoIGJpdHJhdGUgc3RyZWFtIG9mIGRhdGEgaW4g
cmVhbHRpbWUgYXJlIG11Y2gKPj4gbW9yZSBsaWtlbHkgZm9yIHRoaXMgcHJvYmxlbSB0byBiZSB2
aXNpYmxlIHNpbmNlIHN1Y2ggZGV2aWNlcyBoYXZlCj4+IHZlcnkgbGl0dGxlIGJ1ZmZlcmluZyAo
aXQncyBub3QgbGlrZSBhIGhhcmQgZHJpdmUgY29udHJvbGxlciB3aGVyZSBpdAo+PiBjYW4ganVz
dCBkZWxpdmVyIHRoZSBkYXRhIHNsb3dlcikuICBUaGUgcHJvYmxlbSBpcyBub3Qgc3BlY2lmaWMg
dG8gdGhlCj4+IGN4MjM4ODUgLSBwcmV0dHkgbXVjaCBhbGwgb2YgdGhlIFBDSS9QQ0llIGJyaWRn
ZXMgdXNlZCBpbiB0dW5lciBjYXJkcwo+PiB3b3JrIHRoaXMgd2F5LCBhbmQgdGhleSBjYW5ub3Qg
cmVhbGx5IGJlIGJsYW1lZCBmb3IgZXhwZWN0aW5nIHRvIHJ1bgo+PiBpbiBhbiBlbnZpcm9ubWVu
dCB3aXRoIHJlYWxseSBjcmFwcHkgaW50ZXJydXB0IGxhdGVuY3kuCj4+Cj4+IEkgd29uJ3QgZ28g
YXMgZmFyIGFzIHRvIHNheSwgImFiYW5kb24gYWxsIGhvcGUiLCBidXQgeW91J3JlIG5vdCByZWFs
bHkKPj4gbGlrZWx5IHRvIGZpbmQgYW55IGhlbHAgaW4gdGhpcyBmb3J1bS4KPj4gIiIiCj4KPiBO
b3Qgc3VyZSBhYm91dCB0aGUgaW50ZXJydXB0IGxhdGVuY3kuIElmIHlvdSBydW4gdGhpcyBsaXR0
bGUgcHJvZ3JhbQo+IGh0dHA6Ly9kYXJub2sub3JnL3hlbi9yZWFkX2ludGVycnVwdHMuYwo+IHdo
ZW4gY2FwdHVyaW5nIGluIGJvdGggZG9tMCBhbmQgaW4gYmFyZW1ldGFsIGFyZSB0aGUgcmF0ZSBh
Ym91dCB0aGUKPiBzYW1lPwo+Pgo+PiBXaGF0IEkgZG9uwrR0IHVuZGVyc3RhbmQgaXMgaG93IGdy
YXBoaWNzIHBhc3MgdGhyb3VnaCBldmVuIHdvcmtzCj4+IGFuZCBhIHR1bmVyIGNhcmQgaGFzIHBy
b2JsZW1zIGR1ZSB0byB0aGUgaW50cm9kdWNlZCBsYXRlbmNpZXMgaW4gdGhlCj4+IElSUXMuCj4K
PiBUaGUgbGF0ZW5jeSBpcyB2ZXJ5IHZlcnkgbWluaXNjdWxlLiBPbmUgY291bGQgYWN0dWFsbHkg
dmVyaWZ5IHRoYXQgdGhpcwo+IGlzIGEgcHJvYmxlbSBieSBpbnNlcnRpbmcgc2FpZCBsYXRlbmN5
IGluIHRoZSBkcml2ZXIgc28gdGhhdCB1bmRlcgo+IGJhcmVtZXRhbCB0aGUgbGF0ZW5jeSB3b3Vs
ZCBzaG93IHVwLgo+Cj4gQnV0IHRoZSBvdGhlciBpc3N1ZSBpcyB0aGF0IGlmIHRoZSBkYXRhIGlz
IGJlaW5nIGxvc3QgeW91IHdvdWxkIGF0IGxlYXN0Cj4gZ2V0IHNvbWUuIFNvIHRoZSBidWZmZXJz
IG91Z2h0IHRvIGhhdmUgInNvbWV0aGluZyIgaW4gdGhlbT8gTWF5YmUgdGhhdAo+IGRlcGVuZHMg
b24gd2hhdCBjb21wcmVzc2lvbiB5b3UgdXNlIG9uIHRoZSBjb2Rlcj8gSWYgeW91IGp1cyBkbyBZ
VVY0MjAKPiBvciB0aGUgUkdCIHZhcmlhbnRzIGFuZCBqdXN0IGRvIGEgc2ltcGxlICdjYXQgL2Rl
di92aWRlMCA+IC90bXAvZmlsZScKPiBkb2VzIHRoZSBvdXRwdXQgY29udGFpbiBhbnl0aGluZz8g
T3IgaXMganVzdCBhIGJsb2Igb2YgZW1wdHkgZGF0YT8KClRoZSBvdXRwdXQgY29udGFpbnMgZGF0
YSwgcGFydCBvZiB0aGUgbXBlZyBzdHJlYW0gd2l0aG91dCBhbnkgY29udGludWl0eS4KCj4+IERv
IHlvdSBoYXZlIGFueSBtb3JlIGluZm8gYWJvdXQgdGhpcz8KPgo+IFRoZSBvdGhlciBpc3N1ZSBj
b3VsZCBiZSByZWxhdGVkIHRvIHRoZSB2bWFsbG9jXzMyIGJlaW5nIGluIHVzYWdlCj4gYW5kIG5v
dCB1c2luZyB0aGUgRE1BIEFQSS4KPgo+IEkgcmVjYWxsIHBvc3RpbmcgYSBwYXRjaCBmb3IgdGhp
cyAuLiBBaDoKPiBodHRwOi8vbGlzdHMueGVuLm9yZy9hcmNoaXZlcy9odG1sL3hlbi1kZXZlbC8y
MDEyLTAxL21zZzAxOTI3Lmh0bWwKPgo+IFBlcmhhcHMgdGhpcyBpcyB0aGUgaXNzdWU/CgpCaW5n
byBLb25yYWQhIFRoYXQgd2FzIGl0IDopIEF0IGxlYXN0IEkgaGF2ZSBqdXN0IGFwcGxpZWQgdGhl
IHBhdGNoLApyZWJvb3RlZCB1bmRlciBYZW4gYW5kIHRoaXMgdGltZSBJIGdvdCBhIGdvb2QgZHVt
cC4KClJpZ2h0IG5vdyBJIGhhdmUgbXkgdXN1YWwgc3lzdGVtIHJ1bm5pbmcgZmxhd2xlc3NseSB1
bmRlciBYZW4uIFRpbWUgdG8KdGFrZSBhIGxvb2sgYWdhaW4gYXQgdGhlIHN1c3BlbmQvcmVzdW1l
IGlzc3VlIHdoaWNoIEkgbmVhcmx5IGhhZAp3b3JraW5nIGEgZmV3IGRheXMgYWdvLgoKVGhhbmtz
IGEgbG90IGZvciBhbGwgeW91ciBoZWxwIDopCgpQLlMuIEknbSBnb2luZyB0byBwb3N0IHRoaXMg
aW5mbyBvbiB0aGUgbGludXggbWVkaWEgbWFpbGluZyBsaXN0LgoKCi0tIApKYXZpZXIgTWFyY2V0
IDxqbWFyY2V0QGdtYWlsLmNvbT4KCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbi5v
cmcKaHR0cDovL2xpc3RzLnhlbi5vcmcveGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Tue Sep 18 18:27:06 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Sep 2012 18:27:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TE2Vd-0000ZZ-Vy; Tue, 18 Sep 2012 18:26:57 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jmarcet@gmail.com>) id 1TE2Vc-0000ZM-Do
	for xen-devel@lists.xen.org; Tue, 18 Sep 2012 18:26:56 +0000
Received: from [85.158.139.83:18085] by server-6.bemta-5.messagelabs.com id
	D3/BD-21336-FECB8505; Tue, 18 Sep 2012 18:26:55 +0000
X-Env-Sender: jmarcet@gmail.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1347992813!31074244!1
X-Originating-IP: [209.85.214.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-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27477 invoked from network); 18 Sep 2012 18:26:54 -0000
Received: from mail-ob0-f173.google.com (HELO mail-ob0-f173.google.com)
	(209.85.214.173)
	by server-3.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Sep 2012 18:26:54 -0000
Received: by obbta14 with SMTP id ta14so223835obb.32
	for <xen-devel@lists.xen.org>; Tue, 18 Sep 2012 11:26: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:from:date:message-id:subject:to
	:cc:content-type:content-transfer-encoding;
	bh=Yo6+/asOPD1uFB8BHEhLPBBRvnSgiZgYarYqbmShuPQ=;
	b=zqA6MVTvdziGUf8kR1o5WA14IcptiKoFU/znos+bqWa/DQj6wwZSHWOCt3dRvqhA28
	5kpWyeHy/j4LjUDxN2tMHu0pXOVMhlzEHFco8DPcHmvw+LDkfovWFfHoobF+gTmTtPiV
	KWk0m3tOwaFbHcGLgaUh1lZeqaEfS3K8bNdfjFceLXobl3IdA0IPP5SnwfgZdOF28jE9
	y7qTbXONKjsOj8/YuswJ1yG0tDbGadmfkY/SNIa52jU8tYz71QCySeYvahjzqSHbWLYI
	5ydawRUCLIie9yd6UyudHG/B15SWd8THxhPceBCA/hZENSYHeO1SV4AQUpd+jlvOQ0WZ
	J4Dg==
Received: by 10.182.174.68 with SMTP id bq4mr1045971obc.53.1347992813225; Tue,
	18 Sep 2012 11:26:53 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.60.138.225 with HTTP; Tue, 18 Sep 2012 11:26:33 -0700 (PDT)
In-Reply-To: <20120918171725.GA14462@phenom.dumpdata.com>
References: <CAAnFQG9TZj=SxYK_jxqN=M6L40vL=AZu9EM2tbEffPhkL1s8FA@mail.gmail.com>
	<CACJDEmqdqA6CE9SgLL2QCNmQH1dOX0_4OHfJfzes+G6bEkQ7FA@mail.gmail.com>
	<CAAnFQG-8Fkunv6R8+GCLAH4yQCx4-Nn0zN_Ntsf0wsh5yXeihQ@mail.gmail.com>
	<20120917142851.GB14012@phenom.dumpdata.com>
	<CAAnFQG9bUUU8OBeKxYh=O3rRrnEPb4r1bPCr-EHWHuUS8shBhA@mail.gmail.com>
	<CAAnFQG_VnZOYs3SJvO1Gc8P98kOW=6Wxc7tM_vEF8GiACgeVWg@mail.gmail.com>
	<CAAnFQG9s=Yh4od18q8xDOD7ukA4uurxCKWiLrULFkP66Zc+iPg@mail.gmail.com>
	<CAAnFQG9PuzRLSsCS8m_0VUeV+ZaCwK3zsbinxtuFBfdSihJknw@mail.gmail.com>
	<20120918171725.GA14462@phenom.dumpdata.com>
From: Javier Marcet <jmarcet@gmail.com>
Date: Tue, 18 Sep 2012 20:26:33 +0200
Message-ID: <CAAnFQG_so_XmsWPPnzLOi=0nWB8d3Xos--L8=F4NZmoJ+9rLWg@mail.gmail.com>
To: Konrad Rzeszutek Wilk <konrad@kernel.org>
Cc: Xen Devel Mailing list <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.2.0-rc4 issues with DVB tuner
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gVHVlLCBTZXAgMTgsIDIwMTIgYXQgNzoxNyBQTSwgS29ucmFkIFJ6ZXN6dXRlayBXaWxrCjxr
b25yYWRAa2VybmVsLm9yZz4gd3JvdGU6Cgo+PiBJIGhhdmUgc29tZSBuZXdzIGZyb20gdGhlIGxp
bnV4LW1lZGlhIG1haWxpbmcgbGlzdC4gVGhlcmUsIERldmluIEhlaXRtdWVsbGVyLAo+PiBzYWlk
IHRoaXM6Cj4+Cj4+ICIiIgo+PiA+IEluaXRpYWxseSBJIHRob3VnaHQgWGVuIHdvdWxkIGJlIHRo
ZSBjYXVzZSBvZiB0aGUgcHJvYmxlbSwgYnV0IGFmdGVyCj4+ID4gaGF2aW5nIHdyaXR0ZW4gb24K
Pj4gPiB0aGUgWGVuIGRldmVsb3BtZW50IG1haWxpbmcgbGlzdCBhbmQgdGFsa2VkIGFib3V0IGl0
IHdpdGggYSBjb3VwbGUKPj4gPiBkZXZlbG9wZXJzLCBpdCBpc24ndAo+PiA+IHZlcnkgY2xlYXIg
d2hlcmUgdGhlIHByb2JsZW0gaXMuIFNvIGZhciBJIGhhdmVuJ3QgYmVlbiBhYmxlIHRvIGdldCB0
aGUKPj4gPiBzbWFsbGVzdCB3YXJuaW5nCj4+ID4gb3IgZXJyb3IuCj4+Cj4+IFRoaXMgaXMgYSB2
ZXJ5IGNvbW1vbiBwcm9ibGVtIHdoZW4gYXR0ZW1wdGluZyB0byB1c2UgYW55IFBDSS9QQ0llCj4+
IHR1bmVyIHVuZGVyIGEgaHlwZXJ2aXNvci4gIEVzc2VudGlhbGx5IHRoZSBpc3N1ZSBpcyBhbGwg
b2YgdGhlCj4+IHZpcnR1YWxpemF0aW9uIHNvbHV0aW9ucyBwcm92aWRlIHZlcnkgcG9vciBpbnRl
cnJ1cHQgbGF0ZW5jeSwgd2hpY2gKPj4gcmVzdWx0cyBpbiB0aGUgZGF0YSBiZWluZyBsb3N0Lgo+
Pgo+PiBEZXZpY2VzIGRlbGl2ZXJpbmcgYSBoaWdoIGJpdHJhdGUgc3RyZWFtIG9mIGRhdGEgaW4g
cmVhbHRpbWUgYXJlIG11Y2gKPj4gbW9yZSBsaWtlbHkgZm9yIHRoaXMgcHJvYmxlbSB0byBiZSB2
aXNpYmxlIHNpbmNlIHN1Y2ggZGV2aWNlcyBoYXZlCj4+IHZlcnkgbGl0dGxlIGJ1ZmZlcmluZyAo
aXQncyBub3QgbGlrZSBhIGhhcmQgZHJpdmUgY29udHJvbGxlciB3aGVyZSBpdAo+PiBjYW4ganVz
dCBkZWxpdmVyIHRoZSBkYXRhIHNsb3dlcikuICBUaGUgcHJvYmxlbSBpcyBub3Qgc3BlY2lmaWMg
dG8gdGhlCj4+IGN4MjM4ODUgLSBwcmV0dHkgbXVjaCBhbGwgb2YgdGhlIFBDSS9QQ0llIGJyaWRn
ZXMgdXNlZCBpbiB0dW5lciBjYXJkcwo+PiB3b3JrIHRoaXMgd2F5LCBhbmQgdGhleSBjYW5ub3Qg
cmVhbGx5IGJlIGJsYW1lZCBmb3IgZXhwZWN0aW5nIHRvIHJ1bgo+PiBpbiBhbiBlbnZpcm9ubWVu
dCB3aXRoIHJlYWxseSBjcmFwcHkgaW50ZXJydXB0IGxhdGVuY3kuCj4+Cj4+IEkgd29uJ3QgZ28g
YXMgZmFyIGFzIHRvIHNheSwgImFiYW5kb24gYWxsIGhvcGUiLCBidXQgeW91J3JlIG5vdCByZWFs
bHkKPj4gbGlrZWx5IHRvIGZpbmQgYW55IGhlbHAgaW4gdGhpcyBmb3J1bS4KPj4gIiIiCj4KPiBO
b3Qgc3VyZSBhYm91dCB0aGUgaW50ZXJydXB0IGxhdGVuY3kuIElmIHlvdSBydW4gdGhpcyBsaXR0
bGUgcHJvZ3JhbQo+IGh0dHA6Ly9kYXJub2sub3JnL3hlbi9yZWFkX2ludGVycnVwdHMuYwo+IHdo
ZW4gY2FwdHVyaW5nIGluIGJvdGggZG9tMCBhbmQgaW4gYmFyZW1ldGFsIGFyZSB0aGUgcmF0ZSBh
Ym91dCB0aGUKPiBzYW1lPwo+Pgo+PiBXaGF0IEkgZG9uwrR0IHVuZGVyc3RhbmQgaXMgaG93IGdy
YXBoaWNzIHBhc3MgdGhyb3VnaCBldmVuIHdvcmtzCj4+IGFuZCBhIHR1bmVyIGNhcmQgaGFzIHBy
b2JsZW1zIGR1ZSB0byB0aGUgaW50cm9kdWNlZCBsYXRlbmNpZXMgaW4gdGhlCj4+IElSUXMuCj4K
PiBUaGUgbGF0ZW5jeSBpcyB2ZXJ5IHZlcnkgbWluaXNjdWxlLiBPbmUgY291bGQgYWN0dWFsbHkg
dmVyaWZ5IHRoYXQgdGhpcwo+IGlzIGEgcHJvYmxlbSBieSBpbnNlcnRpbmcgc2FpZCBsYXRlbmN5
IGluIHRoZSBkcml2ZXIgc28gdGhhdCB1bmRlcgo+IGJhcmVtZXRhbCB0aGUgbGF0ZW5jeSB3b3Vs
ZCBzaG93IHVwLgo+Cj4gQnV0IHRoZSBvdGhlciBpc3N1ZSBpcyB0aGF0IGlmIHRoZSBkYXRhIGlz
IGJlaW5nIGxvc3QgeW91IHdvdWxkIGF0IGxlYXN0Cj4gZ2V0IHNvbWUuIFNvIHRoZSBidWZmZXJz
IG91Z2h0IHRvIGhhdmUgInNvbWV0aGluZyIgaW4gdGhlbT8gTWF5YmUgdGhhdAo+IGRlcGVuZHMg
b24gd2hhdCBjb21wcmVzc2lvbiB5b3UgdXNlIG9uIHRoZSBjb2Rlcj8gSWYgeW91IGp1cyBkbyBZ
VVY0MjAKPiBvciB0aGUgUkdCIHZhcmlhbnRzIGFuZCBqdXN0IGRvIGEgc2ltcGxlICdjYXQgL2Rl
di92aWRlMCA+IC90bXAvZmlsZScKPiBkb2VzIHRoZSBvdXRwdXQgY29udGFpbiBhbnl0aGluZz8g
T3IgaXMganVzdCBhIGJsb2Igb2YgZW1wdHkgZGF0YT8KClRoZSBvdXRwdXQgY29udGFpbnMgZGF0
YSwgcGFydCBvZiB0aGUgbXBlZyBzdHJlYW0gd2l0aG91dCBhbnkgY29udGludWl0eS4KCj4+IERv
IHlvdSBoYXZlIGFueSBtb3JlIGluZm8gYWJvdXQgdGhpcz8KPgo+IFRoZSBvdGhlciBpc3N1ZSBj
b3VsZCBiZSByZWxhdGVkIHRvIHRoZSB2bWFsbG9jXzMyIGJlaW5nIGluIHVzYWdlCj4gYW5kIG5v
dCB1c2luZyB0aGUgRE1BIEFQSS4KPgo+IEkgcmVjYWxsIHBvc3RpbmcgYSBwYXRjaCBmb3IgdGhp
cyAuLiBBaDoKPiBodHRwOi8vbGlzdHMueGVuLm9yZy9hcmNoaXZlcy9odG1sL3hlbi1kZXZlbC8y
MDEyLTAxL21zZzAxOTI3Lmh0bWwKPgo+IFBlcmhhcHMgdGhpcyBpcyB0aGUgaXNzdWU/CgpCaW5n
byBLb25yYWQhIFRoYXQgd2FzIGl0IDopIEF0IGxlYXN0IEkgaGF2ZSBqdXN0IGFwcGxpZWQgdGhl
IHBhdGNoLApyZWJvb3RlZCB1bmRlciBYZW4gYW5kIHRoaXMgdGltZSBJIGdvdCBhIGdvb2QgZHVt
cC4KClJpZ2h0IG5vdyBJIGhhdmUgbXkgdXN1YWwgc3lzdGVtIHJ1bm5pbmcgZmxhd2xlc3NseSB1
bmRlciBYZW4uIFRpbWUgdG8KdGFrZSBhIGxvb2sgYWdhaW4gYXQgdGhlIHN1c3BlbmQvcmVzdW1l
IGlzc3VlIHdoaWNoIEkgbmVhcmx5IGhhZAp3b3JraW5nIGEgZmV3IGRheXMgYWdvLgoKVGhhbmtz
IGEgbG90IGZvciBhbGwgeW91ciBoZWxwIDopCgpQLlMuIEknbSBnb2luZyB0byBwb3N0IHRoaXMg
aW5mbyBvbiB0aGUgbGludXggbWVkaWEgbWFpbGluZyBsaXN0LgoKCi0tIApKYXZpZXIgTWFyY2V0
IDxqbWFyY2V0QGdtYWlsLmNvbT4KCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbi5v
cmcKaHR0cDovL2xpc3RzLnhlbi5vcmcveGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Tue Sep 18 18:40:42 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Sep 2012 18:40:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TE2ii-00011O-Bq; Tue, 18 Sep 2012 18:40:28 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1TE2ig-00010c-MI
	for xen-devel@lists.xen.org; Tue, 18 Sep 2012 18:40:26 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1347993620!11484557!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDk5MjE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26710 invoked from network); 18 Sep 2012 18:40:20 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Sep 2012 18:40:20 -0000
X-IronPort-AV: E=Sophos;i="4.80,444,1344211200"; d="scan'208";a="14614670"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Sep 2012 18:40:19 +0000
Received: from [10.30.249.82] (10.30.249.82) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Tue, 18 Sep 2012 19:40:17 +0100
Message-ID: <5058C00B.6070106@citrix.com>
Date: Tue, 18 Sep 2012 19:40:11 +0100
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:15.0) Gecko/20120907 Thunderbird/15.0.1
MIME-Version: 1.0
To: <xen-devel@lists.xen.org>
References: <5057AB8D.3040200@gt.net>
In-Reply-To: <5057AB8D.3040200@gt.net>
Subject: Re: [Xen-devel] VM spontaneously losing network on 10gig 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 18/09/2012 00:00, Nathan March wrote:
> Hi All,
>
> Having a very strange problem where a VM's bridge will spontaneously 
> stop bridging traffic. This only seems to occur on our 10gig interfaces 
> (intel x540 on ixgbe driver, mtu 9000), which are 2x links bonded into 
> bond0, then broken down into pvlan462/pvlan463/etc before being bridged 
> with the DomU's. Everything works great at first but several hours after 
> starting a large rsync traffic stops crossing the bridge. Once it's 
> stopped working it only affects that single VM on that single interface. 
> Other VM's on the same dom0 still have access to the same affected vlan.
>
> Layout is Nexenta NFS ---> 2x arista 10gig switches --> intel x540-t2 
> (ixgbe) on dom0 --802.3ad--> bond0 --vconfig--> vlan 462 --bridged--> 
> pvlan 462 / vif4.1 / vif6.1.
> Dom0 is running kernel 3.2.28 w/ xen 4.1.3, domU is kernel 2.6.32.27
>
> xen3 ~ # brctl show
> bridge name     bridge id               STP enabled     interfaces
> vlan462         8000.a0369f0eac2c       no              pvlan462
>                                                          vif4.1
>                                                          vif6.1
> vlan463         8000.a0369f0eac2c       no              pvlan463
>                                                          vif5.1
>
> Once it breaks, doing a tcpdump inside the vm or on the dom0 against the 
> vif show the same arp traffic from the VM (looking for the nfs server), 
> but nothing incoming to the VM at all. Tcpdumping on the parent bridge 
> shows the traffic as normal and other VMs on this bridge have regular 
> access still, only the single vif is affected.
>
> I've tried toggling net.bridge.bridge-nf-call-(arp|ip|ip6)tables off and 
> it didn't seem to make a difference (also flushed all ip/eb/arptables 
> rules just in case).
>
> It takes me several hours to reproduce just by copying data and I 
> haven't managed to figure out a nice small test case yet or what 
> triggers the break. Considering I've found one bug in ixgbe already 
> (reported + fixed!) I suspect the 10gig driver, but seems like this 
> problem would come from either xen or bridging. This feels like a xen 
> net back/front issue?
>
> Any ideas? Or suggestions on where to start looking?

What happens if you detach the vif from the bridge and reattach it -
does the problem go away?

~Andrew

>
> Thanks!
>
> - Nathan
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Sep 18 18:40:42 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Sep 2012 18:40:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TE2ii-00011O-Bq; Tue, 18 Sep 2012 18:40:28 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1TE2ig-00010c-MI
	for xen-devel@lists.xen.org; Tue, 18 Sep 2012 18:40:26 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1347993620!11484557!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDk5MjE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26710 invoked from network); 18 Sep 2012 18:40:20 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Sep 2012 18:40:20 -0000
X-IronPort-AV: E=Sophos;i="4.80,444,1344211200"; d="scan'208";a="14614670"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Sep 2012 18:40:19 +0000
Received: from [10.30.249.82] (10.30.249.82) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Tue, 18 Sep 2012 19:40:17 +0100
Message-ID: <5058C00B.6070106@citrix.com>
Date: Tue, 18 Sep 2012 19:40:11 +0100
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:15.0) Gecko/20120907 Thunderbird/15.0.1
MIME-Version: 1.0
To: <xen-devel@lists.xen.org>
References: <5057AB8D.3040200@gt.net>
In-Reply-To: <5057AB8D.3040200@gt.net>
Subject: Re: [Xen-devel] VM spontaneously losing network on 10gig 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 18/09/2012 00:00, Nathan March wrote:
> Hi All,
>
> Having a very strange problem where a VM's bridge will spontaneously 
> stop bridging traffic. This only seems to occur on our 10gig interfaces 
> (intel x540 on ixgbe driver, mtu 9000), which are 2x links bonded into 
> bond0, then broken down into pvlan462/pvlan463/etc before being bridged 
> with the DomU's. Everything works great at first but several hours after 
> starting a large rsync traffic stops crossing the bridge. Once it's 
> stopped working it only affects that single VM on that single interface. 
> Other VM's on the same dom0 still have access to the same affected vlan.
>
> Layout is Nexenta NFS ---> 2x arista 10gig switches --> intel x540-t2 
> (ixgbe) on dom0 --802.3ad--> bond0 --vconfig--> vlan 462 --bridged--> 
> pvlan 462 / vif4.1 / vif6.1.
> Dom0 is running kernel 3.2.28 w/ xen 4.1.3, domU is kernel 2.6.32.27
>
> xen3 ~ # brctl show
> bridge name     bridge id               STP enabled     interfaces
> vlan462         8000.a0369f0eac2c       no              pvlan462
>                                                          vif4.1
>                                                          vif6.1
> vlan463         8000.a0369f0eac2c       no              pvlan463
>                                                          vif5.1
>
> Once it breaks, doing a tcpdump inside the vm or on the dom0 against the 
> vif show the same arp traffic from the VM (looking for the nfs server), 
> but nothing incoming to the VM at all. Tcpdumping on the parent bridge 
> shows the traffic as normal and other VMs on this bridge have regular 
> access still, only the single vif is affected.
>
> I've tried toggling net.bridge.bridge-nf-call-(arp|ip|ip6)tables off and 
> it didn't seem to make a difference (also flushed all ip/eb/arptables 
> rules just in case).
>
> It takes me several hours to reproduce just by copying data and I 
> haven't managed to figure out a nice small test case yet or what 
> triggers the break. Considering I've found one bug in ixgbe already 
> (reported + fixed!) I suspect the 10gig driver, but seems like this 
> problem would come from either xen or bridging. This feels like a xen 
> net back/front issue?
>
> Any ideas? Or suggestions on where to start looking?

What happens if you detach the vif from the bridge and reattach it -
does the problem go away?

~Andrew

>
> Thanks!
>
> - Nathan
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Sep 18 18:50:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Sep 2012 18:50:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TE2rj-0001Bw-Dk; Tue, 18 Sep 2012 18:49:47 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <m.a.young@durham.ac.uk>) id 1TE2ri-0001Bp-83
	for xen-devel@lists.xen.org; Tue, 18 Sep 2012 18:49:46 +0000
Received: from [85.158.139.83:44304] by server-12.bemta-5.messagelabs.com id
	86/03-22167-942C8505; Tue, 18 Sep 2012 18:49:45 +0000
X-Env-Sender: m.a.young@durham.ac.uk
X-Msg-Ref: server-9.tower-182.messagelabs.com!1347994184!30424725!1
X-Originating-IP: [129.234.248.1]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTI5LjIzNC4yNDguMSA9PiAxMDg0OTA=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13804 invoked from network); 18 Sep 2012 18:49:44 -0000
Received: from hermes1.dur.ac.uk (HELO hermes1.dur.ac.uk) (129.234.248.1)
	by server-9.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 18 Sep 2012 18:49:44 -0000
Received: from smtphost2.dur.ac.uk (smtphost2.dur.ac.uk [129.234.252.2])
	by hermes1.dur.ac.uk (8.13.8/8.13.8) with ESMTP id q8IInAvF029382;
	Tue, 18 Sep 2012 19:49:14 +0100
Received: from procyon.dur.ac.uk (procyon.dur.ac.uk [129.234.250.129])
	by smtphost2.dur.ac.uk (8.13.8/8.13.7) with ESMTP id q8IImqNu011526
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 18 Sep 2012 19:48:52 +0100
Received: from procyon.dur.ac.uk (localhost [127.0.0.1])
	by procyon.dur.ac.uk (8.14.3/8.11.1) with ESMTP id q8IImqRO028354;
	Tue, 18 Sep 2012 19:48:52 +0100
Received: from localhost (dcl0may@localhost)
	by procyon.dur.ac.uk (8.14.3/8.14.3/Submit) with ESMTP id
	q8IImp0x028343; Tue, 18 Sep 2012 19:48:51 +0100
Date: Tue, 18 Sep 2012 19:48:51 +0100 (BST)
From: M A Young <m.a.young@durham.ac.uk>
To: Olaf Hering <olaf@aepfle.de>
In-Reply-To: <20120918143516.GA7170@aepfle.de>
Message-ID: <alpine.DEB.2.00.1209181938500.21507@procyon.dur.ac.uk>
References: <5058850F.6000800@crc.id.au> <20120918143516.GA7170@aepfle.de>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: MULTIPART/MIXED; BOUNDARY="8323329-1453866748-1347994132=:21507"
X-DurhamAcUk-MailScanner: Found to be clean, Found to be clean
X-DurhamAcUk-MailScanner-ID: q8IInAvF029382
Cc: Steven Haigh <netwiz@crc.id.au>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Problems building qemu-xen-dir tools
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
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-1453866748-1347994132=:21507
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed

On Tue, 18 Sep 2012, Olaf Hering wrote:

> On Wed, Sep 19, Steven Haigh wrote:
>
>> Without this, the build fails due to incompatible CFLAGS.
>
> CFLAGS must not be in environment, otherwise make will append its own
> CFLAGS to that environment variable and pass it on to qemu. qemu itself
> is not ready for things like -std=gnu99.

The problem is that packaging guidelines often want you to set CFLAGS to 
supply distribution standard compile options. On the other hand with 
something like qemu it means that someone has probably already solved the 
problem. The attached patch worked for me in testing, which I derived by 
comparing Fedora's qemu with xen's.

 	Michael Young
--8323329-1453866748-1347994132=:21507
Content-Type: TEXT/PLAIN; charset=US-ASCII; name=qemu-xen.build.patch
Content-Transfer-Encoding: BASE64
Content-Description: 
Content-Disposition: attachment; filename=qemu-xen.build.patch

LS0tIHhlbi00LjIuMC90b29scy9xZW11LXhlbi9mcHUvc29mdGZsb2F0LXNw
ZWNpYWxpemUuaAkyMDEyLTA5LTEwIDE5OjEwOjUyLjAwMDAwMDAwMCArMDEw
MA0KKysrIHhlbi00LjIuMC90b29scy9xZW11LXhlbi9mcHUvc29mdGZsb2F0
LXNwZWNpYWxpemUuaAkyMDEyLTA3LTAzIDE1OjIwOjA1LjAwMDAwMDAwMCAr
MDEwMA0KQEAgLTg5LDggKzg5LDggQEANCiAjZGVmaW5lIGZsb2F0eDgwX2Rl
ZmF1bHRfbmFuX2xvdyAgTElUNjQoIDB4QzAwMDAwMDAwMDAwMDAwMCApDQog
I2VuZGlmDQogDQotY29uc3QgZmxvYXR4ODAgZmxvYXR4ODBfZGVmYXVsdF9u
YW4gPSBtYWtlX2Zsb2F0eDgwKGZsb2F0eDgwX2RlZmF1bHRfbmFuX2hpZ2gs
DQotICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgIGZsb2F0eDgwX2RlZmF1bHRfbmFuX2xvdyk7DQorY29uc3Qg
ZmxvYXR4ODAgZmxvYXR4ODBfZGVmYXVsdF9uYW4NCisgICAgPSBtYWtlX2Zs
b2F0eDgwX2luaXQoZmxvYXR4ODBfZGVmYXVsdF9uYW5faGlnaCwgZmxvYXR4
ODBfZGVmYXVsdF9uYW5fbG93KTsNCiANCiAvKi0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0NCiB8IFRoZSBwYXR0ZXJuIGZvciBhIGRlZmF1bHQg
Z2VuZXJhdGVkIHF1YWRydXBsZS1wcmVjaXNpb24gTmFOLiAgVGhlIGBoaWdo
JyBhbmQNCkBAIC0xMDQsOCArMTA0LDggQEANCiAjZGVmaW5lIGZsb2F0MTI4
X2RlZmF1bHRfbmFuX2xvdyAgTElUNjQoIDB4MDAwMDAwMDAwMDAwMDAwMCAp
DQogI2VuZGlmDQogDQotY29uc3QgZmxvYXQxMjggZmxvYXQxMjhfZGVmYXVs
dF9uYW4gPSBtYWtlX2Zsb2F0MTI4KGZsb2F0MTI4X2RlZmF1bHRfbmFuX2hp
Z2gsDQotICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgIGZsb2F0MTI4X2RlZmF1bHRfbmFuX2xvdyk7DQorY29u
c3QgZmxvYXQxMjggZmxvYXQxMjhfZGVmYXVsdF9uYW4NCisgICAgPSBtYWtl
X2Zsb2F0MTI4X2luaXQoZmxvYXQxMjhfZGVmYXVsdF9uYW5faGlnaCwgZmxv
YXQxMjhfZGVmYXVsdF9uYW5fbG93KTsNCiANCiAvKi0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0NCiB8IFJhaXNlcyB0aGUgZXhjZXB0aW9ucyBz
cGVjaWZpZWQgYnkgYGZsYWdzJy4gIEZsb2F0aW5nLXBvaW50IHRyYXBzIGNh
biBiZQ0KLS0tIHhlbi00LjIuMC90b29scy9xZW11LXhlbi9mcHUvc29mdGZs
b2F0LmgJMjAxMi0wOS0xMCAxOToxMDo1Mi4wMDAwMDAwMDAgKzAxMDANCisr
KyB4ZW4tNC4yLjAvdG9vbHMvcWVtdS14ZW4vZnB1L3NvZnRmbG9hdC5oCTIw
MTItMDctMDMgMTU6MjA6MDUuMDAwMDAwMDAwICswMTAwDQpAQCAtMTI5LDYg
KzEyNiw3IEBADQogICAgIHVpbnQxNl90IGhpZ2g7DQogfSBmbG9hdHg4MDsN
CiAjZGVmaW5lIG1ha2VfZmxvYXR4ODAoZXhwLCBtYW50KSAoKGZsb2F0eDgw
KSB7IG1hbnQsIGV4cCB9KQ0KKyNkZWZpbmUgbWFrZV9mbG9hdHg4MF9pbml0
KGV4cCwgbWFudCkgeyAubG93ID0gbWFudCwgLmhpZ2ggPSBleHAgfQ0KIHR5
cGVkZWYgc3RydWN0IHsNCiAjaWZkZWYgSE9TVF9XT1JEU19CSUdFTkRJQU4N
CiAgICAgdWludDY0X3QgaGlnaCwgbG93Ow0KQEAgLTEzNyw2ICsxMzUsNyBA
QA0KICNlbmRpZg0KIH0gZmxvYXQxMjg7DQogI2RlZmluZSBtYWtlX2Zsb2F0
MTI4KGhpZ2hfLCBsb3dfKSAoKGZsb2F0MTI4KSB7IC5oaWdoID0gaGlnaF8s
IC5sb3cgPSBsb3dfIH0pDQorI2RlZmluZSBtYWtlX2Zsb2F0MTI4X2luaXQo
aGlnaF8sIGxvd18pIHsgLmhpZ2ggPSBoaWdoXywgLmxvdyA9IGxvd18gfQ0K
IA0KIC8qLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KIHwgU29m
dHdhcmUgSUVDL0lFRUUgZmxvYXRpbmctcG9pbnQgdW5kZXJmbG93IHRpbmlu
ZXNzLWRldGVjdGlvbiBtb2RlLg0K

--8323329-1453866748-1347994132=:21507
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 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-1453866748-1347994132=:21507--


From xen-devel-bounces@lists.xen.org Tue Sep 18 18:50:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Sep 2012 18:50:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TE2rj-0001Bw-Dk; Tue, 18 Sep 2012 18:49:47 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <m.a.young@durham.ac.uk>) id 1TE2ri-0001Bp-83
	for xen-devel@lists.xen.org; Tue, 18 Sep 2012 18:49:46 +0000
Received: from [85.158.139.83:44304] by server-12.bemta-5.messagelabs.com id
	86/03-22167-942C8505; Tue, 18 Sep 2012 18:49:45 +0000
X-Env-Sender: m.a.young@durham.ac.uk
X-Msg-Ref: server-9.tower-182.messagelabs.com!1347994184!30424725!1
X-Originating-IP: [129.234.248.1]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTI5LjIzNC4yNDguMSA9PiAxMDg0OTA=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13804 invoked from network); 18 Sep 2012 18:49:44 -0000
Received: from hermes1.dur.ac.uk (HELO hermes1.dur.ac.uk) (129.234.248.1)
	by server-9.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 18 Sep 2012 18:49:44 -0000
Received: from smtphost2.dur.ac.uk (smtphost2.dur.ac.uk [129.234.252.2])
	by hermes1.dur.ac.uk (8.13.8/8.13.8) with ESMTP id q8IInAvF029382;
	Tue, 18 Sep 2012 19:49:14 +0100
Received: from procyon.dur.ac.uk (procyon.dur.ac.uk [129.234.250.129])
	by smtphost2.dur.ac.uk (8.13.8/8.13.7) with ESMTP id q8IImqNu011526
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 18 Sep 2012 19:48:52 +0100
Received: from procyon.dur.ac.uk (localhost [127.0.0.1])
	by procyon.dur.ac.uk (8.14.3/8.11.1) with ESMTP id q8IImqRO028354;
	Tue, 18 Sep 2012 19:48:52 +0100
Received: from localhost (dcl0may@localhost)
	by procyon.dur.ac.uk (8.14.3/8.14.3/Submit) with ESMTP id
	q8IImp0x028343; Tue, 18 Sep 2012 19:48:51 +0100
Date: Tue, 18 Sep 2012 19:48:51 +0100 (BST)
From: M A Young <m.a.young@durham.ac.uk>
To: Olaf Hering <olaf@aepfle.de>
In-Reply-To: <20120918143516.GA7170@aepfle.de>
Message-ID: <alpine.DEB.2.00.1209181938500.21507@procyon.dur.ac.uk>
References: <5058850F.6000800@crc.id.au> <20120918143516.GA7170@aepfle.de>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: MULTIPART/MIXED; BOUNDARY="8323329-1453866748-1347994132=:21507"
X-DurhamAcUk-MailScanner: Found to be clean, Found to be clean
X-DurhamAcUk-MailScanner-ID: q8IInAvF029382
Cc: Steven Haigh <netwiz@crc.id.au>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Problems building qemu-xen-dir tools
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
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-1453866748-1347994132=:21507
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed

On Tue, 18 Sep 2012, Olaf Hering wrote:

> On Wed, Sep 19, Steven Haigh wrote:
>
>> Without this, the build fails due to incompatible CFLAGS.
>
> CFLAGS must not be in environment, otherwise make will append its own
> CFLAGS to that environment variable and pass it on to qemu. qemu itself
> is not ready for things like -std=gnu99.

The problem is that packaging guidelines often want you to set CFLAGS to 
supply distribution standard compile options. On the other hand with 
something like qemu it means that someone has probably already solved the 
problem. The attached patch worked for me in testing, which I derived by 
comparing Fedora's qemu with xen's.

 	Michael Young
--8323329-1453866748-1347994132=:21507
Content-Type: TEXT/PLAIN; charset=US-ASCII; name=qemu-xen.build.patch
Content-Transfer-Encoding: BASE64
Content-Description: 
Content-Disposition: attachment; filename=qemu-xen.build.patch

LS0tIHhlbi00LjIuMC90b29scy9xZW11LXhlbi9mcHUvc29mdGZsb2F0LXNw
ZWNpYWxpemUuaAkyMDEyLTA5LTEwIDE5OjEwOjUyLjAwMDAwMDAwMCArMDEw
MA0KKysrIHhlbi00LjIuMC90b29scy9xZW11LXhlbi9mcHUvc29mdGZsb2F0
LXNwZWNpYWxpemUuaAkyMDEyLTA3LTAzIDE1OjIwOjA1LjAwMDAwMDAwMCAr
MDEwMA0KQEAgLTg5LDggKzg5LDggQEANCiAjZGVmaW5lIGZsb2F0eDgwX2Rl
ZmF1bHRfbmFuX2xvdyAgTElUNjQoIDB4QzAwMDAwMDAwMDAwMDAwMCApDQog
I2VuZGlmDQogDQotY29uc3QgZmxvYXR4ODAgZmxvYXR4ODBfZGVmYXVsdF9u
YW4gPSBtYWtlX2Zsb2F0eDgwKGZsb2F0eDgwX2RlZmF1bHRfbmFuX2hpZ2gs
DQotICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgIGZsb2F0eDgwX2RlZmF1bHRfbmFuX2xvdyk7DQorY29uc3Qg
ZmxvYXR4ODAgZmxvYXR4ODBfZGVmYXVsdF9uYW4NCisgICAgPSBtYWtlX2Zs
b2F0eDgwX2luaXQoZmxvYXR4ODBfZGVmYXVsdF9uYW5faGlnaCwgZmxvYXR4
ODBfZGVmYXVsdF9uYW5fbG93KTsNCiANCiAvKi0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0NCiB8IFRoZSBwYXR0ZXJuIGZvciBhIGRlZmF1bHQg
Z2VuZXJhdGVkIHF1YWRydXBsZS1wcmVjaXNpb24gTmFOLiAgVGhlIGBoaWdo
JyBhbmQNCkBAIC0xMDQsOCArMTA0LDggQEANCiAjZGVmaW5lIGZsb2F0MTI4
X2RlZmF1bHRfbmFuX2xvdyAgTElUNjQoIDB4MDAwMDAwMDAwMDAwMDAwMCAp
DQogI2VuZGlmDQogDQotY29uc3QgZmxvYXQxMjggZmxvYXQxMjhfZGVmYXVs
dF9uYW4gPSBtYWtlX2Zsb2F0MTI4KGZsb2F0MTI4X2RlZmF1bHRfbmFuX2hp
Z2gsDQotICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgIGZsb2F0MTI4X2RlZmF1bHRfbmFuX2xvdyk7DQorY29u
c3QgZmxvYXQxMjggZmxvYXQxMjhfZGVmYXVsdF9uYW4NCisgICAgPSBtYWtl
X2Zsb2F0MTI4X2luaXQoZmxvYXQxMjhfZGVmYXVsdF9uYW5faGlnaCwgZmxv
YXQxMjhfZGVmYXVsdF9uYW5fbG93KTsNCiANCiAvKi0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0NCiB8IFJhaXNlcyB0aGUgZXhjZXB0aW9ucyBz
cGVjaWZpZWQgYnkgYGZsYWdzJy4gIEZsb2F0aW5nLXBvaW50IHRyYXBzIGNh
biBiZQ0KLS0tIHhlbi00LjIuMC90b29scy9xZW11LXhlbi9mcHUvc29mdGZs
b2F0LmgJMjAxMi0wOS0xMCAxOToxMDo1Mi4wMDAwMDAwMDAgKzAxMDANCisr
KyB4ZW4tNC4yLjAvdG9vbHMvcWVtdS14ZW4vZnB1L3NvZnRmbG9hdC5oCTIw
MTItMDctMDMgMTU6MjA6MDUuMDAwMDAwMDAwICswMTAwDQpAQCAtMTI5LDYg
KzEyNiw3IEBADQogICAgIHVpbnQxNl90IGhpZ2g7DQogfSBmbG9hdHg4MDsN
CiAjZGVmaW5lIG1ha2VfZmxvYXR4ODAoZXhwLCBtYW50KSAoKGZsb2F0eDgw
KSB7IG1hbnQsIGV4cCB9KQ0KKyNkZWZpbmUgbWFrZV9mbG9hdHg4MF9pbml0
KGV4cCwgbWFudCkgeyAubG93ID0gbWFudCwgLmhpZ2ggPSBleHAgfQ0KIHR5
cGVkZWYgc3RydWN0IHsNCiAjaWZkZWYgSE9TVF9XT1JEU19CSUdFTkRJQU4N
CiAgICAgdWludDY0X3QgaGlnaCwgbG93Ow0KQEAgLTEzNyw2ICsxMzUsNyBA
QA0KICNlbmRpZg0KIH0gZmxvYXQxMjg7DQogI2RlZmluZSBtYWtlX2Zsb2F0
MTI4KGhpZ2hfLCBsb3dfKSAoKGZsb2F0MTI4KSB7IC5oaWdoID0gaGlnaF8s
IC5sb3cgPSBsb3dfIH0pDQorI2RlZmluZSBtYWtlX2Zsb2F0MTI4X2luaXQo
aGlnaF8sIGxvd18pIHsgLmhpZ2ggPSBoaWdoXywgLmxvdyA9IGxvd18gfQ0K
IA0KIC8qLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KIHwgU29m
dHdhcmUgSUVDL0lFRUUgZmxvYXRpbmctcG9pbnQgdW5kZXJmbG93IHRpbmlu
ZXNzLWRldGVjdGlvbiBtb2RlLg0K

--8323329-1453866748-1347994132=:21507
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 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-1453866748-1347994132=:21507--


From xen-devel-bounces@lists.xen.org Tue Sep 18 18:50:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Sep 2012 18: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 1TE2sT-0001Ez-Rd; Tue, 18 Sep 2012 18:50:33 +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 1TE2sS-0001En-Pg
	for xen-devel@lists.xensource.com; Tue, 18 Sep 2012 18:50:32 +0000
Received: from [85.158.139.211:36275] by server-6.bemta-5.messagelabs.com id
	D5/07-21336-772C8505; Tue, 18 Sep 2012 18:50:31 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-12.tower-206.messagelabs.com!1347994230!18065526!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDk5MjE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17981 invoked from network); 18 Sep 2012 18:50:30 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Sep 2012 18:50:30 -0000
X-IronPort-AV: E=Sophos;i="4.80,444,1344211200"; d="scan'208";a="14614797"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Sep 2012 18:50:22 +0000
Received: from [10.30.249.82] (10.30.249.82) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Tue, 18 Sep 2012 19:50:19 +0100
Message-ID: <5058C25A.1090602@citrix.com>
Date: Tue, 18 Sep 2012 19:50:02 +0100
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:15.0) Gecko/20120907 Thunderbird/15.0.1
MIME-Version: 1.0
To: William Dauchy <wdauchy@gmail.com>
References: <CAJ75kXZm-BqWdL2O41XkSE1VCdd4ruW=+CqDmR1b3=701RnXmw@mail.gmail.com>
In-Reply-To: <CAJ75kXZm-BqWdL2O41XkSE1VCdd4ruW=+CqDmR1b3=701RnXmw@mail.gmail.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] Error getting mfn
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 18/09/2012 09:24, William Dauchy wrote:
> Hello,
>
> I'm getting many "Error getting mfn" on a xen4.1.3 with dom0 3.4.11 x86_32.
> I thought it could be related to
> xen/mmu: Release just the MFN list, not MFN list and part of pagetables.
> http://git.kernel.org/?p=linux/kernel/git/konrad/xen.git;a=commit;h=785f62314984ea3af9dd830b020289ba2509ae69
>
> (XEN) Freed 212kB init memory.
> (XEN) mm.c:908:d0 Error getting mfn 2009b (pfn 5555555555555555) from
> L1 entry 000000002009b023 for l1e_owner=0, pg_owner=0
> (XEN) mm.c:908:d0 Error getting mfn 2009c (pfn 5555555555555555) from
> L1 entry 000000002009c023 for l1e_owner=0, pg_owner=0
> [...]
> (XEN) mm.c:908:d0 Error getting mfn c32116 (pfn 5555555555555555) from
> L1 entry 8000000c32116063 for l1e_owner=0, pg_owner=0
> (XEN) mm.c:908:d0 Error getting mfn c32117 (pfn 5555555555555555) from
> L1 entry 8000000c32117063 for l1e_owner=0, pg_owner=0
> (XEN) ../physdev.c:171: dom0: wrong map_pirq type 3
>
> Any hint?

Are you compiling as uniprocessor rather than SMP?  This reminds me of a
bug XenServer came across where a 32bit uniprocessor build would use two
32bit writes to change PTEs, and issue the two writes in the wrong
order, triggering this error.

~Andrew

>
> Regards,


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 18 18:50:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Sep 2012 18: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 1TE2sT-0001Ez-Rd; Tue, 18 Sep 2012 18:50:33 +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 1TE2sS-0001En-Pg
	for xen-devel@lists.xensource.com; Tue, 18 Sep 2012 18:50:32 +0000
Received: from [85.158.139.211:36275] by server-6.bemta-5.messagelabs.com id
	D5/07-21336-772C8505; Tue, 18 Sep 2012 18:50:31 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-12.tower-206.messagelabs.com!1347994230!18065526!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDk5MjE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17981 invoked from network); 18 Sep 2012 18:50:30 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Sep 2012 18:50:30 -0000
X-IronPort-AV: E=Sophos;i="4.80,444,1344211200"; d="scan'208";a="14614797"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Sep 2012 18:50:22 +0000
Received: from [10.30.249.82] (10.30.249.82) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Tue, 18 Sep 2012 19:50:19 +0100
Message-ID: <5058C25A.1090602@citrix.com>
Date: Tue, 18 Sep 2012 19:50:02 +0100
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:15.0) Gecko/20120907 Thunderbird/15.0.1
MIME-Version: 1.0
To: William Dauchy <wdauchy@gmail.com>
References: <CAJ75kXZm-BqWdL2O41XkSE1VCdd4ruW=+CqDmR1b3=701RnXmw@mail.gmail.com>
In-Reply-To: <CAJ75kXZm-BqWdL2O41XkSE1VCdd4ruW=+CqDmR1b3=701RnXmw@mail.gmail.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] Error getting mfn
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 18/09/2012 09:24, William Dauchy wrote:
> Hello,
>
> I'm getting many "Error getting mfn" on a xen4.1.3 with dom0 3.4.11 x86_32.
> I thought it could be related to
> xen/mmu: Release just the MFN list, not MFN list and part of pagetables.
> http://git.kernel.org/?p=linux/kernel/git/konrad/xen.git;a=commit;h=785f62314984ea3af9dd830b020289ba2509ae69
>
> (XEN) Freed 212kB init memory.
> (XEN) mm.c:908:d0 Error getting mfn 2009b (pfn 5555555555555555) from
> L1 entry 000000002009b023 for l1e_owner=0, pg_owner=0
> (XEN) mm.c:908:d0 Error getting mfn 2009c (pfn 5555555555555555) from
> L1 entry 000000002009c023 for l1e_owner=0, pg_owner=0
> [...]
> (XEN) mm.c:908:d0 Error getting mfn c32116 (pfn 5555555555555555) from
> L1 entry 8000000c32116063 for l1e_owner=0, pg_owner=0
> (XEN) mm.c:908:d0 Error getting mfn c32117 (pfn 5555555555555555) from
> L1 entry 8000000c32117063 for l1e_owner=0, pg_owner=0
> (XEN) ../physdev.c:171: dom0: wrong map_pirq type 3
>
> Any hint?

Are you compiling as uniprocessor rather than SMP?  This reminds me of a
bug XenServer came across where a 32bit uniprocessor build would use two
32bit writes to change PTEs, and issue the two writes in the wrong
order, triggering this error.

~Andrew

>
> Regards,


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 18 18:57:49 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Sep 2012 18:57:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TE2z8-0001Tx-Px; Tue, 18 Sep 2012 18:57:26 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jmarcet@gmail.com>) id 1TE2z7-0001Ts-OX
	for xen-devel@lists.xen.org; Tue, 18 Sep 2012 18:57:25 +0000
Received: from [85.158.143.99:15610] by server-2.bemta-4.messagelabs.com id
	D3/BA-06610-514C8505; Tue, 18 Sep 2012 18:57:25 +0000
X-Env-Sender: jmarcet@gmail.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1347994643!19638818!1
X-Originating-IP: [209.85.214.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-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20678 invoked from network); 18 Sep 2012 18:57:24 -0000
Received: from mail-ob0-f173.google.com (HELO mail-ob0-f173.google.com)
	(209.85.214.173)
	by server-16.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Sep 2012 18:57:24 -0000
Received: by obbta14 with SMTP id ta14so266721obb.32
	for <xen-devel@lists.xen.org>; Tue, 18 Sep 2012 11:57:22 -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=VVyHG8wKAGTrEuP0HMyJjHgkTUURx20cNm4XjUurS+k=;
	b=Yv+0hkYqx3sz5i6EyeTbzv6gZgmO/DLAC6zwiAEhiTbYMdODCI2olD8daJOdx2rxnf
	lvxQclfQb3iHkq0B9sLDd9BhaMl8J0XSUx325OiMi80/h40Tic1wXCdKukzJGw1z2gjA
	HaCinW+NG74krS+Kw0LxTaoTyLyaiRLPEIyIsaL9tzyFTl9Uc/VF2mBzuUUNvCw07GWI
	rkhSTIs+f/YxaOwkAxUxXUc4G4sagzStEelIxq/7oIR+Yik1URA4fCMyMjWY07UznVzP
	sR7d/UaqKFG980IQMrcOq/hAffPOm9s+tIzPOzcjtwLZRpcaG5UVh6f8BncHB2fA2PSJ
	3Qww==
Received: by 10.60.172.199 with SMTP id be7mr1097363oec.93.1347994642702; Tue,
	18 Sep 2012 11:57:22 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.60.138.225 with HTTP; Tue, 18 Sep 2012 11:57:02 -0700 (PDT)
From: Javier Marcet <jmarcet@gmail.com>
Date: Tue, 18 Sep 2012 20:57:02 +0200
Message-ID: <CAAnFQG9YZ0bsr=QnHaRxKTwNSCJvRiZ4ddCEMpsOZMNN+j7+vg@mail.gmail.com>
To: Xen Devel Mailing list <xen-devel@lists.xen.org>
Subject: [Xen-devel] Back trace from rcutree.c after resuming from S3
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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,

after solving the issue I had with a DVB tuner I tested again
suspending and resuming from S3.

I am now running Xen 4.2.0 and have applied patches [1] and [2] (any
idea why they are still not in mainline?) over a 3.5.3 kernel. I only
tried once since I upgraded my Xen, but after resuming I got the
following back trace:

[  142.267299] pcieport 0000:00:1c.5: wake-up capability enabled by ACPI
[  142.278312] ehci_hcd 0000:00:1d.0: wake-up capability enabled by ACPI
[  142.289169] ehci_hcd 0000:00:1a.0: wake-up capability enabled by ACPI
[  142.311116] xhci_hcd 0000:00:14.0: wake-up capability enabled by ACPI
[  142.322209] PM: noirq suspend of devices complete after 55.650 msecs
[  142.322778] ACPI: Preparing to enter system sleep state S3
[  142.723286] PM: Saving platform NVS memory
[  142.736453] Disabling non-boot CPUs ...
[  142.851387] ------------[ cut here ]------------
[  142.851397] WARNING: at
/home/storage/src/ubuntu-precise/kernel/rcutree.c:1550
rcu_do_batch.isra.41+0x5f/0x213()
[  142.851401] Hardware name: To Be Filled By O.E.M.
[  142.851404] Modules linked in: blktap(O) ip6table_filter ip6_tables
ipt_MASQUERADE iptable_nat nf_nat nf_conntrack_ipv4 nf_defrag_ipv4
xt_state nf_conntrack ipt_REJECT xt_CHECKSUM iptable_mangle xt_tcpudp
iptable_filter ip_tables x_tables [last unloaded: cx25840]
[  142.851466] Pid: 32, comm: migration/7 Tainted: G           O
3.5.0-14-i7 #18~precise1
[  142.851469] Call Trace:
[  142.851473]  <IRQ>  [<ffffffff8106a9bd>] warn_slowpath_common+0x7e/0x96
[  142.851488]  [<ffffffff8106a9ea>] warn_slowpath_null+0x15/0x17
[  142.851496]  [<ffffffff810c6e87>] rcu_do_batch.isra.41+0x5f/0x213
[  142.851504]  [<ffffffff810c687f>] ?
check_for_new_grace_period.isra.35+0x38/0x44
[  142.851512]  [<ffffffff810c7101>] __rcu_process_callbacks+0xc6/0xee
[  142.851520]  [<ffffffff810c7149>] rcu_process_callbacks+0x20/0x3e
[  142.851527]  [<ffffffff81070c27>] __do_softirq+0x87/0x113
[  142.851536]  [<ffffffff812e7b22>] ? __xen_evtchn_do_upcall+0x1a0/0x1dd
[  142.851546]  [<ffffffff8162f05c>] call_softirq+0x1c/0x30
[  142.851557]  [<ffffffff810343a3>] do_softirq+0x41/0x7e
[  142.851566]  [<ffffffff81070e66>] irq_exit+0x3f/0x9a
[  142.851573]  [<ffffffff812e95c9>] xen_evtchn_do_upcall+0x2c/0x39
[  142.851580]  [<ffffffff8162f0ae>] xen_do_hypervisor_callback+0x1e/0x30
[  142.851588]  <EOI>  [<ffffffff8100122a>] ? hypercall_page+0x22a/0x1000
[  142.851601]  [<ffffffff8100122a>] ? hypercall_page+0x22a/0x1000
[  142.851609]  [<ffffffff8102eee9>] ? xen_force_evtchn_callback+0xd/0xf
[  142.851618]  [<ffffffff8102f552>] ? check_events+0x12/0x20
[  142.851627]  [<ffffffff8102f53f>] ? xen_restore_fl_direct_reloc+0x4/0x4
[  142.851635]  [<ffffffff810b6ff4>] ? arch_local_irq_restore+0xb/0xd
[  142.851644]  [<ffffffff810b73f4>] ? stop_machine_cpu_stop+0xc1/0xd3
[  142.851652]  [<ffffffff810b7333>] ? queue_stop_cpus_work+0xb5/0xb5
[  142.851660]  [<ffffffff810b7152>] ? cpu_stopper_thread+0xf7/0x187
[  142.851667]  [<ffffffff8108a927>] ? finish_task_switch+0x82/0xc1
[  142.851676]  [<ffffffff8162c50b>] ? __schedule+0x428/0x454
[  142.851685]  [<ffffffff8162cff0>] ? _raw_spin_unlock_irqrestore+0x15/0x18
[  142.851693]  [<ffffffff810b705b>] ? cpu_stop_signal_done+0x30/0x30
[  142.851701]  [<ffffffff81082627>] ? kthread+0x86/0x8e
[  142.851710]  [<ffffffff8162ef64>] ? kernel_thread_helper+0x4/0x10
[  142.851718]  [<ffffffff8162d338>] ? retint_restore_args+0x5/0x6
[  142.851726]  [<ffffffff8162ef60>] ? gs_change+0x13/0x13
[  142.851736] ---[ end trace 3722a99bcc5ae37a ]---
[  144.257229] ACPI: Low-level resume complete
[  144.257322] PM: Restoring platform NVS memory
[  144.257866] Enabling non-boot CPUs ...
[  144.258042] installing Xen timer for CPU 1
[  144.258080] cpu 1 spinlock event irq 48
[  144.322077] CPU1 is up
[  144.322352] installing Xen timer for CPU 2
[  144.322379] cpu 2 spinlock event irq 55
[  144.340819] CPU2 is up
[  144.340940] installing Xen timer for CPU 3
[  144.340968] cpu 3 spinlock event irq 62
[  144.404393] CPU3 is up
[  144.404522] installing Xen timer for CPU 4
[  144.404548] cpu 4 spinlock event irq 69
[  144.468656] CPU4 is up
[  144.468780] installing Xen timer for CPU 5
[  144.468807] cpu 5 spinlock event irq 76
[  144.532834] CPU5 is up
[  144.532959] installing Xen timer for CPU 6
[  144.532986] cpu 6 spinlock event irq 83
[  144.597255] CPU6 is up
[  144.597481] installing Xen timer for CPU 7
[  144.597509] cpu 7 spinlock event irq 90
[  144.661253] CPU7 is up
[  144.662834] ACPI: Waking up from system sleep state S3

[1] https://patchwork.kernel.org/patch/1120842/
[2] https://patchwork.kernel.org/patch/1120872/


-- 
Javier Marcet <jmarcet@gmail.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 18 18:57:49 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Sep 2012 18:57:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TE2z8-0001Tx-Px; Tue, 18 Sep 2012 18:57:26 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jmarcet@gmail.com>) id 1TE2z7-0001Ts-OX
	for xen-devel@lists.xen.org; Tue, 18 Sep 2012 18:57:25 +0000
Received: from [85.158.143.99:15610] by server-2.bemta-4.messagelabs.com id
	D3/BA-06610-514C8505; Tue, 18 Sep 2012 18:57:25 +0000
X-Env-Sender: jmarcet@gmail.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1347994643!19638818!1
X-Originating-IP: [209.85.214.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-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20678 invoked from network); 18 Sep 2012 18:57:24 -0000
Received: from mail-ob0-f173.google.com (HELO mail-ob0-f173.google.com)
	(209.85.214.173)
	by server-16.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Sep 2012 18:57:24 -0000
Received: by obbta14 with SMTP id ta14so266721obb.32
	for <xen-devel@lists.xen.org>; Tue, 18 Sep 2012 11:57:22 -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=VVyHG8wKAGTrEuP0HMyJjHgkTUURx20cNm4XjUurS+k=;
	b=Yv+0hkYqx3sz5i6EyeTbzv6gZgmO/DLAC6zwiAEhiTbYMdODCI2olD8daJOdx2rxnf
	lvxQclfQb3iHkq0B9sLDd9BhaMl8J0XSUx325OiMi80/h40Tic1wXCdKukzJGw1z2gjA
	HaCinW+NG74krS+Kw0LxTaoTyLyaiRLPEIyIsaL9tzyFTl9Uc/VF2mBzuUUNvCw07GWI
	rkhSTIs+f/YxaOwkAxUxXUc4G4sagzStEelIxq/7oIR+Yik1URA4fCMyMjWY07UznVzP
	sR7d/UaqKFG980IQMrcOq/hAffPOm9s+tIzPOzcjtwLZRpcaG5UVh6f8BncHB2fA2PSJ
	3Qww==
Received: by 10.60.172.199 with SMTP id be7mr1097363oec.93.1347994642702; Tue,
	18 Sep 2012 11:57:22 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.60.138.225 with HTTP; Tue, 18 Sep 2012 11:57:02 -0700 (PDT)
From: Javier Marcet <jmarcet@gmail.com>
Date: Tue, 18 Sep 2012 20:57:02 +0200
Message-ID: <CAAnFQG9YZ0bsr=QnHaRxKTwNSCJvRiZ4ddCEMpsOZMNN+j7+vg@mail.gmail.com>
To: Xen Devel Mailing list <xen-devel@lists.xen.org>
Subject: [Xen-devel] Back trace from rcutree.c after resuming from S3
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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,

after solving the issue I had with a DVB tuner I tested again
suspending and resuming from S3.

I am now running Xen 4.2.0 and have applied patches [1] and [2] (any
idea why they are still not in mainline?) over a 3.5.3 kernel. I only
tried once since I upgraded my Xen, but after resuming I got the
following back trace:

[  142.267299] pcieport 0000:00:1c.5: wake-up capability enabled by ACPI
[  142.278312] ehci_hcd 0000:00:1d.0: wake-up capability enabled by ACPI
[  142.289169] ehci_hcd 0000:00:1a.0: wake-up capability enabled by ACPI
[  142.311116] xhci_hcd 0000:00:14.0: wake-up capability enabled by ACPI
[  142.322209] PM: noirq suspend of devices complete after 55.650 msecs
[  142.322778] ACPI: Preparing to enter system sleep state S3
[  142.723286] PM: Saving platform NVS memory
[  142.736453] Disabling non-boot CPUs ...
[  142.851387] ------------[ cut here ]------------
[  142.851397] WARNING: at
/home/storage/src/ubuntu-precise/kernel/rcutree.c:1550
rcu_do_batch.isra.41+0x5f/0x213()
[  142.851401] Hardware name: To Be Filled By O.E.M.
[  142.851404] Modules linked in: blktap(O) ip6table_filter ip6_tables
ipt_MASQUERADE iptable_nat nf_nat nf_conntrack_ipv4 nf_defrag_ipv4
xt_state nf_conntrack ipt_REJECT xt_CHECKSUM iptable_mangle xt_tcpudp
iptable_filter ip_tables x_tables [last unloaded: cx25840]
[  142.851466] Pid: 32, comm: migration/7 Tainted: G           O
3.5.0-14-i7 #18~precise1
[  142.851469] Call Trace:
[  142.851473]  <IRQ>  [<ffffffff8106a9bd>] warn_slowpath_common+0x7e/0x96
[  142.851488]  [<ffffffff8106a9ea>] warn_slowpath_null+0x15/0x17
[  142.851496]  [<ffffffff810c6e87>] rcu_do_batch.isra.41+0x5f/0x213
[  142.851504]  [<ffffffff810c687f>] ?
check_for_new_grace_period.isra.35+0x38/0x44
[  142.851512]  [<ffffffff810c7101>] __rcu_process_callbacks+0xc6/0xee
[  142.851520]  [<ffffffff810c7149>] rcu_process_callbacks+0x20/0x3e
[  142.851527]  [<ffffffff81070c27>] __do_softirq+0x87/0x113
[  142.851536]  [<ffffffff812e7b22>] ? __xen_evtchn_do_upcall+0x1a0/0x1dd
[  142.851546]  [<ffffffff8162f05c>] call_softirq+0x1c/0x30
[  142.851557]  [<ffffffff810343a3>] do_softirq+0x41/0x7e
[  142.851566]  [<ffffffff81070e66>] irq_exit+0x3f/0x9a
[  142.851573]  [<ffffffff812e95c9>] xen_evtchn_do_upcall+0x2c/0x39
[  142.851580]  [<ffffffff8162f0ae>] xen_do_hypervisor_callback+0x1e/0x30
[  142.851588]  <EOI>  [<ffffffff8100122a>] ? hypercall_page+0x22a/0x1000
[  142.851601]  [<ffffffff8100122a>] ? hypercall_page+0x22a/0x1000
[  142.851609]  [<ffffffff8102eee9>] ? xen_force_evtchn_callback+0xd/0xf
[  142.851618]  [<ffffffff8102f552>] ? check_events+0x12/0x20
[  142.851627]  [<ffffffff8102f53f>] ? xen_restore_fl_direct_reloc+0x4/0x4
[  142.851635]  [<ffffffff810b6ff4>] ? arch_local_irq_restore+0xb/0xd
[  142.851644]  [<ffffffff810b73f4>] ? stop_machine_cpu_stop+0xc1/0xd3
[  142.851652]  [<ffffffff810b7333>] ? queue_stop_cpus_work+0xb5/0xb5
[  142.851660]  [<ffffffff810b7152>] ? cpu_stopper_thread+0xf7/0x187
[  142.851667]  [<ffffffff8108a927>] ? finish_task_switch+0x82/0xc1
[  142.851676]  [<ffffffff8162c50b>] ? __schedule+0x428/0x454
[  142.851685]  [<ffffffff8162cff0>] ? _raw_spin_unlock_irqrestore+0x15/0x18
[  142.851693]  [<ffffffff810b705b>] ? cpu_stop_signal_done+0x30/0x30
[  142.851701]  [<ffffffff81082627>] ? kthread+0x86/0x8e
[  142.851710]  [<ffffffff8162ef64>] ? kernel_thread_helper+0x4/0x10
[  142.851718]  [<ffffffff8162d338>] ? retint_restore_args+0x5/0x6
[  142.851726]  [<ffffffff8162ef60>] ? gs_change+0x13/0x13
[  142.851736] ---[ end trace 3722a99bcc5ae37a ]---
[  144.257229] ACPI: Low-level resume complete
[  144.257322] PM: Restoring platform NVS memory
[  144.257866] Enabling non-boot CPUs ...
[  144.258042] installing Xen timer for CPU 1
[  144.258080] cpu 1 spinlock event irq 48
[  144.322077] CPU1 is up
[  144.322352] installing Xen timer for CPU 2
[  144.322379] cpu 2 spinlock event irq 55
[  144.340819] CPU2 is up
[  144.340940] installing Xen timer for CPU 3
[  144.340968] cpu 3 spinlock event irq 62
[  144.404393] CPU3 is up
[  144.404522] installing Xen timer for CPU 4
[  144.404548] cpu 4 spinlock event irq 69
[  144.468656] CPU4 is up
[  144.468780] installing Xen timer for CPU 5
[  144.468807] cpu 5 spinlock event irq 76
[  144.532834] CPU5 is up
[  144.532959] installing Xen timer for CPU 6
[  144.532986] cpu 6 spinlock event irq 83
[  144.597255] CPU6 is up
[  144.597481] installing Xen timer for CPU 7
[  144.597509] cpu 7 spinlock event irq 90
[  144.661253] CPU7 is up
[  144.662834] ACPI: Waking up from system sleep state S3

[1] https://patchwork.kernel.org/patch/1120842/
[2] https://patchwork.kernel.org/patch/1120872/


-- 
Javier Marcet <jmarcet@gmail.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 18 19:45:27 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Sep 2012 19:45: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 1TE3jD-0001yX-Q2; Tue, 18 Sep 2012 19:45:03 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ketuzsezr@gmail.com>) id 1TE3jB-0001yS-8g
	for xen-devel@lists.xen.org; Tue, 18 Sep 2012 19:45:01 +0000
X-Env-Sender: ketuzsezr@gmail.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1347997493!3821053!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-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15330 invoked from network); 18 Sep 2012 19:44:54 -0000
Received: from mail-qc0-f173.google.com (HELO mail-qc0-f173.google.com)
	(209.85.216.173)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Sep 2012 19:44:54 -0000
Received: by qcab12 with SMTP id b12so228991qca.32
	for <xen-devel@lists.xen.org>; Tue, 18 Sep 2012 12:44:52 -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:content-transfer-encoding
	:in-reply-to:user-agent;
	bh=KikhhxOHGqoSO9lkaD9p4vkuj8mXBr/FXmZScpMDnVw=;
	b=ep1WP+7QtO2TCPM0MD1gFPaXX7b4xm5R5j7YjH1VrhwH6KtowezrCnQozUuqvwc+6H
	TjIhn/0LMvL+6yCywMtph/IvYYS+y4xT5n2Gh9glagPcLYSXQ8Ea/ZoegMkgLnM0+Ykr
	eD9Tw7poD9LdhYJpdLbSF5H7Q/GP0SZqNNbGZlY7cw2fHgBXO5GWsVQUgS4BtLAftthS
	Zb+ptD0rW/9QlRKQ19iV1n0eU7kKOQlJrTo1g7HFqmHQdM0BMvrxkXyqgE2pOK3/Croc
	FFxhT8NFv8xvdPfg4Eeg9BXElPZ5m/VEt6HZALFT+g+vnQvXkJyUH44oUkS4Kz1ox3dd
	HvUg==
Received: by 10.224.176.144 with SMTP id be16mr1879517qab.83.1347997492654;
	Tue, 18 Sep 2012 12:44:52 -0700 (PDT)
Received: from phenom.dumpdata.com
	(50-195-21-189-static.hfc.comcastbusiness.net. [50.195.21.189])
	by mx.google.com with ESMTPS id bh14sm1046114qab.2.2012.09.18.12.44.51
	(version=TLSv1/SSLv3 cipher=OTHER);
	Tue, 18 Sep 2012 12:44:52 -0700 (PDT)
Date: Tue, 18 Sep 2012 15:34:02 -0400
From: Konrad Rzeszutek Wilk <konrad@kernel.org>
To: Javier Marcet <jmarcet@gmail.com>
Message-ID: <20120918193401.GA7667@phenom.dumpdata.com>
References: <CAAnFQG9TZj=SxYK_jxqN=M6L40vL=AZu9EM2tbEffPhkL1s8FA@mail.gmail.com>
	<CACJDEmqdqA6CE9SgLL2QCNmQH1dOX0_4OHfJfzes+G6bEkQ7FA@mail.gmail.com>
	<CAAnFQG-8Fkunv6R8+GCLAH4yQCx4-Nn0zN_Ntsf0wsh5yXeihQ@mail.gmail.com>
	<20120917142851.GB14012@phenom.dumpdata.com>
	<CAAnFQG9bUUU8OBeKxYh=O3rRrnEPb4r1bPCr-EHWHuUS8shBhA@mail.gmail.com>
	<CAAnFQG_VnZOYs3SJvO1Gc8P98kOW=6Wxc7tM_vEF8GiACgeVWg@mail.gmail.com>
	<CAAnFQG9s=Yh4od18q8xDOD7ukA4uurxCKWiLrULFkP66Zc+iPg@mail.gmail.com>
	<CAAnFQG9PuzRLSsCS8m_0VUeV+ZaCwK3zsbinxtuFBfdSihJknw@mail.gmail.com>
	<20120918171725.GA14462@phenom.dumpdata.com>
	<CAAnFQG_so_XmsWPPnzLOi=0nWB8d3Xos--L8=F4NZmoJ+9rLWg@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAAnFQG_so_XmsWPPnzLOi=0nWB8d3Xos--L8=F4NZmoJ+9rLWg@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: Xen Devel Mailing list <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.2.0-rc4 issues with DVB tuner
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="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, Sep 18, 2012 at 08:26:33PM +0200, Javier Marcet wrote:
> On Tue, Sep 18, 2012 at 7:17 PM, Konrad Rzeszutek Wilk
> <konrad@kernel.org> wrote:
> =

> >> I have some news from the linux-media mailing list. There, Devin Heitm=
ueller,
> >> said this:
> >>
> >> """
> >> > Initially I thought Xen would be the cause of the problem, but after
> >> > having written on
> >> > the Xen development mailing list and talked about it with a couple
> >> > developers, it isn't
> >> > very clear where the problem is. So far I haven't been able to get t=
he
> >> > smallest warning
> >> > or error.
> >>
> >> This is a very common problem when attempting to use any PCI/PCIe
> >> tuner under a hypervisor.  Essentially the issue is all of the
> >> virtualization solutions provide very poor interrupt latency, which
> >> results in the data being lost.
> >>
> >> Devices delivering a high bitrate stream of data in realtime are much
> >> more likely for this problem to be visible since such devices have
> >> very little buffering (it's not like a hard drive controller where it
> >> can just deliver the data slower).  The problem is not specific to the
> >> cx23885 - pretty much all of the PCI/PCIe bridges used in tuner cards
> >> work this way, and they cannot really be blamed for expecting to run
> >> in an environment with really crappy interrupt latency.
> >>
> >> I won't go as far as to say, "abandon all hope", but you're not really
> >> likely to find any help in this forum.
> >> """
> >
> > Not sure about the interrupt latency. If you run this little program
> > http://darnok.org/xen/read_interrupts.c
> > when capturing in both dom0 and in baremetal are the rate about the
> > same?
> >>
> >> What I don=B4t understand is how graphics pass through even works
> >> and a tuner card has problems due to the introduced latencies in the
> >> IRQs.
> >
> > The latency is very very miniscule. One could actually verify that this
> > is a problem by inserting said latency in the driver so that under
> > baremetal the latency would show up.
> >
> > But the other issue is that if the data is being lost you would at least
> > get some. So the buffers ought to have "something" in them? Maybe that
> > depends on what compression you use on the coder? If you jus do YUV420
> > or the RGB variants and just do a simple 'cat /dev/vide0 > /tmp/file'
> > does the output contain anything? Or is just a blob of empty data?
> =

> The output contains data, part of the mpeg stream without any continuity.
> =

I see.
> >> Do you have any more info about this?
> >
> > The other issue could be related to the vmalloc_32 being in usage
> > and not using the DMA API.
> >
> > I recall posting a patch for this .. Ah:
> > http://lists.xen.org/archives/html/xen-devel/2012-01/msg01927.html
> >
> > Perhaps this is the issue?
> =

> Bingo Konrad! That was it :) At least I have just applied the patch,
> rebooted under Xen and this time I got a good dump.

Woohoo!
> =

> Right now I have my usual system running flawlessly under Xen. Time to
> take a look again at the suspend/resume issue which I nearly had
> working a few days ago.

Keep in mind that for the suspend/resume you need out of mainline
patches for right now. I hadn't yet upstreamed all the parts. They are
in  git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
devel/acpi-s3.vXX (I believe 11 would apply cleanly to your tree?)

Keep in mind that there were some bugs in Xen 4.2 in regards to resume.
Look on xen-devel for emails between Jan and Ben Guthro.
> =

> Thanks a lot for all your help :)
> =

> P.S. I'm going to post this info on the linux media mailing list.

If you could CC me on it I can provide the technical explanation
for the 'DMA-API-ing the vmalloc_32' call.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 18 19:45:27 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Sep 2012 19:45: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 1TE3jD-0001yX-Q2; Tue, 18 Sep 2012 19:45:03 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ketuzsezr@gmail.com>) id 1TE3jB-0001yS-8g
	for xen-devel@lists.xen.org; Tue, 18 Sep 2012 19:45:01 +0000
X-Env-Sender: ketuzsezr@gmail.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1347997493!3821053!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-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15330 invoked from network); 18 Sep 2012 19:44:54 -0000
Received: from mail-qc0-f173.google.com (HELO mail-qc0-f173.google.com)
	(209.85.216.173)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Sep 2012 19:44:54 -0000
Received: by qcab12 with SMTP id b12so228991qca.32
	for <xen-devel@lists.xen.org>; Tue, 18 Sep 2012 12:44:52 -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:content-transfer-encoding
	:in-reply-to:user-agent;
	bh=KikhhxOHGqoSO9lkaD9p4vkuj8mXBr/FXmZScpMDnVw=;
	b=ep1WP+7QtO2TCPM0MD1gFPaXX7b4xm5R5j7YjH1VrhwH6KtowezrCnQozUuqvwc+6H
	TjIhn/0LMvL+6yCywMtph/IvYYS+y4xT5n2Gh9glagPcLYSXQ8Ea/ZoegMkgLnM0+Ykr
	eD9Tw7poD9LdhYJpdLbSF5H7Q/GP0SZqNNbGZlY7cw2fHgBXO5GWsVQUgS4BtLAftthS
	Zb+ptD0rW/9QlRKQ19iV1n0eU7kKOQlJrTo1g7HFqmHQdM0BMvrxkXyqgE2pOK3/Croc
	FFxhT8NFv8xvdPfg4Eeg9BXElPZ5m/VEt6HZALFT+g+vnQvXkJyUH44oUkS4Kz1ox3dd
	HvUg==
Received: by 10.224.176.144 with SMTP id be16mr1879517qab.83.1347997492654;
	Tue, 18 Sep 2012 12:44:52 -0700 (PDT)
Received: from phenom.dumpdata.com
	(50-195-21-189-static.hfc.comcastbusiness.net. [50.195.21.189])
	by mx.google.com with ESMTPS id bh14sm1046114qab.2.2012.09.18.12.44.51
	(version=TLSv1/SSLv3 cipher=OTHER);
	Tue, 18 Sep 2012 12:44:52 -0700 (PDT)
Date: Tue, 18 Sep 2012 15:34:02 -0400
From: Konrad Rzeszutek Wilk <konrad@kernel.org>
To: Javier Marcet <jmarcet@gmail.com>
Message-ID: <20120918193401.GA7667@phenom.dumpdata.com>
References: <CAAnFQG9TZj=SxYK_jxqN=M6L40vL=AZu9EM2tbEffPhkL1s8FA@mail.gmail.com>
	<CACJDEmqdqA6CE9SgLL2QCNmQH1dOX0_4OHfJfzes+G6bEkQ7FA@mail.gmail.com>
	<CAAnFQG-8Fkunv6R8+GCLAH4yQCx4-Nn0zN_Ntsf0wsh5yXeihQ@mail.gmail.com>
	<20120917142851.GB14012@phenom.dumpdata.com>
	<CAAnFQG9bUUU8OBeKxYh=O3rRrnEPb4r1bPCr-EHWHuUS8shBhA@mail.gmail.com>
	<CAAnFQG_VnZOYs3SJvO1Gc8P98kOW=6Wxc7tM_vEF8GiACgeVWg@mail.gmail.com>
	<CAAnFQG9s=Yh4od18q8xDOD7ukA4uurxCKWiLrULFkP66Zc+iPg@mail.gmail.com>
	<CAAnFQG9PuzRLSsCS8m_0VUeV+ZaCwK3zsbinxtuFBfdSihJknw@mail.gmail.com>
	<20120918171725.GA14462@phenom.dumpdata.com>
	<CAAnFQG_so_XmsWPPnzLOi=0nWB8d3Xos--L8=F4NZmoJ+9rLWg@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAAnFQG_so_XmsWPPnzLOi=0nWB8d3Xos--L8=F4NZmoJ+9rLWg@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: Xen Devel Mailing list <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.2.0-rc4 issues with DVB tuner
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="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, Sep 18, 2012 at 08:26:33PM +0200, Javier Marcet wrote:
> On Tue, Sep 18, 2012 at 7:17 PM, Konrad Rzeszutek Wilk
> <konrad@kernel.org> wrote:
> =

> >> I have some news from the linux-media mailing list. There, Devin Heitm=
ueller,
> >> said this:
> >>
> >> """
> >> > Initially I thought Xen would be the cause of the problem, but after
> >> > having written on
> >> > the Xen development mailing list and talked about it with a couple
> >> > developers, it isn't
> >> > very clear where the problem is. So far I haven't been able to get t=
he
> >> > smallest warning
> >> > or error.
> >>
> >> This is a very common problem when attempting to use any PCI/PCIe
> >> tuner under a hypervisor.  Essentially the issue is all of the
> >> virtualization solutions provide very poor interrupt latency, which
> >> results in the data being lost.
> >>
> >> Devices delivering a high bitrate stream of data in realtime are much
> >> more likely for this problem to be visible since such devices have
> >> very little buffering (it's not like a hard drive controller where it
> >> can just deliver the data slower).  The problem is not specific to the
> >> cx23885 - pretty much all of the PCI/PCIe bridges used in tuner cards
> >> work this way, and they cannot really be blamed for expecting to run
> >> in an environment with really crappy interrupt latency.
> >>
> >> I won't go as far as to say, "abandon all hope", but you're not really
> >> likely to find any help in this forum.
> >> """
> >
> > Not sure about the interrupt latency. If you run this little program
> > http://darnok.org/xen/read_interrupts.c
> > when capturing in both dom0 and in baremetal are the rate about the
> > same?
> >>
> >> What I don=B4t understand is how graphics pass through even works
> >> and a tuner card has problems due to the introduced latencies in the
> >> IRQs.
> >
> > The latency is very very miniscule. One could actually verify that this
> > is a problem by inserting said latency in the driver so that under
> > baremetal the latency would show up.
> >
> > But the other issue is that if the data is being lost you would at least
> > get some. So the buffers ought to have "something" in them? Maybe that
> > depends on what compression you use on the coder? If you jus do YUV420
> > or the RGB variants and just do a simple 'cat /dev/vide0 > /tmp/file'
> > does the output contain anything? Or is just a blob of empty data?
> =

> The output contains data, part of the mpeg stream without any continuity.
> =

I see.
> >> Do you have any more info about this?
> >
> > The other issue could be related to the vmalloc_32 being in usage
> > and not using the DMA API.
> >
> > I recall posting a patch for this .. Ah:
> > http://lists.xen.org/archives/html/xen-devel/2012-01/msg01927.html
> >
> > Perhaps this is the issue?
> =

> Bingo Konrad! That was it :) At least I have just applied the patch,
> rebooted under Xen and this time I got a good dump.

Woohoo!
> =

> Right now I have my usual system running flawlessly under Xen. Time to
> take a look again at the suspend/resume issue which I nearly had
> working a few days ago.

Keep in mind that for the suspend/resume you need out of mainline
patches for right now. I hadn't yet upstreamed all the parts. They are
in  git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
devel/acpi-s3.vXX (I believe 11 would apply cleanly to your tree?)

Keep in mind that there were some bugs in Xen 4.2 in regards to resume.
Look on xen-devel for emails between Jan and Ben Guthro.
> =

> Thanks a lot for all your help :)
> =

> P.S. I'm going to post this info on the linux media mailing list.

If you could CC me on it I can provide the technical explanation
for the 'DMA-API-ing the vmalloc_32' call.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 18 19:58:38 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Sep 2012 19: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 1TE3w1-00028T-4j; Tue, 18 Sep 2012 19:58:17 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jmarcet@gmail.com>) id 1TE3w0-00028O-0y
	for xen-devel@lists.xen.org; Tue, 18 Sep 2012 19:58:16 +0000
Received: from [85.158.143.35:33141] by server-3.bemta-4.messagelabs.com id
	6C/91-08232-752D8505; Tue, 18 Sep 2012 19:58:15 +0000
X-Env-Sender: jmarcet@gmail.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1347998282!18845894!1
X-Originating-IP: [209.85.219.45]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
	ML_RADAR_SPEW_LINKS_14,ML_RADAR_SPEW_LINKS_19,ML_RADAR_SPEW_LINKS_8,
	RCVD_BY_IP,spamassassin: ,surbl: (ASYNC_NO) 
	c3VyYmxfcmVjaGVja19kZWxheTogNTc5NzgxMSAoYWJhbmRvbmVkOiBnb28uZ2wvdllLNDIp\
	n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19575 invoked from network); 18 Sep 2012 19:58:04 -0000
Received: from mail-oa0-f45.google.com (HELO mail-oa0-f45.google.com)
	(209.85.219.45)
	by server-6.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Sep 2012 19:58:04 -0000
Received: by oagn12 with SMTP id n12so339003oag.32
	for <xen-devel@lists.xen.org>; Tue, 18 Sep 2012 12:58:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to
	:cc:content-type:content-transfer-encoding;
	bh=VVR3ELjUG+fDi6S7WCDtZhypQB+YLqN3jaETLhh0fhE=;
	b=bqOn4eot8aKJvD1OAZSLmsf8BMHPaFEW2C616/qHjOIL5oCBvI3ecnjSd/leD1df+X
	X+datfC/mNjMyTtuUNG/GakFfZr3kbKZZ1SMNZMealMaCqcGTYO9jB76ww+9wDW2nSpN
	Ld6hs468TesacWwAh0YVv7Msjlu22dh5Y+iOYs1m+LhgtBKmbATuzBqzwNE+YeqMl+kC
	Kwws1QXG8kOQjO9Eko0dMKD0HHY/umhScYXvZmBUeQjWZpAMr9IAKwETfPBu6xDkFd1k
	Pmi3suWUiMNNlEbHGoOZSeuVibRr+0H07KopznFDyde48OMgY7if4OiUWgZNcythd3kC
	cMfQ==
Received: by 10.60.25.226 with SMTP id f2mr1297473oeg.53.1347998282334; Tue,
	18 Sep 2012 12:58:02 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.60.138.225 with HTTP; Tue, 18 Sep 2012 12:57:42 -0700 (PDT)
In-Reply-To: <20120918193401.GA7667@phenom.dumpdata.com>
References: <CAAnFQG9TZj=SxYK_jxqN=M6L40vL=AZu9EM2tbEffPhkL1s8FA@mail.gmail.com>
	<CACJDEmqdqA6CE9SgLL2QCNmQH1dOX0_4OHfJfzes+G6bEkQ7FA@mail.gmail.com>
	<CAAnFQG-8Fkunv6R8+GCLAH4yQCx4-Nn0zN_Ntsf0wsh5yXeihQ@mail.gmail.com>
	<20120917142851.GB14012@phenom.dumpdata.com>
	<CAAnFQG9bUUU8OBeKxYh=O3rRrnEPb4r1bPCr-EHWHuUS8shBhA@mail.gmail.com>
	<CAAnFQG_VnZOYs3SJvO1Gc8P98kOW=6Wxc7tM_vEF8GiACgeVWg@mail.gmail.com>
	<CAAnFQG9s=Yh4od18q8xDOD7ukA4uurxCKWiLrULFkP66Zc+iPg@mail.gmail.com>
	<CAAnFQG9PuzRLSsCS8m_0VUeV+ZaCwK3zsbinxtuFBfdSihJknw@mail.gmail.com>
	<20120918171725.GA14462@phenom.dumpdata.com>
	<CAAnFQG_so_XmsWPPnzLOi=0nWB8d3Xos--L8=F4NZmoJ+9rLWg@mail.gmail.com>
	<20120918193401.GA7667@phenom.dumpdata.com>
From: Javier Marcet <jmarcet@gmail.com>
Date: Tue, 18 Sep 2012 21:57:42 +0200
Message-ID: <CAAnFQG8gmB52mbqP04_OZhDyWe22EfZ58HrYLk-CaE6oHisNiw@mail.gmail.com>
To: Konrad Rzeszutek Wilk <konrad@kernel.org>
Cc: Xen Devel Mailing list <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.2.0-rc4 issues with DVB tuner
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gVHVlLCBTZXAgMTgsIDIwMTIgYXQgOTozNCBQTSwgS29ucmFkIFJ6ZXN6dXRlayBXaWxrCjxr
b25yYWRAa2VybmVsLm9yZz4gd3JvdGU6Cgo+PiA+PiBUaGlzIGlzIGEgdmVyeSBjb21tb24gcHJv
YmxlbSB3aGVuIGF0dGVtcHRpbmcgdG8gdXNlIGFueSBQQ0kvUENJZQo+PiA+PiB0dW5lciB1bmRl
ciBhIGh5cGVydmlzb3IuICBFc3NlbnRpYWxseSB0aGUgaXNzdWUgaXMgYWxsIG9mIHRoZQo+PiA+
PiB2aXJ0dWFsaXphdGlvbiBzb2x1dGlvbnMgcHJvdmlkZSB2ZXJ5IHBvb3IgaW50ZXJydXB0IGxh
dGVuY3ksIHdoaWNoCj4+ID4+IHJlc3VsdHMgaW4gdGhlIGRhdGEgYmVpbmcgbG9zdC4KPj4gPj4K
Pj4gPj4gRGV2aWNlcyBkZWxpdmVyaW5nIGEgaGlnaCBiaXRyYXRlIHN0cmVhbSBvZiBkYXRhIGlu
IHJlYWx0aW1lIGFyZSBtdWNoCj4+ID4+IG1vcmUgbGlrZWx5IGZvciB0aGlzIHByb2JsZW0gdG8g
YmUgdmlzaWJsZSBzaW5jZSBzdWNoIGRldmljZXMgaGF2ZQo+PiA+PiB2ZXJ5IGxpdHRsZSBidWZm
ZXJpbmcgKGl0J3Mgbm90IGxpa2UgYSBoYXJkIGRyaXZlIGNvbnRyb2xsZXIgd2hlcmUgaXQKPj4g
Pj4gY2FuIGp1c3QgZGVsaXZlciB0aGUgZGF0YSBzbG93ZXIpLiAgVGhlIHByb2JsZW0gaXMgbm90
IHNwZWNpZmljIHRvIHRoZQo+PiA+PiBjeDIzODg1IC0gcHJldHR5IG11Y2ggYWxsIG9mIHRoZSBQ
Q0kvUENJZSBicmlkZ2VzIHVzZWQgaW4gdHVuZXIgY2FyZHMKPj4gPj4gd29yayB0aGlzIHdheSwg
YW5kIHRoZXkgY2Fubm90IHJlYWxseSBiZSBibGFtZWQgZm9yIGV4cGVjdGluZyB0byBydW4KPj4g
Pj4gaW4gYW4gZW52aXJvbm1lbnQgd2l0aCByZWFsbHkgY3JhcHB5IGludGVycnVwdCBsYXRlbmN5
Lgo+PiA+Pgo+PiA+PiBJIHdvbid0IGdvIGFzIGZhciBhcyB0byBzYXksICJhYmFuZG9uIGFsbCBo
b3BlIiwgYnV0IHlvdSdyZSBub3QgcmVhbGx5Cj4+ID4+IGxpa2VseSB0byBmaW5kIGFueSBoZWxw
IGluIHRoaXMgZm9ydW0uCj4+ID4+ICIiIgo+PiA+Cj4+ID4gTm90IHN1cmUgYWJvdXQgdGhlIGlu
dGVycnVwdCBsYXRlbmN5LiBJZiB5b3UgcnVuIHRoaXMgbGl0dGxlIHByb2dyYW0KPj4gPiBodHRw
Oi8vZGFybm9rLm9yZy94ZW4vcmVhZF9pbnRlcnJ1cHRzLmMKPj4gPiB3aGVuIGNhcHR1cmluZyBp
biBib3RoIGRvbTAgYW5kIGluIGJhcmVtZXRhbCBhcmUgdGhlIHJhdGUgYWJvdXQgdGhlCj4+ID4g
c2FtZT8KPj4gPj4KPj4gPj4gV2hhdCBJIGRvbsK0dCB1bmRlcnN0YW5kIGlzIGhvdyBncmFwaGlj
cyBwYXNzIHRocm91Z2ggZXZlbiB3b3Jrcwo+PiA+PiBhbmQgYSB0dW5lciBjYXJkIGhhcyBwcm9i
bGVtcyBkdWUgdG8gdGhlIGludHJvZHVjZWQgbGF0ZW5jaWVzIGluIHRoZQo+PiA+PiBJUlFzLgo+
PiA+Cj4+ID4gVGhlIGxhdGVuY3kgaXMgdmVyeSB2ZXJ5IG1pbmlzY3VsZS4gT25lIGNvdWxkIGFj
dHVhbGx5IHZlcmlmeSB0aGF0IHRoaXMKPj4gPiBpcyBhIHByb2JsZW0gYnkgaW5zZXJ0aW5nIHNh
aWQgbGF0ZW5jeSBpbiB0aGUgZHJpdmVyIHNvIHRoYXQgdW5kZXIKPj4gPiBiYXJlbWV0YWwgdGhl
IGxhdGVuY3kgd291bGQgc2hvdyB1cC4KPj4gPgo+PiA+IEJ1dCB0aGUgb3RoZXIgaXNzdWUgaXMg
dGhhdCBpZiB0aGUgZGF0YSBpcyBiZWluZyBsb3N0IHlvdSB3b3VsZCBhdCBsZWFzdAo+PiA+IGdl
dCBzb21lLiBTbyB0aGUgYnVmZmVycyBvdWdodCB0byBoYXZlICJzb21ldGhpbmciIGluIHRoZW0/
IE1heWJlIHRoYXQKPj4gPiBkZXBlbmRzIG9uIHdoYXQgY29tcHJlc3Npb24geW91IHVzZSBvbiB0
aGUgY29kZXI/IElmIHlvdSBqdXMgZG8gWVVWNDIwCj4+ID4gb3IgdGhlIFJHQiB2YXJpYW50cyBh
bmQganVzdCBkbyBhIHNpbXBsZSAnY2F0IC9kZXYvdmlkZTAgPiAvdG1wL2ZpbGUnCj4+ID4gZG9l
cyB0aGUgb3V0cHV0IGNvbnRhaW4gYW55dGhpbmc/IE9yIGlzIGp1c3QgYSBibG9iIG9mIGVtcHR5
IGRhdGE/Cj4+Cj4+IFRoZSBvdXRwdXQgY29udGFpbnMgZGF0YSwgcGFydCBvZiB0aGUgbXBlZyBz
dHJlYW0gd2l0aG91dCBhbnkgY29udGludWl0eS4KPj4KPiBJIHNlZS4KPj4gPj4gRG8geW91IGhh
dmUgYW55IG1vcmUgaW5mbyBhYm91dCB0aGlzPwo+PiA+Cj4+ID4gVGhlIG90aGVyIGlzc3VlIGNv
dWxkIGJlIHJlbGF0ZWQgdG8gdGhlIHZtYWxsb2NfMzIgYmVpbmcgaW4gdXNhZ2UKPj4gPiBhbmQg
bm90IHVzaW5nIHRoZSBETUEgQVBJLgo+PiA+Cj4+ID4gSSByZWNhbGwgcG9zdGluZyBhIHBhdGNo
IGZvciB0aGlzIC4uIEFoOgo+PiA+IGh0dHA6Ly9saXN0cy54ZW4ub3JnL2FyY2hpdmVzL2h0bWwv
eGVuLWRldmVsLzIwMTItMDEvbXNnMDE5MjcuaHRtbAo+PiA+Cj4+ID4gUGVyaGFwcyB0aGlzIGlz
IHRoZSBpc3N1ZT8KPj4KPj4gQmluZ28gS29ucmFkISBUaGF0IHdhcyBpdCA6KSBBdCBsZWFzdCBJ
IGhhdmUganVzdCBhcHBsaWVkIHRoZSBwYXRjaCwKPj4gcmVib290ZWQgdW5kZXIgWGVuIGFuZCB0
aGlzIHRpbWUgSSBnb3QgYSBnb29kIGR1bXAuCj4KPiBXb29ob28hCgo6KQoKPj4gUmlnaHQgbm93
IEkgaGF2ZSBteSB1c3VhbCBzeXN0ZW0gcnVubmluZyBmbGF3bGVzc2x5IHVuZGVyIFhlbi4gVGlt
ZSB0bwo+PiB0YWtlIGEgbG9vayBhZ2FpbiBhdCB0aGUgc3VzcGVuZC9yZXN1bWUgaXNzdWUgd2hp
Y2ggSSBuZWFybHkgaGFkCj4+IHdvcmtpbmcgYSBmZXcgZGF5cyBhZ28uCj4KPiBLZWVwIGluIG1p
bmQgdGhhdCBmb3IgdGhlIHN1c3BlbmQvcmVzdW1lIHlvdSBuZWVkIG91dCBvZiBtYWlubGluZQo+
IHBhdGNoZXMgZm9yIHJpZ2h0IG5vdy4gSSBoYWRuJ3QgeWV0IHVwc3RyZWFtZWQgYWxsIHRoZSBw
YXJ0cy4gVGhleSBhcmUKPiBpbiAgZ2l0Oi8vZ2l0Lmtlcm5lbC5vcmcvcHViL3NjbS9saW51eC9r
ZXJuZWwvZ2l0L2tvbnJhZC94ZW4uZ2l0Cj4gZGV2ZWwvYWNwaS1zMy52WFggKEkgYmVsaWV2ZSAx
MSB3b3VsZCBhcHBseSBjbGVhbmx5IHRvIHlvdXIgdHJlZT8pCj4KPiBLZWVwIGluIG1pbmQgdGhh
dCB0aGVyZSB3ZXJlIHNvbWUgYnVncyBpbiBYZW4gNC4yIGluIHJlZ2FyZHMgdG8gcmVzdW1lLgo+
IExvb2sgb24geGVuLWRldmVsIGZvciBlbWFpbHMgYmV0d2VlbiBKYW4gYW5kIEJlbiBHdXRocm8u
CgpJIGhhdmUgdGhlIG5lZWRlZCBwYXRjaGVzIGluIHBsYWNlIGFuZCBJIGhhdmUgZm9sbG93ZWQg
dGhhdCB0aHJlYWQsIGF0CmxlYXN0IHVudGlsIGEgZmV3IGRheXMgYWdvLiBJIGhhdmUgb3BlbmVk
IGEgbmV3IG9uZSBhYm91dCB0aGUgb25seQpwcm9ibGVtIEkgc3RpbGwgaGF2ZSB3aXRoIFMzOiBo
dHRwOi8vZ29vLmdsL3ZZSzQyCgo+PiBUaGFua3MgYSBsb3QgZm9yIGFsbCB5b3VyIGhlbHAgOikK
Pj4KPj4gUC5TLiBJJ20gZ29pbmcgdG8gcG9zdCB0aGlzIGluZm8gb24gdGhlIGxpbnV4IG1lZGlh
IG1haWxpbmcgbGlzdC4KPgo+IElmIHlvdSBjb3VsZCBDQyBtZSBvbiBpdCBJIGNhbiBwcm92aWRl
IHRoZSB0ZWNobmljYWwgZXhwbGFuYXRpb24KPiBmb3IgdGhlICdETUEtQVBJLWluZyB0aGUgdm1h
bGxvY18zMicgY2FsbC4KCkkgaGF2ZSBDQ2VkIHlvdSBpbiBteSBsYXN0IHJlcGx5IHRvIHRoZSB0
aHJlYWQuIEknbSBwcmV0dHkgY2VydGFpbgpEZXZpbiB1bmRlcnN0b29kIHdlbGwgdGhlIHByb2Js
ZW0gYW5kIHdoYXQgdGhlIHNvbHV0aW9uIHlvdXIgcGF0Y2gKZ2l2ZXMuCgoKLS0gCkphdmllciBN
YXJjZXQgPGptYXJjZXRAZ21haWwuY29tPgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMu
eGVuLm9yZwpodHRwOi8vbGlzdHMueGVuLm9yZy94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xen.org Tue Sep 18 19:58:38 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Sep 2012 19: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 1TE3w1-00028T-4j; Tue, 18 Sep 2012 19:58:17 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jmarcet@gmail.com>) id 1TE3w0-00028O-0y
	for xen-devel@lists.xen.org; Tue, 18 Sep 2012 19:58:16 +0000
Received: from [85.158.143.35:33141] by server-3.bemta-4.messagelabs.com id
	6C/91-08232-752D8505; Tue, 18 Sep 2012 19:58:15 +0000
X-Env-Sender: jmarcet@gmail.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1347998282!18845894!1
X-Originating-IP: [209.85.219.45]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
	ML_RADAR_SPEW_LINKS_14,ML_RADAR_SPEW_LINKS_19,ML_RADAR_SPEW_LINKS_8,
	RCVD_BY_IP,spamassassin: ,surbl: (ASYNC_NO) 
	c3VyYmxfcmVjaGVja19kZWxheTogNTc5NzgxMSAoYWJhbmRvbmVkOiBnb28uZ2wvdllLNDIp\
	n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19575 invoked from network); 18 Sep 2012 19:58:04 -0000
Received: from mail-oa0-f45.google.com (HELO mail-oa0-f45.google.com)
	(209.85.219.45)
	by server-6.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Sep 2012 19:58:04 -0000
Received: by oagn12 with SMTP id n12so339003oag.32
	for <xen-devel@lists.xen.org>; Tue, 18 Sep 2012 12:58:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to
	:cc:content-type:content-transfer-encoding;
	bh=VVR3ELjUG+fDi6S7WCDtZhypQB+YLqN3jaETLhh0fhE=;
	b=bqOn4eot8aKJvD1OAZSLmsf8BMHPaFEW2C616/qHjOIL5oCBvI3ecnjSd/leD1df+X
	X+datfC/mNjMyTtuUNG/GakFfZr3kbKZZ1SMNZMealMaCqcGTYO9jB76ww+9wDW2nSpN
	Ld6hs468TesacWwAh0YVv7Msjlu22dh5Y+iOYs1m+LhgtBKmbATuzBqzwNE+YeqMl+kC
	Kwws1QXG8kOQjO9Eko0dMKD0HHY/umhScYXvZmBUeQjWZpAMr9IAKwETfPBu6xDkFd1k
	Pmi3suWUiMNNlEbHGoOZSeuVibRr+0H07KopznFDyde48OMgY7if4OiUWgZNcythd3kC
	cMfQ==
Received: by 10.60.25.226 with SMTP id f2mr1297473oeg.53.1347998282334; Tue,
	18 Sep 2012 12:58:02 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.60.138.225 with HTTP; Tue, 18 Sep 2012 12:57:42 -0700 (PDT)
In-Reply-To: <20120918193401.GA7667@phenom.dumpdata.com>
References: <CAAnFQG9TZj=SxYK_jxqN=M6L40vL=AZu9EM2tbEffPhkL1s8FA@mail.gmail.com>
	<CACJDEmqdqA6CE9SgLL2QCNmQH1dOX0_4OHfJfzes+G6bEkQ7FA@mail.gmail.com>
	<CAAnFQG-8Fkunv6R8+GCLAH4yQCx4-Nn0zN_Ntsf0wsh5yXeihQ@mail.gmail.com>
	<20120917142851.GB14012@phenom.dumpdata.com>
	<CAAnFQG9bUUU8OBeKxYh=O3rRrnEPb4r1bPCr-EHWHuUS8shBhA@mail.gmail.com>
	<CAAnFQG_VnZOYs3SJvO1Gc8P98kOW=6Wxc7tM_vEF8GiACgeVWg@mail.gmail.com>
	<CAAnFQG9s=Yh4od18q8xDOD7ukA4uurxCKWiLrULFkP66Zc+iPg@mail.gmail.com>
	<CAAnFQG9PuzRLSsCS8m_0VUeV+ZaCwK3zsbinxtuFBfdSihJknw@mail.gmail.com>
	<20120918171725.GA14462@phenom.dumpdata.com>
	<CAAnFQG_so_XmsWPPnzLOi=0nWB8d3Xos--L8=F4NZmoJ+9rLWg@mail.gmail.com>
	<20120918193401.GA7667@phenom.dumpdata.com>
From: Javier Marcet <jmarcet@gmail.com>
Date: Tue, 18 Sep 2012 21:57:42 +0200
Message-ID: <CAAnFQG8gmB52mbqP04_OZhDyWe22EfZ58HrYLk-CaE6oHisNiw@mail.gmail.com>
To: Konrad Rzeszutek Wilk <konrad@kernel.org>
Cc: Xen Devel Mailing list <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.2.0-rc4 issues with DVB tuner
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gVHVlLCBTZXAgMTgsIDIwMTIgYXQgOTozNCBQTSwgS29ucmFkIFJ6ZXN6dXRlayBXaWxrCjxr
b25yYWRAa2VybmVsLm9yZz4gd3JvdGU6Cgo+PiA+PiBUaGlzIGlzIGEgdmVyeSBjb21tb24gcHJv
YmxlbSB3aGVuIGF0dGVtcHRpbmcgdG8gdXNlIGFueSBQQ0kvUENJZQo+PiA+PiB0dW5lciB1bmRl
ciBhIGh5cGVydmlzb3IuICBFc3NlbnRpYWxseSB0aGUgaXNzdWUgaXMgYWxsIG9mIHRoZQo+PiA+
PiB2aXJ0dWFsaXphdGlvbiBzb2x1dGlvbnMgcHJvdmlkZSB2ZXJ5IHBvb3IgaW50ZXJydXB0IGxh
dGVuY3ksIHdoaWNoCj4+ID4+IHJlc3VsdHMgaW4gdGhlIGRhdGEgYmVpbmcgbG9zdC4KPj4gPj4K
Pj4gPj4gRGV2aWNlcyBkZWxpdmVyaW5nIGEgaGlnaCBiaXRyYXRlIHN0cmVhbSBvZiBkYXRhIGlu
IHJlYWx0aW1lIGFyZSBtdWNoCj4+ID4+IG1vcmUgbGlrZWx5IGZvciB0aGlzIHByb2JsZW0gdG8g
YmUgdmlzaWJsZSBzaW5jZSBzdWNoIGRldmljZXMgaGF2ZQo+PiA+PiB2ZXJ5IGxpdHRsZSBidWZm
ZXJpbmcgKGl0J3Mgbm90IGxpa2UgYSBoYXJkIGRyaXZlIGNvbnRyb2xsZXIgd2hlcmUgaXQKPj4g
Pj4gY2FuIGp1c3QgZGVsaXZlciB0aGUgZGF0YSBzbG93ZXIpLiAgVGhlIHByb2JsZW0gaXMgbm90
IHNwZWNpZmljIHRvIHRoZQo+PiA+PiBjeDIzODg1IC0gcHJldHR5IG11Y2ggYWxsIG9mIHRoZSBQ
Q0kvUENJZSBicmlkZ2VzIHVzZWQgaW4gdHVuZXIgY2FyZHMKPj4gPj4gd29yayB0aGlzIHdheSwg
YW5kIHRoZXkgY2Fubm90IHJlYWxseSBiZSBibGFtZWQgZm9yIGV4cGVjdGluZyB0byBydW4KPj4g
Pj4gaW4gYW4gZW52aXJvbm1lbnQgd2l0aCByZWFsbHkgY3JhcHB5IGludGVycnVwdCBsYXRlbmN5
Lgo+PiA+Pgo+PiA+PiBJIHdvbid0IGdvIGFzIGZhciBhcyB0byBzYXksICJhYmFuZG9uIGFsbCBo
b3BlIiwgYnV0IHlvdSdyZSBub3QgcmVhbGx5Cj4+ID4+IGxpa2VseSB0byBmaW5kIGFueSBoZWxw
IGluIHRoaXMgZm9ydW0uCj4+ID4+ICIiIgo+PiA+Cj4+ID4gTm90IHN1cmUgYWJvdXQgdGhlIGlu
dGVycnVwdCBsYXRlbmN5LiBJZiB5b3UgcnVuIHRoaXMgbGl0dGxlIHByb2dyYW0KPj4gPiBodHRw
Oi8vZGFybm9rLm9yZy94ZW4vcmVhZF9pbnRlcnJ1cHRzLmMKPj4gPiB3aGVuIGNhcHR1cmluZyBp
biBib3RoIGRvbTAgYW5kIGluIGJhcmVtZXRhbCBhcmUgdGhlIHJhdGUgYWJvdXQgdGhlCj4+ID4g
c2FtZT8KPj4gPj4KPj4gPj4gV2hhdCBJIGRvbsK0dCB1bmRlcnN0YW5kIGlzIGhvdyBncmFwaGlj
cyBwYXNzIHRocm91Z2ggZXZlbiB3b3Jrcwo+PiA+PiBhbmQgYSB0dW5lciBjYXJkIGhhcyBwcm9i
bGVtcyBkdWUgdG8gdGhlIGludHJvZHVjZWQgbGF0ZW5jaWVzIGluIHRoZQo+PiA+PiBJUlFzLgo+
PiA+Cj4+ID4gVGhlIGxhdGVuY3kgaXMgdmVyeSB2ZXJ5IG1pbmlzY3VsZS4gT25lIGNvdWxkIGFj
dHVhbGx5IHZlcmlmeSB0aGF0IHRoaXMKPj4gPiBpcyBhIHByb2JsZW0gYnkgaW5zZXJ0aW5nIHNh
aWQgbGF0ZW5jeSBpbiB0aGUgZHJpdmVyIHNvIHRoYXQgdW5kZXIKPj4gPiBiYXJlbWV0YWwgdGhl
IGxhdGVuY3kgd291bGQgc2hvdyB1cC4KPj4gPgo+PiA+IEJ1dCB0aGUgb3RoZXIgaXNzdWUgaXMg
dGhhdCBpZiB0aGUgZGF0YSBpcyBiZWluZyBsb3N0IHlvdSB3b3VsZCBhdCBsZWFzdAo+PiA+IGdl
dCBzb21lLiBTbyB0aGUgYnVmZmVycyBvdWdodCB0byBoYXZlICJzb21ldGhpbmciIGluIHRoZW0/
IE1heWJlIHRoYXQKPj4gPiBkZXBlbmRzIG9uIHdoYXQgY29tcHJlc3Npb24geW91IHVzZSBvbiB0
aGUgY29kZXI/IElmIHlvdSBqdXMgZG8gWVVWNDIwCj4+ID4gb3IgdGhlIFJHQiB2YXJpYW50cyBh
bmQganVzdCBkbyBhIHNpbXBsZSAnY2F0IC9kZXYvdmlkZTAgPiAvdG1wL2ZpbGUnCj4+ID4gZG9l
cyB0aGUgb3V0cHV0IGNvbnRhaW4gYW55dGhpbmc/IE9yIGlzIGp1c3QgYSBibG9iIG9mIGVtcHR5
IGRhdGE/Cj4+Cj4+IFRoZSBvdXRwdXQgY29udGFpbnMgZGF0YSwgcGFydCBvZiB0aGUgbXBlZyBz
dHJlYW0gd2l0aG91dCBhbnkgY29udGludWl0eS4KPj4KPiBJIHNlZS4KPj4gPj4gRG8geW91IGhh
dmUgYW55IG1vcmUgaW5mbyBhYm91dCB0aGlzPwo+PiA+Cj4+ID4gVGhlIG90aGVyIGlzc3VlIGNv
dWxkIGJlIHJlbGF0ZWQgdG8gdGhlIHZtYWxsb2NfMzIgYmVpbmcgaW4gdXNhZ2UKPj4gPiBhbmQg
bm90IHVzaW5nIHRoZSBETUEgQVBJLgo+PiA+Cj4+ID4gSSByZWNhbGwgcG9zdGluZyBhIHBhdGNo
IGZvciB0aGlzIC4uIEFoOgo+PiA+IGh0dHA6Ly9saXN0cy54ZW4ub3JnL2FyY2hpdmVzL2h0bWwv
eGVuLWRldmVsLzIwMTItMDEvbXNnMDE5MjcuaHRtbAo+PiA+Cj4+ID4gUGVyaGFwcyB0aGlzIGlz
IHRoZSBpc3N1ZT8KPj4KPj4gQmluZ28gS29ucmFkISBUaGF0IHdhcyBpdCA6KSBBdCBsZWFzdCBJ
IGhhdmUganVzdCBhcHBsaWVkIHRoZSBwYXRjaCwKPj4gcmVib290ZWQgdW5kZXIgWGVuIGFuZCB0
aGlzIHRpbWUgSSBnb3QgYSBnb29kIGR1bXAuCj4KPiBXb29ob28hCgo6KQoKPj4gUmlnaHQgbm93
IEkgaGF2ZSBteSB1c3VhbCBzeXN0ZW0gcnVubmluZyBmbGF3bGVzc2x5IHVuZGVyIFhlbi4gVGlt
ZSB0bwo+PiB0YWtlIGEgbG9vayBhZ2FpbiBhdCB0aGUgc3VzcGVuZC9yZXN1bWUgaXNzdWUgd2hp
Y2ggSSBuZWFybHkgaGFkCj4+IHdvcmtpbmcgYSBmZXcgZGF5cyBhZ28uCj4KPiBLZWVwIGluIG1p
bmQgdGhhdCBmb3IgdGhlIHN1c3BlbmQvcmVzdW1lIHlvdSBuZWVkIG91dCBvZiBtYWlubGluZQo+
IHBhdGNoZXMgZm9yIHJpZ2h0IG5vdy4gSSBoYWRuJ3QgeWV0IHVwc3RyZWFtZWQgYWxsIHRoZSBw
YXJ0cy4gVGhleSBhcmUKPiBpbiAgZ2l0Oi8vZ2l0Lmtlcm5lbC5vcmcvcHViL3NjbS9saW51eC9r
ZXJuZWwvZ2l0L2tvbnJhZC94ZW4uZ2l0Cj4gZGV2ZWwvYWNwaS1zMy52WFggKEkgYmVsaWV2ZSAx
MSB3b3VsZCBhcHBseSBjbGVhbmx5IHRvIHlvdXIgdHJlZT8pCj4KPiBLZWVwIGluIG1pbmQgdGhh
dCB0aGVyZSB3ZXJlIHNvbWUgYnVncyBpbiBYZW4gNC4yIGluIHJlZ2FyZHMgdG8gcmVzdW1lLgo+
IExvb2sgb24geGVuLWRldmVsIGZvciBlbWFpbHMgYmV0d2VlbiBKYW4gYW5kIEJlbiBHdXRocm8u
CgpJIGhhdmUgdGhlIG5lZWRlZCBwYXRjaGVzIGluIHBsYWNlIGFuZCBJIGhhdmUgZm9sbG93ZWQg
dGhhdCB0aHJlYWQsIGF0CmxlYXN0IHVudGlsIGEgZmV3IGRheXMgYWdvLiBJIGhhdmUgb3BlbmVk
IGEgbmV3IG9uZSBhYm91dCB0aGUgb25seQpwcm9ibGVtIEkgc3RpbGwgaGF2ZSB3aXRoIFMzOiBo
dHRwOi8vZ29vLmdsL3ZZSzQyCgo+PiBUaGFua3MgYSBsb3QgZm9yIGFsbCB5b3VyIGhlbHAgOikK
Pj4KPj4gUC5TLiBJJ20gZ29pbmcgdG8gcG9zdCB0aGlzIGluZm8gb24gdGhlIGxpbnV4IG1lZGlh
IG1haWxpbmcgbGlzdC4KPgo+IElmIHlvdSBjb3VsZCBDQyBtZSBvbiBpdCBJIGNhbiBwcm92aWRl
IHRoZSB0ZWNobmljYWwgZXhwbGFuYXRpb24KPiBmb3IgdGhlICdETUEtQVBJLWluZyB0aGUgdm1h
bGxvY18zMicgY2FsbC4KCkkgaGF2ZSBDQ2VkIHlvdSBpbiBteSBsYXN0IHJlcGx5IHRvIHRoZSB0
aHJlYWQuIEknbSBwcmV0dHkgY2VydGFpbgpEZXZpbiB1bmRlcnN0b29kIHdlbGwgdGhlIHByb2Js
ZW0gYW5kIHdoYXQgdGhlIHNvbHV0aW9uIHlvdXIgcGF0Y2gKZ2l2ZXMuCgoKLS0gCkphdmllciBN
YXJjZXQgPGptYXJjZXRAZ21haWwuY29tPgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMu
eGVuLm9yZwpodHRwOi8vbGlzdHMueGVuLm9yZy94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xen.org Tue Sep 18 20:54:16 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Sep 2012 20: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 1TE4nl-0002WJ-On; Tue, 18 Sep 2012 20:53:49 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1TE4nk-0002WE-DY
	for xen-devel@lists.xensource.com; Tue, 18 Sep 2012 20:53:48 +0000
Received: from [85.158.139.83:6733] by server-9.bemta-5.messagelabs.com id
	AF/00-20529-B5FD8505; Tue, 18 Sep 2012 20:53:47 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1348001626!30937051!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDk5MjE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17826 invoked from network); 18 Sep 2012 20:53:47 -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 Sep 2012 20:53:47 -0000
X-IronPort-AV: E=Sophos;i="4.80,445,1344211200"; d="scan'208";a="14615869"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Sep 2012 20:53: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.279.1; Tue, 18 Sep 2012 21:53: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 1TE4ni-00029f-9e;
	Tue, 18 Sep 2012 20:53:46 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1TE4nh-0000ko-RG;
	Tue, 18 Sep 2012 21:53:46 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-13807-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Tue, 18 Sep 2012 21:53:45 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [qemu-upstream-4.2-testing test] 13807: 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 13807 qemu-upstream-4.2-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13807/

Failures :-/ but no regressions.

Tests which did not succeed,
including tests which could not be run:
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  9 guest-localmigrate fail never pass
 test-amd64-i386-xl-qemuu-win-vcpus1  9 guest-localmigrate      fail never pass
 test-amd64-amd64-qemuu-win   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64  9 guest-localmigrate      fail never pass
 test-i386-i386-qemuu-win     16 leak-check/check             fail   never pass
 test-i386-i386-xl-qemuu-win   9 guest-localmigrate           fail   never pass
 test-amd64-i386-qemuu-win-vcpus1 16 leak-check/check           fail never pass
 test-amd64-i386-xend-qemuu-winxpsp3 16 leak-check/check        fail never pass
 test-amd64-amd64-xl-qemuu-win  9 guest-localmigrate           fail  never pass
 test-amd64-i386-qemuu-win    16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail never pass
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass


jobs:
 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                           pass    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-win-vcpus1                             fail    
 test-amd64-i386-xl-qemuu-win-vcpus1                          fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-amd64-qemuu-win                                   fail    
 test-amd64-i386-qemuu-win                                    fail    
 test-i386-i386-qemuu-win                                     fail    
 test-amd64-amd64-xl-qemuu-win                                fail    
 test-i386-i386-xl-qemuu-win                                  fail    
 test-amd64-i386-xend-qemuu-winxpsp3                          fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 18 20:54:16 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Sep 2012 20: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 1TE4nl-0002WJ-On; Tue, 18 Sep 2012 20:53:49 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1TE4nk-0002WE-DY
	for xen-devel@lists.xensource.com; Tue, 18 Sep 2012 20:53:48 +0000
Received: from [85.158.139.83:6733] by server-9.bemta-5.messagelabs.com id
	AF/00-20529-B5FD8505; Tue, 18 Sep 2012 20:53:47 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1348001626!30937051!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMDk5MjE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17826 invoked from network); 18 Sep 2012 20:53:47 -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 Sep 2012 20:53:47 -0000
X-IronPort-AV: E=Sophos;i="4.80,445,1344211200"; d="scan'208";a="14615869"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Sep 2012 20:53: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.279.1; Tue, 18 Sep 2012 21:53: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 1TE4ni-00029f-9e;
	Tue, 18 Sep 2012 20:53:46 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1TE4nh-0000ko-RG;
	Tue, 18 Sep 2012 21:53:46 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-13807-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Tue, 18 Sep 2012 21:53:45 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [qemu-upstream-4.2-testing test] 13807: 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 13807 qemu-upstream-4.2-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13807/

Failures :-/ but no regressions.

Tests which did not succeed,
including tests which could not be run:
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  9 guest-localmigrate fail never pass
 test-amd64-i386-xl-qemuu-win-vcpus1  9 guest-localmigrate      fail never pass
 test-amd64-amd64-qemuu-win   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64  9 guest-localmigrate      fail never pass
 test-i386-i386-qemuu-win     16 leak-check/check             fail   never pass
 test-i386-i386-xl-qemuu-win   9 guest-localmigrate           fail   never pass
 test-amd64-i386-qemuu-win-vcpus1 16 leak-check/check           fail never pass
 test-amd64-i386-xend-qemuu-winxpsp3 16 leak-check/check        fail never pass
 test-amd64-amd64-xl-qemuu-win  9 guest-localmigrate           fail  never pass
 test-amd64-i386-qemuu-win    16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail never pass
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass


jobs:
 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                           pass    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-win-vcpus1                             fail    
 test-amd64-i386-xl-qemuu-win-vcpus1                          fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-amd64-qemuu-win                                   fail    
 test-amd64-i386-qemuu-win                                    fail    
 test-i386-i386-qemuu-win                                     fail    
 test-amd64-amd64-xl-qemuu-win                                fail    
 test-i386-i386-xl-qemuu-win                                  fail    
 test-amd64-i386-xend-qemuu-winxpsp3                          fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 18 21:56:38 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Sep 2012 21: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 1TE5m6-0002rc-Kr; Tue, 18 Sep 2012 21:56:10 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1TE5m5-0002rX-1V
	for xen-devel@lists.xen.org; Tue, 18 Sep 2012 21:56:09 +0000
Received: from [85.158.138.51:40690] by server-6.bemta-3.messagelabs.com id
	15/50-29694-8FDE8505; Tue, 18 Sep 2012 21:56:08 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-14.tower-174.messagelabs.com!1348005367!24747154!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiA0MTY2ODc=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiA0MTY2ODc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 975 invoked from network); 18 Sep 2012 21:56:07 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-14.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 18 Sep 2012 21:56:07 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFGhi0PEj9t
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-088-110.pools.arcor-ip.net [88.65.88.110])
	by smtp.strato.de (jorabe mo40) (RZmta 30.15 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id L0099eo8ILN0fI ;
	Tue, 18 Sep 2012 23:56:06 +0200 (CEST)
Received: by probook.site (Postfix, from userid 1000)
	id CC1001863E; Tue, 18 Sep 2012 23:56:05 +0200 (CEST)
Date: Tue, 18 Sep 2012 23:56:05 +0200
From: Olaf Hering <olaf@aepfle.de>
To: M A Young <m.a.young@durham.ac.uk>
Message-ID: <20120918215605.GA9974@aepfle.de>
References: <5058850F.6000800@crc.id.au> <20120918143516.GA7170@aepfle.de>
	<alpine.DEB.2.00.1209181938500.21507@procyon.dur.ac.uk>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <alpine.DEB.2.00.1209181938500.21507@procyon.dur.ac.uk>
User-Agent: Mutt/1.5.21.rev5555 (2012-07-20)
Cc: Steven Haigh <netwiz@crc.id.au>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Problems building qemu-xen-dir tools
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Sep 18, M A Young wrote:

> On Tue, 18 Sep 2012, Olaf Hering wrote:
> 
> >On Wed, Sep 19, Steven Haigh wrote:
> >
> >>Without this, the build fails due to incompatible CFLAGS.
> >
> >CFLAGS must not be in environment, otherwise make will append its own
> >CFLAGS to that environment variable and pass it on to qemu. qemu itself
> >is not ready for things like -std=gnu99.
> 
> The problem is that packaging guidelines often want you to set CFLAGS to
> supply distribution standard compile options. On the other hand with
> something like qemu it means that someone has probably already solved the
> problem. The attached patch worked for me in testing, which I derived by
> comparing Fedora's qemu with xen's.

qemu does not build with rPM_OPT_FLAGS, at least in SuSE.
For Xen, see changeset:   25464:75a2bb5db228
user:        Olaf Hering <olaf@aepfle.de>
date:        Thu Jun 07 18:51:42 2012 +0100
files:       tools/Makefile tools/Rules.mk tools/firmware/Rules.mk
description:
tools: pass EXTRA_CFLAGS via environment


Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 18 21:56:38 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Sep 2012 21: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 1TE5m6-0002rc-Kr; Tue, 18 Sep 2012 21:56:10 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1TE5m5-0002rX-1V
	for xen-devel@lists.xen.org; Tue, 18 Sep 2012 21:56:09 +0000
Received: from [85.158.138.51:40690] by server-6.bemta-3.messagelabs.com id
	15/50-29694-8FDE8505; Tue, 18 Sep 2012 21:56:08 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-14.tower-174.messagelabs.com!1348005367!24747154!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiA0MTY2ODc=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiA0MTY2ODc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 975 invoked from network); 18 Sep 2012 21:56:07 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-14.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 18 Sep 2012 21:56:07 -0000
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFGhi0PEj9t
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-088-110.pools.arcor-ip.net [88.65.88.110])
	by smtp.strato.de (jorabe mo40) (RZmta 30.15 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id L0099eo8ILN0fI ;
	Tue, 18 Sep 2012 23:56:06 +0200 (CEST)
Received: by probook.site (Postfix, from userid 1000)
	id CC1001863E; Tue, 18 Sep 2012 23:56:05 +0200 (CEST)
Date: Tue, 18 Sep 2012 23:56:05 +0200
From: Olaf Hering <olaf@aepfle.de>
To: M A Young <m.a.young@durham.ac.uk>
Message-ID: <20120918215605.GA9974@aepfle.de>
References: <5058850F.6000800@crc.id.au> <20120918143516.GA7170@aepfle.de>
	<alpine.DEB.2.00.1209181938500.21507@procyon.dur.ac.uk>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <alpine.DEB.2.00.1209181938500.21507@procyon.dur.ac.uk>
User-Agent: Mutt/1.5.21.rev5555 (2012-07-20)
Cc: Steven Haigh <netwiz@crc.id.au>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Problems building qemu-xen-dir tools
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Sep 18, M A Young wrote:

> On Tue, 18 Sep 2012, Olaf Hering wrote:
> 
> >On Wed, Sep 19, Steven Haigh wrote:
> >
> >>Without this, the build fails due to incompatible CFLAGS.
> >
> >CFLAGS must not be in environment, otherwise make will append its own
> >CFLAGS to that environment variable and pass it on to qemu. qemu itself
> >is not ready for things like -std=gnu99.
> 
> The problem is that packaging guidelines often want you to set CFLAGS to
> supply distribution standard compile options. On the other hand with
> something like qemu it means that someone has probably already solved the
> problem. The attached patch worked for me in testing, which I derived by
> comparing Fedora's qemu with xen's.

qemu does not build with rPM_OPT_FLAGS, at least in SuSE.
For Xen, see changeset:   25464:75a2bb5db228
user:        Olaf Hering <olaf@aepfle.de>
date:        Thu Jun 07 18:51:42 2012 +0100
files:       tools/Makefile tools/Rules.mk tools/firmware/Rules.mk
description:
tools: pass EXTRA_CFLAGS via environment


Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 18 23:36:06 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Sep 2012 23:36:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TE7KJ-0003MX-C4; Tue, 18 Sep 2012 23:35:35 +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 1TE7KH-0003MS-IT
	for xen-devel@lists.xen.org; Tue, 18 Sep 2012 23:35:33 +0000
Received: from [85.158.137.99:39042] by server-2.bemta-3.messagelabs.com id
	5A/E2-04862-44509505; Tue, 18 Sep 2012 23:35:32 +0000
X-Env-Sender: m.a.young@durham.ac.uk
X-Msg-Ref: server-15.tower-217.messagelabs.com!1348011331!15856741!1
X-Originating-IP: [129.234.248.2]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTI5LjIzNC4yNDguMiA9PiA4NjE4MA==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32744 invoked from network); 18 Sep 2012 23:35:32 -0000
Received: from hermes2.dur.ac.uk (HELO hermes2.dur.ac.uk) (129.234.248.2)
	by server-15.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 18 Sep 2012 23:35:32 -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 q8INYvN3015200;
	Wed, 19 Sep 2012 00:35:01 +0100
Received: from procyon.dur.ac.uk (procyon.dur.ac.uk [129.234.250.129])
	by smtphost3.dur.ac.uk (8.14.4/8.14.4) with ESMTP id q8INYrdF028878
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 19 Sep 2012 00:34:53 +0100
Received: from procyon.dur.ac.uk (localhost [127.0.0.1])
	by procyon.dur.ac.uk (8.14.3/8.11.1) with ESMTP id q8INYrJD028142;
	Wed, 19 Sep 2012 00:34:53 +0100
Received: from localhost (dcl0may@localhost)
	by procyon.dur.ac.uk (8.14.3/8.14.3/Submit) with ESMTP id
	q8INYqxM028134; Wed, 19 Sep 2012 00:34:52 +0100
Date: Wed, 19 Sep 2012 00:34:52 +0100 (BST)
From: M A Young <m.a.young@durham.ac.uk>
To: Olaf Hering <olaf@aepfle.de>
In-Reply-To: <20120918215605.GA9974@aepfle.de>
Message-ID: <alpine.DEB.2.00.1209190031370.3854@procyon.dur.ac.uk>
References: <5058850F.6000800@crc.id.au> <20120918143516.GA7170@aepfle.de>
	<alpine.DEB.2.00.1209181938500.21507@procyon.dur.ac.uk>
	<20120918215605.GA9974@aepfle.de>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
X-DurhamAcUk-MailScanner: Found to be clean, Found to be clean
X-DurhamAcUk-MailScanner-ID: q8INYvN3015200
Cc: Steven Haigh <netwiz@crc.id.au>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Problems building qemu-xen-dir tools
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-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, 18 Sep 2012, Olaf Hering wrote:

> qemu does not build with rPM_OPT_FLAGS, at least in SuSE.
> For Xen, see changeset:   25464:75a2bb5db228
> user:        Olaf Hering <olaf@aepfle.de>
> date:        Thu Jun 07 18:51:42 2012 +0100
> files:       tools/Makefile tools/Rules.mk tools/firmware/Rules.mk
> description:
> tools: pass EXTRA_CFLAGS via environment

Fedora 17 seems happy to build the xen qemu with that patch and the 
RPM_OPT_FLAGS, though I haven't tried it on the full build system.

 	Michael Young

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 18 23:36:06 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 18 Sep 2012 23:36:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TE7KJ-0003MX-C4; Tue, 18 Sep 2012 23:35:35 +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 1TE7KH-0003MS-IT
	for xen-devel@lists.xen.org; Tue, 18 Sep 2012 23:35:33 +0000
Received: from [85.158.137.99:39042] by server-2.bemta-3.messagelabs.com id
	5A/E2-04862-44509505; Tue, 18 Sep 2012 23:35:32 +0000
X-Env-Sender: m.a.young@durham.ac.uk
X-Msg-Ref: server-15.tower-217.messagelabs.com!1348011331!15856741!1
X-Originating-IP: [129.234.248.2]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTI5LjIzNC4yNDguMiA9PiA4NjE4MA==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32744 invoked from network); 18 Sep 2012 23:35:32 -0000
Received: from hermes2.dur.ac.uk (HELO hermes2.dur.ac.uk) (129.234.248.2)
	by server-15.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 18 Sep 2012 23:35:32 -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 q8INYvN3015200;
	Wed, 19 Sep 2012 00:35:01 +0100
Received: from procyon.dur.ac.uk (procyon.dur.ac.uk [129.234.250.129])
	by smtphost3.dur.ac.uk (8.14.4/8.14.4) with ESMTP id q8INYrdF028878
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 19 Sep 2012 00:34:53 +0100
Received: from procyon.dur.ac.uk (localhost [127.0.0.1])
	by procyon.dur.ac.uk (8.14.3/8.11.1) with ESMTP id q8INYrJD028142;
	Wed, 19 Sep 2012 00:34:53 +0100
Received: from localhost (dcl0may@localhost)
	by procyon.dur.ac.uk (8.14.3/8.14.3/Submit) with ESMTP id
	q8INYqxM028134; Wed, 19 Sep 2012 00:34:52 +0100
Date: Wed, 19 Sep 2012 00:34:52 +0100 (BST)
From: M A Young <m.a.young@durham.ac.uk>
To: Olaf Hering <olaf@aepfle.de>
In-Reply-To: <20120918215605.GA9974@aepfle.de>
Message-ID: <alpine.DEB.2.00.1209190031370.3854@procyon.dur.ac.uk>
References: <5058850F.6000800@crc.id.au> <20120918143516.GA7170@aepfle.de>
	<alpine.DEB.2.00.1209181938500.21507@procyon.dur.ac.uk>
	<20120918215605.GA9974@aepfle.de>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
X-DurhamAcUk-MailScanner: Found to be clean, Found to be clean
X-DurhamAcUk-MailScanner-ID: q8INYvN3015200
Cc: Steven Haigh <netwiz@crc.id.au>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Problems building qemu-xen-dir tools
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-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, 18 Sep 2012, Olaf Hering wrote:

> qemu does not build with rPM_OPT_FLAGS, at least in SuSE.
> For Xen, see changeset:   25464:75a2bb5db228
> user:        Olaf Hering <olaf@aepfle.de>
> date:        Thu Jun 07 18:51:42 2012 +0100
> files:       tools/Makefile tools/Rules.mk tools/firmware/Rules.mk
> description:
> tools: pass EXTRA_CFLAGS via environment

Fedora 17 seems happy to build the xen qemu with that patch and the 
RPM_OPT_FLAGS, though I haven't tried it on the full build system.

 	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 Sep 19 00:07:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Sep 2012 00:07: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 1TE7oU-00042l-0P; Wed, 19 Sep 2012 00:06:46 +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 1TE7oS-00042g-OV
	for xen-devel@lists.xen.org; Wed, 19 Sep 2012 00:06:44 +0000
Received: from [85.158.139.211:62474] by server-5.bemta-5.messagelabs.com id
	0B/0F-30514-49C09505; Wed, 19 Sep 2012 00:06:44 +0000
X-Env-Sender: yang.z.zhang@intel.com
X-Msg-Ref: server-8.tower-206.messagelabs.com!1348013202!19066257!1
X-Originating-IP: [134.134.136.24]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjQgPT4gMzQ0MTQ0\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30225 invoked from network); 19 Sep 2012 00:06:43 -0000
Received: from mga09.intel.com (HELO mga09.intel.com) (134.134.136.24)
	by server-8.tower-206.messagelabs.com with SMTP;
	19 Sep 2012 00:06:43 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga102.jf.intel.com with ESMTP; 18 Sep 2012 17:06:30 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.80,446,1344236400"; d="scan'208";a="207438577"
Received: from fmsmsx106.amr.corp.intel.com ([10.19.9.37])
	by orsmga002.jf.intel.com with ESMTP; 18 Sep 2012 17:06:41 -0700
Received: from fmsmsx151.amr.corp.intel.com (10.19.17.220) by
	FMSMSX106.amr.corp.intel.com (10.19.9.37) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Tue, 18 Sep 2012 17:06:41 -0700
Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by
	FMSMSX151.amr.corp.intel.com (10.19.17.220) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Tue, 18 Sep 2012 17:06:41 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.239]) by
	SHSMSX102.ccr.corp.intel.com ([169.254.2.92]) with mapi id
	14.01.0355.002; Wed, 19 Sep 2012 08:06:39 +0800
From: "Zhang, Yang Z" <yang.z.zhang@intel.com>
To: Anthony PERARD <anthony.perard@citrix.com>
Thread-Topic: [Xen-devel] error when pass through device to	guest	with
	qemu-xen-dir-remote
Thread-Index: AQHNlfqjZWfhNnwhh0GdrStYe49w1g==
Date: Wed, 19 Sep 2012 00:06:38 +0000
Message-ID: <A9667DDFB95DB7438FA9D7D576C3D87E25BB14@SHSMSX101.ccr.corp.intel.com>
References: <A9667DDFB95DB7438FA9D7D576C3D87E203D54@SHSMSX101.ccr.corp.intel.com>
	<alpine.DEB.2.02.1208031122170.4645@kaball.uk.xensource.com>
	<1343990187.21372.48.camel@zakaz.uk.xensource.com>
	<40352EBA8B4DF841A9907B883F22B59B0FDBCE1E@SHSMSX102.ccr.corp.intel.com>
	<40352EBA8B4DF841A9907B883F22B59B0FDD25C7@SHSMSX102.ccr.corp.intel.com>
	<A9667DDFB95DB7438FA9D7D576C3D87E258EF6@SHSMSX101.ccr.corp.intel.com>
	<505851CF.2090000@citrix.com>
In-Reply-To: <505851CF.2090000@citrix.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 <xen-devel@lists.xen.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>, "Shan,
	Haitao" <haitao.shan@intel.com>, "Zhou, Chao" <chao.zhou@intel.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] error when pass through device to	guest	with
 qemu-xen-dir-remote
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 wrote on 2012-09-18:
> 
> Hi,
> 
> So, we'll have to add a check in the unplug code of qemu to ignore
> passthrough devices.
> 
> Here is a patches, I did not test it.
> 
> diff --git a/hw/xen_platform.c b/hw/xen_platform.c
> index 0d6c2ff..2d3978e 100644
> --- a/hw/xen_platform.c
> +++ b/hw/xen_platform.c
> @@ -85,8 +85,10 @@ static void log_writeb ...
> 
>   static void unplug_nic(PCIBus *b, PCIDevice *d, void *o)
>   {
> +    /* We have to ignore passthrough devices */
>       if (pci_get_word(d->config + PCI_CLASS_DEVICE) ==
> -            PCI_CLASS_NETWORK_ETHERNET) {
> +            PCI_CLASS_NETWORK_ETHERNET
> +        && strcmp(d->name, "xen-pci-passthrough") != 0) {
>           qdev_free(&d->qdev);
>       }
>   }
In old qemu, we will free the invalid NIC through this function. And it will fail w/ your change. Shouldn't we follow the old logic?

Best regards,
Yang

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 19 00:07:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Sep 2012 00:07: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 1TE7oU-00042l-0P; Wed, 19 Sep 2012 00:06:46 +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 1TE7oS-00042g-OV
	for xen-devel@lists.xen.org; Wed, 19 Sep 2012 00:06:44 +0000
Received: from [85.158.139.211:62474] by server-5.bemta-5.messagelabs.com id
	0B/0F-30514-49C09505; Wed, 19 Sep 2012 00:06:44 +0000
X-Env-Sender: yang.z.zhang@intel.com
X-Msg-Ref: server-8.tower-206.messagelabs.com!1348013202!19066257!1
X-Originating-IP: [134.134.136.24]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjQgPT4gMzQ0MTQ0\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30225 invoked from network); 19 Sep 2012 00:06:43 -0000
Received: from mga09.intel.com (HELO mga09.intel.com) (134.134.136.24)
	by server-8.tower-206.messagelabs.com with SMTP;
	19 Sep 2012 00:06:43 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga102.jf.intel.com with ESMTP; 18 Sep 2012 17:06:30 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.80,446,1344236400"; d="scan'208";a="207438577"
Received: from fmsmsx106.amr.corp.intel.com ([10.19.9.37])
	by orsmga002.jf.intel.com with ESMTP; 18 Sep 2012 17:06:41 -0700
Received: from fmsmsx151.amr.corp.intel.com (10.19.17.220) by
	FMSMSX106.amr.corp.intel.com (10.19.9.37) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Tue, 18 Sep 2012 17:06:41 -0700
Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by
	FMSMSX151.amr.corp.intel.com (10.19.17.220) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Tue, 18 Sep 2012 17:06:41 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.239]) by
	SHSMSX102.ccr.corp.intel.com ([169.254.2.92]) with mapi id
	14.01.0355.002; Wed, 19 Sep 2012 08:06:39 +0800
From: "Zhang, Yang Z" <yang.z.zhang@intel.com>
To: Anthony PERARD <anthony.perard@citrix.com>
Thread-Topic: [Xen-devel] error when pass through device to	guest	with
	qemu-xen-dir-remote
Thread-Index: AQHNlfqjZWfhNnwhh0GdrStYe49w1g==
Date: Wed, 19 Sep 2012 00:06:38 +0000
Message-ID: <A9667DDFB95DB7438FA9D7D576C3D87E25BB14@SHSMSX101.ccr.corp.intel.com>
References: <A9667DDFB95DB7438FA9D7D576C3D87E203D54@SHSMSX101.ccr.corp.intel.com>
	<alpine.DEB.2.02.1208031122170.4645@kaball.uk.xensource.com>
	<1343990187.21372.48.camel@zakaz.uk.xensource.com>
	<40352EBA8B4DF841A9907B883F22B59B0FDBCE1E@SHSMSX102.ccr.corp.intel.com>
	<40352EBA8B4DF841A9907B883F22B59B0FDD25C7@SHSMSX102.ccr.corp.intel.com>
	<A9667DDFB95DB7438FA9D7D576C3D87E258EF6@SHSMSX101.ccr.corp.intel.com>
	<505851CF.2090000@citrix.com>
In-Reply-To: <505851CF.2090000@citrix.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 <xen-devel@lists.xen.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>, "Shan,
	Haitao" <haitao.shan@intel.com>, "Zhou, Chao" <chao.zhou@intel.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] error when pass through device to	guest	with
 qemu-xen-dir-remote
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 wrote on 2012-09-18:
> 
> Hi,
> 
> So, we'll have to add a check in the unplug code of qemu to ignore
> passthrough devices.
> 
> Here is a patches, I did not test it.
> 
> diff --git a/hw/xen_platform.c b/hw/xen_platform.c
> index 0d6c2ff..2d3978e 100644
> --- a/hw/xen_platform.c
> +++ b/hw/xen_platform.c
> @@ -85,8 +85,10 @@ static void log_writeb ...
> 
>   static void unplug_nic(PCIBus *b, PCIDevice *d, void *o)
>   {
> +    /* We have to ignore passthrough devices */
>       if (pci_get_word(d->config + PCI_CLASS_DEVICE) ==
> -            PCI_CLASS_NETWORK_ETHERNET) {
> +            PCI_CLASS_NETWORK_ETHERNET
> +        && strcmp(d->name, "xen-pci-passthrough") != 0) {
>           qdev_free(&d->qdev);
>       }
>   }
In old qemu, we will free the invalid NIC through this function. And it will fail w/ your change. Shouldn't we follow the old logic?

Best regards,
Yang

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 19 01:20:23 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Sep 2012 01:20:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TE8xF-0008ED-14; Wed, 19 Sep 2012 01:19: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 1TE8xD-0008E8-Dg
	for xen-devel@lists.xensource.com; Wed, 19 Sep 2012 01:19:51 +0000
Received: from [85.158.143.35:37684] by server-2.bemta-4.messagelabs.com id
	02/05-06610-6BD19505; Wed, 19 Sep 2012 01:19:50 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1348017590!10766293!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTAwNzc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20968 invoked from network); 19 Sep 2012 01:19:50 -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;
	19 Sep 2012 01:19:50 -0000
X-IronPort-AV: E=Sophos;i="4.80,446,1344211200"; d="scan'208";a="14618175"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Sep 2012 01:19: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.279.1; Wed, 19 Sep 2012 02:19:49 +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 1TE8xB-0003dV-5h;
	Wed, 19 Sep 2012 01:19:49 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1TE8xA-0002fy-Ty;
	Wed, 19 Sep 2012 02:19:49 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-13808-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 19 Sep 2012 02:19:48 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [qemu-upstream-4.2-testing test] 13808: 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 13808 qemu-upstream-4.2-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13808/

Failures :-/ but no regressions.

Tests which did not succeed,
including tests which could not be run:
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  9 guest-localmigrate fail never pass
 test-amd64-i386-xl-qemuu-win-vcpus1  9 guest-localmigrate      fail never pass
 test-amd64-amd64-qemuu-win   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64  9 guest-localmigrate      fail never pass
 test-i386-i386-qemuu-win     16 leak-check/check             fail   never pass
 test-i386-i386-xl-qemuu-win   9 guest-localmigrate           fail   never pass
 test-amd64-i386-qemuu-win-vcpus1 16 leak-check/check           fail never pass
 test-amd64-i386-xend-qemuu-winxpsp3 16 leak-check/check        fail never pass
 test-amd64-amd64-xl-qemuu-win  9 guest-localmigrate           fail  never pass
 test-amd64-i386-qemuu-win    16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail never pass
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass


jobs:
 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                           pass    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-win-vcpus1                             fail    
 test-amd64-i386-xl-qemuu-win-vcpus1                          fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-amd64-qemuu-win                                   fail    
 test-amd64-i386-qemuu-win                                    fail    
 test-i386-i386-qemuu-win                                     fail    
 test-amd64-amd64-xl-qemuu-win                                fail    
 test-i386-i386-xl-qemuu-win                                  fail    
 test-amd64-i386-xend-qemuu-winxpsp3                          fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 19 01:20:23 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Sep 2012 01:20:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TE8xF-0008ED-14; Wed, 19 Sep 2012 01:19: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 1TE8xD-0008E8-Dg
	for xen-devel@lists.xensource.com; Wed, 19 Sep 2012 01:19:51 +0000
Received: from [85.158.143.35:37684] by server-2.bemta-4.messagelabs.com id
	02/05-06610-6BD19505; Wed, 19 Sep 2012 01:19:50 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1348017590!10766293!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTAwNzc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20968 invoked from network); 19 Sep 2012 01:19:50 -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;
	19 Sep 2012 01:19:50 -0000
X-IronPort-AV: E=Sophos;i="4.80,446,1344211200"; d="scan'208";a="14618175"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Sep 2012 01:19: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.279.1; Wed, 19 Sep 2012 02:19:49 +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 1TE8xB-0003dV-5h;
	Wed, 19 Sep 2012 01:19:49 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1TE8xA-0002fy-Ty;
	Wed, 19 Sep 2012 02:19:49 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-13808-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 19 Sep 2012 02:19:48 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [qemu-upstream-4.2-testing test] 13808: 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 13808 qemu-upstream-4.2-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13808/

Failures :-/ but no regressions.

Tests which did not succeed,
including tests which could not be run:
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  9 guest-localmigrate fail never pass
 test-amd64-i386-xl-qemuu-win-vcpus1  9 guest-localmigrate      fail never pass
 test-amd64-amd64-qemuu-win   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64  9 guest-localmigrate      fail never pass
 test-i386-i386-qemuu-win     16 leak-check/check             fail   never pass
 test-i386-i386-xl-qemuu-win   9 guest-localmigrate           fail   never pass
 test-amd64-i386-qemuu-win-vcpus1 16 leak-check/check           fail never pass
 test-amd64-i386-xend-qemuu-winxpsp3 16 leak-check/check        fail never pass
 test-amd64-amd64-xl-qemuu-win  9 guest-localmigrate           fail  never pass
 test-amd64-i386-qemuu-win    16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail never pass
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass


jobs:
 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                           pass    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-win-vcpus1                             fail    
 test-amd64-i386-xl-qemuu-win-vcpus1                          fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-amd64-qemuu-win                                   fail    
 test-amd64-i386-qemuu-win                                    fail    
 test-i386-i386-qemuu-win                                     fail    
 test-amd64-amd64-xl-qemuu-win                                fail    
 test-i386-i386-xl-qemuu-win                                  fail    
 test-amd64-i386-xend-qemuu-winxpsp3                          fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 19 02:39:21 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Sep 2012 02:39:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TEABh-0000Tt-8C; Wed, 19 Sep 2012 02:38:53 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <zhenzhong.duan@oracle.com>) id 1TEABf-0000To-7h
	for xen-devel@lists.xen.org; Wed, 19 Sep 2012 02:38:51 +0000
Received: from [85.158.143.35:4597] by server-2.bemta-4.messagelabs.com id
	81/4F-06610-A3039505; Wed, 19 Sep 2012 02:38:50 +0000
X-Env-Sender: zhenzhong.duan@oracle.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1348022328!7890808!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzQ5NDEz\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18249 invoked from network); 19 Sep 2012 02:38:49 -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; 19 Sep 2012 02:38:49 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q8J2cfLq006389
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 19 Sep 2012 02:38:43 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q8J2cfrC001502
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 19 Sep 2012 02:38:41 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
	q8J2ceWP010672; Tue, 18 Sep 2012 21:38:40 -0500
Received: from [10.191.8.12] (/10.191.8.12)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 18 Sep 2012 19:38:40 -0700
Message-ID: <50593071.2050108@oracle.com>
Date: Wed, 19 Sep 2012 10:39:45 +0800
From: "zhenzhong.duan" <zhenzhong.duan@oracle.com>
Organization: oracle
User-Agent: Mozilla/5.0 (Windows NT 5.1;
	rv:12.0) Gecko/20120428 Thunderbird/12.0.1
MIME-Version: 1.0
To: Tim Deegan <tim@xen.org>
References: <5020F003020000780009322C@nat28.tlf.novell.com>
	<502235E8.9040309@oracle.com>
	<50229B840200007800093A73@nat28.tlf.novell.com>
	<5023860E.7080908@oracle.com>
	<5023AE960200007800093DE8@nat28.tlf.novell.com>
	<502490A7.7020603@oracle.com>
	<502535280200007800094322@nat28.tlf.novell.com>
	<5028B3AB.7060705@oracle.com>
	<5028E53202000078000946B1@nat28.tlf.novell.com>
	<503DAA5F.5030306@oracle.com>
	<20120830090312.GA54290@ocelot.phlegethon.org>
In-Reply-To: <20120830090312.GA54290@ocelot.phlegethon.org>
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: Satish Kantheti <satish.kantheti@oracle.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Feng Jin <joe.jin@oracle.com>, xen-devel <xen-devel@lists.xen.org>,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] kernel bootup slow issue on ovm3.1.1
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: zhenzhong.duan@oracle.com
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 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

Cgrkuo4gMjAxMi0wOC0zMCAxNzowMywgVGltIERlZWdhbiDlhpnpgZM6Cj4gQXQgMTM6MzYgKzA4
MDAgb24gMjkgQXVnICgxMzQ2MjQ3MzkxKSwgemhlbnpob25nLmR1YW4gd3JvdGU6Cj4+Cj4+ID8/
PyAyMDEyLTA4LTEzIDE3OjI5LCBKYW4gQmV1bGljaCA/Pz8/Pz86Cj4+Pj4+PiBPbiAxMy4wOC4x
MiBhdCAwOTo1OCwgInpoZW56aG9uZy5kdWFuIjx6aGVuemhvbmcuZHVhbkBvcmFjbGUuY29tPgo+
Pj4+Pj4gd3JvdGU6Cj4+Pj4gPz8/IDIwMTItMDgtMTAgMjI6MjIsIEphbiBCZXVsaWNoID8/Pz8/
PzoKPj4+Pj4gR29pbmcgYmFjayB0byB5b3VyIG9yaWdpbmFsIG1haWwsIEkgd29uZGVyIGhvd2V2
ZXIgd2h5IHRoaXMKPj4+Pj4gZ2V0cyBkb25lIGF0IGFsbC4gWW91IHNhaWQgaXQgZ290IHRoZXJl
IHZpYQo+Pj4+Pgo+Pj4+PiBtdHJyX2Fwc19pbml0KCkKPj4+Pj4gICAgXC0+ICAgIHNldF9tdHJy
KCkKPj4+Pj4gICAgICAgIFwtPiAgICBtdHJyX3dvcmtfaGFuZGxlcigpCj4+Pj4+Cj4+Pj4+IHll
dCB0aGlzIGlzbid0IGRvbmUgdW5jb25kaXRpb25hbGx5IC0gc2VlIHRoZSBjb21tZW50IGJlZm9y
ZQo+Pj4+PiBjaGVja2luZyBtdHJyX2Fwc19kZWxheWVkX2luaXQuIENhbiB5b3UgZmluZCBvdXQg
d2hlcmUgdGhlCj4+Pj4+IG9idmlvdXNseSBuZWNlc3NhcnkgY2FsbChzKSB0byBzZXRfbXRycl9h
cHNfZGVsYXllZF9pbml0KCkKPj4+Pj4gY29tZShzKSBmcm9tPwo+Pj4+IEF0IGJvb3R1cCBzdGFn
ZSwgc2V0X210cnJfYXBzX2RlbGF5ZWRfaW5pdCBpcyBjYWxsZWQgYnkKPj4+PiBuYXRpdmVfc21w
X3ByZXBhcmVfY3B1cy4KPj4+PiBtdHJyX2Fwc19kZWxheWVkX2luaXQgaXMgYWx3YXlzIHNldCB0
byB0dXJlIGZvciBpbnRlbCBwcm9jZXNzb3IgaW4KPj4+PiB1cHN0cmVhbQo+Pj4+IGNvZGUuCj4+
PiBJbmRlZWQsIGFuZCB0aGF0IChpbiBvbmUgZm9ybSBvciBhbm90aGVyKSBoYXMgYmVlbiBkb25l
Cj4+PiB2aXJ0dWFsbHkgZm9yZXZlciBpbiBMaW51eC4gSSB3b25kZXIgd2h5IHRoZSBwcm9ibGVt
IHdhc24ndAo+Pj4gbm90aWNlZCAob3IgbG9va2VkIGludG8sIGlmIGl0IHdhcyBub3RpY2VkKSBz
byBmYXIuCj4+Pgo+Pj4gQXMgaXQncyBnb2luZyB0byBiZSByYXRoZXIgZGlmZmljdWx0IHRvIGNv
bnZpbmNlIHRoZSBMaW51eCBmb2xrcwo+Pj4gdG8gY2hhbmdlIHRoZWlyIGNvZGUgKHBsdXMgdGhp
cyB3b3VsZG4ndCBoZWxwIHdpdGggZXhpc3RpbmcKPj4+IGtlcm5lbHMgYW55d2F5KSwgd2UnbGwg
bmVlZCB0byBmaW5kIGEgd2F5IHRvIGltcHJvdmUgdGhpcyBpbgo+Pj4gdGhlIGh5cGVydmlzb3Iu
Cj4+IEhpIEphbiwgVGltCj4+IElzIHRoaXMgaXNzdWUgaW1wcm92YWJsZSBmcm9tIHhlbiBzaWRl
Pwo+IFByb2JhYmx5OyB3ZSdyZSBsb29raW5nIGludG8gdGhlIGJlc3Qgd2F5IHRvIGFkZHJlc3Mg
aXQuCkhpIEphbiwgVGltCklzIHRoZXJlIGFueSBwYXRjaCBmb3IgdXMgdG8gdGVzdD8KV2UgYXJl
IGxvb2tpbmcgZm93YXJkIHRvIHlvdXIgZml4LgpPdXIgY3VzdG9tZXIgZ290IHVuc2F0aXNmaWVk
IHdpdGggbW9yZSB0aGFuIDMwIG1pbnMgb2YgYm9vdHVwIGFuZCBsb25nIAp0aW1lIHdhaXQuClJl
Z2FyZHMKemR1YW4KCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbi5vcmcKaHR0cDov
L2xpc3RzLnhlbi5vcmcveGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Wed Sep 19 02:39:21 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Sep 2012 02:39:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TEABh-0000Tt-8C; Wed, 19 Sep 2012 02:38:53 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <zhenzhong.duan@oracle.com>) id 1TEABf-0000To-7h
	for xen-devel@lists.xen.org; Wed, 19 Sep 2012 02:38:51 +0000
Received: from [85.158.143.35:4597] by server-2.bemta-4.messagelabs.com id
	81/4F-06610-A3039505; Wed, 19 Sep 2012 02:38:50 +0000
X-Env-Sender: zhenzhong.duan@oracle.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1348022328!7890808!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzQ5NDEz\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18249 invoked from network); 19 Sep 2012 02:38:49 -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; 19 Sep 2012 02:38:49 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q8J2cfLq006389
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 19 Sep 2012 02:38:43 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q8J2cfrC001502
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 19 Sep 2012 02:38:41 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
	q8J2ceWP010672; Tue, 18 Sep 2012 21:38:40 -0500
Received: from [10.191.8.12] (/10.191.8.12)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 18 Sep 2012 19:38:40 -0700
Message-ID: <50593071.2050108@oracle.com>
Date: Wed, 19 Sep 2012 10:39:45 +0800
From: "zhenzhong.duan" <zhenzhong.duan@oracle.com>
Organization: oracle
User-Agent: Mozilla/5.0 (Windows NT 5.1;
	rv:12.0) Gecko/20120428 Thunderbird/12.0.1
MIME-Version: 1.0
To: Tim Deegan <tim@xen.org>
References: <5020F003020000780009322C@nat28.tlf.novell.com>
	<502235E8.9040309@oracle.com>
	<50229B840200007800093A73@nat28.tlf.novell.com>
	<5023860E.7080908@oracle.com>
	<5023AE960200007800093DE8@nat28.tlf.novell.com>
	<502490A7.7020603@oracle.com>
	<502535280200007800094322@nat28.tlf.novell.com>
	<5028B3AB.7060705@oracle.com>
	<5028E53202000078000946B1@nat28.tlf.novell.com>
	<503DAA5F.5030306@oracle.com>
	<20120830090312.GA54290@ocelot.phlegethon.org>
In-Reply-To: <20120830090312.GA54290@ocelot.phlegethon.org>
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: Satish Kantheti <satish.kantheti@oracle.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Feng Jin <joe.jin@oracle.com>, xen-devel <xen-devel@lists.xen.org>,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] kernel bootup slow issue on ovm3.1.1
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: zhenzhong.duan@oracle.com
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 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

Cgrkuo4gMjAxMi0wOC0zMCAxNzowMywgVGltIERlZWdhbiDlhpnpgZM6Cj4gQXQgMTM6MzYgKzA4
MDAgb24gMjkgQXVnICgxMzQ2MjQ3MzkxKSwgemhlbnpob25nLmR1YW4gd3JvdGU6Cj4+Cj4+ID8/
PyAyMDEyLTA4LTEzIDE3OjI5LCBKYW4gQmV1bGljaCA/Pz8/Pz86Cj4+Pj4+PiBPbiAxMy4wOC4x
MiBhdCAwOTo1OCwgInpoZW56aG9uZy5kdWFuIjx6aGVuemhvbmcuZHVhbkBvcmFjbGUuY29tPgo+
Pj4+Pj4gd3JvdGU6Cj4+Pj4gPz8/IDIwMTItMDgtMTAgMjI6MjIsIEphbiBCZXVsaWNoID8/Pz8/
PzoKPj4+Pj4gR29pbmcgYmFjayB0byB5b3VyIG9yaWdpbmFsIG1haWwsIEkgd29uZGVyIGhvd2V2
ZXIgd2h5IHRoaXMKPj4+Pj4gZ2V0cyBkb25lIGF0IGFsbC4gWW91IHNhaWQgaXQgZ290IHRoZXJl
IHZpYQo+Pj4+Pgo+Pj4+PiBtdHJyX2Fwc19pbml0KCkKPj4+Pj4gICAgXC0+ICAgIHNldF9tdHJy
KCkKPj4+Pj4gICAgICAgIFwtPiAgICBtdHJyX3dvcmtfaGFuZGxlcigpCj4+Pj4+Cj4+Pj4+IHll
dCB0aGlzIGlzbid0IGRvbmUgdW5jb25kaXRpb25hbGx5IC0gc2VlIHRoZSBjb21tZW50IGJlZm9y
ZQo+Pj4+PiBjaGVja2luZyBtdHJyX2Fwc19kZWxheWVkX2luaXQuIENhbiB5b3UgZmluZCBvdXQg
d2hlcmUgdGhlCj4+Pj4+IG9idmlvdXNseSBuZWNlc3NhcnkgY2FsbChzKSB0byBzZXRfbXRycl9h
cHNfZGVsYXllZF9pbml0KCkKPj4+Pj4gY29tZShzKSBmcm9tPwo+Pj4+IEF0IGJvb3R1cCBzdGFn
ZSwgc2V0X210cnJfYXBzX2RlbGF5ZWRfaW5pdCBpcyBjYWxsZWQgYnkKPj4+PiBuYXRpdmVfc21w
X3ByZXBhcmVfY3B1cy4KPj4+PiBtdHJyX2Fwc19kZWxheWVkX2luaXQgaXMgYWx3YXlzIHNldCB0
byB0dXJlIGZvciBpbnRlbCBwcm9jZXNzb3IgaW4KPj4+PiB1cHN0cmVhbQo+Pj4+IGNvZGUuCj4+
PiBJbmRlZWQsIGFuZCB0aGF0IChpbiBvbmUgZm9ybSBvciBhbm90aGVyKSBoYXMgYmVlbiBkb25l
Cj4+PiB2aXJ0dWFsbHkgZm9yZXZlciBpbiBMaW51eC4gSSB3b25kZXIgd2h5IHRoZSBwcm9ibGVt
IHdhc24ndAo+Pj4gbm90aWNlZCAob3IgbG9va2VkIGludG8sIGlmIGl0IHdhcyBub3RpY2VkKSBz
byBmYXIuCj4+Pgo+Pj4gQXMgaXQncyBnb2luZyB0byBiZSByYXRoZXIgZGlmZmljdWx0IHRvIGNv
bnZpbmNlIHRoZSBMaW51eCBmb2xrcwo+Pj4gdG8gY2hhbmdlIHRoZWlyIGNvZGUgKHBsdXMgdGhp
cyB3b3VsZG4ndCBoZWxwIHdpdGggZXhpc3RpbmcKPj4+IGtlcm5lbHMgYW55d2F5KSwgd2UnbGwg
bmVlZCB0byBmaW5kIGEgd2F5IHRvIGltcHJvdmUgdGhpcyBpbgo+Pj4gdGhlIGh5cGVydmlzb3Iu
Cj4+IEhpIEphbiwgVGltCj4+IElzIHRoaXMgaXNzdWUgaW1wcm92YWJsZSBmcm9tIHhlbiBzaWRl
Pwo+IFByb2JhYmx5OyB3ZSdyZSBsb29raW5nIGludG8gdGhlIGJlc3Qgd2F5IHRvIGFkZHJlc3Mg
aXQuCkhpIEphbiwgVGltCklzIHRoZXJlIGFueSBwYXRjaCBmb3IgdXMgdG8gdGVzdD8KV2UgYXJl
IGxvb2tpbmcgZm93YXJkIHRvIHlvdXIgZml4LgpPdXIgY3VzdG9tZXIgZ290IHVuc2F0aXNmaWVk
IHdpdGggbW9yZSB0aGFuIDMwIG1pbnMgb2YgYm9vdHVwIGFuZCBsb25nIAp0aW1lIHdhaXQuClJl
Z2FyZHMKemR1YW4KCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbi5vcmcKaHR0cDov
L2xpc3RzLnhlbi5vcmcveGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Wed Sep 19 03:07:37 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Sep 2012 03:07: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 1TEAd8-00011w-9o; Wed, 19 Sep 2012 03:07:14 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <zhenzhong.duan@oracle.com>) id 1TEAd7-00011r-1W
	for xen-devel@lists.xen.org; Wed, 19 Sep 2012 03:07:13 +0000
Received: from [85.158.139.83:26128] by server-5.bemta-5.messagelabs.com id
	10/CA-30514-0E639505; Wed, 19 Sep 2012 03:07:12 +0000
X-Env-Sender: zhenzhong.duan@oracle.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1348024030!30791467!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzQ5NDEz\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28265 invoked from network); 19 Sep 2012 03:07:11 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-5.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 19 Sep 2012 03:07:11 -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 q8J378vg024471
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 19 Sep 2012 03:07:09 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q8J37756029580
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 19 Sep 2012 03:07:08 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
	q8J3770L006645; Tue, 18 Sep 2012 22:07:07 -0500
MIME-Version: 1.0
Message-ID: <2c58eb85-429e-4dc6-942b-f59414a6b399@default>
Date: Tue, 18 Sep 2012 20:07:07 -0700 (PDT)
From: Zhenzhong Duan <zhenzhong.duan@oracle.com>
To: <xen-devel@lists.xen.org>
X-Mailer: Zimbra on Oracle Beehive
Content-Disposition: inline
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: dan.magenheimer@oracle.com, Feng Jin <joe.jin@oracle.com>,
	JBeulich@suse.com, konrad.wilk@oracle.com
Subject: [Xen-devel] Bump tmem pool version to 1 to fix restore issue when
	tmem 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

Restore fail when tmem enabled both in hypervisor and guest.
This is due to spec version mismatch when restore a pool.

Signed-off-by: Zhenzhong Duan <zhenzhong.duan@oracle.com>
---
diff -r d1c3375c3f11 xen/common/tmem.c
--- a/xen/common/tmem.c Mon Sep 17 21:12:21 2012 +0100
+++ b/xen/common/tmem.c Wed Sep 19 10:28:05 2012 +0800
@@ -2397,7 +2397,8 @@
              break;
          rc = (pool->persistent ? TMEM_POOL_PERSIST : 0) |
               (pool->shared ? TMEM_POOL_SHARED : 0) |
-              (pool->pageshift << TMEM_POOL_PAGESIZE_SHIFT);
+              (pool->pageshift << TMEM_POOL_PAGESIZE_SHIFT) |
+              (TMEM_SPEC_VERSION << TMEM_POOL_VERSION_SHIFT);
         break;
     case TMEMC_SAVE_GET_POOL_NPAGES:
          if ( pool == NULL )


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 19 03:07:37 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Sep 2012 03:07: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 1TEAd8-00011w-9o; Wed, 19 Sep 2012 03:07:14 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <zhenzhong.duan@oracle.com>) id 1TEAd7-00011r-1W
	for xen-devel@lists.xen.org; Wed, 19 Sep 2012 03:07:13 +0000
Received: from [85.158.139.83:26128] by server-5.bemta-5.messagelabs.com id
	10/CA-30514-0E639505; Wed, 19 Sep 2012 03:07:12 +0000
X-Env-Sender: zhenzhong.duan@oracle.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1348024030!30791467!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzQ5NDEz\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28265 invoked from network); 19 Sep 2012 03:07:11 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-5.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 19 Sep 2012 03:07:11 -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 q8J378vg024471
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 19 Sep 2012 03:07:09 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q8J37756029580
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 19 Sep 2012 03:07:08 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
	q8J3770L006645; Tue, 18 Sep 2012 22:07:07 -0500
MIME-Version: 1.0
Message-ID: <2c58eb85-429e-4dc6-942b-f59414a6b399@default>
Date: Tue, 18 Sep 2012 20:07:07 -0700 (PDT)
From: Zhenzhong Duan <zhenzhong.duan@oracle.com>
To: <xen-devel@lists.xen.org>
X-Mailer: Zimbra on Oracle Beehive
Content-Disposition: inline
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: dan.magenheimer@oracle.com, Feng Jin <joe.jin@oracle.com>,
	JBeulich@suse.com, konrad.wilk@oracle.com
Subject: [Xen-devel] Bump tmem pool version to 1 to fix restore issue when
	tmem 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

Restore fail when tmem enabled both in hypervisor and guest.
This is due to spec version mismatch when restore a pool.

Signed-off-by: Zhenzhong Duan <zhenzhong.duan@oracle.com>
---
diff -r d1c3375c3f11 xen/common/tmem.c
--- a/xen/common/tmem.c Mon Sep 17 21:12:21 2012 +0100
+++ b/xen/common/tmem.c Wed Sep 19 10:28:05 2012 +0800
@@ -2397,7 +2397,8 @@
              break;
          rc = (pool->persistent ? TMEM_POOL_PERSIST : 0) |
               (pool->shared ? TMEM_POOL_SHARED : 0) |
-              (pool->pageshift << TMEM_POOL_PAGESIZE_SHIFT);
+              (pool->pageshift << TMEM_POOL_PAGESIZE_SHIFT) |
+              (TMEM_SPEC_VERSION << TMEM_POOL_VERSION_SHIFT);
         break;
     case TMEMC_SAVE_GET_POOL_NPAGES:
          if ( pool == NULL )


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 19 03:08:46 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Sep 2012 03: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 1TEAeE-00015E-Oa; Wed, 19 Sep 2012 03:08:22 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jiongxi.li@intel.com>) id 1TEAeC-000153-JO
	for xen-devel@lists.xen.org; Wed, 19 Sep 2012 03:08:20 +0000
Received: from [85.158.137.99:62806] by server-10.bemta-3.messagelabs.com id
	99/49-10411-32739505; Wed, 19 Sep 2012 03:08:19 +0000
X-Env-Sender: jiongxi.li@intel.com
X-Msg-Ref: server-5.tower-217.messagelabs.com!1348024098!13489391!1
X-Originating-IP: [134.134.136.24]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjQgPT4gMzQ0MTQ0\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31148 invoked from network); 19 Sep 2012 03:08:19 -0000
Received: from mga09.intel.com (HELO mga09.intel.com) (134.134.136.24)
	by server-5.tower-217.messagelabs.com with SMTP;
	19 Sep 2012 03:08:19 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga102.jf.intel.com with ESMTP; 18 Sep 2012 20:08:06 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.80,446,1344236400"; d="scan'208";a="207522568"
Received: from fmsmsx103.amr.corp.intel.com ([10.19.9.34])
	by orsmga002.jf.intel.com with ESMTP; 18 Sep 2012 20:08:17 -0700
Received: from fmsmsx152.amr.corp.intel.com (10.19.17.221) by
	FMSMSX103.amr.corp.intel.com (10.19.9.34) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Tue, 18 Sep 2012 20:08:17 -0700
Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by
	fmsmsx152.amr.corp.intel.com (10.19.17.221) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Tue, 18 Sep 2012 20:08:17 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.239]) by
	SHSMSX102.ccr.corp.intel.com ([169.254.2.92]) with mapi id
	14.01.0355.002; Wed, 19 Sep 2012 11:08:16 +0800
From: "Li, Jiongxi" <jiongxi.li@intel.com>
To: Jan Beulich <JBeulich@suse.com>, Keir Fraser <keir@xen.org>
Thread-Topic: [ PATCH v2 0/3] xen: enable APIC-Register Virtualization,
	Virtual-interrupt delivery and add virtual x2apic support
Thread-Index: Ac2RkYwcGctp5410TmmYGfclsA3yngEggkrw
Date: Wed, 19 Sep 2012 03:08:15 +0000
Message-ID: <D9137FCD9CFF644B965863BCFBEDABB87840E9@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: "Zhang, Yang Z" <yang.z.zhang@intel.com>, "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 v2 0/3] xen: enable APIC-Register
 Virtualization, Virtual-interrupt delivery and add virtual x2apic 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 Jan and Keir,
For the APICV patch, do you have any more comment?

Best regards,
Li Jiongxi

> -----Original Message-----
> From: Li, Jiongxi
> Sent: Thursday, September 13, 2012 6:13 PM
> To: 'xen-devel@lists.xen.org'
> Cc: Jan Beulich; 'Keir Fraser'; Zhang, Xiantao; Zhang, Yang Z; Shan, Haitao
> Subject: [ PATCH v2 0/3] xen: enable APIC-Register Virtualization,
> Virtual-interrupt delivery and add virtual x2apic support
> 
> The VMCS includes controls that enable the virtualization of interrupts and the
> Advanced Programmable Interrupt Controller (APIC).
> When these controls are used, the processor will emulate many accesses to
> the APIC, track the state of the virtual APIC, and deliver virtual interrupts - all
> in VMX non-root operation without a VM exit.
> You can refer to Chapter 29 of the latest SDM.
> This series of patches enable APIC-Register Virtualization and Virtual-interrupt
> delivery.
> 
> PATCH 1/3: Enable APIC-Register Virtualization.
> 
> PATCH 2/3: Enable Virtual-interrupt delivery.
> 
> PATCH 3/3: Add virtual x2apic support

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 19 03:08:46 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Sep 2012 03: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 1TEAeE-00015E-Oa; Wed, 19 Sep 2012 03:08:22 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jiongxi.li@intel.com>) id 1TEAeC-000153-JO
	for xen-devel@lists.xen.org; Wed, 19 Sep 2012 03:08:20 +0000
Received: from [85.158.137.99:62806] by server-10.bemta-3.messagelabs.com id
	99/49-10411-32739505; Wed, 19 Sep 2012 03:08:19 +0000
X-Env-Sender: jiongxi.li@intel.com
X-Msg-Ref: server-5.tower-217.messagelabs.com!1348024098!13489391!1
X-Originating-IP: [134.134.136.24]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjQgPT4gMzQ0MTQ0\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31148 invoked from network); 19 Sep 2012 03:08:19 -0000
Received: from mga09.intel.com (HELO mga09.intel.com) (134.134.136.24)
	by server-5.tower-217.messagelabs.com with SMTP;
	19 Sep 2012 03:08:19 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga102.jf.intel.com with ESMTP; 18 Sep 2012 20:08:06 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.80,446,1344236400"; d="scan'208";a="207522568"
Received: from fmsmsx103.amr.corp.intel.com ([10.19.9.34])
	by orsmga002.jf.intel.com with ESMTP; 18 Sep 2012 20:08:17 -0700
Received: from fmsmsx152.amr.corp.intel.com (10.19.17.221) by
	FMSMSX103.amr.corp.intel.com (10.19.9.34) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Tue, 18 Sep 2012 20:08:17 -0700
Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by
	fmsmsx152.amr.corp.intel.com (10.19.17.221) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Tue, 18 Sep 2012 20:08:17 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.239]) by
	SHSMSX102.ccr.corp.intel.com ([169.254.2.92]) with mapi id
	14.01.0355.002; Wed, 19 Sep 2012 11:08:16 +0800
From: "Li, Jiongxi" <jiongxi.li@intel.com>
To: Jan Beulich <JBeulich@suse.com>, Keir Fraser <keir@xen.org>
Thread-Topic: [ PATCH v2 0/3] xen: enable APIC-Register Virtualization,
	Virtual-interrupt delivery and add virtual x2apic support
Thread-Index: Ac2RkYwcGctp5410TmmYGfclsA3yngEggkrw
Date: Wed, 19 Sep 2012 03:08:15 +0000
Message-ID: <D9137FCD9CFF644B965863BCFBEDABB87840E9@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: "Zhang, Yang Z" <yang.z.zhang@intel.com>, "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 v2 0/3] xen: enable APIC-Register
 Virtualization, Virtual-interrupt delivery and add virtual x2apic 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 Jan and Keir,
For the APICV patch, do you have any more comment?

Best regards,
Li Jiongxi

> -----Original Message-----
> From: Li, Jiongxi
> Sent: Thursday, September 13, 2012 6:13 PM
> To: 'xen-devel@lists.xen.org'
> Cc: Jan Beulich; 'Keir Fraser'; Zhang, Xiantao; Zhang, Yang Z; Shan, Haitao
> Subject: [ PATCH v2 0/3] xen: enable APIC-Register Virtualization,
> Virtual-interrupt delivery and add virtual x2apic support
> 
> The VMCS includes controls that enable the virtualization of interrupts and the
> Advanced Programmable Interrupt Controller (APIC).
> When these controls are used, the processor will emulate many accesses to
> the APIC, track the state of the virtual APIC, and deliver virtual interrupts - all
> in VMX non-root operation without a VM exit.
> You can refer to Chapter 29 of the latest SDM.
> This series of patches enable APIC-Register Virtualization and Virtual-interrupt
> delivery.
> 
> PATCH 1/3: Enable APIC-Register Virtualization.
> 
> PATCH 2/3: Enable Virtual-interrupt delivery.
> 
> PATCH 3/3: Add virtual x2apic support

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 19 05:24:59 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Sep 2012 05: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 1TEClz-0001xw-19; Wed, 19 Sep 2012 05:24: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 1TEClx-0001xr-AE
	for xen-devel@lists.xensource.com; Wed, 19 Sep 2012 05:24:29 +0000
Received: from [85.158.143.35:19754] by server-3.bemta-4.messagelabs.com id
	3F/8A-10986-C0759505; Wed, 19 Sep 2012 05:24:28 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1348032268!16412844!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTAwNzc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9653 invoked from network); 19 Sep 2012 05:24:28 -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 Sep 2012 05:24:28 -0000
X-IronPort-AV: E=Sophos;i="4.80,446,1344211200"; d="scan'208";a="14620597"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Sep 2012 05:24: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.279.1; Wed, 19 Sep 2012 06:24: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 1TEClu-0005AY-R3;
	Wed, 19 Sep 2012 05:24:26 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1TEClu-0007yw-N8;
	Wed, 19 Sep 2012 06:24:26 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-13809-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 19 Sep 2012 06:24:26 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13809: 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 13809 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13809/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore            fail   like 13805
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail like 13805
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail like 13805

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  d1c3375c3f11
baseline version:
 xen                  d1c3375c3f11

jobs:
 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-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-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-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-amd64-amd64-xl-win                                      fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Published tested tree is already up to date.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 19 05:24:59 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Sep 2012 05: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 1TEClz-0001xw-19; Wed, 19 Sep 2012 05:24: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 1TEClx-0001xr-AE
	for xen-devel@lists.xensource.com; Wed, 19 Sep 2012 05:24:29 +0000
Received: from [85.158.143.35:19754] by server-3.bemta-4.messagelabs.com id
	3F/8A-10986-C0759505; Wed, 19 Sep 2012 05:24:28 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1348032268!16412844!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTAwNzc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9653 invoked from network); 19 Sep 2012 05:24:28 -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 Sep 2012 05:24:28 -0000
X-IronPort-AV: E=Sophos;i="4.80,446,1344211200"; d="scan'208";a="14620597"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Sep 2012 05:24: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.279.1; Wed, 19 Sep 2012 06:24: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 1TEClu-0005AY-R3;
	Wed, 19 Sep 2012 05:24:26 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1TEClu-0007yw-N8;
	Wed, 19 Sep 2012 06:24:26 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-13809-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 19 Sep 2012 06:24:26 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13809: 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 13809 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13809/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore            fail   like 13805
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail like 13805
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail like 13805

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  d1c3375c3f11
baseline version:
 xen                  d1c3375c3f11

jobs:
 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-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-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-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-amd64-amd64-xl-win                                      fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Published tested tree is already up to date.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 19 06:55:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Sep 2012 06: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 1TEEB9-0002Qo-1O; Wed, 19 Sep 2012 06:54: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 1TEEB7-0002Qj-9L
	for xen-devel@lists.xensource.com; Wed, 19 Sep 2012 06:54:33 +0000
Received: from [85.158.138.51:53667] by server-1.bemta-3.messagelabs.com id
	D4/B9-05884-82C69505; Wed, 19 Sep 2012 06:54:32 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1348037671!31075000!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTAwNzc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12730 invoked from network); 19 Sep 2012 06:54:32 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Sep 2012 06:54:32 -0000
X-IronPort-AV: E=Sophos;i="4.80,446,1344211200"; d="scan'208";a="14621616"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Sep 2012 06:54: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.279.1; Wed, 19 Sep 2012 07:54:31 +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 1TEEB4-0005x5-Tf;
	Wed, 19 Sep 2012 06:54:30 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1TEEB4-0007uC-Qz;
	Wed, 19 Sep 2012 07:54:30 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-13810-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 19 Sep 2012 07:54:30 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [qemu-upstream-4.2-testing test] 13810: 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 13810 qemu-upstream-4.2-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13810/

Failures :-/ but no regressions.

Tests which did not succeed,
including tests which could not be run:
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  9 guest-localmigrate fail never pass
 test-amd64-i386-xl-qemuu-win-vcpus1  9 guest-localmigrate      fail never pass
 test-amd64-amd64-qemuu-win   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64  9 guest-localmigrate      fail never pass
 test-i386-i386-qemuu-win     16 leak-check/check             fail   never pass
 test-i386-i386-xl-qemuu-win   9 guest-localmigrate           fail   never pass
 test-amd64-i386-qemuu-win-vcpus1 16 leak-check/check           fail never pass
 test-amd64-i386-xend-qemuu-winxpsp3 16 leak-check/check        fail never pass
 test-amd64-amd64-xl-qemuu-win  9 guest-localmigrate           fail  never pass
 test-amd64-i386-qemuu-win    16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail never pass
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass


jobs:
 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                           pass    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-win-vcpus1                             fail    
 test-amd64-i386-xl-qemuu-win-vcpus1                          fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-amd64-qemuu-win                                   fail    
 test-amd64-i386-qemuu-win                                    fail    
 test-i386-i386-qemuu-win                                     fail    
 test-amd64-amd64-xl-qemuu-win                                fail    
 test-i386-i386-xl-qemuu-win                                  fail    
 test-amd64-i386-xend-qemuu-winxpsp3                          fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 19 06:55:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Sep 2012 06: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 1TEEB9-0002Qo-1O; Wed, 19 Sep 2012 06:54: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 1TEEB7-0002Qj-9L
	for xen-devel@lists.xensource.com; Wed, 19 Sep 2012 06:54:33 +0000
Received: from [85.158.138.51:53667] by server-1.bemta-3.messagelabs.com id
	D4/B9-05884-82C69505; Wed, 19 Sep 2012 06:54:32 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1348037671!31075000!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTAwNzc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12730 invoked from network); 19 Sep 2012 06:54:32 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Sep 2012 06:54:32 -0000
X-IronPort-AV: E=Sophos;i="4.80,446,1344211200"; d="scan'208";a="14621616"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Sep 2012 06:54: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.279.1; Wed, 19 Sep 2012 07:54:31 +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 1TEEB4-0005x5-Tf;
	Wed, 19 Sep 2012 06:54:30 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1TEEB4-0007uC-Qz;
	Wed, 19 Sep 2012 07:54:30 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-13810-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 19 Sep 2012 07:54:30 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [qemu-upstream-4.2-testing test] 13810: 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 13810 qemu-upstream-4.2-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13810/

Failures :-/ but no regressions.

Tests which did not succeed,
including tests which could not be run:
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  9 guest-localmigrate fail never pass
 test-amd64-i386-xl-qemuu-win-vcpus1  9 guest-localmigrate      fail never pass
 test-amd64-amd64-qemuu-win   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64  9 guest-localmigrate      fail never pass
 test-i386-i386-qemuu-win     16 leak-check/check             fail   never pass
 test-i386-i386-xl-qemuu-win   9 guest-localmigrate           fail   never pass
 test-amd64-i386-qemuu-win-vcpus1 16 leak-check/check           fail never pass
 test-amd64-i386-xend-qemuu-winxpsp3 16 leak-check/check        fail never pass
 test-amd64-amd64-xl-qemuu-win  9 guest-localmigrate           fail  never pass
 test-amd64-i386-qemuu-win    16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail never pass
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass


jobs:
 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                           pass    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-win-vcpus1                             fail    
 test-amd64-i386-xl-qemuu-win-vcpus1                          fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-amd64-qemuu-win                                   fail    
 test-amd64-i386-qemuu-win                                    fail    
 test-i386-i386-qemuu-win                                     fail    
 test-amd64-amd64-xl-qemuu-win                                fail    
 test-i386-i386-xl-qemuu-win                                  fail    
 test-amd64-i386-xend-qemuu-winxpsp3                          fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 19 07:23:02 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Sep 2012 07:23:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TEEcE-0002rz-4x; Wed, 19 Sep 2012 07:22:34 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1TEEcC-0002ru-C4
	for xen-devel@lists.xen.org; Wed, 19 Sep 2012 07:22:32 +0000
Received: from [85.158.143.99:33966] by server-1.bemta-4.messagelabs.com id
	6C/6E-05684-7B279505; Wed, 19 Sep 2012 07:22:31 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1348039351!30330545!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13069 invoked from network); 19 Sep 2012 07:22:31 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-3.tower-216.messagelabs.com with SMTP;
	19 Sep 2012 07:22:31 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 19 Sep 2012 08:22:30 +0100
Message-Id: <50598ED5020000780009C381@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 19 Sep 2012 08:22:29 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Jiongxi Li" <jiongxi.li@intel.com>
References: <D9137FCD9CFF644B965863BCFBEDABB87840E9@SHSMSX101.ccr.corp.intel.com>
In-Reply-To: <D9137FCD9CFF644B965863BCFBEDABB87840E9@SHSMSX101.ccr.corp.intel.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Yang Z Zhang <yang.z.zhang@intel.com>, Keir Fraser <keir@xen.org>,
	Haitao Shan <haitao.shan@intel.com>,
	Xiantao Zhang <xiantao.zhang@intel.com>,
	"'xen-devel@lists.xen.org'" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [ PATCH v2 0/3] xen: enable APIC-Register
 Virtualization, Virtual-interrupt delivery and add virtual x2apic 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.09.12 at 05:08, "Li, Jiongxi" <jiongxi.li@intel.com> wrote:
> Hi Jan and Keir,
> For the APICV patch, do you have any more comment?

Keir applied the three patches already, and they even came out of
staging already.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 19 07:23:02 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Sep 2012 07:23:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TEEcE-0002rz-4x; Wed, 19 Sep 2012 07:22:34 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1TEEcC-0002ru-C4
	for xen-devel@lists.xen.org; Wed, 19 Sep 2012 07:22:32 +0000
Received: from [85.158.143.99:33966] by server-1.bemta-4.messagelabs.com id
	6C/6E-05684-7B279505; Wed, 19 Sep 2012 07:22:31 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1348039351!30330545!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13069 invoked from network); 19 Sep 2012 07:22:31 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-3.tower-216.messagelabs.com with SMTP;
	19 Sep 2012 07:22:31 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 19 Sep 2012 08:22:30 +0100
Message-Id: <50598ED5020000780009C381@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 19 Sep 2012 08:22:29 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Jiongxi Li" <jiongxi.li@intel.com>
References: <D9137FCD9CFF644B965863BCFBEDABB87840E9@SHSMSX101.ccr.corp.intel.com>
In-Reply-To: <D9137FCD9CFF644B965863BCFBEDABB87840E9@SHSMSX101.ccr.corp.intel.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Yang Z Zhang <yang.z.zhang@intel.com>, Keir Fraser <keir@xen.org>,
	Haitao Shan <haitao.shan@intel.com>,
	Xiantao Zhang <xiantao.zhang@intel.com>,
	"'xen-devel@lists.xen.org'" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [ PATCH v2 0/3] xen: enable APIC-Register
 Virtualization, Virtual-interrupt delivery and add virtual x2apic 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.09.12 at 05:08, "Li, Jiongxi" <jiongxi.li@intel.com> wrote:
> Hi Jan and Keir,
> For the APICV patch, do you have any more comment?

Keir applied the three patches already, and they even came out of
staging already.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 19 07:29:34 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Sep 2012 07: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 1TEEic-00031B-W9; Wed, 19 Sep 2012 07: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 1TEEic-000315-Bp
	for xen-devel@lists.xen.org; Wed, 19 Sep 2012 07:29:10 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1348039744!5996121!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17217 invoked from network); 19 Sep 2012 07:29:04 -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;
	19 Sep 2012 07:29:04 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 19 Sep 2012 08:29:03 +0100
Message-Id: <5059905E020000780009C394@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 19 Sep 2012 08:29:02 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Keir Fraser" <keir.xen@gmail.com>
References: <5058AEC6020000780009C081@nat28.tlf.novell.com>
	<CC7E5507.3F134%keir.xen@gmail.com>
In-Reply-To: <CC7E5507.3F134%keir.xen@gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] ACPI: move tables.c fully into .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 18.09.12 at 17:42, Keir Fraser <keir.xen@gmail.com> wrote:
> On 18/09/2012 16:26, "Jan Beulich" <JBeulich@suse.com> wrote:
> 
>> The only non-init item was the space reserved for the initial tables,
>> but we can as well dynamically allocate that array.
>> 
>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> 
> Really worthwhile, versus having to round up the initial_tables[] allocation
> to a whole number of pages?

It was exactly one page in size already.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 19 07:29:34 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Sep 2012 07: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 1TEEic-00031B-W9; Wed, 19 Sep 2012 07: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 1TEEic-000315-Bp
	for xen-devel@lists.xen.org; Wed, 19 Sep 2012 07:29:10 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1348039744!5996121!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17217 invoked from network); 19 Sep 2012 07:29:04 -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;
	19 Sep 2012 07:29:04 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 19 Sep 2012 08:29:03 +0100
Message-Id: <5059905E020000780009C394@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 19 Sep 2012 08:29:02 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Keir Fraser" <keir.xen@gmail.com>
References: <5058AEC6020000780009C081@nat28.tlf.novell.com>
	<CC7E5507.3F134%keir.xen@gmail.com>
In-Reply-To: <CC7E5507.3F134%keir.xen@gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] ACPI: move tables.c fully into .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 18.09.12 at 17:42, Keir Fraser <keir.xen@gmail.com> wrote:
> On 18/09/2012 16:26, "Jan Beulich" <JBeulich@suse.com> wrote:
> 
>> The only non-init item was the space reserved for the initial tables,
>> but we can as well dynamically allocate that array.
>> 
>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> 
> Really worthwhile, versus having to round up the initial_tables[] allocation
> to a whole number of pages?

It was exactly one page in size already.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 19 07:37:23 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Sep 2012 07: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 1TEEqG-0003E9-18; Wed, 19 Sep 2012 07:37: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 1TEEqE-0003E4-Ju
	for xen-devel@lists.xen.org; Wed, 19 Sep 2012 07:37:02 +0000
Received: from [85.158.143.35:4089] by server-2.bemta-4.messagelabs.com id
	56/5F-06610-D1679505; Wed, 19 Sep 2012 07:37:01 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1348040185!18955515!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24504 invoked from network); 19 Sep 2012 07:36:26 -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;
	19 Sep 2012 07:36:26 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 19 Sep 2012 08:36:25 +0100
Message-Id: <50599218020000780009C39A@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 19 Sep 2012 08:36:24 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__PartFCCDF8E8.0__="
Subject: [Xen-devel] [PATCH] x86/IO-APIC: streamline level ack/end 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.

--=__PartFCCDF8E8.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Rather than evaluating "ioapic_ack_new" on each invocation, and
considering that the two methods really have almost no code in common,
split the handlers.

While at it, also move ioapic_ack_{new,forced} into .init.data
(eliminating the single non-__init reference to the former).

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/arch/x86/io_apic.c
+++ b/xen/arch/x86/io_apic.c
@@ -43,8 +43,8 @@ static struct { int pin, apic; } ioapic_
 static DEFINE_SPINLOCK(ioapic_lock);
=20
 bool_t __read_mostly skip_ioapic_setup;
-bool_t __read_mostly ioapic_ack_new =3D 1;
-bool_t __read_mostly ioapic_ack_forced =3D 0;
+bool_t __initdata ioapic_ack_new =3D 1;
+bool_t __initdata ioapic_ack_forced =3D 0;
=20
 /*
  * # of IRQ routing registers
@@ -918,7 +918,7 @@ static inline int IO_APIC_irq_trigger(in
     return 0;
 }
=20
-static hw_irq_controller ioapic_level_type;
+static struct hw_interrupt_type ioapic_level_type;
 static hw_irq_controller ioapic_edge_type;
=20
 #define IOAPIC_AUTO	-1
@@ -1605,9 +1605,6 @@ static void mask_and_ack_level_ioapic_ir
=20
     irq_complete_move(desc);
=20
-    if ( ioapic_ack_new )
-        return;
-
     if ( !directed_eoi_enabled )
         mask_IO_APIC_irq(desc);
=20
@@ -1651,34 +1648,29 @@ static void mask_and_ack_level_ioapic_ir
     }
 }
=20
-static void end_level_ioapic_irq(struct irq_desc *desc, u8 vector)
+static void end_level_ioapic_irq_old(struct irq_desc *desc, u8 vector)
 {
-    unsigned long v;
-    int i;
-
-    if ( !ioapic_ack_new )
+    if ( directed_eoi_enabled )
     {
-        if ( directed_eoi_enabled )
+        if ( !(desc->status & (IRQ_DISABLED|IRQ_MOVE_PENDING)) )
         {
-            if ( !(desc->status & (IRQ_DISABLED|IRQ_MOVE_PENDING)) )
-            {
-                eoi_IO_APIC_irq(desc);
-                return;
-            }
-
-            mask_IO_APIC_irq(desc);
             eoi_IO_APIC_irq(desc);
-            if ( (desc->status & IRQ_MOVE_PENDING) &&
-                 !io_apic_level_ack_pending(desc->irq) )
-                move_masked_irq(desc);
+            return;
         }
=20
-        if ( !(desc->status & IRQ_DISABLED) )
-            unmask_IO_APIC_irq(desc);
-
-        return;
+        mask_IO_APIC_irq(desc);
+        eoi_IO_APIC_irq(desc);
+        if ( (desc->status & IRQ_MOVE_PENDING) &&
+             !io_apic_level_ack_pending(desc->irq) )
+            move_masked_irq(desc);
     }
=20
+    if ( !(desc->status & IRQ_DISABLED) )
+        unmask_IO_APIC_irq(desc);
+}
+
+static void end_level_ioapic_irq_new(struct irq_desc *desc, u8 vector)
+{
 /*
  * It appears there is an erratum which affects at least version 0x11
  * of I/O APIC (that's the 82093AA and cores integrated into various
@@ -1698,7 +1690,7 @@ static void end_level_ioapic_irq(struct=20
  * operation to prevent an edge-triggered interrupt escaping meanwhile.
  * The idea is from Manfred Spraul.  --macro
  */
-    i =3D desc->arch.vector;
+    unsigned int v, i =3D desc->arch.vector;
=20
     /* Manually EOI the old vector if we are moving to the new */
     if ( vector && i !=3D vector )
@@ -1741,14 +1733,14 @@ static hw_irq_controller ioapic_edge_typ
     .set_affinity 	=3D set_ioapic_affinity_irq,
 };
=20
-static hw_irq_controller ioapic_level_type =3D {
+static struct hw_interrupt_type __read_mostly ioapic_level_type =3D {
     .typename 	=3D "IO-APIC-level",
     .startup 	=3D startup_level_ioapic_irq,
     .shutdown 	=3D mask_IO_APIC_irq,
     .enable 	=3D unmask_IO_APIC_irq,
     .disable 	=3D mask_IO_APIC_irq,
     .ack 		=3D mask_and_ack_level_ioapic_irq,
-    .end 		=3D end_level_ioapic_irq,
+    .end 		=3D end_level_ioapic_irq_old,
     .set_affinity 	=3D set_ioapic_affinity_irq,
 };
=20
@@ -2006,6 +1998,11 @@ void __init setup_IO_APIC(void)
     printk("ENABLING IO-APIC IRQs\n");
     printk(" -> Using %s ACK method\n", ioapic_ack_new ? "new" : "old");
=20
+    if (ioapic_ack_new) {
+        ioapic_level_type.ack =3D irq_complete_move;
+        ioapic_level_type.end =3D end_level_ioapic_irq_new;
+    }
+
     /*
      * Set up IO-APIC IRQ routing.
      */
--- a/xen/arch/x86/irq.c
+++ b/xen/arch/x86/irq.c
@@ -1495,7 +1495,8 @@ static int pirq_acktype(struct domain *d
      * on which they were received. This is because we tickle the LAPIC =
to EOI.
      */
     if ( !strcmp(desc->handler->typename, "IO-APIC-level") )
-        return ioapic_ack_new ? ACKTYPE_EOI : ACKTYPE_UNMASK;
+        return desc->handler->ack =3D=3D irq_complete_move ?
+               ACKTYPE_EOI : ACKTYPE_UNMASK;
=20
     /* Legacy PIC interrupts can be acknowledged from any CPU. */
     if ( !strcmp(desc->handler->typename, "XT-PIC") )



--=__PartFCCDF8E8.0__=
Content-Type: text/plain; name="x86-ioapic-streamline-level.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="x86-ioapic-streamline-level.patch"

x86/IO-APIC: streamline level ack/end handling=0A=0ARather than evaluating =
"ioapic_ack_new" on each invocation, and=0Aconsidering that the two =
methods really have almost no code in common,=0Asplit the handlers.=0A=0AWh=
ile at it, also move ioapic_ack_{new,forced} into .init.data=0A(eliminating=
 the single non-__init reference to the former).=0A=0ASigned-off-by: Jan =
Beulich <jbeulich@suse.com>=0A=0A--- a/xen/arch/x86/io_apic.c=0A+++ =
b/xen/arch/x86/io_apic.c=0A@@ -43,8 +43,8 @@ static struct { int pin, =
apic; } ioapic_=0A static DEFINE_SPINLOCK(ioapic_lock);=0A =0A bool_t =
__read_mostly skip_ioapic_setup;=0A-bool_t __read_mostly ioapic_ack_new =
=3D 1;=0A-bool_t __read_mostly ioapic_ack_forced =3D 0;=0A+bool_t =
__initdata ioapic_ack_new =3D 1;=0A+bool_t __initdata ioapic_ack_forced =
=3D 0;=0A =0A /*=0A  * # of IRQ routing registers=0A@@ -918,7 +918,7 @@ =
static inline int IO_APIC_irq_trigger(in=0A     return 0;=0A }=0A =
=0A-static hw_irq_controller ioapic_level_type;=0A+static struct hw_interru=
pt_type ioapic_level_type;=0A static hw_irq_controller ioapic_edge_type;=0A=
 =0A #define IOAPIC_AUTO	-1=0A@@ -1605,9 +1605,6 @@ static void =
mask_and_ack_level_ioapic_ir=0A =0A     irq_complete_move(desc);=0A =0A-   =
 if ( ioapic_ack_new )=0A-        return;=0A-=0A     if ( !directed_eoi_ena=
bled )=0A         mask_IO_APIC_irq(desc);=0A =0A@@ -1651,34 +1648,29 @@ =
static void mask_and_ack_level_ioapic_ir=0A     }=0A }=0A =0A-static void =
end_level_ioapic_irq(struct irq_desc *desc, u8 vector)=0A+static void =
end_level_ioapic_irq_old(struct irq_desc *desc, u8 vector)=0A {=0A-    =
unsigned long v;=0A-    int i;=0A-=0A-    if ( !ioapic_ack_new )=0A+    if =
( directed_eoi_enabled )=0A     {=0A-        if ( directed_eoi_enabled =
)=0A+        if ( !(desc->status & (IRQ_DISABLED|IRQ_MOVE_PENDING)) )=0A   =
      {=0A-            if ( !(desc->status & (IRQ_DISABLED|IRQ_MOVE_PENDING=
)) )=0A-            {=0A-                eoi_IO_APIC_irq(desc);=0A-        =
        return;=0A-            }=0A-=0A-            mask_IO_APIC_irq(desc);=
=0A             eoi_IO_APIC_irq(desc);=0A-            if ( (desc->status & =
IRQ_MOVE_PENDING) &&=0A-                 !io_apic_level_ack_pending(desc->i=
rq) )=0A-                move_masked_irq(desc);=0A+            return;=0A  =
       }=0A =0A-        if ( !(desc->status & IRQ_DISABLED) )=0A-          =
  unmask_IO_APIC_irq(desc);=0A-=0A-        return;=0A+        mask_IO_APIC_=
irq(desc);=0A+        eoi_IO_APIC_irq(desc);=0A+        if ( (desc->status =
& IRQ_MOVE_PENDING) &&=0A+             !io_apic_level_ack_pending(desc->irq=
) )=0A+            move_masked_irq(desc);=0A     }=0A =0A+    if ( =
!(desc->status & IRQ_DISABLED) )=0A+        unmask_IO_APIC_irq(desc);=0A+}=
=0A+=0A+static void end_level_ioapic_irq_new(struct irq_desc *desc, u8 =
vector)=0A+{=0A /*=0A  * It appears there is an erratum which affects at =
least version 0x11=0A  * of I/O APIC (that's the 82093AA and cores =
integrated into various=0A@@ -1698,7 +1690,7 @@ static void end_level_ioapi=
c_irq(struct =0A  * operation to prevent an edge-triggered interrupt =
escaping meanwhile.=0A  * The idea is from Manfred Spraul.  --macro=0A  =
*/=0A-    i =3D desc->arch.vector;=0A+    unsigned int v, i =3D desc->arch.=
vector;=0A =0A     /* Manually EOI the old vector if we are moving to the =
new */=0A     if ( vector && i !=3D vector )=0A@@ -1741,14 +1733,14 @@ =
static hw_irq_controller ioapic_edge_typ=0A     .set_affinity 	=3D =
set_ioapic_affinity_irq,=0A };=0A =0A-static hw_irq_controller ioapic_level=
_type =3D {=0A+static struct hw_interrupt_type __read_mostly ioapic_level_t=
ype =3D {=0A     .typename 	=3D "IO-APIC-level",=0A     .startup 	=
=3D startup_level_ioapic_irq,=0A     .shutdown 	=3D mask_IO_APIC_irq,=0A   =
  .enable 	=3D unmask_IO_APIC_irq,=0A     .disable 	=3D =
mask_IO_APIC_irq,=0A     .ack 		=3D mask_and_ack_level_ioapic_irq,=
=0A-    .end 		=3D end_level_ioapic_irq,=0A+    .end 		=
=3D end_level_ioapic_irq_old,=0A     .set_affinity 	=3D set_ioapic_affi=
nity_irq,=0A };=0A =0A@@ -2006,6 +1998,11 @@ void __init setup_IO_APIC(void=
)=0A     printk("ENABLING IO-APIC IRQs\n");=0A     printk(" -> Using %s =
ACK method\n", ioapic_ack_new ? "new" : "old");=0A =0A+    if (ioapic_ack_n=
ew) {=0A+        ioapic_level_type.ack =3D irq_complete_move;=0A+        =
ioapic_level_type.end =3D end_level_ioapic_irq_new;=0A+    }=0A+=0A     =
/*=0A      * Set up IO-APIC IRQ routing.=0A      */=0A--- a/xen/arch/x86/ir=
q.c=0A+++ b/xen/arch/x86/irq.c=0A@@ -1495,7 +1495,8 @@ static int =
pirq_acktype(struct domain *d=0A      * on which they were received. This =
is because we tickle the LAPIC to EOI.=0A      */=0A     if ( !strcmp(desc-=
>handler->typename, "IO-APIC-level") )=0A-        return ioapic_ack_new ? =
ACKTYPE_EOI : ACKTYPE_UNMASK;=0A+        return desc->handler->ack =3D=3D =
irq_complete_move ?=0A+               ACKTYPE_EOI : ACKTYPE_UNMASK;=0A =0A =
    /* Legacy PIC interrupts can be acknowledged from any CPU. */=0A     =
if ( !strcmp(desc->handler->typename, "XT-PIC") )=0A
--=__PartFCCDF8E8.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

--=__PartFCCDF8E8.0__=--


From xen-devel-bounces@lists.xen.org Wed Sep 19 07:37:23 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Sep 2012 07: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 1TEEqG-0003E9-18; Wed, 19 Sep 2012 07:37: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 1TEEqE-0003E4-Ju
	for xen-devel@lists.xen.org; Wed, 19 Sep 2012 07:37:02 +0000
Received: from [85.158.143.35:4089] by server-2.bemta-4.messagelabs.com id
	56/5F-06610-D1679505; Wed, 19 Sep 2012 07:37:01 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1348040185!18955515!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24504 invoked from network); 19 Sep 2012 07:36:26 -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;
	19 Sep 2012 07:36:26 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 19 Sep 2012 08:36:25 +0100
Message-Id: <50599218020000780009C39A@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 19 Sep 2012 08:36:24 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__PartFCCDF8E8.0__="
Subject: [Xen-devel] [PATCH] x86/IO-APIC: streamline level ack/end 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.

--=__PartFCCDF8E8.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Rather than evaluating "ioapic_ack_new" on each invocation, and
considering that the two methods really have almost no code in common,
split the handlers.

While at it, also move ioapic_ack_{new,forced} into .init.data
(eliminating the single non-__init reference to the former).

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/arch/x86/io_apic.c
+++ b/xen/arch/x86/io_apic.c
@@ -43,8 +43,8 @@ static struct { int pin, apic; } ioapic_
 static DEFINE_SPINLOCK(ioapic_lock);
=20
 bool_t __read_mostly skip_ioapic_setup;
-bool_t __read_mostly ioapic_ack_new =3D 1;
-bool_t __read_mostly ioapic_ack_forced =3D 0;
+bool_t __initdata ioapic_ack_new =3D 1;
+bool_t __initdata ioapic_ack_forced =3D 0;
=20
 /*
  * # of IRQ routing registers
@@ -918,7 +918,7 @@ static inline int IO_APIC_irq_trigger(in
     return 0;
 }
=20
-static hw_irq_controller ioapic_level_type;
+static struct hw_interrupt_type ioapic_level_type;
 static hw_irq_controller ioapic_edge_type;
=20
 #define IOAPIC_AUTO	-1
@@ -1605,9 +1605,6 @@ static void mask_and_ack_level_ioapic_ir
=20
     irq_complete_move(desc);
=20
-    if ( ioapic_ack_new )
-        return;
-
     if ( !directed_eoi_enabled )
         mask_IO_APIC_irq(desc);
=20
@@ -1651,34 +1648,29 @@ static void mask_and_ack_level_ioapic_ir
     }
 }
=20
-static void end_level_ioapic_irq(struct irq_desc *desc, u8 vector)
+static void end_level_ioapic_irq_old(struct irq_desc *desc, u8 vector)
 {
-    unsigned long v;
-    int i;
-
-    if ( !ioapic_ack_new )
+    if ( directed_eoi_enabled )
     {
-        if ( directed_eoi_enabled )
+        if ( !(desc->status & (IRQ_DISABLED|IRQ_MOVE_PENDING)) )
         {
-            if ( !(desc->status & (IRQ_DISABLED|IRQ_MOVE_PENDING)) )
-            {
-                eoi_IO_APIC_irq(desc);
-                return;
-            }
-
-            mask_IO_APIC_irq(desc);
             eoi_IO_APIC_irq(desc);
-            if ( (desc->status & IRQ_MOVE_PENDING) &&
-                 !io_apic_level_ack_pending(desc->irq) )
-                move_masked_irq(desc);
+            return;
         }
=20
-        if ( !(desc->status & IRQ_DISABLED) )
-            unmask_IO_APIC_irq(desc);
-
-        return;
+        mask_IO_APIC_irq(desc);
+        eoi_IO_APIC_irq(desc);
+        if ( (desc->status & IRQ_MOVE_PENDING) &&
+             !io_apic_level_ack_pending(desc->irq) )
+            move_masked_irq(desc);
     }
=20
+    if ( !(desc->status & IRQ_DISABLED) )
+        unmask_IO_APIC_irq(desc);
+}
+
+static void end_level_ioapic_irq_new(struct irq_desc *desc, u8 vector)
+{
 /*
  * It appears there is an erratum which affects at least version 0x11
  * of I/O APIC (that's the 82093AA and cores integrated into various
@@ -1698,7 +1690,7 @@ static void end_level_ioapic_irq(struct=20
  * operation to prevent an edge-triggered interrupt escaping meanwhile.
  * The idea is from Manfred Spraul.  --macro
  */
-    i =3D desc->arch.vector;
+    unsigned int v, i =3D desc->arch.vector;
=20
     /* Manually EOI the old vector if we are moving to the new */
     if ( vector && i !=3D vector )
@@ -1741,14 +1733,14 @@ static hw_irq_controller ioapic_edge_typ
     .set_affinity 	=3D set_ioapic_affinity_irq,
 };
=20
-static hw_irq_controller ioapic_level_type =3D {
+static struct hw_interrupt_type __read_mostly ioapic_level_type =3D {
     .typename 	=3D "IO-APIC-level",
     .startup 	=3D startup_level_ioapic_irq,
     .shutdown 	=3D mask_IO_APIC_irq,
     .enable 	=3D unmask_IO_APIC_irq,
     .disable 	=3D mask_IO_APIC_irq,
     .ack 		=3D mask_and_ack_level_ioapic_irq,
-    .end 		=3D end_level_ioapic_irq,
+    .end 		=3D end_level_ioapic_irq_old,
     .set_affinity 	=3D set_ioapic_affinity_irq,
 };
=20
@@ -2006,6 +1998,11 @@ void __init setup_IO_APIC(void)
     printk("ENABLING IO-APIC IRQs\n");
     printk(" -> Using %s ACK method\n", ioapic_ack_new ? "new" : "old");
=20
+    if (ioapic_ack_new) {
+        ioapic_level_type.ack =3D irq_complete_move;
+        ioapic_level_type.end =3D end_level_ioapic_irq_new;
+    }
+
     /*
      * Set up IO-APIC IRQ routing.
      */
--- a/xen/arch/x86/irq.c
+++ b/xen/arch/x86/irq.c
@@ -1495,7 +1495,8 @@ static int pirq_acktype(struct domain *d
      * on which they were received. This is because we tickle the LAPIC =
to EOI.
      */
     if ( !strcmp(desc->handler->typename, "IO-APIC-level") )
-        return ioapic_ack_new ? ACKTYPE_EOI : ACKTYPE_UNMASK;
+        return desc->handler->ack =3D=3D irq_complete_move ?
+               ACKTYPE_EOI : ACKTYPE_UNMASK;
=20
     /* Legacy PIC interrupts can be acknowledged from any CPU. */
     if ( !strcmp(desc->handler->typename, "XT-PIC") )



--=__PartFCCDF8E8.0__=
Content-Type: text/plain; name="x86-ioapic-streamline-level.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="x86-ioapic-streamline-level.patch"

x86/IO-APIC: streamline level ack/end handling=0A=0ARather than evaluating =
"ioapic_ack_new" on each invocation, and=0Aconsidering that the two =
methods really have almost no code in common,=0Asplit the handlers.=0A=0AWh=
ile at it, also move ioapic_ack_{new,forced} into .init.data=0A(eliminating=
 the single non-__init reference to the former).=0A=0ASigned-off-by: Jan =
Beulich <jbeulich@suse.com>=0A=0A--- a/xen/arch/x86/io_apic.c=0A+++ =
b/xen/arch/x86/io_apic.c=0A@@ -43,8 +43,8 @@ static struct { int pin, =
apic; } ioapic_=0A static DEFINE_SPINLOCK(ioapic_lock);=0A =0A bool_t =
__read_mostly skip_ioapic_setup;=0A-bool_t __read_mostly ioapic_ack_new =
=3D 1;=0A-bool_t __read_mostly ioapic_ack_forced =3D 0;=0A+bool_t =
__initdata ioapic_ack_new =3D 1;=0A+bool_t __initdata ioapic_ack_forced =
=3D 0;=0A =0A /*=0A  * # of IRQ routing registers=0A@@ -918,7 +918,7 @@ =
static inline int IO_APIC_irq_trigger(in=0A     return 0;=0A }=0A =
=0A-static hw_irq_controller ioapic_level_type;=0A+static struct hw_interru=
pt_type ioapic_level_type;=0A static hw_irq_controller ioapic_edge_type;=0A=
 =0A #define IOAPIC_AUTO	-1=0A@@ -1605,9 +1605,6 @@ static void =
mask_and_ack_level_ioapic_ir=0A =0A     irq_complete_move(desc);=0A =0A-   =
 if ( ioapic_ack_new )=0A-        return;=0A-=0A     if ( !directed_eoi_ena=
bled )=0A         mask_IO_APIC_irq(desc);=0A =0A@@ -1651,34 +1648,29 @@ =
static void mask_and_ack_level_ioapic_ir=0A     }=0A }=0A =0A-static void =
end_level_ioapic_irq(struct irq_desc *desc, u8 vector)=0A+static void =
end_level_ioapic_irq_old(struct irq_desc *desc, u8 vector)=0A {=0A-    =
unsigned long v;=0A-    int i;=0A-=0A-    if ( !ioapic_ack_new )=0A+    if =
( directed_eoi_enabled )=0A     {=0A-        if ( directed_eoi_enabled =
)=0A+        if ( !(desc->status & (IRQ_DISABLED|IRQ_MOVE_PENDING)) )=0A   =
      {=0A-            if ( !(desc->status & (IRQ_DISABLED|IRQ_MOVE_PENDING=
)) )=0A-            {=0A-                eoi_IO_APIC_irq(desc);=0A-        =
        return;=0A-            }=0A-=0A-            mask_IO_APIC_irq(desc);=
=0A             eoi_IO_APIC_irq(desc);=0A-            if ( (desc->status & =
IRQ_MOVE_PENDING) &&=0A-                 !io_apic_level_ack_pending(desc->i=
rq) )=0A-                move_masked_irq(desc);=0A+            return;=0A  =
       }=0A =0A-        if ( !(desc->status & IRQ_DISABLED) )=0A-          =
  unmask_IO_APIC_irq(desc);=0A-=0A-        return;=0A+        mask_IO_APIC_=
irq(desc);=0A+        eoi_IO_APIC_irq(desc);=0A+        if ( (desc->status =
& IRQ_MOVE_PENDING) &&=0A+             !io_apic_level_ack_pending(desc->irq=
) )=0A+            move_masked_irq(desc);=0A     }=0A =0A+    if ( =
!(desc->status & IRQ_DISABLED) )=0A+        unmask_IO_APIC_irq(desc);=0A+}=
=0A+=0A+static void end_level_ioapic_irq_new(struct irq_desc *desc, u8 =
vector)=0A+{=0A /*=0A  * It appears there is an erratum which affects at =
least version 0x11=0A  * of I/O APIC (that's the 82093AA and cores =
integrated into various=0A@@ -1698,7 +1690,7 @@ static void end_level_ioapi=
c_irq(struct =0A  * operation to prevent an edge-triggered interrupt =
escaping meanwhile.=0A  * The idea is from Manfred Spraul.  --macro=0A  =
*/=0A-    i =3D desc->arch.vector;=0A+    unsigned int v, i =3D desc->arch.=
vector;=0A =0A     /* Manually EOI the old vector if we are moving to the =
new */=0A     if ( vector && i !=3D vector )=0A@@ -1741,14 +1733,14 @@ =
static hw_irq_controller ioapic_edge_typ=0A     .set_affinity 	=3D =
set_ioapic_affinity_irq,=0A };=0A =0A-static hw_irq_controller ioapic_level=
_type =3D {=0A+static struct hw_interrupt_type __read_mostly ioapic_level_t=
ype =3D {=0A     .typename 	=3D "IO-APIC-level",=0A     .startup 	=
=3D startup_level_ioapic_irq,=0A     .shutdown 	=3D mask_IO_APIC_irq,=0A   =
  .enable 	=3D unmask_IO_APIC_irq,=0A     .disable 	=3D =
mask_IO_APIC_irq,=0A     .ack 		=3D mask_and_ack_level_ioapic_irq,=
=0A-    .end 		=3D end_level_ioapic_irq,=0A+    .end 		=
=3D end_level_ioapic_irq_old,=0A     .set_affinity 	=3D set_ioapic_affi=
nity_irq,=0A };=0A =0A@@ -2006,6 +1998,11 @@ void __init setup_IO_APIC(void=
)=0A     printk("ENABLING IO-APIC IRQs\n");=0A     printk(" -> Using %s =
ACK method\n", ioapic_ack_new ? "new" : "old");=0A =0A+    if (ioapic_ack_n=
ew) {=0A+        ioapic_level_type.ack =3D irq_complete_move;=0A+        =
ioapic_level_type.end =3D end_level_ioapic_irq_new;=0A+    }=0A+=0A     =
/*=0A      * Set up IO-APIC IRQ routing.=0A      */=0A--- a/xen/arch/x86/ir=
q.c=0A+++ b/xen/arch/x86/irq.c=0A@@ -1495,7 +1495,8 @@ static int =
pirq_acktype(struct domain *d=0A      * on which they were received. This =
is because we tickle the LAPIC to EOI.=0A      */=0A     if ( !strcmp(desc-=
>handler->typename, "IO-APIC-level") )=0A-        return ioapic_ack_new ? =
ACKTYPE_EOI : ACKTYPE_UNMASK;=0A+        return desc->handler->ack =3D=3D =
irq_complete_move ?=0A+               ACKTYPE_EOI : ACKTYPE_UNMASK;=0A =0A =
    /* Legacy PIC interrupts can be acknowledged from any CPU. */=0A     =
if ( !strcmp(desc->handler->typename, "XT-PIC") )=0A
--=__PartFCCDF8E8.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

--=__PartFCCDF8E8.0__=--


From xen-devel-bounces@lists.xen.org Wed Sep 19 07:53:25 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Sep 2012 07: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 1TEF5b-0003Ol-Ih; Wed, 19 Sep 2012 07:52:55 +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 1TEF5Z-0003Og-Jy
	for xen-devel@lists.xensource.com; Wed, 19 Sep 2012 07:52:53 +0000
Received: from [85.158.143.35:35091] by server-1.bemta-4.messagelabs.com id
	2A/F5-05684-4D979505; Wed, 19 Sep 2012 07:52:52 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1348041170!7165957!1
X-Originating-IP: [134.134.136.24]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjQgPT4gMzQ0MTQ0\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31881 invoked from network); 19 Sep 2012 07:52:51 -0000
Received: from mga09.intel.com (HELO mga09.intel.com) (134.134.136.24)
	by server-4.tower-21.messagelabs.com with SMTP;
	19 Sep 2012 07:52:51 -0000
Received: from orsmga001.jf.intel.com ([10.7.209.18])
	by orsmga102.jf.intel.com with ESMTP; 19 Sep 2012 00:52:38 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.80,447,1344236400"; d="scan'208";a="194730916"
Received: from fmsmsx104.amr.corp.intel.com ([10.19.9.35])
	by orsmga001.jf.intel.com with ESMTP; 19 Sep 2012 00:52:48 -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; Wed, 19 Sep 2012 00:52:40 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.239]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.175]) with mapi id
	14.01.0355.002; Wed, 19 Sep 2012 15:52:20 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: Christoph Egger <Christoph.Egger@amd.com>
Thread-Topic: [Xen-devel] [PATCH 4/5] Xen/MCE: Abort live migration when
	vMCE occur
Thread-Index: AQHNlbKC34qTTCYqWE+tSrLDocix8peRS7fw
Date: Wed, 19 Sep 2012 07:52:19 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC82923353304F4@SHSMSX101.ccr.corp.intel.com>
References: <DE8DF0795D48FD4CA783C40EC829233532F43A@SHSMSX101.ccr.corp.intel.com>
	<50589370.8050605@amd.com>
In-Reply-To: <50589370.8050605@amd.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"keir@xen.org" <keir@xen.org>,
	"Ian.Campbell@citrix.com" <Ian.Campbell@citrix.com>,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH 4/5] Xen/MCE: Abort live migration when vMCE
 occur
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hmm, it conflict with c/s 25919.
I have rebased again, will send out later, thanks for remind!

Regards,
Jinsong

Christoph Egger wrote:
> Does this patch still apply after c/s 25919:62de66cec48a?
> 
> Christoph
> 
> 
> On 09/18/12 15:16, Liu, Jinsong wrote:
> 
>> Xen/MCE: Abort live migration when vMCE occur
>> 
>> This patch monitor the critical area of live migration (from vMCE
>> point of view, 
>> the copypages stage of migration is the critical area while other
>> areas are not). 
>> 
>> If a vMCE occur at the critical area of live migration, abort and
>> try migration later. 
>> 
>> Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>
>> 
>> diff -r f843ac6f93c9 tools/libxc/xc_domain.c
>> --- a/tools/libxc/xc_domain.c	Wed Sep 19 01:21:18 2012 +0800
>> +++ b/tools/libxc/xc_domain.c	Wed Sep 19 03:31:30 2012 +0800 @@
>>      -283,6 +283,37 @@ return ret;
>>  }
>> 
>> +/* Start vmce monitor */
>> +int xc_domain_vmce_monitor_strat(xc_interface *xch,
>> +                                 uint32_t domid)
>> +{
>> +    int ret;
>> +    DECLARE_DOMCTL;
>> +
>> +    domctl.cmd = XEN_DOMCTL_vmce_monitor_start;
>> +    domctl.domain = (domid_t)domid;
>> +    ret = do_domctl(xch, &domctl);
>> +
>> +    return ret ? -1 : 0;
>> +}
>> +
>> +/* End vmce monitor */
>> +int xc_domain_vmce_monitor_end(xc_interface *xch,
>> +                               uint32_t domid,
>> +                               signed char *vmce_while_monitor) +{
>> +    int ret;
>> +    DECLARE_DOMCTL;
>> +
>> +    domctl.cmd = XEN_DOMCTL_vmce_monitor_end;
>> +    domctl.domain = (domid_t)domid;
>> +    ret = do_domctl(xch, &domctl);
>> +    if ( !ret )
>> +        *vmce_while_monitor =
>> domctl.u.vmce_monitor.vmce_while_monitor; + +    return ret ? -1 : 0;
>> +}
>> +
>>  /* get info from hvm guest for save */
>>  int xc_domain_hvm_getcontext(xc_interface *xch,
>>                               uint32_t domid,
>> diff -r f843ac6f93c9 tools/libxc/xc_domain_save.c
>> --- a/tools/libxc/xc_domain_save.c	Wed Sep 19 01:21:18 2012 +0800
>> +++ b/tools/libxc/xc_domain_save.c	Wed Sep 19 03:31:30 2012 +0800 @@
>>       -895,6 +895,8 @@ */
>>      int compressing = 0;
>> 
>> +    signed char vmce_while_monitor = 0;
>> +
>>      int completed = 0;
>> 
>>      if ( hvm && !callbacks->switch_qemu_logdirty ) @@ -1109,6
>>          +1111,12 @@ goto out;
>>      }
>> 
>> +    if ( xc_domain_vmce_monitor_strat(xch, dom) )
>> +    {
>> +        PERROR("Error when start vmce monitor\n"); +        goto
>> out; +    }
>> +
>>    copypages:
>>  #define wrexact(fd, buf, len) write_buffer(xch, last_iter, ob,
>>  (fd), (buf), (len)) #define wruncached(fd, live, buf, len)
>> write_uncached(xch, last_iter, ob, (fd), (buf), (len)) @@ -1571,6
>> +1579,17 @@  
>> 
>>      DPRINTF("All memory is saved\n");
>> 
>> +    if ( xc_domain_vmce_monitor_end(xch, dom, &vmce_while_monitor)
>> ) +    { +        PERROR("Error when end vmce monitor\n");
>> +        goto out;
>> +    }
>> +    else if ( vmce_while_monitor == -1 )
>> +    {
>> +        fprintf(stderr, "vMCE occurred, abort this time and try
>> later.\n"); +        goto out; +    }
>> +
>>      /* After last_iter, buffer the rest of pagebuf & tailbuf data
>>       into a * separate output buffer and flush it after the
>> compressed page chunks.       */ 
>> diff -r f843ac6f93c9 tools/libxc/xenctrl.h
>> --- a/tools/libxc/xenctrl.h	Wed Sep 19 01:21:18 2012 +0800
>> +++ b/tools/libxc/xenctrl.h	Wed Sep 19 03:31:30 2012 +0800 @@ -571,6
>>                            +571,26 @@ xc_domaininfo_t *info);
>> 
>>  /**
>> + * This function start monitor vmce event.
>> + * @parm xch a handle to an open hypervisor interface
>> + * @parm domid the domain id monitored
>> + * @return 0 on success, -1 on failure
>> + */
>> +int xc_domain_vmce_monitor_strat(xc_interface *xch,
>> +                                 uint32_t domid);
>> +
>> +/**
>> + * This function end monitor vmce event
>> + * @parm xch a handle to an open hypervisor interface
>> + * @parm domid the domain id monitored
>> + * @parm vmce_while_migrate a pointer return whether vMCE occur
>> when migrate + * @return 0 on success, -1 on failure
>> + */
>> +int xc_domain_vmce_monitor_end(xc_interface *xch,
>> +                               uint32_t domid,
>> +                               signed char *vmce_while_monitor); +
>> +/**
>>   * This function returns information about the context of a hvm
>> domain 
>>   * @parm xch a handle to an open hypervisor interface
>>   * @parm domid the domain to get information from
>> diff -r f843ac6f93c9 xen/arch/x86/cpu/mcheck/mce_intel.c
>> --- a/xen/arch/x86/cpu/mcheck/mce_intel.c	Wed Sep 19 01:21:18 2012
>> +0800 +++ b/xen/arch/x86/cpu/mcheck/mce_intel.c	Wed Sep 19 03:31:30
>>                      2012 +0800 @@ -596,6 +596,12 @@ goto
>>                  vmce_failed; }
>> 
>> +                if ( unlikely(d->arch.vmce_monitor) ) +            
>> { +                    /* vMCE occur when guest migration */
>> +                    d->arch.vmce_monitor = -1;
>> +                }
>> +
>>                  /* We will inject vMCE to DOMU*/
>>                  if ( inject_vmce(d) < 0 )
>>                  {
>> diff -r f843ac6f93c9 xen/arch/x86/domctl.c
>> --- a/xen/arch/x86/domctl.c	Wed Sep 19 01:21:18 2012 +0800
>> +++ b/xen/arch/x86/domctl.c	Wed Sep 19 03:31:30 2012 +0800 @@
>>      -1514,6 +1514,40 @@ }
>>      break;
>> 
>> +    case XEN_DOMCTL_vmce_monitor_start:
>> +    {
>> +        struct domain *d;
>> +
>> +        d = rcu_lock_domain_by_id(domctl->domain); +        if ( d
>> != NULL ) +        {
>> +            d->arch.vmce_monitor = 1;
>> +            rcu_unlock_domain(d);
>> +        }
>> +        else
>> +            ret = -ESRCH;
>> +    }
>> +    break;
>> +
>> +    case XEN_DOMCTL_vmce_monitor_end:
>> +    {
>> +        struct domain *d;
>> +
>> +        d = rcu_lock_domain_by_id(domctl->domain); +        if ( d
>> != NULL) +        {
>> +            domctl->u.vmce_monitor.vmce_while_monitor =
>> +                                      d->arch.vmce_monitor;
>> +            d->arch.vmce_monitor = 0;
>> +            rcu_unlock_domain(d);
>> +            if ( copy_to_guest(u_domctl, domctl, 1) )
>> +                ret = -EFAULT;
>> +        }
>> +        else
>> +            ret = -ESRCH;
>> +    }
>> +    break;
>> +
>>      default:
>>          ret = iommu_do_domctl(domctl, u_domctl);
>>          break;
>> diff -r f843ac6f93c9 xen/include/asm-x86/domain.h
>> --- a/xen/include/asm-x86/domain.h	Wed Sep 19 01:21:18 2012 +0800
>> +++ b/xen/include/asm-x86/domain.h	Wed Sep 19 03:31:30 2012 +0800 @@
>>      -279,6 +279,11 @@ bool_t has_32bit_shinfo;
>>      /* Domain cannot handle spurious page faults? */
>>      bool_t suppress_spurious_page_faults;
>> +    /* Monitoring guest memory copy of migration
>> +     * = 0 - not monitoring
>> +     * > 0 - monitoring
>> +     * < 0 - vMCE occurred while monitoring */
>> +    s8 vmce_monitor;
>> 
>>      /* Continuable domain_relinquish_resources(). */      enum {
>> diff -r f843ac6f93c9 xen/include/public/domctl.h
>> --- a/xen/include/public/domctl.h	Wed Sep 19 01:21:18 2012 +0800
>> +++ b/xen/include/public/domctl.h	Wed Sep 19 03:31:30 2012 +0800 @@
>>  -828,6 +828,12 @@ typedef struct xen_domctl_set_access_required
>>  xen_domctl_set_access_required_t;
>> DEFINE_XEN_GUEST_HANDLE(xen_domctl_set_access_required_t); 
>> 
>> +struct xen_domctl_vmce_monitor {
>> +    signed char vmce_while_monitor;
>> +};
>> +typedef struct xen_domctl_vmce_monitor xen_domctl_vmce_monitor_t;
>> +DEFINE_XEN_GUEST_HANDLE(xen_domctl_vmce_monitor_t); +
>>  struct xen_domctl {
>>      uint32_t cmd;
>>  #define XEN_DOMCTL_createdomain                   1 @@ -893,6
>>  +899,8 @@ #define XEN_DOMCTL_set_access_required           64
>>  #define XEN_DOMCTL_audit_p2m                     65
>>  #define XEN_DOMCTL_set_virq_handler              66
>> +#define XEN_DOMCTL_vmce_monitor_start            67
>> +#define XEN_DOMCTL_vmce_monitor_end              68
>>  #define XEN_DOMCTL_gdbsx_guestmemio            1000
>>  #define XEN_DOMCTL_gdbsx_pausevcpu             1001
>>  #define XEN_DOMCTL_gdbsx_unpausevcpu           1002 @@ -947,6
>>          +955,7 @@ struct xen_domctl_set_access_required
>>          access_required; struct xen_domctl_audit_p2m        
>>          audit_p2m; struct xen_domctl_set_virq_handler 
>> set_virq_handler; +        struct xen_domctl_vmce_monitor     
>>          vmce_monitor; struct xen_domctl_gdbsx_memio      
>>          gdbsx_guest_memio; struct xen_domctl_gdbsx_pauseunp_vcpu
>>          gdbsx_pauseunp_vcpu; struct xen_domctl_gdbsx_domstatus  
>> gdbsx_domstatus; 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 19 07:53:25 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Sep 2012 07: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 1TEF5b-0003Ol-Ih; Wed, 19 Sep 2012 07:52:55 +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 1TEF5Z-0003Og-Jy
	for xen-devel@lists.xensource.com; Wed, 19 Sep 2012 07:52:53 +0000
Received: from [85.158.143.35:35091] by server-1.bemta-4.messagelabs.com id
	2A/F5-05684-4D979505; Wed, 19 Sep 2012 07:52:52 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1348041170!7165957!1
X-Originating-IP: [134.134.136.24]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjQgPT4gMzQ0MTQ0\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31881 invoked from network); 19 Sep 2012 07:52:51 -0000
Received: from mga09.intel.com (HELO mga09.intel.com) (134.134.136.24)
	by server-4.tower-21.messagelabs.com with SMTP;
	19 Sep 2012 07:52:51 -0000
Received: from orsmga001.jf.intel.com ([10.7.209.18])
	by orsmga102.jf.intel.com with ESMTP; 19 Sep 2012 00:52:38 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.80,447,1344236400"; d="scan'208";a="194730916"
Received: from fmsmsx104.amr.corp.intel.com ([10.19.9.35])
	by orsmga001.jf.intel.com with ESMTP; 19 Sep 2012 00:52:48 -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; Wed, 19 Sep 2012 00:52:40 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.239]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.175]) with mapi id
	14.01.0355.002; Wed, 19 Sep 2012 15:52:20 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: Christoph Egger <Christoph.Egger@amd.com>
Thread-Topic: [Xen-devel] [PATCH 4/5] Xen/MCE: Abort live migration when
	vMCE occur
Thread-Index: AQHNlbKC34qTTCYqWE+tSrLDocix8peRS7fw
Date: Wed, 19 Sep 2012 07:52:19 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC82923353304F4@SHSMSX101.ccr.corp.intel.com>
References: <DE8DF0795D48FD4CA783C40EC829233532F43A@SHSMSX101.ccr.corp.intel.com>
	<50589370.8050605@amd.com>
In-Reply-To: <50589370.8050605@amd.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"keir@xen.org" <keir@xen.org>,
	"Ian.Campbell@citrix.com" <Ian.Campbell@citrix.com>,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH 4/5] Xen/MCE: Abort live migration when vMCE
 occur
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hmm, it conflict with c/s 25919.
I have rebased again, will send out later, thanks for remind!

Regards,
Jinsong

Christoph Egger wrote:
> Does this patch still apply after c/s 25919:62de66cec48a?
> 
> Christoph
> 
> 
> On 09/18/12 15:16, Liu, Jinsong wrote:
> 
>> Xen/MCE: Abort live migration when vMCE occur
>> 
>> This patch monitor the critical area of live migration (from vMCE
>> point of view, 
>> the copypages stage of migration is the critical area while other
>> areas are not). 
>> 
>> If a vMCE occur at the critical area of live migration, abort and
>> try migration later. 
>> 
>> Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>
>> 
>> diff -r f843ac6f93c9 tools/libxc/xc_domain.c
>> --- a/tools/libxc/xc_domain.c	Wed Sep 19 01:21:18 2012 +0800
>> +++ b/tools/libxc/xc_domain.c	Wed Sep 19 03:31:30 2012 +0800 @@
>>      -283,6 +283,37 @@ return ret;
>>  }
>> 
>> +/* Start vmce monitor */
>> +int xc_domain_vmce_monitor_strat(xc_interface *xch,
>> +                                 uint32_t domid)
>> +{
>> +    int ret;
>> +    DECLARE_DOMCTL;
>> +
>> +    domctl.cmd = XEN_DOMCTL_vmce_monitor_start;
>> +    domctl.domain = (domid_t)domid;
>> +    ret = do_domctl(xch, &domctl);
>> +
>> +    return ret ? -1 : 0;
>> +}
>> +
>> +/* End vmce monitor */
>> +int xc_domain_vmce_monitor_end(xc_interface *xch,
>> +                               uint32_t domid,
>> +                               signed char *vmce_while_monitor) +{
>> +    int ret;
>> +    DECLARE_DOMCTL;
>> +
>> +    domctl.cmd = XEN_DOMCTL_vmce_monitor_end;
>> +    domctl.domain = (domid_t)domid;
>> +    ret = do_domctl(xch, &domctl);
>> +    if ( !ret )
>> +        *vmce_while_monitor =
>> domctl.u.vmce_monitor.vmce_while_monitor; + +    return ret ? -1 : 0;
>> +}
>> +
>>  /* get info from hvm guest for save */
>>  int xc_domain_hvm_getcontext(xc_interface *xch,
>>                               uint32_t domid,
>> diff -r f843ac6f93c9 tools/libxc/xc_domain_save.c
>> --- a/tools/libxc/xc_domain_save.c	Wed Sep 19 01:21:18 2012 +0800
>> +++ b/tools/libxc/xc_domain_save.c	Wed Sep 19 03:31:30 2012 +0800 @@
>>       -895,6 +895,8 @@ */
>>      int compressing = 0;
>> 
>> +    signed char vmce_while_monitor = 0;
>> +
>>      int completed = 0;
>> 
>>      if ( hvm && !callbacks->switch_qemu_logdirty ) @@ -1109,6
>>          +1111,12 @@ goto out;
>>      }
>> 
>> +    if ( xc_domain_vmce_monitor_strat(xch, dom) )
>> +    {
>> +        PERROR("Error when start vmce monitor\n"); +        goto
>> out; +    }
>> +
>>    copypages:
>>  #define wrexact(fd, buf, len) write_buffer(xch, last_iter, ob,
>>  (fd), (buf), (len)) #define wruncached(fd, live, buf, len)
>> write_uncached(xch, last_iter, ob, (fd), (buf), (len)) @@ -1571,6
>> +1579,17 @@  
>> 
>>      DPRINTF("All memory is saved\n");
>> 
>> +    if ( xc_domain_vmce_monitor_end(xch, dom, &vmce_while_monitor)
>> ) +    { +        PERROR("Error when end vmce monitor\n");
>> +        goto out;
>> +    }
>> +    else if ( vmce_while_monitor == -1 )
>> +    {
>> +        fprintf(stderr, "vMCE occurred, abort this time and try
>> later.\n"); +        goto out; +    }
>> +
>>      /* After last_iter, buffer the rest of pagebuf & tailbuf data
>>       into a * separate output buffer and flush it after the
>> compressed page chunks.       */ 
>> diff -r f843ac6f93c9 tools/libxc/xenctrl.h
>> --- a/tools/libxc/xenctrl.h	Wed Sep 19 01:21:18 2012 +0800
>> +++ b/tools/libxc/xenctrl.h	Wed Sep 19 03:31:30 2012 +0800 @@ -571,6
>>                            +571,26 @@ xc_domaininfo_t *info);
>> 
>>  /**
>> + * This function start monitor vmce event.
>> + * @parm xch a handle to an open hypervisor interface
>> + * @parm domid the domain id monitored
>> + * @return 0 on success, -1 on failure
>> + */
>> +int xc_domain_vmce_monitor_strat(xc_interface *xch,
>> +                                 uint32_t domid);
>> +
>> +/**
>> + * This function end monitor vmce event
>> + * @parm xch a handle to an open hypervisor interface
>> + * @parm domid the domain id monitored
>> + * @parm vmce_while_migrate a pointer return whether vMCE occur
>> when migrate + * @return 0 on success, -1 on failure
>> + */
>> +int xc_domain_vmce_monitor_end(xc_interface *xch,
>> +                               uint32_t domid,
>> +                               signed char *vmce_while_monitor); +
>> +/**
>>   * This function returns information about the context of a hvm
>> domain 
>>   * @parm xch a handle to an open hypervisor interface
>>   * @parm domid the domain to get information from
>> diff -r f843ac6f93c9 xen/arch/x86/cpu/mcheck/mce_intel.c
>> --- a/xen/arch/x86/cpu/mcheck/mce_intel.c	Wed Sep 19 01:21:18 2012
>> +0800 +++ b/xen/arch/x86/cpu/mcheck/mce_intel.c	Wed Sep 19 03:31:30
>>                      2012 +0800 @@ -596,6 +596,12 @@ goto
>>                  vmce_failed; }
>> 
>> +                if ( unlikely(d->arch.vmce_monitor) ) +            
>> { +                    /* vMCE occur when guest migration */
>> +                    d->arch.vmce_monitor = -1;
>> +                }
>> +
>>                  /* We will inject vMCE to DOMU*/
>>                  if ( inject_vmce(d) < 0 )
>>                  {
>> diff -r f843ac6f93c9 xen/arch/x86/domctl.c
>> --- a/xen/arch/x86/domctl.c	Wed Sep 19 01:21:18 2012 +0800
>> +++ b/xen/arch/x86/domctl.c	Wed Sep 19 03:31:30 2012 +0800 @@
>>      -1514,6 +1514,40 @@ }
>>      break;
>> 
>> +    case XEN_DOMCTL_vmce_monitor_start:
>> +    {
>> +        struct domain *d;
>> +
>> +        d = rcu_lock_domain_by_id(domctl->domain); +        if ( d
>> != NULL ) +        {
>> +            d->arch.vmce_monitor = 1;
>> +            rcu_unlock_domain(d);
>> +        }
>> +        else
>> +            ret = -ESRCH;
>> +    }
>> +    break;
>> +
>> +    case XEN_DOMCTL_vmce_monitor_end:
>> +    {
>> +        struct domain *d;
>> +
>> +        d = rcu_lock_domain_by_id(domctl->domain); +        if ( d
>> != NULL) +        {
>> +            domctl->u.vmce_monitor.vmce_while_monitor =
>> +                                      d->arch.vmce_monitor;
>> +            d->arch.vmce_monitor = 0;
>> +            rcu_unlock_domain(d);
>> +            if ( copy_to_guest(u_domctl, domctl, 1) )
>> +                ret = -EFAULT;
>> +        }
>> +        else
>> +            ret = -ESRCH;
>> +    }
>> +    break;
>> +
>>      default:
>>          ret = iommu_do_domctl(domctl, u_domctl);
>>          break;
>> diff -r f843ac6f93c9 xen/include/asm-x86/domain.h
>> --- a/xen/include/asm-x86/domain.h	Wed Sep 19 01:21:18 2012 +0800
>> +++ b/xen/include/asm-x86/domain.h	Wed Sep 19 03:31:30 2012 +0800 @@
>>      -279,6 +279,11 @@ bool_t has_32bit_shinfo;
>>      /* Domain cannot handle spurious page faults? */
>>      bool_t suppress_spurious_page_faults;
>> +    /* Monitoring guest memory copy of migration
>> +     * = 0 - not monitoring
>> +     * > 0 - monitoring
>> +     * < 0 - vMCE occurred while monitoring */
>> +    s8 vmce_monitor;
>> 
>>      /* Continuable domain_relinquish_resources(). */      enum {
>> diff -r f843ac6f93c9 xen/include/public/domctl.h
>> --- a/xen/include/public/domctl.h	Wed Sep 19 01:21:18 2012 +0800
>> +++ b/xen/include/public/domctl.h	Wed Sep 19 03:31:30 2012 +0800 @@
>>  -828,6 +828,12 @@ typedef struct xen_domctl_set_access_required
>>  xen_domctl_set_access_required_t;
>> DEFINE_XEN_GUEST_HANDLE(xen_domctl_set_access_required_t); 
>> 
>> +struct xen_domctl_vmce_monitor {
>> +    signed char vmce_while_monitor;
>> +};
>> +typedef struct xen_domctl_vmce_monitor xen_domctl_vmce_monitor_t;
>> +DEFINE_XEN_GUEST_HANDLE(xen_domctl_vmce_monitor_t); +
>>  struct xen_domctl {
>>      uint32_t cmd;
>>  #define XEN_DOMCTL_createdomain                   1 @@ -893,6
>>  +899,8 @@ #define XEN_DOMCTL_set_access_required           64
>>  #define XEN_DOMCTL_audit_p2m                     65
>>  #define XEN_DOMCTL_set_virq_handler              66
>> +#define XEN_DOMCTL_vmce_monitor_start            67
>> +#define XEN_DOMCTL_vmce_monitor_end              68
>>  #define XEN_DOMCTL_gdbsx_guestmemio            1000
>>  #define XEN_DOMCTL_gdbsx_pausevcpu             1001
>>  #define XEN_DOMCTL_gdbsx_unpausevcpu           1002 @@ -947,6
>>          +955,7 @@ struct xen_domctl_set_access_required
>>          access_required; struct xen_domctl_audit_p2m        
>>          audit_p2m; struct xen_domctl_set_virq_handler 
>> set_virq_handler; +        struct xen_domctl_vmce_monitor     
>>          vmce_monitor; struct xen_domctl_gdbsx_memio      
>>          gdbsx_guest_memio; struct xen_domctl_gdbsx_pauseunp_vcpu
>>          gdbsx_pauseunp_vcpu; struct xen_domctl_gdbsx_domstatus  
>> gdbsx_domstatus; 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 19 07:56:44 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Sep 2012 07:56: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 1TEF8x-0003VH-6L; Wed, 19 Sep 2012 07:56: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 1TEF8v-0003V7-97
	for xen-devel@lists.xen.org; Wed, 19 Sep 2012 07:56:21 +0000
Received: from [85.158.143.99:9269] by server-2.bemta-4.messagelabs.com id
	D9/49-06610-4AA79505; Wed, 19 Sep 2012 07:56:20 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1348041379!23912719!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-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22803 invoked from network); 19 Sep 2012 07:56:20 -0000
Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com)
	(74.125.83.45)
	by server-6.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Sep 2012 07:56:20 -0000
Received: by eeke53 with SMTP id e53so273761eek.32
	for <xen-devel@lists.xen.org>; Wed, 19 Sep 2012 00:56:19 -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=6+wQ0YMdXCdF3h+3yjJUrxpojA6TE2CR0XrTXKBWWas=;
	b=x00fQQLeRuPgPCAqj40YDLs+IGh4ISC32L5p/1yIP9GpsAoq2XjKfjo6IM2sTv7rfk
	6P/7ceiGpDzaxMCXfqrI6otFCdSPw158bTpRtlp0nv9EmNsWJAOOQ0Sj/uh4liKK+TLJ
	rJphA/TN3Ae9iP/66cVuFRCCAMoZaic3Fcab7qRv64mfEzFxe/05z/ZvtPGTsPz/gBSc
	MapKJ1J6fXRCqzeipmlQ4g8oGL7c9jUOqb9o0afquslH2UC+zn88TwzAku0XrSXvha71
	U6fgNGKjzroOoUCQwZATZQHbdrqwSn7mrHMCAs39VWRxzBWvR3aEuG8Z83Okl4I0OGKJ
	+/dw==
Received: by 10.14.178.6 with SMTP id e6mr2065337eem.36.1348041379820;
	Wed, 19 Sep 2012 00:56:19 -0700 (PDT)
Received: from [192.168.1.69] (host86-167-82-156.range86-167.btcentralplus.com.
	[86.167.82.156])
	by mx.google.com with ESMTPS id v3sm4988236eep.10.2012.09.19.00.56.18
	(version=SSLv3 cipher=OTHER); Wed, 19 Sep 2012 00:56:19 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Wed, 19 Sep 2012 08:56:15 +0100
From: Keir Fraser <keir.xen@gmail.com>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <CC7F392F.3F20D%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [PATCH] ACPI: move tables.c fully into .init.*
Thread-Index: Ac2WPD48jV6epEipakycicp/W9WBHw==
In-Reply-To: <5059905E020000780009C394@nat28.tlf.novell.com>
Mime-version: 1.0
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] ACPI: move tables.c fully into .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 19/09/2012 08:29, "Jan Beulich" <JBeulich@suse.com> wrote:

>>>> On 18.09.12 at 17:42, Keir Fraser <keir.xen@gmail.com> wrote:
>> On 18/09/2012 16:26, "Jan Beulich" <JBeulich@suse.com> wrote:
>> 
>>> The only non-init item was the space reserved for the initial tables,
>>> but we can as well dynamically allocate that array.
>>> 
>>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
>> 
>> Really worthwhile, versus having to round up the initial_tables[] allocation
>> to a whole number of pages?
> 
> It was exactly one page in size already.

Well, still I'm not sure about the style of converting static data to heap
data, just to be able to mark a whole unit init-only. If everything else is
already  marked init inside that file already, is there a win?

 -- 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 Sep 19 07:56:44 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Sep 2012 07:56: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 1TEF8x-0003VH-6L; Wed, 19 Sep 2012 07:56: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 1TEF8v-0003V7-97
	for xen-devel@lists.xen.org; Wed, 19 Sep 2012 07:56:21 +0000
Received: from [85.158.143.99:9269] by server-2.bemta-4.messagelabs.com id
	D9/49-06610-4AA79505; Wed, 19 Sep 2012 07:56:20 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1348041379!23912719!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-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22803 invoked from network); 19 Sep 2012 07:56:20 -0000
Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com)
	(74.125.83.45)
	by server-6.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Sep 2012 07:56:20 -0000
Received: by eeke53 with SMTP id e53so273761eek.32
	for <xen-devel@lists.xen.org>; Wed, 19 Sep 2012 00:56:19 -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=6+wQ0YMdXCdF3h+3yjJUrxpojA6TE2CR0XrTXKBWWas=;
	b=x00fQQLeRuPgPCAqj40YDLs+IGh4ISC32L5p/1yIP9GpsAoq2XjKfjo6IM2sTv7rfk
	6P/7ceiGpDzaxMCXfqrI6otFCdSPw158bTpRtlp0nv9EmNsWJAOOQ0Sj/uh4liKK+TLJ
	rJphA/TN3Ae9iP/66cVuFRCCAMoZaic3Fcab7qRv64mfEzFxe/05z/ZvtPGTsPz/gBSc
	MapKJ1J6fXRCqzeipmlQ4g8oGL7c9jUOqb9o0afquslH2UC+zn88TwzAku0XrSXvha71
	U6fgNGKjzroOoUCQwZATZQHbdrqwSn7mrHMCAs39VWRxzBWvR3aEuG8Z83Okl4I0OGKJ
	+/dw==
Received: by 10.14.178.6 with SMTP id e6mr2065337eem.36.1348041379820;
	Wed, 19 Sep 2012 00:56:19 -0700 (PDT)
Received: from [192.168.1.69] (host86-167-82-156.range86-167.btcentralplus.com.
	[86.167.82.156])
	by mx.google.com with ESMTPS id v3sm4988236eep.10.2012.09.19.00.56.18
	(version=SSLv3 cipher=OTHER); Wed, 19 Sep 2012 00:56:19 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Wed, 19 Sep 2012 08:56:15 +0100
From: Keir Fraser <keir.xen@gmail.com>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <CC7F392F.3F20D%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [PATCH] ACPI: move tables.c fully into .init.*
Thread-Index: Ac2WPD48jV6epEipakycicp/W9WBHw==
In-Reply-To: <5059905E020000780009C394@nat28.tlf.novell.com>
Mime-version: 1.0
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] ACPI: move tables.c fully into .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 19/09/2012 08:29, "Jan Beulich" <JBeulich@suse.com> wrote:

>>>> On 18.09.12 at 17:42, Keir Fraser <keir.xen@gmail.com> wrote:
>> On 18/09/2012 16:26, "Jan Beulich" <JBeulich@suse.com> wrote:
>> 
>>> The only non-init item was the space reserved for the initial tables,
>>> but we can as well dynamically allocate that array.
>>> 
>>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
>> 
>> Really worthwhile, versus having to round up the initial_tables[] allocation
>> to a whole number of pages?
> 
> It was exactly one page in size already.

Well, still I'm not sure about the style of converting static data to heap
data, just to be able to mark a whole unit init-only. If everything else is
already  marked init inside that file already, is there a win?

 -- 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 Sep 19 07:56:55 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Sep 2012 07:56: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 1TEF9A-0003Wp-Ox; Wed, 19 Sep 2012 07:56:36 +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 1TEF99-0003Wb-Kg
	for xen-devel@lists.xensource.com; Wed, 19 Sep 2012 07:56:35 +0000
Received: from [85.158.143.35:51330] by server-2.bemta-4.messagelabs.com id
	C6/99-06610-2BA79505; Wed, 19 Sep 2012 07:56:34 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1348041353!14218373!1
X-Originating-IP: [134.134.136.24]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjQgPT4gMzQ0MTQ0\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5936 invoked from network); 19 Sep 2012 07:55:55 -0000
Received: from mga09.intel.com (HELO mga09.intel.com) (134.134.136.24)
	by server-15.tower-21.messagelabs.com with SMTP;
	19 Sep 2012 07:55:55 -0000
Received: from orsmga001.jf.intel.com ([10.7.209.18])
	by orsmga102.jf.intel.com with ESMTP; 19 Sep 2012 00:55:42 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.80,447,1344236400"; d="scan'208";a="194731714"
Received: from fmsmsx107.amr.corp.intel.com ([10.19.9.54])
	by orsmga001.jf.intel.com with ESMTP; 19 Sep 2012 00:55:53 -0700
Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by
	FMSMSX107.amr.corp.intel.com (10.19.9.54) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Wed, 19 Sep 2012 00:55:52 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.239]) by
	SHSMSX102.ccr.corp.intel.com ([169.254.2.92]) with mapi id
	14.01.0355.002; Wed, 19 Sep 2012 15:55:51 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: Jan Beulich <JBeulich@suse.com>, "xen-devel@lists.xensource.com"
	<xen-devel@lists.xensource.com>
Thread-Topic: [PATCH 0/5] Xen vMCE
Thread-Index: Ac2WPC9ty/3ixE1GQOeE+Wk7f2HUHw==
Date: Wed, 19 Sep 2012 07:55:50 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC8292335330514@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: Christoph Egger <Christoph.Egger@amd.com>, "keir@xen.org" <keir@xen.org>,
	"Ian.Campbell@citrix.com" <Ian.Campbell@citrix.com>
Subject: [Xen-devel] [PATCH 0/5] Xen vMCE
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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,

As the patches I sent yesterday conflict with c/s 25919 (checkin on Sep 17), I rebased my patches based on latest c/s 25925.

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 Sep 19 07:56:55 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Sep 2012 07:56: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 1TEF9A-0003Wp-Ox; Wed, 19 Sep 2012 07:56:36 +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 1TEF99-0003Wb-Kg
	for xen-devel@lists.xensource.com; Wed, 19 Sep 2012 07:56:35 +0000
Received: from [85.158.143.35:51330] by server-2.bemta-4.messagelabs.com id
	C6/99-06610-2BA79505; Wed, 19 Sep 2012 07:56:34 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1348041353!14218373!1
X-Originating-IP: [134.134.136.24]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjQgPT4gMzQ0MTQ0\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5936 invoked from network); 19 Sep 2012 07:55:55 -0000
Received: from mga09.intel.com (HELO mga09.intel.com) (134.134.136.24)
	by server-15.tower-21.messagelabs.com with SMTP;
	19 Sep 2012 07:55:55 -0000
Received: from orsmga001.jf.intel.com ([10.7.209.18])
	by orsmga102.jf.intel.com with ESMTP; 19 Sep 2012 00:55:42 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.80,447,1344236400"; d="scan'208";a="194731714"
Received: from fmsmsx107.amr.corp.intel.com ([10.19.9.54])
	by orsmga001.jf.intel.com with ESMTP; 19 Sep 2012 00:55:53 -0700
Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by
	FMSMSX107.amr.corp.intel.com (10.19.9.54) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Wed, 19 Sep 2012 00:55:52 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.239]) by
	SHSMSX102.ccr.corp.intel.com ([169.254.2.92]) with mapi id
	14.01.0355.002; Wed, 19 Sep 2012 15:55:51 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: Jan Beulich <JBeulich@suse.com>, "xen-devel@lists.xensource.com"
	<xen-devel@lists.xensource.com>
Thread-Topic: [PATCH 0/5] Xen vMCE
Thread-Index: Ac2WPC9ty/3ixE1GQOeE+Wk7f2HUHw==
Date: Wed, 19 Sep 2012 07:55:50 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC8292335330514@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: Christoph Egger <Christoph.Egger@amd.com>, "keir@xen.org" <keir@xen.org>,
	"Ian.Campbell@citrix.com" <Ian.Campbell@citrix.com>
Subject: [Xen-devel] [PATCH 0/5] Xen vMCE
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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,

As the patches I sent yesterday conflict with c/s 25919 (checkin on Sep 17), I rebased my patches based on latest c/s 25925.

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 Sep 19 07:58:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Sep 2012 07: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 1TEFAJ-0003gY-BY; Wed, 19 Sep 2012 07:57:47 +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 1TEFAH-0003gB-R4
	for xen-devel@lists.xen.org; Wed, 19 Sep 2012 07:57:46 +0000
Received: from [85.158.143.99:51966] by server-3.bemta-4.messagelabs.com id
	50/4B-10986-9FA79505; Wed, 19 Sep 2012 07:57:45 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1348041464!25640544!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-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29698 invoked from network); 19 Sep 2012 07:57:44 -0000
Received: from mail-ey0-f173.google.com (HELO mail-ey0-f173.google.com)
	(209.85.215.173)
	by server-4.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Sep 2012 07:57:44 -0000
Received: by eaac13 with SMTP id c13so214518eaa.32
	for <xen-devel@lists.xen.org>; Wed, 19 Sep 2012 00:57:44 -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=YJFSeCp43LTvlbxCvYSkElBQMZmrAJEAXwTRthgV6kE=;
	b=KYuJDkFNDHWZcRiTp0UzrJ3D6Q06wb+iJsAeK2pErAlUmpazf3ZCnD/5kXsp/c8nxU
	iLWpZ6ksAiMfe0kA+7lTKmIVvWzWogjeDahbfIMPyIGJpV40HcW1s0L0c4QDCxixDVLV
	x6Mwk1Hx50gZHRikMWMKl5vq/wpwlxIAJuNxwY5RoZKA5zGCzPCFUra5K7GAM73CPU5X
	SETwBAq9HmsEiWIJa9zJlv98DypdU7V4/X7sKy6uyJD3BPQedIp95lFXAvxG9VXv54VR
	EvAQgNDrXyBx24hy0sC4kdqI/YKI5IKBP5BBAUtS13toyWM0zBRkwz+TwT4D/8nDTVze
	XxUQ==
Received: by 10.14.179.136 with SMTP id h8mr2681074eem.6.1348041464257;
	Wed, 19 Sep 2012 00:57:44 -0700 (PDT)
Received: from [192.168.1.69] (host86-167-82-156.range86-167.btcentralplus.com.
	[86.167.82.156])
	by mx.google.com with ESMTPS id 9sm4973664eei.12.2012.09.19.00.57.42
	(version=SSLv3 cipher=OTHER); Wed, 19 Sep 2012 00:57:43 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Wed, 19 Sep 2012 08:57:41 +0100
From: Keir Fraser <keir.xen@gmail.com>
To: Jan Beulich <JBeulich@suse.com>,
	xen-devel <xen-devel@lists.xen.org>
Message-ID: <CC7F3985.3F20F%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [PATCH] x86/IO-APIC: streamline level ack/end
	handling
Thread-Index: Ac2WPHF/SWijGwcUlUyz89f8iP9BWA==
In-Reply-To: <50599218020000780009C39A@nat28.tlf.novell.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] [PATCH] x86/IO-APIC: streamline level ack/end
 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 19/09/2012 08:36, "Jan Beulich" <JBeulich@suse.com> wrote:

> Rather than evaluating "ioapic_ack_new" on each invocation, and
> considering that the two methods really have almost no code in common,
> split the handlers.
> 
> While at it, also move ioapic_ack_{new,forced} into .init.data
> (eliminating the single non-__init reference to the former).
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Acked-by: Keir Fraser <keir@xen.org>

> --- a/xen/arch/x86/io_apic.c
> +++ b/xen/arch/x86/io_apic.c
> @@ -43,8 +43,8 @@ static struct { int pin, apic; } ioapic_
>  static DEFINE_SPINLOCK(ioapic_lock);
>  
>  bool_t __read_mostly skip_ioapic_setup;
> -bool_t __read_mostly ioapic_ack_new = 1;
> -bool_t __read_mostly ioapic_ack_forced = 0;
> +bool_t __initdata ioapic_ack_new = 1;
> +bool_t __initdata ioapic_ack_forced = 0;
>  
>  /*
>   * # of IRQ routing registers
> @@ -918,7 +918,7 @@ static inline int IO_APIC_irq_trigger(in
>      return 0;
>  }
>  
> -static hw_irq_controller ioapic_level_type;
> +static struct hw_interrupt_type ioapic_level_type;
>  static hw_irq_controller ioapic_edge_type;
>  
>  #define IOAPIC_AUTO -1
> @@ -1605,9 +1605,6 @@ static void mask_and_ack_level_ioapic_ir
>  
>      irq_complete_move(desc);
>  
> -    if ( ioapic_ack_new )
> -        return;
> -
>      if ( !directed_eoi_enabled )
>          mask_IO_APIC_irq(desc);
>  
> @@ -1651,34 +1648,29 @@ static void mask_and_ack_level_ioapic_ir
>      }
>  }
>  
> -static void end_level_ioapic_irq(struct irq_desc *desc, u8 vector)
> +static void end_level_ioapic_irq_old(struct irq_desc *desc, u8 vector)
>  {
> -    unsigned long v;
> -    int i;
> -
> -    if ( !ioapic_ack_new )
> +    if ( directed_eoi_enabled )
>      {
> -        if ( directed_eoi_enabled )
> +        if ( !(desc->status & (IRQ_DISABLED|IRQ_MOVE_PENDING)) )
>          {
> -            if ( !(desc->status & (IRQ_DISABLED|IRQ_MOVE_PENDING)) )
> -            {
> -                eoi_IO_APIC_irq(desc);
> -                return;
> -            }
> -
> -            mask_IO_APIC_irq(desc);
>              eoi_IO_APIC_irq(desc);
> -            if ( (desc->status & IRQ_MOVE_PENDING) &&
> -                 !io_apic_level_ack_pending(desc->irq) )
> -                move_masked_irq(desc);
> +            return;
>          }
>  
> -        if ( !(desc->status & IRQ_DISABLED) )
> -            unmask_IO_APIC_irq(desc);
> -
> -        return;
> +        mask_IO_APIC_irq(desc);
> +        eoi_IO_APIC_irq(desc);
> +        if ( (desc->status & IRQ_MOVE_PENDING) &&
> +             !io_apic_level_ack_pending(desc->irq) )
> +            move_masked_irq(desc);
>      }
>  
> +    if ( !(desc->status & IRQ_DISABLED) )
> +        unmask_IO_APIC_irq(desc);
> +}
> +
> +static void end_level_ioapic_irq_new(struct irq_desc *desc, u8 vector)
> +{
>  /*
>   * It appears there is an erratum which affects at least version 0x11
>   * of I/O APIC (that's the 82093AA and cores integrated into various
> @@ -1698,7 +1690,7 @@ static void end_level_ioapic_irq(struct
>   * operation to prevent an edge-triggered interrupt escaping meanwhile.
>   * The idea is from Manfred Spraul.  --macro
>   */
> -    i = desc->arch.vector;
> +    unsigned int v, i = desc->arch.vector;
>  
>      /* Manually EOI the old vector if we are moving to the new */
>      if ( vector && i != vector )
> @@ -1741,14 +1733,14 @@ static hw_irq_controller ioapic_edge_typ
>      .set_affinity  = set_ioapic_affinity_irq,
>  };
>  
> -static hw_irq_controller ioapic_level_type = {
> +static struct hw_interrupt_type __read_mostly ioapic_level_type = {
>      .typename  = "IO-APIC-level",
>      .startup  = startup_level_ioapic_irq,
>      .shutdown  = mask_IO_APIC_irq,
>      .enable  = unmask_IO_APIC_irq,
>      .disable  = mask_IO_APIC_irq,
>      .ack   = mask_and_ack_level_ioapic_irq,
> -    .end   = end_level_ioapic_irq,
> +    .end   = end_level_ioapic_irq_old,
>      .set_affinity  = set_ioapic_affinity_irq,
>  };
>  
> @@ -2006,6 +1998,11 @@ void __init setup_IO_APIC(void)
>      printk("ENABLING IO-APIC IRQs\n");
>      printk(" -> Using %s ACK method\n", ioapic_ack_new ? "new" : "old");
>  
> +    if (ioapic_ack_new) {
> +        ioapic_level_type.ack = irq_complete_move;
> +        ioapic_level_type.end = end_level_ioapic_irq_new;
> +    }
> +
>      /*
>       * Set up IO-APIC IRQ routing.
>       */
> --- a/xen/arch/x86/irq.c
> +++ b/xen/arch/x86/irq.c
> @@ -1495,7 +1495,8 @@ static int pirq_acktype(struct domain *d
>       * on which they were received. This is because we tickle the LAPIC to
> EOI.
>       */
>      if ( !strcmp(desc->handler->typename, "IO-APIC-level") )
> -        return ioapic_ack_new ? ACKTYPE_EOI : ACKTYPE_UNMASK;
> +        return desc->handler->ack == irq_complete_move ?
> +               ACKTYPE_EOI : ACKTYPE_UNMASK;
>  
>      /* Legacy PIC interrupts can be acknowledged from any CPU. */
>      if ( !strcmp(desc->handler->typename, "XT-PIC") )
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Sep 19 07:58:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Sep 2012 07: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 1TEFAJ-0003gY-BY; Wed, 19 Sep 2012 07:57:47 +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 1TEFAH-0003gB-R4
	for xen-devel@lists.xen.org; Wed, 19 Sep 2012 07:57:46 +0000
Received: from [85.158.143.99:51966] by server-3.bemta-4.messagelabs.com id
	50/4B-10986-9FA79505; Wed, 19 Sep 2012 07:57:45 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1348041464!25640544!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-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29698 invoked from network); 19 Sep 2012 07:57:44 -0000
Received: from mail-ey0-f173.google.com (HELO mail-ey0-f173.google.com)
	(209.85.215.173)
	by server-4.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Sep 2012 07:57:44 -0000
Received: by eaac13 with SMTP id c13so214518eaa.32
	for <xen-devel@lists.xen.org>; Wed, 19 Sep 2012 00:57:44 -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=YJFSeCp43LTvlbxCvYSkElBQMZmrAJEAXwTRthgV6kE=;
	b=KYuJDkFNDHWZcRiTp0UzrJ3D6Q06wb+iJsAeK2pErAlUmpazf3ZCnD/5kXsp/c8nxU
	iLWpZ6ksAiMfe0kA+7lTKmIVvWzWogjeDahbfIMPyIGJpV40HcW1s0L0c4QDCxixDVLV
	x6Mwk1Hx50gZHRikMWMKl5vq/wpwlxIAJuNxwY5RoZKA5zGCzPCFUra5K7GAM73CPU5X
	SETwBAq9HmsEiWIJa9zJlv98DypdU7V4/X7sKy6uyJD3BPQedIp95lFXAvxG9VXv54VR
	EvAQgNDrXyBx24hy0sC4kdqI/YKI5IKBP5BBAUtS13toyWM0zBRkwz+TwT4D/8nDTVze
	XxUQ==
Received: by 10.14.179.136 with SMTP id h8mr2681074eem.6.1348041464257;
	Wed, 19 Sep 2012 00:57:44 -0700 (PDT)
Received: from [192.168.1.69] (host86-167-82-156.range86-167.btcentralplus.com.
	[86.167.82.156])
	by mx.google.com with ESMTPS id 9sm4973664eei.12.2012.09.19.00.57.42
	(version=SSLv3 cipher=OTHER); Wed, 19 Sep 2012 00:57:43 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Wed, 19 Sep 2012 08:57:41 +0100
From: Keir Fraser <keir.xen@gmail.com>
To: Jan Beulich <JBeulich@suse.com>,
	xen-devel <xen-devel@lists.xen.org>
Message-ID: <CC7F3985.3F20F%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [PATCH] x86/IO-APIC: streamline level ack/end
	handling
Thread-Index: Ac2WPHF/SWijGwcUlUyz89f8iP9BWA==
In-Reply-To: <50599218020000780009C39A@nat28.tlf.novell.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] [PATCH] x86/IO-APIC: streamline level ack/end
 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 19/09/2012 08:36, "Jan Beulich" <JBeulich@suse.com> wrote:

> Rather than evaluating "ioapic_ack_new" on each invocation, and
> considering that the two methods really have almost no code in common,
> split the handlers.
> 
> While at it, also move ioapic_ack_{new,forced} into .init.data
> (eliminating the single non-__init reference to the former).
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Acked-by: Keir Fraser <keir@xen.org>

> --- a/xen/arch/x86/io_apic.c
> +++ b/xen/arch/x86/io_apic.c
> @@ -43,8 +43,8 @@ static struct { int pin, apic; } ioapic_
>  static DEFINE_SPINLOCK(ioapic_lock);
>  
>  bool_t __read_mostly skip_ioapic_setup;
> -bool_t __read_mostly ioapic_ack_new = 1;
> -bool_t __read_mostly ioapic_ack_forced = 0;
> +bool_t __initdata ioapic_ack_new = 1;
> +bool_t __initdata ioapic_ack_forced = 0;
>  
>  /*
>   * # of IRQ routing registers
> @@ -918,7 +918,7 @@ static inline int IO_APIC_irq_trigger(in
>      return 0;
>  }
>  
> -static hw_irq_controller ioapic_level_type;
> +static struct hw_interrupt_type ioapic_level_type;
>  static hw_irq_controller ioapic_edge_type;
>  
>  #define IOAPIC_AUTO -1
> @@ -1605,9 +1605,6 @@ static void mask_and_ack_level_ioapic_ir
>  
>      irq_complete_move(desc);
>  
> -    if ( ioapic_ack_new )
> -        return;
> -
>      if ( !directed_eoi_enabled )
>          mask_IO_APIC_irq(desc);
>  
> @@ -1651,34 +1648,29 @@ static void mask_and_ack_level_ioapic_ir
>      }
>  }
>  
> -static void end_level_ioapic_irq(struct irq_desc *desc, u8 vector)
> +static void end_level_ioapic_irq_old(struct irq_desc *desc, u8 vector)
>  {
> -    unsigned long v;
> -    int i;
> -
> -    if ( !ioapic_ack_new )
> +    if ( directed_eoi_enabled )
>      {
> -        if ( directed_eoi_enabled )
> +        if ( !(desc->status & (IRQ_DISABLED|IRQ_MOVE_PENDING)) )
>          {
> -            if ( !(desc->status & (IRQ_DISABLED|IRQ_MOVE_PENDING)) )
> -            {
> -                eoi_IO_APIC_irq(desc);
> -                return;
> -            }
> -
> -            mask_IO_APIC_irq(desc);
>              eoi_IO_APIC_irq(desc);
> -            if ( (desc->status & IRQ_MOVE_PENDING) &&
> -                 !io_apic_level_ack_pending(desc->irq) )
> -                move_masked_irq(desc);
> +            return;
>          }
>  
> -        if ( !(desc->status & IRQ_DISABLED) )
> -            unmask_IO_APIC_irq(desc);
> -
> -        return;
> +        mask_IO_APIC_irq(desc);
> +        eoi_IO_APIC_irq(desc);
> +        if ( (desc->status & IRQ_MOVE_PENDING) &&
> +             !io_apic_level_ack_pending(desc->irq) )
> +            move_masked_irq(desc);
>      }
>  
> +    if ( !(desc->status & IRQ_DISABLED) )
> +        unmask_IO_APIC_irq(desc);
> +}
> +
> +static void end_level_ioapic_irq_new(struct irq_desc *desc, u8 vector)
> +{
>  /*
>   * It appears there is an erratum which affects at least version 0x11
>   * of I/O APIC (that's the 82093AA and cores integrated into various
> @@ -1698,7 +1690,7 @@ static void end_level_ioapic_irq(struct
>   * operation to prevent an edge-triggered interrupt escaping meanwhile.
>   * The idea is from Manfred Spraul.  --macro
>   */
> -    i = desc->arch.vector;
> +    unsigned int v, i = desc->arch.vector;
>  
>      /* Manually EOI the old vector if we are moving to the new */
>      if ( vector && i != vector )
> @@ -1741,14 +1733,14 @@ static hw_irq_controller ioapic_edge_typ
>      .set_affinity  = set_ioapic_affinity_irq,
>  };
>  
> -static hw_irq_controller ioapic_level_type = {
> +static struct hw_interrupt_type __read_mostly ioapic_level_type = {
>      .typename  = "IO-APIC-level",
>      .startup  = startup_level_ioapic_irq,
>      .shutdown  = mask_IO_APIC_irq,
>      .enable  = unmask_IO_APIC_irq,
>      .disable  = mask_IO_APIC_irq,
>      .ack   = mask_and_ack_level_ioapic_irq,
> -    .end   = end_level_ioapic_irq,
> +    .end   = end_level_ioapic_irq_old,
>      .set_affinity  = set_ioapic_affinity_irq,
>  };
>  
> @@ -2006,6 +1998,11 @@ void __init setup_IO_APIC(void)
>      printk("ENABLING IO-APIC IRQs\n");
>      printk(" -> Using %s ACK method\n", ioapic_ack_new ? "new" : "old");
>  
> +    if (ioapic_ack_new) {
> +        ioapic_level_type.ack = irq_complete_move;
> +        ioapic_level_type.end = end_level_ioapic_irq_new;
> +    }
> +
>      /*
>       * Set up IO-APIC IRQ routing.
>       */
> --- a/xen/arch/x86/irq.c
> +++ b/xen/arch/x86/irq.c
> @@ -1495,7 +1495,8 @@ static int pirq_acktype(struct domain *d
>       * on which they were received. This is because we tickle the LAPIC to
> EOI.
>       */
>      if ( !strcmp(desc->handler->typename, "IO-APIC-level") )
> -        return ioapic_ack_new ? ACKTYPE_EOI : ACKTYPE_UNMASK;
> +        return desc->handler->ack == irq_complete_move ?
> +               ACKTYPE_EOI : ACKTYPE_UNMASK;
>  
>      /* Legacy PIC interrupts can be acknowledged from any CPU. */
>      if ( !strcmp(desc->handler->typename, "XT-PIC") )
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Sep 19 07:59:11 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Sep 2012 07: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 1TEFBT-0003pZ-RX; Wed, 19 Sep 2012 07:58:59 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jinsong.liu@intel.com>) id 1TEFBR-0003pJ-T3
	for xen-devel@lists.xensource.com; Wed, 19 Sep 2012 07:58:58 +0000
Received: from [85.158.138.51:6733] by server-5.bemta-3.messagelabs.com id
	8A/9A-13133-14B79505; Wed, 19 Sep 2012 07:58:57 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1348041530!23196587!1
X-Originating-IP: [143.182.124.21]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMjEgPT4gMjA0MzE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31179 invoked from network); 19 Sep 2012 07:58:51 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (143.182.124.21)
	by server-12.tower-174.messagelabs.com with SMTP;
	19 Sep 2012 07:58:51 -0000
Received: from azsmga001.ch.intel.com ([10.2.17.19])
	by azsmga101.ch.intel.com with ESMTP; 19 Sep 2012 00:58:49 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.80,447,1344236400"; d="scan'208";a="194426979"
Received: from fmsmsx105.amr.corp.intel.com ([10.19.9.36])
	by azsmga001.ch.intel.com with ESMTP; 19 Sep 2012 00:58:47 -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; Wed, 19 Sep 2012 00:58:46 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.239]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.175]) with mapi id
	14.01.0355.002; Wed, 19 Sep 2012 15:58:44 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: Jan Beulich <JBeulich@suse.com>, "xen-devel@lists.xensource.com"
	<xen-devel@lists.xensource.com>
Thread-Topic: [PATCH 1/5] Xen/MCE: vMCE emulation
Thread-Index: Ac2WPJa8f3GY9vZdQTCABNxgHB75SQ==
Date: Wed, 19 Sep 2012 07:58:43 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC8292335330546@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_DE8DF0795D48FD4CA783C40EC8292335330546SHSMSX101ccrcorpi_"
MIME-Version: 1.0
Cc: Christoph Egger <Christoph.Egger@amd.com>, "keir@xen.org" <keir@xen.org>,
	"Ian.Campbell@citrix.com" <Ian.Campbell@citrix.com>
Subject: [Xen-devel] [PATCH 1/5] Xen/MCE: vMCE emulation
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--_002_DE8DF0795D48FD4CA783C40EC8292335330546SHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Xen/MCE: vMCE emulation

This patch provides virtual MCE support to guest. It emulates a simple
and clean MCE MSRs interface to guest by faking caps to guest if needed
and masking caps if unnecessary:
1. Providing a well-defined MCG_CAP to guest, filter out un-necessary caps =
and provide only guest needed caps;
2. Disabling MCG_CTL to avoid model specific;
3. Sticking all 1's to MCi_CTL to guest to avoid model specific;
4. Enabling CMCI cap but never really inject to guest to prevent polling pe=
riodically;
5. Masking MSCOD field of MCi_STATUS to avoid model specific;
6. Keeping natural semantics by per-vcpu instead of per-domain variables;
7. Using bank1 and reserving bank0 to work around 'bank0 quirk' of some ver=
y old processors;
8. Cleaning some vMCE# injection logic which shared by Intel and AMD but us=
eless under new vMCE implement;
9. Keeping compatilbe w/ old xen version which has been backported to SLES1=
1 SP2, so that old vMCE would not blocked when migrate to new vMCE;

Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>

diff -r f76cd381459e xen/arch/x86/cpu/mcheck/mce.h
--- a/xen/arch/x86/cpu/mcheck/mce.h	Wed Sep 19 21:32:15 2012 +0800
+++ b/xen/arch/x86/cpu/mcheck/mce.h	Wed Sep 19 23:22:57 2012 +0800
@@ -169,15 +169,13 @@
 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
 static inline int mce_vendor_bank_msr(const struct vcpu *v, uint32_t msr)
 {
     switch (boot_cpu_data.x86_vendor) {
     case X86_VENDOR_INTEL:
         if (msr >=3D MSR_IA32_MC0_CTL2 &&
-            msr < MSR_IA32_MCx_CTL2(v->arch.mcg_cap & MCG_CAP_COUNT) )
+            msr < MSR_IA32_MCx_CTL2(v->arch.vmce.mcg_cap & MCG_CAP_COUNT) =
)
             return 1;
         break;
     case X86_VENDOR_AMD:
@@ -195,7 +193,7 @@
 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(v->arch.mcg_cap & MCG_CAP_COUNT)) ||
+         msr < MSR_IA32_MCx_CTL(v->arch.vmce.mcg_cap & MCG_CAP_COUNT)) ||
          mce_vendor_bank_msr(v, msr) )
         return 1;
     return 0;
diff -r f76cd381459e xen/arch/x86/cpu/mcheck/mce_intel.c
--- a/xen/arch/x86/cpu/mcheck/mce_intel.c	Wed Sep 19 21:32:15 2012 +0800
+++ b/xen/arch/x86/cpu/mcheck/mce_intel.c	Wed Sep 19 23:22:57 2012 +0800
@@ -982,14 +982,15 @@
 /* intel specific MCA MSR */
 int intel_mce_wrmsr(struct vcpu *v, uint32_t msr, uint64_t val)
 {
+    unsigned int bank =3D msr - MSR_IA32_MC0_CTL2;
     int ret =3D 0;
=20
-    if ( msr >=3D MSR_IA32_MC0_CTL2 &&
-         msr < MSR_IA32_MCx_CTL2(v->arch.mcg_cap & MCG_CAP_COUNT) )
+    if ( bank < GUEST_MC_BANK_NUM )
     {
-        mce_printk(MCE_QUIET, "We have disabled CMCI capability, "
-                 "Guest should not write this MSR!\n");
-         ret =3D 1;
+        v->arch.vmce.bank[bank].mci_ctl2 =3D val;
+        mce_printk(MCE_VERBOSE, "MCE: wr MC%u_CTL2 %"PRIx64"\n",
+                   bank, val);
+        ret =3D 1;
     }
=20
     return ret;
@@ -997,13 +998,14 @@
=20
 int intel_mce_rdmsr(const struct vcpu *v, uint32_t msr, uint64_t *val)
 {
+    unsigned int bank =3D msr - MSR_IA32_MC0_CTL2;
     int ret =3D 0;
=20
-    if ( msr >=3D MSR_IA32_MC0_CTL2 &&
-         msr < MSR_IA32_MCx_CTL2(v->arch.mcg_cap & MCG_CAP_COUNT) )
+    if ( bank < GUEST_MC_BANK_NUM )
     {
-        mce_printk(MCE_QUIET, "We have disabled CMCI capability, "
-                 "Guest should not read this MSR!\n");
+        *val =3D v->arch.vmce.bank[bank].mci_ctl2;
+        mce_printk(MCE_VERBOSE, "MCE: rdmsr MC%u_CTL2 0x%"PRIx64"\n",
+                   bank, *val);
         ret =3D 1;
     }
=20
diff -r f76cd381459e xen/arch/x86/cpu/mcheck/vmce.c
--- a/xen/arch/x86/cpu/mcheck/vmce.c	Wed Sep 19 21:32:15 2012 +0800
+++ b/xen/arch/x86/cpu/mcheck/vmce.c	Wed Sep 19 23:22:57 2012 +0800
@@ -1,5 +1,22 @@
 /*
- * vmce.c - virtual MCE support
+ * vmce.c - provide software emulated vMCE support to guest
+ *
+ * Copyright (C) 2010, 2011 Jiang, Yunhong <yunhong.jiang@intel.com>
+ * Copyright (C) 2012, 2013 Liu, Jinsong <jinsong.liu@intel.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * 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  U=
SA
  */
=20
 #include <xen/init.h>
@@ -19,67 +36,55 @@
 #include "mce.h"
 #include "x86_mca.h"
=20
-/*
- * Emulate 2 banks for guest
- * Bank0: reserved for 'bank0 quirk' occur at some very old processors:
- *   1). Intel cpu whose family-model value < 06-1A;
- *   2). AMD K7
- * Bank1: used to transfer error info to guest
- */
-#define GUEST_BANK_NUM 2
-#define GUEST_MCG_CAP (MCG_TES_P | MCG_SER_P | GUEST_BANK_NUM)
-
-#define dom_vmce(x)   ((x)->arch.vmca_msrs)
-
-int vmce_init_msr(struct domain *d)
-{
-    dom_vmce(d) =3D xmalloc(struct domain_mca_msrs);
-    if ( !dom_vmce(d) )
-        return -ENOMEM;
-
-    dom_vmce(d)->mcg_status =3D 0x0;
-    dom_vmce(d)->nr_injection =3D 0;
-
-    INIT_LIST_HEAD(&dom_vmce(d)->impact_header);
-    spin_lock_init(&dom_vmce(d)->lock);
-
-    return 0;
-}
-
-void vmce_destroy_msr(struct domain *d)
-{
-    if ( !dom_vmce(d) )
-        return;
-    xfree(dom_vmce(d));
-    dom_vmce(d) =3D NULL;
-}
-
 void vmce_init_vcpu(struct vcpu *v)
 {
-    v->arch.mcg_cap =3D GUEST_MCG_CAP;
+    int i;
+
+    /* global MCA MSRs init */
+    if ( boot_cpu_data.x86_vendor =3D=3D X86_VENDOR_INTEL )
+        v->arch.vmce.mcg_cap =3D INTEL_GUEST_MCG_CAP;
+    else
+        v->arch.vmce.mcg_cap =3D AMD_GUEST_MCG_CAP;
+
+    v->arch.vmce.mcg_status =3D 0;
+
+    /* per-bank MCA MSRs init */
+    for ( i =3D 0; i < GUEST_MC_BANK_NUM; i++ )
+        memset(&v->arch.vmce.bank[i], 0, sizeof(struct vmce_bank));
+
+    spin_lock_init(&v->arch.vmce.lock);
 }
=20
 int vmce_restore_vcpu(struct vcpu *v, uint64_t caps)
 {
-    if ( caps & ~GUEST_MCG_CAP & ~MCG_CAP_COUNT & ~MCG_CTL_P )
+    uint64_t guest_mcg_cap;
+
+    if ( boot_cpu_data.x86_vendor =3D=3D X86_VENDOR_INTEL )
+        guest_mcg_cap =3D INTEL_GUEST_MCG_CAP;
+    else
+        guest_mcg_cap =3D AMD_GUEST_MCG_CAP;
+
+    if ( caps & ~guest_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, GUEST_MCG_CAP & ~MCG_CAP_COUNT);
+                v->vcpu_id, guest_mcg_cap & ~MCG_CAP_COUNT);
         return -EPERM;
     }
=20
-    v->arch.mcg_cap =3D caps;
+    v->arch.vmce.mcg_cap =3D caps;
     return 0;
 }
=20
-static int bank_mce_rdmsr(const struct vcpu *v, uint32_t msr, uint64_t *va=
l)
+/*
+ * For historic version reason, bank number may greater than GUEST_MC_BANK=
_NUM,
+ * when migratie from old vMCE version to new vMCE.
+ */
+static int bank_mce_rdmsr(struct vcpu *v, uint32_t msr, uint64_t *val)
 {
     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
     *val =3D 0;
=20
@@ -92,46 +97,33 @@
                    bank, *val);
         break;
     case MSR_IA32_MC0_STATUS:
-        /* Only error bank is read. Non-error banks simply return. */
-        if ( !list_empty(&vmce->impact_header) )
+        if ( bank < GUEST_MC_BANK_NUM )
         {
-            entry =3D list_entry(vmce->impact_header.next,
-                               struct bank_entry, list);
-            if ( entry->bank =3D=3D bank )
-            {
-                *val =3D entry->mci_status;
+            *val =3D v->arch.vmce.bank[bank].mci_status;
+            if ( *val )
                 mce_printk(MCE_VERBOSE,
-                           "MCE: rd MC%u_STATUS in vMCE# context "
-                           "value 0x%"PRIx64"\n", bank, *val);
-            }
+                           "MCE: rdmsr MC%u_STATUS in vMCE# context "
+                           "0x%"PRIx64"\n", bank, *val);
         }
         break;
     case MSR_IA32_MC0_ADDR:
-        if ( !list_empty(&vmce->impact_header) )
+        if ( bank < GUEST_MC_BANK_NUM )
         {
-            entry =3D list_entry(vmce->impact_header.next,
-                               struct bank_entry, list);
-            if ( entry->bank =3D=3D bank )
-            {
-                *val =3D entry->mci_addr;
+            *val =3D v->arch.vmce.bank[bank].mci_addr;
+            if ( *val )
                 mce_printk(MCE_VERBOSE,
                            "MCE: rdmsr MC%u_ADDR in vMCE# context "
                            "0x%"PRIx64"\n", bank, *val);
-            }
         }
         break;
     case MSR_IA32_MC0_MISC:
-        if ( !list_empty(&vmce->impact_header) )
+        if ( bank < GUEST_MC_BANK_NUM )
         {
-            entry =3D list_entry(vmce->impact_header.next,
-                               struct bank_entry, list);
-            if ( entry->bank =3D=3D bank )
-            {
-                *val =3D entry->mci_misc;
+            *val =3D v->arch.vmce.bank[bank].mci_misc;
+            if ( *val )
                 mce_printk(MCE_VERBOSE,
-                           "MCE: rd MC%u_MISC in vMCE# context "
+                           "MCE: rdmsr MC%u_MISC in vMCE# context "
                            "0x%"PRIx64"\n", bank, *val);
-            }
         }
         break;
     default:
@@ -157,56 +149,50 @@
  */
 int vmce_rdmsr(uint32_t msr, uint64_t *val)
 {
-    const struct vcpu *cur =3D current;
-    struct domain_mca_msrs *vmce =3D dom_vmce(cur->domain);
+    struct vcpu *cur =3D current;
     int ret =3D 1;
=20
     *val =3D 0;
=20
-    spin_lock(&vmce->lock);
+    spin_lock(&cur->arch.vmce.lock);
=20
     switch ( msr )
     {
     case MSR_IA32_MCG_STATUS:
-        *val =3D vmce->mcg_status;
+        *val =3D cur->arch.vmce.mcg_status;
         if (*val)
             mce_printk(MCE_VERBOSE,
                        "MCE: rdmsr MCG_STATUS 0x%"PRIx64"\n", *val);
         break;
     case MSR_IA32_MCG_CAP:
-        *val =3D cur->arch.mcg_cap;
-        mce_printk(MCE_VERBOSE, "MCE: rdmsr MCG_CAP 0x%"PRIx64"\n",
-                   *val);
+        *val =3D cur->arch.vmce.mcg_cap;
+        mce_printk(MCE_VERBOSE, "MCE: rdmsr MCG_CAP 0x%"PRIx64"\n", *val);
         break;
     case MSR_IA32_MCG_CTL:
-        /* Stick all 1's when CTL support, and 0's when no CTL support */
-        if ( cur->arch.mcg_cap & MCG_CTL_P )
-            *val =3D ~0ULL;
-        mce_printk(MCE_VERBOSE, "MCE: rdmsr MCG_CTL 0x%"PRIx64"\n", *val);
+        if ( cur->arch.vmce.mcg_cap & MCG_CTL_P )
+        {
+            *val =3D ~0UL;
+            mce_printk(MCE_VERBOSE, "MCE: rdmsr MCG_CTL 0x%"PRIx64"\n", *v=
al);
+        }
         break;
     default:
         ret =3D mce_bank_msr(cur, msr) ? bank_mce_rdmsr(cur, msr, val) : 0=
;
         break;
     }
=20
-    spin_unlock(&vmce->lock);
+    spin_unlock(&cur->arch.vmce.lock);
+
     return ret;
 }
=20
+/*
+ * For historic version reason, bank number may greater than GUEST_MC_BANK=
_NUM,
+ * when migratie from old vMCE version to new vMCE.
+ */
 static int bank_mce_wrmsr(struct vcpu *v, u32 msr, u64 val)
 {
     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;
-
-    /* Give the first entry of the list, it corresponds to current
-     * vMCE# injection. When vMCE# is finished processing by the
-     * the guest, this node will be deleted.
-     * Only error bank is written. Non-error banks simply return.
-     */
-    if ( !list_empty(&vmce->impact_header) )
-        entry =3D list_entry(vmce->impact_header.next, struct bank_entry, =
list);
=20
     switch ( msr & (MSR_IA32_MC0_CTL | 3) )
     {
@@ -217,50 +203,46 @@
          */
         break;
     case MSR_IA32_MC0_STATUS:
-        if ( entry && (entry->bank =3D=3D bank) )
+        if ( val )
         {
-            entry->mci_status =3D val;
-            mce_printk(MCE_VERBOSE,
-                       "MCE: wr MC%u_STATUS %"PRIx64" in vMCE#\n",
+            mce_printk(MCE_QUIET,
+                       "MCE: wr MC%u_STATUS w/ non-zero cause #GP\n", bank=
);
+            ret =3D -1;
+        }
+        if ( bank < GUEST_MC_BANK_NUM )
+        {
+            v->arch.vmce.bank[bank].mci_status =3D val;
+            mce_printk(MCE_VERBOSE, "MCE: wr MC%u_STATUS %"PRIx64"\n",
                        bank, val);
         }
-        else
-            mce_printk(MCE_VERBOSE,
-                       "MCE: wr MC%u_STATUS %"PRIx64"\n", bank, val);
         break;
     case MSR_IA32_MC0_ADDR:
-        if ( !~val )
+        if ( val )
         {
             mce_printk(MCE_QUIET,
-                       "MCE: wr MC%u_ADDR with all 1s will cause #GP\n", b=
ank);
+                       "MCE: wr MC%u_ADDR w/ non-zero cause #GP\n", bank);
             ret =3D -1;
         }
-        else if ( entry && (entry->bank =3D=3D bank) )
+        else if ( bank < GUEST_MC_BANK_NUM )
         {
-            entry->mci_addr =3D val;
-            mce_printk(MCE_VERBOSE,
-                       "MCE: wr MC%u_ADDR %"PRIx64" in vMCE#\n", bank, val=
);
-        }
-        else
+            v->arch.vmce.bank[bank].mci_addr =3D val;
             mce_printk(MCE_VERBOSE,
                        "MCE: wr MC%u_ADDR %"PRIx64"\n", bank, val);
+        }
         break;
     case MSR_IA32_MC0_MISC:
-        if ( !~val )
+        if ( val )
         {
             mce_printk(MCE_QUIET,
-                       "MCE: wr MC%u_MISC with all 1s will cause #GP\n", b=
ank);
+                       "MCE: wr MC%u_MISC w/ non-zero cause #GP\n", bank);
             ret =3D -1;
         }
-        else if ( entry && (entry->bank =3D=3D bank) )
+        else if ( bank < GUEST_MC_BANK_NUM )
         {
-            entry->mci_misc =3D val;
-            mce_printk(MCE_VERBOSE,
-                       "MCE: wr MC%u_MISC %"PRIx64" in vMCE#\n", bank, val=
);
-        }
-        else
+            v->arch.vmce.bank[bank].mci_misc =3D val;
             mce_printk(MCE_VERBOSE,
                        "MCE: wr MC%u_MISC %"PRIx64"\n", bank, val);
+        }
         break;
     default:
         switch ( boot_cpu_data.x86_vendor )
@@ -286,52 +268,33 @@
 int vmce_wrmsr(u32 msr, u64 val)
 {
     struct vcpu *cur =3D current;
-    struct bank_entry *entry =3D NULL;
-    struct domain_mca_msrs *vmce =3D dom_vmce(cur->domain);
     int ret =3D 1;
=20
-    spin_lock(&vmce->lock);
+    spin_lock(&cur->arch.vmce.lock);
=20
     switch ( msr )
     {
     case MSR_IA32_MCG_CTL:
+        /* If MCG_CTL exist then stick to all 1's. If not exist then ignor=
e */
         break;
     case MSR_IA32_MCG_STATUS:
-        vmce->mcg_status =3D val;
+        cur->arch.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 ( is_hvm_vcpu(cur) && (vmce->nr_injection > 0) )
-        {
-            vmce->nr_injection--; /* Should be 0 */
-            if ( !list_empty(&vmce->impact_header) )
-            {
-                entry =3D list_entry(vmce->impact_header.next,
-                                   struct bank_entry, list);
-                if ( entry->mci_status & MCi_STATUS_VAL )
-                    mce_printk(MCE_QUIET, "MCE: MCi_STATUS MSR should have=
 "
-                               "been cleared before write MCG_STATUS MSR\n=
");
-
-                mce_printk(MCE_QUIET, "MCE: Delete HVM last injection "
-                           "Node, nr_injection %u\n",
-                           vmce->nr_injection);
-                list_del(&entry->list);
-                xfree(entry);
-            }
-            else
-                mce_printk(MCE_QUIET, "MCE: Not found HVM guest"
-                           " last injection Node, something Wrong!\n");
-        }
         break;
     case MSR_IA32_MCG_CAP:
-        mce_printk(MCE_QUIET, "MCE: MCG_CAP is read-only\n");
-        ret =3D -1;
+        /*
+         * According to Intel SDM, IA32_MCG_CAP is a read-only register,
+         * the effect of writing to the IA32_MCG_CAP is undefined. Here we
+         * treat writing as 'write not change'. Guest would not surprise.
+         */
+        mce_printk(MCE_QUIET, "MCE: MCG_CAP is read only and write not cha=
nge\n");
         break;
     default:
         ret =3D mce_bank_msr(cur, msr) ? bank_mce_wrmsr(cur, msr, val) : 0=
;
         break;
     }
=20
-    spin_unlock(&vmce->lock);
+    spin_unlock(&cur->arch.vmce.lock);
     return ret;
 }
=20
@@ -342,7 +305,7 @@
=20
     for_each_vcpu( d, v ) {
         struct hvm_vmce_vcpu ctxt =3D {
-            .caps =3D v->arch.mcg_cap
+            .caps =3D v->arch.vmce.mcg_cap
         };
=20
         err =3D hvm_save_entry(VMCE_VCPU, v->vcpu_id, h, &ctxt);
@@ -422,93 +385,38 @@
     return 0;
 }
=20
-/* 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
- * virtualization. When one vMCE# injection is finished processing
- * processed by guest, the corresponding node will be deleted.
- * This node list is for GUEST vMCE# MSRS virtualization.
- */
-static struct bank_entry* alloc_bank_entry(void)
+int fill_vmsr_data(struct mcinfo_bank *mc_bank, struct domain *d,
+                   uint64_t gstatus)
 {
-    struct bank_entry *entry;
+    struct vcpu *v =3D d->vcpu[0];
=20
-    entry =3D xzalloc(struct bank_entry);
-    if ( entry =3D=3D NULL )
-    {
-        printk(KERN_ERR "MCE: malloc bank_entry failed\n");
-        return NULL;
-    }
-
-    INIT_LIST_HEAD(&entry->list);
-    return entry;
-}
-
-/* Fill error bank info for #vMCE injection and GUEST vMCE#
- * MSR virtualization data
- * 1) Log down how many nr_injections of the impacted.
- * 2) Copy MCE# error bank to impacted DOM node list,
- *    for vMCE# MSRs virtualization
- */
-int fill_vmsr_data(struct mcinfo_bank *mc_bank, struct domain *d,
-                   uint64_t gstatus) {
-    struct bank_entry *entry;
-
-    /* This error bank impacts one domain, we need to fill domain related
-     * data for vMCE MSRs virtualization and vMCE# injection */
     if ( mc_bank->mc_domid !=3D (uint16_t)~0 )
     {
-        /* For HVM guest, Only when first vMCE is consumed by HVM guest
-         * successfully, will we generete another node and inject another =
vMCE.
-         */
-        if ( d->is_hvm && (dom_vmce(d)->nr_injection > 0) )
+        if ( v->arch.vmce.mcg_status & MCG_STATUS_MCIP )
         {
-            mce_printk(MCE_QUIET, "MCE: HVM guest has not handled previous=
"
+            mce_printk(MCE_QUIET, "MCE: guest has not handled previous"
                        " vMCE yet!\n");
             return -1;
         }
=20
-        entry =3D alloc_bank_entry();
-        if ( entry =3D=3D NULL )
-            return -1;
+        spin_lock(&v->arch.vmce.lock);
=20
-        entry->mci_status =3D mc_bank->mc_status;
-        entry->mci_addr =3D mc_bank->mc_addr;
-        entry->mci_misc =3D mc_bank->mc_misc;
-        entry->bank =3D mc_bank->mc_bank;
+        v->arch.vmce.mcg_status =3D gstatus;
+        /*
+         * 1. Skip bank 0 to avoid 'bank 0 quirk' of old processors
+         * 2. Filter MCi_STATUS MSCOD model specific error code to guest
+         */
+        v->arch.vmce.bank[1].mci_status =3D mc_bank->mc_status &
+                                              MCi_STATUS_MSCOD_MASK;
+        v->arch.vmce.bank[1].mci_addr =3D mc_bank->mc_addr;
+        v->arch.vmce.bank[1].mci_misc =3D mc_bank->mc_misc;
=20
-        spin_lock(&dom_vmce(d)->lock);
-        /* New error Node, insert to the tail of the per_dom data */
-        list_add_tail(&entry->list, &dom_vmce(d)->impact_header);
-        /* Fill MSR global status */
-        dom_vmce(d)->mcg_status =3D gstatus;
-        /* New node impact the domain, need another vMCE# injection*/
-        dom_vmce(d)->nr_injection++;
-        spin_unlock(&dom_vmce(d)->lock);
-
-        mce_printk(MCE_VERBOSE,"MCE: Found error @[BANK%d "
-                   "status %"PRIx64" addr %"PRIx64" domid %d]\n ",
-                   mc_bank->mc_bank, mc_bank->mc_status, mc_bank->mc_addr,
-                   mc_bank->mc_domid);
+        spin_unlock(&v->arch.vmce.lock);
     }
=20
     return 0;
 }
=20
-#if 0 /* currently unused */
-int vmce_domain_inject(
-    struct mcinfo_bank *bank, struct domain *d, struct mcinfo_global *glob=
al)
-{
-    int ret;
-
-    ret =3D fill_vmsr_data(bank, d, global->mc_gstatus);
-    if ( ret < 0 )
-        return ret;
-
-    return inject_vmce(d);
-}
-#endif
-
 static int is_hvm_vmce_ready(struct mcinfo_bank *bank, struct domain *d)
 {
     struct vcpu *v;
diff -r f76cd381459e xen/arch/x86/domain.c
--- a/xen/arch/x86/domain.c	Wed Sep 19 21:32:15 2012 +0800
+++ b/xen/arch/x86/domain.c	Wed Sep 19 23:22:57 2012 +0800
@@ -571,9 +571,6 @@
=20
         if ( (rc =3D iommu_domain_init(d)) !=3D 0 )
             goto fail;
-
-        /* For Guest vMCE MSRs virtualization */
-        vmce_init_msr(d);
     }
=20
     if ( is_hvm_domain(d) )
@@ -600,7 +597,6 @@
=20
  fail:
     d->is_dying =3D DOMDYING_dead;
-    vmce_destroy_msr(d);
     cleanup_domain_irq_mapping(d);
     free_xenheap_page(d->shared_info);
     if ( paging_initialised )
@@ -623,7 +619,6 @@
     else
         xfree(d->arch.pv_domain.e820);
=20
-    vmce_destroy_msr(d);
     free_domain_pirqs(d);
     if ( !is_idle_domain(d) )
         iommu_domain_destroy(d);
diff -r f76cd381459e xen/arch/x86/domctl.c
--- a/xen/arch/x86/domctl.c	Wed Sep 19 21:32:15 2012 +0800
+++ b/xen/arch/x86/domctl.c	Wed Sep 19 23:22:57 2012 +0800
@@ -1024,7 +1024,7 @@
                 evc->syscall32_callback_eip    =3D 0;
                 evc->syscall32_disables_events =3D 0;
             }
-            evc->mcg_cap =3D v->arch.mcg_cap;
+            evc->mcg_cap =3D v->arch.vmce.mcg_cap;
         }
         else
         {
diff -r f76cd381459e xen/arch/x86/traps.c
--- a/xen/arch/x86/traps.c	Wed Sep 19 21:32:15 2012 +0800
+++ b/xen/arch/x86/traps.c	Wed Sep 19 23:22:57 2012 +0800
@@ -3133,50 +3133,6 @@
                 break;
     ASSERT(trap <=3D VCPU_TRAP_LAST);
=20
-    /* inject vMCE to PV_Guest including DOM0. */
-    if ( trap =3D=3D VCPU_TRAP_MCE )
-    {
-        gdprintk(XENLOG_DEBUG, "MCE: Return from vMCE# trap!\n");
-        if ( curr->vcpu_id =3D=3D 0 )
-        {
-            struct domain *d =3D curr->domain;
-
-            if ( !d->arch.vmca_msrs->nr_injection )
-            {
-                printk(XENLOG_WARNING "MCE: ret from vMCE#, "
-                       "no injection node\n");
-                goto end;
-            }
-
-            d->arch.vmca_msrs->nr_injection--;
-            if ( !list_empty(&d->arch.vmca_msrs->impact_header) )
-            {
-                struct bank_entry *entry;
-
-                entry =3D list_entry(d->arch.vmca_msrs->impact_header.next=
,
-                                   struct bank_entry, list);
-                gdprintk(XENLOG_DEBUG, "MCE: delete last injection node\n"=
);
-                list_del(&entry->list);
-            }
-            else
-                printk(XENLOG_ERR "MCE: didn't found last injection node\n=
");
-
-            /* further injection */
-            if ( d->arch.vmca_msrs->nr_injection > 0 &&
-                 guest_has_trap_callback(d, 0, TRAP_machine_check) &&
-                 !test_and_set_bool(curr->mce_pending) )
-            {
-                int cpu =3D smp_processor_id();
-
-                cpumask_copy(curr->cpu_affinity_tmp, curr->cpu_affinity);
-                printk(XENLOG_DEBUG "MCE: CPU%d set affinity, old %d\n",
-                       cpu, curr->processor);
-                vcpu_set_affinity(curr, cpumask_of(cpu));
-            }
-        }
-    }
-
-end:
     /* Restore previous asynchronous exception mask. */
     curr->async_exception_mask =3D curr->async_exception_state(trap).old_m=
ask;
 }
diff -r f76cd381459e xen/include/asm-x86/domain.h
--- a/xen/include/asm-x86/domain.h	Wed Sep 19 21:32:15 2012 +0800
+++ b/xen/include/asm-x86/domain.h	Wed Sep 19 23:22:57 2012 +0800
@@ -296,9 +296,6 @@
=20
     struct PITState vpit;
=20
-    /* For Guest vMCA handling */
-    struct domain_mca_msrs *vmca_msrs;
-
     /* TSC management (emulation, pv, scaling, stats) */
     int tsc_mode;            /* see include/asm-x86/time.h */
     bool_t vtsc;             /* tsc is emulated (may change after migrate)=
 */
@@ -438,8 +435,8 @@
      * and thus should be saved/restored. */
     bool_t nonlazy_xstate_used;
=20
-    uint64_t mcg_cap;
-   =20
+    struct vmce vmce;
+
     struct paging_vcpu paging;
=20
     uint32_t gdbsx_vcpu_event;
diff -r f76cd381459e xen/include/asm-x86/mce.h
--- a/xen/include/asm-x86/mce.h	Wed Sep 19 21:32:15 2012 +0800
+++ b/xen/include/asm-x86/mce.h	Wed Sep 19 23:22:57 2012 +0800
@@ -3,28 +3,50 @@
 #ifndef _XEN_X86_MCE_H
 #define _XEN_X86_MCE_H
=20
-/* This entry is for recording bank nodes for the impacted domain,
- * put into impact_header list. */
-struct bank_entry {
-    struct list_head list;
-    uint16_t bank;
+/*
+ * Emulalte 2 banks for guest
+ * Bank0: reserved for 'bank0 quirk' occur at some very old processors:
+ *   1). Intel cpu whose family-model value < 06-1A;
+ *   2). AMD K7
+ * Bank1: used to transfer error info to guest
+ */
+#define GUEST_MC_BANK_NUM 2
+
+/*
+ * MCG_SER_P:  software error recovery supported
+ * MCG_TES_P:  to avoid MCi_status bit56:53 model specific
+ * MCG_CMCI_P: expose CMCI capability but never really inject it to guest,
+ *             for sake of performance since guest not polling periodicall=
y
+ */
+#define INTEL_GUEST_MCG_CAP (MCG_SER_P |	\
+                             MCG_TES_P |	\
+                             MCG_CMCI_P |	\
+                             GUEST_MC_BANK_NUM)
+
+#define AMD_GUEST_MCG_CAP (MCG_SER_P |		\
+                           GUEST_MC_BANK_NUM)
+
+/* Filter MSCOD model specific error code to guest */
+#define MCi_STATUS_MSCOD_MASK (~(0xffffULL << 16))
+
+/* No mci_ctl since it stick all 1's */
+struct vmce_bank {
     uint64_t mci_status;
     uint64_t mci_addr;
     uint64_t mci_misc;
+    uint64_t mci_ctl2;
 };
=20
-struct domain_mca_msrs
-{
-    /* Guest should not change below values after DOM boot up */
+/* No mcg_ctl since it not expose to guest */
+struct vmce {
+    uint64_t mcg_cap;
     uint64_t mcg_status;
-    uint16_t nr_injection;
-    struct list_head impact_header;
+    struct vmce_bank bank[GUEST_MC_BANK_NUM];
+
     spinlock_t lock;
 };
=20
 /* 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);=

--_002_DE8DF0795D48FD4CA783C40EC8292335330546SHSMSX101ccrcorpi_
Content-Type: application/octet-stream; name="1_vmce_emulation.patch"
Content-Description: 1_vmce_emulation.patch
Content-Disposition: attachment; filename="1_vmce_emulation.patch";
	size=27245; creation-date="Wed, 19 Sep 2012 07:39:51 GMT";
	modification-date="Wed, 19 Sep 2012 15:22:58 GMT"
Content-Transfer-Encoding: base64

WGVuL01DRTogdk1DRSBlbXVsYXRpb24KClRoaXMgcGF0Y2ggcHJvdmlkZXMgdmlydHVhbCBNQ0Ug
c3VwcG9ydCB0byBndWVzdC4gSXQgZW11bGF0ZXMgYSBzaW1wbGUKYW5kIGNsZWFuIE1DRSBNU1Jz
IGludGVyZmFjZSB0byBndWVzdCBieSBmYWtpbmcgY2FwcyB0byBndWVzdCBpZiBuZWVkZWQKYW5k
IG1hc2tpbmcgY2FwcyBpZiB1bm5lY2Vzc2FyeToKMS4gUHJvdmlkaW5nIGEgd2VsbC1kZWZpbmVk
IE1DR19DQVAgdG8gZ3Vlc3QsIGZpbHRlciBvdXQgdW4tbmVjZXNzYXJ5IGNhcHMgYW5kIHByb3Zp
ZGUgb25seSBndWVzdCBuZWVkZWQgY2FwczsKMi4gRGlzYWJsaW5nIE1DR19DVEwgdG8gYXZvaWQg
bW9kZWwgc3BlY2lmaWM7CjMuIFN0aWNraW5nIGFsbCAxJ3MgdG8gTUNpX0NUTCB0byBndWVzdCB0
byBhdm9pZCBtb2RlbCBzcGVjaWZpYzsKNC4gRW5hYmxpbmcgQ01DSSBjYXAgYnV0IG5ldmVyIHJl
YWxseSBpbmplY3QgdG8gZ3Vlc3QgdG8gcHJldmVudCBwb2xsaW5nIHBlcmlvZGljYWxseTsKNS4g
TWFza2luZyBNU0NPRCBmaWVsZCBvZiBNQ2lfU1RBVFVTIHRvIGF2b2lkIG1vZGVsIHNwZWNpZmlj
Owo2LiBLZWVwaW5nIG5hdHVyYWwgc2VtYW50aWNzIGJ5IHBlci12Y3B1IGluc3RlYWQgb2YgcGVy
LWRvbWFpbiB2YXJpYWJsZXM7CjcuIFVzaW5nIGJhbmsxIGFuZCByZXNlcnZpbmcgYmFuazAgdG8g
d29yayBhcm91bmQgJ2JhbmswIHF1aXJrJyBvZiBzb21lIHZlcnkgb2xkIHByb2Nlc3NvcnM7Cjgu
IENsZWFuaW5nIHNvbWUgdk1DRSMgaW5qZWN0aW9uIGxvZ2ljIHdoaWNoIHNoYXJlZCBieSBJbnRl
bCBhbmQgQU1EIGJ1dCB1c2VsZXNzIHVuZGVyIG5ldyB2TUNFIGltcGxlbWVudDsKOS4gS2VlcGlu
ZyBjb21wYXRpbGJlIHcvIG9sZCB4ZW4gdmVyc2lvbiB3aGljaCBoYXMgYmVlbiBiYWNrcG9ydGVk
IHRvIFNMRVMxMSBTUDIsIHNvIHRoYXQgb2xkIHZNQ0Ugd291bGQgbm90IGJsb2NrZWQgd2hlbiBt
aWdyYXRlIHRvIG5ldyB2TUNFOwoKU2lnbmVkLW9mZi1ieTogTGl1LCBKaW5zb25nIDxqaW5zb25n
LmxpdUBpbnRlbC5jb20+CgpkaWZmIC1yIGY3NmNkMzgxNDU5ZSB4ZW4vYXJjaC94ODYvY3B1L21j
aGVjay9tY2UuaAotLS0gYS94ZW4vYXJjaC94ODYvY3B1L21jaGVjay9tY2UuaAlXZWQgU2VwIDE5
IDIxOjMyOjE1IDIwMTIgKzA4MDAKKysrIGIveGVuL2FyY2gveDg2L2NwdS9tY2hlY2svbWNlLmgJ
V2VkIFNlcCAxOSAyMzoyMjo1NyAyMDEyICswODAwCkBAIC0xNjksMTUgKzE2OSwxMyBAQAogaW50
IGZpbGxfdm1zcl9kYXRhKHN0cnVjdCBtY2luZm9fYmFuayAqbWNfYmFuaywgc3RydWN0IGRvbWFp
biAqZCwKICAgICB1aW50NjRfdCBnc3RhdHVzKTsKIGludCBpbmplY3Rfdm1jZShzdHJ1Y3QgZG9t
YWluICpkKTsKLWludCB2bWNlX2RvbWFpbl9pbmplY3Qoc3RydWN0IG1jaW5mb19iYW5rICpiYW5r
LCBzdHJ1Y3QgZG9tYWluICpkLAotICAgIHN0cnVjdCBtY2luZm9fZ2xvYmFsICpnbG9iYWwpOwog
CiBzdGF0aWMgaW5saW5lIGludCBtY2VfdmVuZG9yX2JhbmtfbXNyKGNvbnN0IHN0cnVjdCB2Y3B1
ICp2LCB1aW50MzJfdCBtc3IpCiB7CiAgICAgc3dpdGNoIChib290X2NwdV9kYXRhLng4Nl92ZW5k
b3IpIHsKICAgICBjYXNlIFg4Nl9WRU5ET1JfSU5URUw6CiAgICAgICAgIGlmIChtc3IgPj0gTVNS
X0lBMzJfTUMwX0NUTDIgJiYKLSAgICAgICAgICAgIG1zciA8IE1TUl9JQTMyX01DeF9DVEwyKHYt
PmFyY2gubWNnX2NhcCAmIE1DR19DQVBfQ09VTlQpICkKKyAgICAgICAgICAgIG1zciA8IE1TUl9J
QTMyX01DeF9DVEwyKHYtPmFyY2gudm1jZS5tY2dfY2FwICYgTUNHX0NBUF9DT1VOVCkgKQogICAg
ICAgICAgICAgcmV0dXJuIDE7CiAgICAgICAgIGJyZWFrOwogICAgIGNhc2UgWDg2X1ZFTkRPUl9B
TUQ6CkBAIC0xOTUsNyArMTkzLDcgQEAKIHN0YXRpYyBpbmxpbmUgaW50IG1jZV9iYW5rX21zcihj
b25zdCBzdHJ1Y3QgdmNwdSAqdiwgdWludDMyX3QgbXNyKQogewogICAgIGlmICggKG1zciA+PSBN
U1JfSUEzMl9NQzBfQ1RMICYmCi0gICAgICAgICAgbXNyIDwgTVNSX0lBMzJfTUN4X0NUTCh2LT5h
cmNoLm1jZ19jYXAgJiBNQ0dfQ0FQX0NPVU5UKSkgfHwKKyAgICAgICAgIG1zciA8IE1TUl9JQTMy
X01DeF9DVEwodi0+YXJjaC52bWNlLm1jZ19jYXAgJiBNQ0dfQ0FQX0NPVU5UKSkgfHwKICAgICAg
ICAgIG1jZV92ZW5kb3JfYmFua19tc3IodiwgbXNyKSApCiAgICAgICAgIHJldHVybiAxOwogICAg
IHJldHVybiAwOwpkaWZmIC1yIGY3NmNkMzgxNDU5ZSB4ZW4vYXJjaC94ODYvY3B1L21jaGVjay9t
Y2VfaW50ZWwuYwotLS0gYS94ZW4vYXJjaC94ODYvY3B1L21jaGVjay9tY2VfaW50ZWwuYwlXZWQg
U2VwIDE5IDIxOjMyOjE1IDIwMTIgKzA4MDAKKysrIGIveGVuL2FyY2gveDg2L2NwdS9tY2hlY2sv
bWNlX2ludGVsLmMJV2VkIFNlcCAxOSAyMzoyMjo1NyAyMDEyICswODAwCkBAIC05ODIsMTQgKzk4
MiwxNSBAQAogLyogaW50ZWwgc3BlY2lmaWMgTUNBIE1TUiAqLwogaW50IGludGVsX21jZV93cm1z
cihzdHJ1Y3QgdmNwdSAqdiwgdWludDMyX3QgbXNyLCB1aW50NjRfdCB2YWwpCiB7CisgICAgdW5z
aWduZWQgaW50IGJhbmsgPSBtc3IgLSBNU1JfSUEzMl9NQzBfQ1RMMjsKICAgICBpbnQgcmV0ID0g
MDsKIAotICAgIGlmICggbXNyID49IE1TUl9JQTMyX01DMF9DVEwyICYmCi0gICAgICAgICBtc3Ig
PCBNU1JfSUEzMl9NQ3hfQ1RMMih2LT5hcmNoLm1jZ19jYXAgJiBNQ0dfQ0FQX0NPVU5UKSApCisg
ICAgaWYgKCBiYW5rIDwgR1VFU1RfTUNfQkFOS19OVU0gKQogICAgIHsKLSAgICAgICAgbWNlX3By
aW50ayhNQ0VfUVVJRVQsICJXZSBoYXZlIGRpc2FibGVkIENNQ0kgY2FwYWJpbGl0eSwgIgotICAg
ICAgICAgICAgICAgICAiR3Vlc3Qgc2hvdWxkIG5vdCB3cml0ZSB0aGlzIE1TUiFcbiIpOwotICAg
ICAgICAgcmV0ID0gMTsKKyAgICAgICAgdi0+YXJjaC52bWNlLmJhbmtbYmFua10ubWNpX2N0bDIg
PSB2YWw7CisgICAgICAgIG1jZV9wcmludGsoTUNFX1ZFUkJPU0UsICJNQ0U6IHdyIE1DJXVfQ1RM
MiAlIlBSSXg2NCJcbiIsCisgICAgICAgICAgICAgICAgICAgYmFuaywgdmFsKTsKKyAgICAgICAg
cmV0ID0gMTsKICAgICB9CiAKICAgICByZXR1cm4gcmV0OwpAQCAtOTk3LDEzICs5OTgsMTQgQEAK
IAogaW50IGludGVsX21jZV9yZG1zcihjb25zdCBzdHJ1Y3QgdmNwdSAqdiwgdWludDMyX3QgbXNy
LCB1aW50NjRfdCAqdmFsKQogeworICAgIHVuc2lnbmVkIGludCBiYW5rID0gbXNyIC0gTVNSX0lB
MzJfTUMwX0NUTDI7CiAgICAgaW50IHJldCA9IDA7CiAKLSAgICBpZiAoIG1zciA+PSBNU1JfSUEz
Ml9NQzBfQ1RMMiAmJgotICAgICAgICAgbXNyIDwgTVNSX0lBMzJfTUN4X0NUTDIodi0+YXJjaC5t
Y2dfY2FwICYgTUNHX0NBUF9DT1VOVCkgKQorICAgIGlmICggYmFuayA8IEdVRVNUX01DX0JBTktf
TlVNICkKICAgICB7Ci0gICAgICAgIG1jZV9wcmludGsoTUNFX1FVSUVULCAiV2UgaGF2ZSBkaXNh
YmxlZCBDTUNJIGNhcGFiaWxpdHksICIKLSAgICAgICAgICAgICAgICAgIkd1ZXN0IHNob3VsZCBu
b3QgcmVhZCB0aGlzIE1TUiFcbiIpOworICAgICAgICAqdmFsID0gdi0+YXJjaC52bWNlLmJhbmtb
YmFua10ubWNpX2N0bDI7CisgICAgICAgIG1jZV9wcmludGsoTUNFX1ZFUkJPU0UsICJNQ0U6IHJk
bXNyIE1DJXVfQ1RMMiAweCUiUFJJeDY0IlxuIiwKKyAgICAgICAgICAgICAgICAgICBiYW5rLCAq
dmFsKTsKICAgICAgICAgcmV0ID0gMTsKICAgICB9CiAKZGlmZiAtciBmNzZjZDM4MTQ1OWUgeGVu
L2FyY2gveDg2L2NwdS9tY2hlY2svdm1jZS5jCi0tLSBhL3hlbi9hcmNoL3g4Ni9jcHUvbWNoZWNr
L3ZtY2UuYwlXZWQgU2VwIDE5IDIxOjMyOjE1IDIwMTIgKzA4MDAKKysrIGIveGVuL2FyY2gveDg2
L2NwdS9tY2hlY2svdm1jZS5jCVdlZCBTZXAgMTkgMjM6MjI6NTcgMjAxMiArMDgwMApAQCAtMSw1
ICsxLDIyIEBACiAvKgotICogdm1jZS5jIC0gdmlydHVhbCBNQ0Ugc3VwcG9ydAorICogdm1jZS5j
IC0gcHJvdmlkZSBzb2Z0d2FyZSBlbXVsYXRlZCB2TUNFIHN1cHBvcnQgdG8gZ3Vlc3QKKyAqCisg
KiBDb3B5cmlnaHQgKEMpIDIwMTAsIDIwMTEgSmlhbmcsIFl1bmhvbmcgPHl1bmhvbmcuamlhbmdA
aW50ZWwuY29tPgorICogQ29weXJpZ2h0IChDKSAyMDEyLCAyMDEzIExpdSwgSmluc29uZyA8amlu
c29uZy5saXVAaW50ZWwuY29tPgorICoKKyAqIFRoaXMgcHJvZ3JhbSBpcyBmcmVlIHNvZnR3YXJl
OyB5b3UgY2FuIHJlZGlzdHJpYnV0ZSBpdCBhbmQvb3IgbW9kaWZ5CisgKiBpdCB1bmRlciB0aGUg
dGVybXMgb2YgdGhlIEdOVSBHZW5lcmFsIFB1YmxpYyBMaWNlbnNlIGFzIHB1Ymxpc2hlZCBieQor
ICogdGhlIEZyZWUgU29mdHdhcmUgRm91bmRhdGlvbjsgZWl0aGVyIHZlcnNpb24gMiBvZiB0aGUg
TGljZW5zZSwgb3IKKyAqIChhdCB5b3VyIG9wdGlvbikgYW55IGxhdGVyIHZlcnNpb24uCisgKgor
ICogVGhpcyBwcm9ncmFtIGlzIGRpc3RyaWJ1dGVkIGluIHRoZSBob3BlIHRoYXQgaXQgd2lsbCBi
ZSB1c2VmdWwsCisgKiBidXQgV0lUSE9VVCBBTlkgV0FSUkFOVFk7IHdpdGhvdXQgZXZlbiB0aGUg
aW1wbGllZCB3YXJyYW50eSBvZgorICogTUVSQ0hBTlRBQklMSVRZIG9yIEZJVE5FU1MgRk9SIEEg
UEFSVElDVUxBUiBQVVJQT1NFLiAgU2VlIHRoZQorICogR05VIEdlbmVyYWwgUHVibGljIExpY2Vu
c2UgZm9yIG1vcmUgZGV0YWlscy4KKyAqCisgKiBZb3Ugc2hvdWxkIGhhdmUgcmVjZWl2ZWQgYSBj
b3B5IG9mIHRoZSBHTlUgR2VuZXJhbCBQdWJsaWMgTGljZW5zZQorICogYWxvbmcgd2l0aCB0aGlz
IHByb2dyYW07IGlmIG5vdCwgd3JpdGUgdG8gdGhlIEZyZWUgU29mdHdhcmUKKyAqIEZvdW5kYXRp
b24sIEluYy4sIDU5IFRlbXBsZSBQbGFjZSwgU3VpdGUgMzMwLCBCb3N0b24sIE1BICAwMjExMS0x
MzA3ICBVU0EKICAqLwogCiAjaW5jbHVkZSA8eGVuL2luaXQuaD4KQEAgLTE5LDY3ICszNiw1NSBA
QAogI2luY2x1ZGUgIm1jZS5oIgogI2luY2x1ZGUgIng4Nl9tY2EuaCIKIAotLyoKLSAqIEVtdWxh
dGUgMiBiYW5rcyBmb3IgZ3Vlc3QKLSAqIEJhbmswOiByZXNlcnZlZCBmb3IgJ2JhbmswIHF1aXJr
JyBvY2N1ciBhdCBzb21lIHZlcnkgb2xkIHByb2Nlc3NvcnM6Ci0gKiAgIDEpLiBJbnRlbCBjcHUg
d2hvc2UgZmFtaWx5LW1vZGVsIHZhbHVlIDwgMDYtMUE7Ci0gKiAgIDIpLiBBTUQgSzcKLSAqIEJh
bmsxOiB1c2VkIHRvIHRyYW5zZmVyIGVycm9yIGluZm8gdG8gZ3Vlc3QKLSAqLwotI2RlZmluZSBH
VUVTVF9CQU5LX05VTSAyCi0jZGVmaW5lIEdVRVNUX01DR19DQVAgKE1DR19URVNfUCB8IE1DR19T
RVJfUCB8IEdVRVNUX0JBTktfTlVNKQotCi0jZGVmaW5lIGRvbV92bWNlKHgpICAgKCh4KS0+YXJj
aC52bWNhX21zcnMpCi0KLWludCB2bWNlX2luaXRfbXNyKHN0cnVjdCBkb21haW4gKmQpCi17Ci0g
ICAgZG9tX3ZtY2UoZCkgPSB4bWFsbG9jKHN0cnVjdCBkb21haW5fbWNhX21zcnMpOwotICAgIGlm
ICggIWRvbV92bWNlKGQpICkKLSAgICAgICAgcmV0dXJuIC1FTk9NRU07Ci0KLSAgICBkb21fdm1j
ZShkKS0+bWNnX3N0YXR1cyA9IDB4MDsKLSAgICBkb21fdm1jZShkKS0+bnJfaW5qZWN0aW9uID0g
MDsKLQotICAgIElOSVRfTElTVF9IRUFEKCZkb21fdm1jZShkKS0+aW1wYWN0X2hlYWRlcik7Ci0g
ICAgc3Bpbl9sb2NrX2luaXQoJmRvbV92bWNlKGQpLT5sb2NrKTsKLQotICAgIHJldHVybiAwOwot
fQotCi12b2lkIHZtY2VfZGVzdHJveV9tc3Ioc3RydWN0IGRvbWFpbiAqZCkKLXsKLSAgICBpZiAo
ICFkb21fdm1jZShkKSApCi0gICAgICAgIHJldHVybjsKLSAgICB4ZnJlZShkb21fdm1jZShkKSk7
Ci0gICAgZG9tX3ZtY2UoZCkgPSBOVUxMOwotfQotCiB2b2lkIHZtY2VfaW5pdF92Y3B1KHN0cnVj
dCB2Y3B1ICp2KQogewotICAgIHYtPmFyY2gubWNnX2NhcCA9IEdVRVNUX01DR19DQVA7CisgICAg
aW50IGk7CisKKyAgICAvKiBnbG9iYWwgTUNBIE1TUnMgaW5pdCAqLworICAgIGlmICggYm9vdF9j
cHVfZGF0YS54ODZfdmVuZG9yID09IFg4Nl9WRU5ET1JfSU5URUwgKQorICAgICAgICB2LT5hcmNo
LnZtY2UubWNnX2NhcCA9IElOVEVMX0dVRVNUX01DR19DQVA7CisgICAgZWxzZQorICAgICAgICB2
LT5hcmNoLnZtY2UubWNnX2NhcCA9IEFNRF9HVUVTVF9NQ0dfQ0FQOworCisgICAgdi0+YXJjaC52
bWNlLm1jZ19zdGF0dXMgPSAwOworCisgICAgLyogcGVyLWJhbmsgTUNBIE1TUnMgaW5pdCAqLwor
ICAgIGZvciAoIGkgPSAwOyBpIDwgR1VFU1RfTUNfQkFOS19OVU07IGkrKyApCisgICAgICAgIG1l
bXNldCgmdi0+YXJjaC52bWNlLmJhbmtbaV0sIDAsIHNpemVvZihzdHJ1Y3Qgdm1jZV9iYW5rKSk7
CisKKyAgICBzcGluX2xvY2tfaW5pdCgmdi0+YXJjaC52bWNlLmxvY2spOwogfQogCiBpbnQgdm1j
ZV9yZXN0b3JlX3ZjcHUoc3RydWN0IHZjcHUgKnYsIHVpbnQ2NF90IGNhcHMpCiB7Ci0gICAgaWYg
KCBjYXBzICYgfkdVRVNUX01DR19DQVAgJiB+TUNHX0NBUF9DT1VOVCAmIH5NQ0dfQ1RMX1AgKQor
ICAgIHVpbnQ2NF90IGd1ZXN0X21jZ19jYXA7CisKKyAgICBpZiAoIGJvb3RfY3B1X2RhdGEueDg2
X3ZlbmRvciA9PSBYODZfVkVORE9SX0lOVEVMICkKKyAgICAgICAgZ3Vlc3RfbWNnX2NhcCA9IElO
VEVMX0dVRVNUX01DR19DQVA7CisgICAgZWxzZQorICAgICAgICBndWVzdF9tY2dfY2FwID0gQU1E
X0dVRVNUX01DR19DQVA7CisKKyAgICBpZiAoIGNhcHMgJiB+Z3Vlc3RfbWNnX2NhcCAmIH5NQ0df
Q0FQX0NPVU5UICYgfk1DR19DVExfUCApCiAgICAgewogICAgICAgICBkcHJpbnRrKFhFTkxPR19H
X0VSUiwgIiVzIHJlc3RvcmU6IHVuc3VwcG9ydGVkIE1DQSBjYXBhYmlsaXRpZXMiCiAgICAgICAg
ICAgICAgICAgIiAlIyIgUFJJeDY0ICIgZm9yIGQlZDp2JXUgKHN1cHBvcnRlZDogJSNMeClcbiIs
CiAgICAgICAgICAgICAgICAgaXNfaHZtX3ZjcHUodikgPyAiSFZNIiA6ICJQViIsIGNhcHMsIHYt
PmRvbWFpbi0+ZG9tYWluX2lkLAotICAgICAgICAgICAgICAgIHYtPnZjcHVfaWQsIEdVRVNUX01D
R19DQVAgJiB+TUNHX0NBUF9DT1VOVCk7CisgICAgICAgICAgICAgICAgdi0+dmNwdV9pZCwgZ3Vl
c3RfbWNnX2NhcCAmIH5NQ0dfQ0FQX0NPVU5UKTsKICAgICAgICAgcmV0dXJuIC1FUEVSTTsKICAg
ICB9CiAKLSAgICB2LT5hcmNoLm1jZ19jYXAgPSBjYXBzOworICAgIHYtPmFyY2gudm1jZS5tY2df
Y2FwID0gY2FwczsKICAgICByZXR1cm4gMDsKIH0KIAotc3RhdGljIGludCBiYW5rX21jZV9yZG1z
cihjb25zdCBzdHJ1Y3QgdmNwdSAqdiwgdWludDMyX3QgbXNyLCB1aW50NjRfdCAqdmFsKQorLyoK
KyAqIEZvciBoaXN0b3JpYyB2ZXJzaW9uIHJlYXNvbiwgYmFuayBudW1iZXIgbWF5IGdyZWF0ZXIg
dGhhbiBHVUVTVF9NQ19CQU5LX05VTSwKKyAqIHdoZW4gbWlncmF0aWUgZnJvbSBvbGQgdk1DRSB2
ZXJzaW9uIHRvIG5ldyB2TUNFLgorICovCitzdGF0aWMgaW50IGJhbmtfbWNlX3JkbXNyKHN0cnVj
dCB2Y3B1ICp2LCB1aW50MzJfdCBtc3IsIHVpbnQ2NF90ICp2YWwpCiB7CiAgICAgaW50IHJldCA9
IDE7CiAgICAgdW5zaWduZWQgaW50IGJhbmsgPSAobXNyIC0gTVNSX0lBMzJfTUMwX0NUTCkgLyA0
OwotICAgIHN0cnVjdCBkb21haW5fbWNhX21zcnMgKnZtY2UgPSBkb21fdm1jZSh2LT5kb21haW4p
OwotICAgIHN0cnVjdCBiYW5rX2VudHJ5ICplbnRyeTsKIAogICAgICp2YWwgPSAwOwogCkBAIC05
Miw0NiArOTcsMzMgQEAKICAgICAgICAgICAgICAgICAgICBiYW5rLCAqdmFsKTsKICAgICAgICAg
YnJlYWs7CiAgICAgY2FzZSBNU1JfSUEzMl9NQzBfU1RBVFVTOgotICAgICAgICAvKiBPbmx5IGVy
cm9yIGJhbmsgaXMgcmVhZC4gTm9uLWVycm9yIGJhbmtzIHNpbXBseSByZXR1cm4uICovCi0gICAg
ICAgIGlmICggIWxpc3RfZW1wdHkoJnZtY2UtPmltcGFjdF9oZWFkZXIpICkKKyAgICAgICAgaWYg
KCBiYW5rIDwgR1VFU1RfTUNfQkFOS19OVU0gKQogICAgICAgICB7Ci0gICAgICAgICAgICBlbnRy
eSA9IGxpc3RfZW50cnkodm1jZS0+aW1wYWN0X2hlYWRlci5uZXh0LAotICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgIHN0cnVjdCBiYW5rX2VudHJ5LCBsaXN0KTsKLSAgICAgICAgICAgIGlm
ICggZW50cnktPmJhbmsgPT0gYmFuayApCi0gICAgICAgICAgICB7Ci0gICAgICAgICAgICAgICAg
KnZhbCA9IGVudHJ5LT5tY2lfc3RhdHVzOworICAgICAgICAgICAgKnZhbCA9IHYtPmFyY2gudm1j
ZS5iYW5rW2JhbmtdLm1jaV9zdGF0dXM7CisgICAgICAgICAgICBpZiAoICp2YWwgKQogICAgICAg
ICAgICAgICAgIG1jZV9wcmludGsoTUNFX1ZFUkJPU0UsCi0gICAgICAgICAgICAgICAgICAgICAg
ICAgICAiTUNFOiByZCBNQyV1X1NUQVRVUyBpbiB2TUNFIyBjb250ZXh0ICIKLSAgICAgICAgICAg
ICAgICAgICAgICAgICAgICJ2YWx1ZSAweCUiUFJJeDY0IlxuIiwgYmFuaywgKnZhbCk7Ci0gICAg
ICAgICAgICB9CisgICAgICAgICAgICAgICAgICAgICAgICAgICAiTUNFOiByZG1zciBNQyV1X1NU
QVRVUyBpbiB2TUNFIyBjb250ZXh0ICIKKyAgICAgICAgICAgICAgICAgICAgICAgICAgICIweCUi
UFJJeDY0IlxuIiwgYmFuaywgKnZhbCk7CiAgICAgICAgIH0KICAgICAgICAgYnJlYWs7CiAgICAg
Y2FzZSBNU1JfSUEzMl9NQzBfQUREUjoKLSAgICAgICAgaWYgKCAhbGlzdF9lbXB0eSgmdm1jZS0+
aW1wYWN0X2hlYWRlcikgKQorICAgICAgICBpZiAoIGJhbmsgPCBHVUVTVF9NQ19CQU5LX05VTSAp
CiAgICAgICAgIHsKLSAgICAgICAgICAgIGVudHJ5ID0gbGlzdF9lbnRyeSh2bWNlLT5pbXBhY3Rf
aGVhZGVyLm5leHQsCi0gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgc3RydWN0IGJhbmtf
ZW50cnksIGxpc3QpOwotICAgICAgICAgICAgaWYgKCBlbnRyeS0+YmFuayA9PSBiYW5rICkKLSAg
ICAgICAgICAgIHsKLSAgICAgICAgICAgICAgICAqdmFsID0gZW50cnktPm1jaV9hZGRyOworICAg
ICAgICAgICAgKnZhbCA9IHYtPmFyY2gudm1jZS5iYW5rW2JhbmtdLm1jaV9hZGRyOworICAgICAg
ICAgICAgaWYgKCAqdmFsICkKICAgICAgICAgICAgICAgICBtY2VfcHJpbnRrKE1DRV9WRVJCT1NF
LAogICAgICAgICAgICAgICAgICAgICAgICAgICAgIk1DRTogcmRtc3IgTUMldV9BRERSIGluIHZN
Q0UjIGNvbnRleHQgIgogICAgICAgICAgICAgICAgICAgICAgICAgICAgIjB4JSJQUkl4NjQiXG4i
LCBiYW5rLCAqdmFsKTsKLSAgICAgICAgICAgIH0KICAgICAgICAgfQogICAgICAgICBicmVhazsK
ICAgICBjYXNlIE1TUl9JQTMyX01DMF9NSVNDOgotICAgICAgICBpZiAoICFsaXN0X2VtcHR5KCZ2
bWNlLT5pbXBhY3RfaGVhZGVyKSApCisgICAgICAgIGlmICggYmFuayA8IEdVRVNUX01DX0JBTktf
TlVNICkKICAgICAgICAgewotICAgICAgICAgICAgZW50cnkgPSBsaXN0X2VudHJ5KHZtY2UtPmlt
cGFjdF9oZWFkZXIubmV4dCwKLSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBzdHJ1Y3Qg
YmFua19lbnRyeSwgbGlzdCk7Ci0gICAgICAgICAgICBpZiAoIGVudHJ5LT5iYW5rID09IGJhbmsg
KQotICAgICAgICAgICAgewotICAgICAgICAgICAgICAgICp2YWwgPSBlbnRyeS0+bWNpX21pc2M7
CisgICAgICAgICAgICAqdmFsID0gdi0+YXJjaC52bWNlLmJhbmtbYmFua10ubWNpX21pc2M7Cisg
ICAgICAgICAgICBpZiAoICp2YWwgKQogICAgICAgICAgICAgICAgIG1jZV9wcmludGsoTUNFX1ZF
UkJPU0UsCi0gICAgICAgICAgICAgICAgICAgICAgICAgICAiTUNFOiByZCBNQyV1X01JU0MgaW4g
dk1DRSMgY29udGV4dCAiCisgICAgICAgICAgICAgICAgICAgICAgICAgICAiTUNFOiByZG1zciBN
QyV1X01JU0MgaW4gdk1DRSMgY29udGV4dCAiCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAi
MHglIlBSSXg2NCJcbiIsIGJhbmssICp2YWwpOwotICAgICAgICAgICAgfQogICAgICAgICB9CiAg
ICAgICAgIGJyZWFrOwogICAgIGRlZmF1bHQ6CkBAIC0xNTcsNTYgKzE0OSw1MCBAQAogICovCiBp
bnQgdm1jZV9yZG1zcih1aW50MzJfdCBtc3IsIHVpbnQ2NF90ICp2YWwpCiB7Ci0gICAgY29uc3Qg
c3RydWN0IHZjcHUgKmN1ciA9IGN1cnJlbnQ7Ci0gICAgc3RydWN0IGRvbWFpbl9tY2FfbXNycyAq
dm1jZSA9IGRvbV92bWNlKGN1ci0+ZG9tYWluKTsKKyAgICBzdHJ1Y3QgdmNwdSAqY3VyID0gY3Vy
cmVudDsKICAgICBpbnQgcmV0ID0gMTsKIAogICAgICp2YWwgPSAwOwogCi0gICAgc3Bpbl9sb2Nr
KCZ2bWNlLT5sb2NrKTsKKyAgICBzcGluX2xvY2soJmN1ci0+YXJjaC52bWNlLmxvY2spOwogCiAg
ICAgc3dpdGNoICggbXNyICkKICAgICB7CiAgICAgY2FzZSBNU1JfSUEzMl9NQ0dfU1RBVFVTOgot
ICAgICAgICAqdmFsID0gdm1jZS0+bWNnX3N0YXR1czsKKyAgICAgICAgKnZhbCA9IGN1ci0+YXJj
aC52bWNlLm1jZ19zdGF0dXM7CiAgICAgICAgIGlmICgqdmFsKQogICAgICAgICAgICAgbWNlX3By
aW50ayhNQ0VfVkVSQk9TRSwKICAgICAgICAgICAgICAgICAgICAgICAgIk1DRTogcmRtc3IgTUNH
X1NUQVRVUyAweCUiUFJJeDY0IlxuIiwgKnZhbCk7CiAgICAgICAgIGJyZWFrOwogICAgIGNhc2Ug
TVNSX0lBMzJfTUNHX0NBUDoKLSAgICAgICAgKnZhbCA9IGN1ci0+YXJjaC5tY2dfY2FwOwotICAg
ICAgICBtY2VfcHJpbnRrKE1DRV9WRVJCT1NFLCAiTUNFOiByZG1zciBNQ0dfQ0FQIDB4JSJQUkl4
NjQiXG4iLAotICAgICAgICAgICAgICAgICAgICp2YWwpOworICAgICAgICAqdmFsID0gY3VyLT5h
cmNoLnZtY2UubWNnX2NhcDsKKyAgICAgICAgbWNlX3ByaW50ayhNQ0VfVkVSQk9TRSwgIk1DRTog
cmRtc3IgTUNHX0NBUCAweCUiUFJJeDY0IlxuIiwgKnZhbCk7CiAgICAgICAgIGJyZWFrOwogICAg
IGNhc2UgTVNSX0lBMzJfTUNHX0NUTDoKLSAgICAgICAgLyogU3RpY2sgYWxsIDEncyB3aGVuIENU
TCBzdXBwb3J0LCBhbmQgMCdzIHdoZW4gbm8gQ1RMIHN1cHBvcnQgKi8KLSAgICAgICAgaWYgKCBj
dXItPmFyY2gubWNnX2NhcCAmIE1DR19DVExfUCApCi0gICAgICAgICAgICAqdmFsID0gfjBVTEw7
Ci0gICAgICAgIG1jZV9wcmludGsoTUNFX1ZFUkJPU0UsICJNQ0U6IHJkbXNyIE1DR19DVEwgMHgl
IlBSSXg2NCJcbiIsICp2YWwpOworICAgICAgICBpZiAoIGN1ci0+YXJjaC52bWNlLm1jZ19jYXAg
JiBNQ0dfQ1RMX1AgKQorICAgICAgICB7CisgICAgICAgICAgICAqdmFsID0gfjBVTDsKKyAgICAg
ICAgICAgIG1jZV9wcmludGsoTUNFX1ZFUkJPU0UsICJNQ0U6IHJkbXNyIE1DR19DVEwgMHglIlBS
SXg2NCJcbiIsICp2YWwpOworICAgICAgICB9CiAgICAgICAgIGJyZWFrOwogICAgIGRlZmF1bHQ6
CiAgICAgICAgIHJldCA9IG1jZV9iYW5rX21zcihjdXIsIG1zcikgPyBiYW5rX21jZV9yZG1zcihj
dXIsIG1zciwgdmFsKSA6IDA7CiAgICAgICAgIGJyZWFrOwogICAgIH0KIAotICAgIHNwaW5fdW5s
b2NrKCZ2bWNlLT5sb2NrKTsKKyAgICBzcGluX3VubG9jaygmY3VyLT5hcmNoLnZtY2UubG9jayk7
CisKICAgICByZXR1cm4gcmV0OwogfQogCisvKgorICogRm9yIGhpc3RvcmljIHZlcnNpb24gcmVh
c29uLCBiYW5rIG51bWJlciBtYXkgZ3JlYXRlciB0aGFuIEdVRVNUX01DX0JBTktfTlVNLAorICog
d2hlbiBtaWdyYXRpZSBmcm9tIG9sZCB2TUNFIHZlcnNpb24gdG8gbmV3IHZNQ0UuCisgKi8KIHN0
YXRpYyBpbnQgYmFua19tY2Vfd3Jtc3Ioc3RydWN0IHZjcHUgKnYsIHUzMiBtc3IsIHU2NCB2YWwp
CiB7CiAgICAgaW50IHJldCA9IDE7CiAgICAgdW5zaWduZWQgaW50IGJhbmsgPSAobXNyIC0gTVNS
X0lBMzJfTUMwX0NUTCkgLyA0OwotICAgIHN0cnVjdCBkb21haW5fbWNhX21zcnMgKnZtY2UgPSBk
b21fdm1jZSh2LT5kb21haW4pOwotICAgIHN0cnVjdCBiYW5rX2VudHJ5ICplbnRyeSA9IE5VTEw7
Ci0KLSAgICAvKiBHaXZlIHRoZSBmaXJzdCBlbnRyeSBvZiB0aGUgbGlzdCwgaXQgY29ycmVzcG9u
ZHMgdG8gY3VycmVudAotICAgICAqIHZNQ0UjIGluamVjdGlvbi4gV2hlbiB2TUNFIyBpcyBmaW5p
c2hlZCBwcm9jZXNzaW5nIGJ5IHRoZQotICAgICAqIHRoZSBndWVzdCwgdGhpcyBub2RlIHdpbGwg
YmUgZGVsZXRlZC4KLSAgICAgKiBPbmx5IGVycm9yIGJhbmsgaXMgd3JpdHRlbi4gTm9uLWVycm9y
IGJhbmtzIHNpbXBseSByZXR1cm4uCi0gICAgICovCi0gICAgaWYgKCAhbGlzdF9lbXB0eSgmdm1j
ZS0+aW1wYWN0X2hlYWRlcikgKQotICAgICAgICBlbnRyeSA9IGxpc3RfZW50cnkodm1jZS0+aW1w
YWN0X2hlYWRlci5uZXh0LCBzdHJ1Y3QgYmFua19lbnRyeSwgbGlzdCk7CiAKICAgICBzd2l0Y2gg
KCBtc3IgJiAoTVNSX0lBMzJfTUMwX0NUTCB8IDMpICkKICAgICB7CkBAIC0yMTcsNTAgKzIwMyw0
NiBAQAogICAgICAgICAgKi8KICAgICAgICAgYnJlYWs7CiAgICAgY2FzZSBNU1JfSUEzMl9NQzBf
U1RBVFVTOgotICAgICAgICBpZiAoIGVudHJ5ICYmIChlbnRyeS0+YmFuayA9PSBiYW5rKSApCisg
ICAgICAgIGlmICggdmFsICkKICAgICAgICAgewotICAgICAgICAgICAgZW50cnktPm1jaV9zdGF0
dXMgPSB2YWw7Ci0gICAgICAgICAgICBtY2VfcHJpbnRrKE1DRV9WRVJCT1NFLAotICAgICAgICAg
ICAgICAgICAgICAgICAiTUNFOiB3ciBNQyV1X1NUQVRVUyAlIlBSSXg2NCIgaW4gdk1DRSNcbiIs
CisgICAgICAgICAgICBtY2VfcHJpbnRrKE1DRV9RVUlFVCwKKyAgICAgICAgICAgICAgICAgICAg
ICAgIk1DRTogd3IgTUMldV9TVEFUVVMgdy8gbm9uLXplcm8gY2F1c2UgI0dQXG4iLCBiYW5rKTsK
KyAgICAgICAgICAgIHJldCA9IC0xOworICAgICAgICB9CisgICAgICAgIGlmICggYmFuayA8IEdV
RVNUX01DX0JBTktfTlVNICkKKyAgICAgICAgeworICAgICAgICAgICAgdi0+YXJjaC52bWNlLmJh
bmtbYmFua10ubWNpX3N0YXR1cyA9IHZhbDsKKyAgICAgICAgICAgIG1jZV9wcmludGsoTUNFX1ZF
UkJPU0UsICJNQ0U6IHdyIE1DJXVfU1RBVFVTICUiUFJJeDY0IlxuIiwKICAgICAgICAgICAgICAg
ICAgICAgICAgYmFuaywgdmFsKTsKICAgICAgICAgfQotICAgICAgICBlbHNlCi0gICAgICAgICAg
ICBtY2VfcHJpbnRrKE1DRV9WRVJCT1NFLAotICAgICAgICAgICAgICAgICAgICAgICAiTUNFOiB3
ciBNQyV1X1NUQVRVUyAlIlBSSXg2NCJcbiIsIGJhbmssIHZhbCk7CiAgICAgICAgIGJyZWFrOwog
ICAgIGNhc2UgTVNSX0lBMzJfTUMwX0FERFI6Ci0gICAgICAgIGlmICggIX52YWwgKQorICAgICAg
ICBpZiAoIHZhbCApCiAgICAgICAgIHsKICAgICAgICAgICAgIG1jZV9wcmludGsoTUNFX1FVSUVU
LAotICAgICAgICAgICAgICAgICAgICAgICAiTUNFOiB3ciBNQyV1X0FERFIgd2l0aCBhbGwgMXMg
d2lsbCBjYXVzZSAjR1BcbiIsIGJhbmspOworICAgICAgICAgICAgICAgICAgICAgICAiTUNFOiB3
ciBNQyV1X0FERFIgdy8gbm9uLXplcm8gY2F1c2UgI0dQXG4iLCBiYW5rKTsKICAgICAgICAgICAg
IHJldCA9IC0xOwogICAgICAgICB9Ci0gICAgICAgIGVsc2UgaWYgKCBlbnRyeSAmJiAoZW50cnkt
PmJhbmsgPT0gYmFuaykgKQorICAgICAgICBlbHNlIGlmICggYmFuayA8IEdVRVNUX01DX0JBTktf
TlVNICkKICAgICAgICAgewotICAgICAgICAgICAgZW50cnktPm1jaV9hZGRyID0gdmFsOwotICAg
ICAgICAgICAgbWNlX3ByaW50ayhNQ0VfVkVSQk9TRSwKLSAgICAgICAgICAgICAgICAgICAgICAg
Ik1DRTogd3IgTUMldV9BRERSICUiUFJJeDY0IiBpbiB2TUNFI1xuIiwgYmFuaywgdmFsKTsKLSAg
ICAgICAgfQotICAgICAgICBlbHNlCisgICAgICAgICAgICB2LT5hcmNoLnZtY2UuYmFua1tiYW5r
XS5tY2lfYWRkciA9IHZhbDsKICAgICAgICAgICAgIG1jZV9wcmludGsoTUNFX1ZFUkJPU0UsCiAg
ICAgICAgICAgICAgICAgICAgICAgICJNQ0U6IHdyIE1DJXVfQUREUiAlIlBSSXg2NCJcbiIsIGJh
bmssIHZhbCk7CisgICAgICAgIH0KICAgICAgICAgYnJlYWs7CiAgICAgY2FzZSBNU1JfSUEzMl9N
QzBfTUlTQzoKLSAgICAgICAgaWYgKCAhfnZhbCApCisgICAgICAgIGlmICggdmFsICkKICAgICAg
ICAgewogICAgICAgICAgICAgbWNlX3ByaW50ayhNQ0VfUVVJRVQsCi0gICAgICAgICAgICAgICAg
ICAgICAgICJNQ0U6IHdyIE1DJXVfTUlTQyB3aXRoIGFsbCAxcyB3aWxsIGNhdXNlICNHUFxuIiwg
YmFuayk7CisgICAgICAgICAgICAgICAgICAgICAgICJNQ0U6IHdyIE1DJXVfTUlTQyB3LyBub24t
emVybyBjYXVzZSAjR1BcbiIsIGJhbmspOwogICAgICAgICAgICAgcmV0ID0gLTE7CiAgICAgICAg
IH0KLSAgICAgICAgZWxzZSBpZiAoIGVudHJ5ICYmIChlbnRyeS0+YmFuayA9PSBiYW5rKSApCisg
ICAgICAgIGVsc2UgaWYgKCBiYW5rIDwgR1VFU1RfTUNfQkFOS19OVU0gKQogICAgICAgICB7Ci0g
ICAgICAgICAgICBlbnRyeS0+bWNpX21pc2MgPSB2YWw7Ci0gICAgICAgICAgICBtY2VfcHJpbnRr
KE1DRV9WRVJCT1NFLAotICAgICAgICAgICAgICAgICAgICAgICAiTUNFOiB3ciBNQyV1X01JU0Mg
JSJQUkl4NjQiIGluIHZNQ0UjXG4iLCBiYW5rLCB2YWwpOwotICAgICAgICB9Ci0gICAgICAgIGVs
c2UKKyAgICAgICAgICAgIHYtPmFyY2gudm1jZS5iYW5rW2JhbmtdLm1jaV9taXNjID0gdmFsOwog
ICAgICAgICAgICAgbWNlX3ByaW50ayhNQ0VfVkVSQk9TRSwKICAgICAgICAgICAgICAgICAgICAg
ICAgIk1DRTogd3IgTUMldV9NSVNDICUiUFJJeDY0IlxuIiwgYmFuaywgdmFsKTsKKyAgICAgICAg
fQogICAgICAgICBicmVhazsKICAgICBkZWZhdWx0OgogICAgICAgICBzd2l0Y2ggKCBib290X2Nw
dV9kYXRhLng4Nl92ZW5kb3IgKQpAQCAtMjg2LDUyICsyNjgsMzMgQEAKIGludCB2bWNlX3dybXNy
KHUzMiBtc3IsIHU2NCB2YWwpCiB7CiAgICAgc3RydWN0IHZjcHUgKmN1ciA9IGN1cnJlbnQ7Ci0g
ICAgc3RydWN0IGJhbmtfZW50cnkgKmVudHJ5ID0gTlVMTDsKLSAgICBzdHJ1Y3QgZG9tYWluX21j
YV9tc3JzICp2bWNlID0gZG9tX3ZtY2UoY3VyLT5kb21haW4pOwogICAgIGludCByZXQgPSAxOwog
Ci0gICAgc3Bpbl9sb2NrKCZ2bWNlLT5sb2NrKTsKKyAgICBzcGluX2xvY2soJmN1ci0+YXJjaC52
bWNlLmxvY2spOwogCiAgICAgc3dpdGNoICggbXNyICkKICAgICB7CiAgICAgY2FzZSBNU1JfSUEz
Ml9NQ0dfQ1RMOgorICAgICAgICAvKiBJZiBNQ0dfQ1RMIGV4aXN0IHRoZW4gc3RpY2sgdG8gYWxs
IDEncy4gSWYgbm90IGV4aXN0IHRoZW4gaWdub3JlICovCiAgICAgICAgIGJyZWFrOwogICAgIGNh
c2UgTVNSX0lBMzJfTUNHX1NUQVRVUzoKLSAgICAgICAgdm1jZS0+bWNnX3N0YXR1cyA9IHZhbDsK
KyAgICAgICAgY3VyLT5hcmNoLnZtY2UubWNnX3N0YXR1cyA9IHZhbDsKICAgICAgICAgbWNlX3By
aW50ayhNQ0VfVkVSQk9TRSwgIk1DRTogd3Jtc3IgTUNHX1NUQVRVUyAlIlBSSXg2NCJcbiIsIHZh
bCk7Ci0gICAgICAgIC8qIEZvciBIVk0gZ3Vlc3QsIHRoaXMgaXMgdGhlIHBvaW50IGZvciBkZWxl
dGluZyB2TUNFIGluamVjdGlvbiBub2RlICovCi0gICAgICAgIGlmICggaXNfaHZtX3ZjcHUoY3Vy
KSAmJiAodm1jZS0+bnJfaW5qZWN0aW9uID4gMCkgKQotICAgICAgICB7Ci0gICAgICAgICAgICB2
bWNlLT5ucl9pbmplY3Rpb24tLTsgLyogU2hvdWxkIGJlIDAgKi8KLSAgICAgICAgICAgIGlmICgg
IWxpc3RfZW1wdHkoJnZtY2UtPmltcGFjdF9oZWFkZXIpICkKLSAgICAgICAgICAgIHsKLSAgICAg
ICAgICAgICAgICBlbnRyeSA9IGxpc3RfZW50cnkodm1jZS0+aW1wYWN0X2hlYWRlci5uZXh0LAot
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBzdHJ1Y3QgYmFua19lbnRyeSwgbGlz
dCk7Ci0gICAgICAgICAgICAgICAgaWYgKCBlbnRyeS0+bWNpX3N0YXR1cyAmIE1DaV9TVEFUVVNf
VkFMICkKLSAgICAgICAgICAgICAgICAgICAgbWNlX3ByaW50ayhNQ0VfUVVJRVQsICJNQ0U6IE1D
aV9TVEFUVVMgTVNSIHNob3VsZCBoYXZlICIKLSAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAiYmVlbiBjbGVhcmVkIGJlZm9yZSB3cml0ZSBNQ0dfU1RBVFVTIE1TUlxuIik7Ci0KLSAgICAg
ICAgICAgICAgICBtY2VfcHJpbnRrKE1DRV9RVUlFVCwgIk1DRTogRGVsZXRlIEhWTSBsYXN0IGlu
amVjdGlvbiAiCi0gICAgICAgICAgICAgICAgICAgICAgICAgICAiTm9kZSwgbnJfaW5qZWN0aW9u
ICV1XG4iLAotICAgICAgICAgICAgICAgICAgICAgICAgICAgdm1jZS0+bnJfaW5qZWN0aW9uKTsK
LSAgICAgICAgICAgICAgICBsaXN0X2RlbCgmZW50cnktPmxpc3QpOwotICAgICAgICAgICAgICAg
IHhmcmVlKGVudHJ5KTsKLSAgICAgICAgICAgIH0KLSAgICAgICAgICAgIGVsc2UKLSAgICAgICAg
ICAgICAgICBtY2VfcHJpbnRrKE1DRV9RVUlFVCwgIk1DRTogTm90IGZvdW5kIEhWTSBndWVzdCIK
LSAgICAgICAgICAgICAgICAgICAgICAgICAgICIgbGFzdCBpbmplY3Rpb24gTm9kZSwgc29tZXRo
aW5nIFdyb25nIVxuIik7Ci0gICAgICAgIH0KICAgICAgICAgYnJlYWs7CiAgICAgY2FzZSBNU1Jf
SUEzMl9NQ0dfQ0FQOgotICAgICAgICBtY2VfcHJpbnRrKE1DRV9RVUlFVCwgIk1DRTogTUNHX0NB
UCBpcyByZWFkLW9ubHlcbiIpOwotICAgICAgICByZXQgPSAtMTsKKyAgICAgICAgLyoKKyAgICAg
ICAgICogQWNjb3JkaW5nIHRvIEludGVsIFNETSwgSUEzMl9NQ0dfQ0FQIGlzIGEgcmVhZC1vbmx5
IHJlZ2lzdGVyLAorICAgICAgICAgKiB0aGUgZWZmZWN0IG9mIHdyaXRpbmcgdG8gdGhlIElBMzJf
TUNHX0NBUCBpcyB1bmRlZmluZWQuIEhlcmUgd2UKKyAgICAgICAgICogdHJlYXQgd3JpdGluZyBh
cyAnd3JpdGUgbm90IGNoYW5nZScuIEd1ZXN0IHdvdWxkIG5vdCBzdXJwcmlzZS4KKyAgICAgICAg
ICovCisgICAgICAgIG1jZV9wcmludGsoTUNFX1FVSUVULCAiTUNFOiBNQ0dfQ0FQIGlzIHJlYWQg
b25seSBhbmQgd3JpdGUgbm90IGNoYW5nZVxuIik7CiAgICAgICAgIGJyZWFrOwogICAgIGRlZmF1
bHQ6CiAgICAgICAgIHJldCA9IG1jZV9iYW5rX21zcihjdXIsIG1zcikgPyBiYW5rX21jZV93cm1z
cihjdXIsIG1zciwgdmFsKSA6IDA7CiAgICAgICAgIGJyZWFrOwogICAgIH0KIAotICAgIHNwaW5f
dW5sb2NrKCZ2bWNlLT5sb2NrKTsKKyAgICBzcGluX3VubG9jaygmY3VyLT5hcmNoLnZtY2UubG9j
ayk7CiAgICAgcmV0dXJuIHJldDsKIH0KIApAQCAtMzQyLDcgKzMwNSw3IEBACiAKICAgICBmb3Jf
ZWFjaF92Y3B1KCBkLCB2ICkgewogICAgICAgICBzdHJ1Y3QgaHZtX3ZtY2VfdmNwdSBjdHh0ID0g
ewotICAgICAgICAgICAgLmNhcHMgPSB2LT5hcmNoLm1jZ19jYXAKKyAgICAgICAgICAgIC5jYXBz
ID0gdi0+YXJjaC52bWNlLm1jZ19jYXAKICAgICAgICAgfTsKIAogICAgICAgICBlcnIgPSBodm1f
c2F2ZV9lbnRyeShWTUNFX1ZDUFUsIHYtPnZjcHVfaWQsIGgsICZjdHh0KTsKQEAgLTQyMiw5MyAr
Mzg1LDM4IEBACiAgICAgcmV0dXJuIDA7CiB9CiAKLS8qIFRoaXMgbm9kZSBsaXN0IHJlY29yZHMg
ZXJyb3JzIGltcGFjdGluZyBhIGRvbWFpbi4gd2hlbiBvbmUKLSAqIE1DRSMgaGFwcGVucywgb25l
IGVycm9yIGJhbmsgaW1wYWN0cyBhIGRvbWFpbi4gVGhpcyBlcnJvciBub2RlCi0gKiB3aWxsIGJl
IGluc2VydGVkIHRvIHRoZSB0YWlsIG9mIHRoZSBwZXJfZG9tIGRhdGEgZm9yIHZNQ0UjIE1TUgot
ICogdmlydHVhbGl6YXRpb24uIFdoZW4gb25lIHZNQ0UjIGluamVjdGlvbiBpcyBmaW5pc2hlZCBw
cm9jZXNzaW5nCi0gKiBwcm9jZXNzZWQgYnkgZ3Vlc3QsIHRoZSBjb3JyZXNwb25kaW5nIG5vZGUg
d2lsbCBiZSBkZWxldGVkLgotICogVGhpcyBub2RlIGxpc3QgaXMgZm9yIEdVRVNUIHZNQ0UjIE1T
UlMgdmlydHVhbGl6YXRpb24uCi0gKi8KLXN0YXRpYyBzdHJ1Y3QgYmFua19lbnRyeSogYWxsb2Nf
YmFua19lbnRyeSh2b2lkKQoraW50IGZpbGxfdm1zcl9kYXRhKHN0cnVjdCBtY2luZm9fYmFuayAq
bWNfYmFuaywgc3RydWN0IGRvbWFpbiAqZCwKKyAgICAgICAgICAgICAgICAgICB1aW50NjRfdCBn
c3RhdHVzKQogewotICAgIHN0cnVjdCBiYW5rX2VudHJ5ICplbnRyeTsKKyAgICBzdHJ1Y3QgdmNw
dSAqdiA9IGQtPnZjcHVbMF07CiAKLSAgICBlbnRyeSA9IHh6YWxsb2Moc3RydWN0IGJhbmtfZW50
cnkpOwotICAgIGlmICggZW50cnkgPT0gTlVMTCApCi0gICAgewotICAgICAgICBwcmludGsoS0VS
Tl9FUlIgIk1DRTogbWFsbG9jIGJhbmtfZW50cnkgZmFpbGVkXG4iKTsKLSAgICAgICAgcmV0dXJu
IE5VTEw7Ci0gICAgfQotCi0gICAgSU5JVF9MSVNUX0hFQUQoJmVudHJ5LT5saXN0KTsKLSAgICBy
ZXR1cm4gZW50cnk7Ci19Ci0KLS8qIEZpbGwgZXJyb3IgYmFuayBpbmZvIGZvciAjdk1DRSBpbmpl
Y3Rpb24gYW5kIEdVRVNUIHZNQ0UjCi0gKiBNU1IgdmlydHVhbGl6YXRpb24gZGF0YQotICogMSkg
TG9nIGRvd24gaG93IG1hbnkgbnJfaW5qZWN0aW9ucyBvZiB0aGUgaW1wYWN0ZWQuCi0gKiAyKSBD
b3B5IE1DRSMgZXJyb3IgYmFuayB0byBpbXBhY3RlZCBET00gbm9kZSBsaXN0LAotICogICAgZm9y
IHZNQ0UjIE1TUnMgdmlydHVhbGl6YXRpb24KLSAqLwotaW50IGZpbGxfdm1zcl9kYXRhKHN0cnVj
dCBtY2luZm9fYmFuayAqbWNfYmFuaywgc3RydWN0IGRvbWFpbiAqZCwKLSAgICAgICAgICAgICAg
ICAgICB1aW50NjRfdCBnc3RhdHVzKSB7Ci0gICAgc3RydWN0IGJhbmtfZW50cnkgKmVudHJ5Owot
Ci0gICAgLyogVGhpcyBlcnJvciBiYW5rIGltcGFjdHMgb25lIGRvbWFpbiwgd2UgbmVlZCB0byBm
aWxsIGRvbWFpbiByZWxhdGVkCi0gICAgICogZGF0YSBmb3Igdk1DRSBNU1JzIHZpcnR1YWxpemF0
aW9uIGFuZCB2TUNFIyBpbmplY3Rpb24gKi8KICAgICBpZiAoIG1jX2JhbmstPm1jX2RvbWlkICE9
ICh1aW50MTZfdCl+MCApCiAgICAgewotICAgICAgICAvKiBGb3IgSFZNIGd1ZXN0LCBPbmx5IHdo
ZW4gZmlyc3Qgdk1DRSBpcyBjb25zdW1lZCBieSBIVk0gZ3Vlc3QKLSAgICAgICAgICogc3VjY2Vz
c2Z1bGx5LCB3aWxsIHdlIGdlbmVyZXRlIGFub3RoZXIgbm9kZSBhbmQgaW5qZWN0IGFub3RoZXIg
dk1DRS4KLSAgICAgICAgICovCi0gICAgICAgIGlmICggZC0+aXNfaHZtICYmIChkb21fdm1jZShk
KS0+bnJfaW5qZWN0aW9uID4gMCkgKQorICAgICAgICBpZiAoIHYtPmFyY2gudm1jZS5tY2dfc3Rh
dHVzICYgTUNHX1NUQVRVU19NQ0lQICkKICAgICAgICAgewotICAgICAgICAgICAgbWNlX3ByaW50
ayhNQ0VfUVVJRVQsICJNQ0U6IEhWTSBndWVzdCBoYXMgbm90IGhhbmRsZWQgcHJldmlvdXMiCisg
ICAgICAgICAgICBtY2VfcHJpbnRrKE1DRV9RVUlFVCwgIk1DRTogZ3Vlc3QgaGFzIG5vdCBoYW5k
bGVkIHByZXZpb3VzIgogICAgICAgICAgICAgICAgICAgICAgICAiIHZNQ0UgeWV0IVxuIik7CiAg
ICAgICAgICAgICByZXR1cm4gLTE7CiAgICAgICAgIH0KIAotICAgICAgICBlbnRyeSA9IGFsbG9j
X2JhbmtfZW50cnkoKTsKLSAgICAgICAgaWYgKCBlbnRyeSA9PSBOVUxMICkKLSAgICAgICAgICAg
IHJldHVybiAtMTsKKyAgICAgICAgc3Bpbl9sb2NrKCZ2LT5hcmNoLnZtY2UubG9jayk7CiAKLSAg
ICAgICAgZW50cnktPm1jaV9zdGF0dXMgPSBtY19iYW5rLT5tY19zdGF0dXM7Ci0gICAgICAgIGVu
dHJ5LT5tY2lfYWRkciA9IG1jX2JhbmstPm1jX2FkZHI7Ci0gICAgICAgIGVudHJ5LT5tY2lfbWlz
YyA9IG1jX2JhbmstPm1jX21pc2M7Ci0gICAgICAgIGVudHJ5LT5iYW5rID0gbWNfYmFuay0+bWNf
YmFuazsKKyAgICAgICAgdi0+YXJjaC52bWNlLm1jZ19zdGF0dXMgPSBnc3RhdHVzOworICAgICAg
ICAvKgorICAgICAgICAgKiAxLiBTa2lwIGJhbmsgMCB0byBhdm9pZCAnYmFuayAwIHF1aXJrJyBv
ZiBvbGQgcHJvY2Vzc29ycworICAgICAgICAgKiAyLiBGaWx0ZXIgTUNpX1NUQVRVUyBNU0NPRCBt
b2RlbCBzcGVjaWZpYyBlcnJvciBjb2RlIHRvIGd1ZXN0CisgICAgICAgICAqLworICAgICAgICB2
LT5hcmNoLnZtY2UuYmFua1sxXS5tY2lfc3RhdHVzID0gbWNfYmFuay0+bWNfc3RhdHVzICYKKyAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBNQ2lfU1RBVFVTX01T
Q09EX01BU0s7CisgICAgICAgIHYtPmFyY2gudm1jZS5iYW5rWzFdLm1jaV9hZGRyID0gbWNfYmFu
ay0+bWNfYWRkcjsKKyAgICAgICAgdi0+YXJjaC52bWNlLmJhbmtbMV0ubWNpX21pc2MgPSBtY19i
YW5rLT5tY19taXNjOwogCi0gICAgICAgIHNwaW5fbG9jaygmZG9tX3ZtY2UoZCktPmxvY2spOwot
ICAgICAgICAvKiBOZXcgZXJyb3IgTm9kZSwgaW5zZXJ0IHRvIHRoZSB0YWlsIG9mIHRoZSBwZXJf
ZG9tIGRhdGEgKi8KLSAgICAgICAgbGlzdF9hZGRfdGFpbCgmZW50cnktPmxpc3QsICZkb21fdm1j
ZShkKS0+aW1wYWN0X2hlYWRlcik7Ci0gICAgICAgIC8qIEZpbGwgTVNSIGdsb2JhbCBzdGF0dXMg
Ki8KLSAgICAgICAgZG9tX3ZtY2UoZCktPm1jZ19zdGF0dXMgPSBnc3RhdHVzOwotICAgICAgICAv
KiBOZXcgbm9kZSBpbXBhY3QgdGhlIGRvbWFpbiwgbmVlZCBhbm90aGVyIHZNQ0UjIGluamVjdGlv
biovCi0gICAgICAgIGRvbV92bWNlKGQpLT5ucl9pbmplY3Rpb24rKzsKLSAgICAgICAgc3Bpbl91
bmxvY2soJmRvbV92bWNlKGQpLT5sb2NrKTsKLQotICAgICAgICBtY2VfcHJpbnRrKE1DRV9WRVJC
T1NFLCJNQ0U6IEZvdW5kIGVycm9yIEBbQkFOSyVkICIKLSAgICAgICAgICAgICAgICAgICAic3Rh
dHVzICUiUFJJeDY0IiBhZGRyICUiUFJJeDY0IiBkb21pZCAlZF1cbiAiLAotICAgICAgICAgICAg
ICAgICAgIG1jX2JhbmstPm1jX2JhbmssIG1jX2JhbmstPm1jX3N0YXR1cywgbWNfYmFuay0+bWNf
YWRkciwKLSAgICAgICAgICAgICAgICAgICBtY19iYW5rLT5tY19kb21pZCk7CisgICAgICAgIHNw
aW5fdW5sb2NrKCZ2LT5hcmNoLnZtY2UubG9jayk7CiAgICAgfQogCiAgICAgcmV0dXJuIDA7CiB9
CiAKLSNpZiAwIC8qIGN1cnJlbnRseSB1bnVzZWQgKi8KLWludCB2bWNlX2RvbWFpbl9pbmplY3Qo
Ci0gICAgc3RydWN0IG1jaW5mb19iYW5rICpiYW5rLCBzdHJ1Y3QgZG9tYWluICpkLCBzdHJ1Y3Qg
bWNpbmZvX2dsb2JhbCAqZ2xvYmFsKQotewotICAgIGludCByZXQ7Ci0KLSAgICByZXQgPSBmaWxs
X3Ztc3JfZGF0YShiYW5rLCBkLCBnbG9iYWwtPm1jX2dzdGF0dXMpOwotICAgIGlmICggcmV0IDwg
MCApCi0gICAgICAgIHJldHVybiByZXQ7Ci0KLSAgICByZXR1cm4gaW5qZWN0X3ZtY2UoZCk7Ci19
Ci0jZW5kaWYKLQogc3RhdGljIGludCBpc19odm1fdm1jZV9yZWFkeShzdHJ1Y3QgbWNpbmZvX2Jh
bmsgKmJhbmssIHN0cnVjdCBkb21haW4gKmQpCiB7CiAgICAgc3RydWN0IHZjcHUgKnY7CmRpZmYg
LXIgZjc2Y2QzODE0NTllIHhlbi9hcmNoL3g4Ni9kb21haW4uYwotLS0gYS94ZW4vYXJjaC94ODYv
ZG9tYWluLmMJV2VkIFNlcCAxOSAyMTozMjoxNSAyMDEyICswODAwCisrKyBiL3hlbi9hcmNoL3g4
Ni9kb21haW4uYwlXZWQgU2VwIDE5IDIzOjIyOjU3IDIwMTIgKzA4MDAKQEAgLTU3MSw5ICs1NzEs
NiBAQAogCiAgICAgICAgIGlmICggKHJjID0gaW9tbXVfZG9tYWluX2luaXQoZCkpICE9IDAgKQog
ICAgICAgICAgICAgZ290byBmYWlsOwotCi0gICAgICAgIC8qIEZvciBHdWVzdCB2TUNFIE1TUnMg
dmlydHVhbGl6YXRpb24gKi8KLSAgICAgICAgdm1jZV9pbml0X21zcihkKTsKICAgICB9CiAKICAg
ICBpZiAoIGlzX2h2bV9kb21haW4oZCkgKQpAQCAtNjAwLDcgKzU5Nyw2IEBACiAKICBmYWlsOgog
ICAgIGQtPmlzX2R5aW5nID0gRE9NRFlJTkdfZGVhZDsKLSAgICB2bWNlX2Rlc3Ryb3lfbXNyKGQp
OwogICAgIGNsZWFudXBfZG9tYWluX2lycV9tYXBwaW5nKGQpOwogICAgIGZyZWVfeGVuaGVhcF9w
YWdlKGQtPnNoYXJlZF9pbmZvKTsKICAgICBpZiAoIHBhZ2luZ19pbml0aWFsaXNlZCApCkBAIC02
MjMsNyArNjE5LDYgQEAKICAgICBlbHNlCiAgICAgICAgIHhmcmVlKGQtPmFyY2gucHZfZG9tYWlu
LmU4MjApOwogCi0gICAgdm1jZV9kZXN0cm95X21zcihkKTsKICAgICBmcmVlX2RvbWFpbl9waXJx
cyhkKTsKICAgICBpZiAoICFpc19pZGxlX2RvbWFpbihkKSApCiAgICAgICAgIGlvbW11X2RvbWFp
bl9kZXN0cm95KGQpOwpkaWZmIC1yIGY3NmNkMzgxNDU5ZSB4ZW4vYXJjaC94ODYvZG9tY3RsLmMK
LS0tIGEveGVuL2FyY2gveDg2L2RvbWN0bC5jCVdlZCBTZXAgMTkgMjE6MzI6MTUgMjAxMiArMDgw
MAorKysgYi94ZW4vYXJjaC94ODYvZG9tY3RsLmMJV2VkIFNlcCAxOSAyMzoyMjo1NyAyMDEyICsw
ODAwCkBAIC0xMDI0LDcgKzEwMjQsNyBAQAogICAgICAgICAgICAgICAgIGV2Yy0+c3lzY2FsbDMy
X2NhbGxiYWNrX2VpcCAgICA9IDA7CiAgICAgICAgICAgICAgICAgZXZjLT5zeXNjYWxsMzJfZGlz
YWJsZXNfZXZlbnRzID0gMDsKICAgICAgICAgICAgIH0KLSAgICAgICAgICAgIGV2Yy0+bWNnX2Nh
cCA9IHYtPmFyY2gubWNnX2NhcDsKKyAgICAgICAgICAgIGV2Yy0+bWNnX2NhcCA9IHYtPmFyY2gu
dm1jZS5tY2dfY2FwOwogICAgICAgICB9CiAgICAgICAgIGVsc2UKICAgICAgICAgewpkaWZmIC1y
IGY3NmNkMzgxNDU5ZSB4ZW4vYXJjaC94ODYvdHJhcHMuYwotLS0gYS94ZW4vYXJjaC94ODYvdHJh
cHMuYwlXZWQgU2VwIDE5IDIxOjMyOjE1IDIwMTIgKzA4MDAKKysrIGIveGVuL2FyY2gveDg2L3Ry
YXBzLmMJV2VkIFNlcCAxOSAyMzoyMjo1NyAyMDEyICswODAwCkBAIC0zMTMzLDUwICszMTMzLDYg
QEAKICAgICAgICAgICAgICAgICBicmVhazsKICAgICBBU1NFUlQodHJhcCA8PSBWQ1BVX1RSQVBf
TEFTVCk7CiAKLSAgICAvKiBpbmplY3Qgdk1DRSB0byBQVl9HdWVzdCBpbmNsdWRpbmcgRE9NMC4g
Ki8KLSAgICBpZiAoIHRyYXAgPT0gVkNQVV9UUkFQX01DRSApCi0gICAgewotICAgICAgICBnZHBy
aW50ayhYRU5MT0dfREVCVUcsICJNQ0U6IFJldHVybiBmcm9tIHZNQ0UjIHRyYXAhXG4iKTsKLSAg
ICAgICAgaWYgKCBjdXJyLT52Y3B1X2lkID09IDAgKQotICAgICAgICB7Ci0gICAgICAgICAgICBz
dHJ1Y3QgZG9tYWluICpkID0gY3Vyci0+ZG9tYWluOwotCi0gICAgICAgICAgICBpZiAoICFkLT5h
cmNoLnZtY2FfbXNycy0+bnJfaW5qZWN0aW9uICkKLSAgICAgICAgICAgIHsKLSAgICAgICAgICAg
ICAgICBwcmludGsoWEVOTE9HX1dBUk5JTkcgIk1DRTogcmV0IGZyb20gdk1DRSMsICIKLSAgICAg
ICAgICAgICAgICAgICAgICAgIm5vIGluamVjdGlvbiBub2RlXG4iKTsKLSAgICAgICAgICAgICAg
ICBnb3RvIGVuZDsKLSAgICAgICAgICAgIH0KLQotICAgICAgICAgICAgZC0+YXJjaC52bWNhX21z
cnMtPm5yX2luamVjdGlvbi0tOwotICAgICAgICAgICAgaWYgKCAhbGlzdF9lbXB0eSgmZC0+YXJj
aC52bWNhX21zcnMtPmltcGFjdF9oZWFkZXIpICkKLSAgICAgICAgICAgIHsKLSAgICAgICAgICAg
ICAgICBzdHJ1Y3QgYmFua19lbnRyeSAqZW50cnk7Ci0KLSAgICAgICAgICAgICAgICBlbnRyeSA9
IGxpc3RfZW50cnkoZC0+YXJjaC52bWNhX21zcnMtPmltcGFjdF9oZWFkZXIubmV4dCwKLSAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgc3RydWN0IGJhbmtfZW50cnksIGxpc3QpOwot
ICAgICAgICAgICAgICAgIGdkcHJpbnRrKFhFTkxPR19ERUJVRywgIk1DRTogZGVsZXRlIGxhc3Qg
aW5qZWN0aW9uIG5vZGVcbiIpOwotICAgICAgICAgICAgICAgIGxpc3RfZGVsKCZlbnRyeS0+bGlz
dCk7Ci0gICAgICAgICAgICB9Ci0gICAgICAgICAgICBlbHNlCi0gICAgICAgICAgICAgICAgcHJp
bnRrKFhFTkxPR19FUlIgIk1DRTogZGlkbid0IGZvdW5kIGxhc3QgaW5qZWN0aW9uIG5vZGVcbiIp
OwotCi0gICAgICAgICAgICAvKiBmdXJ0aGVyIGluamVjdGlvbiAqLwotICAgICAgICAgICAgaWYg
KCBkLT5hcmNoLnZtY2FfbXNycy0+bnJfaW5qZWN0aW9uID4gMCAmJgotICAgICAgICAgICAgICAg
ICBndWVzdF9oYXNfdHJhcF9jYWxsYmFjayhkLCAwLCBUUkFQX21hY2hpbmVfY2hlY2spICYmCi0g
ICAgICAgICAgICAgICAgICF0ZXN0X2FuZF9zZXRfYm9vbChjdXJyLT5tY2VfcGVuZGluZykgKQot
ICAgICAgICAgICAgewotICAgICAgICAgICAgICAgIGludCBjcHUgPSBzbXBfcHJvY2Vzc29yX2lk
KCk7Ci0KLSAgICAgICAgICAgICAgICBjcHVtYXNrX2NvcHkoY3Vyci0+Y3B1X2FmZmluaXR5X3Rt
cCwgY3Vyci0+Y3B1X2FmZmluaXR5KTsKLSAgICAgICAgICAgICAgICBwcmludGsoWEVOTE9HX0RF
QlVHICJNQ0U6IENQVSVkIHNldCBhZmZpbml0eSwgb2xkICVkXG4iLAotICAgICAgICAgICAgICAg
ICAgICAgICBjcHUsIGN1cnItPnByb2Nlc3Nvcik7Ci0gICAgICAgICAgICAgICAgdmNwdV9zZXRf
YWZmaW5pdHkoY3VyciwgY3B1bWFza19vZihjcHUpKTsKLSAgICAgICAgICAgIH0KLSAgICAgICAg
fQotICAgIH0KLQotZW5kOgogICAgIC8qIFJlc3RvcmUgcHJldmlvdXMgYXN5bmNocm9ub3VzIGV4
Y2VwdGlvbiBtYXNrLiAqLwogICAgIGN1cnItPmFzeW5jX2V4Y2VwdGlvbl9tYXNrID0gY3Vyci0+
YXN5bmNfZXhjZXB0aW9uX3N0YXRlKHRyYXApLm9sZF9tYXNrOwogfQpkaWZmIC1yIGY3NmNkMzgx
NDU5ZSB4ZW4vaW5jbHVkZS9hc20teDg2L2RvbWFpbi5oCi0tLSBhL3hlbi9pbmNsdWRlL2FzbS14
ODYvZG9tYWluLmgJV2VkIFNlcCAxOSAyMTozMjoxNSAyMDEyICswODAwCisrKyBiL3hlbi9pbmNs
dWRlL2FzbS14ODYvZG9tYWluLmgJV2VkIFNlcCAxOSAyMzoyMjo1NyAyMDEyICswODAwCkBAIC0y
OTYsOSArMjk2LDYgQEAKIAogICAgIHN0cnVjdCBQSVRTdGF0ZSB2cGl0OwogCi0gICAgLyogRm9y
IEd1ZXN0IHZNQ0EgaGFuZGxpbmcgKi8KLSAgICBzdHJ1Y3QgZG9tYWluX21jYV9tc3JzICp2bWNh
X21zcnM7Ci0KICAgICAvKiBUU0MgbWFuYWdlbWVudCAoZW11bGF0aW9uLCBwdiwgc2NhbGluZywg
c3RhdHMpICovCiAgICAgaW50IHRzY19tb2RlOyAgICAgICAgICAgIC8qIHNlZSBpbmNsdWRlL2Fz
bS14ODYvdGltZS5oICovCiAgICAgYm9vbF90IHZ0c2M7ICAgICAgICAgICAgIC8qIHRzYyBpcyBl
bXVsYXRlZCAobWF5IGNoYW5nZSBhZnRlciBtaWdyYXRlKSAqLwpAQCAtNDM4LDggKzQzNSw4IEBA
CiAgICAgICogYW5kIHRodXMgc2hvdWxkIGJlIHNhdmVkL3Jlc3RvcmVkLiAqLwogICAgIGJvb2xf
dCBub25sYXp5X3hzdGF0ZV91c2VkOwogCi0gICAgdWludDY0X3QgbWNnX2NhcDsKLSAgICAKKyAg
ICBzdHJ1Y3Qgdm1jZSB2bWNlOworCiAgICAgc3RydWN0IHBhZ2luZ192Y3B1IHBhZ2luZzsKIAog
ICAgIHVpbnQzMl90IGdkYnN4X3ZjcHVfZXZlbnQ7CmRpZmYgLXIgZjc2Y2QzODE0NTllIHhlbi9p
bmNsdWRlL2FzbS14ODYvbWNlLmgKLS0tIGEveGVuL2luY2x1ZGUvYXNtLXg4Ni9tY2UuaAlXZWQg
U2VwIDE5IDIxOjMyOjE1IDIwMTIgKzA4MDAKKysrIGIveGVuL2luY2x1ZGUvYXNtLXg4Ni9tY2Uu
aAlXZWQgU2VwIDE5IDIzOjIyOjU3IDIwMTIgKzA4MDAKQEAgLTMsMjggKzMsNTAgQEAKICNpZm5k
ZWYgX1hFTl9YODZfTUNFX0gKICNkZWZpbmUgX1hFTl9YODZfTUNFX0gKIAotLyogVGhpcyBlbnRy
eSBpcyBmb3IgcmVjb3JkaW5nIGJhbmsgbm9kZXMgZm9yIHRoZSBpbXBhY3RlZCBkb21haW4sCi0g
KiBwdXQgaW50byBpbXBhY3RfaGVhZGVyIGxpc3QuICovCi1zdHJ1Y3QgYmFua19lbnRyeSB7Ci0g
ICAgc3RydWN0IGxpc3RfaGVhZCBsaXN0OwotICAgIHVpbnQxNl90IGJhbms7CisvKgorICogRW11
bGFsdGUgMiBiYW5rcyBmb3IgZ3Vlc3QKKyAqIEJhbmswOiByZXNlcnZlZCBmb3IgJ2JhbmswIHF1
aXJrJyBvY2N1ciBhdCBzb21lIHZlcnkgb2xkIHByb2Nlc3NvcnM6CisgKiAgIDEpLiBJbnRlbCBj
cHUgd2hvc2UgZmFtaWx5LW1vZGVsIHZhbHVlIDwgMDYtMUE7CisgKiAgIDIpLiBBTUQgSzcKKyAq
IEJhbmsxOiB1c2VkIHRvIHRyYW5zZmVyIGVycm9yIGluZm8gdG8gZ3Vlc3QKKyAqLworI2RlZmlu
ZSBHVUVTVF9NQ19CQU5LX05VTSAyCisKKy8qCisgKiBNQ0dfU0VSX1A6ICBzb2Z0d2FyZSBlcnJv
ciByZWNvdmVyeSBzdXBwb3J0ZWQKKyAqIE1DR19URVNfUDogIHRvIGF2b2lkIE1DaV9zdGF0dXMg
Yml0NTY6NTMgbW9kZWwgc3BlY2lmaWMKKyAqIE1DR19DTUNJX1A6IGV4cG9zZSBDTUNJIGNhcGFi
aWxpdHkgYnV0IG5ldmVyIHJlYWxseSBpbmplY3QgaXQgdG8gZ3Vlc3QsCisgKiAgICAgICAgICAg
ICBmb3Igc2FrZSBvZiBwZXJmb3JtYW5jZSBzaW5jZSBndWVzdCBub3QgcG9sbGluZyBwZXJpb2Rp
Y2FsbHkKKyAqLworI2RlZmluZSBJTlRFTF9HVUVTVF9NQ0dfQ0FQIChNQ0dfU0VSX1AgfAlcCisg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgIE1DR19URVNfUCB8CVwKKyAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgTUNHX0NNQ0lfUCB8CVwKKyAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgR1VFU1RfTUNfQkFOS19OVU0pCisKKyNkZWZpbmUgQU1EX0dVRVNUX01DR19DQVAgKE1DR19T
RVJfUCB8CQlcCisgICAgICAgICAgICAgICAgICAgICAgICAgICBHVUVTVF9NQ19CQU5LX05VTSkK
KworLyogRmlsdGVyIE1TQ09EIG1vZGVsIHNwZWNpZmljIGVycm9yIGNvZGUgdG8gZ3Vlc3QgKi8K
KyNkZWZpbmUgTUNpX1NUQVRVU19NU0NPRF9NQVNLICh+KDB4ZmZmZlVMTCA8PCAxNikpCisKKy8q
IE5vIG1jaV9jdGwgc2luY2UgaXQgc3RpY2sgYWxsIDEncyAqLworc3RydWN0IHZtY2VfYmFuayB7
CiAgICAgdWludDY0X3QgbWNpX3N0YXR1czsKICAgICB1aW50NjRfdCBtY2lfYWRkcjsKICAgICB1
aW50NjRfdCBtY2lfbWlzYzsKKyAgICB1aW50NjRfdCBtY2lfY3RsMjsKIH07CiAKLXN0cnVjdCBk
b21haW5fbWNhX21zcnMKLXsKLSAgICAvKiBHdWVzdCBzaG91bGQgbm90IGNoYW5nZSBiZWxvdyB2
YWx1ZXMgYWZ0ZXIgRE9NIGJvb3QgdXAgKi8KKy8qIE5vIG1jZ19jdGwgc2luY2UgaXQgbm90IGV4
cG9zZSB0byBndWVzdCAqLworc3RydWN0IHZtY2UgeworICAgIHVpbnQ2NF90IG1jZ19jYXA7CiAg
ICAgdWludDY0X3QgbWNnX3N0YXR1czsKLSAgICB1aW50MTZfdCBucl9pbmplY3Rpb247Ci0gICAg
c3RydWN0IGxpc3RfaGVhZCBpbXBhY3RfaGVhZGVyOworICAgIHN0cnVjdCB2bWNlX2JhbmsgYmFu
a1tHVUVTVF9NQ19CQU5LX05VTV07CisKICAgICBzcGlubG9ja190IGxvY2s7CiB9OwogCiAvKiBH
dWVzdCB2TUNFIE1TUnMgdmlydHVhbGl6YXRpb24gKi8KLWV4dGVybiBpbnQgdm1jZV9pbml0X21z
cihzdHJ1Y3QgZG9tYWluICpkKTsKLWV4dGVybiB2b2lkIHZtY2VfZGVzdHJveV9tc3Ioc3RydWN0
IGRvbWFpbiAqZCk7CiBleHRlcm4gdm9pZCB2bWNlX2luaXRfdmNwdShzdHJ1Y3QgdmNwdSAqKTsK
IGV4dGVybiBpbnQgdm1jZV9yZXN0b3JlX3ZjcHUoc3RydWN0IHZjcHUgKiwgdWludDY0X3QgY2Fw
cyk7CiBleHRlcm4gaW50IHZtY2Vfd3Jtc3IodWludDMyX3QgbXNyLCB1aW50NjRfdCB2YWwpOwo=

--_002_DE8DF0795D48FD4CA783C40EC8292335330546SHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 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_DE8DF0795D48FD4CA783C40EC8292335330546SHSMSX101ccrcorpi_--


From xen-devel-bounces@lists.xen.org Wed Sep 19 07:59:11 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Sep 2012 07: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 1TEFBT-0003pZ-RX; Wed, 19 Sep 2012 07:58:59 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jinsong.liu@intel.com>) id 1TEFBR-0003pJ-T3
	for xen-devel@lists.xensource.com; Wed, 19 Sep 2012 07:58:58 +0000
Received: from [85.158.138.51:6733] by server-5.bemta-3.messagelabs.com id
	8A/9A-13133-14B79505; Wed, 19 Sep 2012 07:58:57 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1348041530!23196587!1
X-Originating-IP: [143.182.124.21]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMjEgPT4gMjA0MzE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31179 invoked from network); 19 Sep 2012 07:58:51 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (143.182.124.21)
	by server-12.tower-174.messagelabs.com with SMTP;
	19 Sep 2012 07:58:51 -0000
Received: from azsmga001.ch.intel.com ([10.2.17.19])
	by azsmga101.ch.intel.com with ESMTP; 19 Sep 2012 00:58:49 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.80,447,1344236400"; d="scan'208";a="194426979"
Received: from fmsmsx105.amr.corp.intel.com ([10.19.9.36])
	by azsmga001.ch.intel.com with ESMTP; 19 Sep 2012 00:58:47 -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; Wed, 19 Sep 2012 00:58:46 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.239]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.175]) with mapi id
	14.01.0355.002; Wed, 19 Sep 2012 15:58:44 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: Jan Beulich <JBeulich@suse.com>, "xen-devel@lists.xensource.com"
	<xen-devel@lists.xensource.com>
Thread-Topic: [PATCH 1/5] Xen/MCE: vMCE emulation
Thread-Index: Ac2WPJa8f3GY9vZdQTCABNxgHB75SQ==
Date: Wed, 19 Sep 2012 07:58:43 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC8292335330546@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_DE8DF0795D48FD4CA783C40EC8292335330546SHSMSX101ccrcorpi_"
MIME-Version: 1.0
Cc: Christoph Egger <Christoph.Egger@amd.com>, "keir@xen.org" <keir@xen.org>,
	"Ian.Campbell@citrix.com" <Ian.Campbell@citrix.com>
Subject: [Xen-devel] [PATCH 1/5] Xen/MCE: vMCE emulation
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--_002_DE8DF0795D48FD4CA783C40EC8292335330546SHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Xen/MCE: vMCE emulation

This patch provides virtual MCE support to guest. It emulates a simple
and clean MCE MSRs interface to guest by faking caps to guest if needed
and masking caps if unnecessary:
1. Providing a well-defined MCG_CAP to guest, filter out un-necessary caps =
and provide only guest needed caps;
2. Disabling MCG_CTL to avoid model specific;
3. Sticking all 1's to MCi_CTL to guest to avoid model specific;
4. Enabling CMCI cap but never really inject to guest to prevent polling pe=
riodically;
5. Masking MSCOD field of MCi_STATUS to avoid model specific;
6. Keeping natural semantics by per-vcpu instead of per-domain variables;
7. Using bank1 and reserving bank0 to work around 'bank0 quirk' of some ver=
y old processors;
8. Cleaning some vMCE# injection logic which shared by Intel and AMD but us=
eless under new vMCE implement;
9. Keeping compatilbe w/ old xen version which has been backported to SLES1=
1 SP2, so that old vMCE would not blocked when migrate to new vMCE;

Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>

diff -r f76cd381459e xen/arch/x86/cpu/mcheck/mce.h
--- a/xen/arch/x86/cpu/mcheck/mce.h	Wed Sep 19 21:32:15 2012 +0800
+++ b/xen/arch/x86/cpu/mcheck/mce.h	Wed Sep 19 23:22:57 2012 +0800
@@ -169,15 +169,13 @@
 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
 static inline int mce_vendor_bank_msr(const struct vcpu *v, uint32_t msr)
 {
     switch (boot_cpu_data.x86_vendor) {
     case X86_VENDOR_INTEL:
         if (msr >=3D MSR_IA32_MC0_CTL2 &&
-            msr < MSR_IA32_MCx_CTL2(v->arch.mcg_cap & MCG_CAP_COUNT) )
+            msr < MSR_IA32_MCx_CTL2(v->arch.vmce.mcg_cap & MCG_CAP_COUNT) =
)
             return 1;
         break;
     case X86_VENDOR_AMD:
@@ -195,7 +193,7 @@
 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(v->arch.mcg_cap & MCG_CAP_COUNT)) ||
+         msr < MSR_IA32_MCx_CTL(v->arch.vmce.mcg_cap & MCG_CAP_COUNT)) ||
          mce_vendor_bank_msr(v, msr) )
         return 1;
     return 0;
diff -r f76cd381459e xen/arch/x86/cpu/mcheck/mce_intel.c
--- a/xen/arch/x86/cpu/mcheck/mce_intel.c	Wed Sep 19 21:32:15 2012 +0800
+++ b/xen/arch/x86/cpu/mcheck/mce_intel.c	Wed Sep 19 23:22:57 2012 +0800
@@ -982,14 +982,15 @@
 /* intel specific MCA MSR */
 int intel_mce_wrmsr(struct vcpu *v, uint32_t msr, uint64_t val)
 {
+    unsigned int bank =3D msr - MSR_IA32_MC0_CTL2;
     int ret =3D 0;
=20
-    if ( msr >=3D MSR_IA32_MC0_CTL2 &&
-         msr < MSR_IA32_MCx_CTL2(v->arch.mcg_cap & MCG_CAP_COUNT) )
+    if ( bank < GUEST_MC_BANK_NUM )
     {
-        mce_printk(MCE_QUIET, "We have disabled CMCI capability, "
-                 "Guest should not write this MSR!\n");
-         ret =3D 1;
+        v->arch.vmce.bank[bank].mci_ctl2 =3D val;
+        mce_printk(MCE_VERBOSE, "MCE: wr MC%u_CTL2 %"PRIx64"\n",
+                   bank, val);
+        ret =3D 1;
     }
=20
     return ret;
@@ -997,13 +998,14 @@
=20
 int intel_mce_rdmsr(const struct vcpu *v, uint32_t msr, uint64_t *val)
 {
+    unsigned int bank =3D msr - MSR_IA32_MC0_CTL2;
     int ret =3D 0;
=20
-    if ( msr >=3D MSR_IA32_MC0_CTL2 &&
-         msr < MSR_IA32_MCx_CTL2(v->arch.mcg_cap & MCG_CAP_COUNT) )
+    if ( bank < GUEST_MC_BANK_NUM )
     {
-        mce_printk(MCE_QUIET, "We have disabled CMCI capability, "
-                 "Guest should not read this MSR!\n");
+        *val =3D v->arch.vmce.bank[bank].mci_ctl2;
+        mce_printk(MCE_VERBOSE, "MCE: rdmsr MC%u_CTL2 0x%"PRIx64"\n",
+                   bank, *val);
         ret =3D 1;
     }
=20
diff -r f76cd381459e xen/arch/x86/cpu/mcheck/vmce.c
--- a/xen/arch/x86/cpu/mcheck/vmce.c	Wed Sep 19 21:32:15 2012 +0800
+++ b/xen/arch/x86/cpu/mcheck/vmce.c	Wed Sep 19 23:22:57 2012 +0800
@@ -1,5 +1,22 @@
 /*
- * vmce.c - virtual MCE support
+ * vmce.c - provide software emulated vMCE support to guest
+ *
+ * Copyright (C) 2010, 2011 Jiang, Yunhong <yunhong.jiang@intel.com>
+ * Copyright (C) 2012, 2013 Liu, Jinsong <jinsong.liu@intel.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * 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  U=
SA
  */
=20
 #include <xen/init.h>
@@ -19,67 +36,55 @@
 #include "mce.h"
 #include "x86_mca.h"
=20
-/*
- * Emulate 2 banks for guest
- * Bank0: reserved for 'bank0 quirk' occur at some very old processors:
- *   1). Intel cpu whose family-model value < 06-1A;
- *   2). AMD K7
- * Bank1: used to transfer error info to guest
- */
-#define GUEST_BANK_NUM 2
-#define GUEST_MCG_CAP (MCG_TES_P | MCG_SER_P | GUEST_BANK_NUM)
-
-#define dom_vmce(x)   ((x)->arch.vmca_msrs)
-
-int vmce_init_msr(struct domain *d)
-{
-    dom_vmce(d) =3D xmalloc(struct domain_mca_msrs);
-    if ( !dom_vmce(d) )
-        return -ENOMEM;
-
-    dom_vmce(d)->mcg_status =3D 0x0;
-    dom_vmce(d)->nr_injection =3D 0;
-
-    INIT_LIST_HEAD(&dom_vmce(d)->impact_header);
-    spin_lock_init(&dom_vmce(d)->lock);
-
-    return 0;
-}
-
-void vmce_destroy_msr(struct domain *d)
-{
-    if ( !dom_vmce(d) )
-        return;
-    xfree(dom_vmce(d));
-    dom_vmce(d) =3D NULL;
-}
-
 void vmce_init_vcpu(struct vcpu *v)
 {
-    v->arch.mcg_cap =3D GUEST_MCG_CAP;
+    int i;
+
+    /* global MCA MSRs init */
+    if ( boot_cpu_data.x86_vendor =3D=3D X86_VENDOR_INTEL )
+        v->arch.vmce.mcg_cap =3D INTEL_GUEST_MCG_CAP;
+    else
+        v->arch.vmce.mcg_cap =3D AMD_GUEST_MCG_CAP;
+
+    v->arch.vmce.mcg_status =3D 0;
+
+    /* per-bank MCA MSRs init */
+    for ( i =3D 0; i < GUEST_MC_BANK_NUM; i++ )
+        memset(&v->arch.vmce.bank[i], 0, sizeof(struct vmce_bank));
+
+    spin_lock_init(&v->arch.vmce.lock);
 }
=20
 int vmce_restore_vcpu(struct vcpu *v, uint64_t caps)
 {
-    if ( caps & ~GUEST_MCG_CAP & ~MCG_CAP_COUNT & ~MCG_CTL_P )
+    uint64_t guest_mcg_cap;
+
+    if ( boot_cpu_data.x86_vendor =3D=3D X86_VENDOR_INTEL )
+        guest_mcg_cap =3D INTEL_GUEST_MCG_CAP;
+    else
+        guest_mcg_cap =3D AMD_GUEST_MCG_CAP;
+
+    if ( caps & ~guest_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, GUEST_MCG_CAP & ~MCG_CAP_COUNT);
+                v->vcpu_id, guest_mcg_cap & ~MCG_CAP_COUNT);
         return -EPERM;
     }
=20
-    v->arch.mcg_cap =3D caps;
+    v->arch.vmce.mcg_cap =3D caps;
     return 0;
 }
=20
-static int bank_mce_rdmsr(const struct vcpu *v, uint32_t msr, uint64_t *va=
l)
+/*
+ * For historic version reason, bank number may greater than GUEST_MC_BANK=
_NUM,
+ * when migratie from old vMCE version to new vMCE.
+ */
+static int bank_mce_rdmsr(struct vcpu *v, uint32_t msr, uint64_t *val)
 {
     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
     *val =3D 0;
=20
@@ -92,46 +97,33 @@
                    bank, *val);
         break;
     case MSR_IA32_MC0_STATUS:
-        /* Only error bank is read. Non-error banks simply return. */
-        if ( !list_empty(&vmce->impact_header) )
+        if ( bank < GUEST_MC_BANK_NUM )
         {
-            entry =3D list_entry(vmce->impact_header.next,
-                               struct bank_entry, list);
-            if ( entry->bank =3D=3D bank )
-            {
-                *val =3D entry->mci_status;
+            *val =3D v->arch.vmce.bank[bank].mci_status;
+            if ( *val )
                 mce_printk(MCE_VERBOSE,
-                           "MCE: rd MC%u_STATUS in vMCE# context "
-                           "value 0x%"PRIx64"\n", bank, *val);
-            }
+                           "MCE: rdmsr MC%u_STATUS in vMCE# context "
+                           "0x%"PRIx64"\n", bank, *val);
         }
         break;
     case MSR_IA32_MC0_ADDR:
-        if ( !list_empty(&vmce->impact_header) )
+        if ( bank < GUEST_MC_BANK_NUM )
         {
-            entry =3D list_entry(vmce->impact_header.next,
-                               struct bank_entry, list);
-            if ( entry->bank =3D=3D bank )
-            {
-                *val =3D entry->mci_addr;
+            *val =3D v->arch.vmce.bank[bank].mci_addr;
+            if ( *val )
                 mce_printk(MCE_VERBOSE,
                            "MCE: rdmsr MC%u_ADDR in vMCE# context "
                            "0x%"PRIx64"\n", bank, *val);
-            }
         }
         break;
     case MSR_IA32_MC0_MISC:
-        if ( !list_empty(&vmce->impact_header) )
+        if ( bank < GUEST_MC_BANK_NUM )
         {
-            entry =3D list_entry(vmce->impact_header.next,
-                               struct bank_entry, list);
-            if ( entry->bank =3D=3D bank )
-            {
-                *val =3D entry->mci_misc;
+            *val =3D v->arch.vmce.bank[bank].mci_misc;
+            if ( *val )
                 mce_printk(MCE_VERBOSE,
-                           "MCE: rd MC%u_MISC in vMCE# context "
+                           "MCE: rdmsr MC%u_MISC in vMCE# context "
                            "0x%"PRIx64"\n", bank, *val);
-            }
         }
         break;
     default:
@@ -157,56 +149,50 @@
  */
 int vmce_rdmsr(uint32_t msr, uint64_t *val)
 {
-    const struct vcpu *cur =3D current;
-    struct domain_mca_msrs *vmce =3D dom_vmce(cur->domain);
+    struct vcpu *cur =3D current;
     int ret =3D 1;
=20
     *val =3D 0;
=20
-    spin_lock(&vmce->lock);
+    spin_lock(&cur->arch.vmce.lock);
=20
     switch ( msr )
     {
     case MSR_IA32_MCG_STATUS:
-        *val =3D vmce->mcg_status;
+        *val =3D cur->arch.vmce.mcg_status;
         if (*val)
             mce_printk(MCE_VERBOSE,
                        "MCE: rdmsr MCG_STATUS 0x%"PRIx64"\n", *val);
         break;
     case MSR_IA32_MCG_CAP:
-        *val =3D cur->arch.mcg_cap;
-        mce_printk(MCE_VERBOSE, "MCE: rdmsr MCG_CAP 0x%"PRIx64"\n",
-                   *val);
+        *val =3D cur->arch.vmce.mcg_cap;
+        mce_printk(MCE_VERBOSE, "MCE: rdmsr MCG_CAP 0x%"PRIx64"\n", *val);
         break;
     case MSR_IA32_MCG_CTL:
-        /* Stick all 1's when CTL support, and 0's when no CTL support */
-        if ( cur->arch.mcg_cap & MCG_CTL_P )
-            *val =3D ~0ULL;
-        mce_printk(MCE_VERBOSE, "MCE: rdmsr MCG_CTL 0x%"PRIx64"\n", *val);
+        if ( cur->arch.vmce.mcg_cap & MCG_CTL_P )
+        {
+            *val =3D ~0UL;
+            mce_printk(MCE_VERBOSE, "MCE: rdmsr MCG_CTL 0x%"PRIx64"\n", *v=
al);
+        }
         break;
     default:
         ret =3D mce_bank_msr(cur, msr) ? bank_mce_rdmsr(cur, msr, val) : 0=
;
         break;
     }
=20
-    spin_unlock(&vmce->lock);
+    spin_unlock(&cur->arch.vmce.lock);
+
     return ret;
 }
=20
+/*
+ * For historic version reason, bank number may greater than GUEST_MC_BANK=
_NUM,
+ * when migratie from old vMCE version to new vMCE.
+ */
 static int bank_mce_wrmsr(struct vcpu *v, u32 msr, u64 val)
 {
     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;
-
-    /* Give the first entry of the list, it corresponds to current
-     * vMCE# injection. When vMCE# is finished processing by the
-     * the guest, this node will be deleted.
-     * Only error bank is written. Non-error banks simply return.
-     */
-    if ( !list_empty(&vmce->impact_header) )
-        entry =3D list_entry(vmce->impact_header.next, struct bank_entry, =
list);
=20
     switch ( msr & (MSR_IA32_MC0_CTL | 3) )
     {
@@ -217,50 +203,46 @@
          */
         break;
     case MSR_IA32_MC0_STATUS:
-        if ( entry && (entry->bank =3D=3D bank) )
+        if ( val )
         {
-            entry->mci_status =3D val;
-            mce_printk(MCE_VERBOSE,
-                       "MCE: wr MC%u_STATUS %"PRIx64" in vMCE#\n",
+            mce_printk(MCE_QUIET,
+                       "MCE: wr MC%u_STATUS w/ non-zero cause #GP\n", bank=
);
+            ret =3D -1;
+        }
+        if ( bank < GUEST_MC_BANK_NUM )
+        {
+            v->arch.vmce.bank[bank].mci_status =3D val;
+            mce_printk(MCE_VERBOSE, "MCE: wr MC%u_STATUS %"PRIx64"\n",
                        bank, val);
         }
-        else
-            mce_printk(MCE_VERBOSE,
-                       "MCE: wr MC%u_STATUS %"PRIx64"\n", bank, val);
         break;
     case MSR_IA32_MC0_ADDR:
-        if ( !~val )
+        if ( val )
         {
             mce_printk(MCE_QUIET,
-                       "MCE: wr MC%u_ADDR with all 1s will cause #GP\n", b=
ank);
+                       "MCE: wr MC%u_ADDR w/ non-zero cause #GP\n", bank);
             ret =3D -1;
         }
-        else if ( entry && (entry->bank =3D=3D bank) )
+        else if ( bank < GUEST_MC_BANK_NUM )
         {
-            entry->mci_addr =3D val;
-            mce_printk(MCE_VERBOSE,
-                       "MCE: wr MC%u_ADDR %"PRIx64" in vMCE#\n", bank, val=
);
-        }
-        else
+            v->arch.vmce.bank[bank].mci_addr =3D val;
             mce_printk(MCE_VERBOSE,
                        "MCE: wr MC%u_ADDR %"PRIx64"\n", bank, val);
+        }
         break;
     case MSR_IA32_MC0_MISC:
-        if ( !~val )
+        if ( val )
         {
             mce_printk(MCE_QUIET,
-                       "MCE: wr MC%u_MISC with all 1s will cause #GP\n", b=
ank);
+                       "MCE: wr MC%u_MISC w/ non-zero cause #GP\n", bank);
             ret =3D -1;
         }
-        else if ( entry && (entry->bank =3D=3D bank) )
+        else if ( bank < GUEST_MC_BANK_NUM )
         {
-            entry->mci_misc =3D val;
-            mce_printk(MCE_VERBOSE,
-                       "MCE: wr MC%u_MISC %"PRIx64" in vMCE#\n", bank, val=
);
-        }
-        else
+            v->arch.vmce.bank[bank].mci_misc =3D val;
             mce_printk(MCE_VERBOSE,
                        "MCE: wr MC%u_MISC %"PRIx64"\n", bank, val);
+        }
         break;
     default:
         switch ( boot_cpu_data.x86_vendor )
@@ -286,52 +268,33 @@
 int vmce_wrmsr(u32 msr, u64 val)
 {
     struct vcpu *cur =3D current;
-    struct bank_entry *entry =3D NULL;
-    struct domain_mca_msrs *vmce =3D dom_vmce(cur->domain);
     int ret =3D 1;
=20
-    spin_lock(&vmce->lock);
+    spin_lock(&cur->arch.vmce.lock);
=20
     switch ( msr )
     {
     case MSR_IA32_MCG_CTL:
+        /* If MCG_CTL exist then stick to all 1's. If not exist then ignor=
e */
         break;
     case MSR_IA32_MCG_STATUS:
-        vmce->mcg_status =3D val;
+        cur->arch.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 ( is_hvm_vcpu(cur) && (vmce->nr_injection > 0) )
-        {
-            vmce->nr_injection--; /* Should be 0 */
-            if ( !list_empty(&vmce->impact_header) )
-            {
-                entry =3D list_entry(vmce->impact_header.next,
-                                   struct bank_entry, list);
-                if ( entry->mci_status & MCi_STATUS_VAL )
-                    mce_printk(MCE_QUIET, "MCE: MCi_STATUS MSR should have=
 "
-                               "been cleared before write MCG_STATUS MSR\n=
");
-
-                mce_printk(MCE_QUIET, "MCE: Delete HVM last injection "
-                           "Node, nr_injection %u\n",
-                           vmce->nr_injection);
-                list_del(&entry->list);
-                xfree(entry);
-            }
-            else
-                mce_printk(MCE_QUIET, "MCE: Not found HVM guest"
-                           " last injection Node, something Wrong!\n");
-        }
         break;
     case MSR_IA32_MCG_CAP:
-        mce_printk(MCE_QUIET, "MCE: MCG_CAP is read-only\n");
-        ret =3D -1;
+        /*
+         * According to Intel SDM, IA32_MCG_CAP is a read-only register,
+         * the effect of writing to the IA32_MCG_CAP is undefined. Here we
+         * treat writing as 'write not change'. Guest would not surprise.
+         */
+        mce_printk(MCE_QUIET, "MCE: MCG_CAP is read only and write not cha=
nge\n");
         break;
     default:
         ret =3D mce_bank_msr(cur, msr) ? bank_mce_wrmsr(cur, msr, val) : 0=
;
         break;
     }
=20
-    spin_unlock(&vmce->lock);
+    spin_unlock(&cur->arch.vmce.lock);
     return ret;
 }
=20
@@ -342,7 +305,7 @@
=20
     for_each_vcpu( d, v ) {
         struct hvm_vmce_vcpu ctxt =3D {
-            .caps =3D v->arch.mcg_cap
+            .caps =3D v->arch.vmce.mcg_cap
         };
=20
         err =3D hvm_save_entry(VMCE_VCPU, v->vcpu_id, h, &ctxt);
@@ -422,93 +385,38 @@
     return 0;
 }
=20
-/* 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
- * virtualization. When one vMCE# injection is finished processing
- * processed by guest, the corresponding node will be deleted.
- * This node list is for GUEST vMCE# MSRS virtualization.
- */
-static struct bank_entry* alloc_bank_entry(void)
+int fill_vmsr_data(struct mcinfo_bank *mc_bank, struct domain *d,
+                   uint64_t gstatus)
 {
-    struct bank_entry *entry;
+    struct vcpu *v =3D d->vcpu[0];
=20
-    entry =3D xzalloc(struct bank_entry);
-    if ( entry =3D=3D NULL )
-    {
-        printk(KERN_ERR "MCE: malloc bank_entry failed\n");
-        return NULL;
-    }
-
-    INIT_LIST_HEAD(&entry->list);
-    return entry;
-}
-
-/* Fill error bank info for #vMCE injection and GUEST vMCE#
- * MSR virtualization data
- * 1) Log down how many nr_injections of the impacted.
- * 2) Copy MCE# error bank to impacted DOM node list,
- *    for vMCE# MSRs virtualization
- */
-int fill_vmsr_data(struct mcinfo_bank *mc_bank, struct domain *d,
-                   uint64_t gstatus) {
-    struct bank_entry *entry;
-
-    /* This error bank impacts one domain, we need to fill domain related
-     * data for vMCE MSRs virtualization and vMCE# injection */
     if ( mc_bank->mc_domid !=3D (uint16_t)~0 )
     {
-        /* For HVM guest, Only when first vMCE is consumed by HVM guest
-         * successfully, will we generete another node and inject another =
vMCE.
-         */
-        if ( d->is_hvm && (dom_vmce(d)->nr_injection > 0) )
+        if ( v->arch.vmce.mcg_status & MCG_STATUS_MCIP )
         {
-            mce_printk(MCE_QUIET, "MCE: HVM guest has not handled previous=
"
+            mce_printk(MCE_QUIET, "MCE: guest has not handled previous"
                        " vMCE yet!\n");
             return -1;
         }
=20
-        entry =3D alloc_bank_entry();
-        if ( entry =3D=3D NULL )
-            return -1;
+        spin_lock(&v->arch.vmce.lock);
=20
-        entry->mci_status =3D mc_bank->mc_status;
-        entry->mci_addr =3D mc_bank->mc_addr;
-        entry->mci_misc =3D mc_bank->mc_misc;
-        entry->bank =3D mc_bank->mc_bank;
+        v->arch.vmce.mcg_status =3D gstatus;
+        /*
+         * 1. Skip bank 0 to avoid 'bank 0 quirk' of old processors
+         * 2. Filter MCi_STATUS MSCOD model specific error code to guest
+         */
+        v->arch.vmce.bank[1].mci_status =3D mc_bank->mc_status &
+                                              MCi_STATUS_MSCOD_MASK;
+        v->arch.vmce.bank[1].mci_addr =3D mc_bank->mc_addr;
+        v->arch.vmce.bank[1].mci_misc =3D mc_bank->mc_misc;
=20
-        spin_lock(&dom_vmce(d)->lock);
-        /* New error Node, insert to the tail of the per_dom data */
-        list_add_tail(&entry->list, &dom_vmce(d)->impact_header);
-        /* Fill MSR global status */
-        dom_vmce(d)->mcg_status =3D gstatus;
-        /* New node impact the domain, need another vMCE# injection*/
-        dom_vmce(d)->nr_injection++;
-        spin_unlock(&dom_vmce(d)->lock);
-
-        mce_printk(MCE_VERBOSE,"MCE: Found error @[BANK%d "
-                   "status %"PRIx64" addr %"PRIx64" domid %d]\n ",
-                   mc_bank->mc_bank, mc_bank->mc_status, mc_bank->mc_addr,
-                   mc_bank->mc_domid);
+        spin_unlock(&v->arch.vmce.lock);
     }
=20
     return 0;
 }
=20
-#if 0 /* currently unused */
-int vmce_domain_inject(
-    struct mcinfo_bank *bank, struct domain *d, struct mcinfo_global *glob=
al)
-{
-    int ret;
-
-    ret =3D fill_vmsr_data(bank, d, global->mc_gstatus);
-    if ( ret < 0 )
-        return ret;
-
-    return inject_vmce(d);
-}
-#endif
-
 static int is_hvm_vmce_ready(struct mcinfo_bank *bank, struct domain *d)
 {
     struct vcpu *v;
diff -r f76cd381459e xen/arch/x86/domain.c
--- a/xen/arch/x86/domain.c	Wed Sep 19 21:32:15 2012 +0800
+++ b/xen/arch/x86/domain.c	Wed Sep 19 23:22:57 2012 +0800
@@ -571,9 +571,6 @@
=20
         if ( (rc =3D iommu_domain_init(d)) !=3D 0 )
             goto fail;
-
-        /* For Guest vMCE MSRs virtualization */
-        vmce_init_msr(d);
     }
=20
     if ( is_hvm_domain(d) )
@@ -600,7 +597,6 @@
=20
  fail:
     d->is_dying =3D DOMDYING_dead;
-    vmce_destroy_msr(d);
     cleanup_domain_irq_mapping(d);
     free_xenheap_page(d->shared_info);
     if ( paging_initialised )
@@ -623,7 +619,6 @@
     else
         xfree(d->arch.pv_domain.e820);
=20
-    vmce_destroy_msr(d);
     free_domain_pirqs(d);
     if ( !is_idle_domain(d) )
         iommu_domain_destroy(d);
diff -r f76cd381459e xen/arch/x86/domctl.c
--- a/xen/arch/x86/domctl.c	Wed Sep 19 21:32:15 2012 +0800
+++ b/xen/arch/x86/domctl.c	Wed Sep 19 23:22:57 2012 +0800
@@ -1024,7 +1024,7 @@
                 evc->syscall32_callback_eip    =3D 0;
                 evc->syscall32_disables_events =3D 0;
             }
-            evc->mcg_cap =3D v->arch.mcg_cap;
+            evc->mcg_cap =3D v->arch.vmce.mcg_cap;
         }
         else
         {
diff -r f76cd381459e xen/arch/x86/traps.c
--- a/xen/arch/x86/traps.c	Wed Sep 19 21:32:15 2012 +0800
+++ b/xen/arch/x86/traps.c	Wed Sep 19 23:22:57 2012 +0800
@@ -3133,50 +3133,6 @@
                 break;
     ASSERT(trap <=3D VCPU_TRAP_LAST);
=20
-    /* inject vMCE to PV_Guest including DOM0. */
-    if ( trap =3D=3D VCPU_TRAP_MCE )
-    {
-        gdprintk(XENLOG_DEBUG, "MCE: Return from vMCE# trap!\n");
-        if ( curr->vcpu_id =3D=3D 0 )
-        {
-            struct domain *d =3D curr->domain;
-
-            if ( !d->arch.vmca_msrs->nr_injection )
-            {
-                printk(XENLOG_WARNING "MCE: ret from vMCE#, "
-                       "no injection node\n");
-                goto end;
-            }
-
-            d->arch.vmca_msrs->nr_injection--;
-            if ( !list_empty(&d->arch.vmca_msrs->impact_header) )
-            {
-                struct bank_entry *entry;
-
-                entry =3D list_entry(d->arch.vmca_msrs->impact_header.next=
,
-                                   struct bank_entry, list);
-                gdprintk(XENLOG_DEBUG, "MCE: delete last injection node\n"=
);
-                list_del(&entry->list);
-            }
-            else
-                printk(XENLOG_ERR "MCE: didn't found last injection node\n=
");
-
-            /* further injection */
-            if ( d->arch.vmca_msrs->nr_injection > 0 &&
-                 guest_has_trap_callback(d, 0, TRAP_machine_check) &&
-                 !test_and_set_bool(curr->mce_pending) )
-            {
-                int cpu =3D smp_processor_id();
-
-                cpumask_copy(curr->cpu_affinity_tmp, curr->cpu_affinity);
-                printk(XENLOG_DEBUG "MCE: CPU%d set affinity, old %d\n",
-                       cpu, curr->processor);
-                vcpu_set_affinity(curr, cpumask_of(cpu));
-            }
-        }
-    }
-
-end:
     /* Restore previous asynchronous exception mask. */
     curr->async_exception_mask =3D curr->async_exception_state(trap).old_m=
ask;
 }
diff -r f76cd381459e xen/include/asm-x86/domain.h
--- a/xen/include/asm-x86/domain.h	Wed Sep 19 21:32:15 2012 +0800
+++ b/xen/include/asm-x86/domain.h	Wed Sep 19 23:22:57 2012 +0800
@@ -296,9 +296,6 @@
=20
     struct PITState vpit;
=20
-    /* For Guest vMCA handling */
-    struct domain_mca_msrs *vmca_msrs;
-
     /* TSC management (emulation, pv, scaling, stats) */
     int tsc_mode;            /* see include/asm-x86/time.h */
     bool_t vtsc;             /* tsc is emulated (may change after migrate)=
 */
@@ -438,8 +435,8 @@
      * and thus should be saved/restored. */
     bool_t nonlazy_xstate_used;
=20
-    uint64_t mcg_cap;
-   =20
+    struct vmce vmce;
+
     struct paging_vcpu paging;
=20
     uint32_t gdbsx_vcpu_event;
diff -r f76cd381459e xen/include/asm-x86/mce.h
--- a/xen/include/asm-x86/mce.h	Wed Sep 19 21:32:15 2012 +0800
+++ b/xen/include/asm-x86/mce.h	Wed Sep 19 23:22:57 2012 +0800
@@ -3,28 +3,50 @@
 #ifndef _XEN_X86_MCE_H
 #define _XEN_X86_MCE_H
=20
-/* This entry is for recording bank nodes for the impacted domain,
- * put into impact_header list. */
-struct bank_entry {
-    struct list_head list;
-    uint16_t bank;
+/*
+ * Emulalte 2 banks for guest
+ * Bank0: reserved for 'bank0 quirk' occur at some very old processors:
+ *   1). Intel cpu whose family-model value < 06-1A;
+ *   2). AMD K7
+ * Bank1: used to transfer error info to guest
+ */
+#define GUEST_MC_BANK_NUM 2
+
+/*
+ * MCG_SER_P:  software error recovery supported
+ * MCG_TES_P:  to avoid MCi_status bit56:53 model specific
+ * MCG_CMCI_P: expose CMCI capability but never really inject it to guest,
+ *             for sake of performance since guest not polling periodicall=
y
+ */
+#define INTEL_GUEST_MCG_CAP (MCG_SER_P |	\
+                             MCG_TES_P |	\
+                             MCG_CMCI_P |	\
+                             GUEST_MC_BANK_NUM)
+
+#define AMD_GUEST_MCG_CAP (MCG_SER_P |		\
+                           GUEST_MC_BANK_NUM)
+
+/* Filter MSCOD model specific error code to guest */
+#define MCi_STATUS_MSCOD_MASK (~(0xffffULL << 16))
+
+/* No mci_ctl since it stick all 1's */
+struct vmce_bank {
     uint64_t mci_status;
     uint64_t mci_addr;
     uint64_t mci_misc;
+    uint64_t mci_ctl2;
 };
=20
-struct domain_mca_msrs
-{
-    /* Guest should not change below values after DOM boot up */
+/* No mcg_ctl since it not expose to guest */
+struct vmce {
+    uint64_t mcg_cap;
     uint64_t mcg_status;
-    uint16_t nr_injection;
-    struct list_head impact_header;
+    struct vmce_bank bank[GUEST_MC_BANK_NUM];
+
     spinlock_t lock;
 };
=20
 /* 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);=

--_002_DE8DF0795D48FD4CA783C40EC8292335330546SHSMSX101ccrcorpi_
Content-Type: application/octet-stream; name="1_vmce_emulation.patch"
Content-Description: 1_vmce_emulation.patch
Content-Disposition: attachment; filename="1_vmce_emulation.patch";
	size=27245; creation-date="Wed, 19 Sep 2012 07:39:51 GMT";
	modification-date="Wed, 19 Sep 2012 15:22:58 GMT"
Content-Transfer-Encoding: base64

WGVuL01DRTogdk1DRSBlbXVsYXRpb24KClRoaXMgcGF0Y2ggcHJvdmlkZXMgdmlydHVhbCBNQ0Ug
c3VwcG9ydCB0byBndWVzdC4gSXQgZW11bGF0ZXMgYSBzaW1wbGUKYW5kIGNsZWFuIE1DRSBNU1Jz
IGludGVyZmFjZSB0byBndWVzdCBieSBmYWtpbmcgY2FwcyB0byBndWVzdCBpZiBuZWVkZWQKYW5k
IG1hc2tpbmcgY2FwcyBpZiB1bm5lY2Vzc2FyeToKMS4gUHJvdmlkaW5nIGEgd2VsbC1kZWZpbmVk
IE1DR19DQVAgdG8gZ3Vlc3QsIGZpbHRlciBvdXQgdW4tbmVjZXNzYXJ5IGNhcHMgYW5kIHByb3Zp
ZGUgb25seSBndWVzdCBuZWVkZWQgY2FwczsKMi4gRGlzYWJsaW5nIE1DR19DVEwgdG8gYXZvaWQg
bW9kZWwgc3BlY2lmaWM7CjMuIFN0aWNraW5nIGFsbCAxJ3MgdG8gTUNpX0NUTCB0byBndWVzdCB0
byBhdm9pZCBtb2RlbCBzcGVjaWZpYzsKNC4gRW5hYmxpbmcgQ01DSSBjYXAgYnV0IG5ldmVyIHJl
YWxseSBpbmplY3QgdG8gZ3Vlc3QgdG8gcHJldmVudCBwb2xsaW5nIHBlcmlvZGljYWxseTsKNS4g
TWFza2luZyBNU0NPRCBmaWVsZCBvZiBNQ2lfU1RBVFVTIHRvIGF2b2lkIG1vZGVsIHNwZWNpZmlj
Owo2LiBLZWVwaW5nIG5hdHVyYWwgc2VtYW50aWNzIGJ5IHBlci12Y3B1IGluc3RlYWQgb2YgcGVy
LWRvbWFpbiB2YXJpYWJsZXM7CjcuIFVzaW5nIGJhbmsxIGFuZCByZXNlcnZpbmcgYmFuazAgdG8g
d29yayBhcm91bmQgJ2JhbmswIHF1aXJrJyBvZiBzb21lIHZlcnkgb2xkIHByb2Nlc3NvcnM7Cjgu
IENsZWFuaW5nIHNvbWUgdk1DRSMgaW5qZWN0aW9uIGxvZ2ljIHdoaWNoIHNoYXJlZCBieSBJbnRl
bCBhbmQgQU1EIGJ1dCB1c2VsZXNzIHVuZGVyIG5ldyB2TUNFIGltcGxlbWVudDsKOS4gS2VlcGlu
ZyBjb21wYXRpbGJlIHcvIG9sZCB4ZW4gdmVyc2lvbiB3aGljaCBoYXMgYmVlbiBiYWNrcG9ydGVk
IHRvIFNMRVMxMSBTUDIsIHNvIHRoYXQgb2xkIHZNQ0Ugd291bGQgbm90IGJsb2NrZWQgd2hlbiBt
aWdyYXRlIHRvIG5ldyB2TUNFOwoKU2lnbmVkLW9mZi1ieTogTGl1LCBKaW5zb25nIDxqaW5zb25n
LmxpdUBpbnRlbC5jb20+CgpkaWZmIC1yIGY3NmNkMzgxNDU5ZSB4ZW4vYXJjaC94ODYvY3B1L21j
aGVjay9tY2UuaAotLS0gYS94ZW4vYXJjaC94ODYvY3B1L21jaGVjay9tY2UuaAlXZWQgU2VwIDE5
IDIxOjMyOjE1IDIwMTIgKzA4MDAKKysrIGIveGVuL2FyY2gveDg2L2NwdS9tY2hlY2svbWNlLmgJ
V2VkIFNlcCAxOSAyMzoyMjo1NyAyMDEyICswODAwCkBAIC0xNjksMTUgKzE2OSwxMyBAQAogaW50
IGZpbGxfdm1zcl9kYXRhKHN0cnVjdCBtY2luZm9fYmFuayAqbWNfYmFuaywgc3RydWN0IGRvbWFp
biAqZCwKICAgICB1aW50NjRfdCBnc3RhdHVzKTsKIGludCBpbmplY3Rfdm1jZShzdHJ1Y3QgZG9t
YWluICpkKTsKLWludCB2bWNlX2RvbWFpbl9pbmplY3Qoc3RydWN0IG1jaW5mb19iYW5rICpiYW5r
LCBzdHJ1Y3QgZG9tYWluICpkLAotICAgIHN0cnVjdCBtY2luZm9fZ2xvYmFsICpnbG9iYWwpOwog
CiBzdGF0aWMgaW5saW5lIGludCBtY2VfdmVuZG9yX2JhbmtfbXNyKGNvbnN0IHN0cnVjdCB2Y3B1
ICp2LCB1aW50MzJfdCBtc3IpCiB7CiAgICAgc3dpdGNoIChib290X2NwdV9kYXRhLng4Nl92ZW5k
b3IpIHsKICAgICBjYXNlIFg4Nl9WRU5ET1JfSU5URUw6CiAgICAgICAgIGlmIChtc3IgPj0gTVNS
X0lBMzJfTUMwX0NUTDIgJiYKLSAgICAgICAgICAgIG1zciA8IE1TUl9JQTMyX01DeF9DVEwyKHYt
PmFyY2gubWNnX2NhcCAmIE1DR19DQVBfQ09VTlQpICkKKyAgICAgICAgICAgIG1zciA8IE1TUl9J
QTMyX01DeF9DVEwyKHYtPmFyY2gudm1jZS5tY2dfY2FwICYgTUNHX0NBUF9DT1VOVCkgKQogICAg
ICAgICAgICAgcmV0dXJuIDE7CiAgICAgICAgIGJyZWFrOwogICAgIGNhc2UgWDg2X1ZFTkRPUl9B
TUQ6CkBAIC0xOTUsNyArMTkzLDcgQEAKIHN0YXRpYyBpbmxpbmUgaW50IG1jZV9iYW5rX21zcihj
b25zdCBzdHJ1Y3QgdmNwdSAqdiwgdWludDMyX3QgbXNyKQogewogICAgIGlmICggKG1zciA+PSBN
U1JfSUEzMl9NQzBfQ1RMICYmCi0gICAgICAgICAgbXNyIDwgTVNSX0lBMzJfTUN4X0NUTCh2LT5h
cmNoLm1jZ19jYXAgJiBNQ0dfQ0FQX0NPVU5UKSkgfHwKKyAgICAgICAgIG1zciA8IE1TUl9JQTMy
X01DeF9DVEwodi0+YXJjaC52bWNlLm1jZ19jYXAgJiBNQ0dfQ0FQX0NPVU5UKSkgfHwKICAgICAg
ICAgIG1jZV92ZW5kb3JfYmFua19tc3IodiwgbXNyKSApCiAgICAgICAgIHJldHVybiAxOwogICAg
IHJldHVybiAwOwpkaWZmIC1yIGY3NmNkMzgxNDU5ZSB4ZW4vYXJjaC94ODYvY3B1L21jaGVjay9t
Y2VfaW50ZWwuYwotLS0gYS94ZW4vYXJjaC94ODYvY3B1L21jaGVjay9tY2VfaW50ZWwuYwlXZWQg
U2VwIDE5IDIxOjMyOjE1IDIwMTIgKzA4MDAKKysrIGIveGVuL2FyY2gveDg2L2NwdS9tY2hlY2sv
bWNlX2ludGVsLmMJV2VkIFNlcCAxOSAyMzoyMjo1NyAyMDEyICswODAwCkBAIC05ODIsMTQgKzk4
MiwxNSBAQAogLyogaW50ZWwgc3BlY2lmaWMgTUNBIE1TUiAqLwogaW50IGludGVsX21jZV93cm1z
cihzdHJ1Y3QgdmNwdSAqdiwgdWludDMyX3QgbXNyLCB1aW50NjRfdCB2YWwpCiB7CisgICAgdW5z
aWduZWQgaW50IGJhbmsgPSBtc3IgLSBNU1JfSUEzMl9NQzBfQ1RMMjsKICAgICBpbnQgcmV0ID0g
MDsKIAotICAgIGlmICggbXNyID49IE1TUl9JQTMyX01DMF9DVEwyICYmCi0gICAgICAgICBtc3Ig
PCBNU1JfSUEzMl9NQ3hfQ1RMMih2LT5hcmNoLm1jZ19jYXAgJiBNQ0dfQ0FQX0NPVU5UKSApCisg
ICAgaWYgKCBiYW5rIDwgR1VFU1RfTUNfQkFOS19OVU0gKQogICAgIHsKLSAgICAgICAgbWNlX3By
aW50ayhNQ0VfUVVJRVQsICJXZSBoYXZlIGRpc2FibGVkIENNQ0kgY2FwYWJpbGl0eSwgIgotICAg
ICAgICAgICAgICAgICAiR3Vlc3Qgc2hvdWxkIG5vdCB3cml0ZSB0aGlzIE1TUiFcbiIpOwotICAg
ICAgICAgcmV0ID0gMTsKKyAgICAgICAgdi0+YXJjaC52bWNlLmJhbmtbYmFua10ubWNpX2N0bDIg
PSB2YWw7CisgICAgICAgIG1jZV9wcmludGsoTUNFX1ZFUkJPU0UsICJNQ0U6IHdyIE1DJXVfQ1RM
MiAlIlBSSXg2NCJcbiIsCisgICAgICAgICAgICAgICAgICAgYmFuaywgdmFsKTsKKyAgICAgICAg
cmV0ID0gMTsKICAgICB9CiAKICAgICByZXR1cm4gcmV0OwpAQCAtOTk3LDEzICs5OTgsMTQgQEAK
IAogaW50IGludGVsX21jZV9yZG1zcihjb25zdCBzdHJ1Y3QgdmNwdSAqdiwgdWludDMyX3QgbXNy
LCB1aW50NjRfdCAqdmFsKQogeworICAgIHVuc2lnbmVkIGludCBiYW5rID0gbXNyIC0gTVNSX0lB
MzJfTUMwX0NUTDI7CiAgICAgaW50IHJldCA9IDA7CiAKLSAgICBpZiAoIG1zciA+PSBNU1JfSUEz
Ml9NQzBfQ1RMMiAmJgotICAgICAgICAgbXNyIDwgTVNSX0lBMzJfTUN4X0NUTDIodi0+YXJjaC5t
Y2dfY2FwICYgTUNHX0NBUF9DT1VOVCkgKQorICAgIGlmICggYmFuayA8IEdVRVNUX01DX0JBTktf
TlVNICkKICAgICB7Ci0gICAgICAgIG1jZV9wcmludGsoTUNFX1FVSUVULCAiV2UgaGF2ZSBkaXNh
YmxlZCBDTUNJIGNhcGFiaWxpdHksICIKLSAgICAgICAgICAgICAgICAgIkd1ZXN0IHNob3VsZCBu
b3QgcmVhZCB0aGlzIE1TUiFcbiIpOworICAgICAgICAqdmFsID0gdi0+YXJjaC52bWNlLmJhbmtb
YmFua10ubWNpX2N0bDI7CisgICAgICAgIG1jZV9wcmludGsoTUNFX1ZFUkJPU0UsICJNQ0U6IHJk
bXNyIE1DJXVfQ1RMMiAweCUiUFJJeDY0IlxuIiwKKyAgICAgICAgICAgICAgICAgICBiYW5rLCAq
dmFsKTsKICAgICAgICAgcmV0ID0gMTsKICAgICB9CiAKZGlmZiAtciBmNzZjZDM4MTQ1OWUgeGVu
L2FyY2gveDg2L2NwdS9tY2hlY2svdm1jZS5jCi0tLSBhL3hlbi9hcmNoL3g4Ni9jcHUvbWNoZWNr
L3ZtY2UuYwlXZWQgU2VwIDE5IDIxOjMyOjE1IDIwMTIgKzA4MDAKKysrIGIveGVuL2FyY2gveDg2
L2NwdS9tY2hlY2svdm1jZS5jCVdlZCBTZXAgMTkgMjM6MjI6NTcgMjAxMiArMDgwMApAQCAtMSw1
ICsxLDIyIEBACiAvKgotICogdm1jZS5jIC0gdmlydHVhbCBNQ0Ugc3VwcG9ydAorICogdm1jZS5j
IC0gcHJvdmlkZSBzb2Z0d2FyZSBlbXVsYXRlZCB2TUNFIHN1cHBvcnQgdG8gZ3Vlc3QKKyAqCisg
KiBDb3B5cmlnaHQgKEMpIDIwMTAsIDIwMTEgSmlhbmcsIFl1bmhvbmcgPHl1bmhvbmcuamlhbmdA
aW50ZWwuY29tPgorICogQ29weXJpZ2h0IChDKSAyMDEyLCAyMDEzIExpdSwgSmluc29uZyA8amlu
c29uZy5saXVAaW50ZWwuY29tPgorICoKKyAqIFRoaXMgcHJvZ3JhbSBpcyBmcmVlIHNvZnR3YXJl
OyB5b3UgY2FuIHJlZGlzdHJpYnV0ZSBpdCBhbmQvb3IgbW9kaWZ5CisgKiBpdCB1bmRlciB0aGUg
dGVybXMgb2YgdGhlIEdOVSBHZW5lcmFsIFB1YmxpYyBMaWNlbnNlIGFzIHB1Ymxpc2hlZCBieQor
ICogdGhlIEZyZWUgU29mdHdhcmUgRm91bmRhdGlvbjsgZWl0aGVyIHZlcnNpb24gMiBvZiB0aGUg
TGljZW5zZSwgb3IKKyAqIChhdCB5b3VyIG9wdGlvbikgYW55IGxhdGVyIHZlcnNpb24uCisgKgor
ICogVGhpcyBwcm9ncmFtIGlzIGRpc3RyaWJ1dGVkIGluIHRoZSBob3BlIHRoYXQgaXQgd2lsbCBi
ZSB1c2VmdWwsCisgKiBidXQgV0lUSE9VVCBBTlkgV0FSUkFOVFk7IHdpdGhvdXQgZXZlbiB0aGUg
aW1wbGllZCB3YXJyYW50eSBvZgorICogTUVSQ0hBTlRBQklMSVRZIG9yIEZJVE5FU1MgRk9SIEEg
UEFSVElDVUxBUiBQVVJQT1NFLiAgU2VlIHRoZQorICogR05VIEdlbmVyYWwgUHVibGljIExpY2Vu
c2UgZm9yIG1vcmUgZGV0YWlscy4KKyAqCisgKiBZb3Ugc2hvdWxkIGhhdmUgcmVjZWl2ZWQgYSBj
b3B5IG9mIHRoZSBHTlUgR2VuZXJhbCBQdWJsaWMgTGljZW5zZQorICogYWxvbmcgd2l0aCB0aGlz
IHByb2dyYW07IGlmIG5vdCwgd3JpdGUgdG8gdGhlIEZyZWUgU29mdHdhcmUKKyAqIEZvdW5kYXRp
b24sIEluYy4sIDU5IFRlbXBsZSBQbGFjZSwgU3VpdGUgMzMwLCBCb3N0b24sIE1BICAwMjExMS0x
MzA3ICBVU0EKICAqLwogCiAjaW5jbHVkZSA8eGVuL2luaXQuaD4KQEAgLTE5LDY3ICszNiw1NSBA
QAogI2luY2x1ZGUgIm1jZS5oIgogI2luY2x1ZGUgIng4Nl9tY2EuaCIKIAotLyoKLSAqIEVtdWxh
dGUgMiBiYW5rcyBmb3IgZ3Vlc3QKLSAqIEJhbmswOiByZXNlcnZlZCBmb3IgJ2JhbmswIHF1aXJr
JyBvY2N1ciBhdCBzb21lIHZlcnkgb2xkIHByb2Nlc3NvcnM6Ci0gKiAgIDEpLiBJbnRlbCBjcHUg
d2hvc2UgZmFtaWx5LW1vZGVsIHZhbHVlIDwgMDYtMUE7Ci0gKiAgIDIpLiBBTUQgSzcKLSAqIEJh
bmsxOiB1c2VkIHRvIHRyYW5zZmVyIGVycm9yIGluZm8gdG8gZ3Vlc3QKLSAqLwotI2RlZmluZSBH
VUVTVF9CQU5LX05VTSAyCi0jZGVmaW5lIEdVRVNUX01DR19DQVAgKE1DR19URVNfUCB8IE1DR19T
RVJfUCB8IEdVRVNUX0JBTktfTlVNKQotCi0jZGVmaW5lIGRvbV92bWNlKHgpICAgKCh4KS0+YXJj
aC52bWNhX21zcnMpCi0KLWludCB2bWNlX2luaXRfbXNyKHN0cnVjdCBkb21haW4gKmQpCi17Ci0g
ICAgZG9tX3ZtY2UoZCkgPSB4bWFsbG9jKHN0cnVjdCBkb21haW5fbWNhX21zcnMpOwotICAgIGlm
ICggIWRvbV92bWNlKGQpICkKLSAgICAgICAgcmV0dXJuIC1FTk9NRU07Ci0KLSAgICBkb21fdm1j
ZShkKS0+bWNnX3N0YXR1cyA9IDB4MDsKLSAgICBkb21fdm1jZShkKS0+bnJfaW5qZWN0aW9uID0g
MDsKLQotICAgIElOSVRfTElTVF9IRUFEKCZkb21fdm1jZShkKS0+aW1wYWN0X2hlYWRlcik7Ci0g
ICAgc3Bpbl9sb2NrX2luaXQoJmRvbV92bWNlKGQpLT5sb2NrKTsKLQotICAgIHJldHVybiAwOwot
fQotCi12b2lkIHZtY2VfZGVzdHJveV9tc3Ioc3RydWN0IGRvbWFpbiAqZCkKLXsKLSAgICBpZiAo
ICFkb21fdm1jZShkKSApCi0gICAgICAgIHJldHVybjsKLSAgICB4ZnJlZShkb21fdm1jZShkKSk7
Ci0gICAgZG9tX3ZtY2UoZCkgPSBOVUxMOwotfQotCiB2b2lkIHZtY2VfaW5pdF92Y3B1KHN0cnVj
dCB2Y3B1ICp2KQogewotICAgIHYtPmFyY2gubWNnX2NhcCA9IEdVRVNUX01DR19DQVA7CisgICAg
aW50IGk7CisKKyAgICAvKiBnbG9iYWwgTUNBIE1TUnMgaW5pdCAqLworICAgIGlmICggYm9vdF9j
cHVfZGF0YS54ODZfdmVuZG9yID09IFg4Nl9WRU5ET1JfSU5URUwgKQorICAgICAgICB2LT5hcmNo
LnZtY2UubWNnX2NhcCA9IElOVEVMX0dVRVNUX01DR19DQVA7CisgICAgZWxzZQorICAgICAgICB2
LT5hcmNoLnZtY2UubWNnX2NhcCA9IEFNRF9HVUVTVF9NQ0dfQ0FQOworCisgICAgdi0+YXJjaC52
bWNlLm1jZ19zdGF0dXMgPSAwOworCisgICAgLyogcGVyLWJhbmsgTUNBIE1TUnMgaW5pdCAqLwor
ICAgIGZvciAoIGkgPSAwOyBpIDwgR1VFU1RfTUNfQkFOS19OVU07IGkrKyApCisgICAgICAgIG1l
bXNldCgmdi0+YXJjaC52bWNlLmJhbmtbaV0sIDAsIHNpemVvZihzdHJ1Y3Qgdm1jZV9iYW5rKSk7
CisKKyAgICBzcGluX2xvY2tfaW5pdCgmdi0+YXJjaC52bWNlLmxvY2spOwogfQogCiBpbnQgdm1j
ZV9yZXN0b3JlX3ZjcHUoc3RydWN0IHZjcHUgKnYsIHVpbnQ2NF90IGNhcHMpCiB7Ci0gICAgaWYg
KCBjYXBzICYgfkdVRVNUX01DR19DQVAgJiB+TUNHX0NBUF9DT1VOVCAmIH5NQ0dfQ1RMX1AgKQor
ICAgIHVpbnQ2NF90IGd1ZXN0X21jZ19jYXA7CisKKyAgICBpZiAoIGJvb3RfY3B1X2RhdGEueDg2
X3ZlbmRvciA9PSBYODZfVkVORE9SX0lOVEVMICkKKyAgICAgICAgZ3Vlc3RfbWNnX2NhcCA9IElO
VEVMX0dVRVNUX01DR19DQVA7CisgICAgZWxzZQorICAgICAgICBndWVzdF9tY2dfY2FwID0gQU1E
X0dVRVNUX01DR19DQVA7CisKKyAgICBpZiAoIGNhcHMgJiB+Z3Vlc3RfbWNnX2NhcCAmIH5NQ0df
Q0FQX0NPVU5UICYgfk1DR19DVExfUCApCiAgICAgewogICAgICAgICBkcHJpbnRrKFhFTkxPR19H
X0VSUiwgIiVzIHJlc3RvcmU6IHVuc3VwcG9ydGVkIE1DQSBjYXBhYmlsaXRpZXMiCiAgICAgICAg
ICAgICAgICAgIiAlIyIgUFJJeDY0ICIgZm9yIGQlZDp2JXUgKHN1cHBvcnRlZDogJSNMeClcbiIs
CiAgICAgICAgICAgICAgICAgaXNfaHZtX3ZjcHUodikgPyAiSFZNIiA6ICJQViIsIGNhcHMsIHYt
PmRvbWFpbi0+ZG9tYWluX2lkLAotICAgICAgICAgICAgICAgIHYtPnZjcHVfaWQsIEdVRVNUX01D
R19DQVAgJiB+TUNHX0NBUF9DT1VOVCk7CisgICAgICAgICAgICAgICAgdi0+dmNwdV9pZCwgZ3Vl
c3RfbWNnX2NhcCAmIH5NQ0dfQ0FQX0NPVU5UKTsKICAgICAgICAgcmV0dXJuIC1FUEVSTTsKICAg
ICB9CiAKLSAgICB2LT5hcmNoLm1jZ19jYXAgPSBjYXBzOworICAgIHYtPmFyY2gudm1jZS5tY2df
Y2FwID0gY2FwczsKICAgICByZXR1cm4gMDsKIH0KIAotc3RhdGljIGludCBiYW5rX21jZV9yZG1z
cihjb25zdCBzdHJ1Y3QgdmNwdSAqdiwgdWludDMyX3QgbXNyLCB1aW50NjRfdCAqdmFsKQorLyoK
KyAqIEZvciBoaXN0b3JpYyB2ZXJzaW9uIHJlYXNvbiwgYmFuayBudW1iZXIgbWF5IGdyZWF0ZXIg
dGhhbiBHVUVTVF9NQ19CQU5LX05VTSwKKyAqIHdoZW4gbWlncmF0aWUgZnJvbSBvbGQgdk1DRSB2
ZXJzaW9uIHRvIG5ldyB2TUNFLgorICovCitzdGF0aWMgaW50IGJhbmtfbWNlX3JkbXNyKHN0cnVj
dCB2Y3B1ICp2LCB1aW50MzJfdCBtc3IsIHVpbnQ2NF90ICp2YWwpCiB7CiAgICAgaW50IHJldCA9
IDE7CiAgICAgdW5zaWduZWQgaW50IGJhbmsgPSAobXNyIC0gTVNSX0lBMzJfTUMwX0NUTCkgLyA0
OwotICAgIHN0cnVjdCBkb21haW5fbWNhX21zcnMgKnZtY2UgPSBkb21fdm1jZSh2LT5kb21haW4p
OwotICAgIHN0cnVjdCBiYW5rX2VudHJ5ICplbnRyeTsKIAogICAgICp2YWwgPSAwOwogCkBAIC05
Miw0NiArOTcsMzMgQEAKICAgICAgICAgICAgICAgICAgICBiYW5rLCAqdmFsKTsKICAgICAgICAg
YnJlYWs7CiAgICAgY2FzZSBNU1JfSUEzMl9NQzBfU1RBVFVTOgotICAgICAgICAvKiBPbmx5IGVy
cm9yIGJhbmsgaXMgcmVhZC4gTm9uLWVycm9yIGJhbmtzIHNpbXBseSByZXR1cm4uICovCi0gICAg
ICAgIGlmICggIWxpc3RfZW1wdHkoJnZtY2UtPmltcGFjdF9oZWFkZXIpICkKKyAgICAgICAgaWYg
KCBiYW5rIDwgR1VFU1RfTUNfQkFOS19OVU0gKQogICAgICAgICB7Ci0gICAgICAgICAgICBlbnRy
eSA9IGxpc3RfZW50cnkodm1jZS0+aW1wYWN0X2hlYWRlci5uZXh0LAotICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgIHN0cnVjdCBiYW5rX2VudHJ5LCBsaXN0KTsKLSAgICAgICAgICAgIGlm
ICggZW50cnktPmJhbmsgPT0gYmFuayApCi0gICAgICAgICAgICB7Ci0gICAgICAgICAgICAgICAg
KnZhbCA9IGVudHJ5LT5tY2lfc3RhdHVzOworICAgICAgICAgICAgKnZhbCA9IHYtPmFyY2gudm1j
ZS5iYW5rW2JhbmtdLm1jaV9zdGF0dXM7CisgICAgICAgICAgICBpZiAoICp2YWwgKQogICAgICAg
ICAgICAgICAgIG1jZV9wcmludGsoTUNFX1ZFUkJPU0UsCi0gICAgICAgICAgICAgICAgICAgICAg
ICAgICAiTUNFOiByZCBNQyV1X1NUQVRVUyBpbiB2TUNFIyBjb250ZXh0ICIKLSAgICAgICAgICAg
ICAgICAgICAgICAgICAgICJ2YWx1ZSAweCUiUFJJeDY0IlxuIiwgYmFuaywgKnZhbCk7Ci0gICAg
ICAgICAgICB9CisgICAgICAgICAgICAgICAgICAgICAgICAgICAiTUNFOiByZG1zciBNQyV1X1NU
QVRVUyBpbiB2TUNFIyBjb250ZXh0ICIKKyAgICAgICAgICAgICAgICAgICAgICAgICAgICIweCUi
UFJJeDY0IlxuIiwgYmFuaywgKnZhbCk7CiAgICAgICAgIH0KICAgICAgICAgYnJlYWs7CiAgICAg
Y2FzZSBNU1JfSUEzMl9NQzBfQUREUjoKLSAgICAgICAgaWYgKCAhbGlzdF9lbXB0eSgmdm1jZS0+
aW1wYWN0X2hlYWRlcikgKQorICAgICAgICBpZiAoIGJhbmsgPCBHVUVTVF9NQ19CQU5LX05VTSAp
CiAgICAgICAgIHsKLSAgICAgICAgICAgIGVudHJ5ID0gbGlzdF9lbnRyeSh2bWNlLT5pbXBhY3Rf
aGVhZGVyLm5leHQsCi0gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgc3RydWN0IGJhbmtf
ZW50cnksIGxpc3QpOwotICAgICAgICAgICAgaWYgKCBlbnRyeS0+YmFuayA9PSBiYW5rICkKLSAg
ICAgICAgICAgIHsKLSAgICAgICAgICAgICAgICAqdmFsID0gZW50cnktPm1jaV9hZGRyOworICAg
ICAgICAgICAgKnZhbCA9IHYtPmFyY2gudm1jZS5iYW5rW2JhbmtdLm1jaV9hZGRyOworICAgICAg
ICAgICAgaWYgKCAqdmFsICkKICAgICAgICAgICAgICAgICBtY2VfcHJpbnRrKE1DRV9WRVJCT1NF
LAogICAgICAgICAgICAgICAgICAgICAgICAgICAgIk1DRTogcmRtc3IgTUMldV9BRERSIGluIHZN
Q0UjIGNvbnRleHQgIgogICAgICAgICAgICAgICAgICAgICAgICAgICAgIjB4JSJQUkl4NjQiXG4i
LCBiYW5rLCAqdmFsKTsKLSAgICAgICAgICAgIH0KICAgICAgICAgfQogICAgICAgICBicmVhazsK
ICAgICBjYXNlIE1TUl9JQTMyX01DMF9NSVNDOgotICAgICAgICBpZiAoICFsaXN0X2VtcHR5KCZ2
bWNlLT5pbXBhY3RfaGVhZGVyKSApCisgICAgICAgIGlmICggYmFuayA8IEdVRVNUX01DX0JBTktf
TlVNICkKICAgICAgICAgewotICAgICAgICAgICAgZW50cnkgPSBsaXN0X2VudHJ5KHZtY2UtPmlt
cGFjdF9oZWFkZXIubmV4dCwKLSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBzdHJ1Y3Qg
YmFua19lbnRyeSwgbGlzdCk7Ci0gICAgICAgICAgICBpZiAoIGVudHJ5LT5iYW5rID09IGJhbmsg
KQotICAgICAgICAgICAgewotICAgICAgICAgICAgICAgICp2YWwgPSBlbnRyeS0+bWNpX21pc2M7
CisgICAgICAgICAgICAqdmFsID0gdi0+YXJjaC52bWNlLmJhbmtbYmFua10ubWNpX21pc2M7Cisg
ICAgICAgICAgICBpZiAoICp2YWwgKQogICAgICAgICAgICAgICAgIG1jZV9wcmludGsoTUNFX1ZF
UkJPU0UsCi0gICAgICAgICAgICAgICAgICAgICAgICAgICAiTUNFOiByZCBNQyV1X01JU0MgaW4g
dk1DRSMgY29udGV4dCAiCisgICAgICAgICAgICAgICAgICAgICAgICAgICAiTUNFOiByZG1zciBN
QyV1X01JU0MgaW4gdk1DRSMgY29udGV4dCAiCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAi
MHglIlBSSXg2NCJcbiIsIGJhbmssICp2YWwpOwotICAgICAgICAgICAgfQogICAgICAgICB9CiAg
ICAgICAgIGJyZWFrOwogICAgIGRlZmF1bHQ6CkBAIC0xNTcsNTYgKzE0OSw1MCBAQAogICovCiBp
bnQgdm1jZV9yZG1zcih1aW50MzJfdCBtc3IsIHVpbnQ2NF90ICp2YWwpCiB7Ci0gICAgY29uc3Qg
c3RydWN0IHZjcHUgKmN1ciA9IGN1cnJlbnQ7Ci0gICAgc3RydWN0IGRvbWFpbl9tY2FfbXNycyAq
dm1jZSA9IGRvbV92bWNlKGN1ci0+ZG9tYWluKTsKKyAgICBzdHJ1Y3QgdmNwdSAqY3VyID0gY3Vy
cmVudDsKICAgICBpbnQgcmV0ID0gMTsKIAogICAgICp2YWwgPSAwOwogCi0gICAgc3Bpbl9sb2Nr
KCZ2bWNlLT5sb2NrKTsKKyAgICBzcGluX2xvY2soJmN1ci0+YXJjaC52bWNlLmxvY2spOwogCiAg
ICAgc3dpdGNoICggbXNyICkKICAgICB7CiAgICAgY2FzZSBNU1JfSUEzMl9NQ0dfU1RBVFVTOgot
ICAgICAgICAqdmFsID0gdm1jZS0+bWNnX3N0YXR1czsKKyAgICAgICAgKnZhbCA9IGN1ci0+YXJj
aC52bWNlLm1jZ19zdGF0dXM7CiAgICAgICAgIGlmICgqdmFsKQogICAgICAgICAgICAgbWNlX3By
aW50ayhNQ0VfVkVSQk9TRSwKICAgICAgICAgICAgICAgICAgICAgICAgIk1DRTogcmRtc3IgTUNH
X1NUQVRVUyAweCUiUFJJeDY0IlxuIiwgKnZhbCk7CiAgICAgICAgIGJyZWFrOwogICAgIGNhc2Ug
TVNSX0lBMzJfTUNHX0NBUDoKLSAgICAgICAgKnZhbCA9IGN1ci0+YXJjaC5tY2dfY2FwOwotICAg
ICAgICBtY2VfcHJpbnRrKE1DRV9WRVJCT1NFLCAiTUNFOiByZG1zciBNQ0dfQ0FQIDB4JSJQUkl4
NjQiXG4iLAotICAgICAgICAgICAgICAgICAgICp2YWwpOworICAgICAgICAqdmFsID0gY3VyLT5h
cmNoLnZtY2UubWNnX2NhcDsKKyAgICAgICAgbWNlX3ByaW50ayhNQ0VfVkVSQk9TRSwgIk1DRTog
cmRtc3IgTUNHX0NBUCAweCUiUFJJeDY0IlxuIiwgKnZhbCk7CiAgICAgICAgIGJyZWFrOwogICAg
IGNhc2UgTVNSX0lBMzJfTUNHX0NUTDoKLSAgICAgICAgLyogU3RpY2sgYWxsIDEncyB3aGVuIENU
TCBzdXBwb3J0LCBhbmQgMCdzIHdoZW4gbm8gQ1RMIHN1cHBvcnQgKi8KLSAgICAgICAgaWYgKCBj
dXItPmFyY2gubWNnX2NhcCAmIE1DR19DVExfUCApCi0gICAgICAgICAgICAqdmFsID0gfjBVTEw7
Ci0gICAgICAgIG1jZV9wcmludGsoTUNFX1ZFUkJPU0UsICJNQ0U6IHJkbXNyIE1DR19DVEwgMHgl
IlBSSXg2NCJcbiIsICp2YWwpOworICAgICAgICBpZiAoIGN1ci0+YXJjaC52bWNlLm1jZ19jYXAg
JiBNQ0dfQ1RMX1AgKQorICAgICAgICB7CisgICAgICAgICAgICAqdmFsID0gfjBVTDsKKyAgICAg
ICAgICAgIG1jZV9wcmludGsoTUNFX1ZFUkJPU0UsICJNQ0U6IHJkbXNyIE1DR19DVEwgMHglIlBS
SXg2NCJcbiIsICp2YWwpOworICAgICAgICB9CiAgICAgICAgIGJyZWFrOwogICAgIGRlZmF1bHQ6
CiAgICAgICAgIHJldCA9IG1jZV9iYW5rX21zcihjdXIsIG1zcikgPyBiYW5rX21jZV9yZG1zcihj
dXIsIG1zciwgdmFsKSA6IDA7CiAgICAgICAgIGJyZWFrOwogICAgIH0KIAotICAgIHNwaW5fdW5s
b2NrKCZ2bWNlLT5sb2NrKTsKKyAgICBzcGluX3VubG9jaygmY3VyLT5hcmNoLnZtY2UubG9jayk7
CisKICAgICByZXR1cm4gcmV0OwogfQogCisvKgorICogRm9yIGhpc3RvcmljIHZlcnNpb24gcmVh
c29uLCBiYW5rIG51bWJlciBtYXkgZ3JlYXRlciB0aGFuIEdVRVNUX01DX0JBTktfTlVNLAorICog
d2hlbiBtaWdyYXRpZSBmcm9tIG9sZCB2TUNFIHZlcnNpb24gdG8gbmV3IHZNQ0UuCisgKi8KIHN0
YXRpYyBpbnQgYmFua19tY2Vfd3Jtc3Ioc3RydWN0IHZjcHUgKnYsIHUzMiBtc3IsIHU2NCB2YWwp
CiB7CiAgICAgaW50IHJldCA9IDE7CiAgICAgdW5zaWduZWQgaW50IGJhbmsgPSAobXNyIC0gTVNS
X0lBMzJfTUMwX0NUTCkgLyA0OwotICAgIHN0cnVjdCBkb21haW5fbWNhX21zcnMgKnZtY2UgPSBk
b21fdm1jZSh2LT5kb21haW4pOwotICAgIHN0cnVjdCBiYW5rX2VudHJ5ICplbnRyeSA9IE5VTEw7
Ci0KLSAgICAvKiBHaXZlIHRoZSBmaXJzdCBlbnRyeSBvZiB0aGUgbGlzdCwgaXQgY29ycmVzcG9u
ZHMgdG8gY3VycmVudAotICAgICAqIHZNQ0UjIGluamVjdGlvbi4gV2hlbiB2TUNFIyBpcyBmaW5p
c2hlZCBwcm9jZXNzaW5nIGJ5IHRoZQotICAgICAqIHRoZSBndWVzdCwgdGhpcyBub2RlIHdpbGwg
YmUgZGVsZXRlZC4KLSAgICAgKiBPbmx5IGVycm9yIGJhbmsgaXMgd3JpdHRlbi4gTm9uLWVycm9y
IGJhbmtzIHNpbXBseSByZXR1cm4uCi0gICAgICovCi0gICAgaWYgKCAhbGlzdF9lbXB0eSgmdm1j
ZS0+aW1wYWN0X2hlYWRlcikgKQotICAgICAgICBlbnRyeSA9IGxpc3RfZW50cnkodm1jZS0+aW1w
YWN0X2hlYWRlci5uZXh0LCBzdHJ1Y3QgYmFua19lbnRyeSwgbGlzdCk7CiAKICAgICBzd2l0Y2gg
KCBtc3IgJiAoTVNSX0lBMzJfTUMwX0NUTCB8IDMpICkKICAgICB7CkBAIC0yMTcsNTAgKzIwMyw0
NiBAQAogICAgICAgICAgKi8KICAgICAgICAgYnJlYWs7CiAgICAgY2FzZSBNU1JfSUEzMl9NQzBf
U1RBVFVTOgotICAgICAgICBpZiAoIGVudHJ5ICYmIChlbnRyeS0+YmFuayA9PSBiYW5rKSApCisg
ICAgICAgIGlmICggdmFsICkKICAgICAgICAgewotICAgICAgICAgICAgZW50cnktPm1jaV9zdGF0
dXMgPSB2YWw7Ci0gICAgICAgICAgICBtY2VfcHJpbnRrKE1DRV9WRVJCT1NFLAotICAgICAgICAg
ICAgICAgICAgICAgICAiTUNFOiB3ciBNQyV1X1NUQVRVUyAlIlBSSXg2NCIgaW4gdk1DRSNcbiIs
CisgICAgICAgICAgICBtY2VfcHJpbnRrKE1DRV9RVUlFVCwKKyAgICAgICAgICAgICAgICAgICAg
ICAgIk1DRTogd3IgTUMldV9TVEFUVVMgdy8gbm9uLXplcm8gY2F1c2UgI0dQXG4iLCBiYW5rKTsK
KyAgICAgICAgICAgIHJldCA9IC0xOworICAgICAgICB9CisgICAgICAgIGlmICggYmFuayA8IEdV
RVNUX01DX0JBTktfTlVNICkKKyAgICAgICAgeworICAgICAgICAgICAgdi0+YXJjaC52bWNlLmJh
bmtbYmFua10ubWNpX3N0YXR1cyA9IHZhbDsKKyAgICAgICAgICAgIG1jZV9wcmludGsoTUNFX1ZF
UkJPU0UsICJNQ0U6IHdyIE1DJXVfU1RBVFVTICUiUFJJeDY0IlxuIiwKICAgICAgICAgICAgICAg
ICAgICAgICAgYmFuaywgdmFsKTsKICAgICAgICAgfQotICAgICAgICBlbHNlCi0gICAgICAgICAg
ICBtY2VfcHJpbnRrKE1DRV9WRVJCT1NFLAotICAgICAgICAgICAgICAgICAgICAgICAiTUNFOiB3
ciBNQyV1X1NUQVRVUyAlIlBSSXg2NCJcbiIsIGJhbmssIHZhbCk7CiAgICAgICAgIGJyZWFrOwog
ICAgIGNhc2UgTVNSX0lBMzJfTUMwX0FERFI6Ci0gICAgICAgIGlmICggIX52YWwgKQorICAgICAg
ICBpZiAoIHZhbCApCiAgICAgICAgIHsKICAgICAgICAgICAgIG1jZV9wcmludGsoTUNFX1FVSUVU
LAotICAgICAgICAgICAgICAgICAgICAgICAiTUNFOiB3ciBNQyV1X0FERFIgd2l0aCBhbGwgMXMg
d2lsbCBjYXVzZSAjR1BcbiIsIGJhbmspOworICAgICAgICAgICAgICAgICAgICAgICAiTUNFOiB3
ciBNQyV1X0FERFIgdy8gbm9uLXplcm8gY2F1c2UgI0dQXG4iLCBiYW5rKTsKICAgICAgICAgICAg
IHJldCA9IC0xOwogICAgICAgICB9Ci0gICAgICAgIGVsc2UgaWYgKCBlbnRyeSAmJiAoZW50cnkt
PmJhbmsgPT0gYmFuaykgKQorICAgICAgICBlbHNlIGlmICggYmFuayA8IEdVRVNUX01DX0JBTktf
TlVNICkKICAgICAgICAgewotICAgICAgICAgICAgZW50cnktPm1jaV9hZGRyID0gdmFsOwotICAg
ICAgICAgICAgbWNlX3ByaW50ayhNQ0VfVkVSQk9TRSwKLSAgICAgICAgICAgICAgICAgICAgICAg
Ik1DRTogd3IgTUMldV9BRERSICUiUFJJeDY0IiBpbiB2TUNFI1xuIiwgYmFuaywgdmFsKTsKLSAg
ICAgICAgfQotICAgICAgICBlbHNlCisgICAgICAgICAgICB2LT5hcmNoLnZtY2UuYmFua1tiYW5r
XS5tY2lfYWRkciA9IHZhbDsKICAgICAgICAgICAgIG1jZV9wcmludGsoTUNFX1ZFUkJPU0UsCiAg
ICAgICAgICAgICAgICAgICAgICAgICJNQ0U6IHdyIE1DJXVfQUREUiAlIlBSSXg2NCJcbiIsIGJh
bmssIHZhbCk7CisgICAgICAgIH0KICAgICAgICAgYnJlYWs7CiAgICAgY2FzZSBNU1JfSUEzMl9N
QzBfTUlTQzoKLSAgICAgICAgaWYgKCAhfnZhbCApCisgICAgICAgIGlmICggdmFsICkKICAgICAg
ICAgewogICAgICAgICAgICAgbWNlX3ByaW50ayhNQ0VfUVVJRVQsCi0gICAgICAgICAgICAgICAg
ICAgICAgICJNQ0U6IHdyIE1DJXVfTUlTQyB3aXRoIGFsbCAxcyB3aWxsIGNhdXNlICNHUFxuIiwg
YmFuayk7CisgICAgICAgICAgICAgICAgICAgICAgICJNQ0U6IHdyIE1DJXVfTUlTQyB3LyBub24t
emVybyBjYXVzZSAjR1BcbiIsIGJhbmspOwogICAgICAgICAgICAgcmV0ID0gLTE7CiAgICAgICAg
IH0KLSAgICAgICAgZWxzZSBpZiAoIGVudHJ5ICYmIChlbnRyeS0+YmFuayA9PSBiYW5rKSApCisg
ICAgICAgIGVsc2UgaWYgKCBiYW5rIDwgR1VFU1RfTUNfQkFOS19OVU0gKQogICAgICAgICB7Ci0g
ICAgICAgICAgICBlbnRyeS0+bWNpX21pc2MgPSB2YWw7Ci0gICAgICAgICAgICBtY2VfcHJpbnRr
KE1DRV9WRVJCT1NFLAotICAgICAgICAgICAgICAgICAgICAgICAiTUNFOiB3ciBNQyV1X01JU0Mg
JSJQUkl4NjQiIGluIHZNQ0UjXG4iLCBiYW5rLCB2YWwpOwotICAgICAgICB9Ci0gICAgICAgIGVs
c2UKKyAgICAgICAgICAgIHYtPmFyY2gudm1jZS5iYW5rW2JhbmtdLm1jaV9taXNjID0gdmFsOwog
ICAgICAgICAgICAgbWNlX3ByaW50ayhNQ0VfVkVSQk9TRSwKICAgICAgICAgICAgICAgICAgICAg
ICAgIk1DRTogd3IgTUMldV9NSVNDICUiUFJJeDY0IlxuIiwgYmFuaywgdmFsKTsKKyAgICAgICAg
fQogICAgICAgICBicmVhazsKICAgICBkZWZhdWx0OgogICAgICAgICBzd2l0Y2ggKCBib290X2Nw
dV9kYXRhLng4Nl92ZW5kb3IgKQpAQCAtMjg2LDUyICsyNjgsMzMgQEAKIGludCB2bWNlX3dybXNy
KHUzMiBtc3IsIHU2NCB2YWwpCiB7CiAgICAgc3RydWN0IHZjcHUgKmN1ciA9IGN1cnJlbnQ7Ci0g
ICAgc3RydWN0IGJhbmtfZW50cnkgKmVudHJ5ID0gTlVMTDsKLSAgICBzdHJ1Y3QgZG9tYWluX21j
YV9tc3JzICp2bWNlID0gZG9tX3ZtY2UoY3VyLT5kb21haW4pOwogICAgIGludCByZXQgPSAxOwog
Ci0gICAgc3Bpbl9sb2NrKCZ2bWNlLT5sb2NrKTsKKyAgICBzcGluX2xvY2soJmN1ci0+YXJjaC52
bWNlLmxvY2spOwogCiAgICAgc3dpdGNoICggbXNyICkKICAgICB7CiAgICAgY2FzZSBNU1JfSUEz
Ml9NQ0dfQ1RMOgorICAgICAgICAvKiBJZiBNQ0dfQ1RMIGV4aXN0IHRoZW4gc3RpY2sgdG8gYWxs
IDEncy4gSWYgbm90IGV4aXN0IHRoZW4gaWdub3JlICovCiAgICAgICAgIGJyZWFrOwogICAgIGNh
c2UgTVNSX0lBMzJfTUNHX1NUQVRVUzoKLSAgICAgICAgdm1jZS0+bWNnX3N0YXR1cyA9IHZhbDsK
KyAgICAgICAgY3VyLT5hcmNoLnZtY2UubWNnX3N0YXR1cyA9IHZhbDsKICAgICAgICAgbWNlX3By
aW50ayhNQ0VfVkVSQk9TRSwgIk1DRTogd3Jtc3IgTUNHX1NUQVRVUyAlIlBSSXg2NCJcbiIsIHZh
bCk7Ci0gICAgICAgIC8qIEZvciBIVk0gZ3Vlc3QsIHRoaXMgaXMgdGhlIHBvaW50IGZvciBkZWxl
dGluZyB2TUNFIGluamVjdGlvbiBub2RlICovCi0gICAgICAgIGlmICggaXNfaHZtX3ZjcHUoY3Vy
KSAmJiAodm1jZS0+bnJfaW5qZWN0aW9uID4gMCkgKQotICAgICAgICB7Ci0gICAgICAgICAgICB2
bWNlLT5ucl9pbmplY3Rpb24tLTsgLyogU2hvdWxkIGJlIDAgKi8KLSAgICAgICAgICAgIGlmICgg
IWxpc3RfZW1wdHkoJnZtY2UtPmltcGFjdF9oZWFkZXIpICkKLSAgICAgICAgICAgIHsKLSAgICAg
ICAgICAgICAgICBlbnRyeSA9IGxpc3RfZW50cnkodm1jZS0+aW1wYWN0X2hlYWRlci5uZXh0LAot
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBzdHJ1Y3QgYmFua19lbnRyeSwgbGlz
dCk7Ci0gICAgICAgICAgICAgICAgaWYgKCBlbnRyeS0+bWNpX3N0YXR1cyAmIE1DaV9TVEFUVVNf
VkFMICkKLSAgICAgICAgICAgICAgICAgICAgbWNlX3ByaW50ayhNQ0VfUVVJRVQsICJNQ0U6IE1D
aV9TVEFUVVMgTVNSIHNob3VsZCBoYXZlICIKLSAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAiYmVlbiBjbGVhcmVkIGJlZm9yZSB3cml0ZSBNQ0dfU1RBVFVTIE1TUlxuIik7Ci0KLSAgICAg
ICAgICAgICAgICBtY2VfcHJpbnRrKE1DRV9RVUlFVCwgIk1DRTogRGVsZXRlIEhWTSBsYXN0IGlu
amVjdGlvbiAiCi0gICAgICAgICAgICAgICAgICAgICAgICAgICAiTm9kZSwgbnJfaW5qZWN0aW9u
ICV1XG4iLAotICAgICAgICAgICAgICAgICAgICAgICAgICAgdm1jZS0+bnJfaW5qZWN0aW9uKTsK
LSAgICAgICAgICAgICAgICBsaXN0X2RlbCgmZW50cnktPmxpc3QpOwotICAgICAgICAgICAgICAg
IHhmcmVlKGVudHJ5KTsKLSAgICAgICAgICAgIH0KLSAgICAgICAgICAgIGVsc2UKLSAgICAgICAg
ICAgICAgICBtY2VfcHJpbnRrKE1DRV9RVUlFVCwgIk1DRTogTm90IGZvdW5kIEhWTSBndWVzdCIK
LSAgICAgICAgICAgICAgICAgICAgICAgICAgICIgbGFzdCBpbmplY3Rpb24gTm9kZSwgc29tZXRo
aW5nIFdyb25nIVxuIik7Ci0gICAgICAgIH0KICAgICAgICAgYnJlYWs7CiAgICAgY2FzZSBNU1Jf
SUEzMl9NQ0dfQ0FQOgotICAgICAgICBtY2VfcHJpbnRrKE1DRV9RVUlFVCwgIk1DRTogTUNHX0NB
UCBpcyByZWFkLW9ubHlcbiIpOwotICAgICAgICByZXQgPSAtMTsKKyAgICAgICAgLyoKKyAgICAg
ICAgICogQWNjb3JkaW5nIHRvIEludGVsIFNETSwgSUEzMl9NQ0dfQ0FQIGlzIGEgcmVhZC1vbmx5
IHJlZ2lzdGVyLAorICAgICAgICAgKiB0aGUgZWZmZWN0IG9mIHdyaXRpbmcgdG8gdGhlIElBMzJf
TUNHX0NBUCBpcyB1bmRlZmluZWQuIEhlcmUgd2UKKyAgICAgICAgICogdHJlYXQgd3JpdGluZyBh
cyAnd3JpdGUgbm90IGNoYW5nZScuIEd1ZXN0IHdvdWxkIG5vdCBzdXJwcmlzZS4KKyAgICAgICAg
ICovCisgICAgICAgIG1jZV9wcmludGsoTUNFX1FVSUVULCAiTUNFOiBNQ0dfQ0FQIGlzIHJlYWQg
b25seSBhbmQgd3JpdGUgbm90IGNoYW5nZVxuIik7CiAgICAgICAgIGJyZWFrOwogICAgIGRlZmF1
bHQ6CiAgICAgICAgIHJldCA9IG1jZV9iYW5rX21zcihjdXIsIG1zcikgPyBiYW5rX21jZV93cm1z
cihjdXIsIG1zciwgdmFsKSA6IDA7CiAgICAgICAgIGJyZWFrOwogICAgIH0KIAotICAgIHNwaW5f
dW5sb2NrKCZ2bWNlLT5sb2NrKTsKKyAgICBzcGluX3VubG9jaygmY3VyLT5hcmNoLnZtY2UubG9j
ayk7CiAgICAgcmV0dXJuIHJldDsKIH0KIApAQCAtMzQyLDcgKzMwNSw3IEBACiAKICAgICBmb3Jf
ZWFjaF92Y3B1KCBkLCB2ICkgewogICAgICAgICBzdHJ1Y3QgaHZtX3ZtY2VfdmNwdSBjdHh0ID0g
ewotICAgICAgICAgICAgLmNhcHMgPSB2LT5hcmNoLm1jZ19jYXAKKyAgICAgICAgICAgIC5jYXBz
ID0gdi0+YXJjaC52bWNlLm1jZ19jYXAKICAgICAgICAgfTsKIAogICAgICAgICBlcnIgPSBodm1f
c2F2ZV9lbnRyeShWTUNFX1ZDUFUsIHYtPnZjcHVfaWQsIGgsICZjdHh0KTsKQEAgLTQyMiw5MyAr
Mzg1LDM4IEBACiAgICAgcmV0dXJuIDA7CiB9CiAKLS8qIFRoaXMgbm9kZSBsaXN0IHJlY29yZHMg
ZXJyb3JzIGltcGFjdGluZyBhIGRvbWFpbi4gd2hlbiBvbmUKLSAqIE1DRSMgaGFwcGVucywgb25l
IGVycm9yIGJhbmsgaW1wYWN0cyBhIGRvbWFpbi4gVGhpcyBlcnJvciBub2RlCi0gKiB3aWxsIGJl
IGluc2VydGVkIHRvIHRoZSB0YWlsIG9mIHRoZSBwZXJfZG9tIGRhdGEgZm9yIHZNQ0UjIE1TUgot
ICogdmlydHVhbGl6YXRpb24uIFdoZW4gb25lIHZNQ0UjIGluamVjdGlvbiBpcyBmaW5pc2hlZCBw
cm9jZXNzaW5nCi0gKiBwcm9jZXNzZWQgYnkgZ3Vlc3QsIHRoZSBjb3JyZXNwb25kaW5nIG5vZGUg
d2lsbCBiZSBkZWxldGVkLgotICogVGhpcyBub2RlIGxpc3QgaXMgZm9yIEdVRVNUIHZNQ0UjIE1T
UlMgdmlydHVhbGl6YXRpb24uCi0gKi8KLXN0YXRpYyBzdHJ1Y3QgYmFua19lbnRyeSogYWxsb2Nf
YmFua19lbnRyeSh2b2lkKQoraW50IGZpbGxfdm1zcl9kYXRhKHN0cnVjdCBtY2luZm9fYmFuayAq
bWNfYmFuaywgc3RydWN0IGRvbWFpbiAqZCwKKyAgICAgICAgICAgICAgICAgICB1aW50NjRfdCBn
c3RhdHVzKQogewotICAgIHN0cnVjdCBiYW5rX2VudHJ5ICplbnRyeTsKKyAgICBzdHJ1Y3QgdmNw
dSAqdiA9IGQtPnZjcHVbMF07CiAKLSAgICBlbnRyeSA9IHh6YWxsb2Moc3RydWN0IGJhbmtfZW50
cnkpOwotICAgIGlmICggZW50cnkgPT0gTlVMTCApCi0gICAgewotICAgICAgICBwcmludGsoS0VS
Tl9FUlIgIk1DRTogbWFsbG9jIGJhbmtfZW50cnkgZmFpbGVkXG4iKTsKLSAgICAgICAgcmV0dXJu
IE5VTEw7Ci0gICAgfQotCi0gICAgSU5JVF9MSVNUX0hFQUQoJmVudHJ5LT5saXN0KTsKLSAgICBy
ZXR1cm4gZW50cnk7Ci19Ci0KLS8qIEZpbGwgZXJyb3IgYmFuayBpbmZvIGZvciAjdk1DRSBpbmpl
Y3Rpb24gYW5kIEdVRVNUIHZNQ0UjCi0gKiBNU1IgdmlydHVhbGl6YXRpb24gZGF0YQotICogMSkg
TG9nIGRvd24gaG93IG1hbnkgbnJfaW5qZWN0aW9ucyBvZiB0aGUgaW1wYWN0ZWQuCi0gKiAyKSBD
b3B5IE1DRSMgZXJyb3IgYmFuayB0byBpbXBhY3RlZCBET00gbm9kZSBsaXN0LAotICogICAgZm9y
IHZNQ0UjIE1TUnMgdmlydHVhbGl6YXRpb24KLSAqLwotaW50IGZpbGxfdm1zcl9kYXRhKHN0cnVj
dCBtY2luZm9fYmFuayAqbWNfYmFuaywgc3RydWN0IGRvbWFpbiAqZCwKLSAgICAgICAgICAgICAg
ICAgICB1aW50NjRfdCBnc3RhdHVzKSB7Ci0gICAgc3RydWN0IGJhbmtfZW50cnkgKmVudHJ5Owot
Ci0gICAgLyogVGhpcyBlcnJvciBiYW5rIGltcGFjdHMgb25lIGRvbWFpbiwgd2UgbmVlZCB0byBm
aWxsIGRvbWFpbiByZWxhdGVkCi0gICAgICogZGF0YSBmb3Igdk1DRSBNU1JzIHZpcnR1YWxpemF0
aW9uIGFuZCB2TUNFIyBpbmplY3Rpb24gKi8KICAgICBpZiAoIG1jX2JhbmstPm1jX2RvbWlkICE9
ICh1aW50MTZfdCl+MCApCiAgICAgewotICAgICAgICAvKiBGb3IgSFZNIGd1ZXN0LCBPbmx5IHdo
ZW4gZmlyc3Qgdk1DRSBpcyBjb25zdW1lZCBieSBIVk0gZ3Vlc3QKLSAgICAgICAgICogc3VjY2Vz
c2Z1bGx5LCB3aWxsIHdlIGdlbmVyZXRlIGFub3RoZXIgbm9kZSBhbmQgaW5qZWN0IGFub3RoZXIg
dk1DRS4KLSAgICAgICAgICovCi0gICAgICAgIGlmICggZC0+aXNfaHZtICYmIChkb21fdm1jZShk
KS0+bnJfaW5qZWN0aW9uID4gMCkgKQorICAgICAgICBpZiAoIHYtPmFyY2gudm1jZS5tY2dfc3Rh
dHVzICYgTUNHX1NUQVRVU19NQ0lQICkKICAgICAgICAgewotICAgICAgICAgICAgbWNlX3ByaW50
ayhNQ0VfUVVJRVQsICJNQ0U6IEhWTSBndWVzdCBoYXMgbm90IGhhbmRsZWQgcHJldmlvdXMiCisg
ICAgICAgICAgICBtY2VfcHJpbnRrKE1DRV9RVUlFVCwgIk1DRTogZ3Vlc3QgaGFzIG5vdCBoYW5k
bGVkIHByZXZpb3VzIgogICAgICAgICAgICAgICAgICAgICAgICAiIHZNQ0UgeWV0IVxuIik7CiAg
ICAgICAgICAgICByZXR1cm4gLTE7CiAgICAgICAgIH0KIAotICAgICAgICBlbnRyeSA9IGFsbG9j
X2JhbmtfZW50cnkoKTsKLSAgICAgICAgaWYgKCBlbnRyeSA9PSBOVUxMICkKLSAgICAgICAgICAg
IHJldHVybiAtMTsKKyAgICAgICAgc3Bpbl9sb2NrKCZ2LT5hcmNoLnZtY2UubG9jayk7CiAKLSAg
ICAgICAgZW50cnktPm1jaV9zdGF0dXMgPSBtY19iYW5rLT5tY19zdGF0dXM7Ci0gICAgICAgIGVu
dHJ5LT5tY2lfYWRkciA9IG1jX2JhbmstPm1jX2FkZHI7Ci0gICAgICAgIGVudHJ5LT5tY2lfbWlz
YyA9IG1jX2JhbmstPm1jX21pc2M7Ci0gICAgICAgIGVudHJ5LT5iYW5rID0gbWNfYmFuay0+bWNf
YmFuazsKKyAgICAgICAgdi0+YXJjaC52bWNlLm1jZ19zdGF0dXMgPSBnc3RhdHVzOworICAgICAg
ICAvKgorICAgICAgICAgKiAxLiBTa2lwIGJhbmsgMCB0byBhdm9pZCAnYmFuayAwIHF1aXJrJyBv
ZiBvbGQgcHJvY2Vzc29ycworICAgICAgICAgKiAyLiBGaWx0ZXIgTUNpX1NUQVRVUyBNU0NPRCBt
b2RlbCBzcGVjaWZpYyBlcnJvciBjb2RlIHRvIGd1ZXN0CisgICAgICAgICAqLworICAgICAgICB2
LT5hcmNoLnZtY2UuYmFua1sxXS5tY2lfc3RhdHVzID0gbWNfYmFuay0+bWNfc3RhdHVzICYKKyAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBNQ2lfU1RBVFVTX01T
Q09EX01BU0s7CisgICAgICAgIHYtPmFyY2gudm1jZS5iYW5rWzFdLm1jaV9hZGRyID0gbWNfYmFu
ay0+bWNfYWRkcjsKKyAgICAgICAgdi0+YXJjaC52bWNlLmJhbmtbMV0ubWNpX21pc2MgPSBtY19i
YW5rLT5tY19taXNjOwogCi0gICAgICAgIHNwaW5fbG9jaygmZG9tX3ZtY2UoZCktPmxvY2spOwot
ICAgICAgICAvKiBOZXcgZXJyb3IgTm9kZSwgaW5zZXJ0IHRvIHRoZSB0YWlsIG9mIHRoZSBwZXJf
ZG9tIGRhdGEgKi8KLSAgICAgICAgbGlzdF9hZGRfdGFpbCgmZW50cnktPmxpc3QsICZkb21fdm1j
ZShkKS0+aW1wYWN0X2hlYWRlcik7Ci0gICAgICAgIC8qIEZpbGwgTVNSIGdsb2JhbCBzdGF0dXMg
Ki8KLSAgICAgICAgZG9tX3ZtY2UoZCktPm1jZ19zdGF0dXMgPSBnc3RhdHVzOwotICAgICAgICAv
KiBOZXcgbm9kZSBpbXBhY3QgdGhlIGRvbWFpbiwgbmVlZCBhbm90aGVyIHZNQ0UjIGluamVjdGlv
biovCi0gICAgICAgIGRvbV92bWNlKGQpLT5ucl9pbmplY3Rpb24rKzsKLSAgICAgICAgc3Bpbl91
bmxvY2soJmRvbV92bWNlKGQpLT5sb2NrKTsKLQotICAgICAgICBtY2VfcHJpbnRrKE1DRV9WRVJC
T1NFLCJNQ0U6IEZvdW5kIGVycm9yIEBbQkFOSyVkICIKLSAgICAgICAgICAgICAgICAgICAic3Rh
dHVzICUiUFJJeDY0IiBhZGRyICUiUFJJeDY0IiBkb21pZCAlZF1cbiAiLAotICAgICAgICAgICAg
ICAgICAgIG1jX2JhbmstPm1jX2JhbmssIG1jX2JhbmstPm1jX3N0YXR1cywgbWNfYmFuay0+bWNf
YWRkciwKLSAgICAgICAgICAgICAgICAgICBtY19iYW5rLT5tY19kb21pZCk7CisgICAgICAgIHNw
aW5fdW5sb2NrKCZ2LT5hcmNoLnZtY2UubG9jayk7CiAgICAgfQogCiAgICAgcmV0dXJuIDA7CiB9
CiAKLSNpZiAwIC8qIGN1cnJlbnRseSB1bnVzZWQgKi8KLWludCB2bWNlX2RvbWFpbl9pbmplY3Qo
Ci0gICAgc3RydWN0IG1jaW5mb19iYW5rICpiYW5rLCBzdHJ1Y3QgZG9tYWluICpkLCBzdHJ1Y3Qg
bWNpbmZvX2dsb2JhbCAqZ2xvYmFsKQotewotICAgIGludCByZXQ7Ci0KLSAgICByZXQgPSBmaWxs
X3Ztc3JfZGF0YShiYW5rLCBkLCBnbG9iYWwtPm1jX2dzdGF0dXMpOwotICAgIGlmICggcmV0IDwg
MCApCi0gICAgICAgIHJldHVybiByZXQ7Ci0KLSAgICByZXR1cm4gaW5qZWN0X3ZtY2UoZCk7Ci19
Ci0jZW5kaWYKLQogc3RhdGljIGludCBpc19odm1fdm1jZV9yZWFkeShzdHJ1Y3QgbWNpbmZvX2Jh
bmsgKmJhbmssIHN0cnVjdCBkb21haW4gKmQpCiB7CiAgICAgc3RydWN0IHZjcHUgKnY7CmRpZmYg
LXIgZjc2Y2QzODE0NTllIHhlbi9hcmNoL3g4Ni9kb21haW4uYwotLS0gYS94ZW4vYXJjaC94ODYv
ZG9tYWluLmMJV2VkIFNlcCAxOSAyMTozMjoxNSAyMDEyICswODAwCisrKyBiL3hlbi9hcmNoL3g4
Ni9kb21haW4uYwlXZWQgU2VwIDE5IDIzOjIyOjU3IDIwMTIgKzA4MDAKQEAgLTU3MSw5ICs1NzEs
NiBAQAogCiAgICAgICAgIGlmICggKHJjID0gaW9tbXVfZG9tYWluX2luaXQoZCkpICE9IDAgKQog
ICAgICAgICAgICAgZ290byBmYWlsOwotCi0gICAgICAgIC8qIEZvciBHdWVzdCB2TUNFIE1TUnMg
dmlydHVhbGl6YXRpb24gKi8KLSAgICAgICAgdm1jZV9pbml0X21zcihkKTsKICAgICB9CiAKICAg
ICBpZiAoIGlzX2h2bV9kb21haW4oZCkgKQpAQCAtNjAwLDcgKzU5Nyw2IEBACiAKICBmYWlsOgog
ICAgIGQtPmlzX2R5aW5nID0gRE9NRFlJTkdfZGVhZDsKLSAgICB2bWNlX2Rlc3Ryb3lfbXNyKGQp
OwogICAgIGNsZWFudXBfZG9tYWluX2lycV9tYXBwaW5nKGQpOwogICAgIGZyZWVfeGVuaGVhcF9w
YWdlKGQtPnNoYXJlZF9pbmZvKTsKICAgICBpZiAoIHBhZ2luZ19pbml0aWFsaXNlZCApCkBAIC02
MjMsNyArNjE5LDYgQEAKICAgICBlbHNlCiAgICAgICAgIHhmcmVlKGQtPmFyY2gucHZfZG9tYWlu
LmU4MjApOwogCi0gICAgdm1jZV9kZXN0cm95X21zcihkKTsKICAgICBmcmVlX2RvbWFpbl9waXJx
cyhkKTsKICAgICBpZiAoICFpc19pZGxlX2RvbWFpbihkKSApCiAgICAgICAgIGlvbW11X2RvbWFp
bl9kZXN0cm95KGQpOwpkaWZmIC1yIGY3NmNkMzgxNDU5ZSB4ZW4vYXJjaC94ODYvZG9tY3RsLmMK
LS0tIGEveGVuL2FyY2gveDg2L2RvbWN0bC5jCVdlZCBTZXAgMTkgMjE6MzI6MTUgMjAxMiArMDgw
MAorKysgYi94ZW4vYXJjaC94ODYvZG9tY3RsLmMJV2VkIFNlcCAxOSAyMzoyMjo1NyAyMDEyICsw
ODAwCkBAIC0xMDI0LDcgKzEwMjQsNyBAQAogICAgICAgICAgICAgICAgIGV2Yy0+c3lzY2FsbDMy
X2NhbGxiYWNrX2VpcCAgICA9IDA7CiAgICAgICAgICAgICAgICAgZXZjLT5zeXNjYWxsMzJfZGlz
YWJsZXNfZXZlbnRzID0gMDsKICAgICAgICAgICAgIH0KLSAgICAgICAgICAgIGV2Yy0+bWNnX2Nh
cCA9IHYtPmFyY2gubWNnX2NhcDsKKyAgICAgICAgICAgIGV2Yy0+bWNnX2NhcCA9IHYtPmFyY2gu
dm1jZS5tY2dfY2FwOwogICAgICAgICB9CiAgICAgICAgIGVsc2UKICAgICAgICAgewpkaWZmIC1y
IGY3NmNkMzgxNDU5ZSB4ZW4vYXJjaC94ODYvdHJhcHMuYwotLS0gYS94ZW4vYXJjaC94ODYvdHJh
cHMuYwlXZWQgU2VwIDE5IDIxOjMyOjE1IDIwMTIgKzA4MDAKKysrIGIveGVuL2FyY2gveDg2L3Ry
YXBzLmMJV2VkIFNlcCAxOSAyMzoyMjo1NyAyMDEyICswODAwCkBAIC0zMTMzLDUwICszMTMzLDYg
QEAKICAgICAgICAgICAgICAgICBicmVhazsKICAgICBBU1NFUlQodHJhcCA8PSBWQ1BVX1RSQVBf
TEFTVCk7CiAKLSAgICAvKiBpbmplY3Qgdk1DRSB0byBQVl9HdWVzdCBpbmNsdWRpbmcgRE9NMC4g
Ki8KLSAgICBpZiAoIHRyYXAgPT0gVkNQVV9UUkFQX01DRSApCi0gICAgewotICAgICAgICBnZHBy
aW50ayhYRU5MT0dfREVCVUcsICJNQ0U6IFJldHVybiBmcm9tIHZNQ0UjIHRyYXAhXG4iKTsKLSAg
ICAgICAgaWYgKCBjdXJyLT52Y3B1X2lkID09IDAgKQotICAgICAgICB7Ci0gICAgICAgICAgICBz
dHJ1Y3QgZG9tYWluICpkID0gY3Vyci0+ZG9tYWluOwotCi0gICAgICAgICAgICBpZiAoICFkLT5h
cmNoLnZtY2FfbXNycy0+bnJfaW5qZWN0aW9uICkKLSAgICAgICAgICAgIHsKLSAgICAgICAgICAg
ICAgICBwcmludGsoWEVOTE9HX1dBUk5JTkcgIk1DRTogcmV0IGZyb20gdk1DRSMsICIKLSAgICAg
ICAgICAgICAgICAgICAgICAgIm5vIGluamVjdGlvbiBub2RlXG4iKTsKLSAgICAgICAgICAgICAg
ICBnb3RvIGVuZDsKLSAgICAgICAgICAgIH0KLQotICAgICAgICAgICAgZC0+YXJjaC52bWNhX21z
cnMtPm5yX2luamVjdGlvbi0tOwotICAgICAgICAgICAgaWYgKCAhbGlzdF9lbXB0eSgmZC0+YXJj
aC52bWNhX21zcnMtPmltcGFjdF9oZWFkZXIpICkKLSAgICAgICAgICAgIHsKLSAgICAgICAgICAg
ICAgICBzdHJ1Y3QgYmFua19lbnRyeSAqZW50cnk7Ci0KLSAgICAgICAgICAgICAgICBlbnRyeSA9
IGxpc3RfZW50cnkoZC0+YXJjaC52bWNhX21zcnMtPmltcGFjdF9oZWFkZXIubmV4dCwKLSAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgc3RydWN0IGJhbmtfZW50cnksIGxpc3QpOwot
ICAgICAgICAgICAgICAgIGdkcHJpbnRrKFhFTkxPR19ERUJVRywgIk1DRTogZGVsZXRlIGxhc3Qg
aW5qZWN0aW9uIG5vZGVcbiIpOwotICAgICAgICAgICAgICAgIGxpc3RfZGVsKCZlbnRyeS0+bGlz
dCk7Ci0gICAgICAgICAgICB9Ci0gICAgICAgICAgICBlbHNlCi0gICAgICAgICAgICAgICAgcHJp
bnRrKFhFTkxPR19FUlIgIk1DRTogZGlkbid0IGZvdW5kIGxhc3QgaW5qZWN0aW9uIG5vZGVcbiIp
OwotCi0gICAgICAgICAgICAvKiBmdXJ0aGVyIGluamVjdGlvbiAqLwotICAgICAgICAgICAgaWYg
KCBkLT5hcmNoLnZtY2FfbXNycy0+bnJfaW5qZWN0aW9uID4gMCAmJgotICAgICAgICAgICAgICAg
ICBndWVzdF9oYXNfdHJhcF9jYWxsYmFjayhkLCAwLCBUUkFQX21hY2hpbmVfY2hlY2spICYmCi0g
ICAgICAgICAgICAgICAgICF0ZXN0X2FuZF9zZXRfYm9vbChjdXJyLT5tY2VfcGVuZGluZykgKQot
ICAgICAgICAgICAgewotICAgICAgICAgICAgICAgIGludCBjcHUgPSBzbXBfcHJvY2Vzc29yX2lk
KCk7Ci0KLSAgICAgICAgICAgICAgICBjcHVtYXNrX2NvcHkoY3Vyci0+Y3B1X2FmZmluaXR5X3Rt
cCwgY3Vyci0+Y3B1X2FmZmluaXR5KTsKLSAgICAgICAgICAgICAgICBwcmludGsoWEVOTE9HX0RF
QlVHICJNQ0U6IENQVSVkIHNldCBhZmZpbml0eSwgb2xkICVkXG4iLAotICAgICAgICAgICAgICAg
ICAgICAgICBjcHUsIGN1cnItPnByb2Nlc3Nvcik7Ci0gICAgICAgICAgICAgICAgdmNwdV9zZXRf
YWZmaW5pdHkoY3VyciwgY3B1bWFza19vZihjcHUpKTsKLSAgICAgICAgICAgIH0KLSAgICAgICAg
fQotICAgIH0KLQotZW5kOgogICAgIC8qIFJlc3RvcmUgcHJldmlvdXMgYXN5bmNocm9ub3VzIGV4
Y2VwdGlvbiBtYXNrLiAqLwogICAgIGN1cnItPmFzeW5jX2V4Y2VwdGlvbl9tYXNrID0gY3Vyci0+
YXN5bmNfZXhjZXB0aW9uX3N0YXRlKHRyYXApLm9sZF9tYXNrOwogfQpkaWZmIC1yIGY3NmNkMzgx
NDU5ZSB4ZW4vaW5jbHVkZS9hc20teDg2L2RvbWFpbi5oCi0tLSBhL3hlbi9pbmNsdWRlL2FzbS14
ODYvZG9tYWluLmgJV2VkIFNlcCAxOSAyMTozMjoxNSAyMDEyICswODAwCisrKyBiL3hlbi9pbmNs
dWRlL2FzbS14ODYvZG9tYWluLmgJV2VkIFNlcCAxOSAyMzoyMjo1NyAyMDEyICswODAwCkBAIC0y
OTYsOSArMjk2LDYgQEAKIAogICAgIHN0cnVjdCBQSVRTdGF0ZSB2cGl0OwogCi0gICAgLyogRm9y
IEd1ZXN0IHZNQ0EgaGFuZGxpbmcgKi8KLSAgICBzdHJ1Y3QgZG9tYWluX21jYV9tc3JzICp2bWNh
X21zcnM7Ci0KICAgICAvKiBUU0MgbWFuYWdlbWVudCAoZW11bGF0aW9uLCBwdiwgc2NhbGluZywg
c3RhdHMpICovCiAgICAgaW50IHRzY19tb2RlOyAgICAgICAgICAgIC8qIHNlZSBpbmNsdWRlL2Fz
bS14ODYvdGltZS5oICovCiAgICAgYm9vbF90IHZ0c2M7ICAgICAgICAgICAgIC8qIHRzYyBpcyBl
bXVsYXRlZCAobWF5IGNoYW5nZSBhZnRlciBtaWdyYXRlKSAqLwpAQCAtNDM4LDggKzQzNSw4IEBA
CiAgICAgICogYW5kIHRodXMgc2hvdWxkIGJlIHNhdmVkL3Jlc3RvcmVkLiAqLwogICAgIGJvb2xf
dCBub25sYXp5X3hzdGF0ZV91c2VkOwogCi0gICAgdWludDY0X3QgbWNnX2NhcDsKLSAgICAKKyAg
ICBzdHJ1Y3Qgdm1jZSB2bWNlOworCiAgICAgc3RydWN0IHBhZ2luZ192Y3B1IHBhZ2luZzsKIAog
ICAgIHVpbnQzMl90IGdkYnN4X3ZjcHVfZXZlbnQ7CmRpZmYgLXIgZjc2Y2QzODE0NTllIHhlbi9p
bmNsdWRlL2FzbS14ODYvbWNlLmgKLS0tIGEveGVuL2luY2x1ZGUvYXNtLXg4Ni9tY2UuaAlXZWQg
U2VwIDE5IDIxOjMyOjE1IDIwMTIgKzA4MDAKKysrIGIveGVuL2luY2x1ZGUvYXNtLXg4Ni9tY2Uu
aAlXZWQgU2VwIDE5IDIzOjIyOjU3IDIwMTIgKzA4MDAKQEAgLTMsMjggKzMsNTAgQEAKICNpZm5k
ZWYgX1hFTl9YODZfTUNFX0gKICNkZWZpbmUgX1hFTl9YODZfTUNFX0gKIAotLyogVGhpcyBlbnRy
eSBpcyBmb3IgcmVjb3JkaW5nIGJhbmsgbm9kZXMgZm9yIHRoZSBpbXBhY3RlZCBkb21haW4sCi0g
KiBwdXQgaW50byBpbXBhY3RfaGVhZGVyIGxpc3QuICovCi1zdHJ1Y3QgYmFua19lbnRyeSB7Ci0g
ICAgc3RydWN0IGxpc3RfaGVhZCBsaXN0OwotICAgIHVpbnQxNl90IGJhbms7CisvKgorICogRW11
bGFsdGUgMiBiYW5rcyBmb3IgZ3Vlc3QKKyAqIEJhbmswOiByZXNlcnZlZCBmb3IgJ2JhbmswIHF1
aXJrJyBvY2N1ciBhdCBzb21lIHZlcnkgb2xkIHByb2Nlc3NvcnM6CisgKiAgIDEpLiBJbnRlbCBj
cHUgd2hvc2UgZmFtaWx5LW1vZGVsIHZhbHVlIDwgMDYtMUE7CisgKiAgIDIpLiBBTUQgSzcKKyAq
IEJhbmsxOiB1c2VkIHRvIHRyYW5zZmVyIGVycm9yIGluZm8gdG8gZ3Vlc3QKKyAqLworI2RlZmlu
ZSBHVUVTVF9NQ19CQU5LX05VTSAyCisKKy8qCisgKiBNQ0dfU0VSX1A6ICBzb2Z0d2FyZSBlcnJv
ciByZWNvdmVyeSBzdXBwb3J0ZWQKKyAqIE1DR19URVNfUDogIHRvIGF2b2lkIE1DaV9zdGF0dXMg
Yml0NTY6NTMgbW9kZWwgc3BlY2lmaWMKKyAqIE1DR19DTUNJX1A6IGV4cG9zZSBDTUNJIGNhcGFi
aWxpdHkgYnV0IG5ldmVyIHJlYWxseSBpbmplY3QgaXQgdG8gZ3Vlc3QsCisgKiAgICAgICAgICAg
ICBmb3Igc2FrZSBvZiBwZXJmb3JtYW5jZSBzaW5jZSBndWVzdCBub3QgcG9sbGluZyBwZXJpb2Rp
Y2FsbHkKKyAqLworI2RlZmluZSBJTlRFTF9HVUVTVF9NQ0dfQ0FQIChNQ0dfU0VSX1AgfAlcCisg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgIE1DR19URVNfUCB8CVwKKyAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgTUNHX0NNQ0lfUCB8CVwKKyAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgR1VFU1RfTUNfQkFOS19OVU0pCisKKyNkZWZpbmUgQU1EX0dVRVNUX01DR19DQVAgKE1DR19T
RVJfUCB8CQlcCisgICAgICAgICAgICAgICAgICAgICAgICAgICBHVUVTVF9NQ19CQU5LX05VTSkK
KworLyogRmlsdGVyIE1TQ09EIG1vZGVsIHNwZWNpZmljIGVycm9yIGNvZGUgdG8gZ3Vlc3QgKi8K
KyNkZWZpbmUgTUNpX1NUQVRVU19NU0NPRF9NQVNLICh+KDB4ZmZmZlVMTCA8PCAxNikpCisKKy8q
IE5vIG1jaV9jdGwgc2luY2UgaXQgc3RpY2sgYWxsIDEncyAqLworc3RydWN0IHZtY2VfYmFuayB7
CiAgICAgdWludDY0X3QgbWNpX3N0YXR1czsKICAgICB1aW50NjRfdCBtY2lfYWRkcjsKICAgICB1
aW50NjRfdCBtY2lfbWlzYzsKKyAgICB1aW50NjRfdCBtY2lfY3RsMjsKIH07CiAKLXN0cnVjdCBk
b21haW5fbWNhX21zcnMKLXsKLSAgICAvKiBHdWVzdCBzaG91bGQgbm90IGNoYW5nZSBiZWxvdyB2
YWx1ZXMgYWZ0ZXIgRE9NIGJvb3QgdXAgKi8KKy8qIE5vIG1jZ19jdGwgc2luY2UgaXQgbm90IGV4
cG9zZSB0byBndWVzdCAqLworc3RydWN0IHZtY2UgeworICAgIHVpbnQ2NF90IG1jZ19jYXA7CiAg
ICAgdWludDY0X3QgbWNnX3N0YXR1czsKLSAgICB1aW50MTZfdCBucl9pbmplY3Rpb247Ci0gICAg
c3RydWN0IGxpc3RfaGVhZCBpbXBhY3RfaGVhZGVyOworICAgIHN0cnVjdCB2bWNlX2JhbmsgYmFu
a1tHVUVTVF9NQ19CQU5LX05VTV07CisKICAgICBzcGlubG9ja190IGxvY2s7CiB9OwogCiAvKiBH
dWVzdCB2TUNFIE1TUnMgdmlydHVhbGl6YXRpb24gKi8KLWV4dGVybiBpbnQgdm1jZV9pbml0X21z
cihzdHJ1Y3QgZG9tYWluICpkKTsKLWV4dGVybiB2b2lkIHZtY2VfZGVzdHJveV9tc3Ioc3RydWN0
IGRvbWFpbiAqZCk7CiBleHRlcm4gdm9pZCB2bWNlX2luaXRfdmNwdShzdHJ1Y3QgdmNwdSAqKTsK
IGV4dGVybiBpbnQgdm1jZV9yZXN0b3JlX3ZjcHUoc3RydWN0IHZjcHUgKiwgdWludDY0X3QgY2Fw
cyk7CiBleHRlcm4gaW50IHZtY2Vfd3Jtc3IodWludDMyX3QgbXNyLCB1aW50NjRfdCB2YWwpOwo=

--_002_DE8DF0795D48FD4CA783C40EC8292335330546SHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 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_DE8DF0795D48FD4CA783C40EC8292335330546SHSMSX101ccrcorpi_--


From xen-devel-bounces@lists.xen.org Wed Sep 19 08:04:00 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Sep 2012 08:04:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TEFG5-0004ak-Pk; Wed, 19 Sep 2012 08:03:45 +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 1TEFG3-0004ac-TT
	for xen-devel@lists.xensource.com; Wed, 19 Sep 2012 08:03:44 +0000
Received: from [85.158.139.211:10485] by server-5.bemta-5.messagelabs.com id
	DD/03-30514-F5C79505; Wed, 19 Sep 2012 08:03:43 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-4.tower-206.messagelabs.com!1348041821!19141166!1
X-Originating-IP: [192.55.52.93]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjkzID0+IDM0NDQ2OQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14097 invoked from network); 19 Sep 2012 08:03:42 -0000
Received: from mga11.intel.com (HELO mga11.intel.com) (192.55.52.93)
	by server-4.tower-206.messagelabs.com with SMTP;
	19 Sep 2012 08:03:42 -0000
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
	by fmsmga102.fm.intel.com with ESMTP; 19 Sep 2012 01:03:40 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.80,447,1344236400"; d="scan'208";a="223856203"
Received: from fmsmsx104.amr.corp.intel.com ([10.19.9.35])
	by fmsmga001.fm.intel.com with ESMTP; 19 Sep 2012 01:03:40 -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; Wed, 19 Sep 2012 01:03:40 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.239]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.175]) with mapi id
	14.01.0355.002; Wed, 19 Sep 2012 16:03:38 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: Jan Beulich <JBeulich@suse.com>, "xen-devel@lists.xensource.com"
	<xen-devel@lists.xensource.com>
Thread-Topic: [PATCH 2/5] Xen/MCE: vMCE injection
Thread-Index: Ac2WPUYXekObrJQCTVCsi0gKQEvFZA==
Date: Wed, 19 Sep 2012 08:03:37 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC8292335330591@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_DE8DF0795D48FD4CA783C40EC8292335330591SHSMSX101ccrcorpi_"
MIME-Version: 1.0
Cc: Christoph Egger <Christoph.Egger@amd.com>, "keir@xen.org" <keir@xen.org>,
	"Ian.Campbell@citrix.com" <Ian.Campbell@citrix.com>
Subject: [Xen-devel] [PATCH 2/5] Xen/MCE: vMCE injection
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--_002_DE8DF0795D48FD4CA783C40EC8292335330591SHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Xen/MCE: vMCE injection

In our test for win8 guest mce, we find a bug 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.

Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>

diff -r 133664c6bfb4 xen/arch/x86/cpu/mcheck/vmce.c
--- a/xen/arch/x86/cpu/mcheck/vmce.c	Tue Sep 18 22:39:11 2012 +0800
+++ b/xen/arch/x86/cpu/mcheck/vmce.c	Tue Sep 18 23:46:38 2012 +0800
@@ -340,48 +340,27 @@
=20
 int inject_vmce(struct domain *d)
 {
-    int cpu =3D smp_processor_id();
+    struct vcpu *v;
=20
-    /* PV guest and HVM guest have different vMCE# injection methods. */
-    if ( !test_and_set_bool(d->vcpu[0]->mce_pending) )
+    /* inject vMCE to all vcpus */
+    for_each_vcpu(d, v)
     {
-        if ( d->is_hvm )
+        if ( !test_and_set_bool(v->mce_pending) &&
+            ((d->is_hvm) ||
+                guest_has_trap_callback(d, v->vcpu_id, TRAP_machine_check)=
) )
         {
-            mce_printk(MCE_VERBOSE, "MCE: inject vMCE to HVM DOM %d\n",
-                       d->domain_id);
-            vcpu_kick(d->vcpu[0]);
+            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_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);
-            }
+            mce_printk(MCE_QUIET, "Fail to inject vMCE to dom%d vcpu%d\n",
+                       d->domain_id, v->vcpu_id);
+            return -1;
         }
     }
-    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;
 }
 =

--_002_DE8DF0795D48FD4CA783C40EC8292335330591SHSMSX101ccrcorpi_
Content-Type: application/octet-stream; name="2_vmce_injection.patch"
Content-Description: 2_vmce_injection.patch
Content-Disposition: attachment; filename="2_vmce_injection.patch"; size=2793;
	creation-date="Wed, 19 Sep 2012 07:39:51 GMT";
	modification-date="Wed, 19 Sep 2012 15:27:22 GMT"
Content-Transfer-Encoding: base64

WGVuL01DRTogdk1DRSBpbmplY3Rpb24KCkluIG91ciB0ZXN0IGZvciB3aW44IGd1ZXN0IG1jZSwg
d2UgZmluZCBhIGJ1ZyB0aGF0IG5vIG1hdHRlciB3aGF0IFNSQU8vU1JBUgplcnJvciB4ZW4gaW5q
ZWN0IHRvIHdpbjggZ3Vlc3QsIGl0IGFsd2F5cyByZWJvb3QuCgpUaGUgcm9vdCBjYXVzZSBpcywg
Y3VycmVudCBYZW4gdk1DRSBsb2dpYyBpbmplY3Qgdk1DRSMgb25seSB0byB2Y3B1MCwgdGhpcyBp
cwpub3QgY29ycmVjdCBmb3IgSW50ZWwgTUNFIChVbmRlciBJbnRlbCBhcmNoLCBoL3cgZ2VuZXJh
dGUgTUNFIyB0byBhbGwgQ1BVcykuCgpUaGlzIHBhdGNoIGZpeCB2TUNFIGluamVjdGlvbiBidWcs
IGluamVjdGluZyB2TUNFIyB0byBhbGwgdmNwdXMuCgpTaWduZWQtb2ZmLWJ5OiBMaXUsIEppbnNv
bmcgPGppbnNvbmcubGl1QGludGVsLmNvbT4KCmRpZmYgLXIgMTMzNjY0YzZiZmI0IHhlbi9hcmNo
L3g4Ni9jcHUvbWNoZWNrL3ZtY2UuYwotLS0gYS94ZW4vYXJjaC94ODYvY3B1L21jaGVjay92bWNl
LmMJVHVlIFNlcCAxOCAyMjozOToxMSAyMDEyICswODAwCisrKyBiL3hlbi9hcmNoL3g4Ni9jcHUv
bWNoZWNrL3ZtY2UuYwlUdWUgU2VwIDE4IDIzOjQ2OjM4IDIwMTIgKzA4MDAKQEAgLTM0MCw0OCAr
MzQwLDI3IEBACiAKIGludCBpbmplY3Rfdm1jZShzdHJ1Y3QgZG9tYWluICpkKQogewotICAgIGlu
dCBjcHUgPSBzbXBfcHJvY2Vzc29yX2lkKCk7CisgICAgc3RydWN0IHZjcHUgKnY7CiAKLSAgICAv
KiBQViBndWVzdCBhbmQgSFZNIGd1ZXN0IGhhdmUgZGlmZmVyZW50IHZNQ0UjIGluamVjdGlvbiBt
ZXRob2RzLiAqLwotICAgIGlmICggIXRlc3RfYW5kX3NldF9ib29sKGQtPnZjcHVbMF0tPm1jZV9w
ZW5kaW5nKSApCisgICAgLyogaW5qZWN0IHZNQ0UgdG8gYWxsIHZjcHVzICovCisgICAgZm9yX2Vh
Y2hfdmNwdShkLCB2KQogICAgIHsKLSAgICAgICAgaWYgKCBkLT5pc19odm0gKQorICAgICAgICBp
ZiAoICF0ZXN0X2FuZF9zZXRfYm9vbCh2LT5tY2VfcGVuZGluZykgJiYKKyAgICAgICAgICAgICgo
ZC0+aXNfaHZtKSB8fAorICAgICAgICAgICAgICAgIGd1ZXN0X2hhc190cmFwX2NhbGxiYWNrKGQs
IHYtPnZjcHVfaWQsIFRSQVBfbWFjaGluZV9jaGVjaykpICkKICAgICAgICAgewotICAgICAgICAg
ICAgbWNlX3ByaW50ayhNQ0VfVkVSQk9TRSwgIk1DRTogaW5qZWN0IHZNQ0UgdG8gSFZNIERPTSAl
ZFxuIiwKLSAgICAgICAgICAgICAgICAgICAgICAgZC0+ZG9tYWluX2lkKTsKLSAgICAgICAgICAg
IHZjcHVfa2ljayhkLT52Y3B1WzBdKTsKKyAgICAgICAgICAgIG1jZV9wcmludGsoTUNFX1ZFUkJP
U0UsICJNQ0U6IGluamVjdCB2TUNFIHRvIGRvbSVkIHZjcHUlZFxuIiwKKyAgICAgICAgICAgICAg
ICAgICAgICAgZC0+ZG9tYWluX2lkLCB2LT52Y3B1X2lkKTsKKyAgICAgICAgICAgIHZjcHVfa2lj
ayh2KTsKICAgICAgICAgfQogICAgICAgICBlbHNlCiAgICAgICAgIHsKLSAgICAgICAgICAgIG1j
ZV9wcmludGsoTUNFX1ZFUkJPU0UsICJNQ0U6IGluamVjdCB2TUNFIHRvIFBWIERPTSVkXG4iLAot
ICAgICAgICAgICAgICAgICAgICAgICBkLT5kb21haW5faWQpOwotICAgICAgICAgICAgaWYgKCBn
dWVzdF9oYXNfdHJhcF9jYWxsYmFjayhkLCAwLCBUUkFQX21hY2hpbmVfY2hlY2spICkKLSAgICAg
ICAgICAgIHsKLSAgICAgICAgICAgICAgICBjcHVtYXNrX2NvcHkoZC0+dmNwdVswXS0+Y3B1X2Fm
ZmluaXR5X3RtcCwKLSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgZC0+dmNwdVswXS0+Y3B1
X2FmZmluaXR5KTsKLSAgICAgICAgICAgICAgICBtY2VfcHJpbnRrKE1DRV9WRVJCT1NFLCAiTUNF
OiBDUFUlZCBzZXQgYWZmaW5pdHksIG9sZCAlZFxuIiwKLSAgICAgICAgICAgICAgICAgICAgICAg
ICAgIGNwdSwgZC0+dmNwdVswXS0+cHJvY2Vzc29yKTsKLSAgICAgICAgICAgICAgICB2Y3B1X3Nl
dF9hZmZpbml0eShkLT52Y3B1WzBdLCBjcHVtYXNrX29mKGNwdSkpOwotICAgICAgICAgICAgICAg
IHZjcHVfa2ljayhkLT52Y3B1WzBdKTsKLSAgICAgICAgICAgIH0KLSAgICAgICAgICAgIGVsc2UK
LSAgICAgICAgICAgIHsKLSAgICAgICAgICAgICAgICBtY2VfcHJpbnRrKE1DRV9WRVJCT1NFLAot
ICAgICAgICAgICAgICAgICAgICAgICAgICAgIk1DRTogS2lsbCBQViBndWVzdCB3aXRoIE5vIE1D
RSBoYW5kbGVyXG4iKTsKLSAgICAgICAgICAgICAgICBkb21haW5fY3Jhc2goZCk7Ci0gICAgICAg
ICAgICB9CisgICAgICAgICAgICBtY2VfcHJpbnRrKE1DRV9RVUlFVCwgIkZhaWwgdG8gaW5qZWN0
IHZNQ0UgdG8gZG9tJWQgdmNwdSVkXG4iLAorICAgICAgICAgICAgICAgICAgICAgICBkLT5kb21h
aW5faWQsIHYtPnZjcHVfaWQpOworICAgICAgICAgICAgcmV0dXJuIC0xOwogICAgICAgICB9CiAg
ICAgfQotICAgIGVsc2UKLSAgICB7Ci0gICAgICAgIC8qIG5ldyB2TUNFIGNvbWVzIHdoaWxlIGZp
cnN0IG9uZSBoYXMgbm90IGJlZW4gaW5qZWN0ZWQgeWV0LAotICAgICAgICAgKiBpbiB0aGlzIGNh
c2UsIGluamVjdCBmYWlsLiBbV2UgY2FuJ3QgbG9zZSB0aGlzIHZNQ0UgZm9yCi0gICAgICAgICAq
IHRoZSBtY2Ugbm9kZSdzIGNvbnNpc3RlbmN5XS4KLSAgICAgICAgICovCi0gICAgICAgIG1jZV9w
cmludGsoTUNFX1FVSUVULCAiVGhlcmUncyBhIHBlbmRpbmcgdk1DRSB3YWl0aW5nIHRvIGJlIGlu
amVjdGVkICIKLSAgICAgICAgICAgICAgICAgICAiIHRvIHRoaXMgRE9NJWQhXG4iLCBkLT5kb21h
aW5faWQpOwotICAgICAgICByZXR1cm4gLTE7Ci0gICAgfQorCiAgICAgcmV0dXJuIDA7CiB9CiAK

--_002_DE8DF0795D48FD4CA783C40EC8292335330591SHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 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_DE8DF0795D48FD4CA783C40EC8292335330591SHSMSX101ccrcorpi_--


From xen-devel-bounces@lists.xen.org Wed Sep 19 08:04:00 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Sep 2012 08:04:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TEFG5-0004ak-Pk; Wed, 19 Sep 2012 08:03:45 +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 1TEFG3-0004ac-TT
	for xen-devel@lists.xensource.com; Wed, 19 Sep 2012 08:03:44 +0000
Received: from [85.158.139.211:10485] by server-5.bemta-5.messagelabs.com id
	DD/03-30514-F5C79505; Wed, 19 Sep 2012 08:03:43 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-4.tower-206.messagelabs.com!1348041821!19141166!1
X-Originating-IP: [192.55.52.93]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjkzID0+IDM0NDQ2OQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14097 invoked from network); 19 Sep 2012 08:03:42 -0000
Received: from mga11.intel.com (HELO mga11.intel.com) (192.55.52.93)
	by server-4.tower-206.messagelabs.com with SMTP;
	19 Sep 2012 08:03:42 -0000
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
	by fmsmga102.fm.intel.com with ESMTP; 19 Sep 2012 01:03:40 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.80,447,1344236400"; d="scan'208";a="223856203"
Received: from fmsmsx104.amr.corp.intel.com ([10.19.9.35])
	by fmsmga001.fm.intel.com with ESMTP; 19 Sep 2012 01:03:40 -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; Wed, 19 Sep 2012 01:03:40 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.239]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.175]) with mapi id
	14.01.0355.002; Wed, 19 Sep 2012 16:03:38 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: Jan Beulich <JBeulich@suse.com>, "xen-devel@lists.xensource.com"
	<xen-devel@lists.xensource.com>
Thread-Topic: [PATCH 2/5] Xen/MCE: vMCE injection
Thread-Index: Ac2WPUYXekObrJQCTVCsi0gKQEvFZA==
Date: Wed, 19 Sep 2012 08:03:37 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC8292335330591@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_DE8DF0795D48FD4CA783C40EC8292335330591SHSMSX101ccrcorpi_"
MIME-Version: 1.0
Cc: Christoph Egger <Christoph.Egger@amd.com>, "keir@xen.org" <keir@xen.org>,
	"Ian.Campbell@citrix.com" <Ian.Campbell@citrix.com>
Subject: [Xen-devel] [PATCH 2/5] Xen/MCE: vMCE injection
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--_002_DE8DF0795D48FD4CA783C40EC8292335330591SHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Xen/MCE: vMCE injection

In our test for win8 guest mce, we find a bug 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.

Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>

diff -r 133664c6bfb4 xen/arch/x86/cpu/mcheck/vmce.c
--- a/xen/arch/x86/cpu/mcheck/vmce.c	Tue Sep 18 22:39:11 2012 +0800
+++ b/xen/arch/x86/cpu/mcheck/vmce.c	Tue Sep 18 23:46:38 2012 +0800
@@ -340,48 +340,27 @@
=20
 int inject_vmce(struct domain *d)
 {
-    int cpu =3D smp_processor_id();
+    struct vcpu *v;
=20
-    /* PV guest and HVM guest have different vMCE# injection methods. */
-    if ( !test_and_set_bool(d->vcpu[0]->mce_pending) )
+    /* inject vMCE to all vcpus */
+    for_each_vcpu(d, v)
     {
-        if ( d->is_hvm )
+        if ( !test_and_set_bool(v->mce_pending) &&
+            ((d->is_hvm) ||
+                guest_has_trap_callback(d, v->vcpu_id, TRAP_machine_check)=
) )
         {
-            mce_printk(MCE_VERBOSE, "MCE: inject vMCE to HVM DOM %d\n",
-                       d->domain_id);
-            vcpu_kick(d->vcpu[0]);
+            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_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);
-            }
+            mce_printk(MCE_QUIET, "Fail to inject vMCE to dom%d vcpu%d\n",
+                       d->domain_id, v->vcpu_id);
+            return -1;
         }
     }
-    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;
 }
 =

--_002_DE8DF0795D48FD4CA783C40EC8292335330591SHSMSX101ccrcorpi_
Content-Type: application/octet-stream; name="2_vmce_injection.patch"
Content-Description: 2_vmce_injection.patch
Content-Disposition: attachment; filename="2_vmce_injection.patch"; size=2793;
	creation-date="Wed, 19 Sep 2012 07:39:51 GMT";
	modification-date="Wed, 19 Sep 2012 15:27:22 GMT"
Content-Transfer-Encoding: base64

WGVuL01DRTogdk1DRSBpbmplY3Rpb24KCkluIG91ciB0ZXN0IGZvciB3aW44IGd1ZXN0IG1jZSwg
d2UgZmluZCBhIGJ1ZyB0aGF0IG5vIG1hdHRlciB3aGF0IFNSQU8vU1JBUgplcnJvciB4ZW4gaW5q
ZWN0IHRvIHdpbjggZ3Vlc3QsIGl0IGFsd2F5cyByZWJvb3QuCgpUaGUgcm9vdCBjYXVzZSBpcywg
Y3VycmVudCBYZW4gdk1DRSBsb2dpYyBpbmplY3Qgdk1DRSMgb25seSB0byB2Y3B1MCwgdGhpcyBp
cwpub3QgY29ycmVjdCBmb3IgSW50ZWwgTUNFIChVbmRlciBJbnRlbCBhcmNoLCBoL3cgZ2VuZXJh
dGUgTUNFIyB0byBhbGwgQ1BVcykuCgpUaGlzIHBhdGNoIGZpeCB2TUNFIGluamVjdGlvbiBidWcs
IGluamVjdGluZyB2TUNFIyB0byBhbGwgdmNwdXMuCgpTaWduZWQtb2ZmLWJ5OiBMaXUsIEppbnNv
bmcgPGppbnNvbmcubGl1QGludGVsLmNvbT4KCmRpZmYgLXIgMTMzNjY0YzZiZmI0IHhlbi9hcmNo
L3g4Ni9jcHUvbWNoZWNrL3ZtY2UuYwotLS0gYS94ZW4vYXJjaC94ODYvY3B1L21jaGVjay92bWNl
LmMJVHVlIFNlcCAxOCAyMjozOToxMSAyMDEyICswODAwCisrKyBiL3hlbi9hcmNoL3g4Ni9jcHUv
bWNoZWNrL3ZtY2UuYwlUdWUgU2VwIDE4IDIzOjQ2OjM4IDIwMTIgKzA4MDAKQEAgLTM0MCw0OCAr
MzQwLDI3IEBACiAKIGludCBpbmplY3Rfdm1jZShzdHJ1Y3QgZG9tYWluICpkKQogewotICAgIGlu
dCBjcHUgPSBzbXBfcHJvY2Vzc29yX2lkKCk7CisgICAgc3RydWN0IHZjcHUgKnY7CiAKLSAgICAv
KiBQViBndWVzdCBhbmQgSFZNIGd1ZXN0IGhhdmUgZGlmZmVyZW50IHZNQ0UjIGluamVjdGlvbiBt
ZXRob2RzLiAqLwotICAgIGlmICggIXRlc3RfYW5kX3NldF9ib29sKGQtPnZjcHVbMF0tPm1jZV9w
ZW5kaW5nKSApCisgICAgLyogaW5qZWN0IHZNQ0UgdG8gYWxsIHZjcHVzICovCisgICAgZm9yX2Vh
Y2hfdmNwdShkLCB2KQogICAgIHsKLSAgICAgICAgaWYgKCBkLT5pc19odm0gKQorICAgICAgICBp
ZiAoICF0ZXN0X2FuZF9zZXRfYm9vbCh2LT5tY2VfcGVuZGluZykgJiYKKyAgICAgICAgICAgICgo
ZC0+aXNfaHZtKSB8fAorICAgICAgICAgICAgICAgIGd1ZXN0X2hhc190cmFwX2NhbGxiYWNrKGQs
IHYtPnZjcHVfaWQsIFRSQVBfbWFjaGluZV9jaGVjaykpICkKICAgICAgICAgewotICAgICAgICAg
ICAgbWNlX3ByaW50ayhNQ0VfVkVSQk9TRSwgIk1DRTogaW5qZWN0IHZNQ0UgdG8gSFZNIERPTSAl
ZFxuIiwKLSAgICAgICAgICAgICAgICAgICAgICAgZC0+ZG9tYWluX2lkKTsKLSAgICAgICAgICAg
IHZjcHVfa2ljayhkLT52Y3B1WzBdKTsKKyAgICAgICAgICAgIG1jZV9wcmludGsoTUNFX1ZFUkJP
U0UsICJNQ0U6IGluamVjdCB2TUNFIHRvIGRvbSVkIHZjcHUlZFxuIiwKKyAgICAgICAgICAgICAg
ICAgICAgICAgZC0+ZG9tYWluX2lkLCB2LT52Y3B1X2lkKTsKKyAgICAgICAgICAgIHZjcHVfa2lj
ayh2KTsKICAgICAgICAgfQogICAgICAgICBlbHNlCiAgICAgICAgIHsKLSAgICAgICAgICAgIG1j
ZV9wcmludGsoTUNFX1ZFUkJPU0UsICJNQ0U6IGluamVjdCB2TUNFIHRvIFBWIERPTSVkXG4iLAot
ICAgICAgICAgICAgICAgICAgICAgICBkLT5kb21haW5faWQpOwotICAgICAgICAgICAgaWYgKCBn
dWVzdF9oYXNfdHJhcF9jYWxsYmFjayhkLCAwLCBUUkFQX21hY2hpbmVfY2hlY2spICkKLSAgICAg
ICAgICAgIHsKLSAgICAgICAgICAgICAgICBjcHVtYXNrX2NvcHkoZC0+dmNwdVswXS0+Y3B1X2Fm
ZmluaXR5X3RtcCwKLSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgZC0+dmNwdVswXS0+Y3B1
X2FmZmluaXR5KTsKLSAgICAgICAgICAgICAgICBtY2VfcHJpbnRrKE1DRV9WRVJCT1NFLCAiTUNF
OiBDUFUlZCBzZXQgYWZmaW5pdHksIG9sZCAlZFxuIiwKLSAgICAgICAgICAgICAgICAgICAgICAg
ICAgIGNwdSwgZC0+dmNwdVswXS0+cHJvY2Vzc29yKTsKLSAgICAgICAgICAgICAgICB2Y3B1X3Nl
dF9hZmZpbml0eShkLT52Y3B1WzBdLCBjcHVtYXNrX29mKGNwdSkpOwotICAgICAgICAgICAgICAg
IHZjcHVfa2ljayhkLT52Y3B1WzBdKTsKLSAgICAgICAgICAgIH0KLSAgICAgICAgICAgIGVsc2UK
LSAgICAgICAgICAgIHsKLSAgICAgICAgICAgICAgICBtY2VfcHJpbnRrKE1DRV9WRVJCT1NFLAot
ICAgICAgICAgICAgICAgICAgICAgICAgICAgIk1DRTogS2lsbCBQViBndWVzdCB3aXRoIE5vIE1D
RSBoYW5kbGVyXG4iKTsKLSAgICAgICAgICAgICAgICBkb21haW5fY3Jhc2goZCk7Ci0gICAgICAg
ICAgICB9CisgICAgICAgICAgICBtY2VfcHJpbnRrKE1DRV9RVUlFVCwgIkZhaWwgdG8gaW5qZWN0
IHZNQ0UgdG8gZG9tJWQgdmNwdSVkXG4iLAorICAgICAgICAgICAgICAgICAgICAgICBkLT5kb21h
aW5faWQsIHYtPnZjcHVfaWQpOworICAgICAgICAgICAgcmV0dXJuIC0xOwogICAgICAgICB9CiAg
ICAgfQotICAgIGVsc2UKLSAgICB7Ci0gICAgICAgIC8qIG5ldyB2TUNFIGNvbWVzIHdoaWxlIGZp
cnN0IG9uZSBoYXMgbm90IGJlZW4gaW5qZWN0ZWQgeWV0LAotICAgICAgICAgKiBpbiB0aGlzIGNh
c2UsIGluamVjdCBmYWlsLiBbV2UgY2FuJ3QgbG9zZSB0aGlzIHZNQ0UgZm9yCi0gICAgICAgICAq
IHRoZSBtY2Ugbm9kZSdzIGNvbnNpc3RlbmN5XS4KLSAgICAgICAgICovCi0gICAgICAgIG1jZV9w
cmludGsoTUNFX1FVSUVULCAiVGhlcmUncyBhIHBlbmRpbmcgdk1DRSB3YWl0aW5nIHRvIGJlIGlu
amVjdGVkICIKLSAgICAgICAgICAgICAgICAgICAiIHRvIHRoaXMgRE9NJWQhXG4iLCBkLT5kb21h
aW5faWQpOwotICAgICAgICByZXR1cm4gLTE7Ci0gICAgfQorCiAgICAgcmV0dXJuIDA7CiB9CiAK

--_002_DE8DF0795D48FD4CA783C40EC8292335330591SHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 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_DE8DF0795D48FD4CA783C40EC8292335330591SHSMSX101ccrcorpi_--


From xen-devel-bounces@lists.xen.org Wed Sep 19 08:10:11 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Sep 2012 08:10:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TEFM5-0004o6-K4; Wed, 19 Sep 2012 08:09:57 +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 1TEFM3-0004nz-O8
	for xen-devel@lists.xensource.com; Wed, 19 Sep 2012 08:09:56 +0000
Received: from [85.158.137.99:10957] by server-2.bemta-3.messagelabs.com id
	63/06-04862-2DD79505; Wed, 19 Sep 2012 08:09:54 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-5.tower-217.messagelabs.com!1348042193!13518203!1
X-Originating-IP: [192.55.52.88]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjg4ID0+IDMyMTU3Nw==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15055 invoked from network); 19 Sep 2012 08:09:53 -0000
Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88)
	by server-5.tower-217.messagelabs.com with SMTP;
	19 Sep 2012 08:09:53 -0000
Received: from fmsmga002.fm.intel.com ([10.253.24.26])
	by fmsmga101.fm.intel.com with ESMTP; 19 Sep 2012 01:09:52 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.80,447,1344236400"; d="scan'208";a="223948265"
Received: from fmsmsx107.amr.corp.intel.com ([10.19.9.54])
	by fmsmga002.fm.intel.com with ESMTP; 19 Sep 2012 01:09:52 -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; Wed, 19 Sep 2012 01:09:51 -0700
Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by
	fmsmsx109.amr.corp.intel.com (10.19.9.28) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Wed, 19 Sep 2012 01:09:51 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.239]) by
	SHSMSX102.ccr.corp.intel.com ([169.254.2.92]) with mapi id
	14.01.0355.002; Wed, 19 Sep 2012 16:09:49 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: Jan Beulich <JBeulich@suse.com>, "xen-devel@lists.xensource.com"
	<xen-devel@lists.xensource.com>
Thread-Topic: [PATCH 3/5] Xen/MCE: vMCE save and restore
Thread-Index: Ac2WPiNtCjAUXs2FSqq9zE7NWCrWxA==
Date: Wed, 19 Sep 2012 08:09:49 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC82923353305C2@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_DE8DF0795D48FD4CA783C40EC82923353305C2SHSMSX101ccrcorpi_"
MIME-Version: 1.0
Cc: Christoph Egger <Christoph.Egger@amd.com>, "keir@xen.org" <keir@xen.org>,
	"Ian.Campbell@citrix.com" <Ian.Campbell@citrix.com>
Subject: [Xen-devel] [PATCH 3/5] Xen/MCE: vMCE save and restore
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<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_DE8DF0795D48FD4CA783C40EC82923353305C2SHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Xen/MCE: vMCE save and restore

This patch provide vMCE save/restore when migration.
1. MCG_CAP is well-defined. However, considering future cap extension, we k=
eep save/restore logic that Jan implement at c/s 24887;
2. MCi_CTL2 initialized by guestos when booting, so need save/restore other=
wise guest would surprise;
3. Other MSRs do not need save/restore since they are either error-related =
and pointless to save/restore, or, unified among all vMCE platform;

Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>

diff -r 1c7eae1e7d67 tools/misc/xen-hvmctx.c
--- a/tools/misc/xen-hvmctx.c	Tue Sep 18 23:46:39 2012 +0800
+++ b/tools/misc/xen-hvmctx.c	Wed Sep 19 01:21:18 2012 +0800
@@ -388,6 +388,8 @@
     HVM_SAVE_TYPE(VMCE_VCPU) p;
     READ(p);
     printf("    VMCE_VCPU: caps %" PRIx64 "\n", p.caps);
+    printf("    VMCE_VCPU: bank0 mci_ctl2 %" PRIx64 "\n", p.mci_ctl2_bank0=
);
+    printf("    VMCE_VCPU: bank1 mci_ctl2 %" PRIx64 "\n", p.mci_ctl2_bank1=
);
 }
=20
 int main(int argc, char **argv)
diff -r 1c7eae1e7d67 xen/arch/x86/cpu/mcheck/vmce.c
--- a/xen/arch/x86/cpu/mcheck/vmce.c	Tue Sep 18 23:46:39 2012 +0800
+++ b/xen/arch/x86/cpu/mcheck/vmce.c	Wed Sep 19 01:21:18 2012 +0800
@@ -55,9 +55,10 @@
     spin_lock_init(&v->arch.vmce.lock);
 }
=20
-int vmce_restore_vcpu(struct vcpu *v, uint64_t caps)
+int vmce_restore_vcpu(struct vcpu *v, struct hvm_vmce_vcpu *ctxt)
 {
     uint64_t guest_mcg_cap;
+    uint64_t caps =3D ctxt->caps;
=20
     if ( boot_cpu_data.x86_vendor =3D=3D X86_VENDOR_INTEL )
         guest_mcg_cap =3D INTEL_GUEST_MCG_CAP;
@@ -74,6 +75,9 @@
     }
=20
     v->arch.vmce.mcg_cap =3D caps;
+    v->arch.vmce.bank[0].mci_ctl2 =3D ctxt->mci_ctl2_bank0;
+    v->arch.vmce.bank[1].mci_ctl2 =3D ctxt->mci_ctl2_bank1;
+
     return 0;
 }
=20
@@ -305,7 +309,9 @@
=20
     for_each_vcpu( d, v ) {
         struct hvm_vmce_vcpu ctxt =3D {
-            .caps =3D v->arch.vmce.mcg_cap
+            .caps =3D v->arch.vmce.mcg_cap,
+            .mci_ctl2_bank0 =3D v->arch.vmce.bank[0].mci_ctl2,
+            .mci_ctl2_bank1 =3D v->arch.vmce.bank[1].mci_ctl2
         };
=20
         err =3D hvm_save_entry(VMCE_VCPU, v->vcpu_id, h, &ctxt);
@@ -330,9 +336,9 @@
         err =3D -EINVAL;
     }
     else
-        err =3D hvm_load_entry(VMCE_VCPU, h, &ctxt);
+        err =3D hvm_load_entry_zeroextend(VMCE_VCPU, h, &ctxt);
=20
-    return err ?: vmce_restore_vcpu(v, ctxt.caps);
+    return err ?: vmce_restore_vcpu(v, &ctxt);
 }
=20
 HVM_REGISTER_SAVE_RESTORE(VMCE_VCPU, vmce_save_vcpu_ctxt,
diff -r 1c7eae1e7d67 xen/arch/x86/domctl.c
--- a/xen/arch/x86/domctl.c	Tue Sep 18 23:46:39 2012 +0800
+++ b/xen/arch/x86/domctl.c	Wed Sep 19 01:21:18 2012 +0800
@@ -1024,12 +1024,14 @@
                 evc->syscall32_callback_eip    =3D 0;
                 evc->syscall32_disables_events =3D 0;
             }
-            evc->mcg_cap =3D v->arch.vmce.mcg_cap;
+            evc->vmce.caps =3D v->arch.vmce.mcg_cap;
+            evc->vmce.mci_ctl2_bank0 =3D v->arch.vmce.bank[0].mci_ctl2;
+            evc->vmce.mci_ctl2_bank1 =3D v->arch.vmce.bank[1].mci_ctl2;
         }
         else
         {
             ret =3D -EINVAL;
-            if ( evc->size < offsetof(typeof(*evc), mcg_cap) )
+            if ( evc->size < offsetof(typeof(*evc), vmce) )
                 goto ext_vcpucontext_out;
             if ( !is_hvm_domain(d) )
             {
@@ -1059,9 +1061,9 @@
                  evc->syscall32_callback_eip )
                 goto ext_vcpucontext_out;
=20
-            if ( evc->size >=3D offsetof(typeof(*evc), mcg_cap) +
-                              sizeof(evc->mcg_cap) )
-                ret =3D vmce_restore_vcpu(v, evc->mcg_cap);
+            if ( evc->size >=3D offsetof(typeof(*evc), vmce) +
+                              sizeof(evc->vmce) );
+                ret =3D vmce_restore_vcpu(v, &evc->vmce);
         }
=20
         ret =3D 0;
diff -r 1c7eae1e7d67 xen/include/asm-x86/mce.h
--- a/xen/include/asm-x86/mce.h	Tue Sep 18 23:46:39 2012 +0800
+++ b/xen/include/asm-x86/mce.h	Wed Sep 19 01:21:18 2012 +0800
@@ -48,7 +48,7 @@
=20
 /* Guest vMCE MSRs virtualization */
 extern void vmce_init_vcpu(struct vcpu *);
-extern int vmce_restore_vcpu(struct vcpu *, uint64_t caps);
+extern int vmce_restore_vcpu(struct vcpu *, struct hvm_vmce_vcpu *ctxt);
 extern int vmce_wrmsr(uint32_t msr, uint64_t val);
 extern int vmce_rdmsr(uint32_t msr, uint64_t *val);
=20
diff -r 1c7eae1e7d67 xen/include/public/arch-x86/hvm/save.h
--- a/xen/include/public/arch-x86/hvm/save.h	Tue Sep 18 23:46:39 2012 +0800
+++ b/xen/include/public/arch-x86/hvm/save.h	Wed Sep 19 01:21:18 2012 +0800
@@ -577,6 +577,8 @@
=20
 struct hvm_vmce_vcpu {
     uint64_t caps;
+    uint64_t mci_ctl2_bank0;
+    uint64_t mci_ctl2_bank1;
 };
=20
 DECLARE_HVM_SAVE_TYPE(VMCE_VCPU, 18, struct hvm_vmce_vcpu);
diff -r 1c7eae1e7d67 xen/include/public/domctl.h
--- a/xen/include/public/domctl.h	Tue Sep 18 23:46:39 2012 +0800
+++ b/xen/include/public/domctl.h	Wed Sep 19 01:21:18 2012 +0800
@@ -32,6 +32,7 @@
 #error "domctl operations are intended for use by node control tools only"
 #endif
=20
+#include <xen/hvm/save.h>
 #include "xen.h"
 #include "grant_table.h"
=20
@@ -564,7 +565,7 @@
     uint16_t         sysenter_callback_cs;
     uint8_t          syscall32_disables_events;
     uint8_t          sysenter_disables_events;
-    uint64_aligned_t mcg_cap;
+    struct hvm_vmce_vcpu vmce;
 #endif
 };
 typedef struct xen_domctl_ext_vcpucontext xen_domctl_ext_vcpucontext_t;=

--_002_DE8DF0795D48FD4CA783C40EC82923353305C2SHSMSX101ccrcorpi_
Content-Type: application/octet-stream; name="3_vmce_save_restore.patch"
Content-Description: 3_vmce_save_restore.patch
Content-Disposition: attachment; filename="3_vmce_save_restore.patch";
	size=5381; creation-date="Wed, 19 Sep 2012 07:39:51 GMT";
	modification-date="Wed, 19 Sep 2012 15:27:32 GMT"
Content-Transfer-Encoding: base64

WGVuL01DRTogdk1DRSBzYXZlIGFuZCByZXN0b3JlCgpUaGlzIHBhdGNoIHByb3ZpZGUgdk1DRSBz
YXZlL3Jlc3RvcmUgd2hlbiBtaWdyYXRpb24uCjEuIE1DR19DQVAgaXMgd2VsbC1kZWZpbmVkLiBI
b3dldmVyLCBjb25zaWRlcmluZyBmdXR1cmUgY2FwIGV4dGVuc2lvbiwgd2Uga2VlcCBzYXZlL3Jl
c3RvcmUgbG9naWMgdGhhdCBKYW4gaW1wbGVtZW50IGF0IGMvcyAyNDg4NzsKMi4gTUNpX0NUTDIg
aW5pdGlhbGl6ZWQgYnkgZ3Vlc3RvcyB3aGVuIGJvb3RpbmcsIHNvIG5lZWQgc2F2ZS9yZXN0b3Jl
IG90aGVyd2lzZSBndWVzdCB3b3VsZCBzdXJwcmlzZTsKMy4gT3RoZXIgTVNScyBkbyBub3QgbmVl
ZCBzYXZlL3Jlc3RvcmUgc2luY2UgdGhleSBhcmUgZWl0aGVyIGVycm9yLXJlbGF0ZWQgYW5kIHBv
aW50bGVzcyB0byBzYXZlL3Jlc3RvcmUsIG9yLCB1bmlmaWVkIGFtb25nIGFsbCB2TUNFIHBsYXRm
b3JtOwoKU2lnbmVkLW9mZi1ieTogTGl1LCBKaW5zb25nIDxqaW5zb25nLmxpdUBpbnRlbC5jb20+
CgpkaWZmIC1yIDFjN2VhZTFlN2Q2NyB0b29scy9taXNjL3hlbi1odm1jdHguYwotLS0gYS90b29s
cy9taXNjL3hlbi1odm1jdHguYwlUdWUgU2VwIDE4IDIzOjQ2OjM5IDIwMTIgKzA4MDAKKysrIGIv
dG9vbHMvbWlzYy94ZW4taHZtY3R4LmMJV2VkIFNlcCAxOSAwMToyMToxOCAyMDEyICswODAwCkBA
IC0zODgsNiArMzg4LDggQEAKICAgICBIVk1fU0FWRV9UWVBFKFZNQ0VfVkNQVSkgcDsKICAgICBS
RUFEKHApOwogICAgIHByaW50ZigiICAgIFZNQ0VfVkNQVTogY2FwcyAlIiBQUkl4NjQgIlxuIiwg
cC5jYXBzKTsKKyAgICBwcmludGYoIiAgICBWTUNFX1ZDUFU6IGJhbmswIG1jaV9jdGwyICUiIFBS
SXg2NCAiXG4iLCBwLm1jaV9jdGwyX2JhbmswKTsKKyAgICBwcmludGYoIiAgICBWTUNFX1ZDUFU6
IGJhbmsxIG1jaV9jdGwyICUiIFBSSXg2NCAiXG4iLCBwLm1jaV9jdGwyX2JhbmsxKTsKIH0KIAog
aW50IG1haW4oaW50IGFyZ2MsIGNoYXIgKiphcmd2KQpkaWZmIC1yIDFjN2VhZTFlN2Q2NyB4ZW4v
YXJjaC94ODYvY3B1L21jaGVjay92bWNlLmMKLS0tIGEveGVuL2FyY2gveDg2L2NwdS9tY2hlY2sv
dm1jZS5jCVR1ZSBTZXAgMTggMjM6NDY6MzkgMjAxMiArMDgwMAorKysgYi94ZW4vYXJjaC94ODYv
Y3B1L21jaGVjay92bWNlLmMJV2VkIFNlcCAxOSAwMToyMToxOCAyMDEyICswODAwCkBAIC01NSw5
ICs1NSwxMCBAQAogICAgIHNwaW5fbG9ja19pbml0KCZ2LT5hcmNoLnZtY2UubG9jayk7CiB9CiAK
LWludCB2bWNlX3Jlc3RvcmVfdmNwdShzdHJ1Y3QgdmNwdSAqdiwgdWludDY0X3QgY2FwcykKK2lu
dCB2bWNlX3Jlc3RvcmVfdmNwdShzdHJ1Y3QgdmNwdSAqdiwgc3RydWN0IGh2bV92bWNlX3ZjcHUg
KmN0eHQpCiB7CiAgICAgdWludDY0X3QgZ3Vlc3RfbWNnX2NhcDsKKyAgICB1aW50NjRfdCBjYXBz
ID0gY3R4dC0+Y2FwczsKIAogICAgIGlmICggYm9vdF9jcHVfZGF0YS54ODZfdmVuZG9yID09IFg4
Nl9WRU5ET1JfSU5URUwgKQogICAgICAgICBndWVzdF9tY2dfY2FwID0gSU5URUxfR1VFU1RfTUNH
X0NBUDsKQEAgLTc0LDYgKzc1LDkgQEAKICAgICB9CiAKICAgICB2LT5hcmNoLnZtY2UubWNnX2Nh
cCA9IGNhcHM7CisgICAgdi0+YXJjaC52bWNlLmJhbmtbMF0ubWNpX2N0bDIgPSBjdHh0LT5tY2lf
Y3RsMl9iYW5rMDsKKyAgICB2LT5hcmNoLnZtY2UuYmFua1sxXS5tY2lfY3RsMiA9IGN0eHQtPm1j
aV9jdGwyX2JhbmsxOworCiAgICAgcmV0dXJuIDA7CiB9CiAKQEAgLTMwNSw3ICszMDksOSBAQAog
CiAgICAgZm9yX2VhY2hfdmNwdSggZCwgdiApIHsKICAgICAgICAgc3RydWN0IGh2bV92bWNlX3Zj
cHUgY3R4dCA9IHsKLSAgICAgICAgICAgIC5jYXBzID0gdi0+YXJjaC52bWNlLm1jZ19jYXAKKyAg
ICAgICAgICAgIC5jYXBzID0gdi0+YXJjaC52bWNlLm1jZ19jYXAsCisgICAgICAgICAgICAubWNp
X2N0bDJfYmFuazAgPSB2LT5hcmNoLnZtY2UuYmFua1swXS5tY2lfY3RsMiwKKyAgICAgICAgICAg
IC5tY2lfY3RsMl9iYW5rMSA9IHYtPmFyY2gudm1jZS5iYW5rWzFdLm1jaV9jdGwyCiAgICAgICAg
IH07CiAKICAgICAgICAgZXJyID0gaHZtX3NhdmVfZW50cnkoVk1DRV9WQ1BVLCB2LT52Y3B1X2lk
LCBoLCAmY3R4dCk7CkBAIC0zMzAsOSArMzM2LDkgQEAKICAgICAgICAgZXJyID0gLUVJTlZBTDsK
ICAgICB9CiAgICAgZWxzZQotICAgICAgICBlcnIgPSBodm1fbG9hZF9lbnRyeShWTUNFX1ZDUFUs
IGgsICZjdHh0KTsKKyAgICAgICAgZXJyID0gaHZtX2xvYWRfZW50cnlfemVyb2V4dGVuZChWTUNF
X1ZDUFUsIGgsICZjdHh0KTsKIAotICAgIHJldHVybiBlcnIgPzogdm1jZV9yZXN0b3JlX3ZjcHUo
diwgY3R4dC5jYXBzKTsKKyAgICByZXR1cm4gZXJyID86IHZtY2VfcmVzdG9yZV92Y3B1KHYsICZj
dHh0KTsKIH0KIAogSFZNX1JFR0lTVEVSX1NBVkVfUkVTVE9SRShWTUNFX1ZDUFUsIHZtY2Vfc2F2
ZV92Y3B1X2N0eHQsCmRpZmYgLXIgMWM3ZWFlMWU3ZDY3IHhlbi9hcmNoL3g4Ni9kb21jdGwuYwot
LS0gYS94ZW4vYXJjaC94ODYvZG9tY3RsLmMJVHVlIFNlcCAxOCAyMzo0NjozOSAyMDEyICswODAw
CisrKyBiL3hlbi9hcmNoL3g4Ni9kb21jdGwuYwlXZWQgU2VwIDE5IDAxOjIxOjE4IDIwMTIgKzA4
MDAKQEAgLTEwMjQsMTIgKzEwMjQsMTQgQEAKICAgICAgICAgICAgICAgICBldmMtPnN5c2NhbGwz
Ml9jYWxsYmFja19laXAgICAgPSAwOwogICAgICAgICAgICAgICAgIGV2Yy0+c3lzY2FsbDMyX2Rp
c2FibGVzX2V2ZW50cyA9IDA7CiAgICAgICAgICAgICB9Ci0gICAgICAgICAgICBldmMtPm1jZ19j
YXAgPSB2LT5hcmNoLnZtY2UubWNnX2NhcDsKKyAgICAgICAgICAgIGV2Yy0+dm1jZS5jYXBzID0g
di0+YXJjaC52bWNlLm1jZ19jYXA7CisgICAgICAgICAgICBldmMtPnZtY2UubWNpX2N0bDJfYmFu
azAgPSB2LT5hcmNoLnZtY2UuYmFua1swXS5tY2lfY3RsMjsKKyAgICAgICAgICAgIGV2Yy0+dm1j
ZS5tY2lfY3RsMl9iYW5rMSA9IHYtPmFyY2gudm1jZS5iYW5rWzFdLm1jaV9jdGwyOwogICAgICAg
ICB9CiAgICAgICAgIGVsc2UKICAgICAgICAgewogICAgICAgICAgICAgcmV0ID0gLUVJTlZBTDsK
LSAgICAgICAgICAgIGlmICggZXZjLT5zaXplIDwgb2Zmc2V0b2YodHlwZW9mKCpldmMpLCBtY2df
Y2FwKSApCisgICAgICAgICAgICBpZiAoIGV2Yy0+c2l6ZSA8IG9mZnNldG9mKHR5cGVvZigqZXZj
KSwgdm1jZSkgKQogICAgICAgICAgICAgICAgIGdvdG8gZXh0X3ZjcHVjb250ZXh0X291dDsKICAg
ICAgICAgICAgIGlmICggIWlzX2h2bV9kb21haW4oZCkgKQogICAgICAgICAgICAgewpAQCAtMTA1
OSw5ICsxMDYxLDkgQEAKICAgICAgICAgICAgICAgICAgZXZjLT5zeXNjYWxsMzJfY2FsbGJhY2tf
ZWlwICkKICAgICAgICAgICAgICAgICBnb3RvIGV4dF92Y3B1Y29udGV4dF9vdXQ7CiAKLSAgICAg
ICAgICAgIGlmICggZXZjLT5zaXplID49IG9mZnNldG9mKHR5cGVvZigqZXZjKSwgbWNnX2NhcCkg
KwotICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgc2l6ZW9mKGV2Yy0+bWNnX2NhcCkgKQot
ICAgICAgICAgICAgICAgIHJldCA9IHZtY2VfcmVzdG9yZV92Y3B1KHYsIGV2Yy0+bWNnX2NhcCk7
CisgICAgICAgICAgICBpZiAoIGV2Yy0+c2l6ZSA+PSBvZmZzZXRvZih0eXBlb2YoKmV2YyksIHZt
Y2UpICsKKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHNpemVvZihldmMtPnZtY2UpICk7
CisgICAgICAgICAgICAgICAgcmV0ID0gdm1jZV9yZXN0b3JlX3ZjcHUodiwgJmV2Yy0+dm1jZSk7
CiAgICAgICAgIH0KIAogICAgICAgICByZXQgPSAwOwpkaWZmIC1yIDFjN2VhZTFlN2Q2NyB4ZW4v
aW5jbHVkZS9hc20teDg2L21jZS5oCi0tLSBhL3hlbi9pbmNsdWRlL2FzbS14ODYvbWNlLmgJVHVl
IFNlcCAxOCAyMzo0NjozOSAyMDEyICswODAwCisrKyBiL3hlbi9pbmNsdWRlL2FzbS14ODYvbWNl
LmgJV2VkIFNlcCAxOSAwMToyMToxOCAyMDEyICswODAwCkBAIC00OCw3ICs0OCw3IEBACiAKIC8q
IEd1ZXN0IHZNQ0UgTVNScyB2aXJ0dWFsaXphdGlvbiAqLwogZXh0ZXJuIHZvaWQgdm1jZV9pbml0
X3ZjcHUoc3RydWN0IHZjcHUgKik7Ci1leHRlcm4gaW50IHZtY2VfcmVzdG9yZV92Y3B1KHN0cnVj
dCB2Y3B1ICosIHVpbnQ2NF90IGNhcHMpOworZXh0ZXJuIGludCB2bWNlX3Jlc3RvcmVfdmNwdShz
dHJ1Y3QgdmNwdSAqLCBzdHJ1Y3QgaHZtX3ZtY2VfdmNwdSAqY3R4dCk7CiBleHRlcm4gaW50IHZt
Y2Vfd3Jtc3IodWludDMyX3QgbXNyLCB1aW50NjRfdCB2YWwpOwogZXh0ZXJuIGludCB2bWNlX3Jk
bXNyKHVpbnQzMl90IG1zciwgdWludDY0X3QgKnZhbCk7CiAKZGlmZiAtciAxYzdlYWUxZTdkNjcg
eGVuL2luY2x1ZGUvcHVibGljL2FyY2gteDg2L2h2bS9zYXZlLmgKLS0tIGEveGVuL2luY2x1ZGUv
cHVibGljL2FyY2gteDg2L2h2bS9zYXZlLmgJVHVlIFNlcCAxOCAyMzo0NjozOSAyMDEyICswODAw
CisrKyBiL3hlbi9pbmNsdWRlL3B1YmxpYy9hcmNoLXg4Ni9odm0vc2F2ZS5oCVdlZCBTZXAgMTkg
MDE6MjE6MTggMjAxMiArMDgwMApAQCAtNTc3LDYgKzU3Nyw4IEBACiAKIHN0cnVjdCBodm1fdm1j
ZV92Y3B1IHsKICAgICB1aW50NjRfdCBjYXBzOworICAgIHVpbnQ2NF90IG1jaV9jdGwyX2Jhbmsw
OworICAgIHVpbnQ2NF90IG1jaV9jdGwyX2JhbmsxOwogfTsKIAogREVDTEFSRV9IVk1fU0FWRV9U
WVBFKFZNQ0VfVkNQVSwgMTgsIHN0cnVjdCBodm1fdm1jZV92Y3B1KTsKZGlmZiAtciAxYzdlYWUx
ZTdkNjcgeGVuL2luY2x1ZGUvcHVibGljL2RvbWN0bC5oCi0tLSBhL3hlbi9pbmNsdWRlL3B1Ymxp
Yy9kb21jdGwuaAlUdWUgU2VwIDE4IDIzOjQ2OjM5IDIwMTIgKzA4MDAKKysrIGIveGVuL2luY2x1
ZGUvcHVibGljL2RvbWN0bC5oCVdlZCBTZXAgMTkgMDE6MjE6MTggMjAxMiArMDgwMApAQCAtMzIs
NiArMzIsNyBAQAogI2Vycm9yICJkb21jdGwgb3BlcmF0aW9ucyBhcmUgaW50ZW5kZWQgZm9yIHVz
ZSBieSBub2RlIGNvbnRyb2wgdG9vbHMgb25seSIKICNlbmRpZgogCisjaW5jbHVkZSA8eGVuL2h2
bS9zYXZlLmg+CiAjaW5jbHVkZSAieGVuLmgiCiAjaW5jbHVkZSAiZ3JhbnRfdGFibGUuaCIKIApA
QCAtNTY0LDcgKzU2NSw3IEBACiAgICAgdWludDE2X3QgICAgICAgICBzeXNlbnRlcl9jYWxsYmFj
a19jczsKICAgICB1aW50OF90ICAgICAgICAgIHN5c2NhbGwzMl9kaXNhYmxlc19ldmVudHM7CiAg
ICAgdWludDhfdCAgICAgICAgICBzeXNlbnRlcl9kaXNhYmxlc19ldmVudHM7Ci0gICAgdWludDY0
X2FsaWduZWRfdCBtY2dfY2FwOworICAgIHN0cnVjdCBodm1fdm1jZV92Y3B1IHZtY2U7CiAjZW5k
aWYKIH07CiB0eXBlZGVmIHN0cnVjdCB4ZW5fZG9tY3RsX2V4dF92Y3B1Y29udGV4dCB4ZW5fZG9t
Y3RsX2V4dF92Y3B1Y29udGV4dF90Owo=

--_002_DE8DF0795D48FD4CA783C40EC82923353305C2SHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 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_DE8DF0795D48FD4CA783C40EC82923353305C2SHSMSX101ccrcorpi_--


From xen-devel-bounces@lists.xen.org Wed Sep 19 08:10:11 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Sep 2012 08:10:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TEFM5-0004o6-K4; Wed, 19 Sep 2012 08:09:57 +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 1TEFM3-0004nz-O8
	for xen-devel@lists.xensource.com; Wed, 19 Sep 2012 08:09:56 +0000
Received: from [85.158.137.99:10957] by server-2.bemta-3.messagelabs.com id
	63/06-04862-2DD79505; Wed, 19 Sep 2012 08:09:54 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-5.tower-217.messagelabs.com!1348042193!13518203!1
X-Originating-IP: [192.55.52.88]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjg4ID0+IDMyMTU3Nw==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15055 invoked from network); 19 Sep 2012 08:09:53 -0000
Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88)
	by server-5.tower-217.messagelabs.com with SMTP;
	19 Sep 2012 08:09:53 -0000
Received: from fmsmga002.fm.intel.com ([10.253.24.26])
	by fmsmga101.fm.intel.com with ESMTP; 19 Sep 2012 01:09:52 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.80,447,1344236400"; d="scan'208";a="223948265"
Received: from fmsmsx107.amr.corp.intel.com ([10.19.9.54])
	by fmsmga002.fm.intel.com with ESMTP; 19 Sep 2012 01:09:52 -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; Wed, 19 Sep 2012 01:09:51 -0700
Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by
	fmsmsx109.amr.corp.intel.com (10.19.9.28) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Wed, 19 Sep 2012 01:09:51 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.239]) by
	SHSMSX102.ccr.corp.intel.com ([169.254.2.92]) with mapi id
	14.01.0355.002; Wed, 19 Sep 2012 16:09:49 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: Jan Beulich <JBeulich@suse.com>, "xen-devel@lists.xensource.com"
	<xen-devel@lists.xensource.com>
Thread-Topic: [PATCH 3/5] Xen/MCE: vMCE save and restore
Thread-Index: Ac2WPiNtCjAUXs2FSqq9zE7NWCrWxA==
Date: Wed, 19 Sep 2012 08:09:49 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC82923353305C2@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_DE8DF0795D48FD4CA783C40EC82923353305C2SHSMSX101ccrcorpi_"
MIME-Version: 1.0
Cc: Christoph Egger <Christoph.Egger@amd.com>, "keir@xen.org" <keir@xen.org>,
	"Ian.Campbell@citrix.com" <Ian.Campbell@citrix.com>
Subject: [Xen-devel] [PATCH 3/5] Xen/MCE: vMCE save and restore
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<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_DE8DF0795D48FD4CA783C40EC82923353305C2SHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Xen/MCE: vMCE save and restore

This patch provide vMCE save/restore when migration.
1. MCG_CAP is well-defined. However, considering future cap extension, we k=
eep save/restore logic that Jan implement at c/s 24887;
2. MCi_CTL2 initialized by guestos when booting, so need save/restore other=
wise guest would surprise;
3. Other MSRs do not need save/restore since they are either error-related =
and pointless to save/restore, or, unified among all vMCE platform;

Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>

diff -r 1c7eae1e7d67 tools/misc/xen-hvmctx.c
--- a/tools/misc/xen-hvmctx.c	Tue Sep 18 23:46:39 2012 +0800
+++ b/tools/misc/xen-hvmctx.c	Wed Sep 19 01:21:18 2012 +0800
@@ -388,6 +388,8 @@
     HVM_SAVE_TYPE(VMCE_VCPU) p;
     READ(p);
     printf("    VMCE_VCPU: caps %" PRIx64 "\n", p.caps);
+    printf("    VMCE_VCPU: bank0 mci_ctl2 %" PRIx64 "\n", p.mci_ctl2_bank0=
);
+    printf("    VMCE_VCPU: bank1 mci_ctl2 %" PRIx64 "\n", p.mci_ctl2_bank1=
);
 }
=20
 int main(int argc, char **argv)
diff -r 1c7eae1e7d67 xen/arch/x86/cpu/mcheck/vmce.c
--- a/xen/arch/x86/cpu/mcheck/vmce.c	Tue Sep 18 23:46:39 2012 +0800
+++ b/xen/arch/x86/cpu/mcheck/vmce.c	Wed Sep 19 01:21:18 2012 +0800
@@ -55,9 +55,10 @@
     spin_lock_init(&v->arch.vmce.lock);
 }
=20
-int vmce_restore_vcpu(struct vcpu *v, uint64_t caps)
+int vmce_restore_vcpu(struct vcpu *v, struct hvm_vmce_vcpu *ctxt)
 {
     uint64_t guest_mcg_cap;
+    uint64_t caps =3D ctxt->caps;
=20
     if ( boot_cpu_data.x86_vendor =3D=3D X86_VENDOR_INTEL )
         guest_mcg_cap =3D INTEL_GUEST_MCG_CAP;
@@ -74,6 +75,9 @@
     }
=20
     v->arch.vmce.mcg_cap =3D caps;
+    v->arch.vmce.bank[0].mci_ctl2 =3D ctxt->mci_ctl2_bank0;
+    v->arch.vmce.bank[1].mci_ctl2 =3D ctxt->mci_ctl2_bank1;
+
     return 0;
 }
=20
@@ -305,7 +309,9 @@
=20
     for_each_vcpu( d, v ) {
         struct hvm_vmce_vcpu ctxt =3D {
-            .caps =3D v->arch.vmce.mcg_cap
+            .caps =3D v->arch.vmce.mcg_cap,
+            .mci_ctl2_bank0 =3D v->arch.vmce.bank[0].mci_ctl2,
+            .mci_ctl2_bank1 =3D v->arch.vmce.bank[1].mci_ctl2
         };
=20
         err =3D hvm_save_entry(VMCE_VCPU, v->vcpu_id, h, &ctxt);
@@ -330,9 +336,9 @@
         err =3D -EINVAL;
     }
     else
-        err =3D hvm_load_entry(VMCE_VCPU, h, &ctxt);
+        err =3D hvm_load_entry_zeroextend(VMCE_VCPU, h, &ctxt);
=20
-    return err ?: vmce_restore_vcpu(v, ctxt.caps);
+    return err ?: vmce_restore_vcpu(v, &ctxt);
 }
=20
 HVM_REGISTER_SAVE_RESTORE(VMCE_VCPU, vmce_save_vcpu_ctxt,
diff -r 1c7eae1e7d67 xen/arch/x86/domctl.c
--- a/xen/arch/x86/domctl.c	Tue Sep 18 23:46:39 2012 +0800
+++ b/xen/arch/x86/domctl.c	Wed Sep 19 01:21:18 2012 +0800
@@ -1024,12 +1024,14 @@
                 evc->syscall32_callback_eip    =3D 0;
                 evc->syscall32_disables_events =3D 0;
             }
-            evc->mcg_cap =3D v->arch.vmce.mcg_cap;
+            evc->vmce.caps =3D v->arch.vmce.mcg_cap;
+            evc->vmce.mci_ctl2_bank0 =3D v->arch.vmce.bank[0].mci_ctl2;
+            evc->vmce.mci_ctl2_bank1 =3D v->arch.vmce.bank[1].mci_ctl2;
         }
         else
         {
             ret =3D -EINVAL;
-            if ( evc->size < offsetof(typeof(*evc), mcg_cap) )
+            if ( evc->size < offsetof(typeof(*evc), vmce) )
                 goto ext_vcpucontext_out;
             if ( !is_hvm_domain(d) )
             {
@@ -1059,9 +1061,9 @@
                  evc->syscall32_callback_eip )
                 goto ext_vcpucontext_out;
=20
-            if ( evc->size >=3D offsetof(typeof(*evc), mcg_cap) +
-                              sizeof(evc->mcg_cap) )
-                ret =3D vmce_restore_vcpu(v, evc->mcg_cap);
+            if ( evc->size >=3D offsetof(typeof(*evc), vmce) +
+                              sizeof(evc->vmce) );
+                ret =3D vmce_restore_vcpu(v, &evc->vmce);
         }
=20
         ret =3D 0;
diff -r 1c7eae1e7d67 xen/include/asm-x86/mce.h
--- a/xen/include/asm-x86/mce.h	Tue Sep 18 23:46:39 2012 +0800
+++ b/xen/include/asm-x86/mce.h	Wed Sep 19 01:21:18 2012 +0800
@@ -48,7 +48,7 @@
=20
 /* Guest vMCE MSRs virtualization */
 extern void vmce_init_vcpu(struct vcpu *);
-extern int vmce_restore_vcpu(struct vcpu *, uint64_t caps);
+extern int vmce_restore_vcpu(struct vcpu *, struct hvm_vmce_vcpu *ctxt);
 extern int vmce_wrmsr(uint32_t msr, uint64_t val);
 extern int vmce_rdmsr(uint32_t msr, uint64_t *val);
=20
diff -r 1c7eae1e7d67 xen/include/public/arch-x86/hvm/save.h
--- a/xen/include/public/arch-x86/hvm/save.h	Tue Sep 18 23:46:39 2012 +0800
+++ b/xen/include/public/arch-x86/hvm/save.h	Wed Sep 19 01:21:18 2012 +0800
@@ -577,6 +577,8 @@
=20
 struct hvm_vmce_vcpu {
     uint64_t caps;
+    uint64_t mci_ctl2_bank0;
+    uint64_t mci_ctl2_bank1;
 };
=20
 DECLARE_HVM_SAVE_TYPE(VMCE_VCPU, 18, struct hvm_vmce_vcpu);
diff -r 1c7eae1e7d67 xen/include/public/domctl.h
--- a/xen/include/public/domctl.h	Tue Sep 18 23:46:39 2012 +0800
+++ b/xen/include/public/domctl.h	Wed Sep 19 01:21:18 2012 +0800
@@ -32,6 +32,7 @@
 #error "domctl operations are intended for use by node control tools only"
 #endif
=20
+#include <xen/hvm/save.h>
 #include "xen.h"
 #include "grant_table.h"
=20
@@ -564,7 +565,7 @@
     uint16_t         sysenter_callback_cs;
     uint8_t          syscall32_disables_events;
     uint8_t          sysenter_disables_events;
-    uint64_aligned_t mcg_cap;
+    struct hvm_vmce_vcpu vmce;
 #endif
 };
 typedef struct xen_domctl_ext_vcpucontext xen_domctl_ext_vcpucontext_t;=

--_002_DE8DF0795D48FD4CA783C40EC82923353305C2SHSMSX101ccrcorpi_
Content-Type: application/octet-stream; name="3_vmce_save_restore.patch"
Content-Description: 3_vmce_save_restore.patch
Content-Disposition: attachment; filename="3_vmce_save_restore.patch";
	size=5381; creation-date="Wed, 19 Sep 2012 07:39:51 GMT";
	modification-date="Wed, 19 Sep 2012 15:27:32 GMT"
Content-Transfer-Encoding: base64

WGVuL01DRTogdk1DRSBzYXZlIGFuZCByZXN0b3JlCgpUaGlzIHBhdGNoIHByb3ZpZGUgdk1DRSBz
YXZlL3Jlc3RvcmUgd2hlbiBtaWdyYXRpb24uCjEuIE1DR19DQVAgaXMgd2VsbC1kZWZpbmVkLiBI
b3dldmVyLCBjb25zaWRlcmluZyBmdXR1cmUgY2FwIGV4dGVuc2lvbiwgd2Uga2VlcCBzYXZlL3Jl
c3RvcmUgbG9naWMgdGhhdCBKYW4gaW1wbGVtZW50IGF0IGMvcyAyNDg4NzsKMi4gTUNpX0NUTDIg
aW5pdGlhbGl6ZWQgYnkgZ3Vlc3RvcyB3aGVuIGJvb3RpbmcsIHNvIG5lZWQgc2F2ZS9yZXN0b3Jl
IG90aGVyd2lzZSBndWVzdCB3b3VsZCBzdXJwcmlzZTsKMy4gT3RoZXIgTVNScyBkbyBub3QgbmVl
ZCBzYXZlL3Jlc3RvcmUgc2luY2UgdGhleSBhcmUgZWl0aGVyIGVycm9yLXJlbGF0ZWQgYW5kIHBv
aW50bGVzcyB0byBzYXZlL3Jlc3RvcmUsIG9yLCB1bmlmaWVkIGFtb25nIGFsbCB2TUNFIHBsYXRm
b3JtOwoKU2lnbmVkLW9mZi1ieTogTGl1LCBKaW5zb25nIDxqaW5zb25nLmxpdUBpbnRlbC5jb20+
CgpkaWZmIC1yIDFjN2VhZTFlN2Q2NyB0b29scy9taXNjL3hlbi1odm1jdHguYwotLS0gYS90b29s
cy9taXNjL3hlbi1odm1jdHguYwlUdWUgU2VwIDE4IDIzOjQ2OjM5IDIwMTIgKzA4MDAKKysrIGIv
dG9vbHMvbWlzYy94ZW4taHZtY3R4LmMJV2VkIFNlcCAxOSAwMToyMToxOCAyMDEyICswODAwCkBA
IC0zODgsNiArMzg4LDggQEAKICAgICBIVk1fU0FWRV9UWVBFKFZNQ0VfVkNQVSkgcDsKICAgICBS
RUFEKHApOwogICAgIHByaW50ZigiICAgIFZNQ0VfVkNQVTogY2FwcyAlIiBQUkl4NjQgIlxuIiwg
cC5jYXBzKTsKKyAgICBwcmludGYoIiAgICBWTUNFX1ZDUFU6IGJhbmswIG1jaV9jdGwyICUiIFBS
SXg2NCAiXG4iLCBwLm1jaV9jdGwyX2JhbmswKTsKKyAgICBwcmludGYoIiAgICBWTUNFX1ZDUFU6
IGJhbmsxIG1jaV9jdGwyICUiIFBSSXg2NCAiXG4iLCBwLm1jaV9jdGwyX2JhbmsxKTsKIH0KIAog
aW50IG1haW4oaW50IGFyZ2MsIGNoYXIgKiphcmd2KQpkaWZmIC1yIDFjN2VhZTFlN2Q2NyB4ZW4v
YXJjaC94ODYvY3B1L21jaGVjay92bWNlLmMKLS0tIGEveGVuL2FyY2gveDg2L2NwdS9tY2hlY2sv
dm1jZS5jCVR1ZSBTZXAgMTggMjM6NDY6MzkgMjAxMiArMDgwMAorKysgYi94ZW4vYXJjaC94ODYv
Y3B1L21jaGVjay92bWNlLmMJV2VkIFNlcCAxOSAwMToyMToxOCAyMDEyICswODAwCkBAIC01NSw5
ICs1NSwxMCBAQAogICAgIHNwaW5fbG9ja19pbml0KCZ2LT5hcmNoLnZtY2UubG9jayk7CiB9CiAK
LWludCB2bWNlX3Jlc3RvcmVfdmNwdShzdHJ1Y3QgdmNwdSAqdiwgdWludDY0X3QgY2FwcykKK2lu
dCB2bWNlX3Jlc3RvcmVfdmNwdShzdHJ1Y3QgdmNwdSAqdiwgc3RydWN0IGh2bV92bWNlX3ZjcHUg
KmN0eHQpCiB7CiAgICAgdWludDY0X3QgZ3Vlc3RfbWNnX2NhcDsKKyAgICB1aW50NjRfdCBjYXBz
ID0gY3R4dC0+Y2FwczsKIAogICAgIGlmICggYm9vdF9jcHVfZGF0YS54ODZfdmVuZG9yID09IFg4
Nl9WRU5ET1JfSU5URUwgKQogICAgICAgICBndWVzdF9tY2dfY2FwID0gSU5URUxfR1VFU1RfTUNH
X0NBUDsKQEAgLTc0LDYgKzc1LDkgQEAKICAgICB9CiAKICAgICB2LT5hcmNoLnZtY2UubWNnX2Nh
cCA9IGNhcHM7CisgICAgdi0+YXJjaC52bWNlLmJhbmtbMF0ubWNpX2N0bDIgPSBjdHh0LT5tY2lf
Y3RsMl9iYW5rMDsKKyAgICB2LT5hcmNoLnZtY2UuYmFua1sxXS5tY2lfY3RsMiA9IGN0eHQtPm1j
aV9jdGwyX2JhbmsxOworCiAgICAgcmV0dXJuIDA7CiB9CiAKQEAgLTMwNSw3ICszMDksOSBAQAog
CiAgICAgZm9yX2VhY2hfdmNwdSggZCwgdiApIHsKICAgICAgICAgc3RydWN0IGh2bV92bWNlX3Zj
cHUgY3R4dCA9IHsKLSAgICAgICAgICAgIC5jYXBzID0gdi0+YXJjaC52bWNlLm1jZ19jYXAKKyAg
ICAgICAgICAgIC5jYXBzID0gdi0+YXJjaC52bWNlLm1jZ19jYXAsCisgICAgICAgICAgICAubWNp
X2N0bDJfYmFuazAgPSB2LT5hcmNoLnZtY2UuYmFua1swXS5tY2lfY3RsMiwKKyAgICAgICAgICAg
IC5tY2lfY3RsMl9iYW5rMSA9IHYtPmFyY2gudm1jZS5iYW5rWzFdLm1jaV9jdGwyCiAgICAgICAg
IH07CiAKICAgICAgICAgZXJyID0gaHZtX3NhdmVfZW50cnkoVk1DRV9WQ1BVLCB2LT52Y3B1X2lk
LCBoLCAmY3R4dCk7CkBAIC0zMzAsOSArMzM2LDkgQEAKICAgICAgICAgZXJyID0gLUVJTlZBTDsK
ICAgICB9CiAgICAgZWxzZQotICAgICAgICBlcnIgPSBodm1fbG9hZF9lbnRyeShWTUNFX1ZDUFUs
IGgsICZjdHh0KTsKKyAgICAgICAgZXJyID0gaHZtX2xvYWRfZW50cnlfemVyb2V4dGVuZChWTUNF
X1ZDUFUsIGgsICZjdHh0KTsKIAotICAgIHJldHVybiBlcnIgPzogdm1jZV9yZXN0b3JlX3ZjcHUo
diwgY3R4dC5jYXBzKTsKKyAgICByZXR1cm4gZXJyID86IHZtY2VfcmVzdG9yZV92Y3B1KHYsICZj
dHh0KTsKIH0KIAogSFZNX1JFR0lTVEVSX1NBVkVfUkVTVE9SRShWTUNFX1ZDUFUsIHZtY2Vfc2F2
ZV92Y3B1X2N0eHQsCmRpZmYgLXIgMWM3ZWFlMWU3ZDY3IHhlbi9hcmNoL3g4Ni9kb21jdGwuYwot
LS0gYS94ZW4vYXJjaC94ODYvZG9tY3RsLmMJVHVlIFNlcCAxOCAyMzo0NjozOSAyMDEyICswODAw
CisrKyBiL3hlbi9hcmNoL3g4Ni9kb21jdGwuYwlXZWQgU2VwIDE5IDAxOjIxOjE4IDIwMTIgKzA4
MDAKQEAgLTEwMjQsMTIgKzEwMjQsMTQgQEAKICAgICAgICAgICAgICAgICBldmMtPnN5c2NhbGwz
Ml9jYWxsYmFja19laXAgICAgPSAwOwogICAgICAgICAgICAgICAgIGV2Yy0+c3lzY2FsbDMyX2Rp
c2FibGVzX2V2ZW50cyA9IDA7CiAgICAgICAgICAgICB9Ci0gICAgICAgICAgICBldmMtPm1jZ19j
YXAgPSB2LT5hcmNoLnZtY2UubWNnX2NhcDsKKyAgICAgICAgICAgIGV2Yy0+dm1jZS5jYXBzID0g
di0+YXJjaC52bWNlLm1jZ19jYXA7CisgICAgICAgICAgICBldmMtPnZtY2UubWNpX2N0bDJfYmFu
azAgPSB2LT5hcmNoLnZtY2UuYmFua1swXS5tY2lfY3RsMjsKKyAgICAgICAgICAgIGV2Yy0+dm1j
ZS5tY2lfY3RsMl9iYW5rMSA9IHYtPmFyY2gudm1jZS5iYW5rWzFdLm1jaV9jdGwyOwogICAgICAg
ICB9CiAgICAgICAgIGVsc2UKICAgICAgICAgewogICAgICAgICAgICAgcmV0ID0gLUVJTlZBTDsK
LSAgICAgICAgICAgIGlmICggZXZjLT5zaXplIDwgb2Zmc2V0b2YodHlwZW9mKCpldmMpLCBtY2df
Y2FwKSApCisgICAgICAgICAgICBpZiAoIGV2Yy0+c2l6ZSA8IG9mZnNldG9mKHR5cGVvZigqZXZj
KSwgdm1jZSkgKQogICAgICAgICAgICAgICAgIGdvdG8gZXh0X3ZjcHVjb250ZXh0X291dDsKICAg
ICAgICAgICAgIGlmICggIWlzX2h2bV9kb21haW4oZCkgKQogICAgICAgICAgICAgewpAQCAtMTA1
OSw5ICsxMDYxLDkgQEAKICAgICAgICAgICAgICAgICAgZXZjLT5zeXNjYWxsMzJfY2FsbGJhY2tf
ZWlwICkKICAgICAgICAgICAgICAgICBnb3RvIGV4dF92Y3B1Y29udGV4dF9vdXQ7CiAKLSAgICAg
ICAgICAgIGlmICggZXZjLT5zaXplID49IG9mZnNldG9mKHR5cGVvZigqZXZjKSwgbWNnX2NhcCkg
KwotICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgc2l6ZW9mKGV2Yy0+bWNnX2NhcCkgKQot
ICAgICAgICAgICAgICAgIHJldCA9IHZtY2VfcmVzdG9yZV92Y3B1KHYsIGV2Yy0+bWNnX2NhcCk7
CisgICAgICAgICAgICBpZiAoIGV2Yy0+c2l6ZSA+PSBvZmZzZXRvZih0eXBlb2YoKmV2YyksIHZt
Y2UpICsKKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHNpemVvZihldmMtPnZtY2UpICk7
CisgICAgICAgICAgICAgICAgcmV0ID0gdm1jZV9yZXN0b3JlX3ZjcHUodiwgJmV2Yy0+dm1jZSk7
CiAgICAgICAgIH0KIAogICAgICAgICByZXQgPSAwOwpkaWZmIC1yIDFjN2VhZTFlN2Q2NyB4ZW4v
aW5jbHVkZS9hc20teDg2L21jZS5oCi0tLSBhL3hlbi9pbmNsdWRlL2FzbS14ODYvbWNlLmgJVHVl
IFNlcCAxOCAyMzo0NjozOSAyMDEyICswODAwCisrKyBiL3hlbi9pbmNsdWRlL2FzbS14ODYvbWNl
LmgJV2VkIFNlcCAxOSAwMToyMToxOCAyMDEyICswODAwCkBAIC00OCw3ICs0OCw3IEBACiAKIC8q
IEd1ZXN0IHZNQ0UgTVNScyB2aXJ0dWFsaXphdGlvbiAqLwogZXh0ZXJuIHZvaWQgdm1jZV9pbml0
X3ZjcHUoc3RydWN0IHZjcHUgKik7Ci1leHRlcm4gaW50IHZtY2VfcmVzdG9yZV92Y3B1KHN0cnVj
dCB2Y3B1ICosIHVpbnQ2NF90IGNhcHMpOworZXh0ZXJuIGludCB2bWNlX3Jlc3RvcmVfdmNwdShz
dHJ1Y3QgdmNwdSAqLCBzdHJ1Y3QgaHZtX3ZtY2VfdmNwdSAqY3R4dCk7CiBleHRlcm4gaW50IHZt
Y2Vfd3Jtc3IodWludDMyX3QgbXNyLCB1aW50NjRfdCB2YWwpOwogZXh0ZXJuIGludCB2bWNlX3Jk
bXNyKHVpbnQzMl90IG1zciwgdWludDY0X3QgKnZhbCk7CiAKZGlmZiAtciAxYzdlYWUxZTdkNjcg
eGVuL2luY2x1ZGUvcHVibGljL2FyY2gteDg2L2h2bS9zYXZlLmgKLS0tIGEveGVuL2luY2x1ZGUv
cHVibGljL2FyY2gteDg2L2h2bS9zYXZlLmgJVHVlIFNlcCAxOCAyMzo0NjozOSAyMDEyICswODAw
CisrKyBiL3hlbi9pbmNsdWRlL3B1YmxpYy9hcmNoLXg4Ni9odm0vc2F2ZS5oCVdlZCBTZXAgMTkg
MDE6MjE6MTggMjAxMiArMDgwMApAQCAtNTc3LDYgKzU3Nyw4IEBACiAKIHN0cnVjdCBodm1fdm1j
ZV92Y3B1IHsKICAgICB1aW50NjRfdCBjYXBzOworICAgIHVpbnQ2NF90IG1jaV9jdGwyX2Jhbmsw
OworICAgIHVpbnQ2NF90IG1jaV9jdGwyX2JhbmsxOwogfTsKIAogREVDTEFSRV9IVk1fU0FWRV9U
WVBFKFZNQ0VfVkNQVSwgMTgsIHN0cnVjdCBodm1fdm1jZV92Y3B1KTsKZGlmZiAtciAxYzdlYWUx
ZTdkNjcgeGVuL2luY2x1ZGUvcHVibGljL2RvbWN0bC5oCi0tLSBhL3hlbi9pbmNsdWRlL3B1Ymxp
Yy9kb21jdGwuaAlUdWUgU2VwIDE4IDIzOjQ2OjM5IDIwMTIgKzA4MDAKKysrIGIveGVuL2luY2x1
ZGUvcHVibGljL2RvbWN0bC5oCVdlZCBTZXAgMTkgMDE6MjE6MTggMjAxMiArMDgwMApAQCAtMzIs
NiArMzIsNyBAQAogI2Vycm9yICJkb21jdGwgb3BlcmF0aW9ucyBhcmUgaW50ZW5kZWQgZm9yIHVz
ZSBieSBub2RlIGNvbnRyb2wgdG9vbHMgb25seSIKICNlbmRpZgogCisjaW5jbHVkZSA8eGVuL2h2
bS9zYXZlLmg+CiAjaW5jbHVkZSAieGVuLmgiCiAjaW5jbHVkZSAiZ3JhbnRfdGFibGUuaCIKIApA
QCAtNTY0LDcgKzU2NSw3IEBACiAgICAgdWludDE2X3QgICAgICAgICBzeXNlbnRlcl9jYWxsYmFj
a19jczsKICAgICB1aW50OF90ICAgICAgICAgIHN5c2NhbGwzMl9kaXNhYmxlc19ldmVudHM7CiAg
ICAgdWludDhfdCAgICAgICAgICBzeXNlbnRlcl9kaXNhYmxlc19ldmVudHM7Ci0gICAgdWludDY0
X2FsaWduZWRfdCBtY2dfY2FwOworICAgIHN0cnVjdCBodm1fdm1jZV92Y3B1IHZtY2U7CiAjZW5k
aWYKIH07CiB0eXBlZGVmIHN0cnVjdCB4ZW5fZG9tY3RsX2V4dF92Y3B1Y29udGV4dCB4ZW5fZG9t
Y3RsX2V4dF92Y3B1Y29udGV4dF90Owo=

--_002_DE8DF0795D48FD4CA783C40EC82923353305C2SHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 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_DE8DF0795D48FD4CA783C40EC82923353305C2SHSMSX101ccrcorpi_--


From xen-devel-bounces@lists.xen.org Wed Sep 19 08:15:09 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Sep 2012 08:15: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 1TEFQv-0004wY-CE; Wed, 19 Sep 2012 08:14:57 +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 1TEFQt-0004wS-AZ
	for xen-devel@lists.xensource.com; Wed, 19 Sep 2012 08:14:55 +0000
Received: from [85.158.139.211:20503] by server-12.bemta-5.messagelabs.com id
	E1/DC-22167-EFE79505; Wed, 19 Sep 2012 08:14:54 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-3.tower-206.messagelabs.com!1348042492!19118042!1
X-Originating-IP: [192.55.52.88]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjg4ID0+IDMyMTU3Nw==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13817 invoked from network); 19 Sep 2012 08:14:52 -0000
Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88)
	by server-3.tower-206.messagelabs.com with SMTP;
	19 Sep 2012 08:14:52 -0000
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
	by fmsmga101.fm.intel.com with ESMTP; 19 Sep 2012 01:14:51 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.80,447,1344236400"; d="scan'208";a="223859891"
Received: from fmsmsx104.amr.corp.intel.com ([10.19.9.35])
	by fmsmga001.fm.intel.com with ESMTP; 19 Sep 2012 01:14:51 -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; Wed, 19 Sep 2012 01:14:50 -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, 19 Sep 2012 01:14:50 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.239]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.175]) with mapi id
	14.01.0355.002; Wed, 19 Sep 2012 16:14:49 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: Jan Beulich <JBeulich@suse.com>, "xen-devel@lists.xensource.com"
	<xen-devel@lists.xensource.com>
Thread-Topic: [PATCH 4/5] Xen/MCE: Abort live migration when vMCE occur
Thread-Index: Ac2WPtWdLJjFmp0JQpagLbNDjh5/PQ==
Date: Wed, 19 Sep 2012 08:14:48 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC82923353305E0@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_DE8DF0795D48FD4CA783C40EC82923353305E0SHSMSX101ccrcorpi_"
MIME-Version: 1.0
Cc: Christoph Egger <Christoph.Egger@amd.com>, "keir@xen.org" <keir@xen.org>,
	"Ian.Campbell@citrix.com" <Ian.Campbell@citrix.com>
Subject: [Xen-devel] [PATCH 4/5] Xen/MCE: Abort live migration when vMCE
	occur
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--_002_DE8DF0795D48FD4CA783C40EC82923353305E0SHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Xen/MCE: Abort live migration when vMCE occur

This patch monitor the critical area of live migration (from vMCE point of =
view,
the copypages stage of migration is the critical area while other areas are=
 not).

If a vMCE occur at the critical area of live migration, abort and try migra=
tion later.

Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>

diff -r e71c4bdcc05a tools/libxc/xc_domain.c
--- a/tools/libxc/xc_domain.c	Wed Sep 19 23:27:40 2012 +0800
+++ b/tools/libxc/xc_domain.c	Thu Sep 20 00:00:17 2012 +0800
@@ -283,6 +283,37 @@
     return ret;
 }
=20
+/* Start vmce monitor */
+int xc_domain_vmce_monitor_start(xc_interface *xch,
+                                 uint32_t domid)
+{
+    int ret;
+    DECLARE_DOMCTL;
+
+    domctl.cmd =3D XEN_DOMCTL_vmce_monitor_start;
+    domctl.domain =3D (domid_t)domid;
+    ret =3D do_domctl(xch, &domctl);
+
+    return ret ? -1 : 0;
+}
+
+/* End vmce monitor */
+int xc_domain_vmce_monitor_end(xc_interface *xch,
+                               uint32_t domid,
+                               signed char *vmce_while_monitor)
+{
+    int ret;
+    DECLARE_DOMCTL;
+
+    domctl.cmd =3D XEN_DOMCTL_vmce_monitor_end;
+    domctl.domain =3D (domid_t)domid;
+    ret =3D do_domctl(xch, &domctl);
+    if ( !ret )
+        *vmce_while_monitor =3D domctl.u.vmce_monitor.vmce_while_monitor;
+
+    return ret ? -1 : 0;
+}
+
 /* get info from hvm guest for save */
 int xc_domain_hvm_getcontext(xc_interface *xch,
                              uint32_t domid,
diff -r e71c4bdcc05a tools/libxc/xc_domain_save.c
--- a/tools/libxc/xc_domain_save.c	Wed Sep 19 23:27:40 2012 +0800
+++ b/tools/libxc/xc_domain_save.c	Thu Sep 20 00:00:17 2012 +0800
@@ -895,6 +895,8 @@
      */
     int compressing =3D 0;
=20
+    signed char vmce_while_monitor =3D 0;
+
     int completed =3D 0;
=20
     if ( hvm && !callbacks->switch_qemu_logdirty )
@@ -1109,6 +1111,12 @@
         goto out;
     }
=20
+    if ( xc_domain_vmce_monitor_start(xch, dom) )
+    {
+        PERROR("Error when start vmce monitor\n");
+        goto out;
+    }
+
   copypages:
 #define wrexact(fd, buf, len) write_buffer(xch, last_iter, ob, (fd), (buf)=
, (len))
 #define wruncached(fd, live, buf, len) write_uncached(xch, last_iter, ob, =
(fd), (buf), (len))
@@ -1571,6 +1579,17 @@
=20
     DPRINTF("All memory is saved\n");
=20
+    if ( xc_domain_vmce_monitor_end(xch, dom, &vmce_while_monitor) )
+    {
+        PERROR("Error when end vmce monitor\n");
+        goto out;
+    }
+    else if ( vmce_while_monitor =3D=3D -1 )
+    {
+        fprintf(stderr, "vMCE occurred, abort this time and try later.\n")=
;
+        goto out;
+    }
+
     /* After last_iter, buffer the rest of pagebuf & tailbuf data into a
      * separate output buffer and flush it after the compressed page chunk=
s.
      */
diff -r e71c4bdcc05a tools/libxc/xenctrl.h
--- a/tools/libxc/xenctrl.h	Wed Sep 19 23:27:40 2012 +0800
+++ b/tools/libxc/xenctrl.h	Thu Sep 20 00:00:17 2012 +0800
@@ -575,6 +575,26 @@
                           xc_domaininfo_t *info);
=20
 /**
+ * This function start monitor vmce event.
+ * @parm xch a handle to an open hypervisor interface
+ * @parm domid the domain id monitored
+ * @return 0 on success, -1 on failure
+ */
+int xc_domain_vmce_monitor_start(xc_interface *xch,
+                                 uint32_t domid);
+
+/**
+ * This function end monitor vmce event
+ * @parm xch a handle to an open hypervisor interface
+ * @parm domid the domain id monitored
+ * @parm vmce_while_migrate a pointer return whether vMCE occur when migra=
te=20
+ * @return 0 on success, -1 on failure
+ */
+int xc_domain_vmce_monitor_end(xc_interface *xch,
+                               uint32_t domid,
+                               signed char *vmce_while_monitor);
+
+/**
  * This function returns information about the context of a hvm domain
  * @parm xch a handle to an open hypervisor interface
  * @parm domid the domain to get information from
diff -r e71c4bdcc05a xen/arch/x86/cpu/mcheck/mce_intel.c
--- a/xen/arch/x86/cpu/mcheck/mce_intel.c	Wed Sep 19 23:27:40 2012 +0800
+++ b/xen/arch/x86/cpu/mcheck/mce_intel.c	Thu Sep 20 00:00:17 2012 +0800
@@ -358,6 +358,12 @@
                     goto vmce_failed;
                 }
=20
+                if ( unlikely(d->arch.vmce_monitor) )
+                {
+                    /* vMCE occur when guest migration */
+                    d->arch.vmce_monitor =3D -1;
+                }
+
                 /* We will inject vMCE to DOMU*/
                 if ( inject_vmce(d) < 0 )
                 {
diff -r e71c4bdcc05a xen/arch/x86/domctl.c
--- a/xen/arch/x86/domctl.c	Wed Sep 19 23:27:40 2012 +0800
+++ b/xen/arch/x86/domctl.c	Thu Sep 20 00:00:17 2012 +0800
@@ -1514,6 +1514,40 @@
     }
     break;
=20
+    case XEN_DOMCTL_vmce_monitor_start:
+    {
+        struct domain *d;
+
+        d =3D rcu_lock_domain_by_id(domctl->domain);
+        if ( d !=3D NULL )
+        {
+            d->arch.vmce_monitor =3D 1;
+            rcu_unlock_domain(d);
+        }
+        else
+            ret =3D -ESRCH;
+    }
+    break;
+
+    case XEN_DOMCTL_vmce_monitor_end:
+    {
+        struct domain *d;
+
+        d =3D rcu_lock_domain_by_id(domctl->domain);
+        if ( d !=3D NULL)
+        {
+            domctl->u.vmce_monitor.vmce_while_monitor =3D
+                                      d->arch.vmce_monitor;
+            d->arch.vmce_monitor =3D 0;
+            rcu_unlock_domain(d);
+            if ( copy_to_guest(u_domctl, domctl, 1) )
+                ret =3D -EFAULT;
+        }
+        else
+            ret =3D -ESRCH;
+    }
+    break;
+
     default:
         ret =3D iommu_do_domctl(domctl, u_domctl);
         break;
diff -r e71c4bdcc05a xen/include/asm-x86/domain.h
--- a/xen/include/asm-x86/domain.h	Wed Sep 19 23:27:40 2012 +0800
+++ b/xen/include/asm-x86/domain.h	Thu Sep 20 00:00:17 2012 +0800
@@ -279,6 +279,11 @@
     bool_t has_32bit_shinfo;
     /* Domain cannot handle spurious page faults? */
     bool_t suppress_spurious_page_faults;
+    /* Monitoring guest memory copy of migration
+     * =3D 0 - not monitoring
+     * > 0 - monitoring
+     * < 0 - vMCE occurred while monitoring */
+    s8 vmce_monitor;
=20
     /* Continuable domain_relinquish_resources(). */
     enum {
diff -r e71c4bdcc05a xen/include/public/domctl.h
--- a/xen/include/public/domctl.h	Wed Sep 19 23:27:40 2012 +0800
+++ b/xen/include/public/domctl.h	Thu Sep 20 00:00:17 2012 +0800
@@ -828,6 +828,12 @@
 typedef struct xen_domctl_set_access_required xen_domctl_set_access_requir=
ed_t;
 DEFINE_XEN_GUEST_HANDLE(xen_domctl_set_access_required_t);
=20
+struct xen_domctl_vmce_monitor {
+    signed char vmce_while_monitor;
+};
+typedef struct xen_domctl_vmce_monitor xen_domctl_vmce_monitor_t;
+DEFINE_XEN_GUEST_HANDLE(xen_domctl_vmce_monitor_t);
+
 struct xen_domctl {
     uint32_t cmd;
 #define XEN_DOMCTL_createdomain                   1
@@ -893,6 +899,8 @@
 #define XEN_DOMCTL_set_access_required           64
 #define XEN_DOMCTL_audit_p2m                     65
 #define XEN_DOMCTL_set_virq_handler              66
+#define XEN_DOMCTL_vmce_monitor_start            67
+#define XEN_DOMCTL_vmce_monitor_end              68
 #define XEN_DOMCTL_gdbsx_guestmemio            1000
 #define XEN_DOMCTL_gdbsx_pausevcpu             1001
 #define XEN_DOMCTL_gdbsx_unpausevcpu           1002
@@ -947,6 +955,7 @@
         struct xen_domctl_set_access_required access_required;
         struct xen_domctl_audit_p2m         audit_p2m;
         struct xen_domctl_set_virq_handler  set_virq_handler;
+        struct xen_domctl_vmce_monitor      vmce_monitor;
         struct xen_domctl_gdbsx_memio       gdbsx_guest_memio;
         struct xen_domctl_gdbsx_pauseunp_vcpu gdbsx_pauseunp_vcpu;
         struct xen_domctl_gdbsx_domstatus   gdbsx_domstatus;=

--_002_DE8DF0795D48FD4CA783C40EC82923353305E0SHSMSX101ccrcorpi_
Content-Type: application/octet-stream; name="4_vmce_when_migrate.patch"
Content-Description: 4_vmce_when_migrate.patch
Content-Disposition: attachment; filename="4_vmce_when_migrate.patch";
	size=7729; creation-date="Wed, 19 Sep 2012 07:39:51 GMT";
	modification-date="Wed, 19 Sep 2012 16:00:18 GMT"
Content-Transfer-Encoding: base64

WGVuL01DRTogQWJvcnQgbGl2ZSBtaWdyYXRpb24gd2hlbiB2TUNFIG9jY3VyCgpUaGlzIHBhdGNo
IG1vbml0b3IgdGhlIGNyaXRpY2FsIGFyZWEgb2YgbGl2ZSBtaWdyYXRpb24gKGZyb20gdk1DRSBw
b2ludCBvZiB2aWV3LAp0aGUgY29weXBhZ2VzIHN0YWdlIG9mIG1pZ3JhdGlvbiBpcyB0aGUgY3Jp
dGljYWwgYXJlYSB3aGlsZSBvdGhlciBhcmVhcyBhcmUgbm90KS4KCklmIGEgdk1DRSBvY2N1ciBh
dCB0aGUgY3JpdGljYWwgYXJlYSBvZiBsaXZlIG1pZ3JhdGlvbiwgYWJvcnQgYW5kIHRyeSBtaWdy
YXRpb24gbGF0ZXIuCgpTaWduZWQtb2ZmLWJ5OiBMaXUsIEppbnNvbmcgPGppbnNvbmcubGl1QGlu
dGVsLmNvbT4KCmRpZmYgLXIgZTcxYzRiZGNjMDVhIHRvb2xzL2xpYnhjL3hjX2RvbWFpbi5jCi0t
LSBhL3Rvb2xzL2xpYnhjL3hjX2RvbWFpbi5jCVdlZCBTZXAgMTkgMjM6Mjc6NDAgMjAxMiArMDgw
MAorKysgYi90b29scy9saWJ4Yy94Y19kb21haW4uYwlUaHUgU2VwIDIwIDAwOjAwOjE3IDIwMTIg
KzA4MDAKQEAgLTI4Myw2ICsyODMsMzcgQEAKICAgICByZXR1cm4gcmV0OwogfQogCisvKiBTdGFy
dCB2bWNlIG1vbml0b3IgKi8KK2ludCB4Y19kb21haW5fdm1jZV9tb25pdG9yX3N0YXJ0KHhjX2lu
dGVyZmFjZSAqeGNoLAorICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgdWludDMyX3Qg
ZG9taWQpCit7CisgICAgaW50IHJldDsKKyAgICBERUNMQVJFX0RPTUNUTDsKKworICAgIGRvbWN0
bC5jbWQgPSBYRU5fRE9NQ1RMX3ZtY2VfbW9uaXRvcl9zdGFydDsKKyAgICBkb21jdGwuZG9tYWlu
ID0gKGRvbWlkX3QpZG9taWQ7CisgICAgcmV0ID0gZG9fZG9tY3RsKHhjaCwgJmRvbWN0bCk7CisK
KyAgICByZXR1cm4gcmV0ID8gLTEgOiAwOworfQorCisvKiBFbmQgdm1jZSBtb25pdG9yICovCitp
bnQgeGNfZG9tYWluX3ZtY2VfbW9uaXRvcl9lbmQoeGNfaW50ZXJmYWNlICp4Y2gsCisgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgdWludDMyX3QgZG9taWQsCisgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgc2lnbmVkIGNoYXIgKnZtY2Vfd2hpbGVfbW9uaXRvcikKK3sKKyAgICBp
bnQgcmV0OworICAgIERFQ0xBUkVfRE9NQ1RMOworCisgICAgZG9tY3RsLmNtZCA9IFhFTl9ET01D
VExfdm1jZV9tb25pdG9yX2VuZDsKKyAgICBkb21jdGwuZG9tYWluID0gKGRvbWlkX3QpZG9taWQ7
CisgICAgcmV0ID0gZG9fZG9tY3RsKHhjaCwgJmRvbWN0bCk7CisgICAgaWYgKCAhcmV0ICkKKyAg
ICAgICAgKnZtY2Vfd2hpbGVfbW9uaXRvciA9IGRvbWN0bC51LnZtY2VfbW9uaXRvci52bWNlX3do
aWxlX21vbml0b3I7CisKKyAgICByZXR1cm4gcmV0ID8gLTEgOiAwOworfQorCiAvKiBnZXQgaW5m
byBmcm9tIGh2bSBndWVzdCBmb3Igc2F2ZSAqLwogaW50IHhjX2RvbWFpbl9odm1fZ2V0Y29udGV4
dCh4Y19pbnRlcmZhY2UgKnhjaCwKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgdWludDMy
X3QgZG9taWQsCmRpZmYgLXIgZTcxYzRiZGNjMDVhIHRvb2xzL2xpYnhjL3hjX2RvbWFpbl9zYXZl
LmMKLS0tIGEvdG9vbHMvbGlieGMveGNfZG9tYWluX3NhdmUuYwlXZWQgU2VwIDE5IDIzOjI3OjQw
IDIwMTIgKzA4MDAKKysrIGIvdG9vbHMvbGlieGMveGNfZG9tYWluX3NhdmUuYwlUaHUgU2VwIDIw
IDAwOjAwOjE3IDIwMTIgKzA4MDAKQEAgLTg5NSw2ICs4OTUsOCBAQAogICAgICAqLwogICAgIGlu
dCBjb21wcmVzc2luZyA9IDA7CiAKKyAgICBzaWduZWQgY2hhciB2bWNlX3doaWxlX21vbml0b3Ig
PSAwOworCiAgICAgaW50IGNvbXBsZXRlZCA9IDA7CiAKICAgICBpZiAoIGh2bSAmJiAhY2FsbGJh
Y2tzLT5zd2l0Y2hfcWVtdV9sb2dkaXJ0eSApCkBAIC0xMTA5LDYgKzExMTEsMTIgQEAKICAgICAg
ICAgZ290byBvdXQ7CiAgICAgfQogCisgICAgaWYgKCB4Y19kb21haW5fdm1jZV9tb25pdG9yX3N0
YXJ0KHhjaCwgZG9tKSApCisgICAgeworICAgICAgICBQRVJST1IoIkVycm9yIHdoZW4gc3RhcnQg
dm1jZSBtb25pdG9yXG4iKTsKKyAgICAgICAgZ290byBvdXQ7CisgICAgfQorCiAgIGNvcHlwYWdl
czoKICNkZWZpbmUgd3JleGFjdChmZCwgYnVmLCBsZW4pIHdyaXRlX2J1ZmZlcih4Y2gsIGxhc3Rf
aXRlciwgb2IsIChmZCksIChidWYpLCAobGVuKSkKICNkZWZpbmUgd3J1bmNhY2hlZChmZCwgbGl2
ZSwgYnVmLCBsZW4pIHdyaXRlX3VuY2FjaGVkKHhjaCwgbGFzdF9pdGVyLCBvYiwgKGZkKSwgKGJ1
ZiksIChsZW4pKQpAQCAtMTU3MSw2ICsxNTc5LDE3IEBACiAKICAgICBEUFJJTlRGKCJBbGwgbWVt
b3J5IGlzIHNhdmVkXG4iKTsKIAorICAgIGlmICggeGNfZG9tYWluX3ZtY2VfbW9uaXRvcl9lbmQo
eGNoLCBkb20sICZ2bWNlX3doaWxlX21vbml0b3IpICkKKyAgICB7CisgICAgICAgIFBFUlJPUigi
RXJyb3Igd2hlbiBlbmQgdm1jZSBtb25pdG9yXG4iKTsKKyAgICAgICAgZ290byBvdXQ7CisgICAg
fQorICAgIGVsc2UgaWYgKCB2bWNlX3doaWxlX21vbml0b3IgPT0gLTEgKQorICAgIHsKKyAgICAg
ICAgZnByaW50ZihzdGRlcnIsICJ2TUNFIG9jY3VycmVkLCBhYm9ydCB0aGlzIHRpbWUgYW5kIHRy
eSBsYXRlci5cbiIpOworICAgICAgICBnb3RvIG91dDsKKyAgICB9CisKICAgICAvKiBBZnRlciBs
YXN0X2l0ZXIsIGJ1ZmZlciB0aGUgcmVzdCBvZiBwYWdlYnVmICYgdGFpbGJ1ZiBkYXRhIGludG8g
YQogICAgICAqIHNlcGFyYXRlIG91dHB1dCBidWZmZXIgYW5kIGZsdXNoIGl0IGFmdGVyIHRoZSBj
b21wcmVzc2VkIHBhZ2UgY2h1bmtzLgogICAgICAqLwpkaWZmIC1yIGU3MWM0YmRjYzA1YSB0b29s
cy9saWJ4Yy94ZW5jdHJsLmgKLS0tIGEvdG9vbHMvbGlieGMveGVuY3RybC5oCVdlZCBTZXAgMTkg
MjM6Mjc6NDAgMjAxMiArMDgwMAorKysgYi90b29scy9saWJ4Yy94ZW5jdHJsLmgJVGh1IFNlcCAy
MCAwMDowMDoxNyAyMDEyICswODAwCkBAIC01NzUsNiArNTc1LDI2IEBACiAgICAgICAgICAgICAg
ICAgICAgICAgICAgIHhjX2RvbWFpbmluZm9fdCAqaW5mbyk7CiAKIC8qKgorICogVGhpcyBmdW5j
dGlvbiBzdGFydCBtb25pdG9yIHZtY2UgZXZlbnQuCisgKiBAcGFybSB4Y2ggYSBoYW5kbGUgdG8g
YW4gb3BlbiBoeXBlcnZpc29yIGludGVyZmFjZQorICogQHBhcm0gZG9taWQgdGhlIGRvbWFpbiBp
ZCBtb25pdG9yZWQKKyAqIEByZXR1cm4gMCBvbiBzdWNjZXNzLCAtMSBvbiBmYWlsdXJlCisgKi8K
K2ludCB4Y19kb21haW5fdm1jZV9tb25pdG9yX3N0YXJ0KHhjX2ludGVyZmFjZSAqeGNoLAorICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgdWludDMyX3QgZG9taWQpOworCisvKioKKyAq
IFRoaXMgZnVuY3Rpb24gZW5kIG1vbml0b3Igdm1jZSBldmVudAorICogQHBhcm0geGNoIGEgaGFu
ZGxlIHRvIGFuIG9wZW4gaHlwZXJ2aXNvciBpbnRlcmZhY2UKKyAqIEBwYXJtIGRvbWlkIHRoZSBk
b21haW4gaWQgbW9uaXRvcmVkCisgKiBAcGFybSB2bWNlX3doaWxlX21pZ3JhdGUgYSBwb2ludGVy
IHJldHVybiB3aGV0aGVyIHZNQ0Ugb2NjdXIgd2hlbiBtaWdyYXRlIAorICogQHJldHVybiAwIG9u
IHN1Y2Nlc3MsIC0xIG9uIGZhaWx1cmUKKyAqLworaW50IHhjX2RvbWFpbl92bWNlX21vbml0b3Jf
ZW5kKHhjX2ludGVyZmFjZSAqeGNoLAorICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHVp
bnQzMl90IGRvbWlkLAorICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHNpZ25lZCBjaGFy
ICp2bWNlX3doaWxlX21vbml0b3IpOworCisvKioKICAqIFRoaXMgZnVuY3Rpb24gcmV0dXJucyBp
bmZvcm1hdGlvbiBhYm91dCB0aGUgY29udGV4dCBvZiBhIGh2bSBkb21haW4KICAqIEBwYXJtIHhj
aCBhIGhhbmRsZSB0byBhbiBvcGVuIGh5cGVydmlzb3IgaW50ZXJmYWNlCiAgKiBAcGFybSBkb21p
ZCB0aGUgZG9tYWluIHRvIGdldCBpbmZvcm1hdGlvbiBmcm9tCmRpZmYgLXIgZTcxYzRiZGNjMDVh
IHhlbi9hcmNoL3g4Ni9jcHUvbWNoZWNrL21jZV9pbnRlbC5jCi0tLSBhL3hlbi9hcmNoL3g4Ni9j
cHUvbWNoZWNrL21jZV9pbnRlbC5jCVdlZCBTZXAgMTkgMjM6Mjc6NDAgMjAxMiArMDgwMAorKysg
Yi94ZW4vYXJjaC94ODYvY3B1L21jaGVjay9tY2VfaW50ZWwuYwlUaHUgU2VwIDIwIDAwOjAwOjE3
IDIwMTIgKzA4MDAKQEAgLTM1OCw2ICszNTgsMTIgQEAKICAgICAgICAgICAgICAgICAgICAgZ290
byB2bWNlX2ZhaWxlZDsKICAgICAgICAgICAgICAgICB9CiAKKyAgICAgICAgICAgICAgICBpZiAo
IHVubGlrZWx5KGQtPmFyY2gudm1jZV9tb25pdG9yKSApCisgICAgICAgICAgICAgICAgeworICAg
ICAgICAgICAgICAgICAgICAvKiB2TUNFIG9jY3VyIHdoZW4gZ3Vlc3QgbWlncmF0aW9uICovCisg
ICAgICAgICAgICAgICAgICAgIGQtPmFyY2gudm1jZV9tb25pdG9yID0gLTE7CisgICAgICAgICAg
ICAgICAgfQorCiAgICAgICAgICAgICAgICAgLyogV2Ugd2lsbCBpbmplY3Qgdk1DRSB0byBET01V
Ki8KICAgICAgICAgICAgICAgICBpZiAoIGluamVjdF92bWNlKGQpIDwgMCApCiAgICAgICAgICAg
ICAgICAgewpkaWZmIC1yIGU3MWM0YmRjYzA1YSB4ZW4vYXJjaC94ODYvZG9tY3RsLmMKLS0tIGEv
eGVuL2FyY2gveDg2L2RvbWN0bC5jCVdlZCBTZXAgMTkgMjM6Mjc6NDAgMjAxMiArMDgwMAorKysg
Yi94ZW4vYXJjaC94ODYvZG9tY3RsLmMJVGh1IFNlcCAyMCAwMDowMDoxNyAyMDEyICswODAwCkBA
IC0xNTE0LDYgKzE1MTQsNDAgQEAKICAgICB9CiAgICAgYnJlYWs7CiAKKyAgICBjYXNlIFhFTl9E
T01DVExfdm1jZV9tb25pdG9yX3N0YXJ0OgorICAgIHsKKyAgICAgICAgc3RydWN0IGRvbWFpbiAq
ZDsKKworICAgICAgICBkID0gcmN1X2xvY2tfZG9tYWluX2J5X2lkKGRvbWN0bC0+ZG9tYWluKTsK
KyAgICAgICAgaWYgKCBkICE9IE5VTEwgKQorICAgICAgICB7CisgICAgICAgICAgICBkLT5hcmNo
LnZtY2VfbW9uaXRvciA9IDE7CisgICAgICAgICAgICByY3VfdW5sb2NrX2RvbWFpbihkKTsKKyAg
ICAgICAgfQorICAgICAgICBlbHNlCisgICAgICAgICAgICByZXQgPSAtRVNSQ0g7CisgICAgfQor
ICAgIGJyZWFrOworCisgICAgY2FzZSBYRU5fRE9NQ1RMX3ZtY2VfbW9uaXRvcl9lbmQ6CisgICAg
eworICAgICAgICBzdHJ1Y3QgZG9tYWluICpkOworCisgICAgICAgIGQgPSByY3VfbG9ja19kb21h
aW5fYnlfaWQoZG9tY3RsLT5kb21haW4pOworICAgICAgICBpZiAoIGQgIT0gTlVMTCkKKyAgICAg
ICAgeworICAgICAgICAgICAgZG9tY3RsLT51LnZtY2VfbW9uaXRvci52bWNlX3doaWxlX21vbml0
b3IgPQorICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBkLT5hcmNoLnZtY2Vf
bW9uaXRvcjsKKyAgICAgICAgICAgIGQtPmFyY2gudm1jZV9tb25pdG9yID0gMDsKKyAgICAgICAg
ICAgIHJjdV91bmxvY2tfZG9tYWluKGQpOworICAgICAgICAgICAgaWYgKCBjb3B5X3RvX2d1ZXN0
KHVfZG9tY3RsLCBkb21jdGwsIDEpICkKKyAgICAgICAgICAgICAgICByZXQgPSAtRUZBVUxUOwor
ICAgICAgICB9CisgICAgICAgIGVsc2UKKyAgICAgICAgICAgIHJldCA9IC1FU1JDSDsKKyAgICB9
CisgICAgYnJlYWs7CisKICAgICBkZWZhdWx0OgogICAgICAgICByZXQgPSBpb21tdV9kb19kb21j
dGwoZG9tY3RsLCB1X2RvbWN0bCk7CiAgICAgICAgIGJyZWFrOwpkaWZmIC1yIGU3MWM0YmRjYzA1
YSB4ZW4vaW5jbHVkZS9hc20teDg2L2RvbWFpbi5oCi0tLSBhL3hlbi9pbmNsdWRlL2FzbS14ODYv
ZG9tYWluLmgJV2VkIFNlcCAxOSAyMzoyNzo0MCAyMDEyICswODAwCisrKyBiL3hlbi9pbmNsdWRl
L2FzbS14ODYvZG9tYWluLmgJVGh1IFNlcCAyMCAwMDowMDoxNyAyMDEyICswODAwCkBAIC0yNzks
NiArMjc5LDExIEBACiAgICAgYm9vbF90IGhhc18zMmJpdF9zaGluZm87CiAgICAgLyogRG9tYWlu
IGNhbm5vdCBoYW5kbGUgc3B1cmlvdXMgcGFnZSBmYXVsdHM/ICovCiAgICAgYm9vbF90IHN1cHBy
ZXNzX3NwdXJpb3VzX3BhZ2VfZmF1bHRzOworICAgIC8qIE1vbml0b3JpbmcgZ3Vlc3QgbWVtb3J5
IGNvcHkgb2YgbWlncmF0aW9uCisgICAgICogPSAwIC0gbm90IG1vbml0b3JpbmcKKyAgICAgKiA+
IDAgLSBtb25pdG9yaW5nCisgICAgICogPCAwIC0gdk1DRSBvY2N1cnJlZCB3aGlsZSBtb25pdG9y
aW5nICovCisgICAgczggdm1jZV9tb25pdG9yOwogCiAgICAgLyogQ29udGludWFibGUgZG9tYWlu
X3JlbGlucXVpc2hfcmVzb3VyY2VzKCkuICovCiAgICAgZW51bSB7CmRpZmYgLXIgZTcxYzRiZGNj
MDVhIHhlbi9pbmNsdWRlL3B1YmxpYy9kb21jdGwuaAotLS0gYS94ZW4vaW5jbHVkZS9wdWJsaWMv
ZG9tY3RsLmgJV2VkIFNlcCAxOSAyMzoyNzo0MCAyMDEyICswODAwCisrKyBiL3hlbi9pbmNsdWRl
L3B1YmxpYy9kb21jdGwuaAlUaHUgU2VwIDIwIDAwOjAwOjE3IDIwMTIgKzA4MDAKQEAgLTgyOCw2
ICs4MjgsMTIgQEAKIHR5cGVkZWYgc3RydWN0IHhlbl9kb21jdGxfc2V0X2FjY2Vzc19yZXF1aXJl
ZCB4ZW5fZG9tY3RsX3NldF9hY2Nlc3NfcmVxdWlyZWRfdDsKIERFRklORV9YRU5fR1VFU1RfSEFO
RExFKHhlbl9kb21jdGxfc2V0X2FjY2Vzc19yZXF1aXJlZF90KTsKIAorc3RydWN0IHhlbl9kb21j
dGxfdm1jZV9tb25pdG9yIHsKKyAgICBzaWduZWQgY2hhciB2bWNlX3doaWxlX21vbml0b3I7Cit9
OwordHlwZWRlZiBzdHJ1Y3QgeGVuX2RvbWN0bF92bWNlX21vbml0b3IgeGVuX2RvbWN0bF92bWNl
X21vbml0b3JfdDsKK0RFRklORV9YRU5fR1VFU1RfSEFORExFKHhlbl9kb21jdGxfdm1jZV9tb25p
dG9yX3QpOworCiBzdHJ1Y3QgeGVuX2RvbWN0bCB7CiAgICAgdWludDMyX3QgY21kOwogI2RlZmlu
ZSBYRU5fRE9NQ1RMX2NyZWF0ZWRvbWFpbiAgICAgICAgICAgICAgICAgICAxCkBAIC04OTMsNiAr
ODk5LDggQEAKICNkZWZpbmUgWEVOX0RPTUNUTF9zZXRfYWNjZXNzX3JlcXVpcmVkICAgICAgICAg
ICA2NAogI2RlZmluZSBYRU5fRE9NQ1RMX2F1ZGl0X3AybSAgICAgICAgICAgICAgICAgICAgIDY1
CiAjZGVmaW5lIFhFTl9ET01DVExfc2V0X3ZpcnFfaGFuZGxlciAgICAgICAgICAgICAgNjYKKyNk
ZWZpbmUgWEVOX0RPTUNUTF92bWNlX21vbml0b3Jfc3RhcnQgICAgICAgICAgICA2NworI2RlZmlu
ZSBYRU5fRE9NQ1RMX3ZtY2VfbW9uaXRvcl9lbmQgICAgICAgICAgICAgIDY4CiAjZGVmaW5lIFhF
Tl9ET01DVExfZ2Ric3hfZ3Vlc3RtZW1pbyAgICAgICAgICAgIDEwMDAKICNkZWZpbmUgWEVOX0RP
TUNUTF9nZGJzeF9wYXVzZXZjcHUgICAgICAgICAgICAgMTAwMQogI2RlZmluZSBYRU5fRE9NQ1RM
X2dkYnN4X3VucGF1c2V2Y3B1ICAgICAgICAgICAxMDAyCkBAIC05NDcsNiArOTU1LDcgQEAKICAg
ICAgICAgc3RydWN0IHhlbl9kb21jdGxfc2V0X2FjY2Vzc19yZXF1aXJlZCBhY2Nlc3NfcmVxdWly
ZWQ7CiAgICAgICAgIHN0cnVjdCB4ZW5fZG9tY3RsX2F1ZGl0X3AybSAgICAgICAgIGF1ZGl0X3Ay
bTsKICAgICAgICAgc3RydWN0IHhlbl9kb21jdGxfc2V0X3ZpcnFfaGFuZGxlciAgc2V0X3ZpcnFf
aGFuZGxlcjsKKyAgICAgICAgc3RydWN0IHhlbl9kb21jdGxfdm1jZV9tb25pdG9yICAgICAgdm1j
ZV9tb25pdG9yOwogICAgICAgICBzdHJ1Y3QgeGVuX2RvbWN0bF9nZGJzeF9tZW1pbyAgICAgICBn
ZGJzeF9ndWVzdF9tZW1pbzsKICAgICAgICAgc3RydWN0IHhlbl9kb21jdGxfZ2Ric3hfcGF1c2V1
bnBfdmNwdSBnZGJzeF9wYXVzZXVucF92Y3B1OwogICAgICAgICBzdHJ1Y3QgeGVuX2RvbWN0bF9n
ZGJzeF9kb21zdGF0dXMgICBnZGJzeF9kb21zdGF0dXM7Cg==

--_002_DE8DF0795D48FD4CA783C40EC82923353305E0SHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 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_DE8DF0795D48FD4CA783C40EC82923353305E0SHSMSX101ccrcorpi_--


From xen-devel-bounces@lists.xen.org Wed Sep 19 08:15:09 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Sep 2012 08:15: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 1TEFQv-0004wY-CE; Wed, 19 Sep 2012 08:14:57 +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 1TEFQt-0004wS-AZ
	for xen-devel@lists.xensource.com; Wed, 19 Sep 2012 08:14:55 +0000
Received: from [85.158.139.211:20503] by server-12.bemta-5.messagelabs.com id
	E1/DC-22167-EFE79505; Wed, 19 Sep 2012 08:14:54 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-3.tower-206.messagelabs.com!1348042492!19118042!1
X-Originating-IP: [192.55.52.88]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjg4ID0+IDMyMTU3Nw==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13817 invoked from network); 19 Sep 2012 08:14:52 -0000
Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88)
	by server-3.tower-206.messagelabs.com with SMTP;
	19 Sep 2012 08:14:52 -0000
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
	by fmsmga101.fm.intel.com with ESMTP; 19 Sep 2012 01:14:51 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.80,447,1344236400"; d="scan'208";a="223859891"
Received: from fmsmsx104.amr.corp.intel.com ([10.19.9.35])
	by fmsmga001.fm.intel.com with ESMTP; 19 Sep 2012 01:14:51 -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; Wed, 19 Sep 2012 01:14:50 -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, 19 Sep 2012 01:14:50 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.239]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.175]) with mapi id
	14.01.0355.002; Wed, 19 Sep 2012 16:14:49 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: Jan Beulich <JBeulich@suse.com>, "xen-devel@lists.xensource.com"
	<xen-devel@lists.xensource.com>
Thread-Topic: [PATCH 4/5] Xen/MCE: Abort live migration when vMCE occur
Thread-Index: Ac2WPtWdLJjFmp0JQpagLbNDjh5/PQ==
Date: Wed, 19 Sep 2012 08:14:48 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC82923353305E0@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_DE8DF0795D48FD4CA783C40EC82923353305E0SHSMSX101ccrcorpi_"
MIME-Version: 1.0
Cc: Christoph Egger <Christoph.Egger@amd.com>, "keir@xen.org" <keir@xen.org>,
	"Ian.Campbell@citrix.com" <Ian.Campbell@citrix.com>
Subject: [Xen-devel] [PATCH 4/5] Xen/MCE: Abort live migration when vMCE
	occur
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--_002_DE8DF0795D48FD4CA783C40EC82923353305E0SHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Xen/MCE: Abort live migration when vMCE occur

This patch monitor the critical area of live migration (from vMCE point of =
view,
the copypages stage of migration is the critical area while other areas are=
 not).

If a vMCE occur at the critical area of live migration, abort and try migra=
tion later.

Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>

diff -r e71c4bdcc05a tools/libxc/xc_domain.c
--- a/tools/libxc/xc_domain.c	Wed Sep 19 23:27:40 2012 +0800
+++ b/tools/libxc/xc_domain.c	Thu Sep 20 00:00:17 2012 +0800
@@ -283,6 +283,37 @@
     return ret;
 }
=20
+/* Start vmce monitor */
+int xc_domain_vmce_monitor_start(xc_interface *xch,
+                                 uint32_t domid)
+{
+    int ret;
+    DECLARE_DOMCTL;
+
+    domctl.cmd =3D XEN_DOMCTL_vmce_monitor_start;
+    domctl.domain =3D (domid_t)domid;
+    ret =3D do_domctl(xch, &domctl);
+
+    return ret ? -1 : 0;
+}
+
+/* End vmce monitor */
+int xc_domain_vmce_monitor_end(xc_interface *xch,
+                               uint32_t domid,
+                               signed char *vmce_while_monitor)
+{
+    int ret;
+    DECLARE_DOMCTL;
+
+    domctl.cmd =3D XEN_DOMCTL_vmce_monitor_end;
+    domctl.domain =3D (domid_t)domid;
+    ret =3D do_domctl(xch, &domctl);
+    if ( !ret )
+        *vmce_while_monitor =3D domctl.u.vmce_monitor.vmce_while_monitor;
+
+    return ret ? -1 : 0;
+}
+
 /* get info from hvm guest for save */
 int xc_domain_hvm_getcontext(xc_interface *xch,
                              uint32_t domid,
diff -r e71c4bdcc05a tools/libxc/xc_domain_save.c
--- a/tools/libxc/xc_domain_save.c	Wed Sep 19 23:27:40 2012 +0800
+++ b/tools/libxc/xc_domain_save.c	Thu Sep 20 00:00:17 2012 +0800
@@ -895,6 +895,8 @@
      */
     int compressing =3D 0;
=20
+    signed char vmce_while_monitor =3D 0;
+
     int completed =3D 0;
=20
     if ( hvm && !callbacks->switch_qemu_logdirty )
@@ -1109,6 +1111,12 @@
         goto out;
     }
=20
+    if ( xc_domain_vmce_monitor_start(xch, dom) )
+    {
+        PERROR("Error when start vmce monitor\n");
+        goto out;
+    }
+
   copypages:
 #define wrexact(fd, buf, len) write_buffer(xch, last_iter, ob, (fd), (buf)=
, (len))
 #define wruncached(fd, live, buf, len) write_uncached(xch, last_iter, ob, =
(fd), (buf), (len))
@@ -1571,6 +1579,17 @@
=20
     DPRINTF("All memory is saved\n");
=20
+    if ( xc_domain_vmce_monitor_end(xch, dom, &vmce_while_monitor) )
+    {
+        PERROR("Error when end vmce monitor\n");
+        goto out;
+    }
+    else if ( vmce_while_monitor =3D=3D -1 )
+    {
+        fprintf(stderr, "vMCE occurred, abort this time and try later.\n")=
;
+        goto out;
+    }
+
     /* After last_iter, buffer the rest of pagebuf & tailbuf data into a
      * separate output buffer and flush it after the compressed page chunk=
s.
      */
diff -r e71c4bdcc05a tools/libxc/xenctrl.h
--- a/tools/libxc/xenctrl.h	Wed Sep 19 23:27:40 2012 +0800
+++ b/tools/libxc/xenctrl.h	Thu Sep 20 00:00:17 2012 +0800
@@ -575,6 +575,26 @@
                           xc_domaininfo_t *info);
=20
 /**
+ * This function start monitor vmce event.
+ * @parm xch a handle to an open hypervisor interface
+ * @parm domid the domain id monitored
+ * @return 0 on success, -1 on failure
+ */
+int xc_domain_vmce_monitor_start(xc_interface *xch,
+                                 uint32_t domid);
+
+/**
+ * This function end monitor vmce event
+ * @parm xch a handle to an open hypervisor interface
+ * @parm domid the domain id monitored
+ * @parm vmce_while_migrate a pointer return whether vMCE occur when migra=
te=20
+ * @return 0 on success, -1 on failure
+ */
+int xc_domain_vmce_monitor_end(xc_interface *xch,
+                               uint32_t domid,
+                               signed char *vmce_while_monitor);
+
+/**
  * This function returns information about the context of a hvm domain
  * @parm xch a handle to an open hypervisor interface
  * @parm domid the domain to get information from
diff -r e71c4bdcc05a xen/arch/x86/cpu/mcheck/mce_intel.c
--- a/xen/arch/x86/cpu/mcheck/mce_intel.c	Wed Sep 19 23:27:40 2012 +0800
+++ b/xen/arch/x86/cpu/mcheck/mce_intel.c	Thu Sep 20 00:00:17 2012 +0800
@@ -358,6 +358,12 @@
                     goto vmce_failed;
                 }
=20
+                if ( unlikely(d->arch.vmce_monitor) )
+                {
+                    /* vMCE occur when guest migration */
+                    d->arch.vmce_monitor =3D -1;
+                }
+
                 /* We will inject vMCE to DOMU*/
                 if ( inject_vmce(d) < 0 )
                 {
diff -r e71c4bdcc05a xen/arch/x86/domctl.c
--- a/xen/arch/x86/domctl.c	Wed Sep 19 23:27:40 2012 +0800
+++ b/xen/arch/x86/domctl.c	Thu Sep 20 00:00:17 2012 +0800
@@ -1514,6 +1514,40 @@
     }
     break;
=20
+    case XEN_DOMCTL_vmce_monitor_start:
+    {
+        struct domain *d;
+
+        d =3D rcu_lock_domain_by_id(domctl->domain);
+        if ( d !=3D NULL )
+        {
+            d->arch.vmce_monitor =3D 1;
+            rcu_unlock_domain(d);
+        }
+        else
+            ret =3D -ESRCH;
+    }
+    break;
+
+    case XEN_DOMCTL_vmce_monitor_end:
+    {
+        struct domain *d;
+
+        d =3D rcu_lock_domain_by_id(domctl->domain);
+        if ( d !=3D NULL)
+        {
+            domctl->u.vmce_monitor.vmce_while_monitor =3D
+                                      d->arch.vmce_monitor;
+            d->arch.vmce_monitor =3D 0;
+            rcu_unlock_domain(d);
+            if ( copy_to_guest(u_domctl, domctl, 1) )
+                ret =3D -EFAULT;
+        }
+        else
+            ret =3D -ESRCH;
+    }
+    break;
+
     default:
         ret =3D iommu_do_domctl(domctl, u_domctl);
         break;
diff -r e71c4bdcc05a xen/include/asm-x86/domain.h
--- a/xen/include/asm-x86/domain.h	Wed Sep 19 23:27:40 2012 +0800
+++ b/xen/include/asm-x86/domain.h	Thu Sep 20 00:00:17 2012 +0800
@@ -279,6 +279,11 @@
     bool_t has_32bit_shinfo;
     /* Domain cannot handle spurious page faults? */
     bool_t suppress_spurious_page_faults;
+    /* Monitoring guest memory copy of migration
+     * =3D 0 - not monitoring
+     * > 0 - monitoring
+     * < 0 - vMCE occurred while monitoring */
+    s8 vmce_monitor;
=20
     /* Continuable domain_relinquish_resources(). */
     enum {
diff -r e71c4bdcc05a xen/include/public/domctl.h
--- a/xen/include/public/domctl.h	Wed Sep 19 23:27:40 2012 +0800
+++ b/xen/include/public/domctl.h	Thu Sep 20 00:00:17 2012 +0800
@@ -828,6 +828,12 @@
 typedef struct xen_domctl_set_access_required xen_domctl_set_access_requir=
ed_t;
 DEFINE_XEN_GUEST_HANDLE(xen_domctl_set_access_required_t);
=20
+struct xen_domctl_vmce_monitor {
+    signed char vmce_while_monitor;
+};
+typedef struct xen_domctl_vmce_monitor xen_domctl_vmce_monitor_t;
+DEFINE_XEN_GUEST_HANDLE(xen_domctl_vmce_monitor_t);
+
 struct xen_domctl {
     uint32_t cmd;
 #define XEN_DOMCTL_createdomain                   1
@@ -893,6 +899,8 @@
 #define XEN_DOMCTL_set_access_required           64
 #define XEN_DOMCTL_audit_p2m                     65
 #define XEN_DOMCTL_set_virq_handler              66
+#define XEN_DOMCTL_vmce_monitor_start            67
+#define XEN_DOMCTL_vmce_monitor_end              68
 #define XEN_DOMCTL_gdbsx_guestmemio            1000
 #define XEN_DOMCTL_gdbsx_pausevcpu             1001
 #define XEN_DOMCTL_gdbsx_unpausevcpu           1002
@@ -947,6 +955,7 @@
         struct xen_domctl_set_access_required access_required;
         struct xen_domctl_audit_p2m         audit_p2m;
         struct xen_domctl_set_virq_handler  set_virq_handler;
+        struct xen_domctl_vmce_monitor      vmce_monitor;
         struct xen_domctl_gdbsx_memio       gdbsx_guest_memio;
         struct xen_domctl_gdbsx_pauseunp_vcpu gdbsx_pauseunp_vcpu;
         struct xen_domctl_gdbsx_domstatus   gdbsx_domstatus;=

--_002_DE8DF0795D48FD4CA783C40EC82923353305E0SHSMSX101ccrcorpi_
Content-Type: application/octet-stream; name="4_vmce_when_migrate.patch"
Content-Description: 4_vmce_when_migrate.patch
Content-Disposition: attachment; filename="4_vmce_when_migrate.patch";
	size=7729; creation-date="Wed, 19 Sep 2012 07:39:51 GMT";
	modification-date="Wed, 19 Sep 2012 16:00:18 GMT"
Content-Transfer-Encoding: base64

WGVuL01DRTogQWJvcnQgbGl2ZSBtaWdyYXRpb24gd2hlbiB2TUNFIG9jY3VyCgpUaGlzIHBhdGNo
IG1vbml0b3IgdGhlIGNyaXRpY2FsIGFyZWEgb2YgbGl2ZSBtaWdyYXRpb24gKGZyb20gdk1DRSBw
b2ludCBvZiB2aWV3LAp0aGUgY29weXBhZ2VzIHN0YWdlIG9mIG1pZ3JhdGlvbiBpcyB0aGUgY3Jp
dGljYWwgYXJlYSB3aGlsZSBvdGhlciBhcmVhcyBhcmUgbm90KS4KCklmIGEgdk1DRSBvY2N1ciBh
dCB0aGUgY3JpdGljYWwgYXJlYSBvZiBsaXZlIG1pZ3JhdGlvbiwgYWJvcnQgYW5kIHRyeSBtaWdy
YXRpb24gbGF0ZXIuCgpTaWduZWQtb2ZmLWJ5OiBMaXUsIEppbnNvbmcgPGppbnNvbmcubGl1QGlu
dGVsLmNvbT4KCmRpZmYgLXIgZTcxYzRiZGNjMDVhIHRvb2xzL2xpYnhjL3hjX2RvbWFpbi5jCi0t
LSBhL3Rvb2xzL2xpYnhjL3hjX2RvbWFpbi5jCVdlZCBTZXAgMTkgMjM6Mjc6NDAgMjAxMiArMDgw
MAorKysgYi90b29scy9saWJ4Yy94Y19kb21haW4uYwlUaHUgU2VwIDIwIDAwOjAwOjE3IDIwMTIg
KzA4MDAKQEAgLTI4Myw2ICsyODMsMzcgQEAKICAgICByZXR1cm4gcmV0OwogfQogCisvKiBTdGFy
dCB2bWNlIG1vbml0b3IgKi8KK2ludCB4Y19kb21haW5fdm1jZV9tb25pdG9yX3N0YXJ0KHhjX2lu
dGVyZmFjZSAqeGNoLAorICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgdWludDMyX3Qg
ZG9taWQpCit7CisgICAgaW50IHJldDsKKyAgICBERUNMQVJFX0RPTUNUTDsKKworICAgIGRvbWN0
bC5jbWQgPSBYRU5fRE9NQ1RMX3ZtY2VfbW9uaXRvcl9zdGFydDsKKyAgICBkb21jdGwuZG9tYWlu
ID0gKGRvbWlkX3QpZG9taWQ7CisgICAgcmV0ID0gZG9fZG9tY3RsKHhjaCwgJmRvbWN0bCk7CisK
KyAgICByZXR1cm4gcmV0ID8gLTEgOiAwOworfQorCisvKiBFbmQgdm1jZSBtb25pdG9yICovCitp
bnQgeGNfZG9tYWluX3ZtY2VfbW9uaXRvcl9lbmQoeGNfaW50ZXJmYWNlICp4Y2gsCisgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgdWludDMyX3QgZG9taWQsCisgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgc2lnbmVkIGNoYXIgKnZtY2Vfd2hpbGVfbW9uaXRvcikKK3sKKyAgICBp
bnQgcmV0OworICAgIERFQ0xBUkVfRE9NQ1RMOworCisgICAgZG9tY3RsLmNtZCA9IFhFTl9ET01D
VExfdm1jZV9tb25pdG9yX2VuZDsKKyAgICBkb21jdGwuZG9tYWluID0gKGRvbWlkX3QpZG9taWQ7
CisgICAgcmV0ID0gZG9fZG9tY3RsKHhjaCwgJmRvbWN0bCk7CisgICAgaWYgKCAhcmV0ICkKKyAg
ICAgICAgKnZtY2Vfd2hpbGVfbW9uaXRvciA9IGRvbWN0bC51LnZtY2VfbW9uaXRvci52bWNlX3do
aWxlX21vbml0b3I7CisKKyAgICByZXR1cm4gcmV0ID8gLTEgOiAwOworfQorCiAvKiBnZXQgaW5m
byBmcm9tIGh2bSBndWVzdCBmb3Igc2F2ZSAqLwogaW50IHhjX2RvbWFpbl9odm1fZ2V0Y29udGV4
dCh4Y19pbnRlcmZhY2UgKnhjaCwKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgdWludDMy
X3QgZG9taWQsCmRpZmYgLXIgZTcxYzRiZGNjMDVhIHRvb2xzL2xpYnhjL3hjX2RvbWFpbl9zYXZl
LmMKLS0tIGEvdG9vbHMvbGlieGMveGNfZG9tYWluX3NhdmUuYwlXZWQgU2VwIDE5IDIzOjI3OjQw
IDIwMTIgKzA4MDAKKysrIGIvdG9vbHMvbGlieGMveGNfZG9tYWluX3NhdmUuYwlUaHUgU2VwIDIw
IDAwOjAwOjE3IDIwMTIgKzA4MDAKQEAgLTg5NSw2ICs4OTUsOCBAQAogICAgICAqLwogICAgIGlu
dCBjb21wcmVzc2luZyA9IDA7CiAKKyAgICBzaWduZWQgY2hhciB2bWNlX3doaWxlX21vbml0b3Ig
PSAwOworCiAgICAgaW50IGNvbXBsZXRlZCA9IDA7CiAKICAgICBpZiAoIGh2bSAmJiAhY2FsbGJh
Y2tzLT5zd2l0Y2hfcWVtdV9sb2dkaXJ0eSApCkBAIC0xMTA5LDYgKzExMTEsMTIgQEAKICAgICAg
ICAgZ290byBvdXQ7CiAgICAgfQogCisgICAgaWYgKCB4Y19kb21haW5fdm1jZV9tb25pdG9yX3N0
YXJ0KHhjaCwgZG9tKSApCisgICAgeworICAgICAgICBQRVJST1IoIkVycm9yIHdoZW4gc3RhcnQg
dm1jZSBtb25pdG9yXG4iKTsKKyAgICAgICAgZ290byBvdXQ7CisgICAgfQorCiAgIGNvcHlwYWdl
czoKICNkZWZpbmUgd3JleGFjdChmZCwgYnVmLCBsZW4pIHdyaXRlX2J1ZmZlcih4Y2gsIGxhc3Rf
aXRlciwgb2IsIChmZCksIChidWYpLCAobGVuKSkKICNkZWZpbmUgd3J1bmNhY2hlZChmZCwgbGl2
ZSwgYnVmLCBsZW4pIHdyaXRlX3VuY2FjaGVkKHhjaCwgbGFzdF9pdGVyLCBvYiwgKGZkKSwgKGJ1
ZiksIChsZW4pKQpAQCAtMTU3MSw2ICsxNTc5LDE3IEBACiAKICAgICBEUFJJTlRGKCJBbGwgbWVt
b3J5IGlzIHNhdmVkXG4iKTsKIAorICAgIGlmICggeGNfZG9tYWluX3ZtY2VfbW9uaXRvcl9lbmQo
eGNoLCBkb20sICZ2bWNlX3doaWxlX21vbml0b3IpICkKKyAgICB7CisgICAgICAgIFBFUlJPUigi
RXJyb3Igd2hlbiBlbmQgdm1jZSBtb25pdG9yXG4iKTsKKyAgICAgICAgZ290byBvdXQ7CisgICAg
fQorICAgIGVsc2UgaWYgKCB2bWNlX3doaWxlX21vbml0b3IgPT0gLTEgKQorICAgIHsKKyAgICAg
ICAgZnByaW50ZihzdGRlcnIsICJ2TUNFIG9jY3VycmVkLCBhYm9ydCB0aGlzIHRpbWUgYW5kIHRy
eSBsYXRlci5cbiIpOworICAgICAgICBnb3RvIG91dDsKKyAgICB9CisKICAgICAvKiBBZnRlciBs
YXN0X2l0ZXIsIGJ1ZmZlciB0aGUgcmVzdCBvZiBwYWdlYnVmICYgdGFpbGJ1ZiBkYXRhIGludG8g
YQogICAgICAqIHNlcGFyYXRlIG91dHB1dCBidWZmZXIgYW5kIGZsdXNoIGl0IGFmdGVyIHRoZSBj
b21wcmVzc2VkIHBhZ2UgY2h1bmtzLgogICAgICAqLwpkaWZmIC1yIGU3MWM0YmRjYzA1YSB0b29s
cy9saWJ4Yy94ZW5jdHJsLmgKLS0tIGEvdG9vbHMvbGlieGMveGVuY3RybC5oCVdlZCBTZXAgMTkg
MjM6Mjc6NDAgMjAxMiArMDgwMAorKysgYi90b29scy9saWJ4Yy94ZW5jdHJsLmgJVGh1IFNlcCAy
MCAwMDowMDoxNyAyMDEyICswODAwCkBAIC01NzUsNiArNTc1LDI2IEBACiAgICAgICAgICAgICAg
ICAgICAgICAgICAgIHhjX2RvbWFpbmluZm9fdCAqaW5mbyk7CiAKIC8qKgorICogVGhpcyBmdW5j
dGlvbiBzdGFydCBtb25pdG9yIHZtY2UgZXZlbnQuCisgKiBAcGFybSB4Y2ggYSBoYW5kbGUgdG8g
YW4gb3BlbiBoeXBlcnZpc29yIGludGVyZmFjZQorICogQHBhcm0gZG9taWQgdGhlIGRvbWFpbiBp
ZCBtb25pdG9yZWQKKyAqIEByZXR1cm4gMCBvbiBzdWNjZXNzLCAtMSBvbiBmYWlsdXJlCisgKi8K
K2ludCB4Y19kb21haW5fdm1jZV9tb25pdG9yX3N0YXJ0KHhjX2ludGVyZmFjZSAqeGNoLAorICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgdWludDMyX3QgZG9taWQpOworCisvKioKKyAq
IFRoaXMgZnVuY3Rpb24gZW5kIG1vbml0b3Igdm1jZSBldmVudAorICogQHBhcm0geGNoIGEgaGFu
ZGxlIHRvIGFuIG9wZW4gaHlwZXJ2aXNvciBpbnRlcmZhY2UKKyAqIEBwYXJtIGRvbWlkIHRoZSBk
b21haW4gaWQgbW9uaXRvcmVkCisgKiBAcGFybSB2bWNlX3doaWxlX21pZ3JhdGUgYSBwb2ludGVy
IHJldHVybiB3aGV0aGVyIHZNQ0Ugb2NjdXIgd2hlbiBtaWdyYXRlIAorICogQHJldHVybiAwIG9u
IHN1Y2Nlc3MsIC0xIG9uIGZhaWx1cmUKKyAqLworaW50IHhjX2RvbWFpbl92bWNlX21vbml0b3Jf
ZW5kKHhjX2ludGVyZmFjZSAqeGNoLAorICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHVp
bnQzMl90IGRvbWlkLAorICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHNpZ25lZCBjaGFy
ICp2bWNlX3doaWxlX21vbml0b3IpOworCisvKioKICAqIFRoaXMgZnVuY3Rpb24gcmV0dXJucyBp
bmZvcm1hdGlvbiBhYm91dCB0aGUgY29udGV4dCBvZiBhIGh2bSBkb21haW4KICAqIEBwYXJtIHhj
aCBhIGhhbmRsZSB0byBhbiBvcGVuIGh5cGVydmlzb3IgaW50ZXJmYWNlCiAgKiBAcGFybSBkb21p
ZCB0aGUgZG9tYWluIHRvIGdldCBpbmZvcm1hdGlvbiBmcm9tCmRpZmYgLXIgZTcxYzRiZGNjMDVh
IHhlbi9hcmNoL3g4Ni9jcHUvbWNoZWNrL21jZV9pbnRlbC5jCi0tLSBhL3hlbi9hcmNoL3g4Ni9j
cHUvbWNoZWNrL21jZV9pbnRlbC5jCVdlZCBTZXAgMTkgMjM6Mjc6NDAgMjAxMiArMDgwMAorKysg
Yi94ZW4vYXJjaC94ODYvY3B1L21jaGVjay9tY2VfaW50ZWwuYwlUaHUgU2VwIDIwIDAwOjAwOjE3
IDIwMTIgKzA4MDAKQEAgLTM1OCw2ICszNTgsMTIgQEAKICAgICAgICAgICAgICAgICAgICAgZ290
byB2bWNlX2ZhaWxlZDsKICAgICAgICAgICAgICAgICB9CiAKKyAgICAgICAgICAgICAgICBpZiAo
IHVubGlrZWx5KGQtPmFyY2gudm1jZV9tb25pdG9yKSApCisgICAgICAgICAgICAgICAgeworICAg
ICAgICAgICAgICAgICAgICAvKiB2TUNFIG9jY3VyIHdoZW4gZ3Vlc3QgbWlncmF0aW9uICovCisg
ICAgICAgICAgICAgICAgICAgIGQtPmFyY2gudm1jZV9tb25pdG9yID0gLTE7CisgICAgICAgICAg
ICAgICAgfQorCiAgICAgICAgICAgICAgICAgLyogV2Ugd2lsbCBpbmplY3Qgdk1DRSB0byBET01V
Ki8KICAgICAgICAgICAgICAgICBpZiAoIGluamVjdF92bWNlKGQpIDwgMCApCiAgICAgICAgICAg
ICAgICAgewpkaWZmIC1yIGU3MWM0YmRjYzA1YSB4ZW4vYXJjaC94ODYvZG9tY3RsLmMKLS0tIGEv
eGVuL2FyY2gveDg2L2RvbWN0bC5jCVdlZCBTZXAgMTkgMjM6Mjc6NDAgMjAxMiArMDgwMAorKysg
Yi94ZW4vYXJjaC94ODYvZG9tY3RsLmMJVGh1IFNlcCAyMCAwMDowMDoxNyAyMDEyICswODAwCkBA
IC0xNTE0LDYgKzE1MTQsNDAgQEAKICAgICB9CiAgICAgYnJlYWs7CiAKKyAgICBjYXNlIFhFTl9E
T01DVExfdm1jZV9tb25pdG9yX3N0YXJ0OgorICAgIHsKKyAgICAgICAgc3RydWN0IGRvbWFpbiAq
ZDsKKworICAgICAgICBkID0gcmN1X2xvY2tfZG9tYWluX2J5X2lkKGRvbWN0bC0+ZG9tYWluKTsK
KyAgICAgICAgaWYgKCBkICE9IE5VTEwgKQorICAgICAgICB7CisgICAgICAgICAgICBkLT5hcmNo
LnZtY2VfbW9uaXRvciA9IDE7CisgICAgICAgICAgICByY3VfdW5sb2NrX2RvbWFpbihkKTsKKyAg
ICAgICAgfQorICAgICAgICBlbHNlCisgICAgICAgICAgICByZXQgPSAtRVNSQ0g7CisgICAgfQor
ICAgIGJyZWFrOworCisgICAgY2FzZSBYRU5fRE9NQ1RMX3ZtY2VfbW9uaXRvcl9lbmQ6CisgICAg
eworICAgICAgICBzdHJ1Y3QgZG9tYWluICpkOworCisgICAgICAgIGQgPSByY3VfbG9ja19kb21h
aW5fYnlfaWQoZG9tY3RsLT5kb21haW4pOworICAgICAgICBpZiAoIGQgIT0gTlVMTCkKKyAgICAg
ICAgeworICAgICAgICAgICAgZG9tY3RsLT51LnZtY2VfbW9uaXRvci52bWNlX3doaWxlX21vbml0
b3IgPQorICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBkLT5hcmNoLnZtY2Vf
bW9uaXRvcjsKKyAgICAgICAgICAgIGQtPmFyY2gudm1jZV9tb25pdG9yID0gMDsKKyAgICAgICAg
ICAgIHJjdV91bmxvY2tfZG9tYWluKGQpOworICAgICAgICAgICAgaWYgKCBjb3B5X3RvX2d1ZXN0
KHVfZG9tY3RsLCBkb21jdGwsIDEpICkKKyAgICAgICAgICAgICAgICByZXQgPSAtRUZBVUxUOwor
ICAgICAgICB9CisgICAgICAgIGVsc2UKKyAgICAgICAgICAgIHJldCA9IC1FU1JDSDsKKyAgICB9
CisgICAgYnJlYWs7CisKICAgICBkZWZhdWx0OgogICAgICAgICByZXQgPSBpb21tdV9kb19kb21j
dGwoZG9tY3RsLCB1X2RvbWN0bCk7CiAgICAgICAgIGJyZWFrOwpkaWZmIC1yIGU3MWM0YmRjYzA1
YSB4ZW4vaW5jbHVkZS9hc20teDg2L2RvbWFpbi5oCi0tLSBhL3hlbi9pbmNsdWRlL2FzbS14ODYv
ZG9tYWluLmgJV2VkIFNlcCAxOSAyMzoyNzo0MCAyMDEyICswODAwCisrKyBiL3hlbi9pbmNsdWRl
L2FzbS14ODYvZG9tYWluLmgJVGh1IFNlcCAyMCAwMDowMDoxNyAyMDEyICswODAwCkBAIC0yNzks
NiArMjc5LDExIEBACiAgICAgYm9vbF90IGhhc18zMmJpdF9zaGluZm87CiAgICAgLyogRG9tYWlu
IGNhbm5vdCBoYW5kbGUgc3B1cmlvdXMgcGFnZSBmYXVsdHM/ICovCiAgICAgYm9vbF90IHN1cHBy
ZXNzX3NwdXJpb3VzX3BhZ2VfZmF1bHRzOworICAgIC8qIE1vbml0b3JpbmcgZ3Vlc3QgbWVtb3J5
IGNvcHkgb2YgbWlncmF0aW9uCisgICAgICogPSAwIC0gbm90IG1vbml0b3JpbmcKKyAgICAgKiA+
IDAgLSBtb25pdG9yaW5nCisgICAgICogPCAwIC0gdk1DRSBvY2N1cnJlZCB3aGlsZSBtb25pdG9y
aW5nICovCisgICAgczggdm1jZV9tb25pdG9yOwogCiAgICAgLyogQ29udGludWFibGUgZG9tYWlu
X3JlbGlucXVpc2hfcmVzb3VyY2VzKCkuICovCiAgICAgZW51bSB7CmRpZmYgLXIgZTcxYzRiZGNj
MDVhIHhlbi9pbmNsdWRlL3B1YmxpYy9kb21jdGwuaAotLS0gYS94ZW4vaW5jbHVkZS9wdWJsaWMv
ZG9tY3RsLmgJV2VkIFNlcCAxOSAyMzoyNzo0MCAyMDEyICswODAwCisrKyBiL3hlbi9pbmNsdWRl
L3B1YmxpYy9kb21jdGwuaAlUaHUgU2VwIDIwIDAwOjAwOjE3IDIwMTIgKzA4MDAKQEAgLTgyOCw2
ICs4MjgsMTIgQEAKIHR5cGVkZWYgc3RydWN0IHhlbl9kb21jdGxfc2V0X2FjY2Vzc19yZXF1aXJl
ZCB4ZW5fZG9tY3RsX3NldF9hY2Nlc3NfcmVxdWlyZWRfdDsKIERFRklORV9YRU5fR1VFU1RfSEFO
RExFKHhlbl9kb21jdGxfc2V0X2FjY2Vzc19yZXF1aXJlZF90KTsKIAorc3RydWN0IHhlbl9kb21j
dGxfdm1jZV9tb25pdG9yIHsKKyAgICBzaWduZWQgY2hhciB2bWNlX3doaWxlX21vbml0b3I7Cit9
OwordHlwZWRlZiBzdHJ1Y3QgeGVuX2RvbWN0bF92bWNlX21vbml0b3IgeGVuX2RvbWN0bF92bWNl
X21vbml0b3JfdDsKK0RFRklORV9YRU5fR1VFU1RfSEFORExFKHhlbl9kb21jdGxfdm1jZV9tb25p
dG9yX3QpOworCiBzdHJ1Y3QgeGVuX2RvbWN0bCB7CiAgICAgdWludDMyX3QgY21kOwogI2RlZmlu
ZSBYRU5fRE9NQ1RMX2NyZWF0ZWRvbWFpbiAgICAgICAgICAgICAgICAgICAxCkBAIC04OTMsNiAr
ODk5LDggQEAKICNkZWZpbmUgWEVOX0RPTUNUTF9zZXRfYWNjZXNzX3JlcXVpcmVkICAgICAgICAg
ICA2NAogI2RlZmluZSBYRU5fRE9NQ1RMX2F1ZGl0X3AybSAgICAgICAgICAgICAgICAgICAgIDY1
CiAjZGVmaW5lIFhFTl9ET01DVExfc2V0X3ZpcnFfaGFuZGxlciAgICAgICAgICAgICAgNjYKKyNk
ZWZpbmUgWEVOX0RPTUNUTF92bWNlX21vbml0b3Jfc3RhcnQgICAgICAgICAgICA2NworI2RlZmlu
ZSBYRU5fRE9NQ1RMX3ZtY2VfbW9uaXRvcl9lbmQgICAgICAgICAgICAgIDY4CiAjZGVmaW5lIFhF
Tl9ET01DVExfZ2Ric3hfZ3Vlc3RtZW1pbyAgICAgICAgICAgIDEwMDAKICNkZWZpbmUgWEVOX0RP
TUNUTF9nZGJzeF9wYXVzZXZjcHUgICAgICAgICAgICAgMTAwMQogI2RlZmluZSBYRU5fRE9NQ1RM
X2dkYnN4X3VucGF1c2V2Y3B1ICAgICAgICAgICAxMDAyCkBAIC05NDcsNiArOTU1LDcgQEAKICAg
ICAgICAgc3RydWN0IHhlbl9kb21jdGxfc2V0X2FjY2Vzc19yZXF1aXJlZCBhY2Nlc3NfcmVxdWly
ZWQ7CiAgICAgICAgIHN0cnVjdCB4ZW5fZG9tY3RsX2F1ZGl0X3AybSAgICAgICAgIGF1ZGl0X3Ay
bTsKICAgICAgICAgc3RydWN0IHhlbl9kb21jdGxfc2V0X3ZpcnFfaGFuZGxlciAgc2V0X3ZpcnFf
aGFuZGxlcjsKKyAgICAgICAgc3RydWN0IHhlbl9kb21jdGxfdm1jZV9tb25pdG9yICAgICAgdm1j
ZV9tb25pdG9yOwogICAgICAgICBzdHJ1Y3QgeGVuX2RvbWN0bF9nZGJzeF9tZW1pbyAgICAgICBn
ZGJzeF9ndWVzdF9tZW1pbzsKICAgICAgICAgc3RydWN0IHhlbl9kb21jdGxfZ2Ric3hfcGF1c2V1
bnBfdmNwdSBnZGJzeF9wYXVzZXVucF92Y3B1OwogICAgICAgICBzdHJ1Y3QgeGVuX2RvbWN0bF9n
ZGJzeF9kb21zdGF0dXMgICBnZGJzeF9kb21zdGF0dXM7Cg==

--_002_DE8DF0795D48FD4CA783C40EC82923353305E0SHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 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_DE8DF0795D48FD4CA783C40EC82923353305E0SHSMSX101ccrcorpi_--


From xen-devel-bounces@lists.xen.org Wed Sep 19 08:16:09 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Sep 2012 08:16:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TEFRu-00050i-0G; Wed, 19 Sep 2012 08:15:58 +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 1TEFRr-00050X-UD
	for xen-devel@lists.xensource.com; Wed, 19 Sep 2012 08:15:56 +0000
Received: from [85.158.143.35:8130] by server-2.bemta-4.messagelabs.com id
	B2/E8-06610-B3F79505; Wed, 19 Sep 2012 08:15:55 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1348042551!10804152!1
X-Originating-IP: [192.55.52.93]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjkzID0+IDM0NDQ2OQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21084 invoked from network); 19 Sep 2012 08:15:52 -0000
Received: from mga11.intel.com (HELO mga11.intel.com) (192.55.52.93)
	by server-10.tower-21.messagelabs.com with SMTP;
	19 Sep 2012 08:15:52 -0000
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
	by fmsmga102.fm.intel.com with ESMTP; 19 Sep 2012 01:15:50 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.80,447,1344236400"; d="scan'208";a="223860235"
Received: from fmsmsx104.amr.corp.intel.com ([10.19.9.35])
	by fmsmga001.fm.intel.com with ESMTP; 19 Sep 2012 01:15:50 -0700
Received: from fmsmsx153.amr.corp.intel.com (10.19.17.7) by
	FMSMSX104.amr.corp.intel.com (10.19.9.35) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Wed, 19 Sep 2012 01:15:49 -0700
Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by
	FMSMSX153.amr.corp.intel.com (10.19.17.7) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Wed, 19 Sep 2012 01:15:49 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.239]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.175]) with mapi id
	14.01.0355.002; Wed, 19 Sep 2012 16:15:48 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: Jan Beulich <JBeulich@suse.com>, "xen-devel@lists.xensource.com"
	<xen-devel@lists.xensource.com>
Thread-Topic: [PATCH 5/5] X86/vMCE: guest broken page handling when migration
Thread-Index: Ac2WPviRvpujVyHJTrqlyn+jqo4zZg==
Date: Wed, 19 Sep 2012 08:15:46 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC82923353305ED@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_DE8DF0795D48FD4CA783C40EC82923353305EDSHSMSX101ccrcorpi_"
MIME-Version: 1.0
Cc: Christoph Egger <Christoph.Egger@amd.com>, "keir@xen.org" <keir@xen.org>,
	"Ian.Campbell@citrix.com" <Ian.Campbell@citrix.com>
Subject: [Xen-devel] [PATCH 5/5] X86/vMCE: guest broken page handling when
	migration
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--_002_DE8DF0795D48FD4CA783C40EC82923353305EDSHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

X86/vMCE: guest broken page handling when migration

This patch is used to handle guest broken page when migration.

At sender, the broken page would not be mapped, and the error page
content would not be copied to target, otherwise it may trigger more
serious error (i.e. SRAR error). While its pfn_type and pfn number
would be transferred to target so that target take appropriate action.

At target, it would set p2m as p2m_ram_broken for broken page, so that
if guest access the broken page again, it would kill guest as expected.

Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>

diff -r a1d106d1aec8 tools/libxc/xc_domain.c
--- a/tools/libxc/xc_domain.c	Wed Sep 19 03:31:31 2012 +0800
+++ b/tools/libxc/xc_domain.c	Wed Sep 19 04:22:26 2012 +0800
@@ -314,6 +314,22 @@
     return ret ? -1 : 0;
 }
=20
+/* set broken page p2m */
+int xc_set_broken_page_p2m(xc_interface *xch,
+                           uint32_t domid,
+                           unsigned long pfn)
+{
+    int ret;
+    DECLARE_DOMCTL;
+
+    domctl.cmd =3D XEN_DOMCTL_set_broken_page_p2m;
+    domctl.domain =3D (domid_t)domid;
+    domctl.u.set_broken_page_p2m.pfn =3D pfn;
+    ret =3D do_domctl(xch, &domctl);
+
+    return ret ? -1 : 0;
+}
+
 /* get info from hvm guest for save */
 int xc_domain_hvm_getcontext(xc_interface *xch,
                              uint32_t domid,
diff -r a1d106d1aec8 tools/libxc/xc_domain_restore.c
--- a/tools/libxc/xc_domain_restore.c	Wed Sep 19 03:31:31 2012 +0800
+++ b/tools/libxc/xc_domain_restore.c	Wed Sep 19 04:22:26 2012 +0800
@@ -962,9 +962,15 @@
=20
     countpages =3D count;
     for (i =3D oldcount; i < buf->nr_pages; ++i)
-        if ((buf->pfn_types[i] & XEN_DOMCTL_PFINFO_LTAB_MASK) =3D=3D XEN_D=
OMCTL_PFINFO_XTAB
-            ||(buf->pfn_types[i] & XEN_DOMCTL_PFINFO_LTAB_MASK) =3D=3D XEN=
_DOMCTL_PFINFO_XALLOC)
+    {
+        unsigned long pagetype;
+
+        pagetype =3D buf->pfn_types[i] & XEN_DOMCTL_PFINFO_LTAB_MASK;
+        if ( pagetype =3D=3D XEN_DOMCTL_PFINFO_XTAB ||
+             pagetype =3D=3D XEN_DOMCTL_PFINFO_BROKEN ||
+             pagetype =3D=3D XEN_DOMCTL_PFINFO_XALLOC )
             --countpages;
+    }
=20
     if (!countpages)
         return count;
@@ -1200,6 +1206,17 @@
             /* a bogus/unmapped/allocate-only page: skip it */
             continue;
=20
+        if ( pagetype =3D=3D XEN_DOMCTL_PFINFO_BROKEN )
+        {
+            if ( xc_set_broken_page_p2m(xch, dom, pfn) )
+            {
+                ERROR("Set p2m for broken page fail, "
+                      "dom=3D%d, pfn=3D%lx\n", dom, pfn);
+                goto err_mapped;
+            }
+            continue;
+        }
+
         if (pfn_err[i])
         {
             ERROR("unexpected PFN mapping failure pfn %lx map_mfn %lx p2m_=
mfn %lx",
diff -r a1d106d1aec8 tools/libxc/xc_domain_save.c
--- a/tools/libxc/xc_domain_save.c	Wed Sep 19 03:31:31 2012 +0800
+++ b/tools/libxc/xc_domain_save.c	Wed Sep 19 04:22:26 2012 +0800
@@ -1285,6 +1285,13 @@
                 if ( !hvm )
                     gmfn =3D pfn_to_mfn(gmfn);
=20
+                if ( pfn_type[j] =3D=3D XEN_DOMCTL_PFINFO_BROKEN )
+                {
+                    pfn_type[j] |=3D pfn_batch[j];
+                    ++run;
+                    continue;
+                }
+
                 if ( pfn_err[j] )
                 {
                     if ( pfn_type[j] =3D=3D XEN_DOMCTL_PFINFO_XTAB )
@@ -1379,8 +1386,12 @@
                     }
                 }
=20
-                /* skip pages that aren't present or are alloc-only */
+                /*
+                 * skip pages that aren't present,
+                 * or are broken, or are alloc-only
+                 */
                 if ( pagetype =3D=3D XEN_DOMCTL_PFINFO_XTAB
+                    || pagetype =3D=3D XEN_DOMCTL_PFINFO_BROKEN
                     || pagetype =3D=3D XEN_DOMCTL_PFINFO_XALLOC )
                     continue;
=20
diff -r a1d106d1aec8 tools/libxc/xenctrl.h
--- a/tools/libxc/xenctrl.h	Wed Sep 19 03:31:31 2012 +0800
+++ b/tools/libxc/xenctrl.h	Wed Sep 19 04:22:26 2012 +0800
@@ -591,6 +591,17 @@
                                signed char *vmce_while_monitor);
=20
 /**
+ * This function set p2m for broken page
+ * &parm xch a handle to an open hypervisor interface
+ * @parm domid the domain id which broken page belong to
+ * @parm pfn the pfn number of the broken page
+ * @return 0 on success, -1 on failure
+ */
+int xc_set_broken_page_p2m(xc_interface *xch,
+                           uint32_t domid,
+                           unsigned long pfn);
+
+/**
  * This function returns information about the context of a hvm domain
  * @parm xch a handle to an open hypervisor interface
  * @parm domid the domain to get information from
diff -r a1d106d1aec8 xen/arch/x86/domctl.c
--- a/xen/arch/x86/domctl.c	Wed Sep 19 03:31:31 2012 +0800
+++ b/xen/arch/x86/domctl.c	Wed Sep 19 04:22:26 2012 +0800
@@ -209,12 +209,18 @@
                 for ( j =3D 0; j < k; j++ )
                 {
                     unsigned long type =3D 0;
+                    p2m_type_t t;
=20
-                    page =3D get_page_from_gfn(d, arr[j], NULL, P2M_ALLOC)=
;
+                    page =3D get_page_from_gfn(d, arr[j], &t, P2M_ALLOC);
=20
                     if ( unlikely(!page) ||
                          unlikely(is_xen_heap_page(page)) )
-                        type =3D XEN_DOMCTL_PFINFO_XTAB;
+                    {
+                        if ( p2m_is_broken(t) )
+                            type =3D XEN_DOMCTL_PFINFO_BROKEN;
+                        else
+                            type =3D XEN_DOMCTL_PFINFO_XTAB;
+                    }
                     else
                     {
                         switch( page->u.inuse.type_info & PGT_type_mask )
@@ -235,6 +241,9 @@
=20
                         if ( page->u.inuse.type_info & PGT_pinned )
                             type |=3D XEN_DOMCTL_PFINFO_LPINTAB;
+
+                        if ( page->count_info & PGC_broken )
+                            type =3D XEN_DOMCTL_PFINFO_BROKEN;
                     }
=20
                     if ( page )
@@ -1548,6 +1557,28 @@
     }
     break;
=20
+    case XEN_DOMCTL_set_broken_page_p2m:
+    {
+        struct domain *d;
+        p2m_type_t pt;
+        unsigned long pfn;
+
+        d =3D rcu_lock_domain_by_id(domctl->domain);
+        if ( d !=3D NULL )
+        {
+            pfn =3D domctl->u.set_broken_page_p2m.pfn;
+
+            get_gfn_query(d, pfn, &pt);
+            p2m_change_type(d, pfn, pt, p2m_ram_broken);
+            put_gfn(d, pfn);
+
+            rcu_unlock_domain(d);
+        }
+        else
+            ret =3D -ESRCH;
+    }
+    break;
+
     default:
         ret =3D iommu_do_domctl(domctl, u_domctl);
         break;
diff -r a1d106d1aec8 xen/include/public/domctl.h
--- a/xen/include/public/domctl.h	Wed Sep 19 03:31:31 2012 +0800
+++ b/xen/include/public/domctl.h	Wed Sep 19 04:22:26 2012 +0800
@@ -136,6 +136,7 @@
 #define XEN_DOMCTL_PFINFO_LPINTAB (0x1U<<31)
 #define XEN_DOMCTL_PFINFO_XTAB    (0xfU<<28) /* invalid page */
 #define XEN_DOMCTL_PFINFO_XALLOC  (0xeU<<28) /* allocate-only page */
+#define XEN_DOMCTL_PFINFO_BROKEN  (0xdU<<28) /* broken page */
 #define XEN_DOMCTL_PFINFO_PAGEDTAB (0x8U<<28)
 #define XEN_DOMCTL_PFINFO_LTAB_MASK (0xfU<<28)
=20
@@ -834,6 +835,12 @@
 typedef struct xen_domctl_vmce_monitor xen_domctl_vmce_monitor_t;
 DEFINE_XEN_GUEST_HANDLE(xen_domctl_vmce_monitor_t);
=20
+struct xen_domctl_set_broken_page_p2m {
+    uint64_t pfn;
+};
+typedef struct xen_domctl_set_broken_page_p2m xen_domctl_set_broken_page_p=
2m_t;
+DEFINE_XEN_GUEST_HANDLE(xen_domctl_set_broken_page_p2m_t);
+
 struct xen_domctl {
     uint32_t cmd;
 #define XEN_DOMCTL_createdomain                   1
@@ -901,6 +908,7 @@
 #define XEN_DOMCTL_set_virq_handler              66
 #define XEN_DOMCTL_vmce_monitor_start            67
 #define XEN_DOMCTL_vmce_monitor_end              68
+#define XEN_DOMCTL_set_broken_page_p2m           69
 #define XEN_DOMCTL_gdbsx_guestmemio            1000
 #define XEN_DOMCTL_gdbsx_pausevcpu             1001
 #define XEN_DOMCTL_gdbsx_unpausevcpu           1002
@@ -957,6 +965,7 @@
         struct xen_domctl_set_virq_handler  set_virq_handler;
         struct xen_domctl_vmce_monitor      vmce_monitor;
         struct xen_domctl_gdbsx_memio       gdbsx_guest_memio;
+        struct xen_domctl_set_broken_page_p2m set_broken_page_p2m;
         struct xen_domctl_gdbsx_pauseunp_vcpu gdbsx_pauseunp_vcpu;
         struct xen_domctl_gdbsx_domstatus   gdbsx_domstatus;
         uint8_t                             pad[128];=

--_002_DE8DF0795D48FD4CA783C40EC82923353305EDSHSMSX101ccrcorpi_
Content-Type: application/octet-stream;
	name="5_vmce_migration_pfntype_broken.patch"
Content-Description: 5_vmce_migration_pfntype_broken.patch
Content-Disposition: attachment;
	filename="5_vmce_migration_pfntype_broken.patch"; size=8499;
	creation-date="Wed, 19 Sep 2012 07:39:51 GMT";
	modification-date="Wed, 19 Sep 2012 15:27:52 GMT"
Content-Transfer-Encoding: base64

WDg2L3ZNQ0U6IGd1ZXN0IGJyb2tlbiBwYWdlIGhhbmRsaW5nIHdoZW4gbWlncmF0aW9uCgpUaGlz
IHBhdGNoIGlzIHVzZWQgdG8gaGFuZGxlIGd1ZXN0IGJyb2tlbiBwYWdlIHdoZW4gbWlncmF0aW9u
LgoKQXQgc2VuZGVyLCB0aGUgYnJva2VuIHBhZ2Ugd291bGQgbm90IGJlIG1hcHBlZCwgYW5kIHRo
ZSBlcnJvciBwYWdlCmNvbnRlbnQgd291bGQgbm90IGJlIGNvcGllZCB0byB0YXJnZXQsIG90aGVy
d2lzZSBpdCBtYXkgdHJpZ2dlciBtb3JlCnNlcmlvdXMgZXJyb3IgKGkuZS4gU1JBUiBlcnJvciku
IFdoaWxlIGl0cyBwZm5fdHlwZSBhbmQgcGZuIG51bWJlcgp3b3VsZCBiZSB0cmFuc2ZlcnJlZCB0
byB0YXJnZXQgc28gdGhhdCB0YXJnZXQgdGFrZSBhcHByb3ByaWF0ZSBhY3Rpb24uCgpBdCB0YXJn
ZXQsIGl0IHdvdWxkIHNldCBwMm0gYXMgcDJtX3JhbV9icm9rZW4gZm9yIGJyb2tlbiBwYWdlLCBz
byB0aGF0CmlmIGd1ZXN0IGFjY2VzcyB0aGUgYnJva2VuIHBhZ2UgYWdhaW4sIGl0IHdvdWxkIGtp
bGwgZ3Vlc3QgYXMgZXhwZWN0ZWQuCgpTaWduZWQtb2ZmLWJ5OiBMaXUsIEppbnNvbmcgPGppbnNv
bmcubGl1QGludGVsLmNvbT4KCmRpZmYgLXIgYTFkMTA2ZDFhZWM4IHRvb2xzL2xpYnhjL3hjX2Rv
bWFpbi5jCi0tLSBhL3Rvb2xzL2xpYnhjL3hjX2RvbWFpbi5jCVdlZCBTZXAgMTkgMDM6MzE6MzEg
MjAxMiArMDgwMAorKysgYi90b29scy9saWJ4Yy94Y19kb21haW4uYwlXZWQgU2VwIDE5IDA0OjIy
OjI2IDIwMTIgKzA4MDAKQEAgLTMxNCw2ICszMTQsMjIgQEAKICAgICByZXR1cm4gcmV0ID8gLTEg
OiAwOwogfQogCisvKiBzZXQgYnJva2VuIHBhZ2UgcDJtICovCitpbnQgeGNfc2V0X2Jyb2tlbl9w
YWdlX3AybSh4Y19pbnRlcmZhY2UgKnhjaCwKKyAgICAgICAgICAgICAgICAgICAgICAgICAgIHVp
bnQzMl90IGRvbWlkLAorICAgICAgICAgICAgICAgICAgICAgICAgICAgdW5zaWduZWQgbG9uZyBw
Zm4pCit7CisgICAgaW50IHJldDsKKyAgICBERUNMQVJFX0RPTUNUTDsKKworICAgIGRvbWN0bC5j
bWQgPSBYRU5fRE9NQ1RMX3NldF9icm9rZW5fcGFnZV9wMm07CisgICAgZG9tY3RsLmRvbWFpbiA9
IChkb21pZF90KWRvbWlkOworICAgIGRvbWN0bC51LnNldF9icm9rZW5fcGFnZV9wMm0ucGZuID0g
cGZuOworICAgIHJldCA9IGRvX2RvbWN0bCh4Y2gsICZkb21jdGwpOworCisgICAgcmV0dXJuIHJl
dCA/IC0xIDogMDsKK30KKwogLyogZ2V0IGluZm8gZnJvbSBodm0gZ3Vlc3QgZm9yIHNhdmUgKi8K
IGludCB4Y19kb21haW5faHZtX2dldGNvbnRleHQoeGNfaW50ZXJmYWNlICp4Y2gsCiAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgIHVpbnQzMl90IGRvbWlkLApkaWZmIC1yIGExZDEwNmQxYWVj
OCB0b29scy9saWJ4Yy94Y19kb21haW5fcmVzdG9yZS5jCi0tLSBhL3Rvb2xzL2xpYnhjL3hjX2Rv
bWFpbl9yZXN0b3JlLmMJV2VkIFNlcCAxOSAwMzozMTozMSAyMDEyICswODAwCisrKyBiL3Rvb2xz
L2xpYnhjL3hjX2RvbWFpbl9yZXN0b3JlLmMJV2VkIFNlcCAxOSAwNDoyMjoyNiAyMDEyICswODAw
CkBAIC05NjIsOSArOTYyLDE1IEBACiAKICAgICBjb3VudHBhZ2VzID0gY291bnQ7CiAgICAgZm9y
IChpID0gb2xkY291bnQ7IGkgPCBidWYtPm5yX3BhZ2VzOyArK2kpCi0gICAgICAgIGlmICgoYnVm
LT5wZm5fdHlwZXNbaV0gJiBYRU5fRE9NQ1RMX1BGSU5GT19MVEFCX01BU0spID09IFhFTl9ET01D
VExfUEZJTkZPX1hUQUIKLSAgICAgICAgICAgIHx8KGJ1Zi0+cGZuX3R5cGVzW2ldICYgWEVOX0RP
TUNUTF9QRklORk9fTFRBQl9NQVNLKSA9PSBYRU5fRE9NQ1RMX1BGSU5GT19YQUxMT0MpCisgICAg
eworICAgICAgICB1bnNpZ25lZCBsb25nIHBhZ2V0eXBlOworCisgICAgICAgIHBhZ2V0eXBlID0g
YnVmLT5wZm5fdHlwZXNbaV0gJiBYRU5fRE9NQ1RMX1BGSU5GT19MVEFCX01BU0s7CisgICAgICAg
IGlmICggcGFnZXR5cGUgPT0gWEVOX0RPTUNUTF9QRklORk9fWFRBQiB8fAorICAgICAgICAgICAg
IHBhZ2V0eXBlID09IFhFTl9ET01DVExfUEZJTkZPX0JST0tFTiB8fAorICAgICAgICAgICAgIHBh
Z2V0eXBlID09IFhFTl9ET01DVExfUEZJTkZPX1hBTExPQyApCiAgICAgICAgICAgICAtLWNvdW50
cGFnZXM7CisgICAgfQogCiAgICAgaWYgKCFjb3VudHBhZ2VzKQogICAgICAgICByZXR1cm4gY291
bnQ7CkBAIC0xMjAwLDYgKzEyMDYsMTcgQEAKICAgICAgICAgICAgIC8qIGEgYm9ndXMvdW5tYXBw
ZWQvYWxsb2NhdGUtb25seSBwYWdlOiBza2lwIGl0ICovCiAgICAgICAgICAgICBjb250aW51ZTsK
IAorICAgICAgICBpZiAoIHBhZ2V0eXBlID09IFhFTl9ET01DVExfUEZJTkZPX0JST0tFTiApCisg
ICAgICAgIHsKKyAgICAgICAgICAgIGlmICggeGNfc2V0X2Jyb2tlbl9wYWdlX3AybSh4Y2gsIGRv
bSwgcGZuKSApCisgICAgICAgICAgICB7CisgICAgICAgICAgICAgICAgRVJST1IoIlNldCBwMm0g
Zm9yIGJyb2tlbiBwYWdlIGZhaWwsICIKKyAgICAgICAgICAgICAgICAgICAgICAiZG9tPSVkLCBw
Zm49JWx4XG4iLCBkb20sIHBmbik7CisgICAgICAgICAgICAgICAgZ290byBlcnJfbWFwcGVkOwor
ICAgICAgICAgICAgfQorICAgICAgICAgICAgY29udGludWU7CisgICAgICAgIH0KKwogICAgICAg
ICBpZiAocGZuX2VycltpXSkKICAgICAgICAgewogICAgICAgICAgICAgRVJST1IoInVuZXhwZWN0
ZWQgUEZOIG1hcHBpbmcgZmFpbHVyZSBwZm4gJWx4IG1hcF9tZm4gJWx4IHAybV9tZm4gJWx4IiwK
ZGlmZiAtciBhMWQxMDZkMWFlYzggdG9vbHMvbGlieGMveGNfZG9tYWluX3NhdmUuYwotLS0gYS90
b29scy9saWJ4Yy94Y19kb21haW5fc2F2ZS5jCVdlZCBTZXAgMTkgMDM6MzE6MzEgMjAxMiArMDgw
MAorKysgYi90b29scy9saWJ4Yy94Y19kb21haW5fc2F2ZS5jCVdlZCBTZXAgMTkgMDQ6MjI6MjYg
MjAxMiArMDgwMApAQCAtMTI4NSw2ICsxMjg1LDEzIEBACiAgICAgICAgICAgICAgICAgaWYgKCAh
aHZtICkKICAgICAgICAgICAgICAgICAgICAgZ21mbiA9IHBmbl90b19tZm4oZ21mbik7CiAKKyAg
ICAgICAgICAgICAgICBpZiAoIHBmbl90eXBlW2pdID09IFhFTl9ET01DVExfUEZJTkZPX0JST0tF
TiApCisgICAgICAgICAgICAgICAgeworICAgICAgICAgICAgICAgICAgICBwZm5fdHlwZVtqXSB8
PSBwZm5fYmF0Y2hbal07CisgICAgICAgICAgICAgICAgICAgICsrcnVuOworICAgICAgICAgICAg
ICAgICAgICBjb250aW51ZTsKKyAgICAgICAgICAgICAgICB9CisKICAgICAgICAgICAgICAgICBp
ZiAoIHBmbl9lcnJbal0gKQogICAgICAgICAgICAgICAgIHsKICAgICAgICAgICAgICAgICAgICAg
aWYgKCBwZm5fdHlwZVtqXSA9PSBYRU5fRE9NQ1RMX1BGSU5GT19YVEFCICkKQEAgLTEzNzksOCAr
MTM4NiwxMiBAQAogICAgICAgICAgICAgICAgICAgICB9CiAgICAgICAgICAgICAgICAgfQogCi0g
ICAgICAgICAgICAgICAgLyogc2tpcCBwYWdlcyB0aGF0IGFyZW4ndCBwcmVzZW50IG9yIGFyZSBh
bGxvYy1vbmx5ICovCisgICAgICAgICAgICAgICAgLyoKKyAgICAgICAgICAgICAgICAgKiBza2lw
IHBhZ2VzIHRoYXQgYXJlbid0IHByZXNlbnQsCisgICAgICAgICAgICAgICAgICogb3IgYXJlIGJy
b2tlbiwgb3IgYXJlIGFsbG9jLW9ubHkKKyAgICAgICAgICAgICAgICAgKi8KICAgICAgICAgICAg
ICAgICBpZiAoIHBhZ2V0eXBlID09IFhFTl9ET01DVExfUEZJTkZPX1hUQUIKKyAgICAgICAgICAg
ICAgICAgICAgfHwgcGFnZXR5cGUgPT0gWEVOX0RPTUNUTF9QRklORk9fQlJPS0VOCiAgICAgICAg
ICAgICAgICAgICAgIHx8IHBhZ2V0eXBlID09IFhFTl9ET01DVExfUEZJTkZPX1hBTExPQyApCiAg
ICAgICAgICAgICAgICAgICAgIGNvbnRpbnVlOwogCmRpZmYgLXIgYTFkMTA2ZDFhZWM4IHRvb2xz
L2xpYnhjL3hlbmN0cmwuaAotLS0gYS90b29scy9saWJ4Yy94ZW5jdHJsLmgJV2VkIFNlcCAxOSAw
MzozMTozMSAyMDEyICswODAwCisrKyBiL3Rvb2xzL2xpYnhjL3hlbmN0cmwuaAlXZWQgU2VwIDE5
IDA0OjIyOjI2IDIwMTIgKzA4MDAKQEAgLTU5MSw2ICs1OTEsMTcgQEAKICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICBzaWduZWQgY2hhciAqdm1jZV93aGlsZV9tb25pdG9yKTsKIAogLyoq
CisgKiBUaGlzIGZ1bmN0aW9uIHNldCBwMm0gZm9yIGJyb2tlbiBwYWdlCisgKiAmcGFybSB4Y2gg
YSBoYW5kbGUgdG8gYW4gb3BlbiBoeXBlcnZpc29yIGludGVyZmFjZQorICogQHBhcm0gZG9taWQg
dGhlIGRvbWFpbiBpZCB3aGljaCBicm9rZW4gcGFnZSBiZWxvbmcgdG8KKyAqIEBwYXJtIHBmbiB0
aGUgcGZuIG51bWJlciBvZiB0aGUgYnJva2VuIHBhZ2UKKyAqIEByZXR1cm4gMCBvbiBzdWNjZXNz
LCAtMSBvbiBmYWlsdXJlCisgKi8KK2ludCB4Y19zZXRfYnJva2VuX3BhZ2VfcDJtKHhjX2ludGVy
ZmFjZSAqeGNoLAorICAgICAgICAgICAgICAgICAgICAgICAgICAgdWludDMyX3QgZG9taWQsCisg
ICAgICAgICAgICAgICAgICAgICAgICAgICB1bnNpZ25lZCBsb25nIHBmbik7CisKKy8qKgogICog
VGhpcyBmdW5jdGlvbiByZXR1cm5zIGluZm9ybWF0aW9uIGFib3V0IHRoZSBjb250ZXh0IG9mIGEg
aHZtIGRvbWFpbgogICogQHBhcm0geGNoIGEgaGFuZGxlIHRvIGFuIG9wZW4gaHlwZXJ2aXNvciBp
bnRlcmZhY2UKICAqIEBwYXJtIGRvbWlkIHRoZSBkb21haW4gdG8gZ2V0IGluZm9ybWF0aW9uIGZy
b20KZGlmZiAtciBhMWQxMDZkMWFlYzggeGVuL2FyY2gveDg2L2RvbWN0bC5jCi0tLSBhL3hlbi9h
cmNoL3g4Ni9kb21jdGwuYwlXZWQgU2VwIDE5IDAzOjMxOjMxIDIwMTIgKzA4MDAKKysrIGIveGVu
L2FyY2gveDg2L2RvbWN0bC5jCVdlZCBTZXAgMTkgMDQ6MjI6MjYgMjAxMiArMDgwMApAQCAtMjA5
LDEyICsyMDksMTggQEAKICAgICAgICAgICAgICAgICBmb3IgKCBqID0gMDsgaiA8IGs7IGorKyAp
CiAgICAgICAgICAgICAgICAgewogICAgICAgICAgICAgICAgICAgICB1bnNpZ25lZCBsb25nIHR5
cGUgPSAwOworICAgICAgICAgICAgICAgICAgICBwMm1fdHlwZV90IHQ7CiAKLSAgICAgICAgICAg
ICAgICAgICAgcGFnZSA9IGdldF9wYWdlX2Zyb21fZ2ZuKGQsIGFycltqXSwgTlVMTCwgUDJNX0FM
TE9DKTsKKyAgICAgICAgICAgICAgICAgICAgcGFnZSA9IGdldF9wYWdlX2Zyb21fZ2ZuKGQsIGFy
cltqXSwgJnQsIFAyTV9BTExPQyk7CiAKICAgICAgICAgICAgICAgICAgICAgaWYgKCB1bmxpa2Vs
eSghcGFnZSkgfHwKICAgICAgICAgICAgICAgICAgICAgICAgICB1bmxpa2VseShpc194ZW5faGVh
cF9wYWdlKHBhZ2UpKSApCi0gICAgICAgICAgICAgICAgICAgICAgICB0eXBlID0gWEVOX0RPTUNU
TF9QRklORk9fWFRBQjsKKyAgICAgICAgICAgICAgICAgICAgeworICAgICAgICAgICAgICAgICAg
ICAgICAgaWYgKCBwMm1faXNfYnJva2VuKHQpICkKKyAgICAgICAgICAgICAgICAgICAgICAgICAg
ICB0eXBlID0gWEVOX0RPTUNUTF9QRklORk9fQlJPS0VOOworICAgICAgICAgICAgICAgICAgICAg
ICAgZWxzZQorICAgICAgICAgICAgICAgICAgICAgICAgICAgIHR5cGUgPSBYRU5fRE9NQ1RMX1BG
SU5GT19YVEFCOworICAgICAgICAgICAgICAgICAgICB9CiAgICAgICAgICAgICAgICAgICAgIGVs
c2UKICAgICAgICAgICAgICAgICAgICAgewogICAgICAgICAgICAgICAgICAgICAgICAgc3dpdGNo
KCBwYWdlLT51LmludXNlLnR5cGVfaW5mbyAmIFBHVF90eXBlX21hc2sgKQpAQCAtMjM1LDYgKzI0
MSw5IEBACiAKICAgICAgICAgICAgICAgICAgICAgICAgIGlmICggcGFnZS0+dS5pbnVzZS50eXBl
X2luZm8gJiBQR1RfcGlubmVkICkKICAgICAgICAgICAgICAgICAgICAgICAgICAgICB0eXBlIHw9
IFhFTl9ET01DVExfUEZJTkZPX0xQSU5UQUI7CisKKyAgICAgICAgICAgICAgICAgICAgICAgIGlm
ICggcGFnZS0+Y291bnRfaW5mbyAmIFBHQ19icm9rZW4gKQorICAgICAgICAgICAgICAgICAgICAg
ICAgICAgIHR5cGUgPSBYRU5fRE9NQ1RMX1BGSU5GT19CUk9LRU47CiAgICAgICAgICAgICAgICAg
ICAgIH0KIAogICAgICAgICAgICAgICAgICAgICBpZiAoIHBhZ2UgKQpAQCAtMTU0OCw2ICsxNTU3
LDI4IEBACiAgICAgfQogICAgIGJyZWFrOwogCisgICAgY2FzZSBYRU5fRE9NQ1RMX3NldF9icm9r
ZW5fcGFnZV9wMm06CisgICAgeworICAgICAgICBzdHJ1Y3QgZG9tYWluICpkOworICAgICAgICBw
Mm1fdHlwZV90IHB0OworICAgICAgICB1bnNpZ25lZCBsb25nIHBmbjsKKworICAgICAgICBkID0g
cmN1X2xvY2tfZG9tYWluX2J5X2lkKGRvbWN0bC0+ZG9tYWluKTsKKyAgICAgICAgaWYgKCBkICE9
IE5VTEwgKQorICAgICAgICB7CisgICAgICAgICAgICBwZm4gPSBkb21jdGwtPnUuc2V0X2Jyb2tl
bl9wYWdlX3AybS5wZm47CisKKyAgICAgICAgICAgIGdldF9nZm5fcXVlcnkoZCwgcGZuLCAmcHQp
OworICAgICAgICAgICAgcDJtX2NoYW5nZV90eXBlKGQsIHBmbiwgcHQsIHAybV9yYW1fYnJva2Vu
KTsKKyAgICAgICAgICAgIHB1dF9nZm4oZCwgcGZuKTsKKworICAgICAgICAgICAgcmN1X3VubG9j
a19kb21haW4oZCk7CisgICAgICAgIH0KKyAgICAgICAgZWxzZQorICAgICAgICAgICAgcmV0ID0g
LUVTUkNIOworICAgIH0KKyAgICBicmVhazsKKwogICAgIGRlZmF1bHQ6CiAgICAgICAgIHJldCA9
IGlvbW11X2RvX2RvbWN0bChkb21jdGwsIHVfZG9tY3RsKTsKICAgICAgICAgYnJlYWs7CmRpZmYg
LXIgYTFkMTA2ZDFhZWM4IHhlbi9pbmNsdWRlL3B1YmxpYy9kb21jdGwuaAotLS0gYS94ZW4vaW5j
bHVkZS9wdWJsaWMvZG9tY3RsLmgJV2VkIFNlcCAxOSAwMzozMTozMSAyMDEyICswODAwCisrKyBi
L3hlbi9pbmNsdWRlL3B1YmxpYy9kb21jdGwuaAlXZWQgU2VwIDE5IDA0OjIyOjI2IDIwMTIgKzA4
MDAKQEAgLTEzNiw2ICsxMzYsNyBAQAogI2RlZmluZSBYRU5fRE9NQ1RMX1BGSU5GT19MUElOVEFC
ICgweDFVPDwzMSkKICNkZWZpbmUgWEVOX0RPTUNUTF9QRklORk9fWFRBQiAgICAoMHhmVTw8Mjgp
IC8qIGludmFsaWQgcGFnZSAqLwogI2RlZmluZSBYRU5fRE9NQ1RMX1BGSU5GT19YQUxMT0MgICgw
eGVVPDwyOCkgLyogYWxsb2NhdGUtb25seSBwYWdlICovCisjZGVmaW5lIFhFTl9ET01DVExfUEZJ
TkZPX0JST0tFTiAgKDB4ZFU8PDI4KSAvKiBicm9rZW4gcGFnZSAqLwogI2RlZmluZSBYRU5fRE9N
Q1RMX1BGSU5GT19QQUdFRFRBQiAoMHg4VTw8MjgpCiAjZGVmaW5lIFhFTl9ET01DVExfUEZJTkZP
X0xUQUJfTUFTSyAoMHhmVTw8MjgpCiAKQEAgLTgzNCw2ICs4MzUsMTIgQEAKIHR5cGVkZWYgc3Ry
dWN0IHhlbl9kb21jdGxfdm1jZV9tb25pdG9yIHhlbl9kb21jdGxfdm1jZV9tb25pdG9yX3Q7CiBE
RUZJTkVfWEVOX0dVRVNUX0hBTkRMRSh4ZW5fZG9tY3RsX3ZtY2VfbW9uaXRvcl90KTsKIAorc3Ry
dWN0IHhlbl9kb21jdGxfc2V0X2Jyb2tlbl9wYWdlX3AybSB7CisgICAgdWludDY0X3QgcGZuOwor
fTsKK3R5cGVkZWYgc3RydWN0IHhlbl9kb21jdGxfc2V0X2Jyb2tlbl9wYWdlX3AybSB4ZW5fZG9t
Y3RsX3NldF9icm9rZW5fcGFnZV9wMm1fdDsKK0RFRklORV9YRU5fR1VFU1RfSEFORExFKHhlbl9k
b21jdGxfc2V0X2Jyb2tlbl9wYWdlX3AybV90KTsKKwogc3RydWN0IHhlbl9kb21jdGwgewogICAg
IHVpbnQzMl90IGNtZDsKICNkZWZpbmUgWEVOX0RPTUNUTF9jcmVhdGVkb21haW4gICAgICAgICAg
ICAgICAgICAgMQpAQCAtOTAxLDYgKzkwOCw3IEBACiAjZGVmaW5lIFhFTl9ET01DVExfc2V0X3Zp
cnFfaGFuZGxlciAgICAgICAgICAgICAgNjYKICNkZWZpbmUgWEVOX0RPTUNUTF92bWNlX21vbml0
b3Jfc3RhcnQgICAgICAgICAgICA2NwogI2RlZmluZSBYRU5fRE9NQ1RMX3ZtY2VfbW9uaXRvcl9l
bmQgICAgICAgICAgICAgIDY4CisjZGVmaW5lIFhFTl9ET01DVExfc2V0X2Jyb2tlbl9wYWdlX3Ay
bSAgICAgICAgICAgNjkKICNkZWZpbmUgWEVOX0RPTUNUTF9nZGJzeF9ndWVzdG1lbWlvICAgICAg
ICAgICAgMTAwMAogI2RlZmluZSBYRU5fRE9NQ1RMX2dkYnN4X3BhdXNldmNwdSAgICAgICAgICAg
ICAxMDAxCiAjZGVmaW5lIFhFTl9ET01DVExfZ2Ric3hfdW5wYXVzZXZjcHUgICAgICAgICAgIDEw
MDIKQEAgLTk1Nyw2ICs5NjUsNyBAQAogICAgICAgICBzdHJ1Y3QgeGVuX2RvbWN0bF9zZXRfdmly
cV9oYW5kbGVyICBzZXRfdmlycV9oYW5kbGVyOwogICAgICAgICBzdHJ1Y3QgeGVuX2RvbWN0bF92
bWNlX21vbml0b3IgICAgICB2bWNlX21vbml0b3I7CiAgICAgICAgIHN0cnVjdCB4ZW5fZG9tY3Rs
X2dkYnN4X21lbWlvICAgICAgIGdkYnN4X2d1ZXN0X21lbWlvOworICAgICAgICBzdHJ1Y3QgeGVu
X2RvbWN0bF9zZXRfYnJva2VuX3BhZ2VfcDJtIHNldF9icm9rZW5fcGFnZV9wMm07CiAgICAgICAg
IHN0cnVjdCB4ZW5fZG9tY3RsX2dkYnN4X3BhdXNldW5wX3ZjcHUgZ2Ric3hfcGF1c2V1bnBfdmNw
dTsKICAgICAgICAgc3RydWN0IHhlbl9kb21jdGxfZ2Ric3hfZG9tc3RhdHVzICAgZ2Ric3hfZG9t
c3RhdHVzOwogICAgICAgICB1aW50OF90ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBwYWRb
MTI4XTsK

--_002_DE8DF0795D48FD4CA783C40EC82923353305EDSHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 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_DE8DF0795D48FD4CA783C40EC82923353305EDSHSMSX101ccrcorpi_--


From xen-devel-bounces@lists.xen.org Wed Sep 19 08:16:09 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Sep 2012 08:16:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TEFRu-00050i-0G; Wed, 19 Sep 2012 08:15:58 +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 1TEFRr-00050X-UD
	for xen-devel@lists.xensource.com; Wed, 19 Sep 2012 08:15:56 +0000
Received: from [85.158.143.35:8130] by server-2.bemta-4.messagelabs.com id
	B2/E8-06610-B3F79505; Wed, 19 Sep 2012 08:15:55 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1348042551!10804152!1
X-Originating-IP: [192.55.52.93]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjkzID0+IDM0NDQ2OQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21084 invoked from network); 19 Sep 2012 08:15:52 -0000
Received: from mga11.intel.com (HELO mga11.intel.com) (192.55.52.93)
	by server-10.tower-21.messagelabs.com with SMTP;
	19 Sep 2012 08:15:52 -0000
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
	by fmsmga102.fm.intel.com with ESMTP; 19 Sep 2012 01:15:50 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.80,447,1344236400"; d="scan'208";a="223860235"
Received: from fmsmsx104.amr.corp.intel.com ([10.19.9.35])
	by fmsmga001.fm.intel.com with ESMTP; 19 Sep 2012 01:15:50 -0700
Received: from fmsmsx153.amr.corp.intel.com (10.19.17.7) by
	FMSMSX104.amr.corp.intel.com (10.19.9.35) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Wed, 19 Sep 2012 01:15:49 -0700
Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by
	FMSMSX153.amr.corp.intel.com (10.19.17.7) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Wed, 19 Sep 2012 01:15:49 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.239]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.175]) with mapi id
	14.01.0355.002; Wed, 19 Sep 2012 16:15:48 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: Jan Beulich <JBeulich@suse.com>, "xen-devel@lists.xensource.com"
	<xen-devel@lists.xensource.com>
Thread-Topic: [PATCH 5/5] X86/vMCE: guest broken page handling when migration
Thread-Index: Ac2WPviRvpujVyHJTrqlyn+jqo4zZg==
Date: Wed, 19 Sep 2012 08:15:46 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC82923353305ED@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_DE8DF0795D48FD4CA783C40EC82923353305EDSHSMSX101ccrcorpi_"
MIME-Version: 1.0
Cc: Christoph Egger <Christoph.Egger@amd.com>, "keir@xen.org" <keir@xen.org>,
	"Ian.Campbell@citrix.com" <Ian.Campbell@citrix.com>
Subject: [Xen-devel] [PATCH 5/5] X86/vMCE: guest broken page handling when
	migration
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--_002_DE8DF0795D48FD4CA783C40EC82923353305EDSHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

X86/vMCE: guest broken page handling when migration

This patch is used to handle guest broken page when migration.

At sender, the broken page would not be mapped, and the error page
content would not be copied to target, otherwise it may trigger more
serious error (i.e. SRAR error). While its pfn_type and pfn number
would be transferred to target so that target take appropriate action.

At target, it would set p2m as p2m_ram_broken for broken page, so that
if guest access the broken page again, it would kill guest as expected.

Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>

diff -r a1d106d1aec8 tools/libxc/xc_domain.c
--- a/tools/libxc/xc_domain.c	Wed Sep 19 03:31:31 2012 +0800
+++ b/tools/libxc/xc_domain.c	Wed Sep 19 04:22:26 2012 +0800
@@ -314,6 +314,22 @@
     return ret ? -1 : 0;
 }
=20
+/* set broken page p2m */
+int xc_set_broken_page_p2m(xc_interface *xch,
+                           uint32_t domid,
+                           unsigned long pfn)
+{
+    int ret;
+    DECLARE_DOMCTL;
+
+    domctl.cmd =3D XEN_DOMCTL_set_broken_page_p2m;
+    domctl.domain =3D (domid_t)domid;
+    domctl.u.set_broken_page_p2m.pfn =3D pfn;
+    ret =3D do_domctl(xch, &domctl);
+
+    return ret ? -1 : 0;
+}
+
 /* get info from hvm guest for save */
 int xc_domain_hvm_getcontext(xc_interface *xch,
                              uint32_t domid,
diff -r a1d106d1aec8 tools/libxc/xc_domain_restore.c
--- a/tools/libxc/xc_domain_restore.c	Wed Sep 19 03:31:31 2012 +0800
+++ b/tools/libxc/xc_domain_restore.c	Wed Sep 19 04:22:26 2012 +0800
@@ -962,9 +962,15 @@
=20
     countpages =3D count;
     for (i =3D oldcount; i < buf->nr_pages; ++i)
-        if ((buf->pfn_types[i] & XEN_DOMCTL_PFINFO_LTAB_MASK) =3D=3D XEN_D=
OMCTL_PFINFO_XTAB
-            ||(buf->pfn_types[i] & XEN_DOMCTL_PFINFO_LTAB_MASK) =3D=3D XEN=
_DOMCTL_PFINFO_XALLOC)
+    {
+        unsigned long pagetype;
+
+        pagetype =3D buf->pfn_types[i] & XEN_DOMCTL_PFINFO_LTAB_MASK;
+        if ( pagetype =3D=3D XEN_DOMCTL_PFINFO_XTAB ||
+             pagetype =3D=3D XEN_DOMCTL_PFINFO_BROKEN ||
+             pagetype =3D=3D XEN_DOMCTL_PFINFO_XALLOC )
             --countpages;
+    }
=20
     if (!countpages)
         return count;
@@ -1200,6 +1206,17 @@
             /* a bogus/unmapped/allocate-only page: skip it */
             continue;
=20
+        if ( pagetype =3D=3D XEN_DOMCTL_PFINFO_BROKEN )
+        {
+            if ( xc_set_broken_page_p2m(xch, dom, pfn) )
+            {
+                ERROR("Set p2m for broken page fail, "
+                      "dom=3D%d, pfn=3D%lx\n", dom, pfn);
+                goto err_mapped;
+            }
+            continue;
+        }
+
         if (pfn_err[i])
         {
             ERROR("unexpected PFN mapping failure pfn %lx map_mfn %lx p2m_=
mfn %lx",
diff -r a1d106d1aec8 tools/libxc/xc_domain_save.c
--- a/tools/libxc/xc_domain_save.c	Wed Sep 19 03:31:31 2012 +0800
+++ b/tools/libxc/xc_domain_save.c	Wed Sep 19 04:22:26 2012 +0800
@@ -1285,6 +1285,13 @@
                 if ( !hvm )
                     gmfn =3D pfn_to_mfn(gmfn);
=20
+                if ( pfn_type[j] =3D=3D XEN_DOMCTL_PFINFO_BROKEN )
+                {
+                    pfn_type[j] |=3D pfn_batch[j];
+                    ++run;
+                    continue;
+                }
+
                 if ( pfn_err[j] )
                 {
                     if ( pfn_type[j] =3D=3D XEN_DOMCTL_PFINFO_XTAB )
@@ -1379,8 +1386,12 @@
                     }
                 }
=20
-                /* skip pages that aren't present or are alloc-only */
+                /*
+                 * skip pages that aren't present,
+                 * or are broken, or are alloc-only
+                 */
                 if ( pagetype =3D=3D XEN_DOMCTL_PFINFO_XTAB
+                    || pagetype =3D=3D XEN_DOMCTL_PFINFO_BROKEN
                     || pagetype =3D=3D XEN_DOMCTL_PFINFO_XALLOC )
                     continue;
=20
diff -r a1d106d1aec8 tools/libxc/xenctrl.h
--- a/tools/libxc/xenctrl.h	Wed Sep 19 03:31:31 2012 +0800
+++ b/tools/libxc/xenctrl.h	Wed Sep 19 04:22:26 2012 +0800
@@ -591,6 +591,17 @@
                                signed char *vmce_while_monitor);
=20
 /**
+ * This function set p2m for broken page
+ * &parm xch a handle to an open hypervisor interface
+ * @parm domid the domain id which broken page belong to
+ * @parm pfn the pfn number of the broken page
+ * @return 0 on success, -1 on failure
+ */
+int xc_set_broken_page_p2m(xc_interface *xch,
+                           uint32_t domid,
+                           unsigned long pfn);
+
+/**
  * This function returns information about the context of a hvm domain
  * @parm xch a handle to an open hypervisor interface
  * @parm domid the domain to get information from
diff -r a1d106d1aec8 xen/arch/x86/domctl.c
--- a/xen/arch/x86/domctl.c	Wed Sep 19 03:31:31 2012 +0800
+++ b/xen/arch/x86/domctl.c	Wed Sep 19 04:22:26 2012 +0800
@@ -209,12 +209,18 @@
                 for ( j =3D 0; j < k; j++ )
                 {
                     unsigned long type =3D 0;
+                    p2m_type_t t;
=20
-                    page =3D get_page_from_gfn(d, arr[j], NULL, P2M_ALLOC)=
;
+                    page =3D get_page_from_gfn(d, arr[j], &t, P2M_ALLOC);
=20
                     if ( unlikely(!page) ||
                          unlikely(is_xen_heap_page(page)) )
-                        type =3D XEN_DOMCTL_PFINFO_XTAB;
+                    {
+                        if ( p2m_is_broken(t) )
+                            type =3D XEN_DOMCTL_PFINFO_BROKEN;
+                        else
+                            type =3D XEN_DOMCTL_PFINFO_XTAB;
+                    }
                     else
                     {
                         switch( page->u.inuse.type_info & PGT_type_mask )
@@ -235,6 +241,9 @@
=20
                         if ( page->u.inuse.type_info & PGT_pinned )
                             type |=3D XEN_DOMCTL_PFINFO_LPINTAB;
+
+                        if ( page->count_info & PGC_broken )
+                            type =3D XEN_DOMCTL_PFINFO_BROKEN;
                     }
=20
                     if ( page )
@@ -1548,6 +1557,28 @@
     }
     break;
=20
+    case XEN_DOMCTL_set_broken_page_p2m:
+    {
+        struct domain *d;
+        p2m_type_t pt;
+        unsigned long pfn;
+
+        d =3D rcu_lock_domain_by_id(domctl->domain);
+        if ( d !=3D NULL )
+        {
+            pfn =3D domctl->u.set_broken_page_p2m.pfn;
+
+            get_gfn_query(d, pfn, &pt);
+            p2m_change_type(d, pfn, pt, p2m_ram_broken);
+            put_gfn(d, pfn);
+
+            rcu_unlock_domain(d);
+        }
+        else
+            ret =3D -ESRCH;
+    }
+    break;
+
     default:
         ret =3D iommu_do_domctl(domctl, u_domctl);
         break;
diff -r a1d106d1aec8 xen/include/public/domctl.h
--- a/xen/include/public/domctl.h	Wed Sep 19 03:31:31 2012 +0800
+++ b/xen/include/public/domctl.h	Wed Sep 19 04:22:26 2012 +0800
@@ -136,6 +136,7 @@
 #define XEN_DOMCTL_PFINFO_LPINTAB (0x1U<<31)
 #define XEN_DOMCTL_PFINFO_XTAB    (0xfU<<28) /* invalid page */
 #define XEN_DOMCTL_PFINFO_XALLOC  (0xeU<<28) /* allocate-only page */
+#define XEN_DOMCTL_PFINFO_BROKEN  (0xdU<<28) /* broken page */
 #define XEN_DOMCTL_PFINFO_PAGEDTAB (0x8U<<28)
 #define XEN_DOMCTL_PFINFO_LTAB_MASK (0xfU<<28)
=20
@@ -834,6 +835,12 @@
 typedef struct xen_domctl_vmce_monitor xen_domctl_vmce_monitor_t;
 DEFINE_XEN_GUEST_HANDLE(xen_domctl_vmce_monitor_t);
=20
+struct xen_domctl_set_broken_page_p2m {
+    uint64_t pfn;
+};
+typedef struct xen_domctl_set_broken_page_p2m xen_domctl_set_broken_page_p=
2m_t;
+DEFINE_XEN_GUEST_HANDLE(xen_domctl_set_broken_page_p2m_t);
+
 struct xen_domctl {
     uint32_t cmd;
 #define XEN_DOMCTL_createdomain                   1
@@ -901,6 +908,7 @@
 #define XEN_DOMCTL_set_virq_handler              66
 #define XEN_DOMCTL_vmce_monitor_start            67
 #define XEN_DOMCTL_vmce_monitor_end              68
+#define XEN_DOMCTL_set_broken_page_p2m           69
 #define XEN_DOMCTL_gdbsx_guestmemio            1000
 #define XEN_DOMCTL_gdbsx_pausevcpu             1001
 #define XEN_DOMCTL_gdbsx_unpausevcpu           1002
@@ -957,6 +965,7 @@
         struct xen_domctl_set_virq_handler  set_virq_handler;
         struct xen_domctl_vmce_monitor      vmce_monitor;
         struct xen_domctl_gdbsx_memio       gdbsx_guest_memio;
+        struct xen_domctl_set_broken_page_p2m set_broken_page_p2m;
         struct xen_domctl_gdbsx_pauseunp_vcpu gdbsx_pauseunp_vcpu;
         struct xen_domctl_gdbsx_domstatus   gdbsx_domstatus;
         uint8_t                             pad[128];=

--_002_DE8DF0795D48FD4CA783C40EC82923353305EDSHSMSX101ccrcorpi_
Content-Type: application/octet-stream;
	name="5_vmce_migration_pfntype_broken.patch"
Content-Description: 5_vmce_migration_pfntype_broken.patch
Content-Disposition: attachment;
	filename="5_vmce_migration_pfntype_broken.patch"; size=8499;
	creation-date="Wed, 19 Sep 2012 07:39:51 GMT";
	modification-date="Wed, 19 Sep 2012 15:27:52 GMT"
Content-Transfer-Encoding: base64

WDg2L3ZNQ0U6IGd1ZXN0IGJyb2tlbiBwYWdlIGhhbmRsaW5nIHdoZW4gbWlncmF0aW9uCgpUaGlz
IHBhdGNoIGlzIHVzZWQgdG8gaGFuZGxlIGd1ZXN0IGJyb2tlbiBwYWdlIHdoZW4gbWlncmF0aW9u
LgoKQXQgc2VuZGVyLCB0aGUgYnJva2VuIHBhZ2Ugd291bGQgbm90IGJlIG1hcHBlZCwgYW5kIHRo
ZSBlcnJvciBwYWdlCmNvbnRlbnQgd291bGQgbm90IGJlIGNvcGllZCB0byB0YXJnZXQsIG90aGVy
d2lzZSBpdCBtYXkgdHJpZ2dlciBtb3JlCnNlcmlvdXMgZXJyb3IgKGkuZS4gU1JBUiBlcnJvciku
IFdoaWxlIGl0cyBwZm5fdHlwZSBhbmQgcGZuIG51bWJlcgp3b3VsZCBiZSB0cmFuc2ZlcnJlZCB0
byB0YXJnZXQgc28gdGhhdCB0YXJnZXQgdGFrZSBhcHByb3ByaWF0ZSBhY3Rpb24uCgpBdCB0YXJn
ZXQsIGl0IHdvdWxkIHNldCBwMm0gYXMgcDJtX3JhbV9icm9rZW4gZm9yIGJyb2tlbiBwYWdlLCBz
byB0aGF0CmlmIGd1ZXN0IGFjY2VzcyB0aGUgYnJva2VuIHBhZ2UgYWdhaW4sIGl0IHdvdWxkIGtp
bGwgZ3Vlc3QgYXMgZXhwZWN0ZWQuCgpTaWduZWQtb2ZmLWJ5OiBMaXUsIEppbnNvbmcgPGppbnNv
bmcubGl1QGludGVsLmNvbT4KCmRpZmYgLXIgYTFkMTA2ZDFhZWM4IHRvb2xzL2xpYnhjL3hjX2Rv
bWFpbi5jCi0tLSBhL3Rvb2xzL2xpYnhjL3hjX2RvbWFpbi5jCVdlZCBTZXAgMTkgMDM6MzE6MzEg
MjAxMiArMDgwMAorKysgYi90b29scy9saWJ4Yy94Y19kb21haW4uYwlXZWQgU2VwIDE5IDA0OjIy
OjI2IDIwMTIgKzA4MDAKQEAgLTMxNCw2ICszMTQsMjIgQEAKICAgICByZXR1cm4gcmV0ID8gLTEg
OiAwOwogfQogCisvKiBzZXQgYnJva2VuIHBhZ2UgcDJtICovCitpbnQgeGNfc2V0X2Jyb2tlbl9w
YWdlX3AybSh4Y19pbnRlcmZhY2UgKnhjaCwKKyAgICAgICAgICAgICAgICAgICAgICAgICAgIHVp
bnQzMl90IGRvbWlkLAorICAgICAgICAgICAgICAgICAgICAgICAgICAgdW5zaWduZWQgbG9uZyBw
Zm4pCit7CisgICAgaW50IHJldDsKKyAgICBERUNMQVJFX0RPTUNUTDsKKworICAgIGRvbWN0bC5j
bWQgPSBYRU5fRE9NQ1RMX3NldF9icm9rZW5fcGFnZV9wMm07CisgICAgZG9tY3RsLmRvbWFpbiA9
IChkb21pZF90KWRvbWlkOworICAgIGRvbWN0bC51LnNldF9icm9rZW5fcGFnZV9wMm0ucGZuID0g
cGZuOworICAgIHJldCA9IGRvX2RvbWN0bCh4Y2gsICZkb21jdGwpOworCisgICAgcmV0dXJuIHJl
dCA/IC0xIDogMDsKK30KKwogLyogZ2V0IGluZm8gZnJvbSBodm0gZ3Vlc3QgZm9yIHNhdmUgKi8K
IGludCB4Y19kb21haW5faHZtX2dldGNvbnRleHQoeGNfaW50ZXJmYWNlICp4Y2gsCiAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgIHVpbnQzMl90IGRvbWlkLApkaWZmIC1yIGExZDEwNmQxYWVj
OCB0b29scy9saWJ4Yy94Y19kb21haW5fcmVzdG9yZS5jCi0tLSBhL3Rvb2xzL2xpYnhjL3hjX2Rv
bWFpbl9yZXN0b3JlLmMJV2VkIFNlcCAxOSAwMzozMTozMSAyMDEyICswODAwCisrKyBiL3Rvb2xz
L2xpYnhjL3hjX2RvbWFpbl9yZXN0b3JlLmMJV2VkIFNlcCAxOSAwNDoyMjoyNiAyMDEyICswODAw
CkBAIC05NjIsOSArOTYyLDE1IEBACiAKICAgICBjb3VudHBhZ2VzID0gY291bnQ7CiAgICAgZm9y
IChpID0gb2xkY291bnQ7IGkgPCBidWYtPm5yX3BhZ2VzOyArK2kpCi0gICAgICAgIGlmICgoYnVm
LT5wZm5fdHlwZXNbaV0gJiBYRU5fRE9NQ1RMX1BGSU5GT19MVEFCX01BU0spID09IFhFTl9ET01D
VExfUEZJTkZPX1hUQUIKLSAgICAgICAgICAgIHx8KGJ1Zi0+cGZuX3R5cGVzW2ldICYgWEVOX0RP
TUNUTF9QRklORk9fTFRBQl9NQVNLKSA9PSBYRU5fRE9NQ1RMX1BGSU5GT19YQUxMT0MpCisgICAg
eworICAgICAgICB1bnNpZ25lZCBsb25nIHBhZ2V0eXBlOworCisgICAgICAgIHBhZ2V0eXBlID0g
YnVmLT5wZm5fdHlwZXNbaV0gJiBYRU5fRE9NQ1RMX1BGSU5GT19MVEFCX01BU0s7CisgICAgICAg
IGlmICggcGFnZXR5cGUgPT0gWEVOX0RPTUNUTF9QRklORk9fWFRBQiB8fAorICAgICAgICAgICAg
IHBhZ2V0eXBlID09IFhFTl9ET01DVExfUEZJTkZPX0JST0tFTiB8fAorICAgICAgICAgICAgIHBh
Z2V0eXBlID09IFhFTl9ET01DVExfUEZJTkZPX1hBTExPQyApCiAgICAgICAgICAgICAtLWNvdW50
cGFnZXM7CisgICAgfQogCiAgICAgaWYgKCFjb3VudHBhZ2VzKQogICAgICAgICByZXR1cm4gY291
bnQ7CkBAIC0xMjAwLDYgKzEyMDYsMTcgQEAKICAgICAgICAgICAgIC8qIGEgYm9ndXMvdW5tYXBw
ZWQvYWxsb2NhdGUtb25seSBwYWdlOiBza2lwIGl0ICovCiAgICAgICAgICAgICBjb250aW51ZTsK
IAorICAgICAgICBpZiAoIHBhZ2V0eXBlID09IFhFTl9ET01DVExfUEZJTkZPX0JST0tFTiApCisg
ICAgICAgIHsKKyAgICAgICAgICAgIGlmICggeGNfc2V0X2Jyb2tlbl9wYWdlX3AybSh4Y2gsIGRv
bSwgcGZuKSApCisgICAgICAgICAgICB7CisgICAgICAgICAgICAgICAgRVJST1IoIlNldCBwMm0g
Zm9yIGJyb2tlbiBwYWdlIGZhaWwsICIKKyAgICAgICAgICAgICAgICAgICAgICAiZG9tPSVkLCBw
Zm49JWx4XG4iLCBkb20sIHBmbik7CisgICAgICAgICAgICAgICAgZ290byBlcnJfbWFwcGVkOwor
ICAgICAgICAgICAgfQorICAgICAgICAgICAgY29udGludWU7CisgICAgICAgIH0KKwogICAgICAg
ICBpZiAocGZuX2VycltpXSkKICAgICAgICAgewogICAgICAgICAgICAgRVJST1IoInVuZXhwZWN0
ZWQgUEZOIG1hcHBpbmcgZmFpbHVyZSBwZm4gJWx4IG1hcF9tZm4gJWx4IHAybV9tZm4gJWx4IiwK
ZGlmZiAtciBhMWQxMDZkMWFlYzggdG9vbHMvbGlieGMveGNfZG9tYWluX3NhdmUuYwotLS0gYS90
b29scy9saWJ4Yy94Y19kb21haW5fc2F2ZS5jCVdlZCBTZXAgMTkgMDM6MzE6MzEgMjAxMiArMDgw
MAorKysgYi90b29scy9saWJ4Yy94Y19kb21haW5fc2F2ZS5jCVdlZCBTZXAgMTkgMDQ6MjI6MjYg
MjAxMiArMDgwMApAQCAtMTI4NSw2ICsxMjg1LDEzIEBACiAgICAgICAgICAgICAgICAgaWYgKCAh
aHZtICkKICAgICAgICAgICAgICAgICAgICAgZ21mbiA9IHBmbl90b19tZm4oZ21mbik7CiAKKyAg
ICAgICAgICAgICAgICBpZiAoIHBmbl90eXBlW2pdID09IFhFTl9ET01DVExfUEZJTkZPX0JST0tF
TiApCisgICAgICAgICAgICAgICAgeworICAgICAgICAgICAgICAgICAgICBwZm5fdHlwZVtqXSB8
PSBwZm5fYmF0Y2hbal07CisgICAgICAgICAgICAgICAgICAgICsrcnVuOworICAgICAgICAgICAg
ICAgICAgICBjb250aW51ZTsKKyAgICAgICAgICAgICAgICB9CisKICAgICAgICAgICAgICAgICBp
ZiAoIHBmbl9lcnJbal0gKQogICAgICAgICAgICAgICAgIHsKICAgICAgICAgICAgICAgICAgICAg
aWYgKCBwZm5fdHlwZVtqXSA9PSBYRU5fRE9NQ1RMX1BGSU5GT19YVEFCICkKQEAgLTEzNzksOCAr
MTM4NiwxMiBAQAogICAgICAgICAgICAgICAgICAgICB9CiAgICAgICAgICAgICAgICAgfQogCi0g
ICAgICAgICAgICAgICAgLyogc2tpcCBwYWdlcyB0aGF0IGFyZW4ndCBwcmVzZW50IG9yIGFyZSBh
bGxvYy1vbmx5ICovCisgICAgICAgICAgICAgICAgLyoKKyAgICAgICAgICAgICAgICAgKiBza2lw
IHBhZ2VzIHRoYXQgYXJlbid0IHByZXNlbnQsCisgICAgICAgICAgICAgICAgICogb3IgYXJlIGJy
b2tlbiwgb3IgYXJlIGFsbG9jLW9ubHkKKyAgICAgICAgICAgICAgICAgKi8KICAgICAgICAgICAg
ICAgICBpZiAoIHBhZ2V0eXBlID09IFhFTl9ET01DVExfUEZJTkZPX1hUQUIKKyAgICAgICAgICAg
ICAgICAgICAgfHwgcGFnZXR5cGUgPT0gWEVOX0RPTUNUTF9QRklORk9fQlJPS0VOCiAgICAgICAg
ICAgICAgICAgICAgIHx8IHBhZ2V0eXBlID09IFhFTl9ET01DVExfUEZJTkZPX1hBTExPQyApCiAg
ICAgICAgICAgICAgICAgICAgIGNvbnRpbnVlOwogCmRpZmYgLXIgYTFkMTA2ZDFhZWM4IHRvb2xz
L2xpYnhjL3hlbmN0cmwuaAotLS0gYS90b29scy9saWJ4Yy94ZW5jdHJsLmgJV2VkIFNlcCAxOSAw
MzozMTozMSAyMDEyICswODAwCisrKyBiL3Rvb2xzL2xpYnhjL3hlbmN0cmwuaAlXZWQgU2VwIDE5
IDA0OjIyOjI2IDIwMTIgKzA4MDAKQEAgLTU5MSw2ICs1OTEsMTcgQEAKICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICBzaWduZWQgY2hhciAqdm1jZV93aGlsZV9tb25pdG9yKTsKIAogLyoq
CisgKiBUaGlzIGZ1bmN0aW9uIHNldCBwMm0gZm9yIGJyb2tlbiBwYWdlCisgKiAmcGFybSB4Y2gg
YSBoYW5kbGUgdG8gYW4gb3BlbiBoeXBlcnZpc29yIGludGVyZmFjZQorICogQHBhcm0gZG9taWQg
dGhlIGRvbWFpbiBpZCB3aGljaCBicm9rZW4gcGFnZSBiZWxvbmcgdG8KKyAqIEBwYXJtIHBmbiB0
aGUgcGZuIG51bWJlciBvZiB0aGUgYnJva2VuIHBhZ2UKKyAqIEByZXR1cm4gMCBvbiBzdWNjZXNz
LCAtMSBvbiBmYWlsdXJlCisgKi8KK2ludCB4Y19zZXRfYnJva2VuX3BhZ2VfcDJtKHhjX2ludGVy
ZmFjZSAqeGNoLAorICAgICAgICAgICAgICAgICAgICAgICAgICAgdWludDMyX3QgZG9taWQsCisg
ICAgICAgICAgICAgICAgICAgICAgICAgICB1bnNpZ25lZCBsb25nIHBmbik7CisKKy8qKgogICog
VGhpcyBmdW5jdGlvbiByZXR1cm5zIGluZm9ybWF0aW9uIGFib3V0IHRoZSBjb250ZXh0IG9mIGEg
aHZtIGRvbWFpbgogICogQHBhcm0geGNoIGEgaGFuZGxlIHRvIGFuIG9wZW4gaHlwZXJ2aXNvciBp
bnRlcmZhY2UKICAqIEBwYXJtIGRvbWlkIHRoZSBkb21haW4gdG8gZ2V0IGluZm9ybWF0aW9uIGZy
b20KZGlmZiAtciBhMWQxMDZkMWFlYzggeGVuL2FyY2gveDg2L2RvbWN0bC5jCi0tLSBhL3hlbi9h
cmNoL3g4Ni9kb21jdGwuYwlXZWQgU2VwIDE5IDAzOjMxOjMxIDIwMTIgKzA4MDAKKysrIGIveGVu
L2FyY2gveDg2L2RvbWN0bC5jCVdlZCBTZXAgMTkgMDQ6MjI6MjYgMjAxMiArMDgwMApAQCAtMjA5
LDEyICsyMDksMTggQEAKICAgICAgICAgICAgICAgICBmb3IgKCBqID0gMDsgaiA8IGs7IGorKyAp
CiAgICAgICAgICAgICAgICAgewogICAgICAgICAgICAgICAgICAgICB1bnNpZ25lZCBsb25nIHR5
cGUgPSAwOworICAgICAgICAgICAgICAgICAgICBwMm1fdHlwZV90IHQ7CiAKLSAgICAgICAgICAg
ICAgICAgICAgcGFnZSA9IGdldF9wYWdlX2Zyb21fZ2ZuKGQsIGFycltqXSwgTlVMTCwgUDJNX0FM
TE9DKTsKKyAgICAgICAgICAgICAgICAgICAgcGFnZSA9IGdldF9wYWdlX2Zyb21fZ2ZuKGQsIGFy
cltqXSwgJnQsIFAyTV9BTExPQyk7CiAKICAgICAgICAgICAgICAgICAgICAgaWYgKCB1bmxpa2Vs
eSghcGFnZSkgfHwKICAgICAgICAgICAgICAgICAgICAgICAgICB1bmxpa2VseShpc194ZW5faGVh
cF9wYWdlKHBhZ2UpKSApCi0gICAgICAgICAgICAgICAgICAgICAgICB0eXBlID0gWEVOX0RPTUNU
TF9QRklORk9fWFRBQjsKKyAgICAgICAgICAgICAgICAgICAgeworICAgICAgICAgICAgICAgICAg
ICAgICAgaWYgKCBwMm1faXNfYnJva2VuKHQpICkKKyAgICAgICAgICAgICAgICAgICAgICAgICAg
ICB0eXBlID0gWEVOX0RPTUNUTF9QRklORk9fQlJPS0VOOworICAgICAgICAgICAgICAgICAgICAg
ICAgZWxzZQorICAgICAgICAgICAgICAgICAgICAgICAgICAgIHR5cGUgPSBYRU5fRE9NQ1RMX1BG
SU5GT19YVEFCOworICAgICAgICAgICAgICAgICAgICB9CiAgICAgICAgICAgICAgICAgICAgIGVs
c2UKICAgICAgICAgICAgICAgICAgICAgewogICAgICAgICAgICAgICAgICAgICAgICAgc3dpdGNo
KCBwYWdlLT51LmludXNlLnR5cGVfaW5mbyAmIFBHVF90eXBlX21hc2sgKQpAQCAtMjM1LDYgKzI0
MSw5IEBACiAKICAgICAgICAgICAgICAgICAgICAgICAgIGlmICggcGFnZS0+dS5pbnVzZS50eXBl
X2luZm8gJiBQR1RfcGlubmVkICkKICAgICAgICAgICAgICAgICAgICAgICAgICAgICB0eXBlIHw9
IFhFTl9ET01DVExfUEZJTkZPX0xQSU5UQUI7CisKKyAgICAgICAgICAgICAgICAgICAgICAgIGlm
ICggcGFnZS0+Y291bnRfaW5mbyAmIFBHQ19icm9rZW4gKQorICAgICAgICAgICAgICAgICAgICAg
ICAgICAgIHR5cGUgPSBYRU5fRE9NQ1RMX1BGSU5GT19CUk9LRU47CiAgICAgICAgICAgICAgICAg
ICAgIH0KIAogICAgICAgICAgICAgICAgICAgICBpZiAoIHBhZ2UgKQpAQCAtMTU0OCw2ICsxNTU3
LDI4IEBACiAgICAgfQogICAgIGJyZWFrOwogCisgICAgY2FzZSBYRU5fRE9NQ1RMX3NldF9icm9r
ZW5fcGFnZV9wMm06CisgICAgeworICAgICAgICBzdHJ1Y3QgZG9tYWluICpkOworICAgICAgICBw
Mm1fdHlwZV90IHB0OworICAgICAgICB1bnNpZ25lZCBsb25nIHBmbjsKKworICAgICAgICBkID0g
cmN1X2xvY2tfZG9tYWluX2J5X2lkKGRvbWN0bC0+ZG9tYWluKTsKKyAgICAgICAgaWYgKCBkICE9
IE5VTEwgKQorICAgICAgICB7CisgICAgICAgICAgICBwZm4gPSBkb21jdGwtPnUuc2V0X2Jyb2tl
bl9wYWdlX3AybS5wZm47CisKKyAgICAgICAgICAgIGdldF9nZm5fcXVlcnkoZCwgcGZuLCAmcHQp
OworICAgICAgICAgICAgcDJtX2NoYW5nZV90eXBlKGQsIHBmbiwgcHQsIHAybV9yYW1fYnJva2Vu
KTsKKyAgICAgICAgICAgIHB1dF9nZm4oZCwgcGZuKTsKKworICAgICAgICAgICAgcmN1X3VubG9j
a19kb21haW4oZCk7CisgICAgICAgIH0KKyAgICAgICAgZWxzZQorICAgICAgICAgICAgcmV0ID0g
LUVTUkNIOworICAgIH0KKyAgICBicmVhazsKKwogICAgIGRlZmF1bHQ6CiAgICAgICAgIHJldCA9
IGlvbW11X2RvX2RvbWN0bChkb21jdGwsIHVfZG9tY3RsKTsKICAgICAgICAgYnJlYWs7CmRpZmYg
LXIgYTFkMTA2ZDFhZWM4IHhlbi9pbmNsdWRlL3B1YmxpYy9kb21jdGwuaAotLS0gYS94ZW4vaW5j
bHVkZS9wdWJsaWMvZG9tY3RsLmgJV2VkIFNlcCAxOSAwMzozMTozMSAyMDEyICswODAwCisrKyBi
L3hlbi9pbmNsdWRlL3B1YmxpYy9kb21jdGwuaAlXZWQgU2VwIDE5IDA0OjIyOjI2IDIwMTIgKzA4
MDAKQEAgLTEzNiw2ICsxMzYsNyBAQAogI2RlZmluZSBYRU5fRE9NQ1RMX1BGSU5GT19MUElOVEFC
ICgweDFVPDwzMSkKICNkZWZpbmUgWEVOX0RPTUNUTF9QRklORk9fWFRBQiAgICAoMHhmVTw8Mjgp
IC8qIGludmFsaWQgcGFnZSAqLwogI2RlZmluZSBYRU5fRE9NQ1RMX1BGSU5GT19YQUxMT0MgICgw
eGVVPDwyOCkgLyogYWxsb2NhdGUtb25seSBwYWdlICovCisjZGVmaW5lIFhFTl9ET01DVExfUEZJ
TkZPX0JST0tFTiAgKDB4ZFU8PDI4KSAvKiBicm9rZW4gcGFnZSAqLwogI2RlZmluZSBYRU5fRE9N
Q1RMX1BGSU5GT19QQUdFRFRBQiAoMHg4VTw8MjgpCiAjZGVmaW5lIFhFTl9ET01DVExfUEZJTkZP
X0xUQUJfTUFTSyAoMHhmVTw8MjgpCiAKQEAgLTgzNCw2ICs4MzUsMTIgQEAKIHR5cGVkZWYgc3Ry
dWN0IHhlbl9kb21jdGxfdm1jZV9tb25pdG9yIHhlbl9kb21jdGxfdm1jZV9tb25pdG9yX3Q7CiBE
RUZJTkVfWEVOX0dVRVNUX0hBTkRMRSh4ZW5fZG9tY3RsX3ZtY2VfbW9uaXRvcl90KTsKIAorc3Ry
dWN0IHhlbl9kb21jdGxfc2V0X2Jyb2tlbl9wYWdlX3AybSB7CisgICAgdWludDY0X3QgcGZuOwor
fTsKK3R5cGVkZWYgc3RydWN0IHhlbl9kb21jdGxfc2V0X2Jyb2tlbl9wYWdlX3AybSB4ZW5fZG9t
Y3RsX3NldF9icm9rZW5fcGFnZV9wMm1fdDsKK0RFRklORV9YRU5fR1VFU1RfSEFORExFKHhlbl9k
b21jdGxfc2V0X2Jyb2tlbl9wYWdlX3AybV90KTsKKwogc3RydWN0IHhlbl9kb21jdGwgewogICAg
IHVpbnQzMl90IGNtZDsKICNkZWZpbmUgWEVOX0RPTUNUTF9jcmVhdGVkb21haW4gICAgICAgICAg
ICAgICAgICAgMQpAQCAtOTAxLDYgKzkwOCw3IEBACiAjZGVmaW5lIFhFTl9ET01DVExfc2V0X3Zp
cnFfaGFuZGxlciAgICAgICAgICAgICAgNjYKICNkZWZpbmUgWEVOX0RPTUNUTF92bWNlX21vbml0
b3Jfc3RhcnQgICAgICAgICAgICA2NwogI2RlZmluZSBYRU5fRE9NQ1RMX3ZtY2VfbW9uaXRvcl9l
bmQgICAgICAgICAgICAgIDY4CisjZGVmaW5lIFhFTl9ET01DVExfc2V0X2Jyb2tlbl9wYWdlX3Ay
bSAgICAgICAgICAgNjkKICNkZWZpbmUgWEVOX0RPTUNUTF9nZGJzeF9ndWVzdG1lbWlvICAgICAg
ICAgICAgMTAwMAogI2RlZmluZSBYRU5fRE9NQ1RMX2dkYnN4X3BhdXNldmNwdSAgICAgICAgICAg
ICAxMDAxCiAjZGVmaW5lIFhFTl9ET01DVExfZ2Ric3hfdW5wYXVzZXZjcHUgICAgICAgICAgIDEw
MDIKQEAgLTk1Nyw2ICs5NjUsNyBAQAogICAgICAgICBzdHJ1Y3QgeGVuX2RvbWN0bF9zZXRfdmly
cV9oYW5kbGVyICBzZXRfdmlycV9oYW5kbGVyOwogICAgICAgICBzdHJ1Y3QgeGVuX2RvbWN0bF92
bWNlX21vbml0b3IgICAgICB2bWNlX21vbml0b3I7CiAgICAgICAgIHN0cnVjdCB4ZW5fZG9tY3Rs
X2dkYnN4X21lbWlvICAgICAgIGdkYnN4X2d1ZXN0X21lbWlvOworICAgICAgICBzdHJ1Y3QgeGVu
X2RvbWN0bF9zZXRfYnJva2VuX3BhZ2VfcDJtIHNldF9icm9rZW5fcGFnZV9wMm07CiAgICAgICAg
IHN0cnVjdCB4ZW5fZG9tY3RsX2dkYnN4X3BhdXNldW5wX3ZjcHUgZ2Ric3hfcGF1c2V1bnBfdmNw
dTsKICAgICAgICAgc3RydWN0IHhlbl9kb21jdGxfZ2Ric3hfZG9tc3RhdHVzICAgZ2Ric3hfZG9t
c3RhdHVzOwogICAgICAgICB1aW50OF90ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBwYWRb
MTI4XTsK

--_002_DE8DF0795D48FD4CA783C40EC82923353305EDSHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 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_DE8DF0795D48FD4CA783C40EC82923353305EDSHSMSX101ccrcorpi_--


From xen-devel-bounces@lists.xen.org Wed Sep 19 08:36:48 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Sep 2012 08:36:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TEFlp-0005bN-JF; Wed, 19 Sep 2012 08:36:33 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <imperiaonline4@gmail.com>) id 1TEELF-0002nY-NM
	for xen-devel@lists.xen.org; Wed, 19 Sep 2012 07:05:01 +0000
Received: from [85.158.137.99:6628] by server-8.bemta-3.messagelabs.com id
	07/32-24700-C9E69505; Wed, 19 Sep 2012 07:05:00 +0000
X-Env-Sender: imperiaonline4@gmail.com
X-Msg-Ref: server-12.tower-217.messagelabs.com!1348038298!15120575!1
X-Originating-IP: [209.85.219.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25592 invoked from network); 19 Sep 2012 07:05:00 -0000
Received: from mail-oa0-f45.google.com (HELO mail-oa0-f45.google.com)
	(209.85.219.45)
	by server-12.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Sep 2012 07:05:00 -0000
Received: by oagn12 with SMTP id n12so900241oag.32
	for <xen-devel@lists.xen.org>; Wed, 19 Sep 2012 00:04: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=lNXkm6ATrCBijm7fsc0HhObA+nBIOqFm3zPhljg0t80=;
	b=RgFB5w1205Jq60quVez6m3vReZCXEZtNKR5U8lnTY07/d5teZw8N09VOfXYumCsT17
	BXKusn/3G8Uj+RUCgOVVqrXPm2qtdk5OBXR3kS7rKBPv4TjFuhMNdasWGzFGwf2o0k9e
	b/1m5Bvch5bYQXZqweihQ+vFJoyuJtLGUs1+gUe6JmihMDYQALbZiIMv13HNaYG2xIih
	gRDcoyLMkNAUH/ZR85qv3BvZqm0Gsa9SoibCDs9SXZE1hBIWUpqq5M0PsxW0JlS7G/Mv
	GrdUISBQvA8CC3ZN7rkOO31d33NZGbRgdEBoPsh8TzvibkcGRvj+fBy0XyLU6gmyF6tO
	dFRg==
MIME-Version: 1.0
Received: by 10.60.30.136 with SMTP id s8mr2415598oeh.22.1348038298513; Wed,
	19 Sep 2012 00:04:58 -0700 (PDT)
Received: by 10.60.58.234 with HTTP; Wed, 19 Sep 2012 00:04:58 -0700 (PDT)
Date: Wed, 19 Sep 2012 09:04:58 +0200
Message-ID: <CAAREfm1Fxm+b6KBJ1qk8KpTb4JGC_3H9uZpHiP_n50ibsnZrOA@mail.gmail.com>
From: Dariusz Krempa <imperiaonline4@gmail.com>
To: xen-devel@lists.xen.org
X-Mailman-Approved-At: Wed, 19 Sep 2012 08:36:32 +0000
Subject: [Xen-devel] [TESTDAY] Test report
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi.
I'm newbie with Xen and event with linux, but almost 2 weeks i spend
on installation both on my box (thanks to Zhang Enming for his
tutorials) and finally i did it. VGA passthrough is possible on P8H67
even if in bios isn't option to turn on virtualisation.

* Hardware:
- CPU: i5 2400
- GTX 560 DirectCUII Top - drivers 275.50
- P8H67 with bios 3603
- 4GB ram :(

*Software:
- Ubuntu 12.04
- Dom0 kernel - 3.3-rc7
- DomU - windows xp sp3 - x86 (HVM pciback)
- Xen 4.2-rc4 with patch from David Gis

*Functionality
- Asus P8H67 + Asus GTX560OC = VGA passthrough

*Comments
In this moment i don't know that patch from David Gis is needed but i
used it. Dom0 , DomU Windows XP sp3. I'm newbie but i will try to
answer for questions about my configuration. Any suggestions will be
appreciated.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 19 08:36:48 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Sep 2012 08:36:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TEFlp-0005bN-JF; Wed, 19 Sep 2012 08:36:33 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <imperiaonline4@gmail.com>) id 1TEELF-0002nY-NM
	for xen-devel@lists.xen.org; Wed, 19 Sep 2012 07:05:01 +0000
Received: from [85.158.137.99:6628] by server-8.bemta-3.messagelabs.com id
	07/32-24700-C9E69505; Wed, 19 Sep 2012 07:05:00 +0000
X-Env-Sender: imperiaonline4@gmail.com
X-Msg-Ref: server-12.tower-217.messagelabs.com!1348038298!15120575!1
X-Originating-IP: [209.85.219.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25592 invoked from network); 19 Sep 2012 07:05:00 -0000
Received: from mail-oa0-f45.google.com (HELO mail-oa0-f45.google.com)
	(209.85.219.45)
	by server-12.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Sep 2012 07:05:00 -0000
Received: by oagn12 with SMTP id n12so900241oag.32
	for <xen-devel@lists.xen.org>; Wed, 19 Sep 2012 00:04: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=lNXkm6ATrCBijm7fsc0HhObA+nBIOqFm3zPhljg0t80=;
	b=RgFB5w1205Jq60quVez6m3vReZCXEZtNKR5U8lnTY07/d5teZw8N09VOfXYumCsT17
	BXKusn/3G8Uj+RUCgOVVqrXPm2qtdk5OBXR3kS7rKBPv4TjFuhMNdasWGzFGwf2o0k9e
	b/1m5Bvch5bYQXZqweihQ+vFJoyuJtLGUs1+gUe6JmihMDYQALbZiIMv13HNaYG2xIih
	gRDcoyLMkNAUH/ZR85qv3BvZqm0Gsa9SoibCDs9SXZE1hBIWUpqq5M0PsxW0JlS7G/Mv
	GrdUISBQvA8CC3ZN7rkOO31d33NZGbRgdEBoPsh8TzvibkcGRvj+fBy0XyLU6gmyF6tO
	dFRg==
MIME-Version: 1.0
Received: by 10.60.30.136 with SMTP id s8mr2415598oeh.22.1348038298513; Wed,
	19 Sep 2012 00:04:58 -0700 (PDT)
Received: by 10.60.58.234 with HTTP; Wed, 19 Sep 2012 00:04:58 -0700 (PDT)
Date: Wed, 19 Sep 2012 09:04:58 +0200
Message-ID: <CAAREfm1Fxm+b6KBJ1qk8KpTb4JGC_3H9uZpHiP_n50ibsnZrOA@mail.gmail.com>
From: Dariusz Krempa <imperiaonline4@gmail.com>
To: xen-devel@lists.xen.org
X-Mailman-Approved-At: Wed, 19 Sep 2012 08:36:32 +0000
Subject: [Xen-devel] [TESTDAY] Test report
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi.
I'm newbie with Xen and event with linux, but almost 2 weeks i spend
on installation both on my box (thanks to Zhang Enming for his
tutorials) and finally i did it. VGA passthrough is possible on P8H67
even if in bios isn't option to turn on virtualisation.

* Hardware:
- CPU: i5 2400
- GTX 560 DirectCUII Top - drivers 275.50
- P8H67 with bios 3603
- 4GB ram :(

*Software:
- Ubuntu 12.04
- Dom0 kernel - 3.3-rc7
- DomU - windows xp sp3 - x86 (HVM pciback)
- Xen 4.2-rc4 with patch from David Gis

*Functionality
- Asus P8H67 + Asus GTX560OC = VGA passthrough

*Comments
In this moment i don't know that patch from David Gis is needed but i
used it. Dom0 , DomU Windows XP sp3. I'm newbie but i will try to
answer for questions about my configuration. Any suggestions will be
appreciated.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 19 08:53:53 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Sep 2012 08:53: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 1TEG2M-00068j-PW; Wed, 19 Sep 2012 08:53:38 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <qianhu2011@gmail.com>) id 1TEG2L-00068d-7B
	for xen-devel@lists.xen.org; Wed, 19 Sep 2012 08:53:37 +0000
Received: from [85.158.137.99:44228] by server-3.bemta-3.messagelabs.com id
	BC/E9-21322-01889505; Wed, 19 Sep 2012 08:53:36 +0000
X-Env-Sender: qianhu2011@gmail.com
X-Msg-Ref: server-14.tower-217.messagelabs.com!1348044814!18245921!1
X-Originating-IP: [209.85.220.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-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12128 invoked from network); 19 Sep 2012 08:53:35 -0000
Received: from mail-vc0-f173.google.com (HELO mail-vc0-f173.google.com)
	(209.85.220.173)
	by server-14.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Sep 2012 08:53:35 -0000
Received: by vcbfl15 with SMTP id fl15so1049630vcb.32
	for <xen-devel@lists.xen.org>; Wed, 19 Sep 2012 01:53: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=H+8uIc78YIk/8Z5+5N1ZoT/N7MGCtF5WHaj7z7ZJOPY=;
	b=IxIwy/+xz+EFLPRZmSSAOox2EHWfJjsEyCbmhmoZBf2Ni9vdRNytolUski+6q2ldwV
	SHQqhxHoo26jGnSqtAz/ZoDeC+DldrlEyuxGXe+xUuIGPo/kiQc+yaK0CyoTpQWlibWg
	x4jqOmFLy46plUIdyv9T0t4vHPZU+nrWK/xF66f4iOh4zdgfsrp35BMn/+VboxGZ7bn+
	MOH/CUGMKKxKGvLvqVKXdmbZqWnR1ar/PyNT70qO/8obMvHyercYp4vvX9tJLu8G5j07
	QOySeg4r9+OPtsaUZkmO7jBUlfM2BKytDaCisyU2/Y+o3vqfoK5LEMi3JmcjdiOx5QkC
	jpLQ==
MIME-Version: 1.0
Received: by 10.52.67.240 with SMTP id q16mr1284880vdt.45.1348044814011; Wed,
	19 Sep 2012 01:53:34 -0700 (PDT)
Received: by 10.58.249.236 with HTTP; Wed, 19 Sep 2012 01:53:33 -0700 (PDT)
Date: Wed, 19 Sep 2012 16:53:33 +0800
Message-ID: <CALCpXpBnAQr=jk5LbZnQPAuJHrKEAL0ELcZ3L2BRQRUfGbUvAw@mail.gmail.com>
From: Qian Hu <qianhu2011@gmail.com>
To: xen-devel@lists.xen.org
Subject: [Xen-devel] usbpassthrough of xen-4.1.2
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============6861158150346473640=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============6861158150346473640==
Content-Type: multipart/alternative; boundary=20cf307d029447cdd804ca0a24ee

--20cf307d029447cdd804ca0a24ee
Content-Type: text/plain; charset=ISO-8859-1

Hi, everyone!

I am working on the USB passthrough of Xen-4.1.2. My host OS  is Fedora 14
and the guest OS is win7.

According to the wiki page(http://wiki.xen.org/wiki/Xen_USB_Passthrough),

xen supports passthrough of usb device from dom0 to guests. I have tried
the Xen HVM guest qemu-dm usb1.1 emulation,

by specifying "usb = 1" and "usbdevice = host:xxxx:yyyy". But, the mouse
could work, the keyboard and usb storage failed.

If I change the guest OS to winXP, it is surprising that only the usb
storage can be detected in the guest.

I have also tried the PVUSB, it didn't work either.

I am confused and don't know how to resolve it.  Could anyone help me?

Great thanks!

huqian

--20cf307d029447cdd804ca0a24ee
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi, everyone!<div><br></div><div>I am working on the USB passthrough of=A0X=
en-4.1.2. My host OS =A0is Fedora 14 and the guest OS is win7.</div><div><b=
r></div><div>According to the wiki page(<a href=3D"http://wiki.xen.org/wiki=
/Xen_USB_Passthrough">http://wiki.xen.org/wiki/Xen_USB_Passthrough</a>),=A0=
</div>
<div><br></div><div>xen supports passthrough of usb device from dom0 to gue=
sts. I have tried the Xen HVM guest qemu-dm usb1.1 emulation,</div><div><br=
></div><div>by specifying &quot;usb =3D 1&quot; and &quot;usbdevice =3D hos=
t:xxxx:yyyy&quot;. But, the mouse could work, the keyboard and usb storage =
failed.</div>
<div><br></div><div>If I change the guest OS to winXP, it is surprising tha=
t only the usb storage can be detected in the guest.=A0</div><div><br></div=
><div>I have also tried the PVUSB, it didn&#39;t work either.</div><div><br=
>
</div><div>I am confused and don&#39;t know how to resolve it. =A0Could any=
one help me?</div><div><br></div><div>Great thanks!</div><div><br></div><di=
v>huqian</div><div><br></div>

--20cf307d029447cdd804ca0a24ee--


--===============6861158150346473640==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============6861158150346473640==--


From xen-devel-bounces@lists.xen.org Wed Sep 19 08:53:53 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Sep 2012 08:53: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 1TEG2M-00068j-PW; Wed, 19 Sep 2012 08:53:38 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <qianhu2011@gmail.com>) id 1TEG2L-00068d-7B
	for xen-devel@lists.xen.org; Wed, 19 Sep 2012 08:53:37 +0000
Received: from [85.158.137.99:44228] by server-3.bemta-3.messagelabs.com id
	BC/E9-21322-01889505; Wed, 19 Sep 2012 08:53:36 +0000
X-Env-Sender: qianhu2011@gmail.com
X-Msg-Ref: server-14.tower-217.messagelabs.com!1348044814!18245921!1
X-Originating-IP: [209.85.220.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-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12128 invoked from network); 19 Sep 2012 08:53:35 -0000
Received: from mail-vc0-f173.google.com (HELO mail-vc0-f173.google.com)
	(209.85.220.173)
	by server-14.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Sep 2012 08:53:35 -0000
Received: by vcbfl15 with SMTP id fl15so1049630vcb.32
	for <xen-devel@lists.xen.org>; Wed, 19 Sep 2012 01:53: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=H+8uIc78YIk/8Z5+5N1ZoT/N7MGCtF5WHaj7z7ZJOPY=;
	b=IxIwy/+xz+EFLPRZmSSAOox2EHWfJjsEyCbmhmoZBf2Ni9vdRNytolUski+6q2ldwV
	SHQqhxHoo26jGnSqtAz/ZoDeC+DldrlEyuxGXe+xUuIGPo/kiQc+yaK0CyoTpQWlibWg
	x4jqOmFLy46plUIdyv9T0t4vHPZU+nrWK/xF66f4iOh4zdgfsrp35BMn/+VboxGZ7bn+
	MOH/CUGMKKxKGvLvqVKXdmbZqWnR1ar/PyNT70qO/8obMvHyercYp4vvX9tJLu8G5j07
	QOySeg4r9+OPtsaUZkmO7jBUlfM2BKytDaCisyU2/Y+o3vqfoK5LEMi3JmcjdiOx5QkC
	jpLQ==
MIME-Version: 1.0
Received: by 10.52.67.240 with SMTP id q16mr1284880vdt.45.1348044814011; Wed,
	19 Sep 2012 01:53:34 -0700 (PDT)
Received: by 10.58.249.236 with HTTP; Wed, 19 Sep 2012 01:53:33 -0700 (PDT)
Date: Wed, 19 Sep 2012 16:53:33 +0800
Message-ID: <CALCpXpBnAQr=jk5LbZnQPAuJHrKEAL0ELcZ3L2BRQRUfGbUvAw@mail.gmail.com>
From: Qian Hu <qianhu2011@gmail.com>
To: xen-devel@lists.xen.org
Subject: [Xen-devel] usbpassthrough of xen-4.1.2
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============6861158150346473640=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============6861158150346473640==
Content-Type: multipart/alternative; boundary=20cf307d029447cdd804ca0a24ee

--20cf307d029447cdd804ca0a24ee
Content-Type: text/plain; charset=ISO-8859-1

Hi, everyone!

I am working on the USB passthrough of Xen-4.1.2. My host OS  is Fedora 14
and the guest OS is win7.

According to the wiki page(http://wiki.xen.org/wiki/Xen_USB_Passthrough),

xen supports passthrough of usb device from dom0 to guests. I have tried
the Xen HVM guest qemu-dm usb1.1 emulation,

by specifying "usb = 1" and "usbdevice = host:xxxx:yyyy". But, the mouse
could work, the keyboard and usb storage failed.

If I change the guest OS to winXP, it is surprising that only the usb
storage can be detected in the guest.

I have also tried the PVUSB, it didn't work either.

I am confused and don't know how to resolve it.  Could anyone help me?

Great thanks!

huqian

--20cf307d029447cdd804ca0a24ee
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi, everyone!<div><br></div><div>I am working on the USB passthrough of=A0X=
en-4.1.2. My host OS =A0is Fedora 14 and the guest OS is win7.</div><div><b=
r></div><div>According to the wiki page(<a href=3D"http://wiki.xen.org/wiki=
/Xen_USB_Passthrough">http://wiki.xen.org/wiki/Xen_USB_Passthrough</a>),=A0=
</div>
<div><br></div><div>xen supports passthrough of usb device from dom0 to gue=
sts. I have tried the Xen HVM guest qemu-dm usb1.1 emulation,</div><div><br=
></div><div>by specifying &quot;usb =3D 1&quot; and &quot;usbdevice =3D hos=
t:xxxx:yyyy&quot;. But, the mouse could work, the keyboard and usb storage =
failed.</div>
<div><br></div><div>If I change the guest OS to winXP, it is surprising tha=
t only the usb storage can be detected in the guest.=A0</div><div><br></div=
><div>I have also tried the PVUSB, it didn&#39;t work either.</div><div><br=
>
</div><div>I am confused and don&#39;t know how to resolve it. =A0Could any=
one help me?</div><div><br></div><div>Great thanks!</div><div><br></div><di=
v>huqian</div><div><br></div>

--20cf307d029447cdd804ca0a24ee--


--===============6861158150346473640==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============6861158150346473640==--


From xen-devel-bounces@lists.xen.org Wed Sep 19 08:59:11 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Sep 2012 08: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 1TEG7U-0006KZ-N3; Wed, 19 Sep 2012 08:58:56 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1TEG7T-0006KT-QO
	for xen-devel@lists.xen.org; Wed, 19 Sep 2012 08:58:56 +0000
Received: from [85.158.143.99:55122] by server-2.bemta-4.messagelabs.com id
	07/F2-06610-F4989505; Wed, 19 Sep 2012 08:58:55 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1348045134!24517305!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13776 invoked from network); 19 Sep 2012 08:58:54 -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;
	19 Sep 2012 08:58:54 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 19 Sep 2012 09:58:54 +0100
Message-Id: <5059A56C020000780009C430@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 19 Sep 2012 09:58:52 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Keir Fraser" <keir.xen@gmail.com>
References: <5059905E020000780009C394@nat28.tlf.novell.com>
	<CC7F392F.3F20D%keir.xen@gmail.com>
In-Reply-To: <CC7F392F.3F20D%keir.xen@gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] ACPI: move tables.c fully into .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 19.09.12 at 09:56, Keir Fraser <keir.xen@gmail.com> wrote:
> On 19/09/2012 08:29, "Jan Beulich" <JBeulich@suse.com> wrote:
> 
>>>>> On 18.09.12 at 17:42, Keir Fraser <keir.xen@gmail.com> wrote:
>>> On 18/09/2012 16:26, "Jan Beulich" <JBeulich@suse.com> wrote:
>>> 
>>>> The only non-init item was the space reserved for the initial tables,
>>>> but we can as well dynamically allocate that array.
>>>> 
>>>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
>>> 
>>> Really worthwhile, versus having to round up the initial_tables[] allocation
>>> to a whole number of pages?
>> 
>> It was exactly one page in size already.
> 
> Well, still I'm not sure about the style of converting static data to heap
> data, just to be able to mark a whole unit init-only. If everything else is
> already  marked init inside that file already, is there a win?

Yes - there a little of 1k of string literals, and there's no way
(other than making them variables to be able to apply section
attributes) to move them into .init.* - that's the purpose of the
other instances where the same post processing is being applied.

Of course, if you're only against the dynamic allocation, moving
the array elsewhere would be another option (but would require
making the symbol global, whereas here the symbol goes away
altogether from the symbol tables).

Yet another option would be to do the dynamic allocation where
it was actually intended to be done, passing NULL here. The
resizing there isn't being made use of anyway (and wouldn't
work afaict), so we could as well do away with it and replace it
by the simple allocation needed here (or simply fix it,
considering that we might need it at some point).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 19 08:59:11 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Sep 2012 08: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 1TEG7U-0006KZ-N3; Wed, 19 Sep 2012 08:58:56 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1TEG7T-0006KT-QO
	for xen-devel@lists.xen.org; Wed, 19 Sep 2012 08:58:56 +0000
Received: from [85.158.143.99:55122] by server-2.bemta-4.messagelabs.com id
	07/F2-06610-F4989505; Wed, 19 Sep 2012 08:58:55 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1348045134!24517305!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13776 invoked from network); 19 Sep 2012 08:58:54 -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;
	19 Sep 2012 08:58:54 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 19 Sep 2012 09:58:54 +0100
Message-Id: <5059A56C020000780009C430@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 19 Sep 2012 09:58:52 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Keir Fraser" <keir.xen@gmail.com>
References: <5059905E020000780009C394@nat28.tlf.novell.com>
	<CC7F392F.3F20D%keir.xen@gmail.com>
In-Reply-To: <CC7F392F.3F20D%keir.xen@gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] ACPI: move tables.c fully into .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 19.09.12 at 09:56, Keir Fraser <keir.xen@gmail.com> wrote:
> On 19/09/2012 08:29, "Jan Beulich" <JBeulich@suse.com> wrote:
> 
>>>>> On 18.09.12 at 17:42, Keir Fraser <keir.xen@gmail.com> wrote:
>>> On 18/09/2012 16:26, "Jan Beulich" <JBeulich@suse.com> wrote:
>>> 
>>>> The only non-init item was the space reserved for the initial tables,
>>>> but we can as well dynamically allocate that array.
>>>> 
>>>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
>>> 
>>> Really worthwhile, versus having to round up the initial_tables[] allocation
>>> to a whole number of pages?
>> 
>> It was exactly one page in size already.
> 
> Well, still I'm not sure about the style of converting static data to heap
> data, just to be able to mark a whole unit init-only. If everything else is
> already  marked init inside that file already, is there a win?

Yes - there a little of 1k of string literals, and there's no way
(other than making them variables to be able to apply section
attributes) to move them into .init.* - that's the purpose of the
other instances where the same post processing is being applied.

Of course, if you're only against the dynamic allocation, moving
the array elsewhere would be another option (but would require
making the symbol global, whereas here the symbol goes away
altogether from the symbol tables).

Yet another option would be to do the dynamic allocation where
it was actually intended to be done, passing NULL here. The
resizing there isn't being made use of anyway (and wouldn't
work afaict), so we could as well do away with it and replace it
by the simple allocation needed here (or simply fix it,
considering that we might need it at some point).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 19 10:24:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Sep 2012 10:24:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TEHRS-0007F2-Pj; Wed, 19 Sep 2012 10:23:38 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1TEHRR-0007Ex-N3
	for xen-devel@lists.xen.org; Wed, 19 Sep 2012 10:23:37 +0000
Received: from [85.158.139.211:28503] by server-6.bemta-5.messagelabs.com id
	CD/5D-21336-82D99505; Wed, 19 Sep 2012 10:23:36 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-16.tower-206.messagelabs.com!1348050213!19182643!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.3 required=7.0 tests=MAILTO_TO_SPAM_ADDR
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1704 invoked from network); 19 Sep 2012 10:23:33 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-16.tower-206.messagelabs.com with SMTP;
	19 Sep 2012 10:23:33 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 19 Sep 2012 11:23:33 +0100
Message-Id: <5059B944020000780009C453@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 19 Sep 2012 11:23:32 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Navin Patel" <navinjpatel336@gmail.com>
References: <CALEYbrhhLsnx_o2kezp+WbR553iwkHRPO7MQ5Nxi27n-ZovvVA@mail.gmail.com>
	<CC7BDB1E.4BE20%keir@xen.org>
	<CALEYbrjgyeFH2WO5SgL0RyYFQqq1YnLQGFuBn+v-SzTQREGi_A@mail.gmail.com>
In-Reply-To: <CALEYbrjgyeFH2WO5SgL0RyYFQqq1YnLQGFuBn+v-SzTQREGi_A@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Steven Maresca <steve@zentific.com>, Keir Fraser <keir@xen.org>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] 4.2.0-rc4 bug: memory events for CR3 register are
 broken (working in 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="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Pj4+IE9uIDE4LjA5LjEyIGF0IDE2OjMwLCBOYXZpbiBQYXRlbCA8bmF2aW5qcGF0ZWwzMzZAZ21h
aWwuY29tPiB3cm90ZToKPiBLZWlyLAo+IAo+IE9uIFN1biwgU2VwIDE2LCAyMDEyIGF0IDI6Mzgg
UE0sIEtlaXIgRnJhc2VyIDxrZWlyQHhlbi5vcmc+IHdyb3RlOgo+IAo+PiAgS2VlcCBhbiBleWUg
b24geGVuLXVuc3RhYmxlIGFuZCBtYWtlIHN1cmUgdGhlIHBhdGNoLCBvciBlcXVpdmFsZW50LCBn
b2VzCj4+IGluIGluIHRoZSBuZXh0IHdlZWsgb3IgdHdvLiBPbmNlIGl04oCZcyBpbiB5b3UgY2Fu
IHJlcXVlc3QgaXQgYmUgYmFja3BvcnRlZC4KPj4KPj4gIC0tIEtlaXIKPj4KPj4KPj4gT24gMTYv
MDkvMjAxMiAxOTozNSwgIk5hdmluIFBhdGVsIiA8bmF2aW5qcGF0ZWwzMzZAZ21haWwuY29tPiB3
cm90ZToKPj4KPj4gS2VpciBhbmQgU3RldmVuLAo+Pgo+PiBUaGFuayB5b3UgZm9yIHlvdXIgd29y
ay4gVGhlIHByb3Bvc2VkIHBhdGNoIHNvbHZlZCB0aGUgYnVnIQo+Pgo+PiBBZnRlciA0LjIuMCBp
cyBvZmZpY2lhbGx5IHJlbGVhc2VkIHRoaXMgd2VlaywgSSB2ZXJ5IG11Y2ggaG9wZSB0aGF0IHRo
aXMKPj4gcGF0Y2ggaXMgYmFja3BvcnRlZCB0byB0aGUgNC4yLjAgdHJlZS4gU2V2ZXJhbCBkaXN0
cmlidXRpb25zIGxpa2UgRGViaWFuCj4+IGFyZSBhbHJlYWR5IGJ1aWxkaW5nIHVwb24gNC4yLjAg
YW5kIHdpbGwgbm90IHdhaXQgZm9yIDQuMi4xLCBhbmQgd2l0aG91dAo+PiB0aGUgcGF0Y2ggYmVp
bmcgYmFja3BvcnRlZCwgcmVzZWFyY2hlcnMgbGlrZSBtZSB3aWxsIG5vdCBiZSBhYmxlIHRvIHVz
ZSB0aGUKPj4gc3VwcG9ydGVkIFhlbiBmcm9tIHBhY2thZ2UgcmVwb3NpdG9yeS4gIFdlIGNhbiBj
b21waWxlIGZyb20gc291cmNlLCBidXQgaWYKPj4gd2UgaGF2ZSBhIHN1cHBvcnRlZCB2ZXJzaW9u
IGl0IGlzIGJldHRlciBmb3IgZXZlcnlvbmUuIChBbmQgaXQgaXMgc3VjaCBhCj4+IHNpbXBsZSBw
YXRjaCEgKQo+Pgo+PiBJcyB0aGlzIHNvbWV0aGluZyBJIGNhbiByZXF1ZXN0IGluIGZvcm1hbCBt
YW5uZXI/Cj4+Cj4+ICBOb3cgdGhhdCB0aGlzIHBhdGNoIGlzIGluIHhlbi11bnN0YWJsZS5oZywg
SSB3b3VsZCBsaWtlIHRvIHJlcXVlc3QgdGhhdAo+IGl0IGJlIGJhY2twb3J0ZWQgdG8gNC4yLjAg
YXMgd2UgZGlzY3Vzc2VkLgoKSSdsbCB0YWtlIGNhcmUgb2YgdGhpcyBzaG9ydGx5IChhc3N1bWlu
ZyBpdCdzIDI1OTE4OjdhYjg5OWU0NjM0Nwp5b3UncmUgdGFsa2luZyBhYm91dCksIGJ1dCBvYnZp
b3VzbHkgdGhpcyBpcyBvbmx5IGdvaW5nIHRvIGJlIGZvcgo0LjIuMSAoZGVzcGl0ZSB5b3VyIGhv
cGVzL3dpc2hlcyksIGFzIEtlaXIgYWxyZWFkeSBpbmRpY2F0ZWQuCgpKYW4KCl9fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxp
c3QKWGVuLWRldmVsQGxpc3RzLnhlbi5vcmcKaHR0cDovL2xpc3RzLnhlbi5vcmcveGVuLWRldmVs
Cg==

From xen-devel-bounces@lists.xen.org Wed Sep 19 10:24:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Sep 2012 10:24:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TEHRS-0007F2-Pj; Wed, 19 Sep 2012 10:23:38 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1TEHRR-0007Ex-N3
	for xen-devel@lists.xen.org; Wed, 19 Sep 2012 10:23:37 +0000
Received: from [85.158.139.211:28503] by server-6.bemta-5.messagelabs.com id
	CD/5D-21336-82D99505; Wed, 19 Sep 2012 10:23:36 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-16.tower-206.messagelabs.com!1348050213!19182643!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.3 required=7.0 tests=MAILTO_TO_SPAM_ADDR
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1704 invoked from network); 19 Sep 2012 10:23:33 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-16.tower-206.messagelabs.com with SMTP;
	19 Sep 2012 10:23:33 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 19 Sep 2012 11:23:33 +0100
Message-Id: <5059B944020000780009C453@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 19 Sep 2012 11:23:32 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Navin Patel" <navinjpatel336@gmail.com>
References: <CALEYbrhhLsnx_o2kezp+WbR553iwkHRPO7MQ5Nxi27n-ZovvVA@mail.gmail.com>
	<CC7BDB1E.4BE20%keir@xen.org>
	<CALEYbrjgyeFH2WO5SgL0RyYFQqq1YnLQGFuBn+v-SzTQREGi_A@mail.gmail.com>
In-Reply-To: <CALEYbrjgyeFH2WO5SgL0RyYFQqq1YnLQGFuBn+v-SzTQREGi_A@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Steven Maresca <steve@zentific.com>, Keir Fraser <keir@xen.org>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] 4.2.0-rc4 bug: memory events for CR3 register are
 broken (working in 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="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Pj4+IE9uIDE4LjA5LjEyIGF0IDE2OjMwLCBOYXZpbiBQYXRlbCA8bmF2aW5qcGF0ZWwzMzZAZ21h
aWwuY29tPiB3cm90ZToKPiBLZWlyLAo+IAo+IE9uIFN1biwgU2VwIDE2LCAyMDEyIGF0IDI6Mzgg
UE0sIEtlaXIgRnJhc2VyIDxrZWlyQHhlbi5vcmc+IHdyb3RlOgo+IAo+PiAgS2VlcCBhbiBleWUg
b24geGVuLXVuc3RhYmxlIGFuZCBtYWtlIHN1cmUgdGhlIHBhdGNoLCBvciBlcXVpdmFsZW50LCBn
b2VzCj4+IGluIGluIHRoZSBuZXh0IHdlZWsgb3IgdHdvLiBPbmNlIGl04oCZcyBpbiB5b3UgY2Fu
IHJlcXVlc3QgaXQgYmUgYmFja3BvcnRlZC4KPj4KPj4gIC0tIEtlaXIKPj4KPj4KPj4gT24gMTYv
MDkvMjAxMiAxOTozNSwgIk5hdmluIFBhdGVsIiA8bmF2aW5qcGF0ZWwzMzZAZ21haWwuY29tPiB3
cm90ZToKPj4KPj4gS2VpciBhbmQgU3RldmVuLAo+Pgo+PiBUaGFuayB5b3UgZm9yIHlvdXIgd29y
ay4gVGhlIHByb3Bvc2VkIHBhdGNoIHNvbHZlZCB0aGUgYnVnIQo+Pgo+PiBBZnRlciA0LjIuMCBp
cyBvZmZpY2lhbGx5IHJlbGVhc2VkIHRoaXMgd2VlaywgSSB2ZXJ5IG11Y2ggaG9wZSB0aGF0IHRo
aXMKPj4gcGF0Y2ggaXMgYmFja3BvcnRlZCB0byB0aGUgNC4yLjAgdHJlZS4gU2V2ZXJhbCBkaXN0
cmlidXRpb25zIGxpa2UgRGViaWFuCj4+IGFyZSBhbHJlYWR5IGJ1aWxkaW5nIHVwb24gNC4yLjAg
YW5kIHdpbGwgbm90IHdhaXQgZm9yIDQuMi4xLCBhbmQgd2l0aG91dAo+PiB0aGUgcGF0Y2ggYmVp
bmcgYmFja3BvcnRlZCwgcmVzZWFyY2hlcnMgbGlrZSBtZSB3aWxsIG5vdCBiZSBhYmxlIHRvIHVz
ZSB0aGUKPj4gc3VwcG9ydGVkIFhlbiBmcm9tIHBhY2thZ2UgcmVwb3NpdG9yeS4gIFdlIGNhbiBj
b21waWxlIGZyb20gc291cmNlLCBidXQgaWYKPj4gd2UgaGF2ZSBhIHN1cHBvcnRlZCB2ZXJzaW9u
IGl0IGlzIGJldHRlciBmb3IgZXZlcnlvbmUuIChBbmQgaXQgaXMgc3VjaCBhCj4+IHNpbXBsZSBw
YXRjaCEgKQo+Pgo+PiBJcyB0aGlzIHNvbWV0aGluZyBJIGNhbiByZXF1ZXN0IGluIGZvcm1hbCBt
YW5uZXI/Cj4+Cj4+ICBOb3cgdGhhdCB0aGlzIHBhdGNoIGlzIGluIHhlbi11bnN0YWJsZS5oZywg
SSB3b3VsZCBsaWtlIHRvIHJlcXVlc3QgdGhhdAo+IGl0IGJlIGJhY2twb3J0ZWQgdG8gNC4yLjAg
YXMgd2UgZGlzY3Vzc2VkLgoKSSdsbCB0YWtlIGNhcmUgb2YgdGhpcyBzaG9ydGx5IChhc3N1bWlu
ZyBpdCdzIDI1OTE4OjdhYjg5OWU0NjM0Nwp5b3UncmUgdGFsa2luZyBhYm91dCksIGJ1dCBvYnZp
b3VzbHkgdGhpcyBpcyBvbmx5IGdvaW5nIHRvIGJlIGZvcgo0LjIuMSAoZGVzcGl0ZSB5b3VyIGhv
cGVzL3dpc2hlcyksIGFzIEtlaXIgYWxyZWFkeSBpbmRpY2F0ZWQuCgpKYW4KCl9fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxp
c3QKWGVuLWRldmVsQGxpc3RzLnhlbi5vcmcKaHR0cDovL2xpc3RzLnhlbi5vcmcveGVuLWRldmVs
Cg==

From xen-devel-bounces@lists.xen.org Wed Sep 19 10:30:07 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Sep 2012 10:30:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TEHXM-0007Mx-Jc; Wed, 19 Sep 2012 10:29:44 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1TEHXL-0007Ms-EM
	for xen-devel@lists.xen.org; Wed, 19 Sep 2012 10:29:43 +0000
Received: from [85.158.138.51:50913] by server-11.bemta-3.messagelabs.com id
	AB/35-30250-69E99505; Wed, 19 Sep 2012 10:29:42 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1348050581!31138593!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27184 invoked from network); 19 Sep 2012 10:29:42 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-11.tower-174.messagelabs.com with SMTP;
	19 Sep 2012 10:29:42 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 19 Sep 2012 11:29:43 +0100
Message-Id: <5059BAB4020000780009C462@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 19 Sep 2012 11:29:40 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: <zhenzhong.duan@oracle.com>
References: <5020F003020000780009322C@nat28.tlf.novell.com>
	<502235E8.9040309@oracle.com>
	<50229B840200007800093A73@nat28.tlf.novell.com>
	<5023860E.7080908@oracle.com>
	<5023AE960200007800093DE8@nat28.tlf.novell.com>
	<502490A7.7020603@oracle.com>
	<502535280200007800094322@nat28.tlf.novell.com>
	<5028B3AB.7060705@oracle.com>
	<5028E53202000078000946B1@nat28.tlf.novell.com>
	<503DAA5F.5030306@oracle.com>
	<20120830090312.GA54290@ocelot.phlegethon.org>
	<50593071.2050108@oracle.com>
In-Reply-To: <50593071.2050108@oracle.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Satish Kantheti <satish.kantheti@oracle.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Feng Jin <joe.jin@oracle.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Tim Deegan <tim@xen.org>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] kernel bootup slow issue on ovm3.1.1
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Pj4+IE9uIDE5LjA5LjEyIGF0IDA0OjM5LCAiemhlbnpob25nLmR1YW4iIDx6aGVuemhvbmcuZHVh
bkBvcmFjbGUuY29tPiB3cm90ZToKCj4gCj4g5LqOIDIwMTItMDgtMzAgMTc6MDMsIFRpbSBEZWVn
YW4g5YaZ6YGTOgo+PiBBdCAxMzozNiArMDgwMCBvbiAyOSBBdWcgKDEzNDYyNDczOTEpLCB6aGVu
emhvbmcuZHVhbiB3cm90ZToKPj4+Cj4+PiA/Pz8gMjAxMi0wOC0xMyAxNzoyOSwgSmFuIEJldWxp
Y2ggPz8/Pz8/Ogo+Pj4+Pj4+IE9uIDEzLjA4LjEyIGF0IDA5OjU4LCAiemhlbnpob25nLmR1YW4i
PHpoZW56aG9uZy5kdWFuQG9yYWNsZS5jb20+Cj4+Pj4+Pj4gd3JvdGU6Cj4+Pj4+ID8/PyAyMDEy
LTA4LTEwIDIyOjIyLCBKYW4gQmV1bGljaCA/Pz8/Pz86Cj4+Pj4+PiBHb2luZyBiYWNrIHRvIHlv
dXIgb3JpZ2luYWwgbWFpbCwgSSB3b25kZXIgaG93ZXZlciB3aHkgdGhpcwo+Pj4+Pj4gZ2V0cyBk
b25lIGF0IGFsbC4gWW91IHNhaWQgaXQgZ290IHRoZXJlIHZpYQo+Pj4+Pj4KPj4+Pj4+IG10cnJf
YXBzX2luaXQoKQo+Pj4+Pj4gICAgXC0+ICAgIHNldF9tdHJyKCkKPj4+Pj4+ICAgICAgICBcLT4g
ICAgbXRycl93b3JrX2hhbmRsZXIoKQo+Pj4+Pj4KPj4+Pj4+IHlldCB0aGlzIGlzbid0IGRvbmUg
dW5jb25kaXRpb25hbGx5IC0gc2VlIHRoZSBjb21tZW50IGJlZm9yZQo+Pj4+Pj4gY2hlY2tpbmcg
bXRycl9hcHNfZGVsYXllZF9pbml0LiBDYW4geW91IGZpbmQgb3V0IHdoZXJlIHRoZQo+Pj4+Pj4g
b2J2aW91c2x5IG5lY2Vzc2FyeSBjYWxsKHMpIHRvIHNldF9tdHJyX2Fwc19kZWxheWVkX2luaXQo
KQo+Pj4+Pj4gY29tZShzKSBmcm9tPwo+Pj4+PiBBdCBib290dXAgc3RhZ2UsIHNldF9tdHJyX2Fw
c19kZWxheWVkX2luaXQgaXMgY2FsbGVkIGJ5Cj4+Pj4+IG5hdGl2ZV9zbXBfcHJlcGFyZV9jcHVz
Lgo+Pj4+PiBtdHJyX2Fwc19kZWxheWVkX2luaXQgaXMgYWx3YXlzIHNldCB0byB0dXJlIGZvciBp
bnRlbCBwcm9jZXNzb3IgaW4KPj4+Pj4gdXBzdHJlYW0KPj4+Pj4gY29kZS4KPj4+PiBJbmRlZWQs
IGFuZCB0aGF0IChpbiBvbmUgZm9ybSBvciBhbm90aGVyKSBoYXMgYmVlbiBkb25lCj4+Pj4gdmly
dHVhbGx5IGZvcmV2ZXIgaW4gTGludXguIEkgd29uZGVyIHdoeSB0aGUgcHJvYmxlbSB3YXNuJ3QK
Pj4+PiBub3RpY2VkIChvciBsb29rZWQgaW50bywgaWYgaXQgd2FzIG5vdGljZWQpIHNvIGZhci4K
Pj4+Pgo+Pj4+IEFzIGl0J3MgZ29pbmcgdG8gYmUgcmF0aGVyIGRpZmZpY3VsdCB0byBjb252aW5j
ZSB0aGUgTGludXggZm9sa3MKPj4+PiB0byBjaGFuZ2UgdGhlaXIgY29kZSAocGx1cyB0aGlzIHdv
dWxkbid0IGhlbHAgd2l0aCBleGlzdGluZwo+Pj4+IGtlcm5lbHMgYW55d2F5KSwgd2UnbGwgbmVl
ZCB0byBmaW5kIGEgd2F5IHRvIGltcHJvdmUgdGhpcyBpbgo+Pj4+IHRoZSBoeXBlcnZpc29yLgo+
Pj4gSGkgSmFuLCBUaW0KPj4+IElzIHRoaXMgaXNzdWUgaW1wcm92YWJsZSBmcm9tIHhlbiBzaWRl
Pwo+PiBQcm9iYWJseTsgd2UncmUgbG9va2luZyBpbnRvIHRoZSBiZXN0IHdheSB0byBhZGRyZXNz
IGl0Lgo+Cj4gSXMgdGhlcmUgYW55IHBhdGNoIGZvciB1cyB0byB0ZXN0PwoKTm8sIHNvcnJ5LgoK
SmFuCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpYZW4t
ZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW4ub3JnCmh0dHA6Ly9saXN0cy54
ZW4ub3JnL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xen.org Wed Sep 19 10:30:07 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Sep 2012 10:30:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TEHXM-0007Mx-Jc; Wed, 19 Sep 2012 10:29:44 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1TEHXL-0007Ms-EM
	for xen-devel@lists.xen.org; Wed, 19 Sep 2012 10:29:43 +0000
Received: from [85.158.138.51:50913] by server-11.bemta-3.messagelabs.com id
	AB/35-30250-69E99505; Wed, 19 Sep 2012 10:29:42 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1348050581!31138593!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27184 invoked from network); 19 Sep 2012 10:29:42 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-11.tower-174.messagelabs.com with SMTP;
	19 Sep 2012 10:29:42 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 19 Sep 2012 11:29:43 +0100
Message-Id: <5059BAB4020000780009C462@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 19 Sep 2012 11:29:40 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: <zhenzhong.duan@oracle.com>
References: <5020F003020000780009322C@nat28.tlf.novell.com>
	<502235E8.9040309@oracle.com>
	<50229B840200007800093A73@nat28.tlf.novell.com>
	<5023860E.7080908@oracle.com>
	<5023AE960200007800093DE8@nat28.tlf.novell.com>
	<502490A7.7020603@oracle.com>
	<502535280200007800094322@nat28.tlf.novell.com>
	<5028B3AB.7060705@oracle.com>
	<5028E53202000078000946B1@nat28.tlf.novell.com>
	<503DAA5F.5030306@oracle.com>
	<20120830090312.GA54290@ocelot.phlegethon.org>
	<50593071.2050108@oracle.com>
In-Reply-To: <50593071.2050108@oracle.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Satish Kantheti <satish.kantheti@oracle.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Feng Jin <joe.jin@oracle.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Tim Deegan <tim@xen.org>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] kernel bootup slow issue on ovm3.1.1
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Pj4+IE9uIDE5LjA5LjEyIGF0IDA0OjM5LCAiemhlbnpob25nLmR1YW4iIDx6aGVuemhvbmcuZHVh
bkBvcmFjbGUuY29tPiB3cm90ZToKCj4gCj4g5LqOIDIwMTItMDgtMzAgMTc6MDMsIFRpbSBEZWVn
YW4g5YaZ6YGTOgo+PiBBdCAxMzozNiArMDgwMCBvbiAyOSBBdWcgKDEzNDYyNDczOTEpLCB6aGVu
emhvbmcuZHVhbiB3cm90ZToKPj4+Cj4+PiA/Pz8gMjAxMi0wOC0xMyAxNzoyOSwgSmFuIEJldWxp
Y2ggPz8/Pz8/Ogo+Pj4+Pj4+IE9uIDEzLjA4LjEyIGF0IDA5OjU4LCAiemhlbnpob25nLmR1YW4i
PHpoZW56aG9uZy5kdWFuQG9yYWNsZS5jb20+Cj4+Pj4+Pj4gd3JvdGU6Cj4+Pj4+ID8/PyAyMDEy
LTA4LTEwIDIyOjIyLCBKYW4gQmV1bGljaCA/Pz8/Pz86Cj4+Pj4+PiBHb2luZyBiYWNrIHRvIHlv
dXIgb3JpZ2luYWwgbWFpbCwgSSB3b25kZXIgaG93ZXZlciB3aHkgdGhpcwo+Pj4+Pj4gZ2V0cyBk
b25lIGF0IGFsbC4gWW91IHNhaWQgaXQgZ290IHRoZXJlIHZpYQo+Pj4+Pj4KPj4+Pj4+IG10cnJf
YXBzX2luaXQoKQo+Pj4+Pj4gICAgXC0+ICAgIHNldF9tdHJyKCkKPj4+Pj4+ICAgICAgICBcLT4g
ICAgbXRycl93b3JrX2hhbmRsZXIoKQo+Pj4+Pj4KPj4+Pj4+IHlldCB0aGlzIGlzbid0IGRvbmUg
dW5jb25kaXRpb25hbGx5IC0gc2VlIHRoZSBjb21tZW50IGJlZm9yZQo+Pj4+Pj4gY2hlY2tpbmcg
bXRycl9hcHNfZGVsYXllZF9pbml0LiBDYW4geW91IGZpbmQgb3V0IHdoZXJlIHRoZQo+Pj4+Pj4g
b2J2aW91c2x5IG5lY2Vzc2FyeSBjYWxsKHMpIHRvIHNldF9tdHJyX2Fwc19kZWxheWVkX2luaXQo
KQo+Pj4+Pj4gY29tZShzKSBmcm9tPwo+Pj4+PiBBdCBib290dXAgc3RhZ2UsIHNldF9tdHJyX2Fw
c19kZWxheWVkX2luaXQgaXMgY2FsbGVkIGJ5Cj4+Pj4+IG5hdGl2ZV9zbXBfcHJlcGFyZV9jcHVz
Lgo+Pj4+PiBtdHJyX2Fwc19kZWxheWVkX2luaXQgaXMgYWx3YXlzIHNldCB0byB0dXJlIGZvciBp
bnRlbCBwcm9jZXNzb3IgaW4KPj4+Pj4gdXBzdHJlYW0KPj4+Pj4gY29kZS4KPj4+PiBJbmRlZWQs
IGFuZCB0aGF0IChpbiBvbmUgZm9ybSBvciBhbm90aGVyKSBoYXMgYmVlbiBkb25lCj4+Pj4gdmly
dHVhbGx5IGZvcmV2ZXIgaW4gTGludXguIEkgd29uZGVyIHdoeSB0aGUgcHJvYmxlbSB3YXNuJ3QK
Pj4+PiBub3RpY2VkIChvciBsb29rZWQgaW50bywgaWYgaXQgd2FzIG5vdGljZWQpIHNvIGZhci4K
Pj4+Pgo+Pj4+IEFzIGl0J3MgZ29pbmcgdG8gYmUgcmF0aGVyIGRpZmZpY3VsdCB0byBjb252aW5j
ZSB0aGUgTGludXggZm9sa3MKPj4+PiB0byBjaGFuZ2UgdGhlaXIgY29kZSAocGx1cyB0aGlzIHdv
dWxkbid0IGhlbHAgd2l0aCBleGlzdGluZwo+Pj4+IGtlcm5lbHMgYW55d2F5KSwgd2UnbGwgbmVl
ZCB0byBmaW5kIGEgd2F5IHRvIGltcHJvdmUgdGhpcyBpbgo+Pj4+IHRoZSBoeXBlcnZpc29yLgo+
Pj4gSGkgSmFuLCBUaW0KPj4+IElzIHRoaXMgaXNzdWUgaW1wcm92YWJsZSBmcm9tIHhlbiBzaWRl
Pwo+PiBQcm9iYWJseTsgd2UncmUgbG9va2luZyBpbnRvIHRoZSBiZXN0IHdheSB0byBhZGRyZXNz
IGl0Lgo+Cj4gSXMgdGhlcmUgYW55IHBhdGNoIGZvciB1cyB0byB0ZXN0PwoKTm8sIHNvcnJ5LgoK
SmFuCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpYZW4t
ZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW4ub3JnCmh0dHA6Ly9saXN0cy54
ZW4ub3JnL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xen.org Wed Sep 19 10:39:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Sep 2012 10:39: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 1TEHgt-0007b9-Mk; Wed, 19 Sep 2012 10:39:35 +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 1TEHgr-0007b4-Tk
	for xen-devel@lists.xen.org; Wed, 19 Sep 2012 10:39:34 +0000
Received: from [85.158.143.35:36224] by server-1.bemta-4.messagelabs.com id
	8D/A3-05684-5E0A9505; Wed, 19 Sep 2012 10:39:33 +0000
X-Env-Sender: anthony.perard@gmail.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1348051171!17562552!1
X-Originating-IP: [209.85.210.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28803 invoked from network); 19 Sep 2012 10:39:32 -0000
Received: from mail-iy0-f173.google.com (HELO mail-iy0-f173.google.com)
	(209.85.210.173)
	by server-13.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Sep 2012 10:39:32 -0000
Received: by iakx26 with SMTP id x26so814076iak.32
	for <xen-devel@lists.xen.org>; Wed, 19 Sep 2012 03:39: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:from:date
	:x-google-sender-auth:message-id:subject:to:cc:content-type;
	bh=8HfA5J7qLFQO5H5y9/EXiJHjkNZsUAh6ibnj885bk0g=;
	b=fNVOPcPOWHG1BTaseqQxk2Hae4mBiwhN2/NNR5tJ2Duyw4P/02xwyxaLyKYNcR8xcL
	FKC1oyOfM/KOL7RXef9PwBuHDllsGyIIX/Q3PJwgIuMxMC4AI4Hf71dD/r/4p4h73WHC
	HCo03hJCq+5qa9/GNJyiThH9H5hMTxFyUaneib1BgjszhKd6pA5dSeHX15vGubFd7Ib/
	6/rWJavzqqDBoMpH0Cck+MF4bcuRJPyQx31Hn8lhOhzQ9xsQVLWG4CFuogkmm7PRcooN
	tUDAbQJ0rB9rwDszBJy/QYHqrYb1SQFJvixMrSoNh1ibA7URx9fnYnPUXRjRpOdxAPAA
	xADw==
Received: by 10.50.168.69 with SMTP id zu5mr1678042igb.23.1348051155426; Wed,
	19 Sep 2012 03:39:15 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.64.49.4 with HTTP; Wed, 19 Sep 2012 03:38:44 -0700 (PDT)
In-Reply-To: <A9667DDFB95DB7438FA9D7D576C3D87E25BB14@SHSMSX101.ccr.corp.intel.com>
References: <A9667DDFB95DB7438FA9D7D576C3D87E203D54@SHSMSX101.ccr.corp.intel.com>
	<alpine.DEB.2.02.1208031122170.4645@kaball.uk.xensource.com>
	<1343990187.21372.48.camel@zakaz.uk.xensource.com>
	<40352EBA8B4DF841A9907B883F22B59B0FDBCE1E@SHSMSX102.ccr.corp.intel.com>
	<40352EBA8B4DF841A9907B883F22B59B0FDD25C7@SHSMSX102.ccr.corp.intel.com>
	<A9667DDFB95DB7438FA9D7D576C3D87E258EF6@SHSMSX101.ccr.corp.intel.com>
	<505851CF.2090000@citrix.com>
	<A9667DDFB95DB7438FA9D7D576C3D87E25BB14@SHSMSX101.ccr.corp.intel.com>
From: Anthony PERARD <anthony.perard@citrix.com>
Date: Wed, 19 Sep 2012 11:38:44 +0100
X-Google-Sender-Auth: LrrYMRNBPDiFzOhZfzTPn8a49FQ
Message-ID: <CAJJyHjLH38r-r+cTmPprMj4trU8eZpQrfp4ypBzdsmZHSL9BMw@mail.gmail.com>
To: "Zhang, Yang Z" <yang.z.zhang@intel.com>
Cc: Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>, "Shan,
	Haitao" <haitao.shan@intel.com>, "Zhou,
	Chao" <chao.zhou@intel.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] error when pass through device to guest with
	qemu-xen-dir-remote
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Sep 19, 2012 at 1:06 AM, Zhang, Yang Z <yang.z.zhang@intel.com> wrote:
> Anthony PERARD wrote on 2012-09-18:
>>
>> Hi,
>>
>> So, we'll have to add a check in the unplug code of qemu to ignore
>> passthrough devices.
>>
>> Here is a patches, I did not test it.
>>
>> diff --git a/hw/xen_platform.c b/hw/xen_platform.c
>> index 0d6c2ff..2d3978e 100644
>> --- a/hw/xen_platform.c
>> +++ b/hw/xen_platform.c
>> @@ -85,8 +85,10 @@ static void log_writeb ...
>>
>>   static void unplug_nic(PCIBus *b, PCIDevice *d, void *o)
>>   {
>> +    /* We have to ignore passthrough devices */
>>       if (pci_get_word(d->config + PCI_CLASS_DEVICE) ==
>> -            PCI_CLASS_NETWORK_ETHERNET) {
>> +            PCI_CLASS_NETWORK_ETHERNET
>> +        && strcmp(d->name, "xen-pci-passthrough") != 0) {
>>           qdev_free(&d->qdev);
>>       }
>>   }
>
> In old qemu, we will free the invalid NIC through this function. And it will fail w/ your change. Shouldn't we follow the old logic?

I don't understand. Are you arguing this patch or the function it self?

My change is fine and follow the old logic: do not do anything for a
passthrough device.

I now have tested the change, and QEMU work as espected, it will
unplug the emulated NIC, and ignore any passthrough devices. So the
guest can the passthroughed NIC.

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 Wed Sep 19 10:39:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Sep 2012 10:39: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 1TEHgt-0007b9-Mk; Wed, 19 Sep 2012 10:39:35 +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 1TEHgr-0007b4-Tk
	for xen-devel@lists.xen.org; Wed, 19 Sep 2012 10:39:34 +0000
Received: from [85.158.143.35:36224] by server-1.bemta-4.messagelabs.com id
	8D/A3-05684-5E0A9505; Wed, 19 Sep 2012 10:39:33 +0000
X-Env-Sender: anthony.perard@gmail.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1348051171!17562552!1
X-Originating-IP: [209.85.210.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28803 invoked from network); 19 Sep 2012 10:39:32 -0000
Received: from mail-iy0-f173.google.com (HELO mail-iy0-f173.google.com)
	(209.85.210.173)
	by server-13.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Sep 2012 10:39:32 -0000
Received: by iakx26 with SMTP id x26so814076iak.32
	for <xen-devel@lists.xen.org>; Wed, 19 Sep 2012 03:39: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:from:date
	:x-google-sender-auth:message-id:subject:to:cc:content-type;
	bh=8HfA5J7qLFQO5H5y9/EXiJHjkNZsUAh6ibnj885bk0g=;
	b=fNVOPcPOWHG1BTaseqQxk2Hae4mBiwhN2/NNR5tJ2Duyw4P/02xwyxaLyKYNcR8xcL
	FKC1oyOfM/KOL7RXef9PwBuHDllsGyIIX/Q3PJwgIuMxMC4AI4Hf71dD/r/4p4h73WHC
	HCo03hJCq+5qa9/GNJyiThH9H5hMTxFyUaneib1BgjszhKd6pA5dSeHX15vGubFd7Ib/
	6/rWJavzqqDBoMpH0Cck+MF4bcuRJPyQx31Hn8lhOhzQ9xsQVLWG4CFuogkmm7PRcooN
	tUDAbQJ0rB9rwDszBJy/QYHqrYb1SQFJvixMrSoNh1ibA7URx9fnYnPUXRjRpOdxAPAA
	xADw==
Received: by 10.50.168.69 with SMTP id zu5mr1678042igb.23.1348051155426; Wed,
	19 Sep 2012 03:39:15 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.64.49.4 with HTTP; Wed, 19 Sep 2012 03:38:44 -0700 (PDT)
In-Reply-To: <A9667DDFB95DB7438FA9D7D576C3D87E25BB14@SHSMSX101.ccr.corp.intel.com>
References: <A9667DDFB95DB7438FA9D7D576C3D87E203D54@SHSMSX101.ccr.corp.intel.com>
	<alpine.DEB.2.02.1208031122170.4645@kaball.uk.xensource.com>
	<1343990187.21372.48.camel@zakaz.uk.xensource.com>
	<40352EBA8B4DF841A9907B883F22B59B0FDBCE1E@SHSMSX102.ccr.corp.intel.com>
	<40352EBA8B4DF841A9907B883F22B59B0FDD25C7@SHSMSX102.ccr.corp.intel.com>
	<A9667DDFB95DB7438FA9D7D576C3D87E258EF6@SHSMSX101.ccr.corp.intel.com>
	<505851CF.2090000@citrix.com>
	<A9667DDFB95DB7438FA9D7D576C3D87E25BB14@SHSMSX101.ccr.corp.intel.com>
From: Anthony PERARD <anthony.perard@citrix.com>
Date: Wed, 19 Sep 2012 11:38:44 +0100
X-Google-Sender-Auth: LrrYMRNBPDiFzOhZfzTPn8a49FQ
Message-ID: <CAJJyHjLH38r-r+cTmPprMj4trU8eZpQrfp4ypBzdsmZHSL9BMw@mail.gmail.com>
To: "Zhang, Yang Z" <yang.z.zhang@intel.com>
Cc: Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>, "Shan,
	Haitao" <haitao.shan@intel.com>, "Zhou,
	Chao" <chao.zhou@intel.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] error when pass through device to guest with
	qemu-xen-dir-remote
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Sep 19, 2012 at 1:06 AM, Zhang, Yang Z <yang.z.zhang@intel.com> wrote:
> Anthony PERARD wrote on 2012-09-18:
>>
>> Hi,
>>
>> So, we'll have to add a check in the unplug code of qemu to ignore
>> passthrough devices.
>>
>> Here is a patches, I did not test it.
>>
>> diff --git a/hw/xen_platform.c b/hw/xen_platform.c
>> index 0d6c2ff..2d3978e 100644
>> --- a/hw/xen_platform.c
>> +++ b/hw/xen_platform.c
>> @@ -85,8 +85,10 @@ static void log_writeb ...
>>
>>   static void unplug_nic(PCIBus *b, PCIDevice *d, void *o)
>>   {
>> +    /* We have to ignore passthrough devices */
>>       if (pci_get_word(d->config + PCI_CLASS_DEVICE) ==
>> -            PCI_CLASS_NETWORK_ETHERNET) {
>> +            PCI_CLASS_NETWORK_ETHERNET
>> +        && strcmp(d->name, "xen-pci-passthrough") != 0) {
>>           qdev_free(&d->qdev);
>>       }
>>   }
>
> In old qemu, we will free the invalid NIC through this function. And it will fail w/ your change. Shouldn't we follow the old logic?

I don't understand. Are you arguing this patch or the function it self?

My change is fine and follow the old logic: do not do anything for a
passthrough device.

I now have tested the change, and QEMU work as espected, it will
unplug the emulated NIC, and ignore any passthrough devices. So the
guest can the passthroughed NIC.

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 Wed Sep 19 10:50:52 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Sep 2012 10:50: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 1TEHrS-0007mU-2O; Wed, 19 Sep 2012 10:50:30 +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 1TEHrQ-0007mP-8k
	for xen-devel@lists.xen.org; Wed, 19 Sep 2012 10:50:28 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1348051817!8196860!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 472 invoked from network); 19 Sep 2012 10:50:17 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-5.tower-27.messagelabs.com with SMTP;
	19 Sep 2012 10:50:17 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 19 Sep 2012 11:50:17 +0100
Message-Id: <5059BF86020000780009C485@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 19 Sep 2012 11:50:14 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__PartB485B076.0__="
Subject: [Xen-devel] [PATCH] x86: tighten checks in
 XEN_DOMCTL_memory_mapping handler
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
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.

--=__PartB485B076.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Properly checking the MFN implies knowing the physical address width
supported by the platform, so to obtain this consistently the
respective code gets moved out of the MTRR subdir.

Btw., the model specific workaround in that code is likely unnecessary
- I believe those CPU models don't support 64-bit mode. But I wasn't
able to formally verify this, so I preferred to retain that code for
now.

But domctl code here also was lacking other error checks (as was,
looking at it again from that angle) the XEN_DOMCTL_ioport_mapping one.
Besides adding the missing checks, printing is also added for the case
where revoking access permissions didn't work (as that may have
implications for the host operator, e.g. wanting to not pass through
affected devices to another guest until the one previously using them
did actually die).

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/arch/x86/cpu/common.c
+++ b/xen/arch/x86/cpu/common.c
@@ -36,6 +36,8 @@ integer_param("cpuid_mask_ext_edx", opt_
=20
 struct cpu_dev * cpu_devs[X86_VENDOR_NUM] =3D {};
=20
+unsigned int paddr_bits __read_mostly =3D 36;
+
 /*
  * Default host IA32_CR_PAT value to cover all memory types.
  * BIOS usually sets it to 0x07040600070406.
@@ -265,6 +267,8 @@ static void __cpuinit generic_identify(s
 		}
 		if ( xlvl >=3D 0x80000004 )
 			get_model_name(c); /* Default name */
+		if ( xlvl >=3D 0x80000008 )
+			paddr_bits =3D cpuid_eax(0x80000008) & 0xff;
 	}
=20
 	/* Intel-defined flags: level 0x00000007 */
--- a/xen/arch/x86/cpu/intel.c
+++ b/xen/arch/x86/cpu/intel.c
@@ -144,6 +144,11 @@ void __devinit early_intel_workaround(st
 				       c->cpuid_level);
 		}
 	}
+
+	/* CPUID workaround for Intel 0F33/0F34 CPU */
+	if (boot_cpu_data.x86 =3D=3D 0xF && boot_cpu_data.x86_model =3D=3D =
3 &&
+	    (boot_cpu_data.x86_mask =3D=3D 3 || boot_cpu_data.x86_mask =
=3D=3D 4))
+		paddr_bits =3D 36;
 }
=20
 /*
--- a/xen/arch/x86/cpu/mtrr/main.c
+++ b/xen/arch/x86/cpu/mtrr/main.c
@@ -559,8 +559,6 @@ struct mtrr_value {
 	unsigned long	lsize;
 };
=20
-unsigned int paddr_bits __read_mostly =3D 36;
-
 /**
  * mtrr_bp_init - initialize mtrrs on the boot CPU
  *
@@ -572,31 +570,8 @@ void __init mtrr_bp_init(void)
 {
 	if (cpu_has_mtrr) {
 		mtrr_if =3D &generic_mtrr_ops;
-		size_or_mask =3D 0xff000000;	/* 36 bits */
-		size_and_mask =3D 0x00f00000;
-
-		/* This is an AMD specific MSR, but we assume(hope?) that
-		   Intel will implement it to when they extend the address
-		   bus of the Xeon. */
-		if (cpuid_eax(0x80000000) >=3D 0x80000008) {
-			paddr_bits =3D cpuid_eax(0x80000008) & 0xff;
-			/* CPUID workaround for Intel 0F33/0F34 CPU */
-			if (boot_cpu_data.x86_vendor =3D=3D X86_VENDOR_INTE=
L &&
-			    boot_cpu_data.x86 =3D=3D 0xF &&
-			    boot_cpu_data.x86_model =3D=3D 0x3 &&
-			    (boot_cpu_data.x86_mask =3D=3D 0x3 ||
-			     boot_cpu_data.x86_mask =3D=3D 0x4))
-				paddr_bits =3D 36;
-
-			size_or_mask =3D ~((1ULL << (paddr_bits - =
PAGE_SHIFT)) - 1);
-			size_and_mask =3D ~size_or_mask & 0xfffff00000ULL;
-		} else if (boot_cpu_data.x86_vendor =3D=3D X86_VENDOR_CENTA=
UR &&
-			   boot_cpu_data.x86 =3D=3D 6) {
-			/* VIA C* family have Intel style MTRRs, but
-			   don't support PAE */
-			size_or_mask =3D 0xfff00000;	/* 32 bits */
-			size_and_mask =3D 0;
-		}
+		size_or_mask =3D ~((1ULL << (paddr_bits - PAGE_SHIFT)) - =
1);
+		size_and_mask =3D ~size_or_mask & 0xfffff00000ULL;
 	}
=20
 	if (mtrr_if) {
--- a/xen/arch/x86/domctl.c
+++ b/xen/arch/x86/domctl.c
@@ -825,10 +825,12 @@ long arch_do_domctl(
         unsigned long mfn =3D domctl->u.memory_mapping.first_mfn;
         unsigned long nr_mfns =3D domctl->u.memory_mapping.nr_mfns;
         int add =3D domctl->u.memory_mapping.add_mapping;
-        int i;
+        unsigned long i;
=20
         ret =3D -EINVAL;
-        if ( (mfn + nr_mfns - 1) < mfn ) /* wrap? */
+        if ( (mfn + nr_mfns - 1) < mfn || /* wrap? */
+             ((mfn | (mfn + nr_mfns - 1)) >> (paddr_bits - PAGE_SHIFT)) =
||
+             (gfn + nr_mfns - 1) < gfn ) /* wrap? */
             break;
=20
         ret =3D -EPERM;
@@ -853,8 +855,25 @@ long arch_do_domctl(
                    d->domain_id, gfn, mfn, nr_mfns);
=20
             ret =3D iomem_permit_access(d, mfn, mfn + nr_mfns - 1);
-            for ( i =3D 0; i < nr_mfns; i++ )
-                set_mmio_p2m_entry(d, gfn+i, _mfn(mfn+i));
+            if ( !ret && paging_mode_translate(d) )
+            {
+                for ( i =3D 0; !ret && i < nr_mfns; i++ )
+                    if ( !set_mmio_p2m_entry(d, gfn + i, _mfn(mfn + i)) )
+                        ret =3D -EIO;
+                if ( ret )
+                {
+                    printk(XENLOG_G_WARNING
+                           "memory_map:fail: dom%d gfn=3D%lx mfn=3D%lx\n",=

+                           d->domain_id, gfn + i, mfn + i);
+                    while ( i-- )
+                        clear_mmio_p2m_entry(d, gfn + i);
+                    if ( iomem_deny_access(d, mfn, mfn + nr_mfns - 1) &&
+                         IS_PRIV(current->domain) )
+                        printk(XENLOG_ERR
+                               "memory_map: failed to deny dom%d access =
to [%lx,%lx]\n",
+                               d->domain_id, mfn, mfn + nr_mfns - 1);
+                }
+            }
         }
         else
         {
@@ -862,9 +881,17 @@ long arch_do_domctl(
                    "memory_map:remove: dom%d gfn=3D%lx mfn=3D%lx =
nr=3D%lx\n",
                    d->domain_id, gfn, mfn, nr_mfns);
=20
-            for ( i =3D 0; i < nr_mfns; i++ )
-                clear_mmio_p2m_entry(d, gfn+i);
+            if ( paging_mode_translate(d) )
+                for ( i =3D 0; i < nr_mfns; i++ )
+                    add |=3D !clear_mmio_p2m_entry(d, gfn + i);
             ret =3D iomem_deny_access(d, mfn, mfn + nr_mfns - 1);
+            if ( !ret && add )
+                ret =3D -EIO;
+            if ( ret && IS_PRIV(current->domain) )
+                printk(XENLOG_ERR
+                       "memory_map: error %ld %s dom%d access to =
[%lx,%lx]\n",
+                       ret, add ? "removing" : "denying", d->domain_id,
+                       mfn, mfn + nr_mfns - 1);
         }
=20
         rcu_unlock_domain(d);
@@ -926,12 +953,23 @@ long arch_do_domctl(
             if ( !found )
             {
                 g2m_ioport =3D xmalloc(struct g2m_ioport);
+                if ( !g2m_ioport )
+                    ret =3D -ENOMEM;
+            }
+            if ( !found && !ret )
+            {
                 g2m_ioport->gport =3D fgp;
                 g2m_ioport->mport =3D fmp;
                 g2m_ioport->np =3D np;
                 list_add_tail(&g2m_ioport->list, &hd->g2m_ioport_list);
             }
-            ret =3D ioports_permit_access(d, fmp, fmp + np - 1);
+            if ( !ret )
+                ret =3D ioports_permit_access(d, fmp, fmp + np - 1);
+            if ( ret && !found && g2m_ioport )
+            {
+                list_del(&g2m_ioport->list);
+                xfree(g2m_ioport);
+            }
         }
         else
         {
@@ -946,6 +984,10 @@ long arch_do_domctl(
                     break;
                 }
             ret =3D ioports_deny_access(d, fmp, fmp + np - 1);
+            if ( ret && IS_PRIV(current->domain) )
+                printk(XENLOG_ERR
+                       "ioport_map: error %ld denying dom%d access to =
[%x,%x]\n",
+                       ret, d->domain_id, fmp, fmp + np - 1);
         }
         rcu_unlock_domain(d);
     }



--=__PartB485B076.0__=
Content-Type: text/plain; name="x86-domctl-memory-mapping-range.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="x86-domctl-memory-mapping-range.patch"

x86: tighten checks in XEN_DOMCTL_memory_mapping handler=0A=0AProperly =
checking the MFN implies knowing the physical address width=0Asupported by =
the platform, so to obtain this consistently the=0Arespective code gets =
moved out of the MTRR subdir.=0A=0ABtw., the model specific workaround in =
that code is likely unnecessary=0A- I believe those CPU models don't =
support 64-bit mode. But I wasn't=0Aable to formally verify this, so I =
preferred to retain that code for=0Anow.=0A=0ABut domctl code here also =
was lacking other error checks (as was,=0Alooking at it again from that =
angle) the XEN_DOMCTL_ioport_mapping one.=0ABesides adding the missing =
checks, printing is also added for the case=0Awhere revoking access =
permissions didn't work (as that may have=0Aimplications for the host =
operator, e.g. wanting to not pass through=0Aaffected devices to another =
guest until the one previously using them=0Adid actually die).=0A=0ASigned-=
off-by: Jan Beulich <jbeulich@suse.com>=0A=0A--- a/xen/arch/x86/cpu/common.=
c=0A+++ b/xen/arch/x86/cpu/common.c=0A@@ -36,6 +36,8 @@ integer_param("cpui=
d_mask_ext_edx", opt_=0A =0A struct cpu_dev * cpu_devs[X86_VENDOR_NUM] =3D =
{};=0A =0A+unsigned int paddr_bits __read_mostly =3D 36;=0A+=0A /*=0A  * =
Default host IA32_CR_PAT value to cover all memory types.=0A  * BIOS =
usually sets it to 0x07040600070406.=0A@@ -265,6 +267,8 @@ static void =
__cpuinit generic_identify(s=0A 		}=0A 		if ( xlvl =
>=3D 0x80000004 )=0A 			get_model_name(c); /* Default name =
*/=0A+		if ( xlvl >=3D 0x80000008 )=0A+			paddr_bits =
=3D cpuid_eax(0x80000008) & 0xff;=0A 	}=0A =0A 	/* Intel-defined =
flags: level 0x00000007 */=0A--- a/xen/arch/x86/cpu/intel.c=0A+++ =
b/xen/arch/x86/cpu/intel.c=0A@@ -144,6 +144,11 @@ void __devinit early_inte=
l_workaround(st=0A 				       c->cpuid_level);=0A =
		}=0A 	}=0A+=0A+	/* CPUID workaround for Intel =
0F33/0F34 CPU */=0A+	if (boot_cpu_data.x86 =3D=3D 0xF && boot_cpu_data.x=
86_model =3D=3D 3 &&=0A+	    (boot_cpu_data.x86_mask =3D=3D 3 || =
boot_cpu_data.x86_mask =3D=3D 4))=0A+		paddr_bits =3D 36;=0A }=0A =
=0A /*=0A--- a/xen/arch/x86/cpu/mtrr/main.c=0A+++ b/xen/arch/x86/cpu/mtrr/m=
ain.c=0A@@ -559,8 +559,6 @@ struct mtrr_value {=0A 	unsigned long	=
lsize;=0A };=0A =0A-unsigned int paddr_bits __read_mostly =3D 36;=0A-=0A =
/**=0A  * mtrr_bp_init - initialize mtrrs on the boot CPU=0A  *=0A@@ =
-572,31 +570,8 @@ void __init mtrr_bp_init(void)=0A {=0A 	if =
(cpu_has_mtrr) {=0A 		mtrr_if =3D &generic_mtrr_ops;=0A-		=
size_or_mask =3D 0xff000000;	/* 36 bits */=0A-		size_and_ma=
sk =3D 0x00f00000;=0A-=0A-		/* This is an AMD specific MSR, =
but we assume(hope?) that=0A-		   Intel will implement it to when =
they extend the address=0A-		   bus of the Xeon. */=0A-		=
if (cpuid_eax(0x80000000) >=3D 0x80000008) {=0A-			=
paddr_bits =3D cpuid_eax(0x80000008) & 0xff;=0A-			/* =
CPUID workaround for Intel 0F33/0F34 CPU */=0A-			if =
(boot_cpu_data.x86_vendor =3D=3D X86_VENDOR_INTEL &&=0A-			=
    boot_cpu_data.x86 =3D=3D 0xF &&=0A-			    boot_cpu_data.x=
86_model =3D=3D 0x3 &&=0A-			    (boot_cpu_data.x86_mask=
 =3D=3D 0x3 ||=0A-			     boot_cpu_data.x86_mask =3D=3D =
0x4))=0A-				paddr_bits =3D 36;=0A-=0A-		=
	size_or_mask =3D ~((1ULL << (paddr_bits - PAGE_SHIFT)) - 1);=0A-	=
		size_and_mask =3D ~size_or_mask & 0xfffff00000ULL;=0A-		=
} else if (boot_cpu_data.x86_vendor =3D=3D X86_VENDOR_CENTAUR &&=0A-		=
	   boot_cpu_data.x86 =3D=3D 6) {=0A-			/* VIA C* =
family have Intel style MTRRs, but=0A-			   don't support =
PAE */=0A-			size_or_mask =3D 0xfff00000;	/* 32 bits =
*/=0A-			size_and_mask =3D 0;=0A-		}=0A+		=
size_or_mask =3D ~((1ULL << (paddr_bits - PAGE_SHIFT)) - 1);=0A+		=
size_and_mask =3D ~size_or_mask & 0xfffff00000ULL;=0A 	}=0A =0A 	if =
(mtrr_if) {=0A--- a/xen/arch/x86/domctl.c=0A+++ b/xen/arch/x86/domctl.c=0A@=
@ -825,10 +825,12 @@ long arch_do_domctl(=0A         unsigned long mfn =3D =
domctl->u.memory_mapping.first_mfn;=0A         unsigned long nr_mfns =3D =
domctl->u.memory_mapping.nr_mfns;=0A         int add =3D domctl->u.memory_m=
apping.add_mapping;=0A-        int i;=0A+        unsigned long i;=0A =0A   =
      ret =3D -EINVAL;=0A-        if ( (mfn + nr_mfns - 1) < mfn ) /* =
wrap? */=0A+        if ( (mfn + nr_mfns - 1) < mfn || /* wrap? */=0A+      =
       ((mfn | (mfn + nr_mfns - 1)) >> (paddr_bits - PAGE_SHIFT)) ||=0A+   =
          (gfn + nr_mfns - 1) < gfn ) /* wrap? */=0A             break;=0A =
=0A         ret =3D -EPERM;=0A@@ -853,8 +855,25 @@ long arch_do_domctl(=0A =
                   d->domain_id, gfn, mfn, nr_mfns);=0A =0A             =
ret =3D iomem_permit_access(d, mfn, mfn + nr_mfns - 1);=0A-            for =
( i =3D 0; i < nr_mfns; i++ )=0A-                set_mmio_p2m_entry(d, =
gfn+i, _mfn(mfn+i));=0A+            if ( !ret && paging_mode_translate(d) =
)=0A+            {=0A+                for ( i =3D 0; !ret && i < nr_mfns; =
i++ )=0A+                    if ( !set_mmio_p2m_entry(d, gfn + i, _mfn(mfn =
+ i)) )=0A+                        ret =3D -EIO;=0A+                if ( =
ret )=0A+                {=0A+                    printk(XENLOG_G_WARNING=
=0A+                           "memory_map:fail: dom%d gfn=3D%lx mfn=3D%lx\=
n",=0A+                           d->domain_id, gfn + i, mfn + i);=0A+     =
               while ( i-- )=0A+                        clear_mmio_p2m_entr=
y(d, gfn + i);=0A+                    if ( iomem_deny_access(d, mfn, mfn + =
nr_mfns - 1) &&=0A+                         IS_PRIV(current->domain) )=0A+ =
                       printk(XENLOG_ERR=0A+                               =
"memory_map: failed to deny dom%d access to [%lx,%lx]\n",=0A+              =
                 d->domain_id, mfn, mfn + nr_mfns - 1);=0A+                =
}=0A+            }=0A         }=0A         else=0A         {=0A@@ -862,9 =
+881,17 @@ long arch_do_domctl(=0A                    "memory_map:remove: =
dom%d gfn=3D%lx mfn=3D%lx nr=3D%lx\n",=0A                    d->domain_id, =
gfn, mfn, nr_mfns);=0A =0A-            for ( i =3D 0; i < nr_mfns; i++ =
)=0A-                clear_mmio_p2m_entry(d, gfn+i);=0A+            if ( =
paging_mode_translate(d) )=0A+                for ( i =3D 0; i < nr_mfns; =
i++ )=0A+                    add |=3D !clear_mmio_p2m_entry(d, gfn + =
i);=0A             ret =3D iomem_deny_access(d, mfn, mfn + nr_mfns - =
1);=0A+            if ( !ret && add )=0A+                ret =3D -EIO;=0A+ =
           if ( ret && IS_PRIV(current->domain) )=0A+                =
printk(XENLOG_ERR=0A+                       "memory_map: error %ld %s =
dom%d access to [%lx,%lx]\n",=0A+                       ret, add ? =
"removing" : "denying", d->domain_id,=0A+                       mfn, mfn + =
nr_mfns - 1);=0A         }=0A =0A         rcu_unlock_domain(d);=0A@@ =
-926,12 +953,23 @@ long arch_do_domctl(=0A             if ( !found )=0A    =
         {=0A                 g2m_ioport =3D xmalloc(struct g2m_ioport);=0A=
+                if ( !g2m_ioport )=0A+                    ret =3D =
-ENOMEM;=0A+            }=0A+            if ( !found && !ret )=0A+         =
   {=0A                 g2m_ioport->gport =3D fgp;=0A                 =
g2m_ioport->mport =3D fmp;=0A                 g2m_ioport->np =3D np;=0A    =
             list_add_tail(&g2m_ioport->list, &hd->g2m_ioport_list);=0A    =
         }=0A-            ret =3D ioports_permit_access(d, fmp, fmp + np - =
1);=0A+            if ( !ret )=0A+                ret =3D ioports_permit_ac=
cess(d, fmp, fmp + np - 1);=0A+            if ( ret && !found && g2m_ioport=
 )=0A+            {=0A+                list_del(&g2m_ioport->list);=0A+    =
            xfree(g2m_ioport);=0A+            }=0A         }=0A         =
else=0A         {=0A@@ -946,6 +984,10 @@ long arch_do_domctl(=0A           =
          break;=0A                 }=0A             ret =3D ioports_deny_a=
ccess(d, fmp, fmp + np - 1);=0A+            if ( ret && IS_PRIV(current->do=
main) )=0A+                printk(XENLOG_ERR=0A+                       =
"ioport_map: error %ld denying dom%d access to [%x,%x]\n",=0A+             =
          ret, d->domain_id, fmp, fmp + np - 1);=0A         }=0A         =
rcu_unlock_domain(d);=0A     }=0A
--=__PartB485B076.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

--=__PartB485B076.0__=--


From xen-devel-bounces@lists.xen.org Wed Sep 19 10:50:52 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Sep 2012 10:50: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 1TEHrS-0007mU-2O; Wed, 19 Sep 2012 10:50:30 +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 1TEHrQ-0007mP-8k
	for xen-devel@lists.xen.org; Wed, 19 Sep 2012 10:50:28 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1348051817!8196860!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 472 invoked from network); 19 Sep 2012 10:50:17 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-5.tower-27.messagelabs.com with SMTP;
	19 Sep 2012 10:50:17 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 19 Sep 2012 11:50:17 +0100
Message-Id: <5059BF86020000780009C485@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 19 Sep 2012 11:50:14 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__PartB485B076.0__="
Subject: [Xen-devel] [PATCH] x86: tighten checks in
 XEN_DOMCTL_memory_mapping handler
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
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.

--=__PartB485B076.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Properly checking the MFN implies knowing the physical address width
supported by the platform, so to obtain this consistently the
respective code gets moved out of the MTRR subdir.

Btw., the model specific workaround in that code is likely unnecessary
- I believe those CPU models don't support 64-bit mode. But I wasn't
able to formally verify this, so I preferred to retain that code for
now.

But domctl code here also was lacking other error checks (as was,
looking at it again from that angle) the XEN_DOMCTL_ioport_mapping one.
Besides adding the missing checks, printing is also added for the case
where revoking access permissions didn't work (as that may have
implications for the host operator, e.g. wanting to not pass through
affected devices to another guest until the one previously using them
did actually die).

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/arch/x86/cpu/common.c
+++ b/xen/arch/x86/cpu/common.c
@@ -36,6 +36,8 @@ integer_param("cpuid_mask_ext_edx", opt_
=20
 struct cpu_dev * cpu_devs[X86_VENDOR_NUM] =3D {};
=20
+unsigned int paddr_bits __read_mostly =3D 36;
+
 /*
  * Default host IA32_CR_PAT value to cover all memory types.
  * BIOS usually sets it to 0x07040600070406.
@@ -265,6 +267,8 @@ static void __cpuinit generic_identify(s
 		}
 		if ( xlvl >=3D 0x80000004 )
 			get_model_name(c); /* Default name */
+		if ( xlvl >=3D 0x80000008 )
+			paddr_bits =3D cpuid_eax(0x80000008) & 0xff;
 	}
=20
 	/* Intel-defined flags: level 0x00000007 */
--- a/xen/arch/x86/cpu/intel.c
+++ b/xen/arch/x86/cpu/intel.c
@@ -144,6 +144,11 @@ void __devinit early_intel_workaround(st
 				       c->cpuid_level);
 		}
 	}
+
+	/* CPUID workaround for Intel 0F33/0F34 CPU */
+	if (boot_cpu_data.x86 =3D=3D 0xF && boot_cpu_data.x86_model =3D=3D =
3 &&
+	    (boot_cpu_data.x86_mask =3D=3D 3 || boot_cpu_data.x86_mask =
=3D=3D 4))
+		paddr_bits =3D 36;
 }
=20
 /*
--- a/xen/arch/x86/cpu/mtrr/main.c
+++ b/xen/arch/x86/cpu/mtrr/main.c
@@ -559,8 +559,6 @@ struct mtrr_value {
 	unsigned long	lsize;
 };
=20
-unsigned int paddr_bits __read_mostly =3D 36;
-
 /**
  * mtrr_bp_init - initialize mtrrs on the boot CPU
  *
@@ -572,31 +570,8 @@ void __init mtrr_bp_init(void)
 {
 	if (cpu_has_mtrr) {
 		mtrr_if =3D &generic_mtrr_ops;
-		size_or_mask =3D 0xff000000;	/* 36 bits */
-		size_and_mask =3D 0x00f00000;
-
-		/* This is an AMD specific MSR, but we assume(hope?) that
-		   Intel will implement it to when they extend the address
-		   bus of the Xeon. */
-		if (cpuid_eax(0x80000000) >=3D 0x80000008) {
-			paddr_bits =3D cpuid_eax(0x80000008) & 0xff;
-			/* CPUID workaround for Intel 0F33/0F34 CPU */
-			if (boot_cpu_data.x86_vendor =3D=3D X86_VENDOR_INTE=
L &&
-			    boot_cpu_data.x86 =3D=3D 0xF &&
-			    boot_cpu_data.x86_model =3D=3D 0x3 &&
-			    (boot_cpu_data.x86_mask =3D=3D 0x3 ||
-			     boot_cpu_data.x86_mask =3D=3D 0x4))
-				paddr_bits =3D 36;
-
-			size_or_mask =3D ~((1ULL << (paddr_bits - =
PAGE_SHIFT)) - 1);
-			size_and_mask =3D ~size_or_mask & 0xfffff00000ULL;
-		} else if (boot_cpu_data.x86_vendor =3D=3D X86_VENDOR_CENTA=
UR &&
-			   boot_cpu_data.x86 =3D=3D 6) {
-			/* VIA C* family have Intel style MTRRs, but
-			   don't support PAE */
-			size_or_mask =3D 0xfff00000;	/* 32 bits */
-			size_and_mask =3D 0;
-		}
+		size_or_mask =3D ~((1ULL << (paddr_bits - PAGE_SHIFT)) - =
1);
+		size_and_mask =3D ~size_or_mask & 0xfffff00000ULL;
 	}
=20
 	if (mtrr_if) {
--- a/xen/arch/x86/domctl.c
+++ b/xen/arch/x86/domctl.c
@@ -825,10 +825,12 @@ long arch_do_domctl(
         unsigned long mfn =3D domctl->u.memory_mapping.first_mfn;
         unsigned long nr_mfns =3D domctl->u.memory_mapping.nr_mfns;
         int add =3D domctl->u.memory_mapping.add_mapping;
-        int i;
+        unsigned long i;
=20
         ret =3D -EINVAL;
-        if ( (mfn + nr_mfns - 1) < mfn ) /* wrap? */
+        if ( (mfn + nr_mfns - 1) < mfn || /* wrap? */
+             ((mfn | (mfn + nr_mfns - 1)) >> (paddr_bits - PAGE_SHIFT)) =
||
+             (gfn + nr_mfns - 1) < gfn ) /* wrap? */
             break;
=20
         ret =3D -EPERM;
@@ -853,8 +855,25 @@ long arch_do_domctl(
                    d->domain_id, gfn, mfn, nr_mfns);
=20
             ret =3D iomem_permit_access(d, mfn, mfn + nr_mfns - 1);
-            for ( i =3D 0; i < nr_mfns; i++ )
-                set_mmio_p2m_entry(d, gfn+i, _mfn(mfn+i));
+            if ( !ret && paging_mode_translate(d) )
+            {
+                for ( i =3D 0; !ret && i < nr_mfns; i++ )
+                    if ( !set_mmio_p2m_entry(d, gfn + i, _mfn(mfn + i)) )
+                        ret =3D -EIO;
+                if ( ret )
+                {
+                    printk(XENLOG_G_WARNING
+                           "memory_map:fail: dom%d gfn=3D%lx mfn=3D%lx\n",=

+                           d->domain_id, gfn + i, mfn + i);
+                    while ( i-- )
+                        clear_mmio_p2m_entry(d, gfn + i);
+                    if ( iomem_deny_access(d, mfn, mfn + nr_mfns - 1) &&
+                         IS_PRIV(current->domain) )
+                        printk(XENLOG_ERR
+                               "memory_map: failed to deny dom%d access =
to [%lx,%lx]\n",
+                               d->domain_id, mfn, mfn + nr_mfns - 1);
+                }
+            }
         }
         else
         {
@@ -862,9 +881,17 @@ long arch_do_domctl(
                    "memory_map:remove: dom%d gfn=3D%lx mfn=3D%lx =
nr=3D%lx\n",
                    d->domain_id, gfn, mfn, nr_mfns);
=20
-            for ( i =3D 0; i < nr_mfns; i++ )
-                clear_mmio_p2m_entry(d, gfn+i);
+            if ( paging_mode_translate(d) )
+                for ( i =3D 0; i < nr_mfns; i++ )
+                    add |=3D !clear_mmio_p2m_entry(d, gfn + i);
             ret =3D iomem_deny_access(d, mfn, mfn + nr_mfns - 1);
+            if ( !ret && add )
+                ret =3D -EIO;
+            if ( ret && IS_PRIV(current->domain) )
+                printk(XENLOG_ERR
+                       "memory_map: error %ld %s dom%d access to =
[%lx,%lx]\n",
+                       ret, add ? "removing" : "denying", d->domain_id,
+                       mfn, mfn + nr_mfns - 1);
         }
=20
         rcu_unlock_domain(d);
@@ -926,12 +953,23 @@ long arch_do_domctl(
             if ( !found )
             {
                 g2m_ioport =3D xmalloc(struct g2m_ioport);
+                if ( !g2m_ioport )
+                    ret =3D -ENOMEM;
+            }
+            if ( !found && !ret )
+            {
                 g2m_ioport->gport =3D fgp;
                 g2m_ioport->mport =3D fmp;
                 g2m_ioport->np =3D np;
                 list_add_tail(&g2m_ioport->list, &hd->g2m_ioport_list);
             }
-            ret =3D ioports_permit_access(d, fmp, fmp + np - 1);
+            if ( !ret )
+                ret =3D ioports_permit_access(d, fmp, fmp + np - 1);
+            if ( ret && !found && g2m_ioport )
+            {
+                list_del(&g2m_ioport->list);
+                xfree(g2m_ioport);
+            }
         }
         else
         {
@@ -946,6 +984,10 @@ long arch_do_domctl(
                     break;
                 }
             ret =3D ioports_deny_access(d, fmp, fmp + np - 1);
+            if ( ret && IS_PRIV(current->domain) )
+                printk(XENLOG_ERR
+                       "ioport_map: error %ld denying dom%d access to =
[%x,%x]\n",
+                       ret, d->domain_id, fmp, fmp + np - 1);
         }
         rcu_unlock_domain(d);
     }



--=__PartB485B076.0__=
Content-Type: text/plain; name="x86-domctl-memory-mapping-range.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="x86-domctl-memory-mapping-range.patch"

x86: tighten checks in XEN_DOMCTL_memory_mapping handler=0A=0AProperly =
checking the MFN implies knowing the physical address width=0Asupported by =
the platform, so to obtain this consistently the=0Arespective code gets =
moved out of the MTRR subdir.=0A=0ABtw., the model specific workaround in =
that code is likely unnecessary=0A- I believe those CPU models don't =
support 64-bit mode. But I wasn't=0Aable to formally verify this, so I =
preferred to retain that code for=0Anow.=0A=0ABut domctl code here also =
was lacking other error checks (as was,=0Alooking at it again from that =
angle) the XEN_DOMCTL_ioport_mapping one.=0ABesides adding the missing =
checks, printing is also added for the case=0Awhere revoking access =
permissions didn't work (as that may have=0Aimplications for the host =
operator, e.g. wanting to not pass through=0Aaffected devices to another =
guest until the one previously using them=0Adid actually die).=0A=0ASigned-=
off-by: Jan Beulich <jbeulich@suse.com>=0A=0A--- a/xen/arch/x86/cpu/common.=
c=0A+++ b/xen/arch/x86/cpu/common.c=0A@@ -36,6 +36,8 @@ integer_param("cpui=
d_mask_ext_edx", opt_=0A =0A struct cpu_dev * cpu_devs[X86_VENDOR_NUM] =3D =
{};=0A =0A+unsigned int paddr_bits __read_mostly =3D 36;=0A+=0A /*=0A  * =
Default host IA32_CR_PAT value to cover all memory types.=0A  * BIOS =
usually sets it to 0x07040600070406.=0A@@ -265,6 +267,8 @@ static void =
__cpuinit generic_identify(s=0A 		}=0A 		if ( xlvl =
>=3D 0x80000004 )=0A 			get_model_name(c); /* Default name =
*/=0A+		if ( xlvl >=3D 0x80000008 )=0A+			paddr_bits =
=3D cpuid_eax(0x80000008) & 0xff;=0A 	}=0A =0A 	/* Intel-defined =
flags: level 0x00000007 */=0A--- a/xen/arch/x86/cpu/intel.c=0A+++ =
b/xen/arch/x86/cpu/intel.c=0A@@ -144,6 +144,11 @@ void __devinit early_inte=
l_workaround(st=0A 				       c->cpuid_level);=0A =
		}=0A 	}=0A+=0A+	/* CPUID workaround for Intel =
0F33/0F34 CPU */=0A+	if (boot_cpu_data.x86 =3D=3D 0xF && boot_cpu_data.x=
86_model =3D=3D 3 &&=0A+	    (boot_cpu_data.x86_mask =3D=3D 3 || =
boot_cpu_data.x86_mask =3D=3D 4))=0A+		paddr_bits =3D 36;=0A }=0A =
=0A /*=0A--- a/xen/arch/x86/cpu/mtrr/main.c=0A+++ b/xen/arch/x86/cpu/mtrr/m=
ain.c=0A@@ -559,8 +559,6 @@ struct mtrr_value {=0A 	unsigned long	=
lsize;=0A };=0A =0A-unsigned int paddr_bits __read_mostly =3D 36;=0A-=0A =
/**=0A  * mtrr_bp_init - initialize mtrrs on the boot CPU=0A  *=0A@@ =
-572,31 +570,8 @@ void __init mtrr_bp_init(void)=0A {=0A 	if =
(cpu_has_mtrr) {=0A 		mtrr_if =3D &generic_mtrr_ops;=0A-		=
size_or_mask =3D 0xff000000;	/* 36 bits */=0A-		size_and_ma=
sk =3D 0x00f00000;=0A-=0A-		/* This is an AMD specific MSR, =
but we assume(hope?) that=0A-		   Intel will implement it to when =
they extend the address=0A-		   bus of the Xeon. */=0A-		=
if (cpuid_eax(0x80000000) >=3D 0x80000008) {=0A-			=
paddr_bits =3D cpuid_eax(0x80000008) & 0xff;=0A-			/* =
CPUID workaround for Intel 0F33/0F34 CPU */=0A-			if =
(boot_cpu_data.x86_vendor =3D=3D X86_VENDOR_INTEL &&=0A-			=
    boot_cpu_data.x86 =3D=3D 0xF &&=0A-			    boot_cpu_data.x=
86_model =3D=3D 0x3 &&=0A-			    (boot_cpu_data.x86_mask=
 =3D=3D 0x3 ||=0A-			     boot_cpu_data.x86_mask =3D=3D =
0x4))=0A-				paddr_bits =3D 36;=0A-=0A-		=
	size_or_mask =3D ~((1ULL << (paddr_bits - PAGE_SHIFT)) - 1);=0A-	=
		size_and_mask =3D ~size_or_mask & 0xfffff00000ULL;=0A-		=
} else if (boot_cpu_data.x86_vendor =3D=3D X86_VENDOR_CENTAUR &&=0A-		=
	   boot_cpu_data.x86 =3D=3D 6) {=0A-			/* VIA C* =
family have Intel style MTRRs, but=0A-			   don't support =
PAE */=0A-			size_or_mask =3D 0xfff00000;	/* 32 bits =
*/=0A-			size_and_mask =3D 0;=0A-		}=0A+		=
size_or_mask =3D ~((1ULL << (paddr_bits - PAGE_SHIFT)) - 1);=0A+		=
size_and_mask =3D ~size_or_mask & 0xfffff00000ULL;=0A 	}=0A =0A 	if =
(mtrr_if) {=0A--- a/xen/arch/x86/domctl.c=0A+++ b/xen/arch/x86/domctl.c=0A@=
@ -825,10 +825,12 @@ long arch_do_domctl(=0A         unsigned long mfn =3D =
domctl->u.memory_mapping.first_mfn;=0A         unsigned long nr_mfns =3D =
domctl->u.memory_mapping.nr_mfns;=0A         int add =3D domctl->u.memory_m=
apping.add_mapping;=0A-        int i;=0A+        unsigned long i;=0A =0A   =
      ret =3D -EINVAL;=0A-        if ( (mfn + nr_mfns - 1) < mfn ) /* =
wrap? */=0A+        if ( (mfn + nr_mfns - 1) < mfn || /* wrap? */=0A+      =
       ((mfn | (mfn + nr_mfns - 1)) >> (paddr_bits - PAGE_SHIFT)) ||=0A+   =
          (gfn + nr_mfns - 1) < gfn ) /* wrap? */=0A             break;=0A =
=0A         ret =3D -EPERM;=0A@@ -853,8 +855,25 @@ long arch_do_domctl(=0A =
                   d->domain_id, gfn, mfn, nr_mfns);=0A =0A             =
ret =3D iomem_permit_access(d, mfn, mfn + nr_mfns - 1);=0A-            for =
( i =3D 0; i < nr_mfns; i++ )=0A-                set_mmio_p2m_entry(d, =
gfn+i, _mfn(mfn+i));=0A+            if ( !ret && paging_mode_translate(d) =
)=0A+            {=0A+                for ( i =3D 0; !ret && i < nr_mfns; =
i++ )=0A+                    if ( !set_mmio_p2m_entry(d, gfn + i, _mfn(mfn =
+ i)) )=0A+                        ret =3D -EIO;=0A+                if ( =
ret )=0A+                {=0A+                    printk(XENLOG_G_WARNING=
=0A+                           "memory_map:fail: dom%d gfn=3D%lx mfn=3D%lx\=
n",=0A+                           d->domain_id, gfn + i, mfn + i);=0A+     =
               while ( i-- )=0A+                        clear_mmio_p2m_entr=
y(d, gfn + i);=0A+                    if ( iomem_deny_access(d, mfn, mfn + =
nr_mfns - 1) &&=0A+                         IS_PRIV(current->domain) )=0A+ =
                       printk(XENLOG_ERR=0A+                               =
"memory_map: failed to deny dom%d access to [%lx,%lx]\n",=0A+              =
                 d->domain_id, mfn, mfn + nr_mfns - 1);=0A+                =
}=0A+            }=0A         }=0A         else=0A         {=0A@@ -862,9 =
+881,17 @@ long arch_do_domctl(=0A                    "memory_map:remove: =
dom%d gfn=3D%lx mfn=3D%lx nr=3D%lx\n",=0A                    d->domain_id, =
gfn, mfn, nr_mfns);=0A =0A-            for ( i =3D 0; i < nr_mfns; i++ =
)=0A-                clear_mmio_p2m_entry(d, gfn+i);=0A+            if ( =
paging_mode_translate(d) )=0A+                for ( i =3D 0; i < nr_mfns; =
i++ )=0A+                    add |=3D !clear_mmio_p2m_entry(d, gfn + =
i);=0A             ret =3D iomem_deny_access(d, mfn, mfn + nr_mfns - =
1);=0A+            if ( !ret && add )=0A+                ret =3D -EIO;=0A+ =
           if ( ret && IS_PRIV(current->domain) )=0A+                =
printk(XENLOG_ERR=0A+                       "memory_map: error %ld %s =
dom%d access to [%lx,%lx]\n",=0A+                       ret, add ? =
"removing" : "denying", d->domain_id,=0A+                       mfn, mfn + =
nr_mfns - 1);=0A         }=0A =0A         rcu_unlock_domain(d);=0A@@ =
-926,12 +953,23 @@ long arch_do_domctl(=0A             if ( !found )=0A    =
         {=0A                 g2m_ioport =3D xmalloc(struct g2m_ioport);=0A=
+                if ( !g2m_ioport )=0A+                    ret =3D =
-ENOMEM;=0A+            }=0A+            if ( !found && !ret )=0A+         =
   {=0A                 g2m_ioport->gport =3D fgp;=0A                 =
g2m_ioport->mport =3D fmp;=0A                 g2m_ioport->np =3D np;=0A    =
             list_add_tail(&g2m_ioport->list, &hd->g2m_ioport_list);=0A    =
         }=0A-            ret =3D ioports_permit_access(d, fmp, fmp + np - =
1);=0A+            if ( !ret )=0A+                ret =3D ioports_permit_ac=
cess(d, fmp, fmp + np - 1);=0A+            if ( ret && !found && g2m_ioport=
 )=0A+            {=0A+                list_del(&g2m_ioport->list);=0A+    =
            xfree(g2m_ioport);=0A+            }=0A         }=0A         =
else=0A         {=0A@@ -946,6 +984,10 @@ long arch_do_domctl(=0A           =
          break;=0A                 }=0A             ret =3D ioports_deny_a=
ccess(d, fmp, fmp + np - 1);=0A+            if ( ret && IS_PRIV(current->do=
main) )=0A+                printk(XENLOG_ERR=0A+                       =
"ioport_map: error %ld denying dom%d access to [%x,%x]\n",=0A+             =
          ret, d->domain_id, fmp, fmp + np - 1);=0A         }=0A         =
rcu_unlock_domain(d);=0A     }=0A
--=__PartB485B076.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

--=__PartB485B076.0__=--


From xen-devel-bounces@lists.xen.org Wed Sep 19 10:52:19 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Sep 2012 10: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 1TEHsv-0007sb-Mn; Wed, 19 Sep 2012 10:52:01 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <oliver.chick@citrix.com>) id 1TEHsu-0007sM-Pn
	for xen-devel@lists.xen.org; Wed, 19 Sep 2012 10:52:01 +0000
X-Env-Sender: oliver.chick@citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1348051913!6027896!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNzU4MDA=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28378 invoked from network); 19 Sep 2012 10:51:54 -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;
	19 Sep 2012 10:51:54 -0000
X-IronPort-AV: E=Sophos;i="4.80,447,1344211200"; d="scan'208";a="208530654"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Sep 2012 10:51:52 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 19 Sep 2012 06:51:52 -0400
Received: from leeni.uk.xensource.com ([10.80.2.50]
	helo=oliverchick-Precision-WorkStation-T3400.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<oliver.chick@citrix.com>)	id 1TEHsm-0003oR-2R;
	Wed, 19 Sep 2012 11:51:52 +0100
From: Oliver Chick <oliver.chick@citrix.com>
To: xen-devel@lists.xen.org,
	konrad.wilk@oracle.com
Date: Wed, 19 Sep 2012 11:51:27 +0100
Message-ID: <1348051887-21885-1-git-send-email-oliver.chick@citrix.com>
X-Mailer: git-send-email 1.7.9.5
MIME-Version: 1.0
Cc: Oliver Chick <oliver.chick@citrix.com>, linux-kernel@vger.kernel.org
Subject: [Xen-devel] [PATCH] Persistent grant maps for xen blk drivers
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This patch implements persistent grants for the xen-blk{front,back}
mechanism. The effect of this change is to reduce the number of unmap
operations performed, since they cause a (costly) TLB shootdown. This
allows the I/O performance to scale better when a large number of VMs
are performing I/O.

Previously, the blkfront driver was supplied a bvec[] from the request
queue. This was granted to dom0; dom0 performed the I/O and wrote
directly into the grant-mapped memory and unmapped it; blkfront then
removed foreign access for that grant. The cost of unmapping scales
badly with the number of CPUs in Dom0. An experiment showed that when
Dom0 has 24 VCPUs, and guests are performing parallel I/O to a
ramdisk, the IPIs from performing unmap's is a bottleneck at 5 guests
(at which point 650,000 IOPS are being performed in total). If more
than 5 guests are used, the performance declines. By 10 guests, only
400,000 IOPS are being performed.

This patch improves performance by only unmapping when the connection
between blkfront and back is broken.

On startup, blk{front,back} use xenbus to communicate their ability to
perform 'feature-persistent'. Iff both ends have this ability,
persistent mode is used.

To perform a read, in persistent mode, blkfront uses a separate pool
of pages that it maps to dom0. When a request comes in, blkfront
transmutes the request so that blkback will write into one of these
free pages. Blkback keeps note of which grefs it has already
mapped. When a new ring request comes to blkback, it looks to see if
it has already mapped that page. If so, it will not map it again. If
the page hasn't been previously mapped, it is mapped now, and a record
is kept of this mapping. Blkback proceeds as usual. When blkfront is
notified that blkback has completed a request, it memcpy's from the
shared memory, into the bvec supplied. A record that the {gref, page}
tuple is mapped, and not inflight is kept.

Writes are similar, except that the memcpy is peformed from the
supplied bvecs, into the shared pages, before the request is put onto
the ring.

Blkback has to store a mapping of grefs=>{page mapped to by gref} in
an array. As the grefs are not known apriori, and provide no
guarantees on their ordering, we have to perform a linear search
through this array to find the page, for every gref we receive. The
overhead of this is low, however future work might want to use a more
efficient data structure to reduce this O(n) operation.

We (ijc, and myself) have introduced a new constant,
BLKIF_MAX_PERS_REQUESTS_PER_DEV. This is to prevent a malicious guest
from attempting a DoS, by supplying fresh grefs, causing the Dom0
kernel from to map excessively. This is currently set to 256---the
maximum number of entires in the ring. As the number of inflight
requests <= size of ring, 256 is also the maximum sensible size. This
introduces a maximum overhead of 11MB of mapped memory, per block
device. In practice, we don't typically use about 60 of these. If the
guest exceeds the 256 limit, it is either buggy or malicious. We treat
this in one of two ways:
1) If we have mapped <
BLKIF_MAX_SEGMENTS_PER_REQUEST * BLKIF_MAX_PERS_REQUESTS_PER_DEV
pages, we will persistently map the grefs. This can occur is previous
requests have not used all BLKIF_MAX_SEGMENTS_PER_REQUEST segments.
2) Otherwise, we revert to non-persistent grants for all future grefs.

In writing this patch, the question arrises as to if the additional
cost of performing memcpys in the guest (to/from the pool of granted
pages) outweigh the gains of not performing TLB shootdowns. The answer
to that question is `no'. There appears to be very little, if any
additional cost to the guest of using persistent grants. There is
perhaps a small saving, from the reduced number of hypercalls
performed in granting, and ending foreign access.


Signed-off-by: Oliver Chick <oliver.chick@citrix.com>
---
 drivers/block/xen-blkback/blkback.c |  149 +++++++++++++++++++++++++---
 drivers/block/xen-blkback/common.h  |   16 +++
 drivers/block/xen-blkback/xenbus.c  |   21 +++-
 drivers/block/xen-blkfront.c        |  186 ++++++++++++++++++++++++++++++-----
 include/xen/interface/io/blkif.h    |    9 ++
 5 files changed, 338 insertions(+), 43 deletions(-)

diff --git a/drivers/block/xen-blkback/blkback.c b/drivers/block/xen-blkback/blkback.c
index 73f196c..f95dee9 100644
--- a/drivers/block/xen-blkback/blkback.c
+++ b/drivers/block/xen-blkback/blkback.c
@@ -78,6 +78,7 @@ struct pending_req {
 	unsigned short		operation;
 	int			status;
 	struct list_head	free_list;
+	u8			is_pers;
 };
 
 #define BLKBACK_INVALID_HANDLE (~0)
@@ -128,6 +129,24 @@ static int dispatch_rw_block_io(struct xen_blkif *blkif,
 static void make_response(struct xen_blkif *blkif, u64 id,
 			  unsigned short op, int st);
 
+static void add_pers_gnt(struct pers_gnt *pers_gnt, struct xen_blkif *blkif)
+{
+	BUG_ON(blkif->pers_gnt_c >= BLKIF_MAX_PERS_REQUESTS_PER_DEV *
+	       BLKIF_MAX_SEGMENTS_PER_REQUEST);
+	blkif->pers_gnts[blkif->pers_gnt_c++] = pers_gnt;
+}
+
+static struct pers_gnt *get_pers_gnt(struct xen_blkif *blkif,
+				     grant_ref_t gref)
+{
+	int i;
+
+	for (i = 0; i < blkif->pers_gnt_c; i++)
+		if (gref == blkif->pers_gnts[i]->gnt)
+			return blkif->pers_gnts[i];
+	return NULL;
+}
+
 /*
  * Retrieve from the 'pending_reqs' a free pending_req structure to be used.
  */
@@ -274,6 +293,12 @@ int xen_blkif_schedule(void *arg)
 {
 	struct xen_blkif *blkif = arg;
 	struct xen_vbd *vbd = &blkif->vbd;
+	struct gnttab_unmap_grant_ref unmap[BLKIF_MAX_SEGMENTS_PER_REQUEST];
+	struct page *pages[BLKIF_MAX_SEGMENTS_PER_REQUEST];
+	struct pers_gnt *pers_gnt;
+	int i;
+	int ret = 0;
+	int segs_to_unmap;
 
 	xen_blkif_get(blkif);
 
@@ -301,6 +326,29 @@ int xen_blkif_schedule(void *arg)
 			print_stats(blkif);
 	}
 
+	/* Free all persistent grant pages */
+
+	while (segs_to_unmap = min(BLKIF_MAX_SEGMENTS_PER_REQUEST,
+				 blkif->pers_gnt_c)) {
+
+		for (i = 0; i < segs_to_unmap; i++) {
+			pers_gnt = blkif->pers_gnts[blkif->pers_gnt_c - i - 1];
+
+			gnttab_set_unmap_op(&unmap[i],
+					    pfn_to_kaddr(page_to_pfn(
+							     pers_gnt->page)),
+					    GNTMAP_host_map,
+					    pers_gnt->handle);
+
+			pages[i] = pers_gnt->page;
+		}
+
+		ret = gnttab_unmap_refs(unmap, pages, segs_to_unmap, false);
+		BUG_ON(ret);
+
+		blkif->pers_gnt_c -= segs_to_unmap;
+
+	}
+
 	if (log_stats)
 		print_stats(blkif);
 
@@ -343,13 +391,28 @@ static void xen_blkbk_unmap(struct pending_req *req)
 
 static int xen_blkbk_map(struct blkif_request *req,
 			 struct pending_req *pending_req,
-			 struct seg_buf seg[])
+			 struct seg_buf seg[],
+			 struct page *pages[])
 {
 	struct gnttab_map_grant_ref map[BLKIF_MAX_SEGMENTS_PER_REQUEST];
+	struct pers_gnt *new_pers_gnts[BLKIF_MAX_SEGMENTS_PER_REQUEST];
+	struct pers_gnt *pers_gnts[BLKIF_MAX_SEGMENTS_PER_REQUEST];
+	struct page *pages_to_gnt[BLKIF_MAX_SEGMENTS_PER_REQUEST];
+	struct pers_gnt *pers_gnt;
+	phys_addr_t addr;
 	int i;
+	int new_map;
 	int nseg = req->u.rw.nr_segments;
+	int segs_to_init = 0;
 	int ret = 0;
+	int use_pers_gnts;
 
+	use_pers_gnts = (pending_req->blkif->can_grant_persist &&
+			 pending_req->blkif->pers_gnt_c <
+			 BLKIF_MAX_SEGMENTS_PER_REQUEST *
+			 BLKIF_MAX_PERS_REQUESTS_PER_DEV);
+
+	pending_req->is_pers = use_pers_gnts;
 	/*
 	 * Fill out preq.nr_sects with proper amount of sectors, and setup
 	 * assign map[..] with the PFN of the page in our domain with the
@@ -358,36 +421,87 @@ static int xen_blkbk_map(struct blkif_request *req,
 	for (i = 0; i < nseg; i++) {
 		uint32_t flags;
 
+		if (use_pers_gnts) {
+			pers_gnt = get_pers_gnt(pending_req->blkif,
+						req->u.rw.seg[i].gref);
+			if (!pers_gnt) {
+				new_map = 1;
+				pers_gnt = kmalloc(sizeof(struct pers_gnt),
+						   GFP_KERNEL);
+				if (!pers_gnt)
+					return -ENOMEM;
+				pers_gnt->page = alloc_page(GFP_KERNEL);
+				if (!pers_gnt->page)
+					return -ENOMEM;
+				pers_gnt->gnt = req->u.rw.seg[i].gref;
+
+				pages_to_gnt[segs_to_init] = pers_gnt->page;
+				new_pers_gnts[segs_to_init] = pers_gnt;
+
+				add_pers_gnt(pers_gnt, pending_req->blkif);
+
+			} else {
+				new_map = 0;
+			}
+			pages[i] = pers_gnt->page;
+			addr = (unsigned long) pfn_to_kaddr(
+				page_to_pfn(pers_gnt->page));
+			pers_gnts[i] = pers_gnt;
+		} else {
+			new_map = 1;
+			pages[i] = blkbk->pending_page(pending_req, i);
+			addr = vaddr(pending_req, i);
+			pages_to_gnt[i] = blkbk->pending_page(pending_req, i);
+		}
+
 		flags = GNTMAP_host_map;
-		if (pending_req->operation != BLKIF_OP_READ)
+		if (!use_pers_gnts && (pending_req->operation != BLKIF_OP_READ))
 			flags |= GNTMAP_readonly;
-		gnttab_set_map_op(&map[i], vaddr(pending_req, i), flags,
-				  req->u.rw.seg[i].gref,
-				  pending_req->blkif->domid);
+		if (new_map) {
+			gnttab_set_map_op(&map[segs_to_init++], addr,
+					  flags, req->u.rw.seg[i].gref,
+					  pending_req->blkif->domid);
+		}
 	}
 
-	ret = gnttab_map_refs(map, NULL, &blkbk->pending_page(pending_req, 0), nseg);
-	BUG_ON(ret);
+	if (segs_to_init) {
+		ret = gnttab_map_refs(map, NULL, pages_to_gnt, segs_to_init);
+		BUG_ON(ret);
+	}
 
 	/*
 	 * Now swizzle the MFN in our domain with the MFN from the other domain
 	 * so that when we access vaddr(pending_req,i) it has the contents of
 	 * the page from the other domain.
 	 */
-	for (i = 0; i < nseg; i++) {
+	for (i = 0; i < segs_to_init; i++) {
 		if (unlikely(map[i].status != 0)) {
 			pr_debug(DRV_PFX "invalid buffer -- could not remap it\n");
 			map[i].handle = BLKBACK_INVALID_HANDLE;
 			ret |= 1;
 		}
 
-		pending_handle(pending_req, i) = map[i].handle;
+		if (use_pers_gnts) {
+			/* store the `out' values from map */
+		    pending_req->blkif->pers_gnts
+			[pending_req->blkif->pers_gnt_c - segs_to_init +
+			 i]->handle = map[i].handle;
+			new_pers_gnts[i]->dev_bus_addr = map[i].dev_bus_addr;
+		}
 
 		if (ret)
 			continue;
-
-		seg[i].buf  = map[i].dev_bus_addr |
-			(req->u.rw.seg[i].first_sect << 9);
+	}
+	for (i = 0; i < nseg; i++) {
+		if (use_pers_gnts) {
+			pending_handle(pending_req, i) = pers_gnts[i]->handle;
+			seg[i].buf = pers_gnts[i]->dev_bus_addr |
+				(req->u.rw.seg[i].first_sect << 9);
+		} else {
+			pending_handle(pending_req, i) = map[i].handle;
+			seg[i].buf = map[i].dev_bus_addr |
+				(req->u.rw.seg[i].first_sect << 9);
+		}
 	}
 	return ret;
 }
@@ -468,7 +582,8 @@ static void __end_block_io_op(struct pending_req *pending_req, int error)
 	 * the proper response on the ring.
 	 */
 	if (atomic_dec_and_test(&pending_req->pendcnt)) {
-		xen_blkbk_unmap(pending_req);
+		if (!pending_req->is_pers)
+			xen_blkbk_unmap(pending_req);
 		make_response(pending_req->blkif, pending_req->id,
 			      pending_req->operation, pending_req->status);
 		xen_blkif_put(pending_req->blkif);
@@ -590,6 +705,7 @@ static int dispatch_rw_block_io(struct xen_blkif *blkif,
 	int operation;
 	struct blk_plug plug;
 	bool drain = false;
+	struct page *pages[BLKIF_MAX_SEGMENTS_PER_REQUEST];
 
 	switch (req->operation) {
 	case BLKIF_OP_READ:
@@ -676,7 +792,7 @@ static int dispatch_rw_block_io(struct xen_blkif *blkif,
 	 * the hypercall to unmap the grants - that is all done in
 	 * xen_blkbk_unmap.
 	 */
-	if (xen_blkbk_map(req, pending_req, seg))
+	if (xen_blkbk_map(req, pending_req, seg, pages))
 		goto fail_flush;
 
 	/*
@@ -688,7 +804,7 @@ static int dispatch_rw_block_io(struct xen_blkif *blkif,
 	for (i = 0; i < nseg; i++) {
 		while ((bio == NULL) ||
 		       (bio_add_page(bio,
-				     blkbk->pending_page(pending_req, i),
+				     pages[i],
 				     seg[i].nsec << 9,
 				     seg[i].buf & ~PAGE_MASK) == 0)) {
 
@@ -743,7 +859,8 @@ static int dispatch_rw_block_io(struct xen_blkif *blkif,
 	return 0;
 
  fail_flush:
-	xen_blkbk_unmap(pending_req);
+	if (!blkif->can_grant_persist)
+		xen_blkbk_unmap(pending_req);
  fail_response:
 	/* Haven't submitted any bio's yet. */
 	make_response(blkif, req->u.rw.id, req->operation, BLKIF_RSP_ERROR);
diff --git a/drivers/block/xen-blkback/common.h b/drivers/block/xen-blkback/common.h
index 9ad3b5e..1ecb709 100644
--- a/drivers/block/xen-blkback/common.h
+++ b/drivers/block/xen-blkback/common.h
@@ -47,6 +47,8 @@
 #define DPRINTK(fmt, args...)				\
 	pr_debug(DRV_PFX "(%s:%d) " fmt ".\n",		\
 		 __func__, __LINE__, ##args)
+#define BLKIF_MAX_PERS_REQUESTS_PER_DEV 256
+
 
 
 /* Not a real protocol.  Used to generate ring structs which contain
@@ -164,6 +166,14 @@ struct xen_vbd {
 
 struct backend_info;
 
+
+struct pers_gnt {
+	struct page *page;
+	grant_ref_t gnt;
+	uint32_t handle;
+	uint64_t dev_bus_addr;
+};
+
 struct xen_blkif {
 	/* Unique identifier for this interface. */
 	domid_t			domid;
@@ -190,6 +200,12 @@ struct xen_blkif {
 	struct task_struct	*xenblkd;
 	unsigned int		waiting_reqs;
 
+	/* frontend feature information */
+	u8			can_grant_persist:1;
+	struct pers_gnt		*pers_gnts[BLKIF_MAX_PERS_REQUESTS_PER_DEV *
+					  BLKIF_MAX_SEGMENTS_PER_REQUEST];
+	unsigned int		pers_gnt_c;
+
 	/* statistics */
 	unsigned long		st_print;
 	int			st_rd_req;
diff --git a/drivers/block/xen-blkback/xenbus.c b/drivers/block/xen-blkback/xenbus.c
index 4f66171..dc58cc4 100644
--- a/drivers/block/xen-blkback/xenbus.c
+++ b/drivers/block/xen-blkback/xenbus.c
@@ -681,6 +681,13 @@ again:
 		goto abort;
 	}
 
+	err = xenbus_printf(xbt, dev->nodename, "feature-persistent-grants",
+			    "%d", 1);
+	if (err) {
+		xenbus_dev_fatal(dev, err, "writing persistent capability");
+		goto abort;
+	}
+
 	/* FIXME: use a typename instead */
 	err = xenbus_printf(xbt, dev->nodename, "info", "%u",
 			    be->blkif->vbd.type |
@@ -721,6 +728,7 @@ static int connect_ring(struct backend_info *be)
 	struct xenbus_device *dev = be->dev;
 	unsigned long ring_ref;
 	unsigned int evtchn;
+	u8 pers_grants;
 	char protocol[64] = "";
 	int err;
 
@@ -750,8 +758,17 @@ static int connect_ring(struct backend_info *be)
 		xenbus_dev_fatal(dev, err, "unknown fe protocol %s", protocol);
 		return -1;
 	}
-	pr_info(DRV_PFX "ring-ref %ld, event-channel %d, protocol %d (%s)\n",
-		ring_ref, evtchn, be->blkif->blk_protocol, protocol);
+	err = xenbus_gather(XBT_NIL, dev->otherend,
+			    "feature-persistent-grants", "%d",
+			    &pers_grants, NULL);
+	if (err)
+		pers_grants = 0;
+
+	be->blkif->can_grant_persist = pers_grants;
+
+	pr_info(DRV_PFX "ring-ref %ld, event-channel %d, protocol %d (%s) persistent %d\n",
+		ring_ref, evtchn, be->blkif->blk_protocol, protocol,
+		pers_grants);
 
 	/* Map the shared frame, irq etc. */
 	err = xen_blkif_map(be->blkif, ring_ref, evtchn);
diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c
index e4fb337..c1cc5fe 100644
--- a/drivers/block/xen-blkfront.c
+++ b/drivers/block/xen-blkfront.c
@@ -68,6 +68,13 @@ struct blk_shadow {
 	struct blkif_request req;
 	struct request *request;
 	unsigned long frame[BLKIF_MAX_SEGMENTS_PER_REQUEST];
+	struct gnt_list *grants_used[BLKIF_MAX_SEGMENTS_PER_REQUEST];
+};
+
+struct gnt_list {
+	grant_ref_t gref;
+	unsigned long frame;
+	struct gnt_list *tail;
 };
 
 static DEFINE_MUTEX(blkfront_mutex);
@@ -97,11 +104,14 @@ struct blkfront_info
 	struct work_struct work;
 	struct gnttab_free_callback callback;
 	struct blk_shadow shadow[BLK_RING_SIZE];
+	struct gnt_list *persistent_grants_front;
+	unsigned int persistent_grants_c;
 	unsigned long shadow_free;
 	unsigned int feature_flush;
 	unsigned int flush_op;
 	unsigned int feature_discard:1;
 	unsigned int feature_secdiscard:1;
+	unsigned int feature_persistent:1;
 	unsigned int discard_granularity;
 	unsigned int discard_alignment;
 	int is_ready;
@@ -286,22 +296,37 @@ static int blkif_queue_request(struct request *req)
 	struct blkif_request *ring_req;
 	unsigned long id;
 	unsigned int fsect, lsect;
-	int i, ref;
+	int i, ref, use_pers_gnts, new_pers_gnts;
 	grant_ref_t gref_head;
+	struct bio_vec *bvecs[BLKIF_MAX_SEGMENTS_PER_REQUEST];
+	struct bio_vec *bvec;
+	struct req_iterator iter;
+	char *bvec_data;
+	void *shared_data;
+	unsigned long flags;
+	struct page *shared_page;
+	struct gnt_list *gnt_list_entry;
 	struct scatterlist *sg;
 
 	if (unlikely(info->connected != BLKIF_STATE_CONNECTED))
 		return 1;
 
-	if (gnttab_alloc_grant_references(
-		BLKIF_MAX_SEGMENTS_PER_REQUEST, &gref_head) < 0) {
-		gnttab_request_free_callback(
-			&info->callback,
-			blkif_restart_queue_callback,
-			info,
-			BLKIF_MAX_SEGMENTS_PER_REQUEST);
-		return 1;
+	use_pers_gnts = info->feature_persistent;
+
+	if (info->persistent_grants_c < BLKIF_MAX_SEGMENTS_PER_REQUEST) {
+		new_pers_gnts = 1;
+		if (gnttab_alloc_grant_references(
+			    BLKIF_MAX_SEGMENTS_PER_REQUEST, &gref_head) < 0) {
+			gnttab_request_free_callback(
+				&info->callback,
+				blkif_restart_queue_callback,
+				info,
+				BLKIF_MAX_SEGMENTS_PER_REQUEST);
+			return 1;
+		}
 	} else
+		new_pers_gnts = 0;
 
 	/* Fill out a communications ring structure. */
 	ring_req = RING_GET_REQUEST(&info->ring, info->ring.req_prod_pvt);
@@ -341,20 +366,66 @@ static int blkif_queue_request(struct request *req)
 		       BLKIF_MAX_SEGMENTS_PER_REQUEST);
 
 		for_each_sg(info->sg, sg, ring_req->u.rw.nr_segments, i) {
-			buffer_mfn = pfn_to_mfn(page_to_pfn(sg_page(sg)));
 			fsect = sg->offset >> 9;
 			lsect = fsect + (sg->length >> 9) - 1;
-			/* install a grant reference. */
-			ref = gnttab_claim_grant_reference(&gref_head);
-			BUG_ON(ref == -ENOSPC);
 
-			gnttab_grant_foreign_access_ref(
+			if (use_pers_gnts && info->persistent_grants_c) {
+				gnt_list_entry = info->persistent_grants_front;
+
+				info->persistent_grants_front =
+					info->persistent_grants_front->tail;
+				ref = gnt_list_entry->gref;
+				buffer_mfn = pfn_to_mfn(gnt_list_entry->frame);
+				info->persistent_grants_c--;
+			} else {
+				ref = gnttab_claim_grant_reference(&gref_head);
+				BUG_ON(ref == -ENOSPC);
+
+				if (use_pers_gnts) {
+					gnt_list_entry =
+						kmalloc(sizeof(struct gnt_list),
+								 GFP_ATOMIC);
+					if (!gnt_list_entry)
+						return -ENOMEM;
+
+					shared_page = alloc_page(GFP_ATOMIC);
+					if (!shared_page)
+						return -ENOMEM;
+
+					gnt_list_entry->frame =
+						page_to_pfn(shared_page);
+					gnt_list_entry->gref = ref;
+				} else
+					shared_page = sg_page(sg);
+
+				buffer_mfn = pfn_to_mfn(page_to_pfn(
+								shared_page));
+				gnttab_grant_foreign_access_ref(
 					ref,
 					info->xbdev->otherend_id,
 					buffer_mfn,
-					rq_data_dir(req));
+					!use_pers_gnts && rq_data_dir(req));
+			}
+
+			if (use_pers_gnts)
+				info->shadow[id].grants_used[i] =
+					gnt_list_entry;
+
+			if (use_pers_gnts && rq_data_dir(req)) {
+				shared_data = kmap_atomic(
+					pfn_to_page(gnt_list_entry->frame));
+				bvec_data = kmap_atomic(sg_page(sg));
+
+				memcpy(shared_data + sg->offset,
+				       bvec_data   + sg->offset,
+				       sg->length);
+
+				kunmap_atomic(bvec_data);
+				kunmap_atomic(shared_data);
+			}
 
 			info->shadow[id].frame[i] = mfn_to_pfn(buffer_mfn);
+
 			ring_req->u.rw.seg[i] =
 					(struct blkif_request_segment) {
 						.gref       = ref,
@@ -368,7 +439,8 @@ static int blkif_queue_request(struct request *req)
 	/* Keep a private copy so we can reissue requests when recovering. */
 	info->shadow[id].req = *ring_req;
 
-	gnttab_free_grant_references(gref_head);
+	if (new_pers_gnts)
+		gnttab_free_grant_references(gref_head);
 
 	return 0;
 }
@@ -480,12 +552,13 @@ static int xlvbd_init_blk_queue(struct gendisk *gd, u16 sector_size)
 static void xlvbd_flush(struct blkfront_info *info)
 {
 	blk_queue_flush(info->rq, info->feature_flush);
-	printk(KERN_INFO "blkfront: %s: %s: %s\n",
+	printk(KERN_INFO "blkfront: %s: %s: %s. Persistent=%d\n",
 	       info->gd->disk_name,
 	       info->flush_op == BLKIF_OP_WRITE_BARRIER ?
 		"barrier" : (info->flush_op == BLKIF_OP_FLUSH_DISKCACHE ?
 		"flush diskcache" : "barrier or flush"),
-	       info->feature_flush ? "enabled" : "disabled");
+	       info->feature_flush ? "enabled" : "disabled",
+	    info->feature_persistent);
 }
 
 static int xen_translate_vdev(int vdevice, int *minor, unsigned int *offset)
@@ -707,6 +780,8 @@ static void blkif_restart_queue(struct work_struct *work)
 
 static void blkif_free(struct blkfront_info *info, int suspend)
 {
+	struct gnt_list *pers_gnt;
+
 	/* Prevent new requests being issued until we fix things up. */
 	spin_lock_irq(&info->io_lock);
 	info->connected = suspend ?
@@ -714,6 +789,15 @@ static void blkif_free(struct blkfront_info *info, int suspend)
 	/* No more blkif_request(). */
 	if (info->rq)
 		blk_stop_queue(info->rq);
+
+	/* Remove all persistent grants */
+	while (info->persistent_grants_front) {
+		pers_gnt = info->persistent_grants_front;
+		info->persistent_grants_front = pers_gnt->tail;
+		gnttab_end_foreign_access(pers_gnt->gref, 0, 0UL);
+		kfree(pers_gnt);
+	}
+
 	/* No more gnttab callback work. */
 	gnttab_cancel_free_callback(&info->callback);
 	spin_unlock_irq(&info->io_lock);
@@ -734,13 +818,44 @@ static void blkif_free(struct blkfront_info *info, int suspend)
 
 }
 
-static void blkif_completion(struct blk_shadow *s)
+static void blkif_completion(struct blk_shadow *s, struct blkfront_info *info,
+			     struct blkif_response *bret)
 {
 	int i;
-	/* Do not let BLKIF_OP_DISCARD as nr_segment is in the same place
-	 * flag. */
-	for (i = 0; i < s->req.u.rw.nr_segments; i++)
-		gnttab_end_foreign_access(s->req.u.rw.seg[i].gref, 0, 0UL);
+	struct gnt_list *new_gnt_list_entry;
+	struct bio_vec *bvec;
+	struct req_iterator iter;
+	unsigned long flags;
+	char *bvec_data;
+	void *shared_data;
+
+	i = 0;
+	if (info->feature_persistent == 0) {
+		/* Do not let BLKIF_OP_DISCARD as nr_segment is in the same
+		 * place flag. */
+		for (i = 0; i < s->req.u.rw.nr_segments; i++)
+			gnttab_end_foreign_access(s->req.u.rw.seg[i].gref,
+						  0, 0UL);
+		return;
+	}
+
+	if (bret->operation == BLKIF_OP_READ)
+		rq_for_each_segment(bvec, s->request, iter) {
+			shared_data = kmap_atomic
+				(pfn_to_page(s->grants_used[i++]->frame));
+			bvec_data = bvec_kmap_irq(bvec, &flags);
+			memcpy(bvec_data, shared_data + bvec->bv_offset,
+			       bvec->bv_len);
+			bvec_kunmap_irq(bvec_data, &flags);
+			kunmap_atomic(shared_data);
+		}
+	/* Add the persistent grant into the list of free grants */
+	for (i = 0; i < s->req.u.rw.nr_segments; i++) {
+		new_gnt_list_entry = s->grants_used[i];
+		new_gnt_list_entry->tail = info->persistent_grants_front;
+		info->persistent_grants_front = new_gnt_list_entry;
+		info->persistent_grants_c++;
+	}
 }
 
 static irqreturn_t blkif_interrupt(int irq, void *dev_id)
@@ -783,7 +898,7 @@ static irqreturn_t blkif_interrupt(int irq, void *dev_id)
 		req  = info->shadow[id].request;
 
 		if (bret->operation != BLKIF_OP_DISCARD)
-			blkif_completion(&info->shadow[id]);
+			blkif_completion(&info->shadow[id], info, bret);
 
 		if (add_id_to_freelist(info, id)) {
 			WARN(1, "%s: response to %s (id %ld) couldn't be recycled!\n",
@@ -943,6 +1058,12 @@ again:
 		message = "writing protocol";
 		goto abort_transaction;
 	}
+	err = xenbus_printf(xbt, dev->nodename,
+			    "feature-persistent-grants", "%d", 1);
+	if (err) {
+		message = "Writing persistent grants front feature";
+		goto abort_transaction;
+	}
 
 	err = xenbus_transaction_end(xbt, 0);
 	if (err) {
@@ -1030,6 +1151,7 @@ static int blkfront_probe(struct xenbus_device *dev,
 	spin_lock_init(&info->io_lock);
 	info->xbdev = dev;
 	info->vdevice = vdevice;
+	info->persistent_grants_c = 0;
 	info->connected = BLKIF_STATE_DISCONNECTED;
 	INIT_WORK(&info->work, blkif_restart_queue);
 
@@ -1094,6 +1216,7 @@ static int blkif_recover(struct blkfront_info *info)
 					req->u.rw.seg[j].gref,
 					info->xbdev->otherend_id,
 					pfn_to_mfn(info->shadow[req->u.rw.id].frame[j]),
+					!info->feature_persistent &&
 					rq_data_dir(info->shadow[req->u.rw.id].request));
 		}
 		info->shadow[req->u.rw.id].req = *req;
@@ -1226,7 +1349,7 @@ static void blkfront_connect(struct blkfront_info *info)
 	unsigned long sector_size;
 	unsigned int binfo;
 	int err;
-	int barrier, flush, discard;
+	int barrier, flush, discard, persistent;
 
 	switch (info->connected) {
 	case BLKIF_STATE_CONNECTED:
@@ -1297,6 +1420,19 @@ static void blkfront_connect(struct blkfront_info *info)
 		info->flush_op = BLKIF_OP_FLUSH_DISKCACHE;
 	}
 
+	/*
+	 * Are we dealing with an old blkback that will unmap
+	 * all grefs?
+	 */
+	err = xenbus_gather(XBT_NIL, info->xbdev->otherend,
+			    "feature-persistent-grants", "%d", &persistent,
+			    NULL);
+
+	if (err)
+		info->feature_persistent = 0;
+	else
+		info->feature_persistent = persistent;
+
 	err = xenbus_gather(XBT_NIL, info->xbdev->otherend,
 			    "feature-discard", "%d", &discard,
 			    NULL);
diff --git a/include/xen/interface/io/blkif.h b/include/xen/interface/io/blkif.h
index ee338bf..cd267a9b 100644
--- a/include/xen/interface/io/blkif.h
+++ b/include/xen/interface/io/blkif.h
@@ -109,6 +109,15 @@ typedef uint64_t blkif_sector_t;
  */
 #define BLKIF_MAX_SEGMENTS_PER_REQUEST 11
 
+/*
+ * Maximum number of persistent grants that can be mapped by Dom0 for each
+ * interface. This is set to be the size of the ring, as this is a limit on
+ * the number of requests that can be inflight at any one time. 256 imposes
+ * an overhead of 11MB of mapped kernel space per interface.
+ */
+#define BLKIF_MAX_PERS_REQUESTS_PER_DEV 256
+
+
 struct blkif_request_rw {
 	uint8_t        nr_segments;  /* number of segments                   */
 	blkif_vdev_t   handle;       /* only for read/write requests         */
-- 
1.7.9.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 19 10:52:19 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Sep 2012 10: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 1TEHsv-0007sb-Mn; Wed, 19 Sep 2012 10:52:01 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <oliver.chick@citrix.com>) id 1TEHsu-0007sM-Pn
	for xen-devel@lists.xen.org; Wed, 19 Sep 2012 10:52:01 +0000
X-Env-Sender: oliver.chick@citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1348051913!6027896!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNzU4MDA=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28378 invoked from network); 19 Sep 2012 10:51:54 -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;
	19 Sep 2012 10:51:54 -0000
X-IronPort-AV: E=Sophos;i="4.80,447,1344211200"; d="scan'208";a="208530654"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Sep 2012 10:51:52 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 19 Sep 2012 06:51:52 -0400
Received: from leeni.uk.xensource.com ([10.80.2.50]
	helo=oliverchick-Precision-WorkStation-T3400.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<oliver.chick@citrix.com>)	id 1TEHsm-0003oR-2R;
	Wed, 19 Sep 2012 11:51:52 +0100
From: Oliver Chick <oliver.chick@citrix.com>
To: xen-devel@lists.xen.org,
	konrad.wilk@oracle.com
Date: Wed, 19 Sep 2012 11:51:27 +0100
Message-ID: <1348051887-21885-1-git-send-email-oliver.chick@citrix.com>
X-Mailer: git-send-email 1.7.9.5
MIME-Version: 1.0
Cc: Oliver Chick <oliver.chick@citrix.com>, linux-kernel@vger.kernel.org
Subject: [Xen-devel] [PATCH] Persistent grant maps for xen blk drivers
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This patch implements persistent grants for the xen-blk{front,back}
mechanism. The effect of this change is to reduce the number of unmap
operations performed, since they cause a (costly) TLB shootdown. This
allows the I/O performance to scale better when a large number of VMs
are performing I/O.

Previously, the blkfront driver was supplied a bvec[] from the request
queue. This was granted to dom0; dom0 performed the I/O and wrote
directly into the grant-mapped memory and unmapped it; blkfront then
removed foreign access for that grant. The cost of unmapping scales
badly with the number of CPUs in Dom0. An experiment showed that when
Dom0 has 24 VCPUs, and guests are performing parallel I/O to a
ramdisk, the IPIs from performing unmap's is a bottleneck at 5 guests
(at which point 650,000 IOPS are being performed in total). If more
than 5 guests are used, the performance declines. By 10 guests, only
400,000 IOPS are being performed.

This patch improves performance by only unmapping when the connection
between blkfront and back is broken.

On startup, blk{front,back} use xenbus to communicate their ability to
perform 'feature-persistent'. Iff both ends have this ability,
persistent mode is used.

To perform a read, in persistent mode, blkfront uses a separate pool
of pages that it maps to dom0. When a request comes in, blkfront
transmutes the request so that blkback will write into one of these
free pages. Blkback keeps note of which grefs it has already
mapped. When a new ring request comes to blkback, it looks to see if
it has already mapped that page. If so, it will not map it again. If
the page hasn't been previously mapped, it is mapped now, and a record
is kept of this mapping. Blkback proceeds as usual. When blkfront is
notified that blkback has completed a request, it memcpy's from the
shared memory, into the bvec supplied. A record that the {gref, page}
tuple is mapped, and not inflight is kept.

Writes are similar, except that the memcpy is peformed from the
supplied bvecs, into the shared pages, before the request is put onto
the ring.

Blkback has to store a mapping of grefs=>{page mapped to by gref} in
an array. As the grefs are not known apriori, and provide no
guarantees on their ordering, we have to perform a linear search
through this array to find the page, for every gref we receive. The
overhead of this is low, however future work might want to use a more
efficient data structure to reduce this O(n) operation.

We (ijc, and myself) have introduced a new constant,
BLKIF_MAX_PERS_REQUESTS_PER_DEV. This is to prevent a malicious guest
from attempting a DoS, by supplying fresh grefs, causing the Dom0
kernel from to map excessively. This is currently set to 256---the
maximum number of entires in the ring. As the number of inflight
requests <= size of ring, 256 is also the maximum sensible size. This
introduces a maximum overhead of 11MB of mapped memory, per block
device. In practice, we don't typically use about 60 of these. If the
guest exceeds the 256 limit, it is either buggy or malicious. We treat
this in one of two ways:
1) If we have mapped <
BLKIF_MAX_SEGMENTS_PER_REQUEST * BLKIF_MAX_PERS_REQUESTS_PER_DEV
pages, we will persistently map the grefs. This can occur is previous
requests have not used all BLKIF_MAX_SEGMENTS_PER_REQUEST segments.
2) Otherwise, we revert to non-persistent grants for all future grefs.

In writing this patch, the question arrises as to if the additional
cost of performing memcpys in the guest (to/from the pool of granted
pages) outweigh the gains of not performing TLB shootdowns. The answer
to that question is `no'. There appears to be very little, if any
additional cost to the guest of using persistent grants. There is
perhaps a small saving, from the reduced number of hypercalls
performed in granting, and ending foreign access.


Signed-off-by: Oliver Chick <oliver.chick@citrix.com>
---
 drivers/block/xen-blkback/blkback.c |  149 +++++++++++++++++++++++++---
 drivers/block/xen-blkback/common.h  |   16 +++
 drivers/block/xen-blkback/xenbus.c  |   21 +++-
 drivers/block/xen-blkfront.c        |  186 ++++++++++++++++++++++++++++++-----
 include/xen/interface/io/blkif.h    |    9 ++
 5 files changed, 338 insertions(+), 43 deletions(-)

diff --git a/drivers/block/xen-blkback/blkback.c b/drivers/block/xen-blkback/blkback.c
index 73f196c..f95dee9 100644
--- a/drivers/block/xen-blkback/blkback.c
+++ b/drivers/block/xen-blkback/blkback.c
@@ -78,6 +78,7 @@ struct pending_req {
 	unsigned short		operation;
 	int			status;
 	struct list_head	free_list;
+	u8			is_pers;
 };
 
 #define BLKBACK_INVALID_HANDLE (~0)
@@ -128,6 +129,24 @@ static int dispatch_rw_block_io(struct xen_blkif *blkif,
 static void make_response(struct xen_blkif *blkif, u64 id,
 			  unsigned short op, int st);
 
+static void add_pers_gnt(struct pers_gnt *pers_gnt, struct xen_blkif *blkif)
+{
+	BUG_ON(blkif->pers_gnt_c >= BLKIF_MAX_PERS_REQUESTS_PER_DEV *
+	       BLKIF_MAX_SEGMENTS_PER_REQUEST);
+	blkif->pers_gnts[blkif->pers_gnt_c++] = pers_gnt;
+}
+
+static struct pers_gnt *get_pers_gnt(struct xen_blkif *blkif,
+				     grant_ref_t gref)
+{
+	int i;
+
+	for (i = 0; i < blkif->pers_gnt_c; i++)
+		if (gref == blkif->pers_gnts[i]->gnt)
+			return blkif->pers_gnts[i];
+	return NULL;
+}
+
 /*
  * Retrieve from the 'pending_reqs' a free pending_req structure to be used.
  */
@@ -274,6 +293,12 @@ int xen_blkif_schedule(void *arg)
 {
 	struct xen_blkif *blkif = arg;
 	struct xen_vbd *vbd = &blkif->vbd;
+	struct gnttab_unmap_grant_ref unmap[BLKIF_MAX_SEGMENTS_PER_REQUEST];
+	struct page *pages[BLKIF_MAX_SEGMENTS_PER_REQUEST];
+	struct pers_gnt *pers_gnt;
+	int i;
+	int ret = 0;
+	int segs_to_unmap;
 
 	xen_blkif_get(blkif);
 
@@ -301,6 +326,29 @@ int xen_blkif_schedule(void *arg)
 			print_stats(blkif);
 	}
 
+	/* Free all persistent grant pages */
+
+	while (segs_to_unmap = min(BLKIF_MAX_SEGMENTS_PER_REQUEST,
+				 blkif->pers_gnt_c)) {
+
+		for (i = 0; i < segs_to_unmap; i++) {
+			pers_gnt = blkif->pers_gnts[blkif->pers_gnt_c - i - 1];
+
+			gnttab_set_unmap_op(&unmap[i],
+					    pfn_to_kaddr(page_to_pfn(
+							     pers_gnt->page)),
+					    GNTMAP_host_map,
+					    pers_gnt->handle);
+
+			pages[i] = pers_gnt->page;
+		}
+
+		ret = gnttab_unmap_refs(unmap, pages, segs_to_unmap, false);
+		BUG_ON(ret);
+
+		blkif->pers_gnt_c -= segs_to_unmap;
+
+	}
+
 	if (log_stats)
 		print_stats(blkif);
 
@@ -343,13 +391,28 @@ static void xen_blkbk_unmap(struct pending_req *req)
 
 static int xen_blkbk_map(struct blkif_request *req,
 			 struct pending_req *pending_req,
-			 struct seg_buf seg[])
+			 struct seg_buf seg[],
+			 struct page *pages[])
 {
 	struct gnttab_map_grant_ref map[BLKIF_MAX_SEGMENTS_PER_REQUEST];
+	struct pers_gnt *new_pers_gnts[BLKIF_MAX_SEGMENTS_PER_REQUEST];
+	struct pers_gnt *pers_gnts[BLKIF_MAX_SEGMENTS_PER_REQUEST];
+	struct page *pages_to_gnt[BLKIF_MAX_SEGMENTS_PER_REQUEST];
+	struct pers_gnt *pers_gnt;
+	phys_addr_t addr;
 	int i;
+	int new_map;
 	int nseg = req->u.rw.nr_segments;
+	int segs_to_init = 0;
 	int ret = 0;
+	int use_pers_gnts;
 
+	use_pers_gnts = (pending_req->blkif->can_grant_persist &&
+			 pending_req->blkif->pers_gnt_c <
+			 BLKIF_MAX_SEGMENTS_PER_REQUEST *
+			 BLKIF_MAX_PERS_REQUESTS_PER_DEV);
+
+	pending_req->is_pers = use_pers_gnts;
 	/*
 	 * Fill out preq.nr_sects with proper amount of sectors, and setup
 	 * assign map[..] with the PFN of the page in our domain with the
@@ -358,36 +421,87 @@ static int xen_blkbk_map(struct blkif_request *req,
 	for (i = 0; i < nseg; i++) {
 		uint32_t flags;
 
+		if (use_pers_gnts) {
+			pers_gnt = get_pers_gnt(pending_req->blkif,
+						req->u.rw.seg[i].gref);
+			if (!pers_gnt) {
+				new_map = 1;
+				pers_gnt = kmalloc(sizeof(struct pers_gnt),
+						   GFP_KERNEL);
+				if (!pers_gnt)
+					return -ENOMEM;
+				pers_gnt->page = alloc_page(GFP_KERNEL);
+				if (!pers_gnt->page)
+					return -ENOMEM;
+				pers_gnt->gnt = req->u.rw.seg[i].gref;
+
+				pages_to_gnt[segs_to_init] = pers_gnt->page;
+				new_pers_gnts[segs_to_init] = pers_gnt;
+
+				add_pers_gnt(pers_gnt, pending_req->blkif);
+
+			} else {
+				new_map = 0;
+			}
+			pages[i] = pers_gnt->page;
+			addr = (unsigned long) pfn_to_kaddr(
+				page_to_pfn(pers_gnt->page));
+			pers_gnts[i] = pers_gnt;
+		} else {
+			new_map = 1;
+			pages[i] = blkbk->pending_page(pending_req, i);
+			addr = vaddr(pending_req, i);
+			pages_to_gnt[i] = blkbk->pending_page(pending_req, i);
+		}
+
 		flags = GNTMAP_host_map;
-		if (pending_req->operation != BLKIF_OP_READ)
+		if (!use_pers_gnts && (pending_req->operation != BLKIF_OP_READ))
 			flags |= GNTMAP_readonly;
-		gnttab_set_map_op(&map[i], vaddr(pending_req, i), flags,
-				  req->u.rw.seg[i].gref,
-				  pending_req->blkif->domid);
+		if (new_map) {
+			gnttab_set_map_op(&map[segs_to_init++], addr,
+					  flags, req->u.rw.seg[i].gref,
+					  pending_req->blkif->domid);
+		}
 	}
 
-	ret = gnttab_map_refs(map, NULL, &blkbk->pending_page(pending_req, 0), nseg);
-	BUG_ON(ret);
+	if (segs_to_init) {
+		ret = gnttab_map_refs(map, NULL, pages_to_gnt, segs_to_init);
+		BUG_ON(ret);
+	}
 
 	/*
 	 * Now swizzle the MFN in our domain with the MFN from the other domain
 	 * so that when we access vaddr(pending_req,i) it has the contents of
 	 * the page from the other domain.
 	 */
-	for (i = 0; i < nseg; i++) {
+	for (i = 0; i < segs_to_init; i++) {
 		if (unlikely(map[i].status != 0)) {
 			pr_debug(DRV_PFX "invalid buffer -- could not remap it\n");
 			map[i].handle = BLKBACK_INVALID_HANDLE;
 			ret |= 1;
 		}
 
-		pending_handle(pending_req, i) = map[i].handle;
+		if (use_pers_gnts) {
+			/* store the `out' values from map */
+		    pending_req->blkif->pers_gnts
+			[pending_req->blkif->pers_gnt_c - segs_to_init +
+			 i]->handle = map[i].handle;
+			new_pers_gnts[i]->dev_bus_addr = map[i].dev_bus_addr;
+		}
 
 		if (ret)
 			continue;
-
-		seg[i].buf  = map[i].dev_bus_addr |
-			(req->u.rw.seg[i].first_sect << 9);
+	}
+	for (i = 0; i < nseg; i++) {
+		if (use_pers_gnts) {
+			pending_handle(pending_req, i) = pers_gnts[i]->handle;
+			seg[i].buf = pers_gnts[i]->dev_bus_addr |
+				(req->u.rw.seg[i].first_sect << 9);
+		} else {
+			pending_handle(pending_req, i) = map[i].handle;
+			seg[i].buf = map[i].dev_bus_addr |
+				(req->u.rw.seg[i].first_sect << 9);
+		}
 	}
 	return ret;
 }
@@ -468,7 +582,8 @@ static void __end_block_io_op(struct pending_req *pending_req, int error)
 	 * the proper response on the ring.
 	 */
 	if (atomic_dec_and_test(&pending_req->pendcnt)) {
-		xen_blkbk_unmap(pending_req);
+		if (!pending_req->is_pers)
+			xen_blkbk_unmap(pending_req);
 		make_response(pending_req->blkif, pending_req->id,
 			      pending_req->operation, pending_req->status);
 		xen_blkif_put(pending_req->blkif);
@@ -590,6 +705,7 @@ static int dispatch_rw_block_io(struct xen_blkif *blkif,
 	int operation;
 	struct blk_plug plug;
 	bool drain = false;
+	struct page *pages[BLKIF_MAX_SEGMENTS_PER_REQUEST];
 
 	switch (req->operation) {
 	case BLKIF_OP_READ:
@@ -676,7 +792,7 @@ static int dispatch_rw_block_io(struct xen_blkif *blkif,
 	 * the hypercall to unmap the grants - that is all done in
 	 * xen_blkbk_unmap.
 	 */
-	if (xen_blkbk_map(req, pending_req, seg))
+	if (xen_blkbk_map(req, pending_req, seg, pages))
 		goto fail_flush;
 
 	/*
@@ -688,7 +804,7 @@ static int dispatch_rw_block_io(struct xen_blkif *blkif,
 	for (i = 0; i < nseg; i++) {
 		while ((bio == NULL) ||
 		       (bio_add_page(bio,
-				     blkbk->pending_page(pending_req, i),
+				     pages[i],
 				     seg[i].nsec << 9,
 				     seg[i].buf & ~PAGE_MASK) == 0)) {
 
@@ -743,7 +859,8 @@ static int dispatch_rw_block_io(struct xen_blkif *blkif,
 	return 0;
 
  fail_flush:
-	xen_blkbk_unmap(pending_req);
+	if (!blkif->can_grant_persist)
+		xen_blkbk_unmap(pending_req);
  fail_response:
 	/* Haven't submitted any bio's yet. */
 	make_response(blkif, req->u.rw.id, req->operation, BLKIF_RSP_ERROR);
diff --git a/drivers/block/xen-blkback/common.h b/drivers/block/xen-blkback/common.h
index 9ad3b5e..1ecb709 100644
--- a/drivers/block/xen-blkback/common.h
+++ b/drivers/block/xen-blkback/common.h
@@ -47,6 +47,8 @@
 #define DPRINTK(fmt, args...)				\
 	pr_debug(DRV_PFX "(%s:%d) " fmt ".\n",		\
 		 __func__, __LINE__, ##args)
+#define BLKIF_MAX_PERS_REQUESTS_PER_DEV 256
+
 
 
 /* Not a real protocol.  Used to generate ring structs which contain
@@ -164,6 +166,14 @@ struct xen_vbd {
 
 struct backend_info;
 
+
+struct pers_gnt {
+	struct page *page;
+	grant_ref_t gnt;
+	uint32_t handle;
+	uint64_t dev_bus_addr;
+};
+
 struct xen_blkif {
 	/* Unique identifier for this interface. */
 	domid_t			domid;
@@ -190,6 +200,12 @@ struct xen_blkif {
 	struct task_struct	*xenblkd;
 	unsigned int		waiting_reqs;
 
+	/* frontend feature information */
+	u8			can_grant_persist:1;
+	struct pers_gnt		*pers_gnts[BLKIF_MAX_PERS_REQUESTS_PER_DEV *
+					  BLKIF_MAX_SEGMENTS_PER_REQUEST];
+	unsigned int		pers_gnt_c;
+
 	/* statistics */
 	unsigned long		st_print;
 	int			st_rd_req;
diff --git a/drivers/block/xen-blkback/xenbus.c b/drivers/block/xen-blkback/xenbus.c
index 4f66171..dc58cc4 100644
--- a/drivers/block/xen-blkback/xenbus.c
+++ b/drivers/block/xen-blkback/xenbus.c
@@ -681,6 +681,13 @@ again:
 		goto abort;
 	}
 
+	err = xenbus_printf(xbt, dev->nodename, "feature-persistent-grants",
+			    "%d", 1);
+	if (err) {
+		xenbus_dev_fatal(dev, err, "writing persistent capability");
+		goto abort;
+	}
+
 	/* FIXME: use a typename instead */
 	err = xenbus_printf(xbt, dev->nodename, "info", "%u",
 			    be->blkif->vbd.type |
@@ -721,6 +728,7 @@ static int connect_ring(struct backend_info *be)
 	struct xenbus_device *dev = be->dev;
 	unsigned long ring_ref;
 	unsigned int evtchn;
+	u8 pers_grants;
 	char protocol[64] = "";
 	int err;
 
@@ -750,8 +758,17 @@ static int connect_ring(struct backend_info *be)
 		xenbus_dev_fatal(dev, err, "unknown fe protocol %s", protocol);
 		return -1;
 	}
-	pr_info(DRV_PFX "ring-ref %ld, event-channel %d, protocol %d (%s)\n",
-		ring_ref, evtchn, be->blkif->blk_protocol, protocol);
+	err = xenbus_gather(XBT_NIL, dev->otherend,
+			    "feature-persistent-grants", "%d",
+			    &pers_grants, NULL);
+	if (err)
+		pers_grants = 0;
+
+	be->blkif->can_grant_persist = pers_grants;
+
+	pr_info(DRV_PFX "ring-ref %ld, event-channel %d, protocol %d (%s) persistent %d\n",
+		ring_ref, evtchn, be->blkif->blk_protocol, protocol,
+		pers_grants);
 
 	/* Map the shared frame, irq etc. */
 	err = xen_blkif_map(be->blkif, ring_ref, evtchn);
diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c
index e4fb337..c1cc5fe 100644
--- a/drivers/block/xen-blkfront.c
+++ b/drivers/block/xen-blkfront.c
@@ -68,6 +68,13 @@ struct blk_shadow {
 	struct blkif_request req;
 	struct request *request;
 	unsigned long frame[BLKIF_MAX_SEGMENTS_PER_REQUEST];
+	struct gnt_list *grants_used[BLKIF_MAX_SEGMENTS_PER_REQUEST];
+};
+
+struct gnt_list {
+	grant_ref_t gref;
+	unsigned long frame;
+	struct gnt_list *tail;
 };
 
 static DEFINE_MUTEX(blkfront_mutex);
@@ -97,11 +104,14 @@ struct blkfront_info
 	struct work_struct work;
 	struct gnttab_free_callback callback;
 	struct blk_shadow shadow[BLK_RING_SIZE];
+	struct gnt_list *persistent_grants_front;
+	unsigned int persistent_grants_c;
 	unsigned long shadow_free;
 	unsigned int feature_flush;
 	unsigned int flush_op;
 	unsigned int feature_discard:1;
 	unsigned int feature_secdiscard:1;
+	unsigned int feature_persistent:1;
 	unsigned int discard_granularity;
 	unsigned int discard_alignment;
 	int is_ready;
@@ -286,22 +296,37 @@ static int blkif_queue_request(struct request *req)
 	struct blkif_request *ring_req;
 	unsigned long id;
 	unsigned int fsect, lsect;
-	int i, ref;
+	int i, ref, use_pers_gnts, new_pers_gnts;
 	grant_ref_t gref_head;
+	struct bio_vec *bvecs[BLKIF_MAX_SEGMENTS_PER_REQUEST];
+	struct bio_vec *bvec;
+	struct req_iterator iter;
+	char *bvec_data;
+	void *shared_data;
+	unsigned long flags;
+	struct page *shared_page;
+	struct gnt_list *gnt_list_entry;
 	struct scatterlist *sg;
 
 	if (unlikely(info->connected != BLKIF_STATE_CONNECTED))
 		return 1;
 
-	if (gnttab_alloc_grant_references(
-		BLKIF_MAX_SEGMENTS_PER_REQUEST, &gref_head) < 0) {
-		gnttab_request_free_callback(
-			&info->callback,
-			blkif_restart_queue_callback,
-			info,
-			BLKIF_MAX_SEGMENTS_PER_REQUEST);
-		return 1;
+	use_pers_gnts = info->feature_persistent;
+
+	if (info->persistent_grants_c < BLKIF_MAX_SEGMENTS_PER_REQUEST) {
+		new_pers_gnts = 1;
+		if (gnttab_alloc_grant_references(
+			    BLKIF_MAX_SEGMENTS_PER_REQUEST, &gref_head) < 0) {
+			gnttab_request_free_callback(
+				&info->callback,
+				blkif_restart_queue_callback,
+				info,
+				BLKIF_MAX_SEGMENTS_PER_REQUEST);
+			return 1;
+		}
 	} else
+		new_pers_gnts = 0;
 
 	/* Fill out a communications ring structure. */
 	ring_req = RING_GET_REQUEST(&info->ring, info->ring.req_prod_pvt);
@@ -341,20 +366,66 @@ static int blkif_queue_request(struct request *req)
 		       BLKIF_MAX_SEGMENTS_PER_REQUEST);
 
 		for_each_sg(info->sg, sg, ring_req->u.rw.nr_segments, i) {
-			buffer_mfn = pfn_to_mfn(page_to_pfn(sg_page(sg)));
 			fsect = sg->offset >> 9;
 			lsect = fsect + (sg->length >> 9) - 1;
-			/* install a grant reference. */
-			ref = gnttab_claim_grant_reference(&gref_head);
-			BUG_ON(ref == -ENOSPC);
 
-			gnttab_grant_foreign_access_ref(
+			if (use_pers_gnts && info->persistent_grants_c) {
+				gnt_list_entry = info->persistent_grants_front;
+
+				info->persistent_grants_front =
+					info->persistent_grants_front->tail;
+				ref = gnt_list_entry->gref;
+				buffer_mfn = pfn_to_mfn(gnt_list_entry->frame);
+				info->persistent_grants_c--;
+			} else {
+				ref = gnttab_claim_grant_reference(&gref_head);
+				BUG_ON(ref == -ENOSPC);
+
+				if (use_pers_gnts) {
+					gnt_list_entry =
+						kmalloc(sizeof(struct gnt_list),
+								 GFP_ATOMIC);
+					if (!gnt_list_entry)
+						return -ENOMEM;
+
+					shared_page = alloc_page(GFP_ATOMIC);
+					if (!shared_page)
+						return -ENOMEM;
+
+					gnt_list_entry->frame =
+						page_to_pfn(shared_page);
+					gnt_list_entry->gref = ref;
+				} else
+					shared_page = sg_page(sg);
+
+				buffer_mfn = pfn_to_mfn(page_to_pfn(
+								shared_page));
+				gnttab_grant_foreign_access_ref(
 					ref,
 					info->xbdev->otherend_id,
 					buffer_mfn,
-					rq_data_dir(req));
+					!use_pers_gnts && rq_data_dir(req));
+			}
+
+			if (use_pers_gnts)
+				info->shadow[id].grants_used[i] =
+					gnt_list_entry;
+
+			if (use_pers_gnts && rq_data_dir(req)) {
+				shared_data = kmap_atomic(
+					pfn_to_page(gnt_list_entry->frame));
+				bvec_data = kmap_atomic(sg_page(sg));
+
+				memcpy(shared_data + sg->offset,
+				       bvec_data   + sg->offset,
+				       sg->length);
+
+				kunmap_atomic(bvec_data);
+				kunmap_atomic(shared_data);
+			}
 
 			info->shadow[id].frame[i] = mfn_to_pfn(buffer_mfn);
+
 			ring_req->u.rw.seg[i] =
 					(struct blkif_request_segment) {
 						.gref       = ref,
@@ -368,7 +439,8 @@ static int blkif_queue_request(struct request *req)
 	/* Keep a private copy so we can reissue requests when recovering. */
 	info->shadow[id].req = *ring_req;
 
-	gnttab_free_grant_references(gref_head);
+	if (new_pers_gnts)
+		gnttab_free_grant_references(gref_head);
 
 	return 0;
 }
@@ -480,12 +552,13 @@ static int xlvbd_init_blk_queue(struct gendisk *gd, u16 sector_size)
 static void xlvbd_flush(struct blkfront_info *info)
 {
 	blk_queue_flush(info->rq, info->feature_flush);
-	printk(KERN_INFO "blkfront: %s: %s: %s\n",
+	printk(KERN_INFO "blkfront: %s: %s: %s. Persistent=%d\n",
 	       info->gd->disk_name,
 	       info->flush_op == BLKIF_OP_WRITE_BARRIER ?
 		"barrier" : (info->flush_op == BLKIF_OP_FLUSH_DISKCACHE ?
 		"flush diskcache" : "barrier or flush"),
-	       info->feature_flush ? "enabled" : "disabled");
+	       info->feature_flush ? "enabled" : "disabled",
+	    info->feature_persistent);
 }
 
 static int xen_translate_vdev(int vdevice, int *minor, unsigned int *offset)
@@ -707,6 +780,8 @@ static void blkif_restart_queue(struct work_struct *work)
 
 static void blkif_free(struct blkfront_info *info, int suspend)
 {
+	struct gnt_list *pers_gnt;
+
 	/* Prevent new requests being issued until we fix things up. */
 	spin_lock_irq(&info->io_lock);
 	info->connected = suspend ?
@@ -714,6 +789,15 @@ static void blkif_free(struct blkfront_info *info, int suspend)
 	/* No more blkif_request(). */
 	if (info->rq)
 		blk_stop_queue(info->rq);
+
+	/* Remove all persistent grants */
+	while (info->persistent_grants_front) {
+		pers_gnt = info->persistent_grants_front;
+		info->persistent_grants_front = pers_gnt->tail;
+		gnttab_end_foreign_access(pers_gnt->gref, 0, 0UL);
+		kfree(pers_gnt);
+	}
+
 	/* No more gnttab callback work. */
 	gnttab_cancel_free_callback(&info->callback);
 	spin_unlock_irq(&info->io_lock);
@@ -734,13 +818,44 @@ static void blkif_free(struct blkfront_info *info, int suspend)
 
 }
 
-static void blkif_completion(struct blk_shadow *s)
+static void blkif_completion(struct blk_shadow *s, struct blkfront_info *info,
+			     struct blkif_response *bret)
 {
 	int i;
-	/* Do not let BLKIF_OP_DISCARD as nr_segment is in the same place
-	 * flag. */
-	for (i = 0; i < s->req.u.rw.nr_segments; i++)
-		gnttab_end_foreign_access(s->req.u.rw.seg[i].gref, 0, 0UL);
+	struct gnt_list *new_gnt_list_entry;
+	struct bio_vec *bvec;
+	struct req_iterator iter;
+	unsigned long flags;
+	char *bvec_data;
+	void *shared_data;
+
+	i = 0;
+	if (info->feature_persistent == 0) {
+		/* Do not let BLKIF_OP_DISCARD as nr_segment is in the same
+		 * place flag. */
+		for (i = 0; i < s->req.u.rw.nr_segments; i++)
+			gnttab_end_foreign_access(s->req.u.rw.seg[i].gref,
+						  0, 0UL);
+		return;
+	}
+
+	if (bret->operation == BLKIF_OP_READ)
+		rq_for_each_segment(bvec, s->request, iter) {
+			shared_data = kmap_atomic
+				(pfn_to_page(s->grants_used[i++]->frame));
+			bvec_data = bvec_kmap_irq(bvec, &flags);
+			memcpy(bvec_data, shared_data + bvec->bv_offset,
+			       bvec->bv_len);
+			bvec_kunmap_irq(bvec_data, &flags);
+			kunmap_atomic(shared_data);
+		}
+	/* Add the persistent grant into the list of free grants */
+	for (i = 0; i < s->req.u.rw.nr_segments; i++) {
+		new_gnt_list_entry = s->grants_used[i];
+		new_gnt_list_entry->tail = info->persistent_grants_front;
+		info->persistent_grants_front = new_gnt_list_entry;
+		info->persistent_grants_c++;
+	}
 }
 
 static irqreturn_t blkif_interrupt(int irq, void *dev_id)
@@ -783,7 +898,7 @@ static irqreturn_t blkif_interrupt(int irq, void *dev_id)
 		req  = info->shadow[id].request;
 
 		if (bret->operation != BLKIF_OP_DISCARD)
-			blkif_completion(&info->shadow[id]);
+			blkif_completion(&info->shadow[id], info, bret);
 
 		if (add_id_to_freelist(info, id)) {
 			WARN(1, "%s: response to %s (id %ld) couldn't be recycled!\n",
@@ -943,6 +1058,12 @@ again:
 		message = "writing protocol";
 		goto abort_transaction;
 	}
+	err = xenbus_printf(xbt, dev->nodename,
+			    "feature-persistent-grants", "%d", 1);
+	if (err) {
+		message = "Writing persistent grants front feature";
+		goto abort_transaction;
+	}
 
 	err = xenbus_transaction_end(xbt, 0);
 	if (err) {
@@ -1030,6 +1151,7 @@ static int blkfront_probe(struct xenbus_device *dev,
 	spin_lock_init(&info->io_lock);
 	info->xbdev = dev;
 	info->vdevice = vdevice;
+	info->persistent_grants_c = 0;
 	info->connected = BLKIF_STATE_DISCONNECTED;
 	INIT_WORK(&info->work, blkif_restart_queue);
 
@@ -1094,6 +1216,7 @@ static int blkif_recover(struct blkfront_info *info)
 					req->u.rw.seg[j].gref,
 					info->xbdev->otherend_id,
 					pfn_to_mfn(info->shadow[req->u.rw.id].frame[j]),
+					!info->feature_persistent &&
 					rq_data_dir(info->shadow[req->u.rw.id].request));
 		}
 		info->shadow[req->u.rw.id].req = *req;
@@ -1226,7 +1349,7 @@ static void blkfront_connect(struct blkfront_info *info)
 	unsigned long sector_size;
 	unsigned int binfo;
 	int err;
-	int barrier, flush, discard;
+	int barrier, flush, discard, persistent;
 
 	switch (info->connected) {
 	case BLKIF_STATE_CONNECTED:
@@ -1297,6 +1420,19 @@ static void blkfront_connect(struct blkfront_info *info)
 		info->flush_op = BLKIF_OP_FLUSH_DISKCACHE;
 	}
 
+	/*
+	 * Are we dealing with an old blkback that will unmap
+	 * all grefs?
+	 */
+	err = xenbus_gather(XBT_NIL, info->xbdev->otherend,
+			    "feature-persistent-grants", "%d", &persistent,
+			    NULL);
+
+	if (err)
+		info->feature_persistent = 0;
+	else
+		info->feature_persistent = persistent;
+
 	err = xenbus_gather(XBT_NIL, info->xbdev->otherend,
 			    "feature-discard", "%d", &discard,
 			    NULL);
diff --git a/include/xen/interface/io/blkif.h b/include/xen/interface/io/blkif.h
index ee338bf..cd267a9b 100644
--- a/include/xen/interface/io/blkif.h
+++ b/include/xen/interface/io/blkif.h
@@ -109,6 +109,15 @@ typedef uint64_t blkif_sector_t;
  */
 #define BLKIF_MAX_SEGMENTS_PER_REQUEST 11
 
+/*
+ * Maximum number of persistent grants that can be mapped by Dom0 for each
+ * interface. This is set to be the size of the ring, as this is a limit on
+ * the number of requests that can be inflight at any one time. 256 imposes
+ * an overhead of 11MB of mapped kernel space per interface.
+ */
+#define BLKIF_MAX_PERS_REQUESTS_PER_DEV 256
+
+
 struct blkif_request_rw {
 	uint8_t        nr_segments;  /* number of segments                   */
 	blkif_vdev_t   handle;       /* only for read/write requests         */
-- 
1.7.9.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 19 11:05:55 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Sep 2012 11:05:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TEI60-0008Cw-F6; Wed, 19 Sep 2012 11:05:32 +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 1TEI5y-0008Cr-8n
	for xen-devel@lists.xen.org; Wed, 19 Sep 2012 11:05:30 +0000
Received: from [85.158.139.211:51229] by server-12.bemta-5.messagelabs.com id
	3A/44-22167-9F6A9505; Wed, 19 Sep 2012 11:05:29 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-14.tower-206.messagelabs.com!1348052726!19100740!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNzU4MDA=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19920 invoked from network); 19 Sep 2012 11:05:27 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-14.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Sep 2012 11:05:27 -0000
X-IronPort-AV: E=Sophos;i="4.80,447,1344211200"; d="scan'208";a="208531418"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Sep 2012 11:05:25 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 19 Sep 2012 07:05:25 -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 1TEI5s-0004Gv-Pk;
	Wed, 19 Sep 2012 12:05:24 +0100
From: Anthony PERARD <anthony.perard@citrix.com>
To: QEMU-devel <qemu-devel@nongnu.org>
Date: Wed, 19 Sep 2012 12:05:05 +0100
Message-ID: <1348052705-16370-1-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.12
MIME-Version: 1.0
Cc: Anthony PERARD <anthony.perard@citrix.com>, "Zhang,
	Yang Z" <yang.z.zhang@intel.com>,
	Stefano Stabellini <stefano.stabellini@citrix.com>,
	Xen Devel <xen-devel@lists.xen.org>
Subject: [Xen-devel] [PATCH] xen: Fix,
	no unplug of pt device by platform 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 Xen platform device will unplug any NICs if requested by the guest (PVonHVM)
including a NIC that would have been passthrough. This patch makes sure that a
passthrough device will not be unplug.

Reported-by: "Zhang, Yang Z" <yang.z.zhang@intel.com>
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>

---
 hw/xen_platform.c | 8 ++++++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/hw/xen_platform.c b/hw/xen_platform.c
index 0d6c2ff..956dbfe 100644
--- a/hw/xen_platform.c
+++ b/hw/xen_platform.c
@@ -85,8 +85,10 @@ static void log_writeb(PCIXenPlatformState *s, char val)
 
 static void unplug_nic(PCIBus *b, PCIDevice *d, void *o)
 {
+    /* We have to ignore passthrough devices */
     if (pci_get_word(d->config + PCI_CLASS_DEVICE) ==
-            PCI_CLASS_NETWORK_ETHERNET) {
+            PCI_CLASS_NETWORK_ETHERNET
+            && strcmp(d->name, "xen-pci-passthrough") != 0) {
         qdev_free(&d->qdev);
     }
 }
@@ -98,8 +100,10 @@ static void pci_unplug_nics(PCIBus *bus)
 
 static void unplug_disks(PCIBus *b, PCIDevice *d, void *o)
 {
+    /* We have to ignore passthrough devices */
     if (pci_get_word(d->config + PCI_CLASS_DEVICE) ==
-            PCI_CLASS_STORAGE_IDE) {
+            PCI_CLASS_STORAGE_IDE
+            && strcmp(d->name, "xen-pci-passthrough") != 0) {
         qdev_unplug(&(d->qdev), 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 Wed Sep 19 11:05:55 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Sep 2012 11:05:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TEI60-0008Cw-F6; Wed, 19 Sep 2012 11:05:32 +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 1TEI5y-0008Cr-8n
	for xen-devel@lists.xen.org; Wed, 19 Sep 2012 11:05:30 +0000
Received: from [85.158.139.211:51229] by server-12.bemta-5.messagelabs.com id
	3A/44-22167-9F6A9505; Wed, 19 Sep 2012 11:05:29 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-14.tower-206.messagelabs.com!1348052726!19100740!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNzU4MDA=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19920 invoked from network); 19 Sep 2012 11:05:27 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-14.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Sep 2012 11:05:27 -0000
X-IronPort-AV: E=Sophos;i="4.80,447,1344211200"; d="scan'208";a="208531418"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Sep 2012 11:05:25 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 19 Sep 2012 07:05:25 -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 1TEI5s-0004Gv-Pk;
	Wed, 19 Sep 2012 12:05:24 +0100
From: Anthony PERARD <anthony.perard@citrix.com>
To: QEMU-devel <qemu-devel@nongnu.org>
Date: Wed, 19 Sep 2012 12:05:05 +0100
Message-ID: <1348052705-16370-1-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.12
MIME-Version: 1.0
Cc: Anthony PERARD <anthony.perard@citrix.com>, "Zhang,
	Yang Z" <yang.z.zhang@intel.com>,
	Stefano Stabellini <stefano.stabellini@citrix.com>,
	Xen Devel <xen-devel@lists.xen.org>
Subject: [Xen-devel] [PATCH] xen: Fix,
	no unplug of pt device by platform 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 Xen platform device will unplug any NICs if requested by the guest (PVonHVM)
including a NIC that would have been passthrough. This patch makes sure that a
passthrough device will not be unplug.

Reported-by: "Zhang, Yang Z" <yang.z.zhang@intel.com>
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>

---
 hw/xen_platform.c | 8 ++++++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/hw/xen_platform.c b/hw/xen_platform.c
index 0d6c2ff..956dbfe 100644
--- a/hw/xen_platform.c
+++ b/hw/xen_platform.c
@@ -85,8 +85,10 @@ static void log_writeb(PCIXenPlatformState *s, char val)
 
 static void unplug_nic(PCIBus *b, PCIDevice *d, void *o)
 {
+    /* We have to ignore passthrough devices */
     if (pci_get_word(d->config + PCI_CLASS_DEVICE) ==
-            PCI_CLASS_NETWORK_ETHERNET) {
+            PCI_CLASS_NETWORK_ETHERNET
+            && strcmp(d->name, "xen-pci-passthrough") != 0) {
         qdev_free(&d->qdev);
     }
 }
@@ -98,8 +100,10 @@ static void pci_unplug_nics(PCIBus *bus)
 
 static void unplug_disks(PCIBus *b, PCIDevice *d, void *o)
 {
+    /* We have to ignore passthrough devices */
     if (pci_get_word(d->config + PCI_CLASS_DEVICE) ==
-            PCI_CLASS_STORAGE_IDE) {
+            PCI_CLASS_STORAGE_IDE
+            && strcmp(d->name, "xen-pci-passthrough") != 0) {
         qdev_unplug(&(d->qdev), 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 Wed Sep 19 11:25:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Sep 2012 11:25:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TEIOk-0008PA-Bk; Wed, 19 Sep 2012 11:24:54 +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 1TEIOj-0008P5-6O
	for xen-devel@lists.xen.org; Wed, 19 Sep 2012 11:24:53 +0000
Received: from [85.158.139.83:35835] by server-4.bemta-5.messagelabs.com id
	51/4B-23042-48BA9505; Wed, 19 Sep 2012 11:24:52 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1348053891!31178597!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-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13876 invoked from network); 19 Sep 2012 11:24: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;
	19 Sep 2012 11:24:51 -0000
Received: by eaac13 with SMTP id c13so291335eaa.32
	for <xen-devel@lists.xen.org>; Wed, 19 Sep 2012 04:24: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:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=tYf27CEnHMtCPUX6CwdxJ2BUSYfeHaYJSjNxbjN9yLk=;
	b=Dn9nSPgaob/KYstCKZQiqtjiAv+uar4wLdIK9E7U63cnVCblbq87wIl8+oSg1PWBUz
	IOBCQa6wRlPV1hCp4OMfySAx2qn/tT8w6TgwhPZ/ltGkZjqOdjEhAEusqGgiPVSydjOp
	osiHQLJgd7bGUg6Nhxa4oju45WG3kEf5q2Vxh3MaNqFoTS/kz19gWXz8pmvnNo1P8WXL
	nVuDDateHmQqmiiPq+kGNc7XQYVIOczIjoNBn71xJvL527T0qHNRuNyY9AMZGrHRwJQs
	ccQvU76k4l0k7i7vk+892CXFNcagpr/V5J7LmH1zK0+Np2oITIXntgh/r/5EdtqFn9Qf
	XYkQ==
Received: by 10.14.220.134 with SMTP id o6mr3190851eep.35.1348053891214;
	Wed, 19 Sep 2012 04:24:51 -0700 (PDT)
Received: from [192.168.1.69] (host86-167-82-156.range86-167.btcentralplus.com.
	[86.167.82.156])
	by mx.google.com with ESMTPS id e42sm6422536eem.8.2012.09.19.04.24.48
	(version=SSLv3 cipher=OTHER); Wed, 19 Sep 2012 04:24:50 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Wed, 19 Sep 2012 12:24:47 +0100
From: Keir Fraser <keir.xen@gmail.com>
To: Jan Beulich <JBeulich@suse.com>,
	xen-devel <xen-devel@lists.xen.org>
Message-ID: <CC7F6A0F.3F24D%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [PATCH] x86: tighten checks in
	XEN_DOMCTL_memory_mapping handler
Thread-Index: Ac2WWV/49ZKZxNZMJkC135nF6yrHbQ==
In-Reply-To: <5059BF86020000780009C485@nat28.tlf.novell.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] [PATCH] x86: tighten checks in
 XEN_DOMCTL_memory_mapping handler
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 19/09/2012 11:50, "Jan Beulich" <JBeulich@suse.com> wrote:

> Properly checking the MFN implies knowing the physical address width
> supported by the platform, so to obtain this consistently the
> respective code gets moved out of the MTRR subdir.
> 
> Btw., the model specific workaround in that code is likely unnecessary
> - I believe those CPU models don't support 64-bit mode. But I wasn't
> able to formally verify this, so I preferred to retain that code for
> now.
> 
> But domctl code here also was lacking other error checks (as was,
> looking at it again from that angle) the XEN_DOMCTL_ioport_mapping one.
> Besides adding the missing checks, printing is also added for the case
> where revoking access permissions didn't work (as that may have
> implications for the host operator, e.g. wanting to not pass through
> affected devices to another guest until the one previously using them
> did actually die).
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Acked-by: Keir Fraser <keir@xen.org>

> --- a/xen/arch/x86/cpu/common.c
> +++ b/xen/arch/x86/cpu/common.c
> @@ -36,6 +36,8 @@ integer_param("cpuid_mask_ext_edx", opt_
>  
>  struct cpu_dev * cpu_devs[X86_VENDOR_NUM] = {};
>  
> +unsigned int paddr_bits __read_mostly = 36;
> +
>  /*
>   * Default host IA32_CR_PAT value to cover all memory types.
>   * BIOS usually sets it to 0x07040600070406.
> @@ -265,6 +267,8 @@ static void __cpuinit generic_identify(s
> }
> if ( xlvl >= 0x80000004 )
> get_model_name(c); /* Default name */
> +  if ( xlvl >= 0x80000008 )
> +   paddr_bits = cpuid_eax(0x80000008) & 0xff;
> }
>  
> /* Intel-defined flags: level 0x00000007 */
> --- a/xen/arch/x86/cpu/intel.c
> +++ b/xen/arch/x86/cpu/intel.c
> @@ -144,6 +144,11 @@ void __devinit early_intel_workaround(st
>       c->cpuid_level);
> }
> }
> +
> + /* CPUID workaround for Intel 0F33/0F34 CPU */
> + if (boot_cpu_data.x86 == 0xF && boot_cpu_data.x86_model == 3 &&
> +     (boot_cpu_data.x86_mask == 3 || boot_cpu_data.x86_mask == 4))
> +  paddr_bits = 36;
>  }
>  
>  /*
> --- a/xen/arch/x86/cpu/mtrr/main.c
> +++ b/xen/arch/x86/cpu/mtrr/main.c
> @@ -559,8 +559,6 @@ struct mtrr_value {
> unsigned long lsize;
>  };
>  
> -unsigned int paddr_bits __read_mostly = 36;
> -
>  /**
>   * mtrr_bp_init - initialize mtrrs on the boot CPU
>   *
> @@ -572,31 +570,8 @@ void __init mtrr_bp_init(void)
>  {
> if (cpu_has_mtrr) {
> mtrr_if = &generic_mtrr_ops;
> -  size_or_mask = 0xff000000; /* 36 bits */
> -  size_and_mask = 0x00f00000;
> -
> -  /* This is an AMD specific MSR, but we assume(hope?) that
> -     Intel will implement it to when they extend the address
> -     bus of the Xeon. */
> -  if (cpuid_eax(0x80000000) >= 0x80000008) {
> -   paddr_bits = cpuid_eax(0x80000008) & 0xff;
> -   /* CPUID workaround for Intel 0F33/0F34 CPU */
> -   if (boot_cpu_data.x86_vendor == X86_VENDOR_INTEL &&
> -       boot_cpu_data.x86 == 0xF &&
> -       boot_cpu_data.x86_model == 0x3 &&
> -       (boot_cpu_data.x86_mask == 0x3 ||
> -        boot_cpu_data.x86_mask == 0x4))
> -    paddr_bits = 36;
> -
> -   size_or_mask = ~((1ULL << (paddr_bits - PAGE_SHIFT)) - 1);
> -   size_and_mask = ~size_or_mask & 0xfffff00000ULL;
> -  } else if (boot_cpu_data.x86_vendor == X86_VENDOR_CENTAUR &&
> -      boot_cpu_data.x86 == 6) {
> -   /* VIA C* family have Intel style MTRRs, but
> -      don't support PAE */
> -   size_or_mask = 0xfff00000; /* 32 bits */
> -   size_and_mask = 0;
> -  }
> +  size_or_mask = ~((1ULL << (paddr_bits - PAGE_SHIFT)) - 1);
> +  size_and_mask = ~size_or_mask & 0xfffff00000ULL;
> }
>  
> if (mtrr_if) {
> --- a/xen/arch/x86/domctl.c
> +++ b/xen/arch/x86/domctl.c
> @@ -825,10 +825,12 @@ long arch_do_domctl(
>          unsigned long mfn = domctl->u.memory_mapping.first_mfn;
>          unsigned long nr_mfns = domctl->u.memory_mapping.nr_mfns;
>          int add = domctl->u.memory_mapping.add_mapping;
> -        int i;
> +        unsigned long i;
>  
>          ret = -EINVAL;
> -        if ( (mfn + nr_mfns - 1) < mfn ) /* wrap? */
> +        if ( (mfn + nr_mfns - 1) < mfn || /* wrap? */
> +             ((mfn | (mfn + nr_mfns - 1)) >> (paddr_bits - PAGE_SHIFT)) ||
> +             (gfn + nr_mfns - 1) < gfn ) /* wrap? */
>              break;
>  
>          ret = -EPERM;
> @@ -853,8 +855,25 @@ long arch_do_domctl(
>                     d->domain_id, gfn, mfn, nr_mfns);
>  
>              ret = iomem_permit_access(d, mfn, mfn + nr_mfns - 1);
> -            for ( i = 0; i < nr_mfns; i++ )
> -                set_mmio_p2m_entry(d, gfn+i, _mfn(mfn+i));
> +            if ( !ret && paging_mode_translate(d) )
> +            {
> +                for ( i = 0; !ret && i < nr_mfns; i++ )
> +                    if ( !set_mmio_p2m_entry(d, gfn + i, _mfn(mfn + i)) )
> +                        ret = -EIO;
> +                if ( ret )
> +                {
> +                    printk(XENLOG_G_WARNING
> +                           "memory_map:fail: dom%d gfn=%lx mfn=%lx\n",
> +                           d->domain_id, gfn + i, mfn + i);
> +                    while ( i-- )
> +                        clear_mmio_p2m_entry(d, gfn + i);
> +                    if ( iomem_deny_access(d, mfn, mfn + nr_mfns - 1) &&
> +                         IS_PRIV(current->domain) )
> +                        printk(XENLOG_ERR
> +                               "memory_map: failed to deny dom%d access to
> [%lx,%lx]\n",
> +                               d->domain_id, mfn, mfn + nr_mfns - 1);
> +                }
> +            }
>          }
>          else
>          {
> @@ -862,9 +881,17 @@ long arch_do_domctl(
>                     "memory_map:remove: dom%d gfn=%lx mfn=%lx nr=%lx\n",
>                     d->domain_id, gfn, mfn, nr_mfns);
>  
> -            for ( i = 0; i < nr_mfns; i++ )
> -                clear_mmio_p2m_entry(d, gfn+i);
> +            if ( paging_mode_translate(d) )
> +                for ( i = 0; i < nr_mfns; i++ )
> +                    add |= !clear_mmio_p2m_entry(d, gfn + i);
>              ret = iomem_deny_access(d, mfn, mfn + nr_mfns - 1);
> +            if ( !ret && add )
> +                ret = -EIO;
> +            if ( ret && IS_PRIV(current->domain) )
> +                printk(XENLOG_ERR
> +                       "memory_map: error %ld %s dom%d access to
> [%lx,%lx]\n",
> +                       ret, add ? "removing" : "denying", d->domain_id,
> +                       mfn, mfn + nr_mfns - 1);
>          }
>  
>          rcu_unlock_domain(d);
> @@ -926,12 +953,23 @@ long arch_do_domctl(
>              if ( !found )
>              {
>                  g2m_ioport = xmalloc(struct g2m_ioport);
> +                if ( !g2m_ioport )
> +                    ret = -ENOMEM;
> +            }
> +            if ( !found && !ret )
> +            {
>                  g2m_ioport->gport = fgp;
>                  g2m_ioport->mport = fmp;
>                  g2m_ioport->np = np;
>                  list_add_tail(&g2m_ioport->list, &hd->g2m_ioport_list);
>              }
> -            ret = ioports_permit_access(d, fmp, fmp + np - 1);
> +            if ( !ret )
> +                ret = ioports_permit_access(d, fmp, fmp + np - 1);
> +            if ( ret && !found && g2m_ioport )
> +            {
> +                list_del(&g2m_ioport->list);
> +                xfree(g2m_ioport);
> +            }
>          }
>          else
>          {
> @@ -946,6 +984,10 @@ long arch_do_domctl(
>                      break;
>                  }
>              ret = ioports_deny_access(d, fmp, fmp + np - 1);
> +            if ( ret && IS_PRIV(current->domain) )
> +                printk(XENLOG_ERR
> +                       "ioport_map: error %ld denying dom%d access to
> [%x,%x]\n",
> +                       ret, d->domain_id, fmp, fmp + np - 1);
>          }
>          rcu_unlock_domain(d);
>      }
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 19 11:25:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Sep 2012 11:25:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TEIOk-0008PA-Bk; Wed, 19 Sep 2012 11:24:54 +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 1TEIOj-0008P5-6O
	for xen-devel@lists.xen.org; Wed, 19 Sep 2012 11:24:53 +0000
Received: from [85.158.139.83:35835] by server-4.bemta-5.messagelabs.com id
	51/4B-23042-48BA9505; Wed, 19 Sep 2012 11:24:52 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1348053891!31178597!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-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13876 invoked from network); 19 Sep 2012 11:24: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;
	19 Sep 2012 11:24:51 -0000
Received: by eaac13 with SMTP id c13so291335eaa.32
	for <xen-devel@lists.xen.org>; Wed, 19 Sep 2012 04:24: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:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=tYf27CEnHMtCPUX6CwdxJ2BUSYfeHaYJSjNxbjN9yLk=;
	b=Dn9nSPgaob/KYstCKZQiqtjiAv+uar4wLdIK9E7U63cnVCblbq87wIl8+oSg1PWBUz
	IOBCQa6wRlPV1hCp4OMfySAx2qn/tT8w6TgwhPZ/ltGkZjqOdjEhAEusqGgiPVSydjOp
	osiHQLJgd7bGUg6Nhxa4oju45WG3kEf5q2Vxh3MaNqFoTS/kz19gWXz8pmvnNo1P8WXL
	nVuDDateHmQqmiiPq+kGNc7XQYVIOczIjoNBn71xJvL527T0qHNRuNyY9AMZGrHRwJQs
	ccQvU76k4l0k7i7vk+892CXFNcagpr/V5J7LmH1zK0+Np2oITIXntgh/r/5EdtqFn9Qf
	XYkQ==
Received: by 10.14.220.134 with SMTP id o6mr3190851eep.35.1348053891214;
	Wed, 19 Sep 2012 04:24:51 -0700 (PDT)
Received: from [192.168.1.69] (host86-167-82-156.range86-167.btcentralplus.com.
	[86.167.82.156])
	by mx.google.com with ESMTPS id e42sm6422536eem.8.2012.09.19.04.24.48
	(version=SSLv3 cipher=OTHER); Wed, 19 Sep 2012 04:24:50 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Wed, 19 Sep 2012 12:24:47 +0100
From: Keir Fraser <keir.xen@gmail.com>
To: Jan Beulich <JBeulich@suse.com>,
	xen-devel <xen-devel@lists.xen.org>
Message-ID: <CC7F6A0F.3F24D%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [PATCH] x86: tighten checks in
	XEN_DOMCTL_memory_mapping handler
Thread-Index: Ac2WWV/49ZKZxNZMJkC135nF6yrHbQ==
In-Reply-To: <5059BF86020000780009C485@nat28.tlf.novell.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] [PATCH] x86: tighten checks in
 XEN_DOMCTL_memory_mapping handler
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 19/09/2012 11:50, "Jan Beulich" <JBeulich@suse.com> wrote:

> Properly checking the MFN implies knowing the physical address width
> supported by the platform, so to obtain this consistently the
> respective code gets moved out of the MTRR subdir.
> 
> Btw., the model specific workaround in that code is likely unnecessary
> - I believe those CPU models don't support 64-bit mode. But I wasn't
> able to formally verify this, so I preferred to retain that code for
> now.
> 
> But domctl code here also was lacking other error checks (as was,
> looking at it again from that angle) the XEN_DOMCTL_ioport_mapping one.
> Besides adding the missing checks, printing is also added for the case
> where revoking access permissions didn't work (as that may have
> implications for the host operator, e.g. wanting to not pass through
> affected devices to another guest until the one previously using them
> did actually die).
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Acked-by: Keir Fraser <keir@xen.org>

> --- a/xen/arch/x86/cpu/common.c
> +++ b/xen/arch/x86/cpu/common.c
> @@ -36,6 +36,8 @@ integer_param("cpuid_mask_ext_edx", opt_
>  
>  struct cpu_dev * cpu_devs[X86_VENDOR_NUM] = {};
>  
> +unsigned int paddr_bits __read_mostly = 36;
> +
>  /*
>   * Default host IA32_CR_PAT value to cover all memory types.
>   * BIOS usually sets it to 0x07040600070406.
> @@ -265,6 +267,8 @@ static void __cpuinit generic_identify(s
> }
> if ( xlvl >= 0x80000004 )
> get_model_name(c); /* Default name */
> +  if ( xlvl >= 0x80000008 )
> +   paddr_bits = cpuid_eax(0x80000008) & 0xff;
> }
>  
> /* Intel-defined flags: level 0x00000007 */
> --- a/xen/arch/x86/cpu/intel.c
> +++ b/xen/arch/x86/cpu/intel.c
> @@ -144,6 +144,11 @@ void __devinit early_intel_workaround(st
>       c->cpuid_level);
> }
> }
> +
> + /* CPUID workaround for Intel 0F33/0F34 CPU */
> + if (boot_cpu_data.x86 == 0xF && boot_cpu_data.x86_model == 3 &&
> +     (boot_cpu_data.x86_mask == 3 || boot_cpu_data.x86_mask == 4))
> +  paddr_bits = 36;
>  }
>  
>  /*
> --- a/xen/arch/x86/cpu/mtrr/main.c
> +++ b/xen/arch/x86/cpu/mtrr/main.c
> @@ -559,8 +559,6 @@ struct mtrr_value {
> unsigned long lsize;
>  };
>  
> -unsigned int paddr_bits __read_mostly = 36;
> -
>  /**
>   * mtrr_bp_init - initialize mtrrs on the boot CPU
>   *
> @@ -572,31 +570,8 @@ void __init mtrr_bp_init(void)
>  {
> if (cpu_has_mtrr) {
> mtrr_if = &generic_mtrr_ops;
> -  size_or_mask = 0xff000000; /* 36 bits */
> -  size_and_mask = 0x00f00000;
> -
> -  /* This is an AMD specific MSR, but we assume(hope?) that
> -     Intel will implement it to when they extend the address
> -     bus of the Xeon. */
> -  if (cpuid_eax(0x80000000) >= 0x80000008) {
> -   paddr_bits = cpuid_eax(0x80000008) & 0xff;
> -   /* CPUID workaround for Intel 0F33/0F34 CPU */
> -   if (boot_cpu_data.x86_vendor == X86_VENDOR_INTEL &&
> -       boot_cpu_data.x86 == 0xF &&
> -       boot_cpu_data.x86_model == 0x3 &&
> -       (boot_cpu_data.x86_mask == 0x3 ||
> -        boot_cpu_data.x86_mask == 0x4))
> -    paddr_bits = 36;
> -
> -   size_or_mask = ~((1ULL << (paddr_bits - PAGE_SHIFT)) - 1);
> -   size_and_mask = ~size_or_mask & 0xfffff00000ULL;
> -  } else if (boot_cpu_data.x86_vendor == X86_VENDOR_CENTAUR &&
> -      boot_cpu_data.x86 == 6) {
> -   /* VIA C* family have Intel style MTRRs, but
> -      don't support PAE */
> -   size_or_mask = 0xfff00000; /* 32 bits */
> -   size_and_mask = 0;
> -  }
> +  size_or_mask = ~((1ULL << (paddr_bits - PAGE_SHIFT)) - 1);
> +  size_and_mask = ~size_or_mask & 0xfffff00000ULL;
> }
>  
> if (mtrr_if) {
> --- a/xen/arch/x86/domctl.c
> +++ b/xen/arch/x86/domctl.c
> @@ -825,10 +825,12 @@ long arch_do_domctl(
>          unsigned long mfn = domctl->u.memory_mapping.first_mfn;
>          unsigned long nr_mfns = domctl->u.memory_mapping.nr_mfns;
>          int add = domctl->u.memory_mapping.add_mapping;
> -        int i;
> +        unsigned long i;
>  
>          ret = -EINVAL;
> -        if ( (mfn + nr_mfns - 1) < mfn ) /* wrap? */
> +        if ( (mfn + nr_mfns - 1) < mfn || /* wrap? */
> +             ((mfn | (mfn + nr_mfns - 1)) >> (paddr_bits - PAGE_SHIFT)) ||
> +             (gfn + nr_mfns - 1) < gfn ) /* wrap? */
>              break;
>  
>          ret = -EPERM;
> @@ -853,8 +855,25 @@ long arch_do_domctl(
>                     d->domain_id, gfn, mfn, nr_mfns);
>  
>              ret = iomem_permit_access(d, mfn, mfn + nr_mfns - 1);
> -            for ( i = 0; i < nr_mfns; i++ )
> -                set_mmio_p2m_entry(d, gfn+i, _mfn(mfn+i));
> +            if ( !ret && paging_mode_translate(d) )
> +            {
> +                for ( i = 0; !ret && i < nr_mfns; i++ )
> +                    if ( !set_mmio_p2m_entry(d, gfn + i, _mfn(mfn + i)) )
> +                        ret = -EIO;
> +                if ( ret )
> +                {
> +                    printk(XENLOG_G_WARNING
> +                           "memory_map:fail: dom%d gfn=%lx mfn=%lx\n",
> +                           d->domain_id, gfn + i, mfn + i);
> +                    while ( i-- )
> +                        clear_mmio_p2m_entry(d, gfn + i);
> +                    if ( iomem_deny_access(d, mfn, mfn + nr_mfns - 1) &&
> +                         IS_PRIV(current->domain) )
> +                        printk(XENLOG_ERR
> +                               "memory_map: failed to deny dom%d access to
> [%lx,%lx]\n",
> +                               d->domain_id, mfn, mfn + nr_mfns - 1);
> +                }
> +            }
>          }
>          else
>          {
> @@ -862,9 +881,17 @@ long arch_do_domctl(
>                     "memory_map:remove: dom%d gfn=%lx mfn=%lx nr=%lx\n",
>                     d->domain_id, gfn, mfn, nr_mfns);
>  
> -            for ( i = 0; i < nr_mfns; i++ )
> -                clear_mmio_p2m_entry(d, gfn+i);
> +            if ( paging_mode_translate(d) )
> +                for ( i = 0; i < nr_mfns; i++ )
> +                    add |= !clear_mmio_p2m_entry(d, gfn + i);
>              ret = iomem_deny_access(d, mfn, mfn + nr_mfns - 1);
> +            if ( !ret && add )
> +                ret = -EIO;
> +            if ( ret && IS_PRIV(current->domain) )
> +                printk(XENLOG_ERR
> +                       "memory_map: error %ld %s dom%d access to
> [%lx,%lx]\n",
> +                       ret, add ? "removing" : "denying", d->domain_id,
> +                       mfn, mfn + nr_mfns - 1);
>          }
>  
>          rcu_unlock_domain(d);
> @@ -926,12 +953,23 @@ long arch_do_domctl(
>              if ( !found )
>              {
>                  g2m_ioport = xmalloc(struct g2m_ioport);
> +                if ( !g2m_ioport )
> +                    ret = -ENOMEM;
> +            }
> +            if ( !found && !ret )
> +            {
>                  g2m_ioport->gport = fgp;
>                  g2m_ioport->mport = fmp;
>                  g2m_ioport->np = np;
>                  list_add_tail(&g2m_ioport->list, &hd->g2m_ioport_list);
>              }
> -            ret = ioports_permit_access(d, fmp, fmp + np - 1);
> +            if ( !ret )
> +                ret = ioports_permit_access(d, fmp, fmp + np - 1);
> +            if ( ret && !found && g2m_ioport )
> +            {
> +                list_del(&g2m_ioport->list);
> +                xfree(g2m_ioport);
> +            }
>          }
>          else
>          {
> @@ -946,6 +984,10 @@ long arch_do_domctl(
>                      break;
>                  }
>              ret = ioports_deny_access(d, fmp, fmp + np - 1);
> +            if ( ret && IS_PRIV(current->domain) )
> +                printk(XENLOG_ERR
> +                       "ioport_map: error %ld denying dom%d access to
> [%x,%x]\n",
> +                       ret, d->domain_id, fmp, fmp + np - 1);
>          }
>          rcu_unlock_domain(d);
>      }
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 19 11:28:22 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Sep 2012 11:28:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TEIRm-0008VK-VZ; Wed, 19 Sep 2012 11:28:02 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1TEIRl-0008V9-4u
	for xen-devel@lists.xen.org; Wed, 19 Sep 2012 11:28:01 +0000
Received: from [85.158.143.35:46057] by server-1.bemta-4.messagelabs.com id
	7C/90-05684-04CA9505; Wed, 19 Sep 2012 11:28:00 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1348054077!7204819!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDc2MDk3OQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4252 invoked from network); 19 Sep 2012 11:27:58 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-4.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 19 Sep 2012 11:27:58 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q8JBRr8p006193
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 19 Sep 2012 11:27:53 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
	q8JBRq8i004214
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 19 Sep 2012 11:27:53 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
	q8JBRqhu014063; Wed, 19 Sep 2012 06:27:52 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 19 Sep 2012 04:27:52 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 87C0C402EC; Wed, 19 Sep 2012 07:17:01 -0400 (EDT)
Date: Wed, 19 Sep 2012 07:17:01 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Oliver Chick <oliver.chick@citrix.com>
Message-ID: <20120919111701.GB12367@phenom.dumpdata.com>
References: <1348051887-21885-1-git-send-email-oliver.chick@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1348051887-21885-1-git-send-email-oliver.chick@citrix.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: linux-kernel@vger.kernel.org, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] Persistent grant maps for xen blk drivers
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Sep 19, 2012 at 11:51:27AM +0100, Oliver Chick wrote:
> This patch implements persistent grants for the xen-blk{front,back}
> mechanism. The effect of this change is to reduce the number of unmap
> operations performed, since they cause a (costly) TLB shootdown. This
> allows the I/O performance to scale better when a large number of VMs
> are performing I/O.
> 
> Previously, the blkfront driver was supplied a bvec[] from the request
> queue. This was granted to dom0; dom0 performed the I/O and wrote
> directly into the grant-mapped memory and unmapped it; blkfront then
> removed foreign access for that grant. The cost of unmapping scales
> badly with the number of CPUs in Dom0. An experiment showed that when
> Dom0 has 24 VCPUs, and guests are performing parallel I/O to a
> ramdisk, the IPIs from performing unmap's is a bottleneck at 5 guests
> (at which point 650,000 IOPS are being performed in total). If more
> than 5 guests are used, the performance declines. By 10 guests, only
> 400,000 IOPS are being performed.
> 
> This patch improves performance by only unmapping when the connection
> between blkfront and back is broken.
> 
> On startup, blk{front,back} use xenbus to communicate their ability to
> perform 'feature-persistent'. Iff both ends have this ability,
> persistent mode is used.
> 
> To perform a read, in persistent mode, blkfront uses a separate pool
> of pages that it maps to dom0. When a request comes in, blkfront
> transmutes the request so that blkback will write into one of these
> free pages. Blkback keeps note of which grefs it has already
> mapped. When a new ring request comes to blkback, it looks to see if
> it has already mapped that page. If so, it will not map it again. If
> the page hasn't been previously mapped, it is mapped now, and a record
> is kept of this mapping. Blkback proceeds as usual. When blkfront is
> notified that blkback has completed a request, it memcpy's from the
> shared memory, into the bvec supplied. A record that the {gref, page}
> tuple is mapped, and not inflight is kept.
> 
> Writes are similar, except that the memcpy is peformed from the
> supplied bvecs, into the shared pages, before the request is put onto
> the ring.
> 
> Blkback has to store a mapping of grefs=>{page mapped to by gref} in
> an array. As the grefs are not known apriori, and provide no
> guarantees on their ordering, we have to perform a linear search
> through this array to find the page, for every gref we receive. The
> overhead of this is low, however future work might want to use a more
> efficient data structure to reduce this O(n) operation.
> 
> We (ijc, and myself) have introduced a new constant,
> BLKIF_MAX_PERS_REQUESTS_PER_DEV. This is to prevent a malicious guest
> from attempting a DoS, by supplying fresh grefs, causing the Dom0
> kernel from to map excessively. This is currently set to 256---the
> maximum number of entires in the ring. As the number of inflight
> requests <= size of ring, 256 is also the maximum sensible size. This
> introduces a maximum overhead of 11MB of mapped memory, per block
> device. In practice, we don't typically use about 60 of these. If the
> guest exceeds the 256 limit, it is either buggy or malicious. We treat
> this in one of two ways:
> 1) If we have mapped <
> BLKIF_MAX_SEGMENTS_PER_REQUEST * BLKIF_MAX_PERS_REQUESTS_PER_DEV
> pages, we will persistently map the grefs. This can occur is previous
> requests have not used all BLKIF_MAX_SEGMENTS_PER_REQUEST segments.
> 2) Otherwise, we revert to non-persistent grants for all future grefs.
> 
> In writing this patch, the question arrises as to if the additional
> cost of performing memcpys in the guest (to/from the pool of granted
> pages) outweigh the gains of not performing TLB shootdowns. The answer
> to that question is `no'. There appears to be very little, if any
> additional cost to the guest of using persistent grants. There is
> perhaps a small saving, from the reduced number of hypercalls
> performed in granting, and ending foreign access.

I can't apply the patch to test it out?

patch -p1 < /tmp/blk 
patching file drivers/block/xen-blkback/blkback.c
patch: **** malformed patch at line 213:  


> 
> 
> Signed-off-by: Oliver Chick <oliver.chick@citrix.com>
> ---
>  drivers/block/xen-blkback/blkback.c |  149 +++++++++++++++++++++++++---
>  drivers/block/xen-blkback/common.h  |   16 +++
>  drivers/block/xen-blkback/xenbus.c  |   21 +++-
>  drivers/block/xen-blkfront.c        |  186 ++++++++++++++++++++++++++++++-----
>  include/xen/interface/io/blkif.h    |    9 ++
>  5 files changed, 338 insertions(+), 43 deletions(-)
> 
> diff --git a/drivers/block/xen-blkback/blkback.c b/drivers/block/xen-blkback/blkback.c
> index 73f196c..f95dee9 100644
> --- a/drivers/block/xen-blkback/blkback.c
> +++ b/drivers/block/xen-blkback/blkback.c
> @@ -78,6 +78,7 @@ struct pending_req {
>  	unsigned short		operation;
>  	int			status;
>  	struct list_head	free_list;
> +	u8			is_pers;
>  };
>  
>  #define BLKBACK_INVALID_HANDLE (~0)
> @@ -128,6 +129,24 @@ static int dispatch_rw_block_io(struct xen_blkif *blkif,
>  static void make_response(struct xen_blkif *blkif, u64 id,
>  			  unsigned short op, int st);
>  
> +static void add_pers_gnt(struct pers_gnt *pers_gnt, struct xen_blkif *blkif)
> +{
> +	BUG_ON(blkif->pers_gnt_c >= BLKIF_MAX_PERS_REQUESTS_PER_DEV *
> +	       BLKIF_MAX_SEGMENTS_PER_REQUEST);
> +	blkif->pers_gnts[blkif->pers_gnt_c++] = pers_gnt;
> +}
> +
> +static struct pers_gnt *get_pers_gnt(struct xen_blkif *blkif,
> +				     grant_ref_t gref)
> +{
> +	int i;
> +
> +	for (i = 0; i < blkif->pers_gnt_c; i++)
> +		if (gref == blkif->pers_gnts[i]->gnt)
> +			return blkif->pers_gnts[i];
> +	return NULL;
> +}
> +
>  /*
>   * Retrieve from the 'pending_reqs' a free pending_req structure to be used.
>   */
> @@ -274,6 +293,12 @@ int xen_blkif_schedule(void *arg)
>  {
>  	struct xen_blkif *blkif = arg;
>  	struct xen_vbd *vbd = &blkif->vbd;
> +	struct gnttab_unmap_grant_ref unmap[BLKIF_MAX_SEGMENTS_PER_REQUEST];
> +	struct page *pages[BLKIF_MAX_SEGMENTS_PER_REQUEST];
> +	struct pers_gnt *pers_gnt;
> +	int i;
> +	int ret = 0;
> +	int segs_to_unmap;
>  
>  	xen_blkif_get(blkif);
>  
> @@ -301,6 +326,29 @@ int xen_blkif_schedule(void *arg)
>  			print_stats(blkif);
>  	}
>  
> +	/* Free all persistent grant pages */
> +
> +	while (segs_to_unmap = min(BLKIF_MAX_SEGMENTS_PER_REQUEST,
> +				 blkif->pers_gnt_c)) {
> +
> +		for (i = 0; i < segs_to_unmap; i++) {
> +			pers_gnt = blkif->pers_gnts[blkif->pers_gnt_c - i - 1];
> +
> +			gnttab_set_unmap_op(&unmap[i],
> +					    pfn_to_kaddr(page_to_pfn(
> +							     pers_gnt->page)),
> +					    GNTMAP_host_map,
> +					    pers_gnt->handle);
> +
> +			pages[i] = pers_gnt->page;
> +		}
> +
> +		ret = gnttab_unmap_refs(unmap, pages, segs_to_unmap, false);
> +		BUG_ON(ret);
> +
> +		blkif->pers_gnt_c -= segs_to_unmap;
> +
> +	}
> +
>  	if (log_stats)
>  		print_stats(blkif);
>  
> @@ -343,13 +391,28 @@ static void xen_blkbk_unmap(struct pending_req *req)
>  
>  static int xen_blkbk_map(struct blkif_request *req,
>  			 struct pending_req *pending_req,
> -			 struct seg_buf seg[])
> +			 struct seg_buf seg[],
> +			 struct page *pages[])
>  {
>  	struct gnttab_map_grant_ref map[BLKIF_MAX_SEGMENTS_PER_REQUEST];
> +	struct pers_gnt *new_pers_gnts[BLKIF_MAX_SEGMENTS_PER_REQUEST];
> +	struct pers_gnt *pers_gnts[BLKIF_MAX_SEGMENTS_PER_REQUEST];
> +	struct page *pages_to_gnt[BLKIF_MAX_SEGMENTS_PER_REQUEST];
> +	struct pers_gnt *pers_gnt;
> +	phys_addr_t addr;
>  	int i;
> +	int new_map;
>  	int nseg = req->u.rw.nr_segments;
> +	int segs_to_init = 0;
>  	int ret = 0;
> +	int use_pers_gnts;
>  
> +	use_pers_gnts = (pending_req->blkif->can_grant_persist &&
> +			 pending_req->blkif->pers_gnt_c <
> +			 BLKIF_MAX_SEGMENTS_PER_REQUEST *
> +			 BLKIF_MAX_PERS_REQUESTS_PER_DEV);
> +
> +	pending_req->is_pers = use_pers_gnts;
>  	/*
>  	 * Fill out preq.nr_sects with proper amount of sectors, and setup
>  	 * assign map[..] with the PFN of the page in our domain with the
> @@ -358,36 +421,87 @@ static int xen_blkbk_map(struct blkif_request *req,
>  	for (i = 0; i < nseg; i++) {
>  		uint32_t flags;
>  
> +		if (use_pers_gnts) {
> +			pers_gnt = get_pers_gnt(pending_req->blkif,
> +						req->u.rw.seg[i].gref);
> +			if (!pers_gnt) {
> +				new_map = 1;
> +				pers_gnt = kmalloc(sizeof(struct pers_gnt),
> +						   GFP_KERNEL);
> +				if (!pers_gnt)
> +					return -ENOMEM;
> +				pers_gnt->page = alloc_page(GFP_KERNEL);
> +				if (!pers_gnt->page)
> +					return -ENOMEM;
> +				pers_gnt->gnt = req->u.rw.seg[i].gref;
> +
> +				pages_to_gnt[segs_to_init] = pers_gnt->page;
> +				new_pers_gnts[segs_to_init] = pers_gnt;
> +
> +				add_pers_gnt(pers_gnt, pending_req->blkif);
> +
> +			} else {
> +				new_map = 0;
> +			}
> +			pages[i] = pers_gnt->page;
> +			addr = (unsigned long) pfn_to_kaddr(
> +				page_to_pfn(pers_gnt->page));
> +			pers_gnts[i] = pers_gnt;
> +		} else {
> +			new_map = 1;
> +			pages[i] = blkbk->pending_page(pending_req, i);
> +			addr = vaddr(pending_req, i);
> +			pages_to_gnt[i] = blkbk->pending_page(pending_req, i);
> +		}
> +
>  		flags = GNTMAP_host_map;
> -		if (pending_req->operation != BLKIF_OP_READ)
> +		if (!use_pers_gnts && (pending_req->operation != BLKIF_OP_READ))
>  			flags |= GNTMAP_readonly;
> -		gnttab_set_map_op(&map[i], vaddr(pending_req, i), flags,
> -				  req->u.rw.seg[i].gref,
> -				  pending_req->blkif->domid);
> +		if (new_map) {
> +			gnttab_set_map_op(&map[segs_to_init++], addr,
> +					  flags, req->u.rw.seg[i].gref,
> +					  pending_req->blkif->domid);
> +		}
>  	}
>  
> -	ret = gnttab_map_refs(map, NULL, &blkbk->pending_page(pending_req, 0), nseg);
> -	BUG_ON(ret);
> +	if (segs_to_init) {
> +		ret = gnttab_map_refs(map, NULL, pages_to_gnt, segs_to_init);
> +		BUG_ON(ret);
> +	}
>  
>  	/*
>  	 * Now swizzle the MFN in our domain with the MFN from the other domain
>  	 * so that when we access vaddr(pending_req,i) it has the contents of
>  	 * the page from the other domain.
>  	 */
> -	for (i = 0; i < nseg; i++) {
> +	for (i = 0; i < segs_to_init; i++) {
>  		if (unlikely(map[i].status != 0)) {
>  			pr_debug(DRV_PFX "invalid buffer -- could not remap it\n");
>  			map[i].handle = BLKBACK_INVALID_HANDLE;
>  			ret |= 1;
>  		}
>  
> -		pending_handle(pending_req, i) = map[i].handle;
> +		if (use_pers_gnts) {
> +			/* store the `out' values from map */
> +		    pending_req->blkif->pers_gnts
> +			[pending_req->blkif->pers_gnt_c - segs_to_init +
> +			 i]->handle = map[i].handle;
> +			new_pers_gnts[i]->dev_bus_addr = map[i].dev_bus_addr;
> +		}
>  
>  		if (ret)
>  			continue;
> -
> -		seg[i].buf  = map[i].dev_bus_addr |
> -			(req->u.rw.seg[i].first_sect << 9);
> +	}
> +	for (i = 0; i < nseg; i++) {
> +		if (use_pers_gnts) {
> +			pending_handle(pending_req, i) = pers_gnts[i]->handle;
> +			seg[i].buf = pers_gnts[i]->dev_bus_addr |
> +				(req->u.rw.seg[i].first_sect << 9);
> +		} else {
> +			pending_handle(pending_req, i) = map[i].handle;
> +			seg[i].buf = map[i].dev_bus_addr |
> +				(req->u.rw.seg[i].first_sect << 9);
> +		}
>  	}
>  	return ret;
>  }
> @@ -468,7 +582,8 @@ static void __end_block_io_op(struct pending_req *pending_req, int error)
>  	 * the proper response on the ring.
>  	 */
>  	if (atomic_dec_and_test(&pending_req->pendcnt)) {
> -		xen_blkbk_unmap(pending_req);
> +		if (!pending_req->is_pers)
> +			xen_blkbk_unmap(pending_req);
>  		make_response(pending_req->blkif, pending_req->id,
>  			      pending_req->operation, pending_req->status);
>  		xen_blkif_put(pending_req->blkif);
> @@ -590,6 +705,7 @@ static int dispatch_rw_block_io(struct xen_blkif *blkif,
>  	int operation;
>  	struct blk_plug plug;
>  	bool drain = false;
> +	struct page *pages[BLKIF_MAX_SEGMENTS_PER_REQUEST];
>  
>  	switch (req->operation) {
>  	case BLKIF_OP_READ:
> @@ -676,7 +792,7 @@ static int dispatch_rw_block_io(struct xen_blkif *blkif,
>  	 * the hypercall to unmap the grants - that is all done in
>  	 * xen_blkbk_unmap.
>  	 */
> -	if (xen_blkbk_map(req, pending_req, seg))
> +	if (xen_blkbk_map(req, pending_req, seg, pages))
>  		goto fail_flush;
>  
>  	/*
> @@ -688,7 +804,7 @@ static int dispatch_rw_block_io(struct xen_blkif *blkif,
>  	for (i = 0; i < nseg; i++) {
>  		while ((bio == NULL) ||
>  		       (bio_add_page(bio,
> -				     blkbk->pending_page(pending_req, i),
> +				     pages[i],
>  				     seg[i].nsec << 9,
>  				     seg[i].buf & ~PAGE_MASK) == 0)) {
>  
> @@ -743,7 +859,8 @@ static int dispatch_rw_block_io(struct xen_blkif *blkif,
>  	return 0;
>  
>   fail_flush:
> -	xen_blkbk_unmap(pending_req);
> +	if (!blkif->can_grant_persist)
> +		xen_blkbk_unmap(pending_req);
>   fail_response:
>  	/* Haven't submitted any bio's yet. */
>  	make_response(blkif, req->u.rw.id, req->operation, BLKIF_RSP_ERROR);
> diff --git a/drivers/block/xen-blkback/common.h b/drivers/block/xen-blkback/common.h
> index 9ad3b5e..1ecb709 100644
> --- a/drivers/block/xen-blkback/common.h
> +++ b/drivers/block/xen-blkback/common.h
> @@ -47,6 +47,8 @@
>  #define DPRINTK(fmt, args...)				\
>  	pr_debug(DRV_PFX "(%s:%d) " fmt ".\n",		\
>  		 __func__, __LINE__, ##args)
> +#define BLKIF_MAX_PERS_REQUESTS_PER_DEV 256
> +
>  
>  
>  /* Not a real protocol.  Used to generate ring structs which contain
> @@ -164,6 +166,14 @@ struct xen_vbd {
>  
>  struct backend_info;
>  
> +
> +struct pers_gnt {
> +	struct page *page;
> +	grant_ref_t gnt;
> +	uint32_t handle;
> +	uint64_t dev_bus_addr;
> +};
> +
>  struct xen_blkif {
>  	/* Unique identifier for this interface. */
>  	domid_t			domid;
> @@ -190,6 +200,12 @@ struct xen_blkif {
>  	struct task_struct	*xenblkd;
>  	unsigned int		waiting_reqs;
>  
> +	/* frontend feature information */
> +	u8			can_grant_persist:1;
> +	struct pers_gnt		*pers_gnts[BLKIF_MAX_PERS_REQUESTS_PER_DEV *
> +					  BLKIF_MAX_SEGMENTS_PER_REQUEST];
> +	unsigned int		pers_gnt_c;
> +
>  	/* statistics */
>  	unsigned long		st_print;
>  	int			st_rd_req;
> diff --git a/drivers/block/xen-blkback/xenbus.c b/drivers/block/xen-blkback/xenbus.c
> index 4f66171..dc58cc4 100644
> --- a/drivers/block/xen-blkback/xenbus.c
> +++ b/drivers/block/xen-blkback/xenbus.c
> @@ -681,6 +681,13 @@ again:
>  		goto abort;
>  	}
>  
> +	err = xenbus_printf(xbt, dev->nodename, "feature-persistent-grants",
> +			    "%d", 1);
> +	if (err) {
> +		xenbus_dev_fatal(dev, err, "writing persistent capability");
> +		goto abort;
> +	}
> +
>  	/* FIXME: use a typename instead */
>  	err = xenbus_printf(xbt, dev->nodename, "info", "%u",
>  			    be->blkif->vbd.type |
> @@ -721,6 +728,7 @@ static int connect_ring(struct backend_info *be)
>  	struct xenbus_device *dev = be->dev;
>  	unsigned long ring_ref;
>  	unsigned int evtchn;
> +	u8 pers_grants;
>  	char protocol[64] = "";
>  	int err;
>  
> @@ -750,8 +758,17 @@ static int connect_ring(struct backend_info *be)
>  		xenbus_dev_fatal(dev, err, "unknown fe protocol %s", protocol);
>  		return -1;
>  	}
> -	pr_info(DRV_PFX "ring-ref %ld, event-channel %d, protocol %d (%s)\n",
> -		ring_ref, evtchn, be->blkif->blk_protocol, protocol);
> +	err = xenbus_gather(XBT_NIL, dev->otherend,
> +			    "feature-persistent-grants", "%d",
> +			    &pers_grants, NULL);
> +	if (err)
> +		pers_grants = 0;
> +
> +	be->blkif->can_grant_persist = pers_grants;
> +
> +	pr_info(DRV_PFX "ring-ref %ld, event-channel %d, protocol %d (%s) persistent %d\n",
> +		ring_ref, evtchn, be->blkif->blk_protocol, protocol,
> +		pers_grants);
>  
>  	/* Map the shared frame, irq etc. */
>  	err = xen_blkif_map(be->blkif, ring_ref, evtchn);
> diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c
> index e4fb337..c1cc5fe 100644
> --- a/drivers/block/xen-blkfront.c
> +++ b/drivers/block/xen-blkfront.c
> @@ -68,6 +68,13 @@ struct blk_shadow {
>  	struct blkif_request req;
>  	struct request *request;
>  	unsigned long frame[BLKIF_MAX_SEGMENTS_PER_REQUEST];
> +	struct gnt_list *grants_used[BLKIF_MAX_SEGMENTS_PER_REQUEST];
> +};
> +
> +struct gnt_list {
> +	grant_ref_t gref;
> +	unsigned long frame;
> +	struct gnt_list *tail;
>  };
>  
>  static DEFINE_MUTEX(blkfront_mutex);
> @@ -97,11 +104,14 @@ struct blkfront_info
>  	struct work_struct work;
>  	struct gnttab_free_callback callback;
>  	struct blk_shadow shadow[BLK_RING_SIZE];
> +	struct gnt_list *persistent_grants_front;
> +	unsigned int persistent_grants_c;
>  	unsigned long shadow_free;
>  	unsigned int feature_flush;
>  	unsigned int flush_op;
>  	unsigned int feature_discard:1;
>  	unsigned int feature_secdiscard:1;
> +	unsigned int feature_persistent:1;
>  	unsigned int discard_granularity;
>  	unsigned int discard_alignment;
>  	int is_ready;
> @@ -286,22 +296,37 @@ static int blkif_queue_request(struct request *req)
>  	struct blkif_request *ring_req;
>  	unsigned long id;
>  	unsigned int fsect, lsect;
> -	int i, ref;
> +	int i, ref, use_pers_gnts, new_pers_gnts;
>  	grant_ref_t gref_head;
> +	struct bio_vec *bvecs[BLKIF_MAX_SEGMENTS_PER_REQUEST];
> +	struct bio_vec *bvec;
> +	struct req_iterator iter;
> +	char *bvec_data;
> +	void *shared_data;
> +	unsigned long flags;
> +	struct page *shared_page;
> +	struct gnt_list *gnt_list_entry;
>  	struct scatterlist *sg;
>  
>  	if (unlikely(info->connected != BLKIF_STATE_CONNECTED))
>  		return 1;
>  
> -	if (gnttab_alloc_grant_references(
> -		BLKIF_MAX_SEGMENTS_PER_REQUEST, &gref_head) < 0) {
> -		gnttab_request_free_callback(
> -			&info->callback,
> -			blkif_restart_queue_callback,
> -			info,
> -			BLKIF_MAX_SEGMENTS_PER_REQUEST);
> -		return 1;
> +	use_pers_gnts = info->feature_persistent;
> +
> +	if (info->persistent_grants_c < BLKIF_MAX_SEGMENTS_PER_REQUEST) {
> +		new_pers_gnts = 1;
> +		if (gnttab_alloc_grant_references(
> +			    BLKIF_MAX_SEGMENTS_PER_REQUEST, &gref_head) < 0) {
> +			gnttab_request_free_callback(
> +				&info->callback,
> +				blkif_restart_queue_callback,
> +				info,
> +				BLKIF_MAX_SEGMENTS_PER_REQUEST);
> +			return 1;
> +		}
>  	} else
> +		new_pers_gnts = 0;
>  
>  	/* Fill out a communications ring structure. */
>  	ring_req = RING_GET_REQUEST(&info->ring, info->ring.req_prod_pvt);
> @@ -341,20 +366,66 @@ static int blkif_queue_request(struct request *req)
>  		       BLKIF_MAX_SEGMENTS_PER_REQUEST);
>  
>  		for_each_sg(info->sg, sg, ring_req->u.rw.nr_segments, i) {
> -			buffer_mfn = pfn_to_mfn(page_to_pfn(sg_page(sg)));
>  			fsect = sg->offset >> 9;
>  			lsect = fsect + (sg->length >> 9) - 1;
> -			/* install a grant reference. */
> -			ref = gnttab_claim_grant_reference(&gref_head);
> -			BUG_ON(ref == -ENOSPC);
>  
> -			gnttab_grant_foreign_access_ref(
> +			if (use_pers_gnts && info->persistent_grants_c) {
> +				gnt_list_entry = info->persistent_grants_front;
> +
> +				info->persistent_grants_front =
> +					info->persistent_grants_front->tail;
> +				ref = gnt_list_entry->gref;
> +				buffer_mfn = pfn_to_mfn(gnt_list_entry->frame);
> +				info->persistent_grants_c--;
> +			} else {
> +				ref = gnttab_claim_grant_reference(&gref_head);
> +				BUG_ON(ref == -ENOSPC);
> +
> +				if (use_pers_gnts) {
> +					gnt_list_entry =
> +						kmalloc(sizeof(struct gnt_list),
> +								 GFP_ATOMIC);
> +					if (!gnt_list_entry)
> +						return -ENOMEM;
> +
> +					shared_page = alloc_page(GFP_ATOMIC);
> +					if (!shared_page)
> +						return -ENOMEM;
> +
> +					gnt_list_entry->frame =
> +						page_to_pfn(shared_page);
> +					gnt_list_entry->gref = ref;
> +				} else
> +					shared_page = sg_page(sg);
> +
> +				buffer_mfn = pfn_to_mfn(page_to_pfn(
> +								shared_page));
> +				gnttab_grant_foreign_access_ref(
>  					ref,
>  					info->xbdev->otherend_id,
>  					buffer_mfn,
> -					rq_data_dir(req));
> +					!use_pers_gnts && rq_data_dir(req));
> +			}
> +
> +			if (use_pers_gnts)
> +				info->shadow[id].grants_used[i] =
> +					gnt_list_entry;
> +
> +			if (use_pers_gnts && rq_data_dir(req)) {
> +				shared_data = kmap_atomic(
> +					pfn_to_page(gnt_list_entry->frame));
> +				bvec_data = kmap_atomic(sg_page(sg));
> +
> +				memcpy(shared_data + sg->offset,
> +				       bvec_data   + sg->offset,
> +				       sg->length);
> +
> +				kunmap_atomic(bvec_data);
> +				kunmap_atomic(shared_data);
> +			}
>  
>  			info->shadow[id].frame[i] = mfn_to_pfn(buffer_mfn);
> +
>  			ring_req->u.rw.seg[i] =
>  					(struct blkif_request_segment) {
>  						.gref       = ref,
> @@ -368,7 +439,8 @@ static int blkif_queue_request(struct request *req)
>  	/* Keep a private copy so we can reissue requests when recovering. */
>  	info->shadow[id].req = *ring_req;
>  
> -	gnttab_free_grant_references(gref_head);
> +	if (new_pers_gnts)
> +		gnttab_free_grant_references(gref_head);
>  
>  	return 0;
>  }
> @@ -480,12 +552,13 @@ static int xlvbd_init_blk_queue(struct gendisk *gd, u16 sector_size)
>  static void xlvbd_flush(struct blkfront_info *info)
>  {
>  	blk_queue_flush(info->rq, info->feature_flush);
> -	printk(KERN_INFO "blkfront: %s: %s: %s\n",
> +	printk(KERN_INFO "blkfront: %s: %s: %s. Persistent=%d\n",
>  	       info->gd->disk_name,
>  	       info->flush_op == BLKIF_OP_WRITE_BARRIER ?
>  		"barrier" : (info->flush_op == BLKIF_OP_FLUSH_DISKCACHE ?
>  		"flush diskcache" : "barrier or flush"),
> -	       info->feature_flush ? "enabled" : "disabled");
> +	       info->feature_flush ? "enabled" : "disabled",
> +	    info->feature_persistent);
>  }
>  
>  static int xen_translate_vdev(int vdevice, int *minor, unsigned int *offset)
> @@ -707,6 +780,8 @@ static void blkif_restart_queue(struct work_struct *work)
>  
>  static void blkif_free(struct blkfront_info *info, int suspend)
>  {
> +	struct gnt_list *pers_gnt;
> +
>  	/* Prevent new requests being issued until we fix things up. */
>  	spin_lock_irq(&info->io_lock);
>  	info->connected = suspend ?
> @@ -714,6 +789,15 @@ static void blkif_free(struct blkfront_info *info, int suspend)
>  	/* No more blkif_request(). */
>  	if (info->rq)
>  		blk_stop_queue(info->rq);
> +
> +	/* Remove all persistent grants */
> +	while (info->persistent_grants_front) {
> +		pers_gnt = info->persistent_grants_front;
> +		info->persistent_grants_front = pers_gnt->tail;
> +		gnttab_end_foreign_access(pers_gnt->gref, 0, 0UL);
> +		kfree(pers_gnt);
> +	}
> +
>  	/* No more gnttab callback work. */
>  	gnttab_cancel_free_callback(&info->callback);
>  	spin_unlock_irq(&info->io_lock);
> @@ -734,13 +818,44 @@ static void blkif_free(struct blkfront_info *info, int suspend)
>  
>  }
>  
> -static void blkif_completion(struct blk_shadow *s)
> +static void blkif_completion(struct blk_shadow *s, struct blkfront_info *info,
> +			     struct blkif_response *bret)
>  {
>  	int i;
> -	/* Do not let BLKIF_OP_DISCARD as nr_segment is in the same place
> -	 * flag. */
> -	for (i = 0; i < s->req.u.rw.nr_segments; i++)
> -		gnttab_end_foreign_access(s->req.u.rw.seg[i].gref, 0, 0UL);
> +	struct gnt_list *new_gnt_list_entry;
> +	struct bio_vec *bvec;
> +	struct req_iterator iter;
> +	unsigned long flags;
> +	char *bvec_data;
> +	void *shared_data;
> +
> +	i = 0;
> +	if (info->feature_persistent == 0) {
> +		/* Do not let BLKIF_OP_DISCARD as nr_segment is in the same
> +		 * place flag. */
> +		for (i = 0; i < s->req.u.rw.nr_segments; i++)
> +			gnttab_end_foreign_access(s->req.u.rw.seg[i].gref,
> +						  0, 0UL);
> +		return;
> +	}
> +
> +	if (bret->operation == BLKIF_OP_READ)
> +		rq_for_each_segment(bvec, s->request, iter) {
> +			shared_data = kmap_atomic
> +				(pfn_to_page(s->grants_used[i++]->frame));
> +			bvec_data = bvec_kmap_irq(bvec, &flags);
> +			memcpy(bvec_data, shared_data + bvec->bv_offset,
> +			       bvec->bv_len);
> +			bvec_kunmap_irq(bvec_data, &flags);
> +			kunmap_atomic(shared_data);
> +		}
> +	/* Add the persistent grant into the list of free grants */
> +	for (i = 0; i < s->req.u.rw.nr_segments; i++) {
> +		new_gnt_list_entry = s->grants_used[i];
> +		new_gnt_list_entry->tail = info->persistent_grants_front;
> +		info->persistent_grants_front = new_gnt_list_entry;
> +		info->persistent_grants_c++;
> +	}
>  }
>  
>  static irqreturn_t blkif_interrupt(int irq, void *dev_id)
> @@ -783,7 +898,7 @@ static irqreturn_t blkif_interrupt(int irq, void *dev_id)
>  		req  = info->shadow[id].request;
>  
>  		if (bret->operation != BLKIF_OP_DISCARD)
> -			blkif_completion(&info->shadow[id]);
> +			blkif_completion(&info->shadow[id], info, bret);
>  
>  		if (add_id_to_freelist(info, id)) {
>  			WARN(1, "%s: response to %s (id %ld) couldn't be recycled!\n",
> @@ -943,6 +1058,12 @@ again:
>  		message = "writing protocol";
>  		goto abort_transaction;
>  	}
> +	err = xenbus_printf(xbt, dev->nodename,
> +			    "feature-persistent-grants", "%d", 1);
> +	if (err) {
> +		message = "Writing persistent grants front feature";
> +		goto abort_transaction;
> +	}
>  
>  	err = xenbus_transaction_end(xbt, 0);
>  	if (err) {
> @@ -1030,6 +1151,7 @@ static int blkfront_probe(struct xenbus_device *dev,
>  	spin_lock_init(&info->io_lock);
>  	info->xbdev = dev;
>  	info->vdevice = vdevice;
> +	info->persistent_grants_c = 0;
>  	info->connected = BLKIF_STATE_DISCONNECTED;
>  	INIT_WORK(&info->work, blkif_restart_queue);
>  
> @@ -1094,6 +1216,7 @@ static int blkif_recover(struct blkfront_info *info)
>  					req->u.rw.seg[j].gref,
>  					info->xbdev->otherend_id,
>  					pfn_to_mfn(info->shadow[req->u.rw.id].frame[j]),
> +					!info->feature_persistent &&
>  					rq_data_dir(info->shadow[req->u.rw.id].request));
>  		}
>  		info->shadow[req->u.rw.id].req = *req;
> @@ -1226,7 +1349,7 @@ static void blkfront_connect(struct blkfront_info *info)
>  	unsigned long sector_size;
>  	unsigned int binfo;
>  	int err;
> -	int barrier, flush, discard;
> +	int barrier, flush, discard, persistent;
>  
>  	switch (info->connected) {
>  	case BLKIF_STATE_CONNECTED:
> @@ -1297,6 +1420,19 @@ static void blkfront_connect(struct blkfront_info *info)
>  		info->flush_op = BLKIF_OP_FLUSH_DISKCACHE;
>  	}
>  
> +	/*
> +	 * Are we dealing with an old blkback that will unmap
> +	 * all grefs?
> +	 */
> +	err = xenbus_gather(XBT_NIL, info->xbdev->otherend,
> +			    "feature-persistent-grants", "%d", &persistent,
> +			    NULL);
> +
> +	if (err)
> +		info->feature_persistent = 0;
> +	else
> +		info->feature_persistent = persistent;
> +
>  	err = xenbus_gather(XBT_NIL, info->xbdev->otherend,
>  			    "feature-discard", "%d", &discard,
>  			    NULL);
> diff --git a/include/xen/interface/io/blkif.h b/include/xen/interface/io/blkif.h
> index ee338bf..cd267a9b 100644
> --- a/include/xen/interface/io/blkif.h
> +++ b/include/xen/interface/io/blkif.h
> @@ -109,6 +109,15 @@ typedef uint64_t blkif_sector_t;
>   */
>  #define BLKIF_MAX_SEGMENTS_PER_REQUEST 11
>  
> +/*
> + * Maximum number of persistent grants that can be mapped by Dom0 for each
> + * interface. This is set to be the size of the ring, as this is a limit on
> + * the number of requests that can be inflight at any one time. 256 imposes
> + * an overhead of 11MB of mapped kernel space per interface.
> + */
> +#define BLKIF_MAX_PERS_REQUESTS_PER_DEV 256
> +
> +
>  struct blkif_request_rw {
>  	uint8_t        nr_segments;  /* number of segments                   */
>  	blkif_vdev_t   handle;       /* only for read/write requests         */
> -- 
> 1.7.9.5

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 19 11:28:22 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Sep 2012 11:28:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TEIRm-0008VK-VZ; Wed, 19 Sep 2012 11:28:02 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1TEIRl-0008V9-4u
	for xen-devel@lists.xen.org; Wed, 19 Sep 2012 11:28:01 +0000
Received: from [85.158.143.35:46057] by server-1.bemta-4.messagelabs.com id
	7C/90-05684-04CA9505; Wed, 19 Sep 2012 11:28:00 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1348054077!7204819!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDc2MDk3OQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4252 invoked from network); 19 Sep 2012 11:27:58 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-4.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 19 Sep 2012 11:27:58 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q8JBRr8p006193
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 19 Sep 2012 11:27:53 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
	q8JBRq8i004214
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 19 Sep 2012 11:27:53 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
	q8JBRqhu014063; Wed, 19 Sep 2012 06:27:52 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 19 Sep 2012 04:27:52 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 87C0C402EC; Wed, 19 Sep 2012 07:17:01 -0400 (EDT)
Date: Wed, 19 Sep 2012 07:17:01 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Oliver Chick <oliver.chick@citrix.com>
Message-ID: <20120919111701.GB12367@phenom.dumpdata.com>
References: <1348051887-21885-1-git-send-email-oliver.chick@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1348051887-21885-1-git-send-email-oliver.chick@citrix.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: linux-kernel@vger.kernel.org, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] Persistent grant maps for xen blk drivers
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Sep 19, 2012 at 11:51:27AM +0100, Oliver Chick wrote:
> This patch implements persistent grants for the xen-blk{front,back}
> mechanism. The effect of this change is to reduce the number of unmap
> operations performed, since they cause a (costly) TLB shootdown. This
> allows the I/O performance to scale better when a large number of VMs
> are performing I/O.
> 
> Previously, the blkfront driver was supplied a bvec[] from the request
> queue. This was granted to dom0; dom0 performed the I/O and wrote
> directly into the grant-mapped memory and unmapped it; blkfront then
> removed foreign access for that grant. The cost of unmapping scales
> badly with the number of CPUs in Dom0. An experiment showed that when
> Dom0 has 24 VCPUs, and guests are performing parallel I/O to a
> ramdisk, the IPIs from performing unmap's is a bottleneck at 5 guests
> (at which point 650,000 IOPS are being performed in total). If more
> than 5 guests are used, the performance declines. By 10 guests, only
> 400,000 IOPS are being performed.
> 
> This patch improves performance by only unmapping when the connection
> between blkfront and back is broken.
> 
> On startup, blk{front,back} use xenbus to communicate their ability to
> perform 'feature-persistent'. Iff both ends have this ability,
> persistent mode is used.
> 
> To perform a read, in persistent mode, blkfront uses a separate pool
> of pages that it maps to dom0. When a request comes in, blkfront
> transmutes the request so that blkback will write into one of these
> free pages. Blkback keeps note of which grefs it has already
> mapped. When a new ring request comes to blkback, it looks to see if
> it has already mapped that page. If so, it will not map it again. If
> the page hasn't been previously mapped, it is mapped now, and a record
> is kept of this mapping. Blkback proceeds as usual. When blkfront is
> notified that blkback has completed a request, it memcpy's from the
> shared memory, into the bvec supplied. A record that the {gref, page}
> tuple is mapped, and not inflight is kept.
> 
> Writes are similar, except that the memcpy is peformed from the
> supplied bvecs, into the shared pages, before the request is put onto
> the ring.
> 
> Blkback has to store a mapping of grefs=>{page mapped to by gref} in
> an array. As the grefs are not known apriori, and provide no
> guarantees on their ordering, we have to perform a linear search
> through this array to find the page, for every gref we receive. The
> overhead of this is low, however future work might want to use a more
> efficient data structure to reduce this O(n) operation.
> 
> We (ijc, and myself) have introduced a new constant,
> BLKIF_MAX_PERS_REQUESTS_PER_DEV. This is to prevent a malicious guest
> from attempting a DoS, by supplying fresh grefs, causing the Dom0
> kernel from to map excessively. This is currently set to 256---the
> maximum number of entires in the ring. As the number of inflight
> requests <= size of ring, 256 is also the maximum sensible size. This
> introduces a maximum overhead of 11MB of mapped memory, per block
> device. In practice, we don't typically use about 60 of these. If the
> guest exceeds the 256 limit, it is either buggy or malicious. We treat
> this in one of two ways:
> 1) If we have mapped <
> BLKIF_MAX_SEGMENTS_PER_REQUEST * BLKIF_MAX_PERS_REQUESTS_PER_DEV
> pages, we will persistently map the grefs. This can occur is previous
> requests have not used all BLKIF_MAX_SEGMENTS_PER_REQUEST segments.
> 2) Otherwise, we revert to non-persistent grants for all future grefs.
> 
> In writing this patch, the question arrises as to if the additional
> cost of performing memcpys in the guest (to/from the pool of granted
> pages) outweigh the gains of not performing TLB shootdowns. The answer
> to that question is `no'. There appears to be very little, if any
> additional cost to the guest of using persistent grants. There is
> perhaps a small saving, from the reduced number of hypercalls
> performed in granting, and ending foreign access.

I can't apply the patch to test it out?

patch -p1 < /tmp/blk 
patching file drivers/block/xen-blkback/blkback.c
patch: **** malformed patch at line 213:  


> 
> 
> Signed-off-by: Oliver Chick <oliver.chick@citrix.com>
> ---
>  drivers/block/xen-blkback/blkback.c |  149 +++++++++++++++++++++++++---
>  drivers/block/xen-blkback/common.h  |   16 +++
>  drivers/block/xen-blkback/xenbus.c  |   21 +++-
>  drivers/block/xen-blkfront.c        |  186 ++++++++++++++++++++++++++++++-----
>  include/xen/interface/io/blkif.h    |    9 ++
>  5 files changed, 338 insertions(+), 43 deletions(-)
> 
> diff --git a/drivers/block/xen-blkback/blkback.c b/drivers/block/xen-blkback/blkback.c
> index 73f196c..f95dee9 100644
> --- a/drivers/block/xen-blkback/blkback.c
> +++ b/drivers/block/xen-blkback/blkback.c
> @@ -78,6 +78,7 @@ struct pending_req {
>  	unsigned short		operation;
>  	int			status;
>  	struct list_head	free_list;
> +	u8			is_pers;
>  };
>  
>  #define BLKBACK_INVALID_HANDLE (~0)
> @@ -128,6 +129,24 @@ static int dispatch_rw_block_io(struct xen_blkif *blkif,
>  static void make_response(struct xen_blkif *blkif, u64 id,
>  			  unsigned short op, int st);
>  
> +static void add_pers_gnt(struct pers_gnt *pers_gnt, struct xen_blkif *blkif)
> +{
> +	BUG_ON(blkif->pers_gnt_c >= BLKIF_MAX_PERS_REQUESTS_PER_DEV *
> +	       BLKIF_MAX_SEGMENTS_PER_REQUEST);
> +	blkif->pers_gnts[blkif->pers_gnt_c++] = pers_gnt;
> +}
> +
> +static struct pers_gnt *get_pers_gnt(struct xen_blkif *blkif,
> +				     grant_ref_t gref)
> +{
> +	int i;
> +
> +	for (i = 0; i < blkif->pers_gnt_c; i++)
> +		if (gref == blkif->pers_gnts[i]->gnt)
> +			return blkif->pers_gnts[i];
> +	return NULL;
> +}
> +
>  /*
>   * Retrieve from the 'pending_reqs' a free pending_req structure to be used.
>   */
> @@ -274,6 +293,12 @@ int xen_blkif_schedule(void *arg)
>  {
>  	struct xen_blkif *blkif = arg;
>  	struct xen_vbd *vbd = &blkif->vbd;
> +	struct gnttab_unmap_grant_ref unmap[BLKIF_MAX_SEGMENTS_PER_REQUEST];
> +	struct page *pages[BLKIF_MAX_SEGMENTS_PER_REQUEST];
> +	struct pers_gnt *pers_gnt;
> +	int i;
> +	int ret = 0;
> +	int segs_to_unmap;
>  
>  	xen_blkif_get(blkif);
>  
> @@ -301,6 +326,29 @@ int xen_blkif_schedule(void *arg)
>  			print_stats(blkif);
>  	}
>  
> +	/* Free all persistent grant pages */
> +
> +	while (segs_to_unmap = min(BLKIF_MAX_SEGMENTS_PER_REQUEST,
> +				 blkif->pers_gnt_c)) {
> +
> +		for (i = 0; i < segs_to_unmap; i++) {
> +			pers_gnt = blkif->pers_gnts[blkif->pers_gnt_c - i - 1];
> +
> +			gnttab_set_unmap_op(&unmap[i],
> +					    pfn_to_kaddr(page_to_pfn(
> +							     pers_gnt->page)),
> +					    GNTMAP_host_map,
> +					    pers_gnt->handle);
> +
> +			pages[i] = pers_gnt->page;
> +		}
> +
> +		ret = gnttab_unmap_refs(unmap, pages, segs_to_unmap, false);
> +		BUG_ON(ret);
> +
> +		blkif->pers_gnt_c -= segs_to_unmap;
> +
> +	}
> +
>  	if (log_stats)
>  		print_stats(blkif);
>  
> @@ -343,13 +391,28 @@ static void xen_blkbk_unmap(struct pending_req *req)
>  
>  static int xen_blkbk_map(struct blkif_request *req,
>  			 struct pending_req *pending_req,
> -			 struct seg_buf seg[])
> +			 struct seg_buf seg[],
> +			 struct page *pages[])
>  {
>  	struct gnttab_map_grant_ref map[BLKIF_MAX_SEGMENTS_PER_REQUEST];
> +	struct pers_gnt *new_pers_gnts[BLKIF_MAX_SEGMENTS_PER_REQUEST];
> +	struct pers_gnt *pers_gnts[BLKIF_MAX_SEGMENTS_PER_REQUEST];
> +	struct page *pages_to_gnt[BLKIF_MAX_SEGMENTS_PER_REQUEST];
> +	struct pers_gnt *pers_gnt;
> +	phys_addr_t addr;
>  	int i;
> +	int new_map;
>  	int nseg = req->u.rw.nr_segments;
> +	int segs_to_init = 0;
>  	int ret = 0;
> +	int use_pers_gnts;
>  
> +	use_pers_gnts = (pending_req->blkif->can_grant_persist &&
> +			 pending_req->blkif->pers_gnt_c <
> +			 BLKIF_MAX_SEGMENTS_PER_REQUEST *
> +			 BLKIF_MAX_PERS_REQUESTS_PER_DEV);
> +
> +	pending_req->is_pers = use_pers_gnts;
>  	/*
>  	 * Fill out preq.nr_sects with proper amount of sectors, and setup
>  	 * assign map[..] with the PFN of the page in our domain with the
> @@ -358,36 +421,87 @@ static int xen_blkbk_map(struct blkif_request *req,
>  	for (i = 0; i < nseg; i++) {
>  		uint32_t flags;
>  
> +		if (use_pers_gnts) {
> +			pers_gnt = get_pers_gnt(pending_req->blkif,
> +						req->u.rw.seg[i].gref);
> +			if (!pers_gnt) {
> +				new_map = 1;
> +				pers_gnt = kmalloc(sizeof(struct pers_gnt),
> +						   GFP_KERNEL);
> +				if (!pers_gnt)
> +					return -ENOMEM;
> +				pers_gnt->page = alloc_page(GFP_KERNEL);
> +				if (!pers_gnt->page)
> +					return -ENOMEM;
> +				pers_gnt->gnt = req->u.rw.seg[i].gref;
> +
> +				pages_to_gnt[segs_to_init] = pers_gnt->page;
> +				new_pers_gnts[segs_to_init] = pers_gnt;
> +
> +				add_pers_gnt(pers_gnt, pending_req->blkif);
> +
> +			} else {
> +				new_map = 0;
> +			}
> +			pages[i] = pers_gnt->page;
> +			addr = (unsigned long) pfn_to_kaddr(
> +				page_to_pfn(pers_gnt->page));
> +			pers_gnts[i] = pers_gnt;
> +		} else {
> +			new_map = 1;
> +			pages[i] = blkbk->pending_page(pending_req, i);
> +			addr = vaddr(pending_req, i);
> +			pages_to_gnt[i] = blkbk->pending_page(pending_req, i);
> +		}
> +
>  		flags = GNTMAP_host_map;
> -		if (pending_req->operation != BLKIF_OP_READ)
> +		if (!use_pers_gnts && (pending_req->operation != BLKIF_OP_READ))
>  			flags |= GNTMAP_readonly;
> -		gnttab_set_map_op(&map[i], vaddr(pending_req, i), flags,
> -				  req->u.rw.seg[i].gref,
> -				  pending_req->blkif->domid);
> +		if (new_map) {
> +			gnttab_set_map_op(&map[segs_to_init++], addr,
> +					  flags, req->u.rw.seg[i].gref,
> +					  pending_req->blkif->domid);
> +		}
>  	}
>  
> -	ret = gnttab_map_refs(map, NULL, &blkbk->pending_page(pending_req, 0), nseg);
> -	BUG_ON(ret);
> +	if (segs_to_init) {
> +		ret = gnttab_map_refs(map, NULL, pages_to_gnt, segs_to_init);
> +		BUG_ON(ret);
> +	}
>  
>  	/*
>  	 * Now swizzle the MFN in our domain with the MFN from the other domain
>  	 * so that when we access vaddr(pending_req,i) it has the contents of
>  	 * the page from the other domain.
>  	 */
> -	for (i = 0; i < nseg; i++) {
> +	for (i = 0; i < segs_to_init; i++) {
>  		if (unlikely(map[i].status != 0)) {
>  			pr_debug(DRV_PFX "invalid buffer -- could not remap it\n");
>  			map[i].handle = BLKBACK_INVALID_HANDLE;
>  			ret |= 1;
>  		}
>  
> -		pending_handle(pending_req, i) = map[i].handle;
> +		if (use_pers_gnts) {
> +			/* store the `out' values from map */
> +		    pending_req->blkif->pers_gnts
> +			[pending_req->blkif->pers_gnt_c - segs_to_init +
> +			 i]->handle = map[i].handle;
> +			new_pers_gnts[i]->dev_bus_addr = map[i].dev_bus_addr;
> +		}
>  
>  		if (ret)
>  			continue;
> -
> -		seg[i].buf  = map[i].dev_bus_addr |
> -			(req->u.rw.seg[i].first_sect << 9);
> +	}
> +	for (i = 0; i < nseg; i++) {
> +		if (use_pers_gnts) {
> +			pending_handle(pending_req, i) = pers_gnts[i]->handle;
> +			seg[i].buf = pers_gnts[i]->dev_bus_addr |
> +				(req->u.rw.seg[i].first_sect << 9);
> +		} else {
> +			pending_handle(pending_req, i) = map[i].handle;
> +			seg[i].buf = map[i].dev_bus_addr |
> +				(req->u.rw.seg[i].first_sect << 9);
> +		}
>  	}
>  	return ret;
>  }
> @@ -468,7 +582,8 @@ static void __end_block_io_op(struct pending_req *pending_req, int error)
>  	 * the proper response on the ring.
>  	 */
>  	if (atomic_dec_and_test(&pending_req->pendcnt)) {
> -		xen_blkbk_unmap(pending_req);
> +		if (!pending_req->is_pers)
> +			xen_blkbk_unmap(pending_req);
>  		make_response(pending_req->blkif, pending_req->id,
>  			      pending_req->operation, pending_req->status);
>  		xen_blkif_put(pending_req->blkif);
> @@ -590,6 +705,7 @@ static int dispatch_rw_block_io(struct xen_blkif *blkif,
>  	int operation;
>  	struct blk_plug plug;
>  	bool drain = false;
> +	struct page *pages[BLKIF_MAX_SEGMENTS_PER_REQUEST];
>  
>  	switch (req->operation) {
>  	case BLKIF_OP_READ:
> @@ -676,7 +792,7 @@ static int dispatch_rw_block_io(struct xen_blkif *blkif,
>  	 * the hypercall to unmap the grants - that is all done in
>  	 * xen_blkbk_unmap.
>  	 */
> -	if (xen_blkbk_map(req, pending_req, seg))
> +	if (xen_blkbk_map(req, pending_req, seg, pages))
>  		goto fail_flush;
>  
>  	/*
> @@ -688,7 +804,7 @@ static int dispatch_rw_block_io(struct xen_blkif *blkif,
>  	for (i = 0; i < nseg; i++) {
>  		while ((bio == NULL) ||
>  		       (bio_add_page(bio,
> -				     blkbk->pending_page(pending_req, i),
> +				     pages[i],
>  				     seg[i].nsec << 9,
>  				     seg[i].buf & ~PAGE_MASK) == 0)) {
>  
> @@ -743,7 +859,8 @@ static int dispatch_rw_block_io(struct xen_blkif *blkif,
>  	return 0;
>  
>   fail_flush:
> -	xen_blkbk_unmap(pending_req);
> +	if (!blkif->can_grant_persist)
> +		xen_blkbk_unmap(pending_req);
>   fail_response:
>  	/* Haven't submitted any bio's yet. */
>  	make_response(blkif, req->u.rw.id, req->operation, BLKIF_RSP_ERROR);
> diff --git a/drivers/block/xen-blkback/common.h b/drivers/block/xen-blkback/common.h
> index 9ad3b5e..1ecb709 100644
> --- a/drivers/block/xen-blkback/common.h
> +++ b/drivers/block/xen-blkback/common.h
> @@ -47,6 +47,8 @@
>  #define DPRINTK(fmt, args...)				\
>  	pr_debug(DRV_PFX "(%s:%d) " fmt ".\n",		\
>  		 __func__, __LINE__, ##args)
> +#define BLKIF_MAX_PERS_REQUESTS_PER_DEV 256
> +
>  
>  
>  /* Not a real protocol.  Used to generate ring structs which contain
> @@ -164,6 +166,14 @@ struct xen_vbd {
>  
>  struct backend_info;
>  
> +
> +struct pers_gnt {
> +	struct page *page;
> +	grant_ref_t gnt;
> +	uint32_t handle;
> +	uint64_t dev_bus_addr;
> +};
> +
>  struct xen_blkif {
>  	/* Unique identifier for this interface. */
>  	domid_t			domid;
> @@ -190,6 +200,12 @@ struct xen_blkif {
>  	struct task_struct	*xenblkd;
>  	unsigned int		waiting_reqs;
>  
> +	/* frontend feature information */
> +	u8			can_grant_persist:1;
> +	struct pers_gnt		*pers_gnts[BLKIF_MAX_PERS_REQUESTS_PER_DEV *
> +					  BLKIF_MAX_SEGMENTS_PER_REQUEST];
> +	unsigned int		pers_gnt_c;
> +
>  	/* statistics */
>  	unsigned long		st_print;
>  	int			st_rd_req;
> diff --git a/drivers/block/xen-blkback/xenbus.c b/drivers/block/xen-blkback/xenbus.c
> index 4f66171..dc58cc4 100644
> --- a/drivers/block/xen-blkback/xenbus.c
> +++ b/drivers/block/xen-blkback/xenbus.c
> @@ -681,6 +681,13 @@ again:
>  		goto abort;
>  	}
>  
> +	err = xenbus_printf(xbt, dev->nodename, "feature-persistent-grants",
> +			    "%d", 1);
> +	if (err) {
> +		xenbus_dev_fatal(dev, err, "writing persistent capability");
> +		goto abort;
> +	}
> +
>  	/* FIXME: use a typename instead */
>  	err = xenbus_printf(xbt, dev->nodename, "info", "%u",
>  			    be->blkif->vbd.type |
> @@ -721,6 +728,7 @@ static int connect_ring(struct backend_info *be)
>  	struct xenbus_device *dev = be->dev;
>  	unsigned long ring_ref;
>  	unsigned int evtchn;
> +	u8 pers_grants;
>  	char protocol[64] = "";
>  	int err;
>  
> @@ -750,8 +758,17 @@ static int connect_ring(struct backend_info *be)
>  		xenbus_dev_fatal(dev, err, "unknown fe protocol %s", protocol);
>  		return -1;
>  	}
> -	pr_info(DRV_PFX "ring-ref %ld, event-channel %d, protocol %d (%s)\n",
> -		ring_ref, evtchn, be->blkif->blk_protocol, protocol);
> +	err = xenbus_gather(XBT_NIL, dev->otherend,
> +			    "feature-persistent-grants", "%d",
> +			    &pers_grants, NULL);
> +	if (err)
> +		pers_grants = 0;
> +
> +	be->blkif->can_grant_persist = pers_grants;
> +
> +	pr_info(DRV_PFX "ring-ref %ld, event-channel %d, protocol %d (%s) persistent %d\n",
> +		ring_ref, evtchn, be->blkif->blk_protocol, protocol,
> +		pers_grants);
>  
>  	/* Map the shared frame, irq etc. */
>  	err = xen_blkif_map(be->blkif, ring_ref, evtchn);
> diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c
> index e4fb337..c1cc5fe 100644
> --- a/drivers/block/xen-blkfront.c
> +++ b/drivers/block/xen-blkfront.c
> @@ -68,6 +68,13 @@ struct blk_shadow {
>  	struct blkif_request req;
>  	struct request *request;
>  	unsigned long frame[BLKIF_MAX_SEGMENTS_PER_REQUEST];
> +	struct gnt_list *grants_used[BLKIF_MAX_SEGMENTS_PER_REQUEST];
> +};
> +
> +struct gnt_list {
> +	grant_ref_t gref;
> +	unsigned long frame;
> +	struct gnt_list *tail;
>  };
>  
>  static DEFINE_MUTEX(blkfront_mutex);
> @@ -97,11 +104,14 @@ struct blkfront_info
>  	struct work_struct work;
>  	struct gnttab_free_callback callback;
>  	struct blk_shadow shadow[BLK_RING_SIZE];
> +	struct gnt_list *persistent_grants_front;
> +	unsigned int persistent_grants_c;
>  	unsigned long shadow_free;
>  	unsigned int feature_flush;
>  	unsigned int flush_op;
>  	unsigned int feature_discard:1;
>  	unsigned int feature_secdiscard:1;
> +	unsigned int feature_persistent:1;
>  	unsigned int discard_granularity;
>  	unsigned int discard_alignment;
>  	int is_ready;
> @@ -286,22 +296,37 @@ static int blkif_queue_request(struct request *req)
>  	struct blkif_request *ring_req;
>  	unsigned long id;
>  	unsigned int fsect, lsect;
> -	int i, ref;
> +	int i, ref, use_pers_gnts, new_pers_gnts;
>  	grant_ref_t gref_head;
> +	struct bio_vec *bvecs[BLKIF_MAX_SEGMENTS_PER_REQUEST];
> +	struct bio_vec *bvec;
> +	struct req_iterator iter;
> +	char *bvec_data;
> +	void *shared_data;
> +	unsigned long flags;
> +	struct page *shared_page;
> +	struct gnt_list *gnt_list_entry;
>  	struct scatterlist *sg;
>  
>  	if (unlikely(info->connected != BLKIF_STATE_CONNECTED))
>  		return 1;
>  
> -	if (gnttab_alloc_grant_references(
> -		BLKIF_MAX_SEGMENTS_PER_REQUEST, &gref_head) < 0) {
> -		gnttab_request_free_callback(
> -			&info->callback,
> -			blkif_restart_queue_callback,
> -			info,
> -			BLKIF_MAX_SEGMENTS_PER_REQUEST);
> -		return 1;
> +	use_pers_gnts = info->feature_persistent;
> +
> +	if (info->persistent_grants_c < BLKIF_MAX_SEGMENTS_PER_REQUEST) {
> +		new_pers_gnts = 1;
> +		if (gnttab_alloc_grant_references(
> +			    BLKIF_MAX_SEGMENTS_PER_REQUEST, &gref_head) < 0) {
> +			gnttab_request_free_callback(
> +				&info->callback,
> +				blkif_restart_queue_callback,
> +				info,
> +				BLKIF_MAX_SEGMENTS_PER_REQUEST);
> +			return 1;
> +		}
>  	} else
> +		new_pers_gnts = 0;
>  
>  	/* Fill out a communications ring structure. */
>  	ring_req = RING_GET_REQUEST(&info->ring, info->ring.req_prod_pvt);
> @@ -341,20 +366,66 @@ static int blkif_queue_request(struct request *req)
>  		       BLKIF_MAX_SEGMENTS_PER_REQUEST);
>  
>  		for_each_sg(info->sg, sg, ring_req->u.rw.nr_segments, i) {
> -			buffer_mfn = pfn_to_mfn(page_to_pfn(sg_page(sg)));
>  			fsect = sg->offset >> 9;
>  			lsect = fsect + (sg->length >> 9) - 1;
> -			/* install a grant reference. */
> -			ref = gnttab_claim_grant_reference(&gref_head);
> -			BUG_ON(ref == -ENOSPC);
>  
> -			gnttab_grant_foreign_access_ref(
> +			if (use_pers_gnts && info->persistent_grants_c) {
> +				gnt_list_entry = info->persistent_grants_front;
> +
> +				info->persistent_grants_front =
> +					info->persistent_grants_front->tail;
> +				ref = gnt_list_entry->gref;
> +				buffer_mfn = pfn_to_mfn(gnt_list_entry->frame);
> +				info->persistent_grants_c--;
> +			} else {
> +				ref = gnttab_claim_grant_reference(&gref_head);
> +				BUG_ON(ref == -ENOSPC);
> +
> +				if (use_pers_gnts) {
> +					gnt_list_entry =
> +						kmalloc(sizeof(struct gnt_list),
> +								 GFP_ATOMIC);
> +					if (!gnt_list_entry)
> +						return -ENOMEM;
> +
> +					shared_page = alloc_page(GFP_ATOMIC);
> +					if (!shared_page)
> +						return -ENOMEM;
> +
> +					gnt_list_entry->frame =
> +						page_to_pfn(shared_page);
> +					gnt_list_entry->gref = ref;
> +				} else
> +					shared_page = sg_page(sg);
> +
> +				buffer_mfn = pfn_to_mfn(page_to_pfn(
> +								shared_page));
> +				gnttab_grant_foreign_access_ref(
>  					ref,
>  					info->xbdev->otherend_id,
>  					buffer_mfn,
> -					rq_data_dir(req));
> +					!use_pers_gnts && rq_data_dir(req));
> +			}
> +
> +			if (use_pers_gnts)
> +				info->shadow[id].grants_used[i] =
> +					gnt_list_entry;
> +
> +			if (use_pers_gnts && rq_data_dir(req)) {
> +				shared_data = kmap_atomic(
> +					pfn_to_page(gnt_list_entry->frame));
> +				bvec_data = kmap_atomic(sg_page(sg));
> +
> +				memcpy(shared_data + sg->offset,
> +				       bvec_data   + sg->offset,
> +				       sg->length);
> +
> +				kunmap_atomic(bvec_data);
> +				kunmap_atomic(shared_data);
> +			}
>  
>  			info->shadow[id].frame[i] = mfn_to_pfn(buffer_mfn);
> +
>  			ring_req->u.rw.seg[i] =
>  					(struct blkif_request_segment) {
>  						.gref       = ref,
> @@ -368,7 +439,8 @@ static int blkif_queue_request(struct request *req)
>  	/* Keep a private copy so we can reissue requests when recovering. */
>  	info->shadow[id].req = *ring_req;
>  
> -	gnttab_free_grant_references(gref_head);
> +	if (new_pers_gnts)
> +		gnttab_free_grant_references(gref_head);
>  
>  	return 0;
>  }
> @@ -480,12 +552,13 @@ static int xlvbd_init_blk_queue(struct gendisk *gd, u16 sector_size)
>  static void xlvbd_flush(struct blkfront_info *info)
>  {
>  	blk_queue_flush(info->rq, info->feature_flush);
> -	printk(KERN_INFO "blkfront: %s: %s: %s\n",
> +	printk(KERN_INFO "blkfront: %s: %s: %s. Persistent=%d\n",
>  	       info->gd->disk_name,
>  	       info->flush_op == BLKIF_OP_WRITE_BARRIER ?
>  		"barrier" : (info->flush_op == BLKIF_OP_FLUSH_DISKCACHE ?
>  		"flush diskcache" : "barrier or flush"),
> -	       info->feature_flush ? "enabled" : "disabled");
> +	       info->feature_flush ? "enabled" : "disabled",
> +	    info->feature_persistent);
>  }
>  
>  static int xen_translate_vdev(int vdevice, int *minor, unsigned int *offset)
> @@ -707,6 +780,8 @@ static void blkif_restart_queue(struct work_struct *work)
>  
>  static void blkif_free(struct blkfront_info *info, int suspend)
>  {
> +	struct gnt_list *pers_gnt;
> +
>  	/* Prevent new requests being issued until we fix things up. */
>  	spin_lock_irq(&info->io_lock);
>  	info->connected = suspend ?
> @@ -714,6 +789,15 @@ static void blkif_free(struct blkfront_info *info, int suspend)
>  	/* No more blkif_request(). */
>  	if (info->rq)
>  		blk_stop_queue(info->rq);
> +
> +	/* Remove all persistent grants */
> +	while (info->persistent_grants_front) {
> +		pers_gnt = info->persistent_grants_front;
> +		info->persistent_grants_front = pers_gnt->tail;
> +		gnttab_end_foreign_access(pers_gnt->gref, 0, 0UL);
> +		kfree(pers_gnt);
> +	}
> +
>  	/* No more gnttab callback work. */
>  	gnttab_cancel_free_callback(&info->callback);
>  	spin_unlock_irq(&info->io_lock);
> @@ -734,13 +818,44 @@ static void blkif_free(struct blkfront_info *info, int suspend)
>  
>  }
>  
> -static void blkif_completion(struct blk_shadow *s)
> +static void blkif_completion(struct blk_shadow *s, struct blkfront_info *info,
> +			     struct blkif_response *bret)
>  {
>  	int i;
> -	/* Do not let BLKIF_OP_DISCARD as nr_segment is in the same place
> -	 * flag. */
> -	for (i = 0; i < s->req.u.rw.nr_segments; i++)
> -		gnttab_end_foreign_access(s->req.u.rw.seg[i].gref, 0, 0UL);
> +	struct gnt_list *new_gnt_list_entry;
> +	struct bio_vec *bvec;
> +	struct req_iterator iter;
> +	unsigned long flags;
> +	char *bvec_data;
> +	void *shared_data;
> +
> +	i = 0;
> +	if (info->feature_persistent == 0) {
> +		/* Do not let BLKIF_OP_DISCARD as nr_segment is in the same
> +		 * place flag. */
> +		for (i = 0; i < s->req.u.rw.nr_segments; i++)
> +			gnttab_end_foreign_access(s->req.u.rw.seg[i].gref,
> +						  0, 0UL);
> +		return;
> +	}
> +
> +	if (bret->operation == BLKIF_OP_READ)
> +		rq_for_each_segment(bvec, s->request, iter) {
> +			shared_data = kmap_atomic
> +				(pfn_to_page(s->grants_used[i++]->frame));
> +			bvec_data = bvec_kmap_irq(bvec, &flags);
> +			memcpy(bvec_data, shared_data + bvec->bv_offset,
> +			       bvec->bv_len);
> +			bvec_kunmap_irq(bvec_data, &flags);
> +			kunmap_atomic(shared_data);
> +		}
> +	/* Add the persistent grant into the list of free grants */
> +	for (i = 0; i < s->req.u.rw.nr_segments; i++) {
> +		new_gnt_list_entry = s->grants_used[i];
> +		new_gnt_list_entry->tail = info->persistent_grants_front;
> +		info->persistent_grants_front = new_gnt_list_entry;
> +		info->persistent_grants_c++;
> +	}
>  }
>  
>  static irqreturn_t blkif_interrupt(int irq, void *dev_id)
> @@ -783,7 +898,7 @@ static irqreturn_t blkif_interrupt(int irq, void *dev_id)
>  		req  = info->shadow[id].request;
>  
>  		if (bret->operation != BLKIF_OP_DISCARD)
> -			blkif_completion(&info->shadow[id]);
> +			blkif_completion(&info->shadow[id], info, bret);
>  
>  		if (add_id_to_freelist(info, id)) {
>  			WARN(1, "%s: response to %s (id %ld) couldn't be recycled!\n",
> @@ -943,6 +1058,12 @@ again:
>  		message = "writing protocol";
>  		goto abort_transaction;
>  	}
> +	err = xenbus_printf(xbt, dev->nodename,
> +			    "feature-persistent-grants", "%d", 1);
> +	if (err) {
> +		message = "Writing persistent grants front feature";
> +		goto abort_transaction;
> +	}
>  
>  	err = xenbus_transaction_end(xbt, 0);
>  	if (err) {
> @@ -1030,6 +1151,7 @@ static int blkfront_probe(struct xenbus_device *dev,
>  	spin_lock_init(&info->io_lock);
>  	info->xbdev = dev;
>  	info->vdevice = vdevice;
> +	info->persistent_grants_c = 0;
>  	info->connected = BLKIF_STATE_DISCONNECTED;
>  	INIT_WORK(&info->work, blkif_restart_queue);
>  
> @@ -1094,6 +1216,7 @@ static int blkif_recover(struct blkfront_info *info)
>  					req->u.rw.seg[j].gref,
>  					info->xbdev->otherend_id,
>  					pfn_to_mfn(info->shadow[req->u.rw.id].frame[j]),
> +					!info->feature_persistent &&
>  					rq_data_dir(info->shadow[req->u.rw.id].request));
>  		}
>  		info->shadow[req->u.rw.id].req = *req;
> @@ -1226,7 +1349,7 @@ static void blkfront_connect(struct blkfront_info *info)
>  	unsigned long sector_size;
>  	unsigned int binfo;
>  	int err;
> -	int barrier, flush, discard;
> +	int barrier, flush, discard, persistent;
>  
>  	switch (info->connected) {
>  	case BLKIF_STATE_CONNECTED:
> @@ -1297,6 +1420,19 @@ static void blkfront_connect(struct blkfront_info *info)
>  		info->flush_op = BLKIF_OP_FLUSH_DISKCACHE;
>  	}
>  
> +	/*
> +	 * Are we dealing with an old blkback that will unmap
> +	 * all grefs?
> +	 */
> +	err = xenbus_gather(XBT_NIL, info->xbdev->otherend,
> +			    "feature-persistent-grants", "%d", &persistent,
> +			    NULL);
> +
> +	if (err)
> +		info->feature_persistent = 0;
> +	else
> +		info->feature_persistent = persistent;
> +
>  	err = xenbus_gather(XBT_NIL, info->xbdev->otherend,
>  			    "feature-discard", "%d", &discard,
>  			    NULL);
> diff --git a/include/xen/interface/io/blkif.h b/include/xen/interface/io/blkif.h
> index ee338bf..cd267a9b 100644
> --- a/include/xen/interface/io/blkif.h
> +++ b/include/xen/interface/io/blkif.h
> @@ -109,6 +109,15 @@ typedef uint64_t blkif_sector_t;
>   */
>  #define BLKIF_MAX_SEGMENTS_PER_REQUEST 11
>  
> +/*
> + * Maximum number of persistent grants that can be mapped by Dom0 for each
> + * interface. This is set to be the size of the ring, as this is a limit on
> + * the number of requests that can be inflight at any one time. 256 imposes
> + * an overhead of 11MB of mapped kernel space per interface.
> + */
> +#define BLKIF_MAX_PERS_REQUESTS_PER_DEV 256
> +
> +
>  struct blkif_request_rw {
>  	uint8_t        nr_segments;  /* number of segments                   */
>  	blkif_vdev_t   handle;       /* only for read/write requests         */
> -- 
> 1.7.9.5

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 19 11:34:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Sep 2012 11:34: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 1TEIXY-0000Kj-Up; Wed, 19 Sep 2012 11:34: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 1TEIXX-0000Kd-Ga
	for xen-devel@lists.xensource.com; Wed, 19 Sep 2012 11:33:59 +0000
Received: from [85.158.143.99:23486] by server-1.bemta-4.messagelabs.com id
	FF/1A-05684-6ADA9505; Wed, 19 Sep 2012 11:33:58 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1348054438!21178705!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTAxNzU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14063 invoked from network); 19 Sep 2012 11:33:58 -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;
	19 Sep 2012 11:33:58 -0000
X-IronPort-AV: E=Sophos;i="4.80,447,1344211200"; d="scan'208";a="14628917"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Sep 2012 11:33: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.279.1; Wed, 19 Sep 2012 12:33: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 1TEIXV-00014L-I8;
	Wed, 19 Sep 2012 11:33:57 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1TEIXV-0006f2-BW;
	Wed, 19 Sep 2012 12:33:57 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-13811-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 19 Sep 2012 12:33:57 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [qemu-upstream-4.2-testing test] 13811: 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 13811 qemu-upstream-4.2-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13811/

Failures :-/ but no regressions.

Tests which did not succeed,
including tests which could not be run:
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  9 guest-localmigrate fail never pass
 test-amd64-i386-xl-qemuu-win-vcpus1  9 guest-localmigrate      fail never pass
 test-amd64-amd64-qemuu-win   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64  9 guest-localmigrate      fail never pass
 test-i386-i386-qemuu-win     16 leak-check/check             fail   never pass
 test-i386-i386-xl-qemuu-win   9 guest-localmigrate           fail   never pass
 test-amd64-i386-qemuu-win-vcpus1 16 leak-check/check           fail never pass
 test-amd64-i386-xend-qemuu-winxpsp3 16 leak-check/check        fail never pass
 test-amd64-amd64-xl-qemuu-win  9 guest-localmigrate           fail  never pass
 test-amd64-i386-qemuu-win    16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail never pass
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass


jobs:
 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                           pass    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-win-vcpus1                             fail    
 test-amd64-i386-xl-qemuu-win-vcpus1                          fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-amd64-qemuu-win                                   fail    
 test-amd64-i386-qemuu-win                                    fail    
 test-i386-i386-qemuu-win                                     fail    
 test-amd64-amd64-xl-qemuu-win                                fail    
 test-i386-i386-xl-qemuu-win                                  fail    
 test-amd64-i386-xend-qemuu-winxpsp3                          fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 19 11:34:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Sep 2012 11:34: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 1TEIXY-0000Kj-Up; Wed, 19 Sep 2012 11:34: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 1TEIXX-0000Kd-Ga
	for xen-devel@lists.xensource.com; Wed, 19 Sep 2012 11:33:59 +0000
Received: from [85.158.143.99:23486] by server-1.bemta-4.messagelabs.com id
	FF/1A-05684-6ADA9505; Wed, 19 Sep 2012 11:33:58 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1348054438!21178705!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTAxNzU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14063 invoked from network); 19 Sep 2012 11:33:58 -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;
	19 Sep 2012 11:33:58 -0000
X-IronPort-AV: E=Sophos;i="4.80,447,1344211200"; d="scan'208";a="14628917"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Sep 2012 11:33: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.279.1; Wed, 19 Sep 2012 12:33: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 1TEIXV-00014L-I8;
	Wed, 19 Sep 2012 11:33:57 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1TEIXV-0006f2-BW;
	Wed, 19 Sep 2012 12:33:57 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-13811-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 19 Sep 2012 12:33:57 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [qemu-upstream-4.2-testing test] 13811: 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 13811 qemu-upstream-4.2-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13811/

Failures :-/ but no regressions.

Tests which did not succeed,
including tests which could not be run:
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  9 guest-localmigrate fail never pass
 test-amd64-i386-xl-qemuu-win-vcpus1  9 guest-localmigrate      fail never pass
 test-amd64-amd64-qemuu-win   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64  9 guest-localmigrate      fail never pass
 test-i386-i386-qemuu-win     16 leak-check/check             fail   never pass
 test-i386-i386-xl-qemuu-win   9 guest-localmigrate           fail   never pass
 test-amd64-i386-qemuu-win-vcpus1 16 leak-check/check           fail never pass
 test-amd64-i386-xend-qemuu-winxpsp3 16 leak-check/check        fail never pass
 test-amd64-amd64-xl-qemuu-win  9 guest-localmigrate           fail  never pass
 test-amd64-i386-qemuu-win    16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail never pass
 test-i386-i386-xl-qemuu-winxpsp3  7 windows-install            fail never pass


jobs:
 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                           pass    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-win-vcpus1                             fail    
 test-amd64-i386-xl-qemuu-win-vcpus1                          fail    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     fail    
 test-amd64-amd64-qemuu-win                                   fail    
 test-amd64-i386-qemuu-win                                    fail    
 test-i386-i386-qemuu-win                                     fail    
 test-amd64-amd64-xl-qemuu-win                                fail    
 test-i386-i386-xl-qemuu-win                                  fail    
 test-amd64-i386-xend-qemuu-winxpsp3                          fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 19 11:40:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Sep 2012 11: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 1TEIe1-0000Ud-AA; Wed, 19 Sep 2012 11:40:41 +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 1TEIdz-0000UY-9s
	for xen-devel@lists.xen.org; Wed, 19 Sep 2012 11:40:39 +0000
Received: from [85.158.137.99:53767] by server-1.bemta-3.messagelabs.com id
	3F/A9-05884-63FA9505; Wed, 19 Sep 2012 11:40:38 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-3.tower-217.messagelabs.com!1348054837!13232690!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-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8818 invoked from network); 19 Sep 2012 11:40:38 -0000
Received: from mail-ey0-f173.google.com (HELO mail-ey0-f173.google.com)
	(209.85.215.173)
	by server-3.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Sep 2012 11:40:38 -0000
Received: by eaac13 with SMTP id c13so297127eaa.32
	for <xen-devel@lists.xen.org>; Wed, 19 Sep 2012 04:40:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=Y8VxHl2oESuKIyjDzuSwSytPyyoMZjx52bxrLdZcSvc=;
	b=yDNoHr7dgIg3wRfL7+R49P2moEYiWSWKoLQzt30MPMUsN4/n7MwhEi4gwLfL5Kkqc7
	FPlJcOzrQWHdXHnXT7OqaVLU5E2U4MNfyFv3LP03HJTV2YWq3t7rb9OVwCUxSrY7TSwK
	NTz/HX5Dq1Dwk9m9GNhpo8Crwx+NnTfFPLqXUZP86A634mCD7BQndYqIMTVZDAzlu0n6
	q93W5w9eDOLEfYpOCtWwnxqEP5Ibs2woD8SWj1Bxi6wgRjYolk9kOU8zeEv0y7KS0JRq
	1Ebl49nx0BmPUD4Q79MfG7/1I2hJi2XSuzRMiZpJXo5sJisMt2lxeo0XuOtK91BLZkTh
	K/6g==
Received: by 10.14.193.136 with SMTP id k8mr3346550een.9.1348054837726;
	Wed, 19 Sep 2012 04:40:37 -0700 (PDT)
Received: from [192.168.1.69] (host86-167-82-156.range86-167.btcentralplus.com.
	[86.167.82.156])
	by mx.google.com with ESMTPS id 46sm6455519eef.17.2012.09.19.04.40.34
	(version=SSLv3 cipher=OTHER); Wed, 19 Sep 2012 04:40:36 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Wed, 19 Sep 2012 12:40:32 +0100
From: Keir Fraser <keir.xen@gmail.com>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <CC7F6DC0.3F265%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [PATCH] ACPI: move tables.c fully into .init.*
Thread-Index: Ac2WW5M8XTPyESW9V0irC6xoKEHauw==
In-Reply-To: <5059A56C020000780009C430@nat28.tlf.novell.com>
Mime-version: 1.0
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] ACPI: move tables.c fully into .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 19/09/2012 09:58, "Jan Beulich" <JBeulich@suse.com> wrote:

> Of course, if you're only against the dynamic allocation, moving
> the array elsewhere would be another option (but would require
> making the symbol global, whereas here the symbol goes away
> altogether from the symbol tables).
> 
> Yet another option would be to do the dynamic allocation where
> it was actually intended to be done, passing NULL here. The
> resizing there isn't being made use of anyway (and wouldn't
> work afaict), so we could as well do away with it and replace it
> by the simple allocation needed here (or simply fix it,
> considering that we might need it at some point).

I'm not wild about any of the options really. Perhaps passing NULL would be
best. Still, overall, I'm not *that* bothered. You can have my Ack for the
original patch:
Acked-by: Keir Fraser <keir@xen.org>

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 19 11:40:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Sep 2012 11: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 1TEIe1-0000Ud-AA; Wed, 19 Sep 2012 11:40:41 +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 1TEIdz-0000UY-9s
	for xen-devel@lists.xen.org; Wed, 19 Sep 2012 11:40:39 +0000
Received: from [85.158.137.99:53767] by server-1.bemta-3.messagelabs.com id
	3F/A9-05884-63FA9505; Wed, 19 Sep 2012 11:40:38 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-3.tower-217.messagelabs.com!1348054837!13232690!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-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8818 invoked from network); 19 Sep 2012 11:40:38 -0000
Received: from mail-ey0-f173.google.com (HELO mail-ey0-f173.google.com)
	(209.85.215.173)
	by server-3.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Sep 2012 11:40:38 -0000
Received: by eaac13 with SMTP id c13so297127eaa.32
	for <xen-devel@lists.xen.org>; Wed, 19 Sep 2012 04:40:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=Y8VxHl2oESuKIyjDzuSwSytPyyoMZjx52bxrLdZcSvc=;
	b=yDNoHr7dgIg3wRfL7+R49P2moEYiWSWKoLQzt30MPMUsN4/n7MwhEi4gwLfL5Kkqc7
	FPlJcOzrQWHdXHnXT7OqaVLU5E2U4MNfyFv3LP03HJTV2YWq3t7rb9OVwCUxSrY7TSwK
	NTz/HX5Dq1Dwk9m9GNhpo8Crwx+NnTfFPLqXUZP86A634mCD7BQndYqIMTVZDAzlu0n6
	q93W5w9eDOLEfYpOCtWwnxqEP5Ibs2woD8SWj1Bxi6wgRjYolk9kOU8zeEv0y7KS0JRq
	1Ebl49nx0BmPUD4Q79MfG7/1I2hJi2XSuzRMiZpJXo5sJisMt2lxeo0XuOtK91BLZkTh
	K/6g==
Received: by 10.14.193.136 with SMTP id k8mr3346550een.9.1348054837726;
	Wed, 19 Sep 2012 04:40:37 -0700 (PDT)
Received: from [192.168.1.69] (host86-167-82-156.range86-167.btcentralplus.com.
	[86.167.82.156])
	by mx.google.com with ESMTPS id 46sm6455519eef.17.2012.09.19.04.40.34
	(version=SSLv3 cipher=OTHER); Wed, 19 Sep 2012 04:40:36 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Wed, 19 Sep 2012 12:40:32 +0100
From: Keir Fraser <keir.xen@gmail.com>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <CC7F6DC0.3F265%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [PATCH] ACPI: move tables.c fully into .init.*
Thread-Index: Ac2WW5M8XTPyESW9V0irC6xoKEHauw==
In-Reply-To: <5059A56C020000780009C430@nat28.tlf.novell.com>
Mime-version: 1.0
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] ACPI: move tables.c fully into .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 19/09/2012 09:58, "Jan Beulich" <JBeulich@suse.com> wrote:

> Of course, if you're only against the dynamic allocation, moving
> the array elsewhere would be another option (but would require
> making the symbol global, whereas here the symbol goes away
> altogether from the symbol tables).
> 
> Yet another option would be to do the dynamic allocation where
> it was actually intended to be done, passing NULL here. The
> resizing there isn't being made use of anyway (and wouldn't
> work afaict), so we could as well do away with it and replace it
> by the simple allocation needed here (or simply fix it,
> considering that we might need it at some point).

I'm not wild about any of the options really. Perhaps passing NULL would be
best. Still, overall, I'm not *that* bothered. You can have my Ack for the
original patch:
Acked-by: Keir Fraser <keir@xen.org>

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 19 12:04:27 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Sep 2012 12: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 1TEJ0W-0000r2-Tv; Wed, 19 Sep 2012 12:03:56 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1TEJ0V-0000qq-3q
	for xen-devel@lists.xen.org; Wed, 19 Sep 2012 12:03:55 +0000
Received: from [85.158.139.211:37147] by server-7.bemta-5.messagelabs.com id
	54/4A-19703-AA4B9505; Wed, 19 Sep 2012 12:03:54 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-13.tower-206.messagelabs.com!1348056233!15176582!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5808 invoked from network); 19 Sep 2012 12:03:53 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-13.tower-206.messagelabs.com with SMTP;
	19 Sep 2012 12:03:53 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 19 Sep 2012 13:04:36 +0100
Message-Id: <5059D0C8020000780009C4CF@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 19 Sep 2012 13:03:52 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Oliver Chick" <oliver.chick@citrix.com>
References: <1348051887-21885-1-git-send-email-oliver.chick@citrix.com>
In-Reply-To: <1348051887-21885-1-git-send-email-oliver.chick@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: konrad.wilk@oracle.com, linux-kernel@vger.kernel.org,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] Persistent grant maps for xen blk drivers
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 19.09.12 at 12:51, Oliver Chick <oliver.chick@citrix.com> wrote:
> +/*
> + * Maximum number of persistent grants that can be mapped by Dom0 for each
> + * interface. This is set to be the size of the ring, as this is a limit on
> + * the number of requests that can be inflight at any one time. 256 imposes
> + * an overhead of 11MB of mapped kernel space per interface.
> + */
> +#define BLKIF_MAX_PERS_REQUESTS_PER_DEV 256

How can this be a fixed number, especially in the context of ring
size extensions? Iirc, single page rings can accommodate 64
requests, so I'd guess the number above was observed with a
4-page (order 2) ring...

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 19 12:04:27 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Sep 2012 12: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 1TEJ0W-0000r2-Tv; Wed, 19 Sep 2012 12:03:56 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1TEJ0V-0000qq-3q
	for xen-devel@lists.xen.org; Wed, 19 Sep 2012 12:03:55 +0000
Received: from [85.158.139.211:37147] by server-7.bemta-5.messagelabs.com id
	54/4A-19703-AA4B9505; Wed, 19 Sep 2012 12:03:54 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-13.tower-206.messagelabs.com!1348056233!15176582!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5808 invoked from network); 19 Sep 2012 12:03:53 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-13.tower-206.messagelabs.com with SMTP;
	19 Sep 2012 12:03:53 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 19 Sep 2012 13:04:36 +0100
Message-Id: <5059D0C8020000780009C4CF@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 19 Sep 2012 13:03:52 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Oliver Chick" <oliver.chick@citrix.com>
References: <1348051887-21885-1-git-send-email-oliver.chick@citrix.com>
In-Reply-To: <1348051887-21885-1-git-send-email-oliver.chick@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: konrad.wilk@oracle.com, linux-kernel@vger.kernel.org,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] Persistent grant maps for xen blk drivers
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 19.09.12 at 12:51, Oliver Chick <oliver.chick@citrix.com> wrote:
> +/*
> + * Maximum number of persistent grants that can be mapped by Dom0 for each
> + * interface. This is set to be the size of the ring, as this is a limit on
> + * the number of requests that can be inflight at any one time. 256 imposes
> + * an overhead of 11MB of mapped kernel space per interface.
> + */
> +#define BLKIF_MAX_PERS_REQUESTS_PER_DEV 256

How can this be a fixed number, especially in the context of ring
size extensions? Iirc, single page rings can accommodate 64
requests, so I'd guess the number above was observed with a
4-page (order 2) ring...

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 19 12:08:30 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Sep 2012 12:08:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TEJ4d-00013E-LV; Wed, 19 Sep 2012 12:08: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 1TEJ4b-000138-LG
	for xen-devel@lists.xensource.com; Wed, 19 Sep 2012 12:08:09 +0000
Received: from [85.158.143.35:26495] by server-1.bemta-4.messagelabs.com id
	2F/9E-05684-9A5B9505; Wed, 19 Sep 2012 12:08:09 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1348056466!16479678!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTAxNzU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16145 invoked from network); 19 Sep 2012 12:07:47 -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 Sep 2012 12:07:47 -0000
X-IronPort-AV: E=Sophos;i="4.80,447,1344211200"; d="scan'208";a="14629685"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Sep 2012 12:07: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.279.1;
	Wed, 19 Sep 2012 13:07:46 +0100
Message-ID: <1348056465.14977.96.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
Date: Wed, 19 Sep 2012 13:07:45 +0100
In-Reply-To: <50579F53.4070302@jhuapl.edu>
References: <50579F53.4070302@jhuapl.edu>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Samuel Thibault <samuel.thibault@ens-lyon.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH mini-os enhancements for vtpm 8/8] Add 3 tpm
 drivers to mini-os
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2012-09-17 at 23:08 +0100, Matthew Fioravante wrote:
> This patch adds 3 new drivers to mini-os.
> 
> tpmfront - paravirtualized tpm frontend driver
> tpmback - paravirtualized tpm backend driver
> tpm_tis - hardware tpm driver
> 
> Unfortunately these drivers were derived from GPL licensed linux kernel
> drivers so they must carry the GPL license.

I notice that you have used GPL v3 here, while the original Linux
versions of these files (I looked at 3.6-rc3)both say:
 * 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, version 2 of the
 * License.
i.e. doesn't contain the "or later" wording which would allow an upgrade
to v3. Did all of the copyright holders agree to this relicensing?

>  However, since mini-os now
> supports conditional compilation, hopefully these drivers can be
> included into the xen tree and conditionally removed from non-gpl
> projects. By default they are disabled in the makefile.

Are these drivers useful for other stub domains generally or are they
only really useful in the vtpm stub domains? IOW could this GPL code be
made part of the application instead?

This would allow better segregation between the BSD bits of mini-os and
GPL bits.

> Signed off by: Matthew Fioravante matthew.fioravante@jhuapl.edu

Can you confirm that you have the right to submit his code under this
license, since you are not listed in the copyright I guess that would be
clause B of the DCO:
http://wiki.xen.org/wiki/Submitting_Xen_Patches#Signing_off_a_patch

> diff --git a/extras/mini-os/include/tpm_tis.h
> b/extras/mini-os/include/tpm_tis.h
> --- /dev/null
> +++ b/extras/mini-os/include/tpm_tis.h
> @@ -0,0 +1,63 @@
> +/*
> + * Copyright (c) 2010-2012 United States Government, as represented by
> + * the Secretary of Defense.  All rights reserved.
> + *
> + * This driver 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 3 of the License, or
> + * (at your option) any later version.
> + *
> + * This driver is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program.  If not, see <http://www.gnu.org/licenses/>.
> + *
> + * Based upon the files:
> + *  drivers/char/tpm/tpm_tis.c
> + *  drivers/char/tpm/tpm.c
> + * from the Linux kernel, which are Copyright (C) 2006 IBM Corporation
> + */



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 19 12:08:30 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Sep 2012 12:08:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TEJ4d-00013E-LV; Wed, 19 Sep 2012 12:08: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 1TEJ4b-000138-LG
	for xen-devel@lists.xensource.com; Wed, 19 Sep 2012 12:08:09 +0000
Received: from [85.158.143.35:26495] by server-1.bemta-4.messagelabs.com id
	2F/9E-05684-9A5B9505; Wed, 19 Sep 2012 12:08:09 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1348056466!16479678!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTAxNzU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16145 invoked from network); 19 Sep 2012 12:07:47 -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 Sep 2012 12:07:47 -0000
X-IronPort-AV: E=Sophos;i="4.80,447,1344211200"; d="scan'208";a="14629685"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Sep 2012 12:07: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.279.1;
	Wed, 19 Sep 2012 13:07:46 +0100
Message-ID: <1348056465.14977.96.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
Date: Wed, 19 Sep 2012 13:07:45 +0100
In-Reply-To: <50579F53.4070302@jhuapl.edu>
References: <50579F53.4070302@jhuapl.edu>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Samuel Thibault <samuel.thibault@ens-lyon.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH mini-os enhancements for vtpm 8/8] Add 3 tpm
 drivers to mini-os
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2012-09-17 at 23:08 +0100, Matthew Fioravante wrote:
> This patch adds 3 new drivers to mini-os.
> 
> tpmfront - paravirtualized tpm frontend driver
> tpmback - paravirtualized tpm backend driver
> tpm_tis - hardware tpm driver
> 
> Unfortunately these drivers were derived from GPL licensed linux kernel
> drivers so they must carry the GPL license.

I notice that you have used GPL v3 here, while the original Linux
versions of these files (I looked at 3.6-rc3)both say:
 * 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, version 2 of the
 * License.
i.e. doesn't contain the "or later" wording which would allow an upgrade
to v3. Did all of the copyright holders agree to this relicensing?

>  However, since mini-os now
> supports conditional compilation, hopefully these drivers can be
> included into the xen tree and conditionally removed from non-gpl
> projects. By default they are disabled in the makefile.

Are these drivers useful for other stub domains generally or are they
only really useful in the vtpm stub domains? IOW could this GPL code be
made part of the application instead?

This would allow better segregation between the BSD bits of mini-os and
GPL bits.

> Signed off by: Matthew Fioravante matthew.fioravante@jhuapl.edu

Can you confirm that you have the right to submit his code under this
license, since you are not listed in the copyright I guess that would be
clause B of the DCO:
http://wiki.xen.org/wiki/Submitting_Xen_Patches#Signing_off_a_patch

> diff --git a/extras/mini-os/include/tpm_tis.h
> b/extras/mini-os/include/tpm_tis.h
> --- /dev/null
> +++ b/extras/mini-os/include/tpm_tis.h
> @@ -0,0 +1,63 @@
> +/*
> + * Copyright (c) 2010-2012 United States Government, as represented by
> + * the Secretary of Defense.  All rights reserved.
> + *
> + * This driver 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 3 of the License, or
> + * (at your option) any later version.
> + *
> + * This driver is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program.  If not, see <http://www.gnu.org/licenses/>.
> + *
> + * Based upon the files:
> + *  drivers/char/tpm/tpm_tis.c
> + *  drivers/char/tpm/tpm.c
> + * from the Linux kernel, which are Copyright (C) 2006 IBM Corporation
> + */



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 19 12:19:48 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Sep 2012 12: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 1TEJFV-0001GY-RF; Wed, 19 Sep 2012 12:19:25 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1TEJFU-0001GT-NM
	for xen-devel@lists.xensource.com; Wed, 19 Sep 2012 12:19:24 +0000
Received: from [85.158.137.99:34429] by server-7.bemta-3.messagelabs.com id
	DC/5E-32000-B48B9505; Wed, 19 Sep 2012 12:19:23 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-217.messagelabs.com!1348057162!18279861!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTAxNzU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8539 invoked from network); 19 Sep 2012 12:19:22 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Sep 2012 12:19:22 -0000
X-IronPort-AV: E=Sophos;i="4.80,447,1344211200"; d="scan'208";a="14630010"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Sep 2012 12:19:21 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 19 Sep 2012 13:19:21 +0100
Message-ID: <1348057160.14977.98.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
Date: Wed, 19 Sep 2012 13:19:20 +0100
In-Reply-To: <5058B8DB.5040109@jhuapl.edu>
References: <5058B8DB.5040109@jhuapl.edu>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH xm/xl enhancements for vptm 1/6] xl make
 devid a libxl 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 Tue, 2012-09-18 at 19:09 +0100, Matthew Fioravante wrote:
> diff --git a/tools/ocaml/libs/xc/xenctrl.ml b/tools/ocaml/libs/xc/xenctrl.ml
> --- a/tools/ocaml/libs/xc/xenctrl.ml
> +++ b/tools/ocaml/libs/xc/xenctrl.ml
> @@ -16,6 +16,7 @@
>  
>  (** *)
>  type domid = int
> +type devid = int

I don't think libxc exposes the notion of a devid, does it?

In which case there's no need to have a type for it here or in the .mli.
> diff --git a/tools/ocaml/libs/xs/xs.ml b/tools/ocaml/libs/xs/xs.ml
> --- a/tools/ocaml/libs/xs/xs.ml
> +++ b/tools/ocaml/libs/xs/xs.ml
> @@ -17,6 +17,7 @@
>  type perms = Xsraw.perms
>  type con = Xsraw.con
>  type domid = int
> +type devid = int

Likewise xenstore doesn't have a devid either AFAIK.

> 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

Are you basing your patches on xen-unstable? I ask because this file
isn't built there and so I wonder how you noticed it to change it.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 19 12:19:48 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Sep 2012 12: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 1TEJFV-0001GY-RF; Wed, 19 Sep 2012 12:19:25 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1TEJFU-0001GT-NM
	for xen-devel@lists.xensource.com; Wed, 19 Sep 2012 12:19:24 +0000
Received: from [85.158.137.99:34429] by server-7.bemta-3.messagelabs.com id
	DC/5E-32000-B48B9505; Wed, 19 Sep 2012 12:19:23 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-217.messagelabs.com!1348057162!18279861!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTAxNzU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8539 invoked from network); 19 Sep 2012 12:19:22 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Sep 2012 12:19:22 -0000
X-IronPort-AV: E=Sophos;i="4.80,447,1344211200"; d="scan'208";a="14630010"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Sep 2012 12:19:21 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 19 Sep 2012 13:19:21 +0100
Message-ID: <1348057160.14977.98.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
Date: Wed, 19 Sep 2012 13:19:20 +0100
In-Reply-To: <5058B8DB.5040109@jhuapl.edu>
References: <5058B8DB.5040109@jhuapl.edu>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH xm/xl enhancements for vptm 1/6] xl make
 devid a libxl 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 Tue, 2012-09-18 at 19:09 +0100, Matthew Fioravante wrote:
> diff --git a/tools/ocaml/libs/xc/xenctrl.ml b/tools/ocaml/libs/xc/xenctrl.ml
> --- a/tools/ocaml/libs/xc/xenctrl.ml
> +++ b/tools/ocaml/libs/xc/xenctrl.ml
> @@ -16,6 +16,7 @@
>  
>  (** *)
>  type domid = int
> +type devid = int

I don't think libxc exposes the notion of a devid, does it?

In which case there's no need to have a type for it here or in the .mli.
> diff --git a/tools/ocaml/libs/xs/xs.ml b/tools/ocaml/libs/xs/xs.ml
> --- a/tools/ocaml/libs/xs/xs.ml
> +++ b/tools/ocaml/libs/xs/xs.ml
> @@ -17,6 +17,7 @@
>  type perms = Xsraw.perms
>  type con = Xsraw.con
>  type domid = int
> +type devid = int

Likewise xenstore doesn't have a devid either AFAIK.

> 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

Are you basing your patches on xen-unstable? I ask because this file
isn't built there and so I wonder how you noticed it to change it.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 19 12:25:24 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Sep 2012 12:25:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TEJL3-0001dM-2X; Wed, 19 Sep 2012 12:25:09 +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 1TEJL1-0001cY-D0
	for xen-devel@lists.xensource.com; Wed, 19 Sep 2012 12:25:07 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1348057500!9634897!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTAxNzU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25653 invoked from network); 19 Sep 2012 12:25:00 -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;
	19 Sep 2012 12:25:00 -0000
X-IronPort-AV: E=Sophos;i="4.80,447,1344211200"; d="scan'208";a="14630191"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Sep 2012 12:25: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.279.1;
	Wed, 19 Sep 2012 13:25:00 +0100
Message-ID: <1348057499.14977.102.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
Date: Wed, 19 Sep 2012 13:24:59 +0100
In-Reply-To: <5058B969.4020503@jhuapl.edu>
References: <5058B969.4020503@jhuapl.edu>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH xm/xl enhancements for vptm 2/6] add vtpm
 support to 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

On Tue, 2012-09-18 at 19:11 +0100, Matthew Fioravante wrote:
> This patch adds vtpm support to libxl. It adds vtpm parsing to config
> files and 3 new xl commands:
> vtpm-attach
> vtpm-detach
> vtpm-list

Please can you patch docs/man/xl* as appropriate too.

> Signed off by: Matthew Fioravante matthew.fioravante@jhuapl.edu
> 
> diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
> --- a/tools/libxl/libxl.c
> +++ b/tools/libxl/libxl.c
> @@ -2027,6 +2027,274 @@ int libxl__device_disk_local_detach(libxl__gc
> *gc, libxl_device_disk *disk)
>  }
>  
>  /******************************************************************************/
> +int libxl__device_vtpm_setdefault(libxl__gc *gc, libxl_device_vtpm *vtpm)
> +{
> +   if(libxl_uuid_is_nil(&vtpm->uuid)) {
> +      libxl_uuid_generate(&vtpm->uuid);
> +   }
> +   return 0;
> +}
> +
> +static int libxl__device_from_vtpm(libxl__gc *gc, uint32_t domid,
> +                                   libxl_device_vtpm *vtpm,
> +                                   libxl__device *device)
> +{
> +   device->backend_devid   = vtpm->devid;
> +   device->backend_domid   = vtpm->backend_domid;
> +   device->backend_kind    = LIBXL__DEVICE_KIND_VTPM;
> +   device->devid           = vtpm->devid;
> +   device->domid           = domid;
> +   device->kind            = LIBXL__DEVICE_KIND_VTPM;
> +
> +   return 0;
> +}
> +
> +int libxl_device_vtpm_add(libxl_ctx *ctx, uint32_t domid,
> libxl_device_vtpm *vtpm)

It looks like this patch is pretty badly whitespace damaged.

http://wiki.xen.org/wiki/Submitting_Xen_Patches has some hints on using
mercurials patch bomb extension to avoid this sort of thing, and also a
link to Linux's doc on how to configure various popular MUAs to not
corrupt things.

I skimmed the rest of the patch regardless of that and it looks quite
reasonable, 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 Sep 19 12:25:24 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Sep 2012 12:25:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TEJL3-0001dM-2X; Wed, 19 Sep 2012 12:25:09 +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 1TEJL1-0001cY-D0
	for xen-devel@lists.xensource.com; Wed, 19 Sep 2012 12:25:07 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1348057500!9634897!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTAxNzU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25653 invoked from network); 19 Sep 2012 12:25:00 -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;
	19 Sep 2012 12:25:00 -0000
X-IronPort-AV: E=Sophos;i="4.80,447,1344211200"; d="scan'208";a="14630191"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Sep 2012 12:25: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.279.1;
	Wed, 19 Sep 2012 13:25:00 +0100
Message-ID: <1348057499.14977.102.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
Date: Wed, 19 Sep 2012 13:24:59 +0100
In-Reply-To: <5058B969.4020503@jhuapl.edu>
References: <5058B969.4020503@jhuapl.edu>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH xm/xl enhancements for vptm 2/6] add vtpm
 support to 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

On Tue, 2012-09-18 at 19:11 +0100, Matthew Fioravante wrote:
> This patch adds vtpm support to libxl. It adds vtpm parsing to config
> files and 3 new xl commands:
> vtpm-attach
> vtpm-detach
> vtpm-list

Please can you patch docs/man/xl* as appropriate too.

> Signed off by: Matthew Fioravante matthew.fioravante@jhuapl.edu
> 
> diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
> --- a/tools/libxl/libxl.c
> +++ b/tools/libxl/libxl.c
> @@ -2027,6 +2027,274 @@ int libxl__device_disk_local_detach(libxl__gc
> *gc, libxl_device_disk *disk)
>  }
>  
>  /******************************************************************************/
> +int libxl__device_vtpm_setdefault(libxl__gc *gc, libxl_device_vtpm *vtpm)
> +{
> +   if(libxl_uuid_is_nil(&vtpm->uuid)) {
> +      libxl_uuid_generate(&vtpm->uuid);
> +   }
> +   return 0;
> +}
> +
> +static int libxl__device_from_vtpm(libxl__gc *gc, uint32_t domid,
> +                                   libxl_device_vtpm *vtpm,
> +                                   libxl__device *device)
> +{
> +   device->backend_devid   = vtpm->devid;
> +   device->backend_domid   = vtpm->backend_domid;
> +   device->backend_kind    = LIBXL__DEVICE_KIND_VTPM;
> +   device->devid           = vtpm->devid;
> +   device->domid           = domid;
> +   device->kind            = LIBXL__DEVICE_KIND_VTPM;
> +
> +   return 0;
> +}
> +
> +int libxl_device_vtpm_add(libxl_ctx *ctx, uint32_t domid,
> libxl_device_vtpm *vtpm)

It looks like this patch is pretty badly whitespace damaged.

http://wiki.xen.org/wiki/Submitting_Xen_Patches has some hints on using
mercurials patch bomb extension to avoid this sort of thing, and also a
link to Linux's doc on how to configure various popular MUAs to not
corrupt things.

I skimmed the rest of the patch regardless of that and it looks quite
reasonable, 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 Sep 19 12:33:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Sep 2012 12:33:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TEJT9-0002I0-Mq; Wed, 19 Sep 2012 12:33: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 1TEJT8-0002Ho-9b
	for xen-devel@lists.xensource.com; Wed, 19 Sep 2012 12:33:30 +0000
Received: from [85.158.139.211:9630] by server-6.bemta-5.messagelabs.com id
	53/CC-21336-99BB9505; Wed, 19 Sep 2012 12:33:29 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-206.messagelabs.com!1348058008!19219139!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTAxNzU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27480 invoked from network); 19 Sep 2012 12:33:29 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Sep 2012 12:33:29 -0000
X-IronPort-AV: E=Sophos;i="4.80,447,1344211200"; d="scan'208";a="14630457"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Sep 2012 12:33: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.279.1;
	Wed, 19 Sep 2012 13:33:02 +0100
Message-ID: <1348057981.14977.107.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
Date: Wed, 19 Sep 2012 13:33:01 +0100
In-Reply-To: <5058BA2C.7090804@jhuapl.edu>
References: <5058BA2C.7090804@jhuapl.edu>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH xm/xl enhancements for vptm 3/6] add iomem
	option to xl
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-09-18 at 19:15 +0100, Matthew Fioravante wrote:
> This patch adds a new option for xen config files for directly mapping
> hardware io memory into a vm.
> 
> iomem=['pagenum,size',..]
> 
> Where pagenum is the page number and size is the number of page.
> example (for a tpm:
> iomem=['fed40,5']

Please can you patch the docs too.

Your implementation seems to also support a third field "allow"?

Did xm/xend have similar functionality? Is this compatible with the
syntax?

Also this patch is whitespace mangled again I'm afraid (I expect they
all are so I'll stop mentioning it)

> 
> Signed off by Matthew Fioravante matthew.fioravante@jhuapl.edu
> 
> diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
> --- a/tools/libxl/libxl.h
> +++ b/tools/libxl/libxl.h
> @@ -477,7 +477,7 @@ typedef struct {
>      libxl_domain_create_info c_info;
>      libxl_domain_build_info b_info;
>  
> -    int num_disks, num_vifs, num_pcidevs, num_vfbs, num_vkbs, num_vtpms;
> +    int num_disks, num_vifs, num_pcidevs, num_vfbs, num_vkbs,
> num_vtpms, num_iorngs;
>  
>      libxl_device_disk *disks;
>      libxl_device_nic *vifs;
> @@ -485,6 +485,7 @@ typedef struct {
>      libxl_device_vfb *vfbs;
>      libxl_device_vkb *vkbs;
>      libxl_device_vtpm *vtpms;
> +    libxl_iomem_range *iorngs;
>  
>      libxl_action_on_shutdown on_poweroff;
>      libxl_action_on_shutdown on_reboot;
> 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
> @@ -58,6 +58,10 @@ void libxl_domain_config_dispose(libxl_domain_config
> *d_config)
>         libxl_device_vtpm_dispose(&d_config->vtpms[i]);
>      free(d_config->vtpms);
>  
> +    for (i=0; i<d_config->num_iorngs; i++)
> +       libxl_iomem_range_dispose(&d_config->iorngs[i]);
> +    free(d_config->iorngs);
> +
>      libxl_domain_create_info_dispose(&d_config->c_info);
>      libxl_domain_build_info_dispose(&d_config->b_info);
>  }
> @@ -718,6 +722,15 @@ static void domcreate_bootloader_done(libxl__egc *egc,
>  
>      store_libxl_entry(gc, domid, &d_config->b_info);
>  
> +    for (i = 0; i < d_config->num_iorngs; i++) {
> +        ret = xc_domain_iomem_permission(ctx->xch, domid,
> d_config->iorngs[i].start, d_config->iorngs[i].length,
> d_config->iorngs[i].allow);
> +        if (ret) {
> +            LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
> +                       "cannot add iomem range %d to domain: %d", i, ret);
> +            ret = ERROR_FAIL;
> +            goto error_out;
> +        }
> +    }
>      for (i = 0; i < d_config->num_disks; i++) {
>          ret = libxl_device_disk_add(ctx, domid, &d_config->disks[i]);
>          if (ret) {
> 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
> @@ -317,6 +317,12 @@ libxl_domain_build_info = Struct("domain_build_info",[
>      ], dir=DIR_IN
>  )
>  
> +libxl_iomem_range = Struct("iomem_range", [
> +    ("start", uint64),
> +    ("length", uint64),
> +    ("allow", bool),
> +]);
> +
>  libxl_device_vfb = Struct("device_vfb", [
>      ("backend_domid", libxl_domid),
>      ("devid",         libxl_devid),
> 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
> @@ -560,7 +560,7 @@ static void parse_config_data(const char *config_source,
>      const char *buf;
>      long l;
>      XLU_Config *config;
> -    XLU_ConfigList *cpus, *vbds, *nics, *pcis, *cvfbs, *cpuids, *vtpms;
> +    XLU_ConfigList *cpus, *vbds, *nics, *pcis, *cvfbs, *cpuids, *vtpms,
> *iomems;
>      int pci_power_mgmt = 0;
>      int pci_msitranslate = 1;
>      int pci_permissive = 0;
> @@ -1145,6 +1145,42 @@ skip_vfb:
>              libxl_defbool_set(&b_info->u.pv.e820_host, true);
>      }
>  
> +    if(!xlu_cfg_get_list(config, "iomem", &iomems, 0, 0)) {
> +       int i;
> +       for(i =0; (buf = xlu_cfg_get_listitem(iomems, i)) != NULL; ++i) {
> +          libxl_iomem_range *iorng;
> +          char* buf2 = strdup(buf);
> +          char *st, *len, *al;
> +
> +          d_config->iorngs = realloc(d_config->iorngs,
> sizeof(libxl_iomem_range) * (d_config->num_iorngs + 1));
> +          iorng = d_config->iorngs + d_config->num_iorngs;
> +
> +          libxl_iomem_range_init(iorng);
> +
> +          st = strtok(buf2, ",");
> +          len = strtok(NULL, ",");
> +          al = strtok(NULL, ",");
> +
> +          if(st == NULL || len == NULL ||
> +                sscanf(st, "%" PRIx64, &iorng->start) != 1 ||
> +                sscanf(len, "%" PRIu64, &iorng->length) != 1 ||
> +                (al != NULL && ((al[0] != '1' && al[0] != '0') || al[1]
> != '\0'))
> +            ) {
> +             fprintf(stderr, "Malformed iomem specification!\n");
> +             free(buf2);
> +             exit(1);
> +          }
> +          if(al != NULL) {
> +             iorng->allow = al[0] - '0';
> +          } else {
> +             iorng->allow = 1;
> +          }
> +
> +          free(buf2);
> +          d_config->num_iorngs++;
> +       }
> +    }
> +
>      switch (xlu_cfg_get_list(config, "cpuid", &cpuids, 0, 1)) {
>      case 0:
>          {



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 19 12:33:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Sep 2012 12:33:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TEJT9-0002I0-Mq; Wed, 19 Sep 2012 12:33: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 1TEJT8-0002Ho-9b
	for xen-devel@lists.xensource.com; Wed, 19 Sep 2012 12:33:30 +0000
Received: from [85.158.139.211:9630] by server-6.bemta-5.messagelabs.com id
	53/CC-21336-99BB9505; Wed, 19 Sep 2012 12:33:29 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-206.messagelabs.com!1348058008!19219139!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTAxNzU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27480 invoked from network); 19 Sep 2012 12:33:29 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Sep 2012 12:33:29 -0000
X-IronPort-AV: E=Sophos;i="4.80,447,1344211200"; d="scan'208";a="14630457"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Sep 2012 12:33: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.279.1;
	Wed, 19 Sep 2012 13:33:02 +0100
Message-ID: <1348057981.14977.107.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
Date: Wed, 19 Sep 2012 13:33:01 +0100
In-Reply-To: <5058BA2C.7090804@jhuapl.edu>
References: <5058BA2C.7090804@jhuapl.edu>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH xm/xl enhancements for vptm 3/6] add iomem
	option to xl
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-09-18 at 19:15 +0100, Matthew Fioravante wrote:
> This patch adds a new option for xen config files for directly mapping
> hardware io memory into a vm.
> 
> iomem=['pagenum,size',..]
> 
> Where pagenum is the page number and size is the number of page.
> example (for a tpm:
> iomem=['fed40,5']

Please can you patch the docs too.

Your implementation seems to also support a third field "allow"?

Did xm/xend have similar functionality? Is this compatible with the
syntax?

Also this patch is whitespace mangled again I'm afraid (I expect they
all are so I'll stop mentioning it)

> 
> Signed off by Matthew Fioravante matthew.fioravante@jhuapl.edu
> 
> diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
> --- a/tools/libxl/libxl.h
> +++ b/tools/libxl/libxl.h
> @@ -477,7 +477,7 @@ typedef struct {
>      libxl_domain_create_info c_info;
>      libxl_domain_build_info b_info;
>  
> -    int num_disks, num_vifs, num_pcidevs, num_vfbs, num_vkbs, num_vtpms;
> +    int num_disks, num_vifs, num_pcidevs, num_vfbs, num_vkbs,
> num_vtpms, num_iorngs;
>  
>      libxl_device_disk *disks;
>      libxl_device_nic *vifs;
> @@ -485,6 +485,7 @@ typedef struct {
>      libxl_device_vfb *vfbs;
>      libxl_device_vkb *vkbs;
>      libxl_device_vtpm *vtpms;
> +    libxl_iomem_range *iorngs;
>  
>      libxl_action_on_shutdown on_poweroff;
>      libxl_action_on_shutdown on_reboot;
> 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
> @@ -58,6 +58,10 @@ void libxl_domain_config_dispose(libxl_domain_config
> *d_config)
>         libxl_device_vtpm_dispose(&d_config->vtpms[i]);
>      free(d_config->vtpms);
>  
> +    for (i=0; i<d_config->num_iorngs; i++)
> +       libxl_iomem_range_dispose(&d_config->iorngs[i]);
> +    free(d_config->iorngs);
> +
>      libxl_domain_create_info_dispose(&d_config->c_info);
>      libxl_domain_build_info_dispose(&d_config->b_info);
>  }
> @@ -718,6 +722,15 @@ static void domcreate_bootloader_done(libxl__egc *egc,
>  
>      store_libxl_entry(gc, domid, &d_config->b_info);
>  
> +    for (i = 0; i < d_config->num_iorngs; i++) {
> +        ret = xc_domain_iomem_permission(ctx->xch, domid,
> d_config->iorngs[i].start, d_config->iorngs[i].length,
> d_config->iorngs[i].allow);
> +        if (ret) {
> +            LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
> +                       "cannot add iomem range %d to domain: %d", i, ret);
> +            ret = ERROR_FAIL;
> +            goto error_out;
> +        }
> +    }
>      for (i = 0; i < d_config->num_disks; i++) {
>          ret = libxl_device_disk_add(ctx, domid, &d_config->disks[i]);
>          if (ret) {
> 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
> @@ -317,6 +317,12 @@ libxl_domain_build_info = Struct("domain_build_info",[
>      ], dir=DIR_IN
>  )
>  
> +libxl_iomem_range = Struct("iomem_range", [
> +    ("start", uint64),
> +    ("length", uint64),
> +    ("allow", bool),
> +]);
> +
>  libxl_device_vfb = Struct("device_vfb", [
>      ("backend_domid", libxl_domid),
>      ("devid",         libxl_devid),
> 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
> @@ -560,7 +560,7 @@ static void parse_config_data(const char *config_source,
>      const char *buf;
>      long l;
>      XLU_Config *config;
> -    XLU_ConfigList *cpus, *vbds, *nics, *pcis, *cvfbs, *cpuids, *vtpms;
> +    XLU_ConfigList *cpus, *vbds, *nics, *pcis, *cvfbs, *cpuids, *vtpms,
> *iomems;
>      int pci_power_mgmt = 0;
>      int pci_msitranslate = 1;
>      int pci_permissive = 0;
> @@ -1145,6 +1145,42 @@ skip_vfb:
>              libxl_defbool_set(&b_info->u.pv.e820_host, true);
>      }
>  
> +    if(!xlu_cfg_get_list(config, "iomem", &iomems, 0, 0)) {
> +       int i;
> +       for(i =0; (buf = xlu_cfg_get_listitem(iomems, i)) != NULL; ++i) {
> +          libxl_iomem_range *iorng;
> +          char* buf2 = strdup(buf);
> +          char *st, *len, *al;
> +
> +          d_config->iorngs = realloc(d_config->iorngs,
> sizeof(libxl_iomem_range) * (d_config->num_iorngs + 1));
> +          iorng = d_config->iorngs + d_config->num_iorngs;
> +
> +          libxl_iomem_range_init(iorng);
> +
> +          st = strtok(buf2, ",");
> +          len = strtok(NULL, ",");
> +          al = strtok(NULL, ",");
> +
> +          if(st == NULL || len == NULL ||
> +                sscanf(st, "%" PRIx64, &iorng->start) != 1 ||
> +                sscanf(len, "%" PRIu64, &iorng->length) != 1 ||
> +                (al != NULL && ((al[0] != '1' && al[0] != '0') || al[1]
> != '\0'))
> +            ) {
> +             fprintf(stderr, "Malformed iomem specification!\n");
> +             free(buf2);
> +             exit(1);
> +          }
> +          if(al != NULL) {
> +             iorng->allow = al[0] - '0';
> +          } else {
> +             iorng->allow = 1;
> +          }
> +
> +          free(buf2);
> +          d_config->num_iorngs++;
> +       }
> +    }
> +
>      switch (xlu_cfg_get_list(config, "cpuid", &cpuids, 0, 1)) {
>      case 0:
>          {



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 19 12:35:10 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Sep 2012 12: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 1TEJUX-0002RT-63; Wed, 19 Sep 2012 12:34: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 1TEJUW-0002RG-6J
	for xen-devel@lists.xensource.com; Wed, 19 Sep 2012 12:34:56 +0000
Received: from [85.158.143.99:57547] by server-3.bemta-4.messagelabs.com id
	A7/77-10986-FEBB9505; Wed, 19 Sep 2012 12:34:55 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1348058094!30062674!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTAxNzU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9082 invoked from network); 19 Sep 2012 12:34:55 -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 Sep 2012 12:34:55 -0000
X-IronPort-AV: E=Sophos;i="4.80,447,1344211200"; d="scan'208";a="14630519"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Sep 2012 12:34: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.279.1;
	Wed, 19 Sep 2012 13:34:54 +0100
Message-ID: <1348058093.14977.109.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
Date: Wed, 19 Sep 2012 13:34:53 +0100
In-Reply-To: <5058BACF.6030903@jhuapl.edu>
References: <5058BACF.6030903@jhuapl.edu>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH xm/xl enhancements for vptm 4/6] xl add irq
	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-09-18 at 19:17 +0100, Matthew Fioravante wrote:
> This patch adds support for mapping irqs into virtual machines. The
> syntax is
> 
> irq = [irqnum,allow]

Xen 4.2 / unstable already has support for specifying irqs.

What is allow for (I should have asked this for the previous iomem patch
too)? THe default is deny and listing an irq here means allow, do we
need to be able to explicitly deny given 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 Sep 19 12:35:10 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Sep 2012 12: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 1TEJUX-0002RT-63; Wed, 19 Sep 2012 12:34: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 1TEJUW-0002RG-6J
	for xen-devel@lists.xensource.com; Wed, 19 Sep 2012 12:34:56 +0000
Received: from [85.158.143.99:57547] by server-3.bemta-4.messagelabs.com id
	A7/77-10986-FEBB9505; Wed, 19 Sep 2012 12:34:55 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1348058094!30062674!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTAxNzU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9082 invoked from network); 19 Sep 2012 12:34:55 -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 Sep 2012 12:34:55 -0000
X-IronPort-AV: E=Sophos;i="4.80,447,1344211200"; d="scan'208";a="14630519"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Sep 2012 12:34: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.279.1;
	Wed, 19 Sep 2012 13:34:54 +0100
Message-ID: <1348058093.14977.109.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
Date: Wed, 19 Sep 2012 13:34:53 +0100
In-Reply-To: <5058BACF.6030903@jhuapl.edu>
References: <5058BACF.6030903@jhuapl.edu>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH xm/xl enhancements for vptm 4/6] xl add irq
	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-09-18 at 19:17 +0100, Matthew Fioravante wrote:
> This patch adds support for mapping irqs into virtual machines. The
> syntax is
> 
> irq = [irqnum,allow]

Xen 4.2 / unstable already has support for specifying irqs.

What is allow for (I should have asked this for the previous iomem patch
too)? THe default is deny and listing an irq here means allow, do we
need to be able to explicitly deny given 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 Sep 19 12:36:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Sep 2012 12: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 1TEJVO-0002ZT-LJ; Wed, 19 Sep 2012 12:35:50 +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 1TEJVN-0002YW-2x
	for xen-devel@lists.xensource.com; Wed, 19 Sep 2012 12:35:49 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1348058134!11582454!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTAxNzU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1996 invoked from network); 19 Sep 2012 12:35:34 -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;
	19 Sep 2012 12:35:34 -0000
X-IronPort-AV: E=Sophos;i="4.80,447,1344211200"; d="scan'208";a="14630545"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Sep 2012 12:35: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.279.1;
	Wed, 19 Sep 2012 13:35:33 +0100
Message-ID: <1348058132.14977.110.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
Date: Wed, 19 Sep 2012 13:35:32 +0100
In-Reply-To: <5058BB68.5090504@jhuapl.edu>
References: <5058BB68.5090504@jhuapl.edu>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH xm/xl enhancements for vptm 5/6] add ioport
 support to 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

On Tue, 2012-09-18 at 19:20 +0100, Matthew Fioravante wrote:
> This patch adds support for mapping ioports to vms using xl, similar to
> the function in xm.

xl in 4.2 & unstable already supports 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 Sep 19 12:36:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Sep 2012 12: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 1TEJVO-0002ZT-LJ; Wed, 19 Sep 2012 12:35:50 +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 1TEJVN-0002YW-2x
	for xen-devel@lists.xensource.com; Wed, 19 Sep 2012 12:35:49 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1348058134!11582454!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTAxNzU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1996 invoked from network); 19 Sep 2012 12:35:34 -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;
	19 Sep 2012 12:35:34 -0000
X-IronPort-AV: E=Sophos;i="4.80,447,1344211200"; d="scan'208";a="14630545"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Sep 2012 12:35: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.279.1;
	Wed, 19 Sep 2012 13:35:33 +0100
Message-ID: <1348058132.14977.110.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
Date: Wed, 19 Sep 2012 13:35:32 +0100
In-Reply-To: <5058BB68.5090504@jhuapl.edu>
References: <5058BB68.5090504@jhuapl.edu>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH xm/xl enhancements for vptm 5/6] add ioport
 support to 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

On Tue, 2012-09-18 at 19:20 +0100, Matthew Fioravante wrote:
> This patch adds support for mapping ioports to vms using xl, similar to
> the function in xm.

xl in 4.2 & unstable already supports 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 Sep 19 12:46:32 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Sep 2012 12:46:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TEJfU-0003FG-G5; Wed, 19 Sep 2012 12:46: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 1TEJfS-0003FA-Tq
	for xen-devel@lists.xensource.com; Wed, 19 Sep 2012 12:46:15 +0000
Received: from [85.158.143.99:63685] by server-3.bemta-4.messagelabs.com id
	E6/09-10986-69EB9505; Wed, 19 Sep 2012 12:46:14 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1348058770!23446486!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTAxNzU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14156 invoked from network); 19 Sep 2012 12:46:13 -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;
	19 Sep 2012 12:46:13 -0000
X-IronPort-AV: E=Sophos;i="4.80,447,1344211200"; d="scan'208";a="14630775"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Sep 2012 12:46: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.279.1;
	Wed, 19 Sep 2012 13:46:09 +0100
Message-ID: <1348058768.14977.114.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
Date: Wed, 19 Sep 2012 13:46:08 +0100
In-Reply-To: <5058B1FF.8080301@jhuapl.edu>
References: <505793F4.40301@jhuapl.edu>
	<1347954198.25803.92.camel@dagon.hellion.org.uk>
	<5058B1FF.8080301@jhuapl.edu>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH vtpm_manager 2/2] Fixes to vtpm 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

On Tue, 2012-09-18 at 18:40 +0100, Matthew Fioravante wrote:
> On 09/18/2012 03:43 AM, Ian Campbell wrote:
> > On Mon, 2012-09-17 at 22:19 +0100, Matthew Fioravante wrote:
> >> This patch fixes IO deadlocks in the vtpm hotplug scripts
> > Is the switch from awk to gawk a part of this? How?
> >
> > IIRC we deliberately switched from using gawk specific features to allow
> > e.g. mawk to be used. If there is some gawk specific construct used here
> > it would be better to recast it in more portable terms IMHO.
> I'll test and get back to you on this.
> >
> >> - set -e
> >> + local resp_hex
> >> + #send cmd to vtpm_manager and get response
> >> + if ! resp_hex=`echo "$cmd$(str_to_hex32 $inst)" | vtpmmgrtalk `; then
> > Is this really the command/control interface provided by VTPM? Can we
> > not work with upstream to define something more usable?
> Unfortunately xen itself is the upstream for vtpm_manager.

Do you suppose the berlios project might be interested in subsuming this
functionality too? (I'll be honest, I have only the vaguest of ideas
what each of these components does).

>  The
> vtpm_manager code is full of bugs and actually needs a complete rewrite.
> The amount of careless memory leaks and other bugs I found when trying
> to use it were pretty astounding. The first manager patch fixes most of
> the ones I could find to get the manager to work properly.
> 
> The managers current form in the xen tree is actually pretty unusable.
> I don't have time to rewrite the manager, but what I'm offering here is
> at least a huge improvement over the old code.

That doesn't surprise me, it doesn't seem to have been especially
actively maintained for a very long time.

I don't suppose you want to be maintainer do you? If so you could send a
patch against the MAINTINERS file.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 19 12:46:32 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Sep 2012 12:46:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TEJfU-0003FG-G5; Wed, 19 Sep 2012 12:46: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 1TEJfS-0003FA-Tq
	for xen-devel@lists.xensource.com; Wed, 19 Sep 2012 12:46:15 +0000
Received: from [85.158.143.99:63685] by server-3.bemta-4.messagelabs.com id
	E6/09-10986-69EB9505; Wed, 19 Sep 2012 12:46:14 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1348058770!23446486!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTAxNzU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14156 invoked from network); 19 Sep 2012 12:46:13 -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;
	19 Sep 2012 12:46:13 -0000
X-IronPort-AV: E=Sophos;i="4.80,447,1344211200"; d="scan'208";a="14630775"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Sep 2012 12:46: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.279.1;
	Wed, 19 Sep 2012 13:46:09 +0100
Message-ID: <1348058768.14977.114.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
Date: Wed, 19 Sep 2012 13:46:08 +0100
In-Reply-To: <5058B1FF.8080301@jhuapl.edu>
References: <505793F4.40301@jhuapl.edu>
	<1347954198.25803.92.camel@dagon.hellion.org.uk>
	<5058B1FF.8080301@jhuapl.edu>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH vtpm_manager 2/2] Fixes to vtpm 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

On Tue, 2012-09-18 at 18:40 +0100, Matthew Fioravante wrote:
> On 09/18/2012 03:43 AM, Ian Campbell wrote:
> > On Mon, 2012-09-17 at 22:19 +0100, Matthew Fioravante wrote:
> >> This patch fixes IO deadlocks in the vtpm hotplug scripts
> > Is the switch from awk to gawk a part of this? How?
> >
> > IIRC we deliberately switched from using gawk specific features to allow
> > e.g. mawk to be used. If there is some gawk specific construct used here
> > it would be better to recast it in more portable terms IMHO.
> I'll test and get back to you on this.
> >
> >> - set -e
> >> + local resp_hex
> >> + #send cmd to vtpm_manager and get response
> >> + if ! resp_hex=`echo "$cmd$(str_to_hex32 $inst)" | vtpmmgrtalk `; then
> > Is this really the command/control interface provided by VTPM? Can we
> > not work with upstream to define something more usable?
> Unfortunately xen itself is the upstream for vtpm_manager.

Do you suppose the berlios project might be interested in subsuming this
functionality too? (I'll be honest, I have only the vaguest of ideas
what each of these components does).

>  The
> vtpm_manager code is full of bugs and actually needs a complete rewrite.
> The amount of careless memory leaks and other bugs I found when trying
> to use it were pretty astounding. The first manager patch fixes most of
> the ones I could find to get the manager to work properly.
> 
> The managers current form in the xen tree is actually pretty unusable.
> I don't have time to rewrite the manager, but what I'm offering here is
> at least a huge improvement over the old code.

That doesn't surprise me, it doesn't seem to have been especially
actively maintained for a very long time.

I don't suppose you want to be maintainer do you? If so you could send a
patch against the MAINTINERS file.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 19 12:56:18 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Sep 2012 12:56:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TEJoy-0003XW-Do; Wed, 19 Sep 2012 12:56:04 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1TEJow-0003XP-Rp
	for xen-devel@lists.xen.org; Wed, 19 Sep 2012 12:56:03 +0000
Received: from [85.158.139.211:16010] by server-8.bemta-5.messagelabs.com id
	D5/79-16255-1E0C9505; Wed, 19 Sep 2012 12:56:01 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-206.messagelabs.com!1348059360!19118251!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7824 invoked from network); 19 Sep 2012 12:56:00 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-14.tower-206.messagelabs.com with SMTP;
	19 Sep 2012 12:56:00 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 19 Sep 2012 13:58:36 +0100
Message-Id: <5059DCFD020000780009C50F@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 19 Sep 2012 13:55:57 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Keir Fraser" <keir@xen.org>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part6C5D68CD.0__="
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: [Xen-devel] [PATCH, v2] ACPI: move tables.c fully into .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>
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.

--=__Part6C5D68CD.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

The only non-init item was the space reserved for the initial tables,
but we can as well dynamically allocate that array.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
---
v2: Do allocation via the already existing, but so far broken re-sizing
    logic (requires properly handling the early boot case in ACPI's
    allocation abstractions).

--- a/xen/drivers/acpi/Makefile
+++ b/xen/drivers/acpi/Makefile
@@ -2,7 +2,7 @@ subdir-y +=3D tables
 subdir-y +=3D utilities
 subdir-$(x86) +=3D apei
=20
-obj-y +=3D tables.o
+obj-bin-y +=3D tables.init.o
 obj-y +=3D numa.o
 obj-y +=3D osl.o
 obj-y +=3D pmstat.o
--- a/xen/drivers/acpi/osl.c
+++ b/xen/drivers/acpi/osl.c
@@ -27,6 +27,7 @@
 #include <asm/io.h>
 #include <xen/config.h>
 #include <xen/init.h>
+#include <xen/pfn.h>
 #include <xen/types.h>
 #include <xen/errno.h>
 #include <xen/acpi.h>
@@ -182,3 +183,38 @@ acpi_os_write_memory(acpi_physical_addre
=20
 	return AE_OK;
 }
+
+#define is_xmalloc_memory(ptr) ((unsigned long)(ptr) & (PAGE_SIZE - 1))
+
+void *__init acpi_os_alloc_memory(size_t sz)
+{
+	void *ptr;
+
+	if (system_state =3D=3D SYS_STATE_early_boot)
+		return mfn_to_virt(alloc_boot_pages(PFN_UP(sz), 1));
+
+	ptr =3D xmalloc_bytes(sz);
+	ASSERT(!ptr || is_xmalloc_memory(ptr));
+	return ptr;
+}
+
+void *__init acpi_os_zalloc_memory(size_t sz)
+{
+	void *ptr;
+
+	if (system_state !=3D SYS_STATE_early_boot) {
+		ptr =3D xzalloc_bytes(sz);
+		ASSERT(!ptr || is_xmalloc_memory(ptr));
+		return ptr;
+	}
+	ptr =3D acpi_os_alloc_memory(sz);
+	return ptr ? memset(ptr, 0, sz) : NULL;
+}
+
+void __init acpi_os_free_memory(void *ptr)
+{
+	if (is_xmalloc_memory(ptr))
+		xfree(ptr);
+	else if (ptr && system_state =3D=3D SYS_STATE_early_boot)
+		init_boot_pages(__pa(ptr), __pa(ptr) + PAGE_SIZE);
+}
--- a/xen/drivers/acpi/tables.c
+++ b/xen/drivers/acpi/tables.c
@@ -41,8 +41,6 @@ mps_inti_flags_polarity[] =3D { "dfl", "hi
 static const char *__initdata
 mps_inti_flags_trigger[] =3D { "dfl", "edge", "res", "level" };
=20
-static struct acpi_table_desc initial_tables[ACPI_MAX_TABLES];
-
 static int acpi_apic_instance __initdata;
=20
 void __init acpi_table_print_madt_entry(struct acpi_subtable_header =
*header)
@@ -324,7 +322,7 @@ static void __init check_multiple_madt(v
=20
 int __init acpi_table_init(void)
 {
-	acpi_initialize_tables(initial_tables, ACPI_MAX_TABLES, 0);
+	acpi_initialize_tables(NULL, ACPI_MAX_TABLES, 0);
 	check_multiple_madt();
 	return 0;
 }
--- a/xen/include/acpi/platform/aclinux.h
+++ b/xen/include/acpi/platform/aclinux.h
@@ -76,8 +76,12 @@
=20
 #define acpi_thread_id struct vcpu *
=20
-#define ACPI_ALLOCATE(a)	xmalloc_bytes(a)
-#define ACPI_ALLOCATE_ZEROED(a)	xzalloc_bytes(a)
-#define ACPI_FREE(a)		xfree(a)
+void *acpi_os_alloc_memory(size_t);
+void *acpi_os_zalloc_memory(size_t);
+void acpi_os_free_memory(void *);
+
+#define ACPI_ALLOCATE(a)	acpi_os_alloc_memory(a)
+#define ACPI_ALLOCATE_ZEROED(a)	acpi_os_zalloc_memory(a)
+#define ACPI_FREE(a)		acpi_os_free_memory(a)
=20
 #endif				/* __ACLINUX_H__ */




--=__Part6C5D68CD.0__=
Content-Type: text/plain; name="ACPI-tables-init.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="ACPI-tables-init.patch"

ACPI: move tables.c fully into .init.*=0A=0AThe only non-init item was the =
space reserved for the initial tables,=0Abut we can as well dynamically =
allocate that array.=0A=0ASigned-off-by: Jan Beulich <jbeulich@suse.com>=0A=
---=0Av2: Do allocation via the already existing, but so far broken =
re-sizing=0A    logic (requires properly handling the early boot case in =
ACPI's=0A    allocation abstractions).=0A=0A--- a/xen/drivers/acpi/Makefile=
=0A+++ b/xen/drivers/acpi/Makefile=0A@@ -2,7 +2,7 @@ subdir-y +=3D =
tables=0A subdir-y +=3D utilities=0A subdir-$(x86) +=3D apei=0A =0A-obj-y =
+=3D tables.o=0A+obj-bin-y +=3D tables.init.o=0A obj-y +=3D numa.o=0A =
obj-y +=3D osl.o=0A obj-y +=3D pmstat.o=0A--- a/xen/drivers/acpi/osl.c=0A++=
+ b/xen/drivers/acpi/osl.c=0A@@ -27,6 +27,7 @@=0A #include <asm/io.h>=0A =
#include <xen/config.h>=0A #include <xen/init.h>=0A+#include <xen/pfn.h>=0A=
 #include <xen/types.h>=0A #include <xen/errno.h>=0A #include <xen/acpi.h>=
=0A@@ -182,3 +183,38 @@ acpi_os_write_memory(acpi_physical_addre=0A =0A 	=
return AE_OK;=0A }=0A+=0A+#define is_xmalloc_memory(ptr) ((unsigned =
long)(ptr) & (PAGE_SIZE - 1))=0A+=0A+void *__init acpi_os_alloc_memory(size=
_t sz)=0A+{=0A+	void *ptr;=0A+=0A+	if (system_state =3D=3D SYS_STATE_e=
arly_boot)=0A+		return mfn_to_virt(alloc_boot_pages(PFN_UP(sz), =
1));=0A+=0A+	ptr =3D xmalloc_bytes(sz);=0A+	ASSERT(!ptr || is_xmalloc_m=
emory(ptr));=0A+	return ptr;=0A+}=0A+=0A+void *__init acpi_os_zalloc=
_memory(size_t sz)=0A+{=0A+	void *ptr;=0A+=0A+	if (system_state =
!=3D SYS_STATE_early_boot) {=0A+		ptr =3D xzalloc_bytes(sz);=
=0A+		ASSERT(!ptr || is_xmalloc_memory(ptr));=0A+		=
return ptr;=0A+	}=0A+	ptr =3D acpi_os_alloc_memory(sz);=0A+	return ptr =
? memset(ptr, 0, sz) : NULL;=0A+}=0A+=0A+void __init acpi_os_free_memory(vo=
id *ptr)=0A+{=0A+	if (is_xmalloc_memory(ptr))=0A+		xfree(ptr);=
=0A+	else if (ptr && system_state =3D=3D SYS_STATE_early_boot)=0A+		=
init_boot_pages(__pa(ptr), __pa(ptr) + PAGE_SIZE);=0A+}=0A--- a/xen/drivers=
/acpi/tables.c=0A+++ b/xen/drivers/acpi/tables.c=0A@@ -41,8 +41,6 @@ =
mps_inti_flags_polarity[] =3D { "dfl", "hi=0A static const char *__initdata=
=0A mps_inti_flags_trigger[] =3D { "dfl", "edge", "res", "level" };=0A =
=0A-static struct acpi_table_desc initial_tables[ACPI_MAX_TABLES];=0A-=0A =
static int acpi_apic_instance __initdata;=0A =0A void __init acpi_table_pri=
nt_madt_entry(struct acpi_subtable_header *header)=0A@@ -324,7 +322,7 @@ =
static void __init check_multiple_madt(v=0A =0A int __init acpi_table_init(=
void)=0A {=0A-	acpi_initialize_tables(initial_tables, ACPI_MAX_TABLES, =
0);=0A+	acpi_initialize_tables(NULL, ACPI_MAX_TABLES, 0);=0A 	check_multi=
ple_madt();=0A 	return 0;=0A }=0A--- a/xen/include/acpi/platform/aclinux.h=
=0A+++ b/xen/include/acpi/platform/aclinux.h=0A@@ -76,8 +76,12 @@=0A =0A =
#define acpi_thread_id struct vcpu *=0A =0A-#define ACPI_ALLOCATE(a)	=
xmalloc_bytes(a)=0A-#define ACPI_ALLOCATE_ZEROED(a)	xzalloc_bytes(a)=0A=
-#define ACPI_FREE(a)		xfree(a)=0A+void *acpi_os_alloc_memory(size=
_t);=0A+void *acpi_os_zalloc_memory(size_t);=0A+void acpi_os_free_memory(vo=
id *);=0A+=0A+#define ACPI_ALLOCATE(a)	acpi_os_alloc_memory(a)=0A+#define =
ACPI_ALLOCATE_ZEROED(a)	acpi_os_zalloc_memory(a)=0A+#define ACPI_FREE(a)	=
	acpi_os_free_memory(a)=0A =0A #endif				/* =
__ACLINUX_H__ */=0A
--=__Part6C5D68CD.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

--=__Part6C5D68CD.0__=--


From xen-devel-bounces@lists.xen.org Wed Sep 19 12:56:18 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Sep 2012 12:56:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TEJoy-0003XW-Do; Wed, 19 Sep 2012 12:56:04 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1TEJow-0003XP-Rp
	for xen-devel@lists.xen.org; Wed, 19 Sep 2012 12:56:03 +0000
Received: from [85.158.139.211:16010] by server-8.bemta-5.messagelabs.com id
	D5/79-16255-1E0C9505; Wed, 19 Sep 2012 12:56:01 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-206.messagelabs.com!1348059360!19118251!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7824 invoked from network); 19 Sep 2012 12:56:00 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-14.tower-206.messagelabs.com with SMTP;
	19 Sep 2012 12:56:00 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 19 Sep 2012 13:58:36 +0100
Message-Id: <5059DCFD020000780009C50F@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 19 Sep 2012 13:55:57 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Keir Fraser" <keir@xen.org>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part6C5D68CD.0__="
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: [Xen-devel] [PATCH, v2] ACPI: move tables.c fully into .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>
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.

--=__Part6C5D68CD.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

The only non-init item was the space reserved for the initial tables,
but we can as well dynamically allocate that array.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
---
v2: Do allocation via the already existing, but so far broken re-sizing
    logic (requires properly handling the early boot case in ACPI's
    allocation abstractions).

--- a/xen/drivers/acpi/Makefile
+++ b/xen/drivers/acpi/Makefile
@@ -2,7 +2,7 @@ subdir-y +=3D tables
 subdir-y +=3D utilities
 subdir-$(x86) +=3D apei
=20
-obj-y +=3D tables.o
+obj-bin-y +=3D tables.init.o
 obj-y +=3D numa.o
 obj-y +=3D osl.o
 obj-y +=3D pmstat.o
--- a/xen/drivers/acpi/osl.c
+++ b/xen/drivers/acpi/osl.c
@@ -27,6 +27,7 @@
 #include <asm/io.h>
 #include <xen/config.h>
 #include <xen/init.h>
+#include <xen/pfn.h>
 #include <xen/types.h>
 #include <xen/errno.h>
 #include <xen/acpi.h>
@@ -182,3 +183,38 @@ acpi_os_write_memory(acpi_physical_addre
=20
 	return AE_OK;
 }
+
+#define is_xmalloc_memory(ptr) ((unsigned long)(ptr) & (PAGE_SIZE - 1))
+
+void *__init acpi_os_alloc_memory(size_t sz)
+{
+	void *ptr;
+
+	if (system_state =3D=3D SYS_STATE_early_boot)
+		return mfn_to_virt(alloc_boot_pages(PFN_UP(sz), 1));
+
+	ptr =3D xmalloc_bytes(sz);
+	ASSERT(!ptr || is_xmalloc_memory(ptr));
+	return ptr;
+}
+
+void *__init acpi_os_zalloc_memory(size_t sz)
+{
+	void *ptr;
+
+	if (system_state !=3D SYS_STATE_early_boot) {
+		ptr =3D xzalloc_bytes(sz);
+		ASSERT(!ptr || is_xmalloc_memory(ptr));
+		return ptr;
+	}
+	ptr =3D acpi_os_alloc_memory(sz);
+	return ptr ? memset(ptr, 0, sz) : NULL;
+}
+
+void __init acpi_os_free_memory(void *ptr)
+{
+	if (is_xmalloc_memory(ptr))
+		xfree(ptr);
+	else if (ptr && system_state =3D=3D SYS_STATE_early_boot)
+		init_boot_pages(__pa(ptr), __pa(ptr) + PAGE_SIZE);
+}
--- a/xen/drivers/acpi/tables.c
+++ b/xen/drivers/acpi/tables.c
@@ -41,8 +41,6 @@ mps_inti_flags_polarity[] =3D { "dfl", "hi
 static const char *__initdata
 mps_inti_flags_trigger[] =3D { "dfl", "edge", "res", "level" };
=20
-static struct acpi_table_desc initial_tables[ACPI_MAX_TABLES];
-
 static int acpi_apic_instance __initdata;
=20
 void __init acpi_table_print_madt_entry(struct acpi_subtable_header =
*header)
@@ -324,7 +322,7 @@ static void __init check_multiple_madt(v
=20
 int __init acpi_table_init(void)
 {
-	acpi_initialize_tables(initial_tables, ACPI_MAX_TABLES, 0);
+	acpi_initialize_tables(NULL, ACPI_MAX_TABLES, 0);
 	check_multiple_madt();
 	return 0;
 }
--- a/xen/include/acpi/platform/aclinux.h
+++ b/xen/include/acpi/platform/aclinux.h
@@ -76,8 +76,12 @@
=20
 #define acpi_thread_id struct vcpu *
=20
-#define ACPI_ALLOCATE(a)	xmalloc_bytes(a)
-#define ACPI_ALLOCATE_ZEROED(a)	xzalloc_bytes(a)
-#define ACPI_FREE(a)		xfree(a)
+void *acpi_os_alloc_memory(size_t);
+void *acpi_os_zalloc_memory(size_t);
+void acpi_os_free_memory(void *);
+
+#define ACPI_ALLOCATE(a)	acpi_os_alloc_memory(a)
+#define ACPI_ALLOCATE_ZEROED(a)	acpi_os_zalloc_memory(a)
+#define ACPI_FREE(a)		acpi_os_free_memory(a)
=20
 #endif				/* __ACLINUX_H__ */




--=__Part6C5D68CD.0__=
Content-Type: text/plain; name="ACPI-tables-init.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="ACPI-tables-init.patch"

ACPI: move tables.c fully into .init.*=0A=0AThe only non-init item was the =
space reserved for the initial tables,=0Abut we can as well dynamically =
allocate that array.=0A=0ASigned-off-by: Jan Beulich <jbeulich@suse.com>=0A=
---=0Av2: Do allocation via the already existing, but so far broken =
re-sizing=0A    logic (requires properly handling the early boot case in =
ACPI's=0A    allocation abstractions).=0A=0A--- a/xen/drivers/acpi/Makefile=
=0A+++ b/xen/drivers/acpi/Makefile=0A@@ -2,7 +2,7 @@ subdir-y +=3D =
tables=0A subdir-y +=3D utilities=0A subdir-$(x86) +=3D apei=0A =0A-obj-y =
+=3D tables.o=0A+obj-bin-y +=3D tables.init.o=0A obj-y +=3D numa.o=0A =
obj-y +=3D osl.o=0A obj-y +=3D pmstat.o=0A--- a/xen/drivers/acpi/osl.c=0A++=
+ b/xen/drivers/acpi/osl.c=0A@@ -27,6 +27,7 @@=0A #include <asm/io.h>=0A =
#include <xen/config.h>=0A #include <xen/init.h>=0A+#include <xen/pfn.h>=0A=
 #include <xen/types.h>=0A #include <xen/errno.h>=0A #include <xen/acpi.h>=
=0A@@ -182,3 +183,38 @@ acpi_os_write_memory(acpi_physical_addre=0A =0A 	=
return AE_OK;=0A }=0A+=0A+#define is_xmalloc_memory(ptr) ((unsigned =
long)(ptr) & (PAGE_SIZE - 1))=0A+=0A+void *__init acpi_os_alloc_memory(size=
_t sz)=0A+{=0A+	void *ptr;=0A+=0A+	if (system_state =3D=3D SYS_STATE_e=
arly_boot)=0A+		return mfn_to_virt(alloc_boot_pages(PFN_UP(sz), =
1));=0A+=0A+	ptr =3D xmalloc_bytes(sz);=0A+	ASSERT(!ptr || is_xmalloc_m=
emory(ptr));=0A+	return ptr;=0A+}=0A+=0A+void *__init acpi_os_zalloc=
_memory(size_t sz)=0A+{=0A+	void *ptr;=0A+=0A+	if (system_state =
!=3D SYS_STATE_early_boot) {=0A+		ptr =3D xzalloc_bytes(sz);=
=0A+		ASSERT(!ptr || is_xmalloc_memory(ptr));=0A+		=
return ptr;=0A+	}=0A+	ptr =3D acpi_os_alloc_memory(sz);=0A+	return ptr =
? memset(ptr, 0, sz) : NULL;=0A+}=0A+=0A+void __init acpi_os_free_memory(vo=
id *ptr)=0A+{=0A+	if (is_xmalloc_memory(ptr))=0A+		xfree(ptr);=
=0A+	else if (ptr && system_state =3D=3D SYS_STATE_early_boot)=0A+		=
init_boot_pages(__pa(ptr), __pa(ptr) + PAGE_SIZE);=0A+}=0A--- a/xen/drivers=
/acpi/tables.c=0A+++ b/xen/drivers/acpi/tables.c=0A@@ -41,8 +41,6 @@ =
mps_inti_flags_polarity[] =3D { "dfl", "hi=0A static const char *__initdata=
=0A mps_inti_flags_trigger[] =3D { "dfl", "edge", "res", "level" };=0A =
=0A-static struct acpi_table_desc initial_tables[ACPI_MAX_TABLES];=0A-=0A =
static int acpi_apic_instance __initdata;=0A =0A void __init acpi_table_pri=
nt_madt_entry(struct acpi_subtable_header *header)=0A@@ -324,7 +322,7 @@ =
static void __init check_multiple_madt(v=0A =0A int __init acpi_table_init(=
void)=0A {=0A-	acpi_initialize_tables(initial_tables, ACPI_MAX_TABLES, =
0);=0A+	acpi_initialize_tables(NULL, ACPI_MAX_TABLES, 0);=0A 	check_multi=
ple_madt();=0A 	return 0;=0A }=0A--- a/xen/include/acpi/platform/aclinux.h=
=0A+++ b/xen/include/acpi/platform/aclinux.h=0A@@ -76,8 +76,12 @@=0A =0A =
#define acpi_thread_id struct vcpu *=0A =0A-#define ACPI_ALLOCATE(a)	=
xmalloc_bytes(a)=0A-#define ACPI_ALLOCATE_ZEROED(a)	xzalloc_bytes(a)=0A=
-#define ACPI_FREE(a)		xfree(a)=0A+void *acpi_os_alloc_memory(size=
_t);=0A+void *acpi_os_zalloc_memory(size_t);=0A+void acpi_os_free_memory(vo=
id *);=0A+=0A+#define ACPI_ALLOCATE(a)	acpi_os_alloc_memory(a)=0A+#define =
ACPI_ALLOCATE_ZEROED(a)	acpi_os_zalloc_memory(a)=0A+#define ACPI_FREE(a)	=
	acpi_os_free_memory(a)=0A =0A #endif				/* =
__ACLINUX_H__ */=0A
--=__Part6C5D68CD.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

--=__Part6C5D68CD.0__=--


From xen-devel-bounces@lists.xen.org Wed Sep 19 12:57:48 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Sep 2012 12:57:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TEJqR-0003hu-TX; Wed, 19 Sep 2012 12:57:35 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1TEJqQ-0003hl-KS
	for xen-devel@lists.xen.org; Wed, 19 Sep 2012 12:57:34 +0000
Received: from [85.158.139.211:26169] by server-10.bemta-5.messagelabs.com id
	B8/8B-10969-D31C9505; Wed, 19 Sep 2012 12:57:33 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-206.messagelabs.com!1348059453!19181381!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30310 invoked from network); 19 Sep 2012 12:57:33 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-11.tower-206.messagelabs.com with SMTP;
	19 Sep 2012 12:57:33 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 19 Sep 2012 14:00:09 +0100
Message-Id: <5059DD5A020000780009C523@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 19 Sep 2012 13:57:30 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Keir Fraser" <keir.xen@gmail.com>
References: <5059A56C020000780009C430@nat28.tlf.novell.com>
	<CC7F6DC0.3F265%keir.xen@gmail.com>
In-Reply-To: <CC7F6DC0.3F265%keir.xen@gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] ACPI: move tables.c fully into .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 19.09.12 at 13:40, Keir Fraser <keir.xen@gmail.com> wrote:
> On 19/09/2012 09:58, "Jan Beulich" <JBeulich@suse.com> wrote:
> 
>> Of course, if you're only against the dynamic allocation, moving
>> the array elsewhere would be another option (but would require
>> making the symbol global, whereas here the symbol goes away
>> altogether from the symbol tables).
>> 
>> Yet another option would be to do the dynamic allocation where
>> it was actually intended to be done, passing NULL here. The
>> resizing there isn't being made use of anyway (and wouldn't
>> work afaict), so we could as well do away with it and replace it
>> by the simple allocation needed here (or simply fix it,
>> considering that we might need it at some point).
> 
> I'm not wild about any of the options really. Perhaps passing NULL would be
> best. Still, overall, I'm not *that* bothered. You can have my Ack for the
> original patch:
> Acked-by: Keir Fraser <keir@xen.org>

As you were not really happy with it, and as I (also already in
the past) wondered about when the broken re-allocation there
would hit us, I decided to produce a v2, fixing and using the
re-allocation mechanism instead.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 19 12:57:48 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Sep 2012 12:57:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TEJqR-0003hu-TX; Wed, 19 Sep 2012 12:57:35 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1TEJqQ-0003hl-KS
	for xen-devel@lists.xen.org; Wed, 19 Sep 2012 12:57:34 +0000
Received: from [85.158.139.211:26169] by server-10.bemta-5.messagelabs.com id
	B8/8B-10969-D31C9505; Wed, 19 Sep 2012 12:57:33 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-206.messagelabs.com!1348059453!19181381!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30310 invoked from network); 19 Sep 2012 12:57:33 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-11.tower-206.messagelabs.com with SMTP;
	19 Sep 2012 12:57:33 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 19 Sep 2012 14:00:09 +0100
Message-Id: <5059DD5A020000780009C523@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 19 Sep 2012 13:57:30 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Keir Fraser" <keir.xen@gmail.com>
References: <5059A56C020000780009C430@nat28.tlf.novell.com>
	<CC7F6DC0.3F265%keir.xen@gmail.com>
In-Reply-To: <CC7F6DC0.3F265%keir.xen@gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] ACPI: move tables.c fully into .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 19.09.12 at 13:40, Keir Fraser <keir.xen@gmail.com> wrote:
> On 19/09/2012 09:58, "Jan Beulich" <JBeulich@suse.com> wrote:
> 
>> Of course, if you're only against the dynamic allocation, moving
>> the array elsewhere would be another option (but would require
>> making the symbol global, whereas here the symbol goes away
>> altogether from the symbol tables).
>> 
>> Yet another option would be to do the dynamic allocation where
>> it was actually intended to be done, passing NULL here. The
>> resizing there isn't being made use of anyway (and wouldn't
>> work afaict), so we could as well do away with it and replace it
>> by the simple allocation needed here (or simply fix it,
>> considering that we might need it at some point).
> 
> I'm not wild about any of the options really. Perhaps passing NULL would be
> best. Still, overall, I'm not *that* bothered. You can have my Ack for the
> original patch:
> Acked-by: Keir Fraser <keir@xen.org>

As you were not really happy with it, and as I (also already in
the past) wondered about when the broken re-allocation there
would hit us, I decided to produce a v2, fixing and using the
re-allocation mechanism instead.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 19 13:03:23 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Sep 2012 13:03:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TEJvu-0004OX-WF; Wed, 19 Sep 2012 13:03:15 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1TEJvt-0004Nz-08
	for xen-devel@lists.xensource.com; Wed, 19 Sep 2012 13:03:13 +0000
Received: from [85.158.138.51:32651] by server-10.bemta-3.messagelabs.com id
	9D/ED-10411-092C9505; Wed, 19 Sep 2012 13:03:12 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1348059791!30676673!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTAxNzU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5141 invoked from network); 19 Sep 2012 13:03:11 -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;
	19 Sep 2012 13:03:11 -0000
X-IronPort-AV: E=Sophos;i="4.80,447,1344211200"; d="scan'208";a="14631227"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Sep 2012 13:03: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.279.1;
	Wed, 19 Sep 2012 14:03:10 +0100
Message-ID: <1348059789.14977.119.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Date: Wed, 19 Sep 2012 14:03:09 +0100
In-Reply-To: <alpine.DEB.2.02.1209171153350.29232@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1208221159560.15568@kaball.uk.xensource.com>
	<1345633688-31684-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<1347627587.24226.192.camel@zakaz.uk.xensource.com>
	<20120914160727.1ff41de2@mantra.us.oracle.com>
	<alpine.DEB.2.02.1209171153350.29232@kaball.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-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 v4 1/6] xen: improve changes to
	xen_add_to_physmap
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2012-09-17 at 11:54 +0100, Stefano Stabellini wrote:
> On Sat, 15 Sep 2012, Mukesh Rathor wrote:
> > On Fri, 14 Sep 2012 13:59:47 +0100
> > Ian Campbell <Ian.Campbell@citrix.com> wrote:
> > 
> > > 
> > > On Wed, 2012-08-22 at 12:08 +0100, Stefano Stabellini wrote:
> > > > This is an incremental patch on top of
> > > > c0bc926083b5987a3e9944eec2c12ad0580100e2: in order to retain binary
> > > > compatibility, it is better to introduce foreign_domid as part of a
> > > > union containing both size and foreign_domid.
> > > [...]
> > > > -    domid_t foreign_domid; /* IFF gmfn_foreign */
> > > > +    unsigned int space;
> > > >  
> > > >  #define XENMAPIDX_grant_table_status 0x80000000
> > > 
> > > Was this the final consensus on what this interface ought to look
> > > like?
> > > 
> > > Does it work for PVH too (Mukesh CCd)?
> > 
> > Yes it does. Please lmk if the final version asap so I can put in
> > my patch, and also test it.
> 
> It the final version. I think it should go in, unless we want to drop it
> entirely in favor of xen_add_to_physmap_range.

Here is what I came up with on the ARM side. I'd image the X86 version
would not be that different.

Processing the batch in reverse order allows for continuations without
needing an explicit pdone type thing. Still seems a bit wrong somehow.

diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
index aec57e5..7d6101c 100644
--- a/xen/arch/arm/mm.c
+++ b/xen/arch/arm/mm.c
@@ -26,6 +26,8 @@
 #include <xen/preempt.h>
 #include <xen/errno.h>
 #include <xen/grant_table.h>
+#include <xen/softirq.h>
+#include <xen/event.h>
 #include <xen/guest_access.h>
 #include <xen/domain_page.h>
 #include <asm/page.h>
@@ -462,14 +464,17 @@ void share_xen_page_with_guest(struct page_info *page,
     spin_unlock(&d->page_alloc_lock);
 }
 
-static int xenmem_add_to_physmap_once(
+static int xenmem_add_to_physmap_one(
     struct domain *d,
-    const struct xen_add_to_physmap *xatp)
+    uint16_t space,
+    domid_t foreign_domid,
+    unsigned long idx,
+    xen_pfn_t gpfn)
 {
-    unsigned long mfn = 0, idx = 0;
+    unsigned long mfn = 0;
     int rc;
 
-    switch ( xatp->space )
+    switch ( space )
     {
     case XENMAPSPACE_grant_table:
         spin_lock(&d->grant_table->lock);
@@ -477,9 +482,8 @@ static int xenmem_add_to_physmap_once(
         if ( d->grant_table->gt_version == 0 )
             d->grant_table->gt_version = 1;
 
-        idx = xatp->idx;
         if ( d->grant_table->gt_version == 2 &&
-                (xatp->idx & XENMAPIDX_grant_table_status) )
+                (idx & XENMAPIDX_grant_table_status) )
         {
             idx &= ~XENMAPIDX_grant_table_status;
             if ( idx < nr_status_frames(d->grant_table) )
@@ -498,33 +502,31 @@ static int xenmem_add_to_physmap_once(
         spin_unlock(&d->grant_table->lock);
         break;
     case XENMAPSPACE_shared_info:
-        if ( xatp->idx == 0 )
+        if ( idx == 0 )
             mfn = virt_to_mfn(d->shared_info);
         break;
     case XENMAPSPACE_gmfn_foreign:
     {
         paddr_t maddr;
         struct domain *od;
-        static int x = 0;
-        rc = rcu_lock_target_domain_by_id(xatp->foreign_domid, &od);
+        rc = rcu_lock_target_domain_by_id(foreign_domid, &od);
         if ( rc < 0 )
             return rc;
-        maddr = p2m_lookup(od, xatp->idx << PAGE_SHIFT);
+
+        maddr = p2m_lookup(od, idx << PAGE_SHIFT);
         if ( maddr == INVALID_PADDR )
         {
-            printk("bad p2m lookup\n");
-            dump_p2m_lookup(od, xatp->idx << PAGE_SHIFT);
+            dump_p2m_lookup(od, idx << PAGE_SHIFT);
             rcu_unlock_domain(od);
             return -EINVAL;
         }
+
         mfn = maddr >> PAGE_SHIFT;
-	if (x && x--) {
-            printk("Mapping dom%d mfn 0x%lx to dom%d mfn 0x%"PRIpaddr"\n",
-                   od->domain_id, mfn, d->domain_id, xatp->gpfn);
-        }
+
         rcu_unlock_domain(od);
         break;
     }
+
     default:
         return -ENOSYS;
     }
@@ -532,19 +534,51 @@ static int xenmem_add_to_physmap_once(
     domain_lock(d);
 
     /* Map at new location. */
-    rc = guest_physmap_add_page(d, xatp->gpfn, mfn, 0);
-    if ( 0 && xatp->space == XENMAPSPACE_gmfn_foreign )
-        dump_p2m_lookup(d, xatp->gpfn << PAGE_SHIFT);
+    rc = guest_physmap_add_page(d, gpfn, mfn, 0);
 
     domain_unlock(d);
 
     return rc;
 }
 
-static int xenmem_add_to_physmap(struct domain *d,
-                                 struct xen_add_to_physmap *xatp)
+static int xenmem_add_to_physmap_range(struct domain *d,
+                                       struct xen_add_to_physmap_range *xatpr)
 {
-    return xenmem_add_to_physmap_once(d, xatp);
+    int rc;
+
+    /* Process entries in reverse order to allow continuations */
+    while ( xatpr->size > 0 )
+    {
+        xen_ulong_t idx;
+        xen_pfn_t gpfn;
+
+        rc = copy_from_guest_offset(&idx, xatpr->idxs, xatpr->size-1, 1);
+        if ( rc < 0 )
+            goto out;
+
+        rc = copy_from_guest_offset(&gpfn, xatpr->gpfns, xatpr->size-1, 1);
+        if ( rc < 0 )
+            goto out;
+
+        rc = xenmem_add_to_physmap_one(d, xatpr->space,
+                                       xatpr->foreign_domid,
+                                       idx, gpfn);
+
+        xatpr->size--;
+
+        /* Check for continuation if it's not the last interation */
+        if ( xatpr->size > 0 && hypercall_preempt_check() )
+        {
+            rc = -EAGAIN;
+            goto out;
+        }
+    }
+
+    rc = 0;
+
+out:
+    return rc;
+
 }
 
 long arch_memory_op(int op, XEN_GUEST_HANDLE(void) arg)
@@ -565,13 +599,41 @@ long arch_memory_op(int op, XEN_GUEST_HANDLE(void) arg)
         if ( rc != 0 )
             return rc;
 
-        rc = xenmem_add_to_physmap(d, &xatp);
+        rc = xenmem_add_to_physmap_one(d, xatp.space,
+                                       xatp.foreign_domid,
+                                       xatp.idx, xatp.gpfn);
 
         rcu_unlock_domain(d);
 
         return rc;
     }
 
+    case XENMEM_add_to_physmap_range:
+    {
+        struct xen_add_to_physmap_range xatpr;
+        struct domain *d;
+
+        if ( copy_from_guest(&xatpr, arg, 1) )
+            return -EFAULT;
+
+        rc = rcu_lock_target_domain_by_id(xatpr.domid, &d);
+        if ( rc != 0 )
+            return rc;
+
+        rc = xenmem_add_to_physmap_range(d, &xatpr);
+
+        rcu_unlock_domain(d);
+
+        if ( rc && copy_to_guest(arg, &xatpr, 1) )
+            rc = -EFAULT;
+
+        if ( rc == -EAGAIN )
+            rc = hypercall_create_continuation(
+                __HYPERVISOR_memory_op, "ih", op, arg);
+
+        return rc;
+    }
+
     default:
         return -ENOSYS;
     }
diff --git a/xen/include/public/memory.h b/xen/include/public/memory.h
index b2adfbe..1cc7a80 100644
--- a/xen/include/public/memory.h
+++ b/xen/include/public/memory.h
@@ -198,6 +198,15 @@ struct xen_machphys_mapping {
 typedef struct xen_machphys_mapping xen_machphys_mapping_t;
 DEFINE_XEN_GUEST_HANDLE(xen_machphys_mapping_t);
 
+/* Source mapping space. */
+/* ` enum phys_map_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 dom */
+/* ` } */
+
 /*
  * Sets the GPFN at which a particular page appears in the specified guest's
  * pseudophysical address space.
@@ -211,26 +220,40 @@ struct xen_add_to_physmap {
     /* Number of pages to go through for gmfn_range */
     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 */
-#define XENMAPSPACE_gmfn_foreign 4 /* GMFN from another guest */
-    uint16_t space;
+    uint16_t space; /* => enum phys_map_space */
     domid_t foreign_domid; /* IFF gmfn_foreign */
 
 #define XENMAPIDX_grant_table_status 0x80000000
 
-    /* Index into source mapping space. */
+    /* Index into space being mapped. */
     xen_ulong_t idx;
 
-    /* GPFN where the source mapping page should appear. */
+    /* GPFN in domid where the source mapping page should appear. */
     xen_pfn_t     gpfn;
 };
 typedef struct xen_add_to_physmap xen_add_to_physmap_t;
 DEFINE_XEN_GUEST_HANDLE(xen_add_to_physmap_t);
 
+/* A batched version of add_to_physmap. */
+#define XENMEM_add_to_physmap_range 23
+struct xen_add_to_physmap_range {
+    /* Which domain to change the mapping for. */
+    domid_t domid;
+    uint16_t space; /* => enum phys_map_space */
+
+    /* Number of pages to go through */
+    uint16_t size;
+    domid_t foreign_domid; /* IFF gmfn_foreign */
+
+    /* Indexes into space being mapped. */
+    XEN_GUEST_HANDLE(xen_ulong_t) idxs;
+
+    /* GPFN in domdwhere the source mapping page should appear. */
+    XEN_GUEST_HANDLE(xen_pfn_t) gpfns;
+};
+typedef struct xen_add_to_physmap_range xen_add_to_physmap_range_t;
+DEFINE_XEN_GUEST_HANDLE(xen_add_to_physmap_range_t);
+
 /*
  * Unmaps the page appearing at a particular GPFN from the specified guest's
  * pseudophysical address space.
diff --git a/xen/include/public/xen.h b/xen/include/public/xen.h
index b2f6c50..9425520 100644
--- a/xen/include/public/xen.h
+++ b/xen/include/public/xen.h
@@ -51,6 +51,7 @@ DEFINE_XEN_GUEST_HANDLE(void);
 
 DEFINE_XEN_GUEST_HANDLE(uint64_t);
 DEFINE_XEN_GUEST_HANDLE(xen_pfn_t);
+DEFINE_XEN_GUEST_HANDLE(xen_ulong_t);
 #endif
 
 /*



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 19 13:03:23 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Sep 2012 13:03:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TEJvu-0004OX-WF; Wed, 19 Sep 2012 13:03:15 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1TEJvt-0004Nz-08
	for xen-devel@lists.xensource.com; Wed, 19 Sep 2012 13:03:13 +0000
Received: from [85.158.138.51:32651] by server-10.bemta-3.messagelabs.com id
	9D/ED-10411-092C9505; Wed, 19 Sep 2012 13:03:12 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1348059791!30676673!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTAxNzU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5141 invoked from network); 19 Sep 2012 13:03:11 -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;
	19 Sep 2012 13:03:11 -0000
X-IronPort-AV: E=Sophos;i="4.80,447,1344211200"; d="scan'208";a="14631227"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Sep 2012 13:03: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.279.1;
	Wed, 19 Sep 2012 14:03:10 +0100
Message-ID: <1348059789.14977.119.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Date: Wed, 19 Sep 2012 14:03:09 +0100
In-Reply-To: <alpine.DEB.2.02.1209171153350.29232@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1208221159560.15568@kaball.uk.xensource.com>
	<1345633688-31684-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<1347627587.24226.192.camel@zakaz.uk.xensource.com>
	<20120914160727.1ff41de2@mantra.us.oracle.com>
	<alpine.DEB.2.02.1209171153350.29232@kaball.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-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 v4 1/6] xen: improve changes to
	xen_add_to_physmap
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2012-09-17 at 11:54 +0100, Stefano Stabellini wrote:
> On Sat, 15 Sep 2012, Mukesh Rathor wrote:
> > On Fri, 14 Sep 2012 13:59:47 +0100
> > Ian Campbell <Ian.Campbell@citrix.com> wrote:
> > 
> > > 
> > > On Wed, 2012-08-22 at 12:08 +0100, Stefano Stabellini wrote:
> > > > This is an incremental patch on top of
> > > > c0bc926083b5987a3e9944eec2c12ad0580100e2: in order to retain binary
> > > > compatibility, it is better to introduce foreign_domid as part of a
> > > > union containing both size and foreign_domid.
> > > [...]
> > > > -    domid_t foreign_domid; /* IFF gmfn_foreign */
> > > > +    unsigned int space;
> > > >  
> > > >  #define XENMAPIDX_grant_table_status 0x80000000
> > > 
> > > Was this the final consensus on what this interface ought to look
> > > like?
> > > 
> > > Does it work for PVH too (Mukesh CCd)?
> > 
> > Yes it does. Please lmk if the final version asap so I can put in
> > my patch, and also test it.
> 
> It the final version. I think it should go in, unless we want to drop it
> entirely in favor of xen_add_to_physmap_range.

Here is what I came up with on the ARM side. I'd image the X86 version
would not be that different.

Processing the batch in reverse order allows for continuations without
needing an explicit pdone type thing. Still seems a bit wrong somehow.

diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
index aec57e5..7d6101c 100644
--- a/xen/arch/arm/mm.c
+++ b/xen/arch/arm/mm.c
@@ -26,6 +26,8 @@
 #include <xen/preempt.h>
 #include <xen/errno.h>
 #include <xen/grant_table.h>
+#include <xen/softirq.h>
+#include <xen/event.h>
 #include <xen/guest_access.h>
 #include <xen/domain_page.h>
 #include <asm/page.h>
@@ -462,14 +464,17 @@ void share_xen_page_with_guest(struct page_info *page,
     spin_unlock(&d->page_alloc_lock);
 }
 
-static int xenmem_add_to_physmap_once(
+static int xenmem_add_to_physmap_one(
     struct domain *d,
-    const struct xen_add_to_physmap *xatp)
+    uint16_t space,
+    domid_t foreign_domid,
+    unsigned long idx,
+    xen_pfn_t gpfn)
 {
-    unsigned long mfn = 0, idx = 0;
+    unsigned long mfn = 0;
     int rc;
 
-    switch ( xatp->space )
+    switch ( space )
     {
     case XENMAPSPACE_grant_table:
         spin_lock(&d->grant_table->lock);
@@ -477,9 +482,8 @@ static int xenmem_add_to_physmap_once(
         if ( d->grant_table->gt_version == 0 )
             d->grant_table->gt_version = 1;
 
-        idx = xatp->idx;
         if ( d->grant_table->gt_version == 2 &&
-                (xatp->idx & XENMAPIDX_grant_table_status) )
+                (idx & XENMAPIDX_grant_table_status) )
         {
             idx &= ~XENMAPIDX_grant_table_status;
             if ( idx < nr_status_frames(d->grant_table) )
@@ -498,33 +502,31 @@ static int xenmem_add_to_physmap_once(
         spin_unlock(&d->grant_table->lock);
         break;
     case XENMAPSPACE_shared_info:
-        if ( xatp->idx == 0 )
+        if ( idx == 0 )
             mfn = virt_to_mfn(d->shared_info);
         break;
     case XENMAPSPACE_gmfn_foreign:
     {
         paddr_t maddr;
         struct domain *od;
-        static int x = 0;
-        rc = rcu_lock_target_domain_by_id(xatp->foreign_domid, &od);
+        rc = rcu_lock_target_domain_by_id(foreign_domid, &od);
         if ( rc < 0 )
             return rc;
-        maddr = p2m_lookup(od, xatp->idx << PAGE_SHIFT);
+
+        maddr = p2m_lookup(od, idx << PAGE_SHIFT);
         if ( maddr == INVALID_PADDR )
         {
-            printk("bad p2m lookup\n");
-            dump_p2m_lookup(od, xatp->idx << PAGE_SHIFT);
+            dump_p2m_lookup(od, idx << PAGE_SHIFT);
             rcu_unlock_domain(od);
             return -EINVAL;
         }
+
         mfn = maddr >> PAGE_SHIFT;
-	if (x && x--) {
-            printk("Mapping dom%d mfn 0x%lx to dom%d mfn 0x%"PRIpaddr"\n",
-                   od->domain_id, mfn, d->domain_id, xatp->gpfn);
-        }
+
         rcu_unlock_domain(od);
         break;
     }
+
     default:
         return -ENOSYS;
     }
@@ -532,19 +534,51 @@ static int xenmem_add_to_physmap_once(
     domain_lock(d);
 
     /* Map at new location. */
-    rc = guest_physmap_add_page(d, xatp->gpfn, mfn, 0);
-    if ( 0 && xatp->space == XENMAPSPACE_gmfn_foreign )
-        dump_p2m_lookup(d, xatp->gpfn << PAGE_SHIFT);
+    rc = guest_physmap_add_page(d, gpfn, mfn, 0);
 
     domain_unlock(d);
 
     return rc;
 }
 
-static int xenmem_add_to_physmap(struct domain *d,
-                                 struct xen_add_to_physmap *xatp)
+static int xenmem_add_to_physmap_range(struct domain *d,
+                                       struct xen_add_to_physmap_range *xatpr)
 {
-    return xenmem_add_to_physmap_once(d, xatp);
+    int rc;
+
+    /* Process entries in reverse order to allow continuations */
+    while ( xatpr->size > 0 )
+    {
+        xen_ulong_t idx;
+        xen_pfn_t gpfn;
+
+        rc = copy_from_guest_offset(&idx, xatpr->idxs, xatpr->size-1, 1);
+        if ( rc < 0 )
+            goto out;
+
+        rc = copy_from_guest_offset(&gpfn, xatpr->gpfns, xatpr->size-1, 1);
+        if ( rc < 0 )
+            goto out;
+
+        rc = xenmem_add_to_physmap_one(d, xatpr->space,
+                                       xatpr->foreign_domid,
+                                       idx, gpfn);
+
+        xatpr->size--;
+
+        /* Check for continuation if it's not the last interation */
+        if ( xatpr->size > 0 && hypercall_preempt_check() )
+        {
+            rc = -EAGAIN;
+            goto out;
+        }
+    }
+
+    rc = 0;
+
+out:
+    return rc;
+
 }
 
 long arch_memory_op(int op, XEN_GUEST_HANDLE(void) arg)
@@ -565,13 +599,41 @@ long arch_memory_op(int op, XEN_GUEST_HANDLE(void) arg)
         if ( rc != 0 )
             return rc;
 
-        rc = xenmem_add_to_physmap(d, &xatp);
+        rc = xenmem_add_to_physmap_one(d, xatp.space,
+                                       xatp.foreign_domid,
+                                       xatp.idx, xatp.gpfn);
 
         rcu_unlock_domain(d);
 
         return rc;
     }
 
+    case XENMEM_add_to_physmap_range:
+    {
+        struct xen_add_to_physmap_range xatpr;
+        struct domain *d;
+
+        if ( copy_from_guest(&xatpr, arg, 1) )
+            return -EFAULT;
+
+        rc = rcu_lock_target_domain_by_id(xatpr.domid, &d);
+        if ( rc != 0 )
+            return rc;
+
+        rc = xenmem_add_to_physmap_range(d, &xatpr);
+
+        rcu_unlock_domain(d);
+
+        if ( rc && copy_to_guest(arg, &xatpr, 1) )
+            rc = -EFAULT;
+
+        if ( rc == -EAGAIN )
+            rc = hypercall_create_continuation(
+                __HYPERVISOR_memory_op, "ih", op, arg);
+
+        return rc;
+    }
+
     default:
         return -ENOSYS;
     }
diff --git a/xen/include/public/memory.h b/xen/include/public/memory.h
index b2adfbe..1cc7a80 100644
--- a/xen/include/public/memory.h
+++ b/xen/include/public/memory.h
@@ -198,6 +198,15 @@ struct xen_machphys_mapping {
 typedef struct xen_machphys_mapping xen_machphys_mapping_t;
 DEFINE_XEN_GUEST_HANDLE(xen_machphys_mapping_t);
 
+/* Source mapping space. */
+/* ` enum phys_map_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 dom */
+/* ` } */
+
 /*
  * Sets the GPFN at which a particular page appears in the specified guest's
  * pseudophysical address space.
@@ -211,26 +220,40 @@ struct xen_add_to_physmap {
     /* Number of pages to go through for gmfn_range */
     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 */
-#define XENMAPSPACE_gmfn_foreign 4 /* GMFN from another guest */
-    uint16_t space;
+    uint16_t space; /* => enum phys_map_space */
     domid_t foreign_domid; /* IFF gmfn_foreign */
 
 #define XENMAPIDX_grant_table_status 0x80000000
 
-    /* Index into source mapping space. */
+    /* Index into space being mapped. */
     xen_ulong_t idx;
 
-    /* GPFN where the source mapping page should appear. */
+    /* GPFN in domid where the source mapping page should appear. */
     xen_pfn_t     gpfn;
 };
 typedef struct xen_add_to_physmap xen_add_to_physmap_t;
 DEFINE_XEN_GUEST_HANDLE(xen_add_to_physmap_t);
 
+/* A batched version of add_to_physmap. */
+#define XENMEM_add_to_physmap_range 23
+struct xen_add_to_physmap_range {
+    /* Which domain to change the mapping for. */
+    domid_t domid;
+    uint16_t space; /* => enum phys_map_space */
+
+    /* Number of pages to go through */
+    uint16_t size;
+    domid_t foreign_domid; /* IFF gmfn_foreign */
+
+    /* Indexes into space being mapped. */
+    XEN_GUEST_HANDLE(xen_ulong_t) idxs;
+
+    /* GPFN in domdwhere the source mapping page should appear. */
+    XEN_GUEST_HANDLE(xen_pfn_t) gpfns;
+};
+typedef struct xen_add_to_physmap_range xen_add_to_physmap_range_t;
+DEFINE_XEN_GUEST_HANDLE(xen_add_to_physmap_range_t);
+
 /*
  * Unmaps the page appearing at a particular GPFN from the specified guest's
  * pseudophysical address space.
diff --git a/xen/include/public/xen.h b/xen/include/public/xen.h
index b2f6c50..9425520 100644
--- a/xen/include/public/xen.h
+++ b/xen/include/public/xen.h
@@ -51,6 +51,7 @@ DEFINE_XEN_GUEST_HANDLE(void);
 
 DEFINE_XEN_GUEST_HANDLE(uint64_t);
 DEFINE_XEN_GUEST_HANDLE(xen_pfn_t);
+DEFINE_XEN_GUEST_HANDLE(xen_ulong_t);
 #endif
 
 /*



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 19 13:04:55 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Sep 2012 13:04:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TEJxO-0004c6-GJ; Wed, 19 Sep 2012 13:04:46 +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 1TEJxM-0004bt-Vk
	for xen-devel@lists.xen.org; Wed, 19 Sep 2012 13:04:45 +0000
Received: from [85.158.139.211:56218] by server-3.bemta-5.messagelabs.com id
	00/65-21836-CE2C9505; Wed, 19 Sep 2012 13:04:44 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-14.tower-206.messagelabs.com!1348059882!19119880!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA1MDgyMDI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13983 invoked from network); 19 Sep 2012 13:04:43 -0000
Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25)
	by server-14.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 19 Sep 2012 13:04:43 -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 4A64613FD;
	Wed, 19 Sep 2012 16:04:27 +0300 (EEST)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id 2D8AF2005D; Wed, 19 Sep 2012 16:04:27 +0300 (EEST)
Date: Wed, 19 Sep 2012 16:04:27 +0300
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: Qian Hu <qianhu2011@gmail.com>
Message-ID: <20120919130427.GR8912@reaktio.net>
References: <CALCpXpBnAQr=jk5LbZnQPAuJHrKEAL0ELcZ3L2BRQRUfGbUvAw@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CALCpXpBnAQr=jk5LbZnQPAuJHrKEAL0ELcZ3L2BRQRUfGbUvAw@mail.gmail.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] usbpassthrough of xen-4.1.2
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Sep 19, 2012 at 04:53:33PM +0800, Qian Hu wrote:
>    Hi, everyone!
>    I am working on the USB passthrough of Xen-4.1.2. My host OS  is Fedora 14
>    and the guest OS is win7.
>    According to the wiki
>    page([1]http://wiki.xen.org/wiki/Xen_USB_Passthrough),
>    xen supports passthrough of usb device from dom0 to guests. I have tried
>    the Xen HVM guest qemu-dm usb1.1 emulation,
>    by specifying "usb = 1" and "usbdevice = host:xxxx:yyyy". But, the mouse
>    could work, the keyboard and usb storage failed.
>

at least the usb storage is probably USB2 device, so it might have issues in usb1.1 mode..

Did you get any errors in qemu-dm logs (/var/log/xen/) ? or in dom0 linux dmesg? 


>    If I change the guest OS to winXP, it is surprising that only the usb
>    storage can be detected in the guest.
>    I have also tried the PVUSB, it didn't work either.
>

Did you actually install PVUSB drivers? in dom0 kernel you need xen-usbback driver,
and in the kernel of the VM you need xen-usbfront driver.

-- Pasi


>    I am confused and don't know how to resolve it.  Could anyone help me?
>    Great thanks!
>    huqian
> 
> References
> 
>    Visible links
>    1. http://wiki.xen.org/wiki/Xen_USB_Passthrough

> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Sep 19 13:04:55 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Sep 2012 13:04:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TEJxO-0004c6-GJ; Wed, 19 Sep 2012 13:04:46 +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 1TEJxM-0004bt-Vk
	for xen-devel@lists.xen.org; Wed, 19 Sep 2012 13:04:45 +0000
Received: from [85.158.139.211:56218] by server-3.bemta-5.messagelabs.com id
	00/65-21836-CE2C9505; Wed, 19 Sep 2012 13:04:44 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-14.tower-206.messagelabs.com!1348059882!19119880!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA1MDgyMDI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13983 invoked from network); 19 Sep 2012 13:04:43 -0000
Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25)
	by server-14.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 19 Sep 2012 13:04:43 -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 4A64613FD;
	Wed, 19 Sep 2012 16:04:27 +0300 (EEST)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id 2D8AF2005D; Wed, 19 Sep 2012 16:04:27 +0300 (EEST)
Date: Wed, 19 Sep 2012 16:04:27 +0300
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: Qian Hu <qianhu2011@gmail.com>
Message-ID: <20120919130427.GR8912@reaktio.net>
References: <CALCpXpBnAQr=jk5LbZnQPAuJHrKEAL0ELcZ3L2BRQRUfGbUvAw@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CALCpXpBnAQr=jk5LbZnQPAuJHrKEAL0ELcZ3L2BRQRUfGbUvAw@mail.gmail.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] usbpassthrough of xen-4.1.2
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Sep 19, 2012 at 04:53:33PM +0800, Qian Hu wrote:
>    Hi, everyone!
>    I am working on the USB passthrough of Xen-4.1.2. My host OS  is Fedora 14
>    and the guest OS is win7.
>    According to the wiki
>    page([1]http://wiki.xen.org/wiki/Xen_USB_Passthrough),
>    xen supports passthrough of usb device from dom0 to guests. I have tried
>    the Xen HVM guest qemu-dm usb1.1 emulation,
>    by specifying "usb = 1" and "usbdevice = host:xxxx:yyyy". But, the mouse
>    could work, the keyboard and usb storage failed.
>

at least the usb storage is probably USB2 device, so it might have issues in usb1.1 mode..

Did you get any errors in qemu-dm logs (/var/log/xen/) ? or in dom0 linux dmesg? 


>    If I change the guest OS to winXP, it is surprising that only the usb
>    storage can be detected in the guest.
>    I have also tried the PVUSB, it didn't work either.
>

Did you actually install PVUSB drivers? in dom0 kernel you need xen-usbback driver,
and in the kernel of the VM you need xen-usbfront driver.

-- Pasi


>    I am confused and don't know how to resolve it.  Could anyone help me?
>    Great thanks!
>    huqian
> 
> References
> 
>    Visible links
>    1. http://wiki.xen.org/wiki/Xen_USB_Passthrough

> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Sep 19 13:07:17 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Sep 2012 13:07: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 1TEJzf-0004sc-1u; Wed, 19 Sep 2012 13:07: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 1TEJzd-0004sT-V9
	for xen-devel@lists.xen.org; Wed, 19 Sep 2012 13:07:06 +0000
Received: from [85.158.143.99:42726] by server-3.bemta-4.messagelabs.com id
	C4/CB-10986-973C9505; Wed, 19 Sep 2012 13:07:05 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1348060024!19744491!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTAxNzU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27222 invoked from network); 19 Sep 2012 13:07:04 -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;
	19 Sep 2012 13:07:04 -0000
X-IronPort-AV: E=Sophos;i="4.80,447,1344211200"; d="scan'208";a="14631352"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Sep 2012 13:07: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.279.1; Wed, 19 Sep 2012 14:07:04 +0100
Date: Wed, 19 Sep 2012 14:06:17 +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: <1348052705-16370-1-git-send-email-anthony.perard@citrix.com>
Message-ID: <alpine.DEB.2.02.1209191405590.29232@kaball.uk.xensource.com>
References: <1348052705-16370-1-git-send-email-anthony.perard@citrix.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: "Zhang, Yang Z" <yang.z.zhang@intel.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] xen: Fix,
	no unplug of pt device by platform 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 Wed, 19 Sep 2012, Anthony PERARD wrote:
> The Xen platform device will unplug any NICs if requested by the guest (PVonHVM)
> including a NIC that would have been passthrough. This patch makes sure that a
> passthrough device will not be unplug.
> 
> Reported-by: "Zhang, Yang Z" <yang.z.zhang@intel.com>
> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
> 

Zhang, does it this patch fix the problem for you?


>  hw/xen_platform.c | 8 ++++++--
>  1 file changed, 6 insertions(+), 2 deletions(-)
> 
> diff --git a/hw/xen_platform.c b/hw/xen_platform.c
> index 0d6c2ff..956dbfe 100644
> --- a/hw/xen_platform.c
> +++ b/hw/xen_platform.c
> @@ -85,8 +85,10 @@ static void log_writeb(PCIXenPlatformState *s, char val)
>  
>  static void unplug_nic(PCIBus *b, PCIDevice *d, void *o)
>  {
> +    /* We have to ignore passthrough devices */
>      if (pci_get_word(d->config + PCI_CLASS_DEVICE) ==
> -            PCI_CLASS_NETWORK_ETHERNET) {
> +            PCI_CLASS_NETWORK_ETHERNET
> +            && strcmp(d->name, "xen-pci-passthrough") != 0) {
>          qdev_free(&d->qdev);
>      }
>  }
> @@ -98,8 +100,10 @@ static void pci_unplug_nics(PCIBus *bus)
>  
>  static void unplug_disks(PCIBus *b, PCIDevice *d, void *o)
>  {
> +    /* We have to ignore passthrough devices */
>      if (pci_get_word(d->config + PCI_CLASS_DEVICE) ==
> -            PCI_CLASS_STORAGE_IDE) {
> +            PCI_CLASS_STORAGE_IDE
> +            && strcmp(d->name, "xen-pci-passthrough") != 0) {
>          qdev_unplug(&(d->qdev), 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 Wed Sep 19 13:07:17 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Sep 2012 13:07: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 1TEJzf-0004sc-1u; Wed, 19 Sep 2012 13:07: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 1TEJzd-0004sT-V9
	for xen-devel@lists.xen.org; Wed, 19 Sep 2012 13:07:06 +0000
Received: from [85.158.143.99:42726] by server-3.bemta-4.messagelabs.com id
	C4/CB-10986-973C9505; Wed, 19 Sep 2012 13:07:05 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1348060024!19744491!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTAxNzU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27222 invoked from network); 19 Sep 2012 13:07:04 -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;
	19 Sep 2012 13:07:04 -0000
X-IronPort-AV: E=Sophos;i="4.80,447,1344211200"; d="scan'208";a="14631352"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Sep 2012 13:07: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.279.1; Wed, 19 Sep 2012 14:07:04 +0100
Date: Wed, 19 Sep 2012 14:06:17 +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: <1348052705-16370-1-git-send-email-anthony.perard@citrix.com>
Message-ID: <alpine.DEB.2.02.1209191405590.29232@kaball.uk.xensource.com>
References: <1348052705-16370-1-git-send-email-anthony.perard@citrix.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: "Zhang, Yang Z" <yang.z.zhang@intel.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] xen: Fix,
	no unplug of pt device by platform 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 Wed, 19 Sep 2012, Anthony PERARD wrote:
> The Xen platform device will unplug any NICs if requested by the guest (PVonHVM)
> including a NIC that would have been passthrough. This patch makes sure that a
> passthrough device will not be unplug.
> 
> Reported-by: "Zhang, Yang Z" <yang.z.zhang@intel.com>
> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
> 

Zhang, does it this patch fix the problem for you?


>  hw/xen_platform.c | 8 ++++++--
>  1 file changed, 6 insertions(+), 2 deletions(-)
> 
> diff --git a/hw/xen_platform.c b/hw/xen_platform.c
> index 0d6c2ff..956dbfe 100644
> --- a/hw/xen_platform.c
> +++ b/hw/xen_platform.c
> @@ -85,8 +85,10 @@ static void log_writeb(PCIXenPlatformState *s, char val)
>  
>  static void unplug_nic(PCIBus *b, PCIDevice *d, void *o)
>  {
> +    /* We have to ignore passthrough devices */
>      if (pci_get_word(d->config + PCI_CLASS_DEVICE) ==
> -            PCI_CLASS_NETWORK_ETHERNET) {
> +            PCI_CLASS_NETWORK_ETHERNET
> +            && strcmp(d->name, "xen-pci-passthrough") != 0) {
>          qdev_free(&d->qdev);
>      }
>  }
> @@ -98,8 +100,10 @@ static void pci_unplug_nics(PCIBus *bus)
>  
>  static void unplug_disks(PCIBus *b, PCIDevice *d, void *o)
>  {
> +    /* We have to ignore passthrough devices */
>      if (pci_get_word(d->config + PCI_CLASS_DEVICE) ==
> -            PCI_CLASS_STORAGE_IDE) {
> +            PCI_CLASS_STORAGE_IDE
> +            && strcmp(d->name, "xen-pci-passthrough") != 0) {
>          qdev_unplug(&(d->qdev), 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 Wed Sep 19 13:09:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Sep 2012 13: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 1TEK2F-0005Ea-FO; Wed, 19 Sep 2012 13:09: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 1TEK2D-0005E8-Pm
	for xen-devel@lists.xensource.com; Wed, 19 Sep 2012 13:09:46 +0000
Received: from [85.158.138.51:42016] by server-10.bemta-3.messagelabs.com id
	46/60-10411-914C9505; Wed, 19 Sep 2012 13:09:45 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1348060183!22303494!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTAxNzU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8751 invoked from network); 19 Sep 2012 13:09:44 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Sep 2012 13:09:44 -0000
X-IronPort-AV: E=Sophos;i="4.80,447,1344211200"; d="scan'208";a="14631447"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Sep 2012 13:09: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.279.1;
	Wed, 19 Sep 2012 14:09:42 +0100
Message-ID: <1348060180.14977.123.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Date: Wed, 19 Sep 2012 14:09:40 +0100
In-Reply-To: <1348059789.14977.119.camel@zakaz.uk.xensource.com>
References: <alpine.DEB.2.02.1208221159560.15568@kaball.uk.xensource.com>
	<1345633688-31684-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<1347627587.24226.192.camel@zakaz.uk.xensource.com>
	<20120914160727.1ff41de2@mantra.us.oracle.com>
	<alpine.DEB.2.02.1209171153350.29232@kaball.uk.xensource.com>
	<1348059789.14977.119.camel@zakaz.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-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 v4 1/6] xen: improve changes to
 xen_add_to_physmap
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-09-19 at 14:03 +0100, Ian Campbell wrote:

> > It the final version. I think it should go in, unless we want to drop it
> > entirely in favor of xen_add_to_physmap_range.
> 
> Here is what I came up with on the ARM side. I'd image the X86 version
> would not be that different.

Here the (obvious) Linux side, for reference. No actual use of batching
just yet. It's based on top of a somewhat bastardized version of
Mukesh's PVH patches for privcmd.

Ian.

diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
index 43277f8..f01120a 100644
--- a/arch/arm/xen/enlighten.c
+++ b/arch/arm/xen/enlighten.c
@@ -88,13 +88,20 @@ static int pvh_add_to_xen_p2m(unsigned long lpfn, unsigned long fgmfn,
 			      unsigned int domid)
 {
 	int rc;
-	struct xen_add_to_physmap pmb = {.foreign_domid = domid};
-
-	pmb.gpfn = lpfn;
-	pmb.idx = fgmfn;
-	pmb.space = XENMAPSPACE_gmfn_foreign;
-
-	rc = HYPERVISOR_memory_op(XENMEM_add_to_physmap, &pmb);
+	struct xen_add_to_physmap_range xatp = {
+		.domid = DOMID_SELF,
+		.foreign_domid = domid,
+		.size = 1,
+		.space = XENMAPSPACE_gmfn_foreign,
+	};
+	unsigned long idx = fgmfn;
+	xen_pfn_t gpfn = lpfn;
+
+	set_xen_guest_handle(xatp.idxs, &idx);
+	set_xen_guest_handle(xatp.gpfns, &gpfn);
+		       domid, fgmfn, lpfn);
+
+	rc = HYPERVISOR_memory_op(XENMEM_add_to_physmap_range, &xatp);
 	if (rc) {
 		pr_warn("Failed to map pfn to mfn rc:%d pfn:%lx mfn:%lx\n",
 			rc, lpfn, fgmfn);
diff --git a/include/xen/interface/memory.h b/include/xen/interface/memory.h
index 8728330..64cabbb 100644
--- a/include/xen/interface/memory.h
+++ b/include/xen/interface/memory.h
@@ -183,6 +183,24 @@ struct xen_add_to_physmap {
 };
 DEFINE_GUEST_HANDLE_STRUCT(xen_add_to_physmap);
 
+#define XENMEM_add_to_physmap_range 23
+struct xen_add_to_physmap_range {
+    /* Which domain to change the mapping for. */
+    domid_t domid;
+    uint16_t space; /* => enum phys_map_space */
+
+    /* Number of pages to go through */
+    uint16_t size;
+    domid_t foreign_domid; /* IFF gmfn_foreign */
+
+    /* Indexes into space being mapped. */
+    GUEST_HANDLE(ulong) idxs;
+
+    /* GPFN in domdwhere the source mapping page should appear. */
+    GUEST_HANDLE(xen_pfn_t) gpfns;
+};
+DEFINE_GUEST_HANDLE_STRUCT(xen_add_to_physmap_range);
+
 /*
  * Translates a list of domain-specific GPFNs into MFNs. Returns a -ve error
  * code on failure. This call only works for auto-translated guests.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 19 13:09:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Sep 2012 13: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 1TEK2F-0005Ea-FO; Wed, 19 Sep 2012 13:09: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 1TEK2D-0005E8-Pm
	for xen-devel@lists.xensource.com; Wed, 19 Sep 2012 13:09:46 +0000
Received: from [85.158.138.51:42016] by server-10.bemta-3.messagelabs.com id
	46/60-10411-914C9505; Wed, 19 Sep 2012 13:09:45 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1348060183!22303494!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTAxNzU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8751 invoked from network); 19 Sep 2012 13:09:44 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Sep 2012 13:09:44 -0000
X-IronPort-AV: E=Sophos;i="4.80,447,1344211200"; d="scan'208";a="14631447"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Sep 2012 13:09: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.279.1;
	Wed, 19 Sep 2012 14:09:42 +0100
Message-ID: <1348060180.14977.123.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Date: Wed, 19 Sep 2012 14:09:40 +0100
In-Reply-To: <1348059789.14977.119.camel@zakaz.uk.xensource.com>
References: <alpine.DEB.2.02.1208221159560.15568@kaball.uk.xensource.com>
	<1345633688-31684-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<1347627587.24226.192.camel@zakaz.uk.xensource.com>
	<20120914160727.1ff41de2@mantra.us.oracle.com>
	<alpine.DEB.2.02.1209171153350.29232@kaball.uk.xensource.com>
	<1348059789.14977.119.camel@zakaz.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-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 v4 1/6] xen: improve changes to
 xen_add_to_physmap
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-09-19 at 14:03 +0100, Ian Campbell wrote:

> > It the final version. I think it should go in, unless we want to drop it
> > entirely in favor of xen_add_to_physmap_range.
> 
> Here is what I came up with on the ARM side. I'd image the X86 version
> would not be that different.

Here the (obvious) Linux side, for reference. No actual use of batching
just yet. It's based on top of a somewhat bastardized version of
Mukesh's PVH patches for privcmd.

Ian.

diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
index 43277f8..f01120a 100644
--- a/arch/arm/xen/enlighten.c
+++ b/arch/arm/xen/enlighten.c
@@ -88,13 +88,20 @@ static int pvh_add_to_xen_p2m(unsigned long lpfn, unsigned long fgmfn,
 			      unsigned int domid)
 {
 	int rc;
-	struct xen_add_to_physmap pmb = {.foreign_domid = domid};
-
-	pmb.gpfn = lpfn;
-	pmb.idx = fgmfn;
-	pmb.space = XENMAPSPACE_gmfn_foreign;
-
-	rc = HYPERVISOR_memory_op(XENMEM_add_to_physmap, &pmb);
+	struct xen_add_to_physmap_range xatp = {
+		.domid = DOMID_SELF,
+		.foreign_domid = domid,
+		.size = 1,
+		.space = XENMAPSPACE_gmfn_foreign,
+	};
+	unsigned long idx = fgmfn;
+	xen_pfn_t gpfn = lpfn;
+
+	set_xen_guest_handle(xatp.idxs, &idx);
+	set_xen_guest_handle(xatp.gpfns, &gpfn);
+		       domid, fgmfn, lpfn);
+
+	rc = HYPERVISOR_memory_op(XENMEM_add_to_physmap_range, &xatp);
 	if (rc) {
 		pr_warn("Failed to map pfn to mfn rc:%d pfn:%lx mfn:%lx\n",
 			rc, lpfn, fgmfn);
diff --git a/include/xen/interface/memory.h b/include/xen/interface/memory.h
index 8728330..64cabbb 100644
--- a/include/xen/interface/memory.h
+++ b/include/xen/interface/memory.h
@@ -183,6 +183,24 @@ struct xen_add_to_physmap {
 };
 DEFINE_GUEST_HANDLE_STRUCT(xen_add_to_physmap);
 
+#define XENMEM_add_to_physmap_range 23
+struct xen_add_to_physmap_range {
+    /* Which domain to change the mapping for. */
+    domid_t domid;
+    uint16_t space; /* => enum phys_map_space */
+
+    /* Number of pages to go through */
+    uint16_t size;
+    domid_t foreign_domid; /* IFF gmfn_foreign */
+
+    /* Indexes into space being mapped. */
+    GUEST_HANDLE(ulong) idxs;
+
+    /* GPFN in domdwhere the source mapping page should appear. */
+    GUEST_HANDLE(xen_pfn_t) gpfns;
+};
+DEFINE_GUEST_HANDLE_STRUCT(xen_add_to_physmap_range);
+
 /*
  * Translates a list of domain-specific GPFNs into MFNs. Returns a -ve error
  * code on failure. This call only works for auto-translated guests.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 19 13:16:46 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Sep 2012 13: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 1TEK8q-0005wE-35; Wed, 19 Sep 2012 13:16:36 +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 1TEK8p-0005w5-35
	for xen-devel@lists.xen.org; Wed, 19 Sep 2012 13:16:35 +0000
Received: from [85.158.138.51:34925] by server-5.bemta-3.messagelabs.com id
	C6/3C-13133-2B5C9505; Wed, 19 Sep 2012 13:16:34 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-10.tower-174.messagelabs.com!1348060593!23576588!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA1MDgyMDI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4519 invoked from network); 19 Sep 2012 13:16:33 -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; 19 Sep 2012 13:16:33 -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 C5F0E1C71;
	Wed, 19 Sep 2012 16:16:32 +0300 (EEST)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id 936D02005D; Wed, 19 Sep 2012 16:16:32 +0300 (EEST)
Date: Wed, 19 Sep 2012 16:16:32 +0300
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: Oliver Chick <oliver.chick@citrix.com>
Message-ID: <20120919131632.GS8912@reaktio.net>
References: <1348051887-21885-1-git-send-email-oliver.chick@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1348051887-21885-1-git-send-email-oliver.chick@citrix.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: konrad.wilk@oracle.com, linux-kernel@vger.kernel.org,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] Persistent grant maps for xen blk drivers
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Sep 19, 2012 at 11:51:27AM +0100, Oliver Chick wrote:
> This patch implements persistent grants for the xen-blk{front,back}
> mechanism. The effect of this change is to reduce the number of unmap
> operations performed, since they cause a (costly) TLB shootdown. This
> allows the I/O performance to scale better when a large number of VMs
> are performing I/O.
> 
> Previously, the blkfront driver was supplied a bvec[] from the request
> queue. This was granted to dom0; dom0 performed the I/O and wrote
> directly into the grant-mapped memory and unmapped it; blkfront then
> removed foreign access for that grant. The cost of unmapping scales
> badly with the number of CPUs in Dom0. An experiment showed that when
> Dom0 has 24 VCPUs, and guests are performing parallel I/O to a
> ramdisk, the IPIs from performing unmap's is a bottleneck at 5 guests
> (at which point 650,000 IOPS are being performed in total). If more
> than 5 guests are used, the performance declines. By 10 guests, only
> 400,000 IOPS are being performed.
> 
> This patch improves performance by only unmapping when the connection
> between blkfront and back is broken.
>

So how many IOPS can you get with this patch / persistent grants ? 

-- Pasi


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 19 13:16:46 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Sep 2012 13: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 1TEK8q-0005wE-35; Wed, 19 Sep 2012 13:16:36 +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 1TEK8p-0005w5-35
	for xen-devel@lists.xen.org; Wed, 19 Sep 2012 13:16:35 +0000
Received: from [85.158.138.51:34925] by server-5.bemta-3.messagelabs.com id
	C6/3C-13133-2B5C9505; Wed, 19 Sep 2012 13:16:34 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-10.tower-174.messagelabs.com!1348060593!23576588!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA1MDgyMDI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4519 invoked from network); 19 Sep 2012 13:16:33 -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; 19 Sep 2012 13:16:33 -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 C5F0E1C71;
	Wed, 19 Sep 2012 16:16:32 +0300 (EEST)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id 936D02005D; Wed, 19 Sep 2012 16:16:32 +0300 (EEST)
Date: Wed, 19 Sep 2012 16:16:32 +0300
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: Oliver Chick <oliver.chick@citrix.com>
Message-ID: <20120919131632.GS8912@reaktio.net>
References: <1348051887-21885-1-git-send-email-oliver.chick@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1348051887-21885-1-git-send-email-oliver.chick@citrix.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: konrad.wilk@oracle.com, linux-kernel@vger.kernel.org,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] Persistent grant maps for xen blk drivers
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Sep 19, 2012 at 11:51:27AM +0100, Oliver Chick wrote:
> This patch implements persistent grants for the xen-blk{front,back}
> mechanism. The effect of this change is to reduce the number of unmap
> operations performed, since they cause a (costly) TLB shootdown. This
> allows the I/O performance to scale better when a large number of VMs
> are performing I/O.
> 
> Previously, the blkfront driver was supplied a bvec[] from the request
> queue. This was granted to dom0; dom0 performed the I/O and wrote
> directly into the grant-mapped memory and unmapped it; blkfront then
> removed foreign access for that grant. The cost of unmapping scales
> badly with the number of CPUs in Dom0. An experiment showed that when
> Dom0 has 24 VCPUs, and guests are performing parallel I/O to a
> ramdisk, the IPIs from performing unmap's is a bottleneck at 5 guests
> (at which point 650,000 IOPS are being performed in total). If more
> than 5 guests are used, the performance declines. By 10 guests, only
> 400,000 IOPS are being performed.
> 
> This patch improves performance by only unmapping when the connection
> between blkfront and back is broken.
>

So how many IOPS can you get with this patch / persistent grants ? 

-- Pasi


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 19 13:18:29 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Sep 2012 13:18:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TEKAT-00065O-JJ; Wed, 19 Sep 2012 13:18:17 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1TEKAR-000659-Mi
	for xen-devel@lists.xensource.com; Wed, 19 Sep 2012 13:18:16 +0000
Received: from [85.158.138.51:32312] by server-5.bemta-3.messagelabs.com id
	66/BF-13133-616C9505; Wed, 19 Sep 2012 13:18:14 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1348060693!23100871!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTAxNzU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3147 invoked from network); 19 Sep 2012 13:18:14 -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;
	19 Sep 2012 13:18:14 -0000
X-IronPort-AV: E=Sophos;i="4.80,447,1344211200"; d="scan'208";a="14631692"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Sep 2012 13:18:13 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Wed, 19 Sep 2012 14:18:13 +0100
Date: Wed, 19 Sep 2012 14:17: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: <1348059789.14977.119.camel@zakaz.uk.xensource.com>
Message-ID: <alpine.DEB.2.02.1209191408460.29232@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1208221159560.15568@kaball.uk.xensource.com>
	<1345633688-31684-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<1347627587.24226.192.camel@zakaz.uk.xensource.com>
	<20120914160727.1ff41de2@mantra.us.oracle.com> 
	<alpine.DEB.2.02.1209171153350.29232@kaball.uk.xensource.com>
	<1348059789.14977.119.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 v4 1/6] xen: improve changes to
	xen_add_to_physmap
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 19 Sep 2012, Ian Campbell wrote:
> Here is what I came up with on the ARM side. I'd image the X86 version
> would not be that different.
> 
> Processing the batch in reverse order allows for continuations without
> needing an explicit pdone type thing. Still seems a bit wrong somehow.
> 
> diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
> index aec57e5..7d6101c 100644
> --- a/xen/arch/arm/mm.c
> +++ b/xen/arch/arm/mm.c
> @@ -26,6 +26,8 @@
>  #include <xen/preempt.h>
>  #include <xen/errno.h>
>  #include <xen/grant_table.h>
> +#include <xen/softirq.h>
> +#include <xen/event.h>
>  #include <xen/guest_access.h>
>  #include <xen/domain_page.h>
>  #include <asm/page.h>
> @@ -462,14 +464,17 @@ void share_xen_page_with_guest(struct page_info *page,
>      spin_unlock(&d->page_alloc_lock);
>  }
>  
> -static int xenmem_add_to_physmap_once(
> +static int xenmem_add_to_physmap_one(
>      struct domain *d,
> -    const struct xen_add_to_physmap *xatp)
> +    uint16_t space,
> +    domid_t foreign_domid,
> +    unsigned long idx,
> +    xen_pfn_t gpfn)
>  {
> -    unsigned long mfn = 0, idx = 0;
> +    unsigned long mfn = 0;
>      int rc;
>  
> -    switch ( xatp->space )
> +    switch ( space )
>      {
>      case XENMAPSPACE_grant_table:
>          spin_lock(&d->grant_table->lock);
> @@ -477,9 +482,8 @@ static int xenmem_add_to_physmap_once(
>          if ( d->grant_table->gt_version == 0 )
>              d->grant_table->gt_version = 1;
>  
> -        idx = xatp->idx;
>          if ( d->grant_table->gt_version == 2 &&
> -                (xatp->idx & XENMAPIDX_grant_table_status) )
> +                (idx & XENMAPIDX_grant_table_status) )
>          {
>              idx &= ~XENMAPIDX_grant_table_status;
>              if ( idx < nr_status_frames(d->grant_table) )
> @@ -498,33 +502,31 @@ static int xenmem_add_to_physmap_once(
>          spin_unlock(&d->grant_table->lock);
>          break;
>      case XENMAPSPACE_shared_info:
> -        if ( xatp->idx == 0 )
> +        if ( idx == 0 )
>              mfn = virt_to_mfn(d->shared_info);
>          break;
>      case XENMAPSPACE_gmfn_foreign:
>      {
>          paddr_t maddr;
>          struct domain *od;
> -        static int x = 0;
> -        rc = rcu_lock_target_domain_by_id(xatp->foreign_domid, &od);
> +        rc = rcu_lock_target_domain_by_id(foreign_domid, &od);
>          if ( rc < 0 )
>              return rc;
> -        maddr = p2m_lookup(od, xatp->idx << PAGE_SHIFT);
> +
> +        maddr = p2m_lookup(od, idx << PAGE_SHIFT);
>          if ( maddr == INVALID_PADDR )
>          {
> -            printk("bad p2m lookup\n");
> -            dump_p2m_lookup(od, xatp->idx << PAGE_SHIFT);
> +            dump_p2m_lookup(od, idx << PAGE_SHIFT);
>              rcu_unlock_domain(od);
>              return -EINVAL;
>          }
> +
>          mfn = maddr >> PAGE_SHIFT;
> -	if (x && x--) {
> -            printk("Mapping dom%d mfn 0x%lx to dom%d mfn 0x%"PRIpaddr"\n",
> -                   od->domain_id, mfn, d->domain_id, xatp->gpfn);
> -        }

why remove the printk here?


>          rcu_unlock_domain(od);
>          break;
>      }
> +
>      default:
>          return -ENOSYS;
>      }
> @@ -532,19 +534,51 @@ static int xenmem_add_to_physmap_once(
>      domain_lock(d);
>  
>      /* Map at new location. */
> -    rc = guest_physmap_add_page(d, xatp->gpfn, mfn, 0);
> -    if ( 0 && xatp->space == XENMAPSPACE_gmfn_foreign )
> -        dump_p2m_lookup(d, xatp->gpfn << PAGE_SHIFT);
> +    rc = guest_physmap_add_page(d, gpfn, mfn, 0);
>  
>      domain_unlock(d);
>  
>      return rc;
>  }
>  
> -static int xenmem_add_to_physmap(struct domain *d,
> -                                 struct xen_add_to_physmap *xatp)
> +static int xenmem_add_to_physmap_range(struct domain *d,
> +                                       struct xen_add_to_physmap_range *xatpr)
>  {
> -    return xenmem_add_to_physmap_once(d, xatp);
> +    int rc;
> +
> +    /* Process entries in reverse order to allow continuations */
> +    while ( xatpr->size > 0 )
> +    {
> +        xen_ulong_t idx;
> +        xen_pfn_t gpfn;
> +
> +        rc = copy_from_guest_offset(&idx, xatpr->idxs, xatpr->size-1, 1);
> +        if ( rc < 0 )
> +            goto out;
> +
> +        rc = copy_from_guest_offset(&gpfn, xatpr->gpfns, xatpr->size-1, 1);
> +        if ( rc < 0 )
> +            goto out;
> +
> +        rc = xenmem_add_to_physmap_one(d, xatpr->space,
> +                                       xatpr->foreign_domid,
> +                                       idx, gpfn);
> +
> +        xatpr->size--;
> +
> +        /* Check for continuation if it's not the last interation */
> +        if ( xatpr->size > 0 && hypercall_preempt_check() )
> +        {
> +            rc = -EAGAIN;
> +            goto out;
> +        }
> +    }
> +
> +    rc = 0;
> +
> +out:
> +    return rc;
> +
>  }
>  
>  long arch_memory_op(int op, XEN_GUEST_HANDLE(void) arg)
> @@ -565,13 +599,41 @@ long arch_memory_op(int op, XEN_GUEST_HANDLE(void) arg)
>          if ( rc != 0 )
>              return rc;
>  
> -        rc = xenmem_add_to_physmap(d, &xatp);
> +        rc = xenmem_add_to_physmap_one(d, xatp.space,
> +                                       xatp.foreign_domid,
> +                                       xatp.idx, xatp.gpfn);
>  
>          rcu_unlock_domain(d);
>  
>          return rc;
>      }
>  
> +    case XENMEM_add_to_physmap_range:
> +    {
> +        struct xen_add_to_physmap_range xatpr;
> +        struct domain *d;
> +
> +        if ( copy_from_guest(&xatpr, arg, 1) )
> +            return -EFAULT;
> +
> +        rc = rcu_lock_target_domain_by_id(xatpr.domid, &d);
> +        if ( rc != 0 )
> +            return rc;
> +
> +        rc = xenmem_add_to_physmap_range(d, &xatpr);
> +
> +        rcu_unlock_domain(d);
> +
> +        if ( rc && copy_to_guest(arg, &xatpr, 1) )
> +            rc = -EFAULT;
> +
> +        if ( rc == -EAGAIN )
> +            rc = hypercall_create_continuation(
> +                __HYPERVISOR_memory_op, "ih", op, arg);
> +
> +        return rc;
> +    }
> +
>      default:
>          return -ENOSYS;
>      }
> diff --git a/xen/include/public/memory.h b/xen/include/public/memory.h
> index b2adfbe..1cc7a80 100644
> --- a/xen/include/public/memory.h
> +++ b/xen/include/public/memory.h
> @@ -198,6 +198,15 @@ struct xen_machphys_mapping {
>  typedef struct xen_machphys_mapping xen_machphys_mapping_t;
>  DEFINE_XEN_GUEST_HANDLE(xen_machphys_mapping_t);
>  
> +/* Source mapping space. */
> +/* ` enum phys_map_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 dom */
> +/* ` } */
>  /*
>   * Sets the GPFN at which a particular page appears in the specified guest's
>   * pseudophysical address space.
> @@ -211,26 +220,40 @@ struct xen_add_to_physmap {
>      /* Number of pages to go through for gmfn_range */
>      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 */
> -#define XENMAPSPACE_gmfn_foreign 4 /* GMFN from another guest */
> -    uint16_t space;
> +    uint16_t space; /* => enum phys_map_space */
>      domid_t foreign_domid; /* IFF gmfn_foreign */

I don't like very much that you have a uint16_t in the struct that
actually represents a union


>  #define XENMAPIDX_grant_table_status 0x80000000
>  
> -    /* Index into source mapping space. */
> +    /* Index into space being mapped. */
>      xen_ulong_t idx;
>  
> -    /* GPFN where the source mapping page should appear. */
> +    /* GPFN in domid where the source mapping page should appear. */
>      xen_pfn_t     gpfn;
>  };
>  typedef struct xen_add_to_physmap xen_add_to_physmap_t;
>  DEFINE_XEN_GUEST_HANDLE(xen_add_to_physmap_t);
>  
> +/* A batched version of add_to_physmap. */
> +#define XENMEM_add_to_physmap_range 23
> +struct xen_add_to_physmap_range {
> +    /* Which domain to change the mapping for. */
> +    domid_t domid;
> +    uint16_t space; /* => enum phys_map_space */
> +
> +    /* Number of pages to go through */
> +    uint16_t size;
> +    domid_t foreign_domid; /* IFF gmfn_foreign */
> +
> +    /* Indexes into space being mapped. */
> +    XEN_GUEST_HANDLE(xen_ulong_t) idxs;
> +
> +    /* GPFN in domdwhere the source mapping page should appear. */
                     ^ domid where

> +    XEN_GUEST_HANDLE(xen_pfn_t) gpfns;
> +};
> +typedef struct xen_add_to_physmap_range xen_add_to_physmap_range_t;
> +DEFINE_XEN_GUEST_HANDLE(xen_add_to_physmap_range_t);
> +
>  /*
>   * Unmaps the page appearing at a particular GPFN from the specified guest's
>   * pseudophysical address space.
> diff --git a/xen/include/public/xen.h b/xen/include/public/xen.h
> index b2f6c50..9425520 100644
> --- a/xen/include/public/xen.h
> +++ b/xen/include/public/xen.h
> @@ -51,6 +51,7 @@ DEFINE_XEN_GUEST_HANDLE(void);
>  
>  DEFINE_XEN_GUEST_HANDLE(uint64_t);
>  DEFINE_XEN_GUEST_HANDLE(xen_pfn_t);
> +DEFINE_XEN_GUEST_HANDLE(xen_ulong_t);
>  #endif

You shouldn't need that: xen_ulong_t is already defined in arch-arm.h
(and arch-x86/xen.h)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 19 13:18:29 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Sep 2012 13:18:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TEKAT-00065O-JJ; Wed, 19 Sep 2012 13:18:17 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1TEKAR-000659-Mi
	for xen-devel@lists.xensource.com; Wed, 19 Sep 2012 13:18:16 +0000
Received: from [85.158.138.51:32312] by server-5.bemta-3.messagelabs.com id
	66/BF-13133-616C9505; Wed, 19 Sep 2012 13:18:14 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1348060693!23100871!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTAxNzU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3147 invoked from network); 19 Sep 2012 13:18:14 -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;
	19 Sep 2012 13:18:14 -0000
X-IronPort-AV: E=Sophos;i="4.80,447,1344211200"; d="scan'208";a="14631692"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Sep 2012 13:18:13 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Wed, 19 Sep 2012 14:18:13 +0100
Date: Wed, 19 Sep 2012 14:17: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: <1348059789.14977.119.camel@zakaz.uk.xensource.com>
Message-ID: <alpine.DEB.2.02.1209191408460.29232@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1208221159560.15568@kaball.uk.xensource.com>
	<1345633688-31684-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<1347627587.24226.192.camel@zakaz.uk.xensource.com>
	<20120914160727.1ff41de2@mantra.us.oracle.com> 
	<alpine.DEB.2.02.1209171153350.29232@kaball.uk.xensource.com>
	<1348059789.14977.119.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 v4 1/6] xen: improve changes to
	xen_add_to_physmap
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 19 Sep 2012, Ian Campbell wrote:
> Here is what I came up with on the ARM side. I'd image the X86 version
> would not be that different.
> 
> Processing the batch in reverse order allows for continuations without
> needing an explicit pdone type thing. Still seems a bit wrong somehow.
> 
> diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
> index aec57e5..7d6101c 100644
> --- a/xen/arch/arm/mm.c
> +++ b/xen/arch/arm/mm.c
> @@ -26,6 +26,8 @@
>  #include <xen/preempt.h>
>  #include <xen/errno.h>
>  #include <xen/grant_table.h>
> +#include <xen/softirq.h>
> +#include <xen/event.h>
>  #include <xen/guest_access.h>
>  #include <xen/domain_page.h>
>  #include <asm/page.h>
> @@ -462,14 +464,17 @@ void share_xen_page_with_guest(struct page_info *page,
>      spin_unlock(&d->page_alloc_lock);
>  }
>  
> -static int xenmem_add_to_physmap_once(
> +static int xenmem_add_to_physmap_one(
>      struct domain *d,
> -    const struct xen_add_to_physmap *xatp)
> +    uint16_t space,
> +    domid_t foreign_domid,
> +    unsigned long idx,
> +    xen_pfn_t gpfn)
>  {
> -    unsigned long mfn = 0, idx = 0;
> +    unsigned long mfn = 0;
>      int rc;
>  
> -    switch ( xatp->space )
> +    switch ( space )
>      {
>      case XENMAPSPACE_grant_table:
>          spin_lock(&d->grant_table->lock);
> @@ -477,9 +482,8 @@ static int xenmem_add_to_physmap_once(
>          if ( d->grant_table->gt_version == 0 )
>              d->grant_table->gt_version = 1;
>  
> -        idx = xatp->idx;
>          if ( d->grant_table->gt_version == 2 &&
> -                (xatp->idx & XENMAPIDX_grant_table_status) )
> +                (idx & XENMAPIDX_grant_table_status) )
>          {
>              idx &= ~XENMAPIDX_grant_table_status;
>              if ( idx < nr_status_frames(d->grant_table) )
> @@ -498,33 +502,31 @@ static int xenmem_add_to_physmap_once(
>          spin_unlock(&d->grant_table->lock);
>          break;
>      case XENMAPSPACE_shared_info:
> -        if ( xatp->idx == 0 )
> +        if ( idx == 0 )
>              mfn = virt_to_mfn(d->shared_info);
>          break;
>      case XENMAPSPACE_gmfn_foreign:
>      {
>          paddr_t maddr;
>          struct domain *od;
> -        static int x = 0;
> -        rc = rcu_lock_target_domain_by_id(xatp->foreign_domid, &od);
> +        rc = rcu_lock_target_domain_by_id(foreign_domid, &od);
>          if ( rc < 0 )
>              return rc;
> -        maddr = p2m_lookup(od, xatp->idx << PAGE_SHIFT);
> +
> +        maddr = p2m_lookup(od, idx << PAGE_SHIFT);
>          if ( maddr == INVALID_PADDR )
>          {
> -            printk("bad p2m lookup\n");
> -            dump_p2m_lookup(od, xatp->idx << PAGE_SHIFT);
> +            dump_p2m_lookup(od, idx << PAGE_SHIFT);
>              rcu_unlock_domain(od);
>              return -EINVAL;
>          }
> +
>          mfn = maddr >> PAGE_SHIFT;
> -	if (x && x--) {
> -            printk("Mapping dom%d mfn 0x%lx to dom%d mfn 0x%"PRIpaddr"\n",
> -                   od->domain_id, mfn, d->domain_id, xatp->gpfn);
> -        }

why remove the printk here?


>          rcu_unlock_domain(od);
>          break;
>      }
> +
>      default:
>          return -ENOSYS;
>      }
> @@ -532,19 +534,51 @@ static int xenmem_add_to_physmap_once(
>      domain_lock(d);
>  
>      /* Map at new location. */
> -    rc = guest_physmap_add_page(d, xatp->gpfn, mfn, 0);
> -    if ( 0 && xatp->space == XENMAPSPACE_gmfn_foreign )
> -        dump_p2m_lookup(d, xatp->gpfn << PAGE_SHIFT);
> +    rc = guest_physmap_add_page(d, gpfn, mfn, 0);
>  
>      domain_unlock(d);
>  
>      return rc;
>  }
>  
> -static int xenmem_add_to_physmap(struct domain *d,
> -                                 struct xen_add_to_physmap *xatp)
> +static int xenmem_add_to_physmap_range(struct domain *d,
> +                                       struct xen_add_to_physmap_range *xatpr)
>  {
> -    return xenmem_add_to_physmap_once(d, xatp);
> +    int rc;
> +
> +    /* Process entries in reverse order to allow continuations */
> +    while ( xatpr->size > 0 )
> +    {
> +        xen_ulong_t idx;
> +        xen_pfn_t gpfn;
> +
> +        rc = copy_from_guest_offset(&idx, xatpr->idxs, xatpr->size-1, 1);
> +        if ( rc < 0 )
> +            goto out;
> +
> +        rc = copy_from_guest_offset(&gpfn, xatpr->gpfns, xatpr->size-1, 1);
> +        if ( rc < 0 )
> +            goto out;
> +
> +        rc = xenmem_add_to_physmap_one(d, xatpr->space,
> +                                       xatpr->foreign_domid,
> +                                       idx, gpfn);
> +
> +        xatpr->size--;
> +
> +        /* Check for continuation if it's not the last interation */
> +        if ( xatpr->size > 0 && hypercall_preempt_check() )
> +        {
> +            rc = -EAGAIN;
> +            goto out;
> +        }
> +    }
> +
> +    rc = 0;
> +
> +out:
> +    return rc;
> +
>  }
>  
>  long arch_memory_op(int op, XEN_GUEST_HANDLE(void) arg)
> @@ -565,13 +599,41 @@ long arch_memory_op(int op, XEN_GUEST_HANDLE(void) arg)
>          if ( rc != 0 )
>              return rc;
>  
> -        rc = xenmem_add_to_physmap(d, &xatp);
> +        rc = xenmem_add_to_physmap_one(d, xatp.space,
> +                                       xatp.foreign_domid,
> +                                       xatp.idx, xatp.gpfn);
>  
>          rcu_unlock_domain(d);
>  
>          return rc;
>      }
>  
> +    case XENMEM_add_to_physmap_range:
> +    {
> +        struct xen_add_to_physmap_range xatpr;
> +        struct domain *d;
> +
> +        if ( copy_from_guest(&xatpr, arg, 1) )
> +            return -EFAULT;
> +
> +        rc = rcu_lock_target_domain_by_id(xatpr.domid, &d);
> +        if ( rc != 0 )
> +            return rc;
> +
> +        rc = xenmem_add_to_physmap_range(d, &xatpr);
> +
> +        rcu_unlock_domain(d);
> +
> +        if ( rc && copy_to_guest(arg, &xatpr, 1) )
> +            rc = -EFAULT;
> +
> +        if ( rc == -EAGAIN )
> +            rc = hypercall_create_continuation(
> +                __HYPERVISOR_memory_op, "ih", op, arg);
> +
> +        return rc;
> +    }
> +
>      default:
>          return -ENOSYS;
>      }
> diff --git a/xen/include/public/memory.h b/xen/include/public/memory.h
> index b2adfbe..1cc7a80 100644
> --- a/xen/include/public/memory.h
> +++ b/xen/include/public/memory.h
> @@ -198,6 +198,15 @@ struct xen_machphys_mapping {
>  typedef struct xen_machphys_mapping xen_machphys_mapping_t;
>  DEFINE_XEN_GUEST_HANDLE(xen_machphys_mapping_t);
>  
> +/* Source mapping space. */
> +/* ` enum phys_map_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 dom */
> +/* ` } */
>  /*
>   * Sets the GPFN at which a particular page appears in the specified guest's
>   * pseudophysical address space.
> @@ -211,26 +220,40 @@ struct xen_add_to_physmap {
>      /* Number of pages to go through for gmfn_range */
>      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 */
> -#define XENMAPSPACE_gmfn_foreign 4 /* GMFN from another guest */
> -    uint16_t space;
> +    uint16_t space; /* => enum phys_map_space */
>      domid_t foreign_domid; /* IFF gmfn_foreign */

I don't like very much that you have a uint16_t in the struct that
actually represents a union


>  #define XENMAPIDX_grant_table_status 0x80000000
>  
> -    /* Index into source mapping space. */
> +    /* Index into space being mapped. */
>      xen_ulong_t idx;
>  
> -    /* GPFN where the source mapping page should appear. */
> +    /* GPFN in domid where the source mapping page should appear. */
>      xen_pfn_t     gpfn;
>  };
>  typedef struct xen_add_to_physmap xen_add_to_physmap_t;
>  DEFINE_XEN_GUEST_HANDLE(xen_add_to_physmap_t);
>  
> +/* A batched version of add_to_physmap. */
> +#define XENMEM_add_to_physmap_range 23
> +struct xen_add_to_physmap_range {
> +    /* Which domain to change the mapping for. */
> +    domid_t domid;
> +    uint16_t space; /* => enum phys_map_space */
> +
> +    /* Number of pages to go through */
> +    uint16_t size;
> +    domid_t foreign_domid; /* IFF gmfn_foreign */
> +
> +    /* Indexes into space being mapped. */
> +    XEN_GUEST_HANDLE(xen_ulong_t) idxs;
> +
> +    /* GPFN in domdwhere the source mapping page should appear. */
                     ^ domid where

> +    XEN_GUEST_HANDLE(xen_pfn_t) gpfns;
> +};
> +typedef struct xen_add_to_physmap_range xen_add_to_physmap_range_t;
> +DEFINE_XEN_GUEST_HANDLE(xen_add_to_physmap_range_t);
> +
>  /*
>   * Unmaps the page appearing at a particular GPFN from the specified guest's
>   * pseudophysical address space.
> diff --git a/xen/include/public/xen.h b/xen/include/public/xen.h
> index b2f6c50..9425520 100644
> --- a/xen/include/public/xen.h
> +++ b/xen/include/public/xen.h
> @@ -51,6 +51,7 @@ DEFINE_XEN_GUEST_HANDLE(void);
>  
>  DEFINE_XEN_GUEST_HANDLE(uint64_t);
>  DEFINE_XEN_GUEST_HANDLE(xen_pfn_t);
> +DEFINE_XEN_GUEST_HANDLE(xen_ulong_t);
>  #endif

You shouldn't need that: xen_ulong_t is already defined in arch-arm.h
(and arch-x86/xen.h)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 19 13:21:54 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Sep 2012 13:21:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TEKDo-0006M5-7s; Wed, 19 Sep 2012 13:21:44 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1TEKDm-0006Lw-3t
	for xen-devel@lists.xensource.com; Wed, 19 Sep 2012 13:21:42 +0000
Received: from [85.158.138.51:5145] by server-6.bemta-3.messagelabs.com id
	C4/3D-29694-5E6C9505; Wed, 19 Sep 2012 13:21:41 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1348060900!31137999!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTAxNzU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23446 invoked from network); 19 Sep 2012 13:21:40 -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 Sep 2012 13:21:40 -0000
X-IronPort-AV: E=Sophos;i="4.80,447,1344211200"; d="scan'208";a="14631793"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Sep 2012 13:21: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.279.1; Wed, 19 Sep 2012 14:21:38 +0100
Date: Wed, 19 Sep 2012 14:20: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: <1348060180.14977.123.camel@zakaz.uk.xensource.com>
Message-ID: <alpine.DEB.2.02.1209191420290.29232@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1208221159560.15568@kaball.uk.xensource.com>
	<1345633688-31684-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<1347627587.24226.192.camel@zakaz.uk.xensource.com>
	<20120914160727.1ff41de2@mantra.us.oracle.com> 
	<alpine.DEB.2.02.1209171153350.29232@kaball.uk.xensource.com>
	<1348059789.14977.119.camel@zakaz.uk.xensource.com>
	<1348060180.14977.123.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 v4 1/6] xen: improve changes to
 xen_add_to_physmap
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 19 Sep 2012, Ian Campbell wrote:
> On Wed, 2012-09-19 at 14:03 +0100, Ian Campbell wrote:
> 
> > > It the final version. I think it should go in, unless we want to drop it
> > > entirely in favor of xen_add_to_physmap_range.
> > 
> > Here is what I came up with on the ARM side. I'd image the X86 version
> > would not be that different.
> 
> Here the (obvious) Linux side, for reference. No actual use of batching
> just yet. It's based on top of a somewhat bastardized version of
> Mukesh's PVH patches for privcmd.
> 

we also need the xen_remap_domain_mfn_range arm implementation

> 
> diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
> index 43277f8..f01120a 100644
> --- a/arch/arm/xen/enlighten.c
> +++ b/arch/arm/xen/enlighten.c
> @@ -88,13 +88,20 @@ static int pvh_add_to_xen_p2m(unsigned long lpfn, unsigned long fgmfn,
>  			      unsigned int domid)
>  {
>  	int rc;
> -	struct xen_add_to_physmap pmb = {.foreign_domid = domid};
> -
> -	pmb.gpfn = lpfn;
> -	pmb.idx = fgmfn;
> -	pmb.space = XENMAPSPACE_gmfn_foreign;
> -
> -	rc = HYPERVISOR_memory_op(XENMEM_add_to_physmap, &pmb);
> +	struct xen_add_to_physmap_range xatp = {
> +		.domid = DOMID_SELF,
> +		.foreign_domid = domid,
> +		.size = 1,
> +		.space = XENMAPSPACE_gmfn_foreign,
> +	};
> +	unsigned long idx = fgmfn;
> +	xen_pfn_t gpfn = lpfn;
> +
> +	set_xen_guest_handle(xatp.idxs, &idx);
> +	set_xen_guest_handle(xatp.gpfns, &gpfn);
> +		       domid, fgmfn, lpfn);
> +
> +	rc = HYPERVISOR_memory_op(XENMEM_add_to_physmap_range, &xatp);
>  	if (rc) {
>  		pr_warn("Failed to map pfn to mfn rc:%d pfn:%lx mfn:%lx\n",
>  			rc, lpfn, fgmfn);
> diff --git a/include/xen/interface/memory.h b/include/xen/interface/memory.h
> index 8728330..64cabbb 100644
> --- a/include/xen/interface/memory.h
> +++ b/include/xen/interface/memory.h
> @@ -183,6 +183,24 @@ struct xen_add_to_physmap {
>  };
>  DEFINE_GUEST_HANDLE_STRUCT(xen_add_to_physmap);
>  
> +#define XENMEM_add_to_physmap_range 23
> +struct xen_add_to_physmap_range {
> +    /* Which domain to change the mapping for. */
> +    domid_t domid;
> +    uint16_t space; /* => enum phys_map_space */
> +
> +    /* Number of pages to go through */
> +    uint16_t size;
> +    domid_t foreign_domid; /* IFF gmfn_foreign */
> +
> +    /* Indexes into space being mapped. */
> +    GUEST_HANDLE(ulong) idxs;
> +
> +    /* GPFN in domdwhere the source mapping page should appear. */
> +    GUEST_HANDLE(xen_pfn_t) gpfns;
> +};
> +DEFINE_GUEST_HANDLE_STRUCT(xen_add_to_physmap_range);
> +
>  /*
>   * Translates a list of domain-specific GPFNs into MFNs. Returns a -ve error
>   * code on failure. This call only works for auto-translated guests.
> 
> 
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 19 13:21:54 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Sep 2012 13:21:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TEKDo-0006M5-7s; Wed, 19 Sep 2012 13:21:44 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1TEKDm-0006Lw-3t
	for xen-devel@lists.xensource.com; Wed, 19 Sep 2012 13:21:42 +0000
Received: from [85.158.138.51:5145] by server-6.bemta-3.messagelabs.com id
	C4/3D-29694-5E6C9505; Wed, 19 Sep 2012 13:21:41 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1348060900!31137999!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTAxNzU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23446 invoked from network); 19 Sep 2012 13:21:40 -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 Sep 2012 13:21:40 -0000
X-IronPort-AV: E=Sophos;i="4.80,447,1344211200"; d="scan'208";a="14631793"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Sep 2012 13:21: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.279.1; Wed, 19 Sep 2012 14:21:38 +0100
Date: Wed, 19 Sep 2012 14:20: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: <1348060180.14977.123.camel@zakaz.uk.xensource.com>
Message-ID: <alpine.DEB.2.02.1209191420290.29232@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1208221159560.15568@kaball.uk.xensource.com>
	<1345633688-31684-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<1347627587.24226.192.camel@zakaz.uk.xensource.com>
	<20120914160727.1ff41de2@mantra.us.oracle.com> 
	<alpine.DEB.2.02.1209171153350.29232@kaball.uk.xensource.com>
	<1348059789.14977.119.camel@zakaz.uk.xensource.com>
	<1348060180.14977.123.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 v4 1/6] xen: improve changes to
 xen_add_to_physmap
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 19 Sep 2012, Ian Campbell wrote:
> On Wed, 2012-09-19 at 14:03 +0100, Ian Campbell wrote:
> 
> > > It the final version. I think it should go in, unless we want to drop it
> > > entirely in favor of xen_add_to_physmap_range.
> > 
> > Here is what I came up with on the ARM side. I'd image the X86 version
> > would not be that different.
> 
> Here the (obvious) Linux side, for reference. No actual use of batching
> just yet. It's based on top of a somewhat bastardized version of
> Mukesh's PVH patches for privcmd.
> 

we also need the xen_remap_domain_mfn_range arm implementation

> 
> diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
> index 43277f8..f01120a 100644
> --- a/arch/arm/xen/enlighten.c
> +++ b/arch/arm/xen/enlighten.c
> @@ -88,13 +88,20 @@ static int pvh_add_to_xen_p2m(unsigned long lpfn, unsigned long fgmfn,
>  			      unsigned int domid)
>  {
>  	int rc;
> -	struct xen_add_to_physmap pmb = {.foreign_domid = domid};
> -
> -	pmb.gpfn = lpfn;
> -	pmb.idx = fgmfn;
> -	pmb.space = XENMAPSPACE_gmfn_foreign;
> -
> -	rc = HYPERVISOR_memory_op(XENMEM_add_to_physmap, &pmb);
> +	struct xen_add_to_physmap_range xatp = {
> +		.domid = DOMID_SELF,
> +		.foreign_domid = domid,
> +		.size = 1,
> +		.space = XENMAPSPACE_gmfn_foreign,
> +	};
> +	unsigned long idx = fgmfn;
> +	xen_pfn_t gpfn = lpfn;
> +
> +	set_xen_guest_handle(xatp.idxs, &idx);
> +	set_xen_guest_handle(xatp.gpfns, &gpfn);
> +		       domid, fgmfn, lpfn);
> +
> +	rc = HYPERVISOR_memory_op(XENMEM_add_to_physmap_range, &xatp);
>  	if (rc) {
>  		pr_warn("Failed to map pfn to mfn rc:%d pfn:%lx mfn:%lx\n",
>  			rc, lpfn, fgmfn);
> diff --git a/include/xen/interface/memory.h b/include/xen/interface/memory.h
> index 8728330..64cabbb 100644
> --- a/include/xen/interface/memory.h
> +++ b/include/xen/interface/memory.h
> @@ -183,6 +183,24 @@ struct xen_add_to_physmap {
>  };
>  DEFINE_GUEST_HANDLE_STRUCT(xen_add_to_physmap);
>  
> +#define XENMEM_add_to_physmap_range 23
> +struct xen_add_to_physmap_range {
> +    /* Which domain to change the mapping for. */
> +    domid_t domid;
> +    uint16_t space; /* => enum phys_map_space */
> +
> +    /* Number of pages to go through */
> +    uint16_t size;
> +    domid_t foreign_domid; /* IFF gmfn_foreign */
> +
> +    /* Indexes into space being mapped. */
> +    GUEST_HANDLE(ulong) idxs;
> +
> +    /* GPFN in domdwhere the source mapping page should appear. */
> +    GUEST_HANDLE(xen_pfn_t) gpfns;
> +};
> +DEFINE_GUEST_HANDLE_STRUCT(xen_add_to_physmap_range);
> +
>  /*
>   * Translates a list of domain-specific GPFNs into MFNs. Returns a -ve error
>   * code on failure. This call only works for auto-translated guests.
> 
> 
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 19 13:39:44 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Sep 2012 13: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 1TEKUv-0006fh-T7; Wed, 19 Sep 2012 13:39:25 +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 1TEKUv-0006fc-B9
	for xen-devel@lists.xensource.com; Wed, 19 Sep 2012 13:39:25 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1348061927!4621357!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzUwOTQ4\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16683 invoked from network); 19 Sep 2012 13:38:49 -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; 19 Sep 2012 13:38:49 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q8JDciQc000610
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 19 Sep 2012 13:38:44 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
	q8JDchwj024169
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 19 Sep 2012 13:38:43 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
	q8JDchXC023306; Wed, 19 Sep 2012 08:38:43 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 19 Sep 2012 06:38:42 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id F3814402EC; Wed, 19 Sep 2012 09:27:51 -0400 (EDT)
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: linux-kernel@vger.kernel.org, xen-devel@lists.xensource.com
Date: Wed, 19 Sep 2012 09:27:49 -0400
Message-Id: <1348061269-19133-1-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.7.7.6
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: stable@kernel.org, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: [Xen-devel] [PATCH] xen/boot: Disable BIOS SMP MP table search.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

As the initial domain we are able to search/map certain regions
of memory to harvest configuration data. For all low-level we
use ACPI tables - for interrupts we use exclusively ACPI _PRT
(so DSDT) and MADT for INT_SRC_OVR.

The SMP MP table is not used at all. As a matter of fact we do
not even support machines that only have SMP MP but no ACPI tables.

Lets follow how Moorestown does it and just disable searching
for BIOS SMP tables.

This also fixes an issue on HP Proliant BL680c G5 and DL380 G6:

9f->100 for 1:1 PTE
Freeing 9f-100 pfn range: 97 pages freed
1-1 mapping on 9f->100
.. snip..
e820: BIOS-provided physical RAM map:
Xen: [mem 0x0000000000000000-0x000000000009efff] usable
Xen: [mem 0x000000000009f400-0x00000000000fffff] reserved
Xen: [mem 0x0000000000100000-0x00000000cfd1dfff] usable
.. snip..
Scan for SMP in [mem 0x00000000-0x000003ff]
Scan for SMP in [mem 0x0009fc00-0x0009ffff]
Scan for SMP in [mem 0x000f0000-0x000fffff]
found SMP MP-table at [mem 0x000f4fa0-0x000f4faf] mapped at [ffff8800000f4fa0]
(XEN) mm.c:908:d0 Error getting mfn 100 (pfn 5555555555555555) from L1 entry 0000000000100461 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4995:d0 ptwr_emulate: could not get_page_from_l1e()
BUG: unable to handle kernel NULL pointer dereference at           (null)
IP: [<ffffffff81ac07e2>] xen_set_pte_init+0x66/0x71
. snip..
Pid: 0, comm: swapper Not tainted 3.6.0-rc6upstream-00188-gb6fb969-dirty #2 HP ProLiant BL680c G5
.. snip..
Call Trace:
 [<ffffffff81ad31c6>] __early_ioremap+0x18a/0x248
 [<ffffffff81624731>] ? printk+0x48/0x4a
 [<ffffffff81ad32ac>] early_ioremap+0x13/0x15
 [<ffffffff81acc140>] get_mpc_size+0x2f/0x67
 [<ffffffff81acc284>] smp_scan_config+0x10c/0x136
 [<ffffffff81acc2e4>] default_find_smp_config+0x36/0x5a
 [<ffffffff81ac3085>] setup_arch+0x5b3/0xb5b
 [<ffffffff81624731>] ? printk+0x48/0x4a
 [<ffffffff81abca7f>] start_kernel+0x90/0x390
 [<ffffffff81abc356>] x86_64_start_reservations+0x131/0x136
 [<ffffffff81abfa83>] xen_start_kernel+0x65f/0x661
(XEN) Domain 0 crashed: 'noreboot' set - not rebooting.

which is that ioremap would end up mapping 0xff using _PAGE_IOMAP
(which is what early_ioremap sticks as a flag) - which meant
we would get MFN 0xFF (pte ff461, which is OK), and then it would
also map 0x100 (b/c ioremap tries to get page aligned request, and
it was trying to map 0xf4fa0 + PAGE_SIZE - so it mapped the next page)
as _PAGE_IOMAP. Since 0x100 is actually a RAM page, and the _PAGE_IOMAP
bypasses the P2M lookup we would happily set the PTE to 1000461.
Xen would deny the request since we do not have access to the
Machine Frame Number (MFN) of 0x100. The P2M[0x100] is for example
0x80140.

CC: stable@kernel.org
Fixes-Oracle-Bugzilla: https://bugzilla.oracle.com/bugzilla/show_bug.cgi?id=13665
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 arch/x86/xen/enlighten.c |    4 ++++
 1 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
index 9642d4a..1fbe75a 100644
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -1452,6 +1452,10 @@ asmlinkage void __init xen_start_kernel(void)
 		pci_request_acs();
 
 		xen_acpi_sleep_register();
+
+		/* Avoid searching for BIOS MP tables */
+		x86_init.mpparse.find_smp_config = x86_init_noop;
+		x86_init.mpparse.get_smp_config = x86_init_uint_noop;
 	}
 #ifdef CONFIG_PCI
 	/* PCI BIOS service won't work from a PV guest. */
-- 
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 Sep 19 13:39:44 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Sep 2012 13: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 1TEKUv-0006fh-T7; Wed, 19 Sep 2012 13:39:25 +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 1TEKUv-0006fc-B9
	for xen-devel@lists.xensource.com; Wed, 19 Sep 2012 13:39:25 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1348061927!4621357!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzUwOTQ4\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16683 invoked from network); 19 Sep 2012 13:38:49 -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; 19 Sep 2012 13:38:49 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q8JDciQc000610
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 19 Sep 2012 13:38:44 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
	q8JDchwj024169
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 19 Sep 2012 13:38:43 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
	q8JDchXC023306; Wed, 19 Sep 2012 08:38:43 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 19 Sep 2012 06:38:42 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id F3814402EC; Wed, 19 Sep 2012 09:27:51 -0400 (EDT)
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: linux-kernel@vger.kernel.org, xen-devel@lists.xensource.com
Date: Wed, 19 Sep 2012 09:27:49 -0400
Message-Id: <1348061269-19133-1-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.7.7.6
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: stable@kernel.org, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: [Xen-devel] [PATCH] xen/boot: Disable BIOS SMP MP table search.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

As the initial domain we are able to search/map certain regions
of memory to harvest configuration data. For all low-level we
use ACPI tables - for interrupts we use exclusively ACPI _PRT
(so DSDT) and MADT for INT_SRC_OVR.

The SMP MP table is not used at all. As a matter of fact we do
not even support machines that only have SMP MP but no ACPI tables.

Lets follow how Moorestown does it and just disable searching
for BIOS SMP tables.

This also fixes an issue on HP Proliant BL680c G5 and DL380 G6:

9f->100 for 1:1 PTE
Freeing 9f-100 pfn range: 97 pages freed
1-1 mapping on 9f->100
.. snip..
e820: BIOS-provided physical RAM map:
Xen: [mem 0x0000000000000000-0x000000000009efff] usable
Xen: [mem 0x000000000009f400-0x00000000000fffff] reserved
Xen: [mem 0x0000000000100000-0x00000000cfd1dfff] usable
.. snip..
Scan for SMP in [mem 0x00000000-0x000003ff]
Scan for SMP in [mem 0x0009fc00-0x0009ffff]
Scan for SMP in [mem 0x000f0000-0x000fffff]
found SMP MP-table at [mem 0x000f4fa0-0x000f4faf] mapped at [ffff8800000f4fa0]
(XEN) mm.c:908:d0 Error getting mfn 100 (pfn 5555555555555555) from L1 entry 0000000000100461 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4995:d0 ptwr_emulate: could not get_page_from_l1e()
BUG: unable to handle kernel NULL pointer dereference at           (null)
IP: [<ffffffff81ac07e2>] xen_set_pte_init+0x66/0x71
. snip..
Pid: 0, comm: swapper Not tainted 3.6.0-rc6upstream-00188-gb6fb969-dirty #2 HP ProLiant BL680c G5
.. snip..
Call Trace:
 [<ffffffff81ad31c6>] __early_ioremap+0x18a/0x248
 [<ffffffff81624731>] ? printk+0x48/0x4a
 [<ffffffff81ad32ac>] early_ioremap+0x13/0x15
 [<ffffffff81acc140>] get_mpc_size+0x2f/0x67
 [<ffffffff81acc284>] smp_scan_config+0x10c/0x136
 [<ffffffff81acc2e4>] default_find_smp_config+0x36/0x5a
 [<ffffffff81ac3085>] setup_arch+0x5b3/0xb5b
 [<ffffffff81624731>] ? printk+0x48/0x4a
 [<ffffffff81abca7f>] start_kernel+0x90/0x390
 [<ffffffff81abc356>] x86_64_start_reservations+0x131/0x136
 [<ffffffff81abfa83>] xen_start_kernel+0x65f/0x661
(XEN) Domain 0 crashed: 'noreboot' set - not rebooting.

which is that ioremap would end up mapping 0xff using _PAGE_IOMAP
(which is what early_ioremap sticks as a flag) - which meant
we would get MFN 0xFF (pte ff461, which is OK), and then it would
also map 0x100 (b/c ioremap tries to get page aligned request, and
it was trying to map 0xf4fa0 + PAGE_SIZE - so it mapped the next page)
as _PAGE_IOMAP. Since 0x100 is actually a RAM page, and the _PAGE_IOMAP
bypasses the P2M lookup we would happily set the PTE to 1000461.
Xen would deny the request since we do not have access to the
Machine Frame Number (MFN) of 0x100. The P2M[0x100] is for example
0x80140.

CC: stable@kernel.org
Fixes-Oracle-Bugzilla: https://bugzilla.oracle.com/bugzilla/show_bug.cgi?id=13665
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 arch/x86/xen/enlighten.c |    4 ++++
 1 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
index 9642d4a..1fbe75a 100644
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -1452,6 +1452,10 @@ asmlinkage void __init xen_start_kernel(void)
 		pci_request_acs();
 
 		xen_acpi_sleep_register();
+
+		/* Avoid searching for BIOS MP tables */
+		x86_init.mpparse.find_smp_config = x86_init_noop;
+		x86_init.mpparse.get_smp_config = x86_init_uint_noop;
 	}
 #ifdef CONFIG_PCI
 	/* PCI BIOS service won't work from a PV guest. */
-- 
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 Sep 19 13:51:28 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Sep 2012 13:51: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 1TEKgK-0006vk-9t; Wed, 19 Sep 2012 13:51:12 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1TEKgI-0006vf-H4
	for xen-devel@lists.xensource.com; Wed, 19 Sep 2012 13:51:10 +0000
Received: from [85.158.139.83:15600] by server-12.bemta-5.messagelabs.com id
	C3/20-22167-DCDC9505; Wed, 19 Sep 2012 13:51:09 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1348062669!30884954!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTAxNzU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14628 invoked from network); 19 Sep 2012 13:51: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;
	19 Sep 2012 13:51:09 -0000
X-IronPort-AV: E=Sophos;i="4.80,447,1344211200"; d="scan'208";a="14632527"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Sep 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.279.1;
	Wed, 19 Sep 2012 14:50:17 +0100
Message-ID: <1348062615.14977.127.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Date: Wed, 19 Sep 2012 14:50:15 +0100
In-Reply-To: <alpine.DEB.2.02.1209191420290.29232@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1208221159560.15568@kaball.uk.xensource.com>
	<1345633688-31684-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<1347627587.24226.192.camel@zakaz.uk.xensource.com>
	<20120914160727.1ff41de2@mantra.us.oracle.com>
	<alpine.DEB.2.02.1209171153350.29232@kaball.uk.xensource.com>
	<1348059789.14977.119.camel@zakaz.uk.xensource.com>
	<1348060180.14977.123.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.02.1209191420290.29232@kaball.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-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 v4 1/6] xen: improve changes to
 xen_add_to_physmap
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-09-19 at 14:20 +0100, Stefano Stabellini wrote:
> On Wed, 19 Sep 2012, Ian Campbell wrote:
> > On Wed, 2012-09-19 at 14:03 +0100, Ian Campbell wrote:
> > 
> > > > It the final version. I think it should go in, unless we want to drop it
> > > > entirely in favor of xen_add_to_physmap_range.
> > > 
> > > Here is what I came up with on the ARM side. I'd image the X86 version
> > > would not be that different.
> > 
> > Here the (obvious) Linux side, for reference. No actual use of batching
> > just yet. It's based on top of a somewhat bastardized version of
> > Mukesh's PVH patches for privcmd.
> > 
> 
> we also need the xen_remap_domain_mfn_range arm implementation

I have that, it calls this pvh_add_to_xen_p2m. I just didn't include it
here since I was just illustrating the change of the API.

I have a set of patches to reimplement the hacky foreign mapping stuff
on top of Mukesh's PVH privmd stuff, I'm just waiting for him to repost
so I can rebase and post.

> > 
> > diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
> > index 43277f8..f01120a 100644
> > --- a/arch/arm/xen/enlighten.c
> > +++ b/arch/arm/xen/enlighten.c
> > @@ -88,13 +88,20 @@ static int pvh_add_to_xen_p2m(unsigned long lpfn, unsigned long fgmfn,
> >  			      unsigned int domid)
> >  {
> >  	int rc;
> > -	struct xen_add_to_physmap pmb = {.foreign_domid = domid};
> > -
> > -	pmb.gpfn = lpfn;
> > -	pmb.idx = fgmfn;
> > -	pmb.space = XENMAPSPACE_gmfn_foreign;
> > -
> > -	rc = HYPERVISOR_memory_op(XENMEM_add_to_physmap, &pmb);
> > +	struct xen_add_to_physmap_range xatp = {
> > +		.domid = DOMID_SELF,
> > +		.foreign_domid = domid,
> > +		.size = 1,
> > +		.space = XENMAPSPACE_gmfn_foreign,
> > +	};
> > +	unsigned long idx = fgmfn;
> > +	xen_pfn_t gpfn = lpfn;
> > +
> > +	set_xen_guest_handle(xatp.idxs, &idx);
> > +	set_xen_guest_handle(xatp.gpfns, &gpfn);
> > +		       domid, fgmfn, lpfn);
> > +
> > +	rc = HYPERVISOR_memory_op(XENMEM_add_to_physmap_range, &xatp);
> >  	if (rc) {
> >  		pr_warn("Failed to map pfn to mfn rc:%d pfn:%lx mfn:%lx\n",
> >  			rc, lpfn, fgmfn);
> > diff --git a/include/xen/interface/memory.h b/include/xen/interface/memory.h
> > index 8728330..64cabbb 100644
> > --- a/include/xen/interface/memory.h
> > +++ b/include/xen/interface/memory.h
> > @@ -183,6 +183,24 @@ struct xen_add_to_physmap {
> >  };
> >  DEFINE_GUEST_HANDLE_STRUCT(xen_add_to_physmap);
> >  
> > +#define XENMEM_add_to_physmap_range 23
> > +struct xen_add_to_physmap_range {
> > +    /* Which domain to change the mapping for. */
> > +    domid_t domid;
> > +    uint16_t space; /* => enum phys_map_space */
> > +
> > +    /* Number of pages to go through */
> > +    uint16_t size;
> > +    domid_t foreign_domid; /* IFF gmfn_foreign */
> > +
> > +    /* Indexes into space being mapped. */
> > +    GUEST_HANDLE(ulong) idxs;
> > +
> > +    /* GPFN in domdwhere the source mapping page should appear. */
> > +    GUEST_HANDLE(xen_pfn_t) gpfns;
> > +};
> > +DEFINE_GUEST_HANDLE_STRUCT(xen_add_to_physmap_range);
> > +
> >  /*
> >   * Translates a list of domain-specific GPFNs into MFNs. Returns a -ve error
> >   * code on failure. This call only works for auto-translated guests.
> > 
> > 
> > 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 19 13:51:28 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Sep 2012 13:51: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 1TEKgK-0006vk-9t; Wed, 19 Sep 2012 13:51:12 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1TEKgI-0006vf-H4
	for xen-devel@lists.xensource.com; Wed, 19 Sep 2012 13:51:10 +0000
Received: from [85.158.139.83:15600] by server-12.bemta-5.messagelabs.com id
	C3/20-22167-DCDC9505; Wed, 19 Sep 2012 13:51:09 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1348062669!30884954!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTAxNzU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14628 invoked from network); 19 Sep 2012 13:51: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;
	19 Sep 2012 13:51:09 -0000
X-IronPort-AV: E=Sophos;i="4.80,447,1344211200"; d="scan'208";a="14632527"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Sep 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.279.1;
	Wed, 19 Sep 2012 14:50:17 +0100
Message-ID: <1348062615.14977.127.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Date: Wed, 19 Sep 2012 14:50:15 +0100
In-Reply-To: <alpine.DEB.2.02.1209191420290.29232@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1208221159560.15568@kaball.uk.xensource.com>
	<1345633688-31684-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<1347627587.24226.192.camel@zakaz.uk.xensource.com>
	<20120914160727.1ff41de2@mantra.us.oracle.com>
	<alpine.DEB.2.02.1209171153350.29232@kaball.uk.xensource.com>
	<1348059789.14977.119.camel@zakaz.uk.xensource.com>
	<1348060180.14977.123.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.02.1209191420290.29232@kaball.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-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 v4 1/6] xen: improve changes to
 xen_add_to_physmap
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-09-19 at 14:20 +0100, Stefano Stabellini wrote:
> On Wed, 19 Sep 2012, Ian Campbell wrote:
> > On Wed, 2012-09-19 at 14:03 +0100, Ian Campbell wrote:
> > 
> > > > It the final version. I think it should go in, unless we want to drop it
> > > > entirely in favor of xen_add_to_physmap_range.
> > > 
> > > Here is what I came up with on the ARM side. I'd image the X86 version
> > > would not be that different.
> > 
> > Here the (obvious) Linux side, for reference. No actual use of batching
> > just yet. It's based on top of a somewhat bastardized version of
> > Mukesh's PVH patches for privcmd.
> > 
> 
> we also need the xen_remap_domain_mfn_range arm implementation

I have that, it calls this pvh_add_to_xen_p2m. I just didn't include it
here since I was just illustrating the change of the API.

I have a set of patches to reimplement the hacky foreign mapping stuff
on top of Mukesh's PVH privmd stuff, I'm just waiting for him to repost
so I can rebase and post.

> > 
> > diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
> > index 43277f8..f01120a 100644
> > --- a/arch/arm/xen/enlighten.c
> > +++ b/arch/arm/xen/enlighten.c
> > @@ -88,13 +88,20 @@ static int pvh_add_to_xen_p2m(unsigned long lpfn, unsigned long fgmfn,
> >  			      unsigned int domid)
> >  {
> >  	int rc;
> > -	struct xen_add_to_physmap pmb = {.foreign_domid = domid};
> > -
> > -	pmb.gpfn = lpfn;
> > -	pmb.idx = fgmfn;
> > -	pmb.space = XENMAPSPACE_gmfn_foreign;
> > -
> > -	rc = HYPERVISOR_memory_op(XENMEM_add_to_physmap, &pmb);
> > +	struct xen_add_to_physmap_range xatp = {
> > +		.domid = DOMID_SELF,
> > +		.foreign_domid = domid,
> > +		.size = 1,
> > +		.space = XENMAPSPACE_gmfn_foreign,
> > +	};
> > +	unsigned long idx = fgmfn;
> > +	xen_pfn_t gpfn = lpfn;
> > +
> > +	set_xen_guest_handle(xatp.idxs, &idx);
> > +	set_xen_guest_handle(xatp.gpfns, &gpfn);
> > +		       domid, fgmfn, lpfn);
> > +
> > +	rc = HYPERVISOR_memory_op(XENMEM_add_to_physmap_range, &xatp);
> >  	if (rc) {
> >  		pr_warn("Failed to map pfn to mfn rc:%d pfn:%lx mfn:%lx\n",
> >  			rc, lpfn, fgmfn);
> > diff --git a/include/xen/interface/memory.h b/include/xen/interface/memory.h
> > index 8728330..64cabbb 100644
> > --- a/include/xen/interface/memory.h
> > +++ b/include/xen/interface/memory.h
> > @@ -183,6 +183,24 @@ struct xen_add_to_physmap {
> >  };
> >  DEFINE_GUEST_HANDLE_STRUCT(xen_add_to_physmap);
> >  
> > +#define XENMEM_add_to_physmap_range 23
> > +struct xen_add_to_physmap_range {
> > +    /* Which domain to change the mapping for. */
> > +    domid_t domid;
> > +    uint16_t space; /* => enum phys_map_space */
> > +
> > +    /* Number of pages to go through */
> > +    uint16_t size;
> > +    domid_t foreign_domid; /* IFF gmfn_foreign */
> > +
> > +    /* Indexes into space being mapped. */
> > +    GUEST_HANDLE(ulong) idxs;
> > +
> > +    /* GPFN in domdwhere the source mapping page should appear. */
> > +    GUEST_HANDLE(xen_pfn_t) gpfns;
> > +};
> > +DEFINE_GUEST_HANDLE_STRUCT(xen_add_to_physmap_range);
> > +
> >  /*
> >   * Translates a list of domain-specific GPFNs into MFNs. Returns a -ve error
> >   * code on failure. This call only works for auto-translated guests.
> > 
> > 
> > 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 19 13:51:55 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Sep 2012 13:51:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TEKgk-0006yc-NW; Wed, 19 Sep 2012 13:51:38 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wdauchy@gmail.com>) id 1TEKgi-0006yC-0s
	for xen-devel@lists.xensource.com; Wed, 19 Sep 2012 13:51:36 +0000
Received: from [85.158.139.83:21525] by server-4.bemta-5.messagelabs.com id
	CA/07-23042-7EDC9505; Wed, 19 Sep 2012 13:51:35 +0000
X-Env-Sender: wdauchy@gmail.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1348062690!30553096!1
X-Originating-IP: [209.85.160.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-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15824 invoked from network); 19 Sep 2012 13:51:31 -0000
Received: from mail-pb0-f43.google.com (HELO mail-pb0-f43.google.com)
	(209.85.160.43)
	by server-9.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Sep 2012 13:51:31 -0000
Received: by pbbrq2 with SMTP id rq2so3236675pbb.30
	for <xen-devel@lists.xensource.com>;
	Wed, 19 Sep 2012 06:51: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=/gaXM+QHJ3PcDpbtBbtbEE4MWL3sVhKDMOAwBACjVy8=;
	b=K2UQYjqGpOmiDiAfhFUTpO+j1N9mkcUCrFytS/ESGgl6TPuvaPe4l4+/tZVrp5HnFI
	bqpqcBGvFzntZJRmf0CKAc+h5QkjN69F+trQag18i1hr018XTKSt3BGxBKq8wipSKlZK
	AosHDGGg+hsSPtbi3prORy3AG/9cUNsH3EEyueb8c1i+JfxM7Bn5Hh3kPNvavdx1Cqmh
	iIAwPrSUHcIFlvDkiRgkgD8q//LyJ3oj3shiETVrFCL3cYsVwA4PCJEtQRLHsuIottb2
	0lUfd9z05rtkoxFhaHqRHnM5I+lke0J4asbLK+iRrsTOvi8LUyJKROe+ncqSECB7W71x
	ilEA==
Received: by 10.66.86.133 with SMTP id p5mr7053582paz.35.1348062689691; Wed,
	19 Sep 2012 06:51:29 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.68.135.42 with HTTP; Wed, 19 Sep 2012 06:51:08 -0700 (PDT)
In-Reply-To: <20120918133650.GC12053@phenom.dumpdata.com>
References: <CAJ75kXZm-BqWdL2O41XkSE1VCdd4ruW=+CqDmR1b3=701RnXmw@mail.gmail.com>
	<20120918133650.GC12053@phenom.dumpdata.com>
From: William Dauchy <wdauchy@gmail.com>
Date: Wed, 19 Sep 2012 15:51:08 +0200
Message-ID: <CAJ75kXabH_ZE2L_u8y2eD9H6W8AG1OKNv-GOM9uRK7CDtas5zQ@mail.gmail.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] Error getting mfn
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi Konrad,

Thank your for you reply.

On Tue, Sep 18, 2012 at 3:36 PM, Konrad Rzeszutek Wilk
<konrad.wilk@oracle.com> wrote:
> Since this is 32-bit, I wonder if you are hitting the CONFIG_NUMA issue...

yes I do have CONFIG_NUMA enabled

> but I think you reported it some time ago and did you try the fix?

Are you talking about:
http://lists.xen.org/archives/html/xen-devel/2012-05/msg02204.html
because I did validate the fix but for me it was a different issue.
I saw that the fix was not accepted though https://lkml.org/lkml/2012/5/31/417

Please note that this fix was also applied on top of my 3.4.7 kernel.

> That shouldn't be it - b/c the URL you mentioned is for the set of patches
> that are destined for v3.7.

yup thought it could be related. never mind.

> Please use 'sync_console loglvl=all dom0_max_vcpus=1 console=com1 com1=xxxxx' and on the Linux command line:
> 'console=hvc0 debug loglevel=8"

please find below the output with and without CONFIG_NUMA.

without CONFIG_NUMA:

(XEN) Xen version 4.1.3 (package@) (gcc version 4.4.5 (Debian 4.4.5-8)
) Mon Sep 17 15:01:52 UTC 2012
(XEN) Latest ChangeSet: Thu Aug 09 16:47:30 2012 +0100 23334:ce7195d2b80e
(XEN) Bootloader: COM32 Multiboot loader v0.2
(XEN) Command line: console=vga dom0_mem=1024M,max:1024M loglvl=info
guest_loglvl=info
(XEN) Video information:
(XEN)  VGA is text mode 80x25, font 8x16
(XEN)  VBE/DDC methods: none; EDID transfer time: 1 seconds
(XEN)  EDID info not retrieved because no DDC retrieval method detected
(XEN) Disc information:
(XEN)  Found 0 MBR signatures
(XEN)  Found 0 EDD information structures
(XEN) Xen-e820 RAM map:
(XEN)  0000000000000000 - 000000000009b400 (usable)
(XEN)  000000000009b400 - 00000000000a0000 (reserved)
(XEN)  00000000000e0000 - 0000000000100000 (reserved)
(XEN)  0000000000100000 - 00000000bf730000 (usable)
(XEN)  00000000bf730000 - 00000000bf73e000 (ACPI data)
(XEN)  00000000bf73e000 - 00000000bf7a0000 (ACPI NVS)
(XEN)  00000000bf7a0000 - 00000000bf7b0000 (reserved)
(XEN)  00000000bf7bc000 - 00000000c0000000 (reserved)
(XEN)  00000000e0000000 - 00000000f0000000 (reserved)
(XEN)  00000000fee00000 - 00000000fee01000 (reserved)
(XEN)  00000000ffa00000 - 0000000100000000 (reserved)
(XEN)  0000000100000000 - 0000000c40000000 (usable)
(XEN) ACPI: RSDP 000FA6F0, 0024 (r2 ACPIAM)
(XEN) ACPI: XSDT BF730100, 006C (r1 122311 XSDT1136 20111223 MSFT       97)
(XEN) ACPI: FACP BF730290, 00F4 (r4 122311 FACP1136 20111223 MSFT       97)
(XEN) ACPI: DSDT BF730540, 48F7 (r2  5442B 5442B166      166 INTL 20051117)
(XEN) ACPI: FACS BF73E000, 0040
(XEN) ACPI: APIC BF730390, 011E (r2 122311 APIC1136 20111223 MSFT       97)
(XEN) ACPI: SPCR BF7304B0, 0050 (r1 122311 SPCR1136 20111223 MSFT       97)
(XEN) ACPI: MCFG BF730500, 003C (r1 122311 OEMMCFG  20111223 MSFT       97)
(XEN) ACPI: OEMB BF73E040, 0082 (r1 122311 OEMB1136 20111223 MSFT       97)
(XEN) ACPI: SRAT BF73A540, 0250 (r2 122311 OEMSRAT         1 INTL        1)
(XEN) ACPI: HPET BF73A790, 0038 (r1 122311 OEMHPET  20111223 MSFT       97)
(XEN) ACPI: DMAR BF73E0D0, 00D8 (r1    AMI  OEMDMAR        1 MSFT       97)
(XEN) ACPI: SSDT BF7439A0, 0363 (r1 DpgPmm    CpuPm       12 INTL 20051117)
(XEN) System RAM: 49142MB (50322220kB)
(XEN) SRAT: PXM 0 -> APIC 0 -> Node 0
(XEN) SRAT: PXM 0 -> APIC 2 -> Node 0
(XEN) SRAT: PXM 0 -> APIC 4 -> Node 0
(XEN) SRAT: PXM 0 -> APIC 16 -> Node 0
(XEN) SRAT: PXM 0 -> APIC 18 -> Node 0
(XEN) SRAT: PXM 0 -> APIC 20 -> Node 0
(XEN) SRAT: PXM 0 -> APIC 1 -> Node 0
(XEN) SRAT: PXM 0 -> APIC 3 -> Node 0
(XEN) SRAT: PXM 0 -> APIC 5 -> Node 0
(XEN) SRAT: PXM 0 -> APIC 17 -> Node 0
(XEN) SRAT: PXM 0 -> APIC 19 -> Node 0
(XEN) SRAT: PXM 0 -> APIC 21 -> Node 0
(XEN) SRAT: PXM 1 -> APIC 32 -> Node 1
(XEN) SRAT: PXM 1 -> APIC 34 -> Node 1
(XEN) SRAT: PXM 1 -> APIC 36 -> Node 1
(XEN) SRAT: PXM 1 -> APIC 48 -> Node 1
(XEN) SRAT: PXM 1 -> APIC 50 -> Node 1
(XEN) SRAT: PXM 1 -> APIC 52 -> Node 1
(XEN) SRAT: PXM 1 -> APIC 33 -> Node 1
(XEN) SRAT: PXM 1 -> APIC 35 -> Node 1
(XEN) SRAT: PXM 1 -> APIC 37 -> Node 1
(XEN) SRAT: PXM 1 -> APIC 49 -> Node 1
(XEN) SRAT: PXM 1 -> APIC 51 -> Node 1
(XEN) SRAT: PXM 1 -> APIC 53 -> Node 1
(XEN) SRAT: Node 0 PXM 0 0-a0000
(XEN) SRAT: Node 0 PXM 0 100000-c0000000
(XEN) SRAT: Node 0 PXM 0 100000000-640000000
(XEN) SRAT: Node 1 PXM 1 640000000-c40000000
(XEN) Domain heap initialised DMA width 32 bits
(XEN) found SMP MP-table at 000ff780
(XEN) DMI present.
(XEN) Using APIC driver default
(XEN) ACPI: PM-Timer IO Port: 0x808
(XEN) ACPI: ACPI SLEEP INFO: pm1x_cnt[804,0], pm1x_evt[800,0]
(XEN) ACPI:                  wakeup_vec[bf73e00c], vec_size[20]
(XEN) ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled)
(XEN) Processor #0 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x02] lapic_id[0x02] enabled)
(XEN) Processor #2 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x03] lapic_id[0x04] enabled)
(XEN) Processor #4 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x04] lapic_id[0x10] enabled)
(XEN) Processor #16 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x05] lapic_id[0x12] enabled)
(XEN) Processor #18 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x06] lapic_id[0x14] enabled)
(XEN) Processor #20 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x07] lapic_id[0x20] enabled)
(XEN) Processor #32 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x08] lapic_id[0x22] enabled)
(XEN) Processor #34 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x09] lapic_id[0x24] enabled)
(XEN) Processor #36 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x0a] lapic_id[0x30] enabled)
(XEN) Processor #48 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x0b] lapic_id[0x32] enabled)
(XEN) Processor #50 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x0c] lapic_id[0x34] enabled)
(XEN) Processor #52 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x0d] lapic_id[0x01] enabled)
(XEN) Processor #1 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x0e] lapic_id[0x03] enabled)
(XEN) Processor #3 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x0f] lapic_id[0x05] enabled)
(XEN) Processor #5 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x10] lapic_id[0x11] enabled)
(XEN) Processor #17 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x11] lapic_id[0x13] enabled)
(XEN) Processor #19 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x12] lapic_id[0x15] enabled)
(XEN) Processor #21 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x13] lapic_id[0x21] enabled)
(XEN) Processor #33 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x14] lapic_id[0x23] enabled)
(XEN) Processor #35 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x15] lapic_id[0x25] enabled)
(XEN) Processor #37 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x16] lapic_id[0x31] enabled)
(XEN) Processor #49 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x17] lapic_id[0x33] enabled)
(XEN) Processor #51 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x18] lapic_id[0x35] enabled)
(XEN) Processor #53 6:12 APIC version 21
(XEN) ACPI: LAPIC_NMI (acpi_id[0xff] dfl dfl lint[0x1])
(XEN) Overriding APIC driver with bigsmp
(XEN) ACPI: IOAPIC (id[0x06] address[0xfec00000] gsi_base[0])
(XEN) IOAPIC[0]: apic_id 6, version 32, address 0xfec00000, GSI 0-23
(XEN) ACPI: IOAPIC (id[0x07] address[0xfec8a000] gsi_base[24])
(XEN) IOAPIC[1]: apic_id 7, version 32, address 0xfec8a000, GSI 24-47
(XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
(XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
(XEN) Enabling APIC mode:  Phys.  Using 2 I/O APICs
(XEN) ACPI: HPET id: 0x8086a301 base: 0xfed00000
(XEN) PCI: MCFG configuration 0: base e0000000 segment 0 buses 0 - 255
(XEN) PCI: MCFG area at e0000000 reserved in E820
(XEN) Table is not found!
(XEN) Using ACPI (MADT) for SMP configuration information
(XEN) IRQ limits: 48 GSI, 4576 MSI/MSI-X
(XEN) Using scheduler: SMP Credit Scheduler (credit)
(XEN) Detected 2266.823 MHz processor.
(XEN) Initing memory sharing.
(XEN) mce_intel.c:1162: MCA Capability: BCAST 1 SER 0 CMCI 1 firstbank
0 extended MCE MSR 0
(XEN) Intel machine check reporting enabled
(XEN) Intel VT-d supported page sizes: 4kB.
(XEN) Intel VT-d Snoop Control enabled.
(XEN) Intel VT-d Dom0 DMA Passthrough not enabled.
(XEN) Intel VT-d Queued Invalidation enabled.
(XEN) Intel VT-d Interrupt Remapping not enabled.
(XEN) Intel VT-d Shared EPT tables not enabled.
(XEN) I/O virtualisation enabled
(XEN)  - Dom0 mode: Relaxed
(XEN) Enabled directed EOI with ioapic_ack_old on!
(XEN) ENABLING IO-APIC IRQs
(XEN)  -> Using old ACK method
(XEN) ..TIMER: vector=0xF0 apic1=0 pin1=2 apic2=-1 pin2=-1
(XEN) Platform timer is 14.318MHz HPET
(XEN) Defaulting to alternative key handling; send 'A' to switch to normal mode.
(XEN) Allocated console ring of 128 KiB.
(XEN) VMX: Supported advanced features:
(XEN)  - APIC MMIO access virtualisation
(XEN)  - APIC TPR shadow
(XEN)  - Extended Page Tables (EPT)
(XEN)  - Virtual-Processor Identifiers (VPID)
(XEN)  - Virtual NMI
(XEN)  - MSR direct-access bitmap
(XEN)  - Unrestricted Guest
(XEN) HVM: ASIDs enabled.
(XEN) HVM: VMX enabled
(XEN) HVM: Hardware Assisted Paging (HAP) detected
(XEN) HVM: HAP page sizes: 4kB, 2MB, 1GB
(XEN) Brought up 24 CPUs
(XEN) ACPI sleep modes: S3
(XEN) mcheck_poll: Machine check polling timer started.
(XEN) *** LOADING DOMAIN 0 ***
(XEN)  Xen  kernel: 64-bit, lsb, compat32
(XEN)  Dom0 kernel: 32-bit, PAE, lsb, paddr 0x1000000 -> 0x17ce000
(XEN) PHYSICAL MEMORY ARRANGEMENT:
(XEN)  Dom0 alloc.:   0000000c20000000->0000000c22000000 (253212 pages
to be allocated)
(XEN)  Init. ramdisk: 0000000c3fd1c000->0000000c3ffff200
(XEN) VIRTUAL MEMORY ARRANGEMENT:
(XEN)  Loaded kernel: 00000000c1000000->00000000c17ce000
(XEN)  Init. ramdisk: 00000000c17ce000->00000000c1ab1200
(XEN)  Phys-Mach map: 00000000c1ab2000->00000000c1bb2000
(XEN)  Start info:    00000000c1bb2000->00000000c1bb24b4
(XEN)  Page tables:   00000000c1bb3000->00000000c1bc9000
(XEN)  Boot stack:    00000000c1bc9000->00000000c1bca000
(XEN)  TOTAL:         00000000c0000000->00000000c2000000
(XEN)  ENTRY ADDRESS: 00000000c14eb000
(XEN) Dom0 has maximum 24 VCPUs
(XEN) Scrubbing Free RAM:
..........................................................................................................................................................................................................................................................................................................................................................................................................................................................................................done.
(XEN) Xen trace buffers: disabled
(XEN) Std. Loglevel: Errors, warnings and info
(XEN) Guest Loglevel: Errors, warnings and info
(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) mm.c:908:d0 Error getting mfn 2009b (pfn 5555555555555555) from
L1 entry 000000002009b023 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn 2009c (pfn 5555555555555555) from
L1 entry 000000002009c023 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn 2009d (pfn 5555555555555555) from
L1 entry 000000002009d023 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn 2009e (pfn 5555555555555555) from
L1 entry 000000002009e023 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn 2009f (pfn 5555555555555555) from
L1 entry 000000002009f023 for l1e_owner=0, pg_owner=0
(XEN) ../physdev.c:171: dom0: wrong map_pirq type 3

with CONFIG_NUMA:

(XEN) Xen version 4.1.3 (package@) (gcc version 4.4.5 (Debian 4.4.5-8)
) Mon Sep 17 15:01:52 UTC 2012
(XEN) Latest ChangeSet: Thu Aug 09 16:47:30 2012 +0100 23334:ce7195d2b80e
(XEN) Bootloader: COM32 Multiboot loader v0.2
(XEN) Command line: console=vga dom0_mem=1024M,max:1024M loglvl=info
guest_loglvl=info
(XEN) Video information:
(XEN)  VGA is text mode 80x25, font 8x16
(XEN)  VBE/DDC methods: none; EDID transfer time: 1 seconds
(XEN)  EDID info not retrieved because no DDC retrieval method detected
(XEN) Disc information:
(XEN)  Found 0 MBR signatures
(XEN)  Found 0 EDD information structures
(XEN) Xen-e820 RAM map:
(XEN)  0000000000000000 - 000000000009b400 (usable)
(XEN)  000000000009b400 - 00000000000a0000 (reserved)
(XEN)  00000000000e0000 - 0000000000100000 (reserved)
(XEN)  0000000000100000 - 00000000bf730000 (usable)
(XEN)  00000000bf730000 - 00000000bf73e000 (ACPI data)
(XEN)  00000000bf73e000 - 00000000bf7a0000 (ACPI NVS)
(XEN)  00000000bf7a0000 - 00000000bf7b0000 (reserved)
(XEN)  00000000bf7bc000 - 00000000c0000000 (reserved)
(XEN)  00000000e0000000 - 00000000f0000000 (reserved)
(XEN)  00000000fee00000 - 00000000fee01000 (reserved)
(XEN)  00000000ffa00000 - 0000000100000000 (reserved)
(XEN)  0000000100000000 - 0000000c40000000 (usable)
(XEN) ACPI: RSDP 000FA6F0, 0024 (r2 ACPIAM)
(XEN) ACPI: XSDT BF730100, 006C (r1 122311 XSDT1136 20111223 MSFT       97)
(XEN) ACPI: FACP BF730290, 00F4 (r4 122311 FACP1136 20111223 MSFT       97)
(XEN) ACPI: DSDT BF730540, 48F7 (r2  5442B 5442B166      166 INTL 20051117)
(XEN) ACPI: FACS BF73E000, 0040
(XEN) ACPI: APIC BF730390, 011E (r2 122311 APIC1136 20111223 MSFT       97)
(XEN) ACPI: SPCR BF7304B0, 0050 (r1 122311 SPCR1136 20111223 MSFT       97)
(XEN) ACPI: MCFG BF730500, 003C (r1 122311 OEMMCFG  20111223 MSFT       97)
(XEN) ACPI: OEMB BF73E040, 0082 (r1 122311 OEMB1136 20111223 MSFT       97)
(XEN) ACPI: SRAT BF73A540, 0250 (r2 122311 OEMSRAT         1 INTL        1)
(XEN) ACPI: HPET BF73A790, 0038 (r1 122311 OEMHPET  20111223 MSFT       97)
(XEN) ACPI: DMAR BF73E0D0, 00D8 (r1    AMI  OEMDMAR        1 MSFT       97)
(XEN) ACPI: SSDT BF7439A0, 0363 (r1 DpgPmm    CpuPm       12 INTL 20051117)
(XEN) System RAM: 49142MB (50322220kB)
(XEN) SRAT: PXM 0 -> APIC 0 -> Node 0
(XEN) SRAT: PXM 0 -> APIC 2 -> Node 0
(XEN) SRAT: PXM 0 -> APIC 4 -> Node 0
(XEN) SRAT: PXM 0 -> APIC 16 -> Node 0
(XEN) SRAT: PXM 0 -> APIC 18 -> Node 0
(XEN) SRAT: PXM 0 -> APIC 20 -> Node 0
(XEN) SRAT: PXM 0 -> APIC 1 -> Node 0
(XEN) SRAT: PXM 0 -> APIC 3 -> Node 0
(XEN) SRAT: PXM 0 -> APIC 5 -> Node 0
(XEN) SRAT: PXM 0 -> APIC 17 -> Node 0
(XEN) SRAT: PXM 0 -> APIC 19 -> Node 0
(XEN) SRAT: PXM 0 -> APIC 21 -> Node 0
(XEN) SRAT: PXM 1 -> APIC 32 -> Node 1
(XEN) SRAT: PXM 1 -> APIC 34 -> Node 1
(XEN) SRAT: PXM 1 -> APIC 36 -> Node 1
(XEN) SRAT: PXM 1 -> APIC 48 -> Node 1
(XEN) SRAT: PXM 1 -> APIC 50 -> Node 1
(XEN) SRAT: PXM 1 -> APIC 52 -> Node 1
(XEN) SRAT: PXM 1 -> APIC 33 -> Node 1
(XEN) SRAT: PXM 1 -> APIC 35 -> Node 1
(XEN) SRAT: PXM 1 -> APIC 37 -> Node 1
(XEN) SRAT: PXM 1 -> APIC 49 -> Node 1
(XEN) SRAT: PXM 1 -> APIC 51 -> Node 1
(XEN) SRAT: PXM 1 -> APIC 53 -> Node 1
(XEN) SRAT: Node 0 PXM 0 0-a0000
(XEN) SRAT: Node 0 PXM 0 100000-c0000000
(XEN) SRAT: Node 0 PXM 0 100000000-640000000
(XEN) SRAT: Node 1 PXM 1 640000000-c40000000
(XEN) Domain heap initialised DMA width 32 bits
(XEN) found SMP MP-table at 000ff780
(XEN) DMI present.
(XEN) Using APIC driver default
(XEN) ACPI: PM-Timer IO Port: 0x808
(XEN) ACPI: ACPI SLEEP INFO: pm1x_cnt[804,0], pm1x_evt[800,0]
(XEN) ACPI:                  wakeup_vec[bf73e00c], vec_size[20]
(XEN) ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled)
(XEN) Processor #0 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x02] lapic_id[0x02] enabled)
(XEN) Processor #2 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x03] lapic_id[0x04] enabled)
(XEN) Processor #4 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x04] lapic_id[0x10] enabled)
(XEN) Processor #16 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x05] lapic_id[0x12] enabled)
(XEN) Processor #18 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x06] lapic_id[0x14] enabled)
(XEN) Processor #20 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x07] lapic_id[0x20] enabled)
(XEN) Processor #32 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x08] lapic_id[0x22] enabled)
(XEN) Processor #34 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x09] lapic_id[0x24] enabled)
(XEN) Processor #36 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x0a] lapic_id[0x30] enabled)
(XEN) Processor #48 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x0b] lapic_id[0x32] enabled)
(XEN) Processor #50 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x0c] lapic_id[0x34] enabled)
(XEN) Processor #52 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x0d] lapic_id[0x01] enabled)
(XEN) Processor #1 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x0e] lapic_id[0x03] enabled)
(XEN) Processor #3 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x0f] lapic_id[0x05] enabled)
(XEN) Processor #5 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x10] lapic_id[0x11] enabled)
(XEN) Processor #17 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x11] lapic_id[0x13] enabled)
(XEN) Processor #19 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x12] lapic_id[0x15] enabled)
(XEN) Processor #21 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x13] lapic_id[0x21] enabled)
(XEN) Processor #33 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x14] lapic_id[0x23] enabled)
(XEN) Processor #35 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x15] lapic_id[0x25] enabled)
(XEN) Processor #37 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x16] lapic_id[0x31] enabled)
(XEN) Processor #49 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x17] lapic_id[0x33] enabled)
(XEN) Processor #51 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x18] lapic_id[0x35] enabled)
(XEN) Processor #53 6:12 APIC version 21
(XEN) ACPI: LAPIC_NMI (acpi_id[0xff] dfl dfl lint[0x1])
(XEN) Overriding APIC driver with bigsmp
(XEN) ACPI: IOAPIC (id[0x06] address[0xfec00000] gsi_base[0])
(XEN) IOAPIC[0]: apic_id 6, version 32, address 0xfec00000, GSI 0-23
(XEN) ACPI: IOAPIC (id[0x07] address[0xfec8a000] gsi_base[24])
(XEN) IOAPIC[1]: apic_id 7, version 32, address 0xfec8a000, GSI 24-47
(XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
(XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
(XEN) Enabling APIC mode:  Phys.  Using 2 I/O APICs
(XEN) ACPI: HPET id: 0x8086a301 base: 0xfed00000
(XEN) PCI: MCFG configuration 0: base e0000000 segment 0 buses 0 - 255
(XEN) PCI: MCFG area at e0000000 reserved in E820
(XEN) Table is not found!
(XEN) Using ACPI (MADT) for SMP configuration information
(XEN) IRQ limits: 48 GSI, 4576 MSI/MSI-X
(XEN) Using scheduler: SMP Credit Scheduler (credit)
(XEN) Detected 2266.804 MHz processor.
(XEN) Initing memory sharing.
(XEN) mce_intel.c:1162: MCA Capability: BCAST 1 SER 0 CMCI 1 firstbank
0 extended MCE MSR 0
(XEN) Intel machine check reporting enabled
(XEN) Intel VT-d supported page sizes: 4kB.
(XEN) Intel VT-d Snoop Control enabled.
(XEN) Intel VT-d Dom0 DMA Passthrough not enabled.
(XEN) Intel VT-d Queued Invalidation enabled.
(XEN) Intel VT-d Interrupt Remapping not enabled.
(XEN) Intel VT-d Shared EPT tables not enabled.
(XEN) I/O virtualisation enabled
(XEN)  - Dom0 mode: Relaxed
(XEN) Enabled directed EOI with ioapic_ack_old on!
(XEN) ENABLING IO-APIC IRQs
(XEN)  -> Using old ACK method
(XEN) ..TIMER: vector=0xF0 apic1=0 pin1=2 apic2=-1 pin2=-1
(XEN) Platform timer is 14.318MHz HPET
(XEN) Defaulting to alternative key handling; send 'A' to switch to normal mode.
(XEN) Allocated console ring of 128 KiB.
(XEN) VMX: Supported advanced features:
(XEN)  - APIC MMIO access virtualisation
(XEN)  - APIC TPR shadow
(XEN)  - Extended Page Tables (EPT)
(XEN)  - Virtual-Processor Identifiers (VPID)
(XEN)  - Virtual NMI
(XEN)  - MSR direct-access bitmap
(XEN)  - Unrestricted Guest
(XEN) HVM: ASIDs enabled.
(XEN) HVM: VMX enabled
(XEN) HVM: Hardware Assisted Paging (HAP) detected
(XEN) HVM: HAP page sizes: 4kB, 2MB, 1GB
(XEN) Brought up 24 CPUs
(XEN) ACPI sleep modes: S3
(XEN) mcheck_poll: Machine check polling timer started.
(XEN) *** LOADING DOMAIN 0 ***
(XEN)  Xen  kernel: 64-bit, lsb, compat32
(XEN)  Dom0 kernel: 32-bit, PAE, lsb, paddr 0x1000000 -> 0x17dc000
(XEN) PHYSICAL MEMORY ARRANGEMENT:
(XEN)  Dom0 alloc.:   0000000c20000000->0000000c22000000 (253212 pages
to be allocated)
(XEN)  Init. ramdisk: 0000000c3fd1c000->0000000c3ffff200
(XEN) VIRTUAL MEMORY ARRANGEMENT:
(XEN)  Loaded kernel: 00000000c1000000->00000000c17dc000
(XEN)  Init. ramdisk: 00000000c17dc000->00000000c1abf200
(XEN)  Phys-Mach map: 00000000c1ac0000->00000000c1bc0000
(XEN)  Start info:    00000000c1bc0000->00000000c1bc04b4
(XEN)  Page tables:   00000000c1bc1000->00000000c1bd7000
(XEN)  Boot stack:    00000000c1bd7000->00000000c1bd8000
(XEN)  TOTAL:         00000000c0000000->00000000c2000000
(XEN)  ENTRY ADDRESS: 00000000c14f5000
(XEN) Dom0 has maximum 24 VCPUs
(XEN) Scrubbing Free RAM:
..........................................................................................................................................................................................................................................................................................................................................................................................................................................................................................done.
(XEN) Xen trace buffers: disabled
(XEN) Std. Loglevel: Errors, warnings and info
(XEN) Guest Loglevel: Errors, warnings and info
(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) mm.c:908:d0 Error getting mfn 2009b (pfn 5555555555555555) from
L1 entry 000000002009b023 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn 2009c (pfn 5555555555555555) from
L1 entry 000000002009c023 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn 2009d (pfn 5555555555555555) from
L1 entry 000000002009d023 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn 2009e (pfn 5555555555555555) from
L1 entry 000000002009e023 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn 2009f (pfn 5555555555555555) from
L1 entry 000000002009f023 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32000 (pfn 5555555555555555) from
L1 entry 8000000c32000063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32001 (pfn 5555555555555555) from
L1 entry 8000000c32001063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32002 (pfn 5555555555555555) from
L1 entry 8000000c32002063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32003 (pfn 5555555555555555) from
L1 entry 8000000c32003063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32004 (pfn 5555555555555555) from
L1 entry 8000000c32004063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32005 (pfn 5555555555555555) from
L1 entry 8000000c32005063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32006 (pfn 5555555555555555) from
L1 entry 8000000c32006063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32007 (pfn 5555555555555555) from
L1 entry 8000000c32007063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32008 (pfn 5555555555555555) from
L1 entry 8000000c32008063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32009 (pfn 5555555555555555) from
L1 entry 8000000c32009063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c3200a (pfn 5555555555555555) from
L1 entry 8000000c3200a063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c3200b (pfn 5555555555555555) from
L1 entry 8000000c3200b063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c3200c (pfn 5555555555555555) from
L1 entry 8000000c3200c063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c3200d (pfn 5555555555555555) from
L1 entry 8000000c3200d063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c3200e (pfn 5555555555555555) from
L1 entry 8000000c3200e063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c3200f (pfn 5555555555555555) from
L1 entry 8000000c3200f063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32010 (pfn 5555555555555555) from
L1 entry 8000000c32010063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32011 (pfn 5555555555555555) from
L1 entry 8000000c32011063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32012 (pfn 5555555555555555) from
L1 entry 8000000c32012063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32013 (pfn 5555555555555555) from
L1 entry 8000000c32013063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32014 (pfn 5555555555555555) from
L1 entry 8000000c32014063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32015 (pfn 5555555555555555) from
L1 entry 8000000c32015063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32016 (pfn 5555555555555555) from
L1 entry 8000000c32016063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32017 (pfn 5555555555555555) from
L1 entry 8000000c32017063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32018 (pfn 5555555555555555) from
L1 entry 8000000c32018063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32019 (pfn 5555555555555555) from
L1 entry 8000000c32019063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c3201a (pfn 5555555555555555) from
L1 entry 8000000c3201a063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c3201b (pfn 5555555555555555) from
L1 entry 8000000c3201b063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c3201c (pfn 5555555555555555) from
L1 entry 8000000c3201c063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c3201d (pfn 5555555555555555) from
L1 entry 8000000c3201d063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c3201e (pfn 5555555555555555) from
L1 entry 8000000c3201e063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c3201f (pfn 5555555555555555) from
L1 entry 8000000c3201f063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32020 (pfn 5555555555555555) from
L1 entry 8000000c32020063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32021 (pfn 5555555555555555) from
L1 entry 8000000c32021063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32022 (pfn 5555555555555555) from
L1 entry 8000000c32022063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32023 (pfn 5555555555555555) from
L1 entry 8000000c32023063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32024 (pfn 5555555555555555) from
L1 entry 8000000c32024063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32025 (pfn 5555555555555555) from
L1 entry 8000000c32025063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32026 (pfn 5555555555555555) from
L1 entry 8000000c32026063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32027 (pfn 5555555555555555) from
L1 entry 8000000c32027063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32028 (pfn 5555555555555555) from
L1 entry 8000000c32028063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32029 (pfn 5555555555555555) from
L1 entry 8000000c32029063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c3202a (pfn 5555555555555555) from
L1 entry 8000000c3202a063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c3202b (pfn 5555555555555555) from
L1 entry 8000000c3202b063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c3202c (pfn 5555555555555555) from
L1 entry 8000000c3202c063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c3202d (pfn 5555555555555555) from
L1 entry 8000000c3202d063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c3202e (pfn 5555555555555555) from
L1 entry 8000000c3202e063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c3202f (pfn 5555555555555555) from
L1 entry 8000000c3202f063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32030 (pfn 5555555555555555) from
L1 entry 8000000c32030063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32031 (pfn 5555555555555555) from
L1 entry 8000000c32031063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32032 (pfn 5555555555555555) from
L1 entry 8000000c32032063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32033 (pfn 5555555555555555) from
L1 entry 8000000c32033063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32034 (pfn 5555555555555555) from
L1 entry 8000000c32034063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32035 (pfn 5555555555555555) from
L1 entry 8000000c32035063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32036 (pfn 5555555555555555) from
L1 entry 8000000c32036063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32037 (pfn 5555555555555555) from
L1 entry 8000000c32037063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32038 (pfn 5555555555555555) from
L1 entry 8000000c32038063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32039 (pfn 5555555555555555) from
L1 entry 8000000c32039063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c3203a (pfn 5555555555555555) from
L1 entry 8000000c3203a063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c3203b (pfn 5555555555555555) from
L1 entry 8000000c3203b063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c3203c (pfn 5555555555555555) from
L1 entry 8000000c3203c063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c3203d (pfn 5555555555555555) from
L1 entry 8000000c3203d063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c3203e (pfn 5555555555555555) from
L1 entry 8000000c3203e063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c3203f (pfn 5555555555555555) from
L1 entry 8000000c3203f063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32040 (pfn 5555555555555555) from
L1 entry 8000000c32040063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32041 (pfn 5555555555555555) from
L1 entry 8000000c32041063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32042 (pfn 5555555555555555) from
L1 entry 8000000c32042063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32043 (pfn 5555555555555555) from
L1 entry 8000000c32043063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32044 (pfn 5555555555555555) from
L1 entry 8000000c32044063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32045 (pfn 5555555555555555) from
L1 entry 8000000c32045063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32046 (pfn 5555555555555555) from
L1 entry 8000000c32046063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32047 (pfn 5555555555555555) from
L1 entry 8000000c32047063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32048 (pfn 5555555555555555) from
L1 entry 8000000c32048063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32049 (pfn 5555555555555555) from
L1 entry 8000000c32049063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c3204a (pfn 5555555555555555) from
L1 entry 8000000c3204a063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c3204b (pfn 5555555555555555) from
L1 entry 8000000c3204b063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c3204c (pfn 5555555555555555) from
L1 entry 8000000c3204c063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c3204d (pfn 5555555555555555) from
L1 entry 8000000c3204d063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c3204e (pfn 5555555555555555) from
L1 entry 8000000c3204e063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c3204f (pfn 5555555555555555) from
L1 entry 8000000c3204f063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32050 (pfn 5555555555555555) from
L1 entry 8000000c32050063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32051 (pfn 5555555555555555) from
L1 entry 8000000c32051063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32052 (pfn 5555555555555555) from
L1 entry 8000000c32052063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32053 (pfn 5555555555555555) from
L1 entry 8000000c32053063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32054 (pfn 5555555555555555) from
L1 entry 8000000c32054063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32055 (pfn 5555555555555555) from
L1 entry 8000000c32055063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32056 (pfn 5555555555555555) from
L1 entry 8000000c32056063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32057 (pfn 5555555555555555) from
L1 entry 8000000c32057063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32058 (pfn 5555555555555555) from
L1 entry 8000000c32058063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32059 (pfn 5555555555555555) from
L1 entry 8000000c32059063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c3205a (pfn 5555555555555555) from
L1 entry 8000000c3205a063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c3205b (pfn 5555555555555555) from
L1 entry 8000000c3205b063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c3205c (pfn 5555555555555555) from
L1 entry 8000000c3205c063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c3205d (pfn 5555555555555555) from
L1 entry 8000000c3205d063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c3205e (pfn 5555555555555555) from
L1 entry 8000000c3205e063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c3205f (pfn 5555555555555555) from
L1 entry 8000000c3205f063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32060 (pfn 5555555555555555) from
L1 entry 8000000c32060063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32061 (pfn 5555555555555555) from
L1 entry 8000000c32061063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32062 (pfn 5555555555555555) from
L1 entry 8000000c32062063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32063 (pfn 5555555555555555) from
L1 entry 8000000c32063063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32064 (pfn 5555555555555555) from
L1 entry 8000000c32064063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32065 (pfn 5555555555555555) from
L1 entry 8000000c32065063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32066 (pfn 5555555555555555) from
L1 entry 8000000c32066063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32067 (pfn 5555555555555555) from
L1 entry 8000000c32067063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32068 (pfn 5555555555555555) from
L1 entry 8000000c32068063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32069 (pfn 5555555555555555) from
L1 entry 8000000c32069063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c3206a (pfn 5555555555555555) from
L1 entry 8000000c3206a063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c3206b (pfn 5555555555555555) from
L1 entry 8000000c3206b063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c3206c (pfn 5555555555555555) from
L1 entry 8000000c3206c063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c3206d (pfn 5555555555555555) from
L1 entry 8000000c3206d063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c3206e (pfn 5555555555555555) from
L1 entry 8000000c3206e063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c3206f (pfn 5555555555555555) from
L1 entry 8000000c3206f063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32070 (pfn 5555555555555555) from
L1 entry 8000000c32070063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32071 (pfn 5555555555555555) from
L1 entry 8000000c32071063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32072 (pfn 5555555555555555) from
L1 entry 8000000c32072063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32073 (pfn 5555555555555555) from
L1 entry 8000000c32073063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32074 (pfn 5555555555555555) from
L1 entry 8000000c32074063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32075 (pfn 5555555555555555) from
L1 entry 8000000c32075063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32076 (pfn 5555555555555555) from
L1 entry 8000000c32076063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32077 (pfn 5555555555555555) from
L1 entry 8000000c32077063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32078 (pfn 5555555555555555) from
L1 entry 8000000c32078063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32079 (pfn 5555555555555555) from
L1 entry 8000000c32079063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c3207a (pfn 5555555555555555) from
L1 entry 8000000c3207a063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c3207b (pfn 5555555555555555) from
L1 entry 8000000c3207b063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c3207c (pfn 5555555555555555) from
L1 entry 8000000c3207c063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c3207d (pfn 5555555555555555) from
L1 entry 8000000c3207d063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c3207e (pfn 5555555555555555) from
L1 entry 8000000c3207e063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c3207f (pfn 5555555555555555) from
L1 entry 8000000c3207f063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32080 (pfn 5555555555555555) from
L1 entry 8000000c32080063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32081 (pfn 5555555555555555) from
L1 entry 8000000c32081063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32082 (pfn 5555555555555555) from
L1 entry 8000000c32082063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32083 (pfn 5555555555555555) from
L1 entry 8000000c32083063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32084 (pfn 5555555555555555) from
L1 entry 8000000c32084063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32085 (pfn 5555555555555555) from
L1 entry 8000000c32085063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32086 (pfn 5555555555555555) from
L1 entry 8000000c32086063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32087 (pfn 5555555555555555) from
L1 entry 8000000c32087063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32088 (pfn 5555555555555555) from
L1 entry 8000000c32088063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32089 (pfn 5555555555555555) from
L1 entry 8000000c32089063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c3208a (pfn 5555555555555555) from
L1 entry 8000000c3208a063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c3208b (pfn 5555555555555555) from
L1 entry 8000000c3208b063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c3208c (pfn 5555555555555555) from
L1 entry 8000000c3208c063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c3208d (pfn 5555555555555555) from
L1 entry 8000000c3208d063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c3208e (pfn 5555555555555555) from
L1 entry 8000000c3208e063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c3208f (pfn 5555555555555555) from
L1 entry 8000000c3208f063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32090 (pfn 5555555555555555) from
L1 entry 8000000c32090063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32091 (pfn 5555555555555555) from
L1 entry 8000000c32091063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32092 (pfn 5555555555555555) from
L1 entry 8000000c32092063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32093 (pfn 5555555555555555) from
L1 entry 8000000c32093063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32094 (pfn 5555555555555555) from
L1 entry 8000000c32094063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32095 (pfn 5555555555555555) from
L1 entry 8000000c32095063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32096 (pfn 5555555555555555) from
L1 entry 8000000c32096063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32097 (pfn 5555555555555555) from
L1 entry 8000000c32097063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32098 (pfn 5555555555555555) from
L1 entry 8000000c32098063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32099 (pfn 5555555555555555) from
L1 entry 8000000c32099063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c3209a (pfn 5555555555555555) from
L1 entry 8000000c3209a063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c3209b (pfn 5555555555555555) from
L1 entry 8000000c3209b063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c3209c (pfn 5555555555555555) from
L1 entry 8000000c3209c063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c3209d (pfn 5555555555555555) from
L1 entry 8000000c3209d063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c3209e (pfn 5555555555555555) from
L1 entry 8000000c3209e063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c3209f (pfn 5555555555555555) from
L1 entry 8000000c3209f063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320a0 (pfn 5555555555555555) from
L1 entry 8000000c320a0063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320a1 (pfn 5555555555555555) from
L1 entry 8000000c320a1063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320a2 (pfn 5555555555555555) from
L1 entry 8000000c320a2063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320a3 (pfn 5555555555555555) from
L1 entry 8000000c320a3063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320a4 (pfn 5555555555555555) from
L1 entry 8000000c320a4063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320a5 (pfn 5555555555555555) from
L1 entry 8000000c320a5063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320a6 (pfn 5555555555555555) from
L1 entry 8000000c320a6063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320a7 (pfn 5555555555555555) from
L1 entry 8000000c320a7063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320a8 (pfn 5555555555555555) from
L1 entry 8000000c320a8063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320a9 (pfn 5555555555555555) from
L1 entry 8000000c320a9063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320aa (pfn 5555555555555555) from
L1 entry 8000000c320aa063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320ab (pfn 5555555555555555) from
L1 entry 8000000c320ab063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320ac (pfn 5555555555555555) from
L1 entry 8000000c320ac063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320ad (pfn 5555555555555555) from
L1 entry 8000000c320ad063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320ae (pfn 5555555555555555) from
L1 entry 8000000c320ae063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320af (pfn 5555555555555555) from
L1 entry 8000000c320af063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320b0 (pfn 5555555555555555) from
L1 entry 8000000c320b0063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320b1 (pfn 5555555555555555) from
L1 entry 8000000c320b1063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320b2 (pfn 5555555555555555) from
L1 entry 8000000c320b2063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320b3 (pfn 5555555555555555) from
L1 entry 8000000c320b3063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320b4 (pfn 5555555555555555) from
L1 entry 8000000c320b4063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320b5 (pfn 5555555555555555) from
L1 entry 8000000c320b5063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320b6 (pfn 5555555555555555) from
L1 entry 8000000c320b6063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320b7 (pfn 5555555555555555) from
L1 entry 8000000c320b7063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320b8 (pfn 5555555555555555) from
L1 entry 8000000c320b8063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320b9 (pfn 5555555555555555) from
L1 entry 8000000c320b9063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320ba (pfn 5555555555555555) from
L1 entry 8000000c320ba063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320bb (pfn 5555555555555555) from
L1 entry 8000000c320bb063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320bc (pfn 5555555555555555) from
L1 entry 8000000c320bc063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320bd (pfn 5555555555555555) from
L1 entry 8000000c320bd063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320be (pfn 5555555555555555) from
L1 entry 8000000c320be063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320bf (pfn 5555555555555555) from
L1 entry 8000000c320bf063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320c0 (pfn 5555555555555555) from
L1 entry 8000000c320c0063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320c1 (pfn 5555555555555555) from
L1 entry 8000000c320c1063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320c2 (pfn 5555555555555555) from
L1 entry 8000000c320c2063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320c3 (pfn 5555555555555555) from
L1 entry 8000000c320c3063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320c4 (pfn 5555555555555555) from
L1 entry 8000000c320c4063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320c5 (pfn 5555555555555555) from
L1 entry 8000000c320c5063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320c6 (pfn 5555555555555555) from
L1 entry 8000000c320c6063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320c7 (pfn 5555555555555555) from
L1 entry 8000000c320c7063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320c8 (pfn 5555555555555555) from
L1 entry 8000000c320c8063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320c9 (pfn 5555555555555555) from
L1 entry 8000000c320c9063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320ca (pfn 5555555555555555) from
L1 entry 8000000c320ca063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320cb (pfn 5555555555555555) from
L1 entry 8000000c320cb063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320cc (pfn 5555555555555555) from
L1 entry 8000000c320cc063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320cd (pfn 5555555555555555) from
L1 entry 8000000c320cd063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320ce (pfn 5555555555555555) from
L1 entry 8000000c320ce063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320cf (pfn 5555555555555555) from
L1 entry 8000000c320cf063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320d0 (pfn 5555555555555555) from
L1 entry 8000000c320d0063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320d1 (pfn 5555555555555555) from
L1 entry 8000000c320d1063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320d2 (pfn 5555555555555555) from
L1 entry 8000000c320d2063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320d3 (pfn 5555555555555555) from
L1 entry 8000000c320d3063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320d4 (pfn 5555555555555555) from
L1 entry 8000000c320d4063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320d5 (pfn 5555555555555555) from
L1 entry 8000000c320d5063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320d6 (pfn 5555555555555555) from
L1 entry 8000000c320d6063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320d7 (pfn 5555555555555555) from
L1 entry 8000000c320d7063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320d8 (pfn 5555555555555555) from
L1 entry 8000000c320d8063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320d9 (pfn 5555555555555555) from
L1 entry 8000000c320d9063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320da (pfn 5555555555555555) from
L1 entry 8000000c320da063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320db (pfn 5555555555555555) from
L1 entry 8000000c320db063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320dc (pfn 5555555555555555) from
L1 entry 8000000c320dc063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320dd (pfn 5555555555555555) from
L1 entry 8000000c320dd063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320de (pfn 5555555555555555) from
L1 entry 8000000c320de063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320df (pfn 5555555555555555) from
L1 entry 8000000c320df063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320e0 (pfn 5555555555555555) from
L1 entry 8000000c320e0063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320e1 (pfn 5555555555555555) from
L1 entry 8000000c320e1063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320e2 (pfn 5555555555555555) from
L1 entry 8000000c320e2063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320e3 (pfn 5555555555555555) from
L1 entry 8000000c320e3063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320e4 (pfn 5555555555555555) from
L1 entry 8000000c320e4063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320e5 (pfn 5555555555555555) from
L1 entry 8000000c320e5063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320e6 (pfn 5555555555555555) from
L1 entry 8000000c320e6063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320e7 (pfn 5555555555555555) from
L1 entry 8000000c320e7063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320e8 (pfn 5555555555555555) from
L1 entry 8000000c320e8063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320e9 (pfn 5555555555555555) from
L1 entry 8000000c320e9063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320ea (pfn 5555555555555555) from
L1 entry 8000000c320ea063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320eb (pfn 5555555555555555) from
L1 entry 8000000c320eb063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320ec (pfn 5555555555555555) from
L1 entry 8000000c320ec063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320ed (pfn 5555555555555555) from
L1 entry 8000000c320ed063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320ee (pfn 5555555555555555) from
L1 entry 8000000c320ee063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320ef (pfn 5555555555555555) from
L1 entry 8000000c320ef063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320f0 (pfn 5555555555555555) from
L1 entry 8000000c320f0063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320f1 (pfn 5555555555555555) from
L1 entry 8000000c320f1063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320f2 (pfn 5555555555555555) from
L1 entry 8000000c320f2063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320f3 (pfn 5555555555555555) from
L1 entry 8000000c320f3063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320f4 (pfn 5555555555555555) from
L1 entry 8000000c320f4063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320f5 (pfn 5555555555555555) from
L1 entry 8000000c320f5063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320f6 (pfn 5555555555555555) from
L1 entry 8000000c320f6063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320f7 (pfn 5555555555555555) from
L1 entry 8000000c320f7063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320f8 (pfn 5555555555555555) from
L1 entry 8000000c320f8063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320f9 (pfn 5555555555555555) from
L1 entry 8000000c320f9063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320fa (pfn 5555555555555555) from
L1 entry 8000000c320fa063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320fb (pfn 5555555555555555) from
L1 entry 8000000c320fb063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320fc (pfn 5555555555555555) from
L1 entry 8000000c320fc063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320fd (pfn 5555555555555555) from
L1 entry 8000000c320fd063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320fe (pfn 5555555555555555) from
L1 entry 8000000c320fe063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320ff (pfn 5555555555555555) from
L1 entry 8000000c320ff063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32110 (pfn 5555555555555555) from
L1 entry 8000000c32110063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32111 (pfn 5555555555555555) from
L1 entry 8000000c32111063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32112 (pfn 5555555555555555) from
L1 entry 8000000c32112063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32113 (pfn 5555555555555555) from
L1 entry 8000000c32113063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32114 (pfn 5555555555555555) from
L1 entry 8000000c32114063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32115 (pfn 5555555555555555) from
L1 entry 8000000c32115063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32116 (pfn 5555555555555555) from
L1 entry 8000000c32116063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32117 (pfn 5555555555555555) from
L1 entry 8000000c32117063 for l1e_owner=0, pg_owner=0
(XEN) ../physdev.c:171: dom0: wrong map_pirq type 3

-- 
William

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 19 13:51:55 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Sep 2012 13:51:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TEKgk-0006yc-NW; Wed, 19 Sep 2012 13:51:38 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wdauchy@gmail.com>) id 1TEKgi-0006yC-0s
	for xen-devel@lists.xensource.com; Wed, 19 Sep 2012 13:51:36 +0000
Received: from [85.158.139.83:21525] by server-4.bemta-5.messagelabs.com id
	CA/07-23042-7EDC9505; Wed, 19 Sep 2012 13:51:35 +0000
X-Env-Sender: wdauchy@gmail.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1348062690!30553096!1
X-Originating-IP: [209.85.160.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-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15824 invoked from network); 19 Sep 2012 13:51:31 -0000
Received: from mail-pb0-f43.google.com (HELO mail-pb0-f43.google.com)
	(209.85.160.43)
	by server-9.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Sep 2012 13:51:31 -0000
Received: by pbbrq2 with SMTP id rq2so3236675pbb.30
	for <xen-devel@lists.xensource.com>;
	Wed, 19 Sep 2012 06:51: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=/gaXM+QHJ3PcDpbtBbtbEE4MWL3sVhKDMOAwBACjVy8=;
	b=K2UQYjqGpOmiDiAfhFUTpO+j1N9mkcUCrFytS/ESGgl6TPuvaPe4l4+/tZVrp5HnFI
	bqpqcBGvFzntZJRmf0CKAc+h5QkjN69F+trQag18i1hr018XTKSt3BGxBKq8wipSKlZK
	AosHDGGg+hsSPtbi3prORy3AG/9cUNsH3EEyueb8c1i+JfxM7Bn5Hh3kPNvavdx1Cqmh
	iIAwPrSUHcIFlvDkiRgkgD8q//LyJ3oj3shiETVrFCL3cYsVwA4PCJEtQRLHsuIottb2
	0lUfd9z05rtkoxFhaHqRHnM5I+lke0J4asbLK+iRrsTOvi8LUyJKROe+ncqSECB7W71x
	ilEA==
Received: by 10.66.86.133 with SMTP id p5mr7053582paz.35.1348062689691; Wed,
	19 Sep 2012 06:51:29 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.68.135.42 with HTTP; Wed, 19 Sep 2012 06:51:08 -0700 (PDT)
In-Reply-To: <20120918133650.GC12053@phenom.dumpdata.com>
References: <CAJ75kXZm-BqWdL2O41XkSE1VCdd4ruW=+CqDmR1b3=701RnXmw@mail.gmail.com>
	<20120918133650.GC12053@phenom.dumpdata.com>
From: William Dauchy <wdauchy@gmail.com>
Date: Wed, 19 Sep 2012 15:51:08 +0200
Message-ID: <CAJ75kXabH_ZE2L_u8y2eD9H6W8AG1OKNv-GOM9uRK7CDtas5zQ@mail.gmail.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] Error getting mfn
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi Konrad,

Thank your for you reply.

On Tue, Sep 18, 2012 at 3:36 PM, Konrad Rzeszutek Wilk
<konrad.wilk@oracle.com> wrote:
> Since this is 32-bit, I wonder if you are hitting the CONFIG_NUMA issue...

yes I do have CONFIG_NUMA enabled

> but I think you reported it some time ago and did you try the fix?

Are you talking about:
http://lists.xen.org/archives/html/xen-devel/2012-05/msg02204.html
because I did validate the fix but for me it was a different issue.
I saw that the fix was not accepted though https://lkml.org/lkml/2012/5/31/417

Please note that this fix was also applied on top of my 3.4.7 kernel.

> That shouldn't be it - b/c the URL you mentioned is for the set of patches
> that are destined for v3.7.

yup thought it could be related. never mind.

> Please use 'sync_console loglvl=all dom0_max_vcpus=1 console=com1 com1=xxxxx' and on the Linux command line:
> 'console=hvc0 debug loglevel=8"

please find below the output with and without CONFIG_NUMA.

without CONFIG_NUMA:

(XEN) Xen version 4.1.3 (package@) (gcc version 4.4.5 (Debian 4.4.5-8)
) Mon Sep 17 15:01:52 UTC 2012
(XEN) Latest ChangeSet: Thu Aug 09 16:47:30 2012 +0100 23334:ce7195d2b80e
(XEN) Bootloader: COM32 Multiboot loader v0.2
(XEN) Command line: console=vga dom0_mem=1024M,max:1024M loglvl=info
guest_loglvl=info
(XEN) Video information:
(XEN)  VGA is text mode 80x25, font 8x16
(XEN)  VBE/DDC methods: none; EDID transfer time: 1 seconds
(XEN)  EDID info not retrieved because no DDC retrieval method detected
(XEN) Disc information:
(XEN)  Found 0 MBR signatures
(XEN)  Found 0 EDD information structures
(XEN) Xen-e820 RAM map:
(XEN)  0000000000000000 - 000000000009b400 (usable)
(XEN)  000000000009b400 - 00000000000a0000 (reserved)
(XEN)  00000000000e0000 - 0000000000100000 (reserved)
(XEN)  0000000000100000 - 00000000bf730000 (usable)
(XEN)  00000000bf730000 - 00000000bf73e000 (ACPI data)
(XEN)  00000000bf73e000 - 00000000bf7a0000 (ACPI NVS)
(XEN)  00000000bf7a0000 - 00000000bf7b0000 (reserved)
(XEN)  00000000bf7bc000 - 00000000c0000000 (reserved)
(XEN)  00000000e0000000 - 00000000f0000000 (reserved)
(XEN)  00000000fee00000 - 00000000fee01000 (reserved)
(XEN)  00000000ffa00000 - 0000000100000000 (reserved)
(XEN)  0000000100000000 - 0000000c40000000 (usable)
(XEN) ACPI: RSDP 000FA6F0, 0024 (r2 ACPIAM)
(XEN) ACPI: XSDT BF730100, 006C (r1 122311 XSDT1136 20111223 MSFT       97)
(XEN) ACPI: FACP BF730290, 00F4 (r4 122311 FACP1136 20111223 MSFT       97)
(XEN) ACPI: DSDT BF730540, 48F7 (r2  5442B 5442B166      166 INTL 20051117)
(XEN) ACPI: FACS BF73E000, 0040
(XEN) ACPI: APIC BF730390, 011E (r2 122311 APIC1136 20111223 MSFT       97)
(XEN) ACPI: SPCR BF7304B0, 0050 (r1 122311 SPCR1136 20111223 MSFT       97)
(XEN) ACPI: MCFG BF730500, 003C (r1 122311 OEMMCFG  20111223 MSFT       97)
(XEN) ACPI: OEMB BF73E040, 0082 (r1 122311 OEMB1136 20111223 MSFT       97)
(XEN) ACPI: SRAT BF73A540, 0250 (r2 122311 OEMSRAT         1 INTL        1)
(XEN) ACPI: HPET BF73A790, 0038 (r1 122311 OEMHPET  20111223 MSFT       97)
(XEN) ACPI: DMAR BF73E0D0, 00D8 (r1    AMI  OEMDMAR        1 MSFT       97)
(XEN) ACPI: SSDT BF7439A0, 0363 (r1 DpgPmm    CpuPm       12 INTL 20051117)
(XEN) System RAM: 49142MB (50322220kB)
(XEN) SRAT: PXM 0 -> APIC 0 -> Node 0
(XEN) SRAT: PXM 0 -> APIC 2 -> Node 0
(XEN) SRAT: PXM 0 -> APIC 4 -> Node 0
(XEN) SRAT: PXM 0 -> APIC 16 -> Node 0
(XEN) SRAT: PXM 0 -> APIC 18 -> Node 0
(XEN) SRAT: PXM 0 -> APIC 20 -> Node 0
(XEN) SRAT: PXM 0 -> APIC 1 -> Node 0
(XEN) SRAT: PXM 0 -> APIC 3 -> Node 0
(XEN) SRAT: PXM 0 -> APIC 5 -> Node 0
(XEN) SRAT: PXM 0 -> APIC 17 -> Node 0
(XEN) SRAT: PXM 0 -> APIC 19 -> Node 0
(XEN) SRAT: PXM 0 -> APIC 21 -> Node 0
(XEN) SRAT: PXM 1 -> APIC 32 -> Node 1
(XEN) SRAT: PXM 1 -> APIC 34 -> Node 1
(XEN) SRAT: PXM 1 -> APIC 36 -> Node 1
(XEN) SRAT: PXM 1 -> APIC 48 -> Node 1
(XEN) SRAT: PXM 1 -> APIC 50 -> Node 1
(XEN) SRAT: PXM 1 -> APIC 52 -> Node 1
(XEN) SRAT: PXM 1 -> APIC 33 -> Node 1
(XEN) SRAT: PXM 1 -> APIC 35 -> Node 1
(XEN) SRAT: PXM 1 -> APIC 37 -> Node 1
(XEN) SRAT: PXM 1 -> APIC 49 -> Node 1
(XEN) SRAT: PXM 1 -> APIC 51 -> Node 1
(XEN) SRAT: PXM 1 -> APIC 53 -> Node 1
(XEN) SRAT: Node 0 PXM 0 0-a0000
(XEN) SRAT: Node 0 PXM 0 100000-c0000000
(XEN) SRAT: Node 0 PXM 0 100000000-640000000
(XEN) SRAT: Node 1 PXM 1 640000000-c40000000
(XEN) Domain heap initialised DMA width 32 bits
(XEN) found SMP MP-table at 000ff780
(XEN) DMI present.
(XEN) Using APIC driver default
(XEN) ACPI: PM-Timer IO Port: 0x808
(XEN) ACPI: ACPI SLEEP INFO: pm1x_cnt[804,0], pm1x_evt[800,0]
(XEN) ACPI:                  wakeup_vec[bf73e00c], vec_size[20]
(XEN) ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled)
(XEN) Processor #0 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x02] lapic_id[0x02] enabled)
(XEN) Processor #2 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x03] lapic_id[0x04] enabled)
(XEN) Processor #4 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x04] lapic_id[0x10] enabled)
(XEN) Processor #16 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x05] lapic_id[0x12] enabled)
(XEN) Processor #18 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x06] lapic_id[0x14] enabled)
(XEN) Processor #20 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x07] lapic_id[0x20] enabled)
(XEN) Processor #32 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x08] lapic_id[0x22] enabled)
(XEN) Processor #34 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x09] lapic_id[0x24] enabled)
(XEN) Processor #36 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x0a] lapic_id[0x30] enabled)
(XEN) Processor #48 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x0b] lapic_id[0x32] enabled)
(XEN) Processor #50 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x0c] lapic_id[0x34] enabled)
(XEN) Processor #52 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x0d] lapic_id[0x01] enabled)
(XEN) Processor #1 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x0e] lapic_id[0x03] enabled)
(XEN) Processor #3 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x0f] lapic_id[0x05] enabled)
(XEN) Processor #5 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x10] lapic_id[0x11] enabled)
(XEN) Processor #17 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x11] lapic_id[0x13] enabled)
(XEN) Processor #19 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x12] lapic_id[0x15] enabled)
(XEN) Processor #21 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x13] lapic_id[0x21] enabled)
(XEN) Processor #33 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x14] lapic_id[0x23] enabled)
(XEN) Processor #35 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x15] lapic_id[0x25] enabled)
(XEN) Processor #37 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x16] lapic_id[0x31] enabled)
(XEN) Processor #49 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x17] lapic_id[0x33] enabled)
(XEN) Processor #51 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x18] lapic_id[0x35] enabled)
(XEN) Processor #53 6:12 APIC version 21
(XEN) ACPI: LAPIC_NMI (acpi_id[0xff] dfl dfl lint[0x1])
(XEN) Overriding APIC driver with bigsmp
(XEN) ACPI: IOAPIC (id[0x06] address[0xfec00000] gsi_base[0])
(XEN) IOAPIC[0]: apic_id 6, version 32, address 0xfec00000, GSI 0-23
(XEN) ACPI: IOAPIC (id[0x07] address[0xfec8a000] gsi_base[24])
(XEN) IOAPIC[1]: apic_id 7, version 32, address 0xfec8a000, GSI 24-47
(XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
(XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
(XEN) Enabling APIC mode:  Phys.  Using 2 I/O APICs
(XEN) ACPI: HPET id: 0x8086a301 base: 0xfed00000
(XEN) PCI: MCFG configuration 0: base e0000000 segment 0 buses 0 - 255
(XEN) PCI: MCFG area at e0000000 reserved in E820
(XEN) Table is not found!
(XEN) Using ACPI (MADT) for SMP configuration information
(XEN) IRQ limits: 48 GSI, 4576 MSI/MSI-X
(XEN) Using scheduler: SMP Credit Scheduler (credit)
(XEN) Detected 2266.823 MHz processor.
(XEN) Initing memory sharing.
(XEN) mce_intel.c:1162: MCA Capability: BCAST 1 SER 0 CMCI 1 firstbank
0 extended MCE MSR 0
(XEN) Intel machine check reporting enabled
(XEN) Intel VT-d supported page sizes: 4kB.
(XEN) Intel VT-d Snoop Control enabled.
(XEN) Intel VT-d Dom0 DMA Passthrough not enabled.
(XEN) Intel VT-d Queued Invalidation enabled.
(XEN) Intel VT-d Interrupt Remapping not enabled.
(XEN) Intel VT-d Shared EPT tables not enabled.
(XEN) I/O virtualisation enabled
(XEN)  - Dom0 mode: Relaxed
(XEN) Enabled directed EOI with ioapic_ack_old on!
(XEN) ENABLING IO-APIC IRQs
(XEN)  -> Using old ACK method
(XEN) ..TIMER: vector=0xF0 apic1=0 pin1=2 apic2=-1 pin2=-1
(XEN) Platform timer is 14.318MHz HPET
(XEN) Defaulting to alternative key handling; send 'A' to switch to normal mode.
(XEN) Allocated console ring of 128 KiB.
(XEN) VMX: Supported advanced features:
(XEN)  - APIC MMIO access virtualisation
(XEN)  - APIC TPR shadow
(XEN)  - Extended Page Tables (EPT)
(XEN)  - Virtual-Processor Identifiers (VPID)
(XEN)  - Virtual NMI
(XEN)  - MSR direct-access bitmap
(XEN)  - Unrestricted Guest
(XEN) HVM: ASIDs enabled.
(XEN) HVM: VMX enabled
(XEN) HVM: Hardware Assisted Paging (HAP) detected
(XEN) HVM: HAP page sizes: 4kB, 2MB, 1GB
(XEN) Brought up 24 CPUs
(XEN) ACPI sleep modes: S3
(XEN) mcheck_poll: Machine check polling timer started.
(XEN) *** LOADING DOMAIN 0 ***
(XEN)  Xen  kernel: 64-bit, lsb, compat32
(XEN)  Dom0 kernel: 32-bit, PAE, lsb, paddr 0x1000000 -> 0x17ce000
(XEN) PHYSICAL MEMORY ARRANGEMENT:
(XEN)  Dom0 alloc.:   0000000c20000000->0000000c22000000 (253212 pages
to be allocated)
(XEN)  Init. ramdisk: 0000000c3fd1c000->0000000c3ffff200
(XEN) VIRTUAL MEMORY ARRANGEMENT:
(XEN)  Loaded kernel: 00000000c1000000->00000000c17ce000
(XEN)  Init. ramdisk: 00000000c17ce000->00000000c1ab1200
(XEN)  Phys-Mach map: 00000000c1ab2000->00000000c1bb2000
(XEN)  Start info:    00000000c1bb2000->00000000c1bb24b4
(XEN)  Page tables:   00000000c1bb3000->00000000c1bc9000
(XEN)  Boot stack:    00000000c1bc9000->00000000c1bca000
(XEN)  TOTAL:         00000000c0000000->00000000c2000000
(XEN)  ENTRY ADDRESS: 00000000c14eb000
(XEN) Dom0 has maximum 24 VCPUs
(XEN) Scrubbing Free RAM:
..........................................................................................................................................................................................................................................................................................................................................................................................................................................................................................done.
(XEN) Xen trace buffers: disabled
(XEN) Std. Loglevel: Errors, warnings and info
(XEN) Guest Loglevel: Errors, warnings and info
(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) mm.c:908:d0 Error getting mfn 2009b (pfn 5555555555555555) from
L1 entry 000000002009b023 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn 2009c (pfn 5555555555555555) from
L1 entry 000000002009c023 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn 2009d (pfn 5555555555555555) from
L1 entry 000000002009d023 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn 2009e (pfn 5555555555555555) from
L1 entry 000000002009e023 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn 2009f (pfn 5555555555555555) from
L1 entry 000000002009f023 for l1e_owner=0, pg_owner=0
(XEN) ../physdev.c:171: dom0: wrong map_pirq type 3

with CONFIG_NUMA:

(XEN) Xen version 4.1.3 (package@) (gcc version 4.4.5 (Debian 4.4.5-8)
) Mon Sep 17 15:01:52 UTC 2012
(XEN) Latest ChangeSet: Thu Aug 09 16:47:30 2012 +0100 23334:ce7195d2b80e
(XEN) Bootloader: COM32 Multiboot loader v0.2
(XEN) Command line: console=vga dom0_mem=1024M,max:1024M loglvl=info
guest_loglvl=info
(XEN) Video information:
(XEN)  VGA is text mode 80x25, font 8x16
(XEN)  VBE/DDC methods: none; EDID transfer time: 1 seconds
(XEN)  EDID info not retrieved because no DDC retrieval method detected
(XEN) Disc information:
(XEN)  Found 0 MBR signatures
(XEN)  Found 0 EDD information structures
(XEN) Xen-e820 RAM map:
(XEN)  0000000000000000 - 000000000009b400 (usable)
(XEN)  000000000009b400 - 00000000000a0000 (reserved)
(XEN)  00000000000e0000 - 0000000000100000 (reserved)
(XEN)  0000000000100000 - 00000000bf730000 (usable)
(XEN)  00000000bf730000 - 00000000bf73e000 (ACPI data)
(XEN)  00000000bf73e000 - 00000000bf7a0000 (ACPI NVS)
(XEN)  00000000bf7a0000 - 00000000bf7b0000 (reserved)
(XEN)  00000000bf7bc000 - 00000000c0000000 (reserved)
(XEN)  00000000e0000000 - 00000000f0000000 (reserved)
(XEN)  00000000fee00000 - 00000000fee01000 (reserved)
(XEN)  00000000ffa00000 - 0000000100000000 (reserved)
(XEN)  0000000100000000 - 0000000c40000000 (usable)
(XEN) ACPI: RSDP 000FA6F0, 0024 (r2 ACPIAM)
(XEN) ACPI: XSDT BF730100, 006C (r1 122311 XSDT1136 20111223 MSFT       97)
(XEN) ACPI: FACP BF730290, 00F4 (r4 122311 FACP1136 20111223 MSFT       97)
(XEN) ACPI: DSDT BF730540, 48F7 (r2  5442B 5442B166      166 INTL 20051117)
(XEN) ACPI: FACS BF73E000, 0040
(XEN) ACPI: APIC BF730390, 011E (r2 122311 APIC1136 20111223 MSFT       97)
(XEN) ACPI: SPCR BF7304B0, 0050 (r1 122311 SPCR1136 20111223 MSFT       97)
(XEN) ACPI: MCFG BF730500, 003C (r1 122311 OEMMCFG  20111223 MSFT       97)
(XEN) ACPI: OEMB BF73E040, 0082 (r1 122311 OEMB1136 20111223 MSFT       97)
(XEN) ACPI: SRAT BF73A540, 0250 (r2 122311 OEMSRAT         1 INTL        1)
(XEN) ACPI: HPET BF73A790, 0038 (r1 122311 OEMHPET  20111223 MSFT       97)
(XEN) ACPI: DMAR BF73E0D0, 00D8 (r1    AMI  OEMDMAR        1 MSFT       97)
(XEN) ACPI: SSDT BF7439A0, 0363 (r1 DpgPmm    CpuPm       12 INTL 20051117)
(XEN) System RAM: 49142MB (50322220kB)
(XEN) SRAT: PXM 0 -> APIC 0 -> Node 0
(XEN) SRAT: PXM 0 -> APIC 2 -> Node 0
(XEN) SRAT: PXM 0 -> APIC 4 -> Node 0
(XEN) SRAT: PXM 0 -> APIC 16 -> Node 0
(XEN) SRAT: PXM 0 -> APIC 18 -> Node 0
(XEN) SRAT: PXM 0 -> APIC 20 -> Node 0
(XEN) SRAT: PXM 0 -> APIC 1 -> Node 0
(XEN) SRAT: PXM 0 -> APIC 3 -> Node 0
(XEN) SRAT: PXM 0 -> APIC 5 -> Node 0
(XEN) SRAT: PXM 0 -> APIC 17 -> Node 0
(XEN) SRAT: PXM 0 -> APIC 19 -> Node 0
(XEN) SRAT: PXM 0 -> APIC 21 -> Node 0
(XEN) SRAT: PXM 1 -> APIC 32 -> Node 1
(XEN) SRAT: PXM 1 -> APIC 34 -> Node 1
(XEN) SRAT: PXM 1 -> APIC 36 -> Node 1
(XEN) SRAT: PXM 1 -> APIC 48 -> Node 1
(XEN) SRAT: PXM 1 -> APIC 50 -> Node 1
(XEN) SRAT: PXM 1 -> APIC 52 -> Node 1
(XEN) SRAT: PXM 1 -> APIC 33 -> Node 1
(XEN) SRAT: PXM 1 -> APIC 35 -> Node 1
(XEN) SRAT: PXM 1 -> APIC 37 -> Node 1
(XEN) SRAT: PXM 1 -> APIC 49 -> Node 1
(XEN) SRAT: PXM 1 -> APIC 51 -> Node 1
(XEN) SRAT: PXM 1 -> APIC 53 -> Node 1
(XEN) SRAT: Node 0 PXM 0 0-a0000
(XEN) SRAT: Node 0 PXM 0 100000-c0000000
(XEN) SRAT: Node 0 PXM 0 100000000-640000000
(XEN) SRAT: Node 1 PXM 1 640000000-c40000000
(XEN) Domain heap initialised DMA width 32 bits
(XEN) found SMP MP-table at 000ff780
(XEN) DMI present.
(XEN) Using APIC driver default
(XEN) ACPI: PM-Timer IO Port: 0x808
(XEN) ACPI: ACPI SLEEP INFO: pm1x_cnt[804,0], pm1x_evt[800,0]
(XEN) ACPI:                  wakeup_vec[bf73e00c], vec_size[20]
(XEN) ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled)
(XEN) Processor #0 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x02] lapic_id[0x02] enabled)
(XEN) Processor #2 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x03] lapic_id[0x04] enabled)
(XEN) Processor #4 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x04] lapic_id[0x10] enabled)
(XEN) Processor #16 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x05] lapic_id[0x12] enabled)
(XEN) Processor #18 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x06] lapic_id[0x14] enabled)
(XEN) Processor #20 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x07] lapic_id[0x20] enabled)
(XEN) Processor #32 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x08] lapic_id[0x22] enabled)
(XEN) Processor #34 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x09] lapic_id[0x24] enabled)
(XEN) Processor #36 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x0a] lapic_id[0x30] enabled)
(XEN) Processor #48 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x0b] lapic_id[0x32] enabled)
(XEN) Processor #50 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x0c] lapic_id[0x34] enabled)
(XEN) Processor #52 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x0d] lapic_id[0x01] enabled)
(XEN) Processor #1 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x0e] lapic_id[0x03] enabled)
(XEN) Processor #3 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x0f] lapic_id[0x05] enabled)
(XEN) Processor #5 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x10] lapic_id[0x11] enabled)
(XEN) Processor #17 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x11] lapic_id[0x13] enabled)
(XEN) Processor #19 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x12] lapic_id[0x15] enabled)
(XEN) Processor #21 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x13] lapic_id[0x21] enabled)
(XEN) Processor #33 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x14] lapic_id[0x23] enabled)
(XEN) Processor #35 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x15] lapic_id[0x25] enabled)
(XEN) Processor #37 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x16] lapic_id[0x31] enabled)
(XEN) Processor #49 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x17] lapic_id[0x33] enabled)
(XEN) Processor #51 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x18] lapic_id[0x35] enabled)
(XEN) Processor #53 6:12 APIC version 21
(XEN) ACPI: LAPIC_NMI (acpi_id[0xff] dfl dfl lint[0x1])
(XEN) Overriding APIC driver with bigsmp
(XEN) ACPI: IOAPIC (id[0x06] address[0xfec00000] gsi_base[0])
(XEN) IOAPIC[0]: apic_id 6, version 32, address 0xfec00000, GSI 0-23
(XEN) ACPI: IOAPIC (id[0x07] address[0xfec8a000] gsi_base[24])
(XEN) IOAPIC[1]: apic_id 7, version 32, address 0xfec8a000, GSI 24-47
(XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
(XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
(XEN) Enabling APIC mode:  Phys.  Using 2 I/O APICs
(XEN) ACPI: HPET id: 0x8086a301 base: 0xfed00000
(XEN) PCI: MCFG configuration 0: base e0000000 segment 0 buses 0 - 255
(XEN) PCI: MCFG area at e0000000 reserved in E820
(XEN) Table is not found!
(XEN) Using ACPI (MADT) for SMP configuration information
(XEN) IRQ limits: 48 GSI, 4576 MSI/MSI-X
(XEN) Using scheduler: SMP Credit Scheduler (credit)
(XEN) Detected 2266.804 MHz processor.
(XEN) Initing memory sharing.
(XEN) mce_intel.c:1162: MCA Capability: BCAST 1 SER 0 CMCI 1 firstbank
0 extended MCE MSR 0
(XEN) Intel machine check reporting enabled
(XEN) Intel VT-d supported page sizes: 4kB.
(XEN) Intel VT-d Snoop Control enabled.
(XEN) Intel VT-d Dom0 DMA Passthrough not enabled.
(XEN) Intel VT-d Queued Invalidation enabled.
(XEN) Intel VT-d Interrupt Remapping not enabled.
(XEN) Intel VT-d Shared EPT tables not enabled.
(XEN) I/O virtualisation enabled
(XEN)  - Dom0 mode: Relaxed
(XEN) Enabled directed EOI with ioapic_ack_old on!
(XEN) ENABLING IO-APIC IRQs
(XEN)  -> Using old ACK method
(XEN) ..TIMER: vector=0xF0 apic1=0 pin1=2 apic2=-1 pin2=-1
(XEN) Platform timer is 14.318MHz HPET
(XEN) Defaulting to alternative key handling; send 'A' to switch to normal mode.
(XEN) Allocated console ring of 128 KiB.
(XEN) VMX: Supported advanced features:
(XEN)  - APIC MMIO access virtualisation
(XEN)  - APIC TPR shadow
(XEN)  - Extended Page Tables (EPT)
(XEN)  - Virtual-Processor Identifiers (VPID)
(XEN)  - Virtual NMI
(XEN)  - MSR direct-access bitmap
(XEN)  - Unrestricted Guest
(XEN) HVM: ASIDs enabled.
(XEN) HVM: VMX enabled
(XEN) HVM: Hardware Assisted Paging (HAP) detected
(XEN) HVM: HAP page sizes: 4kB, 2MB, 1GB
(XEN) Brought up 24 CPUs
(XEN) ACPI sleep modes: S3
(XEN) mcheck_poll: Machine check polling timer started.
(XEN) *** LOADING DOMAIN 0 ***
(XEN)  Xen  kernel: 64-bit, lsb, compat32
(XEN)  Dom0 kernel: 32-bit, PAE, lsb, paddr 0x1000000 -> 0x17dc000
(XEN) PHYSICAL MEMORY ARRANGEMENT:
(XEN)  Dom0 alloc.:   0000000c20000000->0000000c22000000 (253212 pages
to be allocated)
(XEN)  Init. ramdisk: 0000000c3fd1c000->0000000c3ffff200
(XEN) VIRTUAL MEMORY ARRANGEMENT:
(XEN)  Loaded kernel: 00000000c1000000->00000000c17dc000
(XEN)  Init. ramdisk: 00000000c17dc000->00000000c1abf200
(XEN)  Phys-Mach map: 00000000c1ac0000->00000000c1bc0000
(XEN)  Start info:    00000000c1bc0000->00000000c1bc04b4
(XEN)  Page tables:   00000000c1bc1000->00000000c1bd7000
(XEN)  Boot stack:    00000000c1bd7000->00000000c1bd8000
(XEN)  TOTAL:         00000000c0000000->00000000c2000000
(XEN)  ENTRY ADDRESS: 00000000c14f5000
(XEN) Dom0 has maximum 24 VCPUs
(XEN) Scrubbing Free RAM:
..........................................................................................................................................................................................................................................................................................................................................................................................................................................................................................done.
(XEN) Xen trace buffers: disabled
(XEN) Std. Loglevel: Errors, warnings and info
(XEN) Guest Loglevel: Errors, warnings and info
(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) mm.c:908:d0 Error getting mfn 2009b (pfn 5555555555555555) from
L1 entry 000000002009b023 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn 2009c (pfn 5555555555555555) from
L1 entry 000000002009c023 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn 2009d (pfn 5555555555555555) from
L1 entry 000000002009d023 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn 2009e (pfn 5555555555555555) from
L1 entry 000000002009e023 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn 2009f (pfn 5555555555555555) from
L1 entry 000000002009f023 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32000 (pfn 5555555555555555) from
L1 entry 8000000c32000063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32001 (pfn 5555555555555555) from
L1 entry 8000000c32001063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32002 (pfn 5555555555555555) from
L1 entry 8000000c32002063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32003 (pfn 5555555555555555) from
L1 entry 8000000c32003063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32004 (pfn 5555555555555555) from
L1 entry 8000000c32004063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32005 (pfn 5555555555555555) from
L1 entry 8000000c32005063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32006 (pfn 5555555555555555) from
L1 entry 8000000c32006063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32007 (pfn 5555555555555555) from
L1 entry 8000000c32007063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32008 (pfn 5555555555555555) from
L1 entry 8000000c32008063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32009 (pfn 5555555555555555) from
L1 entry 8000000c32009063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c3200a (pfn 5555555555555555) from
L1 entry 8000000c3200a063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c3200b (pfn 5555555555555555) from
L1 entry 8000000c3200b063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c3200c (pfn 5555555555555555) from
L1 entry 8000000c3200c063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c3200d (pfn 5555555555555555) from
L1 entry 8000000c3200d063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c3200e (pfn 5555555555555555) from
L1 entry 8000000c3200e063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c3200f (pfn 5555555555555555) from
L1 entry 8000000c3200f063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32010 (pfn 5555555555555555) from
L1 entry 8000000c32010063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32011 (pfn 5555555555555555) from
L1 entry 8000000c32011063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32012 (pfn 5555555555555555) from
L1 entry 8000000c32012063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32013 (pfn 5555555555555555) from
L1 entry 8000000c32013063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32014 (pfn 5555555555555555) from
L1 entry 8000000c32014063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32015 (pfn 5555555555555555) from
L1 entry 8000000c32015063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32016 (pfn 5555555555555555) from
L1 entry 8000000c32016063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32017 (pfn 5555555555555555) from
L1 entry 8000000c32017063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32018 (pfn 5555555555555555) from
L1 entry 8000000c32018063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32019 (pfn 5555555555555555) from
L1 entry 8000000c32019063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c3201a (pfn 5555555555555555) from
L1 entry 8000000c3201a063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c3201b (pfn 5555555555555555) from
L1 entry 8000000c3201b063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c3201c (pfn 5555555555555555) from
L1 entry 8000000c3201c063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c3201d (pfn 5555555555555555) from
L1 entry 8000000c3201d063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c3201e (pfn 5555555555555555) from
L1 entry 8000000c3201e063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c3201f (pfn 5555555555555555) from
L1 entry 8000000c3201f063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32020 (pfn 5555555555555555) from
L1 entry 8000000c32020063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32021 (pfn 5555555555555555) from
L1 entry 8000000c32021063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32022 (pfn 5555555555555555) from
L1 entry 8000000c32022063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32023 (pfn 5555555555555555) from
L1 entry 8000000c32023063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32024 (pfn 5555555555555555) from
L1 entry 8000000c32024063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32025 (pfn 5555555555555555) from
L1 entry 8000000c32025063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32026 (pfn 5555555555555555) from
L1 entry 8000000c32026063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32027 (pfn 5555555555555555) from
L1 entry 8000000c32027063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32028 (pfn 5555555555555555) from
L1 entry 8000000c32028063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32029 (pfn 5555555555555555) from
L1 entry 8000000c32029063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c3202a (pfn 5555555555555555) from
L1 entry 8000000c3202a063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c3202b (pfn 5555555555555555) from
L1 entry 8000000c3202b063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c3202c (pfn 5555555555555555) from
L1 entry 8000000c3202c063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c3202d (pfn 5555555555555555) from
L1 entry 8000000c3202d063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c3202e (pfn 5555555555555555) from
L1 entry 8000000c3202e063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c3202f (pfn 5555555555555555) from
L1 entry 8000000c3202f063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32030 (pfn 5555555555555555) from
L1 entry 8000000c32030063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32031 (pfn 5555555555555555) from
L1 entry 8000000c32031063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32032 (pfn 5555555555555555) from
L1 entry 8000000c32032063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32033 (pfn 5555555555555555) from
L1 entry 8000000c32033063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32034 (pfn 5555555555555555) from
L1 entry 8000000c32034063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32035 (pfn 5555555555555555) from
L1 entry 8000000c32035063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32036 (pfn 5555555555555555) from
L1 entry 8000000c32036063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32037 (pfn 5555555555555555) from
L1 entry 8000000c32037063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32038 (pfn 5555555555555555) from
L1 entry 8000000c32038063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32039 (pfn 5555555555555555) from
L1 entry 8000000c32039063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c3203a (pfn 5555555555555555) from
L1 entry 8000000c3203a063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c3203b (pfn 5555555555555555) from
L1 entry 8000000c3203b063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c3203c (pfn 5555555555555555) from
L1 entry 8000000c3203c063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c3203d (pfn 5555555555555555) from
L1 entry 8000000c3203d063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c3203e (pfn 5555555555555555) from
L1 entry 8000000c3203e063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c3203f (pfn 5555555555555555) from
L1 entry 8000000c3203f063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32040 (pfn 5555555555555555) from
L1 entry 8000000c32040063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32041 (pfn 5555555555555555) from
L1 entry 8000000c32041063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32042 (pfn 5555555555555555) from
L1 entry 8000000c32042063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32043 (pfn 5555555555555555) from
L1 entry 8000000c32043063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32044 (pfn 5555555555555555) from
L1 entry 8000000c32044063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32045 (pfn 5555555555555555) from
L1 entry 8000000c32045063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32046 (pfn 5555555555555555) from
L1 entry 8000000c32046063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32047 (pfn 5555555555555555) from
L1 entry 8000000c32047063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32048 (pfn 5555555555555555) from
L1 entry 8000000c32048063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32049 (pfn 5555555555555555) from
L1 entry 8000000c32049063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c3204a (pfn 5555555555555555) from
L1 entry 8000000c3204a063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c3204b (pfn 5555555555555555) from
L1 entry 8000000c3204b063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c3204c (pfn 5555555555555555) from
L1 entry 8000000c3204c063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c3204d (pfn 5555555555555555) from
L1 entry 8000000c3204d063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c3204e (pfn 5555555555555555) from
L1 entry 8000000c3204e063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c3204f (pfn 5555555555555555) from
L1 entry 8000000c3204f063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32050 (pfn 5555555555555555) from
L1 entry 8000000c32050063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32051 (pfn 5555555555555555) from
L1 entry 8000000c32051063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32052 (pfn 5555555555555555) from
L1 entry 8000000c32052063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32053 (pfn 5555555555555555) from
L1 entry 8000000c32053063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32054 (pfn 5555555555555555) from
L1 entry 8000000c32054063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32055 (pfn 5555555555555555) from
L1 entry 8000000c32055063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32056 (pfn 5555555555555555) from
L1 entry 8000000c32056063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32057 (pfn 5555555555555555) from
L1 entry 8000000c32057063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32058 (pfn 5555555555555555) from
L1 entry 8000000c32058063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32059 (pfn 5555555555555555) from
L1 entry 8000000c32059063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c3205a (pfn 5555555555555555) from
L1 entry 8000000c3205a063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c3205b (pfn 5555555555555555) from
L1 entry 8000000c3205b063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c3205c (pfn 5555555555555555) from
L1 entry 8000000c3205c063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c3205d (pfn 5555555555555555) from
L1 entry 8000000c3205d063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c3205e (pfn 5555555555555555) from
L1 entry 8000000c3205e063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c3205f (pfn 5555555555555555) from
L1 entry 8000000c3205f063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32060 (pfn 5555555555555555) from
L1 entry 8000000c32060063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32061 (pfn 5555555555555555) from
L1 entry 8000000c32061063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32062 (pfn 5555555555555555) from
L1 entry 8000000c32062063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32063 (pfn 5555555555555555) from
L1 entry 8000000c32063063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32064 (pfn 5555555555555555) from
L1 entry 8000000c32064063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32065 (pfn 5555555555555555) from
L1 entry 8000000c32065063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32066 (pfn 5555555555555555) from
L1 entry 8000000c32066063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32067 (pfn 5555555555555555) from
L1 entry 8000000c32067063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32068 (pfn 5555555555555555) from
L1 entry 8000000c32068063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32069 (pfn 5555555555555555) from
L1 entry 8000000c32069063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c3206a (pfn 5555555555555555) from
L1 entry 8000000c3206a063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c3206b (pfn 5555555555555555) from
L1 entry 8000000c3206b063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c3206c (pfn 5555555555555555) from
L1 entry 8000000c3206c063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c3206d (pfn 5555555555555555) from
L1 entry 8000000c3206d063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c3206e (pfn 5555555555555555) from
L1 entry 8000000c3206e063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c3206f (pfn 5555555555555555) from
L1 entry 8000000c3206f063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32070 (pfn 5555555555555555) from
L1 entry 8000000c32070063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32071 (pfn 5555555555555555) from
L1 entry 8000000c32071063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32072 (pfn 5555555555555555) from
L1 entry 8000000c32072063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32073 (pfn 5555555555555555) from
L1 entry 8000000c32073063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32074 (pfn 5555555555555555) from
L1 entry 8000000c32074063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32075 (pfn 5555555555555555) from
L1 entry 8000000c32075063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32076 (pfn 5555555555555555) from
L1 entry 8000000c32076063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32077 (pfn 5555555555555555) from
L1 entry 8000000c32077063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32078 (pfn 5555555555555555) from
L1 entry 8000000c32078063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32079 (pfn 5555555555555555) from
L1 entry 8000000c32079063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c3207a (pfn 5555555555555555) from
L1 entry 8000000c3207a063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c3207b (pfn 5555555555555555) from
L1 entry 8000000c3207b063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c3207c (pfn 5555555555555555) from
L1 entry 8000000c3207c063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c3207d (pfn 5555555555555555) from
L1 entry 8000000c3207d063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c3207e (pfn 5555555555555555) from
L1 entry 8000000c3207e063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c3207f (pfn 5555555555555555) from
L1 entry 8000000c3207f063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32080 (pfn 5555555555555555) from
L1 entry 8000000c32080063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32081 (pfn 5555555555555555) from
L1 entry 8000000c32081063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32082 (pfn 5555555555555555) from
L1 entry 8000000c32082063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32083 (pfn 5555555555555555) from
L1 entry 8000000c32083063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32084 (pfn 5555555555555555) from
L1 entry 8000000c32084063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32085 (pfn 5555555555555555) from
L1 entry 8000000c32085063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32086 (pfn 5555555555555555) from
L1 entry 8000000c32086063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32087 (pfn 5555555555555555) from
L1 entry 8000000c32087063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32088 (pfn 5555555555555555) from
L1 entry 8000000c32088063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32089 (pfn 5555555555555555) from
L1 entry 8000000c32089063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c3208a (pfn 5555555555555555) from
L1 entry 8000000c3208a063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c3208b (pfn 5555555555555555) from
L1 entry 8000000c3208b063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c3208c (pfn 5555555555555555) from
L1 entry 8000000c3208c063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c3208d (pfn 5555555555555555) from
L1 entry 8000000c3208d063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c3208e (pfn 5555555555555555) from
L1 entry 8000000c3208e063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c3208f (pfn 5555555555555555) from
L1 entry 8000000c3208f063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32090 (pfn 5555555555555555) from
L1 entry 8000000c32090063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32091 (pfn 5555555555555555) from
L1 entry 8000000c32091063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32092 (pfn 5555555555555555) from
L1 entry 8000000c32092063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32093 (pfn 5555555555555555) from
L1 entry 8000000c32093063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32094 (pfn 5555555555555555) from
L1 entry 8000000c32094063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32095 (pfn 5555555555555555) from
L1 entry 8000000c32095063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32096 (pfn 5555555555555555) from
L1 entry 8000000c32096063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32097 (pfn 5555555555555555) from
L1 entry 8000000c32097063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32098 (pfn 5555555555555555) from
L1 entry 8000000c32098063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32099 (pfn 5555555555555555) from
L1 entry 8000000c32099063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c3209a (pfn 5555555555555555) from
L1 entry 8000000c3209a063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c3209b (pfn 5555555555555555) from
L1 entry 8000000c3209b063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c3209c (pfn 5555555555555555) from
L1 entry 8000000c3209c063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c3209d (pfn 5555555555555555) from
L1 entry 8000000c3209d063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c3209e (pfn 5555555555555555) from
L1 entry 8000000c3209e063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c3209f (pfn 5555555555555555) from
L1 entry 8000000c3209f063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320a0 (pfn 5555555555555555) from
L1 entry 8000000c320a0063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320a1 (pfn 5555555555555555) from
L1 entry 8000000c320a1063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320a2 (pfn 5555555555555555) from
L1 entry 8000000c320a2063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320a3 (pfn 5555555555555555) from
L1 entry 8000000c320a3063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320a4 (pfn 5555555555555555) from
L1 entry 8000000c320a4063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320a5 (pfn 5555555555555555) from
L1 entry 8000000c320a5063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320a6 (pfn 5555555555555555) from
L1 entry 8000000c320a6063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320a7 (pfn 5555555555555555) from
L1 entry 8000000c320a7063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320a8 (pfn 5555555555555555) from
L1 entry 8000000c320a8063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320a9 (pfn 5555555555555555) from
L1 entry 8000000c320a9063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320aa (pfn 5555555555555555) from
L1 entry 8000000c320aa063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320ab (pfn 5555555555555555) from
L1 entry 8000000c320ab063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320ac (pfn 5555555555555555) from
L1 entry 8000000c320ac063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320ad (pfn 5555555555555555) from
L1 entry 8000000c320ad063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320ae (pfn 5555555555555555) from
L1 entry 8000000c320ae063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320af (pfn 5555555555555555) from
L1 entry 8000000c320af063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320b0 (pfn 5555555555555555) from
L1 entry 8000000c320b0063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320b1 (pfn 5555555555555555) from
L1 entry 8000000c320b1063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320b2 (pfn 5555555555555555) from
L1 entry 8000000c320b2063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320b3 (pfn 5555555555555555) from
L1 entry 8000000c320b3063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320b4 (pfn 5555555555555555) from
L1 entry 8000000c320b4063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320b5 (pfn 5555555555555555) from
L1 entry 8000000c320b5063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320b6 (pfn 5555555555555555) from
L1 entry 8000000c320b6063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320b7 (pfn 5555555555555555) from
L1 entry 8000000c320b7063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320b8 (pfn 5555555555555555) from
L1 entry 8000000c320b8063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320b9 (pfn 5555555555555555) from
L1 entry 8000000c320b9063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320ba (pfn 5555555555555555) from
L1 entry 8000000c320ba063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320bb (pfn 5555555555555555) from
L1 entry 8000000c320bb063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320bc (pfn 5555555555555555) from
L1 entry 8000000c320bc063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320bd (pfn 5555555555555555) from
L1 entry 8000000c320bd063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320be (pfn 5555555555555555) from
L1 entry 8000000c320be063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320bf (pfn 5555555555555555) from
L1 entry 8000000c320bf063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320c0 (pfn 5555555555555555) from
L1 entry 8000000c320c0063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320c1 (pfn 5555555555555555) from
L1 entry 8000000c320c1063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320c2 (pfn 5555555555555555) from
L1 entry 8000000c320c2063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320c3 (pfn 5555555555555555) from
L1 entry 8000000c320c3063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320c4 (pfn 5555555555555555) from
L1 entry 8000000c320c4063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320c5 (pfn 5555555555555555) from
L1 entry 8000000c320c5063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320c6 (pfn 5555555555555555) from
L1 entry 8000000c320c6063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320c7 (pfn 5555555555555555) from
L1 entry 8000000c320c7063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320c8 (pfn 5555555555555555) from
L1 entry 8000000c320c8063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320c9 (pfn 5555555555555555) from
L1 entry 8000000c320c9063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320ca (pfn 5555555555555555) from
L1 entry 8000000c320ca063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320cb (pfn 5555555555555555) from
L1 entry 8000000c320cb063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320cc (pfn 5555555555555555) from
L1 entry 8000000c320cc063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320cd (pfn 5555555555555555) from
L1 entry 8000000c320cd063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320ce (pfn 5555555555555555) from
L1 entry 8000000c320ce063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320cf (pfn 5555555555555555) from
L1 entry 8000000c320cf063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320d0 (pfn 5555555555555555) from
L1 entry 8000000c320d0063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320d1 (pfn 5555555555555555) from
L1 entry 8000000c320d1063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320d2 (pfn 5555555555555555) from
L1 entry 8000000c320d2063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320d3 (pfn 5555555555555555) from
L1 entry 8000000c320d3063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320d4 (pfn 5555555555555555) from
L1 entry 8000000c320d4063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320d5 (pfn 5555555555555555) from
L1 entry 8000000c320d5063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320d6 (pfn 5555555555555555) from
L1 entry 8000000c320d6063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320d7 (pfn 5555555555555555) from
L1 entry 8000000c320d7063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320d8 (pfn 5555555555555555) from
L1 entry 8000000c320d8063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320d9 (pfn 5555555555555555) from
L1 entry 8000000c320d9063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320da (pfn 5555555555555555) from
L1 entry 8000000c320da063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320db (pfn 5555555555555555) from
L1 entry 8000000c320db063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320dc (pfn 5555555555555555) from
L1 entry 8000000c320dc063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320dd (pfn 5555555555555555) from
L1 entry 8000000c320dd063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320de (pfn 5555555555555555) from
L1 entry 8000000c320de063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320df (pfn 5555555555555555) from
L1 entry 8000000c320df063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320e0 (pfn 5555555555555555) from
L1 entry 8000000c320e0063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320e1 (pfn 5555555555555555) from
L1 entry 8000000c320e1063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320e2 (pfn 5555555555555555) from
L1 entry 8000000c320e2063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320e3 (pfn 5555555555555555) from
L1 entry 8000000c320e3063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320e4 (pfn 5555555555555555) from
L1 entry 8000000c320e4063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320e5 (pfn 5555555555555555) from
L1 entry 8000000c320e5063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320e6 (pfn 5555555555555555) from
L1 entry 8000000c320e6063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320e7 (pfn 5555555555555555) from
L1 entry 8000000c320e7063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320e8 (pfn 5555555555555555) from
L1 entry 8000000c320e8063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320e9 (pfn 5555555555555555) from
L1 entry 8000000c320e9063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320ea (pfn 5555555555555555) from
L1 entry 8000000c320ea063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320eb (pfn 5555555555555555) from
L1 entry 8000000c320eb063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320ec (pfn 5555555555555555) from
L1 entry 8000000c320ec063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320ed (pfn 5555555555555555) from
L1 entry 8000000c320ed063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320ee (pfn 5555555555555555) from
L1 entry 8000000c320ee063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320ef (pfn 5555555555555555) from
L1 entry 8000000c320ef063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320f0 (pfn 5555555555555555) from
L1 entry 8000000c320f0063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320f1 (pfn 5555555555555555) from
L1 entry 8000000c320f1063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320f2 (pfn 5555555555555555) from
L1 entry 8000000c320f2063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320f3 (pfn 5555555555555555) from
L1 entry 8000000c320f3063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320f4 (pfn 5555555555555555) from
L1 entry 8000000c320f4063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320f5 (pfn 5555555555555555) from
L1 entry 8000000c320f5063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320f6 (pfn 5555555555555555) from
L1 entry 8000000c320f6063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320f7 (pfn 5555555555555555) from
L1 entry 8000000c320f7063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320f8 (pfn 5555555555555555) from
L1 entry 8000000c320f8063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320f9 (pfn 5555555555555555) from
L1 entry 8000000c320f9063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320fa (pfn 5555555555555555) from
L1 entry 8000000c320fa063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320fb (pfn 5555555555555555) from
L1 entry 8000000c320fb063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320fc (pfn 5555555555555555) from
L1 entry 8000000c320fc063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320fd (pfn 5555555555555555) from
L1 entry 8000000c320fd063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320fe (pfn 5555555555555555) from
L1 entry 8000000c320fe063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320ff (pfn 5555555555555555) from
L1 entry 8000000c320ff063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32110 (pfn 5555555555555555) from
L1 entry 8000000c32110063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32111 (pfn 5555555555555555) from
L1 entry 8000000c32111063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32112 (pfn 5555555555555555) from
L1 entry 8000000c32112063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32113 (pfn 5555555555555555) from
L1 entry 8000000c32113063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32114 (pfn 5555555555555555) from
L1 entry 8000000c32114063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32115 (pfn 5555555555555555) from
L1 entry 8000000c32115063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32116 (pfn 5555555555555555) from
L1 entry 8000000c32116063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32117 (pfn 5555555555555555) from
L1 entry 8000000c32117063 for l1e_owner=0, pg_owner=0
(XEN) ../physdev.c:171: dom0: wrong map_pirq type 3

-- 
William

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 19 13:53:16 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Sep 2012 13: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 1TEKi4-00075z-Dz; Wed, 19 Sep 2012 13:53:00 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wdauchy@gmail.com>) id 1TEKi3-00075U-NA
	for xen-devel@lists.xensource.com; Wed, 19 Sep 2012 13:52:59 +0000
X-Env-Sender: wdauchy@gmail.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1348062758!10203394!1
X-Originating-IP: [209.85.160.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6100 invoked from network); 19 Sep 2012 13:52:40 -0000
Received: from mail-pb0-f43.google.com (HELO mail-pb0-f43.google.com)
	(209.85.160.43)
	by server-16.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Sep 2012 13:52:40 -0000
Received: by pbbrq2 with SMTP id rq2so3239742pbb.30
	for <xen-devel@lists.xensource.com>;
	Wed, 19 Sep 2012 06:52:38 -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=MtU7LKytreVyQxvcPVga70wyMIex0eXG4a9Y0Vf1Cp0=;
	b=lrB/EUF+NOWkz1cLe+ZBUl99LGhWC1XQMbZMTXkh+25IsgKk98T91ZIbdwZFEY79S8
	v/Yloi/gjT4hJ4n4IHNls9u7T+x3FEw1pD+tE8VnEWFjJ3ha3RyKZw4Cbqb8dk8amToB
	OEb0fgidi+anNwDUp0fgokgZN7WL2aLW3PTNq0KGJAYYRKQDlqIVFRDIs1xn0a5/C/df
	q61kpGXgidCx8K2JAgIiA2ndpFcD+5hC0i8Q3XOWcPSOPZVmq+1kRtvgOfIjBsVK5GFQ
	p1O5SsZUtMkcWmioT4fmEdjE0yiJ+/6VQyLuv/NXyT24/eFMTLW/0+Bt1WjReqzSzA3v
	Qtag==
Received: by 10.66.81.66 with SMTP id y2mr6998415pax.62.1348062758501; Wed, 19
	Sep 2012 06:52:38 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.68.135.42 with HTTP; Wed, 19 Sep 2012 06:52:15 -0700 (PDT)
In-Reply-To: <5058C25A.1090602@citrix.com>
References: <CAJ75kXZm-BqWdL2O41XkSE1VCdd4ruW=+CqDmR1b3=701RnXmw@mail.gmail.com>
	<5058C25A.1090602@citrix.com>
From: William Dauchy <wdauchy@gmail.com>
Date: Wed, 19 Sep 2012 15:52:15 +0200
Message-ID: <CAJ75kXbn51597XWsZjO_7HbWi6-SXBV41EgD3hwB3nEnBTQVFg@mail.gmail.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] Error getting mfn
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Sep 18, 2012 at 8:50 PM, Andrew Cooper
<andrew.cooper3@citrix.com> wrote:
> Are you compiling as uniprocessor rather than SMP?  This reminds me of a
> bug XenServer came across where a 32bit uniprocessor build would use two
> 32bit writes to change PTEs, and issue the two writes in the wrong
> order, triggering this error.

No, I'm using SMP.

-- 
William

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 19 13:53:16 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Sep 2012 13: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 1TEKi4-00075z-Dz; Wed, 19 Sep 2012 13:53:00 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wdauchy@gmail.com>) id 1TEKi3-00075U-NA
	for xen-devel@lists.xensource.com; Wed, 19 Sep 2012 13:52:59 +0000
X-Env-Sender: wdauchy@gmail.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1348062758!10203394!1
X-Originating-IP: [209.85.160.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6100 invoked from network); 19 Sep 2012 13:52:40 -0000
Received: from mail-pb0-f43.google.com (HELO mail-pb0-f43.google.com)
	(209.85.160.43)
	by server-16.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Sep 2012 13:52:40 -0000
Received: by pbbrq2 with SMTP id rq2so3239742pbb.30
	for <xen-devel@lists.xensource.com>;
	Wed, 19 Sep 2012 06:52:38 -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=MtU7LKytreVyQxvcPVga70wyMIex0eXG4a9Y0Vf1Cp0=;
	b=lrB/EUF+NOWkz1cLe+ZBUl99LGhWC1XQMbZMTXkh+25IsgKk98T91ZIbdwZFEY79S8
	v/Yloi/gjT4hJ4n4IHNls9u7T+x3FEw1pD+tE8VnEWFjJ3ha3RyKZw4Cbqb8dk8amToB
	OEb0fgidi+anNwDUp0fgokgZN7WL2aLW3PTNq0KGJAYYRKQDlqIVFRDIs1xn0a5/C/df
	q61kpGXgidCx8K2JAgIiA2ndpFcD+5hC0i8Q3XOWcPSOPZVmq+1kRtvgOfIjBsVK5GFQ
	p1O5SsZUtMkcWmioT4fmEdjE0yiJ+/6VQyLuv/NXyT24/eFMTLW/0+Bt1WjReqzSzA3v
	Qtag==
Received: by 10.66.81.66 with SMTP id y2mr6998415pax.62.1348062758501; Wed, 19
	Sep 2012 06:52:38 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.68.135.42 with HTTP; Wed, 19 Sep 2012 06:52:15 -0700 (PDT)
In-Reply-To: <5058C25A.1090602@citrix.com>
References: <CAJ75kXZm-BqWdL2O41XkSE1VCdd4ruW=+CqDmR1b3=701RnXmw@mail.gmail.com>
	<5058C25A.1090602@citrix.com>
From: William Dauchy <wdauchy@gmail.com>
Date: Wed, 19 Sep 2012 15:52:15 +0200
Message-ID: <CAJ75kXbn51597XWsZjO_7HbWi6-SXBV41EgD3hwB3nEnBTQVFg@mail.gmail.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] Error getting mfn
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Sep 18, 2012 at 8:50 PM, Andrew Cooper
<andrew.cooper3@citrix.com> wrote:
> Are you compiling as uniprocessor rather than SMP?  This reminds me of a
> bug XenServer came across where a 32bit uniprocessor build would use two
> 32bit writes to change PTEs, and issue the two writes in the wrong
> order, triggering this error.

No, I'm using SMP.

-- 
William

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 19 13:57:49 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Sep 2012 13:57:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TEKmW-0007Nq-8S; Wed, 19 Sep 2012 13:57:36 +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 1TEKmV-0007Nb-6T
	for xen-devel@lists.xensource.com; Wed, 19 Sep 2012 13:57:35 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1348062966!11037943!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTAxNzU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18774 invoked from network); 19 Sep 2012 13:56:07 -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;
	19 Sep 2012 13:56:07 -0000
X-IronPort-AV: E=Sophos;i="4.80,447,1344211200"; d="scan'208";a="14632682"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Sep 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.279.1;
	Wed, 19 Sep 2012 14:55:14 +0100
Message-ID: <1348062913.14977.132.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Date: Wed, 19 Sep 2012 14:55:13 +0100
In-Reply-To: <alpine.DEB.2.02.1209191408460.29232@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1208221159560.15568@kaball.uk.xensource.com>
	<1345633688-31684-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<1347627587.24226.192.camel@zakaz.uk.xensource.com>
	<20120914160727.1ff41de2@mantra.us.oracle.com>
	<alpine.DEB.2.02.1209171153350.29232@kaball.uk.xensource.com>
	<1348059789.14977.119.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.02.1209191408460.29232@kaball.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-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 v4 1/6] xen: improve changes to
	xen_add_to_physmap
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> >          mfn = maddr >> PAGE_SHIFT;
> > -	if (x && x--) {
> > -            printk("Mapping dom%d mfn 0x%lx to dom%d mfn 0x%"PRIpaddr"\n",
> > -                   od->domain_id, mfn, d->domain_id, xatp->gpfn);
> > -        }
> 
> why remove the printk here?

It's debug junk which crept in from somewhere else, I'll clean it up in
the original patch which added it before posting this stuff properly.

> > diff --git a/xen/include/public/memory.h b/xen/include/public/memory.h
> > index b2adfbe..1cc7a80 100644
> > --- a/xen/include/public/memory.h
> > +++ b/xen/include/public/memory.h
> > @@ -198,6 +198,15 @@ struct xen_machphys_mapping {
> >  typedef struct xen_machphys_mapping xen_machphys_mapping_t;
> >  DEFINE_XEN_GUEST_HANDLE(xen_machphys_mapping_t);
> >  
> > +/* Source mapping space. */
> > +/* ` enum phys_map_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 dom */
> > +/* ` } */
> >  /*
> >   * Sets the GPFN at which a particular page appears in the specified guest's
> >   * pseudophysical address space.
> > @@ -211,26 +220,40 @@ struct xen_add_to_physmap {
> >      /* Number of pages to go through for gmfn_range */
> >      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 */
> > -#define XENMAPSPACE_gmfn_foreign 4 /* GMFN from another guest */
> > -    uint16_t space;
> > +    uint16_t space; /* => enum phys_map_space */
> >      domid_t foreign_domid; /* IFF gmfn_foreign */
> 
> I don't like very much that you have a uint16_t in the struct that
> actually represents a union

Actually, the foreign_domid can go from here, since it is entirely
replaced with the xatp_range stuff. IOW XENMAPSPACE_gmfn_foreign will
only be valid with the add_to_physmap_range version of this interface.

This is just a left over (and it's convenient during the transition
period).

> 
> 
> >  #define XENMAPIDX_grant_table_status 0x80000000
> >  
> > -    /* Index into source mapping space. */
> > +    /* Index into space being mapped. */
> >      xen_ulong_t idx;
> >  
> > -    /* GPFN where the source mapping page should appear. */
> > +    /* GPFN in domid where the source mapping page should appear. */
> >      xen_pfn_t     gpfn;
> >  };
> >  typedef struct xen_add_to_physmap xen_add_to_physmap_t;
> >  DEFINE_XEN_GUEST_HANDLE(xen_add_to_physmap_t);
> >  
> > +/* A batched version of add_to_physmap. */
> > +#define XENMEM_add_to_physmap_range 23
> > +struct xen_add_to_physmap_range {
> > +    /* Which domain to change the mapping for. */
> > +    domid_t domid;
> > +    uint16_t space; /* => enum phys_map_space */
> > +
> > +    /* Number of pages to go through */
> > +    uint16_t size;
> > +    domid_t foreign_domid; /* IFF gmfn_foreign */
> > +
> > +    /* Indexes into space being mapped. */
> > +    XEN_GUEST_HANDLE(xen_ulong_t) idxs;
> > +
> > +    /* GPFN in domdwhere the source mapping page should appear. */
>                      ^ domid where

Thanks.

> 
> > +    XEN_GUEST_HANDLE(xen_pfn_t) gpfns;
> > +};
> > +typedef struct xen_add_to_physmap_range xen_add_to_physmap_range_t;
> > +DEFINE_XEN_GUEST_HANDLE(xen_add_to_physmap_range_t);
> > +
> >  /*
> >   * Unmaps the page appearing at a particular GPFN from the specified guest's
> >   * pseudophysical address space.
> > diff --git a/xen/include/public/xen.h b/xen/include/public/xen.h
> > index b2f6c50..9425520 100644
> > --- a/xen/include/public/xen.h
> > +++ b/xen/include/public/xen.h
> > @@ -51,6 +51,7 @@ DEFINE_XEN_GUEST_HANDLE(void);
> >  
> >  DEFINE_XEN_GUEST_HANDLE(uint64_t);
> >  DEFINE_XEN_GUEST_HANDLE(xen_pfn_t);
> > +DEFINE_XEN_GUEST_HANDLE(xen_ulong_t);
> >  #endif
> 
> You shouldn't need that: xen_ulong_t is already defined in arch-arm.h
> (and arch-x86/xen.h)

The type is, but the guest handle is not.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 19 13:57:49 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Sep 2012 13:57:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TEKmW-0007Nq-8S; Wed, 19 Sep 2012 13:57:36 +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 1TEKmV-0007Nb-6T
	for xen-devel@lists.xensource.com; Wed, 19 Sep 2012 13:57:35 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1348062966!11037943!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTAxNzU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18774 invoked from network); 19 Sep 2012 13:56:07 -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;
	19 Sep 2012 13:56:07 -0000
X-IronPort-AV: E=Sophos;i="4.80,447,1344211200"; d="scan'208";a="14632682"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Sep 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.279.1;
	Wed, 19 Sep 2012 14:55:14 +0100
Message-ID: <1348062913.14977.132.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Date: Wed, 19 Sep 2012 14:55:13 +0100
In-Reply-To: <alpine.DEB.2.02.1209191408460.29232@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1208221159560.15568@kaball.uk.xensource.com>
	<1345633688-31684-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<1347627587.24226.192.camel@zakaz.uk.xensource.com>
	<20120914160727.1ff41de2@mantra.us.oracle.com>
	<alpine.DEB.2.02.1209171153350.29232@kaball.uk.xensource.com>
	<1348059789.14977.119.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.02.1209191408460.29232@kaball.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-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 v4 1/6] xen: improve changes to
	xen_add_to_physmap
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> >          mfn = maddr >> PAGE_SHIFT;
> > -	if (x && x--) {
> > -            printk("Mapping dom%d mfn 0x%lx to dom%d mfn 0x%"PRIpaddr"\n",
> > -                   od->domain_id, mfn, d->domain_id, xatp->gpfn);
> > -        }
> 
> why remove the printk here?

It's debug junk which crept in from somewhere else, I'll clean it up in
the original patch which added it before posting this stuff properly.

> > diff --git a/xen/include/public/memory.h b/xen/include/public/memory.h
> > index b2adfbe..1cc7a80 100644
> > --- a/xen/include/public/memory.h
> > +++ b/xen/include/public/memory.h
> > @@ -198,6 +198,15 @@ struct xen_machphys_mapping {
> >  typedef struct xen_machphys_mapping xen_machphys_mapping_t;
> >  DEFINE_XEN_GUEST_HANDLE(xen_machphys_mapping_t);
> >  
> > +/* Source mapping space. */
> > +/* ` enum phys_map_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 dom */
> > +/* ` } */
> >  /*
> >   * Sets the GPFN at which a particular page appears in the specified guest's
> >   * pseudophysical address space.
> > @@ -211,26 +220,40 @@ struct xen_add_to_physmap {
> >      /* Number of pages to go through for gmfn_range */
> >      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 */
> > -#define XENMAPSPACE_gmfn_foreign 4 /* GMFN from another guest */
> > -    uint16_t space;
> > +    uint16_t space; /* => enum phys_map_space */
> >      domid_t foreign_domid; /* IFF gmfn_foreign */
> 
> I don't like very much that you have a uint16_t in the struct that
> actually represents a union

Actually, the foreign_domid can go from here, since it is entirely
replaced with the xatp_range stuff. IOW XENMAPSPACE_gmfn_foreign will
only be valid with the add_to_physmap_range version of this interface.

This is just a left over (and it's convenient during the transition
period).

> 
> 
> >  #define XENMAPIDX_grant_table_status 0x80000000
> >  
> > -    /* Index into source mapping space. */
> > +    /* Index into space being mapped. */
> >      xen_ulong_t idx;
> >  
> > -    /* GPFN where the source mapping page should appear. */
> > +    /* GPFN in domid where the source mapping page should appear. */
> >      xen_pfn_t     gpfn;
> >  };
> >  typedef struct xen_add_to_physmap xen_add_to_physmap_t;
> >  DEFINE_XEN_GUEST_HANDLE(xen_add_to_physmap_t);
> >  
> > +/* A batched version of add_to_physmap. */
> > +#define XENMEM_add_to_physmap_range 23
> > +struct xen_add_to_physmap_range {
> > +    /* Which domain to change the mapping for. */
> > +    domid_t domid;
> > +    uint16_t space; /* => enum phys_map_space */
> > +
> > +    /* Number of pages to go through */
> > +    uint16_t size;
> > +    domid_t foreign_domid; /* IFF gmfn_foreign */
> > +
> > +    /* Indexes into space being mapped. */
> > +    XEN_GUEST_HANDLE(xen_ulong_t) idxs;
> > +
> > +    /* GPFN in domdwhere the source mapping page should appear. */
>                      ^ domid where

Thanks.

> 
> > +    XEN_GUEST_HANDLE(xen_pfn_t) gpfns;
> > +};
> > +typedef struct xen_add_to_physmap_range xen_add_to_physmap_range_t;
> > +DEFINE_XEN_GUEST_HANDLE(xen_add_to_physmap_range_t);
> > +
> >  /*
> >   * Unmaps the page appearing at a particular GPFN from the specified guest's
> >   * pseudophysical address space.
> > diff --git a/xen/include/public/xen.h b/xen/include/public/xen.h
> > index b2f6c50..9425520 100644
> > --- a/xen/include/public/xen.h
> > +++ b/xen/include/public/xen.h
> > @@ -51,6 +51,7 @@ DEFINE_XEN_GUEST_HANDLE(void);
> >  
> >  DEFINE_XEN_GUEST_HANDLE(uint64_t);
> >  DEFINE_XEN_GUEST_HANDLE(xen_pfn_t);
> > +DEFINE_XEN_GUEST_HANDLE(xen_ulong_t);
> >  #endif
> 
> You shouldn't need that: xen_ulong_t is already defined in arch-arm.h
> (and arch-x86/xen.h)

The type is, but the guest handle is not.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 19 14:06:38 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Sep 2012 14:06:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TEKuv-0007hT-8V; Wed, 19 Sep 2012 14:06:17 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <matthew.fioravante@jhuapl.edu>) id 1TEKut-0007hO-Kf
	for xen-devel@lists.xensource.com; Wed, 19 Sep 2012 14:06:16 +0000
Received: from [85.158.139.83:17495] by server-10.bemta-5.messagelabs.com id
	32/44-10969-651D9505; Wed, 19 Sep 2012 14:06:14 +0000
X-Env-Sender: matthew.fioravante@jhuapl.edu
X-Msg-Ref: server-16.tower-182.messagelabs.com!1348063569!23880444!1
X-Originating-IP: [128.244.251.36]
X-SpamReason: No, hits=0.0 required=7.0 tests=UNPARSEABLE_RELAY
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3099 invoked from network); 19 Sep 2012 14:06:10 -0000
Received: from pilot.jhuapl.edu (HELO jhuapl.edu) (128.244.251.36)
	by server-16.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 19 Sep 2012 14:06:10 -0000
Received: from ([128.244.207.89])
	by pilot.jhuapl.edu with ESMTP with TLS id 63GHCH1.153209489;
	Wed, 19 Sep 2012 10:06:04 -0400
Message-ID: <5059D100.6030507@jhuapl.edu>
Date: Wed, 19 Sep 2012 10:04:48 -0400
From: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120827 Thunderbird/15.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <5058BA2C.7090804@jhuapl.edu>
	<1348057981.14977.107.camel@zakaz.uk.xensource.com>
In-Reply-To: <1348057981.14977.107.camel@zakaz.uk.xensource.com>
X-Enigmail-Version: 1.4.4
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH xm/xl enhancements for vptm 3/6] add iomem
	option to 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: multipart/mixed; boundary="===============4804813936959707545=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a cryptographically signed message in MIME format.

--===============4804813936959707545==
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms090509070905060800030708"

This is a cryptographically signed message in MIME format.

--------------ms090509070905060800030708
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Sorry I forgot about the allow boolean, and yes its compatible with xm
in terms of how ioport and irq are implemented.

On 09/19/2012 08:33 AM, Ian Campbell wrote:
> On Tue, 2012-09-18 at 19:15 +0100, Matthew Fioravante wrote:
>> This patch adds a new option for xen config files for directly mapping=

>> hardware io memory into a vm.
>>
>> iomem=3D['pagenum,size',..]
>>
>> Where pagenum is the page number and size is the number of page.
>> example (for a tpm:
>> iomem=3D['fed40,5']
> Please can you patch the docs too.
>
> Your implementation seems to also support a third field "allow"?
>
> Did xm/xend have similar functionality? Is this compatible with the
> syntax?
>
> Also this patch is whitespace mangled again I'm afraid (I expect they
> all are so I'll stop mentioning it)
>
>> Signed off by Matthew Fioravante matthew.fioravante@jhuapl.edu
>>
>> diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
>> --- a/tools/libxl/libxl.h
>> +++ b/tools/libxl/libxl.h
>> @@ -477,7 +477,7 @@ typedef struct {
>>      libxl_domain_create_info c_info;
>>      libxl_domain_build_info b_info;
>> =20
>> -    int num_disks, num_vifs, num_pcidevs, num_vfbs, num_vkbs, num_vtp=
ms;
>> +    int num_disks, num_vifs, num_pcidevs, num_vfbs, num_vkbs,
>> num_vtpms, num_iorngs;
>> =20
>>      libxl_device_disk *disks;
>>      libxl_device_nic *vifs;
>> @@ -485,6 +485,7 @@ typedef struct {
>>      libxl_device_vfb *vfbs;
>>      libxl_device_vkb *vkbs;
>>      libxl_device_vtpm *vtpms;
>> +    libxl_iomem_range *iorngs;
>> =20
>>      libxl_action_on_shutdown on_poweroff;
>>      libxl_action_on_shutdown on_reboot;
>> 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
>> @@ -58,6 +58,10 @@ void libxl_domain_config_dispose(libxl_domain_confi=
g
>> *d_config)
>>         libxl_device_vtpm_dispose(&d_config->vtpms[i]);
>>      free(d_config->vtpms);
>> =20
>> +    for (i=3D0; i<d_config->num_iorngs; i++)
>> +       libxl_iomem_range_dispose(&d_config->iorngs[i]);
>> +    free(d_config->iorngs);
>> +
>>      libxl_domain_create_info_dispose(&d_config->c_info);
>>      libxl_domain_build_info_dispose(&d_config->b_info);
>>  }
>> @@ -718,6 +722,15 @@ static void domcreate_bootloader_done(libxl__egc =
*egc,
>> =20
>>      store_libxl_entry(gc, domid, &d_config->b_info);
>> =20
>> +    for (i =3D 0; i < d_config->num_iorngs; i++) {
>> +        ret =3D xc_domain_iomem_permission(ctx->xch, domid,
>> d_config->iorngs[i].start, d_config->iorngs[i].length,
>> d_config->iorngs[i].allow);
>> +        if (ret) {
>> +            LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
>> +                       "cannot add iomem range %d to domain: %d", i, =
ret);
>> +            ret =3D ERROR_FAIL;
>> +            goto error_out;
>> +        }
>> +    }
>>      for (i =3D 0; i < d_config->num_disks; i++) {
>>          ret =3D libxl_device_disk_add(ctx, domid, &d_config->disks[i]=
);
>>          if (ret) {
>> 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
>> @@ -317,6 +317,12 @@ libxl_domain_build_info =3D Struct("domain_build_=
info",[
>>      ], dir=3DDIR_IN
>>  )
>> =20
>> +libxl_iomem_range =3D Struct("iomem_range", [
>> +    ("start", uint64),
>> +    ("length", uint64),
>> +    ("allow", bool),
>> +]);
>> +
>>  libxl_device_vfb =3D Struct("device_vfb", [
>>      ("backend_domid", libxl_domid),
>>      ("devid",         libxl_devid),
>> 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
>> @@ -560,7 +560,7 @@ static void parse_config_data(const char *config_s=
ource,
>>      const char *buf;
>>      long l;
>>      XLU_Config *config;
>> -    XLU_ConfigList *cpus, *vbds, *nics, *pcis, *cvfbs, *cpuids, *vtpm=
s;
>> +    XLU_ConfigList *cpus, *vbds, *nics, *pcis, *cvfbs, *cpuids, *vtpm=
s,
>> *iomems;
>>      int pci_power_mgmt =3D 0;
>>      int pci_msitranslate =3D 1;
>>      int pci_permissive =3D 0;
>> @@ -1145,6 +1145,42 @@ skip_vfb:
>>              libxl_defbool_set(&b_info->u.pv.e820_host, true);
>>      }
>> =20
>> +    if(!xlu_cfg_get_list(config, "iomem", &iomems, 0, 0)) {
>> +       int i;
>> +       for(i =3D0; (buf =3D xlu_cfg_get_listitem(iomems, i)) !=3D NUL=
L; ++i) {
>> +          libxl_iomem_range *iorng;
>> +          char* buf2 =3D strdup(buf);
>> +          char *st, *len, *al;
>> +
>> +          d_config->iorngs =3D realloc(d_config->iorngs,
>> sizeof(libxl_iomem_range) * (d_config->num_iorngs + 1));
>> +          iorng =3D d_config->iorngs + d_config->num_iorngs;
>> +
>> +          libxl_iomem_range_init(iorng);
>> +
>> +          st =3D strtok(buf2, ",");
>> +          len =3D strtok(NULL, ",");
>> +          al =3D strtok(NULL, ",");
>> +
>> +          if(st =3D=3D NULL || len =3D=3D NULL ||
>> +                sscanf(st, "%" PRIx64, &iorng->start) !=3D 1 ||
>> +                sscanf(len, "%" PRIu64, &iorng->length) !=3D 1 ||
>> +                (al !=3D NULL && ((al[0] !=3D '1' && al[0] !=3D '0') =
|| al[1]
>> !=3D '\0'))
>> +            ) {
>> +             fprintf(stderr, "Malformed iomem specification!\n");
>> +             free(buf2);
>> +             exit(1);
>> +          }
>> +          if(al !=3D NULL) {
>> +             iorng->allow =3D al[0] - '0';
>> +          } else {
>> +             iorng->allow =3D 1;
>> +          }
>> +
>> +          free(buf2);
>> +          d_config->num_iorngs++;
>> +       }
>> +    }
>> +
>>      switch (xlu_cfg_get_list(config, "cpuid", &cpuids, 0, 1)) {
>>      case 0:
>>          {
>



--------------ms090509070905060800030708
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIDyjCC
A8YwggMvoAMCAQICBD/xyf0wDQYJKoZIhvcNAQEFBQAwLzELMAkGA1UEBhMCVVMxDzANBgNV
BAoTBkpIVUFQTDEPMA0GA1UECxMGQklTRENBMB4XDTEwMDYxMTE4MjIwNloXDTEzMDYxMTE4
NTIwNlowZjELMAkGA1UEBhMCVVMxDzANBgNVBAoTBkpIVUFQTDEPMA0GA1UECxMGUGVvcGxl
MTUwFgYDVQQLEw9WUE5Hcm91cC1CSVNEQ0EwGwYDVQQDExRNYXR0aGV3IEUgRmlvcmF2YW50
ZTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAnpbwVSP6o1Nb5lcW7dd3yTo9iBJdi7qz
4nANOMFPK7JOy5npKN1iiousl28U/scUJES55gPwAWYJK3uVyQAsA4adgDKi5DoD1UHDQEwp
bY7iHLJeq0NPr4BqYNqnCFPbE6HC8zSJrr4qKn+gVUQT39SIFqdiIPJwZL8FYTRQ/zsCAwEA
AaOCAbYwggGyMAsGA1UdDwQEAwIHgDArBgNVHRAEJDAigA8yMDEwMDYxMTE4MjIwNlqBDzIw
MTIwNzE3MjI1MjA2WjAbBg0rBgEEAbMlCwMBAQEBBAoWCGZpb3JhbWUxMBsGDSsGAQQBsyUL
AwEBAQIEChIIMDAxMDQyNjEwWAYJYIZIAYb6ax4BBEsMSVRoZSBwcml2YXRlIGtleSBjb3Jy
ZXNwb25kaW5nIHRvIHRoaXMgY2VydGlmaWNhdGUgbWF5IGhhdmUgYmVlbiBleHBvcnRlZC4w
KAYDVR0RBCEwH4EdTWF0dGhldy5GaW9yYXZhbnRlQGpodWFwbC5lZHUwUgYDVR0fBEswSTBH
oEWgQ6RBMD8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJU0RD
QTEOMAwGA1UEAxMFQ1JMNTYwHwYDVR0jBBgwFoAUCDUpmxH52EU2CyWmF2EJMB1yqeswHQYD
VR0OBBYEFO6LYxg6r9wHZ+zdQtBHn1dZ/YTNMAkGA1UdEwQCMAAwGQYJKoZIhvZ9B0EABAww
ChsEVjcuMQMCBLAwDQYJKoZIhvcNAQEFBQADgYEAJO9HQh4YNChVLzuZqK5ARJARD8JoujGZ
fdo75quvg2jXFQe2sEjvLnxJZgm/pv8fdZakq48CWwjYHKuvIp7sDjTEsQfo+y7SpN/N2NvJ
WU5SqfK1VgYtNLRRoGJUB5Q1aZ+Dg95g3kqpyfpUMISJL8IKVLtJVfN4fggFVUYZ9wwxggGr
MIIBpwIBATA3MC8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJ
U0RDQQIEP/HJ/TAJBgUrDgMCGgUAoIHLMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ
KoZIhvcNAQkFMQ8XDTEyMDkxOTE0MDQ0OFowIwYJKoZIhvcNAQkEMRYEFNQOaWdLqNLIUnLU
2TUbEmSH9lBBMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAK
BggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI
KoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEgYAM0paxuUT6XVKQ4nPc4x6rX1BubwR9BydJ
IZYgepFq8l7n1vXQwSNbxxA8I8Hkn5SW1vy7JbsYc1LtBoRrRMDjHa+03etZQQNqxJcINnYM
tC2Dm2OtUGx3dYYiV2hH/iaedFdXxul8sigiBzLRyS03Tjxbpx7Th6+AGSprCC7WjAAAAAAA
AA==
--------------ms090509070905060800030708--


--===============4804813936959707545==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============4804813936959707545==--


From xen-devel-bounces@lists.xen.org Wed Sep 19 14:06:38 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Sep 2012 14:06:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TEKuv-0007hT-8V; Wed, 19 Sep 2012 14:06:17 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <matthew.fioravante@jhuapl.edu>) id 1TEKut-0007hO-Kf
	for xen-devel@lists.xensource.com; Wed, 19 Sep 2012 14:06:16 +0000
Received: from [85.158.139.83:17495] by server-10.bemta-5.messagelabs.com id
	32/44-10969-651D9505; Wed, 19 Sep 2012 14:06:14 +0000
X-Env-Sender: matthew.fioravante@jhuapl.edu
X-Msg-Ref: server-16.tower-182.messagelabs.com!1348063569!23880444!1
X-Originating-IP: [128.244.251.36]
X-SpamReason: No, hits=0.0 required=7.0 tests=UNPARSEABLE_RELAY
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3099 invoked from network); 19 Sep 2012 14:06:10 -0000
Received: from pilot.jhuapl.edu (HELO jhuapl.edu) (128.244.251.36)
	by server-16.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 19 Sep 2012 14:06:10 -0000
Received: from ([128.244.207.89])
	by pilot.jhuapl.edu with ESMTP with TLS id 63GHCH1.153209489;
	Wed, 19 Sep 2012 10:06:04 -0400
Message-ID: <5059D100.6030507@jhuapl.edu>
Date: Wed, 19 Sep 2012 10:04:48 -0400
From: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120827 Thunderbird/15.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <5058BA2C.7090804@jhuapl.edu>
	<1348057981.14977.107.camel@zakaz.uk.xensource.com>
In-Reply-To: <1348057981.14977.107.camel@zakaz.uk.xensource.com>
X-Enigmail-Version: 1.4.4
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH xm/xl enhancements for vptm 3/6] add iomem
	option to 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: multipart/mixed; boundary="===============4804813936959707545=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a cryptographically signed message in MIME format.

--===============4804813936959707545==
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms090509070905060800030708"

This is a cryptographically signed message in MIME format.

--------------ms090509070905060800030708
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Sorry I forgot about the allow boolean, and yes its compatible with xm
in terms of how ioport and irq are implemented.

On 09/19/2012 08:33 AM, Ian Campbell wrote:
> On Tue, 2012-09-18 at 19:15 +0100, Matthew Fioravante wrote:
>> This patch adds a new option for xen config files for directly mapping=

>> hardware io memory into a vm.
>>
>> iomem=3D['pagenum,size',..]
>>
>> Where pagenum is the page number and size is the number of page.
>> example (for a tpm:
>> iomem=3D['fed40,5']
> Please can you patch the docs too.
>
> Your implementation seems to also support a third field "allow"?
>
> Did xm/xend have similar functionality? Is this compatible with the
> syntax?
>
> Also this patch is whitespace mangled again I'm afraid (I expect they
> all are so I'll stop mentioning it)
>
>> Signed off by Matthew Fioravante matthew.fioravante@jhuapl.edu
>>
>> diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
>> --- a/tools/libxl/libxl.h
>> +++ b/tools/libxl/libxl.h
>> @@ -477,7 +477,7 @@ typedef struct {
>>      libxl_domain_create_info c_info;
>>      libxl_domain_build_info b_info;
>> =20
>> -    int num_disks, num_vifs, num_pcidevs, num_vfbs, num_vkbs, num_vtp=
ms;
>> +    int num_disks, num_vifs, num_pcidevs, num_vfbs, num_vkbs,
>> num_vtpms, num_iorngs;
>> =20
>>      libxl_device_disk *disks;
>>      libxl_device_nic *vifs;
>> @@ -485,6 +485,7 @@ typedef struct {
>>      libxl_device_vfb *vfbs;
>>      libxl_device_vkb *vkbs;
>>      libxl_device_vtpm *vtpms;
>> +    libxl_iomem_range *iorngs;
>> =20
>>      libxl_action_on_shutdown on_poweroff;
>>      libxl_action_on_shutdown on_reboot;
>> 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
>> @@ -58,6 +58,10 @@ void libxl_domain_config_dispose(libxl_domain_confi=
g
>> *d_config)
>>         libxl_device_vtpm_dispose(&d_config->vtpms[i]);
>>      free(d_config->vtpms);
>> =20
>> +    for (i=3D0; i<d_config->num_iorngs; i++)
>> +       libxl_iomem_range_dispose(&d_config->iorngs[i]);
>> +    free(d_config->iorngs);
>> +
>>      libxl_domain_create_info_dispose(&d_config->c_info);
>>      libxl_domain_build_info_dispose(&d_config->b_info);
>>  }
>> @@ -718,6 +722,15 @@ static void domcreate_bootloader_done(libxl__egc =
*egc,
>> =20
>>      store_libxl_entry(gc, domid, &d_config->b_info);
>> =20
>> +    for (i =3D 0; i < d_config->num_iorngs; i++) {
>> +        ret =3D xc_domain_iomem_permission(ctx->xch, domid,
>> d_config->iorngs[i].start, d_config->iorngs[i].length,
>> d_config->iorngs[i].allow);
>> +        if (ret) {
>> +            LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
>> +                       "cannot add iomem range %d to domain: %d", i, =
ret);
>> +            ret =3D ERROR_FAIL;
>> +            goto error_out;
>> +        }
>> +    }
>>      for (i =3D 0; i < d_config->num_disks; i++) {
>>          ret =3D libxl_device_disk_add(ctx, domid, &d_config->disks[i]=
);
>>          if (ret) {
>> 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
>> @@ -317,6 +317,12 @@ libxl_domain_build_info =3D Struct("domain_build_=
info",[
>>      ], dir=3DDIR_IN
>>  )
>> =20
>> +libxl_iomem_range =3D Struct("iomem_range", [
>> +    ("start", uint64),
>> +    ("length", uint64),
>> +    ("allow", bool),
>> +]);
>> +
>>  libxl_device_vfb =3D Struct("device_vfb", [
>>      ("backend_domid", libxl_domid),
>>      ("devid",         libxl_devid),
>> 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
>> @@ -560,7 +560,7 @@ static void parse_config_data(const char *config_s=
ource,
>>      const char *buf;
>>      long l;
>>      XLU_Config *config;
>> -    XLU_ConfigList *cpus, *vbds, *nics, *pcis, *cvfbs, *cpuids, *vtpm=
s;
>> +    XLU_ConfigList *cpus, *vbds, *nics, *pcis, *cvfbs, *cpuids, *vtpm=
s,
>> *iomems;
>>      int pci_power_mgmt =3D 0;
>>      int pci_msitranslate =3D 1;
>>      int pci_permissive =3D 0;
>> @@ -1145,6 +1145,42 @@ skip_vfb:
>>              libxl_defbool_set(&b_info->u.pv.e820_host, true);
>>      }
>> =20
>> +    if(!xlu_cfg_get_list(config, "iomem", &iomems, 0, 0)) {
>> +       int i;
>> +       for(i =3D0; (buf =3D xlu_cfg_get_listitem(iomems, i)) !=3D NUL=
L; ++i) {
>> +          libxl_iomem_range *iorng;
>> +          char* buf2 =3D strdup(buf);
>> +          char *st, *len, *al;
>> +
>> +          d_config->iorngs =3D realloc(d_config->iorngs,
>> sizeof(libxl_iomem_range) * (d_config->num_iorngs + 1));
>> +          iorng =3D d_config->iorngs + d_config->num_iorngs;
>> +
>> +          libxl_iomem_range_init(iorng);
>> +
>> +          st =3D strtok(buf2, ",");
>> +          len =3D strtok(NULL, ",");
>> +          al =3D strtok(NULL, ",");
>> +
>> +          if(st =3D=3D NULL || len =3D=3D NULL ||
>> +                sscanf(st, "%" PRIx64, &iorng->start) !=3D 1 ||
>> +                sscanf(len, "%" PRIu64, &iorng->length) !=3D 1 ||
>> +                (al !=3D NULL && ((al[0] !=3D '1' && al[0] !=3D '0') =
|| al[1]
>> !=3D '\0'))
>> +            ) {
>> +             fprintf(stderr, "Malformed iomem specification!\n");
>> +             free(buf2);
>> +             exit(1);
>> +          }
>> +          if(al !=3D NULL) {
>> +             iorng->allow =3D al[0] - '0';
>> +          } else {
>> +             iorng->allow =3D 1;
>> +          }
>> +
>> +          free(buf2);
>> +          d_config->num_iorngs++;
>> +       }
>> +    }
>> +
>>      switch (xlu_cfg_get_list(config, "cpuid", &cpuids, 0, 1)) {
>>      case 0:
>>          {
>



--------------ms090509070905060800030708
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIDyjCC
A8YwggMvoAMCAQICBD/xyf0wDQYJKoZIhvcNAQEFBQAwLzELMAkGA1UEBhMCVVMxDzANBgNV
BAoTBkpIVUFQTDEPMA0GA1UECxMGQklTRENBMB4XDTEwMDYxMTE4MjIwNloXDTEzMDYxMTE4
NTIwNlowZjELMAkGA1UEBhMCVVMxDzANBgNVBAoTBkpIVUFQTDEPMA0GA1UECxMGUGVvcGxl
MTUwFgYDVQQLEw9WUE5Hcm91cC1CSVNEQ0EwGwYDVQQDExRNYXR0aGV3IEUgRmlvcmF2YW50
ZTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAnpbwVSP6o1Nb5lcW7dd3yTo9iBJdi7qz
4nANOMFPK7JOy5npKN1iiousl28U/scUJES55gPwAWYJK3uVyQAsA4adgDKi5DoD1UHDQEwp
bY7iHLJeq0NPr4BqYNqnCFPbE6HC8zSJrr4qKn+gVUQT39SIFqdiIPJwZL8FYTRQ/zsCAwEA
AaOCAbYwggGyMAsGA1UdDwQEAwIHgDArBgNVHRAEJDAigA8yMDEwMDYxMTE4MjIwNlqBDzIw
MTIwNzE3MjI1MjA2WjAbBg0rBgEEAbMlCwMBAQEBBAoWCGZpb3JhbWUxMBsGDSsGAQQBsyUL
AwEBAQIEChIIMDAxMDQyNjEwWAYJYIZIAYb6ax4BBEsMSVRoZSBwcml2YXRlIGtleSBjb3Jy
ZXNwb25kaW5nIHRvIHRoaXMgY2VydGlmaWNhdGUgbWF5IGhhdmUgYmVlbiBleHBvcnRlZC4w
KAYDVR0RBCEwH4EdTWF0dGhldy5GaW9yYXZhbnRlQGpodWFwbC5lZHUwUgYDVR0fBEswSTBH
oEWgQ6RBMD8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJU0RD
QTEOMAwGA1UEAxMFQ1JMNTYwHwYDVR0jBBgwFoAUCDUpmxH52EU2CyWmF2EJMB1yqeswHQYD
VR0OBBYEFO6LYxg6r9wHZ+zdQtBHn1dZ/YTNMAkGA1UdEwQCMAAwGQYJKoZIhvZ9B0EABAww
ChsEVjcuMQMCBLAwDQYJKoZIhvcNAQEFBQADgYEAJO9HQh4YNChVLzuZqK5ARJARD8JoujGZ
fdo75quvg2jXFQe2sEjvLnxJZgm/pv8fdZakq48CWwjYHKuvIp7sDjTEsQfo+y7SpN/N2NvJ
WU5SqfK1VgYtNLRRoGJUB5Q1aZ+Dg95g3kqpyfpUMISJL8IKVLtJVfN4fggFVUYZ9wwxggGr
MIIBpwIBATA3MC8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJ
U0RDQQIEP/HJ/TAJBgUrDgMCGgUAoIHLMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ
KoZIhvcNAQkFMQ8XDTEyMDkxOTE0MDQ0OFowIwYJKoZIhvcNAQkEMRYEFNQOaWdLqNLIUnLU
2TUbEmSH9lBBMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAK
BggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI
KoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEgYAM0paxuUT6XVKQ4nPc4x6rX1BubwR9BydJ
IZYgepFq8l7n1vXQwSNbxxA8I8Hkn5SW1vy7JbsYc1LtBoRrRMDjHa+03etZQQNqxJcINnYM
tC2Dm2OtUGx3dYYiV2hH/iaedFdXxul8sigiBzLRyS03Tjxbpx7Th6+AGSprCC7WjAAAAAAA
AA==
--------------ms090509070905060800030708--


--===============4804813936959707545==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============4804813936959707545==--


From xen-devel-bounces@lists.xen.org Wed Sep 19 14:07:53 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Sep 2012 14:07:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TEKwE-0007lM-O6; Wed, 19 Sep 2012 14:07:38 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <matthew.fioravante@jhuapl.edu>) id 1TEKwC-0007l9-Af
	for xen-devel@lists.xensource.com; Wed, 19 Sep 2012 14:07:36 +0000
Received: from [85.158.138.51:44577] by server-4.bemta-3.messagelabs.com id
	7F/FC-24831-7A1D9505; Wed, 19 Sep 2012 14:07:35 +0000
X-Env-Sender: matthew.fioravante@jhuapl.edu
X-Msg-Ref: server-3.tower-174.messagelabs.com!1348063653!23109308!1
X-Originating-IP: [128.244.251.36]
X-SpamReason: No, hits=0.0 required=7.0 tests=UNPARSEABLE_RELAY
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1185 invoked from network); 19 Sep 2012 14:07:34 -0000
Received: from pilot.jhuapl.edu (HELO jhuapl.edu) (128.244.251.36)
	by server-3.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 19 Sep 2012 14:07:34 -0000
Received: from ([128.244.207.89])
	by pilot.jhuapl.edu with ESMTP with TLS id 63GHCH1.153209662;
	Wed, 19 Sep 2012 10:07:28 -0400
Message-ID: <5059D154.3070105@jhuapl.edu>
Date: Wed, 19 Sep 2012 10:06:12 -0400
From: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120827 Thunderbird/15.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <5058BACF.6030903@jhuapl.edu>
	<1348058093.14977.109.camel@zakaz.uk.xensource.com>
In-Reply-To: <1348058093.14977.109.camel@zakaz.uk.xensource.com>
X-Enigmail-Version: 1.4.4
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH xm/xl enhancements for vptm 4/6] xl add irq
	support
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============2343746549721609787=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a cryptographically signed message in MIME format.

--===============2343746549721609787==
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms050102090800020404030102"

This is a cryptographically signed message in MIME format.

--------------ms050102090800020404030102
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

its for explicitly saying to allow or deny. It might be redundant since
the default is just to deny all of the irqs/mem regions. The allow flag
could be excluded.

On 09/19/2012 08:34 AM, Ian Campbell wrote:
> On Tue, 2012-09-18 at 19:17 +0100, Matthew Fioravante wrote:
>> This patch adds support for mapping irqs into virtual machines. The
>> syntax is
>>
>> irq =3D [irqnum,allow]
> Xen 4.2 / unstable already has support for specifying irqs.
>
> What is allow for (I should have asked this for the previous iomem patc=
h
> too)? THe default is deny and listing an irq here means allow, do we
> need to be able to explicitly deny given that?
>
> Ian.
>
>



--------------ms050102090800020404030102
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIDyjCC
A8YwggMvoAMCAQICBD/xyf0wDQYJKoZIhvcNAQEFBQAwLzELMAkGA1UEBhMCVVMxDzANBgNV
BAoTBkpIVUFQTDEPMA0GA1UECxMGQklTRENBMB4XDTEwMDYxMTE4MjIwNloXDTEzMDYxMTE4
NTIwNlowZjELMAkGA1UEBhMCVVMxDzANBgNVBAoTBkpIVUFQTDEPMA0GA1UECxMGUGVvcGxl
MTUwFgYDVQQLEw9WUE5Hcm91cC1CSVNEQ0EwGwYDVQQDExRNYXR0aGV3IEUgRmlvcmF2YW50
ZTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAnpbwVSP6o1Nb5lcW7dd3yTo9iBJdi7qz
4nANOMFPK7JOy5npKN1iiousl28U/scUJES55gPwAWYJK3uVyQAsA4adgDKi5DoD1UHDQEwp
bY7iHLJeq0NPr4BqYNqnCFPbE6HC8zSJrr4qKn+gVUQT39SIFqdiIPJwZL8FYTRQ/zsCAwEA
AaOCAbYwggGyMAsGA1UdDwQEAwIHgDArBgNVHRAEJDAigA8yMDEwMDYxMTE4MjIwNlqBDzIw
MTIwNzE3MjI1MjA2WjAbBg0rBgEEAbMlCwMBAQEBBAoWCGZpb3JhbWUxMBsGDSsGAQQBsyUL
AwEBAQIEChIIMDAxMDQyNjEwWAYJYIZIAYb6ax4BBEsMSVRoZSBwcml2YXRlIGtleSBjb3Jy
ZXNwb25kaW5nIHRvIHRoaXMgY2VydGlmaWNhdGUgbWF5IGhhdmUgYmVlbiBleHBvcnRlZC4w
KAYDVR0RBCEwH4EdTWF0dGhldy5GaW9yYXZhbnRlQGpodWFwbC5lZHUwUgYDVR0fBEswSTBH
oEWgQ6RBMD8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJU0RD
QTEOMAwGA1UEAxMFQ1JMNTYwHwYDVR0jBBgwFoAUCDUpmxH52EU2CyWmF2EJMB1yqeswHQYD
VR0OBBYEFO6LYxg6r9wHZ+zdQtBHn1dZ/YTNMAkGA1UdEwQCMAAwGQYJKoZIhvZ9B0EABAww
ChsEVjcuMQMCBLAwDQYJKoZIhvcNAQEFBQADgYEAJO9HQh4YNChVLzuZqK5ARJARD8JoujGZ
fdo75quvg2jXFQe2sEjvLnxJZgm/pv8fdZakq48CWwjYHKuvIp7sDjTEsQfo+y7SpN/N2NvJ
WU5SqfK1VgYtNLRRoGJUB5Q1aZ+Dg95g3kqpyfpUMISJL8IKVLtJVfN4fggFVUYZ9wwxggGr
MIIBpwIBATA3MC8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJ
U0RDQQIEP/HJ/TAJBgUrDgMCGgUAoIHLMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ
KoZIhvcNAQkFMQ8XDTEyMDkxOTE0MDYxMlowIwYJKoZIhvcNAQkEMRYEFDOkOJdMEHrAnYkq
4Sp48gKbuFoWMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAK
BggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI
KoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEgYBnfWaFDPrV/fbkMjE/IvrkvZ6dZVs1+8lU
H1xGYtYclOOXeyPkYZfEgKLnDpO9+3T4vDPUjhL32EjvIVtPFxBEVIx28orcfMWy8SEHhKRQ
MtapAr4ntGBF/OmDlac7rNCqQ0qzUaGk8WvqMPSXPQSQOJULWPBFRWSMs1d1dTXETgAAAAAA
AA==
--------------ms050102090800020404030102--


--===============2343746549721609787==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============2343746549721609787==--


From xen-devel-bounces@lists.xen.org Wed Sep 19 14:07:53 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Sep 2012 14:07:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TEKwE-0007lM-O6; Wed, 19 Sep 2012 14:07:38 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <matthew.fioravante@jhuapl.edu>) id 1TEKwC-0007l9-Af
	for xen-devel@lists.xensource.com; Wed, 19 Sep 2012 14:07:36 +0000
Received: from [85.158.138.51:44577] by server-4.bemta-3.messagelabs.com id
	7F/FC-24831-7A1D9505; Wed, 19 Sep 2012 14:07:35 +0000
X-Env-Sender: matthew.fioravante@jhuapl.edu
X-Msg-Ref: server-3.tower-174.messagelabs.com!1348063653!23109308!1
X-Originating-IP: [128.244.251.36]
X-SpamReason: No, hits=0.0 required=7.0 tests=UNPARSEABLE_RELAY
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1185 invoked from network); 19 Sep 2012 14:07:34 -0000
Received: from pilot.jhuapl.edu (HELO jhuapl.edu) (128.244.251.36)
	by server-3.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 19 Sep 2012 14:07:34 -0000
Received: from ([128.244.207.89])
	by pilot.jhuapl.edu with ESMTP with TLS id 63GHCH1.153209662;
	Wed, 19 Sep 2012 10:07:28 -0400
Message-ID: <5059D154.3070105@jhuapl.edu>
Date: Wed, 19 Sep 2012 10:06:12 -0400
From: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120827 Thunderbird/15.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <5058BACF.6030903@jhuapl.edu>
	<1348058093.14977.109.camel@zakaz.uk.xensource.com>
In-Reply-To: <1348058093.14977.109.camel@zakaz.uk.xensource.com>
X-Enigmail-Version: 1.4.4
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH xm/xl enhancements for vptm 4/6] xl add irq
	support
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============2343746549721609787=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a cryptographically signed message in MIME format.

--===============2343746549721609787==
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms050102090800020404030102"

This is a cryptographically signed message in MIME format.

--------------ms050102090800020404030102
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

its for explicitly saying to allow or deny. It might be redundant since
the default is just to deny all of the irqs/mem regions. The allow flag
could be excluded.

On 09/19/2012 08:34 AM, Ian Campbell wrote:
> On Tue, 2012-09-18 at 19:17 +0100, Matthew Fioravante wrote:
>> This patch adds support for mapping irqs into virtual machines. The
>> syntax is
>>
>> irq =3D [irqnum,allow]
> Xen 4.2 / unstable already has support for specifying irqs.
>
> What is allow for (I should have asked this for the previous iomem patc=
h
> too)? THe default is deny and listing an irq here means allow, do we
> need to be able to explicitly deny given that?
>
> Ian.
>
>



--------------ms050102090800020404030102
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIDyjCC
A8YwggMvoAMCAQICBD/xyf0wDQYJKoZIhvcNAQEFBQAwLzELMAkGA1UEBhMCVVMxDzANBgNV
BAoTBkpIVUFQTDEPMA0GA1UECxMGQklTRENBMB4XDTEwMDYxMTE4MjIwNloXDTEzMDYxMTE4
NTIwNlowZjELMAkGA1UEBhMCVVMxDzANBgNVBAoTBkpIVUFQTDEPMA0GA1UECxMGUGVvcGxl
MTUwFgYDVQQLEw9WUE5Hcm91cC1CSVNEQ0EwGwYDVQQDExRNYXR0aGV3IEUgRmlvcmF2YW50
ZTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAnpbwVSP6o1Nb5lcW7dd3yTo9iBJdi7qz
4nANOMFPK7JOy5npKN1iiousl28U/scUJES55gPwAWYJK3uVyQAsA4adgDKi5DoD1UHDQEwp
bY7iHLJeq0NPr4BqYNqnCFPbE6HC8zSJrr4qKn+gVUQT39SIFqdiIPJwZL8FYTRQ/zsCAwEA
AaOCAbYwggGyMAsGA1UdDwQEAwIHgDArBgNVHRAEJDAigA8yMDEwMDYxMTE4MjIwNlqBDzIw
MTIwNzE3MjI1MjA2WjAbBg0rBgEEAbMlCwMBAQEBBAoWCGZpb3JhbWUxMBsGDSsGAQQBsyUL
AwEBAQIEChIIMDAxMDQyNjEwWAYJYIZIAYb6ax4BBEsMSVRoZSBwcml2YXRlIGtleSBjb3Jy
ZXNwb25kaW5nIHRvIHRoaXMgY2VydGlmaWNhdGUgbWF5IGhhdmUgYmVlbiBleHBvcnRlZC4w
KAYDVR0RBCEwH4EdTWF0dGhldy5GaW9yYXZhbnRlQGpodWFwbC5lZHUwUgYDVR0fBEswSTBH
oEWgQ6RBMD8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJU0RD
QTEOMAwGA1UEAxMFQ1JMNTYwHwYDVR0jBBgwFoAUCDUpmxH52EU2CyWmF2EJMB1yqeswHQYD
VR0OBBYEFO6LYxg6r9wHZ+zdQtBHn1dZ/YTNMAkGA1UdEwQCMAAwGQYJKoZIhvZ9B0EABAww
ChsEVjcuMQMCBLAwDQYJKoZIhvcNAQEFBQADgYEAJO9HQh4YNChVLzuZqK5ARJARD8JoujGZ
fdo75quvg2jXFQe2sEjvLnxJZgm/pv8fdZakq48CWwjYHKuvIp7sDjTEsQfo+y7SpN/N2NvJ
WU5SqfK1VgYtNLRRoGJUB5Q1aZ+Dg95g3kqpyfpUMISJL8IKVLtJVfN4fggFVUYZ9wwxggGr
MIIBpwIBATA3MC8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJ
U0RDQQIEP/HJ/TAJBgUrDgMCGgUAoIHLMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ
KoZIhvcNAQkFMQ8XDTEyMDkxOTE0MDYxMlowIwYJKoZIhvcNAQkEMRYEFDOkOJdMEHrAnYkq
4Sp48gKbuFoWMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAK
BggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI
KoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEgYBnfWaFDPrV/fbkMjE/IvrkvZ6dZVs1+8lU
H1xGYtYclOOXeyPkYZfEgKLnDpO9+3T4vDPUjhL32EjvIVtPFxBEVIx28orcfMWy8SEHhKRQ
MtapAr4ntGBF/OmDlac7rNCqQ0qzUaGk8WvqMPSXPQSQOJULWPBFRWSMs1d1dTXETgAAAAAA
AA==
--------------ms050102090800020404030102--


--===============2343746549721609787==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============2343746549721609787==--


From xen-devel-bounces@lists.xen.org Wed Sep 19 14:22:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Sep 2012 14: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 1TELAk-00082m-Af; Wed, 19 Sep 2012 14:22: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 1TELAi-00082h-Op
	for xen-devel@lists.xen.org; Wed, 19 Sep 2012 14:22:37 +0000
Received: from [85.158.143.35:4044] by server-1.bemta-4.messagelabs.com id
	76/B9-05684-C25D9505; Wed, 19 Sep 2012 14:22:36 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1348064553!19031801!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzUwOTQ4\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28922 invoked from network); 19 Sep 2012 14:22:34 -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; 19 Sep 2012 14:22: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 q8JEMUU8025792
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 19 Sep 2012 14:22:31 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q8JEMUaO022385
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 19 Sep 2012 14:22:30 GMT
Received: from abhmt112.oracle.com (abhmt112.oracle.com [141.146.116.64])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q8JEMUkK030732; Wed, 19 Sep 2012 09:22:30 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 19 Sep 2012 07:22:29 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id E554E402EC; Wed, 19 Sep 2012 10:11:38 -0400 (EDT)
Date: Wed, 19 Sep 2012 10:11:38 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Oliver Chick <oliver.chick@citrix.com>
Message-ID: <20120919141138.GC12367@phenom.dumpdata.com>
References: <1348051887-21885-1-git-send-email-oliver.chick@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1348051887-21885-1-git-send-email-oliver.chick@citrix.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: linux-kernel@vger.kernel.org, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] Persistent grant maps for xen blk drivers
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Sep 19, 2012 at 11:51:27AM +0100, Oliver Chick wrote:
> This patch implements persistent grants for the xen-blk{front,back}
> mechanism. The effect of this change is to reduce the number of unmap
> operations performed, since they cause a (costly) TLB shootdown. This
> allows the I/O performance to scale better when a large number of VMs
> are performing I/O.
> 
> Previously, the blkfront driver was supplied a bvec[] from the request
> queue. This was granted to dom0; dom0 performed the I/O and wrote
> directly into the grant-mapped memory and unmapped it; blkfront then
> removed foreign access for that grant. The cost of unmapping scales
> badly with the number of CPUs in Dom0. An experiment showed that when
> Dom0 has 24 VCPUs, and guests are performing parallel I/O to a
> ramdisk, the IPIs from performing unmap's is a bottleneck at 5 guests
> (at which point 650,000 IOPS are being performed in total). If more
> than 5 guests are used, the performance declines. By 10 guests, only
> 400,000 IOPS are being performed.
> 
> This patch improves performance by only unmapping when the connection
> between blkfront and back is broken.
> 
> On startup, blk{front,back} use xenbus to communicate their ability to
> perform 'feature-persistent'. Iff both ends have this ability,
> persistent mode is used.
> 
> To perform a read, in persistent mode, blkfront uses a separate pool
> of pages that it maps to dom0. When a request comes in, blkfront
> transmutes the request so that blkback will write into one of these
> free pages. Blkback keeps note of which grefs it has already
> mapped. When a new ring request comes to blkback, it looks to see if
> it has already mapped that page. If so, it will not map it again. If
> the page hasn't been previously mapped, it is mapped now, and a record
> is kept of this mapping. Blkback proceeds as usual. When blkfront is
> notified that blkback has completed a request, it memcpy's from the
> shared memory, into the bvec supplied. A record that the {gref, page}
> tuple is mapped, and not inflight is kept.
> 
> Writes are similar, except that the memcpy is peformed from the
> supplied bvecs, into the shared pages, before the request is put onto
> the ring.
> 
> Blkback has to store a mapping of grefs=>{page mapped to by gref} in
> an array. As the grefs are not known apriori, and provide no
> guarantees on their ordering, we have to perform a linear search
> through this array to find the page, for every gref we receive. The
> overhead of this is low, however future work might want to use a more
> efficient data structure to reduce this O(n) operation.
> 
> We (ijc, and myself) have introduced a new constant,
> BLKIF_MAX_PERS_REQUESTS_PER_DEV. This is to prevent a malicious guest
> from attempting a DoS, by supplying fresh grefs, causing the Dom0
> kernel from to map excessively. This is currently set to 256---the
> maximum number of entires in the ring. As the number of inflight
> requests <= size of ring, 256 is also the maximum sensible size. This
> introduces a maximum overhead of 11MB of mapped memory, per block
> device. In practice, we don't typically use about 60 of these. If the
> guest exceeds the 256 limit, it is either buggy or malicious. We treat
> this in one of two ways:
> 1) If we have mapped <
> BLKIF_MAX_SEGMENTS_PER_REQUEST * BLKIF_MAX_PERS_REQUESTS_PER_DEV
> pages, we will persistently map the grefs. This can occur is previous
> requests have not used all BLKIF_MAX_SEGMENTS_PER_REQUEST segments.
> 2) Otherwise, we revert to non-persistent grants for all future grefs.
> 
> In writing this patch, the question arrises as to if the additional
> cost of performing memcpys in the guest (to/from the pool of granted
> pages) outweigh the gains of not performing TLB shootdowns. The answer
> to that question is `no'. There appears to be very little, if any
> additional cost to the guest of using persistent grants. There is
> perhaps a small saving, from the reduced number of hypercalls
> performed in granting, and ending foreign access.
> 
> 
> Signed-off-by: Oliver Chick <oliver.chick@citrix.com>
> ---
>  drivers/block/xen-blkback/blkback.c |  149 +++++++++++++++++++++++++---
>  drivers/block/xen-blkback/common.h  |   16 +++
>  drivers/block/xen-blkback/xenbus.c  |   21 +++-
>  drivers/block/xen-blkfront.c        |  186 ++++++++++++++++++++++++++++++-----
>  include/xen/interface/io/blkif.h    |    9 ++
>  5 files changed, 338 insertions(+), 43 deletions(-)
> 
> diff --git a/drivers/block/xen-blkback/blkback.c b/drivers/block/xen-blkback/blkback.c
> index 73f196c..f95dee9 100644
> --- a/drivers/block/xen-blkback/blkback.c
> +++ b/drivers/block/xen-blkback/blkback.c
> @@ -78,6 +78,7 @@ struct pending_req {
>  	unsigned short		operation;
>  	int			status;
>  	struct list_head	free_list;
> +	u8			is_pers;

Just do what you did in the blkfront.c:

	unsigned int feature_persistent:1

or:
	unsigned int flag_persistent:1

or:
	unsigned int flag_pers_gnt:1

>  };
>  
>  #define BLKBACK_INVALID_HANDLE (~0)
> @@ -128,6 +129,24 @@ static int dispatch_rw_block_io(struct xen_blkif *blkif,
>  static void make_response(struct xen_blkif *blkif, u64 id,
>  			  unsigned short op, int st);
>  
> +static void add_pers_gnt(struct pers_gnt *pers_gnt, struct xen_blkif *blkif)
> +{
> +	BUG_ON(blkif->pers_gnt_c >= BLKIF_MAX_PERS_REQUESTS_PER_DEV *
> +	       BLKIF_MAX_SEGMENTS_PER_REQUEST);
> +	blkif->pers_gnts[blkif->pers_gnt_c++] = pers_gnt;
> +}
> +
> +static struct pers_gnt *get_pers_gnt(struct xen_blkif *blkif,
> +				     grant_ref_t gref)
> +{
> +	int i;
> +
> +	for (i = 0; i < blkif->pers_gnt_c; i++)
> +		if (gref == blkif->pers_gnts[i]->gnt)
> +			return blkif->pers_gnts[i];
> +	return NULL;
> +}
> +
>  /*
>   * Retrieve from the 'pending_reqs' a free pending_req structure to be used.
>   */
> @@ -274,6 +293,12 @@ int xen_blkif_schedule(void *arg)
>  {
>  	struct xen_blkif *blkif = arg;
>  	struct xen_vbd *vbd = &blkif->vbd;
> +	struct gnttab_unmap_grant_ref unmap[BLKIF_MAX_SEGMENTS_PER_REQUEST];
> +	struct page *pages[BLKIF_MAX_SEGMENTS_PER_REQUEST];
> +	struct pers_gnt *pers_gnt;
> +	int i;
> +	int ret = 0;
> +	int segs_to_unmap;
>  
>  	xen_blkif_get(blkif);
>  
> @@ -301,6 +326,29 @@ int xen_blkif_schedule(void *arg)
>  			print_stats(blkif);
>  	}
>  
> +	/* Free all persistent grant pages */
> +
> +	while (segs_to_unmap = min(BLKIF_MAX_SEGMENTS_PER_REQUEST,
> +				 blkif->pers_gnt_c)) {
> +
> +		for (i = 0; i < segs_to_unmap; i++) {
> +			pers_gnt = blkif->pers_gnts[blkif->pers_gnt_c - i - 1];
> +
> +			gnttab_set_unmap_op(&unmap[i],
> +					    pfn_to_kaddr(page_to_pfn(
> +							     pers_gnt->page)),
> +					    GNTMAP_host_map,
> +					    pers_gnt->handle);
> +
> +			pages[i] = pers_gnt->page;
> +		}
> +
> +		ret = gnttab_unmap_refs(unmap, pages, segs_to_unmap, false);
> +		BUG_ON(ret);
> +
> +		blkif->pers_gnt_c -= segs_to_unmap;
> +
> +	}
> +
>  	if (log_stats)
>  		print_stats(blkif);
>  
> @@ -343,13 +391,28 @@ static void xen_blkbk_unmap(struct pending_req *req)
>  
>  static int xen_blkbk_map(struct blkif_request *req,
>  			 struct pending_req *pending_req,
> -			 struct seg_buf seg[])
> +			 struct seg_buf seg[],
> +			 struct page *pages[])
>  {
>  	struct gnttab_map_grant_ref map[BLKIF_MAX_SEGMENTS_PER_REQUEST];
> +	struct pers_gnt *new_pers_gnts[BLKIF_MAX_SEGMENTS_PER_REQUEST];
> +	struct pers_gnt *pers_gnts[BLKIF_MAX_SEGMENTS_PER_REQUEST];
> +	struct page *pages_to_gnt[BLKIF_MAX_SEGMENTS_PER_REQUEST];
> +	struct pers_gnt *pers_gnt;
> +	phys_addr_t addr;
>  	int i;
> +	int new_map;
>  	int nseg = req->u.rw.nr_segments;
> +	int segs_to_init = 0;

segs_to_map is probably a better name.

>  	int ret = 0;
> +	int use_pers_gnts;
>  
> +	use_pers_gnts = (pending_req->blkif->can_grant_persist &&
> +			 pending_req->blkif->pers_gnt_c <
> +			 BLKIF_MAX_SEGMENTS_PER_REQUEST *
> +			 BLKIF_MAX_PERS_REQUESTS_PER_DEV);
> +
> +	pending_req->is_pers = use_pers_gnts;
>  	/*
>  	 * Fill out preq.nr_sects with proper amount of sectors, and setup
>  	 * assign map[..] with the PFN of the page in our domain with the
> @@ -358,36 +421,87 @@ static int xen_blkbk_map(struct blkif_request *req,
>  	for (i = 0; i < nseg; i++) {
>  		uint32_t flags;
>  
> +		if (use_pers_gnts) {
> +			pers_gnt = get_pers_gnt(pending_req->blkif,
> +						req->u.rw.seg[i].gref);
> +			if (!pers_gnt) {
> +				new_map = 1;
> +				pers_gnt = kmalloc(sizeof(struct pers_gnt),
> +						   GFP_KERNEL);
> +				if (!pers_gnt)
> +					return -ENOMEM;
> +				pers_gnt->page = alloc_page(GFP_KERNEL);
> +				if (!pers_gnt->page)
> +					return -ENOMEM;

You want to kfree pers_gnt here.

> +				pers_gnt->gnt = req->u.rw.seg[i].gref;
> +
> +				pages_to_gnt[segs_to_init] = pers_gnt->page;
> +				new_pers_gnts[segs_to_init] = pers_gnt;
> +
> +				add_pers_gnt(pers_gnt, pending_req->blkif);
> +
> +			} else {
> +				new_map = 0;
> +			}
> +			pages[i] = pers_gnt->page;
> +			addr = (unsigned long) pfn_to_kaddr(
> +				page_to_pfn(pers_gnt->page));

Would it make sense to cache this in the 'pers_gnt' structure?

> +			pers_gnts[i] = pers_gnt;
> +		} else {
> +			new_map = 1;
> +			pages[i] = blkbk->pending_page(pending_req, i);
> +			addr = vaddr(pending_req, i);
> +			pages_to_gnt[i] = blkbk->pending_page(pending_req, i);
> +		}
> +
>  		flags = GNTMAP_host_map;
> -		if (pending_req->operation != BLKIF_OP_READ)
> +		if (!use_pers_gnts && (pending_req->operation != BLKIF_OP_READ))
>  			flags |= GNTMAP_readonly;
> -		gnttab_set_map_op(&map[i], vaddr(pending_req, i), flags,
> -				  req->u.rw.seg[i].gref,
> -				  pending_req->blkif->domid);
> +		if (new_map) {
> +			gnttab_set_map_op(&map[segs_to_init++], addr,
> +					  flags, req->u.rw.seg[i].gref,
> +					  pending_req->blkif->domid);
> +		}
>  	}
>  
> -	ret = gnttab_map_refs(map, NULL, &blkbk->pending_page(pending_req, 0), nseg);
> -	BUG_ON(ret);
> +	if (segs_to_init) {
> +		ret = gnttab_map_refs(map, NULL, pages_to_gnt, segs_to_init);
> +		BUG_ON(ret);
> +	}
>  
>  	/*
>  	 * Now swizzle the MFN in our domain with the MFN from the other domain
>  	 * so that when we access vaddr(pending_req,i) it has the contents of
>  	 * the page from the other domain.
>  	 */
> -	for (i = 0; i < nseg; i++) {
> +	for (i = 0; i < segs_to_init; i++) {
>  		if (unlikely(map[i].status != 0)) {
>  			pr_debug(DRV_PFX "invalid buffer -- could not remap it\n");
>  			map[i].handle = BLKBACK_INVALID_HANDLE;
>  			ret |= 1;
>  		}
>  
> -		pending_handle(pending_req, i) = map[i].handle;
> +		if (use_pers_gnts) {
> +			/* store the `out' values from map */
> +		    pending_req->blkif->pers_gnts
> +			[pending_req->blkif->pers_gnt_c - segs_to_init +
> +			 i]->handle = map[i].handle;
> +			new_pers_gnts[i]->dev_bus_addr = map[i].dev_bus_addr;
> +		}
>  
>  		if (ret)
>  			continue;
> -
> -		seg[i].buf  = map[i].dev_bus_addr |
> -			(req->u.rw.seg[i].first_sect << 9);
> +	}
> +	for (i = 0; i < nseg; i++) {
> +		if (use_pers_gnts) {
> +			pending_handle(pending_req, i) = pers_gnts[i]->handle;
> +			seg[i].buf = pers_gnts[i]->dev_bus_addr |
> +				(req->u.rw.seg[i].first_sect << 9);
> +		} else {
> +			pending_handle(pending_req, i) = map[i].handle;
> +			seg[i].buf = map[i].dev_bus_addr |
> +				(req->u.rw.seg[i].first_sect << 9);
> +		}
>  	}
>  	return ret;
>  }
> @@ -468,7 +582,8 @@ static void __end_block_io_op(struct pending_req *pending_req, int error)
>  	 * the proper response on the ring.
>  	 */
>  	if (atomic_dec_and_test(&pending_req->pendcnt)) {
> -		xen_blkbk_unmap(pending_req);
> +		if (!pending_req->is_pers)
> +			xen_blkbk_unmap(pending_req);
>  		make_response(pending_req->blkif, pending_req->id,
>  			      pending_req->operation, pending_req->status);
>  		xen_blkif_put(pending_req->blkif);
> @@ -590,6 +705,7 @@ static int dispatch_rw_block_io(struct xen_blkif *blkif,
>  	int operation;
>  	struct blk_plug plug;
>  	bool drain = false;
> +	struct page *pages[BLKIF_MAX_SEGMENTS_PER_REQUEST];
>  
>  	switch (req->operation) {
>  	case BLKIF_OP_READ:
> @@ -676,7 +792,7 @@ static int dispatch_rw_block_io(struct xen_blkif *blkif,
>  	 * the hypercall to unmap the grants - that is all done in
>  	 * xen_blkbk_unmap.
>  	 */
> -	if (xen_blkbk_map(req, pending_req, seg))
> +	if (xen_blkbk_map(req, pending_req, seg, pages))
>  		goto fail_flush;
>  
>  	/*
> @@ -688,7 +804,7 @@ static int dispatch_rw_block_io(struct xen_blkif *blkif,
>  	for (i = 0; i < nseg; i++) {
>  		while ((bio == NULL) ||
>  		       (bio_add_page(bio,
> -				     blkbk->pending_page(pending_req, i),

Can we get rid of pending_page macro?

> +				     pages[i],
>  				     seg[i].nsec << 9,
>  				     seg[i].buf & ~PAGE_MASK) == 0)) {
>  
> @@ -743,7 +859,8 @@ static int dispatch_rw_block_io(struct xen_blkif *blkif,
>  	return 0;
>  
>   fail_flush:
> -	xen_blkbk_unmap(pending_req);
> +	if (!blkif->can_grant_persist)
> +		xen_blkbk_unmap(pending_req);
>   fail_response:
>  	/* Haven't submitted any bio's yet. */
>  	make_response(blkif, req->u.rw.id, req->operation, BLKIF_RSP_ERROR);
> diff --git a/drivers/block/xen-blkback/common.h b/drivers/block/xen-blkback/common.h
> index 9ad3b5e..1ecb709 100644
> --- a/drivers/block/xen-blkback/common.h
> +++ b/drivers/block/xen-blkback/common.h
> @@ -47,6 +47,8 @@
>  #define DPRINTK(fmt, args...)				\
>  	pr_debug(DRV_PFX "(%s:%d) " fmt ".\n",		\
>  		 __func__, __LINE__, ##args)
> +#define BLKIF_MAX_PERS_REQUESTS_PER_DEV 256

You need a comment explaining why this number.

> +
>  
>  
>  /* Not a real protocol.  Used to generate ring structs which contain
> @@ -164,6 +166,14 @@ struct xen_vbd {
>  
>  struct backend_info;
>  
> +
> +struct pers_gnt {
> +	struct page *page;
> +	grant_ref_t gnt;
> +	uint32_t handle;

Not grant_handle_t ?

> +	uint64_t dev_bus_addr;
> +};
> +
>  struct xen_blkif {
>  	/* Unique identifier for this interface. */
>  	domid_t			domid;
> @@ -190,6 +200,12 @@ struct xen_blkif {
>  	struct task_struct	*xenblkd;
>  	unsigned int		waiting_reqs;
>  
> +	/* frontend feature information */
> +	u8			can_grant_persist:1;

Pls move that to the vbd structure, and if you feel
especially adventourous, you could modify the

bool flush_support
bool discard_secure

to be 'unsigned int feature_flush:1' ,etc.. as its own
seperate patch and then introduce the

unsigned int feature_grnt_pers:1

flag.
> +	struct pers_gnt		*pers_gnts[BLKIF_MAX_PERS_REQUESTS_PER_DEV *
> +					  BLKIF_MAX_SEGMENTS_PER_REQUEST];
> +	unsigned int		pers_gnt_c;
> +
>  	/* statistics */
>  	unsigned long		st_print;
>  	int			st_rd_req;
> diff --git a/drivers/block/xen-blkback/xenbus.c b/drivers/block/xen-blkback/xenbus.c
> index 4f66171..dc58cc4 100644
> --- a/drivers/block/xen-blkback/xenbus.c
> +++ b/drivers/block/xen-blkback/xenbus.c
> @@ -681,6 +681,13 @@ again:
>  		goto abort;
>  	}
>  
> +	err = xenbus_printf(xbt, dev->nodename, "feature-persistent-grants",
> +			    "%d", 1);
> +	if (err) {
> +		xenbus_dev_fatal(dev, err, "writing persistent capability");

It is not fatal. Just do dev_warn, like the xen_blkbk_discard does.

> +		goto abort;
> +	}
> +
>  	/* FIXME: use a typename instead */
>  	err = xenbus_printf(xbt, dev->nodename, "info", "%u",
>  			    be->blkif->vbd.type |
> @@ -721,6 +728,7 @@ static int connect_ring(struct backend_info *be)
>  	struct xenbus_device *dev = be->dev;
>  	unsigned long ring_ref;
>  	unsigned int evtchn;
> +	u8 pers_grants;
>  	char protocol[64] = "";
>  	int err;
>  
> @@ -750,8 +758,17 @@ static int connect_ring(struct backend_info *be)
>  		xenbus_dev_fatal(dev, err, "unknown fe protocol %s", protocol);
>  		return -1;
>  	}
> -	pr_info(DRV_PFX "ring-ref %ld, event-channel %d, protocol %d (%s)\n",
> -		ring_ref, evtchn, be->blkif->blk_protocol, protocol);
> +	err = xenbus_gather(XBT_NIL, dev->otherend,
> +			    "feature-persistent-grants", "%d",
> +			    &pers_grants, NULL);
> +	if (err)
> +		pers_grants = 0;
> +
> +	be->blkif->can_grant_persist = pers_grants;

We should also have a patch for the Xen blkif.h to document this feature.. but that
can be done later.

> +
> +	pr_info(DRV_PFX "ring-ref %ld, event-channel %d, protocol %d (%s) persistent %d\n",
> +		ring_ref, evtchn, be->blkif->blk_protocol, protocol,
> +		pers_grants);
>  
>  	/* Map the shared frame, irq etc. */
>  	err = xen_blkif_map(be->blkif, ring_ref, evtchn);
> diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c
> index e4fb337..c1cc5fe 100644
> --- a/drivers/block/xen-blkfront.c
> +++ b/drivers/block/xen-blkfront.c
> @@ -68,6 +68,13 @@ struct blk_shadow {
>  	struct blkif_request req;
>  	struct request *request;
>  	unsigned long frame[BLKIF_MAX_SEGMENTS_PER_REQUEST];
> +	struct gnt_list *grants_used[BLKIF_MAX_SEGMENTS_PER_REQUEST];
> +};
> +
> +struct gnt_list {
> +	grant_ref_t gref;
> +	unsigned long frame;

Pls mention what 'frame' is and what the other ones do.

> +	struct gnt_list *tail;
>  };

How did the compiler actually compile this? You are using it in 'struct blk_shadow'
but it is declared later?
>  
>  static DEFINE_MUTEX(blkfront_mutex);
> @@ -97,11 +104,14 @@ struct blkfront_info
>  	struct work_struct work;
>  	struct gnttab_free_callback callback;
>  	struct blk_shadow shadow[BLK_RING_SIZE];
> +	struct gnt_list *persistent_grants_front;

I don't think you need the 'front' in there. Its obvious you are
in the frontend code.

> +	unsigned int persistent_grants_c;
>  	unsigned long shadow_free;
>  	unsigned int feature_flush;
>  	unsigned int flush_op;
>  	unsigned int feature_discard:1;
>  	unsigned int feature_secdiscard:1;
> +	unsigned int feature_persistent:1;
>  	unsigned int discard_granularity;
>  	unsigned int discard_alignment;
>  	int is_ready;
> @@ -286,22 +296,37 @@ static int blkif_queue_request(struct request *req)
>  	struct blkif_request *ring_req;
>  	unsigned long id;
>  	unsigned int fsect, lsect;
> -	int i, ref;
> +	int i, ref, use_pers_gnts, new_pers_gnts;

use_pers_gnts and new_pers_gnt? Can you document what the difference
is pls?

Perhaps 'new_pers_gnts' should be called:
'got_grant'? or 'using_grant' ?

>  	grant_ref_t gref_head;
> +	struct bio_vec *bvecs[BLKIF_MAX_SEGMENTS_PER_REQUEST];
> +	struct bio_vec *bvec;
> +	struct req_iterator iter;
> +	char *bvec_data;
> +	void *shared_data;
> +	unsigned long flags;

What kind of flags?
> +	struct page *shared_page;

It is not really shared_page. It is a temporary page. Perhaps
tmp_page ?

> +	struct gnt_list *gnt_list_entry;
>  	struct scatterlist *sg;
>  
>  	if (unlikely(info->connected != BLKIF_STATE_CONNECTED))
>  		return 1;
>  
> -	if (gnttab_alloc_grant_references(
> -		BLKIF_MAX_SEGMENTS_PER_REQUEST, &gref_head) < 0) {
> -		gnttab_request_free_callback(
> -			&info->callback,
> -			blkif_restart_queue_callback,
> -			info,
> -			BLKIF_MAX_SEGMENTS_PER_REQUEST);
> -		return 1;
> +	use_pers_gnts = info->feature_persistent;
> +
> +	if (info->persistent_grants_c < BLKIF_MAX_SEGMENTS_PER_REQUEST) {
> +		new_pers_gnts = 1;
> +		if (gnttab_alloc_grant_references(
> +			    BLKIF_MAX_SEGMENTS_PER_REQUEST, &gref_head) < 0) {
> +			gnttab_request_free_callback(
> +				&info->callback,
> +				blkif_restart_queue_callback,
> +				info,
> +				BLKIF_MAX_SEGMENTS_PER_REQUEST);
> +			return 1;
> +		}
>  	} else
> +		new_pers_gnts = 0;
>  
>  	/* Fill out a communications ring structure. */
>  	ring_req = RING_GET_REQUEST(&info->ring, info->ring.req_prod_pvt);
> @@ -341,20 +366,66 @@ static int blkif_queue_request(struct request *req)
>  		       BLKIF_MAX_SEGMENTS_PER_REQUEST);
>  
>  		for_each_sg(info->sg, sg, ring_req->u.rw.nr_segments, i) {
> -			buffer_mfn = pfn_to_mfn(page_to_pfn(sg_page(sg)));
>  			fsect = sg->offset >> 9;
>  			lsect = fsect + (sg->length >> 9) - 1;
> -			/* install a grant reference. */
> -			ref = gnttab_claim_grant_reference(&gref_head);
> -			BUG_ON(ref == -ENOSPC);
>  
> -			gnttab_grant_foreign_access_ref(
> +			if (use_pers_gnts && info->persistent_grants_c) {
> +				gnt_list_entry = info->persistent_grants_front;
> +
> +				info->persistent_grants_front =
> +					info->persistent_grants_front->tail;
> +				ref = gnt_list_entry->gref;
> +				buffer_mfn = pfn_to_mfn(gnt_list_entry->frame);

Ah, so frame is a PFN! why don't you just call it that?

> +				info->persistent_grants_c--;
> +			} else {
> +				ref = gnttab_claim_grant_reference(&gref_head);
> +				BUG_ON(ref == -ENOSPC);
> +
> +				if (use_pers_gnts) {
> +					gnt_list_entry =
> +						kmalloc(sizeof(struct gnt_list),
> +								 GFP_ATOMIC);
> +					if (!gnt_list_entry)
> +						return -ENOMEM;
> +
> +					shared_page = alloc_page(GFP_ATOMIC);
> +					if (!shared_page)
> +						return -ENOMEM;

Make sure to kfree gnt_list_entry.

> +
> +					gnt_list_entry->frame =
> +						page_to_pfn(shared_page);
> +					gnt_list_entry->gref = ref;
> +				} else
> +					shared_page = sg_page(sg);
> +
> +				buffer_mfn = pfn_to_mfn(page_to_pfn(
> +								shared_page));
> +				gnttab_grant_foreign_access_ref(
>  					ref,
>  					info->xbdev->otherend_id,
>  					buffer_mfn,
> -					rq_data_dir(req));
> +					!use_pers_gnts && rq_data_dir(req));
> +			}
> +
> +			if (use_pers_gnts)
> +				info->shadow[id].grants_used[i] =
> +					gnt_list_entry;
> +
> +			if (use_pers_gnts && rq_data_dir(req)) {

You can declare the 'shared_data' here:

				void *shared_data;

and also bvec_data.

> +				shared_data = kmap_atomic(
> +					pfn_to_page(gnt_list_entry->frame));
> +				bvec_data = kmap_atomic(sg_page(sg));
> +
> +				memcpy(shared_data + sg->offset,
> +				       bvec_data   + sg->offset,
> +				       sg->length);

Do we need to worry about it spilling over a page? Should we check that
sg>offset + sg->length < PAGE_SIZE ?

Also this would imply that based on the offset (so say it is 3999) that the old data (0->3998)
might be still there - don't know how important that is?
> +
> +				kunmap_atomic(bvec_data);
> +				kunmap_atomic(shared_data);
> +			}
>  
>  			info->shadow[id].frame[i] = mfn_to_pfn(buffer_mfn);
> +
>  			ring_req->u.rw.seg[i] =
>  					(struct blkif_request_segment) {
>  						.gref       = ref,
> @@ -368,7 +439,8 @@ static int blkif_queue_request(struct request *req)
>  	/* Keep a private copy so we can reissue requests when recovering. */
>  	info->shadow[id].req = *ring_req;
>  
> -	gnttab_free_grant_references(gref_head);
> +	if (new_pers_gnts)
> +		gnttab_free_grant_references(gref_head);
>  
>  	return 0;
>  }
> @@ -480,12 +552,13 @@ static int xlvbd_init_blk_queue(struct gendisk *gd, u16 sector_size)
>  static void xlvbd_flush(struct blkfront_info *info)
>  {
>  	blk_queue_flush(info->rq, info->feature_flush);
> -	printk(KERN_INFO "blkfront: %s: %s: %s\n",
> +	printk(KERN_INFO "blkfront: %s: %s: %s. Persistent=%d\n",

Just use %s like the rest
>  	       info->gd->disk_name,
>  	       info->flush_op == BLKIF_OP_WRITE_BARRIER ?
>  		"barrier" : (info->flush_op == BLKIF_OP_FLUSH_DISKCACHE ?
>  		"flush diskcache" : "barrier or flush"),
> -	       info->feature_flush ? "enabled" : "disabled");
> +	       info->feature_flush ? "enabled" : "disabled",
> +	    info->feature_persistent);

and this can be 'info->feature_persistent ? "persitent" : "".

>  }
>  
>  static int xen_translate_vdev(int vdevice, int *minor, unsigned int *offset)
> @@ -707,6 +780,8 @@ static void blkif_restart_queue(struct work_struct *work)
>  
>  static void blkif_free(struct blkfront_info *info, int suspend)
>  {
> +	struct gnt_list *pers_gnt;
> +
>  	/* Prevent new requests being issued until we fix things up. */
>  	spin_lock_irq(&info->io_lock);
>  	info->connected = suspend ?
> @@ -714,6 +789,15 @@ static void blkif_free(struct blkfront_info *info, int suspend)
>  	/* No more blkif_request(). */
>  	if (info->rq)
>  		blk_stop_queue(info->rq);
> +
> +	/* Remove all persistent grants */
> +	while (info->persistent_grants_front) {
> +		pers_gnt = info->persistent_grants_front;
> +		info->persistent_grants_front = pers_gnt->tail;
> +		gnttab_end_foreign_access(pers_gnt->gref, 0, 0UL);
> +		kfree(pers_gnt);
> +	}
> +
>  	/* No more gnttab callback work. */
>  	gnttab_cancel_free_callback(&info->callback);
>  	spin_unlock_irq(&info->io_lock);
> @@ -734,13 +818,44 @@ static void blkif_free(struct blkfront_info *info, int suspend)
>  
>  }
>  
> -static void blkif_completion(struct blk_shadow *s)
> +static void blkif_completion(struct blk_shadow *s, struct blkfront_info *info,
> +			     struct blkif_response *bret)
>  {
>  	int i;
> -	/* Do not let BLKIF_OP_DISCARD as nr_segment is in the same place
> -	 * flag. */
> -	for (i = 0; i < s->req.u.rw.nr_segments; i++)
> -		gnttab_end_foreign_access(s->req.u.rw.seg[i].gref, 0, 0UL);
> +	struct gnt_list *new_gnt_list_entry;
> +	struct bio_vec *bvec;
> +	struct req_iterator iter;
> +	unsigned long flags;
> +	char *bvec_data;
> +	void *shared_data;
> +
> +	i = 0;
> +	if (info->feature_persistent == 0) {
> +		/* Do not let BLKIF_OP_DISCARD as nr_segment is in the same
> +		 * place flag. */
> +		for (i = 0; i < s->req.u.rw.nr_segments; i++)
> +			gnttab_end_foreign_access(s->req.u.rw.seg[i].gref,
> +						  0, 0UL);
> +		return;
> +	}
> +

Move the 'i = 0' to here.

> +	if (bret->operation == BLKIF_OP_READ)
> +		rq_for_each_segment(bvec, s->request, iter) {
> +			shared_data = kmap_atomic
> +				(pfn_to_page(s->grants_used[i++]->frame));
> +			bvec_data = bvec_kmap_irq(bvec, &flags);
> +			memcpy(bvec_data, shared_data + bvec->bv_offset,
> +			       bvec->bv_len);
> +			bvec_kunmap_irq(bvec_data, &flags);
> +			kunmap_atomic(shared_data);
> +		}
> +	/* Add the persistent grant into the list of free grants */
> +	for (i = 0; i < s->req.u.rw.nr_segments; i++) {
> +		new_gnt_list_entry = s->grants_used[i];
> +		new_gnt_list_entry->tail = info->persistent_grants_front;
> +		info->persistent_grants_front = new_gnt_list_entry;
> +		info->persistent_grants_c++;
> +	}
>  }
>  
>  static irqreturn_t blkif_interrupt(int irq, void *dev_id)
> @@ -783,7 +898,7 @@ static irqreturn_t blkif_interrupt(int irq, void *dev_id)
>  		req  = info->shadow[id].request;
>  
>  		if (bret->operation != BLKIF_OP_DISCARD)
> -			blkif_completion(&info->shadow[id]);
> +			blkif_completion(&info->shadow[id], info, bret);
>  
>  		if (add_id_to_freelist(info, id)) {
>  			WARN(1, "%s: response to %s (id %ld) couldn't be recycled!\n",
> @@ -943,6 +1058,12 @@ again:
>  		message = "writing protocol";
>  		goto abort_transaction;
>  	}
> +	err = xenbus_printf(xbt, dev->nodename,
> +			    "feature-persistent-grants", "%d", 1);
> +	if (err) {
> +		message = "Writing persistent grants front feature";
> +		goto abort_transaction;

I wouldn't abort. Just continue on using the non-grant feature.

> +	}
>  
>  	err = xenbus_transaction_end(xbt, 0);
>  	if (err) {
> @@ -1030,6 +1151,7 @@ static int blkfront_probe(struct xenbus_device *dev,
>  	spin_lock_init(&info->io_lock);
>  	info->xbdev = dev;
>  	info->vdevice = vdevice;
> +	info->persistent_grants_c = 0;
>  	info->connected = BLKIF_STATE_DISCONNECTED;
>  	INIT_WORK(&info->work, blkif_restart_queue);
>  
> @@ -1094,6 +1216,7 @@ static int blkif_recover(struct blkfront_info *info)
>  					req->u.rw.seg[j].gref,
>  					info->xbdev->otherend_id,
>  					pfn_to_mfn(info->shadow[req->u.rw.id].frame[j]),
> +					!info->feature_persistent &&
>  					rq_data_dir(info->shadow[req->u.rw.id].request));
>  		}
>  		info->shadow[req->u.rw.id].req = *req;
> @@ -1226,7 +1349,7 @@ static void blkfront_connect(struct blkfront_info *info)
>  	unsigned long sector_size;
>  	unsigned int binfo;
>  	int err;
> -	int barrier, flush, discard;
> +	int barrier, flush, discard, persistent;
>  
>  	switch (info->connected) {
>  	case BLKIF_STATE_CONNECTED:
> @@ -1297,6 +1420,19 @@ static void blkfront_connect(struct blkfront_info *info)
>  		info->flush_op = BLKIF_OP_FLUSH_DISKCACHE;
>  	}
>  
> +	/*
> +	 * Are we dealing with an old blkback that will unmap
> +	 * all grefs?
> +	 */
> +	err = xenbus_gather(XBT_NIL, info->xbdev->otherend,
> +			    "feature-persistent-grants", "%d", &persistent,
> +			    NULL);
> +
> +	if (err)
> +		info->feature_persistent = 0;
> +	else
> +		info->feature_persistent = persistent;
> +
>  	err = xenbus_gather(XBT_NIL, info->xbdev->otherend,
>  			    "feature-discard", "%d", &discard,
>  			    NULL);
> diff --git a/include/xen/interface/io/blkif.h b/include/xen/interface/io/blkif.h
> index ee338bf..cd267a9b 100644
> --- a/include/xen/interface/io/blkif.h
> +++ b/include/xen/interface/io/blkif.h
> @@ -109,6 +109,15 @@ typedef uint64_t blkif_sector_t;
>   */
>  #define BLKIF_MAX_SEGMENTS_PER_REQUEST 11
>  
> +/*
> + * Maximum number of persistent grants that can be mapped by Dom0 for each

by blkback
> + * interface. This is set to be the size of the ring, as this is a limit on

Size of the ring? You sure?
> + * the number of requests that can be inflight at any one time. 256 imposes
> + * an overhead of 11MB of mapped kernel space per interface.
> + */
> +#define BLKIF_MAX_PERS_REQUESTS_PER_DEV 256
> +
> +
>  struct blkif_request_rw {
>  	uint8_t        nr_segments;  /* number of segments                   */
>  	blkif_vdev_t   handle;       /* only for read/write requests         */
> -- 
> 1.7.9.5

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 19 14:22:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Sep 2012 14: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 1TELAk-00082m-Af; Wed, 19 Sep 2012 14:22: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 1TELAi-00082h-Op
	for xen-devel@lists.xen.org; Wed, 19 Sep 2012 14:22:37 +0000
Received: from [85.158.143.35:4044] by server-1.bemta-4.messagelabs.com id
	76/B9-05684-C25D9505; Wed, 19 Sep 2012 14:22:36 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1348064553!19031801!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzUwOTQ4\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28922 invoked from network); 19 Sep 2012 14:22:34 -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; 19 Sep 2012 14:22: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 q8JEMUU8025792
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 19 Sep 2012 14:22:31 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q8JEMUaO022385
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 19 Sep 2012 14:22:30 GMT
Received: from abhmt112.oracle.com (abhmt112.oracle.com [141.146.116.64])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q8JEMUkK030732; Wed, 19 Sep 2012 09:22:30 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 19 Sep 2012 07:22:29 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id E554E402EC; Wed, 19 Sep 2012 10:11:38 -0400 (EDT)
Date: Wed, 19 Sep 2012 10:11:38 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Oliver Chick <oliver.chick@citrix.com>
Message-ID: <20120919141138.GC12367@phenom.dumpdata.com>
References: <1348051887-21885-1-git-send-email-oliver.chick@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1348051887-21885-1-git-send-email-oliver.chick@citrix.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: linux-kernel@vger.kernel.org, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] Persistent grant maps for xen blk drivers
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Sep 19, 2012 at 11:51:27AM +0100, Oliver Chick wrote:
> This patch implements persistent grants for the xen-blk{front,back}
> mechanism. The effect of this change is to reduce the number of unmap
> operations performed, since they cause a (costly) TLB shootdown. This
> allows the I/O performance to scale better when a large number of VMs
> are performing I/O.
> 
> Previously, the blkfront driver was supplied a bvec[] from the request
> queue. This was granted to dom0; dom0 performed the I/O and wrote
> directly into the grant-mapped memory and unmapped it; blkfront then
> removed foreign access for that grant. The cost of unmapping scales
> badly with the number of CPUs in Dom0. An experiment showed that when
> Dom0 has 24 VCPUs, and guests are performing parallel I/O to a
> ramdisk, the IPIs from performing unmap's is a bottleneck at 5 guests
> (at which point 650,000 IOPS are being performed in total). If more
> than 5 guests are used, the performance declines. By 10 guests, only
> 400,000 IOPS are being performed.
> 
> This patch improves performance by only unmapping when the connection
> between blkfront and back is broken.
> 
> On startup, blk{front,back} use xenbus to communicate their ability to
> perform 'feature-persistent'. Iff both ends have this ability,
> persistent mode is used.
> 
> To perform a read, in persistent mode, blkfront uses a separate pool
> of pages that it maps to dom0. When a request comes in, blkfront
> transmutes the request so that blkback will write into one of these
> free pages. Blkback keeps note of which grefs it has already
> mapped. When a new ring request comes to blkback, it looks to see if
> it has already mapped that page. If so, it will not map it again. If
> the page hasn't been previously mapped, it is mapped now, and a record
> is kept of this mapping. Blkback proceeds as usual. When blkfront is
> notified that blkback has completed a request, it memcpy's from the
> shared memory, into the bvec supplied. A record that the {gref, page}
> tuple is mapped, and not inflight is kept.
> 
> Writes are similar, except that the memcpy is peformed from the
> supplied bvecs, into the shared pages, before the request is put onto
> the ring.
> 
> Blkback has to store a mapping of grefs=>{page mapped to by gref} in
> an array. As the grefs are not known apriori, and provide no
> guarantees on their ordering, we have to perform a linear search
> through this array to find the page, for every gref we receive. The
> overhead of this is low, however future work might want to use a more
> efficient data structure to reduce this O(n) operation.
> 
> We (ijc, and myself) have introduced a new constant,
> BLKIF_MAX_PERS_REQUESTS_PER_DEV. This is to prevent a malicious guest
> from attempting a DoS, by supplying fresh grefs, causing the Dom0
> kernel from to map excessively. This is currently set to 256---the
> maximum number of entires in the ring. As the number of inflight
> requests <= size of ring, 256 is also the maximum sensible size. This
> introduces a maximum overhead of 11MB of mapped memory, per block
> device. In practice, we don't typically use about 60 of these. If the
> guest exceeds the 256 limit, it is either buggy or malicious. We treat
> this in one of two ways:
> 1) If we have mapped <
> BLKIF_MAX_SEGMENTS_PER_REQUEST * BLKIF_MAX_PERS_REQUESTS_PER_DEV
> pages, we will persistently map the grefs. This can occur is previous
> requests have not used all BLKIF_MAX_SEGMENTS_PER_REQUEST segments.
> 2) Otherwise, we revert to non-persistent grants for all future grefs.
> 
> In writing this patch, the question arrises as to if the additional
> cost of performing memcpys in the guest (to/from the pool of granted
> pages) outweigh the gains of not performing TLB shootdowns. The answer
> to that question is `no'. There appears to be very little, if any
> additional cost to the guest of using persistent grants. There is
> perhaps a small saving, from the reduced number of hypercalls
> performed in granting, and ending foreign access.
> 
> 
> Signed-off-by: Oliver Chick <oliver.chick@citrix.com>
> ---
>  drivers/block/xen-blkback/blkback.c |  149 +++++++++++++++++++++++++---
>  drivers/block/xen-blkback/common.h  |   16 +++
>  drivers/block/xen-blkback/xenbus.c  |   21 +++-
>  drivers/block/xen-blkfront.c        |  186 ++++++++++++++++++++++++++++++-----
>  include/xen/interface/io/blkif.h    |    9 ++
>  5 files changed, 338 insertions(+), 43 deletions(-)
> 
> diff --git a/drivers/block/xen-blkback/blkback.c b/drivers/block/xen-blkback/blkback.c
> index 73f196c..f95dee9 100644
> --- a/drivers/block/xen-blkback/blkback.c
> +++ b/drivers/block/xen-blkback/blkback.c
> @@ -78,6 +78,7 @@ struct pending_req {
>  	unsigned short		operation;
>  	int			status;
>  	struct list_head	free_list;
> +	u8			is_pers;

Just do what you did in the blkfront.c:

	unsigned int feature_persistent:1

or:
	unsigned int flag_persistent:1

or:
	unsigned int flag_pers_gnt:1

>  };
>  
>  #define BLKBACK_INVALID_HANDLE (~0)
> @@ -128,6 +129,24 @@ static int dispatch_rw_block_io(struct xen_blkif *blkif,
>  static void make_response(struct xen_blkif *blkif, u64 id,
>  			  unsigned short op, int st);
>  
> +static void add_pers_gnt(struct pers_gnt *pers_gnt, struct xen_blkif *blkif)
> +{
> +	BUG_ON(blkif->pers_gnt_c >= BLKIF_MAX_PERS_REQUESTS_PER_DEV *
> +	       BLKIF_MAX_SEGMENTS_PER_REQUEST);
> +	blkif->pers_gnts[blkif->pers_gnt_c++] = pers_gnt;
> +}
> +
> +static struct pers_gnt *get_pers_gnt(struct xen_blkif *blkif,
> +				     grant_ref_t gref)
> +{
> +	int i;
> +
> +	for (i = 0; i < blkif->pers_gnt_c; i++)
> +		if (gref == blkif->pers_gnts[i]->gnt)
> +			return blkif->pers_gnts[i];
> +	return NULL;
> +}
> +
>  /*
>   * Retrieve from the 'pending_reqs' a free pending_req structure to be used.
>   */
> @@ -274,6 +293,12 @@ int xen_blkif_schedule(void *arg)
>  {
>  	struct xen_blkif *blkif = arg;
>  	struct xen_vbd *vbd = &blkif->vbd;
> +	struct gnttab_unmap_grant_ref unmap[BLKIF_MAX_SEGMENTS_PER_REQUEST];
> +	struct page *pages[BLKIF_MAX_SEGMENTS_PER_REQUEST];
> +	struct pers_gnt *pers_gnt;
> +	int i;
> +	int ret = 0;
> +	int segs_to_unmap;
>  
>  	xen_blkif_get(blkif);
>  
> @@ -301,6 +326,29 @@ int xen_blkif_schedule(void *arg)
>  			print_stats(blkif);
>  	}
>  
> +	/* Free all persistent grant pages */
> +
> +	while (segs_to_unmap = min(BLKIF_MAX_SEGMENTS_PER_REQUEST,
> +				 blkif->pers_gnt_c)) {
> +
> +		for (i = 0; i < segs_to_unmap; i++) {
> +			pers_gnt = blkif->pers_gnts[blkif->pers_gnt_c - i - 1];
> +
> +			gnttab_set_unmap_op(&unmap[i],
> +					    pfn_to_kaddr(page_to_pfn(
> +							     pers_gnt->page)),
> +					    GNTMAP_host_map,
> +					    pers_gnt->handle);
> +
> +			pages[i] = pers_gnt->page;
> +		}
> +
> +		ret = gnttab_unmap_refs(unmap, pages, segs_to_unmap, false);
> +		BUG_ON(ret);
> +
> +		blkif->pers_gnt_c -= segs_to_unmap;
> +
> +	}
> +
>  	if (log_stats)
>  		print_stats(blkif);
>  
> @@ -343,13 +391,28 @@ static void xen_blkbk_unmap(struct pending_req *req)
>  
>  static int xen_blkbk_map(struct blkif_request *req,
>  			 struct pending_req *pending_req,
> -			 struct seg_buf seg[])
> +			 struct seg_buf seg[],
> +			 struct page *pages[])
>  {
>  	struct gnttab_map_grant_ref map[BLKIF_MAX_SEGMENTS_PER_REQUEST];
> +	struct pers_gnt *new_pers_gnts[BLKIF_MAX_SEGMENTS_PER_REQUEST];
> +	struct pers_gnt *pers_gnts[BLKIF_MAX_SEGMENTS_PER_REQUEST];
> +	struct page *pages_to_gnt[BLKIF_MAX_SEGMENTS_PER_REQUEST];
> +	struct pers_gnt *pers_gnt;
> +	phys_addr_t addr;
>  	int i;
> +	int new_map;
>  	int nseg = req->u.rw.nr_segments;
> +	int segs_to_init = 0;

segs_to_map is probably a better name.

>  	int ret = 0;
> +	int use_pers_gnts;
>  
> +	use_pers_gnts = (pending_req->blkif->can_grant_persist &&
> +			 pending_req->blkif->pers_gnt_c <
> +			 BLKIF_MAX_SEGMENTS_PER_REQUEST *
> +			 BLKIF_MAX_PERS_REQUESTS_PER_DEV);
> +
> +	pending_req->is_pers = use_pers_gnts;
>  	/*
>  	 * Fill out preq.nr_sects with proper amount of sectors, and setup
>  	 * assign map[..] with the PFN of the page in our domain with the
> @@ -358,36 +421,87 @@ static int xen_blkbk_map(struct blkif_request *req,
>  	for (i = 0; i < nseg; i++) {
>  		uint32_t flags;
>  
> +		if (use_pers_gnts) {
> +			pers_gnt = get_pers_gnt(pending_req->blkif,
> +						req->u.rw.seg[i].gref);
> +			if (!pers_gnt) {
> +				new_map = 1;
> +				pers_gnt = kmalloc(sizeof(struct pers_gnt),
> +						   GFP_KERNEL);
> +				if (!pers_gnt)
> +					return -ENOMEM;
> +				pers_gnt->page = alloc_page(GFP_KERNEL);
> +				if (!pers_gnt->page)
> +					return -ENOMEM;

You want to kfree pers_gnt here.

> +				pers_gnt->gnt = req->u.rw.seg[i].gref;
> +
> +				pages_to_gnt[segs_to_init] = pers_gnt->page;
> +				new_pers_gnts[segs_to_init] = pers_gnt;
> +
> +				add_pers_gnt(pers_gnt, pending_req->blkif);
> +
> +			} else {
> +				new_map = 0;
> +			}
> +			pages[i] = pers_gnt->page;
> +			addr = (unsigned long) pfn_to_kaddr(
> +				page_to_pfn(pers_gnt->page));

Would it make sense to cache this in the 'pers_gnt' structure?

> +			pers_gnts[i] = pers_gnt;
> +		} else {
> +			new_map = 1;
> +			pages[i] = blkbk->pending_page(pending_req, i);
> +			addr = vaddr(pending_req, i);
> +			pages_to_gnt[i] = blkbk->pending_page(pending_req, i);
> +		}
> +
>  		flags = GNTMAP_host_map;
> -		if (pending_req->operation != BLKIF_OP_READ)
> +		if (!use_pers_gnts && (pending_req->operation != BLKIF_OP_READ))
>  			flags |= GNTMAP_readonly;
> -		gnttab_set_map_op(&map[i], vaddr(pending_req, i), flags,
> -				  req->u.rw.seg[i].gref,
> -				  pending_req->blkif->domid);
> +		if (new_map) {
> +			gnttab_set_map_op(&map[segs_to_init++], addr,
> +					  flags, req->u.rw.seg[i].gref,
> +					  pending_req->blkif->domid);
> +		}
>  	}
>  
> -	ret = gnttab_map_refs(map, NULL, &blkbk->pending_page(pending_req, 0), nseg);
> -	BUG_ON(ret);
> +	if (segs_to_init) {
> +		ret = gnttab_map_refs(map, NULL, pages_to_gnt, segs_to_init);
> +		BUG_ON(ret);
> +	}
>  
>  	/*
>  	 * Now swizzle the MFN in our domain with the MFN from the other domain
>  	 * so that when we access vaddr(pending_req,i) it has the contents of
>  	 * the page from the other domain.
>  	 */
> -	for (i = 0; i < nseg; i++) {
> +	for (i = 0; i < segs_to_init; i++) {
>  		if (unlikely(map[i].status != 0)) {
>  			pr_debug(DRV_PFX "invalid buffer -- could not remap it\n");
>  			map[i].handle = BLKBACK_INVALID_HANDLE;
>  			ret |= 1;
>  		}
>  
> -		pending_handle(pending_req, i) = map[i].handle;
> +		if (use_pers_gnts) {
> +			/* store the `out' values from map */
> +		    pending_req->blkif->pers_gnts
> +			[pending_req->blkif->pers_gnt_c - segs_to_init +
> +			 i]->handle = map[i].handle;
> +			new_pers_gnts[i]->dev_bus_addr = map[i].dev_bus_addr;
> +		}
>  
>  		if (ret)
>  			continue;
> -
> -		seg[i].buf  = map[i].dev_bus_addr |
> -			(req->u.rw.seg[i].first_sect << 9);
> +	}
> +	for (i = 0; i < nseg; i++) {
> +		if (use_pers_gnts) {
> +			pending_handle(pending_req, i) = pers_gnts[i]->handle;
> +			seg[i].buf = pers_gnts[i]->dev_bus_addr |
> +				(req->u.rw.seg[i].first_sect << 9);
> +		} else {
> +			pending_handle(pending_req, i) = map[i].handle;
> +			seg[i].buf = map[i].dev_bus_addr |
> +				(req->u.rw.seg[i].first_sect << 9);
> +		}
>  	}
>  	return ret;
>  }
> @@ -468,7 +582,8 @@ static void __end_block_io_op(struct pending_req *pending_req, int error)
>  	 * the proper response on the ring.
>  	 */
>  	if (atomic_dec_and_test(&pending_req->pendcnt)) {
> -		xen_blkbk_unmap(pending_req);
> +		if (!pending_req->is_pers)
> +			xen_blkbk_unmap(pending_req);
>  		make_response(pending_req->blkif, pending_req->id,
>  			      pending_req->operation, pending_req->status);
>  		xen_blkif_put(pending_req->blkif);
> @@ -590,6 +705,7 @@ static int dispatch_rw_block_io(struct xen_blkif *blkif,
>  	int operation;
>  	struct blk_plug plug;
>  	bool drain = false;
> +	struct page *pages[BLKIF_MAX_SEGMENTS_PER_REQUEST];
>  
>  	switch (req->operation) {
>  	case BLKIF_OP_READ:
> @@ -676,7 +792,7 @@ static int dispatch_rw_block_io(struct xen_blkif *blkif,
>  	 * the hypercall to unmap the grants - that is all done in
>  	 * xen_blkbk_unmap.
>  	 */
> -	if (xen_blkbk_map(req, pending_req, seg))
> +	if (xen_blkbk_map(req, pending_req, seg, pages))
>  		goto fail_flush;
>  
>  	/*
> @@ -688,7 +804,7 @@ static int dispatch_rw_block_io(struct xen_blkif *blkif,
>  	for (i = 0; i < nseg; i++) {
>  		while ((bio == NULL) ||
>  		       (bio_add_page(bio,
> -				     blkbk->pending_page(pending_req, i),

Can we get rid of pending_page macro?

> +				     pages[i],
>  				     seg[i].nsec << 9,
>  				     seg[i].buf & ~PAGE_MASK) == 0)) {
>  
> @@ -743,7 +859,8 @@ static int dispatch_rw_block_io(struct xen_blkif *blkif,
>  	return 0;
>  
>   fail_flush:
> -	xen_blkbk_unmap(pending_req);
> +	if (!blkif->can_grant_persist)
> +		xen_blkbk_unmap(pending_req);
>   fail_response:
>  	/* Haven't submitted any bio's yet. */
>  	make_response(blkif, req->u.rw.id, req->operation, BLKIF_RSP_ERROR);
> diff --git a/drivers/block/xen-blkback/common.h b/drivers/block/xen-blkback/common.h
> index 9ad3b5e..1ecb709 100644
> --- a/drivers/block/xen-blkback/common.h
> +++ b/drivers/block/xen-blkback/common.h
> @@ -47,6 +47,8 @@
>  #define DPRINTK(fmt, args...)				\
>  	pr_debug(DRV_PFX "(%s:%d) " fmt ".\n",		\
>  		 __func__, __LINE__, ##args)
> +#define BLKIF_MAX_PERS_REQUESTS_PER_DEV 256

You need a comment explaining why this number.

> +
>  
>  
>  /* Not a real protocol.  Used to generate ring structs which contain
> @@ -164,6 +166,14 @@ struct xen_vbd {
>  
>  struct backend_info;
>  
> +
> +struct pers_gnt {
> +	struct page *page;
> +	grant_ref_t gnt;
> +	uint32_t handle;

Not grant_handle_t ?

> +	uint64_t dev_bus_addr;
> +};
> +
>  struct xen_blkif {
>  	/* Unique identifier for this interface. */
>  	domid_t			domid;
> @@ -190,6 +200,12 @@ struct xen_blkif {
>  	struct task_struct	*xenblkd;
>  	unsigned int		waiting_reqs;
>  
> +	/* frontend feature information */
> +	u8			can_grant_persist:1;

Pls move that to the vbd structure, and if you feel
especially adventourous, you could modify the

bool flush_support
bool discard_secure

to be 'unsigned int feature_flush:1' ,etc.. as its own
seperate patch and then introduce the

unsigned int feature_grnt_pers:1

flag.
> +	struct pers_gnt		*pers_gnts[BLKIF_MAX_PERS_REQUESTS_PER_DEV *
> +					  BLKIF_MAX_SEGMENTS_PER_REQUEST];
> +	unsigned int		pers_gnt_c;
> +
>  	/* statistics */
>  	unsigned long		st_print;
>  	int			st_rd_req;
> diff --git a/drivers/block/xen-blkback/xenbus.c b/drivers/block/xen-blkback/xenbus.c
> index 4f66171..dc58cc4 100644
> --- a/drivers/block/xen-blkback/xenbus.c
> +++ b/drivers/block/xen-blkback/xenbus.c
> @@ -681,6 +681,13 @@ again:
>  		goto abort;
>  	}
>  
> +	err = xenbus_printf(xbt, dev->nodename, "feature-persistent-grants",
> +			    "%d", 1);
> +	if (err) {
> +		xenbus_dev_fatal(dev, err, "writing persistent capability");

It is not fatal. Just do dev_warn, like the xen_blkbk_discard does.

> +		goto abort;
> +	}
> +
>  	/* FIXME: use a typename instead */
>  	err = xenbus_printf(xbt, dev->nodename, "info", "%u",
>  			    be->blkif->vbd.type |
> @@ -721,6 +728,7 @@ static int connect_ring(struct backend_info *be)
>  	struct xenbus_device *dev = be->dev;
>  	unsigned long ring_ref;
>  	unsigned int evtchn;
> +	u8 pers_grants;
>  	char protocol[64] = "";
>  	int err;
>  
> @@ -750,8 +758,17 @@ static int connect_ring(struct backend_info *be)
>  		xenbus_dev_fatal(dev, err, "unknown fe protocol %s", protocol);
>  		return -1;
>  	}
> -	pr_info(DRV_PFX "ring-ref %ld, event-channel %d, protocol %d (%s)\n",
> -		ring_ref, evtchn, be->blkif->blk_protocol, protocol);
> +	err = xenbus_gather(XBT_NIL, dev->otherend,
> +			    "feature-persistent-grants", "%d",
> +			    &pers_grants, NULL);
> +	if (err)
> +		pers_grants = 0;
> +
> +	be->blkif->can_grant_persist = pers_grants;

We should also have a patch for the Xen blkif.h to document this feature.. but that
can be done later.

> +
> +	pr_info(DRV_PFX "ring-ref %ld, event-channel %d, protocol %d (%s) persistent %d\n",
> +		ring_ref, evtchn, be->blkif->blk_protocol, protocol,
> +		pers_grants);
>  
>  	/* Map the shared frame, irq etc. */
>  	err = xen_blkif_map(be->blkif, ring_ref, evtchn);
> diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c
> index e4fb337..c1cc5fe 100644
> --- a/drivers/block/xen-blkfront.c
> +++ b/drivers/block/xen-blkfront.c
> @@ -68,6 +68,13 @@ struct blk_shadow {
>  	struct blkif_request req;
>  	struct request *request;
>  	unsigned long frame[BLKIF_MAX_SEGMENTS_PER_REQUEST];
> +	struct gnt_list *grants_used[BLKIF_MAX_SEGMENTS_PER_REQUEST];
> +};
> +
> +struct gnt_list {
> +	grant_ref_t gref;
> +	unsigned long frame;

Pls mention what 'frame' is and what the other ones do.

> +	struct gnt_list *tail;
>  };

How did the compiler actually compile this? You are using it in 'struct blk_shadow'
but it is declared later?
>  
>  static DEFINE_MUTEX(blkfront_mutex);
> @@ -97,11 +104,14 @@ struct blkfront_info
>  	struct work_struct work;
>  	struct gnttab_free_callback callback;
>  	struct blk_shadow shadow[BLK_RING_SIZE];
> +	struct gnt_list *persistent_grants_front;

I don't think you need the 'front' in there. Its obvious you are
in the frontend code.

> +	unsigned int persistent_grants_c;
>  	unsigned long shadow_free;
>  	unsigned int feature_flush;
>  	unsigned int flush_op;
>  	unsigned int feature_discard:1;
>  	unsigned int feature_secdiscard:1;
> +	unsigned int feature_persistent:1;
>  	unsigned int discard_granularity;
>  	unsigned int discard_alignment;
>  	int is_ready;
> @@ -286,22 +296,37 @@ static int blkif_queue_request(struct request *req)
>  	struct blkif_request *ring_req;
>  	unsigned long id;
>  	unsigned int fsect, lsect;
> -	int i, ref;
> +	int i, ref, use_pers_gnts, new_pers_gnts;

use_pers_gnts and new_pers_gnt? Can you document what the difference
is pls?

Perhaps 'new_pers_gnts' should be called:
'got_grant'? or 'using_grant' ?

>  	grant_ref_t gref_head;
> +	struct bio_vec *bvecs[BLKIF_MAX_SEGMENTS_PER_REQUEST];
> +	struct bio_vec *bvec;
> +	struct req_iterator iter;
> +	char *bvec_data;
> +	void *shared_data;
> +	unsigned long flags;

What kind of flags?
> +	struct page *shared_page;

It is not really shared_page. It is a temporary page. Perhaps
tmp_page ?

> +	struct gnt_list *gnt_list_entry;
>  	struct scatterlist *sg;
>  
>  	if (unlikely(info->connected != BLKIF_STATE_CONNECTED))
>  		return 1;
>  
> -	if (gnttab_alloc_grant_references(
> -		BLKIF_MAX_SEGMENTS_PER_REQUEST, &gref_head) < 0) {
> -		gnttab_request_free_callback(
> -			&info->callback,
> -			blkif_restart_queue_callback,
> -			info,
> -			BLKIF_MAX_SEGMENTS_PER_REQUEST);
> -		return 1;
> +	use_pers_gnts = info->feature_persistent;
> +
> +	if (info->persistent_grants_c < BLKIF_MAX_SEGMENTS_PER_REQUEST) {
> +		new_pers_gnts = 1;
> +		if (gnttab_alloc_grant_references(
> +			    BLKIF_MAX_SEGMENTS_PER_REQUEST, &gref_head) < 0) {
> +			gnttab_request_free_callback(
> +				&info->callback,
> +				blkif_restart_queue_callback,
> +				info,
> +				BLKIF_MAX_SEGMENTS_PER_REQUEST);
> +			return 1;
> +		}
>  	} else
> +		new_pers_gnts = 0;
>  
>  	/* Fill out a communications ring structure. */
>  	ring_req = RING_GET_REQUEST(&info->ring, info->ring.req_prod_pvt);
> @@ -341,20 +366,66 @@ static int blkif_queue_request(struct request *req)
>  		       BLKIF_MAX_SEGMENTS_PER_REQUEST);
>  
>  		for_each_sg(info->sg, sg, ring_req->u.rw.nr_segments, i) {
> -			buffer_mfn = pfn_to_mfn(page_to_pfn(sg_page(sg)));
>  			fsect = sg->offset >> 9;
>  			lsect = fsect + (sg->length >> 9) - 1;
> -			/* install a grant reference. */
> -			ref = gnttab_claim_grant_reference(&gref_head);
> -			BUG_ON(ref == -ENOSPC);
>  
> -			gnttab_grant_foreign_access_ref(
> +			if (use_pers_gnts && info->persistent_grants_c) {
> +				gnt_list_entry = info->persistent_grants_front;
> +
> +				info->persistent_grants_front =
> +					info->persistent_grants_front->tail;
> +				ref = gnt_list_entry->gref;
> +				buffer_mfn = pfn_to_mfn(gnt_list_entry->frame);

Ah, so frame is a PFN! why don't you just call it that?

> +				info->persistent_grants_c--;
> +			} else {
> +				ref = gnttab_claim_grant_reference(&gref_head);
> +				BUG_ON(ref == -ENOSPC);
> +
> +				if (use_pers_gnts) {
> +					gnt_list_entry =
> +						kmalloc(sizeof(struct gnt_list),
> +								 GFP_ATOMIC);
> +					if (!gnt_list_entry)
> +						return -ENOMEM;
> +
> +					shared_page = alloc_page(GFP_ATOMIC);
> +					if (!shared_page)
> +						return -ENOMEM;

Make sure to kfree gnt_list_entry.

> +
> +					gnt_list_entry->frame =
> +						page_to_pfn(shared_page);
> +					gnt_list_entry->gref = ref;
> +				} else
> +					shared_page = sg_page(sg);
> +
> +				buffer_mfn = pfn_to_mfn(page_to_pfn(
> +								shared_page));
> +				gnttab_grant_foreign_access_ref(
>  					ref,
>  					info->xbdev->otherend_id,
>  					buffer_mfn,
> -					rq_data_dir(req));
> +					!use_pers_gnts && rq_data_dir(req));
> +			}
> +
> +			if (use_pers_gnts)
> +				info->shadow[id].grants_used[i] =
> +					gnt_list_entry;
> +
> +			if (use_pers_gnts && rq_data_dir(req)) {

You can declare the 'shared_data' here:

				void *shared_data;

and also bvec_data.

> +				shared_data = kmap_atomic(
> +					pfn_to_page(gnt_list_entry->frame));
> +				bvec_data = kmap_atomic(sg_page(sg));
> +
> +				memcpy(shared_data + sg->offset,
> +				       bvec_data   + sg->offset,
> +				       sg->length);

Do we need to worry about it spilling over a page? Should we check that
sg>offset + sg->length < PAGE_SIZE ?

Also this would imply that based on the offset (so say it is 3999) that the old data (0->3998)
might be still there - don't know how important that is?
> +
> +				kunmap_atomic(bvec_data);
> +				kunmap_atomic(shared_data);
> +			}
>  
>  			info->shadow[id].frame[i] = mfn_to_pfn(buffer_mfn);
> +
>  			ring_req->u.rw.seg[i] =
>  					(struct blkif_request_segment) {
>  						.gref       = ref,
> @@ -368,7 +439,8 @@ static int blkif_queue_request(struct request *req)
>  	/* Keep a private copy so we can reissue requests when recovering. */
>  	info->shadow[id].req = *ring_req;
>  
> -	gnttab_free_grant_references(gref_head);
> +	if (new_pers_gnts)
> +		gnttab_free_grant_references(gref_head);
>  
>  	return 0;
>  }
> @@ -480,12 +552,13 @@ static int xlvbd_init_blk_queue(struct gendisk *gd, u16 sector_size)
>  static void xlvbd_flush(struct blkfront_info *info)
>  {
>  	blk_queue_flush(info->rq, info->feature_flush);
> -	printk(KERN_INFO "blkfront: %s: %s: %s\n",
> +	printk(KERN_INFO "blkfront: %s: %s: %s. Persistent=%d\n",

Just use %s like the rest
>  	       info->gd->disk_name,
>  	       info->flush_op == BLKIF_OP_WRITE_BARRIER ?
>  		"barrier" : (info->flush_op == BLKIF_OP_FLUSH_DISKCACHE ?
>  		"flush diskcache" : "barrier or flush"),
> -	       info->feature_flush ? "enabled" : "disabled");
> +	       info->feature_flush ? "enabled" : "disabled",
> +	    info->feature_persistent);

and this can be 'info->feature_persistent ? "persitent" : "".

>  }
>  
>  static int xen_translate_vdev(int vdevice, int *minor, unsigned int *offset)
> @@ -707,6 +780,8 @@ static void blkif_restart_queue(struct work_struct *work)
>  
>  static void blkif_free(struct blkfront_info *info, int suspend)
>  {
> +	struct gnt_list *pers_gnt;
> +
>  	/* Prevent new requests being issued until we fix things up. */
>  	spin_lock_irq(&info->io_lock);
>  	info->connected = suspend ?
> @@ -714,6 +789,15 @@ static void blkif_free(struct blkfront_info *info, int suspend)
>  	/* No more blkif_request(). */
>  	if (info->rq)
>  		blk_stop_queue(info->rq);
> +
> +	/* Remove all persistent grants */
> +	while (info->persistent_grants_front) {
> +		pers_gnt = info->persistent_grants_front;
> +		info->persistent_grants_front = pers_gnt->tail;
> +		gnttab_end_foreign_access(pers_gnt->gref, 0, 0UL);
> +		kfree(pers_gnt);
> +	}
> +
>  	/* No more gnttab callback work. */
>  	gnttab_cancel_free_callback(&info->callback);
>  	spin_unlock_irq(&info->io_lock);
> @@ -734,13 +818,44 @@ static void blkif_free(struct blkfront_info *info, int suspend)
>  
>  }
>  
> -static void blkif_completion(struct blk_shadow *s)
> +static void blkif_completion(struct blk_shadow *s, struct blkfront_info *info,
> +			     struct blkif_response *bret)
>  {
>  	int i;
> -	/* Do not let BLKIF_OP_DISCARD as nr_segment is in the same place
> -	 * flag. */
> -	for (i = 0; i < s->req.u.rw.nr_segments; i++)
> -		gnttab_end_foreign_access(s->req.u.rw.seg[i].gref, 0, 0UL);
> +	struct gnt_list *new_gnt_list_entry;
> +	struct bio_vec *bvec;
> +	struct req_iterator iter;
> +	unsigned long flags;
> +	char *bvec_data;
> +	void *shared_data;
> +
> +	i = 0;
> +	if (info->feature_persistent == 0) {
> +		/* Do not let BLKIF_OP_DISCARD as nr_segment is in the same
> +		 * place flag. */
> +		for (i = 0; i < s->req.u.rw.nr_segments; i++)
> +			gnttab_end_foreign_access(s->req.u.rw.seg[i].gref,
> +						  0, 0UL);
> +		return;
> +	}
> +

Move the 'i = 0' to here.

> +	if (bret->operation == BLKIF_OP_READ)
> +		rq_for_each_segment(bvec, s->request, iter) {
> +			shared_data = kmap_atomic
> +				(pfn_to_page(s->grants_used[i++]->frame));
> +			bvec_data = bvec_kmap_irq(bvec, &flags);
> +			memcpy(bvec_data, shared_data + bvec->bv_offset,
> +			       bvec->bv_len);
> +			bvec_kunmap_irq(bvec_data, &flags);
> +			kunmap_atomic(shared_data);
> +		}
> +	/* Add the persistent grant into the list of free grants */
> +	for (i = 0; i < s->req.u.rw.nr_segments; i++) {
> +		new_gnt_list_entry = s->grants_used[i];
> +		new_gnt_list_entry->tail = info->persistent_grants_front;
> +		info->persistent_grants_front = new_gnt_list_entry;
> +		info->persistent_grants_c++;
> +	}
>  }
>  
>  static irqreturn_t blkif_interrupt(int irq, void *dev_id)
> @@ -783,7 +898,7 @@ static irqreturn_t blkif_interrupt(int irq, void *dev_id)
>  		req  = info->shadow[id].request;
>  
>  		if (bret->operation != BLKIF_OP_DISCARD)
> -			blkif_completion(&info->shadow[id]);
> +			blkif_completion(&info->shadow[id], info, bret);
>  
>  		if (add_id_to_freelist(info, id)) {
>  			WARN(1, "%s: response to %s (id %ld) couldn't be recycled!\n",
> @@ -943,6 +1058,12 @@ again:
>  		message = "writing protocol";
>  		goto abort_transaction;
>  	}
> +	err = xenbus_printf(xbt, dev->nodename,
> +			    "feature-persistent-grants", "%d", 1);
> +	if (err) {
> +		message = "Writing persistent grants front feature";
> +		goto abort_transaction;

I wouldn't abort. Just continue on using the non-grant feature.

> +	}
>  
>  	err = xenbus_transaction_end(xbt, 0);
>  	if (err) {
> @@ -1030,6 +1151,7 @@ static int blkfront_probe(struct xenbus_device *dev,
>  	spin_lock_init(&info->io_lock);
>  	info->xbdev = dev;
>  	info->vdevice = vdevice;
> +	info->persistent_grants_c = 0;
>  	info->connected = BLKIF_STATE_DISCONNECTED;
>  	INIT_WORK(&info->work, blkif_restart_queue);
>  
> @@ -1094,6 +1216,7 @@ static int blkif_recover(struct blkfront_info *info)
>  					req->u.rw.seg[j].gref,
>  					info->xbdev->otherend_id,
>  					pfn_to_mfn(info->shadow[req->u.rw.id].frame[j]),
> +					!info->feature_persistent &&
>  					rq_data_dir(info->shadow[req->u.rw.id].request));
>  		}
>  		info->shadow[req->u.rw.id].req = *req;
> @@ -1226,7 +1349,7 @@ static void blkfront_connect(struct blkfront_info *info)
>  	unsigned long sector_size;
>  	unsigned int binfo;
>  	int err;
> -	int barrier, flush, discard;
> +	int barrier, flush, discard, persistent;
>  
>  	switch (info->connected) {
>  	case BLKIF_STATE_CONNECTED:
> @@ -1297,6 +1420,19 @@ static void blkfront_connect(struct blkfront_info *info)
>  		info->flush_op = BLKIF_OP_FLUSH_DISKCACHE;
>  	}
>  
> +	/*
> +	 * Are we dealing with an old blkback that will unmap
> +	 * all grefs?
> +	 */
> +	err = xenbus_gather(XBT_NIL, info->xbdev->otherend,
> +			    "feature-persistent-grants", "%d", &persistent,
> +			    NULL);
> +
> +	if (err)
> +		info->feature_persistent = 0;
> +	else
> +		info->feature_persistent = persistent;
> +
>  	err = xenbus_gather(XBT_NIL, info->xbdev->otherend,
>  			    "feature-discard", "%d", &discard,
>  			    NULL);
> diff --git a/include/xen/interface/io/blkif.h b/include/xen/interface/io/blkif.h
> index ee338bf..cd267a9b 100644
> --- a/include/xen/interface/io/blkif.h
> +++ b/include/xen/interface/io/blkif.h
> @@ -109,6 +109,15 @@ typedef uint64_t blkif_sector_t;
>   */
>  #define BLKIF_MAX_SEGMENTS_PER_REQUEST 11
>  
> +/*
> + * Maximum number of persistent grants that can be mapped by Dom0 for each

by blkback
> + * interface. This is set to be the size of the ring, as this is a limit on

Size of the ring? You sure?
> + * the number of requests that can be inflight at any one time. 256 imposes
> + * an overhead of 11MB of mapped kernel space per interface.
> + */
> +#define BLKIF_MAX_PERS_REQUESTS_PER_DEV 256
> +
> +
>  struct blkif_request_rw {
>  	uint8_t        nr_segments;  /* number of segments                   */
>  	blkif_vdev_t   handle;       /* only for read/write requests         */
> -- 
> 1.7.9.5

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 19 14:45:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Sep 2012 14: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 1TELWr-0008Lj-Sc; Wed, 19 Sep 2012 14:45:29 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1TELWq-0008Le-3z
	for xen-devel@lists.xen.org; Wed, 19 Sep 2012 14:45:28 +0000
Received: from [85.158.138.51:5557] by server-10.bemta-3.messagelabs.com id
	8E/7E-10411-78AD9505; Wed, 19 Sep 2012 14:45:27 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1348065925!23590958!1
X-Originating-IP: [209.85.215.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31471 invoked from network); 19 Sep 2012 14:45:26 -0000
Received: from mail-ey0-f173.google.com (HELO mail-ey0-f173.google.com)
	(209.85.215.173)
	by server-10.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Sep 2012 14:45:26 -0000
Received: by eaac13 with SMTP id c13so371851eaa.32
	for <xen-devel@lists.xen.org>; Wed, 19 Sep 2012 07:45:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=SHNya6szLTgVSCa7hWQYHFZItXVJQk77I5sLA2Ph7/o=;
	b=PCS3CUZpDg+cQfE9m43z8zvObV3NhlLcMxjBVDB+n8smJDU/0vvfpb28OVJ4GjzekC
	Zw/4Ul77MPy5jLfwmdjS8FYUsMdbq3KUK6seNIrrsyc4sUhjsR2sYHCCQt0b+Fx3OtNv
	cn/y95Jk3+GzHWJyd4OdIfEqS486isM9zyeLKo2fJw8p+1RAPAvCTnYD2upMtGYNNHPr
	GONFeGTdGPRTrVMTLu5pd9t9w1p4zxEhITsK2x1vifLPCqFdB8pO49ZNOR/prntpDmpG
	dx+yeXf64STgtSOxESYUNaK61aB3L332VKmEOBeHgopWlysQ10n57meWkhflLY78dnym
	Z8Kg==
Received: by 10.14.184.134 with SMTP id s6mr3783310eem.46.1348065925693;
	Wed, 19 Sep 2012 07:45:25 -0700 (PDT)
Received: from [192.168.1.3] (host86-167-82-156.range86-167.btcentralplus.com.
	[86.167.82.156])
	by mx.google.com with ESMTPS id l42sm7911314eep.1.2012.09.19.07.45.23
	(version=SSLv3 cipher=OTHER); Wed, 19 Sep 2012 07:45:25 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.33.0.120411
Date: Wed, 19 Sep 2012 15:45:12 +0100
From: Keir Fraser <keir@xen.org>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <CC7F9908.4C668%keir@xen.org>
Thread-Topic: [PATCH, v2] ACPI: move tables.c fully into .init.*
Thread-Index: Ac2WdV9upJ4EeK82lEmLThGhNu7fEQ==
In-Reply-To: <5059DCFD020000780009C50F@nat28.tlf.novell.com>
Mime-version: 1.0
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH, v2] ACPI: move tables.c fully into .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 19/09/2012 13:55, "Jan Beulich" <JBeulich@suse.com> wrote:

> The only non-init item was the space reserved for the initial tables,
> but we can as well dynamically allocate that array.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Acked-by: Keir Fraser <keir@xen.org>

> ---
> v2: Do allocation via the already existing, but so far broken re-sizing
>     logic (requires properly handling the early boot case in ACPI's
>     allocation abstractions).
> 
> --- a/xen/drivers/acpi/Makefile
> +++ b/xen/drivers/acpi/Makefile
> @@ -2,7 +2,7 @@ subdir-y += tables
>  subdir-y += utilities
>  subdir-$(x86) += apei
>  
> -obj-y += tables.o
> +obj-bin-y += tables.init.o
>  obj-y += numa.o
>  obj-y += osl.o
>  obj-y += pmstat.o
> --- a/xen/drivers/acpi/osl.c
> +++ b/xen/drivers/acpi/osl.c
> @@ -27,6 +27,7 @@
>  #include <asm/io.h>
>  #include <xen/config.h>
>  #include <xen/init.h>
> +#include <xen/pfn.h>
>  #include <xen/types.h>
>  #include <xen/errno.h>
>  #include <xen/acpi.h>
> @@ -182,3 +183,38 @@ acpi_os_write_memory(acpi_physical_addre
>  
> return AE_OK;
>  }
> +
> +#define is_xmalloc_memory(ptr) ((unsigned long)(ptr) & (PAGE_SIZE - 1))
> +
> +void *__init acpi_os_alloc_memory(size_t sz)
> +{
> + void *ptr;
> +
> + if (system_state == SYS_STATE_early_boot)
> +  return mfn_to_virt(alloc_boot_pages(PFN_UP(sz), 1));
> +
> + ptr = xmalloc_bytes(sz);
> + ASSERT(!ptr || is_xmalloc_memory(ptr));
> + return ptr;
> +}
> +
> +void *__init acpi_os_zalloc_memory(size_t sz)
> +{
> + void *ptr;
> +
> + if (system_state != SYS_STATE_early_boot) {
> +  ptr = xzalloc_bytes(sz);
> +  ASSERT(!ptr || is_xmalloc_memory(ptr));
> +  return ptr;
> + }
> + ptr = acpi_os_alloc_memory(sz);
> + return ptr ? memset(ptr, 0, sz) : NULL;
> +}
> +
> +void __init acpi_os_free_memory(void *ptr)
> +{
> + if (is_xmalloc_memory(ptr))
> +  xfree(ptr);
> + else if (ptr && system_state == SYS_STATE_early_boot)
> +  init_boot_pages(__pa(ptr), __pa(ptr) + PAGE_SIZE);
> +}
> --- a/xen/drivers/acpi/tables.c
> +++ b/xen/drivers/acpi/tables.c
> @@ -41,8 +41,6 @@ mps_inti_flags_polarity[] = { "dfl", "hi
>  static const char *__initdata
>  mps_inti_flags_trigger[] = { "dfl", "edge", "res", "level" };
>  
> -static struct acpi_table_desc initial_tables[ACPI_MAX_TABLES];
> -
>  static int acpi_apic_instance __initdata;
>  
>  void __init acpi_table_print_madt_entry(struct acpi_subtable_header *header)
> @@ -324,7 +322,7 @@ static void __init check_multiple_madt(v
>  
>  int __init acpi_table_init(void)
>  {
> - acpi_initialize_tables(initial_tables, ACPI_MAX_TABLES, 0);
> + acpi_initialize_tables(NULL, ACPI_MAX_TABLES, 0);
> check_multiple_madt();
> return 0;
>  }
> --- a/xen/include/acpi/platform/aclinux.h
> +++ b/xen/include/acpi/platform/aclinux.h
> @@ -76,8 +76,12 @@
>  
>  #define acpi_thread_id struct vcpu *
>  
> -#define ACPI_ALLOCATE(a) xmalloc_bytes(a)
> -#define ACPI_ALLOCATE_ZEROED(a) xzalloc_bytes(a)
> -#define ACPI_FREE(a)  xfree(a)
> +void *acpi_os_alloc_memory(size_t);
> +void *acpi_os_zalloc_memory(size_t);
> +void acpi_os_free_memory(void *);
> +
> +#define ACPI_ALLOCATE(a) acpi_os_alloc_memory(a)
> +#define ACPI_ALLOCATE_ZEROED(a) acpi_os_zalloc_memory(a)
> +#define ACPI_FREE(a)  acpi_os_free_memory(a)
>  
>  #endif    /* __ACLINUX_H__ */
> 
> 
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 19 14:45:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Sep 2012 14: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 1TELWr-0008Lj-Sc; Wed, 19 Sep 2012 14:45:29 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1TELWq-0008Le-3z
	for xen-devel@lists.xen.org; Wed, 19 Sep 2012 14:45:28 +0000
Received: from [85.158.138.51:5557] by server-10.bemta-3.messagelabs.com id
	8E/7E-10411-78AD9505; Wed, 19 Sep 2012 14:45:27 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1348065925!23590958!1
X-Originating-IP: [209.85.215.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31471 invoked from network); 19 Sep 2012 14:45:26 -0000
Received: from mail-ey0-f173.google.com (HELO mail-ey0-f173.google.com)
	(209.85.215.173)
	by server-10.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Sep 2012 14:45:26 -0000
Received: by eaac13 with SMTP id c13so371851eaa.32
	for <xen-devel@lists.xen.org>; Wed, 19 Sep 2012 07:45:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=SHNya6szLTgVSCa7hWQYHFZItXVJQk77I5sLA2Ph7/o=;
	b=PCS3CUZpDg+cQfE9m43z8zvObV3NhlLcMxjBVDB+n8smJDU/0vvfpb28OVJ4GjzekC
	Zw/4Ul77MPy5jLfwmdjS8FYUsMdbq3KUK6seNIrrsyc4sUhjsR2sYHCCQt0b+Fx3OtNv
	cn/y95Jk3+GzHWJyd4OdIfEqS486isM9zyeLKo2fJw8p+1RAPAvCTnYD2upMtGYNNHPr
	GONFeGTdGPRTrVMTLu5pd9t9w1p4zxEhITsK2x1vifLPCqFdB8pO49ZNOR/prntpDmpG
	dx+yeXf64STgtSOxESYUNaK61aB3L332VKmEOBeHgopWlysQ10n57meWkhflLY78dnym
	Z8Kg==
Received: by 10.14.184.134 with SMTP id s6mr3783310eem.46.1348065925693;
	Wed, 19 Sep 2012 07:45:25 -0700 (PDT)
Received: from [192.168.1.3] (host86-167-82-156.range86-167.btcentralplus.com.
	[86.167.82.156])
	by mx.google.com with ESMTPS id l42sm7911314eep.1.2012.09.19.07.45.23
	(version=SSLv3 cipher=OTHER); Wed, 19 Sep 2012 07:45:25 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.33.0.120411
Date: Wed, 19 Sep 2012 15:45:12 +0100
From: Keir Fraser <keir@xen.org>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <CC7F9908.4C668%keir@xen.org>
Thread-Topic: [PATCH, v2] ACPI: move tables.c fully into .init.*
Thread-Index: Ac2WdV9upJ4EeK82lEmLThGhNu7fEQ==
In-Reply-To: <5059DCFD020000780009C50F@nat28.tlf.novell.com>
Mime-version: 1.0
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH, v2] ACPI: move tables.c fully into .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 19/09/2012 13:55, "Jan Beulich" <JBeulich@suse.com> wrote:

> The only non-init item was the space reserved for the initial tables,
> but we can as well dynamically allocate that array.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Acked-by: Keir Fraser <keir@xen.org>

> ---
> v2: Do allocation via the already existing, but so far broken re-sizing
>     logic (requires properly handling the early boot case in ACPI's
>     allocation abstractions).
> 
> --- a/xen/drivers/acpi/Makefile
> +++ b/xen/drivers/acpi/Makefile
> @@ -2,7 +2,7 @@ subdir-y += tables
>  subdir-y += utilities
>  subdir-$(x86) += apei
>  
> -obj-y += tables.o
> +obj-bin-y += tables.init.o
>  obj-y += numa.o
>  obj-y += osl.o
>  obj-y += pmstat.o
> --- a/xen/drivers/acpi/osl.c
> +++ b/xen/drivers/acpi/osl.c
> @@ -27,6 +27,7 @@
>  #include <asm/io.h>
>  #include <xen/config.h>
>  #include <xen/init.h>
> +#include <xen/pfn.h>
>  #include <xen/types.h>
>  #include <xen/errno.h>
>  #include <xen/acpi.h>
> @@ -182,3 +183,38 @@ acpi_os_write_memory(acpi_physical_addre
>  
> return AE_OK;
>  }
> +
> +#define is_xmalloc_memory(ptr) ((unsigned long)(ptr) & (PAGE_SIZE - 1))
> +
> +void *__init acpi_os_alloc_memory(size_t sz)
> +{
> + void *ptr;
> +
> + if (system_state == SYS_STATE_early_boot)
> +  return mfn_to_virt(alloc_boot_pages(PFN_UP(sz), 1));
> +
> + ptr = xmalloc_bytes(sz);
> + ASSERT(!ptr || is_xmalloc_memory(ptr));
> + return ptr;
> +}
> +
> +void *__init acpi_os_zalloc_memory(size_t sz)
> +{
> + void *ptr;
> +
> + if (system_state != SYS_STATE_early_boot) {
> +  ptr = xzalloc_bytes(sz);
> +  ASSERT(!ptr || is_xmalloc_memory(ptr));
> +  return ptr;
> + }
> + ptr = acpi_os_alloc_memory(sz);
> + return ptr ? memset(ptr, 0, sz) : NULL;
> +}
> +
> +void __init acpi_os_free_memory(void *ptr)
> +{
> + if (is_xmalloc_memory(ptr))
> +  xfree(ptr);
> + else if (ptr && system_state == SYS_STATE_early_boot)
> +  init_boot_pages(__pa(ptr), __pa(ptr) + PAGE_SIZE);
> +}
> --- a/xen/drivers/acpi/tables.c
> +++ b/xen/drivers/acpi/tables.c
> @@ -41,8 +41,6 @@ mps_inti_flags_polarity[] = { "dfl", "hi
>  static const char *__initdata
>  mps_inti_flags_trigger[] = { "dfl", "edge", "res", "level" };
>  
> -static struct acpi_table_desc initial_tables[ACPI_MAX_TABLES];
> -
>  static int acpi_apic_instance __initdata;
>  
>  void __init acpi_table_print_madt_entry(struct acpi_subtable_header *header)
> @@ -324,7 +322,7 @@ static void __init check_multiple_madt(v
>  
>  int __init acpi_table_init(void)
>  {
> - acpi_initialize_tables(initial_tables, ACPI_MAX_TABLES, 0);
> + acpi_initialize_tables(NULL, ACPI_MAX_TABLES, 0);
> check_multiple_madt();
> return 0;
>  }
> --- a/xen/include/acpi/platform/aclinux.h
> +++ b/xen/include/acpi/platform/aclinux.h
> @@ -76,8 +76,12 @@
>  
>  #define acpi_thread_id struct vcpu *
>  
> -#define ACPI_ALLOCATE(a) xmalloc_bytes(a)
> -#define ACPI_ALLOCATE_ZEROED(a) xzalloc_bytes(a)
> -#define ACPI_FREE(a)  xfree(a)
> +void *acpi_os_alloc_memory(size_t);
> +void *acpi_os_zalloc_memory(size_t);
> +void acpi_os_free_memory(void *);
> +
> +#define ACPI_ALLOCATE(a) acpi_os_alloc_memory(a)
> +#define ACPI_ALLOCATE_ZEROED(a) acpi_os_zalloc_memory(a)
> +#define ACPI_FREE(a)  acpi_os_free_memory(a)
>  
>  #endif    /* __ACLINUX_H__ */
> 
> 
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 19 14:45:48 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Sep 2012 14: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 1TELWw-0008Ly-8W; Wed, 19 Sep 2012 14:45:34 +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 1TELWu-0008Le-T6
	for xen-devel@lists.xen.org; Wed, 19 Sep 2012 14:45:33 +0000
Received: from [85.158.138.51:46022] by server-10.bemta-3.messagelabs.com id
	3E/BE-10411-C8AD9505; Wed, 19 Sep 2012 14:45:32 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1348065925!23590958!2
X-Originating-IP: [209.85.215.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31665 invoked from network); 19 Sep 2012 14:45:31 -0000
Received: from mail-ey0-f173.google.com (HELO mail-ey0-f173.google.com)
	(209.85.215.173)
	by server-10.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Sep 2012 14:45:31 -0000
Received: by mail-ey0-f173.google.com with SMTP id c13so371851eaa.32
	for <xen-devel@lists.xen.org>; Wed, 19 Sep 2012 07:45:31 -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=e0V2EF885hUETF8huK93UtpHyHYf4FW0TYEiRMGlB40=;
	b=qVRwypfrHHX2wkRRI4zSFaQ8UhxaLy53NdD+MIEYU7yK69t1hZz4mkSwT3AVRI2Pfh
	2qGYGRiKQvWgg/g9A4lh5BI3nhzS/Rd+jtP+Ax97LquizbqspHI2O/sUb1meA4sGFiPJ
	f4K6QkkSrcweRIQHvwUV2b+HXfCszVlouEKJuwITu4sYuhlWv31VOqpaubenj7lTzDSe
	ecu71kWDs+C5WCv5ifCY9CFBU/lOd61CgX626m1AAzYEdj3Ni+0pp+qiJgC/93Ci2XXC
	4524aGRkfEZc/DhPcwwOwcmlLCHJYXUoSryinBXLYKcao2TgZswGWEsEkUaDpEI3cgIx
	27+g==
Received: by 10.14.203.69 with SMTP id e45mr3894444eeo.23.1348065931669;
	Wed, 19 Sep 2012 07:45:31 -0700 (PDT)
Received: from [192.168.1.3] (host86-167-82-156.range86-167.btcentralplus.com.
	[86.167.82.156])
	by mx.google.com with ESMTPS id l42sm7911314eep.1.2012.09.19.07.45.28
	(version=SSLv3 cipher=OTHER); Wed, 19 Sep 2012 07:45:31 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.33.0.120411
Date: Wed, 19 Sep 2012 15:45:27 +0100
From: Keir Fraser <keir@xen.org>
To: Jan Beulich <JBeulich@suse.com>,
	Keir Fraser <keir.xen@gmail.com>
Message-ID: <CC7F9917.4C669%keir@xen.org>
Thread-Topic: [Xen-devel] [PATCH] ACPI: move tables.c fully into .init.*
Thread-Index: Ac2WdWheTKCzd3fhYka/jdhRTCjtOw==
In-Reply-To: <5059DD5A020000780009C523@nat28.tlf.novell.com>
Mime-version: 1.0
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] ACPI: move tables.c fully into .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 19/09/2012 13:57, "Jan Beulich" <JBeulich@suse.com> wrote:

>>>> On 19.09.12 at 13:40, Keir Fraser <keir.xen@gmail.com> wrote:
>> On 19/09/2012 09:58, "Jan Beulich" <JBeulich@suse.com> wrote:
>> 
>>> Of course, if you're only against the dynamic allocation, moving
>>> the array elsewhere would be another option (but would require
>>> making the symbol global, whereas here the symbol goes away
>>> altogether from the symbol tables).
>>> 
>>> Yet another option would be to do the dynamic allocation where
>>> it was actually intended to be done, passing NULL here. The
>>> resizing there isn't being made use of anyway (and wouldn't
>>> work afaict), so we could as well do away with it and replace it
>>> by the simple allocation needed here (or simply fix it,
>>> considering that we might need it at some point).
>> 
>> I'm not wild about any of the options really. Perhaps passing NULL would be
>> best. Still, overall, I'm not *that* bothered. You can have my Ack for the
>> original patch:
>> Acked-by: Keir Fraser <keir@xen.org>
> 
> As you were not really happy with it, and as I (also already in
> the past) wondered about when the broken re-allocation there
> would hit us, I decided to produce a v2, fixing and using the
> re-allocation mechanism instead.

I like that more, yes. Thanks!

> Jan
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 19 14:45:48 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Sep 2012 14: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 1TELWw-0008Ly-8W; Wed, 19 Sep 2012 14:45:34 +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 1TELWu-0008Le-T6
	for xen-devel@lists.xen.org; Wed, 19 Sep 2012 14:45:33 +0000
Received: from [85.158.138.51:46022] by server-10.bemta-3.messagelabs.com id
	3E/BE-10411-C8AD9505; Wed, 19 Sep 2012 14:45:32 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1348065925!23590958!2
X-Originating-IP: [209.85.215.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31665 invoked from network); 19 Sep 2012 14:45:31 -0000
Received: from mail-ey0-f173.google.com (HELO mail-ey0-f173.google.com)
	(209.85.215.173)
	by server-10.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Sep 2012 14:45:31 -0000
Received: by mail-ey0-f173.google.com with SMTP id c13so371851eaa.32
	for <xen-devel@lists.xen.org>; Wed, 19 Sep 2012 07:45:31 -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=e0V2EF885hUETF8huK93UtpHyHYf4FW0TYEiRMGlB40=;
	b=qVRwypfrHHX2wkRRI4zSFaQ8UhxaLy53NdD+MIEYU7yK69t1hZz4mkSwT3AVRI2Pfh
	2qGYGRiKQvWgg/g9A4lh5BI3nhzS/Rd+jtP+Ax97LquizbqspHI2O/sUb1meA4sGFiPJ
	f4K6QkkSrcweRIQHvwUV2b+HXfCszVlouEKJuwITu4sYuhlWv31VOqpaubenj7lTzDSe
	ecu71kWDs+C5WCv5ifCY9CFBU/lOd61CgX626m1AAzYEdj3Ni+0pp+qiJgC/93Ci2XXC
	4524aGRkfEZc/DhPcwwOwcmlLCHJYXUoSryinBXLYKcao2TgZswGWEsEkUaDpEI3cgIx
	27+g==
Received: by 10.14.203.69 with SMTP id e45mr3894444eeo.23.1348065931669;
	Wed, 19 Sep 2012 07:45:31 -0700 (PDT)
Received: from [192.168.1.3] (host86-167-82-156.range86-167.btcentralplus.com.
	[86.167.82.156])
	by mx.google.com with ESMTPS id l42sm7911314eep.1.2012.09.19.07.45.28
	(version=SSLv3 cipher=OTHER); Wed, 19 Sep 2012 07:45:31 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.33.0.120411
Date: Wed, 19 Sep 2012 15:45:27 +0100
From: Keir Fraser <keir@xen.org>
To: Jan Beulich <JBeulich@suse.com>,
	Keir Fraser <keir.xen@gmail.com>
Message-ID: <CC7F9917.4C669%keir@xen.org>
Thread-Topic: [Xen-devel] [PATCH] ACPI: move tables.c fully into .init.*
Thread-Index: Ac2WdWheTKCzd3fhYka/jdhRTCjtOw==
In-Reply-To: <5059DD5A020000780009C523@nat28.tlf.novell.com>
Mime-version: 1.0
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] ACPI: move tables.c fully into .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 19/09/2012 13:57, "Jan Beulich" <JBeulich@suse.com> wrote:

>>>> On 19.09.12 at 13:40, Keir Fraser <keir.xen@gmail.com> wrote:
>> On 19/09/2012 09:58, "Jan Beulich" <JBeulich@suse.com> wrote:
>> 
>>> Of course, if you're only against the dynamic allocation, moving
>>> the array elsewhere would be another option (but would require
>>> making the symbol global, whereas here the symbol goes away
>>> altogether from the symbol tables).
>>> 
>>> Yet another option would be to do the dynamic allocation where
>>> it was actually intended to be done, passing NULL here. The
>>> resizing there isn't being made use of anyway (and wouldn't
>>> work afaict), so we could as well do away with it and replace it
>>> by the simple allocation needed here (or simply fix it,
>>> considering that we might need it at some point).
>> 
>> I'm not wild about any of the options really. Perhaps passing NULL would be
>> best. Still, overall, I'm not *that* bothered. You can have my Ack for the
>> original patch:
>> Acked-by: Keir Fraser <keir@xen.org>
> 
> As you were not really happy with it, and as I (also already in
> the past) wondered about when the broken re-allocation there
> would hit us, I decided to produce a v2, fixing and using the
> re-allocation mechanism instead.

I like that more, yes. Thanks!

> Jan
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 19 14:55:09 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Sep 2012 14:55:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TELfw-0000C9-Aq; Wed, 19 Sep 2012 14:54: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 1TELfv-0000C4-2h
	for xen-devel@lists.xen.org; Wed, 19 Sep 2012 14:54:51 +0000
Received: from [85.158.137.99:35804] by server-4.bemta-3.messagelabs.com id
	82/49-24831-ABCD9505; Wed, 19 Sep 2012 14:54:50 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-3.tower-217.messagelabs.com!1348066489!13265400!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21136 invoked from network); 19 Sep 2012 14:54:49 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-3.tower-217.messagelabs.com with SMTP;
	19 Sep 2012 14:54:49 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 19 Sep 2012 15:54:48 +0100
Message-Id: <5059F8D8020000780009C5CD@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 19 Sep 2012 15:54:48 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>
References: <1348061269-19133-1-git-send-email-konrad.wilk@oracle.com>
In-Reply-To: <1348061269-19133-1-git-send-email-konrad.wilk@oracle.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: linux-kernel@vger.kernel.org, stable@kernel.org,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] xen/boot: Disable BIOS SMP MP table search.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.09.12 at 15:27, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
> As the initial domain we are able to search/map certain regions
> of memory to harvest configuration data. For all low-level we
> use ACPI tables - for interrupts we use exclusively ACPI _PRT
> (so DSDT) and MADT for INT_SRC_OVR.
> 
> The SMP MP table is not used at all. As a matter of fact we do
> not even support machines that only have SMP MP but no ACPI tables.
> 
> Lets follow how Moorestown does it and just disable searching
> for BIOS SMP tables.
> 
> This also fixes an issue on HP Proliant BL680c G5 and DL380 G6:
> 
> 9f->100 for 1:1 PTE
> Freeing 9f-100 pfn range: 97 pages freed
> 1-1 mapping on 9f->100
> .. snip..
> e820: BIOS-provided physical RAM map:
> Xen: [mem 0x0000000000000000-0x000000000009efff] usable
> Xen: [mem 0x000000000009f400-0x00000000000fffff] reserved
> Xen: [mem 0x0000000000100000-0x00000000cfd1dfff] usable
> .. snip..
> Scan for SMP in [mem 0x00000000-0x000003ff]
> Scan for SMP in [mem 0x0009fc00-0x0009ffff]
> Scan for SMP in [mem 0x000f0000-0x000fffff]
> found SMP MP-table at [mem 0x000f4fa0-0x000f4faf] mapped at [ffff8800000f4fa0]
> (XEN) mm.c:908:d0 Error getting mfn 100 (pfn 5555555555555555) from L1 entry 
> 0000000000100461 for l1e_owner=0, pg_owner=0
> (XEN) mm.c:4995:d0 ptwr_emulate: could not get_page_from_l1e()
> BUG: unable to handle kernel NULL pointer dereference at           (null)
> IP: [<ffffffff81ac07e2>] xen_set_pte_init+0x66/0x71
> . snip..
> Pid: 0, comm: swapper Not tainted 3.6.0-rc6upstream-00188-gb6fb969-dirty #2 HP 
> ProLiant BL680c G5
> .. snip..
> Call Trace:
>  [<ffffffff81ad31c6>] __early_ioremap+0x18a/0x248
>  [<ffffffff81624731>] ? printk+0x48/0x4a
>  [<ffffffff81ad32ac>] early_ioremap+0x13/0x15
>  [<ffffffff81acc140>] get_mpc_size+0x2f/0x67
>  [<ffffffff81acc284>] smp_scan_config+0x10c/0x136
>  [<ffffffff81acc2e4>] default_find_smp_config+0x36/0x5a
>  [<ffffffff81ac3085>] setup_arch+0x5b3/0xb5b
>  [<ffffffff81624731>] ? printk+0x48/0x4a
>  [<ffffffff81abca7f>] start_kernel+0x90/0x390
>  [<ffffffff81abc356>] x86_64_start_reservations+0x131/0x136
>  [<ffffffff81abfa83>] xen_start_kernel+0x65f/0x661
> (XEN) Domain 0 crashed: 'noreboot' set - not rebooting.
> 
> which is that ioremap would end up mapping 0xff using _PAGE_IOMAP
> (which is what early_ioremap sticks as a flag) - which meant
> we would get MFN 0xFF (pte ff461, which is OK), and then it would
> also map 0x100 (b/c ioremap tries to get page aligned request, and
> it was trying to map 0xf4fa0 + PAGE_SIZE - so it mapped the next page)
> as _PAGE_IOMAP. Since 0x100 is actually a RAM page, and the _PAGE_IOMAP
> bypasses the P2M lookup we would happily set the PTE to 1000461.
> Xen would deny the request since we do not have access to the
> Machine Frame Number (MFN) of 0x100. The P2M[0x100] is for example
> 0x80140.
> 
> CC: stable@kernel.org 
> Fixes-Oracle-Bugzilla: 
> https://bugzilla.oracle.com/bugzilla/show_bug.cgi?id=13665 
> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

Acked-by: Jan Beulich <jbeulich@suse.com>

> ---
>  arch/x86/xen/enlighten.c |    4 ++++
>  1 files changed, 4 insertions(+), 0 deletions(-)
> 
> diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
> index 9642d4a..1fbe75a 100644
> --- a/arch/x86/xen/enlighten.c
> +++ b/arch/x86/xen/enlighten.c
> @@ -1452,6 +1452,10 @@ asmlinkage void __init xen_start_kernel(void)
>  		pci_request_acs();
>  
>  		xen_acpi_sleep_register();
> +
> +		/* Avoid searching for BIOS MP tables */
> +		x86_init.mpparse.find_smp_config = x86_init_noop;
> +		x86_init.mpparse.get_smp_config = x86_init_uint_noop;
>  	}
>  #ifdef CONFIG_PCI
>  	/* PCI BIOS service won't work from a PV guest. */
> -- 
> 1.7.7.6
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org 
> http://lists.xen.org/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 Sep 19 14:55:09 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Sep 2012 14:55:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TELfw-0000C9-Aq; Wed, 19 Sep 2012 14:54: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 1TELfv-0000C4-2h
	for xen-devel@lists.xen.org; Wed, 19 Sep 2012 14:54:51 +0000
Received: from [85.158.137.99:35804] by server-4.bemta-3.messagelabs.com id
	82/49-24831-ABCD9505; Wed, 19 Sep 2012 14:54:50 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-3.tower-217.messagelabs.com!1348066489!13265400!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21136 invoked from network); 19 Sep 2012 14:54:49 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-3.tower-217.messagelabs.com with SMTP;
	19 Sep 2012 14:54:49 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 19 Sep 2012 15:54:48 +0100
Message-Id: <5059F8D8020000780009C5CD@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 19 Sep 2012 15:54:48 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>
References: <1348061269-19133-1-git-send-email-konrad.wilk@oracle.com>
In-Reply-To: <1348061269-19133-1-git-send-email-konrad.wilk@oracle.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: linux-kernel@vger.kernel.org, stable@kernel.org,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] xen/boot: Disable BIOS SMP MP table search.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.09.12 at 15:27, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
> As the initial domain we are able to search/map certain regions
> of memory to harvest configuration data. For all low-level we
> use ACPI tables - for interrupts we use exclusively ACPI _PRT
> (so DSDT) and MADT for INT_SRC_OVR.
> 
> The SMP MP table is not used at all. As a matter of fact we do
> not even support machines that only have SMP MP but no ACPI tables.
> 
> Lets follow how Moorestown does it and just disable searching
> for BIOS SMP tables.
> 
> This also fixes an issue on HP Proliant BL680c G5 and DL380 G6:
> 
> 9f->100 for 1:1 PTE
> Freeing 9f-100 pfn range: 97 pages freed
> 1-1 mapping on 9f->100
> .. snip..
> e820: BIOS-provided physical RAM map:
> Xen: [mem 0x0000000000000000-0x000000000009efff] usable
> Xen: [mem 0x000000000009f400-0x00000000000fffff] reserved
> Xen: [mem 0x0000000000100000-0x00000000cfd1dfff] usable
> .. snip..
> Scan for SMP in [mem 0x00000000-0x000003ff]
> Scan for SMP in [mem 0x0009fc00-0x0009ffff]
> Scan for SMP in [mem 0x000f0000-0x000fffff]
> found SMP MP-table at [mem 0x000f4fa0-0x000f4faf] mapped at [ffff8800000f4fa0]
> (XEN) mm.c:908:d0 Error getting mfn 100 (pfn 5555555555555555) from L1 entry 
> 0000000000100461 for l1e_owner=0, pg_owner=0
> (XEN) mm.c:4995:d0 ptwr_emulate: could not get_page_from_l1e()
> BUG: unable to handle kernel NULL pointer dereference at           (null)
> IP: [<ffffffff81ac07e2>] xen_set_pte_init+0x66/0x71
> . snip..
> Pid: 0, comm: swapper Not tainted 3.6.0-rc6upstream-00188-gb6fb969-dirty #2 HP 
> ProLiant BL680c G5
> .. snip..
> Call Trace:
>  [<ffffffff81ad31c6>] __early_ioremap+0x18a/0x248
>  [<ffffffff81624731>] ? printk+0x48/0x4a
>  [<ffffffff81ad32ac>] early_ioremap+0x13/0x15
>  [<ffffffff81acc140>] get_mpc_size+0x2f/0x67
>  [<ffffffff81acc284>] smp_scan_config+0x10c/0x136
>  [<ffffffff81acc2e4>] default_find_smp_config+0x36/0x5a
>  [<ffffffff81ac3085>] setup_arch+0x5b3/0xb5b
>  [<ffffffff81624731>] ? printk+0x48/0x4a
>  [<ffffffff81abca7f>] start_kernel+0x90/0x390
>  [<ffffffff81abc356>] x86_64_start_reservations+0x131/0x136
>  [<ffffffff81abfa83>] xen_start_kernel+0x65f/0x661
> (XEN) Domain 0 crashed: 'noreboot' set - not rebooting.
> 
> which is that ioremap would end up mapping 0xff using _PAGE_IOMAP
> (which is what early_ioremap sticks as a flag) - which meant
> we would get MFN 0xFF (pte ff461, which is OK), and then it would
> also map 0x100 (b/c ioremap tries to get page aligned request, and
> it was trying to map 0xf4fa0 + PAGE_SIZE - so it mapped the next page)
> as _PAGE_IOMAP. Since 0x100 is actually a RAM page, and the _PAGE_IOMAP
> bypasses the P2M lookup we would happily set the PTE to 1000461.
> Xen would deny the request since we do not have access to the
> Machine Frame Number (MFN) of 0x100. The P2M[0x100] is for example
> 0x80140.
> 
> CC: stable@kernel.org 
> Fixes-Oracle-Bugzilla: 
> https://bugzilla.oracle.com/bugzilla/show_bug.cgi?id=13665 
> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

Acked-by: Jan Beulich <jbeulich@suse.com>

> ---
>  arch/x86/xen/enlighten.c |    4 ++++
>  1 files changed, 4 insertions(+), 0 deletions(-)
> 
> diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
> index 9642d4a..1fbe75a 100644
> --- a/arch/x86/xen/enlighten.c
> +++ b/arch/x86/xen/enlighten.c
> @@ -1452,6 +1452,10 @@ asmlinkage void __init xen_start_kernel(void)
>  		pci_request_acs();
>  
>  		xen_acpi_sleep_register();
> +
> +		/* Avoid searching for BIOS MP tables */
> +		x86_init.mpparse.find_smp_config = x86_init_noop;
> +		x86_init.mpparse.get_smp_config = x86_init_uint_noop;
>  	}
>  #ifdef CONFIG_PCI
>  	/* PCI BIOS service won't work from a PV guest. */
> -- 
> 1.7.7.6
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org 
> http://lists.xen.org/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 Sep 19 14:57:06 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Sep 2012 14:57:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TELhl-0000J7-S9; Wed, 19 Sep 2012 14:56:45 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <matthew.fioravante@jhuapl.edu>) id 1TELhj-0000Iu-Oi
	for xen-devel@lists.xensource.com; Wed, 19 Sep 2012 14:56:44 +0000
Received: from [85.158.143.35:23626] by server-2.bemta-4.messagelabs.com id
	97/CF-06610-A2DD9505; Wed, 19 Sep 2012 14:56:42 +0000
X-Env-Sender: matthew.fioravante@jhuapl.edu
X-Msg-Ref: server-2.tower-21.messagelabs.com!1348066589!7997320!1
X-Originating-IP: [128.244.251.36]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG,
	UNPARSEABLE_RELAY
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32454 invoked from network); 19 Sep 2012 14:56:31 -0000
Received: from pilot.jhuapl.edu (HELO jhuapl.edu) (128.244.251.36)
	by server-2.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 19 Sep 2012 14:56:31 -0000
Received: from ([128.244.207.89])
	by pilot.jhuapl.edu with ESMTP with TLS id 63GHCH1.153214994;
	Wed, 19 Sep 2012 10:56:10 -0400
Message-ID: <5059DCBE.7060202@jhuapl.edu>
Date: Wed, 19 Sep 2012 10:54:54 -0400
From: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120827 Thunderbird/15.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <50579F53.4070302@jhuapl.edu>
	<1348056465.14977.96.camel@zakaz.uk.xensource.com>
In-Reply-To: <1348056465.14977.96.camel@zakaz.uk.xensource.com>
X-Enigmail-Version: 1.4.4
Cc: Samuel Thibault <samuel.thibault@ens-lyon.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH mini-os enhancements for vtpm 8/8] Add 3 tpm
 drivers to mini-os
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0895186449901109436=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a cryptographically signed message in MIME format.

--===============0895186449901109436==
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms050205000800020200090704"

This is a cryptographically signed message in MIME format.

--------------ms050205000800020200090704
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 09/19/2012 08:07 AM, Ian Campbell wrote:
> On Mon, 2012-09-17 at 23:08 +0100, Matthew Fioravante wrote:
>> This patch adds 3 new drivers to mini-os.
>>
>> tpmfront - paravirtualized tpm frontend driver
>> tpmback - paravirtualized tpm backend driver
>> tpm_tis - hardware tpm driver
>>
>> Unfortunately these drivers were derived from GPL licensed linux kerne=
l
>> drivers so they must carry the GPL license.
> I notice that you have used GPL v3 here, while the original Linux
> versions of these files (I looked at 3.6-rc3)both say:
>  * 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, version 2 of the
>  * License.
> i.e. doesn't contain the "or later" wording which would allow an upgrad=
e
> to v3. Did all of the copyright holders agree to this relicensing?
Thank you, that was a really good catch. I meant to use GPL v2 but put
in the wrong text.
>>  However, since mini-os now
>> supports conditional compilation, hopefully these drivers can be
>> included into the xen tree and conditionally removed from non-gpl
>> projects. By default they are disabled in the makefile.
> Are these drivers useful for other stub domains generally or are they
> only really useful in the vtpm stub domains? IOW could this GPL code be=

> made part of the application instead?
>
> This would allow better segregation between the BSD bits of mini-os and=

> GPL bits.
tpmfront would be useful for any mini-os domain that wants a vtpm.
tpm_tis would be useful for any mini-os domain that wants access to the
physical tpm.

tpmback is only useful for the vtpm system itself. Unless someone else
wants to implement a new vtpm domain, I don't see why they would want to
use this driver.
>> Signed off by: Matthew Fioravante matthew.fioravante@jhuapl.edu
> Can you confirm that you have the right to submit his code under this
> license, since you are not listed in the copyright I guess that would b=
e
> clause B of the DCO:
> http://wiki.xen.org/wiki/Submitting_Xen_Patches#Signing_off_a_patch
I have the rights to submit these patches. The copyright clause and GPL
v2 license were approved by our internal review process and that of our
government sponsor.
>
>> diff --git a/extras/mini-os/include/tpm_tis.h
>> b/extras/mini-os/include/tpm_tis.h
>> --- /dev/null
>> +++ b/extras/mini-os/include/tpm_tis.h
>> @@ -0,0 +1,63 @@
>> +/*
>> + * Copyright (c) 2010-2012 United States Government, as represented b=
y
>> + * the Secretary of Defense.  All rights reserved.
>> + *
>> + * This driver is free software: you can redistribute it and/or modif=
y
>> + * it under the terms of the GNU General Public License as published =
by
>> + * the Free Software Foundation, either version 3 of the License, or
>> + * (at your option) any later version.
>> + *
>> + * This driver is distributed in the hope that it will be useful,
>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
>> + * GNU General Public License for more details.
>> + *
>> + * You should have received a copy of the GNU General Public License
>> + * along with this program.  If not, see <http://www.gnu.org/licenses=
/>.
>> + *
>> + * Based upon the files:
>> + *  drivers/char/tpm/tpm_tis.c
>> + *  drivers/char/tpm/tpm.c
>> + * from the Linux kernel, which are Copyright (C) 2006 IBM Corporatio=
n
>> + */
>
Heres an updated patch with v2

Signed of by Matthew Fioravante matthew.fioravante@jhuapl.edu

diff --git a/extras/mini-os/Makefile b/extras/mini-os/Makefile
--- a/extras/mini-os/Makefile
+++ b/extras/mini-os/Makefile
@@ -22,6 +22,9 @@ CONFIG_QEMU_XS_ARGS ?=3D n
 CONFIG_TEST ?=3D n
 CONFIG_PCIFRONT ?=3D n
 CONFIG_BLKFRONT ?=3D y
+CONFIG_TPMFRONT ?=3D n
+CONFIG_TPM_TIS ?=3D n
+CONFIG_TPMBACK ?=3D n
 CONFIG_NETFRONT ?=3D y
 CONFIG_FBFRONT ?=3D y
 CONFIG_KBDFRONT ?=3D y
@@ -36,6 +39,9 @@ flags-$(CONFIG_SPARSE_BSS) +=3D -DCONFIG_SPARSE_BSS
 flags-$(CONFIG_QEMU_XS_ARGS) +=3D -DCONFIG_QEMU_XS_ARGS
 flags-$(CONFIG_PCIFRONT) +=3D -DCONFIG_PCIFRONT
 flags-$(CONFIG_BLKFRONT) +=3D -DCONFIG_BLKFRONT
+flags-$(CONFIG_TPMFRONT) +=3D -DCONFIG_TPMFRONT
+flags-$(CONFIG_TPM_TIS) +=3D -DCONFIG_TPM_TIS
+flags-$(CONFIG_TPMBACK) +=3D -DCONFIG_TPMBACK
 flags-$(CONFIG_NETFRONT) +=3D -DCONFIG_NETFRONT
 flags-$(CONFIG_KBDFRONT) +=3D -DCONFIG_KBDFRONT
 flags-$(CONFIG_FBFRONT) +=3D -DCONFIG_FBFRONT
@@ -67,6 +73,9 @@ TARGET :=3D mini-os
 SUBDIRS :=3D lib xenbus console
=20
 src-$(CONFIG_BLKFRONT) +=3D blkfront.c
+src-$(CONFIG_TPMFRONT) +=3D tpmfront.c
+src-$(CONFIG_TPM_TIS) +=3D tpm_tis.c
+src-$(CONFIG_TPMBACK) +=3D tpmback.c
 src-y +=3D daytime.c
 src-y +=3D events.c
 src-$(CONFIG_FBFRONT) +=3D fbfront.c
diff --git a/extras/mini-os/include/lib.h b/extras/mini-os/include/lib.h
--- a/extras/mini-os/include/lib.h
+++ b/extras/mini-os/include/lib.h
@@ -142,6 +142,8 @@ enum fd_type {
     FTYPE_FB,
     FTYPE_MEM,
     FTYPE_SAVEFILE,
+    FTYPE_TPMFRONT,
+    FTYPE_TPM_TIS,
 };
=20
 LIST_HEAD(evtchn_port_list, evtchn_port_info);
@@ -185,6 +187,20 @@ extern struct file {
     struct {
         struct consfront_dev *dev;
     } cons;
+#ifdef CONFIG_TPMFRONT
+    struct {
+       struct tpmfront_dev *dev;
+       int respgot;
+       off_t offset;
+    } tpmfront;
+#endif
+#ifdef CONFIG_TPM_TIS
+    struct {
+       struct tpm_chip *dev;
+       int respgot;
+       off_t offset;
+    } tpm_tis;
+#endif
 #ifdef CONFIG_XENBUS
         struct {
             /* To each xenbus FD is associated a queue of watch events
for this
diff --git a/extras/mini-os/include/tpm_tis.h
b/extras/mini-os/include/tpm_tis.h
--- /dev/null
+++ b/extras/mini-os/include/tpm_tis.h
@@ -0,0 +1,74 @@
+/*
+ * Copyright (c) 2010-2012 United States Government, as represented by
+ * the Secretary of Defense.  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 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 MERCHANTABILI=
TY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT
SHALL THE
+ * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHE=
R
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISI=
NG
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
DEALINGS
+ * IN THE SOFTWARE.
+ *
+ * Based upon the files:
+ *  drivers/char/tpm/tpm_tis.c
+ *  drivers/char/tpm/tpm.c
+ * from the Linux kernel, which are Copyright (C) 2006 IBM Corporation
+ */
+#ifndef TPM_TIS_H
+#define TPM_TIS_H
+
+#include <mini-os/types.h>
+#include <mini-os/byteorder.h>
+
+#define TPM_TIS_EN_LOCL0 1
+#define TPM_TIS_EN_LOCL1 (1 << 1)
+#define TPM_TIS_EN_LOCL2 (1 << 2)
+#define TPM_TIS_EN_LOCL3 (1 << 3)
+#define TPM_TIS_EN_LOCL4 (1 << 4)
+#define TPM_TIS_EN_LOCLALL (TPM_TIS_EN_LOCL0 | TPM_TIS_EN_LOCL1  |
TPM_TIS_EN_LOCL2 | TPM_TIS_EN_LOCL3 | TPM_TIS_EN_LOCL4)
+#define TPM_TIS_LOCL_INT_TO_FLAG(x) (1 << x)
+#define TPM_BASEADDR 0xFED40000
+#define TPM_PROBE_IRQ 0xFFFF
+
+struct tpm_chip;
+
+struct tpm_chip* init_tpm_tis(unsigned long baseaddr, int localities,
unsigned int irq);
+void shutdown_tpm_tis(struct tpm_chip* tpm);
+
+int tpm_tis_request_locality(struct tpm_chip* tpm, int locality);
+int tpm_tis_cmd(struct tpm_chip* tpm, uint8_t* req, size_t reqlen,
uint8_t** resp, size_t* resplen);
+
+#ifdef HAVE_LIBC
+#include <sys/stat.h>
+#include <fcntl.h>
+/* POSIX IO functions:
+ * use tpm_tis_open() to get a file descriptor to the tpm device
+ * use write() on the fd to send a command to the backend. You must
+ * include the entire command in a single call to write().
+ * use read() on the fd to read the response. You can use
+ * fstat() to get the size of the response and lseek() to seek on it.
+ */
+int tpm_tis_open(struct tpm_chip* tpm);
+int tpm_tis_posix_read(int fd, uint8_t* buf, size_t count);
+int tpm_tis_posix_write(int fd, const uint8_t* buf, size_t count);
+int tpm_tis_posix_fstat(int fd, struct stat* buf);
+#endif
+
+#endif
diff --git a/extras/mini-os/include/tpmback.h
b/extras/mini-os/include/tpmback.h
--- /dev/null
+++ b/extras/mini-os/include/tpmback.h
@@ -0,0 +1,106 @@
+/*
+ * Copyright (c) 2010-2012 United States Government, as represented by
+ * the Secretary of Defense.  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 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 MERCHANTABILI=
TY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT
SHALL THE
+ * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHE=
R
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISI=
NG
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
DEALINGS
+ * IN THE SOFTWARE.
+ *
+ * Based upon the files:
+ *  drivers/xen/tpmbk.c
+ * from the Linux kernel, which are Copyright (C) 2006 IBM Corporation
+ */
+#include <xen/io/tpmif.h>
+#include <xen/io/xenbus.h>
+#include <mini-os/types.h>
+#include <xen/xen.h>
+#ifndef TPMBACK_H
+#define TPMBACK_H
+
+struct tpmcmd {
+   domid_t domid;        /* Domid of the frontend */
+   unsigned int handle;    /* Handle of the frontend */
+   char* uuid;            /* uuid of the tpm interface - allocated
internally, dont free it */
+
+   unsigned int req_len;        /* Size of the command in buf - set by
tpmback driver */
+   uint8_t* req;            /* tpm command bits, allocated by driver,
DON'T FREE IT */
+   unsigned int resp_len;    /* Size of the outgoing command,
+                   you set this before passing the cmd object to
tpmback_resp */
+   uint8_t* resp;        /* Buffer for response - YOU MUST ALLOCATE IT,
YOU MUST ALSO FREE IT */
+};
+typedef struct tpmcmd tpmcmd_t;
+
+/* Initialize the tpm backend driver
+ * @exclusive_domname - This is NULL terminated list of vtpm uuid
strings. If this list
+ *             is non-empty, then only frontend domains with vtpm
uuid's matching
+ *             entries in this list will be allowed to connect.
+ *             Other connections will be immediatly closed.
+ *             Set this argument to NULL to allow any vtpm to connect.
+ */
+void init_tpmback(char** exclusive_uuids);
+/* Shutdown tpm backend driver */
+void shutdown_tpmback(void);
+
+/* Blocks until a tpm command is sent from any front end.
+ * Returns a pointer to the tpm command to handle.
+ * Do not try to free this pointer or the req buffer
+ * This function will return NULL if the tpm backend driver
+ * is shutdown or any other error occurs */
+tpmcmd_t* tpmback_req_any(void);
+
+/* Blocks until a tpm command from the frontend at domid/handle
+ * is sent.
+ * Returns NULL if domid/handle is not connected, tpmback is
+ * shutdown or shutting down, or if there is an error
+ */
+tpmcmd_t* tpmback_req(domid_t domid, unsigned int handle);
+
+/* Send the response to the tpm command back to the frontend
+ * This function will free the tpmcmd object, but you must free the resp=

+ * buffer yourself */
+void tpmback_resp(tpmcmd_t* tpmcmd);
+
+/* Waits for the first frontend to connect and then sets domid and
handle appropriately.
+ * If one or more frontends are already connected, this will set domid
and handle to one
+ * of them arbitrarily. The main use for this function is to wait until
a single
+ * frontend connection has occured.
+ * returns 0 on success, non-zero on failure */
+int tpmback_wait_for_frontend_connect(domid_t *domid, unsigned int
*handle);
+
+/* returns the number of frontends connected */
+int tpmback_num_frontends(void);
+
+/* Returns the uuid of the specified frontend, NULL on error */
+char* tpmback_get_uuid(domid_t domid, unsigned int handle);
+
+/* Specify a function to call when a new tpm device connects */
+void tpmback_set_open_callback(void (*cb)(domid_t, unsigned int));
+
+/* Specify a function to call when a tpm device disconnects */
+void tpmback_set_close_callback(void (*cb)(domid_t, unsigned int));
+
+//Not Implemented
+void tpmback_set_suspend_callback(void (*cb)(domid_t, unsigned int));
+void tpmback_set_resume_callback(void (*cb)(domid_t, unsigned int));
+
+#endif
diff --git a/extras/mini-os/include/tpmfront.h
b/extras/mini-os/include/tpmfront.h
--- /dev/null
+++ b/extras/mini-os/include/tpmfront.h
@@ -0,0 +1,105 @@
+/*
+ * Copyright (c) 2010-2012 United States Government, as represented by
+ * the Secretary of Defense.  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 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 MERCHANTABILI=
TY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT
SHALL THE
+ * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHE=
R
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISI=
NG
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
DEALINGS
+ * IN THE SOFTWARE.
+ *
+ * Based upon the files:
+ *  drivers/char/tpm/tpm_vtpm.c
+ *  drivers/char/tpm/tpm_xen.c
+ * from the Linux kernel, which are Copyright (C) 2006 IBM Corporation
+ */
+#ifndef TPMFRONT_H
+#define TPMFRONT_H
+
+#include <mini-os/types.h>
+#include <mini-os/os.h>
+#include <mini-os/events.h>
+#include <mini-os/wait.h>
+#include <xen/xen.h>
+#include <xen/io/xenbus.h>
+#include <xen/io/tpmif.h>
+
+struct tpmfront_dev {
+   grant_ref_t ring_ref;
+   evtchn_port_t evtchn;
+
+   tpmif_tx_interface_t* tx;
+
+   void** pages;
+
+   domid_t bedomid;
+   char* nodename;
+   char* bepath;
+
+   XenbusState state;
+
+   uint8_t waiting;
+   struct wait_queue_head waitq;
+
+   uint8_t* respbuf;
+   size_t resplen;
+
+#ifdef HAVE_LIBC
+   int fd;
+#endif
+
+};
+
+
+/*Initialize frontend */
+struct tpmfront_dev* init_tpmfront(const char* nodename);
+/*Shutdown frontend */
+void shutdown_tpmfront(struct tpmfront_dev* dev);
+
+/* Send a tpm command to the backend and wait for the response
+ *
+ * @dev - frontend device
+ * @req - request buffer
+ * @reqlen - length of request buffer
+ * @resp - *resp will be set to internal response buffer, don't free
it! Value is undefined on error
+ * @resplen - *resplen will be set to the length of the response. Value
is undefined on error
+ *
+ * returns 0 on success, non zero on failure.
+ * */
+int tpmfront_cmd(struct tpmfront_dev* dev, uint8_t* req, size_t reqlen,
uint8_t** resp, size_t* resplen);
+
+#ifdef HAVE_LIBC
+#include <sys/stat.h>
+/* POSIX IO functions:
+ * use tpmfront_open() to get a file descriptor to the tpm device
+ * use write() on the fd to send a command to the backend. You must
+ * include the entire command in a single call to write().
+ * use read() on the fd to read the response. You can use
+ * fstat() to get the size of the response and lseek() to seek on it.
+ */
+int tpmfront_open(struct tpmfront_dev* dev);
+int tpmfront_posix_read(int fd, uint8_t* buf, size_t count);
+int tpmfront_posix_write(int fd, const uint8_t* buf, size_t count);
+int tpmfront_posix_fstat(int fd, struct stat* buf);
+#endif
+
+
+#endif
diff --git a/extras/mini-os/lib/sys.c b/extras/mini-os/lib/sys.c
--- a/extras/mini-os/lib/sys.c
+++ b/extras/mini-os/lib/sys.c
@@ -27,6 +27,8 @@
 #include <netfront.h>
 #include <blkfront.h>
 #include <fbfront.h>
+#include <tpmfront.h>
+#include <tpm_tis.h>
 #include <xenbus.h>
 #include <xenstore.h>
=20
@@ -294,6 +296,16 @@ int read(int fd, void *buf, size_t nbytes)
         return blkfront_posix_read(fd, buf, nbytes);
         }
 #endif
+#ifdef CONFIG_TPMFRONT
+        case FTYPE_TPMFRONT: {
+        return tpmfront_posix_read(fd, buf, nbytes);
+        }
+#endif
+#ifdef CONFIG_TPM_TIS
+        case FTYPE_TPM_TIS: {
+        return tpm_tis_posix_read(fd, buf, nbytes);
+        }
+#endif
     default:
         break;
     }
@@ -330,6 +342,14 @@ int write(int fd, const void *buf, size_t nbytes)
     case FTYPE_BLK:
         return blkfront_posix_write(fd, buf, nbytes);
 #endif
+#ifdef CONFIG_TPMFRONT
+    case FTYPE_TPMFRONT:
+        return tpmfront_posix_write(fd, buf, nbytes);
+#endif
+#ifdef CONFIG_TPM_TIS
+    case FTYPE_TPM_TIS:
+        return tpm_tis_posix_write(fd, buf, nbytes);
+#endif
     default:
         break;
     }
@@ -341,8 +361,16 @@ int write(int fd, const void *buf, size_t nbytes)
 off_t lseek(int fd, off_t offset, int whence)
 {
     switch(files[fd].type) {
+#if defined(CONFIG_BLKFRONT) || defined(CONFIG_TPMFRONT) ||
defined(CONFIG_TPM_TIS)
 #ifdef CONFIG_BLKFRONT
        case FTYPE_BLK:
+#endif
+#ifdef CONFIG_TPMFRNT
+       case FTYPE_TPMFRONT:
+#endif
+#ifdef CONFIG_TPM_TIS
+       case FTYPE_TPM_TIS:
+#endif
       switch (whence) {
          case SEEK_SET:
         files[fd].file.offset =3D offset;
@@ -420,6 +448,18 @@ int close(int fd)
         files[fd].type =3D FTYPE_NONE;
         return 0;
 #endif
+#ifdef CONFIG_TPMFRONT
+    case FTYPE_TPMFRONT:
+            shutdown_tpmfront(files[fd].tpmfront.dev);
+        files[fd].type =3D FTYPE_NONE;
+        return 0;
+#endif
+#ifdef CONFIG_TPM_TIS
+    case FTYPE_TPM_TIS:
+            shutdown_tpm_tis(files[fd].tpm_tis.dev);
+        files[fd].type =3D FTYPE_NONE;
+        return 0;
+#endif
 #ifdef CONFIG_KBDFRONT
     case FTYPE_KBD:
             shutdown_kbdfront(files[fd].kbd.dev);
@@ -489,6 +529,14 @@ int fstat(int fd, struct stat *buf)
     case FTYPE_BLK:
        return blkfront_posix_fstat(fd, buf);
 #endif
+#ifdef CONFIG_TPMFRONT
+    case FTYPE_TPMFRONT:
+       return tpmfront_posix_fstat(fd, buf);
+#endif
+#ifdef CONFIG_TPM_TIS
+    case FTYPE_TPM_TIS:
+       return tpm_tis_posix_fstat(fd, buf);
+#endif
     default:
         break;
     }
diff --git a/extras/mini-os/tpm_tis.c b/extras/mini-os/tpm_tis.c
--- /dev/null
+++ b/extras/mini-os/tpm_tis.c
@@ -0,0 +1,1355 @@
+/*
+ * Copyright (c) 2010-2012 United States Government, as represented by
+ * the Secretary of Defense.  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 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 MERCHANTABILI=
TY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT
SHALL THE
+ * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHE=
R
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISI=
NG
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
DEALINGS
+ * IN THE SOFTWARE.
+ *
+ * Based upon the files:
+ *  drivers/char/tpm/tpm_tis.c
+ *  drivers/char/tpm/tpm.c
+ * from the Linux kernel, which are Copyright (C) 2006 IBM Corporation
+ */
+#include <mini-os/ioremap.h>
+#include <mini-os/iorw.h>
+#include <mini-os/tpm_tis.h>
+#include <mini-os/os.h>
+#include <mini-os/sched.h>
+#include <mini-os/byteorder.h>
+#include <mini-os/events.h>
+#include <mini-os/wait.h>
+#include <mini-os/xmalloc.h>
+#include <errno.h>
+#include <stdbool.h>
+
+#ifndef min
+    #define min( a, b ) ( ((a) < (b)) ? (a) : (b) )
+#endif
+
+#define TPM_HEADER_SIZE 10
+
+#define TPM_BUFSIZE 2048
+
+struct tpm_input_header {
+        uint16_t  tag;
+        uint32_t  length;
+        uint32_t  ordinal;
+}__attribute__((packed));
+
+struct tpm_output_header {
+        uint16_t  tag;
+        uint32_t  length;
+        uint32_t  return_code;
+}__attribute__((packed));
+
+struct  stclear_flags_t {
+        uint16_t  tag;
+        uint8_t      deactivated;
+        uint8_t      disableForceClear;
+        uint8_t      physicalPresence;
+        uint8_t      physicalPresenceLock;
+        uint8_t      bGlobalLock;
+}__attribute__((packed));
+
+struct  tpm_version_t {
+        uint8_t      Major;
+        uint8_t      Minor;
+        uint8_t      revMajor;
+        uint8_t      revMinor;
+}__attribute__((packed));
+
+struct  tpm_version_1_2_t {
+        uint16_t  tag;
+        uint8_t      Major;
+        uint8_t      Minor;
+        uint8_t      revMajor;
+        uint8_t      revMinor;
+}__attribute__((packed));
+
+struct  timeout_t {
+        uint32_t  a;
+        uint32_t  b;
+        uint32_t  c;
+        uint32_t  d;
+}__attribute__((packed));
+
+struct duration_t {
+        uint32_t  tpm_short;
+        uint32_t  tpm_medium;
+        uint32_t  tpm_long;
+}__attribute__((packed));
+
+struct permanent_flags_t {
+        uint16_t  tag;
+        uint8_t      disable;
+        uint8_t      ownership;
+        uint8_t      deactivated;
+        uint8_t      readPubek;
+        uint8_t      disableOwnerClear;
+        uint8_t      allowMaintenance;
+        uint8_t      physicalPresenceLifetimeLock;
+        uint8_t      physicalPresenceHWEnable;
+        uint8_t      physicalPresenceCMDEnable;
+        uint8_t      CEKPUsed;
+        uint8_t      TPMpost;
+        uint8_t      TPMpostLock;
+        uint8_t      FIPS;
+        uint8_t      operator;
+        uint8_t      enableRevokeEK;
+        uint8_t      nvLocked;
+        uint8_t      readSRKPub;
+        uint8_t      tpmEstablished;
+        uint8_t      maintenanceDone;
+        uint8_t      disableFullDALogicInfo;
+}__attribute__((packed));
+
+typedef union {
+        struct  permanent_flags_t perm_flags;
+        struct  stclear_flags_t stclear_flags;
+        bool    owned;
+        uint32_t  num_pcrs;
+        struct  tpm_version_t   tpm_version;
+        struct  tpm_version_1_2_t tpm_version_1_2;
+        uint32_t  manufacturer_id;
+        struct timeout_t  timeout;
+        struct duration_t duration;
+} cap_t;
+
+struct  tpm_getcap_params_in {
+        uint32_t  cap;
+        uint32_t  subcap_size;
+        uint32_t  subcap;
+}__attribute__((packed));
+
+struct  tpm_getcap_params_out {
+        uint32_t  cap_size;
+        cap_t   cap;
+}__attribute__((packed));
+
+struct  tpm_readpubek_params_out {
+        uint8_t      algorithm[4];
+        uint8_t      encscheme[2];
+        uint8_t      sigscheme[2];
+        uint32_t  paramsize;
+        uint8_t      parameters[12]; /*assuming RSA*/
+        uint32_t  keysize;
+        uint8_t      modulus[256];
+        uint8_t      checksum[20];
+}__attribute__((packed));
+
+typedef union {
+        struct  tpm_input_header in;
+        struct  tpm_output_header out;
+} tpm_cmd_header;
+
+#define TPM_DIGEST_SIZE 20
+struct tpm_pcrread_out {
+        uint8_t      pcr_result[TPM_DIGEST_SIZE];
+}__attribute__((packed));
+
+struct tpm_pcrread_in {
+        uint32_t  pcr_idx;
+}__attribute__((packed));
+
+struct tpm_pcrextend_in {
+        uint32_t  pcr_idx;
+        uint8_t      hash[TPM_DIGEST_SIZE];
+}__attribute__((packed));
+
+typedef union {
+        struct  tpm_getcap_params_out getcap_out;
+        struct  tpm_readpubek_params_out readpubek_out;
+        uint8_t      readpubek_out_buffer[sizeof(struct
tpm_readpubek_params_out)];
+        struct  tpm_getcap_params_in getcap_in;
+        struct  tpm_pcrread_in  pcrread_in;
+        struct  tpm_pcrread_out pcrread_out;
+        struct  tpm_pcrextend_in pcrextend_in;
+} tpm_cmd_params;
+
+struct tpm_cmd_t {
+        tpm_cmd_header  header;
+        tpm_cmd_params  params;
+}__attribute__((packed));
+
+
+enum tpm_duration {
+   TPM_SHORT =3D 0,
+   TPM_MEDIUM =3D 1,
+   TPM_LONG =3D 2,
+   TPM_UNDEFINED,
+};
+
+#define TPM_MAX_ORDINAL 243
+#define TPM_MAX_PROTECTED_ORDINAL 12
+#define TPM_PROTECTED_ORDINAL_MASK 0xFF
+
+extern const uint8_t
tpm_protected_ordinal_duration[TPM_MAX_PROTECTED_ORDINAL];
+extern const uint8_t tpm_ordinal_duration[TPM_MAX_ORDINAL];
+
+#define TPM_DIGEST_SIZE 20
+#define TPM_ERROR_SIZE 10
+#define TPM_RET_CODE_IDX 6
+
+/* tpm_capabilities */
+#define TPM_CAP_FLAG cpu_to_be32(4)
+#define TPM_CAP_PROP cpu_to_be32(5)
+#define CAP_VERSION_1_1 cpu_to_be32(0x06)
+#define CAP_VERSION_1_2 cpu_to_be32(0x1A)
+
+/* tpm_sub_capabilities */
+#define TPM_CAP_PROP_PCR cpu_to_be32(0x101)
+#define TPM_CAP_PROP_MANUFACTURER cpu_to_be32(0x103)
+#define TPM_CAP_FLAG_PERM cpu_to_be32(0x108)
+#define TPM_CAP_FLAG_VOL cpu_to_be32(0x109)
+#define TPM_CAP_PROP_OWNER cpu_to_be32(0x111)
+#define TPM_CAP_PROP_TIS_TIMEOUT cpu_to_be32(0x115)
+#define TPM_CAP_PROP_TIS_DURATION cpu_to_be32(0x120)
+
+
+#define TPM_INTERNAL_RESULT_SIZE 200
+#define TPM_TAG_RQU_COMMAND cpu_to_be16(193)
+#define TPM_ORD_GET_CAP cpu_to_be32(101)
+
+extern const struct tpm_input_header tpm_getcap_header;
+
+
+
+const uint8_t tpm_protected_ordinal_duration[TPM_MAX_PROTECTED_ORDINAL] =
=3D {
+   TPM_UNDEFINED,          /* 0 */
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,          /* 5 */
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_SHORT,              /* 10 */
+   TPM_SHORT,
+};
+
+const uint8_t tpm_ordinal_duration[TPM_MAX_ORDINAL] =3D {
+   TPM_UNDEFINED,          /* 0 */
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,          /* 5 */
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_SHORT,              /* 10 */
+   TPM_SHORT,
+   TPM_MEDIUM,
+   TPM_LONG,
+   TPM_LONG,
+   TPM_MEDIUM,             /* 15 */
+   TPM_SHORT,
+   TPM_SHORT,
+   TPM_MEDIUM,
+   TPM_LONG,
+   TPM_SHORT,              /* 20 */
+   TPM_SHORT,
+   TPM_MEDIUM,
+   TPM_MEDIUM,
+   TPM_MEDIUM,
+   TPM_SHORT,              /* 25 */
+   TPM_SHORT,
+   TPM_MEDIUM,
+   TPM_SHORT,
+   TPM_SHORT,
+   TPM_MEDIUM,             /* 30 */
+   TPM_LONG,
+   TPM_MEDIUM,
+   TPM_SHORT,
+   TPM_SHORT,
+   TPM_SHORT,              /* 35 */
+   TPM_MEDIUM,
+   TPM_MEDIUM,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_MEDIUM,             /* 40 */
+   TPM_LONG,
+   TPM_MEDIUM,
+   TPM_SHORT,
+   TPM_SHORT,
+   TPM_SHORT,              /* 45 */
+   TPM_SHORT,
+   TPM_SHORT,
+   TPM_SHORT,
+   TPM_LONG,
+   TPM_MEDIUM,             /* 50 */
+   TPM_MEDIUM,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,          /* 55 */
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_MEDIUM,             /* 60 */
+   TPM_MEDIUM,
+   TPM_MEDIUM,
+   TPM_SHORT,
+   TPM_SHORT,
+   TPM_MEDIUM,             /* 65 */
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_SHORT,              /* 70 */
+   TPM_SHORT,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,          /* 75 */
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_LONG,               /* 80 */
+   TPM_UNDEFINED,
+   TPM_MEDIUM,
+   TPM_LONG,
+   TPM_SHORT,
+   TPM_UNDEFINED,          /* 85 */
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_SHORT,              /* 90 */
+   TPM_SHORT,
+   TPM_SHORT,
+   TPM_SHORT,
+   TPM_SHORT,
+   TPM_UNDEFINED,          /* 95 */
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_MEDIUM,             /* 100 */
+   TPM_SHORT,
+   TPM_SHORT,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,          /* 105 */
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_SHORT,              /* 110 */
+   TPM_SHORT,
+   TPM_SHORT,
+   TPM_SHORT,
+   TPM_SHORT,
+   TPM_SHORT,              /* 115 */
+   TPM_SHORT,
+   TPM_SHORT,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_LONG,               /* 120 */
+   TPM_LONG,
+   TPM_MEDIUM,
+   TPM_UNDEFINED,
+   TPM_SHORT,
+   TPM_SHORT,              /* 125 */
+   TPM_SHORT,
+   TPM_LONG,
+   TPM_SHORT,
+   TPM_SHORT,
+   TPM_SHORT,              /* 130 */
+   TPM_MEDIUM,
+   TPM_UNDEFINED,
+   TPM_SHORT,
+   TPM_MEDIUM,
+   TPM_UNDEFINED,          /* 135 */
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_SHORT,              /* 140 */
+   TPM_SHORT,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,          /* 145 */
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_SHORT,              /* 150 */
+   TPM_MEDIUM,
+   TPM_MEDIUM,
+   TPM_SHORT,
+   TPM_SHORT,
+   TPM_UNDEFINED,          /* 155 */
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_SHORT,              /* 160 */
+   TPM_SHORT,
+   TPM_SHORT,
+   TPM_SHORT,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,          /* 165 */
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_LONG,               /* 170 */
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,          /* 175 */
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_MEDIUM,             /* 180 */
+   TPM_SHORT,
+   TPM_MEDIUM,
+   TPM_MEDIUM,
+   TPM_MEDIUM,
+   TPM_MEDIUM,             /* 185 */
+   TPM_SHORT,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,          /* 190 */
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,          /* 195 */
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_SHORT,              /* 200 */
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_SHORT,
+   TPM_SHORT,              /* 205 */
+   TPM_SHORT,
+   TPM_SHORT,
+   TPM_SHORT,
+   TPM_SHORT,
+   TPM_MEDIUM,             /* 210 */
+   TPM_UNDEFINED,
+   TPM_MEDIUM,
+   TPM_MEDIUM,
+   TPM_MEDIUM,
+   TPM_UNDEFINED,          /* 215 */
+   TPM_MEDIUM,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_SHORT,
+   TPM_SHORT,              /* 220 */
+   TPM_SHORT,
+   TPM_SHORT,
+   TPM_SHORT,
+   TPM_SHORT,
+   TPM_UNDEFINED,          /* 225 */
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_SHORT,              /* 230 */
+   TPM_LONG,
+   TPM_MEDIUM,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,          /* 235 */
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_SHORT,              /* 240 */
+   TPM_UNDEFINED,
+   TPM_MEDIUM,
+};
+
+const struct tpm_input_header tpm_getcap_header =3D {
+        .tag =3D TPM_TAG_RQU_COMMAND,
+        .length =3D cpu_to_be32(22),
+        .ordinal =3D TPM_ORD_GET_CAP
+};
+
+
+enum tis_access {
+   TPM_ACCESS_VALID =3D 0x80,
+   TPM_ACCESS_ACTIVE_LOCALITY =3D 0x20,    /* (R) */
+   TPM_ACCESS_RELINQUISH_LOCALITY =3D 0x20,/* (W) */
+   TPM_ACCESS_REQUEST_PENDING =3D 0x04,    /* (W) */
+   TPM_ACCESS_REQUEST_USE =3D 0x02,    /* (W) */
+};
+
+enum tis_status {
+   TPM_STS_VALID =3D 0x80,        /* (R) */
+   TPM_STS_COMMAND_READY =3D 0x40,    /* (R) */
+   TPM_STS_DATA_AVAIL =3D 0x10,        /* (R) */
+   TPM_STS_DATA_EXPECT =3D 0x08,        /* (R) */
+   TPM_STS_GO =3D 0x20,            /* (W) */
+};
+
+enum tis_int_flags {
+   TPM_GLOBAL_INT_ENABLE =3D 0x80000000,
+   TPM_INTF_BURST_COUNT_STATIC =3D 0x100,
+   TPM_INTF_CMD_READY_INT =3D 0x080,
+   TPM_INTF_INT_EDGE_FALLING =3D 0x040,
+   TPM_INTF_INT_EDGE_RISING =3D 0x020,
+   TPM_INTF_INT_LEVEL_LOW =3D 0x010,
+   TPM_INTF_INT_LEVEL_HIGH =3D 0x008,
+   TPM_INTF_LOCALITY_CHANGE_INT =3D 0x004,
+   TPM_INTF_STS_VALID_INT =3D 0x002,
+   TPM_INTF_DATA_AVAIL_INT =3D 0x001,
+};
+
+enum tis_defaults {
+   TIS_MEM_BASE =3D 0xFED40000,
+   TIS_MEM_LEN  =3D 0x5000,
+   TIS_SHORT_TIMEOUT =3D 750, /*ms*/
+   TIS_LONG_TIMEOUT =3D 2000, /*2 sec */
+};
+
+#define TPM_TIMEOUT 5
+
+#define TPM_ACCESS(t, l)                   (((uint8_t*)t->pages[l]) +
0x0000)
+#define TPM_INT_ENABLE(t, l)             =20
((uint32_t*)(((uint8_t*)t->pages[l]) + 0x0008))
+#define TPM_INT_VECTOR(t, l)               (((uint8_t*)t->pages[l]) +
0x000C)
+#define TPM_INT_STATUS(t, l)               (((uint8_t*)t->pages[l]) +
0x0010)
+#define TPM_INTF_CAPS(t, l)              =20
((uint32_t*)(((uint8_t*)t->pages[l]) + 0x0014))
+#define TPM_STS(t, l)                    =20
((uint8_t*)(((uint8_t*)t->pages[l]) + 0x0018))
+#define TPM_DATA_FIFO(t, l)                (((uint8_t*)t->pages[l]) +
0x0024)
+
+#define TPM_DID_VID(t, l)                =20
((uint32_t*)(((uint8_t*)t->pages[l]) + 0x0F00))
+#define TPM_RID(t, l)                      (((uint8_t*)t->pages[l]) +
0x0F04)
+
+struct tpm_chip {
+   int enabled_localities;
+   int locality;
+   unsigned long baseaddr;
+   uint8_t* pages[5];
+   int did, vid, rid;
+
+   uint8_t data_buffer[TPM_BUFSIZE];
+   int data_len;
+
+   s_time_t timeout_a, timeout_b, timeout_c, timeout_d;
+   s_time_t duration[3];
+
+#ifdef HAVE_LIBC
+   int fd;
+#endif
+
+   unsigned int irq;
+   struct wait_queue_head read_queue;
+   struct wait_queue_head int_queue;
+};
+
+
+static void __init_tpm_chip(struct tpm_chip* tpm) {
+   tpm->enabled_localities =3D TPM_TIS_EN_LOCLALL;
+   tpm->locality =3D -1;
+   tpm->baseaddr =3D 0;
+   tpm->pages[0] =3D tpm->pages[1] =3D tpm->pages[2] =3D tpm->pages[3] =3D=

tpm->pages[4] =3D NULL;
+   tpm->vid =3D 0;
+   tpm->did =3D 0;
+   tpm->irq =3D 0;
+   init_waitqueue_head(&tpm->read_queue);
+   init_waitqueue_head(&tpm->int_queue);
+
+   tpm->data_len =3D -1;
+
+#ifdef HAVE_LIBC
+   tpm->fd =3D -1;
+#endif
+}
+
+/*
+ * Returns max number of nsecs to wait
+ */
+s_time_t tpm_calc_ordinal_duration(struct tpm_chip *chip,
+      uint32_t ordinal)
+{
+   int duration_idx =3D TPM_UNDEFINED;
+   s_time_t duration =3D 0;
+
+   if (ordinal < TPM_MAX_ORDINAL)
+      duration_idx =3D tpm_ordinal_duration[ordinal];
+   else if ((ordinal & TPM_PROTECTED_ORDINAL_MASK) <
+     TPM_MAX_PROTECTED_ORDINAL)
+      duration_idx =3D
+     tpm_protected_ordinal_duration[ordinal &
+     TPM_PROTECTED_ORDINAL_MASK];
+
+   if (duration_idx !=3D TPM_UNDEFINED) {
+      duration =3D chip->duration[duration_idx];
+   }
+
+   if (duration <=3D 0) {
+      return SECONDS(120);
+   }
+   else
+   {
+      return duration;
+   }
+}
+
+
+static int locality_enabled(struct tpm_chip* tpm, int l) {
+   return tpm->enabled_localities & (1 << l);
+}
+
+static int check_locality(struct tpm_chip* tpm, int l) {
+   if(locality_enabled(tpm, l) && (ioread8(TPM_ACCESS(tpm, l)) &
+        (TPM_ACCESS_ACTIVE_LOCALITY | TPM_ACCESS_VALID)) =3D=3D
+     (TPM_ACCESS_ACTIVE_LOCALITY | TPM_ACCESS_VALID)) {
+      return l;
+   }
+   return -1;
+}
+
+void release_locality(struct tpm_chip* tpm, int l, int force)
+{
+   if (locality_enabled(tpm, l) && (force || (ioread8(TPM_ACCESS(tpm, l)=
) &
+           (TPM_ACCESS_REQUEST_PENDING | TPM_ACCESS_VALID)) =3D=3D
+        (TPM_ACCESS_REQUEST_PENDING | TPM_ACCESS_VALID))) {
+      iowrite8(TPM_ACCESS(tpm, l), TPM_ACCESS_RELINQUISH_LOCALITY);
+   }
+}
+
+int tpm_tis_request_locality(struct tpm_chip* tpm, int l) {
+
+   s_time_t stop;
+   /*Make sure locality is valid */
+   if(!locality_enabled(tpm, l)) {
+      printk("tpm_tis_change_locality() Tried to change to locality %d,
but it is disabled or invalid!\n", l);
+      return -1;
+   }
+   /* Check if we already have the current locality */
+   if(check_locality(tpm, l) >=3D 0) {
+      return tpm->locality =3D l;
+   }
+   /* Set the new locality*/
+   iowrite8(TPM_ACCESS(tpm, l), TPM_ACCESS_REQUEST_USE);
+
+   if(tpm->irq) {
+      /* Wait for interrupt */
+      wait_event_deadline(tpm->int_queue, (check_locality(tpm, l) >=3D
0), NOW() + tpm->timeout_a);
+
+      /* FIXME: Handle timeout event, should return error in that case *=
/
+      return l;
+   } else {
+      /* Wait for burstcount */
+      stop =3D NOW() + tpm->timeout_a;
+      do {
+     if(check_locality(tpm, l) >=3D 0) {
+        return tpm->locality =3D l;
+     }
+     msleep(TPM_TIMEOUT);
+      } while(NOW() < stop);
+   }
+
+   printk("REQ LOCALITY FAILURE\n");
+   return -1;
+}
+
+static uint8_t tpm_tis_status(struct tpm_chip* tpm) {
+   return ioread8(TPM_STS(tpm, tpm->locality));
+}
+
+/* This causes the current command to be aborted */
+static void tpm_tis_ready(struct tpm_chip* tpm) {
+   iowrite8(TPM_STS(tpm, tpm->locality), TPM_STS_COMMAND_READY);
+}
+#define tpm_tis_cancel_cmd(v) tpm_tis_ready(v)
+
+static int get_burstcount(struct tpm_chip* tpm) {
+   s_time_t stop;
+   int burstcnt;
+
+   stop =3D NOW() + tpm->timeout_d;
+   do {
+      burstcnt =3D ioread8((TPM_STS(tpm, tpm->locality) + 1));
+      burstcnt +=3D ioread8(TPM_STS(tpm, tpm->locality) + 2) << 8;
+
+      if (burstcnt) {
+     return burstcnt;
+      }
+      msleep(TPM_TIMEOUT);
+   } while(NOW() < stop);
+   return -EBUSY;
+}
+
+static int wait_for_stat(struct tpm_chip* tpm, uint8_t mask,
+      unsigned long timeout, struct wait_queue_head* queue) {
+   s_time_t stop;
+   uint8_t status;
+
+   status =3D tpm_tis_status(tpm);
+   if((status & mask) =3D=3D mask) {
+      return 0;
+   }
+
+   if(tpm->irq) {
+      wait_event_deadline(*queue, ((tpm_tis_status(tpm) & mask) =3D=3D
mask), timeout);
+      /* FIXME: Check for timeout and return -ETIME */
+      return 0;
+   } else {
+      stop =3D NOW() + timeout;
+      do {
+     msleep(TPM_TIMEOUT);
+     status =3D tpm_tis_status(tpm);
+     if((status & mask) =3D=3D mask)
+        return 0;
+      } while( NOW() < stop);
+   }
+   return -ETIME;
+}
+
+static int recv_data(struct tpm_chip* tpm, uint8_t* buf, size_t count) {=

+   int size =3D 0;
+   int burstcnt;
+   while( size < count &&
+     wait_for_stat(tpm,
+        TPM_STS_DATA_AVAIL | TPM_STS_VALID,
+        tpm->timeout_c,
+        &tpm->read_queue)
+     =3D=3D 0) {
+      burstcnt =3D get_burstcount(tpm);
+      for(; burstcnt > 0 && size < count; --burstcnt)
+      {
+     buf[size++] =3D ioread8(TPM_DATA_FIFO(tpm, tpm->locality));
+      }
+   }
+   return size;
+}
+
+int tpm_tis_recv(struct tpm_chip* tpm, uint8_t* buf, size_t count) {
+   int size =3D 0;
+   int expected, status;
+
+   if (count < TPM_HEADER_SIZE) {
+      size =3D -EIO;
+      goto out;
+   }
+
+   /* read first 10 bytes, including tag, paramsize, and result */
+   if((size =3D
+        recv_data(tpm, buf, TPM_HEADER_SIZE)) < TPM_HEADER_SIZE) {
+      printk("Error reading tpm cmd header\n");
+      goto out;
+   }
+
+   expected =3D be32_to_cpu(*((uint32_t*)(buf + 2)));
+   if(expected > count) {
+      size =3D -EIO;
+      goto out;
+   }
+
+   if((size +=3D recv_data(tpm, & buf[TPM_HEADER_SIZE],
+           expected - TPM_HEADER_SIZE)) < expected) {
+      printk("Unable to read rest of tpm command size=3D%d
expected=3D%d\n", size, expected);
+      size =3D -ETIME;
+      goto out;
+   }
+
+   wait_for_stat(tpm, TPM_STS_VALID, tpm->timeout_c, &tpm->int_queue);
+   status =3D tpm_tis_status(tpm);
+   if(status & TPM_STS_DATA_AVAIL) {
+      printk("Error: left over data\n");
+      size =3D -EIO;
+      goto out;
+   }
+
+out:
+   tpm_tis_ready(tpm);
+   release_locality(tpm, tpm->locality, 0);
+   return size;
+}
+int tpm_tis_send(struct tpm_chip* tpm, uint8_t* buf, size_t len) {
+   int rc;
+   int status, burstcnt =3D 0;
+   int count =3D 0;
+   uint32_t ordinal;
+
+   if(tpm_tis_request_locality(tpm, tpm->locality) < 0) {
+      return -EBUSY;
+   }
+
+   status =3D tpm_tis_status(tpm);
+   if((status & TPM_STS_COMMAND_READY) =3D=3D 0) {
+      tpm_tis_ready(tpm);
+      if(wait_for_stat(tpm, TPM_STS_COMMAND_READY, tpm->timeout_b,
&tpm->int_queue) < 0) {
+     rc =3D -ETIME;
+     goto out_err;
+      }
+   }
+
+   while(count < len - 1) {
+      burstcnt =3D get_burstcount(tpm);
+      for(;burstcnt > 0 && count < len -1; --burstcnt) {
+     iowrite8(TPM_DATA_FIFO(tpm, tpm->locality), buf[count++]);
+      }
+
+      wait_for_stat(tpm, TPM_STS_VALID, tpm->timeout_c, &tpm->int_queue)=
;
+      status =3D tpm_tis_status(tpm);
+      if((status & TPM_STS_DATA_EXPECT) =3D=3D 0) {
+     rc =3D -EIO;
+     goto out_err;
+      }
+   }
+
+   /*Write last byte*/
+   iowrite8(TPM_DATA_FIFO(tpm, tpm->locality), buf[count]);
+   wait_for_stat(tpm, TPM_STS_VALID, tpm->timeout_c, &tpm->read_queue);
+   status =3D tpm_tis_status(tpm);
+   if((status & TPM_STS_DATA_EXPECT) !=3D 0) {
+      rc =3D -EIO;
+      goto out_err;
+   }
+
+   /*go and do it*/
+   iowrite8(TPM_STS(tpm, tpm->locality), TPM_STS_GO);
+
+   if(tpm->irq) {
+      /*Wait for interrupt */
+      ordinal =3D be32_to_cpu(*(buf + 6));
+      if(wait_for_stat(tpm,
+           TPM_STS_DATA_AVAIL | TPM_STS_VALID,
+           tpm_calc_ordinal_duration(tpm, ordinal),
+           &tpm->read_queue) < 0) {
+     rc =3D -ETIME;
+     goto out_err;
+      }
+   }
+#ifdef HAVE_LIBC
+   if(tpm->fd >=3D 0) {
+      files[tpm->fd].read =3D 0;
+      files[tpm->fd].tpm_tis.respgot =3D 0;
+      files[tpm->fd].tpm_tis.offset =3D 0;
+   }
+#endif
+   return len;
+
+out_err:
+   tpm_tis_ready(tpm);
+   release_locality(tpm, tpm->locality, 0);
+   return rc;
+}
+
+static void tpm_tis_irq_handler(evtchn_port_t port, struct pt_regs
*regs, void* data)
+{
+   struct tpm_chip* tpm =3D data;
+   uint32_t interrupt;
+   int i;
+
+   interrupt =3D ioread32(TPM_INT_STATUS(tpm, tpm->locality));
+   if(interrupt =3D=3D 0) {
+      return;
+   }
+
+   if(interrupt & TPM_INTF_DATA_AVAIL_INT) {
+      wake_up(&tpm->read_queue);
+   }
+   if(interrupt & TPM_INTF_LOCALITY_CHANGE_INT) {
+      for(i =3D 0; i < 5; ++i) {
+     if(check_locality(tpm, i) >=3D 0) {
+        break;
+     }
+      }
+   }
+   if(interrupt & (TPM_INTF_LOCALITY_CHANGE_INT | TPM_INTF_STS_VALID_INT=
 |
+        TPM_INTF_CMD_READY_INT)) {
+      wake_up(&tpm->int_queue);
+   }
+
+   /* Clear interrupts handled with TPM_EOI */
+   iowrite32(TPM_INT_STATUS(tpm, tpm->locality), interrupt);
+   ioread32(TPM_INT_STATUS(tpm, tpm->locality));
+   return;
+}
+
+/*
+ * Internal kernel interface to transmit TPM commands
+ */
+static ssize_t tpm_transmit(struct tpm_chip *chip, const uint8_t *buf,
+      size_t bufsiz)
+{
+   ssize_t rc;
+   uint32_t count, ordinal;
+   s_time_t stop;
+
+   count =3D be32_to_cpu(*((uint32_t *) (buf + 2)));
+   ordinal =3D be32_to_cpu(*((uint32_t *) (buf + 6)));
+   if (count =3D=3D 0)
+      return -ENODATA;
+   if (count > bufsiz) {
+      printk("Error: invalid count value %x %zx \n", count, bufsiz);
+      return -E2BIG;
+   }
+
+   //down(&chip->tpm_mutex);
+
+   if ((rc =3D tpm_tis_send(chip, (uint8_t *) buf, count)) < 0) {
+      printk("tpm_transmit: tpm_send: error %zd\n", rc);
+      goto out;
+   }
+
+   if (chip->irq)
+      goto out_recv;
+
+   stop =3D NOW() + tpm_calc_ordinal_duration(chip, ordinal);
+   do {
+      uint8_t status =3D tpm_tis_status(chip);
+      if ((status & (TPM_STS_DATA_AVAIL | TPM_STS_VALID)) =3D=3D
+        (TPM_STS_DATA_AVAIL | TPM_STS_VALID))
+     goto out_recv;
+
+      if ((status =3D=3D TPM_STS_COMMAND_READY)) {
+     printk("TPM Error: Operation Canceled\n");
+     rc =3D -ECANCELED;
+     goto out;
+      }
+
+      msleep(TPM_TIMEOUT);    /* CHECK */
+      rmb();
+   } while (NOW() < stop);
+
+   /* Cancel the command */
+   tpm_tis_cancel_cmd(chip);
+   printk("TPM Operation Timed out\n");
+   rc =3D -ETIME;
+   goto out;
+
+out_recv:
+   if((rc =3D tpm_tis_recv(chip, (uint8_t *) buf, bufsiz)) < 0) {
+      printk("tpm_transmit: tpm_recv: error %d\n", rc);
+   }
+out:
+   //up(&chip->tpm_mutex);
+   return rc;
+}
+
+static ssize_t transmit_cmd(struct tpm_chip *chip, struct tpm_cmd_t *cmd=
,
+                            int len, const char *desc)
+{
+        int err;
+
+        len =3D tpm_transmit(chip,(uint8_t *) cmd, len);
+        if (len <  0)
+                return len;
+        if (len =3D=3D TPM_ERROR_SIZE) {
+                err =3D be32_to_cpu(cmd->header.out.return_code);
+                printk("A TPM error (%d) occurred %s\n", err, desc);
+                return err;
+        }
+        return 0;
+}
+
+void tpm_get_timeouts(struct tpm_chip *chip)
+{
+   struct tpm_cmd_t tpm_cmd;
+   struct timeout_t *timeout_cap;
+   struct duration_t *duration_cap;
+   ssize_t rc;
+   uint32_t timeout;
+
+   tpm_cmd.header.in =3D tpm_getcap_header;
+   tpm_cmd.params.getcap_in.cap =3D TPM_CAP_PROP;
+   tpm_cmd.params.getcap_in.subcap_size =3D cpu_to_be32(4);
+   tpm_cmd.params.getcap_in.subcap =3D TPM_CAP_PROP_TIS_TIMEOUT;
+
+   if((rc =3D transmit_cmd(chip, &tpm_cmd, TPM_INTERNAL_RESULT_SIZE,
+     "attempting to determine the timeouts")) !=3D 0) {
+      printk("transmit failed %d\n", rc);
+      goto duration;
+   }
+
+   if (be32_to_cpu(tpm_cmd.params.getcap_out.cap_size)
+     !=3D 4 * sizeof(uint32_t)) {
+      printk("Out len check failure %lu \n",
be32_to_cpu(tpm_cmd.header.out.length));
+      goto duration;
+   }
+
+   timeout_cap =3D &tpm_cmd.params.getcap_out.cap.timeout;
+   /* Don't overwrite default if value is 0 */
+   timeout =3D be32_to_cpu(timeout_cap->a);
+   if (timeout)
+      chip->timeout_a =3D MICROSECS(timeout); /*Convert to msec */
+   timeout =3D be32_to_cpu(timeout_cap->b);
+   if (timeout)
+      chip->timeout_b =3D MICROSECS(timeout); /*Convert to msec */
+   timeout =3D be32_to_cpu(timeout_cap->c);
+   if (timeout)
+      chip->timeout_c =3D MICROSECS(timeout); /*Convert to msec */
+   timeout =3D be32_to_cpu(timeout_cap->d);
+   if (timeout)
+      chip->timeout_d =3D MICROSECS(timeout); /*Convert to msec */
+
+duration:
+   tpm_cmd.header.in =3D tpm_getcap_header;
+   tpm_cmd.params.getcap_in.cap =3D TPM_CAP_PROP;
+   tpm_cmd.params.getcap_in.subcap_size =3D cpu_to_be32(4);
+   tpm_cmd.params.getcap_in.subcap =3D TPM_CAP_PROP_TIS_DURATION;
+
+   if((rc =3D transmit_cmd(chip, &tpm_cmd, TPM_INTERNAL_RESULT_SIZE,
+     "attempting to determine the durations")) < 0) {
+      return;
+   }
+
+   if (be32_to_cpu(tpm_cmd.params.getcap_out.cap_size)
+     !=3D 3 * sizeof(uint32_t)) {
+      return;
+   }
+        duration_cap =3D &tpm_cmd.params.getcap_out.cap.duration;
+        chip->duration[TPM_SHORT] =3D be32_to_cpu(duration_cap->tpm_shor=
t);
+        /* The Broadcom BCM0102 chipset in a Dell Latitude D820 gets
the above
+         * value wrong and apparently reports msecs rather than usecs.
So we
+         * fix up the resulting too-small TPM_SHORT value to make
things work.
+         */
+        if (chip->duration[TPM_SHORT] < 10) {
+       chip->duration[TPM_SHORT] =3D MILLISECS(chip->duration[TPM_SHORT]=
);
+    } else {
+       chip->duration[TPM_SHORT] =3D MICROSECS(chip->duration[TPM_SHORT]=
);
+    }
+
+        chip->duration[TPM_MEDIUM] =3D
MICROSECS(be32_to_cpu(duration_cap->tpm_medium));
+        chip->duration[TPM_LONG] =3D
MICROSECS(be32_to_cpu(duration_cap->tpm_long));
+}
+
+
+
+void tpm_continue_selftest(struct tpm_chip* chip) {
+   uint8_t data[] =3D {
+      0, 193,                 /* TPM_TAG_RQU_COMMAND */
+      0, 0, 0, 10,            /* length */
+      0, 0, 0, 83,            /* TPM_ORD_GetCapability */
+   };
+
+   tpm_transmit(chip, data, sizeof(data));
+}
+
+ssize_t tpm_getcap(struct tpm_chip *chip, uint32_t subcap_id, cap_t *cap=
,
+                   const char *desc)
+{
+        struct tpm_cmd_t tpm_cmd;
+        int rc;
+
+        tpm_cmd.header.in =3D tpm_getcap_header;
+        if (subcap_id =3D=3D CAP_VERSION_1_1 || subcap_id =3D=3D CAP_VER=
SION_1_2) {
+                tpm_cmd.params.getcap_in.cap =3D subcap_id;
+                /*subcap field not necessary */
+                tpm_cmd.params.getcap_in.subcap_size =3D cpu_to_be32(0);=

+                tpm_cmd.header.in.length -=3D cpu_to_be32(sizeof(uint32_=
t));
+        } else {
+                if (subcap_id =3D=3D TPM_CAP_FLAG_PERM ||
+                    subcap_id =3D=3D TPM_CAP_FLAG_VOL)
+                        tpm_cmd.params.getcap_in.cap =3D TPM_CAP_FLAG;
+                else
+                        tpm_cmd.params.getcap_in.cap =3D TPM_CAP_PROP;
+                tpm_cmd.params.getcap_in.subcap_size =3D cpu_to_be32(4);=

+                tpm_cmd.params.getcap_in.subcap =3D subcap_id;
+        }
+        rc =3D transmit_cmd(chip, &tpm_cmd, TPM_INTERNAL_RESULT_SIZE, de=
sc);
+        if (!rc)
+                *cap =3D tpm_cmd.params.getcap_out.cap;
+        return rc;
+}
+
+
+struct tpm_chip* init_tpm_tis(unsigned long baseaddr, int localities,
unsigned int irq)
+{
+   int i;
+   unsigned long addr;
+   struct tpm_chip* tpm =3D NULL;
+   uint32_t didvid;
+   uint32_t intfcaps;
+   uint32_t intmask;
+
+   printk("=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Init TPM TIS Driver =3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D\n");
+
+   /*Sanity check the localities input */
+   if(localities & ~TPM_TIS_EN_LOCLALL) {
+      printk("init_tpm_tis() Invalid locality specification! %X\n",
localities);
+      goto abort_egress;
+   }
+
+   printk("IOMEM Machine Base Address: %lX\n", baseaddr);
+
+   /* Create the tpm data structure */
+   tpm =3D malloc(sizeof(struct tpm_chip));
+   __init_tpm_chip(tpm);
+
+   /* Set the enabled localities - if 0 we leave default as all enabled =
*/
+   if(localities !=3D 0) {
+      tpm->enabled_localities =3D localities;
+   }
+   printk("Enabled Localities: ");
+   for(i =3D 0; i < 5; ++i) {
+      if(locality_enabled(tpm, i)) {
+     printk("%d ", i);
+      }
+   }
+   printk("\n");
+
+   /* Set the base machine address */
+   tpm->baseaddr =3D baseaddr;
+
+   /* Set default timeouts */
+   tpm->timeout_a =3D MILLISECS(TIS_SHORT_TIMEOUT);
+   tpm->timeout_b =3D MILLISECS(TIS_LONG_TIMEOUT);
+   tpm->timeout_c =3D MILLISECS(TIS_SHORT_TIMEOUT);
+   tpm->timeout_d =3D MILLISECS(TIS_SHORT_TIMEOUT);
+
+   /*Map the mmio pages */
+   addr =3D tpm->baseaddr;
+   for(i =3D 0; i < 5; ++i) {
+      if(locality_enabled(tpm, i)) {
+     /* Map the page in now */
+     if((tpm->pages[i] =3D ioremap_nocache(addr, PAGE_SIZE)) =3D=3D NULL=
) {
+        printk("Unable to map iomem page a address %p\n", addr);
+        goto abort_egress;
+     }
+
+     /* Set default locality to the first enabled one */
+     if (tpm->locality < 0) {
+        if(tpm_tis_request_locality(tpm, i) < 0) {
+           printk("Unable to request locality %d??\n", i);
+           goto abort_egress;
+        }
+     }
+      }
+      addr +=3D PAGE_SIZE;
+   }
+
+
+   /* Get the vendor and device ids */
+   didvid =3D ioread32(TPM_DID_VID(tpm, tpm->locality));
+   tpm->did =3D didvid >> 16;
+   tpm->vid =3D didvid & 0xFFFF;
+
+
+   /* Get the revision id */
+   tpm->rid =3D ioread8(TPM_RID(tpm, tpm->locality));
+
+   printk("1.2 TPM (device-id=3D0x%X vendor-id =3D %X rev-id =3D %X)\n",=

tpm->did, tpm->vid, tpm->rid);
+
+   intfcaps =3D ioread32(TPM_INTF_CAPS(tpm, tpm->locality));
+   printk("TPM interface capabilities (0x%x):\n", intfcaps);
+   if (intfcaps & TPM_INTF_BURST_COUNT_STATIC)
+      printk("\tBurst Count Static\n");
+   if (intfcaps & TPM_INTF_CMD_READY_INT)
+      printk("\tCommand Ready Int Support\n");
+   if (intfcaps & TPM_INTF_INT_EDGE_FALLING)
+      printk("\tInterrupt Edge Falling\n");
+   if (intfcaps & TPM_INTF_INT_EDGE_RISING)
+      printk("\tInterrupt Edge Rising\n");
+   if (intfcaps & TPM_INTF_INT_LEVEL_LOW)
+      printk("\tInterrupt Level Low\n");
+   if (intfcaps & TPM_INTF_INT_LEVEL_HIGH)
+      printk("\tInterrupt Level High\n");
+   if (intfcaps & TPM_INTF_LOCALITY_CHANGE_INT)
+      printk("\tLocality Change Int Support\n");
+   if (intfcaps & TPM_INTF_STS_VALID_INT)
+      printk("\tSts Valid Int Support\n");
+   if (intfcaps & TPM_INTF_DATA_AVAIL_INT)
+      printk("\tData Avail Int Support\n");
+
+   /*Interupt setup */
+   intmask =3D ioread32(TPM_INT_ENABLE(tpm, tpm->locality));
+
+   intmask |=3D TPM_INTF_CMD_READY_INT
+      | TPM_INTF_LOCALITY_CHANGE_INT | TPM_INTF_DATA_AVAIL_INT
+      | TPM_INTF_STS_VALID_INT;
+
+   iowrite32(TPM_INT_ENABLE(tpm, tpm->locality), intmask);
+
+   /*If interupts are enabled, handle it */
+   if(irq) {
+      if(irq !=3D TPM_PROBE_IRQ) {
+     tpm->irq =3D irq;
+      } else {
+     /*FIXME add irq probing feature later */
+     printk("IRQ probing not implemented\n");
+      }
+   }
+
+   if(tpm->irq) {
+      iowrite8(TPM_INT_VECTOR(tpm, tpm->locality), tpm->irq);
+
+      if(bind_pirq(tpm->irq, 1, tpm_tis_irq_handler, tpm) !=3D 0) {
+     printk("Unabled to request irq: %u for use\n", tpm->irq);
+     printk("Will use polling mode\n");
+     tpm->irq =3D 0;
+      } else {
+     /* Clear all existing */
+     iowrite32(TPM_INT_STATUS(tpm, tpm->locality),
ioread32(TPM_INT_STATUS(tpm, tpm->locality)));
+
+     /* Turn on interrupts */
+     iowrite32(TPM_INT_ENABLE(tpm, tpm->locality), intmask |
TPM_GLOBAL_INT_ENABLE);
+      }
+   }
+
+   tpm_get_timeouts(tpm);
+   tpm_continue_selftest(tpm);
+
+
+   return tpm;
+abort_egress:
+   if(tpm !=3D NULL) {
+      shutdown_tpm_tis(tpm);
+   }
+   return NULL;
+}
+
+void shutdown_tpm_tis(struct tpm_chip* tpm){
+   int i;
+
+   printk("Shutting down tpm_tis device\n");
+
+   iowrite32(TPM_INT_ENABLE(tpm, tpm->locality), ~TPM_GLOBAL_INT_ENABLE)=
;
+
+   /*Unmap all of the mmio pages */
+   for(i =3D 0; i < 5; ++i) {
+      if(tpm->pages[i] !=3D NULL) {
+     iounmap(tpm->pages[i], PAGE_SIZE);
+     tpm->pages[i] =3D NULL;
+      }
+   }
+   free(tpm);
+   return;
+}
+
+
+int tpm_tis_cmd(struct tpm_chip* tpm, uint8_t* req, size_t reqlen,
uint8_t** resp, size_t* resplen)
+{
+   if(tpm->locality < 0) {
+      printk("tpm_tis_cmd() failed! locality not set!\n");
+      return -1;
+   }
+   if(reqlen > TPM_BUFSIZE) {
+      reqlen =3D TPM_BUFSIZE;
+   }
+   memcpy(tpm->data_buffer, req, reqlen);
+   *resplen =3D tpm_transmit(tpm, tpm->data_buffer, TPM_BUFSIZE);
+
+   *resp =3D malloc(*resplen);
+   memcpy(*resp, tpm->data_buffer, *resplen);
+   return 0;
+}
+
+#ifdef HAVE_LIBC
+int tpm_tis_open(struct tpm_chip* tpm)
+{
+   /* Silently prevent multiple opens */
+   if(tpm->fd !=3D -1) {
+      return tpm->fd;
+   }
+
+   tpm->fd =3D alloc_fd(FTYPE_TPM_TIS);
+   printk("tpm_tis_open() -> %d\n", tpm->fd);
+   files[tpm->fd].tpm_tis.dev =3D tpm;
+   files[tpm->fd].tpm_tis.offset =3D 0;
+   files[tpm->fd].tpm_tis.respgot =3D 0;
+   return tpm->fd;
+}
+
+int tpm_tis_posix_write(int fd, const uint8_t* buf, size_t count)
+{
+   struct tpm_chip* tpm;
+   tpm =3D files[fd].tpm_tis.dev;
+
+   if(tpm->locality < 0) {
+      printk("tpm_tis_posix_write() failed! locality not set!\n");
+      errno =3D EINPROGRESS;
+      return -1;
+   }
+   if(count =3D=3D 0) {
+      return 0;
+   }
+
+   /* Return an error if we are already processing a command */
+   if(count > TPM_BUFSIZE) {
+      count =3D TPM_BUFSIZE;
+   }
+   /* Send the command now */
+   memcpy(tpm->data_buffer, buf, count);
+   if((tpm->data_len =3D tpm_transmit(tpm, tpm->data_buffer,
TPM_BUFSIZE)) < 0) {
+      errno =3D EIO;
+      return -1;
+   }
+   return count;
+}
+
+int tpm_tis_posix_read(int fd, uint8_t* buf, size_t count)
+{
+   int rc;
+   struct tpm_chip* tpm;
+   tpm =3D files[fd].tpm_tis.dev;
+
+   if(count =3D=3D 0) {
+      return 0;
+   }
+
+   /* If there is no tpm resp to read, return EIO */
+   if(tpm->data_len < 0) {
+      errno =3D EIO;
+      return -1;
+   }
+
+
+   /* Handle EOF case */
+   if(files[fd].tpm_tis.offset >=3D tpm->data_len) {
+      rc =3D 0;
+   } else {
+      rc =3D min(tpm->data_len - files[fd].tpm_tis.offset, count);
+      memcpy(buf, tpm->data_buffer + files[fd].tpm_tis.offset, rc);
+   }
+   files[fd].tpm_tis.offset +=3D rc;
+   /* Reset the data pending flag */
+   return rc;
+}
+int tpm_tis_posix_fstat(int fd, struct stat* buf)
+{
+   struct tpm_chip* tpm;
+   tpm =3D files[fd].tpm_tis.dev;
+
+   buf->st_mode =3D O_RDWR;
+   buf->st_uid =3D 0;
+   buf->st_gid =3D 0;
+   buf->st_size =3D be32_to_cpu(*((uint32_t*)(tpm->data_buffer + 2)));
+   buf->st_atime =3D buf->st_mtime =3D buf->st_ctime =3D time(NULL);
+   return 0;
+}
+
+
+#endif
diff --git a/extras/mini-os/tpmback.c b/extras/mini-os/tpmback.c
--- /dev/null
+++ b/extras/mini-os/tpmback.c
@@ -0,0 +1,1125 @@
+/*
+ * Copyright (c) 2010-2012 United States Government, as represented by
+ * the Secretary of Defense.  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 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 MERCHANTABILI=
TY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT
SHALL THE
+ * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHE=
R
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISI=
NG
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
DEALINGS
+ * IN THE SOFTWARE.
+ *
+ * Based upon the files:
+ *  drivers/xen/tpmbk.c
+ * from the Linux kernel, which are Copyright (C) 2006 IBM Corporation
+ */
+#include <mini-os/os.h>
+#include <mini-os/xenbus.h>
+#include <mini-os/events.h>
+#include <errno.h>
+#include <mini-os/gnttab.h>
+#include <xen/io/xenbus.h>
+#include <xen/io/tpmif.h>
+#include <xen/io/protocols.h>
+#include <mini-os/xmalloc.h>
+#include <time.h>
+#include <mini-os/tpmback.h>
+#include <mini-os/lib.h>
+#include <fcntl.h>
+#include <mini-os/mm.h>
+#include <mini-os/posix/sys/mman.h>
+#include <mini-os/semaphore.h>
+#include <mini-os/wait.h>
+
+
+#ifndef HAVE_LIBC
+#define strtoul simple_strtoul
+#endif
+
+//#define TPMBACK_PRINT_DEBUG
+#ifdef TPMBACK_PRINT_DEBUG
+#define TPMBACK_DEBUG(fmt,...) printk("Tpmback:Debug("__FILE__":%d) "
fmt, __LINE__, ##__VA_ARGS__)
+#define TPMBACK_DEBUG_MORE(fmt,...) printk(fmt, ##__VA_ARGS__)
+#else
+#define TPMBACK_DEBUG(fmt,...)
+#endif
+#define TPMBACK_ERR(fmt,...) printk("Tpmback:Error " fmt, ##__VA_ARGS__)=

+#define TPMBACK_LOG(fmt,...) printk("Tpmback:Info " fmt, ##__VA_ARGS__)
+
+#define min(a,b) (((a) < (b)) ? (a) : (b))
+
+/* Default size of the tpmif array at initialization */
+#define DEF_ARRAY_SIZE 1
+
+/* tpmif and tpmdev flags */
+#define TPMIF_CLOSED 1
+#define TPMIF_REQ_READY 2
+
+struct tpmif {
+   domid_t domid;
+   unsigned int handle;
+
+   char* fe_path;
+   char* fe_state_path;
+
+   /* Locally bound event channel*/
+   evtchn_port_t evtchn;
+
+   /* Shared page */
+   tpmif_tx_interface_t* tx;
+
+   /* pointer to TPMIF_RX_RING_SIZE pages */
+   void** pages;
+
+   enum xenbus_state state;
+   enum { DISCONNECTED, DISCONNECTING, CONNECTED } status;
+
+   char* uuid;
+
+   /* state flags */
+   int flags;
+};
+typedef struct tpmif tpmif_t;
+
+struct tpmback_dev {
+
+   tpmif_t** tpmlist;
+   unsigned long num_tpms;
+   unsigned long num_alloc;
+
+   struct gntmap map;
+
+   /* True if at least one tpmif has a request to be handled */
+   int flags;
+
+   /* exclusive domains, see init_tpmback comment in tpmback.h */
+   char** exclusive_uuids;
+
+   xenbus_event_queue events;
+
+   /* Callbacks */
+   void (*open_callback)(domid_t, unsigned int);
+   void (*close_callback)(domid_t, unsigned int);
+   void (*suspend_callback)(domid_t, unsigned int);
+   void (*resume_callback)(domid_t, unsigned int);
+};
+typedef struct tpmback_dev tpmback_dev_t;
+
+enum { EV_NONE, EV_NEWFE, EV_STCHNG } tpm_ev_enum;
+
+/* Global objects */
+static struct thread* eventthread =3D NULL;
+static tpmback_dev_t gtpmdev =3D {
+   .tpmlist =3D NULL,
+   .num_tpms =3D 0,
+   .num_alloc =3D 0,
+   .flags =3D TPMIF_CLOSED,
+   .events =3D NULL,
+   .open_callback =3D NULL,
+   .close_callback =3D NULL,
+   .suspend_callback =3D NULL,
+   .resume_callback =3D NULL,
+};
+struct wait_queue_head waitq;
+int globalinit =3D 0;
+
+/************************************
+ * TPMIF SORTED ARRAY FUNCTIONS
+ * tpmback_dev_t.tpmlist is a sorted array, sorted by domid and then
handle number
+ * Duplicates are not allowed
+ * **********************************/
+
+inline void tpmif_req_ready(tpmif_t* tpmif) {
+   tpmif->flags |=3D TPMIF_REQ_READY;
+   gtpmdev.flags |=3D TPMIF_REQ_READY;
+}
+
+inline void tpmdev_check_req(void) {
+   int i;
+   int flags;
+   local_irq_save(flags);
+   for(i =3D 0; i < gtpmdev.num_tpms; ++i) {
+      if(gtpmdev.tpmlist[i]->flags & TPMIF_REQ_READY) {
+     gtpmdev.flags |=3D TPMIF_REQ_READY;
+     local_irq_restore(flags);
+     return;
+      }
+   }
+   gtpmdev.flags &=3D ~TPMIF_REQ_READY;
+   local_irq_restore(flags);
+}
+
+inline void tpmif_req_finished(tpmif_t* tpmif) {
+   tpmif->flags &=3D ~TPMIF_REQ_READY;
+   tpmdev_check_req();
+}
+
+int __get_tpmif_index(int st, int n, domid_t domid, unsigned int handle)=

+{
+   int i =3D st + n /2;
+   tpmif_t* tmp;
+
+   if( n <=3D 0 )
+      return -1;
+
+   tmp =3D gtpmdev.tpmlist[i];
+   if(domid =3D=3D tmp->domid && tmp->handle =3D=3D handle) {
+      return i;
+   } else if ( (domid < tmp->domid) ||
+     (domid =3D=3D tmp->domid && handle < tmp->handle)) {
+      return __get_tpmif_index(st, n/2, domid, handle);
+   } else {
+      return __get_tpmif_index(i + 1, n/2 - ((n +1) % 2), domid, handle)=
;
+   }
+}
+
+/* Returns the array index of the tpmif domid/handle. Returns -1 if no
such tpmif exists */
+int get_tpmif_index(domid_t domid, unsigned int handle)
+{
+   int flags;
+   int index;
+   local_irq_save(flags);
+   index =3D __get_tpmif_index(0, gtpmdev.num_tpms, domid, handle);
+   local_irq_restore(flags);
+   return index;
+}
+
+/* Returns the tpmif domid/handle or NULL if none exists */
+tpmif_t* get_tpmif(domid_t domid, unsigned int handle)
+{
+   int flags;
+   int i;
+   tpmif_t* ret;
+   local_irq_save(flags);
+   i =3D get_tpmif_index(domid, handle);
+   if (i < 0) {
+      ret =3D NULL;
+   } else {
+      ret =3D gtpmdev.tpmlist[i];
+   }
+   local_irq_restore(flags);
+   return ret;
+}
+
+/* Remove the given tpmif. Returns 0 if it was removed, -1 if it was
not removed */
+int remove_tpmif(tpmif_t* tpmif)
+{
+   int i, j;
+   char* err;
+   int flags;
+   local_irq_save(flags);
+
+   /* Find the index in the array if it exists */
+   i =3D get_tpmif_index(tpmif->domid, tpmif->handle);
+   if (i < 0) {
+      goto error;
+   }
+
+   /* Remove the interface from the list */
+   for(j =3D i; j < gtpmdev.num_tpms - 1; ++j) {
+      gtpmdev.tpmlist[j] =3D gtpmdev.tpmlist[j+1];
+   }
+   gtpmdev.tpmlist[j] =3D NULL;
+   --gtpmdev.num_tpms;
+
+   /* If removed tpm was the only ready tpm, then we need to check and
turn off the ready flag */
+   tpmdev_check_req();
+
+   local_irq_restore(flags);
+
+   /* Stop listening for events on this tpm interface */
+   if((err =3D xenbus_unwatch_path_token(XBT_NIL, tpmif->fe_state_path,
tpmif->fe_state_path))) {
+      TPMBACK_ERR("Unable to unwatch path token `%s' Error was %s
Ignoring..\n", tpmif->fe_state_path, err);
+      free(err);
+   }
+
+   return 0;
+error:
+   local_irq_restore(flags);
+   return -1;
+}
+
+/* Insert tpmif into dev->tpmlist. Returns 0 on success and non zero on
error.
+ * It is an error to insert a tpmif with the same domid and handle
+ * number
+ * as something already in the list */
+int insert_tpmif(tpmif_t* tpmif)
+{
+   int flags;
+   unsigned int i, j;
+   tpmif_t* tmp;
+   char* err;
+
+   local_irq_save(flags);
+
+   /*Check if we need to allocate more space */
+   if (gtpmdev.num_tpms =3D=3D gtpmdev.num_alloc) {
+      gtpmdev.num_alloc *=3D 2;
+      gtpmdev.tpmlist =3D realloc(gtpmdev.tpmlist, gtpmdev.num_alloc);
+   }
+
+   /*Find where to put the new interface */
+   for(i =3D 0; i < gtpmdev.num_tpms; ++i)
+   {
+      tmp =3D gtpmdev.tpmlist[i];
+      if(tpmif->domid =3D=3D tmp->domid && tpmif->handle =3D=3D tmp->han=
dle) {
+     TPMBACK_ERR("Tried to insert duplicate tpm interface %u/%u\n",
(unsigned int) tpmif->domid, tpmif->handle);
+     goto error;
+      }
+      if((tpmif->domid < tmp->domid) ||
+        (tpmif->domid =3D=3D tmp->domid && tpmif->handle < tmp->handle))=
 {
+     break;
+      }
+   }
+
+   /*Shift all the tpm pointers past i down one */
+   for(j =3D gtpmdev.num_tpms; j > i; --j) {
+      gtpmdev.tpmlist[j] =3D gtpmdev.tpmlist[j-1];
+   }
+
+   /*Add the new interface */
+   gtpmdev.tpmlist[i] =3D tpmif;
+   ++gtpmdev.num_tpms;
+
+   /*Should not be needed, anything inserted with ready flag is
probably an error */
+   tpmdev_check_req();
+
+   local_irq_restore(flags);
+
+   /*Listen for state changes on the new interface */
+   if((err =3D xenbus_watch_path_token(XBT_NIL, tpmif->fe_state_path,
tpmif->fe_state_path, &gtpmdev.events)))
+   {
+      /* if we got an error here we should carefully remove the
interface and then return */
+      TPMBACK_ERR("Unable to watch path token `%s' Error was %s\n",
tpmif->fe_state_path, err);
+      free(err);
+      remove_tpmif(tpmif);
+      goto error_post_irq;
+   }
+
+   return 0;
+error:
+   local_irq_restore(flags);
+error_post_irq:
+   return -1;
+}
+
+
+/*****************
+ * CHANGE BACKEND STATE
+ * *****************/
+/*Attempts to change the backend state in xenstore
+ * returns 0 on success and non-zero on error */
+int tpmif_change_state(tpmif_t* tpmif, enum xenbus_state state)
+{
+   char path[512];
+   char *value;
+   char *err;
+   enum xenbus_state readst;
+   TPMBACK_DEBUG("Backend state change %u/%u from=3D%d to=3D%d\n",
(unsigned int) tpmif->domid, tpmif->handle, tpmif->state, state);
+   if (tpmif->state =3D=3D state)
+      return 0;
+
+   snprintf(path, 512, "backend/vtpm/%u/%u/state", (unsigned int)
tpmif->domid, tpmif->handle);
+
+   if((err =3D xenbus_read(XBT_NIL, path, &value))) {
+      TPMBACK_ERR("Unable to read backend state %s, error was %s\n",
path, err);
+      free(err);
+      return -1;
+   }
+   if(sscanf(value, "%d", &readst) !=3D 1) {
+      TPMBACK_ERR("Non integer value (%s) in %s ??\n", value, path);
+      free(value);
+      return -1;
+   }
+   free(value);
+
+   /* It's possible that the backend state got updated by hotplug or
something else behind our back */
+   if(readst !=3D tpmif->state) {
+      TPMBACK_DEBUG("tpm interface state was %d but xenstore state was
%d!\n", tpmif->state, readst);
+      tpmif->state =3D readst;
+   }
+
+   /*If if the state isnt changing, then we dont update xenstore b/c we
dont want to fire extraneous events */
+   if(tpmif->state =3D=3D state) {
+      return 0;
+   }
+
+   /*update xenstore*/
+   snprintf(path, 512, "backend/vtpm/%u/%u", (unsigned int)
tpmif->domid, tpmif->handle);
+   if((err =3D xenbus_printf(XBT_NIL, path, "state", "%u", state))) {
+      TPMBACK_ERR("Error writing to xenstore %s, error was %s new
state=3D%d\n", path, err, state);
+      free(err);
+      return -1;
+   }
+
+   tpmif->state =3D state;
+
+   return 0;
+}
+/**********************************
+ * TPMIF CREATION AND DELETION
+ * *******************************/
+inline tpmif_t* __init_tpmif(domid_t domid, unsigned int handle)
+{
+   tpmif_t* tpmif;
+   tpmif =3D malloc(sizeof(*tpmif));
+   tpmif->domid =3D domid;
+   tpmif->handle =3D handle;
+   tpmif->fe_path =3D NULL;
+   tpmif->fe_state_path =3D NULL;
+   tpmif->state =3D XenbusStateInitialising;
+   tpmif->status =3D DISCONNECTED;
+   tpmif->tx =3D NULL;
+   tpmif->pages =3D NULL;
+   tpmif->flags =3D 0;
+   tpmif->uuid =3D NULL;
+   return tpmif;
+}
+
+void __free_tpmif(tpmif_t* tpmif)
+{
+   if(tpmif->pages) {
+      free(tpmif->pages);
+   }
+   if(tpmif->fe_path) {
+      free(tpmif->fe_path);
+   }
+   if(tpmif->fe_state_path) {
+      free(tpmif->fe_state_path);
+   }
+   if(tpmif->uuid) {
+      free(tpmif->uuid);
+   }
+   free(tpmif);
+}
+/* Creates a new tpm interface, adds it to the sorted array and returns =
it.
+ * returns NULL on error
+ * If the tpm interface already exists, it is returned*/
+tpmif_t* new_tpmif(domid_t domid, unsigned int handle)
+{
+   tpmif_t* tpmif;
+   char* err;
+   char path[512];
+
+   /* Make sure we haven't already created this tpm
+    * Double events can occur */
+   if((tpmif =3D get_tpmif(domid, handle)) !=3D NULL) {
+      return tpmif;
+   }
+
+   tpmif =3D __init_tpmif(domid, handle);
+
+   /* Get the uuid from xenstore */
+   snprintf(path, 512, "backend/vtpm/%u/%u/uuid", (unsigned int) domid,
handle);
+   if((err =3D xenbus_read(XBT_NIL, path, &tpmif->uuid))) {
+      TPMBACK_ERR("Error reading %s, Error =3D %s\n", path, err);
+      free(err);
+      goto error;
+   }
+
+   /* Do the exclusive uuid check now */
+   if(gtpmdev.exclusive_uuids !=3D NULL) {
+      char** ptr;
+
+      /* Check that its in the whitelist */
+      for(ptr =3D gtpmdev.exclusive_uuids; *ptr !=3D NULL; ++ptr) {
+     if(!strcmp(tpmif->uuid, *ptr)) {
+        break;
+     }
+      }
+      /* If *ptr =3D=3D NULL then we went through the whole list without=
 a
match, so close the connection */
+      if(*ptr =3D=3D NULL) {
+     tpmif_change_state(tpmif, XenbusStateClosed);
+     TPMBACK_ERR("Frontend %u/%u tried to connect with invalid
uuid=3D%s\n", (unsigned int) domid, handle, tpmif->uuid);
+     goto error;
+      }
+   }
+
+   /* allocate pages to be used for shared mapping */
+   if((tpmif->pages =3D malloc(sizeof(void*) * TPMIF_TX_RING_SIZE)) =3D=3D=

NULL) {
+      goto error;
+   }
+   memset(tpmif->pages, 0, sizeof(void*) * TPMIF_TX_RING_SIZE);
+
+   if(tpmif_change_state(tpmif, XenbusStateInitWait)) {
+      goto error;
+   }
+
+   snprintf(path, 512, "backend/vtpm/%u/%u/frontend", (unsigned int)
domid, handle);
+   if((err =3D xenbus_read(XBT_NIL, path, &tpmif->fe_path))) {
+      TPMBACK_ERR("Error creating new tpm instance xenbus_read(%s),
Error =3D %s", path, err);
+      free(err);
+      goto error;
+   }
+
+   /*Set the state path */
+   tpmif->fe_state_path =3D malloc(strlen(tpmif->fe_path) + 7);
+   strcpy(tpmif->fe_state_path, tpmif->fe_path);
+   strcat(tpmif->fe_state_path, "/state");
+
+   if(insert_tpmif(tpmif)) {
+      goto error;
+   }
+   TPMBACK_DEBUG("New tpmif %u/%u\n", (unsigned int) tpmif->domid,
tpmif->handle);
+   /* Do the callback now */
+   if(gtpmdev.open_callback) {
+      gtpmdev.open_callback(tpmif->domid, tpmif->handle);
+   }
+   return tpmif;
+error:
+   __free_tpmif(tpmif);
+   return NULL;
+
+}
+
+/* Removes tpmif from dev->tpmlist and frees it's memory usage */
+void free_tpmif(tpmif_t* tpmif)
+{
+   char* err;
+   char path[512];
+   TPMBACK_DEBUG("Free tpmif %u/%u\n", (unsigned int) tpmif->domid,
tpmif->handle);
+   if(tpmif->flags & TPMIF_CLOSED) {
+      TPMBACK_ERR("Tried to free an instance twice! Theres a bug
somewhere!\n");
+      BUG();
+   }
+   tpmif->flags =3D TPMIF_CLOSED;
+
+   tpmif_change_state(tpmif, XenbusStateClosing);
+
+   /* Unmap share page and unbind event channel */
+   if(tpmif->status =3D=3D CONNECTED) {
+      tpmif->status =3D DISCONNECTING;
+      mask_evtchn(tpmif->evtchn);
+
+      if(gntmap_munmap(&gtpmdev.map, (unsigned long)tpmif->tx, 1)) {
+     TPMBACK_ERR("%u/%u Error occured while trying to unmap shared
page\n", (unsigned int) tpmif->domid, tpmif->handle);
+      }
+
+      unbind_evtchn(tpmif->evtchn);
+   }
+   tpmif->status =3D DISCONNECTED;
+   tpmif_change_state(tpmif, XenbusStateClosed);
+
+   /* Do the callback now */
+   if(gtpmdev.close_callback) {
+      gtpmdev.close_callback(tpmif->domid, tpmif->handle);
+   }
+
+   /* remove from array */
+   remove_tpmif(tpmif);
+
+   /* Wake up anyone possibly waiting on this interface and let them
exit */
+   wake_up(&waitq);
+   schedule();
+
+   /* Remove the old xenbus entries */
+   snprintf(path, 512, "backend/vtpm/%u/%u", (unsigned int)
tpmif->domid, tpmif->handle);
+   if((err =3D xenbus_rm(XBT_NIL, path))) {
+      TPMBACK_ERR("Error cleaning up xenbus entries path=3D%s
error=3D%s\n", path, err);
+      free(err);
+   }
+
+   TPMBACK_LOG("Frontend %u/%u disconnected\n", (unsigned int)
tpmif->domid, tpmif->handle);
+
+   /* free memory */
+   __free_tpmif(tpmif);
+
+}
+
+/**********************
+ * REMAINING TPMBACK FUNCTIONS
+ * ********************/
+
+/*Event channel handler */
+void tpmback_handler(evtchn_port_t port, struct pt_regs *regs, void *dat=
a)
+{
+   tpmif_t* tpmif =3D (tpmif_t*) data;
+   tpmif_tx_request_t* tx =3D &tpmif->tx->ring[0].req;
+   /* Throw away 0 size events, these can trigger from event channel
unmasking */
+   if(tx->size =3D=3D 0)
+      return;
+
+   TPMBACK_DEBUG("EVENT CHANNEL FIRE %u/%u\n", (unsigned int)
tpmif->domid, tpmif->handle);
+   tpmif_req_ready(tpmif);
+   wake_up(&waitq);
+
+}
+
+/* Connect to frontend */
+int connect_fe(tpmif_t* tpmif)
+{
+   char path[512];
+   char* err, *value;
+   uint32_t domid;
+   grant_ref_t ringref;
+   evtchn_port_t evtchn;
+
+   /* If already connected then quit */
+   if (tpmif->status =3D=3D CONNECTED) {
+      TPMBACK_DEBUG("%u/%u tried to connect while it was already
connected?\n", (unsigned int) tpmif->domid, tpmif->handle);
+      return 0;
+   }
+
+   /* Fetch the grant reference */
+   snprintf(path, 512, "%s/ring-ref", tpmif->fe_path);
+   if((err =3D xenbus_read(XBT_NIL, path, &value))) {
+      TPMBACK_ERR("Error creating new tpm instance xenbus_read(%s)
Error =3D %s", path, err);
+      free(err);
+      return -1;
+   }
+   if(sscanf(value, "%d", &ringref) !=3D 1) {
+      TPMBACK_ERR("Non integer value (%s) in %s ??\n", value, path);
+      free(value);
+      return -1;
+   }
+   free(value);
+
+
+   /* Fetch the event channel*/
+   snprintf(path, 512, "%s/event-channel", tpmif->fe_path);
+   if((err =3D xenbus_read(XBT_NIL, path, &value))) {
+      TPMBACK_ERR("Error creating new tpm instance xenbus_read(%s)
Error =3D %s", path, err);
+      free(err);
+      return -1;
+   }
+   if(sscanf(value, "%d", &evtchn) !=3D 1) {
+      TPMBACK_ERR("Non integer value (%s) in %s ??\n", value, path);
+      free(value);
+      return -1;
+   }
+   free(value);
+
+   domid =3D tpmif->domid;
+   if((tpmif->tx =3D gntmap_map_grant_refs(&gtpmdev.map, 1, &domid, 0,
&ringref, PROT_READ | PROT_WRITE)) =3D=3D NULL) {
+      TPMBACK_ERR("Failed to map grant reference %u/%u\n", (unsigned
int) tpmif->domid, tpmif->handle);
+      return -1;
+   }
+   memset(tpmif->tx, 0, PAGE_SIZE);
+
+   /*Bind the event channel */
+   if((evtchn_bind_interdomain(tpmif->domid, evtchn, tpmback_handler,
tpmif, &tpmif->evtchn)))
+   {
+      TPMBACK_ERR("%u/%u Unable to bind to interdomain event
channel!\n", (unsigned int) tpmif->domid, tpmif->handle);
+      goto error_post_map;
+   }
+   unmask_evtchn(tpmif->evtchn);
+
+   /* Write the ready flag and change status to connected */
+   snprintf(path, 512, "backend/vtpm/%u/%u", (unsigned int)
tpmif->domid, tpmif->handle);
+   if((err =3D xenbus_printf(XBT_NIL, path, "ready", "%u", 1))) {
+      TPMBACK_ERR("%u/%u Unable to write ready flag on connect_fe()\n",
(unsigned int) tpmif->domid, tpmif->handle);
+      free(err);
+      goto error_post_evtchn;
+   }
+   tpmif->status =3D CONNECTED;
+   if((tpmif_change_state(tpmif, XenbusStateConnected))){
+      goto error_post_evtchn;
+   }
+
+   TPMBACK_LOG("Frontend %u/%u connected\n", (unsigned int)
tpmif->domid, tpmif->handle);
+
+   return 0;
+error_post_evtchn:
+   mask_evtchn(tpmif->evtchn);
+   unbind_evtchn(tpmif->evtchn);
+error_post_map:
+   gntmap_munmap(&gtpmdev.map, (unsigned long)tpmif->tx, 1);
+   return -1;
+}
+
+static int frontend_changed(tpmif_t* tpmif)
+{
+   int state =3D xenbus_read_integer(tpmif->fe_state_path);
+   if(state < 0) {
+      state =3D XenbusStateUnknown;
+   }
+
+   TPMBACK_DEBUG("Frontend %u/%u state changed to %d\n", (unsigned int)
tpmif->domid, tpmif->handle, state);
+
+   switch (state) {
+      case XenbusStateInitialising:
+      case XenbusStateInitialised:
+     break;
+
+      case XenbusStateConnected:
+     if(connect_fe(tpmif)) {
+        TPMBACK_ERR("Failed to connect to front end %u/%u\n", (unsigned
int) tpmif->domid, tpmif->handle);
+        tpmif_change_state(tpmif, XenbusStateClosed);
+        return -1;
+     }
+     break;
+
+      case XenbusStateClosing:
+     tpmif_change_state(tpmif, XenbusStateClosing);
+     break;
+
+      case XenbusStateUnknown: /* keep it here */
+      case XenbusStateClosed:
+     free_tpmif(tpmif);
+     break;
+
+      default:
+     TPMBACK_DEBUG("BAD STATE CHANGE %u/%u state =3D %d for tpmif\n",
(unsigned int) tpmif->domid, tpmif->handle, state);
+     return -1;
+   }
+   return 0;
+}
+
+
+/* parses the string that comes out of xenbus_watch_wait_return. */
+static int parse_eventstr(const char* evstr, domid_t* domid, unsigned
int* handle)
+{
+   int ret;
+   char cmd[40];
+   char* err;
+   char* value;
+   unsigned int udomid =3D 0;
+   tpmif_t* tpmif;
+   /* First check for new frontends, this occurs when
/backend/vtpm/<domid>/<handle> gets created. Note we what the sscanf to
fail on the last %s */
+   if (sscanf(evstr, "backend/vtpm/%u/%u/%40s", &udomid, handle, cmd)
=3D=3D 2) {
+      *domid =3D udomid;
+      /* Make sure the entry exists, if this event triggers because the
entry dissapeared then ignore it */
+      if((err =3D xenbus_read(XBT_NIL, evstr, &value))) {
+     free(err);
+     return EV_NONE;
+      }
+      free(value);
+      /* Make sure the tpmif entry does not already exist, this should
not happen */
+      if((tpmif =3D get_tpmif(*domid, *handle)) !=3D NULL) {
+     TPMBACK_DEBUG("Duplicate tpm entries! %u %u\n", tpmif->domid,
tpmif->handle);
+     return EV_NONE;
+      }
+      return EV_NEWFE;
+   } else if((ret =3D sscanf(evstr,
"/local/domain/%u/device/vtpm/%u/%40s", &udomid, handle, cmd)) =3D=3D 3) =
{
+      *domid =3D udomid;
+      if (!strcmp(cmd, "state"))
+     return EV_STCHNG;
+   }
+   return EV_NONE;
+}
+
+void handle_backend_event(char* evstr) {
+   tpmif_t* tpmif;
+   domid_t domid;
+   unsigned int handle;
+   int event;
+
+   TPMBACK_DEBUG("Xenbus Event: %s\n", evstr);
+
+   event =3D parse_eventstr(evstr, &domid, &handle);
+
+   switch(event) {
+      case EV_NEWFE:
+     if(new_tpmif(domid, handle) =3D=3D NULL) {
+        TPMBACK_ERR("Failed to create new tpm instance %u/%u\n",
(unsigned int) domid, handle);
+     }
+     wake_up(&waitq);
+     break;
+      case EV_STCHNG:
+     if((tpmif =3D get_tpmif(domid, handle))) {
+        frontend_changed(tpmif);
+     } else {
+        TPMBACK_DEBUG("Event Received for non-existant tpm!
instance=3D%u/%u xenbus_event=3D%s\n", (unsigned int) domid, handle, evst=
r);
+     }
+     break;
+   }
+}
+
+/* Runs through the given path and creates events recursively
+ * for all of its children.
+ * @path - xenstore path to scan */
+static void generate_backend_events(const char* path)
+{
+   char* err;
+   int i, len;
+   char **dirs;
+   char *entry;
+
+   if((err =3D xenbus_ls(XBT_NIL, path, &dirs)) !=3D NULL) {
+      free(err);
+      return;
+   }
+
+   for(i =3D 0; dirs[i] !=3D NULL; ++i) {
+      len =3D strlen(path) + strlen(dirs[i]) + 2;
+      entry =3D malloc(len);
+      snprintf(entry, len, "%s/%s", path, dirs[i]);
+
+      /* Generate and handle event for the entry itself */
+      handle_backend_event(entry);
+
+      /* Do children */
+      generate_backend_events(entry);
+
+      /* Cleanup */
+      free(entry);
+      free(dirs[i]);
+   }
+   free(dirs);
+   return;
+}
+
+char* tpmback_get_uuid(domid_t domid, unsigned int handle)
+{
+   tpmif_t* tpmif;
+   if((tpmif =3D get_tpmif(domid, handle)) =3D=3D NULL) {
+      TPMBACK_DEBUG("get_uuid() failed, %u/%u is an invalid
frontend\n", (unsigned int) domid, handle);
+      return NULL;
+   }
+
+   return tpmif->uuid;
+}
+
+void tpmback_set_open_callback(void (*cb)(domid_t, unsigned int))
+{
+   gtpmdev.open_callback =3D cb;
+}
+void tpmback_set_close_callback(void (*cb)(domid_t, unsigned int))
+{
+   gtpmdev.close_callback =3D cb;
+}
+void tpmback_set_suspend_callback(void (*cb)(domid_t, unsigned int))
+{
+   gtpmdev.suspend_callback =3D cb;
+}
+void tpmback_set_resume_callback(void (*cb)(domid_t, unsigned int))
+{
+   gtpmdev.resume_callback =3D cb;
+}
+
+static void event_listener(void)
+{
+   const char* bepath =3D "backend/vtpm";
+   char **path;
+   char* err;
+
+   /* Setup the backend device watch */
+   if((err =3D xenbus_watch_path_token(XBT_NIL, bepath, bepath,
&gtpmdev.events)) !=3D NULL) {
+      TPMBACK_ERR("xenbus_watch_path_token(%s) failed with error
%s!\n", bepath, err);
+      free(err);
+      goto egress;
+   }
+
+   /* Check for any frontends that connected before we set the watch.
+    * This is almost guaranteed to happen if both domains are started
+    * immediatly one after the other.
+    * We do this by manually generating events on everything in the back=
end
+    * path */
+   generate_backend_events(bepath);
+
+   /* Wait and listen for changes in frontend connections */
+   while(1) {
+      path =3D xenbus_wait_for_watch_return(&gtpmdev.events);
+
+      /*If quit flag was set then exit */
+      if(gtpmdev.flags & TPMIF_CLOSED) {
+     TPMBACK_DEBUG("listener thread got quit event. Exiting..\n");
+     free(path);
+     break;
+      }
+      handle_backend_event(*path);
+      free(path);
+
+   }
+
+   if((err =3D xenbus_unwatch_path_token(XBT_NIL, bepath, bepath)) !=3D =
NULL) {
+      free(err);
+   }
+egress:
+   return;
+}
+
+void event_thread(void* p) {
+   event_listener();
+}
+
+void init_tpmback(char** exclusive_uuids)
+{
+   if(!globalinit) {
+      init_waitqueue_head(&waitq);
+      globalinit =3D 1;
+   }
+   printk("=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Init TPM BACK =3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D\n");
+   gtpmdev.tpmlist =3D malloc(sizeof(tpmif_t*) * DEF_ARRAY_SIZE);
+   gtpmdev.num_alloc =3D DEF_ARRAY_SIZE;
+   gtpmdev.num_tpms =3D 0;
+   gtpmdev.flags =3D 0;
+   gtpmdev.exclusive_uuids =3D exclusive_uuids;
+
+   gtpmdev.open_callback =3D gtpmdev.close_callback =3D NULL;
+   gtpmdev.suspend_callback =3D gtpmdev.resume_callback =3D NULL;
+
+   eventthread =3D create_thread("tpmback-listener", event_thread, NULL)=
;
+
+}
+
+void shutdown_tpmback(void)
+{
+   /* Disable callbacks */
+   gtpmdev.open_callback =3D gtpmdev.close_callback =3D NULL;
+   gtpmdev.suspend_callback =3D gtpmdev.resume_callback =3D NULL;
+
+   TPMBACK_LOG("Shutting down tpm backend\n");
+   /* Set the quit flag */
+   gtpmdev.flags =3D TPMIF_CLOSED;
+
+   //printk("num tpms is %d\n", gtpmdev.num_tpms);
+   /*Free all backend instances */
+   while(gtpmdev.num_tpms) {
+      free_tpmif(gtpmdev.tpmlist[0]);
+   }
+   free(gtpmdev.tpmlist);
+   gtpmdev.tpmlist =3D NULL;
+   gtpmdev.num_alloc =3D 0;
+
+   /* Wake up anyone possibly waiting on the device and let them exit */=

+   wake_up(&waitq);
+   schedule();
+}
+
+inline void init_tpmcmd(tpmcmd_t* tpmcmd, domid_t domid, unsigned int
handle, char* uuid)
+{
+   tpmcmd->domid =3D domid;
+   tpmcmd->handle =3D handle;
+   tpmcmd->uuid =3D uuid;
+   tpmcmd->req =3D NULL;
+   tpmcmd->req_len =3D 0;
+   tpmcmd->resp =3D NULL;
+   tpmcmd->resp_len =3D 0;
+}
+
+tpmcmd_t* get_request(tpmif_t* tpmif) {
+   tpmcmd_t* cmd;
+   tpmif_tx_request_t* tx;
+   int offset;
+   int tocopy;
+   int i;
+   uint32_t domid;
+   int flags;
+
+   local_irq_save(flags);
+
+   /* Allocate the cmd object to hold the data */
+   if((cmd =3D malloc(sizeof(*cmd))) =3D=3D NULL) {
+      goto error;
+   }
+   init_tpmcmd(cmd, tpmif->domid, tpmif->handle, tpmif->uuid);
+
+   tx =3D &tpmif->tx->ring[0].req;
+   cmd->req_len =3D tx->size;
+   /* Allocate the buffer */
+   if(cmd->req_len) {
+      if((cmd->req =3D malloc(cmd->req_len)) =3D=3D NULL) {
+     goto error;
+      }
+   }
+   /* Copy the bits from the shared pages */
+   offset =3D 0;
+   for(i =3D 0; i < TPMIF_TX_RING_SIZE && offset < cmd->req_len; ++i) {
+      tx =3D &tpmif->tx->ring[i].req;
+
+      /* Map the page with the data */
+      domid =3D (uint32_t)tpmif->domid;
+      if((tpmif->pages[i] =3D gntmap_map_grant_refs(&gtpmdev.map, 1,
&domid, 0, &tx->ref, PROT_READ)) =3D=3D NULL) {
+     TPMBACK_ERR("%u/%u Unable to map shared page during read!\n",
(unsigned int) tpmif->domid, tpmif->handle);
+     goto error;
+      }
+
+      /* do the copy now */
+      tocopy =3D min(cmd->req_len - offset, PAGE_SIZE);
+      memcpy(&cmd->req[offset], tpmif->pages[i], tocopy);
+      offset +=3D tocopy;
+
+      /* release the page */
+      gntmap_munmap(&gtpmdev.map, (unsigned long)tpmif->pages[i], 1);
+
+   }
+
+#ifdef TPMBACK_PRINT_DEBUG
+   TPMBACK_DEBUG("Received Tpm Command from %u/%u of size %u",
(unsigned int) tpmif->domid, tpmif->handle, cmd->req_len);
+   for(i =3D 0; i < cmd->req_len; ++i) {
+      if (!(i % 30)) {
+     TPMBACK_DEBUG_MORE("\n");
+      }
+      TPMBACK_DEBUG_MORE("%02hhX ", cmd->req[i]);
+   }
+   TPMBACK_DEBUG_MORE("\n\n");
+#endif
+
+   local_irq_restore(flags);
+   return cmd;
+error:
+   if(cmd !=3D NULL) {
+      if (cmd->req !=3D NULL) {
+     free(cmd->req);
+     cmd->req =3D NULL;
+      }
+      free(cmd);
+      cmd =3D NULL;
+   }
+   local_irq_restore(flags);
+   return NULL;
+
+}
+
+void send_response(tpmcmd_t* cmd, tpmif_t* tpmif)
+{
+   tpmif_tx_request_t* tx;
+   int offset;
+   int i;
+   uint32_t domid;
+   int tocopy;
+   int flags;
+
+   local_irq_save(flags);
+
+   tx =3D &tpmif->tx->ring[0].req;
+   tx->size =3D cmd->resp_len;
+
+   offset =3D 0;
+   for(i =3D 0; i < TPMIF_TX_RING_SIZE && offset < cmd->resp_len; ++i) {=

+      tx =3D &tpmif->tx->ring[i].req;
+
+      /* Map the page with the data */
+      domid =3D (uint32_t)tpmif->domid;
+      if((tpmif->pages[i] =3D gntmap_map_grant_refs(&gtpmdev.map, 1,
&domid, 0, &tx->ref, PROT_WRITE)) =3D=3D NULL) {
+     TPMBACK_ERR("%u/%u Unable to map shared page during write!\n",
(unsigned int) tpmif->domid, tpmif->handle);
+     goto error;
+      }
+
+      /* do the copy now */
+      tocopy =3D min(cmd->resp_len - offset, PAGE_SIZE);
+      memcpy(tpmif->pages[i], &cmd->resp[offset], tocopy);
+      offset +=3D tocopy;
+
+      /* release the page */
+      gntmap_munmap(&gtpmdev.map, (unsigned long)tpmif->pages[i], 1);
+
+   }
+
+#ifdef TPMBACK_PRINT_DEBUG
+   TPMBACK_DEBUG("Sent response to %u/%u of size %u", (unsigned int)
tpmif->domid, tpmif->handle, cmd->resp_len);
+   for(i =3D 0; i < cmd->resp_len; ++i) {
+      if (!(i % 30)) {
+     TPMBACK_DEBUG_MORE("\n");
+      }
+      TPMBACK_DEBUG_MORE("%02hhX ", cmd->resp[i]);
+   }
+   TPMBACK_DEBUG_MORE("\n\n");
+#endif
+   /* clear the ready flag and send the event channel notice to the
frontend */
+   tpmif_req_finished(tpmif);
+   notify_remote_via_evtchn(tpmif->evtchn);
+error:
+   local_irq_restore(flags);
+   return;
+}
+
+tpmcmd_t* tpmback_req_any(void)
+{
+   int i;
+   /* Block until something has a request */
+   wait_event(waitq, (gtpmdev.flags & (TPMIF_REQ_READY | TPMIF_CLOSED)))=
;
+
+   /* Check if were shutting down */
+   if(gtpmdev.flags & TPMIF_CLOSED) {
+      /* if something was waiting for us to give up the queue so it can
shutdown, let it finish */
+      schedule();
+      return NULL;
+   }
+
+   for(i =3D 0; i < gtpmdev.num_tpms; ++i) {
+      if(gtpmdev.tpmlist[i]->flags & TPMIF_REQ_READY) {
+     return get_request(gtpmdev.tpmlist[i]);
+      }
+   }
+
+   TPMBACK_ERR("backend request ready flag was set but no interfaces
were actually ready\n");
+   return NULL;
+}
+
+tpmcmd_t* tpmback_req(domid_t domid, unsigned int handle)
+{
+   tpmif_t* tpmif;
+   tpmif =3D get_tpmif(domid, handle);
+   if(tpmif =3D=3D NULL) {
+      return NULL;
+   }
+
+   wait_event(waitq, (tpmif->flags & (TPMIF_REQ_READY | TPMIF_CLOSED)
|| gtpmdev.flags & TPMIF_CLOSED));
+
+   /* Check if were shutting down */
+   if(tpmif->flags & TPMIF_CLOSED || gtpmdev.flags & TPMIF_CLOSED) {
+      /* if something was waiting for us to give up the queue so it can
free this instance, let it finish */
+      schedule();
+      return NULL;
+   }
+
+   return get_request(tpmif);
+}
+
+void tpmback_resp(tpmcmd_t* tpmcmd)
+{
+   tpmif_t* tpmif;
+
+   /* Get the associated interface, if it doesnt exist then just quit */=

+   tpmif =3D get_tpmif(tpmcmd->domid, tpmcmd->handle);
+   if(tpmif =3D=3D NULL) {
+      TPMBACK_ERR("Tried to send a reponse to non existant frontend
%u/%u\n", (unsigned int) tpmcmd->domid, tpmcmd->handle);
+      goto end;
+   }
+
+   if(!(tpmif->flags & TPMIF_REQ_READY)) {
+      TPMBACK_ERR("Tried to send response to a frontend that was not
waiting for one %u/%u\n", (unsigned int) tpmcmd->domid, tpmcmd->handle);
+      goto end;
+   }
+
+   /* Send response to frontend */
+   send_response(tpmcmd, tpmif);
+
+end:
+   if(tpmcmd->req !=3D NULL) {
+      free(tpmcmd->req);
+   }
+   free(tpmcmd);
+   return;
+}
+
+int tpmback_wait_for_frontend_connect(domid_t *domid, unsigned int *hand=
le)
+{
+   tpmif_t* tpmif;
+   int flags;
+   wait_event(waitq, ((gtpmdev.num_tpms > 0) || gtpmdev.flags &
TPMIF_CLOSED));
+   if(gtpmdev.flags & TPMIF_CLOSED) {
+      return -1;
+   }
+   local_irq_save(flags);
+   tpmif =3D gtpmdev.tpmlist[0];
+   *domid =3D tpmif->domid;
+   *handle =3D tpmif->handle;
+   local_irq_restore(flags);
+
+   return 0;
+}
+
+int tpmback_num_frontends(void)
+{
+   return gtpmdev.num_tpms;
+}
diff --git a/extras/mini-os/tpmfront.c b/extras/mini-os/tpmfront.c
--- /dev/null
+++ b/extras/mini-os/tpmfront.c
@@ -0,0 +1,617 @@
+/*
+ * Copyright (c) 2010-2012 United States Government, as represented by
+ * the Secretary of Defense.  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 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 MERCHANTABILI=
TY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT
SHALL THE
+ * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHE=
R
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISI=
NG
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
DEALINGS
+ * IN THE SOFTWARE.
+ *
+ * Based upon the files:
+ *  drivers/char/tpm/tpm_vtpm.c
+ *  drivers/char/tpm/tpm_xen.c
+ * from the Linux kernel, which are Copyright (C) 2006 IBM Corporation
+ */
+#include <mini-os/os.h>
+#include <mini-os/xenbus.h>
+#include <mini-os/xmalloc.h>
+#include <mini-os/events.h>
+#include <mini-os/wait.h>
+#include <mini-os/gnttab.h>
+#include <xen/io/xenbus.h>
+#include <xen/io/tpmif.h>
+#include <mini-os/tpmfront.h>
+#include <fcntl.h>
+
+//#define TPMFRONT_PRINT_DEBUG
+#ifdef TPMFRONT_PRINT_DEBUG
+#define TPMFRONT_DEBUG(fmt,...) printk("Tpmfront:Debug("__FILE__":%d) "
fmt, __LINE__, ##__VA_ARGS__)
+#define TPMFRONT_DEBUG_MORE(fmt,...) printk(fmt, ##__VA_ARGS__)
+#else
+#define TPMFRONT_DEBUG(fmt,...)
+#endif
+#define TPMFRONT_ERR(fmt,...) printk("Tpmfront:Error " fmt, ##__VA_ARGS_=
_)
+#define TPMFRONT_LOG(fmt,...) printk("Tpmfront:Info " fmt, ##__VA_ARGS__=
)
+
+#define min(a,b) (((a) < (b)) ? (a) : (b))
+
+void tpmfront_handler(evtchn_port_t port, struct pt_regs *regs, void
*data) {
+   struct tpmfront_dev* dev =3D (struct tpmfront_dev*) data;
+   /*If we get a response when we didnt make a request, just ignore it *=
/
+   if(!dev->waiting) {
+      return;
+   }
+
+   dev->waiting =3D 0;
+#ifdef HAVE_LIBC
+   if(dev->fd >=3D 0) {
+      files[dev->fd].read =3D 1;
+   }
+#endif
+   wake_up(&dev->waitq);
+}
+
+static int publish_xenbus(struct tpmfront_dev* dev) {
+   xenbus_transaction_t xbt;
+   int retry;
+   char* err;
+   /* Write the grant reference and event channel to xenstore */
+again:
+   if((err =3D xenbus_transaction_start(&xbt))) {
+      TPMFRONT_ERR("Unable to start xenbus transaction, error was
%s\n", err);
+      free(err);
+      return -1;
+   }
+
+   if((err =3D xenbus_printf(xbt, dev->nodename, "ring-ref", "%u",
(unsigned int) dev->ring_ref))) {
+      TPMFRONT_ERR("Unable to write %s/ring-ref, error was %s\n",
dev->nodename, err);
+      free(err);
+      goto abort_transaction;
+   }
+
+   if((err =3D xenbus_printf(xbt, dev->nodename, "event-channel", "%u",
(unsigned int) dev->evtchn))) {
+      TPMFRONT_ERR("Unable to write %s/event-channel, error was %s\n",
dev->nodename, err);
+      free(err);
+      goto abort_transaction;
+   }
+
+   if((err =3D xenbus_transaction_end(xbt, 0, &retry))) {
+      TPMFRONT_ERR("Unable to complete xenbus transaction, error was
%s\n", err);
+      free(err);
+      return -1;
+   }
+   if(retry) {
+      goto again;
+   }
+
+   return 0;
+abort_transaction:
+   if((err =3D xenbus_transaction_end(xbt, 1, &retry))) {
+      free(err);
+   }
+   return -1;
+}
+
+static int wait_for_backend_connect(xenbus_event_queue* events, char* pa=
th)
+{
+   int state;
+
+   TPMFRONT_LOG("Waiting for backend connection..\n");
+   /* Wait for the backend to connect */
+   while(1) {
+      state =3D xenbus_read_integer(path);
+      if ( state < 0)
+     state =3D XenbusStateUnknown;
+      switch(state) {
+     /* Bad states, we quit with error */
+     case XenbusStateUnknown:
+     case XenbusStateClosing:
+     case XenbusStateClosed:
+        TPMFRONT_ERR("Unable to connect to backend\n");
+        return -1;
+     /* If backend is connected then break out of loop */
+     case XenbusStateConnected:
+        TPMFRONT_LOG("Backend Connected\n");
+        return 0;
+     default:
+        xenbus_wait_for_watch(events);
+      }
+   }
+
+}
+
+static int wait_for_backend_closed(xenbus_event_queue* events, char* pat=
h)
+{
+   int state;
+
+   TPMFRONT_LOG("Waiting for backend to close..\n");
+   while(1) {
+      state =3D xenbus_read_integer(path);
+      if ( state < 0)
+     state =3D XenbusStateUnknown;
+      switch(state) {
+     case XenbusStateUnknown:
+        TPMFRONT_ERR("Backend Unknown state, forcing shutdown\n");
+        return -1;
+     case XenbusStateClosed:
+        TPMFRONT_LOG("Backend Closed\n");
+        return 0;
+     default:
+        xenbus_wait_for_watch(events);
+      }
+   }
+
+}
+
+static int wait_for_backend_state_changed(struct tpmfront_dev* dev,
XenbusState state) {
+   char* err;
+   int ret =3D 0;
+   xenbus_event_queue events =3D NULL;
+   char path[512];
+
+   snprintf(path, 512, "%s/state", dev->bepath);
+   /*Setup the watch to wait for the backend */
+   if((err =3D xenbus_watch_path_token(XBT_NIL, path, path, &events))) {=

+      TPMFRONT_ERR("Could not set a watch on %s, error was %s\n", path,
err);
+      free(err);
+      return -1;
+   }
+
+   /* Do the actual wait loop now */
+   switch(state) {
+      case XenbusStateConnected:
+     ret =3D wait_for_backend_connect(&events, path);
+     break;
+      case XenbusStateClosed:
+     ret =3D wait_for_backend_closed(&events, path);
+     break;
+      default:
+     break;
+   }
+
+   if((err =3D xenbus_unwatch_path_token(XBT_NIL, path, path))) {
+      TPMFRONT_ERR("Unable to unwatch %s, error was %s, ignoring..\n",
path, err);
+      free(err);
+   }
+   return ret;
+}
+
+static int tpmfront_connect(struct tpmfront_dev* dev)
+{
+   char* err;
+   /* Create shared page */
+   dev->tx =3D (tpmif_tx_interface_t*) alloc_page();
+   if(dev->tx =3D=3D NULL) {
+      TPMFRONT_ERR("Unable to allocate page for shared memory\n");
+      goto error;
+   }
+   memset(dev->tx, 0, PAGE_SIZE);
+   dev->ring_ref =3D gnttab_grant_access(dev->bedomid,
virt_to_mfn(dev->tx), 0);
+   TPMFRONT_DEBUG("grant ref is %lu\n", (unsigned long) dev->ring_ref);
+
+   /*Create event channel */
+   if(evtchn_alloc_unbound(dev->bedomid, tpmfront_handler, dev,
&dev->evtchn)) {
+      TPMFRONT_ERR("Unable to allocate event channel\n");
+      goto error_postmap;
+   }
+   unmask_evtchn(dev->evtchn);
+   TPMFRONT_DEBUG("event channel is %lu\n", (unsigned long) dev->evtchn)=
;
+
+   /* Write the entries to xenstore */
+   if(publish_xenbus(dev)) {
+      goto error_postevtchn;
+   }
+
+   /* Change state to connected */
+   dev->state =3D XenbusStateConnected;
+
+   /* Tell the backend that we are ready */
+   if((err =3D xenbus_printf(XBT_NIL, dev->nodename, "state", "%u",
dev->state))) {
+      TPMFRONT_ERR("Unable to write to xenstore %s/state, value=3D%u",
dev->nodename, XenbusStateConnected);
+      free(err);
+      goto error;
+   }
+
+   return 0;
+error_postevtchn:
+      mask_evtchn(dev->evtchn);
+      unbind_evtchn(dev->evtchn);
+error_postmap:
+      gnttab_end_access(dev->ring_ref);
+      free_page(dev->tx);
+error:
+   return -1;
+}
+
+struct tpmfront_dev* init_tpmfront(const char* _nodename)
+{
+   struct tpmfront_dev* dev;
+   const char* nodename;
+   char path[512];
+   char* value, *err;
+   unsigned long long ival;
+   int i;
+
+   printk("=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Init TPM Front =3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D\n");
+
+   dev =3D malloc(sizeof(struct tpmfront_dev));
+   memset(dev, 0, sizeof(struct tpmfront_dev));
+
+#ifdef HAVE_LIBC
+   dev->fd =3D -1;
+#endif
+
+   nodename =3D _nodename ? _nodename : "device/vtpm/0";
+   dev->nodename =3D strdup(nodename);
+
+   init_waitqueue_head(&dev->waitq);
+
+   /* Get backend domid */
+   snprintf(path, 512, "%s/backend-id", dev->nodename);
+   if((err =3D xenbus_read(XBT_NIL, path, &value))) {
+      TPMFRONT_ERR("Unable to read %s during tpmfront initialization!
error =3D %s\n", path, err);
+      free(err);
+      goto error;
+   }
+   if(sscanf(value, "%llu", &ival) !=3D 1) {
+      TPMFRONT_ERR("%s has non-integer value (%s)\n", path, value);
+      free(value);
+      goto error;
+   }
+   free(value);
+   dev->bedomid =3D ival;
+
+   /* Get backend xenstore path */
+   snprintf(path, 512, "%s/backend", dev->nodename);
+   if((err =3D xenbus_read(XBT_NIL, path, &dev->bepath))) {
+      TPMFRONT_ERR("Unable to read %s during tpmfront initialization!
error =3D %s\n", path, err);
+      free(err);
+      goto error;
+   }
+
+   /* Create and publish grant reference and event channel */
+   if (tpmfront_connect(dev)) {
+      goto error;
+   }
+
+   /* Wait for backend to connect */
+   if( wait_for_backend_state_changed(dev, XenbusStateConnected)) {
+      goto error;
+   }
+
+   /* Allocate pages that will contain the messages */
+   dev->pages =3D malloc(sizeof(void*) * TPMIF_TX_RING_SIZE);
+   if(dev->pages =3D=3D NULL) {
+      goto error;
+   }
+   memset(dev->pages, 0, sizeof(void*) * TPMIF_TX_RING_SIZE);
+   for(i =3D 0; i < TPMIF_TX_RING_SIZE; ++i) {
+      dev->pages[i] =3D (void*)alloc_page();
+      if(dev->pages[i] =3D=3D NULL) {
+     goto error;
+      }
+   }
+
+   TPMFRONT_LOG("Initialization Completed successfully\n");
+
+   return dev;
+
+error:
+   shutdown_tpmfront(dev);
+   return NULL;
+}
+void shutdown_tpmfront(struct tpmfront_dev* dev)
+{
+   char* err;
+   char path[512];
+   int i;
+   tpmif_tx_request_t* tx;
+   if(dev =3D=3D NULL) {
+      return;
+   }
+   TPMFRONT_LOG("Shutting down tpmfront\n");
+   /* disconnect */
+   if(dev->state =3D=3D XenbusStateConnected) {
+      dev->state =3D XenbusStateClosing;
+      //FIXME: Transaction for this?
+      /* Tell backend we are closing */
+      if((err =3D xenbus_printf(XBT_NIL, dev->nodename, "state", "%u",
(unsigned int) dev->state))) {
+     free(err);
+      }
+
+      /* Clean up xenstore entries */
+      snprintf(path, 512, "%s/event-channel", dev->nodename);
+      if((err =3D xenbus_rm(XBT_NIL, path))) {
+     free(err);
+      }
+      snprintf(path, 512, "%s/ring-ref", dev->nodename);
+      if((err =3D xenbus_rm(XBT_NIL, path))) {
+     free(err);
+      }
+
+      /* Tell backend we are closed */
+      dev->state =3D XenbusStateClosed;
+      if((err =3D xenbus_printf(XBT_NIL, dev->nodename, "state", "%u",
(unsigned int) dev->state))) {
+     TPMFRONT_ERR("Unable to write to %s, error was %s", dev->nodename,
err);
+     free(err);
+      }
+
+      /* Wait for the backend to close and unmap shared pages, ignore
any errors */
+      wait_for_backend_state_changed(dev, XenbusStateClosed);
+
+      /* Cleanup any shared pages */
+      if(dev->pages) {
+     for(i =3D 0; i < TPMIF_TX_RING_SIZE; ++i) {
+        if(dev->pages[i]) {
+           tx =3D &dev->tx->ring[i].req;
+           if(tx->ref !=3D 0) {
+          gnttab_end_access(tx->ref);
+           }
+           free_page(dev->pages[i]);
+        }
+     }
+     free(dev->pages);
+      }
+
+      /* Close event channel and unmap shared page */
+      mask_evtchn(dev->evtchn);
+      unbind_evtchn(dev->evtchn);
+      gnttab_end_access(dev->ring_ref);
+
+      free_page(dev->tx);
+
+   }
+
+   /* Cleanup memory usage */
+   if(dev->respbuf) {
+      free(dev->respbuf);
+   }
+   if(dev->bepath) {
+      free(dev->bepath);
+   }
+   if(dev->nodename) {
+      free(dev->nodename);
+   }
+   free(dev);
+}
+
+int tpmfront_send(struct tpmfront_dev* dev, const uint8_t* msg, size_t
length)
+{
+   int i;
+   tpmif_tx_request_t* tx =3D NULL;
+   /* Error Checking */
+   if(dev =3D=3D NULL || dev->state !=3D XenbusStateConnected) {
+      TPMFRONT_ERR("Tried to send message through disconnected
frontend\n");
+      return -1;
+   }
+
+#ifdef TPMFRONT_PRINT_DEBUG
+   TPMFRONT_DEBUG("Sending Msg to backend size=3D%u", (unsigned int) len=
gth);
+   for(i =3D 0; i < length; ++i) {
+      if(!(i % 30)) {
+     TPMFRONT_DEBUG_MORE("\n");
+      }
+      TPMFRONT_DEBUG_MORE("%02X ", msg[i]);
+   }
+   TPMFRONT_DEBUG_MORE("\n");
+#endif
+
+   /* Copy to shared pages now */
+   for(i =3D 0; length > 0 && i < TPMIF_TX_RING_SIZE; ++i) {
+      /* Share the page */
+      tx =3D &dev->tx->ring[i].req;
+      tx->unused =3D 0;
+      tx->addr =3D virt_to_mach(dev->pages[i]);
+      tx->ref =3D gnttab_grant_access(dev->bedomid,
virt_to_mfn(dev->pages[i]), 0);
+      /* Copy the bits to the page */
+      tx->size =3D length > PAGE_SIZE ? PAGE_SIZE : length;
+      memcpy(dev->pages[i], &msg[i * PAGE_SIZE], tx->size);
+
+      /* Update counters */
+      length -=3D tx->size;
+   }
+   dev->waiting =3D 1;
+   dev->resplen =3D 0;
+#ifdef HAVE_LIBC
+   if(dev->fd >=3D 0) {
+      files[dev->fd].read =3D 0;
+      files[dev->fd].tpmfront.respgot =3D 0;
+      files[dev->fd].tpmfront.offset =3D 0;
+   }
+#endif
+   notify_remote_via_evtchn(dev->evtchn);
+   return 0;
+}
+int tpmfront_recv(struct tpmfront_dev* dev, uint8_t** msg, size_t *lengt=
h)
+{
+   tpmif_tx_request_t* tx;
+   int i;
+   if(dev =3D=3D NULL || dev->state !=3D XenbusStateConnected) {
+      TPMFRONT_ERR("Tried to receive message from disconnected
frontend\n");
+      return -1;
+   }
+   /*Wait for the response */
+   wait_event(dev->waitq, (!dev->waiting));
+
+   /* Initialize */
+   *msg =3D NULL;
+   *length =3D 0;
+
+   /* special case, just quit */
+   tx =3D &dev->tx->ring[0].req;
+   if(tx->size =3D=3D 0 ) {
+       goto quit;
+   }
+   /* Get the total size */
+   tx =3D &dev->tx->ring[0].req;
+   for(i =3D 0; i < TPMIF_TX_RING_SIZE && tx->size > 0; ++i) {
+      tx =3D &dev->tx->ring[i].req;
+      *length +=3D tx->size;
+   }
+   /* Alloc the buffer */
+   if(dev->respbuf) {
+      free(dev->respbuf);
+   }
+   *msg =3D dev->respbuf =3D malloc(*length);
+   dev->resplen =3D *length;
+   /* Copy the bits */
+   tx =3D &dev->tx->ring[0].req;
+   for(i =3D 0; i < TPMIF_TX_RING_SIZE && tx->size > 0; ++i) {
+      tx =3D &dev->tx->ring[i].req;
+      memcpy(&(*msg)[i * PAGE_SIZE], dev->pages[i], tx->size);
+      gnttab_end_access(tx->ref);
+      tx->ref =3D 0;
+   }
+#ifdef TPMFRONT_PRINT_DEBUG
+   TPMFRONT_DEBUG("Received response from backend size=3D%u", (unsigned
int) *length);
+   for(i =3D 0; i < *length; ++i) {
+      if(!(i % 30)) {
+     TPMFRONT_DEBUG_MORE("\n");
+      }
+      TPMFRONT_DEBUG_MORE("%02X ", (*msg)[i]);
+   }
+   TPMFRONT_DEBUG_MORE("\n");
+#endif
+#ifdef HAVE_LIBC
+   if(dev->fd >=3D 0) {
+      files[dev->fd].tpmfront.respgot =3D 1;
+   }
+#endif
+quit:
+   return 0;
+}
+
+int tpmfront_cmd(struct tpmfront_dev* dev, uint8_t* req, size_t reqlen,
uint8_t** resp, size_t* resplen)
+{
+   int rc;
+   if((rc =3D tpmfront_send(dev, req, reqlen))) {
+      return rc;
+   }
+   if((rc =3D tpmfront_recv(dev, resp, resplen))) {
+      return rc;
+   }
+
+   return 0;
+}
+
+#ifdef HAVE_LIBC
+#include <errno.h>
+int tpmfront_open(struct tpmfront_dev* dev)
+{
+   /* Silently prevent multiple opens */
+   if(dev->fd !=3D -1) {
+      return dev->fd;
+   }
+
+   dev->fd =3D alloc_fd(FTYPE_TPMFRONT);
+   printk("tpmfront_open(%s) -> %d\n", dev->nodename, dev->fd);
+   files[dev->fd].tpmfront.dev =3D dev;
+   files[dev->fd].tpmfront.offset =3D 0;
+   files[dev->fd].tpmfront.respgot =3D 0;
+   return dev->fd;
+}
+
+int tpmfront_posix_write(int fd, const uint8_t* buf, size_t count)
+{
+   int rc;
+   struct tpmfront_dev* dev;
+   dev =3D files[fd].tpmfront.dev;
+
+   if(count =3D=3D 0) {
+      return 0;
+   }
+
+   /* Return an error if we are already processing a command */
+   if(dev->waiting) {
+      errno =3D EINPROGRESS;
+      return -1;
+   }
+   /* Send the command now */
+   if((rc =3D tpmfront_send(dev, buf, count)) !=3D 0) {
+      errno =3D EIO;
+      return -1;
+   }
+   return count;
+}
+
+int tpmfront_posix_read(int fd, uint8_t* buf, size_t count)
+{
+   int rc;
+   uint8_t* dummybuf;
+   size_t dummysz;
+   struct tpmfront_dev* dev;
+
+   dev =3D files[fd].tpmfront.dev;
+
+   if(count =3D=3D 0) {
+      return 0;
+   }
+
+   /* get the response if we haven't already */
+   if(files[dev->fd].tpmfront.respgot =3D=3D 0) {
+      if ((rc =3D tpmfront_recv(dev, &dummybuf, &dummysz)) !=3D 0) {
+     errno =3D EIO;
+     return -1;
+      }
+   }
+
+   /* handle EOF case */
+   if(files[dev->fd].tpmfront.offset >=3D dev->resplen) {
+      return 0;
+   }
+
+   /* Compute the number of bytes and do the copy operation */
+   if((rc =3D min(count, dev->resplen - files[dev->fd].tpmfront.offset))=

!=3D 0) {
+      memcpy(buf, dev->respbuf + files[dev->fd].tpmfront.offset, rc);
+      files[dev->fd].tpmfront.offset +=3D rc;
+   }
+
+   return rc;
+}
+
+int tpmfront_posix_fstat(int fd, struct stat* buf)
+{
+   uint8_t* dummybuf;
+   size_t dummysz;
+   int rc;
+   struct tpmfront_dev* dev =3D files[fd].tpmfront.dev;
+
+   /* If we have a response waiting, then read it now from the backend
+    * so we can get its length*/
+   if(dev->waiting || (files[dev->fd].read =3D=3D 1 &&
!files[dev->fd].tpmfront.respgot)) {
+      if ((rc =3D tpmfront_recv(dev, &dummybuf, &dummysz)) !=3D 0) {
+     errno =3D EIO;
+     return -1;
+      }
+   }
+
+   buf->st_mode =3D O_RDWR;
+   buf->st_uid =3D 0;
+   buf->st_gid =3D 0;
+   buf->st_size =3D dev->resplen;
+   buf->st_atime =3D buf->st_mtime =3D buf->st_ctime =3D time(NULL);
+
+   return 0;
+}
+
+
+#endif





--------------ms050205000800020200090704
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIDyjCC
A8YwggMvoAMCAQICBD/xyf0wDQYJKoZIhvcNAQEFBQAwLzELMAkGA1UEBhMCVVMxDzANBgNV
BAoTBkpIVUFQTDEPMA0GA1UECxMGQklTRENBMB4XDTEwMDYxMTE4MjIwNloXDTEzMDYxMTE4
NTIwNlowZjELMAkGA1UEBhMCVVMxDzANBgNVBAoTBkpIVUFQTDEPMA0GA1UECxMGUGVvcGxl
MTUwFgYDVQQLEw9WUE5Hcm91cC1CSVNEQ0EwGwYDVQQDExRNYXR0aGV3IEUgRmlvcmF2YW50
ZTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAnpbwVSP6o1Nb5lcW7dd3yTo9iBJdi7qz
4nANOMFPK7JOy5npKN1iiousl28U/scUJES55gPwAWYJK3uVyQAsA4adgDKi5DoD1UHDQEwp
bY7iHLJeq0NPr4BqYNqnCFPbE6HC8zSJrr4qKn+gVUQT39SIFqdiIPJwZL8FYTRQ/zsCAwEA
AaOCAbYwggGyMAsGA1UdDwQEAwIHgDArBgNVHRAEJDAigA8yMDEwMDYxMTE4MjIwNlqBDzIw
MTIwNzE3MjI1MjA2WjAbBg0rBgEEAbMlCwMBAQEBBAoWCGZpb3JhbWUxMBsGDSsGAQQBsyUL
AwEBAQIEChIIMDAxMDQyNjEwWAYJYIZIAYb6ax4BBEsMSVRoZSBwcml2YXRlIGtleSBjb3Jy
ZXNwb25kaW5nIHRvIHRoaXMgY2VydGlmaWNhdGUgbWF5IGhhdmUgYmVlbiBleHBvcnRlZC4w
KAYDVR0RBCEwH4EdTWF0dGhldy5GaW9yYXZhbnRlQGpodWFwbC5lZHUwUgYDVR0fBEswSTBH
oEWgQ6RBMD8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJU0RD
QTEOMAwGA1UEAxMFQ1JMNTYwHwYDVR0jBBgwFoAUCDUpmxH52EU2CyWmF2EJMB1yqeswHQYD
VR0OBBYEFO6LYxg6r9wHZ+zdQtBHn1dZ/YTNMAkGA1UdEwQCMAAwGQYJKoZIhvZ9B0EABAww
ChsEVjcuMQMCBLAwDQYJKoZIhvcNAQEFBQADgYEAJO9HQh4YNChVLzuZqK5ARJARD8JoujGZ
fdo75quvg2jXFQe2sEjvLnxJZgm/pv8fdZakq48CWwjYHKuvIp7sDjTEsQfo+y7SpN/N2NvJ
WU5SqfK1VgYtNLRRoGJUB5Q1aZ+Dg95g3kqpyfpUMISJL8IKVLtJVfN4fggFVUYZ9wwxggGr
MIIBpwIBATA3MC8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJ
U0RDQQIEP/HJ/TAJBgUrDgMCGgUAoIHLMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ
KoZIhvcNAQkFMQ8XDTEyMDkxOTE0NTQ1NFowIwYJKoZIhvcNAQkEMRYEFILynlCFCVaA4ZOX
R2Nzw11fOh3JMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAK
BggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI
KoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEgYAjZhsYws+P6eRbgLEYB3HzX0A48iOqoJ5/
5RssUUEmsHhFURcAQf+EdWivn5v6J6g894cPTH9uMudRe6Zhybmy09y1boF4cHgORxIQxoSC
HKd+vF02A2ond2UN82cpUek2Sz7xG/zhBYmoKrAEiDDFtlcS9esKanOp5CjKttHGJgAAAAAA
AA==
--------------ms050205000800020200090704--


--===============0895186449901109436==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============0895186449901109436==--


From xen-devel-bounces@lists.xen.org Wed Sep 19 14:57:06 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Sep 2012 14:57:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TELhl-0000J7-S9; Wed, 19 Sep 2012 14:56:45 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <matthew.fioravante@jhuapl.edu>) id 1TELhj-0000Iu-Oi
	for xen-devel@lists.xensource.com; Wed, 19 Sep 2012 14:56:44 +0000
Received: from [85.158.143.35:23626] by server-2.bemta-4.messagelabs.com id
	97/CF-06610-A2DD9505; Wed, 19 Sep 2012 14:56:42 +0000
X-Env-Sender: matthew.fioravante@jhuapl.edu
X-Msg-Ref: server-2.tower-21.messagelabs.com!1348066589!7997320!1
X-Originating-IP: [128.244.251.36]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG,
	UNPARSEABLE_RELAY
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32454 invoked from network); 19 Sep 2012 14:56:31 -0000
Received: from pilot.jhuapl.edu (HELO jhuapl.edu) (128.244.251.36)
	by server-2.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 19 Sep 2012 14:56:31 -0000
Received: from ([128.244.207.89])
	by pilot.jhuapl.edu with ESMTP with TLS id 63GHCH1.153214994;
	Wed, 19 Sep 2012 10:56:10 -0400
Message-ID: <5059DCBE.7060202@jhuapl.edu>
Date: Wed, 19 Sep 2012 10:54:54 -0400
From: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120827 Thunderbird/15.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <50579F53.4070302@jhuapl.edu>
	<1348056465.14977.96.camel@zakaz.uk.xensource.com>
In-Reply-To: <1348056465.14977.96.camel@zakaz.uk.xensource.com>
X-Enigmail-Version: 1.4.4
Cc: Samuel Thibault <samuel.thibault@ens-lyon.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH mini-os enhancements for vtpm 8/8] Add 3 tpm
 drivers to mini-os
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0895186449901109436=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a cryptographically signed message in MIME format.

--===============0895186449901109436==
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms050205000800020200090704"

This is a cryptographically signed message in MIME format.

--------------ms050205000800020200090704
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 09/19/2012 08:07 AM, Ian Campbell wrote:
> On Mon, 2012-09-17 at 23:08 +0100, Matthew Fioravante wrote:
>> This patch adds 3 new drivers to mini-os.
>>
>> tpmfront - paravirtualized tpm frontend driver
>> tpmback - paravirtualized tpm backend driver
>> tpm_tis - hardware tpm driver
>>
>> Unfortunately these drivers were derived from GPL licensed linux kerne=
l
>> drivers so they must carry the GPL license.
> I notice that you have used GPL v3 here, while the original Linux
> versions of these files (I looked at 3.6-rc3)both say:
>  * 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, version 2 of the
>  * License.
> i.e. doesn't contain the "or later" wording which would allow an upgrad=
e
> to v3. Did all of the copyright holders agree to this relicensing?
Thank you, that was a really good catch. I meant to use GPL v2 but put
in the wrong text.
>>  However, since mini-os now
>> supports conditional compilation, hopefully these drivers can be
>> included into the xen tree and conditionally removed from non-gpl
>> projects. By default they are disabled in the makefile.
> Are these drivers useful for other stub domains generally or are they
> only really useful in the vtpm stub domains? IOW could this GPL code be=

> made part of the application instead?
>
> This would allow better segregation between the BSD bits of mini-os and=

> GPL bits.
tpmfront would be useful for any mini-os domain that wants a vtpm.
tpm_tis would be useful for any mini-os domain that wants access to the
physical tpm.

tpmback is only useful for the vtpm system itself. Unless someone else
wants to implement a new vtpm domain, I don't see why they would want to
use this driver.
>> Signed off by: Matthew Fioravante matthew.fioravante@jhuapl.edu
> Can you confirm that you have the right to submit his code under this
> license, since you are not listed in the copyright I guess that would b=
e
> clause B of the DCO:
> http://wiki.xen.org/wiki/Submitting_Xen_Patches#Signing_off_a_patch
I have the rights to submit these patches. The copyright clause and GPL
v2 license were approved by our internal review process and that of our
government sponsor.
>
>> diff --git a/extras/mini-os/include/tpm_tis.h
>> b/extras/mini-os/include/tpm_tis.h
>> --- /dev/null
>> +++ b/extras/mini-os/include/tpm_tis.h
>> @@ -0,0 +1,63 @@
>> +/*
>> + * Copyright (c) 2010-2012 United States Government, as represented b=
y
>> + * the Secretary of Defense.  All rights reserved.
>> + *
>> + * This driver is free software: you can redistribute it and/or modif=
y
>> + * it under the terms of the GNU General Public License as published =
by
>> + * the Free Software Foundation, either version 3 of the License, or
>> + * (at your option) any later version.
>> + *
>> + * This driver is distributed in the hope that it will be useful,
>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
>> + * GNU General Public License for more details.
>> + *
>> + * You should have received a copy of the GNU General Public License
>> + * along with this program.  If not, see <http://www.gnu.org/licenses=
/>.
>> + *
>> + * Based upon the files:
>> + *  drivers/char/tpm/tpm_tis.c
>> + *  drivers/char/tpm/tpm.c
>> + * from the Linux kernel, which are Copyright (C) 2006 IBM Corporatio=
n
>> + */
>
Heres an updated patch with v2

Signed of by Matthew Fioravante matthew.fioravante@jhuapl.edu

diff --git a/extras/mini-os/Makefile b/extras/mini-os/Makefile
--- a/extras/mini-os/Makefile
+++ b/extras/mini-os/Makefile
@@ -22,6 +22,9 @@ CONFIG_QEMU_XS_ARGS ?=3D n
 CONFIG_TEST ?=3D n
 CONFIG_PCIFRONT ?=3D n
 CONFIG_BLKFRONT ?=3D y
+CONFIG_TPMFRONT ?=3D n
+CONFIG_TPM_TIS ?=3D n
+CONFIG_TPMBACK ?=3D n
 CONFIG_NETFRONT ?=3D y
 CONFIG_FBFRONT ?=3D y
 CONFIG_KBDFRONT ?=3D y
@@ -36,6 +39,9 @@ flags-$(CONFIG_SPARSE_BSS) +=3D -DCONFIG_SPARSE_BSS
 flags-$(CONFIG_QEMU_XS_ARGS) +=3D -DCONFIG_QEMU_XS_ARGS
 flags-$(CONFIG_PCIFRONT) +=3D -DCONFIG_PCIFRONT
 flags-$(CONFIG_BLKFRONT) +=3D -DCONFIG_BLKFRONT
+flags-$(CONFIG_TPMFRONT) +=3D -DCONFIG_TPMFRONT
+flags-$(CONFIG_TPM_TIS) +=3D -DCONFIG_TPM_TIS
+flags-$(CONFIG_TPMBACK) +=3D -DCONFIG_TPMBACK
 flags-$(CONFIG_NETFRONT) +=3D -DCONFIG_NETFRONT
 flags-$(CONFIG_KBDFRONT) +=3D -DCONFIG_KBDFRONT
 flags-$(CONFIG_FBFRONT) +=3D -DCONFIG_FBFRONT
@@ -67,6 +73,9 @@ TARGET :=3D mini-os
 SUBDIRS :=3D lib xenbus console
=20
 src-$(CONFIG_BLKFRONT) +=3D blkfront.c
+src-$(CONFIG_TPMFRONT) +=3D tpmfront.c
+src-$(CONFIG_TPM_TIS) +=3D tpm_tis.c
+src-$(CONFIG_TPMBACK) +=3D tpmback.c
 src-y +=3D daytime.c
 src-y +=3D events.c
 src-$(CONFIG_FBFRONT) +=3D fbfront.c
diff --git a/extras/mini-os/include/lib.h b/extras/mini-os/include/lib.h
--- a/extras/mini-os/include/lib.h
+++ b/extras/mini-os/include/lib.h
@@ -142,6 +142,8 @@ enum fd_type {
     FTYPE_FB,
     FTYPE_MEM,
     FTYPE_SAVEFILE,
+    FTYPE_TPMFRONT,
+    FTYPE_TPM_TIS,
 };
=20
 LIST_HEAD(evtchn_port_list, evtchn_port_info);
@@ -185,6 +187,20 @@ extern struct file {
     struct {
         struct consfront_dev *dev;
     } cons;
+#ifdef CONFIG_TPMFRONT
+    struct {
+       struct tpmfront_dev *dev;
+       int respgot;
+       off_t offset;
+    } tpmfront;
+#endif
+#ifdef CONFIG_TPM_TIS
+    struct {
+       struct tpm_chip *dev;
+       int respgot;
+       off_t offset;
+    } tpm_tis;
+#endif
 #ifdef CONFIG_XENBUS
         struct {
             /* To each xenbus FD is associated a queue of watch events
for this
diff --git a/extras/mini-os/include/tpm_tis.h
b/extras/mini-os/include/tpm_tis.h
--- /dev/null
+++ b/extras/mini-os/include/tpm_tis.h
@@ -0,0 +1,74 @@
+/*
+ * Copyright (c) 2010-2012 United States Government, as represented by
+ * the Secretary of Defense.  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 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 MERCHANTABILI=
TY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT
SHALL THE
+ * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHE=
R
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISI=
NG
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
DEALINGS
+ * IN THE SOFTWARE.
+ *
+ * Based upon the files:
+ *  drivers/char/tpm/tpm_tis.c
+ *  drivers/char/tpm/tpm.c
+ * from the Linux kernel, which are Copyright (C) 2006 IBM Corporation
+ */
+#ifndef TPM_TIS_H
+#define TPM_TIS_H
+
+#include <mini-os/types.h>
+#include <mini-os/byteorder.h>
+
+#define TPM_TIS_EN_LOCL0 1
+#define TPM_TIS_EN_LOCL1 (1 << 1)
+#define TPM_TIS_EN_LOCL2 (1 << 2)
+#define TPM_TIS_EN_LOCL3 (1 << 3)
+#define TPM_TIS_EN_LOCL4 (1 << 4)
+#define TPM_TIS_EN_LOCLALL (TPM_TIS_EN_LOCL0 | TPM_TIS_EN_LOCL1  |
TPM_TIS_EN_LOCL2 | TPM_TIS_EN_LOCL3 | TPM_TIS_EN_LOCL4)
+#define TPM_TIS_LOCL_INT_TO_FLAG(x) (1 << x)
+#define TPM_BASEADDR 0xFED40000
+#define TPM_PROBE_IRQ 0xFFFF
+
+struct tpm_chip;
+
+struct tpm_chip* init_tpm_tis(unsigned long baseaddr, int localities,
unsigned int irq);
+void shutdown_tpm_tis(struct tpm_chip* tpm);
+
+int tpm_tis_request_locality(struct tpm_chip* tpm, int locality);
+int tpm_tis_cmd(struct tpm_chip* tpm, uint8_t* req, size_t reqlen,
uint8_t** resp, size_t* resplen);
+
+#ifdef HAVE_LIBC
+#include <sys/stat.h>
+#include <fcntl.h>
+/* POSIX IO functions:
+ * use tpm_tis_open() to get a file descriptor to the tpm device
+ * use write() on the fd to send a command to the backend. You must
+ * include the entire command in a single call to write().
+ * use read() on the fd to read the response. You can use
+ * fstat() to get the size of the response and lseek() to seek on it.
+ */
+int tpm_tis_open(struct tpm_chip* tpm);
+int tpm_tis_posix_read(int fd, uint8_t* buf, size_t count);
+int tpm_tis_posix_write(int fd, const uint8_t* buf, size_t count);
+int tpm_tis_posix_fstat(int fd, struct stat* buf);
+#endif
+
+#endif
diff --git a/extras/mini-os/include/tpmback.h
b/extras/mini-os/include/tpmback.h
--- /dev/null
+++ b/extras/mini-os/include/tpmback.h
@@ -0,0 +1,106 @@
+/*
+ * Copyright (c) 2010-2012 United States Government, as represented by
+ * the Secretary of Defense.  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 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 MERCHANTABILI=
TY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT
SHALL THE
+ * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHE=
R
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISI=
NG
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
DEALINGS
+ * IN THE SOFTWARE.
+ *
+ * Based upon the files:
+ *  drivers/xen/tpmbk.c
+ * from the Linux kernel, which are Copyright (C) 2006 IBM Corporation
+ */
+#include <xen/io/tpmif.h>
+#include <xen/io/xenbus.h>
+#include <mini-os/types.h>
+#include <xen/xen.h>
+#ifndef TPMBACK_H
+#define TPMBACK_H
+
+struct tpmcmd {
+   domid_t domid;        /* Domid of the frontend */
+   unsigned int handle;    /* Handle of the frontend */
+   char* uuid;            /* uuid of the tpm interface - allocated
internally, dont free it */
+
+   unsigned int req_len;        /* Size of the command in buf - set by
tpmback driver */
+   uint8_t* req;            /* tpm command bits, allocated by driver,
DON'T FREE IT */
+   unsigned int resp_len;    /* Size of the outgoing command,
+                   you set this before passing the cmd object to
tpmback_resp */
+   uint8_t* resp;        /* Buffer for response - YOU MUST ALLOCATE IT,
YOU MUST ALSO FREE IT */
+};
+typedef struct tpmcmd tpmcmd_t;
+
+/* Initialize the tpm backend driver
+ * @exclusive_domname - This is NULL terminated list of vtpm uuid
strings. If this list
+ *             is non-empty, then only frontend domains with vtpm
uuid's matching
+ *             entries in this list will be allowed to connect.
+ *             Other connections will be immediatly closed.
+ *             Set this argument to NULL to allow any vtpm to connect.
+ */
+void init_tpmback(char** exclusive_uuids);
+/* Shutdown tpm backend driver */
+void shutdown_tpmback(void);
+
+/* Blocks until a tpm command is sent from any front end.
+ * Returns a pointer to the tpm command to handle.
+ * Do not try to free this pointer or the req buffer
+ * This function will return NULL if the tpm backend driver
+ * is shutdown or any other error occurs */
+tpmcmd_t* tpmback_req_any(void);
+
+/* Blocks until a tpm command from the frontend at domid/handle
+ * is sent.
+ * Returns NULL if domid/handle is not connected, tpmback is
+ * shutdown or shutting down, or if there is an error
+ */
+tpmcmd_t* tpmback_req(domid_t domid, unsigned int handle);
+
+/* Send the response to the tpm command back to the frontend
+ * This function will free the tpmcmd object, but you must free the resp=

+ * buffer yourself */
+void tpmback_resp(tpmcmd_t* tpmcmd);
+
+/* Waits for the first frontend to connect and then sets domid and
handle appropriately.
+ * If one or more frontends are already connected, this will set domid
and handle to one
+ * of them arbitrarily. The main use for this function is to wait until
a single
+ * frontend connection has occured.
+ * returns 0 on success, non-zero on failure */
+int tpmback_wait_for_frontend_connect(domid_t *domid, unsigned int
*handle);
+
+/* returns the number of frontends connected */
+int tpmback_num_frontends(void);
+
+/* Returns the uuid of the specified frontend, NULL on error */
+char* tpmback_get_uuid(domid_t domid, unsigned int handle);
+
+/* Specify a function to call when a new tpm device connects */
+void tpmback_set_open_callback(void (*cb)(domid_t, unsigned int));
+
+/* Specify a function to call when a tpm device disconnects */
+void tpmback_set_close_callback(void (*cb)(domid_t, unsigned int));
+
+//Not Implemented
+void tpmback_set_suspend_callback(void (*cb)(domid_t, unsigned int));
+void tpmback_set_resume_callback(void (*cb)(domid_t, unsigned int));
+
+#endif
diff --git a/extras/mini-os/include/tpmfront.h
b/extras/mini-os/include/tpmfront.h
--- /dev/null
+++ b/extras/mini-os/include/tpmfront.h
@@ -0,0 +1,105 @@
+/*
+ * Copyright (c) 2010-2012 United States Government, as represented by
+ * the Secretary of Defense.  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 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 MERCHANTABILI=
TY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT
SHALL THE
+ * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHE=
R
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISI=
NG
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
DEALINGS
+ * IN THE SOFTWARE.
+ *
+ * Based upon the files:
+ *  drivers/char/tpm/tpm_vtpm.c
+ *  drivers/char/tpm/tpm_xen.c
+ * from the Linux kernel, which are Copyright (C) 2006 IBM Corporation
+ */
+#ifndef TPMFRONT_H
+#define TPMFRONT_H
+
+#include <mini-os/types.h>
+#include <mini-os/os.h>
+#include <mini-os/events.h>
+#include <mini-os/wait.h>
+#include <xen/xen.h>
+#include <xen/io/xenbus.h>
+#include <xen/io/tpmif.h>
+
+struct tpmfront_dev {
+   grant_ref_t ring_ref;
+   evtchn_port_t evtchn;
+
+   tpmif_tx_interface_t* tx;
+
+   void** pages;
+
+   domid_t bedomid;
+   char* nodename;
+   char* bepath;
+
+   XenbusState state;
+
+   uint8_t waiting;
+   struct wait_queue_head waitq;
+
+   uint8_t* respbuf;
+   size_t resplen;
+
+#ifdef HAVE_LIBC
+   int fd;
+#endif
+
+};
+
+
+/*Initialize frontend */
+struct tpmfront_dev* init_tpmfront(const char* nodename);
+/*Shutdown frontend */
+void shutdown_tpmfront(struct tpmfront_dev* dev);
+
+/* Send a tpm command to the backend and wait for the response
+ *
+ * @dev - frontend device
+ * @req - request buffer
+ * @reqlen - length of request buffer
+ * @resp - *resp will be set to internal response buffer, don't free
it! Value is undefined on error
+ * @resplen - *resplen will be set to the length of the response. Value
is undefined on error
+ *
+ * returns 0 on success, non zero on failure.
+ * */
+int tpmfront_cmd(struct tpmfront_dev* dev, uint8_t* req, size_t reqlen,
uint8_t** resp, size_t* resplen);
+
+#ifdef HAVE_LIBC
+#include <sys/stat.h>
+/* POSIX IO functions:
+ * use tpmfront_open() to get a file descriptor to the tpm device
+ * use write() on the fd to send a command to the backend. You must
+ * include the entire command in a single call to write().
+ * use read() on the fd to read the response. You can use
+ * fstat() to get the size of the response and lseek() to seek on it.
+ */
+int tpmfront_open(struct tpmfront_dev* dev);
+int tpmfront_posix_read(int fd, uint8_t* buf, size_t count);
+int tpmfront_posix_write(int fd, const uint8_t* buf, size_t count);
+int tpmfront_posix_fstat(int fd, struct stat* buf);
+#endif
+
+
+#endif
diff --git a/extras/mini-os/lib/sys.c b/extras/mini-os/lib/sys.c
--- a/extras/mini-os/lib/sys.c
+++ b/extras/mini-os/lib/sys.c
@@ -27,6 +27,8 @@
 #include <netfront.h>
 #include <blkfront.h>
 #include <fbfront.h>
+#include <tpmfront.h>
+#include <tpm_tis.h>
 #include <xenbus.h>
 #include <xenstore.h>
=20
@@ -294,6 +296,16 @@ int read(int fd, void *buf, size_t nbytes)
         return blkfront_posix_read(fd, buf, nbytes);
         }
 #endif
+#ifdef CONFIG_TPMFRONT
+        case FTYPE_TPMFRONT: {
+        return tpmfront_posix_read(fd, buf, nbytes);
+        }
+#endif
+#ifdef CONFIG_TPM_TIS
+        case FTYPE_TPM_TIS: {
+        return tpm_tis_posix_read(fd, buf, nbytes);
+        }
+#endif
     default:
         break;
     }
@@ -330,6 +342,14 @@ int write(int fd, const void *buf, size_t nbytes)
     case FTYPE_BLK:
         return blkfront_posix_write(fd, buf, nbytes);
 #endif
+#ifdef CONFIG_TPMFRONT
+    case FTYPE_TPMFRONT:
+        return tpmfront_posix_write(fd, buf, nbytes);
+#endif
+#ifdef CONFIG_TPM_TIS
+    case FTYPE_TPM_TIS:
+        return tpm_tis_posix_write(fd, buf, nbytes);
+#endif
     default:
         break;
     }
@@ -341,8 +361,16 @@ int write(int fd, const void *buf, size_t nbytes)
 off_t lseek(int fd, off_t offset, int whence)
 {
     switch(files[fd].type) {
+#if defined(CONFIG_BLKFRONT) || defined(CONFIG_TPMFRONT) ||
defined(CONFIG_TPM_TIS)
 #ifdef CONFIG_BLKFRONT
        case FTYPE_BLK:
+#endif
+#ifdef CONFIG_TPMFRNT
+       case FTYPE_TPMFRONT:
+#endif
+#ifdef CONFIG_TPM_TIS
+       case FTYPE_TPM_TIS:
+#endif
       switch (whence) {
          case SEEK_SET:
         files[fd].file.offset =3D offset;
@@ -420,6 +448,18 @@ int close(int fd)
         files[fd].type =3D FTYPE_NONE;
         return 0;
 #endif
+#ifdef CONFIG_TPMFRONT
+    case FTYPE_TPMFRONT:
+            shutdown_tpmfront(files[fd].tpmfront.dev);
+        files[fd].type =3D FTYPE_NONE;
+        return 0;
+#endif
+#ifdef CONFIG_TPM_TIS
+    case FTYPE_TPM_TIS:
+            shutdown_tpm_tis(files[fd].tpm_tis.dev);
+        files[fd].type =3D FTYPE_NONE;
+        return 0;
+#endif
 #ifdef CONFIG_KBDFRONT
     case FTYPE_KBD:
             shutdown_kbdfront(files[fd].kbd.dev);
@@ -489,6 +529,14 @@ int fstat(int fd, struct stat *buf)
     case FTYPE_BLK:
        return blkfront_posix_fstat(fd, buf);
 #endif
+#ifdef CONFIG_TPMFRONT
+    case FTYPE_TPMFRONT:
+       return tpmfront_posix_fstat(fd, buf);
+#endif
+#ifdef CONFIG_TPM_TIS
+    case FTYPE_TPM_TIS:
+       return tpm_tis_posix_fstat(fd, buf);
+#endif
     default:
         break;
     }
diff --git a/extras/mini-os/tpm_tis.c b/extras/mini-os/tpm_tis.c
--- /dev/null
+++ b/extras/mini-os/tpm_tis.c
@@ -0,0 +1,1355 @@
+/*
+ * Copyright (c) 2010-2012 United States Government, as represented by
+ * the Secretary of Defense.  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 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 MERCHANTABILI=
TY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT
SHALL THE
+ * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHE=
R
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISI=
NG
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
DEALINGS
+ * IN THE SOFTWARE.
+ *
+ * Based upon the files:
+ *  drivers/char/tpm/tpm_tis.c
+ *  drivers/char/tpm/tpm.c
+ * from the Linux kernel, which are Copyright (C) 2006 IBM Corporation
+ */
+#include <mini-os/ioremap.h>
+#include <mini-os/iorw.h>
+#include <mini-os/tpm_tis.h>
+#include <mini-os/os.h>
+#include <mini-os/sched.h>
+#include <mini-os/byteorder.h>
+#include <mini-os/events.h>
+#include <mini-os/wait.h>
+#include <mini-os/xmalloc.h>
+#include <errno.h>
+#include <stdbool.h>
+
+#ifndef min
+    #define min( a, b ) ( ((a) < (b)) ? (a) : (b) )
+#endif
+
+#define TPM_HEADER_SIZE 10
+
+#define TPM_BUFSIZE 2048
+
+struct tpm_input_header {
+        uint16_t  tag;
+        uint32_t  length;
+        uint32_t  ordinal;
+}__attribute__((packed));
+
+struct tpm_output_header {
+        uint16_t  tag;
+        uint32_t  length;
+        uint32_t  return_code;
+}__attribute__((packed));
+
+struct  stclear_flags_t {
+        uint16_t  tag;
+        uint8_t      deactivated;
+        uint8_t      disableForceClear;
+        uint8_t      physicalPresence;
+        uint8_t      physicalPresenceLock;
+        uint8_t      bGlobalLock;
+}__attribute__((packed));
+
+struct  tpm_version_t {
+        uint8_t      Major;
+        uint8_t      Minor;
+        uint8_t      revMajor;
+        uint8_t      revMinor;
+}__attribute__((packed));
+
+struct  tpm_version_1_2_t {
+        uint16_t  tag;
+        uint8_t      Major;
+        uint8_t      Minor;
+        uint8_t      revMajor;
+        uint8_t      revMinor;
+}__attribute__((packed));
+
+struct  timeout_t {
+        uint32_t  a;
+        uint32_t  b;
+        uint32_t  c;
+        uint32_t  d;
+}__attribute__((packed));
+
+struct duration_t {
+        uint32_t  tpm_short;
+        uint32_t  tpm_medium;
+        uint32_t  tpm_long;
+}__attribute__((packed));
+
+struct permanent_flags_t {
+        uint16_t  tag;
+        uint8_t      disable;
+        uint8_t      ownership;
+        uint8_t      deactivated;
+        uint8_t      readPubek;
+        uint8_t      disableOwnerClear;
+        uint8_t      allowMaintenance;
+        uint8_t      physicalPresenceLifetimeLock;
+        uint8_t      physicalPresenceHWEnable;
+        uint8_t      physicalPresenceCMDEnable;
+        uint8_t      CEKPUsed;
+        uint8_t      TPMpost;
+        uint8_t      TPMpostLock;
+        uint8_t      FIPS;
+        uint8_t      operator;
+        uint8_t      enableRevokeEK;
+        uint8_t      nvLocked;
+        uint8_t      readSRKPub;
+        uint8_t      tpmEstablished;
+        uint8_t      maintenanceDone;
+        uint8_t      disableFullDALogicInfo;
+}__attribute__((packed));
+
+typedef union {
+        struct  permanent_flags_t perm_flags;
+        struct  stclear_flags_t stclear_flags;
+        bool    owned;
+        uint32_t  num_pcrs;
+        struct  tpm_version_t   tpm_version;
+        struct  tpm_version_1_2_t tpm_version_1_2;
+        uint32_t  manufacturer_id;
+        struct timeout_t  timeout;
+        struct duration_t duration;
+} cap_t;
+
+struct  tpm_getcap_params_in {
+        uint32_t  cap;
+        uint32_t  subcap_size;
+        uint32_t  subcap;
+}__attribute__((packed));
+
+struct  tpm_getcap_params_out {
+        uint32_t  cap_size;
+        cap_t   cap;
+}__attribute__((packed));
+
+struct  tpm_readpubek_params_out {
+        uint8_t      algorithm[4];
+        uint8_t      encscheme[2];
+        uint8_t      sigscheme[2];
+        uint32_t  paramsize;
+        uint8_t      parameters[12]; /*assuming RSA*/
+        uint32_t  keysize;
+        uint8_t      modulus[256];
+        uint8_t      checksum[20];
+}__attribute__((packed));
+
+typedef union {
+        struct  tpm_input_header in;
+        struct  tpm_output_header out;
+} tpm_cmd_header;
+
+#define TPM_DIGEST_SIZE 20
+struct tpm_pcrread_out {
+        uint8_t      pcr_result[TPM_DIGEST_SIZE];
+}__attribute__((packed));
+
+struct tpm_pcrread_in {
+        uint32_t  pcr_idx;
+}__attribute__((packed));
+
+struct tpm_pcrextend_in {
+        uint32_t  pcr_idx;
+        uint8_t      hash[TPM_DIGEST_SIZE];
+}__attribute__((packed));
+
+typedef union {
+        struct  tpm_getcap_params_out getcap_out;
+        struct  tpm_readpubek_params_out readpubek_out;
+        uint8_t      readpubek_out_buffer[sizeof(struct
tpm_readpubek_params_out)];
+        struct  tpm_getcap_params_in getcap_in;
+        struct  tpm_pcrread_in  pcrread_in;
+        struct  tpm_pcrread_out pcrread_out;
+        struct  tpm_pcrextend_in pcrextend_in;
+} tpm_cmd_params;
+
+struct tpm_cmd_t {
+        tpm_cmd_header  header;
+        tpm_cmd_params  params;
+}__attribute__((packed));
+
+
+enum tpm_duration {
+   TPM_SHORT =3D 0,
+   TPM_MEDIUM =3D 1,
+   TPM_LONG =3D 2,
+   TPM_UNDEFINED,
+};
+
+#define TPM_MAX_ORDINAL 243
+#define TPM_MAX_PROTECTED_ORDINAL 12
+#define TPM_PROTECTED_ORDINAL_MASK 0xFF
+
+extern const uint8_t
tpm_protected_ordinal_duration[TPM_MAX_PROTECTED_ORDINAL];
+extern const uint8_t tpm_ordinal_duration[TPM_MAX_ORDINAL];
+
+#define TPM_DIGEST_SIZE 20
+#define TPM_ERROR_SIZE 10
+#define TPM_RET_CODE_IDX 6
+
+/* tpm_capabilities */
+#define TPM_CAP_FLAG cpu_to_be32(4)
+#define TPM_CAP_PROP cpu_to_be32(5)
+#define CAP_VERSION_1_1 cpu_to_be32(0x06)
+#define CAP_VERSION_1_2 cpu_to_be32(0x1A)
+
+/* tpm_sub_capabilities */
+#define TPM_CAP_PROP_PCR cpu_to_be32(0x101)
+#define TPM_CAP_PROP_MANUFACTURER cpu_to_be32(0x103)
+#define TPM_CAP_FLAG_PERM cpu_to_be32(0x108)
+#define TPM_CAP_FLAG_VOL cpu_to_be32(0x109)
+#define TPM_CAP_PROP_OWNER cpu_to_be32(0x111)
+#define TPM_CAP_PROP_TIS_TIMEOUT cpu_to_be32(0x115)
+#define TPM_CAP_PROP_TIS_DURATION cpu_to_be32(0x120)
+
+
+#define TPM_INTERNAL_RESULT_SIZE 200
+#define TPM_TAG_RQU_COMMAND cpu_to_be16(193)
+#define TPM_ORD_GET_CAP cpu_to_be32(101)
+
+extern const struct tpm_input_header tpm_getcap_header;
+
+
+
+const uint8_t tpm_protected_ordinal_duration[TPM_MAX_PROTECTED_ORDINAL] =
=3D {
+   TPM_UNDEFINED,          /* 0 */
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,          /* 5 */
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_SHORT,              /* 10 */
+   TPM_SHORT,
+};
+
+const uint8_t tpm_ordinal_duration[TPM_MAX_ORDINAL] =3D {
+   TPM_UNDEFINED,          /* 0 */
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,          /* 5 */
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_SHORT,              /* 10 */
+   TPM_SHORT,
+   TPM_MEDIUM,
+   TPM_LONG,
+   TPM_LONG,
+   TPM_MEDIUM,             /* 15 */
+   TPM_SHORT,
+   TPM_SHORT,
+   TPM_MEDIUM,
+   TPM_LONG,
+   TPM_SHORT,              /* 20 */
+   TPM_SHORT,
+   TPM_MEDIUM,
+   TPM_MEDIUM,
+   TPM_MEDIUM,
+   TPM_SHORT,              /* 25 */
+   TPM_SHORT,
+   TPM_MEDIUM,
+   TPM_SHORT,
+   TPM_SHORT,
+   TPM_MEDIUM,             /* 30 */
+   TPM_LONG,
+   TPM_MEDIUM,
+   TPM_SHORT,
+   TPM_SHORT,
+   TPM_SHORT,              /* 35 */
+   TPM_MEDIUM,
+   TPM_MEDIUM,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_MEDIUM,             /* 40 */
+   TPM_LONG,
+   TPM_MEDIUM,
+   TPM_SHORT,
+   TPM_SHORT,
+   TPM_SHORT,              /* 45 */
+   TPM_SHORT,
+   TPM_SHORT,
+   TPM_SHORT,
+   TPM_LONG,
+   TPM_MEDIUM,             /* 50 */
+   TPM_MEDIUM,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,          /* 55 */
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_MEDIUM,             /* 60 */
+   TPM_MEDIUM,
+   TPM_MEDIUM,
+   TPM_SHORT,
+   TPM_SHORT,
+   TPM_MEDIUM,             /* 65 */
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_SHORT,              /* 70 */
+   TPM_SHORT,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,          /* 75 */
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_LONG,               /* 80 */
+   TPM_UNDEFINED,
+   TPM_MEDIUM,
+   TPM_LONG,
+   TPM_SHORT,
+   TPM_UNDEFINED,          /* 85 */
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_SHORT,              /* 90 */
+   TPM_SHORT,
+   TPM_SHORT,
+   TPM_SHORT,
+   TPM_SHORT,
+   TPM_UNDEFINED,          /* 95 */
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_MEDIUM,             /* 100 */
+   TPM_SHORT,
+   TPM_SHORT,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,          /* 105 */
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_SHORT,              /* 110 */
+   TPM_SHORT,
+   TPM_SHORT,
+   TPM_SHORT,
+   TPM_SHORT,
+   TPM_SHORT,              /* 115 */
+   TPM_SHORT,
+   TPM_SHORT,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_LONG,               /* 120 */
+   TPM_LONG,
+   TPM_MEDIUM,
+   TPM_UNDEFINED,
+   TPM_SHORT,
+   TPM_SHORT,              /* 125 */
+   TPM_SHORT,
+   TPM_LONG,
+   TPM_SHORT,
+   TPM_SHORT,
+   TPM_SHORT,              /* 130 */
+   TPM_MEDIUM,
+   TPM_UNDEFINED,
+   TPM_SHORT,
+   TPM_MEDIUM,
+   TPM_UNDEFINED,          /* 135 */
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_SHORT,              /* 140 */
+   TPM_SHORT,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,          /* 145 */
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_SHORT,              /* 150 */
+   TPM_MEDIUM,
+   TPM_MEDIUM,
+   TPM_SHORT,
+   TPM_SHORT,
+   TPM_UNDEFINED,          /* 155 */
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_SHORT,              /* 160 */
+   TPM_SHORT,
+   TPM_SHORT,
+   TPM_SHORT,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,          /* 165 */
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_LONG,               /* 170 */
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,          /* 175 */
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_MEDIUM,             /* 180 */
+   TPM_SHORT,
+   TPM_MEDIUM,
+   TPM_MEDIUM,
+   TPM_MEDIUM,
+   TPM_MEDIUM,             /* 185 */
+   TPM_SHORT,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,          /* 190 */
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,          /* 195 */
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_SHORT,              /* 200 */
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_SHORT,
+   TPM_SHORT,              /* 205 */
+   TPM_SHORT,
+   TPM_SHORT,
+   TPM_SHORT,
+   TPM_SHORT,
+   TPM_MEDIUM,             /* 210 */
+   TPM_UNDEFINED,
+   TPM_MEDIUM,
+   TPM_MEDIUM,
+   TPM_MEDIUM,
+   TPM_UNDEFINED,          /* 215 */
+   TPM_MEDIUM,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_SHORT,
+   TPM_SHORT,              /* 220 */
+   TPM_SHORT,
+   TPM_SHORT,
+   TPM_SHORT,
+   TPM_SHORT,
+   TPM_UNDEFINED,          /* 225 */
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_SHORT,              /* 230 */
+   TPM_LONG,
+   TPM_MEDIUM,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,          /* 235 */
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_SHORT,              /* 240 */
+   TPM_UNDEFINED,
+   TPM_MEDIUM,
+};
+
+const struct tpm_input_header tpm_getcap_header =3D {
+        .tag =3D TPM_TAG_RQU_COMMAND,
+        .length =3D cpu_to_be32(22),
+        .ordinal =3D TPM_ORD_GET_CAP
+};
+
+
+enum tis_access {
+   TPM_ACCESS_VALID =3D 0x80,
+   TPM_ACCESS_ACTIVE_LOCALITY =3D 0x20,    /* (R) */
+   TPM_ACCESS_RELINQUISH_LOCALITY =3D 0x20,/* (W) */
+   TPM_ACCESS_REQUEST_PENDING =3D 0x04,    /* (W) */
+   TPM_ACCESS_REQUEST_USE =3D 0x02,    /* (W) */
+};
+
+enum tis_status {
+   TPM_STS_VALID =3D 0x80,        /* (R) */
+   TPM_STS_COMMAND_READY =3D 0x40,    /* (R) */
+   TPM_STS_DATA_AVAIL =3D 0x10,        /* (R) */
+   TPM_STS_DATA_EXPECT =3D 0x08,        /* (R) */
+   TPM_STS_GO =3D 0x20,            /* (W) */
+};
+
+enum tis_int_flags {
+   TPM_GLOBAL_INT_ENABLE =3D 0x80000000,
+   TPM_INTF_BURST_COUNT_STATIC =3D 0x100,
+   TPM_INTF_CMD_READY_INT =3D 0x080,
+   TPM_INTF_INT_EDGE_FALLING =3D 0x040,
+   TPM_INTF_INT_EDGE_RISING =3D 0x020,
+   TPM_INTF_INT_LEVEL_LOW =3D 0x010,
+   TPM_INTF_INT_LEVEL_HIGH =3D 0x008,
+   TPM_INTF_LOCALITY_CHANGE_INT =3D 0x004,
+   TPM_INTF_STS_VALID_INT =3D 0x002,
+   TPM_INTF_DATA_AVAIL_INT =3D 0x001,
+};
+
+enum tis_defaults {
+   TIS_MEM_BASE =3D 0xFED40000,
+   TIS_MEM_LEN  =3D 0x5000,
+   TIS_SHORT_TIMEOUT =3D 750, /*ms*/
+   TIS_LONG_TIMEOUT =3D 2000, /*2 sec */
+};
+
+#define TPM_TIMEOUT 5
+
+#define TPM_ACCESS(t, l)                   (((uint8_t*)t->pages[l]) +
0x0000)
+#define TPM_INT_ENABLE(t, l)             =20
((uint32_t*)(((uint8_t*)t->pages[l]) + 0x0008))
+#define TPM_INT_VECTOR(t, l)               (((uint8_t*)t->pages[l]) +
0x000C)
+#define TPM_INT_STATUS(t, l)               (((uint8_t*)t->pages[l]) +
0x0010)
+#define TPM_INTF_CAPS(t, l)              =20
((uint32_t*)(((uint8_t*)t->pages[l]) + 0x0014))
+#define TPM_STS(t, l)                    =20
((uint8_t*)(((uint8_t*)t->pages[l]) + 0x0018))
+#define TPM_DATA_FIFO(t, l)                (((uint8_t*)t->pages[l]) +
0x0024)
+
+#define TPM_DID_VID(t, l)                =20
((uint32_t*)(((uint8_t*)t->pages[l]) + 0x0F00))
+#define TPM_RID(t, l)                      (((uint8_t*)t->pages[l]) +
0x0F04)
+
+struct tpm_chip {
+   int enabled_localities;
+   int locality;
+   unsigned long baseaddr;
+   uint8_t* pages[5];
+   int did, vid, rid;
+
+   uint8_t data_buffer[TPM_BUFSIZE];
+   int data_len;
+
+   s_time_t timeout_a, timeout_b, timeout_c, timeout_d;
+   s_time_t duration[3];
+
+#ifdef HAVE_LIBC
+   int fd;
+#endif
+
+   unsigned int irq;
+   struct wait_queue_head read_queue;
+   struct wait_queue_head int_queue;
+};
+
+
+static void __init_tpm_chip(struct tpm_chip* tpm) {
+   tpm->enabled_localities =3D TPM_TIS_EN_LOCLALL;
+   tpm->locality =3D -1;
+   tpm->baseaddr =3D 0;
+   tpm->pages[0] =3D tpm->pages[1] =3D tpm->pages[2] =3D tpm->pages[3] =3D=

tpm->pages[4] =3D NULL;
+   tpm->vid =3D 0;
+   tpm->did =3D 0;
+   tpm->irq =3D 0;
+   init_waitqueue_head(&tpm->read_queue);
+   init_waitqueue_head(&tpm->int_queue);
+
+   tpm->data_len =3D -1;
+
+#ifdef HAVE_LIBC
+   tpm->fd =3D -1;
+#endif
+}
+
+/*
+ * Returns max number of nsecs to wait
+ */
+s_time_t tpm_calc_ordinal_duration(struct tpm_chip *chip,
+      uint32_t ordinal)
+{
+   int duration_idx =3D TPM_UNDEFINED;
+   s_time_t duration =3D 0;
+
+   if (ordinal < TPM_MAX_ORDINAL)
+      duration_idx =3D tpm_ordinal_duration[ordinal];
+   else if ((ordinal & TPM_PROTECTED_ORDINAL_MASK) <
+     TPM_MAX_PROTECTED_ORDINAL)
+      duration_idx =3D
+     tpm_protected_ordinal_duration[ordinal &
+     TPM_PROTECTED_ORDINAL_MASK];
+
+   if (duration_idx !=3D TPM_UNDEFINED) {
+      duration =3D chip->duration[duration_idx];
+   }
+
+   if (duration <=3D 0) {
+      return SECONDS(120);
+   }
+   else
+   {
+      return duration;
+   }
+}
+
+
+static int locality_enabled(struct tpm_chip* tpm, int l) {
+   return tpm->enabled_localities & (1 << l);
+}
+
+static int check_locality(struct tpm_chip* tpm, int l) {
+   if(locality_enabled(tpm, l) && (ioread8(TPM_ACCESS(tpm, l)) &
+        (TPM_ACCESS_ACTIVE_LOCALITY | TPM_ACCESS_VALID)) =3D=3D
+     (TPM_ACCESS_ACTIVE_LOCALITY | TPM_ACCESS_VALID)) {
+      return l;
+   }
+   return -1;
+}
+
+void release_locality(struct tpm_chip* tpm, int l, int force)
+{
+   if (locality_enabled(tpm, l) && (force || (ioread8(TPM_ACCESS(tpm, l)=
) &
+           (TPM_ACCESS_REQUEST_PENDING | TPM_ACCESS_VALID)) =3D=3D
+        (TPM_ACCESS_REQUEST_PENDING | TPM_ACCESS_VALID))) {
+      iowrite8(TPM_ACCESS(tpm, l), TPM_ACCESS_RELINQUISH_LOCALITY);
+   }
+}
+
+int tpm_tis_request_locality(struct tpm_chip* tpm, int l) {
+
+   s_time_t stop;
+   /*Make sure locality is valid */
+   if(!locality_enabled(tpm, l)) {
+      printk("tpm_tis_change_locality() Tried to change to locality %d,
but it is disabled or invalid!\n", l);
+      return -1;
+   }
+   /* Check if we already have the current locality */
+   if(check_locality(tpm, l) >=3D 0) {
+      return tpm->locality =3D l;
+   }
+   /* Set the new locality*/
+   iowrite8(TPM_ACCESS(tpm, l), TPM_ACCESS_REQUEST_USE);
+
+   if(tpm->irq) {
+      /* Wait for interrupt */
+      wait_event_deadline(tpm->int_queue, (check_locality(tpm, l) >=3D
0), NOW() + tpm->timeout_a);
+
+      /* FIXME: Handle timeout event, should return error in that case *=
/
+      return l;
+   } else {
+      /* Wait for burstcount */
+      stop =3D NOW() + tpm->timeout_a;
+      do {
+     if(check_locality(tpm, l) >=3D 0) {
+        return tpm->locality =3D l;
+     }
+     msleep(TPM_TIMEOUT);
+      } while(NOW() < stop);
+   }
+
+   printk("REQ LOCALITY FAILURE\n");
+   return -1;
+}
+
+static uint8_t tpm_tis_status(struct tpm_chip* tpm) {
+   return ioread8(TPM_STS(tpm, tpm->locality));
+}
+
+/* This causes the current command to be aborted */
+static void tpm_tis_ready(struct tpm_chip* tpm) {
+   iowrite8(TPM_STS(tpm, tpm->locality), TPM_STS_COMMAND_READY);
+}
+#define tpm_tis_cancel_cmd(v) tpm_tis_ready(v)
+
+static int get_burstcount(struct tpm_chip* tpm) {
+   s_time_t stop;
+   int burstcnt;
+
+   stop =3D NOW() + tpm->timeout_d;
+   do {
+      burstcnt =3D ioread8((TPM_STS(tpm, tpm->locality) + 1));
+      burstcnt +=3D ioread8(TPM_STS(tpm, tpm->locality) + 2) << 8;
+
+      if (burstcnt) {
+     return burstcnt;
+      }
+      msleep(TPM_TIMEOUT);
+   } while(NOW() < stop);
+   return -EBUSY;
+}
+
+static int wait_for_stat(struct tpm_chip* tpm, uint8_t mask,
+      unsigned long timeout, struct wait_queue_head* queue) {
+   s_time_t stop;
+   uint8_t status;
+
+   status =3D tpm_tis_status(tpm);
+   if((status & mask) =3D=3D mask) {
+      return 0;
+   }
+
+   if(tpm->irq) {
+      wait_event_deadline(*queue, ((tpm_tis_status(tpm) & mask) =3D=3D
mask), timeout);
+      /* FIXME: Check for timeout and return -ETIME */
+      return 0;
+   } else {
+      stop =3D NOW() + timeout;
+      do {
+     msleep(TPM_TIMEOUT);
+     status =3D tpm_tis_status(tpm);
+     if((status & mask) =3D=3D mask)
+        return 0;
+      } while( NOW() < stop);
+   }
+   return -ETIME;
+}
+
+static int recv_data(struct tpm_chip* tpm, uint8_t* buf, size_t count) {=

+   int size =3D 0;
+   int burstcnt;
+   while( size < count &&
+     wait_for_stat(tpm,
+        TPM_STS_DATA_AVAIL | TPM_STS_VALID,
+        tpm->timeout_c,
+        &tpm->read_queue)
+     =3D=3D 0) {
+      burstcnt =3D get_burstcount(tpm);
+      for(; burstcnt > 0 && size < count; --burstcnt)
+      {
+     buf[size++] =3D ioread8(TPM_DATA_FIFO(tpm, tpm->locality));
+      }
+   }
+   return size;
+}
+
+int tpm_tis_recv(struct tpm_chip* tpm, uint8_t* buf, size_t count) {
+   int size =3D 0;
+   int expected, status;
+
+   if (count < TPM_HEADER_SIZE) {
+      size =3D -EIO;
+      goto out;
+   }
+
+   /* read first 10 bytes, including tag, paramsize, and result */
+   if((size =3D
+        recv_data(tpm, buf, TPM_HEADER_SIZE)) < TPM_HEADER_SIZE) {
+      printk("Error reading tpm cmd header\n");
+      goto out;
+   }
+
+   expected =3D be32_to_cpu(*((uint32_t*)(buf + 2)));
+   if(expected > count) {
+      size =3D -EIO;
+      goto out;
+   }
+
+   if((size +=3D recv_data(tpm, & buf[TPM_HEADER_SIZE],
+           expected - TPM_HEADER_SIZE)) < expected) {
+      printk("Unable to read rest of tpm command size=3D%d
expected=3D%d\n", size, expected);
+      size =3D -ETIME;
+      goto out;
+   }
+
+   wait_for_stat(tpm, TPM_STS_VALID, tpm->timeout_c, &tpm->int_queue);
+   status =3D tpm_tis_status(tpm);
+   if(status & TPM_STS_DATA_AVAIL) {
+      printk("Error: left over data\n");
+      size =3D -EIO;
+      goto out;
+   }
+
+out:
+   tpm_tis_ready(tpm);
+   release_locality(tpm, tpm->locality, 0);
+   return size;
+}
+int tpm_tis_send(struct tpm_chip* tpm, uint8_t* buf, size_t len) {
+   int rc;
+   int status, burstcnt =3D 0;
+   int count =3D 0;
+   uint32_t ordinal;
+
+   if(tpm_tis_request_locality(tpm, tpm->locality) < 0) {
+      return -EBUSY;
+   }
+
+   status =3D tpm_tis_status(tpm);
+   if((status & TPM_STS_COMMAND_READY) =3D=3D 0) {
+      tpm_tis_ready(tpm);
+      if(wait_for_stat(tpm, TPM_STS_COMMAND_READY, tpm->timeout_b,
&tpm->int_queue) < 0) {
+     rc =3D -ETIME;
+     goto out_err;
+      }
+   }
+
+   while(count < len - 1) {
+      burstcnt =3D get_burstcount(tpm);
+      for(;burstcnt > 0 && count < len -1; --burstcnt) {
+     iowrite8(TPM_DATA_FIFO(tpm, tpm->locality), buf[count++]);
+      }
+
+      wait_for_stat(tpm, TPM_STS_VALID, tpm->timeout_c, &tpm->int_queue)=
;
+      status =3D tpm_tis_status(tpm);
+      if((status & TPM_STS_DATA_EXPECT) =3D=3D 0) {
+     rc =3D -EIO;
+     goto out_err;
+      }
+   }
+
+   /*Write last byte*/
+   iowrite8(TPM_DATA_FIFO(tpm, tpm->locality), buf[count]);
+   wait_for_stat(tpm, TPM_STS_VALID, tpm->timeout_c, &tpm->read_queue);
+   status =3D tpm_tis_status(tpm);
+   if((status & TPM_STS_DATA_EXPECT) !=3D 0) {
+      rc =3D -EIO;
+      goto out_err;
+   }
+
+   /*go and do it*/
+   iowrite8(TPM_STS(tpm, tpm->locality), TPM_STS_GO);
+
+   if(tpm->irq) {
+      /*Wait for interrupt */
+      ordinal =3D be32_to_cpu(*(buf + 6));
+      if(wait_for_stat(tpm,
+           TPM_STS_DATA_AVAIL | TPM_STS_VALID,
+           tpm_calc_ordinal_duration(tpm, ordinal),
+           &tpm->read_queue) < 0) {
+     rc =3D -ETIME;
+     goto out_err;
+      }
+   }
+#ifdef HAVE_LIBC
+   if(tpm->fd >=3D 0) {
+      files[tpm->fd].read =3D 0;
+      files[tpm->fd].tpm_tis.respgot =3D 0;
+      files[tpm->fd].tpm_tis.offset =3D 0;
+   }
+#endif
+   return len;
+
+out_err:
+   tpm_tis_ready(tpm);
+   release_locality(tpm, tpm->locality, 0);
+   return rc;
+}
+
+static void tpm_tis_irq_handler(evtchn_port_t port, struct pt_regs
*regs, void* data)
+{
+   struct tpm_chip* tpm =3D data;
+   uint32_t interrupt;
+   int i;
+
+   interrupt =3D ioread32(TPM_INT_STATUS(tpm, tpm->locality));
+   if(interrupt =3D=3D 0) {
+      return;
+   }
+
+   if(interrupt & TPM_INTF_DATA_AVAIL_INT) {
+      wake_up(&tpm->read_queue);
+   }
+   if(interrupt & TPM_INTF_LOCALITY_CHANGE_INT) {
+      for(i =3D 0; i < 5; ++i) {
+     if(check_locality(tpm, i) >=3D 0) {
+        break;
+     }
+      }
+   }
+   if(interrupt & (TPM_INTF_LOCALITY_CHANGE_INT | TPM_INTF_STS_VALID_INT=
 |
+        TPM_INTF_CMD_READY_INT)) {
+      wake_up(&tpm->int_queue);
+   }
+
+   /* Clear interrupts handled with TPM_EOI */
+   iowrite32(TPM_INT_STATUS(tpm, tpm->locality), interrupt);
+   ioread32(TPM_INT_STATUS(tpm, tpm->locality));
+   return;
+}
+
+/*
+ * Internal kernel interface to transmit TPM commands
+ */
+static ssize_t tpm_transmit(struct tpm_chip *chip, const uint8_t *buf,
+      size_t bufsiz)
+{
+   ssize_t rc;
+   uint32_t count, ordinal;
+   s_time_t stop;
+
+   count =3D be32_to_cpu(*((uint32_t *) (buf + 2)));
+   ordinal =3D be32_to_cpu(*((uint32_t *) (buf + 6)));
+   if (count =3D=3D 0)
+      return -ENODATA;
+   if (count > bufsiz) {
+      printk("Error: invalid count value %x %zx \n", count, bufsiz);
+      return -E2BIG;
+   }
+
+   //down(&chip->tpm_mutex);
+
+   if ((rc =3D tpm_tis_send(chip, (uint8_t *) buf, count)) < 0) {
+      printk("tpm_transmit: tpm_send: error %zd\n", rc);
+      goto out;
+   }
+
+   if (chip->irq)
+      goto out_recv;
+
+   stop =3D NOW() + tpm_calc_ordinal_duration(chip, ordinal);
+   do {
+      uint8_t status =3D tpm_tis_status(chip);
+      if ((status & (TPM_STS_DATA_AVAIL | TPM_STS_VALID)) =3D=3D
+        (TPM_STS_DATA_AVAIL | TPM_STS_VALID))
+     goto out_recv;
+
+      if ((status =3D=3D TPM_STS_COMMAND_READY)) {
+     printk("TPM Error: Operation Canceled\n");
+     rc =3D -ECANCELED;
+     goto out;
+      }
+
+      msleep(TPM_TIMEOUT);    /* CHECK */
+      rmb();
+   } while (NOW() < stop);
+
+   /* Cancel the command */
+   tpm_tis_cancel_cmd(chip);
+   printk("TPM Operation Timed out\n");
+   rc =3D -ETIME;
+   goto out;
+
+out_recv:
+   if((rc =3D tpm_tis_recv(chip, (uint8_t *) buf, bufsiz)) < 0) {
+      printk("tpm_transmit: tpm_recv: error %d\n", rc);
+   }
+out:
+   //up(&chip->tpm_mutex);
+   return rc;
+}
+
+static ssize_t transmit_cmd(struct tpm_chip *chip, struct tpm_cmd_t *cmd=
,
+                            int len, const char *desc)
+{
+        int err;
+
+        len =3D tpm_transmit(chip,(uint8_t *) cmd, len);
+        if (len <  0)
+                return len;
+        if (len =3D=3D TPM_ERROR_SIZE) {
+                err =3D be32_to_cpu(cmd->header.out.return_code);
+                printk("A TPM error (%d) occurred %s\n", err, desc);
+                return err;
+        }
+        return 0;
+}
+
+void tpm_get_timeouts(struct tpm_chip *chip)
+{
+   struct tpm_cmd_t tpm_cmd;
+   struct timeout_t *timeout_cap;
+   struct duration_t *duration_cap;
+   ssize_t rc;
+   uint32_t timeout;
+
+   tpm_cmd.header.in =3D tpm_getcap_header;
+   tpm_cmd.params.getcap_in.cap =3D TPM_CAP_PROP;
+   tpm_cmd.params.getcap_in.subcap_size =3D cpu_to_be32(4);
+   tpm_cmd.params.getcap_in.subcap =3D TPM_CAP_PROP_TIS_TIMEOUT;
+
+   if((rc =3D transmit_cmd(chip, &tpm_cmd, TPM_INTERNAL_RESULT_SIZE,
+     "attempting to determine the timeouts")) !=3D 0) {
+      printk("transmit failed %d\n", rc);
+      goto duration;
+   }
+
+   if (be32_to_cpu(tpm_cmd.params.getcap_out.cap_size)
+     !=3D 4 * sizeof(uint32_t)) {
+      printk("Out len check failure %lu \n",
be32_to_cpu(tpm_cmd.header.out.length));
+      goto duration;
+   }
+
+   timeout_cap =3D &tpm_cmd.params.getcap_out.cap.timeout;
+   /* Don't overwrite default if value is 0 */
+   timeout =3D be32_to_cpu(timeout_cap->a);
+   if (timeout)
+      chip->timeout_a =3D MICROSECS(timeout); /*Convert to msec */
+   timeout =3D be32_to_cpu(timeout_cap->b);
+   if (timeout)
+      chip->timeout_b =3D MICROSECS(timeout); /*Convert to msec */
+   timeout =3D be32_to_cpu(timeout_cap->c);
+   if (timeout)
+      chip->timeout_c =3D MICROSECS(timeout); /*Convert to msec */
+   timeout =3D be32_to_cpu(timeout_cap->d);
+   if (timeout)
+      chip->timeout_d =3D MICROSECS(timeout); /*Convert to msec */
+
+duration:
+   tpm_cmd.header.in =3D tpm_getcap_header;
+   tpm_cmd.params.getcap_in.cap =3D TPM_CAP_PROP;
+   tpm_cmd.params.getcap_in.subcap_size =3D cpu_to_be32(4);
+   tpm_cmd.params.getcap_in.subcap =3D TPM_CAP_PROP_TIS_DURATION;
+
+   if((rc =3D transmit_cmd(chip, &tpm_cmd, TPM_INTERNAL_RESULT_SIZE,
+     "attempting to determine the durations")) < 0) {
+      return;
+   }
+
+   if (be32_to_cpu(tpm_cmd.params.getcap_out.cap_size)
+     !=3D 3 * sizeof(uint32_t)) {
+      return;
+   }
+        duration_cap =3D &tpm_cmd.params.getcap_out.cap.duration;
+        chip->duration[TPM_SHORT] =3D be32_to_cpu(duration_cap->tpm_shor=
t);
+        /* The Broadcom BCM0102 chipset in a Dell Latitude D820 gets
the above
+         * value wrong and apparently reports msecs rather than usecs.
So we
+         * fix up the resulting too-small TPM_SHORT value to make
things work.
+         */
+        if (chip->duration[TPM_SHORT] < 10) {
+       chip->duration[TPM_SHORT] =3D MILLISECS(chip->duration[TPM_SHORT]=
);
+    } else {
+       chip->duration[TPM_SHORT] =3D MICROSECS(chip->duration[TPM_SHORT]=
);
+    }
+
+        chip->duration[TPM_MEDIUM] =3D
MICROSECS(be32_to_cpu(duration_cap->tpm_medium));
+        chip->duration[TPM_LONG] =3D
MICROSECS(be32_to_cpu(duration_cap->tpm_long));
+}
+
+
+
+void tpm_continue_selftest(struct tpm_chip* chip) {
+   uint8_t data[] =3D {
+      0, 193,                 /* TPM_TAG_RQU_COMMAND */
+      0, 0, 0, 10,            /* length */
+      0, 0, 0, 83,            /* TPM_ORD_GetCapability */
+   };
+
+   tpm_transmit(chip, data, sizeof(data));
+}
+
+ssize_t tpm_getcap(struct tpm_chip *chip, uint32_t subcap_id, cap_t *cap=
,
+                   const char *desc)
+{
+        struct tpm_cmd_t tpm_cmd;
+        int rc;
+
+        tpm_cmd.header.in =3D tpm_getcap_header;
+        if (subcap_id =3D=3D CAP_VERSION_1_1 || subcap_id =3D=3D CAP_VER=
SION_1_2) {
+                tpm_cmd.params.getcap_in.cap =3D subcap_id;
+                /*subcap field not necessary */
+                tpm_cmd.params.getcap_in.subcap_size =3D cpu_to_be32(0);=

+                tpm_cmd.header.in.length -=3D cpu_to_be32(sizeof(uint32_=
t));
+        } else {
+                if (subcap_id =3D=3D TPM_CAP_FLAG_PERM ||
+                    subcap_id =3D=3D TPM_CAP_FLAG_VOL)
+                        tpm_cmd.params.getcap_in.cap =3D TPM_CAP_FLAG;
+                else
+                        tpm_cmd.params.getcap_in.cap =3D TPM_CAP_PROP;
+                tpm_cmd.params.getcap_in.subcap_size =3D cpu_to_be32(4);=

+                tpm_cmd.params.getcap_in.subcap =3D subcap_id;
+        }
+        rc =3D transmit_cmd(chip, &tpm_cmd, TPM_INTERNAL_RESULT_SIZE, de=
sc);
+        if (!rc)
+                *cap =3D tpm_cmd.params.getcap_out.cap;
+        return rc;
+}
+
+
+struct tpm_chip* init_tpm_tis(unsigned long baseaddr, int localities,
unsigned int irq)
+{
+   int i;
+   unsigned long addr;
+   struct tpm_chip* tpm =3D NULL;
+   uint32_t didvid;
+   uint32_t intfcaps;
+   uint32_t intmask;
+
+   printk("=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Init TPM TIS Driver =3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D\n");
+
+   /*Sanity check the localities input */
+   if(localities & ~TPM_TIS_EN_LOCLALL) {
+      printk("init_tpm_tis() Invalid locality specification! %X\n",
localities);
+      goto abort_egress;
+   }
+
+   printk("IOMEM Machine Base Address: %lX\n", baseaddr);
+
+   /* Create the tpm data structure */
+   tpm =3D malloc(sizeof(struct tpm_chip));
+   __init_tpm_chip(tpm);
+
+   /* Set the enabled localities - if 0 we leave default as all enabled =
*/
+   if(localities !=3D 0) {
+      tpm->enabled_localities =3D localities;
+   }
+   printk("Enabled Localities: ");
+   for(i =3D 0; i < 5; ++i) {
+      if(locality_enabled(tpm, i)) {
+     printk("%d ", i);
+      }
+   }
+   printk("\n");
+
+   /* Set the base machine address */
+   tpm->baseaddr =3D baseaddr;
+
+   /* Set default timeouts */
+   tpm->timeout_a =3D MILLISECS(TIS_SHORT_TIMEOUT);
+   tpm->timeout_b =3D MILLISECS(TIS_LONG_TIMEOUT);
+   tpm->timeout_c =3D MILLISECS(TIS_SHORT_TIMEOUT);
+   tpm->timeout_d =3D MILLISECS(TIS_SHORT_TIMEOUT);
+
+   /*Map the mmio pages */
+   addr =3D tpm->baseaddr;
+   for(i =3D 0; i < 5; ++i) {
+      if(locality_enabled(tpm, i)) {
+     /* Map the page in now */
+     if((tpm->pages[i] =3D ioremap_nocache(addr, PAGE_SIZE)) =3D=3D NULL=
) {
+        printk("Unable to map iomem page a address %p\n", addr);
+        goto abort_egress;
+     }
+
+     /* Set default locality to the first enabled one */
+     if (tpm->locality < 0) {
+        if(tpm_tis_request_locality(tpm, i) < 0) {
+           printk("Unable to request locality %d??\n", i);
+           goto abort_egress;
+        }
+     }
+      }
+      addr +=3D PAGE_SIZE;
+   }
+
+
+   /* Get the vendor and device ids */
+   didvid =3D ioread32(TPM_DID_VID(tpm, tpm->locality));
+   tpm->did =3D didvid >> 16;
+   tpm->vid =3D didvid & 0xFFFF;
+
+
+   /* Get the revision id */
+   tpm->rid =3D ioread8(TPM_RID(tpm, tpm->locality));
+
+   printk("1.2 TPM (device-id=3D0x%X vendor-id =3D %X rev-id =3D %X)\n",=

tpm->did, tpm->vid, tpm->rid);
+
+   intfcaps =3D ioread32(TPM_INTF_CAPS(tpm, tpm->locality));
+   printk("TPM interface capabilities (0x%x):\n", intfcaps);
+   if (intfcaps & TPM_INTF_BURST_COUNT_STATIC)
+      printk("\tBurst Count Static\n");
+   if (intfcaps & TPM_INTF_CMD_READY_INT)
+      printk("\tCommand Ready Int Support\n");
+   if (intfcaps & TPM_INTF_INT_EDGE_FALLING)
+      printk("\tInterrupt Edge Falling\n");
+   if (intfcaps & TPM_INTF_INT_EDGE_RISING)
+      printk("\tInterrupt Edge Rising\n");
+   if (intfcaps & TPM_INTF_INT_LEVEL_LOW)
+      printk("\tInterrupt Level Low\n");
+   if (intfcaps & TPM_INTF_INT_LEVEL_HIGH)
+      printk("\tInterrupt Level High\n");
+   if (intfcaps & TPM_INTF_LOCALITY_CHANGE_INT)
+      printk("\tLocality Change Int Support\n");
+   if (intfcaps & TPM_INTF_STS_VALID_INT)
+      printk("\tSts Valid Int Support\n");
+   if (intfcaps & TPM_INTF_DATA_AVAIL_INT)
+      printk("\tData Avail Int Support\n");
+
+   /*Interupt setup */
+   intmask =3D ioread32(TPM_INT_ENABLE(tpm, tpm->locality));
+
+   intmask |=3D TPM_INTF_CMD_READY_INT
+      | TPM_INTF_LOCALITY_CHANGE_INT | TPM_INTF_DATA_AVAIL_INT
+      | TPM_INTF_STS_VALID_INT;
+
+   iowrite32(TPM_INT_ENABLE(tpm, tpm->locality), intmask);
+
+   /*If interupts are enabled, handle it */
+   if(irq) {
+      if(irq !=3D TPM_PROBE_IRQ) {
+     tpm->irq =3D irq;
+      } else {
+     /*FIXME add irq probing feature later */
+     printk("IRQ probing not implemented\n");
+      }
+   }
+
+   if(tpm->irq) {
+      iowrite8(TPM_INT_VECTOR(tpm, tpm->locality), tpm->irq);
+
+      if(bind_pirq(tpm->irq, 1, tpm_tis_irq_handler, tpm) !=3D 0) {
+     printk("Unabled to request irq: %u for use\n", tpm->irq);
+     printk("Will use polling mode\n");
+     tpm->irq =3D 0;
+      } else {
+     /* Clear all existing */
+     iowrite32(TPM_INT_STATUS(tpm, tpm->locality),
ioread32(TPM_INT_STATUS(tpm, tpm->locality)));
+
+     /* Turn on interrupts */
+     iowrite32(TPM_INT_ENABLE(tpm, tpm->locality), intmask |
TPM_GLOBAL_INT_ENABLE);
+      }
+   }
+
+   tpm_get_timeouts(tpm);
+   tpm_continue_selftest(tpm);
+
+
+   return tpm;
+abort_egress:
+   if(tpm !=3D NULL) {
+      shutdown_tpm_tis(tpm);
+   }
+   return NULL;
+}
+
+void shutdown_tpm_tis(struct tpm_chip* tpm){
+   int i;
+
+   printk("Shutting down tpm_tis device\n");
+
+   iowrite32(TPM_INT_ENABLE(tpm, tpm->locality), ~TPM_GLOBAL_INT_ENABLE)=
;
+
+   /*Unmap all of the mmio pages */
+   for(i =3D 0; i < 5; ++i) {
+      if(tpm->pages[i] !=3D NULL) {
+     iounmap(tpm->pages[i], PAGE_SIZE);
+     tpm->pages[i] =3D NULL;
+      }
+   }
+   free(tpm);
+   return;
+}
+
+
+int tpm_tis_cmd(struct tpm_chip* tpm, uint8_t* req, size_t reqlen,
uint8_t** resp, size_t* resplen)
+{
+   if(tpm->locality < 0) {
+      printk("tpm_tis_cmd() failed! locality not set!\n");
+      return -1;
+   }
+   if(reqlen > TPM_BUFSIZE) {
+      reqlen =3D TPM_BUFSIZE;
+   }
+   memcpy(tpm->data_buffer, req, reqlen);
+   *resplen =3D tpm_transmit(tpm, tpm->data_buffer, TPM_BUFSIZE);
+
+   *resp =3D malloc(*resplen);
+   memcpy(*resp, tpm->data_buffer, *resplen);
+   return 0;
+}
+
+#ifdef HAVE_LIBC
+int tpm_tis_open(struct tpm_chip* tpm)
+{
+   /* Silently prevent multiple opens */
+   if(tpm->fd !=3D -1) {
+      return tpm->fd;
+   }
+
+   tpm->fd =3D alloc_fd(FTYPE_TPM_TIS);
+   printk("tpm_tis_open() -> %d\n", tpm->fd);
+   files[tpm->fd].tpm_tis.dev =3D tpm;
+   files[tpm->fd].tpm_tis.offset =3D 0;
+   files[tpm->fd].tpm_tis.respgot =3D 0;
+   return tpm->fd;
+}
+
+int tpm_tis_posix_write(int fd, const uint8_t* buf, size_t count)
+{
+   struct tpm_chip* tpm;
+   tpm =3D files[fd].tpm_tis.dev;
+
+   if(tpm->locality < 0) {
+      printk("tpm_tis_posix_write() failed! locality not set!\n");
+      errno =3D EINPROGRESS;
+      return -1;
+   }
+   if(count =3D=3D 0) {
+      return 0;
+   }
+
+   /* Return an error if we are already processing a command */
+   if(count > TPM_BUFSIZE) {
+      count =3D TPM_BUFSIZE;
+   }
+   /* Send the command now */
+   memcpy(tpm->data_buffer, buf, count);
+   if((tpm->data_len =3D tpm_transmit(tpm, tpm->data_buffer,
TPM_BUFSIZE)) < 0) {
+      errno =3D EIO;
+      return -1;
+   }
+   return count;
+}
+
+int tpm_tis_posix_read(int fd, uint8_t* buf, size_t count)
+{
+   int rc;
+   struct tpm_chip* tpm;
+   tpm =3D files[fd].tpm_tis.dev;
+
+   if(count =3D=3D 0) {
+      return 0;
+   }
+
+   /* If there is no tpm resp to read, return EIO */
+   if(tpm->data_len < 0) {
+      errno =3D EIO;
+      return -1;
+   }
+
+
+   /* Handle EOF case */
+   if(files[fd].tpm_tis.offset >=3D tpm->data_len) {
+      rc =3D 0;
+   } else {
+      rc =3D min(tpm->data_len - files[fd].tpm_tis.offset, count);
+      memcpy(buf, tpm->data_buffer + files[fd].tpm_tis.offset, rc);
+   }
+   files[fd].tpm_tis.offset +=3D rc;
+   /* Reset the data pending flag */
+   return rc;
+}
+int tpm_tis_posix_fstat(int fd, struct stat* buf)
+{
+   struct tpm_chip* tpm;
+   tpm =3D files[fd].tpm_tis.dev;
+
+   buf->st_mode =3D O_RDWR;
+   buf->st_uid =3D 0;
+   buf->st_gid =3D 0;
+   buf->st_size =3D be32_to_cpu(*((uint32_t*)(tpm->data_buffer + 2)));
+   buf->st_atime =3D buf->st_mtime =3D buf->st_ctime =3D time(NULL);
+   return 0;
+}
+
+
+#endif
diff --git a/extras/mini-os/tpmback.c b/extras/mini-os/tpmback.c
--- /dev/null
+++ b/extras/mini-os/tpmback.c
@@ -0,0 +1,1125 @@
+/*
+ * Copyright (c) 2010-2012 United States Government, as represented by
+ * the Secretary of Defense.  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 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 MERCHANTABILI=
TY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT
SHALL THE
+ * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHE=
R
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISI=
NG
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
DEALINGS
+ * IN THE SOFTWARE.
+ *
+ * Based upon the files:
+ *  drivers/xen/tpmbk.c
+ * from the Linux kernel, which are Copyright (C) 2006 IBM Corporation
+ */
+#include <mini-os/os.h>
+#include <mini-os/xenbus.h>
+#include <mini-os/events.h>
+#include <errno.h>
+#include <mini-os/gnttab.h>
+#include <xen/io/xenbus.h>
+#include <xen/io/tpmif.h>
+#include <xen/io/protocols.h>
+#include <mini-os/xmalloc.h>
+#include <time.h>
+#include <mini-os/tpmback.h>
+#include <mini-os/lib.h>
+#include <fcntl.h>
+#include <mini-os/mm.h>
+#include <mini-os/posix/sys/mman.h>
+#include <mini-os/semaphore.h>
+#include <mini-os/wait.h>
+
+
+#ifndef HAVE_LIBC
+#define strtoul simple_strtoul
+#endif
+
+//#define TPMBACK_PRINT_DEBUG
+#ifdef TPMBACK_PRINT_DEBUG
+#define TPMBACK_DEBUG(fmt,...) printk("Tpmback:Debug("__FILE__":%d) "
fmt, __LINE__, ##__VA_ARGS__)
+#define TPMBACK_DEBUG_MORE(fmt,...) printk(fmt, ##__VA_ARGS__)
+#else
+#define TPMBACK_DEBUG(fmt,...)
+#endif
+#define TPMBACK_ERR(fmt,...) printk("Tpmback:Error " fmt, ##__VA_ARGS__)=

+#define TPMBACK_LOG(fmt,...) printk("Tpmback:Info " fmt, ##__VA_ARGS__)
+
+#define min(a,b) (((a) < (b)) ? (a) : (b))
+
+/* Default size of the tpmif array at initialization */
+#define DEF_ARRAY_SIZE 1
+
+/* tpmif and tpmdev flags */
+#define TPMIF_CLOSED 1
+#define TPMIF_REQ_READY 2
+
+struct tpmif {
+   domid_t domid;
+   unsigned int handle;
+
+   char* fe_path;
+   char* fe_state_path;
+
+   /* Locally bound event channel*/
+   evtchn_port_t evtchn;
+
+   /* Shared page */
+   tpmif_tx_interface_t* tx;
+
+   /* pointer to TPMIF_RX_RING_SIZE pages */
+   void** pages;
+
+   enum xenbus_state state;
+   enum { DISCONNECTED, DISCONNECTING, CONNECTED } status;
+
+   char* uuid;
+
+   /* state flags */
+   int flags;
+};
+typedef struct tpmif tpmif_t;
+
+struct tpmback_dev {
+
+   tpmif_t** tpmlist;
+   unsigned long num_tpms;
+   unsigned long num_alloc;
+
+   struct gntmap map;
+
+   /* True if at least one tpmif has a request to be handled */
+   int flags;
+
+   /* exclusive domains, see init_tpmback comment in tpmback.h */
+   char** exclusive_uuids;
+
+   xenbus_event_queue events;
+
+   /* Callbacks */
+   void (*open_callback)(domid_t, unsigned int);
+   void (*close_callback)(domid_t, unsigned int);
+   void (*suspend_callback)(domid_t, unsigned int);
+   void (*resume_callback)(domid_t, unsigned int);
+};
+typedef struct tpmback_dev tpmback_dev_t;
+
+enum { EV_NONE, EV_NEWFE, EV_STCHNG } tpm_ev_enum;
+
+/* Global objects */
+static struct thread* eventthread =3D NULL;
+static tpmback_dev_t gtpmdev =3D {
+   .tpmlist =3D NULL,
+   .num_tpms =3D 0,
+   .num_alloc =3D 0,
+   .flags =3D TPMIF_CLOSED,
+   .events =3D NULL,
+   .open_callback =3D NULL,
+   .close_callback =3D NULL,
+   .suspend_callback =3D NULL,
+   .resume_callback =3D NULL,
+};
+struct wait_queue_head waitq;
+int globalinit =3D 0;
+
+/************************************
+ * TPMIF SORTED ARRAY FUNCTIONS
+ * tpmback_dev_t.tpmlist is a sorted array, sorted by domid and then
handle number
+ * Duplicates are not allowed
+ * **********************************/
+
+inline void tpmif_req_ready(tpmif_t* tpmif) {
+   tpmif->flags |=3D TPMIF_REQ_READY;
+   gtpmdev.flags |=3D TPMIF_REQ_READY;
+}
+
+inline void tpmdev_check_req(void) {
+   int i;
+   int flags;
+   local_irq_save(flags);
+   for(i =3D 0; i < gtpmdev.num_tpms; ++i) {
+      if(gtpmdev.tpmlist[i]->flags & TPMIF_REQ_READY) {
+     gtpmdev.flags |=3D TPMIF_REQ_READY;
+     local_irq_restore(flags);
+     return;
+      }
+   }
+   gtpmdev.flags &=3D ~TPMIF_REQ_READY;
+   local_irq_restore(flags);
+}
+
+inline void tpmif_req_finished(tpmif_t* tpmif) {
+   tpmif->flags &=3D ~TPMIF_REQ_READY;
+   tpmdev_check_req();
+}
+
+int __get_tpmif_index(int st, int n, domid_t domid, unsigned int handle)=

+{
+   int i =3D st + n /2;
+   tpmif_t* tmp;
+
+   if( n <=3D 0 )
+      return -1;
+
+   tmp =3D gtpmdev.tpmlist[i];
+   if(domid =3D=3D tmp->domid && tmp->handle =3D=3D handle) {
+      return i;
+   } else if ( (domid < tmp->domid) ||
+     (domid =3D=3D tmp->domid && handle < tmp->handle)) {
+      return __get_tpmif_index(st, n/2, domid, handle);
+   } else {
+      return __get_tpmif_index(i + 1, n/2 - ((n +1) % 2), domid, handle)=
;
+   }
+}
+
+/* Returns the array index of the tpmif domid/handle. Returns -1 if no
such tpmif exists */
+int get_tpmif_index(domid_t domid, unsigned int handle)
+{
+   int flags;
+   int index;
+   local_irq_save(flags);
+   index =3D __get_tpmif_index(0, gtpmdev.num_tpms, domid, handle);
+   local_irq_restore(flags);
+   return index;
+}
+
+/* Returns the tpmif domid/handle or NULL if none exists */
+tpmif_t* get_tpmif(domid_t domid, unsigned int handle)
+{
+   int flags;
+   int i;
+   tpmif_t* ret;
+   local_irq_save(flags);
+   i =3D get_tpmif_index(domid, handle);
+   if (i < 0) {
+      ret =3D NULL;
+   } else {
+      ret =3D gtpmdev.tpmlist[i];
+   }
+   local_irq_restore(flags);
+   return ret;
+}
+
+/* Remove the given tpmif. Returns 0 if it was removed, -1 if it was
not removed */
+int remove_tpmif(tpmif_t* tpmif)
+{
+   int i, j;
+   char* err;
+   int flags;
+   local_irq_save(flags);
+
+   /* Find the index in the array if it exists */
+   i =3D get_tpmif_index(tpmif->domid, tpmif->handle);
+   if (i < 0) {
+      goto error;
+   }
+
+   /* Remove the interface from the list */
+   for(j =3D i; j < gtpmdev.num_tpms - 1; ++j) {
+      gtpmdev.tpmlist[j] =3D gtpmdev.tpmlist[j+1];
+   }
+   gtpmdev.tpmlist[j] =3D NULL;
+   --gtpmdev.num_tpms;
+
+   /* If removed tpm was the only ready tpm, then we need to check and
turn off the ready flag */
+   tpmdev_check_req();
+
+   local_irq_restore(flags);
+
+   /* Stop listening for events on this tpm interface */
+   if((err =3D xenbus_unwatch_path_token(XBT_NIL, tpmif->fe_state_path,
tpmif->fe_state_path))) {
+      TPMBACK_ERR("Unable to unwatch path token `%s' Error was %s
Ignoring..\n", tpmif->fe_state_path, err);
+      free(err);
+   }
+
+   return 0;
+error:
+   local_irq_restore(flags);
+   return -1;
+}
+
+/* Insert tpmif into dev->tpmlist. Returns 0 on success and non zero on
error.
+ * It is an error to insert a tpmif with the same domid and handle
+ * number
+ * as something already in the list */
+int insert_tpmif(tpmif_t* tpmif)
+{
+   int flags;
+   unsigned int i, j;
+   tpmif_t* tmp;
+   char* err;
+
+   local_irq_save(flags);
+
+   /*Check if we need to allocate more space */
+   if (gtpmdev.num_tpms =3D=3D gtpmdev.num_alloc) {
+      gtpmdev.num_alloc *=3D 2;
+      gtpmdev.tpmlist =3D realloc(gtpmdev.tpmlist, gtpmdev.num_alloc);
+   }
+
+   /*Find where to put the new interface */
+   for(i =3D 0; i < gtpmdev.num_tpms; ++i)
+   {
+      tmp =3D gtpmdev.tpmlist[i];
+      if(tpmif->domid =3D=3D tmp->domid && tpmif->handle =3D=3D tmp->han=
dle) {
+     TPMBACK_ERR("Tried to insert duplicate tpm interface %u/%u\n",
(unsigned int) tpmif->domid, tpmif->handle);
+     goto error;
+      }
+      if((tpmif->domid < tmp->domid) ||
+        (tpmif->domid =3D=3D tmp->domid && tpmif->handle < tmp->handle))=
 {
+     break;
+      }
+   }
+
+   /*Shift all the tpm pointers past i down one */
+   for(j =3D gtpmdev.num_tpms; j > i; --j) {
+      gtpmdev.tpmlist[j] =3D gtpmdev.tpmlist[j-1];
+   }
+
+   /*Add the new interface */
+   gtpmdev.tpmlist[i] =3D tpmif;
+   ++gtpmdev.num_tpms;
+
+   /*Should not be needed, anything inserted with ready flag is
probably an error */
+   tpmdev_check_req();
+
+   local_irq_restore(flags);
+
+   /*Listen for state changes on the new interface */
+   if((err =3D xenbus_watch_path_token(XBT_NIL, tpmif->fe_state_path,
tpmif->fe_state_path, &gtpmdev.events)))
+   {
+      /* if we got an error here we should carefully remove the
interface and then return */
+      TPMBACK_ERR("Unable to watch path token `%s' Error was %s\n",
tpmif->fe_state_path, err);
+      free(err);
+      remove_tpmif(tpmif);
+      goto error_post_irq;
+   }
+
+   return 0;
+error:
+   local_irq_restore(flags);
+error_post_irq:
+   return -1;
+}
+
+
+/*****************
+ * CHANGE BACKEND STATE
+ * *****************/
+/*Attempts to change the backend state in xenstore
+ * returns 0 on success and non-zero on error */
+int tpmif_change_state(tpmif_t* tpmif, enum xenbus_state state)
+{
+   char path[512];
+   char *value;
+   char *err;
+   enum xenbus_state readst;
+   TPMBACK_DEBUG("Backend state change %u/%u from=3D%d to=3D%d\n",
(unsigned int) tpmif->domid, tpmif->handle, tpmif->state, state);
+   if (tpmif->state =3D=3D state)
+      return 0;
+
+   snprintf(path, 512, "backend/vtpm/%u/%u/state", (unsigned int)
tpmif->domid, tpmif->handle);
+
+   if((err =3D xenbus_read(XBT_NIL, path, &value))) {
+      TPMBACK_ERR("Unable to read backend state %s, error was %s\n",
path, err);
+      free(err);
+      return -1;
+   }
+   if(sscanf(value, "%d", &readst) !=3D 1) {
+      TPMBACK_ERR("Non integer value (%s) in %s ??\n", value, path);
+      free(value);
+      return -1;
+   }
+   free(value);
+
+   /* It's possible that the backend state got updated by hotplug or
something else behind our back */
+   if(readst !=3D tpmif->state) {
+      TPMBACK_DEBUG("tpm interface state was %d but xenstore state was
%d!\n", tpmif->state, readst);
+      tpmif->state =3D readst;
+   }
+
+   /*If if the state isnt changing, then we dont update xenstore b/c we
dont want to fire extraneous events */
+   if(tpmif->state =3D=3D state) {
+      return 0;
+   }
+
+   /*update xenstore*/
+   snprintf(path, 512, "backend/vtpm/%u/%u", (unsigned int)
tpmif->domid, tpmif->handle);
+   if((err =3D xenbus_printf(XBT_NIL, path, "state", "%u", state))) {
+      TPMBACK_ERR("Error writing to xenstore %s, error was %s new
state=3D%d\n", path, err, state);
+      free(err);
+      return -1;
+   }
+
+   tpmif->state =3D state;
+
+   return 0;
+}
+/**********************************
+ * TPMIF CREATION AND DELETION
+ * *******************************/
+inline tpmif_t* __init_tpmif(domid_t domid, unsigned int handle)
+{
+   tpmif_t* tpmif;
+   tpmif =3D malloc(sizeof(*tpmif));
+   tpmif->domid =3D domid;
+   tpmif->handle =3D handle;
+   tpmif->fe_path =3D NULL;
+   tpmif->fe_state_path =3D NULL;
+   tpmif->state =3D XenbusStateInitialising;
+   tpmif->status =3D DISCONNECTED;
+   tpmif->tx =3D NULL;
+   tpmif->pages =3D NULL;
+   tpmif->flags =3D 0;
+   tpmif->uuid =3D NULL;
+   return tpmif;
+}
+
+void __free_tpmif(tpmif_t* tpmif)
+{
+   if(tpmif->pages) {
+      free(tpmif->pages);
+   }
+   if(tpmif->fe_path) {
+      free(tpmif->fe_path);
+   }
+   if(tpmif->fe_state_path) {
+      free(tpmif->fe_state_path);
+   }
+   if(tpmif->uuid) {
+      free(tpmif->uuid);
+   }
+   free(tpmif);
+}
+/* Creates a new tpm interface, adds it to the sorted array and returns =
it.
+ * returns NULL on error
+ * If the tpm interface already exists, it is returned*/
+tpmif_t* new_tpmif(domid_t domid, unsigned int handle)
+{
+   tpmif_t* tpmif;
+   char* err;
+   char path[512];
+
+   /* Make sure we haven't already created this tpm
+    * Double events can occur */
+   if((tpmif =3D get_tpmif(domid, handle)) !=3D NULL) {
+      return tpmif;
+   }
+
+   tpmif =3D __init_tpmif(domid, handle);
+
+   /* Get the uuid from xenstore */
+   snprintf(path, 512, "backend/vtpm/%u/%u/uuid", (unsigned int) domid,
handle);
+   if((err =3D xenbus_read(XBT_NIL, path, &tpmif->uuid))) {
+      TPMBACK_ERR("Error reading %s, Error =3D %s\n", path, err);
+      free(err);
+      goto error;
+   }
+
+   /* Do the exclusive uuid check now */
+   if(gtpmdev.exclusive_uuids !=3D NULL) {
+      char** ptr;
+
+      /* Check that its in the whitelist */
+      for(ptr =3D gtpmdev.exclusive_uuids; *ptr !=3D NULL; ++ptr) {
+     if(!strcmp(tpmif->uuid, *ptr)) {
+        break;
+     }
+      }
+      /* If *ptr =3D=3D NULL then we went through the whole list without=
 a
match, so close the connection */
+      if(*ptr =3D=3D NULL) {
+     tpmif_change_state(tpmif, XenbusStateClosed);
+     TPMBACK_ERR("Frontend %u/%u tried to connect with invalid
uuid=3D%s\n", (unsigned int) domid, handle, tpmif->uuid);
+     goto error;
+      }
+   }
+
+   /* allocate pages to be used for shared mapping */
+   if((tpmif->pages =3D malloc(sizeof(void*) * TPMIF_TX_RING_SIZE)) =3D=3D=

NULL) {
+      goto error;
+   }
+   memset(tpmif->pages, 0, sizeof(void*) * TPMIF_TX_RING_SIZE);
+
+   if(tpmif_change_state(tpmif, XenbusStateInitWait)) {
+      goto error;
+   }
+
+   snprintf(path, 512, "backend/vtpm/%u/%u/frontend", (unsigned int)
domid, handle);
+   if((err =3D xenbus_read(XBT_NIL, path, &tpmif->fe_path))) {
+      TPMBACK_ERR("Error creating new tpm instance xenbus_read(%s),
Error =3D %s", path, err);
+      free(err);
+      goto error;
+   }
+
+   /*Set the state path */
+   tpmif->fe_state_path =3D malloc(strlen(tpmif->fe_path) + 7);
+   strcpy(tpmif->fe_state_path, tpmif->fe_path);
+   strcat(tpmif->fe_state_path, "/state");
+
+   if(insert_tpmif(tpmif)) {
+      goto error;
+   }
+   TPMBACK_DEBUG("New tpmif %u/%u\n", (unsigned int) tpmif->domid,
tpmif->handle);
+   /* Do the callback now */
+   if(gtpmdev.open_callback) {
+      gtpmdev.open_callback(tpmif->domid, tpmif->handle);
+   }
+   return tpmif;
+error:
+   __free_tpmif(tpmif);
+   return NULL;
+
+}
+
+/* Removes tpmif from dev->tpmlist and frees it's memory usage */
+void free_tpmif(tpmif_t* tpmif)
+{
+   char* err;
+   char path[512];
+   TPMBACK_DEBUG("Free tpmif %u/%u\n", (unsigned int) tpmif->domid,
tpmif->handle);
+   if(tpmif->flags & TPMIF_CLOSED) {
+      TPMBACK_ERR("Tried to free an instance twice! Theres a bug
somewhere!\n");
+      BUG();
+   }
+   tpmif->flags =3D TPMIF_CLOSED;
+
+   tpmif_change_state(tpmif, XenbusStateClosing);
+
+   /* Unmap share page and unbind event channel */
+   if(tpmif->status =3D=3D CONNECTED) {
+      tpmif->status =3D DISCONNECTING;
+      mask_evtchn(tpmif->evtchn);
+
+      if(gntmap_munmap(&gtpmdev.map, (unsigned long)tpmif->tx, 1)) {
+     TPMBACK_ERR("%u/%u Error occured while trying to unmap shared
page\n", (unsigned int) tpmif->domid, tpmif->handle);
+      }
+
+      unbind_evtchn(tpmif->evtchn);
+   }
+   tpmif->status =3D DISCONNECTED;
+   tpmif_change_state(tpmif, XenbusStateClosed);
+
+   /* Do the callback now */
+   if(gtpmdev.close_callback) {
+      gtpmdev.close_callback(tpmif->domid, tpmif->handle);
+   }
+
+   /* remove from array */
+   remove_tpmif(tpmif);
+
+   /* Wake up anyone possibly waiting on this interface and let them
exit */
+   wake_up(&waitq);
+   schedule();
+
+   /* Remove the old xenbus entries */
+   snprintf(path, 512, "backend/vtpm/%u/%u", (unsigned int)
tpmif->domid, tpmif->handle);
+   if((err =3D xenbus_rm(XBT_NIL, path))) {
+      TPMBACK_ERR("Error cleaning up xenbus entries path=3D%s
error=3D%s\n", path, err);
+      free(err);
+   }
+
+   TPMBACK_LOG("Frontend %u/%u disconnected\n", (unsigned int)
tpmif->domid, tpmif->handle);
+
+   /* free memory */
+   __free_tpmif(tpmif);
+
+}
+
+/**********************
+ * REMAINING TPMBACK FUNCTIONS
+ * ********************/
+
+/*Event channel handler */
+void tpmback_handler(evtchn_port_t port, struct pt_regs *regs, void *dat=
a)
+{
+   tpmif_t* tpmif =3D (tpmif_t*) data;
+   tpmif_tx_request_t* tx =3D &tpmif->tx->ring[0].req;
+   /* Throw away 0 size events, these can trigger from event channel
unmasking */
+   if(tx->size =3D=3D 0)
+      return;
+
+   TPMBACK_DEBUG("EVENT CHANNEL FIRE %u/%u\n", (unsigned int)
tpmif->domid, tpmif->handle);
+   tpmif_req_ready(tpmif);
+   wake_up(&waitq);
+
+}
+
+/* Connect to frontend */
+int connect_fe(tpmif_t* tpmif)
+{
+   char path[512];
+   char* err, *value;
+   uint32_t domid;
+   grant_ref_t ringref;
+   evtchn_port_t evtchn;
+
+   /* If already connected then quit */
+   if (tpmif->status =3D=3D CONNECTED) {
+      TPMBACK_DEBUG("%u/%u tried to connect while it was already
connected?\n", (unsigned int) tpmif->domid, tpmif->handle);
+      return 0;
+   }
+
+   /* Fetch the grant reference */
+   snprintf(path, 512, "%s/ring-ref", tpmif->fe_path);
+   if((err =3D xenbus_read(XBT_NIL, path, &value))) {
+      TPMBACK_ERR("Error creating new tpm instance xenbus_read(%s)
Error =3D %s", path, err);
+      free(err);
+      return -1;
+   }
+   if(sscanf(value, "%d", &ringref) !=3D 1) {
+      TPMBACK_ERR("Non integer value (%s) in %s ??\n", value, path);
+      free(value);
+      return -1;
+   }
+   free(value);
+
+
+   /* Fetch the event channel*/
+   snprintf(path, 512, "%s/event-channel", tpmif->fe_path);
+   if((err =3D xenbus_read(XBT_NIL, path, &value))) {
+      TPMBACK_ERR("Error creating new tpm instance xenbus_read(%s)
Error =3D %s", path, err);
+      free(err);
+      return -1;
+   }
+   if(sscanf(value, "%d", &evtchn) !=3D 1) {
+      TPMBACK_ERR("Non integer value (%s) in %s ??\n", value, path);
+      free(value);
+      return -1;
+   }
+   free(value);
+
+   domid =3D tpmif->domid;
+   if((tpmif->tx =3D gntmap_map_grant_refs(&gtpmdev.map, 1, &domid, 0,
&ringref, PROT_READ | PROT_WRITE)) =3D=3D NULL) {
+      TPMBACK_ERR("Failed to map grant reference %u/%u\n", (unsigned
int) tpmif->domid, tpmif->handle);
+      return -1;
+   }
+   memset(tpmif->tx, 0, PAGE_SIZE);
+
+   /*Bind the event channel */
+   if((evtchn_bind_interdomain(tpmif->domid, evtchn, tpmback_handler,
tpmif, &tpmif->evtchn)))
+   {
+      TPMBACK_ERR("%u/%u Unable to bind to interdomain event
channel!\n", (unsigned int) tpmif->domid, tpmif->handle);
+      goto error_post_map;
+   }
+   unmask_evtchn(tpmif->evtchn);
+
+   /* Write the ready flag and change status to connected */
+   snprintf(path, 512, "backend/vtpm/%u/%u", (unsigned int)
tpmif->domid, tpmif->handle);
+   if((err =3D xenbus_printf(XBT_NIL, path, "ready", "%u", 1))) {
+      TPMBACK_ERR("%u/%u Unable to write ready flag on connect_fe()\n",
(unsigned int) tpmif->domid, tpmif->handle);
+      free(err);
+      goto error_post_evtchn;
+   }
+   tpmif->status =3D CONNECTED;
+   if((tpmif_change_state(tpmif, XenbusStateConnected))){
+      goto error_post_evtchn;
+   }
+
+   TPMBACK_LOG("Frontend %u/%u connected\n", (unsigned int)
tpmif->domid, tpmif->handle);
+
+   return 0;
+error_post_evtchn:
+   mask_evtchn(tpmif->evtchn);
+   unbind_evtchn(tpmif->evtchn);
+error_post_map:
+   gntmap_munmap(&gtpmdev.map, (unsigned long)tpmif->tx, 1);
+   return -1;
+}
+
+static int frontend_changed(tpmif_t* tpmif)
+{
+   int state =3D xenbus_read_integer(tpmif->fe_state_path);
+   if(state < 0) {
+      state =3D XenbusStateUnknown;
+   }
+
+   TPMBACK_DEBUG("Frontend %u/%u state changed to %d\n", (unsigned int)
tpmif->domid, tpmif->handle, state);
+
+   switch (state) {
+      case XenbusStateInitialising:
+      case XenbusStateInitialised:
+     break;
+
+      case XenbusStateConnected:
+     if(connect_fe(tpmif)) {
+        TPMBACK_ERR("Failed to connect to front end %u/%u\n", (unsigned
int) tpmif->domid, tpmif->handle);
+        tpmif_change_state(tpmif, XenbusStateClosed);
+        return -1;
+     }
+     break;
+
+      case XenbusStateClosing:
+     tpmif_change_state(tpmif, XenbusStateClosing);
+     break;
+
+      case XenbusStateUnknown: /* keep it here */
+      case XenbusStateClosed:
+     free_tpmif(tpmif);
+     break;
+
+      default:
+     TPMBACK_DEBUG("BAD STATE CHANGE %u/%u state =3D %d for tpmif\n",
(unsigned int) tpmif->domid, tpmif->handle, state);
+     return -1;
+   }
+   return 0;
+}
+
+
+/* parses the string that comes out of xenbus_watch_wait_return. */
+static int parse_eventstr(const char* evstr, domid_t* domid, unsigned
int* handle)
+{
+   int ret;
+   char cmd[40];
+   char* err;
+   char* value;
+   unsigned int udomid =3D 0;
+   tpmif_t* tpmif;
+   /* First check for new frontends, this occurs when
/backend/vtpm/<domid>/<handle> gets created. Note we what the sscanf to
fail on the last %s */
+   if (sscanf(evstr, "backend/vtpm/%u/%u/%40s", &udomid, handle, cmd)
=3D=3D 2) {
+      *domid =3D udomid;
+      /* Make sure the entry exists, if this event triggers because the
entry dissapeared then ignore it */
+      if((err =3D xenbus_read(XBT_NIL, evstr, &value))) {
+     free(err);
+     return EV_NONE;
+      }
+      free(value);
+      /* Make sure the tpmif entry does not already exist, this should
not happen */
+      if((tpmif =3D get_tpmif(*domid, *handle)) !=3D NULL) {
+     TPMBACK_DEBUG("Duplicate tpm entries! %u %u\n", tpmif->domid,
tpmif->handle);
+     return EV_NONE;
+      }
+      return EV_NEWFE;
+   } else if((ret =3D sscanf(evstr,
"/local/domain/%u/device/vtpm/%u/%40s", &udomid, handle, cmd)) =3D=3D 3) =
{
+      *domid =3D udomid;
+      if (!strcmp(cmd, "state"))
+     return EV_STCHNG;
+   }
+   return EV_NONE;
+}
+
+void handle_backend_event(char* evstr) {
+   tpmif_t* tpmif;
+   domid_t domid;
+   unsigned int handle;
+   int event;
+
+   TPMBACK_DEBUG("Xenbus Event: %s\n", evstr);
+
+   event =3D parse_eventstr(evstr, &domid, &handle);
+
+   switch(event) {
+      case EV_NEWFE:
+     if(new_tpmif(domid, handle) =3D=3D NULL) {
+        TPMBACK_ERR("Failed to create new tpm instance %u/%u\n",
(unsigned int) domid, handle);
+     }
+     wake_up(&waitq);
+     break;
+      case EV_STCHNG:
+     if((tpmif =3D get_tpmif(domid, handle))) {
+        frontend_changed(tpmif);
+     } else {
+        TPMBACK_DEBUG("Event Received for non-existant tpm!
instance=3D%u/%u xenbus_event=3D%s\n", (unsigned int) domid, handle, evst=
r);
+     }
+     break;
+   }
+}
+
+/* Runs through the given path and creates events recursively
+ * for all of its children.
+ * @path - xenstore path to scan */
+static void generate_backend_events(const char* path)
+{
+   char* err;
+   int i, len;
+   char **dirs;
+   char *entry;
+
+   if((err =3D xenbus_ls(XBT_NIL, path, &dirs)) !=3D NULL) {
+      free(err);
+      return;
+   }
+
+   for(i =3D 0; dirs[i] !=3D NULL; ++i) {
+      len =3D strlen(path) + strlen(dirs[i]) + 2;
+      entry =3D malloc(len);
+      snprintf(entry, len, "%s/%s", path, dirs[i]);
+
+      /* Generate and handle event for the entry itself */
+      handle_backend_event(entry);
+
+      /* Do children */
+      generate_backend_events(entry);
+
+      /* Cleanup */
+      free(entry);
+      free(dirs[i]);
+   }
+   free(dirs);
+   return;
+}
+
+char* tpmback_get_uuid(domid_t domid, unsigned int handle)
+{
+   tpmif_t* tpmif;
+   if((tpmif =3D get_tpmif(domid, handle)) =3D=3D NULL) {
+      TPMBACK_DEBUG("get_uuid() failed, %u/%u is an invalid
frontend\n", (unsigned int) domid, handle);
+      return NULL;
+   }
+
+   return tpmif->uuid;
+}
+
+void tpmback_set_open_callback(void (*cb)(domid_t, unsigned int))
+{
+   gtpmdev.open_callback =3D cb;
+}
+void tpmback_set_close_callback(void (*cb)(domid_t, unsigned int))
+{
+   gtpmdev.close_callback =3D cb;
+}
+void tpmback_set_suspend_callback(void (*cb)(domid_t, unsigned int))
+{
+   gtpmdev.suspend_callback =3D cb;
+}
+void tpmback_set_resume_callback(void (*cb)(domid_t, unsigned int))
+{
+   gtpmdev.resume_callback =3D cb;
+}
+
+static void event_listener(void)
+{
+   const char* bepath =3D "backend/vtpm";
+   char **path;
+   char* err;
+
+   /* Setup the backend device watch */
+   if((err =3D xenbus_watch_path_token(XBT_NIL, bepath, bepath,
&gtpmdev.events)) !=3D NULL) {
+      TPMBACK_ERR("xenbus_watch_path_token(%s) failed with error
%s!\n", bepath, err);
+      free(err);
+      goto egress;
+   }
+
+   /* Check for any frontends that connected before we set the watch.
+    * This is almost guaranteed to happen if both domains are started
+    * immediatly one after the other.
+    * We do this by manually generating events on everything in the back=
end
+    * path */
+   generate_backend_events(bepath);
+
+   /* Wait and listen for changes in frontend connections */
+   while(1) {
+      path =3D xenbus_wait_for_watch_return(&gtpmdev.events);
+
+      /*If quit flag was set then exit */
+      if(gtpmdev.flags & TPMIF_CLOSED) {
+     TPMBACK_DEBUG("listener thread got quit event. Exiting..\n");
+     free(path);
+     break;
+      }
+      handle_backend_event(*path);
+      free(path);
+
+   }
+
+   if((err =3D xenbus_unwatch_path_token(XBT_NIL, bepath, bepath)) !=3D =
NULL) {
+      free(err);
+   }
+egress:
+   return;
+}
+
+void event_thread(void* p) {
+   event_listener();
+}
+
+void init_tpmback(char** exclusive_uuids)
+{
+   if(!globalinit) {
+      init_waitqueue_head(&waitq);
+      globalinit =3D 1;
+   }
+   printk("=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Init TPM BACK =3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D\n");
+   gtpmdev.tpmlist =3D malloc(sizeof(tpmif_t*) * DEF_ARRAY_SIZE);
+   gtpmdev.num_alloc =3D DEF_ARRAY_SIZE;
+   gtpmdev.num_tpms =3D 0;
+   gtpmdev.flags =3D 0;
+   gtpmdev.exclusive_uuids =3D exclusive_uuids;
+
+   gtpmdev.open_callback =3D gtpmdev.close_callback =3D NULL;
+   gtpmdev.suspend_callback =3D gtpmdev.resume_callback =3D NULL;
+
+   eventthread =3D create_thread("tpmback-listener", event_thread, NULL)=
;
+
+}
+
+void shutdown_tpmback(void)
+{
+   /* Disable callbacks */
+   gtpmdev.open_callback =3D gtpmdev.close_callback =3D NULL;
+   gtpmdev.suspend_callback =3D gtpmdev.resume_callback =3D NULL;
+
+   TPMBACK_LOG("Shutting down tpm backend\n");
+   /* Set the quit flag */
+   gtpmdev.flags =3D TPMIF_CLOSED;
+
+   //printk("num tpms is %d\n", gtpmdev.num_tpms);
+   /*Free all backend instances */
+   while(gtpmdev.num_tpms) {
+      free_tpmif(gtpmdev.tpmlist[0]);
+   }
+   free(gtpmdev.tpmlist);
+   gtpmdev.tpmlist =3D NULL;
+   gtpmdev.num_alloc =3D 0;
+
+   /* Wake up anyone possibly waiting on the device and let them exit */=

+   wake_up(&waitq);
+   schedule();
+}
+
+inline void init_tpmcmd(tpmcmd_t* tpmcmd, domid_t domid, unsigned int
handle, char* uuid)
+{
+   tpmcmd->domid =3D domid;
+   tpmcmd->handle =3D handle;
+   tpmcmd->uuid =3D uuid;
+   tpmcmd->req =3D NULL;
+   tpmcmd->req_len =3D 0;
+   tpmcmd->resp =3D NULL;
+   tpmcmd->resp_len =3D 0;
+}
+
+tpmcmd_t* get_request(tpmif_t* tpmif) {
+   tpmcmd_t* cmd;
+   tpmif_tx_request_t* tx;
+   int offset;
+   int tocopy;
+   int i;
+   uint32_t domid;
+   int flags;
+
+   local_irq_save(flags);
+
+   /* Allocate the cmd object to hold the data */
+   if((cmd =3D malloc(sizeof(*cmd))) =3D=3D NULL) {
+      goto error;
+   }
+   init_tpmcmd(cmd, tpmif->domid, tpmif->handle, tpmif->uuid);
+
+   tx =3D &tpmif->tx->ring[0].req;
+   cmd->req_len =3D tx->size;
+   /* Allocate the buffer */
+   if(cmd->req_len) {
+      if((cmd->req =3D malloc(cmd->req_len)) =3D=3D NULL) {
+     goto error;
+      }
+   }
+   /* Copy the bits from the shared pages */
+   offset =3D 0;
+   for(i =3D 0; i < TPMIF_TX_RING_SIZE && offset < cmd->req_len; ++i) {
+      tx =3D &tpmif->tx->ring[i].req;
+
+      /* Map the page with the data */
+      domid =3D (uint32_t)tpmif->domid;
+      if((tpmif->pages[i] =3D gntmap_map_grant_refs(&gtpmdev.map, 1,
&domid, 0, &tx->ref, PROT_READ)) =3D=3D NULL) {
+     TPMBACK_ERR("%u/%u Unable to map shared page during read!\n",
(unsigned int) tpmif->domid, tpmif->handle);
+     goto error;
+      }
+
+      /* do the copy now */
+      tocopy =3D min(cmd->req_len - offset, PAGE_SIZE);
+      memcpy(&cmd->req[offset], tpmif->pages[i], tocopy);
+      offset +=3D tocopy;
+
+      /* release the page */
+      gntmap_munmap(&gtpmdev.map, (unsigned long)tpmif->pages[i], 1);
+
+   }
+
+#ifdef TPMBACK_PRINT_DEBUG
+   TPMBACK_DEBUG("Received Tpm Command from %u/%u of size %u",
(unsigned int) tpmif->domid, tpmif->handle, cmd->req_len);
+   for(i =3D 0; i < cmd->req_len; ++i) {
+      if (!(i % 30)) {
+     TPMBACK_DEBUG_MORE("\n");
+      }
+      TPMBACK_DEBUG_MORE("%02hhX ", cmd->req[i]);
+   }
+   TPMBACK_DEBUG_MORE("\n\n");
+#endif
+
+   local_irq_restore(flags);
+   return cmd;
+error:
+   if(cmd !=3D NULL) {
+      if (cmd->req !=3D NULL) {
+     free(cmd->req);
+     cmd->req =3D NULL;
+      }
+      free(cmd);
+      cmd =3D NULL;
+   }
+   local_irq_restore(flags);
+   return NULL;
+
+}
+
+void send_response(tpmcmd_t* cmd, tpmif_t* tpmif)
+{
+   tpmif_tx_request_t* tx;
+   int offset;
+   int i;
+   uint32_t domid;
+   int tocopy;
+   int flags;
+
+   local_irq_save(flags);
+
+   tx =3D &tpmif->tx->ring[0].req;
+   tx->size =3D cmd->resp_len;
+
+   offset =3D 0;
+   for(i =3D 0; i < TPMIF_TX_RING_SIZE && offset < cmd->resp_len; ++i) {=

+      tx =3D &tpmif->tx->ring[i].req;
+
+      /* Map the page with the data */
+      domid =3D (uint32_t)tpmif->domid;
+      if((tpmif->pages[i] =3D gntmap_map_grant_refs(&gtpmdev.map, 1,
&domid, 0, &tx->ref, PROT_WRITE)) =3D=3D NULL) {
+     TPMBACK_ERR("%u/%u Unable to map shared page during write!\n",
(unsigned int) tpmif->domid, tpmif->handle);
+     goto error;
+      }
+
+      /* do the copy now */
+      tocopy =3D min(cmd->resp_len - offset, PAGE_SIZE);
+      memcpy(tpmif->pages[i], &cmd->resp[offset], tocopy);
+      offset +=3D tocopy;
+
+      /* release the page */
+      gntmap_munmap(&gtpmdev.map, (unsigned long)tpmif->pages[i], 1);
+
+   }
+
+#ifdef TPMBACK_PRINT_DEBUG
+   TPMBACK_DEBUG("Sent response to %u/%u of size %u", (unsigned int)
tpmif->domid, tpmif->handle, cmd->resp_len);
+   for(i =3D 0; i < cmd->resp_len; ++i) {
+      if (!(i % 30)) {
+     TPMBACK_DEBUG_MORE("\n");
+      }
+      TPMBACK_DEBUG_MORE("%02hhX ", cmd->resp[i]);
+   }
+   TPMBACK_DEBUG_MORE("\n\n");
+#endif
+   /* clear the ready flag and send the event channel notice to the
frontend */
+   tpmif_req_finished(tpmif);
+   notify_remote_via_evtchn(tpmif->evtchn);
+error:
+   local_irq_restore(flags);
+   return;
+}
+
+tpmcmd_t* tpmback_req_any(void)
+{
+   int i;
+   /* Block until something has a request */
+   wait_event(waitq, (gtpmdev.flags & (TPMIF_REQ_READY | TPMIF_CLOSED)))=
;
+
+   /* Check if were shutting down */
+   if(gtpmdev.flags & TPMIF_CLOSED) {
+      /* if something was waiting for us to give up the queue so it can
shutdown, let it finish */
+      schedule();
+      return NULL;
+   }
+
+   for(i =3D 0; i < gtpmdev.num_tpms; ++i) {
+      if(gtpmdev.tpmlist[i]->flags & TPMIF_REQ_READY) {
+     return get_request(gtpmdev.tpmlist[i]);
+      }
+   }
+
+   TPMBACK_ERR("backend request ready flag was set but no interfaces
were actually ready\n");
+   return NULL;
+}
+
+tpmcmd_t* tpmback_req(domid_t domid, unsigned int handle)
+{
+   tpmif_t* tpmif;
+   tpmif =3D get_tpmif(domid, handle);
+   if(tpmif =3D=3D NULL) {
+      return NULL;
+   }
+
+   wait_event(waitq, (tpmif->flags & (TPMIF_REQ_READY | TPMIF_CLOSED)
|| gtpmdev.flags & TPMIF_CLOSED));
+
+   /* Check if were shutting down */
+   if(tpmif->flags & TPMIF_CLOSED || gtpmdev.flags & TPMIF_CLOSED) {
+      /* if something was waiting for us to give up the queue so it can
free this instance, let it finish */
+      schedule();
+      return NULL;
+   }
+
+   return get_request(tpmif);
+}
+
+void tpmback_resp(tpmcmd_t* tpmcmd)
+{
+   tpmif_t* tpmif;
+
+   /* Get the associated interface, if it doesnt exist then just quit */=

+   tpmif =3D get_tpmif(tpmcmd->domid, tpmcmd->handle);
+   if(tpmif =3D=3D NULL) {
+      TPMBACK_ERR("Tried to send a reponse to non existant frontend
%u/%u\n", (unsigned int) tpmcmd->domid, tpmcmd->handle);
+      goto end;
+   }
+
+   if(!(tpmif->flags & TPMIF_REQ_READY)) {
+      TPMBACK_ERR("Tried to send response to a frontend that was not
waiting for one %u/%u\n", (unsigned int) tpmcmd->domid, tpmcmd->handle);
+      goto end;
+   }
+
+   /* Send response to frontend */
+   send_response(tpmcmd, tpmif);
+
+end:
+   if(tpmcmd->req !=3D NULL) {
+      free(tpmcmd->req);
+   }
+   free(tpmcmd);
+   return;
+}
+
+int tpmback_wait_for_frontend_connect(domid_t *domid, unsigned int *hand=
le)
+{
+   tpmif_t* tpmif;
+   int flags;
+   wait_event(waitq, ((gtpmdev.num_tpms > 0) || gtpmdev.flags &
TPMIF_CLOSED));
+   if(gtpmdev.flags & TPMIF_CLOSED) {
+      return -1;
+   }
+   local_irq_save(flags);
+   tpmif =3D gtpmdev.tpmlist[0];
+   *domid =3D tpmif->domid;
+   *handle =3D tpmif->handle;
+   local_irq_restore(flags);
+
+   return 0;
+}
+
+int tpmback_num_frontends(void)
+{
+   return gtpmdev.num_tpms;
+}
diff --git a/extras/mini-os/tpmfront.c b/extras/mini-os/tpmfront.c
--- /dev/null
+++ b/extras/mini-os/tpmfront.c
@@ -0,0 +1,617 @@
+/*
+ * Copyright (c) 2010-2012 United States Government, as represented by
+ * the Secretary of Defense.  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 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 MERCHANTABILI=
TY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT
SHALL THE
+ * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHE=
R
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISI=
NG
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
DEALINGS
+ * IN THE SOFTWARE.
+ *
+ * Based upon the files:
+ *  drivers/char/tpm/tpm_vtpm.c
+ *  drivers/char/tpm/tpm_xen.c
+ * from the Linux kernel, which are Copyright (C) 2006 IBM Corporation
+ */
+#include <mini-os/os.h>
+#include <mini-os/xenbus.h>
+#include <mini-os/xmalloc.h>
+#include <mini-os/events.h>
+#include <mini-os/wait.h>
+#include <mini-os/gnttab.h>
+#include <xen/io/xenbus.h>
+#include <xen/io/tpmif.h>
+#include <mini-os/tpmfront.h>
+#include <fcntl.h>
+
+//#define TPMFRONT_PRINT_DEBUG
+#ifdef TPMFRONT_PRINT_DEBUG
+#define TPMFRONT_DEBUG(fmt,...) printk("Tpmfront:Debug("__FILE__":%d) "
fmt, __LINE__, ##__VA_ARGS__)
+#define TPMFRONT_DEBUG_MORE(fmt,...) printk(fmt, ##__VA_ARGS__)
+#else
+#define TPMFRONT_DEBUG(fmt,...)
+#endif
+#define TPMFRONT_ERR(fmt,...) printk("Tpmfront:Error " fmt, ##__VA_ARGS_=
_)
+#define TPMFRONT_LOG(fmt,...) printk("Tpmfront:Info " fmt, ##__VA_ARGS__=
)
+
+#define min(a,b) (((a) < (b)) ? (a) : (b))
+
+void tpmfront_handler(evtchn_port_t port, struct pt_regs *regs, void
*data) {
+   struct tpmfront_dev* dev =3D (struct tpmfront_dev*) data;
+   /*If we get a response when we didnt make a request, just ignore it *=
/
+   if(!dev->waiting) {
+      return;
+   }
+
+   dev->waiting =3D 0;
+#ifdef HAVE_LIBC
+   if(dev->fd >=3D 0) {
+      files[dev->fd].read =3D 1;
+   }
+#endif
+   wake_up(&dev->waitq);
+}
+
+static int publish_xenbus(struct tpmfront_dev* dev) {
+   xenbus_transaction_t xbt;
+   int retry;
+   char* err;
+   /* Write the grant reference and event channel to xenstore */
+again:
+   if((err =3D xenbus_transaction_start(&xbt))) {
+      TPMFRONT_ERR("Unable to start xenbus transaction, error was
%s\n", err);
+      free(err);
+      return -1;
+   }
+
+   if((err =3D xenbus_printf(xbt, dev->nodename, "ring-ref", "%u",
(unsigned int) dev->ring_ref))) {
+      TPMFRONT_ERR("Unable to write %s/ring-ref, error was %s\n",
dev->nodename, err);
+      free(err);
+      goto abort_transaction;
+   }
+
+   if((err =3D xenbus_printf(xbt, dev->nodename, "event-channel", "%u",
(unsigned int) dev->evtchn))) {
+      TPMFRONT_ERR("Unable to write %s/event-channel, error was %s\n",
dev->nodename, err);
+      free(err);
+      goto abort_transaction;
+   }
+
+   if((err =3D xenbus_transaction_end(xbt, 0, &retry))) {
+      TPMFRONT_ERR("Unable to complete xenbus transaction, error was
%s\n", err);
+      free(err);
+      return -1;
+   }
+   if(retry) {
+      goto again;
+   }
+
+   return 0;
+abort_transaction:
+   if((err =3D xenbus_transaction_end(xbt, 1, &retry))) {
+      free(err);
+   }
+   return -1;
+}
+
+static int wait_for_backend_connect(xenbus_event_queue* events, char* pa=
th)
+{
+   int state;
+
+   TPMFRONT_LOG("Waiting for backend connection..\n");
+   /* Wait for the backend to connect */
+   while(1) {
+      state =3D xenbus_read_integer(path);
+      if ( state < 0)
+     state =3D XenbusStateUnknown;
+      switch(state) {
+     /* Bad states, we quit with error */
+     case XenbusStateUnknown:
+     case XenbusStateClosing:
+     case XenbusStateClosed:
+        TPMFRONT_ERR("Unable to connect to backend\n");
+        return -1;
+     /* If backend is connected then break out of loop */
+     case XenbusStateConnected:
+        TPMFRONT_LOG("Backend Connected\n");
+        return 0;
+     default:
+        xenbus_wait_for_watch(events);
+      }
+   }
+
+}
+
+static int wait_for_backend_closed(xenbus_event_queue* events, char* pat=
h)
+{
+   int state;
+
+   TPMFRONT_LOG("Waiting for backend to close..\n");
+   while(1) {
+      state =3D xenbus_read_integer(path);
+      if ( state < 0)
+     state =3D XenbusStateUnknown;
+      switch(state) {
+     case XenbusStateUnknown:
+        TPMFRONT_ERR("Backend Unknown state, forcing shutdown\n");
+        return -1;
+     case XenbusStateClosed:
+        TPMFRONT_LOG("Backend Closed\n");
+        return 0;
+     default:
+        xenbus_wait_for_watch(events);
+      }
+   }
+
+}
+
+static int wait_for_backend_state_changed(struct tpmfront_dev* dev,
XenbusState state) {
+   char* err;
+   int ret =3D 0;
+   xenbus_event_queue events =3D NULL;
+   char path[512];
+
+   snprintf(path, 512, "%s/state", dev->bepath);
+   /*Setup the watch to wait for the backend */
+   if((err =3D xenbus_watch_path_token(XBT_NIL, path, path, &events))) {=

+      TPMFRONT_ERR("Could not set a watch on %s, error was %s\n", path,
err);
+      free(err);
+      return -1;
+   }
+
+   /* Do the actual wait loop now */
+   switch(state) {
+      case XenbusStateConnected:
+     ret =3D wait_for_backend_connect(&events, path);
+     break;
+      case XenbusStateClosed:
+     ret =3D wait_for_backend_closed(&events, path);
+     break;
+      default:
+     break;
+   }
+
+   if((err =3D xenbus_unwatch_path_token(XBT_NIL, path, path))) {
+      TPMFRONT_ERR("Unable to unwatch %s, error was %s, ignoring..\n",
path, err);
+      free(err);
+   }
+   return ret;
+}
+
+static int tpmfront_connect(struct tpmfront_dev* dev)
+{
+   char* err;
+   /* Create shared page */
+   dev->tx =3D (tpmif_tx_interface_t*) alloc_page();
+   if(dev->tx =3D=3D NULL) {
+      TPMFRONT_ERR("Unable to allocate page for shared memory\n");
+      goto error;
+   }
+   memset(dev->tx, 0, PAGE_SIZE);
+   dev->ring_ref =3D gnttab_grant_access(dev->bedomid,
virt_to_mfn(dev->tx), 0);
+   TPMFRONT_DEBUG("grant ref is %lu\n", (unsigned long) dev->ring_ref);
+
+   /*Create event channel */
+   if(evtchn_alloc_unbound(dev->bedomid, tpmfront_handler, dev,
&dev->evtchn)) {
+      TPMFRONT_ERR("Unable to allocate event channel\n");
+      goto error_postmap;
+   }
+   unmask_evtchn(dev->evtchn);
+   TPMFRONT_DEBUG("event channel is %lu\n", (unsigned long) dev->evtchn)=
;
+
+   /* Write the entries to xenstore */
+   if(publish_xenbus(dev)) {
+      goto error_postevtchn;
+   }
+
+   /* Change state to connected */
+   dev->state =3D XenbusStateConnected;
+
+   /* Tell the backend that we are ready */
+   if((err =3D xenbus_printf(XBT_NIL, dev->nodename, "state", "%u",
dev->state))) {
+      TPMFRONT_ERR("Unable to write to xenstore %s/state, value=3D%u",
dev->nodename, XenbusStateConnected);
+      free(err);
+      goto error;
+   }
+
+   return 0;
+error_postevtchn:
+      mask_evtchn(dev->evtchn);
+      unbind_evtchn(dev->evtchn);
+error_postmap:
+      gnttab_end_access(dev->ring_ref);
+      free_page(dev->tx);
+error:
+   return -1;
+}
+
+struct tpmfront_dev* init_tpmfront(const char* _nodename)
+{
+   struct tpmfront_dev* dev;
+   const char* nodename;
+   char path[512];
+   char* value, *err;
+   unsigned long long ival;
+   int i;
+
+   printk("=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Init TPM Front =3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D\n");
+
+   dev =3D malloc(sizeof(struct tpmfront_dev));
+   memset(dev, 0, sizeof(struct tpmfront_dev));
+
+#ifdef HAVE_LIBC
+   dev->fd =3D -1;
+#endif
+
+   nodename =3D _nodename ? _nodename : "device/vtpm/0";
+   dev->nodename =3D strdup(nodename);
+
+   init_waitqueue_head(&dev->waitq);
+
+   /* Get backend domid */
+   snprintf(path, 512, "%s/backend-id", dev->nodename);
+   if((err =3D xenbus_read(XBT_NIL, path, &value))) {
+      TPMFRONT_ERR("Unable to read %s during tpmfront initialization!
error =3D %s\n", path, err);
+      free(err);
+      goto error;
+   }
+   if(sscanf(value, "%llu", &ival) !=3D 1) {
+      TPMFRONT_ERR("%s has non-integer value (%s)\n", path, value);
+      free(value);
+      goto error;
+   }
+   free(value);
+   dev->bedomid =3D ival;
+
+   /* Get backend xenstore path */
+   snprintf(path, 512, "%s/backend", dev->nodename);
+   if((err =3D xenbus_read(XBT_NIL, path, &dev->bepath))) {
+      TPMFRONT_ERR("Unable to read %s during tpmfront initialization!
error =3D %s\n", path, err);
+      free(err);
+      goto error;
+   }
+
+   /* Create and publish grant reference and event channel */
+   if (tpmfront_connect(dev)) {
+      goto error;
+   }
+
+   /* Wait for backend to connect */
+   if( wait_for_backend_state_changed(dev, XenbusStateConnected)) {
+      goto error;
+   }
+
+   /* Allocate pages that will contain the messages */
+   dev->pages =3D malloc(sizeof(void*) * TPMIF_TX_RING_SIZE);
+   if(dev->pages =3D=3D NULL) {
+      goto error;
+   }
+   memset(dev->pages, 0, sizeof(void*) * TPMIF_TX_RING_SIZE);
+   for(i =3D 0; i < TPMIF_TX_RING_SIZE; ++i) {
+      dev->pages[i] =3D (void*)alloc_page();
+      if(dev->pages[i] =3D=3D NULL) {
+     goto error;
+      }
+   }
+
+   TPMFRONT_LOG("Initialization Completed successfully\n");
+
+   return dev;
+
+error:
+   shutdown_tpmfront(dev);
+   return NULL;
+}
+void shutdown_tpmfront(struct tpmfront_dev* dev)
+{
+   char* err;
+   char path[512];
+   int i;
+   tpmif_tx_request_t* tx;
+   if(dev =3D=3D NULL) {
+      return;
+   }
+   TPMFRONT_LOG("Shutting down tpmfront\n");
+   /* disconnect */
+   if(dev->state =3D=3D XenbusStateConnected) {
+      dev->state =3D XenbusStateClosing;
+      //FIXME: Transaction for this?
+      /* Tell backend we are closing */
+      if((err =3D xenbus_printf(XBT_NIL, dev->nodename, "state", "%u",
(unsigned int) dev->state))) {
+     free(err);
+      }
+
+      /* Clean up xenstore entries */
+      snprintf(path, 512, "%s/event-channel", dev->nodename);
+      if((err =3D xenbus_rm(XBT_NIL, path))) {
+     free(err);
+      }
+      snprintf(path, 512, "%s/ring-ref", dev->nodename);
+      if((err =3D xenbus_rm(XBT_NIL, path))) {
+     free(err);
+      }
+
+      /* Tell backend we are closed */
+      dev->state =3D XenbusStateClosed;
+      if((err =3D xenbus_printf(XBT_NIL, dev->nodename, "state", "%u",
(unsigned int) dev->state))) {
+     TPMFRONT_ERR("Unable to write to %s, error was %s", dev->nodename,
err);
+     free(err);
+      }
+
+      /* Wait for the backend to close and unmap shared pages, ignore
any errors */
+      wait_for_backend_state_changed(dev, XenbusStateClosed);
+
+      /* Cleanup any shared pages */
+      if(dev->pages) {
+     for(i =3D 0; i < TPMIF_TX_RING_SIZE; ++i) {
+        if(dev->pages[i]) {
+           tx =3D &dev->tx->ring[i].req;
+           if(tx->ref !=3D 0) {
+          gnttab_end_access(tx->ref);
+           }
+           free_page(dev->pages[i]);
+        }
+     }
+     free(dev->pages);
+      }
+
+      /* Close event channel and unmap shared page */
+      mask_evtchn(dev->evtchn);
+      unbind_evtchn(dev->evtchn);
+      gnttab_end_access(dev->ring_ref);
+
+      free_page(dev->tx);
+
+   }
+
+   /* Cleanup memory usage */
+   if(dev->respbuf) {
+      free(dev->respbuf);
+   }
+   if(dev->bepath) {
+      free(dev->bepath);
+   }
+   if(dev->nodename) {
+      free(dev->nodename);
+   }
+   free(dev);
+}
+
+int tpmfront_send(struct tpmfront_dev* dev, const uint8_t* msg, size_t
length)
+{
+   int i;
+   tpmif_tx_request_t* tx =3D NULL;
+   /* Error Checking */
+   if(dev =3D=3D NULL || dev->state !=3D XenbusStateConnected) {
+      TPMFRONT_ERR("Tried to send message through disconnected
frontend\n");
+      return -1;
+   }
+
+#ifdef TPMFRONT_PRINT_DEBUG
+   TPMFRONT_DEBUG("Sending Msg to backend size=3D%u", (unsigned int) len=
gth);
+   for(i =3D 0; i < length; ++i) {
+      if(!(i % 30)) {
+     TPMFRONT_DEBUG_MORE("\n");
+      }
+      TPMFRONT_DEBUG_MORE("%02X ", msg[i]);
+   }
+   TPMFRONT_DEBUG_MORE("\n");
+#endif
+
+   /* Copy to shared pages now */
+   for(i =3D 0; length > 0 && i < TPMIF_TX_RING_SIZE; ++i) {
+      /* Share the page */
+      tx =3D &dev->tx->ring[i].req;
+      tx->unused =3D 0;
+      tx->addr =3D virt_to_mach(dev->pages[i]);
+      tx->ref =3D gnttab_grant_access(dev->bedomid,
virt_to_mfn(dev->pages[i]), 0);
+      /* Copy the bits to the page */
+      tx->size =3D length > PAGE_SIZE ? PAGE_SIZE : length;
+      memcpy(dev->pages[i], &msg[i * PAGE_SIZE], tx->size);
+
+      /* Update counters */
+      length -=3D tx->size;
+   }
+   dev->waiting =3D 1;
+   dev->resplen =3D 0;
+#ifdef HAVE_LIBC
+   if(dev->fd >=3D 0) {
+      files[dev->fd].read =3D 0;
+      files[dev->fd].tpmfront.respgot =3D 0;
+      files[dev->fd].tpmfront.offset =3D 0;
+   }
+#endif
+   notify_remote_via_evtchn(dev->evtchn);
+   return 0;
+}
+int tpmfront_recv(struct tpmfront_dev* dev, uint8_t** msg, size_t *lengt=
h)
+{
+   tpmif_tx_request_t* tx;
+   int i;
+   if(dev =3D=3D NULL || dev->state !=3D XenbusStateConnected) {
+      TPMFRONT_ERR("Tried to receive message from disconnected
frontend\n");
+      return -1;
+   }
+   /*Wait for the response */
+   wait_event(dev->waitq, (!dev->waiting));
+
+   /* Initialize */
+   *msg =3D NULL;
+   *length =3D 0;
+
+   /* special case, just quit */
+   tx =3D &dev->tx->ring[0].req;
+   if(tx->size =3D=3D 0 ) {
+       goto quit;
+   }
+   /* Get the total size */
+   tx =3D &dev->tx->ring[0].req;
+   for(i =3D 0; i < TPMIF_TX_RING_SIZE && tx->size > 0; ++i) {
+      tx =3D &dev->tx->ring[i].req;
+      *length +=3D tx->size;
+   }
+   /* Alloc the buffer */
+   if(dev->respbuf) {
+      free(dev->respbuf);
+   }
+   *msg =3D dev->respbuf =3D malloc(*length);
+   dev->resplen =3D *length;
+   /* Copy the bits */
+   tx =3D &dev->tx->ring[0].req;
+   for(i =3D 0; i < TPMIF_TX_RING_SIZE && tx->size > 0; ++i) {
+      tx =3D &dev->tx->ring[i].req;
+      memcpy(&(*msg)[i * PAGE_SIZE], dev->pages[i], tx->size);
+      gnttab_end_access(tx->ref);
+      tx->ref =3D 0;
+   }
+#ifdef TPMFRONT_PRINT_DEBUG
+   TPMFRONT_DEBUG("Received response from backend size=3D%u", (unsigned
int) *length);
+   for(i =3D 0; i < *length; ++i) {
+      if(!(i % 30)) {
+     TPMFRONT_DEBUG_MORE("\n");
+      }
+      TPMFRONT_DEBUG_MORE("%02X ", (*msg)[i]);
+   }
+   TPMFRONT_DEBUG_MORE("\n");
+#endif
+#ifdef HAVE_LIBC
+   if(dev->fd >=3D 0) {
+      files[dev->fd].tpmfront.respgot =3D 1;
+   }
+#endif
+quit:
+   return 0;
+}
+
+int tpmfront_cmd(struct tpmfront_dev* dev, uint8_t* req, size_t reqlen,
uint8_t** resp, size_t* resplen)
+{
+   int rc;
+   if((rc =3D tpmfront_send(dev, req, reqlen))) {
+      return rc;
+   }
+   if((rc =3D tpmfront_recv(dev, resp, resplen))) {
+      return rc;
+   }
+
+   return 0;
+}
+
+#ifdef HAVE_LIBC
+#include <errno.h>
+int tpmfront_open(struct tpmfront_dev* dev)
+{
+   /* Silently prevent multiple opens */
+   if(dev->fd !=3D -1) {
+      return dev->fd;
+   }
+
+   dev->fd =3D alloc_fd(FTYPE_TPMFRONT);
+   printk("tpmfront_open(%s) -> %d\n", dev->nodename, dev->fd);
+   files[dev->fd].tpmfront.dev =3D dev;
+   files[dev->fd].tpmfront.offset =3D 0;
+   files[dev->fd].tpmfront.respgot =3D 0;
+   return dev->fd;
+}
+
+int tpmfront_posix_write(int fd, const uint8_t* buf, size_t count)
+{
+   int rc;
+   struct tpmfront_dev* dev;
+   dev =3D files[fd].tpmfront.dev;
+
+   if(count =3D=3D 0) {
+      return 0;
+   }
+
+   /* Return an error if we are already processing a command */
+   if(dev->waiting) {
+      errno =3D EINPROGRESS;
+      return -1;
+   }
+   /* Send the command now */
+   if((rc =3D tpmfront_send(dev, buf, count)) !=3D 0) {
+      errno =3D EIO;
+      return -1;
+   }
+   return count;
+}
+
+int tpmfront_posix_read(int fd, uint8_t* buf, size_t count)
+{
+   int rc;
+   uint8_t* dummybuf;
+   size_t dummysz;
+   struct tpmfront_dev* dev;
+
+   dev =3D files[fd].tpmfront.dev;
+
+   if(count =3D=3D 0) {
+      return 0;
+   }
+
+   /* get the response if we haven't already */
+   if(files[dev->fd].tpmfront.respgot =3D=3D 0) {
+      if ((rc =3D tpmfront_recv(dev, &dummybuf, &dummysz)) !=3D 0) {
+     errno =3D EIO;
+     return -1;
+      }
+   }
+
+   /* handle EOF case */
+   if(files[dev->fd].tpmfront.offset >=3D dev->resplen) {
+      return 0;
+   }
+
+   /* Compute the number of bytes and do the copy operation */
+   if((rc =3D min(count, dev->resplen - files[dev->fd].tpmfront.offset))=

!=3D 0) {
+      memcpy(buf, dev->respbuf + files[dev->fd].tpmfront.offset, rc);
+      files[dev->fd].tpmfront.offset +=3D rc;
+   }
+
+   return rc;
+}
+
+int tpmfront_posix_fstat(int fd, struct stat* buf)
+{
+   uint8_t* dummybuf;
+   size_t dummysz;
+   int rc;
+   struct tpmfront_dev* dev =3D files[fd].tpmfront.dev;
+
+   /* If we have a response waiting, then read it now from the backend
+    * so we can get its length*/
+   if(dev->waiting || (files[dev->fd].read =3D=3D 1 &&
!files[dev->fd].tpmfront.respgot)) {
+      if ((rc =3D tpmfront_recv(dev, &dummybuf, &dummysz)) !=3D 0) {
+     errno =3D EIO;
+     return -1;
+      }
+   }
+
+   buf->st_mode =3D O_RDWR;
+   buf->st_uid =3D 0;
+   buf->st_gid =3D 0;
+   buf->st_size =3D dev->resplen;
+   buf->st_atime =3D buf->st_mtime =3D buf->st_ctime =3D time(NULL);
+
+   return 0;
+}
+
+
+#endif





--------------ms050205000800020200090704
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIDyjCC
A8YwggMvoAMCAQICBD/xyf0wDQYJKoZIhvcNAQEFBQAwLzELMAkGA1UEBhMCVVMxDzANBgNV
BAoTBkpIVUFQTDEPMA0GA1UECxMGQklTRENBMB4XDTEwMDYxMTE4MjIwNloXDTEzMDYxMTE4
NTIwNlowZjELMAkGA1UEBhMCVVMxDzANBgNVBAoTBkpIVUFQTDEPMA0GA1UECxMGUGVvcGxl
MTUwFgYDVQQLEw9WUE5Hcm91cC1CSVNEQ0EwGwYDVQQDExRNYXR0aGV3IEUgRmlvcmF2YW50
ZTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAnpbwVSP6o1Nb5lcW7dd3yTo9iBJdi7qz
4nANOMFPK7JOy5npKN1iiousl28U/scUJES55gPwAWYJK3uVyQAsA4adgDKi5DoD1UHDQEwp
bY7iHLJeq0NPr4BqYNqnCFPbE6HC8zSJrr4qKn+gVUQT39SIFqdiIPJwZL8FYTRQ/zsCAwEA
AaOCAbYwggGyMAsGA1UdDwQEAwIHgDArBgNVHRAEJDAigA8yMDEwMDYxMTE4MjIwNlqBDzIw
MTIwNzE3MjI1MjA2WjAbBg0rBgEEAbMlCwMBAQEBBAoWCGZpb3JhbWUxMBsGDSsGAQQBsyUL
AwEBAQIEChIIMDAxMDQyNjEwWAYJYIZIAYb6ax4BBEsMSVRoZSBwcml2YXRlIGtleSBjb3Jy
ZXNwb25kaW5nIHRvIHRoaXMgY2VydGlmaWNhdGUgbWF5IGhhdmUgYmVlbiBleHBvcnRlZC4w
KAYDVR0RBCEwH4EdTWF0dGhldy5GaW9yYXZhbnRlQGpodWFwbC5lZHUwUgYDVR0fBEswSTBH
oEWgQ6RBMD8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJU0RD
QTEOMAwGA1UEAxMFQ1JMNTYwHwYDVR0jBBgwFoAUCDUpmxH52EU2CyWmF2EJMB1yqeswHQYD
VR0OBBYEFO6LYxg6r9wHZ+zdQtBHn1dZ/YTNMAkGA1UdEwQCMAAwGQYJKoZIhvZ9B0EABAww
ChsEVjcuMQMCBLAwDQYJKoZIhvcNAQEFBQADgYEAJO9HQh4YNChVLzuZqK5ARJARD8JoujGZ
fdo75quvg2jXFQe2sEjvLnxJZgm/pv8fdZakq48CWwjYHKuvIp7sDjTEsQfo+y7SpN/N2NvJ
WU5SqfK1VgYtNLRRoGJUB5Q1aZ+Dg95g3kqpyfpUMISJL8IKVLtJVfN4fggFVUYZ9wwxggGr
MIIBpwIBATA3MC8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJ
U0RDQQIEP/HJ/TAJBgUrDgMCGgUAoIHLMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ
KoZIhvcNAQkFMQ8XDTEyMDkxOTE0NTQ1NFowIwYJKoZIhvcNAQkEMRYEFILynlCFCVaA4ZOX
R2Nzw11fOh3JMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAK
BggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI
KoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEgYAjZhsYws+P6eRbgLEYB3HzX0A48iOqoJ5/
5RssUUEmsHhFURcAQf+EdWivn5v6J6g894cPTH9uMudRe6Zhybmy09y1boF4cHgORxIQxoSC
HKd+vF02A2ond2UN82cpUek2Sz7xG/zhBYmoKrAEiDDFtlcS9esKanOp5CjKttHGJgAAAAAA
AA==
--------------ms050205000800020200090704--


--===============0895186449901109436==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============0895186449901109436==--


From xen-devel-bounces@lists.xen.org Wed Sep 19 15:21:24 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Sep 2012 15:21: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 1TEM5D-0000jk-RW; Wed, 19 Sep 2012 15:20:59 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dan.magenheimer@oracle.com>) id 1TEM5B-0000jf-Ps
	for xen-devel@lists.xen.org; Wed, 19 Sep 2012 15:20:58 +0000
Received: from [85.158.139.211:36375] by server-12.bemta-5.messagelabs.com id
	ED/5C-22167-9D2E9505; Wed, 19 Sep 2012 15:20:57 +0000
X-Env-Sender: dan.magenheimer@oracle.com
X-Msg-Ref: server-12.tower-206.messagelabs.com!1348068054!18194568!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzUwOTQ4\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14282 invoked from network); 19 Sep 2012 15:20:56 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-12.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 19 Sep 2012 15:20: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 q8JFKqPR003251
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 19 Sep 2012 15:20:54 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
	q8JFKpXi010707
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 19 Sep 2012 15:20:51 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
	q8JFKp6v011356; Wed, 19 Sep 2012 10:20:51 -0500
MIME-Version: 1.0
Message-ID: <ca12f838-7419-4ab0-9ad5-2f9bd8978773@default>
Date: Wed, 19 Sep 2012 08:20:46 -0700 (PDT)
From: Dan Magenheimer <dan.magenheimer@oracle.com>
To: Zhenzhong Duan <zhenzhong.duan@oracle.com>, xen-devel@lists.xen.org
References: <2c58eb85-429e-4dc6-942b-f59414a6b399@default>
In-Reply-To: <2c58eb85-429e-4dc6-942b-f59414a6b399@default>
X-Priority: 3
X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.7  (607090) [OL
	12.0.6661.5003 (x86)]
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: Joe Jin <joe.jin@oracle.com>, JBeulich@suse.com,
	Konrad Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] Bump tmem pool version to 1 to fix restore issue
 when tmem 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

> From: Zhenzhong Duan
> Sent: Tuesday, September 18, 2012 9:07 PM
> To: xen-devel@lists.xen.org
> Cc: Konrad Wilk; Dan Magenheimer; Feng Jin; JBeulich@suse.com
> Subject: Bump tmem pool version to 1 to fix restore issue when tmem enabled
> 
> Restore fail when tmem enabled both in hypervisor and guest.
> This is due to spec version mismatch when restore a pool.
> 
> Signed-off-by: Zhenzhong Duan <zhenzhong.duan@oracle.com>

Thanks zduan!

I think this fix makes tmem fully functional again on xen-unstable.

Acked-by: Dan Magenheimer <dan.magenheimer@oracle.com>

> ---
> diff -r d1c3375c3f11 xen/common/tmem.c
> --- a/xen/common/tmem.c Mon Sep 17 21:12:21 2012 +0100
> +++ b/xen/common/tmem.c Wed Sep 19 10:28:05 2012 +0800
> @@ -2397,7 +2397,8 @@
>               break;
>           rc = (pool->persistent ? TMEM_POOL_PERSIST : 0) |
>                (pool->shared ? TMEM_POOL_SHARED : 0) |
> -              (pool->pageshift << TMEM_POOL_PAGESIZE_SHIFT);
> +              (pool->pageshift << TMEM_POOL_PAGESIZE_SHIFT) |
> +              (TMEM_SPEC_VERSION << TMEM_POOL_VERSION_SHIFT);
>          break;
>      case TMEMC_SAVE_GET_POOL_NPAGES:
>           if ( pool == NULL )
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 19 15:21:24 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Sep 2012 15:21: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 1TEM5D-0000jk-RW; Wed, 19 Sep 2012 15:20:59 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dan.magenheimer@oracle.com>) id 1TEM5B-0000jf-Ps
	for xen-devel@lists.xen.org; Wed, 19 Sep 2012 15:20:58 +0000
Received: from [85.158.139.211:36375] by server-12.bemta-5.messagelabs.com id
	ED/5C-22167-9D2E9505; Wed, 19 Sep 2012 15:20:57 +0000
X-Env-Sender: dan.magenheimer@oracle.com
X-Msg-Ref: server-12.tower-206.messagelabs.com!1348068054!18194568!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzUwOTQ4\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14282 invoked from network); 19 Sep 2012 15:20:56 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-12.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 19 Sep 2012 15:20: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 q8JFKqPR003251
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 19 Sep 2012 15:20:54 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
	q8JFKpXi010707
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 19 Sep 2012 15:20:51 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
	q8JFKp6v011356; Wed, 19 Sep 2012 10:20:51 -0500
MIME-Version: 1.0
Message-ID: <ca12f838-7419-4ab0-9ad5-2f9bd8978773@default>
Date: Wed, 19 Sep 2012 08:20:46 -0700 (PDT)
From: Dan Magenheimer <dan.magenheimer@oracle.com>
To: Zhenzhong Duan <zhenzhong.duan@oracle.com>, xen-devel@lists.xen.org
References: <2c58eb85-429e-4dc6-942b-f59414a6b399@default>
In-Reply-To: <2c58eb85-429e-4dc6-942b-f59414a6b399@default>
X-Priority: 3
X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.7  (607090) [OL
	12.0.6661.5003 (x86)]
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: Joe Jin <joe.jin@oracle.com>, JBeulich@suse.com,
	Konrad Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] Bump tmem pool version to 1 to fix restore issue
 when tmem 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

> From: Zhenzhong Duan
> Sent: Tuesday, September 18, 2012 9:07 PM
> To: xen-devel@lists.xen.org
> Cc: Konrad Wilk; Dan Magenheimer; Feng Jin; JBeulich@suse.com
> Subject: Bump tmem pool version to 1 to fix restore issue when tmem enabled
> 
> Restore fail when tmem enabled both in hypervisor and guest.
> This is due to spec version mismatch when restore a pool.
> 
> Signed-off-by: Zhenzhong Duan <zhenzhong.duan@oracle.com>

Thanks zduan!

I think this fix makes tmem fully functional again on xen-unstable.

Acked-by: Dan Magenheimer <dan.magenheimer@oracle.com>

> ---
> diff -r d1c3375c3f11 xen/common/tmem.c
> --- a/xen/common/tmem.c Mon Sep 17 21:12:21 2012 +0100
> +++ b/xen/common/tmem.c Wed Sep 19 10:28:05 2012 +0800
> @@ -2397,7 +2397,8 @@
>               break;
>           rc = (pool->persistent ? TMEM_POOL_PERSIST : 0) |
>                (pool->shared ? TMEM_POOL_SHARED : 0) |
> -              (pool->pageshift << TMEM_POOL_PAGESIZE_SHIFT);
> +              (pool->pageshift << TMEM_POOL_PAGESIZE_SHIFT) |
> +              (TMEM_SPEC_VERSION << TMEM_POOL_VERSION_SHIFT);
>          break;
>      case TMEMC_SAVE_GET_POOL_NPAGES:
>           if ( pool == NULL )
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 19 15:35:38 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Sep 2012 15: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 1TEMJ1-00011E-HL; Wed, 19 Sep 2012 15:35: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 1TEMJ0-000119-VB
	for xen-devel@lists.xen.org; Wed, 19 Sep 2012 15:35:15 +0000
Received: from [85.158.139.211:18521] by server-5.bemta-5.messagelabs.com id
	A8/3E-30514-136E9505; Wed, 19 Sep 2012 15:35:13 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-4.tower-206.messagelabs.com!1348068912!19211620!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3596 invoked from network); 19 Sep 2012 15:35:12 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-4.tower-206.messagelabs.com with SMTP;
	19 Sep 2012 15:35:12 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 19 Sep 2012 16:35:12 +0100
Message-Id: <505A024E020000780009C602@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 19 Sep 2012 16:35:10 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
References: <40b91bed1275b13e191f.1347550068@xdev.gridcentric.ca>
In-Reply-To: <40b91bed1275b13e191f.1347550068@xdev.gridcentric.ca>
Mime-Version: 1.0
Content-Disposition: inline
Cc: tim@xen.org, andres@gridcentric.ca, keir@xen.org, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] Extra check in grant table code for mapping
 of shared frame
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.09.12 at 17:27, Andres Lagar-Cavilla <andres@lagarcavilla.org> wrote:
> --- a/xen/common/grant_table.c
> +++ b/xen/common/grant_table.c
> @@ -649,9 +649,12 @@ __gnttab_map_grant_ref(
>      }
>      else if ( owner == rd || owner == dom_cow )
>      {
> -        if ( gnttab_host_mapping_get_page_type(op, ld, rd) &&
> -             !get_page_type(pg, PGT_writable_page) )
> -            goto could_not_pin;
> +        if ( gnttab_host_mapping_get_page_type(op, ld, rd) )
> +        {
> +            if ( (owner == dom_cow) ||
> +                 !get_page_type(pg, PGT_writable_page) )
> +                goto could_not_pin;
> +        }
>  
>          nr_gets++;
>          if ( op->flags & GNTMAP_host_map )

Isn't that only half of it, in that the error/unmap paths need to
also consider that get_page_type() wasn't called? There's
quite a few calls to gnttab_host_mapping_get_page_type()/
put_page_type() sequences there.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 19 15:35:38 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Sep 2012 15: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 1TEMJ1-00011E-HL; Wed, 19 Sep 2012 15:35: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 1TEMJ0-000119-VB
	for xen-devel@lists.xen.org; Wed, 19 Sep 2012 15:35:15 +0000
Received: from [85.158.139.211:18521] by server-5.bemta-5.messagelabs.com id
	A8/3E-30514-136E9505; Wed, 19 Sep 2012 15:35:13 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-4.tower-206.messagelabs.com!1348068912!19211620!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3596 invoked from network); 19 Sep 2012 15:35:12 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-4.tower-206.messagelabs.com with SMTP;
	19 Sep 2012 15:35:12 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 19 Sep 2012 16:35:12 +0100
Message-Id: <505A024E020000780009C602@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 19 Sep 2012 16:35:10 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
References: <40b91bed1275b13e191f.1347550068@xdev.gridcentric.ca>
In-Reply-To: <40b91bed1275b13e191f.1347550068@xdev.gridcentric.ca>
Mime-Version: 1.0
Content-Disposition: inline
Cc: tim@xen.org, andres@gridcentric.ca, keir@xen.org, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] Extra check in grant table code for mapping
 of shared frame
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.09.12 at 17:27, Andres Lagar-Cavilla <andres@lagarcavilla.org> wrote:
> --- a/xen/common/grant_table.c
> +++ b/xen/common/grant_table.c
> @@ -649,9 +649,12 @@ __gnttab_map_grant_ref(
>      }
>      else if ( owner == rd || owner == dom_cow )
>      {
> -        if ( gnttab_host_mapping_get_page_type(op, ld, rd) &&
> -             !get_page_type(pg, PGT_writable_page) )
> -            goto could_not_pin;
> +        if ( gnttab_host_mapping_get_page_type(op, ld, rd) )
> +        {
> +            if ( (owner == dom_cow) ||
> +                 !get_page_type(pg, PGT_writable_page) )
> +                goto could_not_pin;
> +        }
>  
>          nr_gets++;
>          if ( op->flags & GNTMAP_host_map )

Isn't that only half of it, in that the error/unmap paths need to
also consider that get_page_type() wasn't called? There's
quite a few calls to gnttab_host_mapping_get_page_type()/
put_page_type() sequences there.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 19 15:49:27 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Sep 2012 15:49:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TEMWQ-0001BH-Ur; Wed, 19 Sep 2012 15:49:06 +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 1TEMWP-0001BC-Um
	for xen-devel@lists.xen.org; Wed, 19 Sep 2012 15:49:06 +0000
Received: from [85.158.143.99:51352] by server-3.bemta-4.messagelabs.com id
	A1/64-10986-179E9505; Wed, 19 Sep 2012 15:49:05 +0000
X-Env-Sender: dan.magenheimer@oracle.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1348069743!30409639!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzUwOTQ4\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5509 invoked from network); 19 Sep 2012 15:49:04 -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; 19 Sep 2012 15:49:04 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q8JFmt8I005913
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 19 Sep 2012 15:48:56 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
	q8JFmsop029344
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 19 Sep 2012 15:48:55 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
	q8JFmswM002425; Wed, 19 Sep 2012 10:48:54 -0500
MIME-Version: 1.0
Message-ID: <cc71cf29-4505-4acf-ac37-5190ce30451b@default>
Date: Wed, 19 Sep 2012 08:48:49 -0700 (PDT)
From: Dan Magenheimer <dan.magenheimer@oracle.com>
To: xen-devel@lists.xen.org
X-Priority: 3
X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.7  (607090) [OL
	12.0.6661.5003 (x86)]
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: Ian Campbell <ian.campbell@citrix.com>,
	Konrad Wilk <konrad.wilk@oracle.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, tim@xen.org,
	Zhenzhong Duan <zhenzhong.duan@oracle.com>, JBeulich@suse.com
Subject: [Xen-devel] tmem/XSA-15 backport?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Once zduan's tmem restore fix is applied, all known
tmem security issues have been resolved and tested
and tmem is fully functional again in xen-unstable,
including save/restore.

I'd like to recommend that all tmem patches be backported
to 4.1-stable and 4.2-stable prior to the next
point release and preferably asap.

Auditing activities are being conducted separately under
Konrad's supervision, but it seems wise to apply known
security patches to released trees before any users/distros
update.

Comments or objections?

Thanks,
Dan

P.S. Some work remains for tmem to always work properly
with "xl create" but "xm create" works fine.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 19 15:49:27 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Sep 2012 15:49:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TEMWQ-0001BH-Ur; Wed, 19 Sep 2012 15:49:06 +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 1TEMWP-0001BC-Um
	for xen-devel@lists.xen.org; Wed, 19 Sep 2012 15:49:06 +0000
Received: from [85.158.143.99:51352] by server-3.bemta-4.messagelabs.com id
	A1/64-10986-179E9505; Wed, 19 Sep 2012 15:49:05 +0000
X-Env-Sender: dan.magenheimer@oracle.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1348069743!30409639!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzUwOTQ4\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5509 invoked from network); 19 Sep 2012 15:49:04 -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; 19 Sep 2012 15:49:04 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q8JFmt8I005913
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 19 Sep 2012 15:48:56 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
	q8JFmsop029344
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 19 Sep 2012 15:48:55 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
	q8JFmswM002425; Wed, 19 Sep 2012 10:48:54 -0500
MIME-Version: 1.0
Message-ID: <cc71cf29-4505-4acf-ac37-5190ce30451b@default>
Date: Wed, 19 Sep 2012 08:48:49 -0700 (PDT)
From: Dan Magenheimer <dan.magenheimer@oracle.com>
To: xen-devel@lists.xen.org
X-Priority: 3
X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.7  (607090) [OL
	12.0.6661.5003 (x86)]
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: Ian Campbell <ian.campbell@citrix.com>,
	Konrad Wilk <konrad.wilk@oracle.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, tim@xen.org,
	Zhenzhong Duan <zhenzhong.duan@oracle.com>, JBeulich@suse.com
Subject: [Xen-devel] tmem/XSA-15 backport?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Once zduan's tmem restore fix is applied, all known
tmem security issues have been resolved and tested
and tmem is fully functional again in xen-unstable,
including save/restore.

I'd like to recommend that all tmem patches be backported
to 4.1-stable and 4.2-stable prior to the next
point release and preferably asap.

Auditing activities are being conducted separately under
Konrad's supervision, but it seems wise to apply known
security patches to released trees before any users/distros
update.

Comments or objections?

Thanks,
Dan

P.S. Some work remains for tmem to always work properly
with "xl create" but "xm create" works fine.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 19 16:00:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Sep 2012 16: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 1TEMhL-0001kE-4O; Wed, 19 Sep 2012 16:00:23 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1TEMhJ-0001k9-5I
	for xen-devel@lists.xen.org; Wed, 19 Sep 2012 16:00:21 +0000
Received: from [85.158.137.99:27805] by server-8.bemta-3.messagelabs.com id
	25/56-24700-41CE9505; Wed, 19 Sep 2012 16:00:20 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-217.messagelabs.com!1348070419!18346021!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27256 invoked from network); 19 Sep 2012 16:00:19 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-10.tower-217.messagelabs.com with SMTP;
	19 Sep 2012 16:00:19 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 19 Sep 2012 17:00:18 +0100
Message-Id: <505A0832020000780009C61E@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 19 Sep 2012 17:00:18 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Dan Magenheimer" <dan.magenheimer@oracle.com>
References: <cc71cf29-4505-4acf-ac37-5190ce30451b@default>
In-Reply-To: <cc71cf29-4505-4acf-ac37-5190ce30451b@default>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Keir Fraser <keir@xen.org>, Ian Campbell <ian.campbell@citrix.com>,
	Konrad Wilk <konrad.wilk@oracle.com>, tim@xen.org,
	IanJackson <Ian.Jackson@eu.citrix.com>,
	Zhenzhong Duan <zhenzhong.duan@oracle.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] tmem/XSA-15 backport?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 19.09.12 at 17:48, Dan Magenheimer <dan.magenheimer@oracle.com> wrote:
> I'd like to recommend that all tmem patches be backported
> to 4.1-stable and 4.2-stable prior to the next
> point release and preferably asap.
> 
> Auditing activities are being conducted separately under
> Konrad's supervision, but it seems wise to apply known
> security patches to released trees before any users/distros
> update.
> 
> Comments or objections?

My recollection is that the committers more or less agreed to
consider backports only once the full audit was done, and we
were assured that no further vulnerabilities are to be
expected. But I'm certainly open to weakening that position
if others prefer going that route.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 19 16:00:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Sep 2012 16: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 1TEMhL-0001kE-4O; Wed, 19 Sep 2012 16:00:23 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1TEMhJ-0001k9-5I
	for xen-devel@lists.xen.org; Wed, 19 Sep 2012 16:00:21 +0000
Received: from [85.158.137.99:27805] by server-8.bemta-3.messagelabs.com id
	25/56-24700-41CE9505; Wed, 19 Sep 2012 16:00:20 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-217.messagelabs.com!1348070419!18346021!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27256 invoked from network); 19 Sep 2012 16:00:19 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-10.tower-217.messagelabs.com with SMTP;
	19 Sep 2012 16:00:19 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 19 Sep 2012 17:00:18 +0100
Message-Id: <505A0832020000780009C61E@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 19 Sep 2012 17:00:18 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Dan Magenheimer" <dan.magenheimer@oracle.com>
References: <cc71cf29-4505-4acf-ac37-5190ce30451b@default>
In-Reply-To: <cc71cf29-4505-4acf-ac37-5190ce30451b@default>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Keir Fraser <keir@xen.org>, Ian Campbell <ian.campbell@citrix.com>,
	Konrad Wilk <konrad.wilk@oracle.com>, tim@xen.org,
	IanJackson <Ian.Jackson@eu.citrix.com>,
	Zhenzhong Duan <zhenzhong.duan@oracle.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] tmem/XSA-15 backport?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 19.09.12 at 17:48, Dan Magenheimer <dan.magenheimer@oracle.com> wrote:
> I'd like to recommend that all tmem patches be backported
> to 4.1-stable and 4.2-stable prior to the next
> point release and preferably asap.
> 
> Auditing activities are being conducted separately under
> Konrad's supervision, but it seems wise to apply known
> security patches to released trees before any users/distros
> update.
> 
> Comments or objections?

My recollection is that the committers more or less agreed to
consider backports only once the full audit was done, and we
were assured that no further vulnerabilities are to be
expected. But I'm certainly open to weakening that position
if others prefer going that route.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 19 16:05:37 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Sep 2012 16:05: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 1TEMm4-0001tm-4I; Wed, 19 Sep 2012 16:05:16 +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 1TEMm2-0001tH-F9
	for xen-devel@lists.xen.org; Wed, 19 Sep 2012 16:05:14 +0000
Received: from [85.158.139.83:18030] by server-4.bemta-5.messagelabs.com id
	01/81-23042-93DE9505; Wed, 19 Sep 2012 16:05:13 +0000
X-Env-Sender: lars.kurth.xen@gmail.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1348070710!30908264!1
X-Originating-IP: [209.85.212.45]
X-SpamReason: No, hits=0.9 required=7.0 tests=HTML_40_50,HTML_MESSAGE,
	RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27776 invoked from network); 19 Sep 2012 16:05:11 -0000
Received: from mail-vb0-f45.google.com (HELO mail-vb0-f45.google.com)
	(209.85.212.45)
	by server-5.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Sep 2012 16:05:11 -0000
Received: by vbip1 with SMTP id p1so1680774vbi.32
	for <multiple recipients>; Wed, 19 Sep 2012 09:05:09 -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=jntIgkVlvCEDH4f+xVZ4PX0SpX0DBEPD8Jo6+5W6oP8=;
	b=C8HIxbRAg32B3/SM7TuogTZod1PnWsHvv7mhQmispJE9htfdJWVBBtUnGzYJiaS7dw
	G4H5RPKO+qpLHxMJI0gCtF2zjOM/4xzMAfko3p+sG/xaHWxVCumybX73KR01225do+Qy
	7B14GPkGroKa+Lu9Hr1nZ31evouhPSaHIroyUPyomYRMHZ4KeE/5Xccny+wH9QGqzYZB
	u278t79/H2GfbdedIrFHQ3oGM5hGshC4nH8EwmOWfobzYvmnbhaTmlgTCeQ+ihTmoe34
	6BAij0mwiJmPWPrGEsuX/sP2/fO6Asub+8u2SM1kX4KorNfK4RQUhbrdaZzfb5vjJO8i
	Nw8w==
Received: by 10.221.2.76 with SMTP id nt12mr2183375vcb.12.1348070709689;
	Wed, 19 Sep 2012 09:05:09 -0700 (PDT)
Received: from [172.16.26.11] (firewall.ctxuk.citrix.com. [62.200.22.2])
	by mx.google.com with ESMTPS id j13sm564537vej.3.2012.09.19.09.05.06
	(version=SSLv3 cipher=OTHER); Wed, 19 Sep 2012 09:05:08 -0700 (PDT)
Message-ID: <5059ED2F.9080507@xen.org>
Date: Wed, 19 Sep 2012 17:05:03 +0100
From: Lars Kurth <lars.kurth@xen.org>
User-Agent: Mozilla/5.0 (Windows NT 6.1;
	rv:15.0) Gecko/20120907 Thunderbird/15.0.1
MIME-Version: 1.0
To: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>, 
	xen-users@lists.xen.org, "xen-api@lists.xen.org" <xen-api@lists.xen.org>,
	xen-arm@lists.xen.org
Subject: [Xen-devel] Xen Document Day: Sept 24th,
	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-Type: multipart/mixed; boundary="===============8022508016849475690=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a multi-part message in MIME format.
--===============8022508016849475690==
Content-Type: multipart/alternative;
 boundary="------------060509060401040904060408"

This is a multi-part message in MIME format.
--------------060509060401040904060408
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Hi,

everybody. A quick reminder that the next Xen Document Day is 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. I just cleaned up the list 
in preparation for Monday.

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!

--------------060509060401040904060408
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">
    <div class="moz-text-flowed" style="font-family: -moz-fixed;
      font-size: 14px;" lang="x-western">Hi,
      <br>
      <br>
      everybody. A quick reminder that the next Xen Document Day is
      happening next Monday. More info on document days at <a
        class="moz-txt-link-freetext"
        href="http://wiki.xen.org/wiki/Xen_Document_Days">http://wiki.xen.org/wiki/Xen_Document_Days</a>
      <br>
      <br>
      Hope to see you on IRC! Feel free to add stuff to the TODO list (<a
        class="moz-txt-link-freetext"
        href="http://wiki.xen.org/wiki/Xen_Document_Days/TODO">http://wiki.xen.org/wiki/Xen_Document_Days/TODO</a>)
      or put your name besides an item if you intend to work on it. I
      just cleaned up the list in preparation for Monday.
      <br>
      <br>
      Best Regards
      <br>
      Lars
      <br>
      <br>
      *********************
      <br>
      * Xen Document Days *
      <br>
      *********************
      <br>
      <br>
      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!
      <br>
      <br>
      For a list of items that need work, check out the community
      maintained TODO list (<a class="moz-txt-link-freetext"
        href="http://wiki.xen.org/wiki/Xen_Document_Days/TODO">http://wiki.xen.org/wiki/Xen_Document_Days/TODO</a>).
      Of course, you can work on anything you like: the list just
      provides suggestions.
      <br>
      <br>
      How do I participate?
      <br>
      =====================
      <br>
      <br>
      - Join us on IRC: freenode channel #xendocs
      <br>
      - Tell people what you intend to work on (to avoid doing something
      somebody
      <br>
      &nbsp; else is already working on)
      <br>
      - Fix some documentation
      <br>
      - Help others
      <br>
      - And above all: have fun!
      <br>
    </div>
  </body>
</html>

--------------060509060401040904060408--


--===============8022508016849475690==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============8022508016849475690==--


From xen-devel-bounces@lists.xen.org Wed Sep 19 16:05:37 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Sep 2012 16:05: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 1TEMm4-0001tm-4I; Wed, 19 Sep 2012 16:05:16 +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 1TEMm2-0001tH-F9
	for xen-devel@lists.xen.org; Wed, 19 Sep 2012 16:05:14 +0000
Received: from [85.158.139.83:18030] by server-4.bemta-5.messagelabs.com id
	01/81-23042-93DE9505; Wed, 19 Sep 2012 16:05:13 +0000
X-Env-Sender: lars.kurth.xen@gmail.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1348070710!30908264!1
X-Originating-IP: [209.85.212.45]
X-SpamReason: No, hits=0.9 required=7.0 tests=HTML_40_50,HTML_MESSAGE,
	RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27776 invoked from network); 19 Sep 2012 16:05:11 -0000
Received: from mail-vb0-f45.google.com (HELO mail-vb0-f45.google.com)
	(209.85.212.45)
	by server-5.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Sep 2012 16:05:11 -0000
Received: by vbip1 with SMTP id p1so1680774vbi.32
	for <multiple recipients>; Wed, 19 Sep 2012 09:05:09 -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=jntIgkVlvCEDH4f+xVZ4PX0SpX0DBEPD8Jo6+5W6oP8=;
	b=C8HIxbRAg32B3/SM7TuogTZod1PnWsHvv7mhQmispJE9htfdJWVBBtUnGzYJiaS7dw
	G4H5RPKO+qpLHxMJI0gCtF2zjOM/4xzMAfko3p+sG/xaHWxVCumybX73KR01225do+Qy
	7B14GPkGroKa+Lu9Hr1nZ31evouhPSaHIroyUPyomYRMHZ4KeE/5Xccny+wH9QGqzYZB
	u278t79/H2GfbdedIrFHQ3oGM5hGshC4nH8EwmOWfobzYvmnbhaTmlgTCeQ+ihTmoe34
	6BAij0mwiJmPWPrGEsuX/sP2/fO6Asub+8u2SM1kX4KorNfK4RQUhbrdaZzfb5vjJO8i
	Nw8w==
Received: by 10.221.2.76 with SMTP id nt12mr2183375vcb.12.1348070709689;
	Wed, 19 Sep 2012 09:05:09 -0700 (PDT)
Received: from [172.16.26.11] (firewall.ctxuk.citrix.com. [62.200.22.2])
	by mx.google.com with ESMTPS id j13sm564537vej.3.2012.09.19.09.05.06
	(version=SSLv3 cipher=OTHER); Wed, 19 Sep 2012 09:05:08 -0700 (PDT)
Message-ID: <5059ED2F.9080507@xen.org>
Date: Wed, 19 Sep 2012 17:05:03 +0100
From: Lars Kurth <lars.kurth@xen.org>
User-Agent: Mozilla/5.0 (Windows NT 6.1;
	rv:15.0) Gecko/20120907 Thunderbird/15.0.1
MIME-Version: 1.0
To: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>, 
	xen-users@lists.xen.org, "xen-api@lists.xen.org" <xen-api@lists.xen.org>,
	xen-arm@lists.xen.org
Subject: [Xen-devel] Xen Document Day: Sept 24th,
	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-Type: multipart/mixed; boundary="===============8022508016849475690=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a multi-part message in MIME format.
--===============8022508016849475690==
Content-Type: multipart/alternative;
 boundary="------------060509060401040904060408"

This is a multi-part message in MIME format.
--------------060509060401040904060408
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Hi,

everybody. A quick reminder that the next Xen Document Day is 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. I just cleaned up the list 
in preparation for Monday.

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!

--------------060509060401040904060408
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">
    <div class="moz-text-flowed" style="font-family: -moz-fixed;
      font-size: 14px;" lang="x-western">Hi,
      <br>
      <br>
      everybody. A quick reminder that the next Xen Document Day is
      happening next Monday. More info on document days at <a
        class="moz-txt-link-freetext"
        href="http://wiki.xen.org/wiki/Xen_Document_Days">http://wiki.xen.org/wiki/Xen_Document_Days</a>
      <br>
      <br>
      Hope to see you on IRC! Feel free to add stuff to the TODO list (<a
        class="moz-txt-link-freetext"
        href="http://wiki.xen.org/wiki/Xen_Document_Days/TODO">http://wiki.xen.org/wiki/Xen_Document_Days/TODO</a>)
      or put your name besides an item if you intend to work on it. I
      just cleaned up the list in preparation for Monday.
      <br>
      <br>
      Best Regards
      <br>
      Lars
      <br>
      <br>
      *********************
      <br>
      * Xen Document Days *
      <br>
      *********************
      <br>
      <br>
      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!
      <br>
      <br>
      For a list of items that need work, check out the community
      maintained TODO list (<a class="moz-txt-link-freetext"
        href="http://wiki.xen.org/wiki/Xen_Document_Days/TODO">http://wiki.xen.org/wiki/Xen_Document_Days/TODO</a>).
      Of course, you can work on anything you like: the list just
      provides suggestions.
      <br>
      <br>
      How do I participate?
      <br>
      =====================
      <br>
      <br>
      - Join us on IRC: freenode channel #xendocs
      <br>
      - Tell people what you intend to work on (to avoid doing something
      somebody
      <br>
      &nbsp; else is already working on)
      <br>
      - Fix some documentation
      <br>
      - Help others
      <br>
      - And above all: have fun!
      <br>
    </div>
  </body>
</html>

--------------060509060401040904060408--


--===============8022508016849475690==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============8022508016849475690==--


From xen-devel-bounces@lists.xen.org Wed Sep 19 16:20:41 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Sep 2012 16:20:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TEN0S-0002UA-AB; Wed, 19 Sep 2012 16:20: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 1TEN0Q-0002U5-KY
	for xen-devel@lists.xensource.com; Wed, 19 Sep 2012 16:20:06 +0000
Received: from [85.158.139.211:34777] by server-1.bemta-5.messagelabs.com id
	93/CD-04809-5B0F9505; Wed, 19 Sep 2012 16:20:05 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-206.messagelabs.com!1348071604!19252959!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTAxNzU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24035 invoked from network); 19 Sep 2012 16:20:05 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Sep 2012 16:20:05 -0000
X-IronPort-AV: E=Sophos;i="4.80,450,1344211200"; d="scan'208";a="14637279"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Sep 2012 16:19: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.279.1; Wed, 19 Sep 2012 17:19: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 1TEN09-00052B-Rc;
	Wed, 19 Sep 2012 16:19:49 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1TEN09-00086E-KO;
	Wed, 19 Sep 2012 17:19:49 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-13812-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 19 Sep 2012 17:19:49 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13812: 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 13812 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13812/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore            fail   like 13809
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail like 13809
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail like 13809

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  7b045d43e59d
baseline version:
 xen                  d1c3375c3f11

------------------------------------------------------------
People who touched revisions under test:
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Jan Beulich <jbeulich@suse.com>
  Keir Fraser <keir@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-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-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-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-amd64-amd64-xl-win                                      fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=xen-unstable
+ revision=7b045d43e59d
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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 7b045d43e59d
+ branch=xen-unstable
+ revision=7b045d43e59d
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-unstable
+ '[' xxen = xlinux ']'
+ linuxbranch=linux
+ : master
+ : tested/2.6.39.x
+ . ap-common
++ : xen@xenbits.xensource.com
++ : http://xenbits.xen.org/hg/staging/xen-unstable.hg
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : xen@xenbits.xensource.com:git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.xen-unstable
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-unstable.git
++ : daily-cron.xen-unstable
+ TREE_LINUX=xen@xenbits.xensource.com:git/linux-pvops.git
+ TREE_QEMU_UPSTREAM=xen@xenbits.xensource.com:git/qemu-upstream-unstable.git
+ info_linux_tree xen-unstable
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/xen-unstable.hg
+ hg push -r 7b045d43e59d ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg
pushing to ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg
searching for changes
remote: adding changesets
remote: adding manifests
remote: adding file changes
remote: added 3 changesets with 3 changes to 3 files

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 19 16:20:41 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Sep 2012 16:20:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TEN0S-0002UA-AB; Wed, 19 Sep 2012 16:20: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 1TEN0Q-0002U5-KY
	for xen-devel@lists.xensource.com; Wed, 19 Sep 2012 16:20:06 +0000
Received: from [85.158.139.211:34777] by server-1.bemta-5.messagelabs.com id
	93/CD-04809-5B0F9505; Wed, 19 Sep 2012 16:20:05 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-206.messagelabs.com!1348071604!19252959!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTAxNzU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24035 invoked from network); 19 Sep 2012 16:20:05 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Sep 2012 16:20:05 -0000
X-IronPort-AV: E=Sophos;i="4.80,450,1344211200"; d="scan'208";a="14637279"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Sep 2012 16:19: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.279.1; Wed, 19 Sep 2012 17:19: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 1TEN09-00052B-Rc;
	Wed, 19 Sep 2012 16:19:49 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1TEN09-00086E-KO;
	Wed, 19 Sep 2012 17:19:49 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-13812-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 19 Sep 2012 17:19:49 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13812: 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 13812 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13812/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore            fail   like 13809
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail like 13809
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail like 13809

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  7b045d43e59d
baseline version:
 xen                  d1c3375c3f11

------------------------------------------------------------
People who touched revisions under test:
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Jan Beulich <jbeulich@suse.com>
  Keir Fraser <keir@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-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-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-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-amd64-amd64-xl-win                                      fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=xen-unstable
+ revision=7b045d43e59d
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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 7b045d43e59d
+ branch=xen-unstable
+ revision=7b045d43e59d
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-unstable
+ '[' xxen = xlinux ']'
+ linuxbranch=linux
+ : master
+ : tested/2.6.39.x
+ . ap-common
++ : xen@xenbits.xensource.com
++ : http://xenbits.xen.org/hg/staging/xen-unstable.hg
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : xen@xenbits.xensource.com:git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.xen-unstable
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-unstable.git
++ : daily-cron.xen-unstable
+ TREE_LINUX=xen@xenbits.xensource.com:git/linux-pvops.git
+ TREE_QEMU_UPSTREAM=xen@xenbits.xensource.com:git/qemu-upstream-unstable.git
+ info_linux_tree xen-unstable
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/xen-unstable.hg
+ hg push -r 7b045d43e59d ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg
pushing to ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg
searching for changes
remote: adding changesets
remote: adding manifests
remote: adding file changes
remote: added 3 changesets with 3 changes to 3 files

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 19 16:30:32 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Sep 2012 16: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 1TENAA-0002m1-R5; Wed, 19 Sep 2012 16:30:10 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <julien.grall@citrix.com>) id 1TENA8-0002lt-VL
	for xen-devel@lists.xen.org; Wed, 19 Sep 2012 16:30:09 +0000
Received: from [85.158.137.99:31947] by server-8.bemta-3.messagelabs.com id
	E4/46-24700-F03F9505; Wed, 19 Sep 2012 16:30:07 +0000
X-Env-Sender: julien.grall@citrix.com
X-Msg-Ref: server-7.tower-217.messagelabs.com!1348072205!13546895!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzA4ODY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5739 invoked from network); 19 Sep 2012 16:30:07 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-7.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Sep 2012 16:30:07 -0000
X-IronPort-AV: E=Sophos;i="4.80,450,1344211200"; d="scan'208";a="38373302"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Sep 2012 16:30:05 +0000
Received: from meteora.cam.xci-test.com (10.80.248.22) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 19 Sep 2012 12:30:04 -0400
From: Julien Grall <julien.grall@citrix.com>
To: xen-devel@lists.xen.org
Date: Wed, 19 Sep 2012 11:05:47 +0100
Message-ID: <1348049147-16752-1-git-send-email-julien.grall@citrix.com>
X-Mailer: git-send-email 1.7.2.5
MIME-Version: 1.0
Cc: Julien Grall <julien.grall@citrix.com>, Ian.Jackson@eu.citrix.com
Subject: [Xen-devel] [PATCH] libxenstore: filter watch events in libxenstore
	when we unwatch
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

XenStore puts in queued watch events via a thread and notifies the user.
Sometimes xs_unwatch is called before all related message is read. The use
case is non-threaded libevent, we have two event A and B:
    - Event A will destroy something and call xs_unwatch;
    - Event B is used to notify that a node has changed in XenStore.
As the event is called one by one, event A can be handled before event B.
So on next xs_watch_read the user could retrieve an unwatch token and
a segfault occured if the token store the pointer of the structure
(ie: "backend:0xcafe").

Signed-off-by: Julien Grall <julien.grall@citrix.com>
---
 tools/xenstore/xs.c |   41 ++++++++++++++++++++++++++++++++++++++++-
 1 files changed, 40 insertions(+), 1 deletions(-)

diff --git a/tools/xenstore/xs.c b/tools/xenstore/xs.c
index b951015..31aad14 100644
--- a/tools/xenstore/xs.c
+++ b/tools/xenstore/xs.c
@@ -855,14 +855,53 @@ char **xs_read_watch(struct xs_handle *h, unsigned int *num)
 bool xs_unwatch(struct xs_handle *h, const char *path, const char *token)
 {
 	struct iovec iov[2];
+	struct xs_stored_msg *msg, *tmsg;
+	bool res;
+	char *strings;
+	unsigned int num_strings, i;
+	char c;
 
 	iov[0].iov_base = (char *)path;
 	iov[0].iov_len = strlen(path) + 1;
 	iov[1].iov_base = (char *)token;
 	iov[1].iov_len = strlen(token) + 1;
 
-	return xs_bool(xs_talkv(h, XBT_NULL, XS_UNWATCH, iov,
+	res = xs_bool(xs_talkv(h, XBT_NULL, XS_UNWATCH, iov,
 				ARRAY_SIZE(iov), NULL));
+
+	/* Filter the watch list to remove potential message */
+	mutex_lock(&h->watch_mutex);
+
+	if (list_empty(&h->watch_list)) {
+		mutex_unlock(&h->watch_mutex);
+		return res;
+	}
+
+	list_for_each_entry_safe(msg, tmsg, &h->watch_list, list) {
+		assert(msg->hdr.type == XS_WATCH_EVENT);
+
+		strings = msg->body;
+		num_strings = xs_count_strings(strings, msg->hdr.len);
+
+		for (i = 0; i < num_strings; i++) {
+			if (i == XS_WATCH_TOKEN && !strcmp (token, strings)) {
+				list_del(&msg->list);
+				free(msg);
+				break;
+			}
+			strings = strings + strlen (strings) + 1;
+		}
+	}
+
+	/* Clear the pipe token if there are no more pending watches. */
+	if (list_empty(&h->watch_list) && (h->watch_pipe[0] != -1)) {
+		while (read(h->watch_pipe[0], &c, 1) != 1)
+			continue;
+	}
+
+	mutex_unlock(&h->watch_mutex);
+
+	return res;
 }
 
 /* Start a transaction: changes by others will not be seen during this
-- 
Julien Grall


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 19 16:30:32 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Sep 2012 16: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 1TENAA-0002m1-R5; Wed, 19 Sep 2012 16:30:10 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <julien.grall@citrix.com>) id 1TENA8-0002lt-VL
	for xen-devel@lists.xen.org; Wed, 19 Sep 2012 16:30:09 +0000
Received: from [85.158.137.99:31947] by server-8.bemta-3.messagelabs.com id
	E4/46-24700-F03F9505; Wed, 19 Sep 2012 16:30:07 +0000
X-Env-Sender: julien.grall@citrix.com
X-Msg-Ref: server-7.tower-217.messagelabs.com!1348072205!13546895!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzA4ODY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5739 invoked from network); 19 Sep 2012 16:30:07 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-7.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Sep 2012 16:30:07 -0000
X-IronPort-AV: E=Sophos;i="4.80,450,1344211200"; d="scan'208";a="38373302"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Sep 2012 16:30:05 +0000
Received: from meteora.cam.xci-test.com (10.80.248.22) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 19 Sep 2012 12:30:04 -0400
From: Julien Grall <julien.grall@citrix.com>
To: xen-devel@lists.xen.org
Date: Wed, 19 Sep 2012 11:05:47 +0100
Message-ID: <1348049147-16752-1-git-send-email-julien.grall@citrix.com>
X-Mailer: git-send-email 1.7.2.5
MIME-Version: 1.0
Cc: Julien Grall <julien.grall@citrix.com>, Ian.Jackson@eu.citrix.com
Subject: [Xen-devel] [PATCH] libxenstore: filter watch events in libxenstore
	when we unwatch
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

XenStore puts in queued watch events via a thread and notifies the user.
Sometimes xs_unwatch is called before all related message is read. The use
case is non-threaded libevent, we have two event A and B:
    - Event A will destroy something and call xs_unwatch;
    - Event B is used to notify that a node has changed in XenStore.
As the event is called one by one, event A can be handled before event B.
So on next xs_watch_read the user could retrieve an unwatch token and
a segfault occured if the token store the pointer of the structure
(ie: "backend:0xcafe").

Signed-off-by: Julien Grall <julien.grall@citrix.com>
---
 tools/xenstore/xs.c |   41 ++++++++++++++++++++++++++++++++++++++++-
 1 files changed, 40 insertions(+), 1 deletions(-)

diff --git a/tools/xenstore/xs.c b/tools/xenstore/xs.c
index b951015..31aad14 100644
--- a/tools/xenstore/xs.c
+++ b/tools/xenstore/xs.c
@@ -855,14 +855,53 @@ char **xs_read_watch(struct xs_handle *h, unsigned int *num)
 bool xs_unwatch(struct xs_handle *h, const char *path, const char *token)
 {
 	struct iovec iov[2];
+	struct xs_stored_msg *msg, *tmsg;
+	bool res;
+	char *strings;
+	unsigned int num_strings, i;
+	char c;
 
 	iov[0].iov_base = (char *)path;
 	iov[0].iov_len = strlen(path) + 1;
 	iov[1].iov_base = (char *)token;
 	iov[1].iov_len = strlen(token) + 1;
 
-	return xs_bool(xs_talkv(h, XBT_NULL, XS_UNWATCH, iov,
+	res = xs_bool(xs_talkv(h, XBT_NULL, XS_UNWATCH, iov,
 				ARRAY_SIZE(iov), NULL));
+
+	/* Filter the watch list to remove potential message */
+	mutex_lock(&h->watch_mutex);
+
+	if (list_empty(&h->watch_list)) {
+		mutex_unlock(&h->watch_mutex);
+		return res;
+	}
+
+	list_for_each_entry_safe(msg, tmsg, &h->watch_list, list) {
+		assert(msg->hdr.type == XS_WATCH_EVENT);
+
+		strings = msg->body;
+		num_strings = xs_count_strings(strings, msg->hdr.len);
+
+		for (i = 0; i < num_strings; i++) {
+			if (i == XS_WATCH_TOKEN && !strcmp (token, strings)) {
+				list_del(&msg->list);
+				free(msg);
+				break;
+			}
+			strings = strings + strlen (strings) + 1;
+		}
+	}
+
+	/* Clear the pipe token if there are no more pending watches. */
+	if (list_empty(&h->watch_list) && (h->watch_pipe[0] != -1)) {
+		while (read(h->watch_pipe[0], &c, 1) != 1)
+			continue;
+	}
+
+	mutex_unlock(&h->watch_mutex);
+
+	return res;
 }
 
 /* Start a transaction: changes by others will not be seen during this
-- 
Julien Grall


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 19 16:44:01 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Sep 2012 16:44:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TENNH-00030w-LZ; Wed, 19 Sep 2012 16:43:43 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <singapore.mr.teo.en.ming@gmail.com>)
	id 1TENNF-00030r-JJ
	for xen-devel@lists.xen.org; Wed, 19 Sep 2012 16:43:42 +0000
Received: from [85.158.143.35:18115] by server-1.bemta-4.messagelabs.com id
	F4/39-05684-C36F9505; Wed, 19 Sep 2012 16:43:40 +0000
X-Env-Sender: singapore.mr.teo.en.ming@gmail.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1348073014!15743053!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-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8473 invoked from network); 19 Sep 2012 16:43:36 -0000
Received: from mail-pb0-f45.google.com (HELO mail-pb0-f45.google.com)
	(209.85.160.45)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Sep 2012 16:43:36 -0000
Received: by pbbrp12 with SMTP id rp12so2940985pbb.32
	for <multiple recipients>; Wed, 19 Sep 2012 09:43:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=message-id:disposition-notification-to:date:from:user-agent
	:mime-version:to:subject:content-type;
	bh=NhAEaT4RaQ8zkEU7XpSw6qrmedYXSJI/PPxUpKjERxI=;
	b=PY64vJkQntPimOZfS+lN+Kc9Wdu9kNOYzaynZygyOix+/LXQ7f5uzDMHhsZ/8W/6wi
	/dd9Y3cnqR46x9GuSX0ecbVPok8fGdTmI5JcLvL3gL8DFGksVOE/750FE85+IFYg00MS
	JXYNHf6Ap7UAPsq5VL2eIlPYgdaO4pYTuSqjlnaisF3xVC+H2yLjnbnrSnlAhqtjplZe
	j+RnW+1Wv35p2lDtgtlDXxUJRjs4BHY9Hz/lwnRha5OPSw/JMw+Hsz9ZOkzaZDY2Nb/J
	ZEFiji9ByKzqLQkTgHaxwHhGDksSDYKMA242Iyb6suSp567j94rqZXLqdiRucI1IVmAt
	xASg==
Received: by 10.68.116.228 with SMTP id jz4mr8786686pbb.166.1348073014138;
	Wed, 19 Sep 2012 09:43:34 -0700 (PDT)
Received: from [192.168.1.2] (cm70.gamma203.maxonline.com.sg. [202.156.203.70])
	by mx.google.com with ESMTPS id b6sm984792paz.9.2012.09.19.09.43.31
	(version=SSLv3 cipher=OTHER); Wed, 19 Sep 2012 09:43:33 -0700 (PDT)
Message-ID: <5059F632.3050808@gmail.com>
Date: Thu, 20 Sep 2012 00:43:30 +0800
From: "Teo En Ming (Zhang Enming)" <singapore.mr.teo.en.ming@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
MIME-Version: 1.0
To: "xen-users@lists.xen.org" <xen-users@lists.xen.org>, 
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	'Teo En Ming' <teo.en.ming@gmail.com>
Content-Type: multipart/mixed; boundary="------------060301030907070908060303"
Subject: [Xen-devel] VGA Passthrough with Xen 4.3-unstable?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a multi-part message in MIME format.
--------------060301030907070908060303
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Dear All,

I have tried to apply VGA passthrough patches hosted at Jean David 
Techer's website to Xen 4.3-unstable. However, I cannot get VGA 
passthrough to work with Xen 4.3-unstable. Are the VGA passthrough 
patches hosted at David Techer's website incompatible with Xen 4.3-unstable?

This is David Techer's website: 
http://www.davidgis.fr/blog/index.php?2011/12/07/860-xen-42unstable-patches-for-vga-pass-through

I have also provided error logs in this email for troubleshooting purposes.

Please advise. Thank you very much.

-- 
Yours sincerely,

Mr. Teo En Ming (Zhang Enming)
Singapore


--------------060301030907070908060303
Content-Type: text/x-log;
 name="qemu-dm-Windows8.log"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename="qemu-dm-Windows8.log"

domid: 21
Strip off blktap sub-type prefix to /etc/xen/images/windows8.img (drv 'aio')
Using file /etc/xen/images/windows8.img in read-write mode
Strip off blktap sub-type prefix to /home/flyon/windows8.iso (drv 'aio')
Using file /home/flyon/windows8.iso in read-only mode
Watching /local/domain/0/device-model/21/logdirty/cmd
Watching /local/domain/0/device-model/21/command
Watching /local/domain/21/cpu
qemu_map_cache_init nr_buckets = 10000 size 4194304
shared page at pfn feffd
buffered io page at pfn feffb
Guest uuid = 40290d87-cbd9-4656-841b-ba3d95621163
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/21/xen_extended_power_mgmt): read error
medium change watch on `hdc' (index: 1): aio:/home/flyon/windows8.iso
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
Log-dirty: no command yet.
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
vcpu-set: watch node error.
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
xs_read(/local/domain/21/log-throttling): read error
qemu: ignoring not-understood drive `/local/domain/21/log-throttling'
medium change watch on `/local/domain/21/log-throttling' - unknown device, ignored
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
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.

--------------060301030907070908060303
Content-Type: text/plain;
 name="qemu-dm-Windows8.log.1"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename="qemu-dm-Windows8.log.1"

domid: 20
Strip off blktap sub-type prefix to /etc/xen/images/windows8.img (drv 'aio')
Using file /etc/xen/images/windows8.img in read-write mode
Strip off blktap sub-type prefix to /home/flyon/windows8.iso (drv 'aio')
Using file /home/flyon/windows8.iso in read-only mode
Watching /local/domain/0/device-model/20/logdirty/cmd
Watching /local/domain/0/device-model/20/command
Watching /local/domain/20/cpu
qemu_map_cache_init nr_buckets = 10000 size 4194304
shared page at pfn feffd
buffered io page at pfn feffb
Guest uuid = 4a77731a-8b25-4fd8-ac7c-f4d607784917
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/20/xen_extended_power_mgmt): read error
medium change watch on `hdc' (index: 1): aio:/home/flyon/windows8.iso
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
Log-dirty: no command yet.
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
vcpu-set: watch node error.
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
xs_read(/local/domain/20/log-throttling): read error
qemu: ignoring not-understood drive `/local/domain/20/log-throttling'
medium change watch on `/local/domain/20/log-throttling' - unknown device, ignored
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
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.
reset requested in cpu_handle_ioreq.
Issued domain 20 reboot

--------------060301030907070908060303
Content-Type: text/plain;
 name="qemu-dm-Windows8.log.2"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename="qemu-dm-Windows8.log.2"

domid: 19
Strip off blktap sub-type prefix to /etc/xen/images/windows8.img (drv 'aio')
Using file /etc/xen/images/windows8.img in read-write mode
Strip off blktap sub-type prefix to /home/flyon/windows8.iso (drv 'aio')
Using file /home/flyon/windows8.iso in read-only mode
Watching /local/domain/0/device-model/19/logdirty/cmd
Watching /local/domain/0/device-model/19/command
Watching /local/domain/19/cpu
qemu_map_cache_init nr_buckets = 10000 size 4194304
shared page at pfn feffd
buffered io page at pfn feffb
Guest uuid = e72e564f-812a-49dd-9c78-d76a957ebeab
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/19/xen_extended_power_mgmt): read error
medium change watch on `hdc' (index: 1): aio:/home/flyon/windows8.iso
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
Log-dirty: no command yet.
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
vcpu-set: watch node error.
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
xs_read(/local/domain/19/log-throttling): read error
qemu: ignoring not-understood drive `/local/domain/19/log-throttling'
medium change watch on `/local/domain/19/log-throttling' - unknown device, ignored
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
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.
reset requested in cpu_handle_ioreq.
Issued domain 19 reboot

--------------060301030907070908060303
Content-Type: text/plain;
 name="qemu-dm-Windows8.log.3"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename="qemu-dm-Windows8.log.3"

domid: 18
Strip off blktap sub-type prefix to /etc/xen/images/windows8.img (drv 'aio')
Using file /etc/xen/images/windows8.img in read-write mode
Strip off blktap sub-type prefix to /home/flyon/windows8.iso (drv 'aio')
Using file /home/flyon/windows8.iso in read-only mode
Watching /local/domain/0/device-model/18/logdirty/cmd
Watching /local/domain/0/device-model/18/command
Watching /local/domain/18/cpu
qemu_map_cache_init nr_buckets = 10000 size 4194304
shared page at pfn feffd
buffered io page at pfn feffb
Guest uuid = 54da941e-ff5f-4db6-919a-00579c8fccc3
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/18/xen_extended_power_mgmt): read error
medium change watch on `hdc' (index: 1): aio:/home/flyon/windows8.iso
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
Log-dirty: no command yet.
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
vcpu-set: watch node error.
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
xs_read(/local/domain/18/log-throttling): read error
qemu: ignoring not-understood drive `/local/domain/18/log-throttling'
medium change watch on `/local/domain/18/log-throttling' - unknown device, ignored
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
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.
reset requested in cpu_handle_ioreq.
Issued domain 18 reboot

--------------060301030907070908060303
Content-Type: text/plain;
 name="qemu-dm-Windows8.log.4"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename="qemu-dm-Windows8.log.4"

domid: 17
Strip off blktap sub-type prefix to /etc/xen/images/windows8.img (drv 'aio')
Using file /etc/xen/images/windows8.img in read-write mode
Strip off blktap sub-type prefix to /home/flyon/windows8.iso (drv 'aio')
Using file /home/flyon/windows8.iso in read-only mode
Watching /local/domain/0/device-model/17/logdirty/cmd
Watching /local/domain/0/device-model/17/command
Watching /local/domain/17/cpu
qemu_map_cache_init nr_buckets = 10000 size 4194304
shared page at pfn feffd
buffered io page at pfn feffb
Guest uuid = 467e63fb-1054-4b1e-bb58-0ac6a2fe77ef
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/17/xen_extended_power_mgmt): read error
medium change watch on `hdc' (index: 1): aio:/home/flyon/windows8.iso
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
Log-dirty: no command yet.
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
vcpu-set: watch node error.
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
xs_read(/local/domain/17/log-throttling): read error
qemu: ignoring not-understood drive `/local/domain/17/log-throttling'
medium change watch on `/local/domain/17/log-throttling' - unknown device, ignored
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
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.
reset requested in cpu_handle_ioreq.
Issued domain 17 reboot

--------------060301030907070908060303
Content-Type: text/plain;
 name="qemu-dm-Windows8.log.5"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename="qemu-dm-Windows8.log.5"

domid: 16
Strip off blktap sub-type prefix to /etc/xen/images/windows8.img (drv 'aio')
Using file /etc/xen/images/windows8.img in read-write mode
Strip off blktap sub-type prefix to /home/flyon/windows8.iso (drv 'aio')
Using file /home/flyon/windows8.iso in read-only mode
Watching /local/domain/0/device-model/16/logdirty/cmd
Watching /local/domain/0/device-model/16/command
Watching /local/domain/16/cpu
qemu_map_cache_init nr_buckets = 10000 size 4194304
shared page at pfn feffd
buffered io page at pfn feffb
Guest uuid = fbe85911-c17d-4b2d-9ae0-33b2211cb22f
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/16/xen_extended_power_mgmt): read error
medium change watch on `hdc' (index: 1): aio:/home/flyon/windows8.iso
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
Log-dirty: no command yet.
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
vcpu-set: watch node error.
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
xs_read(/local/domain/16/log-throttling): read error
qemu: ignoring not-understood drive `/local/domain/16/log-throttling'
medium change watch on `/local/domain/16/log-throttling' - unknown device, ignored
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
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.
reset requested in cpu_handle_ioreq.
Issued domain 16 reboot

--------------060301030907070908060303
Content-Type: text/plain;
 name="qemu-dm-Windows8.log.6"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename="qemu-dm-Windows8.log.6"

domid: 15
Strip off blktap sub-type prefix to /etc/xen/images/windows8.img (drv 'aio')
Using file /etc/xen/images/windows8.img in read-write mode
Strip off blktap sub-type prefix to /home/flyon/windows8.iso (drv 'aio')
Using file /home/flyon/windows8.iso in read-only mode
Watching /local/domain/0/device-model/15/logdirty/cmd
Watching /local/domain/0/device-model/15/command
Watching /local/domain/15/cpu
qemu_map_cache_init nr_buckets = 10000 size 4194304
shared page at pfn feffd
buffered io page at pfn feffb
Guest uuid = 6ffa0353-1b02-4747-87f6-e30cb6067a76
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/15/xen_extended_power_mgmt): read error
medium change watch on `hdc' (index: 1): aio:/home/flyon/windows8.iso
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
Log-dirty: no command yet.
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
vcpu-set: watch node error.
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
xs_read(/local/domain/15/log-throttling): read error
qemu: ignoring not-understood drive `/local/domain/15/log-throttling'
medium change watch on `/local/domain/15/log-throttling' - unknown device, ignored
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
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.
reset requested in cpu_handle_ioreq.
Issued domain 15 reboot

--------------060301030907070908060303
Content-Type: text/plain;
 name="qemu-dm-Windows8.log.7"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename="qemu-dm-Windows8.log.7"

domid: 14
Strip off blktap sub-type prefix to /etc/xen/images/windows8.img (drv 'aio')
Using file /etc/xen/images/windows8.img in read-write mode
Strip off blktap sub-type prefix to /home/flyon/windows8.iso (drv 'aio')
Using file /home/flyon/windows8.iso in read-only mode
Watching /local/domain/0/device-model/14/logdirty/cmd
Watching /local/domain/0/device-model/14/command
Watching /local/domain/14/cpu
qemu_map_cache_init nr_buckets = 10000 size 4194304
shared page at pfn feffd
buffered io page at pfn feffb
Guest uuid = 908cd1e3-59b3-41f3-88a9-6d846fdbb675
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/14/xen_extended_power_mgmt): read error
medium change watch on `hdc' (index: 1): aio:/home/flyon/windows8.iso
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
Log-dirty: no command yet.
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
vcpu-set: watch node error.
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
xs_read(/local/domain/14/log-throttling): read error
qemu: ignoring not-understood drive `/local/domain/14/log-throttling'
medium change watch on `/local/domain/14/log-throttling' - unknown device, ignored
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
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.
reset requested in cpu_handle_ioreq.
Issued domain 14 reboot

--------------060301030907070908060303
Content-Type: text/plain;
 name="qemu-dm-Windows8.log.8"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename="qemu-dm-Windows8.log.8"

domid: 13
Strip off blktap sub-type prefix to /etc/xen/images/windows8.img (drv 'aio')
Using file /etc/xen/images/windows8.img in read-write mode
Strip off blktap sub-type prefix to /home/flyon/windows8.iso (drv 'aio')
Using file /home/flyon/windows8.iso in read-only mode
Watching /local/domain/0/device-model/13/logdirty/cmd
Watching /local/domain/0/device-model/13/command
Watching /local/domain/13/cpu
qemu_map_cache_init nr_buckets = 10000 size 4194304
shared page at pfn feffd
buffered io page at pfn feffb
Guest uuid = 7a9ba58a-35c9-4ad3-af42-5f371268d141
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/13/xen_extended_power_mgmt): read error
medium change watch on `hdc' (index: 1): aio:/home/flyon/windows8.iso
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
Log-dirty: no command yet.
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
vcpu-set: watch node error.
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
xs_read(/local/domain/13/log-throttling): read error
qemu: ignoring not-understood drive `/local/domain/13/log-throttling'
medium change watch on `/local/domain/13/log-throttling' - unknown device, ignored
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
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.
reset requested in cpu_handle_ioreq.
Issued domain 13 reboot

--------------060301030907070908060303
Content-Type: text/plain;
 name="qemu-dm-Windows8.log.9"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename="qemu-dm-Windows8.log.9"

domid: 12
Strip off blktap sub-type prefix to /etc/xen/images/windows8.img (drv 'aio')
Using file /etc/xen/images/windows8.img in read-write mode
Strip off blktap sub-type prefix to /home/flyon/windows8.iso (drv 'aio')
Using file /home/flyon/windows8.iso in read-only mode
Watching /local/domain/0/device-model/12/logdirty/cmd
Watching /local/domain/0/device-model/12/command
Watching /local/domain/12/cpu
qemu_map_cache_init nr_buckets = 10000 size 4194304
shared page at pfn feffd
buffered io page at pfn feffb
Guest uuid = 3fdbe19b-2484-4f51-a781-45feccb66d65
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/12/xen_extended_power_mgmt): read error
medium change watch on `hdc' (index: 1): aio:/home/flyon/windows8.iso
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
Log-dirty: no command yet.
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
vcpu-set: watch node error.
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
xs_read(/local/domain/12/log-throttling): read error
qemu: ignoring not-understood drive `/local/domain/12/log-throttling'
medium change watch on `/local/domain/12/log-throttling' - unknown device, ignored
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
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.
reset requested in cpu_handle_ioreq.
Issued domain 12 reboot

--------------060301030907070908060303
Content-Type: text/plain;
 name="qemu-dm-Windows8.log.10"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename="qemu-dm-Windows8.log.10"

domid: 11
Strip off blktap sub-type prefix to /etc/xen/images/windows8.img (drv 'aio')
Using file /etc/xen/images/windows8.img in read-write mode
Strip off blktap sub-type prefix to /home/flyon/windows8.iso (drv 'aio')
Using file /home/flyon/windows8.iso in read-only mode
Watching /local/domain/0/device-model/11/logdirty/cmd
Watching /local/domain/0/device-model/11/command
Watching /local/domain/11/cpu
qemu_map_cache_init nr_buckets = 10000 size 4194304
shared page at pfn feffd
buffered io page at pfn feffb
Guest uuid = ce6cf88a-65c6-4bf2-ab37-6881a1909bb5
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/11/xen_extended_power_mgmt): read error
medium change watch on `hdc' (index: 1): aio:/home/flyon/windows8.iso
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
Log-dirty: no command yet.
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
vcpu-set: watch node error.
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
xs_read(/local/domain/11/log-throttling): read error
qemu: ignoring not-understood drive `/local/domain/11/log-throttling'
medium change watch on `/local/domain/11/log-throttling' - unknown device, ignored
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
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.
reset requested in cpu_handle_ioreq.
Issued domain 11 reboot

--------------060301030907070908060303
Content-Type: text/plain;
 name="Windows8.txt"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
 filename="Windows8.txt"

IyBYTCBkb21haW4gY29uZmlndXJhdGlvbiBmaWxlIGZvciBXaW5kb3dzIDggQ29uc3VtZXIg
UHJldmlldyA2NC1iaXQgRW5nbGlzaCBIVk0gZG9tVQ0KIyBQbGVhc2UgcmVmZXIgdG8gIm1h
biB4bC5jZmciIGZvciBmdXJ0aGVyIGV4cGxhbmF0aW9ucy4NCiMgU2VlIGFsc28gZG9jcy9t
aXNjL3hsLW5ldHdvcmstY29uZmlndXJhdGlvbi5tYXJrZG93biBhbmQNCiMgZG9jcy9taXNj
L3hsLWRpc2stY29uZmlndXJhdGlvbi50eHQNCiMgV3JpdHRlbiBieSBUZW8gRW4gTWluZyAo
WmhhbmcgRW5taW5nKQ0KIyBFbWFpbDogdGVvLmVuLm1pbmdAZ21haWwuY29tDQojIE1vYmls
ZSBQaG9uZTogKzY1LTgzNjktMjYxOA0KIyBDb3VudHJ5OiBTaW5nYXBvcmUNCiMgRGF0ZTog
MTggTWFyIDIwMTIgU3VuDQpuYW1lPSJXaW5kb3dzOCINCiMgUHJvZHVjdCBLZXk6IFdKQlJY
LTJON0IyLUNDQkY2LVZQUDk3LVI4OFhWDQpidWlsZGVyPSJodm0iDQp2Y3B1cz0xMg0KbWVt
b3J5PTEyMDAwDQpvbl9wb3dlcm9mZj0iZGVzdHJveSINCm9uX3JlYm9vdD0icmVzdGFydCIN
Cm9uX2NyYXNoPSJkZXN0cm95Ig0KZGlzaz1bICdmb3JtYXQ9cmF3LCB2ZGV2PWhkYSwgYWNj
ZXNzPXJ3LCB0YXJnZXQ9L2V0Yy94ZW4vaW1hZ2VzL3dpbmRvd3M4LmltZycsICdmb3JtYXQ9
cmF3LCB2ZGV2PWhkYywgYWNjZXNzPXJvLCBkZXZ0eXBlPWNkcm9tLCB0YXJnZXQ9L2hvbWUv
Zmx5b24vd2luZG93czguaXNvJyBdDQp2aWY9WyAnYnJpZGdlPWV0aDAsdHlwZT1pb2VtdSxt
b2RlbD1lMTAwMCcgXQ0KI2Jvb3Q9W2N8ZHxuXQ0KIyBTZWxlY3RzIHRoZSBlbXVsYXRlZCB2
aXJ0dWFsIGRldmljZSB0byBib290IGZyb20uIE9wdGlvbnMgYXJlIGhhcmQgZGlzayAoYyks
IGNkLXJvbSAoZCkgb3IgbmV0d29yay9QWEUgKG4pLg0KIyBNdWx0aXBsZSBvcHRpb25zIGNh
biBiZSBnaXZlbiBhbmQgd2lsbCBiZSBhdHRlbXB0ZWQgaW4gdGhlIG9yZGVyIHRoZXkgYXJl
IGdpdmVuLiBlLmcuIHRvIGJvb3QgZnJvbSBjZC1yb20NCiMgYnV0IGZhbGxiYWNrIHRvIHRo
ZSBoYXJkIGRpc2sgeW91IGNhbiBnaXZlIGRjLiBUaGUgZGVmYXVsdCBpcyBjZC4NCmJvb3Q9
ImRjIg0KYWNwaT0xDQp4ZW5fcGxhdGZvcm1fcGNpPTENCnZpcmlkaWFuPTENCnN0ZHZnYT0x
DQoNCnZuYz0xDQp2bmNsaXN0ZW49IjE5Mi4xNjguMjUuNTAiDQp2bmNkaXNwbGF5PTANCnZu
Y3VudXNlZD0xDQp2bmNwYXNzd2Q9IiINCnNkbD0wDQp1c2I9MQ0KdXNiZGV2aWNlPSJ0YWJs
ZXQiDQojIEVuYWJsZSBYZW4gVkdBIFBhc3N0aHJvdWdoDQpnZnhfcGFzc3RocnU9MQ0KIyBW
R0EgUGFzc3Rocm91Z2ggTlZJRElBIFF1YWRybyA2MDAwDQpwY2kgPSBbICcwZDowMC4wJyBd
DQojIFBDSSBQYXNzdGhyb3VnaCBJbnRlbCBIRCBBdWRpbyBDb250cm9sbGVyLg0KI3BjaSA9
IFsgJzAwOjFiLjAnIF0NCiMgUENJIFBhc3N0aHJvdWdoIGFsbCB0aGUgVVNCIENvbnRyb2xs
ZXJzLg0KIyBwY2kgPSBbICcwMDoxYS4wJywnMDA6MWEuMScsJzAwOjFhLjInLCcwMDoxYS43
JywnMDA6MWQuMCcsJzAwOjFkLjEnLCcwMDoxZC4yJywnMDA6MWQuNycgXQ==
--------------060301030907070908060303
Content-Type: text/plain;
 name="xen1.txt"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
 filename="xen1.txt"

DQpbICAgIDIuNzI1MzE4XSBwY2kgMDAwMDowZDowMC4wOiByZWcgMTA6IFttZW0gMHhmODAw
MDAwMC0weGY5ZmZmZmZmXQ0KWyAgICAyLjcyNTMyOF0gcGNpIDAwMDA6MGQ6MDAuMDogcmVn
IDE0OiBbbWVtIDB4ZDgwMDAwMDAtMHhkZmZmZmZmZiA2NGJpdCBwcmVmXQ0KWyAgICAyLjcy
NTMzOF0gcGNpIDAwMDA6MGQ6MDAuMDogcmVnIDFjOiBbbWVtIDB4ZDQwMDAwMDAtMHhkN2Zm
ZmZmZiA2NGJpdCBwcmVmXQ0KWyAgICAyLjcyNTM1MV0gcGNpIDAwMDA6MGQ6MDAuMDogcmVn
IDMwOiBbbWVtIDB4MDAwMDAwMDAtMHgwMDA3ZmZmZiBwcmVmXQ0KWyAgICAyLjc2MzE1MF0g
cGNpIDAwMDA6MGQ6MDAuMDogQkFSIDY6IGFzc2lnbmVkIFttZW0gMHhmN2YwMDAwMC0weGY3
ZjdmZmZmIHByZWZdDQoNCjFzdCBtZW1vcnkgcmFuZ2UNCj09PT09PT09PT09PT09PT0NCg0K
bWF4ID0gMHhmOWZmZmZmZiA9IDQxOTQzMDM5OTkNCm1pbiA9IDB4ZjgwMDAwMDAgPSA0MTYw
NzQ5NTY4DQpkaWZmZXJlbmNlPW1heCAtIG1pbiArMSA9IDQxOTQzMDM5OTkgLSA0MTYwNzQ5
NTY4ICsxPSAzMzU1NDQzMiA9IDB4MDIwMDAwMDANCg0KbWF4ID0gMHhGOUZGRkZGRg0KbWlu
ID0gMHhGODAwMDAwMA0KZGlmZiA9IDB4MDIwMDAwMDANCg0KMm5kIG1lbW9yeSByYW5nZQ0K
PT09PT09PT09PT09PT09PQ0KDQptYXggPSAweGRmZmZmZmZmID0gMzc1ODA5NjM4Mw0KbWlu
ID0gMHhkODAwMDAwMCA9IDM2MjM4Nzg2NTYNCmRpZmZlcmVuY2UgPSBtYXggLSBtaW4gKyAx
ID0gMzc1ODA5NjM4MyAtIDM2MjM4Nzg2NTYgKyAxID0gMTM0MjE3NzI4ID0gMHgwODAwMDAw
MA0KDQptYXggPSAweERGRkZGRkZGDQptaW4gPSAweEQ4MDAwMDAwDQpkaWZmPSAweDA4MDAw
MDAwDQoNCjNyZCBtZW1vcnkgcmFuZ2UNCj09PT09PT09PT09PT09PT0NCg0KbWF4ID0gMHhk
N2ZmZmZmZiA9IDM2MjM4Nzg2NTUNCm1pbiA9IDB4ZDQwMDAwMDAgPSAzNTU2NzY5NzkyDQpk
aWZmZXJlbmNlID0gbWF4IC0gbWluICsgMSA9IDM2MjM4Nzg2NTUgLSAzNTU2NzY5NzkyICsg
MSA9IDY3MTA4ODY0ID0gMHgwNDAwMDAwMA0KDQptYXggPSAweEQ3RkZGRkZGDQptaW4gPSAw
eEQ0MDAwMDAwDQpkaWZmPSAweDA0MDAwMDAwDQoNCjR0aCBtZW1vcnkgcmFuZ2UNCj09PT09
PT09PT09PT09PT0NCg0KbWF4ID0gMHgwMDA3ZmZmZiA9IDUyNDI4Nw0KbWluID0gMHgwMDAw
MDAwMCA9IDANCmRpZmZlcmVuY2UgPSBtYXggLSBtaW4gKzEgPSA1MjQyODcgLSAwICsgMSA9
IDUyNDI4OCA9IDB4MDAwODAwMDANCg0KbWF4ID0gMHgwMDA3RkZGRg0KbWluID0gMHgwMDAw
MDAwMA0KZGlmZj0gMHgwMDA4MDAwMA0KDQoNClVVSUQgZDVlYzZiN2YtZTFkYi00YjQ2LWIw
NTAtZDBiZDQ2NDAzZjU5DQoNCnZtbGludXotMy41LjQteGVuLWZyYW5rLmx5b24tc2dwDQpp
bml0cmQuaW1nLTMuNS40LXhlbi1mcmFuay5seW9uLXNncA0KeGVuLmd6DQoNCnJvb3Q9L2Rl
di9tYXBwZXIvc25vdy1yb290IHJvIG5vbW9kZXNldA0KDQpmbHlvbkBzbm93On4kIGxzcGNp
IC1uIHwgZ3JlcCAiMGQ6MDAuMCINCjBkOjAwLjAgMDMwMDogMTBkZTowNmQ4IChyZXYgYTMp
DQoNCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09DQoN
CiMhL2Jpbi9zaA0Kc2V0IC14DQojIw0KU3RhcnRzIFNob3Jld2FsbCBGaXJld2FsbA0Kc3Vk
byBzZXJ2aWNlIHNob3Jld2FsbCByZXN0YXJ0DQojIw0KTG9hZHMgcGNpLXN0dWIga2VybmVs
IG1vZHVsZQ0Kc3VkbyBtb2Rwcm9iZSBwY2ktc3R1Yg0KIyMNClBhc3N0aHJvdWdoIFBhbGl0
IE5WSURJQSBHZWZvcmNlIDg0MDAgR1MgUENJZSB4MTYgVkdBIGNhcmQNCiMgZWNobyAiDQpQ
YXNzdGhyb3VnaCBQYWxpdCBOVklESUEgR2Vmb3JjZSA4NDAwIEdTIFZHQSBjYXJkLiINCnN1
ZG8gY2htb2Qgbyt3IC9zeXMvYnVzL3BjaS9kcml2ZXJzL3BjaS1zdHViL25ld19pZA0Kc3Vk
byBjaG1vZCBvK3cgL3N5cy9idXMvcGNpL2RldmljZXMvMDAwMDowMTowMC4wL2RyaXZlci91
bmJpbmQNCnN1ZG8gY2htb2Qgbyt3IC9zeXMvYnVzL3BjaS9kcml2ZXJzL3BjaS1zdHViL2Jp
bmQNCmVjaG8gIjEwZGUgMTBjMyIgPiAvc3lzL2J1cy9wY2kvZHJpdmVycy9wY2ktc3R1Yi9u
ZXdfaWQNCmVjaG8gIjAwMDA6MDE6MDAuMCIgPiAvc3lzL2J1cy9wY2kvZGV2aWNlcy8wMDAw
OjAxOjAwLjAvZHJpdmVyL3VuYmluZA0KZWNobyAiMDAwMDowMTowMC4wIiA+IC9zeXMvYnVz
L3BjaS9kcml2ZXJzL3BjaS1zdHViL2JpbmQNCiMjDQpQYXNzdGhyb3VnaCBJbnRlbCBIRCBB
dWRpbyBDb250cm9sbGVyDQojIGVjaG8gIg0KUGFzc3Rocm91Z2ggSW50ZWwgSEQgQXVkaW8g
Q29udHJvbGxlci4iDQpzdWRvIGNobW9kIG8rdyAvc3lzL2J1cy9wY2kvZHJpdmVycy9wY2kt
c3R1Yi9uZXdfaWQNCnN1ZG8gY2htb2Qgbyt3IC9zeXMvYnVzL3BjaS9kZXZpY2VzLzAwMDA6
MDA6MWIuMC9kcml2ZXIvdW5iaW5kDQpzdWRvIGNobW9kIG8rdyAvc3lzL2J1cy9wY2kvZHJp
dmVycy9wY2ktc3R1Yi9iaW5kDQplY2hvICI4MDg2IDNhNmUiID4gL3N5cy9idXMvcGNpL2Ry
aXZlcnMvcGNpLXN0dWIvbmV3X2lkDQplY2hvICIwMDAwOjAwOjFiLjAiID4gL3N5cy9idXMv
cGNpL2RldmljZXMvMDAwMDowMDoxYi4wL2RyaXZlci91bmJpbmQNCmVjaG8gIjAwMDA6MDA6
MWIuMCIgPiAvc3lzL2J1cy9wY2kvZHJpdmVycy9wY2ktc3R1Yi9iaW5kDQojIw0KV2FpdCBm
b3IgMTAgc2Vjb25kcw0KI3MNCmxlZXAgMTANCiMjDQpTdGFydCBXaW5kb3dzIEhWTSBkb21V
IHdpdGggVkdBIFBhc3N0aHJvdWdoDQojDQojc3VkbyB4bCBjcmVhdGUgL2V0Yy94ZW4vV2lu
ZG93c1hQSG9tZUVkaXRpb25TUDMNCnN1ZG8geGwgY3JlYXRlIC9ldGMveGVuL1dpbmRvd3M4
Q29uc3VtZXJQcmV2aWV3NjRiaXRFbmdsaXNo
--------------060301030907070908060303
Content-Type: text/x-log;
 name="xend.log"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
 filename="xend.log"

[2012-09-19 20:48:44 1730] INFO (SrvDaemon:332) Xend Daemon started
[2012-09-19 20:48:44 1730] INFO (SrvDaemon:336) Xend changeset: Mon Sep 1=
7 21:12:21 2012 +0100 25925:d1c3375c3f11.
[2012-09-19 20:48:44 1730] DEBUG (tcp:96) Listening on :8002
[2012-09-19 20:48:47 1730] DEBUG (XendNode:332) pscsi record count: 9
[2012-09-19 20:48:47 1730] DEBUG (XendCPUPool:747) recreate_active_pools
[2012-09-19 20:48:47 1730] DEBUG (XendDomainInfo:151) XendDomainInfo.recr=
eate({'max_vcpu_id': 23, 'cpu_time': 20156983226L, 'ssidref': 0, 'hvm': 0=
, 'shutdown_reason': 255, 'dying': 0, 'online_vcpus': 24, 'domid': 0, 'pa=
used': 0, 'crashed': 0, 'running': 1, 'maxmem_kb': 17179869180L, 'shutdow=
n': 0, 'mem_kb': 24692524L, 'blocked': 0, 'handle': [0, 0, 0, 0, 0, 0, 0,=
 0, 0, 0, 0, 0, 0, 0, 0, 0], 'cpupool': 0, 'name': 'Domain-0'})
[2012-09-19 20:48:47 1730] INFO (XendDomainInfo:169) Recreating domain 0,=
 UUID 00000000-0000-0000-0000-000000000000. at /local/domain/0
[2012-09-19 20:48:47 1730] DEBUG (XendDomainInfo:3426) Storing VM details=
: {'on_xend_stop': 'ignore', 'pool_name': 'Pool-0', 'shadow_memory': '0',=
 'uuid': '00000000-0000-0000-0000-000000000000', 'on_reboot': 'restart', =
'image': "(linux (kernel '') (superpages 0) (nomigrate 0) (tsc_mode 0))",=
 'on_poweroff': 'destroy', 'bootloader_args': '', 'on_xend_start': 'ignor=
e', 'on_crash': 'restart', 'xend/restart_count': '0', 'vcpus': '24', 'vcp=
u_avail': '16777215', 'bootloader': '', 'name': 'Domain-0'}
[2012-09-19 20:48:47 1730] DEBUG (XendDomainInfo:1795) Storing domain det=
ails: {'cpu/3/availability': 'online', 'cpu/6/availability': 'online', 'v=
m': '/vm/00000000-0000-0000-0000-000000000000', 'cpu/22/availability': 'o=
nline', 'control/platform-feature-multiprocessor-suspend': '1', 'cpu/17/a=
vailability': 'online', 'cpu/14/availability': 'online', 'console/limit':=
 '1048576', 'cpu/2/availability': 'online', 'cpu/11/availability': 'onlin=
e', 'cpu/1/availability': 'online', 'cpu/7/availability': 'online', 'memo=
ry/target': '24692524', 'cpu/20/availability': 'online', 'control/platfor=
m-feature-xs_reset_watches': '1', 'cpu/15/availability': 'online', 'descr=
iption': '', 'cpu/13/availability': 'online', 'cpu/8/availability': 'onli=
ne', 'cpu/9/availability': 'online', 'cpu/5/availability': 'online', 'cpu=
/23/availability': 'online', 'cpu/0/availability': 'online', 'cpu/18/avai=
lability': 'online', 'console/type': 'xenconsoled', 'cpu/12/availability'=
: 'online', 'cpu/19/availability': 'online', 'name': 'Domain-0', 'domid':=
 '0', 'cpu/4/availability': 'online', 'cpu/16/availability': 'online', 'c=
pu/21/availability': 'online', 'cpu/10/availability': 'online'}
[2012-09-19 20:48:47 1730] DEBUG (XendDomain:476) Adding Domain: 0
[2012-09-19 20:48:47 1730] DEBUG (XendDomain:410) number of vcpus to use =
is 0
[2012-09-19 20:48:47 1730] DEBUG (XendDomainInfo:1882) XendDomainInfo.han=
dleShutdownWatch
[2012-09-19 20:48:47 1730] WARNING (XendAPI:708) API call: VBD.set_device=
 not found
[2012-09-19 20:48:47 1730] WARNING (XendAPI:708) API call: VBD.set_type n=
ot found
[2012-09-19 20:48:47 1730] WARNING (XendAPI:708) API call: session.get_al=
l_records not found
[2012-09-19 20:48:47 1730] WARNING (XendAPI:708) API call: event.get_reco=
rd not found
[2012-09-19 20:48:47 1730] WARNING (XendAPI:708) API call: event.get_all =
not found
[2012-09-19 20:48:47 1730] WARNING (XendAPI:708) API call: VIF.set_device=
 not found
[2012-09-19 20:48:47 1730] WARNING (XendAPI:708) API call: VIF.set_MAC no=
t found
[2012-09-19 20:48:47 1730] WARNING (XendAPI:708) API call: VIF.set_MTU no=
t found
[2012-09-19 20:48:47 1730] WARNING (XendAPI:708) API call: debug.get_all =
not found
[2012-09-19 20:48:47 1730] INFO (XMLRPCServer:161) Opening Unix domain so=
cket XML-RPC server on /var/run/xend/xen-api.sock; authentication has bee=
n disabled for this server.
[2012-09-19 20:48:47 1730] INFO (XMLRPCServer:161) Opening Unix domain so=
cket XML-RPC server on /var/run/xend/xmlrpc.sock.
[2012-09-19 21:00:22 1730] DEBUG (SrvServer:77) SrvServer.cleanup()
[2012-09-19 21:00:22 1730] DEBUG (XMLRPCServer:251) XMLRPCServer.cleanup(=
)
[2012-09-19 21:00:22 1730] DEBUG (XMLRPCServer:251) XMLRPCServer.cleanup(=
)
[2012-09-19 21:00:22 1730] DEBUG (XendDomain:644) cleanup_domains
[2012-09-19 21:00:22 1729] INFO (SrvDaemon:220) Xend exited with status 0=
=2E
[2012-09-19 21:03:31 1691] INFO (SrvDaemon:332) Xend Daemon started
[2012-09-19 21:03:31 1691] INFO (SrvDaemon:336) Xend changeset: Mon Sep 1=
7 21:12:21 2012 +0100 25925:d1c3375c3f11.
[2012-09-19 21:03:31 1691] DEBUG (tcp:96) Listening on :8002
[2012-09-19 21:03:33 1691] DEBUG (XendNode:332) pscsi record count: 9
[2012-09-19 21:03:33 1691] DEBUG (XendCPUPool:747) recreate_active_pools
[2012-09-19 21:03:33 1691] DEBUG (XendDomainInfo:151) XendDomainInfo.recr=
eate({'max_vcpu_id': 23, 'cpu_time': 17093476257L, 'ssidref': 0, 'hvm': 0=
, 'shutdown_reason': 255, 'dying': 0, 'online_vcpus': 24, 'domid': 0, 'pa=
used': 0, 'crashed': 0, 'running': 1, 'maxmem_kb': 17179869180L, 'shutdow=
n': 0, 'mem_kb': 24692524L, 'blocked': 0, 'handle': [0, 0, 0, 0, 0, 0, 0,=
 0, 0, 0, 0, 0, 0, 0, 0, 0], 'cpupool': 0, 'name': 'Domain-0'})
[2012-09-19 21:03:33 1691] INFO (XendDomainInfo:169) Recreating domain 0,=
 UUID 00000000-0000-0000-0000-000000000000. at /local/domain/0
[2012-09-19 21:03:33 1691] DEBUG (XendDomainInfo:3426) Storing VM details=
: {'on_xend_stop': 'ignore', 'pool_name': 'Pool-0', 'shadow_memory': '0',=
 'uuid': '00000000-0000-0000-0000-000000000000', 'on_reboot': 'restart', =
'image': "(linux (kernel '') (superpages 0) (nomigrate 0) (tsc_mode 0))",=
 'on_poweroff': 'destroy', 'bootloader_args': '', 'on_xend_start': 'ignor=
e', 'on_crash': 'restart', 'xend/restart_count': '0', 'vcpus': '24', 'vcp=
u_avail': '16777215', 'bootloader': '', 'name': 'Domain-0'}
[2012-09-19 21:03:33 1691] DEBUG (XendDomainInfo:1795) Storing domain det=
ails: {'cpu/3/availability': 'online', 'cpu/6/availability': 'online', 'v=
m': '/vm/00000000-0000-0000-0000-000000000000', 'cpu/22/availability': 'o=
nline', 'control/platform-feature-multiprocessor-suspend': '1', 'cpu/17/a=
vailability': 'online', 'cpu/14/availability': 'online', 'console/limit':=
 '1048576', 'cpu/2/availability': 'online', 'cpu/11/availability': 'onlin=
e', 'cpu/1/availability': 'online', 'cpu/7/availability': 'online', 'memo=
ry/target': '24692524', 'cpu/20/availability': 'online', 'control/platfor=
m-feature-xs_reset_watches': '1', 'cpu/15/availability': 'online', 'descr=
iption': '', 'cpu/13/availability': 'online', 'cpu/8/availability': 'onli=
ne', 'cpu/9/availability': 'online', 'cpu/5/availability': 'online', 'cpu=
/23/availability': 'online', 'cpu/0/availability': 'online', 'cpu/18/avai=
lability': 'online', 'console/type': 'xenconsoled', 'cpu/12/availability'=
: 'online', 'cpu/19/availability': 'online', 'name': 'Domain-0', 'domid':=
 '0', 'cpu/4/availability': 'online', 'cpu/16/availability': 'online', 'c=
pu/21/availability': 'online', 'cpu/10/availability': 'online'}
[2012-09-19 21:03:33 1691] DEBUG (XendDomain:476) Adding Domain: 0
[2012-09-19 21:03:33 1691] DEBUG (XendDomain:410) number of vcpus to use =
is 0
[2012-09-19 21:03:33 1691] DEBUG (XendDomainInfo:1882) XendDomainInfo.han=
dleShutdownWatch
[2012-09-19 21:03:33 1691] WARNING (XendAPI:708) API call: VBD.set_device=
 not found
[2012-09-19 21:03:33 1691] WARNING (XendAPI:708) API call: VBD.set_type n=
ot found
[2012-09-19 21:03:33 1691] WARNING (XendAPI:708) API call: session.get_al=
l_records not found
[2012-09-19 21:03:33 1691] WARNING (XendAPI:708) API call: event.get_reco=
rd not found
[2012-09-19 21:03:33 1691] WARNING (XendAPI:708) API call: event.get_all =
not found
[2012-09-19 21:03:33 1691] WARNING (XendAPI:708) API call: VIF.set_device=
 not found
[2012-09-19 21:03:33 1691] WARNING (XendAPI:708) API call: VIF.set_MAC no=
t found
[2012-09-19 21:03:33 1691] WARNING (XendAPI:708) API call: VIF.set_MTU no=
t found
[2012-09-19 21:03:34 1691] WARNING (XendAPI:708) API call: debug.get_all =
not found
[2012-09-19 21:03:34 1691] INFO (XMLRPCServer:161) Opening Unix domain so=
cket XML-RPC server on /var/run/xend/xen-api.sock; authentication has bee=
n disabled for this server.
[2012-09-19 21:03:34 1691] INFO (XMLRPCServer:161) Opening Unix domain so=
cket XML-RPC server on /var/run/xend/xmlrpc.sock.
[2012-09-19 22:18:22 1691] DEBUG (SrvServer:77) SrvServer.cleanup()
[2012-09-19 22:18:22 1691] DEBUG (XMLRPCServer:251) XMLRPCServer.cleanup(=
)
[2012-09-19 22:18:22 1691] DEBUG (XMLRPCServer:251) XMLRPCServer.cleanup(=
)
[2012-09-19 22:18:22 1691] DEBUG (XendDomain:644) cleanup_domains
[2012-09-19 22:18:22 1689] INFO (SrvDaemon:220) Xend exited with status 0=
=2E
[2012-09-19 22:37:19 6950] INFO (SrvDaemon:332) Xend Daemon started
[2012-09-19 22:37:19 6950] INFO (SrvDaemon:336) Xend changeset: Mon Sep 1=
7 21:12:21 2012 +0100 25925:d1c3375c3f11.
[2012-09-19 22:37:19 6950] DEBUG (tcp:96) Listening on :8002
[2012-09-19 22:37:22 6950] DEBUG (XendNode:332) pscsi record count: 12
[2012-09-19 22:37:22 6950] DEBUG (XendCPUPool:747) recreate_active_pools
[2012-09-19 22:37:22 6950] DEBUG (XendDomainInfo:151) XendDomainInfo.recr=
eate({'max_vcpu_id': 23, 'cpu_time': 3726170848291L, 'ssidref': 0, 'hvm':=
 0, 'shutdown_reason': 255, 'dying': 0, 'online_vcpus': 24, 'domid': 0, '=
paused': 0, 'crashed': 0, 'running': 1, 'maxmem_kb': 17179869180L, 'shutd=
own': 0, 'mem_kb': 12293932L, 'blocked': 0, 'handle': [0, 0, 0, 0, 0, 0, =
0, 0, 0, 0, 0, 0, 0, 0, 0, 0], 'cpupool': 0, 'name': 'Domain-0'})
[2012-09-19 22:37:22 6950] INFO (XendDomainInfo:169) Recreating domain 0,=
 UUID 00000000-0000-0000-0000-000000000000. at /local/domain/0
[2012-09-19 22:37:22 6950] DEBUG (XendDomain:476) Adding Domain: 0
[2012-09-19 22:37:22 6950] DEBUG (XendDomainInfo:1882) XendDomainInfo.han=
dleShutdownWatch
[2012-09-19 22:37:22 6950] DEBUG (XendDomain:410) number of vcpus to use =
is 0
[2012-09-19 22:37:22 6950] WARNING (XendAPI:708) API call: VBD.set_device=
 not found
[2012-09-19 22:37:22 6950] WARNING (XendAPI:708) API call: VBD.set_type n=
ot found
[2012-09-19 22:37:22 6950] WARNING (XendAPI:708) API call: session.get_al=
l_records not found
[2012-09-19 22:37:22 6950] WARNING (XendAPI:708) API call: event.get_reco=
rd not found
[2012-09-19 22:37:22 6950] WARNING (XendAPI:708) API call: event.get_all =
not found
[2012-09-19 22:37:22 6950] WARNING (XendAPI:708) API call: VIF.set_device=
 not found
[2012-09-19 22:37:22 6950] WARNING (XendAPI:708) API call: VIF.set_MAC no=
t found
[2012-09-19 22:37:22 6950] WARNING (XendAPI:708) API call: VIF.set_MTU no=
t found
[2012-09-19 22:37:22 6950] WARNING (XendAPI:708) API call: debug.get_all =
not found
[2012-09-19 22:37:22 6950] INFO (XMLRPCServer:161) Opening Unix domain so=
cket XML-RPC server on /var/run/xend/xen-api.sock; authentication has bee=
n disabled for this server.
[2012-09-19 22:37:22 6950] INFO (XMLRPCServer:161) Opening Unix domain so=
cket XML-RPC server on /var/run/xend/xmlrpc.sock.
[2012-09-19 22:38:16 6950] DEBUG (SrvServer:77) SrvServer.cleanup()
[2012-09-19 22:38:16 6950] DEBUG (XMLRPCServer:251) XMLRPCServer.cleanup(=
)
[2012-09-19 22:38:16 6950] DEBUG (XMLRPCServer:251) XMLRPCServer.cleanup(=
)
[2012-09-19 22:38:16 6950] DEBUG (XendDomain:644) cleanup_domains
[2012-09-19 22:38:16 6949] INFO (SrvDaemon:220) Xend exited with status 0=
=2E

--------------060301030907070908060303
Content-Type: text/x-log;
 name="xend-debug.log"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename="xend-debug.log"

Xend started at Wed Sep 19 20:48:44 2012.
cat: /sys/bus/scsi/devices/target1:0:0/vendor: No such file or directory
cat: /sys/bus/scsi/devices/target1:0:0/model: No such file or directory
cat: /sys/bus/scsi/devices/target1:0:0/type: No such file or directory
cat: /sys/bus/scsi/devices/target1:0:0/rev: No such file or directory
cat: /sys/bus/scsi/devices/target1:0:0/scsi_level: No such file or directory
cat: /sys/bus/scsi/devices/target2:0:0/vendor: No such file or directory
cat: /sys/bus/scsi/devices/target2:0:0/model: No such file or directory
cat: /sys/bus/scsi/devices/target2:0:0/type: No such file or directory
cat: /sys/bus/scsi/devices/target2:0:0/rev: No such file or directory
cat: /sys/bus/scsi/devices/target2:0:0/scsi_level: No such file or directory
cat: /sys/bus/scsi/devices/target2:3:0/vendor: No such file or directory
cat: /sys/bus/scsi/devices/target2:3:0/model: No such file or directory
cat: /sys/bus/scsi/devices/target2:3:0/type: No such file or directory
cat: /sys/bus/scsi/devices/target2:3:0/rev: No such file or directory
cat: /sys/bus/scsi/devices/target2:3:0/scsi_level: No such file or directory
cat: /sys/bus/scsi/devices/host0/vendor: No such file or directory
cat: /sys/bus/scsi/devices/host0/model: No such file or directory
cat: /sys/bus/scsi/devices/host0/type: No such file or directory
cat: /sys/bus/scsi/devices/host0/rev: No such file or directory
cat: /sys/bus/scsi/devices/host0/scsi_level: No such file or directory
cat: /sys/bus/scsi/devices/host1/vendor: No such file or directory
cat: /sys/bus/scsi/devices/host1/model: No such file or directory
cat: /sys/bus/scsi/devices/host1/type: No such file or directory
cat: /sys/bus/scsi/devices/host1/rev: No such file or directory
cat: /sys/bus/scsi/devices/host1/scsi_level: No such file or directory
cat: /sys/bus/scsi/devices/host2/vendor: No such file or directory
cat: /sys/bus/scsi/devices/host2/model: No such file or directory
cat: /sys/bus/scsi/devices/host2/type: No such file or directory
cat: /sys/bus/scsi/devices/host2/rev: No such file or directory
cat: /sys/bus/scsi/devices/host2/scsi_level: No such file or directory
Xend started at Wed Sep 19 21:03:31 2012.
cat: /sys/bus/scsi/devices/target1:0:0/vendor: No such file or directory
cat: /sys/bus/scsi/devices/target1:0:0/model: No such file or directory
cat: /sys/bus/scsi/devices/target1:0:0/type: No such file or directory
cat: /sys/bus/scsi/devices/target1:0:0/rev: No such file or directory
cat: /sys/bus/scsi/devices/target1:0:0/scsi_level: No such file or directory
cat: /sys/bus/scsi/devices/target2:0:0/vendor: No such file or directory
cat: /sys/bus/scsi/devices/target2:0:0/model: No such file or directory
cat: /sys/bus/scsi/devices/target2:0:0/type: No such file or directory
cat: /sys/bus/scsi/devices/target2:0:0/rev: No such file or directory
cat: /sys/bus/scsi/devices/target2:0:0/scsi_level: No such file or directory
cat: /sys/bus/scsi/devices/target2:3:0/vendor: No such file or directory
cat: /sys/bus/scsi/devices/target2:3:0/model: No such file or directory
cat: /sys/bus/scsi/devices/target2:3:0/type: No such file or directory
cat: /sys/bus/scsi/devices/target2:3:0/rev: No such file or directory
cat: /sys/bus/scsi/devices/target2:3:0/scsi_level: No such file or directory
cat: /sys/bus/scsi/devices/host0/vendor: No such file or directory
cat: /sys/bus/scsi/devices/host0/model: No such file or directory
cat: /sys/bus/scsi/devices/host0/type: No such file or directory
cat: /sys/bus/scsi/devices/host0/rev: No such file or directory
cat: /sys/bus/scsi/devices/host0/scsi_level: No such file or directory
cat: /sys/bus/scsi/devices/host1/vendor: No such file or directory
cat: /sys/bus/scsi/devices/host1/model: No such file or directory
cat: /sys/bus/scsi/devices/host1/type: No such file or directory
cat: /sys/bus/scsi/devices/host1/rev: No such file or directory
cat: /sys/bus/scsi/devices/host1/scsi_level: No such file or directory
cat: /sys/bus/scsi/devices/host2/vendor: No such file or directory
cat: /sys/bus/scsi/devices/host2/model: No such file or directory
cat: /sys/bus/scsi/devices/host2/type: No such file or directory
cat: /sys/bus/scsi/devices/host2/rev: No such file or directory
cat: /sys/bus/scsi/devices/host2/scsi_level: No such file or directory
Xend started at Wed Sep 19 22:37:19 2012.
cat: /sys/bus/scsi/devices/target1:0:0/vendor: No such file or directory
cat: /sys/bus/scsi/devices/target1:0:0/model: No such file or directory
cat: /sys/bus/scsi/devices/target1:0:0/type: No such file or directory
cat: /sys/bus/scsi/devices/target1:0:0/rev: No such file or directory
cat: /sys/bus/scsi/devices/target1:0:0/scsi_level: No such file or directory
cat: /sys/bus/scsi/devices/target2:0:0/vendor: No such file or directory
cat: /sys/bus/scsi/devices/target2:0:0/model: No such file or directory
cat: /sys/bus/scsi/devices/target2:0:0/type: No such file or directory
cat: /sys/bus/scsi/devices/target2:0:0/rev: No such file or directory
cat: /sys/bus/scsi/devices/target2:0:0/scsi_level: No such file or directory
cat: /sys/bus/scsi/devices/target2:3:0/vendor: No such file or directory
cat: /sys/bus/scsi/devices/target2:3:0/model: No such file or directory
cat: /sys/bus/scsi/devices/target2:3:0/type: No such file or directory
cat: /sys/bus/scsi/devices/target2:3:0/rev: No such file or directory
cat: /sys/bus/scsi/devices/target2:3:0/scsi_level: No such file or directory
cat: /sys/bus/scsi/devices/target3:0:0/vendor: No such file or directory
cat: /sys/bus/scsi/devices/target3:0:0/model: No such file or directory
cat: /sys/bus/scsi/devices/target3:0:0/type: No such file or directory
cat: /sys/bus/scsi/devices/target3:0:0/rev: No such file or directory
cat: /sys/bus/scsi/devices/target3:0:0/scsi_level: No such file or directory
cat: /sys/bus/scsi/devices/host0/vendor: No such file or directory
cat: /sys/bus/scsi/devices/host0/model: No such file or directory
cat: /sys/bus/scsi/devices/host0/type: No such file or directory
cat: /sys/bus/scsi/devices/host0/rev: No such file or directory
cat: /sys/bus/scsi/devices/host0/scsi_level: No such file or directory
cat: /sys/bus/scsi/devices/host1/vendor: No such file or directory
cat: /sys/bus/scsi/devices/host1/model: No such file or directory
cat: /sys/bus/scsi/devices/host1/type: No such file or directory
cat: /sys/bus/scsi/devices/host1/rev: No such file or directory
cat: /sys/bus/scsi/devices/host1/scsi_level: No such file or directory
cat: /sys/bus/scsi/devices/host2/vendor: No such file or directory
cat: /sys/bus/scsi/devices/host2/model: No such file or directory
cat: /sys/bus/scsi/devices/host2/type: No such file or directory
cat: /sys/bus/scsi/devices/host2/rev: No such file or directory
cat: /sys/bus/scsi/devices/host2/scsi_level: No such file or directory
cat: /sys/bus/scsi/devices/host3/vendor: No such file or directory
cat: /sys/bus/scsi/devices/host3/model: No such file or directory
cat: /sys/bus/scsi/devices/host3/type: No such file or directory
cat: /sys/bus/scsi/devices/host3/rev: No such file or directory
cat: /sys/bus/scsi/devices/host3/scsi_level: No such file or directory

--------------060301030907070908060303
Content-Type: text/x-log;
 name="xen-hotplug.log"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename="xen-hotplug.log"

RTNETLINK answers: Operation not supported
RTNETLINK answers: Operation not supported
RTNETLINK answers: Operation not supported
RTNETLINK answers: Operation not supported
RTNETLINK answers: Operation not supported
RTNETLINK answers: Operation not supported
RTNETLINK answers: Operation not supported
RTNETLINK answers: Operation not supported
RTNETLINK answers: Operation not supported
RTNETLINK answers: Operation not supported
RTNETLINK answers: Operation not supported
RTNETLINK answers: Operation not supported
RTNETLINK answers: Operation not supported
RTNETLINK answers: Operation not supported
RTNETLINK answers: Operation not supported
RTNETLINK answers: Operation not supported
RTNETLINK answers: Operation not supported
RTNETLINK answers: Operation not supported
RTNETLINK answers: Operation not supported
RTNETLINK answers: Operation not supported

--------------060301030907070908060303
Content-Type: text/x-log;
 name="xl-Windows8.log"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename="xl-Windows8.log"

Waiting for domain Windows8 (domid 9) to die [pid 7447]
Domain 9 has shut down, reason code 1 0x1
Action for shutdown reason code 1 is restart
Domain 9 needs to be cleaned up: destroying the domain
libxl: error: libxl_pci.c:1001:libxl__device_pci_reset: The kernel doesn't support reset from sysfs for PCI device 0000:0d:00.0
libxl: error: libxl_pci.c:1265:do_pci_remove: xc_deassign_device failed
Done. Rebooting now
xc: info: VIRTUAL MEMORY ARRANGEMENT:
  Loader:        0000000000100000->00000000001ad64c
  TOTAL:         0000000000000000->00000000ff800000
  ENTRY ADDRESS: 0000000000100000
xc: info: PHYSICAL MEMORY ALLOCATION:
  4KB PAGES: 0x0000000000000200
  2MB PAGES: 0x00000000000003fb
  1GB PAGES: 0x0000000000000002
libxl: error: libxl_pci.c:1055:libxl__device_pci_add: PCI device 0:d:0.0 is not assignable
Waiting for domain Windows8 (domid 10) to die [pid 7447]
Domain 10 has shut down, reason code 1 0x1
Action for shutdown reason code 1 is restart
Domain 10 needs to be cleaned up: destroying the domain
libxl: error: libxl_pci.c:1001:libxl__device_pci_reset: The kernel doesn't support reset from sysfs for PCI device 0000:0d:00.0
libxl: error: libxl_pci.c:1265:do_pci_remove: xc_deassign_device failed
Done. Rebooting now
xc: info: VIRTUAL MEMORY ARRANGEMENT:
  Loader:        0000000000100000->00000000001ad64c
  TOTAL:         0000000000000000->00000000ff800000
  ENTRY ADDRESS: 0000000000100000
xc: info: PHYSICAL MEMORY ALLOCATION:
  4KB PAGES: 0x0000000000000200
  2MB PAGES: 0x00000000000003fb
  1GB PAGES: 0x0000000000000002
libxl: error: libxl_pci.c:1055:libxl__device_pci_add: PCI device 0:d:0.0 is not assignable
Waiting for domain Windows8 (domid 11) to die [pid 7447]
Domain 11 has shut down, reason code 1 0x1
Action for shutdown reason code 1 is restart
Domain 11 needs to be cleaned up: destroying the domain
libxl: error: libxl_pci.c:1001:libxl__device_pci_reset: The kernel doesn't support reset from sysfs for PCI device 0000:0d:00.0
libxl: error: libxl_pci.c:1265:do_pci_remove: xc_deassign_device failed
Done. Rebooting now
xc: info: VIRTUAL MEMORY ARRANGEMENT:
  Loader:        0000000000100000->00000000001ad64c
  TOTAL:         0000000000000000->00000000ff800000
  ENTRY ADDRESS: 0000000000100000
xc: info: PHYSICAL MEMORY ALLOCATION:
  4KB PAGES: 0x0000000000000200
  2MB PAGES: 0x00000000000003fb
  1GB PAGES: 0x0000000000000002
libxl: error: libxl_pci.c:1055:libxl__device_pci_add: PCI device 0:d:0.0 is not assignable
Waiting for domain Windows8 (domid 12) to die [pid 7447]
Domain 12 has shut down, reason code 1 0x1
Action for shutdown reason code 1 is restart
Domain 12 needs to be cleaned up: destroying the domain
libxl: error: libxl_pci.c:1001:libxl__device_pci_reset: The kernel doesn't support reset from sysfs for PCI device 0000:0d:00.0
libxl: error: libxl_pci.c:1265:do_pci_remove: xc_deassign_device failed
Done. Rebooting now
xc: info: VIRTUAL MEMORY ARRANGEMENT:
  Loader:        0000000000100000->00000000001ad64c
  TOTAL:         0000000000000000->00000000ff800000
  ENTRY ADDRESS: 0000000000100000
xc: info: PHYSICAL MEMORY ALLOCATION:
  4KB PAGES: 0x0000000000000200
  2MB PAGES: 0x00000000000003fb
  1GB PAGES: 0x0000000000000002
libxl: error: libxl_pci.c:1055:libxl__device_pci_add: PCI device 0:d:0.0 is not assignable
Waiting for domain Windows8 (domid 13) to die [pid 7447]
Domain 13 has shut down, reason code 1 0x1
Action for shutdown reason code 1 is restart
Domain 13 needs to be cleaned up: destroying the domain
libxl: error: libxl_pci.c:1001:libxl__device_pci_reset: The kernel doesn't support reset from sysfs for PCI device 0000:0d:00.0
libxl: error: libxl_pci.c:1265:do_pci_remove: xc_deassign_device failed
Done. Rebooting now
xc: info: VIRTUAL MEMORY ARRANGEMENT:
  Loader:        0000000000100000->00000000001ad64c
  TOTAL:         0000000000000000->00000000ff800000
  ENTRY ADDRESS: 0000000000100000
xc: info: PHYSICAL MEMORY ALLOCATION:
  4KB PAGES: 0x0000000000000200
  2MB PAGES: 0x00000000000003fb
  1GB PAGES: 0x0000000000000002
libxl: error: libxl_pci.c:1055:libxl__device_pci_add: PCI device 0:d:0.0 is not assignable
Waiting for domain Windows8 (domid 14) to die [pid 7447]
Domain 14 has shut down, reason code 1 0x1
Action for shutdown reason code 1 is restart
Domain 14 needs to be cleaned up: destroying the domain
libxl: error: libxl_pci.c:1001:libxl__device_pci_reset: The kernel doesn't support reset from sysfs for PCI device 0000:0d:00.0
libxl: error: libxl_pci.c:1265:do_pci_remove: xc_deassign_device failed
Done. Rebooting now
xc: info: VIRTUAL MEMORY ARRANGEMENT:
  Loader:        0000000000100000->00000000001ad64c
  TOTAL:         0000000000000000->00000000ff800000
  ENTRY ADDRESS: 0000000000100000
xc: info: PHYSICAL MEMORY ALLOCATION:
  4KB PAGES: 0x0000000000000200
  2MB PAGES: 0x00000000000003fb
  1GB PAGES: 0x0000000000000002
libxl: error: libxl_pci.c:1055:libxl__device_pci_add: PCI device 0:d:0.0 is not assignable
Waiting for domain Windows8 (domid 15) to die [pid 7447]
Domain 15 has shut down, reason code 1 0x1
Action for shutdown reason code 1 is restart
Domain 15 needs to be cleaned up: destroying the domain
libxl: error: libxl_pci.c:1001:libxl__device_pci_reset: The kernel doesn't support reset from sysfs for PCI device 0000:0d:00.0
libxl: error: libxl_pci.c:1265:do_pci_remove: xc_deassign_device failed
Done. Rebooting now
xc: info: VIRTUAL MEMORY ARRANGEMENT:
  Loader:        0000000000100000->00000000001ad64c
  TOTAL:         0000000000000000->00000000ff800000
  ENTRY ADDRESS: 0000000000100000
xc: info: PHYSICAL MEMORY ALLOCATION:
  4KB PAGES: 0x0000000000000200
  2MB PAGES: 0x00000000000003fb
  1GB PAGES: 0x0000000000000002
libxl: error: libxl_pci.c:1055:libxl__device_pci_add: PCI device 0:d:0.0 is not assignable
Waiting for domain Windows8 (domid 16) to die [pid 7447]
Domain 16 has shut down, reason code 1 0x1
Action for shutdown reason code 1 is restart
Domain 16 needs to be cleaned up: destroying the domain
libxl: error: libxl_pci.c:1001:libxl__device_pci_reset: The kernel doesn't support reset from sysfs for PCI device 0000:0d:00.0
libxl: error: libxl_pci.c:1265:do_pci_remove: xc_deassign_device failed
Done. Rebooting now
xc: info: VIRTUAL MEMORY ARRANGEMENT:
  Loader:        0000000000100000->00000000001ad64c
  TOTAL:         0000000000000000->00000000ff800000
  ENTRY ADDRESS: 0000000000100000
xc: info: PHYSICAL MEMORY ALLOCATION:
  4KB PAGES: 0x0000000000000200
  2MB PAGES: 0x00000000000003fb
  1GB PAGES: 0x0000000000000002
libxl: error: libxl_pci.c:1055:libxl__device_pci_add: PCI device 0:d:0.0 is not assignable
Waiting for domain Windows8 (domid 17) to die [pid 7447]
Domain 17 has shut down, reason code 1 0x1
Action for shutdown reason code 1 is restart
Domain 17 needs to be cleaned up: destroying the domain
libxl: error: libxl_pci.c:1001:libxl__device_pci_reset: The kernel doesn't support reset from sysfs for PCI device 0000:0d:00.0
libxl: error: libxl_pci.c:1265:do_pci_remove: xc_deassign_device failed
Done. Rebooting now
xc: info: VIRTUAL MEMORY ARRANGEMENT:
  Loader:        0000000000100000->00000000001ad64c
  TOTAL:         0000000000000000->00000000ff800000
  ENTRY ADDRESS: 0000000000100000
xc: info: PHYSICAL MEMORY ALLOCATION:
  4KB PAGES: 0x0000000000000200
  2MB PAGES: 0x00000000000003fb
  1GB PAGES: 0x0000000000000002
libxl: error: libxl_pci.c:1055:libxl__device_pci_add: PCI device 0:d:0.0 is not assignable
Waiting for domain Windows8 (domid 18) to die [pid 7447]
Domain 18 has shut down, reason code 1 0x1
Action for shutdown reason code 1 is restart
Domain 18 needs to be cleaned up: destroying the domain
libxl: error: libxl_pci.c:1001:libxl__device_pci_reset: The kernel doesn't support reset from sysfs for PCI device 0000:0d:00.0
libxl: error: libxl_pci.c:1265:do_pci_remove: xc_deassign_device failed
Done. Rebooting now
xc: info: VIRTUAL MEMORY ARRANGEMENT:
  Loader:        0000000000100000->00000000001ad64c
  TOTAL:         0000000000000000->00000000ff800000
  ENTRY ADDRESS: 0000000000100000
xc: info: PHYSICAL MEMORY ALLOCATION:
  4KB PAGES: 0x0000000000000200
  2MB PAGES: 0x00000000000003fb
  1GB PAGES: 0x0000000000000002
libxl: error: libxl_pci.c:1055:libxl__device_pci_add: PCI device 0:d:0.0 is not assignable
Waiting for domain Windows8 (domid 19) to die [pid 7447]
Domain 19 has shut down, reason code 1 0x1
Action for shutdown reason code 1 is restart
Domain 19 needs to be cleaned up: destroying the domain
libxl: error: libxl_pci.c:1001:libxl__device_pci_reset: The kernel doesn't support reset from sysfs for PCI device 0000:0d:00.0
libxl: error: libxl_pci.c:1265:do_pci_remove: xc_deassign_device failed
Done. Rebooting now
xc: info: VIRTUAL MEMORY ARRANGEMENT:
  Loader:        0000000000100000->00000000001ad64c
  TOTAL:         0000000000000000->00000000ff800000
  ENTRY ADDRESS: 0000000000100000
xc: info: PHYSICAL MEMORY ALLOCATION:
  4KB PAGES: 0x0000000000000200
  2MB PAGES: 0x00000000000003fb
  1GB PAGES: 0x0000000000000002
libxl: error: libxl_pci.c:1055:libxl__device_pci_add: PCI device 0:d:0.0 is not assignable
Waiting for domain Windows8 (domid 20) to die [pid 7447]
Domain 20 has shut down, reason code 1 0x1
Action for shutdown reason code 1 is restart
Domain 20 needs to be cleaned up: destroying the domain
libxl: error: libxl_pci.c:1001:libxl__device_pci_reset: The kernel doesn't support reset from sysfs for PCI device 0000:0d:00.0
libxl: error: libxl_pci.c:1265:do_pci_remove: xc_deassign_device failed
Done. Rebooting now
xc: info: VIRTUAL MEMORY ARRANGEMENT:
  Loader:        0000000000100000->00000000001ad64c
  TOTAL:         0000000000000000->00000000ff800000
  ENTRY ADDRESS: 0000000000100000
xc: info: PHYSICAL MEMORY ALLOCATION:
  4KB PAGES: 0x0000000000000200
  2MB PAGES: 0x00000000000003fb
  1GB PAGES: 0x0000000000000002
libxl: error: libxl_pci.c:1055:libxl__device_pci_add: PCI device 0:d:0.0 is not assignable
Waiting for domain Windows8 (domid 21) to die [pid 7447]

--------------060301030907070908060303
Content-Type: text/plain;
 name="xl-Windows8.log.1"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename="xl-Windows8.log.1"

Waiting for domain Windows8 (domid 2) to die [pid 5545]
Domain 2 has shut down, reason code 1 0x1
Action for shutdown reason code 1 is restart
Domain 2 needs to be cleaned up: destroying the domain
libxl: error: libxl_pci.c:1001:libxl__device_pci_reset: The kernel doesn't support reset from sysfs for PCI device 0000:0d:00.0
libxl: error: libxl_pci.c:1265:do_pci_remove: xc_deassign_device failed
Done. Rebooting now
xc: info: VIRTUAL MEMORY ARRANGEMENT:
  Loader:        0000000000100000->00000000001ad64c
  TOTAL:         0000000000000000->00000000ff800000
  ENTRY ADDRESS: 0000000000100000
xc: info: PHYSICAL MEMORY ALLOCATION:
  4KB PAGES: 0x0000000000000200
  2MB PAGES: 0x00000000000003fb
  1GB PAGES: 0x0000000000000002
libxl: error: libxl_pci.c:1055:libxl__device_pci_add: PCI device 0:d:0.0 is not assignable
Waiting for domain Windows8 (domid 3) to die [pid 5545]
Domain 3 has shut down, reason code 1 0x1
Action for shutdown reason code 1 is restart
Domain 3 needs to be cleaned up: destroying the domain
libxl: error: libxl_pci.c:1001:libxl__device_pci_reset: The kernel doesn't support reset from sysfs for PCI device 0000:0d:00.0
libxl: error: libxl_pci.c:1265:do_pci_remove: xc_deassign_device failed
Done. Rebooting now
xc: info: VIRTUAL MEMORY ARRANGEMENT:
  Loader:        0000000000100000->00000000001ad64c
  TOTAL:         0000000000000000->00000000ff800000
  ENTRY ADDRESS: 0000000000100000
xc: info: PHYSICAL MEMORY ALLOCATION:
  4KB PAGES: 0x0000000000000200
  2MB PAGES: 0x00000000000003fb
  1GB PAGES: 0x0000000000000002
libxl: error: libxl_pci.c:1055:libxl__device_pci_add: PCI device 0:d:0.0 is not assignable
Waiting for domain Windows8 (domid 4) to die [pid 5545]
Domain 4 has shut down, reason code 1 0x1
Action for shutdown reason code 1 is restart
Domain 4 needs to be cleaned up: destroying the domain
libxl: error: libxl_pci.c:1001:libxl__device_pci_reset: The kernel doesn't support reset from sysfs for PCI device 0000:0d:00.0
libxl: error: libxl_pci.c:1265:do_pci_remove: xc_deassign_device failed
Done. Rebooting now
xc: info: VIRTUAL MEMORY ARRANGEMENT:
  Loader:        0000000000100000->00000000001ad64c
  TOTAL:         0000000000000000->00000000ff800000
  ENTRY ADDRESS: 0000000000100000
xc: info: PHYSICAL MEMORY ALLOCATION:
  4KB PAGES: 0x0000000000000200
  2MB PAGES: 0x00000000000003fb
  1GB PAGES: 0x0000000000000002
libxl: error: libxl_pci.c:1055:libxl__device_pci_add: PCI device 0:d:0.0 is not assignable
Waiting for domain Windows8 (domid 5) to die [pid 5545]
Domain 5 has shut down, reason code 1 0x1
Action for shutdown reason code 1 is restart
Domain 5 needs to be cleaned up: destroying the domain
libxl: error: libxl_pci.c:1001:libxl__device_pci_reset: The kernel doesn't support reset from sysfs for PCI device 0000:0d:00.0
libxl: error: libxl_pci.c:1265:do_pci_remove: xc_deassign_device failed
Done. Rebooting now
xc: info: VIRTUAL MEMORY ARRANGEMENT:
  Loader:        0000000000100000->00000000001ad64c
  TOTAL:         0000000000000000->00000000ff800000
  ENTRY ADDRESS: 0000000000100000
xc: info: PHYSICAL MEMORY ALLOCATION:
  4KB PAGES: 0x0000000000000200
  2MB PAGES: 0x00000000000003fb
  1GB PAGES: 0x0000000000000002
libxl: error: libxl_pci.c:1055:libxl__device_pci_add: PCI device 0:d:0.0 is not assignable
Waiting for domain Windows8 (domid 6) to die [pid 5545]
Domain 6 has shut down, reason code 1 0x1
Action for shutdown reason code 1 is restart
Domain 6 needs to be cleaned up: destroying the domain
libxl: error: libxl_pci.c:1001:libxl__device_pci_reset: The kernel doesn't support reset from sysfs for PCI device 0000:0d:00.0
libxl: error: libxl_pci.c:1265:do_pci_remove: xc_deassign_device failed
Done. Rebooting now
xc: info: VIRTUAL MEMORY ARRANGEMENT:
  Loader:        0000000000100000->00000000001ad64c
  TOTAL:         0000000000000000->00000000ff800000
  ENTRY ADDRESS: 0000000000100000
xc: info: PHYSICAL MEMORY ALLOCATION:
  4KB PAGES: 0x0000000000000200
  2MB PAGES: 0x00000000000003fb
  1GB PAGES: 0x0000000000000002
libxl: error: libxl_pci.c:1055:libxl__device_pci_add: PCI device 0:d:0.0 is not assignable
Waiting for domain Windows8 (domid 7) to die [pid 5545]
Domain 7 has shut down, reason code 1 0x1
Action for shutdown reason code 1 is restart
Domain 7 needs to be cleaned up: destroying the domain
libxl: error: libxl_pci.c:1001:libxl__device_pci_reset: The kernel doesn't support reset from sysfs for PCI device 0000:0d:00.0
libxl: error: libxl_pci.c:1265:do_pci_remove: xc_deassign_device failed
Done. Rebooting now
xc: info: VIRTUAL MEMORY ARRANGEMENT:
  Loader:        0000000000100000->00000000001ad64c
  TOTAL:         0000000000000000->00000000ff800000
  ENTRY ADDRESS: 0000000000100000
xc: info: PHYSICAL MEMORY ALLOCATION:
  4KB PAGES: 0x0000000000000200
  2MB PAGES: 0x00000000000003fb
  1GB PAGES: 0x0000000000000002
libxl: error: libxl_pci.c:1055:libxl__device_pci_add: PCI device 0:d:0.0 is not assignable
Waiting for domain Windows8 (domid 8) to die [pid 5545]
Domain 8 has been destroyed.

--------------060301030907070908060303
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--------------060301030907070908060303--


From xen-devel-bounces@lists.xen.org Wed Sep 19 16:44:01 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Sep 2012 16:44:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TENNH-00030w-LZ; Wed, 19 Sep 2012 16:43:43 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <singapore.mr.teo.en.ming@gmail.com>)
	id 1TENNF-00030r-JJ
	for xen-devel@lists.xen.org; Wed, 19 Sep 2012 16:43:42 +0000
Received: from [85.158.143.35:18115] by server-1.bemta-4.messagelabs.com id
	F4/39-05684-C36F9505; Wed, 19 Sep 2012 16:43:40 +0000
X-Env-Sender: singapore.mr.teo.en.ming@gmail.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1348073014!15743053!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-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8473 invoked from network); 19 Sep 2012 16:43:36 -0000
Received: from mail-pb0-f45.google.com (HELO mail-pb0-f45.google.com)
	(209.85.160.45)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Sep 2012 16:43:36 -0000
Received: by pbbrp12 with SMTP id rp12so2940985pbb.32
	for <multiple recipients>; Wed, 19 Sep 2012 09:43:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=message-id:disposition-notification-to:date:from:user-agent
	:mime-version:to:subject:content-type;
	bh=NhAEaT4RaQ8zkEU7XpSw6qrmedYXSJI/PPxUpKjERxI=;
	b=PY64vJkQntPimOZfS+lN+Kc9Wdu9kNOYzaynZygyOix+/LXQ7f5uzDMHhsZ/8W/6wi
	/dd9Y3cnqR46x9GuSX0ecbVPok8fGdTmI5JcLvL3gL8DFGksVOE/750FE85+IFYg00MS
	JXYNHf6Ap7UAPsq5VL2eIlPYgdaO4pYTuSqjlnaisF3xVC+H2yLjnbnrSnlAhqtjplZe
	j+RnW+1Wv35p2lDtgtlDXxUJRjs4BHY9Hz/lwnRha5OPSw/JMw+Hsz9ZOkzaZDY2Nb/J
	ZEFiji9ByKzqLQkTgHaxwHhGDksSDYKMA242Iyb6suSp567j94rqZXLqdiRucI1IVmAt
	xASg==
Received: by 10.68.116.228 with SMTP id jz4mr8786686pbb.166.1348073014138;
	Wed, 19 Sep 2012 09:43:34 -0700 (PDT)
Received: from [192.168.1.2] (cm70.gamma203.maxonline.com.sg. [202.156.203.70])
	by mx.google.com with ESMTPS id b6sm984792paz.9.2012.09.19.09.43.31
	(version=SSLv3 cipher=OTHER); Wed, 19 Sep 2012 09:43:33 -0700 (PDT)
Message-ID: <5059F632.3050808@gmail.com>
Date: Thu, 20 Sep 2012 00:43:30 +0800
From: "Teo En Ming (Zhang Enming)" <singapore.mr.teo.en.ming@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
MIME-Version: 1.0
To: "xen-users@lists.xen.org" <xen-users@lists.xen.org>, 
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	'Teo En Ming' <teo.en.ming@gmail.com>
Content-Type: multipart/mixed; boundary="------------060301030907070908060303"
Subject: [Xen-devel] VGA Passthrough with Xen 4.3-unstable?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a multi-part message in MIME format.
--------------060301030907070908060303
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Dear All,

I have tried to apply VGA passthrough patches hosted at Jean David 
Techer's website to Xen 4.3-unstable. However, I cannot get VGA 
passthrough to work with Xen 4.3-unstable. Are the VGA passthrough 
patches hosted at David Techer's website incompatible with Xen 4.3-unstable?

This is David Techer's website: 
http://www.davidgis.fr/blog/index.php?2011/12/07/860-xen-42unstable-patches-for-vga-pass-through

I have also provided error logs in this email for troubleshooting purposes.

Please advise. Thank you very much.

-- 
Yours sincerely,

Mr. Teo En Ming (Zhang Enming)
Singapore


--------------060301030907070908060303
Content-Type: text/x-log;
 name="qemu-dm-Windows8.log"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename="qemu-dm-Windows8.log"

domid: 21
Strip off blktap sub-type prefix to /etc/xen/images/windows8.img (drv 'aio')
Using file /etc/xen/images/windows8.img in read-write mode
Strip off blktap sub-type prefix to /home/flyon/windows8.iso (drv 'aio')
Using file /home/flyon/windows8.iso in read-only mode
Watching /local/domain/0/device-model/21/logdirty/cmd
Watching /local/domain/0/device-model/21/command
Watching /local/domain/21/cpu
qemu_map_cache_init nr_buckets = 10000 size 4194304
shared page at pfn feffd
buffered io page at pfn feffb
Guest uuid = 40290d87-cbd9-4656-841b-ba3d95621163
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/21/xen_extended_power_mgmt): read error
medium change watch on `hdc' (index: 1): aio:/home/flyon/windows8.iso
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
Log-dirty: no command yet.
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
vcpu-set: watch node error.
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
xs_read(/local/domain/21/log-throttling): read error
qemu: ignoring not-understood drive `/local/domain/21/log-throttling'
medium change watch on `/local/domain/21/log-throttling' - unknown device, ignored
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
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.

--------------060301030907070908060303
Content-Type: text/plain;
 name="qemu-dm-Windows8.log.1"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename="qemu-dm-Windows8.log.1"

domid: 20
Strip off blktap sub-type prefix to /etc/xen/images/windows8.img (drv 'aio')
Using file /etc/xen/images/windows8.img in read-write mode
Strip off blktap sub-type prefix to /home/flyon/windows8.iso (drv 'aio')
Using file /home/flyon/windows8.iso in read-only mode
Watching /local/domain/0/device-model/20/logdirty/cmd
Watching /local/domain/0/device-model/20/command
Watching /local/domain/20/cpu
qemu_map_cache_init nr_buckets = 10000 size 4194304
shared page at pfn feffd
buffered io page at pfn feffb
Guest uuid = 4a77731a-8b25-4fd8-ac7c-f4d607784917
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/20/xen_extended_power_mgmt): read error
medium change watch on `hdc' (index: 1): aio:/home/flyon/windows8.iso
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
Log-dirty: no command yet.
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
vcpu-set: watch node error.
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
xs_read(/local/domain/20/log-throttling): read error
qemu: ignoring not-understood drive `/local/domain/20/log-throttling'
medium change watch on `/local/domain/20/log-throttling' - unknown device, ignored
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
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.
reset requested in cpu_handle_ioreq.
Issued domain 20 reboot

--------------060301030907070908060303
Content-Type: text/plain;
 name="qemu-dm-Windows8.log.2"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename="qemu-dm-Windows8.log.2"

domid: 19
Strip off blktap sub-type prefix to /etc/xen/images/windows8.img (drv 'aio')
Using file /etc/xen/images/windows8.img in read-write mode
Strip off blktap sub-type prefix to /home/flyon/windows8.iso (drv 'aio')
Using file /home/flyon/windows8.iso in read-only mode
Watching /local/domain/0/device-model/19/logdirty/cmd
Watching /local/domain/0/device-model/19/command
Watching /local/domain/19/cpu
qemu_map_cache_init nr_buckets = 10000 size 4194304
shared page at pfn feffd
buffered io page at pfn feffb
Guest uuid = e72e564f-812a-49dd-9c78-d76a957ebeab
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/19/xen_extended_power_mgmt): read error
medium change watch on `hdc' (index: 1): aio:/home/flyon/windows8.iso
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
Log-dirty: no command yet.
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
vcpu-set: watch node error.
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
xs_read(/local/domain/19/log-throttling): read error
qemu: ignoring not-understood drive `/local/domain/19/log-throttling'
medium change watch on `/local/domain/19/log-throttling' - unknown device, ignored
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
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.
reset requested in cpu_handle_ioreq.
Issued domain 19 reboot

--------------060301030907070908060303
Content-Type: text/plain;
 name="qemu-dm-Windows8.log.3"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename="qemu-dm-Windows8.log.3"

domid: 18
Strip off blktap sub-type prefix to /etc/xen/images/windows8.img (drv 'aio')
Using file /etc/xen/images/windows8.img in read-write mode
Strip off blktap sub-type prefix to /home/flyon/windows8.iso (drv 'aio')
Using file /home/flyon/windows8.iso in read-only mode
Watching /local/domain/0/device-model/18/logdirty/cmd
Watching /local/domain/0/device-model/18/command
Watching /local/domain/18/cpu
qemu_map_cache_init nr_buckets = 10000 size 4194304
shared page at pfn feffd
buffered io page at pfn feffb
Guest uuid = 54da941e-ff5f-4db6-919a-00579c8fccc3
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/18/xen_extended_power_mgmt): read error
medium change watch on `hdc' (index: 1): aio:/home/flyon/windows8.iso
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
Log-dirty: no command yet.
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
vcpu-set: watch node error.
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
xs_read(/local/domain/18/log-throttling): read error
qemu: ignoring not-understood drive `/local/domain/18/log-throttling'
medium change watch on `/local/domain/18/log-throttling' - unknown device, ignored
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
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.
reset requested in cpu_handle_ioreq.
Issued domain 18 reboot

--------------060301030907070908060303
Content-Type: text/plain;
 name="qemu-dm-Windows8.log.4"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename="qemu-dm-Windows8.log.4"

domid: 17
Strip off blktap sub-type prefix to /etc/xen/images/windows8.img (drv 'aio')
Using file /etc/xen/images/windows8.img in read-write mode
Strip off blktap sub-type prefix to /home/flyon/windows8.iso (drv 'aio')
Using file /home/flyon/windows8.iso in read-only mode
Watching /local/domain/0/device-model/17/logdirty/cmd
Watching /local/domain/0/device-model/17/command
Watching /local/domain/17/cpu
qemu_map_cache_init nr_buckets = 10000 size 4194304
shared page at pfn feffd
buffered io page at pfn feffb
Guest uuid = 467e63fb-1054-4b1e-bb58-0ac6a2fe77ef
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/17/xen_extended_power_mgmt): read error
medium change watch on `hdc' (index: 1): aio:/home/flyon/windows8.iso
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
Log-dirty: no command yet.
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
vcpu-set: watch node error.
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
xs_read(/local/domain/17/log-throttling): read error
qemu: ignoring not-understood drive `/local/domain/17/log-throttling'
medium change watch on `/local/domain/17/log-throttling' - unknown device, ignored
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
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.
reset requested in cpu_handle_ioreq.
Issued domain 17 reboot

--------------060301030907070908060303
Content-Type: text/plain;
 name="qemu-dm-Windows8.log.5"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename="qemu-dm-Windows8.log.5"

domid: 16
Strip off blktap sub-type prefix to /etc/xen/images/windows8.img (drv 'aio')
Using file /etc/xen/images/windows8.img in read-write mode
Strip off blktap sub-type prefix to /home/flyon/windows8.iso (drv 'aio')
Using file /home/flyon/windows8.iso in read-only mode
Watching /local/domain/0/device-model/16/logdirty/cmd
Watching /local/domain/0/device-model/16/command
Watching /local/domain/16/cpu
qemu_map_cache_init nr_buckets = 10000 size 4194304
shared page at pfn feffd
buffered io page at pfn feffb
Guest uuid = fbe85911-c17d-4b2d-9ae0-33b2211cb22f
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/16/xen_extended_power_mgmt): read error
medium change watch on `hdc' (index: 1): aio:/home/flyon/windows8.iso
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
Log-dirty: no command yet.
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
vcpu-set: watch node error.
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
xs_read(/local/domain/16/log-throttling): read error
qemu: ignoring not-understood drive `/local/domain/16/log-throttling'
medium change watch on `/local/domain/16/log-throttling' - unknown device, ignored
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
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.
reset requested in cpu_handle_ioreq.
Issued domain 16 reboot

--------------060301030907070908060303
Content-Type: text/plain;
 name="qemu-dm-Windows8.log.6"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename="qemu-dm-Windows8.log.6"

domid: 15
Strip off blktap sub-type prefix to /etc/xen/images/windows8.img (drv 'aio')
Using file /etc/xen/images/windows8.img in read-write mode
Strip off blktap sub-type prefix to /home/flyon/windows8.iso (drv 'aio')
Using file /home/flyon/windows8.iso in read-only mode
Watching /local/domain/0/device-model/15/logdirty/cmd
Watching /local/domain/0/device-model/15/command
Watching /local/domain/15/cpu
qemu_map_cache_init nr_buckets = 10000 size 4194304
shared page at pfn feffd
buffered io page at pfn feffb
Guest uuid = 6ffa0353-1b02-4747-87f6-e30cb6067a76
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/15/xen_extended_power_mgmt): read error
medium change watch on `hdc' (index: 1): aio:/home/flyon/windows8.iso
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
Log-dirty: no command yet.
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
vcpu-set: watch node error.
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
xs_read(/local/domain/15/log-throttling): read error
qemu: ignoring not-understood drive `/local/domain/15/log-throttling'
medium change watch on `/local/domain/15/log-throttling' - unknown device, ignored
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
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.
reset requested in cpu_handle_ioreq.
Issued domain 15 reboot

--------------060301030907070908060303
Content-Type: text/plain;
 name="qemu-dm-Windows8.log.7"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename="qemu-dm-Windows8.log.7"

domid: 14
Strip off blktap sub-type prefix to /etc/xen/images/windows8.img (drv 'aio')
Using file /etc/xen/images/windows8.img in read-write mode
Strip off blktap sub-type prefix to /home/flyon/windows8.iso (drv 'aio')
Using file /home/flyon/windows8.iso in read-only mode
Watching /local/domain/0/device-model/14/logdirty/cmd
Watching /local/domain/0/device-model/14/command
Watching /local/domain/14/cpu
qemu_map_cache_init nr_buckets = 10000 size 4194304
shared page at pfn feffd
buffered io page at pfn feffb
Guest uuid = 908cd1e3-59b3-41f3-88a9-6d846fdbb675
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/14/xen_extended_power_mgmt): read error
medium change watch on `hdc' (index: 1): aio:/home/flyon/windows8.iso
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
Log-dirty: no command yet.
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
vcpu-set: watch node error.
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
xs_read(/local/domain/14/log-throttling): read error
qemu: ignoring not-understood drive `/local/domain/14/log-throttling'
medium change watch on `/local/domain/14/log-throttling' - unknown device, ignored
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
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.
reset requested in cpu_handle_ioreq.
Issued domain 14 reboot

--------------060301030907070908060303
Content-Type: text/plain;
 name="qemu-dm-Windows8.log.8"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename="qemu-dm-Windows8.log.8"

domid: 13
Strip off blktap sub-type prefix to /etc/xen/images/windows8.img (drv 'aio')
Using file /etc/xen/images/windows8.img in read-write mode
Strip off blktap sub-type prefix to /home/flyon/windows8.iso (drv 'aio')
Using file /home/flyon/windows8.iso in read-only mode
Watching /local/domain/0/device-model/13/logdirty/cmd
Watching /local/domain/0/device-model/13/command
Watching /local/domain/13/cpu
qemu_map_cache_init nr_buckets = 10000 size 4194304
shared page at pfn feffd
buffered io page at pfn feffb
Guest uuid = 7a9ba58a-35c9-4ad3-af42-5f371268d141
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/13/xen_extended_power_mgmt): read error
medium change watch on `hdc' (index: 1): aio:/home/flyon/windows8.iso
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
Log-dirty: no command yet.
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
vcpu-set: watch node error.
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
xs_read(/local/domain/13/log-throttling): read error
qemu: ignoring not-understood drive `/local/domain/13/log-throttling'
medium change watch on `/local/domain/13/log-throttling' - unknown device, ignored
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
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.
reset requested in cpu_handle_ioreq.
Issued domain 13 reboot

--------------060301030907070908060303
Content-Type: text/plain;
 name="qemu-dm-Windows8.log.9"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename="qemu-dm-Windows8.log.9"

domid: 12
Strip off blktap sub-type prefix to /etc/xen/images/windows8.img (drv 'aio')
Using file /etc/xen/images/windows8.img in read-write mode
Strip off blktap sub-type prefix to /home/flyon/windows8.iso (drv 'aio')
Using file /home/flyon/windows8.iso in read-only mode
Watching /local/domain/0/device-model/12/logdirty/cmd
Watching /local/domain/0/device-model/12/command
Watching /local/domain/12/cpu
qemu_map_cache_init nr_buckets = 10000 size 4194304
shared page at pfn feffd
buffered io page at pfn feffb
Guest uuid = 3fdbe19b-2484-4f51-a781-45feccb66d65
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/12/xen_extended_power_mgmt): read error
medium change watch on `hdc' (index: 1): aio:/home/flyon/windows8.iso
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
Log-dirty: no command yet.
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
vcpu-set: watch node error.
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
xs_read(/local/domain/12/log-throttling): read error
qemu: ignoring not-understood drive `/local/domain/12/log-throttling'
medium change watch on `/local/domain/12/log-throttling' - unknown device, ignored
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
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.
reset requested in cpu_handle_ioreq.
Issued domain 12 reboot

--------------060301030907070908060303
Content-Type: text/plain;
 name="qemu-dm-Windows8.log.10"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename="qemu-dm-Windows8.log.10"

domid: 11
Strip off blktap sub-type prefix to /etc/xen/images/windows8.img (drv 'aio')
Using file /etc/xen/images/windows8.img in read-write mode
Strip off blktap sub-type prefix to /home/flyon/windows8.iso (drv 'aio')
Using file /home/flyon/windows8.iso in read-only mode
Watching /local/domain/0/device-model/11/logdirty/cmd
Watching /local/domain/0/device-model/11/command
Watching /local/domain/11/cpu
qemu_map_cache_init nr_buckets = 10000 size 4194304
shared page at pfn feffd
buffered io page at pfn feffb
Guest uuid = ce6cf88a-65c6-4bf2-ab37-6881a1909bb5
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/11/xen_extended_power_mgmt): read error
medium change watch on `hdc' (index: 1): aio:/home/flyon/windows8.iso
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
Log-dirty: no command yet.
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
vcpu-set: watch node error.
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
xs_read(/local/domain/11/log-throttling): read error
qemu: ignoring not-understood drive `/local/domain/11/log-throttling'
medium change watch on `/local/domain/11/log-throttling' - unknown device, ignored
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
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.
reset requested in cpu_handle_ioreq.
Issued domain 11 reboot

--------------060301030907070908060303
Content-Type: text/plain;
 name="Windows8.txt"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
 filename="Windows8.txt"

IyBYTCBkb21haW4gY29uZmlndXJhdGlvbiBmaWxlIGZvciBXaW5kb3dzIDggQ29uc3VtZXIg
UHJldmlldyA2NC1iaXQgRW5nbGlzaCBIVk0gZG9tVQ0KIyBQbGVhc2UgcmVmZXIgdG8gIm1h
biB4bC5jZmciIGZvciBmdXJ0aGVyIGV4cGxhbmF0aW9ucy4NCiMgU2VlIGFsc28gZG9jcy9t
aXNjL3hsLW5ldHdvcmstY29uZmlndXJhdGlvbi5tYXJrZG93biBhbmQNCiMgZG9jcy9taXNj
L3hsLWRpc2stY29uZmlndXJhdGlvbi50eHQNCiMgV3JpdHRlbiBieSBUZW8gRW4gTWluZyAo
WmhhbmcgRW5taW5nKQ0KIyBFbWFpbDogdGVvLmVuLm1pbmdAZ21haWwuY29tDQojIE1vYmls
ZSBQaG9uZTogKzY1LTgzNjktMjYxOA0KIyBDb3VudHJ5OiBTaW5nYXBvcmUNCiMgRGF0ZTog
MTggTWFyIDIwMTIgU3VuDQpuYW1lPSJXaW5kb3dzOCINCiMgUHJvZHVjdCBLZXk6IFdKQlJY
LTJON0IyLUNDQkY2LVZQUDk3LVI4OFhWDQpidWlsZGVyPSJodm0iDQp2Y3B1cz0xMg0KbWVt
b3J5PTEyMDAwDQpvbl9wb3dlcm9mZj0iZGVzdHJveSINCm9uX3JlYm9vdD0icmVzdGFydCIN
Cm9uX2NyYXNoPSJkZXN0cm95Ig0KZGlzaz1bICdmb3JtYXQ9cmF3LCB2ZGV2PWhkYSwgYWNj
ZXNzPXJ3LCB0YXJnZXQ9L2V0Yy94ZW4vaW1hZ2VzL3dpbmRvd3M4LmltZycsICdmb3JtYXQ9
cmF3LCB2ZGV2PWhkYywgYWNjZXNzPXJvLCBkZXZ0eXBlPWNkcm9tLCB0YXJnZXQ9L2hvbWUv
Zmx5b24vd2luZG93czguaXNvJyBdDQp2aWY9WyAnYnJpZGdlPWV0aDAsdHlwZT1pb2VtdSxt
b2RlbD1lMTAwMCcgXQ0KI2Jvb3Q9W2N8ZHxuXQ0KIyBTZWxlY3RzIHRoZSBlbXVsYXRlZCB2
aXJ0dWFsIGRldmljZSB0byBib290IGZyb20uIE9wdGlvbnMgYXJlIGhhcmQgZGlzayAoYyks
IGNkLXJvbSAoZCkgb3IgbmV0d29yay9QWEUgKG4pLg0KIyBNdWx0aXBsZSBvcHRpb25zIGNh
biBiZSBnaXZlbiBhbmQgd2lsbCBiZSBhdHRlbXB0ZWQgaW4gdGhlIG9yZGVyIHRoZXkgYXJl
IGdpdmVuLiBlLmcuIHRvIGJvb3QgZnJvbSBjZC1yb20NCiMgYnV0IGZhbGxiYWNrIHRvIHRo
ZSBoYXJkIGRpc2sgeW91IGNhbiBnaXZlIGRjLiBUaGUgZGVmYXVsdCBpcyBjZC4NCmJvb3Q9
ImRjIg0KYWNwaT0xDQp4ZW5fcGxhdGZvcm1fcGNpPTENCnZpcmlkaWFuPTENCnN0ZHZnYT0x
DQoNCnZuYz0xDQp2bmNsaXN0ZW49IjE5Mi4xNjguMjUuNTAiDQp2bmNkaXNwbGF5PTANCnZu
Y3VudXNlZD0xDQp2bmNwYXNzd2Q9IiINCnNkbD0wDQp1c2I9MQ0KdXNiZGV2aWNlPSJ0YWJs
ZXQiDQojIEVuYWJsZSBYZW4gVkdBIFBhc3N0aHJvdWdoDQpnZnhfcGFzc3RocnU9MQ0KIyBW
R0EgUGFzc3Rocm91Z2ggTlZJRElBIFF1YWRybyA2MDAwDQpwY2kgPSBbICcwZDowMC4wJyBd
DQojIFBDSSBQYXNzdGhyb3VnaCBJbnRlbCBIRCBBdWRpbyBDb250cm9sbGVyLg0KI3BjaSA9
IFsgJzAwOjFiLjAnIF0NCiMgUENJIFBhc3N0aHJvdWdoIGFsbCB0aGUgVVNCIENvbnRyb2xs
ZXJzLg0KIyBwY2kgPSBbICcwMDoxYS4wJywnMDA6MWEuMScsJzAwOjFhLjInLCcwMDoxYS43
JywnMDA6MWQuMCcsJzAwOjFkLjEnLCcwMDoxZC4yJywnMDA6MWQuNycgXQ==
--------------060301030907070908060303
Content-Type: text/plain;
 name="xen1.txt"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
 filename="xen1.txt"

DQpbICAgIDIuNzI1MzE4XSBwY2kgMDAwMDowZDowMC4wOiByZWcgMTA6IFttZW0gMHhmODAw
MDAwMC0weGY5ZmZmZmZmXQ0KWyAgICAyLjcyNTMyOF0gcGNpIDAwMDA6MGQ6MDAuMDogcmVn
IDE0OiBbbWVtIDB4ZDgwMDAwMDAtMHhkZmZmZmZmZiA2NGJpdCBwcmVmXQ0KWyAgICAyLjcy
NTMzOF0gcGNpIDAwMDA6MGQ6MDAuMDogcmVnIDFjOiBbbWVtIDB4ZDQwMDAwMDAtMHhkN2Zm
ZmZmZiA2NGJpdCBwcmVmXQ0KWyAgICAyLjcyNTM1MV0gcGNpIDAwMDA6MGQ6MDAuMDogcmVn
IDMwOiBbbWVtIDB4MDAwMDAwMDAtMHgwMDA3ZmZmZiBwcmVmXQ0KWyAgICAyLjc2MzE1MF0g
cGNpIDAwMDA6MGQ6MDAuMDogQkFSIDY6IGFzc2lnbmVkIFttZW0gMHhmN2YwMDAwMC0weGY3
ZjdmZmZmIHByZWZdDQoNCjFzdCBtZW1vcnkgcmFuZ2UNCj09PT09PT09PT09PT09PT0NCg0K
bWF4ID0gMHhmOWZmZmZmZiA9IDQxOTQzMDM5OTkNCm1pbiA9IDB4ZjgwMDAwMDAgPSA0MTYw
NzQ5NTY4DQpkaWZmZXJlbmNlPW1heCAtIG1pbiArMSA9IDQxOTQzMDM5OTkgLSA0MTYwNzQ5
NTY4ICsxPSAzMzU1NDQzMiA9IDB4MDIwMDAwMDANCg0KbWF4ID0gMHhGOUZGRkZGRg0KbWlu
ID0gMHhGODAwMDAwMA0KZGlmZiA9IDB4MDIwMDAwMDANCg0KMm5kIG1lbW9yeSByYW5nZQ0K
PT09PT09PT09PT09PT09PQ0KDQptYXggPSAweGRmZmZmZmZmID0gMzc1ODA5NjM4Mw0KbWlu
ID0gMHhkODAwMDAwMCA9IDM2MjM4Nzg2NTYNCmRpZmZlcmVuY2UgPSBtYXggLSBtaW4gKyAx
ID0gMzc1ODA5NjM4MyAtIDM2MjM4Nzg2NTYgKyAxID0gMTM0MjE3NzI4ID0gMHgwODAwMDAw
MA0KDQptYXggPSAweERGRkZGRkZGDQptaW4gPSAweEQ4MDAwMDAwDQpkaWZmPSAweDA4MDAw
MDAwDQoNCjNyZCBtZW1vcnkgcmFuZ2UNCj09PT09PT09PT09PT09PT0NCg0KbWF4ID0gMHhk
N2ZmZmZmZiA9IDM2MjM4Nzg2NTUNCm1pbiA9IDB4ZDQwMDAwMDAgPSAzNTU2NzY5NzkyDQpk
aWZmZXJlbmNlID0gbWF4IC0gbWluICsgMSA9IDM2MjM4Nzg2NTUgLSAzNTU2NzY5NzkyICsg
MSA9IDY3MTA4ODY0ID0gMHgwNDAwMDAwMA0KDQptYXggPSAweEQ3RkZGRkZGDQptaW4gPSAw
eEQ0MDAwMDAwDQpkaWZmPSAweDA0MDAwMDAwDQoNCjR0aCBtZW1vcnkgcmFuZ2UNCj09PT09
PT09PT09PT09PT0NCg0KbWF4ID0gMHgwMDA3ZmZmZiA9IDUyNDI4Nw0KbWluID0gMHgwMDAw
MDAwMCA9IDANCmRpZmZlcmVuY2UgPSBtYXggLSBtaW4gKzEgPSA1MjQyODcgLSAwICsgMSA9
IDUyNDI4OCA9IDB4MDAwODAwMDANCg0KbWF4ID0gMHgwMDA3RkZGRg0KbWluID0gMHgwMDAw
MDAwMA0KZGlmZj0gMHgwMDA4MDAwMA0KDQoNClVVSUQgZDVlYzZiN2YtZTFkYi00YjQ2LWIw
NTAtZDBiZDQ2NDAzZjU5DQoNCnZtbGludXotMy41LjQteGVuLWZyYW5rLmx5b24tc2dwDQpp
bml0cmQuaW1nLTMuNS40LXhlbi1mcmFuay5seW9uLXNncA0KeGVuLmd6DQoNCnJvb3Q9L2Rl
di9tYXBwZXIvc25vdy1yb290IHJvIG5vbW9kZXNldA0KDQpmbHlvbkBzbm93On4kIGxzcGNp
IC1uIHwgZ3JlcCAiMGQ6MDAuMCINCjBkOjAwLjAgMDMwMDogMTBkZTowNmQ4IChyZXYgYTMp
DQoNCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09DQoN
CiMhL2Jpbi9zaA0Kc2V0IC14DQojIw0KU3RhcnRzIFNob3Jld2FsbCBGaXJld2FsbA0Kc3Vk
byBzZXJ2aWNlIHNob3Jld2FsbCByZXN0YXJ0DQojIw0KTG9hZHMgcGNpLXN0dWIga2VybmVs
IG1vZHVsZQ0Kc3VkbyBtb2Rwcm9iZSBwY2ktc3R1Yg0KIyMNClBhc3N0aHJvdWdoIFBhbGl0
IE5WSURJQSBHZWZvcmNlIDg0MDAgR1MgUENJZSB4MTYgVkdBIGNhcmQNCiMgZWNobyAiDQpQ
YXNzdGhyb3VnaCBQYWxpdCBOVklESUEgR2Vmb3JjZSA4NDAwIEdTIFZHQSBjYXJkLiINCnN1
ZG8gY2htb2Qgbyt3IC9zeXMvYnVzL3BjaS9kcml2ZXJzL3BjaS1zdHViL25ld19pZA0Kc3Vk
byBjaG1vZCBvK3cgL3N5cy9idXMvcGNpL2RldmljZXMvMDAwMDowMTowMC4wL2RyaXZlci91
bmJpbmQNCnN1ZG8gY2htb2Qgbyt3IC9zeXMvYnVzL3BjaS9kcml2ZXJzL3BjaS1zdHViL2Jp
bmQNCmVjaG8gIjEwZGUgMTBjMyIgPiAvc3lzL2J1cy9wY2kvZHJpdmVycy9wY2ktc3R1Yi9u
ZXdfaWQNCmVjaG8gIjAwMDA6MDE6MDAuMCIgPiAvc3lzL2J1cy9wY2kvZGV2aWNlcy8wMDAw
OjAxOjAwLjAvZHJpdmVyL3VuYmluZA0KZWNobyAiMDAwMDowMTowMC4wIiA+IC9zeXMvYnVz
L3BjaS9kcml2ZXJzL3BjaS1zdHViL2JpbmQNCiMjDQpQYXNzdGhyb3VnaCBJbnRlbCBIRCBB
dWRpbyBDb250cm9sbGVyDQojIGVjaG8gIg0KUGFzc3Rocm91Z2ggSW50ZWwgSEQgQXVkaW8g
Q29udHJvbGxlci4iDQpzdWRvIGNobW9kIG8rdyAvc3lzL2J1cy9wY2kvZHJpdmVycy9wY2kt
c3R1Yi9uZXdfaWQNCnN1ZG8gY2htb2Qgbyt3IC9zeXMvYnVzL3BjaS9kZXZpY2VzLzAwMDA6
MDA6MWIuMC9kcml2ZXIvdW5iaW5kDQpzdWRvIGNobW9kIG8rdyAvc3lzL2J1cy9wY2kvZHJp
dmVycy9wY2ktc3R1Yi9iaW5kDQplY2hvICI4MDg2IDNhNmUiID4gL3N5cy9idXMvcGNpL2Ry
aXZlcnMvcGNpLXN0dWIvbmV3X2lkDQplY2hvICIwMDAwOjAwOjFiLjAiID4gL3N5cy9idXMv
cGNpL2RldmljZXMvMDAwMDowMDoxYi4wL2RyaXZlci91bmJpbmQNCmVjaG8gIjAwMDA6MDA6
MWIuMCIgPiAvc3lzL2J1cy9wY2kvZHJpdmVycy9wY2ktc3R1Yi9iaW5kDQojIw0KV2FpdCBm
b3IgMTAgc2Vjb25kcw0KI3MNCmxlZXAgMTANCiMjDQpTdGFydCBXaW5kb3dzIEhWTSBkb21V
IHdpdGggVkdBIFBhc3N0aHJvdWdoDQojDQojc3VkbyB4bCBjcmVhdGUgL2V0Yy94ZW4vV2lu
ZG93c1hQSG9tZUVkaXRpb25TUDMNCnN1ZG8geGwgY3JlYXRlIC9ldGMveGVuL1dpbmRvd3M4
Q29uc3VtZXJQcmV2aWV3NjRiaXRFbmdsaXNo
--------------060301030907070908060303
Content-Type: text/x-log;
 name="xend.log"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
 filename="xend.log"

[2012-09-19 20:48:44 1730] INFO (SrvDaemon:332) Xend Daemon started
[2012-09-19 20:48:44 1730] INFO (SrvDaemon:336) Xend changeset: Mon Sep 1=
7 21:12:21 2012 +0100 25925:d1c3375c3f11.
[2012-09-19 20:48:44 1730] DEBUG (tcp:96) Listening on :8002
[2012-09-19 20:48:47 1730] DEBUG (XendNode:332) pscsi record count: 9
[2012-09-19 20:48:47 1730] DEBUG (XendCPUPool:747) recreate_active_pools
[2012-09-19 20:48:47 1730] DEBUG (XendDomainInfo:151) XendDomainInfo.recr=
eate({'max_vcpu_id': 23, 'cpu_time': 20156983226L, 'ssidref': 0, 'hvm': 0=
, 'shutdown_reason': 255, 'dying': 0, 'online_vcpus': 24, 'domid': 0, 'pa=
used': 0, 'crashed': 0, 'running': 1, 'maxmem_kb': 17179869180L, 'shutdow=
n': 0, 'mem_kb': 24692524L, 'blocked': 0, 'handle': [0, 0, 0, 0, 0, 0, 0,=
 0, 0, 0, 0, 0, 0, 0, 0, 0], 'cpupool': 0, 'name': 'Domain-0'})
[2012-09-19 20:48:47 1730] INFO (XendDomainInfo:169) Recreating domain 0,=
 UUID 00000000-0000-0000-0000-000000000000. at /local/domain/0
[2012-09-19 20:48:47 1730] DEBUG (XendDomainInfo:3426) Storing VM details=
: {'on_xend_stop': 'ignore', 'pool_name': 'Pool-0', 'shadow_memory': '0',=
 'uuid': '00000000-0000-0000-0000-000000000000', 'on_reboot': 'restart', =
'image': "(linux (kernel '') (superpages 0) (nomigrate 0) (tsc_mode 0))",=
 'on_poweroff': 'destroy', 'bootloader_args': '', 'on_xend_start': 'ignor=
e', 'on_crash': 'restart', 'xend/restart_count': '0', 'vcpus': '24', 'vcp=
u_avail': '16777215', 'bootloader': '', 'name': 'Domain-0'}
[2012-09-19 20:48:47 1730] DEBUG (XendDomainInfo:1795) Storing domain det=
ails: {'cpu/3/availability': 'online', 'cpu/6/availability': 'online', 'v=
m': '/vm/00000000-0000-0000-0000-000000000000', 'cpu/22/availability': 'o=
nline', 'control/platform-feature-multiprocessor-suspend': '1', 'cpu/17/a=
vailability': 'online', 'cpu/14/availability': 'online', 'console/limit':=
 '1048576', 'cpu/2/availability': 'online', 'cpu/11/availability': 'onlin=
e', 'cpu/1/availability': 'online', 'cpu/7/availability': 'online', 'memo=
ry/target': '24692524', 'cpu/20/availability': 'online', 'control/platfor=
m-feature-xs_reset_watches': '1', 'cpu/15/availability': 'online', 'descr=
iption': '', 'cpu/13/availability': 'online', 'cpu/8/availability': 'onli=
ne', 'cpu/9/availability': 'online', 'cpu/5/availability': 'online', 'cpu=
/23/availability': 'online', 'cpu/0/availability': 'online', 'cpu/18/avai=
lability': 'online', 'console/type': 'xenconsoled', 'cpu/12/availability'=
: 'online', 'cpu/19/availability': 'online', 'name': 'Domain-0', 'domid':=
 '0', 'cpu/4/availability': 'online', 'cpu/16/availability': 'online', 'c=
pu/21/availability': 'online', 'cpu/10/availability': 'online'}
[2012-09-19 20:48:47 1730] DEBUG (XendDomain:476) Adding Domain: 0
[2012-09-19 20:48:47 1730] DEBUG (XendDomain:410) number of vcpus to use =
is 0
[2012-09-19 20:48:47 1730] DEBUG (XendDomainInfo:1882) XendDomainInfo.han=
dleShutdownWatch
[2012-09-19 20:48:47 1730] WARNING (XendAPI:708) API call: VBD.set_device=
 not found
[2012-09-19 20:48:47 1730] WARNING (XendAPI:708) API call: VBD.set_type n=
ot found
[2012-09-19 20:48:47 1730] WARNING (XendAPI:708) API call: session.get_al=
l_records not found
[2012-09-19 20:48:47 1730] WARNING (XendAPI:708) API call: event.get_reco=
rd not found
[2012-09-19 20:48:47 1730] WARNING (XendAPI:708) API call: event.get_all =
not found
[2012-09-19 20:48:47 1730] WARNING (XendAPI:708) API call: VIF.set_device=
 not found
[2012-09-19 20:48:47 1730] WARNING (XendAPI:708) API call: VIF.set_MAC no=
t found
[2012-09-19 20:48:47 1730] WARNING (XendAPI:708) API call: VIF.set_MTU no=
t found
[2012-09-19 20:48:47 1730] WARNING (XendAPI:708) API call: debug.get_all =
not found
[2012-09-19 20:48:47 1730] INFO (XMLRPCServer:161) Opening Unix domain so=
cket XML-RPC server on /var/run/xend/xen-api.sock; authentication has bee=
n disabled for this server.
[2012-09-19 20:48:47 1730] INFO (XMLRPCServer:161) Opening Unix domain so=
cket XML-RPC server on /var/run/xend/xmlrpc.sock.
[2012-09-19 21:00:22 1730] DEBUG (SrvServer:77) SrvServer.cleanup()
[2012-09-19 21:00:22 1730] DEBUG (XMLRPCServer:251) XMLRPCServer.cleanup(=
)
[2012-09-19 21:00:22 1730] DEBUG (XMLRPCServer:251) XMLRPCServer.cleanup(=
)
[2012-09-19 21:00:22 1730] DEBUG (XendDomain:644) cleanup_domains
[2012-09-19 21:00:22 1729] INFO (SrvDaemon:220) Xend exited with status 0=
=2E
[2012-09-19 21:03:31 1691] INFO (SrvDaemon:332) Xend Daemon started
[2012-09-19 21:03:31 1691] INFO (SrvDaemon:336) Xend changeset: Mon Sep 1=
7 21:12:21 2012 +0100 25925:d1c3375c3f11.
[2012-09-19 21:03:31 1691] DEBUG (tcp:96) Listening on :8002
[2012-09-19 21:03:33 1691] DEBUG (XendNode:332) pscsi record count: 9
[2012-09-19 21:03:33 1691] DEBUG (XendCPUPool:747) recreate_active_pools
[2012-09-19 21:03:33 1691] DEBUG (XendDomainInfo:151) XendDomainInfo.recr=
eate({'max_vcpu_id': 23, 'cpu_time': 17093476257L, 'ssidref': 0, 'hvm': 0=
, 'shutdown_reason': 255, 'dying': 0, 'online_vcpus': 24, 'domid': 0, 'pa=
used': 0, 'crashed': 0, 'running': 1, 'maxmem_kb': 17179869180L, 'shutdow=
n': 0, 'mem_kb': 24692524L, 'blocked': 0, 'handle': [0, 0, 0, 0, 0, 0, 0,=
 0, 0, 0, 0, 0, 0, 0, 0, 0], 'cpupool': 0, 'name': 'Domain-0'})
[2012-09-19 21:03:33 1691] INFO (XendDomainInfo:169) Recreating domain 0,=
 UUID 00000000-0000-0000-0000-000000000000. at /local/domain/0
[2012-09-19 21:03:33 1691] DEBUG (XendDomainInfo:3426) Storing VM details=
: {'on_xend_stop': 'ignore', 'pool_name': 'Pool-0', 'shadow_memory': '0',=
 'uuid': '00000000-0000-0000-0000-000000000000', 'on_reboot': 'restart', =
'image': "(linux (kernel '') (superpages 0) (nomigrate 0) (tsc_mode 0))",=
 'on_poweroff': 'destroy', 'bootloader_args': '', 'on_xend_start': 'ignor=
e', 'on_crash': 'restart', 'xend/restart_count': '0', 'vcpus': '24', 'vcp=
u_avail': '16777215', 'bootloader': '', 'name': 'Domain-0'}
[2012-09-19 21:03:33 1691] DEBUG (XendDomainInfo:1795) Storing domain det=
ails: {'cpu/3/availability': 'online', 'cpu/6/availability': 'online', 'v=
m': '/vm/00000000-0000-0000-0000-000000000000', 'cpu/22/availability': 'o=
nline', 'control/platform-feature-multiprocessor-suspend': '1', 'cpu/17/a=
vailability': 'online', 'cpu/14/availability': 'online', 'console/limit':=
 '1048576', 'cpu/2/availability': 'online', 'cpu/11/availability': 'onlin=
e', 'cpu/1/availability': 'online', 'cpu/7/availability': 'online', 'memo=
ry/target': '24692524', 'cpu/20/availability': 'online', 'control/platfor=
m-feature-xs_reset_watches': '1', 'cpu/15/availability': 'online', 'descr=
iption': '', 'cpu/13/availability': 'online', 'cpu/8/availability': 'onli=
ne', 'cpu/9/availability': 'online', 'cpu/5/availability': 'online', 'cpu=
/23/availability': 'online', 'cpu/0/availability': 'online', 'cpu/18/avai=
lability': 'online', 'console/type': 'xenconsoled', 'cpu/12/availability'=
: 'online', 'cpu/19/availability': 'online', 'name': 'Domain-0', 'domid':=
 '0', 'cpu/4/availability': 'online', 'cpu/16/availability': 'online', 'c=
pu/21/availability': 'online', 'cpu/10/availability': 'online'}
[2012-09-19 21:03:33 1691] DEBUG (XendDomain:476) Adding Domain: 0
[2012-09-19 21:03:33 1691] DEBUG (XendDomain:410) number of vcpus to use =
is 0
[2012-09-19 21:03:33 1691] DEBUG (XendDomainInfo:1882) XendDomainInfo.han=
dleShutdownWatch
[2012-09-19 21:03:33 1691] WARNING (XendAPI:708) API call: VBD.set_device=
 not found
[2012-09-19 21:03:33 1691] WARNING (XendAPI:708) API call: VBD.set_type n=
ot found
[2012-09-19 21:03:33 1691] WARNING (XendAPI:708) API call: session.get_al=
l_records not found
[2012-09-19 21:03:33 1691] WARNING (XendAPI:708) API call: event.get_reco=
rd not found
[2012-09-19 21:03:33 1691] WARNING (XendAPI:708) API call: event.get_all =
not found
[2012-09-19 21:03:33 1691] WARNING (XendAPI:708) API call: VIF.set_device=
 not found
[2012-09-19 21:03:33 1691] WARNING (XendAPI:708) API call: VIF.set_MAC no=
t found
[2012-09-19 21:03:33 1691] WARNING (XendAPI:708) API call: VIF.set_MTU no=
t found
[2012-09-19 21:03:34 1691] WARNING (XendAPI:708) API call: debug.get_all =
not found
[2012-09-19 21:03:34 1691] INFO (XMLRPCServer:161) Opening Unix domain so=
cket XML-RPC server on /var/run/xend/xen-api.sock; authentication has bee=
n disabled for this server.
[2012-09-19 21:03:34 1691] INFO (XMLRPCServer:161) Opening Unix domain so=
cket XML-RPC server on /var/run/xend/xmlrpc.sock.
[2012-09-19 22:18:22 1691] DEBUG (SrvServer:77) SrvServer.cleanup()
[2012-09-19 22:18:22 1691] DEBUG (XMLRPCServer:251) XMLRPCServer.cleanup(=
)
[2012-09-19 22:18:22 1691] DEBUG (XMLRPCServer:251) XMLRPCServer.cleanup(=
)
[2012-09-19 22:18:22 1691] DEBUG (XendDomain:644) cleanup_domains
[2012-09-19 22:18:22 1689] INFO (SrvDaemon:220) Xend exited with status 0=
=2E
[2012-09-19 22:37:19 6950] INFO (SrvDaemon:332) Xend Daemon started
[2012-09-19 22:37:19 6950] INFO (SrvDaemon:336) Xend changeset: Mon Sep 1=
7 21:12:21 2012 +0100 25925:d1c3375c3f11.
[2012-09-19 22:37:19 6950] DEBUG (tcp:96) Listening on :8002
[2012-09-19 22:37:22 6950] DEBUG (XendNode:332) pscsi record count: 12
[2012-09-19 22:37:22 6950] DEBUG (XendCPUPool:747) recreate_active_pools
[2012-09-19 22:37:22 6950] DEBUG (XendDomainInfo:151) XendDomainInfo.recr=
eate({'max_vcpu_id': 23, 'cpu_time': 3726170848291L, 'ssidref': 0, 'hvm':=
 0, 'shutdown_reason': 255, 'dying': 0, 'online_vcpus': 24, 'domid': 0, '=
paused': 0, 'crashed': 0, 'running': 1, 'maxmem_kb': 17179869180L, 'shutd=
own': 0, 'mem_kb': 12293932L, 'blocked': 0, 'handle': [0, 0, 0, 0, 0, 0, =
0, 0, 0, 0, 0, 0, 0, 0, 0, 0], 'cpupool': 0, 'name': 'Domain-0'})
[2012-09-19 22:37:22 6950] INFO (XendDomainInfo:169) Recreating domain 0,=
 UUID 00000000-0000-0000-0000-000000000000. at /local/domain/0
[2012-09-19 22:37:22 6950] DEBUG (XendDomain:476) Adding Domain: 0
[2012-09-19 22:37:22 6950] DEBUG (XendDomainInfo:1882) XendDomainInfo.han=
dleShutdownWatch
[2012-09-19 22:37:22 6950] DEBUG (XendDomain:410) number of vcpus to use =
is 0
[2012-09-19 22:37:22 6950] WARNING (XendAPI:708) API call: VBD.set_device=
 not found
[2012-09-19 22:37:22 6950] WARNING (XendAPI:708) API call: VBD.set_type n=
ot found
[2012-09-19 22:37:22 6950] WARNING (XendAPI:708) API call: session.get_al=
l_records not found
[2012-09-19 22:37:22 6950] WARNING (XendAPI:708) API call: event.get_reco=
rd not found
[2012-09-19 22:37:22 6950] WARNING (XendAPI:708) API call: event.get_all =
not found
[2012-09-19 22:37:22 6950] WARNING (XendAPI:708) API call: VIF.set_device=
 not found
[2012-09-19 22:37:22 6950] WARNING (XendAPI:708) API call: VIF.set_MAC no=
t found
[2012-09-19 22:37:22 6950] WARNING (XendAPI:708) API call: VIF.set_MTU no=
t found
[2012-09-19 22:37:22 6950] WARNING (XendAPI:708) API call: debug.get_all =
not found
[2012-09-19 22:37:22 6950] INFO (XMLRPCServer:161) Opening Unix domain so=
cket XML-RPC server on /var/run/xend/xen-api.sock; authentication has bee=
n disabled for this server.
[2012-09-19 22:37:22 6950] INFO (XMLRPCServer:161) Opening Unix domain so=
cket XML-RPC server on /var/run/xend/xmlrpc.sock.
[2012-09-19 22:38:16 6950] DEBUG (SrvServer:77) SrvServer.cleanup()
[2012-09-19 22:38:16 6950] DEBUG (XMLRPCServer:251) XMLRPCServer.cleanup(=
)
[2012-09-19 22:38:16 6950] DEBUG (XMLRPCServer:251) XMLRPCServer.cleanup(=
)
[2012-09-19 22:38:16 6950] DEBUG (XendDomain:644) cleanup_domains
[2012-09-19 22:38:16 6949] INFO (SrvDaemon:220) Xend exited with status 0=
=2E

--------------060301030907070908060303
Content-Type: text/x-log;
 name="xend-debug.log"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename="xend-debug.log"

Xend started at Wed Sep 19 20:48:44 2012.
cat: /sys/bus/scsi/devices/target1:0:0/vendor: No such file or directory
cat: /sys/bus/scsi/devices/target1:0:0/model: No such file or directory
cat: /sys/bus/scsi/devices/target1:0:0/type: No such file or directory
cat: /sys/bus/scsi/devices/target1:0:0/rev: No such file or directory
cat: /sys/bus/scsi/devices/target1:0:0/scsi_level: No such file or directory
cat: /sys/bus/scsi/devices/target2:0:0/vendor: No such file or directory
cat: /sys/bus/scsi/devices/target2:0:0/model: No such file or directory
cat: /sys/bus/scsi/devices/target2:0:0/type: No such file or directory
cat: /sys/bus/scsi/devices/target2:0:0/rev: No such file or directory
cat: /sys/bus/scsi/devices/target2:0:0/scsi_level: No such file or directory
cat: /sys/bus/scsi/devices/target2:3:0/vendor: No such file or directory
cat: /sys/bus/scsi/devices/target2:3:0/model: No such file or directory
cat: /sys/bus/scsi/devices/target2:3:0/type: No such file or directory
cat: /sys/bus/scsi/devices/target2:3:0/rev: No such file or directory
cat: /sys/bus/scsi/devices/target2:3:0/scsi_level: No such file or directory
cat: /sys/bus/scsi/devices/host0/vendor: No such file or directory
cat: /sys/bus/scsi/devices/host0/model: No such file or directory
cat: /sys/bus/scsi/devices/host0/type: No such file or directory
cat: /sys/bus/scsi/devices/host0/rev: No such file or directory
cat: /sys/bus/scsi/devices/host0/scsi_level: No such file or directory
cat: /sys/bus/scsi/devices/host1/vendor: No such file or directory
cat: /sys/bus/scsi/devices/host1/model: No such file or directory
cat: /sys/bus/scsi/devices/host1/type: No such file or directory
cat: /sys/bus/scsi/devices/host1/rev: No such file or directory
cat: /sys/bus/scsi/devices/host1/scsi_level: No such file or directory
cat: /sys/bus/scsi/devices/host2/vendor: No such file or directory
cat: /sys/bus/scsi/devices/host2/model: No such file or directory
cat: /sys/bus/scsi/devices/host2/type: No such file or directory
cat: /sys/bus/scsi/devices/host2/rev: No such file or directory
cat: /sys/bus/scsi/devices/host2/scsi_level: No such file or directory
Xend started at Wed Sep 19 21:03:31 2012.
cat: /sys/bus/scsi/devices/target1:0:0/vendor: No such file or directory
cat: /sys/bus/scsi/devices/target1:0:0/model: No such file or directory
cat: /sys/bus/scsi/devices/target1:0:0/type: No such file or directory
cat: /sys/bus/scsi/devices/target1:0:0/rev: No such file or directory
cat: /sys/bus/scsi/devices/target1:0:0/scsi_level: No such file or directory
cat: /sys/bus/scsi/devices/target2:0:0/vendor: No such file or directory
cat: /sys/bus/scsi/devices/target2:0:0/model: No such file or directory
cat: /sys/bus/scsi/devices/target2:0:0/type: No such file or directory
cat: /sys/bus/scsi/devices/target2:0:0/rev: No such file or directory
cat: /sys/bus/scsi/devices/target2:0:0/scsi_level: No such file or directory
cat: /sys/bus/scsi/devices/target2:3:0/vendor: No such file or directory
cat: /sys/bus/scsi/devices/target2:3:0/model: No such file or directory
cat: /sys/bus/scsi/devices/target2:3:0/type: No such file or directory
cat: /sys/bus/scsi/devices/target2:3:0/rev: No such file or directory
cat: /sys/bus/scsi/devices/target2:3:0/scsi_level: No such file or directory
cat: /sys/bus/scsi/devices/host0/vendor: No such file or directory
cat: /sys/bus/scsi/devices/host0/model: No such file or directory
cat: /sys/bus/scsi/devices/host0/type: No such file or directory
cat: /sys/bus/scsi/devices/host0/rev: No such file or directory
cat: /sys/bus/scsi/devices/host0/scsi_level: No such file or directory
cat: /sys/bus/scsi/devices/host1/vendor: No such file or directory
cat: /sys/bus/scsi/devices/host1/model: No such file or directory
cat: /sys/bus/scsi/devices/host1/type: No such file or directory
cat: /sys/bus/scsi/devices/host1/rev: No such file or directory
cat: /sys/bus/scsi/devices/host1/scsi_level: No such file or directory
cat: /sys/bus/scsi/devices/host2/vendor: No such file or directory
cat: /sys/bus/scsi/devices/host2/model: No such file or directory
cat: /sys/bus/scsi/devices/host2/type: No such file or directory
cat: /sys/bus/scsi/devices/host2/rev: No such file or directory
cat: /sys/bus/scsi/devices/host2/scsi_level: No such file or directory
Xend started at Wed Sep 19 22:37:19 2012.
cat: /sys/bus/scsi/devices/target1:0:0/vendor: No such file or directory
cat: /sys/bus/scsi/devices/target1:0:0/model: No such file or directory
cat: /sys/bus/scsi/devices/target1:0:0/type: No such file or directory
cat: /sys/bus/scsi/devices/target1:0:0/rev: No such file or directory
cat: /sys/bus/scsi/devices/target1:0:0/scsi_level: No such file or directory
cat: /sys/bus/scsi/devices/target2:0:0/vendor: No such file or directory
cat: /sys/bus/scsi/devices/target2:0:0/model: No such file or directory
cat: /sys/bus/scsi/devices/target2:0:0/type: No such file or directory
cat: /sys/bus/scsi/devices/target2:0:0/rev: No such file or directory
cat: /sys/bus/scsi/devices/target2:0:0/scsi_level: No such file or directory
cat: /sys/bus/scsi/devices/target2:3:0/vendor: No such file or directory
cat: /sys/bus/scsi/devices/target2:3:0/model: No such file or directory
cat: /sys/bus/scsi/devices/target2:3:0/type: No such file or directory
cat: /sys/bus/scsi/devices/target2:3:0/rev: No such file or directory
cat: /sys/bus/scsi/devices/target2:3:0/scsi_level: No such file or directory
cat: /sys/bus/scsi/devices/target3:0:0/vendor: No such file or directory
cat: /sys/bus/scsi/devices/target3:0:0/model: No such file or directory
cat: /sys/bus/scsi/devices/target3:0:0/type: No such file or directory
cat: /sys/bus/scsi/devices/target3:0:0/rev: No such file or directory
cat: /sys/bus/scsi/devices/target3:0:0/scsi_level: No such file or directory
cat: /sys/bus/scsi/devices/host0/vendor: No such file or directory
cat: /sys/bus/scsi/devices/host0/model: No such file or directory
cat: /sys/bus/scsi/devices/host0/type: No such file or directory
cat: /sys/bus/scsi/devices/host0/rev: No such file or directory
cat: /sys/bus/scsi/devices/host0/scsi_level: No such file or directory
cat: /sys/bus/scsi/devices/host1/vendor: No such file or directory
cat: /sys/bus/scsi/devices/host1/model: No such file or directory
cat: /sys/bus/scsi/devices/host1/type: No such file or directory
cat: /sys/bus/scsi/devices/host1/rev: No such file or directory
cat: /sys/bus/scsi/devices/host1/scsi_level: No such file or directory
cat: /sys/bus/scsi/devices/host2/vendor: No such file or directory
cat: /sys/bus/scsi/devices/host2/model: No such file or directory
cat: /sys/bus/scsi/devices/host2/type: No such file or directory
cat: /sys/bus/scsi/devices/host2/rev: No such file or directory
cat: /sys/bus/scsi/devices/host2/scsi_level: No such file or directory
cat: /sys/bus/scsi/devices/host3/vendor: No such file or directory
cat: /sys/bus/scsi/devices/host3/model: No such file or directory
cat: /sys/bus/scsi/devices/host3/type: No such file or directory
cat: /sys/bus/scsi/devices/host3/rev: No such file or directory
cat: /sys/bus/scsi/devices/host3/scsi_level: No such file or directory

--------------060301030907070908060303
Content-Type: text/x-log;
 name="xen-hotplug.log"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename="xen-hotplug.log"

RTNETLINK answers: Operation not supported
RTNETLINK answers: Operation not supported
RTNETLINK answers: Operation not supported
RTNETLINK answers: Operation not supported
RTNETLINK answers: Operation not supported
RTNETLINK answers: Operation not supported
RTNETLINK answers: Operation not supported
RTNETLINK answers: Operation not supported
RTNETLINK answers: Operation not supported
RTNETLINK answers: Operation not supported
RTNETLINK answers: Operation not supported
RTNETLINK answers: Operation not supported
RTNETLINK answers: Operation not supported
RTNETLINK answers: Operation not supported
RTNETLINK answers: Operation not supported
RTNETLINK answers: Operation not supported
RTNETLINK answers: Operation not supported
RTNETLINK answers: Operation not supported
RTNETLINK answers: Operation not supported
RTNETLINK answers: Operation not supported

--------------060301030907070908060303
Content-Type: text/x-log;
 name="xl-Windows8.log"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename="xl-Windows8.log"

Waiting for domain Windows8 (domid 9) to die [pid 7447]
Domain 9 has shut down, reason code 1 0x1
Action for shutdown reason code 1 is restart
Domain 9 needs to be cleaned up: destroying the domain
libxl: error: libxl_pci.c:1001:libxl__device_pci_reset: The kernel doesn't support reset from sysfs for PCI device 0000:0d:00.0
libxl: error: libxl_pci.c:1265:do_pci_remove: xc_deassign_device failed
Done. Rebooting now
xc: info: VIRTUAL MEMORY ARRANGEMENT:
  Loader:        0000000000100000->00000000001ad64c
  TOTAL:         0000000000000000->00000000ff800000
  ENTRY ADDRESS: 0000000000100000
xc: info: PHYSICAL MEMORY ALLOCATION:
  4KB PAGES: 0x0000000000000200
  2MB PAGES: 0x00000000000003fb
  1GB PAGES: 0x0000000000000002
libxl: error: libxl_pci.c:1055:libxl__device_pci_add: PCI device 0:d:0.0 is not assignable
Waiting for domain Windows8 (domid 10) to die [pid 7447]
Domain 10 has shut down, reason code 1 0x1
Action for shutdown reason code 1 is restart
Domain 10 needs to be cleaned up: destroying the domain
libxl: error: libxl_pci.c:1001:libxl__device_pci_reset: The kernel doesn't support reset from sysfs for PCI device 0000:0d:00.0
libxl: error: libxl_pci.c:1265:do_pci_remove: xc_deassign_device failed
Done. Rebooting now
xc: info: VIRTUAL MEMORY ARRANGEMENT:
  Loader:        0000000000100000->00000000001ad64c
  TOTAL:         0000000000000000->00000000ff800000
  ENTRY ADDRESS: 0000000000100000
xc: info: PHYSICAL MEMORY ALLOCATION:
  4KB PAGES: 0x0000000000000200
  2MB PAGES: 0x00000000000003fb
  1GB PAGES: 0x0000000000000002
libxl: error: libxl_pci.c:1055:libxl__device_pci_add: PCI device 0:d:0.0 is not assignable
Waiting for domain Windows8 (domid 11) to die [pid 7447]
Domain 11 has shut down, reason code 1 0x1
Action for shutdown reason code 1 is restart
Domain 11 needs to be cleaned up: destroying the domain
libxl: error: libxl_pci.c:1001:libxl__device_pci_reset: The kernel doesn't support reset from sysfs for PCI device 0000:0d:00.0
libxl: error: libxl_pci.c:1265:do_pci_remove: xc_deassign_device failed
Done. Rebooting now
xc: info: VIRTUAL MEMORY ARRANGEMENT:
  Loader:        0000000000100000->00000000001ad64c
  TOTAL:         0000000000000000->00000000ff800000
  ENTRY ADDRESS: 0000000000100000
xc: info: PHYSICAL MEMORY ALLOCATION:
  4KB PAGES: 0x0000000000000200
  2MB PAGES: 0x00000000000003fb
  1GB PAGES: 0x0000000000000002
libxl: error: libxl_pci.c:1055:libxl__device_pci_add: PCI device 0:d:0.0 is not assignable
Waiting for domain Windows8 (domid 12) to die [pid 7447]
Domain 12 has shut down, reason code 1 0x1
Action for shutdown reason code 1 is restart
Domain 12 needs to be cleaned up: destroying the domain
libxl: error: libxl_pci.c:1001:libxl__device_pci_reset: The kernel doesn't support reset from sysfs for PCI device 0000:0d:00.0
libxl: error: libxl_pci.c:1265:do_pci_remove: xc_deassign_device failed
Done. Rebooting now
xc: info: VIRTUAL MEMORY ARRANGEMENT:
  Loader:        0000000000100000->00000000001ad64c
  TOTAL:         0000000000000000->00000000ff800000
  ENTRY ADDRESS: 0000000000100000
xc: info: PHYSICAL MEMORY ALLOCATION:
  4KB PAGES: 0x0000000000000200
  2MB PAGES: 0x00000000000003fb
  1GB PAGES: 0x0000000000000002
libxl: error: libxl_pci.c:1055:libxl__device_pci_add: PCI device 0:d:0.0 is not assignable
Waiting for domain Windows8 (domid 13) to die [pid 7447]
Domain 13 has shut down, reason code 1 0x1
Action for shutdown reason code 1 is restart
Domain 13 needs to be cleaned up: destroying the domain
libxl: error: libxl_pci.c:1001:libxl__device_pci_reset: The kernel doesn't support reset from sysfs for PCI device 0000:0d:00.0
libxl: error: libxl_pci.c:1265:do_pci_remove: xc_deassign_device failed
Done. Rebooting now
xc: info: VIRTUAL MEMORY ARRANGEMENT:
  Loader:        0000000000100000->00000000001ad64c
  TOTAL:         0000000000000000->00000000ff800000
  ENTRY ADDRESS: 0000000000100000
xc: info: PHYSICAL MEMORY ALLOCATION:
  4KB PAGES: 0x0000000000000200
  2MB PAGES: 0x00000000000003fb
  1GB PAGES: 0x0000000000000002
libxl: error: libxl_pci.c:1055:libxl__device_pci_add: PCI device 0:d:0.0 is not assignable
Waiting for domain Windows8 (domid 14) to die [pid 7447]
Domain 14 has shut down, reason code 1 0x1
Action for shutdown reason code 1 is restart
Domain 14 needs to be cleaned up: destroying the domain
libxl: error: libxl_pci.c:1001:libxl__device_pci_reset: The kernel doesn't support reset from sysfs for PCI device 0000:0d:00.0
libxl: error: libxl_pci.c:1265:do_pci_remove: xc_deassign_device failed
Done. Rebooting now
xc: info: VIRTUAL MEMORY ARRANGEMENT:
  Loader:        0000000000100000->00000000001ad64c
  TOTAL:         0000000000000000->00000000ff800000
  ENTRY ADDRESS: 0000000000100000
xc: info: PHYSICAL MEMORY ALLOCATION:
  4KB PAGES: 0x0000000000000200
  2MB PAGES: 0x00000000000003fb
  1GB PAGES: 0x0000000000000002
libxl: error: libxl_pci.c:1055:libxl__device_pci_add: PCI device 0:d:0.0 is not assignable
Waiting for domain Windows8 (domid 15) to die [pid 7447]
Domain 15 has shut down, reason code 1 0x1
Action for shutdown reason code 1 is restart
Domain 15 needs to be cleaned up: destroying the domain
libxl: error: libxl_pci.c:1001:libxl__device_pci_reset: The kernel doesn't support reset from sysfs for PCI device 0000:0d:00.0
libxl: error: libxl_pci.c:1265:do_pci_remove: xc_deassign_device failed
Done. Rebooting now
xc: info: VIRTUAL MEMORY ARRANGEMENT:
  Loader:        0000000000100000->00000000001ad64c
  TOTAL:         0000000000000000->00000000ff800000
  ENTRY ADDRESS: 0000000000100000
xc: info: PHYSICAL MEMORY ALLOCATION:
  4KB PAGES: 0x0000000000000200
  2MB PAGES: 0x00000000000003fb
  1GB PAGES: 0x0000000000000002
libxl: error: libxl_pci.c:1055:libxl__device_pci_add: PCI device 0:d:0.0 is not assignable
Waiting for domain Windows8 (domid 16) to die [pid 7447]
Domain 16 has shut down, reason code 1 0x1
Action for shutdown reason code 1 is restart
Domain 16 needs to be cleaned up: destroying the domain
libxl: error: libxl_pci.c:1001:libxl__device_pci_reset: The kernel doesn't support reset from sysfs for PCI device 0000:0d:00.0
libxl: error: libxl_pci.c:1265:do_pci_remove: xc_deassign_device failed
Done. Rebooting now
xc: info: VIRTUAL MEMORY ARRANGEMENT:
  Loader:        0000000000100000->00000000001ad64c
  TOTAL:         0000000000000000->00000000ff800000
  ENTRY ADDRESS: 0000000000100000
xc: info: PHYSICAL MEMORY ALLOCATION:
  4KB PAGES: 0x0000000000000200
  2MB PAGES: 0x00000000000003fb
  1GB PAGES: 0x0000000000000002
libxl: error: libxl_pci.c:1055:libxl__device_pci_add: PCI device 0:d:0.0 is not assignable
Waiting for domain Windows8 (domid 17) to die [pid 7447]
Domain 17 has shut down, reason code 1 0x1
Action for shutdown reason code 1 is restart
Domain 17 needs to be cleaned up: destroying the domain
libxl: error: libxl_pci.c:1001:libxl__device_pci_reset: The kernel doesn't support reset from sysfs for PCI device 0000:0d:00.0
libxl: error: libxl_pci.c:1265:do_pci_remove: xc_deassign_device failed
Done. Rebooting now
xc: info: VIRTUAL MEMORY ARRANGEMENT:
  Loader:        0000000000100000->00000000001ad64c
  TOTAL:         0000000000000000->00000000ff800000
  ENTRY ADDRESS: 0000000000100000
xc: info: PHYSICAL MEMORY ALLOCATION:
  4KB PAGES: 0x0000000000000200
  2MB PAGES: 0x00000000000003fb
  1GB PAGES: 0x0000000000000002
libxl: error: libxl_pci.c:1055:libxl__device_pci_add: PCI device 0:d:0.0 is not assignable
Waiting for domain Windows8 (domid 18) to die [pid 7447]
Domain 18 has shut down, reason code 1 0x1
Action for shutdown reason code 1 is restart
Domain 18 needs to be cleaned up: destroying the domain
libxl: error: libxl_pci.c:1001:libxl__device_pci_reset: The kernel doesn't support reset from sysfs for PCI device 0000:0d:00.0
libxl: error: libxl_pci.c:1265:do_pci_remove: xc_deassign_device failed
Done. Rebooting now
xc: info: VIRTUAL MEMORY ARRANGEMENT:
  Loader:        0000000000100000->00000000001ad64c
  TOTAL:         0000000000000000->00000000ff800000
  ENTRY ADDRESS: 0000000000100000
xc: info: PHYSICAL MEMORY ALLOCATION:
  4KB PAGES: 0x0000000000000200
  2MB PAGES: 0x00000000000003fb
  1GB PAGES: 0x0000000000000002
libxl: error: libxl_pci.c:1055:libxl__device_pci_add: PCI device 0:d:0.0 is not assignable
Waiting for domain Windows8 (domid 19) to die [pid 7447]
Domain 19 has shut down, reason code 1 0x1
Action for shutdown reason code 1 is restart
Domain 19 needs to be cleaned up: destroying the domain
libxl: error: libxl_pci.c:1001:libxl__device_pci_reset: The kernel doesn't support reset from sysfs for PCI device 0000:0d:00.0
libxl: error: libxl_pci.c:1265:do_pci_remove: xc_deassign_device failed
Done. Rebooting now
xc: info: VIRTUAL MEMORY ARRANGEMENT:
  Loader:        0000000000100000->00000000001ad64c
  TOTAL:         0000000000000000->00000000ff800000
  ENTRY ADDRESS: 0000000000100000
xc: info: PHYSICAL MEMORY ALLOCATION:
  4KB PAGES: 0x0000000000000200
  2MB PAGES: 0x00000000000003fb
  1GB PAGES: 0x0000000000000002
libxl: error: libxl_pci.c:1055:libxl__device_pci_add: PCI device 0:d:0.0 is not assignable
Waiting for domain Windows8 (domid 20) to die [pid 7447]
Domain 20 has shut down, reason code 1 0x1
Action for shutdown reason code 1 is restart
Domain 20 needs to be cleaned up: destroying the domain
libxl: error: libxl_pci.c:1001:libxl__device_pci_reset: The kernel doesn't support reset from sysfs for PCI device 0000:0d:00.0
libxl: error: libxl_pci.c:1265:do_pci_remove: xc_deassign_device failed
Done. Rebooting now
xc: info: VIRTUAL MEMORY ARRANGEMENT:
  Loader:        0000000000100000->00000000001ad64c
  TOTAL:         0000000000000000->00000000ff800000
  ENTRY ADDRESS: 0000000000100000
xc: info: PHYSICAL MEMORY ALLOCATION:
  4KB PAGES: 0x0000000000000200
  2MB PAGES: 0x00000000000003fb
  1GB PAGES: 0x0000000000000002
libxl: error: libxl_pci.c:1055:libxl__device_pci_add: PCI device 0:d:0.0 is not assignable
Waiting for domain Windows8 (domid 21) to die [pid 7447]

--------------060301030907070908060303
Content-Type: text/plain;
 name="xl-Windows8.log.1"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename="xl-Windows8.log.1"

Waiting for domain Windows8 (domid 2) to die [pid 5545]
Domain 2 has shut down, reason code 1 0x1
Action for shutdown reason code 1 is restart
Domain 2 needs to be cleaned up: destroying the domain
libxl: error: libxl_pci.c:1001:libxl__device_pci_reset: The kernel doesn't support reset from sysfs for PCI device 0000:0d:00.0
libxl: error: libxl_pci.c:1265:do_pci_remove: xc_deassign_device failed
Done. Rebooting now
xc: info: VIRTUAL MEMORY ARRANGEMENT:
  Loader:        0000000000100000->00000000001ad64c
  TOTAL:         0000000000000000->00000000ff800000
  ENTRY ADDRESS: 0000000000100000
xc: info: PHYSICAL MEMORY ALLOCATION:
  4KB PAGES: 0x0000000000000200
  2MB PAGES: 0x00000000000003fb
  1GB PAGES: 0x0000000000000002
libxl: error: libxl_pci.c:1055:libxl__device_pci_add: PCI device 0:d:0.0 is not assignable
Waiting for domain Windows8 (domid 3) to die [pid 5545]
Domain 3 has shut down, reason code 1 0x1
Action for shutdown reason code 1 is restart
Domain 3 needs to be cleaned up: destroying the domain
libxl: error: libxl_pci.c:1001:libxl__device_pci_reset: The kernel doesn't support reset from sysfs for PCI device 0000:0d:00.0
libxl: error: libxl_pci.c:1265:do_pci_remove: xc_deassign_device failed
Done. Rebooting now
xc: info: VIRTUAL MEMORY ARRANGEMENT:
  Loader:        0000000000100000->00000000001ad64c
  TOTAL:         0000000000000000->00000000ff800000
  ENTRY ADDRESS: 0000000000100000
xc: info: PHYSICAL MEMORY ALLOCATION:
  4KB PAGES: 0x0000000000000200
  2MB PAGES: 0x00000000000003fb
  1GB PAGES: 0x0000000000000002
libxl: error: libxl_pci.c:1055:libxl__device_pci_add: PCI device 0:d:0.0 is not assignable
Waiting for domain Windows8 (domid 4) to die [pid 5545]
Domain 4 has shut down, reason code 1 0x1
Action for shutdown reason code 1 is restart
Domain 4 needs to be cleaned up: destroying the domain
libxl: error: libxl_pci.c:1001:libxl__device_pci_reset: The kernel doesn't support reset from sysfs for PCI device 0000:0d:00.0
libxl: error: libxl_pci.c:1265:do_pci_remove: xc_deassign_device failed
Done. Rebooting now
xc: info: VIRTUAL MEMORY ARRANGEMENT:
  Loader:        0000000000100000->00000000001ad64c
  TOTAL:         0000000000000000->00000000ff800000
  ENTRY ADDRESS: 0000000000100000
xc: info: PHYSICAL MEMORY ALLOCATION:
  4KB PAGES: 0x0000000000000200
  2MB PAGES: 0x00000000000003fb
  1GB PAGES: 0x0000000000000002
libxl: error: libxl_pci.c:1055:libxl__device_pci_add: PCI device 0:d:0.0 is not assignable
Waiting for domain Windows8 (domid 5) to die [pid 5545]
Domain 5 has shut down, reason code 1 0x1
Action for shutdown reason code 1 is restart
Domain 5 needs to be cleaned up: destroying the domain
libxl: error: libxl_pci.c:1001:libxl__device_pci_reset: The kernel doesn't support reset from sysfs for PCI device 0000:0d:00.0
libxl: error: libxl_pci.c:1265:do_pci_remove: xc_deassign_device failed
Done. Rebooting now
xc: info: VIRTUAL MEMORY ARRANGEMENT:
  Loader:        0000000000100000->00000000001ad64c
  TOTAL:         0000000000000000->00000000ff800000
  ENTRY ADDRESS: 0000000000100000
xc: info: PHYSICAL MEMORY ALLOCATION:
  4KB PAGES: 0x0000000000000200
  2MB PAGES: 0x00000000000003fb
  1GB PAGES: 0x0000000000000002
libxl: error: libxl_pci.c:1055:libxl__device_pci_add: PCI device 0:d:0.0 is not assignable
Waiting for domain Windows8 (domid 6) to die [pid 5545]
Domain 6 has shut down, reason code 1 0x1
Action for shutdown reason code 1 is restart
Domain 6 needs to be cleaned up: destroying the domain
libxl: error: libxl_pci.c:1001:libxl__device_pci_reset: The kernel doesn't support reset from sysfs for PCI device 0000:0d:00.0
libxl: error: libxl_pci.c:1265:do_pci_remove: xc_deassign_device failed
Done. Rebooting now
xc: info: VIRTUAL MEMORY ARRANGEMENT:
  Loader:        0000000000100000->00000000001ad64c
  TOTAL:         0000000000000000->00000000ff800000
  ENTRY ADDRESS: 0000000000100000
xc: info: PHYSICAL MEMORY ALLOCATION:
  4KB PAGES: 0x0000000000000200
  2MB PAGES: 0x00000000000003fb
  1GB PAGES: 0x0000000000000002
libxl: error: libxl_pci.c:1055:libxl__device_pci_add: PCI device 0:d:0.0 is not assignable
Waiting for domain Windows8 (domid 7) to die [pid 5545]
Domain 7 has shut down, reason code 1 0x1
Action for shutdown reason code 1 is restart
Domain 7 needs to be cleaned up: destroying the domain
libxl: error: libxl_pci.c:1001:libxl__device_pci_reset: The kernel doesn't support reset from sysfs for PCI device 0000:0d:00.0
libxl: error: libxl_pci.c:1265:do_pci_remove: xc_deassign_device failed
Done. Rebooting now
xc: info: VIRTUAL MEMORY ARRANGEMENT:
  Loader:        0000000000100000->00000000001ad64c
  TOTAL:         0000000000000000->00000000ff800000
  ENTRY ADDRESS: 0000000000100000
xc: info: PHYSICAL MEMORY ALLOCATION:
  4KB PAGES: 0x0000000000000200
  2MB PAGES: 0x00000000000003fb
  1GB PAGES: 0x0000000000000002
libxl: error: libxl_pci.c:1055:libxl__device_pci_add: PCI device 0:d:0.0 is not assignable
Waiting for domain Windows8 (domid 8) to die [pid 5545]
Domain 8 has been destroyed.

--------------060301030907070908060303
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--------------060301030907070908060303--


From xen-devel-bounces@lists.xen.org Wed Sep 19 16:58:23 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Sep 2012 16:58:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TENbB-0003Zt-Ar; Wed, 19 Sep 2012 16:58:05 +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 1TENbA-0003Zm-C0
	for xen-devel@lists.xen.org; Wed, 19 Sep 2012 16:58:04 +0000
Received: from [85.158.139.211:42445] by server-10.bemta-5.messagelabs.com id
	8E/DC-10969-B99F9505; Wed, 19 Sep 2012 16:58:03 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-15.tower-206.messagelabs.com!1348073882!19257197!1
X-Originating-IP: [74.125.83.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27276 invoked from network); 19 Sep 2012 16:58:03 -0000
Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com)
	(74.125.83.45)
	by server-15.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Sep 2012 16:58:03 -0000
Received: by eeke53 with SMTP id e53so577691eek.32
	for <xen-devel@lists.xen.org>; Wed, 19 Sep 2012 09:58:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:date:x-google-sender-auth:message-id:subject
	:from:to:content-type;
	bh=AXjaBOnyaxeCyJ+Uf454OF8ddq2DAvDFqll+Rgs8vbU=;
	b=uSbxd3583Y7xo74V3a4v3bhh/pR7kKV72WS2GXVFkeSilhaPwP7ncqDLUtUBx31y+c
	1dnlGDUklI4saIXf5iHU4HaIadEz/g2oYCRh0QBPehKD09gZYJVOmb1FEG49TcQVtq1l
	8+FH7nAosB70tXJjNXjPSgwjDfZLVNuL6UXKkqXdVTnYFid59SY1Rm/ulF4UWcICxLuk
	UUYvZDgsoad4JSh6QdCf3uHdgOlp8gpYehxPBA/IDZB3GEh+M0ColN9r3KVJV9f1SwXi
	mebDJTxL4s/q1gjZxYy+OIo9gLt4gCj7OVjk5qIGu4k6+HLZjklWS7zzbg7fbDV0l8EI
	DDmw==
MIME-Version: 1.0
Received: by 10.14.180.68 with SMTP id i44mr4384932eem.20.1348073882845; Wed,
	19 Sep 2012 09:58:02 -0700 (PDT)
Received: by 10.14.215.195 with HTTP; Wed, 19 Sep 2012 09:58:02 -0700 (PDT)
Date: Wed, 19 Sep 2012 17:58:02 +0100
X-Google-Sender-Auth: -0f_KvPl-WWyg3pZPpLHr1lP5E0
Message-ID: <CAFLBxZYtmJ_bKFb90r45=C4Pq1-oe5Fy=eygSsQf4BcGj3EqGA@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: xen-devel@lists.xen.org
Subject: [Xen-devel] Xen 4.3 development 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

= Timeline =

We are planning on a 9-month release cycle.  Based on that, below are
our estimated dates:
* Feature Freeze: 1 March, 2013
* First RC: 15 April 2013
* Release: 1 June 2013

The RCs and release will of course depend on stability and bugs, and
will therefore be fairly unpredictable.  The feature freeze may be
slipped for especially important features which are near completion.

= Feature tracking =

Below is a list of features we're tracking for this release.  Please
respond to this mail with any updates to the status.  If the status
is "?", as most of them are, please respond with the status!  Example
statuses include "not started", "in progress", "initial implementation
submitted for review", "patches submitted".

There are a number of items whose owners are marked as "?".  If you
are working on this, or know who is working on it, please respond and
let me know.  Alternately, if you would *like* to work on it, please
let me know as well.

And if there is something you're working on you'd like tracked, please
respond, and I will add it to the list.


* PVH mode, domU (w/ Linux)
  owner: mukesh@oracle
  status: ?

* PVH mode, dom0 (w/ Linux)
  owner: mukesh@oracle
  status: ?

* Event channel scalability
  owner: attilio@citrix
  status: ?
  Increase limit on event channels (currently 1024 for 32-bit guests,
  4096 for 64-bit guests)

* ARM server port
  owner: ijc@citrix
  status: Core hypervisor patches accepted; Linux paches pending

* NUMA scheduler affinity
  critical
  owner: dario@citrix
  status: ?

* NUMA Memory migration
  owner: dario@citrix
  status: ?

* blktap3
  owner: thanos@citrix
  status: ?

* Default to QEMU upstream
 - qemu-based stubdom (Linux or BSD libc)
   owner: anthony@citrix
   status: ?
   qemu-upstream needs a more fully-featured libc than exists in
   minios.  Either work on a minimalist linux-based stubdom with
   glibc, or port one of the BSD libcs to minios.

 - pci pass-thru
   owner: anthony@citrix
   status: ?

* Persistent grants
  owner: @citrix
  status: ?

* Multi-page blk rings
 - blkback in kernel (konrad@oracle, ?@intel)
 - qemu blkback
  status: ?

* Multi-page net protocol
  owner: ?
  status: ?
  expand the network ring protocol to allow multiple pages for
  increased throughput

* Scalability: 16TiB of RAM
  owner: jan@suse
  status: ?

* libvirt integration
  owner: ?
  status: ?
  To begin with, we need someone to go and make some lists:
  - Features available in libvirt/KVM not available in libvirt/Xen
  - Features available in xl/Xen but not available in libvirt/Xen

* xl vm-{export,import}
  owner: ?
  status: ?
  Allow xl to import and export VMs to other formats; particularly
  ovf, perhaps the XenServer format, or more.


* xl USB pass-through for PV guests
  owner: ?
  status: ?
  - Port the xend PV pass-through functionality to xl.
  - Make sure qemu-based USB with qemu-upstream works
  - Upstream the Linux frontend/backend drivers

* openvswitch toostack integration
  owner: roger@citrix
  status: Sample script posted by Bastian ("[RFC] openvswitch support script")

* Rationalized backend scripts (incl. driver domains)
  owner: roger@citrix
  status: ?

* Linux console improvements
  owner: jan@suse
  -EHCI debug port (done, to be submitted)
  -xHCI debug port
  -Firewire

* CPUID-based idle (don't rely on ACPI info f/ dom0)
  owner: jan@suse
  status: done, to be submitted

* Remove hardcoded mobprobe's in xencommons
  owner: ?
  status: ?

* Make storage migration possible
  owner: ?
  status: ?
  There needs to be a way, either via command-line or via some hooks,
  that someone can build a "storage migration" feature on top of libxl
  or xl.

* Full-VM snapshotting
  owner: ?
  status: ?
  Have a way of coordinating the taking and restoring of VM memory and
  disk snapshots.  This would involve some investigation into the best
  way to accomplish this.

* VM Cloning
  owner: ?
  status: May need review
  Again, a way of coordinating the memory and disk aspects.  Research
  into the best way to do this would probably go along with the
  snapshotting feature.

* Memory: Replace PoD with paging mechanism
  owner: george@citrix
  status: May need review

* PV audio (audio for stubdom qemu)
  owner: stefano.panella@citrix
  status: ?

* Managed domains?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 19 16:58:23 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Sep 2012 16:58:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TENbB-0003Zt-Ar; Wed, 19 Sep 2012 16:58:05 +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 1TENbA-0003Zm-C0
	for xen-devel@lists.xen.org; Wed, 19 Sep 2012 16:58:04 +0000
Received: from [85.158.139.211:42445] by server-10.bemta-5.messagelabs.com id
	8E/DC-10969-B99F9505; Wed, 19 Sep 2012 16:58:03 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-15.tower-206.messagelabs.com!1348073882!19257197!1
X-Originating-IP: [74.125.83.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27276 invoked from network); 19 Sep 2012 16:58:03 -0000
Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com)
	(74.125.83.45)
	by server-15.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Sep 2012 16:58:03 -0000
Received: by eeke53 with SMTP id e53so577691eek.32
	for <xen-devel@lists.xen.org>; Wed, 19 Sep 2012 09:58:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:date:x-google-sender-auth:message-id:subject
	:from:to:content-type;
	bh=AXjaBOnyaxeCyJ+Uf454OF8ddq2DAvDFqll+Rgs8vbU=;
	b=uSbxd3583Y7xo74V3a4v3bhh/pR7kKV72WS2GXVFkeSilhaPwP7ncqDLUtUBx31y+c
	1dnlGDUklI4saIXf5iHU4HaIadEz/g2oYCRh0QBPehKD09gZYJVOmb1FEG49TcQVtq1l
	8+FH7nAosB70tXJjNXjPSgwjDfZLVNuL6UXKkqXdVTnYFid59SY1Rm/ulF4UWcICxLuk
	UUYvZDgsoad4JSh6QdCf3uHdgOlp8gpYehxPBA/IDZB3GEh+M0ColN9r3KVJV9f1SwXi
	mebDJTxL4s/q1gjZxYy+OIo9gLt4gCj7OVjk5qIGu4k6+HLZjklWS7zzbg7fbDV0l8EI
	DDmw==
MIME-Version: 1.0
Received: by 10.14.180.68 with SMTP id i44mr4384932eem.20.1348073882845; Wed,
	19 Sep 2012 09:58:02 -0700 (PDT)
Received: by 10.14.215.195 with HTTP; Wed, 19 Sep 2012 09:58:02 -0700 (PDT)
Date: Wed, 19 Sep 2012 17:58:02 +0100
X-Google-Sender-Auth: -0f_KvPl-WWyg3pZPpLHr1lP5E0
Message-ID: <CAFLBxZYtmJ_bKFb90r45=C4Pq1-oe5Fy=eygSsQf4BcGj3EqGA@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: xen-devel@lists.xen.org
Subject: [Xen-devel] Xen 4.3 development 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

= Timeline =

We are planning on a 9-month release cycle.  Based on that, below are
our estimated dates:
* Feature Freeze: 1 March, 2013
* First RC: 15 April 2013
* Release: 1 June 2013

The RCs and release will of course depend on stability and bugs, and
will therefore be fairly unpredictable.  The feature freeze may be
slipped for especially important features which are near completion.

= Feature tracking =

Below is a list of features we're tracking for this release.  Please
respond to this mail with any updates to the status.  If the status
is "?", as most of them are, please respond with the status!  Example
statuses include "not started", "in progress", "initial implementation
submitted for review", "patches submitted".

There are a number of items whose owners are marked as "?".  If you
are working on this, or know who is working on it, please respond and
let me know.  Alternately, if you would *like* to work on it, please
let me know as well.

And if there is something you're working on you'd like tracked, please
respond, and I will add it to the list.


* PVH mode, domU (w/ Linux)
  owner: mukesh@oracle
  status: ?

* PVH mode, dom0 (w/ Linux)
  owner: mukesh@oracle
  status: ?

* Event channel scalability
  owner: attilio@citrix
  status: ?
  Increase limit on event channels (currently 1024 for 32-bit guests,
  4096 for 64-bit guests)

* ARM server port
  owner: ijc@citrix
  status: Core hypervisor patches accepted; Linux paches pending

* NUMA scheduler affinity
  critical
  owner: dario@citrix
  status: ?

* NUMA Memory migration
  owner: dario@citrix
  status: ?

* blktap3
  owner: thanos@citrix
  status: ?

* Default to QEMU upstream
 - qemu-based stubdom (Linux or BSD libc)
   owner: anthony@citrix
   status: ?
   qemu-upstream needs a more fully-featured libc than exists in
   minios.  Either work on a minimalist linux-based stubdom with
   glibc, or port one of the BSD libcs to minios.

 - pci pass-thru
   owner: anthony@citrix
   status: ?

* Persistent grants
  owner: @citrix
  status: ?

* Multi-page blk rings
 - blkback in kernel (konrad@oracle, ?@intel)
 - qemu blkback
  status: ?

* Multi-page net protocol
  owner: ?
  status: ?
  expand the network ring protocol to allow multiple pages for
  increased throughput

* Scalability: 16TiB of RAM
  owner: jan@suse
  status: ?

* libvirt integration
  owner: ?
  status: ?
  To begin with, we need someone to go and make some lists:
  - Features available in libvirt/KVM not available in libvirt/Xen
  - Features available in xl/Xen but not available in libvirt/Xen

* xl vm-{export,import}
  owner: ?
  status: ?
  Allow xl to import and export VMs to other formats; particularly
  ovf, perhaps the XenServer format, or more.


* xl USB pass-through for PV guests
  owner: ?
  status: ?
  - Port the xend PV pass-through functionality to xl.
  - Make sure qemu-based USB with qemu-upstream works
  - Upstream the Linux frontend/backend drivers

* openvswitch toostack integration
  owner: roger@citrix
  status: Sample script posted by Bastian ("[RFC] openvswitch support script")

* Rationalized backend scripts (incl. driver domains)
  owner: roger@citrix
  status: ?

* Linux console improvements
  owner: jan@suse
  -EHCI debug port (done, to be submitted)
  -xHCI debug port
  -Firewire

* CPUID-based idle (don't rely on ACPI info f/ dom0)
  owner: jan@suse
  status: done, to be submitted

* Remove hardcoded mobprobe's in xencommons
  owner: ?
  status: ?

* Make storage migration possible
  owner: ?
  status: ?
  There needs to be a way, either via command-line or via some hooks,
  that someone can build a "storage migration" feature on top of libxl
  or xl.

* Full-VM snapshotting
  owner: ?
  status: ?
  Have a way of coordinating the taking and restoring of VM memory and
  disk snapshots.  This would involve some investigation into the best
  way to accomplish this.

* VM Cloning
  owner: ?
  status: May need review
  Again, a way of coordinating the memory and disk aspects.  Research
  into the best way to do this would probably go along with the
  snapshotting feature.

* Memory: Replace PoD with paging mechanism
  owner: george@citrix
  status: May need review

* PV audio (audio for stubdom qemu)
  owner: stefano.panella@citrix
  status: ?

* Managed domains?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 19 17:07:01 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Sep 2012 17:07:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TENjW-0003qK-Cp; Wed, 19 Sep 2012 17:06:42 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dan.magenheimer@oracle.com>) id 1TENjV-0003qF-D4
	for xen-devel@lists.xen.org; Wed, 19 Sep 2012 17:06:41 +0000
Received: from [85.158.139.83:2064] by server-6.bemta-5.messagelabs.com id
	D2/12-21336-0ABF9505; Wed, 19 Sep 2012 17:06:40 +0000
X-Env-Sender: dan.magenheimer@oracle.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1348074398!24038844!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzUwOTQ4\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19243 invoked from network); 19 Sep 2012 17:06:39 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-11.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 19 Sep 2012 17:06:39 -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 q8JH6WaO000923
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 19 Sep 2012 17:06:33 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
	q8JH6Vln000243
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 19 Sep 2012 17:06:32 GMT
Received: from abhmt104.oracle.com (abhmt104.oracle.com [141.146.116.56])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q8JH6V1X014380; Wed, 19 Sep 2012 12:06:31 -0500
MIME-Version: 1.0
Message-ID: <010f0452-96a3-4b3a-beca-1ba28b75b760@default>
Date: Wed, 19 Sep 2012 10:06:26 -0700 (PDT)
From: Dan Magenheimer <dan.magenheimer@oracle.com>
To: Jan Beulich <JBeulich@suse.com>
References: <cc71cf29-4505-4acf-ac37-5190ce30451b@default>
	<505A0832020000780009C61E@nat28.tlf.novell.com>
In-Reply-To: <505A0832020000780009C61E@nat28.tlf.novell.com>
X-Priority: 3
X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.7  (607090) [OL
	12.0.6661.5003 (x86)]
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: Keir Fraser <keir@xen.org>, Ian Campbell <ian.campbell@citrix.com>,
	Konrad Wilk <konrad.wilk@oracle.com>, tim@xen.org,
	IanJackson <Ian.Jackson@eu.citrix.com>,
	Zhenzhong Duan <zhenzhong.duan@oracle.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] tmem/XSA-15 backport?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> From: Jan Beulich [mailto:JBeulich@suse.com]
> Sent: Wednesday, September 19, 2012 10:00 AM
> To: Dan Magenheimer
> Cc: Ian Campbell; IanJackson; xen-devel@lists.xen.org; Konrad Wilk; Zhenzhong Duan; Keir Fraser;
> tim@xen.org
> Subject: Re: tmem/XSA-15 backport?
> 
> >>> On 19.09.12 at 17:48, Dan Magenheimer <dan.magenheimer@oracle.com> wrote:
> > I'd like to recommend that all tmem patches be backported
> > to 4.1-stable and 4.2-stable prior to the next
> > point release and preferably asap.
> >
> > Auditing activities are being conducted separately under
> > Konrad's supervision, but it seems wise to apply known
> > security patches to released trees before any users/distros
> > update.
> >
> > Comments or objections?
> 
> My recollection is that the committers more or less agreed to
> consider backports only once the full audit was done, and we
> were assured that no further vulnerabilities are to be
> expected. But I'm certainly open to weakening that position
> if others prefer going that route.

Yes, didn't make much sense to me :-)

I agree it may be wise to _not_ remove any published recommendations
to _not_ enable tmem until a full audit is done, but failing
to fix known issues (security or otherwise) in released trees
because there _might_ be other bugs found in the future seems
odd to me.

Other comments or objections?

Dan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 19 17:07:01 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Sep 2012 17:07:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TENjW-0003qK-Cp; Wed, 19 Sep 2012 17:06:42 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dan.magenheimer@oracle.com>) id 1TENjV-0003qF-D4
	for xen-devel@lists.xen.org; Wed, 19 Sep 2012 17:06:41 +0000
Received: from [85.158.139.83:2064] by server-6.bemta-5.messagelabs.com id
	D2/12-21336-0ABF9505; Wed, 19 Sep 2012 17:06:40 +0000
X-Env-Sender: dan.magenheimer@oracle.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1348074398!24038844!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzUwOTQ4\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19243 invoked from network); 19 Sep 2012 17:06:39 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-11.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 19 Sep 2012 17:06:39 -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 q8JH6WaO000923
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 19 Sep 2012 17:06:33 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
	q8JH6Vln000243
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 19 Sep 2012 17:06:32 GMT
Received: from abhmt104.oracle.com (abhmt104.oracle.com [141.146.116.56])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q8JH6V1X014380; Wed, 19 Sep 2012 12:06:31 -0500
MIME-Version: 1.0
Message-ID: <010f0452-96a3-4b3a-beca-1ba28b75b760@default>
Date: Wed, 19 Sep 2012 10:06:26 -0700 (PDT)
From: Dan Magenheimer <dan.magenheimer@oracle.com>
To: Jan Beulich <JBeulich@suse.com>
References: <cc71cf29-4505-4acf-ac37-5190ce30451b@default>
	<505A0832020000780009C61E@nat28.tlf.novell.com>
In-Reply-To: <505A0832020000780009C61E@nat28.tlf.novell.com>
X-Priority: 3
X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.7  (607090) [OL
	12.0.6661.5003 (x86)]
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: Keir Fraser <keir@xen.org>, Ian Campbell <ian.campbell@citrix.com>,
	Konrad Wilk <konrad.wilk@oracle.com>, tim@xen.org,
	IanJackson <Ian.Jackson@eu.citrix.com>,
	Zhenzhong Duan <zhenzhong.duan@oracle.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] tmem/XSA-15 backport?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> From: Jan Beulich [mailto:JBeulich@suse.com]
> Sent: Wednesday, September 19, 2012 10:00 AM
> To: Dan Magenheimer
> Cc: Ian Campbell; IanJackson; xen-devel@lists.xen.org; Konrad Wilk; Zhenzhong Duan; Keir Fraser;
> tim@xen.org
> Subject: Re: tmem/XSA-15 backport?
> 
> >>> On 19.09.12 at 17:48, Dan Magenheimer <dan.magenheimer@oracle.com> wrote:
> > I'd like to recommend that all tmem patches be backported
> > to 4.1-stable and 4.2-stable prior to the next
> > point release and preferably asap.
> >
> > Auditing activities are being conducted separately under
> > Konrad's supervision, but it seems wise to apply known
> > security patches to released trees before any users/distros
> > update.
> >
> > Comments or objections?
> 
> My recollection is that the committers more or less agreed to
> consider backports only once the full audit was done, and we
> were assured that no further vulnerabilities are to be
> expected. But I'm certainly open to weakening that position
> if others prefer going that route.

Yes, didn't make much sense to me :-)

I agree it may be wise to _not_ remove any published recommendations
to _not_ enable tmem until a full audit is done, but failing
to fix known issues (security or otherwise) in released trees
because there _might_ be other bugs found in the future seems
odd to me.

Other comments or objections?

Dan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 19 17:19:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Sep 2012 17:19:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TENvA-00040K-OB; Wed, 19 Sep 2012 17:18:44 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <hahn@univention.de>) id 1TENv8-00040F-O1
	for xen-devel@lists.xen.org; Wed, 19 Sep 2012 17:18:42 +0000
Received: from [85.158.139.211:40242] by server-7.bemta-5.messagelabs.com id
	B5/B6-19703-17EF9505; Wed, 19 Sep 2012 17:18:41 +0000
X-Env-Sender: hahn@univention.de
X-Msg-Ref: server-4.tower-206.messagelabs.com!1348075121!19223366!1
X-Originating-IP: [82.198.197.8]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30183 invoked from network); 19 Sep 2012 17:18:41 -0000
Received: from mail.univention.de (HELO mail.univention.de) (82.198.197.8)
	by server-4.tower-206.messagelabs.com with SMTP;
	19 Sep 2012 17:18:41 -0000
Received: from localhost (localhost [127.0.0.1])
	by slugis.knut.univention.de (Postfix) with ESMTP id 6CC2FA63101;
	Wed, 19 Sep 2012 19:18:41 +0200 (CEST)
Received: from localhost (localhost [127.0.0.1])
	by slugis.knut.univention.de (Postfix) with ESMTP id 5FA48A63105;
	Wed, 19 Sep 2012 19:18:41 +0200 (CEST)
X-Virus-Scanned: by amavisd-new-2.6.1 (20080629) (Debian) at knut.univention.de
Received: from mail.univention.de ([127.0.0.1])
	by localhost (slugis.knut.univention.de [127.0.0.1]) (amavisd-new,
	port 10024)
	with ESMTP id R-FkEKQmmAYj; Wed, 19 Sep 2012 19:18:40 +0200 (CEST)
Received: from stave.knut.univention.de (mail.univention.de [82.198.197.8])
	by slugis.knut.univention.de (Postfix) with ESMTPSA id B4113A63101;
	Wed, 19 Sep 2012 19:18:40 +0200 (CEST)
From: Philipp Hahn <hahn@univention.de>
Organization: Univention.de
To: xen-devel@lists.xen.org,
 George Dunlap <George.Dunlap@eu.citrix.com>
Date: Wed, 19 Sep 2012 19:18:31 +0200
User-Agent: KMail/1.9.10 (enterprise35 20100903.1171286)
References: <CAFLBxZYtmJ_bKFb90r45=C4Pq1-oe5Fy=eygSsQf4BcGj3EqGA@mail.gmail.com>
In-Reply-To: <CAFLBxZYtmJ_bKFb90r45=C4Pq1-oe5Fy=eygSsQf4BcGj3EqGA@mail.gmail.com>
X-KMail-QuotePrefix: > 
MIME-Version: 1.0
Message-Id: <201209191918.35305.hahn@univention.de>
Subject: Re: [Xen-devel] Xen 4.3 development 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: multipart/mixed; boundary="===============8827946160961656489=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============8827946160961656489==
Content-Type: multipart/signed;
  boundary="nextPart1670893.u6zlPKyXml";
  protocol="application/pgp-signature";
  micalg=pgp-sha1
Content-Transfer-Encoding: 7bit

--nextPart1670893.u6zlPKyXml
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Hello,

On Wednesday 19 September 2012 18:58:02 George Dunlap wrote:
> * libvirt integration
>   owner: ?
>   status: ?
>   To begin with, we need someone to go and make some lists:
>   - Features available in libvirt/KVM not available in libvirt/Xen
>   - Features available in xl/Xen but not available in libvirt/Xen

Libvirt already has a comparison matrix at=20
<http://libvirt.org/hvsupport.html>. That file is actually generated from b=
y=20
docs/hvsupport.pl by looking at the implemented functions.

Sincerely
Philipp
=2D-=20
Philipp Hahn           Open Source Software Engineer      hahn@univention.de
Univention GmbH        be open.                       fon: +49 421 22 232- 0
Mary-Somerville-Str.1  D-28359 Bremen                 fax: +49 421 22 232-99
                                                   http://www.univention.de/

--nextPart1670893.u6zlPKyXml
Content-Type: application/pgp-signature; name=signature.asc 
Content-Description: This is a digitally signed message part.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEABECAAYFAlBZ/mcACgkQYPlgoZpUDjn4vwCfbFW7B1jP80N4wiYK4wKwqnWS
Cg8An1ERfAcgj+ua/T02bxdts2Ma6ahM
=VnrP
-----END PGP SIGNATURE-----

--nextPart1670893.u6zlPKyXml--


--===============8827946160961656489==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============8827946160961656489==--


From xen-devel-bounces@lists.xen.org Wed Sep 19 17:19:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Sep 2012 17:19:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TENvA-00040K-OB; Wed, 19 Sep 2012 17:18:44 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <hahn@univention.de>) id 1TENv8-00040F-O1
	for xen-devel@lists.xen.org; Wed, 19 Sep 2012 17:18:42 +0000
Received: from [85.158.139.211:40242] by server-7.bemta-5.messagelabs.com id
	B5/B6-19703-17EF9505; Wed, 19 Sep 2012 17:18:41 +0000
X-Env-Sender: hahn@univention.de
X-Msg-Ref: server-4.tower-206.messagelabs.com!1348075121!19223366!1
X-Originating-IP: [82.198.197.8]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30183 invoked from network); 19 Sep 2012 17:18:41 -0000
Received: from mail.univention.de (HELO mail.univention.de) (82.198.197.8)
	by server-4.tower-206.messagelabs.com with SMTP;
	19 Sep 2012 17:18:41 -0000
Received: from localhost (localhost [127.0.0.1])
	by slugis.knut.univention.de (Postfix) with ESMTP id 6CC2FA63101;
	Wed, 19 Sep 2012 19:18:41 +0200 (CEST)
Received: from localhost (localhost [127.0.0.1])
	by slugis.knut.univention.de (Postfix) with ESMTP id 5FA48A63105;
	Wed, 19 Sep 2012 19:18:41 +0200 (CEST)
X-Virus-Scanned: by amavisd-new-2.6.1 (20080629) (Debian) at knut.univention.de
Received: from mail.univention.de ([127.0.0.1])
	by localhost (slugis.knut.univention.de [127.0.0.1]) (amavisd-new,
	port 10024)
	with ESMTP id R-FkEKQmmAYj; Wed, 19 Sep 2012 19:18:40 +0200 (CEST)
Received: from stave.knut.univention.de (mail.univention.de [82.198.197.8])
	by slugis.knut.univention.de (Postfix) with ESMTPSA id B4113A63101;
	Wed, 19 Sep 2012 19:18:40 +0200 (CEST)
From: Philipp Hahn <hahn@univention.de>
Organization: Univention.de
To: xen-devel@lists.xen.org,
 George Dunlap <George.Dunlap@eu.citrix.com>
Date: Wed, 19 Sep 2012 19:18:31 +0200
User-Agent: KMail/1.9.10 (enterprise35 20100903.1171286)
References: <CAFLBxZYtmJ_bKFb90r45=C4Pq1-oe5Fy=eygSsQf4BcGj3EqGA@mail.gmail.com>
In-Reply-To: <CAFLBxZYtmJ_bKFb90r45=C4Pq1-oe5Fy=eygSsQf4BcGj3EqGA@mail.gmail.com>
X-KMail-QuotePrefix: > 
MIME-Version: 1.0
Message-Id: <201209191918.35305.hahn@univention.de>
Subject: Re: [Xen-devel] Xen 4.3 development 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: multipart/mixed; boundary="===============8827946160961656489=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============8827946160961656489==
Content-Type: multipart/signed;
  boundary="nextPart1670893.u6zlPKyXml";
  protocol="application/pgp-signature";
  micalg=pgp-sha1
Content-Transfer-Encoding: 7bit

--nextPart1670893.u6zlPKyXml
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Hello,

On Wednesday 19 September 2012 18:58:02 George Dunlap wrote:
> * libvirt integration
>   owner: ?
>   status: ?
>   To begin with, we need someone to go and make some lists:
>   - Features available in libvirt/KVM not available in libvirt/Xen
>   - Features available in xl/Xen but not available in libvirt/Xen

Libvirt already has a comparison matrix at=20
<http://libvirt.org/hvsupport.html>. That file is actually generated from b=
y=20
docs/hvsupport.pl by looking at the implemented functions.

Sincerely
Philipp
=2D-=20
Philipp Hahn           Open Source Software Engineer      hahn@univention.de
Univention GmbH        be open.                       fon: +49 421 22 232- 0
Mary-Somerville-Str.1  D-28359 Bremen                 fax: +49 421 22 232-99
                                                   http://www.univention.de/

--nextPart1670893.u6zlPKyXml
Content-Type: application/pgp-signature; name=signature.asc 
Content-Description: This is a digitally signed message part.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEABECAAYFAlBZ/mcACgkQYPlgoZpUDjn4vwCfbFW7B1jP80N4wiYK4wKwqnWS
Cg8An1ERfAcgj+ua/T02bxdts2Ma6ahM
=VnrP
-----END PGP SIGNATURE-----

--nextPart1670893.u6zlPKyXml--


--===============8827946160961656489==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============8827946160961656489==--


From xen-devel-bounces@lists.xen.org Wed Sep 19 17:22:59 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Sep 2012 17:22: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 1TENyz-00047b-DQ; Wed, 19 Sep 2012 17:22:41 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ketuzsezr@gmail.com>) id 1TENyy-00047V-3l
	for xen-devel@lists.xen.org; Wed, 19 Sep 2012 17:22:40 +0000
Received: from [85.158.139.211:28695] by server-6.bemta-5.messagelabs.com id
	87/98-21336-F5FF9505; Wed, 19 Sep 2012 17:22:39 +0000
X-Env-Sender: ketuzsezr@gmail.com
X-Msg-Ref: server-5.tower-206.messagelabs.com!1348075357!19157901!1
X-Originating-IP: [209.85.160.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3556 invoked from network); 19 Sep 2012 17:22:38 -0000
Received: from mail-pb0-f45.google.com (HELO mail-pb0-f45.google.com)
	(209.85.160.45)
	by server-5.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Sep 2012 17:22:38 -0000
Received: by pbbrp12 with SMTP id rp12so3021715pbb.32
	for <xen-devel@lists.xen.org>; Wed, 19 Sep 2012 10:22: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=H50s7IzAc+wkHZTLG3J+q3L7Sxy6QPUWmSlYVoLsH/I=;
	b=MtPqtKoH0lJKWO+3EdWzuJpBdLxRbapd+iZw1F9cg0njK3osBaNTSduNZcwznpAVl+
	4pZkZYnxQxFxdYm9hcK0SdXpoCZeQy8yeiXuEtntflGR8XZ3vqj83k9T9TM5k6az3gHX
	1sRxzOh7BGLKBEBG3S9Lq1jgvh+0xf02r/zSLeV1+huYY3pWFlLfvRk5nVQrpFvTvLF7
	3L7X1MknlK+z1gTtKLw8c7G0tq7DSn17avonIcfX9v6BFMl8L+zl8wQYbUgSyQOaDdUy
	0oKgDbI/KDnk6awKT5/3ld0/ZmupHV+7NhbXG5FZv+oXeyZUHZmMHbQsz8Oz+080Uct9
	mVSQ==
MIME-Version: 1.0
Received: by 10.68.239.135 with SMTP id vs7mr38855pbc.38.1348075356652; Wed,
	19 Sep 2012 10:22:36 -0700 (PDT)
Received: by 10.66.193.9 with HTTP; Wed, 19 Sep 2012 10:22:36 -0700 (PDT)
In-Reply-To: <CAFLBxZYtmJ_bKFb90r45=C4Pq1-oe5Fy=eygSsQf4BcGj3EqGA@mail.gmail.com>
References: <CAFLBxZYtmJ_bKFb90r45=C4Pq1-oe5Fy=eygSsQf4BcGj3EqGA@mail.gmail.com>
Date: Wed, 19 Sep 2012 13:22:36 -0400
X-Google-Sender-Auth: Yh4cMZOqEOumnh3eArYNJuVdPx0
Message-ID: <CACJDEmq3KV9Lt2CMc3NupbXJkPDhqUB95m7K-OOrHOKn6HW3OA@mail.gmail.com>
From: Konrad Rzeszutek Wilk <konrad@kernel.org>
To: George Dunlap <George.Dunlap@eu.citrix.com>, annie li <annie.li@oracle.com>
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Xen 4.3 development 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

> * Persistent grants
>   owner: @citrix
>   status: ?

on network side:
annie li <annie.li@oracle.com>
>
> * Multi-page blk rings
>  - blkback in kernel (konrad@oracle, ?@intel)
>  - qemu blkback
>   status: ?
>
> * Multi-page net protocol
>   owner: ?

If Ian Campbell doesn't get to it, then annie li <annie.li@oracle.com>
will look at the patches that Wei Liu posted and work the kinks out.

>   status: ?
>   expand the network ring protocol to allow multiple pages for
>   increased throughput
>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 19 17:22:59 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Sep 2012 17:22: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 1TENyz-00047b-DQ; Wed, 19 Sep 2012 17:22:41 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ketuzsezr@gmail.com>) id 1TENyy-00047V-3l
	for xen-devel@lists.xen.org; Wed, 19 Sep 2012 17:22:40 +0000
Received: from [85.158.139.211:28695] by server-6.bemta-5.messagelabs.com id
	87/98-21336-F5FF9505; Wed, 19 Sep 2012 17:22:39 +0000
X-Env-Sender: ketuzsezr@gmail.com
X-Msg-Ref: server-5.tower-206.messagelabs.com!1348075357!19157901!1
X-Originating-IP: [209.85.160.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3556 invoked from network); 19 Sep 2012 17:22:38 -0000
Received: from mail-pb0-f45.google.com (HELO mail-pb0-f45.google.com)
	(209.85.160.45)
	by server-5.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Sep 2012 17:22:38 -0000
Received: by pbbrp12 with SMTP id rp12so3021715pbb.32
	for <xen-devel@lists.xen.org>; Wed, 19 Sep 2012 10:22: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=H50s7IzAc+wkHZTLG3J+q3L7Sxy6QPUWmSlYVoLsH/I=;
	b=MtPqtKoH0lJKWO+3EdWzuJpBdLxRbapd+iZw1F9cg0njK3osBaNTSduNZcwznpAVl+
	4pZkZYnxQxFxdYm9hcK0SdXpoCZeQy8yeiXuEtntflGR8XZ3vqj83k9T9TM5k6az3gHX
	1sRxzOh7BGLKBEBG3S9Lq1jgvh+0xf02r/zSLeV1+huYY3pWFlLfvRk5nVQrpFvTvLF7
	3L7X1MknlK+z1gTtKLw8c7G0tq7DSn17avonIcfX9v6BFMl8L+zl8wQYbUgSyQOaDdUy
	0oKgDbI/KDnk6awKT5/3ld0/ZmupHV+7NhbXG5FZv+oXeyZUHZmMHbQsz8Oz+080Uct9
	mVSQ==
MIME-Version: 1.0
Received: by 10.68.239.135 with SMTP id vs7mr38855pbc.38.1348075356652; Wed,
	19 Sep 2012 10:22:36 -0700 (PDT)
Received: by 10.66.193.9 with HTTP; Wed, 19 Sep 2012 10:22:36 -0700 (PDT)
In-Reply-To: <CAFLBxZYtmJ_bKFb90r45=C4Pq1-oe5Fy=eygSsQf4BcGj3EqGA@mail.gmail.com>
References: <CAFLBxZYtmJ_bKFb90r45=C4Pq1-oe5Fy=eygSsQf4BcGj3EqGA@mail.gmail.com>
Date: Wed, 19 Sep 2012 13:22:36 -0400
X-Google-Sender-Auth: Yh4cMZOqEOumnh3eArYNJuVdPx0
Message-ID: <CACJDEmq3KV9Lt2CMc3NupbXJkPDhqUB95m7K-OOrHOKn6HW3OA@mail.gmail.com>
From: Konrad Rzeszutek Wilk <konrad@kernel.org>
To: George Dunlap <George.Dunlap@eu.citrix.com>, annie li <annie.li@oracle.com>
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Xen 4.3 development 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

> * Persistent grants
>   owner: @citrix
>   status: ?

on network side:
annie li <annie.li@oracle.com>
>
> * Multi-page blk rings
>  - blkback in kernel (konrad@oracle, ?@intel)
>  - qemu blkback
>   status: ?
>
> * Multi-page net protocol
>   owner: ?

If Ian Campbell doesn't get to it, then annie li <annie.li@oracle.com>
will look at the patches that Wei Liu posted and work the kinks out.

>   status: ?
>   expand the network ring protocol to allow multiple pages for
>   increased throughput
>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 19 17:23:49 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Sep 2012 17:23: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 1TENzq-0004BW-Rh; Wed, 19 Sep 2012 17:23:34 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1TENzp-0004BK-68
	for xen-devel@lists.xen.org; Wed, 19 Sep 2012 17:23:33 +0000
Received: from [85.158.143.99:47780] by server-1.bemta-4.messagelabs.com id
	99/A7-05684-49FF9505; Wed, 19 Sep 2012 17:23:32 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-5.tower-216.messagelabs.com!1348075411!30672682!1
X-Originating-IP: [63.239.67.9]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32646 invoked from network); 19 Sep 2012 17:23:31 -0000
Received: from emvm-gh1-uea08.nsa.gov (HELO nsa.gov) (63.239.67.9)
	by server-5.tower-216.messagelabs.com with SMTP;
	19 Sep 2012 17:23:31 -0000
X-TM-IMSS-Message-ID: <5e3a399800146f36@nsa.gov>
Received: from tarius.tycho.ncsc.mil ([144.51.3.1]) by nsa.gov ([63.239.67.9])
	with ESMTP (TREND IMSS SMTP Service 7.1) id 5e3a399800146f36 ;
	Wed, 19 Sep 2012 13: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 q8JHNTE2014000; 
	Wed, 19 Sep 2012 13:23:29 -0400
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xen.org
Date: Wed, 19 Sep 2012 13:23:28 -0400
Message-Id: <1348075408-14660-1-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.11.4
In-Reply-To: <50588084.3090300@tycho.nsa.gov>
References: <50588084.3090300@tycho.nsa.gov>
Cc: Tim Deegan <tim@xen.org>, Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	Keir Fraser <keir@xen.org>, Jan Beulich <jbeulich@suse.com>
Subject: [Xen-devel] [PATCH 19/23 v2] arch/x86: check remote MMIO remap
	permissions
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 domain is mapping pages from a different pg_owner domain, the
iomem_access checks are currently only applied to the pg_owner domain,
potentially allowing a domain with a more restrictive iomem_access
policy to have the pages mapped into its page tables. To catch this,
also check the owner of the page tables. The current domain does not
need to be checked because the ability to manipulate a domain's page
tables implies full access to the target domain, so checking that
domain's permission is sufficient.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Cc: Keir Fraser <keir@xen.org>
Cc: Jan Beulich <jbeulich@suse.com>
Cc: Tim Deegan <tim@xen.org>
---
 xen/arch/x86/mm.c | 13 +++++++++++++
 1 file changed, 13 insertions(+)

diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
index 5c6ea2d..ede92bd 100644
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -754,6 +754,19 @@ get_page_from_l1e(
             return -EINVAL;
         }
 
+        if ( pg_owner != l1e_owner &&
+             !iomem_access_permitted(l1e_owner, mfn, mfn) )
+        {
+            if ( mfn != (PADDR_MASK >> PAGE_SHIFT) ) /* INVALID_MFN? */
+            {
+                MEM_LOG("Domain %u attempted to map I/O space %08lx in domain %u to domain %u",
+                        curr->domain->domain_id, mfn, pg_owner->domain_id,
+						l1e_owner->domain_id);
+                return -EPERM;
+            }
+            return -EINVAL;
+        }
+
         if ( !(l1f & _PAGE_RW) ||
              !rangeset_contains_singleton(mmio_ro_ranges, mfn) )
             return 0;
-- 
1.7.11.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 19 17:23:49 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Sep 2012 17:23: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 1TENzq-0004BW-Rh; Wed, 19 Sep 2012 17:23:34 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1TENzp-0004BK-68
	for xen-devel@lists.xen.org; Wed, 19 Sep 2012 17:23:33 +0000
Received: from [85.158.143.99:47780] by server-1.bemta-4.messagelabs.com id
	99/A7-05684-49FF9505; Wed, 19 Sep 2012 17:23:32 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-5.tower-216.messagelabs.com!1348075411!30672682!1
X-Originating-IP: [63.239.67.9]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32646 invoked from network); 19 Sep 2012 17:23:31 -0000
Received: from emvm-gh1-uea08.nsa.gov (HELO nsa.gov) (63.239.67.9)
	by server-5.tower-216.messagelabs.com with SMTP;
	19 Sep 2012 17:23:31 -0000
X-TM-IMSS-Message-ID: <5e3a399800146f36@nsa.gov>
Received: from tarius.tycho.ncsc.mil ([144.51.3.1]) by nsa.gov ([63.239.67.9])
	with ESMTP (TREND IMSS SMTP Service 7.1) id 5e3a399800146f36 ;
	Wed, 19 Sep 2012 13: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 q8JHNTE2014000; 
	Wed, 19 Sep 2012 13:23:29 -0400
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xen.org
Date: Wed, 19 Sep 2012 13:23:28 -0400
Message-Id: <1348075408-14660-1-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.11.4
In-Reply-To: <50588084.3090300@tycho.nsa.gov>
References: <50588084.3090300@tycho.nsa.gov>
Cc: Tim Deegan <tim@xen.org>, Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	Keir Fraser <keir@xen.org>, Jan Beulich <jbeulich@suse.com>
Subject: [Xen-devel] [PATCH 19/23 v2] arch/x86: check remote MMIO remap
	permissions
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 domain is mapping pages from a different pg_owner domain, the
iomem_access checks are currently only applied to the pg_owner domain,
potentially allowing a domain with a more restrictive iomem_access
policy to have the pages mapped into its page tables. To catch this,
also check the owner of the page tables. The current domain does not
need to be checked because the ability to manipulate a domain's page
tables implies full access to the target domain, so checking that
domain's permission is sufficient.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Cc: Keir Fraser <keir@xen.org>
Cc: Jan Beulich <jbeulich@suse.com>
Cc: Tim Deegan <tim@xen.org>
---
 xen/arch/x86/mm.c | 13 +++++++++++++
 1 file changed, 13 insertions(+)

diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
index 5c6ea2d..ede92bd 100644
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -754,6 +754,19 @@ get_page_from_l1e(
             return -EINVAL;
         }
 
+        if ( pg_owner != l1e_owner &&
+             !iomem_access_permitted(l1e_owner, mfn, mfn) )
+        {
+            if ( mfn != (PADDR_MASK >> PAGE_SHIFT) ) /* INVALID_MFN? */
+            {
+                MEM_LOG("Domain %u attempted to map I/O space %08lx in domain %u to domain %u",
+                        curr->domain->domain_id, mfn, pg_owner->domain_id,
+						l1e_owner->domain_id);
+                return -EPERM;
+            }
+            return -EINVAL;
+        }
+
         if ( !(l1f & _PAGE_RW) ||
              !rangeset_contains_singleton(mmio_ro_ranges, mfn) )
             return 0;
-- 
1.7.11.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 19 17:24:55 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Sep 2012 17:24:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TEO0v-0004IF-Ai; Wed, 19 Sep 2012 17:24:41 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ketuzsezr@gmail.com>) id 1TEO0t-0004Hz-8z
	for xen-devel@lists.xen.org; Wed, 19 Sep 2012 17:24:39 +0000
Received: from [85.158.143.99:49348] by server-1.bemta-4.messagelabs.com id
	40/58-05684-6DFF9505; Wed, 19 Sep 2012 17:24:38 +0000
X-Env-Sender: ketuzsezr@gmail.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1348075476!30102542!1
X-Originating-IP: [209.85.160.45]
X-SpamReason: No, hits=0.6 required=7.0 tests=MAILTO_TO_SPAM_ADDR, RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29649 invoked from network); 19 Sep 2012 17:24:37 -0000
Received: from mail-pb0-f45.google.com (HELO mail-pb0-f45.google.com)
	(209.85.160.45)
	by server-13.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Sep 2012 17:24:37 -0000
Received: by pbbrp12 with SMTP id rp12so3025560pbb.32
	for <xen-devel@lists.xen.org>; Wed, 19 Sep 2012 10: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=IYraHcY6X9btwIqeoSw9blLdNgod9D6LCvVoLLRMJDQ=;
	b=W/XoF9wWxKbKTEDi0LDbfGweMt38I6q5GtmkJLUXOv4zmhuAicbxgtsN6jlmXSgW9F
	6FkDlVidG5MsJH8+nD4/wnWJuyteF5IW0xuB4HPwToiRkP5mEZACEOkYyqkBZbnGMi3N
	QPuIunq8Bjei9IgVnIsgEpe/FdvsM4mwuhuGgJhd0PlYSBCZ6AXbXd+lLoHvcoq3ss8D
	KNYLKMmGBW1oXyegF6Lbyp4EJh4+UASREGAxGUuIIbU8ZyRowWoYtyTe6s6jWLkc++EO
	OkcIf5NknaIu5Yptc6kjf4VRdV9blaofAZIAWu1EzA2qhQtnqWi3/aOwgIFkcEE17uqs
	k5nQ==
MIME-Version: 1.0
Received: by 10.66.82.3 with SMTP id e3mr8458943pay.56.1348075475982; Wed, 19
	Sep 2012 10:24:35 -0700 (PDT)
Received: by 10.66.193.9 with HTTP; Wed, 19 Sep 2012 10:24:35 -0700 (PDT)
In-Reply-To: <CALCpXpBnAQr=jk5LbZnQPAuJHrKEAL0ELcZ3L2BRQRUfGbUvAw@mail.gmail.com>
References: <CALCpXpBnAQr=jk5LbZnQPAuJHrKEAL0ELcZ3L2BRQRUfGbUvAw@mail.gmail.com>
Date: Wed, 19 Sep 2012 13:24:35 -0400
X-Google-Sender-Auth: lXeU46OJVu8FSYlps1m_8-kAhng
Message-ID: <CACJDEmo-cxm0MiAtSo7sXdKsWChTS4NW4SNsOM_pBOgwr2W7BA@mail.gmail.com>
From: Konrad Rzeszutek Wilk <konrad@kernel.org>
To: Qian Hu <qianhu2011@gmail.com>
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] usbpassthrough of xen-4.1.2
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Sep 19, 2012 at 4:53 AM, Qian Hu <qianhu2011@gmail.com> wrote:
> Hi, everyone!
>
> I am working on the USB passthrough of Xen-4.1.2. My host OS  is Fedora 14
> and the guest OS is win7.
>
> According to the wiki page(http://wiki.xen.org/wiki/Xen_USB_Passthrough),
>
> xen supports passthrough of usb device from dom0 to guests. I have tried the
> Xen HVM guest qemu-dm usb1.1 emulation,
>
> by specifying "usb = 1" and "usbdevice = host:xxxx:yyyy". But, the mouse
> could work, the keyboard and usb storage failed.

You need to give more details. How did it not work? Did it work in Linux?
>
> If I change the guest OS to winXP, it is surprising that only the usb
> storage can be detected in the guest.
>
> I have also tried the PVUSB, it didn't work either.

Right, that is b/c it would only work with Linux.
>
> I am confused and don't know how to resolve it.  Could anyone help me?

Try first an Linux HVM guest and pass in. See what works and what does not.
>
> Great thanks!
>
> huqian
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Sep 19 17:24:55 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Sep 2012 17:24:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TEO0v-0004IF-Ai; Wed, 19 Sep 2012 17:24:41 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ketuzsezr@gmail.com>) id 1TEO0t-0004Hz-8z
	for xen-devel@lists.xen.org; Wed, 19 Sep 2012 17:24:39 +0000
Received: from [85.158.143.99:49348] by server-1.bemta-4.messagelabs.com id
	40/58-05684-6DFF9505; Wed, 19 Sep 2012 17:24:38 +0000
X-Env-Sender: ketuzsezr@gmail.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1348075476!30102542!1
X-Originating-IP: [209.85.160.45]
X-SpamReason: No, hits=0.6 required=7.0 tests=MAILTO_TO_SPAM_ADDR, RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29649 invoked from network); 19 Sep 2012 17:24:37 -0000
Received: from mail-pb0-f45.google.com (HELO mail-pb0-f45.google.com)
	(209.85.160.45)
	by server-13.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Sep 2012 17:24:37 -0000
Received: by pbbrp12 with SMTP id rp12so3025560pbb.32
	for <xen-devel@lists.xen.org>; Wed, 19 Sep 2012 10: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=IYraHcY6X9btwIqeoSw9blLdNgod9D6LCvVoLLRMJDQ=;
	b=W/XoF9wWxKbKTEDi0LDbfGweMt38I6q5GtmkJLUXOv4zmhuAicbxgtsN6jlmXSgW9F
	6FkDlVidG5MsJH8+nD4/wnWJuyteF5IW0xuB4HPwToiRkP5mEZACEOkYyqkBZbnGMi3N
	QPuIunq8Bjei9IgVnIsgEpe/FdvsM4mwuhuGgJhd0PlYSBCZ6AXbXd+lLoHvcoq3ss8D
	KNYLKMmGBW1oXyegF6Lbyp4EJh4+UASREGAxGUuIIbU8ZyRowWoYtyTe6s6jWLkc++EO
	OkcIf5NknaIu5Yptc6kjf4VRdV9blaofAZIAWu1EzA2qhQtnqWi3/aOwgIFkcEE17uqs
	k5nQ==
MIME-Version: 1.0
Received: by 10.66.82.3 with SMTP id e3mr8458943pay.56.1348075475982; Wed, 19
	Sep 2012 10:24:35 -0700 (PDT)
Received: by 10.66.193.9 with HTTP; Wed, 19 Sep 2012 10:24:35 -0700 (PDT)
In-Reply-To: <CALCpXpBnAQr=jk5LbZnQPAuJHrKEAL0ELcZ3L2BRQRUfGbUvAw@mail.gmail.com>
References: <CALCpXpBnAQr=jk5LbZnQPAuJHrKEAL0ELcZ3L2BRQRUfGbUvAw@mail.gmail.com>
Date: Wed, 19 Sep 2012 13:24:35 -0400
X-Google-Sender-Auth: lXeU46OJVu8FSYlps1m_8-kAhng
Message-ID: <CACJDEmo-cxm0MiAtSo7sXdKsWChTS4NW4SNsOM_pBOgwr2W7BA@mail.gmail.com>
From: Konrad Rzeszutek Wilk <konrad@kernel.org>
To: Qian Hu <qianhu2011@gmail.com>
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] usbpassthrough of xen-4.1.2
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Sep 19, 2012 at 4:53 AM, Qian Hu <qianhu2011@gmail.com> wrote:
> Hi, everyone!
>
> I am working on the USB passthrough of Xen-4.1.2. My host OS  is Fedora 14
> and the guest OS is win7.
>
> According to the wiki page(http://wiki.xen.org/wiki/Xen_USB_Passthrough),
>
> xen supports passthrough of usb device from dom0 to guests. I have tried the
> Xen HVM guest qemu-dm usb1.1 emulation,
>
> by specifying "usb = 1" and "usbdevice = host:xxxx:yyyy". But, the mouse
> could work, the keyboard and usb storage failed.

You need to give more details. How did it not work? Did it work in Linux?
>
> If I change the guest OS to winXP, it is surprising that only the usb
> storage can be detected in the guest.
>
> I have also tried the PVUSB, it didn't work either.

Right, that is b/c it would only work with Linux.
>
> I am confused and don't know how to resolve it.  Could anyone help me?

Try first an Linux HVM guest and pass in. See what works and what does not.
>
> Great thanks!
>
> huqian
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Sep 19 17:45:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Sep 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 1TEOKi-0004mE-OQ; Wed, 19 Sep 2012 17:45:08 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1TEOKh-0004m3-BY
	for xen-devel@lists.xensource.com; Wed, 19 Sep 2012 17:45:07 +0000
Received: from [85.158.139.211:47719] by server-5.bemta-5.messagelabs.com id
	67/70-30514-2A40A505; Wed, 19 Sep 2012 17:45:06 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-13.tower-206.messagelabs.com!1348076703!15222144!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzA4ODY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8771 invoked from network); 19 Sep 2012 17:45:05 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-13.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Sep 2012 17:45:05 -0000
X-IronPort-AV: E=Sophos;i="4.80,450,1344211200"; d="scan'208";a="38383840"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Sep 2012 17:45:03 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 19 Sep 2012 13:45:02 -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 1TEOKX-0007so-Eg;
	Wed, 19 Sep 2012 18:44:57 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: linux-kernel@vger.kernel.org
Date: Wed, 19 Sep 2012 18:44:18 +0100
Message-ID: <1348076658-4511-1-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.9.5
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com, Ian.Campbell@citrix.com,
	Pawel Moll <pawel.moll@arm.com>, konrad.wilk@oracle.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	linux-arm-kernel@lists.infradead.org
Subject: [Xen-devel] [PATCH] arm: introduce a DTS for Xen unprivileged
	virtual 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

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
CC: Pawel Moll <pawel.moll@arm.com>
CC: linux-arm-kernel@lists.infradead.org
---
 arch/arm/boot/dts/vexpress-xenvm-4.2.dts |  115 ++++++++++++++++++++++++++++++
 arch/arm/mach-vexpress/Makefile.boot     |    3 +-
 2 files changed, 117 insertions(+), 1 deletions(-)
 create mode 100644 arch/arm/boot/dts/vexpress-xenvm-4.2.dts

diff --git a/arch/arm/boot/dts/vexpress-xenvm-4.2.dts b/arch/arm/boot/dts/vexpress-xenvm-4.2.dts
new file mode 100644
index 0000000..bfb802c
--- /dev/null
+++ b/arch/arm/boot/dts/vexpress-xenvm-4.2.dts
@@ -0,0 +1,115 @@
+/*
+ * Xen Virtual Machine for unprivileged guests
+ *
+ * Based on ARM Ltd. Versatile Express CoreTile Express (single CPU)
+ * Cortex-A15 MPCore (V2P-CA15)
+ *
+ */
+
+/dts-v1/;
+
+/include/ "skeleton.dtsi"
+
+/ {
+	model = "XENVM-4.2";
+	compatible = "xen,xenvm-4.2", "arm,vexpress";
+	interrupt-parent = <&gic>;
+
+	chosen {
+		bootargs = "earlyprintk console=hvc0 root=/dev/xvda init=/sbin/init";
+	};
+
+	cpus {
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		cpu@0 {
+			device_type = "cpu";
+			compatible = "arm,cortex-a15";
+			reg = <0>;
+		};
+	};
+
+	memory {
+		device_type = "memory";
+		reg = <0x80000000 0x08000000>;
+	};
+
+	gic: interrupt-controller@2c001000 {
+		compatible = "arm,cortex-a9-gic";
+		#interrupt-cells = <3>;
+		#address-cells = <0>;
+		interrupt-controller;
+		reg = <0x2c001000 0x1000>,
+		      <0x2c002000 0x100>;
+	};
+
+	timer {
+		compatible = "arm,armv7-timer";
+		interrupts = <1 13 0xf08>,
+			     <1 14 0xf08>,
+			     <1 11 0xf08>,
+			     <1 10 0xf08>;
+	};
+
+	hypervisor {
+		compatible = "xen,xen-4.2", "xen,xen";
+		reg = <0xb0000000 0x20000>;
+		interrupts = <1 15 0xf08>;
+	};
+
+	motherboard {
+		arm,v2m-memory-map = "rs1";
+		ranges = <0 0 0x08000000 0x04000000>,
+			 <1 0 0x14000000 0x04000000>,
+			 <2 0 0x18000000 0x04000000>,
+			 <3 0 0x1c000000 0x04000000>,
+			 <4 0 0x0c000000 0x04000000>,
+			 <5 0 0x10000000 0x04000000>;
+
+		interrupt-map-mask = <0 0 63>;
+		interrupt-map = <0 0  0 &gic 0  0 4>,
+				<0 0  1 &gic 0  1 4>,
+				<0 0  2 &gic 0  2 4>,
+				<0 0  3 &gic 0  3 4>,
+				<0 0  4 &gic 0  4 4>,
+				<0 0  5 &gic 0  5 4>,
+				<0 0  6 &gic 0  6 4>,
+				<0 0  7 &gic 0  7 4>,
+				<0 0  8 &gic 0  8 4>,
+				<0 0  9 &gic 0  9 4>,
+				<0 0 10 &gic 0 10 4>,
+				<0 0 11 &gic 0 11 4>,
+				<0 0 12 &gic 0 12 4>,
+				<0 0 13 &gic 0 13 4>,
+				<0 0 14 &gic 0 14 4>,
+				<0 0 15 &gic 0 15 4>,
+				<0 0 16 &gic 0 16 4>,
+				<0 0 17 &gic 0 17 4>,
+				<0 0 18 &gic 0 18 4>,
+				<0 0 19 &gic 0 19 4>,
+				<0 0 20 &gic 0 20 4>,
+				<0 0 21 &gic 0 21 4>,
+				<0 0 22 &gic 0 22 4>,
+				<0 0 23 &gic 0 23 4>,
+				<0 0 24 &gic 0 24 4>,
+				<0 0 25 &gic 0 25 4>,
+				<0 0 26 &gic 0 26 4>,
+				<0 0 27 &gic 0 27 4>,
+				<0 0 28 &gic 0 28 4>,
+				<0 0 29 &gic 0 29 4>,
+				<0 0 30 &gic 0 30 4>,
+				<0 0 31 &gic 0 31 4>,
+				<0 0 32 &gic 0 32 4>,
+				<0 0 33 &gic 0 33 4>,
+				<0 0 34 &gic 0 34 4>,
+				<0 0 35 &gic 0 35 4>,
+				<0 0 36 &gic 0 36 4>,
+				<0 0 37 &gic 0 37 4>,
+				<0 0 38 &gic 0 38 4>,
+				<0 0 39 &gic 0 39 4>,
+				<0 0 40 &gic 0 40 4>,
+				<0 0 41 &gic 0 41 4>,
+				<0 0 42 &gic 0 42 4>;
+	};
+};
diff --git a/arch/arm/mach-vexpress/Makefile.boot b/arch/arm/mach-vexpress/Makefile.boot
index 318d308..5c633c5 100644
--- a/arch/arm/mach-vexpress/Makefile.boot
+++ b/arch/arm/mach-vexpress/Makefile.boot
@@ -7,4 +7,5 @@ initrd_phys-y	:= 0x60800000
 dtb-$(CONFIG_ARCH_VEXPRESS_DT)	+= vexpress-v2p-ca5s.dtb \
 				   vexpress-v2p-ca9.dtb \
 				   vexpress-v2p-ca15-tc1.dtb \
-				   vexpress-v2p-ca15_a7.dtb
+				   vexpress-v2p-ca15_a7.dtb \
+				   vexpress-xenvm-4.2.dtb
-- 
1.7.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 Sep 19 17:45:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Sep 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 1TEOKi-0004mE-OQ; Wed, 19 Sep 2012 17:45:08 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1TEOKh-0004m3-BY
	for xen-devel@lists.xensource.com; Wed, 19 Sep 2012 17:45:07 +0000
Received: from [85.158.139.211:47719] by server-5.bemta-5.messagelabs.com id
	67/70-30514-2A40A505; Wed, 19 Sep 2012 17:45:06 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-13.tower-206.messagelabs.com!1348076703!15222144!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzA4ODY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8771 invoked from network); 19 Sep 2012 17:45:05 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-13.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Sep 2012 17:45:05 -0000
X-IronPort-AV: E=Sophos;i="4.80,450,1344211200"; d="scan'208";a="38383840"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Sep 2012 17:45:03 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 19 Sep 2012 13:45:02 -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 1TEOKX-0007so-Eg;
	Wed, 19 Sep 2012 18:44:57 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: linux-kernel@vger.kernel.org
Date: Wed, 19 Sep 2012 18:44:18 +0100
Message-ID: <1348076658-4511-1-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.9.5
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com, Ian.Campbell@citrix.com,
	Pawel Moll <pawel.moll@arm.com>, konrad.wilk@oracle.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	linux-arm-kernel@lists.infradead.org
Subject: [Xen-devel] [PATCH] arm: introduce a DTS for Xen unprivileged
	virtual 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

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
CC: Pawel Moll <pawel.moll@arm.com>
CC: linux-arm-kernel@lists.infradead.org
---
 arch/arm/boot/dts/vexpress-xenvm-4.2.dts |  115 ++++++++++++++++++++++++++++++
 arch/arm/mach-vexpress/Makefile.boot     |    3 +-
 2 files changed, 117 insertions(+), 1 deletions(-)
 create mode 100644 arch/arm/boot/dts/vexpress-xenvm-4.2.dts

diff --git a/arch/arm/boot/dts/vexpress-xenvm-4.2.dts b/arch/arm/boot/dts/vexpress-xenvm-4.2.dts
new file mode 100644
index 0000000..bfb802c
--- /dev/null
+++ b/arch/arm/boot/dts/vexpress-xenvm-4.2.dts
@@ -0,0 +1,115 @@
+/*
+ * Xen Virtual Machine for unprivileged guests
+ *
+ * Based on ARM Ltd. Versatile Express CoreTile Express (single CPU)
+ * Cortex-A15 MPCore (V2P-CA15)
+ *
+ */
+
+/dts-v1/;
+
+/include/ "skeleton.dtsi"
+
+/ {
+	model = "XENVM-4.2";
+	compatible = "xen,xenvm-4.2", "arm,vexpress";
+	interrupt-parent = <&gic>;
+
+	chosen {
+		bootargs = "earlyprintk console=hvc0 root=/dev/xvda init=/sbin/init";
+	};
+
+	cpus {
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		cpu@0 {
+			device_type = "cpu";
+			compatible = "arm,cortex-a15";
+			reg = <0>;
+		};
+	};
+
+	memory {
+		device_type = "memory";
+		reg = <0x80000000 0x08000000>;
+	};
+
+	gic: interrupt-controller@2c001000 {
+		compatible = "arm,cortex-a9-gic";
+		#interrupt-cells = <3>;
+		#address-cells = <0>;
+		interrupt-controller;
+		reg = <0x2c001000 0x1000>,
+		      <0x2c002000 0x100>;
+	};
+
+	timer {
+		compatible = "arm,armv7-timer";
+		interrupts = <1 13 0xf08>,
+			     <1 14 0xf08>,
+			     <1 11 0xf08>,
+			     <1 10 0xf08>;
+	};
+
+	hypervisor {
+		compatible = "xen,xen-4.2", "xen,xen";
+		reg = <0xb0000000 0x20000>;
+		interrupts = <1 15 0xf08>;
+	};
+
+	motherboard {
+		arm,v2m-memory-map = "rs1";
+		ranges = <0 0 0x08000000 0x04000000>,
+			 <1 0 0x14000000 0x04000000>,
+			 <2 0 0x18000000 0x04000000>,
+			 <3 0 0x1c000000 0x04000000>,
+			 <4 0 0x0c000000 0x04000000>,
+			 <5 0 0x10000000 0x04000000>;
+
+		interrupt-map-mask = <0 0 63>;
+		interrupt-map = <0 0  0 &gic 0  0 4>,
+				<0 0  1 &gic 0  1 4>,
+				<0 0  2 &gic 0  2 4>,
+				<0 0  3 &gic 0  3 4>,
+				<0 0  4 &gic 0  4 4>,
+				<0 0  5 &gic 0  5 4>,
+				<0 0  6 &gic 0  6 4>,
+				<0 0  7 &gic 0  7 4>,
+				<0 0  8 &gic 0  8 4>,
+				<0 0  9 &gic 0  9 4>,
+				<0 0 10 &gic 0 10 4>,
+				<0 0 11 &gic 0 11 4>,
+				<0 0 12 &gic 0 12 4>,
+				<0 0 13 &gic 0 13 4>,
+				<0 0 14 &gic 0 14 4>,
+				<0 0 15 &gic 0 15 4>,
+				<0 0 16 &gic 0 16 4>,
+				<0 0 17 &gic 0 17 4>,
+				<0 0 18 &gic 0 18 4>,
+				<0 0 19 &gic 0 19 4>,
+				<0 0 20 &gic 0 20 4>,
+				<0 0 21 &gic 0 21 4>,
+				<0 0 22 &gic 0 22 4>,
+				<0 0 23 &gic 0 23 4>,
+				<0 0 24 &gic 0 24 4>,
+				<0 0 25 &gic 0 25 4>,
+				<0 0 26 &gic 0 26 4>,
+				<0 0 27 &gic 0 27 4>,
+				<0 0 28 &gic 0 28 4>,
+				<0 0 29 &gic 0 29 4>,
+				<0 0 30 &gic 0 30 4>,
+				<0 0 31 &gic 0 31 4>,
+				<0 0 32 &gic 0 32 4>,
+				<0 0 33 &gic 0 33 4>,
+				<0 0 34 &gic 0 34 4>,
+				<0 0 35 &gic 0 35 4>,
+				<0 0 36 &gic 0 36 4>,
+				<0 0 37 &gic 0 37 4>,
+				<0 0 38 &gic 0 38 4>,
+				<0 0 39 &gic 0 39 4>,
+				<0 0 40 &gic 0 40 4>,
+				<0 0 41 &gic 0 41 4>,
+				<0 0 42 &gic 0 42 4>;
+	};
+};
diff --git a/arch/arm/mach-vexpress/Makefile.boot b/arch/arm/mach-vexpress/Makefile.boot
index 318d308..5c633c5 100644
--- a/arch/arm/mach-vexpress/Makefile.boot
+++ b/arch/arm/mach-vexpress/Makefile.boot
@@ -7,4 +7,5 @@ initrd_phys-y	:= 0x60800000
 dtb-$(CONFIG_ARCH_VEXPRESS_DT)	+= vexpress-v2p-ca5s.dtb \
 				   vexpress-v2p-ca9.dtb \
 				   vexpress-v2p-ca15-tc1.dtb \
-				   vexpress-v2p-ca15_a7.dtb
+				   vexpress-v2p-ca15_a7.dtb \
+				   vexpress-xenvm-4.2.dtb
-- 
1.7.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 Sep 19 18:43:37 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Sep 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 1TEPEu-0005M7-F9; Wed, 19 Sep 2012 18:43: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 1TEPEt-0005M2-1g
	for xen-devel@lists.xen.org; Wed, 19 Sep 2012 18:43:11 +0000
Received: from [85.158.143.35:52228] by server-3.bemta-4.messagelabs.com id
	E8/EE-10986-E321A505; Wed, 19 Sep 2012 18:43:10 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-8.tower-21.messagelabs.com!1348080189!15754387!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA1MDgyMDI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18797 invoked from network); 19 Sep 2012 18:43:10 -0000
Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25)
	by server-8.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 19 Sep 2012 18:43: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 3A56B2059;
	Wed, 19 Sep 2012 21:43:08 +0300 (EEST)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id B98412005D; Wed, 19 Sep 2012 21:43:07 +0300 (EEST)
Date: Wed, 19 Sep 2012 21:43:07 +0300
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: Konrad Rzeszutek Wilk <konrad@kernel.org>
Message-ID: <20120919184307.GT8912@reaktio.net>
References: <CALCpXpBnAQr=jk5LbZnQPAuJHrKEAL0ELcZ3L2BRQRUfGbUvAw@mail.gmail.com>
	<CACJDEmo-cxm0MiAtSo7sXdKsWChTS4NW4SNsOM_pBOgwr2W7BA@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CACJDEmo-cxm0MiAtSo7sXdKsWChTS4NW4SNsOM_pBOgwr2W7BA@mail.gmail.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: Qian Hu <qianhu2011@gmail.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] usbpassthrough of xen-4.1.2
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Sep 19, 2012 at 01:24:35PM -0400, Konrad Rzeszutek Wilk wrote:
> On Wed, Sep 19, 2012 at 4:53 AM, Qian Hu <qianhu2011@gmail.com> wrote:
> > Hi, everyone!
> >
> > I am working on the USB passthrough of Xen-4.1.2. My host OS  is Fedora 14
> > and the guest OS is win7.
> >
> > According to the wiki page(http://wiki.xen.org/wiki/Xen_USB_Passthrough),
> >
> > xen supports passthrough of usb device from dom0 to guests. I have tried the
> > Xen HVM guest qemu-dm usb1.1 emulation,
> >
> > by specifying "usb = 1" and "usbdevice = host:xxxx:yyyy". But, the mouse
> > could work, the keyboard and usb storage failed.
> 
> You need to give more details. How did it not work? Did it work in Linux?
> >
> > If I change the guest OS to winXP, it is surprising that only the usb
> > storage can be detected in the guest.
> >
> > I have also tried the PVUSB, it didn't work either.
> 
> Right, that is b/c it would only work with Linux.
>

Not really true. James Harper's GPLPV drivers do contain usbfront driver for Windows..

(not much tested, but it's there).

-- Pasi


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 19 18:43:37 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Sep 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 1TEPEu-0005M7-F9; Wed, 19 Sep 2012 18:43: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 1TEPEt-0005M2-1g
	for xen-devel@lists.xen.org; Wed, 19 Sep 2012 18:43:11 +0000
Received: from [85.158.143.35:52228] by server-3.bemta-4.messagelabs.com id
	E8/EE-10986-E321A505; Wed, 19 Sep 2012 18:43:10 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-8.tower-21.messagelabs.com!1348080189!15754387!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA1MDgyMDI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18797 invoked from network); 19 Sep 2012 18:43:10 -0000
Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25)
	by server-8.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 19 Sep 2012 18:43: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 3A56B2059;
	Wed, 19 Sep 2012 21:43:08 +0300 (EEST)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id B98412005D; Wed, 19 Sep 2012 21:43:07 +0300 (EEST)
Date: Wed, 19 Sep 2012 21:43:07 +0300
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: Konrad Rzeszutek Wilk <konrad@kernel.org>
Message-ID: <20120919184307.GT8912@reaktio.net>
References: <CALCpXpBnAQr=jk5LbZnQPAuJHrKEAL0ELcZ3L2BRQRUfGbUvAw@mail.gmail.com>
	<CACJDEmo-cxm0MiAtSo7sXdKsWChTS4NW4SNsOM_pBOgwr2W7BA@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CACJDEmo-cxm0MiAtSo7sXdKsWChTS4NW4SNsOM_pBOgwr2W7BA@mail.gmail.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: Qian Hu <qianhu2011@gmail.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] usbpassthrough of xen-4.1.2
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Sep 19, 2012 at 01:24:35PM -0400, Konrad Rzeszutek Wilk wrote:
> On Wed, Sep 19, 2012 at 4:53 AM, Qian Hu <qianhu2011@gmail.com> wrote:
> > Hi, everyone!
> >
> > I am working on the USB passthrough of Xen-4.1.2. My host OS  is Fedora 14
> > and the guest OS is win7.
> >
> > According to the wiki page(http://wiki.xen.org/wiki/Xen_USB_Passthrough),
> >
> > xen supports passthrough of usb device from dom0 to guests. I have tried the
> > Xen HVM guest qemu-dm usb1.1 emulation,
> >
> > by specifying "usb = 1" and "usbdevice = host:xxxx:yyyy". But, the mouse
> > could work, the keyboard and usb storage failed.
> 
> You need to give more details. How did it not work? Did it work in Linux?
> >
> > If I change the guest OS to winXP, it is surprising that only the usb
> > storage can be detected in the guest.
> >
> > I have also tried the PVUSB, it didn't work either.
> 
> Right, that is b/c it would only work with Linux.
>

Not really true. James Harper's GPLPV drivers do contain usbfront driver for Windows..

(not much tested, but it's there).

-- Pasi


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 19 19:08:29 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Sep 2012 19:08:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TEPcw-0005ae-KY; Wed, 19 Sep 2012 19:08:02 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <nathan@gt.net>) id 1TEPcv-0005aZ-LR
	for xen-devel@lists.xen.org; Wed, 19 Sep 2012 19:08:01 +0000
Received: from [85.158.143.99:18560] by server-3.bemta-4.messagelabs.com id
	09/7B-10986-1181A505; Wed, 19 Sep 2012 19:08:01 +0000
X-Env-Sender: nathan@gt.net
X-Msg-Ref: server-10.tower-216.messagelabs.com!1348081678!24597935!1
X-Originating-IP: [208.70.244.21]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18400 invoked from network); 19 Sep 2012 19:08:00 -0000
Received: from gossamer.nmsrv.com (HELO gossamer.nmsrv.com) (208.70.244.21)
	by server-10.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 19 Sep 2012 19:08:00 -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=zsA7DWJ5j0fI
	EDmXHPgWu7UVe7A=; b=ACO0DWC/2viF5k9fVTLsCdZ59ejZAn/ceDYD0nvr/qq+
	Y0aBluXqb+D1akP4u8vFx1Qnf1GfLT2miI1Ebb9UBhEgYjDW7Ckjw/pDKMrPc2+i
	XqS5Nqz0HtPFdf2H74V8hmRO0NHn2ycUZpdwMpHwC1P++1GF9czilmq+d1eARj0=
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=sv7snm
	aqIazlgtoeips7PPi56NVVyYR5K3st/Ymi12jq3xx9sQLRzzQ+uQ2e24Rxpd2GIg
	FLlKa32XMrp9T6iEcUmyID3rcL0MBYOZcPpvBTMrkecaH9PJ0TE8fbK1VFIf2eWH
	wOQDjJcFe9nL7YvAkRuWZ6v2/uzI5mele9DUU=
Received: (qmail 20286 invoked from network); 19 Sep 2012 19:07:57 -0000
X-AntiVirus: Clean
Received: from gateway.gossamer-threads.com (HELO ?192.168.1.152?)
	(nathan@gt.net@208.70.247.145)
	by gossamer.nmsrv.com with ESMTPSA (DHE-RSA-CAMELLIA256-SHA encrypted);
	19 Sep 2012 19:07:57 -0000
Message-ID: <505A180C.1020606@gt.net>
Date: Wed, 19 Sep 2012 12:07:56 -0700
From: Nathan March <nathan@gt.net>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:15.0) Gecko/20120907 Thunderbird/15.0.1
MIME-Version: 1.0
To: xen-devel@lists.xen.org
References: <5057AB8D.3040200@gt.net>
In-Reply-To: <5057AB8D.3040200@gt.net>
Subject: Re: [Xen-devel] VM spontaneously losing network on 10gig 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-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 9/17/2012 4:00 PM, Nathan March wrote:
> Hi All,
>
> Having a very strange problem where a VM's bridge will spontaneously 
> stop bridging traffic. This only seems to occur on our 10gig 
> interfaces (intel x540 on ixgbe driver, mtu 9000), which are 2x links 
> bonded into bond0, then broken down into pvlan462/pvlan463/etc before 
> being bridged with the DomU's. Everything works great at first but 
> several hours after starting a large rsync traffic stops crossing the 
> bridge. Once it's stopped working it only affects that single VM on 
> that single interface. Other VM's on the same dom0 still have access 
> to the same affected vlan.

In case anyone else runs into something like this, it appears to be a 
bug in ixgbe. Switching to using the latest release as a module instead 
of the built in kernel driver, resolved this.

- Nathan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 19 19:08:29 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Sep 2012 19:08:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TEPcw-0005ae-KY; Wed, 19 Sep 2012 19:08:02 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <nathan@gt.net>) id 1TEPcv-0005aZ-LR
	for xen-devel@lists.xen.org; Wed, 19 Sep 2012 19:08:01 +0000
Received: from [85.158.143.99:18560] by server-3.bemta-4.messagelabs.com id
	09/7B-10986-1181A505; Wed, 19 Sep 2012 19:08:01 +0000
X-Env-Sender: nathan@gt.net
X-Msg-Ref: server-10.tower-216.messagelabs.com!1348081678!24597935!1
X-Originating-IP: [208.70.244.21]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18400 invoked from network); 19 Sep 2012 19:08:00 -0000
Received: from gossamer.nmsrv.com (HELO gossamer.nmsrv.com) (208.70.244.21)
	by server-10.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 19 Sep 2012 19:08:00 -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=zsA7DWJ5j0fI
	EDmXHPgWu7UVe7A=; b=ACO0DWC/2viF5k9fVTLsCdZ59ejZAn/ceDYD0nvr/qq+
	Y0aBluXqb+D1akP4u8vFx1Qnf1GfLT2miI1Ebb9UBhEgYjDW7Ckjw/pDKMrPc2+i
	XqS5Nqz0HtPFdf2H74V8hmRO0NHn2ycUZpdwMpHwC1P++1GF9czilmq+d1eARj0=
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=sv7snm
	aqIazlgtoeips7PPi56NVVyYR5K3st/Ymi12jq3xx9sQLRzzQ+uQ2e24Rxpd2GIg
	FLlKa32XMrp9T6iEcUmyID3rcL0MBYOZcPpvBTMrkecaH9PJ0TE8fbK1VFIf2eWH
	wOQDjJcFe9nL7YvAkRuWZ6v2/uzI5mele9DUU=
Received: (qmail 20286 invoked from network); 19 Sep 2012 19:07:57 -0000
X-AntiVirus: Clean
Received: from gateway.gossamer-threads.com (HELO ?192.168.1.152?)
	(nathan@gt.net@208.70.247.145)
	by gossamer.nmsrv.com with ESMTPSA (DHE-RSA-CAMELLIA256-SHA encrypted);
	19 Sep 2012 19:07:57 -0000
Message-ID: <505A180C.1020606@gt.net>
Date: Wed, 19 Sep 2012 12:07:56 -0700
From: Nathan March <nathan@gt.net>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:15.0) Gecko/20120907 Thunderbird/15.0.1
MIME-Version: 1.0
To: xen-devel@lists.xen.org
References: <5057AB8D.3040200@gt.net>
In-Reply-To: <5057AB8D.3040200@gt.net>
Subject: Re: [Xen-devel] VM spontaneously losing network on 10gig 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-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 9/17/2012 4:00 PM, Nathan March wrote:
> Hi All,
>
> Having a very strange problem where a VM's bridge will spontaneously 
> stop bridging traffic. This only seems to occur on our 10gig 
> interfaces (intel x540 on ixgbe driver, mtu 9000), which are 2x links 
> bonded into bond0, then broken down into pvlan462/pvlan463/etc before 
> being bridged with the DomU's. Everything works great at first but 
> several hours after starting a large rsync traffic stops crossing the 
> bridge. Once it's stopped working it only affects that single VM on 
> that single interface. Other VM's on the same dom0 still have access 
> to the same affected vlan.

In case anyone else runs into something like this, it appears to be a 
bug in ixgbe. Switching to using the latest release as a module instead 
of the built in kernel driver, resolved this.

- Nathan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 19 19:29:50 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Sep 2012 19: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 1TEPxe-0005lw-Qa; Wed, 19 Sep 2012 19:29:26 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mukesh.rathor@oracle.com>) id 1TEPxd-0005lr-B3
	for Xen-devel@lists.xensource.com; Wed, 19 Sep 2012 19:29:25 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1348082957!2347292!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzUwOTQ4\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29500 invoked from network); 19 Sep 2012 19:29:19 -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; 19 Sep 2012 19:29:19 -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 q8JJT9qg000365
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 19 Sep 2012 19:29:10 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q8JJT909021357
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 19 Sep 2012 19:29:09 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
	q8JJT8WV007438; Wed, 19 Sep 2012 14:29:08 -0500
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 19 Sep 2012 12:29:08 -0700
Date: Wed, 19 Sep 2012 12:29:07 -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: <20120919122907.1e72704b@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] PVH: iopl
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 noticed anamoly in my code the way IOPL is set. For vcpu 0, its done
via

        set_iopl.iopl = 1;
	rc = HYPERVISOR_physdev_op(PHYSDEVOP_set_iopl, &set_iopl);

in xen_start_kernel() in enlighten.c. But, for non boot vcpus, its done
via eflags in cpu_initialize_context():
        ctxt->user_regs.eflags = 0x1000; /* IOPL_RING1 */

Since I am running in HVM container, IO ops cause vmexit. I can just
check eflags at that point for guest IOPL. So I am thinking of just
using eflags and not doing the hcall.  It will also reduce the need for
another field in the struct pv_vcpu for me. 

(JFYI: EXIT_REASON_IO_INSTRUCTION cause emulate_privileged_op() to be
called).

What do you guys think?

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 Sep 19 19:29:50 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Sep 2012 19: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 1TEPxe-0005lw-Qa; Wed, 19 Sep 2012 19:29:26 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mukesh.rathor@oracle.com>) id 1TEPxd-0005lr-B3
	for Xen-devel@lists.xensource.com; Wed, 19 Sep 2012 19:29:25 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1348082957!2347292!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzUwOTQ4\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29500 invoked from network); 19 Sep 2012 19:29:19 -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; 19 Sep 2012 19:29:19 -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 q8JJT9qg000365
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 19 Sep 2012 19:29:10 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q8JJT909021357
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 19 Sep 2012 19:29:09 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
	q8JJT8WV007438; Wed, 19 Sep 2012 14:29:08 -0500
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 19 Sep 2012 12:29:08 -0700
Date: Wed, 19 Sep 2012 12:29:07 -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: <20120919122907.1e72704b@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] PVH: iopl
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 noticed anamoly in my code the way IOPL is set. For vcpu 0, its done
via

        set_iopl.iopl = 1;
	rc = HYPERVISOR_physdev_op(PHYSDEVOP_set_iopl, &set_iopl);

in xen_start_kernel() in enlighten.c. But, for non boot vcpus, its done
via eflags in cpu_initialize_context():
        ctxt->user_regs.eflags = 0x1000; /* IOPL_RING1 */

Since I am running in HVM container, IO ops cause vmexit. I can just
check eflags at that point for guest IOPL. So I am thinking of just
using eflags and not doing the hcall.  It will also reduce the need for
another field in the struct pv_vcpu for me. 

(JFYI: EXIT_REASON_IO_INSTRUCTION cause emulate_privileged_op() to be
called).

What do you guys think?

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 Sep 19 20:13:27 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Sep 2012 20:13:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TEQdl-00066n-Cp; Wed, 19 Sep 2012 20:12:57 +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 1TEQdj-00066i-F4
	for xen-devel@lists.xensource.com; Wed, 19 Sep 2012 20:12:55 +0000
Received: from [85.158.139.211:30948] by server-4.bemta-5.messagelabs.com id
	34/48-23042-6472A505; Wed, 19 Sep 2012 20:12:54 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-11.tower-206.messagelabs.com!1348085572!19229193!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDc2MDk3OQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18552 invoked from network); 19 Sep 2012 20:12:54 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-11.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 19 Sep 2012 20:12:54 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q8JKCnUL020114
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 19 Sep 2012 20:12:50 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q8JKCmmp024086
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 19 Sep 2012 20:12:48 GMT
Received: from abhmt120.oracle.com (abhmt120.oracle.com [141.146.116.72])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q8JKClKf004427; Wed, 19 Sep 2012 15:12:47 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 19 Sep 2012 13:12:47 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 5E36B402EC; Wed, 19 Sep 2012 16:01:57 -0400 (EDT)
Date: Wed, 19 Sep 2012 16:01:57 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: William Dauchy <wdauchy@gmail.com>
Message-ID: <20120919200157.GA16385@phenom.dumpdata.com>
References: <CAJ75kXZm-BqWdL2O41XkSE1VCdd4ruW=+CqDmR1b3=701RnXmw@mail.gmail.com>
	<20120918133650.GC12053@phenom.dumpdata.com>
	<CAJ75kXabH_ZE2L_u8y2eD9H6W8AG1OKNv-GOM9uRK7CDtas5zQ@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAJ75kXabH_ZE2L_u8y2eD9H6W8AG1OKNv-GOM9uRK7CDtas5zQ@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] Error getting mfn
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Sep 19, 2012 at 03:51:08PM +0200, William Dauchy wrote:
> Hi Konrad,
> 
> Thank your for you reply.
> 
> On Tue, Sep 18, 2012 at 3:36 PM, Konrad Rzeszutek Wilk
> <konrad.wilk@oracle.com> wrote:
> > Since this is 32-bit, I wonder if you are hitting the CONFIG_NUMA issue...
> 
> yes I do have CONFIG_NUMA enabled
> 
> > but I think you reported it some time ago and did you try the fix?
> 
> Are you talking about:
> http://lists.xen.org/archives/html/xen-devel/2012-05/msg02204.html
> because I did validate the fix but for me it was a different issue.
> I saw that the fix was not accepted though https://lkml.org/lkml/2012/5/31/417
> 
> Please note that this fix was also applied on top of my 3.4.7 kernel.
> 
> > That shouldn't be it - b/c the URL you mentioned is for the set of patches
> > that are destined for v3.7.
> 
> yup thought it could be related. never mind.
> 
> > Please use 'sync_console loglvl=all dom0_max_vcpus=1 console=com1 com1=xxxxx' and on the Linux command line:
> > 'console=hvc0 debug loglevel=8"
     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

And also please use those options for the Xen command line I mentioned.

I really need both Linux and Xen serial log interleaved. Those arguments I mentioned
will take care of that.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 19 20:13:27 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Sep 2012 20:13:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TEQdl-00066n-Cp; Wed, 19 Sep 2012 20:12:57 +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 1TEQdj-00066i-F4
	for xen-devel@lists.xensource.com; Wed, 19 Sep 2012 20:12:55 +0000
Received: from [85.158.139.211:30948] by server-4.bemta-5.messagelabs.com id
	34/48-23042-6472A505; Wed, 19 Sep 2012 20:12:54 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-11.tower-206.messagelabs.com!1348085572!19229193!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDc2MDk3OQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18552 invoked from network); 19 Sep 2012 20:12:54 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-11.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 19 Sep 2012 20:12:54 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q8JKCnUL020114
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 19 Sep 2012 20:12:50 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q8JKCmmp024086
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 19 Sep 2012 20:12:48 GMT
Received: from abhmt120.oracle.com (abhmt120.oracle.com [141.146.116.72])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q8JKClKf004427; Wed, 19 Sep 2012 15:12:47 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 19 Sep 2012 13:12:47 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 5E36B402EC; Wed, 19 Sep 2012 16:01:57 -0400 (EDT)
Date: Wed, 19 Sep 2012 16:01:57 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: William Dauchy <wdauchy@gmail.com>
Message-ID: <20120919200157.GA16385@phenom.dumpdata.com>
References: <CAJ75kXZm-BqWdL2O41XkSE1VCdd4ruW=+CqDmR1b3=701RnXmw@mail.gmail.com>
	<20120918133650.GC12053@phenom.dumpdata.com>
	<CAJ75kXabH_ZE2L_u8y2eD9H6W8AG1OKNv-GOM9uRK7CDtas5zQ@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAJ75kXabH_ZE2L_u8y2eD9H6W8AG1OKNv-GOM9uRK7CDtas5zQ@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] Error getting mfn
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Sep 19, 2012 at 03:51:08PM +0200, William Dauchy wrote:
> Hi Konrad,
> 
> Thank your for you reply.
> 
> On Tue, Sep 18, 2012 at 3:36 PM, Konrad Rzeszutek Wilk
> <konrad.wilk@oracle.com> wrote:
> > Since this is 32-bit, I wonder if you are hitting the CONFIG_NUMA issue...
> 
> yes I do have CONFIG_NUMA enabled
> 
> > but I think you reported it some time ago and did you try the fix?
> 
> Are you talking about:
> http://lists.xen.org/archives/html/xen-devel/2012-05/msg02204.html
> because I did validate the fix but for me it was a different issue.
> I saw that the fix was not accepted though https://lkml.org/lkml/2012/5/31/417
> 
> Please note that this fix was also applied on top of my 3.4.7 kernel.
> 
> > That shouldn't be it - b/c the URL you mentioned is for the set of patches
> > that are destined for v3.7.
> 
> yup thought it could be related. never mind.
> 
> > Please use 'sync_console loglvl=all dom0_max_vcpus=1 console=com1 com1=xxxxx' and on the Linux command line:
> > 'console=hvc0 debug loglevel=8"
     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

And also please use those options for the Xen command line I mentioned.

I really need both Linux and Xen serial log interleaved. Those arguments I mentioned
will take care of that.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 19 21:07:41 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Sep 2012 21:07:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TERUH-0006QU-Uj; Wed, 19 Sep 2012 21:07:13 +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 1TERUG-0006QP-GH
	for xen-devel@lists.xen.org; Wed, 19 Sep 2012 21:07:12 +0000
Received: from [85.158.143.99:12851] by server-3.bemta-4.messagelabs.com id
	D6/68-10986-FF33A505; Wed, 19 Sep 2012 21:07:11 +0000
X-Env-Sender: ben.guthro@gmail.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1348088829!21243482!1
X-Originating-IP: [209.85.223.173]
X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_20_30,HTML_MESSAGE,
	RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24427 invoked from network); 19 Sep 2012 21:07:10 -0000
Received: from mail-ie0-f173.google.com (HELO mail-ie0-f173.google.com)
	(209.85.223.173)
	by server-8.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Sep 2012 21:07:10 -0000
Received: by iebc10 with SMTP id c10so2866717ieb.32
	for <xen-devel@lists.xen.org>; Wed, 19 Sep 2012 14: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;
	bh=AF3Fevwe2h/vN4WxT+5WjLSDJzldioLT+ybQuCTeuik=;
	b=VjrmfMOXCqZiQlYbacjjkrmiuxWHxzOf0biaai89VFSPlbzcDb0nBQ1+bPoa2CNKM4
	rOorHhfou5Xf04lzJ30nZebK24LbidHeLtnWhX+l5PXaPbc99IX+G0iT4cLW3N6PfpYW
	sbxiuNmhGm4MDGf8L6Up8qEyG9d3QG0TM9FyjHHBsWFv1q+KXKgFt3pz2axIrdm1LOW+
	9mpgrXWHRkfMKamOD8iz0slIa8ZlHSH1Uz4izoY53C2hyo8bd34GPIYWPrBazheO+wOm
	v7ZNSLhhqBkNbMV2YWovIyUtArD/QRickeSbxwdxtclw9LTxQcnAauvpxK8EVoFSOkKw
	w67w==
MIME-Version: 1.0
Received: by 10.42.110.130 with SMTP id q2mr546434icp.53.1348088828735; Wed,
	19 Sep 2012 14:07:08 -0700 (PDT)
Received: by 10.64.55.132 with HTTP; Wed, 19 Sep 2012 14:07:08 -0700 (PDT)
In-Reply-To: <CAOvdn6XYjyYEgtrPskjCLK4BZWaPyriNGSVGzumdOP8-6=P_=Q@mail.gmail.com>
References: <CAOvdn6WwgBD-2yf1uu3m9-16=Tb5KUrybXf2KibtnxKbP7YtwA@mail.gmail.com>
	<CAOvdn6UBW-yTOMd3YSf5M9JiHLRivyaKL-qzcKG8epszqaKmGg@mail.gmail.com>
	<20120807163320.GC15053@phenom.dumpdata.com>
	<CAOvdn6XcRGKtJxGwJO8J+ZBJr89wfTLc1woW5rhtMM540H9h1w@mail.gmail.com>
	<CAOvdn6XUoSeGoo7X=AJ1kpDxZB9HZEv+TJ4v-=FHcyR4=CHK-w@mail.gmail.com>
	<502240F302000078000937A6@nat28.tlf.novell.com>
	<CAOvdn6WN3kxC8Bb9g6MpfLULu47EGSGCtajPc-SFeJ-8VSUQDQ@mail.gmail.com>
	<CAOvdn6Xk1inm1hU55i0phU2qvSWyJLNoyDdn43biBAY2OewPtw@mail.gmail.com>
	<5023F5400200007800093F4E@nat28.tlf.novell.com>
	<CAOvdn6U-f3C4U8xVPvDyRFkFFLkbfiCXg_n+9zgA9V5u+q5jfw@mail.gmail.com>
	<5023F8B80200007800093F8C@nat28.tlf.novell.com>
	<CAOvdn6XKHfete_+=Hkvt20G7_cJ-4i8+9j9YD30OxzQ16Ru-+g@mail.gmail.com>
	<5024CB720200007800094124@nat28.tlf.novell.com>
	<CAOvdn6VVJdhWVYa-gNVt3euE4AbGi1TijUCUd1wGzv0SCWEUYA@mail.gmail.com>
	<CAOvdn6USnG9Y4MNBhrDZmob0oJ8BgFfKTvFEhcKbXDxNmzfZ-Q@mail.gmail.com>
	<502B75BA0200007800094FD4@nat28.tlf.novell.com>
	<CAOvdn6Ww5oEj6Xg=XT4dWCYWUBuOdPqLz-CqNjz4HmCScE+==g@mail.gmail.com>
	<CAOvdn6Wsjds_dmZ0dwDTYmD-o-OqjBH5-b9mitAuUADE+A4_ag@mail.gmail.com>
	<502BB8FD02000078000951E0@nat28.tlf.novell.com>
	<CAOvdn6VD6bp13F-tvYdkBsj4hkhE7PTGZrapndtdHrDKeZqccg@mail.gmail.com>
	<502CCC0002000078000955C4@nat28.tlf.novell.com>
	<CAOvdn6VEuX7R2_wz74ZvCxMjC-=YUir9kP5sdxEVaKVspRUd_w@mail.gmail.com>
	<502CF0A8020000780009574E@nat28.tlf.novell.com>
	<CAOvdn6VsZvn_1TCWYeuyY5YuTcP8=miK2KwE4583nsj6Qjb_vg@mail.gmail.com>
	<504494FB0200007800098398@nat28.tlf.novell.com>
	<CAOvdn6UT13qvWbMyfZkWND03RoVKVSgb6wW4yqTUpuBYEX01Dg@mail.gmail.com>
	<5048958D02000078000993EB@nat28.tlf.novell.com>
	<CAOvdn6WrNK1Jn_Y_P7C3AwX6ApVcgzacLA_x-u=xBQtebnuPxA@mail.gmail.com>
	<CAOvdn6U_Z=KdEo56nqe7jN54BwiesRJqDOz_VzVNpkWGfFRd2A@mail.gmail.com>
	<5049CEAE0200007800099A33@nat28.tlf.novell.com>
	<CAOvdn6XmsEfs+aO7nqBHdA61HpT_n_8W95u0MMq5J21tZCFbzw@mail.gmail.com>
	<5049F37A0200007800099BDA@nat28.tlf.novell.com>
	<CAOvdn6W+=OYTH3xTWBxUB8f_2tuZYKPTo-eJG0jfkaJ2rVutCA@mail.gmail.com>
	<504A024E0200007800099C5A@nat28.tlf.novell.com>
	<CAOvdn6XYjyYEgtrPskjCLK4BZWaPyriNGSVGzumdOP8-6=P_=Q@mail.gmail.com>
Date: Wed, 19 Sep 2012 17:07:08 -0400
X-Google-Sender-Auth: EDVHUpPvRgy0xNhrCtMNn81Odk8
Message-ID: <CAOvdn6Xn1ZnontBO0KoJE9hgBsW-a1rR2EhWYEpgbbrELkXZNw@mail.gmail.com>
From: Ben Guthro <ben@guthro.net>
To: Jan Beulich <JBeulich@suse.com>
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>, john.baboval@citrix.com,
	Thomas Goetz <thomas.goetz@citrix.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen4.2 S3 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: multipart/mixed; boundary="===============8517680464768631549=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============8517680464768631549==
Content-Type: multipart/alternative; boundary=485b397dcfb5c3325e04ca1463c1

--485b397dcfb5c3325e04ca1463c1
Content-Type: text/plain; charset=ISO-8859-1

No hardware debugger just yet - but I've moved to another machine (Lenovo
T400 laptop) - and am now seeing the following stack trace when I resume
(this is using the tip of the 4.2-testing tree)

It looks like either the vcpu, or the runstate is NULL, at this point in
the resume process...


(XEN) Finishing wakeup from ACPI S3 state.
(XEN) Enabling non-boot CPUs  ...
(XEN) CPU#1 already initialized!
(XEN) Stuck ??
(XEN) Error taking CPU1 up: -5
[   38.570054] ACPI: Low-level resume complete
[   38.570054] PM: Restoring platform NVS memory
[   38.570054] Enabling non-boot CPUs ...
(XEN) ----[ Xen-4.2.1-pre  x86_64  debug=n  Tainted:    C ]----
(XEN) CPU:    0
(XEN) RIP:    e008:[<ffff82c480120585>] vcpu_runstate_get+0xe5/0x130
(XEN) RFLAGS: 0000000000010006   CONTEXT: hypervisor
(XEN) rax: 00007d3b7fd17180   rbx: ffff8300bd2fe000   rcx: 0000000000000000
(XEN) rdx: ffff08003fc8bd80   rsi: ffff82c48029fe28   rdi: ffff8300bd2fe000
(XEN) rbp: ffff82c48029fe28   rsp: ffff82c48029fdf8   r8:  0000000000000008
(XEN) r9:  00000000000001c0   r10: ffff82c48021f4a0   r11: 0000000000000282
(XEN) r12: ffff82c4802e8ee0   r13: ffff880039762da0   r14: ffff82c4802d3140
(XEN) r15: fffffffffffffff2   cr0: 000000008005003b   cr4: 00000000000026f0
(XEN) cr3: 0000000139ee4000   cr2: 0000000000000060
(XEN) ds: 0000   es: 0000   fs: 0000   gs: 0000   ss: e010   cs: e008
(XEN) Xen stack trace from rsp=ffff82c48029fdf8:
(XEN)    ffff8300bd2fe000 ffff82c48029ff18 ffff880037481d40 ffff880039762da0
(XEN)    0000000000000001 ffff82c480157df4 0000000000000070 ffff82f6016db300
(XEN)    00000000000b6d98 ffff8301355d8000 0000000000000070 ffff82c4801702ab
(XEN)    ffff88003fc8bd80 0000000000000000 0000000000000020 ffff8300bd2fe000
(XEN)    ffff8301355d8000 ffff880037481d40 ffff880039762da0 0000000000000001
(XEN)    0000000000000003 ffff82c4801058df ffff82c48029ff18 ffff82c48011462e
(XEN)    0000000000000000 0000000000000000 0000000400000004 ffff82c48029ff18
(XEN)    0000000000000010 ffff8300bd6a0000 ffff8800374819a8 ffff8300bd6a0000
(XEN)    ffff880037481d48 0000000000000001 ffff880039762da0 ffff82c480214288
(XEN)    0000000000000003 0000000000000001 ffff880039762da0 0000000000000001
(XEN)    ffff880037481d48 0000000000000001 0000000000000282 ffff880002dc4240
(XEN)    00000000000001c0 00000000000001c0 0000000000000018 ffffffff8100130a
(XEN)    ffff880037481d40 0000000000000001 0000000000000005 0000010000000000
(XEN)    ffffffff8100130a 000000000000e033 0000000000000282 ffff880037481d20
(XEN)    000000000000e02b 0000000000000000 0000000000000000 0000000000000000
(XEN)    0000000000000000 0000000000000000 ffff8300bd6a0000 0000000000000000
(XEN)    0000000000000000
(XEN) Xen call trace:
(XEN)    [<ffff82c480120585>] vcpu_runstate_get+0xe5/0x130
(XEN)    [<ffff82c480157df4>] arch_do_vcpu_op+0x134/0x5d0
(XEN)    [<ffff82c4801702ab>] do_update_descriptor+0x1db/0x220
(XEN)    [<ffff82c4801058df>] do_vcpu_op+0x6f/0x4a0
(XEN)    [<ffff82c48011462e>] do_multicall+0x13e/0x330
(XEN)    [<ffff82c480214288>] syscall_enter+0x88/0x8d
(XEN)
(XEN) Pagetable walk from 0000000000000060:
(XEN)  L4[0x000] = 00000001004a5067 0000000000038c9d
(XEN)  L3[0x000] = 000000013a703067 0000000000003094
(XEN)  L2[0x000] = 0000000000000000 ffffffffffffffff
(XEN)
(XEN) ****************************************
(XEN) Panic on CPU 0:
(XEN) FATAL PAGE FAULT
(XEN) [error_code=0000]
(XEN) Faulting linear address: 0000000000000060
(XEN) ****************************************
(XEN)
(XEN) Reboot in five seconds...


On Fri, Sep 7, 2012 at 12:06 PM, Ben Guthro <ben@guthro.net> wrote:

> I'll work on getting a JTAG, ICE, or something else - it is on an
> Intel SDP - so it should have the ports for it.
>
> My current suspicion on this is that the hardware registers are not
> being programmed the same way as they were in 4.0.x
> (Since the "pulsing power button LED" on the laptops, and the behavior
> of the Desktop SDP are now similar)
>
> Once again - I don't have a lot of evidence to back this up - however,
> if I ifdef out the register writes that actually start the low level
> suspend - in
> xen/arch/x86/acpi/power.c  acpi_enter_sleep_state() - the rest of the
> suspend process completes as though the machine suspended, and then
> immediately resumed.
>
> In this case - the system seems to be functioning properly.
>
>
>
>
>
> Hack to prevent low level S3 attached.
>
>
>
> On Fri, Sep 7, 2012 at 8:18 AM, Jan Beulich <JBeulich@suse.com> wrote:
> >>>> On 07.09.12 at 13:51, Ben Guthro <ben@guthro.net> wrote:
> >> However, when I run with console=none, the observed behavior is very
> >> different.
> >> The system seems to go to sleep successfully - but when I press the
> >> power button to wake it up - the power comes on - the fans spin up -
> >> but the system is unresponsive.
> >> No video
> >> No network
> >> keyboard LEDs (Caps,Numlock) do not light up.
> >>
> >>
> >> Alternate debugging strategies welcome.
> >
> > I'm afraid other than being lucky to spot something via code
> > inspection, the only alternative is an ITP/ICE. Maybe Intel folks
> > could help out debugging this if it's reproducible for them.
> >
> > Jan
> >
>

--485b397dcfb5c3325e04ca1463c1
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

No hardware debugger just yet - but I&#39;ve moved to another machine (Leno=
vo T400 laptop) - and am now seeing the following stack trace when I resume=
<div>(this is using the tip of the 4.2-testing tree)</div><div><br></div>
<div>It looks like either the vcpu, or the runstate is NULL, at this point =
in the resume process...</div><div><br></div><div><br></div><div><div>(XEN)=
 Finishing wakeup from ACPI S3 state.</div><div>(XEN) Enabling non-boot CPU=
s =A0...</div>
<div>(XEN) CPU#1 already initialized!</div><div>(XEN) Stuck ??</div><div>(X=
EN) Error taking CPU1 up: -5</div><div>[ =A0 38.570054] ACPI: Low-level res=
ume complete</div><div>[ =A0 38.570054] PM: Restoring platform NVS memory</=
div>
<div>[ =A0 38.570054] Enabling non-boot CPUs ...</div><div>(XEN) ----[ Xen-=
4.2.1-pre =A0x86_64 =A0debug=3Dn =A0Tainted: =A0 =A0C ]----</div><div>(XEN)=
 CPU: =A0 =A00</div><div>(XEN) RIP: =A0 =A0e008:[&lt;ffff82c480120585&gt;] =
vcpu_runstate_get+0xe5/0x130</div>
<div>(XEN) RFLAGS: 0000000000010006 =A0 CONTEXT: hypervisor</div><div>(XEN)=
 rax: 00007d3b7fd17180 =A0 rbx: ffff8300bd2fe000 =A0 rcx: 0000000000000000<=
/div><div>(XEN) rdx: ffff08003fc8bd80 =A0 rsi: ffff82c48029fe28 =A0 rdi: ff=
ff8300bd2fe000</div>
<div>(XEN) rbp: ffff82c48029fe28 =A0 rsp: ffff82c48029fdf8 =A0 r8: =A000000=
00000000008</div><div>(XEN) r9: =A000000000000001c0 =A0 r10: ffff82c48021f4=
a0 =A0 r11: 0000000000000282</div><div>(XEN) r12: ffff82c4802e8ee0 =A0 r13:=
 ffff880039762da0 =A0 r14: ffff82c4802d3140</div>
<div>(XEN) r15: fffffffffffffff2 =A0 cr0: 000000008005003b =A0 cr4: 0000000=
0000026f0</div><div>(XEN) cr3: 0000000139ee4000 =A0 cr2: 0000000000000060</=
div><div>(XEN) ds: 0000 =A0 es: 0000 =A0 fs: 0000 =A0 gs: 0000 =A0 ss: e010=
 =A0 cs: e008</div>
<div>(XEN) Xen stack trace from rsp=3Dffff82c48029fdf8:</div><div>(XEN) =A0=
 =A0ffff8300bd2fe000 ffff82c48029ff18 ffff880037481d40 ffff880039762da0</di=
v><div>(XEN) =A0 =A00000000000000001 ffff82c480157df4 0000000000000070 ffff=
82f6016db300</div>
<div>(XEN) =A0 =A000000000000b6d98 ffff8301355d8000 0000000000000070 ffff82=
c4801702ab</div><div>(XEN) =A0 =A0ffff88003fc8bd80 0000000000000000 0000000=
000000020 ffff8300bd2fe000</div><div>(XEN) =A0 =A0ffff8301355d8000 ffff8800=
37481d40 ffff880039762da0 0000000000000001</div>
<div>(XEN) =A0 =A00000000000000003 ffff82c4801058df ffff82c48029ff18 ffff82=
c48011462e</div><div>(XEN) =A0 =A00000000000000000 0000000000000000 0000000=
400000004 ffff82c48029ff18</div><div>(XEN) =A0 =A00000000000000010 ffff8300=
bd6a0000 ffff8800374819a8 ffff8300bd6a0000</div>
<div>(XEN) =A0 =A0ffff880037481d48 0000000000000001 ffff880039762da0 ffff82=
c480214288</div><div>(XEN) =A0 =A00000000000000003 0000000000000001 ffff880=
039762da0 0000000000000001</div><div>(XEN) =A0 =A0ffff880037481d48 00000000=
00000001 0000000000000282 ffff880002dc4240</div>
<div>(XEN) =A0 =A000000000000001c0 00000000000001c0 0000000000000018 ffffff=
ff8100130a</div><div>(XEN) =A0 =A0ffff880037481d40 0000000000000001 0000000=
000000005 0000010000000000</div><div>(XEN) =A0 =A0ffffffff8100130a 00000000=
0000e033 0000000000000282 ffff880037481d20</div>
<div>(XEN) =A0 =A0000000000000e02b 0000000000000000 0000000000000000 000000=
0000000000</div><div>(XEN) =A0 =A00000000000000000 0000000000000000 ffff830=
0bd6a0000 0000000000000000</div><div>(XEN) =A0 =A00000000000000000</div><di=
v>(XEN) Xen call trace:</div>
<div>(XEN) =A0 =A0[&lt;ffff82c480120585&gt;] vcpu_runstate_get+0xe5/0x130</=
div><div>(XEN) =A0 =A0[&lt;ffff82c480157df4&gt;] arch_do_vcpu_op+0x134/0x5d=
0</div><div>(XEN) =A0 =A0[&lt;ffff82c4801702ab&gt;] do_update_descriptor+0x=
1db/0x220</div>
<div>(XEN) =A0 =A0[&lt;ffff82c4801058df&gt;] do_vcpu_op+0x6f/0x4a0</div><di=
v>(XEN) =A0 =A0[&lt;ffff82c48011462e&gt;] do_multicall+0x13e/0x330</div><di=
v>(XEN) =A0 =A0[&lt;ffff82c480214288&gt;] syscall_enter+0x88/0x8d</div><div=
>(XEN) =A0 =A0</div>
<div>(XEN) Pagetable walk from 0000000000000060:</div><div>(XEN) =A0L4[0x00=
0] =3D 00000001004a5067 0000000000038c9d</div><div>(XEN) =A0L3[0x000] =3D 0=
00000013a703067 0000000000003094</div><div>(XEN) =A0L2[0x000] =3D 000000000=
0000000 ffffffffffffffff=A0</div>
<div>(XEN)=A0</div><div>(XEN) ****************************************</div=
><div>(XEN) Panic on CPU 0:</div><div>(XEN) FATAL PAGE FAULT</div><div>(XEN=
) [error_code=3D0000]</div><div>(XEN) Faulting linear address: 000000000000=
0060</div>
<div>(XEN) ****************************************</div><div>(XEN)=A0</div=
><div>(XEN) Reboot in five seconds...</div><div><br></div><br><div class=3D=
"gmail_quote">On Fri, Sep 7, 2012 at 12:06 PM, Ben Guthro <span dir=3D"ltr"=
>&lt;<a href=3D"mailto:ben@guthro.net" target=3D"_blank">ben@guthro.net</a>=
&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">I&#39;ll work on getting a JTAG, ICE, or som=
ething else - it is on an<br>
Intel SDP - so it should have the ports for it.<br>
<br>
My current suspicion on this is that the hardware registers are not<br>
being programmed the same way as they were in 4.0.x<br>
(Since the &quot;pulsing power button LED&quot; on the laptops, and the beh=
avior<br>
of the Desktop SDP are now similar)<br>
<br>
Once again - I don&#39;t have a lot of evidence to back this up - however,<=
br>
if I ifdef out the register writes that actually start the low level<br>
suspend - in<br>
xen/arch/x86/acpi/power.c =A0acpi_enter_sleep_state() - the rest of the<br>
suspend process completes as though the machine suspended, and then<br>
immediately resumed.<br>
<br>
In this case - the system seems to be functioning properly.<br>
<br>
<br>
<br>
<br>
<br>
Hack to prevent low level S3 attached.<br>
<div class=3D"HOEnZb"><div class=3D"h5"><br>
<br>
<br>
On Fri, Sep 7, 2012 at 8:18 AM, Jan Beulich &lt;<a href=3D"mailto:JBeulich@=
suse.com">JBeulich@suse.com</a>&gt; wrote:<br>
&gt;&gt;&gt;&gt; On 07.09.12 at 13:51, Ben Guthro &lt;<a href=3D"mailto:ben=
@guthro.net">ben@guthro.net</a>&gt; wrote:<br>
&gt;&gt; However, when I run with console=3Dnone, the observed behavior is =
very<br>
&gt;&gt; different.<br>
&gt;&gt; The system seems to go to sleep successfully - but when I press th=
e<br>
&gt;&gt; power button to wake it up - the power comes on - the fans spin up=
 -<br>
&gt;&gt; but the system is unresponsive.<br>
&gt;&gt; No video<br>
&gt;&gt; No network<br>
&gt;&gt; keyboard LEDs (Caps,Numlock) do not light up.<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; Alternate debugging strategies welcome.<br>
&gt;<br>
&gt; I&#39;m afraid other than being lucky to spot something via code<br>
&gt; inspection, the only alternative is an ITP/ICE. Maybe Intel folks<br>
&gt; could help out debugging this if it&#39;s reproducible for them.<br>
&gt;<br>
&gt; Jan<br>
&gt;<br>
</div></div></blockquote></div><br></div>

--485b397dcfb5c3325e04ca1463c1--


--===============8517680464768631549==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============8517680464768631549==--


From xen-devel-bounces@lists.xen.org Wed Sep 19 21:07:41 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Sep 2012 21:07:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TERUH-0006QU-Uj; Wed, 19 Sep 2012 21:07:13 +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 1TERUG-0006QP-GH
	for xen-devel@lists.xen.org; Wed, 19 Sep 2012 21:07:12 +0000
Received: from [85.158.143.99:12851] by server-3.bemta-4.messagelabs.com id
	D6/68-10986-FF33A505; Wed, 19 Sep 2012 21:07:11 +0000
X-Env-Sender: ben.guthro@gmail.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1348088829!21243482!1
X-Originating-IP: [209.85.223.173]
X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_20_30,HTML_MESSAGE,
	RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24427 invoked from network); 19 Sep 2012 21:07:10 -0000
Received: from mail-ie0-f173.google.com (HELO mail-ie0-f173.google.com)
	(209.85.223.173)
	by server-8.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Sep 2012 21:07:10 -0000
Received: by iebc10 with SMTP id c10so2866717ieb.32
	for <xen-devel@lists.xen.org>; Wed, 19 Sep 2012 14: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;
	bh=AF3Fevwe2h/vN4WxT+5WjLSDJzldioLT+ybQuCTeuik=;
	b=VjrmfMOXCqZiQlYbacjjkrmiuxWHxzOf0biaai89VFSPlbzcDb0nBQ1+bPoa2CNKM4
	rOorHhfou5Xf04lzJ30nZebK24LbidHeLtnWhX+l5PXaPbc99IX+G0iT4cLW3N6PfpYW
	sbxiuNmhGm4MDGf8L6Up8qEyG9d3QG0TM9FyjHHBsWFv1q+KXKgFt3pz2axIrdm1LOW+
	9mpgrXWHRkfMKamOD8iz0slIa8ZlHSH1Uz4izoY53C2hyo8bd34GPIYWPrBazheO+wOm
	v7ZNSLhhqBkNbMV2YWovIyUtArD/QRickeSbxwdxtclw9LTxQcnAauvpxK8EVoFSOkKw
	w67w==
MIME-Version: 1.0
Received: by 10.42.110.130 with SMTP id q2mr546434icp.53.1348088828735; Wed,
	19 Sep 2012 14:07:08 -0700 (PDT)
Received: by 10.64.55.132 with HTTP; Wed, 19 Sep 2012 14:07:08 -0700 (PDT)
In-Reply-To: <CAOvdn6XYjyYEgtrPskjCLK4BZWaPyriNGSVGzumdOP8-6=P_=Q@mail.gmail.com>
References: <CAOvdn6WwgBD-2yf1uu3m9-16=Tb5KUrybXf2KibtnxKbP7YtwA@mail.gmail.com>
	<CAOvdn6UBW-yTOMd3YSf5M9JiHLRivyaKL-qzcKG8epszqaKmGg@mail.gmail.com>
	<20120807163320.GC15053@phenom.dumpdata.com>
	<CAOvdn6XcRGKtJxGwJO8J+ZBJr89wfTLc1woW5rhtMM540H9h1w@mail.gmail.com>
	<CAOvdn6XUoSeGoo7X=AJ1kpDxZB9HZEv+TJ4v-=FHcyR4=CHK-w@mail.gmail.com>
	<502240F302000078000937A6@nat28.tlf.novell.com>
	<CAOvdn6WN3kxC8Bb9g6MpfLULu47EGSGCtajPc-SFeJ-8VSUQDQ@mail.gmail.com>
	<CAOvdn6Xk1inm1hU55i0phU2qvSWyJLNoyDdn43biBAY2OewPtw@mail.gmail.com>
	<5023F5400200007800093F4E@nat28.tlf.novell.com>
	<CAOvdn6U-f3C4U8xVPvDyRFkFFLkbfiCXg_n+9zgA9V5u+q5jfw@mail.gmail.com>
	<5023F8B80200007800093F8C@nat28.tlf.novell.com>
	<CAOvdn6XKHfete_+=Hkvt20G7_cJ-4i8+9j9YD30OxzQ16Ru-+g@mail.gmail.com>
	<5024CB720200007800094124@nat28.tlf.novell.com>
	<CAOvdn6VVJdhWVYa-gNVt3euE4AbGi1TijUCUd1wGzv0SCWEUYA@mail.gmail.com>
	<CAOvdn6USnG9Y4MNBhrDZmob0oJ8BgFfKTvFEhcKbXDxNmzfZ-Q@mail.gmail.com>
	<502B75BA0200007800094FD4@nat28.tlf.novell.com>
	<CAOvdn6Ww5oEj6Xg=XT4dWCYWUBuOdPqLz-CqNjz4HmCScE+==g@mail.gmail.com>
	<CAOvdn6Wsjds_dmZ0dwDTYmD-o-OqjBH5-b9mitAuUADE+A4_ag@mail.gmail.com>
	<502BB8FD02000078000951E0@nat28.tlf.novell.com>
	<CAOvdn6VD6bp13F-tvYdkBsj4hkhE7PTGZrapndtdHrDKeZqccg@mail.gmail.com>
	<502CCC0002000078000955C4@nat28.tlf.novell.com>
	<CAOvdn6VEuX7R2_wz74ZvCxMjC-=YUir9kP5sdxEVaKVspRUd_w@mail.gmail.com>
	<502CF0A8020000780009574E@nat28.tlf.novell.com>
	<CAOvdn6VsZvn_1TCWYeuyY5YuTcP8=miK2KwE4583nsj6Qjb_vg@mail.gmail.com>
	<504494FB0200007800098398@nat28.tlf.novell.com>
	<CAOvdn6UT13qvWbMyfZkWND03RoVKVSgb6wW4yqTUpuBYEX01Dg@mail.gmail.com>
	<5048958D02000078000993EB@nat28.tlf.novell.com>
	<CAOvdn6WrNK1Jn_Y_P7C3AwX6ApVcgzacLA_x-u=xBQtebnuPxA@mail.gmail.com>
	<CAOvdn6U_Z=KdEo56nqe7jN54BwiesRJqDOz_VzVNpkWGfFRd2A@mail.gmail.com>
	<5049CEAE0200007800099A33@nat28.tlf.novell.com>
	<CAOvdn6XmsEfs+aO7nqBHdA61HpT_n_8W95u0MMq5J21tZCFbzw@mail.gmail.com>
	<5049F37A0200007800099BDA@nat28.tlf.novell.com>
	<CAOvdn6W+=OYTH3xTWBxUB8f_2tuZYKPTo-eJG0jfkaJ2rVutCA@mail.gmail.com>
	<504A024E0200007800099C5A@nat28.tlf.novell.com>
	<CAOvdn6XYjyYEgtrPskjCLK4BZWaPyriNGSVGzumdOP8-6=P_=Q@mail.gmail.com>
Date: Wed, 19 Sep 2012 17:07:08 -0400
X-Google-Sender-Auth: EDVHUpPvRgy0xNhrCtMNn81Odk8
Message-ID: <CAOvdn6Xn1ZnontBO0KoJE9hgBsW-a1rR2EhWYEpgbbrELkXZNw@mail.gmail.com>
From: Ben Guthro <ben@guthro.net>
To: Jan Beulich <JBeulich@suse.com>
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>, john.baboval@citrix.com,
	Thomas Goetz <thomas.goetz@citrix.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen4.2 S3 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: multipart/mixed; boundary="===============8517680464768631549=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============8517680464768631549==
Content-Type: multipart/alternative; boundary=485b397dcfb5c3325e04ca1463c1

--485b397dcfb5c3325e04ca1463c1
Content-Type: text/plain; charset=ISO-8859-1

No hardware debugger just yet - but I've moved to another machine (Lenovo
T400 laptop) - and am now seeing the following stack trace when I resume
(this is using the tip of the 4.2-testing tree)

It looks like either the vcpu, or the runstate is NULL, at this point in
the resume process...


(XEN) Finishing wakeup from ACPI S3 state.
(XEN) Enabling non-boot CPUs  ...
(XEN) CPU#1 already initialized!
(XEN) Stuck ??
(XEN) Error taking CPU1 up: -5
[   38.570054] ACPI: Low-level resume complete
[   38.570054] PM: Restoring platform NVS memory
[   38.570054] Enabling non-boot CPUs ...
(XEN) ----[ Xen-4.2.1-pre  x86_64  debug=n  Tainted:    C ]----
(XEN) CPU:    0
(XEN) RIP:    e008:[<ffff82c480120585>] vcpu_runstate_get+0xe5/0x130
(XEN) RFLAGS: 0000000000010006   CONTEXT: hypervisor
(XEN) rax: 00007d3b7fd17180   rbx: ffff8300bd2fe000   rcx: 0000000000000000
(XEN) rdx: ffff08003fc8bd80   rsi: ffff82c48029fe28   rdi: ffff8300bd2fe000
(XEN) rbp: ffff82c48029fe28   rsp: ffff82c48029fdf8   r8:  0000000000000008
(XEN) r9:  00000000000001c0   r10: ffff82c48021f4a0   r11: 0000000000000282
(XEN) r12: ffff82c4802e8ee0   r13: ffff880039762da0   r14: ffff82c4802d3140
(XEN) r15: fffffffffffffff2   cr0: 000000008005003b   cr4: 00000000000026f0
(XEN) cr3: 0000000139ee4000   cr2: 0000000000000060
(XEN) ds: 0000   es: 0000   fs: 0000   gs: 0000   ss: e010   cs: e008
(XEN) Xen stack trace from rsp=ffff82c48029fdf8:
(XEN)    ffff8300bd2fe000 ffff82c48029ff18 ffff880037481d40 ffff880039762da0
(XEN)    0000000000000001 ffff82c480157df4 0000000000000070 ffff82f6016db300
(XEN)    00000000000b6d98 ffff8301355d8000 0000000000000070 ffff82c4801702ab
(XEN)    ffff88003fc8bd80 0000000000000000 0000000000000020 ffff8300bd2fe000
(XEN)    ffff8301355d8000 ffff880037481d40 ffff880039762da0 0000000000000001
(XEN)    0000000000000003 ffff82c4801058df ffff82c48029ff18 ffff82c48011462e
(XEN)    0000000000000000 0000000000000000 0000000400000004 ffff82c48029ff18
(XEN)    0000000000000010 ffff8300bd6a0000 ffff8800374819a8 ffff8300bd6a0000
(XEN)    ffff880037481d48 0000000000000001 ffff880039762da0 ffff82c480214288
(XEN)    0000000000000003 0000000000000001 ffff880039762da0 0000000000000001
(XEN)    ffff880037481d48 0000000000000001 0000000000000282 ffff880002dc4240
(XEN)    00000000000001c0 00000000000001c0 0000000000000018 ffffffff8100130a
(XEN)    ffff880037481d40 0000000000000001 0000000000000005 0000010000000000
(XEN)    ffffffff8100130a 000000000000e033 0000000000000282 ffff880037481d20
(XEN)    000000000000e02b 0000000000000000 0000000000000000 0000000000000000
(XEN)    0000000000000000 0000000000000000 ffff8300bd6a0000 0000000000000000
(XEN)    0000000000000000
(XEN) Xen call trace:
(XEN)    [<ffff82c480120585>] vcpu_runstate_get+0xe5/0x130
(XEN)    [<ffff82c480157df4>] arch_do_vcpu_op+0x134/0x5d0
(XEN)    [<ffff82c4801702ab>] do_update_descriptor+0x1db/0x220
(XEN)    [<ffff82c4801058df>] do_vcpu_op+0x6f/0x4a0
(XEN)    [<ffff82c48011462e>] do_multicall+0x13e/0x330
(XEN)    [<ffff82c480214288>] syscall_enter+0x88/0x8d
(XEN)
(XEN) Pagetable walk from 0000000000000060:
(XEN)  L4[0x000] = 00000001004a5067 0000000000038c9d
(XEN)  L3[0x000] = 000000013a703067 0000000000003094
(XEN)  L2[0x000] = 0000000000000000 ffffffffffffffff
(XEN)
(XEN) ****************************************
(XEN) Panic on CPU 0:
(XEN) FATAL PAGE FAULT
(XEN) [error_code=0000]
(XEN) Faulting linear address: 0000000000000060
(XEN) ****************************************
(XEN)
(XEN) Reboot in five seconds...


On Fri, Sep 7, 2012 at 12:06 PM, Ben Guthro <ben@guthro.net> wrote:

> I'll work on getting a JTAG, ICE, or something else - it is on an
> Intel SDP - so it should have the ports for it.
>
> My current suspicion on this is that the hardware registers are not
> being programmed the same way as they were in 4.0.x
> (Since the "pulsing power button LED" on the laptops, and the behavior
> of the Desktop SDP are now similar)
>
> Once again - I don't have a lot of evidence to back this up - however,
> if I ifdef out the register writes that actually start the low level
> suspend - in
> xen/arch/x86/acpi/power.c  acpi_enter_sleep_state() - the rest of the
> suspend process completes as though the machine suspended, and then
> immediately resumed.
>
> In this case - the system seems to be functioning properly.
>
>
>
>
>
> Hack to prevent low level S3 attached.
>
>
>
> On Fri, Sep 7, 2012 at 8:18 AM, Jan Beulich <JBeulich@suse.com> wrote:
> >>>> On 07.09.12 at 13:51, Ben Guthro <ben@guthro.net> wrote:
> >> However, when I run with console=none, the observed behavior is very
> >> different.
> >> The system seems to go to sleep successfully - but when I press the
> >> power button to wake it up - the power comes on - the fans spin up -
> >> but the system is unresponsive.
> >> No video
> >> No network
> >> keyboard LEDs (Caps,Numlock) do not light up.
> >>
> >>
> >> Alternate debugging strategies welcome.
> >
> > I'm afraid other than being lucky to spot something via code
> > inspection, the only alternative is an ITP/ICE. Maybe Intel folks
> > could help out debugging this if it's reproducible for them.
> >
> > Jan
> >
>

--485b397dcfb5c3325e04ca1463c1
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

No hardware debugger just yet - but I&#39;ve moved to another machine (Leno=
vo T400 laptop) - and am now seeing the following stack trace when I resume=
<div>(this is using the tip of the 4.2-testing tree)</div><div><br></div>
<div>It looks like either the vcpu, or the runstate is NULL, at this point =
in the resume process...</div><div><br></div><div><br></div><div><div>(XEN)=
 Finishing wakeup from ACPI S3 state.</div><div>(XEN) Enabling non-boot CPU=
s =A0...</div>
<div>(XEN) CPU#1 already initialized!</div><div>(XEN) Stuck ??</div><div>(X=
EN) Error taking CPU1 up: -5</div><div>[ =A0 38.570054] ACPI: Low-level res=
ume complete</div><div>[ =A0 38.570054] PM: Restoring platform NVS memory</=
div>
<div>[ =A0 38.570054] Enabling non-boot CPUs ...</div><div>(XEN) ----[ Xen-=
4.2.1-pre =A0x86_64 =A0debug=3Dn =A0Tainted: =A0 =A0C ]----</div><div>(XEN)=
 CPU: =A0 =A00</div><div>(XEN) RIP: =A0 =A0e008:[&lt;ffff82c480120585&gt;] =
vcpu_runstate_get+0xe5/0x130</div>
<div>(XEN) RFLAGS: 0000000000010006 =A0 CONTEXT: hypervisor</div><div>(XEN)=
 rax: 00007d3b7fd17180 =A0 rbx: ffff8300bd2fe000 =A0 rcx: 0000000000000000<=
/div><div>(XEN) rdx: ffff08003fc8bd80 =A0 rsi: ffff82c48029fe28 =A0 rdi: ff=
ff8300bd2fe000</div>
<div>(XEN) rbp: ffff82c48029fe28 =A0 rsp: ffff82c48029fdf8 =A0 r8: =A000000=
00000000008</div><div>(XEN) r9: =A000000000000001c0 =A0 r10: ffff82c48021f4=
a0 =A0 r11: 0000000000000282</div><div>(XEN) r12: ffff82c4802e8ee0 =A0 r13:=
 ffff880039762da0 =A0 r14: ffff82c4802d3140</div>
<div>(XEN) r15: fffffffffffffff2 =A0 cr0: 000000008005003b =A0 cr4: 0000000=
0000026f0</div><div>(XEN) cr3: 0000000139ee4000 =A0 cr2: 0000000000000060</=
div><div>(XEN) ds: 0000 =A0 es: 0000 =A0 fs: 0000 =A0 gs: 0000 =A0 ss: e010=
 =A0 cs: e008</div>
<div>(XEN) Xen stack trace from rsp=3Dffff82c48029fdf8:</div><div>(XEN) =A0=
 =A0ffff8300bd2fe000 ffff82c48029ff18 ffff880037481d40 ffff880039762da0</di=
v><div>(XEN) =A0 =A00000000000000001 ffff82c480157df4 0000000000000070 ffff=
82f6016db300</div>
<div>(XEN) =A0 =A000000000000b6d98 ffff8301355d8000 0000000000000070 ffff82=
c4801702ab</div><div>(XEN) =A0 =A0ffff88003fc8bd80 0000000000000000 0000000=
000000020 ffff8300bd2fe000</div><div>(XEN) =A0 =A0ffff8301355d8000 ffff8800=
37481d40 ffff880039762da0 0000000000000001</div>
<div>(XEN) =A0 =A00000000000000003 ffff82c4801058df ffff82c48029ff18 ffff82=
c48011462e</div><div>(XEN) =A0 =A00000000000000000 0000000000000000 0000000=
400000004 ffff82c48029ff18</div><div>(XEN) =A0 =A00000000000000010 ffff8300=
bd6a0000 ffff8800374819a8 ffff8300bd6a0000</div>
<div>(XEN) =A0 =A0ffff880037481d48 0000000000000001 ffff880039762da0 ffff82=
c480214288</div><div>(XEN) =A0 =A00000000000000003 0000000000000001 ffff880=
039762da0 0000000000000001</div><div>(XEN) =A0 =A0ffff880037481d48 00000000=
00000001 0000000000000282 ffff880002dc4240</div>
<div>(XEN) =A0 =A000000000000001c0 00000000000001c0 0000000000000018 ffffff=
ff8100130a</div><div>(XEN) =A0 =A0ffff880037481d40 0000000000000001 0000000=
000000005 0000010000000000</div><div>(XEN) =A0 =A0ffffffff8100130a 00000000=
0000e033 0000000000000282 ffff880037481d20</div>
<div>(XEN) =A0 =A0000000000000e02b 0000000000000000 0000000000000000 000000=
0000000000</div><div>(XEN) =A0 =A00000000000000000 0000000000000000 ffff830=
0bd6a0000 0000000000000000</div><div>(XEN) =A0 =A00000000000000000</div><di=
v>(XEN) Xen call trace:</div>
<div>(XEN) =A0 =A0[&lt;ffff82c480120585&gt;] vcpu_runstate_get+0xe5/0x130</=
div><div>(XEN) =A0 =A0[&lt;ffff82c480157df4&gt;] arch_do_vcpu_op+0x134/0x5d=
0</div><div>(XEN) =A0 =A0[&lt;ffff82c4801702ab&gt;] do_update_descriptor+0x=
1db/0x220</div>
<div>(XEN) =A0 =A0[&lt;ffff82c4801058df&gt;] do_vcpu_op+0x6f/0x4a0</div><di=
v>(XEN) =A0 =A0[&lt;ffff82c48011462e&gt;] do_multicall+0x13e/0x330</div><di=
v>(XEN) =A0 =A0[&lt;ffff82c480214288&gt;] syscall_enter+0x88/0x8d</div><div=
>(XEN) =A0 =A0</div>
<div>(XEN) Pagetable walk from 0000000000000060:</div><div>(XEN) =A0L4[0x00=
0] =3D 00000001004a5067 0000000000038c9d</div><div>(XEN) =A0L3[0x000] =3D 0=
00000013a703067 0000000000003094</div><div>(XEN) =A0L2[0x000] =3D 000000000=
0000000 ffffffffffffffff=A0</div>
<div>(XEN)=A0</div><div>(XEN) ****************************************</div=
><div>(XEN) Panic on CPU 0:</div><div>(XEN) FATAL PAGE FAULT</div><div>(XEN=
) [error_code=3D0000]</div><div>(XEN) Faulting linear address: 000000000000=
0060</div>
<div>(XEN) ****************************************</div><div>(XEN)=A0</div=
><div>(XEN) Reboot in five seconds...</div><div><br></div><br><div class=3D=
"gmail_quote">On Fri, Sep 7, 2012 at 12:06 PM, Ben Guthro <span dir=3D"ltr"=
>&lt;<a href=3D"mailto:ben@guthro.net" target=3D"_blank">ben@guthro.net</a>=
&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">I&#39;ll work on getting a JTAG, ICE, or som=
ething else - it is on an<br>
Intel SDP - so it should have the ports for it.<br>
<br>
My current suspicion on this is that the hardware registers are not<br>
being programmed the same way as they were in 4.0.x<br>
(Since the &quot;pulsing power button LED&quot; on the laptops, and the beh=
avior<br>
of the Desktop SDP are now similar)<br>
<br>
Once again - I don&#39;t have a lot of evidence to back this up - however,<=
br>
if I ifdef out the register writes that actually start the low level<br>
suspend - in<br>
xen/arch/x86/acpi/power.c =A0acpi_enter_sleep_state() - the rest of the<br>
suspend process completes as though the machine suspended, and then<br>
immediately resumed.<br>
<br>
In this case - the system seems to be functioning properly.<br>
<br>
<br>
<br>
<br>
<br>
Hack to prevent low level S3 attached.<br>
<div class=3D"HOEnZb"><div class=3D"h5"><br>
<br>
<br>
On Fri, Sep 7, 2012 at 8:18 AM, Jan Beulich &lt;<a href=3D"mailto:JBeulich@=
suse.com">JBeulich@suse.com</a>&gt; wrote:<br>
&gt;&gt;&gt;&gt; On 07.09.12 at 13:51, Ben Guthro &lt;<a href=3D"mailto:ben=
@guthro.net">ben@guthro.net</a>&gt; wrote:<br>
&gt;&gt; However, when I run with console=3Dnone, the observed behavior is =
very<br>
&gt;&gt; different.<br>
&gt;&gt; The system seems to go to sleep successfully - but when I press th=
e<br>
&gt;&gt; power button to wake it up - the power comes on - the fans spin up=
 -<br>
&gt;&gt; but the system is unresponsive.<br>
&gt;&gt; No video<br>
&gt;&gt; No network<br>
&gt;&gt; keyboard LEDs (Caps,Numlock) do not light up.<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; Alternate debugging strategies welcome.<br>
&gt;<br>
&gt; I&#39;m afraid other than being lucky to spot something via code<br>
&gt; inspection, the only alternative is an ITP/ICE. Maybe Intel folks<br>
&gt; could help out debugging this if it&#39;s reproducible for them.<br>
&gt;<br>
&gt; Jan<br>
&gt;<br>
</div></div></blockquote></div><br></div>

--485b397dcfb5c3325e04ca1463c1--


--===============8517680464768631549==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============8517680464768631549==--


From xen-devel-bounces@lists.xen.org Wed Sep 19 21:22:37 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Sep 2012 21:22:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TERih-0006cP-Jr; Wed, 19 Sep 2012 21:22:07 +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 1TERif-0006cK-MU
	for xen-devel@lists.xen.org; Wed, 19 Sep 2012 21:22:05 +0000
Received: from [85.158.139.211:41845] by server-3.bemta-5.messagelabs.com id
	51/CB-21836-C773A505; Wed, 19 Sep 2012 21:22:04 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-10.tower-206.messagelabs.com!1348089722!19196251!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzUwOTQ4\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8084 invoked from network); 19 Sep 2012 21:22:04 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-10.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 19 Sep 2012 21:22:04 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q8JLLu5Q020761
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 19 Sep 2012 21:21:56 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
	q8JLLsAb019658
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 19 Sep 2012 21:21:55 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
	q8JLLsT8018273; Wed, 19 Sep 2012 16:21:54 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 19 Sep 2012 14:21:54 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id C50DE402EC; Wed, 19 Sep 2012 17:11:03 -0400 (EDT)
Date: Wed, 19 Sep 2012 17:11:03 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: "Duan, Ronghui" <ronghui.duan@intel.com>
Message-ID: <20120919211103.GA9488@phenom.dumpdata.com>
References: <A21691DE07B84740B5F0B81466D5148A23BCF1DF@SHSMSX102.ccr.corp.intel.com>
	<20120907174922.GA13040@phenom.dumpdata.com>
	<A21691DE07B84740B5F0B81466D5148A23BF6833@SHSMSX102.ccr.corp.intel.com>
	<5051A83B020000780009AF93@nat28.tlf.novell.com>
	<alpine.DEB.2.02.1209131203270.15568@kaball.uk.xensource.com>
	<20120913132335.GD16635@localhost.localdomain>
	<A21691DE07B84740B5F0B81466D5148A23BF6C1D@SHSMSX102.ccr.corp.intel.com>
	<A21691DE07B84740B5F0B81466D5148A23BF7E2F@SHSMSX102.ccr.corp.intel.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <A21691DE07B84740B5F0B81466D5148A23BF7E2F@SHSMSX102.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.xen.org'" <xen-devel@lists.xen.org>,
	'Ian Jackson' <Ian.Jackson@eu.citrix.com>,
	'Jan Beulich' <JBeulich@suse.com>,
	'Stefano Stabellini' <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [RFC v1 0/5] VBD: enlarge max segment per request
 in blkfront
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Sep 17, 2012 at 06:33:29AM +0000, Duan, Ronghui wrote:
> At last, I saw the regression in random io.
> This is a patch to fix the performance regression. Original the pending request members are allocated from the stack, I alloc them when each request arrives in my last patch. But it will hurt performance. In this fix, I alloc all of them when blkback init. But due to some bugs there, we can't free it, the same to other pending requests member. I am looking for the reason. But have no idea for this now. 
> Konrad, thanks for your comments. Could you have a try when you have time.

Sure.  I get now:

  read : io=4096.0MB, bw=144258KB/s, iops=36064 , runt= 29075msec

so much better I/O.

> > > > > >> And with your patch got:
> > > > > >>   read : io=4096.0MB, bw=92606KB/s, iops=23151 , runt=
> > > > > >> 45292msec
> > > > > >>
> > > > > >> without:
> > > > > >>   read : io=4096.0MB, bw=145187KB/s, iops=36296 , runt=
> > > > > >> 28889msec

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 19 21:22:37 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Sep 2012 21:22:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TERih-0006cP-Jr; Wed, 19 Sep 2012 21:22:07 +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 1TERif-0006cK-MU
	for xen-devel@lists.xen.org; Wed, 19 Sep 2012 21:22:05 +0000
Received: from [85.158.139.211:41845] by server-3.bemta-5.messagelabs.com id
	51/CB-21836-C773A505; Wed, 19 Sep 2012 21:22:04 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-10.tower-206.messagelabs.com!1348089722!19196251!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzUwOTQ4\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8084 invoked from network); 19 Sep 2012 21:22:04 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-10.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 19 Sep 2012 21:22:04 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q8JLLu5Q020761
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 19 Sep 2012 21:21:56 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
	q8JLLsAb019658
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 19 Sep 2012 21:21:55 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
	q8JLLsT8018273; Wed, 19 Sep 2012 16:21:54 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 19 Sep 2012 14:21:54 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id C50DE402EC; Wed, 19 Sep 2012 17:11:03 -0400 (EDT)
Date: Wed, 19 Sep 2012 17:11:03 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: "Duan, Ronghui" <ronghui.duan@intel.com>
Message-ID: <20120919211103.GA9488@phenom.dumpdata.com>
References: <A21691DE07B84740B5F0B81466D5148A23BCF1DF@SHSMSX102.ccr.corp.intel.com>
	<20120907174922.GA13040@phenom.dumpdata.com>
	<A21691DE07B84740B5F0B81466D5148A23BF6833@SHSMSX102.ccr.corp.intel.com>
	<5051A83B020000780009AF93@nat28.tlf.novell.com>
	<alpine.DEB.2.02.1209131203270.15568@kaball.uk.xensource.com>
	<20120913132335.GD16635@localhost.localdomain>
	<A21691DE07B84740B5F0B81466D5148A23BF6C1D@SHSMSX102.ccr.corp.intel.com>
	<A21691DE07B84740B5F0B81466D5148A23BF7E2F@SHSMSX102.ccr.corp.intel.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <A21691DE07B84740B5F0B81466D5148A23BF7E2F@SHSMSX102.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.xen.org'" <xen-devel@lists.xen.org>,
	'Ian Jackson' <Ian.Jackson@eu.citrix.com>,
	'Jan Beulich' <JBeulich@suse.com>,
	'Stefano Stabellini' <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [RFC v1 0/5] VBD: enlarge max segment per request
 in blkfront
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Sep 17, 2012 at 06:33:29AM +0000, Duan, Ronghui wrote:
> At last, I saw the regression in random io.
> This is a patch to fix the performance regression. Original the pending request members are allocated from the stack, I alloc them when each request arrives in my last patch. But it will hurt performance. In this fix, I alloc all of them when blkback init. But due to some bugs there, we can't free it, the same to other pending requests member. I am looking for the reason. But have no idea for this now. 
> Konrad, thanks for your comments. Could you have a try when you have time.

Sure.  I get now:

  read : io=4096.0MB, bw=144258KB/s, iops=36064 , runt= 29075msec

so much better I/O.

> > > > > >> And with your patch got:
> > > > > >>   read : io=4096.0MB, bw=92606KB/s, iops=23151 , runt=
> > > > > >> 45292msec
> > > > > >>
> > > > > >> without:
> > > > > >>   read : io=4096.0MB, bw=145187KB/s, iops=36296 , runt=
> > > > > >> 28889msec

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 19 22:14:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Sep 2012 22: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 1TESWR-0006xL-Lo; Wed, 19 Sep 2012 22:13:31 +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 1TESWQ-0006xG-QN
	for Xen-devel@lists.xensource.com; Wed, 19 Sep 2012 22:13:31 +0000
Received: from [85.158.143.99:19292] by server-3.bemta-4.messagelabs.com id
	D5/81-10986-A834A505; Wed, 19 Sep 2012 22:13:30 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1348092808!30693920!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDc2MjE4Mg==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21140 invoked from network); 19 Sep 2012 22:13:29 -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; 19 Sep 2012 22:13:29 -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 q8JMDLVe002958
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 19 Sep 2012 22:13:22 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
	q8JMDLag007695
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 19 Sep 2012 22:13:21 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
	q8JMDKhs013528; Wed, 19 Sep 2012 17:13:20 -0500
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 19 Sep 2012 15:13:20 -0700
Date: Wed, 19 Sep 2012 15:13:19 -0700
From: Mukesh Rathor <mukesh.rathor@oracle.com>
To: Mukesh Rathor <mukesh.rathor@oracle.com>
Message-ID: <20120919151319.2fbea71c@mantra.us.oracle.com>
In-Reply-To: <20120919122907.1e72704b@mantra.us.oracle.com>
References: <20120919122907.1e72704b@mantra.us.oracle.com>
Organization: Oracle Corporation
X-Mailer: Claws Mail 3.7.6 (GTK+ 2.18.9; x86_64-redhat-linux-gnu)
Mime-Version: 1.0
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: "Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"stefano.stabellini@eu.citrix.com" <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] PVH: iopl
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 19 Sep 2012 12:29:07 -0700
Mukesh Rathor <mukesh.rathor@oracle.com> wrote:

> 
> I noticed anamoly in my code the way IOPL is set. For vcpu 0, its done
> via
> 
>         set_iopl.iopl = 1;
> 	rc = HYPERVISOR_physdev_op(PHYSDEVOP_set_iopl, &set_iopl);
> 
> in xen_start_kernel() in enlighten.c. But, for non boot vcpus, its
> done via eflags in cpu_initialize_context():
>         ctxt->user_regs.eflags = 0x1000; /* IOPL_RING1 */
> 
> Since I am running in HVM container, IO ops cause vmexit. I can just
> check eflags at that point for guest IOPL. So I am thinking of just
> using eflags and not doing the hcall.  It will also reduce the need
> for another field in the struct pv_vcpu for me. 
> 
> (JFYI: EXIT_REASON_IO_INSTRUCTION cause emulate_privileged_op() to be
> called).

So, I got rid of calling hcall to set iopl. The guest just manages
via eflags. Then upon vmexit:

{
    int curr_lvl;
    int requested = (regs->rflags >> 12) & 3;
    read_vmcs_selectors(regs);
    curr_lvl = regs->cs & 3;

    if (requested >= curr_lvl && emulate_privileged_op(regs))
        return success;

    hvm_inject_hw_exception(TRAP_gp_fault, regs->error_code);
}

I tested it out, and seems fine.

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 Sep 19 22:14:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Sep 2012 22: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 1TESWR-0006xL-Lo; Wed, 19 Sep 2012 22:13:31 +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 1TESWQ-0006xG-QN
	for Xen-devel@lists.xensource.com; Wed, 19 Sep 2012 22:13:31 +0000
Received: from [85.158.143.99:19292] by server-3.bemta-4.messagelabs.com id
	D5/81-10986-A834A505; Wed, 19 Sep 2012 22:13:30 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1348092808!30693920!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDc2MjE4Mg==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21140 invoked from network); 19 Sep 2012 22:13:29 -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; 19 Sep 2012 22:13:29 -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 q8JMDLVe002958
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 19 Sep 2012 22:13:22 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
	q8JMDLag007695
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 19 Sep 2012 22:13:21 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
	q8JMDKhs013528; Wed, 19 Sep 2012 17:13:20 -0500
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 19 Sep 2012 15:13:20 -0700
Date: Wed, 19 Sep 2012 15:13:19 -0700
From: Mukesh Rathor <mukesh.rathor@oracle.com>
To: Mukesh Rathor <mukesh.rathor@oracle.com>
Message-ID: <20120919151319.2fbea71c@mantra.us.oracle.com>
In-Reply-To: <20120919122907.1e72704b@mantra.us.oracle.com>
References: <20120919122907.1e72704b@mantra.us.oracle.com>
Organization: Oracle Corporation
X-Mailer: Claws Mail 3.7.6 (GTK+ 2.18.9; x86_64-redhat-linux-gnu)
Mime-Version: 1.0
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: "Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"stefano.stabellini@eu.citrix.com" <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] PVH: iopl
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 19 Sep 2012 12:29:07 -0700
Mukesh Rathor <mukesh.rathor@oracle.com> wrote:

> 
> I noticed anamoly in my code the way IOPL is set. For vcpu 0, its done
> via
> 
>         set_iopl.iopl = 1;
> 	rc = HYPERVISOR_physdev_op(PHYSDEVOP_set_iopl, &set_iopl);
> 
> in xen_start_kernel() in enlighten.c. But, for non boot vcpus, its
> done via eflags in cpu_initialize_context():
>         ctxt->user_regs.eflags = 0x1000; /* IOPL_RING1 */
> 
> Since I am running in HVM container, IO ops cause vmexit. I can just
> check eflags at that point for guest IOPL. So I am thinking of just
> using eflags and not doing the hcall.  It will also reduce the need
> for another field in the struct pv_vcpu for me. 
> 
> (JFYI: EXIT_REASON_IO_INSTRUCTION cause emulate_privileged_op() to be
> called).

So, I got rid of calling hcall to set iopl. The guest just manages
via eflags. Then upon vmexit:

{
    int curr_lvl;
    int requested = (regs->rflags >> 12) & 3;
    read_vmcs_selectors(regs);
    curr_lvl = regs->cs & 3;

    if (requested >= curr_lvl && emulate_privileged_op(regs))
        return success;

    hvm_inject_hw_exception(TRAP_gp_fault, regs->error_code);
}

I tested it out, and seems fine.

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 Sep 19 23:30:41 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Sep 2012 23:30: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 1TETih-0007MJ-VI; Wed, 19 Sep 2012 23:30:15 +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 1TETig-0007ME-Cf
	for xen-devel@lists.xen.org; Wed, 19 Sep 2012 23:30:14 +0000
Received: from [85.158.139.83:31630] by server-11.bemta-5.messagelabs.com id
	78/E2-24658-5855A505; Wed, 19 Sep 2012 23:30:13 +0000
X-Env-Sender: yang.z.zhang@intel.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1348097411!30947392!1
X-Originating-IP: [134.134.136.20]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjAgPT4gMzAwNjUx\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18018 invoked from network); 19 Sep 2012 23:30:12 -0000
Received: from mga02.intel.com (HELO mga02.intel.com) (134.134.136.20)
	by server-5.tower-182.messagelabs.com with SMTP;
	19 Sep 2012 23:30:12 -0000
Received: from orsmga001.jf.intel.com ([10.7.209.18])
	by orsmga101.jf.intel.com with ESMTP; 19 Sep 2012 16:30:10 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.80,451,1344236400"; d="scan'208";a="195064226"
Received: from fmsmsx106.amr.corp.intel.com ([10.19.9.37])
	by orsmga001.jf.intel.com with ESMTP; 19 Sep 2012 16:30:10 -0700
Received: from fmsmsx153.amr.corp.intel.com (10.19.17.7) by
	FMSMSX106.amr.corp.intel.com (10.19.9.37) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Wed, 19 Sep 2012 16:30:09 -0700
Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by
	FMSMSX153.amr.corp.intel.com (10.19.17.7) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Wed, 19 Sep 2012 16:30:09 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.239]) by
	SHSMSX102.ccr.corp.intel.com ([169.254.2.92]) with mapi id
	14.01.0355.002; Thu, 20 Sep 2012 07:30:08 +0800
From: "Zhang, Yang Z" <yang.z.zhang@intel.com>
To: Anthony PERARD <anthony.perard@citrix.com>
Thread-Topic: [Xen-devel] error when pass through device to guest with
	qemu-xen-dir-remote
Thread-Index: AQHNlr6zlPZkXn4fdEaV9SzptFF4jw==
Date: Wed, 19 Sep 2012 23:30:06 +0000
Message-ID: <A9667DDFB95DB7438FA9D7D576C3D87E25F85A@SHSMSX101.ccr.corp.intel.com>
References: <A9667DDFB95DB7438FA9D7D576C3D87E203D54@SHSMSX101.ccr.corp.intel.com>
	<alpine.DEB.2.02.1208031122170.4645@kaball.uk.xensource.com>
	<1343990187.21372.48.camel@zakaz.uk.xensource.com>
	<40352EBA8B4DF841A9907B883F22B59B0FDBCE1E@SHSMSX102.ccr.corp.intel.com>
	<40352EBA8B4DF841A9907B883F22B59B0FDD25C7@SHSMSX102.ccr.corp.intel.com>
	<A9667DDFB95DB7438FA9D7D576C3D87E258EF6@SHSMSX101.ccr.corp.intel.com>
	<505851CF.2090000@citrix.com>
	<A9667DDFB95DB7438FA9D7D576C3D87E25BB14@SHSMSX101.ccr.corp.intel.com>
	<CAJJyHjLH38r-r+cTmPprMj4trU8eZpQrfp4ypBzdsmZHSL9BMw@mail.gmail.com>
In-Reply-To: <CAJJyHjLH38r-r+cTmPprMj4trU8eZpQrfp4ypBzdsmZHSL9BMw@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: Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>, "Shan,
	Haitao" <haitao.shan@intel.com>, "Zhou,
	Chao" <chao.zhou@intel.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] error when pass through device to guest with
 qemu-xen-dir-remote
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 wrote on 2012-09-19:
> On Wed, Sep 19, 2012 at 1:06 AM, Zhang, Yang Z <yang.z.zhang@intel.com>
> wrote:
>> Anthony PERARD wrote on 2012-09-18:
>>> 
>>> Hi,
>>> 
>>> So, we'll have to add a check in the unplug code of qemu to ignore
>>> passthrough devices.
>>> 
>>> Here is a patches, I did not test it.
>>> 
>>> diff --git a/hw/xen_platform.c b/hw/xen_platform.c
>>> index 0d6c2ff..2d3978e 100644
>>> --- a/hw/xen_platform.c
>>> +++ b/hw/xen_platform.c
>>> @@ -85,8 +85,10 @@ static void log_writeb ...
>>> 
>>>   static void unplug_nic(PCIBus *b, PCIDevice *d, void *o)
>>>   {
>>> +    /* We have to ignore passthrough devices */
>>>       if (pci_get_word(d->config + PCI_CLASS_DEVICE) ==
>>> -            PCI_CLASS_NETWORK_ETHERNET) {
>>> +            PCI_CLASS_NETWORK_ETHERNET
>>> +        && strcmp(d->name, "xen-pci-passthrough") != 0) {
>>>           qdev_free(&d->qdev);
>>>       }
>>>   }
>> 
>> In old qemu, we will free the invalid NIC through this function. And it will fail w/
> your change. Shouldn't we follow the old logic?
> 
> I don't understand. Are you arguing this patch or the function it self?
> 
> My change is fine and follow the old logic: do not do anything for a
> passthrough device.
No. Old logic will unplug the passthrough device which mask as invalid. And this patch just ignores all passthrough device.
I wonder whether this change will impact other part? If not, it should be ok.

> I now have tested the change, and QEMU work as espected, it will
> unplug the emulated NIC, and ignore any passthrough devices. So the
> guest can the passthroughed NIC.
> 
> Thanks,
> 
> --
> Anthony PERARD


Best regards,
Yang


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 19 23:30:41 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Sep 2012 23:30: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 1TETih-0007MJ-VI; Wed, 19 Sep 2012 23:30:15 +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 1TETig-0007ME-Cf
	for xen-devel@lists.xen.org; Wed, 19 Sep 2012 23:30:14 +0000
Received: from [85.158.139.83:31630] by server-11.bemta-5.messagelabs.com id
	78/E2-24658-5855A505; Wed, 19 Sep 2012 23:30:13 +0000
X-Env-Sender: yang.z.zhang@intel.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1348097411!30947392!1
X-Originating-IP: [134.134.136.20]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjAgPT4gMzAwNjUx\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18018 invoked from network); 19 Sep 2012 23:30:12 -0000
Received: from mga02.intel.com (HELO mga02.intel.com) (134.134.136.20)
	by server-5.tower-182.messagelabs.com with SMTP;
	19 Sep 2012 23:30:12 -0000
Received: from orsmga001.jf.intel.com ([10.7.209.18])
	by orsmga101.jf.intel.com with ESMTP; 19 Sep 2012 16:30:10 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.80,451,1344236400"; d="scan'208";a="195064226"
Received: from fmsmsx106.amr.corp.intel.com ([10.19.9.37])
	by orsmga001.jf.intel.com with ESMTP; 19 Sep 2012 16:30:10 -0700
Received: from fmsmsx153.amr.corp.intel.com (10.19.17.7) by
	FMSMSX106.amr.corp.intel.com (10.19.9.37) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Wed, 19 Sep 2012 16:30:09 -0700
Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by
	FMSMSX153.amr.corp.intel.com (10.19.17.7) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Wed, 19 Sep 2012 16:30:09 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.239]) by
	SHSMSX102.ccr.corp.intel.com ([169.254.2.92]) with mapi id
	14.01.0355.002; Thu, 20 Sep 2012 07:30:08 +0800
From: "Zhang, Yang Z" <yang.z.zhang@intel.com>
To: Anthony PERARD <anthony.perard@citrix.com>
Thread-Topic: [Xen-devel] error when pass through device to guest with
	qemu-xen-dir-remote
Thread-Index: AQHNlr6zlPZkXn4fdEaV9SzptFF4jw==
Date: Wed, 19 Sep 2012 23:30:06 +0000
Message-ID: <A9667DDFB95DB7438FA9D7D576C3D87E25F85A@SHSMSX101.ccr.corp.intel.com>
References: <A9667DDFB95DB7438FA9D7D576C3D87E203D54@SHSMSX101.ccr.corp.intel.com>
	<alpine.DEB.2.02.1208031122170.4645@kaball.uk.xensource.com>
	<1343990187.21372.48.camel@zakaz.uk.xensource.com>
	<40352EBA8B4DF841A9907B883F22B59B0FDBCE1E@SHSMSX102.ccr.corp.intel.com>
	<40352EBA8B4DF841A9907B883F22B59B0FDD25C7@SHSMSX102.ccr.corp.intel.com>
	<A9667DDFB95DB7438FA9D7D576C3D87E258EF6@SHSMSX101.ccr.corp.intel.com>
	<505851CF.2090000@citrix.com>
	<A9667DDFB95DB7438FA9D7D576C3D87E25BB14@SHSMSX101.ccr.corp.intel.com>
	<CAJJyHjLH38r-r+cTmPprMj4trU8eZpQrfp4ypBzdsmZHSL9BMw@mail.gmail.com>
In-Reply-To: <CAJJyHjLH38r-r+cTmPprMj4trU8eZpQrfp4ypBzdsmZHSL9BMw@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: Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>, "Shan,
	Haitao" <haitao.shan@intel.com>, "Zhou,
	Chao" <chao.zhou@intel.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] error when pass through device to guest with
 qemu-xen-dir-remote
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 wrote on 2012-09-19:
> On Wed, Sep 19, 2012 at 1:06 AM, Zhang, Yang Z <yang.z.zhang@intel.com>
> wrote:
>> Anthony PERARD wrote on 2012-09-18:
>>> 
>>> Hi,
>>> 
>>> So, we'll have to add a check in the unplug code of qemu to ignore
>>> passthrough devices.
>>> 
>>> Here is a patches, I did not test it.
>>> 
>>> diff --git a/hw/xen_platform.c b/hw/xen_platform.c
>>> index 0d6c2ff..2d3978e 100644
>>> --- a/hw/xen_platform.c
>>> +++ b/hw/xen_platform.c
>>> @@ -85,8 +85,10 @@ static void log_writeb ...
>>> 
>>>   static void unplug_nic(PCIBus *b, PCIDevice *d, void *o)
>>>   {
>>> +    /* We have to ignore passthrough devices */
>>>       if (pci_get_word(d->config + PCI_CLASS_DEVICE) ==
>>> -            PCI_CLASS_NETWORK_ETHERNET) {
>>> +            PCI_CLASS_NETWORK_ETHERNET
>>> +        && strcmp(d->name, "xen-pci-passthrough") != 0) {
>>>           qdev_free(&d->qdev);
>>>       }
>>>   }
>> 
>> In old qemu, we will free the invalid NIC through this function. And it will fail w/
> your change. Shouldn't we follow the old logic?
> 
> I don't understand. Are you arguing this patch or the function it self?
> 
> My change is fine and follow the old logic: do not do anything for a
> passthrough device.
No. Old logic will unplug the passthrough device which mask as invalid. And this patch just ignores all passthrough device.
I wonder whether this change will impact other part? If not, it should be ok.

> I now have tested the change, and QEMU work as espected, it will
> unplug the emulated NIC, and ignore any passthrough devices. So the
> guest can the passthroughed NIC.
> 
> Thanks,
> 
> --
> Anthony PERARD


Best regards,
Yang


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 19 23:38:17 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Sep 2012 23:38:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TETpz-0007Xb-Su; Wed, 19 Sep 2012 23:37: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 1TETpy-0007XT-4B
	for xen-devel@lists.xensource.com; Wed, 19 Sep 2012 23:37:46 +0000
Received: from [85.158.138.51:18193] by server-10.bemta-3.messagelabs.com id
	72/6C-10411-9475A505; Wed, 19 Sep 2012 23:37:45 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1348097864!29456818!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTAxNzU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19260 invoked from network); 19 Sep 2012 23:37:44 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Sep 2012 23:37:44 -0000
X-IronPort-AV: E=Sophos;i="4.80,452,1344211200"; d="scan'208";a="14642998"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Sep 2012 23:37: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.279.1; Thu, 20 Sep 2012 00:37: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 1TETpv-0001Mf-79;
	Wed, 19 Sep 2012 23:37:43 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1TETpu-0000rP-Vl;
	Thu, 20 Sep 2012 00:37:43 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-13816-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 20 Sep 2012 00:37:43 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13816: 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 13816 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13816/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore            fail   like 13812
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail like 13812
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail like 13812

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  fee83ac77d8c
baseline version:
 xen                  7b045d43e59d

------------------------------------------------------------
People who touched revisions under test:
  Dan Magenheimer <dan.magenheimer@oracle.com>
  Jan Beulich <jbeulich@suse.com>
  Keir Fraser <keir@xen.org>
  Zhenzhong Duan <zhenzhong.duan@oracle.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-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-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-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-amd64-amd64-xl-win                                      fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=xen-unstable
+ revision=fee83ac77d8c
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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 fee83ac77d8c
+ branch=xen-unstable
+ revision=fee83ac77d8c
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-unstable
+ '[' xxen = xlinux ']'
+ linuxbranch=linux
+ : master
+ : tested/2.6.39.x
+ . ap-common
++ : xen@xenbits.xensource.com
++ : http://xenbits.xen.org/hg/staging/xen-unstable.hg
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : xen@xenbits.xensource.com:git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.xen-unstable
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-unstable.git
++ : daily-cron.xen-unstable
+ TREE_LINUX=xen@xenbits.xensource.com:git/linux-pvops.git
+ TREE_QEMU_UPSTREAM=xen@xenbits.xensource.com:git/qemu-upstream-unstable.git
+ info_linux_tree xen-unstable
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/xen-unstable.hg
+ hg push -r fee83ac77d8c 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 Wed Sep 19 23:38:17 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Sep 2012 23:38:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TETpz-0007Xb-Su; Wed, 19 Sep 2012 23:37: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 1TETpy-0007XT-4B
	for xen-devel@lists.xensource.com; Wed, 19 Sep 2012 23:37:46 +0000
Received: from [85.158.138.51:18193] by server-10.bemta-3.messagelabs.com id
	72/6C-10411-9475A505; Wed, 19 Sep 2012 23:37:45 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1348097864!29456818!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTAxNzU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19260 invoked from network); 19 Sep 2012 23:37:44 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Sep 2012 23:37:44 -0000
X-IronPort-AV: E=Sophos;i="4.80,452,1344211200"; d="scan'208";a="14642998"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Sep 2012 23:37: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.279.1; Thu, 20 Sep 2012 00:37: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 1TETpv-0001Mf-79;
	Wed, 19 Sep 2012 23:37:43 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1TETpu-0000rP-Vl;
	Thu, 20 Sep 2012 00:37:43 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-13816-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 20 Sep 2012 00:37:43 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13816: 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 13816 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13816/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore            fail   like 13812
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail like 13812
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail like 13812

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  fee83ac77d8c
baseline version:
 xen                  7b045d43e59d

------------------------------------------------------------
People who touched revisions under test:
  Dan Magenheimer <dan.magenheimer@oracle.com>
  Jan Beulich <jbeulich@suse.com>
  Keir Fraser <keir@xen.org>
  Zhenzhong Duan <zhenzhong.duan@oracle.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-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-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-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-amd64-amd64-xl-win                                      fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=xen-unstable
+ revision=fee83ac77d8c
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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 fee83ac77d8c
+ branch=xen-unstable
+ revision=fee83ac77d8c
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-unstable
+ '[' xxen = xlinux ']'
+ linuxbranch=linux
+ : master
+ : tested/2.6.39.x
+ . ap-common
++ : xen@xenbits.xensource.com
++ : http://xenbits.xen.org/hg/staging/xen-unstable.hg
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : xen@xenbits.xensource.com:git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.xen-unstable
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-unstable.git
++ : daily-cron.xen-unstable
+ TREE_LINUX=xen@xenbits.xensource.com:git/linux-pvops.git
+ TREE_QEMU_UPSTREAM=xen@xenbits.xensource.com:git/qemu-upstream-unstable.git
+ info_linux_tree xen-unstable
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/xen-unstable.hg
+ hg push -r fee83ac77d8c 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 Wed Sep 19 23:51:10 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Sep 2012 23: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 1TEU2Y-0007he-6H; Wed, 19 Sep 2012 23:50:46 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <attilio.rao@citrix.com>) id 1TEU2V-0007hZ-Tg
	for xen-devel@lists.xensource.com; Wed, 19 Sep 2012 23:50:44 +0000
Received: from [85.158.138.51:43462] by server-8.bemta-3.messagelabs.com id
	F8/FB-24700-35A5A505; Wed, 19 Sep 2012 23:50:43 +0000
X-Env-Sender: attilio.rao@citrix.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1348098642!22365803!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTAxNzU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12555 invoked from network); 19 Sep 2012 23:50:42 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Sep 2012 23:50:42 -0000
X-IronPort-AV: E=Sophos;i="4.80,452,1344211200"; d="scan'208";a="14643093"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Sep 2012 23:50:42 +0000
Received: from [10.80.3.221] (10.80.3.221) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Thu, 20 Sep 2012 00:50:42 +0100
Message-ID: <505A5A03.4000106@citrix.com>
Date: Thu, 20 Sep 2012 00:49:23 +0100
From: Attilio Rao <attilio.rao@citrix.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US;
	rv:1.9.1.16) Gecko/20111110 Icedove/3.0.11
MIME-Version: 1.0
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, Ian
	Campbell <Ian.Campbell@citrix.com>, Stefano Stabellini
	<stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [RFC] Extend the number of event channels availabe to
	guests
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
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,
reported below there is a request for comment on the plan to extend the 
number of event channel the hypervisor can grok. I've informally 
discussed some parts of this with Ian Campbell but I would like to 
formalize it someway, hear more opinion on it and possibly give the 
project more exposure and guidance, as this is supposed to be one of the 
major features for 4.3.

SYNOPSIS
Currently the number of eventchannel every guest can setup is 1k or 4k, 
depending if the guest is 32 or 64 bits. This is a limitation in the 
number of guests an host can actively run, because the host and guest 
will need to setup eventchannel among them and thus at some point Dom0 
will exhaust the number of available eventchannel for all guests. Scope 
of this work is to raise the number of available eventchannel for every 
guest (and then, also for Dom0).

The 4k number cames out directly by the eventchannel organization. In 
order to address a single channel, every guest keeps a map of 
corresponding bits in its shared page with the hypervisor. However, in 
order to avoid to search anytime for 4k bits, a per-cpu, upper level 
further mask is present to address singularly smaller words of the 
pending eventchannel mask (making the organization of the code at all 
the effects a two-level lookup table.

In order to expand the number of available eventchannels, one must take 
into account 2 important aspects, related to compatibility: ABI and 
ability to run both old and new method altogether.
The former one is about the fact that all the controlling structures 
related to eventchannels live in public ABI of the hypervisor. A valid 
solution, then, must not enforce any ABI changes at all.
The latter one is about the ability to leave the hypervisor to work with 
both the old model and the new one. This is to keep support with guests 
running an older kernel than the patched one.

Proposal
The proposal is pretty simple: the eventchannel search will become a 
three-level lookup table, with the leaf level being composed by shared 
pages registered at boot time by the guests.
The bitmap working now as leaf (then called "second level") will work 
alternatively as leaf level still (for older kernel) or for intermediate 
level to address into a new array of shared pages (for newer kernels). 
This leaves the possibility to reuse the existing mechanisms without 
modifying its internals.

More specifically, what needs to happen:
- Add new members to struct domain to handle an array of pages (to 
contain the actual evtchn bitmaps), a further array of pages (to contain 
the evtchn masks) and a control bit to say if it is subjective to the 
new mode or not. Initially the arrays will be empty and the control bit 
will be OFF.
- At init_platform() time, the guest must allocate the pages to compose 
the 2 arrays and invoke a novel hypercall which, at big lines, does the 
following:
   * Creates some pages to populate the new arrays in struct domain via 
alloc_xenheap_pages()
   * Recreates the mapping with the gpfn passed from the userland, using 
basically guest_physmap_add_page()
   * Sets the control bit to ON
- Places that need to access to the actual leaf bit (like, for example, 
xen_evtchn_do_upcall()) will need to double check the control bit. If it 
is OFF they consider the second level as the leaf one, otherwise they 
will do a further lookup to get the bit from the new array of pages.

Of course there are some nits to be decided yet, like, for example:
* How many pages should the new level have? We can start by populating 
just one, for example
* Who should have really the knowledge of how many pages to allocate? 
Likely the hypervisor should have a threshhold, but in general we may 
want to have a posting mechanism to have the guest ask the hypervisor 
before-hand and satisfy its actual request
* How many bits should be indirected in the third-level by every single 
bit in the second-level? (that is a really minor factor, but still).

Please let me know what do you think about this.

Thanks,
Attilio


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 19 23:51:10 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 19 Sep 2012 23: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 1TEU2Y-0007he-6H; Wed, 19 Sep 2012 23:50:46 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <attilio.rao@citrix.com>) id 1TEU2V-0007hZ-Tg
	for xen-devel@lists.xensource.com; Wed, 19 Sep 2012 23:50:44 +0000
Received: from [85.158.138.51:43462] by server-8.bemta-3.messagelabs.com id
	F8/FB-24700-35A5A505; Wed, 19 Sep 2012 23:50:43 +0000
X-Env-Sender: attilio.rao@citrix.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1348098642!22365803!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTAxNzU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12555 invoked from network); 19 Sep 2012 23:50:42 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Sep 2012 23:50:42 -0000
X-IronPort-AV: E=Sophos;i="4.80,452,1344211200"; d="scan'208";a="14643093"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Sep 2012 23:50:42 +0000
Received: from [10.80.3.221] (10.80.3.221) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Thu, 20 Sep 2012 00:50:42 +0100
Message-ID: <505A5A03.4000106@citrix.com>
Date: Thu, 20 Sep 2012 00:49:23 +0100
From: Attilio Rao <attilio.rao@citrix.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US;
	rv:1.9.1.16) Gecko/20111110 Icedove/3.0.11
MIME-Version: 1.0
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, Ian
	Campbell <Ian.Campbell@citrix.com>, Stefano Stabellini
	<stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [RFC] Extend the number of event channels availabe to
	guests
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
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,
reported below there is a request for comment on the plan to extend the 
number of event channel the hypervisor can grok. I've informally 
discussed some parts of this with Ian Campbell but I would like to 
formalize it someway, hear more opinion on it and possibly give the 
project more exposure and guidance, as this is supposed to be one of the 
major features for 4.3.

SYNOPSIS
Currently the number of eventchannel every guest can setup is 1k or 4k, 
depending if the guest is 32 or 64 bits. This is a limitation in the 
number of guests an host can actively run, because the host and guest 
will need to setup eventchannel among them and thus at some point Dom0 
will exhaust the number of available eventchannel for all guests. Scope 
of this work is to raise the number of available eventchannel for every 
guest (and then, also for Dom0).

The 4k number cames out directly by the eventchannel organization. In 
order to address a single channel, every guest keeps a map of 
corresponding bits in its shared page with the hypervisor. However, in 
order to avoid to search anytime for 4k bits, a per-cpu, upper level 
further mask is present to address singularly smaller words of the 
pending eventchannel mask (making the organization of the code at all 
the effects a two-level lookup table.

In order to expand the number of available eventchannels, one must take 
into account 2 important aspects, related to compatibility: ABI and 
ability to run both old and new method altogether.
The former one is about the fact that all the controlling structures 
related to eventchannels live in public ABI of the hypervisor. A valid 
solution, then, must not enforce any ABI changes at all.
The latter one is about the ability to leave the hypervisor to work with 
both the old model and the new one. This is to keep support with guests 
running an older kernel than the patched one.

Proposal
The proposal is pretty simple: the eventchannel search will become a 
three-level lookup table, with the leaf level being composed by shared 
pages registered at boot time by the guests.
The bitmap working now as leaf (then called "second level") will work 
alternatively as leaf level still (for older kernel) or for intermediate 
level to address into a new array of shared pages (for newer kernels). 
This leaves the possibility to reuse the existing mechanisms without 
modifying its internals.

More specifically, what needs to happen:
- Add new members to struct domain to handle an array of pages (to 
contain the actual evtchn bitmaps), a further array of pages (to contain 
the evtchn masks) and a control bit to say if it is subjective to the 
new mode or not. Initially the arrays will be empty and the control bit 
will be OFF.
- At init_platform() time, the guest must allocate the pages to compose 
the 2 arrays and invoke a novel hypercall which, at big lines, does the 
following:
   * Creates some pages to populate the new arrays in struct domain via 
alloc_xenheap_pages()
   * Recreates the mapping with the gpfn passed from the userland, using 
basically guest_physmap_add_page()
   * Sets the control bit to ON
- Places that need to access to the actual leaf bit (like, for example, 
xen_evtchn_do_upcall()) will need to double check the control bit. If it 
is OFF they consider the second level as the leaf one, otherwise they 
will do a further lookup to get the bit from the new array of pages.

Of course there are some nits to be decided yet, like, for example:
* How many pages should the new level have? We can start by populating 
just one, for example
* Who should have really the knowledge of how many pages to allocate? 
Likely the hypervisor should have a threshhold, but in general we may 
want to have a posting mechanism to have the guest ask the hypervisor 
before-hand and satisfy its actual request
* How many bits should be indirected in the third-level by every single 
bit in the second-level? (that is a really minor factor, but still).

Please let me know what do you think about this.

Thanks,
Attilio


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 20 02:09:36 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Sep 2012 02:09: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 1TEWC2-0004Ok-Kv; Thu, 20 Sep 2012 02:08: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 1TEWC0-0004Of-Sk
	for xen-devel@lists.xensource.com; Thu, 20 Sep 2012 02:08:41 +0000
Received: from [85.158.139.83:28657] by server-3.bemta-5.messagelabs.com id
	BE/AA-21836-8AA7A505; Thu, 20 Sep 2012 02:08:40 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1348106919!29096823!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTAzMDk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10258 invoked from network); 20 Sep 2012 02:08:39 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Sep 2012 02:08:39 -0000
X-IronPort-AV: E=Sophos;i="4.80,452,1344211200"; d="scan'208";a="14643574"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Sep 2012 02:08: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.279.1; Thu, 20 Sep 2012 03:08: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 1TEWBy-0002CS-7p;
	Thu, 20 Sep 2012 02:08:38 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1TEWBx-0000BC-RJ;
	Thu, 20 Sep 2012 03:08:38 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-13817-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 20 Sep 2012 03:08:37 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.2-testing test] 13817: 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 13817 xen-4.2-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13817/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore            fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-i386-i386-xl-qemuu-winxpsp3  9 guest-localmigrate         fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             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-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  3462914d95d3
baseline version:
 xen                  357bd4bb2950

------------------------------------------------------------
People who touched revisions under test:
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  Jan Beulich <jbeulich@suse.com>
  Keir Fraser <keir@xen.org>
  Steven Maresca <steve@zentific.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                                 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                                     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-4.2-testing
+ revision=3462914d95d3
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push xen-4.2-testing 3462914d95d3
+ branch=xen-4.2-testing
+ revision=3462914d95d3
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-4.2-testing
+ '[' xxen = xlinux ']'
+ linuxbranch=linux
+ : master
+ : tested/2.6.39.x
+ . ap-common
++ : xen@xenbits.xensource.com
++ : http://xenbits.xen.org/hg/staging/xen-4.2-testing.hg
++ : git://xenbits.xen.org/staging/qemu-xen-4.2-testing.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : xen@xenbits.xensource.com:git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.xen-4.2-testing
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-4.2-testing.git
++ : daily-cron.xen-4.2-testing
+ TREE_LINUX=xen@xenbits.xensource.com:git/linux-pvops.git
+ TREE_QEMU_UPSTREAM=xen@xenbits.xensource.com:git/qemu-upstream-4.2-testing.git
+ info_linux_tree xen-4.2-testing
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/xen-4.2-testing.hg
+ hg push -r 3462914d95d3 ssh://xen@xenbits.xensource.com/HG/xen-4.2-testing.hg
pushing to ssh://xen@xenbits.xensource.com/HG/xen-4.2-testing.hg
searching for changes
remote: adding changesets
remote: adding manifests
remote: adding file changes
remote: added 6 changesets with 8 changes to 7 files

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 20 02:09:36 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Sep 2012 02:09: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 1TEWC2-0004Ok-Kv; Thu, 20 Sep 2012 02:08: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 1TEWC0-0004Of-Sk
	for xen-devel@lists.xensource.com; Thu, 20 Sep 2012 02:08:41 +0000
Received: from [85.158.139.83:28657] by server-3.bemta-5.messagelabs.com id
	BE/AA-21836-8AA7A505; Thu, 20 Sep 2012 02:08:40 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1348106919!29096823!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTAzMDk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10258 invoked from network); 20 Sep 2012 02:08:39 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Sep 2012 02:08:39 -0000
X-IronPort-AV: E=Sophos;i="4.80,452,1344211200"; d="scan'208";a="14643574"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Sep 2012 02:08: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.279.1; Thu, 20 Sep 2012 03:08: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 1TEWBy-0002CS-7p;
	Thu, 20 Sep 2012 02:08:38 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1TEWBx-0000BC-RJ;
	Thu, 20 Sep 2012 03:08:38 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-13817-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 20 Sep 2012 03:08:37 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.2-testing test] 13817: 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 13817 xen-4.2-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13817/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore            fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-i386-i386-xl-qemuu-winxpsp3  9 guest-localmigrate         fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             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-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  3462914d95d3
baseline version:
 xen                  357bd4bb2950

------------------------------------------------------------
People who touched revisions under test:
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  Jan Beulich <jbeulich@suse.com>
  Keir Fraser <keir@xen.org>
  Steven Maresca <steve@zentific.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                                 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                                     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-4.2-testing
+ revision=3462914d95d3
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push xen-4.2-testing 3462914d95d3
+ branch=xen-4.2-testing
+ revision=3462914d95d3
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-4.2-testing
+ '[' xxen = xlinux ']'
+ linuxbranch=linux
+ : master
+ : tested/2.6.39.x
+ . ap-common
++ : xen@xenbits.xensource.com
++ : http://xenbits.xen.org/hg/staging/xen-4.2-testing.hg
++ : git://xenbits.xen.org/staging/qemu-xen-4.2-testing.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : xen@xenbits.xensource.com:git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.xen-4.2-testing
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-4.2-testing.git
++ : daily-cron.xen-4.2-testing
+ TREE_LINUX=xen@xenbits.xensource.com:git/linux-pvops.git
+ TREE_QEMU_UPSTREAM=xen@xenbits.xensource.com:git/qemu-upstream-4.2-testing.git
+ info_linux_tree xen-4.2-testing
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/xen-4.2-testing.hg
+ hg push -r 3462914d95d3 ssh://xen@xenbits.xensource.com/HG/xen-4.2-testing.hg
pushing to ssh://xen@xenbits.xensource.com/HG/xen-4.2-testing.hg
searching for changes
remote: adding changesets
remote: adding manifests
remote: adding file changes
remote: added 6 changesets with 8 changes to 7 files

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 20 06:13:59 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Sep 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 1TEa0r-00062k-T2; Thu, 20 Sep 2012 06:13:25 +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 1TEa0q-00062f-3U
	for xen-devel@lists.xen.org; Thu, 20 Sep 2012 06:13:24 +0000
Received: from [85.158.139.211:63427] by server-6.bemta-5.messagelabs.com id
	F0/1F-21336-304BA505; Thu, 20 Sep 2012 06:13:23 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-14.tower-206.messagelabs.com!1348121601!19206062!1
X-Originating-IP: [209.85.212.173]
X-SpamReason: No, hits=1.4 required=7.0 tests=HTML_20_30,HTML_MESSAGE,
	MIME_QP_LONG_LINE,ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18915 invoked from network); 20 Sep 2012 06:13:21 -0000
Received: from mail-wi0-f173.google.com (HELO mail-wi0-f173.google.com)
	(209.85.212.173)
	by server-14.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Sep 2012 06:13:21 -0000
Received: by wibhm6 with SMTP id hm6so160133wib.14
	for <xen-devel@lists.xen.org>; Wed, 19 Sep 2012 23:13:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type;
	bh=RVI0z2LuNnQrxw/brfFKcWcpsb2oZItPxDeWAU+4odE=;
	b=mumghZNE4Ay2HZUuQBRknEtZg1WDt8J71X1eaq3kfxxSFVXJhrqUYmLEvJUSs/RRZB
	XyZEZ1/NtTX+xjTjvrBBa5XfQ7ARrQZGm4vvgT1KO0DiOJnDz1rGWuRjImCNe2n9M46i
	oPLxxkEW/7SNPbO7mfq2VY6NZK1RdbjbKb+hUCVBHhWFOw7kSm7LkZRtgJ7xV7fl0kdv
	aLQxtMkn6CIIbfhwjul2gBYwmD1Y+X+pUeX80d3skvxRLhrmaKlWJwiNkfrXqFvULkpz
	NuuoE3U+t7htwD9IhWS09VS98MET4bZqnEQT6n+ngwOCKhAMgbRtrc165b8Y4vjz6CFk
	USbg==
Received: by 10.216.136.167 with SMTP id w39mr557802wei.76.1348121601447;
	Wed, 19 Sep 2012 23:13:21 -0700 (PDT)
Received: from [192.168.1.69] (host86-167-82-156.range86-167.btcentralplus.com.
	[86.167.82.156])
	by mx.google.com with ESMTPS id o2sm8990344wiz.11.2012.09.19.23.13.18
	(version=SSLv3 cipher=OTHER); Wed, 19 Sep 2012 23:13:20 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Thu, 20 Sep 2012 07:13:15 +0100
From: Keir Fraser <keir.xen@gmail.com>
To: Ben Guthro <ben@guthro.net>,
	Jan Beulich <JBeulich@suse.com>
Message-ID: <CC80728B.3F362%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] Xen4.2 S3 regression?
Thread-Index: Ac2W9wUV5d1C113vwUiCnR/khSsTCA==
In-Reply-To: <CAOvdn6Xn1ZnontBO0KoJE9hgBsW-a1rR2EhWYEpgbbrELkXZNw@mail.gmail.com>
Mime-version: 1.0
Cc: xen-devel <xen-devel@lists.xen.org>, john.baboval@citrix.com,
	Thomas Goetz <thomas.goetz@citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] Xen4.2 S3 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: multipart/mixed; boundary="===============0740956528939052827=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--===============0740956528939052827==
Content-type: multipart/alternative;
	boundary="B_3430969998_69237725"

> This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--B_3430969998_69237725
Content-type: text/plain;
	charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable

CPU#1 got stuck in loop in cpu_init() as it appears to be =8Calready
initialised=B9 in cpu_initialized bitmap. CPU#0 detects it is stuck and
carries on, but the resume code assumes all CPUs are brought back online an=
d
crashes later.

I wonder how long this has been broken. I recall reworking the CPU bringup
code a lot early during 4.1.0 development... And I didn=B9t test S3.

 -- Keir

On 19/09/2012 22:07, "Ben Guthro" <ben@guthro.net> wrote:

> No hardware debugger just yet - but I've moved to another machine (Lenovo=
 T400
> laptop) - and am now seeing the following stack trace when I resume
> (this is using the tip of the 4.2-testing tree)
>=20
> It looks like either the vcpu, or the runstate is NULL, at this point in =
the
> resume process...
>=20
>=20
> (XEN) Finishing wakeup from ACPI S3 state.
> (XEN) Enabling non-boot CPUs =A0...
> (XEN) CPU#1 already initialized!
> (XEN) Stuck ??
> (XEN) Error taking CPU1 up: -5
> [ =A0 38.570054] ACPI: Low-level resume complete
> [ =A0 38.570054] PM: Restoring platform NVS memory
> [ =A0 38.570054] Enabling non-boot CPUs ...
> (XEN) ----[ Xen-4.2.1-pre =A0x86_64 =A0debug=3Dn =A0Tainted: =A0 =A0C ]----
> (XEN) CPU: =A0 =A00
> (XEN) RIP: =A0 =A0e008:[<ffff82c480120585>] vcpu_runstate_get+0xe5/0x130
> (XEN) RFLAGS: 0000000000010006 =A0 CONTEXT: hypervisor
> (XEN) rax: 00007d3b7fd17180 =A0 rbx: ffff8300bd2fe000 =A0 rcx: 00000000000000=
00
> (XEN) rdx: ffff08003fc8bd80 =A0 rsi: ffff82c48029fe28 =A0 rdi: ffff8300bd2fe0=
00
> (XEN) rbp: ffff82c48029fe28 =A0 rsp: ffff82c48029fdf8 =A0 r8: =A000000000000000=
08
> (XEN) r9: =A000000000000001c0 =A0 r10: ffff82c48021f4a0 =A0 r11: 00000000000002=
82
> (XEN) r12: ffff82c4802e8ee0 =A0 r13: ffff880039762da0 =A0 r14: ffff82c4802d31=
40
> (XEN) r15: fffffffffffffff2 =A0 cr0: 000000008005003b =A0 cr4: 00000000000026=
f0
> (XEN) cr3: 0000000139ee4000 =A0 cr2: 0000000000000060
> (XEN) ds: 0000 =A0 es: 0000 =A0 fs: 0000 =A0 gs: 0000 =A0 ss: e010 =A0 cs: e008
> (XEN) Xen stack trace from rsp=3Dffff82c48029fdf8:
> (XEN) =A0 =A0ffff8300bd2fe000 ffff82c48029ff18 ffff880037481d40 ffff880039762=
da0
> (XEN) =A0 =A00000000000000001 ffff82c480157df4 0000000000000070 ffff82f6016db=
300
> (XEN) =A0 =A000000000000b6d98 ffff8301355d8000 0000000000000070 ffff82c480170=
2ab
> (XEN) =A0 =A0ffff88003fc8bd80 0000000000000000 0000000000000020 ffff8300bd2fe=
000
> (XEN) =A0 =A0ffff8301355d8000 ffff880037481d40 ffff880039762da0 0000000000000=
001
> (XEN) =A0 =A00000000000000003 ffff82c4801058df ffff82c48029ff18 ffff82c480114=
62e
> (XEN) =A0 =A00000000000000000 0000000000000000 0000000400000004 ffff82c48029f=
f18
> (XEN) =A0 =A00000000000000010 ffff8300bd6a0000 ffff8800374819a8 ffff8300bd6a0=
000
> (XEN) =A0 =A0ffff880037481d48 0000000000000001 ffff880039762da0 ffff82c480214=
288
> (XEN) =A0 =A00000000000000003 0000000000000001 ffff880039762da0 0000000000000=
001
> (XEN) =A0 =A0ffff880037481d48 0000000000000001 0000000000000282 ffff880002dc4=
240
> (XEN) =A0 =A000000000000001c0 00000000000001c0 0000000000000018 ffffffff81001=
30a
> (XEN) =A0 =A0ffff880037481d40 0000000000000001 0000000000000005 0000010000000=
000
> (XEN) =A0 =A0ffffffff8100130a 000000000000e033 0000000000000282 ffff880037481=
d20
> (XEN) =A0 =A0000000000000e02b 0000000000000000 0000000000000000 0000000000000=
000
> (XEN) =A0 =A00000000000000000 0000000000000000 ffff8300bd6a0000 0000000000000=
000
> (XEN) =A0 =A00000000000000000
> (XEN) Xen call trace:
> (XEN) =A0 =A0[<ffff82c480120585>] vcpu_runstate_get+0xe5/0x130
> (XEN) =A0 =A0[<ffff82c480157df4>] arch_do_vcpu_op+0x134/0x5d0
> (XEN) =A0 =A0[<ffff82c4801702ab>] do_update_descriptor+0x1db/0x220
> (XEN) =A0 =A0[<ffff82c4801058df>] do_vcpu_op+0x6f/0x4a0
> (XEN) =A0 =A0[<ffff82c48011462e>] do_multicall+0x13e/0x330
> (XEN) =A0 =A0[<ffff82c480214288>] syscall_enter+0x88/0x8d
> (XEN) =A0 =A0
> (XEN) Pagetable walk from 0000000000000060:
> (XEN) =A0L4[0x000] =3D 00000001004a5067 0000000000038c9d
> (XEN) =A0L3[0x000] =3D 000000013a703067 0000000000003094
> (XEN) =A0L2[0x000] =3D 0000000000000000 ffffffffffffffff=A0
> (XEN)=A0
> (XEN) ****************************************
> (XEN) Panic on CPU 0:
> (XEN) FATAL PAGE FAULT
> (XEN) [error_code=3D0000]
> (XEN) Faulting linear address: 0000000000000060
> (XEN) ****************************************
> (XEN)=A0
> (XEN) Reboot in five seconds...
>=20
>=20
> On Fri, Sep 7, 2012 at 12:06 PM, Ben Guthro <ben@guthro.net> wrote:
>> I'll work on getting a JTAG, ICE, or something else - it is on an
>> Intel SDP - so it should have the ports for it.
>>=20
>> My current suspicion on this is that the hardware registers are not
>> being programmed the same way as they were in 4.0.x
>> (Since the "pulsing power button LED" on the laptops, and the behavior
>> of the Desktop SDP are now similar)
>>=20
>> Once again - I don't have a lot of evidence to back this up - however,
>> if I ifdef out the register writes that actually start the low level
>> suspend - in
>> xen/arch/x86/acpi/power.c =A0acpi_enter_sleep_state() - the rest of the
>> suspend process completes as though the machine suspended, and then
>> immediately resumed.
>>=20
>> In this case - the system seems to be functioning properly.
>>=20
>>=20
>>=20
>>=20
>>=20
>> Hack to prevent low level S3 attached.
>>=20
>>=20
>>=20
>> On Fri, Sep 7, 2012 at 8:18 AM, Jan Beulich <JBeulich@suse.com> wrote:
>>>>>> >>>> On 07.09.12 at 13:51, Ben Guthro <ben@guthro.net> wrote:
>>>> >> However, when I run with console=3Dnone, the observed behavior is ver=
y
>>>> >> different.
>>>> >> The system seems to go to sleep successfully - but when I press the
>>>> >> power button to wake it up - the power comes on - the fans spin up =
-
>>>> >> but the system is unresponsive.
>>>> >> No video
>>>> >> No network
>>>> >> keyboard LEDs (Caps,Numlock) do not light up.
>>>> >>
>>>> >>
>>>> >> Alternate debugging strategies welcome.
>>> >
>>> > I'm afraid other than being lucky to spot something via code
>>> > inspection, the only alternative is an ITP/ICE. Maybe Intel folks
>>> > could help out debugging this if it's reproducible for them.
>>> >
>>> > Jan
>>> >
>=20
>=20
>=20
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel


--B_3430969998_69237725
Content-type: text/html;
	charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable

<HTML>
<HEAD>
<TITLE>Re: [Xen-devel] Xen4.2 S3 regression?</TITLE>
</HEAD>
<BODY>
<FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN STYLE=3D'font-size:11pt=
'>CPU#1 got stuck in loop in cpu_init() as it appears to be &#8216;already i=
nitialised&#8217; in cpu_initialized bitmap. CPU#0 detects it is stuck and c=
arries on, but the resume code assumes all CPUs are brought back online and =
crashes later.<BR>
<BR>
I wonder how long this has been broken. I recall reworking the CPU bringup =
code a lot early during 4.1.0 development... And I didn&#8217;t test S3.<BR>
<BR>
&nbsp;-- Keir<BR>
<BR>
On 19/09/2012 22:07, &quot;Ben Guthro&quot; &lt;<a href=3D"ben@guthro.net">be=
n@guthro.net</a>&gt; wrote:<BR>
<BR>
</SPAN></FONT><BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><=
SPAN STYLE=3D'font-size:11pt'>No hardware debugger just yet - but I've moved t=
o another machine (Lenovo T400 laptop) - and am now seeing the following sta=
ck trace when I resume<BR>
(this is using the tip of the 4.2-testing tree)<BR>
<BR>
It looks like either the vcpu, or the runstate is NULL, at this point in th=
e resume process...<BR>
<BR>
<BR>
(XEN) Finishing wakeup from ACPI S3 state.<BR>
(XEN) Enabling non-boot CPUs =A0...<BR>
(XEN) CPU#1 already initialized!<BR>
(XEN) Stuck ??<BR>
(XEN) Error taking CPU1 up: -5<BR>
[ =A0 38.570054] ACPI: Low-level resume complete<BR>
[ =A0 38.570054] PM: Restoring platform NVS memory<BR>
[ =A0 38.570054] Enabling non-boot CPUs ...<BR>
(XEN) ----[ Xen-4.2.1-pre =A0x86_64 =A0debug=3Dn =A0Tainted: =A0 =A0C ]----<BR>
(XEN) CPU: =A0 =A00<BR>
(XEN) RIP: =A0 =A0e008:[&lt;ffff82c480120585&gt;] vcpu_runstate_get+0xe5/0x130<=
BR>
(XEN) RFLAGS: 0000000000010006 =A0 CONTEXT: hypervisor<BR>
(XEN) rax: 00007d3b7fd17180 =A0 rbx: ffff8300bd2fe000 =A0 rcx: 0000000000000000=
<BR>
(XEN) rdx: ffff08003fc8bd80 =A0 rsi: ffff82c48029fe28 =A0 rdi: ffff8300bd2fe000=
<BR>
(XEN) rbp: ffff82c48029fe28 =A0 rsp: ffff82c48029fdf8 =A0 r8: =A00000000000000008=
<BR>
(XEN) r9: =A000000000000001c0 =A0 r10: ffff82c48021f4a0 =A0 r11: 0000000000000282=
<BR>
(XEN) r12: ffff82c4802e8ee0 =A0 r13: ffff880039762da0 =A0 r14: ffff82c4802d3140=
<BR>
(XEN) r15: fffffffffffffff2 =A0 cr0: 000000008005003b =A0 cr4: 00000000000026f0=
<BR>
(XEN) cr3: 0000000139ee4000 =A0 cr2: 0000000000000060<BR>
(XEN) ds: 0000 =A0 es: 0000 =A0 fs: 0000 =A0 gs: 0000 =A0 ss: e010 =A0 cs: e008<BR>
(XEN) Xen stack trace from rsp=3Dffff82c48029fdf8:<BR>
(XEN) =A0 =A0ffff8300bd2fe000 ffff82c48029ff18 ffff880037481d40 ffff880039762da=
0<BR>
(XEN) =A0 =A00000000000000001 ffff82c480157df4 0000000000000070 ffff82f6016db30=
0<BR>
(XEN) =A0 =A000000000000b6d98 ffff8301355d8000 0000000000000070 ffff82c4801702a=
b<BR>
(XEN) =A0 =A0ffff88003fc8bd80 0000000000000000 0000000000000020 ffff8300bd2fe00=
0<BR>
(XEN) =A0 =A0ffff8301355d8000 ffff880037481d40 ffff880039762da0 000000000000000=
1<BR>
(XEN) =A0 =A00000000000000003 ffff82c4801058df ffff82c48029ff18 ffff82c48011462=
e<BR>
(XEN) =A0 =A00000000000000000 0000000000000000 0000000400000004 ffff82c48029ff1=
8<BR>
(XEN) =A0 =A00000000000000010 ffff8300bd6a0000 ffff8800374819a8 ffff8300bd6a000=
0<BR>
(XEN) =A0 =A0ffff880037481d48 0000000000000001 ffff880039762da0 ffff82c48021428=
8<BR>
(XEN) =A0 =A00000000000000003 0000000000000001 ffff880039762da0 000000000000000=
1<BR>
(XEN) =A0 =A0ffff880037481d48 0000000000000001 0000000000000282 ffff880002dc424=
0<BR>
(XEN) =A0 =A000000000000001c0 00000000000001c0 0000000000000018 ffffffff8100130=
a<BR>
(XEN) =A0 =A0ffff880037481d40 0000000000000001 0000000000000005 000001000000000=
0<BR>
(XEN) =A0 =A0ffffffff8100130a 000000000000e033 0000000000000282 ffff880037481d2=
0<BR>
(XEN) =A0 =A0000000000000e02b 0000000000000000 0000000000000000 000000000000000=
0<BR>
(XEN) =A0 =A00000000000000000 0000000000000000 ffff8300bd6a0000 000000000000000=
0<BR>
(XEN) =A0 =A00000000000000000<BR>
(XEN) Xen call trace:<BR>
(XEN) =A0 =A0[&lt;ffff82c480120585&gt;] vcpu_runstate_get+0xe5/0x130<BR>
(XEN) =A0 =A0[&lt;ffff82c480157df4&gt;] arch_do_vcpu_op+0x134/0x5d0<BR>
(XEN) =A0 =A0[&lt;ffff82c4801702ab&gt;] do_update_descriptor+0x1db/0x220<BR>
(XEN) =A0 =A0[&lt;ffff82c4801058df&gt;] do_vcpu_op+0x6f/0x4a0<BR>
(XEN) =A0 =A0[&lt;ffff82c48011462e&gt;] do_multicall+0x13e/0x330<BR>
(XEN) =A0 =A0[&lt;ffff82c480214288&gt;] syscall_enter+0x88/0x8d<BR>
(XEN) =A0 =A0<BR>
(XEN) Pagetable walk from 0000000000000060:<BR>
(XEN) =A0L4[0x000] =3D 00000001004a5067 0000000000038c9d<BR>
(XEN) =A0L3[0x000] =3D 000000013a703067 0000000000003094<BR>
(XEN) =A0L2[0x000] =3D 0000000000000000 ffffffffffffffff=A0<BR>
(XEN)=A0<BR>
(XEN) ****************************************<BR>
(XEN) Panic on CPU 0:<BR>
(XEN) FATAL PAGE FAULT<BR>
(XEN) [error_code=3D0000]<BR>
(XEN) Faulting linear address: 0000000000000060<BR>
(XEN) ****************************************<BR>
(XEN)=A0<BR>
(XEN) Reboot in five seconds...<BR>
<BR>
<BR>
On Fri, Sep 7, 2012 at 12:06 PM, Ben Guthro &lt;<a href=3D"ben@guthro.net">be=
n@guthro.net</a>&gt; wrote:<BR>
</SPAN></FONT><BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><=
SPAN STYLE=3D'font-size:11pt'>I'll work on getting a JTAG, ICE, or something e=
lse - it is on an<BR>
Intel SDP - so it should have the ports for it.<BR>
<BR>
My current suspicion on this is that the hardware registers are not<BR>
being programmed the same way as they were in 4.0.x<BR>
(Since the &quot;pulsing power button LED&quot; on the laptops, and the beh=
avior<BR>
of the Desktop SDP are now similar)<BR>
<BR>
Once again - I don't have a lot of evidence to back this up - however,<BR>
if I ifdef out the register writes that actually start the low level<BR>
suspend - in<BR>
xen/arch/x86/acpi/power.c =A0acpi_enter_sleep_state() - the rest of the<BR>
suspend process completes as though the machine suspended, and then<BR>
immediately resumed.<BR>
<BR>
In this case - the system seems to be functioning properly.<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
Hack to prevent low level S3 attached.<BR>
<BR>
<BR>
<BR>
On Fri, Sep 7, 2012 at 8:18 AM, Jan Beulich &lt;<a href=3D"JBeulich@suse.com"=
>JBeulich@suse.com</a>&gt; wrote:<BR>
&gt;&gt;&gt;&gt; On 07.09.12 at 13:51, Ben Guthro &lt;<a href=3D"ben@guthro.n=
et">ben@guthro.net</a>&gt; wrote:<BR>
&gt;&gt; However, when I run with console=3Dnone, the observed behavior is ve=
ry<BR>
&gt;&gt; different.<BR>
&gt;&gt; The system seems to go to sleep successfully - but when I press th=
e<BR>
&gt;&gt; power button to wake it up - the power comes on - the fans spin up=
 -<BR>
&gt;&gt; but the system is unresponsive.<BR>
&gt;&gt; No video<BR>
&gt;&gt; No network<BR>
&gt;&gt; keyboard LEDs (Caps,Numlock) do not light up.<BR>
&gt;&gt;<BR>
&gt;&gt;<BR>
&gt;&gt; Alternate debugging strategies welcome.<BR>
&gt;<BR>
&gt; I'm afraid other than being lucky to spot something via code<BR>
&gt; inspection, the only alternative is an ITP/ICE. Maybe Intel folks<BR>
&gt; could help out debugging this if it's reproducible for them.<BR>
&gt;<BR>
&gt; Jan<BR>
&gt;<BR>
</SPAN></FONT></BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial">=
<SPAN STYLE=3D'font-size:11pt'><BR>
<BR>
<HR ALIGN=3DCENTER SIZE=3D"3" WIDTH=3D"95%"></SPAN></FONT><FONT SIZE=3D"2"><FONT FA=
CE=3D"Consolas, Courier New, Courier"><SPAN STYLE=3D'font-size:10pt'>___________=
____________________________________<BR>
Xen-devel mailing list<BR>
<a href=3D"Xen-devel@lists.xen.org">Xen-devel@lists.xen.org</a><BR>
<a href=3D"http://lists.xen.org/xen-devel">http://lists.xen.org/xen-devel</a>=
<BR>
</SPAN></FONT></FONT></BLOCKQUOTE>
</BODY>
</HTML>


--B_3430969998_69237725--




--===============0740956528939052827==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============0740956528939052827==--




From xen-devel-bounces@lists.xen.org Thu Sep 20 06:13:59 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Sep 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 1TEa0r-00062k-T2; Thu, 20 Sep 2012 06:13:25 +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 1TEa0q-00062f-3U
	for xen-devel@lists.xen.org; Thu, 20 Sep 2012 06:13:24 +0000
Received: from [85.158.139.211:63427] by server-6.bemta-5.messagelabs.com id
	F0/1F-21336-304BA505; Thu, 20 Sep 2012 06:13:23 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-14.tower-206.messagelabs.com!1348121601!19206062!1
X-Originating-IP: [209.85.212.173]
X-SpamReason: No, hits=1.4 required=7.0 tests=HTML_20_30,HTML_MESSAGE,
	MIME_QP_LONG_LINE,ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18915 invoked from network); 20 Sep 2012 06:13:21 -0000
Received: from mail-wi0-f173.google.com (HELO mail-wi0-f173.google.com)
	(209.85.212.173)
	by server-14.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Sep 2012 06:13:21 -0000
Received: by wibhm6 with SMTP id hm6so160133wib.14
	for <xen-devel@lists.xen.org>; Wed, 19 Sep 2012 23:13:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type;
	bh=RVI0z2LuNnQrxw/brfFKcWcpsb2oZItPxDeWAU+4odE=;
	b=mumghZNE4Ay2HZUuQBRknEtZg1WDt8J71X1eaq3kfxxSFVXJhrqUYmLEvJUSs/RRZB
	XyZEZ1/NtTX+xjTjvrBBa5XfQ7ARrQZGm4vvgT1KO0DiOJnDz1rGWuRjImCNe2n9M46i
	oPLxxkEW/7SNPbO7mfq2VY6NZK1RdbjbKb+hUCVBHhWFOw7kSm7LkZRtgJ7xV7fl0kdv
	aLQxtMkn6CIIbfhwjul2gBYwmD1Y+X+pUeX80d3skvxRLhrmaKlWJwiNkfrXqFvULkpz
	NuuoE3U+t7htwD9IhWS09VS98MET4bZqnEQT6n+ngwOCKhAMgbRtrc165b8Y4vjz6CFk
	USbg==
Received: by 10.216.136.167 with SMTP id w39mr557802wei.76.1348121601447;
	Wed, 19 Sep 2012 23:13:21 -0700 (PDT)
Received: from [192.168.1.69] (host86-167-82-156.range86-167.btcentralplus.com.
	[86.167.82.156])
	by mx.google.com with ESMTPS id o2sm8990344wiz.11.2012.09.19.23.13.18
	(version=SSLv3 cipher=OTHER); Wed, 19 Sep 2012 23:13:20 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Thu, 20 Sep 2012 07:13:15 +0100
From: Keir Fraser <keir.xen@gmail.com>
To: Ben Guthro <ben@guthro.net>,
	Jan Beulich <JBeulich@suse.com>
Message-ID: <CC80728B.3F362%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] Xen4.2 S3 regression?
Thread-Index: Ac2W9wUV5d1C113vwUiCnR/khSsTCA==
In-Reply-To: <CAOvdn6Xn1ZnontBO0KoJE9hgBsW-a1rR2EhWYEpgbbrELkXZNw@mail.gmail.com>
Mime-version: 1.0
Cc: xen-devel <xen-devel@lists.xen.org>, john.baboval@citrix.com,
	Thomas Goetz <thomas.goetz@citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] Xen4.2 S3 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: multipart/mixed; boundary="===============0740956528939052827=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--===============0740956528939052827==
Content-type: multipart/alternative;
	boundary="B_3430969998_69237725"

> This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--B_3430969998_69237725
Content-type: text/plain;
	charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable

CPU#1 got stuck in loop in cpu_init() as it appears to be =8Calready
initialised=B9 in cpu_initialized bitmap. CPU#0 detects it is stuck and
carries on, but the resume code assumes all CPUs are brought back online an=
d
crashes later.

I wonder how long this has been broken. I recall reworking the CPU bringup
code a lot early during 4.1.0 development... And I didn=B9t test S3.

 -- Keir

On 19/09/2012 22:07, "Ben Guthro" <ben@guthro.net> wrote:

> No hardware debugger just yet - but I've moved to another machine (Lenovo=
 T400
> laptop) - and am now seeing the following stack trace when I resume
> (this is using the tip of the 4.2-testing tree)
>=20
> It looks like either the vcpu, or the runstate is NULL, at this point in =
the
> resume process...
>=20
>=20
> (XEN) Finishing wakeup from ACPI S3 state.
> (XEN) Enabling non-boot CPUs =A0...
> (XEN) CPU#1 already initialized!
> (XEN) Stuck ??
> (XEN) Error taking CPU1 up: -5
> [ =A0 38.570054] ACPI: Low-level resume complete
> [ =A0 38.570054] PM: Restoring platform NVS memory
> [ =A0 38.570054] Enabling non-boot CPUs ...
> (XEN) ----[ Xen-4.2.1-pre =A0x86_64 =A0debug=3Dn =A0Tainted: =A0 =A0C ]----
> (XEN) CPU: =A0 =A00
> (XEN) RIP: =A0 =A0e008:[<ffff82c480120585>] vcpu_runstate_get+0xe5/0x130
> (XEN) RFLAGS: 0000000000010006 =A0 CONTEXT: hypervisor
> (XEN) rax: 00007d3b7fd17180 =A0 rbx: ffff8300bd2fe000 =A0 rcx: 00000000000000=
00
> (XEN) rdx: ffff08003fc8bd80 =A0 rsi: ffff82c48029fe28 =A0 rdi: ffff8300bd2fe0=
00
> (XEN) rbp: ffff82c48029fe28 =A0 rsp: ffff82c48029fdf8 =A0 r8: =A000000000000000=
08
> (XEN) r9: =A000000000000001c0 =A0 r10: ffff82c48021f4a0 =A0 r11: 00000000000002=
82
> (XEN) r12: ffff82c4802e8ee0 =A0 r13: ffff880039762da0 =A0 r14: ffff82c4802d31=
40
> (XEN) r15: fffffffffffffff2 =A0 cr0: 000000008005003b =A0 cr4: 00000000000026=
f0
> (XEN) cr3: 0000000139ee4000 =A0 cr2: 0000000000000060
> (XEN) ds: 0000 =A0 es: 0000 =A0 fs: 0000 =A0 gs: 0000 =A0 ss: e010 =A0 cs: e008
> (XEN) Xen stack trace from rsp=3Dffff82c48029fdf8:
> (XEN) =A0 =A0ffff8300bd2fe000 ffff82c48029ff18 ffff880037481d40 ffff880039762=
da0
> (XEN) =A0 =A00000000000000001 ffff82c480157df4 0000000000000070 ffff82f6016db=
300
> (XEN) =A0 =A000000000000b6d98 ffff8301355d8000 0000000000000070 ffff82c480170=
2ab
> (XEN) =A0 =A0ffff88003fc8bd80 0000000000000000 0000000000000020 ffff8300bd2fe=
000
> (XEN) =A0 =A0ffff8301355d8000 ffff880037481d40 ffff880039762da0 0000000000000=
001
> (XEN) =A0 =A00000000000000003 ffff82c4801058df ffff82c48029ff18 ffff82c480114=
62e
> (XEN) =A0 =A00000000000000000 0000000000000000 0000000400000004 ffff82c48029f=
f18
> (XEN) =A0 =A00000000000000010 ffff8300bd6a0000 ffff8800374819a8 ffff8300bd6a0=
000
> (XEN) =A0 =A0ffff880037481d48 0000000000000001 ffff880039762da0 ffff82c480214=
288
> (XEN) =A0 =A00000000000000003 0000000000000001 ffff880039762da0 0000000000000=
001
> (XEN) =A0 =A0ffff880037481d48 0000000000000001 0000000000000282 ffff880002dc4=
240
> (XEN) =A0 =A000000000000001c0 00000000000001c0 0000000000000018 ffffffff81001=
30a
> (XEN) =A0 =A0ffff880037481d40 0000000000000001 0000000000000005 0000010000000=
000
> (XEN) =A0 =A0ffffffff8100130a 000000000000e033 0000000000000282 ffff880037481=
d20
> (XEN) =A0 =A0000000000000e02b 0000000000000000 0000000000000000 0000000000000=
000
> (XEN) =A0 =A00000000000000000 0000000000000000 ffff8300bd6a0000 0000000000000=
000
> (XEN) =A0 =A00000000000000000
> (XEN) Xen call trace:
> (XEN) =A0 =A0[<ffff82c480120585>] vcpu_runstate_get+0xe5/0x130
> (XEN) =A0 =A0[<ffff82c480157df4>] arch_do_vcpu_op+0x134/0x5d0
> (XEN) =A0 =A0[<ffff82c4801702ab>] do_update_descriptor+0x1db/0x220
> (XEN) =A0 =A0[<ffff82c4801058df>] do_vcpu_op+0x6f/0x4a0
> (XEN) =A0 =A0[<ffff82c48011462e>] do_multicall+0x13e/0x330
> (XEN) =A0 =A0[<ffff82c480214288>] syscall_enter+0x88/0x8d
> (XEN) =A0 =A0
> (XEN) Pagetable walk from 0000000000000060:
> (XEN) =A0L4[0x000] =3D 00000001004a5067 0000000000038c9d
> (XEN) =A0L3[0x000] =3D 000000013a703067 0000000000003094
> (XEN) =A0L2[0x000] =3D 0000000000000000 ffffffffffffffff=A0
> (XEN)=A0
> (XEN) ****************************************
> (XEN) Panic on CPU 0:
> (XEN) FATAL PAGE FAULT
> (XEN) [error_code=3D0000]
> (XEN) Faulting linear address: 0000000000000060
> (XEN) ****************************************
> (XEN)=A0
> (XEN) Reboot in five seconds...
>=20
>=20
> On Fri, Sep 7, 2012 at 12:06 PM, Ben Guthro <ben@guthro.net> wrote:
>> I'll work on getting a JTAG, ICE, or something else - it is on an
>> Intel SDP - so it should have the ports for it.
>>=20
>> My current suspicion on this is that the hardware registers are not
>> being programmed the same way as they were in 4.0.x
>> (Since the "pulsing power button LED" on the laptops, and the behavior
>> of the Desktop SDP are now similar)
>>=20
>> Once again - I don't have a lot of evidence to back this up - however,
>> if I ifdef out the register writes that actually start the low level
>> suspend - in
>> xen/arch/x86/acpi/power.c =A0acpi_enter_sleep_state() - the rest of the
>> suspend process completes as though the machine suspended, and then
>> immediately resumed.
>>=20
>> In this case - the system seems to be functioning properly.
>>=20
>>=20
>>=20
>>=20
>>=20
>> Hack to prevent low level S3 attached.
>>=20
>>=20
>>=20
>> On Fri, Sep 7, 2012 at 8:18 AM, Jan Beulich <JBeulich@suse.com> wrote:
>>>>>> >>>> On 07.09.12 at 13:51, Ben Guthro <ben@guthro.net> wrote:
>>>> >> However, when I run with console=3Dnone, the observed behavior is ver=
y
>>>> >> different.
>>>> >> The system seems to go to sleep successfully - but when I press the
>>>> >> power button to wake it up - the power comes on - the fans spin up =
-
>>>> >> but the system is unresponsive.
>>>> >> No video
>>>> >> No network
>>>> >> keyboard LEDs (Caps,Numlock) do not light up.
>>>> >>
>>>> >>
>>>> >> Alternate debugging strategies welcome.
>>> >
>>> > I'm afraid other than being lucky to spot something via code
>>> > inspection, the only alternative is an ITP/ICE. Maybe Intel folks
>>> > could help out debugging this if it's reproducible for them.
>>> >
>>> > Jan
>>> >
>=20
>=20
>=20
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel


--B_3430969998_69237725
Content-type: text/html;
	charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable

<HTML>
<HEAD>
<TITLE>Re: [Xen-devel] Xen4.2 S3 regression?</TITLE>
</HEAD>
<BODY>
<FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN STYLE=3D'font-size:11pt=
'>CPU#1 got stuck in loop in cpu_init() as it appears to be &#8216;already i=
nitialised&#8217; in cpu_initialized bitmap. CPU#0 detects it is stuck and c=
arries on, but the resume code assumes all CPUs are brought back online and =
crashes later.<BR>
<BR>
I wonder how long this has been broken. I recall reworking the CPU bringup =
code a lot early during 4.1.0 development... And I didn&#8217;t test S3.<BR>
<BR>
&nbsp;-- Keir<BR>
<BR>
On 19/09/2012 22:07, &quot;Ben Guthro&quot; &lt;<a href=3D"ben@guthro.net">be=
n@guthro.net</a>&gt; wrote:<BR>
<BR>
</SPAN></FONT><BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><=
SPAN STYLE=3D'font-size:11pt'>No hardware debugger just yet - but I've moved t=
o another machine (Lenovo T400 laptop) - and am now seeing the following sta=
ck trace when I resume<BR>
(this is using the tip of the 4.2-testing tree)<BR>
<BR>
It looks like either the vcpu, or the runstate is NULL, at this point in th=
e resume process...<BR>
<BR>
<BR>
(XEN) Finishing wakeup from ACPI S3 state.<BR>
(XEN) Enabling non-boot CPUs =A0...<BR>
(XEN) CPU#1 already initialized!<BR>
(XEN) Stuck ??<BR>
(XEN) Error taking CPU1 up: -5<BR>
[ =A0 38.570054] ACPI: Low-level resume complete<BR>
[ =A0 38.570054] PM: Restoring platform NVS memory<BR>
[ =A0 38.570054] Enabling non-boot CPUs ...<BR>
(XEN) ----[ Xen-4.2.1-pre =A0x86_64 =A0debug=3Dn =A0Tainted: =A0 =A0C ]----<BR>
(XEN) CPU: =A0 =A00<BR>
(XEN) RIP: =A0 =A0e008:[&lt;ffff82c480120585&gt;] vcpu_runstate_get+0xe5/0x130<=
BR>
(XEN) RFLAGS: 0000000000010006 =A0 CONTEXT: hypervisor<BR>
(XEN) rax: 00007d3b7fd17180 =A0 rbx: ffff8300bd2fe000 =A0 rcx: 0000000000000000=
<BR>
(XEN) rdx: ffff08003fc8bd80 =A0 rsi: ffff82c48029fe28 =A0 rdi: ffff8300bd2fe000=
<BR>
(XEN) rbp: ffff82c48029fe28 =A0 rsp: ffff82c48029fdf8 =A0 r8: =A00000000000000008=
<BR>
(XEN) r9: =A000000000000001c0 =A0 r10: ffff82c48021f4a0 =A0 r11: 0000000000000282=
<BR>
(XEN) r12: ffff82c4802e8ee0 =A0 r13: ffff880039762da0 =A0 r14: ffff82c4802d3140=
<BR>
(XEN) r15: fffffffffffffff2 =A0 cr0: 000000008005003b =A0 cr4: 00000000000026f0=
<BR>
(XEN) cr3: 0000000139ee4000 =A0 cr2: 0000000000000060<BR>
(XEN) ds: 0000 =A0 es: 0000 =A0 fs: 0000 =A0 gs: 0000 =A0 ss: e010 =A0 cs: e008<BR>
(XEN) Xen stack trace from rsp=3Dffff82c48029fdf8:<BR>
(XEN) =A0 =A0ffff8300bd2fe000 ffff82c48029ff18 ffff880037481d40 ffff880039762da=
0<BR>
(XEN) =A0 =A00000000000000001 ffff82c480157df4 0000000000000070 ffff82f6016db30=
0<BR>
(XEN) =A0 =A000000000000b6d98 ffff8301355d8000 0000000000000070 ffff82c4801702a=
b<BR>
(XEN) =A0 =A0ffff88003fc8bd80 0000000000000000 0000000000000020 ffff8300bd2fe00=
0<BR>
(XEN) =A0 =A0ffff8301355d8000 ffff880037481d40 ffff880039762da0 000000000000000=
1<BR>
(XEN) =A0 =A00000000000000003 ffff82c4801058df ffff82c48029ff18 ffff82c48011462=
e<BR>
(XEN) =A0 =A00000000000000000 0000000000000000 0000000400000004 ffff82c48029ff1=
8<BR>
(XEN) =A0 =A00000000000000010 ffff8300bd6a0000 ffff8800374819a8 ffff8300bd6a000=
0<BR>
(XEN) =A0 =A0ffff880037481d48 0000000000000001 ffff880039762da0 ffff82c48021428=
8<BR>
(XEN) =A0 =A00000000000000003 0000000000000001 ffff880039762da0 000000000000000=
1<BR>
(XEN) =A0 =A0ffff880037481d48 0000000000000001 0000000000000282 ffff880002dc424=
0<BR>
(XEN) =A0 =A000000000000001c0 00000000000001c0 0000000000000018 ffffffff8100130=
a<BR>
(XEN) =A0 =A0ffff880037481d40 0000000000000001 0000000000000005 000001000000000=
0<BR>
(XEN) =A0 =A0ffffffff8100130a 000000000000e033 0000000000000282 ffff880037481d2=
0<BR>
(XEN) =A0 =A0000000000000e02b 0000000000000000 0000000000000000 000000000000000=
0<BR>
(XEN) =A0 =A00000000000000000 0000000000000000 ffff8300bd6a0000 000000000000000=
0<BR>
(XEN) =A0 =A00000000000000000<BR>
(XEN) Xen call trace:<BR>
(XEN) =A0 =A0[&lt;ffff82c480120585&gt;] vcpu_runstate_get+0xe5/0x130<BR>
(XEN) =A0 =A0[&lt;ffff82c480157df4&gt;] arch_do_vcpu_op+0x134/0x5d0<BR>
(XEN) =A0 =A0[&lt;ffff82c4801702ab&gt;] do_update_descriptor+0x1db/0x220<BR>
(XEN) =A0 =A0[&lt;ffff82c4801058df&gt;] do_vcpu_op+0x6f/0x4a0<BR>
(XEN) =A0 =A0[&lt;ffff82c48011462e&gt;] do_multicall+0x13e/0x330<BR>
(XEN) =A0 =A0[&lt;ffff82c480214288&gt;] syscall_enter+0x88/0x8d<BR>
(XEN) =A0 =A0<BR>
(XEN) Pagetable walk from 0000000000000060:<BR>
(XEN) =A0L4[0x000] =3D 00000001004a5067 0000000000038c9d<BR>
(XEN) =A0L3[0x000] =3D 000000013a703067 0000000000003094<BR>
(XEN) =A0L2[0x000] =3D 0000000000000000 ffffffffffffffff=A0<BR>
(XEN)=A0<BR>
(XEN) ****************************************<BR>
(XEN) Panic on CPU 0:<BR>
(XEN) FATAL PAGE FAULT<BR>
(XEN) [error_code=3D0000]<BR>
(XEN) Faulting linear address: 0000000000000060<BR>
(XEN) ****************************************<BR>
(XEN)=A0<BR>
(XEN) Reboot in five seconds...<BR>
<BR>
<BR>
On Fri, Sep 7, 2012 at 12:06 PM, Ben Guthro &lt;<a href=3D"ben@guthro.net">be=
n@guthro.net</a>&gt; wrote:<BR>
</SPAN></FONT><BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><=
SPAN STYLE=3D'font-size:11pt'>I'll work on getting a JTAG, ICE, or something e=
lse - it is on an<BR>
Intel SDP - so it should have the ports for it.<BR>
<BR>
My current suspicion on this is that the hardware registers are not<BR>
being programmed the same way as they were in 4.0.x<BR>
(Since the &quot;pulsing power button LED&quot; on the laptops, and the beh=
avior<BR>
of the Desktop SDP are now similar)<BR>
<BR>
Once again - I don't have a lot of evidence to back this up - however,<BR>
if I ifdef out the register writes that actually start the low level<BR>
suspend - in<BR>
xen/arch/x86/acpi/power.c =A0acpi_enter_sleep_state() - the rest of the<BR>
suspend process completes as though the machine suspended, and then<BR>
immediately resumed.<BR>
<BR>
In this case - the system seems to be functioning properly.<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
Hack to prevent low level S3 attached.<BR>
<BR>
<BR>
<BR>
On Fri, Sep 7, 2012 at 8:18 AM, Jan Beulich &lt;<a href=3D"JBeulich@suse.com"=
>JBeulich@suse.com</a>&gt; wrote:<BR>
&gt;&gt;&gt;&gt; On 07.09.12 at 13:51, Ben Guthro &lt;<a href=3D"ben@guthro.n=
et">ben@guthro.net</a>&gt; wrote:<BR>
&gt;&gt; However, when I run with console=3Dnone, the observed behavior is ve=
ry<BR>
&gt;&gt; different.<BR>
&gt;&gt; The system seems to go to sleep successfully - but when I press th=
e<BR>
&gt;&gt; power button to wake it up - the power comes on - the fans spin up=
 -<BR>
&gt;&gt; but the system is unresponsive.<BR>
&gt;&gt; No video<BR>
&gt;&gt; No network<BR>
&gt;&gt; keyboard LEDs (Caps,Numlock) do not light up.<BR>
&gt;&gt;<BR>
&gt;&gt;<BR>
&gt;&gt; Alternate debugging strategies welcome.<BR>
&gt;<BR>
&gt; I'm afraid other than being lucky to spot something via code<BR>
&gt; inspection, the only alternative is an ITP/ICE. Maybe Intel folks<BR>
&gt; could help out debugging this if it's reproducible for them.<BR>
&gt;<BR>
&gt; Jan<BR>
&gt;<BR>
</SPAN></FONT></BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial">=
<SPAN STYLE=3D'font-size:11pt'><BR>
<BR>
<HR ALIGN=3DCENTER SIZE=3D"3" WIDTH=3D"95%"></SPAN></FONT><FONT SIZE=3D"2"><FONT FA=
CE=3D"Consolas, Courier New, Courier"><SPAN STYLE=3D'font-size:10pt'>___________=
____________________________________<BR>
Xen-devel mailing list<BR>
<a href=3D"Xen-devel@lists.xen.org">Xen-devel@lists.xen.org</a><BR>
<a href=3D"http://lists.xen.org/xen-devel">http://lists.xen.org/xen-devel</a>=
<BR>
</SPAN></FONT></FONT></BLOCKQUOTE>
</BODY>
</HTML>


--B_3430969998_69237725--




--===============0740956528939052827==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============0740956528939052827==--




From xen-devel-bounces@lists.xen.org Thu Sep 20 06:25:37 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Sep 2012 06:25:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TEaCE-0006C4-6B; Thu, 20 Sep 2012 06:25:10 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1TEaCB-0006By-Px
	for xen-devel@lists.xen.org; Thu, 20 Sep 2012 06:25:08 +0000
Received: from [85.158.143.35:39773] by server-1.bemta-4.messagelabs.com id
	C8/01-05684-3C6BA505; Thu, 20 Sep 2012 06:25:07 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1348122304!16592468!1
X-Originating-IP: [209.85.212.173]
X-SpamReason: No, hits=0.4 required=7.0 tests=MIME_QP_LONG_LINE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11719 invoked from network); 20 Sep 2012 06:25:05 -0000
Received: from mail-wi0-f173.google.com (HELO mail-wi0-f173.google.com)
	(209.85.212.173)
	by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Sep 2012 06:25:05 -0000
Received: by wibhm6 with SMTP id hm6so168096wib.14
	for <xen-devel@lists.xen.org>; Wed, 19 Sep 2012 23:25:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=/6jBOXyFXTdyPE7w2dxatinEzLsKrJnxZo2+pDfa0Wc=;
	b=tyf0rY+lnQM3lvxL04YypO0rUYrFwBheD/TokwYN9dqVXe1exeXA9R2e8elh2c76Sv
	QqtI6b2rra8mssXGhvWEP0NzhQl6+bBr/SlWTHHFvtwv7ZIFKDcudfgcZitNrEw0WRyt
	DDxhMTdCsZsIGXOkY5sK2nIZaLAMWYYwcAW2OHSC64KSGyOozpxmSHrq4qNAGsOxMnJY
	i6mvqR7JJhZr5Nc1bjKk+E1AYasLAmI7iQRk/DeXTX4gqT/v+ae0cQDA7d9UPFXO3kAs
	mJxILOdUf3XWhkpv54JQ25REnezOk3G9qs10IBU75JZTMFCngnZtBMX04y1gCEpS7Dxv
	QFjA==
Received: by 10.216.131.205 with SMTP id m55mr553532wei.49.1348122304733;
	Wed, 19 Sep 2012 23:25:04 -0700 (PDT)
Received: from [192.168.1.69] (host86-167-82-156.range86-167.btcentralplus.com.
	[86.167.82.156])
	by mx.google.com with ESMTPS id l5sm9055559wix.5.2012.09.19.23.25.02
	(version=SSLv3 cipher=OTHER); Wed, 19 Sep 2012 23:25:04 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Thu, 20 Sep 2012 07:24:58 +0100
From: Keir Fraser <keir.xen@gmail.com>
To: Ben Guthro <ben@guthro.net>,
	Jan Beulich <JBeulich@suse.com>
Message-ID: <CC80754A.3F386%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] Xen4.2 S3 regression?
Thread-Index: Ac2W9wUV5d1C113vwUiCnR/khSsTCAAAaMGw
In-Reply-To: <CC80728B.3F362%keir.xen@gmail.com>
Mime-version: 1.0
Cc: xen-devel <xen-devel@lists.xen.org>, john.baboval@citrix.com,
	Thomas Goetz <thomas.goetz@citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] Xen4.2 S3 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="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 20/09/2012 07:13, "Keir Fraser" <keir.xen@gmail.com> wrote:

> CPU#1 got stuck in loop in cpu_init() as it appears to be =8Calready
> initialised=B9 in cpu_initialized bitmap. CPU#0 detects it is stuck and c=
arries
> on, but the resume code assumes all CPUs are brought back online and cras=
hes
> later.
> =

> I wonder how long this has been broken. I recall reworking the CPU bringup
> code a lot early during 4.1.0 development... And I didn=B9t test S3.
> =

>  -- Keir

However, I did test CPU hotplug a lot, and S3 uses the hotplug logic to take
down and bring up CPUs. So I don't think I can have broken this.

Are you able to hotplug physical CPUs from dom0 using the
tools/misc/xen-hptool utility? If not, at least this might be a friendlier
test method and environment than a full S3.

 -- Keir

> On 19/09/2012 22:07, "Ben Guthro" <ben@guthro.net> wrote:
> =

>> No hardware debugger just yet - but I've moved to another machine (Lenovo
>> T400 laptop) - and am now seeing the following stack trace when I resume
>> (this is using the tip of the 4.2-testing tree)
>> =

>> It looks like either the vcpu, or the runstate is NULL, at this point in=
 the
>> resume process...
>> =

>> =

>> (XEN) Finishing wakeup from ACPI S3 state.
>> (XEN) Enabling non-boot CPUs =A0...
>> (XEN) CPU#1 already initialized!
>> (XEN) Stuck ??
>> (XEN) Error taking CPU1 up: -5
>> [ =A0 38.570054] ACPI: Low-level resume complete
>> [ =A0 38.570054] PM: Restoring platform NVS memory
>> [ =A0 38.570054] Enabling non-boot CPUs ...
>> (XEN) ----[ Xen-4.2.1-pre =A0x86_64 =A0debug=3Dn =A0Tainted: =A0 =A0C ]-=
---
>> (XEN) CPU: =A0 =A00
>> (XEN) RIP: =A0 =A0e008:[<ffff82c480120585>] vcpu_runstate_get+0xe5/0x130
>> (XEN) RFLAGS: 0000000000010006 =A0 CONTEXT: hypervisor
>> (XEN) rax: 00007d3b7fd17180 =A0 rbx: ffff8300bd2fe000 =A0 rcx: 000000000=
0000000
>> (XEN) rdx: ffff08003fc8bd80 =A0 rsi: ffff82c48029fe28 =A0 rdi: ffff8300b=
d2fe000
>> (XEN) rbp: ffff82c48029fe28 =A0 rsp: ffff82c48029fdf8 =A0 r8: =A00000000=
000000008
>> (XEN) r9: =A000000000000001c0 =A0 r10: ffff82c48021f4a0 =A0 r11: 0000000=
000000282
>> (XEN) r12: ffff82c4802e8ee0 =A0 r13: ffff880039762da0 =A0 r14: ffff82c48=
02d3140
>> (XEN) r15: fffffffffffffff2 =A0 cr0: 000000008005003b =A0 cr4: 000000000=
00026f0
>> (XEN) cr3: 0000000139ee4000 =A0 cr2: 0000000000000060
>> (XEN) ds: 0000 =A0 es: 0000 =A0 fs: 0000 =A0 gs: 0000 =A0 ss: e010 =A0 c=
s: e008
>> (XEN) Xen stack trace from rsp=3Dffff82c48029fdf8:
>> (XEN) =A0 =A0ffff8300bd2fe000 ffff82c48029ff18 ffff880037481d40 ffff8800=
39762da0
>> (XEN) =A0 =A00000000000000001 ffff82c480157df4 0000000000000070 ffff82f6=
016db300
>> (XEN) =A0 =A000000000000b6d98 ffff8301355d8000 0000000000000070 ffff82c4=
801702ab
>> (XEN) =A0 =A0ffff88003fc8bd80 0000000000000000 0000000000000020 ffff8300=
bd2fe000
>> (XEN) =A0 =A0ffff8301355d8000 ffff880037481d40 ffff880039762da0 00000000=
00000001
>> (XEN) =A0 =A00000000000000003 ffff82c4801058df ffff82c48029ff18 ffff82c4=
8011462e
>> (XEN) =A0 =A00000000000000000 0000000000000000 0000000400000004 ffff82c4=
8029ff18
>> (XEN) =A0 =A00000000000000010 ffff8300bd6a0000 ffff8800374819a8 ffff8300=
bd6a0000
>> (XEN) =A0 =A0ffff880037481d48 0000000000000001 ffff880039762da0 ffff82c4=
80214288
>> (XEN) =A0 =A00000000000000003 0000000000000001 ffff880039762da0 00000000=
00000001
>> (XEN) =A0 =A0ffff880037481d48 0000000000000001 0000000000000282 ffff8800=
02dc4240
>> (XEN) =A0 =A000000000000001c0 00000000000001c0 0000000000000018 ffffffff=
8100130a
>> (XEN) =A0 =A0ffff880037481d40 0000000000000001 0000000000000005 00000100=
00000000
>> (XEN) =A0 =A0ffffffff8100130a 000000000000e033 0000000000000282 ffff8800=
37481d20
>> (XEN) =A0 =A0000000000000e02b 0000000000000000 0000000000000000 00000000=
00000000
>> (XEN) =A0 =A00000000000000000 0000000000000000 ffff8300bd6a0000 00000000=
00000000
>> (XEN) =A0 =A00000000000000000
>> (XEN) Xen call trace:
>> (XEN) =A0 =A0[<ffff82c480120585>] vcpu_runstate_get+0xe5/0x130
>> (XEN) =A0 =A0[<ffff82c480157df4>] arch_do_vcpu_op+0x134/0x5d0
>> (XEN) =A0 =A0[<ffff82c4801702ab>] do_update_descriptor+0x1db/0x220
>> (XEN) =A0 =A0[<ffff82c4801058df>] do_vcpu_op+0x6f/0x4a0
>> (XEN) =A0 =A0[<ffff82c48011462e>] do_multicall+0x13e/0x330
>> (XEN) =A0 =A0[<ffff82c480214288>] syscall_enter+0x88/0x8d
>> (XEN) =A0 =A0
>> (XEN) Pagetable walk from 0000000000000060:
>> (XEN) =A0L4[0x000] =3D 00000001004a5067 0000000000038c9d
>> (XEN) =A0L3[0x000] =3D 000000013a703067 0000000000003094
>> (XEN) =A0L2[0x000] =3D 0000000000000000 ffffffffffffffff=A0
>> (XEN)=A0
>> (XEN) ****************************************
>> (XEN) Panic on CPU 0:
>> (XEN) FATAL PAGE FAULT
>> (XEN) [error_code=3D0000]
>> (XEN) Faulting linear address: 0000000000000060
>> (XEN) ****************************************
>> (XEN)=A0
>> (XEN) Reboot in five seconds...
>> =

>> =

>> On Fri, Sep 7, 2012 at 12:06 PM, Ben Guthro <ben@guthro.net> wrote:
>>> I'll work on getting a JTAG, ICE, or something else - it is on an
>>> Intel SDP - so it should have the ports for it.
>>> =

>>> My current suspicion on this is that the hardware registers are not
>>> being programmed the same way as they were in 4.0.x
>>> (Since the "pulsing power button LED" on the laptops, and the behavior
>>> of the Desktop SDP are now similar)
>>> =

>>> Once again - I don't have a lot of evidence to back this up - however,
>>> if I ifdef out the register writes that actually start the low level
>>> suspend - in
>>> xen/arch/x86/acpi/power.c =A0acpi_enter_sleep_state() - the rest of the
>>> suspend process completes as though the machine suspended, and then
>>> immediately resumed.
>>> =

>>> In this case - the system seems to be functioning properly.
>>> =

>>> =

>>> =

>>> =

>>> =

>>> Hack to prevent low level S3 attached.
>>> =

>>> =

>>> =

>>> On Fri, Sep 7, 2012 at 8:18 AM, Jan Beulich <JBeulich@suse.com> wrote:
>>>>>>> On 07.09.12 at 13:51, Ben Guthro <ben@guthro.net> wrote:
>>>>> However, when I run with console=3Dnone, the observed behavior is very
>>>>> different.
>>>>> The system seems to go to sleep successfully - but when I press the
>>>>> power button to wake it up - the power comes on - the fans spin up -
>>>>> but the system is unresponsive.
>>>>> No video
>>>>> No network
>>>>> keyboard LEDs (Caps,Numlock) do not light up.
>>>>> =

>>>>> =

>>>>> Alternate debugging strategies welcome.
>>>> =

>>>> I'm afraid other than being lucky to spot something via code
>>>> inspection, the only alternative is an ITP/ICE. Maybe Intel folks
>>>> could help out debugging this if it's reproducible for them.
>>>> =

>>>> 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 Sep 20 06:25:37 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Sep 2012 06:25:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TEaCE-0006C4-6B; Thu, 20 Sep 2012 06:25:10 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1TEaCB-0006By-Px
	for xen-devel@lists.xen.org; Thu, 20 Sep 2012 06:25:08 +0000
Received: from [85.158.143.35:39773] by server-1.bemta-4.messagelabs.com id
	C8/01-05684-3C6BA505; Thu, 20 Sep 2012 06:25:07 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1348122304!16592468!1
X-Originating-IP: [209.85.212.173]
X-SpamReason: No, hits=0.4 required=7.0 tests=MIME_QP_LONG_LINE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11719 invoked from network); 20 Sep 2012 06:25:05 -0000
Received: from mail-wi0-f173.google.com (HELO mail-wi0-f173.google.com)
	(209.85.212.173)
	by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Sep 2012 06:25:05 -0000
Received: by wibhm6 with SMTP id hm6so168096wib.14
	for <xen-devel@lists.xen.org>; Wed, 19 Sep 2012 23:25:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=/6jBOXyFXTdyPE7w2dxatinEzLsKrJnxZo2+pDfa0Wc=;
	b=tyf0rY+lnQM3lvxL04YypO0rUYrFwBheD/TokwYN9dqVXe1exeXA9R2e8elh2c76Sv
	QqtI6b2rra8mssXGhvWEP0NzhQl6+bBr/SlWTHHFvtwv7ZIFKDcudfgcZitNrEw0WRyt
	DDxhMTdCsZsIGXOkY5sK2nIZaLAMWYYwcAW2OHSC64KSGyOozpxmSHrq4qNAGsOxMnJY
	i6mvqR7JJhZr5Nc1bjKk+E1AYasLAmI7iQRk/DeXTX4gqT/v+ae0cQDA7d9UPFXO3kAs
	mJxILOdUf3XWhkpv54JQ25REnezOk3G9qs10IBU75JZTMFCngnZtBMX04y1gCEpS7Dxv
	QFjA==
Received: by 10.216.131.205 with SMTP id m55mr553532wei.49.1348122304733;
	Wed, 19 Sep 2012 23:25:04 -0700 (PDT)
Received: from [192.168.1.69] (host86-167-82-156.range86-167.btcentralplus.com.
	[86.167.82.156])
	by mx.google.com with ESMTPS id l5sm9055559wix.5.2012.09.19.23.25.02
	(version=SSLv3 cipher=OTHER); Wed, 19 Sep 2012 23:25:04 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Thu, 20 Sep 2012 07:24:58 +0100
From: Keir Fraser <keir.xen@gmail.com>
To: Ben Guthro <ben@guthro.net>,
	Jan Beulich <JBeulich@suse.com>
Message-ID: <CC80754A.3F386%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] Xen4.2 S3 regression?
Thread-Index: Ac2W9wUV5d1C113vwUiCnR/khSsTCAAAaMGw
In-Reply-To: <CC80728B.3F362%keir.xen@gmail.com>
Mime-version: 1.0
Cc: xen-devel <xen-devel@lists.xen.org>, john.baboval@citrix.com,
	Thomas Goetz <thomas.goetz@citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] Xen4.2 S3 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="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 20/09/2012 07:13, "Keir Fraser" <keir.xen@gmail.com> wrote:

> CPU#1 got stuck in loop in cpu_init() as it appears to be =8Calready
> initialised=B9 in cpu_initialized bitmap. CPU#0 detects it is stuck and c=
arries
> on, but the resume code assumes all CPUs are brought back online and cras=
hes
> later.
> =

> I wonder how long this has been broken. I recall reworking the CPU bringup
> code a lot early during 4.1.0 development... And I didn=B9t test S3.
> =

>  -- Keir

However, I did test CPU hotplug a lot, and S3 uses the hotplug logic to take
down and bring up CPUs. So I don't think I can have broken this.

Are you able to hotplug physical CPUs from dom0 using the
tools/misc/xen-hptool utility? If not, at least this might be a friendlier
test method and environment than a full S3.

 -- Keir

> On 19/09/2012 22:07, "Ben Guthro" <ben@guthro.net> wrote:
> =

>> No hardware debugger just yet - but I've moved to another machine (Lenovo
>> T400 laptop) - and am now seeing the following stack trace when I resume
>> (this is using the tip of the 4.2-testing tree)
>> =

>> It looks like either the vcpu, or the runstate is NULL, at this point in=
 the
>> resume process...
>> =

>> =

>> (XEN) Finishing wakeup from ACPI S3 state.
>> (XEN) Enabling non-boot CPUs =A0...
>> (XEN) CPU#1 already initialized!
>> (XEN) Stuck ??
>> (XEN) Error taking CPU1 up: -5
>> [ =A0 38.570054] ACPI: Low-level resume complete
>> [ =A0 38.570054] PM: Restoring platform NVS memory
>> [ =A0 38.570054] Enabling non-boot CPUs ...
>> (XEN) ----[ Xen-4.2.1-pre =A0x86_64 =A0debug=3Dn =A0Tainted: =A0 =A0C ]-=
---
>> (XEN) CPU: =A0 =A00
>> (XEN) RIP: =A0 =A0e008:[<ffff82c480120585>] vcpu_runstate_get+0xe5/0x130
>> (XEN) RFLAGS: 0000000000010006 =A0 CONTEXT: hypervisor
>> (XEN) rax: 00007d3b7fd17180 =A0 rbx: ffff8300bd2fe000 =A0 rcx: 000000000=
0000000
>> (XEN) rdx: ffff08003fc8bd80 =A0 rsi: ffff82c48029fe28 =A0 rdi: ffff8300b=
d2fe000
>> (XEN) rbp: ffff82c48029fe28 =A0 rsp: ffff82c48029fdf8 =A0 r8: =A00000000=
000000008
>> (XEN) r9: =A000000000000001c0 =A0 r10: ffff82c48021f4a0 =A0 r11: 0000000=
000000282
>> (XEN) r12: ffff82c4802e8ee0 =A0 r13: ffff880039762da0 =A0 r14: ffff82c48=
02d3140
>> (XEN) r15: fffffffffffffff2 =A0 cr0: 000000008005003b =A0 cr4: 000000000=
00026f0
>> (XEN) cr3: 0000000139ee4000 =A0 cr2: 0000000000000060
>> (XEN) ds: 0000 =A0 es: 0000 =A0 fs: 0000 =A0 gs: 0000 =A0 ss: e010 =A0 c=
s: e008
>> (XEN) Xen stack trace from rsp=3Dffff82c48029fdf8:
>> (XEN) =A0 =A0ffff8300bd2fe000 ffff82c48029ff18 ffff880037481d40 ffff8800=
39762da0
>> (XEN) =A0 =A00000000000000001 ffff82c480157df4 0000000000000070 ffff82f6=
016db300
>> (XEN) =A0 =A000000000000b6d98 ffff8301355d8000 0000000000000070 ffff82c4=
801702ab
>> (XEN) =A0 =A0ffff88003fc8bd80 0000000000000000 0000000000000020 ffff8300=
bd2fe000
>> (XEN) =A0 =A0ffff8301355d8000 ffff880037481d40 ffff880039762da0 00000000=
00000001
>> (XEN) =A0 =A00000000000000003 ffff82c4801058df ffff82c48029ff18 ffff82c4=
8011462e
>> (XEN) =A0 =A00000000000000000 0000000000000000 0000000400000004 ffff82c4=
8029ff18
>> (XEN) =A0 =A00000000000000010 ffff8300bd6a0000 ffff8800374819a8 ffff8300=
bd6a0000
>> (XEN) =A0 =A0ffff880037481d48 0000000000000001 ffff880039762da0 ffff82c4=
80214288
>> (XEN) =A0 =A00000000000000003 0000000000000001 ffff880039762da0 00000000=
00000001
>> (XEN) =A0 =A0ffff880037481d48 0000000000000001 0000000000000282 ffff8800=
02dc4240
>> (XEN) =A0 =A000000000000001c0 00000000000001c0 0000000000000018 ffffffff=
8100130a
>> (XEN) =A0 =A0ffff880037481d40 0000000000000001 0000000000000005 00000100=
00000000
>> (XEN) =A0 =A0ffffffff8100130a 000000000000e033 0000000000000282 ffff8800=
37481d20
>> (XEN) =A0 =A0000000000000e02b 0000000000000000 0000000000000000 00000000=
00000000
>> (XEN) =A0 =A00000000000000000 0000000000000000 ffff8300bd6a0000 00000000=
00000000
>> (XEN) =A0 =A00000000000000000
>> (XEN) Xen call trace:
>> (XEN) =A0 =A0[<ffff82c480120585>] vcpu_runstate_get+0xe5/0x130
>> (XEN) =A0 =A0[<ffff82c480157df4>] arch_do_vcpu_op+0x134/0x5d0
>> (XEN) =A0 =A0[<ffff82c4801702ab>] do_update_descriptor+0x1db/0x220
>> (XEN) =A0 =A0[<ffff82c4801058df>] do_vcpu_op+0x6f/0x4a0
>> (XEN) =A0 =A0[<ffff82c48011462e>] do_multicall+0x13e/0x330
>> (XEN) =A0 =A0[<ffff82c480214288>] syscall_enter+0x88/0x8d
>> (XEN) =A0 =A0
>> (XEN) Pagetable walk from 0000000000000060:
>> (XEN) =A0L4[0x000] =3D 00000001004a5067 0000000000038c9d
>> (XEN) =A0L3[0x000] =3D 000000013a703067 0000000000003094
>> (XEN) =A0L2[0x000] =3D 0000000000000000 ffffffffffffffff=A0
>> (XEN)=A0
>> (XEN) ****************************************
>> (XEN) Panic on CPU 0:
>> (XEN) FATAL PAGE FAULT
>> (XEN) [error_code=3D0000]
>> (XEN) Faulting linear address: 0000000000000060
>> (XEN) ****************************************
>> (XEN)=A0
>> (XEN) Reboot in five seconds...
>> =

>> =

>> On Fri, Sep 7, 2012 at 12:06 PM, Ben Guthro <ben@guthro.net> wrote:
>>> I'll work on getting a JTAG, ICE, or something else - it is on an
>>> Intel SDP - so it should have the ports for it.
>>> =

>>> My current suspicion on this is that the hardware registers are not
>>> being programmed the same way as they were in 4.0.x
>>> (Since the "pulsing power button LED" on the laptops, and the behavior
>>> of the Desktop SDP are now similar)
>>> =

>>> Once again - I don't have a lot of evidence to back this up - however,
>>> if I ifdef out the register writes that actually start the low level
>>> suspend - in
>>> xen/arch/x86/acpi/power.c =A0acpi_enter_sleep_state() - the rest of the
>>> suspend process completes as though the machine suspended, and then
>>> immediately resumed.
>>> =

>>> In this case - the system seems to be functioning properly.
>>> =

>>> =

>>> =

>>> =

>>> =

>>> Hack to prevent low level S3 attached.
>>> =

>>> =

>>> =

>>> On Fri, Sep 7, 2012 at 8:18 AM, Jan Beulich <JBeulich@suse.com> wrote:
>>>>>>> On 07.09.12 at 13:51, Ben Guthro <ben@guthro.net> wrote:
>>>>> However, when I run with console=3Dnone, the observed behavior is very
>>>>> different.
>>>>> The system seems to go to sleep successfully - but when I press the
>>>>> power button to wake it up - the power comes on - the fans spin up -
>>>>> but the system is unresponsive.
>>>>> No video
>>>>> No network
>>>>> keyboard LEDs (Caps,Numlock) do not light up.
>>>>> =

>>>>> =

>>>>> Alternate debugging strategies welcome.
>>>> =

>>>> I'm afraid other than being lucky to spot something via code
>>>> inspection, the only alternative is an ITP/ICE. Maybe Intel folks
>>>> could help out debugging this if it's reproducible for them.
>>>> =

>>>> 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 Sep 20 06:52:35 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Sep 2012 06:52: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 1TEacP-0006i2-Dr; Thu, 20 Sep 2012 06:52:13 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1TEacO-0006hv-Cg
	for xen-devel@lists.xen.org; Thu, 20 Sep 2012 06:52:12 +0000
Received: from [85.158.139.211:11777] by server-2.bemta-5.messagelabs.com id
	4F/F7-11456-B1DBA505; Thu, 20 Sep 2012 06:52:11 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-4.tower-206.messagelabs.com!1348123930!19279892!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21344 invoked from network); 20 Sep 2012 06:52:10 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-4.tower-206.messagelabs.com with SMTP;
	20 Sep 2012 06:52:10 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 20 Sep 2012 07:52:09 +0100
Message-Id: <505AD938020000780009C7AB@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 20 Sep 2012 07:52:08 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Daniel De Graaf" <dgdegra@tycho.nsa.gov>
References: <50588084.3090300@tycho.nsa.gov>
	<1348075408-14660-1-git-send-email-dgdegra@tycho.nsa.gov>
In-Reply-To: <1348075408-14660-1-git-send-email-dgdegra@tycho.nsa.gov>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Tim Deegan <tim@xen.org>, Keir Fraser <keir@xen.org>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 19/23 v2] arch/x86: check remote MMIO remap
 permissions
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.09.12 at 19:23, Daniel De Graaf <dgdegra@tycho.nsa.gov> wrote:

This looks good now to me, apart from minor (cosmetic) issues:

> --- a/xen/arch/x86/mm.c
> +++ b/xen/arch/x86/mm.c
> @@ -754,6 +754,19 @@ get_page_from_l1e(
>              return -EINVAL;
>          }
>  
> +        if ( pg_owner != l1e_owner &&
> +             !iomem_access_permitted(l1e_owner, mfn, mfn) )
> +        {
> +            if ( mfn != (PADDR_MASK >> PAGE_SHIFT) ) /* INVALID_MFN? */
> +            {
> +                MEM_LOG("Domain %u attempted to map I/O space %08lx in domain %u to domain %u",

I'd prefer each of the "[Dd]omain %u" references to be
"[Dd]om%d" instead - no need for excessively long log messages.

> +                        curr->domain->domain_id, mfn, pg_owner->domain_id,
> +						l1e_owner->domain_id);

Indentation wants to be fixed here.

Ack with those changes (but aiui the patch isn't really tied to be
applied in order - if that's right, i.e. I don't overlook some subtlety,
I could as well commit it right away; I would even consider this a
backporting candidate).

Jan

> +                return -EPERM;
> +            }
> +            return -EINVAL;
> +        }
> +
>          if ( !(l1f & _PAGE_RW) ||
>               !rangeset_contains_singleton(mmio_ro_ranges, mfn) )
>              return 0;
> -- 
> 1.7.11.4




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 20 06:52:35 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Sep 2012 06:52: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 1TEacP-0006i2-Dr; Thu, 20 Sep 2012 06:52:13 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1TEacO-0006hv-Cg
	for xen-devel@lists.xen.org; Thu, 20 Sep 2012 06:52:12 +0000
Received: from [85.158.139.211:11777] by server-2.bemta-5.messagelabs.com id
	4F/F7-11456-B1DBA505; Thu, 20 Sep 2012 06:52:11 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-4.tower-206.messagelabs.com!1348123930!19279892!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21344 invoked from network); 20 Sep 2012 06:52:10 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-4.tower-206.messagelabs.com with SMTP;
	20 Sep 2012 06:52:10 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 20 Sep 2012 07:52:09 +0100
Message-Id: <505AD938020000780009C7AB@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 20 Sep 2012 07:52:08 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Daniel De Graaf" <dgdegra@tycho.nsa.gov>
References: <50588084.3090300@tycho.nsa.gov>
	<1348075408-14660-1-git-send-email-dgdegra@tycho.nsa.gov>
In-Reply-To: <1348075408-14660-1-git-send-email-dgdegra@tycho.nsa.gov>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Tim Deegan <tim@xen.org>, Keir Fraser <keir@xen.org>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 19/23 v2] arch/x86: check remote MMIO remap
 permissions
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.09.12 at 19:23, Daniel De Graaf <dgdegra@tycho.nsa.gov> wrote:

This looks good now to me, apart from minor (cosmetic) issues:

> --- a/xen/arch/x86/mm.c
> +++ b/xen/arch/x86/mm.c
> @@ -754,6 +754,19 @@ get_page_from_l1e(
>              return -EINVAL;
>          }
>  
> +        if ( pg_owner != l1e_owner &&
> +             !iomem_access_permitted(l1e_owner, mfn, mfn) )
> +        {
> +            if ( mfn != (PADDR_MASK >> PAGE_SHIFT) ) /* INVALID_MFN? */
> +            {
> +                MEM_LOG("Domain %u attempted to map I/O space %08lx in domain %u to domain %u",

I'd prefer each of the "[Dd]omain %u" references to be
"[Dd]om%d" instead - no need for excessively long log messages.

> +                        curr->domain->domain_id, mfn, pg_owner->domain_id,
> +						l1e_owner->domain_id);

Indentation wants to be fixed here.

Ack with those changes (but aiui the patch isn't really tied to be
applied in order - if that's right, i.e. I don't overlook some subtlety,
I could as well commit it right away; I would even consider this a
backporting candidate).

Jan

> +                return -EPERM;
> +            }
> +            return -EINVAL;
> +        }
> +
>          if ( !(l1f & _PAGE_RW) ||
>               !rangeset_contains_singleton(mmio_ro_ranges, mfn) )
>              return 0;
> -- 
> 1.7.11.4




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 20 07:03:37 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Sep 2012 07:03:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TEan6-00077B-1p; Thu, 20 Sep 2012 07:03: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 1TEan4-000774-Db
	for xen-devel@lists.xen.org; Thu, 20 Sep 2012 07:03:14 +0000
Received: from [85.158.138.51:28614] by server-1.bemta-3.messagelabs.com id
	C5/0A-05884-1BFBA505; Thu, 20 Sep 2012 07:03:13 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1348124592!23238690!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13249 invoked from network); 20 Sep 2012 07:03:13 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-6.tower-174.messagelabs.com with SMTP;
	20 Sep 2012 07:03:13 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 20 Sep 2012 08:03:12 +0100
Message-Id: <505ADBCF020000780009C7BE@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 20 Sep 2012 08:03:11 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "George Dunlap" <George.Dunlap@eu.citrix.com>
References: <CAFLBxZYtmJ_bKFb90r45=C4Pq1-oe5Fy=eygSsQf4BcGj3EqGA@mail.gmail.com>
In-Reply-To: <CAFLBxZYtmJ_bKFb90r45=C4Pq1-oe5Fy=eygSsQf4BcGj3EqGA@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Xen 4.3 development 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 19.09.12 at 18:58, George Dunlap <George.Dunlap@eu.citrix.com> wrote:
> = Timeline =
> 
> We are planning on a 9-month release cycle.  Based on that, below are
> our estimated dates:
> * Feature Freeze: 1 March, 2013
> * First RC: 15 April 2013
> * Release: 1 June 2013

While it's only slightly over two weeks - didn't we agree to count
from the release date (rather than the intended one)?

> * Persistent grants
>   owner: @citrix
>   status: ?

Isn't that a guest side only thing (i.e. not really to be tracked
here)? Or does that mean migrating active grants?

> * Multi-page blk rings
>  - blkback in kernel (konrad@oracle, ?@intel)

This part certainly is a guest side only thing (apart from the
interface definition living in the our tree).

>  - qemu blkback
>   status: ?
> 
> * Multi-page net protocol
>   owner: ?
>   status: ?
>   expand the network ring protocol to allow multiple pages for
>   increased throughput

Same here.

> * Scalability: 16TiB of RAM
>   owner: jan@suse
>   status: ?

Not started.

> * Linux console improvements
>   owner: jan@suse
>   -EHCI debug port (done, to be submitted)

Committed.

>   -xHCI debug port

This one needs an owner having access to suitable hardware _and_
knowledge of the protocol since, other than for EHCI, there isn't
even a reference implementation (e.g. in Linux) to clone from. I'd
therefore rather consider this nice-to-have than a firm plan to have
such functionality.

>   -Firewire

Largely same here - while I'm not suffering from lack of hardware
(apart from - afaict - cables), I've never done anything with
Firewire, and hence would consider this one as well nice-to-have
only.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 20 07:03:37 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Sep 2012 07:03:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TEan6-00077B-1p; Thu, 20 Sep 2012 07:03: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 1TEan4-000774-Db
	for xen-devel@lists.xen.org; Thu, 20 Sep 2012 07:03:14 +0000
Received: from [85.158.138.51:28614] by server-1.bemta-3.messagelabs.com id
	C5/0A-05884-1BFBA505; Thu, 20 Sep 2012 07:03:13 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1348124592!23238690!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13249 invoked from network); 20 Sep 2012 07:03:13 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-6.tower-174.messagelabs.com with SMTP;
	20 Sep 2012 07:03:13 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 20 Sep 2012 08:03:12 +0100
Message-Id: <505ADBCF020000780009C7BE@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 20 Sep 2012 08:03:11 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "George Dunlap" <George.Dunlap@eu.citrix.com>
References: <CAFLBxZYtmJ_bKFb90r45=C4Pq1-oe5Fy=eygSsQf4BcGj3EqGA@mail.gmail.com>
In-Reply-To: <CAFLBxZYtmJ_bKFb90r45=C4Pq1-oe5Fy=eygSsQf4BcGj3EqGA@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Xen 4.3 development 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 19.09.12 at 18:58, George Dunlap <George.Dunlap@eu.citrix.com> wrote:
> = Timeline =
> 
> We are planning on a 9-month release cycle.  Based on that, below are
> our estimated dates:
> * Feature Freeze: 1 March, 2013
> * First RC: 15 April 2013
> * Release: 1 June 2013

While it's only slightly over two weeks - didn't we agree to count
from the release date (rather than the intended one)?

> * Persistent grants
>   owner: @citrix
>   status: ?

Isn't that a guest side only thing (i.e. not really to be tracked
here)? Or does that mean migrating active grants?

> * Multi-page blk rings
>  - blkback in kernel (konrad@oracle, ?@intel)

This part certainly is a guest side only thing (apart from the
interface definition living in the our tree).

>  - qemu blkback
>   status: ?
> 
> * Multi-page net protocol
>   owner: ?
>   status: ?
>   expand the network ring protocol to allow multiple pages for
>   increased throughput

Same here.

> * Scalability: 16TiB of RAM
>   owner: jan@suse
>   status: ?

Not started.

> * Linux console improvements
>   owner: jan@suse
>   -EHCI debug port (done, to be submitted)

Committed.

>   -xHCI debug port

This one needs an owner having access to suitable hardware _and_
knowledge of the protocol since, other than for EHCI, there isn't
even a reference implementation (e.g. in Linux) to clone from. I'd
therefore rather consider this nice-to-have than a firm plan to have
such functionality.

>   -Firewire

Largely same here - while I'm not suffering from lack of hardware
(apart from - afaict - cables), I've never done anything with
Firewire, and hence would consider this one as well nice-to-have
only.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 20 07:08:31 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Sep 2012 07: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 1TEarp-0007G3-PH; Thu, 20 Sep 2012 07:08: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 1TEaro-0007Fy-Rw
	for Xen-devel@lists.xensource.com; Thu, 20 Sep 2012 07:08:09 +0000
Received: from [85.158.137.99:7664] by server-11.bemta-3.messagelabs.com id
	47/0E-30250-8D0CA505; Thu, 20 Sep 2012 07:08:08 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-12.tower-217.messagelabs.com!1348124887!15276912!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18662 invoked from network); 20 Sep 2012 07:08:07 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-12.tower-217.messagelabs.com with SMTP;
	20 Sep 2012 07:08:07 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 20 Sep 2012 08:08:06 +0100
Message-Id: <505ADCF5020000780009C7C8@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 20 Sep 2012 08:08:05 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Mukesh Rathor" <mukesh.rathor@oracle.com>
References: <20120919122907.1e72704b@mantra.us.oracle.com>
	<20120919151319.2fbea71c@mantra.us.oracle.com>
In-Reply-To: <20120919151319.2fbea71c@mantra.us.oracle.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@eu.citrix.com" <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] PVH: iopl
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.09.12 at 00:13, Mukesh Rathor <mukesh.rathor@oracle.com> wrote:
> On Wed, 19 Sep 2012 12:29:07 -0700
> Mukesh Rathor <mukesh.rathor@oracle.com> wrote:
> 
>> 
>> I noticed anamoly in my code the way IOPL is set. For vcpu 0, its done
>> via
>> 
>>         set_iopl.iopl = 1;
>> 	rc = HYPERVISOR_physdev_op(PHYSDEVOP_set_iopl, &set_iopl);
>> 
>> in xen_start_kernel() in enlighten.c. But, for non boot vcpus, its
>> done via eflags in cpu_initialize_context():
>>         ctxt->user_regs.eflags = 0x1000; /* IOPL_RING1 */
>> 
>> Since I am running in HVM container, IO ops cause vmexit. I can just
>> check eflags at that point for guest IOPL. So I am thinking of just
>> using eflags and not doing the hcall.  It will also reduce the need
>> for another field in the struct pv_vcpu for me. 
>> 
>> (JFYI: EXIT_REASON_IO_INSTRUCTION cause emulate_privileged_op() to be
>> called).
> 
> So, I got rid of calling hcall to set iopl. The guest just manages
> via eflags. Then upon vmexit:
> 
> {
>     int curr_lvl;
>     int requested = (regs->rflags >> 12) & 3;
>     read_vmcs_selectors(regs);
>     curr_lvl = regs->cs & 3;
> 
>     if (requested >= curr_lvl && emulate_privileged_op(regs))
>         return success;
> 
>     hvm_inject_hw_exception(TRAP_gp_fault, regs->error_code);
> }
> 
> I tested it out, and seems fine.

And that's also how I would expect it to be. Even more - just like
the ring not needing to be 1, you shouldn't need to fiddle
artificially with IOPL. Just leave it at zero for the kernel, and
adjust between 0 and 3 for user mode based on the respective
syscalls).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 20 07:08:31 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Sep 2012 07: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 1TEarp-0007G3-PH; Thu, 20 Sep 2012 07:08: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 1TEaro-0007Fy-Rw
	for Xen-devel@lists.xensource.com; Thu, 20 Sep 2012 07:08:09 +0000
Received: from [85.158.137.99:7664] by server-11.bemta-3.messagelabs.com id
	47/0E-30250-8D0CA505; Thu, 20 Sep 2012 07:08:08 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-12.tower-217.messagelabs.com!1348124887!15276912!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18662 invoked from network); 20 Sep 2012 07:08:07 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-12.tower-217.messagelabs.com with SMTP;
	20 Sep 2012 07:08:07 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 20 Sep 2012 08:08:06 +0100
Message-Id: <505ADCF5020000780009C7C8@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 20 Sep 2012 08:08:05 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Mukesh Rathor" <mukesh.rathor@oracle.com>
References: <20120919122907.1e72704b@mantra.us.oracle.com>
	<20120919151319.2fbea71c@mantra.us.oracle.com>
In-Reply-To: <20120919151319.2fbea71c@mantra.us.oracle.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@eu.citrix.com" <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] PVH: iopl
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.09.12 at 00:13, Mukesh Rathor <mukesh.rathor@oracle.com> wrote:
> On Wed, 19 Sep 2012 12:29:07 -0700
> Mukesh Rathor <mukesh.rathor@oracle.com> wrote:
> 
>> 
>> I noticed anamoly in my code the way IOPL is set. For vcpu 0, its done
>> via
>> 
>>         set_iopl.iopl = 1;
>> 	rc = HYPERVISOR_physdev_op(PHYSDEVOP_set_iopl, &set_iopl);
>> 
>> in xen_start_kernel() in enlighten.c. But, for non boot vcpus, its
>> done via eflags in cpu_initialize_context():
>>         ctxt->user_regs.eflags = 0x1000; /* IOPL_RING1 */
>> 
>> Since I am running in HVM container, IO ops cause vmexit. I can just
>> check eflags at that point for guest IOPL. So I am thinking of just
>> using eflags and not doing the hcall.  It will also reduce the need
>> for another field in the struct pv_vcpu for me. 
>> 
>> (JFYI: EXIT_REASON_IO_INSTRUCTION cause emulate_privileged_op() to be
>> called).
> 
> So, I got rid of calling hcall to set iopl. The guest just manages
> via eflags. Then upon vmexit:
> 
> {
>     int curr_lvl;
>     int requested = (regs->rflags >> 12) & 3;
>     read_vmcs_selectors(regs);
>     curr_lvl = regs->cs & 3;
> 
>     if (requested >= curr_lvl && emulate_privileged_op(regs))
>         return success;
> 
>     hvm_inject_hw_exception(TRAP_gp_fault, regs->error_code);
> }
> 
> I tested it out, and seems fine.

And that's also how I would expect it to be. Even more - just like
the ring not needing to be 1, you shouldn't need to fiddle
artificially with IOPL. Just leave it at zero for the kernel, and
adjust between 0 and 3 for user mode based on the respective
syscalls).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 20 07:12:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Sep 2012 07:12:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TEavQ-0007OY-Dg; Thu, 20 Sep 2012 07:11:52 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <lukas@laukamp.me>) id 1TEavP-0007ON-52
	for xen-devel@lists.xensource.com; Thu, 20 Sep 2012 07:11:51 +0000
X-Env-Sender: lukas@laukamp.me
X-Msg-Ref: server-14.tower-27.messagelabs.com!1348125104!4706655!1
X-Originating-IP: [5.9.218.245]
X-SpamReason: No, hits=0.2 required=7.0 tests=RCVD_ILLEGAL_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27977 invoked from network); 20 Sep 2012 07:11:44 -0000
Received: from mailer0.lippux.de (HELO mailer0.lippux.de) (5.9.218.245)
	by server-14.tower-27.messagelabs.com with SMTP;
	20 Sep 2012 07:11:44 -0000
Received: from localhost (localhost [127.0.0.1])
	by mailer0.lippux.de (Postfix) with ESMTP id 84E57421E3E
	for <xen-devel@lists.xensource.com>;
	Thu, 20 Sep 2012 09:11:44 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at mailer0.lippux.de
Received: from mailer0.lippux.de ([127.0.0.1])
	by localhost (mailer0.lippux.de [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id ftEF13YKpiUk for <xen-devel@lists.xensource.com>;
	Thu, 20 Sep 2012 09:11:44 +0200 (CEST)
Received: by mailer0.lippux.de (Postfix, from userid 33)
	id 544FE4222C5; Thu, 20 Sep 2012 09:11:44 +0200 (CEST)
To: <xen-devel@lists.xensource.com>
X-PHP-Originating-Script: 0:main.inc
MIME-Version: 1.0
Date: Thu, 20 Sep 2012 09:11:44 +0200
From: Lukas Laukamp <lukas@laukamp.me>
Message-ID: <c277ee4a34ca57f7da68f2e0ab832090@laukamp.me>
X-Sender: lukas@laukamp.me
User-Agent: Roundcube Webmail/0.7.1
Subject: [Xen-devel] [User Question] KVM and VirtualBox in 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: 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

SGVsbG8gYWxsLAoKSSBoYXZlIGEgc2ltcGxlIHVzZXIgcXVlc3Rpb24gYnV0IGl0J3MgdmVyeSB0
ZWNobmljYWwgYW5kIHJlbGF0ZWQgdG8gCnRoZSBYZW4gY29yZS4gRG9lcyBLVk0gYW5kIFZpcnR1
YWxCb3ggd29yayBpbiBhIFhlbiBEb20wIHdpdGggWGVuIDQuMj8gClNvIEkgd291bGQgbGlrZSB0
byBjcmVhdGUgYSBWTSBIb3N0IGZvciBkZXBsb3lpbmcgVk0gdGVtcGxhdGVzIHdoaWNoIGFyZSAK
Y29tcGF0aWJsZSB0byB0aGUgbW9zdCBzb2x1dGlvbnMgYW5kIGhvc3Qgc3lzdGVtcyBhbmQgSSB0
aGluayB0aGF0IFhlbiwgCktWTS9RRW11IGFuZCBWaXJ0dWFsQm94IGFyZSB0aGUgYmVzdCBjaG9p
Y2UgZm9yIHRoaXMuCgpXb3VsZCBiZSBncmVhdCB3aGVuIHRoaXMgaXMgcG9zc2libGUgb3IgY291
bGQgYmUgaW1wbGVtZW50ZWQuIEhvcGUgdGhhdCAKc29tZW9uZSBjYW4gZ2l2ZSBtZSBhbiBhbnN3
ZXIuCgpCZXN0IFJlZ2FyZHMKClBTOiBTb3JyeSBmw7xyIG15IGJlZCBlbmdsaXNoCgpfX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpYZW4tZGV2ZWwgbWFpbGlu
ZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW4ub3JnCmh0dHA6Ly9saXN0cy54ZW4ub3JnL3hlbi1k
ZXZlbAo=

From xen-devel-bounces@lists.xen.org Thu Sep 20 07:12:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Sep 2012 07:12:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TEavQ-0007OY-Dg; Thu, 20 Sep 2012 07:11:52 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <lukas@laukamp.me>) id 1TEavP-0007ON-52
	for xen-devel@lists.xensource.com; Thu, 20 Sep 2012 07:11:51 +0000
X-Env-Sender: lukas@laukamp.me
X-Msg-Ref: server-14.tower-27.messagelabs.com!1348125104!4706655!1
X-Originating-IP: [5.9.218.245]
X-SpamReason: No, hits=0.2 required=7.0 tests=RCVD_ILLEGAL_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27977 invoked from network); 20 Sep 2012 07:11:44 -0000
Received: from mailer0.lippux.de (HELO mailer0.lippux.de) (5.9.218.245)
	by server-14.tower-27.messagelabs.com with SMTP;
	20 Sep 2012 07:11:44 -0000
Received: from localhost (localhost [127.0.0.1])
	by mailer0.lippux.de (Postfix) with ESMTP id 84E57421E3E
	for <xen-devel@lists.xensource.com>;
	Thu, 20 Sep 2012 09:11:44 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at mailer0.lippux.de
Received: from mailer0.lippux.de ([127.0.0.1])
	by localhost (mailer0.lippux.de [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id ftEF13YKpiUk for <xen-devel@lists.xensource.com>;
	Thu, 20 Sep 2012 09:11:44 +0200 (CEST)
Received: by mailer0.lippux.de (Postfix, from userid 33)
	id 544FE4222C5; Thu, 20 Sep 2012 09:11:44 +0200 (CEST)
To: <xen-devel@lists.xensource.com>
X-PHP-Originating-Script: 0:main.inc
MIME-Version: 1.0
Date: Thu, 20 Sep 2012 09:11:44 +0200
From: Lukas Laukamp <lukas@laukamp.me>
Message-ID: <c277ee4a34ca57f7da68f2e0ab832090@laukamp.me>
X-Sender: lukas@laukamp.me
User-Agent: Roundcube Webmail/0.7.1
Subject: [Xen-devel] [User Question] KVM and VirtualBox in 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: 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

SGVsbG8gYWxsLAoKSSBoYXZlIGEgc2ltcGxlIHVzZXIgcXVlc3Rpb24gYnV0IGl0J3MgdmVyeSB0
ZWNobmljYWwgYW5kIHJlbGF0ZWQgdG8gCnRoZSBYZW4gY29yZS4gRG9lcyBLVk0gYW5kIFZpcnR1
YWxCb3ggd29yayBpbiBhIFhlbiBEb20wIHdpdGggWGVuIDQuMj8gClNvIEkgd291bGQgbGlrZSB0
byBjcmVhdGUgYSBWTSBIb3N0IGZvciBkZXBsb3lpbmcgVk0gdGVtcGxhdGVzIHdoaWNoIGFyZSAK
Y29tcGF0aWJsZSB0byB0aGUgbW9zdCBzb2x1dGlvbnMgYW5kIGhvc3Qgc3lzdGVtcyBhbmQgSSB0
aGluayB0aGF0IFhlbiwgCktWTS9RRW11IGFuZCBWaXJ0dWFsQm94IGFyZSB0aGUgYmVzdCBjaG9p
Y2UgZm9yIHRoaXMuCgpXb3VsZCBiZSBncmVhdCB3aGVuIHRoaXMgaXMgcG9zc2libGUgb3IgY291
bGQgYmUgaW1wbGVtZW50ZWQuIEhvcGUgdGhhdCAKc29tZW9uZSBjYW4gZ2l2ZSBtZSBhbiBhbnN3
ZXIuCgpCZXN0IFJlZ2FyZHMKClBTOiBTb3JyeSBmw7xyIG15IGJlZCBlbmdsaXNoCgpfX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpYZW4tZGV2ZWwgbWFpbGlu
ZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW4ub3JnCmh0dHA6Ly9saXN0cy54ZW4ub3JnL3hlbi1k
ZXZlbAo=

From xen-devel-bounces@lists.xen.org Thu Sep 20 07:13:22 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Sep 2012 07:13:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TEawc-0007Td-T4; Thu, 20 Sep 2012 07:13:06 +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 1TEawa-0007T9-Jg
	for xen-devel@lists.xensource.com; Thu, 20 Sep 2012 07:13:04 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1348125171!6138816!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTAzMDk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31329 invoked from network); 20 Sep 2012 07:12: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;
	20 Sep 2012 07:12:51 -0000
X-IronPort-AV: E=Sophos;i="4.80,453,1344211200"; d="scan'208";a="14645841"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Sep 2012 07:12: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.279.1; Thu, 20 Sep 2012 08:12: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 1TEawM-000611-Rl;
	Thu, 20 Sep 2012 07:12:50 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1TEawM-0006XH-Nb;
	Thu, 20 Sep 2012 08:12:50 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-13819-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 20 Sep 2012 08:12:50 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13819: 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 13819 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13819/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-i386-xl-winxpsp3-vcpus1 12 guest-localmigrate/x10 fail pass in 13816

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore            fail   like 13816
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail like 13816
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail like 13816

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop      fail in 13816 never pass

version targeted for testing:
 xen                  fee83ac77d8c
baseline version:
 xen                  fee83ac77d8c

jobs:
 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-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-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-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-amd64-amd64-xl-win                                      fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Published tested tree is already up to date.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 20 07:13:22 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Sep 2012 07:13:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TEawc-0007Td-T4; Thu, 20 Sep 2012 07:13:06 +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 1TEawa-0007T9-Jg
	for xen-devel@lists.xensource.com; Thu, 20 Sep 2012 07:13:04 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1348125171!6138816!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTAzMDk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31329 invoked from network); 20 Sep 2012 07:12: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;
	20 Sep 2012 07:12:51 -0000
X-IronPort-AV: E=Sophos;i="4.80,453,1344211200"; d="scan'208";a="14645841"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Sep 2012 07:12: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.279.1; Thu, 20 Sep 2012 08:12: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 1TEawM-000611-Rl;
	Thu, 20 Sep 2012 07:12:50 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1TEawM-0006XH-Nb;
	Thu, 20 Sep 2012 08:12:50 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-13819-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 20 Sep 2012 08:12:50 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13819: 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 13819 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13819/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-i386-xl-winxpsp3-vcpus1 12 guest-localmigrate/x10 fail pass in 13816

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore            fail   like 13816
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail like 13816
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail like 13816

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop      fail in 13816 never pass

version targeted for testing:
 xen                  fee83ac77d8c
baseline version:
 xen                  fee83ac77d8c

jobs:
 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-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-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-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-amd64-amd64-xl-win                                      fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Published tested tree is already up to date.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 20 07:18:19 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Sep 2012 07:18:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TEb1J-0007hX-KB; Thu, 20 Sep 2012 07:17:57 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1TEb1I-0007hP-Rl
	for xen-devel@lists.xen.org; Thu, 20 Sep 2012 07:17:57 +0000
Received: from [85.158.143.99:43533] by server-2.bemta-4.messagelabs.com id
	58/A9-06610-423CA505; Thu, 20 Sep 2012 07:17:56 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1348125475!22942046!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32698 invoked from network); 20 Sep 2012 07:17:55 -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;
	20 Sep 2012 07:17:55 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 20 Sep 2012 08:17:55 +0100
Message-Id: <505ADF42020000780009C7DD@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 20 Sep 2012 08:17:54 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ben Guthro" <ben@guthro.net>
References: <CAOvdn6WwgBD-2yf1uu3m9-16=Tb5KUrybXf2KibtnxKbP7YtwA@mail.gmail.com>
	<CAOvdn6UBW-yTOMd3YSf5M9JiHLRivyaKL-qzcKG8epszqaKmGg@mail.gmail.com>
	<20120807163320.GC15053@phenom.dumpdata.com>
	<CAOvdn6XcRGKtJxGwJO8J+ZBJr89wfTLc1woW5rhtMM540H9h1w@mail.gmail.com>
	<CAOvdn6XUoSeGoo7X=AJ1kpDxZB9HZEv+TJ4v-=FHcyR4=CHK-w@mail.gmail.com>
	<502240F302000078000937A6@nat28.tlf.novell.com>
	<CAOvdn6WN3kxC8Bb9g6MpfLULu47EGSGCtajPc-SFeJ-8VSUQDQ@mail.gmail.com>
	<CAOvdn6Xk1inm1hU55i0phU2qvSWyJLNoyDdn43biBAY2OewPtw@mail.gmail.com>
	<5023F5400200007800093F4E@nat28.tlf.novell.com>
	<CAOvdn6U-f3C4U8xVPvDyRFkFFLkbfiCXg_n+9zgA9V5u+q5jfw@mail.gmail.com>
	<5023F8B80200007800093F8C@nat28.tlf.novell.com>
	<CAOvdn6XKHfete_+=Hkvt20G7_cJ-4i8+9j9YD30OxzQ16Ru-+g@mail.gmail.com>
	<5024CB720200007800094124@nat28.tlf.novell.com>
	<CAOvdn6VVJdhWVYa-gNVt3euE4AbGi1TijUCUd1wGzv0SCWEUYA@mail.gmail.com>
	<CAOvdn6USnG9Y4MNBhrDZmob0oJ8BgFfKTvFEhcKbXDxNmzfZ-Q@mail.gmail.com>
	<502B75BA0200007800094FD4@nat28.tlf.novell.com>
	<CAOvdn6Ww5oEj6Xg=XT4dWCYWUBuOdPqLz-CqNjz4HmCScE+==g@mail.gmail.com>
	<CAOvdn6Wsjds_dmZ0dwDTYmD-o-OqjBH5-b9mitAuUADE+A4_ag@mail.gmail.com>
	<502BB8FD02000078000951E0@nat28.tlf.novell.com>
	<CAOvdn6VD6bp13F-tvYdkBsj4hkhE7PTGZrapndtdHrDKeZqccg@mail.gmail.com>
	<502CCC0002000078000955C4@nat28.tlf.novell.com>
	<CAOvdn6VEuX7R2_wz74ZvCxMjC-=YUir9kP5sdxEVaKVspRUd_w@mail.gmail.com>
	<502CF0A8020000780009574E@nat28.tlf.novell.com>
	<CAOvdn6VsZvn_1TCWYeuyY5YuTcP8=miK2KwE4583nsj6Qjb_vg@mail.gmail.com>
	<504494FB0200007800098398@nat28.tlf.novell.com>
	<CAOvdn6UT13qvWbMyfZkWND03RoVKVSgb6wW4yqTUpuBYEX01Dg@mail.gmail.com>
	<5048958D02000078000993EB@nat28.tlf.novell.com>
	<CAOvdn6WrNK1Jn_Y_P7C3AwX6ApVcgzacLA_x-u=xBQtebnuPxA@mail.gmail.com>
	<CAOvdn6U_Z=KdEo56nqe7jN54BwiesRJqDOz_VzVNpkWGfFRd2A@mail.gmail.com>
	<5049CEAE0200007800099A33@nat28.tlf.novell.com>
	<CAOvdn6XmsEfs+aO7nqBHdA61HpT_n_8W95u0MMq5J21tZCFbzw@mail.gmail.com>
	<5049F37A0200007800099BDA@nat28.tlf.novell.com>
	<CAOvdn6W+=OYTH3xTWBxUB8f_2tuZYKPTo-eJG0jfkaJ2rVutCA@mail.gmail.com>
	<504A024E0200007800099C5A@nat28.tlf.novell.com>
	<CAOvdn6XYjyYEgtrPskjCLK4BZWaPyriNGSVGzumdOP8-6=P_=Q@mail.gmail.com>
	<CAOvdn6Xn1ZnontBO0KoJE9hgBsW-a1rR2EhWYEpgbbrELkXZNw@mail.gmail.com>
In-Reply-To: <CAOvdn6Xn1ZnontBO0KoJE9hgBsW-a1rR2EhWYEpgbbrELkXZNw@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>, john.baboval@citrix.com,
	Thomas Goetz <thomas.goetz@citrix.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen4.2 S3 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 19.09.12 at 23:07, Ben Guthro <ben@guthro.net> wrote:
> No hardware debugger just yet - but I've moved to another machine (Lenovo
> T400 laptop) - and am now seeing the following stack trace when I resume
> (this is using the tip of the 4.2-testing tree)

Considering that the situation is similar to the one with very early
boot problems - as long as the system either reboots on its own
(albeit I don't think you ever said it does) or has a reset button
(or other way to initiate reset without turning off power), an
alternative debugging method would be to write data into I/O
ports the values of which persist across reset, and read them out
during the following boot. I have found the 0x008x range to be a
candidate for this, as well as certain DMA controller ones. And of
course, if the CMOS RAM has its upper 128 bytes present and
(part of it) usable (i.e. otherwise unused), that would even be
an option permitting power cycling the system without losing the
information.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 20 07:18:19 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Sep 2012 07:18:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TEb1J-0007hX-KB; Thu, 20 Sep 2012 07:17:57 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1TEb1I-0007hP-Rl
	for xen-devel@lists.xen.org; Thu, 20 Sep 2012 07:17:57 +0000
Received: from [85.158.143.99:43533] by server-2.bemta-4.messagelabs.com id
	58/A9-06610-423CA505; Thu, 20 Sep 2012 07:17:56 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1348125475!22942046!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32698 invoked from network); 20 Sep 2012 07:17:55 -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;
	20 Sep 2012 07:17:55 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 20 Sep 2012 08:17:55 +0100
Message-Id: <505ADF42020000780009C7DD@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 20 Sep 2012 08:17:54 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ben Guthro" <ben@guthro.net>
References: <CAOvdn6WwgBD-2yf1uu3m9-16=Tb5KUrybXf2KibtnxKbP7YtwA@mail.gmail.com>
	<CAOvdn6UBW-yTOMd3YSf5M9JiHLRivyaKL-qzcKG8epszqaKmGg@mail.gmail.com>
	<20120807163320.GC15053@phenom.dumpdata.com>
	<CAOvdn6XcRGKtJxGwJO8J+ZBJr89wfTLc1woW5rhtMM540H9h1w@mail.gmail.com>
	<CAOvdn6XUoSeGoo7X=AJ1kpDxZB9HZEv+TJ4v-=FHcyR4=CHK-w@mail.gmail.com>
	<502240F302000078000937A6@nat28.tlf.novell.com>
	<CAOvdn6WN3kxC8Bb9g6MpfLULu47EGSGCtajPc-SFeJ-8VSUQDQ@mail.gmail.com>
	<CAOvdn6Xk1inm1hU55i0phU2qvSWyJLNoyDdn43biBAY2OewPtw@mail.gmail.com>
	<5023F5400200007800093F4E@nat28.tlf.novell.com>
	<CAOvdn6U-f3C4U8xVPvDyRFkFFLkbfiCXg_n+9zgA9V5u+q5jfw@mail.gmail.com>
	<5023F8B80200007800093F8C@nat28.tlf.novell.com>
	<CAOvdn6XKHfete_+=Hkvt20G7_cJ-4i8+9j9YD30OxzQ16Ru-+g@mail.gmail.com>
	<5024CB720200007800094124@nat28.tlf.novell.com>
	<CAOvdn6VVJdhWVYa-gNVt3euE4AbGi1TijUCUd1wGzv0SCWEUYA@mail.gmail.com>
	<CAOvdn6USnG9Y4MNBhrDZmob0oJ8BgFfKTvFEhcKbXDxNmzfZ-Q@mail.gmail.com>
	<502B75BA0200007800094FD4@nat28.tlf.novell.com>
	<CAOvdn6Ww5oEj6Xg=XT4dWCYWUBuOdPqLz-CqNjz4HmCScE+==g@mail.gmail.com>
	<CAOvdn6Wsjds_dmZ0dwDTYmD-o-OqjBH5-b9mitAuUADE+A4_ag@mail.gmail.com>
	<502BB8FD02000078000951E0@nat28.tlf.novell.com>
	<CAOvdn6VD6bp13F-tvYdkBsj4hkhE7PTGZrapndtdHrDKeZqccg@mail.gmail.com>
	<502CCC0002000078000955C4@nat28.tlf.novell.com>
	<CAOvdn6VEuX7R2_wz74ZvCxMjC-=YUir9kP5sdxEVaKVspRUd_w@mail.gmail.com>
	<502CF0A8020000780009574E@nat28.tlf.novell.com>
	<CAOvdn6VsZvn_1TCWYeuyY5YuTcP8=miK2KwE4583nsj6Qjb_vg@mail.gmail.com>
	<504494FB0200007800098398@nat28.tlf.novell.com>
	<CAOvdn6UT13qvWbMyfZkWND03RoVKVSgb6wW4yqTUpuBYEX01Dg@mail.gmail.com>
	<5048958D02000078000993EB@nat28.tlf.novell.com>
	<CAOvdn6WrNK1Jn_Y_P7C3AwX6ApVcgzacLA_x-u=xBQtebnuPxA@mail.gmail.com>
	<CAOvdn6U_Z=KdEo56nqe7jN54BwiesRJqDOz_VzVNpkWGfFRd2A@mail.gmail.com>
	<5049CEAE0200007800099A33@nat28.tlf.novell.com>
	<CAOvdn6XmsEfs+aO7nqBHdA61HpT_n_8W95u0MMq5J21tZCFbzw@mail.gmail.com>
	<5049F37A0200007800099BDA@nat28.tlf.novell.com>
	<CAOvdn6W+=OYTH3xTWBxUB8f_2tuZYKPTo-eJG0jfkaJ2rVutCA@mail.gmail.com>
	<504A024E0200007800099C5A@nat28.tlf.novell.com>
	<CAOvdn6XYjyYEgtrPskjCLK4BZWaPyriNGSVGzumdOP8-6=P_=Q@mail.gmail.com>
	<CAOvdn6Xn1ZnontBO0KoJE9hgBsW-a1rR2EhWYEpgbbrELkXZNw@mail.gmail.com>
In-Reply-To: <CAOvdn6Xn1ZnontBO0KoJE9hgBsW-a1rR2EhWYEpgbbrELkXZNw@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>, john.baboval@citrix.com,
	Thomas Goetz <thomas.goetz@citrix.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen4.2 S3 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 19.09.12 at 23:07, Ben Guthro <ben@guthro.net> wrote:
> No hardware debugger just yet - but I've moved to another machine (Lenovo
> T400 laptop) - and am now seeing the following stack trace when I resume
> (this is using the tip of the 4.2-testing tree)

Considering that the situation is similar to the one with very early
boot problems - as long as the system either reboots on its own
(albeit I don't think you ever said it does) or has a reset button
(or other way to initiate reset without turning off power), an
alternative debugging method would be to write data into I/O
ports the values of which persist across reset, and read them out
during the following boot. I have found the 0x008x range to be a
candidate for this, as well as certain DMA controller ones. And of
course, if the CMOS RAM has its upper 128 bytes present and
(part of it) usable (i.e. otherwise unused), that would even be
an option permitting power cycling the system without losing the
information.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 20 07:18:42 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Sep 2012 07: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 1TEb1n-0007kA-1O; Thu, 20 Sep 2012 07:18:27 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <qianhu2011@gmail.com>) id 1TEb1l-0007jv-Td
	for xen-devel@lists.xen.org; Thu, 20 Sep 2012 07:18:26 +0000
Received: from [85.158.138.51:15330] by server-9.bemta-3.messagelabs.com id
	9C/F7-15390-143CA505; Thu, 20 Sep 2012 07:18:25 +0000
X-Env-Sender: qianhu2011@gmail.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1348125503!29490975!1
X-Originating-IP: [209.85.220.173]
X-SpamReason: No, hits=0.7 required=7.0 tests=HTML_30_40,HTML_MESSAGE,
	MAILTO_TO_SPAM_ADDR,ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2656 invoked from network); 20 Sep 2012 07:18:24 -0000
Received: from mail-vc0-f173.google.com (HELO mail-vc0-f173.google.com)
	(209.85.220.173)
	by server-15.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Sep 2012 07:18:24 -0000
Received: by vcbfl15 with SMTP id fl15so2631226vcb.32
	for <xen-devel@lists.xen.org>; Thu, 20 Sep 2012 00:18:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=GoyUASW67jBjByd29+OrKUEZRZhC2P+vQgP8ONJ/7G0=;
	b=b2Z9jaMdyG1WU9IaPmqQqwdt9DaIUvTIImaYoYcIjFu7KMF4hwgkLqIjImtm+x178Y
	WnQqxomCQ+945AjpncONjLL97UPye7GSXDfAteI0wHXQEoWZcgCR5TCpG8wItm3J5ML4
	6TAQJ4Hf6Gfph8TBzFdBZ+KkNW5bm8BAyq8gT4ydvcFiP050/uqUorM18uuSkbhBnjRB
	VbncoZakhkfs8wN44xTsPKvd/Mg5sy50xxP6w/2YE3U84lXEvDmwR7HhAO2LoynRkxMw
	J7bXtUhOuTWRKzRinBIuRWYQL0ZhBy4ghcjjShyeaibz66segVW7UYZCwNbEw/TRif7J
	MrDw==
MIME-Version: 1.0
Received: by 10.52.16.110 with SMTP id f14mr483768vdd.8.1348125502686; Thu, 20
	Sep 2012 00:18:22 -0700 (PDT)
Received: by 10.58.249.236 with HTTP; Thu, 20 Sep 2012 00:18:22 -0700 (PDT)
In-Reply-To: <CACJDEmo-cxm0MiAtSo7sXdKsWChTS4NW4SNsOM_pBOgwr2W7BA@mail.gmail.com>
References: <CALCpXpBnAQr=jk5LbZnQPAuJHrKEAL0ELcZ3L2BRQRUfGbUvAw@mail.gmail.com>
	<CACJDEmo-cxm0MiAtSo7sXdKsWChTS4NW4SNsOM_pBOgwr2W7BA@mail.gmail.com>
Date: Thu, 20 Sep 2012 15:18:22 +0800
Message-ID: <CALCpXpAQ4OJuOkh44e414MWjEhPtydv97GZwCbZL_DmErz_JeA@mail.gmail.com>
From: Qian Hu <qianhu2011@gmail.com>
To: Konrad Rzeszutek Wilk <konrad@kernel.org>
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] usbpassthrough of xen-4.1.2
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============8596893686986568685=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============8596893686986568685==
Content-Type: multipart/alternative; boundary=bcaec5040ca6b3460f04ca1ced56

--bcaec5040ca6b3460f04ca1ced56
Content-Type: text/plain; charset=ISO-8859-1

More infomation:

I have tried the USB 2.0 Mass Storage by  by specifying "usb = 1" and
"usbdevice = host:xxxx:yyyy"

But I can't use it in the guest OS(win7). It is listed in the device
manager, and the driver is OK, but can't start.

I can only find the message  "The device cannot start(code 10)".

I am sorry I haven't tried the linux guest.


2012/9/20 Konrad Rzeszutek Wilk <konrad@kernel.org>

> On Wed, Sep 19, 2012 at 4:53 AM, Qian Hu <qianhu2011@gmail.com> wrote:
> > Hi, everyone!
> >
> > I am working on the USB passthrough of Xen-4.1.2. My host OS  is Fedora
> 14
> > and the guest OS is win7.
> >
> > According to the wiki page(http://wiki.xen.org/wiki/Xen_USB_Passthrough
> ),
> >
> > xen supports passthrough of usb device from dom0 to guests. I have tried
> the
> > Xen HVM guest qemu-dm usb1.1 emulation,
> >
> > by specifying "usb = 1" and "usbdevice = host:xxxx:yyyy". But, the mouse
> > could work, the keyboard and usb storage failed.
>
> You need to give more details. How did it not work? Did it work in Linux?
> >
> > If I change the guest OS to winXP, it is surprising that only the usb
> > storage can be detected in the guest.
> >
> > I have also tried the PVUSB, it didn't work either.
>
> Right, that is b/c it would only work with Linux.
> >
> > I am confused and don't know how to resolve it.  Could anyone help me?
>
> Try first an Linux HVM guest and pass in. See what works and what does not.
> >
> > Great thanks!
> >
> > huqian
> >
> >
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xen.org
> > http://lists.xen.org/xen-devel
> >
>

--bcaec5040ca6b3460f04ca1ced56
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

More infomation:<div><br></div><div>I have tried the USB 2.0 Mass Storage b=
y=A0
by specifying &quot;usb =3D 1&quot; and &quot;usbdevice =3D host:xxxx:yyyy&=
quot;=A0</div><div><br></div><div>But I can&#39;t use it in the guest OS(wi=
n7). It is listed in the device manager, and the driver is OK, but can&#39;=
t start.</div>

<div><br></div><div>I can only find the message =A0&quot;The device cannot =
start(code 10)&quot;.</div><div><br></div><div>I am sorry I haven&#39;t tri=
ed the linux guest.</div><div><br><br><div class=3D"gmail_quote">2012/9/20 =
Konrad Rzeszutek Wilk <span dir=3D"ltr">&lt;<a href=3D"mailto:konrad@kernel=
.org" target=3D"_blank">konrad@kernel.org</a>&gt;</span><br>

<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div>On Wed, Sep 19, 2012 at 4:53 AM, Qian H=
u &lt;<a href=3D"mailto:qianhu2011@gmail.com" target=3D"_blank">qianhu2011@=
gmail.com</a>&gt; wrote:<br>


&gt; Hi, everyone!<br>
&gt;<br>
&gt; I am working on the USB passthrough of Xen-4.1.2. My host OS =A0is Fed=
ora 14<br>
&gt; and the guest OS is win7.<br>
&gt;<br>
&gt; According to the wiki page(<a href=3D"http://wiki.xen.org/wiki/Xen_USB=
_Passthrough" target=3D"_blank">http://wiki.xen.org/wiki/Xen_USB_Passthroug=
h</a>),<br>
&gt;<br>
&gt; xen supports passthrough of usb device from dom0 to guests. I have tri=
ed the<br>
&gt; Xen HVM guest qemu-dm usb1.1 emulation,<br>
&gt;<br>
&gt; by specifying &quot;usb =3D 1&quot; and &quot;usbdevice =3D host:xxxx:=
yyyy&quot;. But, the mouse<br>
&gt; could work, the keyboard and usb storage failed.<br>
<br>
</div>You need to give more details. How did it not work? Did it work in Li=
nux?<br>
<div>&gt;<br>
&gt; If I change the guest OS to winXP, it is surprising that only the usb<=
br>
&gt; storage can be detected in the guest.<br>
&gt;<br>
&gt; I have also tried the PVUSB, it didn&#39;t work either.<br>
<br>
</div>Right, that is b/c it would only work with Linux.<br>
<div>&gt;<br>
&gt; I am confused and don&#39;t know how to resolve it. =A0Could anyone he=
lp me?<br>
<br>
</div>Try first an Linux HVM guest and pass in. See what works and what doe=
s not.<br>
&gt;<br>
&gt; Great thanks!<br>
&gt;<br>
&gt; huqian<br>
<div><div>&gt;<br>
&gt;<br>
&gt; _______________________________________________<br>
&gt; Xen-devel mailing list<br>
&gt; <a href=3D"mailto:Xen-devel@lists.xen.org" target=3D"_blank">Xen-devel=
@lists.xen.org</a><br>
&gt; <a href=3D"http://lists.xen.org/xen-devel" target=3D"_blank">http://li=
sts.xen.org/xen-devel</a><br>
&gt;<br>
</div></div></blockquote></div><br></div>

--bcaec5040ca6b3460f04ca1ced56--


--===============8596893686986568685==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============8596893686986568685==--


From xen-devel-bounces@lists.xen.org Thu Sep 20 07:18:42 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Sep 2012 07: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 1TEb1n-0007kA-1O; Thu, 20 Sep 2012 07:18:27 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <qianhu2011@gmail.com>) id 1TEb1l-0007jv-Td
	for xen-devel@lists.xen.org; Thu, 20 Sep 2012 07:18:26 +0000
Received: from [85.158.138.51:15330] by server-9.bemta-3.messagelabs.com id
	9C/F7-15390-143CA505; Thu, 20 Sep 2012 07:18:25 +0000
X-Env-Sender: qianhu2011@gmail.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1348125503!29490975!1
X-Originating-IP: [209.85.220.173]
X-SpamReason: No, hits=0.7 required=7.0 tests=HTML_30_40,HTML_MESSAGE,
	MAILTO_TO_SPAM_ADDR,ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2656 invoked from network); 20 Sep 2012 07:18:24 -0000
Received: from mail-vc0-f173.google.com (HELO mail-vc0-f173.google.com)
	(209.85.220.173)
	by server-15.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Sep 2012 07:18:24 -0000
Received: by vcbfl15 with SMTP id fl15so2631226vcb.32
	for <xen-devel@lists.xen.org>; Thu, 20 Sep 2012 00:18:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=GoyUASW67jBjByd29+OrKUEZRZhC2P+vQgP8ONJ/7G0=;
	b=b2Z9jaMdyG1WU9IaPmqQqwdt9DaIUvTIImaYoYcIjFu7KMF4hwgkLqIjImtm+x178Y
	WnQqxomCQ+945AjpncONjLL97UPye7GSXDfAteI0wHXQEoWZcgCR5TCpG8wItm3J5ML4
	6TAQJ4Hf6Gfph8TBzFdBZ+KkNW5bm8BAyq8gT4ydvcFiP050/uqUorM18uuSkbhBnjRB
	VbncoZakhkfs8wN44xTsPKvd/Mg5sy50xxP6w/2YE3U84lXEvDmwR7HhAO2LoynRkxMw
	J7bXtUhOuTWRKzRinBIuRWYQL0ZhBy4ghcjjShyeaibz66segVW7UYZCwNbEw/TRif7J
	MrDw==
MIME-Version: 1.0
Received: by 10.52.16.110 with SMTP id f14mr483768vdd.8.1348125502686; Thu, 20
	Sep 2012 00:18:22 -0700 (PDT)
Received: by 10.58.249.236 with HTTP; Thu, 20 Sep 2012 00:18:22 -0700 (PDT)
In-Reply-To: <CACJDEmo-cxm0MiAtSo7sXdKsWChTS4NW4SNsOM_pBOgwr2W7BA@mail.gmail.com>
References: <CALCpXpBnAQr=jk5LbZnQPAuJHrKEAL0ELcZ3L2BRQRUfGbUvAw@mail.gmail.com>
	<CACJDEmo-cxm0MiAtSo7sXdKsWChTS4NW4SNsOM_pBOgwr2W7BA@mail.gmail.com>
Date: Thu, 20 Sep 2012 15:18:22 +0800
Message-ID: <CALCpXpAQ4OJuOkh44e414MWjEhPtydv97GZwCbZL_DmErz_JeA@mail.gmail.com>
From: Qian Hu <qianhu2011@gmail.com>
To: Konrad Rzeszutek Wilk <konrad@kernel.org>
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] usbpassthrough of xen-4.1.2
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============8596893686986568685=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============8596893686986568685==
Content-Type: multipart/alternative; boundary=bcaec5040ca6b3460f04ca1ced56

--bcaec5040ca6b3460f04ca1ced56
Content-Type: text/plain; charset=ISO-8859-1

More infomation:

I have tried the USB 2.0 Mass Storage by  by specifying "usb = 1" and
"usbdevice = host:xxxx:yyyy"

But I can't use it in the guest OS(win7). It is listed in the device
manager, and the driver is OK, but can't start.

I can only find the message  "The device cannot start(code 10)".

I am sorry I haven't tried the linux guest.


2012/9/20 Konrad Rzeszutek Wilk <konrad@kernel.org>

> On Wed, Sep 19, 2012 at 4:53 AM, Qian Hu <qianhu2011@gmail.com> wrote:
> > Hi, everyone!
> >
> > I am working on the USB passthrough of Xen-4.1.2. My host OS  is Fedora
> 14
> > and the guest OS is win7.
> >
> > According to the wiki page(http://wiki.xen.org/wiki/Xen_USB_Passthrough
> ),
> >
> > xen supports passthrough of usb device from dom0 to guests. I have tried
> the
> > Xen HVM guest qemu-dm usb1.1 emulation,
> >
> > by specifying "usb = 1" and "usbdevice = host:xxxx:yyyy". But, the mouse
> > could work, the keyboard and usb storage failed.
>
> You need to give more details. How did it not work? Did it work in Linux?
> >
> > If I change the guest OS to winXP, it is surprising that only the usb
> > storage can be detected in the guest.
> >
> > I have also tried the PVUSB, it didn't work either.
>
> Right, that is b/c it would only work with Linux.
> >
> > I am confused and don't know how to resolve it.  Could anyone help me?
>
> Try first an Linux HVM guest and pass in. See what works and what does not.
> >
> > Great thanks!
> >
> > huqian
> >
> >
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xen.org
> > http://lists.xen.org/xen-devel
> >
>

--bcaec5040ca6b3460f04ca1ced56
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

More infomation:<div><br></div><div>I have tried the USB 2.0 Mass Storage b=
y=A0
by specifying &quot;usb =3D 1&quot; and &quot;usbdevice =3D host:xxxx:yyyy&=
quot;=A0</div><div><br></div><div>But I can&#39;t use it in the guest OS(wi=
n7). It is listed in the device manager, and the driver is OK, but can&#39;=
t start.</div>

<div><br></div><div>I can only find the message =A0&quot;The device cannot =
start(code 10)&quot;.</div><div><br></div><div>I am sorry I haven&#39;t tri=
ed the linux guest.</div><div><br><br><div class=3D"gmail_quote">2012/9/20 =
Konrad Rzeszutek Wilk <span dir=3D"ltr">&lt;<a href=3D"mailto:konrad@kernel=
.org" target=3D"_blank">konrad@kernel.org</a>&gt;</span><br>

<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div>On Wed, Sep 19, 2012 at 4:53 AM, Qian H=
u &lt;<a href=3D"mailto:qianhu2011@gmail.com" target=3D"_blank">qianhu2011@=
gmail.com</a>&gt; wrote:<br>


&gt; Hi, everyone!<br>
&gt;<br>
&gt; I am working on the USB passthrough of Xen-4.1.2. My host OS =A0is Fed=
ora 14<br>
&gt; and the guest OS is win7.<br>
&gt;<br>
&gt; According to the wiki page(<a href=3D"http://wiki.xen.org/wiki/Xen_USB=
_Passthrough" target=3D"_blank">http://wiki.xen.org/wiki/Xen_USB_Passthroug=
h</a>),<br>
&gt;<br>
&gt; xen supports passthrough of usb device from dom0 to guests. I have tri=
ed the<br>
&gt; Xen HVM guest qemu-dm usb1.1 emulation,<br>
&gt;<br>
&gt; by specifying &quot;usb =3D 1&quot; and &quot;usbdevice =3D host:xxxx:=
yyyy&quot;. But, the mouse<br>
&gt; could work, the keyboard and usb storage failed.<br>
<br>
</div>You need to give more details. How did it not work? Did it work in Li=
nux?<br>
<div>&gt;<br>
&gt; If I change the guest OS to winXP, it is surprising that only the usb<=
br>
&gt; storage can be detected in the guest.<br>
&gt;<br>
&gt; I have also tried the PVUSB, it didn&#39;t work either.<br>
<br>
</div>Right, that is b/c it would only work with Linux.<br>
<div>&gt;<br>
&gt; I am confused and don&#39;t know how to resolve it. =A0Could anyone he=
lp me?<br>
<br>
</div>Try first an Linux HVM guest and pass in. See what works and what doe=
s not.<br>
&gt;<br>
&gt; Great thanks!<br>
&gt;<br>
&gt; huqian<br>
<div><div>&gt;<br>
&gt;<br>
&gt; _______________________________________________<br>
&gt; Xen-devel mailing list<br>
&gt; <a href=3D"mailto:Xen-devel@lists.xen.org" target=3D"_blank">Xen-devel=
@lists.xen.org</a><br>
&gt; <a href=3D"http://lists.xen.org/xen-devel" target=3D"_blank">http://li=
sts.xen.org/xen-devel</a><br>
&gt;<br>
</div></div></blockquote></div><br></div>

--bcaec5040ca6b3460f04ca1ced56--


--===============8596893686986568685==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============8596893686986568685==--


From xen-devel-bounces@lists.xen.org Thu Sep 20 07:37:27 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Sep 2012 07:37: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 1TEbJu-00086e-64; Thu, 20 Sep 2012 07:37:10 +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 1TEbJt-00086W-KI
	for xen-devel@lists.xensource.com; Thu, 20 Sep 2012 07:37:09 +0000
Received: from [85.158.137.99:15216] by server-3.bemta-3.messagelabs.com id
	3F/8E-21322-4A7CA505; Thu, 20 Sep 2012 07:37:08 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-14.tower-217.messagelabs.com!1348126628!18387595!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA1MDkwNzg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29748 invoked from network); 20 Sep 2012 07:37:08 -0000
Received: from smtp.tele.fi (HELO vulpes-int.media.sonera.net) (192.89.123.25)
	by server-14.tower-217.messagelabs.com with SMTP;
	20 Sep 2012 07:37:08 -0000
Received: from smtp.tele.fi (smtp.tele.fi [192.89.123.25])
	by vulpes-int.media.sonera.net (Postfix) with ESMTP id AC86AC12D
	for <xen-devel@lists.xensource.com>;
	Thu, 20 Sep 2012 10:37:07 +0300 (EEST)
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 33EF12F26;
	Thu, 20 Sep 2012 10:36:44 +0300 (EEST)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id DC1AA2005D; Thu, 20 Sep 2012 10:36:43 +0300 (EEST)
Date: Thu, 20 Sep 2012 10:36:43 +0300
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: Lukas Laukamp <lukas@laukamp.me>
Message-ID: <20120920073643.GU8912@reaktio.net>
References: <c277ee4a34ca57f7da68f2e0ab832090@laukamp.me>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <c277ee4a34ca57f7da68f2e0ab832090@laukamp.me>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [User Question] KVM and VirtualBox in 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 Thu, Sep 20, 2012 at 09:11:44AM +0200, Lukas Laukamp wrote:
> Hello all,
> 
> I have a simple user question but it's very technical and related to
> the Xen core. Does KVM and VirtualBox work in a Xen Dom0 with Xen
> 4.2? So I would like to create a VM Host for deploying VM templates
> which are compatible to the most solutions and host systems and I
> think that Xen, KVM/QEmu and VirtualBox are the best choice for
> this.
> 
> Would be great when this is possible or could be implemented. Hope
> that someone can give me an answer.
> 

Nope, KVM or VirtualBox won't work in Xen dom0.

But you can use Xen Nested Hardware Virtualization and run KVM/VirtualBox in Xen HVM guest.
This is a "tech preview" currently.

-- Pasi


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 20 07:37:27 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Sep 2012 07:37: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 1TEbJu-00086e-64; Thu, 20 Sep 2012 07:37:10 +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 1TEbJt-00086W-KI
	for xen-devel@lists.xensource.com; Thu, 20 Sep 2012 07:37:09 +0000
Received: from [85.158.137.99:15216] by server-3.bemta-3.messagelabs.com id
	3F/8E-21322-4A7CA505; Thu, 20 Sep 2012 07:37:08 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-14.tower-217.messagelabs.com!1348126628!18387595!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA1MDkwNzg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29748 invoked from network); 20 Sep 2012 07:37:08 -0000
Received: from smtp.tele.fi (HELO vulpes-int.media.sonera.net) (192.89.123.25)
	by server-14.tower-217.messagelabs.com with SMTP;
	20 Sep 2012 07:37:08 -0000
Received: from smtp.tele.fi (smtp.tele.fi [192.89.123.25])
	by vulpes-int.media.sonera.net (Postfix) with ESMTP id AC86AC12D
	for <xen-devel@lists.xensource.com>;
	Thu, 20 Sep 2012 10:37:07 +0300 (EEST)
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 33EF12F26;
	Thu, 20 Sep 2012 10:36:44 +0300 (EEST)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id DC1AA2005D; Thu, 20 Sep 2012 10:36:43 +0300 (EEST)
Date: Thu, 20 Sep 2012 10:36:43 +0300
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: Lukas Laukamp <lukas@laukamp.me>
Message-ID: <20120920073643.GU8912@reaktio.net>
References: <c277ee4a34ca57f7da68f2e0ab832090@laukamp.me>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <c277ee4a34ca57f7da68f2e0ab832090@laukamp.me>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [User Question] KVM and VirtualBox in 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 Thu, Sep 20, 2012 at 09:11:44AM +0200, Lukas Laukamp wrote:
> Hello all,
> 
> I have a simple user question but it's very technical and related to
> the Xen core. Does KVM and VirtualBox work in a Xen Dom0 with Xen
> 4.2? So I would like to create a VM Host for deploying VM templates
> which are compatible to the most solutions and host systems and I
> think that Xen, KVM/QEmu and VirtualBox are the best choice for
> this.
> 
> Would be great when this is possible or could be implemented. Hope
> that someone can give me an answer.
> 

Nope, KVM or VirtualBox won't work in Xen dom0.

But you can use Xen Nested Hardware Virtualization and run KVM/VirtualBox in Xen HVM guest.
This is a "tech preview" currently.

-- Pasi


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 20 07:45:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Sep 2012 07:45:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TEbRE-0008Gc-3j; Thu, 20 Sep 2012 07:44:44 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <lukas@laukamp.me>) id 1TEbRD-0008GX-2O
	for xen-devel@lists.xensource.com; Thu, 20 Sep 2012 07:44:43 +0000
Received: from [85.158.139.83:18022] by server-6.bemta-5.messagelabs.com id
	5F/D6-21336-A69CA505; Thu, 20 Sep 2012 07:44:42 +0000
X-Env-Sender: lukas@laukamp.me
X-Msg-Ref: server-5.tower-182.messagelabs.com!1348127081!30987284!1
X-Originating-IP: [5.9.218.245]
X-SpamReason: No, hits=0.2 required=7.0 tests=RCVD_ILLEGAL_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19480 invoked from network); 20 Sep 2012 07:44:41 -0000
Received: from mailer0.lippux.de (HELO mailer0.lippux.de) (5.9.218.245)
	by server-5.tower-182.messagelabs.com with SMTP;
	20 Sep 2012 07:44:41 -0000
Received: from localhost (localhost [127.0.0.1])
	by mailer0.lippux.de (Postfix) with ESMTP id 6CA54422337;
	Thu, 20 Sep 2012 09:44:41 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at mailer0.lippux.de
Received: from mailer0.lippux.de ([127.0.0.1])
	by localhost (mailer0.lippux.de [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id 9djLalUZbG-g; Thu, 20 Sep 2012 09:44:41 +0200 (CEST)
Received: by mailer0.lippux.de (Postfix, from userid 33)
	id 25CA0422336; Thu, 20 Sep 2012 09:44:41 +0200 (CEST)
To: =?UTF-8?Q?Pasi_K=C3=A4rkk=C3=A4inen?= <pasik@iki.fi>
X-PHP-Originating-Script: 0:main.inc
MIME-Version: 1.0
Date: Thu, 20 Sep 2012 09:44:41 +0200
From: Lukas Laukamp <lukas@laukamp.me>
In-Reply-To: <20120920073643.GU8912@reaktio.net>
References: <c277ee4a34ca57f7da68f2e0ab832090@laukamp.me>
	<20120920073643.GU8912@reaktio.net>
Message-ID: <bce40f714cae80dfd919b3d2c4e870e4@laukamp.me>
X-Sender: lukas@laukamp.me
User-Agent: Roundcube Webmail/0.7.1
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [User Question] KVM and VirtualBox in 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: 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

QW0gMjAxMi0wOS0yMCAwOTozNiwgc2NocmllYiBQYXNpIEvDpHJra8OkaW5lbjoKPiBPbiBUaHUs
IFNlcCAyMCwgMjAxMiBhdCAwOToxMTo0NEFNICswMjAwLCBMdWthcyBMYXVrYW1wIHdyb3RlOgo+
PiBIZWxsbyBhbGwsCj4+Cj4+IEkgaGF2ZSBhIHNpbXBsZSB1c2VyIHF1ZXN0aW9uIGJ1dCBpdCdz
IHZlcnkgdGVjaG5pY2FsIGFuZCByZWxhdGVkIHRvCj4+IHRoZSBYZW4gY29yZS4gRG9lcyBLVk0g
YW5kIFZpcnR1YWxCb3ggd29yayBpbiBhIFhlbiBEb20wIHdpdGggWGVuCj4+IDQuMj8gU28gSSB3
b3VsZCBsaWtlIHRvIGNyZWF0ZSBhIFZNIEhvc3QgZm9yIGRlcGxveWluZyBWTSB0ZW1wbGF0ZXMK
Pj4gd2hpY2ggYXJlIGNvbXBhdGlibGUgdG8gdGhlIG1vc3Qgc29sdXRpb25zIGFuZCBob3N0IHN5
c3RlbXMgYW5kIEkKPj4gdGhpbmsgdGhhdCBYZW4sIEtWTS9RRW11IGFuZCBWaXJ0dWFsQm94IGFy
ZSB0aGUgYmVzdCBjaG9pY2UgZm9yCj4+IHRoaXMuCj4+Cj4+IFdvdWxkIGJlIGdyZWF0IHdoZW4g
dGhpcyBpcyBwb3NzaWJsZSBvciBjb3VsZCBiZSBpbXBsZW1lbnRlZC4gSG9wZQo+PiB0aGF0IHNv
bWVvbmUgY2FuIGdpdmUgbWUgYW4gYW5zd2VyLgo+Pgo+Cj4gTm9wZSwgS1ZNIG9yIFZpcnR1YWxC
b3ggd29uJ3Qgd29yayBpbiBYZW4gZG9tMC4KPgo+IEJ1dCB5b3UgY2FuIHVzZSBYZW4gTmVzdGVk
IEhhcmR3YXJlIFZpcnR1YWxpemF0aW9uIGFuZCBydW4KPiBLVk0vVmlydHVhbEJveCBpbiBYZW4g
SFZNIGd1ZXN0Lgo+IFRoaXMgaXMgYSAidGVjaCBwcmV2aWV3IiBjdXJyZW50bHkuCj4KPiAtLSBQ
YXNpCgpIZWxsbywKCm9rLCB0aGlzIHdvdWxkIGJlIHBvc3NpYmxlIHdpdGggWGVuIDQuMj8gQW5k
IHdvdWxkIGl0IGJlIHBvc3NpYmxlIHRvIAppbXBsZW1lbnQgc29tZXRoaW5nIHRoYXQgS1ZNIGFu
ZCBWaXJ0dWFsQm94IHdvcmsgaW4gYSBYZW4gRG9tMD8gSXMgdGhpcyAKYSB0YXNrIGZvciB0aGUg
WGVuIGRldmVsb3BtZW50IG9yIHNvbWV0aGluZyBmb3IgdGhlIExpbnV4IGtlcm5lbCwsIEtWTSAK
b3IgVmlydHVhbEJveD8KCkJlc3QgUmVnYXJkcwoKX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlz
dHMueGVuLm9yZwpodHRwOi8vbGlzdHMueGVuLm9yZy94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xen.org Thu Sep 20 07:45:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Sep 2012 07:45:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TEbRE-0008Gc-3j; Thu, 20 Sep 2012 07:44:44 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <lukas@laukamp.me>) id 1TEbRD-0008GX-2O
	for xen-devel@lists.xensource.com; Thu, 20 Sep 2012 07:44:43 +0000
Received: from [85.158.139.83:18022] by server-6.bemta-5.messagelabs.com id
	5F/D6-21336-A69CA505; Thu, 20 Sep 2012 07:44:42 +0000
X-Env-Sender: lukas@laukamp.me
X-Msg-Ref: server-5.tower-182.messagelabs.com!1348127081!30987284!1
X-Originating-IP: [5.9.218.245]
X-SpamReason: No, hits=0.2 required=7.0 tests=RCVD_ILLEGAL_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19480 invoked from network); 20 Sep 2012 07:44:41 -0000
Received: from mailer0.lippux.de (HELO mailer0.lippux.de) (5.9.218.245)
	by server-5.tower-182.messagelabs.com with SMTP;
	20 Sep 2012 07:44:41 -0000
Received: from localhost (localhost [127.0.0.1])
	by mailer0.lippux.de (Postfix) with ESMTP id 6CA54422337;
	Thu, 20 Sep 2012 09:44:41 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at mailer0.lippux.de
Received: from mailer0.lippux.de ([127.0.0.1])
	by localhost (mailer0.lippux.de [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id 9djLalUZbG-g; Thu, 20 Sep 2012 09:44:41 +0200 (CEST)
Received: by mailer0.lippux.de (Postfix, from userid 33)
	id 25CA0422336; Thu, 20 Sep 2012 09:44:41 +0200 (CEST)
To: =?UTF-8?Q?Pasi_K=C3=A4rkk=C3=A4inen?= <pasik@iki.fi>
X-PHP-Originating-Script: 0:main.inc
MIME-Version: 1.0
Date: Thu, 20 Sep 2012 09:44:41 +0200
From: Lukas Laukamp <lukas@laukamp.me>
In-Reply-To: <20120920073643.GU8912@reaktio.net>
References: <c277ee4a34ca57f7da68f2e0ab832090@laukamp.me>
	<20120920073643.GU8912@reaktio.net>
Message-ID: <bce40f714cae80dfd919b3d2c4e870e4@laukamp.me>
X-Sender: lukas@laukamp.me
User-Agent: Roundcube Webmail/0.7.1
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [User Question] KVM and VirtualBox in 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: 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

QW0gMjAxMi0wOS0yMCAwOTozNiwgc2NocmllYiBQYXNpIEvDpHJra8OkaW5lbjoKPiBPbiBUaHUs
IFNlcCAyMCwgMjAxMiBhdCAwOToxMTo0NEFNICswMjAwLCBMdWthcyBMYXVrYW1wIHdyb3RlOgo+
PiBIZWxsbyBhbGwsCj4+Cj4+IEkgaGF2ZSBhIHNpbXBsZSB1c2VyIHF1ZXN0aW9uIGJ1dCBpdCdz
IHZlcnkgdGVjaG5pY2FsIGFuZCByZWxhdGVkIHRvCj4+IHRoZSBYZW4gY29yZS4gRG9lcyBLVk0g
YW5kIFZpcnR1YWxCb3ggd29yayBpbiBhIFhlbiBEb20wIHdpdGggWGVuCj4+IDQuMj8gU28gSSB3
b3VsZCBsaWtlIHRvIGNyZWF0ZSBhIFZNIEhvc3QgZm9yIGRlcGxveWluZyBWTSB0ZW1wbGF0ZXMK
Pj4gd2hpY2ggYXJlIGNvbXBhdGlibGUgdG8gdGhlIG1vc3Qgc29sdXRpb25zIGFuZCBob3N0IHN5
c3RlbXMgYW5kIEkKPj4gdGhpbmsgdGhhdCBYZW4sIEtWTS9RRW11IGFuZCBWaXJ0dWFsQm94IGFy
ZSB0aGUgYmVzdCBjaG9pY2UgZm9yCj4+IHRoaXMuCj4+Cj4+IFdvdWxkIGJlIGdyZWF0IHdoZW4g
dGhpcyBpcyBwb3NzaWJsZSBvciBjb3VsZCBiZSBpbXBsZW1lbnRlZC4gSG9wZQo+PiB0aGF0IHNv
bWVvbmUgY2FuIGdpdmUgbWUgYW4gYW5zd2VyLgo+Pgo+Cj4gTm9wZSwgS1ZNIG9yIFZpcnR1YWxC
b3ggd29uJ3Qgd29yayBpbiBYZW4gZG9tMC4KPgo+IEJ1dCB5b3UgY2FuIHVzZSBYZW4gTmVzdGVk
IEhhcmR3YXJlIFZpcnR1YWxpemF0aW9uIGFuZCBydW4KPiBLVk0vVmlydHVhbEJveCBpbiBYZW4g
SFZNIGd1ZXN0Lgo+IFRoaXMgaXMgYSAidGVjaCBwcmV2aWV3IiBjdXJyZW50bHkuCj4KPiAtLSBQ
YXNpCgpIZWxsbywKCm9rLCB0aGlzIHdvdWxkIGJlIHBvc3NpYmxlIHdpdGggWGVuIDQuMj8gQW5k
IHdvdWxkIGl0IGJlIHBvc3NpYmxlIHRvIAppbXBsZW1lbnQgc29tZXRoaW5nIHRoYXQgS1ZNIGFu
ZCBWaXJ0dWFsQm94IHdvcmsgaW4gYSBYZW4gRG9tMD8gSXMgdGhpcyAKYSB0YXNrIGZvciB0aGUg
WGVuIGRldmVsb3BtZW50IG9yIHNvbWV0aGluZyBmb3IgdGhlIExpbnV4IGtlcm5lbCwsIEtWTSAK
b3IgVmlydHVhbEJveD8KCkJlc3QgUmVnYXJkcwoKX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlz
dHMueGVuLm9yZwpodHRwOi8vbGlzdHMueGVuLm9yZy94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xen.org Thu Sep 20 07:47:21 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Sep 2012 07: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 1TEbTV-0008MB-Lc; Thu, 20 Sep 2012 07:47:05 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1TEbTT-0008M5-ML
	for xen-devel@lists.xen.org; Thu, 20 Sep 2012 07:47:03 +0000
Received: from [85.158.138.51:47594] by server-4.bemta-3.messagelabs.com id
	90/0B-24831-6F9CA505; Thu, 20 Sep 2012 07:47:02 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1348127222!22402548!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4319 invoked from network); 20 Sep 2012 07:47:02 -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;
	20 Sep 2012 07:47:02 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 20 Sep 2012 08:47:01 +0100
Message-Id: <505AE62A020000780009C7F8@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 20 Sep 2012 08:47:22 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Attilio Rao" <attilio.rao@citrix.com>
References: <505A5A03.4000106@citrix.com>
In-Reply-To: <505A5A03.4000106@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel <xen-devel@lists.xen.org>, IanCampbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [RFC] Extend the number of event channels availabe
 to guests
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 20.09.12 at 01:49, Attilio Rao <attilio.rao@citrix.com> wrote:
> Proposal
> The proposal is pretty simple: the eventchannel search will become a 
> three-level lookup table, with the leaf level being composed by shared 
> pages registered at boot time by the guests.
> The bitmap working now as leaf (then called "second level") will work 
> alternatively as leaf level still (for older kernel) or for intermediate 
> level to address into a new array of shared pages (for newer kernels). 
> This leaves the possibility to reuse the existing mechanisms without 
> modifying its internals.

While adding one level would seem to leave ample room, so did
the originally 4096 originally. Therefore, even if unimplemented
right now, I'd like the interface to allow for the guest to specify
more levels.

> More specifically, what needs to happen:
> - Add new members to struct domain to handle an array of pages (to 
> contain the actual evtchn bitmaps), a further array of pages (to contain 
> the evtchn masks) and a control bit to say if it is subjective to the 
> new mode or not. Initially the arrays will be empty and the control bit 
> will be OFF.
> - At init_platform() time, the guest must allocate the pages to compose 
> the 2 arrays and invoke a novel hypercall which, at big lines, does the 
> following:
>    * Creates some pages to populate the new arrays in struct domain via 
> alloc_xenheap_pages()

Why? The guest allocated the pages already. Just have the
hypervisor map them (similar, but without the per-vCPU needs,
to registering an alternative per-vCPU shared page). Whether
it turns out more practical to require the guest to enforce
certain restrictions (like the pages being contiguous and/or
address restricted) is a secondary aspect.

>    * Recreates the mapping with the gpfn passed from the userland, using 
> basically guest_physmap_add_page()

This would then be superfluous.

>    * Sets the control bit to ON
> - Places that need to access to the actual leaf bit (like, for example, 
> xen_evtchn_do_upcall()) will need to double check the control bit. If it 
> is OFF they consider the second level as the leaf one, otherwise they 
> will do a further lookup to get the bit from the new array of pages.

Just like for variable depth page tables - if at all possible, just
make the accesses variable depth, so that all you need to track
on a per-domain basis is the depth of the tree.

> Of course there are some nits to be decided yet, like, for example:
> * How many pages should the new level have? We can start by populating 
> just one, for example

Just let the guest specify this (and error if the number is too large).

> * Who should have really the knowledge of how many pages to allocate? 
> Likely the hypervisor should have a threshhold, but in general we may 
> want to have a posting mechanism to have the guest ask the hypervisor 
> before-hand and satisfy its actual request

Same here (this is really the same with the previous item, if you
follow the earlier suggestions).

> * How many bits should be indirected in the third-level by every single 
> bit in the second-level? (that is a really minor factor, but still).

The tree should clearly be uniform (i.e. having a factor of
BITS_PER_LONG per level), just like it is now. For 64-bit guests,
this would mean 256k channels with 3 levels (32k for 32-bit
guests).

One aspect to also consider is migration - will the guest have to
re-issue the extending hypercall, or will this be taken care of for
it? If the former approach is chosen, would the guest be
expected to deal with not being able to set up the extension
again on the new host?

And another important (but implementation only) aspect not to
forget is making domain_dump_evtchn_info() scale with the
then much higher amount of dumping potentially to be done (i.e.
not just extend it to cope with the count, but also make sure it
properly allows softirqs to be handled, which in turn requires to
not hold the event lock across the whole loop).

Jan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 20 07:47:21 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Sep 2012 07: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 1TEbTV-0008MB-Lc; Thu, 20 Sep 2012 07:47:05 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1TEbTT-0008M5-ML
	for xen-devel@lists.xen.org; Thu, 20 Sep 2012 07:47:03 +0000
Received: from [85.158.138.51:47594] by server-4.bemta-3.messagelabs.com id
	90/0B-24831-6F9CA505; Thu, 20 Sep 2012 07:47:02 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1348127222!22402548!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4319 invoked from network); 20 Sep 2012 07:47:02 -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;
	20 Sep 2012 07:47:02 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 20 Sep 2012 08:47:01 +0100
Message-Id: <505AE62A020000780009C7F8@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 20 Sep 2012 08:47:22 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Attilio Rao" <attilio.rao@citrix.com>
References: <505A5A03.4000106@citrix.com>
In-Reply-To: <505A5A03.4000106@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel <xen-devel@lists.xen.org>, IanCampbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [RFC] Extend the number of event channels availabe
 to guests
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 20.09.12 at 01:49, Attilio Rao <attilio.rao@citrix.com> wrote:
> Proposal
> The proposal is pretty simple: the eventchannel search will become a 
> three-level lookup table, with the leaf level being composed by shared 
> pages registered at boot time by the guests.
> The bitmap working now as leaf (then called "second level") will work 
> alternatively as leaf level still (for older kernel) or for intermediate 
> level to address into a new array of shared pages (for newer kernels). 
> This leaves the possibility to reuse the existing mechanisms without 
> modifying its internals.

While adding one level would seem to leave ample room, so did
the originally 4096 originally. Therefore, even if unimplemented
right now, I'd like the interface to allow for the guest to specify
more levels.

> More specifically, what needs to happen:
> - Add new members to struct domain to handle an array of pages (to 
> contain the actual evtchn bitmaps), a further array of pages (to contain 
> the evtchn masks) and a control bit to say if it is subjective to the 
> new mode or not. Initially the arrays will be empty and the control bit 
> will be OFF.
> - At init_platform() time, the guest must allocate the pages to compose 
> the 2 arrays and invoke a novel hypercall which, at big lines, does the 
> following:
>    * Creates some pages to populate the new arrays in struct domain via 
> alloc_xenheap_pages()

Why? The guest allocated the pages already. Just have the
hypervisor map them (similar, but without the per-vCPU needs,
to registering an alternative per-vCPU shared page). Whether
it turns out more practical to require the guest to enforce
certain restrictions (like the pages being contiguous and/or
address restricted) is a secondary aspect.

>    * Recreates the mapping with the gpfn passed from the userland, using 
> basically guest_physmap_add_page()

This would then be superfluous.

>    * Sets the control bit to ON
> - Places that need to access to the actual leaf bit (like, for example, 
> xen_evtchn_do_upcall()) will need to double check the control bit. If it 
> is OFF they consider the second level as the leaf one, otherwise they 
> will do a further lookup to get the bit from the new array of pages.

Just like for variable depth page tables - if at all possible, just
make the accesses variable depth, so that all you need to track
on a per-domain basis is the depth of the tree.

> Of course there are some nits to be decided yet, like, for example:
> * How many pages should the new level have? We can start by populating 
> just one, for example

Just let the guest specify this (and error if the number is too large).

> * Who should have really the knowledge of how many pages to allocate? 
> Likely the hypervisor should have a threshhold, but in general we may 
> want to have a posting mechanism to have the guest ask the hypervisor 
> before-hand and satisfy its actual request

Same here (this is really the same with the previous item, if you
follow the earlier suggestions).

> * How many bits should be indirected in the third-level by every single 
> bit in the second-level? (that is a really minor factor, but still).

The tree should clearly be uniform (i.e. having a factor of
BITS_PER_LONG per level), just like it is now. For 64-bit guests,
this would mean 256k channels with 3 levels (32k for 32-bit
guests).

One aspect to also consider is migration - will the guest have to
re-issue the extending hypercall, or will this be taken care of for
it? If the former approach is chosen, would the guest be
expected to deal with not being able to set up the extension
again on the new host?

And another important (but implementation only) aspect not to
forget is making domain_dump_evtchn_info() scale with the
then much higher amount of dumping potentially to be done (i.e.
not just extend it to cope with the count, but also make sure it
properly allows softirqs to be handled, which in turn requires to
not hold the event lock across the whole loop).

Jan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 20 07:52:50 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Sep 2012 07:52: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 1TEbYq-00007i-8b; Thu, 20 Sep 2012 07:52:36 +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 1TEbYo-00007d-TX
	for xen-devel@lists.xensource.com; Thu, 20 Sep 2012 07:52:35 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-12.tower-27.messagelabs.com!1348127539!11719980!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA1MDkwNzg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 670 invoked from network); 20 Sep 2012 07:52:20 -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; 20 Sep 2012 07:52:20 -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 2998F2A45;
	Thu, 20 Sep 2012 10:52:18 +0300 (EEST)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id 0258D2005D; Thu, 20 Sep 2012 10:52:18 +0300 (EEST)
Date: Thu, 20 Sep 2012 10:52:17 +0300
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: Lukas Laukamp <lukas@laukamp.me>
Message-ID: <20120920075217.GV8912@reaktio.net>
References: <c277ee4a34ca57f7da68f2e0ab832090@laukamp.me>
	<20120920073643.GU8912@reaktio.net>
	<bce40f714cae80dfd919b3d2c4e870e4@laukamp.me>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <bce40f714cae80dfd919b3d2c4e870e4@laukamp.me>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [User Question] KVM and VirtualBox in 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="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, Sep 20, 2012 at 09:44:41AM +0200, Lukas Laukamp wrote:
> Am 2012-09-20 09:36, schrieb Pasi K=E4rkk=E4inen:
> >On Thu, Sep 20, 2012 at 09:11:44AM +0200, Lukas Laukamp wrote:
> >>Hello all,
> >>
> >>I have a simple user question but it's very technical and related to
> >>the Xen core. Does KVM and VirtualBox work in a Xen Dom0 with Xen
> >>4.2? So I would like to create a VM Host for deploying VM templates
> >>which are compatible to the most solutions and host systems and I
> >>think that Xen, KVM/QEmu and VirtualBox are the best choice for
> >>this.
> >>
> >>Would be great when this is possible or could be implemented. Hope
> >>that someone can give me an answer.
> >>
> >
> >Nope, KVM or VirtualBox won't work in Xen dom0.
> >
> >But you can use Xen Nested Hardware Virtualization and run
> >KVM/VirtualBox in Xen HVM guest.
> >This is a "tech preview" currently.
> >
> >-- Pasi
> =

> Hello,
> =

> ok, this would be possible with Xen 4.2?
>

In Xen 4.2.0 I think Nested Virt should work on AMD CPUs,
but Intel CPUs require some additional patches that aren't yet in 4.2 branc=
h.

> And would it be possible to implement something that KVM and VirtualBox w=
ork in a Xen Dom0?
>

Why do you want to run them in dom0 ? =


> Is this a task for the Xen development or something for the Linux
> kernel,, KVM or VirtualBox?
> =


I think it *might* be possible when Xen PVH (Hybrid) is merged to Xen 4.3,
which basically allows running Xen dom0 in HVM container.

-- Pasi


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 20 07:52:50 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Sep 2012 07:52: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 1TEbYq-00007i-8b; Thu, 20 Sep 2012 07:52:36 +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 1TEbYo-00007d-TX
	for xen-devel@lists.xensource.com; Thu, 20 Sep 2012 07:52:35 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-12.tower-27.messagelabs.com!1348127539!11719980!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA1MDkwNzg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 670 invoked from network); 20 Sep 2012 07:52:20 -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; 20 Sep 2012 07:52:20 -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 2998F2A45;
	Thu, 20 Sep 2012 10:52:18 +0300 (EEST)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id 0258D2005D; Thu, 20 Sep 2012 10:52:18 +0300 (EEST)
Date: Thu, 20 Sep 2012 10:52:17 +0300
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: Lukas Laukamp <lukas@laukamp.me>
Message-ID: <20120920075217.GV8912@reaktio.net>
References: <c277ee4a34ca57f7da68f2e0ab832090@laukamp.me>
	<20120920073643.GU8912@reaktio.net>
	<bce40f714cae80dfd919b3d2c4e870e4@laukamp.me>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <bce40f714cae80dfd919b3d2c4e870e4@laukamp.me>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [User Question] KVM and VirtualBox in 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="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, Sep 20, 2012 at 09:44:41AM +0200, Lukas Laukamp wrote:
> Am 2012-09-20 09:36, schrieb Pasi K=E4rkk=E4inen:
> >On Thu, Sep 20, 2012 at 09:11:44AM +0200, Lukas Laukamp wrote:
> >>Hello all,
> >>
> >>I have a simple user question but it's very technical and related to
> >>the Xen core. Does KVM and VirtualBox work in a Xen Dom0 with Xen
> >>4.2? So I would like to create a VM Host for deploying VM templates
> >>which are compatible to the most solutions and host systems and I
> >>think that Xen, KVM/QEmu and VirtualBox are the best choice for
> >>this.
> >>
> >>Would be great when this is possible or could be implemented. Hope
> >>that someone can give me an answer.
> >>
> >
> >Nope, KVM or VirtualBox won't work in Xen dom0.
> >
> >But you can use Xen Nested Hardware Virtualization and run
> >KVM/VirtualBox in Xen HVM guest.
> >This is a "tech preview" currently.
> >
> >-- Pasi
> =

> Hello,
> =

> ok, this would be possible with Xen 4.2?
>

In Xen 4.2.0 I think Nested Virt should work on AMD CPUs,
but Intel CPUs require some additional patches that aren't yet in 4.2 branc=
h.

> And would it be possible to implement something that KVM and VirtualBox w=
ork in a Xen Dom0?
>

Why do you want to run them in dom0 ? =


> Is this a task for the Xen development or something for the Linux
> kernel,, KVM or VirtualBox?
> =


I think it *might* be possible when Xen PVH (Hybrid) is merged to Xen 4.3,
which basically allows running Xen dom0 in HVM container.

-- Pasi


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 20 07:56:36 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Sep 2012 07:56:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TEbcT-0000FN-UE; Thu, 20 Sep 2012 07:56: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 1TEbcS-0000FG-O9
	for xen-devel@lists.xen.org; Thu, 20 Sep 2012 07:56:21 +0000
Received: from [85.158.139.83:36704] by server-7.bemta-5.messagelabs.com id
	1A/E9-19703-32CCA505; Thu, 20 Sep 2012 07:56:19 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1348127778!31162692!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTAzMDk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16538 invoked from network); 20 Sep 2012 07:56:19 -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 Sep 2012 07:56:19 -0000
X-IronPort-AV: E=Sophos;i="4.80,453,1344211200"; d="scan'208";a="14646638"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Sep 2012 07:55: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.279.1;
	Thu, 20 Sep 2012 08:55:37 +0100
Message-ID: <1348127736.26501.10.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Thu, 20 Sep 2012 08:55:36 +0100
In-Reply-To: <505AE62A020000780009C7F8@nat28.tlf.novell.com>
References: <505A5A03.4000106@citrix.com>
	<505AE62A020000780009C7F8@nat28.tlf.novell.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Attilio Rao <attilio.rao@citrix.com>, xen-devel <xen-devel@lists.xen.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [RFC] Extend the number of event channels availabe
 to guests
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-09-20 at 08:47 +0100, Jan Beulich wrote:
> One aspect to also consider is migration - will the guest have to
> re-issue the extending hypercall, or will this be taken care of for
> it? If the former approach is chosen, would the guest be
> expected to deal with not being able to set up the extension
> again on the new host? 

We only properly care about N->N and N->N+1 migrations, if we think that
we would never reduce the limit over a hypervisor version upgrade then
this would be fine, I think.

We do a similar thing with the grant table v2 stuff I think, i.e. panic
after migration if we can't setup the feature again.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 20 07:56:36 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Sep 2012 07:56:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TEbcT-0000FN-UE; Thu, 20 Sep 2012 07:56: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 1TEbcS-0000FG-O9
	for xen-devel@lists.xen.org; Thu, 20 Sep 2012 07:56:21 +0000
Received: from [85.158.139.83:36704] by server-7.bemta-5.messagelabs.com id
	1A/E9-19703-32CCA505; Thu, 20 Sep 2012 07:56:19 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1348127778!31162692!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTAzMDk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16538 invoked from network); 20 Sep 2012 07:56:19 -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 Sep 2012 07:56:19 -0000
X-IronPort-AV: E=Sophos;i="4.80,453,1344211200"; d="scan'208";a="14646638"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Sep 2012 07:55: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.279.1;
	Thu, 20 Sep 2012 08:55:37 +0100
Message-ID: <1348127736.26501.10.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Thu, 20 Sep 2012 08:55:36 +0100
In-Reply-To: <505AE62A020000780009C7F8@nat28.tlf.novell.com>
References: <505A5A03.4000106@citrix.com>
	<505AE62A020000780009C7F8@nat28.tlf.novell.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Attilio Rao <attilio.rao@citrix.com>, xen-devel <xen-devel@lists.xen.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [RFC] Extend the number of event channels availabe
 to guests
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-09-20 at 08:47 +0100, Jan Beulich wrote:
> One aspect to also consider is migration - will the guest have to
> re-issue the extending hypercall, or will this be taken care of for
> it? If the former approach is chosen, would the guest be
> expected to deal with not being able to set up the extension
> again on the new host? 

We only properly care about N->N and N->N+1 migrations, if we think that
we would never reduce the limit over a hypervisor version upgrade then
this would be fine, I think.

We do a similar thing with the grant table v2 stuff I think, i.e. panic
after migration if we can't setup the feature again.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 20 08:03:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Sep 2012 08: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 1TEbim-0000sK-2B; Thu, 20 Sep 2012 08:02:52 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1TEbik-0000sE-L2
	for xen-devel@lists.xen.org; Thu, 20 Sep 2012 08:02:50 +0000
Received: from [85.158.139.211:20680] by server-4.bemta-5.messagelabs.com id
	22/C7-23042-9ADCA505; Thu, 20 Sep 2012 08:02:49 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-5.tower-206.messagelabs.com!1348128169!19224356!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15327 invoked from network); 20 Sep 2012 08:02:49 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-5.tower-206.messagelabs.com with SMTP;
	20 Sep 2012 08:02:49 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 20 Sep 2012 09:02:48 +0100
Message-Id: <505AE9DB020000780009C813@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 20 Sep 2012 09:03:07 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Keir Fraser" <keir.xen@gmail.com>,"Ben Guthro" <ben@guthro.net>
References: <CAOvdn6Xn1ZnontBO0KoJE9hgBsW-a1rR2EhWYEpgbbrELkXZNw@mail.gmail.com>
	<CC80728B.3F362%keir.xen@gmail.com>
In-Reply-To: <CC80728B.3F362%keir.xen@gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>, john.baboval@citrix.com,
	Thomas Goetz <thomas.goetz@citrix.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen4.2 S3 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="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Pj4+IE9uIDIwLjA5LjEyIGF0IDA4OjEzLCBLZWlyIEZyYXNlciA8a2Vpci54ZW5AZ21haWwuY29t
PiB3cm90ZToKPiBDUFUjMSBnb3Qgc3R1Y2sgaW4gbG9vcCBpbiBjcHVfaW5pdCgpIGFzIGl0IGFw
cGVhcnMgdG8gYmUgxZJhbHJlYWR5Cj4gaW5pdGlhbGlzZWTCuSBpbiBjcHVfaW5pdGlhbGl6ZWQg
Yml0bWFwLiBDUFUjMCBkZXRlY3RzIGl0IGlzIHN0dWNrIGFuZAo+IGNhcnJpZXMgb24sIGJ1dCB0
aGUgcmVzdW1lIGNvZGUgYXNzdW1lcyBhbGwgQ1BVcyBhcmUgYnJvdWdodCBiYWNrIG9ubGluZSBh
bmQKPiBjcmFzaGVzIGxhdGVyLgoKU28gdGhpcyB3b3VsZCBzdWdnZXN0IHBsYXlfZGVhZCgpICgt
PiBjcHVfZXhpdF9jbGVhcigpIC0+CmNwdV91bmluaXQoKSkgbm90IGdldHRpbmcgcmVhY2hlZCBk
dXJpbmcgdGhlIHN1c3BlbmQgY3ljbGUuClRoYXQgc2hvdWxkIGJlIGZhaXJseSBlYXN5IHRvIHZl
cmlmeSwgYXMgdGhlIHNlcmlhbCBjb25zb2xlCm91Z2h0IHRvIHN0aWxsIHdvcmsgd2hlbiB0aGUg
c2Vjb25kYXJ5IENQVXMgZ2V0IG9mZmxpbmVkLgoKVGhhdCBtaWdodCBpbXBseSBjcHVtYXNrX2Ns
ZWFyX2NwdShjcHUsICZjcHVfb25saW5lX21hcCkKbm90IGdldHRpbmcgcmVhY2hlZCBpbiBfX2Nw
dV9kaXNhYmxlKCksIHdoaWNoIHdvdWxkIGJlIGluIGxpbmUKd2l0aCB0aGUgb2JzZXJ2YXRpb24g
dGhhdCBub25lIG9mIHRoZSBsb2dzIHByb3ZpZGVkIHNvIGZhcgpzaG93ZWQgYW55dGhpbmcgYmVp
bmcgZG9uZSBieSBmaXh1cF9pcnFzKCkgKGNhbGxlZCByaWdodAphZnRlciBjbGVhcmluZyB0aGUg
b25saW5lIGJpdCkuCgpKYW4KCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbi5vcmcK
aHR0cDovL2xpc3RzLnhlbi5vcmcveGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Thu Sep 20 08:03:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Sep 2012 08: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 1TEbim-0000sK-2B; Thu, 20 Sep 2012 08:02:52 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1TEbik-0000sE-L2
	for xen-devel@lists.xen.org; Thu, 20 Sep 2012 08:02:50 +0000
Received: from [85.158.139.211:20680] by server-4.bemta-5.messagelabs.com id
	22/C7-23042-9ADCA505; Thu, 20 Sep 2012 08:02:49 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-5.tower-206.messagelabs.com!1348128169!19224356!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15327 invoked from network); 20 Sep 2012 08:02:49 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-5.tower-206.messagelabs.com with SMTP;
	20 Sep 2012 08:02:49 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 20 Sep 2012 09:02:48 +0100
Message-Id: <505AE9DB020000780009C813@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 20 Sep 2012 09:03:07 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Keir Fraser" <keir.xen@gmail.com>,"Ben Guthro" <ben@guthro.net>
References: <CAOvdn6Xn1ZnontBO0KoJE9hgBsW-a1rR2EhWYEpgbbrELkXZNw@mail.gmail.com>
	<CC80728B.3F362%keir.xen@gmail.com>
In-Reply-To: <CC80728B.3F362%keir.xen@gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>, john.baboval@citrix.com,
	Thomas Goetz <thomas.goetz@citrix.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen4.2 S3 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="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Pj4+IE9uIDIwLjA5LjEyIGF0IDA4OjEzLCBLZWlyIEZyYXNlciA8a2Vpci54ZW5AZ21haWwuY29t
PiB3cm90ZToKPiBDUFUjMSBnb3Qgc3R1Y2sgaW4gbG9vcCBpbiBjcHVfaW5pdCgpIGFzIGl0IGFw
cGVhcnMgdG8gYmUgxZJhbHJlYWR5Cj4gaW5pdGlhbGlzZWTCuSBpbiBjcHVfaW5pdGlhbGl6ZWQg
Yml0bWFwLiBDUFUjMCBkZXRlY3RzIGl0IGlzIHN0dWNrIGFuZAo+IGNhcnJpZXMgb24sIGJ1dCB0
aGUgcmVzdW1lIGNvZGUgYXNzdW1lcyBhbGwgQ1BVcyBhcmUgYnJvdWdodCBiYWNrIG9ubGluZSBh
bmQKPiBjcmFzaGVzIGxhdGVyLgoKU28gdGhpcyB3b3VsZCBzdWdnZXN0IHBsYXlfZGVhZCgpICgt
PiBjcHVfZXhpdF9jbGVhcigpIC0+CmNwdV91bmluaXQoKSkgbm90IGdldHRpbmcgcmVhY2hlZCBk
dXJpbmcgdGhlIHN1c3BlbmQgY3ljbGUuClRoYXQgc2hvdWxkIGJlIGZhaXJseSBlYXN5IHRvIHZl
cmlmeSwgYXMgdGhlIHNlcmlhbCBjb25zb2xlCm91Z2h0IHRvIHN0aWxsIHdvcmsgd2hlbiB0aGUg
c2Vjb25kYXJ5IENQVXMgZ2V0IG9mZmxpbmVkLgoKVGhhdCBtaWdodCBpbXBseSBjcHVtYXNrX2Ns
ZWFyX2NwdShjcHUsICZjcHVfb25saW5lX21hcCkKbm90IGdldHRpbmcgcmVhY2hlZCBpbiBfX2Nw
dV9kaXNhYmxlKCksIHdoaWNoIHdvdWxkIGJlIGluIGxpbmUKd2l0aCB0aGUgb2JzZXJ2YXRpb24g
dGhhdCBub25lIG9mIHRoZSBsb2dzIHByb3ZpZGVkIHNvIGZhcgpzaG93ZWQgYW55dGhpbmcgYmVp
bmcgZG9uZSBieSBmaXh1cF9pcnFzKCkgKGNhbGxlZCByaWdodAphZnRlciBjbGVhcmluZyB0aGUg
b25saW5lIGJpdCkuCgpKYW4KCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbi5vcmcK
aHR0cDovL2xpc3RzLnhlbi5vcmcveGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Thu Sep 20 08:04:02 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Sep 2012 08: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 1TEbje-0000xH-HI; Thu, 20 Sep 2012 08:03:46 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <lukas@laukamp.me>) id 1TEbjd-0000x7-Pn
	for xen-devel@lists.xensource.com; Thu, 20 Sep 2012 08:03:45 +0000
Received: from [85.158.139.83:36237] by server-5.bemta-5.messagelabs.com id
	F0/78-30514-0EDCA505; Thu, 20 Sep 2012 08:03:44 +0000
X-Env-Sender: lukas@laukamp.me
X-Msg-Ref: server-10.tower-182.messagelabs.com!1348128224!31611123!1
X-Originating-IP: [5.9.218.245]
X-SpamReason: No, hits=0.2 required=7.0 tests=RCVD_ILLEGAL_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19936 invoked from network); 20 Sep 2012 08:03:44 -0000
Received: from mailer0.lippux.de (HELO mailer0.lippux.de) (5.9.218.245)
	by server-10.tower-182.messagelabs.com with SMTP;
	20 Sep 2012 08:03:44 -0000
Received: from localhost (localhost [127.0.0.1])
	by mailer0.lippux.de (Postfix) with ESMTP id EC0724222D5;
	Thu, 20 Sep 2012 10:03:43 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at mailer0.lippux.de
Received: from mailer0.lippux.de ([127.0.0.1])
	by localhost (mailer0.lippux.de [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id VNvqLKaIeth5; Thu, 20 Sep 2012 10:03:43 +0200 (CEST)
Received: by mailer0.lippux.de (Postfix, from userid 33)
	id A84BB422102; Thu, 20 Sep 2012 10:03:43 +0200 (CEST)
To: =?UTF-8?Q?Pasi_K=C3=A4rkk=C3=A4inen?= <pasik@iki.fi>
X-PHP-Originating-Script: 0:main.inc
MIME-Version: 1.0
Date: Thu, 20 Sep 2012 10:03:43 +0200
From: Lukas Laukamp <lukas@laukamp.me>
In-Reply-To: <20120920075217.GV8912@reaktio.net>
References: <c277ee4a34ca57f7da68f2e0ab832090@laukamp.me>
	<20120920073643.GU8912@reaktio.net>
	<bce40f714cae80dfd919b3d2c4e870e4@laukamp.me>
	<20120920075217.GV8912@reaktio.net>
Message-ID: <7d9d2235fa5d81bf4bd8847b9ad89226@laukamp.me>
X-Sender: lukas@laukamp.me
User-Agent: Roundcube Webmail/0.7.1
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [User Question] KVM and VirtualBox in 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: 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

QW0gMjAxMi0wOS0yMCAwOTo1Miwgc2NocmllYiBQYXNpIEvDpHJra8OkaW5lbjoKPiBPbiBUaHUs
IFNlcCAyMCwgMjAxMiBhdCAwOTo0NDo0MUFNICswMjAwLCBMdWthcyBMYXVrYW1wIHdyb3RlOgo+
PiBBbSAyMDEyLTA5LTIwIDA5OjM2LCBzY2hyaWViIFBhc2kgS8Okcmtrw6RpbmVuOgo+PiA+T24g
VGh1LCBTZXAgMjAsIDIwMTIgYXQgMDk6MTE6NDRBTSArMDIwMCwgTHVrYXMgTGF1a2FtcCB3cm90
ZToKPj4gPj5IZWxsbyBhbGwsCj4+ID4+Cj4+ID4+SSBoYXZlIGEgc2ltcGxlIHVzZXIgcXVlc3Rp
b24gYnV0IGl0J3MgdmVyeSB0ZWNobmljYWwgYW5kIHJlbGF0ZWQgCj4+IHRvCj4+ID4+dGhlIFhl
biBjb3JlLiBEb2VzIEtWTSBhbmQgVmlydHVhbEJveCB3b3JrIGluIGEgWGVuIERvbTAgd2l0aCBY
ZW4KPj4gPj40LjI/IFNvIEkgd291bGQgbGlrZSB0byBjcmVhdGUgYSBWTSBIb3N0IGZvciBkZXBs
b3lpbmcgVk0gCj4+IHRlbXBsYXRlcwo+PiA+PndoaWNoIGFyZSBjb21wYXRpYmxlIHRvIHRoZSBt
b3N0IHNvbHV0aW9ucyBhbmQgaG9zdCBzeXN0ZW1zIGFuZCBJCj4+ID4+dGhpbmsgdGhhdCBYZW4s
IEtWTS9RRW11IGFuZCBWaXJ0dWFsQm94IGFyZSB0aGUgYmVzdCBjaG9pY2UgZm9yCj4+ID4+dGhp
cy4KPj4gPj4KPj4gPj5Xb3VsZCBiZSBncmVhdCB3aGVuIHRoaXMgaXMgcG9zc2libGUgb3IgY291
bGQgYmUgaW1wbGVtZW50ZWQuIEhvcGUKPj4gPj50aGF0IHNvbWVvbmUgY2FuIGdpdmUgbWUgYW4g
YW5zd2VyLgo+PiA+Pgo+PiA+Cj4+ID5Ob3BlLCBLVk0gb3IgVmlydHVhbEJveCB3b24ndCB3b3Jr
IGluIFhlbiBkb20wLgo+PiA+Cj4+ID5CdXQgeW91IGNhbiB1c2UgWGVuIE5lc3RlZCBIYXJkd2Fy
ZSBWaXJ0dWFsaXphdGlvbiBhbmQgcnVuCj4+ID5LVk0vVmlydHVhbEJveCBpbiBYZW4gSFZNIGd1
ZXN0Lgo+PiA+VGhpcyBpcyBhICJ0ZWNoIHByZXZpZXciIGN1cnJlbnRseS4KPj4gPgo+PiA+LS0g
UGFzaQo+Pgo+PiBIZWxsbywKPj4KPj4gb2ssIHRoaXMgd291bGQgYmUgcG9zc2libGUgd2l0aCBY
ZW4gNC4yPwo+Pgo+Cj4gSW4gWGVuIDQuMi4wIEkgdGhpbmsgTmVzdGVkIFZpcnQgc2hvdWxkIHdv
cmsgb24gQU1EIENQVXMsCj4gYnV0IEludGVsIENQVXMgcmVxdWlyZSBzb21lIGFkZGl0aW9uYWwg
cGF0Y2hlcyB0aGF0IGFyZW4ndCB5ZXQgaW4gNC4yIAo+IGJyYW5jaC4KPgo+PiBBbmQgd291bGQg
aXQgYmUgcG9zc2libGUgdG8gaW1wbGVtZW50IHNvbWV0aGluZyB0aGF0IEtWTSBhbmQgCj4+IFZp
cnR1YWxCb3ggd29yayBpbiBhIFhlbiBEb20wPwo+Pgo+Cj4gV2h5IGRvIHlvdSB3YW50IHRvIHJ1
biB0aGVtIGluIGRvbTAgPwo+Cj4+IElzIHRoaXMgYSB0YXNrIGZvciB0aGUgWGVuIGRldmVsb3Bt
ZW50IG9yIHNvbWV0aGluZyBmb3IgdGhlIExpbnV4Cj4+IGtlcm5lbCwsIEtWTSBvciBWaXJ0dWFs
Qm94Pwo+Pgo+Cj4gSSB0aGluayBpdCAqbWlnaHQqIGJlIHBvc3NpYmxlIHdoZW4gWGVuIFBWSCAo
SHlicmlkKSBpcyBtZXJnZWQgdG8gWGVuIAo+IDQuMywKPiB3aGljaCBiYXNpY2FsbHkgYWxsb3dz
IHJ1bm5pbmcgWGVuIGRvbTAgaW4gSFZNIGNvbnRhaW5lci4KPgo+IC0tIFBhc2kKCkhlbGxvLAoK
SSBnb29nbGVkIGZvciB4ZW4gSHlicmlkLCBidXQgaGF2ZSBxdWVzdGlvbiBpZiBJIHVuZGVyc3Rh
bmQgaXQgY29ycmVjdC4gCk5vdyB0aGUgRG9tMCBpcyBhIFBWIEd1ZXN0LiBXaXRoIFhlbiBIeWJy
aWQgdGhlIERvbTAgY2FuIHJ1biBhcyBhIEhWTSAKd2l0aCBQViBmZWF0dXJlcyBvbiB0aGUgaHlw
ZXJ2aXNvci4gVGhpcyB3b3VsZCBtYWtlIGl0IHBvc3NpYmxlIGJlY2F1c2UgCm9mIG5lc3RlZCB2
aXJ0dWFsaXphdGlvbiB0aGF0IEtWTSBhbmQgVmlydHVhbEJveCBydW4gaW5zaWRlIGRvbTAgcmln
aHQ/CgpBbmQgbXkgc2Vjb25kIHF1ZXN0aW9uIHdvdWxkIGJlOiBJcyB0aGUgYWltIG9mIFhlbiBo
eWJyaWQgdG8gYnJpbmcgRG9tMCAKc3VwcG9ydCB0byBtb3JlIE9TZXM/CgpCZXN0IFJlZ2FyZHMK
Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fClhlbi1kZXZl
bCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbi5vcmcKaHR0cDovL2xpc3RzLnhlbi5v
cmcveGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Thu Sep 20 08:04:02 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Sep 2012 08: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 1TEbje-0000xH-HI; Thu, 20 Sep 2012 08:03:46 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <lukas@laukamp.me>) id 1TEbjd-0000x7-Pn
	for xen-devel@lists.xensource.com; Thu, 20 Sep 2012 08:03:45 +0000
Received: from [85.158.139.83:36237] by server-5.bemta-5.messagelabs.com id
	F0/78-30514-0EDCA505; Thu, 20 Sep 2012 08:03:44 +0000
X-Env-Sender: lukas@laukamp.me
X-Msg-Ref: server-10.tower-182.messagelabs.com!1348128224!31611123!1
X-Originating-IP: [5.9.218.245]
X-SpamReason: No, hits=0.2 required=7.0 tests=RCVD_ILLEGAL_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19936 invoked from network); 20 Sep 2012 08:03:44 -0000
Received: from mailer0.lippux.de (HELO mailer0.lippux.de) (5.9.218.245)
	by server-10.tower-182.messagelabs.com with SMTP;
	20 Sep 2012 08:03:44 -0000
Received: from localhost (localhost [127.0.0.1])
	by mailer0.lippux.de (Postfix) with ESMTP id EC0724222D5;
	Thu, 20 Sep 2012 10:03:43 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at mailer0.lippux.de
Received: from mailer0.lippux.de ([127.0.0.1])
	by localhost (mailer0.lippux.de [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id VNvqLKaIeth5; Thu, 20 Sep 2012 10:03:43 +0200 (CEST)
Received: by mailer0.lippux.de (Postfix, from userid 33)
	id A84BB422102; Thu, 20 Sep 2012 10:03:43 +0200 (CEST)
To: =?UTF-8?Q?Pasi_K=C3=A4rkk=C3=A4inen?= <pasik@iki.fi>
X-PHP-Originating-Script: 0:main.inc
MIME-Version: 1.0
Date: Thu, 20 Sep 2012 10:03:43 +0200
From: Lukas Laukamp <lukas@laukamp.me>
In-Reply-To: <20120920075217.GV8912@reaktio.net>
References: <c277ee4a34ca57f7da68f2e0ab832090@laukamp.me>
	<20120920073643.GU8912@reaktio.net>
	<bce40f714cae80dfd919b3d2c4e870e4@laukamp.me>
	<20120920075217.GV8912@reaktio.net>
Message-ID: <7d9d2235fa5d81bf4bd8847b9ad89226@laukamp.me>
X-Sender: lukas@laukamp.me
User-Agent: Roundcube Webmail/0.7.1
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [User Question] KVM and VirtualBox in 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: 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

QW0gMjAxMi0wOS0yMCAwOTo1Miwgc2NocmllYiBQYXNpIEvDpHJra8OkaW5lbjoKPiBPbiBUaHUs
IFNlcCAyMCwgMjAxMiBhdCAwOTo0NDo0MUFNICswMjAwLCBMdWthcyBMYXVrYW1wIHdyb3RlOgo+
PiBBbSAyMDEyLTA5LTIwIDA5OjM2LCBzY2hyaWViIFBhc2kgS8Okcmtrw6RpbmVuOgo+PiA+T24g
VGh1LCBTZXAgMjAsIDIwMTIgYXQgMDk6MTE6NDRBTSArMDIwMCwgTHVrYXMgTGF1a2FtcCB3cm90
ZToKPj4gPj5IZWxsbyBhbGwsCj4+ID4+Cj4+ID4+SSBoYXZlIGEgc2ltcGxlIHVzZXIgcXVlc3Rp
b24gYnV0IGl0J3MgdmVyeSB0ZWNobmljYWwgYW5kIHJlbGF0ZWQgCj4+IHRvCj4+ID4+dGhlIFhl
biBjb3JlLiBEb2VzIEtWTSBhbmQgVmlydHVhbEJveCB3b3JrIGluIGEgWGVuIERvbTAgd2l0aCBY
ZW4KPj4gPj40LjI/IFNvIEkgd291bGQgbGlrZSB0byBjcmVhdGUgYSBWTSBIb3N0IGZvciBkZXBs
b3lpbmcgVk0gCj4+IHRlbXBsYXRlcwo+PiA+PndoaWNoIGFyZSBjb21wYXRpYmxlIHRvIHRoZSBt
b3N0IHNvbHV0aW9ucyBhbmQgaG9zdCBzeXN0ZW1zIGFuZCBJCj4+ID4+dGhpbmsgdGhhdCBYZW4s
IEtWTS9RRW11IGFuZCBWaXJ0dWFsQm94IGFyZSB0aGUgYmVzdCBjaG9pY2UgZm9yCj4+ID4+dGhp
cy4KPj4gPj4KPj4gPj5Xb3VsZCBiZSBncmVhdCB3aGVuIHRoaXMgaXMgcG9zc2libGUgb3IgY291
bGQgYmUgaW1wbGVtZW50ZWQuIEhvcGUKPj4gPj50aGF0IHNvbWVvbmUgY2FuIGdpdmUgbWUgYW4g
YW5zd2VyLgo+PiA+Pgo+PiA+Cj4+ID5Ob3BlLCBLVk0gb3IgVmlydHVhbEJveCB3b24ndCB3b3Jr
IGluIFhlbiBkb20wLgo+PiA+Cj4+ID5CdXQgeW91IGNhbiB1c2UgWGVuIE5lc3RlZCBIYXJkd2Fy
ZSBWaXJ0dWFsaXphdGlvbiBhbmQgcnVuCj4+ID5LVk0vVmlydHVhbEJveCBpbiBYZW4gSFZNIGd1
ZXN0Lgo+PiA+VGhpcyBpcyBhICJ0ZWNoIHByZXZpZXciIGN1cnJlbnRseS4KPj4gPgo+PiA+LS0g
UGFzaQo+Pgo+PiBIZWxsbywKPj4KPj4gb2ssIHRoaXMgd291bGQgYmUgcG9zc2libGUgd2l0aCBY
ZW4gNC4yPwo+Pgo+Cj4gSW4gWGVuIDQuMi4wIEkgdGhpbmsgTmVzdGVkIFZpcnQgc2hvdWxkIHdv
cmsgb24gQU1EIENQVXMsCj4gYnV0IEludGVsIENQVXMgcmVxdWlyZSBzb21lIGFkZGl0aW9uYWwg
cGF0Y2hlcyB0aGF0IGFyZW4ndCB5ZXQgaW4gNC4yIAo+IGJyYW5jaC4KPgo+PiBBbmQgd291bGQg
aXQgYmUgcG9zc2libGUgdG8gaW1wbGVtZW50IHNvbWV0aGluZyB0aGF0IEtWTSBhbmQgCj4+IFZp
cnR1YWxCb3ggd29yayBpbiBhIFhlbiBEb20wPwo+Pgo+Cj4gV2h5IGRvIHlvdSB3YW50IHRvIHJ1
biB0aGVtIGluIGRvbTAgPwo+Cj4+IElzIHRoaXMgYSB0YXNrIGZvciB0aGUgWGVuIGRldmVsb3Bt
ZW50IG9yIHNvbWV0aGluZyBmb3IgdGhlIExpbnV4Cj4+IGtlcm5lbCwsIEtWTSBvciBWaXJ0dWFs
Qm94Pwo+Pgo+Cj4gSSB0aGluayBpdCAqbWlnaHQqIGJlIHBvc3NpYmxlIHdoZW4gWGVuIFBWSCAo
SHlicmlkKSBpcyBtZXJnZWQgdG8gWGVuIAo+IDQuMywKPiB3aGljaCBiYXNpY2FsbHkgYWxsb3dz
IHJ1bm5pbmcgWGVuIGRvbTAgaW4gSFZNIGNvbnRhaW5lci4KPgo+IC0tIFBhc2kKCkhlbGxvLAoK
SSBnb29nbGVkIGZvciB4ZW4gSHlicmlkLCBidXQgaGF2ZSBxdWVzdGlvbiBpZiBJIHVuZGVyc3Rh
bmQgaXQgY29ycmVjdC4gCk5vdyB0aGUgRG9tMCBpcyBhIFBWIEd1ZXN0LiBXaXRoIFhlbiBIeWJy
aWQgdGhlIERvbTAgY2FuIHJ1biBhcyBhIEhWTSAKd2l0aCBQViBmZWF0dXJlcyBvbiB0aGUgaHlw
ZXJ2aXNvci4gVGhpcyB3b3VsZCBtYWtlIGl0IHBvc3NpYmxlIGJlY2F1c2UgCm9mIG5lc3RlZCB2
aXJ0dWFsaXphdGlvbiB0aGF0IEtWTSBhbmQgVmlydHVhbEJveCBydW4gaW5zaWRlIGRvbTAgcmln
aHQ/CgpBbmQgbXkgc2Vjb25kIHF1ZXN0aW9uIHdvdWxkIGJlOiBJcyB0aGUgYWltIG9mIFhlbiBo
eWJyaWQgdG8gYnJpbmcgRG9tMCAKc3VwcG9ydCB0byBtb3JlIE9TZXM/CgpCZXN0IFJlZ2FyZHMK
Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fClhlbi1kZXZl
bCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbi5vcmcKaHR0cDovL2xpc3RzLnhlbi5v
cmcveGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Thu Sep 20 08:06:30 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Sep 2012 08: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 1TEbm7-00016g-3O; Thu, 20 Sep 2012 08:06: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 1TEbm5-00016X-FD
	for xen-devel@lists.xen.org; Thu, 20 Sep 2012 08:06:17 +0000
Received: from [85.158.139.211:61119] by server-7.bemta-5.messagelabs.com id
	6C/17-19703-87ECA505; Thu, 20 Sep 2012 08:06:16 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-206.messagelabs.com!1348128376!19244467!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26062 invoked from network); 20 Sep 2012 08:06:16 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-10.tower-206.messagelabs.com with SMTP;
	20 Sep 2012 08:06:16 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 20 Sep 2012 09:06:15 +0100
Message-Id: <505AEAAC020000780009C81C@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 20 Sep 2012 09:06:36 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Campbell" <Ian.Campbell@citrix.com>
References: <505A5A03.4000106@citrix.com>
	<505AE62A020000780009C7F8@nat28.tlf.novell.com>
	<1348127736.26501.10.camel@zakaz.uk.xensource.com>
In-Reply-To: <1348127736.26501.10.camel@zakaz.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Attilio Rao <attilio.rao@citrix.com>, xen-devel <xen-devel@lists.xen.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [RFC] Extend the number of event channels availabe
 to guests
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 20.09.12 at 09:55, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> On Thu, 2012-09-20 at 08:47 +0100, Jan Beulich wrote:
>> One aspect to also consider is migration - will the guest have to
>> re-issue the extending hypercall, or will this be taken care of for
>> it? If the former approach is chosen, would the guest be
>> expected to deal with not being able to set up the extension
>> again on the new host? 
> 
> We only properly care about N->N and N->N+1 migrations, if we think that
> we would never reduce the limit over a hypervisor version upgrade then
> this would be fine, I think.
> 
> We do a similar thing with the grant table v2 stuff I think, i.e. panic
> after migration if we can't setup the feature again.

Which doesn't sound right - if hypervisor/tools did the re-setup,
then migration could fail in a recoverable way (i.e. continuing to
run on the old host) instead. After all, this may not be just about
feature availability but - especially if indeed there were multiple
pages to be allocated by the hypervisor - resource constraints.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 20 08:06:30 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Sep 2012 08: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 1TEbm7-00016g-3O; Thu, 20 Sep 2012 08:06: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 1TEbm5-00016X-FD
	for xen-devel@lists.xen.org; Thu, 20 Sep 2012 08:06:17 +0000
Received: from [85.158.139.211:61119] by server-7.bemta-5.messagelabs.com id
	6C/17-19703-87ECA505; Thu, 20 Sep 2012 08:06:16 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-206.messagelabs.com!1348128376!19244467!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26062 invoked from network); 20 Sep 2012 08:06:16 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-10.tower-206.messagelabs.com with SMTP;
	20 Sep 2012 08:06:16 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 20 Sep 2012 09:06:15 +0100
Message-Id: <505AEAAC020000780009C81C@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 20 Sep 2012 09:06:36 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Campbell" <Ian.Campbell@citrix.com>
References: <505A5A03.4000106@citrix.com>
	<505AE62A020000780009C7F8@nat28.tlf.novell.com>
	<1348127736.26501.10.camel@zakaz.uk.xensource.com>
In-Reply-To: <1348127736.26501.10.camel@zakaz.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Attilio Rao <attilio.rao@citrix.com>, xen-devel <xen-devel@lists.xen.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [RFC] Extend the number of event channels availabe
 to guests
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 20.09.12 at 09:55, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> On Thu, 2012-09-20 at 08:47 +0100, Jan Beulich wrote:
>> One aspect to also consider is migration - will the guest have to
>> re-issue the extending hypercall, or will this be taken care of for
>> it? If the former approach is chosen, would the guest be
>> expected to deal with not being able to set up the extension
>> again on the new host? 
> 
> We only properly care about N->N and N->N+1 migrations, if we think that
> we would never reduce the limit over a hypervisor version upgrade then
> this would be fine, I think.
> 
> We do a similar thing with the grant table v2 stuff I think, i.e. panic
> after migration if we can't setup the feature again.

Which doesn't sound right - if hypervisor/tools did the re-setup,
then migration could fail in a recoverable way (i.e. continuing to
run on the old host) instead. After all, this may not be just about
feature availability but - especially if indeed there were multiple
pages to be allocated by the hypervisor - resource constraints.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 20 08:06:41 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Sep 2012 08: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 1TEbmI-00018j-LO; Thu, 20 Sep 2012 08:06:30 +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 1TEbmH-00018C-91
	for xen-devel@lists.xensource.com; Thu, 20 Sep 2012 08:06:29 +0000
Received: from [85.158.137.99:12464] by server-10.bemta-3.messagelabs.com id
	42/9C-10411-48ECA505; Thu, 20 Sep 2012 08:06:28 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-14.tower-217.messagelabs.com!1348128387!18392727!1
X-Originating-IP: [192.55.52.93]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjkzID0+IDM0NDk3Mw==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23657 invoked from network); 20 Sep 2012 08:06:28 -0000
Received: from mga11.intel.com (HELO mga11.intel.com) (192.55.52.93)
	by server-14.tower-217.messagelabs.com with SMTP;
	20 Sep 2012 08:06:28 -0000
Received: from fmsmga002.fm.intel.com ([10.253.24.26])
	by fmsmga102.fm.intel.com with ESMTP; 20 Sep 2012 01:06:26 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.80,453,1344236400"; d="scan'208";a="224452000"
Received: from fmsmsx108.amr.corp.intel.com ([10.19.9.228])
	by fmsmga002.fm.intel.com with ESMTP; 20 Sep 2012 01:06:26 -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, 20 Sep 2012 01:06:26 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.239]) by
	SHSMSX102.ccr.corp.intel.com ([169.254.2.92]) with mapi id
	14.01.0355.002; Thu, 20 Sep 2012 16:06:25 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: Jan Beulich <JBeulich@suse.com>, "keir@xen.org" <keir@xen.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Thread-Topic: [PATCH 0/3] tsc adjust implementation for hvm
Thread-Index: Ac2XBtJ3RWSMroowQbKXJZr90iOO2Q==
Date: Thu, 20 Sep 2012 08:06:24 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC8292335331A65@SHSMSX101.ccr.corp.intel.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Subject: [Xen-devel] [PATCH 0/3] tsc adjust implementation for hvm
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Intel recently release a new tsc adjust feature at latest SDM 17.13.3.
CPUID.7.0.EBX[1]=1 indicates TSC_ADJUST MSR 0x3b is supported.

Basically it is used to simplify TSC synchronization, operation of IA32_TSC_ADJUST MSR is as follows:
1). On RESET, the value of the IA32_TSC_ADJUST MSR is 0;
2). If an execution of WRMSR to the IA32_TIME_STAMP_COUNTER MSR adds (or subtracts)
    value X from the TSC, the logical processor also adds (or subtracts) value X
    from the IA32_TSC_ADJUST MSR;
3). If an execution of WRMSR to the IA32_TSC_ADJUST MSR adds (or subtracts)
    value X from that MSR, the logical processor also adds (or subtracts) value X
    from the TSC;

With it, OS would be easier when sync tsc.

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 Sep 20 08:06:41 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Sep 2012 08: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 1TEbmI-00018j-LO; Thu, 20 Sep 2012 08:06:30 +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 1TEbmH-00018C-91
	for xen-devel@lists.xensource.com; Thu, 20 Sep 2012 08:06:29 +0000
Received: from [85.158.137.99:12464] by server-10.bemta-3.messagelabs.com id
	42/9C-10411-48ECA505; Thu, 20 Sep 2012 08:06:28 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-14.tower-217.messagelabs.com!1348128387!18392727!1
X-Originating-IP: [192.55.52.93]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjkzID0+IDM0NDk3Mw==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23657 invoked from network); 20 Sep 2012 08:06:28 -0000
Received: from mga11.intel.com (HELO mga11.intel.com) (192.55.52.93)
	by server-14.tower-217.messagelabs.com with SMTP;
	20 Sep 2012 08:06:28 -0000
Received: from fmsmga002.fm.intel.com ([10.253.24.26])
	by fmsmga102.fm.intel.com with ESMTP; 20 Sep 2012 01:06:26 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.80,453,1344236400"; d="scan'208";a="224452000"
Received: from fmsmsx108.amr.corp.intel.com ([10.19.9.228])
	by fmsmga002.fm.intel.com with ESMTP; 20 Sep 2012 01:06:26 -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, 20 Sep 2012 01:06:26 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.239]) by
	SHSMSX102.ccr.corp.intel.com ([169.254.2.92]) with mapi id
	14.01.0355.002; Thu, 20 Sep 2012 16:06:25 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: Jan Beulich <JBeulich@suse.com>, "keir@xen.org" <keir@xen.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Thread-Topic: [PATCH 0/3] tsc adjust implementation for hvm
Thread-Index: Ac2XBtJ3RWSMroowQbKXJZr90iOO2Q==
Date: Thu, 20 Sep 2012 08:06:24 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC8292335331A65@SHSMSX101.ccr.corp.intel.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Subject: [Xen-devel] [PATCH 0/3] tsc adjust implementation for hvm
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Intel recently release a new tsc adjust feature at latest SDM 17.13.3.
CPUID.7.0.EBX[1]=1 indicates TSC_ADJUST MSR 0x3b is supported.

Basically it is used to simplify TSC synchronization, operation of IA32_TSC_ADJUST MSR is as follows:
1). On RESET, the value of the IA32_TSC_ADJUST MSR is 0;
2). If an execution of WRMSR to the IA32_TIME_STAMP_COUNTER MSR adds (or subtracts)
    value X from the TSC, the logical processor also adds (or subtracts) value X
    from the IA32_TSC_ADJUST MSR;
3). If an execution of WRMSR to the IA32_TSC_ADJUST MSR adds (or subtracts)
    value X from that MSR, the logical processor also adds (or subtracts) value X
    from the TSC;

With it, OS would be easier when sync tsc.

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 Sep 20 08:07:56 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Sep 2012 08: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 1TEbnW-0001Js-6U; Thu, 20 Sep 2012 08:07:46 +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 1TEbnV-0001Jl-Gu
	for xen-devel@lists.xensource.com; Thu, 20 Sep 2012 08:07:45 +0000
Received: from [85.158.137.99:21904] by server-10.bemta-3.messagelabs.com id
	1A/80-10411-0DECA505; Thu, 20 Sep 2012 08:07:44 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-8.tower-217.messagelabs.com!1348128463!13058372!1
X-Originating-IP: [143.182.124.37]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMzcgPT4gMjA1NDE5\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21091 invoked from network); 20 Sep 2012 08:07:43 -0000
Received: from mga14.intel.com (HELO mga14.intel.com) (143.182.124.37)
	by server-8.tower-217.messagelabs.com with SMTP;
	20 Sep 2012 08:07:43 -0000
Received: from azsmga001.ch.intel.com ([10.2.17.19])
	by azsmga102.ch.intel.com with ESMTP; 20 Sep 2012 01:07:42 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.80,453,1344236400"; d="scan'208";a="194901932"
Received: from fmsmsx103.amr.corp.intel.com ([10.19.9.34])
	by azsmga001.ch.intel.com with ESMTP; 20 Sep 2012 01:07:42 -0700
Received: from fmsmsx101.amr.corp.intel.com (10.19.9.52) by
	FMSMSX103.amr.corp.intel.com (10.19.9.34) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Thu, 20 Sep 2012 01:07:41 -0700
Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by
	FMSMSX101.amr.corp.intel.com (10.19.9.52) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Thu, 20 Sep 2012 01:07:41 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.239]) by
	SHSMSX102.ccr.corp.intel.com ([169.254.2.92]) with mapi id
	14.01.0355.002; Thu, 20 Sep 2012 16:07:40 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: Jan Beulich <JBeulich@suse.com>, "keir@xen.org" <keir@xen.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Thread-Topic: [PATCH 1/3] Expose tsc adjust to hvm guest
Thread-Index: Ac2XBwBnRakYZJF1QbObqbkdJQFFhg==
Date: Thu, 20 Sep 2012 08:07:39 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC8292335331A72@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_DE8DF0795D48FD4CA783C40EC8292335331A72SHSMSX101ccrcorpi_"
MIME-Version: 1.0
Subject: [Xen-devel] [PATCH 1/3] Expose tsc adjust to 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_DE8DF0795D48FD4CA783C40EC8292335331A72SHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Expose tsc adjust to hvm guest

Intel latest SDM (17.13.3) release a new MSR
CPUID.7.0.EBX[1]=3D1 indicates TSC_ADJUST MSR 0x3b is supported.

This patch expose it to hvm guest.

Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>

diff -r a6d12a1bc758 tools/libxc/xc_cpufeature.h
--- a/tools/libxc/xc_cpufeature.h	Thu Sep 20 00:03:25 2012 +0800
+++ b/tools/libxc/xc_cpufeature.h	Thu Sep 20 21:50:55 2012 +0800
@@ -128,6 +128,7 @@
=20
 /* Intel-defined CPU features, CPUID level 0x00000007:0 (ebx) */
 #define X86_FEATURE_FSGSBASE     0 /* {RD,WR}{FS,GS}BASE instructions */
+#define X86_FEATURE_TSC_ADJUST   1 /* Tsc thread offset */
 #define X86_FEATURE_BMI1         3 /* 1st group bit manipulation extension=
s */
 #define X86_FEATURE_HLE          4 /* Hardware Lock Elision */
 #define X86_FEATURE_AVX2         5 /* AVX2 instructions */
diff -r a6d12a1bc758 tools/libxc/xc_cpuid_x86.c
--- a/tools/libxc/xc_cpuid_x86.c	Thu Sep 20 00:03:25 2012 +0800
+++ b/tools/libxc/xc_cpuid_x86.c	Thu Sep 20 21:50:55 2012 +0800
@@ -362,7 +362,8 @@
=20
     case 0x00000007: /* Intel-defined CPU features */
         if ( input[1] =3D=3D 0 ) {
-            regs[1] &=3D (bitmaskof(X86_FEATURE_BMI1) |
+            regs[1] &=3D (bitmaskof(X86_FEATURE_TSC_ADJUST) |
+                        bitmaskof(X86_FEATURE_BMI1) |
                         bitmaskof(X86_FEATURE_HLE)  |
                         bitmaskof(X86_FEATURE_AVX2) |
                         bitmaskof(X86_FEATURE_SMEP) |=

--_002_DE8DF0795D48FD4CA783C40EC8292335331A72SHSMSX101ccrcorpi_
Content-Type: application/octet-stream; name="tsc_adjust_1.patch"
Content-Description: tsc_adjust_1.patch
Content-Disposition: attachment; filename="tsc_adjust_1.patch"; size=1456;
	creation-date="Thu, 20 Sep 2012 07:55:15 GMT";
	modification-date="Thu, 20 Sep 2012 15:18:54 GMT"
Content-Transfer-Encoding: base64

RXhwb3NlIHRzYyBhZGp1c3QgdG8gaHZtIGd1ZXN0CgpJbnRlbCBsYXRlc3QgU0RNICgxNy4xMy4z
KSByZWxlYXNlIGEgbmV3IE1TUgpDUFVJRC43LjAuRUJYWzFdPTEgaW5kaWNhdGVzIFRTQ19BREpV
U1QgTVNSIDB4M2IgaXMgc3VwcG9ydGVkLgoKVGhpcyBwYXRjaCBleHBvc2UgaXQgdG8gaHZtIGd1
ZXN0LgoKU2lnbmVkLW9mZi1ieTogTGl1LCBKaW5zb25nIDxqaW5zb25nLmxpdUBpbnRlbC5jb20+
CgpkaWZmIC1yIGE2ZDEyYTFiYzc1OCB0b29scy9saWJ4Yy94Y19jcHVmZWF0dXJlLmgKLS0tIGEv
dG9vbHMvbGlieGMveGNfY3B1ZmVhdHVyZS5oCVRodSBTZXAgMjAgMDA6MDM6MjUgMjAxMiArMDgw
MAorKysgYi90b29scy9saWJ4Yy94Y19jcHVmZWF0dXJlLmgJVGh1IFNlcCAyMCAyMTo1MDo1NSAy
MDEyICswODAwCkBAIC0xMjgsNiArMTI4LDcgQEAKIAogLyogSW50ZWwtZGVmaW5lZCBDUFUgZmVh
dHVyZXMsIENQVUlEIGxldmVsIDB4MDAwMDAwMDc6MCAoZWJ4KSAqLwogI2RlZmluZSBYODZfRkVB
VFVSRV9GU0dTQkFTRSAgICAgMCAvKiB7UkQsV1J9e0ZTLEdTfUJBU0UgaW5zdHJ1Y3Rpb25zICov
CisjZGVmaW5lIFg4Nl9GRUFUVVJFX1RTQ19BREpVU1QgICAxIC8qIFRzYyB0aHJlYWQgb2Zmc2V0
ICovCiAjZGVmaW5lIFg4Nl9GRUFUVVJFX0JNSTEgICAgICAgICAzIC8qIDFzdCBncm91cCBiaXQg
bWFuaXB1bGF0aW9uIGV4dGVuc2lvbnMgKi8KICNkZWZpbmUgWDg2X0ZFQVRVUkVfSExFICAgICAg
ICAgIDQgLyogSGFyZHdhcmUgTG9jayBFbGlzaW9uICovCiAjZGVmaW5lIFg4Nl9GRUFUVVJFX0FW
WDIgICAgICAgICA1IC8qIEFWWDIgaW5zdHJ1Y3Rpb25zICovCmRpZmYgLXIgYTZkMTJhMWJjNzU4
IHRvb2xzL2xpYnhjL3hjX2NwdWlkX3g4Ni5jCi0tLSBhL3Rvb2xzL2xpYnhjL3hjX2NwdWlkX3g4
Ni5jCVRodSBTZXAgMjAgMDA6MDM6MjUgMjAxMiArMDgwMAorKysgYi90b29scy9saWJ4Yy94Y19j
cHVpZF94ODYuYwlUaHUgU2VwIDIwIDIxOjUwOjU1IDIwMTIgKzA4MDAKQEAgLTM2Miw3ICszNjIs
OCBAQAogCiAgICAgY2FzZSAweDAwMDAwMDA3OiAvKiBJbnRlbC1kZWZpbmVkIENQVSBmZWF0dXJl
cyAqLwogICAgICAgICBpZiAoIGlucHV0WzFdID09IDAgKSB7Ci0gICAgICAgICAgICByZWdzWzFd
ICY9IChiaXRtYXNrb2YoWDg2X0ZFQVRVUkVfQk1JMSkgfAorICAgICAgICAgICAgcmVnc1sxXSAm
PSAoYml0bWFza29mKFg4Nl9GRUFUVVJFX1RTQ19BREpVU1QpIHwKKyAgICAgICAgICAgICAgICAg
ICAgICAgIGJpdG1hc2tvZihYODZfRkVBVFVSRV9CTUkxKSB8CiAgICAgICAgICAgICAgICAgICAg
ICAgICBiaXRtYXNrb2YoWDg2X0ZFQVRVUkVfSExFKSAgfAogICAgICAgICAgICAgICAgICAgICAg
ICAgYml0bWFza29mKFg4Nl9GRUFUVVJFX0FWWDIpIHwKICAgICAgICAgICAgICAgICAgICAgICAg
IGJpdG1hc2tvZihYODZfRkVBVFVSRV9TTUVQKSB8Cg==

--_002_DE8DF0795D48FD4CA783C40EC8292335331A72SHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 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_DE8DF0795D48FD4CA783C40EC8292335331A72SHSMSX101ccrcorpi_--


From xen-devel-bounces@lists.xen.org Thu Sep 20 08:07:56 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Sep 2012 08: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 1TEbnW-0001Js-6U; Thu, 20 Sep 2012 08:07:46 +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 1TEbnV-0001Jl-Gu
	for xen-devel@lists.xensource.com; Thu, 20 Sep 2012 08:07:45 +0000
Received: from [85.158.137.99:21904] by server-10.bemta-3.messagelabs.com id
	1A/80-10411-0DECA505; Thu, 20 Sep 2012 08:07:44 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-8.tower-217.messagelabs.com!1348128463!13058372!1
X-Originating-IP: [143.182.124.37]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMzcgPT4gMjA1NDE5\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21091 invoked from network); 20 Sep 2012 08:07:43 -0000
Received: from mga14.intel.com (HELO mga14.intel.com) (143.182.124.37)
	by server-8.tower-217.messagelabs.com with SMTP;
	20 Sep 2012 08:07:43 -0000
Received: from azsmga001.ch.intel.com ([10.2.17.19])
	by azsmga102.ch.intel.com with ESMTP; 20 Sep 2012 01:07:42 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.80,453,1344236400"; d="scan'208";a="194901932"
Received: from fmsmsx103.amr.corp.intel.com ([10.19.9.34])
	by azsmga001.ch.intel.com with ESMTP; 20 Sep 2012 01:07:42 -0700
Received: from fmsmsx101.amr.corp.intel.com (10.19.9.52) by
	FMSMSX103.amr.corp.intel.com (10.19.9.34) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Thu, 20 Sep 2012 01:07:41 -0700
Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by
	FMSMSX101.amr.corp.intel.com (10.19.9.52) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Thu, 20 Sep 2012 01:07:41 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.239]) by
	SHSMSX102.ccr.corp.intel.com ([169.254.2.92]) with mapi id
	14.01.0355.002; Thu, 20 Sep 2012 16:07:40 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: Jan Beulich <JBeulich@suse.com>, "keir@xen.org" <keir@xen.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Thread-Topic: [PATCH 1/3] Expose tsc adjust to hvm guest
Thread-Index: Ac2XBwBnRakYZJF1QbObqbkdJQFFhg==
Date: Thu, 20 Sep 2012 08:07:39 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC8292335331A72@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_DE8DF0795D48FD4CA783C40EC8292335331A72SHSMSX101ccrcorpi_"
MIME-Version: 1.0
Subject: [Xen-devel] [PATCH 1/3] Expose tsc adjust to 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_DE8DF0795D48FD4CA783C40EC8292335331A72SHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Expose tsc adjust to hvm guest

Intel latest SDM (17.13.3) release a new MSR
CPUID.7.0.EBX[1]=3D1 indicates TSC_ADJUST MSR 0x3b is supported.

This patch expose it to hvm guest.

Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>

diff -r a6d12a1bc758 tools/libxc/xc_cpufeature.h
--- a/tools/libxc/xc_cpufeature.h	Thu Sep 20 00:03:25 2012 +0800
+++ b/tools/libxc/xc_cpufeature.h	Thu Sep 20 21:50:55 2012 +0800
@@ -128,6 +128,7 @@
=20
 /* Intel-defined CPU features, CPUID level 0x00000007:0 (ebx) */
 #define X86_FEATURE_FSGSBASE     0 /* {RD,WR}{FS,GS}BASE instructions */
+#define X86_FEATURE_TSC_ADJUST   1 /* Tsc thread offset */
 #define X86_FEATURE_BMI1         3 /* 1st group bit manipulation extension=
s */
 #define X86_FEATURE_HLE          4 /* Hardware Lock Elision */
 #define X86_FEATURE_AVX2         5 /* AVX2 instructions */
diff -r a6d12a1bc758 tools/libxc/xc_cpuid_x86.c
--- a/tools/libxc/xc_cpuid_x86.c	Thu Sep 20 00:03:25 2012 +0800
+++ b/tools/libxc/xc_cpuid_x86.c	Thu Sep 20 21:50:55 2012 +0800
@@ -362,7 +362,8 @@
=20
     case 0x00000007: /* Intel-defined CPU features */
         if ( input[1] =3D=3D 0 ) {
-            regs[1] &=3D (bitmaskof(X86_FEATURE_BMI1) |
+            regs[1] &=3D (bitmaskof(X86_FEATURE_TSC_ADJUST) |
+                        bitmaskof(X86_FEATURE_BMI1) |
                         bitmaskof(X86_FEATURE_HLE)  |
                         bitmaskof(X86_FEATURE_AVX2) |
                         bitmaskof(X86_FEATURE_SMEP) |=

--_002_DE8DF0795D48FD4CA783C40EC8292335331A72SHSMSX101ccrcorpi_
Content-Type: application/octet-stream; name="tsc_adjust_1.patch"
Content-Description: tsc_adjust_1.patch
Content-Disposition: attachment; filename="tsc_adjust_1.patch"; size=1456;
	creation-date="Thu, 20 Sep 2012 07:55:15 GMT";
	modification-date="Thu, 20 Sep 2012 15:18:54 GMT"
Content-Transfer-Encoding: base64

RXhwb3NlIHRzYyBhZGp1c3QgdG8gaHZtIGd1ZXN0CgpJbnRlbCBsYXRlc3QgU0RNICgxNy4xMy4z
KSByZWxlYXNlIGEgbmV3IE1TUgpDUFVJRC43LjAuRUJYWzFdPTEgaW5kaWNhdGVzIFRTQ19BREpV
U1QgTVNSIDB4M2IgaXMgc3VwcG9ydGVkLgoKVGhpcyBwYXRjaCBleHBvc2UgaXQgdG8gaHZtIGd1
ZXN0LgoKU2lnbmVkLW9mZi1ieTogTGl1LCBKaW5zb25nIDxqaW5zb25nLmxpdUBpbnRlbC5jb20+
CgpkaWZmIC1yIGE2ZDEyYTFiYzc1OCB0b29scy9saWJ4Yy94Y19jcHVmZWF0dXJlLmgKLS0tIGEv
dG9vbHMvbGlieGMveGNfY3B1ZmVhdHVyZS5oCVRodSBTZXAgMjAgMDA6MDM6MjUgMjAxMiArMDgw
MAorKysgYi90b29scy9saWJ4Yy94Y19jcHVmZWF0dXJlLmgJVGh1IFNlcCAyMCAyMTo1MDo1NSAy
MDEyICswODAwCkBAIC0xMjgsNiArMTI4LDcgQEAKIAogLyogSW50ZWwtZGVmaW5lZCBDUFUgZmVh
dHVyZXMsIENQVUlEIGxldmVsIDB4MDAwMDAwMDc6MCAoZWJ4KSAqLwogI2RlZmluZSBYODZfRkVB
VFVSRV9GU0dTQkFTRSAgICAgMCAvKiB7UkQsV1J9e0ZTLEdTfUJBU0UgaW5zdHJ1Y3Rpb25zICov
CisjZGVmaW5lIFg4Nl9GRUFUVVJFX1RTQ19BREpVU1QgICAxIC8qIFRzYyB0aHJlYWQgb2Zmc2V0
ICovCiAjZGVmaW5lIFg4Nl9GRUFUVVJFX0JNSTEgICAgICAgICAzIC8qIDFzdCBncm91cCBiaXQg
bWFuaXB1bGF0aW9uIGV4dGVuc2lvbnMgKi8KICNkZWZpbmUgWDg2X0ZFQVRVUkVfSExFICAgICAg
ICAgIDQgLyogSGFyZHdhcmUgTG9jayBFbGlzaW9uICovCiAjZGVmaW5lIFg4Nl9GRUFUVVJFX0FW
WDIgICAgICAgICA1IC8qIEFWWDIgaW5zdHJ1Y3Rpb25zICovCmRpZmYgLXIgYTZkMTJhMWJjNzU4
IHRvb2xzL2xpYnhjL3hjX2NwdWlkX3g4Ni5jCi0tLSBhL3Rvb2xzL2xpYnhjL3hjX2NwdWlkX3g4
Ni5jCVRodSBTZXAgMjAgMDA6MDM6MjUgMjAxMiArMDgwMAorKysgYi90b29scy9saWJ4Yy94Y19j
cHVpZF94ODYuYwlUaHUgU2VwIDIwIDIxOjUwOjU1IDIwMTIgKzA4MDAKQEAgLTM2Miw3ICszNjIs
OCBAQAogCiAgICAgY2FzZSAweDAwMDAwMDA3OiAvKiBJbnRlbC1kZWZpbmVkIENQVSBmZWF0dXJl
cyAqLwogICAgICAgICBpZiAoIGlucHV0WzFdID09IDAgKSB7Ci0gICAgICAgICAgICByZWdzWzFd
ICY9IChiaXRtYXNrb2YoWDg2X0ZFQVRVUkVfQk1JMSkgfAorICAgICAgICAgICAgcmVnc1sxXSAm
PSAoYml0bWFza29mKFg4Nl9GRUFUVVJFX1RTQ19BREpVU1QpIHwKKyAgICAgICAgICAgICAgICAg
ICAgICAgIGJpdG1hc2tvZihYODZfRkVBVFVSRV9CTUkxKSB8CiAgICAgICAgICAgICAgICAgICAg
ICAgICBiaXRtYXNrb2YoWDg2X0ZFQVRVUkVfSExFKSAgfAogICAgICAgICAgICAgICAgICAgICAg
ICAgYml0bWFza29mKFg4Nl9GRUFUVVJFX0FWWDIpIHwKICAgICAgICAgICAgICAgICAgICAgICAg
IGJpdG1hc2tvZihYODZfRkVBVFVSRV9TTUVQKSB8Cg==

--_002_DE8DF0795D48FD4CA783C40EC8292335331A72SHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 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_DE8DF0795D48FD4CA783C40EC8292335331A72SHSMSX101ccrcorpi_--


From xen-devel-bounces@lists.xen.org Thu Sep 20 08:08:43 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Sep 2012 08:08:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TEboH-0001QD-Ke; Thu, 20 Sep 2012 08:08:33 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1TEboF-0001Pr-O4
	for xen-devel@lists.xen.org; Thu, 20 Sep 2012 08:08:31 +0000
Received: from [85.158.139.211:25957] by server-10.bemta-5.messagelabs.com id
	11/6D-10969-AFECA505; Thu, 20 Sep 2012 08:08:26 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-206.messagelabs.com!1348128505!19220938!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12651 invoked from network); 20 Sep 2012 08:08:25 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-14.tower-206.messagelabs.com with SMTP;
	20 Sep 2012 08:08:25 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 20 Sep 2012 09:08:24 +0100
Message-Id: <505AEB2D020000780009C81F@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 20 Sep 2012 09:08:45 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Jeremy Fitzhardinge" <jeremy@goop.org>,
	"Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>, <ehabkost@redhat.com>
References: <7914B38A4445B34AA16EB9F1352942F1012F0F6F4B98@SJCPMAILBOX01.citrite.net>
	<CC681CDD.3D966%keir.xen@gmail.com>
	<40501859.20120902104331@eikelenboom.it>
	<5044849002000078000982EA@nat28.tlf.novell.com>
	<4610648186.20120904090841@eikelenboom.it>
	<5045CDF302000078000985FB@nat28.tlf.novell.com>
	<4710608674.20120904101330@eikelenboom.it> 
In-Reply-To: 
Mime-Version: 1.0
Content-Disposition: inline
Cc: "wei.wang2@amd.com" <wei.wang2@amd.com>,
	Sander Eikelenboom <linux@eikelenboom.it>,
	Keir Fraser <keir.xen@gmail.com>, Santosh Jodh <Santosh.Jodh@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Using debug-key 'o:  Dump IOMMU p2m table,
 locks up machine
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ping?

>>> On 04.09.12 at 11:26, Jan Beulich wrote:
>>>> On 04.09.12 at 10:13, Sander Eikelenboom <linux@eikelenboom.it> wrote:
> > Hmm don't know how to get the file/line, only thing i have found is:
> > 
> > serveerstertje:/boot# gdb xen-syms-4.2.0-rc4-pre
> > GNU gdb (GDB) 7.0.1-debian
> > Copyright (C) 2009 Free Software Foundation, Inc.
> > License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
> > This is free software: you are free to change and redistribute it.
> > There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
> > and "show warranty" for details.
> > This GDB was configured as "x86_64-linux-gnu".
> > For bug reporting instructions, please see:
> > <http://www.gnu.org/software/gdb/bugs/>...
> > Reading symbols from /boot/xen-syms-4.2.0-rc4-pre...done.
> > (gdb) x/i 0xffff82c48015c9ee
> > 0xffff82c48015c9ee <context_switch+916>:        mov    %edx,%gs
> > (gdb)
> 
> I'm not really a gdb expert, so I don't know off the top of my
> head either. I thought I said in a previous reply that people
> generally appear to use the addr2line utility for that purpose.
> 
> But the disassembly already tells us where precisely the
> problem is: The selector value (0x0063) attempted to be put
> into %gs is apparently wrong in the context of the current
> GDT. Now, that's GDT_ENTRY_TLS_MIN on the Linux side,
> and ought to be valid. I'm surprised the guest (and the current
> process in it) survives this (as the failure here results in a failsafe
> callback into the guest).
> 
> Looking at the Linux side of things, this has been that way
> forever, and I think has always been broken: On x86-64, it
> should also clear %gs here (since 32-bit processes use it for
> their TLS, and there's nothing wrong for a 64-bit process to put
> something in there either), albeit not via loadsegment(), but
> through xen_load_gs_index(). And I neither see why on 32-bit
> it only clears %gs - %fs can as much hold a selector that might
> get invalidated with the TLS descriptor updates. Eduardo,
> Jeremy, Konrad?
> 
> Jan
> 




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 20 08:08:43 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Sep 2012 08:08:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TEboH-0001QD-Ke; Thu, 20 Sep 2012 08:08:33 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1TEboF-0001Pr-O4
	for xen-devel@lists.xen.org; Thu, 20 Sep 2012 08:08:31 +0000
Received: from [85.158.139.211:25957] by server-10.bemta-5.messagelabs.com id
	11/6D-10969-AFECA505; Thu, 20 Sep 2012 08:08:26 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-206.messagelabs.com!1348128505!19220938!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12651 invoked from network); 20 Sep 2012 08:08:25 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-14.tower-206.messagelabs.com with SMTP;
	20 Sep 2012 08:08:25 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 20 Sep 2012 09:08:24 +0100
Message-Id: <505AEB2D020000780009C81F@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 20 Sep 2012 09:08:45 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Jeremy Fitzhardinge" <jeremy@goop.org>,
	"Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>, <ehabkost@redhat.com>
References: <7914B38A4445B34AA16EB9F1352942F1012F0F6F4B98@SJCPMAILBOX01.citrite.net>
	<CC681CDD.3D966%keir.xen@gmail.com>
	<40501859.20120902104331@eikelenboom.it>
	<5044849002000078000982EA@nat28.tlf.novell.com>
	<4610648186.20120904090841@eikelenboom.it>
	<5045CDF302000078000985FB@nat28.tlf.novell.com>
	<4710608674.20120904101330@eikelenboom.it> 
In-Reply-To: 
Mime-Version: 1.0
Content-Disposition: inline
Cc: "wei.wang2@amd.com" <wei.wang2@amd.com>,
	Sander Eikelenboom <linux@eikelenboom.it>,
	Keir Fraser <keir.xen@gmail.com>, Santosh Jodh <Santosh.Jodh@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Using debug-key 'o:  Dump IOMMU p2m table,
 locks up machine
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ping?

>>> On 04.09.12 at 11:26, Jan Beulich wrote:
>>>> On 04.09.12 at 10:13, Sander Eikelenboom <linux@eikelenboom.it> wrote:
> > Hmm don't know how to get the file/line, only thing i have found is:
> > 
> > serveerstertje:/boot# gdb xen-syms-4.2.0-rc4-pre
> > GNU gdb (GDB) 7.0.1-debian
> > Copyright (C) 2009 Free Software Foundation, Inc.
> > License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
> > This is free software: you are free to change and redistribute it.
> > There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
> > and "show warranty" for details.
> > This GDB was configured as "x86_64-linux-gnu".
> > For bug reporting instructions, please see:
> > <http://www.gnu.org/software/gdb/bugs/>...
> > Reading symbols from /boot/xen-syms-4.2.0-rc4-pre...done.
> > (gdb) x/i 0xffff82c48015c9ee
> > 0xffff82c48015c9ee <context_switch+916>:        mov    %edx,%gs
> > (gdb)
> 
> I'm not really a gdb expert, so I don't know off the top of my
> head either. I thought I said in a previous reply that people
> generally appear to use the addr2line utility for that purpose.
> 
> But the disassembly already tells us where precisely the
> problem is: The selector value (0x0063) attempted to be put
> into %gs is apparently wrong in the context of the current
> GDT. Now, that's GDT_ENTRY_TLS_MIN on the Linux side,
> and ought to be valid. I'm surprised the guest (and the current
> process in it) survives this (as the failure here results in a failsafe
> callback into the guest).
> 
> Looking at the Linux side of things, this has been that way
> forever, and I think has always been broken: On x86-64, it
> should also clear %gs here (since 32-bit processes use it for
> their TLS, and there's nothing wrong for a 64-bit process to put
> something in there either), albeit not via loadsegment(), but
> through xen_load_gs_index(). And I neither see why on 32-bit
> it only clears %gs - %fs can as much hold a selector that might
> get invalidated with the TLS descriptor updates. Eduardo,
> Jeremy, Konrad?
> 
> Jan
> 




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 20 08:10:40 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Sep 2012 08: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 1TEbqA-0001eH-5P; Thu, 20 Sep 2012 08:10:30 +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 1TEbq8-0001dv-Fg
	for xen-devel@lists.xensource.com; Thu, 20 Sep 2012 08:10:28 +0000
Received: from [85.158.143.35:48073] by server-3.bemta-4.messagelabs.com id
	E0/7B-10986-37FCA505; Thu, 20 Sep 2012 08:10:27 +0000
X-Env-Sender: fajar@fajar.net
X-Msg-Ref: server-6.tower-21.messagelabs.com!1348128624!19079989!1
X-Originating-IP: [209.85.214.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26273 invoked from network); 20 Sep 2012 08:10:25 -0000
Received: from mail-ob0-f171.google.com (HELO mail-ob0-f171.google.com)
	(209.85.214.171)
	by server-6.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Sep 2012 08:10:25 -0000
Received: by obc16 with SMTP id 16so336236obc.30
	for <xen-devel@lists.xensource.com>;
	Thu, 20 Sep 2012 01:10:23 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type:x-gm-message-state;
	bh=txyor5IuFZHOdUEarkjwSMomE3dqTecnv+Q9BDvvHME=;
	b=RsO/PFohDp6cfPNJnq0JOhzl4D7Sad07Xibh937Av2b8xLHvsGZKk//wJG+cjlaMrf
	C9/1I01DXHx9y7JqX3g0RxTTueiuN+8JShMjQSEVXyucmtGyGuUxp/aFdaNYbpRqY5wf
	LLnV22sYKiR2umVU6LMsS8K/sJu6JLQ4sdDiXTiDhcBkDagE7K0vg4AdwTkEVYpfTA+m
	gqCOo1yS8H0AMQu+71t29iGcIlohKKyFRJaDSVSrtDCc3PMH9l4IVFo9WPAgSRL6DSNE
	1eq0YtV0Co8XGjVxNFY/V4/1t3Ot5cDVKhDSCY7xBzfzrv7os/T505JxEmL56GRDG3/8
	BmGw==
MIME-Version: 1.0
Received: by 10.60.172.70 with SMTP id ba6mr690622oec.104.1348128623888; Thu,
	20 Sep 2012 01:10:23 -0700 (PDT)
Received: by 10.60.6.230 with HTTP; Thu, 20 Sep 2012 01:10:23 -0700 (PDT)
In-Reply-To: <bce40f714cae80dfd919b3d2c4e870e4@laukamp.me>
References: <c277ee4a34ca57f7da68f2e0ab832090@laukamp.me>
	<20120920073643.GU8912@reaktio.net>
	<bce40f714cae80dfd919b3d2c4e870e4@laukamp.me>
Date: Thu, 20 Sep 2012 15:10:23 +0700
Message-ID: <CAG1y0sdQ9TCxYHsNM8w44h3_bnNOVTP4iP78i-vz5AaOnFkxww@mail.gmail.com>
From: "Fajar A. Nugraha" <list@fajar.net>
To: Lukas Laukamp <lukas@laukamp.me>
X-Gm-Message-State: ALoCoQkMWJRxlkPpP4hS7fukSBeviYzX+NOFtFv3qPkBrhsPVeyEkimS0cI5f1Yd9ii44BfqWSmb
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [User Question] KVM and VirtualBox in 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 Thu, Sep 20, 2012 at 2:44 PM, Lukas Laukamp <lukas@laukamp.me> wrote:

> And would it be possible to
> implement something that KVM and VirtualBox work in a Xen Dom0?

> Is this a
> task for the Xen development or something for the Linux kernel,, KVM or
> VirtualBox?

Since it looks like you're a user and not a developer, I'd actually
suggest you rethink your requirements and find ways to implement it
using available solutions.

For example, you said you want to "create a VM Host for deploying VM
templates which are compatible to the most solutions". If the
templates are Linux, it's much easier to create one template that
suits all. Some things to watch out for:
- disk driver. Ubuntu loads most disk driver by default, but for other
distros (e.g. Centos) you might need to force drivers (xen front block
driver, virtio, etc) to be included in initrd by modifying
/etc/modprobe.conf or similar regardles which driver is currently
active
- disk naming. Use LABEL or UUID whenever possible
- filesystem for /boot. To be safe, use a separate /boot partition,
and use ext2/ext3, since some versions of pygrub do not support ext4.

If you follow that, you should be able to use the same image on
virtualbox, vmware, xen PV (with vfb enabled) or HVM. If you need more
help creating this template, xen-users will be a more appropriate
place to ask.

Another option, if your machine is dedicated for this purpose, is to
run native linux with kvm and virtualbox installed (you can have them
both installed, just not used at the same time), and install xen
inside a VM. That way you can still test everything except xen HVM.

-- 
Fajar

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 20 08:10:40 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Sep 2012 08: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 1TEbqA-0001eH-5P; Thu, 20 Sep 2012 08:10:30 +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 1TEbq8-0001dv-Fg
	for xen-devel@lists.xensource.com; Thu, 20 Sep 2012 08:10:28 +0000
Received: from [85.158.143.35:48073] by server-3.bemta-4.messagelabs.com id
	E0/7B-10986-37FCA505; Thu, 20 Sep 2012 08:10:27 +0000
X-Env-Sender: fajar@fajar.net
X-Msg-Ref: server-6.tower-21.messagelabs.com!1348128624!19079989!1
X-Originating-IP: [209.85.214.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26273 invoked from network); 20 Sep 2012 08:10:25 -0000
Received: from mail-ob0-f171.google.com (HELO mail-ob0-f171.google.com)
	(209.85.214.171)
	by server-6.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Sep 2012 08:10:25 -0000
Received: by obc16 with SMTP id 16so336236obc.30
	for <xen-devel@lists.xensource.com>;
	Thu, 20 Sep 2012 01:10:23 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type:x-gm-message-state;
	bh=txyor5IuFZHOdUEarkjwSMomE3dqTecnv+Q9BDvvHME=;
	b=RsO/PFohDp6cfPNJnq0JOhzl4D7Sad07Xibh937Av2b8xLHvsGZKk//wJG+cjlaMrf
	C9/1I01DXHx9y7JqX3g0RxTTueiuN+8JShMjQSEVXyucmtGyGuUxp/aFdaNYbpRqY5wf
	LLnV22sYKiR2umVU6LMsS8K/sJu6JLQ4sdDiXTiDhcBkDagE7K0vg4AdwTkEVYpfTA+m
	gqCOo1yS8H0AMQu+71t29iGcIlohKKyFRJaDSVSrtDCc3PMH9l4IVFo9WPAgSRL6DSNE
	1eq0YtV0Co8XGjVxNFY/V4/1t3Ot5cDVKhDSCY7xBzfzrv7os/T505JxEmL56GRDG3/8
	BmGw==
MIME-Version: 1.0
Received: by 10.60.172.70 with SMTP id ba6mr690622oec.104.1348128623888; Thu,
	20 Sep 2012 01:10:23 -0700 (PDT)
Received: by 10.60.6.230 with HTTP; Thu, 20 Sep 2012 01:10:23 -0700 (PDT)
In-Reply-To: <bce40f714cae80dfd919b3d2c4e870e4@laukamp.me>
References: <c277ee4a34ca57f7da68f2e0ab832090@laukamp.me>
	<20120920073643.GU8912@reaktio.net>
	<bce40f714cae80dfd919b3d2c4e870e4@laukamp.me>
Date: Thu, 20 Sep 2012 15:10:23 +0700
Message-ID: <CAG1y0sdQ9TCxYHsNM8w44h3_bnNOVTP4iP78i-vz5AaOnFkxww@mail.gmail.com>
From: "Fajar A. Nugraha" <list@fajar.net>
To: Lukas Laukamp <lukas@laukamp.me>
X-Gm-Message-State: ALoCoQkMWJRxlkPpP4hS7fukSBeviYzX+NOFtFv3qPkBrhsPVeyEkimS0cI5f1Yd9ii44BfqWSmb
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [User Question] KVM and VirtualBox in 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 Thu, Sep 20, 2012 at 2:44 PM, Lukas Laukamp <lukas@laukamp.me> wrote:

> And would it be possible to
> implement something that KVM and VirtualBox work in a Xen Dom0?

> Is this a
> task for the Xen development or something for the Linux kernel,, KVM or
> VirtualBox?

Since it looks like you're a user and not a developer, I'd actually
suggest you rethink your requirements and find ways to implement it
using available solutions.

For example, you said you want to "create a VM Host for deploying VM
templates which are compatible to the most solutions". If the
templates are Linux, it's much easier to create one template that
suits all. Some things to watch out for:
- disk driver. Ubuntu loads most disk driver by default, but for other
distros (e.g. Centos) you might need to force drivers (xen front block
driver, virtio, etc) to be included in initrd by modifying
/etc/modprobe.conf or similar regardles which driver is currently
active
- disk naming. Use LABEL or UUID whenever possible
- filesystem for /boot. To be safe, use a separate /boot partition,
and use ext2/ext3, since some versions of pygrub do not support ext4.

If you follow that, you should be able to use the same image on
virtualbox, vmware, xen PV (with vfb enabled) or HVM. If you need more
help creating this template, xen-users will be a more appropriate
place to ask.

Another option, if your machine is dedicated for this purpose, is to
run native linux with kvm and virtualbox installed (you can have them
both installed, just not used at the same time), and install xen
inside a VM. That way you can still test everything except xen HVM.

-- 
Fajar

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 20 08:10:43 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Sep 2012 08:10:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TEbqA-0001eP-H3; Thu, 20 Sep 2012 08:10:30 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <jinsong.liu@intel.com>) id 1TEbq9-0001db-73
	for xen-devel@lists.xensource.com; Thu, 20 Sep 2012 08:10:29 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1348128554!11127079!1
X-Originating-IP: [134.134.136.20]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjAgPT4gMzAwNjUx\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18520 invoked from network); 20 Sep 2012 08:09:21 -0000
Received: from mga02.intel.com (HELO mga02.intel.com) (134.134.136.20)
	by server-4.tower-27.messagelabs.com with SMTP;
	20 Sep 2012 08:09:21 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga101.jf.intel.com with ESMTP; 20 Sep 2012 01:09:11 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.80,453,1344236400"; d="scan'208";a="208501577"
Received: from fmsmsx107.amr.corp.intel.com ([10.19.9.54])
	by orsmga002.jf.intel.com with ESMTP; 20 Sep 2012 01:09:11 -0700
Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by
	FMSMSX107.amr.corp.intel.com (10.19.9.54) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Thu, 20 Sep 2012 01:09:11 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.239]) by
	SHSMSX102.ccr.corp.intel.com ([169.254.2.92]) with mapi id
	14.01.0355.002; Thu, 20 Sep 2012 16:09:09 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: Jan Beulich <JBeulich@suse.com>, "keir@xen.org" <keir@xen.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Thread-Topic: [PATCH 2/3] Implement tsc adjust feature
Thread-Index: Ac2XBzX7bUbP0YdmT6yKvtUk2+oYFg==
Date: Thu, 20 Sep 2012 08:09:09 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC8292335331A8F@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_DE8DF0795D48FD4CA783C40EC8292335331A8FSHSMSX101ccrcorpi_"
MIME-Version: 1.0
Subject: [Xen-devel] [PATCH 2/3] Implement tsc adjust 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>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--_002_DE8DF0795D48FD4CA783C40EC8292335331A8FSHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Implement tsc adjust feature

IA32_TSC_ADJUST MSR is maintained separately for each logical processor.
A logical processor maintains and uses the IA32_TSC_ADJUST MSR as follows:
1). On RESET, the value of the IA32_TSC_ADJUST MSR is 0;
2). If an execution of WRMSR to the IA32_TIME_STAMP_COUNTER MSR adds (or su=
btracts)
    value X from the TSC, the logical processor also adds (or subtracts) va=
lue X
    from the IA32_TSC_ADJUST MSR;
3). If an execution of WRMSR to the IA32_TSC_ADJUST MSR adds (or subtracts)
    value X from that MSR, the logical processor also adds (or subtracts) v=
alue X
    from the TSC;

Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>

diff -r d5c677159abb xen/arch/x86/hvm/hvm.c
--- a/xen/arch/x86/hvm/hvm.c	Thu Sep 20 21:50:56 2012 +0800
+++ b/xen/arch/x86/hvm/hvm.c	Thu Sep 20 23:34:04 2012 +0800
@@ -244,6 +244,7 @@
 void hvm_set_guest_tsc(struct vcpu *v, u64 guest_tsc)
 {
     uint64_t tsc;
+    uint64_t delta_tsc;
=20
     if ( v->domain->arch.vtsc )
     {
@@ -255,10 +256,23 @@
         rdtscll(tsc);
     }
=20
-    v->arch.hvm_vcpu.cache_tsc_offset =3D guest_tsc - tsc;
+    delta_tsc =3D guest_tsc - tsc;
+
+    v->arch.hvm_vcpu.msr_tsc_adjust +=3D delta_tsc
+                          - v->arch.hvm_vcpu.cache_tsc_offset;
+    v->arch.hvm_vcpu.cache_tsc_offset =3D delta_tsc;
+
     hvm_funcs.set_tsc_offset(v, v->arch.hvm_vcpu.cache_tsc_offset);
 }
=20
+void hvm_set_guest_tsc_adjust(struct vcpu *v, u64 tsc_adjust)
+{
+    v->arch.hvm_vcpu.cache_tsc_offset +=3D tsc_adjust
+                            - v->arch.hvm_vcpu.msr_tsc_adjust;
+    hvm_funcs.set_tsc_offset(v, v->arch.hvm_vcpu.cache_tsc_offset);
+    v->arch.hvm_vcpu.msr_tsc_adjust =3D tsc_adjust;
+}
+
 u64 hvm_get_guest_tsc(struct vcpu *v)
 {
     uint64_t tsc;
@@ -277,6 +291,11 @@
     return tsc + v->arch.hvm_vcpu.cache_tsc_offset;
 }
=20
+u64 hvm_get_guest_tsc_adjust(struct vcpu *v)
+{
+    return v->arch.hvm_vcpu.msr_tsc_adjust;
+}
+
 void hvm_migrate_timers(struct vcpu *v)
 {
     rtc_migrate_timers(v);
@@ -2776,6 +2795,10 @@
         *msr_content =3D hvm_get_guest_tsc(v);
         break;
=20
+    case MSR_IA32_TSC_ADJUST:
+        *msr_content =3D hvm_get_guest_tsc_adjust(v);
+        break;
+
     case MSR_TSC_AUX:
         *msr_content =3D hvm_msr_tsc_aux(v);
         break;
@@ -2889,6 +2912,10 @@
         hvm_set_guest_tsc(v, msr_content);
         break;
=20
+    case MSR_IA32_TSC_ADJUST:
+        hvm_set_guest_tsc_adjust(v, msr_content);
+        break;
+
     case MSR_TSC_AUX:
         v->arch.hvm_vcpu.msr_tsc_aux =3D (uint32_t)msr_content;
         if ( cpu_has_rdtscp
@@ -3436,6 +3463,8 @@
         v->domain->vcpu[0]->arch.hvm_vcpu.cache_tsc_offset;
     hvm_funcs.set_tsc_offset(v, v->arch.hvm_vcpu.cache_tsc_offset);
=20
+    v->arch.hvm_vcpu.msr_tsc_adjust =3D 0;
+
     paging_update_paging_modes(v);
=20
     v->arch.flags |=3D TF_kernel_mode;
diff -r d5c677159abb xen/include/asm-x86/hvm/vcpu.h
--- a/xen/include/asm-x86/hvm/vcpu.h	Thu Sep 20 21:50:56 2012 +0800
+++ b/xen/include/asm-x86/hvm/vcpu.h	Thu Sep 20 23:34:04 2012 +0800
@@ -137,6 +137,7 @@
     struct hvm_vcpu_asid n1asid;
=20
     u32                 msr_tsc_aux;
+    u64                 msr_tsc_adjust;
=20
     /* VPMU */
     struct vpmu_struct  vpmu;
diff -r d5c677159abb xen/include/asm-x86/msr-index.h
--- a/xen/include/asm-x86/msr-index.h	Thu Sep 20 21:50:56 2012 +0800
+++ b/xen/include/asm-x86/msr-index.h	Thu Sep 20 23:34:04 2012 +0800
@@ -284,6 +284,7 @@
 #define MSR_IA32_PLATFORM_ID		0x00000017
 #define MSR_IA32_EBL_CR_POWERON		0x0000002a
 #define MSR_IA32_EBC_FREQUENCY_ID	0x0000002c
+#define MSR_IA32_TSC_ADJUST		0x0000003b
=20
 #define MSR_IA32_APICBASE		0x0000001b
 #define MSR_IA32_APICBASE_BSP		(1<<8)=

--_002_DE8DF0795D48FD4CA783C40EC8292335331A8FSHSMSX101ccrcorpi_
Content-Type: application/octet-stream; name="tsc_adjust_2.patch"
Content-Description: tsc_adjust_2.patch
Content-Disposition: attachment; filename="tsc_adjust_2.patch"; size=3684;
	creation-date="Thu, 20 Sep 2012 07:55:15 GMT";
	modification-date="Thu, 20 Sep 2012 15:38:02 GMT"
Content-Transfer-Encoding: base64

SW1wbGVtZW50IHRzYyBhZGp1c3QgZmVhdHVyZQoKSUEzMl9UU0NfQURKVVNUIE1TUiBpcyBtYWlu
dGFpbmVkIHNlcGFyYXRlbHkgZm9yIGVhY2ggbG9naWNhbCBwcm9jZXNzb3IuCkEgbG9naWNhbCBw
cm9jZXNzb3IgbWFpbnRhaW5zIGFuZCB1c2VzIHRoZSBJQTMyX1RTQ19BREpVU1QgTVNSIGFzIGZv
bGxvd3M6CjEpLiBPbiBSRVNFVCwgdGhlIHZhbHVlIG9mIHRoZSBJQTMyX1RTQ19BREpVU1QgTVNS
IGlzIDA7CjIpLiBJZiBhbiBleGVjdXRpb24gb2YgV1JNU1IgdG8gdGhlIElBMzJfVElNRV9TVEFN
UF9DT1VOVEVSIE1TUiBhZGRzIChvciBzdWJ0cmFjdHMpCiAgICB2YWx1ZSBYIGZyb20gdGhlIFRT
QywgdGhlIGxvZ2ljYWwgcHJvY2Vzc29yIGFsc28gYWRkcyAob3Igc3VidHJhY3RzKSB2YWx1ZSBY
CiAgICBmcm9tIHRoZSBJQTMyX1RTQ19BREpVU1QgTVNSOwozKS4gSWYgYW4gZXhlY3V0aW9uIG9m
IFdSTVNSIHRvIHRoZSBJQTMyX1RTQ19BREpVU1QgTVNSIGFkZHMgKG9yIHN1YnRyYWN0cykKICAg
IHZhbHVlIFggZnJvbSB0aGF0IE1TUiwgdGhlIGxvZ2ljYWwgcHJvY2Vzc29yIGFsc28gYWRkcyAo
b3Igc3VidHJhY3RzKSB2YWx1ZSBYCiAgICBmcm9tIHRoZSBUU0M7CgpTaWduZWQtb2ZmLWJ5OiBM
aXUsIEppbnNvbmcgPGppbnNvbmcubGl1QGludGVsLmNvbT4KCmRpZmYgLXIgZDVjNjc3MTU5YWJi
IHhlbi9hcmNoL3g4Ni9odm0vaHZtLmMKLS0tIGEveGVuL2FyY2gveDg2L2h2bS9odm0uYwlUaHUg
U2VwIDIwIDIxOjUwOjU2IDIwMTIgKzA4MDAKKysrIGIveGVuL2FyY2gveDg2L2h2bS9odm0uYwlU
aHUgU2VwIDIwIDIzOjM0OjA0IDIwMTIgKzA4MDAKQEAgLTI0NCw2ICsyNDQsNyBAQAogdm9pZCBo
dm1fc2V0X2d1ZXN0X3RzYyhzdHJ1Y3QgdmNwdSAqdiwgdTY0IGd1ZXN0X3RzYykKIHsKICAgICB1
aW50NjRfdCB0c2M7CisgICAgdWludDY0X3QgZGVsdGFfdHNjOwogCiAgICAgaWYgKCB2LT5kb21h
aW4tPmFyY2gudnRzYyApCiAgICAgewpAQCAtMjU1LDEwICsyNTYsMjMgQEAKICAgICAgICAgcmR0
c2NsbCh0c2MpOwogICAgIH0KIAotICAgIHYtPmFyY2guaHZtX3ZjcHUuY2FjaGVfdHNjX29mZnNl
dCA9IGd1ZXN0X3RzYyAtIHRzYzsKKyAgICBkZWx0YV90c2MgPSBndWVzdF90c2MgLSB0c2M7CisK
KyAgICB2LT5hcmNoLmh2bV92Y3B1Lm1zcl90c2NfYWRqdXN0ICs9IGRlbHRhX3RzYworICAgICAg
ICAgICAgICAgICAgICAgICAgICAtIHYtPmFyY2guaHZtX3ZjcHUuY2FjaGVfdHNjX29mZnNldDsK
KyAgICB2LT5hcmNoLmh2bV92Y3B1LmNhY2hlX3RzY19vZmZzZXQgPSBkZWx0YV90c2M7CisKICAg
ICBodm1fZnVuY3Muc2V0X3RzY19vZmZzZXQodiwgdi0+YXJjaC5odm1fdmNwdS5jYWNoZV90c2Nf
b2Zmc2V0KTsKIH0KIAordm9pZCBodm1fc2V0X2d1ZXN0X3RzY19hZGp1c3Qoc3RydWN0IHZjcHUg
KnYsIHU2NCB0c2NfYWRqdXN0KQoreworICAgIHYtPmFyY2guaHZtX3ZjcHUuY2FjaGVfdHNjX29m
ZnNldCArPSB0c2NfYWRqdXN0CisgICAgICAgICAgICAgICAgICAgICAgICAgICAgLSB2LT5hcmNo
Lmh2bV92Y3B1Lm1zcl90c2NfYWRqdXN0OworICAgIGh2bV9mdW5jcy5zZXRfdHNjX29mZnNldCh2
LCB2LT5hcmNoLmh2bV92Y3B1LmNhY2hlX3RzY19vZmZzZXQpOworICAgIHYtPmFyY2guaHZtX3Zj
cHUubXNyX3RzY19hZGp1c3QgPSB0c2NfYWRqdXN0OworfQorCiB1NjQgaHZtX2dldF9ndWVzdF90
c2Moc3RydWN0IHZjcHUgKnYpCiB7CiAgICAgdWludDY0X3QgdHNjOwpAQCAtMjc3LDYgKzI5MSwx
MSBAQAogICAgIHJldHVybiB0c2MgKyB2LT5hcmNoLmh2bV92Y3B1LmNhY2hlX3RzY19vZmZzZXQ7
CiB9CiAKK3U2NCBodm1fZ2V0X2d1ZXN0X3RzY19hZGp1c3Qoc3RydWN0IHZjcHUgKnYpCit7Cisg
ICAgcmV0dXJuIHYtPmFyY2guaHZtX3ZjcHUubXNyX3RzY19hZGp1c3Q7Cit9CisKIHZvaWQgaHZt
X21pZ3JhdGVfdGltZXJzKHN0cnVjdCB2Y3B1ICp2KQogewogICAgIHJ0Y19taWdyYXRlX3RpbWVy
cyh2KTsKQEAgLTI3NzYsNiArMjc5NSwxMCBAQAogICAgICAgICAqbXNyX2NvbnRlbnQgPSBodm1f
Z2V0X2d1ZXN0X3RzYyh2KTsKICAgICAgICAgYnJlYWs7CiAKKyAgICBjYXNlIE1TUl9JQTMyX1RT
Q19BREpVU1Q6CisgICAgICAgICptc3JfY29udGVudCA9IGh2bV9nZXRfZ3Vlc3RfdHNjX2FkanVz
dCh2KTsKKyAgICAgICAgYnJlYWs7CisKICAgICBjYXNlIE1TUl9UU0NfQVVYOgogICAgICAgICAq
bXNyX2NvbnRlbnQgPSBodm1fbXNyX3RzY19hdXgodik7CiAgICAgICAgIGJyZWFrOwpAQCAtMjg4
OSw2ICsyOTEyLDEwIEBACiAgICAgICAgIGh2bV9zZXRfZ3Vlc3RfdHNjKHYsIG1zcl9jb250ZW50
KTsKICAgICAgICAgYnJlYWs7CiAKKyAgICBjYXNlIE1TUl9JQTMyX1RTQ19BREpVU1Q6CisgICAg
ICAgIGh2bV9zZXRfZ3Vlc3RfdHNjX2FkanVzdCh2LCBtc3JfY29udGVudCk7CisgICAgICAgIGJy
ZWFrOworCiAgICAgY2FzZSBNU1JfVFNDX0FVWDoKICAgICAgICAgdi0+YXJjaC5odm1fdmNwdS5t
c3JfdHNjX2F1eCA9ICh1aW50MzJfdCltc3JfY29udGVudDsKICAgICAgICAgaWYgKCBjcHVfaGFz
X3JkdHNjcApAQCAtMzQzNiw2ICszNDYzLDggQEAKICAgICAgICAgdi0+ZG9tYWluLT52Y3B1WzBd
LT5hcmNoLmh2bV92Y3B1LmNhY2hlX3RzY19vZmZzZXQ7CiAgICAgaHZtX2Z1bmNzLnNldF90c2Nf
b2Zmc2V0KHYsIHYtPmFyY2guaHZtX3ZjcHUuY2FjaGVfdHNjX29mZnNldCk7CiAKKyAgICB2LT5h
cmNoLmh2bV92Y3B1Lm1zcl90c2NfYWRqdXN0ID0gMDsKKwogICAgIHBhZ2luZ191cGRhdGVfcGFn
aW5nX21vZGVzKHYpOwogCiAgICAgdi0+YXJjaC5mbGFncyB8PSBURl9rZXJuZWxfbW9kZTsKZGlm
ZiAtciBkNWM2NzcxNTlhYmIgeGVuL2luY2x1ZGUvYXNtLXg4Ni9odm0vdmNwdS5oCi0tLSBhL3hl
bi9pbmNsdWRlL2FzbS14ODYvaHZtL3ZjcHUuaAlUaHUgU2VwIDIwIDIxOjUwOjU2IDIwMTIgKzA4
MDAKKysrIGIveGVuL2luY2x1ZGUvYXNtLXg4Ni9odm0vdmNwdS5oCVRodSBTZXAgMjAgMjM6MzQ6
MDQgMjAxMiArMDgwMApAQCAtMTM3LDYgKzEzNyw3IEBACiAgICAgc3RydWN0IGh2bV92Y3B1X2Fz
aWQgbjFhc2lkOwogCiAgICAgdTMyICAgICAgICAgICAgICAgICBtc3JfdHNjX2F1eDsKKyAgICB1
NjQgICAgICAgICAgICAgICAgIG1zcl90c2NfYWRqdXN0OwogCiAgICAgLyogVlBNVSAqLwogICAg
IHN0cnVjdCB2cG11X3N0cnVjdCAgdnBtdTsKZGlmZiAtciBkNWM2NzcxNTlhYmIgeGVuL2luY2x1
ZGUvYXNtLXg4Ni9tc3ItaW5kZXguaAotLS0gYS94ZW4vaW5jbHVkZS9hc20teDg2L21zci1pbmRl
eC5oCVRodSBTZXAgMjAgMjE6NTA6NTYgMjAxMiArMDgwMAorKysgYi94ZW4vaW5jbHVkZS9hc20t
eDg2L21zci1pbmRleC5oCVRodSBTZXAgMjAgMjM6MzQ6MDQgMjAxMiArMDgwMApAQCAtMjg0LDYg
KzI4NCw3IEBACiAjZGVmaW5lIE1TUl9JQTMyX1BMQVRGT1JNX0lECQkweDAwMDAwMDE3CiAjZGVm
aW5lIE1TUl9JQTMyX0VCTF9DUl9QT1dFUk9OCQkweDAwMDAwMDJhCiAjZGVmaW5lIE1TUl9JQTMy
X0VCQ19GUkVRVUVOQ1lfSUQJMHgwMDAwMDAyYworI2RlZmluZSBNU1JfSUEzMl9UU0NfQURKVVNU
CQkweDAwMDAwMDNiCiAKICNkZWZpbmUgTVNSX0lBMzJfQVBJQ0JBU0UJCTB4MDAwMDAwMWIKICNk
ZWZpbmUgTVNSX0lBMzJfQVBJQ0JBU0VfQlNQCQkoMTw8OCkK

--_002_DE8DF0795D48FD4CA783C40EC8292335331A8FSHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 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_DE8DF0795D48FD4CA783C40EC8292335331A8FSHSMSX101ccrcorpi_--


From xen-devel-bounces@lists.xen.org Thu Sep 20 08:10:43 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Sep 2012 08:10:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TEbqA-0001eP-H3; Thu, 20 Sep 2012 08:10:30 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <jinsong.liu@intel.com>) id 1TEbq9-0001db-73
	for xen-devel@lists.xensource.com; Thu, 20 Sep 2012 08:10:29 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1348128554!11127079!1
X-Originating-IP: [134.134.136.20]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjAgPT4gMzAwNjUx\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18520 invoked from network); 20 Sep 2012 08:09:21 -0000
Received: from mga02.intel.com (HELO mga02.intel.com) (134.134.136.20)
	by server-4.tower-27.messagelabs.com with SMTP;
	20 Sep 2012 08:09:21 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga101.jf.intel.com with ESMTP; 20 Sep 2012 01:09:11 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.80,453,1344236400"; d="scan'208";a="208501577"
Received: from fmsmsx107.amr.corp.intel.com ([10.19.9.54])
	by orsmga002.jf.intel.com with ESMTP; 20 Sep 2012 01:09:11 -0700
Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by
	FMSMSX107.amr.corp.intel.com (10.19.9.54) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Thu, 20 Sep 2012 01:09:11 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.239]) by
	SHSMSX102.ccr.corp.intel.com ([169.254.2.92]) with mapi id
	14.01.0355.002; Thu, 20 Sep 2012 16:09:09 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: Jan Beulich <JBeulich@suse.com>, "keir@xen.org" <keir@xen.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Thread-Topic: [PATCH 2/3] Implement tsc adjust feature
Thread-Index: Ac2XBzX7bUbP0YdmT6yKvtUk2+oYFg==
Date: Thu, 20 Sep 2012 08:09:09 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC8292335331A8F@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_DE8DF0795D48FD4CA783C40EC8292335331A8FSHSMSX101ccrcorpi_"
MIME-Version: 1.0
Subject: [Xen-devel] [PATCH 2/3] Implement tsc adjust 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>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--_002_DE8DF0795D48FD4CA783C40EC8292335331A8FSHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Implement tsc adjust feature

IA32_TSC_ADJUST MSR is maintained separately for each logical processor.
A logical processor maintains and uses the IA32_TSC_ADJUST MSR as follows:
1). On RESET, the value of the IA32_TSC_ADJUST MSR is 0;
2). If an execution of WRMSR to the IA32_TIME_STAMP_COUNTER MSR adds (or su=
btracts)
    value X from the TSC, the logical processor also adds (or subtracts) va=
lue X
    from the IA32_TSC_ADJUST MSR;
3). If an execution of WRMSR to the IA32_TSC_ADJUST MSR adds (or subtracts)
    value X from that MSR, the logical processor also adds (or subtracts) v=
alue X
    from the TSC;

Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>

diff -r d5c677159abb xen/arch/x86/hvm/hvm.c
--- a/xen/arch/x86/hvm/hvm.c	Thu Sep 20 21:50:56 2012 +0800
+++ b/xen/arch/x86/hvm/hvm.c	Thu Sep 20 23:34:04 2012 +0800
@@ -244,6 +244,7 @@
 void hvm_set_guest_tsc(struct vcpu *v, u64 guest_tsc)
 {
     uint64_t tsc;
+    uint64_t delta_tsc;
=20
     if ( v->domain->arch.vtsc )
     {
@@ -255,10 +256,23 @@
         rdtscll(tsc);
     }
=20
-    v->arch.hvm_vcpu.cache_tsc_offset =3D guest_tsc - tsc;
+    delta_tsc =3D guest_tsc - tsc;
+
+    v->arch.hvm_vcpu.msr_tsc_adjust +=3D delta_tsc
+                          - v->arch.hvm_vcpu.cache_tsc_offset;
+    v->arch.hvm_vcpu.cache_tsc_offset =3D delta_tsc;
+
     hvm_funcs.set_tsc_offset(v, v->arch.hvm_vcpu.cache_tsc_offset);
 }
=20
+void hvm_set_guest_tsc_adjust(struct vcpu *v, u64 tsc_adjust)
+{
+    v->arch.hvm_vcpu.cache_tsc_offset +=3D tsc_adjust
+                            - v->arch.hvm_vcpu.msr_tsc_adjust;
+    hvm_funcs.set_tsc_offset(v, v->arch.hvm_vcpu.cache_tsc_offset);
+    v->arch.hvm_vcpu.msr_tsc_adjust =3D tsc_adjust;
+}
+
 u64 hvm_get_guest_tsc(struct vcpu *v)
 {
     uint64_t tsc;
@@ -277,6 +291,11 @@
     return tsc + v->arch.hvm_vcpu.cache_tsc_offset;
 }
=20
+u64 hvm_get_guest_tsc_adjust(struct vcpu *v)
+{
+    return v->arch.hvm_vcpu.msr_tsc_adjust;
+}
+
 void hvm_migrate_timers(struct vcpu *v)
 {
     rtc_migrate_timers(v);
@@ -2776,6 +2795,10 @@
         *msr_content =3D hvm_get_guest_tsc(v);
         break;
=20
+    case MSR_IA32_TSC_ADJUST:
+        *msr_content =3D hvm_get_guest_tsc_adjust(v);
+        break;
+
     case MSR_TSC_AUX:
         *msr_content =3D hvm_msr_tsc_aux(v);
         break;
@@ -2889,6 +2912,10 @@
         hvm_set_guest_tsc(v, msr_content);
         break;
=20
+    case MSR_IA32_TSC_ADJUST:
+        hvm_set_guest_tsc_adjust(v, msr_content);
+        break;
+
     case MSR_TSC_AUX:
         v->arch.hvm_vcpu.msr_tsc_aux =3D (uint32_t)msr_content;
         if ( cpu_has_rdtscp
@@ -3436,6 +3463,8 @@
         v->domain->vcpu[0]->arch.hvm_vcpu.cache_tsc_offset;
     hvm_funcs.set_tsc_offset(v, v->arch.hvm_vcpu.cache_tsc_offset);
=20
+    v->arch.hvm_vcpu.msr_tsc_adjust =3D 0;
+
     paging_update_paging_modes(v);
=20
     v->arch.flags |=3D TF_kernel_mode;
diff -r d5c677159abb xen/include/asm-x86/hvm/vcpu.h
--- a/xen/include/asm-x86/hvm/vcpu.h	Thu Sep 20 21:50:56 2012 +0800
+++ b/xen/include/asm-x86/hvm/vcpu.h	Thu Sep 20 23:34:04 2012 +0800
@@ -137,6 +137,7 @@
     struct hvm_vcpu_asid n1asid;
=20
     u32                 msr_tsc_aux;
+    u64                 msr_tsc_adjust;
=20
     /* VPMU */
     struct vpmu_struct  vpmu;
diff -r d5c677159abb xen/include/asm-x86/msr-index.h
--- a/xen/include/asm-x86/msr-index.h	Thu Sep 20 21:50:56 2012 +0800
+++ b/xen/include/asm-x86/msr-index.h	Thu Sep 20 23:34:04 2012 +0800
@@ -284,6 +284,7 @@
 #define MSR_IA32_PLATFORM_ID		0x00000017
 #define MSR_IA32_EBL_CR_POWERON		0x0000002a
 #define MSR_IA32_EBC_FREQUENCY_ID	0x0000002c
+#define MSR_IA32_TSC_ADJUST		0x0000003b
=20
 #define MSR_IA32_APICBASE		0x0000001b
 #define MSR_IA32_APICBASE_BSP		(1<<8)=

--_002_DE8DF0795D48FD4CA783C40EC8292335331A8FSHSMSX101ccrcorpi_
Content-Type: application/octet-stream; name="tsc_adjust_2.patch"
Content-Description: tsc_adjust_2.patch
Content-Disposition: attachment; filename="tsc_adjust_2.patch"; size=3684;
	creation-date="Thu, 20 Sep 2012 07:55:15 GMT";
	modification-date="Thu, 20 Sep 2012 15:38:02 GMT"
Content-Transfer-Encoding: base64

SW1wbGVtZW50IHRzYyBhZGp1c3QgZmVhdHVyZQoKSUEzMl9UU0NfQURKVVNUIE1TUiBpcyBtYWlu
dGFpbmVkIHNlcGFyYXRlbHkgZm9yIGVhY2ggbG9naWNhbCBwcm9jZXNzb3IuCkEgbG9naWNhbCBw
cm9jZXNzb3IgbWFpbnRhaW5zIGFuZCB1c2VzIHRoZSBJQTMyX1RTQ19BREpVU1QgTVNSIGFzIGZv
bGxvd3M6CjEpLiBPbiBSRVNFVCwgdGhlIHZhbHVlIG9mIHRoZSBJQTMyX1RTQ19BREpVU1QgTVNS
IGlzIDA7CjIpLiBJZiBhbiBleGVjdXRpb24gb2YgV1JNU1IgdG8gdGhlIElBMzJfVElNRV9TVEFN
UF9DT1VOVEVSIE1TUiBhZGRzIChvciBzdWJ0cmFjdHMpCiAgICB2YWx1ZSBYIGZyb20gdGhlIFRT
QywgdGhlIGxvZ2ljYWwgcHJvY2Vzc29yIGFsc28gYWRkcyAob3Igc3VidHJhY3RzKSB2YWx1ZSBY
CiAgICBmcm9tIHRoZSBJQTMyX1RTQ19BREpVU1QgTVNSOwozKS4gSWYgYW4gZXhlY3V0aW9uIG9m
IFdSTVNSIHRvIHRoZSBJQTMyX1RTQ19BREpVU1QgTVNSIGFkZHMgKG9yIHN1YnRyYWN0cykKICAg
IHZhbHVlIFggZnJvbSB0aGF0IE1TUiwgdGhlIGxvZ2ljYWwgcHJvY2Vzc29yIGFsc28gYWRkcyAo
b3Igc3VidHJhY3RzKSB2YWx1ZSBYCiAgICBmcm9tIHRoZSBUU0M7CgpTaWduZWQtb2ZmLWJ5OiBM
aXUsIEppbnNvbmcgPGppbnNvbmcubGl1QGludGVsLmNvbT4KCmRpZmYgLXIgZDVjNjc3MTU5YWJi
IHhlbi9hcmNoL3g4Ni9odm0vaHZtLmMKLS0tIGEveGVuL2FyY2gveDg2L2h2bS9odm0uYwlUaHUg
U2VwIDIwIDIxOjUwOjU2IDIwMTIgKzA4MDAKKysrIGIveGVuL2FyY2gveDg2L2h2bS9odm0uYwlU
aHUgU2VwIDIwIDIzOjM0OjA0IDIwMTIgKzA4MDAKQEAgLTI0NCw2ICsyNDQsNyBAQAogdm9pZCBo
dm1fc2V0X2d1ZXN0X3RzYyhzdHJ1Y3QgdmNwdSAqdiwgdTY0IGd1ZXN0X3RzYykKIHsKICAgICB1
aW50NjRfdCB0c2M7CisgICAgdWludDY0X3QgZGVsdGFfdHNjOwogCiAgICAgaWYgKCB2LT5kb21h
aW4tPmFyY2gudnRzYyApCiAgICAgewpAQCAtMjU1LDEwICsyNTYsMjMgQEAKICAgICAgICAgcmR0
c2NsbCh0c2MpOwogICAgIH0KIAotICAgIHYtPmFyY2guaHZtX3ZjcHUuY2FjaGVfdHNjX29mZnNl
dCA9IGd1ZXN0X3RzYyAtIHRzYzsKKyAgICBkZWx0YV90c2MgPSBndWVzdF90c2MgLSB0c2M7CisK
KyAgICB2LT5hcmNoLmh2bV92Y3B1Lm1zcl90c2NfYWRqdXN0ICs9IGRlbHRhX3RzYworICAgICAg
ICAgICAgICAgICAgICAgICAgICAtIHYtPmFyY2guaHZtX3ZjcHUuY2FjaGVfdHNjX29mZnNldDsK
KyAgICB2LT5hcmNoLmh2bV92Y3B1LmNhY2hlX3RzY19vZmZzZXQgPSBkZWx0YV90c2M7CisKICAg
ICBodm1fZnVuY3Muc2V0X3RzY19vZmZzZXQodiwgdi0+YXJjaC5odm1fdmNwdS5jYWNoZV90c2Nf
b2Zmc2V0KTsKIH0KIAordm9pZCBodm1fc2V0X2d1ZXN0X3RzY19hZGp1c3Qoc3RydWN0IHZjcHUg
KnYsIHU2NCB0c2NfYWRqdXN0KQoreworICAgIHYtPmFyY2guaHZtX3ZjcHUuY2FjaGVfdHNjX29m
ZnNldCArPSB0c2NfYWRqdXN0CisgICAgICAgICAgICAgICAgICAgICAgICAgICAgLSB2LT5hcmNo
Lmh2bV92Y3B1Lm1zcl90c2NfYWRqdXN0OworICAgIGh2bV9mdW5jcy5zZXRfdHNjX29mZnNldCh2
LCB2LT5hcmNoLmh2bV92Y3B1LmNhY2hlX3RzY19vZmZzZXQpOworICAgIHYtPmFyY2guaHZtX3Zj
cHUubXNyX3RzY19hZGp1c3QgPSB0c2NfYWRqdXN0OworfQorCiB1NjQgaHZtX2dldF9ndWVzdF90
c2Moc3RydWN0IHZjcHUgKnYpCiB7CiAgICAgdWludDY0X3QgdHNjOwpAQCAtMjc3LDYgKzI5MSwx
MSBAQAogICAgIHJldHVybiB0c2MgKyB2LT5hcmNoLmh2bV92Y3B1LmNhY2hlX3RzY19vZmZzZXQ7
CiB9CiAKK3U2NCBodm1fZ2V0X2d1ZXN0X3RzY19hZGp1c3Qoc3RydWN0IHZjcHUgKnYpCit7Cisg
ICAgcmV0dXJuIHYtPmFyY2guaHZtX3ZjcHUubXNyX3RzY19hZGp1c3Q7Cit9CisKIHZvaWQgaHZt
X21pZ3JhdGVfdGltZXJzKHN0cnVjdCB2Y3B1ICp2KQogewogICAgIHJ0Y19taWdyYXRlX3RpbWVy
cyh2KTsKQEAgLTI3NzYsNiArMjc5NSwxMCBAQAogICAgICAgICAqbXNyX2NvbnRlbnQgPSBodm1f
Z2V0X2d1ZXN0X3RzYyh2KTsKICAgICAgICAgYnJlYWs7CiAKKyAgICBjYXNlIE1TUl9JQTMyX1RT
Q19BREpVU1Q6CisgICAgICAgICptc3JfY29udGVudCA9IGh2bV9nZXRfZ3Vlc3RfdHNjX2FkanVz
dCh2KTsKKyAgICAgICAgYnJlYWs7CisKICAgICBjYXNlIE1TUl9UU0NfQVVYOgogICAgICAgICAq
bXNyX2NvbnRlbnQgPSBodm1fbXNyX3RzY19hdXgodik7CiAgICAgICAgIGJyZWFrOwpAQCAtMjg4
OSw2ICsyOTEyLDEwIEBACiAgICAgICAgIGh2bV9zZXRfZ3Vlc3RfdHNjKHYsIG1zcl9jb250ZW50
KTsKICAgICAgICAgYnJlYWs7CiAKKyAgICBjYXNlIE1TUl9JQTMyX1RTQ19BREpVU1Q6CisgICAg
ICAgIGh2bV9zZXRfZ3Vlc3RfdHNjX2FkanVzdCh2LCBtc3JfY29udGVudCk7CisgICAgICAgIGJy
ZWFrOworCiAgICAgY2FzZSBNU1JfVFNDX0FVWDoKICAgICAgICAgdi0+YXJjaC5odm1fdmNwdS5t
c3JfdHNjX2F1eCA9ICh1aW50MzJfdCltc3JfY29udGVudDsKICAgICAgICAgaWYgKCBjcHVfaGFz
X3JkdHNjcApAQCAtMzQzNiw2ICszNDYzLDggQEAKICAgICAgICAgdi0+ZG9tYWluLT52Y3B1WzBd
LT5hcmNoLmh2bV92Y3B1LmNhY2hlX3RzY19vZmZzZXQ7CiAgICAgaHZtX2Z1bmNzLnNldF90c2Nf
b2Zmc2V0KHYsIHYtPmFyY2guaHZtX3ZjcHUuY2FjaGVfdHNjX29mZnNldCk7CiAKKyAgICB2LT5h
cmNoLmh2bV92Y3B1Lm1zcl90c2NfYWRqdXN0ID0gMDsKKwogICAgIHBhZ2luZ191cGRhdGVfcGFn
aW5nX21vZGVzKHYpOwogCiAgICAgdi0+YXJjaC5mbGFncyB8PSBURl9rZXJuZWxfbW9kZTsKZGlm
ZiAtciBkNWM2NzcxNTlhYmIgeGVuL2luY2x1ZGUvYXNtLXg4Ni9odm0vdmNwdS5oCi0tLSBhL3hl
bi9pbmNsdWRlL2FzbS14ODYvaHZtL3ZjcHUuaAlUaHUgU2VwIDIwIDIxOjUwOjU2IDIwMTIgKzA4
MDAKKysrIGIveGVuL2luY2x1ZGUvYXNtLXg4Ni9odm0vdmNwdS5oCVRodSBTZXAgMjAgMjM6MzQ6
MDQgMjAxMiArMDgwMApAQCAtMTM3LDYgKzEzNyw3IEBACiAgICAgc3RydWN0IGh2bV92Y3B1X2Fz
aWQgbjFhc2lkOwogCiAgICAgdTMyICAgICAgICAgICAgICAgICBtc3JfdHNjX2F1eDsKKyAgICB1
NjQgICAgICAgICAgICAgICAgIG1zcl90c2NfYWRqdXN0OwogCiAgICAgLyogVlBNVSAqLwogICAg
IHN0cnVjdCB2cG11X3N0cnVjdCAgdnBtdTsKZGlmZiAtciBkNWM2NzcxNTlhYmIgeGVuL2luY2x1
ZGUvYXNtLXg4Ni9tc3ItaW5kZXguaAotLS0gYS94ZW4vaW5jbHVkZS9hc20teDg2L21zci1pbmRl
eC5oCVRodSBTZXAgMjAgMjE6NTA6NTYgMjAxMiArMDgwMAorKysgYi94ZW4vaW5jbHVkZS9hc20t
eDg2L21zci1pbmRleC5oCVRodSBTZXAgMjAgMjM6MzQ6MDQgMjAxMiArMDgwMApAQCAtMjg0LDYg
KzI4NCw3IEBACiAjZGVmaW5lIE1TUl9JQTMyX1BMQVRGT1JNX0lECQkweDAwMDAwMDE3CiAjZGVm
aW5lIE1TUl9JQTMyX0VCTF9DUl9QT1dFUk9OCQkweDAwMDAwMDJhCiAjZGVmaW5lIE1TUl9JQTMy
X0VCQ19GUkVRVUVOQ1lfSUQJMHgwMDAwMDAyYworI2RlZmluZSBNU1JfSUEzMl9UU0NfQURKVVNU
CQkweDAwMDAwMDNiCiAKICNkZWZpbmUgTVNSX0lBMzJfQVBJQ0JBU0UJCTB4MDAwMDAwMWIKICNk
ZWZpbmUgTVNSX0lBMzJfQVBJQ0JBU0VfQlNQCQkoMTw8OCkK

--_002_DE8DF0795D48FD4CA783C40EC8292335331A8FSHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 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_DE8DF0795D48FD4CA783C40EC8292335331A8FSHSMSX101ccrcorpi_--


From xen-devel-bounces@lists.xen.org Thu Sep 20 08:10:54 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Sep 2012 08:10: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 1TEbqQ-0001j9-5o; Thu, 20 Sep 2012 08:10:46 +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 1TEbqO-0001id-IY
	for xen-devel@lists.xensource.com; Thu, 20 Sep 2012 08:10:44 +0000
Received: from [85.158.143.99:43557] by server-3.bemta-4.messagelabs.com id
	07/EB-10986-38FCA505; Thu, 20 Sep 2012 08:10:43 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1348128636!25790707!1
X-Originating-IP: [192.55.52.88]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjg4ID0+IDMyMTcxMA==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18952 invoked from network); 20 Sep 2012 08:10:42 -0000
Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88)
	by server-4.tower-216.messagelabs.com with SMTP;
	20 Sep 2012 08:10:42 -0000
Received: from fmsmga002.fm.intel.com ([10.253.24.26])
	by fmsmga101.fm.intel.com with ESMTP; 20 Sep 2012 01:10:35 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.80,453,1344236400"; d="scan'208";a="224453514"
Received: from fmsmsx108.amr.corp.intel.com ([10.19.9.228])
	by fmsmga002.fm.intel.com with ESMTP; 20 Sep 2012 01:10:35 -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, 20 Sep 2012 01:10:34 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.239]) by
	SHSMSX102.ccr.corp.intel.com ([169.254.2.92]) with mapi id
	14.01.0355.002; Thu, 20 Sep 2012 16:10:33 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: Jan Beulich <JBeulich@suse.com>, "keir@xen.org" <keir@xen.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Thread-Topic: [PATCH 3/3] Save/restore tsc adjust when migrate
Thread-Index: Ac2XB2gz6lyN67NXS7Kl4/JQViI/Lw==
Date: Thu, 20 Sep 2012 08:10:33 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC8292335331ABB@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_DE8DF0795D48FD4CA783C40EC8292335331ABBSHSMSX101ccrcorpi_"
MIME-Version: 1.0
Subject: [Xen-devel] [PATCH 3/3] Save/restore tsc adjust when migrate
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--_002_DE8DF0795D48FD4CA783C40EC8292335331ABBSHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Save/restore tsc adjust when migrate

Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>

diff -r d94d78756665 tools/misc/xen-hvmctx.c
--- a/tools/misc/xen-hvmctx.c	Thu Sep 20 21:57:36 2012 +0800
+++ b/tools/misc/xen-hvmctx.c	Thu Sep 20 22:07:14 2012 +0800
@@ -392,6 +392,13 @@
     printf("    VMCE_VCPU: bank1 mci_ctl2 %" PRIx64 "\n", p.mci_ctl2_bank1=
);
 }
=20
+static void dump_tsc_adjust(void)
+{
+    HVM_SAVE_TYPE(TSC_ADJUST) p;
+    READ(p);
+    printf("    TSC_ADJUST: tsc_adjust %" PRIx64 "\n", p.tsc_adjust);
+}
+
 int main(int argc, char **argv)
 {
     int entry, domid;
@@ -459,6 +466,7 @@
         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(TSC_ADJUST): dump_tsc_adjust(); break;
         case HVM_SAVE_CODE(END): break;
         default:
             printf(" ** Don't understand type %u: skipping\n",
diff -r d94d78756665 xen/arch/x86/hvm/hvm.c
--- a/xen/arch/x86/hvm/hvm.c	Thu Sep 20 21:57:36 2012 +0800
+++ b/xen/arch/x86/hvm/hvm.c	Thu Sep 20 22:07:14 2012 +0800
@@ -605,6 +605,45 @@
     hvm_destroy_cacheattr_region_list(d);
 }
=20
+static int hvm_save_tsc_adjust(struct domain *d, hvm_domain_context_t *h)
+{
+    struct vcpu *v;
+    struct hvm_tsc_adjust ctxt;
+    int err =3D 0;
+
+    for_each_vcpu( d, v ){
+        ctxt.tsc_adjust =3D v->arch.hvm_vcpu.msr_tsc_adjust;
+        err =3D hvm_save_entry(TSC_ADJUST, v->vcpu_id, h, &ctxt);
+        if ( err )
+            break;
+    }
+
+    return err;
+}
+
+static int hvm_load_tsc_adjust(struct domain *d, hvm_domain_context_t *h)
+{
+    unsigned int vcpuid =3D hvm_load_instance(h);
+    struct vcpu *v;
+    struct hvm_tsc_adjust ctxt;
+
+    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);
+        return -EINVAL;
+    }
+
+    if ( hvm_load_entry(TSC_ADJUST, h, &ctxt) !=3D 0 )
+        return -EINVAL;
+
+    v->arch.hvm_vcpu.msr_tsc_adjust =3D ctxt.tsc_adjust;
+    return 0;
+}
+
+HVM_REGISTER_SAVE_RESTORE(TSC_ADJUST, hvm_save_tsc_adjust,
+                          hvm_load_tsc_adjust, 1, HVMSR_PER_VCPU);
+
 static int hvm_save_cpu_ctxt(struct domain *d, hvm_domain_context_t *h)
 {
     struct vcpu *v;
diff -r d94d78756665 xen/include/public/arch-x86/hvm/save.h
--- a/xen/include/public/arch-x86/hvm/save.h	Thu Sep 20 21:57:36 2012 +0800
+++ b/xen/include/public/arch-x86/hvm/save.h	Thu Sep 20 22:07:14 2012 +0800
@@ -583,9 +583,15 @@
=20
 DECLARE_HVM_SAVE_TYPE(VMCE_VCPU, 18, struct hvm_vmce_vcpu);
=20
+struct hvm_tsc_adjust {
+    uint64_t tsc_adjust;
+};
+
+DECLARE_HVM_SAVE_TYPE(TSC_ADJUST, 19, struct hvm_tsc_adjust);
+
 /*=20
  * Largest type-code in use
  */
-#define HVM_SAVE_CODE_MAX 18
+#define HVM_SAVE_CODE_MAX 19
=20
 #endif /* __XEN_PUBLIC_HVM_SAVE_X86_H__ */=

--_002_DE8DF0795D48FD4CA783C40EC8292335331ABBSHSMSX101ccrcorpi_
Content-Type: application/octet-stream; name="tsc_adjust_3.patch"
Content-Description: tsc_adjust_3.patch
Content-Disposition: attachment; filename="tsc_adjust_3.patch"; size=2967;
	creation-date="Thu, 20 Sep 2012 07:55:15 GMT";
	modification-date="Thu, 20 Sep 2012 15:40:24 GMT"
Content-Transfer-Encoding: base64

U2F2ZS9yZXN0b3JlIHRzYyBhZGp1c3Qgd2hlbiBtaWdyYXRlCgpTaWduZWQtb2ZmLWJ5OiBMaXUs
IEppbnNvbmcgPGppbnNvbmcubGl1QGludGVsLmNvbT4KCmRpZmYgLXIgZDk0ZDc4NzU2NjY1IHRv
b2xzL21pc2MveGVuLWh2bWN0eC5jCi0tLSBhL3Rvb2xzL21pc2MveGVuLWh2bWN0eC5jCVRodSBT
ZXAgMjAgMjE6NTc6MzYgMjAxMiArMDgwMAorKysgYi90b29scy9taXNjL3hlbi1odm1jdHguYwlU
aHUgU2VwIDIwIDIyOjA3OjE0IDIwMTIgKzA4MDAKQEAgLTM5Miw2ICszOTIsMTMgQEAKICAgICBw
cmludGYoIiAgICBWTUNFX1ZDUFU6IGJhbmsxIG1jaV9jdGwyICUiIFBSSXg2NCAiXG4iLCBwLm1j
aV9jdGwyX2JhbmsxKTsKIH0KIAorc3RhdGljIHZvaWQgZHVtcF90c2NfYWRqdXN0KHZvaWQpCit7
CisgICAgSFZNX1NBVkVfVFlQRShUU0NfQURKVVNUKSBwOworICAgIFJFQUQocCk7CisgICAgcHJp
bnRmKCIgICAgVFNDX0FESlVTVDogdHNjX2FkanVzdCAlIiBQUkl4NjQgIlxuIiwgcC50c2NfYWRq
dXN0KTsKK30KKwogaW50IG1haW4oaW50IGFyZ2MsIGNoYXIgKiphcmd2KQogewogICAgIGludCBl
bnRyeSwgZG9taWQ7CkBAIC00NTksNiArNDY2LDcgQEAKICAgICAgICAgY2FzZSBIVk1fU0FWRV9D
T0RFKFZJUklESUFOX0RPTUFJTik6IGR1bXBfdmlyaWRpYW5fZG9tYWluKCk7IGJyZWFrOwogICAg
ICAgICBjYXNlIEhWTV9TQVZFX0NPREUoVklSSURJQU5fVkNQVSk6IGR1bXBfdmlyaWRpYW5fdmNw
dSgpOyBicmVhazsKICAgICAgICAgY2FzZSBIVk1fU0FWRV9DT0RFKFZNQ0VfVkNQVSk6IGR1bXBf
dm1jZV92Y3B1KCk7IGJyZWFrOworICAgICAgICBjYXNlIEhWTV9TQVZFX0NPREUoVFNDX0FESlVT
VCk6IGR1bXBfdHNjX2FkanVzdCgpOyBicmVhazsKICAgICAgICAgY2FzZSBIVk1fU0FWRV9DT0RF
KEVORCk6IGJyZWFrOwogICAgICAgICBkZWZhdWx0OgogICAgICAgICAgICAgcHJpbnRmKCIgKiog
RG9uJ3QgdW5kZXJzdGFuZCB0eXBlICV1OiBza2lwcGluZ1xuIiwKZGlmZiAtciBkOTRkNzg3NTY2
NjUgeGVuL2FyY2gveDg2L2h2bS9odm0uYwotLS0gYS94ZW4vYXJjaC94ODYvaHZtL2h2bS5jCVRo
dSBTZXAgMjAgMjE6NTc6MzYgMjAxMiArMDgwMAorKysgYi94ZW4vYXJjaC94ODYvaHZtL2h2bS5j
CVRodSBTZXAgMjAgMjI6MDc6MTQgMjAxMiArMDgwMApAQCAtNjA1LDYgKzYwNSw0NSBAQAogICAg
IGh2bV9kZXN0cm95X2NhY2hlYXR0cl9yZWdpb25fbGlzdChkKTsKIH0KIAorc3RhdGljIGludCBo
dm1fc2F2ZV90c2NfYWRqdXN0KHN0cnVjdCBkb21haW4gKmQsIGh2bV9kb21haW5fY29udGV4dF90
ICpoKQoreworICAgIHN0cnVjdCB2Y3B1ICp2OworICAgIHN0cnVjdCBodm1fdHNjX2FkanVzdCBj
dHh0OworICAgIGludCBlcnIgPSAwOworCisgICAgZm9yX2VhY2hfdmNwdSggZCwgdiApeworICAg
ICAgICBjdHh0LnRzY19hZGp1c3QgPSB2LT5hcmNoLmh2bV92Y3B1Lm1zcl90c2NfYWRqdXN0Owor
ICAgICAgICBlcnIgPSBodm1fc2F2ZV9lbnRyeShUU0NfQURKVVNULCB2LT52Y3B1X2lkLCBoLCAm
Y3R4dCk7CisgICAgICAgIGlmICggZXJyICkKKyAgICAgICAgICAgIGJyZWFrOworICAgIH0KKwor
ICAgIHJldHVybiBlcnI7Cit9CisKK3N0YXRpYyBpbnQgaHZtX2xvYWRfdHNjX2FkanVzdChzdHJ1
Y3QgZG9tYWluICpkLCBodm1fZG9tYWluX2NvbnRleHRfdCAqaCkKK3sKKyAgICB1bnNpZ25lZCBp
bnQgdmNwdWlkID0gaHZtX2xvYWRfaW5zdGFuY2UoaCk7CisgICAgc3RydWN0IHZjcHUgKnY7Cisg
ICAgc3RydWN0IGh2bV90c2NfYWRqdXN0IGN0eHQ7CisKKyAgICBpZiAoIHZjcHVpZCA+PSBkLT5t
YXhfdmNwdXMgfHwgKHYgPSBkLT52Y3B1W3ZjcHVpZF0pID09IE5VTEwgKQorICAgIHsKKyAgICAg
ICAgZHByaW50ayhYRU5MT0dfR19FUlIsICJIVk0gcmVzdG9yZTogZG9tJWQgaGFzIG5vIHZjcHUl
dVxuIiwKKyAgICAgICAgICAgICAgICBkLT5kb21haW5faWQsIHZjcHVpZCk7CisgICAgICAgIHJl
dHVybiAtRUlOVkFMOworICAgIH0KKworICAgIGlmICggaHZtX2xvYWRfZW50cnkoVFNDX0FESlVT
VCwgaCwgJmN0eHQpICE9IDAgKQorICAgICAgICByZXR1cm4gLUVJTlZBTDsKKworICAgIHYtPmFy
Y2guaHZtX3ZjcHUubXNyX3RzY19hZGp1c3QgPSBjdHh0LnRzY19hZGp1c3Q7CisgICAgcmV0dXJu
IDA7Cit9CisKK0hWTV9SRUdJU1RFUl9TQVZFX1JFU1RPUkUoVFNDX0FESlVTVCwgaHZtX3NhdmVf
dHNjX2FkanVzdCwKKyAgICAgICAgICAgICAgICAgICAgICAgICAgaHZtX2xvYWRfdHNjX2FkanVz
dCwgMSwgSFZNU1JfUEVSX1ZDUFUpOworCiBzdGF0aWMgaW50IGh2bV9zYXZlX2NwdV9jdHh0KHN0
cnVjdCBkb21haW4gKmQsIGh2bV9kb21haW5fY29udGV4dF90ICpoKQogewogICAgIHN0cnVjdCB2
Y3B1ICp2OwpkaWZmIC1yIGQ5NGQ3ODc1NjY2NSB4ZW4vaW5jbHVkZS9wdWJsaWMvYXJjaC14ODYv
aHZtL3NhdmUuaAotLS0gYS94ZW4vaW5jbHVkZS9wdWJsaWMvYXJjaC14ODYvaHZtL3NhdmUuaAlU
aHUgU2VwIDIwIDIxOjU3OjM2IDIwMTIgKzA4MDAKKysrIGIveGVuL2luY2x1ZGUvcHVibGljL2Fy
Y2gteDg2L2h2bS9zYXZlLmgJVGh1IFNlcCAyMCAyMjowNzoxNCAyMDEyICswODAwCkBAIC01ODMs
OSArNTgzLDE1IEBACiAKIERFQ0xBUkVfSFZNX1NBVkVfVFlQRShWTUNFX1ZDUFUsIDE4LCBzdHJ1
Y3QgaHZtX3ZtY2VfdmNwdSk7CiAKK3N0cnVjdCBodm1fdHNjX2FkanVzdCB7CisgICAgdWludDY0
X3QgdHNjX2FkanVzdDsKK307CisKK0RFQ0xBUkVfSFZNX1NBVkVfVFlQRShUU0NfQURKVVNULCAx
OSwgc3RydWN0IGh2bV90c2NfYWRqdXN0KTsKKwogLyogCiAgKiBMYXJnZXN0IHR5cGUtY29kZSBp
biB1c2UKICAqLwotI2RlZmluZSBIVk1fU0FWRV9DT0RFX01BWCAxOAorI2RlZmluZSBIVk1fU0FW
RV9DT0RFX01BWCAxOQogCiAjZW5kaWYgLyogX19YRU5fUFVCTElDX0hWTV9TQVZFX1g4Nl9IX18g
Ki8K

--_002_DE8DF0795D48FD4CA783C40EC8292335331ABBSHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 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_DE8DF0795D48FD4CA783C40EC8292335331ABBSHSMSX101ccrcorpi_--


From xen-devel-bounces@lists.xen.org Thu Sep 20 08:10:54 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Sep 2012 08:10: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 1TEbqQ-0001j9-5o; Thu, 20 Sep 2012 08:10:46 +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 1TEbqO-0001id-IY
	for xen-devel@lists.xensource.com; Thu, 20 Sep 2012 08:10:44 +0000
Received: from [85.158.143.99:43557] by server-3.bemta-4.messagelabs.com id
	07/EB-10986-38FCA505; Thu, 20 Sep 2012 08:10:43 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1348128636!25790707!1
X-Originating-IP: [192.55.52.88]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjg4ID0+IDMyMTcxMA==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18952 invoked from network); 20 Sep 2012 08:10:42 -0000
Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88)
	by server-4.tower-216.messagelabs.com with SMTP;
	20 Sep 2012 08:10:42 -0000
Received: from fmsmga002.fm.intel.com ([10.253.24.26])
	by fmsmga101.fm.intel.com with ESMTP; 20 Sep 2012 01:10:35 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.80,453,1344236400"; d="scan'208";a="224453514"
Received: from fmsmsx108.amr.corp.intel.com ([10.19.9.228])
	by fmsmga002.fm.intel.com with ESMTP; 20 Sep 2012 01:10:35 -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, 20 Sep 2012 01:10:34 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.239]) by
	SHSMSX102.ccr.corp.intel.com ([169.254.2.92]) with mapi id
	14.01.0355.002; Thu, 20 Sep 2012 16:10:33 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: Jan Beulich <JBeulich@suse.com>, "keir@xen.org" <keir@xen.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Thread-Topic: [PATCH 3/3] Save/restore tsc adjust when migrate
Thread-Index: Ac2XB2gz6lyN67NXS7Kl4/JQViI/Lw==
Date: Thu, 20 Sep 2012 08:10:33 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC8292335331ABB@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_DE8DF0795D48FD4CA783C40EC8292335331ABBSHSMSX101ccrcorpi_"
MIME-Version: 1.0
Subject: [Xen-devel] [PATCH 3/3] Save/restore tsc adjust when migrate
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--_002_DE8DF0795D48FD4CA783C40EC8292335331ABBSHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Save/restore tsc adjust when migrate

Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>

diff -r d94d78756665 tools/misc/xen-hvmctx.c
--- a/tools/misc/xen-hvmctx.c	Thu Sep 20 21:57:36 2012 +0800
+++ b/tools/misc/xen-hvmctx.c	Thu Sep 20 22:07:14 2012 +0800
@@ -392,6 +392,13 @@
     printf("    VMCE_VCPU: bank1 mci_ctl2 %" PRIx64 "\n", p.mci_ctl2_bank1=
);
 }
=20
+static void dump_tsc_adjust(void)
+{
+    HVM_SAVE_TYPE(TSC_ADJUST) p;
+    READ(p);
+    printf("    TSC_ADJUST: tsc_adjust %" PRIx64 "\n", p.tsc_adjust);
+}
+
 int main(int argc, char **argv)
 {
     int entry, domid;
@@ -459,6 +466,7 @@
         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(TSC_ADJUST): dump_tsc_adjust(); break;
         case HVM_SAVE_CODE(END): break;
         default:
             printf(" ** Don't understand type %u: skipping\n",
diff -r d94d78756665 xen/arch/x86/hvm/hvm.c
--- a/xen/arch/x86/hvm/hvm.c	Thu Sep 20 21:57:36 2012 +0800
+++ b/xen/arch/x86/hvm/hvm.c	Thu Sep 20 22:07:14 2012 +0800
@@ -605,6 +605,45 @@
     hvm_destroy_cacheattr_region_list(d);
 }
=20
+static int hvm_save_tsc_adjust(struct domain *d, hvm_domain_context_t *h)
+{
+    struct vcpu *v;
+    struct hvm_tsc_adjust ctxt;
+    int err =3D 0;
+
+    for_each_vcpu( d, v ){
+        ctxt.tsc_adjust =3D v->arch.hvm_vcpu.msr_tsc_adjust;
+        err =3D hvm_save_entry(TSC_ADJUST, v->vcpu_id, h, &ctxt);
+        if ( err )
+            break;
+    }
+
+    return err;
+}
+
+static int hvm_load_tsc_adjust(struct domain *d, hvm_domain_context_t *h)
+{
+    unsigned int vcpuid =3D hvm_load_instance(h);
+    struct vcpu *v;
+    struct hvm_tsc_adjust ctxt;
+
+    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);
+        return -EINVAL;
+    }
+
+    if ( hvm_load_entry(TSC_ADJUST, h, &ctxt) !=3D 0 )
+        return -EINVAL;
+
+    v->arch.hvm_vcpu.msr_tsc_adjust =3D ctxt.tsc_adjust;
+    return 0;
+}
+
+HVM_REGISTER_SAVE_RESTORE(TSC_ADJUST, hvm_save_tsc_adjust,
+                          hvm_load_tsc_adjust, 1, HVMSR_PER_VCPU);
+
 static int hvm_save_cpu_ctxt(struct domain *d, hvm_domain_context_t *h)
 {
     struct vcpu *v;
diff -r d94d78756665 xen/include/public/arch-x86/hvm/save.h
--- a/xen/include/public/arch-x86/hvm/save.h	Thu Sep 20 21:57:36 2012 +0800
+++ b/xen/include/public/arch-x86/hvm/save.h	Thu Sep 20 22:07:14 2012 +0800
@@ -583,9 +583,15 @@
=20
 DECLARE_HVM_SAVE_TYPE(VMCE_VCPU, 18, struct hvm_vmce_vcpu);
=20
+struct hvm_tsc_adjust {
+    uint64_t tsc_adjust;
+};
+
+DECLARE_HVM_SAVE_TYPE(TSC_ADJUST, 19, struct hvm_tsc_adjust);
+
 /*=20
  * Largest type-code in use
  */
-#define HVM_SAVE_CODE_MAX 18
+#define HVM_SAVE_CODE_MAX 19
=20
 #endif /* __XEN_PUBLIC_HVM_SAVE_X86_H__ */=

--_002_DE8DF0795D48FD4CA783C40EC8292335331ABBSHSMSX101ccrcorpi_
Content-Type: application/octet-stream; name="tsc_adjust_3.patch"
Content-Description: tsc_adjust_3.patch
Content-Disposition: attachment; filename="tsc_adjust_3.patch"; size=2967;
	creation-date="Thu, 20 Sep 2012 07:55:15 GMT";
	modification-date="Thu, 20 Sep 2012 15:40:24 GMT"
Content-Transfer-Encoding: base64

U2F2ZS9yZXN0b3JlIHRzYyBhZGp1c3Qgd2hlbiBtaWdyYXRlCgpTaWduZWQtb2ZmLWJ5OiBMaXUs
IEppbnNvbmcgPGppbnNvbmcubGl1QGludGVsLmNvbT4KCmRpZmYgLXIgZDk0ZDc4NzU2NjY1IHRv
b2xzL21pc2MveGVuLWh2bWN0eC5jCi0tLSBhL3Rvb2xzL21pc2MveGVuLWh2bWN0eC5jCVRodSBT
ZXAgMjAgMjE6NTc6MzYgMjAxMiArMDgwMAorKysgYi90b29scy9taXNjL3hlbi1odm1jdHguYwlU
aHUgU2VwIDIwIDIyOjA3OjE0IDIwMTIgKzA4MDAKQEAgLTM5Miw2ICszOTIsMTMgQEAKICAgICBw
cmludGYoIiAgICBWTUNFX1ZDUFU6IGJhbmsxIG1jaV9jdGwyICUiIFBSSXg2NCAiXG4iLCBwLm1j
aV9jdGwyX2JhbmsxKTsKIH0KIAorc3RhdGljIHZvaWQgZHVtcF90c2NfYWRqdXN0KHZvaWQpCit7
CisgICAgSFZNX1NBVkVfVFlQRShUU0NfQURKVVNUKSBwOworICAgIFJFQUQocCk7CisgICAgcHJp
bnRmKCIgICAgVFNDX0FESlVTVDogdHNjX2FkanVzdCAlIiBQUkl4NjQgIlxuIiwgcC50c2NfYWRq
dXN0KTsKK30KKwogaW50IG1haW4oaW50IGFyZ2MsIGNoYXIgKiphcmd2KQogewogICAgIGludCBl
bnRyeSwgZG9taWQ7CkBAIC00NTksNiArNDY2LDcgQEAKICAgICAgICAgY2FzZSBIVk1fU0FWRV9D
T0RFKFZJUklESUFOX0RPTUFJTik6IGR1bXBfdmlyaWRpYW5fZG9tYWluKCk7IGJyZWFrOwogICAg
ICAgICBjYXNlIEhWTV9TQVZFX0NPREUoVklSSURJQU5fVkNQVSk6IGR1bXBfdmlyaWRpYW5fdmNw
dSgpOyBicmVhazsKICAgICAgICAgY2FzZSBIVk1fU0FWRV9DT0RFKFZNQ0VfVkNQVSk6IGR1bXBf
dm1jZV92Y3B1KCk7IGJyZWFrOworICAgICAgICBjYXNlIEhWTV9TQVZFX0NPREUoVFNDX0FESlVT
VCk6IGR1bXBfdHNjX2FkanVzdCgpOyBicmVhazsKICAgICAgICAgY2FzZSBIVk1fU0FWRV9DT0RF
KEVORCk6IGJyZWFrOwogICAgICAgICBkZWZhdWx0OgogICAgICAgICAgICAgcHJpbnRmKCIgKiog
RG9uJ3QgdW5kZXJzdGFuZCB0eXBlICV1OiBza2lwcGluZ1xuIiwKZGlmZiAtciBkOTRkNzg3NTY2
NjUgeGVuL2FyY2gveDg2L2h2bS9odm0uYwotLS0gYS94ZW4vYXJjaC94ODYvaHZtL2h2bS5jCVRo
dSBTZXAgMjAgMjE6NTc6MzYgMjAxMiArMDgwMAorKysgYi94ZW4vYXJjaC94ODYvaHZtL2h2bS5j
CVRodSBTZXAgMjAgMjI6MDc6MTQgMjAxMiArMDgwMApAQCAtNjA1LDYgKzYwNSw0NSBAQAogICAg
IGh2bV9kZXN0cm95X2NhY2hlYXR0cl9yZWdpb25fbGlzdChkKTsKIH0KIAorc3RhdGljIGludCBo
dm1fc2F2ZV90c2NfYWRqdXN0KHN0cnVjdCBkb21haW4gKmQsIGh2bV9kb21haW5fY29udGV4dF90
ICpoKQoreworICAgIHN0cnVjdCB2Y3B1ICp2OworICAgIHN0cnVjdCBodm1fdHNjX2FkanVzdCBj
dHh0OworICAgIGludCBlcnIgPSAwOworCisgICAgZm9yX2VhY2hfdmNwdSggZCwgdiApeworICAg
ICAgICBjdHh0LnRzY19hZGp1c3QgPSB2LT5hcmNoLmh2bV92Y3B1Lm1zcl90c2NfYWRqdXN0Owor
ICAgICAgICBlcnIgPSBodm1fc2F2ZV9lbnRyeShUU0NfQURKVVNULCB2LT52Y3B1X2lkLCBoLCAm
Y3R4dCk7CisgICAgICAgIGlmICggZXJyICkKKyAgICAgICAgICAgIGJyZWFrOworICAgIH0KKwor
ICAgIHJldHVybiBlcnI7Cit9CisKK3N0YXRpYyBpbnQgaHZtX2xvYWRfdHNjX2FkanVzdChzdHJ1
Y3QgZG9tYWluICpkLCBodm1fZG9tYWluX2NvbnRleHRfdCAqaCkKK3sKKyAgICB1bnNpZ25lZCBp
bnQgdmNwdWlkID0gaHZtX2xvYWRfaW5zdGFuY2UoaCk7CisgICAgc3RydWN0IHZjcHUgKnY7Cisg
ICAgc3RydWN0IGh2bV90c2NfYWRqdXN0IGN0eHQ7CisKKyAgICBpZiAoIHZjcHVpZCA+PSBkLT5t
YXhfdmNwdXMgfHwgKHYgPSBkLT52Y3B1W3ZjcHVpZF0pID09IE5VTEwgKQorICAgIHsKKyAgICAg
ICAgZHByaW50ayhYRU5MT0dfR19FUlIsICJIVk0gcmVzdG9yZTogZG9tJWQgaGFzIG5vIHZjcHUl
dVxuIiwKKyAgICAgICAgICAgICAgICBkLT5kb21haW5faWQsIHZjcHVpZCk7CisgICAgICAgIHJl
dHVybiAtRUlOVkFMOworICAgIH0KKworICAgIGlmICggaHZtX2xvYWRfZW50cnkoVFNDX0FESlVT
VCwgaCwgJmN0eHQpICE9IDAgKQorICAgICAgICByZXR1cm4gLUVJTlZBTDsKKworICAgIHYtPmFy
Y2guaHZtX3ZjcHUubXNyX3RzY19hZGp1c3QgPSBjdHh0LnRzY19hZGp1c3Q7CisgICAgcmV0dXJu
IDA7Cit9CisKK0hWTV9SRUdJU1RFUl9TQVZFX1JFU1RPUkUoVFNDX0FESlVTVCwgaHZtX3NhdmVf
dHNjX2FkanVzdCwKKyAgICAgICAgICAgICAgICAgICAgICAgICAgaHZtX2xvYWRfdHNjX2FkanVz
dCwgMSwgSFZNU1JfUEVSX1ZDUFUpOworCiBzdGF0aWMgaW50IGh2bV9zYXZlX2NwdV9jdHh0KHN0
cnVjdCBkb21haW4gKmQsIGh2bV9kb21haW5fY29udGV4dF90ICpoKQogewogICAgIHN0cnVjdCB2
Y3B1ICp2OwpkaWZmIC1yIGQ5NGQ3ODc1NjY2NSB4ZW4vaW5jbHVkZS9wdWJsaWMvYXJjaC14ODYv
aHZtL3NhdmUuaAotLS0gYS94ZW4vaW5jbHVkZS9wdWJsaWMvYXJjaC14ODYvaHZtL3NhdmUuaAlU
aHUgU2VwIDIwIDIxOjU3OjM2IDIwMTIgKzA4MDAKKysrIGIveGVuL2luY2x1ZGUvcHVibGljL2Fy
Y2gteDg2L2h2bS9zYXZlLmgJVGh1IFNlcCAyMCAyMjowNzoxNCAyMDEyICswODAwCkBAIC01ODMs
OSArNTgzLDE1IEBACiAKIERFQ0xBUkVfSFZNX1NBVkVfVFlQRShWTUNFX1ZDUFUsIDE4LCBzdHJ1
Y3QgaHZtX3ZtY2VfdmNwdSk7CiAKK3N0cnVjdCBodm1fdHNjX2FkanVzdCB7CisgICAgdWludDY0
X3QgdHNjX2FkanVzdDsKK307CisKK0RFQ0xBUkVfSFZNX1NBVkVfVFlQRShUU0NfQURKVVNULCAx
OSwgc3RydWN0IGh2bV90c2NfYWRqdXN0KTsKKwogLyogCiAgKiBMYXJnZXN0IHR5cGUtY29kZSBp
biB1c2UKICAqLwotI2RlZmluZSBIVk1fU0FWRV9DT0RFX01BWCAxOAorI2RlZmluZSBIVk1fU0FW
RV9DT0RFX01BWCAxOQogCiAjZW5kaWYgLyogX19YRU5fUFVCTElDX0hWTV9TQVZFX1g4Nl9IX18g
Ki8K

--_002_DE8DF0795D48FD4CA783C40EC8292335331ABBSHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 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_DE8DF0795D48FD4CA783C40EC8292335331ABBSHSMSX101ccrcorpi_--


From xen-devel-bounces@lists.xen.org Thu Sep 20 08:14:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Sep 2012 08:14:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TEbtp-00029Z-RL; Thu, 20 Sep 2012 08:14:17 +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 1TEbto-00029P-CT
	for xen-devel@lists.xen.org; Thu, 20 Sep 2012 08:14:16 +0000
Received: from [85.158.138.51:7095] by server-9.bemta-3.messagelabs.com id
	62/4B-15390-750DA505; Thu, 20 Sep 2012 08:14:15 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1348128854!31268295!1
X-Originating-IP: [209.85.215.173]
X-SpamReason: No, hits=0.4 required=7.0 tests=MIME_QP_LONG_LINE,
  RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18481 invoked from network); 20 Sep 2012 08:14:14 -0000
Received: from mail-ey0-f173.google.com (HELO mail-ey0-f173.google.com)
	(209.85.215.173)
	by server-11.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Sep 2012 08:14:14 -0000
Received: by eaac13 with SMTP id c13so631216eaa.32
	for <xen-devel@lists.xen.org>; Thu, 20 Sep 2012 01:14:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=aK8S6yfCmNLEjXMhifaNUW56J57YxBLbo7JSy2P0K1A=;
	b=P+J2ueB405CtOmMdPVCpCtV7qsaA2UEq6unsZryuRjcADc0lIT9Tjhds3+RJpvSHY5
	2T8Jj5bxc9ApGkGnt4EvtX5OHFsVQQCjCxZvZ+HLuvTav964VTeRUxDCn5ToCNzoFcBT
	WWPRZDv7gGTT8MpTOHiGPK8mZqh9aRJc3kd+rJUNcMJPGtJCY6dLLe4P3cUVmde0XO/L
	tj74o8g/IG9l4AGSf9M61avsLyfcYXBwiOUuOP/NBybjZRP9FPjIfZFiHQ9SQR6ofPeS
	+uLGygauG+lTCPAreTFi3R7uLNcrH7DAcBVen5ImtOS37nCnGsKBRotqzM1Kca6zT7wO
	ZTvg==
Received: by 10.14.212.72 with SMTP id x48mr1134469eeo.40.1348128854481;
	Thu, 20 Sep 2012 01:14:14 -0700 (PDT)
Received: from [192.168.1.3] (host86-167-82-156.range86-167.btcentralplus.com.
	[86.167.82.156])
	by mx.google.com with ESMTPS id k41sm13495619eep.13.2012.09.20.01.14.11
	(version=SSLv3 cipher=OTHER); Thu, 20 Sep 2012 01:14:13 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.33.0.120411
Date: Thu, 20 Sep 2012 09:14:08 +0100
From: Keir Fraser <keir@xen.org>
To: Jan Beulich <JBeulich@suse.com>, Keir Fraser <keir.xen@gmail.com>,
	Ben Guthro <ben@guthro.net>
Message-ID: <CC808EE0.4C7FA%keir@xen.org>
Thread-Topic: [Xen-devel] Xen4.2 S3 regression?
Thread-Index: Ac2XB+g11YfUwRUR4kqnriswd3RB7Q==
In-Reply-To: <505AE9DB020000780009C813@nat28.tlf.novell.com>
Mime-version: 1.0
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>, john.baboval@citrix.com,
	Thomas Goetz <thomas.goetz@citrix.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen4.2 S3 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="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gMjAvMDkvMjAxMiAwOTowMywgIkphbiBCZXVsaWNoIiA8SkJldWxpY2hAc3VzZS5jb20+IHdy
b3RlOgoKPj4+PiBPbiAyMC4wOS4xMiBhdCAwODoxMywgS2VpciBGcmFzZXIgPGtlaXIueGVuQGdt
YWlsLmNvbT4gd3JvdGU6Cj4+IENQVSMxIGdvdCBzdHVjayBpbiBsb29wIGluIGNwdV9pbml0KCkg
YXMgaXQgYXBwZWFycyB0byBiZSDFkmFscmVhZHkKPj4gaW5pdGlhbGlzZWTCuSBpbiBjcHVfaW5p
dGlhbGl6ZWQgYml0bWFwLiBDUFUjMCBkZXRlY3RzIGl0IGlzIHN0dWNrIGFuZAo+PiBjYXJyaWVz
IG9uLCBidXQgdGhlIHJlc3VtZSBjb2RlIGFzc3VtZXMgYWxsIENQVXMgYXJlIGJyb3VnaHQgYmFj
ayBvbmxpbmUgYW5kCj4+IGNyYXNoZXMgbGF0ZXIuCj4gCj4gU28gdGhpcyB3b3VsZCBzdWdnZXN0
IHBsYXlfZGVhZCgpICgtPiBjcHVfZXhpdF9jbGVhcigpIC0+Cj4gY3B1X3VuaW5pdCgpKSBub3Qg
Z2V0dGluZyByZWFjaGVkIGR1cmluZyB0aGUgc3VzcGVuZCBjeWNsZS4KPiBUaGF0IHNob3VsZCBi
ZSBmYWlybHkgZWFzeSB0byB2ZXJpZnksIGFzIHRoZSBzZXJpYWwgY29uc29sZQo+IG91Z2h0IHRv
IHN0aWxsIHdvcmsgd2hlbiB0aGUgc2Vjb25kYXJ5IENQVXMgZ2V0IG9mZmxpbmVkLgoKWWVzLgoK
PiBUaGF0IG1pZ2h0IGltcGx5IGNwdW1hc2tfY2xlYXJfY3B1KGNwdSwgJmNwdV9vbmxpbmVfbWFw
KQo+IG5vdCBnZXR0aW5nIHJlYWNoZWQgaW4gX19jcHVfZGlzYWJsZSgpLCB3aGljaCB3b3VsZCBi
ZSBpbiBsaW5lCj4gd2l0aCB0aGUgb2JzZXJ2YXRpb24gdGhhdCBub25lIG9mIHRoZSBsb2dzIHBy
b3ZpZGVkIHNvIGZhcgo+IHNob3dlZCBhbnl0aGluZyBiZWluZyBkb25lIGJ5IGZpeHVwX2lycXMo
KSAoY2FsbGVkIHJpZ2h0Cj4gYWZ0ZXIgY2xlYXJpbmcgdGhlIG9ubGluZSBiaXQpLgoKSSBkaWQg
anVzdCB0ZXN0IGNwdSBvZmZsaW5lL29ubGluZSB2aWEgeGVuLWhwdG9vbCBteXNlbGYsIGFuZCB0
aGF0IGRvZXMKd29yay4gU28gcGVyaGFwcyB0aGlzIGlzIHBsYXRmb3JtIHNwZWNpZmljLCBvciBT
MyBzcGVjaWZpYy4uLgoKIC0tIEtlaXIKCj4gSmFuCgoKCl9fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVs
QGxpc3RzLnhlbi5vcmcKaHR0cDovL2xpc3RzLnhlbi5vcmcveGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Thu Sep 20 08:14:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Sep 2012 08:14:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TEbtp-00029Z-RL; Thu, 20 Sep 2012 08:14:17 +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 1TEbto-00029P-CT
	for xen-devel@lists.xen.org; Thu, 20 Sep 2012 08:14:16 +0000
Received: from [85.158.138.51:7095] by server-9.bemta-3.messagelabs.com id
	62/4B-15390-750DA505; Thu, 20 Sep 2012 08:14:15 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1348128854!31268295!1
X-Originating-IP: [209.85.215.173]
X-SpamReason: No, hits=0.4 required=7.0 tests=MIME_QP_LONG_LINE,
  RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18481 invoked from network); 20 Sep 2012 08:14:14 -0000
Received: from mail-ey0-f173.google.com (HELO mail-ey0-f173.google.com)
	(209.85.215.173)
	by server-11.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Sep 2012 08:14:14 -0000
Received: by eaac13 with SMTP id c13so631216eaa.32
	for <xen-devel@lists.xen.org>; Thu, 20 Sep 2012 01:14:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=aK8S6yfCmNLEjXMhifaNUW56J57YxBLbo7JSy2P0K1A=;
	b=P+J2ueB405CtOmMdPVCpCtV7qsaA2UEq6unsZryuRjcADc0lIT9Tjhds3+RJpvSHY5
	2T8Jj5bxc9ApGkGnt4EvtX5OHFsVQQCjCxZvZ+HLuvTav964VTeRUxDCn5ToCNzoFcBT
	WWPRZDv7gGTT8MpTOHiGPK8mZqh9aRJc3kd+rJUNcMJPGtJCY6dLLe4P3cUVmde0XO/L
	tj74o8g/IG9l4AGSf9M61avsLyfcYXBwiOUuOP/NBybjZRP9FPjIfZFiHQ9SQR6ofPeS
	+uLGygauG+lTCPAreTFi3R7uLNcrH7DAcBVen5ImtOS37nCnGsKBRotqzM1Kca6zT7wO
	ZTvg==
Received: by 10.14.212.72 with SMTP id x48mr1134469eeo.40.1348128854481;
	Thu, 20 Sep 2012 01:14:14 -0700 (PDT)
Received: from [192.168.1.3] (host86-167-82-156.range86-167.btcentralplus.com.
	[86.167.82.156])
	by mx.google.com with ESMTPS id k41sm13495619eep.13.2012.09.20.01.14.11
	(version=SSLv3 cipher=OTHER); Thu, 20 Sep 2012 01:14:13 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.33.0.120411
Date: Thu, 20 Sep 2012 09:14:08 +0100
From: Keir Fraser <keir@xen.org>
To: Jan Beulich <JBeulich@suse.com>, Keir Fraser <keir.xen@gmail.com>,
	Ben Guthro <ben@guthro.net>
Message-ID: <CC808EE0.4C7FA%keir@xen.org>
Thread-Topic: [Xen-devel] Xen4.2 S3 regression?
Thread-Index: Ac2XB+g11YfUwRUR4kqnriswd3RB7Q==
In-Reply-To: <505AE9DB020000780009C813@nat28.tlf.novell.com>
Mime-version: 1.0
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>, john.baboval@citrix.com,
	Thomas Goetz <thomas.goetz@citrix.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen4.2 S3 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="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gMjAvMDkvMjAxMiAwOTowMywgIkphbiBCZXVsaWNoIiA8SkJldWxpY2hAc3VzZS5jb20+IHdy
b3RlOgoKPj4+PiBPbiAyMC4wOS4xMiBhdCAwODoxMywgS2VpciBGcmFzZXIgPGtlaXIueGVuQGdt
YWlsLmNvbT4gd3JvdGU6Cj4+IENQVSMxIGdvdCBzdHVjayBpbiBsb29wIGluIGNwdV9pbml0KCkg
YXMgaXQgYXBwZWFycyB0byBiZSDFkmFscmVhZHkKPj4gaW5pdGlhbGlzZWTCuSBpbiBjcHVfaW5p
dGlhbGl6ZWQgYml0bWFwLiBDUFUjMCBkZXRlY3RzIGl0IGlzIHN0dWNrIGFuZAo+PiBjYXJyaWVz
IG9uLCBidXQgdGhlIHJlc3VtZSBjb2RlIGFzc3VtZXMgYWxsIENQVXMgYXJlIGJyb3VnaHQgYmFj
ayBvbmxpbmUgYW5kCj4+IGNyYXNoZXMgbGF0ZXIuCj4gCj4gU28gdGhpcyB3b3VsZCBzdWdnZXN0
IHBsYXlfZGVhZCgpICgtPiBjcHVfZXhpdF9jbGVhcigpIC0+Cj4gY3B1X3VuaW5pdCgpKSBub3Qg
Z2V0dGluZyByZWFjaGVkIGR1cmluZyB0aGUgc3VzcGVuZCBjeWNsZS4KPiBUaGF0IHNob3VsZCBi
ZSBmYWlybHkgZWFzeSB0byB2ZXJpZnksIGFzIHRoZSBzZXJpYWwgY29uc29sZQo+IG91Z2h0IHRv
IHN0aWxsIHdvcmsgd2hlbiB0aGUgc2Vjb25kYXJ5IENQVXMgZ2V0IG9mZmxpbmVkLgoKWWVzLgoK
PiBUaGF0IG1pZ2h0IGltcGx5IGNwdW1hc2tfY2xlYXJfY3B1KGNwdSwgJmNwdV9vbmxpbmVfbWFw
KQo+IG5vdCBnZXR0aW5nIHJlYWNoZWQgaW4gX19jcHVfZGlzYWJsZSgpLCB3aGljaCB3b3VsZCBi
ZSBpbiBsaW5lCj4gd2l0aCB0aGUgb2JzZXJ2YXRpb24gdGhhdCBub25lIG9mIHRoZSBsb2dzIHBy
b3ZpZGVkIHNvIGZhcgo+IHNob3dlZCBhbnl0aGluZyBiZWluZyBkb25lIGJ5IGZpeHVwX2lycXMo
KSAoY2FsbGVkIHJpZ2h0Cj4gYWZ0ZXIgY2xlYXJpbmcgdGhlIG9ubGluZSBiaXQpLgoKSSBkaWQg
anVzdCB0ZXN0IGNwdSBvZmZsaW5lL29ubGluZSB2aWEgeGVuLWhwdG9vbCBteXNlbGYsIGFuZCB0
aGF0IGRvZXMKd29yay4gU28gcGVyaGFwcyB0aGlzIGlzIHBsYXRmb3JtIHNwZWNpZmljLCBvciBT
MyBzcGVjaWZpYy4uLgoKIC0tIEtlaXIKCj4gSmFuCgoKCl9fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVs
QGxpc3RzLnhlbi5vcmcKaHR0cDovL2xpc3RzLnhlbi5vcmcveGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Thu Sep 20 08:17:00 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Sep 2012 08: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 1TEbwI-0002Iu-DS; Thu, 20 Sep 2012 08:16:50 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1TEbwH-0002In-Mk
	for xen-devel@lists.xensource.com; Thu, 20 Sep 2012 08:16:49 +0000
Received: from [85.158.143.99:17588] by server-1.bemta-4.messagelabs.com id
	71/B2-05684-FE0DA505; Thu, 20 Sep 2012 08:16:47 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1348129007!25791881!1
X-Originating-IP: [74.125.83.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15766 invoked from network); 20 Sep 2012 08:16:47 -0000
Received: from mail-ee0-f43.google.com (HELO mail-ee0-f43.google.com)
	(74.125.83.43)
	by server-4.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Sep 2012 08:16:47 -0000
Received: by eekd4 with SMTP id d4so812644eek.30
	for <xen-devel@lists.xensource.com>;
	Thu, 20 Sep 2012 01:16:47 -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=3hK9zXvHHh/Y/foltbZbXJYnPE2feDnlSqfDKE9QIYQ=;
	b=Iv+VtOdb5eiXHvzkSwrg0nx+mEcItwzBy33kI66BgYUNqsb3N2FzqNkWv7xgHX4egC
	XfYlPtSNw/2KeoclDTBet+ErSdnIPDGlDdP0QObhh1BmFrFLisvbR2v3jVrxG7T2CJ6n
	HApQIy4kiDA7R0B+6ScLuNNG5mOu+NKzH2eKoH9OeX2PeuN9Ec5//J1aw6Z60rMjP/Hw
	d5L+d3h9C6LIC42+3/P18MibTBM2x2S7rq4guOh3Of39PhlnNWZSBBu7jRUFcfTxPL6e
	iH8h7iY4lnro2f+zdUOVTFkFir4iXrXeNGGE8frYFgeaEk2yZZC6BdpNzHfXp4oLS6Ae
	P7gQ==
Received: by 10.14.199.67 with SMTP id w43mr1166969een.33.1348129006957;
	Thu, 20 Sep 2012 01:16:46 -0700 (PDT)
Received: from [192.168.1.3] (host86-167-82-156.range86-167.btcentralplus.com.
	[86.167.82.156])
	by mx.google.com with ESMTPS id l42sm13633318eep.1.2012.09.20.01.16.45
	(version=SSLv3 cipher=OTHER); Thu, 20 Sep 2012 01:16:46 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.33.0.120411
Date: Thu, 20 Sep 2012 09:16:42 +0100
From: Keir Fraser <keir@xen.org>
To: "Liu, Jinsong" <jinsong.liu@intel.com>, Jan Beulich <JBeulich@suse.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Message-ID: <CC808F7A.4C812%keir@xen.org>
Thread-Topic: [PATCH 0/3] tsc adjust implementation for hvm
Thread-Index: Ac2XBtJ3RWSMroowQbKXJZr90iOO2QAAXGKj
In-Reply-To: <DE8DF0795D48FD4CA783C40EC8292335331A65@SHSMSX101.ccr.corp.intel.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] [PATCH 0/3] tsc adjust implementation for hvm
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 20/09/2012 09:06, "Liu, Jinsong" <jinsong.liu@intel.com> wrote:

> Intel recently release a new tsc adjust feature at latest SDM 17.13.3.
> CPUID.7.0.EBX[1]=1 indicates TSC_ADJUST MSR 0x3b is supported.
> 
> Basically it is used to simplify TSC synchronization, operation of
> IA32_TSC_ADJUST MSR is as follows:
> 1). On RESET, the value of the IA32_TSC_ADJUST MSR is 0;
> 2). If an execution of WRMSR to the IA32_TIME_STAMP_COUNTER MSR adds (or
> subtracts)
>     value X from the TSC, the logical processor also adds (or subtracts) value
> X
>     from the IA32_TSC_ADJUST MSR;
> 3). If an execution of WRMSR to the IA32_TSC_ADJUST MSR adds (or subtracts)
>     value X from that MSR, the logical processor also adds (or subtracts)
> value X
>     from the TSC;
> 
> With it, OS would be easier when sync tsc.

Actually it appears to strictly add code to, and hence complicate, the
hypervisor. So how exactly is it beneficial?

 -- Keir

> 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 Sep 20 08:17:00 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Sep 2012 08: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 1TEbwI-0002Iu-DS; Thu, 20 Sep 2012 08:16:50 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1TEbwH-0002In-Mk
	for xen-devel@lists.xensource.com; Thu, 20 Sep 2012 08:16:49 +0000
Received: from [85.158.143.99:17588] by server-1.bemta-4.messagelabs.com id
	71/B2-05684-FE0DA505; Thu, 20 Sep 2012 08:16:47 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1348129007!25791881!1
X-Originating-IP: [74.125.83.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15766 invoked from network); 20 Sep 2012 08:16:47 -0000
Received: from mail-ee0-f43.google.com (HELO mail-ee0-f43.google.com)
	(74.125.83.43)
	by server-4.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Sep 2012 08:16:47 -0000
Received: by eekd4 with SMTP id d4so812644eek.30
	for <xen-devel@lists.xensource.com>;
	Thu, 20 Sep 2012 01:16:47 -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=3hK9zXvHHh/Y/foltbZbXJYnPE2feDnlSqfDKE9QIYQ=;
	b=Iv+VtOdb5eiXHvzkSwrg0nx+mEcItwzBy33kI66BgYUNqsb3N2FzqNkWv7xgHX4egC
	XfYlPtSNw/2KeoclDTBet+ErSdnIPDGlDdP0QObhh1BmFrFLisvbR2v3jVrxG7T2CJ6n
	HApQIy4kiDA7R0B+6ScLuNNG5mOu+NKzH2eKoH9OeX2PeuN9Ec5//J1aw6Z60rMjP/Hw
	d5L+d3h9C6LIC42+3/P18MibTBM2x2S7rq4guOh3Of39PhlnNWZSBBu7jRUFcfTxPL6e
	iH8h7iY4lnro2f+zdUOVTFkFir4iXrXeNGGE8frYFgeaEk2yZZC6BdpNzHfXp4oLS6Ae
	P7gQ==
Received: by 10.14.199.67 with SMTP id w43mr1166969een.33.1348129006957;
	Thu, 20 Sep 2012 01:16:46 -0700 (PDT)
Received: from [192.168.1.3] (host86-167-82-156.range86-167.btcentralplus.com.
	[86.167.82.156])
	by mx.google.com with ESMTPS id l42sm13633318eep.1.2012.09.20.01.16.45
	(version=SSLv3 cipher=OTHER); Thu, 20 Sep 2012 01:16:46 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.33.0.120411
Date: Thu, 20 Sep 2012 09:16:42 +0100
From: Keir Fraser <keir@xen.org>
To: "Liu, Jinsong" <jinsong.liu@intel.com>, Jan Beulich <JBeulich@suse.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Message-ID: <CC808F7A.4C812%keir@xen.org>
Thread-Topic: [PATCH 0/3] tsc adjust implementation for hvm
Thread-Index: Ac2XBtJ3RWSMroowQbKXJZr90iOO2QAAXGKj
In-Reply-To: <DE8DF0795D48FD4CA783C40EC8292335331A65@SHSMSX101.ccr.corp.intel.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] [PATCH 0/3] tsc adjust implementation for hvm
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 20/09/2012 09:06, "Liu, Jinsong" <jinsong.liu@intel.com> wrote:

> Intel recently release a new tsc adjust feature at latest SDM 17.13.3.
> CPUID.7.0.EBX[1]=1 indicates TSC_ADJUST MSR 0x3b is supported.
> 
> Basically it is used to simplify TSC synchronization, operation of
> IA32_TSC_ADJUST MSR is as follows:
> 1). On RESET, the value of the IA32_TSC_ADJUST MSR is 0;
> 2). If an execution of WRMSR to the IA32_TIME_STAMP_COUNTER MSR adds (or
> subtracts)
>     value X from the TSC, the logical processor also adds (or subtracts) value
> X
>     from the IA32_TSC_ADJUST MSR;
> 3). If an execution of WRMSR to the IA32_TSC_ADJUST MSR adds (or subtracts)
>     value X from that MSR, the logical processor also adds (or subtracts)
> value X
>     from the TSC;
> 
> With it, OS would be easier when sync tsc.

Actually it appears to strictly add code to, and hence complicate, the
hypervisor. So how exactly is it beneficial?

 -- Keir

> 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 Sep 20 08:21:50 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Sep 2012 08: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 1TEc0z-0002UM-96; Thu, 20 Sep 2012 08:21:41 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1TEc0x-0002UG-Vt
	for xen-devel@lists.xen.org; Thu, 20 Sep 2012 08:21:40 +0000
Received: from [85.158.143.99:51103] by server-2.bemta-4.messagelabs.com id
	AB/CC-06610-312DA505; Thu, 20 Sep 2012 08:21:39 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1348129298!21297184!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24904 invoked from network); 20 Sep 2012 08:21:38 -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;
	20 Sep 2012 08:21:38 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 20 Sep 2012 09:21:38 +0100
Message-Id: <505AEE46020000780009C885@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 20 Sep 2012 09:21:58 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Jinsong Liu" <jinsong.liu@intel.com>
References: <DE8DF0795D48FD4CA783C40EC8292335331A72@SHSMSX101.ccr.corp.intel.com>
In-Reply-To: <DE8DF0795D48FD4CA783C40EC8292335331A72@SHSMSX101.ccr.corp.intel.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "keir@xen.org" <keir@xen.org>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 1/3] Expose tsc adjust to 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 20.09.12 at 10:07, "Liu, Jinsong" <jinsong.liu@intel.com> wrote:
> Expose tsc adjust to hvm guest
> 
> Intel latest SDM (17.13.3) release a new MSR
> CPUID.7.0.EBX[1]=1 indicates TSC_ADJUST MSR 0x3b is supported.
> 
> This patch expose it to hvm guest.
> 
> Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>

Shouldn't this be the last patch in the series, rather than the first
one?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 20 08:21:50 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Sep 2012 08: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 1TEc0z-0002UM-96; Thu, 20 Sep 2012 08:21:41 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1TEc0x-0002UG-Vt
	for xen-devel@lists.xen.org; Thu, 20 Sep 2012 08:21:40 +0000
Received: from [85.158.143.99:51103] by server-2.bemta-4.messagelabs.com id
	AB/CC-06610-312DA505; Thu, 20 Sep 2012 08:21:39 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1348129298!21297184!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24904 invoked from network); 20 Sep 2012 08:21:38 -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;
	20 Sep 2012 08:21:38 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 20 Sep 2012 09:21:38 +0100
Message-Id: <505AEE46020000780009C885@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 20 Sep 2012 09:21:58 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Jinsong Liu" <jinsong.liu@intel.com>
References: <DE8DF0795D48FD4CA783C40EC8292335331A72@SHSMSX101.ccr.corp.intel.com>
In-Reply-To: <DE8DF0795D48FD4CA783C40EC8292335331A72@SHSMSX101.ccr.corp.intel.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "keir@xen.org" <keir@xen.org>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 1/3] Expose tsc adjust to 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 20.09.12 at 10:07, "Liu, Jinsong" <jinsong.liu@intel.com> wrote:
> Expose tsc adjust to hvm guest
> 
> Intel latest SDM (17.13.3) release a new MSR
> CPUID.7.0.EBX[1]=1 indicates TSC_ADJUST MSR 0x3b is supported.
> 
> This patch expose it to hvm guest.
> 
> Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>

Shouldn't this be the last patch in the series, rather than the first
one?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 20 08:35:29 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Sep 2012 08: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 1TEcE8-0002fX-L5; Thu, 20 Sep 2012 08:35: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 1TEcE6-0002fS-I0
	for xen-devel@lists.xen.org; Thu, 20 Sep 2012 08:35:14 +0000
Received: from [85.158.138.51:36134] by server-8.bemta-3.messagelabs.com id
	FA/5C-24700-145DA505; Thu, 20 Sep 2012 08:35:13 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1348130112!29502127!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18069 invoked from network); 20 Sep 2012 08:35:12 -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;
	20 Sep 2012 08:35:12 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 20 Sep 2012 09:35:11 +0100
Message-Id: <505AF174020000780009C890@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 20 Sep 2012 09:35:32 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Jinsong Liu" <jinsong.liu@intel.com>
References: <DE8DF0795D48FD4CA783C40EC8292335331A8F@SHSMSX101.ccr.corp.intel.com>
In-Reply-To: <DE8DF0795D48FD4CA783C40EC8292335331A8F@SHSMSX101.ccr.corp.intel.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "keir@xen.org" <keir@xen.org>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 2/3] Implement tsc adjust 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

>>> On 20.09.12 at 10:09, "Liu, Jinsong" <jinsong.liu@intel.com> wrote:
> Implement tsc adjust feature

The title is a little misleading - with how it is, I would have expected
it to make use of the new MSR particularly in synchronize_tsc_slave()
(all other uses of write_tsc() should not be reached on modern CPUs).

But for the purpose of HVM , the patch looks okay to me.

Jan

> IA32_TSC_ADJUST MSR is maintained separately for each logical processor.
> A logical processor maintains and uses the IA32_TSC_ADJUST MSR as follows:
> 1). On RESET, the value of the IA32_TSC_ADJUST MSR is 0;
> 2). If an execution of WRMSR to the IA32_TIME_STAMP_COUNTER MSR adds (or 
> subtracts)
>     value X from the TSC, the logical processor also adds (or subtracts) 
> value X
>     from the IA32_TSC_ADJUST MSR;
> 3). If an execution of WRMSR to the IA32_TSC_ADJUST MSR adds (or subtracts)
>     value X from that MSR, the logical processor also adds (or subtracts) 
> value X
>     from the TSC;
> 
> Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>
> 
> diff -r d5c677159abb xen/arch/x86/hvm/hvm.c
> --- a/xen/arch/x86/hvm/hvm.c	Thu Sep 20 21:50:56 2012 +0800
> +++ b/xen/arch/x86/hvm/hvm.c	Thu Sep 20 23:34:04 2012 +0800
> @@ -244,6 +244,7 @@
>  void hvm_set_guest_tsc(struct vcpu *v, u64 guest_tsc)
>  {
>      uint64_t tsc;
> +    uint64_t delta_tsc;
>  
>      if ( v->domain->arch.vtsc )
>      {
> @@ -255,10 +256,23 @@
>          rdtscll(tsc);
>      }
>  
> -    v->arch.hvm_vcpu.cache_tsc_offset = guest_tsc - tsc;
> +    delta_tsc = guest_tsc - tsc;
> +
> +    v->arch.hvm_vcpu.msr_tsc_adjust += delta_tsc
> +                          - v->arch.hvm_vcpu.cache_tsc_offset;
> +    v->arch.hvm_vcpu.cache_tsc_offset = delta_tsc;
> +
>      hvm_funcs.set_tsc_offset(v, v->arch.hvm_vcpu.cache_tsc_offset);
>  }
>  
> +void hvm_set_guest_tsc_adjust(struct vcpu *v, u64 tsc_adjust)
> +{
> +    v->arch.hvm_vcpu.cache_tsc_offset += tsc_adjust
> +                            - v->arch.hvm_vcpu.msr_tsc_adjust;
> +    hvm_funcs.set_tsc_offset(v, v->arch.hvm_vcpu.cache_tsc_offset);
> +    v->arch.hvm_vcpu.msr_tsc_adjust = tsc_adjust;
> +}
> +
>  u64 hvm_get_guest_tsc(struct vcpu *v)
>  {
>      uint64_t tsc;
> @@ -277,6 +291,11 @@
>      return tsc + v->arch.hvm_vcpu.cache_tsc_offset;
>  }
>  
> +u64 hvm_get_guest_tsc_adjust(struct vcpu *v)
> +{
> +    return v->arch.hvm_vcpu.msr_tsc_adjust;
> +}
> +
>  void hvm_migrate_timers(struct vcpu *v)
>  {
>      rtc_migrate_timers(v);
> @@ -2776,6 +2795,10 @@
>          *msr_content = hvm_get_guest_tsc(v);
>          break;
>  
> +    case MSR_IA32_TSC_ADJUST:
> +        *msr_content = hvm_get_guest_tsc_adjust(v);
> +        break;
> +
>      case MSR_TSC_AUX:
>          *msr_content = hvm_msr_tsc_aux(v);
>          break;
> @@ -2889,6 +2912,10 @@
>          hvm_set_guest_tsc(v, msr_content);
>          break;
>  
> +    case MSR_IA32_TSC_ADJUST:
> +        hvm_set_guest_tsc_adjust(v, msr_content);
> +        break;
> +
>      case MSR_TSC_AUX:
>          v->arch.hvm_vcpu.msr_tsc_aux = (uint32_t)msr_content;
>          if ( cpu_has_rdtscp
> @@ -3436,6 +3463,8 @@
>          v->domain->vcpu[0]->arch.hvm_vcpu.cache_tsc_offset;
>      hvm_funcs.set_tsc_offset(v, v->arch.hvm_vcpu.cache_tsc_offset);
>  
> +    v->arch.hvm_vcpu.msr_tsc_adjust = 0;
> +
>      paging_update_paging_modes(v);
>  
>      v->arch.flags |= TF_kernel_mode;
> diff -r d5c677159abb xen/include/asm-x86/hvm/vcpu.h
> --- a/xen/include/asm-x86/hvm/vcpu.h	Thu Sep 20 21:50:56 2012 +0800
> +++ b/xen/include/asm-x86/hvm/vcpu.h	Thu Sep 20 23:34:04 2012 +0800
> @@ -137,6 +137,7 @@
>      struct hvm_vcpu_asid n1asid;
>  
>      u32                 msr_tsc_aux;
> +    u64                 msr_tsc_adjust;
>  
>      /* VPMU */
>      struct vpmu_struct  vpmu;
> diff -r d5c677159abb xen/include/asm-x86/msr-index.h
> --- a/xen/include/asm-x86/msr-index.h	Thu Sep 20 21:50:56 2012 +0800
> +++ b/xen/include/asm-x86/msr-index.h	Thu Sep 20 23:34:04 2012 +0800
> @@ -284,6 +284,7 @@
>  #define MSR_IA32_PLATFORM_ID		0x00000017
>  #define MSR_IA32_EBL_CR_POWERON		0x0000002a
>  #define MSR_IA32_EBC_FREQUENCY_ID	0x0000002c
> +#define MSR_IA32_TSC_ADJUST		0x0000003b
>  
>  #define MSR_IA32_APICBASE		0x0000001b
>  #define MSR_IA32_APICBASE_BSP		(1<<8)



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 20 08:35:29 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Sep 2012 08: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 1TEcE8-0002fX-L5; Thu, 20 Sep 2012 08:35: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 1TEcE6-0002fS-I0
	for xen-devel@lists.xen.org; Thu, 20 Sep 2012 08:35:14 +0000
Received: from [85.158.138.51:36134] by server-8.bemta-3.messagelabs.com id
	FA/5C-24700-145DA505; Thu, 20 Sep 2012 08:35:13 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1348130112!29502127!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18069 invoked from network); 20 Sep 2012 08:35:12 -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;
	20 Sep 2012 08:35:12 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 20 Sep 2012 09:35:11 +0100
Message-Id: <505AF174020000780009C890@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 20 Sep 2012 09:35:32 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Jinsong Liu" <jinsong.liu@intel.com>
References: <DE8DF0795D48FD4CA783C40EC8292335331A8F@SHSMSX101.ccr.corp.intel.com>
In-Reply-To: <DE8DF0795D48FD4CA783C40EC8292335331A8F@SHSMSX101.ccr.corp.intel.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "keir@xen.org" <keir@xen.org>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 2/3] Implement tsc adjust 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

>>> On 20.09.12 at 10:09, "Liu, Jinsong" <jinsong.liu@intel.com> wrote:
> Implement tsc adjust feature

The title is a little misleading - with how it is, I would have expected
it to make use of the new MSR particularly in synchronize_tsc_slave()
(all other uses of write_tsc() should not be reached on modern CPUs).

But for the purpose of HVM , the patch looks okay to me.

Jan

> IA32_TSC_ADJUST MSR is maintained separately for each logical processor.
> A logical processor maintains and uses the IA32_TSC_ADJUST MSR as follows:
> 1). On RESET, the value of the IA32_TSC_ADJUST MSR is 0;
> 2). If an execution of WRMSR to the IA32_TIME_STAMP_COUNTER MSR adds (or 
> subtracts)
>     value X from the TSC, the logical processor also adds (or subtracts) 
> value X
>     from the IA32_TSC_ADJUST MSR;
> 3). If an execution of WRMSR to the IA32_TSC_ADJUST MSR adds (or subtracts)
>     value X from that MSR, the logical processor also adds (or subtracts) 
> value X
>     from the TSC;
> 
> Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>
> 
> diff -r d5c677159abb xen/arch/x86/hvm/hvm.c
> --- a/xen/arch/x86/hvm/hvm.c	Thu Sep 20 21:50:56 2012 +0800
> +++ b/xen/arch/x86/hvm/hvm.c	Thu Sep 20 23:34:04 2012 +0800
> @@ -244,6 +244,7 @@
>  void hvm_set_guest_tsc(struct vcpu *v, u64 guest_tsc)
>  {
>      uint64_t tsc;
> +    uint64_t delta_tsc;
>  
>      if ( v->domain->arch.vtsc )
>      {
> @@ -255,10 +256,23 @@
>          rdtscll(tsc);
>      }
>  
> -    v->arch.hvm_vcpu.cache_tsc_offset = guest_tsc - tsc;
> +    delta_tsc = guest_tsc - tsc;
> +
> +    v->arch.hvm_vcpu.msr_tsc_adjust += delta_tsc
> +                          - v->arch.hvm_vcpu.cache_tsc_offset;
> +    v->arch.hvm_vcpu.cache_tsc_offset = delta_tsc;
> +
>      hvm_funcs.set_tsc_offset(v, v->arch.hvm_vcpu.cache_tsc_offset);
>  }
>  
> +void hvm_set_guest_tsc_adjust(struct vcpu *v, u64 tsc_adjust)
> +{
> +    v->arch.hvm_vcpu.cache_tsc_offset += tsc_adjust
> +                            - v->arch.hvm_vcpu.msr_tsc_adjust;
> +    hvm_funcs.set_tsc_offset(v, v->arch.hvm_vcpu.cache_tsc_offset);
> +    v->arch.hvm_vcpu.msr_tsc_adjust = tsc_adjust;
> +}
> +
>  u64 hvm_get_guest_tsc(struct vcpu *v)
>  {
>      uint64_t tsc;
> @@ -277,6 +291,11 @@
>      return tsc + v->arch.hvm_vcpu.cache_tsc_offset;
>  }
>  
> +u64 hvm_get_guest_tsc_adjust(struct vcpu *v)
> +{
> +    return v->arch.hvm_vcpu.msr_tsc_adjust;
> +}
> +
>  void hvm_migrate_timers(struct vcpu *v)
>  {
>      rtc_migrate_timers(v);
> @@ -2776,6 +2795,10 @@
>          *msr_content = hvm_get_guest_tsc(v);
>          break;
>  
> +    case MSR_IA32_TSC_ADJUST:
> +        *msr_content = hvm_get_guest_tsc_adjust(v);
> +        break;
> +
>      case MSR_TSC_AUX:
>          *msr_content = hvm_msr_tsc_aux(v);
>          break;
> @@ -2889,6 +2912,10 @@
>          hvm_set_guest_tsc(v, msr_content);
>          break;
>  
> +    case MSR_IA32_TSC_ADJUST:
> +        hvm_set_guest_tsc_adjust(v, msr_content);
> +        break;
> +
>      case MSR_TSC_AUX:
>          v->arch.hvm_vcpu.msr_tsc_aux = (uint32_t)msr_content;
>          if ( cpu_has_rdtscp
> @@ -3436,6 +3463,8 @@
>          v->domain->vcpu[0]->arch.hvm_vcpu.cache_tsc_offset;
>      hvm_funcs.set_tsc_offset(v, v->arch.hvm_vcpu.cache_tsc_offset);
>  
> +    v->arch.hvm_vcpu.msr_tsc_adjust = 0;
> +
>      paging_update_paging_modes(v);
>  
>      v->arch.flags |= TF_kernel_mode;
> diff -r d5c677159abb xen/include/asm-x86/hvm/vcpu.h
> --- a/xen/include/asm-x86/hvm/vcpu.h	Thu Sep 20 21:50:56 2012 +0800
> +++ b/xen/include/asm-x86/hvm/vcpu.h	Thu Sep 20 23:34:04 2012 +0800
> @@ -137,6 +137,7 @@
>      struct hvm_vcpu_asid n1asid;
>  
>      u32                 msr_tsc_aux;
> +    u64                 msr_tsc_adjust;
>  
>      /* VPMU */
>      struct vpmu_struct  vpmu;
> diff -r d5c677159abb xen/include/asm-x86/msr-index.h
> --- a/xen/include/asm-x86/msr-index.h	Thu Sep 20 21:50:56 2012 +0800
> +++ b/xen/include/asm-x86/msr-index.h	Thu Sep 20 23:34:04 2012 +0800
> @@ -284,6 +284,7 @@
>  #define MSR_IA32_PLATFORM_ID		0x00000017
>  #define MSR_IA32_EBL_CR_POWERON		0x0000002a
>  #define MSR_IA32_EBC_FREQUENCY_ID	0x0000002c
> +#define MSR_IA32_TSC_ADJUST		0x0000003b
>  
>  #define MSR_IA32_APICBASE		0x0000001b
>  #define MSR_IA32_APICBASE_BSP		(1<<8)



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 20 08:37:44 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Sep 2012 08:37: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 1TEcGJ-0002l0-6c; Thu, 20 Sep 2012 08:37:31 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1TEcGI-0002ku-No
	for xen-devel@lists.xen.org; Thu, 20 Sep 2012 08:37:30 +0000
Received: from [85.158.137.99:48190] by server-3.bemta-3.messagelabs.com id
	AA/43-21322-9C5DA505; Thu, 20 Sep 2012 08:37:29 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-217.messagelabs.com!1348130249!18430310!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14901 invoked from network); 20 Sep 2012 08:37:29 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-10.tower-217.messagelabs.com with SMTP;
	20 Sep 2012 08:37:29 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 20 Sep 2012 09:37:28 +0100
Message-Id: <505AF1FD020000780009C893@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 20 Sep 2012 09:37:49 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Keir Fraser" <keir@xen.org>
References: <DE8DF0795D48FD4CA783C40EC8292335331A65@SHSMSX101.ccr.corp.intel.com>
	<CC808F7A.4C812%keir@xen.org>
In-Reply-To: <CC808F7A.4C812%keir@xen.org>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Jinsong Liu <jinsong.liu@intel.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 0/3] tsc adjust implementation for hvm
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 20.09.12 at 10:16, Keir Fraser <keir@xen.org> wrote:
> On 20/09/2012 09:06, "Liu, Jinsong" <jinsong.liu@intel.com> wrote:
> 
>> Intel recently release a new tsc adjust feature at latest SDM 17.13.3.
>> CPUID.7.0.EBX[1]=1 indicates TSC_ADJUST MSR 0x3b is supported.
>> 
>> Basically it is used to simplify TSC synchronization, operation of
>> IA32_TSC_ADJUST MSR is as follows:
>> 1). On RESET, the value of the IA32_TSC_ADJUST MSR is 0;
>> 2). If an execution of WRMSR to the IA32_TIME_STAMP_COUNTER MSR adds (or
>> subtracts)
>>     value X from the TSC, the logical processor also adds (or subtracts) 
> value
>> X
>>     from the IA32_TSC_ADJUST MSR;
>> 3). If an execution of WRMSR to the IA32_TSC_ADJUST MSR adds (or subtracts)
>>     value X from that MSR, the logical processor also adds (or subtracts)
>> value X
>>     from the TSC;
>> 
>> With it, OS would be easier when sync tsc.
> 
> Actually it appears to strictly add code to, and hence complicate, the
> hypervisor. So how exactly is it beneficial?

It's beneficial to the guest if I'm not mistaken, for precisely the
purpose that patch 2 doesn't address for the hypervisor in spite
of its title (see my response there).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 20 08:37:44 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Sep 2012 08:37: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 1TEcGJ-0002l0-6c; Thu, 20 Sep 2012 08:37:31 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1TEcGI-0002ku-No
	for xen-devel@lists.xen.org; Thu, 20 Sep 2012 08:37:30 +0000
Received: from [85.158.137.99:48190] by server-3.bemta-3.messagelabs.com id
	AA/43-21322-9C5DA505; Thu, 20 Sep 2012 08:37:29 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-217.messagelabs.com!1348130249!18430310!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14901 invoked from network); 20 Sep 2012 08:37:29 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-10.tower-217.messagelabs.com with SMTP;
	20 Sep 2012 08:37:29 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 20 Sep 2012 09:37:28 +0100
Message-Id: <505AF1FD020000780009C893@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 20 Sep 2012 09:37:49 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Keir Fraser" <keir@xen.org>
References: <DE8DF0795D48FD4CA783C40EC8292335331A65@SHSMSX101.ccr.corp.intel.com>
	<CC808F7A.4C812%keir@xen.org>
In-Reply-To: <CC808F7A.4C812%keir@xen.org>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Jinsong Liu <jinsong.liu@intel.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 0/3] tsc adjust implementation for hvm
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 20.09.12 at 10:16, Keir Fraser <keir@xen.org> wrote:
> On 20/09/2012 09:06, "Liu, Jinsong" <jinsong.liu@intel.com> wrote:
> 
>> Intel recently release a new tsc adjust feature at latest SDM 17.13.3.
>> CPUID.7.0.EBX[1]=1 indicates TSC_ADJUST MSR 0x3b is supported.
>> 
>> Basically it is used to simplify TSC synchronization, operation of
>> IA32_TSC_ADJUST MSR is as follows:
>> 1). On RESET, the value of the IA32_TSC_ADJUST MSR is 0;
>> 2). If an execution of WRMSR to the IA32_TIME_STAMP_COUNTER MSR adds (or
>> subtracts)
>>     value X from the TSC, the logical processor also adds (or subtracts) 
> value
>> X
>>     from the IA32_TSC_ADJUST MSR;
>> 3). If an execution of WRMSR to the IA32_TSC_ADJUST MSR adds (or subtracts)
>>     value X from that MSR, the logical processor also adds (or subtracts)
>> value X
>>     from the TSC;
>> 
>> With it, OS would be easier when sync tsc.
> 
> Actually it appears to strictly add code to, and hence complicate, the
> hypervisor. So how exactly is it beneficial?

It's beneficial to the guest if I'm not mistaken, for precisely the
purpose that patch 2 doesn't address for the hypervisor in spite
of its title (see my response there).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 20 08:37:55 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Sep 2012 08: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 1TEcGY-0002n7-Oq; Thu, 20 Sep 2012 08:37:46 +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 1TEcGX-0002mr-L5
	for xen-devel@lists.xensource.com; Thu, 20 Sep 2012 08:37:45 +0000
Received: from [85.158.139.83:18615] by server-4.bemta-5.messagelabs.com id
	4F/8B-23042-8D5DA505; Thu, 20 Sep 2012 08:37:44 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-8.tower-182.messagelabs.com!1348130264!17245984!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA1MDkwNzg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21046 invoked from network); 20 Sep 2012 08:37:44 -0000
Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25)
	by server-8.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 20 Sep 2012 08:37:44 -0000
X-Originating-Ip: [194.89.68.22]
Received: from ydin.reaktio.net (reaktio.net [194.89.68.22])
	by smtp.tele.fi (Postfix) with ESMTP id 66B6C271B;
	Thu, 20 Sep 2012 11:37:43 +0300 (EEST)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id EF2B82005D; Thu, 20 Sep 2012 11:37:42 +0300 (EEST)
Date: Thu, 20 Sep 2012 11:37:42 +0300
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: Lukas Laukamp <lukas@laukamp.me>
Message-ID: <20120920083742.GW8912@reaktio.net>
References: <c277ee4a34ca57f7da68f2e0ab832090@laukamp.me>
	<20120920073643.GU8912@reaktio.net>
	<bce40f714cae80dfd919b3d2c4e870e4@laukamp.me>
	<20120920075217.GV8912@reaktio.net>
	<7d9d2235fa5d81bf4bd8847b9ad89226@laukamp.me>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <7d9d2235fa5d81bf4bd8847b9ad89226@laukamp.me>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [User Question] KVM and VirtualBox in 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 Thu, Sep 20, 2012 at 10:03:43AM +0200, Lukas Laukamp wrote:
> >
> >I think it *might* be possible when Xen PVH (Hybrid) is merged to
> >Xen 4.3,
> >which basically allows running Xen dom0 in HVM container.
> >
> >-- Pasi
> 
> Hello,
> 
> I googled for xen Hybrid, but have question if I understand it
> correct. Now the Dom0 is a PV Guest.
>

Correct.

> With Xen Hybrid the Dom0 can run as a HVM with PV features on the hypervisor.
>

PVH dom0 is basicly PV dom0 in HVM container. It's more PV than HVM.

> This would make it possible because of nested virtualization that KVM and VirtualBox
> run inside dom0 right?
> 

Yes, but PVH doesn't enable nested virt automatically, that'll require some extra patches.

> And my second question would be: Is the aim of Xen hybrid to bring
> Dom0 support to more OSes?
> 

The purpose of PVH dom0 is to be able to utilize HAP (Hardware Assisted Paging) 
in dom0, and also lowering syscall overhead for 64bit dom0.

So it's about optimizations.
See Mukesh's presentation about PVH/Hybrid from XenSummit North America 2012.

-- Pasi


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 20 08:37:55 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Sep 2012 08: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 1TEcGY-0002n7-Oq; Thu, 20 Sep 2012 08:37:46 +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 1TEcGX-0002mr-L5
	for xen-devel@lists.xensource.com; Thu, 20 Sep 2012 08:37:45 +0000
Received: from [85.158.139.83:18615] by server-4.bemta-5.messagelabs.com id
	4F/8B-23042-8D5DA505; Thu, 20 Sep 2012 08:37:44 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-8.tower-182.messagelabs.com!1348130264!17245984!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA1MDkwNzg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21046 invoked from network); 20 Sep 2012 08:37:44 -0000
Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25)
	by server-8.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 20 Sep 2012 08:37:44 -0000
X-Originating-Ip: [194.89.68.22]
Received: from ydin.reaktio.net (reaktio.net [194.89.68.22])
	by smtp.tele.fi (Postfix) with ESMTP id 66B6C271B;
	Thu, 20 Sep 2012 11:37:43 +0300 (EEST)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id EF2B82005D; Thu, 20 Sep 2012 11:37:42 +0300 (EEST)
Date: Thu, 20 Sep 2012 11:37:42 +0300
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: Lukas Laukamp <lukas@laukamp.me>
Message-ID: <20120920083742.GW8912@reaktio.net>
References: <c277ee4a34ca57f7da68f2e0ab832090@laukamp.me>
	<20120920073643.GU8912@reaktio.net>
	<bce40f714cae80dfd919b3d2c4e870e4@laukamp.me>
	<20120920075217.GV8912@reaktio.net>
	<7d9d2235fa5d81bf4bd8847b9ad89226@laukamp.me>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <7d9d2235fa5d81bf4bd8847b9ad89226@laukamp.me>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [User Question] KVM and VirtualBox in 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 Thu, Sep 20, 2012 at 10:03:43AM +0200, Lukas Laukamp wrote:
> >
> >I think it *might* be possible when Xen PVH (Hybrid) is merged to
> >Xen 4.3,
> >which basically allows running Xen dom0 in HVM container.
> >
> >-- Pasi
> 
> Hello,
> 
> I googled for xen Hybrid, but have question if I understand it
> correct. Now the Dom0 is a PV Guest.
>

Correct.

> With Xen Hybrid the Dom0 can run as a HVM with PV features on the hypervisor.
>

PVH dom0 is basicly PV dom0 in HVM container. It's more PV than HVM.

> This would make it possible because of nested virtualization that KVM and VirtualBox
> run inside dom0 right?
> 

Yes, but PVH doesn't enable nested virt automatically, that'll require some extra patches.

> And my second question would be: Is the aim of Xen hybrid to bring
> Dom0 support to more OSes?
> 

The purpose of PVH dom0 is to be able to utilize HAP (Hardware Assisted Paging) 
in dom0, and also lowering syscall overhead for 64bit dom0.

So it's about optimizations.
See Mukesh's presentation about PVH/Hybrid from XenSummit North America 2012.

-- Pasi


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 20 08:47:33 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Sep 2012 08:47:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TEcPn-0003C5-2l; Thu, 20 Sep 2012 08:47:19 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <jinsong.liu@intel.com>) id 1TEcPl-0003C0-TR
	for xen-devel@lists.xen.org; Thu, 20 Sep 2012 08:47:18 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1348130828!8319774!1
X-Originating-IP: [143.182.124.37]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMzcgPT4gMjA1NDE5\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30490 invoked from network); 20 Sep 2012 08:47:09 -0000
Received: from mga14.intel.com (HELO mga14.intel.com) (143.182.124.37)
	by server-5.tower-27.messagelabs.com with SMTP;
	20 Sep 2012 08:47:09 -0000
Received: from azsmga002.ch.intel.com ([10.2.17.35])
	by azsmga102.ch.intel.com with ESMTP; 20 Sep 2012 01:47:08 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.80,453,1344236400"; d="scan'208";a="147072744"
Received: from fmsmsx105.amr.corp.intel.com ([10.19.9.36])
	by AZSMGA002.ch.intel.com with ESMTP; 20 Sep 2012 01:47:05 -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, 20 Sep 2012 01:47:05 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.239]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.175]) with mapi id
	14.01.0355.002; Thu, 20 Sep 2012 16:47:03 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: Jan Beulich <JBeulich@suse.com>
Thread-Topic: [PATCH 1/3] Expose tsc adjust to hvm guest
Thread-Index: AQHNlwkARakYZJF1QbObqbkdJQFFhpeS6scQ
Date: Thu, 20 Sep 2012 08:47:03 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC8292335331C0A@SHSMSX101.ccr.corp.intel.com>
References: <DE8DF0795D48FD4CA783C40EC8292335331A72@SHSMSX101.ccr.corp.intel.com>
	<505AEE46020000780009C885@nat28.tlf.novell.com>
In-Reply-To: <505AEE46020000780009C885@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>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 1/3] Expose tsc adjust to 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

Yep, last patch is better.

Thanks,
Jinsong

Jan Beulich wrote:
>>>> On 20.09.12 at 10:07, "Liu, Jinsong" <jinsong.liu@intel.com>
>>>> wrote: Expose tsc adjust to hvm guest 
>> 
>> Intel latest SDM (17.13.3) release a new MSR
>> CPUID.7.0.EBX[1]=1 indicates TSC_ADJUST MSR 0x3b is supported.
>> 
>> This patch expose it to hvm guest.
>> 
>> Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>
> 
> Shouldn't this be the last patch in the series, rather than the first
> one?
> 
> Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 20 08:47:33 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Sep 2012 08:47:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TEcPn-0003C5-2l; Thu, 20 Sep 2012 08:47:19 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <jinsong.liu@intel.com>) id 1TEcPl-0003C0-TR
	for xen-devel@lists.xen.org; Thu, 20 Sep 2012 08:47:18 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1348130828!8319774!1
X-Originating-IP: [143.182.124.37]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMzcgPT4gMjA1NDE5\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30490 invoked from network); 20 Sep 2012 08:47:09 -0000
Received: from mga14.intel.com (HELO mga14.intel.com) (143.182.124.37)
	by server-5.tower-27.messagelabs.com with SMTP;
	20 Sep 2012 08:47:09 -0000
Received: from azsmga002.ch.intel.com ([10.2.17.35])
	by azsmga102.ch.intel.com with ESMTP; 20 Sep 2012 01:47:08 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.80,453,1344236400"; d="scan'208";a="147072744"
Received: from fmsmsx105.amr.corp.intel.com ([10.19.9.36])
	by AZSMGA002.ch.intel.com with ESMTP; 20 Sep 2012 01:47:05 -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, 20 Sep 2012 01:47:05 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.239]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.175]) with mapi id
	14.01.0355.002; Thu, 20 Sep 2012 16:47:03 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: Jan Beulich <JBeulich@suse.com>
Thread-Topic: [PATCH 1/3] Expose tsc adjust to hvm guest
Thread-Index: AQHNlwkARakYZJF1QbObqbkdJQFFhpeS6scQ
Date: Thu, 20 Sep 2012 08:47:03 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC8292335331C0A@SHSMSX101.ccr.corp.intel.com>
References: <DE8DF0795D48FD4CA783C40EC8292335331A72@SHSMSX101.ccr.corp.intel.com>
	<505AEE46020000780009C885@nat28.tlf.novell.com>
In-Reply-To: <505AEE46020000780009C885@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>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 1/3] Expose tsc adjust to 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

Yep, last patch is better.

Thanks,
Jinsong

Jan Beulich wrote:
>>>> On 20.09.12 at 10:07, "Liu, Jinsong" <jinsong.liu@intel.com>
>>>> wrote: Expose tsc adjust to hvm guest 
>> 
>> Intel latest SDM (17.13.3) release a new MSR
>> CPUID.7.0.EBX[1]=1 indicates TSC_ADJUST MSR 0x3b is supported.
>> 
>> This patch expose it to hvm guest.
>> 
>> Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>
> 
> Shouldn't this be the last patch in the series, rather than the first
> one?
> 
> Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 20 08:50:52 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Sep 2012 08:50: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 1TEcT4-0003Jp-Mg; Thu, 20 Sep 2012 08:50:42 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <jinsong.liu@intel.com>) id 1TEcT3-0003JU-5o
	for xen-devel@lists.xen.org; Thu, 20 Sep 2012 08:50:41 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1348130910!4746092!1
X-Originating-IP: [192.55.52.88]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjg4ID0+IDMyMTcxMA==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21291 invoked from network); 20 Sep 2012 08:48:31 -0000
Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88)
	by server-15.tower-27.messagelabs.com with SMTP;
	20 Sep 2012 08:48:31 -0000
Received: from fmsmga002.fm.intel.com ([10.253.24.26])
	by fmsmga101.fm.intel.com with ESMTP; 20 Sep 2012 01:48:30 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.80,453,1344236400"; d="scan'208";a="224465079"
Received: from fmsmsx103.amr.corp.intel.com ([10.19.9.34])
	by fmsmga002.fm.intel.com with ESMTP; 20 Sep 2012 01:48:30 -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; Thu, 20 Sep 2012 01:48:29 -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; Thu, 20 Sep 2012 01:48:29 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.239]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.175]) with mapi id
	14.01.0355.002; Thu, 20 Sep 2012 16:48:26 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: Jan Beulich <JBeulich@suse.com>, Keir Fraser <keir@xen.org>
Thread-Topic: [Xen-devel] [PATCH 0/3] tsc adjust implementation for hvm
Thread-Index: AQHNlwtlVpsyDniHZEaRwosPbRL+3peS6wDw
Date: Thu, 20 Sep 2012 08:48:26 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC8292335331C15@SHSMSX101.ccr.corp.intel.com>
References: <DE8DF0795D48FD4CA783C40EC8292335331A65@SHSMSX101.ccr.corp.intel.com>
	<CC808F7A.4C812%keir@xen.org>
	<505AF1FD020000780009C893@nat28.tlf.novell.com>
In-Reply-To: <505AF1FD020000780009C893@nat28.tlf.novell.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 0/3] tsc adjust implementation for hvm
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Jan Beulich wrote:
>>>> On 20.09.12 at 10:16, Keir Fraser <keir@xen.org> wrote:
>> On 20/09/2012 09:06, "Liu, Jinsong" <jinsong.liu@intel.com> wrote:
>> 
>>> Intel recently release a new tsc adjust feature at latest SDM
>>> 17.13.3. CPUID.7.0.EBX[1]=1 indicates TSC_ADJUST MSR 0x3b is
>>> supported. 
>>> 
>>> Basically it is used to simplify TSC synchronization, operation of
>>> IA32_TSC_ADJUST MSR is as follows:
>>> 1). On RESET, the value of the IA32_TSC_ADJUST MSR is 0;
>>> 2). If an execution of WRMSR to the IA32_TIME_STAMP_COUNTER MSR
>>>     adds (or subtracts) value X from the TSC, the logical processor
>>>     also adds (or subtracts) value X from the IA32_TSC_ADJUST MSR;
>>> 3). If an execution of WRMSR to the IA32_TSC_ADJUST MSR adds (or
>>>     subtracts) value X from that MSR, the logical processor also
>>>     adds (or subtracts) value X from the TSC;
>>> 
>>> With it, OS would be easier when sync tsc.
>> 
>> Actually it appears to strictly add code to, and hence complicate,
>> the hypervisor. So how exactly is it beneficial?
> 
> It's beneficial to the guest if I'm not mistaken, for precisely the
> purpose that patch 2 doesn't address for the hypervisor in spite
> of its title (see my response there).
> 
> Jan

Yes, updated accordingly w/ more clear comments and would send 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 Sep 20 08:50:52 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Sep 2012 08:50: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 1TEcT4-0003Jp-Mg; Thu, 20 Sep 2012 08:50:42 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <jinsong.liu@intel.com>) id 1TEcT3-0003JU-5o
	for xen-devel@lists.xen.org; Thu, 20 Sep 2012 08:50:41 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1348130910!4746092!1
X-Originating-IP: [192.55.52.88]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjg4ID0+IDMyMTcxMA==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21291 invoked from network); 20 Sep 2012 08:48:31 -0000
Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88)
	by server-15.tower-27.messagelabs.com with SMTP;
	20 Sep 2012 08:48:31 -0000
Received: from fmsmga002.fm.intel.com ([10.253.24.26])
	by fmsmga101.fm.intel.com with ESMTP; 20 Sep 2012 01:48:30 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.80,453,1344236400"; d="scan'208";a="224465079"
Received: from fmsmsx103.amr.corp.intel.com ([10.19.9.34])
	by fmsmga002.fm.intel.com with ESMTP; 20 Sep 2012 01:48:30 -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; Thu, 20 Sep 2012 01:48:29 -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; Thu, 20 Sep 2012 01:48:29 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.239]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.175]) with mapi id
	14.01.0355.002; Thu, 20 Sep 2012 16:48:26 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: Jan Beulich <JBeulich@suse.com>, Keir Fraser <keir@xen.org>
Thread-Topic: [Xen-devel] [PATCH 0/3] tsc adjust implementation for hvm
Thread-Index: AQHNlwtlVpsyDniHZEaRwosPbRL+3peS6wDw
Date: Thu, 20 Sep 2012 08:48:26 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC8292335331C15@SHSMSX101.ccr.corp.intel.com>
References: <DE8DF0795D48FD4CA783C40EC8292335331A65@SHSMSX101.ccr.corp.intel.com>
	<CC808F7A.4C812%keir@xen.org>
	<505AF1FD020000780009C893@nat28.tlf.novell.com>
In-Reply-To: <505AF1FD020000780009C893@nat28.tlf.novell.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 0/3] tsc adjust implementation for hvm
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Jan Beulich wrote:
>>>> On 20.09.12 at 10:16, Keir Fraser <keir@xen.org> wrote:
>> On 20/09/2012 09:06, "Liu, Jinsong" <jinsong.liu@intel.com> wrote:
>> 
>>> Intel recently release a new tsc adjust feature at latest SDM
>>> 17.13.3. CPUID.7.0.EBX[1]=1 indicates TSC_ADJUST MSR 0x3b is
>>> supported. 
>>> 
>>> Basically it is used to simplify TSC synchronization, operation of
>>> IA32_TSC_ADJUST MSR is as follows:
>>> 1). On RESET, the value of the IA32_TSC_ADJUST MSR is 0;
>>> 2). If an execution of WRMSR to the IA32_TIME_STAMP_COUNTER MSR
>>>     adds (or subtracts) value X from the TSC, the logical processor
>>>     also adds (or subtracts) value X from the IA32_TSC_ADJUST MSR;
>>> 3). If an execution of WRMSR to the IA32_TSC_ADJUST MSR adds (or
>>>     subtracts) value X from that MSR, the logical processor also
>>>     adds (or subtracts) value X from the TSC;
>>> 
>>> With it, OS would be easier when sync tsc.
>> 
>> Actually it appears to strictly add code to, and hence complicate,
>> the hypervisor. So how exactly is it beneficial?
> 
> It's beneficial to the guest if I'm not mistaken, for precisely the
> purpose that patch 2 doesn't address for the hypervisor in spite
> of its title (see my response there).
> 
> Jan

Yes, updated accordingly w/ more clear comments and would send 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 Sep 20 08:52:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Sep 2012 08:52:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TEcUO-0003Pi-6z; Thu, 20 Sep 2012 08:52:04 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <oliver.chick@citrix.com>) id 1TEcUN-0003Pb-38
	for xen-devel@lists.xen.org; Thu, 20 Sep 2012 08:52:03 +0000
Received: from [85.158.143.99:6205] by server-1.bemta-4.messagelabs.com id
	BC/0E-05684-239DA505; Thu, 20 Sep 2012 08:52:02 +0000
X-Env-Sender: oliver.chick@citrix.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1348131115!19853456!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTAzMDk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2984 invoked from network); 20 Sep 2012 08:52:01 -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;
	20 Sep 2012 08:52:01 -0000
X-IronPort-AV: E=Sophos;i="4.80,453,1344211200"; d="scan'208";a="14648494"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Sep 2012 08:51:55 +0000
Received: from [10.80.2.50] (10.80.2.50) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Thu, 20 Sep 2012 09:51:55 +0100
Message-ID: <1348131088.24539.2.camel@oliverchick-Precision-WorkStation-T3400>
From: Oliver Chick <oliver.chick@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Thu, 20 Sep 2012 09:51:28 +0100
In-Reply-To: <5059D0C8020000780009C4CF@nat28.tlf.novell.com>
References: <1348051887-21885-1-git-send-email-oliver.chick@citrix.com>
	<5059D0C8020000780009C4CF@nat28.tlf.novell.com>
X-Mailer: Evolution 3.2.3-0ubuntu6 
MIME-Version: 1.0
Cc: "konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] Persistent grant maps for xen blk drivers
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ah yes, you're right - rings can accomodate 64 requests. ijc, and myself
got muddled. It also explains the comment in my summary that we only use
the first 60-ish persistent grants!

With multipage rings, this will probably become a function, rather than
a constant. Does that sound sensible?

On Wed, 2012-09-19 at 13:03 +0100, Jan Beulich wrote:
> >>> On 19.09.12 at 12:51, Oliver Chick <oliver.chick@citrix.com> wrote:
> > +/*
> > + * Maximum number of persistent grants that can be mapped by Dom0 for each
> > + * interface. This is set to be the size of the ring, as this is a limit on
> > + * the number of requests that can be inflight at any one time. 256 imposes
> > + * an overhead of 11MB of mapped kernel space per interface.
> > + */
> > +#define BLKIF_MAX_PERS_REQUESTS_PER_DEV 256
> 
> How can this be a fixed number, especially in the context of ring
> size extensions? Iirc, single page rings can accommodate 64
> requests, so I'd guess the number above was observed with a
> 4-page (order 2) ring...
> 
> Jan
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 20 08:52:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Sep 2012 08:52:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TEcUO-0003Pi-6z; Thu, 20 Sep 2012 08:52:04 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <oliver.chick@citrix.com>) id 1TEcUN-0003Pb-38
	for xen-devel@lists.xen.org; Thu, 20 Sep 2012 08:52:03 +0000
Received: from [85.158.143.99:6205] by server-1.bemta-4.messagelabs.com id
	BC/0E-05684-239DA505; Thu, 20 Sep 2012 08:52:02 +0000
X-Env-Sender: oliver.chick@citrix.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1348131115!19853456!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTAzMDk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2984 invoked from network); 20 Sep 2012 08:52:01 -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;
	20 Sep 2012 08:52:01 -0000
X-IronPort-AV: E=Sophos;i="4.80,453,1344211200"; d="scan'208";a="14648494"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Sep 2012 08:51:55 +0000
Received: from [10.80.2.50] (10.80.2.50) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Thu, 20 Sep 2012 09:51:55 +0100
Message-ID: <1348131088.24539.2.camel@oliverchick-Precision-WorkStation-T3400>
From: Oliver Chick <oliver.chick@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Thu, 20 Sep 2012 09:51:28 +0100
In-Reply-To: <5059D0C8020000780009C4CF@nat28.tlf.novell.com>
References: <1348051887-21885-1-git-send-email-oliver.chick@citrix.com>
	<5059D0C8020000780009C4CF@nat28.tlf.novell.com>
X-Mailer: Evolution 3.2.3-0ubuntu6 
MIME-Version: 1.0
Cc: "konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] Persistent grant maps for xen blk drivers
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ah yes, you're right - rings can accomodate 64 requests. ijc, and myself
got muddled. It also explains the comment in my summary that we only use
the first 60-ish persistent grants!

With multipage rings, this will probably become a function, rather than
a constant. Does that sound sensible?

On Wed, 2012-09-19 at 13:03 +0100, Jan Beulich wrote:
> >>> On 19.09.12 at 12:51, Oliver Chick <oliver.chick@citrix.com> wrote:
> > +/*
> > + * Maximum number of persistent grants that can be mapped by Dom0 for each
> > + * interface. This is set to be the size of the ring, as this is a limit on
> > + * the number of requests that can be inflight at any one time. 256 imposes
> > + * an overhead of 11MB of mapped kernel space per interface.
> > + */
> > +#define BLKIF_MAX_PERS_REQUESTS_PER_DEV 256
> 
> How can this be a fixed number, especially in the context of ring
> size extensions? Iirc, single page rings can accommodate 64
> requests, so I'd guess the number above was observed with a
> 4-page (order 2) ring...
> 
> Jan
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 20 08:54:25 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Sep 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 1TEcWU-0003Z6-O6; Thu, 20 Sep 2012 08:54:14 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <jinsong.liu@intel.com>) id 1TEcWT-0003Yj-JD
	for xen-devel@lists.xensource.com; Thu, 20 Sep 2012 08:54:13 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1348131239!9747618!1
X-Originating-IP: [134.134.136.24]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjQgPT4gMzQ0ODU0\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27687 invoked from network); 20 Sep 2012 08:54:00 -0000
Received: from mga09.intel.com (HELO mga09.intel.com) (134.134.136.24)
	by server-3.tower-27.messagelabs.com with SMTP;
	20 Sep 2012 08:54:00 -0000
Received: from orsmga001.jf.intel.com ([10.7.209.18])
	by orsmga102.jf.intel.com with ESMTP; 20 Sep 2012 01:53:34 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.80,453,1344236400"; d="scan'208";a="195216857"
Received: from fmsmsx107.amr.corp.intel.com ([10.19.9.54])
	by orsmga001.jf.intel.com with ESMTP; 20 Sep 2012 01:53:46 -0700
Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by
	FMSMSX107.amr.corp.intel.com (10.19.9.54) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Thu, 20 Sep 2012 01:53:46 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.239]) by
	SHSMSX102.ccr.corp.intel.com ([169.254.2.92]) with mapi id
	14.01.0355.002; Thu, 20 Sep 2012 16:53:44 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: Jan Beulich <JBeulich@suse.com>, Keir Fraser <keir@xen.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Thread-Topic: [PATCH 0/3] tsc adjust support for hvm guest
Thread-Index: Ac2XDW7LWn065GZ8QuKZOca8i+wZKQ==
Date: Thu, 20 Sep 2012 08:53:44 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC8292335331C38@SHSMSX101.ccr.corp.intel.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Subject: [Xen-devel] [PATCH 0/3] tsc adjust support for 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

Intel recently release a new tsc adjust feature at latest SDM 17.13.3.
CPUID.7.0.EBX[1]=1 indicates TSC_ADJUST MSR 0x3b is supported.

Basically it is used to simplify TSC synchronization, operation of IA32_TSC_ADJUST MSR is as follows:
1). On RESET, the value of the IA32_TSC_ADJUST MSR is 0;
2). If an execution of WRMSR to the IA32_TIME_STAMP_COUNTER MSR adds (or subtracts)
    value X from the TSC, the logical processor also adds (or subtracts) value X
    from the IA32_TSC_ADJUST MSR;
3). If an execution of WRMSR to the IA32_TSC_ADJUST MSR adds (or subtracts)
    value X from that MSR, the logical processor also adds (or subtracts) value X
    from the TSC;

This patch provides tsc adjust support for hvm guest, with it hvm guest would be happy when sync tsc.

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 Sep 20 08:54:25 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Sep 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 1TEcWU-0003Z6-O6; Thu, 20 Sep 2012 08:54:14 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <jinsong.liu@intel.com>) id 1TEcWT-0003Yj-JD
	for xen-devel@lists.xensource.com; Thu, 20 Sep 2012 08:54:13 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1348131239!9747618!1
X-Originating-IP: [134.134.136.24]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjQgPT4gMzQ0ODU0\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27687 invoked from network); 20 Sep 2012 08:54:00 -0000
Received: from mga09.intel.com (HELO mga09.intel.com) (134.134.136.24)
	by server-3.tower-27.messagelabs.com with SMTP;
	20 Sep 2012 08:54:00 -0000
Received: from orsmga001.jf.intel.com ([10.7.209.18])
	by orsmga102.jf.intel.com with ESMTP; 20 Sep 2012 01:53:34 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.80,453,1344236400"; d="scan'208";a="195216857"
Received: from fmsmsx107.amr.corp.intel.com ([10.19.9.54])
	by orsmga001.jf.intel.com with ESMTP; 20 Sep 2012 01:53:46 -0700
Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by
	FMSMSX107.amr.corp.intel.com (10.19.9.54) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Thu, 20 Sep 2012 01:53:46 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.239]) by
	SHSMSX102.ccr.corp.intel.com ([169.254.2.92]) with mapi id
	14.01.0355.002; Thu, 20 Sep 2012 16:53:44 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: Jan Beulich <JBeulich@suse.com>, Keir Fraser <keir@xen.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Thread-Topic: [PATCH 0/3] tsc adjust support for hvm guest
Thread-Index: Ac2XDW7LWn065GZ8QuKZOca8i+wZKQ==
Date: Thu, 20 Sep 2012 08:53:44 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC8292335331C38@SHSMSX101.ccr.corp.intel.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Subject: [Xen-devel] [PATCH 0/3] tsc adjust support for 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

Intel recently release a new tsc adjust feature at latest SDM 17.13.3.
CPUID.7.0.EBX[1]=1 indicates TSC_ADJUST MSR 0x3b is supported.

Basically it is used to simplify TSC synchronization, operation of IA32_TSC_ADJUST MSR is as follows:
1). On RESET, the value of the IA32_TSC_ADJUST MSR is 0;
2). If an execution of WRMSR to the IA32_TIME_STAMP_COUNTER MSR adds (or subtracts)
    value X from the TSC, the logical processor also adds (or subtracts) value X
    from the IA32_TSC_ADJUST MSR;
3). If an execution of WRMSR to the IA32_TSC_ADJUST MSR adds (or subtracts)
    value X from that MSR, the logical processor also adds (or subtracts) value X
    from the TSC;

This patch provides tsc adjust support for hvm guest, with it hvm guest would be happy when sync tsc.

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 Sep 20 08:56:34 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Sep 2012 08:56: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 1TEcYY-0003io-GG; Thu, 20 Sep 2012 08:56: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 1TEcYW-0003if-Bo
	for xen-devel@lists.xensource.com; Thu, 20 Sep 2012 08:56:20 +0000
Received: from [85.158.138.51:60207] by server-11.bemta-3.messagelabs.com id
	30/30-30250-33ADA505; Thu, 20 Sep 2012 08:56:19 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1348131377!23208700!1
X-Originating-IP: [192.55.52.93]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjkzID0+IDM0NDk3Mw==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16176 invoked from network); 20 Sep 2012 08:56:18 -0000
Received: from mga11.intel.com (HELO mga11.intel.com) (192.55.52.93)
	by server-3.tower-174.messagelabs.com with SMTP;
	20 Sep 2012 08:56:18 -0000
Received: from fmsmga002.fm.intel.com ([10.253.24.26])
	by fmsmga102.fm.intel.com with ESMTP; 20 Sep 2012 01:56:04 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.80,453,1344236400"; d="scan'208";a="224467427"
Received: from fmsmsx103.amr.corp.intel.com ([10.19.9.34])
	by fmsmga002.fm.intel.com with ESMTP; 20 Sep 2012 01:56:04 -0700
Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by
	FMSMSX103.amr.corp.intel.com (10.19.9.34) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Thu, 20 Sep 2012 01:56:03 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.239]) by
	SHSMSX102.ccr.corp.intel.com ([169.254.2.92]) with mapi id
	14.01.0355.002; Thu, 20 Sep 2012 16:56:02 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: Jan Beulich <JBeulich@suse.com>, Keir Fraser <keir@xen.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Thread-Topic: [PATCH 1/3] Implement tsc adjust feature for hvm guest
Thread-Index: Ac2XDcENCZMFyx5JS3CH2UElyxcsVA==
Date: Thu, 20 Sep 2012 08:56:01 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC8292335331C56@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_DE8DF0795D48FD4CA783C40EC8292335331C56SHSMSX101ccrcorpi_"
MIME-Version: 1.0
Subject: [Xen-devel] [PATCH 1/3] Implement tsc adjust feature for 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_DE8DF0795D48FD4CA783C40EC8292335331C56SHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Implement tsc adjust feature for hvm guest

IA32_TSC_ADJUST MSR is maintained separately for each logical processor.
A logical processor maintains and uses the IA32_TSC_ADJUST MSR as follows:
1). On RESET, the value of the IA32_TSC_ADJUST MSR is 0;
2). If an execution of WRMSR to the IA32_TIME_STAMP_COUNTER MSR adds (or su=
btracts)
    value X from the TSC, the logical processor also adds (or subtracts) va=
lue X
    from the IA32_TSC_ADJUST MSR;
3). If an execution of WRMSR to the IA32_TSC_ADJUST MSR adds (or subtracts)
    value X from that MSR, the logical processor also adds (or subtracts) v=
alue X
    from the TSC;

This patch provides tsc adjust support for hvm guest, with it guest OS woul=
d be happy when sync tsc.

Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>

diff -r d5c677159abb xen/arch/x86/hvm/hvm.c
--- a/xen/arch/x86/hvm/hvm.c	Thu Sep 20 21:50:56 2012 +0800
+++ b/xen/arch/x86/hvm/hvm.c	Thu Sep 20 23:34:04 2012 +0800
@@ -244,6 +244,7 @@
 void hvm_set_guest_tsc(struct vcpu *v, u64 guest_tsc)
 {
     uint64_t tsc;
+    uint64_t delta_tsc;
=20
     if ( v->domain->arch.vtsc )
     {
@@ -255,10 +256,23 @@
         rdtscll(tsc);
     }
=20
-    v->arch.hvm_vcpu.cache_tsc_offset =3D guest_tsc - tsc;
+    delta_tsc =3D guest_tsc - tsc;
+
+    v->arch.hvm_vcpu.msr_tsc_adjust +=3D delta_tsc
+                          - v->arch.hvm_vcpu.cache_tsc_offset;
+    v->arch.hvm_vcpu.cache_tsc_offset =3D delta_tsc;
+
     hvm_funcs.set_tsc_offset(v, v->arch.hvm_vcpu.cache_tsc_offset);
 }
=20
+void hvm_set_guest_tsc_adjust(struct vcpu *v, u64 tsc_adjust)
+{
+    v->arch.hvm_vcpu.cache_tsc_offset +=3D tsc_adjust
+                            - v->arch.hvm_vcpu.msr_tsc_adjust;
+    hvm_funcs.set_tsc_offset(v, v->arch.hvm_vcpu.cache_tsc_offset);
+    v->arch.hvm_vcpu.msr_tsc_adjust =3D tsc_adjust;
+}
+
 u64 hvm_get_guest_tsc(struct vcpu *v)
 {
     uint64_t tsc;
@@ -277,6 +291,11 @@
     return tsc + v->arch.hvm_vcpu.cache_tsc_offset;
 }
=20
+u64 hvm_get_guest_tsc_adjust(struct vcpu *v)
+{
+    return v->arch.hvm_vcpu.msr_tsc_adjust;
+}
+
 void hvm_migrate_timers(struct vcpu *v)
 {
     rtc_migrate_timers(v);
@@ -2776,6 +2795,10 @@
         *msr_content =3D hvm_get_guest_tsc(v);
         break;
=20
+    case MSR_IA32_TSC_ADJUST:
+        *msr_content =3D hvm_get_guest_tsc_adjust(v);
+        break;
+
     case MSR_TSC_AUX:
         *msr_content =3D hvm_msr_tsc_aux(v);
         break;
@@ -2889,6 +2912,10 @@
         hvm_set_guest_tsc(v, msr_content);
         break;
=20
+    case MSR_IA32_TSC_ADJUST:
+        hvm_set_guest_tsc_adjust(v, msr_content);
+        break;
+
     case MSR_TSC_AUX:
         v->arch.hvm_vcpu.msr_tsc_aux =3D (uint32_t)msr_content;
         if ( cpu_has_rdtscp
@@ -3436,6 +3463,8 @@
         v->domain->vcpu[0]->arch.hvm_vcpu.cache_tsc_offset;
     hvm_funcs.set_tsc_offset(v, v->arch.hvm_vcpu.cache_tsc_offset);
=20
+    v->arch.hvm_vcpu.msr_tsc_adjust =3D 0;
+
     paging_update_paging_modes(v);
=20
     v->arch.flags |=3D TF_kernel_mode;
diff -r d5c677159abb xen/include/asm-x86/hvm/vcpu.h
--- a/xen/include/asm-x86/hvm/vcpu.h	Thu Sep 20 21:50:56 2012 +0800
+++ b/xen/include/asm-x86/hvm/vcpu.h	Thu Sep 20 23:34:04 2012 +0800
@@ -137,6 +137,7 @@
     struct hvm_vcpu_asid n1asid;
=20
     u32                 msr_tsc_aux;
+    u64                 msr_tsc_adjust;
=20
     /* VPMU */
     struct vpmu_struct  vpmu;
diff -r d5c677159abb xen/include/asm-x86/msr-index.h
--- a/xen/include/asm-x86/msr-index.h	Thu Sep 20 21:50:56 2012 +0800
+++ b/xen/include/asm-x86/msr-index.h	Thu Sep 20 23:34:04 2012 +0800
@@ -284,6 +284,7 @@
 #define MSR_IA32_PLATFORM_ID		0x00000017
 #define MSR_IA32_EBL_CR_POWERON		0x0000002a
 #define MSR_IA32_EBC_FREQUENCY_ID	0x0000002c
+#define MSR_IA32_TSC_ADJUST		0x0000003b
=20
 #define MSR_IA32_APICBASE		0x0000001b
 #define MSR_IA32_APICBASE_BSP		(1<<8)=

--_002_DE8DF0795D48FD4CA783C40EC8292335331C56SHSMSX101ccrcorpi_
Content-Type: application/octet-stream; name="tsc_adjust_1.patch"
Content-Description: tsc_adjust_1.patch
Content-Disposition: attachment; filename="tsc_adjust_1.patch"; size=3800;
	creation-date="Thu, 20 Sep 2012 08:50:31 GMT";
	modification-date="Thu, 20 Sep 2012 16:39:00 GMT"
Content-Transfer-Encoding: base64

SW1wbGVtZW50IHRzYyBhZGp1c3QgZmVhdHVyZSBmb3IgaHZtIGd1ZXN0CgpJQTMyX1RTQ19BREpV
U1QgTVNSIGlzIG1haW50YWluZWQgc2VwYXJhdGVseSBmb3IgZWFjaCBsb2dpY2FsIHByb2Nlc3Nv
ci4KQSBsb2dpY2FsIHByb2Nlc3NvciBtYWludGFpbnMgYW5kIHVzZXMgdGhlIElBMzJfVFNDX0FE
SlVTVCBNU1IgYXMgZm9sbG93czoKMSkuIE9uIFJFU0VULCB0aGUgdmFsdWUgb2YgdGhlIElBMzJf
VFNDX0FESlVTVCBNU1IgaXMgMDsKMikuIElmIGFuIGV4ZWN1dGlvbiBvZiBXUk1TUiB0byB0aGUg
SUEzMl9USU1FX1NUQU1QX0NPVU5URVIgTVNSIGFkZHMgKG9yIHN1YnRyYWN0cykKICAgIHZhbHVl
IFggZnJvbSB0aGUgVFNDLCB0aGUgbG9naWNhbCBwcm9jZXNzb3IgYWxzbyBhZGRzIChvciBzdWJ0
cmFjdHMpIHZhbHVlIFgKICAgIGZyb20gdGhlIElBMzJfVFNDX0FESlVTVCBNU1I7CjMpLiBJZiBh
biBleGVjdXRpb24gb2YgV1JNU1IgdG8gdGhlIElBMzJfVFNDX0FESlVTVCBNU1IgYWRkcyAob3Ig
c3VidHJhY3RzKQogICAgdmFsdWUgWCBmcm9tIHRoYXQgTVNSLCB0aGUgbG9naWNhbCBwcm9jZXNz
b3IgYWxzbyBhZGRzIChvciBzdWJ0cmFjdHMpIHZhbHVlIFgKICAgIGZyb20gdGhlIFRTQzsKClRo
aXMgcGF0Y2ggcHJvdmlkZXMgdHNjIGFkanVzdCBzdXBwb3J0IGZvciBodm0gZ3Vlc3QsIHdpdGgg
aXQgZ3Vlc3QgT1Mgd291bGQgYmUgaGFwcHkgd2hlbiBzeW5jIHRzYy4KClNpZ25lZC1vZmYtYnk6
IExpdSwgSmluc29uZyA8amluc29uZy5saXVAaW50ZWwuY29tPgoKZGlmZiAtciBkNWM2NzcxNTlh
YmIgeGVuL2FyY2gveDg2L2h2bS9odm0uYwotLS0gYS94ZW4vYXJjaC94ODYvaHZtL2h2bS5jCVRo
dSBTZXAgMjAgMjE6NTA6NTYgMjAxMiArMDgwMAorKysgYi94ZW4vYXJjaC94ODYvaHZtL2h2bS5j
CVRodSBTZXAgMjAgMjM6MzQ6MDQgMjAxMiArMDgwMApAQCAtMjQ0LDYgKzI0NCw3IEBACiB2b2lk
IGh2bV9zZXRfZ3Vlc3RfdHNjKHN0cnVjdCB2Y3B1ICp2LCB1NjQgZ3Vlc3RfdHNjKQogewogICAg
IHVpbnQ2NF90IHRzYzsKKyAgICB1aW50NjRfdCBkZWx0YV90c2M7CiAKICAgICBpZiAoIHYtPmRv
bWFpbi0+YXJjaC52dHNjICkKICAgICB7CkBAIC0yNTUsMTAgKzI1NiwyMyBAQAogICAgICAgICBy
ZHRzY2xsKHRzYyk7CiAgICAgfQogCi0gICAgdi0+YXJjaC5odm1fdmNwdS5jYWNoZV90c2Nfb2Zm
c2V0ID0gZ3Vlc3RfdHNjIC0gdHNjOworICAgIGRlbHRhX3RzYyA9IGd1ZXN0X3RzYyAtIHRzYzsK
KworICAgIHYtPmFyY2guaHZtX3ZjcHUubXNyX3RzY19hZGp1c3QgKz0gZGVsdGFfdHNjCisgICAg
ICAgICAgICAgICAgICAgICAgICAgIC0gdi0+YXJjaC5odm1fdmNwdS5jYWNoZV90c2Nfb2Zmc2V0
OworICAgIHYtPmFyY2guaHZtX3ZjcHUuY2FjaGVfdHNjX29mZnNldCA9IGRlbHRhX3RzYzsKKwog
ICAgIGh2bV9mdW5jcy5zZXRfdHNjX29mZnNldCh2LCB2LT5hcmNoLmh2bV92Y3B1LmNhY2hlX3Rz
Y19vZmZzZXQpOwogfQogCit2b2lkIGh2bV9zZXRfZ3Vlc3RfdHNjX2FkanVzdChzdHJ1Y3QgdmNw
dSAqdiwgdTY0IHRzY19hZGp1c3QpCit7CisgICAgdi0+YXJjaC5odm1fdmNwdS5jYWNoZV90c2Nf
b2Zmc2V0ICs9IHRzY19hZGp1c3QKKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAtIHYtPmFy
Y2guaHZtX3ZjcHUubXNyX3RzY19hZGp1c3Q7CisgICAgaHZtX2Z1bmNzLnNldF90c2Nfb2Zmc2V0
KHYsIHYtPmFyY2guaHZtX3ZjcHUuY2FjaGVfdHNjX29mZnNldCk7CisgICAgdi0+YXJjaC5odm1f
dmNwdS5tc3JfdHNjX2FkanVzdCA9IHRzY19hZGp1c3Q7Cit9CisKIHU2NCBodm1fZ2V0X2d1ZXN0
X3RzYyhzdHJ1Y3QgdmNwdSAqdikKIHsKICAgICB1aW50NjRfdCB0c2M7CkBAIC0yNzcsNiArMjkx
LDExIEBACiAgICAgcmV0dXJuIHRzYyArIHYtPmFyY2guaHZtX3ZjcHUuY2FjaGVfdHNjX29mZnNl
dDsKIH0KIAordTY0IGh2bV9nZXRfZ3Vlc3RfdHNjX2FkanVzdChzdHJ1Y3QgdmNwdSAqdikKK3sK
KyAgICByZXR1cm4gdi0+YXJjaC5odm1fdmNwdS5tc3JfdHNjX2FkanVzdDsKK30KKwogdm9pZCBo
dm1fbWlncmF0ZV90aW1lcnMoc3RydWN0IHZjcHUgKnYpCiB7CiAgICAgcnRjX21pZ3JhdGVfdGlt
ZXJzKHYpOwpAQCAtMjc3Niw2ICsyNzk1LDEwIEBACiAgICAgICAgICptc3JfY29udGVudCA9IGh2
bV9nZXRfZ3Vlc3RfdHNjKHYpOwogICAgICAgICBicmVhazsKIAorICAgIGNhc2UgTVNSX0lBMzJf
VFNDX0FESlVTVDoKKyAgICAgICAgKm1zcl9jb250ZW50ID0gaHZtX2dldF9ndWVzdF90c2NfYWRq
dXN0KHYpOworICAgICAgICBicmVhazsKKwogICAgIGNhc2UgTVNSX1RTQ19BVVg6CiAgICAgICAg
ICptc3JfY29udGVudCA9IGh2bV9tc3JfdHNjX2F1eCh2KTsKICAgICAgICAgYnJlYWs7CkBAIC0y
ODg5LDYgKzI5MTIsMTAgQEAKICAgICAgICAgaHZtX3NldF9ndWVzdF90c2ModiwgbXNyX2NvbnRl
bnQpOwogICAgICAgICBicmVhazsKIAorICAgIGNhc2UgTVNSX0lBMzJfVFNDX0FESlVTVDoKKyAg
ICAgICAgaHZtX3NldF9ndWVzdF90c2NfYWRqdXN0KHYsIG1zcl9jb250ZW50KTsKKyAgICAgICAg
YnJlYWs7CisKICAgICBjYXNlIE1TUl9UU0NfQVVYOgogICAgICAgICB2LT5hcmNoLmh2bV92Y3B1
Lm1zcl90c2NfYXV4ID0gKHVpbnQzMl90KW1zcl9jb250ZW50OwogICAgICAgICBpZiAoIGNwdV9o
YXNfcmR0c2NwCkBAIC0zNDM2LDYgKzM0NjMsOCBAQAogICAgICAgICB2LT5kb21haW4tPnZjcHVb
MF0tPmFyY2guaHZtX3ZjcHUuY2FjaGVfdHNjX29mZnNldDsKICAgICBodm1fZnVuY3Muc2V0X3Rz
Y19vZmZzZXQodiwgdi0+YXJjaC5odm1fdmNwdS5jYWNoZV90c2Nfb2Zmc2V0KTsKIAorICAgIHYt
PmFyY2guaHZtX3ZjcHUubXNyX3RzY19hZGp1c3QgPSAwOworCiAgICAgcGFnaW5nX3VwZGF0ZV9w
YWdpbmdfbW9kZXModik7CiAKICAgICB2LT5hcmNoLmZsYWdzIHw9IFRGX2tlcm5lbF9tb2RlOwpk
aWZmIC1yIGQ1YzY3NzE1OWFiYiB4ZW4vaW5jbHVkZS9hc20teDg2L2h2bS92Y3B1LmgKLS0tIGEv
eGVuL2luY2x1ZGUvYXNtLXg4Ni9odm0vdmNwdS5oCVRodSBTZXAgMjAgMjE6NTA6NTYgMjAxMiAr
MDgwMAorKysgYi94ZW4vaW5jbHVkZS9hc20teDg2L2h2bS92Y3B1LmgJVGh1IFNlcCAyMCAyMzoz
NDowNCAyMDEyICswODAwCkBAIC0xMzcsNiArMTM3LDcgQEAKICAgICBzdHJ1Y3QgaHZtX3ZjcHVf
YXNpZCBuMWFzaWQ7CiAKICAgICB1MzIgICAgICAgICAgICAgICAgIG1zcl90c2NfYXV4OworICAg
IHU2NCAgICAgICAgICAgICAgICAgbXNyX3RzY19hZGp1c3Q7CiAKICAgICAvKiBWUE1VICovCiAg
ICAgc3RydWN0IHZwbXVfc3RydWN0ICB2cG11OwpkaWZmIC1yIGQ1YzY3NzE1OWFiYiB4ZW4vaW5j
bHVkZS9hc20teDg2L21zci1pbmRleC5oCi0tLSBhL3hlbi9pbmNsdWRlL2FzbS14ODYvbXNyLWlu
ZGV4LmgJVGh1IFNlcCAyMCAyMTo1MDo1NiAyMDEyICswODAwCisrKyBiL3hlbi9pbmNsdWRlL2Fz
bS14ODYvbXNyLWluZGV4LmgJVGh1IFNlcCAyMCAyMzozNDowNCAyMDEyICswODAwCkBAIC0yODQs
NiArMjg0LDcgQEAKICNkZWZpbmUgTVNSX0lBMzJfUExBVEZPUk1fSUQJCTB4MDAwMDAwMTcKICNk
ZWZpbmUgTVNSX0lBMzJfRUJMX0NSX1BPV0VST04JCTB4MDAwMDAwMmEKICNkZWZpbmUgTVNSX0lB
MzJfRUJDX0ZSRVFVRU5DWV9JRAkweDAwMDAwMDJjCisjZGVmaW5lIE1TUl9JQTMyX1RTQ19BREpV
U1QJCTB4MDAwMDAwM2IKIAogI2RlZmluZSBNU1JfSUEzMl9BUElDQkFTRQkJMHgwMDAwMDAxYgog
I2RlZmluZSBNU1JfSUEzMl9BUElDQkFTRV9CU1AJCSgxPDw4KQo=

--_002_DE8DF0795D48FD4CA783C40EC8292335331C56SHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 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_DE8DF0795D48FD4CA783C40EC8292335331C56SHSMSX101ccrcorpi_--


From xen-devel-bounces@lists.xen.org Thu Sep 20 08:56:34 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Sep 2012 08:56: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 1TEcYY-0003io-GG; Thu, 20 Sep 2012 08:56: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 1TEcYW-0003if-Bo
	for xen-devel@lists.xensource.com; Thu, 20 Sep 2012 08:56:20 +0000
Received: from [85.158.138.51:60207] by server-11.bemta-3.messagelabs.com id
	30/30-30250-33ADA505; Thu, 20 Sep 2012 08:56:19 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1348131377!23208700!1
X-Originating-IP: [192.55.52.93]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjkzID0+IDM0NDk3Mw==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16176 invoked from network); 20 Sep 2012 08:56:18 -0000
Received: from mga11.intel.com (HELO mga11.intel.com) (192.55.52.93)
	by server-3.tower-174.messagelabs.com with SMTP;
	20 Sep 2012 08:56:18 -0000
Received: from fmsmga002.fm.intel.com ([10.253.24.26])
	by fmsmga102.fm.intel.com with ESMTP; 20 Sep 2012 01:56:04 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.80,453,1344236400"; d="scan'208";a="224467427"
Received: from fmsmsx103.amr.corp.intel.com ([10.19.9.34])
	by fmsmga002.fm.intel.com with ESMTP; 20 Sep 2012 01:56:04 -0700
Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by
	FMSMSX103.amr.corp.intel.com (10.19.9.34) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Thu, 20 Sep 2012 01:56:03 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.239]) by
	SHSMSX102.ccr.corp.intel.com ([169.254.2.92]) with mapi id
	14.01.0355.002; Thu, 20 Sep 2012 16:56:02 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: Jan Beulich <JBeulich@suse.com>, Keir Fraser <keir@xen.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Thread-Topic: [PATCH 1/3] Implement tsc adjust feature for hvm guest
Thread-Index: Ac2XDcENCZMFyx5JS3CH2UElyxcsVA==
Date: Thu, 20 Sep 2012 08:56:01 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC8292335331C56@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_DE8DF0795D48FD4CA783C40EC8292335331C56SHSMSX101ccrcorpi_"
MIME-Version: 1.0
Subject: [Xen-devel] [PATCH 1/3] Implement tsc adjust feature for 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_DE8DF0795D48FD4CA783C40EC8292335331C56SHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Implement tsc adjust feature for hvm guest

IA32_TSC_ADJUST MSR is maintained separately for each logical processor.
A logical processor maintains and uses the IA32_TSC_ADJUST MSR as follows:
1). On RESET, the value of the IA32_TSC_ADJUST MSR is 0;
2). If an execution of WRMSR to the IA32_TIME_STAMP_COUNTER MSR adds (or su=
btracts)
    value X from the TSC, the logical processor also adds (or subtracts) va=
lue X
    from the IA32_TSC_ADJUST MSR;
3). If an execution of WRMSR to the IA32_TSC_ADJUST MSR adds (or subtracts)
    value X from that MSR, the logical processor also adds (or subtracts) v=
alue X
    from the TSC;

This patch provides tsc adjust support for hvm guest, with it guest OS woul=
d be happy when sync tsc.

Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>

diff -r d5c677159abb xen/arch/x86/hvm/hvm.c
--- a/xen/arch/x86/hvm/hvm.c	Thu Sep 20 21:50:56 2012 +0800
+++ b/xen/arch/x86/hvm/hvm.c	Thu Sep 20 23:34:04 2012 +0800
@@ -244,6 +244,7 @@
 void hvm_set_guest_tsc(struct vcpu *v, u64 guest_tsc)
 {
     uint64_t tsc;
+    uint64_t delta_tsc;
=20
     if ( v->domain->arch.vtsc )
     {
@@ -255,10 +256,23 @@
         rdtscll(tsc);
     }
=20
-    v->arch.hvm_vcpu.cache_tsc_offset =3D guest_tsc - tsc;
+    delta_tsc =3D guest_tsc - tsc;
+
+    v->arch.hvm_vcpu.msr_tsc_adjust +=3D delta_tsc
+                          - v->arch.hvm_vcpu.cache_tsc_offset;
+    v->arch.hvm_vcpu.cache_tsc_offset =3D delta_tsc;
+
     hvm_funcs.set_tsc_offset(v, v->arch.hvm_vcpu.cache_tsc_offset);
 }
=20
+void hvm_set_guest_tsc_adjust(struct vcpu *v, u64 tsc_adjust)
+{
+    v->arch.hvm_vcpu.cache_tsc_offset +=3D tsc_adjust
+                            - v->arch.hvm_vcpu.msr_tsc_adjust;
+    hvm_funcs.set_tsc_offset(v, v->arch.hvm_vcpu.cache_tsc_offset);
+    v->arch.hvm_vcpu.msr_tsc_adjust =3D tsc_adjust;
+}
+
 u64 hvm_get_guest_tsc(struct vcpu *v)
 {
     uint64_t tsc;
@@ -277,6 +291,11 @@
     return tsc + v->arch.hvm_vcpu.cache_tsc_offset;
 }
=20
+u64 hvm_get_guest_tsc_adjust(struct vcpu *v)
+{
+    return v->arch.hvm_vcpu.msr_tsc_adjust;
+}
+
 void hvm_migrate_timers(struct vcpu *v)
 {
     rtc_migrate_timers(v);
@@ -2776,6 +2795,10 @@
         *msr_content =3D hvm_get_guest_tsc(v);
         break;
=20
+    case MSR_IA32_TSC_ADJUST:
+        *msr_content =3D hvm_get_guest_tsc_adjust(v);
+        break;
+
     case MSR_TSC_AUX:
         *msr_content =3D hvm_msr_tsc_aux(v);
         break;
@@ -2889,6 +2912,10 @@
         hvm_set_guest_tsc(v, msr_content);
         break;
=20
+    case MSR_IA32_TSC_ADJUST:
+        hvm_set_guest_tsc_adjust(v, msr_content);
+        break;
+
     case MSR_TSC_AUX:
         v->arch.hvm_vcpu.msr_tsc_aux =3D (uint32_t)msr_content;
         if ( cpu_has_rdtscp
@@ -3436,6 +3463,8 @@
         v->domain->vcpu[0]->arch.hvm_vcpu.cache_tsc_offset;
     hvm_funcs.set_tsc_offset(v, v->arch.hvm_vcpu.cache_tsc_offset);
=20
+    v->arch.hvm_vcpu.msr_tsc_adjust =3D 0;
+
     paging_update_paging_modes(v);
=20
     v->arch.flags |=3D TF_kernel_mode;
diff -r d5c677159abb xen/include/asm-x86/hvm/vcpu.h
--- a/xen/include/asm-x86/hvm/vcpu.h	Thu Sep 20 21:50:56 2012 +0800
+++ b/xen/include/asm-x86/hvm/vcpu.h	Thu Sep 20 23:34:04 2012 +0800
@@ -137,6 +137,7 @@
     struct hvm_vcpu_asid n1asid;
=20
     u32                 msr_tsc_aux;
+    u64                 msr_tsc_adjust;
=20
     /* VPMU */
     struct vpmu_struct  vpmu;
diff -r d5c677159abb xen/include/asm-x86/msr-index.h
--- a/xen/include/asm-x86/msr-index.h	Thu Sep 20 21:50:56 2012 +0800
+++ b/xen/include/asm-x86/msr-index.h	Thu Sep 20 23:34:04 2012 +0800
@@ -284,6 +284,7 @@
 #define MSR_IA32_PLATFORM_ID		0x00000017
 #define MSR_IA32_EBL_CR_POWERON		0x0000002a
 #define MSR_IA32_EBC_FREQUENCY_ID	0x0000002c
+#define MSR_IA32_TSC_ADJUST		0x0000003b
=20
 #define MSR_IA32_APICBASE		0x0000001b
 #define MSR_IA32_APICBASE_BSP		(1<<8)=

--_002_DE8DF0795D48FD4CA783C40EC8292335331C56SHSMSX101ccrcorpi_
Content-Type: application/octet-stream; name="tsc_adjust_1.patch"
Content-Description: tsc_adjust_1.patch
Content-Disposition: attachment; filename="tsc_adjust_1.patch"; size=3800;
	creation-date="Thu, 20 Sep 2012 08:50:31 GMT";
	modification-date="Thu, 20 Sep 2012 16:39:00 GMT"
Content-Transfer-Encoding: base64

SW1wbGVtZW50IHRzYyBhZGp1c3QgZmVhdHVyZSBmb3IgaHZtIGd1ZXN0CgpJQTMyX1RTQ19BREpV
U1QgTVNSIGlzIG1haW50YWluZWQgc2VwYXJhdGVseSBmb3IgZWFjaCBsb2dpY2FsIHByb2Nlc3Nv
ci4KQSBsb2dpY2FsIHByb2Nlc3NvciBtYWludGFpbnMgYW5kIHVzZXMgdGhlIElBMzJfVFNDX0FE
SlVTVCBNU1IgYXMgZm9sbG93czoKMSkuIE9uIFJFU0VULCB0aGUgdmFsdWUgb2YgdGhlIElBMzJf
VFNDX0FESlVTVCBNU1IgaXMgMDsKMikuIElmIGFuIGV4ZWN1dGlvbiBvZiBXUk1TUiB0byB0aGUg
SUEzMl9USU1FX1NUQU1QX0NPVU5URVIgTVNSIGFkZHMgKG9yIHN1YnRyYWN0cykKICAgIHZhbHVl
IFggZnJvbSB0aGUgVFNDLCB0aGUgbG9naWNhbCBwcm9jZXNzb3IgYWxzbyBhZGRzIChvciBzdWJ0
cmFjdHMpIHZhbHVlIFgKICAgIGZyb20gdGhlIElBMzJfVFNDX0FESlVTVCBNU1I7CjMpLiBJZiBh
biBleGVjdXRpb24gb2YgV1JNU1IgdG8gdGhlIElBMzJfVFNDX0FESlVTVCBNU1IgYWRkcyAob3Ig
c3VidHJhY3RzKQogICAgdmFsdWUgWCBmcm9tIHRoYXQgTVNSLCB0aGUgbG9naWNhbCBwcm9jZXNz
b3IgYWxzbyBhZGRzIChvciBzdWJ0cmFjdHMpIHZhbHVlIFgKICAgIGZyb20gdGhlIFRTQzsKClRo
aXMgcGF0Y2ggcHJvdmlkZXMgdHNjIGFkanVzdCBzdXBwb3J0IGZvciBodm0gZ3Vlc3QsIHdpdGgg
aXQgZ3Vlc3QgT1Mgd291bGQgYmUgaGFwcHkgd2hlbiBzeW5jIHRzYy4KClNpZ25lZC1vZmYtYnk6
IExpdSwgSmluc29uZyA8amluc29uZy5saXVAaW50ZWwuY29tPgoKZGlmZiAtciBkNWM2NzcxNTlh
YmIgeGVuL2FyY2gveDg2L2h2bS9odm0uYwotLS0gYS94ZW4vYXJjaC94ODYvaHZtL2h2bS5jCVRo
dSBTZXAgMjAgMjE6NTA6NTYgMjAxMiArMDgwMAorKysgYi94ZW4vYXJjaC94ODYvaHZtL2h2bS5j
CVRodSBTZXAgMjAgMjM6MzQ6MDQgMjAxMiArMDgwMApAQCAtMjQ0LDYgKzI0NCw3IEBACiB2b2lk
IGh2bV9zZXRfZ3Vlc3RfdHNjKHN0cnVjdCB2Y3B1ICp2LCB1NjQgZ3Vlc3RfdHNjKQogewogICAg
IHVpbnQ2NF90IHRzYzsKKyAgICB1aW50NjRfdCBkZWx0YV90c2M7CiAKICAgICBpZiAoIHYtPmRv
bWFpbi0+YXJjaC52dHNjICkKICAgICB7CkBAIC0yNTUsMTAgKzI1NiwyMyBAQAogICAgICAgICBy
ZHRzY2xsKHRzYyk7CiAgICAgfQogCi0gICAgdi0+YXJjaC5odm1fdmNwdS5jYWNoZV90c2Nfb2Zm
c2V0ID0gZ3Vlc3RfdHNjIC0gdHNjOworICAgIGRlbHRhX3RzYyA9IGd1ZXN0X3RzYyAtIHRzYzsK
KworICAgIHYtPmFyY2guaHZtX3ZjcHUubXNyX3RzY19hZGp1c3QgKz0gZGVsdGFfdHNjCisgICAg
ICAgICAgICAgICAgICAgICAgICAgIC0gdi0+YXJjaC5odm1fdmNwdS5jYWNoZV90c2Nfb2Zmc2V0
OworICAgIHYtPmFyY2guaHZtX3ZjcHUuY2FjaGVfdHNjX29mZnNldCA9IGRlbHRhX3RzYzsKKwog
ICAgIGh2bV9mdW5jcy5zZXRfdHNjX29mZnNldCh2LCB2LT5hcmNoLmh2bV92Y3B1LmNhY2hlX3Rz
Y19vZmZzZXQpOwogfQogCit2b2lkIGh2bV9zZXRfZ3Vlc3RfdHNjX2FkanVzdChzdHJ1Y3QgdmNw
dSAqdiwgdTY0IHRzY19hZGp1c3QpCit7CisgICAgdi0+YXJjaC5odm1fdmNwdS5jYWNoZV90c2Nf
b2Zmc2V0ICs9IHRzY19hZGp1c3QKKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAtIHYtPmFy
Y2guaHZtX3ZjcHUubXNyX3RzY19hZGp1c3Q7CisgICAgaHZtX2Z1bmNzLnNldF90c2Nfb2Zmc2V0
KHYsIHYtPmFyY2guaHZtX3ZjcHUuY2FjaGVfdHNjX29mZnNldCk7CisgICAgdi0+YXJjaC5odm1f
dmNwdS5tc3JfdHNjX2FkanVzdCA9IHRzY19hZGp1c3Q7Cit9CisKIHU2NCBodm1fZ2V0X2d1ZXN0
X3RzYyhzdHJ1Y3QgdmNwdSAqdikKIHsKICAgICB1aW50NjRfdCB0c2M7CkBAIC0yNzcsNiArMjkx
LDExIEBACiAgICAgcmV0dXJuIHRzYyArIHYtPmFyY2guaHZtX3ZjcHUuY2FjaGVfdHNjX29mZnNl
dDsKIH0KIAordTY0IGh2bV9nZXRfZ3Vlc3RfdHNjX2FkanVzdChzdHJ1Y3QgdmNwdSAqdikKK3sK
KyAgICByZXR1cm4gdi0+YXJjaC5odm1fdmNwdS5tc3JfdHNjX2FkanVzdDsKK30KKwogdm9pZCBo
dm1fbWlncmF0ZV90aW1lcnMoc3RydWN0IHZjcHUgKnYpCiB7CiAgICAgcnRjX21pZ3JhdGVfdGlt
ZXJzKHYpOwpAQCAtMjc3Niw2ICsyNzk1LDEwIEBACiAgICAgICAgICptc3JfY29udGVudCA9IGh2
bV9nZXRfZ3Vlc3RfdHNjKHYpOwogICAgICAgICBicmVhazsKIAorICAgIGNhc2UgTVNSX0lBMzJf
VFNDX0FESlVTVDoKKyAgICAgICAgKm1zcl9jb250ZW50ID0gaHZtX2dldF9ndWVzdF90c2NfYWRq
dXN0KHYpOworICAgICAgICBicmVhazsKKwogICAgIGNhc2UgTVNSX1RTQ19BVVg6CiAgICAgICAg
ICptc3JfY29udGVudCA9IGh2bV9tc3JfdHNjX2F1eCh2KTsKICAgICAgICAgYnJlYWs7CkBAIC0y
ODg5LDYgKzI5MTIsMTAgQEAKICAgICAgICAgaHZtX3NldF9ndWVzdF90c2ModiwgbXNyX2NvbnRl
bnQpOwogICAgICAgICBicmVhazsKIAorICAgIGNhc2UgTVNSX0lBMzJfVFNDX0FESlVTVDoKKyAg
ICAgICAgaHZtX3NldF9ndWVzdF90c2NfYWRqdXN0KHYsIG1zcl9jb250ZW50KTsKKyAgICAgICAg
YnJlYWs7CisKICAgICBjYXNlIE1TUl9UU0NfQVVYOgogICAgICAgICB2LT5hcmNoLmh2bV92Y3B1
Lm1zcl90c2NfYXV4ID0gKHVpbnQzMl90KW1zcl9jb250ZW50OwogICAgICAgICBpZiAoIGNwdV9o
YXNfcmR0c2NwCkBAIC0zNDM2LDYgKzM0NjMsOCBAQAogICAgICAgICB2LT5kb21haW4tPnZjcHVb
MF0tPmFyY2guaHZtX3ZjcHUuY2FjaGVfdHNjX29mZnNldDsKICAgICBodm1fZnVuY3Muc2V0X3Rz
Y19vZmZzZXQodiwgdi0+YXJjaC5odm1fdmNwdS5jYWNoZV90c2Nfb2Zmc2V0KTsKIAorICAgIHYt
PmFyY2guaHZtX3ZjcHUubXNyX3RzY19hZGp1c3QgPSAwOworCiAgICAgcGFnaW5nX3VwZGF0ZV9w
YWdpbmdfbW9kZXModik7CiAKICAgICB2LT5hcmNoLmZsYWdzIHw9IFRGX2tlcm5lbF9tb2RlOwpk
aWZmIC1yIGQ1YzY3NzE1OWFiYiB4ZW4vaW5jbHVkZS9hc20teDg2L2h2bS92Y3B1LmgKLS0tIGEv
eGVuL2luY2x1ZGUvYXNtLXg4Ni9odm0vdmNwdS5oCVRodSBTZXAgMjAgMjE6NTA6NTYgMjAxMiAr
MDgwMAorKysgYi94ZW4vaW5jbHVkZS9hc20teDg2L2h2bS92Y3B1LmgJVGh1IFNlcCAyMCAyMzoz
NDowNCAyMDEyICswODAwCkBAIC0xMzcsNiArMTM3LDcgQEAKICAgICBzdHJ1Y3QgaHZtX3ZjcHVf
YXNpZCBuMWFzaWQ7CiAKICAgICB1MzIgICAgICAgICAgICAgICAgIG1zcl90c2NfYXV4OworICAg
IHU2NCAgICAgICAgICAgICAgICAgbXNyX3RzY19hZGp1c3Q7CiAKICAgICAvKiBWUE1VICovCiAg
ICAgc3RydWN0IHZwbXVfc3RydWN0ICB2cG11OwpkaWZmIC1yIGQ1YzY3NzE1OWFiYiB4ZW4vaW5j
bHVkZS9hc20teDg2L21zci1pbmRleC5oCi0tLSBhL3hlbi9pbmNsdWRlL2FzbS14ODYvbXNyLWlu
ZGV4LmgJVGh1IFNlcCAyMCAyMTo1MDo1NiAyMDEyICswODAwCisrKyBiL3hlbi9pbmNsdWRlL2Fz
bS14ODYvbXNyLWluZGV4LmgJVGh1IFNlcCAyMCAyMzozNDowNCAyMDEyICswODAwCkBAIC0yODQs
NiArMjg0LDcgQEAKICNkZWZpbmUgTVNSX0lBMzJfUExBVEZPUk1fSUQJCTB4MDAwMDAwMTcKICNk
ZWZpbmUgTVNSX0lBMzJfRUJMX0NSX1BPV0VST04JCTB4MDAwMDAwMmEKICNkZWZpbmUgTVNSX0lB
MzJfRUJDX0ZSRVFVRU5DWV9JRAkweDAwMDAwMDJjCisjZGVmaW5lIE1TUl9JQTMyX1RTQ19BREpV
U1QJCTB4MDAwMDAwM2IKIAogI2RlZmluZSBNU1JfSUEzMl9BUElDQkFTRQkJMHgwMDAwMDAxYgog
I2RlZmluZSBNU1JfSUEzMl9BUElDQkFTRV9CU1AJCSgxPDw4KQo=

--_002_DE8DF0795D48FD4CA783C40EC8292335331C56SHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 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_DE8DF0795D48FD4CA783C40EC8292335331C56SHSMSX101ccrcorpi_--


From xen-devel-bounces@lists.xen.org Thu Sep 20 08:57:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Sep 2012 08: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 1TEcZG-0003oW-2s; Thu, 20 Sep 2012 08:57:06 +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 1TEcZE-0003oG-HC
	for xen-devel@lists.xensource.com; Thu, 20 Sep 2012 08:57:04 +0000
Received: from [85.158.139.211:49793] by server-6.bemta-5.messagelabs.com id
	C9/9D-21336-F5ADA505; Thu, 20 Sep 2012 08:57:03 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-11.tower-206.messagelabs.com!1348131408!19291909!1
X-Originating-IP: [134.134.136.24]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjQgPT4gMzQ0ODU0\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3714 invoked from network); 20 Sep 2012 08:56:58 -0000
Received: from mga09.intel.com (HELO mga09.intel.com) (134.134.136.24)
	by server-11.tower-206.messagelabs.com with SMTP;
	20 Sep 2012 08:56:58 -0000
Received: from orsmga001.jf.intel.com ([10.7.209.18])
	by orsmga102.jf.intel.com with ESMTP; 20 Sep 2012 01:56:35 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.80,453,1344236400"; d="scan'208";a="195217795"
Received: from fmsmsx107.amr.corp.intel.com ([10.19.9.54])
	by orsmga001.jf.intel.com with ESMTP; 20 Sep 2012 01:56:47 -0700
Received: from fmsmsx101.amr.corp.intel.com (10.19.9.52) by
	FMSMSX107.amr.corp.intel.com (10.19.9.54) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Thu, 20 Sep 2012 01:56:46 -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; Thu, 20 Sep 2012 01:56:46 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.239]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.175]) with mapi id
	14.01.0355.002; Thu, 20 Sep 2012 16:56:44 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: Jan Beulich <JBeulich@suse.com>, Keir Fraser <keir@xen.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Thread-Topic: [PATCH 2/3] Save/restore tsc adjust when hvm guest migrate
Thread-Index: Ac2XDdpXFp6nyN3wTGWhNJ06hLB4cw==
Date: Thu, 20 Sep 2012 08:56:44 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC8292335331C64@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_DE8DF0795D48FD4CA783C40EC8292335331C64SHSMSX101ccrcorpi_"
MIME-Version: 1.0
Subject: [Xen-devel] [PATCH 2/3] Save/restore tsc adjust when hvm guest
	migrate
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--_002_DE8DF0795D48FD4CA783C40EC8292335331C64SHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Save/restore tsc adjust when hvm guest migrate

Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>

diff -r d94d78756665 tools/misc/xen-hvmctx.c
--- a/tools/misc/xen-hvmctx.c	Thu Sep 20 21:57:36 2012 +0800
+++ b/tools/misc/xen-hvmctx.c	Thu Sep 20 22:07:14 2012 +0800
@@ -392,6 +392,13 @@
     printf("    VMCE_VCPU: bank1 mci_ctl2 %" PRIx64 "\n", p.mci_ctl2_bank1=
);
 }
=20
+static void dump_tsc_adjust(void)
+{
+    HVM_SAVE_TYPE(TSC_ADJUST) p;
+    READ(p);
+    printf("    TSC_ADJUST: tsc_adjust %" PRIx64 "\n", p.tsc_adjust);
+}
+
 int main(int argc, char **argv)
 {
     int entry, domid;
@@ -459,6 +466,7 @@
         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(TSC_ADJUST): dump_tsc_adjust(); break;
         case HVM_SAVE_CODE(END): break;
         default:
             printf(" ** Don't understand type %u: skipping\n",
diff -r d94d78756665 xen/arch/x86/hvm/hvm.c
--- a/xen/arch/x86/hvm/hvm.c	Thu Sep 20 21:57:36 2012 +0800
+++ b/xen/arch/x86/hvm/hvm.c	Thu Sep 20 22:07:14 2012 +0800
@@ -605,6 +605,45 @@
     hvm_destroy_cacheattr_region_list(d);
 }
=20
+static int hvm_save_tsc_adjust(struct domain *d, hvm_domain_context_t *h)
+{
+    struct vcpu *v;
+    struct hvm_tsc_adjust ctxt;
+    int err =3D 0;
+
+    for_each_vcpu( d, v ){
+        ctxt.tsc_adjust =3D v->arch.hvm_vcpu.msr_tsc_adjust;
+        err =3D hvm_save_entry(TSC_ADJUST, v->vcpu_id, h, &ctxt);
+        if ( err )
+            break;
+    }
+
+    return err;
+}
+
+static int hvm_load_tsc_adjust(struct domain *d, hvm_domain_context_t *h)
+{
+    unsigned int vcpuid =3D hvm_load_instance(h);
+    struct vcpu *v;
+    struct hvm_tsc_adjust ctxt;
+
+    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);
+        return -EINVAL;
+    }
+
+    if ( hvm_load_entry(TSC_ADJUST, h, &ctxt) !=3D 0 )
+        return -EINVAL;
+
+    v->arch.hvm_vcpu.msr_tsc_adjust =3D ctxt.tsc_adjust;
+    return 0;
+}
+
+HVM_REGISTER_SAVE_RESTORE(TSC_ADJUST, hvm_save_tsc_adjust,
+                          hvm_load_tsc_adjust, 1, HVMSR_PER_VCPU);
+
 static int hvm_save_cpu_ctxt(struct domain *d, hvm_domain_context_t *h)
 {
     struct vcpu *v;
diff -r d94d78756665 xen/include/public/arch-x86/hvm/save.h
--- a/xen/include/public/arch-x86/hvm/save.h	Thu Sep 20 21:57:36 2012 +0800
+++ b/xen/include/public/arch-x86/hvm/save.h	Thu Sep 20 22:07:14 2012 +0800
@@ -583,9 +583,15 @@
=20
 DECLARE_HVM_SAVE_TYPE(VMCE_VCPU, 18, struct hvm_vmce_vcpu);
=20
+struct hvm_tsc_adjust {
+    uint64_t tsc_adjust;
+};
+
+DECLARE_HVM_SAVE_TYPE(TSC_ADJUST, 19, struct hvm_tsc_adjust);
+
 /*=20
  * Largest type-code in use
  */
-#define HVM_SAVE_CODE_MAX 18
+#define HVM_SAVE_CODE_MAX 19
=20
 #endif /* __XEN_PUBLIC_HVM_SAVE_X86_H__ */=

--_002_DE8DF0795D48FD4CA783C40EC8292335331C64SHSMSX101ccrcorpi_
Content-Type: application/octet-stream; name="tsc_adjust_2.patch"
Content-Description: tsc_adjust_2.patch
Content-Disposition: attachment; filename="tsc_adjust_2.patch"; size=2977;
	creation-date="Thu, 20 Sep 2012 08:50:31 GMT";
	modification-date="Thu, 20 Sep 2012 16:39:26 GMT"
Content-Transfer-Encoding: base64

U2F2ZS9yZXN0b3JlIHRzYyBhZGp1c3Qgd2hlbiBodm0gZ3Vlc3QgbWlncmF0ZQoKU2lnbmVkLW9m
Zi1ieTogTGl1LCBKaW5zb25nIDxqaW5zb25nLmxpdUBpbnRlbC5jb20+CgpkaWZmIC1yIGQ5NGQ3
ODc1NjY2NSB0b29scy9taXNjL3hlbi1odm1jdHguYwotLS0gYS90b29scy9taXNjL3hlbi1odm1j
dHguYwlUaHUgU2VwIDIwIDIxOjU3OjM2IDIwMTIgKzA4MDAKKysrIGIvdG9vbHMvbWlzYy94ZW4t
aHZtY3R4LmMJVGh1IFNlcCAyMCAyMjowNzoxNCAyMDEyICswODAwCkBAIC0zOTIsNiArMzkyLDEz
IEBACiAgICAgcHJpbnRmKCIgICAgVk1DRV9WQ1BVOiBiYW5rMSBtY2lfY3RsMiAlIiBQUkl4NjQg
IlxuIiwgcC5tY2lfY3RsMl9iYW5rMSk7CiB9CiAKK3N0YXRpYyB2b2lkIGR1bXBfdHNjX2FkanVz
dCh2b2lkKQoreworICAgIEhWTV9TQVZFX1RZUEUoVFNDX0FESlVTVCkgcDsKKyAgICBSRUFEKHAp
OworICAgIHByaW50ZigiICAgIFRTQ19BREpVU1Q6IHRzY19hZGp1c3QgJSIgUFJJeDY0ICJcbiIs
IHAudHNjX2FkanVzdCk7Cit9CisKIGludCBtYWluKGludCBhcmdjLCBjaGFyICoqYXJndikKIHsK
ICAgICBpbnQgZW50cnksIGRvbWlkOwpAQCAtNDU5LDYgKzQ2Niw3IEBACiAgICAgICAgIGNhc2Ug
SFZNX1NBVkVfQ09ERShWSVJJRElBTl9ET01BSU4pOiBkdW1wX3ZpcmlkaWFuX2RvbWFpbigpOyBi
cmVhazsKICAgICAgICAgY2FzZSBIVk1fU0FWRV9DT0RFKFZJUklESUFOX1ZDUFUpOiBkdW1wX3Zp
cmlkaWFuX3ZjcHUoKTsgYnJlYWs7CiAgICAgICAgIGNhc2UgSFZNX1NBVkVfQ09ERShWTUNFX1ZD
UFUpOiBkdW1wX3ZtY2VfdmNwdSgpOyBicmVhazsKKyAgICAgICAgY2FzZSBIVk1fU0FWRV9DT0RF
KFRTQ19BREpVU1QpOiBkdW1wX3RzY19hZGp1c3QoKTsgYnJlYWs7CiAgICAgICAgIGNhc2UgSFZN
X1NBVkVfQ09ERShFTkQpOiBicmVhazsKICAgICAgICAgZGVmYXVsdDoKICAgICAgICAgICAgIHBy
aW50ZigiICoqIERvbid0IHVuZGVyc3RhbmQgdHlwZSAldTogc2tpcHBpbmdcbiIsCmRpZmYgLXIg
ZDk0ZDc4NzU2NjY1IHhlbi9hcmNoL3g4Ni9odm0vaHZtLmMKLS0tIGEveGVuL2FyY2gveDg2L2h2
bS9odm0uYwlUaHUgU2VwIDIwIDIxOjU3OjM2IDIwMTIgKzA4MDAKKysrIGIveGVuL2FyY2gveDg2
L2h2bS9odm0uYwlUaHUgU2VwIDIwIDIyOjA3OjE0IDIwMTIgKzA4MDAKQEAgLTYwNSw2ICs2MDUs
NDUgQEAKICAgICBodm1fZGVzdHJveV9jYWNoZWF0dHJfcmVnaW9uX2xpc3QoZCk7CiB9CiAKK3N0
YXRpYyBpbnQgaHZtX3NhdmVfdHNjX2FkanVzdChzdHJ1Y3QgZG9tYWluICpkLCBodm1fZG9tYWlu
X2NvbnRleHRfdCAqaCkKK3sKKyAgICBzdHJ1Y3QgdmNwdSAqdjsKKyAgICBzdHJ1Y3QgaHZtX3Rz
Y19hZGp1c3QgY3R4dDsKKyAgICBpbnQgZXJyID0gMDsKKworICAgIGZvcl9lYWNoX3ZjcHUoIGQs
IHYgKXsKKyAgICAgICAgY3R4dC50c2NfYWRqdXN0ID0gdi0+YXJjaC5odm1fdmNwdS5tc3JfdHNj
X2FkanVzdDsKKyAgICAgICAgZXJyID0gaHZtX3NhdmVfZW50cnkoVFNDX0FESlVTVCwgdi0+dmNw
dV9pZCwgaCwgJmN0eHQpOworICAgICAgICBpZiAoIGVyciApCisgICAgICAgICAgICBicmVhazsK
KyAgICB9CisKKyAgICByZXR1cm4gZXJyOworfQorCitzdGF0aWMgaW50IGh2bV9sb2FkX3RzY19h
ZGp1c3Qoc3RydWN0IGRvbWFpbiAqZCwgaHZtX2RvbWFpbl9jb250ZXh0X3QgKmgpCit7CisgICAg
dW5zaWduZWQgaW50IHZjcHVpZCA9IGh2bV9sb2FkX2luc3RhbmNlKGgpOworICAgIHN0cnVjdCB2
Y3B1ICp2OworICAgIHN0cnVjdCBodm1fdHNjX2FkanVzdCBjdHh0OworCisgICAgaWYgKCB2Y3B1
aWQgPj0gZC0+bWF4X3ZjcHVzIHx8ICh2ID0gZC0+dmNwdVt2Y3B1aWRdKSA9PSBOVUxMICkKKyAg
ICB7CisgICAgICAgIGRwcmludGsoWEVOTE9HX0dfRVJSLCAiSFZNIHJlc3RvcmU6IGRvbSVkIGhh
cyBubyB2Y3B1JXVcbiIsCisgICAgICAgICAgICAgICAgZC0+ZG9tYWluX2lkLCB2Y3B1aWQpOwor
ICAgICAgICByZXR1cm4gLUVJTlZBTDsKKyAgICB9CisKKyAgICBpZiAoIGh2bV9sb2FkX2VudHJ5
KFRTQ19BREpVU1QsIGgsICZjdHh0KSAhPSAwICkKKyAgICAgICAgcmV0dXJuIC1FSU5WQUw7CisK
KyAgICB2LT5hcmNoLmh2bV92Y3B1Lm1zcl90c2NfYWRqdXN0ID0gY3R4dC50c2NfYWRqdXN0Owor
ICAgIHJldHVybiAwOworfQorCitIVk1fUkVHSVNURVJfU0FWRV9SRVNUT1JFKFRTQ19BREpVU1Qs
IGh2bV9zYXZlX3RzY19hZGp1c3QsCisgICAgICAgICAgICAgICAgICAgICAgICAgIGh2bV9sb2Fk
X3RzY19hZGp1c3QsIDEsIEhWTVNSX1BFUl9WQ1BVKTsKKwogc3RhdGljIGludCBodm1fc2F2ZV9j
cHVfY3R4dChzdHJ1Y3QgZG9tYWluICpkLCBodm1fZG9tYWluX2NvbnRleHRfdCAqaCkKIHsKICAg
ICBzdHJ1Y3QgdmNwdSAqdjsKZGlmZiAtciBkOTRkNzg3NTY2NjUgeGVuL2luY2x1ZGUvcHVibGlj
L2FyY2gteDg2L2h2bS9zYXZlLmgKLS0tIGEveGVuL2luY2x1ZGUvcHVibGljL2FyY2gteDg2L2h2
bS9zYXZlLmgJVGh1IFNlcCAyMCAyMTo1NzozNiAyMDEyICswODAwCisrKyBiL3hlbi9pbmNsdWRl
L3B1YmxpYy9hcmNoLXg4Ni9odm0vc2F2ZS5oCVRodSBTZXAgMjAgMjI6MDc6MTQgMjAxMiArMDgw
MApAQCAtNTgzLDkgKzU4MywxNSBAQAogCiBERUNMQVJFX0hWTV9TQVZFX1RZUEUoVk1DRV9WQ1BV
LCAxOCwgc3RydWN0IGh2bV92bWNlX3ZjcHUpOwogCitzdHJ1Y3QgaHZtX3RzY19hZGp1c3Qgewor
ICAgIHVpbnQ2NF90IHRzY19hZGp1c3Q7Cit9OworCitERUNMQVJFX0hWTV9TQVZFX1RZUEUoVFND
X0FESlVTVCwgMTksIHN0cnVjdCBodm1fdHNjX2FkanVzdCk7CisKIC8qIAogICogTGFyZ2VzdCB0
eXBlLWNvZGUgaW4gdXNlCiAgKi8KLSNkZWZpbmUgSFZNX1NBVkVfQ09ERV9NQVggMTgKKyNkZWZp
bmUgSFZNX1NBVkVfQ09ERV9NQVggMTkKIAogI2VuZGlmIC8qIF9fWEVOX1BVQkxJQ19IVk1fU0FW
RV9YODZfSF9fICovCg==

--_002_DE8DF0795D48FD4CA783C40EC8292335331C64SHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 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_DE8DF0795D48FD4CA783C40EC8292335331C64SHSMSX101ccrcorpi_--


From xen-devel-bounces@lists.xen.org Thu Sep 20 08:57:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Sep 2012 08: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 1TEcZG-0003oW-2s; Thu, 20 Sep 2012 08:57:06 +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 1TEcZE-0003oG-HC
	for xen-devel@lists.xensource.com; Thu, 20 Sep 2012 08:57:04 +0000
Received: from [85.158.139.211:49793] by server-6.bemta-5.messagelabs.com id
	C9/9D-21336-F5ADA505; Thu, 20 Sep 2012 08:57:03 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-11.tower-206.messagelabs.com!1348131408!19291909!1
X-Originating-IP: [134.134.136.24]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjQgPT4gMzQ0ODU0\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3714 invoked from network); 20 Sep 2012 08:56:58 -0000
Received: from mga09.intel.com (HELO mga09.intel.com) (134.134.136.24)
	by server-11.tower-206.messagelabs.com with SMTP;
	20 Sep 2012 08:56:58 -0000
Received: from orsmga001.jf.intel.com ([10.7.209.18])
	by orsmga102.jf.intel.com with ESMTP; 20 Sep 2012 01:56:35 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.80,453,1344236400"; d="scan'208";a="195217795"
Received: from fmsmsx107.amr.corp.intel.com ([10.19.9.54])
	by orsmga001.jf.intel.com with ESMTP; 20 Sep 2012 01:56:47 -0700
Received: from fmsmsx101.amr.corp.intel.com (10.19.9.52) by
	FMSMSX107.amr.corp.intel.com (10.19.9.54) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Thu, 20 Sep 2012 01:56:46 -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; Thu, 20 Sep 2012 01:56:46 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.239]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.175]) with mapi id
	14.01.0355.002; Thu, 20 Sep 2012 16:56:44 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: Jan Beulich <JBeulich@suse.com>, Keir Fraser <keir@xen.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Thread-Topic: [PATCH 2/3] Save/restore tsc adjust when hvm guest migrate
Thread-Index: Ac2XDdpXFp6nyN3wTGWhNJ06hLB4cw==
Date: Thu, 20 Sep 2012 08:56:44 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC8292335331C64@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_DE8DF0795D48FD4CA783C40EC8292335331C64SHSMSX101ccrcorpi_"
MIME-Version: 1.0
Subject: [Xen-devel] [PATCH 2/3] Save/restore tsc adjust when hvm guest
	migrate
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--_002_DE8DF0795D48FD4CA783C40EC8292335331C64SHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Save/restore tsc adjust when hvm guest migrate

Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>

diff -r d94d78756665 tools/misc/xen-hvmctx.c
--- a/tools/misc/xen-hvmctx.c	Thu Sep 20 21:57:36 2012 +0800
+++ b/tools/misc/xen-hvmctx.c	Thu Sep 20 22:07:14 2012 +0800
@@ -392,6 +392,13 @@
     printf("    VMCE_VCPU: bank1 mci_ctl2 %" PRIx64 "\n", p.mci_ctl2_bank1=
);
 }
=20
+static void dump_tsc_adjust(void)
+{
+    HVM_SAVE_TYPE(TSC_ADJUST) p;
+    READ(p);
+    printf("    TSC_ADJUST: tsc_adjust %" PRIx64 "\n", p.tsc_adjust);
+}
+
 int main(int argc, char **argv)
 {
     int entry, domid;
@@ -459,6 +466,7 @@
         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(TSC_ADJUST): dump_tsc_adjust(); break;
         case HVM_SAVE_CODE(END): break;
         default:
             printf(" ** Don't understand type %u: skipping\n",
diff -r d94d78756665 xen/arch/x86/hvm/hvm.c
--- a/xen/arch/x86/hvm/hvm.c	Thu Sep 20 21:57:36 2012 +0800
+++ b/xen/arch/x86/hvm/hvm.c	Thu Sep 20 22:07:14 2012 +0800
@@ -605,6 +605,45 @@
     hvm_destroy_cacheattr_region_list(d);
 }
=20
+static int hvm_save_tsc_adjust(struct domain *d, hvm_domain_context_t *h)
+{
+    struct vcpu *v;
+    struct hvm_tsc_adjust ctxt;
+    int err =3D 0;
+
+    for_each_vcpu( d, v ){
+        ctxt.tsc_adjust =3D v->arch.hvm_vcpu.msr_tsc_adjust;
+        err =3D hvm_save_entry(TSC_ADJUST, v->vcpu_id, h, &ctxt);
+        if ( err )
+            break;
+    }
+
+    return err;
+}
+
+static int hvm_load_tsc_adjust(struct domain *d, hvm_domain_context_t *h)
+{
+    unsigned int vcpuid =3D hvm_load_instance(h);
+    struct vcpu *v;
+    struct hvm_tsc_adjust ctxt;
+
+    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);
+        return -EINVAL;
+    }
+
+    if ( hvm_load_entry(TSC_ADJUST, h, &ctxt) !=3D 0 )
+        return -EINVAL;
+
+    v->arch.hvm_vcpu.msr_tsc_adjust =3D ctxt.tsc_adjust;
+    return 0;
+}
+
+HVM_REGISTER_SAVE_RESTORE(TSC_ADJUST, hvm_save_tsc_adjust,
+                          hvm_load_tsc_adjust, 1, HVMSR_PER_VCPU);
+
 static int hvm_save_cpu_ctxt(struct domain *d, hvm_domain_context_t *h)
 {
     struct vcpu *v;
diff -r d94d78756665 xen/include/public/arch-x86/hvm/save.h
--- a/xen/include/public/arch-x86/hvm/save.h	Thu Sep 20 21:57:36 2012 +0800
+++ b/xen/include/public/arch-x86/hvm/save.h	Thu Sep 20 22:07:14 2012 +0800
@@ -583,9 +583,15 @@
=20
 DECLARE_HVM_SAVE_TYPE(VMCE_VCPU, 18, struct hvm_vmce_vcpu);
=20
+struct hvm_tsc_adjust {
+    uint64_t tsc_adjust;
+};
+
+DECLARE_HVM_SAVE_TYPE(TSC_ADJUST, 19, struct hvm_tsc_adjust);
+
 /*=20
  * Largest type-code in use
  */
-#define HVM_SAVE_CODE_MAX 18
+#define HVM_SAVE_CODE_MAX 19
=20
 #endif /* __XEN_PUBLIC_HVM_SAVE_X86_H__ */=

--_002_DE8DF0795D48FD4CA783C40EC8292335331C64SHSMSX101ccrcorpi_
Content-Type: application/octet-stream; name="tsc_adjust_2.patch"
Content-Description: tsc_adjust_2.patch
Content-Disposition: attachment; filename="tsc_adjust_2.patch"; size=2977;
	creation-date="Thu, 20 Sep 2012 08:50:31 GMT";
	modification-date="Thu, 20 Sep 2012 16:39:26 GMT"
Content-Transfer-Encoding: base64

U2F2ZS9yZXN0b3JlIHRzYyBhZGp1c3Qgd2hlbiBodm0gZ3Vlc3QgbWlncmF0ZQoKU2lnbmVkLW9m
Zi1ieTogTGl1LCBKaW5zb25nIDxqaW5zb25nLmxpdUBpbnRlbC5jb20+CgpkaWZmIC1yIGQ5NGQ3
ODc1NjY2NSB0b29scy9taXNjL3hlbi1odm1jdHguYwotLS0gYS90b29scy9taXNjL3hlbi1odm1j
dHguYwlUaHUgU2VwIDIwIDIxOjU3OjM2IDIwMTIgKzA4MDAKKysrIGIvdG9vbHMvbWlzYy94ZW4t
aHZtY3R4LmMJVGh1IFNlcCAyMCAyMjowNzoxNCAyMDEyICswODAwCkBAIC0zOTIsNiArMzkyLDEz
IEBACiAgICAgcHJpbnRmKCIgICAgVk1DRV9WQ1BVOiBiYW5rMSBtY2lfY3RsMiAlIiBQUkl4NjQg
IlxuIiwgcC5tY2lfY3RsMl9iYW5rMSk7CiB9CiAKK3N0YXRpYyB2b2lkIGR1bXBfdHNjX2FkanVz
dCh2b2lkKQoreworICAgIEhWTV9TQVZFX1RZUEUoVFNDX0FESlVTVCkgcDsKKyAgICBSRUFEKHAp
OworICAgIHByaW50ZigiICAgIFRTQ19BREpVU1Q6IHRzY19hZGp1c3QgJSIgUFJJeDY0ICJcbiIs
IHAudHNjX2FkanVzdCk7Cit9CisKIGludCBtYWluKGludCBhcmdjLCBjaGFyICoqYXJndikKIHsK
ICAgICBpbnQgZW50cnksIGRvbWlkOwpAQCAtNDU5LDYgKzQ2Niw3IEBACiAgICAgICAgIGNhc2Ug
SFZNX1NBVkVfQ09ERShWSVJJRElBTl9ET01BSU4pOiBkdW1wX3ZpcmlkaWFuX2RvbWFpbigpOyBi
cmVhazsKICAgICAgICAgY2FzZSBIVk1fU0FWRV9DT0RFKFZJUklESUFOX1ZDUFUpOiBkdW1wX3Zp
cmlkaWFuX3ZjcHUoKTsgYnJlYWs7CiAgICAgICAgIGNhc2UgSFZNX1NBVkVfQ09ERShWTUNFX1ZD
UFUpOiBkdW1wX3ZtY2VfdmNwdSgpOyBicmVhazsKKyAgICAgICAgY2FzZSBIVk1fU0FWRV9DT0RF
KFRTQ19BREpVU1QpOiBkdW1wX3RzY19hZGp1c3QoKTsgYnJlYWs7CiAgICAgICAgIGNhc2UgSFZN
X1NBVkVfQ09ERShFTkQpOiBicmVhazsKICAgICAgICAgZGVmYXVsdDoKICAgICAgICAgICAgIHBy
aW50ZigiICoqIERvbid0IHVuZGVyc3RhbmQgdHlwZSAldTogc2tpcHBpbmdcbiIsCmRpZmYgLXIg
ZDk0ZDc4NzU2NjY1IHhlbi9hcmNoL3g4Ni9odm0vaHZtLmMKLS0tIGEveGVuL2FyY2gveDg2L2h2
bS9odm0uYwlUaHUgU2VwIDIwIDIxOjU3OjM2IDIwMTIgKzA4MDAKKysrIGIveGVuL2FyY2gveDg2
L2h2bS9odm0uYwlUaHUgU2VwIDIwIDIyOjA3OjE0IDIwMTIgKzA4MDAKQEAgLTYwNSw2ICs2MDUs
NDUgQEAKICAgICBodm1fZGVzdHJveV9jYWNoZWF0dHJfcmVnaW9uX2xpc3QoZCk7CiB9CiAKK3N0
YXRpYyBpbnQgaHZtX3NhdmVfdHNjX2FkanVzdChzdHJ1Y3QgZG9tYWluICpkLCBodm1fZG9tYWlu
X2NvbnRleHRfdCAqaCkKK3sKKyAgICBzdHJ1Y3QgdmNwdSAqdjsKKyAgICBzdHJ1Y3QgaHZtX3Rz
Y19hZGp1c3QgY3R4dDsKKyAgICBpbnQgZXJyID0gMDsKKworICAgIGZvcl9lYWNoX3ZjcHUoIGQs
IHYgKXsKKyAgICAgICAgY3R4dC50c2NfYWRqdXN0ID0gdi0+YXJjaC5odm1fdmNwdS5tc3JfdHNj
X2FkanVzdDsKKyAgICAgICAgZXJyID0gaHZtX3NhdmVfZW50cnkoVFNDX0FESlVTVCwgdi0+dmNw
dV9pZCwgaCwgJmN0eHQpOworICAgICAgICBpZiAoIGVyciApCisgICAgICAgICAgICBicmVhazsK
KyAgICB9CisKKyAgICByZXR1cm4gZXJyOworfQorCitzdGF0aWMgaW50IGh2bV9sb2FkX3RzY19h
ZGp1c3Qoc3RydWN0IGRvbWFpbiAqZCwgaHZtX2RvbWFpbl9jb250ZXh0X3QgKmgpCit7CisgICAg
dW5zaWduZWQgaW50IHZjcHVpZCA9IGh2bV9sb2FkX2luc3RhbmNlKGgpOworICAgIHN0cnVjdCB2
Y3B1ICp2OworICAgIHN0cnVjdCBodm1fdHNjX2FkanVzdCBjdHh0OworCisgICAgaWYgKCB2Y3B1
aWQgPj0gZC0+bWF4X3ZjcHVzIHx8ICh2ID0gZC0+dmNwdVt2Y3B1aWRdKSA9PSBOVUxMICkKKyAg
ICB7CisgICAgICAgIGRwcmludGsoWEVOTE9HX0dfRVJSLCAiSFZNIHJlc3RvcmU6IGRvbSVkIGhh
cyBubyB2Y3B1JXVcbiIsCisgICAgICAgICAgICAgICAgZC0+ZG9tYWluX2lkLCB2Y3B1aWQpOwor
ICAgICAgICByZXR1cm4gLUVJTlZBTDsKKyAgICB9CisKKyAgICBpZiAoIGh2bV9sb2FkX2VudHJ5
KFRTQ19BREpVU1QsIGgsICZjdHh0KSAhPSAwICkKKyAgICAgICAgcmV0dXJuIC1FSU5WQUw7CisK
KyAgICB2LT5hcmNoLmh2bV92Y3B1Lm1zcl90c2NfYWRqdXN0ID0gY3R4dC50c2NfYWRqdXN0Owor
ICAgIHJldHVybiAwOworfQorCitIVk1fUkVHSVNURVJfU0FWRV9SRVNUT1JFKFRTQ19BREpVU1Qs
IGh2bV9zYXZlX3RzY19hZGp1c3QsCisgICAgICAgICAgICAgICAgICAgICAgICAgIGh2bV9sb2Fk
X3RzY19hZGp1c3QsIDEsIEhWTVNSX1BFUl9WQ1BVKTsKKwogc3RhdGljIGludCBodm1fc2F2ZV9j
cHVfY3R4dChzdHJ1Y3QgZG9tYWluICpkLCBodm1fZG9tYWluX2NvbnRleHRfdCAqaCkKIHsKICAg
ICBzdHJ1Y3QgdmNwdSAqdjsKZGlmZiAtciBkOTRkNzg3NTY2NjUgeGVuL2luY2x1ZGUvcHVibGlj
L2FyY2gteDg2L2h2bS9zYXZlLmgKLS0tIGEveGVuL2luY2x1ZGUvcHVibGljL2FyY2gteDg2L2h2
bS9zYXZlLmgJVGh1IFNlcCAyMCAyMTo1NzozNiAyMDEyICswODAwCisrKyBiL3hlbi9pbmNsdWRl
L3B1YmxpYy9hcmNoLXg4Ni9odm0vc2F2ZS5oCVRodSBTZXAgMjAgMjI6MDc6MTQgMjAxMiArMDgw
MApAQCAtNTgzLDkgKzU4MywxNSBAQAogCiBERUNMQVJFX0hWTV9TQVZFX1RZUEUoVk1DRV9WQ1BV
LCAxOCwgc3RydWN0IGh2bV92bWNlX3ZjcHUpOwogCitzdHJ1Y3QgaHZtX3RzY19hZGp1c3Qgewor
ICAgIHVpbnQ2NF90IHRzY19hZGp1c3Q7Cit9OworCitERUNMQVJFX0hWTV9TQVZFX1RZUEUoVFND
X0FESlVTVCwgMTksIHN0cnVjdCBodm1fdHNjX2FkanVzdCk7CisKIC8qIAogICogTGFyZ2VzdCB0
eXBlLWNvZGUgaW4gdXNlCiAgKi8KLSNkZWZpbmUgSFZNX1NBVkVfQ09ERV9NQVggMTgKKyNkZWZp
bmUgSFZNX1NBVkVfQ09ERV9NQVggMTkKIAogI2VuZGlmIC8qIF9fWEVOX1BVQkxJQ19IVk1fU0FW
RV9YODZfSF9fICovCg==

--_002_DE8DF0795D48FD4CA783C40EC8292335331C64SHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 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_DE8DF0795D48FD4CA783C40EC8292335331C64SHSMSX101ccrcorpi_--


From xen-devel-bounces@lists.xen.org Thu Sep 20 08:57:37 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Sep 2012 08:57:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TEcZb-0003sZ-Gp; Thu, 20 Sep 2012 08:57:27 +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 1TEcZZ-0003sF-Q2
	for xen-devel@lists.xensource.com; Thu, 20 Sep 2012 08:57:25 +0000
Received: from [85.158.143.99:15423] by server-2.bemta-4.messagelabs.com id
	60/29-06610-57ADA505; Thu, 20 Sep 2012 08:57:25 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1348131443!24961616!1
X-Originating-IP: [143.182.124.21]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMjEgPT4gMjA1MTY3\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11139 invoked from network); 20 Sep 2012 08:57:24 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (143.182.124.21)
	by server-7.tower-216.messagelabs.com with SMTP;
	20 Sep 2012 08:57:24 -0000
Received: from azsmga002.ch.intel.com ([10.2.17.35])
	by azsmga101.ch.intel.com with ESMTP; 20 Sep 2012 01:57:23 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.80,453,1344236400"; d="scan'208";a="147075409"
Received: from fmsmsx106.amr.corp.intel.com ([10.19.9.37])
	by AZSMGA002.ch.intel.com with ESMTP; 20 Sep 2012 01:57:22 -0700
Received: from fmsmsx152.amr.corp.intel.com (10.19.17.221) by
	FMSMSX106.amr.corp.intel.com (10.19.9.37) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Thu, 20 Sep 2012 01:57:22 -0700
Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by
	fmsmsx152.amr.corp.intel.com (10.19.17.221) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Thu, 20 Sep 2012 01:57:21 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.239]) by
	SHSMSX102.ccr.corp.intel.com ([169.254.2.92]) with mapi id
	14.01.0355.002; Thu, 20 Sep 2012 16:57:20 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: Jan Beulich <JBeulich@suse.com>, Keir Fraser <keir@xen.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Thread-Topic: [PATCH 3/3] Expose tsc adjust to hvm guest
Thread-Index: Ac2XDe/GX7zN2TRuSJ2FgKsQftsNkw==
Date: Thu, 20 Sep 2012 08:57:19 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC8292335331C73@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_DE8DF0795D48FD4CA783C40EC8292335331C73SHSMSX101ccrcorpi_"
MIME-Version: 1.0
Subject: [Xen-devel] [PATCH 3/3] Expose tsc adjust to 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_DE8DF0795D48FD4CA783C40EC8292335331C73SHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Expose tsc adjust to hvm guest

Intel latest SDM (17.13.3) release a new MSR
CPUID.7.0.EBX[1]=3D1 indicates TSC_ADJUST MSR 0x3b is supported.

This patch expose it to hvm guest.

Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>

diff -r a6d12a1bc758 tools/libxc/xc_cpufeature.h
--- a/tools/libxc/xc_cpufeature.h	Thu Sep 20 00:03:25 2012 +0800
+++ b/tools/libxc/xc_cpufeature.h	Thu Sep 20 21:50:55 2012 +0800
@@ -128,6 +128,7 @@
=20
 /* Intel-defined CPU features, CPUID level 0x00000007:0 (ebx) */
 #define X86_FEATURE_FSGSBASE     0 /* {RD,WR}{FS,GS}BASE instructions */
+#define X86_FEATURE_TSC_ADJUST   1 /* Tsc thread offset */
 #define X86_FEATURE_BMI1         3 /* 1st group bit manipulation extension=
s */
 #define X86_FEATURE_HLE          4 /* Hardware Lock Elision */
 #define X86_FEATURE_AVX2         5 /* AVX2 instructions */
diff -r a6d12a1bc758 tools/libxc/xc_cpuid_x86.c
--- a/tools/libxc/xc_cpuid_x86.c	Thu Sep 20 00:03:25 2012 +0800
+++ b/tools/libxc/xc_cpuid_x86.c	Thu Sep 20 21:50:55 2012 +0800
@@ -362,7 +362,8 @@
=20
     case 0x00000007: /* Intel-defined CPU features */
         if ( input[1] =3D=3D 0 ) {
-            regs[1] &=3D (bitmaskof(X86_FEATURE_BMI1) |
+            regs[1] &=3D (bitmaskof(X86_FEATURE_TSC_ADJUST) |
+                        bitmaskof(X86_FEATURE_BMI1) |
                         bitmaskof(X86_FEATURE_HLE)  |
                         bitmaskof(X86_FEATURE_AVX2) |
                         bitmaskof(X86_FEATURE_SMEP) |=

--_002_DE8DF0795D48FD4CA783C40EC8292335331C73SHSMSX101ccrcorpi_
Content-Type: application/octet-stream; name="tsc_adjust_3.patch"
Content-Description: tsc_adjust_3.patch
Content-Disposition: attachment; filename="tsc_adjust_3.patch"; size=1456;
	creation-date="Thu, 20 Sep 2012 08:50:31 GMT";
	modification-date="Thu, 20 Sep 2012 16:31:00 GMT"
Content-Transfer-Encoding: base64

RXhwb3NlIHRzYyBhZGp1c3QgdG8gaHZtIGd1ZXN0CgpJbnRlbCBsYXRlc3QgU0RNICgxNy4xMy4z
KSByZWxlYXNlIGEgbmV3IE1TUgpDUFVJRC43LjAuRUJYWzFdPTEgaW5kaWNhdGVzIFRTQ19BREpV
U1QgTVNSIDB4M2IgaXMgc3VwcG9ydGVkLgoKVGhpcyBwYXRjaCBleHBvc2UgaXQgdG8gaHZtIGd1
ZXN0LgoKU2lnbmVkLW9mZi1ieTogTGl1LCBKaW5zb25nIDxqaW5zb25nLmxpdUBpbnRlbC5jb20+
CgpkaWZmIC1yIGE2ZDEyYTFiYzc1OCB0b29scy9saWJ4Yy94Y19jcHVmZWF0dXJlLmgKLS0tIGEv
dG9vbHMvbGlieGMveGNfY3B1ZmVhdHVyZS5oCVRodSBTZXAgMjAgMDA6MDM6MjUgMjAxMiArMDgw
MAorKysgYi90b29scy9saWJ4Yy94Y19jcHVmZWF0dXJlLmgJVGh1IFNlcCAyMCAyMTo1MDo1NSAy
MDEyICswODAwCkBAIC0xMjgsNiArMTI4LDcgQEAKIAogLyogSW50ZWwtZGVmaW5lZCBDUFUgZmVh
dHVyZXMsIENQVUlEIGxldmVsIDB4MDAwMDAwMDc6MCAoZWJ4KSAqLwogI2RlZmluZSBYODZfRkVB
VFVSRV9GU0dTQkFTRSAgICAgMCAvKiB7UkQsV1J9e0ZTLEdTfUJBU0UgaW5zdHJ1Y3Rpb25zICov
CisjZGVmaW5lIFg4Nl9GRUFUVVJFX1RTQ19BREpVU1QgICAxIC8qIFRzYyB0aHJlYWQgb2Zmc2V0
ICovCiAjZGVmaW5lIFg4Nl9GRUFUVVJFX0JNSTEgICAgICAgICAzIC8qIDFzdCBncm91cCBiaXQg
bWFuaXB1bGF0aW9uIGV4dGVuc2lvbnMgKi8KICNkZWZpbmUgWDg2X0ZFQVRVUkVfSExFICAgICAg
ICAgIDQgLyogSGFyZHdhcmUgTG9jayBFbGlzaW9uICovCiAjZGVmaW5lIFg4Nl9GRUFUVVJFX0FW
WDIgICAgICAgICA1IC8qIEFWWDIgaW5zdHJ1Y3Rpb25zICovCmRpZmYgLXIgYTZkMTJhMWJjNzU4
IHRvb2xzL2xpYnhjL3hjX2NwdWlkX3g4Ni5jCi0tLSBhL3Rvb2xzL2xpYnhjL3hjX2NwdWlkX3g4
Ni5jCVRodSBTZXAgMjAgMDA6MDM6MjUgMjAxMiArMDgwMAorKysgYi90b29scy9saWJ4Yy94Y19j
cHVpZF94ODYuYwlUaHUgU2VwIDIwIDIxOjUwOjU1IDIwMTIgKzA4MDAKQEAgLTM2Miw3ICszNjIs
OCBAQAogCiAgICAgY2FzZSAweDAwMDAwMDA3OiAvKiBJbnRlbC1kZWZpbmVkIENQVSBmZWF0dXJl
cyAqLwogICAgICAgICBpZiAoIGlucHV0WzFdID09IDAgKSB7Ci0gICAgICAgICAgICByZWdzWzFd
ICY9IChiaXRtYXNrb2YoWDg2X0ZFQVRVUkVfQk1JMSkgfAorICAgICAgICAgICAgcmVnc1sxXSAm
PSAoYml0bWFza29mKFg4Nl9GRUFUVVJFX1RTQ19BREpVU1QpIHwKKyAgICAgICAgICAgICAgICAg
ICAgICAgIGJpdG1hc2tvZihYODZfRkVBVFVSRV9CTUkxKSB8CiAgICAgICAgICAgICAgICAgICAg
ICAgICBiaXRtYXNrb2YoWDg2X0ZFQVRVUkVfSExFKSAgfAogICAgICAgICAgICAgICAgICAgICAg
ICAgYml0bWFza29mKFg4Nl9GRUFUVVJFX0FWWDIpIHwKICAgICAgICAgICAgICAgICAgICAgICAg
IGJpdG1hc2tvZihYODZfRkVBVFVSRV9TTUVQKSB8Cg==

--_002_DE8DF0795D48FD4CA783C40EC8292335331C73SHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 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_DE8DF0795D48FD4CA783C40EC8292335331C73SHSMSX101ccrcorpi_--


From xen-devel-bounces@lists.xen.org Thu Sep 20 08:57:37 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Sep 2012 08:57:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TEcZb-0003sZ-Gp; Thu, 20 Sep 2012 08:57:27 +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 1TEcZZ-0003sF-Q2
	for xen-devel@lists.xensource.com; Thu, 20 Sep 2012 08:57:25 +0000
Received: from [85.158.143.99:15423] by server-2.bemta-4.messagelabs.com id
	60/29-06610-57ADA505; Thu, 20 Sep 2012 08:57:25 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1348131443!24961616!1
X-Originating-IP: [143.182.124.21]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMjEgPT4gMjA1MTY3\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11139 invoked from network); 20 Sep 2012 08:57:24 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (143.182.124.21)
	by server-7.tower-216.messagelabs.com with SMTP;
	20 Sep 2012 08:57:24 -0000
Received: from azsmga002.ch.intel.com ([10.2.17.35])
	by azsmga101.ch.intel.com with ESMTP; 20 Sep 2012 01:57:23 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.80,453,1344236400"; d="scan'208";a="147075409"
Received: from fmsmsx106.amr.corp.intel.com ([10.19.9.37])
	by AZSMGA002.ch.intel.com with ESMTP; 20 Sep 2012 01:57:22 -0700
Received: from fmsmsx152.amr.corp.intel.com (10.19.17.221) by
	FMSMSX106.amr.corp.intel.com (10.19.9.37) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Thu, 20 Sep 2012 01:57:22 -0700
Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by
	fmsmsx152.amr.corp.intel.com (10.19.17.221) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Thu, 20 Sep 2012 01:57:21 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.239]) by
	SHSMSX102.ccr.corp.intel.com ([169.254.2.92]) with mapi id
	14.01.0355.002; Thu, 20 Sep 2012 16:57:20 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: Jan Beulich <JBeulich@suse.com>, Keir Fraser <keir@xen.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Thread-Topic: [PATCH 3/3] Expose tsc adjust to hvm guest
Thread-Index: Ac2XDe/GX7zN2TRuSJ2FgKsQftsNkw==
Date: Thu, 20 Sep 2012 08:57:19 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC8292335331C73@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_DE8DF0795D48FD4CA783C40EC8292335331C73SHSMSX101ccrcorpi_"
MIME-Version: 1.0
Subject: [Xen-devel] [PATCH 3/3] Expose tsc adjust to 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_DE8DF0795D48FD4CA783C40EC8292335331C73SHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Expose tsc adjust to hvm guest

Intel latest SDM (17.13.3) release a new MSR
CPUID.7.0.EBX[1]=3D1 indicates TSC_ADJUST MSR 0x3b is supported.

This patch expose it to hvm guest.

Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>

diff -r a6d12a1bc758 tools/libxc/xc_cpufeature.h
--- a/tools/libxc/xc_cpufeature.h	Thu Sep 20 00:03:25 2012 +0800
+++ b/tools/libxc/xc_cpufeature.h	Thu Sep 20 21:50:55 2012 +0800
@@ -128,6 +128,7 @@
=20
 /* Intel-defined CPU features, CPUID level 0x00000007:0 (ebx) */
 #define X86_FEATURE_FSGSBASE     0 /* {RD,WR}{FS,GS}BASE instructions */
+#define X86_FEATURE_TSC_ADJUST   1 /* Tsc thread offset */
 #define X86_FEATURE_BMI1         3 /* 1st group bit manipulation extension=
s */
 #define X86_FEATURE_HLE          4 /* Hardware Lock Elision */
 #define X86_FEATURE_AVX2         5 /* AVX2 instructions */
diff -r a6d12a1bc758 tools/libxc/xc_cpuid_x86.c
--- a/tools/libxc/xc_cpuid_x86.c	Thu Sep 20 00:03:25 2012 +0800
+++ b/tools/libxc/xc_cpuid_x86.c	Thu Sep 20 21:50:55 2012 +0800
@@ -362,7 +362,8 @@
=20
     case 0x00000007: /* Intel-defined CPU features */
         if ( input[1] =3D=3D 0 ) {
-            regs[1] &=3D (bitmaskof(X86_FEATURE_BMI1) |
+            regs[1] &=3D (bitmaskof(X86_FEATURE_TSC_ADJUST) |
+                        bitmaskof(X86_FEATURE_BMI1) |
                         bitmaskof(X86_FEATURE_HLE)  |
                         bitmaskof(X86_FEATURE_AVX2) |
                         bitmaskof(X86_FEATURE_SMEP) |=

--_002_DE8DF0795D48FD4CA783C40EC8292335331C73SHSMSX101ccrcorpi_
Content-Type: application/octet-stream; name="tsc_adjust_3.patch"
Content-Description: tsc_adjust_3.patch
Content-Disposition: attachment; filename="tsc_adjust_3.patch"; size=1456;
	creation-date="Thu, 20 Sep 2012 08:50:31 GMT";
	modification-date="Thu, 20 Sep 2012 16:31:00 GMT"
Content-Transfer-Encoding: base64

RXhwb3NlIHRzYyBhZGp1c3QgdG8gaHZtIGd1ZXN0CgpJbnRlbCBsYXRlc3QgU0RNICgxNy4xMy4z
KSByZWxlYXNlIGEgbmV3IE1TUgpDUFVJRC43LjAuRUJYWzFdPTEgaW5kaWNhdGVzIFRTQ19BREpV
U1QgTVNSIDB4M2IgaXMgc3VwcG9ydGVkLgoKVGhpcyBwYXRjaCBleHBvc2UgaXQgdG8gaHZtIGd1
ZXN0LgoKU2lnbmVkLW9mZi1ieTogTGl1LCBKaW5zb25nIDxqaW5zb25nLmxpdUBpbnRlbC5jb20+
CgpkaWZmIC1yIGE2ZDEyYTFiYzc1OCB0b29scy9saWJ4Yy94Y19jcHVmZWF0dXJlLmgKLS0tIGEv
dG9vbHMvbGlieGMveGNfY3B1ZmVhdHVyZS5oCVRodSBTZXAgMjAgMDA6MDM6MjUgMjAxMiArMDgw
MAorKysgYi90b29scy9saWJ4Yy94Y19jcHVmZWF0dXJlLmgJVGh1IFNlcCAyMCAyMTo1MDo1NSAy
MDEyICswODAwCkBAIC0xMjgsNiArMTI4LDcgQEAKIAogLyogSW50ZWwtZGVmaW5lZCBDUFUgZmVh
dHVyZXMsIENQVUlEIGxldmVsIDB4MDAwMDAwMDc6MCAoZWJ4KSAqLwogI2RlZmluZSBYODZfRkVB
VFVSRV9GU0dTQkFTRSAgICAgMCAvKiB7UkQsV1J9e0ZTLEdTfUJBU0UgaW5zdHJ1Y3Rpb25zICov
CisjZGVmaW5lIFg4Nl9GRUFUVVJFX1RTQ19BREpVU1QgICAxIC8qIFRzYyB0aHJlYWQgb2Zmc2V0
ICovCiAjZGVmaW5lIFg4Nl9GRUFUVVJFX0JNSTEgICAgICAgICAzIC8qIDFzdCBncm91cCBiaXQg
bWFuaXB1bGF0aW9uIGV4dGVuc2lvbnMgKi8KICNkZWZpbmUgWDg2X0ZFQVRVUkVfSExFICAgICAg
ICAgIDQgLyogSGFyZHdhcmUgTG9jayBFbGlzaW9uICovCiAjZGVmaW5lIFg4Nl9GRUFUVVJFX0FW
WDIgICAgICAgICA1IC8qIEFWWDIgaW5zdHJ1Y3Rpb25zICovCmRpZmYgLXIgYTZkMTJhMWJjNzU4
IHRvb2xzL2xpYnhjL3hjX2NwdWlkX3g4Ni5jCi0tLSBhL3Rvb2xzL2xpYnhjL3hjX2NwdWlkX3g4
Ni5jCVRodSBTZXAgMjAgMDA6MDM6MjUgMjAxMiArMDgwMAorKysgYi90b29scy9saWJ4Yy94Y19j
cHVpZF94ODYuYwlUaHUgU2VwIDIwIDIxOjUwOjU1IDIwMTIgKzA4MDAKQEAgLTM2Miw3ICszNjIs
OCBAQAogCiAgICAgY2FzZSAweDAwMDAwMDA3OiAvKiBJbnRlbC1kZWZpbmVkIENQVSBmZWF0dXJl
cyAqLwogICAgICAgICBpZiAoIGlucHV0WzFdID09IDAgKSB7Ci0gICAgICAgICAgICByZWdzWzFd
ICY9IChiaXRtYXNrb2YoWDg2X0ZFQVRVUkVfQk1JMSkgfAorICAgICAgICAgICAgcmVnc1sxXSAm
PSAoYml0bWFza29mKFg4Nl9GRUFUVVJFX1RTQ19BREpVU1QpIHwKKyAgICAgICAgICAgICAgICAg
ICAgICAgIGJpdG1hc2tvZihYODZfRkVBVFVSRV9CTUkxKSB8CiAgICAgICAgICAgICAgICAgICAg
ICAgICBiaXRtYXNrb2YoWDg2X0ZFQVRVUkVfSExFKSAgfAogICAgICAgICAgICAgICAgICAgICAg
ICAgYml0bWFza29mKFg4Nl9GRUFUVVJFX0FWWDIpIHwKICAgICAgICAgICAgICAgICAgICAgICAg
IGJpdG1hc2tvZihYODZfRkVBVFVSRV9TTUVQKSB8Cg==

--_002_DE8DF0795D48FD4CA783C40EC8292335331C73SHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 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_DE8DF0795D48FD4CA783C40EC8292335331C73SHSMSX101ccrcorpi_--


From xen-devel-bounces@lists.xen.org Thu Sep 20 09:04:49 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Sep 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 1TEcga-0004Y5-71; Thu, 20 Sep 2012 09:04:40 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jinsong.liu@intel.com>) id 1TEcgZ-0004Xs-4h
	for xen-devel@lists.xensource.com; Thu, 20 Sep 2012 09:04:39 +0000
Received: from [85.158.139.211:63883] by server-3.bemta-5.messagelabs.com id
	3B/CB-21836-52CDA505; Thu, 20 Sep 2012 09:04:37 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-10.tower-206.messagelabs.com!1348131876!19254162!1
X-Originating-IP: [192.55.52.88]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjg4ID0+IDMyMjA5OQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22578 invoked from network); 20 Sep 2012 09:04:36 -0000
Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88)
	by server-10.tower-206.messagelabs.com with SMTP;
	20 Sep 2012 09:04:36 -0000
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
	by fmsmga101.fm.intel.com with ESMTP; 20 Sep 2012 02:04:35 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.80,453,1344236400"; d="scan'208";a="224353443"
Received: from fmsmsx103.amr.corp.intel.com ([10.19.9.34])
	by fmsmga001.fm.intel.com with ESMTP; 20 Sep 2012 02:04:34 -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, 20 Sep 2012 02:04:34 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.239]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.175]) with mapi id
	14.01.0355.002; Thu, 20 Sep 2012 17:04:33 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: Keir Fraser <keir@xen.org>, Jan Beulich <JBeulich@suse.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Thread-Topic: [PATCH 0/3] tsc adjust implementation for hvm
Thread-Index: Ac2XBtJ3RWSMroowQbKXJZr90iOO2QAAXGKjAAFteHA=
Date: Thu, 20 Sep 2012 09:04:33 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC8292335331CBE@SHSMSX101.ccr.corp.intel.com>
References: <DE8DF0795D48FD4CA783C40EC8292335331A65@SHSMSX101.ccr.corp.intel.com>
	<CC808F7A.4C812%keir@xen.org>
In-Reply-To: <CC808F7A.4C812%keir@xen.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Subject: Re: [Xen-devel] [PATCH 0/3] tsc adjust implementation for hvm
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Keir Fraser wrote:
> On 20/09/2012 09:06, "Liu, Jinsong" <jinsong.liu@intel.com> wrote:
> 
>> Intel recently release a new tsc adjust feature at latest SDM
>> 17.13.3. CPUID.7.0.EBX[1]=1 indicates TSC_ADJUST MSR 0x3b is
>> supported. 
>> 
>> Basically it is used to simplify TSC synchronization, operation of
>> IA32_TSC_ADJUST MSR is as follows:
>> 1). On RESET, the value of the IA32_TSC_ADJUST MSR is 0;
>> 2). If an execution of WRMSR to the IA32_TIME_STAMP_COUNTER MSR adds
>>     (or subtracts) value X from the TSC, the logical processor also
>>     adds (or subtracts) value X from the IA32_TSC_ADJUST MSR;
>> 3). If an execution of WRMSR to the IA32_TSC_ADJUST MSR adds (or
>>     subtracts) value X from that MSR, the logical processor also
>>     adds (or subtracts) value X from the TSC;
>> 
>> With it, OS would be easier when sync tsc.
> 
> Actually it appears to strictly add code to, and hence complicate, the
> hypervisor. So how exactly is it beneficial?
> 
>  -- Keir
> 

The benefit of these patches are for hvm guest.

The comments in SDM may best explain why guest like the feature:
===================
Software can modify the value of the time-stamp counter (TSC) of a logical processor by using the WRMSR instruction
to write to the IA32_TIME_STAMP_COUNTER MSR (address 10H). Because such a write applies only to that
logical processor, software seeking to synchronize the TSC values of multiple logical processors must perform these
writes on each logical processor. It may be difficult for software to do this in a way than ensures that all logical
processors will have the same value for the TSC at a given point in time.
===================

IMO tsc adjust provide another way to update tsc, but better than directly update IA32_TIME_STAMP_COUNTER MSR, since with tsc adjust logical processor can individually adjust tsc on its convenient time.

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 Sep 20 09:04:49 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Sep 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 1TEcga-0004Y5-71; Thu, 20 Sep 2012 09:04:40 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jinsong.liu@intel.com>) id 1TEcgZ-0004Xs-4h
	for xen-devel@lists.xensource.com; Thu, 20 Sep 2012 09:04:39 +0000
Received: from [85.158.139.211:63883] by server-3.bemta-5.messagelabs.com id
	3B/CB-21836-52CDA505; Thu, 20 Sep 2012 09:04:37 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-10.tower-206.messagelabs.com!1348131876!19254162!1
X-Originating-IP: [192.55.52.88]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjg4ID0+IDMyMjA5OQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22578 invoked from network); 20 Sep 2012 09:04:36 -0000
Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88)
	by server-10.tower-206.messagelabs.com with SMTP;
	20 Sep 2012 09:04:36 -0000
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
	by fmsmga101.fm.intel.com with ESMTP; 20 Sep 2012 02:04:35 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.80,453,1344236400"; d="scan'208";a="224353443"
Received: from fmsmsx103.amr.corp.intel.com ([10.19.9.34])
	by fmsmga001.fm.intel.com with ESMTP; 20 Sep 2012 02:04:34 -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, 20 Sep 2012 02:04:34 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.239]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.175]) with mapi id
	14.01.0355.002; Thu, 20 Sep 2012 17:04:33 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: Keir Fraser <keir@xen.org>, Jan Beulich <JBeulich@suse.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Thread-Topic: [PATCH 0/3] tsc adjust implementation for hvm
Thread-Index: Ac2XBtJ3RWSMroowQbKXJZr90iOO2QAAXGKjAAFteHA=
Date: Thu, 20 Sep 2012 09:04:33 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC8292335331CBE@SHSMSX101.ccr.corp.intel.com>
References: <DE8DF0795D48FD4CA783C40EC8292335331A65@SHSMSX101.ccr.corp.intel.com>
	<CC808F7A.4C812%keir@xen.org>
In-Reply-To: <CC808F7A.4C812%keir@xen.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Subject: Re: [Xen-devel] [PATCH 0/3] tsc adjust implementation for hvm
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Keir Fraser wrote:
> On 20/09/2012 09:06, "Liu, Jinsong" <jinsong.liu@intel.com> wrote:
> 
>> Intel recently release a new tsc adjust feature at latest SDM
>> 17.13.3. CPUID.7.0.EBX[1]=1 indicates TSC_ADJUST MSR 0x3b is
>> supported. 
>> 
>> Basically it is used to simplify TSC synchronization, operation of
>> IA32_TSC_ADJUST MSR is as follows:
>> 1). On RESET, the value of the IA32_TSC_ADJUST MSR is 0;
>> 2). If an execution of WRMSR to the IA32_TIME_STAMP_COUNTER MSR adds
>>     (or subtracts) value X from the TSC, the logical processor also
>>     adds (or subtracts) value X from the IA32_TSC_ADJUST MSR;
>> 3). If an execution of WRMSR to the IA32_TSC_ADJUST MSR adds (or
>>     subtracts) value X from that MSR, the logical processor also
>>     adds (or subtracts) value X from the TSC;
>> 
>> With it, OS would be easier when sync tsc.
> 
> Actually it appears to strictly add code to, and hence complicate, the
> hypervisor. So how exactly is it beneficial?
> 
>  -- Keir
> 

The benefit of these patches are for hvm guest.

The comments in SDM may best explain why guest like the feature:
===================
Software can modify the value of the time-stamp counter (TSC) of a logical processor by using the WRMSR instruction
to write to the IA32_TIME_STAMP_COUNTER MSR (address 10H). Because such a write applies only to that
logical processor, software seeking to synchronize the TSC values of multiple logical processors must perform these
writes on each logical processor. It may be difficult for software to do this in a way than ensures that all logical
processors will have the same value for the TSC at a given point in time.
===================

IMO tsc adjust provide another way to update tsc, but better than directly update IA32_TIME_STAMP_COUNTER MSR, since with tsc adjust logical processor can individually adjust tsc on its convenient time.

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 Sep 20 09:11:53 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Sep 2012 09:11: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 1TEcnM-0004pM-3m; Thu, 20 Sep 2012 09:11:40 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1TEcnK-0004pD-Cu
	for xen-devel@lists.xen.org; Thu, 20 Sep 2012 09:11:38 +0000
Received: from [85.158.143.99:57756] by server-1.bemta-4.messagelabs.com id
	D6/44-05684-9CDDA505; Thu, 20 Sep 2012 09:11:37 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1348132292!30179940!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23162 invoked from network); 20 Sep 2012 09:11:33 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-13.tower-216.messagelabs.com with SMTP;
	20 Sep 2012 09:11:33 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 20 Sep 2012 10:11:32 +0100
Message-Id: <505AF9F6020000780009C909@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 20 Sep 2012 10:11:50 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Oliver Chick" <oliver.chick@citrix.com>
References: <1348051887-21885-1-git-send-email-oliver.chick@citrix.com>
	<5059D0C8020000780009C4CF@nat28.tlf.novell.com>
	<1348131088.24539.2.camel@oliverchick-Precision-WorkStation-T3400>
In-Reply-To: <1348131088.24539.2.camel@oliverchick-Precision-WorkStation-T3400>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] Persistent grant maps for xen blk drivers
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 20.09.12 at 10:51, Oliver Chick <oliver.chick@citrix.com> wrote:
> Ah yes, you're right - rings can accomodate 64 requests. ijc, and myself
> got muddled. It also explains the comment in my summary that we only use
> the first 60-ish persistent grants!
> 
> With multipage rings, this will probably become a function, rather than
> a constant. Does that sound sensible?

Yes, that's what I was expecting. Whether a separate function/
macro is necessary is unclear, as it's simply __RING_SIZE().

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 20 09:11:53 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Sep 2012 09:11: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 1TEcnM-0004pM-3m; Thu, 20 Sep 2012 09:11:40 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1TEcnK-0004pD-Cu
	for xen-devel@lists.xen.org; Thu, 20 Sep 2012 09:11:38 +0000
Received: from [85.158.143.99:57756] by server-1.bemta-4.messagelabs.com id
	D6/44-05684-9CDDA505; Thu, 20 Sep 2012 09:11:37 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1348132292!30179940!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23162 invoked from network); 20 Sep 2012 09:11:33 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-13.tower-216.messagelabs.com with SMTP;
	20 Sep 2012 09:11:33 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 20 Sep 2012 10:11:32 +0100
Message-Id: <505AF9F6020000780009C909@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 20 Sep 2012 10:11:50 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Oliver Chick" <oliver.chick@citrix.com>
References: <1348051887-21885-1-git-send-email-oliver.chick@citrix.com>
	<5059D0C8020000780009C4CF@nat28.tlf.novell.com>
	<1348131088.24539.2.camel@oliverchick-Precision-WorkStation-T3400>
In-Reply-To: <1348131088.24539.2.camel@oliverchick-Precision-WorkStation-T3400>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] Persistent grant maps for xen blk drivers
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 20.09.12 at 10:51, Oliver Chick <oliver.chick@citrix.com> wrote:
> Ah yes, you're right - rings can accomodate 64 requests. ijc, and myself
> got muddled. It also explains the comment in my summary that we only use
> the first 60-ish persistent grants!
> 
> With multipage rings, this will probably become a function, rather than
> a constant. Does that sound sensible?

Yes, that's what I was expecting. Whether a separate function/
macro is necessary is unclear, as it's simply __RING_SIZE().

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 20 09:36:21 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Sep 2012 09:36:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TEdAx-00054y-99; Thu, 20 Sep 2012 09:36:03 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <oliver.chick@citrix.com>) id 1TEdAw-00054t-1b
	for xen-devel@lists.xen.org; Thu, 20 Sep 2012 09:36:02 +0000
Received: from [85.158.139.211:37512] by server-10.bemta-5.messagelabs.com id
	2E/2F-10969-183EA505; Thu, 20 Sep 2012 09:36:01 +0000
X-Env-Sender: oliver.chick@citrix.com
X-Msg-Ref: server-10.tower-206.messagelabs.com!1348133760!19259296!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTA0NTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18724 invoked from network); 20 Sep 2012 09:36:00 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Sep 2012 09:36:00 -0000
X-IronPort-AV: E=Sophos;i="4.80,453,1344211200"; 
	d="pdf'?scan'208";a="14650150"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Sep 2012 09:36:00 +0000
Received: from [10.80.2.50] (10.80.2.50) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Thu, 20 Sep 2012 10:36:00 +0100
Message-ID: <1348133733.24539.8.camel@oliverchick-Precision-WorkStation-T3400>
From: Oliver Chick <oliver.chick@citrix.com>
To: Pasi =?ISO-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
Date: Thu, 20 Sep 2012 10:35:33 +0100
In-Reply-To: <20120919131632.GS8912@reaktio.net>
References: <1348051887-21885-1-git-send-email-oliver.chick@citrix.com>
	<20120919131632.GS8912@reaktio.net>
Content-Type: multipart/mixed; boundary="=-WTNocMG3YNTG0rOLTsJV"
X-Mailer: Evolution 3.2.3-0ubuntu6 
MIME-Version: 1.0
Cc: "konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] Persistent grant maps for xen blk drivers
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--=-WTNocMG3YNTG0rOLTsJV
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit

I have attached a graph that shows the results of my benchmarking.

The setup is:
-Xeon X5650
-32GB of Ram
-Xen 4.2
-Linux 3.5.0 for dom0 and domus
-Dom0 has 24 CPUs.
-Each guest has a (separate) xvdb backed by a 1GB ramdisk (/dev/ramX) in
dom0. No LVM on these.
-The setup is that initially 1 guest does an fio sequential read of the
ramdisk, then 2, then 3 etc.
-The y axis is the sum of the iops, as reported by the guests' fio
output.

On Wed, 2012-09-19 at 14:16 +0100, X5650Pasi Kärkkäinen wrote:
> On Wed, Sep 19, 2012 at 11:51:27AM +0100, Oliver Chick wrote:
> > This patch implements persistent grants for the xen-blk{front,back}
> > mechanism. The effect of this change is to reduce the number of unmap
> > operations performed, since they cause a (costly) TLB shootdown. This
> > allows the I/O performance to scale better when a large number of VMs
> > are performing I/O.
> > 
> > Previously, the blkfront driver was supplied a bvec[] from the request
> > queue. This was granted to dom0; dom0 performed the I/O and wrote
> > directly into the grant-mapped memory and unmapped it; blkfront then
> > removed foreign access for that grant. The cost of unmapping scales
> > badly with the number of CPUs in Dom0. An experiment showed that when
> > Dom0 has 24 VCPUs, and guests are performing parallel I/O to a
> > ramdisk, the IPIs from performing unmap's is a bottleneck at 5 guests
> > (at which point 650,000 IOPS are being performed in total). If more
> > than 5 guests are used, the performance declines. By 10 guests, only
> > 400,000 IOPS are being performed.
> > 
> > This patch improves performance by only unmapping when the connection
> > between blkfront and back is broken.
> >
> 
> So how many IOPS can you get with this patch / persistent grants ? 
> 
> -- Pasi
> 


--=-WTNocMG3YNTG0rOLTsJV
Content-Type: application/pdf; name="pers-vs-nonpers.pdf"
Content-Disposition: attachment; filename="pers-vs-nonpers.pdf"
Content-Transfer-Encoding: base64

JVBERi0xLjQKJYHigeOBz4HTXHIKMSAwIG9iago8PAovQ3JlYXRpb25EYXRlIChEOjIwMTIwOTIw
MTAyODI2KQovTW9kRGF0ZSAoRDoyMDEyMDkyMDEwMjgyNikKL1RpdGxlIChSIEdyYXBoaWNzIE91
dHB1dCkKL1Byb2R1Y2VyIChSIDIuMTQuMSkKL0NyZWF0b3IgKFIpCj4+CmVuZG9iagoyIDAgb2Jq
Cjw8IC9UeXBlIC9DYXRhbG9nIC9QYWdlcyAzIDAgUiA+PgplbmRvYmoKNyAwIG9iago8PCAvVHlw
ZSAvUGFnZSAvUGFyZW50IDMgMCBSIC9Db250ZW50cyA4IDAgUiAvUmVzb3VyY2VzIDQgMCBSID4+
CmVuZG9iago4IDAgb2JqCjw8Ci9MZW5ndGggMTE2NCAvRmlsdGVyIC9GbGF0ZURlY29kZQo+Pgpz
dHJlYW0KeJy1V01vHDcMvc+v0NE+WBFJSZy5JmgKGEiA1ov2EOSUuE0Mb+x4HfTv95HSjCeukWQn
aIDY+5akPh4p8pnCeaBwFT4Pv4XPoUwx5aAScw6ZclQOohQLh7vL8Gf4NDw7/P7r8/DiYkgxpRTW
Py9evMa3WsI/w5u3IYX3A4Vz/L8ayBzCq+H5bnj2krDd7i/7cRc05hGeqX3ARtiWSKNq2O3DyfVp
2F3Bursbftl9L3ocI0mgPEaZjo+mlOOIcMUqeUM4gyQJnCbj6vhwGSNzYClR6obwkuOE8MpxpA3h
IL5S4FEibwkH80JBkkYqx4dzKlYdwmMsG9LOYF4Rnr1Yjw8XrxcpGuuWwxccHuGa4rQhcQzmFeE1
W/qPDwfz+CW1xLKh5gXMk4WrJeD4cDA/KsK3JU7E42Rj0QqY5+rhvOHBWlebLFxilQ3hYL5WZ37L
g81gXoofnraEM8eE8FI3dZsM5jUjfIqy4e4ZzGcLz1a7/w3HHPm5MUGZrC7bFNoHmdCeuMPrcPHY
3mGtVghmZ86WnNne4YNdkjf5Zf0GV/b1hsv+D3bjx+/37vDE/Q7vMCVfcqePYzeEM//ZviDROJaQ
dc5fMQYX7r8dzBiQ07QKpnREtCRMWV1HH7O3jJg064PzsneTDqNGTiCtoSxk0Eh7ZEbrmNGDlZN3
lNnc4YNdqNqUne0dPtj7drN9tfv6aqvrnK2uiSrSGjADx/YinyT1m7E0kmXV85ns39Er8CRWyi2p
25bISedD0NenWGu7/ZDxQedHcj3DjDGKtng9E/o1nJ0v/I3/yDOQXk35cTX5F8woANRinWL2I785
2X24O0Xiw8nNl78/3H65P30bduc/+jAyhrGlYVYCr2/CH68OR1CIj7guQ0NyG4gfb26X+P9fH0NF
FNOSIIdRxeqisEOrYs0x2yFTq/IZqhW72e09mRpUW2YfJiSPZmh2NDJCQPFUw95gJVvGG2uSOGkg
M5gDkQvDjpuHWtMn7CTeezu2rdoedrqqaFLOCjzY1WHHzQPnnpBkNeG2DzOmYmu6B9ojxipLjsXP
kV0idrwaASzJJtkyA1zN9XNgPKW2BgTa3q+pacbNA8S1NdiazoLVaHMPJMReJfpMdQ91sdhx88gm
YhiFg0dnHg2DhNx3AVUoblO55LedXDF27B6gFwewbseje3Q8mqj3gYY/TiCtjWUyTo1MHWfcPLRl
LkWxXRaMX/NQTFYmhAauo0/FsYl3x6uxSaNr2WVumryv7aRGTcEaqH9xD+SFdMbugTzgI+FFF5+9
HataetwDeeH2h1byc1Rv8h03j9HUjVHJvkvH1l0bp2xyW3xfdT7UpWTHzSPbS7NzTM5Hx+oXcA/k
pbY1Jl9jcj3ZsXtM7e9RbOaZWzDqVrqQyFHwQrXGbGNJyEVlxyupQcomIRatYRxzWU+u1mh1sqd+
lsUeODrKxQDVgW8yatRfAk6HlHRo4bigTTqu7R10iCLvz+A7Wg7Lo+Qzia33tBL8OaWDi9Z2Pm5D
6eb6/RF6o4fTMlhvL+8OHw/3l5/ul7Y8/AtaU3BbZW5kc3RyZWFtCmVuZG9iagozIDAgb2JqCjw8
IC9UeXBlIC9QYWdlcyAvS2lkcyBbIDcgMCBSIF0gL0NvdW50IDEgL01lZGlhQm94IFswIDAgNTA0
IDUwNF0gPj4KZW5kb2JqCjQgMCBvYmoKPDwKL1Byb2NTZXQgWy9QREYgL1RleHRdCi9Gb250IDw8
IC9GMSAxMCAwIFIgL0YyIDExIDAgUiAvRjMgMTIgMCBSID4+Ci9FeHRHU3RhdGUgPDwgPj4KL0Nv
bG9yU3BhY2UgPDwgL3NSR0IgNSAwIFIgPj4KPj4KZW5kb2JqCjUgMCBvYmoKWy9JQ0NCYXNlZCA2
IDAgUl0KZW5kb2JqCjYgMCBvYmoKPDwgL0FsdGVybmF0ZSAvRGV2aWNlUkdCIC9OIDMgL0xlbmd0
aCAyNTk2IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+CnN0cmVhbQp4nJ2Wd1RT2RaHz703vVCSEIqU
0GtoUgJIDb1IkS4qMQkQSsCQACI2RFRwRFGRpggyKOCAo0ORsSKKhQFRsesEGUTUcXAUG5ZJZK0Z
37x5782b3x/3fmufvc/dZ+991roAkPyDBcJMWAmADKFYFOHnxYiNi2dgBwEM8AADbADgcLOzQhb4
RgKZAnzYjGyZE/gXvboOIPn7KtM/jMEA/5+UuVkiMQBQmIzn8vjZXBkXyTg9V5wlt0/JmLY0Tc4w
Ss4iWYIyVpNz8ixbfPaZZQ858zKEPBnLc87iZfDk3CfjjTkSvoyRYBkX5wj4uTK+JmODdEmGQMZv
5LEZfE42ACiS3C7mc1NkbC1jkigygi3jeQDgSMlf8NIvWMzPE8sPxc7MWi4SJKeIGSZcU4aNkxOL
4c/PTeeLxcwwDjeNI+Ix2JkZWRzhcgBmz/xZFHltGbIiO9g4OTgwbS1tvijUf138m5L3dpZehH/u
GUQf+MP2V36ZDQCwpmW12fqHbWkVAF3rAVC7/YfNYC8AirK+dQ59cR66fF5SxOIsZyur3NxcSwGf
aykv6O/6nw5/Q198z1K+3e/lYXjzkziSdDFDXjduZnqmRMTIzuJw+Qzmn4f4Hwf+dR4WEfwkvogv
lEVEy6ZMIEyWtVvIE4gFmUKGQPifmvgPw/6k2bmWidr4EdCWWAKlIRpAfh4AKCoRIAl7ZCvQ730L
xkcD+c2L0ZmYnfvPgv59V7hM/sgWJH+OY0dEMrgSUc7smvxaAjQgAEVAA+pAG+gDE8AEtsARuAAP
4AMCQSiIBHFgMeCCFJABRCAXFIC1oBiUgq1gJ6gGdaARNIM2cBh0gWPgNDgHLoHLYATcAVIwDp6A
KfAKzEAQhIXIEBVSh3QgQ8gcsoVYkBvkAwVDEVAclAglQ0JIAhVA66BSqByqhuqhZuhb6Ch0GroA
DUO3oFFoEvoVegcjMAmmwVqwEWwFs2BPOAiOhBfByfAyOB8ugrfAlXADfBDuhE/Dl+ARWAo/gacR
gBAROqKLMBEWwkZCkXgkCREhq5ASpAJpQNqQHqQfuYpIkafIWxQGRUUxUEyUC8ofFYXiopahVqE2
o6pRB1CdqD7UVdQoagr1EU1Ga6LN0c7oAHQsOhmdiy5GV6Cb0B3os+gR9Dj6FQaDoWOMMY4Yf0wc
JhWzArMZsxvTjjmFGcaMYaaxWKw61hzrig3FcrBibDG2CnsQexJ7BTuOfYMj4nRwtjhfXDxOiCvE
VeBacCdwV3ATuBm8Et4Q74wPxfPwy/Fl+EZ8D34IP46fISgTjAmuhEhCKmEtoZLQRjhLuEt4QSQS
9YhOxHCigLiGWEk8RDxPHCW+JVFIZiQ2KYEkIW0h7SedIt0ivSCTyUZkD3I8WUzeQm4mnyHfJ79R
oCpYKgQo8BRWK9QodCpcUXimiFc0VPRUXKyYr1iheERxSPGpEl7JSImtxFFapVSjdFTphtK0MlXZ
RjlUOUN5s3KL8gXlRxQsxYjiQ+FRiij7KGcoY1SEqk9lU7nUddRG6lnqOA1DM6YF0FJppbRvaIO0
KRWKip1KtEqeSo3KcRUpHaEb0QPo6fQy+mH6dfo7VS1VT1W+6ibVNtUrqq/V5qh5qPHVStTa1UbU
3qkz1H3U09S3qXep39NAaZhphGvkauzROKvxdA5tjssc7pySOYfn3NaENc00IzRXaO7THNCc1tLW
8tPK0qrSOqP1VJuu7aGdqr1D+4T2pA5Vx01HoLND56TOY4YKw5ORzqhk9DGmdDV1/XUluvW6g7oz
esZ6UXqFeu169/QJ+iz9JP0d+r36UwY6BiEGBQatBrcN8YYswxTDXYb9hq+NjI1ijDYYdRk9MlYz
DjDON241vmtCNnE3WWbSYHLNFGPKMk0z3W162Qw2szdLMasxGzKHzR3MBea7zYct0BZOFkKLBosb
TBLTk5nDbGWOWtItgy0LLbssn1kZWMVbbbPqt/pobW+dbt1ofceGYhNoU2jTY/OrrZkt17bG9tpc
8lzfuavnds99bmdux7fbY3fTnmofYr/Bvtf+g4Ojg8ihzWHS0cAx0bHW8QaLxgpjbWadd0I7eTmt
djrm9NbZwVnsfNj5FxemS5pLi8ujecbz+PMa54256rlyXOtdpW4Mt0S3vW5Sd113jnuD+wMPfQ+e
R5PHhKepZ6rnQc9nXtZeIq8Or9dsZ/ZK9ilvxNvPu8R70IfiE+VT7XPfV8832bfVd8rP3m+F3yl/
tH+Q/zb/GwFaAdyA5oCpQMfAlYF9QaSgBUHVQQ+CzYJFwT0hcEhgyPaQu/MN5wvnd4WC0IDQ7aH3
wozDloV9H44JDwuvCX8YYRNRENG/gLpgyYKWBa8ivSLLIu9EmURJonqjFaMTopujX8d4x5THSGOt
YlfGXorTiBPEdcdj46Pjm+KnF/os3LlwPME+oTjh+iLjRXmLLizWWJy++PgSxSWcJUcS0YkxiS2J
7zmhnAbO9NKApbVLp7hs7i7uE54Hbwdvku/KL+dPJLkmlSc9SnZN3p48meKeUpHyVMAWVAuep/qn
1qW+TgtN25/2KT0mvT0Dl5GYcVRIEaYJ+zK1M/Myh7PMs4qzpMucl+1cNiUKEjVlQ9mLsrvFNNnP
1IDERLJeMprjllOT8yY3OvdInnKeMG9gudnyTcsn8n3zv16BWsFd0VugW7C2YHSl58r6VdCqpat6
V+uvLlo9vsZvzYG1hLVpa38otC4sL3y5LmZdT5FW0ZqisfV+61uLFYpFxTc2uGyo24jaKNg4uGnu
pqpNH0t4JRdLrUsrSt9v5m6++JXNV5VffdqStGWwzKFsz1bMVuHW69vctx0oVy7PLx/bHrK9cwdj
R8mOlzuX7LxQYVdRt4uwS7JLWhlc2V1lULW16n11SvVIjVdNe61m7aba17t5u6/s8djTVqdVV1r3
bq9g7816v/rOBqOGin2YfTn7HjZGN/Z/zfq6uUmjqbTpw37hfumBiAN9zY7NzS2aLWWtcKukdfJg
wsHL33h/093GbKtvp7eXHgKHJIcef5v47fXDQYd7j7COtH1n+F1tB7WjpBPqXN451ZXSJe2O6x4+
Gni0t8elp+N7y+/3H9M9VnNc5XjZCcKJohOfTuafnD6Vderp6eTTY71Leu+ciT1zrS+8b/Bs0Nnz
53zPnen37D953vX8sQvOF45eZF3suuRwqXPAfqDjB/sfOgYdBjuHHIe6Lztd7hmeN3ziivuV01e9
r567FnDt0sj8keHrUddv3ki4Ib3Ju/noVvqt57dzbs/cWXMXfbfkntK9ivua9xt+NP2xXeogPT7q
PTrwYMGDO2PcsSc/Zf/0frzoIflhxYTORPMj20fHJn0nLz9e+Hj8SdaTmafFPyv/XPvM5Nl3v3j8
MjAVOzX+XPT806+bX6i/2P/S7mXvdNj0/VcZr2Zel7xRf3PgLett/7uYdxMzue+x7ys/mH7o+Rj0
8e6njE+ffgP3hPP7ZW5kc3RyZWFtCmVuZG9iago5IDAgb2JqCjw8Ci9UeXBlIC9FbmNvZGluZyAv
QmFzZUVuY29kaW5nIC9XaW5BbnNpRW5jb2RpbmcKL0RpZmZlcmVuY2VzIFsgNDUvbWludXMgOTYv
cXVvdGVsZWZ0CjE0NC9kb3RsZXNzaSAvZ3JhdmUgL2FjdXRlIC9jaXJjdW1mbGV4IC90aWxkZSAv
bWFjcm9uIC9icmV2ZSAvZG90YWNjZW50Ci9kaWVyZXNpcyAvLm5vdGRlZiAvcmluZyAvY2VkaWxs
YSAvLm5vdGRlZiAvaHVuZ2FydW1sYXV0IC9vZ29uZWsgL2Nhcm9uIC9zcGFjZV0KPj4KZW5kb2Jq
CjEwIDAgb2JqCjw8IC9UeXBlIC9Gb250IC9TdWJ0eXBlIC9UeXBlMSAvTmFtZSAvRjEgL0Jhc2VG
b250IC9aYXBmRGluZ2JhdHMgPj4KZW5kb2JqCjExIDAgb2JqCjw8IC9UeXBlIC9Gb250IC9TdWJ0
eXBlIC9UeXBlMSAvTmFtZSAvRjIgL0Jhc2VGb250IC9IZWx2ZXRpY2EKL0VuY29kaW5nIDkgMCBS
ID4+CmVuZG9iagoxMiAwIG9iago8PCAvVHlwZSAvRm9udCAvU3VidHlwZSAvVHlwZTEgL05hbWUg
L0YzIC9CYXNlRm9udCAvSGVsdmV0aWNhLUJvbGQKL0VuY29kaW5nIDkgMCBSID4+CmVuZG9iagp4
cmVmCjAgMTMKMDAwMDAwMDAwMCA2NTUzNSBmIAowMDAwMDAwMDIxIDAwMDAwIG4gCjAwMDAwMDAx
NjQgMDAwMDAgbiAKMDAwMDAwMTUyOSAwMDAwMCBuIAowMDAwMDAxNjEyIDAwMDAwIG4gCjAwMDAw
MDE3NDcgMDAwMDAgbiAKMDAwMDAwMTc4MCAwMDAwMCBuIAowMDAwMDAwMjEzIDAwMDAwIG4gCjAw
MDAwMDAyOTMgMDAwMDAgbiAKMDAwMDAwNDQ3NSAwMDAwMCBuIAowMDAwMDA0NzMyIDAwMDAwIG4g
CjAwMDAwMDQ4MTYgMDAwMDAgbiAKMDAwMDAwNDkxMyAwMDAwMCBuIAp0cmFpbGVyCjw8IC9TaXpl
IDEzIC9JbmZvIDEgMCBSIC9Sb290IDIgMCBSID4+CnN0YXJ0eHJlZgo1MDE1CiUlRU9GCg==


--=-WTNocMG3YNTG0rOLTsJV
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--=-WTNocMG3YNTG0rOLTsJV--


From xen-devel-bounces@lists.xen.org Thu Sep 20 09:36:21 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Sep 2012 09:36:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TEdAx-00054y-99; Thu, 20 Sep 2012 09:36:03 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <oliver.chick@citrix.com>) id 1TEdAw-00054t-1b
	for xen-devel@lists.xen.org; Thu, 20 Sep 2012 09:36:02 +0000
Received: from [85.158.139.211:37512] by server-10.bemta-5.messagelabs.com id
	2E/2F-10969-183EA505; Thu, 20 Sep 2012 09:36:01 +0000
X-Env-Sender: oliver.chick@citrix.com
X-Msg-Ref: server-10.tower-206.messagelabs.com!1348133760!19259296!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTA0NTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18724 invoked from network); 20 Sep 2012 09:36:00 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Sep 2012 09:36:00 -0000
X-IronPort-AV: E=Sophos;i="4.80,453,1344211200"; 
	d="pdf'?scan'208";a="14650150"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Sep 2012 09:36:00 +0000
Received: from [10.80.2.50] (10.80.2.50) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Thu, 20 Sep 2012 10:36:00 +0100
Message-ID: <1348133733.24539.8.camel@oliverchick-Precision-WorkStation-T3400>
From: Oliver Chick <oliver.chick@citrix.com>
To: Pasi =?ISO-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
Date: Thu, 20 Sep 2012 10:35:33 +0100
In-Reply-To: <20120919131632.GS8912@reaktio.net>
References: <1348051887-21885-1-git-send-email-oliver.chick@citrix.com>
	<20120919131632.GS8912@reaktio.net>
Content-Type: multipart/mixed; boundary="=-WTNocMG3YNTG0rOLTsJV"
X-Mailer: Evolution 3.2.3-0ubuntu6 
MIME-Version: 1.0
Cc: "konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] Persistent grant maps for xen blk drivers
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--=-WTNocMG3YNTG0rOLTsJV
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit

I have attached a graph that shows the results of my benchmarking.

The setup is:
-Xeon X5650
-32GB of Ram
-Xen 4.2
-Linux 3.5.0 for dom0 and domus
-Dom0 has 24 CPUs.
-Each guest has a (separate) xvdb backed by a 1GB ramdisk (/dev/ramX) in
dom0. No LVM on these.
-The setup is that initially 1 guest does an fio sequential read of the
ramdisk, then 2, then 3 etc.
-The y axis is the sum of the iops, as reported by the guests' fio
output.

On Wed, 2012-09-19 at 14:16 +0100, X5650Pasi Kärkkäinen wrote:
> On Wed, Sep 19, 2012 at 11:51:27AM +0100, Oliver Chick wrote:
> > This patch implements persistent grants for the xen-blk{front,back}
> > mechanism. The effect of this change is to reduce the number of unmap
> > operations performed, since they cause a (costly) TLB shootdown. This
> > allows the I/O performance to scale better when a large number of VMs
> > are performing I/O.
> > 
> > Previously, the blkfront driver was supplied a bvec[] from the request
> > queue. This was granted to dom0; dom0 performed the I/O and wrote
> > directly into the grant-mapped memory and unmapped it; blkfront then
> > removed foreign access for that grant. The cost of unmapping scales
> > badly with the number of CPUs in Dom0. An experiment showed that when
> > Dom0 has 24 VCPUs, and guests are performing parallel I/O to a
> > ramdisk, the IPIs from performing unmap's is a bottleneck at 5 guests
> > (at which point 650,000 IOPS are being performed in total). If more
> > than 5 guests are used, the performance declines. By 10 guests, only
> > 400,000 IOPS are being performed.
> > 
> > This patch improves performance by only unmapping when the connection
> > between blkfront and back is broken.
> >
> 
> So how many IOPS can you get with this patch / persistent grants ? 
> 
> -- Pasi
> 


--=-WTNocMG3YNTG0rOLTsJV
Content-Type: application/pdf; name="pers-vs-nonpers.pdf"
Content-Disposition: attachment; filename="pers-vs-nonpers.pdf"
Content-Transfer-Encoding: base64

JVBERi0xLjQKJYHigeOBz4HTXHIKMSAwIG9iago8PAovQ3JlYXRpb25EYXRlIChEOjIwMTIwOTIw
MTAyODI2KQovTW9kRGF0ZSAoRDoyMDEyMDkyMDEwMjgyNikKL1RpdGxlIChSIEdyYXBoaWNzIE91
dHB1dCkKL1Byb2R1Y2VyIChSIDIuMTQuMSkKL0NyZWF0b3IgKFIpCj4+CmVuZG9iagoyIDAgb2Jq
Cjw8IC9UeXBlIC9DYXRhbG9nIC9QYWdlcyAzIDAgUiA+PgplbmRvYmoKNyAwIG9iago8PCAvVHlw
ZSAvUGFnZSAvUGFyZW50IDMgMCBSIC9Db250ZW50cyA4IDAgUiAvUmVzb3VyY2VzIDQgMCBSID4+
CmVuZG9iago4IDAgb2JqCjw8Ci9MZW5ndGggMTE2NCAvRmlsdGVyIC9GbGF0ZURlY29kZQo+Pgpz
dHJlYW0KeJy1V01vHDcMvc+v0NE+WBFJSZy5JmgKGEiA1ov2EOSUuE0Mb+x4HfTv95HSjCeukWQn
aIDY+5akPh4p8pnCeaBwFT4Pv4XPoUwx5aAScw6ZclQOohQLh7vL8Gf4NDw7/P7r8/DiYkgxpRTW
Py9evMa3WsI/w5u3IYX3A4Vz/L8ayBzCq+H5bnj2krDd7i/7cRc05hGeqX3ARtiWSKNq2O3DyfVp
2F3Bursbftl9L3ocI0mgPEaZjo+mlOOIcMUqeUM4gyQJnCbj6vhwGSNzYClR6obwkuOE8MpxpA3h
IL5S4FEibwkH80JBkkYqx4dzKlYdwmMsG9LOYF4Rnr1Yjw8XrxcpGuuWwxccHuGa4rQhcQzmFeE1
W/qPDwfz+CW1xLKh5gXMk4WrJeD4cDA/KsK3JU7E42Rj0QqY5+rhvOHBWlebLFxilQ3hYL5WZ37L
g81gXoofnraEM8eE8FI3dZsM5jUjfIqy4e4ZzGcLz1a7/w3HHPm5MUGZrC7bFNoHmdCeuMPrcPHY
3mGtVghmZ86WnNne4YNdkjf5Zf0GV/b1hsv+D3bjx+/37vDE/Q7vMCVfcqePYzeEM//ZviDROJaQ
dc5fMQYX7r8dzBiQ07QKpnREtCRMWV1HH7O3jJg064PzsneTDqNGTiCtoSxk0Eh7ZEbrmNGDlZN3
lNnc4YNdqNqUne0dPtj7drN9tfv6aqvrnK2uiSrSGjADx/YinyT1m7E0kmXV85ns39Er8CRWyi2p
25bISedD0NenWGu7/ZDxQedHcj3DjDGKtng9E/o1nJ0v/I3/yDOQXk35cTX5F8woANRinWL2I785
2X24O0Xiw8nNl78/3H65P30bduc/+jAyhrGlYVYCr2/CH68OR1CIj7guQ0NyG4gfb26X+P9fH0NF
FNOSIIdRxeqisEOrYs0x2yFTq/IZqhW72e09mRpUW2YfJiSPZmh2NDJCQPFUw95gJVvGG2uSOGkg
M5gDkQvDjpuHWtMn7CTeezu2rdoedrqqaFLOCjzY1WHHzQPnnpBkNeG2DzOmYmu6B9ojxipLjsXP
kV0idrwaASzJJtkyA1zN9XNgPKW2BgTa3q+pacbNA8S1NdiazoLVaHMPJMReJfpMdQ91sdhx88gm
YhiFg0dnHg2DhNx3AVUoblO55LedXDF27B6gFwewbseje3Q8mqj3gYY/TiCtjWUyTo1MHWfcPLRl
LkWxXRaMX/NQTFYmhAauo0/FsYl3x6uxSaNr2WVumryv7aRGTcEaqH9xD+SFdMbugTzgI+FFF5+9
HataetwDeeH2h1byc1Rv8h03j9HUjVHJvkvH1l0bp2xyW3xfdT7UpWTHzSPbS7NzTM5Hx+oXcA/k
pbY1Jl9jcj3ZsXtM7e9RbOaZWzDqVrqQyFHwQrXGbGNJyEVlxyupQcomIRatYRxzWU+u1mh1sqd+
lsUeODrKxQDVgW8yatRfAk6HlHRo4bigTTqu7R10iCLvz+A7Wg7Lo+Qzia33tBL8OaWDi9Z2Pm5D
6eb6/RF6o4fTMlhvL+8OHw/3l5/ul7Y8/AtaU3BbZW5kc3RyZWFtCmVuZG9iagozIDAgb2JqCjw8
IC9UeXBlIC9QYWdlcyAvS2lkcyBbIDcgMCBSIF0gL0NvdW50IDEgL01lZGlhQm94IFswIDAgNTA0
IDUwNF0gPj4KZW5kb2JqCjQgMCBvYmoKPDwKL1Byb2NTZXQgWy9QREYgL1RleHRdCi9Gb250IDw8
IC9GMSAxMCAwIFIgL0YyIDExIDAgUiAvRjMgMTIgMCBSID4+Ci9FeHRHU3RhdGUgPDwgPj4KL0Nv
bG9yU3BhY2UgPDwgL3NSR0IgNSAwIFIgPj4KPj4KZW5kb2JqCjUgMCBvYmoKWy9JQ0NCYXNlZCA2
IDAgUl0KZW5kb2JqCjYgMCBvYmoKPDwgL0FsdGVybmF0ZSAvRGV2aWNlUkdCIC9OIDMgL0xlbmd0
aCAyNTk2IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+CnN0cmVhbQp4nJ2Wd1RT2RaHz703vVCSEIqU
0GtoUgJIDb1IkS4qMQkQSsCQACI2RFRwRFGRpggyKOCAo0ORsSKKhQFRsesEGUTUcXAUG5ZJZK0Z
37x5782b3x/3fmufvc/dZ+991roAkPyDBcJMWAmADKFYFOHnxYiNi2dgBwEM8AADbADgcLOzQhb4
RgKZAnzYjGyZE/gXvboOIPn7KtM/jMEA/5+UuVkiMQBQmIzn8vjZXBkXyTg9V5wlt0/JmLY0Tc4w
Ss4iWYIyVpNz8ixbfPaZZQ858zKEPBnLc87iZfDk3CfjjTkSvoyRYBkX5wj4uTK+JmODdEmGQMZv
5LEZfE42ACiS3C7mc1NkbC1jkigygi3jeQDgSMlf8NIvWMzPE8sPxc7MWi4SJKeIGSZcU4aNkxOL
4c/PTeeLxcwwDjeNI+Ix2JkZWRzhcgBmz/xZFHltGbIiO9g4OTgwbS1tvijUf138m5L3dpZehH/u
GUQf+MP2V36ZDQCwpmW12fqHbWkVAF3rAVC7/YfNYC8AirK+dQ59cR66fF5SxOIsZyur3NxcSwGf
aykv6O/6nw5/Q198z1K+3e/lYXjzkziSdDFDXjduZnqmRMTIzuJw+Qzmn4f4Hwf+dR4WEfwkvogv
lEVEy6ZMIEyWtVvIE4gFmUKGQPifmvgPw/6k2bmWidr4EdCWWAKlIRpAfh4AKCoRIAl7ZCvQ730L
xkcD+c2L0ZmYnfvPgv59V7hM/sgWJH+OY0dEMrgSUc7smvxaAjQgAEVAA+pAG+gDE8AEtsARuAAP
4AMCQSiIBHFgMeCCFJABRCAXFIC1oBiUgq1gJ6gGdaARNIM2cBh0gWPgNDgHLoHLYATcAVIwDp6A
KfAKzEAQhIXIEBVSh3QgQ8gcsoVYkBvkAwVDEVAclAglQ0JIAhVA66BSqByqhuqhZuhb6Ch0GroA
DUO3oFFoEvoVegcjMAmmwVqwEWwFs2BPOAiOhBfByfAyOB8ugrfAlXADfBDuhE/Dl+ARWAo/gacR
gBAROqKLMBEWwkZCkXgkCREhq5ASpAJpQNqQHqQfuYpIkafIWxQGRUUxUEyUC8ofFYXiopahVqE2
o6pRB1CdqD7UVdQoagr1EU1Ga6LN0c7oAHQsOhmdiy5GV6Cb0B3os+gR9Dj6FQaDoWOMMY4Yf0wc
JhWzArMZsxvTjjmFGcaMYaaxWKw61hzrig3FcrBibDG2CnsQexJ7BTuOfYMj4nRwtjhfXDxOiCvE
VeBacCdwV3ATuBm8Et4Q74wPxfPwy/Fl+EZ8D34IP46fISgTjAmuhEhCKmEtoZLQRjhLuEt4QSQS
9YhOxHCigLiGWEk8RDxPHCW+JVFIZiQ2KYEkIW0h7SedIt0ivSCTyUZkD3I8WUzeQm4mnyHfJ79R
oCpYKgQo8BRWK9QodCpcUXimiFc0VPRUXKyYr1iheERxSPGpEl7JSImtxFFapVSjdFTphtK0MlXZ
RjlUOUN5s3KL8gXlRxQsxYjiQ+FRiij7KGcoY1SEqk9lU7nUddRG6lnqOA1DM6YF0FJppbRvaIO0
KRWKip1KtEqeSo3KcRUpHaEb0QPo6fQy+mH6dfo7VS1VT1W+6ibVNtUrqq/V5qh5qPHVStTa1UbU
3qkz1H3U09S3qXep39NAaZhphGvkauzROKvxdA5tjssc7pySOYfn3NaENc00IzRXaO7THNCc1tLW
8tPK0qrSOqP1VJuu7aGdqr1D+4T2pA5Vx01HoLND56TOY4YKw5ORzqhk9DGmdDV1/XUluvW6g7oz
esZ6UXqFeu169/QJ+iz9JP0d+r36UwY6BiEGBQatBrcN8YYswxTDXYb9hq+NjI1ijDYYdRk9MlYz
DjDON241vmtCNnE3WWbSYHLNFGPKMk0z3W162Qw2szdLMasxGzKHzR3MBea7zYct0BZOFkKLBosb
TBLTk5nDbGWOWtItgy0LLbssn1kZWMVbbbPqt/pobW+dbt1ofceGYhNoU2jTY/OrrZkt17bG9tpc
8lzfuavnds99bmdux7fbY3fTnmofYr/Bvtf+g4Ojg8ihzWHS0cAx0bHW8QaLxgpjbWadd0I7eTmt
djrm9NbZwVnsfNj5FxemS5pLi8ujecbz+PMa54256rlyXOtdpW4Mt0S3vW5Sd113jnuD+wMPfQ+e
R5PHhKepZ6rnQc9nXtZeIq8Or9dsZ/ZK9ilvxNvPu8R70IfiE+VT7XPfV8832bfVd8rP3m+F3yl/
tH+Q/zb/GwFaAdyA5oCpQMfAlYF9QaSgBUHVQQ+CzYJFwT0hcEhgyPaQu/MN5wvnd4WC0IDQ7aH3
wozDloV9H44JDwuvCX8YYRNRENG/gLpgyYKWBa8ivSLLIu9EmURJonqjFaMTopujX8d4x5THSGOt
YlfGXorTiBPEdcdj46Pjm+KnF/os3LlwPME+oTjh+iLjRXmLLizWWJy++PgSxSWcJUcS0YkxiS2J
7zmhnAbO9NKApbVLp7hs7i7uE54Hbwdvku/KL+dPJLkmlSc9SnZN3p48meKeUpHyVMAWVAuep/qn
1qW+TgtN25/2KT0mvT0Dl5GYcVRIEaYJ+zK1M/Myh7PMs4qzpMucl+1cNiUKEjVlQ9mLsrvFNNnP
1IDERLJeMprjllOT8yY3OvdInnKeMG9gudnyTcsn8n3zv16BWsFd0VugW7C2YHSl58r6VdCqpat6
V+uvLlo9vsZvzYG1hLVpa38otC4sL3y5LmZdT5FW0ZqisfV+61uLFYpFxTc2uGyo24jaKNg4uGnu
pqpNH0t4JRdLrUsrSt9v5m6++JXNV5VffdqStGWwzKFsz1bMVuHW69vctx0oVy7PLx/bHrK9cwdj
R8mOlzuX7LxQYVdRt4uwS7JLWhlc2V1lULW16n11SvVIjVdNe61m7aba17t5u6/s8djTVqdVV1r3
bq9g7816v/rOBqOGin2YfTn7HjZGN/Z/zfq6uUmjqbTpw37hfumBiAN9zY7NzS2aLWWtcKukdfJg
wsHL33h/093GbKtvp7eXHgKHJIcef5v47fXDQYd7j7COtH1n+F1tB7WjpBPqXN451ZXSJe2O6x4+
Gni0t8elp+N7y+/3H9M9VnNc5XjZCcKJohOfTuafnD6Vderp6eTTY71Leu+ciT1zrS+8b/Bs0Nnz
53zPnen37D953vX8sQvOF45eZF3suuRwqXPAfqDjB/sfOgYdBjuHHIe6Lztd7hmeN3ziivuV01e9
r567FnDt0sj8keHrUddv3ki4Ib3Ju/noVvqt57dzbs/cWXMXfbfkntK9ivua9xt+NP2xXeogPT7q
PTrwYMGDO2PcsSc/Zf/0frzoIflhxYTORPMj20fHJn0nLz9e+Hj8SdaTmafFPyv/XPvM5Nl3v3j8
MjAVOzX+XPT806+bX6i/2P/S7mXvdNj0/VcZr2Zel7xRf3PgLett/7uYdxMzue+x7ys/mH7o+Rj0
8e6njE+ffgP3hPP7ZW5kc3RyZWFtCmVuZG9iago5IDAgb2JqCjw8Ci9UeXBlIC9FbmNvZGluZyAv
QmFzZUVuY29kaW5nIC9XaW5BbnNpRW5jb2RpbmcKL0RpZmZlcmVuY2VzIFsgNDUvbWludXMgOTYv
cXVvdGVsZWZ0CjE0NC9kb3RsZXNzaSAvZ3JhdmUgL2FjdXRlIC9jaXJjdW1mbGV4IC90aWxkZSAv
bWFjcm9uIC9icmV2ZSAvZG90YWNjZW50Ci9kaWVyZXNpcyAvLm5vdGRlZiAvcmluZyAvY2VkaWxs
YSAvLm5vdGRlZiAvaHVuZ2FydW1sYXV0IC9vZ29uZWsgL2Nhcm9uIC9zcGFjZV0KPj4KZW5kb2Jq
CjEwIDAgb2JqCjw8IC9UeXBlIC9Gb250IC9TdWJ0eXBlIC9UeXBlMSAvTmFtZSAvRjEgL0Jhc2VG
b250IC9aYXBmRGluZ2JhdHMgPj4KZW5kb2JqCjExIDAgb2JqCjw8IC9UeXBlIC9Gb250IC9TdWJ0
eXBlIC9UeXBlMSAvTmFtZSAvRjIgL0Jhc2VGb250IC9IZWx2ZXRpY2EKL0VuY29kaW5nIDkgMCBS
ID4+CmVuZG9iagoxMiAwIG9iago8PCAvVHlwZSAvRm9udCAvU3VidHlwZSAvVHlwZTEgL05hbWUg
L0YzIC9CYXNlRm9udCAvSGVsdmV0aWNhLUJvbGQKL0VuY29kaW5nIDkgMCBSID4+CmVuZG9iagp4
cmVmCjAgMTMKMDAwMDAwMDAwMCA2NTUzNSBmIAowMDAwMDAwMDIxIDAwMDAwIG4gCjAwMDAwMDAx
NjQgMDAwMDAgbiAKMDAwMDAwMTUyOSAwMDAwMCBuIAowMDAwMDAxNjEyIDAwMDAwIG4gCjAwMDAw
MDE3NDcgMDAwMDAgbiAKMDAwMDAwMTc4MCAwMDAwMCBuIAowMDAwMDAwMjEzIDAwMDAwIG4gCjAw
MDAwMDAyOTMgMDAwMDAgbiAKMDAwMDAwNDQ3NSAwMDAwMCBuIAowMDAwMDA0NzMyIDAwMDAwIG4g
CjAwMDAwMDQ4MTYgMDAwMDAgbiAKMDAwMDAwNDkxMyAwMDAwMCBuIAp0cmFpbGVyCjw8IC9TaXpl
IDEzIC9JbmZvIDEgMCBSIC9Sb290IDIgMCBSID4+CnN0YXJ0eHJlZgo1MDE1CiUlRU9GCg==


--=-WTNocMG3YNTG0rOLTsJV
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--=-WTNocMG3YNTG0rOLTsJV--


From xen-devel-bounces@lists.xen.org Thu Sep 20 09:39:22 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Sep 2012 09: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 1TEdDt-0005Dc-5R; Thu, 20 Sep 2012 09:39:05 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <oliver.chick@citrix.com>) id 1TEdDs-0005DW-5Q
	for xen-devel@lists.xen.org; Thu, 20 Sep 2012 09:39:04 +0000
Received: from [85.158.138.51:46994] by server-10.bemta-3.messagelabs.com id
	1E/90-10411-734EA505; Thu, 20 Sep 2012 09:39:03 +0000
X-Env-Sender: oliver.chick@citrix.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1348133942!23693877!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTAzMDk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15833 invoked from network); 20 Sep 2012 09:39:02 -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;
	20 Sep 2012 09:39:02 -0000
X-IronPort-AV: E=Sophos;i="4.80,453,1344211200"; d="scan'208";a="14650238"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Sep 2012 09:39:02 +0000
Received: from [10.80.2.50] (10.80.2.50) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Thu, 20 Sep 2012 10:39:02 +0100
Message-ID: <1348133915.24539.10.camel@oliverchick-Precision-WorkStation-T3400>
From: Oliver Chick <oliver.chick@citrix.com>
To: George Dunlap <George.Dunlap@eu.citrix.com>
Date: Thu, 20 Sep 2012 10:38:35 +0100
In-Reply-To: <CAFLBxZYtmJ_bKFb90r45=C4Pq1-oe5Fy=eygSsQf4BcGj3EqGA@mail.gmail.com>
References: <CAFLBxZYtmJ_bKFb90r45=C4Pq1-oe5Fy=eygSsQf4BcGj3EqGA@mail.gmail.com>
X-Mailer: Evolution 3.2.3-0ubuntu6 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.3 development 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-09-19 at 17:58 +0100, George Dunlap wrote:
> = Timeline =
> 
> We are planning on a 9-month release cycle.  Based on that, below are
> our estimated dates:
> * Feature Freeze: 1 March, 2013
> * First RC: 15 April 2013
> * Release: 1 June 2013
> 
> The RCs and release will of course depend on stability and bugs, and
> will therefore be fairly unpredictable.  The feature freeze may be
> slipped for especially important features which are near completion.
> 
> = Feature tracking =
> 
> Below is a list of features we're tracking for this release.  Please
> respond to this mail with any updates to the status.  If the status
> is "?", as most of them are, please respond with the status!  Example
> statuses include "not started", "in progress", "initial implementation
> submitted for review", "patches submitted".
> 
> There are a number of items whose owners are marked as "?".  If you
> are working on this, or know who is working on it, please respond and
> let me know.  Alternately, if you would *like* to work on it, please
> let me know as well.
> 
> And if there is something you're working on you'd like tracked, please
> respond, and I will add it to the list.
> 
> 
> * PVH mode, domU (w/ Linux)
>   owner: mukesh@oracle
>   status: ?
> 
> * PVH mode, dom0 (w/ Linux)
>   owner: mukesh@oracle
>   status: ?
> 
> * Event channel scalability
>   owner: attilio@citrix
>   status: ?
>   Increase limit on event channels (currently 1024 for 32-bit guests,
>   4096 for 64-bit guests)
> 
> * ARM server port
>   owner: ijc@citrix
>   status: Core hypervisor patches accepted; Linux paches pending
> 
> * NUMA scheduler affinity
>   critical
>   owner: dario@citrix
>   status: ?
> 
> * NUMA Memory migration
>   owner: dario@citrix
>   status: ?
> 
> * blktap3
>   owner: thanos@citrix
>   status: ?
> 
> * Default to QEMU upstream
>  - qemu-based stubdom (Linux or BSD libc)
>    owner: anthony@citrix
>    status: ?
>    qemu-upstream needs a more fully-featured libc than exists in
>    minios.  Either work on a minimalist linux-based stubdom with
>    glibc, or port one of the BSD libcs to minios.
> 
>  - pci pass-thru
>    owner: anthony@citrix
>    status: ?
> 
> * Persistent grants
>   owner: @citrix
>   status:

Initial implementation of persistent grants for block devices submitted
for review

> 
> * Multi-page blk rings
>  - blkback in kernel (konrad@oracle, ?@intel)
>  - qemu blkback
>   status: ?
> 
> * Multi-page net protocol
>   owner: ?
>   status: ?
>   expand the network ring protocol to allow multiple pages for
>   increased throughput
> 
> * Scalability: 16TiB of RAM
>   owner: jan@suse
>   status: ?
> 
> * libvirt integration
>   owner: ?
>   status: ?
>   To begin with, we need someone to go and make some lists:
>   - Features available in libvirt/KVM not available in libvirt/Xen
>   - Features available in xl/Xen but not available in libvirt/Xen
> 
> * xl vm-{export,import}
>   owner: ?
>   status: ?
>   Allow xl to import and export VMs to other formats; particularly
>   ovf, perhaps the XenServer format, or more.
> 
> 
> * xl USB pass-through for PV guests
>   owner: ?
>   status: ?
>   - Port the xend PV pass-through functionality to xl.
>   - Make sure qemu-based USB with qemu-upstream works
>   - Upstream the Linux frontend/backend drivers
> 
> * openvswitch toostack integration
>   owner: roger@citrix
>   status: Sample script posted by Bastian ("[RFC] openvswitch support script")
> 
> * Rationalized backend scripts (incl. driver domains)
>   owner: roger@citrix
>   status: ?
> 
> * Linux console improvements
>   owner: jan@suse
>   -EHCI debug port (done, to be submitted)
>   -xHCI debug port
>   -Firewire
> 
> * CPUID-based idle (don't rely on ACPI info f/ dom0)
>   owner: jan@suse
>   status: done, to be submitted
> 
> * Remove hardcoded mobprobe's in xencommons
>   owner: ?
>   status: ?
> 
> * Make storage migration possible
>   owner: ?
>   status: ?
>   There needs to be a way, either via command-line or via some hooks,
>   that someone can build a "storage migration" feature on top of libxl
>   or xl.
> 
> * Full-VM snapshotting
>   owner: ?
>   status: ?
>   Have a way of coordinating the taking and restoring of VM memory and
>   disk snapshots.  This would involve some investigation into the best
>   way to accomplish this.
> 
> * VM Cloning
>   owner: ?
>   status: May need review
>   Again, a way of coordinating the memory and disk aspects.  Research
>   into the best way to do this would probably go along with the
>   snapshotting feature.
> 
> * Memory: Replace PoD with paging mechanism
>   owner: george@citrix
>   status: May need review
> 
> * PV audio (audio for stubdom qemu)
>   owner: stefano.panella@citrix
>   status: ?
> 
> * Managed domains?
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Sep 20 09:39:22 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Sep 2012 09: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 1TEdDt-0005Dc-5R; Thu, 20 Sep 2012 09:39:05 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <oliver.chick@citrix.com>) id 1TEdDs-0005DW-5Q
	for xen-devel@lists.xen.org; Thu, 20 Sep 2012 09:39:04 +0000
Received: from [85.158.138.51:46994] by server-10.bemta-3.messagelabs.com id
	1E/90-10411-734EA505; Thu, 20 Sep 2012 09:39:03 +0000
X-Env-Sender: oliver.chick@citrix.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1348133942!23693877!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTAzMDk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15833 invoked from network); 20 Sep 2012 09:39:02 -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;
	20 Sep 2012 09:39:02 -0000
X-IronPort-AV: E=Sophos;i="4.80,453,1344211200"; d="scan'208";a="14650238"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Sep 2012 09:39:02 +0000
Received: from [10.80.2.50] (10.80.2.50) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Thu, 20 Sep 2012 10:39:02 +0100
Message-ID: <1348133915.24539.10.camel@oliverchick-Precision-WorkStation-T3400>
From: Oliver Chick <oliver.chick@citrix.com>
To: George Dunlap <George.Dunlap@eu.citrix.com>
Date: Thu, 20 Sep 2012 10:38:35 +0100
In-Reply-To: <CAFLBxZYtmJ_bKFb90r45=C4Pq1-oe5Fy=eygSsQf4BcGj3EqGA@mail.gmail.com>
References: <CAFLBxZYtmJ_bKFb90r45=C4Pq1-oe5Fy=eygSsQf4BcGj3EqGA@mail.gmail.com>
X-Mailer: Evolution 3.2.3-0ubuntu6 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.3 development 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-09-19 at 17:58 +0100, George Dunlap wrote:
> = Timeline =
> 
> We are planning on a 9-month release cycle.  Based on that, below are
> our estimated dates:
> * Feature Freeze: 1 March, 2013
> * First RC: 15 April 2013
> * Release: 1 June 2013
> 
> The RCs and release will of course depend on stability and bugs, and
> will therefore be fairly unpredictable.  The feature freeze may be
> slipped for especially important features which are near completion.
> 
> = Feature tracking =
> 
> Below is a list of features we're tracking for this release.  Please
> respond to this mail with any updates to the status.  If the status
> is "?", as most of them are, please respond with the status!  Example
> statuses include "not started", "in progress", "initial implementation
> submitted for review", "patches submitted".
> 
> There are a number of items whose owners are marked as "?".  If you
> are working on this, or know who is working on it, please respond and
> let me know.  Alternately, if you would *like* to work on it, please
> let me know as well.
> 
> And if there is something you're working on you'd like tracked, please
> respond, and I will add it to the list.
> 
> 
> * PVH mode, domU (w/ Linux)
>   owner: mukesh@oracle
>   status: ?
> 
> * PVH mode, dom0 (w/ Linux)
>   owner: mukesh@oracle
>   status: ?
> 
> * Event channel scalability
>   owner: attilio@citrix
>   status: ?
>   Increase limit on event channels (currently 1024 for 32-bit guests,
>   4096 for 64-bit guests)
> 
> * ARM server port
>   owner: ijc@citrix
>   status: Core hypervisor patches accepted; Linux paches pending
> 
> * NUMA scheduler affinity
>   critical
>   owner: dario@citrix
>   status: ?
> 
> * NUMA Memory migration
>   owner: dario@citrix
>   status: ?
> 
> * blktap3
>   owner: thanos@citrix
>   status: ?
> 
> * Default to QEMU upstream
>  - qemu-based stubdom (Linux or BSD libc)
>    owner: anthony@citrix
>    status: ?
>    qemu-upstream needs a more fully-featured libc than exists in
>    minios.  Either work on a minimalist linux-based stubdom with
>    glibc, or port one of the BSD libcs to minios.
> 
>  - pci pass-thru
>    owner: anthony@citrix
>    status: ?
> 
> * Persistent grants
>   owner: @citrix
>   status:

Initial implementation of persistent grants for block devices submitted
for review

> 
> * Multi-page blk rings
>  - blkback in kernel (konrad@oracle, ?@intel)
>  - qemu blkback
>   status: ?
> 
> * Multi-page net protocol
>   owner: ?
>   status: ?
>   expand the network ring protocol to allow multiple pages for
>   increased throughput
> 
> * Scalability: 16TiB of RAM
>   owner: jan@suse
>   status: ?
> 
> * libvirt integration
>   owner: ?
>   status: ?
>   To begin with, we need someone to go and make some lists:
>   - Features available in libvirt/KVM not available in libvirt/Xen
>   - Features available in xl/Xen but not available in libvirt/Xen
> 
> * xl vm-{export,import}
>   owner: ?
>   status: ?
>   Allow xl to import and export VMs to other formats; particularly
>   ovf, perhaps the XenServer format, or more.
> 
> 
> * xl USB pass-through for PV guests
>   owner: ?
>   status: ?
>   - Port the xend PV pass-through functionality to xl.
>   - Make sure qemu-based USB with qemu-upstream works
>   - Upstream the Linux frontend/backend drivers
> 
> * openvswitch toostack integration
>   owner: roger@citrix
>   status: Sample script posted by Bastian ("[RFC] openvswitch support script")
> 
> * Rationalized backend scripts (incl. driver domains)
>   owner: roger@citrix
>   status: ?
> 
> * Linux console improvements
>   owner: jan@suse
>   -EHCI debug port (done, to be submitted)
>   -xHCI debug port
>   -Firewire
> 
> * CPUID-based idle (don't rely on ACPI info f/ dom0)
>   owner: jan@suse
>   status: done, to be submitted
> 
> * Remove hardcoded mobprobe's in xencommons
>   owner: ?
>   status: ?
> 
> * Make storage migration possible
>   owner: ?
>   status: ?
>   There needs to be a way, either via command-line or via some hooks,
>   that someone can build a "storage migration" feature on top of libxl
>   or xl.
> 
> * Full-VM snapshotting
>   owner: ?
>   status: ?
>   Have a way of coordinating the taking and restoring of VM memory and
>   disk snapshots.  This would involve some investigation into the best
>   way to accomplish this.
> 
> * VM Cloning
>   owner: ?
>   status: May need review
>   Again, a way of coordinating the memory and disk aspects.  Research
>   into the best way to do this would probably go along with the
>   snapshotting feature.
> 
> * Memory: Replace PoD with paging mechanism
>   owner: george@citrix
>   status: May need review
> 
> * PV audio (audio for stubdom qemu)
>   owner: stefano.panella@citrix
>   status: ?
> 
> * Managed domains?
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Sep 20 09:46:00 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Sep 2012 09: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 1TEdKP-0005Qc-LR; Thu, 20 Sep 2012 09:45:49 +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 1TEdKM-0005Pe-To
	for xen-devel@lists.xen.org; Thu, 20 Sep 2012 09:45:47 +0000
Received: from [85.158.137.99:56131] by server-5.bemta-3.messagelabs.com id
	0B/78-13133-9C5EA505; Thu, 20 Sep 2012 09:45:45 +0000
X-Env-Sender: jean.guyader@citrix.com
X-Msg-Ref: server-8.tower-217.messagelabs.com!1348134343!13075422!4
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTA0NTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7986 invoked from network); 20 Sep 2012 09:45:44 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Sep 2012 09:45:44 -0000
X-IronPort-AV: E=Sophos;i="4.80,453,1344211200"; d="scan'208";a="14650467"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Sep 2012 09:44: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.279.1; Thu, 20 Sep 2012 10:44: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 1TEdJR-0007kn-2I;
	Thu, 20 Sep 2012 09:44:49 +0000
Received: by spongy (Postfix, from userid 2023)	id 3D3D3341ABF; Thu, 20 Sep
	2012 10:47:08 +0100 (BST)
From: Jean Guyader <jean.guyader@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Thu, 20 Sep 2012 10:47:06 +0100
Message-ID: <1348134426-25320-5-git-send-email-jean.guyader@citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <1348134426-25320-1-git-send-email-jean.guyader@citrix.com>
References: <1348134426-25320-1-git-send-email-jean.guyader@citrix.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="------------true"
Cc: tim@xen.org, Jean Guyader <jean.guyader@citrix.com>, JBeulich@suse.com
Subject: [Xen-devel] [PATCH 4/4] 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             |    6 +-
 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                |   13 +-
 xen/common/v4v.c                   | 1905 ++++++++++++++++++++++++++++++=
++++++
 xen/include/public/v4v.h           |  308 ++++++
 xen/include/public/xen.h           |    2 +-
 xen/include/xen/sched.h            |    4 +
 xen/include/xen/v4v.h              |  133 +++
 10 files changed, 2372 insertions(+), 4 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 d69e419..b685535 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -3183,7 +3183,8 @@ static hvm_hypercall_t *const hvm_hypercall64_table=
[NR_hypercalls] =3D {
     HYPERCALL(set_timer_op),
     HYPERCALL(hvm_op),
     HYPERCALL(sysctl),
-    HYPERCALL(tmem_op)
+    HYPERCALL(tmem_op),
+    HYPERCALL(v4v_op)
 };
=20
 #define COMPAT_CALL(x)                                        \
@@ -3200,7 +3201,8 @@ static hvm_hypercall_t *const hvm_hypercall32_table=
[NR_hypercalls] =3D {
     COMPAT_CALL(set_timer_op),
     HYPERCALL(hvm_op),
     HYPERCALL(sysctl),
-    HYPERCALL(tmem_op)
+    HYPERCALL(tmem_op),
+    HYPERCALL(v4v_op)
 };
=20
 int hvm_do_hypercall(struct cpu_user_regs *regs)
diff --git a/xen/arch/x86/x86_64/compat/entry.S b/xen/arch/x86/x86_64/com=
pat/entry.S
index 2f606ab..f518a03 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 5 /* 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 8156827..5f4e7bf 100644
--- a/xen/arch/x86/x86_64/entry.S
+++ b/xen/arch/x86/x86_64/entry.S
@@ -707,6 +707,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
@@ -755,6 +756,7 @@ ENTRY(hypercall_args_table)
         .byte 1 /* do_domctl            */
         .byte 2 /* do_kexec             */
         .byte 1 /* do_tmem_op           */
+        .byte 5 /* 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 c1c100f..ba63cec 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 a1aa05e..94283e3 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 err, init_status =3D 0;
     int poolid =3D CPUPOOLID_NONE;
=20
@@ -307,6 +308,13 @@ struct domain *domain_create(
         spin_unlock(&domlist_update_lock);
     }
=20
+    if ( !is_idle_domain(d) )
+    {
+        if ( v4v_init(d) !=3D 0 )
+            goto fail;
+        init_status |=3D INIT_v4v;
+    }
+
     return d;
=20
  fail:
@@ -315,6 +323,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 )
@@ -468,6 +478,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..afb9267
--- /dev/null
+++ b/xen/common/v4v.c
@@ -0,0 +1,1905 @@
+/***********************************************************************=
*******
+ * 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 <asm/types.h>
+
+#ifdef V4V_DEBUG
+#define v4v_dprintk(format, args...)            \
+    do {                                        \
+        printk("%s:%d " format,                 \
+               __FILE__, __LINE__, ## args );   \
+    } while ( 1 =3D=3D 0 )
+#else
+#define v4v_dprintk(format, ... ) (void)0
+#endif
+
+/*
+ * 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
+ */
+#define V4V_ROUNDUP(a) (((a) +0xf ) & ~0xf)
+
+DEFINE_XEN_GUEST_HANDLE(uint8_t);
+static struct v4v_ring_info *v4v_ring_find_info(struct domain *d,
+                                                v4v_ring_id_t *id);
+
+static struct v4v_ring_info *v4v_ring_find_info_by_addr(struct domain *d=
,
+                                                        struct v4v_addr =
*a,
+                                                        domid_t p);
+
+typedef struct internal_v4v_iov
+{
+    XEN_GUEST_HANDLE(v4v_iov_t) guest_iov;
+    v4v_iov_t                   *xen_iov;
+} internal_v4v_iov_t;
+
+struct list_head viprules =3D LIST_HEAD_INIT(viprules);
+
+/*
+ * 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
+ */
+
+/*
+ * lock to protect the filtering rules list: viprules
+ *
+ * The write lock is held for viptables_del and viptables_add
+ * The read lock is held for viptable_list
+ */
+static DEFINE_RWLOCK(viprules_lock);
+
+
+/*
+ * Debugs
+ */
+
+#ifdef V4V_DEBUG
+static void __attribute__((unused))
+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);
+
+    evtchn_send(d, d->v4v->evtchn_port);
+}
+
+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
+ */
+
+static void
+v4v_ring_unmap(struct v4v_ring_info *ring_info)
+{
+    int i;
+
+    ASSERT(spin_is_locked(&ring_info->lock));
+
+    for ( i =3D 0; i < ring_info->npage; ++i )
+    {
+        if ( !ring_info->mfn_mapping[i] )
+            continue;
+        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;
+    }
+}
+
+static uint8_t *
+v4v_ring_map_page(struct v4v_ring_info *ring_info, int i)
+{
+    ASSERT(spin_is_locked(&ring_info->lock));
+
+    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->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];
+}
+
+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;
+
+    ASSERT(spin_is_locked(&ring_info->lock));
+
+    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;
+}
+
+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);
+    uint32_t *p =3D (uint32_t *)(dst + offsetof(v4v_ring_t, tx_ptr));
+
+    ASSERT(spin_is_locked(&ring_info->lock));
+
+    if ( !dst )
+        return -EFAULT;
+    write_atomic(p, tx_ptr);
+    mb();
+    return 0;
+}
+
+static int
+v4v_copy_from_guest_maybe(void *dst, void *src,
+                          XEN_GUEST_HANDLE(uint8_t) src_hnd,
+                          uint32_t len)
+{
+    int rc =3D 0;
+
+    if ( src )
+        memcpy(dst, src, len);
+    else
+        rc =3D copy_from_guest(dst, src_hnd, len);
+    return rc;
+}
+
+static int
+v4v_memcpy_to_guest_ring(struct v4v_ring_info *ring_info,
+                         uint32_t offset,
+                         void *src,
+                         XEN_GUEST_HANDLE(uint8_t) src_hnd,
+                         uint32_t len)
+{
+    int page =3D offset >> PAGE_SHIFT;
+    uint8_t *dst;
+
+    ASSERT(spin_is_locked(&ring_info->lock));
+
+    offset &=3D PAGE_SIZE - 1;
+
+    while ( (offset + len) > PAGE_SIZE )
+    {
+        dst =3D v4v_ring_map_page(ring_info, page);
+        if ( !dst )
+            return -EFAULT;
+
+        if ( v4v_copy_from_guest_maybe(dst + offset, src, src_hnd,
+                                       PAGE_SIZE - offset) )
+            return -EFAULT;
+
+        page++;
+        len -=3D PAGE_SIZE - offset;
+        if ( src )
+            src +=3D (PAGE_SIZE - offset);
+        else
+            guest_handle_add_offset(src_hnd, PAGE_SIZE - offset);
+        offset =3D 0;
+    }
+
+    dst =3D v4v_ring_map_page(ring_info, page);
+    if ( !dst )
+        return -EFAULT;
+
+    if ( v4v_copy_from_guest_maybe(dst + offset, src, src_hnd, len) )
+        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 =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;
+
+    write_atomic(rx_ptr, ringp->rx_ptr);
+    mb();
+
+    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 =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;
+}
+
+static unsigned long
+v4v_iov_copy(v4v_iov_t *iov, internal_v4v_iov_t *iovs)
+{
+    if (iovs->xen_iov =3D=3D NULL)
+    {
+        return copy_from_guest(iov, iovs->guest_iov, 1);
+    }
+    else
+    {
+        *iov =3D *(iovs->xen_iov);
+        return 0;
+    }
+}
+
+static void
+v4v_iov_add_offset(internal_v4v_iov_t *iovs, int offset)
+{
+    if (iovs->xen_iov =3D=3D NULL)
+        guest_handle_add_offset(iovs->guest_iov, offset);
+    else
+        iovs->xen_iov +=3D offset;
+}
+
+static long
+v4v_iov_count(internal_v4v_iov_t iovs, int niov)
+{
+    v4v_iov_t iov;
+    size_t ret =3D 0;
+
+    while ( niov-- )
+    {
+        if ( v4v_iov_copy(&iov, &iovs) )
+            return -EFAULT;
+
+        /* message bigger than 2G can't be sent */
+        if (ret > 2L * 1024 * 1024 * 1024)
+            return -EMSGSIZE;
+
+        ret +=3D iov.iov_len;
+        v4v_iov_add_offset(&iovs, 1);
+    }
+
+    return ret;
+}
+
+static long
+v4v_ringbuf_insertv(struct domain *d,
+                    struct v4v_ring_info *ring_info,
+                    v4v_ring_id_t *src_id, uint32_t proto,
+                    internal_v4v_iov_t iovs, uint32_t niov,
+                    size_t len)
+{
+    v4v_ring_t ring;
+    struct v4v_ring_message_header mh =3D { 0 };
+    int32_t sp;
+    long happy_ret;
+    int32_t ret =3D 0;
+    XEN_GUEST_HANDLE(uint8_t) empty_hnd =3D { 0 };
+
+    ASSERT(spin_is_locked(&ring_info->lock));
+
+    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.message_type =3D proto;
+
+        if ( (ret =3D v4v_memcpy_to_guest_ring(ring_info,
+                                             ring.tx_ptr + sizeof (v4v_r=
ing_t),
+                                             &mh, empty_hnd,
+                                             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 ( v4v_iov_copy(&iov, &iovs) )
+            {
+                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 )
+            {
+                ret =3D v4v_memcpy_to_guest_ring(ring_info,
+                        ring.tx_ptr + sizeof (v4v_ring_t),
+                        NULL, buf_hnd, sp);
+                if ( ret )
+                    break;
+
+                ring.tx_ptr =3D 0;
+                len -=3D sp;
+                guest_handle_add_offset(buf_hnd, sp);
+            }
+
+            ret =3D v4v_memcpy_to_guest_ring(ring_info,
+                    ring.tx_ptr + sizeof (v4v_ring_t),
+                    NULL, buf_hnd, len);
+            if ( ret )
+                break;
+
+            ring.tx_ptr +=3D len;
+
+            if ( ring.tx_ptr =3D=3D ring_info->len )
+                ring.tx_ptr =3D 0;
+
+            v4v_iov_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);
+}
+
+static void
+v4v_pending_remove_all(struct v4v_ring_info *info)
+{
+    struct hlist_node *node, *next;
+    struct v4v_pending_ent *pending_ent;
+
+    ASSERT(spin_is_locked(&info->lock));
+    hlist_for_each_entry_safe(pending_ent, node, next, &info->pending,
+            node) v4v_pending_remove_ent(pending_ent);
+}
+
+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;
+
+    ASSERT(rw_is_locked(&v4v_lock));
+
+    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);
+    }
+
+}
+
+static void
+v4v_pending_find(struct domain *d, 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;
+
+    ASSERT(rw_is_locked(&d->v4v->lock));
+
+    spin_lock(&ring_info->lock);
+    hlist_for_each_entry_safe(ent, node, next, &ring_info->pending, node=
)
+    {
+        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 l=
en)
+{
+    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, int=
 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, node=
)
+    {
+        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(xen_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);
+    }
+    return ret;
+}
+
+
+static struct v4v_ring_info *
+v4v_ring_find_info(struct domain *d, v4v_ring_id_t *id)
+{
+    uint16_t hash;
+    struct hlist_node *node;
+    struct v4v_ring_info *ring_info;
+
+    ASSERT(rw_is_locked(&d->v4v->lock));
+
+    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], node=
)
+    {
+        v4v_ring_id_t *cmpid =3D &ring_info->id;
+
+        if ( cmpid->addr.port =3D=3D id->addr.port &&
+             cmpid->addr.domain =3D=3D id->addr.domain &&
+             cmpid->partner =3D=3D id->partner)
+        {
+            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;
+}
+
+static struct v4v_ring_info *
+v4v_ring_find_info_by_addr(struct domain *d, struct v4v_addr *a, domid_t=
 p)
+{
+    v4v_ring_id_t id;
+    struct v4v_ring_info *ret;
+
+    ASSERT(rw_is_locked(&d->v4v->lock));
+
+    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_ANY;
+
+    return v4v_ring_find_info(d, &id);
+}
+
+static void v4v_ring_remove_mfns(struct domain *d, struct v4v_ring_info =
*ring_info)
+{
+    int i;
+
+    ASSERT(rw_is_write_locked(&d->v4v->lock));
+
+    if ( ring_info->mfns )
+    {
+        for ( i =3D 0; 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);
+    }
+    if ( ring_info->mfn_mapping )
+        xfree(ring_info->mfn_mapping);
+    ring_info->mfns =3D NULL;
+
+}
+
+static void
+v4v_ring_remove_info(struct domain *d, struct v4v_ring_info *ring_info)
+{
+    ASSERT(rw_is_write_locked(&d->v4v->lock));
+
+    spin_lock(&ring_info->lock);
+
+    v4v_pending_remove_all(ring_info);
+    hlist_del(&ring_info->node);
+    v4v_ring_remove_mfns(d, ring_info);
+
+    spin_unlock(&ring_info->lock);
+
+    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 =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(d, 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(xen_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 rin=
g.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.
+             */
+            printk(KERN_INFO "v4v: dom%d ring already registered\n",
+                    current->domain->domain_id);
+            ret =3D -EEXIST;
+            break;
+        }
+
+        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
+ */
+
+static void
+v4v_notify_ring(struct domain *d, struct v4v_ring_info *ring_info,
+                struct hlist_head *to_notify)
+{
+    uint32_t space;
+
+    ASSERT(rw_is_locked(&v4v_lock));
+    ASSERT(rw_is_locked(&d->v4v->lock));
+
+    spin_lock(&ring_info->lock);
+    space =3D v4v_ringbuf_payload_space(d, ring_info);
+    spin_unlock(&ring_info->lock);
+
+    v4v_pending_find(d, 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, data[0]);
+                ret =3D v4v_fill_ring_datas(d, ring_data.nent, ring_data=
_ent_hnd);
+            }
+        }
+    }
+    while ( 0 );
+
+    read_unlock(&v4v_lock);
+
+    return ret;
+}
+
+#ifdef V4V_DEBUG
+void
+v4v_viptables_print_rule(struct v4v_viptables_rule_node *node)
+{
+    v4v_viptables_rule_t *rule;
+
+    if ( node =3D=3D NULL )
+    {
+        printk("(null)\n");
+        return;
+    }
+
+    rule =3D &node->rule;
+
+    if ( rule->accept =3D=3D 1 )
+        printk("ACCEPT");
+    else
+        printk("REJECT");
+
+    printk(" ");
+
+    if ( rule->src.domain =3D=3D V4V_DOMID_ANY )
+        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 V4V_DOMID_ANY )
+        printk("*");
+    else
+        printk("%i", rule->dst.domain);
+
+    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 =3D NULL;
+    struct list_head* tmp;
+
+    ASSERT(rw_is_write_locked(&viprules_lock));
+
+    /* First rule is n.1 */
+    position--;
+
+    new =3D xmalloc(struct v4v_viptables_rule_node);
+    if ( new =3D=3D NULL )
+        return -ENOMEM;
+
+    if ( copy_from_guest(&new->rule, rule, 1) )
+    {
+        xfree(new);
+        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_hnd,
+                  int32_t position)
+{
+    struct list_head *tmp =3D NULL;
+    struct list_head *next =3D NULL;
+    struct v4v_viptables_rule_node *node;
+
+    ASSERT(rw_is_write_locked(&viprules_lock));
+
+    v4v_dprintk("v4v_viptables_del position:%d\n", position);
+
+    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_hnd) )
+    {
+        struct v4v_viptables_rule r;
+
+        if ( copy_from_guest(&r, rule_hnd, 1) )
+            return -EFAULT;
+
+        list_for_each(tmp, &viprules)
+        {
+            node =3D list_entry(tmp, struct v4v_viptables_rule_node, lis=
t);
+
+            if ( (node->rule.src.domain =3D=3D r.src.domain) &&
+                 (node->rule.src.port   =3D=3D r.src.port)   &&
+                 (node->rule.dst.domain =3D=3D r.dst.domain) &&
+                 (node->rule.dst.port   =3D=3D r.dst.port))
+            {
+                position =3D 0;
+                break;
+            }
+        }
+    }
+    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, lis=
t);
+            list_del(tmp);
+            xfree(node);
+        }
+    }
+
+    if ( position =3D=3D 0 && tmp !=3D &viprules )
+    {
+        node =3D list_entry(tmp, struct v4v_viptables_rule_node, list);
+#ifdef V4V_DEBUG
+        printk(KERN_ERR "VIPTables: deleting rule: ");
+        v4v_viptables_print_rule(node);
+#endif /* V4V_DEBUG */
+        list_del(tmp);
+        xfree(node);
+    }
+
+    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;
+    XEN_GUEST_HANDLE(v4v_viptables_rule_t) guest_rules;
+
+    ASSERT(rw_is_locked(&viprules_lock));
+
+    memset(&rules_list, 0, sizeof (rules_list));
+    if ( copy_from_guest(&rules_list, list_hnd, 1) )
+        return -EFAULT;
+
+    ptr =3D viprules.next;
+    while ( rules_list.start_rule !=3D 0 && ptr->next !=3D &viprules )
+    {
+        ptr =3D ptr->next;
+        rules_list.start_rule--;
+    }
+
+    if ( rules_list.nb_rules =3D=3D 0 )
+        return -EINVAL;
+
+    guest_rules =3D guest_handle_for_field(list_hnd, v4v_viptables_rule_=
t, rules[0]);
+
+    nbrules =3D 0;
+    while ( nbrules < rules_list.nb_rules && ptr !=3D &viprules )
+    {
+        node =3D list_entry(ptr, struct v4v_viptables_rule_node, list);
+
+        if ( !guest_handle_okay(guest_rules, 1) )
+            break;
+
+        if ( copy_to_guest(guest_rules, &node->rule, 1) )
+            break;
+
+        guest_handle_add_offset(guest_rules, 1);
+
+        nbrules++;
+        ptr =3D ptr->next;
+    }
+
+    rules_list.nb_rules =3D nbrules;
+    if ( copy_field_to_guest(list_hnd, &rules_list, nb_rules) )
+        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;
+    size_t ret =3D 0; /* Defaulting to ACCEPT */
+
+    read_lock(&viprules_lock);
+
+    list_for_each(ptr, &viprules)
+    {
+        node =3D list_entry(ptr, struct v4v_viptables_rule_node, list);
+
+        if ( (node->rule.src.domain =3D=3D V4V_DOMID_ANY ||
+              node->rule.src.domain =3D=3D src->domain) &&
+             (node->rule.src.port =3D=3D V4V_PORT_ANY ||
+              node->rule.src.port =3D=3D src->port) &&
+             (node->rule.dst.domain =3D=3D V4V_DOMID_ANY ||
+              node->rule.dst.domain =3D=3D dst->domain) &&
+             (node->rule.dst.port =3D=3D V4V_PORT_ANY ||
+              node->rule.dst.port =3D=3D dst->port) )
+        {
+            ret =3D !node->rule.accept;
+            break;
+        }
+    }
+
+    read_unlock(&viprules_lock);
+    return ret;
+}
+
+/*
+ * Hypercall to do the send
+ */
+static long
+v4v_sendv(struct domain *src_d, v4v_addr_t * src_addr,
+          v4v_addr_t * dst_addr, uint32_t proto,
+          internal_v4v_iov_t iovs, size_t niov)
+{
+    struct domain *dst_d;
+    v4v_ring_id_t 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;
+    }
+
+    if ( v4v_viptables_check(src_addr, dst_addr) !=3D 0 )
+    {
+        read_unlock(&v4v_lock);
+        gdprintk(XENLOG_WARNING,
+                 "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 )
+        {
+            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->domain=
);
+
+        if ( !ring_info )
+        {
+            ret =3D -ECONNREFUSED;
+            v4v_dprintk(" !ring_info, ECONNREFUSED\n");
+        }
+        else
+        {
+            long 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, io=
vs,
+                        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;
+}
+
+static void
+v4v_info(struct domain *d, v4v_info_t *info)
+{
+    read_lock(&d->v4v->lock);
+    info->ring_magic =3D V4V_RING_MAGIC;
+    info->data_magic =3D V4V_RING_DATA_MAGIC;
+    info->evtchn =3D d->v4v->evtchn_port;
+    read_unlock(&d->v4v->lock);
+}
+
+/*
+ * hypercall glue
+ */
+long
+do_v4v_op(int cmd, XEN_GUEST_HANDLE(void) arg1,
+          XEN_GUEST_HANDLE(void) arg2,
+          uint32_t arg3, uint32_t arg4)
+{
+    struct domain *d =3D current->domain;
+    long rc =3D -EFAULT;
+
+    v4v_dprintk("->do_v4v_op(%d,%p,%p,%d,%d)\n", cmd,
+                (void *)arg1.p, (void *)arg2.p, (int) arg3, (int) arg4);
+
+    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(xen_pfn_t) pfn_hnd =3D
+                    guest_handle_cast(arg2, xen_pfn_t);
+                uint32_t npage =3D arg3;
+                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:
+            {
+                uint32_t len =3D arg3;
+                uint32_t message_type =3D arg4;
+                v4v_iov_t iov;
+                internal_v4v_iov_t iovs;
+                XEN_GUEST_HANDLE(v4v_send_addr_t) addr_hnd =3D
+                    guest_handle_cast(arg1, v4v_send_addr_t);
+                v4v_send_addr_t addr;
+
+                if ( unlikely(!guest_handle_okay(addr_hnd, 1)) )
+                    goto out;
+                if ( copy_from_guest(&addr, addr_hnd, 1) )
+                    goto out;
+
+                iov.iov_base =3D (uint64_t)arg2.p; // FIXME
+                iov.iov_len =3D len;
+                iovs.xen_iov =3D &iov;
+                rc =3D v4v_sendv(d, &addr.src, &addr.dst, message_type, =
iovs, 1);
+                break;
+            }
+        case V4VOP_sendv:
+            {
+                internal_v4v_iov_t iovs;
+                uint32_t niov =3D arg3;
+                uint32_t message_type =3D arg4;
+                XEN_GUEST_HANDLE(v4v_send_addr_t) addr_hnd =3D
+                    guest_handle_cast(arg1, v4v_send_addr_t);
+                v4v_send_addr_t addr;
+
+                memset(&iovs, 0, sizeof (iovs));
+                iovs.guest_iov =3D guest_handle_cast(arg2, v4v_iov_t);
+
+                if ( unlikely(!guest_handle_okay(addr_hnd, 1)) )
+                    goto out;
+                if ( copy_from_guest(&addr, addr_hnd, 1) )
+                    goto out;
+
+                if ( unlikely(!guest_handle_okay(iovs.guest_iov, niov)) =
)
+                    goto out;
+
+                rc =3D v4v_sendv(d, &addr.src, &addr.dst, message_type, =
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;
+            }
+        case V4VOP_viptables_add:
+            {
+                uint32_t position =3D arg3;
+                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;
+
+                write_lock(&viprules_lock);
+                rc =3D v4v_viptables_add(d, rule_hnd, position);
+                write_unlock(&viprules_lock);
+                break;
+            }
+        case V4VOP_viptables_del:
+            {
+                uint32_t position =3D arg3;
+                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;
+
+                write_lock(&viprules_lock);
+                rc =3D v4v_viptables_del(d, rule_hnd, position);
+                write_unlock(&viprules_lock);
+                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 -EFAULT;
+                if ( unlikely(!guest_handle_okay(rules_list_hnd, 1)) )
+                    goto out;
+
+                read_lock(&viprules_lock);
+                rc =3D v4v_viptables_list(d, rules_list_hnd);
+                read_unlock(&viprules_lock);
+                break;
+            }
+        case V4VOP_info:
+            {
+                XEN_GUEST_HANDLE(v4v_info_t) info_hnd =3D
+                    guest_handle_cast(arg1, v4v_info_t);
+                v4v_info_t info;
+
+                if ( unlikely(!guest_handle_okay(info_hnd, 1)) )
+                    goto out;
+                v4v_info(d, &info);
+                if ( copy_to_guest(info_hnd, &info, 1) )
+                    goto out;
+                rc =3D 0;
+                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(d, ring_info);
+            }
+        }
+    }
+
+    d->v4v =3D NULL;
+    write_unlock(&v4v_lock);
+}
+
+int
+v4v_init(struct domain *d)
+{
+    struct v4v_domain *v4v;
+    evtchn_port_t port;
+    int i;
+    int rc;
+
+    v4v =3D xmalloc(struct v4v_domain);
+    if ( !v4v )
+        return -ENOMEM;
+
+    rc =3D evtchn_alloc_unbound_domain(d, &port, d->domain_id);
+    if ( rc )
+        return rc;
+
+    rwlock_init(&v4v->lock);
+
+    v4v->evtchn_port =3D port;
+    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 npage=
=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(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], nod=
e)
+            dump_domain_ring(d, ring_info);
+    }
+
+    printk(KERN_ERR "  event channel: %d\n",  d->v4v->evtchn_port);
+    read_unlock(&d->v4v->lock);
+
+    printk(KERN_ERR "\n");
+    v4v_signal_domain(d);
+}
+
+static void
+dump_state(unsigned char key)
+{
+    struct domain *d;
+
+    printk(KERN_ERR "\n\nV4V:\n");
+    read_lock(&v4v_lock);
+
+    rcu_read_lock(&domlist_read_lock);
+
+    for_each_domain(d)
+        dump_domain(d);
+
+    rcu_read_unlock(&domlist_read_lock);
+
+    read_unlock(&v4v_lock);
+}
+
+struct keyhandler v4v_info_keyhandler =3D
+{
+    .diagnostic =3D 1,
+    .u.fn =3D dump_state,
+    .desc =3D "dump v4v states and interupt"
+};
+
+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..6a9d55c
--- /dev/null
+++ b/xen/include/public/v4v.h
@@ -0,0 +1,308 @@
+/***********************************************************************=
*******
+ * 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"
+#include "event_channel.h"
+
+/*
+ * Structure definitions
+ */
+
+#define V4V_RING_MAGIC          0xa822f72bb0b9d8ccULL
+#define V4V_RING_DATA_MAGIC	0x45fe852220b801d4ULL
+
+#define V4V_MESSAGE_DGRAM       0x3c2c1db8
+#define V4V_MESSAGE_STREAM 	0x70f6a8e5
+
+#define V4V_DOMID_ANY           DOMID_INVALID
+#define V4V_PORT_ANY            0
+
+typedef struct v4v_iov
+{
+    uint64_t iov_base;
+    uint32_t iov_len;
+    uint32_t pad;
+} v4v_iov_t;
+
+typedef struct v4v_addr
+{
+    uint32_t port;
+    domid_t domain;
+    uint16_t pad;
+} v4v_addr_t;
+
+typedef struct v4v_ring_id
+{
+    v4v_addr_t addr;
+    domid_t partner;
+    uint16_t pad;
+} v4v_ring_id_t;
+
+typedef struct
+{
+    v4v_addr_t src;
+    v4v_addr_t dst;
+} v4v_send_addr_t;
+
+/*
+ * v4v_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
+ *
+ */
+struct v4v_ring
+{
+    uint64_t magic;
+    v4v_ring_id_t id;
+    uint32_t len;
+    uint32_t rx_ptr;
+    uint32_t tx_ptr;
+    uint8_t reserved[32];
+    uint8_t ring[];
+};
+typedef struct v4v_ring v4v_ring_t;
+
+#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 exist=
s - do not
+                                               * rely on this field - fo=
r
+                                               * profiling only */
+#define V4V_RING_DATA_F_SUFFICIENT  (1U << 3) /* Sufficient space to que=
ue
+                                               * space_required bytes ex=
ists */
+
+typedef struct v4v_ring_data_ent
+{
+    v4v_addr_t ring;
+    uint16_t flags;
+    uint16_t pad1;
+    uint32_t pad2;
+    uint32_t space_required;
+    uint32_t max_message_size;
+} v4v_ring_data_ent_t;
+
+typedef struct v4v_ring_data
+{
+    uint64_t magic;
+    uint32_t nent;
+    uint32_t pad;
+    uint64_t reserved[4];
+    v4v_ring_data_ent_t data[];
+} v4v_ring_data_t;
+
+struct v4v_info
+{
+    uint64_t ring_magic;
+    uint64_t data_magic;
+    evtchn_port_t evtchn;
+    uint32_t pad;
+};
+typedef struct v4v_info v4v_info_t;
+
+#define V4V_SHF_SYN		(1 << 0)
+#define V4V_SHF_ACK		(1 << 1)
+#define V4V_SHF_RST		(1 << 2)
+
+#define V4V_SHF_PING		(1 << 8)
+#define V4V_SHF_PONG		(1 << 9)
+
+struct v4v_stream_header
+{
+    uint32_t flags;
+    uint32_t conid;
+};
+
+struct v4v_ring_message_header
+{
+    uint32_t len;
+    uint32_t pad0;
+    v4v_addr_t source;
+    uint32_t message_type;
+    uint32_t pad1;
+    uint8_t data[];
+};
+
+typedef struct v4v_viptables_rule
+{
+    v4v_addr_t src;
+    v4v_addr_t dst;
+    uint32_t accept;
+    uint32_t pad;
+} v4v_viptables_rule_t;
+
+typedef struct v4v_viptables_list
+{
+    uint32_t start_rule;
+    uint32_t nb_rules;
+    struct v4v_viptables_rule rules[];
+} v4v_viptables_list_t;
+
+/*
+ * HYPERCALLS
+ */
+
+/*
+ * V4VOP_register_ring
+ *
+ * Registers a ring with Xen. If a ring with the same v4v_ring_id exists=
,
+ * the hypercall will return -EEXIST.
+ *
+ * do_v4v_op(V4VOP_unregister_ring,
+ *           XEN_GUEST_HANDLE(v4v_ring_t), XEN_GUEST_HANDLE(xen_pfn_t),
+ *           npage, 0)
+ */
+#define V4VOP_register_ring 	1
+
+
+/*
+ * V4VOP_unregister_ring
+ *
+ * Unregister a ring.
+ *
+ * do_v4v_op(V4VOP_unregister_ring,
+ *           XEN_GUEST_HANDLE(v4v_ring),
+ *           NULL, 0, 0)
+ */
+#define V4VOP_unregister_ring 	2
+
+/*
+ * V4VOP_send
+ *
+ * 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.
+ * message_type is the 32 bit number used from the message
+ * most likely V4V_MESSAGE_DGRAM or V4V_MESSAGE_STREAM. If insufficient =
space exists
+ * it will return -EAGAIN and xen will twing the V4V_INTERRUPT when
+ * sufficient space becomes available
+ *
+ * do_v4v_op(V4VOP_send,
+ *           XEN_GUEST_HANDLE(v4v_send_addr_t) addr,
+ *           XEN_GUEST_HANDLE(void) buf,
+ *           uint32_t len,
+ *           uint32_t message_type)
+ */
+#define V4VOP_send 		3
+
+
+/*
+ * V4VOP_notify
+ *
+ * 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
+ *
+ * do_v4v_op(V4VOP_notify,
+ *           XEN_GUEST_HANDLE(v4v_ring_data_ent) ent,
+ *           NULL, 0, 0)
+ */
+#define V4VOP_notify 		4
+
+/*
+ * V4VOP_sendv
+ *
+ * Identical to V4VOP_send except rather than buf and len it takes
+ * an array of v4v_iov and a length of the array.
+ *
+ * do_v4v_op(V4VOP_sendv,
+ *           XEN_GUEST_HANDLE(v4v_send_addr_t) addr,
+ *           XEN_GUEST_HANDLE(v4v_iov) iov,
+ *           uint32_t niov,
+ *           uint32_t message_type)
+ */
+#define V4VOP_sendv		5
+
+/*
+ * V4VOP_viptables_add
+ *
+ * Insert a filtering rules after a given position.
+ *
+ * do_v4v_op(V4VOP_viptables_add,
+ *           XEN_GUEST_HANDLE(v4v_viptables_rule_t) rule,
+ *           NULL,
+ *           uint32_t position, 0)
+ */
+#define V4VOP_viptables_add     6
+
+/*
+ * V4VOP_viptables_del
+ *
+ * Delete a filtering rules at a position or the rule
+ * that matches "rule".
+ *
+ * do_v4v_op(V4VOP_viptables_del,
+ *           XEN_GUEST_HANDLE(v4v_viptables_rule_t) rule,
+ *           NULL,
+ *           uint32_t position, 0)
+ */
+#define V4VOP_viptables_del     7
+
+/*
+ * V4VOP_viptables_list
+ *
+ * Delete a filtering rules at a position or the rule
+ * that matches "rule".
+ *
+ * do_v4v_op(V4VOP_viptables_list,
+ *           XEN_GUEST_HANDLE(v4v_vitpables_list_t) list,
+ *           NULL, 0, 0)
+ */
+#define V4VOP_viptables_list    8
+
+/*
+ * V4VOP_info
+ *
+ * Returns v4v info for the current domain (domain that issued the hyper=
call).
+ *      - V4V magic number
+ *      - event channel port (for current domain)
+ *
+ * do_v4v_op(V4VOP_info,
+ *           XEN_GUEST_HANDLE(v4v_info_t) info,
+ *           NULL, 0, 0)
+ */
+#define V4VOP_info              9
+
+#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 8def420..7a3fade 100644
--- a/xen/include/public/xen.h
+++ b/xen/include/public/xen.h
@@ -97,7 +97,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..296de52 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,9 @@ struct domain
     nodemask_t node_affinity;
     unsigned int last_alloc_node;
     spinlock_t node_affinity_lock;
+
+    /* v4v */
+    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..05d20b5
--- /dev/null
+++ b/xen/include/xen/v4v.h
@@ -0,0 +1,133 @@
+/***********************************************************************=
*******
+ * 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
+
+/*
+ * Handlers
+ */
+
+DEFINE_XEN_GUEST_HANDLE (v4v_iov_t);
+DEFINE_XEN_GUEST_HANDLE (v4v_addr_t);
+DEFINE_XEN_GUEST_HANDLE (v4v_send_addr_t);
+DEFINE_XEN_GUEST_HANDLE (v4v_ring_t);
+DEFINE_XEN_GUEST_HANDLE (v4v_ring_data_ent_t);
+DEFINE_XEN_GUEST_HANDLE (v4v_ring_data_t);
+DEFINE_XEN_GUEST_HANDLE (v4v_info_t);
+
+DEFINE_XEN_GUEST_HANDLE (v4v_viptables_rule_t);
+DEFINE_XEN_GUEST_HANDLE (v4v_viptables_list_t);
+
+/*
+ * Helper functions
+ */
+
+static inline uint16_t
+v4v_hash_fn (v4v_ring_id_t *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;
+};
+
+
+struct v4v_ring_info
+{
+    /* next node in the hash, protected by L2  */
+    struct hlist_node node;
+    /* this ring's id, protected by L2 */
+    v4v_ring_id_t 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;
+    /* event channel */
+    evtchn_port_t evtchn_port;
+    /* protected by L2 */
+    struct hlist_head ring_hash[V4V_HTABLE_SIZE];
+};
+
+typedef struct v4v_viptables_rule_node
+{
+    struct list_head list;
+    v4v_viptables_rule_t rule;
+} v4v_viptables_rule_node_t;
+
+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,
+                uint32_t arg3,
+                uint32_t arg4);
+
+#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 Sep 20 09:46:00 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Sep 2012 09: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 1TEdKP-0005Qc-LR; Thu, 20 Sep 2012 09:45:49 +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 1TEdKM-0005Pe-To
	for xen-devel@lists.xen.org; Thu, 20 Sep 2012 09:45:47 +0000
Received: from [85.158.137.99:56131] by server-5.bemta-3.messagelabs.com id
	0B/78-13133-9C5EA505; Thu, 20 Sep 2012 09:45:45 +0000
X-Env-Sender: jean.guyader@citrix.com
X-Msg-Ref: server-8.tower-217.messagelabs.com!1348134343!13075422!4
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTA0NTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7986 invoked from network); 20 Sep 2012 09:45:44 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Sep 2012 09:45:44 -0000
X-IronPort-AV: E=Sophos;i="4.80,453,1344211200"; d="scan'208";a="14650467"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Sep 2012 09:44: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.279.1; Thu, 20 Sep 2012 10:44: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 1TEdJR-0007kn-2I;
	Thu, 20 Sep 2012 09:44:49 +0000
Received: by spongy (Postfix, from userid 2023)	id 3D3D3341ABF; Thu, 20 Sep
	2012 10:47:08 +0100 (BST)
From: Jean Guyader <jean.guyader@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Thu, 20 Sep 2012 10:47:06 +0100
Message-ID: <1348134426-25320-5-git-send-email-jean.guyader@citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <1348134426-25320-1-git-send-email-jean.guyader@citrix.com>
References: <1348134426-25320-1-git-send-email-jean.guyader@citrix.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="------------true"
Cc: tim@xen.org, Jean Guyader <jean.guyader@citrix.com>, JBeulich@suse.com
Subject: [Xen-devel] [PATCH 4/4] 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             |    6 +-
 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                |   13 +-
 xen/common/v4v.c                   | 1905 ++++++++++++++++++++++++++++++=
++++++
 xen/include/public/v4v.h           |  308 ++++++
 xen/include/public/xen.h           |    2 +-
 xen/include/xen/sched.h            |    4 +
 xen/include/xen/v4v.h              |  133 +++
 10 files changed, 2372 insertions(+), 4 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 d69e419..b685535 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -3183,7 +3183,8 @@ static hvm_hypercall_t *const hvm_hypercall64_table=
[NR_hypercalls] =3D {
     HYPERCALL(set_timer_op),
     HYPERCALL(hvm_op),
     HYPERCALL(sysctl),
-    HYPERCALL(tmem_op)
+    HYPERCALL(tmem_op),
+    HYPERCALL(v4v_op)
 };
=20
 #define COMPAT_CALL(x)                                        \
@@ -3200,7 +3201,8 @@ static hvm_hypercall_t *const hvm_hypercall32_table=
[NR_hypercalls] =3D {
     COMPAT_CALL(set_timer_op),
     HYPERCALL(hvm_op),
     HYPERCALL(sysctl),
-    HYPERCALL(tmem_op)
+    HYPERCALL(tmem_op),
+    HYPERCALL(v4v_op)
 };
=20
 int hvm_do_hypercall(struct cpu_user_regs *regs)
diff --git a/xen/arch/x86/x86_64/compat/entry.S b/xen/arch/x86/x86_64/com=
pat/entry.S
index 2f606ab..f518a03 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 5 /* 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 8156827..5f4e7bf 100644
--- a/xen/arch/x86/x86_64/entry.S
+++ b/xen/arch/x86/x86_64/entry.S
@@ -707,6 +707,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
@@ -755,6 +756,7 @@ ENTRY(hypercall_args_table)
         .byte 1 /* do_domctl            */
         .byte 2 /* do_kexec             */
         .byte 1 /* do_tmem_op           */
+        .byte 5 /* 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 c1c100f..ba63cec 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 a1aa05e..94283e3 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 err, init_status =3D 0;
     int poolid =3D CPUPOOLID_NONE;
=20
@@ -307,6 +308,13 @@ struct domain *domain_create(
         spin_unlock(&domlist_update_lock);
     }
=20
+    if ( !is_idle_domain(d) )
+    {
+        if ( v4v_init(d) !=3D 0 )
+            goto fail;
+        init_status |=3D INIT_v4v;
+    }
+
     return d;
=20
  fail:
@@ -315,6 +323,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 )
@@ -468,6 +478,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..afb9267
--- /dev/null
+++ b/xen/common/v4v.c
@@ -0,0 +1,1905 @@
+/***********************************************************************=
*******
+ * 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 <asm/types.h>
+
+#ifdef V4V_DEBUG
+#define v4v_dprintk(format, args...)            \
+    do {                                        \
+        printk("%s:%d " format,                 \
+               __FILE__, __LINE__, ## args );   \
+    } while ( 1 =3D=3D 0 )
+#else
+#define v4v_dprintk(format, ... ) (void)0
+#endif
+
+/*
+ * 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
+ */
+#define V4V_ROUNDUP(a) (((a) +0xf ) & ~0xf)
+
+DEFINE_XEN_GUEST_HANDLE(uint8_t);
+static struct v4v_ring_info *v4v_ring_find_info(struct domain *d,
+                                                v4v_ring_id_t *id);
+
+static struct v4v_ring_info *v4v_ring_find_info_by_addr(struct domain *d=
,
+                                                        struct v4v_addr =
*a,
+                                                        domid_t p);
+
+typedef struct internal_v4v_iov
+{
+    XEN_GUEST_HANDLE(v4v_iov_t) guest_iov;
+    v4v_iov_t                   *xen_iov;
+} internal_v4v_iov_t;
+
+struct list_head viprules =3D LIST_HEAD_INIT(viprules);
+
+/*
+ * 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
+ */
+
+/*
+ * lock to protect the filtering rules list: viprules
+ *
+ * The write lock is held for viptables_del and viptables_add
+ * The read lock is held for viptable_list
+ */
+static DEFINE_RWLOCK(viprules_lock);
+
+
+/*
+ * Debugs
+ */
+
+#ifdef V4V_DEBUG
+static void __attribute__((unused))
+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);
+
+    evtchn_send(d, d->v4v->evtchn_port);
+}
+
+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
+ */
+
+static void
+v4v_ring_unmap(struct v4v_ring_info *ring_info)
+{
+    int i;
+
+    ASSERT(spin_is_locked(&ring_info->lock));
+
+    for ( i =3D 0; i < ring_info->npage; ++i )
+    {
+        if ( !ring_info->mfn_mapping[i] )
+            continue;
+        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;
+    }
+}
+
+static uint8_t *
+v4v_ring_map_page(struct v4v_ring_info *ring_info, int i)
+{
+    ASSERT(spin_is_locked(&ring_info->lock));
+
+    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->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];
+}
+
+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;
+
+    ASSERT(spin_is_locked(&ring_info->lock));
+
+    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;
+}
+
+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);
+    uint32_t *p =3D (uint32_t *)(dst + offsetof(v4v_ring_t, tx_ptr));
+
+    ASSERT(spin_is_locked(&ring_info->lock));
+
+    if ( !dst )
+        return -EFAULT;
+    write_atomic(p, tx_ptr);
+    mb();
+    return 0;
+}
+
+static int
+v4v_copy_from_guest_maybe(void *dst, void *src,
+                          XEN_GUEST_HANDLE(uint8_t) src_hnd,
+                          uint32_t len)
+{
+    int rc =3D 0;
+
+    if ( src )
+        memcpy(dst, src, len);
+    else
+        rc =3D copy_from_guest(dst, src_hnd, len);
+    return rc;
+}
+
+static int
+v4v_memcpy_to_guest_ring(struct v4v_ring_info *ring_info,
+                         uint32_t offset,
+                         void *src,
+                         XEN_GUEST_HANDLE(uint8_t) src_hnd,
+                         uint32_t len)
+{
+    int page =3D offset >> PAGE_SHIFT;
+    uint8_t *dst;
+
+    ASSERT(spin_is_locked(&ring_info->lock));
+
+    offset &=3D PAGE_SIZE - 1;
+
+    while ( (offset + len) > PAGE_SIZE )
+    {
+        dst =3D v4v_ring_map_page(ring_info, page);
+        if ( !dst )
+            return -EFAULT;
+
+        if ( v4v_copy_from_guest_maybe(dst + offset, src, src_hnd,
+                                       PAGE_SIZE - offset) )
+            return -EFAULT;
+
+        page++;
+        len -=3D PAGE_SIZE - offset;
+        if ( src )
+            src +=3D (PAGE_SIZE - offset);
+        else
+            guest_handle_add_offset(src_hnd, PAGE_SIZE - offset);
+        offset =3D 0;
+    }
+
+    dst =3D v4v_ring_map_page(ring_info, page);
+    if ( !dst )
+        return -EFAULT;
+
+    if ( v4v_copy_from_guest_maybe(dst + offset, src, src_hnd, len) )
+        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 =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;
+
+    write_atomic(rx_ptr, ringp->rx_ptr);
+    mb();
+
+    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 =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;
+}
+
+static unsigned long
+v4v_iov_copy(v4v_iov_t *iov, internal_v4v_iov_t *iovs)
+{
+    if (iovs->xen_iov =3D=3D NULL)
+    {
+        return copy_from_guest(iov, iovs->guest_iov, 1);
+    }
+    else
+    {
+        *iov =3D *(iovs->xen_iov);
+        return 0;
+    }
+}
+
+static void
+v4v_iov_add_offset(internal_v4v_iov_t *iovs, int offset)
+{
+    if (iovs->xen_iov =3D=3D NULL)
+        guest_handle_add_offset(iovs->guest_iov, offset);
+    else
+        iovs->xen_iov +=3D offset;
+}
+
+static long
+v4v_iov_count(internal_v4v_iov_t iovs, int niov)
+{
+    v4v_iov_t iov;
+    size_t ret =3D 0;
+
+    while ( niov-- )
+    {
+        if ( v4v_iov_copy(&iov, &iovs) )
+            return -EFAULT;
+
+        /* message bigger than 2G can't be sent */
+        if (ret > 2L * 1024 * 1024 * 1024)
+            return -EMSGSIZE;
+
+        ret +=3D iov.iov_len;
+        v4v_iov_add_offset(&iovs, 1);
+    }
+
+    return ret;
+}
+
+static long
+v4v_ringbuf_insertv(struct domain *d,
+                    struct v4v_ring_info *ring_info,
+                    v4v_ring_id_t *src_id, uint32_t proto,
+                    internal_v4v_iov_t iovs, uint32_t niov,
+                    size_t len)
+{
+    v4v_ring_t ring;
+    struct v4v_ring_message_header mh =3D { 0 };
+    int32_t sp;
+    long happy_ret;
+    int32_t ret =3D 0;
+    XEN_GUEST_HANDLE(uint8_t) empty_hnd =3D { 0 };
+
+    ASSERT(spin_is_locked(&ring_info->lock));
+
+    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.message_type =3D proto;
+
+        if ( (ret =3D v4v_memcpy_to_guest_ring(ring_info,
+                                             ring.tx_ptr + sizeof (v4v_r=
ing_t),
+                                             &mh, empty_hnd,
+                                             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 ( v4v_iov_copy(&iov, &iovs) )
+            {
+                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 )
+            {
+                ret =3D v4v_memcpy_to_guest_ring(ring_info,
+                        ring.tx_ptr + sizeof (v4v_ring_t),
+                        NULL, buf_hnd, sp);
+                if ( ret )
+                    break;
+
+                ring.tx_ptr =3D 0;
+                len -=3D sp;
+                guest_handle_add_offset(buf_hnd, sp);
+            }
+
+            ret =3D v4v_memcpy_to_guest_ring(ring_info,
+                    ring.tx_ptr + sizeof (v4v_ring_t),
+                    NULL, buf_hnd, len);
+            if ( ret )
+                break;
+
+            ring.tx_ptr +=3D len;
+
+            if ( ring.tx_ptr =3D=3D ring_info->len )
+                ring.tx_ptr =3D 0;
+
+            v4v_iov_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);
+}
+
+static void
+v4v_pending_remove_all(struct v4v_ring_info *info)
+{
+    struct hlist_node *node, *next;
+    struct v4v_pending_ent *pending_ent;
+
+    ASSERT(spin_is_locked(&info->lock));
+    hlist_for_each_entry_safe(pending_ent, node, next, &info->pending,
+            node) v4v_pending_remove_ent(pending_ent);
+}
+
+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;
+
+    ASSERT(rw_is_locked(&v4v_lock));
+
+    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);
+    }
+
+}
+
+static void
+v4v_pending_find(struct domain *d, 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;
+
+    ASSERT(rw_is_locked(&d->v4v->lock));
+
+    spin_lock(&ring_info->lock);
+    hlist_for_each_entry_safe(ent, node, next, &ring_info->pending, node=
)
+    {
+        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 l=
en)
+{
+    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, int=
 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, node=
)
+    {
+        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(xen_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);
+    }
+    return ret;
+}
+
+
+static struct v4v_ring_info *
+v4v_ring_find_info(struct domain *d, v4v_ring_id_t *id)
+{
+    uint16_t hash;
+    struct hlist_node *node;
+    struct v4v_ring_info *ring_info;
+
+    ASSERT(rw_is_locked(&d->v4v->lock));
+
+    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], node=
)
+    {
+        v4v_ring_id_t *cmpid =3D &ring_info->id;
+
+        if ( cmpid->addr.port =3D=3D id->addr.port &&
+             cmpid->addr.domain =3D=3D id->addr.domain &&
+             cmpid->partner =3D=3D id->partner)
+        {
+            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;
+}
+
+static struct v4v_ring_info *
+v4v_ring_find_info_by_addr(struct domain *d, struct v4v_addr *a, domid_t=
 p)
+{
+    v4v_ring_id_t id;
+    struct v4v_ring_info *ret;
+
+    ASSERT(rw_is_locked(&d->v4v->lock));
+
+    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_ANY;
+
+    return v4v_ring_find_info(d, &id);
+}
+
+static void v4v_ring_remove_mfns(struct domain *d, struct v4v_ring_info =
*ring_info)
+{
+    int i;
+
+    ASSERT(rw_is_write_locked(&d->v4v->lock));
+
+    if ( ring_info->mfns )
+    {
+        for ( i =3D 0; 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);
+    }
+    if ( ring_info->mfn_mapping )
+        xfree(ring_info->mfn_mapping);
+    ring_info->mfns =3D NULL;
+
+}
+
+static void
+v4v_ring_remove_info(struct domain *d, struct v4v_ring_info *ring_info)
+{
+    ASSERT(rw_is_write_locked(&d->v4v->lock));
+
+    spin_lock(&ring_info->lock);
+
+    v4v_pending_remove_all(ring_info);
+    hlist_del(&ring_info->node);
+    v4v_ring_remove_mfns(d, ring_info);
+
+    spin_unlock(&ring_info->lock);
+
+    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 =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(d, 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(xen_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 rin=
g.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.
+             */
+            printk(KERN_INFO "v4v: dom%d ring already registered\n",
+                    current->domain->domain_id);
+            ret =3D -EEXIST;
+            break;
+        }
+
+        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
+ */
+
+static void
+v4v_notify_ring(struct domain *d, struct v4v_ring_info *ring_info,
+                struct hlist_head *to_notify)
+{
+    uint32_t space;
+
+    ASSERT(rw_is_locked(&v4v_lock));
+    ASSERT(rw_is_locked(&d->v4v->lock));
+
+    spin_lock(&ring_info->lock);
+    space =3D v4v_ringbuf_payload_space(d, ring_info);
+    spin_unlock(&ring_info->lock);
+
+    v4v_pending_find(d, 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, data[0]);
+                ret =3D v4v_fill_ring_datas(d, ring_data.nent, ring_data=
_ent_hnd);
+            }
+        }
+    }
+    while ( 0 );
+
+    read_unlock(&v4v_lock);
+
+    return ret;
+}
+
+#ifdef V4V_DEBUG
+void
+v4v_viptables_print_rule(struct v4v_viptables_rule_node *node)
+{
+    v4v_viptables_rule_t *rule;
+
+    if ( node =3D=3D NULL )
+    {
+        printk("(null)\n");
+        return;
+    }
+
+    rule =3D &node->rule;
+
+    if ( rule->accept =3D=3D 1 )
+        printk("ACCEPT");
+    else
+        printk("REJECT");
+
+    printk(" ");
+
+    if ( rule->src.domain =3D=3D V4V_DOMID_ANY )
+        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 V4V_DOMID_ANY )
+        printk("*");
+    else
+        printk("%i", rule->dst.domain);
+
+    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 =3D NULL;
+    struct list_head* tmp;
+
+    ASSERT(rw_is_write_locked(&viprules_lock));
+
+    /* First rule is n.1 */
+    position--;
+
+    new =3D xmalloc(struct v4v_viptables_rule_node);
+    if ( new =3D=3D NULL )
+        return -ENOMEM;
+
+    if ( copy_from_guest(&new->rule, rule, 1) )
+    {
+        xfree(new);
+        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_hnd,
+                  int32_t position)
+{
+    struct list_head *tmp =3D NULL;
+    struct list_head *next =3D NULL;
+    struct v4v_viptables_rule_node *node;
+
+    ASSERT(rw_is_write_locked(&viprules_lock));
+
+    v4v_dprintk("v4v_viptables_del position:%d\n", position);
+
+    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_hnd) )
+    {
+        struct v4v_viptables_rule r;
+
+        if ( copy_from_guest(&r, rule_hnd, 1) )
+            return -EFAULT;
+
+        list_for_each(tmp, &viprules)
+        {
+            node =3D list_entry(tmp, struct v4v_viptables_rule_node, lis=
t);
+
+            if ( (node->rule.src.domain =3D=3D r.src.domain) &&
+                 (node->rule.src.port   =3D=3D r.src.port)   &&
+                 (node->rule.dst.domain =3D=3D r.dst.domain) &&
+                 (node->rule.dst.port   =3D=3D r.dst.port))
+            {
+                position =3D 0;
+                break;
+            }
+        }
+    }
+    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, lis=
t);
+            list_del(tmp);
+            xfree(node);
+        }
+    }
+
+    if ( position =3D=3D 0 && tmp !=3D &viprules )
+    {
+        node =3D list_entry(tmp, struct v4v_viptables_rule_node, list);
+#ifdef V4V_DEBUG
+        printk(KERN_ERR "VIPTables: deleting rule: ");
+        v4v_viptables_print_rule(node);
+#endif /* V4V_DEBUG */
+        list_del(tmp);
+        xfree(node);
+    }
+
+    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;
+    XEN_GUEST_HANDLE(v4v_viptables_rule_t) guest_rules;
+
+    ASSERT(rw_is_locked(&viprules_lock));
+
+    memset(&rules_list, 0, sizeof (rules_list));
+    if ( copy_from_guest(&rules_list, list_hnd, 1) )
+        return -EFAULT;
+
+    ptr =3D viprules.next;
+    while ( rules_list.start_rule !=3D 0 && ptr->next !=3D &viprules )
+    {
+        ptr =3D ptr->next;
+        rules_list.start_rule--;
+    }
+
+    if ( rules_list.nb_rules =3D=3D 0 )
+        return -EINVAL;
+
+    guest_rules =3D guest_handle_for_field(list_hnd, v4v_viptables_rule_=
t, rules[0]);
+
+    nbrules =3D 0;
+    while ( nbrules < rules_list.nb_rules && ptr !=3D &viprules )
+    {
+        node =3D list_entry(ptr, struct v4v_viptables_rule_node, list);
+
+        if ( !guest_handle_okay(guest_rules, 1) )
+            break;
+
+        if ( copy_to_guest(guest_rules, &node->rule, 1) )
+            break;
+
+        guest_handle_add_offset(guest_rules, 1);
+
+        nbrules++;
+        ptr =3D ptr->next;
+    }
+
+    rules_list.nb_rules =3D nbrules;
+    if ( copy_field_to_guest(list_hnd, &rules_list, nb_rules) )
+        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;
+    size_t ret =3D 0; /* Defaulting to ACCEPT */
+
+    read_lock(&viprules_lock);
+
+    list_for_each(ptr, &viprules)
+    {
+        node =3D list_entry(ptr, struct v4v_viptables_rule_node, list);
+
+        if ( (node->rule.src.domain =3D=3D V4V_DOMID_ANY ||
+              node->rule.src.domain =3D=3D src->domain) &&
+             (node->rule.src.port =3D=3D V4V_PORT_ANY ||
+              node->rule.src.port =3D=3D src->port) &&
+             (node->rule.dst.domain =3D=3D V4V_DOMID_ANY ||
+              node->rule.dst.domain =3D=3D dst->domain) &&
+             (node->rule.dst.port =3D=3D V4V_PORT_ANY ||
+              node->rule.dst.port =3D=3D dst->port) )
+        {
+            ret =3D !node->rule.accept;
+            break;
+        }
+    }
+
+    read_unlock(&viprules_lock);
+    return ret;
+}
+
+/*
+ * Hypercall to do the send
+ */
+static long
+v4v_sendv(struct domain *src_d, v4v_addr_t * src_addr,
+          v4v_addr_t * dst_addr, uint32_t proto,
+          internal_v4v_iov_t iovs, size_t niov)
+{
+    struct domain *dst_d;
+    v4v_ring_id_t 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;
+    }
+
+    if ( v4v_viptables_check(src_addr, dst_addr) !=3D 0 )
+    {
+        read_unlock(&v4v_lock);
+        gdprintk(XENLOG_WARNING,
+                 "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 )
+        {
+            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->domain=
);
+
+        if ( !ring_info )
+        {
+            ret =3D -ECONNREFUSED;
+            v4v_dprintk(" !ring_info, ECONNREFUSED\n");
+        }
+        else
+        {
+            long 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, io=
vs,
+                        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;
+}
+
+static void
+v4v_info(struct domain *d, v4v_info_t *info)
+{
+    read_lock(&d->v4v->lock);
+    info->ring_magic =3D V4V_RING_MAGIC;
+    info->data_magic =3D V4V_RING_DATA_MAGIC;
+    info->evtchn =3D d->v4v->evtchn_port;
+    read_unlock(&d->v4v->lock);
+}
+
+/*
+ * hypercall glue
+ */
+long
+do_v4v_op(int cmd, XEN_GUEST_HANDLE(void) arg1,
+          XEN_GUEST_HANDLE(void) arg2,
+          uint32_t arg3, uint32_t arg4)
+{
+    struct domain *d =3D current->domain;
+    long rc =3D -EFAULT;
+
+    v4v_dprintk("->do_v4v_op(%d,%p,%p,%d,%d)\n", cmd,
+                (void *)arg1.p, (void *)arg2.p, (int) arg3, (int) arg4);
+
+    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(xen_pfn_t) pfn_hnd =3D
+                    guest_handle_cast(arg2, xen_pfn_t);
+                uint32_t npage =3D arg3;
+                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:
+            {
+                uint32_t len =3D arg3;
+                uint32_t message_type =3D arg4;
+                v4v_iov_t iov;
+                internal_v4v_iov_t iovs;
+                XEN_GUEST_HANDLE(v4v_send_addr_t) addr_hnd =3D
+                    guest_handle_cast(arg1, v4v_send_addr_t);
+                v4v_send_addr_t addr;
+
+                if ( unlikely(!guest_handle_okay(addr_hnd, 1)) )
+                    goto out;
+                if ( copy_from_guest(&addr, addr_hnd, 1) )
+                    goto out;
+
+                iov.iov_base =3D (uint64_t)arg2.p; // FIXME
+                iov.iov_len =3D len;
+                iovs.xen_iov =3D &iov;
+                rc =3D v4v_sendv(d, &addr.src, &addr.dst, message_type, =
iovs, 1);
+                break;
+            }
+        case V4VOP_sendv:
+            {
+                internal_v4v_iov_t iovs;
+                uint32_t niov =3D arg3;
+                uint32_t message_type =3D arg4;
+                XEN_GUEST_HANDLE(v4v_send_addr_t) addr_hnd =3D
+                    guest_handle_cast(arg1, v4v_send_addr_t);
+                v4v_send_addr_t addr;
+
+                memset(&iovs, 0, sizeof (iovs));
+                iovs.guest_iov =3D guest_handle_cast(arg2, v4v_iov_t);
+
+                if ( unlikely(!guest_handle_okay(addr_hnd, 1)) )
+                    goto out;
+                if ( copy_from_guest(&addr, addr_hnd, 1) )
+                    goto out;
+
+                if ( unlikely(!guest_handle_okay(iovs.guest_iov, niov)) =
)
+                    goto out;
+
+                rc =3D v4v_sendv(d, &addr.src, &addr.dst, message_type, =
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;
+            }
+        case V4VOP_viptables_add:
+            {
+                uint32_t position =3D arg3;
+                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;
+
+                write_lock(&viprules_lock);
+                rc =3D v4v_viptables_add(d, rule_hnd, position);
+                write_unlock(&viprules_lock);
+                break;
+            }
+        case V4VOP_viptables_del:
+            {
+                uint32_t position =3D arg3;
+                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;
+
+                write_lock(&viprules_lock);
+                rc =3D v4v_viptables_del(d, rule_hnd, position);
+                write_unlock(&viprules_lock);
+                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 -EFAULT;
+                if ( unlikely(!guest_handle_okay(rules_list_hnd, 1)) )
+                    goto out;
+
+                read_lock(&viprules_lock);
+                rc =3D v4v_viptables_list(d, rules_list_hnd);
+                read_unlock(&viprules_lock);
+                break;
+            }
+        case V4VOP_info:
+            {
+                XEN_GUEST_HANDLE(v4v_info_t) info_hnd =3D
+                    guest_handle_cast(arg1, v4v_info_t);
+                v4v_info_t info;
+
+                if ( unlikely(!guest_handle_okay(info_hnd, 1)) )
+                    goto out;
+                v4v_info(d, &info);
+                if ( copy_to_guest(info_hnd, &info, 1) )
+                    goto out;
+                rc =3D 0;
+                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(d, ring_info);
+            }
+        }
+    }
+
+    d->v4v =3D NULL;
+    write_unlock(&v4v_lock);
+}
+
+int
+v4v_init(struct domain *d)
+{
+    struct v4v_domain *v4v;
+    evtchn_port_t port;
+    int i;
+    int rc;
+
+    v4v =3D xmalloc(struct v4v_domain);
+    if ( !v4v )
+        return -ENOMEM;
+
+    rc =3D evtchn_alloc_unbound_domain(d, &port, d->domain_id);
+    if ( rc )
+        return rc;
+
+    rwlock_init(&v4v->lock);
+
+    v4v->evtchn_port =3D port;
+    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 npage=
=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(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], nod=
e)
+            dump_domain_ring(d, ring_info);
+    }
+
+    printk(KERN_ERR "  event channel: %d\n",  d->v4v->evtchn_port);
+    read_unlock(&d->v4v->lock);
+
+    printk(KERN_ERR "\n");
+    v4v_signal_domain(d);
+}
+
+static void
+dump_state(unsigned char key)
+{
+    struct domain *d;
+
+    printk(KERN_ERR "\n\nV4V:\n");
+    read_lock(&v4v_lock);
+
+    rcu_read_lock(&domlist_read_lock);
+
+    for_each_domain(d)
+        dump_domain(d);
+
+    rcu_read_unlock(&domlist_read_lock);
+
+    read_unlock(&v4v_lock);
+}
+
+struct keyhandler v4v_info_keyhandler =3D
+{
+    .diagnostic =3D 1,
+    .u.fn =3D dump_state,
+    .desc =3D "dump v4v states and interupt"
+};
+
+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..6a9d55c
--- /dev/null
+++ b/xen/include/public/v4v.h
@@ -0,0 +1,308 @@
+/***********************************************************************=
*******
+ * 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"
+#include "event_channel.h"
+
+/*
+ * Structure definitions
+ */
+
+#define V4V_RING_MAGIC          0xa822f72bb0b9d8ccULL
+#define V4V_RING_DATA_MAGIC	0x45fe852220b801d4ULL
+
+#define V4V_MESSAGE_DGRAM       0x3c2c1db8
+#define V4V_MESSAGE_STREAM 	0x70f6a8e5
+
+#define V4V_DOMID_ANY           DOMID_INVALID
+#define V4V_PORT_ANY            0
+
+typedef struct v4v_iov
+{
+    uint64_t iov_base;
+    uint32_t iov_len;
+    uint32_t pad;
+} v4v_iov_t;
+
+typedef struct v4v_addr
+{
+    uint32_t port;
+    domid_t domain;
+    uint16_t pad;
+} v4v_addr_t;
+
+typedef struct v4v_ring_id
+{
+    v4v_addr_t addr;
+    domid_t partner;
+    uint16_t pad;
+} v4v_ring_id_t;
+
+typedef struct
+{
+    v4v_addr_t src;
+    v4v_addr_t dst;
+} v4v_send_addr_t;
+
+/*
+ * v4v_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
+ *
+ */
+struct v4v_ring
+{
+    uint64_t magic;
+    v4v_ring_id_t id;
+    uint32_t len;
+    uint32_t rx_ptr;
+    uint32_t tx_ptr;
+    uint8_t reserved[32];
+    uint8_t ring[];
+};
+typedef struct v4v_ring v4v_ring_t;
+
+#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 exist=
s - do not
+                                               * rely on this field - fo=
r
+                                               * profiling only */
+#define V4V_RING_DATA_F_SUFFICIENT  (1U << 3) /* Sufficient space to que=
ue
+                                               * space_required bytes ex=
ists */
+
+typedef struct v4v_ring_data_ent
+{
+    v4v_addr_t ring;
+    uint16_t flags;
+    uint16_t pad1;
+    uint32_t pad2;
+    uint32_t space_required;
+    uint32_t max_message_size;
+} v4v_ring_data_ent_t;
+
+typedef struct v4v_ring_data
+{
+    uint64_t magic;
+    uint32_t nent;
+    uint32_t pad;
+    uint64_t reserved[4];
+    v4v_ring_data_ent_t data[];
+} v4v_ring_data_t;
+
+struct v4v_info
+{
+    uint64_t ring_magic;
+    uint64_t data_magic;
+    evtchn_port_t evtchn;
+    uint32_t pad;
+};
+typedef struct v4v_info v4v_info_t;
+
+#define V4V_SHF_SYN		(1 << 0)
+#define V4V_SHF_ACK		(1 << 1)
+#define V4V_SHF_RST		(1 << 2)
+
+#define V4V_SHF_PING		(1 << 8)
+#define V4V_SHF_PONG		(1 << 9)
+
+struct v4v_stream_header
+{
+    uint32_t flags;
+    uint32_t conid;
+};
+
+struct v4v_ring_message_header
+{
+    uint32_t len;
+    uint32_t pad0;
+    v4v_addr_t source;
+    uint32_t message_type;
+    uint32_t pad1;
+    uint8_t data[];
+};
+
+typedef struct v4v_viptables_rule
+{
+    v4v_addr_t src;
+    v4v_addr_t dst;
+    uint32_t accept;
+    uint32_t pad;
+} v4v_viptables_rule_t;
+
+typedef struct v4v_viptables_list
+{
+    uint32_t start_rule;
+    uint32_t nb_rules;
+    struct v4v_viptables_rule rules[];
+} v4v_viptables_list_t;
+
+/*
+ * HYPERCALLS
+ */
+
+/*
+ * V4VOP_register_ring
+ *
+ * Registers a ring with Xen. If a ring with the same v4v_ring_id exists=
,
+ * the hypercall will return -EEXIST.
+ *
+ * do_v4v_op(V4VOP_unregister_ring,
+ *           XEN_GUEST_HANDLE(v4v_ring_t), XEN_GUEST_HANDLE(xen_pfn_t),
+ *           npage, 0)
+ */
+#define V4VOP_register_ring 	1
+
+
+/*
+ * V4VOP_unregister_ring
+ *
+ * Unregister a ring.
+ *
+ * do_v4v_op(V4VOP_unregister_ring,
+ *           XEN_GUEST_HANDLE(v4v_ring),
+ *           NULL, 0, 0)
+ */
+#define V4VOP_unregister_ring 	2
+
+/*
+ * V4VOP_send
+ *
+ * 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.
+ * message_type is the 32 bit number used from the message
+ * most likely V4V_MESSAGE_DGRAM or V4V_MESSAGE_STREAM. If insufficient =
space exists
+ * it will return -EAGAIN and xen will twing the V4V_INTERRUPT when
+ * sufficient space becomes available
+ *
+ * do_v4v_op(V4VOP_send,
+ *           XEN_GUEST_HANDLE(v4v_send_addr_t) addr,
+ *           XEN_GUEST_HANDLE(void) buf,
+ *           uint32_t len,
+ *           uint32_t message_type)
+ */
+#define V4VOP_send 		3
+
+
+/*
+ * V4VOP_notify
+ *
+ * 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
+ *
+ * do_v4v_op(V4VOP_notify,
+ *           XEN_GUEST_HANDLE(v4v_ring_data_ent) ent,
+ *           NULL, 0, 0)
+ */
+#define V4VOP_notify 		4
+
+/*
+ * V4VOP_sendv
+ *
+ * Identical to V4VOP_send except rather than buf and len it takes
+ * an array of v4v_iov and a length of the array.
+ *
+ * do_v4v_op(V4VOP_sendv,
+ *           XEN_GUEST_HANDLE(v4v_send_addr_t) addr,
+ *           XEN_GUEST_HANDLE(v4v_iov) iov,
+ *           uint32_t niov,
+ *           uint32_t message_type)
+ */
+#define V4VOP_sendv		5
+
+/*
+ * V4VOP_viptables_add
+ *
+ * Insert a filtering rules after a given position.
+ *
+ * do_v4v_op(V4VOP_viptables_add,
+ *           XEN_GUEST_HANDLE(v4v_viptables_rule_t) rule,
+ *           NULL,
+ *           uint32_t position, 0)
+ */
+#define V4VOP_viptables_add     6
+
+/*
+ * V4VOP_viptables_del
+ *
+ * Delete a filtering rules at a position or the rule
+ * that matches "rule".
+ *
+ * do_v4v_op(V4VOP_viptables_del,
+ *           XEN_GUEST_HANDLE(v4v_viptables_rule_t) rule,
+ *           NULL,
+ *           uint32_t position, 0)
+ */
+#define V4VOP_viptables_del     7
+
+/*
+ * V4VOP_viptables_list
+ *
+ * Delete a filtering rules at a position or the rule
+ * that matches "rule".
+ *
+ * do_v4v_op(V4VOP_viptables_list,
+ *           XEN_GUEST_HANDLE(v4v_vitpables_list_t) list,
+ *           NULL, 0, 0)
+ */
+#define V4VOP_viptables_list    8
+
+/*
+ * V4VOP_info
+ *
+ * Returns v4v info for the current domain (domain that issued the hyper=
call).
+ *      - V4V magic number
+ *      - event channel port (for current domain)
+ *
+ * do_v4v_op(V4VOP_info,
+ *           XEN_GUEST_HANDLE(v4v_info_t) info,
+ *           NULL, 0, 0)
+ */
+#define V4VOP_info              9
+
+#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 8def420..7a3fade 100644
--- a/xen/include/public/xen.h
+++ b/xen/include/public/xen.h
@@ -97,7 +97,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..296de52 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,9 @@ struct domain
     nodemask_t node_affinity;
     unsigned int last_alloc_node;
     spinlock_t node_affinity_lock;
+
+    /* v4v */
+    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..05d20b5
--- /dev/null
+++ b/xen/include/xen/v4v.h
@@ -0,0 +1,133 @@
+/***********************************************************************=
*******
+ * 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
+
+/*
+ * Handlers
+ */
+
+DEFINE_XEN_GUEST_HANDLE (v4v_iov_t);
+DEFINE_XEN_GUEST_HANDLE (v4v_addr_t);
+DEFINE_XEN_GUEST_HANDLE (v4v_send_addr_t);
+DEFINE_XEN_GUEST_HANDLE (v4v_ring_t);
+DEFINE_XEN_GUEST_HANDLE (v4v_ring_data_ent_t);
+DEFINE_XEN_GUEST_HANDLE (v4v_ring_data_t);
+DEFINE_XEN_GUEST_HANDLE (v4v_info_t);
+
+DEFINE_XEN_GUEST_HANDLE (v4v_viptables_rule_t);
+DEFINE_XEN_GUEST_HANDLE (v4v_viptables_list_t);
+
+/*
+ * Helper functions
+ */
+
+static inline uint16_t
+v4v_hash_fn (v4v_ring_id_t *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;
+};
+
+
+struct v4v_ring_info
+{
+    /* next node in the hash, protected by L2  */
+    struct hlist_node node;
+    /* this ring's id, protected by L2 */
+    v4v_ring_id_t 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;
+    /* event channel */
+    evtchn_port_t evtchn_port;
+    /* protected by L2 */
+    struct hlist_head ring_hash[V4V_HTABLE_SIZE];
+};
+
+typedef struct v4v_viptables_rule_node
+{
+    struct list_head list;
+    v4v_viptables_rule_t rule;
+} v4v_viptables_rule_node_t;
+
+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,
+                uint32_t arg3,
+                uint32_t arg4);
+
+#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 Sep 20 09:46:00 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Sep 2012 09: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 1TEdKN-0005Pr-15; Thu, 20 Sep 2012 09:45:47 +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 1TEdKL-0005PX-8w
	for xen-devel@lists.xen.org; Thu, 20 Sep 2012 09:45:45 +0000
Received: from [85.158.137.99:21663] by server-7.bemta-3.messagelabs.com id
	61/7E-32000-8C5EA505; Thu, 20 Sep 2012 09:45:44 +0000
X-Env-Sender: jean.guyader@citrix.com
X-Msg-Ref: server-8.tower-217.messagelabs.com!1348134343!13075422!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTA0NTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7884 invoked from network); 20 Sep 2012 09:45:43 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Sep 2012 09:45:43 -0000
X-IronPort-AV: E=Sophos;i="4.80,453,1344211200"; d="scan'208";a="14650463"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Sep 2012 09:44: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.279.1; Thu, 20 Sep 2012 10:44: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 1TEdJQ-0007kc-NI;
	Thu, 20 Sep 2012 09:44:48 +0000
Received: by spongy (Postfix, from userid 2023)	id D7878341ABD; Thu, 20 Sep
	2012 10:47:07 +0100 (BST)
From: Jean Guyader <jean.guyader@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Thu, 20 Sep 2012 10:47:03 +0100
Message-ID: <1348134426-25320-2-git-send-email-jean.guyader@citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <1348134426-25320-1-git-send-email-jean.guyader@citrix.com>
References: <1348134426-25320-1-git-send-email-jean.guyader@citrix.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="------------true"
Cc: tim@xen.org, JBeulich@suse.com
Subject: [Xen-devel] [PATCH 1/4] xen: 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: Jan Beulich <JBeulich@suse.com>
---
 xen/include/asm-x86/guest_access.h |    3 +++
 1 file changed, 3 insertions(+)


--------------true
Content-Type: text/x-patch;
	name="0001-xen-Introduce-guest_handle_for_field.patch"
Content-Disposition: attachment;
	filename="0001-xen-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 Sep 20 09:46:00 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Sep 2012 09: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 1TEdKN-0005Pr-15; Thu, 20 Sep 2012 09:45:47 +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 1TEdKL-0005PX-8w
	for xen-devel@lists.xen.org; Thu, 20 Sep 2012 09:45:45 +0000
Received: from [85.158.137.99:21663] by server-7.bemta-3.messagelabs.com id
	61/7E-32000-8C5EA505; Thu, 20 Sep 2012 09:45:44 +0000
X-Env-Sender: jean.guyader@citrix.com
X-Msg-Ref: server-8.tower-217.messagelabs.com!1348134343!13075422!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTA0NTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7884 invoked from network); 20 Sep 2012 09:45:43 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Sep 2012 09:45:43 -0000
X-IronPort-AV: E=Sophos;i="4.80,453,1344211200"; d="scan'208";a="14650463"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Sep 2012 09:44: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.279.1; Thu, 20 Sep 2012 10:44: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 1TEdJQ-0007kc-NI;
	Thu, 20 Sep 2012 09:44:48 +0000
Received: by spongy (Postfix, from userid 2023)	id D7878341ABD; Thu, 20 Sep
	2012 10:47:07 +0100 (BST)
From: Jean Guyader <jean.guyader@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Thu, 20 Sep 2012 10:47:03 +0100
Message-ID: <1348134426-25320-2-git-send-email-jean.guyader@citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <1348134426-25320-1-git-send-email-jean.guyader@citrix.com>
References: <1348134426-25320-1-git-send-email-jean.guyader@citrix.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="------------true"
Cc: tim@xen.org, JBeulich@suse.com
Subject: [Xen-devel] [PATCH 1/4] xen: 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: Jan Beulich <JBeulich@suse.com>
---
 xen/include/asm-x86/guest_access.h |    3 +++
 1 file changed, 3 insertions(+)


--------------true
Content-Type: text/x-patch;
	name="0001-xen-Introduce-guest_handle_for_field.patch"
Content-Disposition: attachment;
	filename="0001-xen-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 Sep 20 09:46:00 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Sep 2012 09: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 1TEdKN-0005Py-Ct; Thu, 20 Sep 2012 09:45:47 +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 1TEdKL-0005PY-Iw
	for xen-devel@lists.xen.org; Thu, 20 Sep 2012 09:45:45 +0000
Received: from [85.158.137.99:56039] by server-11.bemta-3.messagelabs.com id
	AC/E6-30250-8C5EA505; Thu, 20 Sep 2012 09:45:44 +0000
X-Env-Sender: jean.guyader@citrix.com
X-Msg-Ref: server-8.tower-217.messagelabs.com!1348134343!13075422!2
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTA0NTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7906 invoked from network); 20 Sep 2012 09:45:44 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Sep 2012 09:45:44 -0000
X-IronPort-AV: E=Sophos;i="4.80,453,1344211200"; d="scan'208";a="14650464"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Sep 2012 09:44: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.279.1; Thu, 20 Sep 2012 10:44:48 +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 1TEdJQ-0007kZ-IQ;
	Thu, 20 Sep 2012 09:44:48 +0000
Received: by spongy (Postfix, from userid 2023)	id C042034040D; Thu, 20 Sep
	2012 10:47:07 +0100 (BST)
From: Jean Guyader <jean.guyader@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Thu, 20 Sep 2012 10:47:02 +0100
Message-ID: <1348134426-25320-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: tim@xen.org, Jean Guyader <jean.guyader@citrix.com>, JBeulich@suse.com
Subject: [Xen-devel] [PATCH 0/4] Add V4V to Xen v5
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
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

v5 changes:
        - Fix prototypes in v4v.h for do_v4v_op
        - Add padding to make sure all the structures
          are 64 bits aligned
        - Replace [0] with []

v4 changes:
        - Stop using ssize_t, use long instead
        - Return -MSGSIZE for message bigger than 2GB
        - Fixup size handling
        - Rename protocol with message_type to avoid the
          confusion with the IP protocol flag
        - Replaced V4V_DOMID_ANY value with DOMID_INVALID
        - Replaced v4v_pfn_t with xen_pfn_t
        - Add padding to struct v4v_info
        - Fixup hypercall documentation
        - Move V4V_ROUNDUP to v4v.c
        - Remove v4v_utils.h (we could potentially add it later).

v3 changes:
        - Switch to event channel
                - Allocated a unbound event channel
                  per domain.
                - Add a new v4v call to share the
                  event channel port.
        - Public headers with actual type definition
        - Align all the v4v type to 64 bits
        - Modify v4v MAGIC numbers because we won't
          but backward compatible anymore
        - Merge insert and insertv
        - Merge send and sendv
        - Turn all the lock prerequisite from comment
          to ASSERT()
        - Make use or write_atomic instead of volatile pointers
        - Merge v4v_memcpy_to_guest_ring and
          v4v_memcpy_to_guest_ring_from_guest
                - Introduce copy_from_guest_maybe that can take
                  a void * and a handle as src address.
        - Replace 6 arguments hypercalls with 5 arguments hypercalls.

v2 changes:
        - Cleanup plugin header
        - Include basic access control
        - Use guest_handle_for_field

Jan Beulich (1):
  xen: Introduce guest_handle_for_field

Jean Guyader (3):
  xen: virq, remove VIRQ_XC_RESERVED
  xen: events, exposes evtchn_alloc_unbound_domain
  xen: Add V4V implementation

 xen/arch/x86/hvm/hvm.c             |    6 +-
 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                |   13 +-
 xen/common/event_channel.c         |   39 +-
 xen/common/v4v.c                   | 1905 ++++++++++++++++++++++++++++++=
++++++
 xen/include/asm-x86/guest_access.h |    3 +
 xen/include/public/v4v.h           |  308 ++++++
 xen/include/public/xen.h           |    3 +-
 xen/include/xen/event.h            |    3 +
 xen/include/xen/sched.h            |    4 +
 xen/include/xen/v4v.h              |  133 +++
 13 files changed, 2405 insertions(+), 17 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 Sep 20 09:46:00 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Sep 2012 09: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 1TEdKN-0005Py-Ct; Thu, 20 Sep 2012 09:45:47 +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 1TEdKL-0005PY-Iw
	for xen-devel@lists.xen.org; Thu, 20 Sep 2012 09:45:45 +0000
Received: from [85.158.137.99:56039] by server-11.bemta-3.messagelabs.com id
	AC/E6-30250-8C5EA505; Thu, 20 Sep 2012 09:45:44 +0000
X-Env-Sender: jean.guyader@citrix.com
X-Msg-Ref: server-8.tower-217.messagelabs.com!1348134343!13075422!2
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTA0NTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7906 invoked from network); 20 Sep 2012 09:45:44 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Sep 2012 09:45:44 -0000
X-IronPort-AV: E=Sophos;i="4.80,453,1344211200"; d="scan'208";a="14650464"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Sep 2012 09:44: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.279.1; Thu, 20 Sep 2012 10:44:48 +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 1TEdJQ-0007kZ-IQ;
	Thu, 20 Sep 2012 09:44:48 +0000
Received: by spongy (Postfix, from userid 2023)	id C042034040D; Thu, 20 Sep
	2012 10:47:07 +0100 (BST)
From: Jean Guyader <jean.guyader@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Thu, 20 Sep 2012 10:47:02 +0100
Message-ID: <1348134426-25320-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: tim@xen.org, Jean Guyader <jean.guyader@citrix.com>, JBeulich@suse.com
Subject: [Xen-devel] [PATCH 0/4] Add V4V to Xen v5
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
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

v5 changes:
        - Fix prototypes in v4v.h for do_v4v_op
        - Add padding to make sure all the structures
          are 64 bits aligned
        - Replace [0] with []

v4 changes:
        - Stop using ssize_t, use long instead
        - Return -MSGSIZE for message bigger than 2GB
        - Fixup size handling
        - Rename protocol with message_type to avoid the
          confusion with the IP protocol flag
        - Replaced V4V_DOMID_ANY value with DOMID_INVALID
        - Replaced v4v_pfn_t with xen_pfn_t
        - Add padding to struct v4v_info
        - Fixup hypercall documentation
        - Move V4V_ROUNDUP to v4v.c
        - Remove v4v_utils.h (we could potentially add it later).

v3 changes:
        - Switch to event channel
                - Allocated a unbound event channel
                  per domain.
                - Add a new v4v call to share the
                  event channel port.
        - Public headers with actual type definition
        - Align all the v4v type to 64 bits
        - Modify v4v MAGIC numbers because we won't
          but backward compatible anymore
        - Merge insert and insertv
        - Merge send and sendv
        - Turn all the lock prerequisite from comment
          to ASSERT()
        - Make use or write_atomic instead of volatile pointers
        - Merge v4v_memcpy_to_guest_ring and
          v4v_memcpy_to_guest_ring_from_guest
                - Introduce copy_from_guest_maybe that can take
                  a void * and a handle as src address.
        - Replace 6 arguments hypercalls with 5 arguments hypercalls.

v2 changes:
        - Cleanup plugin header
        - Include basic access control
        - Use guest_handle_for_field

Jan Beulich (1):
  xen: Introduce guest_handle_for_field

Jean Guyader (3):
  xen: virq, remove VIRQ_XC_RESERVED
  xen: events, exposes evtchn_alloc_unbound_domain
  xen: Add V4V implementation

 xen/arch/x86/hvm/hvm.c             |    6 +-
 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                |   13 +-
 xen/common/event_channel.c         |   39 +-
 xen/common/v4v.c                   | 1905 ++++++++++++++++++++++++++++++=
++++++
 xen/include/asm-x86/guest_access.h |    3 +
 xen/include/public/v4v.h           |  308 ++++++
 xen/include/public/xen.h           |    3 +-
 xen/include/xen/event.h            |    3 +
 xen/include/xen/sched.h            |    4 +
 xen/include/xen/v4v.h              |  133 +++
 13 files changed, 2405 insertions(+), 17 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 Sep 20 09:46:00 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Sep 2012 09: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 1TEdKO-0005QJ-6g; Thu, 20 Sep 2012 09:45:48 +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 1TEdKM-0005Pe-78
	for xen-devel@lists.xen.org; Thu, 20 Sep 2012 09:45:46 +0000
Received: from [85.158.138.51:56208] by server-5.bemta-3.messagelabs.com id
	14/78-13133-9C5EA505; Thu, 20 Sep 2012 09:45:45 +0000
X-Env-Sender: jean.guyader@citrix.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1348134344!12622226!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTA0NTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16205 invoked from network); 20 Sep 2012 09:45:44 -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;
	20 Sep 2012 09:45:44 -0000
X-IronPort-AV: E=Sophos;i="4.80,453,1344211200"; d="scan'208";a="14650466"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Sep 2012 09:44: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.279.1; Thu, 20 Sep 2012 10:44: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 1TEdJQ-0007ki-UT;
	Thu, 20 Sep 2012 09:44:49 +0000
Received: by spongy (Postfix, from userid 2023)	id 2BF6D341ABD; Thu, 20 Sep
	2012 10:47:08 +0100 (BST)
From: Jean Guyader <jean.guyader@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Thu, 20 Sep 2012 10:47:05 +0100
Message-ID: <1348134426-25320-4-git-send-email-jean.guyader@citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <1348134426-25320-1-git-send-email-jean.guyader@citrix.com>
References: <1348134426-25320-1-git-send-email-jean.guyader@citrix.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="------------true"
Cc: tim@xen.org, Jean Guyader <jean.guyader@citrix.com>, JBeulich@suse.com
Subject: [Xen-devel] [PATCH 3/4] xen: events,
	exposes evtchn_alloc_unbound_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>
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


Exposes evtchn_alloc_unbound_domain to the rest of
Xen so we can create allocated unbound evtchn within Xen.

Signed-off-by: Jean Guyader <jean.guyader@citrix.com>
---
 xen/common/event_channel.c |   39 +++++++++++++++++++++++++++-----------=
-
 xen/include/xen/event.h    |    3 +++
 2 files changed, 30 insertions(+), 12 deletions(-)


--------------true
Content-Type: text/x-patch;
	name="0003-xen-events-exposes-evtchn_alloc_unbound_domain.patch"
Content-Disposition: attachment;
	filename="0003-xen-events-exposes-evtchn_alloc_unbound_domain.patch"
Content-Transfer-Encoding: quoted-printable

diff --git a/xen/common/event_channel.c b/xen/common/event_channel.c
index 53777f8..6a0e342 100644
--- a/xen/common/event_channel.c
+++ b/xen/common/event_channel.c
@@ -159,36 +159,51 @@ static int get_free_port(struct domain *d)
=20
 static long evtchn_alloc_unbound(evtchn_alloc_unbound_t *alloc)
 {
-    struct evtchn *chn;
     struct domain *d;
-    int            port;
-    domid_t        dom =3D alloc->dom;
     long           rc;
=20
-    rc =3D rcu_lock_target_domain_by_id(dom, &d);
+    rc =3D rcu_lock_target_domain_by_id(alloc->dom, &d);
     if ( rc )
         return rc;
=20
+    rc =3D evtchn_alloc_unbound_domain(d, &alloc->port, alloc->remote_do=
m);
+    if ( rc )
+        ERROR_EXIT_DOM((int)rc, d);
+
+ out:
+    rcu_unlock_domain(d);
+
+    return rc;
+}
+
+int evtchn_alloc_unbound_domain(struct domain *d, evtchn_port_t *port,
+                                domid_t remote_domid)
+{
+    struct evtchn *chn;
+    int           rc;
+    int           free_port;
+
     spin_lock(&d->event_lock);
=20
-    if ( (port =3D get_free_port(d)) < 0 )
-        ERROR_EXIT_DOM(port, d);
-    chn =3D evtchn_from_port(d, port);
+    rc =3D free_port =3D get_free_port(d);
+    if ( free_port < 0 )
+        goto out;
=20
-    rc =3D xsm_evtchn_unbound(d, chn, alloc->remote_dom);
+    chn =3D evtchn_from_port(d, free_port);
+    rc =3D xsm_evtchn_unbound(d, chn, remote_domid);
     if ( rc )
         goto out;
=20
     chn->state =3D ECS_UNBOUND;
-    if ( (chn->u.unbound.remote_domid =3D alloc->remote_dom) =3D=3D DOMI=
D_SELF )
+    if ( (chn->u.unbound.remote_domid =3D remote_domid) =3D=3D DOMID_SEL=
F )
         chn->u.unbound.remote_domid =3D current->domain->domain_id;
=20
-    alloc->port =3D port;
+    *port =3D free_port;
+    /* Everything is fine, returns 0 */
+    rc =3D 0;
=20
  out:
     spin_unlock(&d->event_lock);
-    rcu_unlock_domain(d);
-
     return rc;
 }
=20
diff --git a/xen/include/xen/event.h b/xen/include/xen/event.h
index 71c3e92..1a0c832 100644
--- a/xen/include/xen/event.h
+++ b/xen/include/xen/event.h
@@ -69,6 +69,9 @@ int guest_enabled_event(struct vcpu *v, uint32_t virq);
 /* Notify remote end of a Xen-attached event channel.*/
 void notify_via_xen_event_channel(struct domain *ld, int lport);
=20
+int evtchn_alloc_unbound_domain(struct domain *d, evtchn_port_t *port,
+                                domid_t remote_domid);
+
 /* Internal event channel object accessors */
 #define bucket_from_port(d,p) \
     ((d)->evtchn[(p)/EVTCHNS_PER_BUCKET])

--------------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 Sep 20 09:46:00 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Sep 2012 09: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 1TEdKO-0005QJ-6g; Thu, 20 Sep 2012 09:45:48 +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 1TEdKM-0005Pe-78
	for xen-devel@lists.xen.org; Thu, 20 Sep 2012 09:45:46 +0000
Received: from [85.158.138.51:56208] by server-5.bemta-3.messagelabs.com id
	14/78-13133-9C5EA505; Thu, 20 Sep 2012 09:45:45 +0000
X-Env-Sender: jean.guyader@citrix.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1348134344!12622226!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTA0NTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16205 invoked from network); 20 Sep 2012 09:45:44 -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;
	20 Sep 2012 09:45:44 -0000
X-IronPort-AV: E=Sophos;i="4.80,453,1344211200"; d="scan'208";a="14650466"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Sep 2012 09:44: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.279.1; Thu, 20 Sep 2012 10:44: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 1TEdJQ-0007ki-UT;
	Thu, 20 Sep 2012 09:44:49 +0000
Received: by spongy (Postfix, from userid 2023)	id 2BF6D341ABD; Thu, 20 Sep
	2012 10:47:08 +0100 (BST)
From: Jean Guyader <jean.guyader@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Thu, 20 Sep 2012 10:47:05 +0100
Message-ID: <1348134426-25320-4-git-send-email-jean.guyader@citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <1348134426-25320-1-git-send-email-jean.guyader@citrix.com>
References: <1348134426-25320-1-git-send-email-jean.guyader@citrix.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="------------true"
Cc: tim@xen.org, Jean Guyader <jean.guyader@citrix.com>, JBeulich@suse.com
Subject: [Xen-devel] [PATCH 3/4] xen: events,
	exposes evtchn_alloc_unbound_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>
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


Exposes evtchn_alloc_unbound_domain to the rest of
Xen so we can create allocated unbound evtchn within Xen.

Signed-off-by: Jean Guyader <jean.guyader@citrix.com>
---
 xen/common/event_channel.c |   39 +++++++++++++++++++++++++++-----------=
-
 xen/include/xen/event.h    |    3 +++
 2 files changed, 30 insertions(+), 12 deletions(-)


--------------true
Content-Type: text/x-patch;
	name="0003-xen-events-exposes-evtchn_alloc_unbound_domain.patch"
Content-Disposition: attachment;
	filename="0003-xen-events-exposes-evtchn_alloc_unbound_domain.patch"
Content-Transfer-Encoding: quoted-printable

diff --git a/xen/common/event_channel.c b/xen/common/event_channel.c
index 53777f8..6a0e342 100644
--- a/xen/common/event_channel.c
+++ b/xen/common/event_channel.c
@@ -159,36 +159,51 @@ static int get_free_port(struct domain *d)
=20
 static long evtchn_alloc_unbound(evtchn_alloc_unbound_t *alloc)
 {
-    struct evtchn *chn;
     struct domain *d;
-    int            port;
-    domid_t        dom =3D alloc->dom;
     long           rc;
=20
-    rc =3D rcu_lock_target_domain_by_id(dom, &d);
+    rc =3D rcu_lock_target_domain_by_id(alloc->dom, &d);
     if ( rc )
         return rc;
=20
+    rc =3D evtchn_alloc_unbound_domain(d, &alloc->port, alloc->remote_do=
m);
+    if ( rc )
+        ERROR_EXIT_DOM((int)rc, d);
+
+ out:
+    rcu_unlock_domain(d);
+
+    return rc;
+}
+
+int evtchn_alloc_unbound_domain(struct domain *d, evtchn_port_t *port,
+                                domid_t remote_domid)
+{
+    struct evtchn *chn;
+    int           rc;
+    int           free_port;
+
     spin_lock(&d->event_lock);
=20
-    if ( (port =3D get_free_port(d)) < 0 )
-        ERROR_EXIT_DOM(port, d);
-    chn =3D evtchn_from_port(d, port);
+    rc =3D free_port =3D get_free_port(d);
+    if ( free_port < 0 )
+        goto out;
=20
-    rc =3D xsm_evtchn_unbound(d, chn, alloc->remote_dom);
+    chn =3D evtchn_from_port(d, free_port);
+    rc =3D xsm_evtchn_unbound(d, chn, remote_domid);
     if ( rc )
         goto out;
=20
     chn->state =3D ECS_UNBOUND;
-    if ( (chn->u.unbound.remote_domid =3D alloc->remote_dom) =3D=3D DOMI=
D_SELF )
+    if ( (chn->u.unbound.remote_domid =3D remote_domid) =3D=3D DOMID_SEL=
F )
         chn->u.unbound.remote_domid =3D current->domain->domain_id;
=20
-    alloc->port =3D port;
+    *port =3D free_port;
+    /* Everything is fine, returns 0 */
+    rc =3D 0;
=20
  out:
     spin_unlock(&d->event_lock);
-    rcu_unlock_domain(d);
-
     return rc;
 }
=20
diff --git a/xen/include/xen/event.h b/xen/include/xen/event.h
index 71c3e92..1a0c832 100644
--- a/xen/include/xen/event.h
+++ b/xen/include/xen/event.h
@@ -69,6 +69,9 @@ int guest_enabled_event(struct vcpu *v, uint32_t virq);
 /* Notify remote end of a Xen-attached event channel.*/
 void notify_via_xen_event_channel(struct domain *ld, int lport);
=20
+int evtchn_alloc_unbound_domain(struct domain *d, evtchn_port_t *port,
+                                domid_t remote_domid);
+
 /* Internal event channel object accessors */
 #define bucket_from_port(d,p) \
     ((d)->evtchn[(p)/EVTCHNS_PER_BUCKET])

--------------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 Sep 20 09:46:00 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Sep 2012 09: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 1TEdKN-0005QA-Qk; Thu, 20 Sep 2012 09:45:47 +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 1TEdKL-0005PZ-Tu
	for xen-devel@lists.xen.org; Thu, 20 Sep 2012 09:45:46 +0000
Received: from [85.158.137.99:21708] by server-9.bemta-3.messagelabs.com id
	96/CD-15390-9C5EA505; Thu, 20 Sep 2012 09:45:45 +0000
X-Env-Sender: jean.guyader@citrix.com
X-Msg-Ref: server-8.tower-217.messagelabs.com!1348134343!13075422!3
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTA0NTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7941 invoked from network); 20 Sep 2012 09:45:44 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Sep 2012 09:45:44 -0000
X-IronPort-AV: E=Sophos;i="4.80,453,1344211200"; d="scan'208";a="14650465"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Sep 2012 09:44: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.279.1; Thu, 20 Sep 2012 10:44: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 1TEdJQ-0007kf-Rq;
	Thu, 20 Sep 2012 09:44:48 +0000
Received: by spongy (Postfix, from userid 2023)	id 0985B34040D; Thu, 20 Sep
	2012 10:47:07 +0100 (BST)
From: Jean Guyader <jean.guyader@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Thu, 20 Sep 2012 10:47:04 +0100
Message-ID: <1348134426-25320-3-git-send-email-jean.guyader@citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <1348134426-25320-1-git-send-email-jean.guyader@citrix.com>
References: <1348134426-25320-1-git-send-email-jean.guyader@citrix.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="------------true"
Cc: tim@xen.org, Jean Guyader <jean.guyader@citrix.com>, JBeulich@suse.com
Subject: [Xen-devel] [PATCH 2/4] xen: virq, remove VIRQ_XC_RESERVED
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<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


VIRQ_XC_RESERVED was reserved for V4V but we have switched
to event channels so this place holder is no longer required.

Signed-off-by: Jean Guyader <jean.guyader@citrix.com>
---
 xen/include/public/xen.h |    1 -
 1 file changed, 1 deletion(-)


--------------true
Content-Type: text/x-patch;
	name="0002-xen-virq-remove-VIRQ_XC_RESERVED.patch"
Content-Disposition: attachment;
	filename="0002-xen-virq-remove-VIRQ_XC_RESERVED.patch"
Content-Transfer-Encoding: quoted-printable

diff --git a/xen/include/public/xen.h b/xen/include/public/xen.h
index 361398b..8def420 100644
--- a/xen/include/public/xen.h
+++ b/xen/include/public/xen.h
@@ -155,7 +155,6 @@ 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_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 Sep 20 09:46:00 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Sep 2012 09: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 1TEdKN-0005QA-Qk; Thu, 20 Sep 2012 09:45:47 +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 1TEdKL-0005PZ-Tu
	for xen-devel@lists.xen.org; Thu, 20 Sep 2012 09:45:46 +0000
Received: from [85.158.137.99:21708] by server-9.bemta-3.messagelabs.com id
	96/CD-15390-9C5EA505; Thu, 20 Sep 2012 09:45:45 +0000
X-Env-Sender: jean.guyader@citrix.com
X-Msg-Ref: server-8.tower-217.messagelabs.com!1348134343!13075422!3
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTA0NTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7941 invoked from network); 20 Sep 2012 09:45:44 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Sep 2012 09:45:44 -0000
X-IronPort-AV: E=Sophos;i="4.80,453,1344211200"; d="scan'208";a="14650465"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Sep 2012 09:44: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.279.1; Thu, 20 Sep 2012 10:44: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 1TEdJQ-0007kf-Rq;
	Thu, 20 Sep 2012 09:44:48 +0000
Received: by spongy (Postfix, from userid 2023)	id 0985B34040D; Thu, 20 Sep
	2012 10:47:07 +0100 (BST)
From: Jean Guyader <jean.guyader@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Thu, 20 Sep 2012 10:47:04 +0100
Message-ID: <1348134426-25320-3-git-send-email-jean.guyader@citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <1348134426-25320-1-git-send-email-jean.guyader@citrix.com>
References: <1348134426-25320-1-git-send-email-jean.guyader@citrix.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="------------true"
Cc: tim@xen.org, Jean Guyader <jean.guyader@citrix.com>, JBeulich@suse.com
Subject: [Xen-devel] [PATCH 2/4] xen: virq, remove VIRQ_XC_RESERVED
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<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


VIRQ_XC_RESERVED was reserved for V4V but we have switched
to event channels so this place holder is no longer required.

Signed-off-by: Jean Guyader <jean.guyader@citrix.com>
---
 xen/include/public/xen.h |    1 -
 1 file changed, 1 deletion(-)


--------------true
Content-Type: text/x-patch;
	name="0002-xen-virq-remove-VIRQ_XC_RESERVED.patch"
Content-Disposition: attachment;
	filename="0002-xen-virq-remove-VIRQ_XC_RESERVED.patch"
Content-Transfer-Encoding: quoted-printable

diff --git a/xen/include/public/xen.h b/xen/include/public/xen.h
index 361398b..8def420 100644
--- a/xen/include/public/xen.h
+++ b/xen/include/public/xen.h
@@ -155,7 +155,6 @@ 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_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 Sep 20 09:54:10 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Sep 2012 09:54:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TEdSH-00068S-Uv; Thu, 20 Sep 2012 09:53:57 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jean.guyader@gmail.com>) id 1TEdSG-00068N-IV
	for xen-devel@lists.xen.org; Thu, 20 Sep 2012 09:53:56 +0000
Received: from [85.158.138.51:33883] by server-1.bemta-3.messagelabs.com id
	C5/91-05884-3B7EA505; Thu, 20 Sep 2012 09:53:55 +0000
X-Env-Sender: jean.guyader@gmail.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1348134833!29612587!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-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17289 invoked from network); 20 Sep 2012 09:53:54 -0000
Received: from mail-vb0-f45.google.com (HELO mail-vb0-f45.google.com)
	(209.85.212.45)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Sep 2012 09:53:54 -0000
Received: by vbip1 with SMTP id p1so2792577vbi.32
	for <xen-devel@lists.xen.org>; Thu, 20 Sep 2012 02:53:52 -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=DqRTgKagX9H5dEIGd/hZ5odKk1nMYJxW32lyIV+IVEo=;
	b=MtUo4YO20Rw7qD1PK99HRlRuvPdXLR95ra7U9BKdTF3F9RUo459B1nGXd/SUILSjgM
	CnnViJkalS0dzQ1O9q75pI1oQW4s4kWnb56dGUUVTFBHyhoOqWvDK5uCs4FSQ40sj0OW
	npBKlmi2bw07OCz6jaOzw6yGtpqTfm1JRKIU+LhPuozZ25DcaZAiIZS03Kwls+J0nWVT
	dcxow3L/obja/E0qnVqTbNIrMU8uSjLSCNb0ywrx0nOyV7r/87aWNnEJJHsHWsD+82kK
	92AkuyOh1A9VAmz9iA79jj7BSlG7gwvw3pbLEdP0uSUd6ch6MKjuPbf9xqYQJd5yS0he
	BxuQ==
Received: by 10.52.27.239 with SMTP id w15mr599585vdg.96.1348134832800; Thu,
	20 Sep 2012 02:53:52 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.58.91.72 with HTTP; Thu, 20 Sep 2012 02:53:32 -0700 (PDT)
In-Reply-To: <CAFLBxZYtmJ_bKFb90r45=C4Pq1-oe5Fy=eygSsQf4BcGj3EqGA@mail.gmail.com>
References: <CAFLBxZYtmJ_bKFb90r45=C4Pq1-oe5Fy=eygSsQf4BcGj3EqGA@mail.gmail.com>
From: Jean Guyader <jean.guyader@gmail.com>
Date: Thu, 20 Sep 2012 10:53:32 +0100
Message-ID: <CAEBdQ90Htx8xqtbmBdV+06nrCTtAmVV-tXqRpWomez-WP4TRtA@mail.gmail.com>
To: George Dunlap <George.Dunlap@eu.citrix.com>
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Xen 4.3 development 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 19 September 2012 17:58, George Dunlap <George.Dunlap@eu.citrix.com> wrote:
> = Timeline =
>
> We are planning on a 9-month release cycle.  Based on that, below are
> our estimated dates:
> * Feature Freeze: 1 March, 2013
> * First RC: 15 April 2013
> * Release: 1 June 2013
>
> The RCs and release will of course depend on stability and bugs, and
> will therefore be fairly unpredictable.  The feature freeze may be
> slipped for especially important features which are near completion.
>
> = Feature tracking =
>
> Below is a list of features we're tracking for this release.  Please
> respond to this mail with any updates to the status.  If the status
> is "?", as most of them are, please respond with the status!  Example
> statuses include "not started", "in progress", "initial implementation
> submitted for review", "patches submitted".
>
> There are a number of items whose owners are marked as "?".  If you
> are working on this, or know who is working on it, please respond and
> let me know.  Alternately, if you would *like* to work on it, please
> let me know as well.
>
> And if there is something you're working on you'd like tracked, please
> respond, and I will add it to the list.
>
>
> * PVH mode, domU (w/ Linux)
>   owner: mukesh@oracle
>   status: ?
>
> * PVH mode, dom0 (w/ Linux)
>   owner: mukesh@oracle
>   status: ?
>
> * Event channel scalability
>   owner: attilio@citrix
>   status: ?
>   Increase limit on event channels (currently 1024 for 32-bit guests,
>   4096 for 64-bit guests)
>
> * ARM server port
>   owner: ijc@citrix
>   status: Core hypervisor patches accepted; Linux paches pending
>
> * NUMA scheduler affinity
>   critical
>   owner: dario@citrix
>   status: ?
>
> * NUMA Memory migration
>   owner: dario@citrix
>   status: ?
>
> * blktap3
>   owner: thanos@citrix
>   status: ?
>
> * Default to QEMU upstream
>  - qemu-based stubdom (Linux or BSD libc)
>    owner: anthony@citrix
>    status: ?
>    qemu-upstream needs a more fully-featured libc than exists in
>    minios.  Either work on a minimalist linux-based stubdom with
>    glibc, or port one of the BSD libcs to minios.
>
>  - pci pass-thru
>    owner: anthony@citrix
>    status: ?
>
> * Persistent grants
>   owner: @citrix
>   status: ?
>
> * Multi-page blk rings
>  - blkback in kernel (konrad@oracle, ?@intel)
>  - qemu blkback
>   status: ?
>
> * Multi-page net protocol
>   owner: ?
>   status: ?
>   expand the network ring protocol to allow multiple pages for
>   increased throughput
>
> * Scalability: 16TiB of RAM
>   owner: jan@suse
>   status: ?
>
> * libvirt integration
>   owner: ?
>   status: ?
>   To begin with, we need someone to go and make some lists:
>   - Features available in libvirt/KVM not available in libvirt/Xen
>   - Features available in xl/Xen but not available in libvirt/Xen
>
> * xl vm-{export,import}
>   owner: ?
>   status: ?
>   Allow xl to import and export VMs to other formats; particularly
>   ovf, perhaps the XenServer format, or more.
>
>
> * xl USB pass-through for PV guests
>   owner: ?
>   status: ?
>   - Port the xend PV pass-through functionality to xl.
>   - Make sure qemu-based USB with qemu-upstream works
>   - Upstream the Linux frontend/backend drivers
>
> * openvswitch toostack integration
>   owner: roger@citrix
>   status: Sample script posted by Bastian ("[RFC] openvswitch support script")
>
> * Rationalized backend scripts (incl. driver domains)
>   owner: roger@citrix
>   status: ?
>
> * Linux console improvements
>   owner: jan@suse
>   -EHCI debug port (done, to be submitted)
>   -xHCI debug port
>   -Firewire
>
> * CPUID-based idle (don't rely on ACPI info f/ dom0)
>   owner: jan@suse
>   status: done, to be submitted
>
> * Remove hardcoded mobprobe's in xencommons
>   owner: ?
>   status: ?
>
> * Make storage migration possible
>   owner: ?
>   status: ?
>   There needs to be a way, either via command-line or via some hooks,
>   that someone can build a "storage migration" feature on top of libxl
>   or xl.
>
> * Full-VM snapshotting
>   owner: ?
>   status: ?
>   Have a way of coordinating the taking and restoring of VM memory and
>   disk snapshots.  This would involve some investigation into the best
>   way to accomplish this.
>
> * VM Cloning
>   owner: ?
>   status: May need review
>   Again, a way of coordinating the memory and disk aspects.  Research
>   into the best way to do this would probably go along with the
>   snapshotting feature.
>
> * Memory: Replace PoD with paging mechanism
>   owner: george@citrix
>   status: May need review
>
> * PV audio (audio for stubdom qemu)
>   owner: stefano.panella@citrix
>   status: ?
>
> * Managed domains?
>

Hi George,

Maybe we could had V4V in the list.

* V4V: Inter-domain communication
  owner (Xen): jean.guyader@citrix.com
  status (Xen): patches submitted
  owner (Linux driver):  stefano.panella@citrix
  status (Linux driver): in progress

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 Sep 20 09:54:10 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Sep 2012 09:54:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TEdSH-00068S-Uv; Thu, 20 Sep 2012 09:53:57 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jean.guyader@gmail.com>) id 1TEdSG-00068N-IV
	for xen-devel@lists.xen.org; Thu, 20 Sep 2012 09:53:56 +0000
Received: from [85.158.138.51:33883] by server-1.bemta-3.messagelabs.com id
	C5/91-05884-3B7EA505; Thu, 20 Sep 2012 09:53:55 +0000
X-Env-Sender: jean.guyader@gmail.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1348134833!29612587!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-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17289 invoked from network); 20 Sep 2012 09:53:54 -0000
Received: from mail-vb0-f45.google.com (HELO mail-vb0-f45.google.com)
	(209.85.212.45)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Sep 2012 09:53:54 -0000
Received: by vbip1 with SMTP id p1so2792577vbi.32
	for <xen-devel@lists.xen.org>; Thu, 20 Sep 2012 02:53:52 -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=DqRTgKagX9H5dEIGd/hZ5odKk1nMYJxW32lyIV+IVEo=;
	b=MtUo4YO20Rw7qD1PK99HRlRuvPdXLR95ra7U9BKdTF3F9RUo459B1nGXd/SUILSjgM
	CnnViJkalS0dzQ1O9q75pI1oQW4s4kWnb56dGUUVTFBHyhoOqWvDK5uCs4FSQ40sj0OW
	npBKlmi2bw07OCz6jaOzw6yGtpqTfm1JRKIU+LhPuozZ25DcaZAiIZS03Kwls+J0nWVT
	dcxow3L/obja/E0qnVqTbNIrMU8uSjLSCNb0ywrx0nOyV7r/87aWNnEJJHsHWsD+82kK
	92AkuyOh1A9VAmz9iA79jj7BSlG7gwvw3pbLEdP0uSUd6ch6MKjuPbf9xqYQJd5yS0he
	BxuQ==
Received: by 10.52.27.239 with SMTP id w15mr599585vdg.96.1348134832800; Thu,
	20 Sep 2012 02:53:52 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.58.91.72 with HTTP; Thu, 20 Sep 2012 02:53:32 -0700 (PDT)
In-Reply-To: <CAFLBxZYtmJ_bKFb90r45=C4Pq1-oe5Fy=eygSsQf4BcGj3EqGA@mail.gmail.com>
References: <CAFLBxZYtmJ_bKFb90r45=C4Pq1-oe5Fy=eygSsQf4BcGj3EqGA@mail.gmail.com>
From: Jean Guyader <jean.guyader@gmail.com>
Date: Thu, 20 Sep 2012 10:53:32 +0100
Message-ID: <CAEBdQ90Htx8xqtbmBdV+06nrCTtAmVV-tXqRpWomez-WP4TRtA@mail.gmail.com>
To: George Dunlap <George.Dunlap@eu.citrix.com>
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Xen 4.3 development 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 19 September 2012 17:58, George Dunlap <George.Dunlap@eu.citrix.com> wrote:
> = Timeline =
>
> We are planning on a 9-month release cycle.  Based on that, below are
> our estimated dates:
> * Feature Freeze: 1 March, 2013
> * First RC: 15 April 2013
> * Release: 1 June 2013
>
> The RCs and release will of course depend on stability and bugs, and
> will therefore be fairly unpredictable.  The feature freeze may be
> slipped for especially important features which are near completion.
>
> = Feature tracking =
>
> Below is a list of features we're tracking for this release.  Please
> respond to this mail with any updates to the status.  If the status
> is "?", as most of them are, please respond with the status!  Example
> statuses include "not started", "in progress", "initial implementation
> submitted for review", "patches submitted".
>
> There are a number of items whose owners are marked as "?".  If you
> are working on this, or know who is working on it, please respond and
> let me know.  Alternately, if you would *like* to work on it, please
> let me know as well.
>
> And if there is something you're working on you'd like tracked, please
> respond, and I will add it to the list.
>
>
> * PVH mode, domU (w/ Linux)
>   owner: mukesh@oracle
>   status: ?
>
> * PVH mode, dom0 (w/ Linux)
>   owner: mukesh@oracle
>   status: ?
>
> * Event channel scalability
>   owner: attilio@citrix
>   status: ?
>   Increase limit on event channels (currently 1024 for 32-bit guests,
>   4096 for 64-bit guests)
>
> * ARM server port
>   owner: ijc@citrix
>   status: Core hypervisor patches accepted; Linux paches pending
>
> * NUMA scheduler affinity
>   critical
>   owner: dario@citrix
>   status: ?
>
> * NUMA Memory migration
>   owner: dario@citrix
>   status: ?
>
> * blktap3
>   owner: thanos@citrix
>   status: ?
>
> * Default to QEMU upstream
>  - qemu-based stubdom (Linux or BSD libc)
>    owner: anthony@citrix
>    status: ?
>    qemu-upstream needs a more fully-featured libc than exists in
>    minios.  Either work on a minimalist linux-based stubdom with
>    glibc, or port one of the BSD libcs to minios.
>
>  - pci pass-thru
>    owner: anthony@citrix
>    status: ?
>
> * Persistent grants
>   owner: @citrix
>   status: ?
>
> * Multi-page blk rings
>  - blkback in kernel (konrad@oracle, ?@intel)
>  - qemu blkback
>   status: ?
>
> * Multi-page net protocol
>   owner: ?
>   status: ?
>   expand the network ring protocol to allow multiple pages for
>   increased throughput
>
> * Scalability: 16TiB of RAM
>   owner: jan@suse
>   status: ?
>
> * libvirt integration
>   owner: ?
>   status: ?
>   To begin with, we need someone to go and make some lists:
>   - Features available in libvirt/KVM not available in libvirt/Xen
>   - Features available in xl/Xen but not available in libvirt/Xen
>
> * xl vm-{export,import}
>   owner: ?
>   status: ?
>   Allow xl to import and export VMs to other formats; particularly
>   ovf, perhaps the XenServer format, or more.
>
>
> * xl USB pass-through for PV guests
>   owner: ?
>   status: ?
>   - Port the xend PV pass-through functionality to xl.
>   - Make sure qemu-based USB with qemu-upstream works
>   - Upstream the Linux frontend/backend drivers
>
> * openvswitch toostack integration
>   owner: roger@citrix
>   status: Sample script posted by Bastian ("[RFC] openvswitch support script")
>
> * Rationalized backend scripts (incl. driver domains)
>   owner: roger@citrix
>   status: ?
>
> * Linux console improvements
>   owner: jan@suse
>   -EHCI debug port (done, to be submitted)
>   -xHCI debug port
>   -Firewire
>
> * CPUID-based idle (don't rely on ACPI info f/ dom0)
>   owner: jan@suse
>   status: done, to be submitted
>
> * Remove hardcoded mobprobe's in xencommons
>   owner: ?
>   status: ?
>
> * Make storage migration possible
>   owner: ?
>   status: ?
>   There needs to be a way, either via command-line or via some hooks,
>   that someone can build a "storage migration" feature on top of libxl
>   or xl.
>
> * Full-VM snapshotting
>   owner: ?
>   status: ?
>   Have a way of coordinating the taking and restoring of VM memory and
>   disk snapshots.  This would involve some investigation into the best
>   way to accomplish this.
>
> * VM Cloning
>   owner: ?
>   status: May need review
>   Again, a way of coordinating the memory and disk aspects.  Research
>   into the best way to do this would probably go along with the
>   snapshotting feature.
>
> * Memory: Replace PoD with paging mechanism
>   owner: george@citrix
>   status: May need review
>
> * PV audio (audio for stubdom qemu)
>   owner: stefano.panella@citrix
>   status: ?
>
> * Managed domains?
>

Hi George,

Maybe we could had V4V in the list.

* V4V: Inter-domain communication
  owner (Xen): jean.guyader@citrix.com
  status (Xen): patches submitted
  owner (Linux driver):  stefano.panella@citrix
  status (Linux driver): in progress

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 Sep 20 10:06:28 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Sep 2012 10: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 1TEdeA-0006RX-7g; Thu, 20 Sep 2012 10:06:14 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <pawel.moll@arm.com>) id 1TEde8-0006RS-Pi
	for xen-devel@lists.xensource.com; Thu, 20 Sep 2012 10:06:13 +0000
Received: from [85.158.138.51:11473] by server-2.bemta-3.messagelabs.com id
	55/47-04862-39AEA505; Thu, 20 Sep 2012 10:06:11 +0000
X-Env-Sender: pawel.moll@arm.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1348135571!31286738!1
X-Originating-IP: [91.220.42.44]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogOTEuMjIwLjQyLjQ0ID0+IDI5ODkzOA==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32394 invoked from network); 20 Sep 2012 10:06:11 -0000
Received: from service87.mimecast.com (HELO service87.mimecast.com)
	(91.220.42.44) by server-11.tower-174.messagelabs.com with SMTP;
	20 Sep 2012 10:06:11 -0000
Received: from cam-owa1.Emea.Arm.com (fw-tnat.cambridge.arm.com
	[217.140.96.21]) by service87.mimecast.com;
	Thu, 20 Sep 2012 11:06:10 +0100
Received: from [10.1.205.42] ([10.1.255.212]) by cam-owa1.Emea.Arm.com with
	Microsoft SMTPSVC(6.0.3790.0); Thu, 20 Sep 2012 11:06:04 +0100
Message-ID: <1348135563.11116.94.camel@hornet>
From: Pawel Moll <pawel.moll@arm.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Thu, 20 Sep 2012 11:06:03 +0100
In-Reply-To: <1348076658-4511-1-git-send-email-stefano.stabellini@eu.citrix.com>
References: <1348076658-4511-1-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: Evolution 3.2.3-0ubuntu6
Mime-Version: 1.0
X-OriginalArrivalTime: 20 Sep 2012 10:06:04.0298 (UTC)
	FILETIME=[8B6F46A0:01CD9717]
X-MC-Unique: 112092011061006101
Cc: "linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
	"Ian.Campbell@citrix.com" <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH] arm: introduce a DTS for Xen unprivileged
 virtual 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

Morning,

On Wed, 2012-09-19 at 18:44 +0100, Stefano Stabellini wrote:
> +/dts-v1/;
> +
> +/include/ "skeleton.dtsi"

Any particular reason to include skeleton? And I think it would be
better to use #address-cells = <2> and #size-cells = <2>, to be ready
for LPAE addresses...

> +/ {
> +	model = "XENVM-4.2";
> +	compatible = "xen,xenvm-4.2", "arm,vexpress";
> +	interrupt-parent = <&gic>;
> +
> +	chosen {
> +		bootargs = "earlyprintk console=hvc0 root=/dev/xvda init=/sbin/init";
> +	};
> +
> +	cpus {
> +		#address-cells = <1>;
> +		#size-cells = <0>;
> +
> +		cpu@0 {
> +			device_type = "cpu";
> +			compatible = "arm,cortex-a15";
> +			reg = <0>;
> +		};
> +	};
> +
> +	memory {

Formally, it should be memory@80000000, not that I have any strong
feelings about it :-)

> +		device_type = "memory";
> +		reg = <0x80000000 0x08000000>;
> +	};
> +
> +	gic: interrupt-controller@2c001000 {
> +		compatible = "arm,cortex-a9-gic";
> +		#interrupt-cells = <3>;
> +		#address-cells = <0>;
> +		interrupt-controller;
> +		reg = <0x2c001000 0x1000>,
> +		      <0x2c002000 0x100>;
> +	};
> +
> +	timer {
> +		compatible = "arm,armv7-timer";
> +		interrupts = <1 13 0xf08>,
> +			     <1 14 0xf08>,
> +			     <1 11 0xf08>,
> +			     <1 10 0xf08>;
> +	};
> +
> +	hypervisor {
> +		compatible = "xen,xen-4.2", "xen,xen";
> +		reg = <0xb0000000 0x20000>;
> +		interrupts = <1 15 0xf08>;
> +	};

Is this binding documented somewhere - I mean in
Documentation/devicetree/bindings?

> +	motherboard {
> +		arm,v2m-memory-map = "rs1";
> +		ranges = <0 0 0x08000000 0x04000000>,
> +			 <1 0 0x14000000 0x04000000>,
> +			 <2 0 0x18000000 0x04000000>,
> +			 <3 0 0x1c000000 0x04000000>,
> +			 <4 0 0x0c000000 0x04000000>,
> +			 <5 0 0x10000000 0x04000000>;
> +
> +		interrupt-map-mask = <0 0 63>;
> +		interrupt-map = <0 0  0 &gic 0  0 4>,
> +				<0 0  1 &gic 0  1 4>,
> +				<0 0  2 &gic 0  2 4>,
> +				<0 0  3 &gic 0  3 4>,
> +				<0 0  4 &gic 0  4 4>,
> +				<0 0  5 &gic 0  5 4>,
> +				<0 0  6 &gic 0  6 4>,
> +				<0 0  7 &gic 0  7 4>,
> +				<0 0  8 &gic 0  8 4>,
> +				<0 0  9 &gic 0  9 4>,
> +				<0 0 10 &gic 0 10 4>,
> +				<0 0 11 &gic 0 11 4>,
> +				<0 0 12 &gic 0 12 4>,
> +				<0 0 13 &gic 0 13 4>,
> +				<0 0 14 &gic 0 14 4>,
> +				<0 0 15 &gic 0 15 4>,
> +				<0 0 16 &gic 0 16 4>,
> +				<0 0 17 &gic 0 17 4>,
> +				<0 0 18 &gic 0 18 4>,
> +				<0 0 19 &gic 0 19 4>,
> +				<0 0 20 &gic 0 20 4>,
> +				<0 0 21 &gic 0 21 4>,
> +				<0 0 22 &gic 0 22 4>,
> +				<0 0 23 &gic 0 23 4>,
> +				<0 0 24 &gic 0 24 4>,
> +				<0 0 25 &gic 0 25 4>,
> +				<0 0 26 &gic 0 26 4>,
> +				<0 0 27 &gic 0 27 4>,
> +				<0 0 28 &gic 0 28 4>,
> +				<0 0 29 &gic 0 29 4>,
> +				<0 0 30 &gic 0 30 4>,
> +				<0 0 31 &gic 0 31 4>,
> +				<0 0 32 &gic 0 32 4>,
> +				<0 0 33 &gic 0 33 4>,
> +				<0 0 34 &gic 0 34 4>,
> +				<0 0 35 &gic 0 35 4>,
> +				<0 0 36 &gic 0 36 4>,
> +				<0 0 37 &gic 0 37 4>,
> +				<0 0 38 &gic 0 38 4>,
> +				<0 0 39 &gic 0 39 4>,
> +				<0 0 40 &gic 0 40 4>,
> +				<0 0 41 &gic 0 41 4>,
> +				<0 0 42 &gic 0 42 4>;
> +	};
> +};

You've lost me here... You have ranges and interrupt map, but don't
include motherboard file. Is it a mistake? If not, you could remove the
ranges and interrupt-map, but where do you get your peripherals from
then?

> diff --git a/arch/arm/mach-vexpress/Makefile.boot b/arch/arm/mach-vexpress/Makefile.boot
> index 318d308..5c633c5 100644
> --- a/arch/arm/mach-vexpress/Makefile.boot
> +++ b/arch/arm/mach-vexpress/Makefile.boot
> @@ -7,4 +7,5 @@ initrd_phys-y	:= 0x60800000
>  dtb-$(CONFIG_ARCH_VEXPRESS_DT)	+= vexpress-v2p-ca5s.dtb \
>  				   vexpress-v2p-ca9.dtb \
>  				   vexpress-v2p-ca15-tc1.dtb \
> -				   vexpress-v2p-ca15_a7.dtb
> +				   vexpress-v2p-ca15_a7.dtb \
> +				   vexpress-xenvm-4.2.dtb

Cheers!

Pawel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 20 10:06:28 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Sep 2012 10: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 1TEdeA-0006RX-7g; Thu, 20 Sep 2012 10:06:14 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <pawel.moll@arm.com>) id 1TEde8-0006RS-Pi
	for xen-devel@lists.xensource.com; Thu, 20 Sep 2012 10:06:13 +0000
Received: from [85.158.138.51:11473] by server-2.bemta-3.messagelabs.com id
	55/47-04862-39AEA505; Thu, 20 Sep 2012 10:06:11 +0000
X-Env-Sender: pawel.moll@arm.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1348135571!31286738!1
X-Originating-IP: [91.220.42.44]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogOTEuMjIwLjQyLjQ0ID0+IDI5ODkzOA==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32394 invoked from network); 20 Sep 2012 10:06:11 -0000
Received: from service87.mimecast.com (HELO service87.mimecast.com)
	(91.220.42.44) by server-11.tower-174.messagelabs.com with SMTP;
	20 Sep 2012 10:06:11 -0000
Received: from cam-owa1.Emea.Arm.com (fw-tnat.cambridge.arm.com
	[217.140.96.21]) by service87.mimecast.com;
	Thu, 20 Sep 2012 11:06:10 +0100
Received: from [10.1.205.42] ([10.1.255.212]) by cam-owa1.Emea.Arm.com with
	Microsoft SMTPSVC(6.0.3790.0); Thu, 20 Sep 2012 11:06:04 +0100
Message-ID: <1348135563.11116.94.camel@hornet>
From: Pawel Moll <pawel.moll@arm.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Thu, 20 Sep 2012 11:06:03 +0100
In-Reply-To: <1348076658-4511-1-git-send-email-stefano.stabellini@eu.citrix.com>
References: <1348076658-4511-1-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: Evolution 3.2.3-0ubuntu6
Mime-Version: 1.0
X-OriginalArrivalTime: 20 Sep 2012 10:06:04.0298 (UTC)
	FILETIME=[8B6F46A0:01CD9717]
X-MC-Unique: 112092011061006101
Cc: "linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
	"Ian.Campbell@citrix.com" <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH] arm: introduce a DTS for Xen unprivileged
 virtual 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

Morning,

On Wed, 2012-09-19 at 18:44 +0100, Stefano Stabellini wrote:
> +/dts-v1/;
> +
> +/include/ "skeleton.dtsi"

Any particular reason to include skeleton? And I think it would be
better to use #address-cells = <2> and #size-cells = <2>, to be ready
for LPAE addresses...

> +/ {
> +	model = "XENVM-4.2";
> +	compatible = "xen,xenvm-4.2", "arm,vexpress";
> +	interrupt-parent = <&gic>;
> +
> +	chosen {
> +		bootargs = "earlyprintk console=hvc0 root=/dev/xvda init=/sbin/init";
> +	};
> +
> +	cpus {
> +		#address-cells = <1>;
> +		#size-cells = <0>;
> +
> +		cpu@0 {
> +			device_type = "cpu";
> +			compatible = "arm,cortex-a15";
> +			reg = <0>;
> +		};
> +	};
> +
> +	memory {

Formally, it should be memory@80000000, not that I have any strong
feelings about it :-)

> +		device_type = "memory";
> +		reg = <0x80000000 0x08000000>;
> +	};
> +
> +	gic: interrupt-controller@2c001000 {
> +		compatible = "arm,cortex-a9-gic";
> +		#interrupt-cells = <3>;
> +		#address-cells = <0>;
> +		interrupt-controller;
> +		reg = <0x2c001000 0x1000>,
> +		      <0x2c002000 0x100>;
> +	};
> +
> +	timer {
> +		compatible = "arm,armv7-timer";
> +		interrupts = <1 13 0xf08>,
> +			     <1 14 0xf08>,
> +			     <1 11 0xf08>,
> +			     <1 10 0xf08>;
> +	};
> +
> +	hypervisor {
> +		compatible = "xen,xen-4.2", "xen,xen";
> +		reg = <0xb0000000 0x20000>;
> +		interrupts = <1 15 0xf08>;
> +	};

Is this binding documented somewhere - I mean in
Documentation/devicetree/bindings?

> +	motherboard {
> +		arm,v2m-memory-map = "rs1";
> +		ranges = <0 0 0x08000000 0x04000000>,
> +			 <1 0 0x14000000 0x04000000>,
> +			 <2 0 0x18000000 0x04000000>,
> +			 <3 0 0x1c000000 0x04000000>,
> +			 <4 0 0x0c000000 0x04000000>,
> +			 <5 0 0x10000000 0x04000000>;
> +
> +		interrupt-map-mask = <0 0 63>;
> +		interrupt-map = <0 0  0 &gic 0  0 4>,
> +				<0 0  1 &gic 0  1 4>,
> +				<0 0  2 &gic 0  2 4>,
> +				<0 0  3 &gic 0  3 4>,
> +				<0 0  4 &gic 0  4 4>,
> +				<0 0  5 &gic 0  5 4>,
> +				<0 0  6 &gic 0  6 4>,
> +				<0 0  7 &gic 0  7 4>,
> +				<0 0  8 &gic 0  8 4>,
> +				<0 0  9 &gic 0  9 4>,
> +				<0 0 10 &gic 0 10 4>,
> +				<0 0 11 &gic 0 11 4>,
> +				<0 0 12 &gic 0 12 4>,
> +				<0 0 13 &gic 0 13 4>,
> +				<0 0 14 &gic 0 14 4>,
> +				<0 0 15 &gic 0 15 4>,
> +				<0 0 16 &gic 0 16 4>,
> +				<0 0 17 &gic 0 17 4>,
> +				<0 0 18 &gic 0 18 4>,
> +				<0 0 19 &gic 0 19 4>,
> +				<0 0 20 &gic 0 20 4>,
> +				<0 0 21 &gic 0 21 4>,
> +				<0 0 22 &gic 0 22 4>,
> +				<0 0 23 &gic 0 23 4>,
> +				<0 0 24 &gic 0 24 4>,
> +				<0 0 25 &gic 0 25 4>,
> +				<0 0 26 &gic 0 26 4>,
> +				<0 0 27 &gic 0 27 4>,
> +				<0 0 28 &gic 0 28 4>,
> +				<0 0 29 &gic 0 29 4>,
> +				<0 0 30 &gic 0 30 4>,
> +				<0 0 31 &gic 0 31 4>,
> +				<0 0 32 &gic 0 32 4>,
> +				<0 0 33 &gic 0 33 4>,
> +				<0 0 34 &gic 0 34 4>,
> +				<0 0 35 &gic 0 35 4>,
> +				<0 0 36 &gic 0 36 4>,
> +				<0 0 37 &gic 0 37 4>,
> +				<0 0 38 &gic 0 38 4>,
> +				<0 0 39 &gic 0 39 4>,
> +				<0 0 40 &gic 0 40 4>,
> +				<0 0 41 &gic 0 41 4>,
> +				<0 0 42 &gic 0 42 4>;
> +	};
> +};

You've lost me here... You have ranges and interrupt map, but don't
include motherboard file. Is it a mistake? If not, you could remove the
ranges and interrupt-map, but where do you get your peripherals from
then?

> diff --git a/arch/arm/mach-vexpress/Makefile.boot b/arch/arm/mach-vexpress/Makefile.boot
> index 318d308..5c633c5 100644
> --- a/arch/arm/mach-vexpress/Makefile.boot
> +++ b/arch/arm/mach-vexpress/Makefile.boot
> @@ -7,4 +7,5 @@ initrd_phys-y	:= 0x60800000
>  dtb-$(CONFIG_ARCH_VEXPRESS_DT)	+= vexpress-v2p-ca5s.dtb \
>  				   vexpress-v2p-ca9.dtb \
>  				   vexpress-v2p-ca15-tc1.dtb \
> -				   vexpress-v2p-ca15_a7.dtb
> +				   vexpress-v2p-ca15_a7.dtb \
> +				   vexpress-xenvm-4.2.dtb

Cheers!

Pawel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 20 10:10:00 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Sep 2012 10: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 1TEdha-0006Z1-S3; Thu, 20 Sep 2012 10:09:46 +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 1TEdha-0006Yw-AJ
	for xen-devel@lists.xen.org; Thu, 20 Sep 2012 10:09:46 +0000
Received: from [85.158.139.83:62695] by server-11.bemta-5.messagelabs.com id
	BA/FE-24658-96BEA505; Thu, 20 Sep 2012 10:09:45 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-6.tower-182.messagelabs.com!1348135784!27467063!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA1MDk4NTY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5069 invoked from network); 20 Sep 2012 10:09:45 -0000
Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25)
	by server-6.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 20 Sep 2012 10:09:45 -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 E6BFD1834;
	Thu, 20 Sep 2012 13:09:43 +0300 (EEST)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id A6F6C2005D; Thu, 20 Sep 2012 13:09:43 +0300 (EEST)
Date: Thu, 20 Sep 2012 13:09:43 +0300
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: Oliver Chick <oliver.chick@citrix.com>
Message-ID: <20120920100943.GX8912@reaktio.net>
References: <1348051887-21885-1-git-send-email-oliver.chick@citrix.com>
	<20120919131632.GS8912@reaktio.net>
	<1348133733.24539.8.camel@oliverchick-Precision-WorkStation-T3400>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1348133733.24539.8.camel@oliverchick-Precision-WorkStation-T3400>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: "konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] Persistent grant maps for xen blk drivers
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="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, Sep 20, 2012 at 10:35:33AM +0100, Oliver Chick wrote:
> I have attached a graph that shows the results of my benchmarking.
> =

> The setup is:
> -Xeon X5650
> -32GB of Ram
> -Xen 4.2
> -Linux 3.5.0 for dom0 and domus
> -Dom0 has 24 CPUs.
> -Each guest has a (separate) xvdb backed by a 1GB ramdisk (/dev/ramX) in
> dom0. No LVM on these.
> -The setup is that initially 1 guest does an fio sequential read of the
> ramdisk, then 2, then 3 etc.
> -The y axis is the sum of the iops, as reported by the guests' fio
> output.
> =


Thanks! The graph looks pretty nice :)

-- Pasi

> On Wed, 2012-09-19 at 14:16 +0100, X5650Pasi K=E4rkk=E4inen wrote:
> > On Wed, Sep 19, 2012 at 11:51:27AM +0100, Oliver Chick wrote:
> > > This patch implements persistent grants for the xen-blk{front,back}
> > > mechanism. The effect of this change is to reduce the number of unmap
> > > operations performed, since they cause a (costly) TLB shootdown. This
> > > allows the I/O performance to scale better when a large number of VMs
> > > are performing I/O.
> > > =

> > > Previously, the blkfront driver was supplied a bvec[] from the request
> > > queue. This was granted to dom0; dom0 performed the I/O and wrote
> > > directly into the grant-mapped memory and unmapped it; blkfront then
> > > removed foreign access for that grant. The cost of unmapping scales
> > > badly with the number of CPUs in Dom0. An experiment showed that when
> > > Dom0 has 24 VCPUs, and guests are performing parallel I/O to a
> > > ramdisk, the IPIs from performing unmap's is a bottleneck at 5 guests
> > > (at which point 650,000 IOPS are being performed in total). If more
> > > than 5 guests are used, the performance declines. By 10 guests, only
> > > 400,000 IOPS are being performed.
> > > =

> > > This patch improves performance by only unmapping when the connection
> > > between blkfront and back is broken.
> > >
> > =

> > So how many IOPS can you get with this patch / persistent grants ? =

> > =

> > -- Pasi
> > =

> =




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 20 10:10:00 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Sep 2012 10: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 1TEdha-0006Z1-S3; Thu, 20 Sep 2012 10:09:46 +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 1TEdha-0006Yw-AJ
	for xen-devel@lists.xen.org; Thu, 20 Sep 2012 10:09:46 +0000
Received: from [85.158.139.83:62695] by server-11.bemta-5.messagelabs.com id
	BA/FE-24658-96BEA505; Thu, 20 Sep 2012 10:09:45 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-6.tower-182.messagelabs.com!1348135784!27467063!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA1MDk4NTY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5069 invoked from network); 20 Sep 2012 10:09:45 -0000
Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25)
	by server-6.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 20 Sep 2012 10:09:45 -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 E6BFD1834;
	Thu, 20 Sep 2012 13:09:43 +0300 (EEST)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id A6F6C2005D; Thu, 20 Sep 2012 13:09:43 +0300 (EEST)
Date: Thu, 20 Sep 2012 13:09:43 +0300
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: Oliver Chick <oliver.chick@citrix.com>
Message-ID: <20120920100943.GX8912@reaktio.net>
References: <1348051887-21885-1-git-send-email-oliver.chick@citrix.com>
	<20120919131632.GS8912@reaktio.net>
	<1348133733.24539.8.camel@oliverchick-Precision-WorkStation-T3400>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1348133733.24539.8.camel@oliverchick-Precision-WorkStation-T3400>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: "konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] Persistent grant maps for xen blk drivers
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="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, Sep 20, 2012 at 10:35:33AM +0100, Oliver Chick wrote:
> I have attached a graph that shows the results of my benchmarking.
> =

> The setup is:
> -Xeon X5650
> -32GB of Ram
> -Xen 4.2
> -Linux 3.5.0 for dom0 and domus
> -Dom0 has 24 CPUs.
> -Each guest has a (separate) xvdb backed by a 1GB ramdisk (/dev/ramX) in
> dom0. No LVM on these.
> -The setup is that initially 1 guest does an fio sequential read of the
> ramdisk, then 2, then 3 etc.
> -The y axis is the sum of the iops, as reported by the guests' fio
> output.
> =


Thanks! The graph looks pretty nice :)

-- Pasi

> On Wed, 2012-09-19 at 14:16 +0100, X5650Pasi K=E4rkk=E4inen wrote:
> > On Wed, Sep 19, 2012 at 11:51:27AM +0100, Oliver Chick wrote:
> > > This patch implements persistent grants for the xen-blk{front,back}
> > > mechanism. The effect of this change is to reduce the number of unmap
> > > operations performed, since they cause a (costly) TLB shootdown. This
> > > allows the I/O performance to scale better when a large number of VMs
> > > are performing I/O.
> > > =

> > > Previously, the blkfront driver was supplied a bvec[] from the request
> > > queue. This was granted to dom0; dom0 performed the I/O and wrote
> > > directly into the grant-mapped memory and unmapped it; blkfront then
> > > removed foreign access for that grant. The cost of unmapping scales
> > > badly with the number of CPUs in Dom0. An experiment showed that when
> > > Dom0 has 24 VCPUs, and guests are performing parallel I/O to a
> > > ramdisk, the IPIs from performing unmap's is a bottleneck at 5 guests
> > > (at which point 650,000 IOPS are being performed in total). If more
> > > than 5 guests are used, the performance declines. By 10 guests, only
> > > 400,000 IOPS are being performed.
> > > =

> > > This patch improves performance by only unmapping when the connection
> > > between blkfront and back is broken.
> > >
> > =

> > So how many IOPS can you get with this patch / persistent grants ? =

> > =

> > -- Pasi
> > =

> =




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 20 10:17:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Sep 2012 10:17:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TEdoj-0006kK-Cq; Thu, 20 Sep 2012 10:17: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 1TEdoh-0006kC-Nm
	for xen-devel@lists.xensource.com; Thu, 20 Sep 2012 10:17:08 +0000
Received: from [85.158.138.51:2335] by server-6.bemta-3.messagelabs.com id
	1E/F2-29694-32DEA505; Thu, 20 Sep 2012 10:17:07 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1348136224!23222585!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTA0NTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31292 invoked from network); 20 Sep 2012 10:17:05 -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 Sep 2012 10:17:05 -0000
X-IronPort-AV: E=Sophos;i="4.80,453,1344211200"; d="scan'208";a="14651511"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Sep 2012 10:17: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.279.1;
	Thu, 20 Sep 2012 11:17:03 +0100
Message-ID: <1348136222.26501.19.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Thu, 20 Sep 2012 11:17:02 +0100
In-Reply-To: <1348076658-4511-1-git-send-email-stefano.stabellini@eu.citrix.com>
References: <1348076658-4511-1-git-send-email-stefano.stabellini@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Pawel Moll <pawel.moll@arm.com>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH] arm: introduce a DTS for Xen unprivileged
 virtual 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, 2012-09-19 at 18:44 +0100, Stefano Stabellini wrote:
> +/include/ "skeleton.dtsi"
> +
> +/ {
> +	model = "XENVM-4.2";

Why the shouty caps?

Did you mean 4.3 here and throughout?

> +	compatible = "xen,xenvm-4.2", "arm,vexpress";

Is this second compatible thing actually true? We don't actually emulate
much (anything?) of what would be on a real vexpress motherboard.

"arm,vexpress" is used only in v2m.c and I don't think we want the
majority of that -- we don't provide any of the peripherals which it
registers.

I think the only things we might want out of that lot are the arch timer
and perhaps the uart0 (as a debug port).

I suspect we should have our own xen machine .c.

[...]
> +	gic: interrupt-controller@2c001000 {
> +		compatible = "arm,cortex-a9-gic";

Don't we mean "arm,cortex-a15-gic" here? That's what we actually
provide. I'm not sure how the a9 and a15 differ.

> +		#interrupt-cells = <3>;
> +		#address-cells = <0>;
> +		interrupt-controller;
> +		reg = <0x2c001000 0x1000>,
> +		      <0x2c002000 0x100>;
> +	};
> +

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 20 10:17:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Sep 2012 10:17:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TEdoj-0006kK-Cq; Thu, 20 Sep 2012 10:17: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 1TEdoh-0006kC-Nm
	for xen-devel@lists.xensource.com; Thu, 20 Sep 2012 10:17:08 +0000
Received: from [85.158.138.51:2335] by server-6.bemta-3.messagelabs.com id
	1E/F2-29694-32DEA505; Thu, 20 Sep 2012 10:17:07 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1348136224!23222585!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTA0NTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31292 invoked from network); 20 Sep 2012 10:17:05 -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 Sep 2012 10:17:05 -0000
X-IronPort-AV: E=Sophos;i="4.80,453,1344211200"; d="scan'208";a="14651511"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Sep 2012 10:17: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.279.1;
	Thu, 20 Sep 2012 11:17:03 +0100
Message-ID: <1348136222.26501.19.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Thu, 20 Sep 2012 11:17:02 +0100
In-Reply-To: <1348076658-4511-1-git-send-email-stefano.stabellini@eu.citrix.com>
References: <1348076658-4511-1-git-send-email-stefano.stabellini@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Pawel Moll <pawel.moll@arm.com>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH] arm: introduce a DTS for Xen unprivileged
 virtual 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, 2012-09-19 at 18:44 +0100, Stefano Stabellini wrote:
> +/include/ "skeleton.dtsi"
> +
> +/ {
> +	model = "XENVM-4.2";

Why the shouty caps?

Did you mean 4.3 here and throughout?

> +	compatible = "xen,xenvm-4.2", "arm,vexpress";

Is this second compatible thing actually true? We don't actually emulate
much (anything?) of what would be on a real vexpress motherboard.

"arm,vexpress" is used only in v2m.c and I don't think we want the
majority of that -- we don't provide any of the peripherals which it
registers.

I think the only things we might want out of that lot are the arch timer
and perhaps the uart0 (as a debug port).

I suspect we should have our own xen machine .c.

[...]
> +	gic: interrupt-controller@2c001000 {
> +		compatible = "arm,cortex-a9-gic";

Don't we mean "arm,cortex-a15-gic" here? That's what we actually
provide. I'm not sure how the a9 and a15 differ.

> +		#interrupt-cells = <3>;
> +		#address-cells = <0>;
> +		interrupt-controller;
> +		reg = <0x2c001000 0x1000>,
> +		      <0x2c002000 0x100>;
> +	};
> +

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 20 10:22:44 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Sep 2012 10:22: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 1TEdtt-00076o-8a; Thu, 20 Sep 2012 10:22: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 1TEdts-00076g-Dc
	for xen-devel@lists.xen.org; Thu, 20 Sep 2012 10:22:28 +0000
Received: from [85.158.139.211:37303] by server-1.bemta-5.messagelabs.com id
	E7/02-04809-36EEA505; Thu, 20 Sep 2012 10:22:27 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-6.tower-206.messagelabs.com!1348136547!19300509!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2451 invoked from network); 20 Sep 2012 10:22:27 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-6.tower-206.messagelabs.com with SMTP;
	20 Sep 2012 10:22:27 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 20 Sep 2012 11:22:26 +0100
Message-Id: <505B0A97020000780009C986@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 20 Sep 2012 11:22:47 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Jean Guyader" <jean.guyader@citrix.com>
References: <1348134426-25320-1-git-send-email-jean.guyader@citrix.com>
In-Reply-To: <1348134426-25320-1-git-send-email-jean.guyader@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: tim@xen.org, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 0/4] Add V4V to Xen v5
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.09.12 at 11:47, Jean Guyader <jean.guyader@citrix.com> wrote:
> v5 changes:
>         - Fix prototypes in v4v.h for do_v4v_op
>         - Add padding to make sure all the structures
>           are 64 bits aligned
>         - Replace [0] with []

But that isn't standard C either (before C99 at least).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 20 10:22:44 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Sep 2012 10:22: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 1TEdtt-00076o-8a; Thu, 20 Sep 2012 10:22: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 1TEdts-00076g-Dc
	for xen-devel@lists.xen.org; Thu, 20 Sep 2012 10:22:28 +0000
Received: from [85.158.139.211:37303] by server-1.bemta-5.messagelabs.com id
	E7/02-04809-36EEA505; Thu, 20 Sep 2012 10:22:27 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-6.tower-206.messagelabs.com!1348136547!19300509!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2451 invoked from network); 20 Sep 2012 10:22:27 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-6.tower-206.messagelabs.com with SMTP;
	20 Sep 2012 10:22:27 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 20 Sep 2012 11:22:26 +0100
Message-Id: <505B0A97020000780009C986@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 20 Sep 2012 11:22:47 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Jean Guyader" <jean.guyader@citrix.com>
References: <1348134426-25320-1-git-send-email-jean.guyader@citrix.com>
In-Reply-To: <1348134426-25320-1-git-send-email-jean.guyader@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: tim@xen.org, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 0/4] Add V4V to Xen v5
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.09.12 at 11:47, Jean Guyader <jean.guyader@citrix.com> wrote:
> v5 changes:
>         - Fix prototypes in v4v.h for do_v4v_op
>         - Add padding to make sure all the structures
>           are 64 bits aligned
>         - Replace [0] with []

But that isn't standard C either (before C99 at least).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 20 10:24:58 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Sep 2012 10:24:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TEdw2-0007Du-QD; Thu, 20 Sep 2012 10:24:42 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dunlapg@gmail.com>) id 1TEdw1-0007Dn-30
	for xen-devel@lists.xen.org; Thu, 20 Sep 2012 10:24:41 +0000
Received: from [85.158.137.99:47562] by server-2.bemta-3.messagelabs.com id
	E8/50-04862-8EEEA505; Thu, 20 Sep 2012 10:24:40 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-14.tower-217.messagelabs.com!1348136679!18416029!1
X-Originating-IP: [209.85.215.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 561 invoked from network); 20 Sep 2012 10:24:39 -0000
Received: from mail-ey0-f173.google.com (HELO mail-ey0-f173.google.com)
	(209.85.215.173)
	by server-14.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Sep 2012 10:24:39 -0000
Received: by eaac13 with SMTP id c13so681273eaa.32
	for <xen-devel@lists.xen.org>; Thu, 20 Sep 2012 03:24:39 -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=cEgUhEitTrWjmlfD6uPfpdJK3ge+mBqPLHSwGMMgESs=;
	b=IBifKBIqjPW9h2m+v76ehQzWF5bv7N7vZSJVNKNyYQb1g9+mR29KLCBRan6hiwAnc8
	oSYtBsX7Tm46YU/ZpqSzW2FekKZ2FdSEKp3nag9aQ0usKZC7oNTWYFfqDKg0vNaNjUgM
	CYOsajy5+4Gv4IYFOiy1UHyIc9kY4G+YQQAYwrTSh+zgK6jCma2Z8fed7W2vyP5D/i1/
	7CIqV+c8153+zo0cfKAPA16WeZtP54+rvjI8s0X4ZmGYVhvKCH8EEC8S83gj1RX5vnSY
	8b6yiqix2jJ3EVoFGifYiDYvlsrO8M7FkQ5cgyr+L1TUtI2bevAcgqtSHqND2tVUm4xW
	PEHQ==
MIME-Version: 1.0
Received: by 10.14.199.67 with SMTP id w43mr1566301een.33.1348136679529; Thu,
	20 Sep 2012 03:24:39 -0700 (PDT)
Received: by 10.14.215.195 with HTTP; Thu, 20 Sep 2012 03:24:39 -0700 (PDT)
In-Reply-To: <201209191918.35305.hahn@univention.de>
References: <CAFLBxZYtmJ_bKFb90r45=C4Pq1-oe5Fy=eygSsQf4BcGj3EqGA@mail.gmail.com>
	<201209191918.35305.hahn@univention.de>
Date: Thu, 20 Sep 2012 11:24:39 +0100
X-Google-Sender-Auth: rjqDrUB7D1PdRKmx0NCTBuWgc7c
Message-ID: <CAFLBxZZko72sMVPr9LEyea7E-tNx74qCvRoxqPZ-eWbvhvctgQ@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: Philipp Hahn <hahn@univention.de>
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Xen 4.3 development 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, Sep 19, 2012 at 6:18 PM, Philipp Hahn <hahn@univention.de> wrote:
> Hello,
>
> On Wednesday 19 September 2012 18:58:02 George Dunlap wrote:
>> * libvirt integration
>>   owner: ?
>>   status: ?
>>   To begin with, we need someone to go and make some lists:
>>   - Features available in libvirt/KVM not available in libvirt/Xen
>>   - Features available in xl/Xen but not available in libvirt/Xen
>
> Libvirt already has a comparison matrix at
> <http://libvirt.org/hvsupport.html>. That file is actually generated from by
> docs/hvsupport.pl by looking at the implemented functions.

Ah, very interesting -- so "libxl" is the one we particularly care
about.  "Xen" is presumably "xm"?  Would KVM fall under "qemu"?

I guess the next step would be for someone to go through and identify
user-level features that would be enabled by the various functions, so
that we can figure out which functions are important to us.

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 20 10:24:58 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Sep 2012 10:24:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TEdw2-0007Du-QD; Thu, 20 Sep 2012 10:24:42 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dunlapg@gmail.com>) id 1TEdw1-0007Dn-30
	for xen-devel@lists.xen.org; Thu, 20 Sep 2012 10:24:41 +0000
Received: from [85.158.137.99:47562] by server-2.bemta-3.messagelabs.com id
	E8/50-04862-8EEEA505; Thu, 20 Sep 2012 10:24:40 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-14.tower-217.messagelabs.com!1348136679!18416029!1
X-Originating-IP: [209.85.215.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 561 invoked from network); 20 Sep 2012 10:24:39 -0000
Received: from mail-ey0-f173.google.com (HELO mail-ey0-f173.google.com)
	(209.85.215.173)
	by server-14.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Sep 2012 10:24:39 -0000
Received: by eaac13 with SMTP id c13so681273eaa.32
	for <xen-devel@lists.xen.org>; Thu, 20 Sep 2012 03:24:39 -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=cEgUhEitTrWjmlfD6uPfpdJK3ge+mBqPLHSwGMMgESs=;
	b=IBifKBIqjPW9h2m+v76ehQzWF5bv7N7vZSJVNKNyYQb1g9+mR29KLCBRan6hiwAnc8
	oSYtBsX7Tm46YU/ZpqSzW2FekKZ2FdSEKp3nag9aQ0usKZC7oNTWYFfqDKg0vNaNjUgM
	CYOsajy5+4Gv4IYFOiy1UHyIc9kY4G+YQQAYwrTSh+zgK6jCma2Z8fed7W2vyP5D/i1/
	7CIqV+c8153+zo0cfKAPA16WeZtP54+rvjI8s0X4ZmGYVhvKCH8EEC8S83gj1RX5vnSY
	8b6yiqix2jJ3EVoFGifYiDYvlsrO8M7FkQ5cgyr+L1TUtI2bevAcgqtSHqND2tVUm4xW
	PEHQ==
MIME-Version: 1.0
Received: by 10.14.199.67 with SMTP id w43mr1566301een.33.1348136679529; Thu,
	20 Sep 2012 03:24:39 -0700 (PDT)
Received: by 10.14.215.195 with HTTP; Thu, 20 Sep 2012 03:24:39 -0700 (PDT)
In-Reply-To: <201209191918.35305.hahn@univention.de>
References: <CAFLBxZYtmJ_bKFb90r45=C4Pq1-oe5Fy=eygSsQf4BcGj3EqGA@mail.gmail.com>
	<201209191918.35305.hahn@univention.de>
Date: Thu, 20 Sep 2012 11:24:39 +0100
X-Google-Sender-Auth: rjqDrUB7D1PdRKmx0NCTBuWgc7c
Message-ID: <CAFLBxZZko72sMVPr9LEyea7E-tNx74qCvRoxqPZ-eWbvhvctgQ@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: Philipp Hahn <hahn@univention.de>
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Xen 4.3 development 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, Sep 19, 2012 at 6:18 PM, Philipp Hahn <hahn@univention.de> wrote:
> Hello,
>
> On Wednesday 19 September 2012 18:58:02 George Dunlap wrote:
>> * libvirt integration
>>   owner: ?
>>   status: ?
>>   To begin with, we need someone to go and make some lists:
>>   - Features available in libvirt/KVM not available in libvirt/Xen
>>   - Features available in xl/Xen but not available in libvirt/Xen
>
> Libvirt already has a comparison matrix at
> <http://libvirt.org/hvsupport.html>. That file is actually generated from by
> docs/hvsupport.pl by looking at the implemented functions.

Ah, very interesting -- so "libxl" is the one we particularly care
about.  "Xen" is presumably "xm"?  Would KVM fall under "qemu"?

I guess the next step would be for someone to go through and identify
user-level features that would be enabled by the various functions, so
that we can figure out which functions are important to us.

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 20 10:28:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Sep 2012 10: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 1TEdz6-0007PK-DG; Thu, 20 Sep 2012 10:27:52 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jean.guyader@gmail.com>) id 1TEdz4-0007PA-5i
	for xen-devel@lists.xen.org; Thu, 20 Sep 2012 10:27:50 +0000
Received: from [85.158.137.99:25434] by server-2.bemta-3.messagelabs.com id
	B1/F6-04862-5AFEA505; Thu, 20 Sep 2012 10:27:49 +0000
X-Env-Sender: jean.guyader@gmail.com
X-Msg-Ref: server-10.tower-217.messagelabs.com!1348136867!18450020!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-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29908 invoked from network); 20 Sep 2012 10:27:48 -0000
Received: from mail-vb0-f45.google.com (HELO mail-vb0-f45.google.com)
	(209.85.212.45)
	by server-10.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Sep 2012 10:27:48 -0000
Received: by vbip1 with SMTP id p1so2827679vbi.32
	for <xen-devel@lists.xen.org>; Thu, 20 Sep 2012 03:27: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:from:date:message-id:subject:to
	:cc:content-type;
	bh=0lfBsEtqx1044Xr9el6ETk/EmjoVSfL3N4LkDcJrjKc=;
	b=J/qkPFt1RvmSJkl7HPVk1g6T7K/wICF7L8YhzV57Bvz0Xkj1hircTpMQ9rsDArv+pg
	eVs+8JVcdbqMCGs0tpX6VGtBlRsUJZPahKK3MFs0qnEiygcsINnWq4syTbTp2nekkciV
	1JpwaW5P6BgS3R6o+mDWjunAqg6KrK0uUH76nJ6Zy2SdNhM1gtI+VS6q6QQNftoA+oVJ
	XoH/VRqASvGIT0Jq/fnW6uu/G68rXnbF+qZNK7clI2+0xvzlouBZDWGoP2Sk8+zx36RM
	Rpw7tqMkVwB2UWEJKb5aMIDNOhpaPis26pNJUkXl4iw9P7Sj/o/iGamHldOxspFolJFi
	p3Zg==
Received: by 10.220.37.194 with SMTP id y2mr773416vcd.44.1348136867058; Thu,
	20 Sep 2012 03:27:47 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.58.91.72 with HTTP; Thu, 20 Sep 2012 03:27:26 -0700 (PDT)
In-Reply-To: <505B0A97020000780009C986@nat28.tlf.novell.com>
References: <1348134426-25320-1-git-send-email-jean.guyader@citrix.com>
	<505B0A97020000780009C986@nat28.tlf.novell.com>
From: Jean Guyader <jean.guyader@gmail.com>
Date: Thu, 20 Sep 2012 11:27:26 +0100
Message-ID: <CAEBdQ91yr0jW+sNgidzdYUjU8=CUZWwsRJ0oXHAriMbSbo2JzQ@mail.gmail.com>
To: Jan Beulich <JBeulich@suse.com>
Cc: tim@xen.org, Jean Guyader <jean.guyader@citrix.com>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 0/4] Add V4V to Xen v5
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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 September 2012 11:22, Jan Beulich <JBeulich@suse.com> wrote:
>>>> On 20.09.12 at 11:47, Jean Guyader <jean.guyader@citrix.com> wrote:
>> v5 changes:
>>         - Fix prototypes in v4v.h for do_v4v_op
>>         - Add padding to make sure all the structures
>>           are 64 bits aligned
>>         - Replace [0] with []
>
> But that isn't standard C either (before C99 at least).
>

I found that in xen/public/physdev.h

struct physdev_pci_device_add {
    /* IN */
    uint16_t seg;
    uint8_t bus;
    uint8_t devfn;
    uint32_t flags;
    struct {
        uint8_t bus;
        uint8_t devfn;
    } physfn;
#if defined(__STDC_VERSION__) && __STDC_VERSION__ >= 199901L
    uint32_t optarr[];
#elif defined(__GNUC__)
    uint32_t optarr[0];
#endif
};

Would something similar be ok?

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 Sep 20 10:28:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Sep 2012 10: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 1TEdz6-0007PK-DG; Thu, 20 Sep 2012 10:27:52 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jean.guyader@gmail.com>) id 1TEdz4-0007PA-5i
	for xen-devel@lists.xen.org; Thu, 20 Sep 2012 10:27:50 +0000
Received: from [85.158.137.99:25434] by server-2.bemta-3.messagelabs.com id
	B1/F6-04862-5AFEA505; Thu, 20 Sep 2012 10:27:49 +0000
X-Env-Sender: jean.guyader@gmail.com
X-Msg-Ref: server-10.tower-217.messagelabs.com!1348136867!18450020!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-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29908 invoked from network); 20 Sep 2012 10:27:48 -0000
Received: from mail-vb0-f45.google.com (HELO mail-vb0-f45.google.com)
	(209.85.212.45)
	by server-10.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Sep 2012 10:27:48 -0000
Received: by vbip1 with SMTP id p1so2827679vbi.32
	for <xen-devel@lists.xen.org>; Thu, 20 Sep 2012 03:27: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:from:date:message-id:subject:to
	:cc:content-type;
	bh=0lfBsEtqx1044Xr9el6ETk/EmjoVSfL3N4LkDcJrjKc=;
	b=J/qkPFt1RvmSJkl7HPVk1g6T7K/wICF7L8YhzV57Bvz0Xkj1hircTpMQ9rsDArv+pg
	eVs+8JVcdbqMCGs0tpX6VGtBlRsUJZPahKK3MFs0qnEiygcsINnWq4syTbTp2nekkciV
	1JpwaW5P6BgS3R6o+mDWjunAqg6KrK0uUH76nJ6Zy2SdNhM1gtI+VS6q6QQNftoA+oVJ
	XoH/VRqASvGIT0Jq/fnW6uu/G68rXnbF+qZNK7clI2+0xvzlouBZDWGoP2Sk8+zx36RM
	Rpw7tqMkVwB2UWEJKb5aMIDNOhpaPis26pNJUkXl4iw9P7Sj/o/iGamHldOxspFolJFi
	p3Zg==
Received: by 10.220.37.194 with SMTP id y2mr773416vcd.44.1348136867058; Thu,
	20 Sep 2012 03:27:47 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.58.91.72 with HTTP; Thu, 20 Sep 2012 03:27:26 -0700 (PDT)
In-Reply-To: <505B0A97020000780009C986@nat28.tlf.novell.com>
References: <1348134426-25320-1-git-send-email-jean.guyader@citrix.com>
	<505B0A97020000780009C986@nat28.tlf.novell.com>
From: Jean Guyader <jean.guyader@gmail.com>
Date: Thu, 20 Sep 2012 11:27:26 +0100
Message-ID: <CAEBdQ91yr0jW+sNgidzdYUjU8=CUZWwsRJ0oXHAriMbSbo2JzQ@mail.gmail.com>
To: Jan Beulich <JBeulich@suse.com>
Cc: tim@xen.org, Jean Guyader <jean.guyader@citrix.com>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 0/4] Add V4V to Xen v5
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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 September 2012 11:22, Jan Beulich <JBeulich@suse.com> wrote:
>>>> On 20.09.12 at 11:47, Jean Guyader <jean.guyader@citrix.com> wrote:
>> v5 changes:
>>         - Fix prototypes in v4v.h for do_v4v_op
>>         - Add padding to make sure all the structures
>>           are 64 bits aligned
>>         - Replace [0] with []
>
> But that isn't standard C either (before C99 at least).
>

I found that in xen/public/physdev.h

struct physdev_pci_device_add {
    /* IN */
    uint16_t seg;
    uint8_t bus;
    uint8_t devfn;
    uint32_t flags;
    struct {
        uint8_t bus;
        uint8_t devfn;
    } physfn;
#if defined(__STDC_VERSION__) && __STDC_VERSION__ >= 199901L
    uint32_t optarr[];
#elif defined(__GNUC__)
    uint32_t optarr[0];
#endif
};

Would something similar be ok?

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 Sep 20 10:34:37 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Sep 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 1TEe5Q-0007gF-Cy; Thu, 20 Sep 2012 10:34:24 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1TEe5P-0007g4-Je
	for xen-devel@lists.xen.org; Thu, 20 Sep 2012 10:34:23 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1348137256!11707225!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNzYxMzI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29349 invoked from network); 20 Sep 2012 10:34:17 -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;
	20 Sep 2012 10:34:17 -0000
X-IronPort-AV: E=Sophos;i="4.80,453,1344211200"; d="scan'208";a="208665077"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Sep 2012 10:34:15 +0000
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.279.1; Thu, 20 Sep 2012
	06:34:15 -0400
Message-ID: <505AF126.2050806@citrix.com>
Date: Thu, 20 Sep 2012 11:34:14 +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 Iceowl/1.0b1 Icedove/3.0.11
MIME-Version: 1.0
To: Oliver Chick <oliver.chick@citrix.com>
References: <1348051887-21885-1-git-send-email-oliver.chick@citrix.com>
In-Reply-To: <1348051887-21885-1-git-send-email-oliver.chick@citrix.com>
Cc: konrad.wilk@oracle.com, linux-kernel@vger.kernel.org,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] Persistent grant maps for xen blk drivers
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 19/09/12 11:51, Oliver Chick wrote:
> This patch implements persistent grants for the xen-blk{front,back}
> mechanism.
[...]
> We (ijc, and myself) have introduced a new constant,
> BLKIF_MAX_PERS_REQUESTS_PER_DEV. This is to prevent a malicious guest
> from attempting a DoS, by supplying fresh grefs, causing the Dom0
> kernel from to map excessively. 
[...]
> 2) Otherwise, we revert to non-persistent grants for all future grefs.

Why fallback instead of immediately failing the request?

> diff --git a/drivers/block/xen-blkback/blkback.c b/drivers/block/xen-blkback/blkback.c
> index 73f196c..f95dee9 100644
> --- a/drivers/block/xen-blkback/blkback.c
> +++ b/drivers/block/xen-blkback/blkback.c
> @@ -78,6 +78,7 @@ struct pending_req {
>  	unsigned short		operation;
>  	int			status;
>  	struct list_head	free_list;
> +	u8			is_pers;

Using "pers" as an abbreviation for "persistent" isn't obvious.  For
readability it may be better spell it in full.

> +/*
> + * Maximum number of persistent grants that can be mapped by Dom0 for each
> + * interface. This is set to be the size of the ring, as this is a limit on
> + * the number of requests that can be inflight at any one time. 256 imposes
> + * an overhead of 11MB of mapped kernel space per interface.
> + */
> +#define BLKIF_MAX_PERS_REQUESTS_PER_DEV 256

This 11MB per VBD seems like a lot.  With 150 VMs each with 2 VBDs this
requires > 3 GB.  Is this a scalability problem?

Does there need to be a mechanism to expire old maps in blkback?

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 20 10:34:37 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Sep 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 1TEe5Q-0007gF-Cy; Thu, 20 Sep 2012 10:34:24 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1TEe5P-0007g4-Je
	for xen-devel@lists.xen.org; Thu, 20 Sep 2012 10:34:23 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1348137256!11707225!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNzYxMzI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29349 invoked from network); 20 Sep 2012 10:34:17 -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;
	20 Sep 2012 10:34:17 -0000
X-IronPort-AV: E=Sophos;i="4.80,453,1344211200"; d="scan'208";a="208665077"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Sep 2012 10:34:15 +0000
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.279.1; Thu, 20 Sep 2012
	06:34:15 -0400
Message-ID: <505AF126.2050806@citrix.com>
Date: Thu, 20 Sep 2012 11:34:14 +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 Iceowl/1.0b1 Icedove/3.0.11
MIME-Version: 1.0
To: Oliver Chick <oliver.chick@citrix.com>
References: <1348051887-21885-1-git-send-email-oliver.chick@citrix.com>
In-Reply-To: <1348051887-21885-1-git-send-email-oliver.chick@citrix.com>
Cc: konrad.wilk@oracle.com, linux-kernel@vger.kernel.org,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] Persistent grant maps for xen blk drivers
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 19/09/12 11:51, Oliver Chick wrote:
> This patch implements persistent grants for the xen-blk{front,back}
> mechanism.
[...]
> We (ijc, and myself) have introduced a new constant,
> BLKIF_MAX_PERS_REQUESTS_PER_DEV. This is to prevent a malicious guest
> from attempting a DoS, by supplying fresh grefs, causing the Dom0
> kernel from to map excessively. 
[...]
> 2) Otherwise, we revert to non-persistent grants for all future grefs.

Why fallback instead of immediately failing the request?

> diff --git a/drivers/block/xen-blkback/blkback.c b/drivers/block/xen-blkback/blkback.c
> index 73f196c..f95dee9 100644
> --- a/drivers/block/xen-blkback/blkback.c
> +++ b/drivers/block/xen-blkback/blkback.c
> @@ -78,6 +78,7 @@ struct pending_req {
>  	unsigned short		operation;
>  	int			status;
>  	struct list_head	free_list;
> +	u8			is_pers;

Using "pers" as an abbreviation for "persistent" isn't obvious.  For
readability it may be better spell it in full.

> +/*
> + * Maximum number of persistent grants that can be mapped by Dom0 for each
> + * interface. This is set to be the size of the ring, as this is a limit on
> + * the number of requests that can be inflight at any one time. 256 imposes
> + * an overhead of 11MB of mapped kernel space per interface.
> + */
> +#define BLKIF_MAX_PERS_REQUESTS_PER_DEV 256

This 11MB per VBD seems like a lot.  With 150 VMs each with 2 VBDs this
requires > 3 GB.  Is this a scalability problem?

Does there need to be a mechanism to expire old maps in blkback?

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 20 10:46:21 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Sep 2012 10:46:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TEeGh-0007uC-KL; Thu, 20 Sep 2012 10:46:03 +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 1TEeGg-0007u7-Bm
	for xen-devel@lists.xensource.com; Thu, 20 Sep 2012 10:46:02 +0000
Received: from [85.158.138.51:45151] by server-7.bemta-3.messagelabs.com id
	30/D4-32000-9E3FA505; Thu, 20 Sep 2012 10:46:01 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1348137959!12632655!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNjk5MTY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2800 invoked from network); 20 Sep 2012 10:46:00 -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;
	20 Sep 2012 10:46:00 -0000
X-IronPort-AV: E=Sophos;i="4.80,453,1344211200"; d="scan'208";a="38465895"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Sep 2012 10:45:59 +0000
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.279.1; Thu, 20 Sep 2012
	06:45:58 -0400
Message-ID: <505AF3E5.1050306@citrix.com>
Date: Thu, 20 Sep 2012 11:45:57 +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 Iceowl/1.0b1 Icedove/3.0.11
MIME-Version: 1.0
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
References: <1348076658-4511-1-git-send-email-stefano.stabellini@eu.citrix.com>
In-Reply-To: <1348076658-4511-1-git-send-email-stefano.stabellini@eu.citrix.com>
Cc: xen-devel@lists.xensource.com, Ian.Campbell@citrix.com,
	Pawel Moll <pawel.moll@arm.com>, konrad.wilk@oracle.com,
	linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org
Subject: Re: [Xen-devel] [PATCH] arm: introduce a DTS for Xen unprivileged
 virtual 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 19/09/12 18:44, Stefano Stabellini wrote:
> --- /dev/null
> +++ b/arch/arm/boot/dts/vexpress-xenvm-4.2.dts

Does this make sense?  There is no fixed configuration for VMs.

Is the intention to pass a DTS to the toolstack for it to create the VM
with the appropriate amount of memory and peripheral mapped to the right
place etc?  Or is the toolstack going to create the VM and generate the
DTB from (e.g.,) an xl VM configuration file.

> +
> +	hypervisor {
> +		compatible = "xen,xen-4.2", "xen,xen";
> +		reg = <0xb0000000 0x20000>;
> +		interrupts = <1 15 0xf08>;
> +	};

This node needs to be generated by the toolstack as only it knows what
ABI the hypervisor has.

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 20 10:46:21 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Sep 2012 10:46:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TEeGh-0007uC-KL; Thu, 20 Sep 2012 10:46:03 +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 1TEeGg-0007u7-Bm
	for xen-devel@lists.xensource.com; Thu, 20 Sep 2012 10:46:02 +0000
Received: from [85.158.138.51:45151] by server-7.bemta-3.messagelabs.com id
	30/D4-32000-9E3FA505; Thu, 20 Sep 2012 10:46:01 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1348137959!12632655!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNjk5MTY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2800 invoked from network); 20 Sep 2012 10:46:00 -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;
	20 Sep 2012 10:46:00 -0000
X-IronPort-AV: E=Sophos;i="4.80,453,1344211200"; d="scan'208";a="38465895"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Sep 2012 10:45:59 +0000
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.279.1; Thu, 20 Sep 2012
	06:45:58 -0400
Message-ID: <505AF3E5.1050306@citrix.com>
Date: Thu, 20 Sep 2012 11:45:57 +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 Iceowl/1.0b1 Icedove/3.0.11
MIME-Version: 1.0
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
References: <1348076658-4511-1-git-send-email-stefano.stabellini@eu.citrix.com>
In-Reply-To: <1348076658-4511-1-git-send-email-stefano.stabellini@eu.citrix.com>
Cc: xen-devel@lists.xensource.com, Ian.Campbell@citrix.com,
	Pawel Moll <pawel.moll@arm.com>, konrad.wilk@oracle.com,
	linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org
Subject: Re: [Xen-devel] [PATCH] arm: introduce a DTS for Xen unprivileged
 virtual 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 19/09/12 18:44, Stefano Stabellini wrote:
> --- /dev/null
> +++ b/arch/arm/boot/dts/vexpress-xenvm-4.2.dts

Does this make sense?  There is no fixed configuration for VMs.

Is the intention to pass a DTS to the toolstack for it to create the VM
with the appropriate amount of memory and peripheral mapped to the right
place etc?  Or is the toolstack going to create the VM and generate the
DTB from (e.g.,) an xl VM configuration file.

> +
> +	hypervisor {
> +		compatible = "xen,xen-4.2", "xen,xen";
> +		reg = <0xb0000000 0x20000>;
> +		interrupts = <1 15 0xf08>;
> +	};

This node needs to be generated by the toolstack as only it knows what
ABI the hypervisor has.

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 20 10:51:37 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Sep 2012 10: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 1TEeLn-00082s-CX; Thu, 20 Sep 2012 10:51:19 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <stefano.panella@citrix.com>) id 1TEeLl-00082m-2L
	for xen-devel@lists.xen.org; Thu, 20 Sep 2012 10:51:17 +0000
Received: from [85.158.143.35:19897] by server-3.bemta-4.messagelabs.com id
	8D/33-10986-425FA505; Thu, 20 Sep 2012 10:51:16 +0000
X-Env-Sender: stefano.panella@citrix.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1348138275!7365824!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTA0NTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4853 invoked from network); 20 Sep 2012 10:51:15 -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;
	20 Sep 2012 10:51:15 -0000
X-IronPort-AV: E=Sophos;i="4.80,453,1344211200"; d="scan'208";a="14652589"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Sep 2012 10:51: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.279.1; Thu, 20 Sep 2012 11:51:15 +0100
Received: from slimey.cam.xci-test.com ([10.80.249.177])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<stefano.panella@citrix.com>)	id 1TEeLi-0000qb-OM;
	Thu, 20 Sep 2012 10:51:14 +0000
Message-ID: <505AF532.6050406@citrix.com>
Date: Thu, 20 Sep 2012 11:51:30 +0100
From: Stefano Panella <stefano.panella@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:14.0) Gecko/20120714 Thunderbird/14.0
MIME-Version: 1.0
To: Jean Guyader <jean.guyader@gmail.com>
References: <CAFLBxZYtmJ_bKFb90r45=C4Pq1-oe5Fy=eygSsQf4BcGj3EqGA@mail.gmail.com>
	<CAEBdQ90Htx8xqtbmBdV+06nrCTtAmVV-tXqRpWomez-WP4TRtA@mail.gmail.com>
In-Reply-To: <CAEBdQ90Htx8xqtbmBdV+06nrCTtAmVV-tXqRpWomez-WP4TRtA@mail.gmail.com>
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.3 development 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-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 09/20/2012 10:53 AM, Jean Guyader wrote:
> On 19 September 2012 17:58, George Dunlap <George.Dunlap@eu.citrix.com> wrote:
>> = Timeline =
>>
>> We are planning on a 9-month release cycle.  Based on that, below are
>> our estimated dates:
>> * Feature Freeze: 1 March, 2013
>> * First RC: 15 April 2013
>> * Release: 1 June 2013
>>
>> The RCs and release will of course depend on stability and bugs, and
>> will therefore be fairly unpredictable.  The feature freeze may be
>> slipped for especially important features which are near completion.
>>
>> = Feature tracking =
>>
>> Below is a list of features we're tracking for this release.  Please
>> respond to this mail with any updates to the status.  If the status
>> is "?", as most of them are, please respond with the status!  Example
>> statuses include "not started", "in progress", "initial implementation
>> submitted for review", "patches submitted".
>>
>> There are a number of items whose owners are marked as "?".  If you
>> are working on this, or know who is working on it, please respond and
>> let me know.  Alternately, if you would *like* to work on it, please
>> let me know as well.
>>
>> And if there is something you're working on you'd like tracked, please
>> respond, and I will add it to the list.
>>
>>
>> * PVH mode, domU (w/ Linux)
>>    owner: mukesh@oracle
>>    status: ?
>>
>> * PVH mode, dom0 (w/ Linux)
>>    owner: mukesh@oracle
>>    status: ?
>>
>> * Event channel scalability
>>    owner: attilio@citrix
>>    status: ?
>>    Increase limit on event channels (currently 1024 for 32-bit guests,
>>    4096 for 64-bit guests)
>>
>> * ARM server port
>>    owner: ijc@citrix
>>    status: Core hypervisor patches accepted; Linux paches pending
>>
>> * NUMA scheduler affinity
>>    critical
>>    owner: dario@citrix
>>    status: ?
>>
>> * NUMA Memory migration
>>    owner: dario@citrix
>>    status: ?
>>
>> * blktap3
>>    owner: thanos@citrix
>>    status: ?
>>
>> * Default to QEMU upstream
>>   - qemu-based stubdom (Linux or BSD libc)
>>     owner: anthony@citrix
>>     status: ?
>>     qemu-upstream needs a more fully-featured libc than exists in
>>     minios.  Either work on a minimalist linux-based stubdom with
>>     glibc, or port one of the BSD libcs to minios.
>>
>>   - pci pass-thru
>>     owner: anthony@citrix
>>     status: ?
>>
>> * Persistent grants
>>    owner: @citrix
>>    status: ?
>>
>> * Multi-page blk rings
>>   - blkback in kernel (konrad@oracle, ?@intel)
>>   - qemu blkback
>>    status: ?
>>
>> * Multi-page net protocol
>>    owner: ?
>>    status: ?
>>    expand the network ring protocol to allow multiple pages for
>>    increased throughput
>>
>> * Scalability: 16TiB of RAM
>>    owner: jan@suse
>>    status: ?
>>
>> * libvirt integration
>>    owner: ?
>>    status: ?
>>    To begin with, we need someone to go and make some lists:
>>    - Features available in libvirt/KVM not available in libvirt/Xen
>>    - Features available in xl/Xen but not available in libvirt/Xen
>>
>> * xl vm-{export,import}
>>    owner: ?
>>    status: ?
>>    Allow xl to import and export VMs to other formats; particularly
>>    ovf, perhaps the XenServer format, or more.
>>
>>
>> * xl USB pass-through for PV guests
>>    owner: ?
>>    status: ?
>>    - Port the xend PV pass-through functionality to xl.
>>    - Make sure qemu-based USB with qemu-upstream works
>>    - Upstream the Linux frontend/backend drivers
>>
>> * openvswitch toostack integration
>>    owner: roger@citrix
>>    status: Sample script posted by Bastian ("[RFC] openvswitch support script")
>>
>> * Rationalized backend scripts (incl. driver domains)
>>    owner: roger@citrix
>>    status: ?
>>
>> * Linux console improvements
>>    owner: jan@suse
>>    -EHCI debug port (done, to be submitted)
>>    -xHCI debug port
>>    -Firewire
>>
>> * CPUID-based idle (don't rely on ACPI info f/ dom0)
>>    owner: jan@suse
>>    status: done, to be submitted
>>
>> * Remove hardcoded mobprobe's in xencommons
>>    owner: ?
>>    status: ?
>>
>> * Make storage migration possible
>>    owner: ?
>>    status: ?
>>    There needs to be a way, either via command-line or via some hooks,
>>    that someone can build a "storage migration" feature on top of libxl
>>    or xl.
>>
>> * Full-VM snapshotting
>>    owner: ?
>>    status: ?
>>    Have a way of coordinating the taking and restoring of VM memory and
>>    disk snapshots.  This would involve some investigation into the best
>>    way to accomplish this.
>>
>> * VM Cloning
>>    owner: ?
>>    status: May need review
>>    Again, a way of coordinating the memory and disk aspects.  Research
>>    into the best way to do this would probably go along with the
>>    snapshotting feature.
>>
>> * Memory: Replace PoD with paging mechanism
>>    owner: george@citrix
>>    status: May need review
>>
>> * PV audio (audio for stubdom qemu)
>>    owner: stefano.panella@citrix
>>    status: ?
>>
>> * Managed domains?
>>
> Hi George,
>
> Maybe we could had V4V in the list.
>
> * V4V: Inter-domain communication
>    owner (Xen): jean.guyader@citrix.com
>    status (Xen): patches submitte
>    owner (Linux driver):  stefano.panella@citrix
>    status (Linux driver): in progress
As Jean has mentioned, I agree to take ownership of the linux driver for 
v4v.
>
> Thanks,
> Jean
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Sep 20 10:51:37 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Sep 2012 10: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 1TEeLn-00082s-CX; Thu, 20 Sep 2012 10:51:19 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <stefano.panella@citrix.com>) id 1TEeLl-00082m-2L
	for xen-devel@lists.xen.org; Thu, 20 Sep 2012 10:51:17 +0000
Received: from [85.158.143.35:19897] by server-3.bemta-4.messagelabs.com id
	8D/33-10986-425FA505; Thu, 20 Sep 2012 10:51:16 +0000
X-Env-Sender: stefano.panella@citrix.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1348138275!7365824!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTA0NTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4853 invoked from network); 20 Sep 2012 10:51:15 -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;
	20 Sep 2012 10:51:15 -0000
X-IronPort-AV: E=Sophos;i="4.80,453,1344211200"; d="scan'208";a="14652589"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Sep 2012 10:51: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.279.1; Thu, 20 Sep 2012 11:51:15 +0100
Received: from slimey.cam.xci-test.com ([10.80.249.177])	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<stefano.panella@citrix.com>)	id 1TEeLi-0000qb-OM;
	Thu, 20 Sep 2012 10:51:14 +0000
Message-ID: <505AF532.6050406@citrix.com>
Date: Thu, 20 Sep 2012 11:51:30 +0100
From: Stefano Panella <stefano.panella@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:14.0) Gecko/20120714 Thunderbird/14.0
MIME-Version: 1.0
To: Jean Guyader <jean.guyader@gmail.com>
References: <CAFLBxZYtmJ_bKFb90r45=C4Pq1-oe5Fy=eygSsQf4BcGj3EqGA@mail.gmail.com>
	<CAEBdQ90Htx8xqtbmBdV+06nrCTtAmVV-tXqRpWomez-WP4TRtA@mail.gmail.com>
In-Reply-To: <CAEBdQ90Htx8xqtbmBdV+06nrCTtAmVV-tXqRpWomez-WP4TRtA@mail.gmail.com>
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.3 development 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-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 09/20/2012 10:53 AM, Jean Guyader wrote:
> On 19 September 2012 17:58, George Dunlap <George.Dunlap@eu.citrix.com> wrote:
>> = Timeline =
>>
>> We are planning on a 9-month release cycle.  Based on that, below are
>> our estimated dates:
>> * Feature Freeze: 1 March, 2013
>> * First RC: 15 April 2013
>> * Release: 1 June 2013
>>
>> The RCs and release will of course depend on stability and bugs, and
>> will therefore be fairly unpredictable.  The feature freeze may be
>> slipped for especially important features which are near completion.
>>
>> = Feature tracking =
>>
>> Below is a list of features we're tracking for this release.  Please
>> respond to this mail with any updates to the status.  If the status
>> is "?", as most of them are, please respond with the status!  Example
>> statuses include "not started", "in progress", "initial implementation
>> submitted for review", "patches submitted".
>>
>> There are a number of items whose owners are marked as "?".  If you
>> are working on this, or know who is working on it, please respond and
>> let me know.  Alternately, if you would *like* to work on it, please
>> let me know as well.
>>
>> And if there is something you're working on you'd like tracked, please
>> respond, and I will add it to the list.
>>
>>
>> * PVH mode, domU (w/ Linux)
>>    owner: mukesh@oracle
>>    status: ?
>>
>> * PVH mode, dom0 (w/ Linux)
>>    owner: mukesh@oracle
>>    status: ?
>>
>> * Event channel scalability
>>    owner: attilio@citrix
>>    status: ?
>>    Increase limit on event channels (currently 1024 for 32-bit guests,
>>    4096 for 64-bit guests)
>>
>> * ARM server port
>>    owner: ijc@citrix
>>    status: Core hypervisor patches accepted; Linux paches pending
>>
>> * NUMA scheduler affinity
>>    critical
>>    owner: dario@citrix
>>    status: ?
>>
>> * NUMA Memory migration
>>    owner: dario@citrix
>>    status: ?
>>
>> * blktap3
>>    owner: thanos@citrix
>>    status: ?
>>
>> * Default to QEMU upstream
>>   - qemu-based stubdom (Linux or BSD libc)
>>     owner: anthony@citrix
>>     status: ?
>>     qemu-upstream needs a more fully-featured libc than exists in
>>     minios.  Either work on a minimalist linux-based stubdom with
>>     glibc, or port one of the BSD libcs to minios.
>>
>>   - pci pass-thru
>>     owner: anthony@citrix
>>     status: ?
>>
>> * Persistent grants
>>    owner: @citrix
>>    status: ?
>>
>> * Multi-page blk rings
>>   - blkback in kernel (konrad@oracle, ?@intel)
>>   - qemu blkback
>>    status: ?
>>
>> * Multi-page net protocol
>>    owner: ?
>>    status: ?
>>    expand the network ring protocol to allow multiple pages for
>>    increased throughput
>>
>> * Scalability: 16TiB of RAM
>>    owner: jan@suse
>>    status: ?
>>
>> * libvirt integration
>>    owner: ?
>>    status: ?
>>    To begin with, we need someone to go and make some lists:
>>    - Features available in libvirt/KVM not available in libvirt/Xen
>>    - Features available in xl/Xen but not available in libvirt/Xen
>>
>> * xl vm-{export,import}
>>    owner: ?
>>    status: ?
>>    Allow xl to import and export VMs to other formats; particularly
>>    ovf, perhaps the XenServer format, or more.
>>
>>
>> * xl USB pass-through for PV guests
>>    owner: ?
>>    status: ?
>>    - Port the xend PV pass-through functionality to xl.
>>    - Make sure qemu-based USB with qemu-upstream works
>>    - Upstream the Linux frontend/backend drivers
>>
>> * openvswitch toostack integration
>>    owner: roger@citrix
>>    status: Sample script posted by Bastian ("[RFC] openvswitch support script")
>>
>> * Rationalized backend scripts (incl. driver domains)
>>    owner: roger@citrix
>>    status: ?
>>
>> * Linux console improvements
>>    owner: jan@suse
>>    -EHCI debug port (done, to be submitted)
>>    -xHCI debug port
>>    -Firewire
>>
>> * CPUID-based idle (don't rely on ACPI info f/ dom0)
>>    owner: jan@suse
>>    status: done, to be submitted
>>
>> * Remove hardcoded mobprobe's in xencommons
>>    owner: ?
>>    status: ?
>>
>> * Make storage migration possible
>>    owner: ?
>>    status: ?
>>    There needs to be a way, either via command-line or via some hooks,
>>    that someone can build a "storage migration" feature on top of libxl
>>    or xl.
>>
>> * Full-VM snapshotting
>>    owner: ?
>>    status: ?
>>    Have a way of coordinating the taking and restoring of VM memory and
>>    disk snapshots.  This would involve some investigation into the best
>>    way to accomplish this.
>>
>> * VM Cloning
>>    owner: ?
>>    status: May need review
>>    Again, a way of coordinating the memory and disk aspects.  Research
>>    into the best way to do this would probably go along with the
>>    snapshotting feature.
>>
>> * Memory: Replace PoD with paging mechanism
>>    owner: george@citrix
>>    status: May need review
>>
>> * PV audio (audio for stubdom qemu)
>>    owner: stefano.panella@citrix
>>    status: ?
>>
>> * Managed domains?
>>
> Hi George,
>
> Maybe we could had V4V in the list.
>
> * V4V: Inter-domain communication
>    owner (Xen): jean.guyader@citrix.com
>    status (Xen): patches submitte
>    owner (Linux driver):  stefano.panella@citrix
>    status (Linux driver): in progress
As Jean has mentioned, I agree to take ownership of the linux driver for 
v4v.
>
> Thanks,
> Jean
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Sep 20 10:57:51 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Sep 2012 10:57: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 1TEeRq-0008DA-AZ; Thu, 20 Sep 2012 10:57:34 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony.perard@gmail.com>) id 1TEeRp-0008D5-BH
	for xen-devel@lists.xen.org; Thu, 20 Sep 2012 10:57:33 +0000
Received: from [85.158.139.83:31497] by server-3.bemta-5.messagelabs.com id
	26/1D-21836-C96FA505; Thu, 20 Sep 2012 10:57:32 +0000
X-Env-Sender: anthony.perard@gmail.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1348138650!26833364!1
X-Originating-IP: [209.85.214.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31859 invoked from network); 20 Sep 2012 10:57:31 -0000
Received: from mail-ob0-f173.google.com (HELO mail-ob0-f173.google.com)
	(209.85.214.173)
	by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Sep 2012 10:57:31 -0000
Received: by obbta14 with SMTP id ta14so2540555obb.32
	for <xen-devel@lists.xen.org>; Thu, 20 Sep 2012 03:57:30 -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=g+0m9QSfP1T0/itL+8mcpylix1dxtYm55Gqy8Egrqqc=;
	b=OHGv6uuqS8VMjnJp9AT13vEMDFyGaAMzVM59qNXTC8IupqYo3BzndbtF2UB4w0fIOw
	hC+4q6vexgROD8Lf0LKfWHcyn8sLgm5wrfwGcuUxeLIkvxF8hswki70f6N+7b2q5cDRy
	VO4moz8VIjz0NTCOS9fKphlqnKtTgcRVUOV1a8XhMmQVM8PWol1/+yK56mZOd9ottG4m
	WALkaO44zmfvKsCZCNi3P4PUqTxfayOtGlHjYnLBkspmsRdXUVcCmMiuO0VErx8DMQIs
	4YnFbalVCGHP9NtelofPvt6+6Udeq/j9fQAHI77A2r7WmNSaWR/Pe2Jjx6oyKoJybXp8
	0Liw==
Received: by 10.182.43.40 with SMTP id t8mr974967obl.93.1348138650123; Thu, 20
	Sep 2012 03:57:30 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.60.9.33 with HTTP; Thu, 20 Sep 2012 03:56:59 -0700 (PDT)
In-Reply-To: <A9667DDFB95DB7438FA9D7D576C3D87E25F85A@SHSMSX101.ccr.corp.intel.com>
References: <A9667DDFB95DB7438FA9D7D576C3D87E203D54@SHSMSX101.ccr.corp.intel.com>
	<alpine.DEB.2.02.1208031122170.4645@kaball.uk.xensource.com>
	<1343990187.21372.48.camel@zakaz.uk.xensource.com>
	<40352EBA8B4DF841A9907B883F22B59B0FDBCE1E@SHSMSX102.ccr.corp.intel.com>
	<40352EBA8B4DF841A9907B883F22B59B0FDD25C7@SHSMSX102.ccr.corp.intel.com>
	<A9667DDFB95DB7438FA9D7D576C3D87E258EF6@SHSMSX101.ccr.corp.intel.com>
	<505851CF.2090000@citrix.com>
	<A9667DDFB95DB7438FA9D7D576C3D87E25BB14@SHSMSX101.ccr.corp.intel.com>
	<CAJJyHjLH38r-r+cTmPprMj4trU8eZpQrfp4ypBzdsmZHSL9BMw@mail.gmail.com>
	<A9667DDFB95DB7438FA9D7D576C3D87E25F85A@SHSMSX101.ccr.corp.intel.com>
From: Anthony PERARD <anthony.perard@citrix.com>
Date: Thu, 20 Sep 2012 11:56:59 +0100
X-Google-Sender-Auth: sRhgGf22xRD2IX9-zWKQjqNzHMo
Message-ID: <CAJJyHjKGy78596x+dP9kfyCzOcgKu1JywYo9q7urm1fLR0M32w@mail.gmail.com>
To: "Zhang, Yang Z" <yang.z.zhang@intel.com>
Cc: "Zhou, Chao" <chao.zhou@intel.com>, xen-devel <xen-devel@lists.xen.org>,
	"Shan, Haitao" <haitao.shan@intel.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] error when pass through device to guest with
	qemu-xen-dir-remote
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Sep 20, 2012 at 12:30 AM, Zhang, Yang Z <yang.z.zhang@intel.com> wrote:
>>> In old qemu, we will free the invalid NIC through this function. And it will fail w/
>> your change. Shouldn't we follow the old logic?
>>
>> I don't understand. Are you arguing this patch or the function it self?
>>
>> My change is fine and follow the old logic: do not do anything for a
>> passthrough device.
> No. Old logic will unplug the passthrough device which mask as invalid. And this patch just ignores all passthrough device.

I probably miss something in qemu-traditional then.

Anyway ...

> I wonder whether this change will impact other part? If not, it should be ok.

This should not have any impact on any other part of QEMU.

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 Thu Sep 20 10:57:51 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Sep 2012 10:57: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 1TEeRq-0008DA-AZ; Thu, 20 Sep 2012 10:57:34 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony.perard@gmail.com>) id 1TEeRp-0008D5-BH
	for xen-devel@lists.xen.org; Thu, 20 Sep 2012 10:57:33 +0000
Received: from [85.158.139.83:31497] by server-3.bemta-5.messagelabs.com id
	26/1D-21836-C96FA505; Thu, 20 Sep 2012 10:57:32 +0000
X-Env-Sender: anthony.perard@gmail.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1348138650!26833364!1
X-Originating-IP: [209.85.214.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31859 invoked from network); 20 Sep 2012 10:57:31 -0000
Received: from mail-ob0-f173.google.com (HELO mail-ob0-f173.google.com)
	(209.85.214.173)
	by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Sep 2012 10:57:31 -0000
Received: by obbta14 with SMTP id ta14so2540555obb.32
	for <xen-devel@lists.xen.org>; Thu, 20 Sep 2012 03:57:30 -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=g+0m9QSfP1T0/itL+8mcpylix1dxtYm55Gqy8Egrqqc=;
	b=OHGv6uuqS8VMjnJp9AT13vEMDFyGaAMzVM59qNXTC8IupqYo3BzndbtF2UB4w0fIOw
	hC+4q6vexgROD8Lf0LKfWHcyn8sLgm5wrfwGcuUxeLIkvxF8hswki70f6N+7b2q5cDRy
	VO4moz8VIjz0NTCOS9fKphlqnKtTgcRVUOV1a8XhMmQVM8PWol1/+yK56mZOd9ottG4m
	WALkaO44zmfvKsCZCNi3P4PUqTxfayOtGlHjYnLBkspmsRdXUVcCmMiuO0VErx8DMQIs
	4YnFbalVCGHP9NtelofPvt6+6Udeq/j9fQAHI77A2r7WmNSaWR/Pe2Jjx6oyKoJybXp8
	0Liw==
Received: by 10.182.43.40 with SMTP id t8mr974967obl.93.1348138650123; Thu, 20
	Sep 2012 03:57:30 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.60.9.33 with HTTP; Thu, 20 Sep 2012 03:56:59 -0700 (PDT)
In-Reply-To: <A9667DDFB95DB7438FA9D7D576C3D87E25F85A@SHSMSX101.ccr.corp.intel.com>
References: <A9667DDFB95DB7438FA9D7D576C3D87E203D54@SHSMSX101.ccr.corp.intel.com>
	<alpine.DEB.2.02.1208031122170.4645@kaball.uk.xensource.com>
	<1343990187.21372.48.camel@zakaz.uk.xensource.com>
	<40352EBA8B4DF841A9907B883F22B59B0FDBCE1E@SHSMSX102.ccr.corp.intel.com>
	<40352EBA8B4DF841A9907B883F22B59B0FDD25C7@SHSMSX102.ccr.corp.intel.com>
	<A9667DDFB95DB7438FA9D7D576C3D87E258EF6@SHSMSX101.ccr.corp.intel.com>
	<505851CF.2090000@citrix.com>
	<A9667DDFB95DB7438FA9D7D576C3D87E25BB14@SHSMSX101.ccr.corp.intel.com>
	<CAJJyHjLH38r-r+cTmPprMj4trU8eZpQrfp4ypBzdsmZHSL9BMw@mail.gmail.com>
	<A9667DDFB95DB7438FA9D7D576C3D87E25F85A@SHSMSX101.ccr.corp.intel.com>
From: Anthony PERARD <anthony.perard@citrix.com>
Date: Thu, 20 Sep 2012 11:56:59 +0100
X-Google-Sender-Auth: sRhgGf22xRD2IX9-zWKQjqNzHMo
Message-ID: <CAJJyHjKGy78596x+dP9kfyCzOcgKu1JywYo9q7urm1fLR0M32w@mail.gmail.com>
To: "Zhang, Yang Z" <yang.z.zhang@intel.com>
Cc: "Zhou, Chao" <chao.zhou@intel.com>, xen-devel <xen-devel@lists.xen.org>,
	"Shan, Haitao" <haitao.shan@intel.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] error when pass through device to guest with
	qemu-xen-dir-remote
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Sep 20, 2012 at 12:30 AM, Zhang, Yang Z <yang.z.zhang@intel.com> wrote:
>>> In old qemu, we will free the invalid NIC through this function. And it will fail w/
>> your change. Shouldn't we follow the old logic?
>>
>> I don't understand. Are you arguing this patch or the function it self?
>>
>> My change is fine and follow the old logic: do not do anything for a
>> passthrough device.
> No. Old logic will unplug the passthrough device which mask as invalid. And this patch just ignores all passthrough device.

I probably miss something in qemu-traditional then.

Anyway ...

> I wonder whether this change will impact other part? If not, it should be ok.

This should not have any impact on any other part of QEMU.

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 Thu Sep 20 11:12:35 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Sep 2012 11: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 1TEeg2-0008Sr-OM; Thu, 20 Sep 2012 11:12: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 1TEeg1-0008Sm-4K
	for xen-devel@lists.xen.org; Thu, 20 Sep 2012 11:12:13 +0000
Received: from [85.158.143.35:26489] by server-2.bemta-4.messagelabs.com id
	77/09-06610-C0AFA505; Thu, 20 Sep 2012 11:12:12 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1348139529!19114083!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11087 invoked from network); 20 Sep 2012 11:12:10 -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;
	20 Sep 2012 11:12:10 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 20 Sep 2012 12:12:10 +0100
Message-Id: <505B163E020000780009C9C3@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 20 Sep 2012 12:12:30 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Jean Guyader" <jean.guyader@gmail.com>
References: <1348134426-25320-1-git-send-email-jean.guyader@citrix.com>
	<505B0A97020000780009C986@nat28.tlf.novell.com>
	<CAEBdQ91yr0jW+sNgidzdYUjU8=CUZWwsRJ0oXHAriMbSbo2JzQ@mail.gmail.com>
In-Reply-To: <CAEBdQ91yr0jW+sNgidzdYUjU8=CUZWwsRJ0oXHAriMbSbo2JzQ@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: tim@xen.org, Jean Guyader <jean.guyader@citrix.com>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 0/4] Add V4V to Xen v5
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.09.12 at 12:27, Jean Guyader <jean.guyader@gmail.com> wrote:
> On 20 September 2012 11:22, Jan Beulich <JBeulich@suse.com> wrote:
>>>>> On 20.09.12 at 11:47, Jean Guyader <jean.guyader@citrix.com> wrote:
>>> v5 changes:
>>>         - Fix prototypes in v4v.h for do_v4v_op
>>>         - Add padding to make sure all the structures
>>>           are 64 bits aligned
>>>         - Replace [0] with []
>>
>> But that isn't standard C either (before C99 at least).
>>
> 
> I found that in xen/public/physdev.h
> 
> struct physdev_pci_device_add {
>     /* IN */
>     uint16_t seg;
>     uint8_t bus;
>     uint8_t devfn;
>     uint32_t flags;
>     struct {
>         uint8_t bus;
>         uint8_t devfn;
>     } physfn;
> #if defined(__STDC_VERSION__) && __STDC_VERSION__ >= 199901L
>     uint32_t optarr[];
> #elif defined(__GNUC__)
>     uint32_t optarr[0];
> #endif
> };
> 
> Would something similar be ok?

Yes, obviously.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 20 11:12:35 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Sep 2012 11: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 1TEeg2-0008Sr-OM; Thu, 20 Sep 2012 11:12: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 1TEeg1-0008Sm-4K
	for xen-devel@lists.xen.org; Thu, 20 Sep 2012 11:12:13 +0000
Received: from [85.158.143.35:26489] by server-2.bemta-4.messagelabs.com id
	77/09-06610-C0AFA505; Thu, 20 Sep 2012 11:12:12 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1348139529!19114083!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11087 invoked from network); 20 Sep 2012 11:12:10 -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;
	20 Sep 2012 11:12:10 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 20 Sep 2012 12:12:10 +0100
Message-Id: <505B163E020000780009C9C3@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 20 Sep 2012 12:12:30 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Jean Guyader" <jean.guyader@gmail.com>
References: <1348134426-25320-1-git-send-email-jean.guyader@citrix.com>
	<505B0A97020000780009C986@nat28.tlf.novell.com>
	<CAEBdQ91yr0jW+sNgidzdYUjU8=CUZWwsRJ0oXHAriMbSbo2JzQ@mail.gmail.com>
In-Reply-To: <CAEBdQ91yr0jW+sNgidzdYUjU8=CUZWwsRJ0oXHAriMbSbo2JzQ@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: tim@xen.org, Jean Guyader <jean.guyader@citrix.com>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 0/4] Add V4V to Xen v5
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.09.12 at 12:27, Jean Guyader <jean.guyader@gmail.com> wrote:
> On 20 September 2012 11:22, Jan Beulich <JBeulich@suse.com> wrote:
>>>>> On 20.09.12 at 11:47, Jean Guyader <jean.guyader@citrix.com> wrote:
>>> v5 changes:
>>>         - Fix prototypes in v4v.h for do_v4v_op
>>>         - Add padding to make sure all the structures
>>>           are 64 bits aligned
>>>         - Replace [0] with []
>>
>> But that isn't standard C either (before C99 at least).
>>
> 
> I found that in xen/public/physdev.h
> 
> struct physdev_pci_device_add {
>     /* IN */
>     uint16_t seg;
>     uint8_t bus;
>     uint8_t devfn;
>     uint32_t flags;
>     struct {
>         uint8_t bus;
>         uint8_t devfn;
>     } physfn;
> #if defined(__STDC_VERSION__) && __STDC_VERSION__ >= 199901L
>     uint32_t optarr[];
> #elif defined(__GNUC__)
>     uint32_t optarr[0];
> #endif
> };
> 
> Would something similar be ok?

Yes, obviously.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 20 11:14:07 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Sep 2012 11:14:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TEehg-00007p-En; Thu, 20 Sep 2012 11:13: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 1TEehf-00005o-77
	for xen-devel@lists.xen.org; Thu, 20 Sep 2012 11:13:55 +0000
Received: from [85.158.143.99:62640] by server-1.bemta-4.messagelabs.com id
	D5/6A-05684-27AFA505; Thu, 20 Sep 2012 11:13:54 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1348139627!24688639!5
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNzYxMzI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2989 invoked from network); 20 Sep 2012 11:13:53 -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;
	20 Sep 2012 11:13:53 -0000
X-IronPort-AV: E=Sophos;i="4.80,453,1344211200"; d="scan'208";a="208668338"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Sep 2012 11:13:28 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Thu, 20 Sep 2012 07:13:28 -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 1TEehE-0006Xi-9d;
	Thu, 20 Sep 2012 12:13:28 +0100
From: Anthony PERARD <anthony.perard@citrix.com>
To: QEMU-devel <qemu-devel@nongnu.org>
Date: Thu, 20 Sep 2012 12:12:50 +0100
Message-ID: <1348139574-23324-2-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.12
In-Reply-To: <1348139574-23324-1-git-send-email-anthony.perard@citrix.com>
References: <1348139574-23324-1-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Cc: Anthony Liguori <aliguori@us.ibm.com>,
	Luiz Capitulino <lcapitulino@redhat.com>,
	Stefano Stabellini <stefano.stabellini@citrix.com>,
	Avi Kivity <avi@redhat.com>, Anthony PERARD <anthony.perard@citrix.com>,
	Xen Devel <xen-devel@lists.xen.org>
Subject: [Xen-devel] [PATCH V3 1/5] QMP,
	Introduce xen-set-global-dirty-log command.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This command is used during a migration of a guest under Xen. It calls
memory_global_dirty_log_start or memory_global_dirty_log_stop according to the
argument pass to the command.

Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Reviewed-by: Luiz Capitulino <lcapitulino@redhat.com>
---
 qapi-schema.json | 13 +++++++++++++
 qmp-commands.hx  | 24 ++++++++++++++++++++++++
 xen-all.c        | 15 +++++++++++++++
 xen-stub.c       |  5 +++++
 4 files changed, 57 insertions(+)

diff --git a/qapi-schema.json b/qapi-schema.json
index 14e4419..696f45a 100644
--- a/qapi-schema.json
+++ b/qapi-schema.json
@@ -1956,6 +1956,19 @@
 { 'command': 'xen-save-devices-state', 'data': {'filename': 'str'} }
 
 ##
+# @xen-set-global-dirty-log
+#
+# Enable or disable the global dirty log mode.
+#
+# @enable: true to enable, false to disable.
+#
+# Returns: nothing
+#
+# Since: 1.2
+##
+{ 'command': 'xen-set-global-dirty-log', 'data': { 'enable': 'bool' } }
+
+##
 # @device_del:
 #
 # Remove a device from a guest
diff --git a/qmp-commands.hx b/qmp-commands.hx
index 6e21ddb..662b7cf 100644
--- a/qmp-commands.hx
+++ b/qmp-commands.hx
@@ -493,6 +493,30 @@ Example:
 EQMP
 
     {
+        .name       = "xen-set-global-dirty-log",
+        .args_type  = "enable:b",
+        .mhandler.cmd_new = qmp_marshal_input_xen_set_global_dirty_log,
+    },
+
+SQMP
+xen-set-global-dirty-log
+-------
+
+Enable or disable the global dirty log mode.
+
+Arguments:
+
+- "enable": Enable it or disable it.
+
+Example:
+
+-> { "execute": "xen-set-global-dirty-log",
+     "arguments": { "enable": true } }
+<- { "return": {} }
+
+EQMP
+
+    {
         .name       = "migrate",
         .args_type  = "detach:-d,blk:-b,inc:-i,uri:s",
         .mhandler.cmd_new = qmp_marshal_input_migrate,
diff --git a/xen-all.c b/xen-all.c
index f76b051..f75ae9f 100644
--- a/xen-all.c
+++ b/xen-all.c
@@ -14,6 +14,7 @@
 #include "hw/pc.h"
 #include "hw/xen_common.h"
 #include "hw/xen_backend.h"
+#include "qmp-commands.h"
 
 #include "range.h"
 #include "xen-mapcache.h"
@@ -36,6 +37,7 @@
 
 static MemoryRegion ram_memory, ram_640k, ram_lo, ram_hi;
 static MemoryRegion *framebuffer;
+static bool xen_in_migration;
 
 /* Compatibility with older version */
 #if __XEN_LATEST_INTERFACE_VERSION__ < 0x0003020a
@@ -552,10 +554,14 @@ static void xen_log_sync(MemoryListener *listener, MemoryRegionSection *section)
 
 static void xen_log_global_start(MemoryListener *listener)
 {
+    if (xen_enabled()) {
+        xen_in_migration = true;
+    }
 }
 
 static void xen_log_global_stop(MemoryListener *listener)
 {
+    xen_in_migration = false;
 }
 
 static void xen_eventfd_add(MemoryListener *listener,
@@ -588,6 +594,15 @@ static MemoryListener xen_memory_listener = {
     .priority = 10,
 };
 
+void qmp_xen_set_global_dirty_log(bool enable, Error **errp)
+{
+    if (enable) {
+        memory_global_dirty_log_start();
+    } else {
+        memory_global_dirty_log_stop();
+    }
+}
+
 /* VCPU Operations, MMIO, IO ring ... */
 
 static void xen_reset_vcpu(void *opaque)
diff --git a/xen-stub.c b/xen-stub.c
index 8ff2b79..5e66ba8 100644
--- a/xen-stub.c
+++ b/xen-stub.c
@@ -11,6 +11,7 @@
 #include "qemu-common.h"
 #include "hw/xen.h"
 #include "memory.h"
+#include "qmp-commands.h"
 
 void xenstore_store_pv_console_info(int i, CharDriverState *chr)
 {
@@ -54,3 +55,7 @@ int xen_init(void)
 void xen_register_framebuffer(MemoryRegion *mr)
 {
 }
+
+void qmp_xen_set_global_dirty_log(bool enable, Error **errp)
+{
+}
-- 
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 Sep 20 11:14:07 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Sep 2012 11:14:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TEehg-00007p-En; Thu, 20 Sep 2012 11:13: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 1TEehf-00005o-77
	for xen-devel@lists.xen.org; Thu, 20 Sep 2012 11:13:55 +0000
Received: from [85.158.143.99:62640] by server-1.bemta-4.messagelabs.com id
	D5/6A-05684-27AFA505; Thu, 20 Sep 2012 11:13:54 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1348139627!24688639!5
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNzYxMzI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2989 invoked from network); 20 Sep 2012 11:13:53 -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;
	20 Sep 2012 11:13:53 -0000
X-IronPort-AV: E=Sophos;i="4.80,453,1344211200"; d="scan'208";a="208668338"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Sep 2012 11:13:28 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Thu, 20 Sep 2012 07:13:28 -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 1TEehE-0006Xi-9d;
	Thu, 20 Sep 2012 12:13:28 +0100
From: Anthony PERARD <anthony.perard@citrix.com>
To: QEMU-devel <qemu-devel@nongnu.org>
Date: Thu, 20 Sep 2012 12:12:50 +0100
Message-ID: <1348139574-23324-2-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.12
In-Reply-To: <1348139574-23324-1-git-send-email-anthony.perard@citrix.com>
References: <1348139574-23324-1-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Cc: Anthony Liguori <aliguori@us.ibm.com>,
	Luiz Capitulino <lcapitulino@redhat.com>,
	Stefano Stabellini <stefano.stabellini@citrix.com>,
	Avi Kivity <avi@redhat.com>, Anthony PERARD <anthony.perard@citrix.com>,
	Xen Devel <xen-devel@lists.xen.org>
Subject: [Xen-devel] [PATCH V3 1/5] QMP,
	Introduce xen-set-global-dirty-log command.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This command is used during a migration of a guest under Xen. It calls
memory_global_dirty_log_start or memory_global_dirty_log_stop according to the
argument pass to the command.

Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Reviewed-by: Luiz Capitulino <lcapitulino@redhat.com>
---
 qapi-schema.json | 13 +++++++++++++
 qmp-commands.hx  | 24 ++++++++++++++++++++++++
 xen-all.c        | 15 +++++++++++++++
 xen-stub.c       |  5 +++++
 4 files changed, 57 insertions(+)

diff --git a/qapi-schema.json b/qapi-schema.json
index 14e4419..696f45a 100644
--- a/qapi-schema.json
+++ b/qapi-schema.json
@@ -1956,6 +1956,19 @@
 { 'command': 'xen-save-devices-state', 'data': {'filename': 'str'} }
 
 ##
+# @xen-set-global-dirty-log
+#
+# Enable or disable the global dirty log mode.
+#
+# @enable: true to enable, false to disable.
+#
+# Returns: nothing
+#
+# Since: 1.2
+##
+{ 'command': 'xen-set-global-dirty-log', 'data': { 'enable': 'bool' } }
+
+##
 # @device_del:
 #
 # Remove a device from a guest
diff --git a/qmp-commands.hx b/qmp-commands.hx
index 6e21ddb..662b7cf 100644
--- a/qmp-commands.hx
+++ b/qmp-commands.hx
@@ -493,6 +493,30 @@ Example:
 EQMP
 
     {
+        .name       = "xen-set-global-dirty-log",
+        .args_type  = "enable:b",
+        .mhandler.cmd_new = qmp_marshal_input_xen_set_global_dirty_log,
+    },
+
+SQMP
+xen-set-global-dirty-log
+-------
+
+Enable or disable the global dirty log mode.
+
+Arguments:
+
+- "enable": Enable it or disable it.
+
+Example:
+
+-> { "execute": "xen-set-global-dirty-log",
+     "arguments": { "enable": true } }
+<- { "return": {} }
+
+EQMP
+
+    {
         .name       = "migrate",
         .args_type  = "detach:-d,blk:-b,inc:-i,uri:s",
         .mhandler.cmd_new = qmp_marshal_input_migrate,
diff --git a/xen-all.c b/xen-all.c
index f76b051..f75ae9f 100644
--- a/xen-all.c
+++ b/xen-all.c
@@ -14,6 +14,7 @@
 #include "hw/pc.h"
 #include "hw/xen_common.h"
 #include "hw/xen_backend.h"
+#include "qmp-commands.h"
 
 #include "range.h"
 #include "xen-mapcache.h"
@@ -36,6 +37,7 @@
 
 static MemoryRegion ram_memory, ram_640k, ram_lo, ram_hi;
 static MemoryRegion *framebuffer;
+static bool xen_in_migration;
 
 /* Compatibility with older version */
 #if __XEN_LATEST_INTERFACE_VERSION__ < 0x0003020a
@@ -552,10 +554,14 @@ static void xen_log_sync(MemoryListener *listener, MemoryRegionSection *section)
 
 static void xen_log_global_start(MemoryListener *listener)
 {
+    if (xen_enabled()) {
+        xen_in_migration = true;
+    }
 }
 
 static void xen_log_global_stop(MemoryListener *listener)
 {
+    xen_in_migration = false;
 }
 
 static void xen_eventfd_add(MemoryListener *listener,
@@ -588,6 +594,15 @@ static MemoryListener xen_memory_listener = {
     .priority = 10,
 };
 
+void qmp_xen_set_global_dirty_log(bool enable, Error **errp)
+{
+    if (enable) {
+        memory_global_dirty_log_start();
+    } else {
+        memory_global_dirty_log_stop();
+    }
+}
+
 /* VCPU Operations, MMIO, IO ring ... */
 
 static void xen_reset_vcpu(void *opaque)
diff --git a/xen-stub.c b/xen-stub.c
index 8ff2b79..5e66ba8 100644
--- a/xen-stub.c
+++ b/xen-stub.c
@@ -11,6 +11,7 @@
 #include "qemu-common.h"
 #include "hw/xen.h"
 #include "memory.h"
+#include "qmp-commands.h"
 
 void xenstore_store_pv_console_info(int i, CharDriverState *chr)
 {
@@ -54,3 +55,7 @@ int xen_init(void)
 void xen_register_framebuffer(MemoryRegion *mr)
 {
 }
+
+void qmp_xen_set_global_dirty_log(bool enable, Error **errp)
+{
+}
-- 
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 Sep 20 11:14:07 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Sep 2012 11:14:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TEehc-00006D-Jq; Thu, 20 Sep 2012 11:13: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 1TEehb-00005u-SW
	for xen-devel@lists.xen.org; Thu, 20 Sep 2012 11:13:52 +0000
Received: from [85.158.143.99:48096] by server-2.bemta-4.messagelabs.com id
	2E/5B-06610-F6AFA505; Thu, 20 Sep 2012 11:13:51 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1348139627!24688639!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNzYxMzI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2870 invoked from network); 20 Sep 2012 11:13:50 -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;
	20 Sep 2012 11:13:50 -0000
X-IronPort-AV: E=Sophos;i="4.80,453,1344211200"; d="scan'208";a="208668337"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Sep 2012 11:13:28 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Thu, 20 Sep 2012 07:13:28 -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 1TEehE-0006Xi-A1;
	Thu, 20 Sep 2012 12:13:28 +0100
From: Anthony PERARD <anthony.perard@citrix.com>
To: QEMU-devel <qemu-devel@nongnu.org>
Date: Thu, 20 Sep 2012 12:12:51 +0100
Message-ID: <1348139574-23324-3-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.12
In-Reply-To: <1348139574-23324-1-git-send-email-anthony.perard@citrix.com>
References: <1348139574-23324-1-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Cc: Anthony Liguori <aliguori@us.ibm.com>,
	Luiz Capitulino <lcapitulino@redhat.com>,
	Stefano Stabellini <stefano.stabellini@citrix.com>,
	Avi Kivity <avi@redhat.com>, Anthony PERARD <anthony.perard@citrix.com>,
	Xen Devel <xen-devel@lists.xen.org>
Subject: [Xen-devel] [PATCH V3 2/5] xen: Introduce xen_modified_memory.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This function is to be used during live migration. Every write access to the
guest memory should call this funcion so the Xen tools knows which pages are
dirty.

Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
 hw/xen.h   |  1 +
 xen-all.c  | 21 +++++++++++++++++++++
 xen-stub.c |  4 ++++
 3 files changed, 26 insertions(+)

diff --git a/hw/xen.h b/hw/xen.h
index e5926b7..d14e92d 100644
--- a/hw/xen.h
+++ b/hw/xen.h
@@ -48,6 +48,7 @@ void xenstore_store_pv_console_info(int i, struct CharDriverState *chr);
 struct MemoryRegion;
 void xen_ram_alloc(ram_addr_t ram_addr, ram_addr_t size,
                    struct MemoryRegion *mr);
+void xen_modified_memory(ram_addr_t start, ram_addr_t length);
 #endif
 
 struct MemoryRegion;
diff --git a/xen-all.c b/xen-all.c
index f75ae9f..6250593 100644
--- a/xen-all.c
+++ b/xen-all.c
@@ -1228,3 +1228,24 @@ void xen_shutdown_fatal_error(const char *fmt, ...)
     /* destroy the domain */
     qemu_system_shutdown_request();
 }
+
+void xen_modified_memory(ram_addr_t start, ram_addr_t length)
+{
+    if (unlikely(xen_in_migration)) {
+        int rc;
+        ram_addr_t start_pfn, nb_pages;
+
+        if (length == 0) {
+            length = TARGET_PAGE_SIZE;
+        }
+        start_pfn = start >> TARGET_PAGE_BITS;
+        nb_pages = ((start + length + TARGET_PAGE_SIZE - 1) >> TARGET_PAGE_BITS)
+            - start_pfn;
+        rc = xc_hvm_modified_memory(xen_xc, xen_domid, start_pfn, nb_pages);
+        if (rc) {
+            fprintf(stderr, "%s failed for "RAM_ADDR_FMT" ("RAM_ADDR_FMT
+                    "): %i, %s\n", __func__,
+                    start, nb_pages, rc, strerror(-rc));
+        }
+    }
+}
diff --git a/xen-stub.c b/xen-stub.c
index 5e66ba8..9214392 100644
--- a/xen-stub.c
+++ b/xen-stub.c
@@ -59,3 +59,7 @@ void xen_register_framebuffer(MemoryRegion *mr)
 void qmp_xen_set_global_dirty_log(bool enable, Error **errp)
 {
 }
+
+void xen_modified_memory(ram_addr_t start, ram_addr_t length)
+{
+}
-- 
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 Sep 20 11:14:07 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Sep 2012 11:14:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TEehc-00006D-Jq; Thu, 20 Sep 2012 11:13: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 1TEehb-00005u-SW
	for xen-devel@lists.xen.org; Thu, 20 Sep 2012 11:13:52 +0000
Received: from [85.158.143.99:48096] by server-2.bemta-4.messagelabs.com id
	2E/5B-06610-F6AFA505; Thu, 20 Sep 2012 11:13:51 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1348139627!24688639!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNzYxMzI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2870 invoked from network); 20 Sep 2012 11:13:50 -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;
	20 Sep 2012 11:13:50 -0000
X-IronPort-AV: E=Sophos;i="4.80,453,1344211200"; d="scan'208";a="208668337"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Sep 2012 11:13:28 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Thu, 20 Sep 2012 07:13:28 -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 1TEehE-0006Xi-A1;
	Thu, 20 Sep 2012 12:13:28 +0100
From: Anthony PERARD <anthony.perard@citrix.com>
To: QEMU-devel <qemu-devel@nongnu.org>
Date: Thu, 20 Sep 2012 12:12:51 +0100
Message-ID: <1348139574-23324-3-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.12
In-Reply-To: <1348139574-23324-1-git-send-email-anthony.perard@citrix.com>
References: <1348139574-23324-1-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Cc: Anthony Liguori <aliguori@us.ibm.com>,
	Luiz Capitulino <lcapitulino@redhat.com>,
	Stefano Stabellini <stefano.stabellini@citrix.com>,
	Avi Kivity <avi@redhat.com>, Anthony PERARD <anthony.perard@citrix.com>,
	Xen Devel <xen-devel@lists.xen.org>
Subject: [Xen-devel] [PATCH V3 2/5] xen: Introduce xen_modified_memory.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This function is to be used during live migration. Every write access to the
guest memory should call this funcion so the Xen tools knows which pages are
dirty.

Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
 hw/xen.h   |  1 +
 xen-all.c  | 21 +++++++++++++++++++++
 xen-stub.c |  4 ++++
 3 files changed, 26 insertions(+)

diff --git a/hw/xen.h b/hw/xen.h
index e5926b7..d14e92d 100644
--- a/hw/xen.h
+++ b/hw/xen.h
@@ -48,6 +48,7 @@ void xenstore_store_pv_console_info(int i, struct CharDriverState *chr);
 struct MemoryRegion;
 void xen_ram_alloc(ram_addr_t ram_addr, ram_addr_t size,
                    struct MemoryRegion *mr);
+void xen_modified_memory(ram_addr_t start, ram_addr_t length);
 #endif
 
 struct MemoryRegion;
diff --git a/xen-all.c b/xen-all.c
index f75ae9f..6250593 100644
--- a/xen-all.c
+++ b/xen-all.c
@@ -1228,3 +1228,24 @@ void xen_shutdown_fatal_error(const char *fmt, ...)
     /* destroy the domain */
     qemu_system_shutdown_request();
 }
+
+void xen_modified_memory(ram_addr_t start, ram_addr_t length)
+{
+    if (unlikely(xen_in_migration)) {
+        int rc;
+        ram_addr_t start_pfn, nb_pages;
+
+        if (length == 0) {
+            length = TARGET_PAGE_SIZE;
+        }
+        start_pfn = start >> TARGET_PAGE_BITS;
+        nb_pages = ((start + length + TARGET_PAGE_SIZE - 1) >> TARGET_PAGE_BITS)
+            - start_pfn;
+        rc = xc_hvm_modified_memory(xen_xc, xen_domid, start_pfn, nb_pages);
+        if (rc) {
+            fprintf(stderr, "%s failed for "RAM_ADDR_FMT" ("RAM_ADDR_FMT
+                    "): %i, %s\n", __func__,
+                    start, nb_pages, rc, strerror(-rc));
+        }
+    }
+}
diff --git a/xen-stub.c b/xen-stub.c
index 5e66ba8..9214392 100644
--- a/xen-stub.c
+++ b/xen-stub.c
@@ -59,3 +59,7 @@ void xen_register_framebuffer(MemoryRegion *mr)
 void qmp_xen_set_global_dirty_log(bool enable, Error **errp)
 {
 }
+
+void xen_modified_memory(ram_addr_t start, ram_addr_t length)
+{
+}
-- 
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 Sep 20 11:14:07 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Sep 2012 11:14:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TEehc-000061-89; Thu, 20 Sep 2012 11:13: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 1TEeha-00005o-PR
	for xen-devel@lists.xen.org; Thu, 20 Sep 2012 11:13:50 +0000
Received: from [85.158.143.99:62433] by server-1.bemta-4.messagelabs.com id
	D2/5A-05684-E6AFA505; Thu, 20 Sep 2012 11:13:50 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1348139627!24688639!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNzYxMzI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2843 invoked from network); 20 Sep 2012 11:13:49 -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;
	20 Sep 2012 11:13:49 -0000
X-IronPort-AV: E=Sophos;i="4.80,453,1344211200"; d="scan'208";a="208668336"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Sep 2012 11:13:28 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Thu, 20 Sep 2012 07:13:28 -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 1TEehE-0006Xi-9B;
	Thu, 20 Sep 2012 12:13:28 +0100
From: Anthony PERARD <anthony.perard@citrix.com>
To: QEMU-devel <qemu-devel@nongnu.org>
Date: Thu, 20 Sep 2012 12:12:49 +0100
Message-ID: <1348139574-23324-1-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.12
MIME-Version: 1.0
Cc: Anthony Liguori <aliguori@us.ibm.com>,
	Luiz Capitulino <lcapitulino@redhat.com>,
	Stefano Stabellini <stefano.stabellini@citrix.com>,
	Avi Kivity <avi@redhat.com>, Anthony PERARD <anthony.perard@citrix.com>,
	Xen Devel <xen-devel@lists.xen.org>
Subject: [Xen-devel] [PATCH V3 0/5] Xen, introducing dirty log for 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

Hi,

This patch set will fix live migration under Xen. For this I introduce a new
QMP command to switch global-dirty log and few calls (in exec.c and memory.c)
to xen set_dirty function.

Change since v2:
  - renamed set_dirty_helper to invalidate_and_set_dirty.
  - in the last patch, set vram as dirty if the xen call fails, instead of only
    during migration.

Change v1-v2:
  - New patch to set dirty if not, in exec.c
    => only one place to add the xen call in exec.c


Thanks for your reviews,



Anthony PERARD (5):
  QMP, Introduce xen-set-global-dirty-log command.
  xen: Introduce xen_modified_memory.
  exec: Introduce helper to set dirty flags.
  exec, memory: Call to xen_modified_memory.
  xen: Set the vram dirty when an error occur.

 exec.c           | 53 ++++++++++++++++++-----------------------------------
 hw/xen.h         |  1 +
 memory.c         |  2 ++
 qapi-schema.json | 13 +++++++++++++
 qmp-commands.hx  | 24 ++++++++++++++++++++++++
 xen-all.c        | 39 ++++++++++++++++++++++++++++++++++++++-
 xen-stub.c       |  9 +++++++++
 7 files changed, 105 insertions(+), 36 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 Thu Sep 20 11:14:07 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Sep 2012 11:14:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TEehc-000061-89; Thu, 20 Sep 2012 11:13: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 1TEeha-00005o-PR
	for xen-devel@lists.xen.org; Thu, 20 Sep 2012 11:13:50 +0000
Received: from [85.158.143.99:62433] by server-1.bemta-4.messagelabs.com id
	D2/5A-05684-E6AFA505; Thu, 20 Sep 2012 11:13:50 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1348139627!24688639!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNzYxMzI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2843 invoked from network); 20 Sep 2012 11:13:49 -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;
	20 Sep 2012 11:13:49 -0000
X-IronPort-AV: E=Sophos;i="4.80,453,1344211200"; d="scan'208";a="208668336"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Sep 2012 11:13:28 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Thu, 20 Sep 2012 07:13:28 -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 1TEehE-0006Xi-9B;
	Thu, 20 Sep 2012 12:13:28 +0100
From: Anthony PERARD <anthony.perard@citrix.com>
To: QEMU-devel <qemu-devel@nongnu.org>
Date: Thu, 20 Sep 2012 12:12:49 +0100
Message-ID: <1348139574-23324-1-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.12
MIME-Version: 1.0
Cc: Anthony Liguori <aliguori@us.ibm.com>,
	Luiz Capitulino <lcapitulino@redhat.com>,
	Stefano Stabellini <stefano.stabellini@citrix.com>,
	Avi Kivity <avi@redhat.com>, Anthony PERARD <anthony.perard@citrix.com>,
	Xen Devel <xen-devel@lists.xen.org>
Subject: [Xen-devel] [PATCH V3 0/5] Xen, introducing dirty log for 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

Hi,

This patch set will fix live migration under Xen. For this I introduce a new
QMP command to switch global-dirty log and few calls (in exec.c and memory.c)
to xen set_dirty function.

Change since v2:
  - renamed set_dirty_helper to invalidate_and_set_dirty.
  - in the last patch, set vram as dirty if the xen call fails, instead of only
    during migration.

Change v1-v2:
  - New patch to set dirty if not, in exec.c
    => only one place to add the xen call in exec.c


Thanks for your reviews,



Anthony PERARD (5):
  QMP, Introduce xen-set-global-dirty-log command.
  xen: Introduce xen_modified_memory.
  exec: Introduce helper to set dirty flags.
  exec, memory: Call to xen_modified_memory.
  xen: Set the vram dirty when an error occur.

 exec.c           | 53 ++++++++++++++++++-----------------------------------
 hw/xen.h         |  1 +
 memory.c         |  2 ++
 qapi-schema.json | 13 +++++++++++++
 qmp-commands.hx  | 24 ++++++++++++++++++++++++
 xen-all.c        | 39 ++++++++++++++++++++++++++++++++++++++-
 xen-stub.c       |  9 +++++++++
 7 files changed, 105 insertions(+), 36 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 Thu Sep 20 11:14:07 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Sep 2012 11:14:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TEehg-00007Y-0G; Thu, 20 Sep 2012 11:13: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 1TEehf-00006V-1z
	for xen-devel@lists.xen.org; Thu, 20 Sep 2012 11:13:55 +0000
Received: from [85.158.143.35:10821] by server-3.bemta-4.messagelabs.com id
	F6/EA-10986-17AFA505; Thu, 20 Sep 2012 11:13:53 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1348139630!8078463!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNzYxMzI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32087 invoked from network); 20 Sep 2012 11:13:52 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Sep 2012 11:13:52 -0000
X-IronPort-AV: E=Sophos;i="4.80,453,1344211200"; d="scan'208";a="208668342"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Sep 2012 11:13:29 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Thu, 20 Sep 2012 07:13:28 -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 1TEehE-0006Xi-BL;
	Thu, 20 Sep 2012 12:13:28 +0100
From: Anthony PERARD <anthony.perard@citrix.com>
To: QEMU-devel <qemu-devel@nongnu.org>
Date: Thu, 20 Sep 2012 12:12:54 +0100
Message-ID: <1348139574-23324-6-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.12
In-Reply-To: <1348139574-23324-1-git-send-email-anthony.perard@citrix.com>
References: <1348139574-23324-1-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Cc: Anthony Liguori <aliguori@us.ibm.com>,
	Luiz Capitulino <lcapitulino@redhat.com>,
	Stefano Stabellini <stefano.stabellini@citrix.com>,
	Avi Kivity <avi@redhat.com>, Anthony PERARD <anthony.perard@citrix.com>,
	Xen Devel <xen-devel@lists.xen.org>
Subject: [Xen-devel] [PATCH V3 5/5] xen: Set the vram dirty when an error
	occur.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

If the call to xc_hvm_track_dirty_vram() fails, then we set dirtybit on all the
video ram. This case happens during migration, but we don't need a special case
for live migration with patch.

Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
 xen-all.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/xen-all.c b/xen-all.c
index 6250593..ab28261 100644
--- a/xen-all.c
+++ b/xen-all.c
@@ -507,7 +507,8 @@ static void xen_sync_dirty_bitmap(XenIOState *state,
                                  bitmap);
     if (rc < 0) {
         if (rc != -ENODATA) {
-            fprintf(stderr, "xen: track_dirty_vram failed (0x" TARGET_FMT_plx
+            memory_region_set_dirty(framebuffer, 0, size);
+            DPRINTF("xen: track_dirty_vram failed (0x" TARGET_FMT_plx
                     ", 0x" TARGET_FMT_plx "): %s\n",
                     start_addr, start_addr + size, strerror(-rc));
         }
-- 
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 Sep 20 11:14:07 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Sep 2012 11:14:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TEehg-00007Y-0G; Thu, 20 Sep 2012 11:13: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 1TEehf-00006V-1z
	for xen-devel@lists.xen.org; Thu, 20 Sep 2012 11:13:55 +0000
Received: from [85.158.143.35:10821] by server-3.bemta-4.messagelabs.com id
	F6/EA-10986-17AFA505; Thu, 20 Sep 2012 11:13:53 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1348139630!8078463!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNzYxMzI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32087 invoked from network); 20 Sep 2012 11:13:52 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Sep 2012 11:13:52 -0000
X-IronPort-AV: E=Sophos;i="4.80,453,1344211200"; d="scan'208";a="208668342"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Sep 2012 11:13:29 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Thu, 20 Sep 2012 07:13:28 -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 1TEehE-0006Xi-BL;
	Thu, 20 Sep 2012 12:13:28 +0100
From: Anthony PERARD <anthony.perard@citrix.com>
To: QEMU-devel <qemu-devel@nongnu.org>
Date: Thu, 20 Sep 2012 12:12:54 +0100
Message-ID: <1348139574-23324-6-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.12
In-Reply-To: <1348139574-23324-1-git-send-email-anthony.perard@citrix.com>
References: <1348139574-23324-1-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Cc: Anthony Liguori <aliguori@us.ibm.com>,
	Luiz Capitulino <lcapitulino@redhat.com>,
	Stefano Stabellini <stefano.stabellini@citrix.com>,
	Avi Kivity <avi@redhat.com>, Anthony PERARD <anthony.perard@citrix.com>,
	Xen Devel <xen-devel@lists.xen.org>
Subject: [Xen-devel] [PATCH V3 5/5] xen: Set the vram dirty when an error
	occur.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

If the call to xc_hvm_track_dirty_vram() fails, then we set dirtybit on all the
video ram. This case happens during migration, but we don't need a special case
for live migration with patch.

Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
 xen-all.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/xen-all.c b/xen-all.c
index 6250593..ab28261 100644
--- a/xen-all.c
+++ b/xen-all.c
@@ -507,7 +507,8 @@ static void xen_sync_dirty_bitmap(XenIOState *state,
                                  bitmap);
     if (rc < 0) {
         if (rc != -ENODATA) {
-            fprintf(stderr, "xen: track_dirty_vram failed (0x" TARGET_FMT_plx
+            memory_region_set_dirty(framebuffer, 0, size);
+            DPRINTF("xen: track_dirty_vram failed (0x" TARGET_FMT_plx
                     ", 0x" TARGET_FMT_plx "): %s\n",
                     start_addr, start_addr + size, strerror(-rc));
         }
-- 
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 Sep 20 11:14:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Sep 2012 11: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 1TEehe-00006v-JO; Thu, 20 Sep 2012 11:13: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 1TEehd-00005o-7L
	for xen-devel@lists.xen.org; Thu, 20 Sep 2012 11:13:53 +0000
Received: from [85.158.143.99:48177] by server-1.bemta-4.messagelabs.com id
	C0/6A-05684-07AFA505; Thu, 20 Sep 2012 11:13:52 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1348139627!24688639!4
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNzYxMzI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2911 invoked from network); 20 Sep 2012 11:13:51 -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;
	20 Sep 2012 11:13:51 -0000
X-IronPort-AV: E=Sophos;i="4.80,453,1344211200"; d="scan'208";a="208668339"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Sep 2012 11:13:29 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Thu, 20 Sep 2012 07:13:28 -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 1TEehE-0006Xi-AT;
	Thu, 20 Sep 2012 12:13:28 +0100
From: Anthony PERARD <anthony.perard@citrix.com>
To: QEMU-devel <qemu-devel@nongnu.org>
Date: Thu, 20 Sep 2012 12:12:52 +0100
Message-ID: <1348139574-23324-4-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.12
In-Reply-To: <1348139574-23324-1-git-send-email-anthony.perard@citrix.com>
References: <1348139574-23324-1-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Cc: Anthony Liguori <aliguori@us.ibm.com>,
	Luiz Capitulino <lcapitulino@redhat.com>,
	Stefano Stabellini <stefano.stabellini@citrix.com>,
	Avi Kivity <avi@redhat.com>, Anthony PERARD <anthony.perard@citrix.com>,
	Xen Devel <xen-devel@lists.xen.org>
Subject: [Xen-devel] [PATCH V3 3/5] exec: Introduce helper to set dirty
	flags.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This new helper/hook is used in the next patch to add an extra call in a single
place.

Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
 exec.c | 52 +++++++++++++++++-----------------------------------
 1 file changed, 17 insertions(+), 35 deletions(-)

diff --git a/exec.c b/exec.c
index f22e9e6..209ac1c 100644
--- a/exec.c
+++ b/exec.c
@@ -3419,6 +3419,18 @@ int cpu_memory_rw_debug(CPUArchState *env, target_ulong addr,
 }
 
 #else
+
+static void invalidate_and_set_dirty(target_phys_addr_t addr,
+                                     target_phys_addr_t length)
+{
+    if (!cpu_physical_memory_is_dirty(addr)) {
+        /* invalidate code */
+        tb_invalidate_phys_page_range(addr, addr + length, 0);
+        /* set dirty bit */
+        cpu_physical_memory_set_dirty_flags(addr, (0xff & ~CODE_DIRTY_FLAG));
+    }
+}
+
 void cpu_physical_memory_rw(target_phys_addr_t addr, uint8_t *buf,
                             int len, int is_write)
 {
@@ -3464,13 +3476,7 @@ void cpu_physical_memory_rw(target_phys_addr_t addr, uint8_t *buf,
                 /* RAM case */
                 ptr = qemu_get_ram_ptr(addr1);
                 memcpy(ptr, buf, l);
-                if (!cpu_physical_memory_is_dirty(addr1)) {
-                    /* invalidate code */
-                    tb_invalidate_phys_page_range(addr1, addr1 + l, 0);
-                    /* set dirty bit */
-                    cpu_physical_memory_set_dirty_flags(
-                        addr1, (0xff & ~CODE_DIRTY_FLAG));
-                }
+                invalidate_and_set_dirty(addr1, l);
                 qemu_put_ram_ptr(ptr);
             }
         } else {
@@ -3536,13 +3542,7 @@ void cpu_physical_memory_write_rom(target_phys_addr_t addr,
             /* ROM/RAM case */
             ptr = qemu_get_ram_ptr(addr1);
             memcpy(ptr, buf, l);
-            if (!cpu_physical_memory_is_dirty(addr1)) {
-                /* invalidate code */
-                tb_invalidate_phys_page_range(addr1, addr1 + l, 0);
-                /* set dirty bit */
-                cpu_physical_memory_set_dirty_flags(
-                    addr1, (0xff & ~CODE_DIRTY_FLAG));
-            }
+            invalidate_and_set_dirty(addr1, l);
             qemu_put_ram_ptr(ptr);
         }
         len -= l;
@@ -3668,13 +3668,7 @@ void cpu_physical_memory_unmap(void *buffer, target_phys_addr_t len,
                 l = TARGET_PAGE_SIZE;
                 if (l > access_len)
                     l = access_len;
-                if (!cpu_physical_memory_is_dirty(addr1)) {
-                    /* invalidate code */
-                    tb_invalidate_phys_page_range(addr1, addr1 + l, 0);
-                    /* set dirty bit */
-                    cpu_physical_memory_set_dirty_flags(
-                        addr1, (0xff & ~CODE_DIRTY_FLAG));
-                }
+                invalidate_and_set_dirty(addr1, l);
                 addr1 += l;
                 access_len -= l;
             }
@@ -3980,13 +3974,7 @@ static inline void stl_phys_internal(target_phys_addr_t addr, uint32_t val,
             stl_p(ptr, val);
             break;
         }
-        if (!cpu_physical_memory_is_dirty(addr1)) {
-            /* invalidate code */
-            tb_invalidate_phys_page_range(addr1, addr1 + 4, 0);
-            /* set dirty bit */
-            cpu_physical_memory_set_dirty_flags(addr1,
-                (0xff & ~CODE_DIRTY_FLAG));
-        }
+        invalidate_and_set_dirty(addr1, 4);
     }
 }
 
@@ -4053,13 +4041,7 @@ static inline void stw_phys_internal(target_phys_addr_t addr, uint32_t val,
             stw_p(ptr, val);
             break;
         }
-        if (!cpu_physical_memory_is_dirty(addr1)) {
-            /* invalidate code */
-            tb_invalidate_phys_page_range(addr1, addr1 + 2, 0);
-            /* set dirty bit */
-            cpu_physical_memory_set_dirty_flags(addr1,
-                (0xff & ~CODE_DIRTY_FLAG));
-        }
+        invalidate_and_set_dirty(addr1, 2);
     }
 }
 
-- 
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 Sep 20 11:14:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Sep 2012 11: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 1TEehe-00006v-JO; Thu, 20 Sep 2012 11:13: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 1TEehd-00005o-7L
	for xen-devel@lists.xen.org; Thu, 20 Sep 2012 11:13:53 +0000
Received: from [85.158.143.99:48177] by server-1.bemta-4.messagelabs.com id
	C0/6A-05684-07AFA505; Thu, 20 Sep 2012 11:13:52 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1348139627!24688639!4
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNzYxMzI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2911 invoked from network); 20 Sep 2012 11:13:51 -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;
	20 Sep 2012 11:13:51 -0000
X-IronPort-AV: E=Sophos;i="4.80,453,1344211200"; d="scan'208";a="208668339"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Sep 2012 11:13:29 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Thu, 20 Sep 2012 07:13:28 -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 1TEehE-0006Xi-AT;
	Thu, 20 Sep 2012 12:13:28 +0100
From: Anthony PERARD <anthony.perard@citrix.com>
To: QEMU-devel <qemu-devel@nongnu.org>
Date: Thu, 20 Sep 2012 12:12:52 +0100
Message-ID: <1348139574-23324-4-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.12
In-Reply-To: <1348139574-23324-1-git-send-email-anthony.perard@citrix.com>
References: <1348139574-23324-1-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Cc: Anthony Liguori <aliguori@us.ibm.com>,
	Luiz Capitulino <lcapitulino@redhat.com>,
	Stefano Stabellini <stefano.stabellini@citrix.com>,
	Avi Kivity <avi@redhat.com>, Anthony PERARD <anthony.perard@citrix.com>,
	Xen Devel <xen-devel@lists.xen.org>
Subject: [Xen-devel] [PATCH V3 3/5] exec: Introduce helper to set dirty
	flags.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This new helper/hook is used in the next patch to add an extra call in a single
place.

Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
 exec.c | 52 +++++++++++++++++-----------------------------------
 1 file changed, 17 insertions(+), 35 deletions(-)

diff --git a/exec.c b/exec.c
index f22e9e6..209ac1c 100644
--- a/exec.c
+++ b/exec.c
@@ -3419,6 +3419,18 @@ int cpu_memory_rw_debug(CPUArchState *env, target_ulong addr,
 }
 
 #else
+
+static void invalidate_and_set_dirty(target_phys_addr_t addr,
+                                     target_phys_addr_t length)
+{
+    if (!cpu_physical_memory_is_dirty(addr)) {
+        /* invalidate code */
+        tb_invalidate_phys_page_range(addr, addr + length, 0);
+        /* set dirty bit */
+        cpu_physical_memory_set_dirty_flags(addr, (0xff & ~CODE_DIRTY_FLAG));
+    }
+}
+
 void cpu_physical_memory_rw(target_phys_addr_t addr, uint8_t *buf,
                             int len, int is_write)
 {
@@ -3464,13 +3476,7 @@ void cpu_physical_memory_rw(target_phys_addr_t addr, uint8_t *buf,
                 /* RAM case */
                 ptr = qemu_get_ram_ptr(addr1);
                 memcpy(ptr, buf, l);
-                if (!cpu_physical_memory_is_dirty(addr1)) {
-                    /* invalidate code */
-                    tb_invalidate_phys_page_range(addr1, addr1 + l, 0);
-                    /* set dirty bit */
-                    cpu_physical_memory_set_dirty_flags(
-                        addr1, (0xff & ~CODE_DIRTY_FLAG));
-                }
+                invalidate_and_set_dirty(addr1, l);
                 qemu_put_ram_ptr(ptr);
             }
         } else {
@@ -3536,13 +3542,7 @@ void cpu_physical_memory_write_rom(target_phys_addr_t addr,
             /* ROM/RAM case */
             ptr = qemu_get_ram_ptr(addr1);
             memcpy(ptr, buf, l);
-            if (!cpu_physical_memory_is_dirty(addr1)) {
-                /* invalidate code */
-                tb_invalidate_phys_page_range(addr1, addr1 + l, 0);
-                /* set dirty bit */
-                cpu_physical_memory_set_dirty_flags(
-                    addr1, (0xff & ~CODE_DIRTY_FLAG));
-            }
+            invalidate_and_set_dirty(addr1, l);
             qemu_put_ram_ptr(ptr);
         }
         len -= l;
@@ -3668,13 +3668,7 @@ void cpu_physical_memory_unmap(void *buffer, target_phys_addr_t len,
                 l = TARGET_PAGE_SIZE;
                 if (l > access_len)
                     l = access_len;
-                if (!cpu_physical_memory_is_dirty(addr1)) {
-                    /* invalidate code */
-                    tb_invalidate_phys_page_range(addr1, addr1 + l, 0);
-                    /* set dirty bit */
-                    cpu_physical_memory_set_dirty_flags(
-                        addr1, (0xff & ~CODE_DIRTY_FLAG));
-                }
+                invalidate_and_set_dirty(addr1, l);
                 addr1 += l;
                 access_len -= l;
             }
@@ -3980,13 +3974,7 @@ static inline void stl_phys_internal(target_phys_addr_t addr, uint32_t val,
             stl_p(ptr, val);
             break;
         }
-        if (!cpu_physical_memory_is_dirty(addr1)) {
-            /* invalidate code */
-            tb_invalidate_phys_page_range(addr1, addr1 + 4, 0);
-            /* set dirty bit */
-            cpu_physical_memory_set_dirty_flags(addr1,
-                (0xff & ~CODE_DIRTY_FLAG));
-        }
+        invalidate_and_set_dirty(addr1, 4);
     }
 }
 
@@ -4053,13 +4041,7 @@ static inline void stw_phys_internal(target_phys_addr_t addr, uint32_t val,
             stw_p(ptr, val);
             break;
         }
-        if (!cpu_physical_memory_is_dirty(addr1)) {
-            /* invalidate code */
-            tb_invalidate_phys_page_range(addr1, addr1 + 2, 0);
-            /* set dirty bit */
-            cpu_physical_memory_set_dirty_flags(addr1,
-                (0xff & ~CODE_DIRTY_FLAG));
-        }
+        invalidate_and_set_dirty(addr1, 2);
     }
 }
 
-- 
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 Sep 20 11:14:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Sep 2012 11: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 1TEehd-00006K-18; Thu, 20 Sep 2012 11:13: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 1TEehc-00005o-4F
	for xen-devel@lists.xen.org; Thu, 20 Sep 2012 11:13:52 +0000
Received: from [85.158.143.99:62488] by server-1.bemta-4.messagelabs.com id
	7A/5A-05684-F6AFA505; Thu, 20 Sep 2012 11:13:51 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1348139627!24688639!3
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNzYxMzI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2896 invoked from network); 20 Sep 2012 11:13:51 -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;
	20 Sep 2012 11:13:51 -0000
X-IronPort-AV: E=Sophos;i="4.80,453,1344211200"; d="scan'208";a="208668340"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Sep 2012 11:13:29 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Thu, 20 Sep 2012 07:13:28 -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 1TEehE-0006Xi-Av;
	Thu, 20 Sep 2012 12:13:28 +0100
From: Anthony PERARD <anthony.perard@citrix.com>
To: QEMU-devel <qemu-devel@nongnu.org>
Date: Thu, 20 Sep 2012 12:12:53 +0100
Message-ID: <1348139574-23324-5-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.12
In-Reply-To: <1348139574-23324-1-git-send-email-anthony.perard@citrix.com>
References: <1348139574-23324-1-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Cc: Anthony Liguori <aliguori@us.ibm.com>,
	Luiz Capitulino <lcapitulino@redhat.com>,
	Stefano Stabellini <stefano.stabellini@citrix.com>,
	Avi Kivity <avi@redhat.com>, Anthony PERARD <anthony.perard@citrix.com>,
	Xen Devel <xen-devel@lists.xen.org>
Subject: [Xen-devel] [PATCH V3 4/5] exec,
	memory: Call to xen_modified_memory.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This patch add some calls to xen_modified_memory to notify Xen about dirtybits
during migration.

Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
 exec.c   | 1 +
 memory.c | 2 ++
 2 files changed, 3 insertions(+)

diff --git a/exec.c b/exec.c
index 209ac1c..844a73c 100644
--- a/exec.c
+++ b/exec.c
@@ -3429,6 +3429,7 @@ static void invalidate_and_set_dirty(target_phys_addr_t addr,
         /* set dirty bit */
         cpu_physical_memory_set_dirty_flags(addr, (0xff & ~CODE_DIRTY_FLAG));
     }
+    xen_modified_memory(addr, length);
 }
 
 void cpu_physical_memory_rw(target_phys_addr_t addr, uint8_t *buf,
diff --git a/memory.c b/memory.c
index 4f3ade0..015c544 100644
--- a/memory.c
+++ b/memory.c
@@ -19,6 +19,7 @@
 #include "bitops.h"
 #include "kvm.h"
 #include <assert.h>
+#include "hw/xen.h"
 
 #define WANT_EXEC_OBSOLETE
 #include "exec-obsolete.h"
@@ -1077,6 +1078,7 @@ void memory_region_set_dirty(MemoryRegion *mr, target_phys_addr_t addr,
                              target_phys_addr_t size)
 {
     assert(mr->terminates);
+    xen_modified_memory(mr->ram_addr + addr, size);
     return cpu_physical_memory_set_dirty_range(mr->ram_addr + addr, size, -1);
 }
 
-- 
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 Sep 20 11:14:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Sep 2012 11: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 1TEehd-00006K-18; Thu, 20 Sep 2012 11:13: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 1TEehc-00005o-4F
	for xen-devel@lists.xen.org; Thu, 20 Sep 2012 11:13:52 +0000
Received: from [85.158.143.99:62488] by server-1.bemta-4.messagelabs.com id
	7A/5A-05684-F6AFA505; Thu, 20 Sep 2012 11:13:51 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1348139627!24688639!3
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNzYxMzI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2896 invoked from network); 20 Sep 2012 11:13:51 -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;
	20 Sep 2012 11:13:51 -0000
X-IronPort-AV: E=Sophos;i="4.80,453,1344211200"; d="scan'208";a="208668340"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Sep 2012 11:13:29 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Thu, 20 Sep 2012 07:13:28 -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 1TEehE-0006Xi-Av;
	Thu, 20 Sep 2012 12:13:28 +0100
From: Anthony PERARD <anthony.perard@citrix.com>
To: QEMU-devel <qemu-devel@nongnu.org>
Date: Thu, 20 Sep 2012 12:12:53 +0100
Message-ID: <1348139574-23324-5-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.12
In-Reply-To: <1348139574-23324-1-git-send-email-anthony.perard@citrix.com>
References: <1348139574-23324-1-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Cc: Anthony Liguori <aliguori@us.ibm.com>,
	Luiz Capitulino <lcapitulino@redhat.com>,
	Stefano Stabellini <stefano.stabellini@citrix.com>,
	Avi Kivity <avi@redhat.com>, Anthony PERARD <anthony.perard@citrix.com>,
	Xen Devel <xen-devel@lists.xen.org>
Subject: [Xen-devel] [PATCH V3 4/5] exec,
	memory: Call to xen_modified_memory.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This patch add some calls to xen_modified_memory to notify Xen about dirtybits
during migration.

Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
 exec.c   | 1 +
 memory.c | 2 ++
 2 files changed, 3 insertions(+)

diff --git a/exec.c b/exec.c
index 209ac1c..844a73c 100644
--- a/exec.c
+++ b/exec.c
@@ -3429,6 +3429,7 @@ static void invalidate_and_set_dirty(target_phys_addr_t addr,
         /* set dirty bit */
         cpu_physical_memory_set_dirty_flags(addr, (0xff & ~CODE_DIRTY_FLAG));
     }
+    xen_modified_memory(addr, length);
 }
 
 void cpu_physical_memory_rw(target_phys_addr_t addr, uint8_t *buf,
diff --git a/memory.c b/memory.c
index 4f3ade0..015c544 100644
--- a/memory.c
+++ b/memory.c
@@ -19,6 +19,7 @@
 #include "bitops.h"
 #include "kvm.h"
 #include <assert.h>
+#include "hw/xen.h"
 
 #define WANT_EXEC_OBSOLETE
 #include "exec-obsolete.h"
@@ -1077,6 +1078,7 @@ void memory_region_set_dirty(MemoryRegion *mr, target_phys_addr_t addr,
                              target_phys_addr_t size)
 {
     assert(mr->terminates);
+    xen_modified_memory(mr->ram_addr + addr, size);
     return cpu_physical_memory_set_dirty_range(mr->ram_addr + addr, size, -1);
 }
 
-- 
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 Sep 20 11:17:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Sep 2012 11:17:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TEelO-0000t4-50; Thu, 20 Sep 2012 11:17:46 +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 1TEelM-0000sm-AU
	for xen-devel@lists.xen.org; Thu, 20 Sep 2012 11:17:44 +0000
Received: from [85.158.143.99:7220] by server-3.bemta-4.messagelabs.com id
	63/70-10986-75BFA505; Thu, 20 Sep 2012 11:17:43 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1348139862!31142185!1
X-Originating-IP: [209.85.215.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12167 invoked from network); 20 Sep 2012 11:17:43 -0000
Received: from mail-ey0-f173.google.com (HELO mail-ey0-f173.google.com)
	(209.85.215.173)
	by server-9.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Sep 2012 11:17:43 -0000
Received: by eaac13 with SMTP id c13so702150eaa.32
	for <xen-devel@lists.xen.org>; Thu, 20 Sep 2012 04:17: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;
	bh=TOswM+9yALbc5Gasc5DhPXkWObaGa7PBX8DecfjX5iU=;
	b=UZUAsqilRJRPS5jIEldAsE0SL5NG5SHPBzWCrafr1N5f5zO1GbHT00a7+vqEllucuK
	ANtCnVgvlHy/54WMuCJLGplc/QRr7KmSaeaT62tlF7h3Nzu3QCHFeWdSlgG72EC+qFZV
	FCKBVkIJNALmjUSMYhVd2K9GgvWub5hNSgPiSUjwB/iEIWwWevQct8p6hKVSLItPS3s9
	M6yoBSstVwAdYGrCflinksUrJObxd+R3lz2SVp14zQtArNnX7tVfUUluF/aUD27pKqTL
	UE4ONndY3zj5QJG7FEf9R2SS7iuN06H4V1u58U9gopI+4BppEDqx3HBLRldujQXk18kS
	gz5g==
MIME-Version: 1.0
Received: by 10.14.199.67 with SMTP id w43mr1746735een.33.1348139862709; Thu,
	20 Sep 2012 04:17:42 -0700 (PDT)
Received: by 10.14.215.195 with HTTP; Thu, 20 Sep 2012 04:17:42 -0700 (PDT)
In-Reply-To: <505ADBCF020000780009C7BE@nat28.tlf.novell.com>
References: <CAFLBxZYtmJ_bKFb90r45=C4Pq1-oe5Fy=eygSsQf4BcGj3EqGA@mail.gmail.com>
	<505ADBCF020000780009C7BE@nat28.tlf.novell.com>
Date: Thu, 20 Sep 2012 12:17:42 +0100
X-Google-Sender-Auth: twzjZJRos8VreFX3GI657GCADR0
Message-ID: <CAFLBxZZAYBjYxX4K_LBE+dvkH8D9rfeAy538n4ACcQr=+bew8g@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Xen 4.3 development 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 Thu, Sep 20, 2012 at 8:03 AM, Jan Beulich <JBeulich@suse.com> wrote:
>>>> On 19.09.12 at 18:58, George Dunlap <George.Dunlap@eu.citrix.com> wrote:
>> = Timeline =
>>
>> We are planning on a 9-month release cycle.  Based on that, below are
>> our estimated dates:
>> * Feature Freeze: 1 March, 2013
>> * First RC: 15 April 2013
>> * Release: 1 June 2013
>
> While it's only slightly over two weeks - didn't we agree to count
> from the release date (rather than the intended one)?

So we did.  And if we actually do 6 weeks for each milestone, that gives us:

* Feature Freeze: 25 March 2013
* First RC: 6 May 2013
* Release: 17 June 2013

Sound reasonable?

>> * Persistent grants
>>   owner: @citrix
>>   status: ?
>
> Isn't that a guest side only thing (i.e. not really to be tracked
> here)? Or does that mean migrating active grants?

It is a bit funny to have Linux-side stuff tracked here, since it has
its own release schedule; but there's not really a better place to
track it.  For both a "look at the great stuff happening" aspect, and
a "what needs to be done and who is going to do it when" aspect,
having all of the various development activities in one place is an
advantage.

>> * Scalability: 16TiB of RAM
>>   owner: jan@suse
>>   status: ?
>
> Not started.
>
>> * Linux console improvements
>>   owner: jan@suse
>>   -EHCI debug port (done, to be submitted)
>
> Committed.

Excellent; first to go under the (newly-created) "completed" category.

>>   -xHCI debug port
>
> This one needs an owner having access to suitable hardware _and_
> knowledge of the protocol since, other than for EHCI, there isn't
> even a reference implementation (e.g. in Linux) to clone from. I'd
> therefore rather consider this nice-to-have than a firm plan to have
> such functionality.
>
>>   -Firewire
>
> Largely same here - while I'm not suffering from lack of hardware
> (apart from - afaict - cables), I've never done anything with
> Firewire, and hence would consider this one as well nice-to-have
> only.

"Nice-to-have" vs "blocker" is more something that will need to be
considered near the feature freeze.  There are a handful of things
that the Citrix team, internally, have deemed "critical" -- that is,
if they seem to be in danger of missing, we will divert resources in
order to help them make 4.3; but other than those, I think basically
all the features in this list would be "nice-to-have".

Perhaps what we really need is a way to track the probability of
success, so that those who want a particular feature to make it in can
take action if they need to; for example:
* Green: Owned, and no reason to think it won't make it in
* Yellow: At-risk; may need intervention to make it in
* Red: High probability of failure; possibly avert-able by immediate action
* Grey: Not owned, or something blocking; but no reason it couldn't
make it in if someone picks it up
* Black: Very unlikely to make it in; expected to be held off until
next release.

So in this scheme, the xHCI and Firewire would be "grey" -- no reason
to think they couldn't make it by the deadline, but it's blocked on
something.

Or, maybe that's more than we need at the moment. :-)  Thoughts?

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 20 11:17:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Sep 2012 11:17:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TEelO-0000t4-50; Thu, 20 Sep 2012 11:17:46 +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 1TEelM-0000sm-AU
	for xen-devel@lists.xen.org; Thu, 20 Sep 2012 11:17:44 +0000
Received: from [85.158.143.99:7220] by server-3.bemta-4.messagelabs.com id
	63/70-10986-75BFA505; Thu, 20 Sep 2012 11:17:43 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1348139862!31142185!1
X-Originating-IP: [209.85.215.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12167 invoked from network); 20 Sep 2012 11:17:43 -0000
Received: from mail-ey0-f173.google.com (HELO mail-ey0-f173.google.com)
	(209.85.215.173)
	by server-9.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Sep 2012 11:17:43 -0000
Received: by eaac13 with SMTP id c13so702150eaa.32
	for <xen-devel@lists.xen.org>; Thu, 20 Sep 2012 04:17: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;
	bh=TOswM+9yALbc5Gasc5DhPXkWObaGa7PBX8DecfjX5iU=;
	b=UZUAsqilRJRPS5jIEldAsE0SL5NG5SHPBzWCrafr1N5f5zO1GbHT00a7+vqEllucuK
	ANtCnVgvlHy/54WMuCJLGplc/QRr7KmSaeaT62tlF7h3Nzu3QCHFeWdSlgG72EC+qFZV
	FCKBVkIJNALmjUSMYhVd2K9GgvWub5hNSgPiSUjwB/iEIWwWevQct8p6hKVSLItPS3s9
	M6yoBSstVwAdYGrCflinksUrJObxd+R3lz2SVp14zQtArNnX7tVfUUluF/aUD27pKqTL
	UE4ONndY3zj5QJG7FEf9R2SS7iuN06H4V1u58U9gopI+4BppEDqx3HBLRldujQXk18kS
	gz5g==
MIME-Version: 1.0
Received: by 10.14.199.67 with SMTP id w43mr1746735een.33.1348139862709; Thu,
	20 Sep 2012 04:17:42 -0700 (PDT)
Received: by 10.14.215.195 with HTTP; Thu, 20 Sep 2012 04:17:42 -0700 (PDT)
In-Reply-To: <505ADBCF020000780009C7BE@nat28.tlf.novell.com>
References: <CAFLBxZYtmJ_bKFb90r45=C4Pq1-oe5Fy=eygSsQf4BcGj3EqGA@mail.gmail.com>
	<505ADBCF020000780009C7BE@nat28.tlf.novell.com>
Date: Thu, 20 Sep 2012 12:17:42 +0100
X-Google-Sender-Auth: twzjZJRos8VreFX3GI657GCADR0
Message-ID: <CAFLBxZZAYBjYxX4K_LBE+dvkH8D9rfeAy538n4ACcQr=+bew8g@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Xen 4.3 development 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 Thu, Sep 20, 2012 at 8:03 AM, Jan Beulich <JBeulich@suse.com> wrote:
>>>> On 19.09.12 at 18:58, George Dunlap <George.Dunlap@eu.citrix.com> wrote:
>> = Timeline =
>>
>> We are planning on a 9-month release cycle.  Based on that, below are
>> our estimated dates:
>> * Feature Freeze: 1 March, 2013
>> * First RC: 15 April 2013
>> * Release: 1 June 2013
>
> While it's only slightly over two weeks - didn't we agree to count
> from the release date (rather than the intended one)?

So we did.  And if we actually do 6 weeks for each milestone, that gives us:

* Feature Freeze: 25 March 2013
* First RC: 6 May 2013
* Release: 17 June 2013

Sound reasonable?

>> * Persistent grants
>>   owner: @citrix
>>   status: ?
>
> Isn't that a guest side only thing (i.e. not really to be tracked
> here)? Or does that mean migrating active grants?

It is a bit funny to have Linux-side stuff tracked here, since it has
its own release schedule; but there's not really a better place to
track it.  For both a "look at the great stuff happening" aspect, and
a "what needs to be done and who is going to do it when" aspect,
having all of the various development activities in one place is an
advantage.

>> * Scalability: 16TiB of RAM
>>   owner: jan@suse
>>   status: ?
>
> Not started.
>
>> * Linux console improvements
>>   owner: jan@suse
>>   -EHCI debug port (done, to be submitted)
>
> Committed.

Excellent; first to go under the (newly-created) "completed" category.

>>   -xHCI debug port
>
> This one needs an owner having access to suitable hardware _and_
> knowledge of the protocol since, other than for EHCI, there isn't
> even a reference implementation (e.g. in Linux) to clone from. I'd
> therefore rather consider this nice-to-have than a firm plan to have
> such functionality.
>
>>   -Firewire
>
> Largely same here - while I'm not suffering from lack of hardware
> (apart from - afaict - cables), I've never done anything with
> Firewire, and hence would consider this one as well nice-to-have
> only.

"Nice-to-have" vs "blocker" is more something that will need to be
considered near the feature freeze.  There are a handful of things
that the Citrix team, internally, have deemed "critical" -- that is,
if they seem to be in danger of missing, we will divert resources in
order to help them make 4.3; but other than those, I think basically
all the features in this list would be "nice-to-have".

Perhaps what we really need is a way to track the probability of
success, so that those who want a particular feature to make it in can
take action if they need to; for example:
* Green: Owned, and no reason to think it won't make it in
* Yellow: At-risk; may need intervention to make it in
* Red: High probability of failure; possibly avert-able by immediate action
* Grey: Not owned, or something blocking; but no reason it couldn't
make it in if someone picks it up
* Black: Very unlikely to make it in; expected to be held off until
next release.

So in this scheme, the xHCI and Firewire would be "grey" -- no reason
to think they couldn't make it by the deadline, but it's blocked on
something.

Or, maybe that's more than we need at the moment. :-)  Thoughts?

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 20 11:18:36 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Sep 2012 11: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 1TEem2-0000zH-Iw; Thu, 20 Sep 2012 11:18:26 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dave.martin@linaro.org>) id 1TEem1-0000z3-47
	for xen-devel@lists.xensource.com; Thu, 20 Sep 2012 11:18:25 +0000
Received: from [85.158.143.35:31168] by server-3.bemta-4.messagelabs.com id
	B0/B1-10986-08BFA505; Thu, 20 Sep 2012 11:18:24 +0000
X-Env-Sender: dave.martin@linaro.org
X-Msg-Ref: server-14.tower-21.messagelabs.com!1348139903!19170602!1
X-Originating-IP: [209.85.215.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16613 invoked from network); 20 Sep 2012 11:18:24 -0000
Received: from mail-ey0-f171.google.com (HELO mail-ey0-f171.google.com)
	(209.85.215.171)
	by server-14.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Sep 2012 11:18:24 -0000
Received: by eaah11 with SMTP id h11so679222eaa.30
	for <xen-devel@lists.xensource.com>;
	Thu, 20 Sep 2012 04:18:23 -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=rgKMzIoOz1BkwVxc5NECAPx/QHZNU84dUmqvDE1hhn8=;
	b=ZftU8ciiIztRq5bTmCUkEH1oBHVo7NyJggjVkZS4LES4nhAVSrApvS6CQ61mjexd8N
	JID02gYSmeUoWA/rNOBpTNsJGW3jNQtHeCWOmC29zdQukU8Tbye1I4v+qNPYGqJT/a9D
	ArMkrPyT5R2YaIKGYRYgMQFBHxXv9kYeXsjbQTlKfnGgbKJrZPgHYy0vLIq1O4FsWgiy
	iXVUNRLpnbLnsC3qG4SYnqTpUDHGL6tDFw+irwX+y2S6WpEvCYYJUoABKBbGEwDJ/2Br
	dbnfpa11uyh/4bn3Wuj0dEPn5ue/+2ntd4Z/oDTlQ8vnL/oFnipNo9gTNlAb7S04Z67J
	L7vA==
Received: by 10.14.178.72 with SMTP id e48mr1836699eem.1.1348139903545;
	Thu, 20 Sep 2012 04:18:23 -0700 (PDT)
Received: from linaro.org (fw-lnat.cambridge.arm.com. [217.140.96.63])
	by mx.google.com with ESMTPS id k41sm14733748eep.13.2012.09.20.04.18.21
	(version=SSLv3 cipher=OTHER); Thu, 20 Sep 2012 04:18:22 -0700 (PDT)
Date: Thu, 20 Sep 2012 12:18:15 +0100
From: Dave Martin <dave.martin@linaro.org>
To: Pawel Moll <pawel.moll@arm.com>
Message-ID: <20120920111815.GC2117@linaro.org>
References: <1348076658-4511-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<1348135563.11116.94.camel@hornet>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1348135563.11116.94.camel@hornet>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Gm-Message-State: ALoCoQkwQ+uur1zeOu1D/RWTxvSNHBRFrj0D6Fs+Mwu4kIe86UwRcvl+X1TlfVk8NxuKpFBdoxQV
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Ian.Campbell@citrix.com" <Ian.Campbell@citrix.com>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Xen-devel] [PATCH] arm: introduce a DTS for Xen unprivileged
 virtual 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 Thu, Sep 20, 2012 at 11:06:03AM +0100, Pawel Moll wrote:
> Morning,
> 
> On Wed, 2012-09-19 at 18:44 +0100, Stefano Stabellini wrote:
> > +/dts-v1/;
> > +
> > +/include/ "skeleton.dtsi"
> 
> Any particular reason to include skeleton? And I think it would be
> better to use #address-cells = <2> and #size-cells = <2>, to be ready
> for LPAE addresses...
> 
> > +/ {
> > +	model = "XENVM-4.2";
> > +	compatible = "xen,xenvm-4.2", "arm,vexpress";
> > +	interrupt-parent = <&gic>;
> > +
> > +	chosen {
> > +		bootargs = "earlyprintk console=hvc0 root=/dev/xvda init=/sbin/init";
> > +	};

Are you sure this default command line is appropriate?

I don't normally like to see default command lines unless they really
add something which is crucial for the board to work.

None of those args looks vital to me.  They are configuration choices
and should be left up to the user.

Cheers
---Dave

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 20 11:18:36 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Sep 2012 11: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 1TEem2-0000zH-Iw; Thu, 20 Sep 2012 11:18:26 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dave.martin@linaro.org>) id 1TEem1-0000z3-47
	for xen-devel@lists.xensource.com; Thu, 20 Sep 2012 11:18:25 +0000
Received: from [85.158.143.35:31168] by server-3.bemta-4.messagelabs.com id
	B0/B1-10986-08BFA505; Thu, 20 Sep 2012 11:18:24 +0000
X-Env-Sender: dave.martin@linaro.org
X-Msg-Ref: server-14.tower-21.messagelabs.com!1348139903!19170602!1
X-Originating-IP: [209.85.215.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16613 invoked from network); 20 Sep 2012 11:18:24 -0000
Received: from mail-ey0-f171.google.com (HELO mail-ey0-f171.google.com)
	(209.85.215.171)
	by server-14.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Sep 2012 11:18:24 -0000
Received: by eaah11 with SMTP id h11so679222eaa.30
	for <xen-devel@lists.xensource.com>;
	Thu, 20 Sep 2012 04:18:23 -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=rgKMzIoOz1BkwVxc5NECAPx/QHZNU84dUmqvDE1hhn8=;
	b=ZftU8ciiIztRq5bTmCUkEH1oBHVo7NyJggjVkZS4LES4nhAVSrApvS6CQ61mjexd8N
	JID02gYSmeUoWA/rNOBpTNsJGW3jNQtHeCWOmC29zdQukU8Tbye1I4v+qNPYGqJT/a9D
	ArMkrPyT5R2YaIKGYRYgMQFBHxXv9kYeXsjbQTlKfnGgbKJrZPgHYy0vLIq1O4FsWgiy
	iXVUNRLpnbLnsC3qG4SYnqTpUDHGL6tDFw+irwX+y2S6WpEvCYYJUoABKBbGEwDJ/2Br
	dbnfpa11uyh/4bn3Wuj0dEPn5ue/+2ntd4Z/oDTlQ8vnL/oFnipNo9gTNlAb7S04Z67J
	L7vA==
Received: by 10.14.178.72 with SMTP id e48mr1836699eem.1.1348139903545;
	Thu, 20 Sep 2012 04:18:23 -0700 (PDT)
Received: from linaro.org (fw-lnat.cambridge.arm.com. [217.140.96.63])
	by mx.google.com with ESMTPS id k41sm14733748eep.13.2012.09.20.04.18.21
	(version=SSLv3 cipher=OTHER); Thu, 20 Sep 2012 04:18:22 -0700 (PDT)
Date: Thu, 20 Sep 2012 12:18:15 +0100
From: Dave Martin <dave.martin@linaro.org>
To: Pawel Moll <pawel.moll@arm.com>
Message-ID: <20120920111815.GC2117@linaro.org>
References: <1348076658-4511-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<1348135563.11116.94.camel@hornet>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1348135563.11116.94.camel@hornet>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Gm-Message-State: ALoCoQkwQ+uur1zeOu1D/RWTxvSNHBRFrj0D6Fs+Mwu4kIe86UwRcvl+X1TlfVk8NxuKpFBdoxQV
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Ian.Campbell@citrix.com" <Ian.Campbell@citrix.com>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Xen-devel] [PATCH] arm: introduce a DTS for Xen unprivileged
 virtual 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 Thu, Sep 20, 2012 at 11:06:03AM +0100, Pawel Moll wrote:
> Morning,
> 
> On Wed, 2012-09-19 at 18:44 +0100, Stefano Stabellini wrote:
> > +/dts-v1/;
> > +
> > +/include/ "skeleton.dtsi"
> 
> Any particular reason to include skeleton? And I think it would be
> better to use #address-cells = <2> and #size-cells = <2>, to be ready
> for LPAE addresses...
> 
> > +/ {
> > +	model = "XENVM-4.2";
> > +	compatible = "xen,xenvm-4.2", "arm,vexpress";
> > +	interrupt-parent = <&gic>;
> > +
> > +	chosen {
> > +		bootargs = "earlyprintk console=hvc0 root=/dev/xvda init=/sbin/init";
> > +	};

Are you sure this default command line is appropriate?

I don't normally like to see default command lines unless they really
add something which is crucial for the board to work.

None of those args looks vital to me.  They are configuration choices
and should be left up to the user.

Cheers
---Dave

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 20 11:19:53 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Sep 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 1TEenJ-0001Ct-71; Thu, 20 Sep 2012 11:19:45 +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 1TEenH-0001Ce-IV
	for xen-devel@lists.xen.org; Thu, 20 Sep 2012 11:19:43 +0000
Received: from [85.158.137.99:18325] by server-10.bemta-3.messagelabs.com id
	1C/DC-10411-ECBFA505; Thu, 20 Sep 2012 11:19:42 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-14.tower-217.messagelabs.com!1348139981!18424734!1
X-Originating-IP: [74.125.83.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3587 invoked from network); 20 Sep 2012 11:19:41 -0000
Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com)
	(74.125.83.45)
	by server-14.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Sep 2012 11:19:41 -0000
Received: by eeke53 with SMTP id e53so943340eek.32
	for <xen-devel@lists.xen.org>; Thu, 20 Sep 2012 04:19:41 -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=r7fgwYF9UHAHLQ4JbNVGOIaaY4uPANukUYJiLJHBD4U=;
	b=uWkaVkwlD+gEISVL721sKzq/amLyAmNGGB//ruEo1vZutOpvZfFB4e3DanYUZr2dMl
	lKfgmbX4YkgC1c/6acEZfOj40J/GvXa5djwpDs8eDhKCK8mCoIU/5grGGQdOPrM35YYq
	f6c9rAkwr3z6ylMII+oskdSIM4qhmRRrWSBvpKXwMtX3BQDnBdXuKtKt2sCz0VomzFQf
	bcv43zOmZEgUiHPZ265T23jn4a4rC1D7HuTsZd6m0ynpypDmyiRzTfovcjF4AgFW98rn
	7iTfE6z7RoZRzysjuYXvcoa6r+ODoFMkFKxCm5LNntoBnVnU/XWW3E9ZnDxOKpNy3uAK
	lO3A==
MIME-Version: 1.0
Received: by 10.14.172.193 with SMTP id t41mr1770932eel.25.1348139981064; Thu,
	20 Sep 2012 04:19:41 -0700 (PDT)
Received: by 10.14.215.195 with HTTP; Thu, 20 Sep 2012 04:19:41 -0700 (PDT)
In-Reply-To: <CAEBdQ90Htx8xqtbmBdV+06nrCTtAmVV-tXqRpWomez-WP4TRtA@mail.gmail.com>
References: <CAFLBxZYtmJ_bKFb90r45=C4Pq1-oe5Fy=eygSsQf4BcGj3EqGA@mail.gmail.com>
	<CAEBdQ90Htx8xqtbmBdV+06nrCTtAmVV-tXqRpWomez-WP4TRtA@mail.gmail.com>
Date: Thu, 20 Sep 2012 12:19:41 +0100
X-Google-Sender-Auth: uRMXs0_f4oPWiuLIVOxa4RG2d08
Message-ID: <CAFLBxZa_zCbW+FNcPqSeNZVTmigvLdkHfB4oAq_jEYOApTnOHQ@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: Jean Guyader <jean.guyader@gmail.com>
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Xen 4.3 development 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 Thu, Sep 20, 2012 at 10:53 AM, Jean Guyader <jean.guyader@gmail.com> wrote:
> Hi George,
>
> Maybe we could had V4V in the list.
>
> * V4V: Inter-domain communication
>   owner (Xen): jean.guyader@citrix.com
>   status (Xen): patches submitted
>   owner (Linux driver):  stefano.panella@citrix
>   status (Linux driver): in progress

Added.

Just as an aside, in the future, could you trim the quotes from the
reply?  Since I use gmail it doesn't bother me much, but many other
people have complained about having to scroll through hundreds of
lines of quote to get to the new message part. :-)

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 20 11:19:53 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Sep 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 1TEenJ-0001Ct-71; Thu, 20 Sep 2012 11:19:45 +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 1TEenH-0001Ce-IV
	for xen-devel@lists.xen.org; Thu, 20 Sep 2012 11:19:43 +0000
Received: from [85.158.137.99:18325] by server-10.bemta-3.messagelabs.com id
	1C/DC-10411-ECBFA505; Thu, 20 Sep 2012 11:19:42 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-14.tower-217.messagelabs.com!1348139981!18424734!1
X-Originating-IP: [74.125.83.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3587 invoked from network); 20 Sep 2012 11:19:41 -0000
Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com)
	(74.125.83.45)
	by server-14.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Sep 2012 11:19:41 -0000
Received: by eeke53 with SMTP id e53so943340eek.32
	for <xen-devel@lists.xen.org>; Thu, 20 Sep 2012 04:19:41 -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=r7fgwYF9UHAHLQ4JbNVGOIaaY4uPANukUYJiLJHBD4U=;
	b=uWkaVkwlD+gEISVL721sKzq/amLyAmNGGB//ruEo1vZutOpvZfFB4e3DanYUZr2dMl
	lKfgmbX4YkgC1c/6acEZfOj40J/GvXa5djwpDs8eDhKCK8mCoIU/5grGGQdOPrM35YYq
	f6c9rAkwr3z6ylMII+oskdSIM4qhmRRrWSBvpKXwMtX3BQDnBdXuKtKt2sCz0VomzFQf
	bcv43zOmZEgUiHPZ265T23jn4a4rC1D7HuTsZd6m0ynpypDmyiRzTfovcjF4AgFW98rn
	7iTfE6z7RoZRzysjuYXvcoa6r+ODoFMkFKxCm5LNntoBnVnU/XWW3E9ZnDxOKpNy3uAK
	lO3A==
MIME-Version: 1.0
Received: by 10.14.172.193 with SMTP id t41mr1770932eel.25.1348139981064; Thu,
	20 Sep 2012 04:19:41 -0700 (PDT)
Received: by 10.14.215.195 with HTTP; Thu, 20 Sep 2012 04:19:41 -0700 (PDT)
In-Reply-To: <CAEBdQ90Htx8xqtbmBdV+06nrCTtAmVV-tXqRpWomez-WP4TRtA@mail.gmail.com>
References: <CAFLBxZYtmJ_bKFb90r45=C4Pq1-oe5Fy=eygSsQf4BcGj3EqGA@mail.gmail.com>
	<CAEBdQ90Htx8xqtbmBdV+06nrCTtAmVV-tXqRpWomez-WP4TRtA@mail.gmail.com>
Date: Thu, 20 Sep 2012 12:19:41 +0100
X-Google-Sender-Auth: uRMXs0_f4oPWiuLIVOxa4RG2d08
Message-ID: <CAFLBxZa_zCbW+FNcPqSeNZVTmigvLdkHfB4oAq_jEYOApTnOHQ@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: Jean Guyader <jean.guyader@gmail.com>
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Xen 4.3 development 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 Thu, Sep 20, 2012 at 10:53 AM, Jean Guyader <jean.guyader@gmail.com> wrote:
> Hi George,
>
> Maybe we could had V4V in the list.
>
> * V4V: Inter-domain communication
>   owner (Xen): jean.guyader@citrix.com
>   status (Xen): patches submitted
>   owner (Linux driver):  stefano.panella@citrix
>   status (Linux driver): in progress

Added.

Just as an aside, in the future, could you trim the quotes from the
reply?  Since I use gmail it doesn't bother me much, but many other
people have complained about having to scroll through hundreds of
lines of quote to get to the new message part. :-)

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 20 11:21:17 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Sep 2012 11:21:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TEeof-0001MN-Me; Thu, 20 Sep 2012 11:21:09 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dave.martin@linaro.org>) id 1TEeod-0001M8-Kq
	for xen-devel@lists.xensource.com; Thu, 20 Sep 2012 11:21:07 +0000
Received: from [85.158.137.99:23251] by server-6.bemta-3.messagelabs.com id
	34/25-29694-22CFA505; Thu, 20 Sep 2012 11:21:06 +0000
X-Env-Sender: dave.martin@linaro.org
X-Msg-Ref: server-10.tower-217.messagelabs.com!1348140066!18458923!1
X-Originating-IP: [74.125.83.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3609 invoked from network); 20 Sep 2012 11:21:06 -0000
Received: from mail-ee0-f43.google.com (HELO mail-ee0-f43.google.com)
	(74.125.83.43)
	by server-10.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Sep 2012 11:21:06 -0000
Received: by eekd4 with SMTP id d4so909869eek.30
	for <xen-devel@lists.xensource.com>;
	Thu, 20 Sep 2012 04:21:06 -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=v4f9YXY+Q6/gzF7qzKPetPiUsM9MflI6FKoB9mryWJ4=;
	b=RhYDt7yZPjKPxhenuVjNks5ILu5hdhvX0LOlzWSxZzltMF3QBWNmHk/2ymsE2IKaFk
	ZoytTGa2t0/AVd8A3hpmNqja3X5AyI8jo63qAjYYXsh5dsIogBr7Ya15UH44HojQEQ2/
	laRJ9WsigS26aYrcoQwIKnbaDnnNQSBN2Y3ymP91qD5VaNcNnDbf2TpPzqckBpI7Coie
	Hu149pVa+1Pe3LVDc46xpmpFA99Gfygi6WyDjHKvqEX7AmovZJT5HpVh42ONWNKQId+8
	Vtk2lfJvDhuELF+KCYpiu1CwOgdcBSu8HhF4ySPETJF5F1tCSpVyi539tS5pqXvksfQ2
	CwZQ==
Received: by 10.14.173.131 with SMTP id v3mr1788264eel.15.1348140065880;
	Thu, 20 Sep 2012 04:21:05 -0700 (PDT)
Received: from linaro.org (fw-lnat.cambridge.arm.com. [217.140.96.63])
	by mx.google.com with ESMTPS id a7sm14733198eep.14.2012.09.20.04.21.04
	(version=SSLv3 cipher=OTHER); Thu, 20 Sep 2012 04:21:05 -0700 (PDT)
Date: Thu, 20 Sep 2012 12:21:02 +0100
From: Dave Martin <dave.martin@linaro.org>
To: David Vrabel <david.vrabel@citrix.com>
Message-ID: <20120920112102.GD2117@linaro.org>
References: <1348076658-4511-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<505AF3E5.1050306@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <505AF3E5.1050306@citrix.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Gm-Message-State: ALoCoQkiGmITrPxWtGJWe3jSNIL59R965qG7lAy4bPXUfJMySK0120rqytCt4foiTTrqXFKPNpsB
Cc: xen-devel@lists.xensource.com, Ian.Campbell@citrix.com,
	Pawel Moll <pawel.moll@arm.com>, konrad.wilk@oracle.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org
Subject: Re: [Xen-devel] [PATCH] arm: introduce a DTS for Xen unprivileged
 virtual 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 Thu, Sep 20, 2012 at 11:45:57AM +0100, David Vrabel wrote:
> On 19/09/12 18:44, Stefano Stabellini wrote:
> > --- /dev/null
> > +++ b/arch/arm/boot/dts/vexpress-xenvm-4.2.dts
> 
> Does this make sense?  There is no fixed configuration for VMs.
> 
> Is the intention to pass a DTS to the toolstack for it to create the VM
> with the appropriate amount of memory and peripheral mapped to the right
> place etc?  Or is the toolstack going to create the VM and generate the
> DTB from (e.g.,) an xl VM configuration file.
> 
> > +
> > +	hypervisor {
> > +		compatible = "xen,xen-4.2", "xen,xen";
> > +		reg = <0xb0000000 0x20000>;
> > +		interrupts = <1 15 0xf08>;
> > +	};
> 
> This node needs to be generated by the toolstack as only it knows what
> ABI the hypervisor has.

That's a good point: the same applies to the command line.  The toolstack
knows where the console and root device should be etc.: the kernel itself
shouldn't have static defaults for those.

Cheers
---Dave

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 20 11:21:17 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Sep 2012 11:21:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TEeof-0001MN-Me; Thu, 20 Sep 2012 11:21:09 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dave.martin@linaro.org>) id 1TEeod-0001M8-Kq
	for xen-devel@lists.xensource.com; Thu, 20 Sep 2012 11:21:07 +0000
Received: from [85.158.137.99:23251] by server-6.bemta-3.messagelabs.com id
	34/25-29694-22CFA505; Thu, 20 Sep 2012 11:21:06 +0000
X-Env-Sender: dave.martin@linaro.org
X-Msg-Ref: server-10.tower-217.messagelabs.com!1348140066!18458923!1
X-Originating-IP: [74.125.83.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3609 invoked from network); 20 Sep 2012 11:21:06 -0000
Received: from mail-ee0-f43.google.com (HELO mail-ee0-f43.google.com)
	(74.125.83.43)
	by server-10.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Sep 2012 11:21:06 -0000
Received: by eekd4 with SMTP id d4so909869eek.30
	for <xen-devel@lists.xensource.com>;
	Thu, 20 Sep 2012 04:21:06 -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=v4f9YXY+Q6/gzF7qzKPetPiUsM9MflI6FKoB9mryWJ4=;
	b=RhYDt7yZPjKPxhenuVjNks5ILu5hdhvX0LOlzWSxZzltMF3QBWNmHk/2ymsE2IKaFk
	ZoytTGa2t0/AVd8A3hpmNqja3X5AyI8jo63qAjYYXsh5dsIogBr7Ya15UH44HojQEQ2/
	laRJ9WsigS26aYrcoQwIKnbaDnnNQSBN2Y3ymP91qD5VaNcNnDbf2TpPzqckBpI7Coie
	Hu149pVa+1Pe3LVDc46xpmpFA99Gfygi6WyDjHKvqEX7AmovZJT5HpVh42ONWNKQId+8
	Vtk2lfJvDhuELF+KCYpiu1CwOgdcBSu8HhF4ySPETJF5F1tCSpVyi539tS5pqXvksfQ2
	CwZQ==
Received: by 10.14.173.131 with SMTP id v3mr1788264eel.15.1348140065880;
	Thu, 20 Sep 2012 04:21:05 -0700 (PDT)
Received: from linaro.org (fw-lnat.cambridge.arm.com. [217.140.96.63])
	by mx.google.com with ESMTPS id a7sm14733198eep.14.2012.09.20.04.21.04
	(version=SSLv3 cipher=OTHER); Thu, 20 Sep 2012 04:21:05 -0700 (PDT)
Date: Thu, 20 Sep 2012 12:21:02 +0100
From: Dave Martin <dave.martin@linaro.org>
To: David Vrabel <david.vrabel@citrix.com>
Message-ID: <20120920112102.GD2117@linaro.org>
References: <1348076658-4511-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<505AF3E5.1050306@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <505AF3E5.1050306@citrix.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Gm-Message-State: ALoCoQkiGmITrPxWtGJWe3jSNIL59R965qG7lAy4bPXUfJMySK0120rqytCt4foiTTrqXFKPNpsB
Cc: xen-devel@lists.xensource.com, Ian.Campbell@citrix.com,
	Pawel Moll <pawel.moll@arm.com>, konrad.wilk@oracle.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org
Subject: Re: [Xen-devel] [PATCH] arm: introduce a DTS for Xen unprivileged
 virtual 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 Thu, Sep 20, 2012 at 11:45:57AM +0100, David Vrabel wrote:
> On 19/09/12 18:44, Stefano Stabellini wrote:
> > --- /dev/null
> > +++ b/arch/arm/boot/dts/vexpress-xenvm-4.2.dts
> 
> Does this make sense?  There is no fixed configuration for VMs.
> 
> Is the intention to pass a DTS to the toolstack for it to create the VM
> with the appropriate amount of memory and peripheral mapped to the right
> place etc?  Or is the toolstack going to create the VM and generate the
> DTB from (e.g.,) an xl VM configuration file.
> 
> > +
> > +	hypervisor {
> > +		compatible = "xen,xen-4.2", "xen,xen";
> > +		reg = <0xb0000000 0x20000>;
> > +		interrupts = <1 15 0xf08>;
> > +	};
> 
> This node needs to be generated by the toolstack as only it knows what
> ABI the hypervisor has.

That's a good point: the same applies to the command line.  The toolstack
knows where the console and root device should be etc.: the kernel itself
shouldn't have static defaults for those.

Cheers
---Dave

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 20 11:23:51 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Sep 2012 11:23:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TEer7-0001YJ-Au; Thu, 20 Sep 2012 11:23:41 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <avi@redhat.com>) id 1TEer6-0001YC-Cj
	for xen-devel@lists.xen.org; Thu, 20 Sep 2012 11:23:40 +0000
Received: from [85.158.143.35:61986] by server-3.bemta-4.messagelabs.com id
	03/3A-10986-BBCFA505; Thu, 20 Sep 2012 11:23:39 +0000
X-Env-Sender: avi@redhat.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1348140218!7371828!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTY5NzI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7289 invoked from network); 20 Sep 2012 11:23:38 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-4.tower-21.messagelabs.com with SMTP;
	20 Sep 2012 11:23:38 -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 q8KBNaJ5031080
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 20 Sep 2012 07:23:36 -0400
Received: from balrog.usersys.tlv.redhat.com (dhcp-4-121.tlv.redhat.com
	[10.35.4.121])
	by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP
	id q8KBNWxa013690; Thu, 20 Sep 2012 07:23:33 -0400
Message-ID: <505AFCB4.2000401@redhat.com>
Date: Thu, 20 Sep 2012 14:23:32 +0300
From: Avi Kivity <avi@redhat.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120828 Thunderbird/15.0
MIME-Version: 1.0
To: Anthony PERARD <anthony.perard@citrix.com>
References: <1348139574-23324-1-git-send-email-anthony.perard@citrix.com>
	<1348139574-23324-4-git-send-email-anthony.perard@citrix.com>
In-Reply-To: <1348139574-23324-4-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>,
	Luiz Capitulino <lcapitulino@redhat.com>,
	Stefano Stabellini <stefano.stabellini@citrix.com>,
	QEMU-devel <qemu-devel@nongnu.org>, Xen Devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH V3 3/5] exec: Introduce helper to set dirty
	flags.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 09/20/2012 02:12 PM, Anthony PERARD wrote:
> This new helper/hook is used in the next patch to add an extra call in a single
> place.
> 

Reviewed-by: Avi Kivity <avi@redhat.com>


-- 
error compiling committee.c: too many arguments to function

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 20 11:23:51 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Sep 2012 11:23:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TEer7-0001YJ-Au; Thu, 20 Sep 2012 11:23:41 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <avi@redhat.com>) id 1TEer6-0001YC-Cj
	for xen-devel@lists.xen.org; Thu, 20 Sep 2012 11:23:40 +0000
Received: from [85.158.143.35:61986] by server-3.bemta-4.messagelabs.com id
	03/3A-10986-BBCFA505; Thu, 20 Sep 2012 11:23:39 +0000
X-Env-Sender: avi@redhat.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1348140218!7371828!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTY5NzI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7289 invoked from network); 20 Sep 2012 11:23:38 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-4.tower-21.messagelabs.com with SMTP;
	20 Sep 2012 11:23:38 -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 q8KBNaJ5031080
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 20 Sep 2012 07:23:36 -0400
Received: from balrog.usersys.tlv.redhat.com (dhcp-4-121.tlv.redhat.com
	[10.35.4.121])
	by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP
	id q8KBNWxa013690; Thu, 20 Sep 2012 07:23:33 -0400
Message-ID: <505AFCB4.2000401@redhat.com>
Date: Thu, 20 Sep 2012 14:23:32 +0300
From: Avi Kivity <avi@redhat.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120828 Thunderbird/15.0
MIME-Version: 1.0
To: Anthony PERARD <anthony.perard@citrix.com>
References: <1348139574-23324-1-git-send-email-anthony.perard@citrix.com>
	<1348139574-23324-4-git-send-email-anthony.perard@citrix.com>
In-Reply-To: <1348139574-23324-4-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>,
	Luiz Capitulino <lcapitulino@redhat.com>,
	Stefano Stabellini <stefano.stabellini@citrix.com>,
	QEMU-devel <qemu-devel@nongnu.org>, Xen Devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH V3 3/5] exec: Introduce helper to set dirty
	flags.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 09/20/2012 02:12 PM, Anthony PERARD wrote:
> This new helper/hook is used in the next patch to add an extra call in a single
> place.
> 

Reviewed-by: Avi Kivity <avi@redhat.com>


-- 
error compiling committee.c: too many arguments to function

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 20 11:26:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Sep 2012 11:26:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TEetQ-0001hJ-SW; Thu, 20 Sep 2012 11:26:04 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1TEetP-0001hB-Mr
	for xen-devel@lists.xen.org; Thu, 20 Sep 2012 11:26:03 +0000
Received: from [85.158.139.83:5872] by server-5.bemta-5.messagelabs.com id
	C4/6C-30514-A4DFA505; Thu, 20 Sep 2012 11:26:02 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1348140361!27413579!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30043 invoked from network); 20 Sep 2012 11:26:01 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-7.tower-182.messagelabs.com with SMTP;
	20 Sep 2012 11:26:01 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 20 Sep 2012 12:26:02 +0100
Message-Id: <505B197D020000780009C9FB@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 20 Sep 2012 12:26:21 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "George Dunlap" <George.Dunlap@eu.citrix.com>
References: <CAFLBxZYtmJ_bKFb90r45=C4Pq1-oe5Fy=eygSsQf4BcGj3EqGA@mail.gmail.com>
	<505ADBCF020000780009C7BE@nat28.tlf.novell.com>
	<CAFLBxZZAYBjYxX4K_LBE+dvkH8D9rfeAy538n4ACcQr=+bew8g@mail.gmail.com>
In-Reply-To: <CAFLBxZZAYBjYxX4K_LBE+dvkH8D9rfeAy538n4ACcQr=+bew8g@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Xen 4.3 development 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 20.09.12 at 13:17, George Dunlap <George.Dunlap@eu.citrix.com> wrote:
> On Thu, Sep 20, 2012 at 8:03 AM, Jan Beulich <JBeulich@suse.com> wrote:
>>>>> On 19.09.12 at 18:58, George Dunlap <George.Dunlap@eu.citrix.com> wrote:
>>> = Timeline =
>>>
>>> We are planning on a 9-month release cycle.  Based on that, below are
>>> our estimated dates:
>>> * Feature Freeze: 1 March, 2013
>>> * First RC: 15 April 2013
>>> * Release: 1 June 2013
>>
>> While it's only slightly over two weeks - didn't we agree to count
>> from the release date (rather than the intended one)?
> 
> So we did.  And if we actually do 6 weeks for each milestone, that gives us:
> 
> * Feature Freeze: 25 March 2013
> * First RC: 6 May 2013
> * Release: 17 June 2013
> 
> Sound reasonable?

Absolutely.

>>> * Persistent grants
>>>   owner: @citrix
>>>   status: ?
>>
>> Isn't that a guest side only thing (i.e. not really to be tracked
>> here)? Or does that mean migrating active grants?
> 
> It is a bit funny to have Linux-side stuff tracked here, since it has
> its own release schedule; but there's not really a better place to
> track it.  For both a "look at the great stuff happening" aspect, and
> a "what needs to be done and who is going to do it when" aspect,
> having all of the various development activities in one place is an
> advantage.

Understood.

>>>   -xHCI debug port
>>
>> This one needs an owner having access to suitable hardware _and_
>> knowledge of the protocol since, other than for EHCI, there isn't
>> even a reference implementation (e.g. in Linux) to clone from. I'd
>> therefore rather consider this nice-to-have than a firm plan to have
>> such functionality.
>>
>>>   -Firewire
>>
>> Largely same here - while I'm not suffering from lack of hardware
>> (apart from - afaict - cables), I've never done anything with
>> Firewire, and hence would consider this one as well nice-to-have
>> only.
> 
> "Nice-to-have" vs "blocker" is more something that will need to be
> considered near the feature freeze.  There are a handful of things
> that the Citrix team, internally, have deemed "critical" -- that is,
> if they seem to be in danger of missing, we will divert resources in
> order to help them make 4.3; but other than those, I think basically
> all the features in this list would be "nice-to-have".
> 
> Perhaps what we really need is a way to track the probability of
> success, so that those who want a particular feature to make it in can
> take action if they need to; for example:
> * Green: Owned, and no reason to think it won't make it in
> * Yellow: At-risk; may need intervention to make it in
> * Red: High probability of failure; possibly avert-able by immediate action
> * Grey: Not owned, or something blocking; but no reason it couldn't
> make it in if someone picks it up
> * Black: Very unlikely to make it in; expected to be held off until
> next release.
> 
> So in this scheme, the xHCI and Firewire would be "grey" -- no reason
> to think they couldn't make it by the deadline, but it's blocked on
> something.
> 
> Or, maybe that's more than we need at the moment. :-)  Thoughts?

Indeed this might be more than we want/need. With my response
I just wanted to clarify that while I would like to see these two things
to happen, it's unlikely that I'm going to be able to do anything about
them for the time being (so listing them as un-owned rather than
owned by me would presumably be the better choice).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 20 11:26:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Sep 2012 11:26:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TEetQ-0001hJ-SW; Thu, 20 Sep 2012 11:26:04 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1TEetP-0001hB-Mr
	for xen-devel@lists.xen.org; Thu, 20 Sep 2012 11:26:03 +0000
Received: from [85.158.139.83:5872] by server-5.bemta-5.messagelabs.com id
	C4/6C-30514-A4DFA505; Thu, 20 Sep 2012 11:26:02 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1348140361!27413579!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30043 invoked from network); 20 Sep 2012 11:26:01 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-7.tower-182.messagelabs.com with SMTP;
	20 Sep 2012 11:26:01 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 20 Sep 2012 12:26:02 +0100
Message-Id: <505B197D020000780009C9FB@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 20 Sep 2012 12:26:21 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "George Dunlap" <George.Dunlap@eu.citrix.com>
References: <CAFLBxZYtmJ_bKFb90r45=C4Pq1-oe5Fy=eygSsQf4BcGj3EqGA@mail.gmail.com>
	<505ADBCF020000780009C7BE@nat28.tlf.novell.com>
	<CAFLBxZZAYBjYxX4K_LBE+dvkH8D9rfeAy538n4ACcQr=+bew8g@mail.gmail.com>
In-Reply-To: <CAFLBxZZAYBjYxX4K_LBE+dvkH8D9rfeAy538n4ACcQr=+bew8g@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Xen 4.3 development 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 20.09.12 at 13:17, George Dunlap <George.Dunlap@eu.citrix.com> wrote:
> On Thu, Sep 20, 2012 at 8:03 AM, Jan Beulich <JBeulich@suse.com> wrote:
>>>>> On 19.09.12 at 18:58, George Dunlap <George.Dunlap@eu.citrix.com> wrote:
>>> = Timeline =
>>>
>>> We are planning on a 9-month release cycle.  Based on that, below are
>>> our estimated dates:
>>> * Feature Freeze: 1 March, 2013
>>> * First RC: 15 April 2013
>>> * Release: 1 June 2013
>>
>> While it's only slightly over two weeks - didn't we agree to count
>> from the release date (rather than the intended one)?
> 
> So we did.  And if we actually do 6 weeks for each milestone, that gives us:
> 
> * Feature Freeze: 25 March 2013
> * First RC: 6 May 2013
> * Release: 17 June 2013
> 
> Sound reasonable?

Absolutely.

>>> * Persistent grants
>>>   owner: @citrix
>>>   status: ?
>>
>> Isn't that a guest side only thing (i.e. not really to be tracked
>> here)? Or does that mean migrating active grants?
> 
> It is a bit funny to have Linux-side stuff tracked here, since it has
> its own release schedule; but there's not really a better place to
> track it.  For both a "look at the great stuff happening" aspect, and
> a "what needs to be done and who is going to do it when" aspect,
> having all of the various development activities in one place is an
> advantage.

Understood.

>>>   -xHCI debug port
>>
>> This one needs an owner having access to suitable hardware _and_
>> knowledge of the protocol since, other than for EHCI, there isn't
>> even a reference implementation (e.g. in Linux) to clone from. I'd
>> therefore rather consider this nice-to-have than a firm plan to have
>> such functionality.
>>
>>>   -Firewire
>>
>> Largely same here - while I'm not suffering from lack of hardware
>> (apart from - afaict - cables), I've never done anything with
>> Firewire, and hence would consider this one as well nice-to-have
>> only.
> 
> "Nice-to-have" vs "blocker" is more something that will need to be
> considered near the feature freeze.  There are a handful of things
> that the Citrix team, internally, have deemed "critical" -- that is,
> if they seem to be in danger of missing, we will divert resources in
> order to help them make 4.3; but other than those, I think basically
> all the features in this list would be "nice-to-have".
> 
> Perhaps what we really need is a way to track the probability of
> success, so that those who want a particular feature to make it in can
> take action if they need to; for example:
> * Green: Owned, and no reason to think it won't make it in
> * Yellow: At-risk; may need intervention to make it in
> * Red: High probability of failure; possibly avert-able by immediate action
> * Grey: Not owned, or something blocking; but no reason it couldn't
> make it in if someone picks it up
> * Black: Very unlikely to make it in; expected to be held off until
> next release.
> 
> So in this scheme, the xHCI and Firewire would be "grey" -- no reason
> to think they couldn't make it by the deadline, but it's blocked on
> something.
> 
> Or, maybe that's more than we need at the moment. :-)  Thoughts?

Indeed this might be more than we want/need. With my response
I just wanted to clarify that while I would like to see these two things
to happen, it's unlikely that I'm going to be able to do anything about
them for the time being (so listing them as un-owned rather than
owned by me would presumably be the better choice).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 20 11:31:35 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Sep 2012 11:31:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TEeya-0001tF-90; Thu, 20 Sep 2012 11:31:24 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <oliver.chick@citrix.com>) id 1TEeyY-0001t1-Ns
	for xen-devel@lists.xen.org; Thu, 20 Sep 2012 11:31:22 +0000
X-Env-Sender: oliver.chick@citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1348140664!4051430!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTA0NTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13737 invoked from network); 20 Sep 2012 11:31: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;
	20 Sep 2012 11:31:05 -0000
X-IronPort-AV: E=Sophos;i="4.80,453,1344211200"; d="scan'208";a="14653558"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Sep 2012 11:31:04 +0000
Received: from [10.80.2.50] (10.80.2.50) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Thu, 20 Sep 2012 12:31:04 +0100
Message-ID: <1348140637.24539.32.camel@oliverchick-Precision-WorkStation-T3400>
From: Oliver Chick <oliver.chick@citrix.com>
To: David Vrabel <david.vrabel@citrix.com>
Date: Thu, 20 Sep 2012 12:30:37 +0100
In-Reply-To: <505AF126.2050806@citrix.com>
References: <1348051887-21885-1-git-send-email-oliver.chick@citrix.com>
	<505AF126.2050806@citrix.com>
X-Mailer: Evolution 3.2.3-0ubuntu6 
MIME-Version: 1.0
Cc: "konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] Persistent grant maps for xen blk drivers
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

The memory overhead, and fallback mode points are related:
-Firstly, it turns out that the overhead is actually 2.75MB, not 11MB
per device. I made a mistake (pointed out by Jan) as the maximum number
of requests that can fit into a single-page ring is 64, not 256.
-Clearly, this still scales linearly. So the problem of memory footprint
will occur with more VMs, or block devices.
-Whilst 2.75MB per device is probably acceptable (?), if we start using
multipage rings, then we might not want to have
BLKIF_MAX_PERS_REQUESTS_PER_DEVICE==__RING_SIZE, as this will cause the
memory overhead to increase. This is why I have implemented the
'fallback' mode. With a multipage ring, it seems reasonable to want the
first $x$ grefs seen by blkback to be treated as persistent, and any
later ones to be non-persistent. Does that seem sensible?


On Thu, 2012-09-20 at 11:34 +0100, David Vrabel wrote:
> On 19/09/12 11:51, Oliver Chick wrote:
> > This patch implements persistent grants for the xen-blk{front,back}
> > mechanism.
> [...]
> > We (ijc, and myself) have introduced a new constant,
> > BLKIF_MAX_PERS_REQUESTS_PER_DEV. This is to prevent a malicious guest
> > from attempting a DoS, by supplying fresh grefs, causing the Dom0
> > kernel from to map excessively. 
> [...]
> > 2) Otherwise, we revert to non-persistent grants for all future grefs.
> 
> Why fallback instead of immediately failing the request?
> > diff --git a/drivers/block/xen-blkback/blkback.c b/drivers/block/xen-blkback/blkback.c
> > index 73f196c..f95dee9 100644
> > --- a/drivers/block/xen-blkback/blkback.c
> > +++ b/drivers/block/xen-blkback/blkback.c
> > @@ -78,6 +78,7 @@ struct pending_req {
> >  	unsigned short		operation;
> >  	int			status;
> >  	struct list_head	free_list;
> > +	u8			is_pers;
> 
> Using "pers" as an abbreviation for "persistent" isn't obvious.  For
> readability it may be better spell it in full.
> 
Good point

> > +/*
> > + * Maximum number of persistent grants that can be mapped by Dom0 for each
> > + * interface. This is set to be the size of the ring, as this is a limit on
> > + * the number of requests that can be inflight at any one time. 256 imposes
> > + * an overhead of 11MB of mapped kernel space per interface.
> > + */
> > +#define BLKIF_MAX_PERS_REQUESTS_PER_DEV 256
> 
> This 11MB per VBD seems like a lot.  With 150 VMs each with 2 VBDs this
> requires > 3 GB.  Is this a scalability problem?


> 
> Does there need to be a mechanism to expire old maps in blkback?


When blkback closes, I unmap. Or do you mean that I could unmap if there
has been a spike in block-device activity, after which the mapped pages
are not getting used?
> 
> David



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 20 11:31:35 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Sep 2012 11:31:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TEeya-0001tF-90; Thu, 20 Sep 2012 11:31:24 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <oliver.chick@citrix.com>) id 1TEeyY-0001t1-Ns
	for xen-devel@lists.xen.org; Thu, 20 Sep 2012 11:31:22 +0000
X-Env-Sender: oliver.chick@citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1348140664!4051430!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTA0NTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13737 invoked from network); 20 Sep 2012 11:31: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;
	20 Sep 2012 11:31:05 -0000
X-IronPort-AV: E=Sophos;i="4.80,453,1344211200"; d="scan'208";a="14653558"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Sep 2012 11:31:04 +0000
Received: from [10.80.2.50] (10.80.2.50) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Thu, 20 Sep 2012 12:31:04 +0100
Message-ID: <1348140637.24539.32.camel@oliverchick-Precision-WorkStation-T3400>
From: Oliver Chick <oliver.chick@citrix.com>
To: David Vrabel <david.vrabel@citrix.com>
Date: Thu, 20 Sep 2012 12:30:37 +0100
In-Reply-To: <505AF126.2050806@citrix.com>
References: <1348051887-21885-1-git-send-email-oliver.chick@citrix.com>
	<505AF126.2050806@citrix.com>
X-Mailer: Evolution 3.2.3-0ubuntu6 
MIME-Version: 1.0
Cc: "konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] Persistent grant maps for xen blk drivers
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

The memory overhead, and fallback mode points are related:
-Firstly, it turns out that the overhead is actually 2.75MB, not 11MB
per device. I made a mistake (pointed out by Jan) as the maximum number
of requests that can fit into a single-page ring is 64, not 256.
-Clearly, this still scales linearly. So the problem of memory footprint
will occur with more VMs, or block devices.
-Whilst 2.75MB per device is probably acceptable (?), if we start using
multipage rings, then we might not want to have
BLKIF_MAX_PERS_REQUESTS_PER_DEVICE==__RING_SIZE, as this will cause the
memory overhead to increase. This is why I have implemented the
'fallback' mode. With a multipage ring, it seems reasonable to want the
first $x$ grefs seen by blkback to be treated as persistent, and any
later ones to be non-persistent. Does that seem sensible?


On Thu, 2012-09-20 at 11:34 +0100, David Vrabel wrote:
> On 19/09/12 11:51, Oliver Chick wrote:
> > This patch implements persistent grants for the xen-blk{front,back}
> > mechanism.
> [...]
> > We (ijc, and myself) have introduced a new constant,
> > BLKIF_MAX_PERS_REQUESTS_PER_DEV. This is to prevent a malicious guest
> > from attempting a DoS, by supplying fresh grefs, causing the Dom0
> > kernel from to map excessively. 
> [...]
> > 2) Otherwise, we revert to non-persistent grants for all future grefs.
> 
> Why fallback instead of immediately failing the request?
> > diff --git a/drivers/block/xen-blkback/blkback.c b/drivers/block/xen-blkback/blkback.c
> > index 73f196c..f95dee9 100644
> > --- a/drivers/block/xen-blkback/blkback.c
> > +++ b/drivers/block/xen-blkback/blkback.c
> > @@ -78,6 +78,7 @@ struct pending_req {
> >  	unsigned short		operation;
> >  	int			status;
> >  	struct list_head	free_list;
> > +	u8			is_pers;
> 
> Using "pers" as an abbreviation for "persistent" isn't obvious.  For
> readability it may be better spell it in full.
> 
Good point

> > +/*
> > + * Maximum number of persistent grants that can be mapped by Dom0 for each
> > + * interface. This is set to be the size of the ring, as this is a limit on
> > + * the number of requests that can be inflight at any one time. 256 imposes
> > + * an overhead of 11MB of mapped kernel space per interface.
> > + */
> > +#define BLKIF_MAX_PERS_REQUESTS_PER_DEV 256
> 
> This 11MB per VBD seems like a lot.  With 150 VMs each with 2 VBDs this
> requires > 3 GB.  Is this a scalability problem?


> 
> Does there need to be a mechanism to expire old maps in blkback?


When blkback closes, I unmap. Or do you mean that I could unmap if there
has been a spike in block-device activity, after which the mapped pages
are not getting used?
> 
> David



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 20 11:38:09 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Sep 2012 11: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 1TEf4x-0002I1-5f; Thu, 20 Sep 2012 11:37:59 +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 1TEf4v-0002Ht-WE
	for xen-devel@lists.xen.org; Thu, 20 Sep 2012 11:37:58 +0000
Received: from [85.158.139.83:28891] by server-6.bemta-5.messagelabs.com id
	94/CD-21336-5100B505; Thu, 20 Sep 2012 11:37:57 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1348141075!24154821!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNzYxMzI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8864 invoked from network); 20 Sep 2012 11:37:56 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-11.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Sep 2012 11:37:56 -0000
X-IronPort-AV: E=Sophos;i="4.80,453,1344211200"; d="scan'208";a="208678294"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Sep 2012 11:37:54 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Thu, 20 Sep 2012 07:37: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 1TEf4r-0006vf-OU;
	Thu, 20 Sep 2012 12:37:53 +0100
Message-ID: <505AFF10.7060107@eu.citrix.com>
Date: Thu, 20 Sep 2012 12:33:36 +0100
From: George Dunlap <george.dunlap@eu.citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:14.0) Gecko/20120714 Thunderbird/14.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <CAFLBxZYtmJ_bKFb90r45=C4Pq1-oe5Fy=eygSsQf4BcGj3EqGA@mail.gmail.com>
	<505ADBCF020000780009C7BE@nat28.tlf.novell.com>
	<CAFLBxZZAYBjYxX4K_LBE+dvkH8D9rfeAy538n4ACcQr=+bew8g@mail.gmail.com>
	<505B197D020000780009C9FB@nat28.tlf.novell.com>
In-Reply-To: <505B197D020000780009C9FB@nat28.tlf.novell.com>
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.3 development 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-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 20/09/12 12:26, Jan Beulich wrote:
>
> Indeed this might be more than we want/need. With my response
> I just wanted to clarify that while I would like to see these two things
> to happen, it's unlikely that I'm going to be able to do anything about
> them for the time being (so listing them as un-owned rather than
> owned by me would presumably be the better choice).
Right -- well they were added to the list because you said you were 
going to be working on them; so if you're not, shall I just take them off?

  -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 20 11:38:09 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Sep 2012 11: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 1TEf4x-0002I1-5f; Thu, 20 Sep 2012 11:37:59 +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 1TEf4v-0002Ht-WE
	for xen-devel@lists.xen.org; Thu, 20 Sep 2012 11:37:58 +0000
Received: from [85.158.139.83:28891] by server-6.bemta-5.messagelabs.com id
	94/CD-21336-5100B505; Thu, 20 Sep 2012 11:37:57 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1348141075!24154821!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNzYxMzI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8864 invoked from network); 20 Sep 2012 11:37:56 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-11.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Sep 2012 11:37:56 -0000
X-IronPort-AV: E=Sophos;i="4.80,453,1344211200"; d="scan'208";a="208678294"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Sep 2012 11:37:54 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Thu, 20 Sep 2012 07:37: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 1TEf4r-0006vf-OU;
	Thu, 20 Sep 2012 12:37:53 +0100
Message-ID: <505AFF10.7060107@eu.citrix.com>
Date: Thu, 20 Sep 2012 12:33:36 +0100
From: George Dunlap <george.dunlap@eu.citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:14.0) Gecko/20120714 Thunderbird/14.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <CAFLBxZYtmJ_bKFb90r45=C4Pq1-oe5Fy=eygSsQf4BcGj3EqGA@mail.gmail.com>
	<505ADBCF020000780009C7BE@nat28.tlf.novell.com>
	<CAFLBxZZAYBjYxX4K_LBE+dvkH8D9rfeAy538n4ACcQr=+bew8g@mail.gmail.com>
	<505B197D020000780009C9FB@nat28.tlf.novell.com>
In-Reply-To: <505B197D020000780009C9FB@nat28.tlf.novell.com>
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.3 development 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-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 20/09/12 12:26, Jan Beulich wrote:
>
> Indeed this might be more than we want/need. With my response
> I just wanted to clarify that while I would like to see these two things
> to happen, it's unlikely that I'm going to be able to do anything about
> them for the time being (so listing them as un-owned rather than
> owned by me would presumably be the better choice).
Right -- well they were added to the list because you said you were 
going to be working on them; so if you're not, shall I just take them off?

  -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 20 11:40:24 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Sep 2012 11: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 1TEf74-0002Pp-N4; Thu, 20 Sep 2012 11:40:10 +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 1TEf73-0002Pg-SD
	for xen-devel@lists.xen.org; Thu, 20 Sep 2012 11:40:10 +0000
Received: from [85.158.139.211:43565] by server-6.bemta-5.messagelabs.com id
	00/D3-21336-9900B505; Thu, 20 Sep 2012 11:40:09 +0000
X-Env-Sender: jean.guyader@citrix.com
X-Msg-Ref: server-8.tower-206.messagelabs.com!1348141207!19290275!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTA0NTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30693 invoked from network); 20 Sep 2012 11:40:08 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Sep 2012 11:40:08 -0000
X-IronPort-AV: E=Sophos;i="4.80,453,1344211200"; d="scan'208";a="14653889"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Sep 2012 11:39: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.279.1; Thu, 20 Sep 2012 12:39:45 +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 1TEf6e-0001et-Jv;
	Thu, 20 Sep 2012 11:39:44 +0000
Received: by spongy (Postfix, from userid 2023)	id DD87B341ABD; Thu, 20 Sep
	2012 12:42:03 +0100 (BST)
From: Jean Guyader <jean.guyader@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Thu, 20 Sep 2012 12:41:59 +0100
Message-ID: <1348141322-28657-2-git-send-email-jean.guyader@citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <1348141322-28657-1-git-send-email-jean.guyader@citrix.com>
References: <1348141322-28657-1-git-send-email-jean.guyader@citrix.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="------------true"
Cc: tim@xen.org, JBeulich@suse.com
Subject: [Xen-devel] [PATCH 1/4] xen: 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: Jan Beulich <JBeulich@suse.com>
---
 xen/include/asm-x86/guest_access.h |    3 +++
 1 file changed, 3 insertions(+)


--------------true
Content-Type: text/x-patch;
	name="0001-xen-Introduce-guest_handle_for_field.patch"
Content-Disposition: attachment;
	filename="0001-xen-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 Sep 20 11:40:24 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Sep 2012 11: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 1TEf74-0002Pp-N4; Thu, 20 Sep 2012 11:40:10 +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 1TEf73-0002Pg-SD
	for xen-devel@lists.xen.org; Thu, 20 Sep 2012 11:40:10 +0000
Received: from [85.158.139.211:43565] by server-6.bemta-5.messagelabs.com id
	00/D3-21336-9900B505; Thu, 20 Sep 2012 11:40:09 +0000
X-Env-Sender: jean.guyader@citrix.com
X-Msg-Ref: server-8.tower-206.messagelabs.com!1348141207!19290275!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTA0NTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30693 invoked from network); 20 Sep 2012 11:40:08 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Sep 2012 11:40:08 -0000
X-IronPort-AV: E=Sophos;i="4.80,453,1344211200"; d="scan'208";a="14653889"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Sep 2012 11:39: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.279.1; Thu, 20 Sep 2012 12:39:45 +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 1TEf6e-0001et-Jv;
	Thu, 20 Sep 2012 11:39:44 +0000
Received: by spongy (Postfix, from userid 2023)	id DD87B341ABD; Thu, 20 Sep
	2012 12:42:03 +0100 (BST)
From: Jean Guyader <jean.guyader@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Thu, 20 Sep 2012 12:41:59 +0100
Message-ID: <1348141322-28657-2-git-send-email-jean.guyader@citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <1348141322-28657-1-git-send-email-jean.guyader@citrix.com>
References: <1348141322-28657-1-git-send-email-jean.guyader@citrix.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="------------true"
Cc: tim@xen.org, JBeulich@suse.com
Subject: [Xen-devel] [PATCH 1/4] xen: 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: Jan Beulich <JBeulich@suse.com>
---
 xen/include/asm-x86/guest_access.h |    3 +++
 1 file changed, 3 insertions(+)


--------------true
Content-Type: text/x-patch;
	name="0001-xen-Introduce-guest_handle_for_field.patch"
Content-Disposition: attachment;
	filename="0001-xen-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 Sep 20 11:40:24 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Sep 2012 11: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 1TEf76-0002Q2-3e; Thu, 20 Sep 2012 11:40:12 +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 1TEf74-0002Pg-HU
	for xen-devel@lists.xen.org; Thu, 20 Sep 2012 11:40:10 +0000
Received: from [85.158.139.211:40502] by server-6.bemta-5.messagelabs.com id
	C6/D3-21336-9900B505; Thu, 20 Sep 2012 11:40:09 +0000
X-Env-Sender: jean.guyader@citrix.com
X-Msg-Ref: server-8.tower-206.messagelabs.com!1348141207!19290275!2
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTA0NTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30755 invoked from network); 20 Sep 2012 11:40:09 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Sep 2012 11:40:09 -0000
X-IronPort-AV: E=Sophos;i="4.80,453,1344211200"; d="scan'208";a="14653947"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Sep 2012 11: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.279.1; Thu, 20 Sep 2012 12:39: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 1TEf6e-0001eq-Fo;
	Thu, 20 Sep 2012 11:39:44 +0000
Received: by spongy (Postfix, from userid 2023)	id B5A5534040D; Thu, 20 Sep
	2012 12:42:03 +0100 (BST)
From: Jean Guyader <jean.guyader@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Thu, 20 Sep 2012 12:41:58 +0100
Message-ID: <1348141322-28657-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: tim@xen.org, Jean Guyader <jean.guyader@citrix.com>, JBeulich@suse.com
Subject: [Xen-devel] [PATCH 0/4] Add V4V to Xen (v6)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<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

v6 changes:
        - Check compiler before using [0] or [].

v5 changes:
        - Fix prototypes in v4v.h for do_v4v_op
        - Add padding to make sure all the structures
          are 64 bits aligned
        - Replace [0] with []

v4 changes:
        - Stop using ssize_t, use long instead
        - Return -MSGSIZE for message bigger than 2GB
        - Fixup size handling
        - Rename protocol with message_type to avoid the
          confusion with the IP protocol flag
        - Replaced V4V_DOMID_ANY value with DOMID_INVALID
        - Replaced v4v_pfn_t with xen_pfn_t
        - Add padding to struct v4v_info
        - Fixup hypercall documentation
        - Move V4V_ROUNDUP to v4v.c
        - Remove v4v_utils.h (we could potentially add it later).

v3 changes:
        - Switch to event channel
                - Allocated a unbound event channel
                  per domain.
                - Add a new v4v call to share the
                  event channel port.
        - Public headers with actual type definition
        - Align all the v4v type to 64 bits
        - Modify v4v MAGIC numbers because we won't
          but backward compatible anymore
        - Merge insert and insertv
        - Merge send and sendv
        - Turn all the lock prerequisite from comment
          to ASSERT()
        - Make use or write_atomic instead of volatile pointers
        - Merge v4v_memcpy_to_guest_ring and
          v4v_memcpy_to_guest_ring_from_guest
                - Introduce copy_from_guest_maybe that can take
                  a void * and a handle as src address.
        - Replace 6 arguments hypercalls with 5 arguments hypercalls.

v2 changes:
        - Cleanup plugin header
        - Include basic access control
        - Use guest_handle_for_field

Jan Beulich (1):
  xen: Introduce guest_handle_for_field

Jean Guyader (3):
  xen: virq, remove VIRQ_XC_RESERVED
  xen: events, exposes evtchn_alloc_unbound_domain
  xen: Add V4V implementation

 xen/arch/x86/hvm/hvm.c             |    6 +-
 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                |   13 +-
 xen/common/event_channel.c         |   39 +-
 xen/common/v4v.c                   | 1905 ++++++++++++++++++++++++++++++=
++++++
 xen/include/asm-x86/guest_access.h |    3 +
 xen/include/public/v4v.h           |  324 ++++++
 xen/include/public/xen.h           |    3 +-
 xen/include/xen/event.h            |    3 +
 xen/include/xen/sched.h            |    4 +
 xen/include/xen/v4v.h              |  133 +++
 13 files changed, 2421 insertions(+), 17 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 Sep 20 11:40:24 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Sep 2012 11: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 1TEf76-0002Q2-3e; Thu, 20 Sep 2012 11:40:12 +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 1TEf74-0002Pg-HU
	for xen-devel@lists.xen.org; Thu, 20 Sep 2012 11:40:10 +0000
Received: from [85.158.139.211:40502] by server-6.bemta-5.messagelabs.com id
	C6/D3-21336-9900B505; Thu, 20 Sep 2012 11:40:09 +0000
X-Env-Sender: jean.guyader@citrix.com
X-Msg-Ref: server-8.tower-206.messagelabs.com!1348141207!19290275!2
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTA0NTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30755 invoked from network); 20 Sep 2012 11:40:09 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Sep 2012 11:40:09 -0000
X-IronPort-AV: E=Sophos;i="4.80,453,1344211200"; d="scan'208";a="14653947"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Sep 2012 11: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.279.1; Thu, 20 Sep 2012 12:39: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 1TEf6e-0001eq-Fo;
	Thu, 20 Sep 2012 11:39:44 +0000
Received: by spongy (Postfix, from userid 2023)	id B5A5534040D; Thu, 20 Sep
	2012 12:42:03 +0100 (BST)
From: Jean Guyader <jean.guyader@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Thu, 20 Sep 2012 12:41:58 +0100
Message-ID: <1348141322-28657-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: tim@xen.org, Jean Guyader <jean.guyader@citrix.com>, JBeulich@suse.com
Subject: [Xen-devel] [PATCH 0/4] Add V4V to Xen (v6)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<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

v6 changes:
        - Check compiler before using [0] or [].

v5 changes:
        - Fix prototypes in v4v.h for do_v4v_op
        - Add padding to make sure all the structures
          are 64 bits aligned
        - Replace [0] with []

v4 changes:
        - Stop using ssize_t, use long instead
        - Return -MSGSIZE for message bigger than 2GB
        - Fixup size handling
        - Rename protocol with message_type to avoid the
          confusion with the IP protocol flag
        - Replaced V4V_DOMID_ANY value with DOMID_INVALID
        - Replaced v4v_pfn_t with xen_pfn_t
        - Add padding to struct v4v_info
        - Fixup hypercall documentation
        - Move V4V_ROUNDUP to v4v.c
        - Remove v4v_utils.h (we could potentially add it later).

v3 changes:
        - Switch to event channel
                - Allocated a unbound event channel
                  per domain.
                - Add a new v4v call to share the
                  event channel port.
        - Public headers with actual type definition
        - Align all the v4v type to 64 bits
        - Modify v4v MAGIC numbers because we won't
          but backward compatible anymore
        - Merge insert and insertv
        - Merge send and sendv
        - Turn all the lock prerequisite from comment
          to ASSERT()
        - Make use or write_atomic instead of volatile pointers
        - Merge v4v_memcpy_to_guest_ring and
          v4v_memcpy_to_guest_ring_from_guest
                - Introduce copy_from_guest_maybe that can take
                  a void * and a handle as src address.
        - Replace 6 arguments hypercalls with 5 arguments hypercalls.

v2 changes:
        - Cleanup plugin header
        - Include basic access control
        - Use guest_handle_for_field

Jan Beulich (1):
  xen: Introduce guest_handle_for_field

Jean Guyader (3):
  xen: virq, remove VIRQ_XC_RESERVED
  xen: events, exposes evtchn_alloc_unbound_domain
  xen: Add V4V implementation

 xen/arch/x86/hvm/hvm.c             |    6 +-
 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                |   13 +-
 xen/common/event_channel.c         |   39 +-
 xen/common/v4v.c                   | 1905 ++++++++++++++++++++++++++++++=
++++++
 xen/include/asm-x86/guest_access.h |    3 +
 xen/include/public/v4v.h           |  324 ++++++
 xen/include/public/xen.h           |    3 +-
 xen/include/xen/event.h            |    3 +
 xen/include/xen/sched.h            |    4 +
 xen/include/xen/v4v.h              |  133 +++
 13 files changed, 2421 insertions(+), 17 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 Sep 20 11:40:25 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Sep 2012 11:40: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 1TEf7A-0002RE-Mn; Thu, 20 Sep 2012 11:40:16 +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 1TEf78-0002Pg-TC
	for xen-devel@lists.xen.org; Thu, 20 Sep 2012 11:40:15 +0000
Received: from [85.158.139.211:23379] by server-6.bemta-5.messagelabs.com id
	BF/04-21336-E900B505; Thu, 20 Sep 2012 11:40:14 +0000
X-Env-Sender: jean.guyader@citrix.com
X-Msg-Ref: server-8.tower-206.messagelabs.com!1348141207!19290275!3
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTA0NTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31028 invoked from network); 20 Sep 2012 11:40:13 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Sep 2012 11:40:13 -0000
X-IronPort-AV: E=Sophos;i="4.80,453,1344211200"; d="scan'208";a="14654007"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Sep 2012 11:39:58 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Thu, 20 Sep 2012 12:39:45 +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 1TEf6e-0001ew-PM;
	Thu, 20 Sep 2012 11:39:44 +0000
Received: by spongy (Postfix, from userid 2023)	id 0A86C34040D; Thu, 20 Sep
	2012 12:42:03 +0100 (BST)
From: Jean Guyader <jean.guyader@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Thu, 20 Sep 2012 12:42:00 +0100
Message-ID: <1348141322-28657-3-git-send-email-jean.guyader@citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <1348141322-28657-1-git-send-email-jean.guyader@citrix.com>
References: <1348141322-28657-1-git-send-email-jean.guyader@citrix.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="------------true"
Cc: tim@xen.org, Jean Guyader <jean.guyader@citrix.com>, JBeulich@suse.com
Subject: [Xen-devel] [PATCH 2/4] xen: virq, remove VIRQ_XC_RESERVED
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<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


VIRQ_XC_RESERVED was reserved for V4V but we have switched
to event channels so this place holder is no longer required.

Signed-off-by: Jean Guyader <jean.guyader@citrix.com>
---
 xen/include/public/xen.h |    1 -
 1 file changed, 1 deletion(-)


--------------true
Content-Type: text/x-patch;
	name="0002-xen-virq-remove-VIRQ_XC_RESERVED.patch"
Content-Disposition: attachment;
	filename="0002-xen-virq-remove-VIRQ_XC_RESERVED.patch"
Content-Transfer-Encoding: quoted-printable

diff --git a/xen/include/public/xen.h b/xen/include/public/xen.h
index 361398b..8def420 100644
--- a/xen/include/public/xen.h
+++ b/xen/include/public/xen.h
@@ -155,7 +155,6 @@ 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_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 Sep 20 11:40:25 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Sep 2012 11:40: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 1TEf7A-0002RE-Mn; Thu, 20 Sep 2012 11:40:16 +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 1TEf78-0002Pg-TC
	for xen-devel@lists.xen.org; Thu, 20 Sep 2012 11:40:15 +0000
Received: from [85.158.139.211:23379] by server-6.bemta-5.messagelabs.com id
	BF/04-21336-E900B505; Thu, 20 Sep 2012 11:40:14 +0000
X-Env-Sender: jean.guyader@citrix.com
X-Msg-Ref: server-8.tower-206.messagelabs.com!1348141207!19290275!3
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTA0NTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31028 invoked from network); 20 Sep 2012 11:40:13 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Sep 2012 11:40:13 -0000
X-IronPort-AV: E=Sophos;i="4.80,453,1344211200"; d="scan'208";a="14654007"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Sep 2012 11:39:58 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Thu, 20 Sep 2012 12:39:45 +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 1TEf6e-0001ew-PM;
	Thu, 20 Sep 2012 11:39:44 +0000
Received: by spongy (Postfix, from userid 2023)	id 0A86C34040D; Thu, 20 Sep
	2012 12:42:03 +0100 (BST)
From: Jean Guyader <jean.guyader@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Thu, 20 Sep 2012 12:42:00 +0100
Message-ID: <1348141322-28657-3-git-send-email-jean.guyader@citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <1348141322-28657-1-git-send-email-jean.guyader@citrix.com>
References: <1348141322-28657-1-git-send-email-jean.guyader@citrix.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="------------true"
Cc: tim@xen.org, Jean Guyader <jean.guyader@citrix.com>, JBeulich@suse.com
Subject: [Xen-devel] [PATCH 2/4] xen: virq, remove VIRQ_XC_RESERVED
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<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


VIRQ_XC_RESERVED was reserved for V4V but we have switched
to event channels so this place holder is no longer required.

Signed-off-by: Jean Guyader <jean.guyader@citrix.com>
---
 xen/include/public/xen.h |    1 -
 1 file changed, 1 deletion(-)


--------------true
Content-Type: text/x-patch;
	name="0002-xen-virq-remove-VIRQ_XC_RESERVED.patch"
Content-Disposition: attachment;
	filename="0002-xen-virq-remove-VIRQ_XC_RESERVED.patch"
Content-Transfer-Encoding: quoted-printable

diff --git a/xen/include/public/xen.h b/xen/include/public/xen.h
index 361398b..8def420 100644
--- a/xen/include/public/xen.h
+++ b/xen/include/public/xen.h
@@ -155,7 +155,6 @@ 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_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 Sep 20 11:40:29 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Sep 2012 11: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 1TEf7F-0002SY-3L; Thu, 20 Sep 2012 11:40:21 +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 1TEf7E-0002S1-3X
	for xen-devel@lists.xen.org; Thu, 20 Sep 2012 11:40:20 +0000
Received: from [85.158.139.211:41250] by server-11.bemta-5.messagelabs.com id
	AA/8C-24658-3A00B505; Thu, 20 Sep 2012 11:40:19 +0000
X-Env-Sender: jean.guyader@citrix.com
X-Msg-Ref: server-8.tower-206.messagelabs.com!1348141207!19290275!4
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTA0NTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31542 invoked from network); 20 Sep 2012 11:40:18 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Sep 2012 11:40:18 -0000
X-IronPort-AV: E=Sophos;i="4.80,453,1344211200"; d="scan'208";a="14654042"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Sep 2012 11:40: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.279.1; Thu, 20 Sep 2012 12:39:45 +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 1TEf6e-0001f0-VA;
	Thu, 20 Sep 2012 11:39:45 +0000
Received: by spongy (Postfix, from userid 2023)	id 33D27341ABD; Thu, 20 Sep
	2012 12:42:03 +0100 (BST)
From: Jean Guyader <jean.guyader@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Thu, 20 Sep 2012 12:42:01 +0100
Message-ID: <1348141322-28657-4-git-send-email-jean.guyader@citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <1348141322-28657-1-git-send-email-jean.guyader@citrix.com>
References: <1348141322-28657-1-git-send-email-jean.guyader@citrix.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="------------true"
Cc: tim@xen.org, Jean Guyader <jean.guyader@citrix.com>, JBeulich@suse.com
Subject: [Xen-devel] [PATCH 3/4] xen: events,
	exposes evtchn_alloc_unbound_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>
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


Exposes evtchn_alloc_unbound_domain to the rest of
Xen so we can create allocated unbound evtchn within Xen.

Signed-off-by: Jean Guyader <jean.guyader@citrix.com>
---
 xen/common/event_channel.c |   39 +++++++++++++++++++++++++++-----------=
-
 xen/include/xen/event.h    |    3 +++
 2 files changed, 30 insertions(+), 12 deletions(-)


--------------true
Content-Type: text/x-patch;
	name="0003-xen-events-exposes-evtchn_alloc_unbound_domain.patch"
Content-Disposition: attachment;
	filename="0003-xen-events-exposes-evtchn_alloc_unbound_domain.patch"
Content-Transfer-Encoding: quoted-printable

diff --git a/xen/common/event_channel.c b/xen/common/event_channel.c
index 53777f8..6a0e342 100644
--- a/xen/common/event_channel.c
+++ b/xen/common/event_channel.c
@@ -159,36 +159,51 @@ static int get_free_port(struct domain *d)
=20
 static long evtchn_alloc_unbound(evtchn_alloc_unbound_t *alloc)
 {
-    struct evtchn *chn;
     struct domain *d;
-    int            port;
-    domid_t        dom =3D alloc->dom;
     long           rc;
=20
-    rc =3D rcu_lock_target_domain_by_id(dom, &d);
+    rc =3D rcu_lock_target_domain_by_id(alloc->dom, &d);
     if ( rc )
         return rc;
=20
+    rc =3D evtchn_alloc_unbound_domain(d, &alloc->port, alloc->remote_do=
m);
+    if ( rc )
+        ERROR_EXIT_DOM((int)rc, d);
+
+ out:
+    rcu_unlock_domain(d);
+
+    return rc;
+}
+
+int evtchn_alloc_unbound_domain(struct domain *d, evtchn_port_t *port,
+                                domid_t remote_domid)
+{
+    struct evtchn *chn;
+    int           rc;
+    int           free_port;
+
     spin_lock(&d->event_lock);
=20
-    if ( (port =3D get_free_port(d)) < 0 )
-        ERROR_EXIT_DOM(port, d);
-    chn =3D evtchn_from_port(d, port);
+    rc =3D free_port =3D get_free_port(d);
+    if ( free_port < 0 )
+        goto out;
=20
-    rc =3D xsm_evtchn_unbound(d, chn, alloc->remote_dom);
+    chn =3D evtchn_from_port(d, free_port);
+    rc =3D xsm_evtchn_unbound(d, chn, remote_domid);
     if ( rc )
         goto out;
=20
     chn->state =3D ECS_UNBOUND;
-    if ( (chn->u.unbound.remote_domid =3D alloc->remote_dom) =3D=3D DOMI=
D_SELF )
+    if ( (chn->u.unbound.remote_domid =3D remote_domid) =3D=3D DOMID_SEL=
F )
         chn->u.unbound.remote_domid =3D current->domain->domain_id;
=20
-    alloc->port =3D port;
+    *port =3D free_port;
+    /* Everything is fine, returns 0 */
+    rc =3D 0;
=20
  out:
     spin_unlock(&d->event_lock);
-    rcu_unlock_domain(d);
-
     return rc;
 }
=20
diff --git a/xen/include/xen/event.h b/xen/include/xen/event.h
index 71c3e92..1a0c832 100644
--- a/xen/include/xen/event.h
+++ b/xen/include/xen/event.h
@@ -69,6 +69,9 @@ int guest_enabled_event(struct vcpu *v, uint32_t virq);
 /* Notify remote end of a Xen-attached event channel.*/
 void notify_via_xen_event_channel(struct domain *ld, int lport);
=20
+int evtchn_alloc_unbound_domain(struct domain *d, evtchn_port_t *port,
+                                domid_t remote_domid);
+
 /* Internal event channel object accessors */
 #define bucket_from_port(d,p) \
     ((d)->evtchn[(p)/EVTCHNS_PER_BUCKET])

--------------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 Sep 20 11:40:29 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Sep 2012 11: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 1TEf7F-0002SY-3L; Thu, 20 Sep 2012 11:40:21 +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 1TEf7E-0002S1-3X
	for xen-devel@lists.xen.org; Thu, 20 Sep 2012 11:40:20 +0000
Received: from [85.158.139.211:41250] by server-11.bemta-5.messagelabs.com id
	AA/8C-24658-3A00B505; Thu, 20 Sep 2012 11:40:19 +0000
X-Env-Sender: jean.guyader@citrix.com
X-Msg-Ref: server-8.tower-206.messagelabs.com!1348141207!19290275!4
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTA0NTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31542 invoked from network); 20 Sep 2012 11:40:18 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Sep 2012 11:40:18 -0000
X-IronPort-AV: E=Sophos;i="4.80,453,1344211200"; d="scan'208";a="14654042"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Sep 2012 11:40: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.279.1; Thu, 20 Sep 2012 12:39:45 +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 1TEf6e-0001f0-VA;
	Thu, 20 Sep 2012 11:39:45 +0000
Received: by spongy (Postfix, from userid 2023)	id 33D27341ABD; Thu, 20 Sep
	2012 12:42:03 +0100 (BST)
From: Jean Guyader <jean.guyader@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Thu, 20 Sep 2012 12:42:01 +0100
Message-ID: <1348141322-28657-4-git-send-email-jean.guyader@citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <1348141322-28657-1-git-send-email-jean.guyader@citrix.com>
References: <1348141322-28657-1-git-send-email-jean.guyader@citrix.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="------------true"
Cc: tim@xen.org, Jean Guyader <jean.guyader@citrix.com>, JBeulich@suse.com
Subject: [Xen-devel] [PATCH 3/4] xen: events,
	exposes evtchn_alloc_unbound_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>
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


Exposes evtchn_alloc_unbound_domain to the rest of
Xen so we can create allocated unbound evtchn within Xen.

Signed-off-by: Jean Guyader <jean.guyader@citrix.com>
---
 xen/common/event_channel.c |   39 +++++++++++++++++++++++++++-----------=
-
 xen/include/xen/event.h    |    3 +++
 2 files changed, 30 insertions(+), 12 deletions(-)


--------------true
Content-Type: text/x-patch;
	name="0003-xen-events-exposes-evtchn_alloc_unbound_domain.patch"
Content-Disposition: attachment;
	filename="0003-xen-events-exposes-evtchn_alloc_unbound_domain.patch"
Content-Transfer-Encoding: quoted-printable

diff --git a/xen/common/event_channel.c b/xen/common/event_channel.c
index 53777f8..6a0e342 100644
--- a/xen/common/event_channel.c
+++ b/xen/common/event_channel.c
@@ -159,36 +159,51 @@ static int get_free_port(struct domain *d)
=20
 static long evtchn_alloc_unbound(evtchn_alloc_unbound_t *alloc)
 {
-    struct evtchn *chn;
     struct domain *d;
-    int            port;
-    domid_t        dom =3D alloc->dom;
     long           rc;
=20
-    rc =3D rcu_lock_target_domain_by_id(dom, &d);
+    rc =3D rcu_lock_target_domain_by_id(alloc->dom, &d);
     if ( rc )
         return rc;
=20
+    rc =3D evtchn_alloc_unbound_domain(d, &alloc->port, alloc->remote_do=
m);
+    if ( rc )
+        ERROR_EXIT_DOM((int)rc, d);
+
+ out:
+    rcu_unlock_domain(d);
+
+    return rc;
+}
+
+int evtchn_alloc_unbound_domain(struct domain *d, evtchn_port_t *port,
+                                domid_t remote_domid)
+{
+    struct evtchn *chn;
+    int           rc;
+    int           free_port;
+
     spin_lock(&d->event_lock);
=20
-    if ( (port =3D get_free_port(d)) < 0 )
-        ERROR_EXIT_DOM(port, d);
-    chn =3D evtchn_from_port(d, port);
+    rc =3D free_port =3D get_free_port(d);
+    if ( free_port < 0 )
+        goto out;
=20
-    rc =3D xsm_evtchn_unbound(d, chn, alloc->remote_dom);
+    chn =3D evtchn_from_port(d, free_port);
+    rc =3D xsm_evtchn_unbound(d, chn, remote_domid);
     if ( rc )
         goto out;
=20
     chn->state =3D ECS_UNBOUND;
-    if ( (chn->u.unbound.remote_domid =3D alloc->remote_dom) =3D=3D DOMI=
D_SELF )
+    if ( (chn->u.unbound.remote_domid =3D remote_domid) =3D=3D DOMID_SEL=
F )
         chn->u.unbound.remote_domid =3D current->domain->domain_id;
=20
-    alloc->port =3D port;
+    *port =3D free_port;
+    /* Everything is fine, returns 0 */
+    rc =3D 0;
=20
  out:
     spin_unlock(&d->event_lock);
-    rcu_unlock_domain(d);
-
     return rc;
 }
=20
diff --git a/xen/include/xen/event.h b/xen/include/xen/event.h
index 71c3e92..1a0c832 100644
--- a/xen/include/xen/event.h
+++ b/xen/include/xen/event.h
@@ -69,6 +69,9 @@ int guest_enabled_event(struct vcpu *v, uint32_t virq);
 /* Notify remote end of a Xen-attached event channel.*/
 void notify_via_xen_event_channel(struct domain *ld, int lport);
=20
+int evtchn_alloc_unbound_domain(struct domain *d, evtchn_port_t *port,
+                                domid_t remote_domid);
+
 /* Internal event channel object accessors */
 #define bucket_from_port(d,p) \
     ((d)->evtchn[(p)/EVTCHNS_PER_BUCKET])

--------------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 Sep 20 11:40:31 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Sep 2012 11:40:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TEf7K-0002VK-GN; Thu, 20 Sep 2012 11:40:26 +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 1TEf7I-0002TR-E6
	for xen-devel@lists.xen.org; Thu, 20 Sep 2012 11:40:25 +0000
Received: from [85.158.139.211:50381] by server-5.bemta-5.messagelabs.com id
	7A/B6-30514-7A00B505; Thu, 20 Sep 2012 11:40:23 +0000
X-Env-Sender: jean.guyader@citrix.com
X-Msg-Ref: server-8.tower-206.messagelabs.com!1348141207!19290275!5
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTA0NTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31773 invoked from network); 20 Sep 2012 11:40:22 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Sep 2012 11:40:22 -0000
X-IronPort-AV: E=Sophos;i="4.80,453,1344211200"; d="scan'208";a="14654055"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Sep 2012 11:40: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.279.1; Thu, 20 Sep 2012 12:39:45 +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 1TEf6e-0001f1-VK;
	Thu, 20 Sep 2012 11:39:45 +0000
Received: by spongy (Postfix, from userid 2023)	id 4BC22341ABF; Thu, 20 Sep
	2012 12:42:04 +0100 (BST)
From: Jean Guyader <jean.guyader@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Thu, 20 Sep 2012 12:42:02 +0100
Message-ID: <1348141322-28657-5-git-send-email-jean.guyader@citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <1348141322-28657-1-git-send-email-jean.guyader@citrix.com>
References: <1348141322-28657-1-git-send-email-jean.guyader@citrix.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="------------true"
Cc: tim@xen.org, Jean Guyader <jean.guyader@citrix.com>, JBeulich@suse.com
Subject: [Xen-devel] [PATCH 4/4] 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             |    6 +-
 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                |   13 +-
 xen/common/v4v.c                   | 1905 ++++++++++++++++++++++++++++++=
++++++
 xen/include/public/v4v.h           |  324 ++++++
 xen/include/public/xen.h           |    2 +-
 xen/include/xen/sched.h            |    4 +
 xen/include/xen/v4v.h              |  133 +++
 10 files changed, 2388 insertions(+), 4 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 d69e419..b685535 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -3183,7 +3183,8 @@ static hvm_hypercall_t *const hvm_hypercall64_table=
[NR_hypercalls] =3D {
     HYPERCALL(set_timer_op),
     HYPERCALL(hvm_op),
     HYPERCALL(sysctl),
-    HYPERCALL(tmem_op)
+    HYPERCALL(tmem_op),
+    HYPERCALL(v4v_op)
 };
=20
 #define COMPAT_CALL(x)                                        \
@@ -3200,7 +3201,8 @@ static hvm_hypercall_t *const hvm_hypercall32_table=
[NR_hypercalls] =3D {
     COMPAT_CALL(set_timer_op),
     HYPERCALL(hvm_op),
     HYPERCALL(sysctl),
-    HYPERCALL(tmem_op)
+    HYPERCALL(tmem_op),
+    HYPERCALL(v4v_op)
 };
=20
 int hvm_do_hypercall(struct cpu_user_regs *regs)
diff --git a/xen/arch/x86/x86_64/compat/entry.S b/xen/arch/x86/x86_64/com=
pat/entry.S
index 2f606ab..f518a03 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 5 /* 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 8156827..5f4e7bf 100644
--- a/xen/arch/x86/x86_64/entry.S
+++ b/xen/arch/x86/x86_64/entry.S
@@ -707,6 +707,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
@@ -755,6 +756,7 @@ ENTRY(hypercall_args_table)
         .byte 1 /* do_domctl            */
         .byte 2 /* do_kexec             */
         .byte 1 /* do_tmem_op           */
+        .byte 5 /* 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 c1c100f..ba63cec 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 a1aa05e..94283e3 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 err, init_status =3D 0;
     int poolid =3D CPUPOOLID_NONE;
=20
@@ -307,6 +308,13 @@ struct domain *domain_create(
         spin_unlock(&domlist_update_lock);
     }
=20
+    if ( !is_idle_domain(d) )
+    {
+        if ( v4v_init(d) !=3D 0 )
+            goto fail;
+        init_status |=3D INIT_v4v;
+    }
+
     return d;
=20
  fail:
@@ -315,6 +323,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 )
@@ -468,6 +478,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..afb9267
--- /dev/null
+++ b/xen/common/v4v.c
@@ -0,0 +1,1905 @@
+/***********************************************************************=
*******
+ * 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 <asm/types.h>
+
+#ifdef V4V_DEBUG
+#define v4v_dprintk(format, args...)            \
+    do {                                        \
+        printk("%s:%d " format,                 \
+               __FILE__, __LINE__, ## args );   \
+    } while ( 1 =3D=3D 0 )
+#else
+#define v4v_dprintk(format, ... ) (void)0
+#endif
+
+/*
+ * 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
+ */
+#define V4V_ROUNDUP(a) (((a) +0xf ) & ~0xf)
+
+DEFINE_XEN_GUEST_HANDLE(uint8_t);
+static struct v4v_ring_info *v4v_ring_find_info(struct domain *d,
+                                                v4v_ring_id_t *id);
+
+static struct v4v_ring_info *v4v_ring_find_info_by_addr(struct domain *d=
,
+                                                        struct v4v_addr =
*a,
+                                                        domid_t p);
+
+typedef struct internal_v4v_iov
+{
+    XEN_GUEST_HANDLE(v4v_iov_t) guest_iov;
+    v4v_iov_t                   *xen_iov;
+} internal_v4v_iov_t;
+
+struct list_head viprules =3D LIST_HEAD_INIT(viprules);
+
+/*
+ * 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
+ */
+
+/*
+ * lock to protect the filtering rules list: viprules
+ *
+ * The write lock is held for viptables_del and viptables_add
+ * The read lock is held for viptable_list
+ */
+static DEFINE_RWLOCK(viprules_lock);
+
+
+/*
+ * Debugs
+ */
+
+#ifdef V4V_DEBUG
+static void __attribute__((unused))
+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);
+
+    evtchn_send(d, d->v4v->evtchn_port);
+}
+
+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
+ */
+
+static void
+v4v_ring_unmap(struct v4v_ring_info *ring_info)
+{
+    int i;
+
+    ASSERT(spin_is_locked(&ring_info->lock));
+
+    for ( i =3D 0; i < ring_info->npage; ++i )
+    {
+        if ( !ring_info->mfn_mapping[i] )
+            continue;
+        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;
+    }
+}
+
+static uint8_t *
+v4v_ring_map_page(struct v4v_ring_info *ring_info, int i)
+{
+    ASSERT(spin_is_locked(&ring_info->lock));
+
+    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->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];
+}
+
+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;
+
+    ASSERT(spin_is_locked(&ring_info->lock));
+
+    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;
+}
+
+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);
+    uint32_t *p =3D (uint32_t *)(dst + offsetof(v4v_ring_t, tx_ptr));
+
+    ASSERT(spin_is_locked(&ring_info->lock));
+
+    if ( !dst )
+        return -EFAULT;
+    write_atomic(p, tx_ptr);
+    mb();
+    return 0;
+}
+
+static int
+v4v_copy_from_guest_maybe(void *dst, void *src,
+                          XEN_GUEST_HANDLE(uint8_t) src_hnd,
+                          uint32_t len)
+{
+    int rc =3D 0;
+
+    if ( src )
+        memcpy(dst, src, len);
+    else
+        rc =3D copy_from_guest(dst, src_hnd, len);
+    return rc;
+}
+
+static int
+v4v_memcpy_to_guest_ring(struct v4v_ring_info *ring_info,
+                         uint32_t offset,
+                         void *src,
+                         XEN_GUEST_HANDLE(uint8_t) src_hnd,
+                         uint32_t len)
+{
+    int page =3D offset >> PAGE_SHIFT;
+    uint8_t *dst;
+
+    ASSERT(spin_is_locked(&ring_info->lock));
+
+    offset &=3D PAGE_SIZE - 1;
+
+    while ( (offset + len) > PAGE_SIZE )
+    {
+        dst =3D v4v_ring_map_page(ring_info, page);
+        if ( !dst )
+            return -EFAULT;
+
+        if ( v4v_copy_from_guest_maybe(dst + offset, src, src_hnd,
+                                       PAGE_SIZE - offset) )
+            return -EFAULT;
+
+        page++;
+        len -=3D PAGE_SIZE - offset;
+        if ( src )
+            src +=3D (PAGE_SIZE - offset);
+        else
+            guest_handle_add_offset(src_hnd, PAGE_SIZE - offset);
+        offset =3D 0;
+    }
+
+    dst =3D v4v_ring_map_page(ring_info, page);
+    if ( !dst )
+        return -EFAULT;
+
+    if ( v4v_copy_from_guest_maybe(dst + offset, src, src_hnd, len) )
+        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 =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;
+
+    write_atomic(rx_ptr, ringp->rx_ptr);
+    mb();
+
+    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 =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;
+}
+
+static unsigned long
+v4v_iov_copy(v4v_iov_t *iov, internal_v4v_iov_t *iovs)
+{
+    if (iovs->xen_iov =3D=3D NULL)
+    {
+        return copy_from_guest(iov, iovs->guest_iov, 1);
+    }
+    else
+    {
+        *iov =3D *(iovs->xen_iov);
+        return 0;
+    }
+}
+
+static void
+v4v_iov_add_offset(internal_v4v_iov_t *iovs, int offset)
+{
+    if (iovs->xen_iov =3D=3D NULL)
+        guest_handle_add_offset(iovs->guest_iov, offset);
+    else
+        iovs->xen_iov +=3D offset;
+}
+
+static long
+v4v_iov_count(internal_v4v_iov_t iovs, int niov)
+{
+    v4v_iov_t iov;
+    size_t ret =3D 0;
+
+    while ( niov-- )
+    {
+        if ( v4v_iov_copy(&iov, &iovs) )
+            return -EFAULT;
+
+        /* message bigger than 2G can't be sent */
+        if (ret > 2L * 1024 * 1024 * 1024)
+            return -EMSGSIZE;
+
+        ret +=3D iov.iov_len;
+        v4v_iov_add_offset(&iovs, 1);
+    }
+
+    return ret;
+}
+
+static long
+v4v_ringbuf_insertv(struct domain *d,
+                    struct v4v_ring_info *ring_info,
+                    v4v_ring_id_t *src_id, uint32_t proto,
+                    internal_v4v_iov_t iovs, uint32_t niov,
+                    size_t len)
+{
+    v4v_ring_t ring;
+    struct v4v_ring_message_header mh =3D { 0 };
+    int32_t sp;
+    long happy_ret;
+    int32_t ret =3D 0;
+    XEN_GUEST_HANDLE(uint8_t) empty_hnd =3D { 0 };
+
+    ASSERT(spin_is_locked(&ring_info->lock));
+
+    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.message_type =3D proto;
+
+        if ( (ret =3D v4v_memcpy_to_guest_ring(ring_info,
+                                             ring.tx_ptr + sizeof (v4v_r=
ing_t),
+                                             &mh, empty_hnd,
+                                             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 ( v4v_iov_copy(&iov, &iovs) )
+            {
+                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 )
+            {
+                ret =3D v4v_memcpy_to_guest_ring(ring_info,
+                        ring.tx_ptr + sizeof (v4v_ring_t),
+                        NULL, buf_hnd, sp);
+                if ( ret )
+                    break;
+
+                ring.tx_ptr =3D 0;
+                len -=3D sp;
+                guest_handle_add_offset(buf_hnd, sp);
+            }
+
+            ret =3D v4v_memcpy_to_guest_ring(ring_info,
+                    ring.tx_ptr + sizeof (v4v_ring_t),
+                    NULL, buf_hnd, len);
+            if ( ret )
+                break;
+
+            ring.tx_ptr +=3D len;
+
+            if ( ring.tx_ptr =3D=3D ring_info->len )
+                ring.tx_ptr =3D 0;
+
+            v4v_iov_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);
+}
+
+static void
+v4v_pending_remove_all(struct v4v_ring_info *info)
+{
+    struct hlist_node *node, *next;
+    struct v4v_pending_ent *pending_ent;
+
+    ASSERT(spin_is_locked(&info->lock));
+    hlist_for_each_entry_safe(pending_ent, node, next, &info->pending,
+            node) v4v_pending_remove_ent(pending_ent);
+}
+
+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;
+
+    ASSERT(rw_is_locked(&v4v_lock));
+
+    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);
+    }
+
+}
+
+static void
+v4v_pending_find(struct domain *d, 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;
+
+    ASSERT(rw_is_locked(&d->v4v->lock));
+
+    spin_lock(&ring_info->lock);
+    hlist_for_each_entry_safe(ent, node, next, &ring_info->pending, node=
)
+    {
+        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 l=
en)
+{
+    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, int=
 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, node=
)
+    {
+        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(xen_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);
+    }
+    return ret;
+}
+
+
+static struct v4v_ring_info *
+v4v_ring_find_info(struct domain *d, v4v_ring_id_t *id)
+{
+    uint16_t hash;
+    struct hlist_node *node;
+    struct v4v_ring_info *ring_info;
+
+    ASSERT(rw_is_locked(&d->v4v->lock));
+
+    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], node=
)
+    {
+        v4v_ring_id_t *cmpid =3D &ring_info->id;
+
+        if ( cmpid->addr.port =3D=3D id->addr.port &&
+             cmpid->addr.domain =3D=3D id->addr.domain &&
+             cmpid->partner =3D=3D id->partner)
+        {
+            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;
+}
+
+static struct v4v_ring_info *
+v4v_ring_find_info_by_addr(struct domain *d, struct v4v_addr *a, domid_t=
 p)
+{
+    v4v_ring_id_t id;
+    struct v4v_ring_info *ret;
+
+    ASSERT(rw_is_locked(&d->v4v->lock));
+
+    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_ANY;
+
+    return v4v_ring_find_info(d, &id);
+}
+
+static void v4v_ring_remove_mfns(struct domain *d, struct v4v_ring_info =
*ring_info)
+{
+    int i;
+
+    ASSERT(rw_is_write_locked(&d->v4v->lock));
+
+    if ( ring_info->mfns )
+    {
+        for ( i =3D 0; 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);
+    }
+    if ( ring_info->mfn_mapping )
+        xfree(ring_info->mfn_mapping);
+    ring_info->mfns =3D NULL;
+
+}
+
+static void
+v4v_ring_remove_info(struct domain *d, struct v4v_ring_info *ring_info)
+{
+    ASSERT(rw_is_write_locked(&d->v4v->lock));
+
+    spin_lock(&ring_info->lock);
+
+    v4v_pending_remove_all(ring_info);
+    hlist_del(&ring_info->node);
+    v4v_ring_remove_mfns(d, ring_info);
+
+    spin_unlock(&ring_info->lock);
+
+    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 =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(d, 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(xen_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 rin=
g.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.
+             */
+            printk(KERN_INFO "v4v: dom%d ring already registered\n",
+                    current->domain->domain_id);
+            ret =3D -EEXIST;
+            break;
+        }
+
+        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
+ */
+
+static void
+v4v_notify_ring(struct domain *d, struct v4v_ring_info *ring_info,
+                struct hlist_head *to_notify)
+{
+    uint32_t space;
+
+    ASSERT(rw_is_locked(&v4v_lock));
+    ASSERT(rw_is_locked(&d->v4v->lock));
+
+    spin_lock(&ring_info->lock);
+    space =3D v4v_ringbuf_payload_space(d, ring_info);
+    spin_unlock(&ring_info->lock);
+
+    v4v_pending_find(d, 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, data[0]);
+                ret =3D v4v_fill_ring_datas(d, ring_data.nent, ring_data=
_ent_hnd);
+            }
+        }
+    }
+    while ( 0 );
+
+    read_unlock(&v4v_lock);
+
+    return ret;
+}
+
+#ifdef V4V_DEBUG
+void
+v4v_viptables_print_rule(struct v4v_viptables_rule_node *node)
+{
+    v4v_viptables_rule_t *rule;
+
+    if ( node =3D=3D NULL )
+    {
+        printk("(null)\n");
+        return;
+    }
+
+    rule =3D &node->rule;
+
+    if ( rule->accept =3D=3D 1 )
+        printk("ACCEPT");
+    else
+        printk("REJECT");
+
+    printk(" ");
+
+    if ( rule->src.domain =3D=3D V4V_DOMID_ANY )
+        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 V4V_DOMID_ANY )
+        printk("*");
+    else
+        printk("%i", rule->dst.domain);
+
+    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 =3D NULL;
+    struct list_head* tmp;
+
+    ASSERT(rw_is_write_locked(&viprules_lock));
+
+    /* First rule is n.1 */
+    position--;
+
+    new =3D xmalloc(struct v4v_viptables_rule_node);
+    if ( new =3D=3D NULL )
+        return -ENOMEM;
+
+    if ( copy_from_guest(&new->rule, rule, 1) )
+    {
+        xfree(new);
+        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_hnd,
+                  int32_t position)
+{
+    struct list_head *tmp =3D NULL;
+    struct list_head *next =3D NULL;
+    struct v4v_viptables_rule_node *node;
+
+    ASSERT(rw_is_write_locked(&viprules_lock));
+
+    v4v_dprintk("v4v_viptables_del position:%d\n", position);
+
+    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_hnd) )
+    {
+        struct v4v_viptables_rule r;
+
+        if ( copy_from_guest(&r, rule_hnd, 1) )
+            return -EFAULT;
+
+        list_for_each(tmp, &viprules)
+        {
+            node =3D list_entry(tmp, struct v4v_viptables_rule_node, lis=
t);
+
+            if ( (node->rule.src.domain =3D=3D r.src.domain) &&
+                 (node->rule.src.port   =3D=3D r.src.port)   &&
+                 (node->rule.dst.domain =3D=3D r.dst.domain) &&
+                 (node->rule.dst.port   =3D=3D r.dst.port))
+            {
+                position =3D 0;
+                break;
+            }
+        }
+    }
+    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, lis=
t);
+            list_del(tmp);
+            xfree(node);
+        }
+    }
+
+    if ( position =3D=3D 0 && tmp !=3D &viprules )
+    {
+        node =3D list_entry(tmp, struct v4v_viptables_rule_node, list);
+#ifdef V4V_DEBUG
+        printk(KERN_ERR "VIPTables: deleting rule: ");
+        v4v_viptables_print_rule(node);
+#endif /* V4V_DEBUG */
+        list_del(tmp);
+        xfree(node);
+    }
+
+    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;
+    XEN_GUEST_HANDLE(v4v_viptables_rule_t) guest_rules;
+
+    ASSERT(rw_is_locked(&viprules_lock));
+
+    memset(&rules_list, 0, sizeof (rules_list));
+    if ( copy_from_guest(&rules_list, list_hnd, 1) )
+        return -EFAULT;
+
+    ptr =3D viprules.next;
+    while ( rules_list.start_rule !=3D 0 && ptr->next !=3D &viprules )
+    {
+        ptr =3D ptr->next;
+        rules_list.start_rule--;
+    }
+
+    if ( rules_list.nb_rules =3D=3D 0 )
+        return -EINVAL;
+
+    guest_rules =3D guest_handle_for_field(list_hnd, v4v_viptables_rule_=
t, rules[0]);
+
+    nbrules =3D 0;
+    while ( nbrules < rules_list.nb_rules && ptr !=3D &viprules )
+    {
+        node =3D list_entry(ptr, struct v4v_viptables_rule_node, list);
+
+        if ( !guest_handle_okay(guest_rules, 1) )
+            break;
+
+        if ( copy_to_guest(guest_rules, &node->rule, 1) )
+            break;
+
+        guest_handle_add_offset(guest_rules, 1);
+
+        nbrules++;
+        ptr =3D ptr->next;
+    }
+
+    rules_list.nb_rules =3D nbrules;
+    if ( copy_field_to_guest(list_hnd, &rules_list, nb_rules) )
+        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;
+    size_t ret =3D 0; /* Defaulting to ACCEPT */
+
+    read_lock(&viprules_lock);
+
+    list_for_each(ptr, &viprules)
+    {
+        node =3D list_entry(ptr, struct v4v_viptables_rule_node, list);
+
+        if ( (node->rule.src.domain =3D=3D V4V_DOMID_ANY ||
+              node->rule.src.domain =3D=3D src->domain) &&
+             (node->rule.src.port =3D=3D V4V_PORT_ANY ||
+              node->rule.src.port =3D=3D src->port) &&
+             (node->rule.dst.domain =3D=3D V4V_DOMID_ANY ||
+              node->rule.dst.domain =3D=3D dst->domain) &&
+             (node->rule.dst.port =3D=3D V4V_PORT_ANY ||
+              node->rule.dst.port =3D=3D dst->port) )
+        {
+            ret =3D !node->rule.accept;
+            break;
+        }
+    }
+
+    read_unlock(&viprules_lock);
+    return ret;
+}
+
+/*
+ * Hypercall to do the send
+ */
+static long
+v4v_sendv(struct domain *src_d, v4v_addr_t * src_addr,
+          v4v_addr_t * dst_addr, uint32_t proto,
+          internal_v4v_iov_t iovs, size_t niov)
+{
+    struct domain *dst_d;
+    v4v_ring_id_t 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;
+    }
+
+    if ( v4v_viptables_check(src_addr, dst_addr) !=3D 0 )
+    {
+        read_unlock(&v4v_lock);
+        gdprintk(XENLOG_WARNING,
+                 "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 )
+        {
+            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->domain=
);
+
+        if ( !ring_info )
+        {
+            ret =3D -ECONNREFUSED;
+            v4v_dprintk(" !ring_info, ECONNREFUSED\n");
+        }
+        else
+        {
+            long 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, io=
vs,
+                        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;
+}
+
+static void
+v4v_info(struct domain *d, v4v_info_t *info)
+{
+    read_lock(&d->v4v->lock);
+    info->ring_magic =3D V4V_RING_MAGIC;
+    info->data_magic =3D V4V_RING_DATA_MAGIC;
+    info->evtchn =3D d->v4v->evtchn_port;
+    read_unlock(&d->v4v->lock);
+}
+
+/*
+ * hypercall glue
+ */
+long
+do_v4v_op(int cmd, XEN_GUEST_HANDLE(void) arg1,
+          XEN_GUEST_HANDLE(void) arg2,
+          uint32_t arg3, uint32_t arg4)
+{
+    struct domain *d =3D current->domain;
+    long rc =3D -EFAULT;
+
+    v4v_dprintk("->do_v4v_op(%d,%p,%p,%d,%d)\n", cmd,
+                (void *)arg1.p, (void *)arg2.p, (int) arg3, (int) arg4);
+
+    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(xen_pfn_t) pfn_hnd =3D
+                    guest_handle_cast(arg2, xen_pfn_t);
+                uint32_t npage =3D arg3;
+                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:
+            {
+                uint32_t len =3D arg3;
+                uint32_t message_type =3D arg4;
+                v4v_iov_t iov;
+                internal_v4v_iov_t iovs;
+                XEN_GUEST_HANDLE(v4v_send_addr_t) addr_hnd =3D
+                    guest_handle_cast(arg1, v4v_send_addr_t);
+                v4v_send_addr_t addr;
+
+                if ( unlikely(!guest_handle_okay(addr_hnd, 1)) )
+                    goto out;
+                if ( copy_from_guest(&addr, addr_hnd, 1) )
+                    goto out;
+
+                iov.iov_base =3D (uint64_t)arg2.p; // FIXME
+                iov.iov_len =3D len;
+                iovs.xen_iov =3D &iov;
+                rc =3D v4v_sendv(d, &addr.src, &addr.dst, message_type, =
iovs, 1);
+                break;
+            }
+        case V4VOP_sendv:
+            {
+                internal_v4v_iov_t iovs;
+                uint32_t niov =3D arg3;
+                uint32_t message_type =3D arg4;
+                XEN_GUEST_HANDLE(v4v_send_addr_t) addr_hnd =3D
+                    guest_handle_cast(arg1, v4v_send_addr_t);
+                v4v_send_addr_t addr;
+
+                memset(&iovs, 0, sizeof (iovs));
+                iovs.guest_iov =3D guest_handle_cast(arg2, v4v_iov_t);
+
+                if ( unlikely(!guest_handle_okay(addr_hnd, 1)) )
+                    goto out;
+                if ( copy_from_guest(&addr, addr_hnd, 1) )
+                    goto out;
+
+                if ( unlikely(!guest_handle_okay(iovs.guest_iov, niov)) =
)
+                    goto out;
+
+                rc =3D v4v_sendv(d, &addr.src, &addr.dst, message_type, =
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;
+            }
+        case V4VOP_viptables_add:
+            {
+                uint32_t position =3D arg3;
+                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;
+
+                write_lock(&viprules_lock);
+                rc =3D v4v_viptables_add(d, rule_hnd, position);
+                write_unlock(&viprules_lock);
+                break;
+            }
+        case V4VOP_viptables_del:
+            {
+                uint32_t position =3D arg3;
+                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;
+
+                write_lock(&viprules_lock);
+                rc =3D v4v_viptables_del(d, rule_hnd, position);
+                write_unlock(&viprules_lock);
+                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 -EFAULT;
+                if ( unlikely(!guest_handle_okay(rules_list_hnd, 1)) )
+                    goto out;
+
+                read_lock(&viprules_lock);
+                rc =3D v4v_viptables_list(d, rules_list_hnd);
+                read_unlock(&viprules_lock);
+                break;
+            }
+        case V4VOP_info:
+            {
+                XEN_GUEST_HANDLE(v4v_info_t) info_hnd =3D
+                    guest_handle_cast(arg1, v4v_info_t);
+                v4v_info_t info;
+
+                if ( unlikely(!guest_handle_okay(info_hnd, 1)) )
+                    goto out;
+                v4v_info(d, &info);
+                if ( copy_to_guest(info_hnd, &info, 1) )
+                    goto out;
+                rc =3D 0;
+                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(d, ring_info);
+            }
+        }
+    }
+
+    d->v4v =3D NULL;
+    write_unlock(&v4v_lock);
+}
+
+int
+v4v_init(struct domain *d)
+{
+    struct v4v_domain *v4v;
+    evtchn_port_t port;
+    int i;
+    int rc;
+
+    v4v =3D xmalloc(struct v4v_domain);
+    if ( !v4v )
+        return -ENOMEM;
+
+    rc =3D evtchn_alloc_unbound_domain(d, &port, d->domain_id);
+    if ( rc )
+        return rc;
+
+    rwlock_init(&v4v->lock);
+
+    v4v->evtchn_port =3D port;
+    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 npage=
=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(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], nod=
e)
+            dump_domain_ring(d, ring_info);
+    }
+
+    printk(KERN_ERR "  event channel: %d\n",  d->v4v->evtchn_port);
+    read_unlock(&d->v4v->lock);
+
+    printk(KERN_ERR "\n");
+    v4v_signal_domain(d);
+}
+
+static void
+dump_state(unsigned char key)
+{
+    struct domain *d;
+
+    printk(KERN_ERR "\n\nV4V:\n");
+    read_lock(&v4v_lock);
+
+    rcu_read_lock(&domlist_read_lock);
+
+    for_each_domain(d)
+        dump_domain(d);
+
+    rcu_read_unlock(&domlist_read_lock);
+
+    read_unlock(&v4v_lock);
+}
+
+struct keyhandler v4v_info_keyhandler =3D
+{
+    .diagnostic =3D 1,
+    .u.fn =3D dump_state,
+    .desc =3D "dump v4v states and interupt"
+};
+
+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..380ac29
--- /dev/null
+++ b/xen/include/public/v4v.h
@@ -0,0 +1,324 @@
+/***********************************************************************=
*******
+ * 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"
+#include "event_channel.h"
+
+/*
+ * Structure definitions
+ */
+
+#define V4V_RING_MAGIC          0xa822f72bb0b9d8ccULL
+#define V4V_RING_DATA_MAGIC	0x45fe852220b801d4ULL
+
+#define V4V_MESSAGE_DGRAM       0x3c2c1db8
+#define V4V_MESSAGE_STREAM 	0x70f6a8e5
+
+#define V4V_DOMID_ANY           DOMID_INVALID
+#define V4V_PORT_ANY            0
+
+typedef struct v4v_iov
+{
+    uint64_t iov_base;
+    uint32_t iov_len;
+    uint32_t pad;
+} v4v_iov_t;
+
+typedef struct v4v_addr
+{
+    uint32_t port;
+    domid_t domain;
+    uint16_t pad;
+} v4v_addr_t;
+
+typedef struct v4v_ring_id
+{
+    v4v_addr_t addr;
+    domid_t partner;
+    uint16_t pad;
+} v4v_ring_id_t;
+
+typedef struct
+{
+    v4v_addr_t src;
+    v4v_addr_t dst;
+} v4v_send_addr_t;
+
+/*
+ * v4v_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
+ *
+ */
+struct v4v_ring
+{
+    uint64_t magic;
+    v4v_ring_id_t id;
+    uint32_t len;
+    uint32_t rx_ptr;
+    uint32_t tx_ptr;
+    uint8_t reserved[32];
+#if defined(__STDC_VERSION__) && __STDC_VERSION__ >=3D 199901L
+    uint8_t ring[];
+#elif defined(__GNUC__)
+    uint8_t ring[0];
+#endif
+};
+typedef struct v4v_ring v4v_ring_t;
+
+#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 exist=
s - do not
+                                               * rely on this field - fo=
r
+                                               * profiling only */
+#define V4V_RING_DATA_F_SUFFICIENT  (1U << 3) /* Sufficient space to que=
ue
+                                               * space_required bytes ex=
ists */
+
+typedef struct v4v_ring_data_ent
+{
+    v4v_addr_t ring;
+    uint16_t flags;
+    uint16_t pad1;
+    uint32_t pad2;
+    uint32_t space_required;
+    uint32_t max_message_size;
+} v4v_ring_data_ent_t;
+
+typedef struct v4v_ring_data
+{
+    uint64_t magic;
+    uint32_t nent;
+    uint32_t pad;
+    uint64_t reserved[4];
+#if defined(__STDC_VERSION__) && __STDC_VERSION__ >=3D 199901L
+    v4v_ring_data_ent_t data[];
+#elif defined(__GNUC__)
+    v4v_ring_data_ent_t data[0];
+#endif
+} v4v_ring_data_t;
+
+struct v4v_info
+{
+    uint64_t ring_magic;
+    uint64_t data_magic;
+    evtchn_port_t evtchn;
+    uint32_t pad;
+};
+typedef struct v4v_info v4v_info_t;
+
+#define V4V_SHF_SYN		(1 << 0)
+#define V4V_SHF_ACK		(1 << 1)
+#define V4V_SHF_RST		(1 << 2)
+
+#define V4V_SHF_PING		(1 << 8)
+#define V4V_SHF_PONG		(1 << 9)
+
+struct v4v_stream_header
+{
+    uint32_t flags;
+    uint32_t conid;
+};
+
+struct v4v_ring_message_header
+{
+    uint32_t len;
+    uint32_t pad0;
+    v4v_addr_t source;
+    uint32_t message_type;
+    uint32_t pad1;
+#if defined(__STDC_VERSION__) && __STDC_VERSION__ >=3D 199901L
+    uint8_t data[];
+#elif defined(__GNUC__)
+    uint8_t data[0];
+#endif
+};
+
+typedef struct v4v_viptables_rule
+{
+    v4v_addr_t src;
+    v4v_addr_t dst;
+    uint32_t accept;
+    uint32_t pad;
+} v4v_viptables_rule_t;
+
+typedef struct v4v_viptables_list
+{
+    uint32_t start_rule;
+    uint32_t nb_rules;
+#if defined(__STDC_VERSION__) && __STDC_VERSION__ >=3D 199901L
+    struct v4v_viptables_rule rules[];
+#elif defined(__GNUC__)
+    struct v4v_viptables_rule rules[0];
+#endif
+} v4v_viptables_list_t;
+
+/*
+ * HYPERCALLS
+ */
+
+/*
+ * V4VOP_register_ring
+ *
+ * Registers a ring with Xen. If a ring with the same v4v_ring_id exists=
,
+ * the hypercall will return -EEXIST.
+ *
+ * do_v4v_op(V4VOP_unregister_ring,
+ *           XEN_GUEST_HANDLE(v4v_ring_t), XEN_GUEST_HANDLE(xen_pfn_t),
+ *           npage, 0)
+ */
+#define V4VOP_register_ring 	1
+
+
+/*
+ * V4VOP_unregister_ring
+ *
+ * Unregister a ring.
+ *
+ * do_v4v_op(V4VOP_unregister_ring,
+ *           XEN_GUEST_HANDLE(v4v_ring),
+ *           NULL, 0, 0)
+ */
+#define V4VOP_unregister_ring 	2
+
+/*
+ * V4VOP_send
+ *
+ * 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.
+ * message_type is the 32 bit number used from the message
+ * most likely V4V_MESSAGE_DGRAM or V4V_MESSAGE_STREAM. If insufficient =
space exists
+ * it will return -EAGAIN and xen will twing the V4V_INTERRUPT when
+ * sufficient space becomes available
+ *
+ * do_v4v_op(V4VOP_send,
+ *           XEN_GUEST_HANDLE(v4v_send_addr_t) addr,
+ *           XEN_GUEST_HANDLE(void) buf,
+ *           uint32_t len,
+ *           uint32_t message_type)
+ */
+#define V4VOP_send 		3
+
+
+/*
+ * V4VOP_notify
+ *
+ * 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
+ *
+ * do_v4v_op(V4VOP_notify,
+ *           XEN_GUEST_HANDLE(v4v_ring_data_ent) ent,
+ *           NULL, 0, 0)
+ */
+#define V4VOP_notify 		4
+
+/*
+ * V4VOP_sendv
+ *
+ * Identical to V4VOP_send except rather than buf and len it takes
+ * an array of v4v_iov and a length of the array.
+ *
+ * do_v4v_op(V4VOP_sendv,
+ *           XEN_GUEST_HANDLE(v4v_send_addr_t) addr,
+ *           XEN_GUEST_HANDLE(v4v_iov) iov,
+ *           uint32_t niov,
+ *           uint32_t message_type)
+ */
+#define V4VOP_sendv		5
+
+/*
+ * V4VOP_viptables_add
+ *
+ * Insert a filtering rules after a given position.
+ *
+ * do_v4v_op(V4VOP_viptables_add,
+ *           XEN_GUEST_HANDLE(v4v_viptables_rule_t) rule,
+ *           NULL,
+ *           uint32_t position, 0)
+ */
+#define V4VOP_viptables_add     6
+
+/*
+ * V4VOP_viptables_del
+ *
+ * Delete a filtering rules at a position or the rule
+ * that matches "rule".
+ *
+ * do_v4v_op(V4VOP_viptables_del,
+ *           XEN_GUEST_HANDLE(v4v_viptables_rule_t) rule,
+ *           NULL,
+ *           uint32_t position, 0)
+ */
+#define V4VOP_viptables_del     7
+
+/*
+ * V4VOP_viptables_list
+ *
+ * Delete a filtering rules at a position or the rule
+ * that matches "rule".
+ *
+ * do_v4v_op(V4VOP_viptables_list,
+ *           XEN_GUEST_HANDLE(v4v_vitpables_list_t) list,
+ *           NULL, 0, 0)
+ */
+#define V4VOP_viptables_list    8
+
+/*
+ * V4VOP_info
+ *
+ * Returns v4v info for the current domain (domain that issued the hyper=
call).
+ *      - V4V magic number
+ *      - event channel port (for current domain)
+ *
+ * do_v4v_op(V4VOP_info,
+ *           XEN_GUEST_HANDLE(v4v_info_t) info,
+ *           NULL, 0, 0)
+ */
+#define V4VOP_info              9
+
+#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 8def420..7a3fade 100644
--- a/xen/include/public/xen.h
+++ b/xen/include/public/xen.h
@@ -97,7 +97,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..296de52 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,9 @@ struct domain
     nodemask_t node_affinity;
     unsigned int last_alloc_node;
     spinlock_t node_affinity_lock;
+
+    /* v4v */
+    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..05d20b5
--- /dev/null
+++ b/xen/include/xen/v4v.h
@@ -0,0 +1,133 @@
+/***********************************************************************=
*******
+ * 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
+
+/*
+ * Handlers
+ */
+
+DEFINE_XEN_GUEST_HANDLE (v4v_iov_t);
+DEFINE_XEN_GUEST_HANDLE (v4v_addr_t);
+DEFINE_XEN_GUEST_HANDLE (v4v_send_addr_t);
+DEFINE_XEN_GUEST_HANDLE (v4v_ring_t);
+DEFINE_XEN_GUEST_HANDLE (v4v_ring_data_ent_t);
+DEFINE_XEN_GUEST_HANDLE (v4v_ring_data_t);
+DEFINE_XEN_GUEST_HANDLE (v4v_info_t);
+
+DEFINE_XEN_GUEST_HANDLE (v4v_viptables_rule_t);
+DEFINE_XEN_GUEST_HANDLE (v4v_viptables_list_t);
+
+/*
+ * Helper functions
+ */
+
+static inline uint16_t
+v4v_hash_fn (v4v_ring_id_t *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;
+};
+
+
+struct v4v_ring_info
+{
+    /* next node in the hash, protected by L2  */
+    struct hlist_node node;
+    /* this ring's id, protected by L2 */
+    v4v_ring_id_t 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;
+    /* event channel */
+    evtchn_port_t evtchn_port;
+    /* protected by L2 */
+    struct hlist_head ring_hash[V4V_HTABLE_SIZE];
+};
+
+typedef struct v4v_viptables_rule_node
+{
+    struct list_head list;
+    v4v_viptables_rule_t rule;
+} v4v_viptables_rule_node_t;
+
+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,
+                uint32_t arg3,
+                uint32_t arg4);
+
+#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 Sep 20 11:40:31 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Sep 2012 11:40:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TEf7K-0002VK-GN; Thu, 20 Sep 2012 11:40:26 +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 1TEf7I-0002TR-E6
	for xen-devel@lists.xen.org; Thu, 20 Sep 2012 11:40:25 +0000
Received: from [85.158.139.211:50381] by server-5.bemta-5.messagelabs.com id
	7A/B6-30514-7A00B505; Thu, 20 Sep 2012 11:40:23 +0000
X-Env-Sender: jean.guyader@citrix.com
X-Msg-Ref: server-8.tower-206.messagelabs.com!1348141207!19290275!5
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTA0NTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31773 invoked from network); 20 Sep 2012 11:40:22 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Sep 2012 11:40:22 -0000
X-IronPort-AV: E=Sophos;i="4.80,453,1344211200"; d="scan'208";a="14654055"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Sep 2012 11:40: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.279.1; Thu, 20 Sep 2012 12:39:45 +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 1TEf6e-0001f1-VK;
	Thu, 20 Sep 2012 11:39:45 +0000
Received: by spongy (Postfix, from userid 2023)	id 4BC22341ABF; Thu, 20 Sep
	2012 12:42:04 +0100 (BST)
From: Jean Guyader <jean.guyader@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Thu, 20 Sep 2012 12:42:02 +0100
Message-ID: <1348141322-28657-5-git-send-email-jean.guyader@citrix.com>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <1348141322-28657-1-git-send-email-jean.guyader@citrix.com>
References: <1348141322-28657-1-git-send-email-jean.guyader@citrix.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="------------true"
Cc: tim@xen.org, Jean Guyader <jean.guyader@citrix.com>, JBeulich@suse.com
Subject: [Xen-devel] [PATCH 4/4] 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             |    6 +-
 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                |   13 +-
 xen/common/v4v.c                   | 1905 ++++++++++++++++++++++++++++++=
++++++
 xen/include/public/v4v.h           |  324 ++++++
 xen/include/public/xen.h           |    2 +-
 xen/include/xen/sched.h            |    4 +
 xen/include/xen/v4v.h              |  133 +++
 10 files changed, 2388 insertions(+), 4 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 d69e419..b685535 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -3183,7 +3183,8 @@ static hvm_hypercall_t *const hvm_hypercall64_table=
[NR_hypercalls] =3D {
     HYPERCALL(set_timer_op),
     HYPERCALL(hvm_op),
     HYPERCALL(sysctl),
-    HYPERCALL(tmem_op)
+    HYPERCALL(tmem_op),
+    HYPERCALL(v4v_op)
 };
=20
 #define COMPAT_CALL(x)                                        \
@@ -3200,7 +3201,8 @@ static hvm_hypercall_t *const hvm_hypercall32_table=
[NR_hypercalls] =3D {
     COMPAT_CALL(set_timer_op),
     HYPERCALL(hvm_op),
     HYPERCALL(sysctl),
-    HYPERCALL(tmem_op)
+    HYPERCALL(tmem_op),
+    HYPERCALL(v4v_op)
 };
=20
 int hvm_do_hypercall(struct cpu_user_regs *regs)
diff --git a/xen/arch/x86/x86_64/compat/entry.S b/xen/arch/x86/x86_64/com=
pat/entry.S
index 2f606ab..f518a03 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 5 /* 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 8156827..5f4e7bf 100644
--- a/xen/arch/x86/x86_64/entry.S
+++ b/xen/arch/x86/x86_64/entry.S
@@ -707,6 +707,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
@@ -755,6 +756,7 @@ ENTRY(hypercall_args_table)
         .byte 1 /* do_domctl            */
         .byte 2 /* do_kexec             */
         .byte 1 /* do_tmem_op           */
+        .byte 5 /* 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 c1c100f..ba63cec 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 a1aa05e..94283e3 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 err, init_status =3D 0;
     int poolid =3D CPUPOOLID_NONE;
=20
@@ -307,6 +308,13 @@ struct domain *domain_create(
         spin_unlock(&domlist_update_lock);
     }
=20
+    if ( !is_idle_domain(d) )
+    {
+        if ( v4v_init(d) !=3D 0 )
+            goto fail;
+        init_status |=3D INIT_v4v;
+    }
+
     return d;
=20
  fail:
@@ -315,6 +323,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 )
@@ -468,6 +478,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..afb9267
--- /dev/null
+++ b/xen/common/v4v.c
@@ -0,0 +1,1905 @@
+/***********************************************************************=
*******
+ * 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 <asm/types.h>
+
+#ifdef V4V_DEBUG
+#define v4v_dprintk(format, args...)            \
+    do {                                        \
+        printk("%s:%d " format,                 \
+               __FILE__, __LINE__, ## args );   \
+    } while ( 1 =3D=3D 0 )
+#else
+#define v4v_dprintk(format, ... ) (void)0
+#endif
+
+/*
+ * 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
+ */
+#define V4V_ROUNDUP(a) (((a) +0xf ) & ~0xf)
+
+DEFINE_XEN_GUEST_HANDLE(uint8_t);
+static struct v4v_ring_info *v4v_ring_find_info(struct domain *d,
+                                                v4v_ring_id_t *id);
+
+static struct v4v_ring_info *v4v_ring_find_info_by_addr(struct domain *d=
,
+                                                        struct v4v_addr =
*a,
+                                                        domid_t p);
+
+typedef struct internal_v4v_iov
+{
+    XEN_GUEST_HANDLE(v4v_iov_t) guest_iov;
+    v4v_iov_t                   *xen_iov;
+} internal_v4v_iov_t;
+
+struct list_head viprules =3D LIST_HEAD_INIT(viprules);
+
+/*
+ * 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
+ */
+
+/*
+ * lock to protect the filtering rules list: viprules
+ *
+ * The write lock is held for viptables_del and viptables_add
+ * The read lock is held for viptable_list
+ */
+static DEFINE_RWLOCK(viprules_lock);
+
+
+/*
+ * Debugs
+ */
+
+#ifdef V4V_DEBUG
+static void __attribute__((unused))
+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);
+
+    evtchn_send(d, d->v4v->evtchn_port);
+}
+
+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
+ */
+
+static void
+v4v_ring_unmap(struct v4v_ring_info *ring_info)
+{
+    int i;
+
+    ASSERT(spin_is_locked(&ring_info->lock));
+
+    for ( i =3D 0; i < ring_info->npage; ++i )
+    {
+        if ( !ring_info->mfn_mapping[i] )
+            continue;
+        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;
+    }
+}
+
+static uint8_t *
+v4v_ring_map_page(struct v4v_ring_info *ring_info, int i)
+{
+    ASSERT(spin_is_locked(&ring_info->lock));
+
+    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->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];
+}
+
+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;
+
+    ASSERT(spin_is_locked(&ring_info->lock));
+
+    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;
+}
+
+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);
+    uint32_t *p =3D (uint32_t *)(dst + offsetof(v4v_ring_t, tx_ptr));
+
+    ASSERT(spin_is_locked(&ring_info->lock));
+
+    if ( !dst )
+        return -EFAULT;
+    write_atomic(p, tx_ptr);
+    mb();
+    return 0;
+}
+
+static int
+v4v_copy_from_guest_maybe(void *dst, void *src,
+                          XEN_GUEST_HANDLE(uint8_t) src_hnd,
+                          uint32_t len)
+{
+    int rc =3D 0;
+
+    if ( src )
+        memcpy(dst, src, len);
+    else
+        rc =3D copy_from_guest(dst, src_hnd, len);
+    return rc;
+}
+
+static int
+v4v_memcpy_to_guest_ring(struct v4v_ring_info *ring_info,
+                         uint32_t offset,
+                         void *src,
+                         XEN_GUEST_HANDLE(uint8_t) src_hnd,
+                         uint32_t len)
+{
+    int page =3D offset >> PAGE_SHIFT;
+    uint8_t *dst;
+
+    ASSERT(spin_is_locked(&ring_info->lock));
+
+    offset &=3D PAGE_SIZE - 1;
+
+    while ( (offset + len) > PAGE_SIZE )
+    {
+        dst =3D v4v_ring_map_page(ring_info, page);
+        if ( !dst )
+            return -EFAULT;
+
+        if ( v4v_copy_from_guest_maybe(dst + offset, src, src_hnd,
+                                       PAGE_SIZE - offset) )
+            return -EFAULT;
+
+        page++;
+        len -=3D PAGE_SIZE - offset;
+        if ( src )
+            src +=3D (PAGE_SIZE - offset);
+        else
+            guest_handle_add_offset(src_hnd, PAGE_SIZE - offset);
+        offset =3D 0;
+    }
+
+    dst =3D v4v_ring_map_page(ring_info, page);
+    if ( !dst )
+        return -EFAULT;
+
+    if ( v4v_copy_from_guest_maybe(dst + offset, src, src_hnd, len) )
+        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 =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;
+
+    write_atomic(rx_ptr, ringp->rx_ptr);
+    mb();
+
+    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 =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;
+}
+
+static unsigned long
+v4v_iov_copy(v4v_iov_t *iov, internal_v4v_iov_t *iovs)
+{
+    if (iovs->xen_iov =3D=3D NULL)
+    {
+        return copy_from_guest(iov, iovs->guest_iov, 1);
+    }
+    else
+    {
+        *iov =3D *(iovs->xen_iov);
+        return 0;
+    }
+}
+
+static void
+v4v_iov_add_offset(internal_v4v_iov_t *iovs, int offset)
+{
+    if (iovs->xen_iov =3D=3D NULL)
+        guest_handle_add_offset(iovs->guest_iov, offset);
+    else
+        iovs->xen_iov +=3D offset;
+}
+
+static long
+v4v_iov_count(internal_v4v_iov_t iovs, int niov)
+{
+    v4v_iov_t iov;
+    size_t ret =3D 0;
+
+    while ( niov-- )
+    {
+        if ( v4v_iov_copy(&iov, &iovs) )
+            return -EFAULT;
+
+        /* message bigger than 2G can't be sent */
+        if (ret > 2L * 1024 * 1024 * 1024)
+            return -EMSGSIZE;
+
+        ret +=3D iov.iov_len;
+        v4v_iov_add_offset(&iovs, 1);
+    }
+
+    return ret;
+}
+
+static long
+v4v_ringbuf_insertv(struct domain *d,
+                    struct v4v_ring_info *ring_info,
+                    v4v_ring_id_t *src_id, uint32_t proto,
+                    internal_v4v_iov_t iovs, uint32_t niov,
+                    size_t len)
+{
+    v4v_ring_t ring;
+    struct v4v_ring_message_header mh =3D { 0 };
+    int32_t sp;
+    long happy_ret;
+    int32_t ret =3D 0;
+    XEN_GUEST_HANDLE(uint8_t) empty_hnd =3D { 0 };
+
+    ASSERT(spin_is_locked(&ring_info->lock));
+
+    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.message_type =3D proto;
+
+        if ( (ret =3D v4v_memcpy_to_guest_ring(ring_info,
+                                             ring.tx_ptr + sizeof (v4v_r=
ing_t),
+                                             &mh, empty_hnd,
+                                             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 ( v4v_iov_copy(&iov, &iovs) )
+            {
+                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 )
+            {
+                ret =3D v4v_memcpy_to_guest_ring(ring_info,
+                        ring.tx_ptr + sizeof (v4v_ring_t),
+                        NULL, buf_hnd, sp);
+                if ( ret )
+                    break;
+
+                ring.tx_ptr =3D 0;
+                len -=3D sp;
+                guest_handle_add_offset(buf_hnd, sp);
+            }
+
+            ret =3D v4v_memcpy_to_guest_ring(ring_info,
+                    ring.tx_ptr + sizeof (v4v_ring_t),
+                    NULL, buf_hnd, len);
+            if ( ret )
+                break;
+
+            ring.tx_ptr +=3D len;
+
+            if ( ring.tx_ptr =3D=3D ring_info->len )
+                ring.tx_ptr =3D 0;
+
+            v4v_iov_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);
+}
+
+static void
+v4v_pending_remove_all(struct v4v_ring_info *info)
+{
+    struct hlist_node *node, *next;
+    struct v4v_pending_ent *pending_ent;
+
+    ASSERT(spin_is_locked(&info->lock));
+    hlist_for_each_entry_safe(pending_ent, node, next, &info->pending,
+            node) v4v_pending_remove_ent(pending_ent);
+}
+
+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;
+
+    ASSERT(rw_is_locked(&v4v_lock));
+
+    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);
+    }
+
+}
+
+static void
+v4v_pending_find(struct domain *d, 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;
+
+    ASSERT(rw_is_locked(&d->v4v->lock));
+
+    spin_lock(&ring_info->lock);
+    hlist_for_each_entry_safe(ent, node, next, &ring_info->pending, node=
)
+    {
+        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 l=
en)
+{
+    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, int=
 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, node=
)
+    {
+        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(xen_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);
+    }
+    return ret;
+}
+
+
+static struct v4v_ring_info *
+v4v_ring_find_info(struct domain *d, v4v_ring_id_t *id)
+{
+    uint16_t hash;
+    struct hlist_node *node;
+    struct v4v_ring_info *ring_info;
+
+    ASSERT(rw_is_locked(&d->v4v->lock));
+
+    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], node=
)
+    {
+        v4v_ring_id_t *cmpid =3D &ring_info->id;
+
+        if ( cmpid->addr.port =3D=3D id->addr.port &&
+             cmpid->addr.domain =3D=3D id->addr.domain &&
+             cmpid->partner =3D=3D id->partner)
+        {
+            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;
+}
+
+static struct v4v_ring_info *
+v4v_ring_find_info_by_addr(struct domain *d, struct v4v_addr *a, domid_t=
 p)
+{
+    v4v_ring_id_t id;
+    struct v4v_ring_info *ret;
+
+    ASSERT(rw_is_locked(&d->v4v->lock));
+
+    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_ANY;
+
+    return v4v_ring_find_info(d, &id);
+}
+
+static void v4v_ring_remove_mfns(struct domain *d, struct v4v_ring_info =
*ring_info)
+{
+    int i;
+
+    ASSERT(rw_is_write_locked(&d->v4v->lock));
+
+    if ( ring_info->mfns )
+    {
+        for ( i =3D 0; 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);
+    }
+    if ( ring_info->mfn_mapping )
+        xfree(ring_info->mfn_mapping);
+    ring_info->mfns =3D NULL;
+
+}
+
+static void
+v4v_ring_remove_info(struct domain *d, struct v4v_ring_info *ring_info)
+{
+    ASSERT(rw_is_write_locked(&d->v4v->lock));
+
+    spin_lock(&ring_info->lock);
+
+    v4v_pending_remove_all(ring_info);
+    hlist_del(&ring_info->node);
+    v4v_ring_remove_mfns(d, ring_info);
+
+    spin_unlock(&ring_info->lock);
+
+    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 =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(d, 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(xen_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 rin=
g.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.
+             */
+            printk(KERN_INFO "v4v: dom%d ring already registered\n",
+                    current->domain->domain_id);
+            ret =3D -EEXIST;
+            break;
+        }
+
+        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
+ */
+
+static void
+v4v_notify_ring(struct domain *d, struct v4v_ring_info *ring_info,
+                struct hlist_head *to_notify)
+{
+    uint32_t space;
+
+    ASSERT(rw_is_locked(&v4v_lock));
+    ASSERT(rw_is_locked(&d->v4v->lock));
+
+    spin_lock(&ring_info->lock);
+    space =3D v4v_ringbuf_payload_space(d, ring_info);
+    spin_unlock(&ring_info->lock);
+
+    v4v_pending_find(d, 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, data[0]);
+                ret =3D v4v_fill_ring_datas(d, ring_data.nent, ring_data=
_ent_hnd);
+            }
+        }
+    }
+    while ( 0 );
+
+    read_unlock(&v4v_lock);
+
+    return ret;
+}
+
+#ifdef V4V_DEBUG
+void
+v4v_viptables_print_rule(struct v4v_viptables_rule_node *node)
+{
+    v4v_viptables_rule_t *rule;
+
+    if ( node =3D=3D NULL )
+    {
+        printk("(null)\n");
+        return;
+    }
+
+    rule =3D &node->rule;
+
+    if ( rule->accept =3D=3D 1 )
+        printk("ACCEPT");
+    else
+        printk("REJECT");
+
+    printk(" ");
+
+    if ( rule->src.domain =3D=3D V4V_DOMID_ANY )
+        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 V4V_DOMID_ANY )
+        printk("*");
+    else
+        printk("%i", rule->dst.domain);
+
+    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 =3D NULL;
+    struct list_head* tmp;
+
+    ASSERT(rw_is_write_locked(&viprules_lock));
+
+    /* First rule is n.1 */
+    position--;
+
+    new =3D xmalloc(struct v4v_viptables_rule_node);
+    if ( new =3D=3D NULL )
+        return -ENOMEM;
+
+    if ( copy_from_guest(&new->rule, rule, 1) )
+    {
+        xfree(new);
+        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_hnd,
+                  int32_t position)
+{
+    struct list_head *tmp =3D NULL;
+    struct list_head *next =3D NULL;
+    struct v4v_viptables_rule_node *node;
+
+    ASSERT(rw_is_write_locked(&viprules_lock));
+
+    v4v_dprintk("v4v_viptables_del position:%d\n", position);
+
+    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_hnd) )
+    {
+        struct v4v_viptables_rule r;
+
+        if ( copy_from_guest(&r, rule_hnd, 1) )
+            return -EFAULT;
+
+        list_for_each(tmp, &viprules)
+        {
+            node =3D list_entry(tmp, struct v4v_viptables_rule_node, lis=
t);
+
+            if ( (node->rule.src.domain =3D=3D r.src.domain) &&
+                 (node->rule.src.port   =3D=3D r.src.port)   &&
+                 (node->rule.dst.domain =3D=3D r.dst.domain) &&
+                 (node->rule.dst.port   =3D=3D r.dst.port))
+            {
+                position =3D 0;
+                break;
+            }
+        }
+    }
+    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, lis=
t);
+            list_del(tmp);
+            xfree(node);
+        }
+    }
+
+    if ( position =3D=3D 0 && tmp !=3D &viprules )
+    {
+        node =3D list_entry(tmp, struct v4v_viptables_rule_node, list);
+#ifdef V4V_DEBUG
+        printk(KERN_ERR "VIPTables: deleting rule: ");
+        v4v_viptables_print_rule(node);
+#endif /* V4V_DEBUG */
+        list_del(tmp);
+        xfree(node);
+    }
+
+    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;
+    XEN_GUEST_HANDLE(v4v_viptables_rule_t) guest_rules;
+
+    ASSERT(rw_is_locked(&viprules_lock));
+
+    memset(&rules_list, 0, sizeof (rules_list));
+    if ( copy_from_guest(&rules_list, list_hnd, 1) )
+        return -EFAULT;
+
+    ptr =3D viprules.next;
+    while ( rules_list.start_rule !=3D 0 && ptr->next !=3D &viprules )
+    {
+        ptr =3D ptr->next;
+        rules_list.start_rule--;
+    }
+
+    if ( rules_list.nb_rules =3D=3D 0 )
+        return -EINVAL;
+
+    guest_rules =3D guest_handle_for_field(list_hnd, v4v_viptables_rule_=
t, rules[0]);
+
+    nbrules =3D 0;
+    while ( nbrules < rules_list.nb_rules && ptr !=3D &viprules )
+    {
+        node =3D list_entry(ptr, struct v4v_viptables_rule_node, list);
+
+        if ( !guest_handle_okay(guest_rules, 1) )
+            break;
+
+        if ( copy_to_guest(guest_rules, &node->rule, 1) )
+            break;
+
+        guest_handle_add_offset(guest_rules, 1);
+
+        nbrules++;
+        ptr =3D ptr->next;
+    }
+
+    rules_list.nb_rules =3D nbrules;
+    if ( copy_field_to_guest(list_hnd, &rules_list, nb_rules) )
+        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;
+    size_t ret =3D 0; /* Defaulting to ACCEPT */
+
+    read_lock(&viprules_lock);
+
+    list_for_each(ptr, &viprules)
+    {
+        node =3D list_entry(ptr, struct v4v_viptables_rule_node, list);
+
+        if ( (node->rule.src.domain =3D=3D V4V_DOMID_ANY ||
+              node->rule.src.domain =3D=3D src->domain) &&
+             (node->rule.src.port =3D=3D V4V_PORT_ANY ||
+              node->rule.src.port =3D=3D src->port) &&
+             (node->rule.dst.domain =3D=3D V4V_DOMID_ANY ||
+              node->rule.dst.domain =3D=3D dst->domain) &&
+             (node->rule.dst.port =3D=3D V4V_PORT_ANY ||
+              node->rule.dst.port =3D=3D dst->port) )
+        {
+            ret =3D !node->rule.accept;
+            break;
+        }
+    }
+
+    read_unlock(&viprules_lock);
+    return ret;
+}
+
+/*
+ * Hypercall to do the send
+ */
+static long
+v4v_sendv(struct domain *src_d, v4v_addr_t * src_addr,
+          v4v_addr_t * dst_addr, uint32_t proto,
+          internal_v4v_iov_t iovs, size_t niov)
+{
+    struct domain *dst_d;
+    v4v_ring_id_t 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;
+    }
+
+    if ( v4v_viptables_check(src_addr, dst_addr) !=3D 0 )
+    {
+        read_unlock(&v4v_lock);
+        gdprintk(XENLOG_WARNING,
+                 "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 )
+        {
+            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->domain=
);
+
+        if ( !ring_info )
+        {
+            ret =3D -ECONNREFUSED;
+            v4v_dprintk(" !ring_info, ECONNREFUSED\n");
+        }
+        else
+        {
+            long 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, io=
vs,
+                        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;
+}
+
+static void
+v4v_info(struct domain *d, v4v_info_t *info)
+{
+    read_lock(&d->v4v->lock);
+    info->ring_magic =3D V4V_RING_MAGIC;
+    info->data_magic =3D V4V_RING_DATA_MAGIC;
+    info->evtchn =3D d->v4v->evtchn_port;
+    read_unlock(&d->v4v->lock);
+}
+
+/*
+ * hypercall glue
+ */
+long
+do_v4v_op(int cmd, XEN_GUEST_HANDLE(void) arg1,
+          XEN_GUEST_HANDLE(void) arg2,
+          uint32_t arg3, uint32_t arg4)
+{
+    struct domain *d =3D current->domain;
+    long rc =3D -EFAULT;
+
+    v4v_dprintk("->do_v4v_op(%d,%p,%p,%d,%d)\n", cmd,
+                (void *)arg1.p, (void *)arg2.p, (int) arg3, (int) arg4);
+
+    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(xen_pfn_t) pfn_hnd =3D
+                    guest_handle_cast(arg2, xen_pfn_t);
+                uint32_t npage =3D arg3;
+                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:
+            {
+                uint32_t len =3D arg3;
+                uint32_t message_type =3D arg4;
+                v4v_iov_t iov;
+                internal_v4v_iov_t iovs;
+                XEN_GUEST_HANDLE(v4v_send_addr_t) addr_hnd =3D
+                    guest_handle_cast(arg1, v4v_send_addr_t);
+                v4v_send_addr_t addr;
+
+                if ( unlikely(!guest_handle_okay(addr_hnd, 1)) )
+                    goto out;
+                if ( copy_from_guest(&addr, addr_hnd, 1) )
+                    goto out;
+
+                iov.iov_base =3D (uint64_t)arg2.p; // FIXME
+                iov.iov_len =3D len;
+                iovs.xen_iov =3D &iov;
+                rc =3D v4v_sendv(d, &addr.src, &addr.dst, message_type, =
iovs, 1);
+                break;
+            }
+        case V4VOP_sendv:
+            {
+                internal_v4v_iov_t iovs;
+                uint32_t niov =3D arg3;
+                uint32_t message_type =3D arg4;
+                XEN_GUEST_HANDLE(v4v_send_addr_t) addr_hnd =3D
+                    guest_handle_cast(arg1, v4v_send_addr_t);
+                v4v_send_addr_t addr;
+
+                memset(&iovs, 0, sizeof (iovs));
+                iovs.guest_iov =3D guest_handle_cast(arg2, v4v_iov_t);
+
+                if ( unlikely(!guest_handle_okay(addr_hnd, 1)) )
+                    goto out;
+                if ( copy_from_guest(&addr, addr_hnd, 1) )
+                    goto out;
+
+                if ( unlikely(!guest_handle_okay(iovs.guest_iov, niov)) =
)
+                    goto out;
+
+                rc =3D v4v_sendv(d, &addr.src, &addr.dst, message_type, =
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;
+            }
+        case V4VOP_viptables_add:
+            {
+                uint32_t position =3D arg3;
+                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;
+
+                write_lock(&viprules_lock);
+                rc =3D v4v_viptables_add(d, rule_hnd, position);
+                write_unlock(&viprules_lock);
+                break;
+            }
+        case V4VOP_viptables_del:
+            {
+                uint32_t position =3D arg3;
+                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;
+
+                write_lock(&viprules_lock);
+                rc =3D v4v_viptables_del(d, rule_hnd, position);
+                write_unlock(&viprules_lock);
+                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 -EFAULT;
+                if ( unlikely(!guest_handle_okay(rules_list_hnd, 1)) )
+                    goto out;
+
+                read_lock(&viprules_lock);
+                rc =3D v4v_viptables_list(d, rules_list_hnd);
+                read_unlock(&viprules_lock);
+                break;
+            }
+        case V4VOP_info:
+            {
+                XEN_GUEST_HANDLE(v4v_info_t) info_hnd =3D
+                    guest_handle_cast(arg1, v4v_info_t);
+                v4v_info_t info;
+
+                if ( unlikely(!guest_handle_okay(info_hnd, 1)) )
+                    goto out;
+                v4v_info(d, &info);
+                if ( copy_to_guest(info_hnd, &info, 1) )
+                    goto out;
+                rc =3D 0;
+                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(d, ring_info);
+            }
+        }
+    }
+
+    d->v4v =3D NULL;
+    write_unlock(&v4v_lock);
+}
+
+int
+v4v_init(struct domain *d)
+{
+    struct v4v_domain *v4v;
+    evtchn_port_t port;
+    int i;
+    int rc;
+
+    v4v =3D xmalloc(struct v4v_domain);
+    if ( !v4v )
+        return -ENOMEM;
+
+    rc =3D evtchn_alloc_unbound_domain(d, &port, d->domain_id);
+    if ( rc )
+        return rc;
+
+    rwlock_init(&v4v->lock);
+
+    v4v->evtchn_port =3D port;
+    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 npage=
=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(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], nod=
e)
+            dump_domain_ring(d, ring_info);
+    }
+
+    printk(KERN_ERR "  event channel: %d\n",  d->v4v->evtchn_port);
+    read_unlock(&d->v4v->lock);
+
+    printk(KERN_ERR "\n");
+    v4v_signal_domain(d);
+}
+
+static void
+dump_state(unsigned char key)
+{
+    struct domain *d;
+
+    printk(KERN_ERR "\n\nV4V:\n");
+    read_lock(&v4v_lock);
+
+    rcu_read_lock(&domlist_read_lock);
+
+    for_each_domain(d)
+        dump_domain(d);
+
+    rcu_read_unlock(&domlist_read_lock);
+
+    read_unlock(&v4v_lock);
+}
+
+struct keyhandler v4v_info_keyhandler =3D
+{
+    .diagnostic =3D 1,
+    .u.fn =3D dump_state,
+    .desc =3D "dump v4v states and interupt"
+};
+
+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..380ac29
--- /dev/null
+++ b/xen/include/public/v4v.h
@@ -0,0 +1,324 @@
+/***********************************************************************=
*******
+ * 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"
+#include "event_channel.h"
+
+/*
+ * Structure definitions
+ */
+
+#define V4V_RING_MAGIC          0xa822f72bb0b9d8ccULL
+#define V4V_RING_DATA_MAGIC	0x45fe852220b801d4ULL
+
+#define V4V_MESSAGE_DGRAM       0x3c2c1db8
+#define V4V_MESSAGE_STREAM 	0x70f6a8e5
+
+#define V4V_DOMID_ANY           DOMID_INVALID
+#define V4V_PORT_ANY            0
+
+typedef struct v4v_iov
+{
+    uint64_t iov_base;
+    uint32_t iov_len;
+    uint32_t pad;
+} v4v_iov_t;
+
+typedef struct v4v_addr
+{
+    uint32_t port;
+    domid_t domain;
+    uint16_t pad;
+} v4v_addr_t;
+
+typedef struct v4v_ring_id
+{
+    v4v_addr_t addr;
+    domid_t partner;
+    uint16_t pad;
+} v4v_ring_id_t;
+
+typedef struct
+{
+    v4v_addr_t src;
+    v4v_addr_t dst;
+} v4v_send_addr_t;
+
+/*
+ * v4v_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
+ *
+ */
+struct v4v_ring
+{
+    uint64_t magic;
+    v4v_ring_id_t id;
+    uint32_t len;
+    uint32_t rx_ptr;
+    uint32_t tx_ptr;
+    uint8_t reserved[32];
+#if defined(__STDC_VERSION__) && __STDC_VERSION__ >=3D 199901L
+    uint8_t ring[];
+#elif defined(__GNUC__)
+    uint8_t ring[0];
+#endif
+};
+typedef struct v4v_ring v4v_ring_t;
+
+#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 exist=
s - do not
+                                               * rely on this field - fo=
r
+                                               * profiling only */
+#define V4V_RING_DATA_F_SUFFICIENT  (1U << 3) /* Sufficient space to que=
ue
+                                               * space_required bytes ex=
ists */
+
+typedef struct v4v_ring_data_ent
+{
+    v4v_addr_t ring;
+    uint16_t flags;
+    uint16_t pad1;
+    uint32_t pad2;
+    uint32_t space_required;
+    uint32_t max_message_size;
+} v4v_ring_data_ent_t;
+
+typedef struct v4v_ring_data
+{
+    uint64_t magic;
+    uint32_t nent;
+    uint32_t pad;
+    uint64_t reserved[4];
+#if defined(__STDC_VERSION__) && __STDC_VERSION__ >=3D 199901L
+    v4v_ring_data_ent_t data[];
+#elif defined(__GNUC__)
+    v4v_ring_data_ent_t data[0];
+#endif
+} v4v_ring_data_t;
+
+struct v4v_info
+{
+    uint64_t ring_magic;
+    uint64_t data_magic;
+    evtchn_port_t evtchn;
+    uint32_t pad;
+};
+typedef struct v4v_info v4v_info_t;
+
+#define V4V_SHF_SYN		(1 << 0)
+#define V4V_SHF_ACK		(1 << 1)
+#define V4V_SHF_RST		(1 << 2)
+
+#define V4V_SHF_PING		(1 << 8)
+#define V4V_SHF_PONG		(1 << 9)
+
+struct v4v_stream_header
+{
+    uint32_t flags;
+    uint32_t conid;
+};
+
+struct v4v_ring_message_header
+{
+    uint32_t len;
+    uint32_t pad0;
+    v4v_addr_t source;
+    uint32_t message_type;
+    uint32_t pad1;
+#if defined(__STDC_VERSION__) && __STDC_VERSION__ >=3D 199901L
+    uint8_t data[];
+#elif defined(__GNUC__)
+    uint8_t data[0];
+#endif
+};
+
+typedef struct v4v_viptables_rule
+{
+    v4v_addr_t src;
+    v4v_addr_t dst;
+    uint32_t accept;
+    uint32_t pad;
+} v4v_viptables_rule_t;
+
+typedef struct v4v_viptables_list
+{
+    uint32_t start_rule;
+    uint32_t nb_rules;
+#if defined(__STDC_VERSION__) && __STDC_VERSION__ >=3D 199901L
+    struct v4v_viptables_rule rules[];
+#elif defined(__GNUC__)
+    struct v4v_viptables_rule rules[0];
+#endif
+} v4v_viptables_list_t;
+
+/*
+ * HYPERCALLS
+ */
+
+/*
+ * V4VOP_register_ring
+ *
+ * Registers a ring with Xen. If a ring with the same v4v_ring_id exists=
,
+ * the hypercall will return -EEXIST.
+ *
+ * do_v4v_op(V4VOP_unregister_ring,
+ *           XEN_GUEST_HANDLE(v4v_ring_t), XEN_GUEST_HANDLE(xen_pfn_t),
+ *           npage, 0)
+ */
+#define V4VOP_register_ring 	1
+
+
+/*
+ * V4VOP_unregister_ring
+ *
+ * Unregister a ring.
+ *
+ * do_v4v_op(V4VOP_unregister_ring,
+ *           XEN_GUEST_HANDLE(v4v_ring),
+ *           NULL, 0, 0)
+ */
+#define V4VOP_unregister_ring 	2
+
+/*
+ * V4VOP_send
+ *
+ * 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.
+ * message_type is the 32 bit number used from the message
+ * most likely V4V_MESSAGE_DGRAM or V4V_MESSAGE_STREAM. If insufficient =
space exists
+ * it will return -EAGAIN and xen will twing the V4V_INTERRUPT when
+ * sufficient space becomes available
+ *
+ * do_v4v_op(V4VOP_send,
+ *           XEN_GUEST_HANDLE(v4v_send_addr_t) addr,
+ *           XEN_GUEST_HANDLE(void) buf,
+ *           uint32_t len,
+ *           uint32_t message_type)
+ */
+#define V4VOP_send 		3
+
+
+/*
+ * V4VOP_notify
+ *
+ * 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
+ *
+ * do_v4v_op(V4VOP_notify,
+ *           XEN_GUEST_HANDLE(v4v_ring_data_ent) ent,
+ *           NULL, 0, 0)
+ */
+#define V4VOP_notify 		4
+
+/*
+ * V4VOP_sendv
+ *
+ * Identical to V4VOP_send except rather than buf and len it takes
+ * an array of v4v_iov and a length of the array.
+ *
+ * do_v4v_op(V4VOP_sendv,
+ *           XEN_GUEST_HANDLE(v4v_send_addr_t) addr,
+ *           XEN_GUEST_HANDLE(v4v_iov) iov,
+ *           uint32_t niov,
+ *           uint32_t message_type)
+ */
+#define V4VOP_sendv		5
+
+/*
+ * V4VOP_viptables_add
+ *
+ * Insert a filtering rules after a given position.
+ *
+ * do_v4v_op(V4VOP_viptables_add,
+ *           XEN_GUEST_HANDLE(v4v_viptables_rule_t) rule,
+ *           NULL,
+ *           uint32_t position, 0)
+ */
+#define V4VOP_viptables_add     6
+
+/*
+ * V4VOP_viptables_del
+ *
+ * Delete a filtering rules at a position or the rule
+ * that matches "rule".
+ *
+ * do_v4v_op(V4VOP_viptables_del,
+ *           XEN_GUEST_HANDLE(v4v_viptables_rule_t) rule,
+ *           NULL,
+ *           uint32_t position, 0)
+ */
+#define V4VOP_viptables_del     7
+
+/*
+ * V4VOP_viptables_list
+ *
+ * Delete a filtering rules at a position or the rule
+ * that matches "rule".
+ *
+ * do_v4v_op(V4VOP_viptables_list,
+ *           XEN_GUEST_HANDLE(v4v_vitpables_list_t) list,
+ *           NULL, 0, 0)
+ */
+#define V4VOP_viptables_list    8
+
+/*
+ * V4VOP_info
+ *
+ * Returns v4v info for the current domain (domain that issued the hyper=
call).
+ *      - V4V magic number
+ *      - event channel port (for current domain)
+ *
+ * do_v4v_op(V4VOP_info,
+ *           XEN_GUEST_HANDLE(v4v_info_t) info,
+ *           NULL, 0, 0)
+ */
+#define V4VOP_info              9
+
+#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 8def420..7a3fade 100644
--- a/xen/include/public/xen.h
+++ b/xen/include/public/xen.h
@@ -97,7 +97,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..296de52 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,9 @@ struct domain
     nodemask_t node_affinity;
     unsigned int last_alloc_node;
     spinlock_t node_affinity_lock;
+
+    /* v4v */
+    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..05d20b5
--- /dev/null
+++ b/xen/include/xen/v4v.h
@@ -0,0 +1,133 @@
+/***********************************************************************=
*******
+ * 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
+
+/*
+ * Handlers
+ */
+
+DEFINE_XEN_GUEST_HANDLE (v4v_iov_t);
+DEFINE_XEN_GUEST_HANDLE (v4v_addr_t);
+DEFINE_XEN_GUEST_HANDLE (v4v_send_addr_t);
+DEFINE_XEN_GUEST_HANDLE (v4v_ring_t);
+DEFINE_XEN_GUEST_HANDLE (v4v_ring_data_ent_t);
+DEFINE_XEN_GUEST_HANDLE (v4v_ring_data_t);
+DEFINE_XEN_GUEST_HANDLE (v4v_info_t);
+
+DEFINE_XEN_GUEST_HANDLE (v4v_viptables_rule_t);
+DEFINE_XEN_GUEST_HANDLE (v4v_viptables_list_t);
+
+/*
+ * Helper functions
+ */
+
+static inline uint16_t
+v4v_hash_fn (v4v_ring_id_t *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;
+};
+
+
+struct v4v_ring_info
+{
+    /* next node in the hash, protected by L2  */
+    struct hlist_node node;
+    /* this ring's id, protected by L2 */
+    v4v_ring_id_t 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;
+    /* event channel */
+    evtchn_port_t evtchn_port;
+    /* protected by L2 */
+    struct hlist_head ring_hash[V4V_HTABLE_SIZE];
+};
+
+typedef struct v4v_viptables_rule_node
+{
+    struct list_head list;
+    v4v_viptables_rule_t rule;
+} v4v_viptables_rule_node_t;
+
+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,
+                uint32_t arg3,
+                uint32_t arg4);
+
+#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 Sep 20 11:40:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Sep 2012 11: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 1TEf7l-0002gy-6H; Thu, 20 Sep 2012 11:40:53 +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 1TEf7i-0002fx-Se
	for xen-devel@lists.xensource.com; Thu, 20 Sep 2012 11:40:51 +0000
Received: from [85.158.139.83:52462] by server-9.bemta-5.messagelabs.com id
	5A/71-20529-2C00B505; Thu, 20 Sep 2012 11:40:50 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1348141233!30833223!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTA0NTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32726 invoked from network); 20 Sep 2012 11:40:35 -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;
	20 Sep 2012 11:40:35 -0000
X-IronPort-AV: E=Sophos;i="4.80,453,1344211200"; d="scan'208";a="14654088"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Sep 2012 11:40: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.279.1; Thu, 20 Sep 2012 12:40:33 +0100
Date: Thu, 20 Sep 2012 12:39:45 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Pawel Moll <pawel.moll@arm.com>
In-Reply-To: <1348135563.11116.94.camel@hornet>
Message-ID: <alpine.DEB.2.02.1209201235450.29232@kaball.uk.xensource.com>
References: <1348076658-4511-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<1348135563.11116.94.camel@hornet>
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>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Xen-devel] [PATCH] arm: introduce a DTS for Xen unprivileged
 virtual 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 Thu, 20 Sep 2012, Pawel Moll wrote:
> Morning,
> 
> On Wed, 2012-09-19 at 18:44 +0100, Stefano Stabellini wrote:
> > +/dts-v1/;
> > +
> > +/include/ "skeleton.dtsi"
> 
> Any particular reason to include skeleton? And I think it would be
> better to use #address-cells = <2> and #size-cells = <2>, to be ready
> for LPAE addresses...

good idea


> > +/ {
> > +	model = "XENVM-4.2";
> > +	compatible = "xen,xenvm-4.2", "arm,vexpress";
> > +	interrupt-parent = <&gic>;
> > +
> > +	chosen {
> > +		bootargs = "earlyprintk console=hvc0 root=/dev/xvda init=/sbin/init";
> > +	};
> > +
> > +	cpus {
> > +		#address-cells = <1>;
> > +		#size-cells = <0>;
> > +
> > +		cpu@0 {
> > +			device_type = "cpu";
> > +			compatible = "arm,cortex-a15";
> > +			reg = <0>;
> > +		};
> > +	};
> > +
> > +	memory {
> 
> Formally, it should be memory@80000000, not that I have any strong
> feelings about it :-)

OK


> > +		device_type = "memory";
> > +		reg = <0x80000000 0x08000000>;
> > +	};
> > +
> > +	gic: interrupt-controller@2c001000 {
> > +		compatible = "arm,cortex-a9-gic";
> > +		#interrupt-cells = <3>;
> > +		#address-cells = <0>;
> > +		interrupt-controller;
> > +		reg = <0x2c001000 0x1000>,
> > +		      <0x2c002000 0x100>;
> > +	};
> > +
> > +	timer {
> > +		compatible = "arm,armv7-timer";
> > +		interrupts = <1 13 0xf08>,
> > +			     <1 14 0xf08>,
> > +			     <1 11 0xf08>,
> > +			     <1 10 0xf08>;
> > +	};
> > +
> > +	hypervisor {
> > +		compatible = "xen,xen-4.2", "xen,xen";
> > +		reg = <0xb0000000 0x20000>;
> > +		interrupts = <1 15 0xf08>;
> > +	};
> 
> Is this binding documented somewhere - I mean in
> Documentation/devicetree/bindings?

Yes, it is: Documentation/devicetree/bindings/arm/xen.txt
added by: http://marc.info/?l=linux-kernel&m=134790380030990&w=2


> > +	motherboard {
> > +		arm,v2m-memory-map = "rs1";
> > +		ranges = <0 0 0x08000000 0x04000000>,
> > +			 <1 0 0x14000000 0x04000000>,
> > +			 <2 0 0x18000000 0x04000000>,
> > +			 <3 0 0x1c000000 0x04000000>,
> > +			 <4 0 0x0c000000 0x04000000>,
> > +			 <5 0 0x10000000 0x04000000>;
> > +
> > +		interrupt-map-mask = <0 0 63>;
> > +		interrupt-map = <0 0  0 &gic 0  0 4>,
> > +				<0 0  1 &gic 0  1 4>,
> > +				<0 0  2 &gic 0  2 4>,
> > +				<0 0  3 &gic 0  3 4>,
> > +				<0 0  4 &gic 0  4 4>,
> > +				<0 0  5 &gic 0  5 4>,
> > +				<0 0  6 &gic 0  6 4>,
> > +				<0 0  7 &gic 0  7 4>,
> > +				<0 0  8 &gic 0  8 4>,
> > +				<0 0  9 &gic 0  9 4>,
> > +				<0 0 10 &gic 0 10 4>,
> > +				<0 0 11 &gic 0 11 4>,
> > +				<0 0 12 &gic 0 12 4>,
> > +				<0 0 13 &gic 0 13 4>,
> > +				<0 0 14 &gic 0 14 4>,
> > +				<0 0 15 &gic 0 15 4>,
> > +				<0 0 16 &gic 0 16 4>,
> > +				<0 0 17 &gic 0 17 4>,
> > +				<0 0 18 &gic 0 18 4>,
> > +				<0 0 19 &gic 0 19 4>,
> > +				<0 0 20 &gic 0 20 4>,
> > +				<0 0 21 &gic 0 21 4>,
> > +				<0 0 22 &gic 0 22 4>,
> > +				<0 0 23 &gic 0 23 4>,
> > +				<0 0 24 &gic 0 24 4>,
> > +				<0 0 25 &gic 0 25 4>,
> > +				<0 0 26 &gic 0 26 4>,
> > +				<0 0 27 &gic 0 27 4>,
> > +				<0 0 28 &gic 0 28 4>,
> > +				<0 0 29 &gic 0 29 4>,
> > +				<0 0 30 &gic 0 30 4>,
> > +				<0 0 31 &gic 0 31 4>,
> > +				<0 0 32 &gic 0 32 4>,
> > +				<0 0 33 &gic 0 33 4>,
> > +				<0 0 34 &gic 0 34 4>,
> > +				<0 0 35 &gic 0 35 4>,
> > +				<0 0 36 &gic 0 36 4>,
> > +				<0 0 37 &gic 0 37 4>,
> > +				<0 0 38 &gic 0 38 4>,
> > +				<0 0 39 &gic 0 39 4>,
> > +				<0 0 40 &gic 0 40 4>,
> > +				<0 0 41 &gic 0 41 4>,
> > +				<0 0 42 &gic 0 42 4>;
> > +	};
> > +};
> 
> You've lost me here... You have ranges and interrupt map, but don't
> include motherboard file. Is it a mistake? If not, you could remove the
> ranges and interrupt-map, but where do you get your peripherals from
> then?

There are no peripherals apart from the ones that are already described
here (timer, gic). All the peripherals that the guest sees are virtual
devices that show up on xenbus (a virtual bus). In order to initialize
xenbus, the guest only needs the hypervisor node.  So I'll remove the
ranges and interrupt-map.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 20 11:40:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Sep 2012 11: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 1TEf7l-0002gy-6H; Thu, 20 Sep 2012 11:40:53 +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 1TEf7i-0002fx-Se
	for xen-devel@lists.xensource.com; Thu, 20 Sep 2012 11:40:51 +0000
Received: from [85.158.139.83:52462] by server-9.bemta-5.messagelabs.com id
	5A/71-20529-2C00B505; Thu, 20 Sep 2012 11:40:50 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1348141233!30833223!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTA0NTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32726 invoked from network); 20 Sep 2012 11:40:35 -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;
	20 Sep 2012 11:40:35 -0000
X-IronPort-AV: E=Sophos;i="4.80,453,1344211200"; d="scan'208";a="14654088"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Sep 2012 11:40: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.279.1; Thu, 20 Sep 2012 12:40:33 +0100
Date: Thu, 20 Sep 2012 12:39:45 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Pawel Moll <pawel.moll@arm.com>
In-Reply-To: <1348135563.11116.94.camel@hornet>
Message-ID: <alpine.DEB.2.02.1209201235450.29232@kaball.uk.xensource.com>
References: <1348076658-4511-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<1348135563.11116.94.camel@hornet>
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>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Xen-devel] [PATCH] arm: introduce a DTS for Xen unprivileged
 virtual 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 Thu, 20 Sep 2012, Pawel Moll wrote:
> Morning,
> 
> On Wed, 2012-09-19 at 18:44 +0100, Stefano Stabellini wrote:
> > +/dts-v1/;
> > +
> > +/include/ "skeleton.dtsi"
> 
> Any particular reason to include skeleton? And I think it would be
> better to use #address-cells = <2> and #size-cells = <2>, to be ready
> for LPAE addresses...

good idea


> > +/ {
> > +	model = "XENVM-4.2";
> > +	compatible = "xen,xenvm-4.2", "arm,vexpress";
> > +	interrupt-parent = <&gic>;
> > +
> > +	chosen {
> > +		bootargs = "earlyprintk console=hvc0 root=/dev/xvda init=/sbin/init";
> > +	};
> > +
> > +	cpus {
> > +		#address-cells = <1>;
> > +		#size-cells = <0>;
> > +
> > +		cpu@0 {
> > +			device_type = "cpu";
> > +			compatible = "arm,cortex-a15";
> > +			reg = <0>;
> > +		};
> > +	};
> > +
> > +	memory {
> 
> Formally, it should be memory@80000000, not that I have any strong
> feelings about it :-)

OK


> > +		device_type = "memory";
> > +		reg = <0x80000000 0x08000000>;
> > +	};
> > +
> > +	gic: interrupt-controller@2c001000 {
> > +		compatible = "arm,cortex-a9-gic";
> > +		#interrupt-cells = <3>;
> > +		#address-cells = <0>;
> > +		interrupt-controller;
> > +		reg = <0x2c001000 0x1000>,
> > +		      <0x2c002000 0x100>;
> > +	};
> > +
> > +	timer {
> > +		compatible = "arm,armv7-timer";
> > +		interrupts = <1 13 0xf08>,
> > +			     <1 14 0xf08>,
> > +			     <1 11 0xf08>,
> > +			     <1 10 0xf08>;
> > +	};
> > +
> > +	hypervisor {
> > +		compatible = "xen,xen-4.2", "xen,xen";
> > +		reg = <0xb0000000 0x20000>;
> > +		interrupts = <1 15 0xf08>;
> > +	};
> 
> Is this binding documented somewhere - I mean in
> Documentation/devicetree/bindings?

Yes, it is: Documentation/devicetree/bindings/arm/xen.txt
added by: http://marc.info/?l=linux-kernel&m=134790380030990&w=2


> > +	motherboard {
> > +		arm,v2m-memory-map = "rs1";
> > +		ranges = <0 0 0x08000000 0x04000000>,
> > +			 <1 0 0x14000000 0x04000000>,
> > +			 <2 0 0x18000000 0x04000000>,
> > +			 <3 0 0x1c000000 0x04000000>,
> > +			 <4 0 0x0c000000 0x04000000>,
> > +			 <5 0 0x10000000 0x04000000>;
> > +
> > +		interrupt-map-mask = <0 0 63>;
> > +		interrupt-map = <0 0  0 &gic 0  0 4>,
> > +				<0 0  1 &gic 0  1 4>,
> > +				<0 0  2 &gic 0  2 4>,
> > +				<0 0  3 &gic 0  3 4>,
> > +				<0 0  4 &gic 0  4 4>,
> > +				<0 0  5 &gic 0  5 4>,
> > +				<0 0  6 &gic 0  6 4>,
> > +				<0 0  7 &gic 0  7 4>,
> > +				<0 0  8 &gic 0  8 4>,
> > +				<0 0  9 &gic 0  9 4>,
> > +				<0 0 10 &gic 0 10 4>,
> > +				<0 0 11 &gic 0 11 4>,
> > +				<0 0 12 &gic 0 12 4>,
> > +				<0 0 13 &gic 0 13 4>,
> > +				<0 0 14 &gic 0 14 4>,
> > +				<0 0 15 &gic 0 15 4>,
> > +				<0 0 16 &gic 0 16 4>,
> > +				<0 0 17 &gic 0 17 4>,
> > +				<0 0 18 &gic 0 18 4>,
> > +				<0 0 19 &gic 0 19 4>,
> > +				<0 0 20 &gic 0 20 4>,
> > +				<0 0 21 &gic 0 21 4>,
> > +				<0 0 22 &gic 0 22 4>,
> > +				<0 0 23 &gic 0 23 4>,
> > +				<0 0 24 &gic 0 24 4>,
> > +				<0 0 25 &gic 0 25 4>,
> > +				<0 0 26 &gic 0 26 4>,
> > +				<0 0 27 &gic 0 27 4>,
> > +				<0 0 28 &gic 0 28 4>,
> > +				<0 0 29 &gic 0 29 4>,
> > +				<0 0 30 &gic 0 30 4>,
> > +				<0 0 31 &gic 0 31 4>,
> > +				<0 0 32 &gic 0 32 4>,
> > +				<0 0 33 &gic 0 33 4>,
> > +				<0 0 34 &gic 0 34 4>,
> > +				<0 0 35 &gic 0 35 4>,
> > +				<0 0 36 &gic 0 36 4>,
> > +				<0 0 37 &gic 0 37 4>,
> > +				<0 0 38 &gic 0 38 4>,
> > +				<0 0 39 &gic 0 39 4>,
> > +				<0 0 40 &gic 0 40 4>,
> > +				<0 0 41 &gic 0 41 4>,
> > +				<0 0 42 &gic 0 42 4>;
> > +	};
> > +};
> 
> You've lost me here... You have ranges and interrupt map, but don't
> include motherboard file. Is it a mistake? If not, you could remove the
> ranges and interrupt-map, but where do you get your peripherals from
> then?

There are no peripherals apart from the ones that are already described
here (timer, gic). All the peripherals that the guest sees are virtual
devices that show up on xenbus (a virtual bus). In order to initialize
xenbus, the guest only needs the hypervisor node.  So I'll remove the
ranges and interrupt-map.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 20 11:41:01 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Sep 2012 11:41:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TEf7o-0002jE-KJ; Thu, 20 Sep 2012 11:40:56 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <hahn@univention.de>) id 1TEf7n-0002i7-Pu
	for xen-devel@lists.xen.org; Thu, 20 Sep 2012 11:40:56 +0000
Received: from [85.158.137.99:27437] by server-2.bemta-3.messagelabs.com id
	52/31-04862-7C00B505; Thu, 20 Sep 2012 11:40:55 +0000
X-Env-Sender: hahn@univention.de
X-Msg-Ref: server-11.tower-217.messagelabs.com!1348141254!17258499!1
X-Originating-IP: [82.198.197.8]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19218 invoked from network); 20 Sep 2012 11:40:54 -0000
Received: from mail.univention.de (HELO mail.univention.de) (82.198.197.8)
	by server-11.tower-217.messagelabs.com with SMTP;
	20 Sep 2012 11:40:54 -0000
Received: from localhost (localhost [127.0.0.1])
	by slugis.knut.univention.de (Postfix) with ESMTP id 027A6164B110;
	Thu, 20 Sep 2012 13:40:55 +0200 (CEST)
Received: from localhost (localhost [127.0.0.1])
	by slugis.knut.univention.de (Postfix) with ESMTP id EB53D164B113;
	Thu, 20 Sep 2012 13:40:54 +0200 (CEST)
X-Virus-Scanned: by amavisd-new-2.6.1 (20080629) (Debian) at knut.univention.de
Received: from mail.univention.de ([127.0.0.1])
	by localhost (slugis.knut.univention.de [127.0.0.1]) (amavisd-new,
	port 10024)
	with ESMTP id QjEPx11l6GYX; Thu, 20 Sep 2012 13:40:54 +0200 (CEST)
Received: from stave.knut.univention.de (mail.univention.de [82.198.197.8])
	by slugis.knut.univention.de (Postfix) with ESMTPSA id 4D682164B110;
	Thu, 20 Sep 2012 13:40:54 +0200 (CEST)
From: Philipp Hahn <hahn@univention.de>
Organization: Univention.de
To: George Dunlap <George.Dunlap@eu.citrix.com>
Date: Thu, 20 Sep 2012 13:40:47 +0200
User-Agent: KMail/1.9.10 (enterprise35 20100903.1171286)
References: <CAFLBxZYtmJ_bKFb90r45=C4Pq1-oe5Fy=eygSsQf4BcGj3EqGA@mail.gmail.com>
	<201209191918.35305.hahn@univention.de>
	<CAFLBxZZko72sMVPr9LEyea7E-tNx74qCvRoxqPZ-eWbvhvctgQ@mail.gmail.com>
In-Reply-To: <CAFLBxZZko72sMVPr9LEyea7E-tNx74qCvRoxqPZ-eWbvhvctgQ@mail.gmail.com>
X-KMail-QuotePrefix: > 
MIME-Version: 1.0
Message-Id: <201209201340.52218.hahn@univention.de>
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Xen 4.3 development 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: multipart/mixed; boundary="===============1941833846458576013=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============1941833846458576013==
Content-Type: multipart/signed;
  boundary="nextPart6274970.quzCOyVfbW";
  protocol="application/pgp-signature";
  micalg=pgp-sha1
Content-Transfer-Encoding: 7bit

--nextPart6274970.quzCOyVfbW
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Hello George,

Am Donnerstag 20 September 2012 12:24:39 schrieb George Dunlap:
> On Wed, Sep 19, 2012 at 6:18 PM, Philipp Hahn <hahn@univention.de> wrote:
> > On Wednesday 19 September 2012 18:58:02 George Dunlap wrote:
> >> * libvirt integration
=2E..
> > Libvirt already has a comparison matrix at
> > <http://libvirt.org/hvsupport.html>. That file is actually generated fr=
om
> > by docs/hvsupport.pl by looking at the implemented functions.
>
> Ah, very interesting -- so "libxl" is the one we particularly care
> about.  "Xen" is presumably "xm"?  Would KVM fall under "qemu"?

Yes, that's all correct.
The current "Xen" implementation is a mixture of Xend + direct xenstore=20
accress + direct hypervisor access + inotify monitor on xm files.

> I guess the next step would be for someone to go through and identify
> user-level features that would be enabled by the various functions, so
> that we can figure out which functions are important to us.

Top on my wish list would be virDomainMigrate*, because migration is availa=
ble=20
with the old Xend driver, but not with the newer libxl.
It would probably help alot, if first those things already available via th=
e=20
old Xend would be added, since this would allow libvirt to deprecate the Xe=
nd=20
part there as well.

Sincerely
Philipp
=2D-=20
Philipp Hahn           Open Source Software Engineer      hahn@univention.de
Univention GmbH        be open.                       fon: +49 421 22 232- 0
Mary-Somerville-Str.1  D-28359 Bremen                 fax: +49 421 22 232-99
                                                   http://www.univention.de/

--nextPart6274970.quzCOyVfbW
Content-Type: application/pgp-signature; name=signature.asc 
Content-Description: This is a digitally signed message part.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEABECAAYFAlBbAL8ACgkQYPlgoZpUDjmVPACdFx9sIZReFhlAfn3OfUZD+rKn
Eg0AoMBVAwJDQV9uBkZwhG9A0KO2ogMw
=1tpF
-----END PGP SIGNATURE-----

--nextPart6274970.quzCOyVfbW--


--===============1941833846458576013==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============1941833846458576013==--


From xen-devel-bounces@lists.xen.org Thu Sep 20 11:41:01 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Sep 2012 11:41:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TEf7o-0002jE-KJ; Thu, 20 Sep 2012 11:40:56 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <hahn@univention.de>) id 1TEf7n-0002i7-Pu
	for xen-devel@lists.xen.org; Thu, 20 Sep 2012 11:40:56 +0000
Received: from [85.158.137.99:27437] by server-2.bemta-3.messagelabs.com id
	52/31-04862-7C00B505; Thu, 20 Sep 2012 11:40:55 +0000
X-Env-Sender: hahn@univention.de
X-Msg-Ref: server-11.tower-217.messagelabs.com!1348141254!17258499!1
X-Originating-IP: [82.198.197.8]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19218 invoked from network); 20 Sep 2012 11:40:54 -0000
Received: from mail.univention.de (HELO mail.univention.de) (82.198.197.8)
	by server-11.tower-217.messagelabs.com with SMTP;
	20 Sep 2012 11:40:54 -0000
Received: from localhost (localhost [127.0.0.1])
	by slugis.knut.univention.de (Postfix) with ESMTP id 027A6164B110;
	Thu, 20 Sep 2012 13:40:55 +0200 (CEST)
Received: from localhost (localhost [127.0.0.1])
	by slugis.knut.univention.de (Postfix) with ESMTP id EB53D164B113;
	Thu, 20 Sep 2012 13:40:54 +0200 (CEST)
X-Virus-Scanned: by amavisd-new-2.6.1 (20080629) (Debian) at knut.univention.de
Received: from mail.univention.de ([127.0.0.1])
	by localhost (slugis.knut.univention.de [127.0.0.1]) (amavisd-new,
	port 10024)
	with ESMTP id QjEPx11l6GYX; Thu, 20 Sep 2012 13:40:54 +0200 (CEST)
Received: from stave.knut.univention.de (mail.univention.de [82.198.197.8])
	by slugis.knut.univention.de (Postfix) with ESMTPSA id 4D682164B110;
	Thu, 20 Sep 2012 13:40:54 +0200 (CEST)
From: Philipp Hahn <hahn@univention.de>
Organization: Univention.de
To: George Dunlap <George.Dunlap@eu.citrix.com>
Date: Thu, 20 Sep 2012 13:40:47 +0200
User-Agent: KMail/1.9.10 (enterprise35 20100903.1171286)
References: <CAFLBxZYtmJ_bKFb90r45=C4Pq1-oe5Fy=eygSsQf4BcGj3EqGA@mail.gmail.com>
	<201209191918.35305.hahn@univention.de>
	<CAFLBxZZko72sMVPr9LEyea7E-tNx74qCvRoxqPZ-eWbvhvctgQ@mail.gmail.com>
In-Reply-To: <CAFLBxZZko72sMVPr9LEyea7E-tNx74qCvRoxqPZ-eWbvhvctgQ@mail.gmail.com>
X-KMail-QuotePrefix: > 
MIME-Version: 1.0
Message-Id: <201209201340.52218.hahn@univention.de>
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Xen 4.3 development 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: multipart/mixed; boundary="===============1941833846458576013=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============1941833846458576013==
Content-Type: multipart/signed;
  boundary="nextPart6274970.quzCOyVfbW";
  protocol="application/pgp-signature";
  micalg=pgp-sha1
Content-Transfer-Encoding: 7bit

--nextPart6274970.quzCOyVfbW
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Hello George,

Am Donnerstag 20 September 2012 12:24:39 schrieb George Dunlap:
> On Wed, Sep 19, 2012 at 6:18 PM, Philipp Hahn <hahn@univention.de> wrote:
> > On Wednesday 19 September 2012 18:58:02 George Dunlap wrote:
> >> * libvirt integration
=2E..
> > Libvirt already has a comparison matrix at
> > <http://libvirt.org/hvsupport.html>. That file is actually generated fr=
om
> > by docs/hvsupport.pl by looking at the implemented functions.
>
> Ah, very interesting -- so "libxl" is the one we particularly care
> about.  "Xen" is presumably "xm"?  Would KVM fall under "qemu"?

Yes, that's all correct.
The current "Xen" implementation is a mixture of Xend + direct xenstore=20
accress + direct hypervisor access + inotify monitor on xm files.

> I guess the next step would be for someone to go through and identify
> user-level features that would be enabled by the various functions, so
> that we can figure out which functions are important to us.

Top on my wish list would be virDomainMigrate*, because migration is availa=
ble=20
with the old Xend driver, but not with the newer libxl.
It would probably help alot, if first those things already available via th=
e=20
old Xend would be added, since this would allow libvirt to deprecate the Xe=
nd=20
part there as well.

Sincerely
Philipp
=2D-=20
Philipp Hahn           Open Source Software Engineer      hahn@univention.de
Univention GmbH        be open.                       fon: +49 421 22 232- 0
Mary-Somerville-Str.1  D-28359 Bremen                 fax: +49 421 22 232-99
                                                   http://www.univention.de/

--nextPart6274970.quzCOyVfbW
Content-Type: application/pgp-signature; name=signature.asc 
Content-Description: This is a digitally signed message part.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEABECAAYFAlBbAL8ACgkQYPlgoZpUDjmVPACdFx9sIZReFhlAfn3OfUZD+rKn
Eg0AoMBVAwJDQV9uBkZwhG9A0KO2ogMw
=1tpF
-----END PGP SIGNATURE-----

--nextPart6274970.quzCOyVfbW--


--===============1941833846458576013==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============1941833846458576013==--


From xen-devel-bounces@lists.xen.org Thu Sep 20 11:44:39 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Sep 2012 11:44: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 1TEfBI-0003Vi-AB; Thu, 20 Sep 2012 11:44: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 1TEfBG-0003VH-GW
	for xen-devel@lists.xen.org; Thu, 20 Sep 2012 11:44:30 +0000
Received: from [85.158.139.211:7959] by server-7.bemta-5.messagelabs.com id
	2E/F0-19703-D910B505; Thu, 20 Sep 2012 11:44:29 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-2.tower-206.messagelabs.com!1348141468!19293599!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31145 invoked from network); 20 Sep 2012 11:44:28 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-2.tower-206.messagelabs.com with SMTP;
	20 Sep 2012 11:44:28 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 20 Sep 2012 12:44:33 +0100
Message-Id: <505B1DD1020000780009CA59@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 20 Sep 2012 12:44:49 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "George Dunlap" <george.dunlap@eu.citrix.com>
References: <CAFLBxZYtmJ_bKFb90r45=C4Pq1-oe5Fy=eygSsQf4BcGj3EqGA@mail.gmail.com>
	<505ADBCF020000780009C7BE@nat28.tlf.novell.com>
	<CAFLBxZZAYBjYxX4K_LBE+dvkH8D9rfeAy538n4ACcQr=+bew8g@mail.gmail.com>
	<505B197D020000780009C9FB@nat28.tlf.novell.com>
	<505AFF10.7060107@eu.citrix.com>
In-Reply-To: <505AFF10.7060107@eu.citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.3 development 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 20.09.12 at 13:33, George Dunlap <george.dunlap@eu.citrix.com> wrote:
> On 20/09/12 12:26, Jan Beulich wrote:
>>
>> Indeed this might be more than we want/need. With my response
>> I just wanted to clarify that while I would like to see these two things
>> to happen, it's unlikely that I'm going to be able to do anything about
>> them for the time being (so listing them as un-owned rather than
>> owned by me would presumably be the better choice).
> Right -- well they were added to the list because you said you were 
> going to be working on them; so if you're not, shall I just take them off?

I think keeping them un-owned would be preferable, to draw
people's attention. The console situation really needs
improvement; the EHCI debug port thing was just a first step.
But in the end it's you to decide, as you'll have to maintain the
list...

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 20 11:44:39 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Sep 2012 11:44: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 1TEfBI-0003Vi-AB; Thu, 20 Sep 2012 11:44: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 1TEfBG-0003VH-GW
	for xen-devel@lists.xen.org; Thu, 20 Sep 2012 11:44:30 +0000
Received: from [85.158.139.211:7959] by server-7.bemta-5.messagelabs.com id
	2E/F0-19703-D910B505; Thu, 20 Sep 2012 11:44:29 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-2.tower-206.messagelabs.com!1348141468!19293599!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31145 invoked from network); 20 Sep 2012 11:44:28 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-2.tower-206.messagelabs.com with SMTP;
	20 Sep 2012 11:44:28 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 20 Sep 2012 12:44:33 +0100
Message-Id: <505B1DD1020000780009CA59@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 20 Sep 2012 12:44:49 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "George Dunlap" <george.dunlap@eu.citrix.com>
References: <CAFLBxZYtmJ_bKFb90r45=C4Pq1-oe5Fy=eygSsQf4BcGj3EqGA@mail.gmail.com>
	<505ADBCF020000780009C7BE@nat28.tlf.novell.com>
	<CAFLBxZZAYBjYxX4K_LBE+dvkH8D9rfeAy538n4ACcQr=+bew8g@mail.gmail.com>
	<505B197D020000780009C9FB@nat28.tlf.novell.com>
	<505AFF10.7060107@eu.citrix.com>
In-Reply-To: <505AFF10.7060107@eu.citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.3 development 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 20.09.12 at 13:33, George Dunlap <george.dunlap@eu.citrix.com> wrote:
> On 20/09/12 12:26, Jan Beulich wrote:
>>
>> Indeed this might be more than we want/need. With my response
>> I just wanted to clarify that while I would like to see these two things
>> to happen, it's unlikely that I'm going to be able to do anything about
>> them for the time being (so listing them as un-owned rather than
>> owned by me would presumably be the better choice).
> Right -- well they were added to the list because you said you were 
> going to be working on them; so if you're not, shall I just take them off?

I think keeping them un-owned would be preferable, to draw
people's attention. The console situation really needs
improvement; the EHCI debug port thing was just a first step.
But in the end it's you to decide, as you'll have to maintain the
list...

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 20 11:48:31 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Sep 2012 11: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 1TEfF1-0003jO-V8; Thu, 20 Sep 2012 11:48: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 1TEfEz-0003jG-MZ
	for xen-devel@lists.xen.org; Thu, 20 Sep 2012 11:48:21 +0000
Received: from [85.158.139.211:64574] by server-9.bemta-5.messagelabs.com id
	E6/11-20529-5820B505; Thu, 20 Sep 2012 11:48:21 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-6.tower-206.messagelabs.com!1348141700!19314619!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5342 invoked from network); 20 Sep 2012 11:48:20 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-6.tower-206.messagelabs.com with SMTP;
	20 Sep 2012 11:48:20 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 20 Sep 2012 12:48:26 +0100
Message-Id: <505B1EB9020000780009CA6E@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 20 Sep 2012 12:48:41 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "David Vrabel" <david.vrabel@citrix.com>,
	"Oliver Chick" <oliver.chick@citrix.com>
References: <1348051887-21885-1-git-send-email-oliver.chick@citrix.com>
	<505AF126.2050806@citrix.com>
	<1348140637.24539.32.camel@oliverchick-Precision-WorkStation-T3400>
In-Reply-To: <1348140637.24539.32.camel@oliverchick-Precision-WorkStation-T3400>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] Persistent grant maps for xen blk drivers
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 20.09.12 at 13:30, Oliver Chick <oliver.chick@citrix.com> wrote:
> The memory overhead, and fallback mode points are related:
> -Firstly, it turns out that the overhead is actually 2.75MB, not 11MB
> per device. I made a mistake (pointed out by Jan) as the maximum number
> of requests that can fit into a single-page ring is 64, not 256.
> -Clearly, this still scales linearly. So the problem of memory footprint
> will occur with more VMs, or block devices.
> -Whilst 2.75MB per device is probably acceptable (?), if we start using
> multipage rings, then we might not want to have
> BLKIF_MAX_PERS_REQUESTS_PER_DEVICE==__RING_SIZE, as this will cause the
> memory overhead to increase. This is why I have implemented the
> 'fallback' mode. With a multipage ring, it seems reasonable to want the
> first $x$ grefs seen by blkback to be treated as persistent, and any
> later ones to be non-persistent. Does that seem sensible?

>From a resource usage pov, perhaps. But this will get the guest
entirely unpredictable performance. Plus I don't think 11Mb of
_virtual_ space is unacceptable overhead in a 64-bit kernel. If
you really want/need this in a 32-bit one, then perhaps some
other alternatives would be needed (and persistent grants may
not be the right approach there in the first place).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 20 11:48:31 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Sep 2012 11: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 1TEfF1-0003jO-V8; Thu, 20 Sep 2012 11:48: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 1TEfEz-0003jG-MZ
	for xen-devel@lists.xen.org; Thu, 20 Sep 2012 11:48:21 +0000
Received: from [85.158.139.211:64574] by server-9.bemta-5.messagelabs.com id
	E6/11-20529-5820B505; Thu, 20 Sep 2012 11:48:21 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-6.tower-206.messagelabs.com!1348141700!19314619!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5342 invoked from network); 20 Sep 2012 11:48:20 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-6.tower-206.messagelabs.com with SMTP;
	20 Sep 2012 11:48:20 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 20 Sep 2012 12:48:26 +0100
Message-Id: <505B1EB9020000780009CA6E@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 20 Sep 2012 12:48:41 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "David Vrabel" <david.vrabel@citrix.com>,
	"Oliver Chick" <oliver.chick@citrix.com>
References: <1348051887-21885-1-git-send-email-oliver.chick@citrix.com>
	<505AF126.2050806@citrix.com>
	<1348140637.24539.32.camel@oliverchick-Precision-WorkStation-T3400>
In-Reply-To: <1348140637.24539.32.camel@oliverchick-Precision-WorkStation-T3400>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] Persistent grant maps for xen blk drivers
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 20.09.12 at 13:30, Oliver Chick <oliver.chick@citrix.com> wrote:
> The memory overhead, and fallback mode points are related:
> -Firstly, it turns out that the overhead is actually 2.75MB, not 11MB
> per device. I made a mistake (pointed out by Jan) as the maximum number
> of requests that can fit into a single-page ring is 64, not 256.
> -Clearly, this still scales linearly. So the problem of memory footprint
> will occur with more VMs, or block devices.
> -Whilst 2.75MB per device is probably acceptable (?), if we start using
> multipage rings, then we might not want to have
> BLKIF_MAX_PERS_REQUESTS_PER_DEVICE==__RING_SIZE, as this will cause the
> memory overhead to increase. This is why I have implemented the
> 'fallback' mode. With a multipage ring, it seems reasonable to want the
> first $x$ grefs seen by blkback to be treated as persistent, and any
> later ones to be non-persistent. Does that seem sensible?

>From a resource usage pov, perhaps. But this will get the guest
entirely unpredictable performance. Plus I don't think 11Mb of
_virtual_ space is unacceptable overhead in a 64-bit kernel. If
you really want/need this in a 32-bit one, then perhaps some
other alternatives would be needed (and persistent grants may
not be the right approach there in the first place).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 20 11:55:49 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Sep 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 1TEfM0-0003tL-Rw; Thu, 20 Sep 2012 11:55:36 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <pawel.moll@arm.com>) id 1TEfM0-0003tG-6U
	for xen-devel@lists.xensource.com; Thu, 20 Sep 2012 11:55:36 +0000
Received: from [85.158.139.211:4727] by server-1.bemta-5.messagelabs.com id
	4E/FB-04809-7340B505; Thu, 20 Sep 2012 11:55:35 +0000
X-Env-Sender: pawel.moll@arm.com
X-Msg-Ref: server-9.tower-206.messagelabs.com!1348142134!17800345!1
X-Originating-IP: [91.220.42.44]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogOTEuMjIwLjQyLjQ0ID0+IDI5ODkzOA==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4465 invoked from network); 20 Sep 2012 11:55:34 -0000
Received: from service87.mimecast.com (HELO service87.mimecast.com)
	(91.220.42.44) by server-9.tower-206.messagelabs.com with SMTP;
	20 Sep 2012 11:55:34 -0000
Received: from cam-owa1.Emea.Arm.com (fw-tnat.cambridge.arm.com
	[217.140.96.21]) by service87.mimecast.com;
	Thu, 20 Sep 2012 12:55:34 +0100
Received: from [10.1.205.42] ([10.1.255.212]) by cam-owa1.Emea.Arm.com with
	Microsoft SMTPSVC(6.0.3790.0); Thu, 20 Sep 2012 12:55:34 +0100
Message-ID: <1348142133.11116.109.camel@hornet>
From: Pawel Moll <pawel.moll@arm.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Thu, 20 Sep 2012 12:55:33 +0100
In-Reply-To: <alpine.DEB.2.02.1209201235450.29232@kaball.uk.xensource.com>
References: <1348076658-4511-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<1348135563.11116.94.camel@hornet>
	<alpine.DEB.2.02.1209201235450.29232@kaball.uk.xensource.com>
X-Mailer: Evolution 3.2.3-0ubuntu6
Mime-Version: 1.0
X-OriginalArrivalTime: 20 Sep 2012 11:55:34.0167 (UTC)
	FILETIME=[D761BA70:01CD9726]
X-MC-Unique: 112092012553402201
Cc: "linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH] arm: introduce a DTS for Xen unprivileged
 virtual 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="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gVGh1LCAyMDEyLTA5LTIwIGF0IDEyOjM5ICswMTAwLCBTdGVmYW5vIFN0YWJlbGxpbmkgd3Jv
dGU6Cj4gVGhlcmUgYXJlIG5vIHBlcmlwaGVyYWxzIGFwYXJ0IGZyb20gdGhlIG9uZXMgdGhhdCBh
cmUgYWxyZWFkeSBkZXNjcmliZWQKPiBoZXJlICh0aW1lciwgZ2ljKS4gQWxsIHRoZSBwZXJpcGhl
cmFscyB0aGF0IHRoZSBndWVzdCBzZWVzIGFyZSB2aXJ0dWFsCj4gZGV2aWNlcyB0aGF0IHNob3cg
dXAgb24geGVuYnVzIChhIHZpcnR1YWwgYnVzKS4gSW4gb3JkZXIgdG8gaW5pdGlhbGl6ZQo+IHhl
bmJ1cywgdGhlIGd1ZXN0IG9ubHkgbmVlZHMgdGhlIGh5cGVydmlzb3Igbm9kZS4gIFNvIEknbGwg
cmVtb3ZlIHRoZQo+IHJhbmdlcyBhbmQgaW50ZXJydXB0LW1hcC4KClNvIGFsbCB0aGUgcGVyaXBo
ZXJhbHMgYXJlIGFjdHVhbGx5IGRpc2NvdmVyYWJsZSAtIGF3ZXNvbWUhCgpCdXQgdGhlIGZhY3Qg
aXMgdGhhdCB0aGUgb25seSAidmV4cHJlc3NuZXNzIiBvZiB0aGlzIHRyZWUgaXMKbWVtb3J5QDgw
MDAwMDAwIGFuZCBnaWNAMmMwMDEwMDAuIFRoZSByZXN0IChub3QgbXVjaCBvZiBpdCA7LSkgaXMg
YQoiZ2VuZXJpYyBBMTUgcGxhdGZvcm0iLiAKCkkgdW5kZXJzdGFuZCB0aGF0IHlvdSBoYWQgdG8g
dXNlIHNvbWUgImNvbXBhdGlibGUiIHZhbHVlIHRvIGdldAppbml0aWFsaXphdGlvbiBjb2RlIGFu
ZCBJJ20gZmxhdHRlcmVkIDstKSBieSB5b3VyIGNob2ljZSBvZgoiYXJtLHZleHByZXNzIiwgYnV0
IG1heWJlIC0gYXMgc3VnZ2VzdGVkIGJ5IG90aGVycyAtIHlvdSB3b3VsZCBiZSBiZXR0ZXIKb2Zm
IHdpdGggZ2VuZXJhdGluZyB0aGlzIHN0dWZmIGluIHJ1bnRpbWUsIGJ5IHdoYXRldmVyIHRvb2wg
aXMgdXNlZCB0bwppbnN0YW50aWF0ZSB0aGUgZ3Vlc3Q/CgpQYXdlxYIKCgoKCl9fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxp
c3QKWGVuLWRldmVsQGxpc3RzLnhlbi5vcmcKaHR0cDovL2xpc3RzLnhlbi5vcmcveGVuLWRldmVs
Cg==

From xen-devel-bounces@lists.xen.org Thu Sep 20 11:55:49 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Sep 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 1TEfM0-0003tL-Rw; Thu, 20 Sep 2012 11:55:36 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <pawel.moll@arm.com>) id 1TEfM0-0003tG-6U
	for xen-devel@lists.xensource.com; Thu, 20 Sep 2012 11:55:36 +0000
Received: from [85.158.139.211:4727] by server-1.bemta-5.messagelabs.com id
	4E/FB-04809-7340B505; Thu, 20 Sep 2012 11:55:35 +0000
X-Env-Sender: pawel.moll@arm.com
X-Msg-Ref: server-9.tower-206.messagelabs.com!1348142134!17800345!1
X-Originating-IP: [91.220.42.44]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogOTEuMjIwLjQyLjQ0ID0+IDI5ODkzOA==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4465 invoked from network); 20 Sep 2012 11:55:34 -0000
Received: from service87.mimecast.com (HELO service87.mimecast.com)
	(91.220.42.44) by server-9.tower-206.messagelabs.com with SMTP;
	20 Sep 2012 11:55:34 -0000
Received: from cam-owa1.Emea.Arm.com (fw-tnat.cambridge.arm.com
	[217.140.96.21]) by service87.mimecast.com;
	Thu, 20 Sep 2012 12:55:34 +0100
Received: from [10.1.205.42] ([10.1.255.212]) by cam-owa1.Emea.Arm.com with
	Microsoft SMTPSVC(6.0.3790.0); Thu, 20 Sep 2012 12:55:34 +0100
Message-ID: <1348142133.11116.109.camel@hornet>
From: Pawel Moll <pawel.moll@arm.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Thu, 20 Sep 2012 12:55:33 +0100
In-Reply-To: <alpine.DEB.2.02.1209201235450.29232@kaball.uk.xensource.com>
References: <1348076658-4511-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<1348135563.11116.94.camel@hornet>
	<alpine.DEB.2.02.1209201235450.29232@kaball.uk.xensource.com>
X-Mailer: Evolution 3.2.3-0ubuntu6
Mime-Version: 1.0
X-OriginalArrivalTime: 20 Sep 2012 11:55:34.0167 (UTC)
	FILETIME=[D761BA70:01CD9726]
X-MC-Unique: 112092012553402201
Cc: "linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH] arm: introduce a DTS for Xen unprivileged
 virtual 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="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gVGh1LCAyMDEyLTA5LTIwIGF0IDEyOjM5ICswMTAwLCBTdGVmYW5vIFN0YWJlbGxpbmkgd3Jv
dGU6Cj4gVGhlcmUgYXJlIG5vIHBlcmlwaGVyYWxzIGFwYXJ0IGZyb20gdGhlIG9uZXMgdGhhdCBh
cmUgYWxyZWFkeSBkZXNjcmliZWQKPiBoZXJlICh0aW1lciwgZ2ljKS4gQWxsIHRoZSBwZXJpcGhl
cmFscyB0aGF0IHRoZSBndWVzdCBzZWVzIGFyZSB2aXJ0dWFsCj4gZGV2aWNlcyB0aGF0IHNob3cg
dXAgb24geGVuYnVzIChhIHZpcnR1YWwgYnVzKS4gSW4gb3JkZXIgdG8gaW5pdGlhbGl6ZQo+IHhl
bmJ1cywgdGhlIGd1ZXN0IG9ubHkgbmVlZHMgdGhlIGh5cGVydmlzb3Igbm9kZS4gIFNvIEknbGwg
cmVtb3ZlIHRoZQo+IHJhbmdlcyBhbmQgaW50ZXJydXB0LW1hcC4KClNvIGFsbCB0aGUgcGVyaXBo
ZXJhbHMgYXJlIGFjdHVhbGx5IGRpc2NvdmVyYWJsZSAtIGF3ZXNvbWUhCgpCdXQgdGhlIGZhY3Qg
aXMgdGhhdCB0aGUgb25seSAidmV4cHJlc3NuZXNzIiBvZiB0aGlzIHRyZWUgaXMKbWVtb3J5QDgw
MDAwMDAwIGFuZCBnaWNAMmMwMDEwMDAuIFRoZSByZXN0IChub3QgbXVjaCBvZiBpdCA7LSkgaXMg
YQoiZ2VuZXJpYyBBMTUgcGxhdGZvcm0iLiAKCkkgdW5kZXJzdGFuZCB0aGF0IHlvdSBoYWQgdG8g
dXNlIHNvbWUgImNvbXBhdGlibGUiIHZhbHVlIHRvIGdldAppbml0aWFsaXphdGlvbiBjb2RlIGFu
ZCBJJ20gZmxhdHRlcmVkIDstKSBieSB5b3VyIGNob2ljZSBvZgoiYXJtLHZleHByZXNzIiwgYnV0
IG1heWJlIC0gYXMgc3VnZ2VzdGVkIGJ5IG90aGVycyAtIHlvdSB3b3VsZCBiZSBiZXR0ZXIKb2Zm
IHdpdGggZ2VuZXJhdGluZyB0aGlzIHN0dWZmIGluIHJ1bnRpbWUsIGJ5IHdoYXRldmVyIHRvb2wg
aXMgdXNlZCB0bwppbnN0YW50aWF0ZSB0aGUgZ3Vlc3Q/CgpQYXdlxYIKCgoKCl9fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxp
c3QKWGVuLWRldmVsQGxpc3RzLnhlbi5vcmcKaHR0cDovL2xpc3RzLnhlbi5vcmcveGVuLWRldmVs
Cg==

From xen-devel-bounces@lists.xen.org Thu Sep 20 11:57:34 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Sep 2012 11:57:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TEfNj-0003yj-Bq; Thu, 20 Sep 2012 11:57:23 +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 1TEfNi-0003yc-71
	for xen-devel@lists.xensource.com; Thu, 20 Sep 2012 11:57:22 +0000
Received: from [85.158.138.51:64590] by server-10.bemta-3.messagelabs.com id
	51/F0-10411-1A40B505; Thu, 20 Sep 2012 11:57:21 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1348142240!23717298!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTA0NTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23023 invoked from network); 20 Sep 2012 11:57:21 -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;
	20 Sep 2012 11:57:21 -0000
X-IronPort-AV: E=Sophos;i="4.80,453,1344211200"; d="scan'208";a="14654536"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Sep 2012 11:57: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.279.1; Thu, 20 Sep 2012 12:57:19 +0100
Date: Thu, 20 Sep 2012 12:56:30 +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: <1348136222.26501.19.camel@zakaz.uk.xensource.com>
Message-ID: <alpine.DEB.2.02.1209201240110.29232@kaball.uk.xensource.com>
References: <1348076658-4511-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<1348136222.26501.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>,
	Pawel Moll <pawel.moll@arm.com>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Xen-devel] [PATCH] arm: introduce a DTS for Xen unprivileged
 virtual 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 Thu, 20 Sep 2012, Ian Campbell wrote:
> On Wed, 2012-09-19 at 18:44 +0100, Stefano Stabellini wrote:
> > +/include/ "skeleton.dtsi"
> > +
> > +/ {
> > +	model = "XENVM-4.2";
> 
> Why the shouty caps?

It looks like that model names are always capital, at least in the
vexpress family.


> Did you mean 4.3 here and throughout?

Nope, after all this is the fruit of the work we did on Xen 4.2, mostly
already upstream. By the time of the 4.3 release we might have a
different dts.


> > +	compatible = "xen,xenvm-4.2", "arm,vexpress";
> 
> Is this second compatible thing actually true? We don't actually emulate
> much (anything?) of what would be on a real vexpress motherboard.
> 
> "arm,vexpress" is used only in v2m.c and I don't think we want the
> majority of that -- we don't provide any of the peripherals which it
> registers.
> 
> I think the only things we might want out of that lot are the arch timer
> and perhaps the uart0 (as a debug port).
> 
> I suspect we should have our own xen machine .c.
> 
> [...]

It is true that we are "arm,vexpress" compatible at the moment.
Also we need to be unless we want to introduce our own arch/arm/mach-xen
that I think is overkill.

Versatile Express is flexible enough to be a good base for our own
virtual machine platform, especially if the maintainers keep an eye on
getting everything through DT and not expecting devices just to be there
;-)


> > +	gic: interrupt-controller@2c001000 {
> > +		compatible = "arm,cortex-a9-gic";
> 
> Don't we mean "arm,cortex-a15-gic" here? That's what we actually
> provide. I'm not sure how the a9 and a15 differ.

The GIC that comes with vexpress is a9 compatible.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 20 11:57:34 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Sep 2012 11:57:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TEfNj-0003yj-Bq; Thu, 20 Sep 2012 11:57:23 +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 1TEfNi-0003yc-71
	for xen-devel@lists.xensource.com; Thu, 20 Sep 2012 11:57:22 +0000
Received: from [85.158.138.51:64590] by server-10.bemta-3.messagelabs.com id
	51/F0-10411-1A40B505; Thu, 20 Sep 2012 11:57:21 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1348142240!23717298!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTA0NTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23023 invoked from network); 20 Sep 2012 11:57:21 -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;
	20 Sep 2012 11:57:21 -0000
X-IronPort-AV: E=Sophos;i="4.80,453,1344211200"; d="scan'208";a="14654536"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Sep 2012 11:57: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.279.1; Thu, 20 Sep 2012 12:57:19 +0100
Date: Thu, 20 Sep 2012 12:56:30 +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: <1348136222.26501.19.camel@zakaz.uk.xensource.com>
Message-ID: <alpine.DEB.2.02.1209201240110.29232@kaball.uk.xensource.com>
References: <1348076658-4511-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<1348136222.26501.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>,
	Pawel Moll <pawel.moll@arm.com>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Xen-devel] [PATCH] arm: introduce a DTS for Xen unprivileged
 virtual 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 Thu, 20 Sep 2012, Ian Campbell wrote:
> On Wed, 2012-09-19 at 18:44 +0100, Stefano Stabellini wrote:
> > +/include/ "skeleton.dtsi"
> > +
> > +/ {
> > +	model = "XENVM-4.2";
> 
> Why the shouty caps?

It looks like that model names are always capital, at least in the
vexpress family.


> Did you mean 4.3 here and throughout?

Nope, after all this is the fruit of the work we did on Xen 4.2, mostly
already upstream. By the time of the 4.3 release we might have a
different dts.


> > +	compatible = "xen,xenvm-4.2", "arm,vexpress";
> 
> Is this second compatible thing actually true? We don't actually emulate
> much (anything?) of what would be on a real vexpress motherboard.
> 
> "arm,vexpress" is used only in v2m.c and I don't think we want the
> majority of that -- we don't provide any of the peripherals which it
> registers.
> 
> I think the only things we might want out of that lot are the arch timer
> and perhaps the uart0 (as a debug port).
> 
> I suspect we should have our own xen machine .c.
> 
> [...]

It is true that we are "arm,vexpress" compatible at the moment.
Also we need to be unless we want to introduce our own arch/arm/mach-xen
that I think is overkill.

Versatile Express is flexible enough to be a good base for our own
virtual machine platform, especially if the maintainers keep an eye on
getting everything through DT and not expecting devices just to be there
;-)


> > +	gic: interrupt-controller@2c001000 {
> > +		compatible = "arm,cortex-a9-gic";
> 
> Don't we mean "arm,cortex-a15-gic" here? That's what we actually
> provide. I'm not sure how the a9 and a15 differ.

The GIC that comes with vexpress is a9 compatible.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 20 12:01:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Sep 2012 12:01:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TEfRo-0004I1-23; Thu, 20 Sep 2012 12:01:36 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1TEfRl-0004Ha-QY
	for xen-devel@lists.xensource.com; Thu, 20 Sep 2012 12:01:34 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1348142487!10643534!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTA0NTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8040 invoked from network); 20 Sep 2012 12:01:27 -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;
	20 Sep 2012 12:01:27 -0000
X-IronPort-AV: E=Sophos;i="4.80,453,1344211200"; d="scan'208";a="14654619"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Sep 2012 12:01: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.279.1; Thu, 20 Sep 2012 13:01:27 +0100
Date: Thu, 20 Sep 2012 13:00:38 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: David Vrabel <david.vrabel@citrix.com>
In-Reply-To: <505AF3E5.1050306@citrix.com>
Message-ID: <alpine.DEB.2.02.1209201256560.29232@kaball.uk.xensource.com>
References: <1348076658-4511-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<505AF3E5.1050306@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>,
	Ian Campbell <Ian.Campbell@citrix.com>, Pawel Moll <pawel.moll@arm.com>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Xen-devel] [PATCH] arm: introduce a DTS for Xen unprivileged
 virtual 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 Thu, 20 Sep 2012, David Vrabel wrote:
> On 19/09/12 18:44, Stefano Stabellini wrote:
> > --- /dev/null
> > +++ b/arch/arm/boot/dts/vexpress-xenvm-4.2.dts
> 
> Does this make sense?  There is no fixed configuration for VMs.
> 
> Is the intention to pass a DTS to the toolstack for it to create the VM
> with the appropriate amount of memory and peripheral mapped to the right
> place etc?  Or is the toolstack going to create the VM and generate the
> DTB from (e.g.,) an xl VM configuration file.
> 
> > +
> > +	hypervisor {
> > +		compatible = "xen,xen-4.2", "xen,xen";
> > +		reg = <0xb0000000 0x20000>;
> > +		interrupts = <1 15 0xf08>;
> > +	};
> 
> This node needs to be generated by the toolstack as only it knows what
> ABI the hypervisor has.
 
This DTS is going to be genereted by the toolstack (or the hypervisor).
We don't expect people to take this exact DTS and use it for Xen VMs.
However it is useful to have it in the Linux tree as a reference.

Of course the amount of memory and the position of the memory region
under the hypervisor node can change.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 20 12:01:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Sep 2012 12:01:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TEfRo-0004I1-23; Thu, 20 Sep 2012 12:01:36 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1TEfRl-0004Ha-QY
	for xen-devel@lists.xensource.com; Thu, 20 Sep 2012 12:01:34 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1348142487!10643534!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTA0NTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8040 invoked from network); 20 Sep 2012 12:01:27 -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;
	20 Sep 2012 12:01:27 -0000
X-IronPort-AV: E=Sophos;i="4.80,453,1344211200"; d="scan'208";a="14654619"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Sep 2012 12:01: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.279.1; Thu, 20 Sep 2012 13:01:27 +0100
Date: Thu, 20 Sep 2012 13:00:38 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: David Vrabel <david.vrabel@citrix.com>
In-Reply-To: <505AF3E5.1050306@citrix.com>
Message-ID: <alpine.DEB.2.02.1209201256560.29232@kaball.uk.xensource.com>
References: <1348076658-4511-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<505AF3E5.1050306@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>,
	Ian Campbell <Ian.Campbell@citrix.com>, Pawel Moll <pawel.moll@arm.com>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Xen-devel] [PATCH] arm: introduce a DTS for Xen unprivileged
 virtual 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 Thu, 20 Sep 2012, David Vrabel wrote:
> On 19/09/12 18:44, Stefano Stabellini wrote:
> > --- /dev/null
> > +++ b/arch/arm/boot/dts/vexpress-xenvm-4.2.dts
> 
> Does this make sense?  There is no fixed configuration for VMs.
> 
> Is the intention to pass a DTS to the toolstack for it to create the VM
> with the appropriate amount of memory and peripheral mapped to the right
> place etc?  Or is the toolstack going to create the VM and generate the
> DTB from (e.g.,) an xl VM configuration file.
> 
> > +
> > +	hypervisor {
> > +		compatible = "xen,xen-4.2", "xen,xen";
> > +		reg = <0xb0000000 0x20000>;
> > +		interrupts = <1 15 0xf08>;
> > +	};
> 
> This node needs to be generated by the toolstack as only it knows what
> ABI the hypervisor has.
 
This DTS is going to be genereted by the toolstack (or the hypervisor).
We don't expect people to take this exact DTS and use it for Xen VMs.
However it is useful to have it in the Linux tree as a reference.

Of course the amount of memory and the position of the memory region
under the hypervisor node can change.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 20 12:03:25 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Sep 2012 12:03:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TEfTM-0004P5-IR; Thu, 20 Sep 2012 12:03: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 1TEfTL-0004Ot-Ue
	for xen-devel@lists.xensource.com; Thu, 20 Sep 2012 12:03:12 +0000
Received: from [85.158.139.211:20020] by server-6.bemta-5.messagelabs.com id
	76/B6-21336-EF50B505; Thu, 20 Sep 2012 12:03:10 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-10.tower-206.messagelabs.com!1348142589!19284721!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTA0NTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15754 invoked from network); 20 Sep 2012 12:03:10 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Sep 2012 12:03:10 -0000
X-IronPort-AV: E=Sophos;i="4.80,453,1344211200"; d="scan'208";a="14654661"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Sep 2012 12:03:09 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Thu, 20 Sep 2012 13:03:09 +0100
Date: Thu, 20 Sep 2012 13:02:20 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Dave Martin <dave.martin@linaro.org>
In-Reply-To: <20120920111815.GC2117@linaro.org>
Message-ID: <alpine.DEB.2.02.1209201301340.29232@kaball.uk.xensource.com>
References: <1348076658-4511-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<1348135563.11116.94.camel@hornet>
	<20120920111815.GC2117@linaro.org>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, Pawel Moll <pawel.moll@arm.com>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Xen-devel] [PATCH] arm: introduce a DTS for Xen unprivileged
 virtual 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 Thu, 20 Sep 2012, Dave Martin wrote:
> On Thu, Sep 20, 2012 at 11:06:03AM +0100, Pawel Moll wrote:
> > Morning,
> > 
> > On Wed, 2012-09-19 at 18:44 +0100, Stefano Stabellini wrote:
> > > +/dts-v1/;
> > > +
> > > +/include/ "skeleton.dtsi"
> > 
> > Any particular reason to include skeleton? And I think it would be
> > better to use #address-cells = <2> and #size-cells = <2>, to be ready
> > for LPAE addresses...
> > 
> > > +/ {
> > > +	model = "XENVM-4.2";
> > > +	compatible = "xen,xenvm-4.2", "arm,vexpress";
> > > +	interrupt-parent = <&gic>;
> > > +
> > > +	chosen {
> > > +		bootargs = "earlyprintk console=hvc0 root=/dev/xvda init=/sbin/init";
> > > +	};
> 
> Are you sure this default command line is appropriate?
> 
> I don't normally like to see default command lines unless they really
> add something which is crucial for the board to work.
> 
> None of those args looks vital to me.  They are configuration choices
> and should be left up to the user.

Yes, you are right. I'll trim it down to "console=hvc0 root=/dev/xvda".

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 20 12:03:25 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Sep 2012 12:03:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TEfTM-0004P5-IR; Thu, 20 Sep 2012 12:03: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 1TEfTL-0004Ot-Ue
	for xen-devel@lists.xensource.com; Thu, 20 Sep 2012 12:03:12 +0000
Received: from [85.158.139.211:20020] by server-6.bemta-5.messagelabs.com id
	76/B6-21336-EF50B505; Thu, 20 Sep 2012 12:03:10 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-10.tower-206.messagelabs.com!1348142589!19284721!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTA0NTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15754 invoked from network); 20 Sep 2012 12:03:10 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Sep 2012 12:03:10 -0000
X-IronPort-AV: E=Sophos;i="4.80,453,1344211200"; d="scan'208";a="14654661"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Sep 2012 12:03:09 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Thu, 20 Sep 2012 13:03:09 +0100
Date: Thu, 20 Sep 2012 13:02:20 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Dave Martin <dave.martin@linaro.org>
In-Reply-To: <20120920111815.GC2117@linaro.org>
Message-ID: <alpine.DEB.2.02.1209201301340.29232@kaball.uk.xensource.com>
References: <1348076658-4511-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<1348135563.11116.94.camel@hornet>
	<20120920111815.GC2117@linaro.org>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, Pawel Moll <pawel.moll@arm.com>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Xen-devel] [PATCH] arm: introduce a DTS for Xen unprivileged
 virtual 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 Thu, 20 Sep 2012, Dave Martin wrote:
> On Thu, Sep 20, 2012 at 11:06:03AM +0100, Pawel Moll wrote:
> > Morning,
> > 
> > On Wed, 2012-09-19 at 18:44 +0100, Stefano Stabellini wrote:
> > > +/dts-v1/;
> > > +
> > > +/include/ "skeleton.dtsi"
> > 
> > Any particular reason to include skeleton? And I think it would be
> > better to use #address-cells = <2> and #size-cells = <2>, to be ready
> > for LPAE addresses...
> > 
> > > +/ {
> > > +	model = "XENVM-4.2";
> > > +	compatible = "xen,xenvm-4.2", "arm,vexpress";
> > > +	interrupt-parent = <&gic>;
> > > +
> > > +	chosen {
> > > +		bootargs = "earlyprintk console=hvc0 root=/dev/xvda init=/sbin/init";
> > > +	};
> 
> Are you sure this default command line is appropriate?
> 
> I don't normally like to see default command lines unless they really
> add something which is crucial for the board to work.
> 
> None of those args looks vital to me.  They are configuration choices
> and should be left up to the user.

Yes, you are right. I'll trim it down to "console=hvc0 root=/dev/xvda".

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 20 12:05:37 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Sep 2012 12:05: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 1TEfVa-0004Zt-4K; Thu, 20 Sep 2012 12:05: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 1TEfVY-0004Zf-TY
	for xen-devel@lists.xensource.com; Thu, 20 Sep 2012 12:05:29 +0000
Received: from [85.158.138.51:4726] by server-12.bemta-3.messagelabs.com id
	90/E7-10384-8860B505; Thu, 20 Sep 2012 12:05:28 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1348142723!29536201!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTA0NTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2301 invoked from network); 20 Sep 2012 12:05:24 -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 Sep 2012 12:05:24 -0000
X-IronPort-AV: E=Sophos;i="4.80,453,1344211200"; d="scan'208";a="14654763"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Sep 2012 12:05: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.279.1; Thu, 20 Sep 2012 13:05:23 +0100
Date: Thu, 20 Sep 2012 13:04:34 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Dave Martin <dave.martin@linaro.org>
In-Reply-To: <20120920112102.GD2117@linaro.org>
Message-ID: <alpine.DEB.2.02.1209201302440.29232@kaball.uk.xensource.com>
References: <1348076658-4511-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<505AF3E5.1050306@citrix.com> <20120920112102.GD2117@linaro.org>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, Pawel Moll <pawel.moll@arm.com>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	David Vrabel <david.vrabel@citrix.com>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Xen-devel] [PATCH] arm: introduce a DTS for Xen unprivileged
 virtual 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 Thu, 20 Sep 2012, Dave Martin wrote:
> On Thu, Sep 20, 2012 at 11:45:57AM +0100, David Vrabel wrote:
> > On 19/09/12 18:44, Stefano Stabellini wrote:
> > > --- /dev/null
> > > +++ b/arch/arm/boot/dts/vexpress-xenvm-4.2.dts
> > 
> > Does this make sense?  There is no fixed configuration for VMs.
> > 
> > Is the intention to pass a DTS to the toolstack for it to create the VM
> > with the appropriate amount of memory and peripheral mapped to the right
> > place etc?  Or is the toolstack going to create the VM and generate the
> > DTB from (e.g.,) an xl VM configuration file.
> > 
> > > +
> > > +	hypervisor {
> > > +		compatible = "xen,xen-4.2", "xen,xen";
> > > +		reg = <0xb0000000 0x20000>;
> > > +		interrupts = <1 15 0xf08>;
> > > +	};
> > 
> > This node needs to be generated by the toolstack as only it knows what
> > ABI the hypervisor has.
> 
> That's a good point: the same applies to the command line.  The toolstack
> knows where the console and root device should be etc.: the kernel itself
> shouldn't have static defaults for those.

As I was saying in the other email, this dts is just supposed to be a
reference. The real one is going to come from the toolstack or the
hypervisor. 

But isn't the same true for other dts as well? Aren't they supposed to
be passed to the kernel by the bootloader?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 20 12:05:37 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Sep 2012 12:05: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 1TEfVa-0004Zt-4K; Thu, 20 Sep 2012 12:05: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 1TEfVY-0004Zf-TY
	for xen-devel@lists.xensource.com; Thu, 20 Sep 2012 12:05:29 +0000
Received: from [85.158.138.51:4726] by server-12.bemta-3.messagelabs.com id
	90/E7-10384-8860B505; Thu, 20 Sep 2012 12:05:28 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1348142723!29536201!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTA0NTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2301 invoked from network); 20 Sep 2012 12:05:24 -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 Sep 2012 12:05:24 -0000
X-IronPort-AV: E=Sophos;i="4.80,453,1344211200"; d="scan'208";a="14654763"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Sep 2012 12:05: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.279.1; Thu, 20 Sep 2012 13:05:23 +0100
Date: Thu, 20 Sep 2012 13:04:34 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Dave Martin <dave.martin@linaro.org>
In-Reply-To: <20120920112102.GD2117@linaro.org>
Message-ID: <alpine.DEB.2.02.1209201302440.29232@kaball.uk.xensource.com>
References: <1348076658-4511-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<505AF3E5.1050306@citrix.com> <20120920112102.GD2117@linaro.org>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, Pawel Moll <pawel.moll@arm.com>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	David Vrabel <david.vrabel@citrix.com>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Xen-devel] [PATCH] arm: introduce a DTS for Xen unprivileged
 virtual 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 Thu, 20 Sep 2012, Dave Martin wrote:
> On Thu, Sep 20, 2012 at 11:45:57AM +0100, David Vrabel wrote:
> > On 19/09/12 18:44, Stefano Stabellini wrote:
> > > --- /dev/null
> > > +++ b/arch/arm/boot/dts/vexpress-xenvm-4.2.dts
> > 
> > Does this make sense?  There is no fixed configuration for VMs.
> > 
> > Is the intention to pass a DTS to the toolstack for it to create the VM
> > with the appropriate amount of memory and peripheral mapped to the right
> > place etc?  Or is the toolstack going to create the VM and generate the
> > DTB from (e.g.,) an xl VM configuration file.
> > 
> > > +
> > > +	hypervisor {
> > > +		compatible = "xen,xen-4.2", "xen,xen";
> > > +		reg = <0xb0000000 0x20000>;
> > > +		interrupts = <1 15 0xf08>;
> > > +	};
> > 
> > This node needs to be generated by the toolstack as only it knows what
> > ABI the hypervisor has.
> 
> That's a good point: the same applies to the command line.  The toolstack
> knows where the console and root device should be etc.: the kernel itself
> shouldn't have static defaults for those.

As I was saying in the other email, this dts is just supposed to be a
reference. The real one is going to come from the toolstack or the
hypervisor. 

But isn't the same true for other dts as well? Aren't they supposed to
be passed to the kernel by the bootloader?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 20 12:16:20 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Sep 2012 12:16: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 1TEffp-0004vI-9D; Thu, 20 Sep 2012 12:16:05 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1TEffn-0004vD-DT
	for xen-devel@lists.xensource.com; Thu, 20 Sep 2012 12:16:03 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1348143356!6569183!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTA0NTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2091 invoked from network); 20 Sep 2012 12:15:57 -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;
	20 Sep 2012 12:15:57 -0000
X-IronPort-AV: E=Sophos;i="4.80,453,1344211200"; d="scan'208";a="14655142"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Sep 2012 12:15: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.279.1; Thu, 20 Sep 2012 13:15:56 +0100
Date: Thu, 20 Sep 2012 13:15:07 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Pawel Moll <pawel.moll@arm.com>
In-Reply-To: <1348142133.11116.109.camel@hornet>
Message-ID: <alpine.DEB.2.02.1209201308490.29232@kaball.uk.xensource.com>
References: <1348076658-4511-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<1348135563.11116.94.camel@hornet>
	<alpine.DEB.2.02.1209201235450.29232@kaball.uk.xensource.com>
	<1348142133.11116.109.camel@hornet>
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>, Arnd Bergmann <arnd@arndb.de>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>, marc.zyngier@arm.com,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Xen-devel] [PATCH] arm: introduce a DTS for Xen unprivileged
 virtual 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 Thu, 20 Sep 2012, Pawel Moll wrote:
> On Thu, 2012-09-20 at 12:39 +0100, Stefano Stabellini wrote:
> > There are no peripherals apart from the ones that are already described
> > here (timer, gic). All the peripherals that the guest sees are virtual
> > devices that show up on xenbus (a virtual bus). In order to initialize
> > xenbus, the guest only needs the hypervisor node.  So I'll remove the
> > ranges and interrupt-map.
> 
> So all the peripherals are actually discoverable - awesome!
> 
> But the fact is that the only "vexpressness" of this tree is
> memory@80000000 and gic@2c001000. The rest (not much of it ;-) is a
> "generic A15 platform". 
> 
> I understand that you had to use some "compatible" value to get
> initialization code and I'm flattered ;-) by your choice of
> "arm,vexpress", but maybe - as suggested by others - you would be better
> off with generating this stuff in runtime, by whatever tool is used to
> instantiate the guest?

Yes, it is certainly going to be generated at run time. Does it make
sense to keep an example under arch/arm/boot/dts? I think so. There must
be other platforms that actually pass the device tree to the kernel from
the firmware and still have a dts in the kernel tree, right?
If actually there are none, it is probably best to forget about this
patch :)

Regarding the choice of "arm,vexpress", there was a discussion at kernel
summit about vexpress being the right choice as a base platform for
virtual machines on ARM, even though in the Xen case it means having a
vexpress with no peripherals.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 20 12:16:20 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Sep 2012 12:16: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 1TEffp-0004vI-9D; Thu, 20 Sep 2012 12:16:05 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1TEffn-0004vD-DT
	for xen-devel@lists.xensource.com; Thu, 20 Sep 2012 12:16:03 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1348143356!6569183!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTA0NTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2091 invoked from network); 20 Sep 2012 12:15:57 -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;
	20 Sep 2012 12:15:57 -0000
X-IronPort-AV: E=Sophos;i="4.80,453,1344211200"; d="scan'208";a="14655142"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Sep 2012 12:15: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.279.1; Thu, 20 Sep 2012 13:15:56 +0100
Date: Thu, 20 Sep 2012 13:15:07 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Pawel Moll <pawel.moll@arm.com>
In-Reply-To: <1348142133.11116.109.camel@hornet>
Message-ID: <alpine.DEB.2.02.1209201308490.29232@kaball.uk.xensource.com>
References: <1348076658-4511-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<1348135563.11116.94.camel@hornet>
	<alpine.DEB.2.02.1209201235450.29232@kaball.uk.xensource.com>
	<1348142133.11116.109.camel@hornet>
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>, Arnd Bergmann <arnd@arndb.de>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>, marc.zyngier@arm.com,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Xen-devel] [PATCH] arm: introduce a DTS for Xen unprivileged
 virtual 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 Thu, 20 Sep 2012, Pawel Moll wrote:
> On Thu, 2012-09-20 at 12:39 +0100, Stefano Stabellini wrote:
> > There are no peripherals apart from the ones that are already described
> > here (timer, gic). All the peripherals that the guest sees are virtual
> > devices that show up on xenbus (a virtual bus). In order to initialize
> > xenbus, the guest only needs the hypervisor node.  So I'll remove the
> > ranges and interrupt-map.
> 
> So all the peripherals are actually discoverable - awesome!
> 
> But the fact is that the only "vexpressness" of this tree is
> memory@80000000 and gic@2c001000. The rest (not much of it ;-) is a
> "generic A15 platform". 
> 
> I understand that you had to use some "compatible" value to get
> initialization code and I'm flattered ;-) by your choice of
> "arm,vexpress", but maybe - as suggested by others - you would be better
> off with generating this stuff in runtime, by whatever tool is used to
> instantiate the guest?

Yes, it is certainly going to be generated at run time. Does it make
sense to keep an example under arch/arm/boot/dts? I think so. There must
be other platforms that actually pass the device tree to the kernel from
the firmware and still have a dts in the kernel tree, right?
If actually there are none, it is probably best to forget about this
patch :)

Regarding the choice of "arm,vexpress", there was a discussion at kernel
summit about vexpress being the right choice as a base platform for
virtual machines on ARM, even though in the Xen case it means having a
vexpress with no peripherals.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 20 12:19:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Sep 2012 12: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 1TEfib-00053u-SI; Thu, 20 Sep 2012 12:18: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 1TEfia-00053p-B9
	for xen-devel@lists.xensource.com; Thu, 20 Sep 2012 12:18:56 +0000
Received: from [85.158.139.83:59968] by server-4.bemta-5.messagelabs.com id
	45/A0-23042-FA90B505; Thu, 20 Sep 2012 12:18:55 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1348143534!24035404!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTA0NTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6211 invoked from network); 20 Sep 2012 12:18:54 -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;
	20 Sep 2012 12:18:54 -0000
X-IronPort-AV: E=Sophos;i="4.80,453,1344211200"; d="scan'208";a="14655251"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Sep 2012 12:18: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.279.1;
	Thu, 20 Sep 2012 13:18:54 +0100
Message-ID: <1348143533.26501.28.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Date: Thu, 20 Sep 2012 13:18:53 +0100
In-Reply-To: <alpine.DEB.2.02.1209201240110.29232@kaball.uk.xensource.com>
References: <1348076658-4511-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<1348136222.26501.19.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.02.1209201240110.29232@kaball.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Pawel Moll <pawel.moll@arm.com>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH] arm: introduce a DTS for Xen unprivileged
 virtual 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 Thu, 2012-09-20 at 12:56 +0100, Stefano Stabellini wrote:
> On Thu, 20 Sep 2012, Ian Campbell wrote:
> > On Wed, 2012-09-19 at 18:44 +0100, Stefano Stabellini wrote:
> > > +/include/ "skeleton.dtsi"
> > > +
> > > +/ {
> > > +	model = "XENVM-4.2";
> > 
> > Why the shouty caps?
> 
> It looks like that model names are always capital, at least in the
> vexpress family.
> 
> 
> > Did you mean 4.3 here and throughout?
> 
> Nope, after all this is the fruit of the work we did on Xen 4.2, mostly
> already upstream. By the time of the 4.3 release we might have a
> different dts.
> 
> 
> > > +	compatible = "xen,xenvm-4.2", "arm,vexpress";
> > 
> > Is this second compatible thing actually true? We don't actually emulate
> > much (anything?) of what would be on a real vexpress motherboard.
> > 
> > "arm,vexpress" is used only in v2m.c and I don't think we want the
> > majority of that -- we don't provide any of the peripherals which it
> > registers.
> > 
> > I think the only things we might want out of that lot are the arch timer
> > and perhaps the uart0 (as a debug port).
> > 
> > I suspect we should have our own xen machine .c.
> > 
> > [...]
> 
> It is true that we are "arm,vexpress" compatible at the moment.

But we aren't, we don't emulate 90%+ of the actual hardware which
vexpress compatibility would actually imply.

Look in arch/arm/mach-vexpress/v2m.c, which is the only thing keyed off
this compat value -- it's full of stuff which we don't (and aren't going
to) implement.

> Also we need to be unless we want to introduce our own arch/arm/mach-xen
> that I think is overkill.

Probably.

> Versatile Express is flexible enough to be a good base for our own
> virtual machine platform, especially if the maintainers keep an eye on
> getting everything through DT and not expecting devices just to be there
> ;-)

Perhaps what we want is a stricter subset of the stuff in mach-vexpress
then. But if so then this should be expressed both in the DT and in the
code, not just papered over by declaring things compatible when they are
not.

> > > +	gic: interrupt-controller@2c001000 {
> > > +		compatible = "arm,cortex-a9-gic";
> > 
> > Don't we mean "arm,cortex-a15-gic" here? That's what we actually
> > provide. I'm not sure how the a9 and a15 differ.
> 
> The GIC that comes with vexpress is a9 compatible.

The GIC which Xen emulates is the one which matters here though, and
that is an a15.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 20 12:19:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Sep 2012 12: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 1TEfib-00053u-SI; Thu, 20 Sep 2012 12:18: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 1TEfia-00053p-B9
	for xen-devel@lists.xensource.com; Thu, 20 Sep 2012 12:18:56 +0000
Received: from [85.158.139.83:59968] by server-4.bemta-5.messagelabs.com id
	45/A0-23042-FA90B505; Thu, 20 Sep 2012 12:18:55 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1348143534!24035404!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTA0NTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6211 invoked from network); 20 Sep 2012 12:18:54 -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;
	20 Sep 2012 12:18:54 -0000
X-IronPort-AV: E=Sophos;i="4.80,453,1344211200"; d="scan'208";a="14655251"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Sep 2012 12:18: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.279.1;
	Thu, 20 Sep 2012 13:18:54 +0100
Message-ID: <1348143533.26501.28.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Date: Thu, 20 Sep 2012 13:18:53 +0100
In-Reply-To: <alpine.DEB.2.02.1209201240110.29232@kaball.uk.xensource.com>
References: <1348076658-4511-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<1348136222.26501.19.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.02.1209201240110.29232@kaball.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Pawel Moll <pawel.moll@arm.com>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH] arm: introduce a DTS for Xen unprivileged
 virtual 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 Thu, 2012-09-20 at 12:56 +0100, Stefano Stabellini wrote:
> On Thu, 20 Sep 2012, Ian Campbell wrote:
> > On Wed, 2012-09-19 at 18:44 +0100, Stefano Stabellini wrote:
> > > +/include/ "skeleton.dtsi"
> > > +
> > > +/ {
> > > +	model = "XENVM-4.2";
> > 
> > Why the shouty caps?
> 
> It looks like that model names are always capital, at least in the
> vexpress family.
> 
> 
> > Did you mean 4.3 here and throughout?
> 
> Nope, after all this is the fruit of the work we did on Xen 4.2, mostly
> already upstream. By the time of the 4.3 release we might have a
> different dts.
> 
> 
> > > +	compatible = "xen,xenvm-4.2", "arm,vexpress";
> > 
> > Is this second compatible thing actually true? We don't actually emulate
> > much (anything?) of what would be on a real vexpress motherboard.
> > 
> > "arm,vexpress" is used only in v2m.c and I don't think we want the
> > majority of that -- we don't provide any of the peripherals which it
> > registers.
> > 
> > I think the only things we might want out of that lot are the arch timer
> > and perhaps the uart0 (as a debug port).
> > 
> > I suspect we should have our own xen machine .c.
> > 
> > [...]
> 
> It is true that we are "arm,vexpress" compatible at the moment.

But we aren't, we don't emulate 90%+ of the actual hardware which
vexpress compatibility would actually imply.

Look in arch/arm/mach-vexpress/v2m.c, which is the only thing keyed off
this compat value -- it's full of stuff which we don't (and aren't going
to) implement.

> Also we need to be unless we want to introduce our own arch/arm/mach-xen
> that I think is overkill.

Probably.

> Versatile Express is flexible enough to be a good base for our own
> virtual machine platform, especially if the maintainers keep an eye on
> getting everything through DT and not expecting devices just to be there
> ;-)

Perhaps what we want is a stricter subset of the stuff in mach-vexpress
then. But if so then this should be expressed both in the DT and in the
code, not just papered over by declaring things compatible when they are
not.

> > > +	gic: interrupt-controller@2c001000 {
> > > +		compatible = "arm,cortex-a9-gic";
> > 
> > Don't we mean "arm,cortex-a15-gic" here? That's what we actually
> > provide. I'm not sure how the a9 and a15 differ.
> 
> The GIC that comes with vexpress is a9 compatible.

The GIC which Xen emulates is the one which matters here though, and
that is an a15.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 20 12:20:35 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Sep 2012 12:20:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TEfjz-0005Aw-G0; Thu, 20 Sep 2012 12:20:23 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1TEfjy-0005An-KR
	for xen-devel@lists.xen.org; Thu, 20 Sep 2012 12:20:22 +0000
Received: from [85.158.143.99:34619] by server-1.bemta-4.messagelabs.com id
	79/ED-05684-50A0B505; Thu, 20 Sep 2012 12:20:21 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1348143617!19887025!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7154 invoked from network); 20 Sep 2012 12:20:20 -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;
	20 Sep 2012 12:20:20 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 20 Sep 2012 13:20:41 +0100
Message-Id: <505B2636020000780009CAA6@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 20 Sep 2012 13:20:38 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Jean Guyader" <jean.guyader@citrix.com>
References: <1348141322-28657-1-git-send-email-jean.guyader@citrix.com>
	<1348141322-28657-5-git-send-email-jean.guyader@citrix.com>
In-Reply-To: <1348141322-28657-5-git-send-email-jean.guyader@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: tim@xen.org, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 4/4] 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 20.09.12 at 13:42, Jean Guyader <jean.guyader@citrix.com> wrote:
>+        case V4VOP_register_ring:
>+            {
>+                XEN_GUEST_HANDLE(v4v_ring_t) ring_hnd =
>+                    guest_handle_cast(arg1, v4v_ring_t);
>+                XEN_GUEST_HANDLE(xen_pfn_t) pfn_hnd =
>+                    guest_handle_cast(arg2, xen_pfn_t);
>+                uint32_t npage = arg3;
>+                if ( unlikely(!guest_handle_okay(ring_hnd, 1)) )
>+                    goto out;
>+                if ( unlikely(!guest_handle_okay(pfn_hnd, npage)) )
>+                    goto out;

Here and below - this isn't sufficient for compat guests, or else
you give them a way to point into the compat m2p table.

>+                if ( unlikely(!guest_handle_okay(addr_hnd, 1)) )
>+                    goto out;
>+                if ( copy_from_guest(&addr, addr_hnd, 1) )
>+                    goto out;

The former is redundant with the latter. Also, if you already
used guest_handle_okay() on an array, you then can (and
should) use the cheaper __copy_{to,from}_guest() functions.
While looking at this, I also spotted at least on guest access
without error checking. Plus many guest accesses happen
with some sort of lock held - that'll cause problems when the
guest memory you're trying to access was paged out (quite
likely you would be able to point out other such cases, but
those likely predate paging, and hence are an oversight of
whoever introduced the paging code).

>+struct v4v_ring_message_header
>+{
>+    uint32_t len;
>+    uint32_t pad0;

Why? v4v_addr_t is 4-byte aligned.

>+    v4v_addr_t source;
>+    uint32_t message_type;
>+    uint32_t pad1;

And again, why?

>+#if defined(__STDC_VERSION__) && __STDC_VERSION__ >= 199901L
>+    uint8_t data[];
>+#elif defined(__GNUC__)
>+    uint8_t data[0];
>+#endif
>+};
...
>+/*
>+ * V4VOP_register_ring
>+ *
>+ * Registers a ring with Xen. If a ring with the same v4v_ring_id exists,
>+ * the hypercall will return -EEXIST.
>+ *
>+ * do_v4v_op(V4VOP_unregister_ring,
>+ *           XEN_GUEST_HANDLE(v4v_ring_t), XEN_GUEST_HANDLE(xen_pfn_t),
>+ *           npage, 0)
>+ */
>+#define V4VOP_register_ring 	1

"register" or "unregister"?

Also, note the use of v4v_ring_t here, but ...

>+/*
>+ * V4VOP_unregister_ring
>+ *
>+ * Unregister a ring.
>+ *
>+ * do_v4v_op(V4VOP_unregister_ring,
>+ *           XEN_GUEST_HANDLE(v4v_ring),
>+ *           NULL, 0, 0)
>+ */
>+#define V4VOP_unregister_ring 	2

... not here. Please be consistent, even if this is just comments.
(Again at least for V4VOP_sendv.)

>+/*
>+ * V4VOP_viptables_list
>+ *
>+ * Delete a filtering rules at a position or the rule

Delete? Also, here and above, make clear whether you talk
about a single or multiple rules.

>+ * that matches "rule".
>+ *
>+ * do_v4v_op(V4VOP_viptables_list,
>+ *           XEN_GUEST_HANDLE(v4v_vitpables_list_t) list,
>+ *           NULL, 0, 0)
>+ */
>+#define V4VOP_viptables_list    8

Also, with all of the padding fields and unused arguments (for
certain sub-ops) - if you see the slightest chance of them ever
getting used for some extension, you will want to make sure
they got zero-filled by the guest.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 20 12:20:35 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Sep 2012 12:20:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TEfjz-0005Aw-G0; Thu, 20 Sep 2012 12:20:23 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1TEfjy-0005An-KR
	for xen-devel@lists.xen.org; Thu, 20 Sep 2012 12:20:22 +0000
Received: from [85.158.143.99:34619] by server-1.bemta-4.messagelabs.com id
	79/ED-05684-50A0B505; Thu, 20 Sep 2012 12:20:21 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1348143617!19887025!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7154 invoked from network); 20 Sep 2012 12:20:20 -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;
	20 Sep 2012 12:20:20 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 20 Sep 2012 13:20:41 +0100
Message-Id: <505B2636020000780009CAA6@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 20 Sep 2012 13:20:38 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Jean Guyader" <jean.guyader@citrix.com>
References: <1348141322-28657-1-git-send-email-jean.guyader@citrix.com>
	<1348141322-28657-5-git-send-email-jean.guyader@citrix.com>
In-Reply-To: <1348141322-28657-5-git-send-email-jean.guyader@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: tim@xen.org, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 4/4] 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 20.09.12 at 13:42, Jean Guyader <jean.guyader@citrix.com> wrote:
>+        case V4VOP_register_ring:
>+            {
>+                XEN_GUEST_HANDLE(v4v_ring_t) ring_hnd =
>+                    guest_handle_cast(arg1, v4v_ring_t);
>+                XEN_GUEST_HANDLE(xen_pfn_t) pfn_hnd =
>+                    guest_handle_cast(arg2, xen_pfn_t);
>+                uint32_t npage = arg3;
>+                if ( unlikely(!guest_handle_okay(ring_hnd, 1)) )
>+                    goto out;
>+                if ( unlikely(!guest_handle_okay(pfn_hnd, npage)) )
>+                    goto out;

Here and below - this isn't sufficient for compat guests, or else
you give them a way to point into the compat m2p table.

>+                if ( unlikely(!guest_handle_okay(addr_hnd, 1)) )
>+                    goto out;
>+                if ( copy_from_guest(&addr, addr_hnd, 1) )
>+                    goto out;

The former is redundant with the latter. Also, if you already
used guest_handle_okay() on an array, you then can (and
should) use the cheaper __copy_{to,from}_guest() functions.
While looking at this, I also spotted at least on guest access
without error checking. Plus many guest accesses happen
with some sort of lock held - that'll cause problems when the
guest memory you're trying to access was paged out (quite
likely you would be able to point out other such cases, but
those likely predate paging, and hence are an oversight of
whoever introduced the paging code).

>+struct v4v_ring_message_header
>+{
>+    uint32_t len;
>+    uint32_t pad0;

Why? v4v_addr_t is 4-byte aligned.

>+    v4v_addr_t source;
>+    uint32_t message_type;
>+    uint32_t pad1;

And again, why?

>+#if defined(__STDC_VERSION__) && __STDC_VERSION__ >= 199901L
>+    uint8_t data[];
>+#elif defined(__GNUC__)
>+    uint8_t data[0];
>+#endif
>+};
...
>+/*
>+ * V4VOP_register_ring
>+ *
>+ * Registers a ring with Xen. If a ring with the same v4v_ring_id exists,
>+ * the hypercall will return -EEXIST.
>+ *
>+ * do_v4v_op(V4VOP_unregister_ring,
>+ *           XEN_GUEST_HANDLE(v4v_ring_t), XEN_GUEST_HANDLE(xen_pfn_t),
>+ *           npage, 0)
>+ */
>+#define V4VOP_register_ring 	1

"register" or "unregister"?

Also, note the use of v4v_ring_t here, but ...

>+/*
>+ * V4VOP_unregister_ring
>+ *
>+ * Unregister a ring.
>+ *
>+ * do_v4v_op(V4VOP_unregister_ring,
>+ *           XEN_GUEST_HANDLE(v4v_ring),
>+ *           NULL, 0, 0)
>+ */
>+#define V4VOP_unregister_ring 	2

... not here. Please be consistent, even if this is just comments.
(Again at least for V4VOP_sendv.)

>+/*
>+ * V4VOP_viptables_list
>+ *
>+ * Delete a filtering rules at a position or the rule

Delete? Also, here and above, make clear whether you talk
about a single or multiple rules.

>+ * that matches "rule".
>+ *
>+ * do_v4v_op(V4VOP_viptables_list,
>+ *           XEN_GUEST_HANDLE(v4v_vitpables_list_t) list,
>+ *           NULL, 0, 0)
>+ */
>+#define V4VOP_viptables_list    8

Also, with all of the padding fields and unused arguments (for
certain sub-ops) - if you see the slightest chance of them ever
getting used for some extension, you will want to make sure
they got zero-filled by the guest.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 20 12:29:10 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Sep 2012 12: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 1TEfsG-0005PY-Ib; Thu, 20 Sep 2012 12:28:56 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <marc.zyngier@arm.com>) id 1TEfsE-0005PT-UU
	for xen-devel@lists.xensource.com; Thu, 20 Sep 2012 12:28:55 +0000
Received: from [85.158.138.51:47939] by server-4.bemta-3.messagelabs.com id
	8F/D9-24831-60C0B505; Thu, 20 Sep 2012 12:28:54 +0000
X-Env-Sender: marc.zyngier@arm.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1348144133!31296494!1
X-Originating-IP: [91.220.42.44]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogOTEuMjIwLjQyLjQ0ID0+IDI5ODkzOA==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17720 invoked from network); 20 Sep 2012 12:28:53 -0000
Received: from service87.mimecast.com (HELO service87.mimecast.com)
	(91.220.42.44) by server-2.tower-174.messagelabs.com with SMTP;
	20 Sep 2012 12:28:53 -0000
Received: from cam-owa1.Emea.Arm.com (fw-tnat.cambridge.arm.com
	[217.140.96.21]) by service87.mimecast.com;
	Thu, 20 Sep 2012 13:28:52 +0100
Received: from [10.1.70.21] ([10.1.255.212]) by cam-owa1.Emea.Arm.com with
	Microsoft SMTPSVC(6.0.3790.0); Thu, 20 Sep 2012 13:28:49 +0100
Message-ID: <505B0C00.5010003@arm.com>
Date: Thu, 20 Sep 2012 13:28:48 +0100
From: Marc Zyngier <marc.zyngier@arm.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:14.0) Gecko/20120714 Thunderbird/14.0
MIME-Version: 1.0
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
References: <1348076658-4511-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<1348135563.11116.94.camel@hornet>
	<alpine.DEB.2.02.1209201235450.29232@kaball.uk.xensource.com>
	<1348142133.11116.109.camel@hornet>
	<alpine.DEB.2.02.1209201308490.29232@kaball.uk.xensource.com>
In-Reply-To: <alpine.DEB.2.02.1209201308490.29232@kaball.uk.xensource.com>
X-Enigmail-Version: 1.5a1pre
X-OriginalArrivalTime: 20 Sep 2012 12:28:49.0423 (UTC)
	FILETIME=[7CA5A1F0:01CD972B]
X-MC-Unique: 112092013285202501
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, Pawel Moll <Pawel.Moll@arm.com>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Arnd Bergmann <arnd@arndb.de>, "linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Xen-devel] [PATCH] arm: introduce a DTS for Xen unprivileged
	virtual 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 20/09/12 13:15, Stefano Stabellini wrote:
> On Thu, 20 Sep 2012, Pawel Moll wrote:
>> On Thu, 2012-09-20 at 12:39 +0100, Stefano Stabellini wrote:
>>> There are no peripherals apart from the ones that are already described
>>> here (timer, gic). All the peripherals that the guest sees are virtual
>>> devices that show up on xenbus (a virtual bus). In order to initialize
>>> xenbus, the guest only needs the hypervisor node.  So I'll remove the
>>> ranges and interrupt-map.
>>
>> So all the peripherals are actually discoverable - awesome!
>>
>> But the fact is that the only "vexpressness" of this tree is
>> memory@80000000 and gic@2c001000. The rest (not much of it ;-) is a
>> "generic A15 platform". 
>>
>> I understand that you had to use some "compatible" value to get
>> initialization code and I'm flattered ;-) by your choice of
>> "arm,vexpress", but maybe - as suggested by others - you would be better
>> off with generating this stuff in runtime, by whatever tool is used to
>> instantiate the guest?
> 
> Yes, it is certainly going to be generated at run time. Does it make
> sense to keep an example under arch/arm/boot/dts? I think so. There must
> be other platforms that actually pass the device tree to the kernel from
> the firmware and still have a dts in the kernel tree, right?
> If actually there are none, it is probably best to forget about this
> patch :)
> 
> Regarding the choice of "arm,vexpress", there was a discussion at kernel
> summit about vexpress being the right choice as a base platform for
> virtual machines on ARM, even though in the Xen case it means having a
> vexpress with no peripherals.

I think the important thing here is that the memory map is RS1. As this
is a (very limited) subset of a vexpress A15, it seems to make some sense.

I still think it is useful at have an example of such a platform in the
tree, if only as a very minimal example.

	M.
-- 
Jazz is not dead. It just smells funny...


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 20 12:29:10 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Sep 2012 12: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 1TEfsG-0005PY-Ib; Thu, 20 Sep 2012 12:28:56 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <marc.zyngier@arm.com>) id 1TEfsE-0005PT-UU
	for xen-devel@lists.xensource.com; Thu, 20 Sep 2012 12:28:55 +0000
Received: from [85.158.138.51:47939] by server-4.bemta-3.messagelabs.com id
	8F/D9-24831-60C0B505; Thu, 20 Sep 2012 12:28:54 +0000
X-Env-Sender: marc.zyngier@arm.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1348144133!31296494!1
X-Originating-IP: [91.220.42.44]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogOTEuMjIwLjQyLjQ0ID0+IDI5ODkzOA==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17720 invoked from network); 20 Sep 2012 12:28:53 -0000
Received: from service87.mimecast.com (HELO service87.mimecast.com)
	(91.220.42.44) by server-2.tower-174.messagelabs.com with SMTP;
	20 Sep 2012 12:28:53 -0000
Received: from cam-owa1.Emea.Arm.com (fw-tnat.cambridge.arm.com
	[217.140.96.21]) by service87.mimecast.com;
	Thu, 20 Sep 2012 13:28:52 +0100
Received: from [10.1.70.21] ([10.1.255.212]) by cam-owa1.Emea.Arm.com with
	Microsoft SMTPSVC(6.0.3790.0); Thu, 20 Sep 2012 13:28:49 +0100
Message-ID: <505B0C00.5010003@arm.com>
Date: Thu, 20 Sep 2012 13:28:48 +0100
From: Marc Zyngier <marc.zyngier@arm.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:14.0) Gecko/20120714 Thunderbird/14.0
MIME-Version: 1.0
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
References: <1348076658-4511-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<1348135563.11116.94.camel@hornet>
	<alpine.DEB.2.02.1209201235450.29232@kaball.uk.xensource.com>
	<1348142133.11116.109.camel@hornet>
	<alpine.DEB.2.02.1209201308490.29232@kaball.uk.xensource.com>
In-Reply-To: <alpine.DEB.2.02.1209201308490.29232@kaball.uk.xensource.com>
X-Enigmail-Version: 1.5a1pre
X-OriginalArrivalTime: 20 Sep 2012 12:28:49.0423 (UTC)
	FILETIME=[7CA5A1F0:01CD972B]
X-MC-Unique: 112092013285202501
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, Pawel Moll <Pawel.Moll@arm.com>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Arnd Bergmann <arnd@arndb.de>, "linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Xen-devel] [PATCH] arm: introduce a DTS for Xen unprivileged
	virtual 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 20/09/12 13:15, Stefano Stabellini wrote:
> On Thu, 20 Sep 2012, Pawel Moll wrote:
>> On Thu, 2012-09-20 at 12:39 +0100, Stefano Stabellini wrote:
>>> There are no peripherals apart from the ones that are already described
>>> here (timer, gic). All the peripherals that the guest sees are virtual
>>> devices that show up on xenbus (a virtual bus). In order to initialize
>>> xenbus, the guest only needs the hypervisor node.  So I'll remove the
>>> ranges and interrupt-map.
>>
>> So all the peripherals are actually discoverable - awesome!
>>
>> But the fact is that the only "vexpressness" of this tree is
>> memory@80000000 and gic@2c001000. The rest (not much of it ;-) is a
>> "generic A15 platform". 
>>
>> I understand that you had to use some "compatible" value to get
>> initialization code and I'm flattered ;-) by your choice of
>> "arm,vexpress", but maybe - as suggested by others - you would be better
>> off with generating this stuff in runtime, by whatever tool is used to
>> instantiate the guest?
> 
> Yes, it is certainly going to be generated at run time. Does it make
> sense to keep an example under arch/arm/boot/dts? I think so. There must
> be other platforms that actually pass the device tree to the kernel from
> the firmware and still have a dts in the kernel tree, right?
> If actually there are none, it is probably best to forget about this
> patch :)
> 
> Regarding the choice of "arm,vexpress", there was a discussion at kernel
> summit about vexpress being the right choice as a base platform for
> virtual machines on ARM, even though in the Xen case it means having a
> vexpress with no peripherals.

I think the important thing here is that the memory map is RS1. As this
is a (very limited) subset of a vexpress A15, it seems to make some sense.

I still think it is useful at have an example of such a platform in the
tree, if only as a very minimal example.

	M.
-- 
Jazz is not dead. It just smells funny...


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 20 12:30:44 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Sep 2012 12:30:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TEftl-0005Vv-6M; Thu, 20 Sep 2012 12:30: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 1TEftj-0005Vn-Nt
	for xen-devel@lists.xen.org; Thu, 20 Sep 2012 12:30:27 +0000
Received: from [85.158.139.83:24357] by server-1.bemta-5.messagelabs.com id
	A9/1B-04809-36C0B505; Thu, 20 Sep 2012 12:30:27 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1348144225!24164572!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTA0NTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12365 invoked from network); 20 Sep 2012 12:30:26 -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;
	20 Sep 2012 12:30:26 -0000
X-IronPort-AV: E=Sophos;i="4.80,453,1344211200"; d="scan'208";a="14655560"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Sep 2012 12:30: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.279.1; Thu, 20 Sep 2012 13:30:25 +0100
Date: Thu, 20 Sep 2012 13:29:37 +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: <1348139574-23324-3-git-send-email-anthony.perard@citrix.com>
Message-ID: <alpine.DEB.2.02.1209201328030.29232@kaball.uk.xensource.com>
References: <1348139574-23324-1-git-send-email-anthony.perard@citrix.com>
	<1348139574-23324-3-git-send-email-anthony.perard@citrix.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>,
	QEMU-devel <qemu-devel@nongnu.org>,
	Luiz Capitulino <lcapitulino@redhat.com>,
	Avi Kivity <avi@redhat.com>, Xen Devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH V3 2/5] xen: Introduce xen_modified_memory.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 20 Sep 2012, Anthony PERARD wrote:
> This function is to be used during live migration. Every write access to the
> guest memory should call this funcion so the Xen tools knows which pages are
> dirty.
> 
> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
> ---
>  hw/xen.h   |  1 +
>  xen-all.c  | 21 +++++++++++++++++++++
>  xen-stub.c |  4 ++++
>  3 files changed, 26 insertions(+)
> 
> diff --git a/hw/xen.h b/hw/xen.h
> index e5926b7..d14e92d 100644
> --- a/hw/xen.h
> +++ b/hw/xen.h
> @@ -48,6 +48,7 @@ void xenstore_store_pv_console_info(int i, struct CharDriverState *chr);
>  struct MemoryRegion;
>  void xen_ram_alloc(ram_addr_t ram_addr, ram_addr_t size,
>                     struct MemoryRegion *mr);
> +void xen_modified_memory(ram_addr_t start, ram_addr_t length);
>  #endif
>  
>  struct MemoryRegion;
> diff --git a/xen-all.c b/xen-all.c
> index f75ae9f..6250593 100644
> --- a/xen-all.c
> +++ b/xen-all.c
> @@ -1228,3 +1228,24 @@ void xen_shutdown_fatal_error(const char *fmt, ...)
>      /* destroy the domain */
>      qemu_system_shutdown_request();
>  }
> +
> +void xen_modified_memory(ram_addr_t start, ram_addr_t length)
> +{
> +    if (unlikely(xen_in_migration)) {
> +        int rc;
> +        ram_addr_t start_pfn, nb_pages;
> +
> +        if (length == 0) {
> +            length = TARGET_PAGE_SIZE;
> +        }
> +        start_pfn = start >> TARGET_PAGE_BITS;
> +        nb_pages = ((start + length + TARGET_PAGE_SIZE - 1) >> TARGET_PAGE_BITS)
> +            - start_pfn;
> +        rc = xc_hvm_modified_memory(xen_xc, xen_domid, start_pfn, nb_pages);
> +        if (rc) {
> +            fprintf(stderr, "%s failed for "RAM_ADDR_FMT" ("RAM_ADDR_FMT
> +                    "): %i, %s\n", __func__,
> +                    start, nb_pages, rc, strerror(-rc));

a would prefer a more sane way of splitting this sentence in lines

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 20 12:30:44 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Sep 2012 12:30:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TEftl-0005Vv-6M; Thu, 20 Sep 2012 12:30: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 1TEftj-0005Vn-Nt
	for xen-devel@lists.xen.org; Thu, 20 Sep 2012 12:30:27 +0000
Received: from [85.158.139.83:24357] by server-1.bemta-5.messagelabs.com id
	A9/1B-04809-36C0B505; Thu, 20 Sep 2012 12:30:27 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1348144225!24164572!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTA0NTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12365 invoked from network); 20 Sep 2012 12:30:26 -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;
	20 Sep 2012 12:30:26 -0000
X-IronPort-AV: E=Sophos;i="4.80,453,1344211200"; d="scan'208";a="14655560"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Sep 2012 12:30: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.279.1; Thu, 20 Sep 2012 13:30:25 +0100
Date: Thu, 20 Sep 2012 13:29:37 +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: <1348139574-23324-3-git-send-email-anthony.perard@citrix.com>
Message-ID: <alpine.DEB.2.02.1209201328030.29232@kaball.uk.xensource.com>
References: <1348139574-23324-1-git-send-email-anthony.perard@citrix.com>
	<1348139574-23324-3-git-send-email-anthony.perard@citrix.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>,
	QEMU-devel <qemu-devel@nongnu.org>,
	Luiz Capitulino <lcapitulino@redhat.com>,
	Avi Kivity <avi@redhat.com>, Xen Devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH V3 2/5] xen: Introduce xen_modified_memory.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 20 Sep 2012, Anthony PERARD wrote:
> This function is to be used during live migration. Every write access to the
> guest memory should call this funcion so the Xen tools knows which pages are
> dirty.
> 
> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
> ---
>  hw/xen.h   |  1 +
>  xen-all.c  | 21 +++++++++++++++++++++
>  xen-stub.c |  4 ++++
>  3 files changed, 26 insertions(+)
> 
> diff --git a/hw/xen.h b/hw/xen.h
> index e5926b7..d14e92d 100644
> --- a/hw/xen.h
> +++ b/hw/xen.h
> @@ -48,6 +48,7 @@ void xenstore_store_pv_console_info(int i, struct CharDriverState *chr);
>  struct MemoryRegion;
>  void xen_ram_alloc(ram_addr_t ram_addr, ram_addr_t size,
>                     struct MemoryRegion *mr);
> +void xen_modified_memory(ram_addr_t start, ram_addr_t length);
>  #endif
>  
>  struct MemoryRegion;
> diff --git a/xen-all.c b/xen-all.c
> index f75ae9f..6250593 100644
> --- a/xen-all.c
> +++ b/xen-all.c
> @@ -1228,3 +1228,24 @@ void xen_shutdown_fatal_error(const char *fmt, ...)
>      /* destroy the domain */
>      qemu_system_shutdown_request();
>  }
> +
> +void xen_modified_memory(ram_addr_t start, ram_addr_t length)
> +{
> +    if (unlikely(xen_in_migration)) {
> +        int rc;
> +        ram_addr_t start_pfn, nb_pages;
> +
> +        if (length == 0) {
> +            length = TARGET_PAGE_SIZE;
> +        }
> +        start_pfn = start >> TARGET_PAGE_BITS;
> +        nb_pages = ((start + length + TARGET_PAGE_SIZE - 1) >> TARGET_PAGE_BITS)
> +            - start_pfn;
> +        rc = xc_hvm_modified_memory(xen_xc, xen_domid, start_pfn, nb_pages);
> +        if (rc) {
> +            fprintf(stderr, "%s failed for "RAM_ADDR_FMT" ("RAM_ADDR_FMT
> +                    "): %i, %s\n", __func__,
> +                    start, nb_pages, rc, strerror(-rc));

a would prefer a more sane way of splitting this sentence in lines

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 20 12:32:42 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Sep 2012 12:32:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TEfve-0005eD-NQ; Thu, 20 Sep 2012 12:32:26 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1TEfvd-0005e3-PP
	for xen-devel@lists.xen.org; Thu, 20 Sep 2012 12:32:25 +0000
Received: from [85.158.139.211:6875] by server-2.bemta-5.messagelabs.com id
	50/F8-11456-8DC0B505; Thu, 20 Sep 2012 12:32:24 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-11.tower-206.messagelabs.com!1348144344!19324716!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTA0NTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32274 invoked from network); 20 Sep 2012 12:32:24 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Sep 2012 12:32:24 -0000
X-IronPort-AV: E=Sophos;i="4.80,453,1344211200"; d="scan'208";a="14655609"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Sep 2012 12:32: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.279.1; Thu, 20 Sep 2012 13:32:24 +0100
Date: Thu, 20 Sep 2012 13:31:35 +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: <1348139574-23324-6-git-send-email-anthony.perard@citrix.com>
Message-ID: <alpine.DEB.2.02.1209201330340.29232@kaball.uk.xensource.com>
References: <1348139574-23324-1-git-send-email-anthony.perard@citrix.com>
	<1348139574-23324-6-git-send-email-anthony.perard@citrix.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>,
	QEMU-devel <qemu-devel@nongnu.org>,
	Luiz Capitulino <lcapitulino@redhat.com>,
	Avi Kivity <avi@redhat.com>, Xen Devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH V3 5/5] xen: Set the vram dirty when an
	error occur.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 20 Sep 2012, Anthony PERARD wrote:
> If the call to xc_hvm_track_dirty_vram() fails, then we set dirtybit on all the
> video ram. This case happens during migration, but we don't need a special case
> for live migration with patch.

Just as a reference, what is this special case for live migration that
you are talking about? A pointer to the qemu-xen-traditional code would
be welcomed here.



> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
> ---
>  xen-all.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/xen-all.c b/xen-all.c
> index 6250593..ab28261 100644
> --- a/xen-all.c
> +++ b/xen-all.c
> @@ -507,7 +507,8 @@ static void xen_sync_dirty_bitmap(XenIOState *state,
>                                   bitmap);
>      if (rc < 0) {
>          if (rc != -ENODATA) {
> -            fprintf(stderr, "xen: track_dirty_vram failed (0x" TARGET_FMT_plx
> +            memory_region_set_dirty(framebuffer, 0, size);
> +            DPRINTF("xen: track_dirty_vram failed (0x" TARGET_FMT_plx
>                      ", 0x" TARGET_FMT_plx "): %s\n",
>                      start_addr, start_addr + size, strerror(-rc));
>          }
> -- 
> 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 Sep 20 12:32:42 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Sep 2012 12:32:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TEfve-0005eD-NQ; Thu, 20 Sep 2012 12:32:26 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1TEfvd-0005e3-PP
	for xen-devel@lists.xen.org; Thu, 20 Sep 2012 12:32:25 +0000
Received: from [85.158.139.211:6875] by server-2.bemta-5.messagelabs.com id
	50/F8-11456-8DC0B505; Thu, 20 Sep 2012 12:32:24 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-11.tower-206.messagelabs.com!1348144344!19324716!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTA0NTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32274 invoked from network); 20 Sep 2012 12:32:24 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Sep 2012 12:32:24 -0000
X-IronPort-AV: E=Sophos;i="4.80,453,1344211200"; d="scan'208";a="14655609"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Sep 2012 12:32: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.279.1; Thu, 20 Sep 2012 13:32:24 +0100
Date: Thu, 20 Sep 2012 13:31:35 +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: <1348139574-23324-6-git-send-email-anthony.perard@citrix.com>
Message-ID: <alpine.DEB.2.02.1209201330340.29232@kaball.uk.xensource.com>
References: <1348139574-23324-1-git-send-email-anthony.perard@citrix.com>
	<1348139574-23324-6-git-send-email-anthony.perard@citrix.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>,
	QEMU-devel <qemu-devel@nongnu.org>,
	Luiz Capitulino <lcapitulino@redhat.com>,
	Avi Kivity <avi@redhat.com>, Xen Devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH V3 5/5] xen: Set the vram dirty when an
	error occur.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 20 Sep 2012, Anthony PERARD wrote:
> If the call to xc_hvm_track_dirty_vram() fails, then we set dirtybit on all the
> video ram. This case happens during migration, but we don't need a special case
> for live migration with patch.

Just as a reference, what is this special case for live migration that
you are talking about? A pointer to the qemu-xen-traditional code would
be welcomed here.



> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
> ---
>  xen-all.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/xen-all.c b/xen-all.c
> index 6250593..ab28261 100644
> --- a/xen-all.c
> +++ b/xen-all.c
> @@ -507,7 +507,8 @@ static void xen_sync_dirty_bitmap(XenIOState *state,
>                                   bitmap);
>      if (rc < 0) {
>          if (rc != -ENODATA) {
> -            fprintf(stderr, "xen: track_dirty_vram failed (0x" TARGET_FMT_plx
> +            memory_region_set_dirty(framebuffer, 0, size);
> +            DPRINTF("xen: track_dirty_vram failed (0x" TARGET_FMT_plx
>                      ", 0x" TARGET_FMT_plx "): %s\n",
>                      start_addr, start_addr + size, strerror(-rc));
>          }
> -- 
> 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 Sep 20 12:41:06 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Sep 2012 12:41: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 1TEg3n-00060Z-N6; Thu, 20 Sep 2012 12:40:51 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1TEg3l-00060U-OM
	for xen-devel@lists.xensource.com; Thu, 20 Sep 2012 12:40:49 +0000
Received: from [85.158.138.51:32647] by server-8.bemta-3.messagelabs.com id
	32/B0-24700-0DE0B505; Thu, 20 Sep 2012 12:40:48 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1348144847!31411678!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTA0NTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18796 invoked from network); 20 Sep 2012 12:40:48 -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 Sep 2012 12:40:48 -0000
X-IronPort-AV: E=Sophos;i="4.80,453,1344211200"; d="scan'208";a="14655854"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Sep 2012 12:40: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.279.1; Thu, 20 Sep 2012 13:40:47 +0100
Date: Thu, 20 Sep 2012 13:39: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: <1348143533.26501.28.camel@zakaz.uk.xensource.com>
Message-ID: <alpine.DEB.2.02.1209201333460.29232@kaball.uk.xensource.com>
References: <1348076658-4511-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<1348136222.26501.19.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.02.1209201240110.29232@kaball.uk.xensource.com>
	<1348143533.26501.28.camel@zakaz.uk.xensource.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Pawel Moll <pawel.moll@arm.com>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Xen-devel] [PATCH] arm: introduce a DTS for Xen unprivileged
 virtual 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 Thu, 20 Sep 2012, Ian Campbell wrote:
> > Versatile Express is flexible enough to be a good base for our own
> > virtual machine platform, especially if the maintainers keep an eye on
> > getting everything through DT and not expecting devices just to be there
> > ;-)
> 
> Perhaps what we want is a stricter subset of the stuff in mach-vexpress
> then. But if so then this should be expressed both in the DT and in the
> code, not just papered over by declaring things compatible when they are
> not.

But it is already expressed in the DT, by removing all the device nodes
we don't emulated. And it is already expressed in the code, by fully
discovering peripherals via DT, therefore not trying to initialize
non-present devices.


> > > > +	gic: interrupt-controller@2c001000 {
> > > > +		compatible = "arm,cortex-a9-gic";
> > > 
> > > Don't we mean "arm,cortex-a15-gic" here? That's what we actually
> > > provide. I'm not sure how the a9 and a15 differ.
> > 
> > The GIC that comes with vexpress is a9 compatible.
> 
> The GIC which Xen emulates is the one which matters here though, and
> that is an a15.

The a15 gic is still a9 compatible. OK to be precise I am going to add
"arm,cortex-a15-gic", but I cannot really remove "arm,cortex-a9-gic".

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 20 12:41:06 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Sep 2012 12:41: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 1TEg3n-00060Z-N6; Thu, 20 Sep 2012 12:40:51 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1TEg3l-00060U-OM
	for xen-devel@lists.xensource.com; Thu, 20 Sep 2012 12:40:49 +0000
Received: from [85.158.138.51:32647] by server-8.bemta-3.messagelabs.com id
	32/B0-24700-0DE0B505; Thu, 20 Sep 2012 12:40:48 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1348144847!31411678!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTA0NTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18796 invoked from network); 20 Sep 2012 12:40:48 -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 Sep 2012 12:40:48 -0000
X-IronPort-AV: E=Sophos;i="4.80,453,1344211200"; d="scan'208";a="14655854"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Sep 2012 12:40: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.279.1; Thu, 20 Sep 2012 13:40:47 +0100
Date: Thu, 20 Sep 2012 13:39: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: <1348143533.26501.28.camel@zakaz.uk.xensource.com>
Message-ID: <alpine.DEB.2.02.1209201333460.29232@kaball.uk.xensource.com>
References: <1348076658-4511-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<1348136222.26501.19.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.02.1209201240110.29232@kaball.uk.xensource.com>
	<1348143533.26501.28.camel@zakaz.uk.xensource.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Pawel Moll <pawel.moll@arm.com>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Xen-devel] [PATCH] arm: introduce a DTS for Xen unprivileged
 virtual 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 Thu, 20 Sep 2012, Ian Campbell wrote:
> > Versatile Express is flexible enough to be a good base for our own
> > virtual machine platform, especially if the maintainers keep an eye on
> > getting everything through DT and not expecting devices just to be there
> > ;-)
> 
> Perhaps what we want is a stricter subset of the stuff in mach-vexpress
> then. But if so then this should be expressed both in the DT and in the
> code, not just papered over by declaring things compatible when they are
> not.

But it is already expressed in the DT, by removing all the device nodes
we don't emulated. And it is already expressed in the code, by fully
discovering peripherals via DT, therefore not trying to initialize
non-present devices.


> > > > +	gic: interrupt-controller@2c001000 {
> > > > +		compatible = "arm,cortex-a9-gic";
> > > 
> > > Don't we mean "arm,cortex-a15-gic" here? That's what we actually
> > > provide. I'm not sure how the a9 and a15 differ.
> > 
> > The GIC that comes with vexpress is a9 compatible.
> 
> The GIC which Xen emulates is the one which matters here though, and
> that is an a15.

The a15 gic is still a9 compatible. OK to be precise I am going to add
"arm,cortex-a15-gic", but I cannot really remove "arm,cortex-a9-gic".

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 20 12:57:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Sep 2012 12: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 1TEgJC-0006T4-SS; Thu, 20 Sep 2012 12:56:46 +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 1TEgJC-0006Sw-0M
	for xen-devel@lists.xen.org; Thu, 20 Sep 2012 12:56:46 +0000
Received: from [85.158.139.211:51341] by server-11.bemta-5.messagelabs.com id
	ED/6F-24658-D821B505; Thu, 20 Sep 2012 12:56:45 +0000
X-Env-Sender: ben.guthro@gmail.com
X-Msg-Ref: server-2.tower-206.messagelabs.com!1348145803!19304377!1
X-Originating-IP: [209.85.223.173]
X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE,
	RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12039 invoked from network); 20 Sep 2012 12:56:44 -0000
Received: from mail-ie0-f173.google.com (HELO mail-ie0-f173.google.com)
	(209.85.223.173)
	by server-2.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Sep 2012 12:56:44 -0000
Received: by iebc10 with SMTP id c10so4261056ieb.32
	for <xen-devel@lists.xen.org>; Thu, 20 Sep 2012 05:56: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;
	bh=sqOmyjJtXERM7KcQ4r0NrDOTRFBA12ZUImGwGp1eqSY=;
	b=LvUV7sUWyMNRdqEoeV4lZGUF5lsGs4dqQ6hysAumeBqOe19QM3z4E18nmfUQW/IQ9u
	d18Aa/lBd1zEkPDqyvymcEThDTO+jnKE3q9N11rW0QtaKewanhI232hc5LKFzuoN8XP7
	yHXexuRCXCR1HV77JXg0pPbfXsukr24JSxIVKf6E3NR0t2+R2jPDG+oZatYQNtcj5O5d
	yoxsj7/Mye9SylaNts6qQIhmbB98bwQxLQLme1XvGsuUtSn5J8UXVb2EAGGNA5fQ3Dm/
	G8HIx9rnHUWjBEKuJ9j8fdYSizr91eZKvqspWOOM22SQhxIYsB6wvQNu9XBFiZXf+lPS
	87EA==
MIME-Version: 1.0
Received: by 10.50.169.3 with SMTP id aa3mr1557212igc.54.1348145802813; Thu,
	20 Sep 2012 05:56:42 -0700 (PDT)
Received: by 10.64.55.132 with HTTP; Thu, 20 Sep 2012 05:56:42 -0700 (PDT)
In-Reply-To: <505AE9DB020000780009C813@nat28.tlf.novell.com>
References: <CAOvdn6Xn1ZnontBO0KoJE9hgBsW-a1rR2EhWYEpgbbrELkXZNw@mail.gmail.com>
	<CC80728B.3F362%keir.xen@gmail.com>
	<505AE9DB020000780009C813@nat28.tlf.novell.com>
Date: Thu, 20 Sep 2012 08:56:42 -0400
X-Google-Sender-Auth: paL9YlB5Z49nDbtHrKp-NcfQM5o
Message-ID: <CAOvdn6VF+1KP0EkzwkoAEoc=B2bcLUWteOM8HmN-cj_YosN-pw@mail.gmail.com>
From: Ben Guthro <ben@guthro.net>
To: Jan Beulich <JBeulich@suse.com>
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Keir Fraser <keir.xen@gmail.com>, john.baboval@citrix.com,
	Thomas Goetz <thomas.goetz@citrix.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen4.2 S3 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: multipart/mixed; boundary="===============7827870452055413886=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============7827870452055413886==
Content-Type: multipart/alternative; boundary=e89a8f234361aea26b04ca21a733

--e89a8f234361aea26b04ca21a733
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

It appears __cpu_disable() is not getting reached at all, for CPU1

I put a cpu id conditional BUG() call in there, to verify - and while it is
reached when using
xen-hptool cpu-offline 1
It never seems to be reached from the S3 path.


What is the expected call chain to get into this code during S3?


On Thu, Sep 20, 2012 at 4:03 AM, Jan Beulich <JBeulich@suse.com> wrote:

> >>> On 20.09.12 at 08:13, Keir Fraser <keir.xen@gmail.com> wrote:
> > CPU#1 got stuck in loop in cpu_init() as it appears to be =8Calready
> > initialised=B9 in cpu_initialized bitmap. CPU#0 detects it is stuck and
> > carries on, but the resume code assumes all CPUs are brought back onlin=
e
> and
> > crashes later.
>
> So this would suggest play_dead() (-> cpu_exit_clear() ->
> cpu_uninit()) not getting reached during the suspend cycle.
> That should be fairly easy to verify, as the serial console
> ought to still work when the secondary CPUs get offlined.
>
> That might imply cpumask_clear_cpu(cpu, &cpu_online_map)
> not getting reached in __cpu_disable(), which would be in line
> with the observation that none of the logs provided so far
> showed anything being done by fixup_irqs() (called right
> after clearing the online bit).
>
> Jan
>

--e89a8f234361aea26b04ca21a733
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

It appears __cpu_disable() is not getting reached at all, for CPU1<div><br>=
</div><div>I put a cpu id conditional BUG() call in there, to verify - and =
while it is reached when using=A0</div><div>xen-hptool cpu-offline 1</div>

<div>It never seems to be reached from the S3 path.</div><div><br></div><di=
v><br></div><div>What is the expected call chain to get into this code duri=
ng S3?</div><div><br><br><div class=3D"gmail_quote">On Thu, Sep 20, 2012 at=
 4:03 AM, 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>

<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">&gt;&gt;&gt; On 20.09.12 at 08:13, Keir Fras=
er &lt;<a href=3D"mailto:keir.xen@gmail.com" target=3D"_blank">keir.xen@gma=
il.com</a>&gt; wrote:<br>


&gt; CPU#1 got stuck in loop in cpu_init() as it appears to be =8Calready<b=
r>
<div>&gt; initialised=B9 in cpu_initialized bitmap. CPU#0 detects it is stu=
ck and<br>
&gt; carries on, but the resume code assumes all CPUs are brought back onli=
ne and<br>
&gt; crashes later.<br>
<br>
</div>So this would suggest play_dead() (-&gt; cpu_exit_clear() -&gt;<br>
cpu_uninit()) not getting reached during the suspend cycle.<br>
That should be fairly easy to verify, as the serial console<br>
ought to still work when the secondary CPUs get offlined.<br>
<br>
That might imply cpumask_clear_cpu(cpu, &amp;cpu_online_map)<br>
not getting reached in __cpu_disable(), which would be in line<br>
with the observation that none of the logs provided so far<br>
showed anything being done by fixup_irqs() (called right<br>
after clearing the online bit).<br>
<span><font color=3D"#888888"><br>
Jan<br>
</font></span></blockquote></div><br></div>

--e89a8f234361aea26b04ca21a733--


--===============7827870452055413886==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============7827870452055413886==--


From xen-devel-bounces@lists.xen.org Thu Sep 20 12:57:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Sep 2012 12: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 1TEgJC-0006T4-SS; Thu, 20 Sep 2012 12:56:46 +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 1TEgJC-0006Sw-0M
	for xen-devel@lists.xen.org; Thu, 20 Sep 2012 12:56:46 +0000
Received: from [85.158.139.211:51341] by server-11.bemta-5.messagelabs.com id
	ED/6F-24658-D821B505; Thu, 20 Sep 2012 12:56:45 +0000
X-Env-Sender: ben.guthro@gmail.com
X-Msg-Ref: server-2.tower-206.messagelabs.com!1348145803!19304377!1
X-Originating-IP: [209.85.223.173]
X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE,
	RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12039 invoked from network); 20 Sep 2012 12:56:44 -0000
Received: from mail-ie0-f173.google.com (HELO mail-ie0-f173.google.com)
	(209.85.223.173)
	by server-2.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Sep 2012 12:56:44 -0000
Received: by iebc10 with SMTP id c10so4261056ieb.32
	for <xen-devel@lists.xen.org>; Thu, 20 Sep 2012 05:56: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;
	bh=sqOmyjJtXERM7KcQ4r0NrDOTRFBA12ZUImGwGp1eqSY=;
	b=LvUV7sUWyMNRdqEoeV4lZGUF5lsGs4dqQ6hysAumeBqOe19QM3z4E18nmfUQW/IQ9u
	d18Aa/lBd1zEkPDqyvymcEThDTO+jnKE3q9N11rW0QtaKewanhI232hc5LKFzuoN8XP7
	yHXexuRCXCR1HV77JXg0pPbfXsukr24JSxIVKf6E3NR0t2+R2jPDG+oZatYQNtcj5O5d
	yoxsj7/Mye9SylaNts6qQIhmbB98bwQxLQLme1XvGsuUtSn5J8UXVb2EAGGNA5fQ3Dm/
	G8HIx9rnHUWjBEKuJ9j8fdYSizr91eZKvqspWOOM22SQhxIYsB6wvQNu9XBFiZXf+lPS
	87EA==
MIME-Version: 1.0
Received: by 10.50.169.3 with SMTP id aa3mr1557212igc.54.1348145802813; Thu,
	20 Sep 2012 05:56:42 -0700 (PDT)
Received: by 10.64.55.132 with HTTP; Thu, 20 Sep 2012 05:56:42 -0700 (PDT)
In-Reply-To: <505AE9DB020000780009C813@nat28.tlf.novell.com>
References: <CAOvdn6Xn1ZnontBO0KoJE9hgBsW-a1rR2EhWYEpgbbrELkXZNw@mail.gmail.com>
	<CC80728B.3F362%keir.xen@gmail.com>
	<505AE9DB020000780009C813@nat28.tlf.novell.com>
Date: Thu, 20 Sep 2012 08:56:42 -0400
X-Google-Sender-Auth: paL9YlB5Z49nDbtHrKp-NcfQM5o
Message-ID: <CAOvdn6VF+1KP0EkzwkoAEoc=B2bcLUWteOM8HmN-cj_YosN-pw@mail.gmail.com>
From: Ben Guthro <ben@guthro.net>
To: Jan Beulich <JBeulich@suse.com>
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Keir Fraser <keir.xen@gmail.com>, john.baboval@citrix.com,
	Thomas Goetz <thomas.goetz@citrix.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen4.2 S3 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: multipart/mixed; boundary="===============7827870452055413886=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============7827870452055413886==
Content-Type: multipart/alternative; boundary=e89a8f234361aea26b04ca21a733

--e89a8f234361aea26b04ca21a733
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

It appears __cpu_disable() is not getting reached at all, for CPU1

I put a cpu id conditional BUG() call in there, to verify - and while it is
reached when using
xen-hptool cpu-offline 1
It never seems to be reached from the S3 path.


What is the expected call chain to get into this code during S3?


On Thu, Sep 20, 2012 at 4:03 AM, Jan Beulich <JBeulich@suse.com> wrote:

> >>> On 20.09.12 at 08:13, Keir Fraser <keir.xen@gmail.com> wrote:
> > CPU#1 got stuck in loop in cpu_init() as it appears to be =8Calready
> > initialised=B9 in cpu_initialized bitmap. CPU#0 detects it is stuck and
> > carries on, but the resume code assumes all CPUs are brought back onlin=
e
> and
> > crashes later.
>
> So this would suggest play_dead() (-> cpu_exit_clear() ->
> cpu_uninit()) not getting reached during the suspend cycle.
> That should be fairly easy to verify, as the serial console
> ought to still work when the secondary CPUs get offlined.
>
> That might imply cpumask_clear_cpu(cpu, &cpu_online_map)
> not getting reached in __cpu_disable(), which would be in line
> with the observation that none of the logs provided so far
> showed anything being done by fixup_irqs() (called right
> after clearing the online bit).
>
> Jan
>

--e89a8f234361aea26b04ca21a733
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

It appears __cpu_disable() is not getting reached at all, for CPU1<div><br>=
</div><div>I put a cpu id conditional BUG() call in there, to verify - and =
while it is reached when using=A0</div><div>xen-hptool cpu-offline 1</div>

<div>It never seems to be reached from the S3 path.</div><div><br></div><di=
v><br></div><div>What is the expected call chain to get into this code duri=
ng S3?</div><div><br><br><div class=3D"gmail_quote">On Thu, Sep 20, 2012 at=
 4:03 AM, 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>

<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">&gt;&gt;&gt; On 20.09.12 at 08:13, Keir Fras=
er &lt;<a href=3D"mailto:keir.xen@gmail.com" target=3D"_blank">keir.xen@gma=
il.com</a>&gt; wrote:<br>


&gt; CPU#1 got stuck in loop in cpu_init() as it appears to be =8Calready<b=
r>
<div>&gt; initialised=B9 in cpu_initialized bitmap. CPU#0 detects it is stu=
ck and<br>
&gt; carries on, but the resume code assumes all CPUs are brought back onli=
ne and<br>
&gt; crashes later.<br>
<br>
</div>So this would suggest play_dead() (-&gt; cpu_exit_clear() -&gt;<br>
cpu_uninit()) not getting reached during the suspend cycle.<br>
That should be fairly easy to verify, as the serial console<br>
ought to still work when the secondary CPUs get offlined.<br>
<br>
That might imply cpumask_clear_cpu(cpu, &amp;cpu_online_map)<br>
not getting reached in __cpu_disable(), which would be in line<br>
with the observation that none of the logs provided so far<br>
showed anything being done by fixup_irqs() (called right<br>
after clearing the online bit).<br>
<span><font color=3D"#888888"><br>
Jan<br>
</font></span></blockquote></div><br></div>

--e89a8f234361aea26b04ca21a733--


--===============7827870452055413886==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============7827870452055413886==--


From xen-devel-bounces@lists.xen.org Thu Sep 20 12:57:56 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Sep 2012 12: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 1TEgK8-0006Wv-BA; Thu, 20 Sep 2012 12:57:44 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dave.martin@linaro.org>) id 1TEgK7-0006WQ-4a
	for xen-devel@lists.xensource.com; Thu, 20 Sep 2012 12:57:43 +0000
X-Env-Sender: dave.martin@linaro.org
X-Msg-Ref: server-7.tower-27.messagelabs.com!1348145855!4064771!1
X-Originating-IP: [209.85.215.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6424 invoked from network); 20 Sep 2012 12:57:35 -0000
Received: from mail-ey0-f171.google.com (HELO mail-ey0-f171.google.com)
	(209.85.215.171)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Sep 2012 12:57:35 -0000
Received: by eaah11 with SMTP id h11so717243eaa.30
	for <xen-devel@lists.xensource.com>;
	Thu, 20 Sep 2012 05:57:35 -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=zy/nwGjxYWvREFJNw+Nzm9LVCpoB7wKZaEmhHP9z/a4=;
	b=pKndR3P0D5LIJy+5vh0i/ETeomKIDtbMvSOOBzNCiOm5QQPns0mEmRW2YXjlfn12C4
	LhdAB6R6shrhM0ziSkbELQnWX8zr37ZMBEKW4Lz/Dras9AKM5DZVtkTqAf0P+4/urYD8
	ZZhnwNFU1ji8D7m/eQSC6FdFVtC8Oe2dPUiMJk7IZ0Fo72EDWCJffdqNK8QJ322LJLJD
	4mk+awQ2Nxu8FjV4/0/+D4o1e//wLV0om+/vNv9C+ATvlDAlmkCrGCwQjmbNffmydu+a
	3+t9UnW56R4cU9NWulf99CCcgjuya5TfVbgI80I2CzkUAptjydcygsV0fouFezoAltaM
	nlyw==
Received: by 10.14.224.73 with SMTP id w49mr2108092eep.37.1348145854815;
	Thu, 20 Sep 2012 05:57:34 -0700 (PDT)
Received: from linaro.org (fw-lnat.cambridge.arm.com. [217.140.96.63])
	by mx.google.com with ESMTPS id y1sm15545111eel.0.2012.09.20.05.57.32
	(version=SSLv3 cipher=OTHER); Thu, 20 Sep 2012 05:57:34 -0700 (PDT)
Date: Thu, 20 Sep 2012 13:57:30 +0100
From: Dave Martin <dave.martin@linaro.org>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20120920125730.GE2117@linaro.org>
References: <1348076658-4511-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<505AF3E5.1050306@citrix.com> <20120920112102.GD2117@linaro.org>
	<alpine.DEB.2.02.1209201302440.29232@kaball.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <alpine.DEB.2.02.1209201302440.29232@kaball.uk.xensource.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Gm-Message-State: ALoCoQlKzM12o6yA4AYbmRe1iywlusJy6MNoyymLuGkBI9YYxMIsTlwLT1i2EA2D+mwZW0X4vfMa
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, Pawel Moll <pawel.moll@arm.com>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	David Vrabel <david.vrabel@citrix.com>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Xen-devel] [PATCH] arm: introduce a DTS for Xen unprivileged
 virtual 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 Thu, Sep 20, 2012 at 01:04:34PM +0100, Stefano Stabellini wrote:
> On Thu, 20 Sep 2012, Dave Martin wrote:
> > On Thu, Sep 20, 2012 at 11:45:57AM +0100, David Vrabel wrote:
> > > On 19/09/12 18:44, Stefano Stabellini wrote:
> > > > --- /dev/null
> > > > +++ b/arch/arm/boot/dts/vexpress-xenvm-4.2.dts
> > > 
> > > Does this make sense?  There is no fixed configuration for VMs.
> > > 
> > > Is the intention to pass a DTS to the toolstack for it to create the VM
> > > with the appropriate amount of memory and peripheral mapped to the right
> > > place etc?  Or is the toolstack going to create the VM and generate the
> > > DTB from (e.g.,) an xl VM configuration file.
> > > 
> > > > +
> > > > +	hypervisor {
> > > > +		compatible = "xen,xen-4.2", "xen,xen";
> > > > +		reg = <0xb0000000 0x20000>;
> > > > +		interrupts = <1 15 0xf08>;
> > > > +	};
> > > 
> > > This node needs to be generated by the toolstack as only it knows what
> > > ABI the hypervisor has.
> > 
> > That's a good point: the same applies to the command line.  The toolstack
> > knows where the console and root device should be etc.: the kernel itself
> > shouldn't have static defaults for those.
> 
> As I was saying in the other email, this dts is just supposed to be a
> reference. The real one is going to come from the toolstack or the
> hypervisor. 
> 
> But isn't the same true for other dts as well? Aren't they supposed to
> be passed to the kernel by the bootloader?

Opinions on this may differ -- but I would say that the bootloader (or
virtualisation toolstack) should receive a dtb as configuration data for
the image, and should do the minimum appropriate customisations on it.
The rationale for that is that fixing buggy firmware is harder than
deploying a new device tree blob.

For a virtualisation toolstack, I think the expected level of
customisation might be higher: because it is the toolstack that knows
what virtualised I/O devices the guest is supposed to attach to etc. 
For example, if I want to boot a guest using a particular image file as
its disk, then the toolstack needs to set things up, and then boot the
guest OS with appropriate configuration.  Exactly _what_ configuration
may be a private protocol between the toolstack, the hypervisor/host and
the client drivers in the guest OS.

But for all the stuff which never changes in the guest VM (such as the
simulated interrupt controller topology, or whatever) the dts can be
fairly static and just provided as input to the toolstack; part of the
configuration for a particular guest image.

That means that the static parts of the config can be fixed
independently of the toolstack if necessary.  Fixing the dynamic
configuration aspects independently of the toolstack makes less sense
because the toolstack really does have to participate in those areas.

This is just my view, though.

Cheers
---Dave

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 20 12:57:56 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Sep 2012 12: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 1TEgK8-0006Wv-BA; Thu, 20 Sep 2012 12:57:44 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dave.martin@linaro.org>) id 1TEgK7-0006WQ-4a
	for xen-devel@lists.xensource.com; Thu, 20 Sep 2012 12:57:43 +0000
X-Env-Sender: dave.martin@linaro.org
X-Msg-Ref: server-7.tower-27.messagelabs.com!1348145855!4064771!1
X-Originating-IP: [209.85.215.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6424 invoked from network); 20 Sep 2012 12:57:35 -0000
Received: from mail-ey0-f171.google.com (HELO mail-ey0-f171.google.com)
	(209.85.215.171)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Sep 2012 12:57:35 -0000
Received: by eaah11 with SMTP id h11so717243eaa.30
	for <xen-devel@lists.xensource.com>;
	Thu, 20 Sep 2012 05:57:35 -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=zy/nwGjxYWvREFJNw+Nzm9LVCpoB7wKZaEmhHP9z/a4=;
	b=pKndR3P0D5LIJy+5vh0i/ETeomKIDtbMvSOOBzNCiOm5QQPns0mEmRW2YXjlfn12C4
	LhdAB6R6shrhM0ziSkbELQnWX8zr37ZMBEKW4Lz/Dras9AKM5DZVtkTqAf0P+4/urYD8
	ZZhnwNFU1ji8D7m/eQSC6FdFVtC8Oe2dPUiMJk7IZ0Fo72EDWCJffdqNK8QJ322LJLJD
	4mk+awQ2Nxu8FjV4/0/+D4o1e//wLV0om+/vNv9C+ATvlDAlmkCrGCwQjmbNffmydu+a
	3+t9UnW56R4cU9NWulf99CCcgjuya5TfVbgI80I2CzkUAptjydcygsV0fouFezoAltaM
	nlyw==
Received: by 10.14.224.73 with SMTP id w49mr2108092eep.37.1348145854815;
	Thu, 20 Sep 2012 05:57:34 -0700 (PDT)
Received: from linaro.org (fw-lnat.cambridge.arm.com. [217.140.96.63])
	by mx.google.com with ESMTPS id y1sm15545111eel.0.2012.09.20.05.57.32
	(version=SSLv3 cipher=OTHER); Thu, 20 Sep 2012 05:57:34 -0700 (PDT)
Date: Thu, 20 Sep 2012 13:57:30 +0100
From: Dave Martin <dave.martin@linaro.org>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20120920125730.GE2117@linaro.org>
References: <1348076658-4511-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<505AF3E5.1050306@citrix.com> <20120920112102.GD2117@linaro.org>
	<alpine.DEB.2.02.1209201302440.29232@kaball.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <alpine.DEB.2.02.1209201302440.29232@kaball.uk.xensource.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Gm-Message-State: ALoCoQlKzM12o6yA4AYbmRe1iywlusJy6MNoyymLuGkBI9YYxMIsTlwLT1i2EA2D+mwZW0X4vfMa
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, Pawel Moll <pawel.moll@arm.com>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	David Vrabel <david.vrabel@citrix.com>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Xen-devel] [PATCH] arm: introduce a DTS for Xen unprivileged
 virtual 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 Thu, Sep 20, 2012 at 01:04:34PM +0100, Stefano Stabellini wrote:
> On Thu, 20 Sep 2012, Dave Martin wrote:
> > On Thu, Sep 20, 2012 at 11:45:57AM +0100, David Vrabel wrote:
> > > On 19/09/12 18:44, Stefano Stabellini wrote:
> > > > --- /dev/null
> > > > +++ b/arch/arm/boot/dts/vexpress-xenvm-4.2.dts
> > > 
> > > Does this make sense?  There is no fixed configuration for VMs.
> > > 
> > > Is the intention to pass a DTS to the toolstack for it to create the VM
> > > with the appropriate amount of memory and peripheral mapped to the right
> > > place etc?  Or is the toolstack going to create the VM and generate the
> > > DTB from (e.g.,) an xl VM configuration file.
> > > 
> > > > +
> > > > +	hypervisor {
> > > > +		compatible = "xen,xen-4.2", "xen,xen";
> > > > +		reg = <0xb0000000 0x20000>;
> > > > +		interrupts = <1 15 0xf08>;
> > > > +	};
> > > 
> > > This node needs to be generated by the toolstack as only it knows what
> > > ABI the hypervisor has.
> > 
> > That's a good point: the same applies to the command line.  The toolstack
> > knows where the console and root device should be etc.: the kernel itself
> > shouldn't have static defaults for those.
> 
> As I was saying in the other email, this dts is just supposed to be a
> reference. The real one is going to come from the toolstack or the
> hypervisor. 
> 
> But isn't the same true for other dts as well? Aren't they supposed to
> be passed to the kernel by the bootloader?

Opinions on this may differ -- but I would say that the bootloader (or
virtualisation toolstack) should receive a dtb as configuration data for
the image, and should do the minimum appropriate customisations on it.
The rationale for that is that fixing buggy firmware is harder than
deploying a new device tree blob.

For a virtualisation toolstack, I think the expected level of
customisation might be higher: because it is the toolstack that knows
what virtualised I/O devices the guest is supposed to attach to etc. 
For example, if I want to boot a guest using a particular image file as
its disk, then the toolstack needs to set things up, and then boot the
guest OS with appropriate configuration.  Exactly _what_ configuration
may be a private protocol between the toolstack, the hypervisor/host and
the client drivers in the guest OS.

But for all the stuff which never changes in the guest VM (such as the
simulated interrupt controller topology, or whatever) the dts can be
fairly static and just provided as input to the toolstack; part of the
configuration for a particular guest image.

That means that the static parts of the config can be fixed
independently of the toolstack if necessary.  Fixing the dynamic
configuration aspects independently of the toolstack makes less sense
because the toolstack really does have to participate in those areas.

This is just my view, though.

Cheers
---Dave

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 20 13:07:54 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Sep 2012 13: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 1TEgTi-0006za-Jb; Thu, 20 Sep 2012 13:07:38 +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 1TEgTg-0006zV-Cs
	for xen-devel@lists.xen.org; Thu, 20 Sep 2012 13:07:36 +0000
Received: from [85.158.139.211:57058] by server-6.bemta-5.messagelabs.com id
	3C/B8-21336-7151B505; Thu, 20 Sep 2012 13:07:35 +0000
X-Env-Sender: lars.kurth.xen@gmail.com
X-Msg-Ref: server-2.tower-206.messagelabs.com!1348146454!19306209!1
X-Originating-IP: [74.125.83.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31815 invoked from network); 20 Sep 2012 13:07:35 -0000
Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com)
	(74.125.83.45)
	by server-2.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Sep 2012 13:07:35 -0000
Received: by eeke53 with SMTP id e53so1007083eek.32
	for <xen-devel@lists.xen.org>; Thu, 20 Sep 2012 06:07:34 -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=kmSF8e3ETwYeZqfRg0Lp/anPfhMg2/Vb9m6o5HAe38E=;
	b=yFzoKnZ0vZ/FF+GGpUAtN5RqjtxTrJbsBYGMToadLTI1PsfnUUR+Z1YHhK3fqvby0a
	8SR7o9bUDU36XLoC0xOwjB6odFVGZu73sPX7/sp6DuHov0tDTXJEDptKHfr2qVSJ2t2A
	4h1ZVmQUsgMwE42M8YqEDO/DBaORBpqS9wKgk/T81cCxQPCiZJ9ThYj+WdOZWCXjk0/M
	NrKBa2A0lleTJ3A30P2NRZNC3hYIiav/c10uzzF6tI2D/JwErXjWvdDfR8i926KADl+m
	130keV+uHlPn+zefxV7UrpmVcyW8eaxVmCDUM13r70hUWXzjTCGXoJSzQJq8R3GaQez4
	Dciw==
Received: by 10.14.180.65 with SMTP id i41mr2191750eem.10.1348146454888;
	Thu, 20 Sep 2012 06:07:34 -0700 (PDT)
Received: from [172.16.26.11] (b0fb5b35.bb.sky.com. [176.251.91.53])
	by mx.google.com with ESMTPS id e7sm15579423eep.2.2012.09.20.06.07.33
	(version=SSLv3 cipher=OTHER); Thu, 20 Sep 2012 06:07:34 -0700 (PDT)
Message-ID: <505B1515.5020007@xen.org>
Date: Thu, 20 Sep 2012 14:07:33 +0100
From: Lars Kurth <lars.kurth@xen.org>
User-Agent: Mozilla/5.0 (Windows NT 6.1;
	rv:15.0) Gecko/20120907 Thunderbird/15.0.1
MIME-Version: 1.0
To: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: [Xen-devel] [Minutes] Xen Maintainer,
 Committer and Developer Meeting / September 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

See 
http://wiki.xen.org/wiki/Xen_Maintainer,_Committer_and_Developer_Meeting/September_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 Sep 20 13:07:54 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Sep 2012 13: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 1TEgTi-0006za-Jb; Thu, 20 Sep 2012 13:07:38 +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 1TEgTg-0006zV-Cs
	for xen-devel@lists.xen.org; Thu, 20 Sep 2012 13:07:36 +0000
Received: from [85.158.139.211:57058] by server-6.bemta-5.messagelabs.com id
	3C/B8-21336-7151B505; Thu, 20 Sep 2012 13:07:35 +0000
X-Env-Sender: lars.kurth.xen@gmail.com
X-Msg-Ref: server-2.tower-206.messagelabs.com!1348146454!19306209!1
X-Originating-IP: [74.125.83.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31815 invoked from network); 20 Sep 2012 13:07:35 -0000
Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com)
	(74.125.83.45)
	by server-2.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Sep 2012 13:07:35 -0000
Received: by eeke53 with SMTP id e53so1007083eek.32
	for <xen-devel@lists.xen.org>; Thu, 20 Sep 2012 06:07:34 -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=kmSF8e3ETwYeZqfRg0Lp/anPfhMg2/Vb9m6o5HAe38E=;
	b=yFzoKnZ0vZ/FF+GGpUAtN5RqjtxTrJbsBYGMToadLTI1PsfnUUR+Z1YHhK3fqvby0a
	8SR7o9bUDU36XLoC0xOwjB6odFVGZu73sPX7/sp6DuHov0tDTXJEDptKHfr2qVSJ2t2A
	4h1ZVmQUsgMwE42M8YqEDO/DBaORBpqS9wKgk/T81cCxQPCiZJ9ThYj+WdOZWCXjk0/M
	NrKBa2A0lleTJ3A30P2NRZNC3hYIiav/c10uzzF6tI2D/JwErXjWvdDfR8i926KADl+m
	130keV+uHlPn+zefxV7UrpmVcyW8eaxVmCDUM13r70hUWXzjTCGXoJSzQJq8R3GaQez4
	Dciw==
Received: by 10.14.180.65 with SMTP id i41mr2191750eem.10.1348146454888;
	Thu, 20 Sep 2012 06:07:34 -0700 (PDT)
Received: from [172.16.26.11] (b0fb5b35.bb.sky.com. [176.251.91.53])
	by mx.google.com with ESMTPS id e7sm15579423eep.2.2012.09.20.06.07.33
	(version=SSLv3 cipher=OTHER); Thu, 20 Sep 2012 06:07:34 -0700 (PDT)
Message-ID: <505B1515.5020007@xen.org>
Date: Thu, 20 Sep 2012 14:07:33 +0100
From: Lars Kurth <lars.kurth@xen.org>
User-Agent: Mozilla/5.0 (Windows NT 6.1;
	rv:15.0) Gecko/20120907 Thunderbird/15.0.1
MIME-Version: 1.0
To: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: [Xen-devel] [Minutes] Xen Maintainer,
 Committer and Developer Meeting / September 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

See 
http://wiki.xen.org/wiki/Xen_Maintainer,_Committer_and_Developer_Meeting/September_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 Sep 20 13:08:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Sep 2012 13:08:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TEgU7-00071R-1E; Thu, 20 Sep 2012 13:08:03 +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 1TEgU6-00071I-74
	for xen-devel@lists.xen.org; Thu, 20 Sep 2012 13:08:02 +0000
Received: from [85.158.139.211:34705] by server-9.bemta-5.messagelabs.com id
	EA/48-20529-1351B505; Thu, 20 Sep 2012 13:08:01 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-4.tower-206.messagelabs.com!1348146479!19337017!1
X-Originating-IP: [209.85.213.173]
X-SpamReason: No, hits=0.6 required=7.0 tests=HTML_30_40,HTML_MESSAGE,
	MIME_QP_LONG_LINE,ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23710 invoked from network); 20 Sep 2012 13:08:00 -0000
Received: from mail-yx0-f173.google.com (HELO mail-yx0-f173.google.com)
	(209.85.213.173)
	by server-4.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Sep 2012 13:08:00 -0000
Received: by yenq1 with SMTP id q1so676102yen.32
	for <xen-devel@lists.xen.org>; Thu, 20 Sep 2012 06:07:59 -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;
	bh=fLmHx/lYeFbyFKh2ravBGMQFyaE1aRAGkYLILui++hE=;
	b=A9Wy3O/GFRtY5H8bgKv2fFIofjhV08xV8r0NV6FwMVGEBICO6u/nY6BLeyhx4qtspC
	taQLtbS1+VryvhbNssbZpQvVACX+gKvF45NH2tHpbh+NpnNqYhWideSpeo6Tv9VPCO/3
	JZfwDy9W7a8P2bhFTaVZwp5afbnRFzoZQcFMTXlghFV1SFgdnTBd/gndS2bekvwELljn
	EcwwzuBjOOC70JIfCzsRUeDJrhpIeMKDY7Phnblkm3u8yGm7Oh/+nJJqnTz2ASMiNmox
	G5eW9wqOA+l3npBGtRAPQOZSFMUPV1U6Q3Epg77B8U6RmllJ0u3nX5o9rnT58I7YidYM
	HXrw==
Received: by 10.236.118.16 with SMTP id k16mr1415563yhh.66.1348146478925;
	Thu, 20 Sep 2012 06:07:58 -0700 (PDT)
Received: from [10.80.114.52] (firewall.ctxuk.citrix.com. [62.200.22.2])
	by mx.google.com with ESMTPS id i3sm5854108anl.0.2012.09.20.06.07.54
	(version=SSLv3 cipher=OTHER); Thu, 20 Sep 2012 06:07:57 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Thu, 20 Sep 2012 14:07:45 +0100
From: Keir Fraser <keir.xen@gmail.com>
To: Ben Guthro <ben@guthro.net>,
	Jan Beulich <JBeulich@suse.com>
Message-ID: <CC80D3B1.3F411%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] Xen4.2 S3 regression?
Thread-Index: Ac2XMOzCQ71YTcqOI0WC0fzhr8uAKA==
In-Reply-To: <CAOvdn6VF+1KP0EkzwkoAEoc=B2bcLUWteOM8HmN-cj_YosN-pw@mail.gmail.com>
Mime-version: 1.0
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>, john.baboval@citrix.com,
	Thomas Goetz <thomas.goetz@citrix.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen4.2 S3 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: multipart/mixed; boundary="===============4236950969225128557=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--===============4236950969225128557==
Content-type: multipart/alternative;
	boundary="B_3430994876_69768592"

> This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--B_3430994876_69768592
Content-type: text/plain;
	charset="UTF-8"
Content-transfer-encoding: quoted-printable

disable_nonboot_cpus() -> cpu_down(1) -> ...

...and from there it is same as the xen-hptool case:
arch_do_sysctl() -> cpu_down_helper() -> cpu_down(1) ->
stop_machine_run(take_cpu_down, 1) -> [on CPU#1] take_cpu_down() ->
__cpu_disable()

On 20/09/2012 13:56, "Ben Guthro" <ben@guthro.net> wrote:

> It appears __cpu_disable() is not getting reached at all, for CPU1
>=20
> I put a cpu id conditional BUG() call in there, to verify - and while it =
is
> reached when using=C2=A0
> xen-hptool cpu-offline 1
> It never seems to be reached from the S3 path.
>=20
>=20
> What is the expected call chain to get into this code during S3?
>=20
>=20
> On Thu, Sep 20, 2012 at 4:03 AM, Jan Beulich <JBeulich@suse.com> wrote:
>>>>> >>> On 20.09.12 at 08:13, Keir Fraser <keir.xen@gmail.com> wrote:
>>> > CPU#1 got stuck in loop in cpu_init() as it appears to be =C5=92already
>>> > initialised=C2=B9 in cpu_initialized bitmap. CPU#0 detects it is stuck an=
d
>>> > carries on, but the resume code assumes all CPUs are brought back onl=
ine
>>> and
>>> > crashes later.
>>=20
>> So this would suggest play_dead() (-> cpu_exit_clear() ->
>> cpu_uninit()) not getting reached during the suspend cycle.
>> That should be fairly easy to verify, as the serial console
>> ought to still work when the secondary CPUs get offlined.
>>=20
>> That might imply cpumask_clear_cpu(cpu, &cpu_online_map)
>> not getting reached in __cpu_disable(), which would be in line
>> with the observation that none of the logs provided so far
>> showed anything being done by fixup_irqs() (called right
>> after clearing the online bit).
>>=20
>> Jan
>=20
>=20


--B_3430994876_69768592
Content-type: text/html;
	charset="UTF-8"
Content-transfer-encoding: quoted-printable

<HTML>
<HEAD>
<TITLE>Re: [Xen-devel] Xen4.2 S3 regression?</TITLE>
</HEAD>
<BODY>
<FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN STYLE=3D'font-size:11pt=
'>disable_nonboot_cpus() -&gt; cpu_down(1) -&gt; ...<BR>
<BR>
...and from there it is same as the xen-hptool case:<BR>
arch_do_sysctl() -&gt; cpu_down_helper() -&gt; cpu_down(1) -&gt; stop_machi=
ne_run(take_cpu_down, 1) -&gt; [on CPU#1] take_cpu_down() -&gt; __cpu_disabl=
e()<BR>
<BR>
On 20/09/2012 13:56, &quot;Ben Guthro&quot; &lt;<a href=3D"ben@guthro.net">be=
n@guthro.net</a>&gt; wrote:<BR>
<BR>
</SPAN></FONT><BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><=
SPAN STYLE=3D'font-size:11pt'>It appears __cpu_disable() is not getting reache=
d at all, for CPU1<BR>
<BR>
I put a cpu id conditional BUG() call in there, to verify - and while it is=
 reached when using=C2=A0<BR>
xen-hptool cpu-offline 1<BR>
It never seems to be reached from the S3 path.<BR>
<BR>
<BR>
What is the expected call chain to get into this code during S3?<BR>
<BR>
<BR>
On Thu, Sep 20, 2012 at 4:03 AM, Jan Beulich &lt;<a href=3D"JBeulich@suse.com=
">JBeulich@suse.com</a>&gt; wrote:<BR>
</SPAN></FONT><BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><=
SPAN STYLE=3D'font-size:11pt'>&gt;&gt;&gt; On 20.09.12 at 08:13, Keir Fraser &=
lt;<a href=3D"keir.xen@gmail.com">keir.xen@gmail.com</a>&gt; wrote:<BR>
&gt; CPU#1 got stuck in loop in cpu_init() as it appears to be &#338;alread=
y<BR>
&gt; initialised&sup1; in cpu_initialized bitmap. CPU#0 detects it is stuck=
 and<BR>
&gt; carries on, but the resume code assumes all CPUs are brought back onli=
ne and<BR>
&gt; crashes later.<BR>
<BR>
So this would suggest play_dead() (-&gt; cpu_exit_clear() -&gt;<BR>
cpu_uninit()) not getting reached during the suspend cycle.<BR>
That should be fairly easy to verify, as the serial console<BR>
ought to still work when the secondary CPUs get offlined.<BR>
<BR>
That might imply cpumask_clear_cpu(cpu, &amp;cpu_online_map)<BR>
not getting reached in __cpu_disable(), which would be in line<BR>
with the observation that none of the logs provided so far<BR>
showed anything being done by fixup_irqs() (called right<BR>
after clearing the online bit).<BR>
<FONT COLOR=3D"#888888"><BR>
Jan<BR>
</FONT></SPAN></FONT></BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, =
Arial"><SPAN STYLE=3D'font-size:11pt'><BR>
<BR>
</SPAN></FONT></BLOCKQUOTE>
</BODY>
</HTML>


--B_3430994876_69768592--




--===============4236950969225128557==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============4236950969225128557==--




From xen-devel-bounces@lists.xen.org Thu Sep 20 13:08:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Sep 2012 13:08:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TEgU7-00071R-1E; Thu, 20 Sep 2012 13:08:03 +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 1TEgU6-00071I-74
	for xen-devel@lists.xen.org; Thu, 20 Sep 2012 13:08:02 +0000
Received: from [85.158.139.211:34705] by server-9.bemta-5.messagelabs.com id
	EA/48-20529-1351B505; Thu, 20 Sep 2012 13:08:01 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-4.tower-206.messagelabs.com!1348146479!19337017!1
X-Originating-IP: [209.85.213.173]
X-SpamReason: No, hits=0.6 required=7.0 tests=HTML_30_40,HTML_MESSAGE,
	MIME_QP_LONG_LINE,ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23710 invoked from network); 20 Sep 2012 13:08:00 -0000
Received: from mail-yx0-f173.google.com (HELO mail-yx0-f173.google.com)
	(209.85.213.173)
	by server-4.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Sep 2012 13:08:00 -0000
Received: by yenq1 with SMTP id q1so676102yen.32
	for <xen-devel@lists.xen.org>; Thu, 20 Sep 2012 06:07:59 -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;
	bh=fLmHx/lYeFbyFKh2ravBGMQFyaE1aRAGkYLILui++hE=;
	b=A9Wy3O/GFRtY5H8bgKv2fFIofjhV08xV8r0NV6FwMVGEBICO6u/nY6BLeyhx4qtspC
	taQLtbS1+VryvhbNssbZpQvVACX+gKvF45NH2tHpbh+NpnNqYhWideSpeo6Tv9VPCO/3
	JZfwDy9W7a8P2bhFTaVZwp5afbnRFzoZQcFMTXlghFV1SFgdnTBd/gndS2bekvwELljn
	EcwwzuBjOOC70JIfCzsRUeDJrhpIeMKDY7Phnblkm3u8yGm7Oh/+nJJqnTz2ASMiNmox
	G5eW9wqOA+l3npBGtRAPQOZSFMUPV1U6Q3Epg77B8U6RmllJ0u3nX5o9rnT58I7YidYM
	HXrw==
Received: by 10.236.118.16 with SMTP id k16mr1415563yhh.66.1348146478925;
	Thu, 20 Sep 2012 06:07:58 -0700 (PDT)
Received: from [10.80.114.52] (firewall.ctxuk.citrix.com. [62.200.22.2])
	by mx.google.com with ESMTPS id i3sm5854108anl.0.2012.09.20.06.07.54
	(version=SSLv3 cipher=OTHER); Thu, 20 Sep 2012 06:07:57 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Thu, 20 Sep 2012 14:07:45 +0100
From: Keir Fraser <keir.xen@gmail.com>
To: Ben Guthro <ben@guthro.net>,
	Jan Beulich <JBeulich@suse.com>
Message-ID: <CC80D3B1.3F411%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] Xen4.2 S3 regression?
Thread-Index: Ac2XMOzCQ71YTcqOI0WC0fzhr8uAKA==
In-Reply-To: <CAOvdn6VF+1KP0EkzwkoAEoc=B2bcLUWteOM8HmN-cj_YosN-pw@mail.gmail.com>
Mime-version: 1.0
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>, john.baboval@citrix.com,
	Thomas Goetz <thomas.goetz@citrix.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen4.2 S3 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: multipart/mixed; boundary="===============4236950969225128557=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--===============4236950969225128557==
Content-type: multipart/alternative;
	boundary="B_3430994876_69768592"

> This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--B_3430994876_69768592
Content-type: text/plain;
	charset="UTF-8"
Content-transfer-encoding: quoted-printable

disable_nonboot_cpus() -> cpu_down(1) -> ...

...and from there it is same as the xen-hptool case:
arch_do_sysctl() -> cpu_down_helper() -> cpu_down(1) ->
stop_machine_run(take_cpu_down, 1) -> [on CPU#1] take_cpu_down() ->
__cpu_disable()

On 20/09/2012 13:56, "Ben Guthro" <ben@guthro.net> wrote:

> It appears __cpu_disable() is not getting reached at all, for CPU1
>=20
> I put a cpu id conditional BUG() call in there, to verify - and while it =
is
> reached when using=C2=A0
> xen-hptool cpu-offline 1
> It never seems to be reached from the S3 path.
>=20
>=20
> What is the expected call chain to get into this code during S3?
>=20
>=20
> On Thu, Sep 20, 2012 at 4:03 AM, Jan Beulich <JBeulich@suse.com> wrote:
>>>>> >>> On 20.09.12 at 08:13, Keir Fraser <keir.xen@gmail.com> wrote:
>>> > CPU#1 got stuck in loop in cpu_init() as it appears to be =C5=92already
>>> > initialised=C2=B9 in cpu_initialized bitmap. CPU#0 detects it is stuck an=
d
>>> > carries on, but the resume code assumes all CPUs are brought back onl=
ine
>>> and
>>> > crashes later.
>>=20
>> So this would suggest play_dead() (-> cpu_exit_clear() ->
>> cpu_uninit()) not getting reached during the suspend cycle.
>> That should be fairly easy to verify, as the serial console
>> ought to still work when the secondary CPUs get offlined.
>>=20
>> That might imply cpumask_clear_cpu(cpu, &cpu_online_map)
>> not getting reached in __cpu_disable(), which would be in line
>> with the observation that none of the logs provided so far
>> showed anything being done by fixup_irqs() (called right
>> after clearing the online bit).
>>=20
>> Jan
>=20
>=20


--B_3430994876_69768592
Content-type: text/html;
	charset="UTF-8"
Content-transfer-encoding: quoted-printable

<HTML>
<HEAD>
<TITLE>Re: [Xen-devel] Xen4.2 S3 regression?</TITLE>
</HEAD>
<BODY>
<FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN STYLE=3D'font-size:11pt=
'>disable_nonboot_cpus() -&gt; cpu_down(1) -&gt; ...<BR>
<BR>
...and from there it is same as the xen-hptool case:<BR>
arch_do_sysctl() -&gt; cpu_down_helper() -&gt; cpu_down(1) -&gt; stop_machi=
ne_run(take_cpu_down, 1) -&gt; [on CPU#1] take_cpu_down() -&gt; __cpu_disabl=
e()<BR>
<BR>
On 20/09/2012 13:56, &quot;Ben Guthro&quot; &lt;<a href=3D"ben@guthro.net">be=
n@guthro.net</a>&gt; wrote:<BR>
<BR>
</SPAN></FONT><BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><=
SPAN STYLE=3D'font-size:11pt'>It appears __cpu_disable() is not getting reache=
d at all, for CPU1<BR>
<BR>
I put a cpu id conditional BUG() call in there, to verify - and while it is=
 reached when using=C2=A0<BR>
xen-hptool cpu-offline 1<BR>
It never seems to be reached from the S3 path.<BR>
<BR>
<BR>
What is the expected call chain to get into this code during S3?<BR>
<BR>
<BR>
On Thu, Sep 20, 2012 at 4:03 AM, Jan Beulich &lt;<a href=3D"JBeulich@suse.com=
">JBeulich@suse.com</a>&gt; wrote:<BR>
</SPAN></FONT><BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><=
SPAN STYLE=3D'font-size:11pt'>&gt;&gt;&gt; On 20.09.12 at 08:13, Keir Fraser &=
lt;<a href=3D"keir.xen@gmail.com">keir.xen@gmail.com</a>&gt; wrote:<BR>
&gt; CPU#1 got stuck in loop in cpu_init() as it appears to be &#338;alread=
y<BR>
&gt; initialised&sup1; in cpu_initialized bitmap. CPU#0 detects it is stuck=
 and<BR>
&gt; carries on, but the resume code assumes all CPUs are brought back onli=
ne and<BR>
&gt; crashes later.<BR>
<BR>
So this would suggest play_dead() (-&gt; cpu_exit_clear() -&gt;<BR>
cpu_uninit()) not getting reached during the suspend cycle.<BR>
That should be fairly easy to verify, as the serial console<BR>
ought to still work when the secondary CPUs get offlined.<BR>
<BR>
That might imply cpumask_clear_cpu(cpu, &amp;cpu_online_map)<BR>
not getting reached in __cpu_disable(), which would be in line<BR>
with the observation that none of the logs provided so far<BR>
showed anything being done by fixup_irqs() (called right<BR>
after clearing the online bit).<BR>
<FONT COLOR=3D"#888888"><BR>
Jan<BR>
</FONT></SPAN></FONT></BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, =
Arial"><SPAN STYLE=3D'font-size:11pt'><BR>
<BR>
</SPAN></FONT></BLOCKQUOTE>
</BODY>
</HTML>


--B_3430994876_69768592--




--===============4236950969225128557==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============4236950969225128557==--




From xen-devel-bounces@lists.xen.org Thu Sep 20 13:14:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Sep 2012 13:14: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 1TEgZo-0007L4-7i; Thu, 20 Sep 2012 13:13:56 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <oliver.chick@citrix.com>) id 1TEgZm-0007Kz-2W
	for xen-devel@lists.xen.org; Thu, 20 Sep 2012 13:13:54 +0000
Received: from [85.158.139.211:8451] by server-7.bemta-5.messagelabs.com id
	2A/7A-19703-1961B505; Thu, 20 Sep 2012 13:13:53 +0000
X-Env-Sender: oliver.chick@citrix.com
X-Msg-Ref: server-8.tower-206.messagelabs.com!1348146831!19304337!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTA0NTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32635 invoked from network); 20 Sep 2012 13:13:52 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Sep 2012 13:13:52 -0000
X-IronPort-AV: E=Sophos;i="4.80,453,1344211200"; d="scan'208";a="14656790"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Sep 2012 13:12:52 +0000
Received: from [10.80.2.50] (10.80.2.50) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Thu, 20 Sep 2012 14:12:52 +0100
Message-ID: <1348146745.24539.42.camel@oliverchick-Precision-WorkStation-T3400>
From: Oliver Chick <oliver.chick@citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Thu, 20 Sep 2012 14:12:25 +0100
In-Reply-To: <20120919141138.GC12367@phenom.dumpdata.com>
References: <1348051887-21885-1-git-send-email-oliver.chick@citrix.com>
	<20120919141138.GC12367@phenom.dumpdata.com>
X-Mailer: Evolution 3.2.3-0ubuntu6 
MIME-Version: 1.0
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] Persistent grant maps for xen blk drivers
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Thank you for all your useful feedback, Konrad.

I have made most of the changes you suggest. I will test them and
repost. I have made a few points below.

On Wed, 2012-09-19 at 15:11 +0100, Konrad Rzeszutek Wilk wrote:
> On Wed, Sep 19, 2012 at 11:51:27AM +0100, Oliver Chick wrote:
> > This patch implements persistent grants for the xen-blk{front,back}
> > mechanism. The effect of this change is to reduce the number of unmap
> > operations performed, since they cause a (costly) TLB shootdown. This
> > allows the I/O performance to scale better when a large number of VMs
> > are performing I/O.
> >
> > Previously, the blkfront driver was supplied a bvec[] from the request
> > queue. This was granted to dom0; dom0 performed the I/O and wrote
> > directly into the grant-mapped memory and unmapped it; blkfront then
> > removed foreign access for that grant. The cost of unmapping scales
> > badly with the number of CPUs in Dom0. An experiment showed that when
> > Dom0 has 24 VCPUs, and guests are performing parallel I/O to a
> > ramdisk, the IPIs from performing unmap's is a bottleneck at 5 guests
> > (at which point 650,000 IOPS are being performed in total). If more
> > than 5 guests are used, the performance declines. By 10 guests, only
> > 400,000 IOPS are being performed.
> >
> > This patch improves performance by only unmapping when the connection
> > between blkfront and back is broken.
> >
> > On startup, blk{front,back} use xenbus to communicate their ability to
> > perform 'feature-persistent'. Iff both ends have this ability,
> > persistent mode is used.
> >
> > To perform a read, in persistent mode, blkfront uses a separate pool
> > of pages that it maps to dom0. When a request comes in, blkfront
> > transmutes the request so that blkback will write into one of these
> > free pages. Blkback keeps note of which grefs it has already
> > mapped. When a new ring request comes to blkback, it looks to see if
> > it has already mapped that page. If so, it will not map it again. If
> > the page hasn't been previously mapped, it is mapped now, and a record
> > is kept of this mapping. Blkback proceeds as usual. When blkfront is
> > notified that blkback has completed a request, it memcpy's from the
> > shared memory, into the bvec supplied. A record that the {gref, page}
> > tuple is mapped, and not inflight is kept.
> >
> > Writes are similar, except that the memcpy is peformed from the
> > supplied bvecs, into the shared pages, before the request is put onto
> > the ring.
> >
> > Blkback has to store a mapping of grefs=>{page mapped to by gref} in
> > an array. As the grefs are not known apriori, and provide no
> > guarantees on their ordering, we have to perform a linear search
> > through this array to find the page, for every gref we receive. The
> > overhead of this is low, however future work might want to use a more
> > efficient data structure to reduce this O(n) operation.
> >
> > We (ijc, and myself) have introduced a new constant,
> > BLKIF_MAX_PERS_REQUESTS_PER_DEV. This is to prevent a malicious guest
> > from attempting a DoS, by supplying fresh grefs, causing the Dom0
> > kernel from to map excessively. This is currently set to 256---the
> > maximum number of entires in the ring. As the number of inflight
> > requests <= size of ring, 256 is also the maximum sensible size. This
> > introduces a maximum overhead of 11MB of mapped memory, per block
> > device. In practice, we don't typically use about 60 of these. If the
> > guest exceeds the 256 limit, it is either buggy or malicious. We treat
> > this in one of two ways:
> > 1) If we have mapped <
> > BLKIF_MAX_SEGMENTS_PER_REQUEST * BLKIF_MAX_PERS_REQUESTS_PER_DEV
> > pages, we will persistently map the grefs. This can occur is previous
> > requests have not used all BLKIF_MAX_SEGMENTS_PER_REQUEST segments.
> > 2) Otherwise, we revert to non-persistent grants for all future grefs.
> >
> > In writing this patch, the question arrises as to if the additional
> > cost of performing memcpys in the guest (to/from the pool of granted
> > pages) outweigh the gains of not performing TLB shootdowns. The answer
> > to that question is `no'. There appears to be very little, if any
> > additional cost to the guest of using persistent grants. There is
> > perhaps a small saving, from the reduced number of hypercalls
> > performed in granting, and ending foreign access.
> >
> >
> > Signed-off-by: Oliver Chick <oliver.chick@citrix.com>
> > ---
> >  drivers/block/xen-blkback/blkback.c |  149 +++++++++++++++++++++++++---
> >  drivers/block/xen-blkback/common.h  |   16 +++
> >  drivers/block/xen-blkback/xenbus.c  |   21 +++-
> >  drivers/block/xen-blkfront.c        |  186 ++++++++++++++++++++++++++++++-----
> >  include/xen/interface/io/blkif.h    |    9 ++
> >  5 files changed, 338 insertions(+), 43 deletions(-)
> >
> > diff --git a/drivers/block/xen-blkback/blkback.c b/drivers/block/xen-blkback/blkback.c
> > index 73f196c..f95dee9 100644
> > --- a/drivers/block/xen-blkback/blkback.c
> > +++ b/drivers/block/xen-blkback/blkback.c
> > @@ -78,6 +78,7 @@ struct pending_req {
> >       unsigned short          operation;
> >       int                     status;
> >       struct list_head        free_list;
> > +     u8                      is_pers;
> 
> Just do what you did in the blkfront.c:
> 
>         unsigned int feature_persistent:1
> 
> or:
>         unsigned int flag_persistent:1
> 
> or:
>         unsigned int flag_pers_gnt:1
> 
> >  };
> >
> >  #define BLKBACK_INVALID_HANDLE (~0)
> > @@ -128,6 +129,24 @@ static int dispatch_rw_block_io(struct xen_blkif *blkif,
> >  static void make_response(struct xen_blkif *blkif, u64 id,
> >                         unsigned short op, int st);
> >
> > +static void add_pers_gnt(struct pers_gnt *pers_gnt, struct xen_blkif *blkif)
> > +{
> > +     BUG_ON(blkif->pers_gnt_c >= BLKIF_MAX_PERS_REQUESTS_PER_DEV *
> > +            BLKIF_MAX_SEGMENTS_PER_REQUEST);
> > +     blkif->pers_gnts[blkif->pers_gnt_c++] = pers_gnt;
> > +}
> > +
> > +static struct pers_gnt *get_pers_gnt(struct xen_blkif *blkif,
> > +                                  grant_ref_t gref)
> > +{
> > +     int i;
> > +
> > +     for (i = 0; i < blkif->pers_gnt_c; i++)
> > +             if (gref == blkif->pers_gnts[i]->gnt)
> > +                     return blkif->pers_gnts[i];
> > +     return NULL;
> > +}
> > +
> >  /*
> >   * Retrieve from the 'pending_reqs' a free pending_req structure to be used.
> >   */
> > @@ -274,6 +293,12 @@ int xen_blkif_schedule(void *arg)
> >  {
> >       struct xen_blkif *blkif = arg;
> >       struct xen_vbd *vbd = &blkif->vbd;
> > +     struct gnttab_unmap_grant_ref unmap[BLKIF_MAX_SEGMENTS_PER_REQUEST];
> > +     struct page *pages[BLKIF_MAX_SEGMENTS_PER_REQUEST];
> > +     struct pers_gnt *pers_gnt;
> > +     int i;
> > +     int ret = 0;
> > +     int segs_to_unmap;
> >
> >       xen_blkif_get(blkif);
> >
> > @@ -301,6 +326,29 @@ int xen_blkif_schedule(void *arg)
> >                       print_stats(blkif);
> >       }
> >
> > +     /* Free all persistent grant pages */
> > +
> > +     while (segs_to_unmap = min(BLKIF_MAX_SEGMENTS_PER_REQUEST,
> > +                              blkif->pers_gnt_c)) {
> > +
> > +             for (i = 0; i < segs_to_unmap; i++) {
> > +                     pers_gnt = blkif->pers_gnts[blkif->pers_gnt_c - i - 1];
> > +
> > +                     gnttab_set_unmap_op(&unmap[i],
> > +                                         pfn_to_kaddr(page_to_pfn(
> > +                                                          pers_gnt->page)),
> > +                                         GNTMAP_host_map,
> > +                                         pers_gnt->handle);
> > +
> > +                     pages[i] = pers_gnt->page;
> > +             }
> > +
> > +             ret = gnttab_unmap_refs(unmap, pages, segs_to_unmap, false);
> > +             BUG_ON(ret);
> > +
> > +             blkif->pers_gnt_c -= segs_to_unmap;
> > +
> > +     }
> > +
> >       if (log_stats)
> >               print_stats(blkif);
> >
> > @@ -343,13 +391,28 @@ static void xen_blkbk_unmap(struct pending_req *req)
> >
> >  static int xen_blkbk_map(struct blkif_request *req,
> >                        struct pending_req *pending_req,
> > -                      struct seg_buf seg[])
> > +                      struct seg_buf seg[],
> > +                      struct page *pages[])
> >  {
> >       struct gnttab_map_grant_ref map[BLKIF_MAX_SEGMENTS_PER_REQUEST];
> > +     struct pers_gnt *new_pers_gnts[BLKIF_MAX_SEGMENTS_PER_REQUEST];
> > +     struct pers_gnt *pers_gnts[BLKIF_MAX_SEGMENTS_PER_REQUEST];
> > +     struct page *pages_to_gnt[BLKIF_MAX_SEGMENTS_PER_REQUEST];
> > +     struct pers_gnt *pers_gnt;
> > +     phys_addr_t addr;
> >       int i;
> > +     int new_map;
> >       int nseg = req->u.rw.nr_segments;
> > +     int segs_to_init = 0;
> 
> segs_to_map is probably a better name.
> 
> >       int ret = 0;
> > +     int use_pers_gnts;
> >
> > +     use_pers_gnts = (pending_req->blkif->can_grant_persist &&
> > +                      pending_req->blkif->pers_gnt_c <
> > +                      BLKIF_MAX_SEGMENTS_PER_REQUEST *
> > +                      BLKIF_MAX_PERS_REQUESTS_PER_DEV);
> > +
> > +     pending_req->is_pers = use_pers_gnts;
> >       /*
> >        * Fill out preq.nr_sects with proper amount of sectors, and setup
> >        * assign map[..] with the PFN of the page in our domain with the
> > @@ -358,36 +421,87 @@ static int xen_blkbk_map(struct blkif_request *req,
> >       for (i = 0; i < nseg; i++) {
> >               uint32_t flags;
> >
> > +             if (use_pers_gnts) {
> > +                     pers_gnt = get_pers_gnt(pending_req->blkif,
> > +                                             req->u.rw.seg[i].gref);
> > +                     if (!pers_gnt) {
> > +                             new_map = 1;
> > +                             pers_gnt = kmalloc(sizeof(struct pers_gnt),
> > +                                                GFP_KERNEL);
> > +                             if (!pers_gnt)
> > +                                     return -ENOMEM;
> > +                             pers_gnt->page = alloc_page(GFP_KERNEL);
> > +                             if (!pers_gnt->page)
> > +                                     return -ENOMEM;
> 
> You want to kfree pers_gnt here.
> 
> > +                             pers_gnt->gnt = req->u.rw.seg[i].gref;
> > +
> > +                             pages_to_gnt[segs_to_init] = pers_gnt->page;
> > +                             new_pers_gnts[segs_to_init] = pers_gnt;
> > +
> > +                             add_pers_gnt(pers_gnt, pending_req->blkif);
> > +
> > +                     } else {
> > +                             new_map = 0;
> > +                     }
> > +                     pages[i] = pers_gnt->page;
> > +                     addr = (unsigned long) pfn_to_kaddr(
> > +                             page_to_pfn(pers_gnt->page));
> 
> Would it make sense to cache this in the 'pers_gnt' structure?

As far as I can tell, we only need this value when mapping, and
unmapping. So if we cache it, we will use it a maximum of one time. I
think it's cheap to calculate. Am I right?

> 
> > +                     pers_gnts[i] = pers_gnt;
> > +             } else {
> > +                     new_map = 1;
> > +                     pages[i] = blkbk->pending_page(pending_req, i);
> > +                     addr = vaddr(pending_req, i);
> > +                     pages_to_gnt[i] = blkbk->pending_page(pending_req, i);
> > +             }
> > +
> >               flags = GNTMAP_host_map;
> > -             if (pending_req->operation != BLKIF_OP_READ)
> > +             if (!use_pers_gnts && (pending_req->operation != BLKIF_OP_READ))
> >                       flags |= GNTMAP_readonly;
> > -             gnttab_set_map_op(&map[i], vaddr(pending_req, i), flags,
> > -                               req->u.rw.seg[i].gref,
> > -                               pending_req->blkif->domid);
> > +             if (new_map) {
> > +                     gnttab_set_map_op(&map[segs_to_init++], addr,
> > +                                       flags, req->u.rw.seg[i].gref,
> > +                                       pending_req->blkif->domid);
> > +             }
> >       }
> >
> > -     ret = gnttab_map_refs(map, NULL, &blkbk->pending_page(pending_req, 0), nseg);
> > -     BUG_ON(ret);
> > +     if (segs_to_init) {
> > +             ret = gnttab_map_refs(map, NULL, pages_to_gnt, segs_to_init);
> > +             BUG_ON(ret);
> > +     }
> >
> >       /*
> >        * Now swizzle the MFN in our domain with the MFN from the other domain
> >        * so that when we access vaddr(pending_req,i) it has the contents of
> >        * the page from the other domain.
> >        */
> > -     for (i = 0; i < nseg; i++) {
> > +     for (i = 0; i < segs_to_init; i++) {
> >               if (unlikely(map[i].status != 0)) {
> >                       pr_debug(DRV_PFX "invalid buffer -- could not remap it\n");
> >                       map[i].handle = BLKBACK_INVALID_HANDLE;
> >                       ret |= 1;
> >               }
> >
> > -             pending_handle(pending_req, i) = map[i].handle;
> > +             if (use_pers_gnts) {
> > +                     /* store the `out' values from map */
> > +                 pending_req->blkif->pers_gnts
> > +                     [pending_req->blkif->pers_gnt_c - segs_to_init +
> > +                      i]->handle = map[i].handle;
> > +                     new_pers_gnts[i]->dev_bus_addr = map[i].dev_bus_addr;
> > +             }
> >
> >               if (ret)
> >                       continue;
> > -
> > -             seg[i].buf  = map[i].dev_bus_addr |
> > -                     (req->u.rw.seg[i].first_sect << 9);
> > +     }
> > +     for (i = 0; i < nseg; i++) {
> > +             if (use_pers_gnts) {
> > +                     pending_handle(pending_req, i) = pers_gnts[i]->handle;
> > +                     seg[i].buf = pers_gnts[i]->dev_bus_addr |
> > +                             (req->u.rw.seg[i].first_sect << 9);
> > +             } else {
> > +                     pending_handle(pending_req, i) = map[i].handle;
> > +                     seg[i].buf = map[i].dev_bus_addr |
> > +                             (req->u.rw.seg[i].first_sect << 9);
> > +             }
> >       }
> >       return ret;
> >  }
> > @@ -468,7 +582,8 @@ static void __end_block_io_op(struct pending_req *pending_req, int error)
> >        * the proper response on the ring.
> >        */
> >       if (atomic_dec_and_test(&pending_req->pendcnt)) {
> > -             xen_blkbk_unmap(pending_req);
> > +             if (!pending_req->is_pers)
> > +                     xen_blkbk_unmap(pending_req);
> >               make_response(pending_req->blkif, pending_req->id,
> >                             pending_req->operation, pending_req->status);
> >               xen_blkif_put(pending_req->blkif);
> > @@ -590,6 +705,7 @@ static int dispatch_rw_block_io(struct xen_blkif *blkif,
> >       int operation;
> >       struct blk_plug plug;
> >       bool drain = false;
> > +     struct page *pages[BLKIF_MAX_SEGMENTS_PER_REQUEST];
> >
> >       switch (req->operation) {
> >       case BLKIF_OP_READ:
> > @@ -676,7 +792,7 @@ static int dispatch_rw_block_io(struct xen_blkif *blkif,
> >        * the hypercall to unmap the grants - that is all done in
> >        * xen_blkbk_unmap.
> >        */
> > -     if (xen_blkbk_map(req, pending_req, seg))
> > +     if (xen_blkbk_map(req, pending_req, seg, pages))
> >               goto fail_flush;
> >
> >       /*
> > @@ -688,7 +804,7 @@ static int dispatch_rw_block_io(struct xen_blkif *blkif,
> >       for (i = 0; i < nseg; i++) {
> >               while ((bio == NULL) ||
> >                      (bio_add_page(bio,
> > -                                  blkbk->pending_page(pending_req, i),
> 
> Can we get rid of pending_page macro?

Unfortunately not, it is still used in the non-persistent mode to
populate the pages[].

> 
> > +                                  pages[i],
> >                                    seg[i].nsec << 9,
> >                                    seg[i].buf & ~PAGE_MASK) == 0)) {
> >
> > @@ -743,7 +859,8 @@ static int dispatch_rw_block_io(struct xen_blkif *blkif,
> >       return 0;
> >
> >   fail_flush:
> > -     xen_blkbk_unmap(pending_req);
> > +     if (!blkif->can_grant_persist)
> > +             xen_blkbk_unmap(pending_req);
> >   fail_response:
> >       /* Haven't submitted any bio's yet. */
> >       make_response(blkif, req->u.rw.id, req->operation, BLKIF_RSP_ERROR);
> > diff --git a/drivers/block/xen-blkback/common.h b/drivers/block/xen-blkback/common.h
> > index 9ad3b5e..1ecb709 100644
> > --- a/drivers/block/xen-blkback/common.h
> > +++ b/drivers/block/xen-blkback/common.h
> > @@ -47,6 +47,8 @@
> >  #define DPRINTK(fmt, args...)                                \
> >       pr_debug(DRV_PFX "(%s:%d) " fmt ".\n",          \
> >                __func__, __LINE__, ##args)
> > +#define BLKIF_MAX_PERS_REQUESTS_PER_DEV 256
> 
> You need a comment explaining why this number.
> 
> > +
> >
> >
> >  /* Not a real protocol.  Used to generate ring structs which contain
> > @@ -164,6 +166,14 @@ struct xen_vbd {
> >
> >  struct backend_info;
> >
> > +
> > +struct pers_gnt {
> > +     struct page *page;
> > +     grant_ref_t gnt;
> > +     uint32_t handle;
> 
> Not grant_handle_t ?
> 
> > +     uint64_t dev_bus_addr;
> > +};
> > +
> >  struct xen_blkif {
> >       /* Unique identifier for this interface. */
> >       domid_t                 domid;
> > @@ -190,6 +200,12 @@ struct xen_blkif {
> >       struct task_struct      *xenblkd;
> >       unsigned int            waiting_reqs;
> >
> > +     /* frontend feature information */
> > +     u8                      can_grant_persist:1;
> 
> Pls move that to the vbd structure, and if you feel
> especially adventourous, you could modify the
> 
> bool flush_support
> bool discard_secure
> 
> to be 'unsigned int feature_flush:1' ,etc.. as its own
> seperate patch and then introduce the
> 
> unsigned int feature_grnt_pers:1
> 
> flag.
> > +     struct pers_gnt         *pers_gnts[BLKIF_MAX_PERS_REQUESTS_PER_DEV *
> > +                                       BLKIF_MAX_SEGMENTS_PER_REQUEST];
> > +     unsigned int            pers_gnt_c;
> > +
> >       /* statistics */
> >       unsigned long           st_print;
> >       int                     st_rd_req;
> > diff --git a/drivers/block/xen-blkback/xenbus.c b/drivers/block/xen-blkback/xenbus.c
> > index 4f66171..dc58cc4 100644
> > --- a/drivers/block/xen-blkback/xenbus.c
> > +++ b/drivers/block/xen-blkback/xenbus.c
> > @@ -681,6 +681,13 @@ again:
> >               goto abort;
> >       }
> >
> > +     err = xenbus_printf(xbt, dev->nodename, "feature-persistent-grants",
> > +                         "%d", 1);
> > +     if (err) {
> > +             xenbus_dev_fatal(dev, err, "writing persistent capability");
> 
> It is not fatal. Just do dev_warn, like the xen_blkbk_discard does.
> 
> > +             goto abort;
> > +     }
> > +
> >       /* FIXME: use a typename instead */
> >       err = xenbus_printf(xbt, dev->nodename, "info", "%u",
> >                           be->blkif->vbd.type |
> > @@ -721,6 +728,7 @@ static int connect_ring(struct backend_info *be)
> >       struct xenbus_device *dev = be->dev;
> >       unsigned long ring_ref;
> >       unsigned int evtchn;
> > +     u8 pers_grants;
> >       char protocol[64] = "";
> >       int err;
> >
> > @@ -750,8 +758,17 @@ static int connect_ring(struct backend_info *be)
> >               xenbus_dev_fatal(dev, err, "unknown fe protocol %s", protocol);
> >               return -1;
> >       }
> > -     pr_info(DRV_PFX "ring-ref %ld, event-channel %d, protocol %d (%s)\n",
> > -             ring_ref, evtchn, be->blkif->blk_protocol, protocol);
> > +     err = xenbus_gather(XBT_NIL, dev->otherend,
> > +                         "feature-persistent-grants", "%d",
> > +                         &pers_grants, NULL);
> > +     if (err)
> > +             pers_grants = 0;
> > +
> > +     be->blkif->can_grant_persist = pers_grants;
> 
> We should also have a patch for the Xen blkif.h to document this feature.. but that
> can be done later.
> 
> > +
> > +     pr_info(DRV_PFX "ring-ref %ld, event-channel %d, protocol %d (%s) persistent %d\n",
> > +             ring_ref, evtchn, be->blkif->blk_protocol, protocol,
> > +             pers_grants);
> >
> >       /* Map the shared frame, irq etc. */
> >       err = xen_blkif_map(be->blkif, ring_ref, evtchn);
> > diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c
> > index e4fb337..c1cc5fe 100644
> > --- a/drivers/block/xen-blkfront.c
> > +++ b/drivers/block/xen-blkfront.c
> > @@ -68,6 +68,13 @@ struct blk_shadow {
> >       struct blkif_request req;
> >       struct request *request;
> >       unsigned long frame[BLKIF_MAX_SEGMENTS_PER_REQUEST];
> > +     struct gnt_list *grants_used[BLKIF_MAX_SEGMENTS_PER_REQUEST];
> > +};
> > +
> > +struct gnt_list {
> > +     grant_ref_t gref;
> > +     unsigned long frame;
> 
> Pls mention what 'frame' is and what the other ones do.
> 
> > +     struct gnt_list *tail;
> >  };
> 
> How did the compiler actually compile this? You are using it in 'struct blk_shadow'
> but it is declared later?
> >
> >  static DEFINE_MUTEX(blkfront_mutex);
> > @@ -97,11 +104,14 @@ struct blkfront_info
> >       struct work_struct work;
> >       struct gnttab_free_callback callback;
> >       struct blk_shadow shadow[BLK_RING_SIZE];
> > +     struct gnt_list *persistent_grants_front;
> 
> I don't think you need the 'front' in there. Its obvious you are
> in the frontend code.
> 
> > +     unsigned int persistent_grants_c;
> >       unsigned long shadow_free;
> >       unsigned int feature_flush;
> >       unsigned int flush_op;
> >       unsigned int feature_discard:1;
> >       unsigned int feature_secdiscard:1;
> > +     unsigned int feature_persistent:1;
> >       unsigned int discard_granularity;
> >       unsigned int discard_alignment;
> >       int is_ready;
> > @@ -286,22 +296,37 @@ static int blkif_queue_request(struct request *req)
> >       struct blkif_request *ring_req;
> >       unsigned long id;
> >       unsigned int fsect, lsect;
> > -     int i, ref;
> > +     int i, ref, use_pers_gnts, new_pers_gnts;
> 
> use_pers_gnts and new_pers_gnt? Can you document what the difference
> is pls?
> 
> Perhaps 'new_pers_gnts' should be called:
> 'got_grant'? or 'using_grant' ?
> 
> >       grant_ref_t gref_head;
> > +     struct bio_vec *bvecs[BLKIF_MAX_SEGMENTS_PER_REQUEST];
> > +     struct bio_vec *bvec;
> > +     struct req_iterator iter;
> > +     char *bvec_data;
> > +     void *shared_data;
> > +     unsigned long flags;
> 
> What kind of flags?
> > +     struct page *shared_page;
> 
> It is not really shared_page. It is a temporary page. Perhaps
> tmp_page ?
> 
> > +     struct gnt_list *gnt_list_entry;
> >       struct scatterlist *sg;
> >
> >       if (unlikely(info->connected != BLKIF_STATE_CONNECTED))
> >               return 1;
> >
> > -     if (gnttab_alloc_grant_references(
> > -             BLKIF_MAX_SEGMENTS_PER_REQUEST, &gref_head) < 0) {
> > -             gnttab_request_free_callback(
> > -                     &info->callback,
> > -                     blkif_restart_queue_callback,
> > -                     info,
> > -                     BLKIF_MAX_SEGMENTS_PER_REQUEST);
> > -             return 1;
> > +     use_pers_gnts = info->feature_persistent;
> > +
> > +     if (info->persistent_grants_c < BLKIF_MAX_SEGMENTS_PER_REQUEST) {
> > +             new_pers_gnts = 1;
> > +             if (gnttab_alloc_grant_references(
> > +                         BLKIF_MAX_SEGMENTS_PER_REQUEST, &gref_head) < 0) {
> > +                     gnttab_request_free_callback(
> > +                             &info->callback,
> > +                             blkif_restart_queue_callback,
> > +                             info,
> > +                             BLKIF_MAX_SEGMENTS_PER_REQUEST);
> > +                     return 1;
> > +             }
> >       } else
> > +             new_pers_gnts = 0;
> >
> >       /* Fill out a communications ring structure. */
> >       ring_req = RING_GET_REQUEST(&info->ring, info->ring.req_prod_pvt);
> > @@ -341,20 +366,66 @@ static int blkif_queue_request(struct request *req)
> >                      BLKIF_MAX_SEGMENTS_PER_REQUEST);
> >
> >               for_each_sg(info->sg, sg, ring_req->u.rw.nr_segments, i) {
> > -                     buffer_mfn = pfn_to_mfn(page_to_pfn(sg_page(sg)));
> >                       fsect = sg->offset >> 9;
> >                       lsect = fsect + (sg->length >> 9) - 1;
> > -                     /* install a grant reference. */
> > -                     ref = gnttab_claim_grant_reference(&gref_head);
> > -                     BUG_ON(ref == -ENOSPC);
> >
> > -                     gnttab_grant_foreign_access_ref(
> > +                     if (use_pers_gnts && info->persistent_grants_c) {
> > +                             gnt_list_entry = info->persistent_grants_front;
> > +
> > +                             info->persistent_grants_front =
> > +                                     info->persistent_grants_front->tail;
> > +                             ref = gnt_list_entry->gref;
> > +                             buffer_mfn = pfn_to_mfn(gnt_list_entry->frame);
> 
> Ah, so frame is a PFN! why don't you just call it that?
> 
> > +                             info->persistent_grants_c--;
> > +                     } else {
> > +                             ref = gnttab_claim_grant_reference(&gref_head);
> > +                             BUG_ON(ref == -ENOSPC);
> > +
> > +                             if (use_pers_gnts) {
> > +                                     gnt_list_entry =
> > +                                             kmalloc(sizeof(struct gnt_list),
> > +                                                              GFP_ATOMIC);
> > +                                     if (!gnt_list_entry)
> > +                                             return -ENOMEM;
> > +
> > +                                     shared_page = alloc_page(GFP_ATOMIC);
> > +                                     if (!shared_page)
> > +                                             return -ENOMEM;
> 
> Make sure to kfree gnt_list_entry.
> 
> > +
> > +                                     gnt_list_entry->frame =
> > +                                             page_to_pfn(shared_page);
> > +                                     gnt_list_entry->gref = ref;
> > +                             } else
> > +                                     shared_page = sg_page(sg);
> > +
> > +                             buffer_mfn = pfn_to_mfn(page_to_pfn(
> > +                                                             shared_page));
> > +                             gnttab_grant_foreign_access_ref(
> >                                       ref,
> >                                       info->xbdev->otherend_id,
> >                                       buffer_mfn,
> > -                                     rq_data_dir(req));
> > +                                     !use_pers_gnts && rq_data_dir(req));
> > +                     }
> > +
> > +                     if (use_pers_gnts)
> > +                             info->shadow[id].grants_used[i] =
> > +                                     gnt_list_entry;
> > +
> > +                     if (use_pers_gnts && rq_data_dir(req)) {
> 
> You can declare the 'shared_data' here:
> 
>                                 void *shared_data;
> 
> and also bvec_data.
> 
> > +                             shared_data = kmap_atomic(
> > +                                     pfn_to_page(gnt_list_entry->frame));
> > +                             bvec_data = kmap_atomic(sg_page(sg));
> > +
> > +                             memcpy(shared_data + sg->offset,
> > +                                    bvec_data   + sg->offset,
> > +                                    sg->length);
> 
> Do we need to worry about it spilling over a page? Should we check that
> sg>offset + sg->length < PAGE_SIZE ?

I agree, this is probably a worthwhile thing to check.

> 
> Also this would imply that based on the offset (so say it is 3999) that the old data (0->3998)
> might be still there - don't know how important that is?

This is true. I spoke with IanC about this, and we *think* that this is
ok. Any old data that is there will have already been given to blkback,
so we're not really leaking data that we shouldn't be. 

> > +
> > +                             kunmap_atomic(bvec_data);
> > +                             kunmap_atomic(shared_data);
> > +                     }
> >
> >                       info->shadow[id].frame[i] = mfn_to_pfn(buffer_mfn);
> > +
> >                       ring_req->u.rw.seg[i] =
> >                                       (struct blkif_request_segment) {
> >                                               .gref       = ref,
> > @@ -368,7 +439,8 @@ static int blkif_queue_request(struct request *req)
> >       /* Keep a private copy so we can reissue requests when recovering. */
> >       info->shadow[id].req = *ring_req;
> >
> > -     gnttab_free_grant_references(gref_head);
> > +     if (new_pers_gnts)
> > +             gnttab_free_grant_references(gref_head);
> >
> >       return 0;
> >  }
> > @@ -480,12 +552,13 @@ static int xlvbd_init_blk_queue(struct gendisk *gd, u16 sector_size)
> >  static void xlvbd_flush(struct blkfront_info *info)
> >  {
> >       blk_queue_flush(info->rq, info->feature_flush);
> > -     printk(KERN_INFO "blkfront: %s: %s: %s\n",
> > +     printk(KERN_INFO "blkfront: %s: %s: %s. Persistent=%d\n",
> 
> Just use %s like the rest
> >              info->gd->disk_name,
> >              info->flush_op == BLKIF_OP_WRITE_BARRIER ?
> >               "barrier" : (info->flush_op == BLKIF_OP_FLUSH_DISKCACHE ?
> >               "flush diskcache" : "barrier or flush"),
> > -            info->feature_flush ? "enabled" : "disabled");
> > +            info->feature_flush ? "enabled" : "disabled",
> > +         info->feature_persistent);
> 
> and this can be 'info->feature_persistent ? "persitent" : "".
> 
> >  }
> >
> >  static int xen_translate_vdev(int vdevice, int *minor, unsigned int *offset)
> > @@ -707,6 +780,8 @@ static void blkif_restart_queue(struct work_struct *work)
> >
> >  static void blkif_free(struct blkfront_info *info, int suspend)
> >  {
> > +     struct gnt_list *pers_gnt;
> > +
> >       /* Prevent new requests being issued until we fix things up. */
> >       spin_lock_irq(&info->io_lock);
> >       info->connected = suspend ?
> > @@ -714,6 +789,15 @@ static void blkif_free(struct blkfront_info *info, int suspend)
> >       /* No more blkif_request(). */
> >       if (info->rq)
> >               blk_stop_queue(info->rq);
> > +
> > +     /* Remove all persistent grants */
> > +     while (info->persistent_grants_front) {
> > +             pers_gnt = info->persistent_grants_front;
> > +             info->persistent_grants_front = pers_gnt->tail;
> > +             gnttab_end_foreign_access(pers_gnt->gref, 0, 0UL);
> > +             kfree(pers_gnt);
> > +     }
> > +
> >       /* No more gnttab callback work. */
> >       gnttab_cancel_free_callback(&info->callback);
> >       spin_unlock_irq(&info->io_lock);
> > @@ -734,13 +818,44 @@ static void blkif_free(struct blkfront_info *info, int suspend)
> >
> >  }
> >
> > -static void blkif_completion(struct blk_shadow *s)
> > +static void blkif_completion(struct blk_shadow *s, struct blkfront_info *info,
> > +                          struct blkif_response *bret)
> >  {
> >       int i;
> > -     /* Do not let BLKIF_OP_DISCARD as nr_segment is in the same place
> > -      * flag. */
> > -     for (i = 0; i < s->req.u.rw.nr_segments; i++)
> > -             gnttab_end_foreign_access(s->req.u.rw.seg[i].gref, 0, 0UL);
> > +     struct gnt_list *new_gnt_list_entry;
> > +     struct bio_vec *bvec;
> > +     struct req_iterator iter;
> > +     unsigned long flags;
> > +     char *bvec_data;
> > +     void *shared_data;
> > +
> > +     i = 0;
> > +     if (info->feature_persistent == 0) {
> > +             /* Do not let BLKIF_OP_DISCARD as nr_segment is in the same
> > +              * place flag. */
> > +             for (i = 0; i < s->req.u.rw.nr_segments; i++)
> > +                     gnttab_end_foreign_access(s->req.u.rw.seg[i].gref,
> > +                                               0, 0UL);
> > +             return;
> > +     }
> > +
> 
> Move the 'i = 0' to here.
> 
> > +     if (bret->operation == BLKIF_OP_READ)
> > +             rq_for_each_segment(bvec, s->request, iter) {
> > +                     shared_data = kmap_atomic
> > +                             (pfn_to_page(s->grants_used[i++]->frame));
> > +                     bvec_data = bvec_kmap_irq(bvec, &flags);
> > +                     memcpy(bvec_data, shared_data + bvec->bv_offset,
> > +                            bvec->bv_len);
> > +                     bvec_kunmap_irq(bvec_data, &flags);
> > +                     kunmap_atomic(shared_data);
> > +             }
> > +     /* Add the persistent grant into the list of free grants */
> > +     for (i = 0; i < s->req.u.rw.nr_segments; i++) {
> > +             new_gnt_list_entry = s->grants_used[i];
> > +             new_gnt_list_entry->tail = info->persistent_grants_front;
> > +             info->persistent_grants_front = new_gnt_list_entry;
> > +             info->persistent_grants_c++;
> > +     }
> >  }
> >
> >  static irqreturn_t blkif_interrupt(int irq, void *dev_id)
> > @@ -783,7 +898,7 @@ static irqreturn_t blkif_interrupt(int irq, void *dev_id)
> >               req  = info->shadow[id].request;
> >
> >               if (bret->operation != BLKIF_OP_DISCARD)
> > -                     blkif_completion(&info->shadow[id]);
> > +                     blkif_completion(&info->shadow[id], info, bret);
> >
> >               if (add_id_to_freelist(info, id)) {
> >                       WARN(1, "%s: response to %s (id %ld) couldn't be recycled!\n",
> > @@ -943,6 +1058,12 @@ again:
> >               message = "writing protocol";
> >               goto abort_transaction;
> >       }
> > +     err = xenbus_printf(xbt, dev->nodename,
> > +                         "feature-persistent-grants", "%d", 1);
> > +     if (err) {
> > +             message = "Writing persistent grants front feature";
> > +             goto abort_transaction;
> 
> I wouldn't abort. Just continue on using the non-grant feature.
> 
> > +     }
> >
> >       err = xenbus_transaction_end(xbt, 0);
> >       if (err) {
> > @@ -1030,6 +1151,7 @@ static int blkfront_probe(struct xenbus_device *dev,
> >       spin_lock_init(&info->io_lock);
> >       info->xbdev = dev;
> >       info->vdevice = vdevice;
> > +     info->persistent_grants_c = 0;
> >       info->connected = BLKIF_STATE_DISCONNECTED;
> >       INIT_WORK(&info->work, blkif_restart_queue);
> >
> > @@ -1094,6 +1216,7 @@ static int blkif_recover(struct blkfront_info *info)
> >                                       req->u.rw.seg[j].gref,
> >                                       info->xbdev->otherend_id,
> >                                       pfn_to_mfn(info->shadow[req->u.rw.id].frame[j]),
> > +                                     !info->feature_persistent &&
> >                                       rq_data_dir(info->shadow[req->u.rw.id].request));
> >               }
> >               info->shadow[req->u.rw.id].req = *req;
> > @@ -1226,7 +1349,7 @@ static void blkfront_connect(struct blkfront_info *info)
> >       unsigned long sector_size;
> >       unsigned int binfo;
> >       int err;
> > -     int barrier, flush, discard;
> > +     int barrier, flush, discard, persistent;
> >
> >       switch (info->connected) {
> >       case BLKIF_STATE_CONNECTED:
> > @@ -1297,6 +1420,19 @@ static void blkfront_connect(struct blkfront_info *info)
> >               info->flush_op = BLKIF_OP_FLUSH_DISKCACHE;
> >       }
> >
> > +     /*
> > +      * Are we dealing with an old blkback that will unmap
> > +      * all grefs?
> > +      */
> > +     err = xenbus_gather(XBT_NIL, info->xbdev->otherend,
> > +                         "feature-persistent-grants", "%d", &persistent,
> > +                         NULL);
> > +
> > +     if (err)
> > +             info->feature_persistent = 0;
> > +     else
> > +             info->feature_persistent = persistent;
> > +
> >       err = xenbus_gather(XBT_NIL, info->xbdev->otherend,
> >                           "feature-discard", "%d", &discard,
> >                           NULL);
> > diff --git a/include/xen/interface/io/blkif.h b/include/xen/interface/io/blkif.h
> > index ee338bf..cd267a9b 100644
> > --- a/include/xen/interface/io/blkif.h
> > +++ b/include/xen/interface/io/blkif.h
> > @@ -109,6 +109,15 @@ typedef uint64_t blkif_sector_t;
> >   */
> >  #define BLKIF_MAX_SEGMENTS_PER_REQUEST 11
> >
> > +/*
> > + * Maximum number of persistent grants that can be mapped by Dom0 for each
> 
> by blkback
> > + * interface. This is set to be the size of the ring, as this is a limit on
> 
> Size of the ring? You sure?
> > + * the number of requests that can be inflight at any one time. 256 imposes
> > + * an overhead of 11MB of mapped kernel space per interface.
> > + */
> > +#define BLKIF_MAX_PERS_REQUESTS_PER_DEV 256
> > +
> > +
> >  struct blkif_request_rw {
> >       uint8_t        nr_segments;  /* number of segments                   */
> >       blkif_vdev_t   handle;       /* only for read/write requests         */
> > --
> > 1.7.9.5



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 20 13:14:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Sep 2012 13:14: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 1TEgZo-0007L4-7i; Thu, 20 Sep 2012 13:13:56 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <oliver.chick@citrix.com>) id 1TEgZm-0007Kz-2W
	for xen-devel@lists.xen.org; Thu, 20 Sep 2012 13:13:54 +0000
Received: from [85.158.139.211:8451] by server-7.bemta-5.messagelabs.com id
	2A/7A-19703-1961B505; Thu, 20 Sep 2012 13:13:53 +0000
X-Env-Sender: oliver.chick@citrix.com
X-Msg-Ref: server-8.tower-206.messagelabs.com!1348146831!19304337!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTA0NTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32635 invoked from network); 20 Sep 2012 13:13:52 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Sep 2012 13:13:52 -0000
X-IronPort-AV: E=Sophos;i="4.80,453,1344211200"; d="scan'208";a="14656790"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Sep 2012 13:12:52 +0000
Received: from [10.80.2.50] (10.80.2.50) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Thu, 20 Sep 2012 14:12:52 +0100
Message-ID: <1348146745.24539.42.camel@oliverchick-Precision-WorkStation-T3400>
From: Oliver Chick <oliver.chick@citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Thu, 20 Sep 2012 14:12:25 +0100
In-Reply-To: <20120919141138.GC12367@phenom.dumpdata.com>
References: <1348051887-21885-1-git-send-email-oliver.chick@citrix.com>
	<20120919141138.GC12367@phenom.dumpdata.com>
X-Mailer: Evolution 3.2.3-0ubuntu6 
MIME-Version: 1.0
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] Persistent grant maps for xen blk drivers
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Thank you for all your useful feedback, Konrad.

I have made most of the changes you suggest. I will test them and
repost. I have made a few points below.

On Wed, 2012-09-19 at 15:11 +0100, Konrad Rzeszutek Wilk wrote:
> On Wed, Sep 19, 2012 at 11:51:27AM +0100, Oliver Chick wrote:
> > This patch implements persistent grants for the xen-blk{front,back}
> > mechanism. The effect of this change is to reduce the number of unmap
> > operations performed, since they cause a (costly) TLB shootdown. This
> > allows the I/O performance to scale better when a large number of VMs
> > are performing I/O.
> >
> > Previously, the blkfront driver was supplied a bvec[] from the request
> > queue. This was granted to dom0; dom0 performed the I/O and wrote
> > directly into the grant-mapped memory and unmapped it; blkfront then
> > removed foreign access for that grant. The cost of unmapping scales
> > badly with the number of CPUs in Dom0. An experiment showed that when
> > Dom0 has 24 VCPUs, and guests are performing parallel I/O to a
> > ramdisk, the IPIs from performing unmap's is a bottleneck at 5 guests
> > (at which point 650,000 IOPS are being performed in total). If more
> > than 5 guests are used, the performance declines. By 10 guests, only
> > 400,000 IOPS are being performed.
> >
> > This patch improves performance by only unmapping when the connection
> > between blkfront and back is broken.
> >
> > On startup, blk{front,back} use xenbus to communicate their ability to
> > perform 'feature-persistent'. Iff both ends have this ability,
> > persistent mode is used.
> >
> > To perform a read, in persistent mode, blkfront uses a separate pool
> > of pages that it maps to dom0. When a request comes in, blkfront
> > transmutes the request so that blkback will write into one of these
> > free pages. Blkback keeps note of which grefs it has already
> > mapped. When a new ring request comes to blkback, it looks to see if
> > it has already mapped that page. If so, it will not map it again. If
> > the page hasn't been previously mapped, it is mapped now, and a record
> > is kept of this mapping. Blkback proceeds as usual. When blkfront is
> > notified that blkback has completed a request, it memcpy's from the
> > shared memory, into the bvec supplied. A record that the {gref, page}
> > tuple is mapped, and not inflight is kept.
> >
> > Writes are similar, except that the memcpy is peformed from the
> > supplied bvecs, into the shared pages, before the request is put onto
> > the ring.
> >
> > Blkback has to store a mapping of grefs=>{page mapped to by gref} in
> > an array. As the grefs are not known apriori, and provide no
> > guarantees on their ordering, we have to perform a linear search
> > through this array to find the page, for every gref we receive. The
> > overhead of this is low, however future work might want to use a more
> > efficient data structure to reduce this O(n) operation.
> >
> > We (ijc, and myself) have introduced a new constant,
> > BLKIF_MAX_PERS_REQUESTS_PER_DEV. This is to prevent a malicious guest
> > from attempting a DoS, by supplying fresh grefs, causing the Dom0
> > kernel from to map excessively. This is currently set to 256---the
> > maximum number of entires in the ring. As the number of inflight
> > requests <= size of ring, 256 is also the maximum sensible size. This
> > introduces a maximum overhead of 11MB of mapped memory, per block
> > device. In practice, we don't typically use about 60 of these. If the
> > guest exceeds the 256 limit, it is either buggy or malicious. We treat
> > this in one of two ways:
> > 1) If we have mapped <
> > BLKIF_MAX_SEGMENTS_PER_REQUEST * BLKIF_MAX_PERS_REQUESTS_PER_DEV
> > pages, we will persistently map the grefs. This can occur is previous
> > requests have not used all BLKIF_MAX_SEGMENTS_PER_REQUEST segments.
> > 2) Otherwise, we revert to non-persistent grants for all future grefs.
> >
> > In writing this patch, the question arrises as to if the additional
> > cost of performing memcpys in the guest (to/from the pool of granted
> > pages) outweigh the gains of not performing TLB shootdowns. The answer
> > to that question is `no'. There appears to be very little, if any
> > additional cost to the guest of using persistent grants. There is
> > perhaps a small saving, from the reduced number of hypercalls
> > performed in granting, and ending foreign access.
> >
> >
> > Signed-off-by: Oliver Chick <oliver.chick@citrix.com>
> > ---
> >  drivers/block/xen-blkback/blkback.c |  149 +++++++++++++++++++++++++---
> >  drivers/block/xen-blkback/common.h  |   16 +++
> >  drivers/block/xen-blkback/xenbus.c  |   21 +++-
> >  drivers/block/xen-blkfront.c        |  186 ++++++++++++++++++++++++++++++-----
> >  include/xen/interface/io/blkif.h    |    9 ++
> >  5 files changed, 338 insertions(+), 43 deletions(-)
> >
> > diff --git a/drivers/block/xen-blkback/blkback.c b/drivers/block/xen-blkback/blkback.c
> > index 73f196c..f95dee9 100644
> > --- a/drivers/block/xen-blkback/blkback.c
> > +++ b/drivers/block/xen-blkback/blkback.c
> > @@ -78,6 +78,7 @@ struct pending_req {
> >       unsigned short          operation;
> >       int                     status;
> >       struct list_head        free_list;
> > +     u8                      is_pers;
> 
> Just do what you did in the blkfront.c:
> 
>         unsigned int feature_persistent:1
> 
> or:
>         unsigned int flag_persistent:1
> 
> or:
>         unsigned int flag_pers_gnt:1
> 
> >  };
> >
> >  #define BLKBACK_INVALID_HANDLE (~0)
> > @@ -128,6 +129,24 @@ static int dispatch_rw_block_io(struct xen_blkif *blkif,
> >  static void make_response(struct xen_blkif *blkif, u64 id,
> >                         unsigned short op, int st);
> >
> > +static void add_pers_gnt(struct pers_gnt *pers_gnt, struct xen_blkif *blkif)
> > +{
> > +     BUG_ON(blkif->pers_gnt_c >= BLKIF_MAX_PERS_REQUESTS_PER_DEV *
> > +            BLKIF_MAX_SEGMENTS_PER_REQUEST);
> > +     blkif->pers_gnts[blkif->pers_gnt_c++] = pers_gnt;
> > +}
> > +
> > +static struct pers_gnt *get_pers_gnt(struct xen_blkif *blkif,
> > +                                  grant_ref_t gref)
> > +{
> > +     int i;
> > +
> > +     for (i = 0; i < blkif->pers_gnt_c; i++)
> > +             if (gref == blkif->pers_gnts[i]->gnt)
> > +                     return blkif->pers_gnts[i];
> > +     return NULL;
> > +}
> > +
> >  /*
> >   * Retrieve from the 'pending_reqs' a free pending_req structure to be used.
> >   */
> > @@ -274,6 +293,12 @@ int xen_blkif_schedule(void *arg)
> >  {
> >       struct xen_blkif *blkif = arg;
> >       struct xen_vbd *vbd = &blkif->vbd;
> > +     struct gnttab_unmap_grant_ref unmap[BLKIF_MAX_SEGMENTS_PER_REQUEST];
> > +     struct page *pages[BLKIF_MAX_SEGMENTS_PER_REQUEST];
> > +     struct pers_gnt *pers_gnt;
> > +     int i;
> > +     int ret = 0;
> > +     int segs_to_unmap;
> >
> >       xen_blkif_get(blkif);
> >
> > @@ -301,6 +326,29 @@ int xen_blkif_schedule(void *arg)
> >                       print_stats(blkif);
> >       }
> >
> > +     /* Free all persistent grant pages */
> > +
> > +     while (segs_to_unmap = min(BLKIF_MAX_SEGMENTS_PER_REQUEST,
> > +                              blkif->pers_gnt_c)) {
> > +
> > +             for (i = 0; i < segs_to_unmap; i++) {
> > +                     pers_gnt = blkif->pers_gnts[blkif->pers_gnt_c - i - 1];
> > +
> > +                     gnttab_set_unmap_op(&unmap[i],
> > +                                         pfn_to_kaddr(page_to_pfn(
> > +                                                          pers_gnt->page)),
> > +                                         GNTMAP_host_map,
> > +                                         pers_gnt->handle);
> > +
> > +                     pages[i] = pers_gnt->page;
> > +             }
> > +
> > +             ret = gnttab_unmap_refs(unmap, pages, segs_to_unmap, false);
> > +             BUG_ON(ret);
> > +
> > +             blkif->pers_gnt_c -= segs_to_unmap;
> > +
> > +     }
> > +
> >       if (log_stats)
> >               print_stats(blkif);
> >
> > @@ -343,13 +391,28 @@ static void xen_blkbk_unmap(struct pending_req *req)
> >
> >  static int xen_blkbk_map(struct blkif_request *req,
> >                        struct pending_req *pending_req,
> > -                      struct seg_buf seg[])
> > +                      struct seg_buf seg[],
> > +                      struct page *pages[])
> >  {
> >       struct gnttab_map_grant_ref map[BLKIF_MAX_SEGMENTS_PER_REQUEST];
> > +     struct pers_gnt *new_pers_gnts[BLKIF_MAX_SEGMENTS_PER_REQUEST];
> > +     struct pers_gnt *pers_gnts[BLKIF_MAX_SEGMENTS_PER_REQUEST];
> > +     struct page *pages_to_gnt[BLKIF_MAX_SEGMENTS_PER_REQUEST];
> > +     struct pers_gnt *pers_gnt;
> > +     phys_addr_t addr;
> >       int i;
> > +     int new_map;
> >       int nseg = req->u.rw.nr_segments;
> > +     int segs_to_init = 0;
> 
> segs_to_map is probably a better name.
> 
> >       int ret = 0;
> > +     int use_pers_gnts;
> >
> > +     use_pers_gnts = (pending_req->blkif->can_grant_persist &&
> > +                      pending_req->blkif->pers_gnt_c <
> > +                      BLKIF_MAX_SEGMENTS_PER_REQUEST *
> > +                      BLKIF_MAX_PERS_REQUESTS_PER_DEV);
> > +
> > +     pending_req->is_pers = use_pers_gnts;
> >       /*
> >        * Fill out preq.nr_sects with proper amount of sectors, and setup
> >        * assign map[..] with the PFN of the page in our domain with the
> > @@ -358,36 +421,87 @@ static int xen_blkbk_map(struct blkif_request *req,
> >       for (i = 0; i < nseg; i++) {
> >               uint32_t flags;
> >
> > +             if (use_pers_gnts) {
> > +                     pers_gnt = get_pers_gnt(pending_req->blkif,
> > +                                             req->u.rw.seg[i].gref);
> > +                     if (!pers_gnt) {
> > +                             new_map = 1;
> > +                             pers_gnt = kmalloc(sizeof(struct pers_gnt),
> > +                                                GFP_KERNEL);
> > +                             if (!pers_gnt)
> > +                                     return -ENOMEM;
> > +                             pers_gnt->page = alloc_page(GFP_KERNEL);
> > +                             if (!pers_gnt->page)
> > +                                     return -ENOMEM;
> 
> You want to kfree pers_gnt here.
> 
> > +                             pers_gnt->gnt = req->u.rw.seg[i].gref;
> > +
> > +                             pages_to_gnt[segs_to_init] = pers_gnt->page;
> > +                             new_pers_gnts[segs_to_init] = pers_gnt;
> > +
> > +                             add_pers_gnt(pers_gnt, pending_req->blkif);
> > +
> > +                     } else {
> > +                             new_map = 0;
> > +                     }
> > +                     pages[i] = pers_gnt->page;
> > +                     addr = (unsigned long) pfn_to_kaddr(
> > +                             page_to_pfn(pers_gnt->page));
> 
> Would it make sense to cache this in the 'pers_gnt' structure?

As far as I can tell, we only need this value when mapping, and
unmapping. So if we cache it, we will use it a maximum of one time. I
think it's cheap to calculate. Am I right?

> 
> > +                     pers_gnts[i] = pers_gnt;
> > +             } else {
> > +                     new_map = 1;
> > +                     pages[i] = blkbk->pending_page(pending_req, i);
> > +                     addr = vaddr(pending_req, i);
> > +                     pages_to_gnt[i] = blkbk->pending_page(pending_req, i);
> > +             }
> > +
> >               flags = GNTMAP_host_map;
> > -             if (pending_req->operation != BLKIF_OP_READ)
> > +             if (!use_pers_gnts && (pending_req->operation != BLKIF_OP_READ))
> >                       flags |= GNTMAP_readonly;
> > -             gnttab_set_map_op(&map[i], vaddr(pending_req, i), flags,
> > -                               req->u.rw.seg[i].gref,
> > -                               pending_req->blkif->domid);
> > +             if (new_map) {
> > +                     gnttab_set_map_op(&map[segs_to_init++], addr,
> > +                                       flags, req->u.rw.seg[i].gref,
> > +                                       pending_req->blkif->domid);
> > +             }
> >       }
> >
> > -     ret = gnttab_map_refs(map, NULL, &blkbk->pending_page(pending_req, 0), nseg);
> > -     BUG_ON(ret);
> > +     if (segs_to_init) {
> > +             ret = gnttab_map_refs(map, NULL, pages_to_gnt, segs_to_init);
> > +             BUG_ON(ret);
> > +     }
> >
> >       /*
> >        * Now swizzle the MFN in our domain with the MFN from the other domain
> >        * so that when we access vaddr(pending_req,i) it has the contents of
> >        * the page from the other domain.
> >        */
> > -     for (i = 0; i < nseg; i++) {
> > +     for (i = 0; i < segs_to_init; i++) {
> >               if (unlikely(map[i].status != 0)) {
> >                       pr_debug(DRV_PFX "invalid buffer -- could not remap it\n");
> >                       map[i].handle = BLKBACK_INVALID_HANDLE;
> >                       ret |= 1;
> >               }
> >
> > -             pending_handle(pending_req, i) = map[i].handle;
> > +             if (use_pers_gnts) {
> > +                     /* store the `out' values from map */
> > +                 pending_req->blkif->pers_gnts
> > +                     [pending_req->blkif->pers_gnt_c - segs_to_init +
> > +                      i]->handle = map[i].handle;
> > +                     new_pers_gnts[i]->dev_bus_addr = map[i].dev_bus_addr;
> > +             }
> >
> >               if (ret)
> >                       continue;
> > -
> > -             seg[i].buf  = map[i].dev_bus_addr |
> > -                     (req->u.rw.seg[i].first_sect << 9);
> > +     }
> > +     for (i = 0; i < nseg; i++) {
> > +             if (use_pers_gnts) {
> > +                     pending_handle(pending_req, i) = pers_gnts[i]->handle;
> > +                     seg[i].buf = pers_gnts[i]->dev_bus_addr |
> > +                             (req->u.rw.seg[i].first_sect << 9);
> > +             } else {
> > +                     pending_handle(pending_req, i) = map[i].handle;
> > +                     seg[i].buf = map[i].dev_bus_addr |
> > +                             (req->u.rw.seg[i].first_sect << 9);
> > +             }
> >       }
> >       return ret;
> >  }
> > @@ -468,7 +582,8 @@ static void __end_block_io_op(struct pending_req *pending_req, int error)
> >        * the proper response on the ring.
> >        */
> >       if (atomic_dec_and_test(&pending_req->pendcnt)) {
> > -             xen_blkbk_unmap(pending_req);
> > +             if (!pending_req->is_pers)
> > +                     xen_blkbk_unmap(pending_req);
> >               make_response(pending_req->blkif, pending_req->id,
> >                             pending_req->operation, pending_req->status);
> >               xen_blkif_put(pending_req->blkif);
> > @@ -590,6 +705,7 @@ static int dispatch_rw_block_io(struct xen_blkif *blkif,
> >       int operation;
> >       struct blk_plug plug;
> >       bool drain = false;
> > +     struct page *pages[BLKIF_MAX_SEGMENTS_PER_REQUEST];
> >
> >       switch (req->operation) {
> >       case BLKIF_OP_READ:
> > @@ -676,7 +792,7 @@ static int dispatch_rw_block_io(struct xen_blkif *blkif,
> >        * the hypercall to unmap the grants - that is all done in
> >        * xen_blkbk_unmap.
> >        */
> > -     if (xen_blkbk_map(req, pending_req, seg))
> > +     if (xen_blkbk_map(req, pending_req, seg, pages))
> >               goto fail_flush;
> >
> >       /*
> > @@ -688,7 +804,7 @@ static int dispatch_rw_block_io(struct xen_blkif *blkif,
> >       for (i = 0; i < nseg; i++) {
> >               while ((bio == NULL) ||
> >                      (bio_add_page(bio,
> > -                                  blkbk->pending_page(pending_req, i),
> 
> Can we get rid of pending_page macro?

Unfortunately not, it is still used in the non-persistent mode to
populate the pages[].

> 
> > +                                  pages[i],
> >                                    seg[i].nsec << 9,
> >                                    seg[i].buf & ~PAGE_MASK) == 0)) {
> >
> > @@ -743,7 +859,8 @@ static int dispatch_rw_block_io(struct xen_blkif *blkif,
> >       return 0;
> >
> >   fail_flush:
> > -     xen_blkbk_unmap(pending_req);
> > +     if (!blkif->can_grant_persist)
> > +             xen_blkbk_unmap(pending_req);
> >   fail_response:
> >       /* Haven't submitted any bio's yet. */
> >       make_response(blkif, req->u.rw.id, req->operation, BLKIF_RSP_ERROR);
> > diff --git a/drivers/block/xen-blkback/common.h b/drivers/block/xen-blkback/common.h
> > index 9ad3b5e..1ecb709 100644
> > --- a/drivers/block/xen-blkback/common.h
> > +++ b/drivers/block/xen-blkback/common.h
> > @@ -47,6 +47,8 @@
> >  #define DPRINTK(fmt, args...)                                \
> >       pr_debug(DRV_PFX "(%s:%d) " fmt ".\n",          \
> >                __func__, __LINE__, ##args)
> > +#define BLKIF_MAX_PERS_REQUESTS_PER_DEV 256
> 
> You need a comment explaining why this number.
> 
> > +
> >
> >
> >  /* Not a real protocol.  Used to generate ring structs which contain
> > @@ -164,6 +166,14 @@ struct xen_vbd {
> >
> >  struct backend_info;
> >
> > +
> > +struct pers_gnt {
> > +     struct page *page;
> > +     grant_ref_t gnt;
> > +     uint32_t handle;
> 
> Not grant_handle_t ?
> 
> > +     uint64_t dev_bus_addr;
> > +};
> > +
> >  struct xen_blkif {
> >       /* Unique identifier for this interface. */
> >       domid_t                 domid;
> > @@ -190,6 +200,12 @@ struct xen_blkif {
> >       struct task_struct      *xenblkd;
> >       unsigned int            waiting_reqs;
> >
> > +     /* frontend feature information */
> > +     u8                      can_grant_persist:1;
> 
> Pls move that to the vbd structure, and if you feel
> especially adventourous, you could modify the
> 
> bool flush_support
> bool discard_secure
> 
> to be 'unsigned int feature_flush:1' ,etc.. as its own
> seperate patch and then introduce the
> 
> unsigned int feature_grnt_pers:1
> 
> flag.
> > +     struct pers_gnt         *pers_gnts[BLKIF_MAX_PERS_REQUESTS_PER_DEV *
> > +                                       BLKIF_MAX_SEGMENTS_PER_REQUEST];
> > +     unsigned int            pers_gnt_c;
> > +
> >       /* statistics */
> >       unsigned long           st_print;
> >       int                     st_rd_req;
> > diff --git a/drivers/block/xen-blkback/xenbus.c b/drivers/block/xen-blkback/xenbus.c
> > index 4f66171..dc58cc4 100644
> > --- a/drivers/block/xen-blkback/xenbus.c
> > +++ b/drivers/block/xen-blkback/xenbus.c
> > @@ -681,6 +681,13 @@ again:
> >               goto abort;
> >       }
> >
> > +     err = xenbus_printf(xbt, dev->nodename, "feature-persistent-grants",
> > +                         "%d", 1);
> > +     if (err) {
> > +             xenbus_dev_fatal(dev, err, "writing persistent capability");
> 
> It is not fatal. Just do dev_warn, like the xen_blkbk_discard does.
> 
> > +             goto abort;
> > +     }
> > +
> >       /* FIXME: use a typename instead */
> >       err = xenbus_printf(xbt, dev->nodename, "info", "%u",
> >                           be->blkif->vbd.type |
> > @@ -721,6 +728,7 @@ static int connect_ring(struct backend_info *be)
> >       struct xenbus_device *dev = be->dev;
> >       unsigned long ring_ref;
> >       unsigned int evtchn;
> > +     u8 pers_grants;
> >       char protocol[64] = "";
> >       int err;
> >
> > @@ -750,8 +758,17 @@ static int connect_ring(struct backend_info *be)
> >               xenbus_dev_fatal(dev, err, "unknown fe protocol %s", protocol);
> >               return -1;
> >       }
> > -     pr_info(DRV_PFX "ring-ref %ld, event-channel %d, protocol %d (%s)\n",
> > -             ring_ref, evtchn, be->blkif->blk_protocol, protocol);
> > +     err = xenbus_gather(XBT_NIL, dev->otherend,
> > +                         "feature-persistent-grants", "%d",
> > +                         &pers_grants, NULL);
> > +     if (err)
> > +             pers_grants = 0;
> > +
> > +     be->blkif->can_grant_persist = pers_grants;
> 
> We should also have a patch for the Xen blkif.h to document this feature.. but that
> can be done later.
> 
> > +
> > +     pr_info(DRV_PFX "ring-ref %ld, event-channel %d, protocol %d (%s) persistent %d\n",
> > +             ring_ref, evtchn, be->blkif->blk_protocol, protocol,
> > +             pers_grants);
> >
> >       /* Map the shared frame, irq etc. */
> >       err = xen_blkif_map(be->blkif, ring_ref, evtchn);
> > diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c
> > index e4fb337..c1cc5fe 100644
> > --- a/drivers/block/xen-blkfront.c
> > +++ b/drivers/block/xen-blkfront.c
> > @@ -68,6 +68,13 @@ struct blk_shadow {
> >       struct blkif_request req;
> >       struct request *request;
> >       unsigned long frame[BLKIF_MAX_SEGMENTS_PER_REQUEST];
> > +     struct gnt_list *grants_used[BLKIF_MAX_SEGMENTS_PER_REQUEST];
> > +};
> > +
> > +struct gnt_list {
> > +     grant_ref_t gref;
> > +     unsigned long frame;
> 
> Pls mention what 'frame' is and what the other ones do.
> 
> > +     struct gnt_list *tail;
> >  };
> 
> How did the compiler actually compile this? You are using it in 'struct blk_shadow'
> but it is declared later?
> >
> >  static DEFINE_MUTEX(blkfront_mutex);
> > @@ -97,11 +104,14 @@ struct blkfront_info
> >       struct work_struct work;
> >       struct gnttab_free_callback callback;
> >       struct blk_shadow shadow[BLK_RING_SIZE];
> > +     struct gnt_list *persistent_grants_front;
> 
> I don't think you need the 'front' in there. Its obvious you are
> in the frontend code.
> 
> > +     unsigned int persistent_grants_c;
> >       unsigned long shadow_free;
> >       unsigned int feature_flush;
> >       unsigned int flush_op;
> >       unsigned int feature_discard:1;
> >       unsigned int feature_secdiscard:1;
> > +     unsigned int feature_persistent:1;
> >       unsigned int discard_granularity;
> >       unsigned int discard_alignment;
> >       int is_ready;
> > @@ -286,22 +296,37 @@ static int blkif_queue_request(struct request *req)
> >       struct blkif_request *ring_req;
> >       unsigned long id;
> >       unsigned int fsect, lsect;
> > -     int i, ref;
> > +     int i, ref, use_pers_gnts, new_pers_gnts;
> 
> use_pers_gnts and new_pers_gnt? Can you document what the difference
> is pls?
> 
> Perhaps 'new_pers_gnts' should be called:
> 'got_grant'? or 'using_grant' ?
> 
> >       grant_ref_t gref_head;
> > +     struct bio_vec *bvecs[BLKIF_MAX_SEGMENTS_PER_REQUEST];
> > +     struct bio_vec *bvec;
> > +     struct req_iterator iter;
> > +     char *bvec_data;
> > +     void *shared_data;
> > +     unsigned long flags;
> 
> What kind of flags?
> > +     struct page *shared_page;
> 
> It is not really shared_page. It is a temporary page. Perhaps
> tmp_page ?
> 
> > +     struct gnt_list *gnt_list_entry;
> >       struct scatterlist *sg;
> >
> >       if (unlikely(info->connected != BLKIF_STATE_CONNECTED))
> >               return 1;
> >
> > -     if (gnttab_alloc_grant_references(
> > -             BLKIF_MAX_SEGMENTS_PER_REQUEST, &gref_head) < 0) {
> > -             gnttab_request_free_callback(
> > -                     &info->callback,
> > -                     blkif_restart_queue_callback,
> > -                     info,
> > -                     BLKIF_MAX_SEGMENTS_PER_REQUEST);
> > -             return 1;
> > +     use_pers_gnts = info->feature_persistent;
> > +
> > +     if (info->persistent_grants_c < BLKIF_MAX_SEGMENTS_PER_REQUEST) {
> > +             new_pers_gnts = 1;
> > +             if (gnttab_alloc_grant_references(
> > +                         BLKIF_MAX_SEGMENTS_PER_REQUEST, &gref_head) < 0) {
> > +                     gnttab_request_free_callback(
> > +                             &info->callback,
> > +                             blkif_restart_queue_callback,
> > +                             info,
> > +                             BLKIF_MAX_SEGMENTS_PER_REQUEST);
> > +                     return 1;
> > +             }
> >       } else
> > +             new_pers_gnts = 0;
> >
> >       /* Fill out a communications ring structure. */
> >       ring_req = RING_GET_REQUEST(&info->ring, info->ring.req_prod_pvt);
> > @@ -341,20 +366,66 @@ static int blkif_queue_request(struct request *req)
> >                      BLKIF_MAX_SEGMENTS_PER_REQUEST);
> >
> >               for_each_sg(info->sg, sg, ring_req->u.rw.nr_segments, i) {
> > -                     buffer_mfn = pfn_to_mfn(page_to_pfn(sg_page(sg)));
> >                       fsect = sg->offset >> 9;
> >                       lsect = fsect + (sg->length >> 9) - 1;
> > -                     /* install a grant reference. */
> > -                     ref = gnttab_claim_grant_reference(&gref_head);
> > -                     BUG_ON(ref == -ENOSPC);
> >
> > -                     gnttab_grant_foreign_access_ref(
> > +                     if (use_pers_gnts && info->persistent_grants_c) {
> > +                             gnt_list_entry = info->persistent_grants_front;
> > +
> > +                             info->persistent_grants_front =
> > +                                     info->persistent_grants_front->tail;
> > +                             ref = gnt_list_entry->gref;
> > +                             buffer_mfn = pfn_to_mfn(gnt_list_entry->frame);
> 
> Ah, so frame is a PFN! why don't you just call it that?
> 
> > +                             info->persistent_grants_c--;
> > +                     } else {
> > +                             ref = gnttab_claim_grant_reference(&gref_head);
> > +                             BUG_ON(ref == -ENOSPC);
> > +
> > +                             if (use_pers_gnts) {
> > +                                     gnt_list_entry =
> > +                                             kmalloc(sizeof(struct gnt_list),
> > +                                                              GFP_ATOMIC);
> > +                                     if (!gnt_list_entry)
> > +                                             return -ENOMEM;
> > +
> > +                                     shared_page = alloc_page(GFP_ATOMIC);
> > +                                     if (!shared_page)
> > +                                             return -ENOMEM;
> 
> Make sure to kfree gnt_list_entry.
> 
> > +
> > +                                     gnt_list_entry->frame =
> > +                                             page_to_pfn(shared_page);
> > +                                     gnt_list_entry->gref = ref;
> > +                             } else
> > +                                     shared_page = sg_page(sg);
> > +
> > +                             buffer_mfn = pfn_to_mfn(page_to_pfn(
> > +                                                             shared_page));
> > +                             gnttab_grant_foreign_access_ref(
> >                                       ref,
> >                                       info->xbdev->otherend_id,
> >                                       buffer_mfn,
> > -                                     rq_data_dir(req));
> > +                                     !use_pers_gnts && rq_data_dir(req));
> > +                     }
> > +
> > +                     if (use_pers_gnts)
> > +                             info->shadow[id].grants_used[i] =
> > +                                     gnt_list_entry;
> > +
> > +                     if (use_pers_gnts && rq_data_dir(req)) {
> 
> You can declare the 'shared_data' here:
> 
>                                 void *shared_data;
> 
> and also bvec_data.
> 
> > +                             shared_data = kmap_atomic(
> > +                                     pfn_to_page(gnt_list_entry->frame));
> > +                             bvec_data = kmap_atomic(sg_page(sg));
> > +
> > +                             memcpy(shared_data + sg->offset,
> > +                                    bvec_data   + sg->offset,
> > +                                    sg->length);
> 
> Do we need to worry about it spilling over a page? Should we check that
> sg>offset + sg->length < PAGE_SIZE ?

I agree, this is probably a worthwhile thing to check.

> 
> Also this would imply that based on the offset (so say it is 3999) that the old data (0->3998)
> might be still there - don't know how important that is?

This is true. I spoke with IanC about this, and we *think* that this is
ok. Any old data that is there will have already been given to blkback,
so we're not really leaking data that we shouldn't be. 

> > +
> > +                             kunmap_atomic(bvec_data);
> > +                             kunmap_atomic(shared_data);
> > +                     }
> >
> >                       info->shadow[id].frame[i] = mfn_to_pfn(buffer_mfn);
> > +
> >                       ring_req->u.rw.seg[i] =
> >                                       (struct blkif_request_segment) {
> >                                               .gref       = ref,
> > @@ -368,7 +439,8 @@ static int blkif_queue_request(struct request *req)
> >       /* Keep a private copy so we can reissue requests when recovering. */
> >       info->shadow[id].req = *ring_req;
> >
> > -     gnttab_free_grant_references(gref_head);
> > +     if (new_pers_gnts)
> > +             gnttab_free_grant_references(gref_head);
> >
> >       return 0;
> >  }
> > @@ -480,12 +552,13 @@ static int xlvbd_init_blk_queue(struct gendisk *gd, u16 sector_size)
> >  static void xlvbd_flush(struct blkfront_info *info)
> >  {
> >       blk_queue_flush(info->rq, info->feature_flush);
> > -     printk(KERN_INFO "blkfront: %s: %s: %s\n",
> > +     printk(KERN_INFO "blkfront: %s: %s: %s. Persistent=%d\n",
> 
> Just use %s like the rest
> >              info->gd->disk_name,
> >              info->flush_op == BLKIF_OP_WRITE_BARRIER ?
> >               "barrier" : (info->flush_op == BLKIF_OP_FLUSH_DISKCACHE ?
> >               "flush diskcache" : "barrier or flush"),
> > -            info->feature_flush ? "enabled" : "disabled");
> > +            info->feature_flush ? "enabled" : "disabled",
> > +         info->feature_persistent);
> 
> and this can be 'info->feature_persistent ? "persitent" : "".
> 
> >  }
> >
> >  static int xen_translate_vdev(int vdevice, int *minor, unsigned int *offset)
> > @@ -707,6 +780,8 @@ static void blkif_restart_queue(struct work_struct *work)
> >
> >  static void blkif_free(struct blkfront_info *info, int suspend)
> >  {
> > +     struct gnt_list *pers_gnt;
> > +
> >       /* Prevent new requests being issued until we fix things up. */
> >       spin_lock_irq(&info->io_lock);
> >       info->connected = suspend ?
> > @@ -714,6 +789,15 @@ static void blkif_free(struct blkfront_info *info, int suspend)
> >       /* No more blkif_request(). */
> >       if (info->rq)
> >               blk_stop_queue(info->rq);
> > +
> > +     /* Remove all persistent grants */
> > +     while (info->persistent_grants_front) {
> > +             pers_gnt = info->persistent_grants_front;
> > +             info->persistent_grants_front = pers_gnt->tail;
> > +             gnttab_end_foreign_access(pers_gnt->gref, 0, 0UL);
> > +             kfree(pers_gnt);
> > +     }
> > +
> >       /* No more gnttab callback work. */
> >       gnttab_cancel_free_callback(&info->callback);
> >       spin_unlock_irq(&info->io_lock);
> > @@ -734,13 +818,44 @@ static void blkif_free(struct blkfront_info *info, int suspend)
> >
> >  }
> >
> > -static void blkif_completion(struct blk_shadow *s)
> > +static void blkif_completion(struct blk_shadow *s, struct blkfront_info *info,
> > +                          struct blkif_response *bret)
> >  {
> >       int i;
> > -     /* Do not let BLKIF_OP_DISCARD as nr_segment is in the same place
> > -      * flag. */
> > -     for (i = 0; i < s->req.u.rw.nr_segments; i++)
> > -             gnttab_end_foreign_access(s->req.u.rw.seg[i].gref, 0, 0UL);
> > +     struct gnt_list *new_gnt_list_entry;
> > +     struct bio_vec *bvec;
> > +     struct req_iterator iter;
> > +     unsigned long flags;
> > +     char *bvec_data;
> > +     void *shared_data;
> > +
> > +     i = 0;
> > +     if (info->feature_persistent == 0) {
> > +             /* Do not let BLKIF_OP_DISCARD as nr_segment is in the same
> > +              * place flag. */
> > +             for (i = 0; i < s->req.u.rw.nr_segments; i++)
> > +                     gnttab_end_foreign_access(s->req.u.rw.seg[i].gref,
> > +                                               0, 0UL);
> > +             return;
> > +     }
> > +
> 
> Move the 'i = 0' to here.
> 
> > +     if (bret->operation == BLKIF_OP_READ)
> > +             rq_for_each_segment(bvec, s->request, iter) {
> > +                     shared_data = kmap_atomic
> > +                             (pfn_to_page(s->grants_used[i++]->frame));
> > +                     bvec_data = bvec_kmap_irq(bvec, &flags);
> > +                     memcpy(bvec_data, shared_data + bvec->bv_offset,
> > +                            bvec->bv_len);
> > +                     bvec_kunmap_irq(bvec_data, &flags);
> > +                     kunmap_atomic(shared_data);
> > +             }
> > +     /* Add the persistent grant into the list of free grants */
> > +     for (i = 0; i < s->req.u.rw.nr_segments; i++) {
> > +             new_gnt_list_entry = s->grants_used[i];
> > +             new_gnt_list_entry->tail = info->persistent_grants_front;
> > +             info->persistent_grants_front = new_gnt_list_entry;
> > +             info->persistent_grants_c++;
> > +     }
> >  }
> >
> >  static irqreturn_t blkif_interrupt(int irq, void *dev_id)
> > @@ -783,7 +898,7 @@ static irqreturn_t blkif_interrupt(int irq, void *dev_id)
> >               req  = info->shadow[id].request;
> >
> >               if (bret->operation != BLKIF_OP_DISCARD)
> > -                     blkif_completion(&info->shadow[id]);
> > +                     blkif_completion(&info->shadow[id], info, bret);
> >
> >               if (add_id_to_freelist(info, id)) {
> >                       WARN(1, "%s: response to %s (id %ld) couldn't be recycled!\n",
> > @@ -943,6 +1058,12 @@ again:
> >               message = "writing protocol";
> >               goto abort_transaction;
> >       }
> > +     err = xenbus_printf(xbt, dev->nodename,
> > +                         "feature-persistent-grants", "%d", 1);
> > +     if (err) {
> > +             message = "Writing persistent grants front feature";
> > +             goto abort_transaction;
> 
> I wouldn't abort. Just continue on using the non-grant feature.
> 
> > +     }
> >
> >       err = xenbus_transaction_end(xbt, 0);
> >       if (err) {
> > @@ -1030,6 +1151,7 @@ static int blkfront_probe(struct xenbus_device *dev,
> >       spin_lock_init(&info->io_lock);
> >       info->xbdev = dev;
> >       info->vdevice = vdevice;
> > +     info->persistent_grants_c = 0;
> >       info->connected = BLKIF_STATE_DISCONNECTED;
> >       INIT_WORK(&info->work, blkif_restart_queue);
> >
> > @@ -1094,6 +1216,7 @@ static int blkif_recover(struct blkfront_info *info)
> >                                       req->u.rw.seg[j].gref,
> >                                       info->xbdev->otherend_id,
> >                                       pfn_to_mfn(info->shadow[req->u.rw.id].frame[j]),
> > +                                     !info->feature_persistent &&
> >                                       rq_data_dir(info->shadow[req->u.rw.id].request));
> >               }
> >               info->shadow[req->u.rw.id].req = *req;
> > @@ -1226,7 +1349,7 @@ static void blkfront_connect(struct blkfront_info *info)
> >       unsigned long sector_size;
> >       unsigned int binfo;
> >       int err;
> > -     int barrier, flush, discard;
> > +     int barrier, flush, discard, persistent;
> >
> >       switch (info->connected) {
> >       case BLKIF_STATE_CONNECTED:
> > @@ -1297,6 +1420,19 @@ static void blkfront_connect(struct blkfront_info *info)
> >               info->flush_op = BLKIF_OP_FLUSH_DISKCACHE;
> >       }
> >
> > +     /*
> > +      * Are we dealing with an old blkback that will unmap
> > +      * all grefs?
> > +      */
> > +     err = xenbus_gather(XBT_NIL, info->xbdev->otherend,
> > +                         "feature-persistent-grants", "%d", &persistent,
> > +                         NULL);
> > +
> > +     if (err)
> > +             info->feature_persistent = 0;
> > +     else
> > +             info->feature_persistent = persistent;
> > +
> >       err = xenbus_gather(XBT_NIL, info->xbdev->otherend,
> >                           "feature-discard", "%d", &discard,
> >                           NULL);
> > diff --git a/include/xen/interface/io/blkif.h b/include/xen/interface/io/blkif.h
> > index ee338bf..cd267a9b 100644
> > --- a/include/xen/interface/io/blkif.h
> > +++ b/include/xen/interface/io/blkif.h
> > @@ -109,6 +109,15 @@ typedef uint64_t blkif_sector_t;
> >   */
> >  #define BLKIF_MAX_SEGMENTS_PER_REQUEST 11
> >
> > +/*
> > + * Maximum number of persistent grants that can be mapped by Dom0 for each
> 
> by blkback
> > + * interface. This is set to be the size of the ring, as this is a limit on
> 
> Size of the ring? You sure?
> > + * the number of requests that can be inflight at any one time. 256 imposes
> > + * an overhead of 11MB of mapped kernel space per interface.
> > + */
> > +#define BLKIF_MAX_PERS_REQUESTS_PER_DEV 256
> > +
> > +
> >  struct blkif_request_rw {
> >       uint8_t        nr_segments;  /* number of segments                   */
> >       blkif_vdev_t   handle;       /* only for read/write requests         */
> > --
> > 1.7.9.5



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 20 13:17:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Sep 2012 13: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 1TEgci-0007Sb-WB; Thu, 20 Sep 2012 13: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 1TEgch-0007SU-IP
	for xen-devel@lists.xensource.com; Thu, 20 Sep 2012 13:16:55 +0000
Received: from [85.158.143.35:37857] by server-2.bemta-4.messagelabs.com id
	67/8B-06610-6471B505; Thu, 20 Sep 2012 13:16:54 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1348146990!16668669!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTA0NTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27523 invoked from network); 20 Sep 2012 13:16:32 -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;
	20 Sep 2012 13:16:32 -0000
X-IronPort-AV: E=Sophos;i="4.80,453,1344211200"; d="scan'208";a="14656927"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Sep 2012 13:16: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.279.1;
	Thu, 20 Sep 2012 14:16:29 +0100
Message-ID: <1348146987.26501.40.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Date: Thu, 20 Sep 2012 14:16:27 +0100
In-Reply-To: <alpine.DEB.2.02.1209201333460.29232@kaball.uk.xensource.com>
References: <1348076658-4511-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<1348136222.26501.19.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.02.1209201240110.29232@kaball.uk.xensource.com>
	<1348143533.26501.28.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.02.1209201333460.29232@kaball.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Pawel Moll <pawel.moll@arm.com>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH] arm: introduce a DTS for Xen unprivileged
 virtual 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 Thu, 2012-09-20 at 13:39 +0100, Stefano Stabellini wrote:
> On Thu, 20 Sep 2012, Ian Campbell wrote:
> > > Versatile Express is flexible enough to be a good base for our own
> > > virtual machine platform, especially if the maintainers keep an eye on
> > > getting everything through DT and not expecting devices just to be there
> > > ;-)
> > 
> > Perhaps what we want is a stricter subset of the stuff in mach-vexpress
> > then. But if so then this should be expressed both in the DT and in the
> > code, not just papered over by declaring things compatible when they are
> > not.
> 
> But it is already expressed in the DT, by removing all the device nodes
> we don't emulated. And it is already expressed in the code, by fully
> discovering peripherals via DT, therefore not trying to initialize
> non-present devices.

Sorry on second look most of the non-DT stuff is part of the non-DT
vexpress support code in the same file.

There are some exceptions though:

v2m_reset and v2m_power_off don't refer to DT and touch system
peripherals directly.

v2m_dt_map_io falls back to v2m_io_desc if there is no rs1 node (which I
think we don't have?) 

v2m_clk_init is called from v2m_dt_timer_init (I think you may have
fixed this one).

> 
> 
> > > > > +	gic: interrupt-controller@2c001000 {
> > > > > +		compatible = "arm,cortex-a9-gic";
> > > > 
> > > > Don't we mean "arm,cortex-a15-gic" here? That's what we actually
> > > > provide. I'm not sure how the a9 and a15 differ.
> > > 
> > > The GIC that comes with vexpress is a9 compatible.
> > 
> > The GIC which Xen emulates is the one which matters here though, and
> > that is an a15.
> 
> The a15 gic is still a9 compatible. OK to be precise I am going to add
> "arm,cortex-a15-gic", but I cannot really remove "arm,cortex-a9-gic".

I think A9 is GIC v1 and A15 is GIC v2, with the primary difference
being the alignment of the memory mapped registers, but I'm not totally
sure of that.

A bunch of places do use "arm,cortex-a15-gic", "arm,cortex-a9-gic" so
you are probably right that this is the proper answer.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 20 13:17:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Sep 2012 13: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 1TEgci-0007Sb-WB; Thu, 20 Sep 2012 13: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 1TEgch-0007SU-IP
	for xen-devel@lists.xensource.com; Thu, 20 Sep 2012 13:16:55 +0000
Received: from [85.158.143.35:37857] by server-2.bemta-4.messagelabs.com id
	67/8B-06610-6471B505; Thu, 20 Sep 2012 13:16:54 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1348146990!16668669!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTA0NTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27523 invoked from network); 20 Sep 2012 13:16:32 -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;
	20 Sep 2012 13:16:32 -0000
X-IronPort-AV: E=Sophos;i="4.80,453,1344211200"; d="scan'208";a="14656927"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Sep 2012 13:16: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.279.1;
	Thu, 20 Sep 2012 14:16:29 +0100
Message-ID: <1348146987.26501.40.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Date: Thu, 20 Sep 2012 14:16:27 +0100
In-Reply-To: <alpine.DEB.2.02.1209201333460.29232@kaball.uk.xensource.com>
References: <1348076658-4511-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<1348136222.26501.19.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.02.1209201240110.29232@kaball.uk.xensource.com>
	<1348143533.26501.28.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.02.1209201333460.29232@kaball.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Pawel Moll <pawel.moll@arm.com>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH] arm: introduce a DTS for Xen unprivileged
 virtual 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 Thu, 2012-09-20 at 13:39 +0100, Stefano Stabellini wrote:
> On Thu, 20 Sep 2012, Ian Campbell wrote:
> > > Versatile Express is flexible enough to be a good base for our own
> > > virtual machine platform, especially if the maintainers keep an eye on
> > > getting everything through DT and not expecting devices just to be there
> > > ;-)
> > 
> > Perhaps what we want is a stricter subset of the stuff in mach-vexpress
> > then. But if so then this should be expressed both in the DT and in the
> > code, not just papered over by declaring things compatible when they are
> > not.
> 
> But it is already expressed in the DT, by removing all the device nodes
> we don't emulated. And it is already expressed in the code, by fully
> discovering peripherals via DT, therefore not trying to initialize
> non-present devices.

Sorry on second look most of the non-DT stuff is part of the non-DT
vexpress support code in the same file.

There are some exceptions though:

v2m_reset and v2m_power_off don't refer to DT and touch system
peripherals directly.

v2m_dt_map_io falls back to v2m_io_desc if there is no rs1 node (which I
think we don't have?) 

v2m_clk_init is called from v2m_dt_timer_init (I think you may have
fixed this one).

> 
> 
> > > > > +	gic: interrupt-controller@2c001000 {
> > > > > +		compatible = "arm,cortex-a9-gic";
> > > > 
> > > > Don't we mean "arm,cortex-a15-gic" here? That's what we actually
> > > > provide. I'm not sure how the a9 and a15 differ.
> > > 
> > > The GIC that comes with vexpress is a9 compatible.
> > 
> > The GIC which Xen emulates is the one which matters here though, and
> > that is an a15.
> 
> The a15 gic is still a9 compatible. OK to be precise I am going to add
> "arm,cortex-a15-gic", but I cannot really remove "arm,cortex-a9-gic".

I think A9 is GIC v1 and A15 is GIC v2, with the primary difference
being the alignment of the memory mapped registers, but I'm not totally
sure of that.

A bunch of places do use "arm,cortex-a15-gic", "arm,cortex-a9-gic" so
you are probably right that this is the proper answer.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 20 13:28:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Sep 2012 13: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 1TEgnI-0007jO-7L; Thu, 20 Sep 2012 13:27:52 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <arnd@arndb.de>) id 1TEgnH-0007jJ-4S
	for xen-devel@lists.xensource.com; Thu, 20 Sep 2012 13:27:51 +0000
Received: from [85.158.143.35:61521] by server-3.bemta-4.messagelabs.com id
	03/32-10986-6D91B505; Thu, 20 Sep 2012 13:27:50 +0000
X-Env-Sender: arnd@arndb.de
X-Msg-Ref: server-8.tower-21.messagelabs.com!1348147669!15885910!1
X-Originating-IP: [212.227.126.171]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiAyMTIuMjI3LjEyNi4xNzEgPT4gNzAzNzY=\n,sa_preprocessor: 
	QmFkIElQOiAyMTIuMjI3LjEyNi4xNzEgPT4gNzAzNzY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12610 invoked from network); 20 Sep 2012 13:27:49 -0000
Received: from moutng.kundenserver.de (HELO moutng.kundenserver.de)
	(212.227.126.171) by server-8.tower-21.messagelabs.com with SMTP;
	20 Sep 2012 13:27:49 -0000
Received: from klappe2.localnet (deibp9eh1--blueice3n2.emea.ibm.com
	[195.212.29.180])
	by mrelayeu.kundenserver.de (node=mrbap1) with ESMTP (Nemesis)
	id 0MNO13-1T7mu53FKT-006uyJ; Thu, 20 Sep 2012 15:27:49 +0200
From: Arnd Bergmann <arnd@arndb.de>
To: linux-arm-kernel@lists.infradead.org
Date: Thu, 20 Sep 2012 13:27:45 +0000
User-Agent: KMail/1.12.2 (Linux/3.5.0; KDE/4.3.2; x86_64; ; )
References: <1348076658-4511-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<alpine.DEB.2.02.1209201240110.29232@kaball.uk.xensource.com>
	<1348143533.26501.28.camel@zakaz.uk.xensource.com>
In-Reply-To: <1348143533.26501.28.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Message-Id: <201209201327.45802.arnd@arndb.de>
X-Provags-ID: V02:K0:MbamWzyfXUWMJ4bda6+S6Fl6++JJwT+lvfOV1RSoIMq
	fblgtv0+qKgmgbvcArD1nwhvEElfTCXnkzOxIZunO8hxtz/X61
	hUe5TmeAQEdrkxP1HkJnHRFkO94UhGLlZCS9bKCL7aA4bCGF6q
	xBNxffC20ZQBTIJemklzXDtCReJCUD46RCHqmvk6qaiQOnv7Se
	MwcpF491XefSCKBlEGE7px9eJbnMINpFeLsKkGah/OPs/9n+9I
	3NYD7yvkzz4uUH+6eokrYcGUMMVrev8+BNUiDTD483lf3g5+IB
	oY+93PV4dM5Xgx6TAhD4kzkpnoOL3sr3Q800ynTBB0HdC1IsOQ
	ZbBxse1F0TI+qiM+Ribk=
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, Pawel Moll <pawel.moll@arm.com>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [Xen-devel] [PATCH] arm: introduce a DTS for Xen unprivileged
	virtual 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 Thursday 20 September 2012, Ian Campbell wrote:
> On Thu, 2012-09-20 at 12:56 +0100, Stefano Stabellini wrote:
> > On Thu, 20 Sep 2012, Ian Campbell wrote:
> > > On Wed, 2012-09-19 at 18:44 +0100, Stefano Stabellini wrote:

> > > > + compatible = "xen,xenvm-4.2", "arm,vexpress";
> > > 
> > > Is this second compatible thing actually true? We don't actually emulate
> > > much (anything?) of what would be on a real vexpress motherboard.
> > > 
> > > "arm,vexpress" is used only in v2m.c and I don't think we want the
> > > majority of that -- we don't provide any of the peripherals which it
> > > registers.
> > > 
> > > I think the only things we might want out of that lot are the arch timer
> > > and perhaps the uart0 (as a debug port).
> > > 
> > > I suspect we should have our own xen machine .c.
> > > 
> > > [...]
> > 
> > It is true that we are "arm,vexpress" compatible at the moment.
> 
> But we aren't, we don't emulate 90%+ of the actual hardware which
> vexpress compatibility would actually imply.
> 
> Look in arch/arm/mach-vexpress/v2m.c, which is the only thing keyed off
> this compat value -- it's full of stuff which we don't (and aren't going
> to) implement.

It's not much different in the end, but I think I'd rather make the
compatible list in the device tree "xen,xenvm-4.2", "xen,xenvm" without
listing "arm,vexpress", but then adding "xen,xenvm" to the list of
compatible devices in the vexpress kernel code.

The main difference is that if we decide to separate out the Linux
code for Xen and vexpress later into distinct ports, we have the
option to do that. vexpress will support multiplatform configurations
in 3.7 anyway, so the idea of making all virtual platforms part of
vexpress in order to be able to boot the same kernel on them is not
all that important any more.

	Arnd

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 20 13:28:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Sep 2012 13: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 1TEgnI-0007jO-7L; Thu, 20 Sep 2012 13:27:52 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <arnd@arndb.de>) id 1TEgnH-0007jJ-4S
	for xen-devel@lists.xensource.com; Thu, 20 Sep 2012 13:27:51 +0000
Received: from [85.158.143.35:61521] by server-3.bemta-4.messagelabs.com id
	03/32-10986-6D91B505; Thu, 20 Sep 2012 13:27:50 +0000
X-Env-Sender: arnd@arndb.de
X-Msg-Ref: server-8.tower-21.messagelabs.com!1348147669!15885910!1
X-Originating-IP: [212.227.126.171]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiAyMTIuMjI3LjEyNi4xNzEgPT4gNzAzNzY=\n,sa_preprocessor: 
	QmFkIElQOiAyMTIuMjI3LjEyNi4xNzEgPT4gNzAzNzY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12610 invoked from network); 20 Sep 2012 13:27:49 -0000
Received: from moutng.kundenserver.de (HELO moutng.kundenserver.de)
	(212.227.126.171) by server-8.tower-21.messagelabs.com with SMTP;
	20 Sep 2012 13:27:49 -0000
Received: from klappe2.localnet (deibp9eh1--blueice3n2.emea.ibm.com
	[195.212.29.180])
	by mrelayeu.kundenserver.de (node=mrbap1) with ESMTP (Nemesis)
	id 0MNO13-1T7mu53FKT-006uyJ; Thu, 20 Sep 2012 15:27:49 +0200
From: Arnd Bergmann <arnd@arndb.de>
To: linux-arm-kernel@lists.infradead.org
Date: Thu, 20 Sep 2012 13:27:45 +0000
User-Agent: KMail/1.12.2 (Linux/3.5.0; KDE/4.3.2; x86_64; ; )
References: <1348076658-4511-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<alpine.DEB.2.02.1209201240110.29232@kaball.uk.xensource.com>
	<1348143533.26501.28.camel@zakaz.uk.xensource.com>
In-Reply-To: <1348143533.26501.28.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Message-Id: <201209201327.45802.arnd@arndb.de>
X-Provags-ID: V02:K0:MbamWzyfXUWMJ4bda6+S6Fl6++JJwT+lvfOV1RSoIMq
	fblgtv0+qKgmgbvcArD1nwhvEElfTCXnkzOxIZunO8hxtz/X61
	hUe5TmeAQEdrkxP1HkJnHRFkO94UhGLlZCS9bKCL7aA4bCGF6q
	xBNxffC20ZQBTIJemklzXDtCReJCUD46RCHqmvk6qaiQOnv7Se
	MwcpF491XefSCKBlEGE7px9eJbnMINpFeLsKkGah/OPs/9n+9I
	3NYD7yvkzz4uUH+6eokrYcGUMMVrev8+BNUiDTD483lf3g5+IB
	oY+93PV4dM5Xgx6TAhD4kzkpnoOL3sr3Q800ynTBB0HdC1IsOQ
	ZbBxse1F0TI+qiM+Ribk=
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, Pawel Moll <pawel.moll@arm.com>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [Xen-devel] [PATCH] arm: introduce a DTS for Xen unprivileged
	virtual 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 Thursday 20 September 2012, Ian Campbell wrote:
> On Thu, 2012-09-20 at 12:56 +0100, Stefano Stabellini wrote:
> > On Thu, 20 Sep 2012, Ian Campbell wrote:
> > > On Wed, 2012-09-19 at 18:44 +0100, Stefano Stabellini wrote:

> > > > + compatible = "xen,xenvm-4.2", "arm,vexpress";
> > > 
> > > Is this second compatible thing actually true? We don't actually emulate
> > > much (anything?) of what would be on a real vexpress motherboard.
> > > 
> > > "arm,vexpress" is used only in v2m.c and I don't think we want the
> > > majority of that -- we don't provide any of the peripherals which it
> > > registers.
> > > 
> > > I think the only things we might want out of that lot are the arch timer
> > > and perhaps the uart0 (as a debug port).
> > > 
> > > I suspect we should have our own xen machine .c.
> > > 
> > > [...]
> > 
> > It is true that we are "arm,vexpress" compatible at the moment.
> 
> But we aren't, we don't emulate 90%+ of the actual hardware which
> vexpress compatibility would actually imply.
> 
> Look in arch/arm/mach-vexpress/v2m.c, which is the only thing keyed off
> this compat value -- it's full of stuff which we don't (and aren't going
> to) implement.

It's not much different in the end, but I think I'd rather make the
compatible list in the device tree "xen,xenvm-4.2", "xen,xenvm" without
listing "arm,vexpress", but then adding "xen,xenvm" to the list of
compatible devices in the vexpress kernel code.

The main difference is that if we decide to separate out the Linux
code for Xen and vexpress later into distinct ports, we have the
option to do that. vexpress will support multiplatform configurations
in 3.7 anyway, so the idea of making all virtual platforms part of
vexpress in order to be able to boot the same kernel on them is not
all that important any more.

	Arnd

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 20 13:30:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Sep 2012 13:30:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TEgp9-0007pO-Ny; Thu, 20 Sep 2012 13:29:47 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wdauchy@gmail.com>) id 1TEgp8-0007pF-AF
	for xen-devel@lists.xensource.com; Thu, 20 Sep 2012 13:29:46 +0000
Received: from [85.158.143.35:12915] by server-1.bemta-4.messagelabs.com id
	45/3C-05684-94A1B505; Thu, 20 Sep 2012 13:29:45 +0000
X-Env-Sender: wdauchy@gmail.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1348147780!7396774!1
X-Originating-IP: [209.85.160.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-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17865 invoked from network); 20 Sep 2012 13:29:42 -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;
	20 Sep 2012 13:29:42 -0000
Received: by pbbrq2 with SMTP id rq2so6593661pbb.30
	for <xen-devel@lists.xensource.com>;
	Thu, 20 Sep 2012 06:29: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:from:date:message-id:subject:to
	:cc:content-type:content-transfer-encoding;
	bh=KR3U43A+Mk/5vXXFLl9fd1HbdgR+Uwdzx7CHS3G9vzo=;
	b=tGdU+nxUR/C8H8xFUt19YSEdUJ+gv/QeUAA8U18eXAmX9lLGm/I0I/A81mTTlxg1ax
	utITq+I0emz2Z9p7Totaa3mEi+O64ipSBUYgPOQTwYLkQ9xV3x/hpo2E7WUvKMe/rLk4
	lZ+Pc27orfuPp/hoZQMEZiyUAYfZHZUNPg0kBi+gBhv4DIuaJYUPn3CdPUpQw6fVblX5
	5fiK/hlAkQrIewzblISo331ia+iW3x4dHQd73ArTFeib9S4zEBmq+wEE8cOKMWuZqbxv
	8NvvD0MpcZKzWDRdApQIkqWJJuuA/zzofcymU5HuRpwg689/9rvUodrU2PF2G9h2GEGB
	YPrw==
Received: by 10.68.228.161 with SMTP id sj1mr6810231pbc.71.1348147779816; Thu,
	20 Sep 2012 06:29:39 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.68.135.42 with HTTP; Thu, 20 Sep 2012 06:29:19 -0700 (PDT)
In-Reply-To: <20120918133650.GC12053@phenom.dumpdata.com>
References: <CAJ75kXZm-BqWdL2O41XkSE1VCdd4ruW=+CqDmR1b3=701RnXmw@mail.gmail.com>
	<20120918133650.GC12053@phenom.dumpdata.com>
From: William Dauchy <wdauchy@gmail.com>
Date: Thu, 20 Sep 2012 15:29:19 +0200
Message-ID: <CAJ75kXZEaCj4Jqs_qm46d7U-s1C2hkAONs8c5Audrw2c3X=nBA@mail.gmail.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] Error getting mfn
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Sep 18, 2012 at 3:36 PM, Konrad Rzeszutek Wilk
<konrad.wilk@oracle.com> wrote:
> Please use 'sync_console loglvl=all dom0_max_vcpus=1 console=com1 com1=xxxxx' and on the Linux command line:
> 'console=hvc0 debug loglevel=8"

Here the version with NUMA:

(XEN) Xen version 4.1.3 (package@) (gcc version 4.4.5 (Debian 4.4.5-8)
) Mon Sep 17 15:01:52 UTC 2012
(XEN) Latest ChangeSet: Thu Aug 09 16:47:30 2012 +0100 23334:ce7195d2b80e
(XEN) Console output is synchronous.
(XEN) Bootloader: COM32 Multiboot loader v0.2
(XEN) Command line: console=com2 debug sync_console dom0_max_vcpus=1
dom0_mem=1024M,max:1024M loglvl=all guest_loglvl=info
(XEN) Video information:
(XEN)  VGA is text mode 80x25, font 8x16
(XEN)  VBE/DDC methods: none; EDID transfer time: 1 seconds
(XEN)  EDID info not retrieved because no DDC retrieval method detected
(XEN) Disc information:
(XEN)  Found 0 MBR signatures
(XEN)  Found 0 EDD information structures
(XEN) Xen-e820 RAM map:
(XEN)  0000000000000000 - 000000000009b400 (usable)
(XEN)  000000000009b400 - 00000000000a0000 (reserved)
(XEN)  00000000000e0000 - 0000000000100000 (reserved)
(XEN)  0000000000100000 - 00000000bf730000 (usable)
(XEN)  00000000bf730000 - 00000000bf73e000 (ACPI data)
(XEN)  00000000bf73e000 - 00000000bf7a0000 (ACPI NVS)
(XEN)  00000000bf7a0000 - 00000000bf7b0000 (reserved)
(XEN)  00000000bf7bc000 - 00000000c0000000 (reserved)
(XEN)  00000000e0000000 - 00000000f0000000 (reserved)
(XEN)  00000000fee00000 - 00000000fee01000 (reserved)
(XEN)  00000000ffa00000 - 0000000100000000 (reserved)
(XEN)  0000000100000000 - 0000000c40000000 (usable)
(XEN) ACPI: RSDP 000FA6F0, 0024 (r2 ACPIAM)
(XEN) ACPI: XSDT BF730100, 006C (r1 122311 XSDT1136 20111223 MSFT       97)
(XEN) ACPI: FACP BF730290, 00F4 (r4 122311 FACP1136 20111223 MSFT       97)
(XEN) ACPI: DSDT BF730540, 48F7 (r2  5442B 5442B166      166 INTL 20051117)
(XEN) ACPI: FACS BF73E000, 0040
(XEN) ACPI: APIC BF730390, 011E (r2 122311 APIC1136 20111223 MSFT       97)
(XEN) ACPI: SPCR BF7304B0, 0050 (r1 122311 SPCR1136 20111223 MSFT       97)
(XEN) ACPI: MCFG BF730500, 003C (r1 122311 OEMMCFG  20111223 MSFT       97)
(XEN) ACPI: OEMB BF73E040, 0082 (r1 122311 OEMB1136 20111223 MSFT       97)
(XEN) ACPI: SRAT BF73A540, 0250 (r2 122311 OEMSRAT         1 INTL        1)
(XEN) ACPI: HPET BF73A790, 0038 (r1 122311 OEMHPET  20111223 MSFT       97)
(XEN) ACPI: DMAR BF73E0D0, 00D8 (r1    AMI  OEMDMAR        1 MSFT       97)
(XEN) ACPI: SSDT BF7439A0, 0363 (r1 DpgPmm    CpuPm       12 INTL 20051117)
(XEN) System RAM: 49142MB (50322220kB)
(XEN) SRAT: PXM 0 -> APIC 0 -> Node 0
(XEN) SRAT: PXM 0 -> APIC 2 -> Node 0
(XEN) SRAT: PXM 0 -> APIC 4 -> Node 0
(XEN) SRAT: PXM 0 -> APIC 16 -> Node 0
(XEN) SRAT: PXM 0 -> APIC 18 -> Node 0
(XEN) SRAT: PXM 0 -> APIC 20 -> Node 0
(XEN) SRAT: PXM 0 -> APIC 1 -> Node 0
(XEN) SRAT: PXM 0 -> APIC 3 -> Node 0
(XEN) SRAT: PXM 0 -> APIC 5 -> Node 0
(XEN) SRAT: PXM 0 -> APIC 17 -> Node 0
(XEN) SRAT: PXM 0 -> APIC 19 -> Node 0
(XEN) SRAT: PXM 0 -> APIC 21 -> Node 0
(XEN) SRAT: PXM 1 -> APIC 32 -> Node 1
(XEN) SRAT: PXM 1 -> APIC 34 -> Node 1
(XEN) SRAT: PXM 1 -> APIC 36 -> Node 1
(XEN) SRAT: PXM 1 -> APIC 48 -> Node 1
(XEN) SRAT: PXM 1 -> APIC 50 -> Node 1
(XEN) SRAT: PXM 1 -> APIC 52 -> Node 1
(XEN) SRAT: PXM 1 -> APIC 33 -> Node 1
(XEN) SRAT: PXM 1 -> APIC 35 -> Node 1
(XEN) SRAT: PXM 1 -> APIC 37 -> Node 1
(XEN) SRAT: PXM 1 -> APIC 49 -> Node 1
(XEN) SRAT: PXM 1 -> APIC 51 -> Node 1
(XEN) SRAT: PXM 1 -> APIC 53 -> Node 1
(XEN) SRAT: Node 0 PXM 0 0-a0000
(XEN) SRAT: Node 0 PXM 0 100000-c0000000
(XEN) SRAT: Node 0 PXM 0 100000000-640000000
(XEN) SRAT: Node 1 PXM 1 640000000-c40000000
(XEN) NUMA: Allocated memnodemap from c3f7b8000 - c3f7c5000
(XEN) NUMA: Using 8 for the hash shift.
(XEN) Domain heap initialised DMA width 32 bits
(XEN) found SMP MP-table at 000ff780
(XEN) DMI present.
(XEN) Using APIC driver default
(XEN) ACPI: PM-Timer IO Port: 0x808
(XEN) ACPI: ACPI SLEEP INFO: pm1x_cnt[804,0], pm1x_evt[800,0]
(XEN) ACPI:                  wakeup_vec[bf73e00c], vec_size[20]
(XEN) ACPI: Local APIC address 0xfee00000
(XEN) ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled)
(XEN) Processor #0 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x02] lapic_id[0x02] enabled)
(XEN) Processor #2 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x03] lapic_id[0x04] enabled)
(XEN) Processor #4 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x04] lapic_id[0x10] enabled)
(XEN) Processor #16 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x05] lapic_id[0x12] enabled)
(XEN) Processor #18 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x06] lapic_id[0x14] enabled)
(XEN) Processor #20 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x07] lapic_id[0x20] enabled)
(XEN) Processor #32 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x08] lapic_id[0x22] enabled)
(XEN) Processor #34 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x09] lapic_id[0x24] enabled)
(XEN) Processor #36 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x0a] lapic_id[0x30] enabled)
(XEN) Processor #48 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x0b] lapic_id[0x32] enabled)
(XEN) Processor #50 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x0c] lapic_id[0x34] enabled)
(XEN) Processor #52 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x0d] lapic_id[0x01] enabled)
(XEN) Processor #1 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x0e] lapic_id[0x03] enabled)
(XEN) Processor #3 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x0f] lapic_id[0x05] enabled)
(XEN) Processor #5 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x10] lapic_id[0x11] enabled)
(XEN) Processor #17 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x11] lapic_id[0x13] enabled)
(XEN) Processor #19 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x12] lapic_id[0x15] enabled)
(XEN) Processor #21 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x13] lapic_id[0x21] enabled)
(XEN) Processor #33 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x14] lapic_id[0x23] enabled)
(XEN) Processor #35 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x15] lapic_id[0x25] enabled)
(XEN) Processor #37 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x16] lapic_id[0x31] enabled)
(XEN) Processor #49 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x17] lapic_id[0x33] enabled)
(XEN) Processor #51 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x18] lapic_id[0x35] enabled)
(XEN) Processor #53 6:12 APIC version 21
(XEN) ACPI: LAPIC_NMI (acpi_id[0xff] dfl dfl lint[0x1])
(XEN) Overriding APIC driver with bigsmp
(XEN) ACPI: IOAPIC (id[0x06] address[0xfec00000] gsi_base[0])
(XEN) IOAPIC[0]: apic_id 6, version 32, address 0xfec00000, GSI 0-23
(XEN) ACPI: IOAPIC (id[0x07] address[0xfec8a000] gsi_base[24])
(XEN) IOAPIC[1]: apic_id 7, version 32, address 0xfec8a000, GSI 24-47
(XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
(XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
(XEN) ACPI: IRQ0 used by override.
(XEN) ACPI: IRQ2 used by override.
(XEN) ACPI: IRQ9 used by override.
(XEN) Enabling APIC mode:  Phys.  Using 2 I/O APICs
(XEN) ACPI: HPET id: 0x8086a301 base: 0xfed00000
(XEN) PCI: MCFG configuration 0: base e0000000 segment 0 buses 0 - 255
(XEN) PCI: MCFG area at e0000000 reserved in E820
(XEN) Table is not found!
(XEN) Using ACPI (MADT) for SMP configuration information
(XEN) IRQ limits: 48 GSI, 4576 MSI/MSI-X
(XEN) Using scheduler: SMP Credit Scheduler (credit)
(XEN) Detected 2266.812 MHz processor.
(XEN) Initing memory sharing.
(XEN) mce_intel.c:1162: MCA Capability: BCAST 1 SER 0 CMCI 1 firstbank
0 extended MCE MSR 0
(XEN) Intel machine check reporting enabled
(XEN) Intel VT-d supported page sizes: 4kB.
(XEN) Intel VT-d Snoop Control enabled.
(XEN) Intel VT-d Dom0 DMA Passthrough not enabled.
(XEN) Intel VT-d Queued Invalidation enabled.
(XEN) Intel VT-d Interrupt Remapping not enabled.
(XEN) Intel VT-d Shared EPT tables not enabled.
(XEN) I/O virtualisation enabled
(XEN)  - Dom0 mode: Relaxed
(XEN) Enabled directed EOI with ioapic_ack_old on!
(XEN) ENABLING IO-APIC IRQs
(XEN)  -> Using old ACK method
(XEN) ..TIMER: vector=0xF0 apic1=0 pin1=2 apic2=-1 pin2=-1
(XEN) Platform timer is 14.318MHz HPET
(XEN) Defaulting to alternative key handling; send 'A' to switch to normal mode.
(XEN) Allocated console ring of 256 KiB.
(XEN) VMX: Supported advanced features:
(XEN)  - APIC MMIO access virtualisation
(XEN)  - APIC TPR shadow
(XEN)  - Extended Page Tables (EPT)
(XEN)  - Virtual-Processor Identifiers (VPID)
(XEN)  - Virtual NMI
(XEN)  - MSR direct-access bitmap
(XEN)  - Unrestricted Guest
(XEN) HVM: ASIDs enabled.
(XEN) HVM: VMX enabled
(XEN) HVM: Hardware Assisted Paging (HAP) detected
(XEN) HVM: HAP page sizes: 4kB, 2MB, 1GB
(XEN) Brought up 24 CPUs
(XEN) ACPI sleep modes: S3
(XEN) mcheck_poll: Machine check polling timer started.
(XEN) *** LOADING DOMAIN 0 ***
(XEN)  Xen  kernel: 64-bit, lsb, compat32
(XEN)  Dom0 kernel: 32-bit, PAE, lsb, paddr 0x1000000 -> 0x17dc000
(XEN) PHYSICAL MEMORY ARRANGEMENT:
(XEN)  Dom0 alloc.:   0000000c20000000->0000000c22000000 (253212 pages
to be allocated)
(XEN)  Init. ramdisk: 0000000c3fd1c000->0000000c3ffff200
(XEN) VIRTUAL MEMORY ARRANGEMENT:
(XEN)  Loaded kernel: 00000000c1000000->00000000c17dc000
(XEN)  Init. ramdisk: 00000000c17dc000->00000000c1abf200
(XEN)  Phys-Mach map: 00000000c1ac0000->00000000c1bc0000
(XEN)  Start info:    00000000c1bc0000->00000000c1bc04b4
(XEN)  Page tables:   00000000c1bc1000->00000000c1bd7000
(XEN)  Boot stack:    00000000c1bd7000->00000000c1bd8000
(XEN)  TOTAL:         00000000c0000000->00000000c2000000
(XEN)  ENTRY ADDRESS: 00000000c14f5000
(XEN) Dom0 has maximum 1 VCPUs
(XEN) Scrubbing Free RAM:
..........................................................................................................................................................................................................................................................................................................................................................................................................................................................................................done.
(XEN) Xen trace buffers: disabled
(XEN) Std. Loglevel: All
(XEN) Guest Loglevel: Errors, warnings and info
(XEN) **********************************************
(XEN) ******* WARNING: CONSOLE OUTPUT IS SYNCHRONOUS
(XEN) ******* This option is intended to aid debugging of Xen by ensuring
(XEN) ******* that all output is synchronously delivered on the serial line.
(XEN) ******* However it can introduce SIGNIFICANT latencies and affect
(XEN) ******* timekeeping. It is NOT recommended for production use!
(XEN) **********************************************
(XEN) 3... 2... 1...
(XEN) *** Serial input -> DOM0 (type 'CTRL-a' three times to switch
input to Xen)
(XEN) Freed 212kB init memory.
(XEN) mm.c:908:d0 Error getting mfn 2009b (pfn 5555555555555555) from
L1 entry 000000002009b023 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn 2009c (pfn 5555555555555555) from
L1 entry 000000002009c023 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn 2009d (pfn 5555555555555555) from
L1 entry 000000002009d023 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn 2009e (pfn 5555555555555555) from
L1 entry 000000002009e023 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn 2009f (pfn 5555555555555555) from
L1 entry 000000002009f023 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32000 (pfn 5555555555555555) from
L1 entry 8000000c32000063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32001 (pfn 5555555555555555) from
L1 entry 8000000c32001063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32002 (pfn 5555555555555555) from
L1 entry 8000000c32002063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32003 (pfn 5555555555555555) from
L1 entry 8000000c32003063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32004 (pfn 5555555555555555) from
L1 entry 8000000c32004063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32005 (pfn 5555555555555555) from
L1 entry 8000000c32005063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32006 (pfn 5555555555555555) from
L1 entry 8000000c32006063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32007 (pfn 5555555555555555) from
L1 entry 8000000c32007063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32008 (pfn 5555555555555555) from
L1 entry 8000000c32008063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32009 (pfn 5555555555555555) from
L1 entry 8000000c32009063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c3200a (pfn 5555555555555555) from
L1 entry 8000000c3200a063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c3200b (pfn 5555555555555555) from
L1 entry 8000000c3200b063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c3200c (pfn 5555555555555555) from
L1 entry 8000000c3200c063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c3200d (pfn 5555555555555555) from
L1 entry 8000000c3200d063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c3200e (pfn 5555555555555555) from
L1 entry 8000000c3200e063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c3200f (pfn 5555555555555555) from
L1 entry 8000000c3200f063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32010 (pfn 5555555555555555) from
L1 entry 8000000c32010063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32011 (pfn 5555555555555555) from
L1 entry 8000000c32011063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32012 (pfn 5555555555555555) from
L1 entry 8000000c32012063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32013 (pfn 5555555555555555) from
L1 entry 8000000c32013063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32014 (pfn 5555555555555555) from
L1 entry 8000000c32014063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32015 (pfn 5555555555555555) from
L1 entry 8000000c32015063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32016 (pfn 5555555555555555) from
L1 entry 8000000c32016063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32017 (pfn 5555555555555555) from
L1 entry 8000000c32017063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32018 (pfn 5555555555555555) from
L1 entry 8000000c32018063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32019 (pfn 5555555555555555) from
L1 entry 8000000c32019063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c3201a (pfn 5555555555555555) from
L1 entry 8000000c3201a063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c3201b (pfn 5555555555555555) from
L1 entry 8000000c3201b063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c3201c (pfn 5555555555555555) from
L1 entry 8000000c3201c063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c3201d (pfn 5555555555555555) from
L1 entry 8000000c3201d063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c3201e (pfn 5555555555555555) from
L1 entry 8000000c3201e063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c3201f (pfn 5555555555555555) from
L1 entry 8000000c3201f063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32020 (pfn 5555555555555555) from
L1 entry 8000000c32020063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32021 (pfn 5555555555555555) from
L1 entry 8000000c32021063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32022 (pfn 5555555555555555) from
L1 entry 8000000c32022063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32023 (pfn 5555555555555555) from
L1 entry 8000000c32023063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32024 (pfn 5555555555555555) from
L1 entry 8000000c32024063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32025 (pfn 5555555555555555) from
L1 entry 8000000c32025063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32026 (pfn 5555555555555555) from
L1 entry 8000000c32026063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32027 (pfn 5555555555555555) from
L1 entry 8000000c32027063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32028 (pfn 5555555555555555) from
L1 entry 8000000c32028063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32029 (pfn 5555555555555555) from
L1 entry 8000000c32029063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c3202a (pfn 5555555555555555) from
L1 entry 8000000c3202a063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c3202b (pfn 5555555555555555) from
L1 entry 8000000c3202b063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c3202c (pfn 5555555555555555) from
L1 entry 8000000c3202c063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c3202d (pfn 5555555555555555) from
L1 entry 8000000c3202d063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c3202e (pfn 5555555555555555) from
L1 entry 8000000c3202e063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c3202f (pfn 5555555555555555) from
L1 entry 8000000c3202f063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32030 (pfn 5555555555555555) from
L1 entry 8000000c32030063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32031 (pfn 5555555555555555) from
L1 entry 8000000c32031063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32032 (pfn 5555555555555555) from
L1 entry 8000000c32032063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32033 (pfn 5555555555555555) from
L1 entry 8000000c32033063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32034 (pfn 5555555555555555) from
L1 entry 8000000c32034063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32035 (pfn 5555555555555555) from
L1 entry 8000000c32035063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32036 (pfn 5555555555555555) from
L1 entry 8000000c32036063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32037 (pfn 5555555555555555) from
L1 entry 8000000c32037063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32038 (pfn 5555555555555555) from
L1 entry 8000000c32038063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32039 (pfn 5555555555555555) from
L1 entry 8000000c32039063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c3203a (pfn 5555555555555555) from
L1 entry 8000000c3203a063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c3203b (pfn 5555555555555555) from
L1 entry 8000000c3203b063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c3203c (pfn 5555555555555555) from
L1 entry 8000000c3203c063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c3203d (pfn 5555555555555555) from
L1 entry 8000000c3203d063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c3203e (pfn 5555555555555555) from
L1 entry 8000000c3203e063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c3203f (pfn 5555555555555555) from
L1 entry 8000000c3203f063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32040 (pfn 5555555555555555) from
L1 entry 8000000c32040063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32041 (pfn 5555555555555555) from
L1 entry 8000000c32041063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32042 (pfn 5555555555555555) from
L1 entry 8000000c32042063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32043 (pfn 5555555555555555) from
L1 entry 8000000c32043063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32044 (pfn 5555555555555555) from
L1 entry 8000000c32044063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32045 (pfn 5555555555555555) from
L1 entry 8000000c32045063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32046 (pfn 5555555555555555) from
L1 entry 8000000c32046063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32047 (pfn 5555555555555555) from
L1 entry 8000000c32047063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32048 (pfn 5555555555555555) from
L1 entry 8000000c32048063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32049 (pfn 5555555555555555) from
L1 entry 8000000c32049063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c3204a (pfn 5555555555555555) from
L1 entry 8000000c3204a063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c3204b (pfn 5555555555555555) from
L1 entry 8000000c3204b063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c3204c (pfn 5555555555555555) from
L1 entry 8000000c3204c063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c3204d (pfn 5555555555555555) from
L1 entry 8000000c3204d063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c3204e (pfn 5555555555555555) from
L1 entry 8000000c3204e063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c3204f (pfn 5555555555555555) from
L1 entry 8000000c3204f063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32050 (pfn 5555555555555555) from
L1 entry 8000000c32050063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32051 (pfn 5555555555555555) from
L1 entry 8000000c32051063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32052 (pfn 5555555555555555) from
L1 entry 8000000c32052063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32053 (pfn 5555555555555555) from
L1 entry 8000000c32053063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32054 (pfn 5555555555555555) from
L1 entry 8000000c32054063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32055 (pfn 5555555555555555) from
L1 entry 8000000c32055063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32056 (pfn 5555555555555555) from
L1 entry 8000000c32056063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32057 (pfn 5555555555555555) from
L1 entry 8000000c32057063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32058 (pfn 5555555555555555) from
L1 entry 8000000c32058063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32059 (pfn 5555555555555555) from
L1 entry 8000000c32059063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c3205a (pfn 5555555555555555) from
L1 entry 8000000c3205a063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c3205b (pfn 5555555555555555) from
L1 entry 8000000c3205b063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c3205c (pfn 5555555555555555) from
L1 entry 8000000c3205c063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c3205d (pfn 5555555555555555) from
L1 entry 8000000c3205d063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c3205e (pfn 5555555555555555) from
L1 entry 8000000c3205e063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c3205f (pfn 5555555555555555) from
L1 entry 8000000c3205f063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32060 (pfn 5555555555555555) from
L1 entry 8000000c32060063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32061 (pfn 5555555555555555) from
L1 entry 8000000c32061063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32062 (pfn 5555555555555555) from
L1 entry 8000000c32062063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32063 (pfn 5555555555555555) from
L1 entry 8000000c32063063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32064 (pfn 5555555555555555) from
L1 entry 8000000c32064063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32065 (pfn 5555555555555555) from
L1 entry 8000000c32065063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32066 (pfn 5555555555555555) from
L1 entry 8000000c32066063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32067 (pfn 5555555555555555) from
L1 entry 8000000c32067063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32068 (pfn 5555555555555555) from
L1 entry 8000000c32068063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32069 (pfn 5555555555555555) from
L1 entry 8000000c32069063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c3206a (pfn 5555555555555555) from
L1 entry 8000000c3206a063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c3206b (pfn 5555555555555555) from
L1 entry 8000000c3206b063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c3206c (pfn 5555555555555555) from
L1 entry 8000000c3206c063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c3206d (pfn 5555555555555555) from
L1 entry 8000000c3206d063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c3206e (pfn 5555555555555555) from
L1 entry 8000000c3206e063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c3206f (pfn 5555555555555555) from
L1 entry 8000000c3206f063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32070 (pfn 5555555555555555) from
L1 entry 8000000c32070063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32071 (pfn 5555555555555555) from
L1 entry 8000000c32071063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32072 (pfn 5555555555555555) from
L1 entry 8000000c32072063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32073 (pfn 5555555555555555) from
L1 entry 8000000c32073063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32074 (pfn 5555555555555555) from
L1 entry 8000000c32074063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32075 (pfn 5555555555555555) from
L1 entry 8000000c32075063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32076 (pfn 5555555555555555) from
L1 entry 8000000c32076063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32077 (pfn 5555555555555555) from
L1 entry 8000000c32077063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32078 (pfn 5555555555555555) from
L1 entry 8000000c32078063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32079 (pfn 5555555555555555) from
L1 entry 8000000c32079063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c3207a (pfn 5555555555555555) from
L1 entry 8000000c3207a063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c3207b (pfn 5555555555555555) from
L1 entry 8000000c3207b063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c3207c (pfn 5555555555555555) from
L1 entry 8000000c3207c063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c3207d (pfn 5555555555555555) from
L1 entry 8000000c3207d063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c3207e (pfn 5555555555555555) from
L1 entry 8000000c3207e063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c3207f (pfn 5555555555555555) from
L1 entry 8000000c3207f063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32080 (pfn 5555555555555555) from
L1 entry 8000000c32080063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32081 (pfn 5555555555555555) from
L1 entry 8000000c32081063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32082 (pfn 5555555555555555) from
L1 entry 8000000c32082063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32083 (pfn 5555555555555555) from
L1 entry 8000000c32083063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32084 (pfn 5555555555555555) from
L1 entry 8000000c32084063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32085 (pfn 5555555555555555) from
L1 entry 8000000c32085063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32086 (pfn 5555555555555555) from
L1 entry 8000000c32086063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32087 (pfn 5555555555555555) from
L1 entry 8000000c32087063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32088 (pfn 5555555555555555) from
L1 entry 8000000c32088063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32089 (pfn 5555555555555555) from
L1 entry 8000000c32089063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c3208a (pfn 5555555555555555) from
L1 entry 8000000c3208a063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c3208b (pfn 5555555555555555) from
L1 entry 8000000c3208b063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c3208c (pfn 5555555555555555) from
L1 entry 8000000c3208c063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c3208d (pfn 5555555555555555) from
L1 entry 8000000c3208d063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c3208e (pfn 5555555555555555) from
L1 entry 8000000c3208e063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c3208f (pfn 5555555555555555) from
L1 entry 8000000c3208f063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32090 (pfn 5555555555555555) from
L1 entry 8000000c32090063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32091 (pfn 5555555555555555) from
L1 entry 8000000c32091063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32092 (pfn 5555555555555555) from
L1 entry 8000000c32092063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32093 (pfn 5555555555555555) from
L1 entry 8000000c32093063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32094 (pfn 5555555555555555) from
L1 entry 8000000c32094063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32095 (pfn 5555555555555555) from
L1 entry 8000000c32095063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32096 (pfn 5555555555555555) from
L1 entry 8000000c32096063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32097 (pfn 5555555555555555) from
L1 entry 8000000c32097063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32098 (pfn 5555555555555555) from
L1 entry 8000000c32098063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32099 (pfn 5555555555555555) from
L1 entry 8000000c32099063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c3209a (pfn 5555555555555555) from
L1 entry 8000000c3209a063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c3209b (pfn 5555555555555555) from
L1 entry 8000000c3209b063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c3209c (pfn 5555555555555555) from
L1 entry 8000000c3209c063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c3209d (pfn 5555555555555555) from
L1 entry 8000000c3209d063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c3209e (pfn 5555555555555555) from
L1 entry 8000000c3209e063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c3209f (pfn 5555555555555555) from
L1 entry 8000000c3209f063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320a0 (pfn 5555555555555555) from
L1 entry 8000000c320a0063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320a1 (pfn 5555555555555555) from
L1 entry 8000000c320a1063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320a2 (pfn 5555555555555555) from
L1 entry 8000000c320a2063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320a3 (pfn 5555555555555555) from
L1 entry 8000000c320a3063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320a4 (pfn 5555555555555555) from
L1 entry 8000000c320a4063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320a5 (pfn 5555555555555555) from
L1 entry 8000000c320a5063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320a6 (pfn 5555555555555555) from
L1 entry 8000000c320a6063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320a7 (pfn 5555555555555555) from
L1 entry 8000000c320a7063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320a8 (pfn 5555555555555555) from
L1 entry 8000000c320a8063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320a9 (pfn 5555555555555555) from
L1 entry 8000000c320a9063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320aa (pfn 5555555555555555) from
L1 entry 8000000c320aa063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320ab (pfn 5555555555555555) from
L1 entry 8000000c320ab063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320ac (pfn 5555555555555555) from
L1 entry 8000000c320ac063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320ad (pfn 5555555555555555) from
L1 entry 8000000c320ad063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320ae (pfn 5555555555555555) from
L1 entry 8000000c320ae063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320af (pfn 5555555555555555) from
L1 entry 8000000c320af063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320b0 (pfn 5555555555555555) from
L1 entry 8000000c320b0063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320b1 (pfn 5555555555555555) from
L1 entry 8000000c320b1063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320b2 (pfn 5555555555555555) from
L1 entry 8000000c320b2063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320b3 (pfn 5555555555555555) from
L1 entry 8000000c320b3063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320b4 (pfn 5555555555555555) from
L1 entry 8000000c320b4063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320b5 (pfn 5555555555555555) from
L1 entry 8000000c320b5063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320b6 (pfn 5555555555555555) from
L1 entry 8000000c320b6063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320b7 (pfn 5555555555555555) from
L1 entry 8000000c320b7063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320b8 (pfn 5555555555555555) from
L1 entry 8000000c320b8063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320b9 (pfn 5555555555555555) from
L1 entry 8000000c320b9063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320ba (pfn 5555555555555555) from
L1 entry 8000000c320ba063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320bb (pfn 5555555555555555) from
L1 entry 8000000c320bb063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320bc (pfn 5555555555555555) from
L1 entry 8000000c320bc063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320bd (pfn 5555555555555555) from
L1 entry 8000000c320bd063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320be (pfn 5555555555555555) from
L1 entry 8000000c320be063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320bf (pfn 5555555555555555) from
L1 entry 8000000c320bf063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320c0 (pfn 5555555555555555) from
L1 entry 8000000c320c0063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320c1 (pfn 5555555555555555) from
L1 entry 8000000c320c1063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320c2 (pfn 5555555555555555) from
L1 entry 8000000c320c2063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320c3 (pfn 5555555555555555) from
L1 entry 8000000c320c3063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320c4 (pfn 5555555555555555) from
L1 entry 8000000c320c4063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320c5 (pfn 5555555555555555) from
L1 entry 8000000c320c5063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320c6 (pfn 5555555555555555) from
L1 entry 8000000c320c6063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320c7 (pfn 5555555555555555) from
L1 entry 8000000c320c7063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320c8 (pfn 5555555555555555) from
L1 entry 8000000c320c8063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320c9 (pfn 5555555555555555) from
L1 entry 8000000c320c9063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320ca (pfn 5555555555555555) from
L1 entry 8000000c320ca063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320cb (pfn 5555555555555555) from
L1 entry 8000000c320cb063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320cc (pfn 5555555555555555) from
L1 entry 8000000c320cc063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320cd (pfn 5555555555555555) from
L1 entry 8000000c320cd063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320ce (pfn 5555555555555555) from
L1 entry 8000000c320ce063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320cf (pfn 5555555555555555) from
L1 entry 8000000c320cf063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320d0 (pfn 5555555555555555) from
L1 entry 8000000c320d0063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320d1 (pfn 5555555555555555) from
L1 entry 8000000c320d1063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320d2 (pfn 5555555555555555) from
L1 entry 8000000c320d2063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320d3 (pfn 5555555555555555) from
L1 entry 8000000c320d3063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320d4 (pfn 5555555555555555) from
L1 entry 8000000c320d4063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320d5 (pfn 5555555555555555) from
L1 entry 8000000c320d5063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320d6 (pfn 5555555555555555) from
L1 entry 8000000c320d6063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320d7 (pfn 5555555555555555) from
L1 entry 8000000c320d7063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320d8 (pfn 5555555555555555) from
L1 entry 8000000c320d8063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320d9 (pfn 5555555555555555) from
L1 entry 8000000c320d9063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320da (pfn 5555555555555555) from
L1 entry 8000000c320da063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320db (pfn 5555555555555555) from
L1 entry 8000000c320db063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320dc (pfn 5555555555555555) from
L1 entry 8000000c320dc063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320dd (pfn 5555555555555555) from
L1 entry 8000000c320dd063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320de (pfn 5555555555555555) from
L1 entry 8000000c320de063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320df (pfn 5555555555555555) from
L1 entry 8000000c320df063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320e0 (pfn 5555555555555555) from
L1 entry 8000000c320e0063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320e1 (pfn 5555555555555555) from
L1 entry 8000000c320e1063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320e2 (pfn 5555555555555555) from
L1 entry 8000000c320e2063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320e3 (pfn 5555555555555555) from
L1 entry 8000000c320e3063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320e4 (pfn 5555555555555555) from
L1 entry 8000000c320e4063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320e5 (pfn 5555555555555555) from
L1 entry 8000000c320e5063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320e6 (pfn 5555555555555555) from
L1 entry 8000000c320e6063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320e7 (pfn 5555555555555555) from
L1 entry 8000000c320e7063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320e8 (pfn 5555555555555555) from
L1 entry 8000000c320e8063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320e9 (pfn 5555555555555555) from
L1 entry 8000000c320e9063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320ea (pfn 5555555555555555) from
L1 entry 8000000c320ea063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320eb (pfn 5555555555555555) from
L1 entry 8000000c320eb063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320ec (pfn 5555555555555555) from
L1 entry 8000000c320ec063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320ed (pfn 5555555555555555) from
L1 entry 8000000c320ed063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320ee (pfn 5555555555555555) from
L1 entry 8000000c320ee063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320ef (pfn 5555555555555555) from
L1 entry 8000000c320ef063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320f0 (pfn 5555555555555555) from
L1 entry 8000000c320f0063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320f1 (pfn 5555555555555555) from
L1 entry 8000000c320f1063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320f2 (pfn 5555555555555555) from
L1 entry 8000000c320f2063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320f3 (pfn 5555555555555555) from
L1 entry 8000000c320f3063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320f4 (pfn 5555555555555555) from
L1 entry 8000000c320f4063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320f5 (pfn 5555555555555555) from
L1 entry 8000000c320f5063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320f6 (pfn 5555555555555555) from
L1 entry 8000000c320f6063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320f7 (pfn 5555555555555555) from
L1 entry 8000000c320f7063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320f8 (pfn 5555555555555555) from
L1 entry 8000000c320f8063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320f9 (pfn 5555555555555555) from
L1 entry 8000000c320f9063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320fa (pfn 5555555555555555) from
L1 entry 8000000c320fa063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320fb (pfn 5555555555555555) from
L1 entry 8000000c320fb063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320fc (pfn 5555555555555555) from
L1 entry 8000000c320fc063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320fd (pfn 5555555555555555) from
L1 entry 8000000c320fd063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320fe (pfn 5555555555555555) from
L1 entry 8000000c320fe063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320ff (pfn 5555555555555555) from
L1 entry 8000000c320ff063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32110 (pfn 5555555555555555) from
L1 entry 8000000c32110063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32111 (pfn 5555555555555555) from
L1 entry 8000000c32111063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32112 (pfn 5555555555555555) from
L1 entry 8000000c32112063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32113 (pfn 5555555555555555) from
L1 entry 8000000c32113063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32114 (pfn 5555555555555555) from
L1 entry 8000000c32114063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32115 (pfn 5555555555555555) from
L1 entry 8000000c32115063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32116 (pfn 5555555555555555) from
L1 entry 8000000c32116063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32117 (pfn 5555555555555555) from
L1 entry 8000000c32117063 for l1e_owner=0, pg_owner=0
(XEN) PCI add device 00:00.0
(XEN) PCI add device 00:01.0
(XEN) PCI add device 00:03.0
(XEN) PCI add device 00:05.0
(XEN) PCI add device 00:07.0
(XEN) PCI add device 00:13.0
(XEN) PCI add device 00:14.0
(XEN) PCI add device 00:14.1
(XEN) PCI add device 00:14.2
(XEN) PCI add device 00:14.3
(XEN) PCI add device 00:16.0
(XEN) PCI add device 00:16.1
(XEN) PCI add device 00:16.2
(XEN) PCI add device 00:16.3
(XEN) PCI add device 00:16.4
(XEN) PCI add device 00:16.5
(XEN) PCI add device 00:16.6
(XEN) PCI add device 00:16.7
(XEN) PCI add device 00:1d.0
(XEN) PCI add device 00:1d.1
(XEN) PCI add device 00:1d.2
(XEN) PCI add device 00:1d.7
(XEN) PCI add device 00:1e.0
(XEN) PCI add device 00:1f.0
(XEN) PCI add device 00:1f.2
(XEN) PCI add device 00:1f.3
(XEN) PCI add device 01:00.0
(XEN) PCI add device 01:00.1
(XEN) PCI add device 03:00.0
(XEN) PCI add device 03:00.1
(XEN) PCI add device 07:04.0
(XEN) PCI add device fe:00.0
(XEN) PCI add device fe:00.1
(XEN) PCI add device fe:02.0
(XEN) PCI add device fe:02.1
(XEN) PCI add device fe:02.2
(XEN) PCI add device fe:02.3
(XEN) PCI add device fe:02.4
(XEN) PCI add device fe:02.5
(XEN) PCI add device fe:03.0
(XEN) PCI add device fe:03.1
(XEN) PCI add device fe:03.2
(XEN) PCI add device fe:03.4
(XEN) PCI add device fe:04.0
(XEN) PCI add device fe:04.1
(XEN) PCI add device fe:04.2
(XEN) PCI add device fe:04.3
(XEN) PCI add device fe:05.0
(XEN) PCI add device fe:05.1
(XEN) PCI add device fe:05.2
(XEN) PCI add device fe:05.3
(XEN) PCI add device fe:06.0
(XEN) PCI add device fe:06.1
(XEN) PCI add device fe:06.2
(XEN) PCI add device fe:06.3
(XEN) PCI add device ff:00.0
(XEN) PCI add device ff:00.1
(XEN) PCI add device ff:02.0
(XEN) PCI add device ff:02.1
(XEN) PCI add device ff:02.2
(XEN) PCI add device ff:02.3
(XEN) PCI add device ff:02.4
(XEN) PCI add device ff:02.5
(XEN) PCI add device ff:03.0
(XEN) PCI add device ff:03.1
(XEN) PCI add device ff:03.2
(XEN) PCI add device ff:03.4
(XEN) PCI add device ff:04.0
(XEN) PCI add device ff:04.1
(XEN) PCI add device ff:04.2
(XEN) PCI add device ff:04.3
(XEN) PCI add device ff:05.0
(XEN) PCI add device ff:05.1
(XEN) PCI add device ff:05.2
(XEN) PCI add device ff:05.3
(XEN) PCI add device ff:06.0
(XEN) PCI add device ff:06.1
(XEN) PCI add device ff:06.2
(XEN) PCI add device ff:06.3
(XEN) ../physdev.c:171: dom0: wrong map_pirq type 3



-- 
William

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 20 13:30:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Sep 2012 13:30:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TEgp9-0007pO-Ny; Thu, 20 Sep 2012 13:29:47 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wdauchy@gmail.com>) id 1TEgp8-0007pF-AF
	for xen-devel@lists.xensource.com; Thu, 20 Sep 2012 13:29:46 +0000
Received: from [85.158.143.35:12915] by server-1.bemta-4.messagelabs.com id
	45/3C-05684-94A1B505; Thu, 20 Sep 2012 13:29:45 +0000
X-Env-Sender: wdauchy@gmail.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1348147780!7396774!1
X-Originating-IP: [209.85.160.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-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17865 invoked from network); 20 Sep 2012 13:29:42 -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;
	20 Sep 2012 13:29:42 -0000
Received: by pbbrq2 with SMTP id rq2so6593661pbb.30
	for <xen-devel@lists.xensource.com>;
	Thu, 20 Sep 2012 06:29: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:from:date:message-id:subject:to
	:cc:content-type:content-transfer-encoding;
	bh=KR3U43A+Mk/5vXXFLl9fd1HbdgR+Uwdzx7CHS3G9vzo=;
	b=tGdU+nxUR/C8H8xFUt19YSEdUJ+gv/QeUAA8U18eXAmX9lLGm/I0I/A81mTTlxg1ax
	utITq+I0emz2Z9p7Totaa3mEi+O64ipSBUYgPOQTwYLkQ9xV3x/hpo2E7WUvKMe/rLk4
	lZ+Pc27orfuPp/hoZQMEZiyUAYfZHZUNPg0kBi+gBhv4DIuaJYUPn3CdPUpQw6fVblX5
	5fiK/hlAkQrIewzblISo331ia+iW3x4dHQd73ArTFeib9S4zEBmq+wEE8cOKMWuZqbxv
	8NvvD0MpcZKzWDRdApQIkqWJJuuA/zzofcymU5HuRpwg689/9rvUodrU2PF2G9h2GEGB
	YPrw==
Received: by 10.68.228.161 with SMTP id sj1mr6810231pbc.71.1348147779816; Thu,
	20 Sep 2012 06:29:39 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.68.135.42 with HTTP; Thu, 20 Sep 2012 06:29:19 -0700 (PDT)
In-Reply-To: <20120918133650.GC12053@phenom.dumpdata.com>
References: <CAJ75kXZm-BqWdL2O41XkSE1VCdd4ruW=+CqDmR1b3=701RnXmw@mail.gmail.com>
	<20120918133650.GC12053@phenom.dumpdata.com>
From: William Dauchy <wdauchy@gmail.com>
Date: Thu, 20 Sep 2012 15:29:19 +0200
Message-ID: <CAJ75kXZEaCj4Jqs_qm46d7U-s1C2hkAONs8c5Audrw2c3X=nBA@mail.gmail.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] Error getting mfn
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Sep 18, 2012 at 3:36 PM, Konrad Rzeszutek Wilk
<konrad.wilk@oracle.com> wrote:
> Please use 'sync_console loglvl=all dom0_max_vcpus=1 console=com1 com1=xxxxx' and on the Linux command line:
> 'console=hvc0 debug loglevel=8"

Here the version with NUMA:

(XEN) Xen version 4.1.3 (package@) (gcc version 4.4.5 (Debian 4.4.5-8)
) Mon Sep 17 15:01:52 UTC 2012
(XEN) Latest ChangeSet: Thu Aug 09 16:47:30 2012 +0100 23334:ce7195d2b80e
(XEN) Console output is synchronous.
(XEN) Bootloader: COM32 Multiboot loader v0.2
(XEN) Command line: console=com2 debug sync_console dom0_max_vcpus=1
dom0_mem=1024M,max:1024M loglvl=all guest_loglvl=info
(XEN) Video information:
(XEN)  VGA is text mode 80x25, font 8x16
(XEN)  VBE/DDC methods: none; EDID transfer time: 1 seconds
(XEN)  EDID info not retrieved because no DDC retrieval method detected
(XEN) Disc information:
(XEN)  Found 0 MBR signatures
(XEN)  Found 0 EDD information structures
(XEN) Xen-e820 RAM map:
(XEN)  0000000000000000 - 000000000009b400 (usable)
(XEN)  000000000009b400 - 00000000000a0000 (reserved)
(XEN)  00000000000e0000 - 0000000000100000 (reserved)
(XEN)  0000000000100000 - 00000000bf730000 (usable)
(XEN)  00000000bf730000 - 00000000bf73e000 (ACPI data)
(XEN)  00000000bf73e000 - 00000000bf7a0000 (ACPI NVS)
(XEN)  00000000bf7a0000 - 00000000bf7b0000 (reserved)
(XEN)  00000000bf7bc000 - 00000000c0000000 (reserved)
(XEN)  00000000e0000000 - 00000000f0000000 (reserved)
(XEN)  00000000fee00000 - 00000000fee01000 (reserved)
(XEN)  00000000ffa00000 - 0000000100000000 (reserved)
(XEN)  0000000100000000 - 0000000c40000000 (usable)
(XEN) ACPI: RSDP 000FA6F0, 0024 (r2 ACPIAM)
(XEN) ACPI: XSDT BF730100, 006C (r1 122311 XSDT1136 20111223 MSFT       97)
(XEN) ACPI: FACP BF730290, 00F4 (r4 122311 FACP1136 20111223 MSFT       97)
(XEN) ACPI: DSDT BF730540, 48F7 (r2  5442B 5442B166      166 INTL 20051117)
(XEN) ACPI: FACS BF73E000, 0040
(XEN) ACPI: APIC BF730390, 011E (r2 122311 APIC1136 20111223 MSFT       97)
(XEN) ACPI: SPCR BF7304B0, 0050 (r1 122311 SPCR1136 20111223 MSFT       97)
(XEN) ACPI: MCFG BF730500, 003C (r1 122311 OEMMCFG  20111223 MSFT       97)
(XEN) ACPI: OEMB BF73E040, 0082 (r1 122311 OEMB1136 20111223 MSFT       97)
(XEN) ACPI: SRAT BF73A540, 0250 (r2 122311 OEMSRAT         1 INTL        1)
(XEN) ACPI: HPET BF73A790, 0038 (r1 122311 OEMHPET  20111223 MSFT       97)
(XEN) ACPI: DMAR BF73E0D0, 00D8 (r1    AMI  OEMDMAR        1 MSFT       97)
(XEN) ACPI: SSDT BF7439A0, 0363 (r1 DpgPmm    CpuPm       12 INTL 20051117)
(XEN) System RAM: 49142MB (50322220kB)
(XEN) SRAT: PXM 0 -> APIC 0 -> Node 0
(XEN) SRAT: PXM 0 -> APIC 2 -> Node 0
(XEN) SRAT: PXM 0 -> APIC 4 -> Node 0
(XEN) SRAT: PXM 0 -> APIC 16 -> Node 0
(XEN) SRAT: PXM 0 -> APIC 18 -> Node 0
(XEN) SRAT: PXM 0 -> APIC 20 -> Node 0
(XEN) SRAT: PXM 0 -> APIC 1 -> Node 0
(XEN) SRAT: PXM 0 -> APIC 3 -> Node 0
(XEN) SRAT: PXM 0 -> APIC 5 -> Node 0
(XEN) SRAT: PXM 0 -> APIC 17 -> Node 0
(XEN) SRAT: PXM 0 -> APIC 19 -> Node 0
(XEN) SRAT: PXM 0 -> APIC 21 -> Node 0
(XEN) SRAT: PXM 1 -> APIC 32 -> Node 1
(XEN) SRAT: PXM 1 -> APIC 34 -> Node 1
(XEN) SRAT: PXM 1 -> APIC 36 -> Node 1
(XEN) SRAT: PXM 1 -> APIC 48 -> Node 1
(XEN) SRAT: PXM 1 -> APIC 50 -> Node 1
(XEN) SRAT: PXM 1 -> APIC 52 -> Node 1
(XEN) SRAT: PXM 1 -> APIC 33 -> Node 1
(XEN) SRAT: PXM 1 -> APIC 35 -> Node 1
(XEN) SRAT: PXM 1 -> APIC 37 -> Node 1
(XEN) SRAT: PXM 1 -> APIC 49 -> Node 1
(XEN) SRAT: PXM 1 -> APIC 51 -> Node 1
(XEN) SRAT: PXM 1 -> APIC 53 -> Node 1
(XEN) SRAT: Node 0 PXM 0 0-a0000
(XEN) SRAT: Node 0 PXM 0 100000-c0000000
(XEN) SRAT: Node 0 PXM 0 100000000-640000000
(XEN) SRAT: Node 1 PXM 1 640000000-c40000000
(XEN) NUMA: Allocated memnodemap from c3f7b8000 - c3f7c5000
(XEN) NUMA: Using 8 for the hash shift.
(XEN) Domain heap initialised DMA width 32 bits
(XEN) found SMP MP-table at 000ff780
(XEN) DMI present.
(XEN) Using APIC driver default
(XEN) ACPI: PM-Timer IO Port: 0x808
(XEN) ACPI: ACPI SLEEP INFO: pm1x_cnt[804,0], pm1x_evt[800,0]
(XEN) ACPI:                  wakeup_vec[bf73e00c], vec_size[20]
(XEN) ACPI: Local APIC address 0xfee00000
(XEN) ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled)
(XEN) Processor #0 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x02] lapic_id[0x02] enabled)
(XEN) Processor #2 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x03] lapic_id[0x04] enabled)
(XEN) Processor #4 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x04] lapic_id[0x10] enabled)
(XEN) Processor #16 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x05] lapic_id[0x12] enabled)
(XEN) Processor #18 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x06] lapic_id[0x14] enabled)
(XEN) Processor #20 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x07] lapic_id[0x20] enabled)
(XEN) Processor #32 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x08] lapic_id[0x22] enabled)
(XEN) Processor #34 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x09] lapic_id[0x24] enabled)
(XEN) Processor #36 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x0a] lapic_id[0x30] enabled)
(XEN) Processor #48 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x0b] lapic_id[0x32] enabled)
(XEN) Processor #50 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x0c] lapic_id[0x34] enabled)
(XEN) Processor #52 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x0d] lapic_id[0x01] enabled)
(XEN) Processor #1 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x0e] lapic_id[0x03] enabled)
(XEN) Processor #3 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x0f] lapic_id[0x05] enabled)
(XEN) Processor #5 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x10] lapic_id[0x11] enabled)
(XEN) Processor #17 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x11] lapic_id[0x13] enabled)
(XEN) Processor #19 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x12] lapic_id[0x15] enabled)
(XEN) Processor #21 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x13] lapic_id[0x21] enabled)
(XEN) Processor #33 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x14] lapic_id[0x23] enabled)
(XEN) Processor #35 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x15] lapic_id[0x25] enabled)
(XEN) Processor #37 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x16] lapic_id[0x31] enabled)
(XEN) Processor #49 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x17] lapic_id[0x33] enabled)
(XEN) Processor #51 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x18] lapic_id[0x35] enabled)
(XEN) Processor #53 6:12 APIC version 21
(XEN) ACPI: LAPIC_NMI (acpi_id[0xff] dfl dfl lint[0x1])
(XEN) Overriding APIC driver with bigsmp
(XEN) ACPI: IOAPIC (id[0x06] address[0xfec00000] gsi_base[0])
(XEN) IOAPIC[0]: apic_id 6, version 32, address 0xfec00000, GSI 0-23
(XEN) ACPI: IOAPIC (id[0x07] address[0xfec8a000] gsi_base[24])
(XEN) IOAPIC[1]: apic_id 7, version 32, address 0xfec8a000, GSI 24-47
(XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
(XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
(XEN) ACPI: IRQ0 used by override.
(XEN) ACPI: IRQ2 used by override.
(XEN) ACPI: IRQ9 used by override.
(XEN) Enabling APIC mode:  Phys.  Using 2 I/O APICs
(XEN) ACPI: HPET id: 0x8086a301 base: 0xfed00000
(XEN) PCI: MCFG configuration 0: base e0000000 segment 0 buses 0 - 255
(XEN) PCI: MCFG area at e0000000 reserved in E820
(XEN) Table is not found!
(XEN) Using ACPI (MADT) for SMP configuration information
(XEN) IRQ limits: 48 GSI, 4576 MSI/MSI-X
(XEN) Using scheduler: SMP Credit Scheduler (credit)
(XEN) Detected 2266.812 MHz processor.
(XEN) Initing memory sharing.
(XEN) mce_intel.c:1162: MCA Capability: BCAST 1 SER 0 CMCI 1 firstbank
0 extended MCE MSR 0
(XEN) Intel machine check reporting enabled
(XEN) Intel VT-d supported page sizes: 4kB.
(XEN) Intel VT-d Snoop Control enabled.
(XEN) Intel VT-d Dom0 DMA Passthrough not enabled.
(XEN) Intel VT-d Queued Invalidation enabled.
(XEN) Intel VT-d Interrupt Remapping not enabled.
(XEN) Intel VT-d Shared EPT tables not enabled.
(XEN) I/O virtualisation enabled
(XEN)  - Dom0 mode: Relaxed
(XEN) Enabled directed EOI with ioapic_ack_old on!
(XEN) ENABLING IO-APIC IRQs
(XEN)  -> Using old ACK method
(XEN) ..TIMER: vector=0xF0 apic1=0 pin1=2 apic2=-1 pin2=-1
(XEN) Platform timer is 14.318MHz HPET
(XEN) Defaulting to alternative key handling; send 'A' to switch to normal mode.
(XEN) Allocated console ring of 256 KiB.
(XEN) VMX: Supported advanced features:
(XEN)  - APIC MMIO access virtualisation
(XEN)  - APIC TPR shadow
(XEN)  - Extended Page Tables (EPT)
(XEN)  - Virtual-Processor Identifiers (VPID)
(XEN)  - Virtual NMI
(XEN)  - MSR direct-access bitmap
(XEN)  - Unrestricted Guest
(XEN) HVM: ASIDs enabled.
(XEN) HVM: VMX enabled
(XEN) HVM: Hardware Assisted Paging (HAP) detected
(XEN) HVM: HAP page sizes: 4kB, 2MB, 1GB
(XEN) Brought up 24 CPUs
(XEN) ACPI sleep modes: S3
(XEN) mcheck_poll: Machine check polling timer started.
(XEN) *** LOADING DOMAIN 0 ***
(XEN)  Xen  kernel: 64-bit, lsb, compat32
(XEN)  Dom0 kernel: 32-bit, PAE, lsb, paddr 0x1000000 -> 0x17dc000
(XEN) PHYSICAL MEMORY ARRANGEMENT:
(XEN)  Dom0 alloc.:   0000000c20000000->0000000c22000000 (253212 pages
to be allocated)
(XEN)  Init. ramdisk: 0000000c3fd1c000->0000000c3ffff200
(XEN) VIRTUAL MEMORY ARRANGEMENT:
(XEN)  Loaded kernel: 00000000c1000000->00000000c17dc000
(XEN)  Init. ramdisk: 00000000c17dc000->00000000c1abf200
(XEN)  Phys-Mach map: 00000000c1ac0000->00000000c1bc0000
(XEN)  Start info:    00000000c1bc0000->00000000c1bc04b4
(XEN)  Page tables:   00000000c1bc1000->00000000c1bd7000
(XEN)  Boot stack:    00000000c1bd7000->00000000c1bd8000
(XEN)  TOTAL:         00000000c0000000->00000000c2000000
(XEN)  ENTRY ADDRESS: 00000000c14f5000
(XEN) Dom0 has maximum 1 VCPUs
(XEN) Scrubbing Free RAM:
..........................................................................................................................................................................................................................................................................................................................................................................................................................................................................................done.
(XEN) Xen trace buffers: disabled
(XEN) Std. Loglevel: All
(XEN) Guest Loglevel: Errors, warnings and info
(XEN) **********************************************
(XEN) ******* WARNING: CONSOLE OUTPUT IS SYNCHRONOUS
(XEN) ******* This option is intended to aid debugging of Xen by ensuring
(XEN) ******* that all output is synchronously delivered on the serial line.
(XEN) ******* However it can introduce SIGNIFICANT latencies and affect
(XEN) ******* timekeeping. It is NOT recommended for production use!
(XEN) **********************************************
(XEN) 3... 2... 1...
(XEN) *** Serial input -> DOM0 (type 'CTRL-a' three times to switch
input to Xen)
(XEN) Freed 212kB init memory.
(XEN) mm.c:908:d0 Error getting mfn 2009b (pfn 5555555555555555) from
L1 entry 000000002009b023 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn 2009c (pfn 5555555555555555) from
L1 entry 000000002009c023 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn 2009d (pfn 5555555555555555) from
L1 entry 000000002009d023 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn 2009e (pfn 5555555555555555) from
L1 entry 000000002009e023 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn 2009f (pfn 5555555555555555) from
L1 entry 000000002009f023 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32000 (pfn 5555555555555555) from
L1 entry 8000000c32000063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32001 (pfn 5555555555555555) from
L1 entry 8000000c32001063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32002 (pfn 5555555555555555) from
L1 entry 8000000c32002063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32003 (pfn 5555555555555555) from
L1 entry 8000000c32003063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32004 (pfn 5555555555555555) from
L1 entry 8000000c32004063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32005 (pfn 5555555555555555) from
L1 entry 8000000c32005063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32006 (pfn 5555555555555555) from
L1 entry 8000000c32006063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32007 (pfn 5555555555555555) from
L1 entry 8000000c32007063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32008 (pfn 5555555555555555) from
L1 entry 8000000c32008063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32009 (pfn 5555555555555555) from
L1 entry 8000000c32009063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c3200a (pfn 5555555555555555) from
L1 entry 8000000c3200a063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c3200b (pfn 5555555555555555) from
L1 entry 8000000c3200b063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c3200c (pfn 5555555555555555) from
L1 entry 8000000c3200c063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c3200d (pfn 5555555555555555) from
L1 entry 8000000c3200d063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c3200e (pfn 5555555555555555) from
L1 entry 8000000c3200e063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c3200f (pfn 5555555555555555) from
L1 entry 8000000c3200f063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32010 (pfn 5555555555555555) from
L1 entry 8000000c32010063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32011 (pfn 5555555555555555) from
L1 entry 8000000c32011063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32012 (pfn 5555555555555555) from
L1 entry 8000000c32012063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32013 (pfn 5555555555555555) from
L1 entry 8000000c32013063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32014 (pfn 5555555555555555) from
L1 entry 8000000c32014063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32015 (pfn 5555555555555555) from
L1 entry 8000000c32015063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32016 (pfn 5555555555555555) from
L1 entry 8000000c32016063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32017 (pfn 5555555555555555) from
L1 entry 8000000c32017063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32018 (pfn 5555555555555555) from
L1 entry 8000000c32018063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32019 (pfn 5555555555555555) from
L1 entry 8000000c32019063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c3201a (pfn 5555555555555555) from
L1 entry 8000000c3201a063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c3201b (pfn 5555555555555555) from
L1 entry 8000000c3201b063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c3201c (pfn 5555555555555555) from
L1 entry 8000000c3201c063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c3201d (pfn 5555555555555555) from
L1 entry 8000000c3201d063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c3201e (pfn 5555555555555555) from
L1 entry 8000000c3201e063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c3201f (pfn 5555555555555555) from
L1 entry 8000000c3201f063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32020 (pfn 5555555555555555) from
L1 entry 8000000c32020063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32021 (pfn 5555555555555555) from
L1 entry 8000000c32021063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32022 (pfn 5555555555555555) from
L1 entry 8000000c32022063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32023 (pfn 5555555555555555) from
L1 entry 8000000c32023063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32024 (pfn 5555555555555555) from
L1 entry 8000000c32024063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32025 (pfn 5555555555555555) from
L1 entry 8000000c32025063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32026 (pfn 5555555555555555) from
L1 entry 8000000c32026063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32027 (pfn 5555555555555555) from
L1 entry 8000000c32027063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32028 (pfn 5555555555555555) from
L1 entry 8000000c32028063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32029 (pfn 5555555555555555) from
L1 entry 8000000c32029063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c3202a (pfn 5555555555555555) from
L1 entry 8000000c3202a063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c3202b (pfn 5555555555555555) from
L1 entry 8000000c3202b063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c3202c (pfn 5555555555555555) from
L1 entry 8000000c3202c063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c3202d (pfn 5555555555555555) from
L1 entry 8000000c3202d063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c3202e (pfn 5555555555555555) from
L1 entry 8000000c3202e063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c3202f (pfn 5555555555555555) from
L1 entry 8000000c3202f063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32030 (pfn 5555555555555555) from
L1 entry 8000000c32030063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32031 (pfn 5555555555555555) from
L1 entry 8000000c32031063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32032 (pfn 5555555555555555) from
L1 entry 8000000c32032063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32033 (pfn 5555555555555555) from
L1 entry 8000000c32033063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32034 (pfn 5555555555555555) from
L1 entry 8000000c32034063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32035 (pfn 5555555555555555) from
L1 entry 8000000c32035063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32036 (pfn 5555555555555555) from
L1 entry 8000000c32036063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32037 (pfn 5555555555555555) from
L1 entry 8000000c32037063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32038 (pfn 5555555555555555) from
L1 entry 8000000c32038063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32039 (pfn 5555555555555555) from
L1 entry 8000000c32039063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c3203a (pfn 5555555555555555) from
L1 entry 8000000c3203a063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c3203b (pfn 5555555555555555) from
L1 entry 8000000c3203b063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c3203c (pfn 5555555555555555) from
L1 entry 8000000c3203c063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c3203d (pfn 5555555555555555) from
L1 entry 8000000c3203d063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c3203e (pfn 5555555555555555) from
L1 entry 8000000c3203e063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c3203f (pfn 5555555555555555) from
L1 entry 8000000c3203f063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32040 (pfn 5555555555555555) from
L1 entry 8000000c32040063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32041 (pfn 5555555555555555) from
L1 entry 8000000c32041063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32042 (pfn 5555555555555555) from
L1 entry 8000000c32042063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32043 (pfn 5555555555555555) from
L1 entry 8000000c32043063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32044 (pfn 5555555555555555) from
L1 entry 8000000c32044063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32045 (pfn 5555555555555555) from
L1 entry 8000000c32045063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32046 (pfn 5555555555555555) from
L1 entry 8000000c32046063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32047 (pfn 5555555555555555) from
L1 entry 8000000c32047063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32048 (pfn 5555555555555555) from
L1 entry 8000000c32048063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32049 (pfn 5555555555555555) from
L1 entry 8000000c32049063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c3204a (pfn 5555555555555555) from
L1 entry 8000000c3204a063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c3204b (pfn 5555555555555555) from
L1 entry 8000000c3204b063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c3204c (pfn 5555555555555555) from
L1 entry 8000000c3204c063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c3204d (pfn 5555555555555555) from
L1 entry 8000000c3204d063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c3204e (pfn 5555555555555555) from
L1 entry 8000000c3204e063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c3204f (pfn 5555555555555555) from
L1 entry 8000000c3204f063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32050 (pfn 5555555555555555) from
L1 entry 8000000c32050063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32051 (pfn 5555555555555555) from
L1 entry 8000000c32051063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32052 (pfn 5555555555555555) from
L1 entry 8000000c32052063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32053 (pfn 5555555555555555) from
L1 entry 8000000c32053063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32054 (pfn 5555555555555555) from
L1 entry 8000000c32054063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32055 (pfn 5555555555555555) from
L1 entry 8000000c32055063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32056 (pfn 5555555555555555) from
L1 entry 8000000c32056063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32057 (pfn 5555555555555555) from
L1 entry 8000000c32057063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32058 (pfn 5555555555555555) from
L1 entry 8000000c32058063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32059 (pfn 5555555555555555) from
L1 entry 8000000c32059063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c3205a (pfn 5555555555555555) from
L1 entry 8000000c3205a063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c3205b (pfn 5555555555555555) from
L1 entry 8000000c3205b063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c3205c (pfn 5555555555555555) from
L1 entry 8000000c3205c063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c3205d (pfn 5555555555555555) from
L1 entry 8000000c3205d063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c3205e (pfn 5555555555555555) from
L1 entry 8000000c3205e063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c3205f (pfn 5555555555555555) from
L1 entry 8000000c3205f063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32060 (pfn 5555555555555555) from
L1 entry 8000000c32060063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32061 (pfn 5555555555555555) from
L1 entry 8000000c32061063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32062 (pfn 5555555555555555) from
L1 entry 8000000c32062063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32063 (pfn 5555555555555555) from
L1 entry 8000000c32063063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32064 (pfn 5555555555555555) from
L1 entry 8000000c32064063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32065 (pfn 5555555555555555) from
L1 entry 8000000c32065063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32066 (pfn 5555555555555555) from
L1 entry 8000000c32066063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32067 (pfn 5555555555555555) from
L1 entry 8000000c32067063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32068 (pfn 5555555555555555) from
L1 entry 8000000c32068063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32069 (pfn 5555555555555555) from
L1 entry 8000000c32069063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c3206a (pfn 5555555555555555) from
L1 entry 8000000c3206a063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c3206b (pfn 5555555555555555) from
L1 entry 8000000c3206b063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c3206c (pfn 5555555555555555) from
L1 entry 8000000c3206c063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c3206d (pfn 5555555555555555) from
L1 entry 8000000c3206d063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c3206e (pfn 5555555555555555) from
L1 entry 8000000c3206e063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c3206f (pfn 5555555555555555) from
L1 entry 8000000c3206f063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32070 (pfn 5555555555555555) from
L1 entry 8000000c32070063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32071 (pfn 5555555555555555) from
L1 entry 8000000c32071063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32072 (pfn 5555555555555555) from
L1 entry 8000000c32072063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32073 (pfn 5555555555555555) from
L1 entry 8000000c32073063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32074 (pfn 5555555555555555) from
L1 entry 8000000c32074063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32075 (pfn 5555555555555555) from
L1 entry 8000000c32075063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32076 (pfn 5555555555555555) from
L1 entry 8000000c32076063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32077 (pfn 5555555555555555) from
L1 entry 8000000c32077063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32078 (pfn 5555555555555555) from
L1 entry 8000000c32078063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32079 (pfn 5555555555555555) from
L1 entry 8000000c32079063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c3207a (pfn 5555555555555555) from
L1 entry 8000000c3207a063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c3207b (pfn 5555555555555555) from
L1 entry 8000000c3207b063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c3207c (pfn 5555555555555555) from
L1 entry 8000000c3207c063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c3207d (pfn 5555555555555555) from
L1 entry 8000000c3207d063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c3207e (pfn 5555555555555555) from
L1 entry 8000000c3207e063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c3207f (pfn 5555555555555555) from
L1 entry 8000000c3207f063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32080 (pfn 5555555555555555) from
L1 entry 8000000c32080063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32081 (pfn 5555555555555555) from
L1 entry 8000000c32081063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32082 (pfn 5555555555555555) from
L1 entry 8000000c32082063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32083 (pfn 5555555555555555) from
L1 entry 8000000c32083063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32084 (pfn 5555555555555555) from
L1 entry 8000000c32084063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32085 (pfn 5555555555555555) from
L1 entry 8000000c32085063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32086 (pfn 5555555555555555) from
L1 entry 8000000c32086063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32087 (pfn 5555555555555555) from
L1 entry 8000000c32087063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32088 (pfn 5555555555555555) from
L1 entry 8000000c32088063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32089 (pfn 5555555555555555) from
L1 entry 8000000c32089063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c3208a (pfn 5555555555555555) from
L1 entry 8000000c3208a063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c3208b (pfn 5555555555555555) from
L1 entry 8000000c3208b063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c3208c (pfn 5555555555555555) from
L1 entry 8000000c3208c063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c3208d (pfn 5555555555555555) from
L1 entry 8000000c3208d063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c3208e (pfn 5555555555555555) from
L1 entry 8000000c3208e063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c3208f (pfn 5555555555555555) from
L1 entry 8000000c3208f063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32090 (pfn 5555555555555555) from
L1 entry 8000000c32090063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32091 (pfn 5555555555555555) from
L1 entry 8000000c32091063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32092 (pfn 5555555555555555) from
L1 entry 8000000c32092063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32093 (pfn 5555555555555555) from
L1 entry 8000000c32093063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32094 (pfn 5555555555555555) from
L1 entry 8000000c32094063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32095 (pfn 5555555555555555) from
L1 entry 8000000c32095063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32096 (pfn 5555555555555555) from
L1 entry 8000000c32096063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32097 (pfn 5555555555555555) from
L1 entry 8000000c32097063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32098 (pfn 5555555555555555) from
L1 entry 8000000c32098063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32099 (pfn 5555555555555555) from
L1 entry 8000000c32099063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c3209a (pfn 5555555555555555) from
L1 entry 8000000c3209a063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c3209b (pfn 5555555555555555) from
L1 entry 8000000c3209b063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c3209c (pfn 5555555555555555) from
L1 entry 8000000c3209c063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c3209d (pfn 5555555555555555) from
L1 entry 8000000c3209d063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c3209e (pfn 5555555555555555) from
L1 entry 8000000c3209e063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c3209f (pfn 5555555555555555) from
L1 entry 8000000c3209f063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320a0 (pfn 5555555555555555) from
L1 entry 8000000c320a0063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320a1 (pfn 5555555555555555) from
L1 entry 8000000c320a1063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320a2 (pfn 5555555555555555) from
L1 entry 8000000c320a2063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320a3 (pfn 5555555555555555) from
L1 entry 8000000c320a3063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320a4 (pfn 5555555555555555) from
L1 entry 8000000c320a4063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320a5 (pfn 5555555555555555) from
L1 entry 8000000c320a5063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320a6 (pfn 5555555555555555) from
L1 entry 8000000c320a6063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320a7 (pfn 5555555555555555) from
L1 entry 8000000c320a7063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320a8 (pfn 5555555555555555) from
L1 entry 8000000c320a8063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320a9 (pfn 5555555555555555) from
L1 entry 8000000c320a9063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320aa (pfn 5555555555555555) from
L1 entry 8000000c320aa063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320ab (pfn 5555555555555555) from
L1 entry 8000000c320ab063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320ac (pfn 5555555555555555) from
L1 entry 8000000c320ac063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320ad (pfn 5555555555555555) from
L1 entry 8000000c320ad063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320ae (pfn 5555555555555555) from
L1 entry 8000000c320ae063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320af (pfn 5555555555555555) from
L1 entry 8000000c320af063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320b0 (pfn 5555555555555555) from
L1 entry 8000000c320b0063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320b1 (pfn 5555555555555555) from
L1 entry 8000000c320b1063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320b2 (pfn 5555555555555555) from
L1 entry 8000000c320b2063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320b3 (pfn 5555555555555555) from
L1 entry 8000000c320b3063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320b4 (pfn 5555555555555555) from
L1 entry 8000000c320b4063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320b5 (pfn 5555555555555555) from
L1 entry 8000000c320b5063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320b6 (pfn 5555555555555555) from
L1 entry 8000000c320b6063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320b7 (pfn 5555555555555555) from
L1 entry 8000000c320b7063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320b8 (pfn 5555555555555555) from
L1 entry 8000000c320b8063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320b9 (pfn 5555555555555555) from
L1 entry 8000000c320b9063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320ba (pfn 5555555555555555) from
L1 entry 8000000c320ba063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320bb (pfn 5555555555555555) from
L1 entry 8000000c320bb063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320bc (pfn 5555555555555555) from
L1 entry 8000000c320bc063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320bd (pfn 5555555555555555) from
L1 entry 8000000c320bd063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320be (pfn 5555555555555555) from
L1 entry 8000000c320be063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320bf (pfn 5555555555555555) from
L1 entry 8000000c320bf063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320c0 (pfn 5555555555555555) from
L1 entry 8000000c320c0063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320c1 (pfn 5555555555555555) from
L1 entry 8000000c320c1063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320c2 (pfn 5555555555555555) from
L1 entry 8000000c320c2063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320c3 (pfn 5555555555555555) from
L1 entry 8000000c320c3063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320c4 (pfn 5555555555555555) from
L1 entry 8000000c320c4063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320c5 (pfn 5555555555555555) from
L1 entry 8000000c320c5063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320c6 (pfn 5555555555555555) from
L1 entry 8000000c320c6063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320c7 (pfn 5555555555555555) from
L1 entry 8000000c320c7063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320c8 (pfn 5555555555555555) from
L1 entry 8000000c320c8063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320c9 (pfn 5555555555555555) from
L1 entry 8000000c320c9063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320ca (pfn 5555555555555555) from
L1 entry 8000000c320ca063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320cb (pfn 5555555555555555) from
L1 entry 8000000c320cb063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320cc (pfn 5555555555555555) from
L1 entry 8000000c320cc063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320cd (pfn 5555555555555555) from
L1 entry 8000000c320cd063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320ce (pfn 5555555555555555) from
L1 entry 8000000c320ce063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320cf (pfn 5555555555555555) from
L1 entry 8000000c320cf063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320d0 (pfn 5555555555555555) from
L1 entry 8000000c320d0063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320d1 (pfn 5555555555555555) from
L1 entry 8000000c320d1063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320d2 (pfn 5555555555555555) from
L1 entry 8000000c320d2063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320d3 (pfn 5555555555555555) from
L1 entry 8000000c320d3063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320d4 (pfn 5555555555555555) from
L1 entry 8000000c320d4063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320d5 (pfn 5555555555555555) from
L1 entry 8000000c320d5063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320d6 (pfn 5555555555555555) from
L1 entry 8000000c320d6063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320d7 (pfn 5555555555555555) from
L1 entry 8000000c320d7063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320d8 (pfn 5555555555555555) from
L1 entry 8000000c320d8063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320d9 (pfn 5555555555555555) from
L1 entry 8000000c320d9063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320da (pfn 5555555555555555) from
L1 entry 8000000c320da063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320db (pfn 5555555555555555) from
L1 entry 8000000c320db063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320dc (pfn 5555555555555555) from
L1 entry 8000000c320dc063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320dd (pfn 5555555555555555) from
L1 entry 8000000c320dd063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320de (pfn 5555555555555555) from
L1 entry 8000000c320de063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320df (pfn 5555555555555555) from
L1 entry 8000000c320df063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320e0 (pfn 5555555555555555) from
L1 entry 8000000c320e0063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320e1 (pfn 5555555555555555) from
L1 entry 8000000c320e1063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320e2 (pfn 5555555555555555) from
L1 entry 8000000c320e2063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320e3 (pfn 5555555555555555) from
L1 entry 8000000c320e3063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320e4 (pfn 5555555555555555) from
L1 entry 8000000c320e4063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320e5 (pfn 5555555555555555) from
L1 entry 8000000c320e5063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320e6 (pfn 5555555555555555) from
L1 entry 8000000c320e6063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320e7 (pfn 5555555555555555) from
L1 entry 8000000c320e7063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320e8 (pfn 5555555555555555) from
L1 entry 8000000c320e8063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320e9 (pfn 5555555555555555) from
L1 entry 8000000c320e9063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320ea (pfn 5555555555555555) from
L1 entry 8000000c320ea063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320eb (pfn 5555555555555555) from
L1 entry 8000000c320eb063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320ec (pfn 5555555555555555) from
L1 entry 8000000c320ec063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320ed (pfn 5555555555555555) from
L1 entry 8000000c320ed063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320ee (pfn 5555555555555555) from
L1 entry 8000000c320ee063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320ef (pfn 5555555555555555) from
L1 entry 8000000c320ef063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320f0 (pfn 5555555555555555) from
L1 entry 8000000c320f0063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320f1 (pfn 5555555555555555) from
L1 entry 8000000c320f1063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320f2 (pfn 5555555555555555) from
L1 entry 8000000c320f2063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320f3 (pfn 5555555555555555) from
L1 entry 8000000c320f3063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320f4 (pfn 5555555555555555) from
L1 entry 8000000c320f4063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320f5 (pfn 5555555555555555) from
L1 entry 8000000c320f5063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320f6 (pfn 5555555555555555) from
L1 entry 8000000c320f6063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320f7 (pfn 5555555555555555) from
L1 entry 8000000c320f7063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320f8 (pfn 5555555555555555) from
L1 entry 8000000c320f8063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320f9 (pfn 5555555555555555) from
L1 entry 8000000c320f9063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320fa (pfn 5555555555555555) from
L1 entry 8000000c320fa063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320fb (pfn 5555555555555555) from
L1 entry 8000000c320fb063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320fc (pfn 5555555555555555) from
L1 entry 8000000c320fc063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320fd (pfn 5555555555555555) from
L1 entry 8000000c320fd063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320fe (pfn 5555555555555555) from
L1 entry 8000000c320fe063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c320ff (pfn 5555555555555555) from
L1 entry 8000000c320ff063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32110 (pfn 5555555555555555) from
L1 entry 8000000c32110063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32111 (pfn 5555555555555555) from
L1 entry 8000000c32111063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32112 (pfn 5555555555555555) from
L1 entry 8000000c32112063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32113 (pfn 5555555555555555) from
L1 entry 8000000c32113063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32114 (pfn 5555555555555555) from
L1 entry 8000000c32114063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32115 (pfn 5555555555555555) from
L1 entry 8000000c32115063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32116 (pfn 5555555555555555) from
L1 entry 8000000c32116063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:908:d0 Error getting mfn c32117 (pfn 5555555555555555) from
L1 entry 8000000c32117063 for l1e_owner=0, pg_owner=0
(XEN) PCI add device 00:00.0
(XEN) PCI add device 00:01.0
(XEN) PCI add device 00:03.0
(XEN) PCI add device 00:05.0
(XEN) PCI add device 00:07.0
(XEN) PCI add device 00:13.0
(XEN) PCI add device 00:14.0
(XEN) PCI add device 00:14.1
(XEN) PCI add device 00:14.2
(XEN) PCI add device 00:14.3
(XEN) PCI add device 00:16.0
(XEN) PCI add device 00:16.1
(XEN) PCI add device 00:16.2
(XEN) PCI add device 00:16.3
(XEN) PCI add device 00:16.4
(XEN) PCI add device 00:16.5
(XEN) PCI add device 00:16.6
(XEN) PCI add device 00:16.7
(XEN) PCI add device 00:1d.0
(XEN) PCI add device 00:1d.1
(XEN) PCI add device 00:1d.2
(XEN) PCI add device 00:1d.7
(XEN) PCI add device 00:1e.0
(XEN) PCI add device 00:1f.0
(XEN) PCI add device 00:1f.2
(XEN) PCI add device 00:1f.3
(XEN) PCI add device 01:00.0
(XEN) PCI add device 01:00.1
(XEN) PCI add device 03:00.0
(XEN) PCI add device 03:00.1
(XEN) PCI add device 07:04.0
(XEN) PCI add device fe:00.0
(XEN) PCI add device fe:00.1
(XEN) PCI add device fe:02.0
(XEN) PCI add device fe:02.1
(XEN) PCI add device fe:02.2
(XEN) PCI add device fe:02.3
(XEN) PCI add device fe:02.4
(XEN) PCI add device fe:02.5
(XEN) PCI add device fe:03.0
(XEN) PCI add device fe:03.1
(XEN) PCI add device fe:03.2
(XEN) PCI add device fe:03.4
(XEN) PCI add device fe:04.0
(XEN) PCI add device fe:04.1
(XEN) PCI add device fe:04.2
(XEN) PCI add device fe:04.3
(XEN) PCI add device fe:05.0
(XEN) PCI add device fe:05.1
(XEN) PCI add device fe:05.2
(XEN) PCI add device fe:05.3
(XEN) PCI add device fe:06.0
(XEN) PCI add device fe:06.1
(XEN) PCI add device fe:06.2
(XEN) PCI add device fe:06.3
(XEN) PCI add device ff:00.0
(XEN) PCI add device ff:00.1
(XEN) PCI add device ff:02.0
(XEN) PCI add device ff:02.1
(XEN) PCI add device ff:02.2
(XEN) PCI add device ff:02.3
(XEN) PCI add device ff:02.4
(XEN) PCI add device ff:02.5
(XEN) PCI add device ff:03.0
(XEN) PCI add device ff:03.1
(XEN) PCI add device ff:03.2
(XEN) PCI add device ff:03.4
(XEN) PCI add device ff:04.0
(XEN) PCI add device ff:04.1
(XEN) PCI add device ff:04.2
(XEN) PCI add device ff:04.3
(XEN) PCI add device ff:05.0
(XEN) PCI add device ff:05.1
(XEN) PCI add device ff:05.2
(XEN) PCI add device ff:05.3
(XEN) PCI add device ff:06.0
(XEN) PCI add device ff:06.1
(XEN) PCI add device ff:06.2
(XEN) PCI add device ff:06.3
(XEN) ../physdev.c:171: dom0: wrong map_pirq type 3



-- 
William

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 20 13:30:43 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Sep 2012 13: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 1TEgpr-0007tt-BR; Thu, 20 Sep 2012 13:30: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 1TEgpp-0007te-W3
	for xen-devel@lists.xensource.com; Thu, 20 Sep 2012 13:30:30 +0000
Received: from [85.158.137.99:64150] by server-7.bemta-3.messagelabs.com id
	98/98-32000-57A1B505; Thu, 20 Sep 2012 13:30:29 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-217.messagelabs.com!1348147827!13678819!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTA0NTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27117 invoked from network); 20 Sep 2012 13:30:28 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Sep 2012 13:30:28 -0000
X-IronPort-AV: E=Sophos;i="4.80,453,1344211200"; d="scan'208";a="14657372"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Sep 2012 13:30: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.279.1;
	Thu, 20 Sep 2012 14:30:27 +0100
Message-ID: <1348147826.26501.47.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Marc Zyngier <marc.zyngier@arm.com>
Date: Thu, 20 Sep 2012 14:30:26 +0100
In-Reply-To: <505B0C00.5010003@arm.com>
References: <1348076658-4511-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<1348135563.11116.94.camel@hornet>
	<alpine.DEB.2.02.1209201235450.29232@kaball.uk.xensource.com>
	<1348142133.11116.109.camel@hornet>
	<alpine.DEB.2.02.1209201308490.29232@kaball.uk.xensource.com>
	<505B0C00.5010003@arm.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Arnd Bergmann <arnd@arndb.de>, Pawel Moll <Pawel.Moll@arm.com>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Xen-devel] [PATCH] arm: introduce a DTS for Xen unprivileged
 virtual 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 Thu, 2012-09-20 at 13:28 +0100, Marc Zyngier wrote:
> I think the important thing here is that the memory map is RS1. As this
> is a (very limited) subset of a vexpress A15, it seems to make some sense.

Looking at arch/arm/boot/dts/vexpress-v2m-rs1.dtsi I don't think we
provide anything which is on rs1 though.

The Xen VM environment has only a gic (via a combination of the gic
virtualisation mode for CPU regs and emulation for the distributor), the
arch timers and xenbus (which is the s/w bus which Xen uses to discover
its paravirtualised peripherals).

Currently we provide a very simple output only emulation of UART0,
simply to get the debug output from the decompresser, but we want that
to go away not get baked in.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 20 13:30:43 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Sep 2012 13: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 1TEgpr-0007tt-BR; Thu, 20 Sep 2012 13:30: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 1TEgpp-0007te-W3
	for xen-devel@lists.xensource.com; Thu, 20 Sep 2012 13:30:30 +0000
Received: from [85.158.137.99:64150] by server-7.bemta-3.messagelabs.com id
	98/98-32000-57A1B505; Thu, 20 Sep 2012 13:30:29 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-217.messagelabs.com!1348147827!13678819!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTA0NTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27117 invoked from network); 20 Sep 2012 13:30:28 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Sep 2012 13:30:28 -0000
X-IronPort-AV: E=Sophos;i="4.80,453,1344211200"; d="scan'208";a="14657372"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Sep 2012 13:30: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.279.1;
	Thu, 20 Sep 2012 14:30:27 +0100
Message-ID: <1348147826.26501.47.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Marc Zyngier <marc.zyngier@arm.com>
Date: Thu, 20 Sep 2012 14:30:26 +0100
In-Reply-To: <505B0C00.5010003@arm.com>
References: <1348076658-4511-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<1348135563.11116.94.camel@hornet>
	<alpine.DEB.2.02.1209201235450.29232@kaball.uk.xensource.com>
	<1348142133.11116.109.camel@hornet>
	<alpine.DEB.2.02.1209201308490.29232@kaball.uk.xensource.com>
	<505B0C00.5010003@arm.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Arnd Bergmann <arnd@arndb.de>, Pawel Moll <Pawel.Moll@arm.com>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Xen-devel] [PATCH] arm: introduce a DTS for Xen unprivileged
 virtual 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 Thu, 2012-09-20 at 13:28 +0100, Marc Zyngier wrote:
> I think the important thing here is that the memory map is RS1. As this
> is a (very limited) subset of a vexpress A15, it seems to make some sense.

Looking at arch/arm/boot/dts/vexpress-v2m-rs1.dtsi I don't think we
provide anything which is on rs1 though.

The Xen VM environment has only a gic (via a combination of the gic
virtualisation mode for CPU regs and emulation for the distributor), the
arch timers and xenbus (which is the s/w bus which Xen uses to discover
its paravirtualised peripherals).

Currently we provide a very simple output only emulation of UART0,
simply to get the debug output from the decompresser, but we want that
to go away not get baked in.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 20 13:49:23 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Sep 2012 13: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 1TEh7n-0008Nz-At; Thu, 20 Sep 2012 13:49:03 +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 1TEh7m-0008Nu-2B
	for xen-devel@lists.xensource.com; Thu, 20 Sep 2012 13:49:02 +0000
Received: from [85.158.138.51:33894] by server-4.bemta-3.messagelabs.com id
	14/CC-24831-DCE1B505; Thu, 20 Sep 2012 13:49:01 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1348148938!23406774!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzUzNjM5\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17900 invoked from network); 20 Sep 2012 13:49:00 -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; 20 Sep 2012 13:49:00 -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 q8KDmvuO023218
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 20 Sep 2012 13:48: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
	q8KDmuhX007377
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 20 Sep 2012 13:48:57 GMT
Received: from abhmt105.oracle.com (abhmt105.oracle.com [141.146.116.57])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q8KDmu35004605; Thu, 20 Sep 2012 08:48:56 -0500
Received: from localhost.localdomain (/208.54.36.158)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 20 Sep 2012 06:48:55 -0700
Date: Thu, 20 Sep 2012 09:48:52 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: William Dauchy <wdauchy@gmail.com>
Message-ID: <20120920134851.GB1998@localhost.localdomain>
References: <CAJ75kXZm-BqWdL2O41XkSE1VCdd4ruW=+CqDmR1b3=701RnXmw@mail.gmail.com>
	<20120918133650.GC12053@phenom.dumpdata.com>
	<CAJ75kXZEaCj4Jqs_qm46d7U-s1C2hkAONs8c5Audrw2c3X=nBA@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAJ75kXZEaCj4Jqs_qm46d7U-s1C2hkAONs8c5Audrw2c3X=nBA@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] Error getting mfn
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Sep 20, 2012 at 03:29:19PM +0200, William Dauchy wrote:
> On Tue, Sep 18, 2012 at 3:36 PM, Konrad Rzeszutek Wilk
> <konrad.wilk@oracle.com> wrote:
> > Please use 'sync_console loglvl=all dom0_max_vcpus=1 console=com1 com1=xxxxx' and on the Linux command line:
> > 'console=hvc0 debug loglevel=8"

I really need to see the Linux command line as well. I am not
sure why I am not seeing it thought? What are your Linux commnad
line parameters? Can you do 'cat /proc/cmdline' after Linux has booted?
(if it has booted).

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 20 13:49:23 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Sep 2012 13: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 1TEh7n-0008Nz-At; Thu, 20 Sep 2012 13:49:03 +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 1TEh7m-0008Nu-2B
	for xen-devel@lists.xensource.com; Thu, 20 Sep 2012 13:49:02 +0000
Received: from [85.158.138.51:33894] by server-4.bemta-3.messagelabs.com id
	14/CC-24831-DCE1B505; Thu, 20 Sep 2012 13:49:01 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1348148938!23406774!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzUzNjM5\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17900 invoked from network); 20 Sep 2012 13:49:00 -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; 20 Sep 2012 13:49:00 -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 q8KDmvuO023218
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 20 Sep 2012 13:48: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
	q8KDmuhX007377
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 20 Sep 2012 13:48:57 GMT
Received: from abhmt105.oracle.com (abhmt105.oracle.com [141.146.116.57])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q8KDmu35004605; Thu, 20 Sep 2012 08:48:56 -0500
Received: from localhost.localdomain (/208.54.36.158)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 20 Sep 2012 06:48:55 -0700
Date: Thu, 20 Sep 2012 09:48:52 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: William Dauchy <wdauchy@gmail.com>
Message-ID: <20120920134851.GB1998@localhost.localdomain>
References: <CAJ75kXZm-BqWdL2O41XkSE1VCdd4ruW=+CqDmR1b3=701RnXmw@mail.gmail.com>
	<20120918133650.GC12053@phenom.dumpdata.com>
	<CAJ75kXZEaCj4Jqs_qm46d7U-s1C2hkAONs8c5Audrw2c3X=nBA@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAJ75kXZEaCj4Jqs_qm46d7U-s1C2hkAONs8c5Audrw2c3X=nBA@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] Error getting mfn
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Sep 20, 2012 at 03:29:19PM +0200, William Dauchy wrote:
> On Tue, Sep 18, 2012 at 3:36 PM, Konrad Rzeszutek Wilk
> <konrad.wilk@oracle.com> wrote:
> > Please use 'sync_console loglvl=all dom0_max_vcpus=1 console=com1 com1=xxxxx' and on the Linux command line:
> > 'console=hvc0 debug loglevel=8"

I really need to see the Linux command line as well. I am not
sure why I am not seeing it thought? What are your Linux commnad
line parameters? Can you do 'cat /proc/cmdline' after Linux has booted?
(if it has booted).

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 20 13:50:31 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Sep 2012 13:50:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TEh8q-0008Rz-QB; Thu, 20 Sep 2012 13:50:08 +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 1TEh8p-0008Rm-Gi
	for xen-devel@lists.xen.org; Thu, 20 Sep 2012 13:50:07 +0000
Received: from [85.158.139.83:25664] by server-5.bemta-5.messagelabs.com id
	62/86-30514-E0F1B505; Thu, 20 Sep 2012 13:50:06 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1348149004!31231754!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDc2MzYwOQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13168 invoked from network); 20 Sep 2012 13:50:05 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-12.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 20 Sep 2012 13:50:05 -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 q8KDnwsH001431
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 20 Sep 2012 13:49:58 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
	q8KDnvEh029554
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 20 Sep 2012 13:49:57 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
	q8KDnvjq020000; Thu, 20 Sep 2012 08:49:57 -0500
Received: from localhost.localdomain (/208.54.36.158)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 20 Sep 2012 06:49:57 -0700
Date: Thu, 20 Sep 2012 09:49:53 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20120920134951.GC1998@localhost.localdomain>
References: <1348051887-21885-1-git-send-email-oliver.chick@citrix.com>
	<505AF126.2050806@citrix.com>
	<1348140637.24539.32.camel@oliverchick-Precision-WorkStation-T3400>
	<505B1EB9020000780009CA6E@nat28.tlf.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <505B1EB9020000780009CA6E@nat28.tlf.novell.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>,
	Oliver Chick <oliver.chick@citrix.com>,
	David Vrabel <david.vrabel@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] Persistent grant maps for xen blk drivers
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Sep 20, 2012 at 12:48:41PM +0100, Jan Beulich wrote:
> >>> On 20.09.12 at 13:30, Oliver Chick <oliver.chick@citrix.com> wrote:
> > The memory overhead, and fallback mode points are related:
> > -Firstly, it turns out that the overhead is actually 2.75MB, not 11MB
> > per device. I made a mistake (pointed out by Jan) as the maximum number
> > of requests that can fit into a single-page ring is 64, not 256.
> > -Clearly, this still scales linearly. So the problem of memory footprint
> > will occur with more VMs, or block devices.
> > -Whilst 2.75MB per device is probably acceptable (?), if we start using
> > multipage rings, then we might not want to have
> > BLKIF_MAX_PERS_REQUESTS_PER_DEVICE==__RING_SIZE, as this will cause the
> > memory overhead to increase. This is why I have implemented the
> > 'fallback' mode. With a multipage ring, it seems reasonable to want the
> > first $x$ grefs seen by blkback to be treated as persistent, and any
> > later ones to be non-persistent. Does that seem sensible?
> 
> From a resource usage pov, perhaps. But this will get the guest
> entirely unpredictable performance. Plus I don't think 11Mb of

Wouldn't it fall back to the older performance?
> _virtual_ space is unacceptable overhead in a 64-bit kernel. If
> you really want/need this in a 32-bit one, then perhaps some
> other alternatives would be needed (and persistent grants may
> not be the right approach there in the first place).
> 
> Jan
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 20 13:50:31 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Sep 2012 13:50:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TEh8q-0008Rz-QB; Thu, 20 Sep 2012 13:50:08 +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 1TEh8p-0008Rm-Gi
	for xen-devel@lists.xen.org; Thu, 20 Sep 2012 13:50:07 +0000
Received: from [85.158.139.83:25664] by server-5.bemta-5.messagelabs.com id
	62/86-30514-E0F1B505; Thu, 20 Sep 2012 13:50:06 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1348149004!31231754!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDc2MzYwOQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13168 invoked from network); 20 Sep 2012 13:50:05 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-12.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 20 Sep 2012 13:50:05 -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 q8KDnwsH001431
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 20 Sep 2012 13:49:58 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
	q8KDnvEh029554
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 20 Sep 2012 13:49:57 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
	q8KDnvjq020000; Thu, 20 Sep 2012 08:49:57 -0500
Received: from localhost.localdomain (/208.54.36.158)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 20 Sep 2012 06:49:57 -0700
Date: Thu, 20 Sep 2012 09:49:53 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20120920134951.GC1998@localhost.localdomain>
References: <1348051887-21885-1-git-send-email-oliver.chick@citrix.com>
	<505AF126.2050806@citrix.com>
	<1348140637.24539.32.camel@oliverchick-Precision-WorkStation-T3400>
	<505B1EB9020000780009CA6E@nat28.tlf.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <505B1EB9020000780009CA6E@nat28.tlf.novell.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>,
	Oliver Chick <oliver.chick@citrix.com>,
	David Vrabel <david.vrabel@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] Persistent grant maps for xen blk drivers
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Sep 20, 2012 at 12:48:41PM +0100, Jan Beulich wrote:
> >>> On 20.09.12 at 13:30, Oliver Chick <oliver.chick@citrix.com> wrote:
> > The memory overhead, and fallback mode points are related:
> > -Firstly, it turns out that the overhead is actually 2.75MB, not 11MB
> > per device. I made a mistake (pointed out by Jan) as the maximum number
> > of requests that can fit into a single-page ring is 64, not 256.
> > -Clearly, this still scales linearly. So the problem of memory footprint
> > will occur with more VMs, or block devices.
> > -Whilst 2.75MB per device is probably acceptable (?), if we start using
> > multipage rings, then we might not want to have
> > BLKIF_MAX_PERS_REQUESTS_PER_DEVICE==__RING_SIZE, as this will cause the
> > memory overhead to increase. This is why I have implemented the
> > 'fallback' mode. With a multipage ring, it seems reasonable to want the
> > first $x$ grefs seen by blkback to be treated as persistent, and any
> > later ones to be non-persistent. Does that seem sensible?
> 
> From a resource usage pov, perhaps. But this will get the guest
> entirely unpredictable performance. Plus I don't think 11Mb of

Wouldn't it fall back to the older performance?
> _virtual_ space is unacceptable overhead in a 64-bit kernel. If
> you really want/need this in a 32-bit one, then perhaps some
> other alternatives would be needed (and persistent grants may
> not be the right approach there in the first place).
> 
> Jan
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 20 13:51:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Sep 2012 13:51:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TEh9a-0008WO-8e; Thu, 20 Sep 2012 13:50:54 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <marc.zyngier@arm.com>) id 1TEh9Y-0008Vx-0S
	for xen-devel@lists.xensource.com; Thu, 20 Sep 2012 13:50:52 +0000
Received: from [85.158.143.99:10157] by server-2.bemta-4.messagelabs.com id
	EC/75-06610-B3F1B505; Thu, 20 Sep 2012 13:50:51 +0000
X-Env-Sender: marc.zyngier@arm.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1348149049!22938915!1
X-Originating-IP: [91.220.42.44]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogOTEuMjIwLjQyLjQ0ID0+IDI5ODkzOA==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30719 invoked from network); 20 Sep 2012 13:50:50 -0000
Received: from service87.mimecast.com (HELO service87.mimecast.com)
	(91.220.42.44) by server-2.tower-216.messagelabs.com with SMTP;
	20 Sep 2012 13:50:50 -0000
Received: from cam-owa1.Emea.Arm.com (fw-tnat.cambridge.arm.com
	[217.140.96.21]) by service87.mimecast.com;
	Thu, 20 Sep 2012 14:50:49 +0100
Received: from [10.1.70.21] ([10.1.255.212]) by cam-owa1.Emea.Arm.com with
	Microsoft SMTPSVC(6.0.3790.0); Thu, 20 Sep 2012 14:50:48 +0100
Message-ID: <505B1F37.9040305@arm.com>
Date: Thu, 20 Sep 2012 14:50:47 +0100
From: Marc Zyngier <marc.zyngier@arm.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:14.0) Gecko/20120714 Thunderbird/14.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <1348076658-4511-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<1348135563.11116.94.camel@hornet>
	<alpine.DEB.2.02.1209201235450.29232@kaball.uk.xensource.com>
	<1348142133.11116.109.camel@hornet>
	<alpine.DEB.2.02.1209201308490.29232@kaball.uk.xensource.com>
	<505B0C00.5010003@arm.com>
	<1348147826.26501.47.camel@zakaz.uk.xensource.com>
In-Reply-To: <1348147826.26501.47.camel@zakaz.uk.xensource.com>
X-Enigmail-Version: 1.5a1pre
X-OriginalArrivalTime: 20 Sep 2012 13:50:48.0413 (UTC)
	FILETIME=[F097F0D0:01CD9736]
X-MC-Unique: 112092014504917701
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Arnd Bergmann <arnd@arndb.de>, Pawel Moll <Pawel.Moll@arm.com>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Xen-devel] [PATCH] arm: introduce a DTS for Xen unprivileged
	virtual 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 20/09/12 14:30, Ian Campbell wrote:
> On Thu, 2012-09-20 at 13:28 +0100, Marc Zyngier wrote:
>> I think the important thing here is that the memory map is RS1. As this
>> is a (very limited) subset of a vexpress A15, it seems to make some sense.
> 
> Looking at arch/arm/boot/dts/vexpress-v2m-rs1.dtsi I don't think we
> provide anything which is on rs1 though.

The location of both GIC and memory are RS1 "compliant" (as in "they are
at the expected location").

	M.
-- 
Jazz is not dead. It just smells funny...


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 20 13:51:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Sep 2012 13:51:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TEh9a-0008WO-8e; Thu, 20 Sep 2012 13:50:54 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <marc.zyngier@arm.com>) id 1TEh9Y-0008Vx-0S
	for xen-devel@lists.xensource.com; Thu, 20 Sep 2012 13:50:52 +0000
Received: from [85.158.143.99:10157] by server-2.bemta-4.messagelabs.com id
	EC/75-06610-B3F1B505; Thu, 20 Sep 2012 13:50:51 +0000
X-Env-Sender: marc.zyngier@arm.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1348149049!22938915!1
X-Originating-IP: [91.220.42.44]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogOTEuMjIwLjQyLjQ0ID0+IDI5ODkzOA==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30719 invoked from network); 20 Sep 2012 13:50:50 -0000
Received: from service87.mimecast.com (HELO service87.mimecast.com)
	(91.220.42.44) by server-2.tower-216.messagelabs.com with SMTP;
	20 Sep 2012 13:50:50 -0000
Received: from cam-owa1.Emea.Arm.com (fw-tnat.cambridge.arm.com
	[217.140.96.21]) by service87.mimecast.com;
	Thu, 20 Sep 2012 14:50:49 +0100
Received: from [10.1.70.21] ([10.1.255.212]) by cam-owa1.Emea.Arm.com with
	Microsoft SMTPSVC(6.0.3790.0); Thu, 20 Sep 2012 14:50:48 +0100
Message-ID: <505B1F37.9040305@arm.com>
Date: Thu, 20 Sep 2012 14:50:47 +0100
From: Marc Zyngier <marc.zyngier@arm.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:14.0) Gecko/20120714 Thunderbird/14.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <1348076658-4511-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<1348135563.11116.94.camel@hornet>
	<alpine.DEB.2.02.1209201235450.29232@kaball.uk.xensource.com>
	<1348142133.11116.109.camel@hornet>
	<alpine.DEB.2.02.1209201308490.29232@kaball.uk.xensource.com>
	<505B0C00.5010003@arm.com>
	<1348147826.26501.47.camel@zakaz.uk.xensource.com>
In-Reply-To: <1348147826.26501.47.camel@zakaz.uk.xensource.com>
X-Enigmail-Version: 1.5a1pre
X-OriginalArrivalTime: 20 Sep 2012 13:50:48.0413 (UTC)
	FILETIME=[F097F0D0:01CD9736]
X-MC-Unique: 112092014504917701
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Arnd Bergmann <arnd@arndb.de>, Pawel Moll <Pawel.Moll@arm.com>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Xen-devel] [PATCH] arm: introduce a DTS for Xen unprivileged
	virtual 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 20/09/12 14:30, Ian Campbell wrote:
> On Thu, 2012-09-20 at 13:28 +0100, Marc Zyngier wrote:
>> I think the important thing here is that the memory map is RS1. As this
>> is a (very limited) subset of a vexpress A15, it seems to make some sense.
> 
> Looking at arch/arm/boot/dts/vexpress-v2m-rs1.dtsi I don't think we
> provide anything which is on rs1 though.

The location of both GIC and memory are RS1 "compliant" (as in "they are
at the expected location").

	M.
-- 
Jazz is not dead. It just smells funny...


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 20 13:52:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Sep 2012 13:52:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TEhBM-0000GX-Q4; Thu, 20 Sep 2012 13:52:44 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <lukas@laukamp.me>) id 1TEhBM-0000G1-04
	for xen-devel@lists.xensource.com; Thu, 20 Sep 2012 13:52:44 +0000
X-Env-Sender: lukas@laukamp.me
X-Msg-Ref: server-5.tower-27.messagelabs.com!1348149133!8366480!1
X-Originating-IP: [5.9.218.245]
X-SpamReason: No, hits=0.2 required=7.0 tests=RCVD_ILLEGAL_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13217 invoked from network); 20 Sep 2012 13:52:14 -0000
Received: from mailer0.lippux.de (HELO mailer0.lippux.de) (5.9.218.245)
	by server-5.tower-27.messagelabs.com with SMTP;
	20 Sep 2012 13:52:14 -0000
Received: from localhost (localhost [127.0.0.1])
	by mailer0.lippux.de (Postfix) with ESMTP id A48554223E5;
	Thu, 20 Sep 2012 15:52:13 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at mailer0.lippux.de
Received: from mailer0.lippux.de ([127.0.0.1])
	by localhost (mailer0.lippux.de [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id 10k5ntzZHJFH; Thu, 20 Sep 2012 15:52:12 +0200 (CEST)
Received: by mailer0.lippux.de (Postfix, from userid 33)
	id B7A36422410; Thu, 20 Sep 2012 15:52:12 +0200 (CEST)
To: =?UTF-8?Q?Pasi_K=C3=A4rkk=C3=A4inen?= <pasik@iki.fi>
X-PHP-Originating-Script: 0:main.inc
MIME-Version: 1.0
Date: Thu, 20 Sep 2012 15:52:12 +0200
From: Lukas Laukamp <lukas@laukamp.me>
In-Reply-To: <20120920083742.GW8912@reaktio.net>
References: <c277ee4a34ca57f7da68f2e0ab832090@laukamp.me>
	<20120920073643.GU8912@reaktio.net>
	<bce40f714cae80dfd919b3d2c4e870e4@laukamp.me>
	<20120920075217.GV8912@reaktio.net>
	<7d9d2235fa5d81bf4bd8847b9ad89226@laukamp.me>
	<20120920083742.GW8912@reaktio.net>
Message-ID: <a62fce60d8c566e07fa241f405af998f@laukamp.me>
X-Sender: lukas@laukamp.me
User-Agent: Roundcube Webmail/0.7.1
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [User Question] KVM and VirtualBox in 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: 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

QW0gMjAxMi0wOS0yMCAxMDozNywgc2NocmllYiBQYXNpIEvDpHJra8OkaW5lbjoKPiBPbiBUaHUs
IFNlcCAyMCwgMjAxMiBhdCAxMDowMzo0M0FNICswMjAwLCBMdWthcyBMYXVrYW1wIHdyb3RlOgo+
PiA+Cj4+ID5JIHRoaW5rIGl0ICptaWdodCogYmUgcG9zc2libGUgd2hlbiBYZW4gUFZIIChIeWJy
aWQpIGlzIG1lcmdlZCB0bwo+PiA+WGVuIDQuMywKPj4gPndoaWNoIGJhc2ljYWxseSBhbGxvd3Mg
cnVubmluZyBYZW4gZG9tMCBpbiBIVk0gY29udGFpbmVyLgo+PiA+Cj4+ID4tLSBQYXNpCj4+Cj4+
IEhlbGxvLAo+Pgo+PiBJIGdvb2dsZWQgZm9yIHhlbiBIeWJyaWQsIGJ1dCBoYXZlIHF1ZXN0aW9u
IGlmIEkgdW5kZXJzdGFuZCBpdAo+PiBjb3JyZWN0LiBOb3cgdGhlIERvbTAgaXMgYSBQViBHdWVz
dC4KPj4KPgo+IENvcnJlY3QuCj4KPj4gV2l0aCBYZW4gSHlicmlkIHRoZSBEb20wIGNhbiBydW4g
YXMgYSBIVk0gd2l0aCBQViBmZWF0dXJlcyBvbiB0aGUgCj4+IGh5cGVydmlzb3IuCj4+Cj4KPiBQ
VkggZG9tMCBpcyBiYXNpY2x5IFBWIGRvbTAgaW4gSFZNIGNvbnRhaW5lci4gSXQncyBtb3JlIFBW
IHRoYW4gSFZNLgo+Cj4+IFRoaXMgd291bGQgbWFrZSBpdCBwb3NzaWJsZSBiZWNhdXNlIG9mIG5l
c3RlZCB2aXJ0dWFsaXphdGlvbiB0aGF0IAo+PiBLVk0gYW5kIFZpcnR1YWxCb3gKPj4gcnVuIGlu
c2lkZSBkb20wIHJpZ2h0Pwo+Pgo+Cj4gWWVzLCBidXQgUFZIIGRvZXNuJ3QgZW5hYmxlIG5lc3Rl
ZCB2aXJ0IGF1dG9tYXRpY2FsbHksIHRoYXQnbGwKPiByZXF1aXJlIHNvbWUgZXh0cmEgcGF0Y2hl
cy4KPgo+PiBBbmQgbXkgc2Vjb25kIHF1ZXN0aW9uIHdvdWxkIGJlOiBJcyB0aGUgYWltIG9mIFhl
biBoeWJyaWQgdG8gYnJpbmcKPj4gRG9tMCBzdXBwb3J0IHRvIG1vcmUgT1Nlcz8KPj4KPgo+IFRo
ZSBwdXJwb3NlIG9mIFBWSCBkb20wIGlzIHRvIGJlIGFibGUgdG8gdXRpbGl6ZSBIQVAgKEhhcmR3
YXJlCj4gQXNzaXN0ZWQgUGFnaW5nKQo+IGluIGRvbTAsIGFuZCBhbHNvIGxvd2VyaW5nIHN5c2Nh
bGwgb3ZlcmhlYWQgZm9yIDY0Yml0IGRvbTAuCj4KPiBTbyBpdCdzIGFib3V0IG9wdGltaXphdGlv
bnMuCj4gU2VlIE11a2VzaCdzIHByZXNlbnRhdGlvbiBhYm91dCBQVkgvSHlicmlkIGZyb20gWGVu
U3VtbWl0IE5vcnRoIAo+IEFtZXJpY2EgMjAxMi4KPgo+IC0tIFBhc2kKPgo+Cj4gX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KPiBYZW4tZGV2ZWwgbWFpbGlu
ZyBsaXN0Cj4gWGVuLWRldmVsQGxpc3RzLnhlbi5vcmcKPiBodHRwOi8vbGlzdHMueGVuLm9yZy94
ZW4tZGV2ZWwKCkhlbGxvLAoKdGhhbmtzIGZvciBvdXIgcmVwbGllcyBGYWphciBhbmQgUGFzaS4g
TXkgcXVlc3Rpb25zIGFyZSByZXBsaWVkIG5vdy4gSSAKdGhvdWdodCBpdCB3b3VsZCBiZSBjb21m
b3J0YWJsZSB0byBoYXZlIHRoZW0gYWxsIG9uIG9uZSBob3N0LCB3ZSB3aWxsIApzZWUgd2hldGhl
ciBpdCdzIHBvc3NpYmxlIGluIGZ1dHVyZSB3aXRoIFBWSC4KCkJlc3QgUmVnYXJkcwoKX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxp
bmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwOi8vbGlzdHMueGVuLm9yZy94ZW4t
ZGV2ZWwK

From xen-devel-bounces@lists.xen.org Thu Sep 20 13:52:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Sep 2012 13:52:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TEhBM-0000GX-Q4; Thu, 20 Sep 2012 13:52:44 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <lukas@laukamp.me>) id 1TEhBM-0000G1-04
	for xen-devel@lists.xensource.com; Thu, 20 Sep 2012 13:52:44 +0000
X-Env-Sender: lukas@laukamp.me
X-Msg-Ref: server-5.tower-27.messagelabs.com!1348149133!8366480!1
X-Originating-IP: [5.9.218.245]
X-SpamReason: No, hits=0.2 required=7.0 tests=RCVD_ILLEGAL_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13217 invoked from network); 20 Sep 2012 13:52:14 -0000
Received: from mailer0.lippux.de (HELO mailer0.lippux.de) (5.9.218.245)
	by server-5.tower-27.messagelabs.com with SMTP;
	20 Sep 2012 13:52:14 -0000
Received: from localhost (localhost [127.0.0.1])
	by mailer0.lippux.de (Postfix) with ESMTP id A48554223E5;
	Thu, 20 Sep 2012 15:52:13 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at mailer0.lippux.de
Received: from mailer0.lippux.de ([127.0.0.1])
	by localhost (mailer0.lippux.de [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id 10k5ntzZHJFH; Thu, 20 Sep 2012 15:52:12 +0200 (CEST)
Received: by mailer0.lippux.de (Postfix, from userid 33)
	id B7A36422410; Thu, 20 Sep 2012 15:52:12 +0200 (CEST)
To: =?UTF-8?Q?Pasi_K=C3=A4rkk=C3=A4inen?= <pasik@iki.fi>
X-PHP-Originating-Script: 0:main.inc
MIME-Version: 1.0
Date: Thu, 20 Sep 2012 15:52:12 +0200
From: Lukas Laukamp <lukas@laukamp.me>
In-Reply-To: <20120920083742.GW8912@reaktio.net>
References: <c277ee4a34ca57f7da68f2e0ab832090@laukamp.me>
	<20120920073643.GU8912@reaktio.net>
	<bce40f714cae80dfd919b3d2c4e870e4@laukamp.me>
	<20120920075217.GV8912@reaktio.net>
	<7d9d2235fa5d81bf4bd8847b9ad89226@laukamp.me>
	<20120920083742.GW8912@reaktio.net>
Message-ID: <a62fce60d8c566e07fa241f405af998f@laukamp.me>
X-Sender: lukas@laukamp.me
User-Agent: Roundcube Webmail/0.7.1
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [User Question] KVM and VirtualBox in 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: 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

QW0gMjAxMi0wOS0yMCAxMDozNywgc2NocmllYiBQYXNpIEvDpHJra8OkaW5lbjoKPiBPbiBUaHUs
IFNlcCAyMCwgMjAxMiBhdCAxMDowMzo0M0FNICswMjAwLCBMdWthcyBMYXVrYW1wIHdyb3RlOgo+
PiA+Cj4+ID5JIHRoaW5rIGl0ICptaWdodCogYmUgcG9zc2libGUgd2hlbiBYZW4gUFZIIChIeWJy
aWQpIGlzIG1lcmdlZCB0bwo+PiA+WGVuIDQuMywKPj4gPndoaWNoIGJhc2ljYWxseSBhbGxvd3Mg
cnVubmluZyBYZW4gZG9tMCBpbiBIVk0gY29udGFpbmVyLgo+PiA+Cj4+ID4tLSBQYXNpCj4+Cj4+
IEhlbGxvLAo+Pgo+PiBJIGdvb2dsZWQgZm9yIHhlbiBIeWJyaWQsIGJ1dCBoYXZlIHF1ZXN0aW9u
IGlmIEkgdW5kZXJzdGFuZCBpdAo+PiBjb3JyZWN0LiBOb3cgdGhlIERvbTAgaXMgYSBQViBHdWVz
dC4KPj4KPgo+IENvcnJlY3QuCj4KPj4gV2l0aCBYZW4gSHlicmlkIHRoZSBEb20wIGNhbiBydW4g
YXMgYSBIVk0gd2l0aCBQViBmZWF0dXJlcyBvbiB0aGUgCj4+IGh5cGVydmlzb3IuCj4+Cj4KPiBQ
VkggZG9tMCBpcyBiYXNpY2x5IFBWIGRvbTAgaW4gSFZNIGNvbnRhaW5lci4gSXQncyBtb3JlIFBW
IHRoYW4gSFZNLgo+Cj4+IFRoaXMgd291bGQgbWFrZSBpdCBwb3NzaWJsZSBiZWNhdXNlIG9mIG5l
c3RlZCB2aXJ0dWFsaXphdGlvbiB0aGF0IAo+PiBLVk0gYW5kIFZpcnR1YWxCb3gKPj4gcnVuIGlu
c2lkZSBkb20wIHJpZ2h0Pwo+Pgo+Cj4gWWVzLCBidXQgUFZIIGRvZXNuJ3QgZW5hYmxlIG5lc3Rl
ZCB2aXJ0IGF1dG9tYXRpY2FsbHksIHRoYXQnbGwKPiByZXF1aXJlIHNvbWUgZXh0cmEgcGF0Y2hl
cy4KPgo+PiBBbmQgbXkgc2Vjb25kIHF1ZXN0aW9uIHdvdWxkIGJlOiBJcyB0aGUgYWltIG9mIFhl
biBoeWJyaWQgdG8gYnJpbmcKPj4gRG9tMCBzdXBwb3J0IHRvIG1vcmUgT1Nlcz8KPj4KPgo+IFRo
ZSBwdXJwb3NlIG9mIFBWSCBkb20wIGlzIHRvIGJlIGFibGUgdG8gdXRpbGl6ZSBIQVAgKEhhcmR3
YXJlCj4gQXNzaXN0ZWQgUGFnaW5nKQo+IGluIGRvbTAsIGFuZCBhbHNvIGxvd2VyaW5nIHN5c2Nh
bGwgb3ZlcmhlYWQgZm9yIDY0Yml0IGRvbTAuCj4KPiBTbyBpdCdzIGFib3V0IG9wdGltaXphdGlv
bnMuCj4gU2VlIE11a2VzaCdzIHByZXNlbnRhdGlvbiBhYm91dCBQVkgvSHlicmlkIGZyb20gWGVu
U3VtbWl0IE5vcnRoIAo+IEFtZXJpY2EgMjAxMi4KPgo+IC0tIFBhc2kKPgo+Cj4gX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KPiBYZW4tZGV2ZWwgbWFpbGlu
ZyBsaXN0Cj4gWGVuLWRldmVsQGxpc3RzLnhlbi5vcmcKPiBodHRwOi8vbGlzdHMueGVuLm9yZy94
ZW4tZGV2ZWwKCkhlbGxvLAoKdGhhbmtzIGZvciBvdXIgcmVwbGllcyBGYWphciBhbmQgUGFzaS4g
TXkgcXVlc3Rpb25zIGFyZSByZXBsaWVkIG5vdy4gSSAKdGhvdWdodCBpdCB3b3VsZCBiZSBjb21m
b3J0YWJsZSB0byBoYXZlIHRoZW0gYWxsIG9uIG9uZSBob3N0LCB3ZSB3aWxsIApzZWUgd2hldGhl
ciBpdCdzIHBvc3NpYmxlIGluIGZ1dHVyZSB3aXRoIFBWSC4KCkJlc3QgUmVnYXJkcwoKX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxp
bmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwOi8vbGlzdHMueGVuLm9yZy94ZW4t
ZGV2ZWwK

From xen-devel-bounces@lists.xen.org Thu Sep 20 13:53:23 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Sep 2012 13:53:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TEhBq-0000Kq-80; Thu, 20 Sep 2012 13:53:14 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1TEhBo-0000KT-KN
	for xen-devel@lists.xen.org; Thu, 20 Sep 2012 13:53:12 +0000
Received: from [85.158.143.35:17961] by server-2.bemta-4.messagelabs.com id
	1A/09-06610-7CF1B505; Thu, 20 Sep 2012 13:53:11 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1348149187!15891039!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDc2MzYwOQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30700 invoked from network); 20 Sep 2012 13:53:11 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-8.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 20 Sep 2012 13:53:11 -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 q8KDr4dT005074
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 20 Sep 2012 13:53:04 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q8KDr3tM025760
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 20 Sep 2012 13:53:03 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
	q8KDr3uN007765; Thu, 20 Sep 2012 08:53:03 -0500
Received: from localhost.localdomain (/208.54.36.158)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 20 Sep 2012 06:53:02 -0700
Date: Thu, 20 Sep 2012 09:52:59 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Oliver Chick <oliver.chick@citrix.com>
Message-ID: <20120920135257.GD1998@localhost.localdomain>
References: <1348051887-21885-1-git-send-email-oliver.chick@citrix.com>
	<20120919141138.GC12367@phenom.dumpdata.com>
	<1348146745.24539.42.camel@oliverchick-Precision-WorkStation-T3400>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1348146745.24539.42.camel@oliverchick-Precision-WorkStation-T3400>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] Persistent grant maps for xen blk drivers
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Sep 20, 2012 at 02:12:25PM +0100, Oliver Chick wrote:
> Thank you for all your useful feedback, Konrad.
> 
> I have made most of the changes you suggest. I will test them and
> repost. I have made a few points below.

Great. Looking forward to your next patch. Also pls include it
as an attachment as I could not apply it last time.. Not sure if
that is something with your mailer - but attachments usually survive
any MUA mangling.
> > > +                             page_to_pfn(pers_gnt->page));
> > 
> > Would it make sense to cache this in the 'pers_gnt' structure?
> 
> As far as I can tell, we only need this value when mapping, and
> unmapping. So if we cache it, we will use it a maximum of one time. I
> think it's cheap to calculate. Am I right?

Then lets not cache it.
> > > @@ -688,7 +804,7 @@ static int dispatch_rw_block_io(struct xen_blkif *blkif,
> > >       for (i = 0; i < nseg; i++) {
> > >               while ((bio == NULL) ||
> > >                      (bio_add_page(bio,
> > > -                                  blkbk->pending_page(pending_req, i),
> > 
> > Can we get rid of pending_page macro?
> 
> Unfortunately not, it is still used in the non-persistent mode to
> populate the pages[].

Fair enough
> > > +                             memcpy(shared_data + sg->offset,
> > > +                                    bvec_data   + sg->offset,
> > > +                                    sg->length);
> > 
> > Do we need to worry about it spilling over a page? Should we check that
> > sg>offset + sg->length < PAGE_SIZE ?
> 
> I agree, this is probably a worthwhile thing to check.

> 
> > 
> > Also this would imply that based on the offset (so say it is 3999) that the old data (0->3998)
> > might be still there - don't know how important that is?
> 
> This is true. I spoke with IanC about this, and we *think* that this is
> ok. Any old data that is there will have already been given to blkback,
> so we're not really leaking data that we shouldn't be. 

Put a comment in saying that. In case in the future we want to share
the persistent grants with other domains, we would need to address this.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 20 13:53:23 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Sep 2012 13:53:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TEhBq-0000Kq-80; Thu, 20 Sep 2012 13:53:14 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1TEhBo-0000KT-KN
	for xen-devel@lists.xen.org; Thu, 20 Sep 2012 13:53:12 +0000
Received: from [85.158.143.35:17961] by server-2.bemta-4.messagelabs.com id
	1A/09-06610-7CF1B505; Thu, 20 Sep 2012 13:53:11 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1348149187!15891039!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDc2MzYwOQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30700 invoked from network); 20 Sep 2012 13:53:11 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-8.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 20 Sep 2012 13:53:11 -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 q8KDr4dT005074
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 20 Sep 2012 13:53:04 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q8KDr3tM025760
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 20 Sep 2012 13:53:03 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
	q8KDr3uN007765; Thu, 20 Sep 2012 08:53:03 -0500
Received: from localhost.localdomain (/208.54.36.158)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 20 Sep 2012 06:53:02 -0700
Date: Thu, 20 Sep 2012 09:52:59 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Oliver Chick <oliver.chick@citrix.com>
Message-ID: <20120920135257.GD1998@localhost.localdomain>
References: <1348051887-21885-1-git-send-email-oliver.chick@citrix.com>
	<20120919141138.GC12367@phenom.dumpdata.com>
	<1348146745.24539.42.camel@oliverchick-Precision-WorkStation-T3400>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1348146745.24539.42.camel@oliverchick-Precision-WorkStation-T3400>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] Persistent grant maps for xen blk drivers
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Sep 20, 2012 at 02:12:25PM +0100, Oliver Chick wrote:
> Thank you for all your useful feedback, Konrad.
> 
> I have made most of the changes you suggest. I will test them and
> repost. I have made a few points below.

Great. Looking forward to your next patch. Also pls include it
as an attachment as I could not apply it last time.. Not sure if
that is something with your mailer - but attachments usually survive
any MUA mangling.
> > > +                             page_to_pfn(pers_gnt->page));
> > 
> > Would it make sense to cache this in the 'pers_gnt' structure?
> 
> As far as I can tell, we only need this value when mapping, and
> unmapping. So if we cache it, we will use it a maximum of one time. I
> think it's cheap to calculate. Am I right?

Then lets not cache it.
> > > @@ -688,7 +804,7 @@ static int dispatch_rw_block_io(struct xen_blkif *blkif,
> > >       for (i = 0; i < nseg; i++) {
> > >               while ((bio == NULL) ||
> > >                      (bio_add_page(bio,
> > > -                                  blkbk->pending_page(pending_req, i),
> > 
> > Can we get rid of pending_page macro?
> 
> Unfortunately not, it is still used in the non-persistent mode to
> populate the pages[].

Fair enough
> > > +                             memcpy(shared_data + sg->offset,
> > > +                                    bvec_data   + sg->offset,
> > > +                                    sg->length);
> > 
> > Do we need to worry about it spilling over a page? Should we check that
> > sg>offset + sg->length < PAGE_SIZE ?
> 
> I agree, this is probably a worthwhile thing to check.

> 
> > 
> > Also this would imply that based on the offset (so say it is 3999) that the old data (0->3998)
> > might be still there - don't know how important that is?
> 
> This is true. I spoke with IanC about this, and we *think* that this is
> ok. Any old data that is there will have already been given to blkback,
> so we're not really leaking data that we shouldn't be. 

Put a comment in saying that. In case in the future we want to share
the persistent grants with other domains, we would need to address this.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 20 14:07:36 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Sep 2012 14: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 1TEhPY-0000qH-Pd; Thu, 20 Sep 2012 14:07:24 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <attilio.rao@citrix.com>) id 1TEhPW-0000py-Dn
	for xen-devel@lists.xen.org; Thu, 20 Sep 2012 14:07:22 +0000
Received: from [85.158.143.35:27807] by server-2.bemta-4.messagelabs.com id
	29/B0-06610-9132B505; Thu, 20 Sep 2012 14:07:21 +0000
X-Env-Sender: attilio.rao@citrix.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1348150038!17773977!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTA0NTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11374 invoked from network); 20 Sep 2012 14:07: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;
	20 Sep 2012 14:07:19 -0000
X-IronPort-AV: E=Sophos;i="4.80,453,1344211200"; d="scan'208";a="14659684"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Sep 2012 14:07:18 +0000
Received: from [10.80.3.221] (10.80.3.221) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Thu, 20 Sep 2012 15:07:18 +0100
Message-ID: <505B22C5.4050004@citrix.com>
Date: Thu, 20 Sep 2012 15:05:57 +0100
From: Attilio Rao <attilio.rao@citrix.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US;
	rv:1.9.1.16) Gecko/20111110 Icedove/3.0.11
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <505A5A03.4000106@citrix.com>
	<505AE62A020000780009C7F8@nat28.tlf.novell.com>
In-Reply-To: <505AE62A020000780009C7F8@nat28.tlf.novell.com>
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] [RFC] Extend the number of event channels availabe
 to guests
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 20/09/12 08:47, Jan Beulich wrote:
>>>> On 20.09.12 at 01:49, Attilio Rao<attilio.rao@citrix.com>  wrote:
>>>>          
>> Proposal
>> The proposal is pretty simple: the eventchannel search will become a
>> three-level lookup table, with the leaf level being composed by shared
>> pages registered at boot time by the guests.
>> The bitmap working now as leaf (then called "second level") will work
>> alternatively as leaf level still (for older kernel) or for intermediate
>> level to address into a new array of shared pages (for newer kernels).
>> This leaves the possibility to reuse the existing mechanisms without
>> modifying its internals.
>>      
> While adding one level would seem to leave ample room, so did
> the originally 4096 originally. Therefore, even if unimplemented
> right now, I'd like the interface to allow for the guest to specify
> more levels.
>    

There is a big difference here. The third/new level will be composed of 
pages registered at guest installing so it can be expanded on demanded 
necessity. The second-level we have now doesn't work because it is stuck 
in the immutable ABI.
The only useful way to have another level would be in the case we think 
the second-level is not enough to address all the necessary bits in the 
third level in efficient way.

To make you an example, the first level is 64 bits while the second 
level can address 64 times the first level. The third level, to be 
on-par with the same ratio of the second level in terms of performance, 
would be large something like 4 pages. I think we are very far from 
reaching critical levels.

>    
>> More specifically, what needs to happen:
>> - Add new members to struct domain to handle an array of pages (to
>> contain the actual evtchn bitmaps), a further array of pages (to contain
>> the evtchn masks) and a control bit to say if it is subjective to the
>> new mode or not. Initially the arrays will be empty and the control bit
>> will be OFF.
>> - At init_platform() time, the guest must allocate the pages to compose
>> the 2 arrays and invoke a novel hypercall which, at big lines, does the
>> following:
>>     * Creates some pages to populate the new arrays in struct domain via
>> alloc_xenheap_pages()
>>      
> Why? The guest allocated the pages already. Just have the
> hypervisor map them (similar, but without the per-vCPU needs,
> to registering an alternative per-vCPU shared page). Whether
> it turns out more practical to require the guest to enforce
> certain restrictions (like the pages being contiguous and/or
> address restricted) is a secondary aspect.
>    

Actually what I propose seems to be what happens infact in the shared 
page case. Look at what arch_domain_create() and XENMEM_add_to_physmap 
hypercall do (in the XENMAPSPACE_shared_info case). I think this is the 
quicker way to get what we want.

>    
>>     * Recreates the mapping with the gpfn passed from the userland, using
>> basically guest_physmap_add_page()
>>      
> This would then be superfluous.
>
>    
>>     * Sets the control bit to ON
>> - Places that need to access to the actual leaf bit (like, for example,
>> xen_evtchn_do_upcall()) will need to double check the control bit. If it
>> is OFF they consider the second level as the leaf one, otherwise they
>> will do a further lookup to get the bit from the new array of pages.
>>      
> Just like for variable depth page tables - if at all possible, just
> make the accesses variable depth, so that all you need to track
> on a per-domain basis is the depth of the tree.
>    

I agree.

>    
>> Of course there are some nits to be decided yet, like, for example:
>> * How many pages should the new level have? We can start by populating
>> just one, for example
>>      
> Just let the guest specify this (and error if the number is too large).
>    

I agree.

>    
>> * Who should have really the knowledge of how many pages to allocate?
>> Likely the hypervisor should have a threshhold, but in general we may
>> want to have a posting mechanism to have the guest ask the hypervisor
>> before-hand and satisfy its actual request
>>      
> Same here (this is really the same with the previous item, if you
> follow the earlier suggestions).
>
>    
>> * How many bits should be indirected in the third-level by every single
>> bit in the second-level? (that is a really minor factor, but still).
>>      
> The tree should clearly be uniform (i.e. having a factor of
> BITS_PER_LONG per level), just like it is now. For 64-bit guests,
> this would mean 256k channels with 3 levels (32k for 32-bit
> guests).
>
> One aspect to also consider is migration - will the guest have to
> re-issue the extending hypercall, or will this be taken care of for
> it? If the former approach is chosen, would the guest be
> expected to deal with not being able to set up the extension
> again on the new host?
>    

I think this could be also handled with some trickery by switching the 
control bit off. I need to make an assessment on the races invovled 
because we are not any longer in the "domain startup" case.

> And another important (but implementation only) aspect not to
> forget is making domain_dump_evtchn_info() scale with the
> then much higher amount of dumping potentially to be done (i.e.
> not just extend it to cope with the count, but also make sure it
> properly allows softirqs to be handled, which in turn requires to
> not hold the event lock across the whole loop).
>
>    

I still didn't look into it, but thanks for pointing out.

Attilio

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 20 14:07:36 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Sep 2012 14: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 1TEhPY-0000qH-Pd; Thu, 20 Sep 2012 14:07:24 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <attilio.rao@citrix.com>) id 1TEhPW-0000py-Dn
	for xen-devel@lists.xen.org; Thu, 20 Sep 2012 14:07:22 +0000
Received: from [85.158.143.35:27807] by server-2.bemta-4.messagelabs.com id
	29/B0-06610-9132B505; Thu, 20 Sep 2012 14:07:21 +0000
X-Env-Sender: attilio.rao@citrix.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1348150038!17773977!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTA0NTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11374 invoked from network); 20 Sep 2012 14:07: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;
	20 Sep 2012 14:07:19 -0000
X-IronPort-AV: E=Sophos;i="4.80,453,1344211200"; d="scan'208";a="14659684"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Sep 2012 14:07:18 +0000
Received: from [10.80.3.221] (10.80.3.221) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Thu, 20 Sep 2012 15:07:18 +0100
Message-ID: <505B22C5.4050004@citrix.com>
Date: Thu, 20 Sep 2012 15:05:57 +0100
From: Attilio Rao <attilio.rao@citrix.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US;
	rv:1.9.1.16) Gecko/20111110 Icedove/3.0.11
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <505A5A03.4000106@citrix.com>
	<505AE62A020000780009C7F8@nat28.tlf.novell.com>
In-Reply-To: <505AE62A020000780009C7F8@nat28.tlf.novell.com>
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] [RFC] Extend the number of event channels availabe
 to guests
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 20/09/12 08:47, Jan Beulich wrote:
>>>> On 20.09.12 at 01:49, Attilio Rao<attilio.rao@citrix.com>  wrote:
>>>>          
>> Proposal
>> The proposal is pretty simple: the eventchannel search will become a
>> three-level lookup table, with the leaf level being composed by shared
>> pages registered at boot time by the guests.
>> The bitmap working now as leaf (then called "second level") will work
>> alternatively as leaf level still (for older kernel) or for intermediate
>> level to address into a new array of shared pages (for newer kernels).
>> This leaves the possibility to reuse the existing mechanisms without
>> modifying its internals.
>>      
> While adding one level would seem to leave ample room, so did
> the originally 4096 originally. Therefore, even if unimplemented
> right now, I'd like the interface to allow for the guest to specify
> more levels.
>    

There is a big difference here. The third/new level will be composed of 
pages registered at guest installing so it can be expanded on demanded 
necessity. The second-level we have now doesn't work because it is stuck 
in the immutable ABI.
The only useful way to have another level would be in the case we think 
the second-level is not enough to address all the necessary bits in the 
third level in efficient way.

To make you an example, the first level is 64 bits while the second 
level can address 64 times the first level. The third level, to be 
on-par with the same ratio of the second level in terms of performance, 
would be large something like 4 pages. I think we are very far from 
reaching critical levels.

>    
>> More specifically, what needs to happen:
>> - Add new members to struct domain to handle an array of pages (to
>> contain the actual evtchn bitmaps), a further array of pages (to contain
>> the evtchn masks) and a control bit to say if it is subjective to the
>> new mode or not. Initially the arrays will be empty and the control bit
>> will be OFF.
>> - At init_platform() time, the guest must allocate the pages to compose
>> the 2 arrays and invoke a novel hypercall which, at big lines, does the
>> following:
>>     * Creates some pages to populate the new arrays in struct domain via
>> alloc_xenheap_pages()
>>      
> Why? The guest allocated the pages already. Just have the
> hypervisor map them (similar, but without the per-vCPU needs,
> to registering an alternative per-vCPU shared page). Whether
> it turns out more practical to require the guest to enforce
> certain restrictions (like the pages being contiguous and/or
> address restricted) is a secondary aspect.
>    

Actually what I propose seems to be what happens infact in the shared 
page case. Look at what arch_domain_create() and XENMEM_add_to_physmap 
hypercall do (in the XENMAPSPACE_shared_info case). I think this is the 
quicker way to get what we want.

>    
>>     * Recreates the mapping with the gpfn passed from the userland, using
>> basically guest_physmap_add_page()
>>      
> This would then be superfluous.
>
>    
>>     * Sets the control bit to ON
>> - Places that need to access to the actual leaf bit (like, for example,
>> xen_evtchn_do_upcall()) will need to double check the control bit. If it
>> is OFF they consider the second level as the leaf one, otherwise they
>> will do a further lookup to get the bit from the new array of pages.
>>      
> Just like for variable depth page tables - if at all possible, just
> make the accesses variable depth, so that all you need to track
> on a per-domain basis is the depth of the tree.
>    

I agree.

>    
>> Of course there are some nits to be decided yet, like, for example:
>> * How many pages should the new level have? We can start by populating
>> just one, for example
>>      
> Just let the guest specify this (and error if the number is too large).
>    

I agree.

>    
>> * Who should have really the knowledge of how many pages to allocate?
>> Likely the hypervisor should have a threshhold, but in general we may
>> want to have a posting mechanism to have the guest ask the hypervisor
>> before-hand and satisfy its actual request
>>      
> Same here (this is really the same with the previous item, if you
> follow the earlier suggestions).
>
>    
>> * How many bits should be indirected in the third-level by every single
>> bit in the second-level? (that is a really minor factor, but still).
>>      
> The tree should clearly be uniform (i.e. having a factor of
> BITS_PER_LONG per level), just like it is now. For 64-bit guests,
> this would mean 256k channels with 3 levels (32k for 32-bit
> guests).
>
> One aspect to also consider is migration - will the guest have to
> re-issue the extending hypercall, or will this be taken care of for
> it? If the former approach is chosen, would the guest be
> expected to deal with not being able to set up the extension
> again on the new host?
>    

I think this could be also handled with some trickery by switching the 
control bit off. I need to make an assessment on the races invovled 
because we are not any longer in the "domain startup" case.

> And another important (but implementation only) aspect not to
> forget is making domain_dump_evtchn_info() scale with the
> then much higher amount of dumping potentially to be done (i.e.
> not just extend it to cope with the count, but also make sure it
> properly allows softirqs to be handled, which in turn requires to
> not hold the event lock across the whole loop).
>
>    

I still didn't look into it, but thanks for pointing out.

Attilio

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 20 14:13:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Sep 2012 14:13:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TEhUm-00014e-Rf; Thu, 20 Sep 2012 14:12:48 +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 1TEhUl-00014X-4P
	for xen-devel@lists.xensource.com; Thu, 20 Sep 2012 14:12:47 +0000
Received: from [85.158.139.211:7308] by server-9.bemta-5.messagelabs.com id
	94/92-20529-E542B505; Thu, 20 Sep 2012 14:12:46 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-9.tower-206.messagelabs.com!1348150365!17823060!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTA0NTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23483 invoked from network); 20 Sep 2012 14:12:45 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Sep 2012 14:12:45 -0000
X-IronPort-AV: E=Sophos;i="4.80,453,1344211200"; d="scan'208";a="14659955"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Sep 2012 14:12: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.279.1; Thu, 20 Sep 2012 15:12:45 +0100
Date: Thu, 20 Sep 2012 15:11:56 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Arnd Bergmann <arnd@arndb.de>
In-Reply-To: <201209201327.45802.arnd@arndb.de>
Message-ID: <alpine.DEB.2.02.1209201501140.29232@kaball.uk.xensource.com>
References: <1348076658-4511-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<alpine.DEB.2.02.1209201240110.29232@kaball.uk.xensource.com>
	<1348143533.26501.28.camel@zakaz.uk.xensource.com>
	<201209201327.45802.arnd@arndb.de>
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>, Pawel Moll <pawel.moll@arm.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Xen-devel] [PATCH] arm: introduce a DTS for Xen unprivileged
 virtual 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 Thu, 20 Sep 2012, Arnd Bergmann wrote:
> On Thursday 20 September 2012, Ian Campbell wrote:
> > On Thu, 2012-09-20 at 12:56 +0100, Stefano Stabellini wrote:
> > > On Thu, 20 Sep 2012, Ian Campbell wrote:
> > > > On Wed, 2012-09-19 at 18:44 +0100, Stefano Stabellini wrote:
> 
> > > > > + compatible = "xen,xenvm-4.2", "arm,vexpress";
> > > > 
> > > > Is this second compatible thing actually true? We don't actually emulate
> > > > much (anything?) of what would be on a real vexpress motherboard.
> > > > 
> > > > "arm,vexpress" is used only in v2m.c and I don't think we want the
> > > > majority of that -- we don't provide any of the peripherals which it
> > > > registers.
> > > > 
> > > > I think the only things we might want out of that lot are the arch timer
> > > > and perhaps the uart0 (as a debug port).
> > > > 
> > > > I suspect we should have our own xen machine .c.
> > > > 
> > > > [...]
> > > 
> > > It is true that we are "arm,vexpress" compatible at the moment.
> > 
> > But we aren't, we don't emulate 90%+ of the actual hardware which
> > vexpress compatibility would actually imply.
> > 
> > Look in arch/arm/mach-vexpress/v2m.c, which is the only thing keyed off
> > this compat value -- it's full of stuff which we don't (and aren't going
> > to) implement.
> 
> It's not much different in the end, but I think I'd rather make the
> compatible list in the device tree "xen,xenvm-4.2", "xen,xenvm" without
> listing "arm,vexpress", but then adding "xen,xenvm" to the list of
> compatible devices in the vexpress kernel code.
> 
> The main difference is that if we decide to separate out the Linux
> code for Xen and vexpress later into distinct ports, we have the
> option to do that. vexpress will support multiplatform configurations
> in 3.7 anyway, so the idea of making all virtual platforms part of
> vexpress in order to be able to boot the same kernel on them is not
> all that important any more.

That's a very good idea, I'll do that.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 20 14:13:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Sep 2012 14:13:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TEhUm-00014e-Rf; Thu, 20 Sep 2012 14:12:48 +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 1TEhUl-00014X-4P
	for xen-devel@lists.xensource.com; Thu, 20 Sep 2012 14:12:47 +0000
Received: from [85.158.139.211:7308] by server-9.bemta-5.messagelabs.com id
	94/92-20529-E542B505; Thu, 20 Sep 2012 14:12:46 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-9.tower-206.messagelabs.com!1348150365!17823060!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTA0NTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23483 invoked from network); 20 Sep 2012 14:12:45 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Sep 2012 14:12:45 -0000
X-IronPort-AV: E=Sophos;i="4.80,453,1344211200"; d="scan'208";a="14659955"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Sep 2012 14:12: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.279.1; Thu, 20 Sep 2012 15:12:45 +0100
Date: Thu, 20 Sep 2012 15:11:56 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Arnd Bergmann <arnd@arndb.de>
In-Reply-To: <201209201327.45802.arnd@arndb.de>
Message-ID: <alpine.DEB.2.02.1209201501140.29232@kaball.uk.xensource.com>
References: <1348076658-4511-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<alpine.DEB.2.02.1209201240110.29232@kaball.uk.xensource.com>
	<1348143533.26501.28.camel@zakaz.uk.xensource.com>
	<201209201327.45802.arnd@arndb.de>
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>, Pawel Moll <pawel.moll@arm.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Xen-devel] [PATCH] arm: introduce a DTS for Xen unprivileged
 virtual 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 Thu, 20 Sep 2012, Arnd Bergmann wrote:
> On Thursday 20 September 2012, Ian Campbell wrote:
> > On Thu, 2012-09-20 at 12:56 +0100, Stefano Stabellini wrote:
> > > On Thu, 20 Sep 2012, Ian Campbell wrote:
> > > > On Wed, 2012-09-19 at 18:44 +0100, Stefano Stabellini wrote:
> 
> > > > > + compatible = "xen,xenvm-4.2", "arm,vexpress";
> > > > 
> > > > Is this second compatible thing actually true? We don't actually emulate
> > > > much (anything?) of what would be on a real vexpress motherboard.
> > > > 
> > > > "arm,vexpress" is used only in v2m.c and I don't think we want the
> > > > majority of that -- we don't provide any of the peripherals which it
> > > > registers.
> > > > 
> > > > I think the only things we might want out of that lot are the arch timer
> > > > and perhaps the uart0 (as a debug port).
> > > > 
> > > > I suspect we should have our own xen machine .c.
> > > > 
> > > > [...]
> > > 
> > > It is true that we are "arm,vexpress" compatible at the moment.
> > 
> > But we aren't, we don't emulate 90%+ of the actual hardware which
> > vexpress compatibility would actually imply.
> > 
> > Look in arch/arm/mach-vexpress/v2m.c, which is the only thing keyed off
> > this compat value -- it's full of stuff which we don't (and aren't going
> > to) implement.
> 
> It's not much different in the end, but I think I'd rather make the
> compatible list in the device tree "xen,xenvm-4.2", "xen,xenvm" without
> listing "arm,vexpress", but then adding "xen,xenvm" to the list of
> compatible devices in the vexpress kernel code.
> 
> The main difference is that if we decide to separate out the Linux
> code for Xen and vexpress later into distinct ports, we have the
> option to do that. vexpress will support multiplatform configurations
> in 3.7 anyway, so the idea of making all virtual platforms part of
> vexpress in order to be able to boot the same kernel on them is not
> all that important any more.

That's a very good idea, I'll do that.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 20 14:14:56 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Sep 2012 14:14:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TEhWc-0001DN-CE; Thu, 20 Sep 2012 14:14:42 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <oliver.chick@citrix.com>) id 1TEhWa-0001DH-VJ
	for xen-devel@lists.xen.org; Thu, 20 Sep 2012 14:14:41 +0000
Received: from [85.158.143.99:7779] by server-1.bemta-4.messagelabs.com id
	85/C9-05684-0D42B505; Thu, 20 Sep 2012 14:14:40 +0000
X-Env-Sender: oliver.chick@citrix.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1348150456!19905064!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTA0NTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10855 invoked from network); 20 Sep 2012 14:14:16 -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;
	20 Sep 2012 14:14:16 -0000
X-IronPort-AV: E=Sophos;i="4.80,453,1344211200"; d="scan'208";a="14659991"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Sep 2012 14:14:10 +0000
Received: from [10.80.2.50] (10.80.2.50) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Thu, 20 Sep 2012 15:14:09 +0100
Message-ID: <1348150422.24539.58.camel@oliverchick-Precision-WorkStation-T3400>
From: Oliver Chick <oliver.chick@citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Thu, 20 Sep 2012 15:13:42 +0100
In-Reply-To: <20120920134951.GC1998@localhost.localdomain>
References: <1348051887-21885-1-git-send-email-oliver.chick@citrix.com>
	<505AF126.2050806@citrix.com>
	<1348140637.24539.32.camel@oliverchick-Precision-WorkStation-T3400>
	<505B1EB9020000780009CA6E@nat28.tlf.novell.com>
	<20120920134951.GC1998@localhost.localdomain>
X-Mailer: Evolution 3.2.3-0ubuntu6 
MIME-Version: 1.0
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	David Vrabel <david.vrabel@citrix.com>, Jan Beulich <JBeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] Persistent grant maps for xen blk drivers
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-09-20 at 14:49 +0100, Konrad Rzeszutek Wilk wrote:
> On Thu, Sep 20, 2012 at 12:48:41PM +0100, Jan Beulich wrote:
> > >>> On 20.09.12 at 13:30, Oliver Chick <oliver.chick@citrix.com> wrote:
> > > The memory overhead, and fallback mode points are related:
> > > -Firstly, it turns out that the overhead is actually 2.75MB, not 11MB
> > > per device. I made a mistake (pointed out by Jan) as the maximum number
> > > of requests that can fit into a single-page ring is 64, not 256.
> > > -Clearly, this still scales linearly. So the problem of memory footprint
> > > will occur with more VMs, or block devices.
> > > -Whilst 2.75MB per device is probably acceptable (?), if we start using
> > > multipage rings, then we might not want to have
> > > BLKIF_MAX_PERS_REQUESTS_PER_DEVICE==__RING_SIZE, as this will cause the
> > > memory overhead to increase. This is why I have implemented the
> > > 'fallback' mode. With a multipage ring, it seems reasonable to want the
> > > first $x$ grefs seen by blkback to be treated as persistent, and any
> > > later ones to be non-persistent. Does that seem sensible?
> > 
> > From a resource usage pov, perhaps. But this will get the guest
> > entirely unpredictable performance. Plus I don't think 11Mb of
> 
> Wouldn't it fall back to the older performance?

I guess it would be a bit more complex than that. It would be worse than
the new performance because the grefs that get processed by the
'fallback' mode will cause TLB shootdowns. But any early grefs will
still be processed by the persistent mode, so won't have shootdowns.
Therefore, depending on the ratio of {persistent grants}:{non-persistent
grants), allocated by blkfront, the performance will be somewhere
inbetween the two extremes.

I guess that the choice is between
1) Compiling blk{front,back} with a pre-determined number of persistent
grants, and failing if this limit is exceeded. This seems rather
unflexible, as blk{front,back} must then both both use the same version,
or you will get failures.
2 (current setup)) Have a recommended maximum number of
persistently-mapped pages, and going into a 'fallback' mode if blkfront
exceeds this limit.
3) Having blkback inform blkfront on startup as to how many grefs it is
willing to persistently-map. We then hit the same question again though:
what should be do if blkfront ignores this limit?

> > _virtual_ space is unacceptable overhead in a 64-bit kernel. If
> > you really want/need this in a 32-bit one, then perhaps some
> > other alternatives would be needed (and persistent grants may
> > not be the right approach there in the first place).
> > 
> > Jan
> > 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 20 14:14:56 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Sep 2012 14:14:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TEhWc-0001DN-CE; Thu, 20 Sep 2012 14:14:42 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <oliver.chick@citrix.com>) id 1TEhWa-0001DH-VJ
	for xen-devel@lists.xen.org; Thu, 20 Sep 2012 14:14:41 +0000
Received: from [85.158.143.99:7779] by server-1.bemta-4.messagelabs.com id
	85/C9-05684-0D42B505; Thu, 20 Sep 2012 14:14:40 +0000
X-Env-Sender: oliver.chick@citrix.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1348150456!19905064!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTA0NTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10855 invoked from network); 20 Sep 2012 14:14:16 -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;
	20 Sep 2012 14:14:16 -0000
X-IronPort-AV: E=Sophos;i="4.80,453,1344211200"; d="scan'208";a="14659991"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Sep 2012 14:14:10 +0000
Received: from [10.80.2.50] (10.80.2.50) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Thu, 20 Sep 2012 15:14:09 +0100
Message-ID: <1348150422.24539.58.camel@oliverchick-Precision-WorkStation-T3400>
From: Oliver Chick <oliver.chick@citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Thu, 20 Sep 2012 15:13:42 +0100
In-Reply-To: <20120920134951.GC1998@localhost.localdomain>
References: <1348051887-21885-1-git-send-email-oliver.chick@citrix.com>
	<505AF126.2050806@citrix.com>
	<1348140637.24539.32.camel@oliverchick-Precision-WorkStation-T3400>
	<505B1EB9020000780009CA6E@nat28.tlf.novell.com>
	<20120920134951.GC1998@localhost.localdomain>
X-Mailer: Evolution 3.2.3-0ubuntu6 
MIME-Version: 1.0
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	David Vrabel <david.vrabel@citrix.com>, Jan Beulich <JBeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] Persistent grant maps for xen blk drivers
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-09-20 at 14:49 +0100, Konrad Rzeszutek Wilk wrote:
> On Thu, Sep 20, 2012 at 12:48:41PM +0100, Jan Beulich wrote:
> > >>> On 20.09.12 at 13:30, Oliver Chick <oliver.chick@citrix.com> wrote:
> > > The memory overhead, and fallback mode points are related:
> > > -Firstly, it turns out that the overhead is actually 2.75MB, not 11MB
> > > per device. I made a mistake (pointed out by Jan) as the maximum number
> > > of requests that can fit into a single-page ring is 64, not 256.
> > > -Clearly, this still scales linearly. So the problem of memory footprint
> > > will occur with more VMs, or block devices.
> > > -Whilst 2.75MB per device is probably acceptable (?), if we start using
> > > multipage rings, then we might not want to have
> > > BLKIF_MAX_PERS_REQUESTS_PER_DEVICE==__RING_SIZE, as this will cause the
> > > memory overhead to increase. This is why I have implemented the
> > > 'fallback' mode. With a multipage ring, it seems reasonable to want the
> > > first $x$ grefs seen by blkback to be treated as persistent, and any
> > > later ones to be non-persistent. Does that seem sensible?
> > 
> > From a resource usage pov, perhaps. But this will get the guest
> > entirely unpredictable performance. Plus I don't think 11Mb of
> 
> Wouldn't it fall back to the older performance?

I guess it would be a bit more complex than that. It would be worse than
the new performance because the grefs that get processed by the
'fallback' mode will cause TLB shootdowns. But any early grefs will
still be processed by the persistent mode, so won't have shootdowns.
Therefore, depending on the ratio of {persistent grants}:{non-persistent
grants), allocated by blkfront, the performance will be somewhere
inbetween the two extremes.

I guess that the choice is between
1) Compiling blk{front,back} with a pre-determined number of persistent
grants, and failing if this limit is exceeded. This seems rather
unflexible, as blk{front,back} must then both both use the same version,
or you will get failures.
2 (current setup)) Have a recommended maximum number of
persistently-mapped pages, and going into a 'fallback' mode if blkfront
exceeds this limit.
3) Having blkback inform blkfront on startup as to how many grefs it is
willing to persistently-map. We then hit the same question again though:
what should be do if blkfront ignores this limit?

> > _virtual_ space is unacceptable overhead in a 64-bit kernel. If
> > you really want/need this in a 32-bit one, then perhaps some
> > other alternatives would be needed (and persistent grants may
> > not be the right approach there in the first place).
> > 
> > Jan
> > 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 20 14:15:41 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Sep 2012 14: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 1TEhXJ-0001HL-Qm; Thu, 20 Sep 2012 14:15:25 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wdauchy@gmail.com>) id 1TEhXI-0001H8-IS
	for xen-devel@lists.xensource.com; Thu, 20 Sep 2012 14:15:24 +0000
Received: from [85.158.137.99:23870] by server-2.bemta-3.messagelabs.com id
	26/7D-04862-BF42B505; Thu, 20 Sep 2012 14:15:23 +0000
X-Env-Sender: wdauchy@gmail.com
X-Msg-Ref: server-3.tower-217.messagelabs.com!1348150521!13413340!1
X-Originating-IP: [209.85.160.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27600 invoked from network); 20 Sep 2012 14:15:23 -0000
Received: from mail-pb0-f43.google.com (HELO mail-pb0-f43.google.com)
	(209.85.160.43)
	by server-3.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Sep 2012 14:15:23 -0000
Received: by pbbrq2 with SMTP id rq2so6711438pbb.30
	for <xen-devel@lists.xensource.com>;
	Thu, 20 Sep 2012 07:15: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;
	bh=jSGFfr5SHibVnNjsdSISFOROSnMKEtk/xjzcdR8HGVA=;
	b=Nz66p1zGS+4kPXK1grjZY5VJtAtEKDEq3o6N+4SaGf7Rmatj4Ti9FULSMGlPgkReln
	XLHo1mPDRdumxDJnNAvQU0JhTDUD65MX0zcCvX4amIP9wqiNeE3AHtuIhZIDNxP9odQt
	Bzo4oifeDsV7XA2P/VS2lt3m2nDWaJ2UWlDg4GdqqAtESBjyOVu4oxFI4A1y2YgbNcNt
	bPENfVkQF41/eNLjRmLRwsTnGoDNEFK24j9jEE5H0iuDB9w0TQtJe6hI3Z9p5rHR1vzj
	cNqBakiVksBca66uJ5cyfLKJq9TH2jXhMWlQXhZTi3nhEI+QsZFenVTy/I+9pS0f+CYO
	pm5A==
Received: by 10.66.78.6 with SMTP id x6mr5644105paw.41.1348150520965; Thu, 20
	Sep 2012 07:15:20 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.68.135.42 with HTTP; Thu, 20 Sep 2012 07:15:00 -0700 (PDT)
In-Reply-To: <20120920134851.GB1998@localhost.localdomain>
References: <CAJ75kXZm-BqWdL2O41XkSE1VCdd4ruW=+CqDmR1b3=701RnXmw@mail.gmail.com>
	<20120918133650.GC12053@phenom.dumpdata.com>
	<CAJ75kXZEaCj4Jqs_qm46d7U-s1C2hkAONs8c5Audrw2c3X=nBA@mail.gmail.com>
	<20120920134851.GB1998@localhost.localdomain>
From: William Dauchy <wdauchy@gmail.com>
Date: Thu, 20 Sep 2012 16:15:00 +0200
Message-ID: <CAJ75kXZ0depUJF_h0yok-r4aL0TBGnqTpW_PKT4Q7P1_6R4X2A@mail.gmail.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] Error getting mfn
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Sep 20, 2012 at 3:48 PM, Konrad Rzeszutek Wilk
<konrad.wilk@oracle.com> wrote:
> I really need to see the Linux command line as well. I am not
> sure why I am not seeing it thought? What are your Linux commnad
> line parameters? Can you do 'cat /proc/cmdline' after Linux has booted?
> (if it has booted).

sync_console loglvl=all dom0_max_vcpus=1 verbose=y console=hvc0 debug
loglevel=8
did I forgot something?
-- 
William

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 20 14:15:41 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Sep 2012 14: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 1TEhXJ-0001HL-Qm; Thu, 20 Sep 2012 14:15:25 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wdauchy@gmail.com>) id 1TEhXI-0001H8-IS
	for xen-devel@lists.xensource.com; Thu, 20 Sep 2012 14:15:24 +0000
Received: from [85.158.137.99:23870] by server-2.bemta-3.messagelabs.com id
	26/7D-04862-BF42B505; Thu, 20 Sep 2012 14:15:23 +0000
X-Env-Sender: wdauchy@gmail.com
X-Msg-Ref: server-3.tower-217.messagelabs.com!1348150521!13413340!1
X-Originating-IP: [209.85.160.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27600 invoked from network); 20 Sep 2012 14:15:23 -0000
Received: from mail-pb0-f43.google.com (HELO mail-pb0-f43.google.com)
	(209.85.160.43)
	by server-3.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Sep 2012 14:15:23 -0000
Received: by pbbrq2 with SMTP id rq2so6711438pbb.30
	for <xen-devel@lists.xensource.com>;
	Thu, 20 Sep 2012 07:15: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;
	bh=jSGFfr5SHibVnNjsdSISFOROSnMKEtk/xjzcdR8HGVA=;
	b=Nz66p1zGS+4kPXK1grjZY5VJtAtEKDEq3o6N+4SaGf7Rmatj4Ti9FULSMGlPgkReln
	XLHo1mPDRdumxDJnNAvQU0JhTDUD65MX0zcCvX4amIP9wqiNeE3AHtuIhZIDNxP9odQt
	Bzo4oifeDsV7XA2P/VS2lt3m2nDWaJ2UWlDg4GdqqAtESBjyOVu4oxFI4A1y2YgbNcNt
	bPENfVkQF41/eNLjRmLRwsTnGoDNEFK24j9jEE5H0iuDB9w0TQtJe6hI3Z9p5rHR1vzj
	cNqBakiVksBca66uJ5cyfLKJq9TH2jXhMWlQXhZTi3nhEI+QsZFenVTy/I+9pS0f+CYO
	pm5A==
Received: by 10.66.78.6 with SMTP id x6mr5644105paw.41.1348150520965; Thu, 20
	Sep 2012 07:15:20 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.68.135.42 with HTTP; Thu, 20 Sep 2012 07:15:00 -0700 (PDT)
In-Reply-To: <20120920134851.GB1998@localhost.localdomain>
References: <CAJ75kXZm-BqWdL2O41XkSE1VCdd4ruW=+CqDmR1b3=701RnXmw@mail.gmail.com>
	<20120918133650.GC12053@phenom.dumpdata.com>
	<CAJ75kXZEaCj4Jqs_qm46d7U-s1C2hkAONs8c5Audrw2c3X=nBA@mail.gmail.com>
	<20120920134851.GB1998@localhost.localdomain>
From: William Dauchy <wdauchy@gmail.com>
Date: Thu, 20 Sep 2012 16:15:00 +0200
Message-ID: <CAJ75kXZ0depUJF_h0yok-r4aL0TBGnqTpW_PKT4Q7P1_6R4X2A@mail.gmail.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] Error getting mfn
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Sep 20, 2012 at 3:48 PM, Konrad Rzeszutek Wilk
<konrad.wilk@oracle.com> wrote:
> I really need to see the Linux command line as well. I am not
> sure why I am not seeing it thought? What are your Linux commnad
> line parameters? Can you do 'cat /proc/cmdline' after Linux has booted?
> (if it has booted).

sync_console loglvl=all dom0_max_vcpus=1 verbose=y console=hvc0 debug
loglevel=8
did I forgot something?
-- 
William

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 20 14:24:53 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Sep 2012 14: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 1TEhgF-0001oE-FG; Thu, 20 Sep 2012 14:24:39 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <pawel.moll@arm.com>) id 1TEhgE-0001o9-0S
	for xen-devel@lists.xensource.com; Thu, 20 Sep 2012 14:24:38 +0000
Received: from [85.158.138.51:51902] by server-12.bemta-3.messagelabs.com id
	B8/90-10384-5272B505; Thu, 20 Sep 2012 14:24:37 +0000
X-Env-Sender: pawel.moll@arm.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1348151076!12669047!1
X-Originating-IP: [91.220.42.44]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogOTEuMjIwLjQyLjQ0ID0+IDI5ODkzOA==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25894 invoked from network); 20 Sep 2012 14:24:36 -0000
Received: from service87.mimecast.com (HELO service87.mimecast.com)
	(91.220.42.44) by server-13.tower-174.messagelabs.com with SMTP;
	20 Sep 2012 14:24:36 -0000
Received: from cam-owa1.Emea.Arm.com (fw-tnat.cambridge.arm.com
	[217.140.96.21]) by service87.mimecast.com;
	Thu, 20 Sep 2012 15:24:35 +0100
Received: from [10.1.205.42] ([10.1.255.212]) by cam-owa1.Emea.Arm.com with
	Microsoft SMTPSVC(6.0.3790.0); Thu, 20 Sep 2012 15:24:34 +0100
Message-ID: <1348151074.11116.126.camel@hornet>
From: Pawel Moll <pawel.moll@arm.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Thu, 20 Sep 2012 15:24:34 +0100
In-Reply-To: <alpine.DEB.2.02.1209201501140.29232@kaball.uk.xensource.com>
References: <1348076658-4511-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<alpine.DEB.2.02.1209201240110.29232@kaball.uk.xensource.com>
	<1348143533.26501.28.camel@zakaz.uk.xensource.com>
	<201209201327.45802.arnd@arndb.de>
	<alpine.DEB.2.02.1209201501140.29232@kaball.uk.xensource.com>
X-Mailer: Evolution 3.2.3-0ubuntu6
Mime-Version: 1.0
X-OriginalArrivalTime: 20 Sep 2012 14:24:35.0028 (UTC)
	FILETIME=[A88CD940:01CD973B]
X-MC-Unique: 112092015243509501
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, Arnd Bergmann <arnd@arndb.de>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Xen-devel] [PATCH] arm: introduce a DTS for Xen unprivileged
 virtual 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="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gVGh1LCAyMDEyLTA5LTIwIGF0IDE1OjExICswMTAwLCBTdGVmYW5vIFN0YWJlbGxpbmkgd3Jv
dGU6Cj4gT24gVGh1LCAyMCBTZXAgMjAxMiwgQXJuZCBCZXJnbWFubiB3cm90ZToKPiA+IEl0J3Mg
bm90IG11Y2ggZGlmZmVyZW50IGluIHRoZSBlbmQsIGJ1dCBJIHRoaW5rIEknZCByYXRoZXIgbWFr
ZSB0aGUKPiA+IGNvbXBhdGlibGUgbGlzdCBpbiB0aGUgZGV2aWNlIHRyZWUgInhlbix4ZW52bS00
LjIiLCAieGVuLHhlbnZtIiB3aXRob3V0Cj4gPiBsaXN0aW5nICJhcm0sdmV4cHJlc3MiLCBidXQg
dGhlbiBhZGRpbmcgInhlbix4ZW52bSIgdG8gdGhlIGxpc3Qgb2YKPiA+IGNvbXBhdGlibGUgZGV2
aWNlcyBpbiB0aGUgdmV4cHJlc3Mga2VybmVsIGNvZGUuCj4KPiBUaGF0J3MgYSB2ZXJ5IGdvb2Qg
aWRlYSwgSSdsbCBkbyB0aGF0LgoKWWVwLCB0aGlzIHdvdWxkIHdvcmsgd2l0aCBtZSBhcyB3ZWxs
LiBBbmQgSSdtIHN1cmUgd2UgY2FuIG1ha2UgdGhlCiJhcm0sdmV4cHJlc3MsbWVtb3J5LW1hcCIg
Yml0IHVubmVjZXNzYXJ5IGFzIHdlbGwgLSBoYXZlIGEgbG9vayBpbnRvIGl0LAphbmQgSSdsbCBo
ZWxwIHlvdSBhcyBtdWNoIGFzIEkgY2FuLgoKQW5kIHRoZW4sIGlmIHlvdXIgInJlZmVyZW5jZSIg
RFRTIGlzIHRvIGJlIG1lcmdlZCwgaXQgd29uJ3QgYmUgY2FsbGVkCnZleHByZXNzLSouZHRzLCBz
byBJIHdpbGwgbm90IGhhdmUgdG8gZGVjaWRlIHdoZXRoZXIgdG8gdGFrZSBpdCBpbiBvcgpub3Qg
Oi0pCgpDaGVlcnMhCgpQYXdlxYIKCgoKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhl
bi5vcmcKaHR0cDovL2xpc3RzLnhlbi5vcmcveGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Thu Sep 20 14:24:53 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Sep 2012 14: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 1TEhgF-0001oE-FG; Thu, 20 Sep 2012 14:24:39 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <pawel.moll@arm.com>) id 1TEhgE-0001o9-0S
	for xen-devel@lists.xensource.com; Thu, 20 Sep 2012 14:24:38 +0000
Received: from [85.158.138.51:51902] by server-12.bemta-3.messagelabs.com id
	B8/90-10384-5272B505; Thu, 20 Sep 2012 14:24:37 +0000
X-Env-Sender: pawel.moll@arm.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1348151076!12669047!1
X-Originating-IP: [91.220.42.44]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogOTEuMjIwLjQyLjQ0ID0+IDI5ODkzOA==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25894 invoked from network); 20 Sep 2012 14:24:36 -0000
Received: from service87.mimecast.com (HELO service87.mimecast.com)
	(91.220.42.44) by server-13.tower-174.messagelabs.com with SMTP;
	20 Sep 2012 14:24:36 -0000
Received: from cam-owa1.Emea.Arm.com (fw-tnat.cambridge.arm.com
	[217.140.96.21]) by service87.mimecast.com;
	Thu, 20 Sep 2012 15:24:35 +0100
Received: from [10.1.205.42] ([10.1.255.212]) by cam-owa1.Emea.Arm.com with
	Microsoft SMTPSVC(6.0.3790.0); Thu, 20 Sep 2012 15:24:34 +0100
Message-ID: <1348151074.11116.126.camel@hornet>
From: Pawel Moll <pawel.moll@arm.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Thu, 20 Sep 2012 15:24:34 +0100
In-Reply-To: <alpine.DEB.2.02.1209201501140.29232@kaball.uk.xensource.com>
References: <1348076658-4511-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<alpine.DEB.2.02.1209201240110.29232@kaball.uk.xensource.com>
	<1348143533.26501.28.camel@zakaz.uk.xensource.com>
	<201209201327.45802.arnd@arndb.de>
	<alpine.DEB.2.02.1209201501140.29232@kaball.uk.xensource.com>
X-Mailer: Evolution 3.2.3-0ubuntu6
Mime-Version: 1.0
X-OriginalArrivalTime: 20 Sep 2012 14:24:35.0028 (UTC)
	FILETIME=[A88CD940:01CD973B]
X-MC-Unique: 112092015243509501
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, Arnd Bergmann <arnd@arndb.de>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Xen-devel] [PATCH] arm: introduce a DTS for Xen unprivileged
 virtual 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="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gVGh1LCAyMDEyLTA5LTIwIGF0IDE1OjExICswMTAwLCBTdGVmYW5vIFN0YWJlbGxpbmkgd3Jv
dGU6Cj4gT24gVGh1LCAyMCBTZXAgMjAxMiwgQXJuZCBCZXJnbWFubiB3cm90ZToKPiA+IEl0J3Mg
bm90IG11Y2ggZGlmZmVyZW50IGluIHRoZSBlbmQsIGJ1dCBJIHRoaW5rIEknZCByYXRoZXIgbWFr
ZSB0aGUKPiA+IGNvbXBhdGlibGUgbGlzdCBpbiB0aGUgZGV2aWNlIHRyZWUgInhlbix4ZW52bS00
LjIiLCAieGVuLHhlbnZtIiB3aXRob3V0Cj4gPiBsaXN0aW5nICJhcm0sdmV4cHJlc3MiLCBidXQg
dGhlbiBhZGRpbmcgInhlbix4ZW52bSIgdG8gdGhlIGxpc3Qgb2YKPiA+IGNvbXBhdGlibGUgZGV2
aWNlcyBpbiB0aGUgdmV4cHJlc3Mga2VybmVsIGNvZGUuCj4KPiBUaGF0J3MgYSB2ZXJ5IGdvb2Qg
aWRlYSwgSSdsbCBkbyB0aGF0LgoKWWVwLCB0aGlzIHdvdWxkIHdvcmsgd2l0aCBtZSBhcyB3ZWxs
LiBBbmQgSSdtIHN1cmUgd2UgY2FuIG1ha2UgdGhlCiJhcm0sdmV4cHJlc3MsbWVtb3J5LW1hcCIg
Yml0IHVubmVjZXNzYXJ5IGFzIHdlbGwgLSBoYXZlIGEgbG9vayBpbnRvIGl0LAphbmQgSSdsbCBo
ZWxwIHlvdSBhcyBtdWNoIGFzIEkgY2FuLgoKQW5kIHRoZW4sIGlmIHlvdXIgInJlZmVyZW5jZSIg
RFRTIGlzIHRvIGJlIG1lcmdlZCwgaXQgd29uJ3QgYmUgY2FsbGVkCnZleHByZXNzLSouZHRzLCBz
byBJIHdpbGwgbm90IGhhdmUgdG8gZGVjaWRlIHdoZXRoZXIgdG8gdGFrZSBpdCBpbiBvcgpub3Qg
Oi0pCgpDaGVlcnMhCgpQYXdlxYIKCgoKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhl
bi5vcmcKaHR0cDovL2xpc3RzLnhlbi5vcmcveGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Thu Sep 20 14:38:16 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Sep 2012 14:38:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TEhtA-00027z-QL; Thu, 20 Sep 2012 14:38:00 +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 1TEht9-00027u-RN
	for xen-devel@lists.xen.org; Thu, 20 Sep 2012 14:38:00 +0000
Received: from [85.158.139.211:57669] by server-3.bemta-5.messagelabs.com id
	F3/BC-21836-64A2B505; Thu, 20 Sep 2012 14:37:58 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-3.tower-206.messagelabs.com!1348151877!19327688!1
X-Originating-IP: [74.125.83.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26414 invoked from network); 20 Sep 2012 14:37:58 -0000
Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com)
	(74.125.83.45)
	by server-3.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Sep 2012 14:37:58 -0000
Received: by eeke53 with SMTP id e53so1064968eek.32
	for <xen-devel@lists.xen.org>; Thu, 20 Sep 2012 07:37:57 -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=P7/4zmYoz1HhBnc3yxqZE2uasM4HETYE+n139UsKDDU=;
	b=FxAygY/Y1QvFTh3IzBtDPf1KbsAlCqXJ1a2tEfRbkG9Qg93CYgfOSMVjYQhlCJBZ1/
	HI058csWV/Oh4xruSv3yhZv3ZhwSo4bpz1N61st7p/SfJP8wWAi+vueyEvVpNFzqbpSx
	OLCZ5aQKVlt1v7QfZcKR0oDRUDjP8HSiXB0ODgkxjeMIdY6HnDU6g3rFw+6PW8XH0Gs/
	m3WVQQLFXzWTd0zdtRzi6pHwn1vpKAgRfGMzv7+7xy2AB/Hr1VrXEECo/nNNQRGzIMY1
	2OUsQy6zYrtbKd1YIXDbONir7Cnsiv9UgWseHXf+FRu8WwSTkl3LplC0Hw0MP6suov8F
	zyNg==
MIME-Version: 1.0
Received: by 10.14.212.72 with SMTP id x48mr2462683eeo.40.1348151877552; Thu,
	20 Sep 2012 07:37:57 -0700 (PDT)
Received: by 10.14.215.195 with HTTP; Thu, 20 Sep 2012 07:37:57 -0700 (PDT)
In-Reply-To: <505B1DD1020000780009CA59@nat28.tlf.novell.com>
References: <CAFLBxZYtmJ_bKFb90r45=C4Pq1-oe5Fy=eygSsQf4BcGj3EqGA@mail.gmail.com>
	<505ADBCF020000780009C7BE@nat28.tlf.novell.com>
	<CAFLBxZZAYBjYxX4K_LBE+dvkH8D9rfeAy538n4ACcQr=+bew8g@mail.gmail.com>
	<505B197D020000780009C9FB@nat28.tlf.novell.com>
	<505AFF10.7060107@eu.citrix.com>
	<505B1DD1020000780009CA59@nat28.tlf.novell.com>
Date: Thu, 20 Sep 2012 15:37:57 +0100
X-Google-Sender-Auth: p2kEpvr-D8tzmRulsarbhUwDS08
Message-ID: <CAFLBxZb4LV2n7T2xxaJxC53sr9ta-Zb4r6am3fSHNPik0DL0PQ@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.3 development 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 Thu, Sep 20, 2012 at 12:44 PM, Jan Beulich <JBeulich@suse.com> wrote:
>>>> On 20.09.12 at 13:33, George Dunlap <george.dunlap@eu.citrix.com> wrote:
>> Right -- well they were added to the list because you said you were
>> going to be working on them; so if you're not, shall I just take them off?
>
> I think keeping them un-owned would be preferable, to draw
> people's attention. The console situation really needs
> improvement; the EHCI debug port thing was just a first step.
> But in the end it's you to decide, as you'll have to maintain the
> list...

OK, so what you mean is, "I think these are fairly important, and
Someone(TM) should do them sometime"?  It seems like more effective
than just having them on this list without an owner would be for you
to advertise that and ask if anyone can help, either by doing it
themselves or lending you the necessary hardware.

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 20 14:38:16 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Sep 2012 14:38:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TEhtA-00027z-QL; Thu, 20 Sep 2012 14:38:00 +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 1TEht9-00027u-RN
	for xen-devel@lists.xen.org; Thu, 20 Sep 2012 14:38:00 +0000
Received: from [85.158.139.211:57669] by server-3.bemta-5.messagelabs.com id
	F3/BC-21836-64A2B505; Thu, 20 Sep 2012 14:37:58 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-3.tower-206.messagelabs.com!1348151877!19327688!1
X-Originating-IP: [74.125.83.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26414 invoked from network); 20 Sep 2012 14:37:58 -0000
Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com)
	(74.125.83.45)
	by server-3.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Sep 2012 14:37:58 -0000
Received: by eeke53 with SMTP id e53so1064968eek.32
	for <xen-devel@lists.xen.org>; Thu, 20 Sep 2012 07:37:57 -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=P7/4zmYoz1HhBnc3yxqZE2uasM4HETYE+n139UsKDDU=;
	b=FxAygY/Y1QvFTh3IzBtDPf1KbsAlCqXJ1a2tEfRbkG9Qg93CYgfOSMVjYQhlCJBZ1/
	HI058csWV/Oh4xruSv3yhZv3ZhwSo4bpz1N61st7p/SfJP8wWAi+vueyEvVpNFzqbpSx
	OLCZ5aQKVlt1v7QfZcKR0oDRUDjP8HSiXB0ODgkxjeMIdY6HnDU6g3rFw+6PW8XH0Gs/
	m3WVQQLFXzWTd0zdtRzi6pHwn1vpKAgRfGMzv7+7xy2AB/Hr1VrXEECo/nNNQRGzIMY1
	2OUsQy6zYrtbKd1YIXDbONir7Cnsiv9UgWseHXf+FRu8WwSTkl3LplC0Hw0MP6suov8F
	zyNg==
MIME-Version: 1.0
Received: by 10.14.212.72 with SMTP id x48mr2462683eeo.40.1348151877552; Thu,
	20 Sep 2012 07:37:57 -0700 (PDT)
Received: by 10.14.215.195 with HTTP; Thu, 20 Sep 2012 07:37:57 -0700 (PDT)
In-Reply-To: <505B1DD1020000780009CA59@nat28.tlf.novell.com>
References: <CAFLBxZYtmJ_bKFb90r45=C4Pq1-oe5Fy=eygSsQf4BcGj3EqGA@mail.gmail.com>
	<505ADBCF020000780009C7BE@nat28.tlf.novell.com>
	<CAFLBxZZAYBjYxX4K_LBE+dvkH8D9rfeAy538n4ACcQr=+bew8g@mail.gmail.com>
	<505B197D020000780009C9FB@nat28.tlf.novell.com>
	<505AFF10.7060107@eu.citrix.com>
	<505B1DD1020000780009CA59@nat28.tlf.novell.com>
Date: Thu, 20 Sep 2012 15:37:57 +0100
X-Google-Sender-Auth: p2kEpvr-D8tzmRulsarbhUwDS08
Message-ID: <CAFLBxZb4LV2n7T2xxaJxC53sr9ta-Zb4r6am3fSHNPik0DL0PQ@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.3 development 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 Thu, Sep 20, 2012 at 12:44 PM, Jan Beulich <JBeulich@suse.com> wrote:
>>>> On 20.09.12 at 13:33, George Dunlap <george.dunlap@eu.citrix.com> wrote:
>> Right -- well they were added to the list because you said you were
>> going to be working on them; so if you're not, shall I just take them off?
>
> I think keeping them un-owned would be preferable, to draw
> people's attention. The console situation really needs
> improvement; the EHCI debug port thing was just a first step.
> But in the end it's you to decide, as you'll have to maintain the
> list...

OK, so what you mean is, "I think these are fairly important, and
Someone(TM) should do them sometime"?  It seems like more effective
than just having them on this list without an owner would be for you
to advertise that and ask if anyone can help, either by doing it
themselves or lending you the necessary hardware.

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 20 15:23:52 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Sep 2012 15: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 1TEibE-0002T9-UB; Thu, 20 Sep 2012 15:23:32 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andreslc@gridcentric.ca>) id 1TEibC-0002Sy-PQ
	for xen-devel@lists.xen.org; Thu, 20 Sep 2012 15:23:30 +0000
Received: from [85.158.143.99:55650] by server-1.bemta-4.messagelabs.com id
	88/15-05684-2F43B505; Thu, 20 Sep 2012 15:23:30 +0000
X-Env-Sender: andreslc@gridcentric.ca
X-Msg-Ref: server-16.tower-216.messagelabs.com!1348154608!19915916!1
X-Originating-IP: [209.85.161.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21299 invoked from network); 20 Sep 2012 15:23:29 -0000
Received: from mail-gg0-f173.google.com (HELO mail-gg0-f173.google.com)
	(209.85.161.173)
	by server-16.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Sep 2012 15:23:29 -0000
Received: by ggna5 with SMTP id a5so728235ggn.32
	for <xen-devel@lists.xen.org>; Thu, 20 Sep 2012 08:23:28 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=from:content-type:content-transfer-encoding:subject:date:message-id
	:cc:to:mime-version:x-mailer:x-gm-message-state;
	bh=zk3hSX90dG862G4XDVzZfMQMDRMeWX2VMLc/9jHgl/s=;
	b=G3gEgbODkAtqZKPtlqvnpMrfdDrocjnjBqfFF6FY+Ex1XmFJ50mFfBxvPGTedVVJvq
	EoTfvwz0DmFw4xF9qDjFhB+kW5NT2tTHmlh9GJsGq/2+68WSXzFo+JJtxBYjR4DXL07j
	6NULXsUKlgD3VCRZBKTmnXxDxGogDDdcP9IIHKfO1W5z5mwLcxTw5ocLzLgdJSr0H/qT
	FVrmGB5gkEqV9cRDmPHhk0AnaLouAxLlxWd0ZT2TLZrRt6owxr3LICopVParwpGno8Nn
	u73Pjcr2T1UBB8/R1gaU36eo5P+fcg4QXt9gbH1EGCKmxk8AcpkJBHVJsrPckcWWflYv
	UATw==
Received: by 10.236.189.68 with SMTP id b44mr2021805yhn.82.1348154608077;
	Thu, 20 Sep 2012 08:23:28 -0700 (PDT)
Received: from [192.168.7.210] ([206.223.182.18])
	by mx.google.com with ESMTPS id h27sm8992526yhk.10.2012.09.20.08.23.27
	(version=TLSv1/SSLv3 cipher=OTHER);
	Thu, 20 Sep 2012 08:23:27 -0700 (PDT)
From: Andres Lagar-Cavilla <andreslc@gridcentric.ca>
Date: Thu, 20 Sep 2012 11:23:41 -0400
Message-Id: <E269205F-457F-4503-BB86-11C0EFA15CEC@gridcentric.ca>
To: xen-devel <xen-devel@lists.xen.org>
Mime-Version: 1.0 (Apple Message framework v1278)
X-Mailer: Apple Mail (2.1278)
X-Gm-Message-State: ALoCoQms5pvum/YASy5ys7OthxfGQOG8t1xhcZh2Mwozz28stHRd3xaJ9r5pdAYVqU/dDhg0nisF
Cc: Keir Fraser <keir@xen.org>, Jan Beulich <JBeulich@suse.com>
Subject: [Xen-devel] Backport request: 25914:cd2a831d0a41 to
	xen-4.2-testing.hg
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

It seems back porting has started. I would have asked for a few others, but I've been beaten to the punch!

Thanks a lot
Andres
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 20 15:23:52 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Sep 2012 15: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 1TEibE-0002T9-UB; Thu, 20 Sep 2012 15:23:32 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andreslc@gridcentric.ca>) id 1TEibC-0002Sy-PQ
	for xen-devel@lists.xen.org; Thu, 20 Sep 2012 15:23:30 +0000
Received: from [85.158.143.99:55650] by server-1.bemta-4.messagelabs.com id
	88/15-05684-2F43B505; Thu, 20 Sep 2012 15:23:30 +0000
X-Env-Sender: andreslc@gridcentric.ca
X-Msg-Ref: server-16.tower-216.messagelabs.com!1348154608!19915916!1
X-Originating-IP: [209.85.161.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21299 invoked from network); 20 Sep 2012 15:23:29 -0000
Received: from mail-gg0-f173.google.com (HELO mail-gg0-f173.google.com)
	(209.85.161.173)
	by server-16.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Sep 2012 15:23:29 -0000
Received: by ggna5 with SMTP id a5so728235ggn.32
	for <xen-devel@lists.xen.org>; Thu, 20 Sep 2012 08:23:28 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=from:content-type:content-transfer-encoding:subject:date:message-id
	:cc:to:mime-version:x-mailer:x-gm-message-state;
	bh=zk3hSX90dG862G4XDVzZfMQMDRMeWX2VMLc/9jHgl/s=;
	b=G3gEgbODkAtqZKPtlqvnpMrfdDrocjnjBqfFF6FY+Ex1XmFJ50mFfBxvPGTedVVJvq
	EoTfvwz0DmFw4xF9qDjFhB+kW5NT2tTHmlh9GJsGq/2+68WSXzFo+JJtxBYjR4DXL07j
	6NULXsUKlgD3VCRZBKTmnXxDxGogDDdcP9IIHKfO1W5z5mwLcxTw5ocLzLgdJSr0H/qT
	FVrmGB5gkEqV9cRDmPHhk0AnaLouAxLlxWd0ZT2TLZrRt6owxr3LICopVParwpGno8Nn
	u73Pjcr2T1UBB8/R1gaU36eo5P+fcg4QXt9gbH1EGCKmxk8AcpkJBHVJsrPckcWWflYv
	UATw==
Received: by 10.236.189.68 with SMTP id b44mr2021805yhn.82.1348154608077;
	Thu, 20 Sep 2012 08:23:28 -0700 (PDT)
Received: from [192.168.7.210] ([206.223.182.18])
	by mx.google.com with ESMTPS id h27sm8992526yhk.10.2012.09.20.08.23.27
	(version=TLSv1/SSLv3 cipher=OTHER);
	Thu, 20 Sep 2012 08:23:27 -0700 (PDT)
From: Andres Lagar-Cavilla <andreslc@gridcentric.ca>
Date: Thu, 20 Sep 2012 11:23:41 -0400
Message-Id: <E269205F-457F-4503-BB86-11C0EFA15CEC@gridcentric.ca>
To: xen-devel <xen-devel@lists.xen.org>
Mime-Version: 1.0 (Apple Message framework v1278)
X-Mailer: Apple Mail (2.1278)
X-Gm-Message-State: ALoCoQms5pvum/YASy5ys7OthxfGQOG8t1xhcZh2Mwozz28stHRd3xaJ9r5pdAYVqU/dDhg0nisF
Cc: Keir Fraser <keir@xen.org>, Jan Beulich <JBeulich@suse.com>
Subject: [Xen-devel] Backport request: 25914:cd2a831d0a41 to
	xen-4.2-testing.hg
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

It seems back porting has started. I would have asked for a few others, but I've been beaten to the punch!

Thanks a lot
Andres
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 20 15:23:53 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Sep 2012 15:23: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 1TEib7-0002Sm-Hf; Thu, 20 Sep 2012 15:23:25 +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 1TEib6-0002Sh-De
	for xen-devel@lists.xensource.com; Thu, 20 Sep 2012 15:23:24 +0000
Received: from [85.158.143.99:22890] by server-1.bemta-4.messagelabs.com id
	31/F4-05684-BE43B505; Thu, 20 Sep 2012 15:23:23 +0000
X-Env-Sender: Christoph.Egger@amd.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1348154601!25862061!1
X-Originating-IP: [216.32.181.181]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29588 invoked from network); 20 Sep 2012 15:23:22 -0000
Received: from ch1ehsobe001.messaging.microsoft.com (HELO
	ch1outboundpool.messaging.microsoft.com) (216.32.181.181)
	by server-4.tower-216.messagelabs.com with AES128-SHA encrypted SMTP;
	20 Sep 2012 15:23:22 -0000
Received: from mail73-ch1-R.bigfish.com (10.43.68.232) by
	CH1EHSOBE014.bigfish.com (10.43.70.64) with Microsoft SMTP Server id
	14.1.225.23; Thu, 20 Sep 2012 15:23:21 +0000
Received: from mail73-ch1 (localhost [127.0.0.1])	by mail73-ch1-R.bigfish.com
	(Postfix) with ESMTP id 5716360148;
	Thu, 20 Sep 2012 15:23:21 +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: -2
X-BigFish: VPS-2(zzbb2dI98dI1432Id6f1izz1202h1d1ah1d2ahzz8275bhz2dh668h839hd25he5bhf0ah107ah1288h12a5h12a9h12bdh1155h)
Received: from mail73-ch1 (localhost.localdomain [127.0.0.1]) by mail73-ch1
	(MessageSwitch) id 134815460047352_15331;
	Thu, 20 Sep 2012 15:23:20 +0000 (UTC)
Received: from CH1EHSMHS041.bigfish.com (snatpool2.int.messaging.microsoft.com
	[10.43.68.239])	by mail73-ch1.bigfish.com (Postfix) with ESMTP id
	063984014C; Thu, 20 Sep 2012 15:23:20 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	CH1EHSMHS041.bigfish.com (10.43.69.250) with Microsoft SMTP Server id
	14.1.225.23; Thu, 20 Sep 2012 15:23:18 +0000
X-WSS-ID: 0MANMQR-02-AF6-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 25149C8145;	Thu, 20 Sep 2012 10:23:14 -0500 (CDT)
Received: from SAUSEXDAG05.amd.com (163.181.55.6) by sausexedgep02.amd.com
	(163.181.36.59) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Thu, 20 Sep 2012 10:23:25 -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, 20 Sep 2012 10:23:16 -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, 20 Sep 2012
	11:23:15 -0400
Message-ID: <505B34E1.6030609@amd.com>
Date: Thu, 20 Sep 2012 17:23:13 +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: <DE8DF0795D48FD4CA783C40EC8292335330591@SHSMSX101.ccr.corp.intel.com>
In-Reply-To: <DE8DF0795D48FD4CA783C40EC8292335330591@SHSMSX101.ccr.corp.intel.com>
X-OriginatorOrg: amd.com
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"keir@xen.org" <keir@xen.org>,
	"Ian.Campbell@citrix.com" <Ian.Campbell@citrix.com>,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH 2/5] Xen/MCE: vMCE 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 09/19/12 10:03, Liu, Jinsong wrote:

> Xen/MCE: vMCE injection
> 
> In our test for win8 guest mce, we find a bug 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.


This breaks the AMD way. The AMD way is to only inject it to vcpu0.
I suggest to add a flag argument to inject_vmce() that says whether
to inject to all vcpus or just vcpu0.
Then set/clear that flag from the caller side depending on whether you
run on Intel or AMD.

Christoph


> 
> Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>
> 
> diff -r 133664c6bfb4 xen/arch/x86/cpu/mcheck/vmce.c
> --- a/xen/arch/x86/cpu/mcheck/vmce.c	Tue Sep 18 22:39:11 2012 +0800
> +++ b/xen/arch/x86/cpu/mcheck/vmce.c	Tue Sep 18 23:46:38 2012 +0800
> @@ -340,48 +340,27 @@
>  
>  int inject_vmce(struct domain *d)
>  {
> -    int cpu = smp_processor_id();
> +    struct vcpu *v;
>  
> -    /* PV guest and HVM guest have different vMCE# injection methods. */
> -    if ( !test_and_set_bool(d->vcpu[0]->mce_pending) )
> +    /* inject vMCE to all vcpus */
> +    for_each_vcpu(d, v)
>      {
> -        if ( d->is_hvm )
> +        if ( !test_and_set_bool(v->mce_pending) &&
> +            ((d->is_hvm) ||
> +                guest_has_trap_callback(d, v->vcpu_id, TRAP_machine_check)) )
>          {
> -            mce_printk(MCE_VERBOSE, "MCE: inject vMCE to HVM DOM %d\n",
> -                       d->domain_id);
> -            vcpu_kick(d->vcpu[0]);
> +            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_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);
> -            }
> +            mce_printk(MCE_QUIET, "Fail to inject vMCE to dom%d vcpu%d\n",
> +                       d->domain_id, v->vcpu_id);
> +            return -1;
>          }
>      }
> -    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 injected "
> -                   " to this DOM%d!\n", d->domain_id);
> -        return -1;
> -    }
> +
>      return 0;
>  }
>  



-- 
---to satisfy European Law for business letters:
Advanced Micro Devices GmbH
Einsteinring 24, 85689 Dornach b. Muenchen
Geschaeftsfuehrer: Alberto Bozzo
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 Thu Sep 20 15:23:53 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Sep 2012 15:23: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 1TEib7-0002Sm-Hf; Thu, 20 Sep 2012 15:23:25 +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 1TEib6-0002Sh-De
	for xen-devel@lists.xensource.com; Thu, 20 Sep 2012 15:23:24 +0000
Received: from [85.158.143.99:22890] by server-1.bemta-4.messagelabs.com id
	31/F4-05684-BE43B505; Thu, 20 Sep 2012 15:23:23 +0000
X-Env-Sender: Christoph.Egger@amd.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1348154601!25862061!1
X-Originating-IP: [216.32.181.181]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29588 invoked from network); 20 Sep 2012 15:23:22 -0000
Received: from ch1ehsobe001.messaging.microsoft.com (HELO
	ch1outboundpool.messaging.microsoft.com) (216.32.181.181)
	by server-4.tower-216.messagelabs.com with AES128-SHA encrypted SMTP;
	20 Sep 2012 15:23:22 -0000
Received: from mail73-ch1-R.bigfish.com (10.43.68.232) by
	CH1EHSOBE014.bigfish.com (10.43.70.64) with Microsoft SMTP Server id
	14.1.225.23; Thu, 20 Sep 2012 15:23:21 +0000
Received: from mail73-ch1 (localhost [127.0.0.1])	by mail73-ch1-R.bigfish.com
	(Postfix) with ESMTP id 5716360148;
	Thu, 20 Sep 2012 15:23:21 +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: -2
X-BigFish: VPS-2(zzbb2dI98dI1432Id6f1izz1202h1d1ah1d2ahzz8275bhz2dh668h839hd25he5bhf0ah107ah1288h12a5h12a9h12bdh1155h)
Received: from mail73-ch1 (localhost.localdomain [127.0.0.1]) by mail73-ch1
	(MessageSwitch) id 134815460047352_15331;
	Thu, 20 Sep 2012 15:23:20 +0000 (UTC)
Received: from CH1EHSMHS041.bigfish.com (snatpool2.int.messaging.microsoft.com
	[10.43.68.239])	by mail73-ch1.bigfish.com (Postfix) with ESMTP id
	063984014C; Thu, 20 Sep 2012 15:23:20 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	CH1EHSMHS041.bigfish.com (10.43.69.250) with Microsoft SMTP Server id
	14.1.225.23; Thu, 20 Sep 2012 15:23:18 +0000
X-WSS-ID: 0MANMQR-02-AF6-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 25149C8145;	Thu, 20 Sep 2012 10:23:14 -0500 (CDT)
Received: from SAUSEXDAG05.amd.com (163.181.55.6) by sausexedgep02.amd.com
	(163.181.36.59) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Thu, 20 Sep 2012 10:23:25 -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, 20 Sep 2012 10:23:16 -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, 20 Sep 2012
	11:23:15 -0400
Message-ID: <505B34E1.6030609@amd.com>
Date: Thu, 20 Sep 2012 17:23:13 +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: <DE8DF0795D48FD4CA783C40EC8292335330591@SHSMSX101.ccr.corp.intel.com>
In-Reply-To: <DE8DF0795D48FD4CA783C40EC8292335330591@SHSMSX101.ccr.corp.intel.com>
X-OriginatorOrg: amd.com
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"keir@xen.org" <keir@xen.org>,
	"Ian.Campbell@citrix.com" <Ian.Campbell@citrix.com>,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH 2/5] Xen/MCE: vMCE 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 09/19/12 10:03, Liu, Jinsong wrote:

> Xen/MCE: vMCE injection
> 
> In our test for win8 guest mce, we find a bug 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.


This breaks the AMD way. The AMD way is to only inject it to vcpu0.
I suggest to add a flag argument to inject_vmce() that says whether
to inject to all vcpus or just vcpu0.
Then set/clear that flag from the caller side depending on whether you
run on Intel or AMD.

Christoph


> 
> Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>
> 
> diff -r 133664c6bfb4 xen/arch/x86/cpu/mcheck/vmce.c
> --- a/xen/arch/x86/cpu/mcheck/vmce.c	Tue Sep 18 22:39:11 2012 +0800
> +++ b/xen/arch/x86/cpu/mcheck/vmce.c	Tue Sep 18 23:46:38 2012 +0800
> @@ -340,48 +340,27 @@
>  
>  int inject_vmce(struct domain *d)
>  {
> -    int cpu = smp_processor_id();
> +    struct vcpu *v;
>  
> -    /* PV guest and HVM guest have different vMCE# injection methods. */
> -    if ( !test_and_set_bool(d->vcpu[0]->mce_pending) )
> +    /* inject vMCE to all vcpus */
> +    for_each_vcpu(d, v)
>      {
> -        if ( d->is_hvm )
> +        if ( !test_and_set_bool(v->mce_pending) &&
> +            ((d->is_hvm) ||
> +                guest_has_trap_callback(d, v->vcpu_id, TRAP_machine_check)) )
>          {
> -            mce_printk(MCE_VERBOSE, "MCE: inject vMCE to HVM DOM %d\n",
> -                       d->domain_id);
> -            vcpu_kick(d->vcpu[0]);
> +            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_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);
> -            }
> +            mce_printk(MCE_QUIET, "Fail to inject vMCE to dom%d vcpu%d\n",
> +                       d->domain_id, v->vcpu_id);
> +            return -1;
>          }
>      }
> -    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 injected "
> -                   " to this DOM%d!\n", d->domain_id);
> -        return -1;
> -    }
> +
>      return 0;
>  }
>  



-- 
---to satisfy European Law for business letters:
Advanced Micro Devices GmbH
Einsteinring 24, 85689 Dornach b. Muenchen
Geschaeftsfuehrer: Alberto Bozzo
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 Thu Sep 20 15:31:09 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Sep 2012 15: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 1TEiiG-0002mk-2A; Thu, 20 Sep 2012 15:30:48 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andreslc@gridcentric.ca>) id 1TEiiF-0002mf-77
	for xen-devel@lists.xen.org; Thu, 20 Sep 2012 15:30:47 +0000
Received: from [85.158.143.35:58139] by server-2.bemta-4.messagelabs.com id
	EA/01-06610-5A63B505; Thu, 20 Sep 2012 15:30:45 +0000
X-Env-Sender: andreslc@gridcentric.ca
X-Msg-Ref: server-7.tower-21.messagelabs.com!1348155042!13327089!1
X-Originating-IP: [209.85.213.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26149 invoked from network); 20 Sep 2012 15:30:43 -0000
Received: from mail-yx0-f173.google.com (HELO mail-yx0-f173.google.com)
	(209.85.213.173)
	by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Sep 2012 15:30:43 -0000
Received: by yenl3 with SMTP id l3so45437yen.32
	for <xen-devel@lists.xen.org>; Thu, 20 Sep 2012 08:30:42 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=subject:mime-version:content-type:from:in-reply-to:date:cc
	:content-transfer-encoding:message-id:references:to:x-mailer
	:x-gm-message-state;
	bh=k6k3uxetQXeVgtCKy00i0rGcTcf22CePL+6Hzxq7nk0=;
	b=eERvjGNk6YOlp3DOrXDup05GlUO++8j0WpMi5aZLt8RFihJCXTsxWTXw8e26R7XyeE
	N+4uwFqPYacJA/e5HVuFOr+zFZlw9ztbc7+LPkc7sgb3tpwrgnlID3WsGWXDE/eYPver
	ZmqjPOvzYIVBad7kGodb+WxezMnrKQGKIo8qKYbIL4GOaTk/2qQVCBfBZxxjTyrDSXUz
	I3BcRcqgMtrDptgVwVbyoOLnQ0UZTvRJOp7c9F9uBzUd7LcIClfGBCkFYusq333PxJaA
	sTau54OJX4tY7CkVqzBeSAL/7b6kVs+OU0P0xbCEsWj/gM5uZzY1aAkaSJsJ3LInEcUm
	L2yQ==
Received: by 10.236.185.201 with SMTP id u49mr2089630yhm.28.1348155042002;
	Thu, 20 Sep 2012 08:30:42 -0700 (PDT)
Received: from [192.168.7.210] ([206.223.182.18])
	by mx.google.com with ESMTPS id o25sm9013130yhm.14.2012.09.20.08.30.39
	(version=TLSv1/SSLv3 cipher=OTHER);
	Thu, 20 Sep 2012 08:30:41 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1278)
From: Andres Lagar-Cavilla <andreslc@gridcentric.ca>
In-Reply-To: <505A024E020000780009C602@nat28.tlf.novell.com>
Date: Thu, 20 Sep 2012 11:30:53 -0400
Message-Id: <45FC1469-4B51-4A53-A9D8-2012954907C3@gridcentric.ca>
References: <40b91bed1275b13e191f.1347550068@xdev.gridcentric.ca>
	<505A024E020000780009C602@nat28.tlf.novell.com>
To: Jan Beulich <JBeulich@suse.com>
X-Mailer: Apple Mail (2.1278)
X-Gm-Message-State: ALoCoQnf/wQCqfiSc+bxlcyEtUgatmwMMBSOwJgxfaW7/UP57GQI/sa4CbrLQfYB3shz4eDj51vW
Cc: tim@xen.org, keir@xen.org, Andres Lagar-Cavilla <andres@lagarcavilla.org>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] Extra check in grant table code for mapping
	of shared frame
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <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 Sep 19, 2012, at 11:35 AM, Jan Beulich wrote:

>>>> On 13.09.12 at 17:27, Andres Lagar-Cavilla <andres@lagarcavilla.org> w=
rote:
>> --- a/xen/common/grant_table.c
>> +++ b/xen/common/grant_table.c
>> @@ -649,9 +649,12 @@ __gnttab_map_grant_ref(
>>     }
>>     else if ( owner =3D=3D rd || owner =3D=3D dom_cow )
>>     {
>> -        if ( gnttab_host_mapping_get_page_type(op, ld, rd) &&
>> -             !get_page_type(pg, PGT_writable_page) )
>> -            goto could_not_pin;
>> +        if ( gnttab_host_mapping_get_page_type(op, ld, rd) )
>> +        {
>> +            if ( (owner =3D=3D dom_cow) ||
>> +                 !get_page_type(pg, PGT_writable_page) )
>> +                goto could_not_pin;
>> +        }
>> =

>>         nr_gets++;
>>         if ( op->flags & GNTMAP_host_map )
> =

> Isn't that only half of it, in that the error/unmap paths need to
> also consider that get_page_type() wasn't called? There's
> quite a few calls to gnttab_host_mapping_get_page_type()/
> put_page_type() sequences there.

I think this is covered. could_not_pin will cascade into undo_out, and nr_g=
ets remains at zero at this point. Then:
 undo_out:
    if ( nr_gets > 1 )
    {
       =85
    }
    if ( nr_gets > 0 )
    {
        if ( gnttab_host_mapping_get_page_type(op, ld, rd) )
            put_page_type(pg);
            ...

i.e. put_page_type will not be called. This is really tricky code!

Andres
> =

> Jan
> =



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 20 15:31:09 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Sep 2012 15: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 1TEiiG-0002mk-2A; Thu, 20 Sep 2012 15:30:48 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andreslc@gridcentric.ca>) id 1TEiiF-0002mf-77
	for xen-devel@lists.xen.org; Thu, 20 Sep 2012 15:30:47 +0000
Received: from [85.158.143.35:58139] by server-2.bemta-4.messagelabs.com id
	EA/01-06610-5A63B505; Thu, 20 Sep 2012 15:30:45 +0000
X-Env-Sender: andreslc@gridcentric.ca
X-Msg-Ref: server-7.tower-21.messagelabs.com!1348155042!13327089!1
X-Originating-IP: [209.85.213.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26149 invoked from network); 20 Sep 2012 15:30:43 -0000
Received: from mail-yx0-f173.google.com (HELO mail-yx0-f173.google.com)
	(209.85.213.173)
	by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Sep 2012 15:30:43 -0000
Received: by yenl3 with SMTP id l3so45437yen.32
	for <xen-devel@lists.xen.org>; Thu, 20 Sep 2012 08:30:42 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=subject:mime-version:content-type:from:in-reply-to:date:cc
	:content-transfer-encoding:message-id:references:to:x-mailer
	:x-gm-message-state;
	bh=k6k3uxetQXeVgtCKy00i0rGcTcf22CePL+6Hzxq7nk0=;
	b=eERvjGNk6YOlp3DOrXDup05GlUO++8j0WpMi5aZLt8RFihJCXTsxWTXw8e26R7XyeE
	N+4uwFqPYacJA/e5HVuFOr+zFZlw9ztbc7+LPkc7sgb3tpwrgnlID3WsGWXDE/eYPver
	ZmqjPOvzYIVBad7kGodb+WxezMnrKQGKIo8qKYbIL4GOaTk/2qQVCBfBZxxjTyrDSXUz
	I3BcRcqgMtrDptgVwVbyoOLnQ0UZTvRJOp7c9F9uBzUd7LcIClfGBCkFYusq333PxJaA
	sTau54OJX4tY7CkVqzBeSAL/7b6kVs+OU0P0xbCEsWj/gM5uZzY1aAkaSJsJ3LInEcUm
	L2yQ==
Received: by 10.236.185.201 with SMTP id u49mr2089630yhm.28.1348155042002;
	Thu, 20 Sep 2012 08:30:42 -0700 (PDT)
Received: from [192.168.7.210] ([206.223.182.18])
	by mx.google.com with ESMTPS id o25sm9013130yhm.14.2012.09.20.08.30.39
	(version=TLSv1/SSLv3 cipher=OTHER);
	Thu, 20 Sep 2012 08:30:41 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1278)
From: Andres Lagar-Cavilla <andreslc@gridcentric.ca>
In-Reply-To: <505A024E020000780009C602@nat28.tlf.novell.com>
Date: Thu, 20 Sep 2012 11:30:53 -0400
Message-Id: <45FC1469-4B51-4A53-A9D8-2012954907C3@gridcentric.ca>
References: <40b91bed1275b13e191f.1347550068@xdev.gridcentric.ca>
	<505A024E020000780009C602@nat28.tlf.novell.com>
To: Jan Beulich <JBeulich@suse.com>
X-Mailer: Apple Mail (2.1278)
X-Gm-Message-State: ALoCoQnf/wQCqfiSc+bxlcyEtUgatmwMMBSOwJgxfaW7/UP57GQI/sa4CbrLQfYB3shz4eDj51vW
Cc: tim@xen.org, keir@xen.org, Andres Lagar-Cavilla <andres@lagarcavilla.org>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] Extra check in grant table code for mapping
	of shared frame
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <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 Sep 19, 2012, at 11:35 AM, Jan Beulich wrote:

>>>> On 13.09.12 at 17:27, Andres Lagar-Cavilla <andres@lagarcavilla.org> w=
rote:
>> --- a/xen/common/grant_table.c
>> +++ b/xen/common/grant_table.c
>> @@ -649,9 +649,12 @@ __gnttab_map_grant_ref(
>>     }
>>     else if ( owner =3D=3D rd || owner =3D=3D dom_cow )
>>     {
>> -        if ( gnttab_host_mapping_get_page_type(op, ld, rd) &&
>> -             !get_page_type(pg, PGT_writable_page) )
>> -            goto could_not_pin;
>> +        if ( gnttab_host_mapping_get_page_type(op, ld, rd) )
>> +        {
>> +            if ( (owner =3D=3D dom_cow) ||
>> +                 !get_page_type(pg, PGT_writable_page) )
>> +                goto could_not_pin;
>> +        }
>> =

>>         nr_gets++;
>>         if ( op->flags & GNTMAP_host_map )
> =

> Isn't that only half of it, in that the error/unmap paths need to
> also consider that get_page_type() wasn't called? There's
> quite a few calls to gnttab_host_mapping_get_page_type()/
> put_page_type() sequences there.

I think this is covered. could_not_pin will cascade into undo_out, and nr_g=
ets remains at zero at this point. Then:
 undo_out:
    if ( nr_gets > 1 )
    {
       =85
    }
    if ( nr_gets > 0 )
    {
        if ( gnttab_host_mapping_get_page_type(op, ld, rd) )
            put_page_type(pg);
            ...

i.e. put_page_type will not be called. This is really tricky code!

Andres
> =

> Jan
> =



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 20 15:35:19 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Sep 2012 15:35:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TEimL-0002zS-Se; Thu, 20 Sep 2012 15:35:01 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1TEimK-0002zN-Mo
	for xen-devel@lists.xen.org; Thu, 20 Sep 2012 15:35:00 +0000
Received: from [85.158.143.35:16462] by server-3.bemta-4.messagelabs.com id
	67/16-10986-4A73B505; Thu, 20 Sep 2012 15:35:00 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1348155299!8179107!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21895 invoked from network); 20 Sep 2012 15:34: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 Sep 2012 15:34:59 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 20 Sep 2012 16:34:59 +0100
Message-Id: <505B53D7020000780009CBB5@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 20 Sep 2012 16:35:19 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>
References: <1348051887-21885-1-git-send-email-oliver.chick@citrix.com>
	<505AF126.2050806@citrix.com>
	<1348140637.24539.32.camel@oliverchick-Precision-WorkStation-T3400>
	<505B1EB9020000780009CA6E@nat28.tlf.novell.com>
	<20120920134951.GC1998@localhost.localdomain>
In-Reply-To: <20120920134951.GC1998@localhost.localdomain>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Oliver Chick <oliver.chick@citrix.com>,
	David Vrabel <david.vrabel@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] Persistent grant maps for xen blk drivers
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 20.09.12 at 15:49, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
> On Thu, Sep 20, 2012 at 12:48:41PM +0100, Jan Beulich wrote:
>> >>> On 20.09.12 at 13:30, Oliver Chick <oliver.chick@citrix.com> wrote:
>> > The memory overhead, and fallback mode points are related:
>> > -Firstly, it turns out that the overhead is actually 2.75MB, not 11MB
>> > per device. I made a mistake (pointed out by Jan) as the maximum number
>> > of requests that can fit into a single-page ring is 64, not 256.
>> > -Clearly, this still scales linearly. So the problem of memory footprint
>> > will occur with more VMs, or block devices.
>> > -Whilst 2.75MB per device is probably acceptable (?), if we start using
>> > multipage rings, then we might not want to have
>> > BLKIF_MAX_PERS_REQUESTS_PER_DEVICE==__RING_SIZE, as this will cause the
>> > memory overhead to increase. This is why I have implemented the
>> > 'fallback' mode. With a multipage ring, it seems reasonable to want the
>> > first $x$ grefs seen by blkback to be treated as persistent, and any
>> > later ones to be non-persistent. Does that seem sensible?
>> 
>> From a resource usage pov, perhaps. But this will get the guest
>> entirely unpredictable performance. Plus I don't think 11Mb of
> 
> Wouldn't it fall back to the older performance?

Right, but the guest can't really predict this. That may have
significant impact if the performance difference is big enough.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 20 15:35:19 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Sep 2012 15:35:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TEimL-0002zS-Se; Thu, 20 Sep 2012 15:35:01 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1TEimK-0002zN-Mo
	for xen-devel@lists.xen.org; Thu, 20 Sep 2012 15:35:00 +0000
Received: from [85.158.143.35:16462] by server-3.bemta-4.messagelabs.com id
	67/16-10986-4A73B505; Thu, 20 Sep 2012 15:35:00 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1348155299!8179107!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21895 invoked from network); 20 Sep 2012 15:34: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 Sep 2012 15:34:59 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 20 Sep 2012 16:34:59 +0100
Message-Id: <505B53D7020000780009CBB5@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 20 Sep 2012 16:35:19 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>
References: <1348051887-21885-1-git-send-email-oliver.chick@citrix.com>
	<505AF126.2050806@citrix.com>
	<1348140637.24539.32.camel@oliverchick-Precision-WorkStation-T3400>
	<505B1EB9020000780009CA6E@nat28.tlf.novell.com>
	<20120920134951.GC1998@localhost.localdomain>
In-Reply-To: <20120920134951.GC1998@localhost.localdomain>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Oliver Chick <oliver.chick@citrix.com>,
	David Vrabel <david.vrabel@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] Persistent grant maps for xen blk drivers
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 20.09.12 at 15:49, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
> On Thu, Sep 20, 2012 at 12:48:41PM +0100, Jan Beulich wrote:
>> >>> On 20.09.12 at 13:30, Oliver Chick <oliver.chick@citrix.com> wrote:
>> > The memory overhead, and fallback mode points are related:
>> > -Firstly, it turns out that the overhead is actually 2.75MB, not 11MB
>> > per device. I made a mistake (pointed out by Jan) as the maximum number
>> > of requests that can fit into a single-page ring is 64, not 256.
>> > -Clearly, this still scales linearly. So the problem of memory footprint
>> > will occur with more VMs, or block devices.
>> > -Whilst 2.75MB per device is probably acceptable (?), if we start using
>> > multipage rings, then we might not want to have
>> > BLKIF_MAX_PERS_REQUESTS_PER_DEVICE==__RING_SIZE, as this will cause the
>> > memory overhead to increase. This is why I have implemented the
>> > 'fallback' mode. With a multipage ring, it seems reasonable to want the
>> > first $x$ grefs seen by blkback to be treated as persistent, and any
>> > later ones to be non-persistent. Does that seem sensible?
>> 
>> From a resource usage pov, perhaps. But this will get the guest
>> entirely unpredictable performance. Plus I don't think 11Mb of
> 
> Wouldn't it fall back to the older performance?

Right, but the guest can't really predict this. That may have
significant impact if the performance difference is big enough.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 20 15:40:10 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Sep 2012 15:40:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TEir4-00039I-Kv; Thu, 20 Sep 2012 15:39:54 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <attilio.rao@citrix.com>) id 1TEir3-00039D-9i
	for xen-devel@lists.xen.org; Thu, 20 Sep 2012 15:39:53 +0000
Received: from [85.158.139.83:24851] by server-10.bemta-5.messagelabs.com id
	B1/CC-10969-8C83B505; Thu, 20 Sep 2012 15:39:52 +0000
X-Env-Sender: attilio.rao@citrix.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1348155590!31699177!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTA0NTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26454 invoked from network); 20 Sep 2012 15:39:51 -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;
	20 Sep 2012 15:39:51 -0000
X-IronPort-AV: E=Sophos;i="4.80,454,1344211200"; d="scan'208";a="14664325"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Sep 2012 15:39:50 +0000
Received: from [10.80.3.221] (10.80.3.221) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Thu, 20 Sep 2012 16:39:50 +0100
Message-ID: <505B3878.405@citrix.com>
Date: Thu, 20 Sep 2012 16:38:32 +0100
From: Attilio Rao <attilio.rao@citrix.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US;
	rv:1.9.1.16) Gecko/20111110 Icedove/3.0.11
MIME-Version: 1.0
To: <xen-devel@lists.xen.org>, George Dunlap <George.Dunlap@eu.citrix.com>
References: <CAFLBxZYtmJ_bKFb90r45=C4Pq1-oe5Fy=eygSsQf4BcGj3EqGA@mail.gmail.com>
In-Reply-To: <CAFLBxZYtmJ_bKFb90r45=C4Pq1-oe5Fy=eygSsQf4BcGj3EqGA@mail.gmail.com>
Subject: Re: [Xen-devel] Xen 4.3 development 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-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 19/09/12 17:58, George Dunlap wrote:
> = Timeline =
>
> We are planning on a 9-month release cycle.  Based on that, below are
> our estimated dates:
> * Feature Freeze: 1 March, 2013
> * First RC: 15 April 2013
> * Release: 1 June 2013
>
> The RCs and release will of course depend on stability and bugs, and
> will therefore be fairly unpredictable.  The feature freeze may be
> slipped for especially important features which are near completion.
>
> = Feature tracking =
>
> Below is a list of features we're tracking for this release.  Please
> respond to this mail with any updates to the status.  If the status
> is "?", as most of them are, please respond with the status!  Example
> statuses include "not started", "in progress", "initial implementation
> submitted for review", "patches submitted".
>
> There are a number of items whose owners are marked as "?".  If you
> are working on this, or know who is working on it, please respond and
> let me know.  Alternately, if you would *like* to work on it, please
> let me know as well.
>
> And if there is something you're working on you'd like tracked, please
> respond, and I will add it to the list.
>
>
> * PVH mode, domU (w/ Linux)
>    owner: mukesh@oracle
>    status: ?
>
> * PVH mode, dom0 (w/ Linux)
>    owner: mukesh@oracle
>    status: ?
>
> * Event channel scalability
>    owner: attilio@citrix
>    status: ?
>    Increase limit on event channels (currently 1024 for 32-bit guests,
>    4096 for 64-bit guests)
>    

"in progress", green.

Attilio

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 20 15:40:10 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Sep 2012 15:40:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TEir4-00039I-Kv; Thu, 20 Sep 2012 15:39:54 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <attilio.rao@citrix.com>) id 1TEir3-00039D-9i
	for xen-devel@lists.xen.org; Thu, 20 Sep 2012 15:39:53 +0000
Received: from [85.158.139.83:24851] by server-10.bemta-5.messagelabs.com id
	B1/CC-10969-8C83B505; Thu, 20 Sep 2012 15:39:52 +0000
X-Env-Sender: attilio.rao@citrix.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1348155590!31699177!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTA0NTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26454 invoked from network); 20 Sep 2012 15:39:51 -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;
	20 Sep 2012 15:39:51 -0000
X-IronPort-AV: E=Sophos;i="4.80,454,1344211200"; d="scan'208";a="14664325"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Sep 2012 15:39:50 +0000
Received: from [10.80.3.221] (10.80.3.221) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Thu, 20 Sep 2012 16:39:50 +0100
Message-ID: <505B3878.405@citrix.com>
Date: Thu, 20 Sep 2012 16:38:32 +0100
From: Attilio Rao <attilio.rao@citrix.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US;
	rv:1.9.1.16) Gecko/20111110 Icedove/3.0.11
MIME-Version: 1.0
To: <xen-devel@lists.xen.org>, George Dunlap <George.Dunlap@eu.citrix.com>
References: <CAFLBxZYtmJ_bKFb90r45=C4Pq1-oe5Fy=eygSsQf4BcGj3EqGA@mail.gmail.com>
In-Reply-To: <CAFLBxZYtmJ_bKFb90r45=C4Pq1-oe5Fy=eygSsQf4BcGj3EqGA@mail.gmail.com>
Subject: Re: [Xen-devel] Xen 4.3 development 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-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 19/09/12 17:58, George Dunlap wrote:
> = Timeline =
>
> We are planning on a 9-month release cycle.  Based on that, below are
> our estimated dates:
> * Feature Freeze: 1 March, 2013
> * First RC: 15 April 2013
> * Release: 1 June 2013
>
> The RCs and release will of course depend on stability and bugs, and
> will therefore be fairly unpredictable.  The feature freeze may be
> slipped for especially important features which are near completion.
>
> = Feature tracking =
>
> Below is a list of features we're tracking for this release.  Please
> respond to this mail with any updates to the status.  If the status
> is "?", as most of them are, please respond with the status!  Example
> statuses include "not started", "in progress", "initial implementation
> submitted for review", "patches submitted".
>
> There are a number of items whose owners are marked as "?".  If you
> are working on this, or know who is working on it, please respond and
> let me know.  Alternately, if you would *like* to work on it, please
> let me know as well.
>
> And if there is something you're working on you'd like tracked, please
> respond, and I will add it to the list.
>
>
> * PVH mode, domU (w/ Linux)
>    owner: mukesh@oracle
>    status: ?
>
> * PVH mode, dom0 (w/ Linux)
>    owner: mukesh@oracle
>    status: ?
>
> * Event channel scalability
>    owner: attilio@citrix
>    status: ?
>    Increase limit on event channels (currently 1024 for 32-bit guests,
>    4096 for 64-bit guests)
>    

"in progress", green.

Attilio

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 20 15:42:34 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Sep 2012 15: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 1TEitP-0003F3-6Y; Thu, 20 Sep 2012 15:42: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 1TEitN-0003Ex-B3
	for xen-devel@lists.xen.org; Thu, 20 Sep 2012 15:42:17 +0000
Received: from [85.158.139.83:41213] by server-10.bemta-5.messagelabs.com id
	7B/35-10969-8593B505; Thu, 20 Sep 2012 15:42:16 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1348155730!31252318!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1263 invoked from network); 20 Sep 2012 15:42:10 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-12.tower-182.messagelabs.com with SMTP;
	20 Sep 2012 15:42:10 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 20 Sep 2012 16:42:09 +0100
Message-Id: <505B5586020000780009CBCF@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 20 Sep 2012 16:42:30 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Attilio Rao" <attilio.rao@citrix.com>
References: <505A5A03.4000106@citrix.com>
	<505AE62A020000780009C7F8@nat28.tlf.novell.com>
	<505B22C5.4050004@citrix.com>
In-Reply-To: <505B22C5.4050004@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] [RFC] Extend the number of event channels availabe
 to guests
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 20.09.12 at 16:05, Attilio Rao <attilio.rao@citrix.com> wrote:
> On 20/09/12 08:47, Jan Beulich wrote:
>>>>> On 20.09.12 at 01:49, Attilio Rao<attilio.rao@citrix.com>  wrote:
>>>>>          
>>> Proposal
>>> The proposal is pretty simple: the eventchannel search will become a
>>> three-level lookup table, with the leaf level being composed by shared
>>> pages registered at boot time by the guests.
>>> The bitmap working now as leaf (then called "second level") will work
>>> alternatively as leaf level still (for older kernel) or for intermediate
>>> level to address into a new array of shared pages (for newer kernels).
>>> This leaves the possibility to reuse the existing mechanisms without
>>> modifying its internals.
>>>      
>> While adding one level would seem to leave ample room, so did
>> the originally 4096 originally. Therefore, even if unimplemented
>> right now, I'd like the interface to allow for the guest to specify
>> more levels.
>>    
> 
> There is a big difference here. The third/new level will be composed of 
> pages registered at guest installing so it can be expanded on demanded 
> necessity. The second-level we have now doesn't work because it is stuck 
> in the immutable ABI.
> The only useful way to have another level would be in the case we think 
> the second-level is not enough to address all the necessary bits in the 
> third level in efficient way.
> 
> To make you an example, the first level is 64 bits while the second 
> level can address 64 times the first level. The third level, to be 
> on-par with the same ratio of the second level in terms of performance, 
> would be large something like 4 pages. I think we are very far from 
> reaching critical levels.

What I'm saying is that further levels should be continuing at the
rate, i.e. times BITS_PER_LONG per level. Allowing for an only
partially populated leaf level is certainly an option. But similarly
it should be an option to have a fourth level once needed, without
having to start over from scratch again.

>>> More specifically, what needs to happen:
>>> - Add new members to struct domain to handle an array of pages (to
>>> contain the actual evtchn bitmaps), a further array of pages (to contain
>>> the evtchn masks) and a control bit to say if it is subjective to the
>>> new mode or not. Initially the arrays will be empty and the control bit
>>> will be OFF.
>>> - At init_platform() time, the guest must allocate the pages to compose
>>> the 2 arrays and invoke a novel hypercall which, at big lines, does the
>>> following:
>>>     * Creates some pages to populate the new arrays in struct domain via
>>> alloc_xenheap_pages()
>>>      
>> Why? The guest allocated the pages already. Just have the
>> hypervisor map them (similar, but without the per-vCPU needs,
>> to registering an alternative per-vCPU shared page). Whether
>> it turns out more practical to require the guest to enforce
>> certain restrictions (like the pages being contiguous and/or
>> address restricted) is a secondary aspect.
>>    
> 
> Actually what I propose seems to be what happens infact in the shared 
> page case. Look at what arch_domain_create() and XENMEM_add_to_physmap 
> hypercall do (in the XENMAPSPACE_shared_info case). I think this is the 
> quicker way to get what we want.

This is HVM-only thinking. PV doesn't use this, and I don't think
artificially inserting something somewhere in the physmap of a
PV guest is a good idea either. To have things done uniformly,
going the PV route and using guest allocated pages seems the
better choice to me. Alternatively, you'd have to implement a
HVM mechanism (via add-to-physmap) and a PV one.

Plus the add-to-physmap one has the drawback of limiting the
space available for adding pages (as these would generally
have to go into the MMIO space of the platform PCI device).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 20 15:42:34 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Sep 2012 15: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 1TEitP-0003F3-6Y; Thu, 20 Sep 2012 15:42: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 1TEitN-0003Ex-B3
	for xen-devel@lists.xen.org; Thu, 20 Sep 2012 15:42:17 +0000
Received: from [85.158.139.83:41213] by server-10.bemta-5.messagelabs.com id
	7B/35-10969-8593B505; Thu, 20 Sep 2012 15:42:16 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1348155730!31252318!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1263 invoked from network); 20 Sep 2012 15:42:10 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-12.tower-182.messagelabs.com with SMTP;
	20 Sep 2012 15:42:10 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 20 Sep 2012 16:42:09 +0100
Message-Id: <505B5586020000780009CBCF@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 20 Sep 2012 16:42:30 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Attilio Rao" <attilio.rao@citrix.com>
References: <505A5A03.4000106@citrix.com>
	<505AE62A020000780009C7F8@nat28.tlf.novell.com>
	<505B22C5.4050004@citrix.com>
In-Reply-To: <505B22C5.4050004@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] [RFC] Extend the number of event channels availabe
 to guests
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 20.09.12 at 16:05, Attilio Rao <attilio.rao@citrix.com> wrote:
> On 20/09/12 08:47, Jan Beulich wrote:
>>>>> On 20.09.12 at 01:49, Attilio Rao<attilio.rao@citrix.com>  wrote:
>>>>>          
>>> Proposal
>>> The proposal is pretty simple: the eventchannel search will become a
>>> three-level lookup table, with the leaf level being composed by shared
>>> pages registered at boot time by the guests.
>>> The bitmap working now as leaf (then called "second level") will work
>>> alternatively as leaf level still (for older kernel) or for intermediate
>>> level to address into a new array of shared pages (for newer kernels).
>>> This leaves the possibility to reuse the existing mechanisms without
>>> modifying its internals.
>>>      
>> While adding one level would seem to leave ample room, so did
>> the originally 4096 originally. Therefore, even if unimplemented
>> right now, I'd like the interface to allow for the guest to specify
>> more levels.
>>    
> 
> There is a big difference here. The third/new level will be composed of 
> pages registered at guest installing so it can be expanded on demanded 
> necessity. The second-level we have now doesn't work because it is stuck 
> in the immutable ABI.
> The only useful way to have another level would be in the case we think 
> the second-level is not enough to address all the necessary bits in the 
> third level in efficient way.
> 
> To make you an example, the first level is 64 bits while the second 
> level can address 64 times the first level. The third level, to be 
> on-par with the same ratio of the second level in terms of performance, 
> would be large something like 4 pages. I think we are very far from 
> reaching critical levels.

What I'm saying is that further levels should be continuing at the
rate, i.e. times BITS_PER_LONG per level. Allowing for an only
partially populated leaf level is certainly an option. But similarly
it should be an option to have a fourth level once needed, without
having to start over from scratch again.

>>> More specifically, what needs to happen:
>>> - Add new members to struct domain to handle an array of pages (to
>>> contain the actual evtchn bitmaps), a further array of pages (to contain
>>> the evtchn masks) and a control bit to say if it is subjective to the
>>> new mode or not. Initially the arrays will be empty and the control bit
>>> will be OFF.
>>> - At init_platform() time, the guest must allocate the pages to compose
>>> the 2 arrays and invoke a novel hypercall which, at big lines, does the
>>> following:
>>>     * Creates some pages to populate the new arrays in struct domain via
>>> alloc_xenheap_pages()
>>>      
>> Why? The guest allocated the pages already. Just have the
>> hypervisor map them (similar, but without the per-vCPU needs,
>> to registering an alternative per-vCPU shared page). Whether
>> it turns out more practical to require the guest to enforce
>> certain restrictions (like the pages being contiguous and/or
>> address restricted) is a secondary aspect.
>>    
> 
> Actually what I propose seems to be what happens infact in the shared 
> page case. Look at what arch_domain_create() and XENMEM_add_to_physmap 
> hypercall do (in the XENMAPSPACE_shared_info case). I think this is the 
> quicker way to get what we want.

This is HVM-only thinking. PV doesn't use this, and I don't think
artificially inserting something somewhere in the physmap of a
PV guest is a good idea either. To have things done uniformly,
going the PV route and using guest allocated pages seems the
better choice to me. Alternatively, you'd have to implement a
HVM mechanism (via add-to-physmap) and a PV one.

Plus the add-to-physmap one has the drawback of limiting the
space available for adding pages (as these would generally
have to go into the MMIO space of the platform PCI device).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 20 15:48:40 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Sep 2012 15:48: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 1TEizN-0003jo-5S; Thu, 20 Sep 2012 15:48:29 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <thanos.makatos@citrix.com>) id 1TEizM-0003je-7x
	for xen-devel@lists.xen.org; Thu, 20 Sep 2012 15:48:28 +0000
Received: from [85.158.139.83:23625] by server-11.bemta-5.messagelabs.com id
	2E/F8-24658-BCA3B505; Thu, 20 Sep 2012 15:48:27 +0000
X-Env-Sender: thanos.makatos@citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1348156104!28571653!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTA0NTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12786 invoked from network); 20 Sep 2012 15:48:26 -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 Sep 2012 15:48:26 -0000
X-IronPort-AV: E=Sophos;i="4.80,454,1344211200"; d="scan'208";a="14666197"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Sep 2012 15:46:37 +0000
Received: from LONPMAILBOX01.citrite.net ([10.30.224.160]) by
	LONPMAILMX01.citrite.net ([10.30.203.162]) with mapi; Thu, 20 Sep 2012
	16:46:34 +0100
From: Thanos Makatos <thanos.makatos@citrix.com>
To: George Dunlap <George.Dunlap@eu.citrix.com>, "xen-devel@lists.xen.org"
	<xen-devel@lists.xen.org>
Date: Thu, 20 Sep 2012 16:46:33 +0100
Thread-Topic: [Xen-devel] Xen 4.3 development update
Thread-Index: Ac2WiDuRp7Gc6BKKSReTYnxqt0V4rAAvsN+w
Message-ID: <4B45B535F7F6BE4CB1C044ED5115CDDE011A6DD00816@LONPMAILBOX01.citrite.net>
References: <CAFLBxZYtmJ_bKFb90r45=C4Pq1-oe5Fy=eygSsQf4BcGj3EqGA@mail.gmail.com>
In-Reply-To: <CAFLBxZYtmJ_bKFb90r45=C4Pq1-oe5Fy=eygSsQf4BcGj3EqGA@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] Xen 4.3 development 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



> -----Original Message-----
> From: xen-devel-bounces@lists.xen.org [mailto:xen-devel-
> bounces@lists.xen.org] On Behalf Of George Dunlap
> Sent: 19 September 2012 17:58
> To: xen-devel@lists.xen.org
> Subject: [Xen-devel] Xen 4.3 development update
> 
> = Timeline =
> 
> We are planning on a 9-month release cycle.  Based on that, below are
> our estimated dates:
> * Feature Freeze: 1 March, 2013
> * First RC: 15 April 2013
> * Release: 1 June 2013
> 
> The RCs and release will of course depend on stability and bugs, and
> will therefore be fairly unpredictable.  The feature freeze may be
> slipped for especially important features which are near completion.
> 
> = Feature tracking =
> 
> Below is a list of features we're tracking for this release.  Please
> respond to this mail with any updates to the status.  If the status is
> "?", as most of them are, please respond with the status!  Example
> statuses include "not started", "in progress", "initial implementation
> submitted for review", "patches submitted".
> 
> There are a number of items whose owners are marked as "?".  If you are
> working on this, or know who is working on it, please respond and let
> me know.  Alternately, if you would *like* to work on it, please let me
> know as well.
> 
> And if there is something you're working on you'd like tracked, please
> respond, and I will add it to the list.
> 
> 
> * PVH mode, domU (w/ Linux)
>   owner: mukesh@oracle
>   status: ?
> 
> * PVH mode, dom0 (w/ Linux)
>   owner: mukesh@oracle
>   status: ?
> 
> * Event channel scalability
>   owner: attilio@citrix
>   status: ?
>   Increase limit on event channels (currently 1024 for 32-bit guests,
>   4096 for 64-bit guests)
> 
> * ARM server port
>   owner: ijc@citrix
>   status: Core hypervisor patches accepted; Linux paches pending
> 
> * NUMA scheduler affinity
>   critical
>   owner: dario@citrix
>   status: ?
> 
> * NUMA Memory migration
>   owner: dario@citrix
>   status: ?
> 
> * blktap3
>   owner: thanos@citrix
>   status: ?
In progress
> 
> * Default to QEMU upstream
>  - qemu-based stubdom (Linux or BSD libc)
>    owner: anthony@citrix
>    status: ?
>    qemu-upstream needs a more fully-featured libc than exists in
>    minios.  Either work on a minimalist linux-based stubdom with
>    glibc, or port one of the BSD libcs to minios.
> 
>  - pci pass-thru
>    owner: anthony@citrix
>    status: ?
> 
> * Persistent grants
>   owner: @citrix
>   status: ?
> 
> * Multi-page blk rings
>  - blkback in kernel (konrad@oracle, ?@intel)
>  - qemu blkback
>   status: ?
> 
> * Multi-page net protocol
>   owner: ?
>   status: ?
>   expand the network ring protocol to allow multiple pages for
>   increased throughput
> 
> * Scalability: 16TiB of RAM
>   owner: jan@suse
>   status: ?
> 
> * libvirt integration
>   owner: ?
>   status: ?
>   To begin with, we need someone to go and make some lists:
>   - Features available in libvirt/KVM not available in libvirt/Xen
>   - Features available in xl/Xen but not available in libvirt/Xen
> 
> * xl vm-{export,import}
>   owner: ?
>   status: ?
>   Allow xl to import and export VMs to other formats; particularly
>   ovf, perhaps the XenServer format, or more.
> 
> 
> * xl USB pass-through for PV guests
>   owner: ?
>   status: ?
>   - Port the xend PV pass-through functionality to xl.
>   - Make sure qemu-based USB with qemu-upstream works
>   - Upstream the Linux frontend/backend drivers
> 
> * openvswitch toostack integration
>   owner: roger@citrix
>   status: Sample script posted by Bastian ("[RFC] openvswitch support
> script")
> 
> * Rationalized backend scripts (incl. driver domains)
>   owner: roger@citrix
>   status: ?
> 
> * Linux console improvements
>   owner: jan@suse
>   -EHCI debug port (done, to be submitted)
>   -xHCI debug port
>   -Firewire
> 
> * CPUID-based idle (don't rely on ACPI info f/ dom0)
>   owner: jan@suse
>   status: done, to be submitted
> 
> * Remove hardcoded mobprobe's in xencommons
>   owner: ?
>   status: ?
> 
> * Make storage migration possible
>   owner: ?
>   status: ?
>   There needs to be a way, either via command-line or via some hooks,
>   that someone can build a "storage migration" feature on top of libxl
>   or xl.
> 
> * Full-VM snapshotting
>   owner: ?
>   status: ?
>   Have a way of coordinating the taking and restoring of VM memory and
>   disk snapshots.  This would involve some investigation into the best
>   way to accomplish this.
> 
> * VM Cloning
>   owner: ?
>   status: May need review
>   Again, a way of coordinating the memory and disk aspects.  Research
>   into the best way to do this would probably go along with the
>   snapshotting feature.
> 
> * Memory: Replace PoD with paging mechanism
>   owner: george@citrix
>   status: May need review
> 
> * PV audio (audio for stubdom qemu)
>   owner: stefano.panella@citrix
>   status: ?
> 
> * Managed domains?
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Sep 20 15:48:40 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Sep 2012 15:48: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 1TEizN-0003jo-5S; Thu, 20 Sep 2012 15:48:29 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <thanos.makatos@citrix.com>) id 1TEizM-0003je-7x
	for xen-devel@lists.xen.org; Thu, 20 Sep 2012 15:48:28 +0000
Received: from [85.158.139.83:23625] by server-11.bemta-5.messagelabs.com id
	2E/F8-24658-BCA3B505; Thu, 20 Sep 2012 15:48:27 +0000
X-Env-Sender: thanos.makatos@citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1348156104!28571653!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTA0NTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12786 invoked from network); 20 Sep 2012 15:48:26 -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 Sep 2012 15:48:26 -0000
X-IronPort-AV: E=Sophos;i="4.80,454,1344211200"; d="scan'208";a="14666197"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Sep 2012 15:46:37 +0000
Received: from LONPMAILBOX01.citrite.net ([10.30.224.160]) by
	LONPMAILMX01.citrite.net ([10.30.203.162]) with mapi; Thu, 20 Sep 2012
	16:46:34 +0100
From: Thanos Makatos <thanos.makatos@citrix.com>
To: George Dunlap <George.Dunlap@eu.citrix.com>, "xen-devel@lists.xen.org"
	<xen-devel@lists.xen.org>
Date: Thu, 20 Sep 2012 16:46:33 +0100
Thread-Topic: [Xen-devel] Xen 4.3 development update
Thread-Index: Ac2WiDuRp7Gc6BKKSReTYnxqt0V4rAAvsN+w
Message-ID: <4B45B535F7F6BE4CB1C044ED5115CDDE011A6DD00816@LONPMAILBOX01.citrite.net>
References: <CAFLBxZYtmJ_bKFb90r45=C4Pq1-oe5Fy=eygSsQf4BcGj3EqGA@mail.gmail.com>
In-Reply-To: <CAFLBxZYtmJ_bKFb90r45=C4Pq1-oe5Fy=eygSsQf4BcGj3EqGA@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] Xen 4.3 development 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



> -----Original Message-----
> From: xen-devel-bounces@lists.xen.org [mailto:xen-devel-
> bounces@lists.xen.org] On Behalf Of George Dunlap
> Sent: 19 September 2012 17:58
> To: xen-devel@lists.xen.org
> Subject: [Xen-devel] Xen 4.3 development update
> 
> = Timeline =
> 
> We are planning on a 9-month release cycle.  Based on that, below are
> our estimated dates:
> * Feature Freeze: 1 March, 2013
> * First RC: 15 April 2013
> * Release: 1 June 2013
> 
> The RCs and release will of course depend on stability and bugs, and
> will therefore be fairly unpredictable.  The feature freeze may be
> slipped for especially important features which are near completion.
> 
> = Feature tracking =
> 
> Below is a list of features we're tracking for this release.  Please
> respond to this mail with any updates to the status.  If the status is
> "?", as most of them are, please respond with the status!  Example
> statuses include "not started", "in progress", "initial implementation
> submitted for review", "patches submitted".
> 
> There are a number of items whose owners are marked as "?".  If you are
> working on this, or know who is working on it, please respond and let
> me know.  Alternately, if you would *like* to work on it, please let me
> know as well.
> 
> And if there is something you're working on you'd like tracked, please
> respond, and I will add it to the list.
> 
> 
> * PVH mode, domU (w/ Linux)
>   owner: mukesh@oracle
>   status: ?
> 
> * PVH mode, dom0 (w/ Linux)
>   owner: mukesh@oracle
>   status: ?
> 
> * Event channel scalability
>   owner: attilio@citrix
>   status: ?
>   Increase limit on event channels (currently 1024 for 32-bit guests,
>   4096 for 64-bit guests)
> 
> * ARM server port
>   owner: ijc@citrix
>   status: Core hypervisor patches accepted; Linux paches pending
> 
> * NUMA scheduler affinity
>   critical
>   owner: dario@citrix
>   status: ?
> 
> * NUMA Memory migration
>   owner: dario@citrix
>   status: ?
> 
> * blktap3
>   owner: thanos@citrix
>   status: ?
In progress
> 
> * Default to QEMU upstream
>  - qemu-based stubdom (Linux or BSD libc)
>    owner: anthony@citrix
>    status: ?
>    qemu-upstream needs a more fully-featured libc than exists in
>    minios.  Either work on a minimalist linux-based stubdom with
>    glibc, or port one of the BSD libcs to minios.
> 
>  - pci pass-thru
>    owner: anthony@citrix
>    status: ?
> 
> * Persistent grants
>   owner: @citrix
>   status: ?
> 
> * Multi-page blk rings
>  - blkback in kernel (konrad@oracle, ?@intel)
>  - qemu blkback
>   status: ?
> 
> * Multi-page net protocol
>   owner: ?
>   status: ?
>   expand the network ring protocol to allow multiple pages for
>   increased throughput
> 
> * Scalability: 16TiB of RAM
>   owner: jan@suse
>   status: ?
> 
> * libvirt integration
>   owner: ?
>   status: ?
>   To begin with, we need someone to go and make some lists:
>   - Features available in libvirt/KVM not available in libvirt/Xen
>   - Features available in xl/Xen but not available in libvirt/Xen
> 
> * xl vm-{export,import}
>   owner: ?
>   status: ?
>   Allow xl to import and export VMs to other formats; particularly
>   ovf, perhaps the XenServer format, or more.
> 
> 
> * xl USB pass-through for PV guests
>   owner: ?
>   status: ?
>   - Port the xend PV pass-through functionality to xl.
>   - Make sure qemu-based USB with qemu-upstream works
>   - Upstream the Linux frontend/backend drivers
> 
> * openvswitch toostack integration
>   owner: roger@citrix
>   status: Sample script posted by Bastian ("[RFC] openvswitch support
> script")
> 
> * Rationalized backend scripts (incl. driver domains)
>   owner: roger@citrix
>   status: ?
> 
> * Linux console improvements
>   owner: jan@suse
>   -EHCI debug port (done, to be submitted)
>   -xHCI debug port
>   -Firewire
> 
> * CPUID-based idle (don't rely on ACPI info f/ dom0)
>   owner: jan@suse
>   status: done, to be submitted
> 
> * Remove hardcoded mobprobe's in xencommons
>   owner: ?
>   status: ?
> 
> * Make storage migration possible
>   owner: ?
>   status: ?
>   There needs to be a way, either via command-line or via some hooks,
>   that someone can build a "storage migration" feature on top of libxl
>   or xl.
> 
> * Full-VM snapshotting
>   owner: ?
>   status: ?
>   Have a way of coordinating the taking and restoring of VM memory and
>   disk snapshots.  This would involve some investigation into the best
>   way to accomplish this.
> 
> * VM Cloning
>   owner: ?
>   status: May need review
>   Again, a way of coordinating the memory and disk aspects.  Research
>   into the best way to do this would probably go along with the
>   snapshotting feature.
> 
> * Memory: Replace PoD with paging mechanism
>   owner: george@citrix
>   status: May need review
> 
> * PV audio (audio for stubdom qemu)
>   owner: stefano.panella@citrix
>   status: ?
> 
> * Managed domains?
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Sep 20 15:50:44 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Sep 2012 15:50:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TEj1K-0003uD-MX; Thu, 20 Sep 2012 15:50:30 +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 1TEj1J-0003tu-4C
	for xen-devel@lists.xen.org; Thu, 20 Sep 2012 15:50:29 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1348156221!4785761!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21792 invoked from network); 20 Sep 2012 15:50:21 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-14.tower-27.messagelabs.com with SMTP;
	20 Sep 2012 15:50:21 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 20 Sep 2012 16:50:20 +0100
Message-Id: <505B5772020000780009CBE7@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 20 Sep 2012 16:50:42 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Andres Lagar-Cavilla" <andreslc@gridcentric.ca>
References: <40b91bed1275b13e191f.1347550068@xdev.gridcentric.ca>
	<505A024E020000780009C602@nat28.tlf.novell.com>
	<45FC1469-4B51-4A53-A9D8-2012954907C3@gridcentric.ca>
In-Reply-To: <45FC1469-4B51-4A53-A9D8-2012954907C3@gridcentric.ca>
Mime-Version: 1.0
Content-Disposition: inline
Cc: tim@xen.org, keir@xen.org, Andres Lagar-Cavilla <andres@lagarcavilla.org>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] Extra check in grant table code for mapping
 of shared frame
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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+IE9uIDIwLjA5LjEyIGF0IDE3OjMwLCBBbmRyZXMgTGFnYXItQ2F2aWxsYSA8YW5kcmVzbGNA
Z3JpZGNlbnRyaWMuY2E+IHdyb3RlOgo+IE9uIFNlcCAxOSwgMjAxMiwgYXQgMTE6MzUgQU0sIEph
biBCZXVsaWNoIHdyb3RlOgo+IAo+Pj4+PiBPbiAxMy4wOS4xMiBhdCAxNzoyNywgQW5kcmVzIExh
Z2FyLUNhdmlsbGEgPGFuZHJlc0BsYWdhcmNhdmlsbGEub3JnPiB3cm90ZToKPj4+IC0tLSBhL3hl
bi9jb21tb24vZ3JhbnRfdGFibGUuYwo+Pj4gKysrIGIveGVuL2NvbW1vbi9ncmFudF90YWJsZS5j
Cj4+PiBAQCAtNjQ5LDkgKzY0OSwxMiBAQCBfX2dudHRhYl9tYXBfZ3JhbnRfcmVmKAo+Pj4gICAg
IH0KPj4+ICAgICBlbHNlIGlmICggb3duZXIgPT0gcmQgfHwgb3duZXIgPT0gZG9tX2NvdyApCj4+
PiAgICAgewo+Pj4gLSAgICAgICAgaWYgKCBnbnR0YWJfaG9zdF9tYXBwaW5nX2dldF9wYWdlX3R5
cGUob3AsIGxkLCByZCkgJiYKPj4+IC0gICAgICAgICAgICAgIWdldF9wYWdlX3R5cGUocGcsIFBH
VF93cml0YWJsZV9wYWdlKSApCj4+PiAtICAgICAgICAgICAgZ290byBjb3VsZF9ub3RfcGluOwo+
Pj4gKyAgICAgICAgaWYgKCBnbnR0YWJfaG9zdF9tYXBwaW5nX2dldF9wYWdlX3R5cGUob3AsIGxk
LCByZCkgKQo+Pj4gKyAgICAgICAgewo+Pj4gKyAgICAgICAgICAgIGlmICggKG93bmVyID09IGRv
bV9jb3cpIHx8Cj4+PiArICAgICAgICAgICAgICAgICAhZ2V0X3BhZ2VfdHlwZShwZywgUEdUX3dy
aXRhYmxlX3BhZ2UpICkKPj4+ICsgICAgICAgICAgICAgICAgZ290byBjb3VsZF9ub3RfcGluOwo+
Pj4gKyAgICAgICAgfQo+Pj4gCj4+PiAgICAgICAgIG5yX2dldHMrKzsKPj4+ICAgICAgICAgaWYg
KCBvcC0+ZmxhZ3MgJiBHTlRNQVBfaG9zdF9tYXAgKQo+PiAKPj4gSXNuJ3QgdGhhdCBvbmx5IGhh
bGYgb2YgaXQsIGluIHRoYXQgdGhlIGVycm9yL3VubWFwIHBhdGhzIG5lZWQgdG8KPj4gYWxzbyBj
b25zaWRlciB0aGF0IGdldF9wYWdlX3R5cGUoKSB3YXNuJ3QgY2FsbGVkPyBUaGVyZSdzCj4+IHF1
aXRlIGEgZmV3IGNhbGxzIHRvIGdudHRhYl9ob3N0X21hcHBpbmdfZ2V0X3BhZ2VfdHlwZSgpLwo+
PiBwdXRfcGFnZV90eXBlKCkgc2VxdWVuY2VzIHRoZXJlLgo+IAo+IEkgdGhpbmsgdGhpcyBpcyBj
b3ZlcmVkLiBjb3VsZF9ub3RfcGluIHdpbGwgY2FzY2FkZSBpbnRvIHVuZG9fb3V0LCBhbmQgCj4g
bnJfZ2V0cyByZW1haW5zIGF0IHplcm8gYXQgdGhpcyBwb2ludC4gVGhlbjoKPiAgdW5kb19vdXQ6
Cj4gICAgIGlmICggbnJfZ2V0cyA+IDEgKQo+ICAgICB7Cj4gICAgICAgIOKApgo+ICAgICB9Cj4g
ICAgIGlmICggbnJfZ2V0cyA+IDAgKQo+ICAgICB7Cj4gICAgICAgICBpZiAoIGdudHRhYl9ob3N0
X21hcHBpbmdfZ2V0X3BhZ2VfdHlwZShvcCwgbGQsIHJkKSApCj4gICAgICAgICAgICAgcHV0X3Bh
Z2VfdHlwZShwZyk7Cj4gICAgICAgICAgICAgLi4uCj4gCj4gaS5lLiBwdXRfcGFnZV90eXBlIHdp
bGwgbm90IGJlIGNhbGxlZC4gVGhpcyBpcyByZWFsbHkgdHJpY2t5IGNvZGUhCgpPa2F5LCB0aGF0
IHBhdGggaW5kZWVkIGxvb2tzIHNhZmUgdGhyb3VnaCB0aGlzIG5yX2dldHMgdXNlLgoKT2gsIGFu
ZCBJIHNlZSwgdGhlIG90aGVyIGNhc2VzIGFyZSBvZiBubyBjb25jZXJuIGJlY2F1c2UKdGhlIGNo
ZWNrIHlvdSBhZGRlZCBsZWFkcyBkaXJlY3RseSB0byB0aGUgZmFpbHVyZSBwYXRoLgoKVGhhbmtz
IGZvciBjbGFyaWZ5aW5nLApKYW4KCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbi5v
cmcKaHR0cDovL2xpc3RzLnhlbi5vcmcveGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Thu Sep 20 15:50:44 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Sep 2012 15:50:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TEj1K-0003uD-MX; Thu, 20 Sep 2012 15:50:30 +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 1TEj1J-0003tu-4C
	for xen-devel@lists.xen.org; Thu, 20 Sep 2012 15:50:29 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1348156221!4785761!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21792 invoked from network); 20 Sep 2012 15:50:21 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-14.tower-27.messagelabs.com with SMTP;
	20 Sep 2012 15:50:21 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 20 Sep 2012 16:50:20 +0100
Message-Id: <505B5772020000780009CBE7@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 20 Sep 2012 16:50:42 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Andres Lagar-Cavilla" <andreslc@gridcentric.ca>
References: <40b91bed1275b13e191f.1347550068@xdev.gridcentric.ca>
	<505A024E020000780009C602@nat28.tlf.novell.com>
	<45FC1469-4B51-4A53-A9D8-2012954907C3@gridcentric.ca>
In-Reply-To: <45FC1469-4B51-4A53-A9D8-2012954907C3@gridcentric.ca>
Mime-Version: 1.0
Content-Disposition: inline
Cc: tim@xen.org, keir@xen.org, Andres Lagar-Cavilla <andres@lagarcavilla.org>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] Extra check in grant table code for mapping
 of shared frame
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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+IE9uIDIwLjA5LjEyIGF0IDE3OjMwLCBBbmRyZXMgTGFnYXItQ2F2aWxsYSA8YW5kcmVzbGNA
Z3JpZGNlbnRyaWMuY2E+IHdyb3RlOgo+IE9uIFNlcCAxOSwgMjAxMiwgYXQgMTE6MzUgQU0sIEph
biBCZXVsaWNoIHdyb3RlOgo+IAo+Pj4+PiBPbiAxMy4wOS4xMiBhdCAxNzoyNywgQW5kcmVzIExh
Z2FyLUNhdmlsbGEgPGFuZHJlc0BsYWdhcmNhdmlsbGEub3JnPiB3cm90ZToKPj4+IC0tLSBhL3hl
bi9jb21tb24vZ3JhbnRfdGFibGUuYwo+Pj4gKysrIGIveGVuL2NvbW1vbi9ncmFudF90YWJsZS5j
Cj4+PiBAQCAtNjQ5LDkgKzY0OSwxMiBAQCBfX2dudHRhYl9tYXBfZ3JhbnRfcmVmKAo+Pj4gICAg
IH0KPj4+ICAgICBlbHNlIGlmICggb3duZXIgPT0gcmQgfHwgb3duZXIgPT0gZG9tX2NvdyApCj4+
PiAgICAgewo+Pj4gLSAgICAgICAgaWYgKCBnbnR0YWJfaG9zdF9tYXBwaW5nX2dldF9wYWdlX3R5
cGUob3AsIGxkLCByZCkgJiYKPj4+IC0gICAgICAgICAgICAgIWdldF9wYWdlX3R5cGUocGcsIFBH
VF93cml0YWJsZV9wYWdlKSApCj4+PiAtICAgICAgICAgICAgZ290byBjb3VsZF9ub3RfcGluOwo+
Pj4gKyAgICAgICAgaWYgKCBnbnR0YWJfaG9zdF9tYXBwaW5nX2dldF9wYWdlX3R5cGUob3AsIGxk
LCByZCkgKQo+Pj4gKyAgICAgICAgewo+Pj4gKyAgICAgICAgICAgIGlmICggKG93bmVyID09IGRv
bV9jb3cpIHx8Cj4+PiArICAgICAgICAgICAgICAgICAhZ2V0X3BhZ2VfdHlwZShwZywgUEdUX3dy
aXRhYmxlX3BhZ2UpICkKPj4+ICsgICAgICAgICAgICAgICAgZ290byBjb3VsZF9ub3RfcGluOwo+
Pj4gKyAgICAgICAgfQo+Pj4gCj4+PiAgICAgICAgIG5yX2dldHMrKzsKPj4+ICAgICAgICAgaWYg
KCBvcC0+ZmxhZ3MgJiBHTlRNQVBfaG9zdF9tYXAgKQo+PiAKPj4gSXNuJ3QgdGhhdCBvbmx5IGhh
bGYgb2YgaXQsIGluIHRoYXQgdGhlIGVycm9yL3VubWFwIHBhdGhzIG5lZWQgdG8KPj4gYWxzbyBj
b25zaWRlciB0aGF0IGdldF9wYWdlX3R5cGUoKSB3YXNuJ3QgY2FsbGVkPyBUaGVyZSdzCj4+IHF1
aXRlIGEgZmV3IGNhbGxzIHRvIGdudHRhYl9ob3N0X21hcHBpbmdfZ2V0X3BhZ2VfdHlwZSgpLwo+
PiBwdXRfcGFnZV90eXBlKCkgc2VxdWVuY2VzIHRoZXJlLgo+IAo+IEkgdGhpbmsgdGhpcyBpcyBj
b3ZlcmVkLiBjb3VsZF9ub3RfcGluIHdpbGwgY2FzY2FkZSBpbnRvIHVuZG9fb3V0LCBhbmQgCj4g
bnJfZ2V0cyByZW1haW5zIGF0IHplcm8gYXQgdGhpcyBwb2ludC4gVGhlbjoKPiAgdW5kb19vdXQ6
Cj4gICAgIGlmICggbnJfZ2V0cyA+IDEgKQo+ICAgICB7Cj4gICAgICAgIOKApgo+ICAgICB9Cj4g
ICAgIGlmICggbnJfZ2V0cyA+IDAgKQo+ICAgICB7Cj4gICAgICAgICBpZiAoIGdudHRhYl9ob3N0
X21hcHBpbmdfZ2V0X3BhZ2VfdHlwZShvcCwgbGQsIHJkKSApCj4gICAgICAgICAgICAgcHV0X3Bh
Z2VfdHlwZShwZyk7Cj4gICAgICAgICAgICAgLi4uCj4gCj4gaS5lLiBwdXRfcGFnZV90eXBlIHdp
bGwgbm90IGJlIGNhbGxlZC4gVGhpcyBpcyByZWFsbHkgdHJpY2t5IGNvZGUhCgpPa2F5LCB0aGF0
IHBhdGggaW5kZWVkIGxvb2tzIHNhZmUgdGhyb3VnaCB0aGlzIG5yX2dldHMgdXNlLgoKT2gsIGFu
ZCBJIHNlZSwgdGhlIG90aGVyIGNhc2VzIGFyZSBvZiBubyBjb25jZXJuIGJlY2F1c2UKdGhlIGNo
ZWNrIHlvdSBhZGRlZCBsZWFkcyBkaXJlY3RseSB0byB0aGUgZmFpbHVyZSBwYXRoLgoKVGhhbmtz
IGZvciBjbGFyaWZ5aW5nLApKYW4KCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbi5v
cmcKaHR0cDovL2xpc3RzLnhlbi5vcmcveGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Thu Sep 20 15:52:09 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Sep 2012 15:52: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 1TEj2h-00043m-CK; Thu, 20 Sep 2012 15:51:55 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1TEj2f-00043T-Lj
	for xen-devel@lists.xensource.com; Thu, 20 Sep 2012 15:51:53 +0000
Received: from [85.158.139.83:61644] by server-1.bemta-5.messagelabs.com id
	7C/9A-04809-89B3B505; Thu, 20 Sep 2012 15:51:52 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1348156308!28572057!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNzYxMzI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22371 invoked from network); 20 Sep 2012 15:51:52 -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;
	20 Sep 2012 15:51:52 -0000
X-IronPort-AV: E=Sophos;i="4.80,454,1344211200"; d="scan'208";a="208767663"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Sep 2012 15:48:23 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Thu, 20 Sep 2012 11:48:21 -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 1TEiz9-0002MB-Rq;
	Thu, 20 Sep 2012 16:48:15 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: linux-kernel@vger.kernel.org
Date: Thu, 20 Sep 2012 16:47:42 +0100
Message-ID: <1348156062-11476-1-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.9.5
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com, Ian.Campbell@citrix.com, pawel.moll@arm.com,
	konrad.wilk@oracle.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Arnd Bergmann <arnd@arndb.de>, linux-arm-kernel@lists.infradead.org
Subject: [Xen-devel] [PATCH v2] arm: introduce a DTS for Xen unprivileged
	virtual 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

Given that the xenvm machine is based on vexpress but with an extremely
limited selection of peripherals (the guest is supposed to use virtual
devices instead), add "xen,xenvm" to the list of compatible machines in
mach-vexpress.


Changes in v2:

- remove include skeleton;
- use #address-cells = <2> and #size-cells = <2>;
- remove the debug bootargs;
- use memory@80000000 instead of memory;
- remove the ranges and interrupt-map from the motherboard node;
- set the machine compatible to "xen,xenvm-4.2", "xen,xenvm";
- rename the dts file to xenvm-4.2.dts;
- add "xen,xenvm" to the list of compatible DT strings to mach-vexpress.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
CC: Pawel Moll <pawel.moll@arm.com>
CC: Arnd Bergmann <arnd@arndb.de>
---
 arch/arm/boot/dts/xenvm-4.2.dts      |   64 ++++++++++++++++++++++++++++++++++
 arch/arm/mach-vexpress/Makefile.boot |    3 +-
 arch/arm/mach-vexpress/v2m.c         |    1 +
 3 files changed, 67 insertions(+), 1 deletions(-)
 create mode 100644 arch/arm/boot/dts/xenvm-4.2.dts

diff --git a/arch/arm/boot/dts/xenvm-4.2.dts b/arch/arm/boot/dts/xenvm-4.2.dts
new file mode 100644
index 0000000..03d7c84
--- /dev/null
+++ b/arch/arm/boot/dts/xenvm-4.2.dts
@@ -0,0 +1,64 @@
+/*
+ * Xen Virtual Machine for unprivileged guests
+ *
+ * Based on ARM Ltd. Versatile Express CoreTile Express (single CPU)
+ * Cortex-A15 MPCore (V2P-CA15)
+ *
+ */
+
+/dts-v1/;
+
+/ {
+	model = "XENVM-4.2";
+	compatible = "xen,xenvm-4.2", "xen,xenvm";
+	interrupt-parent = <&gic>;
+	#address-cells = <2>;
+	#size-cells = <2>;
+
+	chosen {
+		bootargs = "console=hvc0 root=/dev/xvda";
+	};
+
+	cpus {
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		cpu@0 {
+			device_type = "cpu";
+			compatible = "arm,cortex-a15";
+			reg = <0>;
+		};
+	};
+
+	memory@80000000 {
+		device_type = "memory";
+		reg = <0 0x80000000 0 0x08000000>;
+	};
+
+	gic: interrupt-controller@2c001000 {
+		compatible = "arm,cortex-a15-gic", "arm,cortex-a9-gic";
+		#interrupt-cells = <3>;
+		#address-cells = <0>;
+		interrupt-controller;
+		reg = <0 0x2c001000 0 0x1000>,
+		      <0 0x2c002000 0 0x100>;
+	};
+
+	timer {
+		compatible = "arm,armv7-timer";
+		interrupts = <1 13 0xf08>,
+			     <1 14 0xf08>,
+			     <1 11 0xf08>,
+			     <1 10 0xf08>;
+	};
+
+	hypervisor {
+		compatible = "xen,xen-4.2", "xen,xen";
+		reg = <0 0xb0000000 0 0x20000>;
+		interrupts = <1 15 0xf08>;
+	};
+
+	motherboard {
+		arm,v2m-memory-map = "rs1";
+	};
+};
diff --git a/arch/arm/mach-vexpress/Makefile.boot b/arch/arm/mach-vexpress/Makefile.boot
index 318d308..38dbaac 100644
--- a/arch/arm/mach-vexpress/Makefile.boot
+++ b/arch/arm/mach-vexpress/Makefile.boot
@@ -7,4 +7,5 @@ initrd_phys-y	:= 0x60800000
 dtb-$(CONFIG_ARCH_VEXPRESS_DT)	+= vexpress-v2p-ca5s.dtb \
 				   vexpress-v2p-ca9.dtb \
 				   vexpress-v2p-ca15-tc1.dtb \
-				   vexpress-v2p-ca15_a7.dtb
+				   vexpress-v2p-ca15_a7.dtb \
+				   xenvm-4.2.dtb
diff --git a/arch/arm/mach-vexpress/v2m.c b/arch/arm/mach-vexpress/v2m.c
index 4e567f7..9545b70 100644
--- a/arch/arm/mach-vexpress/v2m.c
+++ b/arch/arm/mach-vexpress/v2m.c
@@ -659,6 +659,7 @@ static void __init v2m_dt_init(void)
 
 const static char *v2m_dt_match[] __initconst = {
 	"arm,vexpress",
+	"xen,xenvm",
 	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 Sep 20 15:52:09 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Sep 2012 15:52: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 1TEj2h-00043m-CK; Thu, 20 Sep 2012 15:51:55 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1TEj2f-00043T-Lj
	for xen-devel@lists.xensource.com; Thu, 20 Sep 2012 15:51:53 +0000
Received: from [85.158.139.83:61644] by server-1.bemta-5.messagelabs.com id
	7C/9A-04809-89B3B505; Thu, 20 Sep 2012 15:51:52 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1348156308!28572057!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNzYxMzI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22371 invoked from network); 20 Sep 2012 15:51:52 -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;
	20 Sep 2012 15:51:52 -0000
X-IronPort-AV: E=Sophos;i="4.80,454,1344211200"; d="scan'208";a="208767663"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Sep 2012 15:48:23 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Thu, 20 Sep 2012 11:48:21 -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 1TEiz9-0002MB-Rq;
	Thu, 20 Sep 2012 16:48:15 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: linux-kernel@vger.kernel.org
Date: Thu, 20 Sep 2012 16:47:42 +0100
Message-ID: <1348156062-11476-1-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.9.5
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com, Ian.Campbell@citrix.com, pawel.moll@arm.com,
	konrad.wilk@oracle.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Arnd Bergmann <arnd@arndb.de>, linux-arm-kernel@lists.infradead.org
Subject: [Xen-devel] [PATCH v2] arm: introduce a DTS for Xen unprivileged
	virtual 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

Given that the xenvm machine is based on vexpress but with an extremely
limited selection of peripherals (the guest is supposed to use virtual
devices instead), add "xen,xenvm" to the list of compatible machines in
mach-vexpress.


Changes in v2:

- remove include skeleton;
- use #address-cells = <2> and #size-cells = <2>;
- remove the debug bootargs;
- use memory@80000000 instead of memory;
- remove the ranges and interrupt-map from the motherboard node;
- set the machine compatible to "xen,xenvm-4.2", "xen,xenvm";
- rename the dts file to xenvm-4.2.dts;
- add "xen,xenvm" to the list of compatible DT strings to mach-vexpress.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
CC: Pawel Moll <pawel.moll@arm.com>
CC: Arnd Bergmann <arnd@arndb.de>
---
 arch/arm/boot/dts/xenvm-4.2.dts      |   64 ++++++++++++++++++++++++++++++++++
 arch/arm/mach-vexpress/Makefile.boot |    3 +-
 arch/arm/mach-vexpress/v2m.c         |    1 +
 3 files changed, 67 insertions(+), 1 deletions(-)
 create mode 100644 arch/arm/boot/dts/xenvm-4.2.dts

diff --git a/arch/arm/boot/dts/xenvm-4.2.dts b/arch/arm/boot/dts/xenvm-4.2.dts
new file mode 100644
index 0000000..03d7c84
--- /dev/null
+++ b/arch/arm/boot/dts/xenvm-4.2.dts
@@ -0,0 +1,64 @@
+/*
+ * Xen Virtual Machine for unprivileged guests
+ *
+ * Based on ARM Ltd. Versatile Express CoreTile Express (single CPU)
+ * Cortex-A15 MPCore (V2P-CA15)
+ *
+ */
+
+/dts-v1/;
+
+/ {
+	model = "XENVM-4.2";
+	compatible = "xen,xenvm-4.2", "xen,xenvm";
+	interrupt-parent = <&gic>;
+	#address-cells = <2>;
+	#size-cells = <2>;
+
+	chosen {
+		bootargs = "console=hvc0 root=/dev/xvda";
+	};
+
+	cpus {
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		cpu@0 {
+			device_type = "cpu";
+			compatible = "arm,cortex-a15";
+			reg = <0>;
+		};
+	};
+
+	memory@80000000 {
+		device_type = "memory";
+		reg = <0 0x80000000 0 0x08000000>;
+	};
+
+	gic: interrupt-controller@2c001000 {
+		compatible = "arm,cortex-a15-gic", "arm,cortex-a9-gic";
+		#interrupt-cells = <3>;
+		#address-cells = <0>;
+		interrupt-controller;
+		reg = <0 0x2c001000 0 0x1000>,
+		      <0 0x2c002000 0 0x100>;
+	};
+
+	timer {
+		compatible = "arm,armv7-timer";
+		interrupts = <1 13 0xf08>,
+			     <1 14 0xf08>,
+			     <1 11 0xf08>,
+			     <1 10 0xf08>;
+	};
+
+	hypervisor {
+		compatible = "xen,xen-4.2", "xen,xen";
+		reg = <0 0xb0000000 0 0x20000>;
+		interrupts = <1 15 0xf08>;
+	};
+
+	motherboard {
+		arm,v2m-memory-map = "rs1";
+	};
+};
diff --git a/arch/arm/mach-vexpress/Makefile.boot b/arch/arm/mach-vexpress/Makefile.boot
index 318d308..38dbaac 100644
--- a/arch/arm/mach-vexpress/Makefile.boot
+++ b/arch/arm/mach-vexpress/Makefile.boot
@@ -7,4 +7,5 @@ initrd_phys-y	:= 0x60800000
 dtb-$(CONFIG_ARCH_VEXPRESS_DT)	+= vexpress-v2p-ca5s.dtb \
 				   vexpress-v2p-ca9.dtb \
 				   vexpress-v2p-ca15-tc1.dtb \
-				   vexpress-v2p-ca15_a7.dtb
+				   vexpress-v2p-ca15_a7.dtb \
+				   xenvm-4.2.dtb
diff --git a/arch/arm/mach-vexpress/v2m.c b/arch/arm/mach-vexpress/v2m.c
index 4e567f7..9545b70 100644
--- a/arch/arm/mach-vexpress/v2m.c
+++ b/arch/arm/mach-vexpress/v2m.c
@@ -659,6 +659,7 @@ static void __init v2m_dt_init(void)
 
 const static char *v2m_dt_match[] __initconst = {
 	"arm,vexpress",
+	"xen,xenvm",
 	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 Sep 20 16:10:17 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Sep 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 1TEjKG-00056A-Ml; Thu, 20 Sep 2012 16:10:04 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1TEjKF-000563-5o
	for xen-devel@lists.xen.org; Thu, 20 Sep 2012 16:10:03 +0000
Received: from [85.158.139.83:40882] by server-9.bemta-5.messagelabs.com id
	E2/9D-20529-ADF3B505; Thu, 20 Sep 2012 16:10:02 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1348157401!24077960!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14918 invoked from network); 20 Sep 2012 16:10:01 -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;
	20 Sep 2012 16:10:01 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 20 Sep 2012 17:10:01 +0100
Message-Id: <505B5C0C020000780009CC14@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 20 Sep 2012 17:10:20 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Oliver Chick" <oliver.chick@citrix.com>
References: <1348051887-21885-1-git-send-email-oliver.chick@citrix.com>
	<505AF126.2050806@citrix.com>
	<1348140637.24539.32.camel@oliverchick-Precision-WorkStation-T3400>
	<505B1EB9020000780009CA6E@nat28.tlf.novell.com>
	<20120920134951.GC1998@localhost.localdomain>
	<1348150422.24539.58.camel@oliverchick-Precision-WorkStation-T3400>
In-Reply-To: <1348150422.24539.58.camel@oliverchick-Precision-WorkStation-T3400>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	David Vrabel <david.vrabel@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] Persistent grant maps for xen blk drivers
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 20.09.12 at 16:13, Oliver Chick <oliver.chick@citrix.com> wrote:
> 3) Having blkback inform blkfront on startup as to how many grefs it is
> willing to persistently-map. We then hit the same question again though:
> what should be do if blkfront ignores this limit?

Not really - if any information coming from the backend is being
ignored by the frontend, then it certainly can't expect consistent
performance.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 20 16:10:17 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Sep 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 1TEjKG-00056A-Ml; Thu, 20 Sep 2012 16:10:04 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1TEjKF-000563-5o
	for xen-devel@lists.xen.org; Thu, 20 Sep 2012 16:10:03 +0000
Received: from [85.158.139.83:40882] by server-9.bemta-5.messagelabs.com id
	E2/9D-20529-ADF3B505; Thu, 20 Sep 2012 16:10:02 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1348157401!24077960!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14918 invoked from network); 20 Sep 2012 16:10:01 -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;
	20 Sep 2012 16:10:01 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 20 Sep 2012 17:10:01 +0100
Message-Id: <505B5C0C020000780009CC14@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 20 Sep 2012 17:10:20 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Oliver Chick" <oliver.chick@citrix.com>
References: <1348051887-21885-1-git-send-email-oliver.chick@citrix.com>
	<505AF126.2050806@citrix.com>
	<1348140637.24539.32.camel@oliverchick-Precision-WorkStation-T3400>
	<505B1EB9020000780009CA6E@nat28.tlf.novell.com>
	<20120920134951.GC1998@localhost.localdomain>
	<1348150422.24539.58.camel@oliverchick-Precision-WorkStation-T3400>
In-Reply-To: <1348150422.24539.58.camel@oliverchick-Precision-WorkStation-T3400>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	David Vrabel <david.vrabel@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] Persistent grant maps for xen blk drivers
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 20.09.12 at 16:13, Oliver Chick <oliver.chick@citrix.com> wrote:
> 3) Having blkback inform blkfront on startup as to how many grefs it is
> willing to persistently-map. We then hit the same question again though:
> what should be do if blkfront ignores this limit?

Not really - if any information coming from the backend is being
ignored by the frontend, then it certainly can't expect consistent
performance.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 20 16:23:59 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Sep 2012 16:23:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TEjXS-0005P2-1u; Thu, 20 Sep 2012 16:23:42 +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 1TEjXQ-0005Ox-Tr
	for xen-devel@lists.xensource.com; Thu, 20 Sep 2012 16:23:41 +0000
Received: from [85.158.139.83:53137] by server-7.bemta-5.messagelabs.com id
	3E/47-19703-C034B505; Thu, 20 Sep 2012 16:23:40 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-14.tower-182.messagelabs.com!1348158219!27145253!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA1MDk4NTY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28321 invoked from network); 20 Sep 2012 16:23:39 -0000
Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25)
	by server-14.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 20 Sep 2012 16:23: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 5B8721CA2;
	Thu, 20 Sep 2012 19:23:38 +0300 (EEST)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id B1DD62005D; Thu, 20 Sep 2012 19:23:37 +0300 (EEST)
Date: Thu, 20 Sep 2012 19:23:37 +0300
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: William Dauchy <wdauchy@gmail.com>
Message-ID: <20120920162337.GB8912@reaktio.net>
References: <CAJ75kXZm-BqWdL2O41XkSE1VCdd4ruW=+CqDmR1b3=701RnXmw@mail.gmail.com>
	<20120918133650.GC12053@phenom.dumpdata.com>
	<CAJ75kXZEaCj4Jqs_qm46d7U-s1C2hkAONs8c5Audrw2c3X=nBA@mail.gmail.com>
	<20120920134851.GB1998@localhost.localdomain>
	<CAJ75kXZ0depUJF_h0yok-r4aL0TBGnqTpW_PKT4Q7P1_6R4X2A@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAJ75kXZ0depUJF_h0yok-r4aL0TBGnqTpW_PKT4Q7P1_6R4X2A@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] Error getting mfn
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Sep 20, 2012 at 04:15:00PM +0200, William Dauchy wrote:
> On Thu, Sep 20, 2012 at 3:48 PM, Konrad Rzeszutek Wilk
> <konrad.wilk@oracle.com> wrote:
> > I really need to see the Linux command line as well. I am not
> > sure why I am not seeing it thought? What are your Linux commnad
> > line parameters? Can you do 'cat /proc/cmdline' after Linux has booted?
> > (if it has booted).
> 
> sync_console loglvl=all dom0_max_vcpus=1 verbose=y console=hvc0 debug
> loglevel=8
> did I forgot something?
>

The ones you listed are Xen *hypervisor* cmdline options.
Konrad needs also the options for dom0 *Linux kernel*.

You need to set both.

-- Pasi


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 20 16:23:59 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Sep 2012 16:23:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TEjXS-0005P2-1u; Thu, 20 Sep 2012 16:23:42 +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 1TEjXQ-0005Ox-Tr
	for xen-devel@lists.xensource.com; Thu, 20 Sep 2012 16:23:41 +0000
Received: from [85.158.139.83:53137] by server-7.bemta-5.messagelabs.com id
	3E/47-19703-C034B505; Thu, 20 Sep 2012 16:23:40 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-14.tower-182.messagelabs.com!1348158219!27145253!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA1MDk4NTY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28321 invoked from network); 20 Sep 2012 16:23:39 -0000
Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25)
	by server-14.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 20 Sep 2012 16:23: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 5B8721CA2;
	Thu, 20 Sep 2012 19:23:38 +0300 (EEST)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id B1DD62005D; Thu, 20 Sep 2012 19:23:37 +0300 (EEST)
Date: Thu, 20 Sep 2012 19:23:37 +0300
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: William Dauchy <wdauchy@gmail.com>
Message-ID: <20120920162337.GB8912@reaktio.net>
References: <CAJ75kXZm-BqWdL2O41XkSE1VCdd4ruW=+CqDmR1b3=701RnXmw@mail.gmail.com>
	<20120918133650.GC12053@phenom.dumpdata.com>
	<CAJ75kXZEaCj4Jqs_qm46d7U-s1C2hkAONs8c5Audrw2c3X=nBA@mail.gmail.com>
	<20120920134851.GB1998@localhost.localdomain>
	<CAJ75kXZ0depUJF_h0yok-r4aL0TBGnqTpW_PKT4Q7P1_6R4X2A@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAJ75kXZ0depUJF_h0yok-r4aL0TBGnqTpW_PKT4Q7P1_6R4X2A@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] Error getting mfn
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Sep 20, 2012 at 04:15:00PM +0200, William Dauchy wrote:
> On Thu, Sep 20, 2012 at 3:48 PM, Konrad Rzeszutek Wilk
> <konrad.wilk@oracle.com> wrote:
> > I really need to see the Linux command line as well. I am not
> > sure why I am not seeing it thought? What are your Linux commnad
> > line parameters? Can you do 'cat /proc/cmdline' after Linux has booted?
> > (if it has booted).
> 
> sync_console loglvl=all dom0_max_vcpus=1 verbose=y console=hvc0 debug
> loglevel=8
> did I forgot something?
>

The ones you listed are Xen *hypervisor* cmdline options.
Konrad needs also the options for dom0 *Linux kernel*.

You need to set both.

-- Pasi


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 20 16:31:27 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Sep 2012 16:31:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TEjeZ-0005XT-Ul; Thu, 20 Sep 2012 16:31:03 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wdauchy@gmail.com>) id 1TEjeY-0005XM-Md
	for xen-devel@lists.xensource.com; Thu, 20 Sep 2012 16:31:02 +0000
X-Env-Sender: wdauchy@gmail.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1348158654!2480768!1
X-Originating-IP: [209.85.160.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19745 invoked from network); 20 Sep 2012 16:30:56 -0000
Received: from mail-pb0-f43.google.com (HELO mail-pb0-f43.google.com)
	(209.85.160.43)
	by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Sep 2012 16:30:56 -0000
Received: by pbbrq2 with SMTP id rq2so7068327pbb.30
	for <xen-devel@lists.xensource.com>;
	Thu, 20 Sep 2012 09:30: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:from:date:message-id:subject:to
	:cc:content-type:content-transfer-encoding;
	bh=GlWm7JWJXoEtN5zZs4aaKBhLcq6oLkV9PTB0xLQqJJY=;
	b=sUUsDCJqPigv7MgJR7yrxEQPMTFXk6cWQIvTEMQPUtYcsZ+WGBCZfb7mRc3ADavoYU
	AtOADnRtgLoSa3MiDM/K39uvOIqYiQM+IF/QoaLzvZTcnYTaEqVeLOyMas8Rgzby9WzJ
	wAonf1GQ8me/nvNLYbAPsDy6C7rVEPIiT8WrUgwsqQvV82IXvTcUqRDOLkNKNzAZu0k8
	Br4Gk2FlXL5uor0eZ9STr9zycXFk27LTmWyDllqR4JPsUAckLjcbcomhnO1uc5KtwS8M
	nBvM4sdqDkLqjMevjX6LEOlig2DOdxnkAnJJH75qDVRa6tU2lb9kG1kJvL5yqvH3Dd7t
	r5uQ==
Received: by 10.66.81.66 with SMTP id y2mr6532371pax.62.1348158653782; Thu, 20
	Sep 2012 09:30:53 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.68.135.42 with HTTP; Thu, 20 Sep 2012 09:30:33 -0700 (PDT)
In-Reply-To: <20120920162337.GB8912@reaktio.net>
References: <CAJ75kXZm-BqWdL2O41XkSE1VCdd4ruW=+CqDmR1b3=701RnXmw@mail.gmail.com>
	<20120918133650.GC12053@phenom.dumpdata.com>
	<CAJ75kXZEaCj4Jqs_qm46d7U-s1C2hkAONs8c5Audrw2c3X=nBA@mail.gmail.com>
	<20120920134851.GB1998@localhost.localdomain>
	<CAJ75kXZ0depUJF_h0yok-r4aL0TBGnqTpW_PKT4Q7P1_6R4X2A@mail.gmail.com>
	<20120920162337.GB8912@reaktio.net>
From: William Dauchy <wdauchy@gmail.com>
Date: Thu, 20 Sep 2012 18:30:33 +0200
Message-ID: <CAJ75kXaXbitBvosYp8Sv_548XbvdxU=M_NSSHTb_5d56=-n4nA@mail.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] Error getting mfn
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="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, Sep 20, 2012 at 6:23 PM, Pasi K=E4rkk=E4inen <pasik@iki.fi> wrote:
> You need to set both.

that's what I did, even know I did put some xen hypervisor options on
dom0, it doesn't change anything.
hypervisor:
console=3Dcom2 debug sync_console dom0_max_vcpus=3D1
dom0_mem=3D1024M,max:1024M loglvl=3Dall guest_loglvl=3Dinfo
dom0:
loglvl=3Dall verbose=3Dy console=3Dhvc0 debug loglevel=3D8
-- =

William

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 20 16:31:27 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Sep 2012 16:31:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TEjeZ-0005XT-Ul; Thu, 20 Sep 2012 16:31:03 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wdauchy@gmail.com>) id 1TEjeY-0005XM-Md
	for xen-devel@lists.xensource.com; Thu, 20 Sep 2012 16:31:02 +0000
X-Env-Sender: wdauchy@gmail.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1348158654!2480768!1
X-Originating-IP: [209.85.160.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19745 invoked from network); 20 Sep 2012 16:30:56 -0000
Received: from mail-pb0-f43.google.com (HELO mail-pb0-f43.google.com)
	(209.85.160.43)
	by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Sep 2012 16:30:56 -0000
Received: by pbbrq2 with SMTP id rq2so7068327pbb.30
	for <xen-devel@lists.xensource.com>;
	Thu, 20 Sep 2012 09:30: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:from:date:message-id:subject:to
	:cc:content-type:content-transfer-encoding;
	bh=GlWm7JWJXoEtN5zZs4aaKBhLcq6oLkV9PTB0xLQqJJY=;
	b=sUUsDCJqPigv7MgJR7yrxEQPMTFXk6cWQIvTEMQPUtYcsZ+WGBCZfb7mRc3ADavoYU
	AtOADnRtgLoSa3MiDM/K39uvOIqYiQM+IF/QoaLzvZTcnYTaEqVeLOyMas8Rgzby9WzJ
	wAonf1GQ8me/nvNLYbAPsDy6C7rVEPIiT8WrUgwsqQvV82IXvTcUqRDOLkNKNzAZu0k8
	Br4Gk2FlXL5uor0eZ9STr9zycXFk27LTmWyDllqR4JPsUAckLjcbcomhnO1uc5KtwS8M
	nBvM4sdqDkLqjMevjX6LEOlig2DOdxnkAnJJH75qDVRa6tU2lb9kG1kJvL5yqvH3Dd7t
	r5uQ==
Received: by 10.66.81.66 with SMTP id y2mr6532371pax.62.1348158653782; Thu, 20
	Sep 2012 09:30:53 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.68.135.42 with HTTP; Thu, 20 Sep 2012 09:30:33 -0700 (PDT)
In-Reply-To: <20120920162337.GB8912@reaktio.net>
References: <CAJ75kXZm-BqWdL2O41XkSE1VCdd4ruW=+CqDmR1b3=701RnXmw@mail.gmail.com>
	<20120918133650.GC12053@phenom.dumpdata.com>
	<CAJ75kXZEaCj4Jqs_qm46d7U-s1C2hkAONs8c5Audrw2c3X=nBA@mail.gmail.com>
	<20120920134851.GB1998@localhost.localdomain>
	<CAJ75kXZ0depUJF_h0yok-r4aL0TBGnqTpW_PKT4Q7P1_6R4X2A@mail.gmail.com>
	<20120920162337.GB8912@reaktio.net>
From: William Dauchy <wdauchy@gmail.com>
Date: Thu, 20 Sep 2012 18:30:33 +0200
Message-ID: <CAJ75kXaXbitBvosYp8Sv_548XbvdxU=M_NSSHTb_5d56=-n4nA@mail.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] Error getting mfn
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="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, Sep 20, 2012 at 6:23 PM, Pasi K=E4rkk=E4inen <pasik@iki.fi> wrote:
> You need to set both.

that's what I did, even know I did put some xen hypervisor options on
dom0, it doesn't change anything.
hypervisor:
console=3Dcom2 debug sync_console dom0_max_vcpus=3D1
dom0_mem=3D1024M,max:1024M loglvl=3Dall guest_loglvl=3Dinfo
dom0:
loglvl=3Dall verbose=3Dy console=3Dhvc0 debug loglevel=3D8
-- =

William

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 20 16:35:50 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Sep 2012 16: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 1TEjiy-0005mQ-8w; Thu, 20 Sep 2012 16:35:36 +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 1TEjiw-0005mF-F6
	for xen-devel@lists.xensource.com; Thu, 20 Sep 2012 16:35:34 +0000
Received: from [85.158.137.99:59840] by server-5.bemta-3.messagelabs.com id
	01/6F-13133-5D54B505; Thu, 20 Sep 2012 16:35:33 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-13.tower-217.messagelabs.com!1348158931!18518888!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA1MDk4NTY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31225 invoked from network); 20 Sep 2012 16:35:32 -0000
Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25)
	by server-13.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 20 Sep 2012 16:35: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 4694A1F64;
	Thu, 20 Sep 2012 19:35:25 +0300 (EEST)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id 306092005D; Thu, 20 Sep 2012 19:35:25 +0300 (EEST)
Date: Thu, 20 Sep 2012 19:35:25 +0300
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: William Dauchy <wdauchy@gmail.com>
Message-ID: <20120920163525.GC8912@reaktio.net>
References: <CAJ75kXZm-BqWdL2O41XkSE1VCdd4ruW=+CqDmR1b3=701RnXmw@mail.gmail.com>
	<20120918133650.GC12053@phenom.dumpdata.com>
	<CAJ75kXZEaCj4Jqs_qm46d7U-s1C2hkAONs8c5Audrw2c3X=nBA@mail.gmail.com>
	<20120920134851.GB1998@localhost.localdomain>
	<CAJ75kXZ0depUJF_h0yok-r4aL0TBGnqTpW_PKT4Q7P1_6R4X2A@mail.gmail.com>
	<20120920162337.GB8912@reaktio.net>
	<CAJ75kXaXbitBvosYp8Sv_548XbvdxU=M_NSSHTb_5d56=-n4nA@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAJ75kXaXbitBvosYp8Sv_548XbvdxU=M_NSSHTb_5d56=-n4nA@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] Error getting mfn
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="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, Sep 20, 2012 at 06:30:33PM +0200, William Dauchy wrote:
> On Thu, Sep 20, 2012 at 6:23 PM, Pasi K=E4rkk=E4inen <pasik@iki.fi> wrote:
> > You need to set both.
> =

> that's what I did, even know I did put some xen hypervisor options on
> dom0, it doesn't change anything.
> hypervisor:
> console=3Dcom2 debug sync_console dom0_max_vcpus=3D1
> dom0_mem=3D1024M,max:1024M loglvl=3Dall guest_loglvl=3Dinfo
                                                   ^^^^
Try putting "all" there instead of "info".

> dom0:
> loglvl=3Dall verbose=3Dy console=3Dhvc0 debug loglevel=3D8

-- Pasi


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 20 16:35:50 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Sep 2012 16: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 1TEjiy-0005mQ-8w; Thu, 20 Sep 2012 16:35:36 +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 1TEjiw-0005mF-F6
	for xen-devel@lists.xensource.com; Thu, 20 Sep 2012 16:35:34 +0000
Received: from [85.158.137.99:59840] by server-5.bemta-3.messagelabs.com id
	01/6F-13133-5D54B505; Thu, 20 Sep 2012 16:35:33 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-13.tower-217.messagelabs.com!1348158931!18518888!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA1MDk4NTY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31225 invoked from network); 20 Sep 2012 16:35:32 -0000
Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25)
	by server-13.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 20 Sep 2012 16:35: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 4694A1F64;
	Thu, 20 Sep 2012 19:35:25 +0300 (EEST)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id 306092005D; Thu, 20 Sep 2012 19:35:25 +0300 (EEST)
Date: Thu, 20 Sep 2012 19:35:25 +0300
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: William Dauchy <wdauchy@gmail.com>
Message-ID: <20120920163525.GC8912@reaktio.net>
References: <CAJ75kXZm-BqWdL2O41XkSE1VCdd4ruW=+CqDmR1b3=701RnXmw@mail.gmail.com>
	<20120918133650.GC12053@phenom.dumpdata.com>
	<CAJ75kXZEaCj4Jqs_qm46d7U-s1C2hkAONs8c5Audrw2c3X=nBA@mail.gmail.com>
	<20120920134851.GB1998@localhost.localdomain>
	<CAJ75kXZ0depUJF_h0yok-r4aL0TBGnqTpW_PKT4Q7P1_6R4X2A@mail.gmail.com>
	<20120920162337.GB8912@reaktio.net>
	<CAJ75kXaXbitBvosYp8Sv_548XbvdxU=M_NSSHTb_5d56=-n4nA@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAJ75kXaXbitBvosYp8Sv_548XbvdxU=M_NSSHTb_5d56=-n4nA@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] Error getting mfn
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="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, Sep 20, 2012 at 06:30:33PM +0200, William Dauchy wrote:
> On Thu, Sep 20, 2012 at 6:23 PM, Pasi K=E4rkk=E4inen <pasik@iki.fi> wrote:
> > You need to set both.
> =

> that's what I did, even know I did put some xen hypervisor options on
> dom0, it doesn't change anything.
> hypervisor:
> console=3Dcom2 debug sync_console dom0_max_vcpus=3D1
> dom0_mem=3D1024M,max:1024M loglvl=3Dall guest_loglvl=3Dinfo
                                                   ^^^^
Try putting "all" there instead of "info".

> dom0:
> loglvl=3Dall verbose=3Dy console=3Dhvc0 debug loglevel=3D8

-- Pasi


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 20 17:09:44 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Sep 2012 17: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 1TEkFe-0006eY-Ng; Thu, 20 Sep 2012 17:09:22 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wdauchy@gmail.com>) id 1TEkFd-0006eQ-1R
	for xen-devel@lists.xensource.com; Thu, 20 Sep 2012 17:09:21 +0000
Received: from [85.158.138.51:19250] by server-5.bemta-3.messagelabs.com id
	D1/1C-13133-0CD4B505; Thu, 20 Sep 2012 17:09:20 +0000
X-Env-Sender: wdauchy@gmail.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1348160953!30864025!1
X-Originating-IP: [209.85.160.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-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32086 invoked from network); 20 Sep 2012 17:09:14 -0000
Received: from mail-pb0-f43.google.com (HELO mail-pb0-f43.google.com)
	(209.85.160.43)
	by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Sep 2012 17:09:14 -0000
Received: by pbbrq2 with SMTP id rq2so7165200pbb.30
	for <xen-devel@lists.xensource.com>;
	Thu, 20 Sep 2012 10:09: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:from:date:message-id:subject:to
	:cc:content-type:content-transfer-encoding;
	bh=FSvETMzL9+biaaQfRgQwrykmqDUD0FkMOmWULU2nS+A=;
	b=fK5CGhQw+p8TD848QYQlQspUK4AHut2uADasuNdn7yj7G4qL/OJDsKI5/ubOHeYKKe
	pjPW0qaZGkK4CFRtlFBIGzeO/efNQ/GWfmsWAYR+KwwNfyaX/Nd4h6UMgpUZOndfIUym
	gpglRnjInDVUM428wO6ggGw+C0pfkJF0MvstWUIMduyQDI5NrL3dJwSFpNbj3aBnTYrJ
	4Sv2AE0Vy+u5cG+WWvdCxfQSv93J3CRwTmAeQzPa2x/OThzPnuH+iJkkSW3BECMpMHc9
	zvFg5539gUvrcZ+3m110xjBupIUfErTjhJi+n4FgPnEtbCJEKPvORk4VRxw83DZSfW4k
	VMmg==
Received: by 10.68.221.70 with SMTP id qc6mr8601684pbc.92.1348160952568; Thu,
	20 Sep 2012 10:09:12 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.68.135.42 with HTTP; Thu, 20 Sep 2012 10:08:51 -0700 (PDT)
In-Reply-To: <20120920163525.GC8912@reaktio.net>
References: <CAJ75kXZm-BqWdL2O41XkSE1VCdd4ruW=+CqDmR1b3=701RnXmw@mail.gmail.com>
	<20120918133650.GC12053@phenom.dumpdata.com>
	<CAJ75kXZEaCj4Jqs_qm46d7U-s1C2hkAONs8c5Audrw2c3X=nBA@mail.gmail.com>
	<20120920134851.GB1998@localhost.localdomain>
	<CAJ75kXZ0depUJF_h0yok-r4aL0TBGnqTpW_PKT4Q7P1_6R4X2A@mail.gmail.com>
	<20120920162337.GB8912@reaktio.net>
	<CAJ75kXaXbitBvosYp8Sv_548XbvdxU=M_NSSHTb_5d56=-n4nA@mail.gmail.com>
	<20120920163525.GC8912@reaktio.net>
From: William Dauchy <wdauchy@gmail.com>
Date: Thu, 20 Sep 2012 19:08:51 +0200
Message-ID: <CAJ75kXZnb82GnssNWxyGMHjTYiRQCRsNdPeYdEb-tsvkshpfEg@mail.gmail.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] Error getting mfn
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi Konrad,

I finally got what you asked, xen output with dom0 included. sorry for
the previous noise, there was some issues with my console redirection.

(XEN) Xen version 4.1.3 (package@) (gcc version 4.4.5 (Debian 4.4.5-8)
) Mon Sep 17 15:01:52 UTC 2012
(XEN) Latest ChangeSet: Thu Aug 09 16:47:30 2012 +0100 23334:ce7195d2b80e
(XEN) Console output is synchronous.
(XEN) Bootloader: COM32 Multiboot loader v0.2
(XEN) Command line: console=com2 debug sync_console dom0_max_vcpus=1
dom0_mem=1024M,max:1024M loglvl=all guest_loglvl=all
(XEN) Video information:
(XEN)  VGA is text mode 80x25, font 8x16
(XEN)  VBE/DDC methods: none; EDID transfer time: 1 seconds
(XEN)  EDID info not retrieved because no DDC retrieval method detected
(XEN) Disc information:
(XEN)  Found 0 MBR signatures
(XEN)  Found 0 EDD information structures
(XEN) Xen-e820 RAM map:
(XEN)  0000000000000000 - 000000000009b400 (usable)
(XEN)  000000000009b400 - 00000000000a0000 (reserved)
(XEN)  00000000000e0000 - 0000000000100000 (reserved)
(XEN)  0000000000100000 - 00000000bf730000 (usable)
(XEN)  00000000bf730000 - 00000000bf73e000 (ACPI data)
(XEN)  00000000bf73e000 - 00000000bf7a0000 (ACPI NVS)
(XEN)  00000000bf7a0000 - 00000000bf7b0000 (reserved)
(XEN)  00000000bf7bc000 - 00000000c0000000 (reserved)
(XEN)  00000000e0000000 - 00000000f0000000 (reserved)
(XEN)  00000000fee00000 - 00000000fee01000 (reserved)
(XEN)  00000000ffa00000 - 0000000100000000 (reserved)
(XEN)  0000000100000000 - 0000000c40000000 (usable)
(XEN) ACPI: RSDP 000FA6F0, 0024 (r2 ACPIAM)
(XEN) ACPI: XSDT BF730100, 006C (r1 122311 XSDT1136 20111223 MSFT       97)
(XEN) ACPI: FACP BF730290, 00F4 (r4 122311 FACP1136 20111223 MSFT       97)
(XEN) ACPI: DSDT BF730540, 48F7 (r2  5442B 5442B166      166 INTL 20051117)
(XEN) ACPI: FACS BF73E000, 0040
(XEN) ACPI: APIC BF730390, 011E (r2 122311 APIC1136 20111223 MSFT       97)
(XEN) ACPI: SPCR BF7304B0, 0050 (r1 122311 SPCR1136 20111223 MSFT       97)
(XEN) ACPI: MCFG BF730500, 003C (r1 122311 OEMMCFG  20111223 MSFT       97)
(XEN) ACPI: OEMB BF73E040, 0082 (r1 122311 OEMB1136 20111223 MSFT       97)
(XEN) ACPI: SRAT BF73A540, 0250 (r2 122311 OEMSRAT         1 INTL        1)
(XEN) ACPI: HPET BF73A790, 0038 (r1 122311 OEMHPET  20111223 MSFT       97)
(XEN) ACPI: DMAR BF73E0D0, 00D8 (r1    AMI  OEMDMAR        1 MSFT       97)
(XEN) ACPI: SSDT BF7439A0, 0363 (r1 DpgPmm    CpuPm       12 INTL 20051117)
(XEN) System RAM: 49142MB (50322220kB)
(XEN) SRAT: PXM 0 -> APIC 0 -> Node 0
(XEN) SRAT: PXM 0 -> APIC 2 -> Node 0
(XEN) SRAT: PXM 0 -> APIC 4 -> Node 0
(XEN) SRAT: PXM 0 -> APIC 16 -> Node 0
(XEN) SRAT: PXM 0 -> APIC 18 -> Node 0
(XEN) SRAT: PXM 0 -> APIC 20 -> Node 0
(XEN) SRAT: PXM 0 -> APIC 1 -> Node 0
(XEN) SRAT: PXM 0 -> APIC 3 -> Node 0
(XEN) SRAT: PXM 0 -> APIC 5 -> Node 0
(XEN) SRAT: PXM 0 -> APIC 17 -> Node 0
(XEN) SRAT: PXM 0 -> APIC 19 -> Node 0
(XEN) SRAT: PXM 0 -> APIC 21 -> Node 0
(XEN) SRAT: PXM 1 -> APIC 32 -> Node 1
(XEN) SRAT: PXM 1 -> APIC 34 -> Node 1
(XEN) SRAT: PXM 1 -> APIC 36 -> Node 1
(XEN) SRAT: PXM 1 -> APIC 48 -> Node 1
(XEN) SRAT: PXM 1 -> APIC 50 -> Node 1
(XEN) SRAT: PXM 1 -> APIC 52 -> Node 1
(XEN) SRAT: PXM 1 -> APIC 33 -> Node 1
(XEN) SRAT: PXM 1 -> APIC 35 -> Node 1
(XEN) SRAT: PXM 1 -> APIC 37 -> Node 1
(XEN) SRAT: PXM 1 -> APIC 49 -> Node 1
(XEN) SRAT: PXM 1 -> APIC 51 -> Node 1
(XEN) SRAT: PXM 1 -> APIC 53 -> Node 1
(XEN) SRAT: Node 0 PXM 0 0-a0000
(XEN) SRAT: Node 0 PXM 0 100000-c0000000
(XEN) SRAT: Node 0 PXM 0 100000000-640000000
(XEN) SRAT: Node 1 PXM 1 640000000-c40000000
(XEN) NUMA: Allocated memnodemap from c3f7b8000 - c3f7c5000
(XEN) NUMA: Using 8 for the hash shift.
(XEN) Domain heap initialised DMA width 32 bits
(XEN) found SMP MP-table at 000ff780
(XEN) DMI present.
(XEN) Using APIC driver default
(XEN) ACPI: PM-Timer IO Port: 0x808
(XEN) ACPI: ACPI SLEEP INFO: pm1x_cnt[804,0], pm1x_evt[800,0]
(XEN) ACPI:                  wakeup_vec[bf73e00c], vec_size[20]
(XEN) ACPI: Local APIC address 0xfee00000
(XEN) ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled)
(XEN) Processor #0 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x02] lapic_id[0x02] enabled)
(XEN) Processor #2 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x03] lapic_id[0x04] enabled)
(XEN) Processor #4 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x04] lapic_id[0x10] enabled)
(XEN) Processor #16 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x05] lapic_id[0x12] enabled)
(XEN) Processor #18 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x06] lapic_id[0x14] enabled)
(XEN) Processor #20 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x07] lapic_id[0x20] enabled)
(XEN) Processor #32 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x08] lapic_id[0x22] enabled)
(XEN) Processor #34 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x09] lapic_id[0x24] enabled)
(XEN) Processor #36 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x0a] lapic_id[0x30] enabled)
(XEN) Processor #48 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x0b] lapic_id[0x32] enabled)
(XEN) Processor #50 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x0c] lapic_id[0x34] enabled)
(XEN) Processor #52 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x0d] lapic_id[0x01] enabled)
(XEN) Processor #1 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x0e] lapic_id[0x03] enabled)
(XEN) Processor #3 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x0f] lapic_id[0x05] enabled)
(XEN) Processor #5 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x10] lapic_id[0x11] enabled)
(XEN) Processor #17 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x11] lapic_id[0x13] enabled)
(XEN) Processor #19 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x12] lapic_id[0x15] enabled)
(XEN) Processor #21 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x13] lapic_id[0x21] enabled)
(XEN) Processor #33 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x14] lapic_id[0x23] enabled)
(XEN) Processor #35 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x15] lapic_id[0x25] enabled)
(XEN) Processor #37 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x16] lapic_id[0x31] enabled)
(XEN) Processor #49 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x17] lapic_id[0x33] enabled)
(XEN) Processor #51 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x18] lapic_id[0x35] enabled)
(XEN) Processor #53 6:12 APIC version 21
(XEN) ACPI: LAPIC_NMI (acpi_id[0xff] dfl dfl lint[0x1])
(XEN) Overriding APIC driver with bigsmp
(XEN) ACPI: IOAPIC (id[0x06] address[0xfec00000] gsi_base[0])
(XEN) IOAPIC[0]: apic_id 6, version 32, address 0xfec00000, GSI 0-23
(XEN) ACPI: IOAPIC (id[0x07] address[0xfec8a000] gsi_base[24])
(XEN) IOAPIC[1]: apic_id 7, version 32, address 0xfec8a000, GSI 24-47
(XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
(XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
(XEN) ACPI: IRQ0 used by override.
(XEN) ACPI: IRQ2 used by override.
(XEN) ACPI: IRQ9 used by override.
(XEN) Enabling APIC mode:  Phys.  Using 2 I/O APICs
(XEN) ACPI: HPET id: 0x8086a301 base: 0xfed00000
(XEN) PCI: MCFG configuration 0: base e0000000 segment 0 buses 0 - 255
(XEN) PCI: MCFG area at e0000000 reserved in E820
(XEN) Table is not found!
(XEN) Using ACPI (MADT) for SMP configuration information
(XEN) IRQ limits: 48 GSI, 4576 MSI/MSI-X
(XEN) Using scheduler: SMP Credit Scheduler (credit)
(XEN) Detected 2266.825 MHz processor.
(XEN) Initing memory sharing.
(XEN) mce_intel.c:1162: MCA Capability: BCAST 1 SER 0 CMCI 1 firstbank
0 extended MCE MSR 0
(XEN) Intel machine check reporting enabled
(XEN) Intel VT-d supported page sizes: 4kB.
(XEN) Intel VT-d Snoop Control enabled.
(XEN) Intel VT-d Dom0 DMA Passthrough not enabled.
(XEN) Intel VT-d Queued Invalidation enabled.
(XEN) Intel VT-d Interrupt Remapping not enabled.
(XEN) Intel VT-d Shared EPT tables not enabled.
(XEN) I/O virtualisation enabled
(XEN)  - Dom0 mode: Relaxed
(XEN) Enabled directed EOI with ioapic_ack_old on!
(XEN) ENABLING IO-APIC IRQs
(XEN)  -> Using old ACK method
(XEN) ..TIMER: vector=0xF0 apic1=0 pin1=2 apic2=-1 pin2=-1
(XEN) Platform timer is 14.318MHz HPET
(XEN) Defaulting to alternative key handling; send 'A' to switch to normal mode.
(XEN) Allocated console ring of 256 KiB.
(XEN) VMX: Supported advanced features:
(XEN)  - APIC MMIO access virtualisation
(XEN)  - APIC TPR shadow
(XEN)  - Extended Page Tables (EPT)
(XEN)  - Virtual-Processor Identifiers (VPID)
(XEN)  - Virtual NMI
(XEN)  - MSR direct-access bitmap
(XEN)  - Unrestricted Guest
(XEN) HVM: ASIDs enabled.
(XEN) HVM: VMX enabled
(XEN) HVM: Hardware Assisted Paging (HAP) detected
(XEN) HVM: HAP page sizes: 4kB, 2MB, 1GB
(XEN) Brought up 24 CPUs
(XEN) ACPI sleep modes: S3
(XEN) mcheck_poll: Machine check polling timer started.
(XEN) *** LOADING DOMAIN 0 ***
(XEN)  Xen  kernel: 64-bit, lsb, compat32
(XEN)  Dom0 kernel: 32-bit, PAE, lsb, paddr 0x1000000 -> 0x17dc000
(XEN) PHYSICAL MEMORY ARRANGEMENT:
(XEN)  Dom0 alloc.:   0000000c20000000->0000000c22000000 (253212 pages
to be allocated)
(XEN)  Init. ramdisk: 0000000c3fd1c000->0000000c3ffff200
(XEN) VIRTUAL MEMORY ARRANGEMENT:
(XEN)  Loaded kernel: 00000000c1000000->00000000c17dc000
(XEN)  Init. ramdisk: 00000000c17dc000->00000000c1abf200
(XEN)  Phys-Mach map: 00000000c1ac0000->00000000c1bc0000
(XEN)  Start info:    00000000c1bc0000->00000000c1bc04b4
(XEN)  Page tables:   00000000c1bc1000->00000000c1bd7000
(XEN)  Boot stack:    00000000c1bd7000->00000000c1bd8000
(XEN)  TOTAL:         00000000c0000000->00000000c2000000
(XEN)  ENTRY ADDRESS: 00000000c14f5000
(XEN) Dom0 has maximum 1 VCPUs
(XEN) Scrubbing Free RAM:
..........................................................................................................................................................................................................................................................................................................................................................................................................................................................................................done.
(XEN) Xen trace buffers: disabled
(XEN) Std. Loglevel: All
(XEN) Guest Loglevel: All
(XEN) **********************************************
(XEN) ******* WARNING: CONSOLE OUTPUT IS SYNCHRONOUS
(XEN) ******* This option is intended to aid debugging of Xen by ensuring
(XEN) ******* that all output is synchronously delivered on the serial line.
(XEN) ******* However it can introduce SIGNIFICANT latencies and affect
(XEN) ******* timekeeping. It is NOT recommended for production use!
(XEN) **********************************************
(XEN) 3... 2... 1...
(XEN) *** Serial input -> DOM0 (type 'CTRL-a' three times to switch
input to Xen)
(XEN) Freed 212kB init memory.
mapping kernel into physical memory
Xen: setup ISA identity maps
about to get started...
(XEN) mm.c:908:d0 Error getting mfn 2009b (pfn 5555555555555555) from
L1 entry 000000002009b023 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 000000002009b023
(XEN) mm.c:908:d0 Error getting mfn 2009c (pfn 5555555555555555) from
L1 entry 000000002009c023 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 000000002009c023
(XEN) mm.c:908:d0 Error getting mfn 2009d (pfn 5555555555555555) from
L1 entry 000000002009d023 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 000000002009d023
(XEN) mm.c:908:d0 Error getting mfn 2009e (pfn 5555555555555555) from
L1 entry 000000002009e023 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 000000002009e023
(XEN) mm.c:908:d0 Error getting mfn 2009f (pfn 5555555555555555) from
L1 entry 000000002009f023 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 000000002009f023
(XEN) mm.c:908:d0 Error getting mfn c32000 (pfn 5555555555555555) from
L1 entry 8000000c32000063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c32000063
(XEN) mm.c:908:d0 Error getting mfn c32001 (pfn 5555555555555555) from
L1 entry 8000000c32001063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c32001063
(XEN) mm.c:908:d0 Error getting mfn c32002 (pfn 5555555555555555) from
L1 entry 8000000c32002063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c32002063
(XEN) mm.c:908:d0 Error getting mfn c32003 (pfn 5555555555555555) from
L1 entry 8000000c32003063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c32003063
(XEN) mm.c:908:d0 Error getting mfn c32004 (pfn 5555555555555555) from
L1 entry 8000000c32004063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c32004063
(XEN) mm.c:908:d0 Error getting mfn c32005 (pfn 5555555555555555) from
L1 entry 8000000c32005063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c32005063
(XEN) mm.c:908:d0 Error getting mfn c32006 (pfn 5555555555555555) from
L1 entry 8000000c32006063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c32006063
(XEN) mm.c:908:d0 Error getting mfn c32007 (pfn 5555555555555555) from
L1 entry 8000000c32007063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c32007063
(XEN) mm.c:908:d0 Error getting mfn c32008 (pfn 5555555555555555) from
L1 entry 8000000c32008063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c32008063
(XEN) mm.c:908:d0 Error getting mfn c32009 (pfn 5555555555555555) from
L1 entry 8000000c32009063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c32009063
(XEN) mm.c:908:d0 Error getting mfn c3200a (pfn 5555555555555555) from
L1 entry 8000000c3200a063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c3200a063
(XEN) mm.c:908:d0 Error getting mfn c3200b (pfn 5555555555555555) from
L1 entry 8000000c3200b063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c3200b063
(XEN) mm.c:908:d0 Error getting mfn c3200c (pfn 5555555555555555) from
L1 entry 8000000c3200c063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c3200c063
(XEN) mm.c:908:d0 Error getting mfn c3200d (pfn 5555555555555555) from
L1 entry 8000000c3200d063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c3200d063
(XEN) mm.c:908:d0 Error getting mfn c3200e (pfn 5555555555555555) from
L1 entry 8000000c3200e063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c3200e063
(XEN) mm.c:908:d0 Error getting mfn c3200f (pfn 5555555555555555) from
L1 entry 8000000c3200f063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c3200f063
(XEN) mm.c:908:d0 Error getting mfn c32010 (pfn 5555555555555555) from
L1 entry 8000000c32010063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c32010063
(XEN) mm.c:908:d0 Error getting mfn c32011 (pfn 5555555555555555) from
L1 entry 8000000c32011063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c32011063
(XEN) mm.c:908:d0 Error getting mfn c32012 (pfn 5555555555555555) from
L1 entry 8000000c32012063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c32012063
(XEN) mm.c:908:d0 Error getting mfn c32013 (pfn 5555555555555555) from
L1 entry 8000000c32013063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c32013063
(XEN) mm.c:908:d0 Error getting mfn c32014 (pfn 5555555555555555) from
L1 entry 8000000c32014063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c32014063
(XEN) mm.c:908:d0 Error getting mfn c32015 (pfn 5555555555555555) from
L1 entry 8000000c32015063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c32015063
(XEN) mm.c:908:d0 Error getting mfn c32016 (pfn 5555555555555555) from
L1 entry 8000000c32016063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c32016063
(XEN) mm.c:908:d0 Error getting mfn c32017 (pfn 5555555555555555) from
L1 entry 8000000c32017063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c32017063
(XEN) mm.c:908:d0 Error getting mfn c32018 (pfn 5555555555555555) from
L1 entry 8000000c32018063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c32018063
(XEN) mm.c:908:d0 Error getting mfn c32019 (pfn 5555555555555555) from
L1 entry 8000000c32019063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c32019063
(XEN) mm.c:908:d0 Error getting mfn c3201a (pfn 5555555555555555) from
L1 entry 8000000c3201a063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c3201a063
(XEN) mm.c:908:d0 Error getting mfn c3201b (pfn 5555555555555555) from
L1 entry 8000000c3201b063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c3201b063
(XEN) mm.c:908:d0 Error getting mfn c3201c (pfn 5555555555555555) from
L1 entry 8000000c3201c063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c3201c063
(XEN) mm.c:908:d0 Error getting mfn c3201d (pfn 5555555555555555) from
L1 entry 8000000c3201d063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c3201d063
(XEN) mm.c:908:d0 Error getting mfn c3201e (pfn 5555555555555555) from
L1 entry 8000000c3201e063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c3201e063
(XEN) mm.c:908:d0 Error getting mfn c3201f (pfn 5555555555555555) from
L1 entry 8000000c3201f063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c3201f063
(XEN) mm.c:908:d0 Error getting mfn c32020 (pfn 5555555555555555) from
L1 entry 8000000c32020063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c32020063
(XEN) mm.c:908:d0 Error getting mfn c32021 (pfn 5555555555555555) from
L1 entry 8000000c32021063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c32021063
(XEN) mm.c:908:d0 Error getting mfn c32022 (pfn 5555555555555555) from
L1 entry 8000000c32022063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c32022063
(XEN) mm.c:908:d0 Error getting mfn c32023 (pfn 5555555555555555) from
L1 entry 8000000c32023063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c32023063
(XEN) mm.c:908:d0 Error getting mfn c32024 (pfn 5555555555555555) from
L1 entry 8000000c32024063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c32024063
(XEN) mm.c:908:d0 Error getting mfn c32025 (pfn 5555555555555555) from
L1 entry 8000000c32025063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c32025063
(XEN) mm.c:908:d0 Error getting mfn c32026 (pfn 5555555555555555) from
L1 entry 8000000c32026063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c32026063
(XEN) mm.c:908:d0 Error getting mfn c32027 (pfn 5555555555555555) from
L1 entry 8000000c32027063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c32027063
(XEN) mm.c:908:d0 Error getting mfn c32028 (pfn 5555555555555555) from
L1 entry 8000000c32028063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c32028063
(XEN) mm.c:908:d0 Error getting mfn c32029 (pfn 5555555555555555) from
L1 entry 8000000c32029063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c32029063
(XEN) mm.c:908:d0 Error getting mfn c3202a (pfn 5555555555555555) from
L1 entry 8000000c3202a063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c3202a063
(XEN) mm.c:908:d0 Error getting mfn c3202b (pfn 5555555555555555) from
L1 entry 8000000c3202b063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c3202b063
(XEN) mm.c:908:d0 Error getting mfn c3202c (pfn 5555555555555555) from
L1 entry 8000000c3202c063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c3202c063
(XEN) mm.c:908:d0 Error getting mfn c3202d (pfn 5555555555555555) from
L1 entry 8000000c3202d063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c3202d063
(XEN) mm.c:908:d0 Error getting mfn c3202e (pfn 5555555555555555) from
L1 entry 8000000c3202e063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c3202e063
(XEN) mm.c:908:d0 Error getting mfn c3202f (pfn 5555555555555555) from
L1 entry 8000000c3202f063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c3202f063
(XEN) mm.c:908:d0 Error getting mfn c32030 (pfn 5555555555555555) from
L1 entry 8000000c32030063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c32030063
(XEN) mm.c:908:d0 Error getting mfn c32031 (pfn 5555555555555555) from
L1 entry 8000000c32031063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c32031063
(XEN) mm.c:908:d0 Error getting mfn c32032 (pfn 5555555555555555) from
L1 entry 8000000c32032063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c32032063
(XEN) mm.c:908:d0 Error getting mfn c32033 (pfn 5555555555555555) from
L1 entry 8000000c32033063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c32033063
(XEN) mm.c:908:d0 Error getting mfn c32034 (pfn 5555555555555555) from
L1 entry 8000000c32034063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c32034063
(XEN) mm.c:908:d0 Error getting mfn c32035 (pfn 5555555555555555) from
L1 entry 8000000c32035063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c32035063
(XEN) mm.c:908:d0 Error getting mfn c32036 (pfn 5555555555555555) from
L1 entry 8000000c32036063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c32036063
(XEN) mm.c:908:d0 Error getting mfn c32037 (pfn 5555555555555555) from
L1 entry 8000000c32037063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c32037063
(XEN) mm.c:908:d0 Error getting mfn c32038 (pfn 5555555555555555) from
L1 entry 8000000c32038063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c32038063
(XEN) mm.c:908:d0 Error getting mfn c32039 (pfn 5555555555555555) from
L1 entry 8000000c32039063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c32039063
(XEN) mm.c:908:d0 Error getting mfn c3203a (pfn 5555555555555555) from
L1 entry 8000000c3203a063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c3203a063
(XEN) mm.c:908:d0 Error getting mfn c3203b (pfn 5555555555555555) from
L1 entry 8000000c3203b063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c3203b063
(XEN) mm.c:908:d0 Error getting mfn c3203c (pfn 5555555555555555) from
L1 entry 8000000c3203c063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c3203c063
(XEN) mm.c:908:d0 Error getting mfn c3203d (pfn 5555555555555555) from
L1 entry 8000000c3203d063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c3203d063
(XEN) mm.c:908:d0 Error getting mfn c3203e (pfn 5555555555555555) from
L1 entry 8000000c3203e063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c3203e063
(XEN) mm.c:908:d0 Error getting mfn c3203f (pfn 5555555555555555) from
L1 entry 8000000c3203f063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c3203f063
(XEN) mm.c:908:d0 Error getting mfn c32040 (pfn 5555555555555555) from
L1 entry 8000000c32040063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c32040063
(XEN) mm.c:908:d0 Error getting mfn c32041 (pfn 5555555555555555) from
L1 entry 8000000c32041063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c32041063
(XEN) mm.c:908:d0 Error getting mfn c32042 (pfn 5555555555555555) from
L1 entry 8000000c32042063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c32042063
(XEN) mm.c:908:d0 Error getting mfn c32043 (pfn 5555555555555555) from
L1 entry 8000000c32043063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c32043063
(XEN) mm.c:908:d0 Error getting mfn c32044 (pfn 5555555555555555) from
L1 entry 8000000c32044063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c32044063
(XEN) mm.c:908:d0 Error getting mfn c32045 (pfn 5555555555555555) from
L1 entry 8000000c32045063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c32045063
(XEN) mm.c:908:d0 Error getting mfn c32046 (pfn 5555555555555555) from
L1 entry 8000000c32046063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c32046063
(XEN) mm.c:908:d0 Error getting mfn c32047 (pfn 5555555555555555) from
L1 entry 8000000c32047063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c32047063
(XEN) mm.c:908:d0 Error getting mfn c32048 (pfn 5555555555555555) from
L1 entry 8000000c32048063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c32048063
(XEN) mm.c:908:d0 Error getting mfn c32049 (pfn 5555555555555555) from
L1 entry 8000000c32049063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c32049063
(XEN) mm.c:908:d0 Error getting mfn c3204a (pfn 5555555555555555) from
L1 entry 8000000c3204a063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c3204a063
(XEN) mm.c:908:d0 Error getting mfn c3204b (pfn 5555555555555555) from
L1 entry 8000000c3204b063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c3204b063
(XEN) mm.c:908:d0 Error getting mfn c3204c (pfn 5555555555555555) from
L1 entry 8000000c3204c063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c3204c063
(XEN) mm.c:908:d0 Error getting mfn c3204d (pfn 5555555555555555) from
L1 entry 8000000c3204d063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c3204d063
(XEN) mm.c:908:d0 Error getting mfn c3204e (pfn 5555555555555555) from
L1 entry 8000000c3204e063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c3204e063
(XEN) mm.c:908:d0 Error getting mfn c3204f (pfn 5555555555555555) from
L1 entry 8000000c3204f063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c3204f063
(XEN) mm.c:908:d0 Error getting mfn c32050 (pfn 5555555555555555) from
L1 entry 8000000c32050063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c32050063
(XEN) mm.c:908:d0 Error getting mfn c32051 (pfn 5555555555555555) from
L1 entry 8000000c32051063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c32051063
(XEN) mm.c:908:d0 Error getting mfn c32052 (pfn 5555555555555555) from
L1 entry 8000000c32052063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c32052063
(XEN) mm.c:908:d0 Error getting mfn c32053 (pfn 5555555555555555) from
L1 entry 8000000c32053063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c32053063
(XEN) mm.c:908:d0 Error getting mfn c32054 (pfn 5555555555555555) from
L1 entry 8000000c32054063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c32054063
(XEN) mm.c:908:d0 Error getting mfn c32055 (pfn 5555555555555555) from
L1 entry 8000000c32055063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c32055063
(XEN) mm.c:908:d0 Error getting mfn c32056 (pfn 5555555555555555) from
L1 entry 8000000c32056063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c32056063
(XEN) mm.c:908:d0 Error getting mfn c32057 (pfn 5555555555555555) from
L1 entry 8000000c32057063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c32057063
(XEN) mm.c:908:d0 Error getting mfn c32058 (pfn 5555555555555555) from
L1 entry 8000000c32058063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c32058063
(XEN) mm.c:908:d0 Error getting mfn c32059 (pfn 5555555555555555) from
L1 entry 8000000c32059063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c32059063
(XEN) mm.c:908:d0 Error getting mfn c3205a (pfn 5555555555555555) from
L1 entry 8000000c3205a063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c3205a063
(XEN) mm.c:908:d0 Error getting mfn c3205b (pfn 5555555555555555) from
L1 entry 8000000c3205b063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c3205b063
(XEN) mm.c:908:d0 Error getting mfn c3205c (pfn 5555555555555555) from
L1 entry 8000000c3205c063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c3205c063
(XEN) mm.c:908:d0 Error getting mfn c3205d (pfn 5555555555555555) from
L1 entry 8000000c3205d063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c3205d063
(XEN) mm.c:908:d0 Error getting mfn c3205e (pfn 5555555555555555) from
L1 entry 8000000c3205e063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c3205e063
(XEN) mm.c:908:d0 Error getting mfn c3205f (pfn 5555555555555555) from
L1 entry 8000000c3205f063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c3205f063
(XEN) mm.c:908:d0 Error getting mfn c32060 (pfn 5555555555555555) from
L1 entry 8000000c32060063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c32060063
(XEN) mm.c:908:d0 Error getting mfn c32061 (pfn 5555555555555555) from
L1 entry 8000000c32061063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c32061063
(XEN) mm.c:908:d0 Error getting mfn c32062 (pfn 5555555555555555) from
L1 entry 8000000c32062063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c32062063
(XEN) mm.c:908:d0 Error getting mfn c32063 (pfn 5555555555555555) from
L1 entry 8000000c32063063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c32063063
(XEN) mm.c:908:d0 Error getting mfn c32064 (pfn 5555555555555555) from
L1 entry 8000000c32064063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c32064063
(XEN) mm.c:908:d0 Error getting mfn c32065 (pfn 5555555555555555) from
L1 entry 8000000c32065063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c32065063
(XEN) mm.c:908:d0 Error getting mfn c32066 (pfn 5555555555555555) from
L1 entry 8000000c32066063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c32066063
(XEN) mm.c:908:d0 Error getting mfn c32067 (pfn 5555555555555555) from
L1 entry 8000000c32067063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c32067063
(XEN) mm.c:908:d0 Error getting mfn c32068 (pfn 5555555555555555) from
L1 entry 8000000c32068063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c32068063
(XEN) mm.c:908:d0 Error getting mfn c32069 (pfn 5555555555555555) from
L1 entry 8000000c32069063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c32069063
(XEN) mm.c:908:d0 Error getting mfn c3206a (pfn 5555555555555555) from
L1 entry 8000000c3206a063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c3206a063
(XEN) mm.c:908:d0 Error getting mfn c3206b (pfn 5555555555555555) from
L1 entry 8000000c3206b063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c3206b063
(XEN) mm.c:908:d0 Error getting mfn c3206c (pfn 5555555555555555) from
L1 entry 8000000c3206c063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c3206c063
(XEN) mm.c:908:d0 Error getting mfn c3206d (pfn 5555555555555555) from
L1 entry 8000000c3206d063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c3206d063
(XEN) mm.c:908:d0 Error getting mfn c3206e (pfn 5555555555555555) from
L1 entry 8000000c3206e063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c3206e063
(XEN) mm.c:908:d0 Error getting mfn c3206f (pfn 5555555555555555) from
L1 entry 8000000c3206f063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c3206f063
(XEN) mm.c:908:d0 Error getting mfn c32070 (pfn 5555555555555555) from
L1 entry 8000000c32070063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c32070063
(XEN) mm.c:908:d0 Error getting mfn c32071 (pfn 5555555555555555) from
L1 entry 8000000c32071063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c32071063
(XEN) mm.c:908:d0 Error getting mfn c32072 (pfn 5555555555555555) from
L1 entry 8000000c32072063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c32072063
(XEN) mm.c:908:d0 Error getting mfn c32073 (pfn 5555555555555555) from
L1 entry 8000000c32073063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c32073063
(XEN) mm.c:908:d0 Error getting mfn c32074 (pfn 5555555555555555) from
L1 entry 8000000c32074063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c32074063
(XEN) mm.c:908:d0 Error getting mfn c32075 (pfn 5555555555555555) from
L1 entry 8000000c32075063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c32075063
(XEN) mm.c:908:d0 Error getting mfn c32076 (pfn 5555555555555555) from
L1 entry 8000000c32076063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c32076063
(XEN) mm.c:908:d0 Error getting mfn c32077 (pfn 5555555555555555) from
L1 entry 8000000c32077063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c32077063
(XEN) mm.c:908:d0 Error getting mfn c32078 (pfn 5555555555555555) from
L1 entry 8000000c32078063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c32078063
(XEN) mm.c:908:d0 Error getting mfn c32079 (pfn 5555555555555555) from
L1 entry 8000000c32079063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c32079063
(XEN) mm.c:908:d0 Error getting mfn c3207a (pfn 5555555555555555) from
L1 entry 8000000c3207a063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c3207a063
(XEN) mm.c:908:d0 Error getting mfn c3207b (pfn 5555555555555555) from
L1 entry 8000000c3207b063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c3207b063
(XEN) mm.c:908:d0 Error getting mfn c3207c (pfn 5555555555555555) from
L1 entry 8000000c3207c063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c3207c063
(XEN) mm.c:908:d0 Error getting mfn c3207d (pfn 5555555555555555) from
L1 entry 8000000c3207d063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c3207d063
(XEN) mm.c:908:d0 Error getting mfn c3207e (pfn 5555555555555555) from
L1 entry 8000000c3207e063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c3207e063
(XEN) mm.c:908:d0 Error getting mfn c3207f (pfn 5555555555555555) from
L1 entry 8000000c3207f063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c3207f063
(XEN) mm.c:908:d0 Error getting mfn c32080 (pfn 5555555555555555) from
L1 entry 8000000c32080063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c32080063
(XEN) mm.c:908:d0 Error getting mfn c32081 (pfn 5555555555555555) from
L1 entry 8000000c32081063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c32081063
(XEN) mm.c:908:d0 Error getting mfn c32082 (pfn 5555555555555555) from
L1 entry 8000000c32082063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c32082063
(XEN) mm.c:908:d0 Error getting mfn c32083 (pfn 5555555555555555) from
L1 entry 8000000c32083063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c32083063
(XEN) mm.c:908:d0 Error getting mfn c32084 (pfn 5555555555555555) from
L1 entry 8000000c32084063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c32084063
(XEN) mm.c:908:d0 Error getting mfn c32085 (pfn 5555555555555555) from
L1 entry 8000000c32085063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c32085063
(XEN) mm.c:908:d0 Error getting mfn c32086 (pfn 5555555555555555) from
L1 entry 8000000c32086063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c32086063
(XEN) mm.c:908:d0 Error getting mfn c32087 (pfn 5555555555555555) from
L1 entry 8000000c32087063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c32087063
(XEN) mm.c:908:d0 Error getting mfn c32088 (pfn 5555555555555555) from
L1 entry 8000000c32088063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c32088063
(XEN) mm.c:908:d0 Error getting mfn c32089 (pfn 5555555555555555) from
L1 entry 8000000c32089063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c32089063
(XEN) mm.c:908:d0 Error getting mfn c3208a (pfn 5555555555555555) from
L1 entry 8000000c3208a063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c3208a063
(XEN) mm.c:908:d0 Error getting mfn c3208b (pfn 5555555555555555) from
L1 entry 8000000c3208b063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c3208b063
(XEN) mm.c:908:d0 Error getting mfn c3208c (pfn 5555555555555555) from
L1 entry 8000000c3208c063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c3208c063
(XEN) mm.c:908:d0 Error getting mfn c3208d (pfn 5555555555555555) from
L1 entry 8000000c3208d063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c3208d063
(XEN) mm.c:908:d0 Error getting mfn c3208e (pfn 5555555555555555) from
L1 entry 8000000c3208e063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c3208e063
(XEN) mm.c:908:d0 Error getting mfn c3208f (pfn 5555555555555555) from
L1 entry 8000000c3208f063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c3208f063
(XEN) mm.c:908:d0 Error getting mfn c32090 (pfn 5555555555555555) from
L1 entry 8000000c32090063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c32090063
(XEN) mm.c:908:d0 Error getting mfn c32091 (pfn 5555555555555555) from
L1 entry 8000000c32091063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c32091063
(XEN) mm.c:908:d0 Error getting mfn c32092 (pfn 5555555555555555) from
L1 entry 8000000c32092063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c32092063
(XEN) mm.c:908:d0 Error getting mfn c32093 (pfn 5555555555555555) from
L1 entry 8000000c32093063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c32093063
(XEN) mm.c:908:d0 Error getting mfn c32094 (pfn 5555555555555555) from
L1 entry 8000000c32094063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c32094063
(XEN) mm.c:908:d0 Error getting mfn c32095 (pfn 5555555555555555) from
L1 entry 8000000c32095063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c32095063
(XEN) mm.c:908:d0 Error getting mfn c32096 (pfn 5555555555555555) from
L1 entry 8000000c32096063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c32096063
(XEN) mm.c:908:d0 Error getting mfn c32097 (pfn 5555555555555555) from
L1 entry 8000000c32097063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c32097063
(XEN) mm.c:908:d0 Error getting mfn c32098 (pfn 5555555555555555) from
L1 entry 8000000c32098063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c32098063
(XEN) mm.c:908:d0 Error getting mfn c32099 (pfn 5555555555555555) from
L1 entry 8000000c32099063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c32099063
(XEN) mm.c:908:d0 Error getting mfn c3209a (pfn 5555555555555555) from
L1 entry 8000000c3209a063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c3209a063
(XEN) mm.c:908:d0 Error getting mfn c3209b (pfn 5555555555555555) from
L1 entry 8000000c3209b063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c3209b063
(XEN) mm.c:908:d0 Error getting mfn c3209c (pfn 5555555555555555) from
L1 entry 8000000c3209c063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c3209c063
(XEN) mm.c:908:d0 Error getting mfn c3209d (pfn 5555555555555555) from
L1 entry 8000000c3209d063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c3209d063
(XEN) mm.c:908:d0 Error getting mfn c3209e (pfn 5555555555555555) from
L1 entry 8000000c3209e063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c3209e063
(XEN) mm.c:908:d0 Error getting mfn c3209f (pfn 5555555555555555) from
L1 entry 8000000c3209f063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c3209f063
(XEN) mm.c:908:d0 Error getting mfn c320a0 (pfn 5555555555555555) from
L1 entry 8000000c320a0063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c320a0063
(XEN) mm.c:908:d0 Error getting mfn c320a1 (pfn 5555555555555555) from
L1 entry 8000000c320a1063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c320a1063
(XEN) mm.c:908:d0 Error getting mfn c320a2 (pfn 5555555555555555) from
L1 entry 8000000c320a2063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c320a2063
(XEN) mm.c:908:d0 Error getting mfn c320a3 (pfn 5555555555555555) from
L1 entry 8000000c320a3063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c320a3063
(XEN) mm.c:908:d0 Error getting mfn c320a4 (pfn 5555555555555555) from
L1 entry 8000000c320a4063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c320a4063
(XEN) mm.c:908:d0 Error getting mfn c320a5 (pfn 5555555555555555) from
L1 entry 8000000c320a5063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c320a5063
(XEN) mm.c:908:d0 Error getting mfn c320a6 (pfn 5555555555555555) from
L1 entry 8000000c320a6063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c320a6063
(XEN) mm.c:908:d0 Error getting mfn c320a7 (pfn 5555555555555555) from
L1 entry 8000000c320a7063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c320a7063
(XEN) mm.c:908:d0 Error getting mfn c320a8 (pfn 5555555555555555) from
L1 entry 8000000c320a8063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c320a8063
(XEN) mm.c:908:d0 Error getting mfn c320a9 (pfn 5555555555555555) from
L1 entry 8000000c320a9063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c320a9063
(XEN) mm.c:908:d0 Error getting mfn c320aa (pfn 5555555555555555) from
L1 entry 8000000c320aa063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c320aa063
(XEN) mm.c:908:d0 Error getting mfn c320ab (pfn 5555555555555555) from
L1 entry 8000000c320ab063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c320ab063
(XEN) mm.c:908:d0 Error getting mfn c320ac (pfn 5555555555555555) from
L1 entry 8000000c320ac063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c320ac063
(XEN) mm.c:908:d0 Error getting mfn c320ad (pfn 5555555555555555) from
L1 entry 8000000c320ad063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c320ad063
(XEN) mm.c:908:d0 Error getting mfn c320ae (pfn 5555555555555555) from
L1 entry 8000000c320ae063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c320ae063
(XEN) mm.c:908:d0 Error getting mfn c320af (pfn 5555555555555555) from
L1 entry 8000000c320af063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c320af063
(XEN) mm.c:908:d0 Error getting mfn c320b0 (pfn 5555555555555555) from
L1 entry 8000000c320b0063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c320b0063
(XEN) mm.c:908:d0 Error getting mfn c320b1 (pfn 5555555555555555) from
L1 entry 8000000c320b1063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c320b1063
(XEN) mm.c:908:d0 Error getting mfn c320b2 (pfn 5555555555555555) from
L1 entry 8000000c320b2063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c320b2063
(XEN) mm.c:908:d0 Error getting mfn c320b3 (pfn 5555555555555555) from
L1 entry 8000000c320b3063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c320b3063
(XEN) mm.c:908:d0 Error getting mfn c320b4 (pfn 5555555555555555) from
L1 entry 8000000c320b4063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c320b4063
(XEN) mm.c:908:d0 Error getting mfn c320b5 (pfn 5555555555555555) from
L1 entry 8000000c320b5063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c320b5063
(XEN) mm.c:908:d0 Error getting mfn c320b6 (pfn 5555555555555555) from
L1 entry 8000000c320b6063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c320b6063
(XEN) mm.c:908:d0 Error getting mfn c320b7 (pfn 5555555555555555) from
L1 entry 8000000c320b7063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c320b7063
(XEN) mm.c:908:d0 Error getting mfn c320b8 (pfn 5555555555555555) from
L1 entry 8000000c320b8063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c320b8063
(XEN) mm.c:908:d0 Error getting mfn c320b9 (pfn 5555555555555555) from
L1 entry 8000000c320b9063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c320b9063
(XEN) mm.c:908:d0 Error getting mfn c320ba (pfn 5555555555555555) from
L1 entry 8000000c320ba063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c320ba063
(XEN) mm.c:908:d0 Error getting mfn c320bb (pfn 5555555555555555) from
L1 entry 8000000c320bb063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c320bb063
(XEN) mm.c:908:d0 Error getting mfn c320bc (pfn 5555555555555555) from
L1 entry 8000000c320bc063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c320bc063
(XEN) mm.c:908:d0 Error getting mfn c320bd (pfn 5555555555555555) from
L1 entry 8000000c320bd063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c320bd063
(XEN) mm.c:908:d0 Error getting mfn c320be (pfn 5555555555555555) from
L1 entry 8000000c320be063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c320be063
(XEN) mm.c:908:d0 Error getting mfn c320bf (pfn 5555555555555555) from
L1 entry 8000000c320bf063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c320bf063
(XEN) mm.c:908:d0 Error getting mfn c320c0 (pfn 5555555555555555) from
L1 entry 8000000c320c0063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c320c0063
(XEN) mm.c:908:d0 Error getting mfn c320c1 (pfn 5555555555555555) from
L1 entry 8000000c320c1063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c320c1063
(XEN) mm.c:908:d0 Error getting mfn c320c2 (pfn 5555555555555555) from
L1 entry 8000000c320c2063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c320c2063
(XEN) mm.c:908:d0 Error getting mfn c320c3 (pfn 5555555555555555) from
L1 entry 8000000c320c3063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c320c3063
(XEN) mm.c:908:d0 Error getting mfn c320c4 (pfn 5555555555555555) from
L1 entry 8000000c320c4063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c320c4063
(XEN) mm.c:908:d0 Error getting mfn c320c5 (pfn 5555555555555555) from
L1 entry 8000000c320c5063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c320c5063
(XEN) mm.c:908:d0 Error getting mfn c320c6 (pfn 5555555555555555) from
L1 entry 8000000c320c6063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c320c6063
(XEN) mm.c:908:d0 Error getting mfn c320c7 (pfn 5555555555555555) from
L1 entry 8000000c320c7063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c320c7063
(XEN) mm.c:908:d0 Error getting mfn c320c8 (pfn 5555555555555555) from
L1 entry 8000000c320c8063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c320c8063
(XEN) mm.c:908:d0 Error getting mfn c320c9 (pfn 5555555555555555) from
L1 entry 8000000c320c9063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c320c9063
(XEN) mm.c:908:d0 Error getting mfn c320ca (pfn 5555555555555555) from
L1 entry 8000000c320ca063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c320ca063
(XEN) mm.c:908:d0 Error getting mfn c320cb (pfn 5555555555555555) from
L1 entry 8000000c320cb063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c320cb063
(XEN) mm.c:908:d0 Error getting mfn c320cc (pfn 5555555555555555) from
L1 entry 8000000c320cc063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c320cc063
(XEN) mm.c:908:d0 Error getting mfn c320cd (pfn 5555555555555555) from
L1 entry 8000000c320cd063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c320cd063
(XEN) mm.c:908:d0 Error getting mfn c320ce (pfn 5555555555555555) from
L1 entry 8000000c320ce063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c320ce063
(XEN) mm.c:908:d0 Error getting mfn c320cf (pfn 5555555555555555) from
L1 entry 8000000c320cf063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c320cf063
(XEN) mm.c:908:d0 Error getting mfn c320d0 (pfn 5555555555555555) from
L1 entry 8000000c320d0063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c320d0063
(XEN) mm.c:908:d0 Error getting mfn c320d1 (pfn 5555555555555555) from
L1 entry 8000000c320d1063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c320d1063
(XEN) mm.c:908:d0 Error getting mfn c320d2 (pfn 5555555555555555) from
L1 entry 8000000c320d2063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c320d2063
(XEN) mm.c:908:d0 Error getting mfn c320d3 (pfn 5555555555555555) from
L1 entry 8000000c320d3063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c320d3063
(XEN) mm.c:908:d0 Error getting mfn c320d4 (pfn 5555555555555555) from
L1 entry 8000000c320d4063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c320d4063
(XEN) mm.c:908:d0 Error getting mfn c320d5 (pfn 5555555555555555) from
L1 entry 8000000c320d5063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c320d5063
(XEN) mm.c:908:d0 Error getting mfn c320d6 (pfn 5555555555555555) from
L1 entry 8000000c320d6063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c320d6063
(XEN) mm.c:908:d0 Error getting mfn c320d7 (pfn 5555555555555555) from
L1 entry 8000000c320d7063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c320d7063
(XEN) mm.c:908:d0 Error getting mfn c320d8 (pfn 5555555555555555) from
L1 entry 8000000c320d8063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c320d8063
(XEN) mm.c:908:d0 Error getting mfn c320d9 (pfn 5555555555555555) from
L1 entry 8000000c320d9063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c320d9063
(XEN) mm.c:908:d0 Error getting mfn c320da (pfn 5555555555555555) from
L1 entry 8000000c320da063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c320da063
(XEN) mm.c:908:d0 Error getting mfn c320db (pfn 5555555555555555) from
L1 entry 8000000c320db063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c320db063
(XEN) mm.c:908:d0 Error getting mfn c320dc (pfn 5555555555555555) from
L1 entry 8000000c320dc063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c320dc063
(XEN) mm.c:908:d0 Error getting mfn c320dd (pfn 5555555555555555) from
L1 entry 8000000c320dd063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c320dd063
(XEN) mm.c:908:d0 Error getting mfn c320de (pfn 5555555555555555) from
L1 entry 8000000c320de063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c320de063
(XEN) mm.c:908:d0 Error getting mfn c320df (pfn 5555555555555555) from
L1 entry 8000000c320df063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c320df063
(XEN) mm.c:908:d0 Error getting mfn c320e0 (pfn 5555555555555555) from
L1 entry 8000000c320e0063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c320e0063
(XEN) mm.c:908:d0 Error getting mfn c320e1 (pfn 5555555555555555) from
L1 entry 8000000c320e1063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c320e1063
(XEN) mm.c:908:d0 Error getting mfn c320e2 (pfn 5555555555555555) from
L1 entry 8000000c320e2063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c320e2063
(XEN) mm.c:908:d0 Error getting mfn c320e3 (pfn 5555555555555555) from
L1 entry 8000000c320e3063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c320e3063
(XEN) mm.c:908:d0 Error getting mfn c320e4 (pfn 5555555555555555) from
L1 entry 8000000c320e4063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c320e4063
(XEN) mm.c:908:d0 Error getting mfn c320e5 (pfn 5555555555555555) from
L1 entry 8000000c320e5063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c320e5063
(XEN) mm.c:908:d0 Error getting mfn c320e6 (pfn 5555555555555555) from
L1 entry 8000000c320e6063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c320e6063
(XEN) mm.c:908:d0 Error getting mfn c320e7 (pfn 5555555555555555) from
L1 entry 8000000c320e7063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c320e7063
(XEN) mm.c:908:d0 Error getting mfn c320e8 (pfn 5555555555555555) from
L1 entry 8000000c320e8063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c320e8063
(XEN) mm.c:908:d0 Error getting mfn c320e9 (pfn 5555555555555555) from
L1 entry 8000000c320e9063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c320e9063
(XEN) mm.c:908:d0 Error getting mfn c320ea (pfn 5555555555555555) from
L1 entry 8000000c320ea063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c320ea063
(XEN) mm.c:908:d0 Error getting mfn c320eb (pfn 5555555555555555) from
L1 entry 8000000c320eb063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c320eb063
(XEN) mm.c:908:d0 Error getting mfn c320ec (pfn 5555555555555555) from
L1 entry 8000000c320ec063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c320ec063
(XEN) mm.c:908:d0 Error getting mfn c320ed (pfn 5555555555555555) from
L1 entry 8000000c320ed063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c320ed063
(XEN) mm.c:908:d0 Error getting mfn c320ee (pfn 5555555555555555) from
L1 entry 8000000c320ee063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c320ee063
(XEN) mm.c:908:d0 Error getting mfn c320ef (pfn 5555555555555555) from
L1 entry 8000000c320ef063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c320ef063
(XEN) mm.c:908:d0 Error getting mfn c320f0 (pfn 5555555555555555) from
L1 entry 8000000c320f0063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c320f0063
(XEN) mm.c:908:d0 Error getting mfn c320f1 (pfn 5555555555555555) from
L1 entry 8000000c320f1063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c320f1063
(XEN) mm.c:908:d0 Error getting mfn c320f2 (pfn 5555555555555555) from
L1 entry 8000000c320f2063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c320f2063
(XEN) mm.c:908:d0 Error getting mfn c320f3 (pfn 5555555555555555) from
L1 entry 8000000c320f3063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c320f3063
(XEN) mm.c:908:d0 Error getting mfn c320f4 (pfn 5555555555555555) from
L1 entry 8000000c320f4063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c320f4063
(XEN) mm.c:908:d0 Error getting mfn c320f5 (pfn 5555555555555555) from
L1 entry 8000000c320f5063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c320f5063
(XEN) mm.c:908:d0 Error getting mfn c320f6 (pfn 5555555555555555) from
L1 entry 8000000c320f6063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c320f6063
(XEN) mm.c:908:d0 Error getting mfn c320f7 (pfn 5555555555555555) from
L1 entry 8000000c320f7063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c320f7063
(XEN) mm.c:908:d0 Error getting mfn c320f8 (pfn 5555555555555555) from
L1 entry 8000000c320f8063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c320f8063
(XEN) mm.c:908:d0 Error getting mfn c320f9 (pfn 5555555555555555) from
L1 entry 8000000c320f9063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c320f9063
(XEN) mm.c:908:d0 Error getting mfn c320fa (pfn 5555555555555555) from
L1 entry 8000000c320fa063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c320fa063
(XEN) mm.c:908:d0 Error getting mfn c320fb (pfn 5555555555555555) from
L1 entry 8000000c320fb063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c320fb063
(XEN) mm.c:908:d0 Error getting mfn c320fc (pfn 5555555555555555) from
L1 entry 8000000c320fc063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c320fc063
(XEN) mm.c:908:d0 Error getting mfn c320fd (pfn 5555555555555555) from
L1 entry 8000000c320fd063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c320fd063
(XEN) mm.c:908:d0 Error getting mfn c320fe (pfn 5555555555555555) from
L1 entry 8000000c320fe063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c320fe063
(XEN) mm.c:908:d0 Error getting mfn c320ff (pfn 5555555555555555) from
L1 entry 8000000c320ff063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c320ff063
(XEN) mm.c:908:d0 Error getting mfn c32110 (pfn 5555555555555555) from
L1 entry 8000000c32110063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c32110063
(XEN) mm.c:908:d0 Error getting mfn c32111 (pfn 5555555555555555) from
L1 entry 8000000c32111063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c32111063
(XEN) mm.c:908:d0 Error getting mfn c32112 (pfn 5555555555555555) from
L1 entry 8000000c32112063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c32112063
(XEN) mm.c:908:d0 Error getting mfn c32113 (pfn 5555555555555555) from
L1 entry 8000000c32113063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c32113063
(XEN) mm.c:908:d0 Error getting mfn c32114 (pfn 5555555555555555) from
L1 entry 8000000c32114063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c32114063
(XEN) mm.c:908:d0 Error getting mfn c32115 (pfn 5555555555555555) from
L1 entry 8000000c32115063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c32115063
(XEN) mm.c:908:d0 Error getting mfn c32116 (pfn 5555555555555555) from
L1 entry 8000000c32116063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c32116063
(XEN) mm.c:908:d0 Error getting mfn c32117 (pfn 5555555555555555) from
L1 entry 8000000c32117063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c32117063
Reserving virtual address space above 0xfcc00000
Linux version 3.4.11 (package@squeeze64) (gcc version 4.4.5 (Debian
4.4.5-8) ) #16 SMP Wed Sep 19 13:42:38 UTC 2012
KERNEL supported cpus:

  Intel GenuineIntel

Freeing  9b-100 pfn range: 101 pages freed

1-1 mapping on 9b->100

1-1 mapping on bf730->100000

Released 101 pages of unused memory

Set 264501 page(s) to 1-1 mapping

BIOS-provided physical RAM map:

 Xen: 0000000000000000 - 000000000009b000 (usable)

 Xen: 000000000009b400 - 0000000000100000 (reserved)

 Xen: 0000000000100000 - 0000000040065000 (usable)

 Xen: 0000000040065000 - 00000000bf730000 (unusable)

 Xen: 00000000bf730000 - 00000000bf73e000 (ACPI data)

 Xen: 00000000bf73e000 - 00000000bf7a0000 (ACPI NVS)

 Xen: 00000000bf7a0000 - 00000000bf7b0000 (reserved)

 Xen: 00000000bf7bc000 - 00000000c0000000 (reserved)

 Xen: 00000000e0000000 - 00000000f0000000 (reserved)

 Xen: 00000000fec00000 - 00000000fec01000 (reserved)

 Xen: 00000000fec8a000 - 00000000fec8b000 (reserved)

 Xen: 00000000fee00000 - 00000000fee01000 (reserved)

 Xen: 00000000ffa00000 - 0000000100000000 (reserved)

 Xen: 0000000100000000 - 0000000c40000000 (unusable)

NX (Execute Disable) protection: active

DMI present.

DMI: Dell       C6100           /0D61XP, BIOS 1.66 12/23/2011

e820 update range: 0000000000000000 - 0000000000010000 (usable) ==> (reserved)

e820 remove range: 00000000000a0000 - 0000000000100000 (usable)

last_pfn = 0x40065 max_arch_pfn = 0x1000000

initial memory mapped : 0 - 027ff000

Base memory trampoline at [c009a000] 9a000 size 4096

init_memory_mapping: 0000000000000000-00000000345fe000

 0000000000 - 00345fe000 page 4k

kernel direct mapping tables up to 345fe000 @ 2658000-27ff000

xen: setting RW the range 27e9000 - 27ff000

RAMDISK: 017dc000 - 01ac0000

ACPI: RSDP 000fa6f0 00024 (v02 ACPIAM)
ACPI: XSDT bf730100 0006C (v01 122311 XSDT1136 20111223 MSFT 00000097)
ACPI: FACP bf730290 000F4 (v04 122311 FACP1136 20111223 MSFT 00000097)
ACPI: DSDT bf730540 048F7 (v02  5442B 5442B166 00000166 INTL 20051117)
ACPI: FACS bf73e000 00040
ACPI: APIC bf730390 0011E (v02 122311 APIC1136 20111223 MSFT 00000097)
ACPI: SPCR bf7304b0 00050 (v01 122311 SPCR1136 20111223 MSFT 00000097)
ACPI: MCFG bf730500 0003C (v01 122311 OEMMCFG  20111223 MSFT 00000097)
ACPI: OEMB bf73e040 00082 (v01 122311 OEMB1136 20111223 MSFT 00000097)
ACPI: SRAT bf73a540 00250 (v02 122311 OEMSRAT  00000001 INTL 00000001)
ACPI: HPET bf73a790 00038 (v01 122311 OEMHPET  20111223 MSFT 00000097)
ACPI: XMAR bf73e0d0 000D8 (v01    AMI  OEMDMAR 00000001 MSFT 00000097)
ACPI: SSDT bf7439a0 00363 (v01 DpgPmm    CpuPm 00000012 INTL 20051117)
ACPI: Local APIC address 0xfee00000

No NUMA configuration found
Faking a node at 0000000000000000-0000000040065000
node 0 pfn: [0 - 40065]
remap_alloc: node 0 [3fe00000-40000000) -> [f4200000-f4400000)
Initmem setup node 0 0000000000000000-0000000040065000
  NODE_DATA [0000000034200000 - 0000000034201fff] (remapped)
186MB HIGHMEM available.
837MB LOWMEM available.

max_low_pfn = 345fe, highstart_pfn = 345fe
Low memory ends at vaddr f45fe000
High memory starts at vaddr f45fe000
  mapped low ram: 0 - 345fe000
  low ram: 0 - 345fe000
Zone PFN ranges:

  DMA      0x00000010 -> 0x00001000

  Normal   0x00001000 -> 0x000345fe

  HighMem  0x000345fe -> 0x00040065

Movable zone start PFN for each node

Early memory PFN ranges

    0: 0x00000010 -> 0x0000009b

    0: 0x00000100 -> 0x00040065

On node 0 totalpages: 262128

  DMA zone: 32 pages used for memmap

  DMA zone: 0 pages reserved

  DMA zone: 3947 pages, LIFO batch:0

  Normal zone: 1644 pages used for memmap

  Normal zone: 208786 pages, LIFO batch:31

  HighMem zone: 373 pages used for memmap

  HighMem zone: 47346 pages, LIFO batch:15

Using APIC driver default

ACPI: PM-Timer IO Port: 0x808

ACPI: Local APIC address 0xfee00000

ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled)

ACPI: LAPIC (acpi_id[0x02] lapic_id[0x02] enabled)

ACPI: LAPIC (acpi_id[0x03] lapic_id[0x04] enabled)

ACPI: LAPIC (acpi_id[0x04] lapic_id[0x10] enabled)

ACPI: LAPIC (acpi_id[0x05] lapic_id[0x12] enabled)

ACPI: LAPIC (acpi_id[0x06] lapic_id[0x14] enabled)

ACPI: LAPIC (acpi_id[0x07] lapic_id[0x20] enabled)

ACPI: LAPIC (acpi_id[0x08] lapic_id[0x22] enabled)

ACPI: LAPIC (acpi_id[0x09] lapic_id[0x24] enabled)

ACPI: LAPIC (acpi_id[0x0a] lapic_id[0x30] enabled)

ACPI: LAPIC (acpi_id[0x0b] lapic_id[0x32] enabled)

ACPI: LAPIC (acpi_id[0x0c] lapic_id[0x34] enabled)

ACPI: LAPIC (acpi_id[0x0d] lapic_id[0x01] enabled)

ACPI: LAPIC (acpi_id[0x0e] lapic_id[0x03] enabled)

ACPI: LAPIC (acpi_id[0x0f] lapic_id[0x05] enabled)

ACPI: LAPIC (acpi_id[0x10] lapic_id[0x11] enabled)

ACPI: LAPIC (acpi_id[0x11] lapic_id[0x13] enabled)

ACPI: LAPIC (acpi_id[0x12] lapic_id[0x15] enabled)

ACPI: LAPIC (acpi_id[0x13] lapic_id[0x21] enabled)

ACPI: LAPIC (acpi_id[0x14] lapic_id[0x23] enabled)

ACPI: LAPIC (acpi_id[0x15] lapic_id[0x25] enabled)

ACPI: LAPIC (acpi_id[0x16] lapic_id[0x31] enabled)

ACPI: LAPIC (acpi_id[0x17] lapic_id[0x33] enabled)

ACPI: LAPIC (acpi_id[0x18] lapic_id[0x35] enabled)

ACPI: LAPIC_NMI (acpi_id[0xff] dfl dfl lint[0x1])

ACPI: IOAPIC (id[0x06] address[0xfec00000] gsi_base[0])

IOAPIC[0]: apic_id 6, version 253, address 0xfec00000, GSI 0-253

ACPI: IOAPIC (id[0x07] address[0xfec8a000] gsi_base[24])

IOAPIC[1]: apic_id 7, version 253, address 0xfec8a000, GSI 24-277

ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)

ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)

ACPI: IRQ0 used by override.

ACPI: IRQ2 used by override.

ACPI: IRQ9 used by override.

Using ACPI (MADT) for SMP configuration information

ACPI: HPET id: 0x8086a301 base: 0xfed00000

SMP: Allowing 24 CPUs, 0 hotplug CPUs

nr_irqs_gsi: 294

Allocating PCI resources starting at c0000000 (gap: c0000000:20000000)

Booting paravirtualized kernel on Xen

Xen version: 4.1.3 (preserve-AD)

setup_percpu: NR_CPUS:32 nr_cpumask_bits:32 nr_cpu_ids:24 nr_node_ids:1

PERCPU: Embedded 12 pages/cpu @f44b6000 s27072 r0 d22080 u49152

pcpu-alloc: s27072 r0 d22080 u49152 alloc=12*4096

pcpu-alloc: [0] 00 [0] 01 [0] 02 [0] 03 [0] 04 [0] 05 [0] 06 [0] 07

pcpu-alloc: [0] 08 [0] 09 [0] 10 [0] 11 [0] 12 [0] 13 [0] 14 [0] 15

pcpu-alloc: [0] 16 [0] 17 [0] 18 [0] 19 [0] 20 [0] 21 [0] 22 [0] 23

Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 260079

Policy zone: HighMem

Kernel command line: root=/dev/nfs ip=:::::eth0:dhcp nfsroot=
loglvl=all verbose=y console=hvc0 debug loglevel=8

PID hash table entries: 4096 (order: 2, 16384 bytes)

Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)

Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)

Initializing CPU#0

Placing 64MB software IO TLB between ef5c0000 - f35c0000

software IO TLB at phys 0x2f5c0000 - 0x335c0000

Initializing HighMem for node 0 (000345fe:00040065)

Memory: 952272k/1048980k available (3657k kernel code, 93788k
reserved, 1416k data, 356k init, 188424k highmem)

virtual kernel memory layout:

    fixmap  : 0xfc936000 - 0xfcbff000   (2852 kB)

    pkmap   : 0xfc600000 - 0xfc800000   (2048 kB)

    vmalloc : 0xf4dfe000 - 0xfc5fe000   ( 120 MB)

    lowmem  : 0xc0000000 - 0xf45fe000   ( 837 MB)

      .init : 0xc14f5000 - 0xc154e000   ( 356 kB)

      .data : 0xc1392789 - 0xc14f4940   (1416 kB)

      .text : 0xc1000000 - 0xc1392789   (3657 kB)

Hierarchical RCU implementation.

	Additional per-CPU info printed with stalls.

NR_IRQS:2304 nr_irqs:256 16

CPU 0 irqstacks, hard=ef008000 soft=ef00a000

xen: sci override: global_irq=9 trigger=0 polarity=0
xen: registering gsi 9 triggering 0 polarity 0
xen: --> pirq=9 -> irq=9 (gsi=9)
xen: acpi sci 9
xen: --> pirq=1 -> irq=1 (gsi=1)
xen: --> pirq=2 -> irq=2 (gsi=2)
xen: --> pirq=3 -> irq=3 (gsi=3)
xen: --> pirq=4 -> irq=4 (gsi=4)
xen: --> pirq=5 -> irq=5 (gsi=5)
xen: --> pirq=6 -> irq=6 (gsi=6)
xen: --> pirq=7 -> irq=7 (gsi=7)
xen: --> pirq=8 -> irq=8 (gsi=8)
xen: --> pirq=10 -> irq=10 (gsi=10)
xen: --> pirq=11 -> irq=11 (gsi=11)
xen: --> pirq=12 -> irq=12 (gsi=12)
xen: --> pirq=13 -> irq=13 (gsi=13)
xen: --> pirq=14 -> irq=14 (gsi=14)
xen: --> pirq=15 -> irq=15 (gsi=15)

Console: colour VGA+ 80x25

console [hvc0] enabled

Xen: using vcpuop timer interface

installing Xen timer for CPU 0

Detected 2266.824 MHz processor.

Calibrating delay loop (skipped), value calculated using timer
frequency.. 4533.64 BogoMIPS (lpj=9067296)

pid_max: default: 32768 minimum: 301

Mount-cache hash table entries: 512

CPU: Physical Processor ID: 0

CPU: Processor Core ID: 0

ENERGY_PERF_BIAS: Set to 'normal', was 'performance'

ENERGY_PERF_BIAS: View and update with x86_energy_perf_policy(8)

SMP alternatives: switching to UP code

Freeing SMP alternatives: 20k freed

ACPI: Core revision 20120320

Performance Events: unsupported p6 CPU model 44 no PMU driver,
software events only.

Brought up 1 CPUs

Grant tables using version 2 layout.

Grant table initialized

NET: Registered protocol family 16

ACPI: bus type pci registered

dca service started, version 1.12.1

PCI: MMCONFIG for domain 0000 [bus 00-ff] at [mem
0xe0000000-0xefffffff] (base 0xe0000000)

PCI: MMCONFIG at [mem 0xe0000000-0xefffffff] reserved in E820

PCI: Using MMCONFIG for extended config space

PCI: Using configuration type 1 for base access

bio: create slab <bio-0> at 0

ACPI: Added _OSI(Module Device)

ACPI: Added _OSI(Processor Device)

ACPI: Added _OSI(3.0 _SCP Extensions)

ACPI: Added _OSI(Processor Aggregator Device)

ACPI: EC: Look up EC in DSDT

\_SB_:_OSC invalid UUID

_OSC request data:1 6

ACPI: Executed 2 blocks of module-level executable AML code

ACPI: SSDT bf73e1b0 0414C (v01 DpgPmm  P001Ist 00000011 INTL 20051117)

ACPI: Dynamic OEM Table Load:

ACPI: SSDT   (null) 0414C (v01 DpgPmm  P001Ist 00000011 INTL 20051117)

ACPI: SSDT bf742300 00C88 (v01  PmRef  P001Cst 00003001 INTL 20051117)

ACPI: Dynamic OEM Table Load:

ACPI: SSDT   (null) 00C88 (v01  PmRef  P001Cst 00003001 INTL 20051117)

ACPI: SSDT bf742f90 00A0A (v01  PmRef  Cpu0Tst 00003000 INTL 20051117)

ACPI: Dynamic OEM Table Load:

ACPI: SSDT   (null) 00A0A (v01  PmRef  Cpu0Tst 00003000 INTL 20051117)

ACPI: Interpreter enabled

ACPI: (supports S0 S5)

ACPI: Using IOAPIC for interrupt routing

PCI: Using host bridge windows from ACPI; if necessary, use
"pci=nocrs" and report a bug

ACPI: PCI Root Bridge [PCI0] (domain 0000 [bus 00-ff])

pci_root PNP0A08:00: host bridge window [io  0x0000-0x03af]

pci_root PNP0A08:00: host bridge window [io  0x03e0-0x0cf7]

pci_root PNP0A08:00: host bridge window [io  0x03b0-0x03bb]

pci_root PNP0A08:00: host bridge window [io  0x03c0-0x03df]

pci_root PNP0A08:00: host bridge window [io  0x0d00-0xffff]

pci_root PNP0A08:00: host bridge window [mem 0x000a0000-0x000bffff]

pci_root PNP0A08:00: host bridge window [mem 0x000d0000-0x000dffff]

pci_root PNP0A08:00: host bridge window [mem 0xc0000000-0xdfffffff]

pci_root PNP0A08:00: host bridge window [mem 0xf0000000-0xfed8ffff]

PCI host bridge to bus 0000:00

pci_bus 0000:00: root bus resource [io  0x0000-0x03af]

pci_bus 0000:00: root bus resource [io  0x03e0-0x0cf7]

pci_bus 0000:00: root bus resource [io  0x03b0-0x03bb]

pci_bus 0000:00: root bus resource [io  0x03c0-0x03df]

pci_bus 0000:00: root bus resource [io  0x0d00-0xffff]

pci_bus 0000:00: root bus resource [mem 0x000a0000-0x000bffff]

pci_bus 0000:00: root bus resource [mem 0x000d0000-0x000dffff]

pci_bus 0000:00: root bus resource [mem 0xc0000000-0xdfffffff]

pci_bus 0000:00: root bus resource [mem 0xf0000000-0xfed8ffff]

pci 0000:00:00.0: [8086:3406] type 00 class 0x060000

pci 0000:00:00.0: PME# supported from D0 D3hot D3cold

pci 0000:00:01.0: [8086:3408] type 01 class 0x060400

pci 0000:00:01.0: PME# supported from D0 D3hot D3cold

pci 0000:00:03.0: [8086:340a] type 01 class 0x060400

pci 0000:00:03.0: PME# supported from D0 D3hot D3cold

pci 0000:00:05.0: [8086:340c] type 01 class 0x060400

pci 0000:00:05.0: PME# supported from D0 D3hot D3cold

pci 0000:00:07.0: [8086:340e] type 01 class 0x060400

pci 0000:00:07.0: PME# supported from D0 D3hot D3cold

pci 0000:00:13.0: [8086:342d] type 00 class 0x080020

pci 0000:00:13.0: reg 10: [mem 0xfec8a000-0xfec8afff]

pci 0000:00:13.0: PME# supported from D0 D3hot D3cold

pci 0000:00:14.0: [8086:342e] type 00 class 0x080000

pci 0000:00:14.1: [8086:3422] type 00 class 0x080000

pci 0000:00:14.2: [8086:3423] type 00 class 0x080000

pci 0000:00:14.3: [8086:3438] type 00 class 0x080000

pci 0000:00:16.0: [8086:3430] type 00 class 0x088000

pci 0000:00:16.0: reg 10: [mem 0xfbef8000-0xfbefbfff 64bit]

pci 0000:00:16.1: [8086:3431] type 00 class 0x088000

pci 0000:00:16.1: reg 10: [mem 0xfbef4000-0xfbef7fff 64bit]

pci 0000:00:16.2: [8086:3432] type 00 class 0x088000

pci 0000:00:16.2: reg 10: [mem 0xfbef0000-0xfbef3fff 64bit]

pci 0000:00:16.3: [8086:3433] type 00 class 0x088000

pci 0000:00:16.3: reg 10: [mem 0xfbeec000-0xfbeeffff 64bit]

pci 0000:00:16.4: [8086:3429] type 00 class 0x088000

pci 0000:00:16.4: reg 10: [mem 0xfbee8000-0xfbeebfff 64bit]

pci 0000:00:16.5: [8086:342a] type 00 class 0x088000

pci 0000:00:16.5: reg 10: [mem 0xfbee4000-0xfbee7fff 64bit]

pci 0000:00:16.6: [8086:342b] type 00 class 0x088000

pci 0000:00:16.6: reg 10: [mem 0xfbee0000-0xfbee3fff 64bit]

pci 0000:00:16.7: [8086:342c] type 00 class 0x088000

pci 0000:00:16.7: reg 10: [mem 0xfbedc000-0xfbedffff 64bit]

pci 0000:00:1d.0: [8086:3a34] type 00 class 0x0c0300

pci 0000:00:1d.0: reg 20: [io  0xbc00-0xbc1f]

pci 0000:00:1d.1: [8086:3a35] type 00 class 0x0c0300

pci 0000:00:1d.1: reg 20: [io  0xb880-0xb89f]

pci 0000:00:1d.2: [8086:3a36] type 00 class 0x0c0300

pci 0000:00:1d.2: reg 20: [io  0xb800-0xb81f]

pci 0000:00:1d.7: [8086:3a3a] type 00 class 0x0c0320

pci 0000:00:1d.7: reg 10: [mem 0xfbeda000-0xfbeda3ff]

pci 0000:00:1d.7: PME# supported from D0 D3hot D3cold

pci 0000:00:1e.0: [8086:244e] type 01 class 0x060401

pci 0000:00:1f.0: [8086:3a16] type 00 class 0x060100

pci 0000:00:1f.0: ICH7 LPC Generic IO decode 2 PIO at 0ca0 (mask 000f)

pci 0000:00:1f.2: [8086:3a22] type 00 class 0x010601

pci 0000:00:1f.2: reg 10: [io  0xac00-0xac07]

pci 0000:00:1f.2: reg 14: [io  0xb480-0xb483]

pci 0000:00:1f.2: reg 18: [io  0xb400-0xb407]

pci 0000:00:1f.2: reg 1c: [io  0xb080-0xb083]

pci 0000:00:1f.2: reg 20: [io  0xb000-0xb01f]

pci 0000:00:1f.2: reg 24: [mem 0xfbed8000-0xfbed87ff]

pci 0000:00:1f.2: PME# supported from D3hot

pci 0000:00:1f.3: [8086:3a30] type 00 class 0x0c0500

pci 0000:00:1f.3: reg 10: [mem 0xfbed6000-0xfbed60ff 64bit]

pci 0000:00:1f.3: reg 20: [io  0x0400-0x041f]

pci 0000:01:00.0: [8086:10c9] type 00 class 0x020000

pci 0000:01:00.0: reg 10: [mem 0xfbce0000-0xfbcfffff]

pci 0000:01:00.0: reg 14: [mem 0xfbcc0000-0xfbcdffff]

pci 0000:01:00.0: reg 18: [io  0xcc00-0xcc1f]

pci 0000:01:00.0: reg 1c: [mem 0xfbc9c000-0xfbc9ffff]

pci 0000:01:00.0: reg 30: [mem 0xfbca0000-0xfbcbffff pref]

pci 0000:01:00.0: PME# supported from D0 D3hot D3cold

pci 0000:01:00.1: [8086:10c9] type 00 class 0x020000

pci 0000:01:00.1: reg 10: [mem 0xfbc20000-0xfbc3ffff]

pci 0000:01:00.1: reg 14: [mem 0xfbc00000-0xfbc1ffff]

pci 0000:01:00.1: reg 18: [io  0xc880-0xc89f]

pci 0000:01:00.1: reg 1c: [mem 0xfbbdc000-0xfbbdffff]

pci 0000:01:00.1: reg 30: [mem 0xfbbe0000-0xfbbfffff pref]

pci 0000:01:00.1: PME# supported from D0 D3hot D3cold

pci 0000:00:01.0: PCI bridge to [bus 01-02]

pci 0000:00:01.0:   bridge window [io  0xc000-0xcfff]

pci 0000:00:01.0:   bridge window [mem 0xfbb00000-0xfbcfffff]

pci 0000:03:00.0: [8086:10fb] type 00 class 0x020000

pci 0000:03:00.0: reg 10: [mem 0xfbdc0000-0xfbdfffff 64bit]

pci 0000:03:00.0: reg 18: [io  0xdc00-0xdc1f]

pci 0000:03:00.0: reg 20: [mem 0xfbd9c000-0xfbd9ffff 64bit]

pci 0000:03:00.0: reg 30: [mem 0xfbda0000-0xfbdbffff pref]

pci 0000:03:00.0: PME# supported from D0 D3hot

pci 0000:03:00.1: [8086:10fb] type 00 class 0x020000

pci 0000:03:00.1: reg 10: [mem 0xfbd40000-0xfbd7ffff 64bit]

pci 0000:03:00.1: reg 18: [io  0xd880-0xd89f]

pci 0000:03:00.1: reg 20: [mem 0xfbd1c000-0xfbd1ffff 64bit]

pci 0000:03:00.1: reg 30: [mem 0xfbd20000-0xfbd3ffff pref]

pci 0000:03:00.1: PME# supported from D0 D3hot

pci 0000:00:03.0: PCI bridge to [bus 03-04]

pci 0000:00:03.0:   bridge window [io  0xd000-0xdfff]

pci 0000:00:03.0:   bridge window [mem 0xfbd00000-0xfbdfffff]

pci 0000:00:03.0:   bridge window [mem 0xf9c00000-0xf9ffffff 64bit pref]

pci 0000:00:05.0: PCI bridge to [bus 05-05]

pci 0000:00:07.0: PCI bridge to [bus 06-06]

pci 0000:07:04.0: [1a03:2000] type 00 class 0x030000

pci 0000:07:04.0: reg 10: [mem 0xfb000000-0xfb7fffff]

pci 0000:07:04.0: reg 14: [mem 0xfafe0000-0xfaffffff]

pci 0000:07:04.0: reg 18: [io  0xec00-0xec7f]

pci 0000:07:04.0: supports D1 D2

pci 0000:07:04.0: PME# supported from D0 D1 D2 D3hot D3cold

pci 0000:00:1e.0: PCI bridge to [bus 07-07] (subtractive decode)

pci 0000:00:1e.0:   bridge window [io  0xe000-0xefff]

pci 0000:00:1e.0:   bridge window [mem 0xfaf00000-0xfb7fffff]

pci 0000:00:1e.0:   bridge window [io  0x0000-0x03af] (subtractive decode)

pci 0000:00:1e.0:   bridge window [io  0x03e0-0x0cf7] (subtractive decode)

pci 0000:00:1e.0:   bridge window [io  0x03b0-0x03bb] (subtractive decode)

pci 0000:00:1e.0:   bridge window [io  0x03c0-0x03df] (subtractive decode)

pci 0000:00:1e.0:   bridge window [io  0x0d00-0xffff] (subtractive decode)

pci 0000:00:1e.0:   bridge window [mem 0x000a0000-0x000bffff]
(subtractive decode)

pci 0000:00:1e.0:   bridge window [mem 0x000d0000-0x000dffff]
(subtractive decode)

pci 0000:00:1e.0:   bridge window [mem 0xc0000000-0xdfffffff]
(subtractive decode)

pci 0000:00:1e.0:   bridge window [mem 0xf0000000-0xfed8ffff]
(subtractive decode)

ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT]

ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.NPE7._PRT]

ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.P0P1._PRT]

ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.NPE1._PRT]

ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.NPE5._PRT]

 pci0000:00: Unable to request _OSC control (_OSC support mask: 0x19)

(XEN) PCI add device 00:00.0
(XEN) PCI add device 00:01.0
(XEN) PCI add device 00:03.0
(XEN) PCI add device 00:05.0
(XEN) PCI add device 00:07.0
(XEN) PCI add device 00:13.0
(XEN) PCI add device 00:14.0
(XEN) PCI add device 00:14.1
(XEN) PCI add device 00:14.2
(XEN) PCI add device 00:14.3
(XEN) PCI add device 00:16.0
(XEN) PCI add device 00:16.1
(XEN) PCI add device 00:16.2
(XEN) PCI add device 00:16.3
(XEN) PCI add device 00:16.4
(XEN) PCI add device 00:16.5
(XEN) PCI add device 00:16.6
(XEN) PCI add device 00:16.7
(XEN) PCI add device 00:1d.0
(XEN) PCI add device 00:1d.1
(XEN) PCI add device 00:1d.2
(XEN) PCI add device 00:1d.7
(XEN) PCI add device 00:1e.0
(XEN) PCI add device 00:1f.0
(XEN) PCI add device 00:1f.2
(XEN) PCI add device 00:1f.3
(XEN) PCI add device 01:00.0
(XEN) PCI add device 01:00.1
(XEN) PCI add device 03:00.0
(XEN) PCI add device 03:00.1
(XEN) PCI add device 07:04.0
ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 6 7 *10 11 12 14 15)

ACPI: PCI Interrupt Link [LNKB] (IRQs *5)

ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 6 7 10 11 12 14 *15)

ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 6 7 10 *11 12 14 15)

ACPI: PCI Interrupt Link [LNKE] (IRQs 3 4 6 7 10 11 12 14 15) *0, disabled.

ACPI: PCI Interrupt Link [LNKF] (IRQs 3 4 6 7 10 11 12 14 15) *0, disabled.

ACPI: PCI Interrupt Link [LNKG] (IRQs 3 4 6 7 10 11 12 14 15) *0, disabled.

ACPI: PCI Interrupt Link [LNKH] (IRQs 3 4 6 7 10 11 12 *14 15)

xen/balloon: Initialising balloon driver.

xen-balloon: Initialising balloon driver.

xen/balloon: Xen selfballooning driver disabled for domain0.

vgaarb: device added: PCI:0000:07:04.0,decodes=io+mem,owns=io+mem,locks=none

vgaarb: loaded

vgaarb: bridge control possible 0000:07:04.0

PCI: Using ACPI for IRQ routing

PCI: Discovered peer bus fe

PCI: root bus fe: using default resources

PCI host bridge to bus 0000:fe

pci_bus 0000:fe: root bus resource [io  0x0000-0xffff]

pci_bus 0000:fe: root bus resource [mem 0x00000000-0xffffffffff]

pci 0000:fe:00.0: [8086:2c70] type 00 class 0x060000

pci 0000:fe:00.1: [8086:2d81] type 00 class 0x060000

pci 0000:fe:02.0: [8086:2d90] type 00 class 0x060000

pci 0000:fe:02.1: [8086:2d91] type 00 class 0x060000

pci 0000:fe:02.2: [8086:2d92] type 00 class 0x060000

pci 0000:fe:02.3: [8086:2d93] type 00 class 0x060000

pci 0000:fe:02.4: [8086:2d94] type 00 class 0x060000

pci 0000:fe:02.5: [8086:2d95] type 00 class 0x060000

pci 0000:fe:03.0: [8086:2d98] type 00 class 0x060000

pci 0000:fe:03.1: [8086:2d99] type 00 class 0x060000

pci 0000:fe:03.2: [8086:2d9a] type 00 class 0x060000

pci 0000:fe:03.4: [8086:2d9c] type 00 class 0x060000

pci 0000:fe:04.0: [8086:2da0] type 00 class 0x060000

pci 0000:fe:04.1: [8086:2da1] type 00 class 0x060000

pci 0000:fe:04.2: [8086:2da2] type 00 class 0x060000

pci 0000:fe:04.3: [8086:2da3] type 00 class 0x060000

pci 0000:fe:05.0: [8086:2da8] type 00 class 0x060000

pci 0000:fe:05.1: [8086:2da9] type 00 class 0x060000

pci 0000:fe:05.2: [8086:2daa] type 00 class 0x060000

pci 0000:fe:05.3: [8086:2dab] type 00 class 0x060000

pci 0000:fe:06.0: [8086:2db0] type 00 class 0x060000

pci 0000:fe:06.1: [8086:2db1] type 00 class 0x060000

pci 0000:fe:06.2: [8086:2db2] type 00 class 0x060000

pci 0000:fe:06.3: [8086:2db3] type 00 class 0x060000

(XEN) PCI add device fe:00.0
(XEN) PCI add device fe:00.1
(XEN) PCI add device fe:02.0
(XEN) PCI add device fe:02.1
(XEN) PCI add device fe:02.2
(XEN) PCI add device fe:02.3
(XEN) PCI add device fe:02.4
(XEN) PCI add device fe:02.5
(XEN) PCI add device fe:03.0
(XEN) PCI add device fe:03.1
(XEN) PCI add device fe:03.2
(XEN) PCI add device fe:03.4
(XEN) PCI add device fe:04.0
(XEN) PCI add device fe:04.1
(XEN) PCI add device fe:04.2
(XEN) PCI add device fe:04.3
(XEN) PCI add device fe:05.0
(XEN) PCI add device fe:05.1
(XEN) PCI add device fe:05.2
(XEN) PCI add device fe:05.3
(XEN) PCI add device fe:06.0
(XEN) PCI add device fe:06.1
(XEN) PCI add device fe:06.2
(XEN) PCI add device fe:06.3
PCI: Discovered peer bus ff

PCI: root bus ff: using default resources

PCI host bridge to bus 0000:ff

pci_bus 0000:ff: root bus resource [io  0x0000-0xffff]

pci_bus 0000:ff: root bus resource [mem 0x00000000-0xffffffffff]

pci 0000:ff:00.0: [8086:2c70] type 00 class 0x060000

pci 0000:ff:00.1: [8086:2d81] type 00 class 0x060000

pci 0000:ff:02.0: [8086:2d90] type 00 class 0x060000

pci 0000:ff:02.1: [8086:2d91] type 00 class 0x060000

pci 0000:ff:02.2: [8086:2d92] type 00 class 0x060000

pci 0000:ff:02.3: [8086:2d93] type 00 class 0x060000

pci 0000:ff:02.4: [8086:2d94] type 00 class 0x060000

pci 0000:ff:02.5: [8086:2d95] type 00 class 0x060000

pci 0000:ff:03.0: [8086:2d98] type 00 class 0x060000

pci 0000:ff:03.1: [8086:2d99] type 00 class 0x060000

pci 0000:ff:03.2: [8086:2d9a] type 00 class 0x060000

pci 0000:ff:03.4: [8086:2d9c] type 00 class 0x060000

pci 0000:ff:04.0: [8086:2da0] type 00 class 0x060000

pci 0000:ff:04.1: [8086:2da1] type 00 class 0x060000

pci 0000:ff:04.2: [8086:2da2] type 00 class 0x060000

pci 0000:ff:04.3: [8086:2da3] type 00 class 0x060000

pci 0000:ff:05.0: [8086:2da8] type 00 class 0x060000

pci 0000:ff:05.1: [8086:2da9] type 00 class 0x060000

pci 0000:ff:05.2: [8086:2daa] type 00 class 0x060000

pci 0000:ff:05.3: [8086:2dab] type 00 class 0x060000

pci 0000:ff:06.0: [8086:2db0] type 00 class 0x060000

pci 0000:ff:06.1: [8086:2db1] type 00 class 0x060000

pci 0000:ff:06.2: [8086:2db2] type 00 class 0x060000

pci 0000:ff:06.3: [8086:2db3] type 00 class 0x060000

(XEN) PCI add device ff:00.0
(XEN) PCI add device ff:00.1
(XEN) PCI add device ff:02.0
(XEN) PCI add device ff:02.1
(XEN) PCI add device ff:02.2
(XEN) PCI add device ff:02.3
(XEN) PCI add device ff:02.4
(XEN) PCI add device ff:02.5
(XEN) PCI add device ff:03.0
(XEN) PCI add device ff:03.1
(XEN) PCI add device ff:03.2
(XEN) PCI add device ff:03.4
(XEN) PCI add device ff:04.0
(XEN) PCI add device ff:04.1
(XEN) PCI add device ff:04.2
(XEN) PCI add device ff:04.3
(XEN) PCI add device ff:05.0
(XEN) PCI add device ff:05.1
(XEN) PCI add device ff:05.2
(XEN) PCI add device ff:05.3
(XEN) PCI add device ff:06.0
(XEN) PCI add device ff:06.1
(XEN) PCI add device ff:06.2
(XEN) PCI add device ff:06.3
PCI: pci_cache_line_size set to 64 bytes

reserve RAM buffer: 000000000009b000 - 000000000009ffff

reserve RAM buffer: 0000000040065000 - 0000000043ffffff

Switching to clocksource xen

pnp: PnP ACPI init

ACPI: bus type pnp registered

pnp 00:00: [bus 00-ff]

pnp 00:00: [io  0x0cf8-0x0cff]

pnp 00:00: [io  0x0000-0x03af window]

pnp 00:00: [io  0x03e0-0x0cf7 window]

pnp 00:00: [io  0x03b0-0x03bb window]

pnp 00:00: [io  0x03c0-0x03df window]

pnp 00:00: [io  0x0d00-0xffff window]

pnp 00:00: [mem 0x000a0000-0x000bffff window]

pnp 00:00: [mem 0x000d0000-0x000dffff window]

pnp 00:00: [mem 0xc0000000-0xdfffffff window]

pnp 00:00: [mem 0xf0000000-0xfed8ffff window]

pnp 00:00: Plug and Play ACPI device, IDs PNP0a08 PNP0a03 (active)

pnp 00:01: [mem 0xfbf00000-0xfbffffff]

pnp 00:01: [mem 0xfc000000-0xfcffffff]

pnp 00:01: [mem 0xfd000000-0xfdffffff]

pnp 00:01: [mem 0xfe000000-0xfebfffff]

pnp 00:01: [mem 0xfec8a000-0xfec8afff]

pnp 00:01: [mem 0xfed10000-0xfed10fff]

system 00:01: [mem 0xfbf00000-0xfbffffff] has been reserved

system 00:01: [mem 0xfc000000-0xfcffffff] has been reserved

system 00:01: [mem 0xfd000000-0xfdffffff] has been reserved

system 00:01: [mem 0xfe000000-0xfebfffff] has been reserved

system 00:01: [mem 0xfec8a000-0xfec8afff] could not be reserved

system 00:01: [mem 0xfed10000-0xfed10fff] has been reserved

system 00:01: Plug and Play ACPI device, IDs PNP0c01 (active)

pnp 00:02: [dma 4]

pnp 00:02: [io  0x0000-0x000f]

pnp 00:02: [io  0x0081-0x0083]

pnp 00:02: [io  0x0087]

pnp 00:02: [io  0x0089-0x008b]

pnp 00:02: [io  0x008f]

pnp 00:02: [io  0x00c0-0x00df]

pnp 00:02: Plug and Play ACPI device, IDs PNP0200 (active)

pnp 00:03: [io  0x0070-0x0071]

xen: registering gsi 8 triggering 1 polarity 0

pnp 00:03: [irq 8]

pnp 00:03: Plug and Play ACPI device, IDs PNP0b00 (active)

pnp 00:04: [io  0x0061]

pnp 00:04: Plug and Play ACPI device, IDs PNP0800 (active)

pnp 00:05: [io  0x00f0-0x00ff]

xen: registering gsi 13 triggering 1 polarity 0

pnp 00:05: [irq 13]

pnp 00:05: Plug and Play ACPI device, IDs PNP0c04 (active)

pnp 00:06: [io  0x0010-0x001f]

pnp 00:06: [io  0x0022-0x003f]

pnp 00:06: [io  0x0044-0x005f]

pnp 00:06: [io  0x0062-0x0063]

pnp 00:06: [io  0x0065-0x006f]

pnp 00:06: [io  0x0072-0x007f]

pnp 00:06: [io  0x0080]

pnp 00:06: [io  0x0084-0x0086]

pnp 00:06: [io  0x0088]

pnp 00:06: [io  0x008c-0x008e]

pnp 00:06: [io  0x0090-0x009f]

pnp 00:06: [io  0x00a2-0x00bf]

pnp 00:06: [io  0x00e0-0x00ef]

pnp 00:06: [io  0x04d0-0x04d1]

pnp 00:06: [io  0x0800-0x087f]

pnp 00:06: [io  0x0000-0xffffffffffffffff disabled]

pnp 00:06: [io  0x0500-0x057f]

pnp 00:06: [io  0x0000-0xffffffffffffffff disabled]

pnp 00:06: [mem 0xfed1c000-0xfed1ffff]

pnp 00:06: [mem 0xfed20000-0xfed3ffff]

pnp 00:06: [mem 0xfed40000-0xfed8ffff]

system 00:06: [io  0x04d0-0x04d1] has been reserved

system 00:06: [io  0x0800-0x087f] has been reserved

system 00:06: [io  0x0500-0x057f] has been reserved

system 00:06: [mem 0xfed1c000-0xfed1ffff] has been reserved

system 00:06: [mem 0xfed20000-0xfed3ffff] has been reserved

system 00:06: [mem 0xfed40000-0xfed8ffff] has been reserved

system 00:06: Plug and Play ACPI device, IDs PNP0c02 (active)

pnp 00:07: [io  0x0ca2]

pnp 00:07: [io  0x0ca3]

pnp 00:07: Plug and Play ACPI device, IDs IPI0001 (active)

pnp 00:08: [mem 0xfed00000-0xfed003ff]

pnp 00:08: Plug and Play ACPI device, IDs PNP0103 (active)

pnp 00:09: [io  0x0060]

pnp 00:09: [io  0x0064]

pnp 00:09: [mem 0xfec00000-0xfec00fff]

pnp 00:09: [mem 0xfee00000-0xfee00fff]

system 00:09: [mem 0xfec00000-0xfec00fff] could not be reserved

system 00:09: [mem 0xfee00000-0xfee00fff] has been reserved

system 00:09: Plug and Play ACPI device, IDs PNP0c02 (active)

pnp 00:0a: [mem 0xe0000000-0xefffffff]

system 00:0a: [mem 0xe0000000-0xefffffff] has been reserved

system 00:0a: Plug and Play ACPI device, IDs PNP0c02 (active)

pnp 00:0b: [mem 0x00000000-0x0009ffff]

pnp 00:0b: [mem 0x000c0000-0x000cffff]

pnp 00:0b: [mem 0x000e0000-0x000fffff]

pnp 00:0b: [mem 0x00100000-0xbfffffff]

pnp 00:0b: [mem 0xfed90000-0xffffffff]

system 00:0b: [mem 0x00000000-0x0009ffff] could not be reserved

system 00:0b: [mem 0x000c0000-0x000cffff] could not be reserved

system 00:0b: [mem 0x000e0000-0x000fffff] could not be reserved

system 00:0b: [mem 0x00100000-0xbfffffff] could not be reserved

system 00:0b: [mem 0xfed90000-0xffffffff] could not be reserved

system 00:0b: Plug and Play ACPI device, IDs PNP0c01 (active)

pnp: PnP ACPI: found 12 devices

ACPI: ACPI bus type pnp unregistered

PM-Timer failed consistency check  (0x0xffffff) - aborting.

pci 0000:00:01.0: PCI bridge to [bus 01-02]

pci 0000:00:01.0:   bridge window [io  0xc000-0xcfff]

pci 0000:00:01.0:   bridge window [mem 0xfbb00000-0xfbcfffff]

pci 0000:00:03.0: PCI bridge to [bus 03-04]

pci 0000:00:03.0:   bridge window [io  0xd000-0xdfff]

pci 0000:00:03.0:   bridge window [mem 0xfbd00000-0xfbdfffff]

pci 0000:00:03.0:   bridge window [mem 0xf9c00000-0xf9ffffff 64bit pref]

pci 0000:00:05.0: PCI bridge to [bus 05-05]

pci 0000:00:07.0: PCI bridge to [bus 06-06]

pci 0000:00:1e.0: PCI bridge to [bus 07-07]

pci 0000:00:1e.0:   bridge window [io  0xe000-0xefff]

pci 0000:00:1e.0:   bridge window [mem 0xfaf00000-0xfb7fffff]

pci 0000:00:1e.0: setting latency timer to 64

pci_bus 0000:00: resource 4 [io  0x0000-0x03af]

pci_bus 0000:00: resource 5 [io  0x03e0-0x0cf7]

pci_bus 0000:00: resource 6 [io  0x03b0-0x03bb]

pci_bus 0000:00: resource 7 [io  0x03c0-0x03df]

pci_bus 0000:00: resource 8 [io  0x0d00-0xffff]

pci_bus 0000:00: resource 9 [mem 0x000a0000-0x000bffff]

pci_bus 0000:00: resource 10 [mem 0x000d0000-0x000dffff]

pci_bus 0000:00: resource 11 [mem 0xc0000000-0xdfffffff]

pci_bus 0000:00: resource 12 [mem 0xf0000000-0xfed8ffff]

pci_bus 0000:01: resource 0 [io  0xc000-0xcfff]

pci_bus 0000:01: resource 1 [mem 0xfbb00000-0xfbcfffff]

pci_bus 0000:03: resource 0 [io  0xd000-0xdfff]

pci_bus 0000:03: resource 1 [mem 0xfbd00000-0xfbdfffff]

pci_bus 0000:03: resource 2 [mem 0xf9c00000-0xf9ffffff 64bit pref]

pci_bus 0000:07: resource 0 [io  0xe000-0xefff]

pci_bus 0000:07: resource 1 [mem 0xfaf00000-0xfb7fffff]

pci_bus 0000:07: resource 4 [io  0x0000-0x03af]

pci_bus 0000:07: resource 5 [io  0x03e0-0x0cf7]

pci_bus 0000:07: resource 6 [io  0x03b0-0x03bb]

pci_bus 0000:07: resource 7 [io  0x03c0-0x03df]

pci_bus 0000:07: resource 8 [io  0x0d00-0xffff]

pci_bus 0000:07: resource 9 [mem 0x000a0000-0x000bffff]

pci_bus 0000:07: resource 10 [mem 0x000d0000-0x000dffff]

pci_bus 0000:07: resource 11 [mem 0xc0000000-0xdfffffff]

pci_bus 0000:07: resource 12 [mem 0xf0000000-0xfed8ffff]

pci_bus 0000:fe: resource 4 [io  0x0000-0xffff]

pci_bus 0000:fe: resource 5 [mem 0x00000000-0xffffffffff]

pci_bus 0000:ff: resource 4 [io  0x0000-0xffff]

pci_bus 0000:ff: resource 5 [mem 0x00000000-0xffffffffff]

NET: Registered protocol family 2

IP route cache hash table entries: 32768 (order: 5, 131072 bytes)

TCP established hash table entries: 131072 (order: 8, 1048576 bytes)

TCP bind hash table entries: 65536 (order: 7, 524288 bytes)

TCP: Hash tables configured (established 131072 bind 65536)

TCP: reno registered

UDP hash table entries: 512 (order: 2, 16384 bytes)

UDP-Lite hash table entries: 512 (order: 2, 16384 bytes)

NET: Registered protocol family 1

RPC: Registered named UNIX socket transport module.

RPC: Registered udp transport module.

RPC: Registered tcp transport module.

RPC: Registered tcp NFSv4.1 backchannel transport module.

xen: registering gsi 23 triggering 0 polarity 1

xen: --> pirq=23 -> irq=23 (gsi=23)

xen: registering gsi 19 triggering 0 polarity 1

xen: --> pirq=19 -> irq=19 (gsi=19)

xen: registering gsi 18 triggering 0 polarity 1

xen: --> pirq=18 -> irq=18 (gsi=18)

xen: registering gsi 23 triggering 0 polarity 1

Already setup the GSI :23

pci 0000:07:04.0: Boot video device

PCI: CLS 256 bytes, default 64

Trying to unpack rootfs image as initramfs...

Freeing initrd memory: 2960k freed

microcode: CPU0 sig=0x206c2, pf=0x1, revision=0x14

microcode: Microcode Update Driver: v2.00
<tigran@aivazian.fsnet.co.uk>, Peter Oruba

highmem bounce pool size: 64 pages

NFS: Registering the id_resolver key type

msgmni has been set to 1497

Block layer SCSI generic (bsg) driver version 0.4 loaded (major 253)

io scheduler noop registered (default)

io scheduler deadline registered

io scheduler cfq registered

ioapic: probe of 0000:00:13.0 failed with error -22

ioatdma: Intel(R) QuickData Technology Driver 4.00

xen: registering gsi 43 triggering 0 polarity 1

xen: --> pirq=43 -> irq=43 (gsi=43)

(XEN) ../physdev.c:171: dom0: wrong map_pirq type 3
xen: registering gsi 44 triggering 0 polarity 1

xen: --> pirq=44 -> irq=44 (gsi=44)

xen: registering gsi 45 triggering 0 polarity 1

xen: --> pirq=45 -> irq=45 (gsi=45)

xen: registering gsi 46 triggering 0 polarity 1

xen: --> pirq=46 -> irq=46 (gsi=46)

xen: registering gsi 43 triggering 0 polarity 1

Already setup the GSI :43

xen: registering gsi 44 triggering 0 polarity 1

Already setup the GSI :44

xen: registering gsi 45 triggering 0 polarity 1

Already setup the GSI :45

xen: registering gsi 46 triggering 0 polarity 1

Already setup the GSI :46

Event-channel device installed.

xen-pciback: backend is vpci

Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled

serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A

brd: module loaded

loop: module loaded

igb: Intel(R) Gigabit Ethernet Network Driver - version 3.2.10-k

igb: Copyright (c) 2007-2012 Intel Corporation.

xen: registering gsi 17 triggering 0 polarity 1

xen: --> pirq=17 -> irq=17 (gsi=17)

igb 0000:01:00.0: Intel(R) Gigabit Ethernet Network Connection

igb 0000:01:00.0: eth0: (PCIe:2.5Gb/s:Width x4) 00:26:6c:ff:b3:8c

igb 0000:01:00.0: eth0: PBA No: 82576B-001

igb 0000:01:00.0: Using MSI-X interrupts. 1 rx queue(s), 1 tx queue(s)

xen: registering gsi 16 triggering 0 polarity 1

xen: --> pirq=16 -> irq=16 (gsi=16)

igb 0000:01:00.1: Intel(R) Gigabit Ethernet Network Connection

igb 0000:01:00.1: eth1: (PCIe:2.5Gb/s:Width x4) 00:26:6c:ff:b3:8d

igb 0000:01:00.1: eth1: PBA No: 82576B-001

igb 0000:01:00.1: Using MSI-X interrupts. 1 rx queue(s), 1 tx queue(s)

ixgbe: Intel(R) 10 Gigabit PCI Express Network Driver - version 3.8.21-k

ixgbe: Copyright (c) 1999-2012 Intel Corporation.

xen: registering gsi 24 triggering 0 polarity 1

xen: --> pirq=24 -> irq=24 (gsi=24)

ixgbe 0000:03:00.0: Multiqueue Disabled: Rx Queue count = 1, Tx Queue count = 1

ixgbe 0000:03:00.0: (PCI Express:5.0GT/s:Width x8) 00:8c:fa:01:84:6a

ixgbe 0000:03:00.0: MAC: 2, PHY: 1, PBA No: FFFFFF-0FF

ixgbe 0000:03:00.0: Intel(R) 10 Gigabit Network Connection

xen: registering gsi 34 triggering 0 polarity 1

xen: --> pirq=34 -> irq=34 (gsi=34)

ixgbe 0000:03:00.1: Multiqueue Disabled: Rx Queue count = 1, Tx Queue count = 1

ixgbe 0000:03:00.1: (PCI Express:5.0GT/s:Width x8) 00:8c:fa:01:84:6b

ixgbe 0000:03:00.1: MAC: 2, PHY: 1, PBA No: FFFFFF-0FF

ixgbe 0000:03:00.1: Intel(R) 10 Gigabit Network Connection

md: raid0 personality registered for level 0

md: raid1 personality registered for level 1

device-mapper: ioctl: 4.22.0-ioctl (2011-10-19) initialised: dm-devel@redhat.com

dcdbas dcdbas: Dell Systems Management Base Driver (version 5.6.0-3.2)

ip_tables: (C) 2000-2006 Netfilter Core Team

TCP: cubic registered

NET: Registered protocol family 10

NET: Registered protocol family 17
8021q: 802.1Q VLAN Support v1.8
Using IPI No-Shortcut mode
console [netcon0] enabled
netconsole: network logging started
drivers/rtc/hctosys.c: unable to open rtc device (rtc0)
BIOS EDD facility v0.16 2004-Jun-25, 0 devices found
EDD information not available.
ADDRCONF(NETDEV_UP): eth0: link is not ready
8021q: adding VLAN 0 to HW filter on device eth0
igb: eth0 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX
ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
Sending DHCP requests .., OK
IP-Config: Got DHCP answer from 10.5.5.55, my address is
IP-Config: Complete:

Freeing unused kernel memory: 356k freed

Using fallback suid method

Using fallback suid method

Using fallback suid method

Using fallback suid method

Using fallback suid method

Using fallback suid method

Using fallback suid method

Using fallback suid method

Using fallback suid method


INIT: version 2.88 booting
Using makefile-style concurrent boot in runlevel S.
.udev/ already exists on the static /dev! ...  [33m(warning). [39;49m
Starting the hotplug events dispatcher: udevd.
Synthesizing the initial hotplug events...done.
Waiting for /dev to be fully populated...input: Power Button as
/devices/LNXSYSTM:00/device:00/PNP0C0C:00/input/input0
ACPI: Power Button [PWRB]
input: Power Button as /devices/LNXSYSTM:00/LNXPWRBN:00/input/input1
ACPI: Power Button [PWRF]
rtc_cmos 00:03: RTC can wake from S4
rtc_cmos 00:03: rtc core: registered rtc_cmos as rtc0
rtc0: alarms up to one month, y3k, 114 bytes nvram
udev[1190]: renamed network interface eth3 to eth4
udevd-work[1177]: error changing net interface name eth0 to eth5:
Device or resource busy
udev[1189]: renamed network interface eth2 to eth6
udev[1178]: renamed network interface eth1 to eth7

done.
Setting preliminary keymap...done.

-- 
William

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 20 17:09:44 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Sep 2012 17: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 1TEkFe-0006eY-Ng; Thu, 20 Sep 2012 17:09:22 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wdauchy@gmail.com>) id 1TEkFd-0006eQ-1R
	for xen-devel@lists.xensource.com; Thu, 20 Sep 2012 17:09:21 +0000
Received: from [85.158.138.51:19250] by server-5.bemta-3.messagelabs.com id
	D1/1C-13133-0CD4B505; Thu, 20 Sep 2012 17:09:20 +0000
X-Env-Sender: wdauchy@gmail.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1348160953!30864025!1
X-Originating-IP: [209.85.160.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-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32086 invoked from network); 20 Sep 2012 17:09:14 -0000
Received: from mail-pb0-f43.google.com (HELO mail-pb0-f43.google.com)
	(209.85.160.43)
	by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Sep 2012 17:09:14 -0000
Received: by pbbrq2 with SMTP id rq2so7165200pbb.30
	for <xen-devel@lists.xensource.com>;
	Thu, 20 Sep 2012 10:09: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:from:date:message-id:subject:to
	:cc:content-type:content-transfer-encoding;
	bh=FSvETMzL9+biaaQfRgQwrykmqDUD0FkMOmWULU2nS+A=;
	b=fK5CGhQw+p8TD848QYQlQspUK4AHut2uADasuNdn7yj7G4qL/OJDsKI5/ubOHeYKKe
	pjPW0qaZGkK4CFRtlFBIGzeO/efNQ/GWfmsWAYR+KwwNfyaX/Nd4h6UMgpUZOndfIUym
	gpglRnjInDVUM428wO6ggGw+C0pfkJF0MvstWUIMduyQDI5NrL3dJwSFpNbj3aBnTYrJ
	4Sv2AE0Vy+u5cG+WWvdCxfQSv93J3CRwTmAeQzPa2x/OThzPnuH+iJkkSW3BECMpMHc9
	zvFg5539gUvrcZ+3m110xjBupIUfErTjhJi+n4FgPnEtbCJEKPvORk4VRxw83DZSfW4k
	VMmg==
Received: by 10.68.221.70 with SMTP id qc6mr8601684pbc.92.1348160952568; Thu,
	20 Sep 2012 10:09:12 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.68.135.42 with HTTP; Thu, 20 Sep 2012 10:08:51 -0700 (PDT)
In-Reply-To: <20120920163525.GC8912@reaktio.net>
References: <CAJ75kXZm-BqWdL2O41XkSE1VCdd4ruW=+CqDmR1b3=701RnXmw@mail.gmail.com>
	<20120918133650.GC12053@phenom.dumpdata.com>
	<CAJ75kXZEaCj4Jqs_qm46d7U-s1C2hkAONs8c5Audrw2c3X=nBA@mail.gmail.com>
	<20120920134851.GB1998@localhost.localdomain>
	<CAJ75kXZ0depUJF_h0yok-r4aL0TBGnqTpW_PKT4Q7P1_6R4X2A@mail.gmail.com>
	<20120920162337.GB8912@reaktio.net>
	<CAJ75kXaXbitBvosYp8Sv_548XbvdxU=M_NSSHTb_5d56=-n4nA@mail.gmail.com>
	<20120920163525.GC8912@reaktio.net>
From: William Dauchy <wdauchy@gmail.com>
Date: Thu, 20 Sep 2012 19:08:51 +0200
Message-ID: <CAJ75kXZnb82GnssNWxyGMHjTYiRQCRsNdPeYdEb-tsvkshpfEg@mail.gmail.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] Error getting mfn
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi Konrad,

I finally got what you asked, xen output with dom0 included. sorry for
the previous noise, there was some issues with my console redirection.

(XEN) Xen version 4.1.3 (package@) (gcc version 4.4.5 (Debian 4.4.5-8)
) Mon Sep 17 15:01:52 UTC 2012
(XEN) Latest ChangeSet: Thu Aug 09 16:47:30 2012 +0100 23334:ce7195d2b80e
(XEN) Console output is synchronous.
(XEN) Bootloader: COM32 Multiboot loader v0.2
(XEN) Command line: console=com2 debug sync_console dom0_max_vcpus=1
dom0_mem=1024M,max:1024M loglvl=all guest_loglvl=all
(XEN) Video information:
(XEN)  VGA is text mode 80x25, font 8x16
(XEN)  VBE/DDC methods: none; EDID transfer time: 1 seconds
(XEN)  EDID info not retrieved because no DDC retrieval method detected
(XEN) Disc information:
(XEN)  Found 0 MBR signatures
(XEN)  Found 0 EDD information structures
(XEN) Xen-e820 RAM map:
(XEN)  0000000000000000 - 000000000009b400 (usable)
(XEN)  000000000009b400 - 00000000000a0000 (reserved)
(XEN)  00000000000e0000 - 0000000000100000 (reserved)
(XEN)  0000000000100000 - 00000000bf730000 (usable)
(XEN)  00000000bf730000 - 00000000bf73e000 (ACPI data)
(XEN)  00000000bf73e000 - 00000000bf7a0000 (ACPI NVS)
(XEN)  00000000bf7a0000 - 00000000bf7b0000 (reserved)
(XEN)  00000000bf7bc000 - 00000000c0000000 (reserved)
(XEN)  00000000e0000000 - 00000000f0000000 (reserved)
(XEN)  00000000fee00000 - 00000000fee01000 (reserved)
(XEN)  00000000ffa00000 - 0000000100000000 (reserved)
(XEN)  0000000100000000 - 0000000c40000000 (usable)
(XEN) ACPI: RSDP 000FA6F0, 0024 (r2 ACPIAM)
(XEN) ACPI: XSDT BF730100, 006C (r1 122311 XSDT1136 20111223 MSFT       97)
(XEN) ACPI: FACP BF730290, 00F4 (r4 122311 FACP1136 20111223 MSFT       97)
(XEN) ACPI: DSDT BF730540, 48F7 (r2  5442B 5442B166      166 INTL 20051117)
(XEN) ACPI: FACS BF73E000, 0040
(XEN) ACPI: APIC BF730390, 011E (r2 122311 APIC1136 20111223 MSFT       97)
(XEN) ACPI: SPCR BF7304B0, 0050 (r1 122311 SPCR1136 20111223 MSFT       97)
(XEN) ACPI: MCFG BF730500, 003C (r1 122311 OEMMCFG  20111223 MSFT       97)
(XEN) ACPI: OEMB BF73E040, 0082 (r1 122311 OEMB1136 20111223 MSFT       97)
(XEN) ACPI: SRAT BF73A540, 0250 (r2 122311 OEMSRAT         1 INTL        1)
(XEN) ACPI: HPET BF73A790, 0038 (r1 122311 OEMHPET  20111223 MSFT       97)
(XEN) ACPI: DMAR BF73E0D0, 00D8 (r1    AMI  OEMDMAR        1 MSFT       97)
(XEN) ACPI: SSDT BF7439A0, 0363 (r1 DpgPmm    CpuPm       12 INTL 20051117)
(XEN) System RAM: 49142MB (50322220kB)
(XEN) SRAT: PXM 0 -> APIC 0 -> Node 0
(XEN) SRAT: PXM 0 -> APIC 2 -> Node 0
(XEN) SRAT: PXM 0 -> APIC 4 -> Node 0
(XEN) SRAT: PXM 0 -> APIC 16 -> Node 0
(XEN) SRAT: PXM 0 -> APIC 18 -> Node 0
(XEN) SRAT: PXM 0 -> APIC 20 -> Node 0
(XEN) SRAT: PXM 0 -> APIC 1 -> Node 0
(XEN) SRAT: PXM 0 -> APIC 3 -> Node 0
(XEN) SRAT: PXM 0 -> APIC 5 -> Node 0
(XEN) SRAT: PXM 0 -> APIC 17 -> Node 0
(XEN) SRAT: PXM 0 -> APIC 19 -> Node 0
(XEN) SRAT: PXM 0 -> APIC 21 -> Node 0
(XEN) SRAT: PXM 1 -> APIC 32 -> Node 1
(XEN) SRAT: PXM 1 -> APIC 34 -> Node 1
(XEN) SRAT: PXM 1 -> APIC 36 -> Node 1
(XEN) SRAT: PXM 1 -> APIC 48 -> Node 1
(XEN) SRAT: PXM 1 -> APIC 50 -> Node 1
(XEN) SRAT: PXM 1 -> APIC 52 -> Node 1
(XEN) SRAT: PXM 1 -> APIC 33 -> Node 1
(XEN) SRAT: PXM 1 -> APIC 35 -> Node 1
(XEN) SRAT: PXM 1 -> APIC 37 -> Node 1
(XEN) SRAT: PXM 1 -> APIC 49 -> Node 1
(XEN) SRAT: PXM 1 -> APIC 51 -> Node 1
(XEN) SRAT: PXM 1 -> APIC 53 -> Node 1
(XEN) SRAT: Node 0 PXM 0 0-a0000
(XEN) SRAT: Node 0 PXM 0 100000-c0000000
(XEN) SRAT: Node 0 PXM 0 100000000-640000000
(XEN) SRAT: Node 1 PXM 1 640000000-c40000000
(XEN) NUMA: Allocated memnodemap from c3f7b8000 - c3f7c5000
(XEN) NUMA: Using 8 for the hash shift.
(XEN) Domain heap initialised DMA width 32 bits
(XEN) found SMP MP-table at 000ff780
(XEN) DMI present.
(XEN) Using APIC driver default
(XEN) ACPI: PM-Timer IO Port: 0x808
(XEN) ACPI: ACPI SLEEP INFO: pm1x_cnt[804,0], pm1x_evt[800,0]
(XEN) ACPI:                  wakeup_vec[bf73e00c], vec_size[20]
(XEN) ACPI: Local APIC address 0xfee00000
(XEN) ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled)
(XEN) Processor #0 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x02] lapic_id[0x02] enabled)
(XEN) Processor #2 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x03] lapic_id[0x04] enabled)
(XEN) Processor #4 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x04] lapic_id[0x10] enabled)
(XEN) Processor #16 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x05] lapic_id[0x12] enabled)
(XEN) Processor #18 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x06] lapic_id[0x14] enabled)
(XEN) Processor #20 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x07] lapic_id[0x20] enabled)
(XEN) Processor #32 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x08] lapic_id[0x22] enabled)
(XEN) Processor #34 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x09] lapic_id[0x24] enabled)
(XEN) Processor #36 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x0a] lapic_id[0x30] enabled)
(XEN) Processor #48 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x0b] lapic_id[0x32] enabled)
(XEN) Processor #50 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x0c] lapic_id[0x34] enabled)
(XEN) Processor #52 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x0d] lapic_id[0x01] enabled)
(XEN) Processor #1 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x0e] lapic_id[0x03] enabled)
(XEN) Processor #3 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x0f] lapic_id[0x05] enabled)
(XEN) Processor #5 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x10] lapic_id[0x11] enabled)
(XEN) Processor #17 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x11] lapic_id[0x13] enabled)
(XEN) Processor #19 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x12] lapic_id[0x15] enabled)
(XEN) Processor #21 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x13] lapic_id[0x21] enabled)
(XEN) Processor #33 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x14] lapic_id[0x23] enabled)
(XEN) Processor #35 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x15] lapic_id[0x25] enabled)
(XEN) Processor #37 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x16] lapic_id[0x31] enabled)
(XEN) Processor #49 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x17] lapic_id[0x33] enabled)
(XEN) Processor #51 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x18] lapic_id[0x35] enabled)
(XEN) Processor #53 6:12 APIC version 21
(XEN) ACPI: LAPIC_NMI (acpi_id[0xff] dfl dfl lint[0x1])
(XEN) Overriding APIC driver with bigsmp
(XEN) ACPI: IOAPIC (id[0x06] address[0xfec00000] gsi_base[0])
(XEN) IOAPIC[0]: apic_id 6, version 32, address 0xfec00000, GSI 0-23
(XEN) ACPI: IOAPIC (id[0x07] address[0xfec8a000] gsi_base[24])
(XEN) IOAPIC[1]: apic_id 7, version 32, address 0xfec8a000, GSI 24-47
(XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
(XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
(XEN) ACPI: IRQ0 used by override.
(XEN) ACPI: IRQ2 used by override.
(XEN) ACPI: IRQ9 used by override.
(XEN) Enabling APIC mode:  Phys.  Using 2 I/O APICs
(XEN) ACPI: HPET id: 0x8086a301 base: 0xfed00000
(XEN) PCI: MCFG configuration 0: base e0000000 segment 0 buses 0 - 255
(XEN) PCI: MCFG area at e0000000 reserved in E820
(XEN) Table is not found!
(XEN) Using ACPI (MADT) for SMP configuration information
(XEN) IRQ limits: 48 GSI, 4576 MSI/MSI-X
(XEN) Using scheduler: SMP Credit Scheduler (credit)
(XEN) Detected 2266.825 MHz processor.
(XEN) Initing memory sharing.
(XEN) mce_intel.c:1162: MCA Capability: BCAST 1 SER 0 CMCI 1 firstbank
0 extended MCE MSR 0
(XEN) Intel machine check reporting enabled
(XEN) Intel VT-d supported page sizes: 4kB.
(XEN) Intel VT-d Snoop Control enabled.
(XEN) Intel VT-d Dom0 DMA Passthrough not enabled.
(XEN) Intel VT-d Queued Invalidation enabled.
(XEN) Intel VT-d Interrupt Remapping not enabled.
(XEN) Intel VT-d Shared EPT tables not enabled.
(XEN) I/O virtualisation enabled
(XEN)  - Dom0 mode: Relaxed
(XEN) Enabled directed EOI with ioapic_ack_old on!
(XEN) ENABLING IO-APIC IRQs
(XEN)  -> Using old ACK method
(XEN) ..TIMER: vector=0xF0 apic1=0 pin1=2 apic2=-1 pin2=-1
(XEN) Platform timer is 14.318MHz HPET
(XEN) Defaulting to alternative key handling; send 'A' to switch to normal mode.
(XEN) Allocated console ring of 256 KiB.
(XEN) VMX: Supported advanced features:
(XEN)  - APIC MMIO access virtualisation
(XEN)  - APIC TPR shadow
(XEN)  - Extended Page Tables (EPT)
(XEN)  - Virtual-Processor Identifiers (VPID)
(XEN)  - Virtual NMI
(XEN)  - MSR direct-access bitmap
(XEN)  - Unrestricted Guest
(XEN) HVM: ASIDs enabled.
(XEN) HVM: VMX enabled
(XEN) HVM: Hardware Assisted Paging (HAP) detected
(XEN) HVM: HAP page sizes: 4kB, 2MB, 1GB
(XEN) Brought up 24 CPUs
(XEN) ACPI sleep modes: S3
(XEN) mcheck_poll: Machine check polling timer started.
(XEN) *** LOADING DOMAIN 0 ***
(XEN)  Xen  kernel: 64-bit, lsb, compat32
(XEN)  Dom0 kernel: 32-bit, PAE, lsb, paddr 0x1000000 -> 0x17dc000
(XEN) PHYSICAL MEMORY ARRANGEMENT:
(XEN)  Dom0 alloc.:   0000000c20000000->0000000c22000000 (253212 pages
to be allocated)
(XEN)  Init. ramdisk: 0000000c3fd1c000->0000000c3ffff200
(XEN) VIRTUAL MEMORY ARRANGEMENT:
(XEN)  Loaded kernel: 00000000c1000000->00000000c17dc000
(XEN)  Init. ramdisk: 00000000c17dc000->00000000c1abf200
(XEN)  Phys-Mach map: 00000000c1ac0000->00000000c1bc0000
(XEN)  Start info:    00000000c1bc0000->00000000c1bc04b4
(XEN)  Page tables:   00000000c1bc1000->00000000c1bd7000
(XEN)  Boot stack:    00000000c1bd7000->00000000c1bd8000
(XEN)  TOTAL:         00000000c0000000->00000000c2000000
(XEN)  ENTRY ADDRESS: 00000000c14f5000
(XEN) Dom0 has maximum 1 VCPUs
(XEN) Scrubbing Free RAM:
..........................................................................................................................................................................................................................................................................................................................................................................................................................................................................................done.
(XEN) Xen trace buffers: disabled
(XEN) Std. Loglevel: All
(XEN) Guest Loglevel: All
(XEN) **********************************************
(XEN) ******* WARNING: CONSOLE OUTPUT IS SYNCHRONOUS
(XEN) ******* This option is intended to aid debugging of Xen by ensuring
(XEN) ******* that all output is synchronously delivered on the serial line.
(XEN) ******* However it can introduce SIGNIFICANT latencies and affect
(XEN) ******* timekeeping. It is NOT recommended for production use!
(XEN) **********************************************
(XEN) 3... 2... 1...
(XEN) *** Serial input -> DOM0 (type 'CTRL-a' three times to switch
input to Xen)
(XEN) Freed 212kB init memory.
mapping kernel into physical memory
Xen: setup ISA identity maps
about to get started...
(XEN) mm.c:908:d0 Error getting mfn 2009b (pfn 5555555555555555) from
L1 entry 000000002009b023 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 000000002009b023
(XEN) mm.c:908:d0 Error getting mfn 2009c (pfn 5555555555555555) from
L1 entry 000000002009c023 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 000000002009c023
(XEN) mm.c:908:d0 Error getting mfn 2009d (pfn 5555555555555555) from
L1 entry 000000002009d023 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 000000002009d023
(XEN) mm.c:908:d0 Error getting mfn 2009e (pfn 5555555555555555) from
L1 entry 000000002009e023 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 000000002009e023
(XEN) mm.c:908:d0 Error getting mfn 2009f (pfn 5555555555555555) from
L1 entry 000000002009f023 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 000000002009f023
(XEN) mm.c:908:d0 Error getting mfn c32000 (pfn 5555555555555555) from
L1 entry 8000000c32000063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c32000063
(XEN) mm.c:908:d0 Error getting mfn c32001 (pfn 5555555555555555) from
L1 entry 8000000c32001063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c32001063
(XEN) mm.c:908:d0 Error getting mfn c32002 (pfn 5555555555555555) from
L1 entry 8000000c32002063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c32002063
(XEN) mm.c:908:d0 Error getting mfn c32003 (pfn 5555555555555555) from
L1 entry 8000000c32003063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c32003063
(XEN) mm.c:908:d0 Error getting mfn c32004 (pfn 5555555555555555) from
L1 entry 8000000c32004063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c32004063
(XEN) mm.c:908:d0 Error getting mfn c32005 (pfn 5555555555555555) from
L1 entry 8000000c32005063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c32005063
(XEN) mm.c:908:d0 Error getting mfn c32006 (pfn 5555555555555555) from
L1 entry 8000000c32006063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c32006063
(XEN) mm.c:908:d0 Error getting mfn c32007 (pfn 5555555555555555) from
L1 entry 8000000c32007063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c32007063
(XEN) mm.c:908:d0 Error getting mfn c32008 (pfn 5555555555555555) from
L1 entry 8000000c32008063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c32008063
(XEN) mm.c:908:d0 Error getting mfn c32009 (pfn 5555555555555555) from
L1 entry 8000000c32009063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c32009063
(XEN) mm.c:908:d0 Error getting mfn c3200a (pfn 5555555555555555) from
L1 entry 8000000c3200a063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c3200a063
(XEN) mm.c:908:d0 Error getting mfn c3200b (pfn 5555555555555555) from
L1 entry 8000000c3200b063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c3200b063
(XEN) mm.c:908:d0 Error getting mfn c3200c (pfn 5555555555555555) from
L1 entry 8000000c3200c063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c3200c063
(XEN) mm.c:908:d0 Error getting mfn c3200d (pfn 5555555555555555) from
L1 entry 8000000c3200d063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c3200d063
(XEN) mm.c:908:d0 Error getting mfn c3200e (pfn 5555555555555555) from
L1 entry 8000000c3200e063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c3200e063
(XEN) mm.c:908:d0 Error getting mfn c3200f (pfn 5555555555555555) from
L1 entry 8000000c3200f063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c3200f063
(XEN) mm.c:908:d0 Error getting mfn c32010 (pfn 5555555555555555) from
L1 entry 8000000c32010063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c32010063
(XEN) mm.c:908:d0 Error getting mfn c32011 (pfn 5555555555555555) from
L1 entry 8000000c32011063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c32011063
(XEN) mm.c:908:d0 Error getting mfn c32012 (pfn 5555555555555555) from
L1 entry 8000000c32012063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c32012063
(XEN) mm.c:908:d0 Error getting mfn c32013 (pfn 5555555555555555) from
L1 entry 8000000c32013063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c32013063
(XEN) mm.c:908:d0 Error getting mfn c32014 (pfn 5555555555555555) from
L1 entry 8000000c32014063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c32014063
(XEN) mm.c:908:d0 Error getting mfn c32015 (pfn 5555555555555555) from
L1 entry 8000000c32015063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c32015063
(XEN) mm.c:908:d0 Error getting mfn c32016 (pfn 5555555555555555) from
L1 entry 8000000c32016063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c32016063
(XEN) mm.c:908:d0 Error getting mfn c32017 (pfn 5555555555555555) from
L1 entry 8000000c32017063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c32017063
(XEN) mm.c:908:d0 Error getting mfn c32018 (pfn 5555555555555555) from
L1 entry 8000000c32018063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c32018063
(XEN) mm.c:908:d0 Error getting mfn c32019 (pfn 5555555555555555) from
L1 entry 8000000c32019063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c32019063
(XEN) mm.c:908:d0 Error getting mfn c3201a (pfn 5555555555555555) from
L1 entry 8000000c3201a063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c3201a063
(XEN) mm.c:908:d0 Error getting mfn c3201b (pfn 5555555555555555) from
L1 entry 8000000c3201b063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c3201b063
(XEN) mm.c:908:d0 Error getting mfn c3201c (pfn 5555555555555555) from
L1 entry 8000000c3201c063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c3201c063
(XEN) mm.c:908:d0 Error getting mfn c3201d (pfn 5555555555555555) from
L1 entry 8000000c3201d063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c3201d063
(XEN) mm.c:908:d0 Error getting mfn c3201e (pfn 5555555555555555) from
L1 entry 8000000c3201e063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c3201e063
(XEN) mm.c:908:d0 Error getting mfn c3201f (pfn 5555555555555555) from
L1 entry 8000000c3201f063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c3201f063
(XEN) mm.c:908:d0 Error getting mfn c32020 (pfn 5555555555555555) from
L1 entry 8000000c32020063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c32020063
(XEN) mm.c:908:d0 Error getting mfn c32021 (pfn 5555555555555555) from
L1 entry 8000000c32021063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c32021063
(XEN) mm.c:908:d0 Error getting mfn c32022 (pfn 5555555555555555) from
L1 entry 8000000c32022063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c32022063
(XEN) mm.c:908:d0 Error getting mfn c32023 (pfn 5555555555555555) from
L1 entry 8000000c32023063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c32023063
(XEN) mm.c:908:d0 Error getting mfn c32024 (pfn 5555555555555555) from
L1 entry 8000000c32024063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c32024063
(XEN) mm.c:908:d0 Error getting mfn c32025 (pfn 5555555555555555) from
L1 entry 8000000c32025063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c32025063
(XEN) mm.c:908:d0 Error getting mfn c32026 (pfn 5555555555555555) from
L1 entry 8000000c32026063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c32026063
(XEN) mm.c:908:d0 Error getting mfn c32027 (pfn 5555555555555555) from
L1 entry 8000000c32027063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c32027063
(XEN) mm.c:908:d0 Error getting mfn c32028 (pfn 5555555555555555) from
L1 entry 8000000c32028063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c32028063
(XEN) mm.c:908:d0 Error getting mfn c32029 (pfn 5555555555555555) from
L1 entry 8000000c32029063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c32029063
(XEN) mm.c:908:d0 Error getting mfn c3202a (pfn 5555555555555555) from
L1 entry 8000000c3202a063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c3202a063
(XEN) mm.c:908:d0 Error getting mfn c3202b (pfn 5555555555555555) from
L1 entry 8000000c3202b063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c3202b063
(XEN) mm.c:908:d0 Error getting mfn c3202c (pfn 5555555555555555) from
L1 entry 8000000c3202c063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c3202c063
(XEN) mm.c:908:d0 Error getting mfn c3202d (pfn 5555555555555555) from
L1 entry 8000000c3202d063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c3202d063
(XEN) mm.c:908:d0 Error getting mfn c3202e (pfn 5555555555555555) from
L1 entry 8000000c3202e063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c3202e063
(XEN) mm.c:908:d0 Error getting mfn c3202f (pfn 5555555555555555) from
L1 entry 8000000c3202f063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c3202f063
(XEN) mm.c:908:d0 Error getting mfn c32030 (pfn 5555555555555555) from
L1 entry 8000000c32030063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c32030063
(XEN) mm.c:908:d0 Error getting mfn c32031 (pfn 5555555555555555) from
L1 entry 8000000c32031063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c32031063
(XEN) mm.c:908:d0 Error getting mfn c32032 (pfn 5555555555555555) from
L1 entry 8000000c32032063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c32032063
(XEN) mm.c:908:d0 Error getting mfn c32033 (pfn 5555555555555555) from
L1 entry 8000000c32033063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c32033063
(XEN) mm.c:908:d0 Error getting mfn c32034 (pfn 5555555555555555) from
L1 entry 8000000c32034063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c32034063
(XEN) mm.c:908:d0 Error getting mfn c32035 (pfn 5555555555555555) from
L1 entry 8000000c32035063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c32035063
(XEN) mm.c:908:d0 Error getting mfn c32036 (pfn 5555555555555555) from
L1 entry 8000000c32036063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c32036063
(XEN) mm.c:908:d0 Error getting mfn c32037 (pfn 5555555555555555) from
L1 entry 8000000c32037063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c32037063
(XEN) mm.c:908:d0 Error getting mfn c32038 (pfn 5555555555555555) from
L1 entry 8000000c32038063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c32038063
(XEN) mm.c:908:d0 Error getting mfn c32039 (pfn 5555555555555555) from
L1 entry 8000000c32039063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c32039063
(XEN) mm.c:908:d0 Error getting mfn c3203a (pfn 5555555555555555) from
L1 entry 8000000c3203a063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c3203a063
(XEN) mm.c:908:d0 Error getting mfn c3203b (pfn 5555555555555555) from
L1 entry 8000000c3203b063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c3203b063
(XEN) mm.c:908:d0 Error getting mfn c3203c (pfn 5555555555555555) from
L1 entry 8000000c3203c063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c3203c063
(XEN) mm.c:908:d0 Error getting mfn c3203d (pfn 5555555555555555) from
L1 entry 8000000c3203d063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c3203d063
(XEN) mm.c:908:d0 Error getting mfn c3203e (pfn 5555555555555555) from
L1 entry 8000000c3203e063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c3203e063
(XEN) mm.c:908:d0 Error getting mfn c3203f (pfn 5555555555555555) from
L1 entry 8000000c3203f063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c3203f063
(XEN) mm.c:908:d0 Error getting mfn c32040 (pfn 5555555555555555) from
L1 entry 8000000c32040063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c32040063
(XEN) mm.c:908:d0 Error getting mfn c32041 (pfn 5555555555555555) from
L1 entry 8000000c32041063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c32041063
(XEN) mm.c:908:d0 Error getting mfn c32042 (pfn 5555555555555555) from
L1 entry 8000000c32042063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c32042063
(XEN) mm.c:908:d0 Error getting mfn c32043 (pfn 5555555555555555) from
L1 entry 8000000c32043063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c32043063
(XEN) mm.c:908:d0 Error getting mfn c32044 (pfn 5555555555555555) from
L1 entry 8000000c32044063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c32044063
(XEN) mm.c:908:d0 Error getting mfn c32045 (pfn 5555555555555555) from
L1 entry 8000000c32045063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c32045063
(XEN) mm.c:908:d0 Error getting mfn c32046 (pfn 5555555555555555) from
L1 entry 8000000c32046063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c32046063
(XEN) mm.c:908:d0 Error getting mfn c32047 (pfn 5555555555555555) from
L1 entry 8000000c32047063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c32047063
(XEN) mm.c:908:d0 Error getting mfn c32048 (pfn 5555555555555555) from
L1 entry 8000000c32048063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c32048063
(XEN) mm.c:908:d0 Error getting mfn c32049 (pfn 5555555555555555) from
L1 entry 8000000c32049063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c32049063
(XEN) mm.c:908:d0 Error getting mfn c3204a (pfn 5555555555555555) from
L1 entry 8000000c3204a063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c3204a063
(XEN) mm.c:908:d0 Error getting mfn c3204b (pfn 5555555555555555) from
L1 entry 8000000c3204b063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c3204b063
(XEN) mm.c:908:d0 Error getting mfn c3204c (pfn 5555555555555555) from
L1 entry 8000000c3204c063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c3204c063
(XEN) mm.c:908:d0 Error getting mfn c3204d (pfn 5555555555555555) from
L1 entry 8000000c3204d063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c3204d063
(XEN) mm.c:908:d0 Error getting mfn c3204e (pfn 5555555555555555) from
L1 entry 8000000c3204e063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c3204e063
(XEN) mm.c:908:d0 Error getting mfn c3204f (pfn 5555555555555555) from
L1 entry 8000000c3204f063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c3204f063
(XEN) mm.c:908:d0 Error getting mfn c32050 (pfn 5555555555555555) from
L1 entry 8000000c32050063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c32050063
(XEN) mm.c:908:d0 Error getting mfn c32051 (pfn 5555555555555555) from
L1 entry 8000000c32051063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c32051063
(XEN) mm.c:908:d0 Error getting mfn c32052 (pfn 5555555555555555) from
L1 entry 8000000c32052063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c32052063
(XEN) mm.c:908:d0 Error getting mfn c32053 (pfn 5555555555555555) from
L1 entry 8000000c32053063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c32053063
(XEN) mm.c:908:d0 Error getting mfn c32054 (pfn 5555555555555555) from
L1 entry 8000000c32054063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c32054063
(XEN) mm.c:908:d0 Error getting mfn c32055 (pfn 5555555555555555) from
L1 entry 8000000c32055063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c32055063
(XEN) mm.c:908:d0 Error getting mfn c32056 (pfn 5555555555555555) from
L1 entry 8000000c32056063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c32056063
(XEN) mm.c:908:d0 Error getting mfn c32057 (pfn 5555555555555555) from
L1 entry 8000000c32057063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c32057063
(XEN) mm.c:908:d0 Error getting mfn c32058 (pfn 5555555555555555) from
L1 entry 8000000c32058063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c32058063
(XEN) mm.c:908:d0 Error getting mfn c32059 (pfn 5555555555555555) from
L1 entry 8000000c32059063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c32059063
(XEN) mm.c:908:d0 Error getting mfn c3205a (pfn 5555555555555555) from
L1 entry 8000000c3205a063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c3205a063
(XEN) mm.c:908:d0 Error getting mfn c3205b (pfn 5555555555555555) from
L1 entry 8000000c3205b063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c3205b063
(XEN) mm.c:908:d0 Error getting mfn c3205c (pfn 5555555555555555) from
L1 entry 8000000c3205c063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c3205c063
(XEN) mm.c:908:d0 Error getting mfn c3205d (pfn 5555555555555555) from
L1 entry 8000000c3205d063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c3205d063
(XEN) mm.c:908:d0 Error getting mfn c3205e (pfn 5555555555555555) from
L1 entry 8000000c3205e063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c3205e063
(XEN) mm.c:908:d0 Error getting mfn c3205f (pfn 5555555555555555) from
L1 entry 8000000c3205f063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c3205f063
(XEN) mm.c:908:d0 Error getting mfn c32060 (pfn 5555555555555555) from
L1 entry 8000000c32060063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c32060063
(XEN) mm.c:908:d0 Error getting mfn c32061 (pfn 5555555555555555) from
L1 entry 8000000c32061063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c32061063
(XEN) mm.c:908:d0 Error getting mfn c32062 (pfn 5555555555555555) from
L1 entry 8000000c32062063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c32062063
(XEN) mm.c:908:d0 Error getting mfn c32063 (pfn 5555555555555555) from
L1 entry 8000000c32063063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c32063063
(XEN) mm.c:908:d0 Error getting mfn c32064 (pfn 5555555555555555) from
L1 entry 8000000c32064063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c32064063
(XEN) mm.c:908:d0 Error getting mfn c32065 (pfn 5555555555555555) from
L1 entry 8000000c32065063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c32065063
(XEN) mm.c:908:d0 Error getting mfn c32066 (pfn 5555555555555555) from
L1 entry 8000000c32066063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c32066063
(XEN) mm.c:908:d0 Error getting mfn c32067 (pfn 5555555555555555) from
L1 entry 8000000c32067063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c32067063
(XEN) mm.c:908:d0 Error getting mfn c32068 (pfn 5555555555555555) from
L1 entry 8000000c32068063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c32068063
(XEN) mm.c:908:d0 Error getting mfn c32069 (pfn 5555555555555555) from
L1 entry 8000000c32069063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c32069063
(XEN) mm.c:908:d0 Error getting mfn c3206a (pfn 5555555555555555) from
L1 entry 8000000c3206a063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c3206a063
(XEN) mm.c:908:d0 Error getting mfn c3206b (pfn 5555555555555555) from
L1 entry 8000000c3206b063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c3206b063
(XEN) mm.c:908:d0 Error getting mfn c3206c (pfn 5555555555555555) from
L1 entry 8000000c3206c063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c3206c063
(XEN) mm.c:908:d0 Error getting mfn c3206d (pfn 5555555555555555) from
L1 entry 8000000c3206d063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c3206d063
(XEN) mm.c:908:d0 Error getting mfn c3206e (pfn 5555555555555555) from
L1 entry 8000000c3206e063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c3206e063
(XEN) mm.c:908:d0 Error getting mfn c3206f (pfn 5555555555555555) from
L1 entry 8000000c3206f063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c3206f063
(XEN) mm.c:908:d0 Error getting mfn c32070 (pfn 5555555555555555) from
L1 entry 8000000c32070063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c32070063
(XEN) mm.c:908:d0 Error getting mfn c32071 (pfn 5555555555555555) from
L1 entry 8000000c32071063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c32071063
(XEN) mm.c:908:d0 Error getting mfn c32072 (pfn 5555555555555555) from
L1 entry 8000000c32072063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c32072063
(XEN) mm.c:908:d0 Error getting mfn c32073 (pfn 5555555555555555) from
L1 entry 8000000c32073063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c32073063
(XEN) mm.c:908:d0 Error getting mfn c32074 (pfn 5555555555555555) from
L1 entry 8000000c32074063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c32074063
(XEN) mm.c:908:d0 Error getting mfn c32075 (pfn 5555555555555555) from
L1 entry 8000000c32075063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c32075063
(XEN) mm.c:908:d0 Error getting mfn c32076 (pfn 5555555555555555) from
L1 entry 8000000c32076063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c32076063
(XEN) mm.c:908:d0 Error getting mfn c32077 (pfn 5555555555555555) from
L1 entry 8000000c32077063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c32077063
(XEN) mm.c:908:d0 Error getting mfn c32078 (pfn 5555555555555555) from
L1 entry 8000000c32078063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c32078063
(XEN) mm.c:908:d0 Error getting mfn c32079 (pfn 5555555555555555) from
L1 entry 8000000c32079063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c32079063
(XEN) mm.c:908:d0 Error getting mfn c3207a (pfn 5555555555555555) from
L1 entry 8000000c3207a063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c3207a063
(XEN) mm.c:908:d0 Error getting mfn c3207b (pfn 5555555555555555) from
L1 entry 8000000c3207b063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c3207b063
(XEN) mm.c:908:d0 Error getting mfn c3207c (pfn 5555555555555555) from
L1 entry 8000000c3207c063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c3207c063
(XEN) mm.c:908:d0 Error getting mfn c3207d (pfn 5555555555555555) from
L1 entry 8000000c3207d063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c3207d063
(XEN) mm.c:908:d0 Error getting mfn c3207e (pfn 5555555555555555) from
L1 entry 8000000c3207e063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c3207e063
(XEN) mm.c:908:d0 Error getting mfn c3207f (pfn 5555555555555555) from
L1 entry 8000000c3207f063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c3207f063
(XEN) mm.c:908:d0 Error getting mfn c32080 (pfn 5555555555555555) from
L1 entry 8000000c32080063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c32080063
(XEN) mm.c:908:d0 Error getting mfn c32081 (pfn 5555555555555555) from
L1 entry 8000000c32081063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c32081063
(XEN) mm.c:908:d0 Error getting mfn c32082 (pfn 5555555555555555) from
L1 entry 8000000c32082063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c32082063
(XEN) mm.c:908:d0 Error getting mfn c32083 (pfn 5555555555555555) from
L1 entry 8000000c32083063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c32083063
(XEN) mm.c:908:d0 Error getting mfn c32084 (pfn 5555555555555555) from
L1 entry 8000000c32084063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c32084063
(XEN) mm.c:908:d0 Error getting mfn c32085 (pfn 5555555555555555) from
L1 entry 8000000c32085063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c32085063
(XEN) mm.c:908:d0 Error getting mfn c32086 (pfn 5555555555555555) from
L1 entry 8000000c32086063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c32086063
(XEN) mm.c:908:d0 Error getting mfn c32087 (pfn 5555555555555555) from
L1 entry 8000000c32087063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c32087063
(XEN) mm.c:908:d0 Error getting mfn c32088 (pfn 5555555555555555) from
L1 entry 8000000c32088063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c32088063
(XEN) mm.c:908:d0 Error getting mfn c32089 (pfn 5555555555555555) from
L1 entry 8000000c32089063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c32089063
(XEN) mm.c:908:d0 Error getting mfn c3208a (pfn 5555555555555555) from
L1 entry 8000000c3208a063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c3208a063
(XEN) mm.c:908:d0 Error getting mfn c3208b (pfn 5555555555555555) from
L1 entry 8000000c3208b063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c3208b063
(XEN) mm.c:908:d0 Error getting mfn c3208c (pfn 5555555555555555) from
L1 entry 8000000c3208c063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c3208c063
(XEN) mm.c:908:d0 Error getting mfn c3208d (pfn 5555555555555555) from
L1 entry 8000000c3208d063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c3208d063
(XEN) mm.c:908:d0 Error getting mfn c3208e (pfn 5555555555555555) from
L1 entry 8000000c3208e063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c3208e063
(XEN) mm.c:908:d0 Error getting mfn c3208f (pfn 5555555555555555) from
L1 entry 8000000c3208f063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c3208f063
(XEN) mm.c:908:d0 Error getting mfn c32090 (pfn 5555555555555555) from
L1 entry 8000000c32090063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c32090063
(XEN) mm.c:908:d0 Error getting mfn c32091 (pfn 5555555555555555) from
L1 entry 8000000c32091063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c32091063
(XEN) mm.c:908:d0 Error getting mfn c32092 (pfn 5555555555555555) from
L1 entry 8000000c32092063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c32092063
(XEN) mm.c:908:d0 Error getting mfn c32093 (pfn 5555555555555555) from
L1 entry 8000000c32093063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c32093063
(XEN) mm.c:908:d0 Error getting mfn c32094 (pfn 5555555555555555) from
L1 entry 8000000c32094063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c32094063
(XEN) mm.c:908:d0 Error getting mfn c32095 (pfn 5555555555555555) from
L1 entry 8000000c32095063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c32095063
(XEN) mm.c:908:d0 Error getting mfn c32096 (pfn 5555555555555555) from
L1 entry 8000000c32096063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c32096063
(XEN) mm.c:908:d0 Error getting mfn c32097 (pfn 5555555555555555) from
L1 entry 8000000c32097063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c32097063
(XEN) mm.c:908:d0 Error getting mfn c32098 (pfn 5555555555555555) from
L1 entry 8000000c32098063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c32098063
(XEN) mm.c:908:d0 Error getting mfn c32099 (pfn 5555555555555555) from
L1 entry 8000000c32099063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c32099063
(XEN) mm.c:908:d0 Error getting mfn c3209a (pfn 5555555555555555) from
L1 entry 8000000c3209a063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c3209a063
(XEN) mm.c:908:d0 Error getting mfn c3209b (pfn 5555555555555555) from
L1 entry 8000000c3209b063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c3209b063
(XEN) mm.c:908:d0 Error getting mfn c3209c (pfn 5555555555555555) from
L1 entry 8000000c3209c063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c3209c063
(XEN) mm.c:908:d0 Error getting mfn c3209d (pfn 5555555555555555) from
L1 entry 8000000c3209d063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c3209d063
(XEN) mm.c:908:d0 Error getting mfn c3209e (pfn 5555555555555555) from
L1 entry 8000000c3209e063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c3209e063
(XEN) mm.c:908:d0 Error getting mfn c3209f (pfn 5555555555555555) from
L1 entry 8000000c3209f063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c3209f063
(XEN) mm.c:908:d0 Error getting mfn c320a0 (pfn 5555555555555555) from
L1 entry 8000000c320a0063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c320a0063
(XEN) mm.c:908:d0 Error getting mfn c320a1 (pfn 5555555555555555) from
L1 entry 8000000c320a1063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c320a1063
(XEN) mm.c:908:d0 Error getting mfn c320a2 (pfn 5555555555555555) from
L1 entry 8000000c320a2063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c320a2063
(XEN) mm.c:908:d0 Error getting mfn c320a3 (pfn 5555555555555555) from
L1 entry 8000000c320a3063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c320a3063
(XEN) mm.c:908:d0 Error getting mfn c320a4 (pfn 5555555555555555) from
L1 entry 8000000c320a4063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c320a4063
(XEN) mm.c:908:d0 Error getting mfn c320a5 (pfn 5555555555555555) from
L1 entry 8000000c320a5063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c320a5063
(XEN) mm.c:908:d0 Error getting mfn c320a6 (pfn 5555555555555555) from
L1 entry 8000000c320a6063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c320a6063
(XEN) mm.c:908:d0 Error getting mfn c320a7 (pfn 5555555555555555) from
L1 entry 8000000c320a7063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c320a7063
(XEN) mm.c:908:d0 Error getting mfn c320a8 (pfn 5555555555555555) from
L1 entry 8000000c320a8063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c320a8063
(XEN) mm.c:908:d0 Error getting mfn c320a9 (pfn 5555555555555555) from
L1 entry 8000000c320a9063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c320a9063
(XEN) mm.c:908:d0 Error getting mfn c320aa (pfn 5555555555555555) from
L1 entry 8000000c320aa063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c320aa063
(XEN) mm.c:908:d0 Error getting mfn c320ab (pfn 5555555555555555) from
L1 entry 8000000c320ab063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c320ab063
(XEN) mm.c:908:d0 Error getting mfn c320ac (pfn 5555555555555555) from
L1 entry 8000000c320ac063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c320ac063
(XEN) mm.c:908:d0 Error getting mfn c320ad (pfn 5555555555555555) from
L1 entry 8000000c320ad063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c320ad063
(XEN) mm.c:908:d0 Error getting mfn c320ae (pfn 5555555555555555) from
L1 entry 8000000c320ae063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c320ae063
(XEN) mm.c:908:d0 Error getting mfn c320af (pfn 5555555555555555) from
L1 entry 8000000c320af063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c320af063
(XEN) mm.c:908:d0 Error getting mfn c320b0 (pfn 5555555555555555) from
L1 entry 8000000c320b0063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c320b0063
(XEN) mm.c:908:d0 Error getting mfn c320b1 (pfn 5555555555555555) from
L1 entry 8000000c320b1063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c320b1063
(XEN) mm.c:908:d0 Error getting mfn c320b2 (pfn 5555555555555555) from
L1 entry 8000000c320b2063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c320b2063
(XEN) mm.c:908:d0 Error getting mfn c320b3 (pfn 5555555555555555) from
L1 entry 8000000c320b3063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c320b3063
(XEN) mm.c:908:d0 Error getting mfn c320b4 (pfn 5555555555555555) from
L1 entry 8000000c320b4063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c320b4063
(XEN) mm.c:908:d0 Error getting mfn c320b5 (pfn 5555555555555555) from
L1 entry 8000000c320b5063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c320b5063
(XEN) mm.c:908:d0 Error getting mfn c320b6 (pfn 5555555555555555) from
L1 entry 8000000c320b6063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c320b6063
(XEN) mm.c:908:d0 Error getting mfn c320b7 (pfn 5555555555555555) from
L1 entry 8000000c320b7063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c320b7063
(XEN) mm.c:908:d0 Error getting mfn c320b8 (pfn 5555555555555555) from
L1 entry 8000000c320b8063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c320b8063
(XEN) mm.c:908:d0 Error getting mfn c320b9 (pfn 5555555555555555) from
L1 entry 8000000c320b9063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c320b9063
(XEN) mm.c:908:d0 Error getting mfn c320ba (pfn 5555555555555555) from
L1 entry 8000000c320ba063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c320ba063
(XEN) mm.c:908:d0 Error getting mfn c320bb (pfn 5555555555555555) from
L1 entry 8000000c320bb063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c320bb063
(XEN) mm.c:908:d0 Error getting mfn c320bc (pfn 5555555555555555) from
L1 entry 8000000c320bc063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c320bc063
(XEN) mm.c:908:d0 Error getting mfn c320bd (pfn 5555555555555555) from
L1 entry 8000000c320bd063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c320bd063
(XEN) mm.c:908:d0 Error getting mfn c320be (pfn 5555555555555555) from
L1 entry 8000000c320be063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c320be063
(XEN) mm.c:908:d0 Error getting mfn c320bf (pfn 5555555555555555) from
L1 entry 8000000c320bf063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c320bf063
(XEN) mm.c:908:d0 Error getting mfn c320c0 (pfn 5555555555555555) from
L1 entry 8000000c320c0063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c320c0063
(XEN) mm.c:908:d0 Error getting mfn c320c1 (pfn 5555555555555555) from
L1 entry 8000000c320c1063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c320c1063
(XEN) mm.c:908:d0 Error getting mfn c320c2 (pfn 5555555555555555) from
L1 entry 8000000c320c2063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c320c2063
(XEN) mm.c:908:d0 Error getting mfn c320c3 (pfn 5555555555555555) from
L1 entry 8000000c320c3063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c320c3063
(XEN) mm.c:908:d0 Error getting mfn c320c4 (pfn 5555555555555555) from
L1 entry 8000000c320c4063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c320c4063
(XEN) mm.c:908:d0 Error getting mfn c320c5 (pfn 5555555555555555) from
L1 entry 8000000c320c5063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c320c5063
(XEN) mm.c:908:d0 Error getting mfn c320c6 (pfn 5555555555555555) from
L1 entry 8000000c320c6063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c320c6063
(XEN) mm.c:908:d0 Error getting mfn c320c7 (pfn 5555555555555555) from
L1 entry 8000000c320c7063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c320c7063
(XEN) mm.c:908:d0 Error getting mfn c320c8 (pfn 5555555555555555) from
L1 entry 8000000c320c8063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c320c8063
(XEN) mm.c:908:d0 Error getting mfn c320c9 (pfn 5555555555555555) from
L1 entry 8000000c320c9063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c320c9063
(XEN) mm.c:908:d0 Error getting mfn c320ca (pfn 5555555555555555) from
L1 entry 8000000c320ca063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c320ca063
(XEN) mm.c:908:d0 Error getting mfn c320cb (pfn 5555555555555555) from
L1 entry 8000000c320cb063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c320cb063
(XEN) mm.c:908:d0 Error getting mfn c320cc (pfn 5555555555555555) from
L1 entry 8000000c320cc063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c320cc063
(XEN) mm.c:908:d0 Error getting mfn c320cd (pfn 5555555555555555) from
L1 entry 8000000c320cd063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c320cd063
(XEN) mm.c:908:d0 Error getting mfn c320ce (pfn 5555555555555555) from
L1 entry 8000000c320ce063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c320ce063
(XEN) mm.c:908:d0 Error getting mfn c320cf (pfn 5555555555555555) from
L1 entry 8000000c320cf063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c320cf063
(XEN) mm.c:908:d0 Error getting mfn c320d0 (pfn 5555555555555555) from
L1 entry 8000000c320d0063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c320d0063
(XEN) mm.c:908:d0 Error getting mfn c320d1 (pfn 5555555555555555) from
L1 entry 8000000c320d1063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c320d1063
(XEN) mm.c:908:d0 Error getting mfn c320d2 (pfn 5555555555555555) from
L1 entry 8000000c320d2063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c320d2063
(XEN) mm.c:908:d0 Error getting mfn c320d3 (pfn 5555555555555555) from
L1 entry 8000000c320d3063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c320d3063
(XEN) mm.c:908:d0 Error getting mfn c320d4 (pfn 5555555555555555) from
L1 entry 8000000c320d4063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c320d4063
(XEN) mm.c:908:d0 Error getting mfn c320d5 (pfn 5555555555555555) from
L1 entry 8000000c320d5063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c320d5063
(XEN) mm.c:908:d0 Error getting mfn c320d6 (pfn 5555555555555555) from
L1 entry 8000000c320d6063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c320d6063
(XEN) mm.c:908:d0 Error getting mfn c320d7 (pfn 5555555555555555) from
L1 entry 8000000c320d7063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c320d7063
(XEN) mm.c:908:d0 Error getting mfn c320d8 (pfn 5555555555555555) from
L1 entry 8000000c320d8063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c320d8063
(XEN) mm.c:908:d0 Error getting mfn c320d9 (pfn 5555555555555555) from
L1 entry 8000000c320d9063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c320d9063
(XEN) mm.c:908:d0 Error getting mfn c320da (pfn 5555555555555555) from
L1 entry 8000000c320da063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c320da063
(XEN) mm.c:908:d0 Error getting mfn c320db (pfn 5555555555555555) from
L1 entry 8000000c320db063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c320db063
(XEN) mm.c:908:d0 Error getting mfn c320dc (pfn 5555555555555555) from
L1 entry 8000000c320dc063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c320dc063
(XEN) mm.c:908:d0 Error getting mfn c320dd (pfn 5555555555555555) from
L1 entry 8000000c320dd063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c320dd063
(XEN) mm.c:908:d0 Error getting mfn c320de (pfn 5555555555555555) from
L1 entry 8000000c320de063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c320de063
(XEN) mm.c:908:d0 Error getting mfn c320df (pfn 5555555555555555) from
L1 entry 8000000c320df063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c320df063
(XEN) mm.c:908:d0 Error getting mfn c320e0 (pfn 5555555555555555) from
L1 entry 8000000c320e0063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c320e0063
(XEN) mm.c:908:d0 Error getting mfn c320e1 (pfn 5555555555555555) from
L1 entry 8000000c320e1063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c320e1063
(XEN) mm.c:908:d0 Error getting mfn c320e2 (pfn 5555555555555555) from
L1 entry 8000000c320e2063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c320e2063
(XEN) mm.c:908:d0 Error getting mfn c320e3 (pfn 5555555555555555) from
L1 entry 8000000c320e3063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c320e3063
(XEN) mm.c:908:d0 Error getting mfn c320e4 (pfn 5555555555555555) from
L1 entry 8000000c320e4063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c320e4063
(XEN) mm.c:908:d0 Error getting mfn c320e5 (pfn 5555555555555555) from
L1 entry 8000000c320e5063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c320e5063
(XEN) mm.c:908:d0 Error getting mfn c320e6 (pfn 5555555555555555) from
L1 entry 8000000c320e6063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c320e6063
(XEN) mm.c:908:d0 Error getting mfn c320e7 (pfn 5555555555555555) from
L1 entry 8000000c320e7063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c320e7063
(XEN) mm.c:908:d0 Error getting mfn c320e8 (pfn 5555555555555555) from
L1 entry 8000000c320e8063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c320e8063
(XEN) mm.c:908:d0 Error getting mfn c320e9 (pfn 5555555555555555) from
L1 entry 8000000c320e9063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c320e9063
(XEN) mm.c:908:d0 Error getting mfn c320ea (pfn 5555555555555555) from
L1 entry 8000000c320ea063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c320ea063
(XEN) mm.c:908:d0 Error getting mfn c320eb (pfn 5555555555555555) from
L1 entry 8000000c320eb063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c320eb063
(XEN) mm.c:908:d0 Error getting mfn c320ec (pfn 5555555555555555) from
L1 entry 8000000c320ec063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c320ec063
(XEN) mm.c:908:d0 Error getting mfn c320ed (pfn 5555555555555555) from
L1 entry 8000000c320ed063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c320ed063
(XEN) mm.c:908:d0 Error getting mfn c320ee (pfn 5555555555555555) from
L1 entry 8000000c320ee063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c320ee063
(XEN) mm.c:908:d0 Error getting mfn c320ef (pfn 5555555555555555) from
L1 entry 8000000c320ef063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c320ef063
(XEN) mm.c:908:d0 Error getting mfn c320f0 (pfn 5555555555555555) from
L1 entry 8000000c320f0063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c320f0063
(XEN) mm.c:908:d0 Error getting mfn c320f1 (pfn 5555555555555555) from
L1 entry 8000000c320f1063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c320f1063
(XEN) mm.c:908:d0 Error getting mfn c320f2 (pfn 5555555555555555) from
L1 entry 8000000c320f2063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c320f2063
(XEN) mm.c:908:d0 Error getting mfn c320f3 (pfn 5555555555555555) from
L1 entry 8000000c320f3063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c320f3063
(XEN) mm.c:908:d0 Error getting mfn c320f4 (pfn 5555555555555555) from
L1 entry 8000000c320f4063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c320f4063
(XEN) mm.c:908:d0 Error getting mfn c320f5 (pfn 5555555555555555) from
L1 entry 8000000c320f5063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c320f5063
(XEN) mm.c:908:d0 Error getting mfn c320f6 (pfn 5555555555555555) from
L1 entry 8000000c320f6063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c320f6063
(XEN) mm.c:908:d0 Error getting mfn c320f7 (pfn 5555555555555555) from
L1 entry 8000000c320f7063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c320f7063
(XEN) mm.c:908:d0 Error getting mfn c320f8 (pfn 5555555555555555) from
L1 entry 8000000c320f8063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c320f8063
(XEN) mm.c:908:d0 Error getting mfn c320f9 (pfn 5555555555555555) from
L1 entry 8000000c320f9063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c320f9063
(XEN) mm.c:908:d0 Error getting mfn c320fa (pfn 5555555555555555) from
L1 entry 8000000c320fa063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c320fa063
(XEN) mm.c:908:d0 Error getting mfn c320fb (pfn 5555555555555555) from
L1 entry 8000000c320fb063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c320fb063
(XEN) mm.c:908:d0 Error getting mfn c320fc (pfn 5555555555555555) from
L1 entry 8000000c320fc063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c320fc063
(XEN) mm.c:908:d0 Error getting mfn c320fd (pfn 5555555555555555) from
L1 entry 8000000c320fd063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c320fd063
(XEN) mm.c:908:d0 Error getting mfn c320fe (pfn 5555555555555555) from
L1 entry 8000000c320fe063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c320fe063
(XEN) mm.c:908:d0 Error getting mfn c320ff (pfn 5555555555555555) from
L1 entry 8000000c320ff063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c320ff063
(XEN) mm.c:908:d0 Error getting mfn c32110 (pfn 5555555555555555) from
L1 entry 8000000c32110063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c32110063
(XEN) mm.c:908:d0 Error getting mfn c32111 (pfn 5555555555555555) from
L1 entry 8000000c32111063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c32111063
(XEN) mm.c:908:d0 Error getting mfn c32112 (pfn 5555555555555555) from
L1 entry 8000000c32112063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c32112063
(XEN) mm.c:908:d0 Error getting mfn c32113 (pfn 5555555555555555) from
L1 entry 8000000c32113063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c32113063
(XEN) mm.c:908:d0 Error getting mfn c32114 (pfn 5555555555555555) from
L1 entry 8000000c32114063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c32114063
(XEN) mm.c:908:d0 Error getting mfn c32115 (pfn 5555555555555555) from
L1 entry 8000000c32115063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c32115063
(XEN) mm.c:908:d0 Error getting mfn c32116 (pfn 5555555555555555) from
L1 entry 8000000c32116063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c32116063
(XEN) mm.c:908:d0 Error getting mfn c32117 (pfn 5555555555555555) from
L1 entry 8000000c32117063 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 8000000c32117063
Reserving virtual address space above 0xfcc00000
Linux version 3.4.11 (package@squeeze64) (gcc version 4.4.5 (Debian
4.4.5-8) ) #16 SMP Wed Sep 19 13:42:38 UTC 2012
KERNEL supported cpus:

  Intel GenuineIntel

Freeing  9b-100 pfn range: 101 pages freed

1-1 mapping on 9b->100

1-1 mapping on bf730->100000

Released 101 pages of unused memory

Set 264501 page(s) to 1-1 mapping

BIOS-provided physical RAM map:

 Xen: 0000000000000000 - 000000000009b000 (usable)

 Xen: 000000000009b400 - 0000000000100000 (reserved)

 Xen: 0000000000100000 - 0000000040065000 (usable)

 Xen: 0000000040065000 - 00000000bf730000 (unusable)

 Xen: 00000000bf730000 - 00000000bf73e000 (ACPI data)

 Xen: 00000000bf73e000 - 00000000bf7a0000 (ACPI NVS)

 Xen: 00000000bf7a0000 - 00000000bf7b0000 (reserved)

 Xen: 00000000bf7bc000 - 00000000c0000000 (reserved)

 Xen: 00000000e0000000 - 00000000f0000000 (reserved)

 Xen: 00000000fec00000 - 00000000fec01000 (reserved)

 Xen: 00000000fec8a000 - 00000000fec8b000 (reserved)

 Xen: 00000000fee00000 - 00000000fee01000 (reserved)

 Xen: 00000000ffa00000 - 0000000100000000 (reserved)

 Xen: 0000000100000000 - 0000000c40000000 (unusable)

NX (Execute Disable) protection: active

DMI present.

DMI: Dell       C6100           /0D61XP, BIOS 1.66 12/23/2011

e820 update range: 0000000000000000 - 0000000000010000 (usable) ==> (reserved)

e820 remove range: 00000000000a0000 - 0000000000100000 (usable)

last_pfn = 0x40065 max_arch_pfn = 0x1000000

initial memory mapped : 0 - 027ff000

Base memory trampoline at [c009a000] 9a000 size 4096

init_memory_mapping: 0000000000000000-00000000345fe000

 0000000000 - 00345fe000 page 4k

kernel direct mapping tables up to 345fe000 @ 2658000-27ff000

xen: setting RW the range 27e9000 - 27ff000

RAMDISK: 017dc000 - 01ac0000

ACPI: RSDP 000fa6f0 00024 (v02 ACPIAM)
ACPI: XSDT bf730100 0006C (v01 122311 XSDT1136 20111223 MSFT 00000097)
ACPI: FACP bf730290 000F4 (v04 122311 FACP1136 20111223 MSFT 00000097)
ACPI: DSDT bf730540 048F7 (v02  5442B 5442B166 00000166 INTL 20051117)
ACPI: FACS bf73e000 00040
ACPI: APIC bf730390 0011E (v02 122311 APIC1136 20111223 MSFT 00000097)
ACPI: SPCR bf7304b0 00050 (v01 122311 SPCR1136 20111223 MSFT 00000097)
ACPI: MCFG bf730500 0003C (v01 122311 OEMMCFG  20111223 MSFT 00000097)
ACPI: OEMB bf73e040 00082 (v01 122311 OEMB1136 20111223 MSFT 00000097)
ACPI: SRAT bf73a540 00250 (v02 122311 OEMSRAT  00000001 INTL 00000001)
ACPI: HPET bf73a790 00038 (v01 122311 OEMHPET  20111223 MSFT 00000097)
ACPI: XMAR bf73e0d0 000D8 (v01    AMI  OEMDMAR 00000001 MSFT 00000097)
ACPI: SSDT bf7439a0 00363 (v01 DpgPmm    CpuPm 00000012 INTL 20051117)
ACPI: Local APIC address 0xfee00000

No NUMA configuration found
Faking a node at 0000000000000000-0000000040065000
node 0 pfn: [0 - 40065]
remap_alloc: node 0 [3fe00000-40000000) -> [f4200000-f4400000)
Initmem setup node 0 0000000000000000-0000000040065000
  NODE_DATA [0000000034200000 - 0000000034201fff] (remapped)
186MB HIGHMEM available.
837MB LOWMEM available.

max_low_pfn = 345fe, highstart_pfn = 345fe
Low memory ends at vaddr f45fe000
High memory starts at vaddr f45fe000
  mapped low ram: 0 - 345fe000
  low ram: 0 - 345fe000
Zone PFN ranges:

  DMA      0x00000010 -> 0x00001000

  Normal   0x00001000 -> 0x000345fe

  HighMem  0x000345fe -> 0x00040065

Movable zone start PFN for each node

Early memory PFN ranges

    0: 0x00000010 -> 0x0000009b

    0: 0x00000100 -> 0x00040065

On node 0 totalpages: 262128

  DMA zone: 32 pages used for memmap

  DMA zone: 0 pages reserved

  DMA zone: 3947 pages, LIFO batch:0

  Normal zone: 1644 pages used for memmap

  Normal zone: 208786 pages, LIFO batch:31

  HighMem zone: 373 pages used for memmap

  HighMem zone: 47346 pages, LIFO batch:15

Using APIC driver default

ACPI: PM-Timer IO Port: 0x808

ACPI: Local APIC address 0xfee00000

ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled)

ACPI: LAPIC (acpi_id[0x02] lapic_id[0x02] enabled)

ACPI: LAPIC (acpi_id[0x03] lapic_id[0x04] enabled)

ACPI: LAPIC (acpi_id[0x04] lapic_id[0x10] enabled)

ACPI: LAPIC (acpi_id[0x05] lapic_id[0x12] enabled)

ACPI: LAPIC (acpi_id[0x06] lapic_id[0x14] enabled)

ACPI: LAPIC (acpi_id[0x07] lapic_id[0x20] enabled)

ACPI: LAPIC (acpi_id[0x08] lapic_id[0x22] enabled)

ACPI: LAPIC (acpi_id[0x09] lapic_id[0x24] enabled)

ACPI: LAPIC (acpi_id[0x0a] lapic_id[0x30] enabled)

ACPI: LAPIC (acpi_id[0x0b] lapic_id[0x32] enabled)

ACPI: LAPIC (acpi_id[0x0c] lapic_id[0x34] enabled)

ACPI: LAPIC (acpi_id[0x0d] lapic_id[0x01] enabled)

ACPI: LAPIC (acpi_id[0x0e] lapic_id[0x03] enabled)

ACPI: LAPIC (acpi_id[0x0f] lapic_id[0x05] enabled)

ACPI: LAPIC (acpi_id[0x10] lapic_id[0x11] enabled)

ACPI: LAPIC (acpi_id[0x11] lapic_id[0x13] enabled)

ACPI: LAPIC (acpi_id[0x12] lapic_id[0x15] enabled)

ACPI: LAPIC (acpi_id[0x13] lapic_id[0x21] enabled)

ACPI: LAPIC (acpi_id[0x14] lapic_id[0x23] enabled)

ACPI: LAPIC (acpi_id[0x15] lapic_id[0x25] enabled)

ACPI: LAPIC (acpi_id[0x16] lapic_id[0x31] enabled)

ACPI: LAPIC (acpi_id[0x17] lapic_id[0x33] enabled)

ACPI: LAPIC (acpi_id[0x18] lapic_id[0x35] enabled)

ACPI: LAPIC_NMI (acpi_id[0xff] dfl dfl lint[0x1])

ACPI: IOAPIC (id[0x06] address[0xfec00000] gsi_base[0])

IOAPIC[0]: apic_id 6, version 253, address 0xfec00000, GSI 0-253

ACPI: IOAPIC (id[0x07] address[0xfec8a000] gsi_base[24])

IOAPIC[1]: apic_id 7, version 253, address 0xfec8a000, GSI 24-277

ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)

ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)

ACPI: IRQ0 used by override.

ACPI: IRQ2 used by override.

ACPI: IRQ9 used by override.

Using ACPI (MADT) for SMP configuration information

ACPI: HPET id: 0x8086a301 base: 0xfed00000

SMP: Allowing 24 CPUs, 0 hotplug CPUs

nr_irqs_gsi: 294

Allocating PCI resources starting at c0000000 (gap: c0000000:20000000)

Booting paravirtualized kernel on Xen

Xen version: 4.1.3 (preserve-AD)

setup_percpu: NR_CPUS:32 nr_cpumask_bits:32 nr_cpu_ids:24 nr_node_ids:1

PERCPU: Embedded 12 pages/cpu @f44b6000 s27072 r0 d22080 u49152

pcpu-alloc: s27072 r0 d22080 u49152 alloc=12*4096

pcpu-alloc: [0] 00 [0] 01 [0] 02 [0] 03 [0] 04 [0] 05 [0] 06 [0] 07

pcpu-alloc: [0] 08 [0] 09 [0] 10 [0] 11 [0] 12 [0] 13 [0] 14 [0] 15

pcpu-alloc: [0] 16 [0] 17 [0] 18 [0] 19 [0] 20 [0] 21 [0] 22 [0] 23

Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 260079

Policy zone: HighMem

Kernel command line: root=/dev/nfs ip=:::::eth0:dhcp nfsroot=
loglvl=all verbose=y console=hvc0 debug loglevel=8

PID hash table entries: 4096 (order: 2, 16384 bytes)

Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)

Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)

Initializing CPU#0

Placing 64MB software IO TLB between ef5c0000 - f35c0000

software IO TLB at phys 0x2f5c0000 - 0x335c0000

Initializing HighMem for node 0 (000345fe:00040065)

Memory: 952272k/1048980k available (3657k kernel code, 93788k
reserved, 1416k data, 356k init, 188424k highmem)

virtual kernel memory layout:

    fixmap  : 0xfc936000 - 0xfcbff000   (2852 kB)

    pkmap   : 0xfc600000 - 0xfc800000   (2048 kB)

    vmalloc : 0xf4dfe000 - 0xfc5fe000   ( 120 MB)

    lowmem  : 0xc0000000 - 0xf45fe000   ( 837 MB)

      .init : 0xc14f5000 - 0xc154e000   ( 356 kB)

      .data : 0xc1392789 - 0xc14f4940   (1416 kB)

      .text : 0xc1000000 - 0xc1392789   (3657 kB)

Hierarchical RCU implementation.

	Additional per-CPU info printed with stalls.

NR_IRQS:2304 nr_irqs:256 16

CPU 0 irqstacks, hard=ef008000 soft=ef00a000

xen: sci override: global_irq=9 trigger=0 polarity=0
xen: registering gsi 9 triggering 0 polarity 0
xen: --> pirq=9 -> irq=9 (gsi=9)
xen: acpi sci 9
xen: --> pirq=1 -> irq=1 (gsi=1)
xen: --> pirq=2 -> irq=2 (gsi=2)
xen: --> pirq=3 -> irq=3 (gsi=3)
xen: --> pirq=4 -> irq=4 (gsi=4)
xen: --> pirq=5 -> irq=5 (gsi=5)
xen: --> pirq=6 -> irq=6 (gsi=6)
xen: --> pirq=7 -> irq=7 (gsi=7)
xen: --> pirq=8 -> irq=8 (gsi=8)
xen: --> pirq=10 -> irq=10 (gsi=10)
xen: --> pirq=11 -> irq=11 (gsi=11)
xen: --> pirq=12 -> irq=12 (gsi=12)
xen: --> pirq=13 -> irq=13 (gsi=13)
xen: --> pirq=14 -> irq=14 (gsi=14)
xen: --> pirq=15 -> irq=15 (gsi=15)

Console: colour VGA+ 80x25

console [hvc0] enabled

Xen: using vcpuop timer interface

installing Xen timer for CPU 0

Detected 2266.824 MHz processor.

Calibrating delay loop (skipped), value calculated using timer
frequency.. 4533.64 BogoMIPS (lpj=9067296)

pid_max: default: 32768 minimum: 301

Mount-cache hash table entries: 512

CPU: Physical Processor ID: 0

CPU: Processor Core ID: 0

ENERGY_PERF_BIAS: Set to 'normal', was 'performance'

ENERGY_PERF_BIAS: View and update with x86_energy_perf_policy(8)

SMP alternatives: switching to UP code

Freeing SMP alternatives: 20k freed

ACPI: Core revision 20120320

Performance Events: unsupported p6 CPU model 44 no PMU driver,
software events only.

Brought up 1 CPUs

Grant tables using version 2 layout.

Grant table initialized

NET: Registered protocol family 16

ACPI: bus type pci registered

dca service started, version 1.12.1

PCI: MMCONFIG for domain 0000 [bus 00-ff] at [mem
0xe0000000-0xefffffff] (base 0xe0000000)

PCI: MMCONFIG at [mem 0xe0000000-0xefffffff] reserved in E820

PCI: Using MMCONFIG for extended config space

PCI: Using configuration type 1 for base access

bio: create slab <bio-0> at 0

ACPI: Added _OSI(Module Device)

ACPI: Added _OSI(Processor Device)

ACPI: Added _OSI(3.0 _SCP Extensions)

ACPI: Added _OSI(Processor Aggregator Device)

ACPI: EC: Look up EC in DSDT

\_SB_:_OSC invalid UUID

_OSC request data:1 6

ACPI: Executed 2 blocks of module-level executable AML code

ACPI: SSDT bf73e1b0 0414C (v01 DpgPmm  P001Ist 00000011 INTL 20051117)

ACPI: Dynamic OEM Table Load:

ACPI: SSDT   (null) 0414C (v01 DpgPmm  P001Ist 00000011 INTL 20051117)

ACPI: SSDT bf742300 00C88 (v01  PmRef  P001Cst 00003001 INTL 20051117)

ACPI: Dynamic OEM Table Load:

ACPI: SSDT   (null) 00C88 (v01  PmRef  P001Cst 00003001 INTL 20051117)

ACPI: SSDT bf742f90 00A0A (v01  PmRef  Cpu0Tst 00003000 INTL 20051117)

ACPI: Dynamic OEM Table Load:

ACPI: SSDT   (null) 00A0A (v01  PmRef  Cpu0Tst 00003000 INTL 20051117)

ACPI: Interpreter enabled

ACPI: (supports S0 S5)

ACPI: Using IOAPIC for interrupt routing

PCI: Using host bridge windows from ACPI; if necessary, use
"pci=nocrs" and report a bug

ACPI: PCI Root Bridge [PCI0] (domain 0000 [bus 00-ff])

pci_root PNP0A08:00: host bridge window [io  0x0000-0x03af]

pci_root PNP0A08:00: host bridge window [io  0x03e0-0x0cf7]

pci_root PNP0A08:00: host bridge window [io  0x03b0-0x03bb]

pci_root PNP0A08:00: host bridge window [io  0x03c0-0x03df]

pci_root PNP0A08:00: host bridge window [io  0x0d00-0xffff]

pci_root PNP0A08:00: host bridge window [mem 0x000a0000-0x000bffff]

pci_root PNP0A08:00: host bridge window [mem 0x000d0000-0x000dffff]

pci_root PNP0A08:00: host bridge window [mem 0xc0000000-0xdfffffff]

pci_root PNP0A08:00: host bridge window [mem 0xf0000000-0xfed8ffff]

PCI host bridge to bus 0000:00

pci_bus 0000:00: root bus resource [io  0x0000-0x03af]

pci_bus 0000:00: root bus resource [io  0x03e0-0x0cf7]

pci_bus 0000:00: root bus resource [io  0x03b0-0x03bb]

pci_bus 0000:00: root bus resource [io  0x03c0-0x03df]

pci_bus 0000:00: root bus resource [io  0x0d00-0xffff]

pci_bus 0000:00: root bus resource [mem 0x000a0000-0x000bffff]

pci_bus 0000:00: root bus resource [mem 0x000d0000-0x000dffff]

pci_bus 0000:00: root bus resource [mem 0xc0000000-0xdfffffff]

pci_bus 0000:00: root bus resource [mem 0xf0000000-0xfed8ffff]

pci 0000:00:00.0: [8086:3406] type 00 class 0x060000

pci 0000:00:00.0: PME# supported from D0 D3hot D3cold

pci 0000:00:01.0: [8086:3408] type 01 class 0x060400

pci 0000:00:01.0: PME# supported from D0 D3hot D3cold

pci 0000:00:03.0: [8086:340a] type 01 class 0x060400

pci 0000:00:03.0: PME# supported from D0 D3hot D3cold

pci 0000:00:05.0: [8086:340c] type 01 class 0x060400

pci 0000:00:05.0: PME# supported from D0 D3hot D3cold

pci 0000:00:07.0: [8086:340e] type 01 class 0x060400

pci 0000:00:07.0: PME# supported from D0 D3hot D3cold

pci 0000:00:13.0: [8086:342d] type 00 class 0x080020

pci 0000:00:13.0: reg 10: [mem 0xfec8a000-0xfec8afff]

pci 0000:00:13.0: PME# supported from D0 D3hot D3cold

pci 0000:00:14.0: [8086:342e] type 00 class 0x080000

pci 0000:00:14.1: [8086:3422] type 00 class 0x080000

pci 0000:00:14.2: [8086:3423] type 00 class 0x080000

pci 0000:00:14.3: [8086:3438] type 00 class 0x080000

pci 0000:00:16.0: [8086:3430] type 00 class 0x088000

pci 0000:00:16.0: reg 10: [mem 0xfbef8000-0xfbefbfff 64bit]

pci 0000:00:16.1: [8086:3431] type 00 class 0x088000

pci 0000:00:16.1: reg 10: [mem 0xfbef4000-0xfbef7fff 64bit]

pci 0000:00:16.2: [8086:3432] type 00 class 0x088000

pci 0000:00:16.2: reg 10: [mem 0xfbef0000-0xfbef3fff 64bit]

pci 0000:00:16.3: [8086:3433] type 00 class 0x088000

pci 0000:00:16.3: reg 10: [mem 0xfbeec000-0xfbeeffff 64bit]

pci 0000:00:16.4: [8086:3429] type 00 class 0x088000

pci 0000:00:16.4: reg 10: [mem 0xfbee8000-0xfbeebfff 64bit]

pci 0000:00:16.5: [8086:342a] type 00 class 0x088000

pci 0000:00:16.5: reg 10: [mem 0xfbee4000-0xfbee7fff 64bit]

pci 0000:00:16.6: [8086:342b] type 00 class 0x088000

pci 0000:00:16.6: reg 10: [mem 0xfbee0000-0xfbee3fff 64bit]

pci 0000:00:16.7: [8086:342c] type 00 class 0x088000

pci 0000:00:16.7: reg 10: [mem 0xfbedc000-0xfbedffff 64bit]

pci 0000:00:1d.0: [8086:3a34] type 00 class 0x0c0300

pci 0000:00:1d.0: reg 20: [io  0xbc00-0xbc1f]

pci 0000:00:1d.1: [8086:3a35] type 00 class 0x0c0300

pci 0000:00:1d.1: reg 20: [io  0xb880-0xb89f]

pci 0000:00:1d.2: [8086:3a36] type 00 class 0x0c0300

pci 0000:00:1d.2: reg 20: [io  0xb800-0xb81f]

pci 0000:00:1d.7: [8086:3a3a] type 00 class 0x0c0320

pci 0000:00:1d.7: reg 10: [mem 0xfbeda000-0xfbeda3ff]

pci 0000:00:1d.7: PME# supported from D0 D3hot D3cold

pci 0000:00:1e.0: [8086:244e] type 01 class 0x060401

pci 0000:00:1f.0: [8086:3a16] type 00 class 0x060100

pci 0000:00:1f.0: ICH7 LPC Generic IO decode 2 PIO at 0ca0 (mask 000f)

pci 0000:00:1f.2: [8086:3a22] type 00 class 0x010601

pci 0000:00:1f.2: reg 10: [io  0xac00-0xac07]

pci 0000:00:1f.2: reg 14: [io  0xb480-0xb483]

pci 0000:00:1f.2: reg 18: [io  0xb400-0xb407]

pci 0000:00:1f.2: reg 1c: [io  0xb080-0xb083]

pci 0000:00:1f.2: reg 20: [io  0xb000-0xb01f]

pci 0000:00:1f.2: reg 24: [mem 0xfbed8000-0xfbed87ff]

pci 0000:00:1f.2: PME# supported from D3hot

pci 0000:00:1f.3: [8086:3a30] type 00 class 0x0c0500

pci 0000:00:1f.3: reg 10: [mem 0xfbed6000-0xfbed60ff 64bit]

pci 0000:00:1f.3: reg 20: [io  0x0400-0x041f]

pci 0000:01:00.0: [8086:10c9] type 00 class 0x020000

pci 0000:01:00.0: reg 10: [mem 0xfbce0000-0xfbcfffff]

pci 0000:01:00.0: reg 14: [mem 0xfbcc0000-0xfbcdffff]

pci 0000:01:00.0: reg 18: [io  0xcc00-0xcc1f]

pci 0000:01:00.0: reg 1c: [mem 0xfbc9c000-0xfbc9ffff]

pci 0000:01:00.0: reg 30: [mem 0xfbca0000-0xfbcbffff pref]

pci 0000:01:00.0: PME# supported from D0 D3hot D3cold

pci 0000:01:00.1: [8086:10c9] type 00 class 0x020000

pci 0000:01:00.1: reg 10: [mem 0xfbc20000-0xfbc3ffff]

pci 0000:01:00.1: reg 14: [mem 0xfbc00000-0xfbc1ffff]

pci 0000:01:00.1: reg 18: [io  0xc880-0xc89f]

pci 0000:01:00.1: reg 1c: [mem 0xfbbdc000-0xfbbdffff]

pci 0000:01:00.1: reg 30: [mem 0xfbbe0000-0xfbbfffff pref]

pci 0000:01:00.1: PME# supported from D0 D3hot D3cold

pci 0000:00:01.0: PCI bridge to [bus 01-02]

pci 0000:00:01.0:   bridge window [io  0xc000-0xcfff]

pci 0000:00:01.0:   bridge window [mem 0xfbb00000-0xfbcfffff]

pci 0000:03:00.0: [8086:10fb] type 00 class 0x020000

pci 0000:03:00.0: reg 10: [mem 0xfbdc0000-0xfbdfffff 64bit]

pci 0000:03:00.0: reg 18: [io  0xdc00-0xdc1f]

pci 0000:03:00.0: reg 20: [mem 0xfbd9c000-0xfbd9ffff 64bit]

pci 0000:03:00.0: reg 30: [mem 0xfbda0000-0xfbdbffff pref]

pci 0000:03:00.0: PME# supported from D0 D3hot

pci 0000:03:00.1: [8086:10fb] type 00 class 0x020000

pci 0000:03:00.1: reg 10: [mem 0xfbd40000-0xfbd7ffff 64bit]

pci 0000:03:00.1: reg 18: [io  0xd880-0xd89f]

pci 0000:03:00.1: reg 20: [mem 0xfbd1c000-0xfbd1ffff 64bit]

pci 0000:03:00.1: reg 30: [mem 0xfbd20000-0xfbd3ffff pref]

pci 0000:03:00.1: PME# supported from D0 D3hot

pci 0000:00:03.0: PCI bridge to [bus 03-04]

pci 0000:00:03.0:   bridge window [io  0xd000-0xdfff]

pci 0000:00:03.0:   bridge window [mem 0xfbd00000-0xfbdfffff]

pci 0000:00:03.0:   bridge window [mem 0xf9c00000-0xf9ffffff 64bit pref]

pci 0000:00:05.0: PCI bridge to [bus 05-05]

pci 0000:00:07.0: PCI bridge to [bus 06-06]

pci 0000:07:04.0: [1a03:2000] type 00 class 0x030000

pci 0000:07:04.0: reg 10: [mem 0xfb000000-0xfb7fffff]

pci 0000:07:04.0: reg 14: [mem 0xfafe0000-0xfaffffff]

pci 0000:07:04.0: reg 18: [io  0xec00-0xec7f]

pci 0000:07:04.0: supports D1 D2

pci 0000:07:04.0: PME# supported from D0 D1 D2 D3hot D3cold

pci 0000:00:1e.0: PCI bridge to [bus 07-07] (subtractive decode)

pci 0000:00:1e.0:   bridge window [io  0xe000-0xefff]

pci 0000:00:1e.0:   bridge window [mem 0xfaf00000-0xfb7fffff]

pci 0000:00:1e.0:   bridge window [io  0x0000-0x03af] (subtractive decode)

pci 0000:00:1e.0:   bridge window [io  0x03e0-0x0cf7] (subtractive decode)

pci 0000:00:1e.0:   bridge window [io  0x03b0-0x03bb] (subtractive decode)

pci 0000:00:1e.0:   bridge window [io  0x03c0-0x03df] (subtractive decode)

pci 0000:00:1e.0:   bridge window [io  0x0d00-0xffff] (subtractive decode)

pci 0000:00:1e.0:   bridge window [mem 0x000a0000-0x000bffff]
(subtractive decode)

pci 0000:00:1e.0:   bridge window [mem 0x000d0000-0x000dffff]
(subtractive decode)

pci 0000:00:1e.0:   bridge window [mem 0xc0000000-0xdfffffff]
(subtractive decode)

pci 0000:00:1e.0:   bridge window [mem 0xf0000000-0xfed8ffff]
(subtractive decode)

ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT]

ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.NPE7._PRT]

ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.P0P1._PRT]

ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.NPE1._PRT]

ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.NPE5._PRT]

 pci0000:00: Unable to request _OSC control (_OSC support mask: 0x19)

(XEN) PCI add device 00:00.0
(XEN) PCI add device 00:01.0
(XEN) PCI add device 00:03.0
(XEN) PCI add device 00:05.0
(XEN) PCI add device 00:07.0
(XEN) PCI add device 00:13.0
(XEN) PCI add device 00:14.0
(XEN) PCI add device 00:14.1
(XEN) PCI add device 00:14.2
(XEN) PCI add device 00:14.3
(XEN) PCI add device 00:16.0
(XEN) PCI add device 00:16.1
(XEN) PCI add device 00:16.2
(XEN) PCI add device 00:16.3
(XEN) PCI add device 00:16.4
(XEN) PCI add device 00:16.5
(XEN) PCI add device 00:16.6
(XEN) PCI add device 00:16.7
(XEN) PCI add device 00:1d.0
(XEN) PCI add device 00:1d.1
(XEN) PCI add device 00:1d.2
(XEN) PCI add device 00:1d.7
(XEN) PCI add device 00:1e.0
(XEN) PCI add device 00:1f.0
(XEN) PCI add device 00:1f.2
(XEN) PCI add device 00:1f.3
(XEN) PCI add device 01:00.0
(XEN) PCI add device 01:00.1
(XEN) PCI add device 03:00.0
(XEN) PCI add device 03:00.1
(XEN) PCI add device 07:04.0
ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 6 7 *10 11 12 14 15)

ACPI: PCI Interrupt Link [LNKB] (IRQs *5)

ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 6 7 10 11 12 14 *15)

ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 6 7 10 *11 12 14 15)

ACPI: PCI Interrupt Link [LNKE] (IRQs 3 4 6 7 10 11 12 14 15) *0, disabled.

ACPI: PCI Interrupt Link [LNKF] (IRQs 3 4 6 7 10 11 12 14 15) *0, disabled.

ACPI: PCI Interrupt Link [LNKG] (IRQs 3 4 6 7 10 11 12 14 15) *0, disabled.

ACPI: PCI Interrupt Link [LNKH] (IRQs 3 4 6 7 10 11 12 *14 15)

xen/balloon: Initialising balloon driver.

xen-balloon: Initialising balloon driver.

xen/balloon: Xen selfballooning driver disabled for domain0.

vgaarb: device added: PCI:0000:07:04.0,decodes=io+mem,owns=io+mem,locks=none

vgaarb: loaded

vgaarb: bridge control possible 0000:07:04.0

PCI: Using ACPI for IRQ routing

PCI: Discovered peer bus fe

PCI: root bus fe: using default resources

PCI host bridge to bus 0000:fe

pci_bus 0000:fe: root bus resource [io  0x0000-0xffff]

pci_bus 0000:fe: root bus resource [mem 0x00000000-0xffffffffff]

pci 0000:fe:00.0: [8086:2c70] type 00 class 0x060000

pci 0000:fe:00.1: [8086:2d81] type 00 class 0x060000

pci 0000:fe:02.0: [8086:2d90] type 00 class 0x060000

pci 0000:fe:02.1: [8086:2d91] type 00 class 0x060000

pci 0000:fe:02.2: [8086:2d92] type 00 class 0x060000

pci 0000:fe:02.3: [8086:2d93] type 00 class 0x060000

pci 0000:fe:02.4: [8086:2d94] type 00 class 0x060000

pci 0000:fe:02.5: [8086:2d95] type 00 class 0x060000

pci 0000:fe:03.0: [8086:2d98] type 00 class 0x060000

pci 0000:fe:03.1: [8086:2d99] type 00 class 0x060000

pci 0000:fe:03.2: [8086:2d9a] type 00 class 0x060000

pci 0000:fe:03.4: [8086:2d9c] type 00 class 0x060000

pci 0000:fe:04.0: [8086:2da0] type 00 class 0x060000

pci 0000:fe:04.1: [8086:2da1] type 00 class 0x060000

pci 0000:fe:04.2: [8086:2da2] type 00 class 0x060000

pci 0000:fe:04.3: [8086:2da3] type 00 class 0x060000

pci 0000:fe:05.0: [8086:2da8] type 00 class 0x060000

pci 0000:fe:05.1: [8086:2da9] type 00 class 0x060000

pci 0000:fe:05.2: [8086:2daa] type 00 class 0x060000

pci 0000:fe:05.3: [8086:2dab] type 00 class 0x060000

pci 0000:fe:06.0: [8086:2db0] type 00 class 0x060000

pci 0000:fe:06.1: [8086:2db1] type 00 class 0x060000

pci 0000:fe:06.2: [8086:2db2] type 00 class 0x060000

pci 0000:fe:06.3: [8086:2db3] type 00 class 0x060000

(XEN) PCI add device fe:00.0
(XEN) PCI add device fe:00.1
(XEN) PCI add device fe:02.0
(XEN) PCI add device fe:02.1
(XEN) PCI add device fe:02.2
(XEN) PCI add device fe:02.3
(XEN) PCI add device fe:02.4
(XEN) PCI add device fe:02.5
(XEN) PCI add device fe:03.0
(XEN) PCI add device fe:03.1
(XEN) PCI add device fe:03.2
(XEN) PCI add device fe:03.4
(XEN) PCI add device fe:04.0
(XEN) PCI add device fe:04.1
(XEN) PCI add device fe:04.2
(XEN) PCI add device fe:04.3
(XEN) PCI add device fe:05.0
(XEN) PCI add device fe:05.1
(XEN) PCI add device fe:05.2
(XEN) PCI add device fe:05.3
(XEN) PCI add device fe:06.0
(XEN) PCI add device fe:06.1
(XEN) PCI add device fe:06.2
(XEN) PCI add device fe:06.3
PCI: Discovered peer bus ff

PCI: root bus ff: using default resources

PCI host bridge to bus 0000:ff

pci_bus 0000:ff: root bus resource [io  0x0000-0xffff]

pci_bus 0000:ff: root bus resource [mem 0x00000000-0xffffffffff]

pci 0000:ff:00.0: [8086:2c70] type 00 class 0x060000

pci 0000:ff:00.1: [8086:2d81] type 00 class 0x060000

pci 0000:ff:02.0: [8086:2d90] type 00 class 0x060000

pci 0000:ff:02.1: [8086:2d91] type 00 class 0x060000

pci 0000:ff:02.2: [8086:2d92] type 00 class 0x060000

pci 0000:ff:02.3: [8086:2d93] type 00 class 0x060000

pci 0000:ff:02.4: [8086:2d94] type 00 class 0x060000

pci 0000:ff:02.5: [8086:2d95] type 00 class 0x060000

pci 0000:ff:03.0: [8086:2d98] type 00 class 0x060000

pci 0000:ff:03.1: [8086:2d99] type 00 class 0x060000

pci 0000:ff:03.2: [8086:2d9a] type 00 class 0x060000

pci 0000:ff:03.4: [8086:2d9c] type 00 class 0x060000

pci 0000:ff:04.0: [8086:2da0] type 00 class 0x060000

pci 0000:ff:04.1: [8086:2da1] type 00 class 0x060000

pci 0000:ff:04.2: [8086:2da2] type 00 class 0x060000

pci 0000:ff:04.3: [8086:2da3] type 00 class 0x060000

pci 0000:ff:05.0: [8086:2da8] type 00 class 0x060000

pci 0000:ff:05.1: [8086:2da9] type 00 class 0x060000

pci 0000:ff:05.2: [8086:2daa] type 00 class 0x060000

pci 0000:ff:05.3: [8086:2dab] type 00 class 0x060000

pci 0000:ff:06.0: [8086:2db0] type 00 class 0x060000

pci 0000:ff:06.1: [8086:2db1] type 00 class 0x060000

pci 0000:ff:06.2: [8086:2db2] type 00 class 0x060000

pci 0000:ff:06.3: [8086:2db3] type 00 class 0x060000

(XEN) PCI add device ff:00.0
(XEN) PCI add device ff:00.1
(XEN) PCI add device ff:02.0
(XEN) PCI add device ff:02.1
(XEN) PCI add device ff:02.2
(XEN) PCI add device ff:02.3
(XEN) PCI add device ff:02.4
(XEN) PCI add device ff:02.5
(XEN) PCI add device ff:03.0
(XEN) PCI add device ff:03.1
(XEN) PCI add device ff:03.2
(XEN) PCI add device ff:03.4
(XEN) PCI add device ff:04.0
(XEN) PCI add device ff:04.1
(XEN) PCI add device ff:04.2
(XEN) PCI add device ff:04.3
(XEN) PCI add device ff:05.0
(XEN) PCI add device ff:05.1
(XEN) PCI add device ff:05.2
(XEN) PCI add device ff:05.3
(XEN) PCI add device ff:06.0
(XEN) PCI add device ff:06.1
(XEN) PCI add device ff:06.2
(XEN) PCI add device ff:06.3
PCI: pci_cache_line_size set to 64 bytes

reserve RAM buffer: 000000000009b000 - 000000000009ffff

reserve RAM buffer: 0000000040065000 - 0000000043ffffff

Switching to clocksource xen

pnp: PnP ACPI init

ACPI: bus type pnp registered

pnp 00:00: [bus 00-ff]

pnp 00:00: [io  0x0cf8-0x0cff]

pnp 00:00: [io  0x0000-0x03af window]

pnp 00:00: [io  0x03e0-0x0cf7 window]

pnp 00:00: [io  0x03b0-0x03bb window]

pnp 00:00: [io  0x03c0-0x03df window]

pnp 00:00: [io  0x0d00-0xffff window]

pnp 00:00: [mem 0x000a0000-0x000bffff window]

pnp 00:00: [mem 0x000d0000-0x000dffff window]

pnp 00:00: [mem 0xc0000000-0xdfffffff window]

pnp 00:00: [mem 0xf0000000-0xfed8ffff window]

pnp 00:00: Plug and Play ACPI device, IDs PNP0a08 PNP0a03 (active)

pnp 00:01: [mem 0xfbf00000-0xfbffffff]

pnp 00:01: [mem 0xfc000000-0xfcffffff]

pnp 00:01: [mem 0xfd000000-0xfdffffff]

pnp 00:01: [mem 0xfe000000-0xfebfffff]

pnp 00:01: [mem 0xfec8a000-0xfec8afff]

pnp 00:01: [mem 0xfed10000-0xfed10fff]

system 00:01: [mem 0xfbf00000-0xfbffffff] has been reserved

system 00:01: [mem 0xfc000000-0xfcffffff] has been reserved

system 00:01: [mem 0xfd000000-0xfdffffff] has been reserved

system 00:01: [mem 0xfe000000-0xfebfffff] has been reserved

system 00:01: [mem 0xfec8a000-0xfec8afff] could not be reserved

system 00:01: [mem 0xfed10000-0xfed10fff] has been reserved

system 00:01: Plug and Play ACPI device, IDs PNP0c01 (active)

pnp 00:02: [dma 4]

pnp 00:02: [io  0x0000-0x000f]

pnp 00:02: [io  0x0081-0x0083]

pnp 00:02: [io  0x0087]

pnp 00:02: [io  0x0089-0x008b]

pnp 00:02: [io  0x008f]

pnp 00:02: [io  0x00c0-0x00df]

pnp 00:02: Plug and Play ACPI device, IDs PNP0200 (active)

pnp 00:03: [io  0x0070-0x0071]

xen: registering gsi 8 triggering 1 polarity 0

pnp 00:03: [irq 8]

pnp 00:03: Plug and Play ACPI device, IDs PNP0b00 (active)

pnp 00:04: [io  0x0061]

pnp 00:04: Plug and Play ACPI device, IDs PNP0800 (active)

pnp 00:05: [io  0x00f0-0x00ff]

xen: registering gsi 13 triggering 1 polarity 0

pnp 00:05: [irq 13]

pnp 00:05: Plug and Play ACPI device, IDs PNP0c04 (active)

pnp 00:06: [io  0x0010-0x001f]

pnp 00:06: [io  0x0022-0x003f]

pnp 00:06: [io  0x0044-0x005f]

pnp 00:06: [io  0x0062-0x0063]

pnp 00:06: [io  0x0065-0x006f]

pnp 00:06: [io  0x0072-0x007f]

pnp 00:06: [io  0x0080]

pnp 00:06: [io  0x0084-0x0086]

pnp 00:06: [io  0x0088]

pnp 00:06: [io  0x008c-0x008e]

pnp 00:06: [io  0x0090-0x009f]

pnp 00:06: [io  0x00a2-0x00bf]

pnp 00:06: [io  0x00e0-0x00ef]

pnp 00:06: [io  0x04d0-0x04d1]

pnp 00:06: [io  0x0800-0x087f]

pnp 00:06: [io  0x0000-0xffffffffffffffff disabled]

pnp 00:06: [io  0x0500-0x057f]

pnp 00:06: [io  0x0000-0xffffffffffffffff disabled]

pnp 00:06: [mem 0xfed1c000-0xfed1ffff]

pnp 00:06: [mem 0xfed20000-0xfed3ffff]

pnp 00:06: [mem 0xfed40000-0xfed8ffff]

system 00:06: [io  0x04d0-0x04d1] has been reserved

system 00:06: [io  0x0800-0x087f] has been reserved

system 00:06: [io  0x0500-0x057f] has been reserved

system 00:06: [mem 0xfed1c000-0xfed1ffff] has been reserved

system 00:06: [mem 0xfed20000-0xfed3ffff] has been reserved

system 00:06: [mem 0xfed40000-0xfed8ffff] has been reserved

system 00:06: Plug and Play ACPI device, IDs PNP0c02 (active)

pnp 00:07: [io  0x0ca2]

pnp 00:07: [io  0x0ca3]

pnp 00:07: Plug and Play ACPI device, IDs IPI0001 (active)

pnp 00:08: [mem 0xfed00000-0xfed003ff]

pnp 00:08: Plug and Play ACPI device, IDs PNP0103 (active)

pnp 00:09: [io  0x0060]

pnp 00:09: [io  0x0064]

pnp 00:09: [mem 0xfec00000-0xfec00fff]

pnp 00:09: [mem 0xfee00000-0xfee00fff]

system 00:09: [mem 0xfec00000-0xfec00fff] could not be reserved

system 00:09: [mem 0xfee00000-0xfee00fff] has been reserved

system 00:09: Plug and Play ACPI device, IDs PNP0c02 (active)

pnp 00:0a: [mem 0xe0000000-0xefffffff]

system 00:0a: [mem 0xe0000000-0xefffffff] has been reserved

system 00:0a: Plug and Play ACPI device, IDs PNP0c02 (active)

pnp 00:0b: [mem 0x00000000-0x0009ffff]

pnp 00:0b: [mem 0x000c0000-0x000cffff]

pnp 00:0b: [mem 0x000e0000-0x000fffff]

pnp 00:0b: [mem 0x00100000-0xbfffffff]

pnp 00:0b: [mem 0xfed90000-0xffffffff]

system 00:0b: [mem 0x00000000-0x0009ffff] could not be reserved

system 00:0b: [mem 0x000c0000-0x000cffff] could not be reserved

system 00:0b: [mem 0x000e0000-0x000fffff] could not be reserved

system 00:0b: [mem 0x00100000-0xbfffffff] could not be reserved

system 00:0b: [mem 0xfed90000-0xffffffff] could not be reserved

system 00:0b: Plug and Play ACPI device, IDs PNP0c01 (active)

pnp: PnP ACPI: found 12 devices

ACPI: ACPI bus type pnp unregistered

PM-Timer failed consistency check  (0x0xffffff) - aborting.

pci 0000:00:01.0: PCI bridge to [bus 01-02]

pci 0000:00:01.0:   bridge window [io  0xc000-0xcfff]

pci 0000:00:01.0:   bridge window [mem 0xfbb00000-0xfbcfffff]

pci 0000:00:03.0: PCI bridge to [bus 03-04]

pci 0000:00:03.0:   bridge window [io  0xd000-0xdfff]

pci 0000:00:03.0:   bridge window [mem 0xfbd00000-0xfbdfffff]

pci 0000:00:03.0:   bridge window [mem 0xf9c00000-0xf9ffffff 64bit pref]

pci 0000:00:05.0: PCI bridge to [bus 05-05]

pci 0000:00:07.0: PCI bridge to [bus 06-06]

pci 0000:00:1e.0: PCI bridge to [bus 07-07]

pci 0000:00:1e.0:   bridge window [io  0xe000-0xefff]

pci 0000:00:1e.0:   bridge window [mem 0xfaf00000-0xfb7fffff]

pci 0000:00:1e.0: setting latency timer to 64

pci_bus 0000:00: resource 4 [io  0x0000-0x03af]

pci_bus 0000:00: resource 5 [io  0x03e0-0x0cf7]

pci_bus 0000:00: resource 6 [io  0x03b0-0x03bb]

pci_bus 0000:00: resource 7 [io  0x03c0-0x03df]

pci_bus 0000:00: resource 8 [io  0x0d00-0xffff]

pci_bus 0000:00: resource 9 [mem 0x000a0000-0x000bffff]

pci_bus 0000:00: resource 10 [mem 0x000d0000-0x000dffff]

pci_bus 0000:00: resource 11 [mem 0xc0000000-0xdfffffff]

pci_bus 0000:00: resource 12 [mem 0xf0000000-0xfed8ffff]

pci_bus 0000:01: resource 0 [io  0xc000-0xcfff]

pci_bus 0000:01: resource 1 [mem 0xfbb00000-0xfbcfffff]

pci_bus 0000:03: resource 0 [io  0xd000-0xdfff]

pci_bus 0000:03: resource 1 [mem 0xfbd00000-0xfbdfffff]

pci_bus 0000:03: resource 2 [mem 0xf9c00000-0xf9ffffff 64bit pref]

pci_bus 0000:07: resource 0 [io  0xe000-0xefff]

pci_bus 0000:07: resource 1 [mem 0xfaf00000-0xfb7fffff]

pci_bus 0000:07: resource 4 [io  0x0000-0x03af]

pci_bus 0000:07: resource 5 [io  0x03e0-0x0cf7]

pci_bus 0000:07: resource 6 [io  0x03b0-0x03bb]

pci_bus 0000:07: resource 7 [io  0x03c0-0x03df]

pci_bus 0000:07: resource 8 [io  0x0d00-0xffff]

pci_bus 0000:07: resource 9 [mem 0x000a0000-0x000bffff]

pci_bus 0000:07: resource 10 [mem 0x000d0000-0x000dffff]

pci_bus 0000:07: resource 11 [mem 0xc0000000-0xdfffffff]

pci_bus 0000:07: resource 12 [mem 0xf0000000-0xfed8ffff]

pci_bus 0000:fe: resource 4 [io  0x0000-0xffff]

pci_bus 0000:fe: resource 5 [mem 0x00000000-0xffffffffff]

pci_bus 0000:ff: resource 4 [io  0x0000-0xffff]

pci_bus 0000:ff: resource 5 [mem 0x00000000-0xffffffffff]

NET: Registered protocol family 2

IP route cache hash table entries: 32768 (order: 5, 131072 bytes)

TCP established hash table entries: 131072 (order: 8, 1048576 bytes)

TCP bind hash table entries: 65536 (order: 7, 524288 bytes)

TCP: Hash tables configured (established 131072 bind 65536)

TCP: reno registered

UDP hash table entries: 512 (order: 2, 16384 bytes)

UDP-Lite hash table entries: 512 (order: 2, 16384 bytes)

NET: Registered protocol family 1

RPC: Registered named UNIX socket transport module.

RPC: Registered udp transport module.

RPC: Registered tcp transport module.

RPC: Registered tcp NFSv4.1 backchannel transport module.

xen: registering gsi 23 triggering 0 polarity 1

xen: --> pirq=23 -> irq=23 (gsi=23)

xen: registering gsi 19 triggering 0 polarity 1

xen: --> pirq=19 -> irq=19 (gsi=19)

xen: registering gsi 18 triggering 0 polarity 1

xen: --> pirq=18 -> irq=18 (gsi=18)

xen: registering gsi 23 triggering 0 polarity 1

Already setup the GSI :23

pci 0000:07:04.0: Boot video device

PCI: CLS 256 bytes, default 64

Trying to unpack rootfs image as initramfs...

Freeing initrd memory: 2960k freed

microcode: CPU0 sig=0x206c2, pf=0x1, revision=0x14

microcode: Microcode Update Driver: v2.00
<tigran@aivazian.fsnet.co.uk>, Peter Oruba

highmem bounce pool size: 64 pages

NFS: Registering the id_resolver key type

msgmni has been set to 1497

Block layer SCSI generic (bsg) driver version 0.4 loaded (major 253)

io scheduler noop registered (default)

io scheduler deadline registered

io scheduler cfq registered

ioapic: probe of 0000:00:13.0 failed with error -22

ioatdma: Intel(R) QuickData Technology Driver 4.00

xen: registering gsi 43 triggering 0 polarity 1

xen: --> pirq=43 -> irq=43 (gsi=43)

(XEN) ../physdev.c:171: dom0: wrong map_pirq type 3
xen: registering gsi 44 triggering 0 polarity 1

xen: --> pirq=44 -> irq=44 (gsi=44)

xen: registering gsi 45 triggering 0 polarity 1

xen: --> pirq=45 -> irq=45 (gsi=45)

xen: registering gsi 46 triggering 0 polarity 1

xen: --> pirq=46 -> irq=46 (gsi=46)

xen: registering gsi 43 triggering 0 polarity 1

Already setup the GSI :43

xen: registering gsi 44 triggering 0 polarity 1

Already setup the GSI :44

xen: registering gsi 45 triggering 0 polarity 1

Already setup the GSI :45

xen: registering gsi 46 triggering 0 polarity 1

Already setup the GSI :46

Event-channel device installed.

xen-pciback: backend is vpci

Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled

serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A

brd: module loaded

loop: module loaded

igb: Intel(R) Gigabit Ethernet Network Driver - version 3.2.10-k

igb: Copyright (c) 2007-2012 Intel Corporation.

xen: registering gsi 17 triggering 0 polarity 1

xen: --> pirq=17 -> irq=17 (gsi=17)

igb 0000:01:00.0: Intel(R) Gigabit Ethernet Network Connection

igb 0000:01:00.0: eth0: (PCIe:2.5Gb/s:Width x4) 00:26:6c:ff:b3:8c

igb 0000:01:00.0: eth0: PBA No: 82576B-001

igb 0000:01:00.0: Using MSI-X interrupts. 1 rx queue(s), 1 tx queue(s)

xen: registering gsi 16 triggering 0 polarity 1

xen: --> pirq=16 -> irq=16 (gsi=16)

igb 0000:01:00.1: Intel(R) Gigabit Ethernet Network Connection

igb 0000:01:00.1: eth1: (PCIe:2.5Gb/s:Width x4) 00:26:6c:ff:b3:8d

igb 0000:01:00.1: eth1: PBA No: 82576B-001

igb 0000:01:00.1: Using MSI-X interrupts. 1 rx queue(s), 1 tx queue(s)

ixgbe: Intel(R) 10 Gigabit PCI Express Network Driver - version 3.8.21-k

ixgbe: Copyright (c) 1999-2012 Intel Corporation.

xen: registering gsi 24 triggering 0 polarity 1

xen: --> pirq=24 -> irq=24 (gsi=24)

ixgbe 0000:03:00.0: Multiqueue Disabled: Rx Queue count = 1, Tx Queue count = 1

ixgbe 0000:03:00.0: (PCI Express:5.0GT/s:Width x8) 00:8c:fa:01:84:6a

ixgbe 0000:03:00.0: MAC: 2, PHY: 1, PBA No: FFFFFF-0FF

ixgbe 0000:03:00.0: Intel(R) 10 Gigabit Network Connection

xen: registering gsi 34 triggering 0 polarity 1

xen: --> pirq=34 -> irq=34 (gsi=34)

ixgbe 0000:03:00.1: Multiqueue Disabled: Rx Queue count = 1, Tx Queue count = 1

ixgbe 0000:03:00.1: (PCI Express:5.0GT/s:Width x8) 00:8c:fa:01:84:6b

ixgbe 0000:03:00.1: MAC: 2, PHY: 1, PBA No: FFFFFF-0FF

ixgbe 0000:03:00.1: Intel(R) 10 Gigabit Network Connection

md: raid0 personality registered for level 0

md: raid1 personality registered for level 1

device-mapper: ioctl: 4.22.0-ioctl (2011-10-19) initialised: dm-devel@redhat.com

dcdbas dcdbas: Dell Systems Management Base Driver (version 5.6.0-3.2)

ip_tables: (C) 2000-2006 Netfilter Core Team

TCP: cubic registered

NET: Registered protocol family 10

NET: Registered protocol family 17
8021q: 802.1Q VLAN Support v1.8
Using IPI No-Shortcut mode
console [netcon0] enabled
netconsole: network logging started
drivers/rtc/hctosys.c: unable to open rtc device (rtc0)
BIOS EDD facility v0.16 2004-Jun-25, 0 devices found
EDD information not available.
ADDRCONF(NETDEV_UP): eth0: link is not ready
8021q: adding VLAN 0 to HW filter on device eth0
igb: eth0 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX
ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
Sending DHCP requests .., OK
IP-Config: Got DHCP answer from 10.5.5.55, my address is
IP-Config: Complete:

Freeing unused kernel memory: 356k freed

Using fallback suid method

Using fallback suid method

Using fallback suid method

Using fallback suid method

Using fallback suid method

Using fallback suid method

Using fallback suid method

Using fallback suid method

Using fallback suid method


INIT: version 2.88 booting
Using makefile-style concurrent boot in runlevel S.
.udev/ already exists on the static /dev! ...  [33m(warning). [39;49m
Starting the hotplug events dispatcher: udevd.
Synthesizing the initial hotplug events...done.
Waiting for /dev to be fully populated...input: Power Button as
/devices/LNXSYSTM:00/device:00/PNP0C0C:00/input/input0
ACPI: Power Button [PWRB]
input: Power Button as /devices/LNXSYSTM:00/LNXPWRBN:00/input/input1
ACPI: Power Button [PWRF]
rtc_cmos 00:03: RTC can wake from S4
rtc_cmos 00:03: rtc core: registered rtc_cmos as rtc0
rtc0: alarms up to one month, y3k, 114 bytes nvram
udev[1190]: renamed network interface eth3 to eth4
udevd-work[1177]: error changing net interface name eth0 to eth5:
Device or resource busy
udev[1189]: renamed network interface eth2 to eth6
udev[1178]: renamed network interface eth1 to eth7

done.
Setting preliminary keymap...done.

-- 
William

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 20 17:18:40 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Sep 2012 17:18: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 1TEkOO-0007AA-Ka; Thu, 20 Sep 2012 17:18:24 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1TEkOM-0007A0-TY
	for xen-devel@lists.xensource.com; Thu, 20 Sep 2012 17:18:23 +0000
Received: from [85.158.143.35:14943] by server-3.bemta-4.messagelabs.com id
	D0/56-10986-EDF4B505; Thu, 20 Sep 2012 17:18:22 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1348161501!7435453!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTA0NTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 734 invoked from network); 20 Sep 2012 17:18:21 -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;
	20 Sep 2012 17:18:21 -0000
X-IronPort-AV: E=Sophos;i="4.80,455,1344211200"; d="scan'208";a="14670485"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Sep 2012 17:18: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.279.1; Thu, 20 Sep 2012 18:18: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 1TEkOL-0007C8-2m;
	Thu, 20 Sep 2012 17:18:21 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1TEkOK-00055i-LZ;
	Thu, 20 Sep 2012 18:18:20 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-13820-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 20 Sep 2012 18:18:20 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.1-testing test] 13820: 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 13820 xen-4.1-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13820/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-pcipt-intel  8 debian-fixup                fail like 13725
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 13725

Tests which did not succeed, but are not blocking:
 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-i386-i386-xl-winxpsp3   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-win           16 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-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 13 guest-stop               fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel 11 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-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-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-i386-i386-xl-qemuu-winxpsp3 13 guest-stop                 fail never pass

version targeted for testing:
 xen                  6a17d5f11d66
baseline version:
 xen                  c52e7afc96a9

------------------------------------------------------------
People who touched revisions under test:
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  Andrew Cooper <andrew.cooper3@citrix.com>
  Boris Ostrovsky <boris.ostrovsky@amd.com>
  George Dunlap <george.dunlap@eu.citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  J?rgen Gro? <juergen.gross@ts.fujitsu.com>
  Jan Beulich <jbeulich@suse.com>
  Jonathan Tripathy <jonnyt@abpni.co.uk>
  Keir Fraser <keir@xen.org>
  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                                     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=6a17d5f11d66
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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 6a17d5f11d66
+ branch=xen-4.1-testing
+ revision=6a17d5f11d66
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-4.1-testing
+ '[' xxen = xlinux ']'
+ linuxbranch=linux
+ : master
+ : tested/2.6.39.x
+ . ap-common
++ : xen@xenbits.xensource.com
++ : http://xenbits.xen.org/hg/staging/xen-4.1-testing.hg
++ : git://xenbits.xen.org/staging/qemu-xen-4.1-testing.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : xen@xenbits.xensource.com:git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.xen-4.1-testing
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-4.1-testing.git
++ : daily-cron.xen-4.1-testing
+ TREE_LINUX=xen@xenbits.xensource.com:git/linux-pvops.git
+ TREE_QEMU_UPSTREAM=xen@xenbits.xensource.com:git/qemu-upstream-4.1-testing.git
+ info_linux_tree xen-4.1-testing
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/xen-4.1-testing.hg
+ hg push -r 6a17d5f11d66 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 10 changesets with 15 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 Sep 20 17:18:40 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Sep 2012 17:18: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 1TEkOO-0007AA-Ka; Thu, 20 Sep 2012 17:18:24 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1TEkOM-0007A0-TY
	for xen-devel@lists.xensource.com; Thu, 20 Sep 2012 17:18:23 +0000
Received: from [85.158.143.35:14943] by server-3.bemta-4.messagelabs.com id
	D0/56-10986-EDF4B505; Thu, 20 Sep 2012 17:18:22 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1348161501!7435453!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTA0NTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 734 invoked from network); 20 Sep 2012 17:18:21 -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;
	20 Sep 2012 17:18:21 -0000
X-IronPort-AV: E=Sophos;i="4.80,455,1344211200"; d="scan'208";a="14670485"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Sep 2012 17:18: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.279.1; Thu, 20 Sep 2012 18:18: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 1TEkOL-0007C8-2m;
	Thu, 20 Sep 2012 17:18:21 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1TEkOK-00055i-LZ;
	Thu, 20 Sep 2012 18:18:20 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-13820-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 20 Sep 2012 18:18:20 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.1-testing test] 13820: 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 13820 xen-4.1-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13820/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-pcipt-intel  8 debian-fixup                fail like 13725
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 13725

Tests which did not succeed, but are not blocking:
 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-i386-i386-xl-winxpsp3   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-win           16 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-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 13 guest-stop               fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel 11 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-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-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-i386-i386-xl-qemuu-winxpsp3 13 guest-stop                 fail never pass

version targeted for testing:
 xen                  6a17d5f11d66
baseline version:
 xen                  c52e7afc96a9

------------------------------------------------------------
People who touched revisions under test:
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  Andrew Cooper <andrew.cooper3@citrix.com>
  Boris Ostrovsky <boris.ostrovsky@amd.com>
  George Dunlap <george.dunlap@eu.citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  J?rgen Gro? <juergen.gross@ts.fujitsu.com>
  Jan Beulich <jbeulich@suse.com>
  Jonathan Tripathy <jonnyt@abpni.co.uk>
  Keir Fraser <keir@xen.org>
  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                                     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=6a17d5f11d66
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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 6a17d5f11d66
+ branch=xen-4.1-testing
+ revision=6a17d5f11d66
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-4.1-testing
+ '[' xxen = xlinux ']'
+ linuxbranch=linux
+ : master
+ : tested/2.6.39.x
+ . ap-common
++ : xen@xenbits.xensource.com
++ : http://xenbits.xen.org/hg/staging/xen-4.1-testing.hg
++ : git://xenbits.xen.org/staging/qemu-xen-4.1-testing.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : xen@xenbits.xensource.com:git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.xen-4.1-testing
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-4.1-testing.git
++ : daily-cron.xen-4.1-testing
+ TREE_LINUX=xen@xenbits.xensource.com:git/linux-pvops.git
+ TREE_QEMU_UPSTREAM=xen@xenbits.xensource.com:git/qemu-upstream-4.1-testing.git
+ info_linux_tree xen-4.1-testing
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/xen-4.1-testing.hg
+ hg push -r 6a17d5f11d66 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 10 changesets with 15 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 Sep 20 18:43:56 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Sep 2012 18:43:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TElif-0000N2-As; Thu, 20 Sep 2012 18:43:25 +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 1TElie-0000Mx-9k
	for xen-devel@lists.xen.org; Thu, 20 Sep 2012 18:43:24 +0000
Received: from [85.158.137.99:61200] by server-4.bemta-3.messagelabs.com id
	11/2D-24831-BC36B505; Thu, 20 Sep 2012 18:43:23 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-8.tower-217.messagelabs.com!1348166602!13151413!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA1MDk4NTY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26319 invoked from network); 20 Sep 2012 18:43:22 -0000
Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25)
	by server-8.tower-217.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 20 Sep 2012 18:43:22 -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 2D96611FE;
	Thu, 20 Sep 2012 21:43:11 +0300 (EEST)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id C6EF42005D; Thu, 20 Sep 2012 21:43:10 +0300 (EEST)
Date: Thu, 20 Sep 2012 21:43:10 +0300
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120920184310.GD8912@reaktio.net>
References: <201208281225.q7SCP1WO017490@wind.enjellic.com>
	<1346226868.4847.21.camel@dagon.hellion.org.uk>
	<20120906131834.GV8912@reaktio.net>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120906131834.GV8912@reaktio.net>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: "greg@enjellic.com" <greg@enjellic.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] XEN 4.1.3 blktap2 patches.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="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, Sep 06, 2012 at 04:18:34PM +0300, Pasi K=E4rkk=E4inen wrote:
> Hello,
> =

> On Wed, Aug 29, 2012 at 08:54:28AM +0100, Ian Campbell wrote:
> > On Tue, 2012-08-28 at 13:25 +0100, Dr. Greg Wettstein wrote:
> > > Good morning, hope the day is going well for everyone.
> > > =

> > > The patches to fix the blktap2 issues which result in orphaned
> > > tapdisk2 processes and the transitory deadlock on guest shutdown
> > > didn't make it into the 4.1.3 release.  Updated patches to address
> > > these problems are available at the following location:
> > > =

> > > 	ftp://ftp.enjellic.com/pub/xen/xen-4.1.3.blktap1.patch
> > > 	ftp://ftp.enjellic.com/pub/xen/xen-4.1.3.blktap2.patch
> > > =

> > > The patches are designed to be applied in order and have been verified
> > > to work against the 4.1.3 release.
> > =

> > Please can you post these patches as emails with a changelog and a
> > signed-off-by. You should also CC Ian Jackson since he is the one who
> > does the tools backports.
> > =

> =

> Added Ian Jackson to CC list..
> =


Ping? =


Do we need a repost here or can these go into 4.1-testing.hg ? =

I see xen-4.1-testing.hg has received other backports now. =


-- Pasi

> =

> > The changelog should be clear about the backport status. IIRC one of
> > these is a backport from unstable (so the changelog should say of which
> > commit and preserve the original S-o-b) and the other is a
> > reimplementation since too much has changed in unstable so there is no
> > plausible backport (and the changelog should mention this).
> > =

> > Ideally these mails would be threaded with subjects "[PATCH 1/2] ..."
> > and "[PATCH 2/2] ..." so that it is obvious that there is a sequence to
> > them. A tool such as hg email will do this for you.
> > http://wiki.xen.org/wiki/Submitting_Xen_Patches has some hints on how to
> > use it.
> > =

> > If nothing has changed since the previous posting it may be sufficient
> > to reply to that previous postings with a "ping" message and CC Ian
> > there.
> > =

> =

> So is repost needed here? =

> =

> -- Pasi
> =

> =

> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Sep 20 18:43:56 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Sep 2012 18:43:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TElif-0000N2-As; Thu, 20 Sep 2012 18:43:25 +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 1TElie-0000Mx-9k
	for xen-devel@lists.xen.org; Thu, 20 Sep 2012 18:43:24 +0000
Received: from [85.158.137.99:61200] by server-4.bemta-3.messagelabs.com id
	11/2D-24831-BC36B505; Thu, 20 Sep 2012 18:43:23 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-8.tower-217.messagelabs.com!1348166602!13151413!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA1MDk4NTY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26319 invoked from network); 20 Sep 2012 18:43:22 -0000
Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25)
	by server-8.tower-217.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 20 Sep 2012 18:43:22 -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 2D96611FE;
	Thu, 20 Sep 2012 21:43:11 +0300 (EEST)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id C6EF42005D; Thu, 20 Sep 2012 21:43:10 +0300 (EEST)
Date: Thu, 20 Sep 2012 21:43:10 +0300
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120920184310.GD8912@reaktio.net>
References: <201208281225.q7SCP1WO017490@wind.enjellic.com>
	<1346226868.4847.21.camel@dagon.hellion.org.uk>
	<20120906131834.GV8912@reaktio.net>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120906131834.GV8912@reaktio.net>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: "greg@enjellic.com" <greg@enjellic.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] XEN 4.1.3 blktap2 patches.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="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, Sep 06, 2012 at 04:18:34PM +0300, Pasi K=E4rkk=E4inen wrote:
> Hello,
> =

> On Wed, Aug 29, 2012 at 08:54:28AM +0100, Ian Campbell wrote:
> > On Tue, 2012-08-28 at 13:25 +0100, Dr. Greg Wettstein wrote:
> > > Good morning, hope the day is going well for everyone.
> > > =

> > > The patches to fix the blktap2 issues which result in orphaned
> > > tapdisk2 processes and the transitory deadlock on guest shutdown
> > > didn't make it into the 4.1.3 release.  Updated patches to address
> > > these problems are available at the following location:
> > > =

> > > 	ftp://ftp.enjellic.com/pub/xen/xen-4.1.3.blktap1.patch
> > > 	ftp://ftp.enjellic.com/pub/xen/xen-4.1.3.blktap2.patch
> > > =

> > > The patches are designed to be applied in order and have been verified
> > > to work against the 4.1.3 release.
> > =

> > Please can you post these patches as emails with a changelog and a
> > signed-off-by. You should also CC Ian Jackson since he is the one who
> > does the tools backports.
> > =

> =

> Added Ian Jackson to CC list..
> =


Ping? =


Do we need a repost here or can these go into 4.1-testing.hg ? =

I see xen-4.1-testing.hg has received other backports now. =


-- Pasi

> =

> > The changelog should be clear about the backport status. IIRC one of
> > these is a backport from unstable (so the changelog should say of which
> > commit and preserve the original S-o-b) and the other is a
> > reimplementation since too much has changed in unstable so there is no
> > plausible backport (and the changelog should mention this).
> > =

> > Ideally these mails would be threaded with subjects "[PATCH 1/2] ..."
> > and "[PATCH 2/2] ..." so that it is obvious that there is a sequence to
> > them. A tool such as hg email will do this for you.
> > http://wiki.xen.org/wiki/Submitting_Xen_Patches has some hints on how to
> > use it.
> > =

> > If nothing has changed since the previous posting it may be sufficient
> > to reply to that previous postings with a "ping" message and CC Ian
> > there.
> > =

> =

> So is repost needed here? =

> =

> -- Pasi
> =

> =

> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Sep 20 19:16:11 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Sep 2012 19:16:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TEmDx-0000iA-6M; Thu, 20 Sep 2012 19:15:45 +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 1TEmDw-0000i5-22
	for xen-devel@lists.xensource.com; Thu, 20 Sep 2012 19:15:44 +0000
Received: from [85.158.139.211:51257] by server-9.bemta-5.messagelabs.com id
	E2/99-20529-F5B6B505; Thu, 20 Sep 2012 19:15:43 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1348168541!18908144!1
X-Originating-IP: [143.182.124.21]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMjEgPT4gMjA1ODM3\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18677 invoked from network); 20 Sep 2012 19:15:42 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (143.182.124.21)
	by server-7.tower-206.messagelabs.com with SMTP;
	20 Sep 2012 19:15:42 -0000
Received: from azsmga001.ch.intel.com ([10.2.17.19])
	by azsmga101.ch.intel.com with ESMTP; 20 Sep 2012 12:15:40 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.80,455,1344236400"; d="scan'208";a="195162673"
Received: from fmsmsx104.amr.corp.intel.com ([10.19.9.35])
	by azsmga001.ch.intel.com with ESMTP; 20 Sep 2012 12:15:40 -0700
Received: from fmsmsx152.amr.corp.intel.com (10.19.17.221) by
	FMSMSX104.amr.corp.intel.com (10.19.9.35) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Thu, 20 Sep 2012 12:15:39 -0700
Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by
	fmsmsx152.amr.corp.intel.com (10.19.17.221) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Thu, 20 Sep 2012 12:15:39 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.239]) by
	SHSMSX102.ccr.corp.intel.com ([169.254.2.92]) with mapi id
	14.01.0355.002; Fri, 21 Sep 2012 03:15:37 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: Christoph Egger <Christoph.Egger@amd.com>
Thread-Topic: [PATCH 2/5] Xen/MCE: vMCE injection
Thread-Index: AQHNl0PZekObrJQCTVCsi0gKQEvFZJeTiMgg
Date: Thu, 20 Sep 2012 19:15:37 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC82923353326D5@SHSMSX101.ccr.corp.intel.com>
References: <DE8DF0795D48FD4CA783C40EC8292335330591@SHSMSX101.ccr.corp.intel.com>
	<505B34E1.6030609@amd.com>
In-Reply-To: <505B34E1.6030609@amd.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"keir@xen.org" <keir@xen.org>,
	"Ian.Campbell@citrix.com" <Ian.Campbell@citrix.com>,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH 2/5] Xen/MCE: vMCE 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

Christoph Egger wrote:
> On 09/19/12 10:03, Liu, Jinsong wrote:
> 
>> Xen/MCE: vMCE injection
>> 
>> In our test for win8 guest mce, we find a bug 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.
> 
> 
> This breaks the AMD way. The AMD way is to only inject it to vcpu0.
> I suggest to add a flag argument to inject_vmce() that says whether
> to inject to all vcpus or just vcpu0.
> Then set/clear that flag from the caller side depending on whether you
> run on Intel or AMD.
> 
> Christoph
> 

No, it didn't breaks AMD since it only called by intel_memerr_dhandler().

Thanks,
Jinsong

> 
>> 
>> Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>
>> 
>> diff -r 133664c6bfb4 xen/arch/x86/cpu/mcheck/vmce.c
>> --- a/xen/arch/x86/cpu/mcheck/vmce.c	Tue Sep 18 22:39:11 2012 +0800
>> +++ b/xen/arch/x86/cpu/mcheck/vmce.c	Tue Sep 18 23:46:38 2012 +0800
>> @@ -340,48 +340,27 @@ 
>> 
>>  int inject_vmce(struct domain *d)
>>  {
>> -    int cpu = smp_processor_id();
>> +    struct vcpu *v;
>> 
>> -    /* PV guest and HVM guest have different vMCE# injection
>> methods. */ 
>> -    if ( !test_and_set_bool(d->vcpu[0]->mce_pending) )
>> +    /* inject vMCE to all vcpus */
>> +    for_each_vcpu(d, v)
>>      {
>> -        if ( d->is_hvm )
>> +        if ( !test_and_set_bool(v->mce_pending) && +           
>> ((d->is_hvm) || +                guest_has_trap_callback(d,
>> v->vcpu_id, TRAP_machine_check)) )          { 
>> -            mce_printk(MCE_VERBOSE, "MCE: inject vMCE to HVM DOM
>> %d\n", 
>> -                       d->domain_id);
>> -            vcpu_kick(d->vcpu[0]);
>> +            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_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);
>> -            }
>> +            mce_printk(MCE_QUIET, "Fail to inject vMCE to dom%d
>> vcpu%d\n", +                       d->domain_id, v->vcpu_id);
>> +            return -1;
>>          }
>>      }
>> -    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
>> injected " 
>> -                   " to this DOM%d!\n", d->domain_id);
>> -        return -1;
>> -    }
>> +
>>      return 0;
>>  }


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 20 19:16:11 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Sep 2012 19:16:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TEmDx-0000iA-6M; Thu, 20 Sep 2012 19:15:45 +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 1TEmDw-0000i5-22
	for xen-devel@lists.xensource.com; Thu, 20 Sep 2012 19:15:44 +0000
Received: from [85.158.139.211:51257] by server-9.bemta-5.messagelabs.com id
	E2/99-20529-F5B6B505; Thu, 20 Sep 2012 19:15:43 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1348168541!18908144!1
X-Originating-IP: [143.182.124.21]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMjEgPT4gMjA1ODM3\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18677 invoked from network); 20 Sep 2012 19:15:42 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (143.182.124.21)
	by server-7.tower-206.messagelabs.com with SMTP;
	20 Sep 2012 19:15:42 -0000
Received: from azsmga001.ch.intel.com ([10.2.17.19])
	by azsmga101.ch.intel.com with ESMTP; 20 Sep 2012 12:15:40 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.80,455,1344236400"; d="scan'208";a="195162673"
Received: from fmsmsx104.amr.corp.intel.com ([10.19.9.35])
	by azsmga001.ch.intel.com with ESMTP; 20 Sep 2012 12:15:40 -0700
Received: from fmsmsx152.amr.corp.intel.com (10.19.17.221) by
	FMSMSX104.amr.corp.intel.com (10.19.9.35) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Thu, 20 Sep 2012 12:15:39 -0700
Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by
	fmsmsx152.amr.corp.intel.com (10.19.17.221) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Thu, 20 Sep 2012 12:15:39 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.239]) by
	SHSMSX102.ccr.corp.intel.com ([169.254.2.92]) with mapi id
	14.01.0355.002; Fri, 21 Sep 2012 03:15:37 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: Christoph Egger <Christoph.Egger@amd.com>
Thread-Topic: [PATCH 2/5] Xen/MCE: vMCE injection
Thread-Index: AQHNl0PZekObrJQCTVCsi0gKQEvFZJeTiMgg
Date: Thu, 20 Sep 2012 19:15:37 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC82923353326D5@SHSMSX101.ccr.corp.intel.com>
References: <DE8DF0795D48FD4CA783C40EC8292335330591@SHSMSX101.ccr.corp.intel.com>
	<505B34E1.6030609@amd.com>
In-Reply-To: <505B34E1.6030609@amd.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"keir@xen.org" <keir@xen.org>,
	"Ian.Campbell@citrix.com" <Ian.Campbell@citrix.com>,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH 2/5] Xen/MCE: vMCE 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

Christoph Egger wrote:
> On 09/19/12 10:03, Liu, Jinsong wrote:
> 
>> Xen/MCE: vMCE injection
>> 
>> In our test for win8 guest mce, we find a bug 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.
> 
> 
> This breaks the AMD way. The AMD way is to only inject it to vcpu0.
> I suggest to add a flag argument to inject_vmce() that says whether
> to inject to all vcpus or just vcpu0.
> Then set/clear that flag from the caller side depending on whether you
> run on Intel or AMD.
> 
> Christoph
> 

No, it didn't breaks AMD since it only called by intel_memerr_dhandler().

Thanks,
Jinsong

> 
>> 
>> Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>
>> 
>> diff -r 133664c6bfb4 xen/arch/x86/cpu/mcheck/vmce.c
>> --- a/xen/arch/x86/cpu/mcheck/vmce.c	Tue Sep 18 22:39:11 2012 +0800
>> +++ b/xen/arch/x86/cpu/mcheck/vmce.c	Tue Sep 18 23:46:38 2012 +0800
>> @@ -340,48 +340,27 @@ 
>> 
>>  int inject_vmce(struct domain *d)
>>  {
>> -    int cpu = smp_processor_id();
>> +    struct vcpu *v;
>> 
>> -    /* PV guest and HVM guest have different vMCE# injection
>> methods. */ 
>> -    if ( !test_and_set_bool(d->vcpu[0]->mce_pending) )
>> +    /* inject vMCE to all vcpus */
>> +    for_each_vcpu(d, v)
>>      {
>> -        if ( d->is_hvm )
>> +        if ( !test_and_set_bool(v->mce_pending) && +           
>> ((d->is_hvm) || +                guest_has_trap_callback(d,
>> v->vcpu_id, TRAP_machine_check)) )          { 
>> -            mce_printk(MCE_VERBOSE, "MCE: inject vMCE to HVM DOM
>> %d\n", 
>> -                       d->domain_id);
>> -            vcpu_kick(d->vcpu[0]);
>> +            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_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);
>> -            }
>> +            mce_printk(MCE_QUIET, "Fail to inject vMCE to dom%d
>> vcpu%d\n", +                       d->domain_id, v->vcpu_id);
>> +            return -1;
>>          }
>>      }
>> -    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
>> injected " 
>> -                   " to this DOM%d!\n", d->domain_id);
>> -        return -1;
>> -    }
>> +
>>      return 0;
>>  }


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 20 19:25:36 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Sep 2012 19:25:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TEmNC-0000rX-8r; Thu, 20 Sep 2012 19:25: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 1TEmNA-0000rS-6P
	for xen-devel@lists.xensource.com; Thu, 20 Sep 2012 19:25:16 +0000
Received: from [85.158.143.35:43746] by server-1.bemta-4.messagelabs.com id
	90/93-05684-B9D6B505; Thu, 20 Sep 2012 19:25:15 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1348169113!15936365!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTA0NTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18193 invoked from network); 20 Sep 2012 19:25:14 -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;
	20 Sep 2012 19:25:14 -0000
X-IronPort-AV: E=Sophos;i="4.80,455,1344211200"; d="scan'208";a="14672574"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Sep 2012 19:24: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.279.1; Thu, 20 Sep 2012 20:24:59 +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 1TEmMs-0000W7-Sv;
	Thu, 20 Sep 2012 19:24:58 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1TEmMs-00075J-Mk;
	Thu, 20 Sep 2012 20:24:58 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-13821-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 20 Sep 2012 20:24:58 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13821: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 13821 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13821/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-winxpsp3-vcpus1  7 windows-install     fail REGR. vs. 13819

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore            fail   like 13819
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail like 13819
 test-amd64-amd64-xl-sedf     14 guest-localmigrate/x10    fail REGR. vs. 13819
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail like 13819

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  06a0774df47c
baseline version:
 xen                  fee83ac77d8c

------------------------------------------------------------
People who touched revisions under test:
  Dan Magenheimer <dan.magenheimer@oracle.com>
  Jan Beulich <jbeulich@suse.com>
  Keir Fraser <keir@xen.org>
  Zhenzhong Duan <zhenzhong.duan@oracle.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-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-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-amd64-amd64-xl-win                                      fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
changeset:   25932:06a0774df47c
tag:         tip
user:        Jan Beulich <jbeulich@suse.com>
date:        Thu Sep 20 09:22:55 2012 +0200
    
    ACPI: move tables.c fully into .init.*
    
    The only non-init item was the space reserved for the initial tables,
    but we can as well dynamically allocate that array.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   25931:149805919569
user:        Jan Beulich <jbeulich@suse.com>
date:        Thu Sep 20 09:21:53 2012 +0200
    
    x86: tighten checks in XEN_DOMCTL_memory_mapping handler
    
    Properly checking the MFN implies knowing the physical address width
    supported by the platform, so to obtain this consistently the
    respective code gets moved out of the MTRR subdir.
    
    Btw., the model specific workaround in that code is likely unnecessary
    - I believe those CPU models don't support 64-bit mode. But I wasn't
    able to formally verify this, so I preferred to retain that code for
    now.
    
    But domctl code here also was lacking other error checks (as was,
    looking at it again from that angle) the XEN_DOMCTL_ioport_mapping one.
    Besides adding the missing checks, printing is also added for the case
    where revoking access permissions didn't work (as that may have
    implications for the host operator, e.g. wanting to not pass through
    affected devices to another guest until the one previously using them
    did actually die).
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   25930:4e93cbeac98b
user:        Jan Beulich <jbeulich@suse.com>
date:        Thu Sep 20 09:20:30 2012 +0200
    
    x86/IO-APIC: streamline level ack/end handling
    
    Rather than evaluating "ioapic_ack_new" on each invocation, and
    considering that the two methods really have almost no code in common,
    split the handlers.
    
    While at it, also move ioapic_ack_{new,forced} into .init.data
    (eliminating the single non-__init reference to the former).
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   25929:fee83ac77d8c
user:        Zhenzhong Duan <zhenzhong.duan@oracle.com>
date:        Wed Sep 19 17:38:47 2012 +0200
    
    tmem: bump pool version to 1 to fix restore issue when tmem enabled
    
    Restore fails when tmem is enabled both in hypervisor and guest. This
    is due to spec version mismatch when restoring a pool.
    
    Signed-off-by: Zhenzhong Duan <zhenzhong.duan@oracle.com>
    Acked-by: Dan Magenheimer <dan.magenheimer@oracle.com>
    Committed-by: Jan Beulich <jbeulich@suse.com>
    
    
(qemu changes not included)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 20 19:25:36 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Sep 2012 19:25:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TEmNC-0000rX-8r; Thu, 20 Sep 2012 19:25: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 1TEmNA-0000rS-6P
	for xen-devel@lists.xensource.com; Thu, 20 Sep 2012 19:25:16 +0000
Received: from [85.158.143.35:43746] by server-1.bemta-4.messagelabs.com id
	90/93-05684-B9D6B505; Thu, 20 Sep 2012 19:25:15 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1348169113!15936365!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTA0NTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18193 invoked from network); 20 Sep 2012 19:25:14 -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;
	20 Sep 2012 19:25:14 -0000
X-IronPort-AV: E=Sophos;i="4.80,455,1344211200"; d="scan'208";a="14672574"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Sep 2012 19:24: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.279.1; Thu, 20 Sep 2012 20:24:59 +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 1TEmMs-0000W7-Sv;
	Thu, 20 Sep 2012 19:24:58 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1TEmMs-00075J-Mk;
	Thu, 20 Sep 2012 20:24:58 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-13821-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 20 Sep 2012 20:24:58 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13821: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 13821 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13821/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-winxpsp3-vcpus1  7 windows-install     fail REGR. vs. 13819

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore            fail   like 13819
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail like 13819
 test-amd64-amd64-xl-sedf     14 guest-localmigrate/x10    fail REGR. vs. 13819
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail like 13819

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  06a0774df47c
baseline version:
 xen                  fee83ac77d8c

------------------------------------------------------------
People who touched revisions under test:
  Dan Magenheimer <dan.magenheimer@oracle.com>
  Jan Beulich <jbeulich@suse.com>
  Keir Fraser <keir@xen.org>
  Zhenzhong Duan <zhenzhong.duan@oracle.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-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-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-amd64-amd64-xl-win                                      fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
changeset:   25932:06a0774df47c
tag:         tip
user:        Jan Beulich <jbeulich@suse.com>
date:        Thu Sep 20 09:22:55 2012 +0200
    
    ACPI: move tables.c fully into .init.*
    
    The only non-init item was the space reserved for the initial tables,
    but we can as well dynamically allocate that array.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   25931:149805919569
user:        Jan Beulich <jbeulich@suse.com>
date:        Thu Sep 20 09:21:53 2012 +0200
    
    x86: tighten checks in XEN_DOMCTL_memory_mapping handler
    
    Properly checking the MFN implies knowing the physical address width
    supported by the platform, so to obtain this consistently the
    respective code gets moved out of the MTRR subdir.
    
    Btw., the model specific workaround in that code is likely unnecessary
    - I believe those CPU models don't support 64-bit mode. But I wasn't
    able to formally verify this, so I preferred to retain that code for
    now.
    
    But domctl code here also was lacking other error checks (as was,
    looking at it again from that angle) the XEN_DOMCTL_ioport_mapping one.
    Besides adding the missing checks, printing is also added for the case
    where revoking access permissions didn't work (as that may have
    implications for the host operator, e.g. wanting to not pass through
    affected devices to another guest until the one previously using them
    did actually die).
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   25930:4e93cbeac98b
user:        Jan Beulich <jbeulich@suse.com>
date:        Thu Sep 20 09:20:30 2012 +0200
    
    x86/IO-APIC: streamline level ack/end handling
    
    Rather than evaluating "ioapic_ack_new" on each invocation, and
    considering that the two methods really have almost no code in common,
    split the handlers.
    
    While at it, also move ioapic_ack_{new,forced} into .init.data
    (eliminating the single non-__init reference to the former).
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   25929:fee83ac77d8c
user:        Zhenzhong Duan <zhenzhong.duan@oracle.com>
date:        Wed Sep 19 17:38:47 2012 +0200
    
    tmem: bump pool version to 1 to fix restore issue when tmem enabled
    
    Restore fails when tmem is enabled both in hypervisor and guest. This
    is due to spec version mismatch when restoring a pool.
    
    Signed-off-by: Zhenzhong Duan <zhenzhong.duan@oracle.com>
    Acked-by: Dan Magenheimer <dan.magenheimer@oracle.com>
    Committed-by: Jan Beulich <jbeulich@suse.com>
    
    
(qemu changes not included)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 20 20:26:53 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Sep 2012 20:26:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TEnKO-0001Mn-7Y; Thu, 20 Sep 2012 20:26:28 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <robherring2@gmail.com>) id 1TEnKM-0001Mi-Bt
	for xen-devel@lists.xensource.com; Thu, 20 Sep 2012 20:26:26 +0000
Received: from [85.158.143.99:63953] by server-1.bemta-4.messagelabs.com id
	3D/40-05684-1FB7B505; Thu, 20 Sep 2012 20:26:25 +0000
X-Env-Sender: robherring2@gmail.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1348172783!23652467!1
X-Originating-IP: [209.85.219.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17511 invoked from network); 20 Sep 2012 20:26:24 -0000
Received: from mail-oa0-f43.google.com (HELO mail-oa0-f43.google.com)
	(209.85.219.43)
	by server-11.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Sep 2012 20:26:24 -0000
Received: by oagl10 with SMTP id l10so3616475oag.30
	for <xen-devel@lists.xensource.com>;
	Thu, 20 Sep 2012 13:26:22 -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=T/ryLdZy6afO1n/zPkIgd+/kpSrjQaBXOIZNIDJF9DA=;
	b=rQ2LEAMVXXlh8bxSgGNJ2h0fSTb9rn9aCTYUd1/aOQ7CxyjV9KLILcwRNf18Oybxmt
	cgx3SntihpvmBDN4MKPjXlsnJRd2/vYM19tFGz416BupwDxdIns5v5PAebwjOt16+pg8
	bQcFHu0q/61Ef7f3vPxI/TimwryQdMOBEP9q+NDu1CObAIYO0vqyuURFYwThJOauJWiQ
	LQpQBVnYq6Q0Qjne3/5zu9rlsC6F1oNT83ikfk9sRzmJ6QQebl+MfZT2iys4MkNEINkS
	7FjTdZs+i+HcreEmCk5lSWFemyWn9NL71sZMFuK8MmFYQHjaXWK9PrTe4pzm2jxYhHDu
	RgYA==
Received: by 10.60.29.134 with SMTP id k6mr2205992oeh.5.1348172782483;
	Thu, 20 Sep 2012 13:26:22 -0700 (PDT)
Received: from [10.10.10.90] ([173.226.190.126])
	by mx.google.com with ESMTPS id 9sm1401064obi.22.2012.09.20.13.26.20
	(version=SSLv3 cipher=OTHER); Thu, 20 Sep 2012 13:26:21 -0700 (PDT)
Message-ID: <505B7BEB.6010105@gmail.com>
Date: Thu, 20 Sep 2012 15:26:19 -0500
From: Rob Herring <robherring2@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120827 Thunderbird/15.0
MIME-Version: 1.0
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
References: <1348076658-4511-1-git-send-email-stefano.stabellini@eu.citrix.com>
In-Reply-To: <1348076658-4511-1-git-send-email-stefano.stabellini@eu.citrix.com>
Cc: xen-devel@lists.xensource.com, Ian.Campbell@citrix.com,
	Pawel Moll <pawel.moll@arm.com>, konrad.wilk@oracle.com,
	linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org
Subject: Re: [Xen-devel] [PATCH] arm: introduce a DTS for Xen unprivileged
	virtual 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 09/19/2012 12:44 PM, Stefano Stabellini wrote:
> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> CC: Pawel Moll <pawel.moll@arm.com>
> CC: linux-arm-kernel@lists.infradead.org
> ---
>  arch/arm/boot/dts/vexpress-xenvm-4.2.dts |  115 ++++++++++++++++++++++++++++++
>  arch/arm/mach-vexpress/Makefile.boot     |    3 +-
>  2 files changed, 117 insertions(+), 1 deletions(-)
>  create mode 100644 arch/arm/boot/dts/vexpress-xenvm-4.2.dts
> 
> diff --git a/arch/arm/boot/dts/vexpress-xenvm-4.2.dts b/arch/arm/boot/dts/vexpress-xenvm-4.2.dts
> new file mode 100644
> index 0000000..bfb802c
> --- /dev/null
> +++ b/arch/arm/boot/dts/vexpress-xenvm-4.2.dts
> @@ -0,0 +1,115 @@
> +/*
> + * Xen Virtual Machine for unprivileged guests
> + *
> + * Based on ARM Ltd. Versatile Express CoreTile Express (single CPU)
> + * Cortex-A15 MPCore (V2P-CA15)
> + *
> + */
> +
> +/dts-v1/;
> +
> +/include/ "skeleton.dtsi"
> +
> +/ {
> +	model = "XENVM-4.2";
> +	compatible = "xen,xenvm-4.2", "arm,vexpress";
> +	interrupt-parent = <&gic>;
> +
> +	chosen {
> +		bootargs = "earlyprintk console=hvc0 root=/dev/xvda init=/sbin/init";
> +	};
> +
> +	cpus {
> +		#address-cells = <1>;
> +		#size-cells = <0>;
> +
> +		cpu@0 {
> +			device_type = "cpu";
> +			compatible = "arm,cortex-a15";
> +			reg = <0>;
> +		};
> +	};
> +
> +	memory {
> +		device_type = "memory";
> +		reg = <0x80000000 0x08000000>;

How much guest memory can be supported here?

I would expect something like the memory size to be filled in by the
hypervisor. If so, perhaps a note on any fields hypervisor will adjust.

Rob

> +	};
> +
> +	gic: interrupt-controller@2c001000 {
> +		compatible = "arm,cortex-a9-gic";
> +		#interrupt-cells = <3>;
> +		#address-cells = <0>;
> +		interrupt-controller;
> +		reg = <0x2c001000 0x1000>,
> +		      <0x2c002000 0x100>;
> +	};
> +
> +	timer {
> +		compatible = "arm,armv7-timer";
> +		interrupts = <1 13 0xf08>,
> +			     <1 14 0xf08>,
> +			     <1 11 0xf08>,
> +			     <1 10 0xf08>;
> +	};
> +
> +	hypervisor {
> +		compatible = "xen,xen-4.2", "xen,xen";
> +		reg = <0xb0000000 0x20000>;
> +		interrupts = <1 15 0xf08>;
> +	};
> +
> +	motherboard {
> +		arm,v2m-memory-map = "rs1";
> +		ranges = <0 0 0x08000000 0x04000000>,
> +			 <1 0 0x14000000 0x04000000>,
> +			 <2 0 0x18000000 0x04000000>,
> +			 <3 0 0x1c000000 0x04000000>,
> +			 <4 0 0x0c000000 0x04000000>,
> +			 <5 0 0x10000000 0x04000000>;
> +
> +		interrupt-map-mask = <0 0 63>;
> +		interrupt-map = <0 0  0 &gic 0  0 4>,
> +				<0 0  1 &gic 0  1 4>,
> +				<0 0  2 &gic 0  2 4>,
> +				<0 0  3 &gic 0  3 4>,
> +				<0 0  4 &gic 0  4 4>,
> +				<0 0  5 &gic 0  5 4>,
> +				<0 0  6 &gic 0  6 4>,
> +				<0 0  7 &gic 0  7 4>,
> +				<0 0  8 &gic 0  8 4>,
> +				<0 0  9 &gic 0  9 4>,
> +				<0 0 10 &gic 0 10 4>,
> +				<0 0 11 &gic 0 11 4>,
> +				<0 0 12 &gic 0 12 4>,
> +				<0 0 13 &gic 0 13 4>,
> +				<0 0 14 &gic 0 14 4>,
> +				<0 0 15 &gic 0 15 4>,
> +				<0 0 16 &gic 0 16 4>,
> +				<0 0 17 &gic 0 17 4>,
> +				<0 0 18 &gic 0 18 4>,
> +				<0 0 19 &gic 0 19 4>,
> +				<0 0 20 &gic 0 20 4>,
> +				<0 0 21 &gic 0 21 4>,
> +				<0 0 22 &gic 0 22 4>,
> +				<0 0 23 &gic 0 23 4>,
> +				<0 0 24 &gic 0 24 4>,
> +				<0 0 25 &gic 0 25 4>,
> +				<0 0 26 &gic 0 26 4>,
> +				<0 0 27 &gic 0 27 4>,
> +				<0 0 28 &gic 0 28 4>,
> +				<0 0 29 &gic 0 29 4>,
> +				<0 0 30 &gic 0 30 4>,
> +				<0 0 31 &gic 0 31 4>,
> +				<0 0 32 &gic 0 32 4>,
> +				<0 0 33 &gic 0 33 4>,
> +				<0 0 34 &gic 0 34 4>,
> +				<0 0 35 &gic 0 35 4>,
> +				<0 0 36 &gic 0 36 4>,
> +				<0 0 37 &gic 0 37 4>,
> +				<0 0 38 &gic 0 38 4>,
> +				<0 0 39 &gic 0 39 4>,
> +				<0 0 40 &gic 0 40 4>,
> +				<0 0 41 &gic 0 41 4>,
> +				<0 0 42 &gic 0 42 4>;
> +	};
> +};
> diff --git a/arch/arm/mach-vexpress/Makefile.boot b/arch/arm/mach-vexpress/Makefile.boot
> index 318d308..5c633c5 100644
> --- a/arch/arm/mach-vexpress/Makefile.boot
> +++ b/arch/arm/mach-vexpress/Makefile.boot
> @@ -7,4 +7,5 @@ initrd_phys-y	:= 0x60800000
>  dtb-$(CONFIG_ARCH_VEXPRESS_DT)	+= vexpress-v2p-ca5s.dtb \
>  				   vexpress-v2p-ca9.dtb \
>  				   vexpress-v2p-ca15-tc1.dtb \
> -				   vexpress-v2p-ca15_a7.dtb
> +				   vexpress-v2p-ca15_a7.dtb \
> +				   vexpress-xenvm-4.2.dtb
> 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 20 20:26:53 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Sep 2012 20:26:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TEnKO-0001Mn-7Y; Thu, 20 Sep 2012 20:26:28 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <robherring2@gmail.com>) id 1TEnKM-0001Mi-Bt
	for xen-devel@lists.xensource.com; Thu, 20 Sep 2012 20:26:26 +0000
Received: from [85.158.143.99:63953] by server-1.bemta-4.messagelabs.com id
	3D/40-05684-1FB7B505; Thu, 20 Sep 2012 20:26:25 +0000
X-Env-Sender: robherring2@gmail.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1348172783!23652467!1
X-Originating-IP: [209.85.219.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17511 invoked from network); 20 Sep 2012 20:26:24 -0000
Received: from mail-oa0-f43.google.com (HELO mail-oa0-f43.google.com)
	(209.85.219.43)
	by server-11.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Sep 2012 20:26:24 -0000
Received: by oagl10 with SMTP id l10so3616475oag.30
	for <xen-devel@lists.xensource.com>;
	Thu, 20 Sep 2012 13:26:22 -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=T/ryLdZy6afO1n/zPkIgd+/kpSrjQaBXOIZNIDJF9DA=;
	b=rQ2LEAMVXXlh8bxSgGNJ2h0fSTb9rn9aCTYUd1/aOQ7CxyjV9KLILcwRNf18Oybxmt
	cgx3SntihpvmBDN4MKPjXlsnJRd2/vYM19tFGz416BupwDxdIns5v5PAebwjOt16+pg8
	bQcFHu0q/61Ef7f3vPxI/TimwryQdMOBEP9q+NDu1CObAIYO0vqyuURFYwThJOauJWiQ
	LQpQBVnYq6Q0Qjne3/5zu9rlsC6F1oNT83ikfk9sRzmJ6QQebl+MfZT2iys4MkNEINkS
	7FjTdZs+i+HcreEmCk5lSWFemyWn9NL71sZMFuK8MmFYQHjaXWK9PrTe4pzm2jxYhHDu
	RgYA==
Received: by 10.60.29.134 with SMTP id k6mr2205992oeh.5.1348172782483;
	Thu, 20 Sep 2012 13:26:22 -0700 (PDT)
Received: from [10.10.10.90] ([173.226.190.126])
	by mx.google.com with ESMTPS id 9sm1401064obi.22.2012.09.20.13.26.20
	(version=SSLv3 cipher=OTHER); Thu, 20 Sep 2012 13:26:21 -0700 (PDT)
Message-ID: <505B7BEB.6010105@gmail.com>
Date: Thu, 20 Sep 2012 15:26:19 -0500
From: Rob Herring <robherring2@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120827 Thunderbird/15.0
MIME-Version: 1.0
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
References: <1348076658-4511-1-git-send-email-stefano.stabellini@eu.citrix.com>
In-Reply-To: <1348076658-4511-1-git-send-email-stefano.stabellini@eu.citrix.com>
Cc: xen-devel@lists.xensource.com, Ian.Campbell@citrix.com,
	Pawel Moll <pawel.moll@arm.com>, konrad.wilk@oracle.com,
	linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org
Subject: Re: [Xen-devel] [PATCH] arm: introduce a DTS for Xen unprivileged
	virtual 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 09/19/2012 12:44 PM, Stefano Stabellini wrote:
> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> CC: Pawel Moll <pawel.moll@arm.com>
> CC: linux-arm-kernel@lists.infradead.org
> ---
>  arch/arm/boot/dts/vexpress-xenvm-4.2.dts |  115 ++++++++++++++++++++++++++++++
>  arch/arm/mach-vexpress/Makefile.boot     |    3 +-
>  2 files changed, 117 insertions(+), 1 deletions(-)
>  create mode 100644 arch/arm/boot/dts/vexpress-xenvm-4.2.dts
> 
> diff --git a/arch/arm/boot/dts/vexpress-xenvm-4.2.dts b/arch/arm/boot/dts/vexpress-xenvm-4.2.dts
> new file mode 100644
> index 0000000..bfb802c
> --- /dev/null
> +++ b/arch/arm/boot/dts/vexpress-xenvm-4.2.dts
> @@ -0,0 +1,115 @@
> +/*
> + * Xen Virtual Machine for unprivileged guests
> + *
> + * Based on ARM Ltd. Versatile Express CoreTile Express (single CPU)
> + * Cortex-A15 MPCore (V2P-CA15)
> + *
> + */
> +
> +/dts-v1/;
> +
> +/include/ "skeleton.dtsi"
> +
> +/ {
> +	model = "XENVM-4.2";
> +	compatible = "xen,xenvm-4.2", "arm,vexpress";
> +	interrupt-parent = <&gic>;
> +
> +	chosen {
> +		bootargs = "earlyprintk console=hvc0 root=/dev/xvda init=/sbin/init";
> +	};
> +
> +	cpus {
> +		#address-cells = <1>;
> +		#size-cells = <0>;
> +
> +		cpu@0 {
> +			device_type = "cpu";
> +			compatible = "arm,cortex-a15";
> +			reg = <0>;
> +		};
> +	};
> +
> +	memory {
> +		device_type = "memory";
> +		reg = <0x80000000 0x08000000>;

How much guest memory can be supported here?

I would expect something like the memory size to be filled in by the
hypervisor. If so, perhaps a note on any fields hypervisor will adjust.

Rob

> +	};
> +
> +	gic: interrupt-controller@2c001000 {
> +		compatible = "arm,cortex-a9-gic";
> +		#interrupt-cells = <3>;
> +		#address-cells = <0>;
> +		interrupt-controller;
> +		reg = <0x2c001000 0x1000>,
> +		      <0x2c002000 0x100>;
> +	};
> +
> +	timer {
> +		compatible = "arm,armv7-timer";
> +		interrupts = <1 13 0xf08>,
> +			     <1 14 0xf08>,
> +			     <1 11 0xf08>,
> +			     <1 10 0xf08>;
> +	};
> +
> +	hypervisor {
> +		compatible = "xen,xen-4.2", "xen,xen";
> +		reg = <0xb0000000 0x20000>;
> +		interrupts = <1 15 0xf08>;
> +	};
> +
> +	motherboard {
> +		arm,v2m-memory-map = "rs1";
> +		ranges = <0 0 0x08000000 0x04000000>,
> +			 <1 0 0x14000000 0x04000000>,
> +			 <2 0 0x18000000 0x04000000>,
> +			 <3 0 0x1c000000 0x04000000>,
> +			 <4 0 0x0c000000 0x04000000>,
> +			 <5 0 0x10000000 0x04000000>;
> +
> +		interrupt-map-mask = <0 0 63>;
> +		interrupt-map = <0 0  0 &gic 0  0 4>,
> +				<0 0  1 &gic 0  1 4>,
> +				<0 0  2 &gic 0  2 4>,
> +				<0 0  3 &gic 0  3 4>,
> +				<0 0  4 &gic 0  4 4>,
> +				<0 0  5 &gic 0  5 4>,
> +				<0 0  6 &gic 0  6 4>,
> +				<0 0  7 &gic 0  7 4>,
> +				<0 0  8 &gic 0  8 4>,
> +				<0 0  9 &gic 0  9 4>,
> +				<0 0 10 &gic 0 10 4>,
> +				<0 0 11 &gic 0 11 4>,
> +				<0 0 12 &gic 0 12 4>,
> +				<0 0 13 &gic 0 13 4>,
> +				<0 0 14 &gic 0 14 4>,
> +				<0 0 15 &gic 0 15 4>,
> +				<0 0 16 &gic 0 16 4>,
> +				<0 0 17 &gic 0 17 4>,
> +				<0 0 18 &gic 0 18 4>,
> +				<0 0 19 &gic 0 19 4>,
> +				<0 0 20 &gic 0 20 4>,
> +				<0 0 21 &gic 0 21 4>,
> +				<0 0 22 &gic 0 22 4>,
> +				<0 0 23 &gic 0 23 4>,
> +				<0 0 24 &gic 0 24 4>,
> +				<0 0 25 &gic 0 25 4>,
> +				<0 0 26 &gic 0 26 4>,
> +				<0 0 27 &gic 0 27 4>,
> +				<0 0 28 &gic 0 28 4>,
> +				<0 0 29 &gic 0 29 4>,
> +				<0 0 30 &gic 0 30 4>,
> +				<0 0 31 &gic 0 31 4>,
> +				<0 0 32 &gic 0 32 4>,
> +				<0 0 33 &gic 0 33 4>,
> +				<0 0 34 &gic 0 34 4>,
> +				<0 0 35 &gic 0 35 4>,
> +				<0 0 36 &gic 0 36 4>,
> +				<0 0 37 &gic 0 37 4>,
> +				<0 0 38 &gic 0 38 4>,
> +				<0 0 39 &gic 0 39 4>,
> +				<0 0 40 &gic 0 40 4>,
> +				<0 0 41 &gic 0 41 4>,
> +				<0 0 42 &gic 0 42 4>;
> +	};
> +};
> diff --git a/arch/arm/mach-vexpress/Makefile.boot b/arch/arm/mach-vexpress/Makefile.boot
> index 318d308..5c633c5 100644
> --- a/arch/arm/mach-vexpress/Makefile.boot
> +++ b/arch/arm/mach-vexpress/Makefile.boot
> @@ -7,4 +7,5 @@ initrd_phys-y	:= 0x60800000
>  dtb-$(CONFIG_ARCH_VEXPRESS_DT)	+= vexpress-v2p-ca5s.dtb \
>  				   vexpress-v2p-ca9.dtb \
>  				   vexpress-v2p-ca15-tc1.dtb \
> -				   vexpress-v2p-ca15_a7.dtb
> +				   vexpress-v2p-ca15_a7.dtb \
> +				   vexpress-xenvm-4.2.dtb
> 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 20 20:30:59 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Sep 2012 20: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 1TEnOM-0001U4-2u; Thu, 20 Sep 2012 20:30:34 +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 1TEnOK-0001Tx-L7
	for xen-devel@lists.xen.org; Thu, 20 Sep 2012 20:30:33 +0000
Received: from [85.158.138.51:55967] by server-7.bemta-3.messagelabs.com id
	A5/6B-32000-7EC7B505; Thu, 20 Sep 2012 20:30:31 +0000
X-Env-Sender: ben.guthro@gmail.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1348173028!12705292!1
X-Originating-IP: [209.85.223.173]
X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE,
	RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11590 invoked from network); 20 Sep 2012 20:30:30 -0000
Received: from mail-ie0-f173.google.com (HELO mail-ie0-f173.google.com)
	(209.85.223.173)
	by server-13.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Sep 2012 20:30:30 -0000
Received: by iebc10 with SMTP id c10so5267439ieb.32
	for <xen-devel@lists.xen.org>; Thu, 20 Sep 2012 13:30:28 -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=fY1Gi8GLzujFlyKzXtUimHjHVs1arbiO3WjtUD8tdqM=;
	b=AeKnSsYOTGuCsbw3OmFxt+SwJBDBSrJe/VzrxZkfFWmolCYxNtHMd5frxdu32zjU6K
	vJ0Hwkm/PwtuGaNV5WprV2m6kxKIa5E6PfmzTfInMe+xMGmDRgg3cGrBHZn+ZM/p15+P
	b2NFoT97yxsJ0pTsPALbJ+VeekZch8nsLHFZe5VtMxHB1IEWfnZafd2f7WeBmBPA9tYy
	mfD7+gZyz9b/22n6Iaimx4zpDjdB1/KS/xBZYYZZHdxqSRxXRgqIGlmkVgUWbG/XImMB
	dCQWchLWfCt+psH8bCBgcc8FfZYtvbMskmuw3z++YK4kurtZ/AFY4nANlF24HtLgqttX
	hNkg==
MIME-Version: 1.0
Received: by 10.50.106.233 with SMTP id gx9mr2764737igb.49.1348173028008; Thu,
	20 Sep 2012 13:30:28 -0700 (PDT)
Received: by 10.64.55.132 with HTTP; Thu, 20 Sep 2012 13:30:27 -0700 (PDT)
In-Reply-To: <CAOvdn6VF+1KP0EkzwkoAEoc=B2bcLUWteOM8HmN-cj_YosN-pw@mail.gmail.com>
References: <CAOvdn6Xn1ZnontBO0KoJE9hgBsW-a1rR2EhWYEpgbbrELkXZNw@mail.gmail.com>
	<CC80728B.3F362%keir.xen@gmail.com>
	<505AE9DB020000780009C813@nat28.tlf.novell.com>
	<CAOvdn6VF+1KP0EkzwkoAEoc=B2bcLUWteOM8HmN-cj_YosN-pw@mail.gmail.com>
Date: Thu, 20 Sep 2012 16:30:27 -0400
X-Google-Sender-Auth: SL8-m2GdFYe7IPHzK7Gy065y6FY
Message-ID: <CAOvdn6XFy_Teo0x8rBYvY1j+=ZEDAeE4bZ359nVOtgUyb=ZJig@mail.gmail.com>
From: Ben Guthro <ben@guthro.net>
To: Jan Beulich <JBeulich@suse.com>
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Keir Fraser <keir.xen@gmail.com>, john.baboval@citrix.com,
	Thomas Goetz <thomas.goetz@citrix.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen4.2 S3 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: multipart/mixed; boundary="===============7129929938763769654=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============7129929938763769654==
Content-Type: multipart/alternative; boundary=e89a8f2343b36e21f804ca27fe19

--e89a8f2343b36e21f804ca27fe19
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

On Thu, Sep 20, 2012 at 8:56 AM, Ben Guthro <ben@guthro.net> wrote:

> It appears __cpu_disable() is not getting reached at all, for CPU1
>
>
I was incorrect about this, after messing around with various serial
configs to properly get all output.

I have traced this through to verify that the sequence in question, does,
in fact seem to be getting executed.


disable_nonboot_cpus()
cpu_down()
__cpu_disable()
play_dead()
cpu_exit_clear()
cpu_uninit()
__cpu_die()
do_suspend_lowlevel()

I also enabled the printk's in smpboot.c


[   32.145824] ACPI: Preparing to enter system sleep state S3
[   32.600118] PM: Saving platform NVS memory
[   32.671666] Disabling non-boot CPUs ...
(XEN) Preparing system for ACPI S3 state.
(XEN) Disabling non-boot CPUs ...
(XEN) Bringing CPU1 down
(XEN) Disabling CPU1
(XEN) Disabled CPU1
(XEN) play_dead: CPU1
(XEN) cpu_exit_clear: CPU1
(XEN) cpu_uninit: CPU1
(XEN) CPU1 dead
(XEN) Entering ACPI S3 state.
(XEN) Finishing wakeup from ACPI S3 state.
(XEN) Enabling non-boot CPUs  ...
(XEN) Bringing CPU1 up
(XEN) Setting warm reset code and vector.
(XEN) Asserting INIT.
(XEN) Waiting for send to finish...
(XEN) +Deasserting INIT.
(XEN) Waiting for send to finish...
(XEN) +#startup loops: 2.
(XEN) Sending STARTUP #1.
(XEN) After apic_write.
(XEN) CPU#1 already initialized!
(XEN) Startup point 1.
(XEN) Waiting for send to finish...
(XEN) +Sending STARTUP #2.
(XEN) After apic_write.
(XEN) Startup point 1.
(XEN) Waiting for send to finish...
(XEN) +After Startup.
(XEN) After Callout 1.
(XEN) Stuck ??
(XEN) cpu_exit_clear: CPU1
(XEN) cpu_uninit: CPU1
(XEN) __cpu_up - do_boot_cpu error
(XEN) cpu_up CPU1 CPU not up
(XEN) cpu_up CPU1 fail
(XEN) Error taking CPU1 up: -5
[   32.780055] ACPI: Low-level resume complete
[   32.780055] PM: Restoring platform NVS memory
[   32.780055] Enabling non-boot CPUs ...

then it crashes.

It seems that it is always falling through into the "else" clause of
the do_boot_cpu() function when attempting to bring it back up, seemingly
stuck in CPU_STATE_CALLOUT


Any ideas as to what might be causing it to get stuck in that state?






> I put a cpu id conditional BUG() call in there, to verify - and while it
> is reached when using
> xen-hptool cpu-offline 1
> It never seems to be reached from the S3 path.
>
>
> What is the expected call chain to get into this code during S3?
>
>
> On Thu, Sep 20, 2012 at 4:03 AM, Jan Beulich <JBeulich@suse.com> wrote:
>
>> >>> On 20.09.12 at 08:13, Keir Fraser <keir.xen@gmail.com> wrote:
>> > CPU#1 got stuck in loop in cpu_init() as it appears to be =8Calready
>> > initialised=B9 in cpu_initialized bitmap. CPU#0 detects it is stuck an=
d
>> > carries on, but the resume code assumes all CPUs are brought back
>> online and
>> > crashes later.
>>
>> So this would suggest play_dead() (-> cpu_exit_clear() ->
>> cpu_uninit()) not getting reached during the suspend cycle.
>> That should be fairly easy to verify, as the serial console
>> ought to still work when the secondary CPUs get offlined.
>>
>> That might imply cpumask_clear_cpu(cpu, &cpu_online_map)
>> not getting reached in __cpu_disable(), which would be in line
>> with the observation that none of the logs provided so far
>> showed anything being done by fixup_irqs() (called right
>> after clearing the online bit).
>>
>> Jan
>>
>
>

--e89a8f2343b36e21f804ca27fe19
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

<br><div class=3D"gmail_quote">On Thu, Sep 20, 2012 at 8:56 AM, Ben Guthro =
<span dir=3D"ltr">&lt;<a href=3D"mailto:ben@guthro.net" target=3D"_blank">b=
en@guthro.net</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" st=
yle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">



It appears __cpu_disable() is not getting reached at all, for CPU1<div><br>=
</div></blockquote><div><br></div><div>I was incorrect about this, after me=
ssing around with various serial configs to properly get all output.</div>


<div><br></div><div>I have traced this through to verify that the sequence =
in question, does, in fact seem to be getting executed.</div><div><br></div=
><div><br></div><div>disable_nonboot_cpus()</div><div>cpu_down()=A0</div>

<div>__cpu_disable()=A0</div><div>play_dead()</div><div>cpu_exit_clear()</d=
iv>
<div>cpu_uninit()</div><div>__cpu_die()</div><div>do_suspend_lowlevel()</di=
v><div><br></div><div>I also enabled the printk&#39;s in smpboot.c</div><di=
v><br></div><div><br></div><div><div>[ =A0 32.145824] ACPI: Preparing to en=
ter system sleep state S3</div>

<div>[ =A0 32.600118] PM: Saving platform NVS memory</div><div>[ =A0 32.671=
666] Disabling non-boot CPUs ...</div><div>(XEN) Preparing system for ACPI =
S3 state.</div><div>(XEN) Disabling non-boot CPUs ...</div><div>(XEN) Bring=
ing CPU1 down</div>

<div>(XEN) Disabling CPU1</div><div>(XEN) Disabled CPU1</div><div>(XEN) pla=
y_dead: CPU1</div><div>(XEN) cpu_exit_clear: CPU1</div><div>(XEN) cpu_unini=
t: CPU1</div><div>(XEN) CPU1 dead</div><div>(XEN) Entering ACPI S3 state.</=
div>

<div>(XEN) Finishing wakeup from ACPI S3 state.</div><div>(XEN) Enabling no=
n-boot CPUs =A0...</div><div>(XEN) Bringing CPU1 up</div><div>(XEN) Setting=
 warm reset code and vector.</div><div>(XEN) Asserting INIT.</div><div>(XEN=
) Waiting for send to finish...</div>

<div>(XEN) +Deasserting INIT.</div><div>(XEN) Waiting for send to finish...=
</div><div>(XEN) +#startup loops: 2.</div><div>(XEN) Sending STARTUP #1.</d=
iv><div>(XEN) After apic_write.</div><div>(XEN) CPU#1 already initialized!<=
/div>

<div>(XEN) Startup point 1.</div><div>(XEN) Waiting for send to finish...</=
div><div>(XEN) +Sending STARTUP #2.</div><div>(XEN) After apic_write.</div>=
<div>(XEN) Startup point 1.</div><div>(XEN) Waiting for send to finish...</=
div>

<div>(XEN) +After Startup.</div><div>(XEN) After Callout 1.</div><div>(XEN)=
 Stuck ??</div><div>(XEN) cpu_exit_clear: CPU1</div><div>(XEN) cpu_uninit: =
CPU1</div><div>(XEN) __cpu_up - do_boot_cpu error</div><div>(XEN) cpu_up CP=
U1 CPU not up</div>

<div>(XEN) cpu_up CPU1 fail</div><div>(XEN) Error taking CPU1 up: -5</div><=
div>[ =A0 32.780055] ACPI: Low-level resume complete</div><div>[ =A0 32.780=
055] PM: Restoring platform NVS memory</div><div>[ =A0 32.780055] Enabling =
non-boot CPUs ...</div>

<div><br></div></div><div>then it crashes.</div><div><br></div><div>It seem=
s that it is always falling through into the &quot;else&quot; clause of the=
=A0do_boot_cpu() function when attempting to bring it back up, seemingly st=
uck in=A0CPU_STATE_CALLOUT</div>
<div><br></div><div><br></div><div>Any ideas as to what might be causing it=
 to get stuck in that state?</div><div>
<br></div><div><br></div>
<div><br></div><div><br></div><div>=A0</div><blockquote class=3D"gmail_quot=
e" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">=
<div></div><div>I put a cpu id conditional BUG() call in there, to verify -=
 and while it is reached when using=A0</div>



<div>xen-hptool cpu-offline 1</div>

<div>It never seems to be reached from the S3 path.</div><div><br></div><di=
v><br></div><div>What is the expected call chain to get into this code duri=
ng S3?</div><div><div><div><br><br><div class=3D"gmail_quote">
On Thu, Sep 20, 2012 at 4:03 AM, 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>

<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">&gt;&gt;&gt; On 20.09.12 at 08:13, Keir Fras=
er &lt;<a href=3D"mailto:keir.xen@gmail.com" target=3D"_blank">keir.xen@gma=
il.com</a>&gt; wrote:<br>






&gt; CPU#1 got stuck in loop in cpu_init() as it appears to be =8Calready<b=
r>
<div>&gt; initialised=B9 in cpu_initialized bitmap. CPU#0 detects it is stu=
ck and<br>
&gt; carries on, but the resume code assumes all CPUs are brought back onli=
ne and<br>
&gt; crashes later.<br>
<br>
</div>So this would suggest play_dead() (-&gt; cpu_exit_clear() -&gt;<br>
cpu_uninit()) not getting reached during the suspend cycle.<br>
That should be fairly easy to verify, as the serial console<br>
ought to still work when the secondary CPUs get offlined.<br>
<br>
That might imply cpumask_clear_cpu(cpu, &amp;cpu_online_map)<br>
not getting reached in __cpu_disable(), which would be in line<br>
with the observation that none of the logs provided so far<br>
showed anything being done by fixup_irqs() (called right<br>
after clearing the online bit).<br>
<span><font color=3D"#888888"><br>
Jan<br>
</font></span></blockquote></div><br></div>
</div></div></blockquote></div><br>

--e89a8f2343b36e21f804ca27fe19--


--===============7129929938763769654==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============7129929938763769654==--


From xen-devel-bounces@lists.xen.org Thu Sep 20 20:30:59 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Sep 2012 20: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 1TEnOM-0001U4-2u; Thu, 20 Sep 2012 20:30:34 +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 1TEnOK-0001Tx-L7
	for xen-devel@lists.xen.org; Thu, 20 Sep 2012 20:30:33 +0000
Received: from [85.158.138.51:55967] by server-7.bemta-3.messagelabs.com id
	A5/6B-32000-7EC7B505; Thu, 20 Sep 2012 20:30:31 +0000
X-Env-Sender: ben.guthro@gmail.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1348173028!12705292!1
X-Originating-IP: [209.85.223.173]
X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE,
	RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11590 invoked from network); 20 Sep 2012 20:30:30 -0000
Received: from mail-ie0-f173.google.com (HELO mail-ie0-f173.google.com)
	(209.85.223.173)
	by server-13.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Sep 2012 20:30:30 -0000
Received: by iebc10 with SMTP id c10so5267439ieb.32
	for <xen-devel@lists.xen.org>; Thu, 20 Sep 2012 13:30:28 -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=fY1Gi8GLzujFlyKzXtUimHjHVs1arbiO3WjtUD8tdqM=;
	b=AeKnSsYOTGuCsbw3OmFxt+SwJBDBSrJe/VzrxZkfFWmolCYxNtHMd5frxdu32zjU6K
	vJ0Hwkm/PwtuGaNV5WprV2m6kxKIa5E6PfmzTfInMe+xMGmDRgg3cGrBHZn+ZM/p15+P
	b2NFoT97yxsJ0pTsPALbJ+VeekZch8nsLHFZe5VtMxHB1IEWfnZafd2f7WeBmBPA9tYy
	mfD7+gZyz9b/22n6Iaimx4zpDjdB1/KS/xBZYYZZHdxqSRxXRgqIGlmkVgUWbG/XImMB
	dCQWchLWfCt+psH8bCBgcc8FfZYtvbMskmuw3z++YK4kurtZ/AFY4nANlF24HtLgqttX
	hNkg==
MIME-Version: 1.0
Received: by 10.50.106.233 with SMTP id gx9mr2764737igb.49.1348173028008; Thu,
	20 Sep 2012 13:30:28 -0700 (PDT)
Received: by 10.64.55.132 with HTTP; Thu, 20 Sep 2012 13:30:27 -0700 (PDT)
In-Reply-To: <CAOvdn6VF+1KP0EkzwkoAEoc=B2bcLUWteOM8HmN-cj_YosN-pw@mail.gmail.com>
References: <CAOvdn6Xn1ZnontBO0KoJE9hgBsW-a1rR2EhWYEpgbbrELkXZNw@mail.gmail.com>
	<CC80728B.3F362%keir.xen@gmail.com>
	<505AE9DB020000780009C813@nat28.tlf.novell.com>
	<CAOvdn6VF+1KP0EkzwkoAEoc=B2bcLUWteOM8HmN-cj_YosN-pw@mail.gmail.com>
Date: Thu, 20 Sep 2012 16:30:27 -0400
X-Google-Sender-Auth: SL8-m2GdFYe7IPHzK7Gy065y6FY
Message-ID: <CAOvdn6XFy_Teo0x8rBYvY1j+=ZEDAeE4bZ359nVOtgUyb=ZJig@mail.gmail.com>
From: Ben Guthro <ben@guthro.net>
To: Jan Beulich <JBeulich@suse.com>
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Keir Fraser <keir.xen@gmail.com>, john.baboval@citrix.com,
	Thomas Goetz <thomas.goetz@citrix.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen4.2 S3 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: multipart/mixed; boundary="===============7129929938763769654=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============7129929938763769654==
Content-Type: multipart/alternative; boundary=e89a8f2343b36e21f804ca27fe19

--e89a8f2343b36e21f804ca27fe19
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

On Thu, Sep 20, 2012 at 8:56 AM, Ben Guthro <ben@guthro.net> wrote:

> It appears __cpu_disable() is not getting reached at all, for CPU1
>
>
I was incorrect about this, after messing around with various serial
configs to properly get all output.

I have traced this through to verify that the sequence in question, does,
in fact seem to be getting executed.


disable_nonboot_cpus()
cpu_down()
__cpu_disable()
play_dead()
cpu_exit_clear()
cpu_uninit()
__cpu_die()
do_suspend_lowlevel()

I also enabled the printk's in smpboot.c


[   32.145824] ACPI: Preparing to enter system sleep state S3
[   32.600118] PM: Saving platform NVS memory
[   32.671666] Disabling non-boot CPUs ...
(XEN) Preparing system for ACPI S3 state.
(XEN) Disabling non-boot CPUs ...
(XEN) Bringing CPU1 down
(XEN) Disabling CPU1
(XEN) Disabled CPU1
(XEN) play_dead: CPU1
(XEN) cpu_exit_clear: CPU1
(XEN) cpu_uninit: CPU1
(XEN) CPU1 dead
(XEN) Entering ACPI S3 state.
(XEN) Finishing wakeup from ACPI S3 state.
(XEN) Enabling non-boot CPUs  ...
(XEN) Bringing CPU1 up
(XEN) Setting warm reset code and vector.
(XEN) Asserting INIT.
(XEN) Waiting for send to finish...
(XEN) +Deasserting INIT.
(XEN) Waiting for send to finish...
(XEN) +#startup loops: 2.
(XEN) Sending STARTUP #1.
(XEN) After apic_write.
(XEN) CPU#1 already initialized!
(XEN) Startup point 1.
(XEN) Waiting for send to finish...
(XEN) +Sending STARTUP #2.
(XEN) After apic_write.
(XEN) Startup point 1.
(XEN) Waiting for send to finish...
(XEN) +After Startup.
(XEN) After Callout 1.
(XEN) Stuck ??
(XEN) cpu_exit_clear: CPU1
(XEN) cpu_uninit: CPU1
(XEN) __cpu_up - do_boot_cpu error
(XEN) cpu_up CPU1 CPU not up
(XEN) cpu_up CPU1 fail
(XEN) Error taking CPU1 up: -5
[   32.780055] ACPI: Low-level resume complete
[   32.780055] PM: Restoring platform NVS memory
[   32.780055] Enabling non-boot CPUs ...

then it crashes.

It seems that it is always falling through into the "else" clause of
the do_boot_cpu() function when attempting to bring it back up, seemingly
stuck in CPU_STATE_CALLOUT


Any ideas as to what might be causing it to get stuck in that state?






> I put a cpu id conditional BUG() call in there, to verify - and while it
> is reached when using
> xen-hptool cpu-offline 1
> It never seems to be reached from the S3 path.
>
>
> What is the expected call chain to get into this code during S3?
>
>
> On Thu, Sep 20, 2012 at 4:03 AM, Jan Beulich <JBeulich@suse.com> wrote:
>
>> >>> On 20.09.12 at 08:13, Keir Fraser <keir.xen@gmail.com> wrote:
>> > CPU#1 got stuck in loop in cpu_init() as it appears to be =8Calready
>> > initialised=B9 in cpu_initialized bitmap. CPU#0 detects it is stuck an=
d
>> > carries on, but the resume code assumes all CPUs are brought back
>> online and
>> > crashes later.
>>
>> So this would suggest play_dead() (-> cpu_exit_clear() ->
>> cpu_uninit()) not getting reached during the suspend cycle.
>> That should be fairly easy to verify, as the serial console
>> ought to still work when the secondary CPUs get offlined.
>>
>> That might imply cpumask_clear_cpu(cpu, &cpu_online_map)
>> not getting reached in __cpu_disable(), which would be in line
>> with the observation that none of the logs provided so far
>> showed anything being done by fixup_irqs() (called right
>> after clearing the online bit).
>>
>> Jan
>>
>
>

--e89a8f2343b36e21f804ca27fe19
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

<br><div class=3D"gmail_quote">On Thu, Sep 20, 2012 at 8:56 AM, Ben Guthro =
<span dir=3D"ltr">&lt;<a href=3D"mailto:ben@guthro.net" target=3D"_blank">b=
en@guthro.net</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" st=
yle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">



It appears __cpu_disable() is not getting reached at all, for CPU1<div><br>=
</div></blockquote><div><br></div><div>I was incorrect about this, after me=
ssing around with various serial configs to properly get all output.</div>


<div><br></div><div>I have traced this through to verify that the sequence =
in question, does, in fact seem to be getting executed.</div><div><br></div=
><div><br></div><div>disable_nonboot_cpus()</div><div>cpu_down()=A0</div>

<div>__cpu_disable()=A0</div><div>play_dead()</div><div>cpu_exit_clear()</d=
iv>
<div>cpu_uninit()</div><div>__cpu_die()</div><div>do_suspend_lowlevel()</di=
v><div><br></div><div>I also enabled the printk&#39;s in smpboot.c</div><di=
v><br></div><div><br></div><div><div>[ =A0 32.145824] ACPI: Preparing to en=
ter system sleep state S3</div>

<div>[ =A0 32.600118] PM: Saving platform NVS memory</div><div>[ =A0 32.671=
666] Disabling non-boot CPUs ...</div><div>(XEN) Preparing system for ACPI =
S3 state.</div><div>(XEN) Disabling non-boot CPUs ...</div><div>(XEN) Bring=
ing CPU1 down</div>

<div>(XEN) Disabling CPU1</div><div>(XEN) Disabled CPU1</div><div>(XEN) pla=
y_dead: CPU1</div><div>(XEN) cpu_exit_clear: CPU1</div><div>(XEN) cpu_unini=
t: CPU1</div><div>(XEN) CPU1 dead</div><div>(XEN) Entering ACPI S3 state.</=
div>

<div>(XEN) Finishing wakeup from ACPI S3 state.</div><div>(XEN) Enabling no=
n-boot CPUs =A0...</div><div>(XEN) Bringing CPU1 up</div><div>(XEN) Setting=
 warm reset code and vector.</div><div>(XEN) Asserting INIT.</div><div>(XEN=
) Waiting for send to finish...</div>

<div>(XEN) +Deasserting INIT.</div><div>(XEN) Waiting for send to finish...=
</div><div>(XEN) +#startup loops: 2.</div><div>(XEN) Sending STARTUP #1.</d=
iv><div>(XEN) After apic_write.</div><div>(XEN) CPU#1 already initialized!<=
/div>

<div>(XEN) Startup point 1.</div><div>(XEN) Waiting for send to finish...</=
div><div>(XEN) +Sending STARTUP #2.</div><div>(XEN) After apic_write.</div>=
<div>(XEN) Startup point 1.</div><div>(XEN) Waiting for send to finish...</=
div>

<div>(XEN) +After Startup.</div><div>(XEN) After Callout 1.</div><div>(XEN)=
 Stuck ??</div><div>(XEN) cpu_exit_clear: CPU1</div><div>(XEN) cpu_uninit: =
CPU1</div><div>(XEN) __cpu_up - do_boot_cpu error</div><div>(XEN) cpu_up CP=
U1 CPU not up</div>

<div>(XEN) cpu_up CPU1 fail</div><div>(XEN) Error taking CPU1 up: -5</div><=
div>[ =A0 32.780055] ACPI: Low-level resume complete</div><div>[ =A0 32.780=
055] PM: Restoring platform NVS memory</div><div>[ =A0 32.780055] Enabling =
non-boot CPUs ...</div>

<div><br></div></div><div>then it crashes.</div><div><br></div><div>It seem=
s that it is always falling through into the &quot;else&quot; clause of the=
=A0do_boot_cpu() function when attempting to bring it back up, seemingly st=
uck in=A0CPU_STATE_CALLOUT</div>
<div><br></div><div><br></div><div>Any ideas as to what might be causing it=
 to get stuck in that state?</div><div>
<br></div><div><br></div>
<div><br></div><div><br></div><div>=A0</div><blockquote class=3D"gmail_quot=
e" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">=
<div></div><div>I put a cpu id conditional BUG() call in there, to verify -=
 and while it is reached when using=A0</div>



<div>xen-hptool cpu-offline 1</div>

<div>It never seems to be reached from the S3 path.</div><div><br></div><di=
v><br></div><div>What is the expected call chain to get into this code duri=
ng S3?</div><div><div><div><br><br><div class=3D"gmail_quote">
On Thu, Sep 20, 2012 at 4:03 AM, 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>

<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">&gt;&gt;&gt; On 20.09.12 at 08:13, Keir Fras=
er &lt;<a href=3D"mailto:keir.xen@gmail.com" target=3D"_blank">keir.xen@gma=
il.com</a>&gt; wrote:<br>






&gt; CPU#1 got stuck in loop in cpu_init() as it appears to be =8Calready<b=
r>
<div>&gt; initialised=B9 in cpu_initialized bitmap. CPU#0 detects it is stu=
ck and<br>
&gt; carries on, but the resume code assumes all CPUs are brought back onli=
ne and<br>
&gt; crashes later.<br>
<br>
</div>So this would suggest play_dead() (-&gt; cpu_exit_clear() -&gt;<br>
cpu_uninit()) not getting reached during the suspend cycle.<br>
That should be fairly easy to verify, as the serial console<br>
ought to still work when the secondary CPUs get offlined.<br>
<br>
That might imply cpumask_clear_cpu(cpu, &amp;cpu_online_map)<br>
not getting reached in __cpu_disable(), which would be in line<br>
with the observation that none of the logs provided so far<br>
showed anything being done by fixup_irqs() (called right<br>
after clearing the online bit).<br>
<span><font color=3D"#888888"><br>
Jan<br>
</font></span></blockquote></div><br></div>
</div></div></blockquote></div><br>

--e89a8f2343b36e21f804ca27fe19--


--===============7129929938763769654==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============7129929938763769654==--


From xen-devel-bounces@lists.xen.org Thu Sep 20 21:21:19 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Sep 2012 21:21:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TEoB2-0002Ba-O6; Thu, 20 Sep 2012 21:20:52 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jfehlig@suse.com>) id 1TEoB1-0002BR-1K
	for xen-devel@lists.xen.org; Thu, 20 Sep 2012 21:20:51 +0000
Received: from [85.158.143.99:46150] by server-3.bemta-4.messagelabs.com id
	70/3E-10986-2B88B505; Thu, 20 Sep 2012 21:20:50 +0000
X-Env-Sender: jfehlig@suse.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1348176047!19946464!1
X-Originating-IP: [137.65.250.26]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13735 invoked from network); 20 Sep 2012 21:20:49 -0000
Received: from victor.provo.novell.com (HELO victor.provo.novell.com)
	(137.65.250.26)
	by server-16.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 20 Sep 2012 21:20:49 -0000
Received: from linux-0v7v.site (prv-ext-foundry1int.gns.novell.com
	[137.65.251.240])
	by victor.provo.novell.com with ESMTP (TLS encrypted);
	Thu, 20 Sep 2012 15:20:35 -0600
Message-ID: <505B88A1.1070701@suse.com>
Date: Thu, 20 Sep 2012 15:20:33 -0600
From: Jim Fehlig <jfehlig@suse.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120825 Thunderbird/15.0
MIME-Version: 1.0
To: Philipp Hahn <hahn@univention.de>
References: <CAFLBxZYtmJ_bKFb90r45=C4Pq1-oe5Fy=eygSsQf4BcGj3EqGA@mail.gmail.com>
	<201209191918.35305.hahn@univention.de>
	<CAFLBxZZko72sMVPr9LEyea7E-tNx74qCvRoxqPZ-eWbvhvctgQ@mail.gmail.com>
	<201209201340.52218.hahn@univention.de>
In-Reply-To: <201209201340.52218.hahn@univention.de>
Cc: George Dunlap <George.Dunlap@eu.citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Xen 4.3 development 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-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Philipp Hahn wrote:
> Hello George,
>
> Am Donnerstag 20 September 2012 12:24:39 schrieb George Dunlap:
>> On Wed, Sep 19, 2012 at 6:18 PM, Philipp Hahn <hahn@univention.de> wrote:
>>> On Wednesday 19 September 2012 18:58:02 George Dunlap wrote:
>>>> * libvirt integration
> ...
>>> Libvirt already has a comparison matrix at
>>> <http://libvirt.org/hvsupport.html>. That file is actually generated from
>>> by docs/hvsupport.pl by looking at the implemented functions.
>> Ah, very interesting -- so "libxl" is the one we particularly care
>> about.  "Xen" is presumably "xm"?  Would KVM fall under "qemu"?
> Yes, that's all correct.
> The current "Xen" implementation is a mixture of Xend + direct xenstore
> accress + direct hypervisor access + inotify monitor on xm files.
>
>> I guess the next step would be for someone to go through and identify
>> user-level features that would be enabled by the various functions, so
>> that we can figure out which functions are important to us.
> Top on my wish list would be virDomainMigrate*, because migration is available
> with the old Xend driver, but not with the newer libxl.
> It would probably help alot, if first those things already available via the
> old Xend would be added, since this would allow libvirt to deprecate the Xend
> part there as well.

Chun Yan Liu was working on a patch to implement migration in the libvirt libxl 
driver, but she wasn't able to finish tidying the patch before departing on 
maternity leave.  She recently returned to work and I'd expect a refreshed patch 
soon - after working through her backlog.

But why is libvirt integration listed as a Xen 4.3 feature?  AFAIK, all of this 
work is in libvirt and really doesn't have much to do with the release of 4.3.

Cheers,
Jim


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 20 21:21:19 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Sep 2012 21:21:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TEoB2-0002Ba-O6; Thu, 20 Sep 2012 21:20:52 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jfehlig@suse.com>) id 1TEoB1-0002BR-1K
	for xen-devel@lists.xen.org; Thu, 20 Sep 2012 21:20:51 +0000
Received: from [85.158.143.99:46150] by server-3.bemta-4.messagelabs.com id
	70/3E-10986-2B88B505; Thu, 20 Sep 2012 21:20:50 +0000
X-Env-Sender: jfehlig@suse.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1348176047!19946464!1
X-Originating-IP: [137.65.250.26]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13735 invoked from network); 20 Sep 2012 21:20:49 -0000
Received: from victor.provo.novell.com (HELO victor.provo.novell.com)
	(137.65.250.26)
	by server-16.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 20 Sep 2012 21:20:49 -0000
Received: from linux-0v7v.site (prv-ext-foundry1int.gns.novell.com
	[137.65.251.240])
	by victor.provo.novell.com with ESMTP (TLS encrypted);
	Thu, 20 Sep 2012 15:20:35 -0600
Message-ID: <505B88A1.1070701@suse.com>
Date: Thu, 20 Sep 2012 15:20:33 -0600
From: Jim Fehlig <jfehlig@suse.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120825 Thunderbird/15.0
MIME-Version: 1.0
To: Philipp Hahn <hahn@univention.de>
References: <CAFLBxZYtmJ_bKFb90r45=C4Pq1-oe5Fy=eygSsQf4BcGj3EqGA@mail.gmail.com>
	<201209191918.35305.hahn@univention.de>
	<CAFLBxZZko72sMVPr9LEyea7E-tNx74qCvRoxqPZ-eWbvhvctgQ@mail.gmail.com>
	<201209201340.52218.hahn@univention.de>
In-Reply-To: <201209201340.52218.hahn@univention.de>
Cc: George Dunlap <George.Dunlap@eu.citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Xen 4.3 development 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-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Philipp Hahn wrote:
> Hello George,
>
> Am Donnerstag 20 September 2012 12:24:39 schrieb George Dunlap:
>> On Wed, Sep 19, 2012 at 6:18 PM, Philipp Hahn <hahn@univention.de> wrote:
>>> On Wednesday 19 September 2012 18:58:02 George Dunlap wrote:
>>>> * libvirt integration
> ...
>>> Libvirt already has a comparison matrix at
>>> <http://libvirt.org/hvsupport.html>. That file is actually generated from
>>> by docs/hvsupport.pl by looking at the implemented functions.
>> Ah, very interesting -- so "libxl" is the one we particularly care
>> about.  "Xen" is presumably "xm"?  Would KVM fall under "qemu"?
> Yes, that's all correct.
> The current "Xen" implementation is a mixture of Xend + direct xenstore
> accress + direct hypervisor access + inotify monitor on xm files.
>
>> I guess the next step would be for someone to go through and identify
>> user-level features that would be enabled by the various functions, so
>> that we can figure out which functions are important to us.
> Top on my wish list would be virDomainMigrate*, because migration is available
> with the old Xend driver, but not with the newer libxl.
> It would probably help alot, if first those things already available via the
> old Xend would be added, since this would allow libvirt to deprecate the Xend
> part there as well.

Chun Yan Liu was working on a patch to implement migration in the libvirt libxl 
driver, but she wasn't able to finish tidying the patch before departing on 
maternity leave.  She recently returned to work and I'd expect a refreshed patch 
soon - after working through her backlog.

But why is libvirt integration listed as a Xen 4.3 feature?  AFAIK, all of this 
work is in libvirt and really doesn't have much to do with the release of 4.3.

Cheers,
Jim


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 20 21:24:42 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Sep 2012 21: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 1TEoEP-0002KX-C2; Thu, 20 Sep 2012 21:24:21 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1TEoEN-0002KP-Al
	for xen-devel@lists.xen.org; Thu, 20 Sep 2012 21:24:19 +0000
Received: from [85.158.138.51:65427] by server-7.bemta-3.messagelabs.com id
	BB/F9-32000-2898B505; Thu, 20 Sep 2012 21:24:18 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1348176255!29596458!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzUzNjM5\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19849 invoked from network); 20 Sep 2012 21:24:17 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-15.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 20 Sep 2012 21:24:17 -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 q8KLOB8D014234
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 20 Sep 2012 21:24:12 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
	q8KLOAGN002277
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 20 Sep 2012 21:24:11 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
	q8KLOAoi032026; Thu, 20 Sep 2012 16:24:10 -0500
Received: from konrad-lan.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 20 Sep 2012 14:24:10 -0700
Date: Thu, 20 Sep 2012 17:24:07 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Oliver Chick <oliver.chick@citrix.com>
Message-ID: <20120920212407.GD27312@konrad-lan.dumpdata.com>
References: <1348051887-21885-1-git-send-email-oliver.chick@citrix.com>
	<505AF126.2050806@citrix.com>
	<1348140637.24539.32.camel@oliverchick-Precision-WorkStation-T3400>
	<505B1EB9020000780009CA6E@nat28.tlf.novell.com>
	<20120920134951.GC1998@localhost.localdomain>
	<1348150422.24539.58.camel@oliverchick-Precision-WorkStation-T3400>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1348150422.24539.58.camel@oliverchick-Precision-WorkStation-T3400>
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>,
	David Vrabel <david.vrabel@citrix.com>, Jan Beulich <JBeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] Persistent grant maps for xen blk drivers
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Sep 20, 2012 at 03:13:42PM +0100, Oliver Chick wrote:
> On Thu, 2012-09-20 at 14:49 +0100, Konrad Rzeszutek Wilk wrote:
> > On Thu, Sep 20, 2012 at 12:48:41PM +0100, Jan Beulich wrote:
> > > >>> On 20.09.12 at 13:30, Oliver Chick <oliver.chick@citrix.com> wrote:
> > > > The memory overhead, and fallback mode points are related:
> > > > -Firstly, it turns out that the overhead is actually 2.75MB, not 11MB
> > > > per device. I made a mistake (pointed out by Jan) as the maximum number
> > > > of requests that can fit into a single-page ring is 64, not 256.
> > > > -Clearly, this still scales linearly. So the problem of memory footprint
> > > > will occur with more VMs, or block devices.
> > > > -Whilst 2.75MB per device is probably acceptable (?), if we start using
> > > > multipage rings, then we might not want to have
> > > > BLKIF_MAX_PERS_REQUESTS_PER_DEVICE==__RING_SIZE, as this will cause the
> > > > memory overhead to increase. This is why I have implemented the
> > > > 'fallback' mode. With a multipage ring, it seems reasonable to want the
> > > > first $x$ grefs seen by blkback to be treated as persistent, and any
> > > > later ones to be non-persistent. Does that seem sensible?
> > > 
> > > From a resource usage pov, perhaps. But this will get the guest
> > > entirely unpredictable performance. Plus I don't think 11Mb of
> > 
> > Wouldn't it fall back to the older performance?
> 
> I guess it would be a bit more complex than that. It would be worse than
> the new performance because the grefs that get processed by the
> 'fallback' mode will cause TLB shootdowns. But any early grefs will
> still be processed by the persistent mode, so won't have shootdowns.
> Therefore, depending on the ratio of {persistent grants}:{non-persistent
> grants), allocated by blkfront, the performance will be somewhere
> inbetween the two extremes.
> 
> I guess that the choice is between
> 1) Compiling blk{front,back} with a pre-determined number of persistent
> grants, and failing if this limit is exceeded. This seems rather
> unflexible, as blk{front,back} must then both both use the same version,
> or you will get failures.
> 2 (current setup)) Have a recommended maximum number of
> persistently-mapped pages, and going into a 'fallback' mode if blkfront
> exceeds this limit.
> 3) Having blkback inform blkfront on startup as to how many grefs it is
> willing to persistently-map. We then hit the same question again though:
> what should be do if blkfront ignores this limit?

How about 2 and 3 together? Meaning have a recommended maximmum number.
If we fall back due to memory pressure we can tell the guest that we
are entering fall-back mode. The frontend can decide what it wants to do
(throttle the amount of I/Os?) or just do a printk telling the user it
dropped the speed from "Insane Hot!" down to "Turbo!"... 

Or maybe not. Perhaps just reporting it in the backend that we are
hitting memory pressure and using the old-style-fallback mechanism
so the system admin can take actions (and tell his users why suddenly
their I/Os are so slow).

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 20 21:24:42 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Sep 2012 21: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 1TEoEP-0002KX-C2; Thu, 20 Sep 2012 21:24:21 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1TEoEN-0002KP-Al
	for xen-devel@lists.xen.org; Thu, 20 Sep 2012 21:24:19 +0000
Received: from [85.158.138.51:65427] by server-7.bemta-3.messagelabs.com id
	BB/F9-32000-2898B505; Thu, 20 Sep 2012 21:24:18 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1348176255!29596458!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzUzNjM5\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19849 invoked from network); 20 Sep 2012 21:24:17 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-15.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 20 Sep 2012 21:24:17 -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 q8KLOB8D014234
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 20 Sep 2012 21:24:12 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
	q8KLOAGN002277
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 20 Sep 2012 21:24:11 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
	q8KLOAoi032026; Thu, 20 Sep 2012 16:24:10 -0500
Received: from konrad-lan.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 20 Sep 2012 14:24:10 -0700
Date: Thu, 20 Sep 2012 17:24:07 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Oliver Chick <oliver.chick@citrix.com>
Message-ID: <20120920212407.GD27312@konrad-lan.dumpdata.com>
References: <1348051887-21885-1-git-send-email-oliver.chick@citrix.com>
	<505AF126.2050806@citrix.com>
	<1348140637.24539.32.camel@oliverchick-Precision-WorkStation-T3400>
	<505B1EB9020000780009CA6E@nat28.tlf.novell.com>
	<20120920134951.GC1998@localhost.localdomain>
	<1348150422.24539.58.camel@oliverchick-Precision-WorkStation-T3400>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1348150422.24539.58.camel@oliverchick-Precision-WorkStation-T3400>
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>,
	David Vrabel <david.vrabel@citrix.com>, Jan Beulich <JBeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] Persistent grant maps for xen blk drivers
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Sep 20, 2012 at 03:13:42PM +0100, Oliver Chick wrote:
> On Thu, 2012-09-20 at 14:49 +0100, Konrad Rzeszutek Wilk wrote:
> > On Thu, Sep 20, 2012 at 12:48:41PM +0100, Jan Beulich wrote:
> > > >>> On 20.09.12 at 13:30, Oliver Chick <oliver.chick@citrix.com> wrote:
> > > > The memory overhead, and fallback mode points are related:
> > > > -Firstly, it turns out that the overhead is actually 2.75MB, not 11MB
> > > > per device. I made a mistake (pointed out by Jan) as the maximum number
> > > > of requests that can fit into a single-page ring is 64, not 256.
> > > > -Clearly, this still scales linearly. So the problem of memory footprint
> > > > will occur with more VMs, or block devices.
> > > > -Whilst 2.75MB per device is probably acceptable (?), if we start using
> > > > multipage rings, then we might not want to have
> > > > BLKIF_MAX_PERS_REQUESTS_PER_DEVICE==__RING_SIZE, as this will cause the
> > > > memory overhead to increase. This is why I have implemented the
> > > > 'fallback' mode. With a multipage ring, it seems reasonable to want the
> > > > first $x$ grefs seen by blkback to be treated as persistent, and any
> > > > later ones to be non-persistent. Does that seem sensible?
> > > 
> > > From a resource usage pov, perhaps. But this will get the guest
> > > entirely unpredictable performance. Plus I don't think 11Mb of
> > 
> > Wouldn't it fall back to the older performance?
> 
> I guess it would be a bit more complex than that. It would be worse than
> the new performance because the grefs that get processed by the
> 'fallback' mode will cause TLB shootdowns. But any early grefs will
> still be processed by the persistent mode, so won't have shootdowns.
> Therefore, depending on the ratio of {persistent grants}:{non-persistent
> grants), allocated by blkfront, the performance will be somewhere
> inbetween the two extremes.
> 
> I guess that the choice is between
> 1) Compiling blk{front,back} with a pre-determined number of persistent
> grants, and failing if this limit is exceeded. This seems rather
> unflexible, as blk{front,back} must then both both use the same version,
> or you will get failures.
> 2 (current setup)) Have a recommended maximum number of
> persistently-mapped pages, and going into a 'fallback' mode if blkfront
> exceeds this limit.
> 3) Having blkback inform blkfront on startup as to how many grefs it is
> willing to persistently-map. We then hit the same question again though:
> what should be do if blkfront ignores this limit?

How about 2 and 3 together? Meaning have a recommended maximmum number.
If we fall back due to memory pressure we can tell the guest that we
are entering fall-back mode. The frontend can decide what it wants to do
(throttle the amount of I/Os?) or just do a printk telling the user it
dropped the speed from "Insane Hot!" down to "Turbo!"... 

Or maybe not. Perhaps just reporting it in the backend that we are
hitting memory pressure and using the old-style-fallback mechanism
so the system admin can take actions (and tell his users why suddenly
their I/Os are so slow).

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 20 21:29:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Sep 2012 21:29:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TEoIe-0002Wh-1o; Thu, 20 Sep 2012 21:28: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 1TEoIc-0002Wa-UV
	for xen-devel@lists.xensource.com; Thu, 20 Sep 2012 21:28:43 +0000
Received: from [85.158.143.35:57972] by server-1.bemta-4.messagelabs.com id
	E2/6A-05684-A8A8B505; Thu, 20 Sep 2012 21:28:42 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1348176519!15711126!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDc2MzYwOQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26026 invoked from network); 20 Sep 2012 21:28:41 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-14.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 20 Sep 2012 21:28:41 -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 q8KLSSCr031311
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 20 Sep 2012 21:28:29 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q8KLSRiJ009646
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 20 Sep 2012 21:28:28 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
	q8KLSQ6B000549; Thu, 20 Sep 2012 16:28:26 -0500
Received: from konrad-lan.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 20 Sep 2012 14:28:26 -0700
Date: Thu, 20 Sep 2012 17:28:24 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: William Dauchy <wdauchy@gmail.com>
Message-ID: <20120920212823.GE27312@konrad-lan.dumpdata.com>
References: <CAJ75kXZm-BqWdL2O41XkSE1VCdd4ruW=+CqDmR1b3=701RnXmw@mail.gmail.com>
	<20120918133650.GC12053@phenom.dumpdata.com>
	<CAJ75kXZEaCj4Jqs_qm46d7U-s1C2hkAONs8c5Audrw2c3X=nBA@mail.gmail.com>
	<20120920134851.GB1998@localhost.localdomain>
	<CAJ75kXZ0depUJF_h0yok-r4aL0TBGnqTpW_PKT4Q7P1_6R4X2A@mail.gmail.com>
	<20120920162337.GB8912@reaktio.net>
	<CAJ75kXaXbitBvosYp8Sv_548XbvdxU=M_NSSHTb_5d56=-n4nA@mail.gmail.com>
	<20120920163525.GC8912@reaktio.net>
	<CAJ75kXZnb82GnssNWxyGMHjTYiRQCRsNdPeYdEb-tsvkshpfEg@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAJ75kXZnb82GnssNWxyGMHjTYiRQCRsNdPeYdEb-tsvkshpfEg@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
Subject: Re: [Xen-devel] Error getting mfn
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Sep 20, 2012 at 07:08:51PM +0200, William Dauchy wrote:
> Hi Konrad,
> 
> I finally got what you asked, xen output with dom0 included. sorry for
> the previous noise, there was some issues with my console redirection.

Ah. OK. so lets deal with one issue at hand. The CONFIG_NUMA - you said
you applied I posted for it some time ago? Is it this one?

http://lkml.indiana.edu/hypermail/linux/kernel/1205.3/03619.html

For the non-NUMA case - can you try to compile a kernel without
NUMA enabled and also include 'earlyprintk=xen' on your Linux command
line? That should give me a good approximation of what/where
it is being hit.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 20 21:29:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Sep 2012 21:29:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TEoIe-0002Wh-1o; Thu, 20 Sep 2012 21:28: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 1TEoIc-0002Wa-UV
	for xen-devel@lists.xensource.com; Thu, 20 Sep 2012 21:28:43 +0000
Received: from [85.158.143.35:57972] by server-1.bemta-4.messagelabs.com id
	E2/6A-05684-A8A8B505; Thu, 20 Sep 2012 21:28:42 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1348176519!15711126!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDc2MzYwOQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26026 invoked from network); 20 Sep 2012 21:28:41 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-14.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 20 Sep 2012 21:28:41 -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 q8KLSSCr031311
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 20 Sep 2012 21:28:29 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q8KLSRiJ009646
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 20 Sep 2012 21:28:28 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
	q8KLSQ6B000549; Thu, 20 Sep 2012 16:28:26 -0500
Received: from konrad-lan.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 20 Sep 2012 14:28:26 -0700
Date: Thu, 20 Sep 2012 17:28:24 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: William Dauchy <wdauchy@gmail.com>
Message-ID: <20120920212823.GE27312@konrad-lan.dumpdata.com>
References: <CAJ75kXZm-BqWdL2O41XkSE1VCdd4ruW=+CqDmR1b3=701RnXmw@mail.gmail.com>
	<20120918133650.GC12053@phenom.dumpdata.com>
	<CAJ75kXZEaCj4Jqs_qm46d7U-s1C2hkAONs8c5Audrw2c3X=nBA@mail.gmail.com>
	<20120920134851.GB1998@localhost.localdomain>
	<CAJ75kXZ0depUJF_h0yok-r4aL0TBGnqTpW_PKT4Q7P1_6R4X2A@mail.gmail.com>
	<20120920162337.GB8912@reaktio.net>
	<CAJ75kXaXbitBvosYp8Sv_548XbvdxU=M_NSSHTb_5d56=-n4nA@mail.gmail.com>
	<20120920163525.GC8912@reaktio.net>
	<CAJ75kXZnb82GnssNWxyGMHjTYiRQCRsNdPeYdEb-tsvkshpfEg@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAJ75kXZnb82GnssNWxyGMHjTYiRQCRsNdPeYdEb-tsvkshpfEg@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
Subject: Re: [Xen-devel] Error getting mfn
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Sep 20, 2012 at 07:08:51PM +0200, William Dauchy wrote:
> Hi Konrad,
> 
> I finally got what you asked, xen output with dom0 included. sorry for
> the previous noise, there was some issues with my console redirection.

Ah. OK. so lets deal with one issue at hand. The CONFIG_NUMA - you said
you applied I posted for it some time ago? Is it this one?

http://lkml.indiana.edu/hypermail/linux/kernel/1205.3/03619.html

For the non-NUMA case - can you try to compile a kernel without
NUMA enabled and also include 'earlyprintk=xen' on your Linux command
line? That should give me a good approximation of what/where
it is being hit.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 20 21:30:35 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Sep 2012 21: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 1TEoK8-0002e5-Mn; Thu, 20 Sep 2012 21:30:16 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1TEoK7-0002dy-5y
	for xen-devel@lists.xensource.com; Thu, 20 Sep 2012 21:30:15 +0000
Received: from [85.158.139.83:49502] by server-15.bemta-5.messagelabs.com id
	80/D1-23541-6EA8B505; Thu, 20 Sep 2012 21:30:14 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1348176612!31731394!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDc2MzYwOQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17190 invoked from network); 20 Sep 2012 21:30:13 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-10.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 20 Sep 2012 21:30: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 q8KLTsG7032375
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 20 Sep 2012 21:29:55 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q8KLTsTp021405
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 20 Sep 2012 21:29:54 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
	q8KLTpLj002948; Thu, 20 Sep 2012 16:29:51 -0500
Received: from konrad-lan.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 20 Sep 2012 14:29:51 -0700
Date: Thu, 20 Sep 2012 17:29:48 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Dave Martin <dave.martin@linaro.org>
Message-ID: <20120920212948.GF27312@konrad-lan.dumpdata.com>
References: <1348076658-4511-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<1348135563.11116.94.camel@hornet>
	<20120920111815.GC2117@linaro.org>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120920111815.GC2117@linaro.org>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Ian.Campbell@citrix.com" <Ian.Campbell@citrix.com>,
	Pawel Moll <pawel.moll@arm.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Xen-devel] [PATCH] arm: introduce a DTS for Xen unprivileged
 virtual 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 Thu, Sep 20, 2012 at 12:18:15PM +0100, Dave Martin wrote:
> On Thu, Sep 20, 2012 at 11:06:03AM +0100, Pawel Moll wrote:
> > Morning,
> > 
> > On Wed, 2012-09-19 at 18:44 +0100, Stefano Stabellini wrote:
> > > +/dts-v1/;
> > > +
> > > +/include/ "skeleton.dtsi"
> > 
> > Any particular reason to include skeleton? And I think it would be
> > better to use #address-cells = <2> and #size-cells = <2>, to be ready
> > for LPAE addresses...
> > 
> > > +/ {
> > > +	model = "XENVM-4.2";
> > > +	compatible = "xen,xenvm-4.2", "arm,vexpress";
> > > +	interrupt-parent = <&gic>;
> > > +
> > > +	chosen {
> > > +		bootargs = "earlyprintk console=hvc0 root=/dev/xvda init=/sbin/init";

earlyprintk=xen ?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 20 21:30:35 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Sep 2012 21: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 1TEoK8-0002e5-Mn; Thu, 20 Sep 2012 21:30:16 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1TEoK7-0002dy-5y
	for xen-devel@lists.xensource.com; Thu, 20 Sep 2012 21:30:15 +0000
Received: from [85.158.139.83:49502] by server-15.bemta-5.messagelabs.com id
	80/D1-23541-6EA8B505; Thu, 20 Sep 2012 21:30:14 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1348176612!31731394!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDc2MzYwOQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17190 invoked from network); 20 Sep 2012 21:30:13 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-10.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 20 Sep 2012 21:30: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 q8KLTsG7032375
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 20 Sep 2012 21:29:55 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q8KLTsTp021405
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 20 Sep 2012 21:29:54 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
	q8KLTpLj002948; Thu, 20 Sep 2012 16:29:51 -0500
Received: from konrad-lan.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 20 Sep 2012 14:29:51 -0700
Date: Thu, 20 Sep 2012 17:29:48 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Dave Martin <dave.martin@linaro.org>
Message-ID: <20120920212948.GF27312@konrad-lan.dumpdata.com>
References: <1348076658-4511-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<1348135563.11116.94.camel@hornet>
	<20120920111815.GC2117@linaro.org>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120920111815.GC2117@linaro.org>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Ian.Campbell@citrix.com" <Ian.Campbell@citrix.com>,
	Pawel Moll <pawel.moll@arm.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Xen-devel] [PATCH] arm: introduce a DTS for Xen unprivileged
 virtual 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 Thu, Sep 20, 2012 at 12:18:15PM +0100, Dave Martin wrote:
> On Thu, Sep 20, 2012 at 11:06:03AM +0100, Pawel Moll wrote:
> > Morning,
> > 
> > On Wed, 2012-09-19 at 18:44 +0100, Stefano Stabellini wrote:
> > > +/dts-v1/;
> > > +
> > > +/include/ "skeleton.dtsi"
> > 
> > Any particular reason to include skeleton? And I think it would be
> > better to use #address-cells = <2> and #size-cells = <2>, to be ready
> > for LPAE addresses...
> > 
> > > +/ {
> > > +	model = "XENVM-4.2";
> > > +	compatible = "xen,xenvm-4.2", "arm,vexpress";
> > > +	interrupt-parent = <&gic>;
> > > +
> > > +	chosen {
> > > +		bootargs = "earlyprintk console=hvc0 root=/dev/xvda init=/sbin/init";

earlyprintk=xen ?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 20 22:07:27 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Sep 2012 22:07: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 1TEotm-0003gh-4g; Thu, 20 Sep 2012 22:07:06 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <attilio.rao@citrix.com>) id 1TEotk-0003gb-A0
	for xen-devel@lists.xen.org; Thu, 20 Sep 2012 22:07:04 +0000
Received: from [85.158.137.99:54058] by server-3.bemta-3.messagelabs.com id
	DD/02-21322-7839B505; Thu, 20 Sep 2012 22:07:03 +0000
X-Env-Sender: attilio.rao@citrix.com
X-Msg-Ref: server-15.tower-217.messagelabs.com!1348178822!16156561!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTA0NTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20835 invoked from network); 20 Sep 2012 22:07:02 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Sep 2012 22:07:02 -0000
X-IronPort-AV: E=Sophos;i="4.80,455,1344211200"; d="scan'208";a="14675502"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Sep 2012 22:07:02 +0000
Received: from [10.80.3.221] (10.80.3.221) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Thu, 20 Sep 2012 23:07:02 +0100
Message-ID: <505B9338.70908@citrix.com>
Date: Thu, 20 Sep 2012 23:05:44 +0100
From: Attilio Rao <attilio.rao@citrix.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US;
	rv:1.9.1.16) Gecko/20111110 Icedove/3.0.11
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <505A5A03.4000106@citrix.com>
	<505AE62A020000780009C7F8@nat28.tlf.novell.com>
	<505B22C5.4050004@citrix.com>
	<505B5586020000780009CBCF@nat28.tlf.novell.com>
In-Reply-To: <505B5586020000780009CBCF@nat28.tlf.novell.com>
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] [RFC] Extend the number of event channels availabe
 to guests
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 20/09/12 16:42, Jan Beulich wrote:
>>>> On 20.09.12 at 16:05, Attilio Rao<attilio.rao@citrix.com>  wrote:
>>>>          
>> On 20/09/12 08:47, Jan Beulich wrote:
>>      
>>>>>> On 20.09.12 at 01:49, Attilio Rao<attilio.rao@citrix.com>   wrote:
>>>>>>
>>>>>>              
>>>> Proposal
>>>> The proposal is pretty simple: the eventchannel search will become a
>>>> three-level lookup table, with the leaf level being composed by shared
>>>> pages registered at boot time by the guests.
>>>> The bitmap working now as leaf (then called "second level") will work
>>>> alternatively as leaf level still (for older kernel) or for intermediate
>>>> level to address into a new array of shared pages (for newer kernels).
>>>> This leaves the possibility to reuse the existing mechanisms without
>>>> modifying its internals.
>>>>
>>>>          
>>> While adding one level would seem to leave ample room, so did
>>> the originally 4096 originally. Therefore, even if unimplemented
>>> right now, I'd like the interface to allow for the guest to specify
>>> more levels.
>>>
>>>        
>> There is a big difference here. The third/new level will be composed of
>> pages registered at guest installing so it can be expanded on demanded
>> necessity. The second-level we have now doesn't work because it is stuck
>> in the immutable ABI.
>> The only useful way to have another level would be in the case we think
>> the second-level is not enough to address all the necessary bits in the
>> third level in efficient way.
>>
>> To make you an example, the first level is 64 bits while the second
>> level can address 64 times the first level. The third level, to be
>> on-par with the same ratio of the second level in terms of performance,
>> would be large something like 4 pages. I think we are very far from
>> reaching critical levels.
>>      
> What I'm saying is that further levels should be continuing at the
> rate, i.e. times BITS_PER_LONG per level. Allowing for an only
> partially populated leaf level is certainly an option. But similarly
> it should be an option to have a fourth level once needed, without
> having to start over from scratch again.
>    

Yes, I agree, but I don't see a big problem here, besides having a way 
to specify which level pages should compose and deal with them.
The only difference is that maybe we could be ending up building sort of 
containers for such topology, to deal with a multi-digi table. I think 
it will not be too difficult to do, but I would leave this as very last 
item, eventually, once that the "third-level" already works ok.

>    
>>>> More specifically, what needs to happen:
>>>> - Add new members to struct domain to handle an array of pages (to
>>>> contain the actual evtchn bitmaps), a further array of pages (to contain
>>>> the evtchn masks) and a control bit to say if it is subjective to the
>>>> new mode or not. Initially the arrays will be empty and the control bit
>>>> will be OFF.
>>>> - At init_platform() time, the guest must allocate the pages to compose
>>>> the 2 arrays and invoke a novel hypercall which, at big lines, does the
>>>> following:
>>>>      * Creates some pages to populate the new arrays in struct domain via
>>>> alloc_xenheap_pages()
>>>>
>>>>          
>>> Why? The guest allocated the pages already. Just have the
>>> hypervisor map them (similar, but without the per-vCPU needs,
>>> to registering an alternative per-vCPU shared page). Whether
>>> it turns out more practical to require the guest to enforce
>>> certain restrictions (like the pages being contiguous and/or
>>> address restricted) is a secondary aspect.
>>>
>>>        
>> Actually what I propose seems to be what happens infact in the shared
>> page case. Look at what arch_domain_create() and XENMEM_add_to_physmap
>> hypercall do (in the XENMAPSPACE_shared_info case). I think this is the
>> quicker way to get what we want.
>>      
> This is HVM-only thinking. PV doesn't use this, and I don't think
> artificially inserting something somewhere in the physmap of a
> PV guest is a good idea either. To have things done uniformly,
> going the PV route and using guest allocated pages seems the
> better choice to me. Alternatively, you'd have to implement a
> HVM mechanism (via add-to-physmap) and a PV one.
>
> Plus the add-to-physmap one has the drawback of limiting the
> space available for adding pages (as these would generally
> have to go into the MMIO space of the platform PCI device).
>
>    

On a second thought, I think I can use something very similar to the 
sharing mechanism of the grant tables, basically modeled over 
grant_table_create() and subsequent gnttab_setup_table() mapping 
creation. This should also work in the PV case.

Attilio


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 20 22:07:27 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 20 Sep 2012 22:07: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 1TEotm-0003gh-4g; Thu, 20 Sep 2012 22:07:06 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <attilio.rao@citrix.com>) id 1TEotk-0003gb-A0
	for xen-devel@lists.xen.org; Thu, 20 Sep 2012 22:07:04 +0000
Received: from [85.158.137.99:54058] by server-3.bemta-3.messagelabs.com id
	DD/02-21322-7839B505; Thu, 20 Sep 2012 22:07:03 +0000
X-Env-Sender: attilio.rao@citrix.com
X-Msg-Ref: server-15.tower-217.messagelabs.com!1348178822!16156561!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTA0NTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20835 invoked from network); 20 Sep 2012 22:07:02 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Sep 2012 22:07:02 -0000
X-IronPort-AV: E=Sophos;i="4.80,455,1344211200"; d="scan'208";a="14675502"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Sep 2012 22:07:02 +0000
Received: from [10.80.3.221] (10.80.3.221) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Thu, 20 Sep 2012 23:07:02 +0100
Message-ID: <505B9338.70908@citrix.com>
Date: Thu, 20 Sep 2012 23:05:44 +0100
From: Attilio Rao <attilio.rao@citrix.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US;
	rv:1.9.1.16) Gecko/20111110 Icedove/3.0.11
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <505A5A03.4000106@citrix.com>
	<505AE62A020000780009C7F8@nat28.tlf.novell.com>
	<505B22C5.4050004@citrix.com>
	<505B5586020000780009CBCF@nat28.tlf.novell.com>
In-Reply-To: <505B5586020000780009CBCF@nat28.tlf.novell.com>
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] [RFC] Extend the number of event channels availabe
 to guests
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 20/09/12 16:42, Jan Beulich wrote:
>>>> On 20.09.12 at 16:05, Attilio Rao<attilio.rao@citrix.com>  wrote:
>>>>          
>> On 20/09/12 08:47, Jan Beulich wrote:
>>      
>>>>>> On 20.09.12 at 01:49, Attilio Rao<attilio.rao@citrix.com>   wrote:
>>>>>>
>>>>>>              
>>>> Proposal
>>>> The proposal is pretty simple: the eventchannel search will become a
>>>> three-level lookup table, with the leaf level being composed by shared
>>>> pages registered at boot time by the guests.
>>>> The bitmap working now as leaf (then called "second level") will work
>>>> alternatively as leaf level still (for older kernel) or for intermediate
>>>> level to address into a new array of shared pages (for newer kernels).
>>>> This leaves the possibility to reuse the existing mechanisms without
>>>> modifying its internals.
>>>>
>>>>          
>>> While adding one level would seem to leave ample room, so did
>>> the originally 4096 originally. Therefore, even if unimplemented
>>> right now, I'd like the interface to allow for the guest to specify
>>> more levels.
>>>
>>>        
>> There is a big difference here. The third/new level will be composed of
>> pages registered at guest installing so it can be expanded on demanded
>> necessity. The second-level we have now doesn't work because it is stuck
>> in the immutable ABI.
>> The only useful way to have another level would be in the case we think
>> the second-level is not enough to address all the necessary bits in the
>> third level in efficient way.
>>
>> To make you an example, the first level is 64 bits while the second
>> level can address 64 times the first level. The third level, to be
>> on-par with the same ratio of the second level in terms of performance,
>> would be large something like 4 pages. I think we are very far from
>> reaching critical levels.
>>      
> What I'm saying is that further levels should be continuing at the
> rate, i.e. times BITS_PER_LONG per level. Allowing for an only
> partially populated leaf level is certainly an option. But similarly
> it should be an option to have a fourth level once needed, without
> having to start over from scratch again.
>    

Yes, I agree, but I don't see a big problem here, besides having a way 
to specify which level pages should compose and deal with them.
The only difference is that maybe we could be ending up building sort of 
containers for such topology, to deal with a multi-digi table. I think 
it will not be too difficult to do, but I would leave this as very last 
item, eventually, once that the "third-level" already works ok.

>    
>>>> More specifically, what needs to happen:
>>>> - Add new members to struct domain to handle an array of pages (to
>>>> contain the actual evtchn bitmaps), a further array of pages (to contain
>>>> the evtchn masks) and a control bit to say if it is subjective to the
>>>> new mode or not. Initially the arrays will be empty and the control bit
>>>> will be OFF.
>>>> - At init_platform() time, the guest must allocate the pages to compose
>>>> the 2 arrays and invoke a novel hypercall which, at big lines, does the
>>>> following:
>>>>      * Creates some pages to populate the new arrays in struct domain via
>>>> alloc_xenheap_pages()
>>>>
>>>>          
>>> Why? The guest allocated the pages already. Just have the
>>> hypervisor map them (similar, but without the per-vCPU needs,
>>> to registering an alternative per-vCPU shared page). Whether
>>> it turns out more practical to require the guest to enforce
>>> certain restrictions (like the pages being contiguous and/or
>>> address restricted) is a secondary aspect.
>>>
>>>        
>> Actually what I propose seems to be what happens infact in the shared
>> page case. Look at what arch_domain_create() and XENMEM_add_to_physmap
>> hypercall do (in the XENMAPSPACE_shared_info case). I think this is the
>> quicker way to get what we want.
>>      
> This is HVM-only thinking. PV doesn't use this, and I don't think
> artificially inserting something somewhere in the physmap of a
> PV guest is a good idea either. To have things done uniformly,
> going the PV route and using guest allocated pages seems the
> better choice to me. Alternatively, you'd have to implement a
> HVM mechanism (via add-to-physmap) and a PV one.
>
> Plus the add-to-physmap one has the drawback of limiting the
> space available for adding pages (as these would generally
> have to go into the MMIO space of the platform PCI device).
>
>    

On a second thought, I think I can use something very similar to the 
sharing mechanism of the grant tables, basically modeled over 
grant_table_create() and subsequent gnttab_setup_table() mapping 
creation. This should also work in the PV case.

Attilio


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 21 00:00:34 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Sep 2012 00:00: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 1TEqfD-0005Dr-7f; Fri, 21 Sep 2012 00:00:11 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1TEqfB-0005Dj-4O
	for xen-devel@lists.xensource.com; Fri, 21 Sep 2012 00:00:09 +0000
Received: from [85.158.143.35:35099] by server-1.bemta-4.messagelabs.com id
	7C/2B-05684-80EAB505; Fri, 21 Sep 2012 00:00:08 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1348185607!8224769!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTA1OTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31833 invoked from network); 21 Sep 2012 00:00:07 -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;
	21 Sep 2012 00:00:07 -0000
X-IronPort-AV: E=Sophos;i="4.80,457,1344211200"; d="scan'208";a="14676644"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Sep 2012 00:00: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.279.1; Fri, 21 Sep 2012 01:00: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 1TEqf8-0002SU-6H;
	Fri, 21 Sep 2012 00:00:06 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1TEqf8-0001Mf-1o;
	Fri, 21 Sep 2012 01:00:06 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-13823-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 21 Sep 2012 01:00:06 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13823: 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 13823 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13823/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore            fail   like 13819
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail like 13819
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail like 13819

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  d364becfb083
baseline version:
 xen                  fee83ac77d8c

------------------------------------------------------------
People who touched revisions under test:
  Dan Magenheimer <dan.magenheimer@oracle.com>
  Jan Beulich <jbeulich@suse.com>
  Keir Fraser <keir@xen.org>
  Zhenzhong Duan <zhenzhong.duan@oracle.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-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-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-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-amd64-amd64-xl-win                                      fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=xen-unstable
+ revision=d364becfb083
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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 d364becfb083
+ branch=xen-unstable
+ revision=d364becfb083
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-unstable
+ '[' xxen = xlinux ']'
+ linuxbranch=linux
+ : master
+ : tested/2.6.39.x
+ . ap-common
++ : xen@xenbits.xensource.com
++ : http://xenbits.xen.org/hg/staging/xen-unstable.hg
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : xen@xenbits.xensource.com:git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.xen-unstable
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-unstable.git
++ : daily-cron.xen-unstable
+ TREE_LINUX=xen@xenbits.xensource.com:git/linux-pvops.git
+ TREE_QEMU_UPSTREAM=xen@xenbits.xensource.com:git/qemu-upstream-unstable.git
+ info_linux_tree xen-unstable
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/xen-unstable.hg
+ hg push -r d364becfb083 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 4 changesets with 11 changes to 11 files

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 21 00:00:34 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Sep 2012 00:00: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 1TEqfD-0005Dr-7f; Fri, 21 Sep 2012 00:00:11 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1TEqfB-0005Dj-4O
	for xen-devel@lists.xensource.com; Fri, 21 Sep 2012 00:00:09 +0000
Received: from [85.158.143.35:35099] by server-1.bemta-4.messagelabs.com id
	7C/2B-05684-80EAB505; Fri, 21 Sep 2012 00:00:08 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1348185607!8224769!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTA1OTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31833 invoked from network); 21 Sep 2012 00:00:07 -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;
	21 Sep 2012 00:00:07 -0000
X-IronPort-AV: E=Sophos;i="4.80,457,1344211200"; d="scan'208";a="14676644"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Sep 2012 00:00: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.279.1; Fri, 21 Sep 2012 01:00: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 1TEqf8-0002SU-6H;
	Fri, 21 Sep 2012 00:00:06 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1TEqf8-0001Mf-1o;
	Fri, 21 Sep 2012 01:00:06 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-13823-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 21 Sep 2012 01:00:06 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13823: 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 13823 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13823/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore            fail   like 13819
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail like 13819
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail like 13819

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  d364becfb083
baseline version:
 xen                  fee83ac77d8c

------------------------------------------------------------
People who touched revisions under test:
  Dan Magenheimer <dan.magenheimer@oracle.com>
  Jan Beulich <jbeulich@suse.com>
  Keir Fraser <keir@xen.org>
  Zhenzhong Duan <zhenzhong.duan@oracle.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-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-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-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-amd64-amd64-xl-win                                      fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=xen-unstable
+ revision=d364becfb083
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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 d364becfb083
+ branch=xen-unstable
+ revision=d364becfb083
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-unstable
+ '[' xxen = xlinux ']'
+ linuxbranch=linux
+ : master
+ : tested/2.6.39.x
+ . ap-common
++ : xen@xenbits.xensource.com
++ : http://xenbits.xen.org/hg/staging/xen-unstable.hg
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : xen@xenbits.xensource.com:git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.xen-unstable
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-unstable.git
++ : daily-cron.xen-unstable
+ TREE_LINUX=xen@xenbits.xensource.com:git/linux-pvops.git
+ TREE_QEMU_UPSTREAM=xen@xenbits.xensource.com:git/qemu-upstream-unstable.git
+ info_linux_tree xen-unstable
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/xen-unstable.hg
+ hg push -r d364becfb083 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 4 changesets with 11 changes to 11 files

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 21 03:19:06 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Sep 2012 03:19:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TEtlB-0002Qf-Dp; Fri, 21 Sep 2012 03:18:33 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <msw@amazon.com>) id 1TEtlA-0002Qa-L8
	for xen-devel@lists.xen.org; Fri, 21 Sep 2012 03:18:32 +0000
X-Env-Sender: msw@amazon.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1348197504!10413061!1
X-Originating-IP: [207.171.178.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA3LjE3MS4xNzguMjUgPT4gNjk0MjM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22022 invoked from network); 21 Sep 2012 03:18:26 -0000
Received: from smtp-fw-31001.amazon.com (HELO smtp-fw-31001.amazon.com)
	(207.171.178.25)
	by server-16.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Sep 2012 03:18:26 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=amazon.com; i=msw@amazon.com; q=dns/txt; s=rte02;
	t=1348197506; x=1379733506;
	h=date:from:to:cc:subject:message-id:references:
	mime-version:in-reply-to;
	bh=Q4Hhad7JNjO3PMxJ1/o5j4ODKvti1feyjB3Z4WrQPfA=;
	b=Jbx4+hE4FIWddMAgfoZ2NkrC83s/M+yal28vuNCtDJtobNtmsKs+d/66
	R/1q2BoELs+j3rqAnEcMl/MKsTk+yw==;
X-IronPort-AV: E=Sophos;i="4.80,458,1344211200"; d="scan'208";a="297625049"
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; 21 Sep 2012 03:18:22 +0000
Received: from ex10-hub-31006.ant.amazon.com (ex10-hub-31006.sea31.amazon.com
	[10.185.176.13])
	by smtp-in-5102.iad5.amazon.com (8.13.8/8.13.8) with ESMTP id
	q8L3IKKV005062
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL);
	Fri, 21 Sep 2012 03:18:21 GMT
Received: from u002268147cd4502c336d.ant.amazon.com (10.224.80.42) by
	ex10-hub-31006.ant.amazon.com (10.185.176.13) with Microsoft SMTP
	Server id 14.2.247.3; Thu, 20 Sep 2012 20:18:16 -0700
Received: by u002268147cd4502c336d.ant.amazon.com (sSMTP sendmail emulation); 
	Thu, 20 Sep 2012 20:18:14 -0700
Date: Thu, 20 Sep 2012 20:18:14 -0700
From: Matt Wilson <msw@amazon.com>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20120921031759.GA3953@u002268147cd4502c336d.ant.amazon.com>
References: <CAFLBxZYtmJ_bKFb90r45=C4Pq1-oe5Fy=eygSsQf4BcGj3EqGA@mail.gmail.com>
	<505ADBCF020000780009C7BE@nat28.tlf.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <505ADBCF020000780009C7BE@nat28.tlf.novell.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: George Dunlap <George.Dunlap@eu.citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Xen 4.3 development 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 Thu, Sep 20, 2012 at 08:03:11AM +0100, Jan Beulich wrote:
> > On 19.09.12 at 18:58, George Dunlap <George.Dunlap@eu.citrix.com> wrote:
> > * Persistent grants
> >   owner: @citrix
> >   status: ?
> 
> Isn't that a guest side only thing (i.e. not really to be tracked
> here)? Or does that mean migrating active grants?

I'd assume that the device would be renegotiated during migration, and
that new grants would be established during the re-connect sequence.

One question I have is how persistent grants intersect with
blktap3. Will a persistent grant-capable blktap3 implementation be in
scope for 4.3?

> > * Multi-page blk rings
> >  - blkback in kernel (konrad@oracle, ?@intel)
> 
> This part certainly is a guest side only thing (apart from the
> interface definition living in the our tree).

Same question here regarding blktap3.

Matt

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 21 03:19:06 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Sep 2012 03:19:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TEtlB-0002Qf-Dp; Fri, 21 Sep 2012 03:18:33 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <msw@amazon.com>) id 1TEtlA-0002Qa-L8
	for xen-devel@lists.xen.org; Fri, 21 Sep 2012 03:18:32 +0000
X-Env-Sender: msw@amazon.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1348197504!10413061!1
X-Originating-IP: [207.171.178.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA3LjE3MS4xNzguMjUgPT4gNjk0MjM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22022 invoked from network); 21 Sep 2012 03:18:26 -0000
Received: from smtp-fw-31001.amazon.com (HELO smtp-fw-31001.amazon.com)
	(207.171.178.25)
	by server-16.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Sep 2012 03:18:26 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=amazon.com; i=msw@amazon.com; q=dns/txt; s=rte02;
	t=1348197506; x=1379733506;
	h=date:from:to:cc:subject:message-id:references:
	mime-version:in-reply-to;
	bh=Q4Hhad7JNjO3PMxJ1/o5j4ODKvti1feyjB3Z4WrQPfA=;
	b=Jbx4+hE4FIWddMAgfoZ2NkrC83s/M+yal28vuNCtDJtobNtmsKs+d/66
	R/1q2BoELs+j3rqAnEcMl/MKsTk+yw==;
X-IronPort-AV: E=Sophos;i="4.80,458,1344211200"; d="scan'208";a="297625049"
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; 21 Sep 2012 03:18:22 +0000
Received: from ex10-hub-31006.ant.amazon.com (ex10-hub-31006.sea31.amazon.com
	[10.185.176.13])
	by smtp-in-5102.iad5.amazon.com (8.13.8/8.13.8) with ESMTP id
	q8L3IKKV005062
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL);
	Fri, 21 Sep 2012 03:18:21 GMT
Received: from u002268147cd4502c336d.ant.amazon.com (10.224.80.42) by
	ex10-hub-31006.ant.amazon.com (10.185.176.13) with Microsoft SMTP
	Server id 14.2.247.3; Thu, 20 Sep 2012 20:18:16 -0700
Received: by u002268147cd4502c336d.ant.amazon.com (sSMTP sendmail emulation); 
	Thu, 20 Sep 2012 20:18:14 -0700
Date: Thu, 20 Sep 2012 20:18:14 -0700
From: Matt Wilson <msw@amazon.com>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20120921031759.GA3953@u002268147cd4502c336d.ant.amazon.com>
References: <CAFLBxZYtmJ_bKFb90r45=C4Pq1-oe5Fy=eygSsQf4BcGj3EqGA@mail.gmail.com>
	<505ADBCF020000780009C7BE@nat28.tlf.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <505ADBCF020000780009C7BE@nat28.tlf.novell.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: George Dunlap <George.Dunlap@eu.citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Xen 4.3 development 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 Thu, Sep 20, 2012 at 08:03:11AM +0100, Jan Beulich wrote:
> > On 19.09.12 at 18:58, George Dunlap <George.Dunlap@eu.citrix.com> wrote:
> > * Persistent grants
> >   owner: @citrix
> >   status: ?
> 
> Isn't that a guest side only thing (i.e. not really to be tracked
> here)? Or does that mean migrating active grants?

I'd assume that the device would be renegotiated during migration, and
that new grants would be established during the re-connect sequence.

One question I have is how persistent grants intersect with
blktap3. Will a persistent grant-capable blktap3 implementation be in
scope for 4.3?

> > * Multi-page blk rings
> >  - blkback in kernel (konrad@oracle, ?@intel)
> 
> This part certainly is a guest side only thing (apart from the
> interface definition living in the our tree).

Same question here regarding blktap3.

Matt

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 21 04:35:39 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Sep 2012 04:35:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TEuxH-0002xP-IZ; Fri, 21 Sep 2012 04:35:07 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <vivagin@yeah.net>) id 1TEuxG-0002xH-4P
	for xen-devel@lists.xensource.com; Fri, 21 Sep 2012 04:35:06 +0000
Received: from [85.158.138.51:57378] by server-9.bemta-3.messagelabs.com id
	1B/54-15390-97EEB505; Fri, 21 Sep 2012 04:35:05 +0000
X-Env-Sender: vivagin@yeah.net
X-Msg-Ref: server-7.tower-174.messagelabs.com!1348202102!22532990!1
X-Originating-IP: [216.139.236.26]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25573 invoked from network); 21 Sep 2012 04:35:04 -0000
Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26)
	by server-7.tower-174.messagelabs.com with AES256-SHA encrypted SMTP;
	21 Sep 2012 04:35:04 -0000
Received: from [192.168.236.26] (helo=sam.nabble.com)
	by sam.nabble.com with esmtp (Exim 4.72)
	(envelope-from <vivagin@yeah.net>) id 1TEuxC-0008HN-DS
	for xen-devel@lists.xensource.com; Thu, 20 Sep 2012 21:35:02 -0700
Date: Thu, 20 Sep 2012 21:35:02 -0700 (PDT)
From: Bruce Granger <vivagin@yeah.net>
To: xen-devel@lists.xensource.com
Message-ID: <1348202102238-5711423.post@n5.nabble.com>
MIME-Version: 1.0
Subject: [Xen-devel] Relationship between GuestOS shutdown and destroy
	operations?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

SGVsbG8gZXZlcnlvbmUhCgpJbiBteSBvcGluaW9uLCBJIHRoaW5rIHdoZW4gd2Ugc2h1dGRvd24g
dGhlIEd1ZXN0T1MsCiBYZW4gc2hvdWxkIGZyZWUgYWxsb2NhdGVkIHZjcHUgYW5kIGRvbWFpbiBn
aXZlZCB0byBHdWVzdE9TIAp3aGVuIGl0IGNyZWF0ZWQgYXQgdGhlIHNhbWUgdGltZS4gCgpCdXQg
SSBkb27igJl0IGZpbmQgYW55IGNvZGUgaW4gZnVuY3Rpb25zIGFzc29jaWF0ZWQgd2l0aCBzaHV0
ZG93biBwcm9jZXNzIHRvCnNob3cgdGhpcyB3b3JrLApmb3IgZXhhbXBsZTogCkh2bV92Y3B1X2Rv
d24oKS3jgIlkb21haW5fc2h1dGRvd24oKS0+X19kb21haW5fZmluYWxpc2Vfc2h1dGRvd24oKQoK
QnV0IEkgZmluZCB0aGUgZnVuY3Rpb25zIGZyZWVfdmNwdV9zdHJ1Y3QoKSBhbmQgZnJlZV9kb21h
aW5fc3RydWN0KCkgCmluIHRoZSBmdW5jdGlvbiBjb21wbGV0ZV9kb21haW5fZGVzdHJveSgpIGlu
IHRoZSBwcm9jZXNzIG9mIGRlc3Ryb3kKb3BlcmF0aW9uLCAKdGhlIGNvZGUgcHJvY2VzcyBpczoK
RG9tYWluX2tpbGwoKS0+cHV0X2RvbWFpbigpLT5kb21haW5fZGVzdHJveSgpLT5jb21wbGV0ZV9k
b21haW5fZGVzdHJveSgpCgpJcyB0aGF0IHByb2Nlc3MgcmlnaHQ/IElzIHRoZXJlIGFueSByZWxh
dGlvbnNoaXAgYmV0d2VlbiB0aGVtPwpEb2VzIGFueW9uZSBrbm93IGl0PwoKVGhhbmtzIGZvciB5
b3VyIGhlbHAhCgoKCi0tClZpZXcgdGhpcyBtZXNzYWdlIGluIGNvbnRleHQ6IGh0dHA6Ly94ZW4u
MTA0NTcxMi5uNS5uYWJibGUuY29tL1JlbGF0aW9uc2hpcC1iZXR3ZWVuLUd1ZXN0T1Mtc2h1dGRv
d24tYW5kLWRlc3Ryb3ktb3BlcmF0aW9ucy10cDU3MTE0MjMuaHRtbApTZW50IGZyb20gdGhlIFhl
biAtIERldiBtYWlsaW5nIGxpc3QgYXJjaGl2ZSBhdCBOYWJibGUuY29tLgoKX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlz
dApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwOi8vbGlzdHMueGVuLm9yZy94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xen.org Fri Sep 21 04:35:39 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Sep 2012 04:35:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TEuxH-0002xP-IZ; Fri, 21 Sep 2012 04:35:07 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <vivagin@yeah.net>) id 1TEuxG-0002xH-4P
	for xen-devel@lists.xensource.com; Fri, 21 Sep 2012 04:35:06 +0000
Received: from [85.158.138.51:57378] by server-9.bemta-3.messagelabs.com id
	1B/54-15390-97EEB505; Fri, 21 Sep 2012 04:35:05 +0000
X-Env-Sender: vivagin@yeah.net
X-Msg-Ref: server-7.tower-174.messagelabs.com!1348202102!22532990!1
X-Originating-IP: [216.139.236.26]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25573 invoked from network); 21 Sep 2012 04:35:04 -0000
Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26)
	by server-7.tower-174.messagelabs.com with AES256-SHA encrypted SMTP;
	21 Sep 2012 04:35:04 -0000
Received: from [192.168.236.26] (helo=sam.nabble.com)
	by sam.nabble.com with esmtp (Exim 4.72)
	(envelope-from <vivagin@yeah.net>) id 1TEuxC-0008HN-DS
	for xen-devel@lists.xensource.com; Thu, 20 Sep 2012 21:35:02 -0700
Date: Thu, 20 Sep 2012 21:35:02 -0700 (PDT)
From: Bruce Granger <vivagin@yeah.net>
To: xen-devel@lists.xensource.com
Message-ID: <1348202102238-5711423.post@n5.nabble.com>
MIME-Version: 1.0
Subject: [Xen-devel] Relationship between GuestOS shutdown and destroy
	operations?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

SGVsbG8gZXZlcnlvbmUhCgpJbiBteSBvcGluaW9uLCBJIHRoaW5rIHdoZW4gd2Ugc2h1dGRvd24g
dGhlIEd1ZXN0T1MsCiBYZW4gc2hvdWxkIGZyZWUgYWxsb2NhdGVkIHZjcHUgYW5kIGRvbWFpbiBn
aXZlZCB0byBHdWVzdE9TIAp3aGVuIGl0IGNyZWF0ZWQgYXQgdGhlIHNhbWUgdGltZS4gCgpCdXQg
SSBkb27igJl0IGZpbmQgYW55IGNvZGUgaW4gZnVuY3Rpb25zIGFzc29jaWF0ZWQgd2l0aCBzaHV0
ZG93biBwcm9jZXNzIHRvCnNob3cgdGhpcyB3b3JrLApmb3IgZXhhbXBsZTogCkh2bV92Y3B1X2Rv
d24oKS3jgIlkb21haW5fc2h1dGRvd24oKS0+X19kb21haW5fZmluYWxpc2Vfc2h1dGRvd24oKQoK
QnV0IEkgZmluZCB0aGUgZnVuY3Rpb25zIGZyZWVfdmNwdV9zdHJ1Y3QoKSBhbmQgZnJlZV9kb21h
aW5fc3RydWN0KCkgCmluIHRoZSBmdW5jdGlvbiBjb21wbGV0ZV9kb21haW5fZGVzdHJveSgpIGlu
IHRoZSBwcm9jZXNzIG9mIGRlc3Ryb3kKb3BlcmF0aW9uLCAKdGhlIGNvZGUgcHJvY2VzcyBpczoK
RG9tYWluX2tpbGwoKS0+cHV0X2RvbWFpbigpLT5kb21haW5fZGVzdHJveSgpLT5jb21wbGV0ZV9k
b21haW5fZGVzdHJveSgpCgpJcyB0aGF0IHByb2Nlc3MgcmlnaHQ/IElzIHRoZXJlIGFueSByZWxh
dGlvbnNoaXAgYmV0d2VlbiB0aGVtPwpEb2VzIGFueW9uZSBrbm93IGl0PwoKVGhhbmtzIGZvciB5
b3VyIGhlbHAhCgoKCi0tClZpZXcgdGhpcyBtZXNzYWdlIGluIGNvbnRleHQ6IGh0dHA6Ly94ZW4u
MTA0NTcxMi5uNS5uYWJibGUuY29tL1JlbGF0aW9uc2hpcC1iZXR3ZWVuLUd1ZXN0T1Mtc2h1dGRv
d24tYW5kLWRlc3Ryb3ktb3BlcmF0aW9ucy10cDU3MTE0MjMuaHRtbApTZW50IGZyb20gdGhlIFhl
biAtIERldiBtYWlsaW5nIGxpc3QgYXJjaGl2ZSBhdCBOYWJibGUuY29tLgoKX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlz
dApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwOi8vbGlzdHMueGVuLm9yZy94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xen.org Fri Sep 21 05:32:33 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Sep 2012 05:32:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TEvqR-0003pX-Oy; Fri, 21 Sep 2012 05:32:07 +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 1TEvqQ-0003pS-59
	for xen-devel@lists.xensource.com; Fri, 21 Sep 2012 05:32:06 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1348205519!4866217!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTA1OTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6428 invoked from network); 21 Sep 2012 05:32:00 -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;
	21 Sep 2012 05:32:00 -0000
X-IronPort-AV: E=Sophos;i="4.80,459,1344211200"; d="scan'208";a="14680002"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Sep 2012 05:31: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.279.1; Fri, 21 Sep 2012 06:31:59 +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 1TEvqI-000541-Sp;
	Fri, 21 Sep 2012 05:31:58 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1TEvqI-0001hD-Om;
	Fri, 21 Sep 2012 06:31:58 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-13825-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 21 Sep 2012 06:31:58 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13825: tolerable trouble:
	broken/fail/pass
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 13825 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13825/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install       fail pass in 13823
 test-amd64-amd64-xl-sedf      3 host-install(3)           broken pass in 13823
 test-amd64-i386-xl-win-vcpus1 12 guest-localmigrate/x10     fail pass in 13823

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore            fail   like 13823
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail like 13823
 test-amd64-amd64-xl-qemuu-winxpsp3 9 guest-localmigrate fail in 13823 blocked in 13825

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop           fail in 13823 never pass

version targeted for testing:
 xen                  d364becfb083
baseline version:
 xen                  d364becfb083

jobs:
 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-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-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-amd64-amd64-xl-sedf                                     broken  
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-amd64-amd64-xl-win                                      fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Published tested tree is already up to date.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 21 05:32:33 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Sep 2012 05:32:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TEvqR-0003pX-Oy; Fri, 21 Sep 2012 05:32:07 +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 1TEvqQ-0003pS-59
	for xen-devel@lists.xensource.com; Fri, 21 Sep 2012 05:32:06 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1348205519!4866217!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTA1OTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6428 invoked from network); 21 Sep 2012 05:32:00 -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;
	21 Sep 2012 05:32:00 -0000
X-IronPort-AV: E=Sophos;i="4.80,459,1344211200"; d="scan'208";a="14680002"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Sep 2012 05:31: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.279.1; Fri, 21 Sep 2012 06:31:59 +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 1TEvqI-000541-Sp;
	Fri, 21 Sep 2012 05:31:58 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1TEvqI-0001hD-Om;
	Fri, 21 Sep 2012 06:31:58 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-13825-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 21 Sep 2012 06:31:58 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13825: tolerable trouble:
	broken/fail/pass
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 13825 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13825/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-qemuu-winxpsp3  7 windows-install       fail pass in 13823
 test-amd64-amd64-xl-sedf      3 host-install(3)           broken pass in 13823
 test-amd64-i386-xl-win-vcpus1 12 guest-localmigrate/x10     fail pass in 13823

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore            fail   like 13823
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail like 13823
 test-amd64-amd64-xl-qemuu-winxpsp3 9 guest-localmigrate fail in 13823 blocked in 13825

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop           fail in 13823 never pass

version targeted for testing:
 xen                  d364becfb083
baseline version:
 xen                  d364becfb083

jobs:
 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-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-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-amd64-amd64-xl-sedf                                     broken  
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-amd64-amd64-xl-win                                      fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Published tested tree is already up to date.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 21 06:03:06 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Sep 2012 06:03:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TEwK0-0004AY-ID; Fri, 21 Sep 2012 06:02:40 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <vivagin@yeah.net>) id 1TEwJx-0004AT-Oh
	for xen-devel@lists.xen.org; Fri, 21 Sep 2012 06:02:38 +0000
Received: from [85.158.139.83:28585] by server-12.bemta-5.messagelabs.com id
	55/AA-22670-DF20C505; Fri, 21 Sep 2012 06:02:37 +0000
X-Env-Sender: vivagin@yeah.net
X-Msg-Ref: server-12.tower-182.messagelabs.com!1348207353!31318430!1
X-Originating-IP: [123.58.178.154]
X-SpamReason: No, hits=0.9 required=7.0 tests=HTML_40_50,HTML_MESSAGE,
	MIME_BASE64_TEXT
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8528 invoked from network); 21 Sep 2012 06:02:35 -0000
Received: from m154-178.yeah.net (HELO m154-177.yeah.net) (123.58.178.154)
	by server-12.tower-182.messagelabs.com with SMTP;
	21 Sep 2012 06:02:35 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yeah.net;
	s=s110527; h=Received:Date:From:To:Subject:Content-Type:
	MIME-Version:Message-ID; bh=tQOp3eqLNdQrpkvE7V9JskN9pLW2j7IqOBbE
	OfIUQHU=; b=TzGzMV8hAdKOyWvIupTqzhn0d21rsdQBfjlSxyNo+yVdxsbVK14r
	9pLKMuKBNFNMmoTNNBlii2fEasyooTlLdAT/QZgZSl6TVTEBYkLXXG9MHhD5w47s
	9bb0pakwCH8E7yKbt+6ru25UH03UYJ7YU7EyECX1f22B0soNSOSKIx4=
Received: from vivagin$yeah.net ( [115.61.24.47] ) by ajax-webmail-app5
	(Coremail) ; Fri, 21 Sep 2012 14:02:28 +0800 (CST)
X-Originating-IP: [115.61.24.47]
Date: Fri, 21 Sep 2012 14:02:28 +0800 (CST)
From: =?GBK?B?0KG7xra5?= <vivagin@yeah.net>
To: "Xen org" <xen-devel@lists.xen.org>
X-Priority: 3
X-Mailer: Coremail Webmail Server Version SP_ntes V3.5 build
	20120914(19817.4926.4909) Copyright (c) 2002-2012 www.mailtech.cn yeah
X-CM-CTRLDATA: hVF7smZvb3Rlcl9odG09MTYwNzo4MQ==
MIME-Version: 1.0
Message-ID: <507ae72.1b8c.139e76b8b4c.Coremail.vivagin@yeah.net>
X-CM-TRANSID: NlUQrEA5p0H1AlxQQ1sDAA--.10305W
X-CM-SenderInfo: 5ylytw1lq65vtdko0vbw/1tbiBAAxak1p3J7YBwABsn
X-Coremail-Antispam: 1U5529EdanIXcx71UUUUU7vcSsGvfC2KfnxnUU==
Subject: [Xen-devel] Relationship between GuestOS shutdown and destroy
 operations?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============7409723075219407153=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============7409723075219407153==
Content-Type: multipart/alternative; 
	boundary="----=_Part_68154_1108488147.1348207348556"

------=_Part_68154_1108488147.1348207348556
Content-Type: text/plain; charset=GBK
Content-Transfer-Encoding: base64

SGVsbG8gZXZlcnlvbmUhCgpJbiBteSBvcGluaW9uLCBJIHRoaW5rIHdoZW4gd2Ugc2h1dGRvd24g
dGhlIEd1ZXN0T1MsCiBYZW4gc2hvdWxkIGZyZWUgYWxsb2NhdGVkIHZjcHUgYW5kIGRvbWFpbiBn
aXZlZCB0byBHdWVzdE9TIAp3aGVuIGl0IGNyZWF0ZWQgYXQgdGhlIHNhbWUgdGltZS4gCgpCdXQg
SSBkb26hr3QgZmluZCBhbnkgY29kZSBpbiBmdW5jdGlvbnMgYXNzb2NpYXRlZCB3aXRoIHNodXRk
b3duIHByb2Nlc3MgdG8Kc2hvdyB0aGlzIHdvcmssCmZvciBleGFtcGxlOiAKSHZtX3ZjcHVfZG93
bigpLaG1ZG9tYWluX3NodXRkb3duKCktPl9fZG9tYWluX2ZpbmFsaXNlX3NodXRkb3duKCkKCkJ1
dCBJIGZpbmQgdGhlIGZ1bmN0aW9ucyBmcmVlX3ZjcHVfc3RydWN0KCkgYW5kIGZyZWVfZG9tYWlu
X3N0cnVjdCgpIAppbiB0aGUgZnVuY3Rpb24gY29tcGxldGVfZG9tYWluX2Rlc3Ryb3koKSBpbiB0
aGUgcHJvY2VzcyBvZiBkZXN0cm95Cm9wZXJhdGlvbiwgCnRoZSBjb2RlIHByb2Nlc3MgaXM6CkRv
bWFpbl9raWxsKCktPnB1dF9kb21haW4oKS0+ZG9tYWluX2Rlc3Ryb3koKS0+Y29tcGxldGVfZG9t
YWluX2Rlc3Ryb3koKQoKSXMgdGhhdCBwcm9jZXNzIHJpZ2h0PyBJcyB0aGVyZSBhbnkgcmVsYXRp
b25zaGlwIGJldHdlZW4gdGhlbT8KRG9lcyBhbnlvbmUga25vdyBpdD8KClRoYW5rcyBmb3IgeW91
ciBoZWxwIQoKCgotLQpWaWV3IHRoaXMgbWVzc2FnZSBpbiBjb250ZXh0OiBodHRwOi8veGVuLjEw
NDU3MTIubjUubmFiYmxlLmNvbS9SZWxhdGlvbnNoaXAtYmV0d2Vlbi1HdWVzdE9TLXNodXRkb3du
LWFuZC1kZXN0cm95LW9wZXJhdGlvbnMtdHA1NzExNDIzLmh0bWwKU2VudCBmcm9tIHRoZSBYZW4g
LSBEZXYgbWFpbGluZyBsaXN0IGFyY2hpdmUgYXQgTmFiYmxlLmNvbS4KCl9fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QK
WGVuLWRldmVsQGxpc3RzLnhlbi5vcmcKaHR0cDovL2xpc3RzLnhlbi5vcmcveGVuLWRldmVsCg==

------=_Part_68154_1108488147.1348207348556
Content-Type: text/html; charset=GBK
Content-Transfer-Encoding: base64

PGRpdiBzdHlsZT0ibGluZS1oZWlnaHQ6MS43O2NvbG9yOiMwMDAwMDA7Zm9udC1zaXplOjE0cHg7
Zm9udC1mYW1pbHk6YXJpYWwiPjxwcmU+SGVsbG8mbmJzcDtldmVyeW9uZSEKCkluJm5ic3A7bXkm
bmJzcDtvcGluaW9uLCZuYnNwO0kmbmJzcDt0aGluayZuYnNwO3doZW4mbmJzcDt3ZSZuYnNwO3No
dXRkb3duJm5ic3A7dGhlJm5ic3A7R3Vlc3RPUywKJm5ic3A7WGVuJm5ic3A7c2hvdWxkJm5ic3A7
ZnJlZSZuYnNwO2FsbG9jYXRlZCZuYnNwO3ZjcHUmbmJzcDthbmQmbmJzcDtkb21haW4mbmJzcDtn
aXZlZCZuYnNwO3RvJm5ic3A7R3Vlc3RPUyZuYnNwOwp3aGVuJm5ic3A7aXQmbmJzcDtjcmVhdGVk
Jm5ic3A7YXQmbmJzcDt0aGUmbmJzcDtzYW1lJm5ic3A7dGltZS4mbmJzcDsKCkJ1dCZuYnNwO0km
bmJzcDtkb26hr3QmbmJzcDtmaW5kJm5ic3A7YW55Jm5ic3A7Y29kZSZuYnNwO2luJm5ic3A7ZnVu
Y3Rpb25zJm5ic3A7YXNzb2NpYXRlZCZuYnNwO3dpdGgmbmJzcDtzaHV0ZG93biZuYnNwO3Byb2Nl
c3MmbmJzcDt0bwpzaG93Jm5ic3A7dGhpcyZuYnNwO3dvcmssCmZvciZuYnNwO2V4YW1wbGU6Jm5i
c3A7Ckh2bV92Y3B1X2Rvd24oKS2htWRvbWFpbl9zaHV0ZG93bigpLSZndDtfX2RvbWFpbl9maW5h
bGlzZV9zaHV0ZG93bigpCgpCdXQmbmJzcDtJJm5ic3A7ZmluZCZuYnNwO3RoZSZuYnNwO2Z1bmN0
aW9ucyZuYnNwO2ZyZWVfdmNwdV9zdHJ1Y3QoKSZuYnNwO2FuZCZuYnNwO2ZyZWVfZG9tYWluX3N0
cnVjdCgpJm5ic3A7CmluJm5ic3A7dGhlJm5ic3A7ZnVuY3Rpb24mbmJzcDtjb21wbGV0ZV9kb21h
aW5fZGVzdHJveSgpJm5ic3A7aW4mbmJzcDt0aGUmbmJzcDtwcm9jZXNzJm5ic3A7b2YmbmJzcDtk
ZXN0cm95Cm9wZXJhdGlvbiwmbmJzcDsKdGhlJm5ic3A7Y29kZSZuYnNwO3Byb2Nlc3MmbmJzcDtp
czoKRG9tYWluX2tpbGwoKS0mZ3Q7cHV0X2RvbWFpbigpLSZndDtkb21haW5fZGVzdHJveSgpLSZn
dDtjb21wbGV0ZV9kb21haW5fZGVzdHJveSgpCgpJcyZuYnNwO3RoYXQmbmJzcDtwcm9jZXNzJm5i
c3A7cmlnaHQ/Jm5ic3A7SXMmbmJzcDt0aGVyZSZuYnNwO2FueSZuYnNwO3JlbGF0aW9uc2hpcCZu
YnNwO2JldHdlZW4mbmJzcDt0aGVtPwpEb2VzJm5ic3A7YW55b25lJm5ic3A7a25vdyZuYnNwO2l0
PwoKVGhhbmtzJm5ic3A7Zm9yJm5ic3A7eW91ciZuYnNwO2hlbHAhCgoKCi0tClZpZXcmbmJzcDt0
aGlzJm5ic3A7bWVzc2FnZSZuYnNwO2luJm5ic3A7Y29udGV4dDombmJzcDtodHRwOi8veGVuLjEw
NDU3MTIubjUubmFiYmxlLmNvbS9SZWxhdGlvbnNoaXAtYmV0d2Vlbi1HdWVzdE9TLXNodXRkb3du
LWFuZC1kZXN0cm95LW9wZXJhdGlvbnMtdHA1NzExNDIzLmh0bWwKU2VudCZuYnNwO2Zyb20mbmJz
cDt0aGUmbmJzcDtYZW4mbmJzcDstJm5ic3A7RGV2Jm5ic3A7bWFpbGluZyZuYnNwO2xpc3QmbmJz
cDthcmNoaXZlJm5ic3A7YXQmbmJzcDtOYWJibGUuY29tLgoKX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVsJm5ic3A7bWFpbGluZyZuYnNwO2xp
c3QKWGVuLWRldmVsQGxpc3RzLnhlbi5vcmcKaHR0cDovL2xpc3RzLnhlbi5vcmcveGVuLWRldmVs
CjwvcHJlPjwvZGl2Pjxicj48YnI+PHNwYW4gdGl0bGU9Im5ldGVhc2Vmb290ZXIiPjxzcGFuIGlk
PSJuZXRlYXNlX21haWxfZm9vdGVyIj48L3NwYW4+PC9zcGFuPg==
------=_Part_68154_1108488147.1348207348556--



--===============7409723075219407153==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============7409723075219407153==--



From xen-devel-bounces@lists.xen.org Fri Sep 21 06:03:06 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Sep 2012 06:03:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TEwK0-0004AY-ID; Fri, 21 Sep 2012 06:02:40 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <vivagin@yeah.net>) id 1TEwJx-0004AT-Oh
	for xen-devel@lists.xen.org; Fri, 21 Sep 2012 06:02:38 +0000
Received: from [85.158.139.83:28585] by server-12.bemta-5.messagelabs.com id
	55/AA-22670-DF20C505; Fri, 21 Sep 2012 06:02:37 +0000
X-Env-Sender: vivagin@yeah.net
X-Msg-Ref: server-12.tower-182.messagelabs.com!1348207353!31318430!1
X-Originating-IP: [123.58.178.154]
X-SpamReason: No, hits=0.9 required=7.0 tests=HTML_40_50,HTML_MESSAGE,
	MIME_BASE64_TEXT
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8528 invoked from network); 21 Sep 2012 06:02:35 -0000
Received: from m154-178.yeah.net (HELO m154-177.yeah.net) (123.58.178.154)
	by server-12.tower-182.messagelabs.com with SMTP;
	21 Sep 2012 06:02:35 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yeah.net;
	s=s110527; h=Received:Date:From:To:Subject:Content-Type:
	MIME-Version:Message-ID; bh=tQOp3eqLNdQrpkvE7V9JskN9pLW2j7IqOBbE
	OfIUQHU=; b=TzGzMV8hAdKOyWvIupTqzhn0d21rsdQBfjlSxyNo+yVdxsbVK14r
	9pLKMuKBNFNMmoTNNBlii2fEasyooTlLdAT/QZgZSl6TVTEBYkLXXG9MHhD5w47s
	9bb0pakwCH8E7yKbt+6ru25UH03UYJ7YU7EyECX1f22B0soNSOSKIx4=
Received: from vivagin$yeah.net ( [115.61.24.47] ) by ajax-webmail-app5
	(Coremail) ; Fri, 21 Sep 2012 14:02:28 +0800 (CST)
X-Originating-IP: [115.61.24.47]
Date: Fri, 21 Sep 2012 14:02:28 +0800 (CST)
From: =?GBK?B?0KG7xra5?= <vivagin@yeah.net>
To: "Xen org" <xen-devel@lists.xen.org>
X-Priority: 3
X-Mailer: Coremail Webmail Server Version SP_ntes V3.5 build
	20120914(19817.4926.4909) Copyright (c) 2002-2012 www.mailtech.cn yeah
X-CM-CTRLDATA: hVF7smZvb3Rlcl9odG09MTYwNzo4MQ==
MIME-Version: 1.0
Message-ID: <507ae72.1b8c.139e76b8b4c.Coremail.vivagin@yeah.net>
X-CM-TRANSID: NlUQrEA5p0H1AlxQQ1sDAA--.10305W
X-CM-SenderInfo: 5ylytw1lq65vtdko0vbw/1tbiBAAxak1p3J7YBwABsn
X-Coremail-Antispam: 1U5529EdanIXcx71UUUUU7vcSsGvfC2KfnxnUU==
Subject: [Xen-devel] Relationship between GuestOS shutdown and destroy
 operations?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============7409723075219407153=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============7409723075219407153==
Content-Type: multipart/alternative; 
	boundary="----=_Part_68154_1108488147.1348207348556"

------=_Part_68154_1108488147.1348207348556
Content-Type: text/plain; charset=GBK
Content-Transfer-Encoding: base64

SGVsbG8gZXZlcnlvbmUhCgpJbiBteSBvcGluaW9uLCBJIHRoaW5rIHdoZW4gd2Ugc2h1dGRvd24g
dGhlIEd1ZXN0T1MsCiBYZW4gc2hvdWxkIGZyZWUgYWxsb2NhdGVkIHZjcHUgYW5kIGRvbWFpbiBn
aXZlZCB0byBHdWVzdE9TIAp3aGVuIGl0IGNyZWF0ZWQgYXQgdGhlIHNhbWUgdGltZS4gCgpCdXQg
SSBkb26hr3QgZmluZCBhbnkgY29kZSBpbiBmdW5jdGlvbnMgYXNzb2NpYXRlZCB3aXRoIHNodXRk
b3duIHByb2Nlc3MgdG8Kc2hvdyB0aGlzIHdvcmssCmZvciBleGFtcGxlOiAKSHZtX3ZjcHVfZG93
bigpLaG1ZG9tYWluX3NodXRkb3duKCktPl9fZG9tYWluX2ZpbmFsaXNlX3NodXRkb3duKCkKCkJ1
dCBJIGZpbmQgdGhlIGZ1bmN0aW9ucyBmcmVlX3ZjcHVfc3RydWN0KCkgYW5kIGZyZWVfZG9tYWlu
X3N0cnVjdCgpIAppbiB0aGUgZnVuY3Rpb24gY29tcGxldGVfZG9tYWluX2Rlc3Ryb3koKSBpbiB0
aGUgcHJvY2VzcyBvZiBkZXN0cm95Cm9wZXJhdGlvbiwgCnRoZSBjb2RlIHByb2Nlc3MgaXM6CkRv
bWFpbl9raWxsKCktPnB1dF9kb21haW4oKS0+ZG9tYWluX2Rlc3Ryb3koKS0+Y29tcGxldGVfZG9t
YWluX2Rlc3Ryb3koKQoKSXMgdGhhdCBwcm9jZXNzIHJpZ2h0PyBJcyB0aGVyZSBhbnkgcmVsYXRp
b25zaGlwIGJldHdlZW4gdGhlbT8KRG9lcyBhbnlvbmUga25vdyBpdD8KClRoYW5rcyBmb3IgeW91
ciBoZWxwIQoKCgotLQpWaWV3IHRoaXMgbWVzc2FnZSBpbiBjb250ZXh0OiBodHRwOi8veGVuLjEw
NDU3MTIubjUubmFiYmxlLmNvbS9SZWxhdGlvbnNoaXAtYmV0d2Vlbi1HdWVzdE9TLXNodXRkb3du
LWFuZC1kZXN0cm95LW9wZXJhdGlvbnMtdHA1NzExNDIzLmh0bWwKU2VudCBmcm9tIHRoZSBYZW4g
LSBEZXYgbWFpbGluZyBsaXN0IGFyY2hpdmUgYXQgTmFiYmxlLmNvbS4KCl9fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QK
WGVuLWRldmVsQGxpc3RzLnhlbi5vcmcKaHR0cDovL2xpc3RzLnhlbi5vcmcveGVuLWRldmVsCg==

------=_Part_68154_1108488147.1348207348556
Content-Type: text/html; charset=GBK
Content-Transfer-Encoding: base64

PGRpdiBzdHlsZT0ibGluZS1oZWlnaHQ6MS43O2NvbG9yOiMwMDAwMDA7Zm9udC1zaXplOjE0cHg7
Zm9udC1mYW1pbHk6YXJpYWwiPjxwcmU+SGVsbG8mbmJzcDtldmVyeW9uZSEKCkluJm5ic3A7bXkm
bmJzcDtvcGluaW9uLCZuYnNwO0kmbmJzcDt0aGluayZuYnNwO3doZW4mbmJzcDt3ZSZuYnNwO3No
dXRkb3duJm5ic3A7dGhlJm5ic3A7R3Vlc3RPUywKJm5ic3A7WGVuJm5ic3A7c2hvdWxkJm5ic3A7
ZnJlZSZuYnNwO2FsbG9jYXRlZCZuYnNwO3ZjcHUmbmJzcDthbmQmbmJzcDtkb21haW4mbmJzcDtn
aXZlZCZuYnNwO3RvJm5ic3A7R3Vlc3RPUyZuYnNwOwp3aGVuJm5ic3A7aXQmbmJzcDtjcmVhdGVk
Jm5ic3A7YXQmbmJzcDt0aGUmbmJzcDtzYW1lJm5ic3A7dGltZS4mbmJzcDsKCkJ1dCZuYnNwO0km
bmJzcDtkb26hr3QmbmJzcDtmaW5kJm5ic3A7YW55Jm5ic3A7Y29kZSZuYnNwO2luJm5ic3A7ZnVu
Y3Rpb25zJm5ic3A7YXNzb2NpYXRlZCZuYnNwO3dpdGgmbmJzcDtzaHV0ZG93biZuYnNwO3Byb2Nl
c3MmbmJzcDt0bwpzaG93Jm5ic3A7dGhpcyZuYnNwO3dvcmssCmZvciZuYnNwO2V4YW1wbGU6Jm5i
c3A7Ckh2bV92Y3B1X2Rvd24oKS2htWRvbWFpbl9zaHV0ZG93bigpLSZndDtfX2RvbWFpbl9maW5h
bGlzZV9zaHV0ZG93bigpCgpCdXQmbmJzcDtJJm5ic3A7ZmluZCZuYnNwO3RoZSZuYnNwO2Z1bmN0
aW9ucyZuYnNwO2ZyZWVfdmNwdV9zdHJ1Y3QoKSZuYnNwO2FuZCZuYnNwO2ZyZWVfZG9tYWluX3N0
cnVjdCgpJm5ic3A7CmluJm5ic3A7dGhlJm5ic3A7ZnVuY3Rpb24mbmJzcDtjb21wbGV0ZV9kb21h
aW5fZGVzdHJveSgpJm5ic3A7aW4mbmJzcDt0aGUmbmJzcDtwcm9jZXNzJm5ic3A7b2YmbmJzcDtk
ZXN0cm95Cm9wZXJhdGlvbiwmbmJzcDsKdGhlJm5ic3A7Y29kZSZuYnNwO3Byb2Nlc3MmbmJzcDtp
czoKRG9tYWluX2tpbGwoKS0mZ3Q7cHV0X2RvbWFpbigpLSZndDtkb21haW5fZGVzdHJveSgpLSZn
dDtjb21wbGV0ZV9kb21haW5fZGVzdHJveSgpCgpJcyZuYnNwO3RoYXQmbmJzcDtwcm9jZXNzJm5i
c3A7cmlnaHQ/Jm5ic3A7SXMmbmJzcDt0aGVyZSZuYnNwO2FueSZuYnNwO3JlbGF0aW9uc2hpcCZu
YnNwO2JldHdlZW4mbmJzcDt0aGVtPwpEb2VzJm5ic3A7YW55b25lJm5ic3A7a25vdyZuYnNwO2l0
PwoKVGhhbmtzJm5ic3A7Zm9yJm5ic3A7eW91ciZuYnNwO2hlbHAhCgoKCi0tClZpZXcmbmJzcDt0
aGlzJm5ic3A7bWVzc2FnZSZuYnNwO2luJm5ic3A7Y29udGV4dDombmJzcDtodHRwOi8veGVuLjEw
NDU3MTIubjUubmFiYmxlLmNvbS9SZWxhdGlvbnNoaXAtYmV0d2Vlbi1HdWVzdE9TLXNodXRkb3du
LWFuZC1kZXN0cm95LW9wZXJhdGlvbnMtdHA1NzExNDIzLmh0bWwKU2VudCZuYnNwO2Zyb20mbmJz
cDt0aGUmbmJzcDtYZW4mbmJzcDstJm5ic3A7RGV2Jm5ic3A7bWFpbGluZyZuYnNwO2xpc3QmbmJz
cDthcmNoaXZlJm5ic3A7YXQmbmJzcDtOYWJibGUuY29tLgoKX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVsJm5ic3A7bWFpbGluZyZuYnNwO2xp
c3QKWGVuLWRldmVsQGxpc3RzLnhlbi5vcmcKaHR0cDovL2xpc3RzLnhlbi5vcmcveGVuLWRldmVs
CjwvcHJlPjwvZGl2Pjxicj48YnI+PHNwYW4gdGl0bGU9Im5ldGVhc2Vmb290ZXIiPjxzcGFuIGlk
PSJuZXRlYXNlX21haWxfZm9vdGVyIj48L3NwYW4+PC9zcGFuPg==
------=_Part_68154_1108488147.1348207348556--



--===============7409723075219407153==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============7409723075219407153==--



From xen-devel-bounces@lists.xen.org Fri Sep 21 06:35:21 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Sep 2012 06:35:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TEwpE-0004UB-5y; Fri, 21 Sep 2012 06:34:56 +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 1TEwpB-0004U6-Rr
	for xen-devel@lists.xen.org; Fri, 21 Sep 2012 06:34:54 +0000
Received: from [85.158.137.99:60663] by server-16.bemta-3.messagelabs.com id
	D6/F4-31776-D8A0C505; Fri, 21 Sep 2012 06:34:53 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-16.tower-217.messagelabs.com!1348209291!18552818!1
X-Originating-IP: [74.125.82.51]
X-SpamReason: No, hits=0.4 required=7.0 tests=MIME_QP_LONG_LINE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2804 invoked from network); 21 Sep 2012 06:34:51 -0000
Received: from mail-wg0-f51.google.com (HELO mail-wg0-f51.google.com)
	(74.125.82.51)
	by server-16.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Sep 2012 06:34:51 -0000
Received: by wgbed3 with SMTP id ed3so1831463wgb.32
	for <xen-devel@lists.xen.org>; Thu, 20 Sep 2012 23:34: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=Ut3IrVQ1Mka5w7+ihRyNPSyEmr1u+G2D1v/jrgpZkVM=;
	b=T9oo32UlvSreKXGrdMZSvoD6d2t+uJJkXC0cIGLA8rGmvjvZj6YZqcGZzda3ueoXwE
	qttblp0TZelY8fdZi6k3BKLnjQOAXvr4asTOzneQJHAcS09a1M2cXwTbKXsfMxnTT9xl
	kM/S81OXW2xhRMR87hnKyBKlYJBh4O5FAkh1W0JW3B7tgxDqFXxGp4yqQmQh9uMFMXXB
	GwGnKkjBxMvFkXA09dzDBS3z+H7ff4RPGeU9y/AVWW8Em3slsp6BZ59m5/i+oiSqTfNg
	+lgBrWBAFvsod9PBXbz2eUuszDJrt1R24pfNxudpPKzGEKKN1LN91wJHhrmdIJCH1Ilq
	hUEQ==
Received: by 10.180.91.163 with SMTP id cf3mr2335529wib.13.1348209291223;
	Thu, 20 Sep 2012 23:34:51 -0700 (PDT)
Received: from [192.168.1.69] (host86-167-82-156.range86-167.btcentralplus.com.
	[86.167.82.156])
	by mx.google.com with ESMTPS id ct3sm36331942wib.5.2012.09.20.23.34.48
	(version=SSLv3 cipher=OTHER); Thu, 20 Sep 2012 23:34:50 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Fri, 21 Sep 2012 07:34:43 +0100
From: Keir Fraser <keir.xen@gmail.com>
To: Ben Guthro <ben@guthro.net>,
	Jan Beulich <JBeulich@suse.com>
Message-ID: <CC81C913.3F4B0%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] Xen4.2 S3 regression?
Thread-Index: Ac2Xwy80QqRxP2MzdEOGB4TuuYclLQ==
In-Reply-To: <CAOvdn6XFy_Teo0x8rBYvY1j+=ZEDAeE4bZ359nVOtgUyb=ZJig@mail.gmail.com>
Mime-version: 1.0
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>, john.baboval@citrix.com,
	Thomas Goetz <thomas.goetz@citrix.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen4.2 S3 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="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gMjAvMDkvMjAxMiAyMTozMCwgIkJlbiBHdXRocm8iIDxiZW5AZ3V0aHJvLm5ldD4gd3JvdGU6
Cgo+IChYRU4pIEJyaW5naW5nIENQVTEgZG93bgo+IChYRU4pIERpc2FibGluZyBDUFUxCj4gKFhF
TikgRGlzYWJsZWQgQ1BVMQo+IChYRU4pIHBsYXlfZGVhZDogQ1BVMQo+IChYRU4pIGNwdV9leGl0
X2NsZWFyOiBDUFUxCj4gKFhFTikgY3B1X3VuaW5pdDogQ1BVMQo+IChYRU4pIENQVTEgZGVhZAoK
U28gQ1BVMSBpcyB0YWtlbiBkb3duIHByb3Blcmx5LCBhcHBhcmVudGx5Li4uCgo+IChYRU4pIEVu
dGVyaW5nIEFDUEkgUzMgc3RhdGUuCgouLi4gRHVyaW5nIFMzIHN1c3BlbmQuCgo+IChYRU4pIEZp
bmlzaGluZyB3YWtldXAgZnJvbSBBQ1BJIFMzIHN0YXRlLgo+IChYRU4pIEVuYWJsaW5nIG5vbi1i
b290IENQVXMgwqAuLi4KPiAoWEVOKSBCcmluZ2luZyBDUFUxIHVwCj4gKFhFTikgU2V0dGluZyB3
YXJtIHJlc2V0IGNvZGUgYW5kIHZlY3Rvci4KPiAoWEVOKSBBc3NlcnRpbmcgSU5JVC4KPiAoWEVO
KSBXYWl0aW5nIGZvciBzZW5kIHRvIGZpbmlzaC4uLgo+IChYRU4pICtEZWFzc2VydGluZyBJTklU
Lgo+IChYRU4pIFdhaXRpbmcgZm9yIHNlbmQgdG8gZmluaXNoLi4uCj4gKFhFTikgKyNzdGFydHVw
IGxvb3BzOiAyLgo+IChYRU4pIFNlbmRpbmcgU1RBUlRVUCAjMS4KPiAoWEVOKSBBZnRlciBhcGlj
X3dyaXRlLgo+IChYRU4pIENQVSMxIGFscmVhZHkgaW5pdGlhbGl6ZWQhCgpCdXQgaGVyZSBDUFUx
IHRoaW5rcyBpdCBpcyBhbHJlYWR5IGluaXRpYWxpc2VkISAqVGhpcyogaXMgdGhlIGJ1ZyB5b3Ug
bmVlZAp0byBnbyBsb29rIGF0LiBDUFUxIHdpbGwgc3BpbiBhdCB0aGlzIHBvaW50Li4uCgo+IChY
RU4pIFN0YXJ0dXAgcG9pbnQgMS4KPiAoWEVOKSBXYWl0aW5nIGZvciBzZW5kIHRvIGZpbmlzaC4u
Lgo+IChYRU4pICtTZW5kaW5nIFNUQVJUVVAgIzIuCj4gKFhFTikgQWZ0ZXIgYXBpY193cml0ZS4K
PiAoWEVOKSBTdGFydHVwIHBvaW50IDEuCj4gKFhFTikgV2FpdGluZyBmb3Igc2VuZCB0byBmaW5p
c2guLi4KPiAoWEVOKSArQWZ0ZXIgU3RhcnR1cC4KPiAoWEVOKSBBZnRlciBDYWxsb3V0IDEuCj4g
KFhFTikgU3R1Y2sgPz8KCi4uLkNhdXNpbmcgQ1BVMCB0byB0aGluayBDUFUxIGlzIHN0dWNrICh3
aGljaCBpcyBmYWlyLCBiZWNhdXNlIGl0IGlzKS4KCj4gKFhFTikgY3B1X2V4aXRfY2xlYXI6IENQ
VTEKPiAoWEVOKSBjcHVfdW5pbml0OiBDUFUxCj4gKFhFTikgX19jcHVfdXAgLSBkb19ib290X2Nw
dSBlcnJvcgo+IChYRU4pIGNwdV91cCBDUFUxIENQVSBub3QgdXAKPiAoWEVOKSBjcHVfdXAgQ1BV
MSBmYWlsCj4gKFhFTikgRXJyb3IgdGFraW5nIENQVTEgdXA6IC01Cj4gWyDCoCAzMi43ODAwNTVd
IEFDUEk6IExvdy1sZXZlbCByZXN1bWUgY29tcGxldGUKPiBbIMKgIDMyLjc4MDA1NV0gUE06IFJl
c3RvcmluZyBwbGF0Zm9ybSBOVlMgbWVtb3J5Cj4gWyDCoCAzMi43ODAwNTVdIEVuYWJsaW5nIG5v
bi1ib290IENQVXMgLi4uCj4gCj4gdGhlbiBpdCBjcmFzaGVzLgo+IAo+IEl0IHNlZW1zIHRoYXQg
aXQgaXMgYWx3YXlzIGZhbGxpbmcgdGhyb3VnaCBpbnRvIHRoZSAiZWxzZSIgY2xhdXNlIG9mCj4g
dGhlwqBkb19ib290X2NwdSgpIGZ1bmN0aW9uIHdoZW4gYXR0ZW1wdGluZyB0byBicmluZyBpdCBi
YWNrIHVwLCBzZWVtaW5nbHkKPiBzdHVjayBpbsKgQ1BVX1NUQVRFX0NBTExPVVQKPiAKPiBBbnkg
aWRlYXMgYXMgdG8gd2hhdCBtaWdodCBiZSBjYXVzaW5nIGl0IHRvIGdldCBzdHVjayBpbiB0aGF0
IHN0YXRlPwoKWWVzLCBzZWUgZXhwbGFuYXRpb24gYWJvdmUsIHdoaWNoIGlzIGFjdHVhbGx5IHRo
ZSBzYW1lIGV4cGxhbmF0aW9uIEkgZ2F2ZQp5b3UgYmVmb3JlLiBZb3UgbmVlZCB0byBnbyBpbnZl
c3RpZ2F0ZSB3aHkgQ1BVMSBpcyBnZXR0aW5nIGNvbmZ1c2VkIGluCmNwdV9pbml0KCkuCgogLS0g
S2VpcgoKPiAKPiAKPiAKPiDCoAo+PiBJIHB1dCBhIGNwdSBpZCBjb25kaXRpb25hbCBCVUcoKSBj
YWxsIGluIHRoZXJlLCB0byB2ZXJpZnkgLSBhbmQgd2hpbGUgaXQgaXMKPj4gcmVhY2hlZCB3aGVu
IHVzaW5nwqAKPj4geGVuLWhwdG9vbCBjcHUtb2ZmbGluZSAxCj4+IEl0IG5ldmVyIHNlZW1zIHRv
IGJlIHJlYWNoZWQgZnJvbSB0aGUgUzMgcGF0aC4KPj4gCj4+IAo+PiBXaGF0IGlzIHRoZSBleHBl
Y3RlZCBjYWxsIGNoYWluIHRvIGdldCBpbnRvIHRoaXMgY29kZSBkdXJpbmcgUzM/Cj4+IAo+PiAK
Pj4gT24gVGh1LCBTZXAgMjAsIDIwMTIgYXQgNDowMyBBTSwgSmFuIEJldWxpY2ggPEpCZXVsaWNo
QHN1c2UuY29tPiB3cm90ZToKPj4+Pj4+IE9uIDIwLjA5LjEyIGF0IDA4OjEzLCBLZWlyIEZyYXNl
ciA8a2Vpci54ZW5AZ21haWwuY29tPiB3cm90ZToKPj4+PiBDUFUjMSBnb3Qgc3R1Y2sgaW4gbG9v
cCBpbiBjcHVfaW5pdCgpIGFzIGl0IGFwcGVhcnMgdG8gYmUgxZJhbHJlYWR5Cj4+Pj4gaW5pdGlh
bGlzZWTCuSBpbiBjcHVfaW5pdGlhbGl6ZWQgYml0bWFwLiBDUFUjMCBkZXRlY3RzIGl0IGlzIHN0
dWNrIGFuZAo+Pj4+IGNhcnJpZXMgb24sIGJ1dCB0aGUgcmVzdW1lIGNvZGUgYXNzdW1lcyBhbGwg
Q1BVcyBhcmUgYnJvdWdodCBiYWNrIG9ubGluZQo+Pj4+IGFuZAo+Pj4+IGNyYXNoZXMgbGF0ZXIu
Cj4+PiAKPj4+IFNvIHRoaXMgd291bGQgc3VnZ2VzdCBwbGF5X2RlYWQoKSAoLT4gY3B1X2V4aXRf
Y2xlYXIoKSAtPgo+Pj4gY3B1X3VuaW5pdCgpKSBub3QgZ2V0dGluZyByZWFjaGVkIGR1cmluZyB0
aGUgc3VzcGVuZCBjeWNsZS4KPj4+IFRoYXQgc2hvdWxkIGJlIGZhaXJseSBlYXN5IHRvIHZlcmlm
eSwgYXMgdGhlIHNlcmlhbCBjb25zb2xlCj4+PiBvdWdodCB0byBzdGlsbCB3b3JrIHdoZW4gdGhl
IHNlY29uZGFyeSBDUFVzIGdldCBvZmZsaW5lZC4KPj4+IAo+Pj4gVGhhdCBtaWdodCBpbXBseSBj
cHVtYXNrX2NsZWFyX2NwdShjcHUsICZjcHVfb25saW5lX21hcCkKPj4+IG5vdCBnZXR0aW5nIHJl
YWNoZWQgaW4gX19jcHVfZGlzYWJsZSgpLCB3aGljaCB3b3VsZCBiZSBpbiBsaW5lCj4+PiB3aXRo
IHRoZSBvYnNlcnZhdGlvbiB0aGF0IG5vbmUgb2YgdGhlIGxvZ3MgcHJvdmlkZWQgc28gZmFyCj4+
PiBzaG93ZWQgYW55dGhpbmcgYmVpbmcgZG9uZSBieSBmaXh1cF9pcnFzKCkgKGNhbGxlZCByaWdo
dAo+Pj4gYWZ0ZXIgY2xlYXJpbmcgdGhlIG9ubGluZSBiaXQpLgo+Pj4gCj4+PiBKYW4KPj4gCj4g
Cj4gCgoKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fClhl
bi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbi5vcmcKaHR0cDovL2xpc3Rz
Lnhlbi5vcmcveGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Fri Sep 21 06:35:21 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Sep 2012 06:35:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TEwpE-0004UB-5y; Fri, 21 Sep 2012 06:34:56 +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 1TEwpB-0004U6-Rr
	for xen-devel@lists.xen.org; Fri, 21 Sep 2012 06:34:54 +0000
Received: from [85.158.137.99:60663] by server-16.bemta-3.messagelabs.com id
	D6/F4-31776-D8A0C505; Fri, 21 Sep 2012 06:34:53 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-16.tower-217.messagelabs.com!1348209291!18552818!1
X-Originating-IP: [74.125.82.51]
X-SpamReason: No, hits=0.4 required=7.0 tests=MIME_QP_LONG_LINE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2804 invoked from network); 21 Sep 2012 06:34:51 -0000
Received: from mail-wg0-f51.google.com (HELO mail-wg0-f51.google.com)
	(74.125.82.51)
	by server-16.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Sep 2012 06:34:51 -0000
Received: by wgbed3 with SMTP id ed3so1831463wgb.32
	for <xen-devel@lists.xen.org>; Thu, 20 Sep 2012 23:34: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=Ut3IrVQ1Mka5w7+ihRyNPSyEmr1u+G2D1v/jrgpZkVM=;
	b=T9oo32UlvSreKXGrdMZSvoD6d2t+uJJkXC0cIGLA8rGmvjvZj6YZqcGZzda3ueoXwE
	qttblp0TZelY8fdZi6k3BKLnjQOAXvr4asTOzneQJHAcS09a1M2cXwTbKXsfMxnTT9xl
	kM/S81OXW2xhRMR87hnKyBKlYJBh4O5FAkh1W0JW3B7tgxDqFXxGp4yqQmQh9uMFMXXB
	GwGnKkjBxMvFkXA09dzDBS3z+H7ff4RPGeU9y/AVWW8Em3slsp6BZ59m5/i+oiSqTfNg
	+lgBrWBAFvsod9PBXbz2eUuszDJrt1R24pfNxudpPKzGEKKN1LN91wJHhrmdIJCH1Ilq
	hUEQ==
Received: by 10.180.91.163 with SMTP id cf3mr2335529wib.13.1348209291223;
	Thu, 20 Sep 2012 23:34:51 -0700 (PDT)
Received: from [192.168.1.69] (host86-167-82-156.range86-167.btcentralplus.com.
	[86.167.82.156])
	by mx.google.com with ESMTPS id ct3sm36331942wib.5.2012.09.20.23.34.48
	(version=SSLv3 cipher=OTHER); Thu, 20 Sep 2012 23:34:50 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Fri, 21 Sep 2012 07:34:43 +0100
From: Keir Fraser <keir.xen@gmail.com>
To: Ben Guthro <ben@guthro.net>,
	Jan Beulich <JBeulich@suse.com>
Message-ID: <CC81C913.3F4B0%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] Xen4.2 S3 regression?
Thread-Index: Ac2Xwy80QqRxP2MzdEOGB4TuuYclLQ==
In-Reply-To: <CAOvdn6XFy_Teo0x8rBYvY1j+=ZEDAeE4bZ359nVOtgUyb=ZJig@mail.gmail.com>
Mime-version: 1.0
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>, john.baboval@citrix.com,
	Thomas Goetz <thomas.goetz@citrix.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen4.2 S3 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="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gMjAvMDkvMjAxMiAyMTozMCwgIkJlbiBHdXRocm8iIDxiZW5AZ3V0aHJvLm5ldD4gd3JvdGU6
Cgo+IChYRU4pIEJyaW5naW5nIENQVTEgZG93bgo+IChYRU4pIERpc2FibGluZyBDUFUxCj4gKFhF
TikgRGlzYWJsZWQgQ1BVMQo+IChYRU4pIHBsYXlfZGVhZDogQ1BVMQo+IChYRU4pIGNwdV9leGl0
X2NsZWFyOiBDUFUxCj4gKFhFTikgY3B1X3VuaW5pdDogQ1BVMQo+IChYRU4pIENQVTEgZGVhZAoK
U28gQ1BVMSBpcyB0YWtlbiBkb3duIHByb3Blcmx5LCBhcHBhcmVudGx5Li4uCgo+IChYRU4pIEVu
dGVyaW5nIEFDUEkgUzMgc3RhdGUuCgouLi4gRHVyaW5nIFMzIHN1c3BlbmQuCgo+IChYRU4pIEZp
bmlzaGluZyB3YWtldXAgZnJvbSBBQ1BJIFMzIHN0YXRlLgo+IChYRU4pIEVuYWJsaW5nIG5vbi1i
b290IENQVXMgwqAuLi4KPiAoWEVOKSBCcmluZ2luZyBDUFUxIHVwCj4gKFhFTikgU2V0dGluZyB3
YXJtIHJlc2V0IGNvZGUgYW5kIHZlY3Rvci4KPiAoWEVOKSBBc3NlcnRpbmcgSU5JVC4KPiAoWEVO
KSBXYWl0aW5nIGZvciBzZW5kIHRvIGZpbmlzaC4uLgo+IChYRU4pICtEZWFzc2VydGluZyBJTklU
Lgo+IChYRU4pIFdhaXRpbmcgZm9yIHNlbmQgdG8gZmluaXNoLi4uCj4gKFhFTikgKyNzdGFydHVw
IGxvb3BzOiAyLgo+IChYRU4pIFNlbmRpbmcgU1RBUlRVUCAjMS4KPiAoWEVOKSBBZnRlciBhcGlj
X3dyaXRlLgo+IChYRU4pIENQVSMxIGFscmVhZHkgaW5pdGlhbGl6ZWQhCgpCdXQgaGVyZSBDUFUx
IHRoaW5rcyBpdCBpcyBhbHJlYWR5IGluaXRpYWxpc2VkISAqVGhpcyogaXMgdGhlIGJ1ZyB5b3Ug
bmVlZAp0byBnbyBsb29rIGF0LiBDUFUxIHdpbGwgc3BpbiBhdCB0aGlzIHBvaW50Li4uCgo+IChY
RU4pIFN0YXJ0dXAgcG9pbnQgMS4KPiAoWEVOKSBXYWl0aW5nIGZvciBzZW5kIHRvIGZpbmlzaC4u
Lgo+IChYRU4pICtTZW5kaW5nIFNUQVJUVVAgIzIuCj4gKFhFTikgQWZ0ZXIgYXBpY193cml0ZS4K
PiAoWEVOKSBTdGFydHVwIHBvaW50IDEuCj4gKFhFTikgV2FpdGluZyBmb3Igc2VuZCB0byBmaW5p
c2guLi4KPiAoWEVOKSArQWZ0ZXIgU3RhcnR1cC4KPiAoWEVOKSBBZnRlciBDYWxsb3V0IDEuCj4g
KFhFTikgU3R1Y2sgPz8KCi4uLkNhdXNpbmcgQ1BVMCB0byB0aGluayBDUFUxIGlzIHN0dWNrICh3
aGljaCBpcyBmYWlyLCBiZWNhdXNlIGl0IGlzKS4KCj4gKFhFTikgY3B1X2V4aXRfY2xlYXI6IENQ
VTEKPiAoWEVOKSBjcHVfdW5pbml0OiBDUFUxCj4gKFhFTikgX19jcHVfdXAgLSBkb19ib290X2Nw
dSBlcnJvcgo+IChYRU4pIGNwdV91cCBDUFUxIENQVSBub3QgdXAKPiAoWEVOKSBjcHVfdXAgQ1BV
MSBmYWlsCj4gKFhFTikgRXJyb3IgdGFraW5nIENQVTEgdXA6IC01Cj4gWyDCoCAzMi43ODAwNTVd
IEFDUEk6IExvdy1sZXZlbCByZXN1bWUgY29tcGxldGUKPiBbIMKgIDMyLjc4MDA1NV0gUE06IFJl
c3RvcmluZyBwbGF0Zm9ybSBOVlMgbWVtb3J5Cj4gWyDCoCAzMi43ODAwNTVdIEVuYWJsaW5nIG5v
bi1ib290IENQVXMgLi4uCj4gCj4gdGhlbiBpdCBjcmFzaGVzLgo+IAo+IEl0IHNlZW1zIHRoYXQg
aXQgaXMgYWx3YXlzIGZhbGxpbmcgdGhyb3VnaCBpbnRvIHRoZSAiZWxzZSIgY2xhdXNlIG9mCj4g
dGhlwqBkb19ib290X2NwdSgpIGZ1bmN0aW9uIHdoZW4gYXR0ZW1wdGluZyB0byBicmluZyBpdCBi
YWNrIHVwLCBzZWVtaW5nbHkKPiBzdHVjayBpbsKgQ1BVX1NUQVRFX0NBTExPVVQKPiAKPiBBbnkg
aWRlYXMgYXMgdG8gd2hhdCBtaWdodCBiZSBjYXVzaW5nIGl0IHRvIGdldCBzdHVjayBpbiB0aGF0
IHN0YXRlPwoKWWVzLCBzZWUgZXhwbGFuYXRpb24gYWJvdmUsIHdoaWNoIGlzIGFjdHVhbGx5IHRo
ZSBzYW1lIGV4cGxhbmF0aW9uIEkgZ2F2ZQp5b3UgYmVmb3JlLiBZb3UgbmVlZCB0byBnbyBpbnZl
c3RpZ2F0ZSB3aHkgQ1BVMSBpcyBnZXR0aW5nIGNvbmZ1c2VkIGluCmNwdV9pbml0KCkuCgogLS0g
S2VpcgoKPiAKPiAKPiAKPiDCoAo+PiBJIHB1dCBhIGNwdSBpZCBjb25kaXRpb25hbCBCVUcoKSBj
YWxsIGluIHRoZXJlLCB0byB2ZXJpZnkgLSBhbmQgd2hpbGUgaXQgaXMKPj4gcmVhY2hlZCB3aGVu
IHVzaW5nwqAKPj4geGVuLWhwdG9vbCBjcHUtb2ZmbGluZSAxCj4+IEl0IG5ldmVyIHNlZW1zIHRv
IGJlIHJlYWNoZWQgZnJvbSB0aGUgUzMgcGF0aC4KPj4gCj4+IAo+PiBXaGF0IGlzIHRoZSBleHBl
Y3RlZCBjYWxsIGNoYWluIHRvIGdldCBpbnRvIHRoaXMgY29kZSBkdXJpbmcgUzM/Cj4+IAo+PiAK
Pj4gT24gVGh1LCBTZXAgMjAsIDIwMTIgYXQgNDowMyBBTSwgSmFuIEJldWxpY2ggPEpCZXVsaWNo
QHN1c2UuY29tPiB3cm90ZToKPj4+Pj4+IE9uIDIwLjA5LjEyIGF0IDA4OjEzLCBLZWlyIEZyYXNl
ciA8a2Vpci54ZW5AZ21haWwuY29tPiB3cm90ZToKPj4+PiBDUFUjMSBnb3Qgc3R1Y2sgaW4gbG9v
cCBpbiBjcHVfaW5pdCgpIGFzIGl0IGFwcGVhcnMgdG8gYmUgxZJhbHJlYWR5Cj4+Pj4gaW5pdGlh
bGlzZWTCuSBpbiBjcHVfaW5pdGlhbGl6ZWQgYml0bWFwLiBDUFUjMCBkZXRlY3RzIGl0IGlzIHN0
dWNrIGFuZAo+Pj4+IGNhcnJpZXMgb24sIGJ1dCB0aGUgcmVzdW1lIGNvZGUgYXNzdW1lcyBhbGwg
Q1BVcyBhcmUgYnJvdWdodCBiYWNrIG9ubGluZQo+Pj4+IGFuZAo+Pj4+IGNyYXNoZXMgbGF0ZXIu
Cj4+PiAKPj4+IFNvIHRoaXMgd291bGQgc3VnZ2VzdCBwbGF5X2RlYWQoKSAoLT4gY3B1X2V4aXRf
Y2xlYXIoKSAtPgo+Pj4gY3B1X3VuaW5pdCgpKSBub3QgZ2V0dGluZyByZWFjaGVkIGR1cmluZyB0
aGUgc3VzcGVuZCBjeWNsZS4KPj4+IFRoYXQgc2hvdWxkIGJlIGZhaXJseSBlYXN5IHRvIHZlcmlm
eSwgYXMgdGhlIHNlcmlhbCBjb25zb2xlCj4+PiBvdWdodCB0byBzdGlsbCB3b3JrIHdoZW4gdGhl
IHNlY29uZGFyeSBDUFVzIGdldCBvZmZsaW5lZC4KPj4+IAo+Pj4gVGhhdCBtaWdodCBpbXBseSBj
cHVtYXNrX2NsZWFyX2NwdShjcHUsICZjcHVfb25saW5lX21hcCkKPj4+IG5vdCBnZXR0aW5nIHJl
YWNoZWQgaW4gX19jcHVfZGlzYWJsZSgpLCB3aGljaCB3b3VsZCBiZSBpbiBsaW5lCj4+PiB3aXRo
IHRoZSBvYnNlcnZhdGlvbiB0aGF0IG5vbmUgb2YgdGhlIGxvZ3MgcHJvdmlkZWQgc28gZmFyCj4+
PiBzaG93ZWQgYW55dGhpbmcgYmVpbmcgZG9uZSBieSBmaXh1cF9pcnFzKCkgKGNhbGxlZCByaWdo
dAo+Pj4gYWZ0ZXIgY2xlYXJpbmcgdGhlIG9ubGluZSBiaXQpLgo+Pj4gCj4+PiBKYW4KPj4gCj4g
Cj4gCgoKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fClhl
bi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbi5vcmcKaHR0cDovL2xpc3Rz
Lnhlbi5vcmcveGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Fri Sep 21 06:45:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Sep 2012 06: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 1TEwyu-0004db-A7; Fri, 21 Sep 2012 06:44:56 +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 1TEwys-0004dW-Up
	for xen-devel@lists.xensource.com; Fri, 21 Sep 2012 06:44:55 +0000
Received: from [85.158.137.99:7608] by server-12.bemta-3.messagelabs.com id
	13/42-10384-6EC0C505; Fri, 21 Sep 2012 06:44:54 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-10.tower-217.messagelabs.com!1348209892!18568371!1
X-Originating-IP: [143.182.124.21]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMjEgPT4gMjA2Mjk1\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25997 invoked from network); 21 Sep 2012 06:44:53 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (143.182.124.21)
	by server-10.tower-217.messagelabs.com with SMTP;
	21 Sep 2012 06:44:53 -0000
Received: from azsmga001.ch.intel.com ([10.2.17.19])
	by azsmga101.ch.intel.com with ESMTP; 20 Sep 2012 23:44:41 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.80,460,1344236400"; d="scan'208";a="195355701"
Received: from fmsmsx104.amr.corp.intel.com ([10.19.9.35])
	by azsmga001.ch.intel.com with ESMTP; 20 Sep 2012 23:44:34 -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; Thu, 20 Sep 2012 23:44:33 -0700
Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by
	fmsmsx109.amr.corp.intel.com (10.19.9.28) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Thu, 20 Sep 2012 23:44:33 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.239]) by
	SHSMSX102.ccr.corp.intel.com ([169.254.2.92]) with mapi id
	14.01.0355.002; Fri, 21 Sep 2012 14:44:30 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: Christoph Egger <Christoph.Egger@amd.com>, "xen-devel@lists.xensource.com"
	<xen-devel@lists.xensource.com>
Thread-Topic: comments for c/s 25919 Xen mce
Thread-Index: Ac2XxI0Om0PxwQPZS1qiRYz6p8f4jw==
Date: Fri, 21 Sep 2012 06:44:30 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC8292335332DA5@SHSMSX101.ccr.corp.intel.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: "keir@xen.org" <keir@xen.org>, Jan Beulich <JBeulich@suse.com>
Subject: [Xen-devel] comments for c/s 25919 Xen mce
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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, Keir, Jan

I have a draft look at c/s 25919. It moves some mce_intel.c logic to mce.c (and remove old mce.c logic). By draft reviewing the patch I think it need more work to do, and currently it in fact would hung at AMD platform (I have no AMD platform to test), i.e, MACHINE_CHECK_SOFTIRQ --> mce_delayed_action() --> mce_action() --> ASSERT(handler_num);

For AMD mce it may need add (if any misunderstanding please point to me)
1). add default handler which used at softirq context
2). add AMD vmce inject logic
3). more test

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 Fri Sep 21 06:45:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Sep 2012 06: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 1TEwyu-0004db-A7; Fri, 21 Sep 2012 06:44:56 +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 1TEwys-0004dW-Up
	for xen-devel@lists.xensource.com; Fri, 21 Sep 2012 06:44:55 +0000
Received: from [85.158.137.99:7608] by server-12.bemta-3.messagelabs.com id
	13/42-10384-6EC0C505; Fri, 21 Sep 2012 06:44:54 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-10.tower-217.messagelabs.com!1348209892!18568371!1
X-Originating-IP: [143.182.124.21]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMjEgPT4gMjA2Mjk1\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25997 invoked from network); 21 Sep 2012 06:44:53 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (143.182.124.21)
	by server-10.tower-217.messagelabs.com with SMTP;
	21 Sep 2012 06:44:53 -0000
Received: from azsmga001.ch.intel.com ([10.2.17.19])
	by azsmga101.ch.intel.com with ESMTP; 20 Sep 2012 23:44:41 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.80,460,1344236400"; d="scan'208";a="195355701"
Received: from fmsmsx104.amr.corp.intel.com ([10.19.9.35])
	by azsmga001.ch.intel.com with ESMTP; 20 Sep 2012 23:44:34 -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; Thu, 20 Sep 2012 23:44:33 -0700
Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by
	fmsmsx109.amr.corp.intel.com (10.19.9.28) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Thu, 20 Sep 2012 23:44:33 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.239]) by
	SHSMSX102.ccr.corp.intel.com ([169.254.2.92]) with mapi id
	14.01.0355.002; Fri, 21 Sep 2012 14:44:30 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: Christoph Egger <Christoph.Egger@amd.com>, "xen-devel@lists.xensource.com"
	<xen-devel@lists.xensource.com>
Thread-Topic: comments for c/s 25919 Xen mce
Thread-Index: Ac2XxI0Om0PxwQPZS1qiRYz6p8f4jw==
Date: Fri, 21 Sep 2012 06:44:30 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC8292335332DA5@SHSMSX101.ccr.corp.intel.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: "keir@xen.org" <keir@xen.org>, Jan Beulich <JBeulich@suse.com>
Subject: [Xen-devel] comments for c/s 25919 Xen mce
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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, Keir, Jan

I have a draft look at c/s 25919. It moves some mce_intel.c logic to mce.c (and remove old mce.c logic). By draft reviewing the patch I think it need more work to do, and currently it in fact would hung at AMD platform (I have no AMD platform to test), i.e, MACHINE_CHECK_SOFTIRQ --> mce_delayed_action() --> mce_action() --> ASSERT(handler_num);

For AMD mce it may need add (if any misunderstanding please point to me)
1). add default handler which used at softirq context
2). add AMD vmce inject logic
3). more test

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 Fri Sep 21 06:48:11 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Sep 2012 06:48:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TEx1m-0004jQ-St; Fri, 21 Sep 2012 06:47:54 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1TEx1l-0004jH-I3
	for xen-devel@lists.xen.org; Fri, 21 Sep 2012 06:47:53 +0000
Received: from [85.158.137.99:23447] by server-2.bemta-3.messagelabs.com id
	AB/5F-04862-89D0C505; Fri, 21 Sep 2012 06:47:52 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-16.tower-217.messagelabs.com!1348210070!18554272!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10155 invoked from network); 21 Sep 2012 06:47:50 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-16.tower-217.messagelabs.com with SMTP;
	21 Sep 2012 06:47:50 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 21 Sep 2012 07:47:49 +0100
Message-Id: <505C29B3020000780009CDA2@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 21 Sep 2012 07:47:47 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ben Guthro" <ben@guthro.net>
References: <CAOvdn6Xn1ZnontBO0KoJE9hgBsW-a1rR2EhWYEpgbbrELkXZNw@mail.gmail.com>
	<CC80728B.3F362%keir.xen@gmail.com>
	<505AE9DB020000780009C813@nat28.tlf.novell.com>
	<CAOvdn6VF+1KP0EkzwkoAEoc=B2bcLUWteOM8HmN-cj_YosN-pw@mail.gmail.com>
	<CAOvdn6XFy_Teo0x8rBYvY1j+=ZEDAeE4bZ359nVOtgUyb=ZJig@mail.gmail.com>
In-Reply-To: <CAOvdn6XFy_Teo0x8rBYvY1j+=ZEDAeE4bZ359nVOtgUyb=ZJig@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Keir Fraser <keir.xen@gmail.com>, john.baboval@citrix.com,
	Thomas Goetz <thomas.goetz@citrix.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen4.2 S3 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 20.09.12 at 22:30, Ben Guthro <ben@guthro.net> wrote:
> On Thu, Sep 20, 2012 at 8:56 AM, Ben Guthro <ben@guthro.net> wrote:
> [   32.145824] ACPI: Preparing to enter system sleep state S3
> [   32.600118] PM: Saving platform NVS memory
> [   32.671666] Disabling non-boot CPUs ...
> (XEN) Preparing system for ACPI S3 state.
> (XEN) Disabling non-boot CPUs ...
> (XEN) Bringing CPU1 down
> (XEN) Disabling CPU1
> (XEN) Disabled CPU1
> (XEN) play_dead: CPU1
> (XEN) cpu_exit_clear: CPU1
> (XEN) cpu_uninit: CPU1
> (XEN) CPU1 dead

So how about inserting printout of cpu_initialized here ...

> (XEN) Entering ACPI S3 state.
> (XEN) Finishing wakeup from ACPI S3 state.
> (XEN) Enabling non-boot CPUs  ...

... and here?

Plus adding "cpuinfo" to the Xen command line, which would allow
us to see whether CPU1 gets into cpu_init() twice.

Perhaps tracking cpu_state throughout the below sequence might
also be useful.

> (XEN) Bringing CPU1 up
> (XEN) Setting warm reset code and vector.
> (XEN) Asserting INIT.
> (XEN) Waiting for send to finish...
> (XEN) +Deasserting INIT.
> (XEN) Waiting for send to finish...
> (XEN) +#startup loops: 2.
> (XEN) Sending STARTUP #1.
> (XEN) After apic_write.
> (XEN) CPU#1 already initialized!
> (XEN) Startup point 1.
> (XEN) Waiting for send to finish...
> (XEN) +Sending STARTUP #2.
> (XEN) After apic_write.
> (XEN) Startup point 1.
> (XEN) Waiting for send to finish...
> (XEN) +After Startup.
> (XEN) After Callout 1.
> (XEN) Stuck ??
> (XEN) cpu_exit_clear: CPU1
> (XEN) cpu_uninit: CPU1
> (XEN) __cpu_up - do_boot_cpu error
> (XEN) cpu_up CPU1 CPU not up
> (XEN) cpu_up CPU1 fail
> (XEN) Error taking CPU1 up: -5
> [   32.780055] ACPI: Low-level resume complete
> [   32.780055] PM: Restoring platform NVS memory
> [   32.780055] Enabling non-boot CPUs ...
> 
> then it crashes.
> 
> It seems that it is always falling through into the "else" clause of
> the do_boot_cpu() function when attempting to bring it back up, seemingly
> stuck in CPU_STATE_CALLOUT
> 
> 
> Any ideas as to what might be causing it to get stuck in that state?

That's because CPU1 is stuck in cpu_init() (in the infinite loop after
printing "CPU#1 already initialized!"), as Keir pointed out yesterday.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 21 06:48:11 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Sep 2012 06:48:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TEx1m-0004jQ-St; Fri, 21 Sep 2012 06:47:54 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1TEx1l-0004jH-I3
	for xen-devel@lists.xen.org; Fri, 21 Sep 2012 06:47:53 +0000
Received: from [85.158.137.99:23447] by server-2.bemta-3.messagelabs.com id
	AB/5F-04862-89D0C505; Fri, 21 Sep 2012 06:47:52 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-16.tower-217.messagelabs.com!1348210070!18554272!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10155 invoked from network); 21 Sep 2012 06:47:50 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-16.tower-217.messagelabs.com with SMTP;
	21 Sep 2012 06:47:50 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 21 Sep 2012 07:47:49 +0100
Message-Id: <505C29B3020000780009CDA2@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 21 Sep 2012 07:47:47 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ben Guthro" <ben@guthro.net>
References: <CAOvdn6Xn1ZnontBO0KoJE9hgBsW-a1rR2EhWYEpgbbrELkXZNw@mail.gmail.com>
	<CC80728B.3F362%keir.xen@gmail.com>
	<505AE9DB020000780009C813@nat28.tlf.novell.com>
	<CAOvdn6VF+1KP0EkzwkoAEoc=B2bcLUWteOM8HmN-cj_YosN-pw@mail.gmail.com>
	<CAOvdn6XFy_Teo0x8rBYvY1j+=ZEDAeE4bZ359nVOtgUyb=ZJig@mail.gmail.com>
In-Reply-To: <CAOvdn6XFy_Teo0x8rBYvY1j+=ZEDAeE4bZ359nVOtgUyb=ZJig@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Keir Fraser <keir.xen@gmail.com>, john.baboval@citrix.com,
	Thomas Goetz <thomas.goetz@citrix.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen4.2 S3 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 20.09.12 at 22:30, Ben Guthro <ben@guthro.net> wrote:
> On Thu, Sep 20, 2012 at 8:56 AM, Ben Guthro <ben@guthro.net> wrote:
> [   32.145824] ACPI: Preparing to enter system sleep state S3
> [   32.600118] PM: Saving platform NVS memory
> [   32.671666] Disabling non-boot CPUs ...
> (XEN) Preparing system for ACPI S3 state.
> (XEN) Disabling non-boot CPUs ...
> (XEN) Bringing CPU1 down
> (XEN) Disabling CPU1
> (XEN) Disabled CPU1
> (XEN) play_dead: CPU1
> (XEN) cpu_exit_clear: CPU1
> (XEN) cpu_uninit: CPU1
> (XEN) CPU1 dead

So how about inserting printout of cpu_initialized here ...

> (XEN) Entering ACPI S3 state.
> (XEN) Finishing wakeup from ACPI S3 state.
> (XEN) Enabling non-boot CPUs  ...

... and here?

Plus adding "cpuinfo" to the Xen command line, which would allow
us to see whether CPU1 gets into cpu_init() twice.

Perhaps tracking cpu_state throughout the below sequence might
also be useful.

> (XEN) Bringing CPU1 up
> (XEN) Setting warm reset code and vector.
> (XEN) Asserting INIT.
> (XEN) Waiting for send to finish...
> (XEN) +Deasserting INIT.
> (XEN) Waiting for send to finish...
> (XEN) +#startup loops: 2.
> (XEN) Sending STARTUP #1.
> (XEN) After apic_write.
> (XEN) CPU#1 already initialized!
> (XEN) Startup point 1.
> (XEN) Waiting for send to finish...
> (XEN) +Sending STARTUP #2.
> (XEN) After apic_write.
> (XEN) Startup point 1.
> (XEN) Waiting for send to finish...
> (XEN) +After Startup.
> (XEN) After Callout 1.
> (XEN) Stuck ??
> (XEN) cpu_exit_clear: CPU1
> (XEN) cpu_uninit: CPU1
> (XEN) __cpu_up - do_boot_cpu error
> (XEN) cpu_up CPU1 CPU not up
> (XEN) cpu_up CPU1 fail
> (XEN) Error taking CPU1 up: -5
> [   32.780055] ACPI: Low-level resume complete
> [   32.780055] PM: Restoring platform NVS memory
> [   32.780055] Enabling non-boot CPUs ...
> 
> then it crashes.
> 
> It seems that it is always falling through into the "else" clause of
> the do_boot_cpu() function when attempting to bring it back up, seemingly
> stuck in CPU_STATE_CALLOUT
> 
> 
> Any ideas as to what might be causing it to get stuck in that state?

That's because CPU1 is stuck in cpu_init() (in the infinite loop after
printing "CPU#1 already initialized!"), as Keir pointed out yesterday.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 21 07:13:27 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Sep 2012 07:13:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TExQ8-0005DK-0C; Fri, 21 Sep 2012 07:13: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 1TExQ6-0005DF-GQ
	for xen-devel@lists.xen.org; Fri, 21 Sep 2012 07:13:02 +0000
Received: from [85.158.143.35:4565] by server-3.bemta-4.messagelabs.com id
	6A/34-10986-D731C505; Fri, 21 Sep 2012 07:13:01 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1348211580!15753573!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21068 invoked from network); 21 Sep 2012 07:13: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;
	21 Sep 2012 07:13:00 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 21 Sep 2012 08:13:00 +0100
Message-Id: <505C2F97020000780009CDC9@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 21 Sep 2012 08:12:55 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Andres Lagar-Cavilla" <andreslc@gridcentric.ca>
References: <E269205F-457F-4503-BB86-11C0EFA15CEC@gridcentric.ca>
In-Reply-To: <E269205F-457F-4503-BB86-11C0EFA15CEC@gridcentric.ca>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Keir Fraser <keir@xen.org>, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Backport request: 25914:cd2a831d0a41 to
	xen-4.2-testing.hg
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.09.12 at 17:23, Andres Lagar-Cavilla <andreslc@gridcentric.ca> wrote:
> It seems back porting has started. I would have asked for a few others, but 
> I've been beaten to the punch!

Do you realize that you Cc-ed the wrong people (neither Keir nor
I generally take care of tools issues).

Ian, Ian - can one of you take care of this?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 21 07:13:27 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Sep 2012 07:13:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TExQ8-0005DK-0C; Fri, 21 Sep 2012 07:13: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 1TExQ6-0005DF-GQ
	for xen-devel@lists.xen.org; Fri, 21 Sep 2012 07:13:02 +0000
Received: from [85.158.143.35:4565] by server-3.bemta-4.messagelabs.com id
	6A/34-10986-D731C505; Fri, 21 Sep 2012 07:13:01 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1348211580!15753573!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21068 invoked from network); 21 Sep 2012 07:13: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;
	21 Sep 2012 07:13:00 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 21 Sep 2012 08:13:00 +0100
Message-Id: <505C2F97020000780009CDC9@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 21 Sep 2012 08:12:55 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Andres Lagar-Cavilla" <andreslc@gridcentric.ca>
References: <E269205F-457F-4503-BB86-11C0EFA15CEC@gridcentric.ca>
In-Reply-To: <E269205F-457F-4503-BB86-11C0EFA15CEC@gridcentric.ca>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Keir Fraser <keir@xen.org>, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Backport request: 25914:cd2a831d0a41 to
	xen-4.2-testing.hg
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.09.12 at 17:23, Andres Lagar-Cavilla <andreslc@gridcentric.ca> wrote:
> It seems back porting has started. I would have asked for a few others, but 
> I've been beaten to the punch!

Do you realize that you Cc-ed the wrong people (neither Keir nor
I generally take care of tools issues).

Ian, Ian - can one of you take care of this?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 21 07:18:30 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Sep 2012 07: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 1TExV6-0005Kx-Og; Fri, 21 Sep 2012 07:18: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 1TExV5-0005Ks-39
	for xen-devel@lists.xen.org; Fri, 21 Sep 2012 07:18:11 +0000
Received: from [85.158.139.83:31820] by server-6.bemta-5.messagelabs.com id
	26/DE-21336-2B41C505; Fri, 21 Sep 2012 07:18:10 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1348211889!31774090!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5495 invoked from network); 21 Sep 2012 07:18:09 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-10.tower-182.messagelabs.com with SMTP;
	21 Sep 2012 07:18:09 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 21 Sep 2012 08:18:09 +0100
Message-Id: <505C30CC020000780009CDD6@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 21 Sep 2012 08:18:04 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Oliver Chick" <oliver.chick@citrix.com>,
	"Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>
References: <1348051887-21885-1-git-send-email-oliver.chick@citrix.com>
	<505AF126.2050806@citrix.com>
	<1348140637.24539.32.camel@oliverchick-Precision-WorkStation-T3400>
	<505B1EB9020000780009CA6E@nat28.tlf.novell.com>
	<20120920134951.GC1998@localhost.localdomain>
	<1348150422.24539.58.camel@oliverchick-Precision-WorkStation-T3400>
	<20120920212407.GD27312@konrad-lan.dumpdata.com>
In-Reply-To: <20120920212407.GD27312@konrad-lan.dumpdata.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	David Vrabel <david.vrabel@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] Persistent grant maps for xen blk drivers
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 20.09.12 at 23:24, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
> On Thu, Sep 20, 2012 at 03:13:42PM +0100, Oliver Chick wrote:
>> On Thu, 2012-09-20 at 14:49 +0100, Konrad Rzeszutek Wilk wrote:
>> > On Thu, Sep 20, 2012 at 12:48:41PM +0100, Jan Beulich wrote:
>> > > >>> On 20.09.12 at 13:30, Oliver Chick <oliver.chick@citrix.com> wrote:
>> > > > The memory overhead, and fallback mode points are related:
>> > > > -Firstly, it turns out that the overhead is actually 2.75MB, not 11MB
>> > > > per device. I made a mistake (pointed out by Jan) as the maximum number
>> > > > of requests that can fit into a single-page ring is 64, not 256.
>> > > > -Clearly, this still scales linearly. So the problem of memory footprint
>> > > > will occur with more VMs, or block devices.
>> > > > -Whilst 2.75MB per device is probably acceptable (?), if we start using
>> > > > multipage rings, then we might not want to have
>> > > > BLKIF_MAX_PERS_REQUESTS_PER_DEVICE==__RING_SIZE, as this will cause the
>> > > > memory overhead to increase. This is why I have implemented the
>> > > > 'fallback' mode. With a multipage ring, it seems reasonable to want the
>> > > > first $x$ grefs seen by blkback to be treated as persistent, and any
>> > > > later ones to be non-persistent. Does that seem sensible?
>> > > 
>> > > From a resource usage pov, perhaps. But this will get the guest
>> > > entirely unpredictable performance. Plus I don't think 11Mb of
>> > 
>> > Wouldn't it fall back to the older performance?
>> 
>> I guess it would be a bit more complex than that. It would be worse than
>> the new performance because the grefs that get processed by the
>> 'fallback' mode will cause TLB shootdowns. But any early grefs will
>> still be processed by the persistent mode, so won't have shootdowns.
>> Therefore, depending on the ratio of {persistent grants}:{non-persistent
>> grants), allocated by blkfront, the performance will be somewhere
>> inbetween the two extremes.
>> 
>> I guess that the choice is between
>> 1) Compiling blk{front,back} with a pre-determined number of persistent
>> grants, and failing if this limit is exceeded. This seems rather
>> unflexible, as blk{front,back} must then both both use the same version,
>> or you will get failures.
>> 2 (current setup)) Have a recommended maximum number of
>> persistently-mapped pages, and going into a 'fallback' mode if blkfront
>> exceeds this limit.
>> 3) Having blkback inform blkfront on startup as to how many grefs it is
>> willing to persistently-map. We then hit the same question again though:
>> what should be do if blkfront ignores this limit?
> 
> How about 2 and 3 together? Meaning have a recommended maximmum number.
> If we fall back due to memory pressure we can tell the guest that we
> are entering fall-back mode. The frontend can decide what it wants to do
> (throttle the amount of I/Os?) or just do a printk telling the user it
> dropped the speed from "Insane Hot!" down to "Turbo!"... 
> 
> Or maybe not. Perhaps just reporting it in the backend that we are
> hitting memory pressure and using the old-style-fallback mechanism
> so the system admin can take actions (and tell his users why suddenly
> their I/Os are so slow).

So would either of you help me understand what memory pressure
we're in need of dealing with here. So far, talk was only about
virtual address space that's needed for mapping in the grants, and
even then I don't see how this space requirement varies between
persistent and non-persistent grants - it's being reserved during
backend initialization anyway.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 21 07:18:30 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Sep 2012 07: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 1TExV6-0005Kx-Og; Fri, 21 Sep 2012 07:18: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 1TExV5-0005Ks-39
	for xen-devel@lists.xen.org; Fri, 21 Sep 2012 07:18:11 +0000
Received: from [85.158.139.83:31820] by server-6.bemta-5.messagelabs.com id
	26/DE-21336-2B41C505; Fri, 21 Sep 2012 07:18:10 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1348211889!31774090!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5495 invoked from network); 21 Sep 2012 07:18:09 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-10.tower-182.messagelabs.com with SMTP;
	21 Sep 2012 07:18:09 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 21 Sep 2012 08:18:09 +0100
Message-Id: <505C30CC020000780009CDD6@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 21 Sep 2012 08:18:04 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Oliver Chick" <oliver.chick@citrix.com>,
	"Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>
References: <1348051887-21885-1-git-send-email-oliver.chick@citrix.com>
	<505AF126.2050806@citrix.com>
	<1348140637.24539.32.camel@oliverchick-Precision-WorkStation-T3400>
	<505B1EB9020000780009CA6E@nat28.tlf.novell.com>
	<20120920134951.GC1998@localhost.localdomain>
	<1348150422.24539.58.camel@oliverchick-Precision-WorkStation-T3400>
	<20120920212407.GD27312@konrad-lan.dumpdata.com>
In-Reply-To: <20120920212407.GD27312@konrad-lan.dumpdata.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	David Vrabel <david.vrabel@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] Persistent grant maps for xen blk drivers
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 20.09.12 at 23:24, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
> On Thu, Sep 20, 2012 at 03:13:42PM +0100, Oliver Chick wrote:
>> On Thu, 2012-09-20 at 14:49 +0100, Konrad Rzeszutek Wilk wrote:
>> > On Thu, Sep 20, 2012 at 12:48:41PM +0100, Jan Beulich wrote:
>> > > >>> On 20.09.12 at 13:30, Oliver Chick <oliver.chick@citrix.com> wrote:
>> > > > The memory overhead, and fallback mode points are related:
>> > > > -Firstly, it turns out that the overhead is actually 2.75MB, not 11MB
>> > > > per device. I made a mistake (pointed out by Jan) as the maximum number
>> > > > of requests that can fit into a single-page ring is 64, not 256.
>> > > > -Clearly, this still scales linearly. So the problem of memory footprint
>> > > > will occur with more VMs, or block devices.
>> > > > -Whilst 2.75MB per device is probably acceptable (?), if we start using
>> > > > multipage rings, then we might not want to have
>> > > > BLKIF_MAX_PERS_REQUESTS_PER_DEVICE==__RING_SIZE, as this will cause the
>> > > > memory overhead to increase. This is why I have implemented the
>> > > > 'fallback' mode. With a multipage ring, it seems reasonable to want the
>> > > > first $x$ grefs seen by blkback to be treated as persistent, and any
>> > > > later ones to be non-persistent. Does that seem sensible?
>> > > 
>> > > From a resource usage pov, perhaps. But this will get the guest
>> > > entirely unpredictable performance. Plus I don't think 11Mb of
>> > 
>> > Wouldn't it fall back to the older performance?
>> 
>> I guess it would be a bit more complex than that. It would be worse than
>> the new performance because the grefs that get processed by the
>> 'fallback' mode will cause TLB shootdowns. But any early grefs will
>> still be processed by the persistent mode, so won't have shootdowns.
>> Therefore, depending on the ratio of {persistent grants}:{non-persistent
>> grants), allocated by blkfront, the performance will be somewhere
>> inbetween the two extremes.
>> 
>> I guess that the choice is between
>> 1) Compiling blk{front,back} with a pre-determined number of persistent
>> grants, and failing if this limit is exceeded. This seems rather
>> unflexible, as blk{front,back} must then both both use the same version,
>> or you will get failures.
>> 2 (current setup)) Have a recommended maximum number of
>> persistently-mapped pages, and going into a 'fallback' mode if blkfront
>> exceeds this limit.
>> 3) Having blkback inform blkfront on startup as to how many grefs it is
>> willing to persistently-map. We then hit the same question again though:
>> what should be do if blkfront ignores this limit?
> 
> How about 2 and 3 together? Meaning have a recommended maximmum number.
> If we fall back due to memory pressure we can tell the guest that we
> are entering fall-back mode. The frontend can decide what it wants to do
> (throttle the amount of I/Os?) or just do a printk telling the user it
> dropped the speed from "Insane Hot!" down to "Turbo!"... 
> 
> Or maybe not. Perhaps just reporting it in the backend that we are
> hitting memory pressure and using the old-style-fallback mechanism
> so the system admin can take actions (and tell his users why suddenly
> their I/Os are so slow).

So would either of you help me understand what memory pressure
we're in need of dealing with here. So far, talk was only about
virtual address space that's needed for mapping in the grants, and
even then I don't see how this space requirement varies between
persistent and non-persistent grants - it's being reserved during
backend initialization anyway.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 21 07:39:24 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Sep 2012 07:39:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TExpH-0005bG-LG; Fri, 21 Sep 2012 07:39:03 +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 1TExpF-0005bB-85
	for xen-devel@lists.xensource.com; Fri, 21 Sep 2012 07:39:01 +0000
Received: from [85.158.143.99:60960] by server-1.bemta-4.messagelabs.com id
	8F/68-05684-4991C505; Fri, 21 Sep 2012 07:39:00 +0000
X-Env-Sender: Christoph.Egger@amd.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1348213138!24209232!1
X-Originating-IP: [216.32.180.12]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5167 invoked from network); 21 Sep 2012 07:38:59 -0000
Received: from va3ehsobe002.messaging.microsoft.com (HELO
	va3outboundpool.messaging.microsoft.com) (216.32.180.12)
	by server-6.tower-216.messagelabs.com with AES128-SHA encrypted SMTP;
	21 Sep 2012 07:38:59 -0000
Received: from mail248-va3-R.bigfish.com (10.7.14.241) by
	VA3EHSOBE008.bigfish.com (10.7.40.28) with Microsoft SMTP Server id
	14.1.225.23; Fri, 21 Sep 2012 07:38:58 +0000
Received: from mail248-va3 (localhost [127.0.0.1])	by
	mail248-va3-R.bigfish.com (Postfix) with ESMTP id 19FDC70015B;
	Fri, 21 Sep 2012 07:38:58 +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: -3
X-BigFish: VPS-3(zzbb2dI98dI1432I4015Id6f1izz1202h1d1ah1d2ahzz8275bhz2dh668h839hd25he5bhf0ah107ah1288h12a5h12a9h12bdh137ah1155h)
Received: from mail248-va3 (localhost.localdomain [127.0.0.1]) by mail248-va3
	(MessageSwitch) id 1348213135692657_15556;
	Fri, 21 Sep 2012 07:38:55 +0000 (UTC)
Received: from VA3EHSMHS038.bigfish.com (unknown [10.7.14.239])	by
	mail248-va3.bigfish.com (Postfix) with ESMTP id A5339C40047;
	Fri, 21 Sep 2012 07:38:55 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	VA3EHSMHS038.bigfish.com (10.7.99.48) with Microsoft SMTP Server id
	14.1.225.23; Fri, 21 Sep 2012 07:38:55 +0000
X-WSS-ID: 0MAOVWU-01-K21-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 2A139102811F;	Fri, 21 Sep 2012 02:38:54 -0500 (CDT)
Received: from sausexhtp02.amd.com (163.181.3.152) by sausexedgep02.amd.com
	(163.181.36.59) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Fri, 21 Sep 2012 02:39:05 -0500
Received: from storexhtp02.amd.com (172.24.4.4) by sausexhtp02.amd.com
	(163.181.3.152) with Microsoft SMTP Server (TLS) id 8.3.213.0;
	Fri, 21 Sep 2012 02:38:53 -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, 21 Sep 2012
	03:38:52 -0400
Message-ID: <505C198A.30203@amd.com>
Date: Fri, 21 Sep 2012 09:38:50 +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: <DE8DF0795D48FD4CA783C40EC8292335330591@SHSMSX101.ccr.corp.intel.com>
	<505B34E1.6030609@amd.com>
	<DE8DF0795D48FD4CA783C40EC82923353326D5@SHSMSX101.ccr.corp.intel.com>
In-Reply-To: <DE8DF0795D48FD4CA783C40EC82923353326D5@SHSMSX101.ccr.corp.intel.com>
X-OriginatorOrg: amd.com
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"keir@xen.org" <keir@xen.org>,
	"Ian.Campbell@citrix.com" <Ian.Campbell@citrix.com>,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH 2/5] Xen/MCE: vMCE 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 09/20/12 21:15, Liu, Jinsong wrote:

> Christoph Egger wrote:
>> On 09/19/12 10:03, Liu, Jinsong wrote:
>>
>>> Xen/MCE: vMCE injection
>>>
>>> In our test for win8 guest mce, we find a bug 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.
>>
>>
>> This breaks the AMD way. The AMD way is to only inject it to vcpu0.
>> I suggest to add a flag argument to inject_vmce() that says whether
>> to inject to all vcpus or just vcpu0.
>> Then set/clear that flag from the caller side depending on whether you
>> run on Intel or AMD.
>>
>> Christoph
>>
> 
> No, it didn't breaks AMD since it only called by intel_memerr_dhandler().

But it will with the mce patches I still have in my queue.

Christoph


> Thanks,
> Jinsong
> 
>>
>>>
>>> Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>
>>>
>>> diff -r 133664c6bfb4 xen/arch/x86/cpu/mcheck/vmce.c
>>> --- a/xen/arch/x86/cpu/mcheck/vmce.c	Tue Sep 18 22:39:11 2012 +0800
>>> +++ b/xen/arch/x86/cpu/mcheck/vmce.c	Tue Sep 18 23:46:38 2012 +0800
>>> @@ -340,48 +340,27 @@ 
>>>
>>>  int inject_vmce(struct domain *d)
>>>  {
>>> -    int cpu = smp_processor_id();
>>> +    struct vcpu *v;
>>>
>>> -    /* PV guest and HVM guest have different vMCE# injection
>>> methods. */ 
>>> -    if ( !test_and_set_bool(d->vcpu[0]->mce_pending) )
>>> +    /* inject vMCE to all vcpus */
>>> +    for_each_vcpu(d, v)
>>>      {
>>> -        if ( d->is_hvm )
>>> +        if ( !test_and_set_bool(v->mce_pending) && +           
>>> ((d->is_hvm) || +                guest_has_trap_callback(d,
>>> v->vcpu_id, TRAP_machine_check)) )          { 
>>> -            mce_printk(MCE_VERBOSE, "MCE: inject vMCE to HVM DOM
>>> %d\n", 
>>> -                       d->domain_id);
>>> -            vcpu_kick(d->vcpu[0]);
>>> +            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_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);
>>> -            }
>>> +            mce_printk(MCE_QUIET, "Fail to inject vMCE to dom%d
>>> vcpu%d\n", +                       d->domain_id, v->vcpu_id);
>>> +            return -1;
>>>          }
>>>      }
>>> -    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
>>> injected " 
>>> -                   " to this DOM%d!\n", d->domain_id);
>>> -        return -1;
>>> -    }
>>> +
>>>      return 0;
>>>  }
> 
> 



-- 
---to satisfy European Law for business letters:
Advanced Micro Devices GmbH
Einsteinring 24, 85689 Dornach b. Muenchen
Geschaeftsfuehrer: Alberto Bozzo
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 Sep 21 07:39:24 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Sep 2012 07:39:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TExpH-0005bG-LG; Fri, 21 Sep 2012 07:39:03 +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 1TExpF-0005bB-85
	for xen-devel@lists.xensource.com; Fri, 21 Sep 2012 07:39:01 +0000
Received: from [85.158.143.99:60960] by server-1.bemta-4.messagelabs.com id
	8F/68-05684-4991C505; Fri, 21 Sep 2012 07:39:00 +0000
X-Env-Sender: Christoph.Egger@amd.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1348213138!24209232!1
X-Originating-IP: [216.32.180.12]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5167 invoked from network); 21 Sep 2012 07:38:59 -0000
Received: from va3ehsobe002.messaging.microsoft.com (HELO
	va3outboundpool.messaging.microsoft.com) (216.32.180.12)
	by server-6.tower-216.messagelabs.com with AES128-SHA encrypted SMTP;
	21 Sep 2012 07:38:59 -0000
Received: from mail248-va3-R.bigfish.com (10.7.14.241) by
	VA3EHSOBE008.bigfish.com (10.7.40.28) with Microsoft SMTP Server id
	14.1.225.23; Fri, 21 Sep 2012 07:38:58 +0000
Received: from mail248-va3 (localhost [127.0.0.1])	by
	mail248-va3-R.bigfish.com (Postfix) with ESMTP id 19FDC70015B;
	Fri, 21 Sep 2012 07:38:58 +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: -3
X-BigFish: VPS-3(zzbb2dI98dI1432I4015Id6f1izz1202h1d1ah1d2ahzz8275bhz2dh668h839hd25he5bhf0ah107ah1288h12a5h12a9h12bdh137ah1155h)
Received: from mail248-va3 (localhost.localdomain [127.0.0.1]) by mail248-va3
	(MessageSwitch) id 1348213135692657_15556;
	Fri, 21 Sep 2012 07:38:55 +0000 (UTC)
Received: from VA3EHSMHS038.bigfish.com (unknown [10.7.14.239])	by
	mail248-va3.bigfish.com (Postfix) with ESMTP id A5339C40047;
	Fri, 21 Sep 2012 07:38:55 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	VA3EHSMHS038.bigfish.com (10.7.99.48) with Microsoft SMTP Server id
	14.1.225.23; Fri, 21 Sep 2012 07:38:55 +0000
X-WSS-ID: 0MAOVWU-01-K21-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 2A139102811F;	Fri, 21 Sep 2012 02:38:54 -0500 (CDT)
Received: from sausexhtp02.amd.com (163.181.3.152) by sausexedgep02.amd.com
	(163.181.36.59) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Fri, 21 Sep 2012 02:39:05 -0500
Received: from storexhtp02.amd.com (172.24.4.4) by sausexhtp02.amd.com
	(163.181.3.152) with Microsoft SMTP Server (TLS) id 8.3.213.0;
	Fri, 21 Sep 2012 02:38:53 -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, 21 Sep 2012
	03:38:52 -0400
Message-ID: <505C198A.30203@amd.com>
Date: Fri, 21 Sep 2012 09:38:50 +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: <DE8DF0795D48FD4CA783C40EC8292335330591@SHSMSX101.ccr.corp.intel.com>
	<505B34E1.6030609@amd.com>
	<DE8DF0795D48FD4CA783C40EC82923353326D5@SHSMSX101.ccr.corp.intel.com>
In-Reply-To: <DE8DF0795D48FD4CA783C40EC82923353326D5@SHSMSX101.ccr.corp.intel.com>
X-OriginatorOrg: amd.com
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"keir@xen.org" <keir@xen.org>,
	"Ian.Campbell@citrix.com" <Ian.Campbell@citrix.com>,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH 2/5] Xen/MCE: vMCE 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 09/20/12 21:15, Liu, Jinsong wrote:

> Christoph Egger wrote:
>> On 09/19/12 10:03, Liu, Jinsong wrote:
>>
>>> Xen/MCE: vMCE injection
>>>
>>> In our test for win8 guest mce, we find a bug 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.
>>
>>
>> This breaks the AMD way. The AMD way is to only inject it to vcpu0.
>> I suggest to add a flag argument to inject_vmce() that says whether
>> to inject to all vcpus or just vcpu0.
>> Then set/clear that flag from the caller side depending on whether you
>> run on Intel or AMD.
>>
>> Christoph
>>
> 
> No, it didn't breaks AMD since it only called by intel_memerr_dhandler().

But it will with the mce patches I still have in my queue.

Christoph


> Thanks,
> Jinsong
> 
>>
>>>
>>> Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>
>>>
>>> diff -r 133664c6bfb4 xen/arch/x86/cpu/mcheck/vmce.c
>>> --- a/xen/arch/x86/cpu/mcheck/vmce.c	Tue Sep 18 22:39:11 2012 +0800
>>> +++ b/xen/arch/x86/cpu/mcheck/vmce.c	Tue Sep 18 23:46:38 2012 +0800
>>> @@ -340,48 +340,27 @@ 
>>>
>>>  int inject_vmce(struct domain *d)
>>>  {
>>> -    int cpu = smp_processor_id();
>>> +    struct vcpu *v;
>>>
>>> -    /* PV guest and HVM guest have different vMCE# injection
>>> methods. */ 
>>> -    if ( !test_and_set_bool(d->vcpu[0]->mce_pending) )
>>> +    /* inject vMCE to all vcpus */
>>> +    for_each_vcpu(d, v)
>>>      {
>>> -        if ( d->is_hvm )
>>> +        if ( !test_and_set_bool(v->mce_pending) && +           
>>> ((d->is_hvm) || +                guest_has_trap_callback(d,
>>> v->vcpu_id, TRAP_machine_check)) )          { 
>>> -            mce_printk(MCE_VERBOSE, "MCE: inject vMCE to HVM DOM
>>> %d\n", 
>>> -                       d->domain_id);
>>> -            vcpu_kick(d->vcpu[0]);
>>> +            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_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);
>>> -            }
>>> +            mce_printk(MCE_QUIET, "Fail to inject vMCE to dom%d
>>> vcpu%d\n", +                       d->domain_id, v->vcpu_id);
>>> +            return -1;
>>>          }
>>>      }
>>> -    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
>>> injected " 
>>> -                   " to this DOM%d!\n", d->domain_id);
>>> -        return -1;
>>> -    }
>>> +
>>>      return 0;
>>>  }
> 
> 



-- 
---to satisfy European Law for business letters:
Advanced Micro Devices GmbH
Einsteinring 24, 85689 Dornach b. Muenchen
Geschaeftsfuehrer: Alberto Bozzo
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 Sep 21 07:43:22 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Sep 2012 07:43:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TExt9-0005kI-Fl; Fri, 21 Sep 2012 07:43:03 +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 1TExt8-0005kA-0m
	for xen-devel@lists.xensource.com; Fri, 21 Sep 2012 07:43:02 +0000
Received: from [85.158.137.99:63175] by server-11.bemta-3.messagelabs.com id
	37/03-30250-58A1C505; Fri, 21 Sep 2012 07:43:01 +0000
X-Env-Sender: Christoph.Egger@amd.com
X-Msg-Ref: server-15.tower-217.messagelabs.com!1348213379!16198592!1
X-Originating-IP: [65.55.88.14]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26596 invoked from network); 21 Sep 2012 07:43:00 -0000
Received: from tx2ehsobe004.messaging.microsoft.com (HELO
	tx2outboundpool.messaging.microsoft.com) (65.55.88.14)
	by server-15.tower-217.messagelabs.com with AES128-SHA encrypted SMTP;
	21 Sep 2012 07:43:00 -0000
Received: from mail117-tx2-R.bigfish.com (10.9.14.236) by
	TX2EHSOBE014.bigfish.com (10.9.40.34) with Microsoft SMTP Server id
	14.1.225.23; Fri, 21 Sep 2012 07:42:58 +0000
Received: from mail117-tx2 (localhost [127.0.0.1])	by
	mail117-tx2-R.bigfish.com (Postfix) with ESMTP id D0D7F360072;
	Fri, 21 Sep 2012 07:42: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: -4
X-BigFish: VPS-4(zzbb2dI98dI1432I4015Izz1202h1d1ah1d2ahzz17326ah8275dhz2dh668h839hd25he5bhf0ah107ah1288h12a5h12a9h12bdh137ah1155h)
Received: from mail117-tx2 (localhost.localdomain [127.0.0.1]) by mail117-tx2
	(MessageSwitch) id 134821337637697_21346;
	Fri, 21 Sep 2012 07:42:56 +0000 (UTC)
Received: from TX2EHSMHS040.bigfish.com (unknown [10.9.14.252])	by
	mail117-tx2.bigfish.com (Postfix) with ESMTP id 05498C008B;
	Fri, 21 Sep 2012 07:42:56 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	TX2EHSMHS040.bigfish.com (10.9.99.140) with Microsoft SMTP Server id
	14.1.225.23; Fri, 21 Sep 2012 07:42:55 +0000
X-WSS-ID: 0MAOW3H-02-34Y-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 28DC7C813C;	Fri, 21 Sep 2012 02:42:53 -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, 21 Sep 2012 02:43:12 -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, 21 Sep 2012 02:42:53 -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, 21 Sep 2012
	03:42:52 -0400
Message-ID: <505C1A79.9060100@amd.com>
Date: Fri, 21 Sep 2012 09:42:49 +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: <DE8DF0795D48FD4CA783C40EC8292335332DA5@SHSMSX101.ccr.corp.intel.com>
In-Reply-To: <DE8DF0795D48FD4CA783C40EC8292335332DA5@SHSMSX101.ccr.corp.intel.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] comments for c/s 25919 Xen mce
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 09/21/12 08:44, Liu, Jinsong wrote:

> Christoph, Keir, Jan
> 
> I have a draft look at c/s 25919. It moves some mce_intel.c logic to mce.c (and remove old mce.c logic). By draft reviewing the patch I think it need more work to do, and currently it in fact would hung at AMD platform (I have no AMD platform to test), i.e, MACHINE_CHECK_SOFTIRQ --> mce_delayed_action() --> mce_action() --> ASSERT(handler_num);
> 
> For AMD mce it may need add (if any misunderstanding please point to me)
> 1). add default handler which used at softirq context


This is mcee_softirq().

> 2). add AMD vmce inject logic


Yes, patch is sent.
See http://lists.xen.org/archives/html/xen-devel/2012-09/msg01413.html

> 3). more test


There are more patches in my queue.

Christoph

> 
> Thoughts?
> 
> Thanks,
> Jinsong



-- 
---to satisfy European Law for business letters:
Advanced Micro Devices GmbH
Einsteinring 24, 85689 Dornach b. Muenchen
Geschaeftsfuehrer: Alberto Bozzo
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 Sep 21 07:43:22 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Sep 2012 07:43:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TExt9-0005kI-Fl; Fri, 21 Sep 2012 07:43:03 +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 1TExt8-0005kA-0m
	for xen-devel@lists.xensource.com; Fri, 21 Sep 2012 07:43:02 +0000
Received: from [85.158.137.99:63175] by server-11.bemta-3.messagelabs.com id
	37/03-30250-58A1C505; Fri, 21 Sep 2012 07:43:01 +0000
X-Env-Sender: Christoph.Egger@amd.com
X-Msg-Ref: server-15.tower-217.messagelabs.com!1348213379!16198592!1
X-Originating-IP: [65.55.88.14]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26596 invoked from network); 21 Sep 2012 07:43:00 -0000
Received: from tx2ehsobe004.messaging.microsoft.com (HELO
	tx2outboundpool.messaging.microsoft.com) (65.55.88.14)
	by server-15.tower-217.messagelabs.com with AES128-SHA encrypted SMTP;
	21 Sep 2012 07:43:00 -0000
Received: from mail117-tx2-R.bigfish.com (10.9.14.236) by
	TX2EHSOBE014.bigfish.com (10.9.40.34) with Microsoft SMTP Server id
	14.1.225.23; Fri, 21 Sep 2012 07:42:58 +0000
Received: from mail117-tx2 (localhost [127.0.0.1])	by
	mail117-tx2-R.bigfish.com (Postfix) with ESMTP id D0D7F360072;
	Fri, 21 Sep 2012 07:42: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: -4
X-BigFish: VPS-4(zzbb2dI98dI1432I4015Izz1202h1d1ah1d2ahzz17326ah8275dhz2dh668h839hd25he5bhf0ah107ah1288h12a5h12a9h12bdh137ah1155h)
Received: from mail117-tx2 (localhost.localdomain [127.0.0.1]) by mail117-tx2
	(MessageSwitch) id 134821337637697_21346;
	Fri, 21 Sep 2012 07:42:56 +0000 (UTC)
Received: from TX2EHSMHS040.bigfish.com (unknown [10.9.14.252])	by
	mail117-tx2.bigfish.com (Postfix) with ESMTP id 05498C008B;
	Fri, 21 Sep 2012 07:42:56 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	TX2EHSMHS040.bigfish.com (10.9.99.140) with Microsoft SMTP Server id
	14.1.225.23; Fri, 21 Sep 2012 07:42:55 +0000
X-WSS-ID: 0MAOW3H-02-34Y-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 28DC7C813C;	Fri, 21 Sep 2012 02:42:53 -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, 21 Sep 2012 02:43:12 -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, 21 Sep 2012 02:42:53 -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, 21 Sep 2012
	03:42:52 -0400
Message-ID: <505C1A79.9060100@amd.com>
Date: Fri, 21 Sep 2012 09:42:49 +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: <DE8DF0795D48FD4CA783C40EC8292335332DA5@SHSMSX101.ccr.corp.intel.com>
In-Reply-To: <DE8DF0795D48FD4CA783C40EC8292335332DA5@SHSMSX101.ccr.corp.intel.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] comments for c/s 25919 Xen mce
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 09/21/12 08:44, Liu, Jinsong wrote:

> Christoph, Keir, Jan
> 
> I have a draft look at c/s 25919. It moves some mce_intel.c logic to mce.c (and remove old mce.c logic). By draft reviewing the patch I think it need more work to do, and currently it in fact would hung at AMD platform (I have no AMD platform to test), i.e, MACHINE_CHECK_SOFTIRQ --> mce_delayed_action() --> mce_action() --> ASSERT(handler_num);
> 
> For AMD mce it may need add (if any misunderstanding please point to me)
> 1). add default handler which used at softirq context


This is mcee_softirq().

> 2). add AMD vmce inject logic


Yes, patch is sent.
See http://lists.xen.org/archives/html/xen-devel/2012-09/msg01413.html

> 3). more test


There are more patches in my queue.

Christoph

> 
> Thoughts?
> 
> Thanks,
> Jinsong



-- 
---to satisfy European Law for business letters:
Advanced Micro Devices GmbH
Einsteinring 24, 85689 Dornach b. Muenchen
Geschaeftsfuehrer: Alberto Bozzo
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 Sep 21 07:46:46 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Sep 2012 07: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 1TExwS-0005tE-H2; Fri, 21 Sep 2012 07:46:28 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <vivagin@yeah.net>) id 1TEuVl-0002sN-7A
	for xen-devel@lists.xensource.com; Fri, 21 Sep 2012 04:06:41 +0000
Received: from [85.158.139.83:43539] by server-1.bemta-5.messagelabs.com id
	5B/54-04809-0D7EB505; Fri, 21 Sep 2012 04:06:40 +0000
X-Env-Sender: vivagin@yeah.net
X-Msg-Ref: server-9.tower-182.messagelabs.com!1348200398!30805280!1
X-Originating-IP: [216.139.236.26]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22652 invoked from network); 21 Sep 2012 04:06:39 -0000
Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26)
	by server-9.tower-182.messagelabs.com with AES256-SHA encrypted SMTP;
	21 Sep 2012 04:06:39 -0000
Received: from [192.168.236.26] (helo=sam.nabble.com)
	by sam.nabble.com with esmtp (Exim 4.72)
	(envelope-from <vivagin@yeah.net>) id 1TEuVh-0005wg-Rz
	for xen-devel@lists.xensource.com; Thu, 20 Sep 2012 21:06:37 -0700
Date: Thu, 20 Sep 2012 21:06:37 -0700 (PDT)
From: Bruce Granger <vivagin@yeah.net>
To: xen-devel@lists.xensource.com
Message-ID: <1348200397859-5711422.post@n5.nabble.com>
MIME-Version: 1.0
X-Mailman-Approved-At: Fri, 21 Sep 2012 07:46:27 +0000
Subject: [Xen-devel] From which place in source code Xen start to deal with
 the GuestOS shutdown 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="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

SGVsbG8gZXZlcnlvbmUhCkkgZmVlbCBJJ20gc3RpbGwgYSBuZXcgYmFieSB0aG91Z2ggSSBoYXZl
IGJlZW4gc3R1ZHkgeGVuIHNvdXJjZSBjb2RlIGZvcgpzb21lIGRheXMhCldoZW4gSSBzaHV0ZG93
biBHdWVzdE9TLCBJIHdhbnQgdG8gZ2V0IHRvIGtub3cgaG93IFhlbiBkZWFsIHdpdGggdGhlCm9w
ZXJhdGlvbj8gSSBmaW5kIHRoZSBjb2RlIGluIHhlblxhcmNoXHg4Nlxodm1cdmxhcGljLmMsIHNl
ZToKc3RhdGljIGludCB2bGFwaWNfYWNjZXB0X2lycShzdHJ1Y3QgdmNwdSAqdiwgdWludDMyX3Qg
aWNyX2xvdykKewrigKbigKYKc3dpdGNoICggaWNyX2xvdyAmIEFQSUNfTU9ERV9NQVNLICkKewri
gKbigKYKICAgIGNhc2UgQVBJQ19ETV9JTklUOgogICAgICAgIC8qIE5vIHdvcmsgb24gSU5JVCBk
ZS1hc3NlcnQgZm9yIFA0LXR5cGUgQVBJQy4gKi8KICAgICAgICBpZiAoIChpY3JfbG93ICYgKEFQ
SUNfSU5UX0xFVkVMVFJJRyB8IEFQSUNfSU5UX0FTU0VSVCkpID09CiAgICAgICAgICAgICBBUElD
X0lOVF9MRVZFTFRSSUcgKQogICAgICAgICAgICBicmVhazsKICAgICAgICAvKiBOb3RoaW5nIHRv
IGRvIGlmIHRoZSBWQ1BVIGlzIGFscmVhZHkgcmVzZXQuICovCiAgICAgICAgaWYgKCAhdi0+aXNf
aW5pdGlhbGlzZWQgKQogICAgICAgICAgICBicmVhazsKICAgICAgICBodm1fdmNwdV9kb3duKHYp
OwogICAgICAgIHJjID0gdmxhcGljX3NjaGVkdWxlX2luaXRfc2lwaV90YXNrbGV0KHYsIGljcl9s
b3cpOwogICAgICAgIGJyZWFrOwrigKbigKYKfQrigKbigKYKSSB0aGluayB0aGF0IHdoZW4gd2Ug
aW5wdXQgdGhlIHNodXRkb3duIGNvbW1hbmQgaW4gR3Vlc3RPUywgeGVuIHdpbGwgZmlyc3QKY2F0
Y2ggdGhlIEFQSUNfRE1fSU5JVCBhbmQgdGhlbiBjYWxsIHRoZQrigJhodm1fdmNwdV9kb3duKHYp
4oCZ44CB4oCZZG9tYWluX3NodXRkb3duKCnigJkgYW5kIHNvIG9uICwgaXMgdGhhdCByaWdodD8g
SWYgbm90LAp3aGVyZSBpcyB0aGUgY29kZSBlbnRyYW5jZSB3aGVuIHNodXRkb3duIG9wZXJhdGlv
biBvY2N1cnM/CgoKCi0tClZpZXcgdGhpcyBtZXNzYWdlIGluIGNvbnRleHQ6IGh0dHA6Ly94ZW4u
MTA0NTcxMi5uNS5uYWJibGUuY29tL0Zyb20td2hpY2gtcGxhY2UtaW4tc291cmNlLWNvZGUtWGVu
LXN0YXJ0LXRvLWRlYWwtd2l0aC10aGUtR3Vlc3RPUy1zaHV0ZG93bi1vcGVyYXRpb24tdHA1NzEx
NDIyLmh0bWwKU2VudCBmcm9tIHRoZSBYZW4gLSBEZXYgbWFpbGluZyBsaXN0IGFyY2hpdmUgYXQg
TmFiYmxlLmNvbS4KCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbi5vcmcKaHR0cDov
L2xpc3RzLnhlbi5vcmcveGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Fri Sep 21 07:46:46 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Sep 2012 07: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 1TExwS-0005tE-H2; Fri, 21 Sep 2012 07:46:28 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <vivagin@yeah.net>) id 1TEuVl-0002sN-7A
	for xen-devel@lists.xensource.com; Fri, 21 Sep 2012 04:06:41 +0000
Received: from [85.158.139.83:43539] by server-1.bemta-5.messagelabs.com id
	5B/54-04809-0D7EB505; Fri, 21 Sep 2012 04:06:40 +0000
X-Env-Sender: vivagin@yeah.net
X-Msg-Ref: server-9.tower-182.messagelabs.com!1348200398!30805280!1
X-Originating-IP: [216.139.236.26]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22652 invoked from network); 21 Sep 2012 04:06:39 -0000
Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26)
	by server-9.tower-182.messagelabs.com with AES256-SHA encrypted SMTP;
	21 Sep 2012 04:06:39 -0000
Received: from [192.168.236.26] (helo=sam.nabble.com)
	by sam.nabble.com with esmtp (Exim 4.72)
	(envelope-from <vivagin@yeah.net>) id 1TEuVh-0005wg-Rz
	for xen-devel@lists.xensource.com; Thu, 20 Sep 2012 21:06:37 -0700
Date: Thu, 20 Sep 2012 21:06:37 -0700 (PDT)
From: Bruce Granger <vivagin@yeah.net>
To: xen-devel@lists.xensource.com
Message-ID: <1348200397859-5711422.post@n5.nabble.com>
MIME-Version: 1.0
X-Mailman-Approved-At: Fri, 21 Sep 2012 07:46:27 +0000
Subject: [Xen-devel] From which place in source code Xen start to deal with
 the GuestOS shutdown 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="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

SGVsbG8gZXZlcnlvbmUhCkkgZmVlbCBJJ20gc3RpbGwgYSBuZXcgYmFieSB0aG91Z2ggSSBoYXZl
IGJlZW4gc3R1ZHkgeGVuIHNvdXJjZSBjb2RlIGZvcgpzb21lIGRheXMhCldoZW4gSSBzaHV0ZG93
biBHdWVzdE9TLCBJIHdhbnQgdG8gZ2V0IHRvIGtub3cgaG93IFhlbiBkZWFsIHdpdGggdGhlCm9w
ZXJhdGlvbj8gSSBmaW5kIHRoZSBjb2RlIGluIHhlblxhcmNoXHg4Nlxodm1cdmxhcGljLmMsIHNl
ZToKc3RhdGljIGludCB2bGFwaWNfYWNjZXB0X2lycShzdHJ1Y3QgdmNwdSAqdiwgdWludDMyX3Qg
aWNyX2xvdykKewrigKbigKYKc3dpdGNoICggaWNyX2xvdyAmIEFQSUNfTU9ERV9NQVNLICkKewri
gKbigKYKICAgIGNhc2UgQVBJQ19ETV9JTklUOgogICAgICAgIC8qIE5vIHdvcmsgb24gSU5JVCBk
ZS1hc3NlcnQgZm9yIFA0LXR5cGUgQVBJQy4gKi8KICAgICAgICBpZiAoIChpY3JfbG93ICYgKEFQ
SUNfSU5UX0xFVkVMVFJJRyB8IEFQSUNfSU5UX0FTU0VSVCkpID09CiAgICAgICAgICAgICBBUElD
X0lOVF9MRVZFTFRSSUcgKQogICAgICAgICAgICBicmVhazsKICAgICAgICAvKiBOb3RoaW5nIHRv
IGRvIGlmIHRoZSBWQ1BVIGlzIGFscmVhZHkgcmVzZXQuICovCiAgICAgICAgaWYgKCAhdi0+aXNf
aW5pdGlhbGlzZWQgKQogICAgICAgICAgICBicmVhazsKICAgICAgICBodm1fdmNwdV9kb3duKHYp
OwogICAgICAgIHJjID0gdmxhcGljX3NjaGVkdWxlX2luaXRfc2lwaV90YXNrbGV0KHYsIGljcl9s
b3cpOwogICAgICAgIGJyZWFrOwrigKbigKYKfQrigKbigKYKSSB0aGluayB0aGF0IHdoZW4gd2Ug
aW5wdXQgdGhlIHNodXRkb3duIGNvbW1hbmQgaW4gR3Vlc3RPUywgeGVuIHdpbGwgZmlyc3QKY2F0
Y2ggdGhlIEFQSUNfRE1fSU5JVCBhbmQgdGhlbiBjYWxsIHRoZQrigJhodm1fdmNwdV9kb3duKHYp
4oCZ44CB4oCZZG9tYWluX3NodXRkb3duKCnigJkgYW5kIHNvIG9uICwgaXMgdGhhdCByaWdodD8g
SWYgbm90LAp3aGVyZSBpcyB0aGUgY29kZSBlbnRyYW5jZSB3aGVuIHNodXRkb3duIG9wZXJhdGlv
biBvY2N1cnM/CgoKCi0tClZpZXcgdGhpcyBtZXNzYWdlIGluIGNvbnRleHQ6IGh0dHA6Ly94ZW4u
MTA0NTcxMi5uNS5uYWJibGUuY29tL0Zyb20td2hpY2gtcGxhY2UtaW4tc291cmNlLWNvZGUtWGVu
LXN0YXJ0LXRvLWRlYWwtd2l0aC10aGUtR3Vlc3RPUy1zaHV0ZG93bi1vcGVyYXRpb24tdHA1NzEx
NDIyLmh0bWwKU2VudCBmcm9tIHRoZSBYZW4gLSBEZXYgbWFpbGluZyBsaXN0IGFyY2hpdmUgYXQg
TmFiYmxlLmNvbS4KCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbi5vcmcKaHR0cDov
L2xpc3RzLnhlbi5vcmcveGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Fri Sep 21 07:46:46 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Sep 2012 07: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 1TExwS-0005t6-3h; Fri, 21 Sep 2012 07:46:28 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <vivagin@yeah.net>) id 1TEtqA-0002Y9-Ns
	for xen-devel@lists.xensource.com; Fri, 21 Sep 2012 03:23:42 +0000
X-Env-Sender: vivagin@yeah.net
X-Msg-Ref: server-12.tower-27.messagelabs.com!1348197815!11838961!1
X-Originating-IP: [216.139.236.26]
X-SpamReason: No, hits=0.9 required=7.0 tests=HTML_20_30,HTML_MESSAGE
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8429 invoked from network); 21 Sep 2012 03:23:36 -0000
Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26)
	by server-12.tower-27.messagelabs.com with AES256-SHA encrypted SMTP;
	21 Sep 2012 03:23:36 -0000
Received: from [192.168.236.26] (helo=sam.nabble.com)
	by sam.nabble.com with esmtp (Exim 4.72)
	(envelope-from <vivagin@yeah.net>) id 1TEtq2-0000iV-KA
	for xen-devel@lists.xensource.com; Thu, 20 Sep 2012 20:23:34 -0700
Date: Thu, 20 Sep 2012 20:23:34 -0700 (PDT)
From: Bruce Granger <vivagin@yeah.net>
To: xen-devel@lists.xensource.com
Message-ID: <1348197814609-5711421.post@n5.nabble.com>
MIME-Version: 1.0
X-Mailman-Approved-At: Fri, 21 Sep 2012 07:46:27 +0000
Subject: [Xen-devel] How could Xen know a certain GuestOS have already
	shutdown?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============5489418311379282620=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============5489418311379282620==
Content-Type: multipart/alternative; 
	boundary="----=_Part_21015_4787649.1348197814612"

------=_Part_21015_4787649.1348197814612
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi everyone!This is probably a familiar problem, but I haven't found anythi=
ng
in the archives or from google yet. I also talked with my parterners but we
haven't got a sure conclusion.Recently I=E2=80=99m caring about a question =
about
shutdown operation:     When we shutdown a GuestOS by giving the command in
its terminal, how can hypervisor get to know that this GuestOS is about to
shutdown and How can hypervisor know that GuestOS has already done the work
of shutdown?       In other word, is there any signal or something else tha=
t
GuestOS deliver to hypervisor to notice that it will shutdown or it has
accomplished its shutdown work?      Does anyone know the detailed
process?Thanks for your help!



--
View this message in context: http://xen.1045712.n5.nabble.com/How-could-Xe=
n-know-a-certain-GuestOS-have-already-shutdown-tp5711421.html
Sent from the Xen - Dev mailing list archive at Nabble.com.
------=_Part_21015_4787649.1348197814612
Content-Type: text/html; charset=UTF8
Content-Transfer-Encoding: quoted-printable

Hi everyone!

This is probably a familiar problem, but I haven't found anything in the ar=
chives or from google yet. I also talked with my parterners but we haven't =
got a sure conclusion.

Recently I=E2=80=99m caring about a question about shutdown operation:=20
    When we shutdown a GuestOS by giving the command in its terminal, how c=
an hypervisor get to know that this GuestOS is about to shutdown and How ca=
n hypervisor know that GuestOS has already done the work of shutdown? =20
     In other word, is there any signal or something else that GuestOS deli=
ver to hypervisor to notice that it will shutdown or it has accomplished it=
s shutdown work?=20
     Does anyone know the detailed process?

Thanks for your help!

=09
=09
=09
<br/><hr align=3D"left" width=3D"300" />
View this message in context: <a href=3D"http://xen.1045712.n5.nabble.com/H=
ow-could-Xen-know-a-certain-GuestOS-have-already-shutdown-tp5711421.html">H=
ow could Xen know a certain GuestOS have already shutdown?</a><br/>
Sent from the <a href=3D"http://xen.1045712.n5.nabble.com/Xen-Dev-f2473738.=
html">Xen - Dev mailing list archive</a> at Nabble.com.<br/>
------=_Part_21015_4787649.1348197814612--


--===============5489418311379282620==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============5489418311379282620==--


From xen-devel-bounces@lists.xen.org Fri Sep 21 07:46:46 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Sep 2012 07: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 1TExwS-0005t6-3h; Fri, 21 Sep 2012 07:46:28 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <vivagin@yeah.net>) id 1TEtqA-0002Y9-Ns
	for xen-devel@lists.xensource.com; Fri, 21 Sep 2012 03:23:42 +0000
X-Env-Sender: vivagin@yeah.net
X-Msg-Ref: server-12.tower-27.messagelabs.com!1348197815!11838961!1
X-Originating-IP: [216.139.236.26]
X-SpamReason: No, hits=0.9 required=7.0 tests=HTML_20_30,HTML_MESSAGE
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8429 invoked from network); 21 Sep 2012 03:23:36 -0000
Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26)
	by server-12.tower-27.messagelabs.com with AES256-SHA encrypted SMTP;
	21 Sep 2012 03:23:36 -0000
Received: from [192.168.236.26] (helo=sam.nabble.com)
	by sam.nabble.com with esmtp (Exim 4.72)
	(envelope-from <vivagin@yeah.net>) id 1TEtq2-0000iV-KA
	for xen-devel@lists.xensource.com; Thu, 20 Sep 2012 20:23:34 -0700
Date: Thu, 20 Sep 2012 20:23:34 -0700 (PDT)
From: Bruce Granger <vivagin@yeah.net>
To: xen-devel@lists.xensource.com
Message-ID: <1348197814609-5711421.post@n5.nabble.com>
MIME-Version: 1.0
X-Mailman-Approved-At: Fri, 21 Sep 2012 07:46:27 +0000
Subject: [Xen-devel] How could Xen know a certain GuestOS have already
	shutdown?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============5489418311379282620=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============5489418311379282620==
Content-Type: multipart/alternative; 
	boundary="----=_Part_21015_4787649.1348197814612"

------=_Part_21015_4787649.1348197814612
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi everyone!This is probably a familiar problem, but I haven't found anythi=
ng
in the archives or from google yet. I also talked with my parterners but we
haven't got a sure conclusion.Recently I=E2=80=99m caring about a question =
about
shutdown operation:     When we shutdown a GuestOS by giving the command in
its terminal, how can hypervisor get to know that this GuestOS is about to
shutdown and How can hypervisor know that GuestOS has already done the work
of shutdown?       In other word, is there any signal or something else tha=
t
GuestOS deliver to hypervisor to notice that it will shutdown or it has
accomplished its shutdown work?      Does anyone know the detailed
process?Thanks for your help!



--
View this message in context: http://xen.1045712.n5.nabble.com/How-could-Xe=
n-know-a-certain-GuestOS-have-already-shutdown-tp5711421.html
Sent from the Xen - Dev mailing list archive at Nabble.com.
------=_Part_21015_4787649.1348197814612
Content-Type: text/html; charset=UTF8
Content-Transfer-Encoding: quoted-printable

Hi everyone!

This is probably a familiar problem, but I haven't found anything in the ar=
chives or from google yet. I also talked with my parterners but we haven't =
got a sure conclusion.

Recently I=E2=80=99m caring about a question about shutdown operation:=20
    When we shutdown a GuestOS by giving the command in its terminal, how c=
an hypervisor get to know that this GuestOS is about to shutdown and How ca=
n hypervisor know that GuestOS has already done the work of shutdown? =20
     In other word, is there any signal or something else that GuestOS deli=
ver to hypervisor to notice that it will shutdown or it has accomplished it=
s shutdown work?=20
     Does anyone know the detailed process?

Thanks for your help!

=09
=09
=09
<br/><hr align=3D"left" width=3D"300" />
View this message in context: <a href=3D"http://xen.1045712.n5.nabble.com/H=
ow-could-Xen-know-a-certain-GuestOS-have-already-shutdown-tp5711421.html">H=
ow could Xen know a certain GuestOS have already shutdown?</a><br/>
Sent from the <a href=3D"http://xen.1045712.n5.nabble.com/Xen-Dev-f2473738.=
html">Xen - Dev mailing list archive</a> at Nabble.com.<br/>
------=_Part_21015_4787649.1348197814612--


--===============5489418311379282620==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============5489418311379282620==--


From xen-devel-bounces@lists.xen.org Fri Sep 21 07:57:11 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Sep 2012 07: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 1TEy6X-0006Cc-M8; Fri, 21 Sep 2012 07:56:53 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1TEy6W-0006CX-NR
	for xen-devel@lists.xen.org; Fri, 21 Sep 2012 07:56:52 +0000
Received: from [85.158.139.83:47491] by server-8.bemta-5.messagelabs.com id
	C0/B2-30083-3CD1C505; Fri, 21 Sep 2012 07:56:51 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1348214210!26965205!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTA1OTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12144 invoked from network); 21 Sep 2012 07:56:51 -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;
	21 Sep 2012 07:56:51 -0000
X-IronPort-AV: E=Sophos;i="4.80,460,1344211200"; d="scan'208";a="14681765"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Sep 2012 07:56: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.279.1;
	Fri, 21 Sep 2012 08:56:50 +0100
Message-ID: <1348214207.26501.58.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Fri, 21 Sep 2012 08:56:47 +0100
In-Reply-To: <505C2F97020000780009CDC9@nat28.tlf.novell.com>
References: <E269205F-457F-4503-BB86-11C0EFA15CEC@gridcentric.ca>
	<505C2F97020000780009CDC9@nat28.tlf.novell.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Andres Lagar-Cavilla <andreslc@gridcentric.ca>, "Keir
	\(Xen.org\)" <keir@xen.org>, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Backport request: 25914:cd2a831d0a41 to
	xen-4.2-testing.hg
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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-09-21 at 08:12 +0100, Jan Beulich wrote:
> >>> On 20.09.12 at 17:23, Andres Lagar-Cavilla <andreslc@gridcentric.ca> wrote:
> > It seems back porting has started. I would have asked for a few others, but 
> > I've been beaten to the punch!
> 
> Do you realize that you Cc-ed the wrong people (neither Keir nor
> I generally take care of tools issues).
> 
> Ian, Ian - can one of you take care of this?

I think we (Ian J & me) agreed that Ian J is going to continue to look
after backport requests.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 21 07:57:11 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Sep 2012 07: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 1TEy6X-0006Cc-M8; Fri, 21 Sep 2012 07:56:53 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1TEy6W-0006CX-NR
	for xen-devel@lists.xen.org; Fri, 21 Sep 2012 07:56:52 +0000
Received: from [85.158.139.83:47491] by server-8.bemta-5.messagelabs.com id
	C0/B2-30083-3CD1C505; Fri, 21 Sep 2012 07:56:51 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1348214210!26965205!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTA1OTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12144 invoked from network); 21 Sep 2012 07:56:51 -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;
	21 Sep 2012 07:56:51 -0000
X-IronPort-AV: E=Sophos;i="4.80,460,1344211200"; d="scan'208";a="14681765"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Sep 2012 07:56: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.279.1;
	Fri, 21 Sep 2012 08:56:50 +0100
Message-ID: <1348214207.26501.58.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Fri, 21 Sep 2012 08:56:47 +0100
In-Reply-To: <505C2F97020000780009CDC9@nat28.tlf.novell.com>
References: <E269205F-457F-4503-BB86-11C0EFA15CEC@gridcentric.ca>
	<505C2F97020000780009CDC9@nat28.tlf.novell.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Andres Lagar-Cavilla <andreslc@gridcentric.ca>, "Keir
	\(Xen.org\)" <keir@xen.org>, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Backport request: 25914:cd2a831d0a41 to
	xen-4.2-testing.hg
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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-09-21 at 08:12 +0100, Jan Beulich wrote:
> >>> On 20.09.12 at 17:23, Andres Lagar-Cavilla <andreslc@gridcentric.ca> wrote:
> > It seems back porting has started. I would have asked for a few others, but 
> > I've been beaten to the punch!
> 
> Do you realize that you Cc-ed the wrong people (neither Keir nor
> I generally take care of tools issues).
> 
> Ian, Ian - can one of you take care of this?

I think we (Ian J & me) agreed that Ian J is going to continue to look
after backport requests.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 21 08:06:28 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Sep 2012 08: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 1TEyFU-0006r6-MA; Fri, 21 Sep 2012 08:06:08 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1TEyFS-0006r1-Sf
	for xen-devel@lists.xensource.com; Fri, 21 Sep 2012 08:06:07 +0000
Received: from [85.158.139.211:43373] by server-15.bemta-5.messagelabs.com id
	E7/85-23541-EEF1C505; Fri, 21 Sep 2012 08:06:06 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-3.tower-206.messagelabs.com!1348214764!19408512!1
X-Originating-IP: [209.85.215.171]
X-SpamReason: No, hits=0.6 required=7.0 tests=HTML_30_40,HTML_MESSAGE,
	MIME_QP_LONG_LINE,ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23926 invoked from network); 21 Sep 2012 08:06:05 -0000
Received: from mail-ey0-f171.google.com (HELO mail-ey0-f171.google.com)
	(209.85.215.171)
	by server-3.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Sep 2012 08:06:05 -0000
Received: by eaah11 with SMTP id h11so1012363eaa.30
	for <xen-devel@lists.xensource.com>;
	Fri, 21 Sep 2012 01:06:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=user-agent:date:subject:from:to:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type;
	bh=Ti44jclJxTKJ0JgI+dv9Hdr00xHT6+Ym9GPkMNBnw8Q=;
	b=B9wyj9gfBWXAYOX+0dHD2br0ECKt+Pe8FDgSkm7XQM27VlwyQCfXVMpg/bKV2EyIF1
	RPlJvjna5qZi9RcXGEkAaqQZoWrt6KlrBkxGmsuBKwtTuLGIZ044IqV0GYVvmo6pH+de
	RPkFKXYtBCVPtZiq18xfVittApiprpScRrqqWzP+klRb9BqqOewrtvd87+TQqy39gbGT
	aMyIZppA6brTJlHrBhBlayvH3sWduSbAkfiWEAoFd7fAroOS+qlWy2nqoZPDYMD0VcW+
	MRF1HFk4yPO9fN/mZ6TcFhHm0CtFZbU2kNKpKaIOXlvSFmtKA7/OFQ8pIFfYVg6olnAH
	15qA==
Received: by 10.14.182.134 with SMTP id o6mr5141384eem.26.1348214764401;
	Fri, 21 Sep 2012 01:06:04 -0700 (PDT)
Received: from [192.168.1.69] (host86-167-82-156.range86-167.btcentralplus.com.
	[86.167.82.156])
	by mx.google.com with ESMTPS id r45sm21802313eem.6.2012.09.21.01.06.03
	(version=SSLv3 cipher=OTHER); Fri, 21 Sep 2012 01:06:03 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Fri, 21 Sep 2012 09:06:01 +0100
From: Keir Fraser <keir.xen@gmail.com>
To: Bruce Granger <vivagin@yeah.net>,
	<xen-devel@lists.xensource.com>
Message-ID: <CC81DE79.3F4C6%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] How could Xen know a certain GuestOS have already
	shutdown?
Thread-Index: Ac2Xz/BYEJaj608tuk2hNL5N4kXntQ==
In-Reply-To: <1348197814609-5711421.post@n5.nabble.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] How could Xen know a certain GuestOS have already
 shutdown?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============7816328326419399765=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--===============7816328326419399765==
Content-type: multipart/alternative;
	boundary="B_3431063163_71240419"

> This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--B_3431063163_71240419
Content-type: text/plain;
	charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable

When the guest shuts down, Xen sends VIRQ_DOM0_EXC to dom0. This is picked
up by xenstored which fires the @releaseDomain watch. Anyone in dom0 can
register on that watch. Or see libxl__domaindeathcheck_* functions in
libxl/libxl_event.c for another method to pick up on domain shutdowns.

 -- Keir


On 21/09/2012 04:23, "Bruce Granger" <vivagin@yeah.net> wrote:

> Hi everyone! This is probably a familiar problem, but I haven't found any=
thing
> in the archives or from google yet. I also talked with my parterners but =
we
> haven't got a sure conclusion. Recently I=B9m caring about a question about
> shutdown operation:  When we shutdown a GuestOS by giving the command in =
its
> terminal, how can hypervisor get to know that this GuestOS is about to
> shutdown and How can hypervisor know that GuestOS has already done the wo=
rk of
> shutdown?   In other word, is there any signal or something else that Gue=
stOS
> deliver to hypervisor to notice that it will shutdown or it has accomplis=
hed
> its shutdown work?  Does anyone know the detailed process? Thanks for you=
r
> help!=20
>=20
> View this message in context: How could Xen know a certain GuestOS have
> already shutdown?
> <http://xen.1045712.n5.nabble.com/How-could-Xen-know-a-certain-GuestOS-ha=
ve-al
> ready-shutdown-tp5711421.html> Sent from the Xen - Dev mailing list archi=
ve
> <http://xen.1045712.n5.nabble.com/Xen-Dev-f2473738.html>  at Nabble.com.
>=20
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel


--B_3431063163_71240419
Content-type: text/html;
	charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable

<HTML>
<HEAD>
<TITLE>Re: [Xen-devel] How could Xen know a certain GuestOS have already sh=
utdown?</TITLE>
</HEAD>
<BODY>
<FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN STYLE=3D'font-size:11pt=
'>When the guest shuts down, Xen sends VIRQ_DOM0_EXC to dom0. This is picked=
 up by xenstored which fires the @releaseDomain watch. Anyone in dom0 can re=
gister on that watch. Or see libxl__domaindeathcheck_* functions in libxl/li=
bxl_event.c for another method to pick up on domain shutdowns.<BR>
<BR>
&nbsp;-- Keir<BR>
<BR>
<BR>
On 21/09/2012 04:23, &quot;Bruce Granger&quot; &lt;<a href=3D"vivagin@yeah.ne=
t">vivagin@yeah.net</a>&gt; wrote:<BR>
<BR>
</SPAN></FONT><BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><=
SPAN STYLE=3D'font-size:11pt'>Hi everyone! This is probably a familiar problem=
, but I haven't found anything in the archives or from google yet. I also ta=
lked with my parterners but we haven't got a sure conclusion. Recently I&#82=
17;m caring about a question about shutdown operation: &nbsp;When we shutdow=
n a GuestOS by giving the command in its terminal, how can hypervisor get to=
 know that this GuestOS is about to shutdown and How can hypervisor know tha=
t GuestOS has already done the work of shutdown? &nbsp;&nbsp;In other word, =
is there any signal or something else that GuestOS deliver to hypervisor to =
notice that it will shutdown or it has accomplished its shutdown work? &nbsp=
;Does anyone know the detailed process? Thanks for your help! <BR>
<HR ALIGN=3DLEFT SIZE=3D"3" WIDTH=3D"300">View this message in context: How could=
 Xen know a certain GuestOS have already shutdown? &lt;<a href=3D"http://xen.1=
045712.n5.nabble.com/How-could-Xen-know-a-certain-GuestOS-have-already-shutd=
own-tp5711421.html">http://xen.1045712.n5.nabble.com/How-could-Xen-know-a-ce=
rtain-GuestOS-have-already-shutdown-tp5711421.html</a>&gt; Sent from the Xen=
 - Dev mailing list archive &lt;<a href=3D"http://xen.1045712.n5.nabble.com/Xe=
n-Dev-f2473738.html">http://xen.1045712.n5.nabble.com/Xen-Dev-f2473738.html<=
/a>&gt; &nbsp;at Nabble.com.<BR>
<HR ALIGN=3DCENTER SIZE=3D"3" WIDTH=3D"95%"></SPAN></FONT><FONT SIZE=3D"2"><FONT FA=
CE=3D"Consolas, Courier New, Courier"><SPAN STYLE=3D'font-size:10pt'>___________=
____________________________________<BR>
Xen-devel mailing list<BR>
<a href=3D"Xen-devel@lists.xen.org">Xen-devel@lists.xen.org</a><BR>
<a href=3D"http://lists.xen.org/xen-devel">http://lists.xen.org/xen-devel</a>=
<BR>
</SPAN></FONT></FONT></BLOCKQUOTE>
</BODY>
</HTML>


--B_3431063163_71240419--




--===============7816328326419399765==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============7816328326419399765==--




From xen-devel-bounces@lists.xen.org Fri Sep 21 08:06:28 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Sep 2012 08: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 1TEyFU-0006r6-MA; Fri, 21 Sep 2012 08:06:08 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1TEyFS-0006r1-Sf
	for xen-devel@lists.xensource.com; Fri, 21 Sep 2012 08:06:07 +0000
Received: from [85.158.139.211:43373] by server-15.bemta-5.messagelabs.com id
	E7/85-23541-EEF1C505; Fri, 21 Sep 2012 08:06:06 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-3.tower-206.messagelabs.com!1348214764!19408512!1
X-Originating-IP: [209.85.215.171]
X-SpamReason: No, hits=0.6 required=7.0 tests=HTML_30_40,HTML_MESSAGE,
	MIME_QP_LONG_LINE,ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23926 invoked from network); 21 Sep 2012 08:06:05 -0000
Received: from mail-ey0-f171.google.com (HELO mail-ey0-f171.google.com)
	(209.85.215.171)
	by server-3.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Sep 2012 08:06:05 -0000
Received: by eaah11 with SMTP id h11so1012363eaa.30
	for <xen-devel@lists.xensource.com>;
	Fri, 21 Sep 2012 01:06:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=user-agent:date:subject:from:to:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type;
	bh=Ti44jclJxTKJ0JgI+dv9Hdr00xHT6+Ym9GPkMNBnw8Q=;
	b=B9wyj9gfBWXAYOX+0dHD2br0ECKt+Pe8FDgSkm7XQM27VlwyQCfXVMpg/bKV2EyIF1
	RPlJvjna5qZi9RcXGEkAaqQZoWrt6KlrBkxGmsuBKwtTuLGIZ044IqV0GYVvmo6pH+de
	RPkFKXYtBCVPtZiq18xfVittApiprpScRrqqWzP+klRb9BqqOewrtvd87+TQqy39gbGT
	aMyIZppA6brTJlHrBhBlayvH3sWduSbAkfiWEAoFd7fAroOS+qlWy2nqoZPDYMD0VcW+
	MRF1HFk4yPO9fN/mZ6TcFhHm0CtFZbU2kNKpKaIOXlvSFmtKA7/OFQ8pIFfYVg6olnAH
	15qA==
Received: by 10.14.182.134 with SMTP id o6mr5141384eem.26.1348214764401;
	Fri, 21 Sep 2012 01:06:04 -0700 (PDT)
Received: from [192.168.1.69] (host86-167-82-156.range86-167.btcentralplus.com.
	[86.167.82.156])
	by mx.google.com with ESMTPS id r45sm21802313eem.6.2012.09.21.01.06.03
	(version=SSLv3 cipher=OTHER); Fri, 21 Sep 2012 01:06:03 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Fri, 21 Sep 2012 09:06:01 +0100
From: Keir Fraser <keir.xen@gmail.com>
To: Bruce Granger <vivagin@yeah.net>,
	<xen-devel@lists.xensource.com>
Message-ID: <CC81DE79.3F4C6%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] How could Xen know a certain GuestOS have already
	shutdown?
Thread-Index: Ac2Xz/BYEJaj608tuk2hNL5N4kXntQ==
In-Reply-To: <1348197814609-5711421.post@n5.nabble.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] How could Xen know a certain GuestOS have already
 shutdown?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============7816328326419399765=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--===============7816328326419399765==
Content-type: multipart/alternative;
	boundary="B_3431063163_71240419"

> This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--B_3431063163_71240419
Content-type: text/plain;
	charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable

When the guest shuts down, Xen sends VIRQ_DOM0_EXC to dom0. This is picked
up by xenstored which fires the @releaseDomain watch. Anyone in dom0 can
register on that watch. Or see libxl__domaindeathcheck_* functions in
libxl/libxl_event.c for another method to pick up on domain shutdowns.

 -- Keir


On 21/09/2012 04:23, "Bruce Granger" <vivagin@yeah.net> wrote:

> Hi everyone! This is probably a familiar problem, but I haven't found any=
thing
> in the archives or from google yet. I also talked with my parterners but =
we
> haven't got a sure conclusion. Recently I=B9m caring about a question about
> shutdown operation:  When we shutdown a GuestOS by giving the command in =
its
> terminal, how can hypervisor get to know that this GuestOS is about to
> shutdown and How can hypervisor know that GuestOS has already done the wo=
rk of
> shutdown?   In other word, is there any signal or something else that Gue=
stOS
> deliver to hypervisor to notice that it will shutdown or it has accomplis=
hed
> its shutdown work?  Does anyone know the detailed process? Thanks for you=
r
> help!=20
>=20
> View this message in context: How could Xen know a certain GuestOS have
> already shutdown?
> <http://xen.1045712.n5.nabble.com/How-could-Xen-know-a-certain-GuestOS-ha=
ve-al
> ready-shutdown-tp5711421.html> Sent from the Xen - Dev mailing list archi=
ve
> <http://xen.1045712.n5.nabble.com/Xen-Dev-f2473738.html>  at Nabble.com.
>=20
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel


--B_3431063163_71240419
Content-type: text/html;
	charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable

<HTML>
<HEAD>
<TITLE>Re: [Xen-devel] How could Xen know a certain GuestOS have already sh=
utdown?</TITLE>
</HEAD>
<BODY>
<FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN STYLE=3D'font-size:11pt=
'>When the guest shuts down, Xen sends VIRQ_DOM0_EXC to dom0. This is picked=
 up by xenstored which fires the @releaseDomain watch. Anyone in dom0 can re=
gister on that watch. Or see libxl__domaindeathcheck_* functions in libxl/li=
bxl_event.c for another method to pick up on domain shutdowns.<BR>
<BR>
&nbsp;-- Keir<BR>
<BR>
<BR>
On 21/09/2012 04:23, &quot;Bruce Granger&quot; &lt;<a href=3D"vivagin@yeah.ne=
t">vivagin@yeah.net</a>&gt; wrote:<BR>
<BR>
</SPAN></FONT><BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><=
SPAN STYLE=3D'font-size:11pt'>Hi everyone! This is probably a familiar problem=
, but I haven't found anything in the archives or from google yet. I also ta=
lked with my parterners but we haven't got a sure conclusion. Recently I&#82=
17;m caring about a question about shutdown operation: &nbsp;When we shutdow=
n a GuestOS by giving the command in its terminal, how can hypervisor get to=
 know that this GuestOS is about to shutdown and How can hypervisor know tha=
t GuestOS has already done the work of shutdown? &nbsp;&nbsp;In other word, =
is there any signal or something else that GuestOS deliver to hypervisor to =
notice that it will shutdown or it has accomplished its shutdown work? &nbsp=
;Does anyone know the detailed process? Thanks for your help! <BR>
<HR ALIGN=3DLEFT SIZE=3D"3" WIDTH=3D"300">View this message in context: How could=
 Xen know a certain GuestOS have already shutdown? &lt;<a href=3D"http://xen.1=
045712.n5.nabble.com/How-could-Xen-know-a-certain-GuestOS-have-already-shutd=
own-tp5711421.html">http://xen.1045712.n5.nabble.com/How-could-Xen-know-a-ce=
rtain-GuestOS-have-already-shutdown-tp5711421.html</a>&gt; Sent from the Xen=
 - Dev mailing list archive &lt;<a href=3D"http://xen.1045712.n5.nabble.com/Xe=
n-Dev-f2473738.html">http://xen.1045712.n5.nabble.com/Xen-Dev-f2473738.html<=
/a>&gt; &nbsp;at Nabble.com.<BR>
<HR ALIGN=3DCENTER SIZE=3D"3" WIDTH=3D"95%"></SPAN></FONT><FONT SIZE=3D"2"><FONT FA=
CE=3D"Consolas, Courier New, Courier"><SPAN STYLE=3D'font-size:10pt'>___________=
____________________________________<BR>
Xen-devel mailing list<BR>
<a href=3D"Xen-devel@lists.xen.org">Xen-devel@lists.xen.org</a><BR>
<a href=3D"http://lists.xen.org/xen-devel">http://lists.xen.org/xen-devel</a>=
<BR>
</SPAN></FONT></FONT></BLOCKQUOTE>
</BODY>
</HTML>


--B_3431063163_71240419--




--===============7816328326419399765==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============7816328326419399765==--




From xen-devel-bounces@lists.xen.org Fri Sep 21 08:08:56 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Sep 2012 08:08:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TEyHx-0006xZ-8J; Fri, 21 Sep 2012 08:08:41 +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 1TEyHv-0006xP-QJ
	for xen-devel@lists.xensource.com; Fri, 21 Sep 2012 08:08:40 +0000
Received: from [85.158.143.35:64736] by server-2.bemta-4.messagelabs.com id
	77/E1-06610-7802C505; Fri, 21 Sep 2012 08:08:39 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1348214918!14566423!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-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22480 invoked from network); 21 Sep 2012 08:08:38 -0000
Received: from mail-ey0-f171.google.com (HELO mail-ey0-f171.google.com)
	(209.85.215.171)
	by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Sep 2012 08:08:38 -0000
Received: by eaah11 with SMTP id h11so1013218eaa.30
	for <xen-devel@lists.xensource.com>;
	Fri, 21 Sep 2012 01:08:38 -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=rPAP5mAFrYLM6ml4uIsNVsX7yl3NyQ5uSHqv9jG39N4=;
	b=h/e4vRNpqszLadeAdKa9YLekHje400ertkfZCaKMpu/y7F9OQqi+JUtYxbUSGmxsS1
	tjIiCrZSmSdEl0DyPVxoE7PWb/aC/44n05seTT7DedfuroxUNzXftGgeINV61+sglCIA
	jOU0yZ5j/lwoPQRyRJSUrzXcwPlOktlNwOjVMFa7yb/X9E7Wb+K5IOiyhApuDK1O0a0O
	xDrT7pkfzGZ9WMZnKDu/YocfMq5l6mgn06BH1mcRLgFkEVRyMU3N5MCnxciwyfkfGAhH
	KtZjsloh3cEkAyvnOiWsvUJqz3vAcX+gOM77pn2LLw3O0tc4rH/vGsl4RCQgnLwRtIKf
	CFdQ==
Received: by 10.14.180.68 with SMTP id i44mr5202693eem.20.1348214918035;
	Fri, 21 Sep 2012 01:08:38 -0700 (PDT)
Received: from [192.168.1.69] (host86-167-82-156.range86-167.btcentralplus.com.
	[86.167.82.156])
	by mx.google.com with ESMTPS id i41sm21807627eem.7.2012.09.21.01.08.35
	(version=SSLv3 cipher=OTHER); Fri, 21 Sep 2012 01:08:37 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Fri, 21 Sep 2012 09:08:31 +0100
From: Keir Fraser <keir.xen@gmail.com>
To: Bruce Granger <vivagin@yeah.net>,
	<xen-devel@lists.xensource.com>
Message-ID: <CC81DF0F.3F4C8%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] From which place in source code Xen start to deal
	with the GuestOS shutdown operation?
Thread-Index: Ac2X0EnBK/ce8cvFoEiEv/JJVlxB0g==
In-Reply-To: <1348200397859-5711422.post@n5.nabble.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] From which place in source code Xen start to deal
 with the GuestOS shutdown 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="iso-2022-jp"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 21/09/2012 05:06, "Bruce Granger" <vivagin@yeah.net> wrote:

> Hello everyone!
I feel I'm still a new baby though I have been study xen
> source code for
some days!
When I shutdown GuestOS, I want to get to know how
> Xen deal with the
operation? I find the code in xen\arch\x86\hvm\vlapic.c,
> see:
static int vlapic_accept_irq(struct vcpu *v, uint32_t
> icr_low)
{
$B!D!D(B
switch ( icr_low & APIC_MODE_MASK )
{
$B!D!D(B
    case APIC_DM_INIT:

> /* No work on INIT de-assert for P4-type APIC. */
        if ( (icr_low &
> (APIC_INT_LEVELTRIG | APIC_INT_ASSERT)) ==
             APIC_INT_LEVELTRIG )

> break;
        /* Nothing to do if the VCPU is already reset. */
        if (
> !v->is_initialised )
            break;
        hvm_vcpu_down(v);
        rc =
> vlapic_schedule_init_sipi_tasklet(v, icr_low);
        break;
$B!D!D(B
}
$B!D!D(B
I think
> that when we input the shutdown command in GuestOS, xen will first
catch the
> APIC_DM_INIT and then call the
$B!F(Bhvm_vcpu_down(v)$B!G!"!G(Bdomain_shutdown()$B!G(B and so
> on , is that right? If not,
where is the code entrance when shutdown operation
> occurs?



--
View this message in context:


Yes that's about right. Some guests will not re-INIT the VCPUs but will
simply leave them HLTed with interrupts disabled. We also pick up that case
in hvm_hlt().

Once all VCPUs are down, hvm_vcpu_down() dows the domain_shutdown() call,
which then triggers machinery in dom0 to kill off the domain fully. I
described that path in my previous email.

 -- Keir

> http://xen.1045712.n5.nabble.com/From-which-place-in-source-code-Xen-start-to-
> deal-with-the-GuestOS-shutdown-operation-tp5711422.html
Sent from the Xen -
> Dev mailing list archive at
> Nabble.com.

_______________________________________________
Xen-devel mailing
> list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 21 08:08:56 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Sep 2012 08:08:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TEyHx-0006xZ-8J; Fri, 21 Sep 2012 08:08:41 +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 1TEyHv-0006xP-QJ
	for xen-devel@lists.xensource.com; Fri, 21 Sep 2012 08:08:40 +0000
Received: from [85.158.143.35:64736] by server-2.bemta-4.messagelabs.com id
	77/E1-06610-7802C505; Fri, 21 Sep 2012 08:08:39 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1348214918!14566423!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-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22480 invoked from network); 21 Sep 2012 08:08:38 -0000
Received: from mail-ey0-f171.google.com (HELO mail-ey0-f171.google.com)
	(209.85.215.171)
	by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Sep 2012 08:08:38 -0000
Received: by eaah11 with SMTP id h11so1013218eaa.30
	for <xen-devel@lists.xensource.com>;
	Fri, 21 Sep 2012 01:08:38 -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=rPAP5mAFrYLM6ml4uIsNVsX7yl3NyQ5uSHqv9jG39N4=;
	b=h/e4vRNpqszLadeAdKa9YLekHje400ertkfZCaKMpu/y7F9OQqi+JUtYxbUSGmxsS1
	tjIiCrZSmSdEl0DyPVxoE7PWb/aC/44n05seTT7DedfuroxUNzXftGgeINV61+sglCIA
	jOU0yZ5j/lwoPQRyRJSUrzXcwPlOktlNwOjVMFa7yb/X9E7Wb+K5IOiyhApuDK1O0a0O
	xDrT7pkfzGZ9WMZnKDu/YocfMq5l6mgn06BH1mcRLgFkEVRyMU3N5MCnxciwyfkfGAhH
	KtZjsloh3cEkAyvnOiWsvUJqz3vAcX+gOM77pn2LLw3O0tc4rH/vGsl4RCQgnLwRtIKf
	CFdQ==
Received: by 10.14.180.68 with SMTP id i44mr5202693eem.20.1348214918035;
	Fri, 21 Sep 2012 01:08:38 -0700 (PDT)
Received: from [192.168.1.69] (host86-167-82-156.range86-167.btcentralplus.com.
	[86.167.82.156])
	by mx.google.com with ESMTPS id i41sm21807627eem.7.2012.09.21.01.08.35
	(version=SSLv3 cipher=OTHER); Fri, 21 Sep 2012 01:08:37 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Fri, 21 Sep 2012 09:08:31 +0100
From: Keir Fraser <keir.xen@gmail.com>
To: Bruce Granger <vivagin@yeah.net>,
	<xen-devel@lists.xensource.com>
Message-ID: <CC81DF0F.3F4C8%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] From which place in source code Xen start to deal
	with the GuestOS shutdown operation?
Thread-Index: Ac2X0EnBK/ce8cvFoEiEv/JJVlxB0g==
In-Reply-To: <1348200397859-5711422.post@n5.nabble.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] From which place in source code Xen start to deal
 with the GuestOS shutdown 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="iso-2022-jp"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 21/09/2012 05:06, "Bruce Granger" <vivagin@yeah.net> wrote:

> Hello everyone!
I feel I'm still a new baby though I have been study xen
> source code for
some days!
When I shutdown GuestOS, I want to get to know how
> Xen deal with the
operation? I find the code in xen\arch\x86\hvm\vlapic.c,
> see:
static int vlapic_accept_irq(struct vcpu *v, uint32_t
> icr_low)
{
$B!D!D(B
switch ( icr_low & APIC_MODE_MASK )
{
$B!D!D(B
    case APIC_DM_INIT:

> /* No work on INIT de-assert for P4-type APIC. */
        if ( (icr_low &
> (APIC_INT_LEVELTRIG | APIC_INT_ASSERT)) ==
             APIC_INT_LEVELTRIG )

> break;
        /* Nothing to do if the VCPU is already reset. */
        if (
> !v->is_initialised )
            break;
        hvm_vcpu_down(v);
        rc =
> vlapic_schedule_init_sipi_tasklet(v, icr_low);
        break;
$B!D!D(B
}
$B!D!D(B
I think
> that when we input the shutdown command in GuestOS, xen will first
catch the
> APIC_DM_INIT and then call the
$B!F(Bhvm_vcpu_down(v)$B!G!"!G(Bdomain_shutdown()$B!G(B and so
> on , is that right? If not,
where is the code entrance when shutdown operation
> occurs?



--
View this message in context:


Yes that's about right. Some guests will not re-INIT the VCPUs but will
simply leave them HLTed with interrupts disabled. We also pick up that case
in hvm_hlt().

Once all VCPUs are down, hvm_vcpu_down() dows the domain_shutdown() call,
which then triggers machinery in dom0 to kill off the domain fully. I
described that path in my previous email.

 -- Keir

> http://xen.1045712.n5.nabble.com/From-which-place-in-source-code-Xen-start-to-
> deal-with-the-GuestOS-shutdown-operation-tp5711422.html
Sent from the Xen -
> Dev mailing list archive at
> Nabble.com.

_______________________________________________
Xen-devel mailing
> list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 21 08:09:33 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Sep 2012 08: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 1TEyIX-00070z-Lj; Fri, 21 Sep 2012 08:09: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 1TEyIV-00070m-RE
	for xen-devel@lists.xensource.com; Fri, 21 Sep 2012 08:09:16 +0000
Received: from [85.158.143.35:10706] by server-2.bemta-4.messagelabs.com id
	5A/D2-06610-BA02C505; Fri, 21 Sep 2012 08:09:15 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1348214953!15761740!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTA1OTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5181 invoked from network); 21 Sep 2012 08:09:14 -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 Sep 2012 08:09:14 -0000
X-IronPort-AV: E=Sophos;i="4.80,460,1344211200"; d="scan'208";a="14682042"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Sep 2012 08:08:02 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Fri, 21 Sep 2012 09:08:01 +0100
Message-ID: <1348214879.26501.68.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Bruce Granger <vivagin@yeah.net>
Date: Fri, 21 Sep 2012 09:07:59 +0100
In-Reply-To: <1348202102238-5711423.post@n5.nabble.com>
References: <1348202102238-5711423.post@n5.nabble.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Relationship between GuestOS shutdown and destroy
 operations?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gRnJpLCAyMDEyLTA5LTIxIGF0IDA1OjM1ICswMTAwLCBCcnVjZSBHcmFuZ2VyIHdyb3RlOgo+
IEhlbGxvIGV2ZXJ5b25lIQoKSGVsbG8uCgpQbGVhc2UgZG9uJ3Qgc3BhbSB0aGUgbGlzdCBieSBy
ZXNlbmRpbmcgZWZmZWN0aXZlbHkgdGhlIHNhbWUgcXVlc3Rpb24gMwp0aW1lcyBpbiBsZXNzIHRo
YW4gMS41IGhvdXJzLiBUaGUgeGVuLWRldmVsIGxpc3QgbWVtYmVyc2hpcCBpcyBzcHJlYWQKb3Zl
ciBtdWx0aXBsZSB0aW1lIHpvbmVzLCBzbyBwbGVhc2UgbGVhdmUgZW5vdWdoIHRpbWUgZm9yIHBl
b3BsZSB0bwphY3R1YWxseSByZWNlaXZlIGFuZCBkaWdlc3QgeW91ciBtYWlscy4gQWxzbyBiZSBy
ZW1lbWJlciB0aGF0IHlvdSBhc2tpbmcKcGVvcGxlIHRvIHRha2UgdGltZSBvdXQgZnJvbSB3aGF0
ZXZlciB0aGV5IGFyZSBkb2luZyB0byByZXBseSB0byB5b3UgYW5kCnRoZXkgbWF5IG5vdCBkbyBz
byBzdHJhaWdodCBhd2F5LgoKQWxzbyBwbGVhc2Uga2VlcCB0aGluZ3MgaW4gdGhlIHNhbWUgdGhy
ZWFkICh5b3UgaGF2ZSBzdGFydGVkIHRocmVlCnNlcGFyYXRlIHRocmVhZHMgdG9kYXkpIGFuZCBy
ZW1lbWJlciBxdW90ZSBmcm9tIHByZXZpb3VzIG1haWxzIHdoZXJlCmFwcHJvcHJpYXRlLgoKSSBy
ZWNvbW1lbmQgc3Vic2NyaWJpbmcgdGhlIGxpc3QgZGlyZWN0bHkgcmF0aGVyIHRoYW4gdXNpbmcg
bmFiYmxlIHNpbmNlCnRoYXQgc2VydmljZSB0ZW5kcyB0byBlbmNvdXJhZ2UgcXVpdGUgcG9vciBu
ZXRpcXVldHRlLgoKWW91IG1pZ2h0IGZpbmQgaXQgdXNlZnVsIHRvIHJlYWQKaHR0cDovL3dpa2ku
eGVuLm9yZy93aWtpL0Fza2luZ19YZW5fRGV2ZWxfUXVlc3Rpb25zCgo+IEluIG15IG9waW5pb24s
IEkgdGhpbmsgd2hlbiB3ZSBzaHV0ZG93biB0aGUgR3Vlc3RPUywKPiAgWGVuIHNob3VsZCBmcmVl
IGFsbG9jYXRlZCB2Y3B1IGFuZCBkb21haW4gZ2l2ZWQgdG8gR3Vlc3RPUyAKPiB3aGVuIGl0IGNy
ZWF0ZWQgYXQgdGhlIHNhbWUgdGltZS4gCgpzaHV0ZG93biBpcyBhIGd1ZXN0IGRyaXZlbiBvcGVy
YXRpb24gd2hpbGUgZGVzdHJveSBpcyB0b29sc3RhY2sgZHJpdmVuLgoKVGhlIGZsb3cgaXMgdGhh
dCB0aGUgZ3Vlc3Qgc2h1dHMgaXRzZWxmIGRvd24gKGVpdGhlciBieSB1c2luZyBQVgppbnRlcmZh
Y2VzLCBTQ0hFRE9QX3NodXRkb3duIG9yIGVtdWxhdGVkIG1lYW5zIHN1Y2ggYXMgaGFsdGluZyBh
bGwKcHJvY2Vzc29ycyB3aXRoIGludGVycnVwdHMgZGlzYWJsZWQgb3IgdmlhIEFDUEkgZXRjKS4g
VGhpcyB0aGVuIGNhdXNlcyBhCnNpZ25hbCB0byB0aGUgdG9vbHN0YWNrIHdoaWNoIHdpbGwgdGhl
biBpbml0aWF0ZSB0aGUgZGVzdHJveSwgd2hpY2gKY2F1c2VzIHRoZSBoeXBlcnZpc29yIHRvIGZp
bmFsbHkgdGVhcmRvd24gYWxsIHRoZSByZXNvdXJjZXMuCgpUaGUgc2lnbmFsIHRvIHRoZSB0b29s
c3RhY2sgaXMgVklSUV9ET01fRVhDIHdoaWNoIGlzIHJlY2VpdmVkIGJ5IHRoZQp4ZW5zdG9yZSBk
YWVtb24gd2hpY2ggdGhlbiByYWlzZXMgYSB3YXRjaCBjYWxsZWQgQHJlbGVhc2VEb21haW4uIFRo
ZQp0b29sc3RhY2sgaXMgd2F0Y2hpbmcgZm9yIHRoaXMgYW5kIHdpbGwgaW5pdGlhdGUgdGhlIGZp
bmFsIHRlYXJkb3duIG9mCnRoZSBkb21haW4gKG9yIHJlYm9vdCBpdCwgb3IgdGFrZSBhIGNyYXNo
IGR1bXAgb2YgaXRzIG1lbW9yeSwgb3Igc3VzcGVuZAppdCwgZXRjLCBhcyBhcHByb3ByaWF0ZSku
CgpJYW4uCgo+IAo+IEJ1dCBJIGRvbuKAmXQgZmluZCBhbnkgY29kZSBpbiBmdW5jdGlvbnMgYXNz
b2NpYXRlZCB3aXRoIHNodXRkb3duIHByb2Nlc3MgdG8KPiBzaG93IHRoaXMgd29yaywKPiBmb3Ig
ZXhhbXBsZTogCj4gSHZtX3ZjcHVfZG93bigpLeOAiWRvbWFpbl9zaHV0ZG93bigpLT5fX2RvbWFp
bl9maW5hbGlzZV9zaHV0ZG93bigpCj4gCj4gQnV0IEkgZmluZCB0aGUgZnVuY3Rpb25zIGZyZWVf
dmNwdV9zdHJ1Y3QoKSBhbmQgZnJlZV9kb21haW5fc3RydWN0KCkgCj4gaW4gdGhlIGZ1bmN0aW9u
IGNvbXBsZXRlX2RvbWFpbl9kZXN0cm95KCkgaW4gdGhlIHByb2Nlc3Mgb2YgZGVzdHJveQo+IG9w
ZXJhdGlvbiwgCj4gdGhlIGNvZGUgcHJvY2VzcyBpczoKPiBEb21haW5fa2lsbCgpLT5wdXRfZG9t
YWluKCktPmRvbWFpbl9kZXN0cm95KCktPmNvbXBsZXRlX2RvbWFpbl9kZXN0cm95KCkKPiAKPiBJ
cyB0aGF0IHByb2Nlc3MgcmlnaHQ/IElzIHRoZXJlIGFueSByZWxhdGlvbnNoaXAgYmV0d2VlbiB0
aGVtPwo+IERvZXMgYW55b25lIGtub3cgaXQ/Cj4gCj4gVGhhbmtzIGZvciB5b3VyIGhlbHAhCj4g
Cj4gCj4gCj4gLS0KPiBWaWV3IHRoaXMgbWVzc2FnZSBpbiBjb250ZXh0OiBodHRwOi8veGVuLjEw
NDU3MTIubjUubmFiYmxlLmNvbS9SZWxhdGlvbnNoaXAtYmV0d2Vlbi1HdWVzdE9TLXNodXRkb3du
LWFuZC1kZXN0cm95LW9wZXJhdGlvbnMtdHA1NzExNDIzLmh0bWwKPiBTZW50IGZyb20gdGhlIFhl
biAtIERldiBtYWlsaW5nIGxpc3QgYXJjaGl2ZSBhdCBOYWJibGUuY29tLgo+IAo+IF9fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCj4gWGVuLWRldmVsIG1haWxp
bmcgbGlzdAo+IFhlbi1kZXZlbEBsaXN0cy54ZW4ub3JnCj4gaHR0cDovL2xpc3RzLnhlbi5vcmcv
eGVuLWRldmVsCgoKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbi5vcmcKaHR0cDov
L2xpc3RzLnhlbi5vcmcveGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Fri Sep 21 08:09:33 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Sep 2012 08: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 1TEyIX-00070z-Lj; Fri, 21 Sep 2012 08:09: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 1TEyIV-00070m-RE
	for xen-devel@lists.xensource.com; Fri, 21 Sep 2012 08:09:16 +0000
Received: from [85.158.143.35:10706] by server-2.bemta-4.messagelabs.com id
	5A/D2-06610-BA02C505; Fri, 21 Sep 2012 08:09:15 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1348214953!15761740!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTA1OTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5181 invoked from network); 21 Sep 2012 08:09:14 -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 Sep 2012 08:09:14 -0000
X-IronPort-AV: E=Sophos;i="4.80,460,1344211200"; d="scan'208";a="14682042"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Sep 2012 08:08:02 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Fri, 21 Sep 2012 09:08:01 +0100
Message-ID: <1348214879.26501.68.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Bruce Granger <vivagin@yeah.net>
Date: Fri, 21 Sep 2012 09:07:59 +0100
In-Reply-To: <1348202102238-5711423.post@n5.nabble.com>
References: <1348202102238-5711423.post@n5.nabble.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Relationship between GuestOS shutdown and destroy
 operations?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gRnJpLCAyMDEyLTA5LTIxIGF0IDA1OjM1ICswMTAwLCBCcnVjZSBHcmFuZ2VyIHdyb3RlOgo+
IEhlbGxvIGV2ZXJ5b25lIQoKSGVsbG8uCgpQbGVhc2UgZG9uJ3Qgc3BhbSB0aGUgbGlzdCBieSBy
ZXNlbmRpbmcgZWZmZWN0aXZlbHkgdGhlIHNhbWUgcXVlc3Rpb24gMwp0aW1lcyBpbiBsZXNzIHRo
YW4gMS41IGhvdXJzLiBUaGUgeGVuLWRldmVsIGxpc3QgbWVtYmVyc2hpcCBpcyBzcHJlYWQKb3Zl
ciBtdWx0aXBsZSB0aW1lIHpvbmVzLCBzbyBwbGVhc2UgbGVhdmUgZW5vdWdoIHRpbWUgZm9yIHBl
b3BsZSB0bwphY3R1YWxseSByZWNlaXZlIGFuZCBkaWdlc3QgeW91ciBtYWlscy4gQWxzbyBiZSBy
ZW1lbWJlciB0aGF0IHlvdSBhc2tpbmcKcGVvcGxlIHRvIHRha2UgdGltZSBvdXQgZnJvbSB3aGF0
ZXZlciB0aGV5IGFyZSBkb2luZyB0byByZXBseSB0byB5b3UgYW5kCnRoZXkgbWF5IG5vdCBkbyBz
byBzdHJhaWdodCBhd2F5LgoKQWxzbyBwbGVhc2Uga2VlcCB0aGluZ3MgaW4gdGhlIHNhbWUgdGhy
ZWFkICh5b3UgaGF2ZSBzdGFydGVkIHRocmVlCnNlcGFyYXRlIHRocmVhZHMgdG9kYXkpIGFuZCBy
ZW1lbWJlciBxdW90ZSBmcm9tIHByZXZpb3VzIG1haWxzIHdoZXJlCmFwcHJvcHJpYXRlLgoKSSBy
ZWNvbW1lbmQgc3Vic2NyaWJpbmcgdGhlIGxpc3QgZGlyZWN0bHkgcmF0aGVyIHRoYW4gdXNpbmcg
bmFiYmxlIHNpbmNlCnRoYXQgc2VydmljZSB0ZW5kcyB0byBlbmNvdXJhZ2UgcXVpdGUgcG9vciBu
ZXRpcXVldHRlLgoKWW91IG1pZ2h0IGZpbmQgaXQgdXNlZnVsIHRvIHJlYWQKaHR0cDovL3dpa2ku
eGVuLm9yZy93aWtpL0Fza2luZ19YZW5fRGV2ZWxfUXVlc3Rpb25zCgo+IEluIG15IG9waW5pb24s
IEkgdGhpbmsgd2hlbiB3ZSBzaHV0ZG93biB0aGUgR3Vlc3RPUywKPiAgWGVuIHNob3VsZCBmcmVl
IGFsbG9jYXRlZCB2Y3B1IGFuZCBkb21haW4gZ2l2ZWQgdG8gR3Vlc3RPUyAKPiB3aGVuIGl0IGNy
ZWF0ZWQgYXQgdGhlIHNhbWUgdGltZS4gCgpzaHV0ZG93biBpcyBhIGd1ZXN0IGRyaXZlbiBvcGVy
YXRpb24gd2hpbGUgZGVzdHJveSBpcyB0b29sc3RhY2sgZHJpdmVuLgoKVGhlIGZsb3cgaXMgdGhh
dCB0aGUgZ3Vlc3Qgc2h1dHMgaXRzZWxmIGRvd24gKGVpdGhlciBieSB1c2luZyBQVgppbnRlcmZh
Y2VzLCBTQ0hFRE9QX3NodXRkb3duIG9yIGVtdWxhdGVkIG1lYW5zIHN1Y2ggYXMgaGFsdGluZyBh
bGwKcHJvY2Vzc29ycyB3aXRoIGludGVycnVwdHMgZGlzYWJsZWQgb3IgdmlhIEFDUEkgZXRjKS4g
VGhpcyB0aGVuIGNhdXNlcyBhCnNpZ25hbCB0byB0aGUgdG9vbHN0YWNrIHdoaWNoIHdpbGwgdGhl
biBpbml0aWF0ZSB0aGUgZGVzdHJveSwgd2hpY2gKY2F1c2VzIHRoZSBoeXBlcnZpc29yIHRvIGZp
bmFsbHkgdGVhcmRvd24gYWxsIHRoZSByZXNvdXJjZXMuCgpUaGUgc2lnbmFsIHRvIHRoZSB0b29s
c3RhY2sgaXMgVklSUV9ET01fRVhDIHdoaWNoIGlzIHJlY2VpdmVkIGJ5IHRoZQp4ZW5zdG9yZSBk
YWVtb24gd2hpY2ggdGhlbiByYWlzZXMgYSB3YXRjaCBjYWxsZWQgQHJlbGVhc2VEb21haW4uIFRo
ZQp0b29sc3RhY2sgaXMgd2F0Y2hpbmcgZm9yIHRoaXMgYW5kIHdpbGwgaW5pdGlhdGUgdGhlIGZp
bmFsIHRlYXJkb3duIG9mCnRoZSBkb21haW4gKG9yIHJlYm9vdCBpdCwgb3IgdGFrZSBhIGNyYXNo
IGR1bXAgb2YgaXRzIG1lbW9yeSwgb3Igc3VzcGVuZAppdCwgZXRjLCBhcyBhcHByb3ByaWF0ZSku
CgpJYW4uCgo+IAo+IEJ1dCBJIGRvbuKAmXQgZmluZCBhbnkgY29kZSBpbiBmdW5jdGlvbnMgYXNz
b2NpYXRlZCB3aXRoIHNodXRkb3duIHByb2Nlc3MgdG8KPiBzaG93IHRoaXMgd29yaywKPiBmb3Ig
ZXhhbXBsZTogCj4gSHZtX3ZjcHVfZG93bigpLeOAiWRvbWFpbl9zaHV0ZG93bigpLT5fX2RvbWFp
bl9maW5hbGlzZV9zaHV0ZG93bigpCj4gCj4gQnV0IEkgZmluZCB0aGUgZnVuY3Rpb25zIGZyZWVf
dmNwdV9zdHJ1Y3QoKSBhbmQgZnJlZV9kb21haW5fc3RydWN0KCkgCj4gaW4gdGhlIGZ1bmN0aW9u
IGNvbXBsZXRlX2RvbWFpbl9kZXN0cm95KCkgaW4gdGhlIHByb2Nlc3Mgb2YgZGVzdHJveQo+IG9w
ZXJhdGlvbiwgCj4gdGhlIGNvZGUgcHJvY2VzcyBpczoKPiBEb21haW5fa2lsbCgpLT5wdXRfZG9t
YWluKCktPmRvbWFpbl9kZXN0cm95KCktPmNvbXBsZXRlX2RvbWFpbl9kZXN0cm95KCkKPiAKPiBJ
cyB0aGF0IHByb2Nlc3MgcmlnaHQ/IElzIHRoZXJlIGFueSByZWxhdGlvbnNoaXAgYmV0d2VlbiB0
aGVtPwo+IERvZXMgYW55b25lIGtub3cgaXQ/Cj4gCj4gVGhhbmtzIGZvciB5b3VyIGhlbHAhCj4g
Cj4gCj4gCj4gLS0KPiBWaWV3IHRoaXMgbWVzc2FnZSBpbiBjb250ZXh0OiBodHRwOi8veGVuLjEw
NDU3MTIubjUubmFiYmxlLmNvbS9SZWxhdGlvbnNoaXAtYmV0d2Vlbi1HdWVzdE9TLXNodXRkb3du
LWFuZC1kZXN0cm95LW9wZXJhdGlvbnMtdHA1NzExNDIzLmh0bWwKPiBTZW50IGZyb20gdGhlIFhl
biAtIERldiBtYWlsaW5nIGxpc3QgYXJjaGl2ZSBhdCBOYWJibGUuY29tLgo+IAo+IF9fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCj4gWGVuLWRldmVsIG1haWxp
bmcgbGlzdAo+IFhlbi1kZXZlbEBsaXN0cy54ZW4ub3JnCj4gaHR0cDovL2xpc3RzLnhlbi5vcmcv
eGVuLWRldmVsCgoKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbi5vcmcKaHR0cDov
L2xpc3RzLnhlbi5vcmcveGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Fri Sep 21 08:11:07 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Sep 2012 08: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 1TEyK6-0007Bl-AT; Fri, 21 Sep 2012 08: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.Campbell@citrix.com>) id 1TEyK4-0007BZ-Jr
	for xen-devel@lists.xen.org; Fri, 21 Sep 2012 08:10:52 +0000
Received: from [85.158.137.99:63750] by server-1.bemta-3.messagelabs.com id
	D5/BF-05884-B012C505; Fri, 21 Sep 2012 08:10:51 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-217.messagelabs.com!1348215045!16202830!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTA1OTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24622 invoked from network); 21 Sep 2012 08:10:46 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Sep 2012 08:10:46 -0000
X-IronPort-AV: E=Sophos;i="4.80,460,1344211200"; d="scan'208";a="14682109"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Sep 2012 08:10: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.279.1;
	Fri, 21 Sep 2012 09:10:45 +0100
Message-ID: <1348215044.26501.70.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Fri, 21 Sep 2012 09:10:44 +0100
In-Reply-To: <20120920212407.GD27312@konrad-lan.dumpdata.com>
References: <1348051887-21885-1-git-send-email-oliver.chick@citrix.com>
	<505AF126.2050806@citrix.com>
	<1348140637.24539.32.camel@oliverchick-Precision-WorkStation-T3400>
	<505B1EB9020000780009CA6E@nat28.tlf.novell.com>
	<20120920134951.GC1998@localhost.localdomain>
	<1348150422.24539.58.camel@oliverchick-Precision-WorkStation-T3400>
	<20120920212407.GD27312@konrad-lan.dumpdata.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "Oliver Chick \(Intern\)" <oliver.chick@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Jan Beulich <JBeulich@suse.com>, David Vrabel <david.vrabel@citrix.com>
Subject: Re: [Xen-devel] [PATCH] Persistent grant maps for xen blk drivers
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-09-20 at 22:24 +0100, Konrad Rzeszutek Wilk wrote:
> On Thu, Sep 20, 2012 at 03:13:42PM +0100, Oliver Chick wrote:
> > On Thu, 2012-09-20 at 14:49 +0100, Konrad Rzeszutek Wilk wrote:
> > > On Thu, Sep 20, 2012 at 12:48:41PM +0100, Jan Beulich wrote:
> > > > >>> On 20.09.12 at 13:30, Oliver Chick <oliver.chick@citrix.com> wrote:
> > > > > The memory overhead, and fallback mode points are related:
> > > > > -Firstly, it turns out that the overhead is actually 2.75MB, not 11MB
> > > > > per device. I made a mistake (pointed out by Jan) as the maximum number
> > > > > of requests that can fit into a single-page ring is 64, not 256.
> > > > > -Clearly, this still scales linearly. So the problem of memory footprint
> > > > > will occur with more VMs, or block devices.
> > > > > -Whilst 2.75MB per device is probably acceptable (?), if we start using
> > > > > multipage rings, then we might not want to have
> > > > > BLKIF_MAX_PERS_REQUESTS_PER_DEVICE==__RING_SIZE, as this will cause the
> > > > > memory overhead to increase. This is why I have implemented the
> > > > > 'fallback' mode. With a multipage ring, it seems reasonable to want the
> > > > > first $x$ grefs seen by blkback to be treated as persistent, and any
> > > > > later ones to be non-persistent. Does that seem sensible?
> > > > 
> > > > From a resource usage pov, perhaps. But this will get the guest
> > > > entirely unpredictable performance. Plus I don't think 11Mb of
> > > 
> > > Wouldn't it fall back to the older performance?
> > 
> > I guess it would be a bit more complex than that. It would be worse than
> > the new performance because the grefs that get processed by the
> > 'fallback' mode will cause TLB shootdowns. But any early grefs will
> > still be processed by the persistent mode, so won't have shootdowns.
> > Therefore, depending on the ratio of {persistent grants}:{non-persistent
> > grants), allocated by blkfront, the performance will be somewhere
> > inbetween the two extremes.
> > 
> > I guess that the choice is between
> > 1) Compiling blk{front,back} with a pre-determined number of persistent
> > grants, and failing if this limit is exceeded. This seems rather
> > unflexible, as blk{front,back} must then both both use the same version,
> > or you will get failures.
> > 2 (current setup)) Have a recommended maximum number of
> > persistently-mapped pages, and going into a 'fallback' mode if blkfront
> > exceeds this limit.
> > 3) Having blkback inform blkfront on startup as to how many grefs it is
> > willing to persistently-map. We then hit the same question again though:
> > what should be do if blkfront ignores this limit?
> 
> How about 2 and 3 together?

I think 1 is fine for a "phase 1" implementation, especially taking into
consideration that the end of Oliver's internship is next week.

Also it seems that the cases where there might be some disconnect
between the number of persistent grants supported by the backend and the
number of requests from the frontend are currently theoretical or
predicated on the existence of unmerged or as yet unwritten patches.

So lets say, for now, that the default number of persistent grants is
the same as the number of slots in the ring and that it is a bug for
netfront to try and use more than that if it has signed up to the use of
persistent grants. netback is at liberty to fail such "overflow"
requests. In practice this can't happen with the current implementations
given the default specified above.

If someone wants to implement something like 2 or 3 in the future then
they can do so by negotiating through a xenstore key for a non-default
number of pgrants.

I think that if/when the number of persistent grants can differ from the
number of ring slots that an LRU scheme would be best. i.e. if there are
N slots then when the N+1th unique grant comes in we discard the least
recently used N/M (M perhaps in {2,3,4}) of the persistently granted
pages. This way there is an incentive for the f.e. to try to reuse pages
as much as possible and we get good batching on the unmaps if not.

Ian.

>  Meaning have a recommended maximmum number.
> If we fall back due to memory pressure we can tell the guest that we
> are entering fall-back mode. The frontend can decide what it wants to do
> (throttle the amount of I/Os?) or just do a printk telling the user it
> dropped the speed from "Insane Hot!" down to "Turbo!"... 
> 
> Or maybe not. Perhaps just reporting it in the backend that we are
> hitting memory pressure and using the old-style-fallback mechanism
> so the system admin can take actions (and tell his users why suddenly
> their I/Os are so slow).
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Sep 21 08:11:07 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Sep 2012 08: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 1TEyK6-0007Bl-AT; Fri, 21 Sep 2012 08: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.Campbell@citrix.com>) id 1TEyK4-0007BZ-Jr
	for xen-devel@lists.xen.org; Fri, 21 Sep 2012 08:10:52 +0000
Received: from [85.158.137.99:63750] by server-1.bemta-3.messagelabs.com id
	D5/BF-05884-B012C505; Fri, 21 Sep 2012 08:10:51 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-217.messagelabs.com!1348215045!16202830!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTA1OTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24622 invoked from network); 21 Sep 2012 08:10:46 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Sep 2012 08:10:46 -0000
X-IronPort-AV: E=Sophos;i="4.80,460,1344211200"; d="scan'208";a="14682109"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Sep 2012 08:10: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.279.1;
	Fri, 21 Sep 2012 09:10:45 +0100
Message-ID: <1348215044.26501.70.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Fri, 21 Sep 2012 09:10:44 +0100
In-Reply-To: <20120920212407.GD27312@konrad-lan.dumpdata.com>
References: <1348051887-21885-1-git-send-email-oliver.chick@citrix.com>
	<505AF126.2050806@citrix.com>
	<1348140637.24539.32.camel@oliverchick-Precision-WorkStation-T3400>
	<505B1EB9020000780009CA6E@nat28.tlf.novell.com>
	<20120920134951.GC1998@localhost.localdomain>
	<1348150422.24539.58.camel@oliverchick-Precision-WorkStation-T3400>
	<20120920212407.GD27312@konrad-lan.dumpdata.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "Oliver Chick \(Intern\)" <oliver.chick@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Jan Beulich <JBeulich@suse.com>, David Vrabel <david.vrabel@citrix.com>
Subject: Re: [Xen-devel] [PATCH] Persistent grant maps for xen blk drivers
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-09-20 at 22:24 +0100, Konrad Rzeszutek Wilk wrote:
> On Thu, Sep 20, 2012 at 03:13:42PM +0100, Oliver Chick wrote:
> > On Thu, 2012-09-20 at 14:49 +0100, Konrad Rzeszutek Wilk wrote:
> > > On Thu, Sep 20, 2012 at 12:48:41PM +0100, Jan Beulich wrote:
> > > > >>> On 20.09.12 at 13:30, Oliver Chick <oliver.chick@citrix.com> wrote:
> > > > > The memory overhead, and fallback mode points are related:
> > > > > -Firstly, it turns out that the overhead is actually 2.75MB, not 11MB
> > > > > per device. I made a mistake (pointed out by Jan) as the maximum number
> > > > > of requests that can fit into a single-page ring is 64, not 256.
> > > > > -Clearly, this still scales linearly. So the problem of memory footprint
> > > > > will occur with more VMs, or block devices.
> > > > > -Whilst 2.75MB per device is probably acceptable (?), if we start using
> > > > > multipage rings, then we might not want to have
> > > > > BLKIF_MAX_PERS_REQUESTS_PER_DEVICE==__RING_SIZE, as this will cause the
> > > > > memory overhead to increase. This is why I have implemented the
> > > > > 'fallback' mode. With a multipage ring, it seems reasonable to want the
> > > > > first $x$ grefs seen by blkback to be treated as persistent, and any
> > > > > later ones to be non-persistent. Does that seem sensible?
> > > > 
> > > > From a resource usage pov, perhaps. But this will get the guest
> > > > entirely unpredictable performance. Plus I don't think 11Mb of
> > > 
> > > Wouldn't it fall back to the older performance?
> > 
> > I guess it would be a bit more complex than that. It would be worse than
> > the new performance because the grefs that get processed by the
> > 'fallback' mode will cause TLB shootdowns. But any early grefs will
> > still be processed by the persistent mode, so won't have shootdowns.
> > Therefore, depending on the ratio of {persistent grants}:{non-persistent
> > grants), allocated by blkfront, the performance will be somewhere
> > inbetween the two extremes.
> > 
> > I guess that the choice is between
> > 1) Compiling blk{front,back} with a pre-determined number of persistent
> > grants, and failing if this limit is exceeded. This seems rather
> > unflexible, as blk{front,back} must then both both use the same version,
> > or you will get failures.
> > 2 (current setup)) Have a recommended maximum number of
> > persistently-mapped pages, and going into a 'fallback' mode if blkfront
> > exceeds this limit.
> > 3) Having blkback inform blkfront on startup as to how many grefs it is
> > willing to persistently-map. We then hit the same question again though:
> > what should be do if blkfront ignores this limit?
> 
> How about 2 and 3 together?

I think 1 is fine for a "phase 1" implementation, especially taking into
consideration that the end of Oliver's internship is next week.

Also it seems that the cases where there might be some disconnect
between the number of persistent grants supported by the backend and the
number of requests from the frontend are currently theoretical or
predicated on the existence of unmerged or as yet unwritten patches.

So lets say, for now, that the default number of persistent grants is
the same as the number of slots in the ring and that it is a bug for
netfront to try and use more than that if it has signed up to the use of
persistent grants. netback is at liberty to fail such "overflow"
requests. In practice this can't happen with the current implementations
given the default specified above.

If someone wants to implement something like 2 or 3 in the future then
they can do so by negotiating through a xenstore key for a non-default
number of pgrants.

I think that if/when the number of persistent grants can differ from the
number of ring slots that an LRU scheme would be best. i.e. if there are
N slots then when the N+1th unique grant comes in we discard the least
recently used N/M (M perhaps in {2,3,4}) of the persistently granted
pages. This way there is an incentive for the f.e. to try to reuse pages
as much as possible and we get good batching on the unmaps if not.

Ian.

>  Meaning have a recommended maximmum number.
> If we fall back due to memory pressure we can tell the guest that we
> are entering fall-back mode. The frontend can decide what it wants to do
> (throttle the amount of I/Os?) or just do a printk telling the user it
> dropped the speed from "Insane Hot!" down to "Turbo!"... 
> 
> Or maybe not. Perhaps just reporting it in the backend that we are
> hitting memory pressure and using the old-style-fallback mechanism
> so the system admin can take actions (and tell his users why suddenly
> their I/Os are so slow).
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Sep 21 08:42:38 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Sep 2012 08:42:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TEyoW-0007yA-PQ; Fri, 21 Sep 2012 08:42:20 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <oliver.chick@citrix.com>) id 1TEyoV-0007y5-9G
	for xen-devel@lists.xen.org; Fri, 21 Sep 2012 08:42:19 +0000
Received: from [85.158.137.99:23898] by server-13.bemta-3.messagelabs.com id
	C8/15-01606-A682C505; Fri, 21 Sep 2012 08:42:18 +0000
X-Env-Sender: oliver.chick@citrix.com
X-Msg-Ref: server-4.tower-217.messagelabs.com!1348216937!18579799!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTA2NjI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20671 invoked from network); 21 Sep 2012 08:42:18 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Sep 2012 08:42:18 -0000
X-IronPort-AV: E=Sophos;i="4.80,460,1344211200"; d="scan'208";a="14682919"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Sep 2012 08:42:17 +0000
Received: from [10.80.2.50] (10.80.2.50) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Fri, 21 Sep 2012 09:42:17 +0100
Message-ID: <1348216908.3689.3.camel@oliverchick-Precision-WorkStation-T3400>
From: Oliver Chick <oliver.chick@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Fri, 21 Sep 2012 09:41:48 +0100
In-Reply-To: <505C30CC020000780009CDD6@nat28.tlf.novell.com>
References: <1348051887-21885-1-git-send-email-oliver.chick@citrix.com>
	<505AF126.2050806@citrix.com>
	<1348140637.24539.32.camel@oliverchick-Precision-WorkStation-T3400>
	<505B1EB9020000780009CA6E@nat28.tlf.novell.com>
	<20120920134951.GC1998@localhost.localdomain>
	<1348150422.24539.58.camel@oliverchick-Precision-WorkStation-T3400>
	<20120920212407.GD27312@konrad-lan.dumpdata.com>
	<505C30CC020000780009CDD6@nat28.tlf.novell.com>
X-Mailer: Evolution 3.2.3-0ubuntu6 
MIME-Version: 1.0
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	David Vrabel <david.vrabel@citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH] Persistent grant maps for xen blk drivers
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-09-21 at 08:18 +0100, Jan Beulich wrote:
> >>> On 20.09.12 at 23:24, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
> > On Thu, Sep 20, 2012 at 03:13:42PM +0100, Oliver Chick wrote:
> >> On Thu, 2012-09-20 at 14:49 +0100, Konrad Rzeszutek Wilk wrote:
> >> > On Thu, Sep 20, 2012 at 12:48:41PM +0100, Jan Beulich wrote:
> >> > > >>> On 20.09.12 at 13:30, Oliver Chick <oliver.chick@citrix.com> wrote:
> >> > > > The memory overhead, and fallback mode points are related:
> >> > > > -Firstly, it turns out that the overhead is actually 2.75MB, not 11MB
> >> > > > per device. I made a mistake (pointed out by Jan) as the maximum number
> >> > > > of requests that can fit into a single-page ring is 64, not 256.
> >> > > > -Clearly, this still scales linearly. So the problem of memory footprint
> >> > > > will occur with more VMs, or block devices.
> >> > > > -Whilst 2.75MB per device is probably acceptable (?), if we start using
> >> > > > multipage rings, then we might not want to have
> >> > > > BLKIF_MAX_PERS_REQUESTS_PER_DEVICE==__RING_SIZE, as this will cause the
> >> > > > memory overhead to increase. This is why I have implemented the
> >> > > > 'fallback' mode. With a multipage ring, it seems reasonable to want the
> >> > > > first $x$ grefs seen by blkback to be treated as persistent, and any
> >> > > > later ones to be non-persistent. Does that seem sensible?
> >> > > 
> >> > > From a resource usage pov, perhaps. But this will get the guest
> >> > > entirely unpredictable performance. Plus I don't think 11Mb of
> >> > 
> >> > Wouldn't it fall back to the older performance?
> >> 
> >> I guess it would be a bit more complex than that. It would be worse than
> >> the new performance because the grefs that get processed by the
> >> 'fallback' mode will cause TLB shootdowns. But any early grefs will
> >> still be processed by the persistent mode, so won't have shootdowns.
> >> Therefore, depending on the ratio of {persistent grants}:{non-persistent
> >> grants), allocated by blkfront, the performance will be somewhere
> >> inbetween the two extremes.
> >> 
> >> I guess that the choice is between
> >> 1) Compiling blk{front,back} with a pre-determined number of persistent
> >> grants, and failing if this limit is exceeded. This seems rather
> >> unflexible, as blk{front,back} must then both both use the same version,
> >> or you will get failures.
> >> 2 (current setup)) Have a recommended maximum number of
> >> persistently-mapped pages, and going into a 'fallback' mode if blkfront
> >> exceeds this limit.
> >> 3) Having blkback inform blkfront on startup as to how many grefs it is
> >> willing to persistently-map. We then hit the same question again though:
> >> what should be do if blkfront ignores this limit?
> > 
> > How about 2 and 3 together? Meaning have a recommended maximmum number.
> > If we fall back due to memory pressure we can tell the guest that we
> > are entering fall-back mode. The frontend can decide what it wants to do
> > (throttle the amount of I/Os?) or just do a printk telling the user it
> > dropped the speed from "Insane Hot!" down to "Turbo!"... 
> > 
> > Or maybe not. Perhaps just reporting it in the backend that we are
> > hitting memory pressure and using the old-style-fallback mechanism
> > so the system admin can take actions (and tell his users why suddenly
> > their I/Os are so slow).
> 
> So would either of you help me understand what memory pressure
> we're in need of dealing with here. So far, talk was only about
> virtual address space that's needed for mapping in the grants, and
> even then I don't see how this space requirement varies between
> persistent and non-persistent grants - it's being reserved during
> backend initialization anyway.
> 
> Jan
> 

IIRC, the pending_pages[] used by blkback is a static array of 256
pages, allocated during initialisation. Therefore, the memory mapped
does not increase with the number of block devices being backed, for
non-persistent operation. Whereas, when we become persistent, we don't
unmap pages so can't reuse pages for different block devices, therefore
we have to alloc more pages for each device.

Does that answer your question, and make sense?


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 21 08:42:38 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Sep 2012 08:42:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TEyoW-0007yA-PQ; Fri, 21 Sep 2012 08:42:20 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <oliver.chick@citrix.com>) id 1TEyoV-0007y5-9G
	for xen-devel@lists.xen.org; Fri, 21 Sep 2012 08:42:19 +0000
Received: from [85.158.137.99:23898] by server-13.bemta-3.messagelabs.com id
	C8/15-01606-A682C505; Fri, 21 Sep 2012 08:42:18 +0000
X-Env-Sender: oliver.chick@citrix.com
X-Msg-Ref: server-4.tower-217.messagelabs.com!1348216937!18579799!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTA2NjI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20671 invoked from network); 21 Sep 2012 08:42:18 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Sep 2012 08:42:18 -0000
X-IronPort-AV: E=Sophos;i="4.80,460,1344211200"; d="scan'208";a="14682919"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Sep 2012 08:42:17 +0000
Received: from [10.80.2.50] (10.80.2.50) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Fri, 21 Sep 2012 09:42:17 +0100
Message-ID: <1348216908.3689.3.camel@oliverchick-Precision-WorkStation-T3400>
From: Oliver Chick <oliver.chick@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Fri, 21 Sep 2012 09:41:48 +0100
In-Reply-To: <505C30CC020000780009CDD6@nat28.tlf.novell.com>
References: <1348051887-21885-1-git-send-email-oliver.chick@citrix.com>
	<505AF126.2050806@citrix.com>
	<1348140637.24539.32.camel@oliverchick-Precision-WorkStation-T3400>
	<505B1EB9020000780009CA6E@nat28.tlf.novell.com>
	<20120920134951.GC1998@localhost.localdomain>
	<1348150422.24539.58.camel@oliverchick-Precision-WorkStation-T3400>
	<20120920212407.GD27312@konrad-lan.dumpdata.com>
	<505C30CC020000780009CDD6@nat28.tlf.novell.com>
X-Mailer: Evolution 3.2.3-0ubuntu6 
MIME-Version: 1.0
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	David Vrabel <david.vrabel@citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH] Persistent grant maps for xen blk drivers
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-09-21 at 08:18 +0100, Jan Beulich wrote:
> >>> On 20.09.12 at 23:24, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
> > On Thu, Sep 20, 2012 at 03:13:42PM +0100, Oliver Chick wrote:
> >> On Thu, 2012-09-20 at 14:49 +0100, Konrad Rzeszutek Wilk wrote:
> >> > On Thu, Sep 20, 2012 at 12:48:41PM +0100, Jan Beulich wrote:
> >> > > >>> On 20.09.12 at 13:30, Oliver Chick <oliver.chick@citrix.com> wrote:
> >> > > > The memory overhead, and fallback mode points are related:
> >> > > > -Firstly, it turns out that the overhead is actually 2.75MB, not 11MB
> >> > > > per device. I made a mistake (pointed out by Jan) as the maximum number
> >> > > > of requests that can fit into a single-page ring is 64, not 256.
> >> > > > -Clearly, this still scales linearly. So the problem of memory footprint
> >> > > > will occur with more VMs, or block devices.
> >> > > > -Whilst 2.75MB per device is probably acceptable (?), if we start using
> >> > > > multipage rings, then we might not want to have
> >> > > > BLKIF_MAX_PERS_REQUESTS_PER_DEVICE==__RING_SIZE, as this will cause the
> >> > > > memory overhead to increase. This is why I have implemented the
> >> > > > 'fallback' mode. With a multipage ring, it seems reasonable to want the
> >> > > > first $x$ grefs seen by blkback to be treated as persistent, and any
> >> > > > later ones to be non-persistent. Does that seem sensible?
> >> > > 
> >> > > From a resource usage pov, perhaps. But this will get the guest
> >> > > entirely unpredictable performance. Plus I don't think 11Mb of
> >> > 
> >> > Wouldn't it fall back to the older performance?
> >> 
> >> I guess it would be a bit more complex than that. It would be worse than
> >> the new performance because the grefs that get processed by the
> >> 'fallback' mode will cause TLB shootdowns. But any early grefs will
> >> still be processed by the persistent mode, so won't have shootdowns.
> >> Therefore, depending on the ratio of {persistent grants}:{non-persistent
> >> grants), allocated by blkfront, the performance will be somewhere
> >> inbetween the two extremes.
> >> 
> >> I guess that the choice is between
> >> 1) Compiling blk{front,back} with a pre-determined number of persistent
> >> grants, and failing if this limit is exceeded. This seems rather
> >> unflexible, as blk{front,back} must then both both use the same version,
> >> or you will get failures.
> >> 2 (current setup)) Have a recommended maximum number of
> >> persistently-mapped pages, and going into a 'fallback' mode if blkfront
> >> exceeds this limit.
> >> 3) Having blkback inform blkfront on startup as to how many grefs it is
> >> willing to persistently-map. We then hit the same question again though:
> >> what should be do if blkfront ignores this limit?
> > 
> > How about 2 and 3 together? Meaning have a recommended maximmum number.
> > If we fall back due to memory pressure we can tell the guest that we
> > are entering fall-back mode. The frontend can decide what it wants to do
> > (throttle the amount of I/Os?) or just do a printk telling the user it
> > dropped the speed from "Insane Hot!" down to "Turbo!"... 
> > 
> > Or maybe not. Perhaps just reporting it in the backend that we are
> > hitting memory pressure and using the old-style-fallback mechanism
> > so the system admin can take actions (and tell his users why suddenly
> > their I/Os are so slow).
> 
> So would either of you help me understand what memory pressure
> we're in need of dealing with here. So far, talk was only about
> virtual address space that's needed for mapping in the grants, and
> even then I don't see how this space requirement varies between
> persistent and non-persistent grants - it's being reserved during
> backend initialization anyway.
> 
> Jan
> 

IIRC, the pending_pages[] used by blkback is a static array of 256
pages, allocated during initialisation. Therefore, the memory mapped
does not increase with the number of block devices being backed, for
non-persistent operation. Whereas, when we become persistent, we don't
unmap pages so can't reuse pages for different block devices, therefore
we have to alloc more pages for each device.

Does that answer your question, and make sense?


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 21 08:49:06 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Sep 2012 08:49: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 1TEyul-00087E-M1; Fri, 21 Sep 2012 08:48: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 1TEyuj-000876-VD
	for xen-devel@lists.xen.org; Fri, 21 Sep 2012 08:48:46 +0000
Received: from [85.158.139.83:29673] by server-5.bemta-5.messagelabs.com id
	F3/4D-30514-DE92C505; Fri, 21 Sep 2012 08:48:45 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1348217324!27551165!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTA1OTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31102 invoked from network); 21 Sep 2012 08:48:44 -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 Sep 2012 08:48:44 -0000
X-IronPort-AV: E=Sophos;i="4.80,460,1344211200"; d="scan'208";a="14683093"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Sep 2012 08:48: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.279.1;
	Fri, 21 Sep 2012 09:48:44 +0100
Message-ID: <1348217322.3452.0.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jim Fehlig <jfehlig@suse.com>
Date: Fri, 21 Sep 2012 09:48:42 +0100
In-Reply-To: <505B88A1.1070701@suse.com>
References: <CAFLBxZYtmJ_bKFb90r45=C4Pq1-oe5Fy=eygSsQf4BcGj3EqGA@mail.gmail.com>
	<201209191918.35305.hahn@univention.de>
	<CAFLBxZZko72sMVPr9LEyea7E-tNx74qCvRoxqPZ-eWbvhvctgQ@mail.gmail.com>
	<201209201340.52218.hahn@univention.de> <505B88A1.1070701@suse.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Philipp Hahn <hahn@univention.de>
Subject: Re: [Xen-devel] Xen 4.3 development 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 Thu, 2012-09-20 at 22:20 +0100, Jim Fehlig wrote:
> But why is libvirt integration listed as a Xen 4.3 feature?  AFAIK, all of this 
> work is in libvirt and really doesn't have much to do with the release of 4.3.

I think it's useful to track activities undertaken by the community
during the 4.3 development timeframe even if it is on things which are
strictly speaking external and/or independent projects.

It makes a bit of sense if you also consider that we might want to
divert effort from stuff happening for Xen 4.3 "proper" to one of these
external projects, which makes it useful to be able to prioritise/track
them next to each other.

Lastly, in this specific case the availability of libvirt bindings ties
into the xend->xl transition, which makes it interesting as a Xen 4.3
thing, IYSWIM.

George, since Jim isn't the first to ask this question perhaps it would
be useful to include an "external" flag on these items and explain in
the legend why we are tracking 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 Sep 21 08:49:06 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Sep 2012 08:49: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 1TEyul-00087E-M1; Fri, 21 Sep 2012 08:48: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 1TEyuj-000876-VD
	for xen-devel@lists.xen.org; Fri, 21 Sep 2012 08:48:46 +0000
Received: from [85.158.139.83:29673] by server-5.bemta-5.messagelabs.com id
	F3/4D-30514-DE92C505; Fri, 21 Sep 2012 08:48:45 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1348217324!27551165!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTA1OTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31102 invoked from network); 21 Sep 2012 08:48:44 -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 Sep 2012 08:48:44 -0000
X-IronPort-AV: E=Sophos;i="4.80,460,1344211200"; d="scan'208";a="14683093"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Sep 2012 08:48: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.279.1;
	Fri, 21 Sep 2012 09:48:44 +0100
Message-ID: <1348217322.3452.0.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jim Fehlig <jfehlig@suse.com>
Date: Fri, 21 Sep 2012 09:48:42 +0100
In-Reply-To: <505B88A1.1070701@suse.com>
References: <CAFLBxZYtmJ_bKFb90r45=C4Pq1-oe5Fy=eygSsQf4BcGj3EqGA@mail.gmail.com>
	<201209191918.35305.hahn@univention.de>
	<CAFLBxZZko72sMVPr9LEyea7E-tNx74qCvRoxqPZ-eWbvhvctgQ@mail.gmail.com>
	<201209201340.52218.hahn@univention.de> <505B88A1.1070701@suse.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Philipp Hahn <hahn@univention.de>
Subject: Re: [Xen-devel] Xen 4.3 development 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 Thu, 2012-09-20 at 22:20 +0100, Jim Fehlig wrote:
> But why is libvirt integration listed as a Xen 4.3 feature?  AFAIK, all of this 
> work is in libvirt and really doesn't have much to do with the release of 4.3.

I think it's useful to track activities undertaken by the community
during the 4.3 development timeframe even if it is on things which are
strictly speaking external and/or independent projects.

It makes a bit of sense if you also consider that we might want to
divert effort from stuff happening for Xen 4.3 "proper" to one of these
external projects, which makes it useful to be able to prioritise/track
them next to each other.

Lastly, in this specific case the availability of libvirt bindings ties
into the xend->xl transition, which makes it interesting as a Xen 4.3
thing, IYSWIM.

George, since Jim isn't the first to ask this question perhaps it would
be useful to include an "external" flag on these items and explain in
the legend why we are tracking 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 Sep 21 09:05:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Sep 2012 09:05:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TEzAJ-0008PE-CQ; Fri, 21 Sep 2012 09:04:51 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <oliver.chick@citrix.com>) id 1TEzAI-0008P7-Ne
	for xen-devel@lists.xensource.com; Fri, 21 Sep 2012 09:04:50 +0000
Received: from [85.158.139.83:53347] by server-3.bemta-5.messagelabs.com id
	15/17-21836-1BD2C505; Fri, 21 Sep 2012 09:04:49 +0000
X-Env-Sender: oliver.chick@citrix.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1348218288!24169052!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzAwNTE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12268 invoked from network); 21 Sep 2012 09:04:49 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-16.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Sep 2012 09:04:49 -0000
X-IronPort-AV: E=Sophos;i="4.80,460,1344211200"; d="scan'208";a="38699921"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Sep 2012 09:04:47 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1;
	Fri, 21 Sep 2012 05:04:47 -0400
Received: from leeni.uk.xensource.com ([10.80.2.50]
	helo=oliverchick-Precision-WorkStation-T3400.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<oliver.chick@citrix.com>)	id 1TEzAE-0001fk-Uy;
	Fri, 21 Sep 2012 10:04:46 +0100
From: Oliver Chick <oliver.chick@citrix.com>
To: konrad.wilk@oracle.com, xen-devel@lists.xensource.com,
	linux-kernel@vger.kernel.org
Date: Fri, 21 Sep 2012 10:04:18 +0100
Message-ID: <1348218258-4418-1-git-send-email-oliver.chick@citrix.com>
X-Mailer: git-send-email 1.7.9.5
MIME-Version: 1.0
Cc: Oliver Chick <oliver.chick@citrix.com>
Subject: [Xen-devel] [PATCH] Change xen_vbd's flush_support and
	discard_secure to have type unsigned int, rather than bool
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Changing the type of bdev parameters to be unsigned int :1, rather than bool.
This is more consistent with the types of other features in the block drivers.

Signed-off-by: Oliver Chick <oliver.chick@citrix.com>
---
 drivers/block/xen-blkback/common.h |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/block/xen-blkback/common.h b/drivers/block/xen-blkback/common.h
index 9ad3b5e..9a54623 100644
--- a/drivers/block/xen-blkback/common.h
+++ b/drivers/block/xen-blkback/common.h
@@ -158,8 +158,8 @@ struct xen_vbd {
 	struct block_device	*bdev;
 	/* Cached size parameter. */
 	sector_t		size;
-	bool			flush_support;
-	bool			discard_secure;
+	unsigned int		flush_support:1;
+	unsigned int		discard_secure:1;
 };
 
 struct backend_info;
-- 
1.7.9.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 21 09:05:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Sep 2012 09:05:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TEzAJ-0008PE-CQ; Fri, 21 Sep 2012 09:04:51 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <oliver.chick@citrix.com>) id 1TEzAI-0008P7-Ne
	for xen-devel@lists.xensource.com; Fri, 21 Sep 2012 09:04:50 +0000
Received: from [85.158.139.83:53347] by server-3.bemta-5.messagelabs.com id
	15/17-21836-1BD2C505; Fri, 21 Sep 2012 09:04:49 +0000
X-Env-Sender: oliver.chick@citrix.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1348218288!24169052!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzAwNTE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12268 invoked from network); 21 Sep 2012 09:04:49 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-16.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Sep 2012 09:04:49 -0000
X-IronPort-AV: E=Sophos;i="4.80,460,1344211200"; d="scan'208";a="38699921"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Sep 2012 09:04:47 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1;
	Fri, 21 Sep 2012 05:04:47 -0400
Received: from leeni.uk.xensource.com ([10.80.2.50]
	helo=oliverchick-Precision-WorkStation-T3400.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<oliver.chick@citrix.com>)	id 1TEzAE-0001fk-Uy;
	Fri, 21 Sep 2012 10:04:46 +0100
From: Oliver Chick <oliver.chick@citrix.com>
To: konrad.wilk@oracle.com, xen-devel@lists.xensource.com,
	linux-kernel@vger.kernel.org
Date: Fri, 21 Sep 2012 10:04:18 +0100
Message-ID: <1348218258-4418-1-git-send-email-oliver.chick@citrix.com>
X-Mailer: git-send-email 1.7.9.5
MIME-Version: 1.0
Cc: Oliver Chick <oliver.chick@citrix.com>
Subject: [Xen-devel] [PATCH] Change xen_vbd's flush_support and
	discard_secure to have type unsigned int, rather than bool
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Changing the type of bdev parameters to be unsigned int :1, rather than bool.
This is more consistent with the types of other features in the block drivers.

Signed-off-by: Oliver Chick <oliver.chick@citrix.com>
---
 drivers/block/xen-blkback/common.h |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/block/xen-blkback/common.h b/drivers/block/xen-blkback/common.h
index 9ad3b5e..9a54623 100644
--- a/drivers/block/xen-blkback/common.h
+++ b/drivers/block/xen-blkback/common.h
@@ -158,8 +158,8 @@ struct xen_vbd {
 	struct block_device	*bdev;
 	/* Cached size parameter. */
 	sector_t		size;
-	bool			flush_support;
-	bool			discard_secure;
+	unsigned int		flush_support:1;
+	unsigned int		discard_secure:1;
 };
 
 struct backend_info;
-- 
1.7.9.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 21 09:40:54 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Sep 2012 09:40:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TEziq-0000EC-FM; Fri, 21 Sep 2012 09:40:32 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <zhenzhong.duan@oracle.com>) id 1TEzio-0000E7-Jx
	for xen-devel@lists.xen.org; Fri, 21 Sep 2012 09:40:30 +0000
Received: from [85.158.137.99:17190] by server-14.bemta-3.messagelabs.com id
	F4/EB-21431-D063C505; Fri, 21 Sep 2012 09:40:29 +0000
X-Env-Sender: zhenzhong.duan@oracle.com
X-Msg-Ref: server-10.tower-217.messagelabs.com!1348220427!18594858!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDc2NjM1OA==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4859 invoked from network); 21 Sep 2012 09:40:29 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-10.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 21 Sep 2012 09:40:29 -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 q8L9ePw3009989
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK)
	for <xen-devel@lists.xen.org>; Fri, 21 Sep 2012 09:40:26 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q8L9ePsw027605
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for <xen-devel@lists.xen.org>; Fri, 21 Sep 2012 09:40:25 GMT
Received: from abhmt120.oracle.com (abhmt120.oracle.com [141.146.116.72])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q8L9eOPR000643
	for <xen-devel@lists.xen.org>; Fri, 21 Sep 2012 04:40:24 -0500
Received: from [10.191.5.204] (/10.191.5.204)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 21 Sep 2012 02:40:24 -0700
Message-ID: <505C3647.1030003@oracle.com>
Date: Fri, 21 Sep 2012 17:41:27 +0800
From: Zhenzhong Duan <zhenzhong.duan@oracle.com>
Organization: oracle
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 <xen-devel@lists.xen.org>
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: Dan Magenheimer <dan.magenheimer@oracle.com>, Feng Jin <joe.jin@oracle.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: [Xen-devel] an issue with 'xm save'
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: zhenzhong.duan@oracle.com
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 maintainers,

I found there is an issue when 'xm save' a pvm guest. See below:

When I do save then restore once, CPU(%) in xentop showed around 99%.
When I do that second time, CPU(%) showed 199%

top in dom0 showed:
    PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
   20946 root      18  -2 10984 1284  964 S 19.8  0.3   0:48.93 block
   4939 root      18  -2 10984 1288  964 S 19.5  0.3   1:34.68 block

I could kill the block process, then all look normal again.

xen and xen-tools are both generated with xen-unstable.
I tried xl, but it segfault.
I also tried ovm3.1.1(xen-4.1.2-18.el5.1 and xen-tools-4.1.2-18.el5.1),
can't reproduce.

Did anybody see similar issue before? Any fix already there?
thanks
zduan



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 21 09:40:54 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Sep 2012 09:40:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TEziq-0000EC-FM; Fri, 21 Sep 2012 09:40:32 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <zhenzhong.duan@oracle.com>) id 1TEzio-0000E7-Jx
	for xen-devel@lists.xen.org; Fri, 21 Sep 2012 09:40:30 +0000
Received: from [85.158.137.99:17190] by server-14.bemta-3.messagelabs.com id
	F4/EB-21431-D063C505; Fri, 21 Sep 2012 09:40:29 +0000
X-Env-Sender: zhenzhong.duan@oracle.com
X-Msg-Ref: server-10.tower-217.messagelabs.com!1348220427!18594858!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDc2NjM1OA==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4859 invoked from network); 21 Sep 2012 09:40:29 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-10.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 21 Sep 2012 09:40:29 -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 q8L9ePw3009989
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK)
	for <xen-devel@lists.xen.org>; Fri, 21 Sep 2012 09:40:26 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q8L9ePsw027605
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for <xen-devel@lists.xen.org>; Fri, 21 Sep 2012 09:40:25 GMT
Received: from abhmt120.oracle.com (abhmt120.oracle.com [141.146.116.72])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q8L9eOPR000643
	for <xen-devel@lists.xen.org>; Fri, 21 Sep 2012 04:40:24 -0500
Received: from [10.191.5.204] (/10.191.5.204)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 21 Sep 2012 02:40:24 -0700
Message-ID: <505C3647.1030003@oracle.com>
Date: Fri, 21 Sep 2012 17:41:27 +0800
From: Zhenzhong Duan <zhenzhong.duan@oracle.com>
Organization: oracle
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 <xen-devel@lists.xen.org>
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: Dan Magenheimer <dan.magenheimer@oracle.com>, Feng Jin <joe.jin@oracle.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: [Xen-devel] an issue with 'xm save'
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: zhenzhong.duan@oracle.com
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 maintainers,

I found there is an issue when 'xm save' a pvm guest. See below:

When I do save then restore once, CPU(%) in xentop showed around 99%.
When I do that second time, CPU(%) showed 199%

top in dom0 showed:
    PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
   20946 root      18  -2 10984 1284  964 S 19.8  0.3   0:48.93 block
   4939 root      18  -2 10984 1288  964 S 19.5  0.3   1:34.68 block

I could kill the block process, then all look normal again.

xen and xen-tools are both generated with xen-unstable.
I tried xl, but it segfault.
I also tried ovm3.1.1(xen-4.1.2-18.el5.1 and xen-tools-4.1.2-18.el5.1),
can't reproduce.

Did anybody see similar issue before? Any fix already there?
thanks
zduan



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 21 09:41:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Sep 2012 09: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 1TEzji-0000HM-Ta; Fri, 21 Sep 2012 09:41:26 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1TEzjg-0000HD-Qx
	for xen-devel@lists.xen.org; Fri, 21 Sep 2012 09:41:25 +0000
Received: from [85.158.139.211:61015] by server-1.bemta-5.messagelabs.com id
	DF/7B-04809-4463C505; Fri, 21 Sep 2012 09:41:24 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-206.messagelabs.com!1348220482!19442310!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20428 invoked from network); 21 Sep 2012 09:41:23 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-11.tower-206.messagelabs.com with SMTP;
	21 Sep 2012 09:41:23 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 21 Sep 2012 10:41:22 +0100
Message-Id: <505C525E020000780009CE63@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 21 Sep 2012 10:41:18 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Oliver Chick" <oliver.chick@citrix.com>
References: <1348051887-21885-1-git-send-email-oliver.chick@citrix.com>
	<505AF126.2050806@citrix.com>
	<1348140637.24539.32.camel@oliverchick-Precision-WorkStation-T3400>
	<505B1EB9020000780009CA6E@nat28.tlf.novell.com>
	<20120920134951.GC1998@localhost.localdomain>
	<1348150422.24539.58.camel@oliverchick-Precision-WorkStation-T3400>
	<20120920212407.GD27312@konrad-lan.dumpdata.com>
	<505C30CC020000780009CDD6@nat28.tlf.novell.com>
	<1348216908.3689.3.camel@oliverchick-Precision-WorkStation-T3400>
In-Reply-To: <1348216908.3689.3.camel@oliverchick-Precision-WorkStation-T3400>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	David Vrabel <david.vrabel@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] Persistent grant maps for xen blk drivers
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 21.09.12 at 10:41, Oliver Chick <oliver.chick@citrix.com> wrote:
> On Fri, 2012-09-21 at 08:18 +0100, Jan Beulich wrote:
>> >>> On 20.09.12 at 23:24, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
>> > On Thu, Sep 20, 2012 at 03:13:42PM +0100, Oliver Chick wrote:
>> >> On Thu, 2012-09-20 at 14:49 +0100, Konrad Rzeszutek Wilk wrote:
>> >> > On Thu, Sep 20, 2012 at 12:48:41PM +0100, Jan Beulich wrote:
>> >> > > >>> On 20.09.12 at 13:30, Oliver Chick <oliver.chick@citrix.com> wrote:
>> >> > > > The memory overhead, and fallback mode points are related:
>> >> > > > -Firstly, it turns out that the overhead is actually 2.75MB, not 11MB
>> >> > > > per device. I made a mistake (pointed out by Jan) as the maximum number
>> >> > > > of requests that can fit into a single-page ring is 64, not 256.
>> >> > > > -Clearly, this still scales linearly. So the problem of memory footprint
>> >> > > > will occur with more VMs, or block devices.
>> >> > > > -Whilst 2.75MB per device is probably acceptable (?), if we start using
>> >> > > > multipage rings, then we might not want to have
>> >> > > > BLKIF_MAX_PERS_REQUESTS_PER_DEVICE==__RING_SIZE, as this will cause the
>> >> > > > memory overhead to increase. This is why I have implemented the
>> >> > > > 'fallback' mode. With a multipage ring, it seems reasonable to want the
>> >> > > > first $x$ grefs seen by blkback to be treated as persistent, and any
>> >> > > > later ones to be non-persistent. Does that seem sensible?
>> >> > > 
>> >> > > From a resource usage pov, perhaps. But this will get the guest
>> >> > > entirely unpredictable performance. Plus I don't think 11Mb of
>> >> > 
>> >> > Wouldn't it fall back to the older performance?
>> >> 
>> >> I guess it would be a bit more complex than that. It would be worse than
>> >> the new performance because the grefs that get processed by the
>> >> 'fallback' mode will cause TLB shootdowns. But any early grefs will
>> >> still be processed by the persistent mode, so won't have shootdowns.
>> >> Therefore, depending on the ratio of {persistent grants}:{non-persistent
>> >> grants), allocated by blkfront, the performance will be somewhere
>> >> inbetween the two extremes.
>> >> 
>> >> I guess that the choice is between
>> >> 1) Compiling blk{front,back} with a pre-determined number of persistent
>> >> grants, and failing if this limit is exceeded. This seems rather
>> >> unflexible, as blk{front,back} must then both both use the same version,
>> >> or you will get failures.
>> >> 2 (current setup)) Have a recommended maximum number of
>> >> persistently-mapped pages, and going into a 'fallback' mode if blkfront
>> >> exceeds this limit.
>> >> 3) Having blkback inform blkfront on startup as to how many grefs it is
>> >> willing to persistently-map. We then hit the same question again though:
>> >> what should be do if blkfront ignores this limit?
>> > 
>> > How about 2 and 3 together? Meaning have a recommended maximmum number.
>> > If we fall back due to memory pressure we can tell the guest that we
>> > are entering fall-back mode. The frontend can decide what it wants to do
>> > (throttle the amount of I/Os?) or just do a printk telling the user it
>> > dropped the speed from "Insane Hot!" down to "Turbo!"... 
>> > 
>> > Or maybe not. Perhaps just reporting it in the backend that we are
>> > hitting memory pressure and using the old-style-fallback mechanism
>> > so the system admin can take actions (and tell his users why suddenly
>> > their I/Os are so slow).
>> 
>> So would either of you help me understand what memory pressure
>> we're in need of dealing with here. So far, talk was only about
>> virtual address space that's needed for mapping in the grants, and
>> even then I don't see how this space requirement varies between
>> persistent and non-persistent grants - it's being reserved during
>> backend initialization anyway.
>> 
>> Jan
>> 
> 
> IIRC, the pending_pages[] used by blkback is a static array of 256
> pages, allocated during initialisation. Therefore, the memory mapped
> does not increase with the number of block devices being backed, for
> non-persistent operation. Whereas, when we become persistent, we don't
> unmap pages so can't reuse pages for different block devices, therefore
> we have to alloc more pages for each device.
> 
> Does that answer your question, and make sense?

This is an array of pointers to struct page, not an array of
pages. 11Mb worth of pages amounts to about 22k of memory
needed for this array. If we're _that_ short of memory, of
course some throttling or even failing of requests is desirable.

Jan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 21 09:41:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Sep 2012 09: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 1TEzji-0000HM-Ta; Fri, 21 Sep 2012 09:41:26 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1TEzjg-0000HD-Qx
	for xen-devel@lists.xen.org; Fri, 21 Sep 2012 09:41:25 +0000
Received: from [85.158.139.211:61015] by server-1.bemta-5.messagelabs.com id
	DF/7B-04809-4463C505; Fri, 21 Sep 2012 09:41:24 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-206.messagelabs.com!1348220482!19442310!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20428 invoked from network); 21 Sep 2012 09:41:23 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-11.tower-206.messagelabs.com with SMTP;
	21 Sep 2012 09:41:23 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 21 Sep 2012 10:41:22 +0100
Message-Id: <505C525E020000780009CE63@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 21 Sep 2012 10:41:18 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Oliver Chick" <oliver.chick@citrix.com>
References: <1348051887-21885-1-git-send-email-oliver.chick@citrix.com>
	<505AF126.2050806@citrix.com>
	<1348140637.24539.32.camel@oliverchick-Precision-WorkStation-T3400>
	<505B1EB9020000780009CA6E@nat28.tlf.novell.com>
	<20120920134951.GC1998@localhost.localdomain>
	<1348150422.24539.58.camel@oliverchick-Precision-WorkStation-T3400>
	<20120920212407.GD27312@konrad-lan.dumpdata.com>
	<505C30CC020000780009CDD6@nat28.tlf.novell.com>
	<1348216908.3689.3.camel@oliverchick-Precision-WorkStation-T3400>
In-Reply-To: <1348216908.3689.3.camel@oliverchick-Precision-WorkStation-T3400>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	David Vrabel <david.vrabel@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] Persistent grant maps for xen blk drivers
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 21.09.12 at 10:41, Oliver Chick <oliver.chick@citrix.com> wrote:
> On Fri, 2012-09-21 at 08:18 +0100, Jan Beulich wrote:
>> >>> On 20.09.12 at 23:24, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
>> > On Thu, Sep 20, 2012 at 03:13:42PM +0100, Oliver Chick wrote:
>> >> On Thu, 2012-09-20 at 14:49 +0100, Konrad Rzeszutek Wilk wrote:
>> >> > On Thu, Sep 20, 2012 at 12:48:41PM +0100, Jan Beulich wrote:
>> >> > > >>> On 20.09.12 at 13:30, Oliver Chick <oliver.chick@citrix.com> wrote:
>> >> > > > The memory overhead, and fallback mode points are related:
>> >> > > > -Firstly, it turns out that the overhead is actually 2.75MB, not 11MB
>> >> > > > per device. I made a mistake (pointed out by Jan) as the maximum number
>> >> > > > of requests that can fit into a single-page ring is 64, not 256.
>> >> > > > -Clearly, this still scales linearly. So the problem of memory footprint
>> >> > > > will occur with more VMs, or block devices.
>> >> > > > -Whilst 2.75MB per device is probably acceptable (?), if we start using
>> >> > > > multipage rings, then we might not want to have
>> >> > > > BLKIF_MAX_PERS_REQUESTS_PER_DEVICE==__RING_SIZE, as this will cause the
>> >> > > > memory overhead to increase. This is why I have implemented the
>> >> > > > 'fallback' mode. With a multipage ring, it seems reasonable to want the
>> >> > > > first $x$ grefs seen by blkback to be treated as persistent, and any
>> >> > > > later ones to be non-persistent. Does that seem sensible?
>> >> > > 
>> >> > > From a resource usage pov, perhaps. But this will get the guest
>> >> > > entirely unpredictable performance. Plus I don't think 11Mb of
>> >> > 
>> >> > Wouldn't it fall back to the older performance?
>> >> 
>> >> I guess it would be a bit more complex than that. It would be worse than
>> >> the new performance because the grefs that get processed by the
>> >> 'fallback' mode will cause TLB shootdowns. But any early grefs will
>> >> still be processed by the persistent mode, so won't have shootdowns.
>> >> Therefore, depending on the ratio of {persistent grants}:{non-persistent
>> >> grants), allocated by blkfront, the performance will be somewhere
>> >> inbetween the two extremes.
>> >> 
>> >> I guess that the choice is between
>> >> 1) Compiling blk{front,back} with a pre-determined number of persistent
>> >> grants, and failing if this limit is exceeded. This seems rather
>> >> unflexible, as blk{front,back} must then both both use the same version,
>> >> or you will get failures.
>> >> 2 (current setup)) Have a recommended maximum number of
>> >> persistently-mapped pages, and going into a 'fallback' mode if blkfront
>> >> exceeds this limit.
>> >> 3) Having blkback inform blkfront on startup as to how many grefs it is
>> >> willing to persistently-map. We then hit the same question again though:
>> >> what should be do if blkfront ignores this limit?
>> > 
>> > How about 2 and 3 together? Meaning have a recommended maximmum number.
>> > If we fall back due to memory pressure we can tell the guest that we
>> > are entering fall-back mode. The frontend can decide what it wants to do
>> > (throttle the amount of I/Os?) or just do a printk telling the user it
>> > dropped the speed from "Insane Hot!" down to "Turbo!"... 
>> > 
>> > Or maybe not. Perhaps just reporting it in the backend that we are
>> > hitting memory pressure and using the old-style-fallback mechanism
>> > so the system admin can take actions (and tell his users why suddenly
>> > their I/Os are so slow).
>> 
>> So would either of you help me understand what memory pressure
>> we're in need of dealing with here. So far, talk was only about
>> virtual address space that's needed for mapping in the grants, and
>> even then I don't see how this space requirement varies between
>> persistent and non-persistent grants - it's being reserved during
>> backend initialization anyway.
>> 
>> Jan
>> 
> 
> IIRC, the pending_pages[] used by blkback is a static array of 256
> pages, allocated during initialisation. Therefore, the memory mapped
> does not increase with the number of block devices being backed, for
> non-persistent operation. Whereas, when we become persistent, we don't
> unmap pages so can't reuse pages for different block devices, therefore
> we have to alloc more pages for each device.
> 
> Does that answer your question, and make sense?

This is an array of pointers to struct page, not an array of
pages. 11Mb worth of pages amounts to about 22k of memory
needed for this array. If we're _that_ short of memory, of
course some throttling or even failing of requests is desirable.

Jan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 21 10:38:50 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Sep 2012 10: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 1TF0ct-0000nZ-Pa; Fri, 21 Sep 2012 10:38:27 +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 1TF0cs-0000nU-5W
	for xen-devel@lists.xen.org; Fri, 21 Sep 2012 10:38:26 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1348223900!6692372!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29842 invoked from network); 21 Sep 2012 10:38:20 -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;
	21 Sep 2012 10:38:20 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 21 Sep 2012 11:38:19 +0100
Message-Id: <505C5FB7020000780009CEB0@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 21 Sep 2012 11:38:15 +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 0/2] cpuidle adjustments
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

1: remove unused latency_ticks member
2: x86: introduce MWAIT-based, ACPI-less CPU idle driver

Signed-off-by: Jan Beulich <jbeulich@suse.com>


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 21 10:38:50 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Sep 2012 10: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 1TF0ct-0000nZ-Pa; Fri, 21 Sep 2012 10:38:27 +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 1TF0cs-0000nU-5W
	for xen-devel@lists.xen.org; Fri, 21 Sep 2012 10:38:26 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1348223900!6692372!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29842 invoked from network); 21 Sep 2012 10:38:20 -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;
	21 Sep 2012 10:38:20 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 21 Sep 2012 11:38:19 +0100
Message-Id: <505C5FB7020000780009CEB0@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 21 Sep 2012 11:38:15 +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 0/2] cpuidle adjustments
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

1: remove unused latency_ticks member
2: x86: introduce MWAIT-based, ACPI-less CPU idle driver

Signed-off-by: Jan Beulich <jbeulich@suse.com>


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 21 10:39:31 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Sep 2012 10:39: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 1TF0da-0000pp-71; Fri, 21 Sep 2012 10:39:10 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony.perard@gmail.com>) id 1TF0dY-0000pd-QO
	for xen-devel@lists.xen.org; Fri, 21 Sep 2012 10:39:09 +0000
Received: from [85.158.137.99:45044] by server-12.bemta-3.messagelabs.com id
	A2/DB-10384-CC34C505; Fri, 21 Sep 2012 10:39:08 +0000
X-Env-Sender: anthony.perard@gmail.com
X-Msg-Ref: server-10.tower-217.messagelabs.com!1348223946!18604781!1
X-Originating-IP: [209.85.223.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-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13393 invoked from network); 21 Sep 2012 10:39:07 -0000
Received: from mail-ie0-f173.google.com (HELO mail-ie0-f173.google.com)
	(209.85.223.173)
	by server-10.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Sep 2012 10:39:07 -0000
Received: by iea17 with SMTP id 17so797213iea.32
	for <xen-devel@lists.xen.org>; Fri, 21 Sep 2012 03:39:05 -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=m7wuXd3ahI1AmNTHqghvy64bB1xR/jKKAHzwU40AzG0=;
	b=NVw2jsaAFKReyU/kzn4/IOTtX/eyZFsZkstV/tv9EIx4rpIU7ZRumvMBGs1Mmzu/SW
	aNNDEqf6yzStn/wp/qGwrbK+dc/O46ATM8fJBVXWfVSL27Qx3EJNXNTairYhGw5d5hBS
	i8bic+Xe049iGugWVnf/yGiy15F93w+By+RB/I06BMedUxWhGx8AUfzSljfLIXXOXsOC
	UCw5yEQhCZn8U6zuUbPrYT+WV3XCba2PJUPUIdF/TuCan3hAtThII0XT5zgOQCrzXKP0
	6qNgj4JN733WfDsZQ3c24ixbRCcf3RkE0QuLxp5JiuHToGK/d7XeEgZO/+vJK0NXBYAG
	1Okg==
Received: by 10.42.84.69 with SMTP id k5mr3646533icl.5.1348223945255; Fri, 21
	Sep 2012 03:39:05 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.64.126.131 with HTTP; Fri, 21 Sep 2012 03:38:33 -0700 (PDT)
In-Reply-To: <CAFLBxZYtmJ_bKFb90r45=C4Pq1-oe5Fy=eygSsQf4BcGj3EqGA@mail.gmail.com>
References: <CAFLBxZYtmJ_bKFb90r45=C4Pq1-oe5Fy=eygSsQf4BcGj3EqGA@mail.gmail.com>
From: Anthony PERARD <anthony.perard@gmail.com>
Date: Fri, 21 Sep 2012 11:38:33 +0100
Message-ID: <CAJJyHj+prTB1bit633+z60Yy8nyzH-8A=FUf485S9Mv6wFnY8A@mail.gmail.com>
To: George Dunlap <George.Dunlap@eu.citrix.com>
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Xen 4.3 development 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, Sep 19, 2012 at 5:58 PM, George Dunlap
<George.Dunlap@eu.citrix.com> wrote:
> = Feature tracking =
>
> Below is a list of features we're tracking for this release.  Please
> respond to this mail with any updates to the status.  If the status
> is "?", as most of them are, please respond with the status!  Example
> statuses include "not started", "in progress", "initial implementation
> submitted for review", "patches submitted".

> * Default to QEMU upstream
>  - qemu-based stubdom (Linux or BSD libc)
>    owner: anthony@citrix
>    status: ?
>    qemu-upstream needs a more fully-featured libc than exists in
>    minios.  Either work on a minimalist linux-based stubdom with
>    glibc, or port one of the BSD libcs to minios.

status: in progress

>  - pci pass-thru
>    owner: anthony@citrix
>    status: ?

Support for passthrough a PCI device is done, unless I miss something.
LibXL in Xen 4.2 support it, but qemu-xen in 4.2 does not. Right now,
only the last release of QEMU (1.2) support pci passthrough with Xen.

Also, to use QEMU upstream as default device model, we need implement
few more feature. I have:

- enable dirtybit tracking during migration
  status: patches submitted to QEMU and to LibXL.
- xl cd-{insert,eject}
  status: intilal implementation submitted

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 Fri Sep 21 10:39:31 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Sep 2012 10:39: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 1TF0da-0000pp-71; Fri, 21 Sep 2012 10:39:10 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony.perard@gmail.com>) id 1TF0dY-0000pd-QO
	for xen-devel@lists.xen.org; Fri, 21 Sep 2012 10:39:09 +0000
Received: from [85.158.137.99:45044] by server-12.bemta-3.messagelabs.com id
	A2/DB-10384-CC34C505; Fri, 21 Sep 2012 10:39:08 +0000
X-Env-Sender: anthony.perard@gmail.com
X-Msg-Ref: server-10.tower-217.messagelabs.com!1348223946!18604781!1
X-Originating-IP: [209.85.223.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-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13393 invoked from network); 21 Sep 2012 10:39:07 -0000
Received: from mail-ie0-f173.google.com (HELO mail-ie0-f173.google.com)
	(209.85.223.173)
	by server-10.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Sep 2012 10:39:07 -0000
Received: by iea17 with SMTP id 17so797213iea.32
	for <xen-devel@lists.xen.org>; Fri, 21 Sep 2012 03:39:05 -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=m7wuXd3ahI1AmNTHqghvy64bB1xR/jKKAHzwU40AzG0=;
	b=NVw2jsaAFKReyU/kzn4/IOTtX/eyZFsZkstV/tv9EIx4rpIU7ZRumvMBGs1Mmzu/SW
	aNNDEqf6yzStn/wp/qGwrbK+dc/O46ATM8fJBVXWfVSL27Qx3EJNXNTairYhGw5d5hBS
	i8bic+Xe049iGugWVnf/yGiy15F93w+By+RB/I06BMedUxWhGx8AUfzSljfLIXXOXsOC
	UCw5yEQhCZn8U6zuUbPrYT+WV3XCba2PJUPUIdF/TuCan3hAtThII0XT5zgOQCrzXKP0
	6qNgj4JN733WfDsZQ3c24ixbRCcf3RkE0QuLxp5JiuHToGK/d7XeEgZO/+vJK0NXBYAG
	1Okg==
Received: by 10.42.84.69 with SMTP id k5mr3646533icl.5.1348223945255; Fri, 21
	Sep 2012 03:39:05 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.64.126.131 with HTTP; Fri, 21 Sep 2012 03:38:33 -0700 (PDT)
In-Reply-To: <CAFLBxZYtmJ_bKFb90r45=C4Pq1-oe5Fy=eygSsQf4BcGj3EqGA@mail.gmail.com>
References: <CAFLBxZYtmJ_bKFb90r45=C4Pq1-oe5Fy=eygSsQf4BcGj3EqGA@mail.gmail.com>
From: Anthony PERARD <anthony.perard@gmail.com>
Date: Fri, 21 Sep 2012 11:38:33 +0100
Message-ID: <CAJJyHj+prTB1bit633+z60Yy8nyzH-8A=FUf485S9Mv6wFnY8A@mail.gmail.com>
To: George Dunlap <George.Dunlap@eu.citrix.com>
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Xen 4.3 development 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, Sep 19, 2012 at 5:58 PM, George Dunlap
<George.Dunlap@eu.citrix.com> wrote:
> = Feature tracking =
>
> Below is a list of features we're tracking for this release.  Please
> respond to this mail with any updates to the status.  If the status
> is "?", as most of them are, please respond with the status!  Example
> statuses include "not started", "in progress", "initial implementation
> submitted for review", "patches submitted".

> * Default to QEMU upstream
>  - qemu-based stubdom (Linux or BSD libc)
>    owner: anthony@citrix
>    status: ?
>    qemu-upstream needs a more fully-featured libc than exists in
>    minios.  Either work on a minimalist linux-based stubdom with
>    glibc, or port one of the BSD libcs to minios.

status: in progress

>  - pci pass-thru
>    owner: anthony@citrix
>    status: ?

Support for passthrough a PCI device is done, unless I miss something.
LibXL in Xen 4.2 support it, but qemu-xen in 4.2 does not. Right now,
only the last release of QEMU (1.2) support pci passthrough with Xen.

Also, to use QEMU upstream as default device model, we need implement
few more feature. I have:

- enable dirtybit tracking during migration
  status: patches submitted to QEMU and to LibXL.
- xl cd-{insert,eject}
  status: intilal implementation submitted

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 Fri Sep 21 10:39:33 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Sep 2012 10:39: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 1TF0dd-0000qN-K1; Fri, 21 Sep 2012 10:39:13 +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 1TF0db-0000pV-UH
	for xen-devel@lists.xen.org; Fri, 21 Sep 2012 10:39:12 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1348223945!4183951!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2772 invoked from network); 21 Sep 2012 10:39: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;
	21 Sep 2012 10:39:05 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 21 Sep 2012 11:39:05 +0100
Message-Id: <505C5FE6020000780009CEB5@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 21 Sep 2012 11:39:02 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__PartF1C0F0D6.0__="
Subject: [Xen-devel] [PATCH 1/2] cpuidle: remove unused latency_ticks member
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<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.

--=__PartF1C0F0D6.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

... and code used only for initializing it.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/arch/x86/acpi/cpu_idle.c
+++ b/xen/arch/x86/acpi/cpu_idle.c
@@ -74,7 +74,6 @@ static void (*lapic_timer_off)(void);
 static void (*lapic_timer_on)(void);
=20
 static uint64_t (*__read_mostly tick_to_ns)(uint64_t) =3D acpi_pm_tick_to_=
ns;
-static uint64_t (*__read_mostly ns_to_tick)(uint64_t) =3D ns_to_acpi_pm_ti=
ck;
=20
 static void (*pm_idle_save) (void) __read_mostly;
 unsigned int max_cstate __read_mostly =3D ACPI_PROCESSOR_MAX_POWER - 1;
@@ -225,7 +224,6 @@ __initcall(cpu_idle_key_init);
 static uint64_t get_stime_tick(void) { return (uint64_t)NOW(); }
 static uint64_t stime_ticks_elapsed(uint64_t t1, uint64_t t2) { return t2 =
- t1; }
 static uint64_t stime_tick_to_ns(uint64_t ticks) { return ticks; }
-static uint64_t ns_to_stime_tick(uint64_t ns) { return ns; }
=20
 static uint64_t get_acpi_pm_tick(void) { return (uint64_t)inl(pmtmr_ioport=
); }
 static uint64_t acpi_pm_ticks_elapsed(uint64_t t1, uint64_t t2)
@@ -665,7 +663,6 @@ static int cpuidle_init_cpu(int cpu)
             get_tick =3D get_stime_tick;
             ticks_elapsed =3D stime_ticks_elapsed;
             tick_to_ns =3D stime_tick_to_ns;
-            ns_to_tick =3D ns_to_stime_tick;
         }
=20
         acpi_power =3D xzalloc(struct acpi_processor_power);
@@ -943,7 +940,6 @@ static void set_cx(
     cx->latency  =3D xen_cx->latency;
     cx->power    =3D xen_cx->power;
    =20
-    cx->latency_ticks =3D ns_to_tick(cx->latency * 1000UL);
     cx->target_residency =3D cx->latency * latency_factor;
     if ( cx->type =3D=3D ACPI_STATE_C1 || cx->type =3D=3D ACPI_STATE_C2 )
         acpi_power->safe_state =3D cx;
--- a/xen/include/xen/cpuidle.h
+++ b/xen/include/xen/cpuidle.h
@@ -45,11 +45,10 @@ struct acpi_processor_cx
     u8 entry_method; /* ACPI_CSTATE_EM_xxx */
     u32 address;
     u32 latency;
-    u32 latency_ticks;
+    u32 target_residency;
     u32 power;
     u32 usage;
     u64 time;
-    u32 target_residency;
 };
=20
 struct acpi_processor_flags




--=__PartF1C0F0D6.0__=
Content-Type: text/plain; name="cpuidle-no-latency_ticks.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="cpuidle-no-latency_ticks.patch"

cpuidle: remove unused latency_ticks member=0A=0A... and code used only =
for initializing it.=0A=0ASigned-off-by: Jan Beulich <jbeulich@suse.com>=0A=
=0A--- a/xen/arch/x86/acpi/cpu_idle.c=0A+++ b/xen/arch/x86/acpi/cpu_idle.c=
=0A@@ -74,7 +74,6 @@ static void (*lapic_timer_off)(void);=0A static void =
(*lapic_timer_on)(void);=0A =0A static uint64_t (*__read_mostly tick_to_ns)=
(uint64_t) =3D acpi_pm_tick_to_ns;=0A-static uint64_t (*__read_mostly =
ns_to_tick)(uint64_t) =3D ns_to_acpi_pm_tick;=0A =0A static void (*pm_idle_=
save) (void) __read_mostly;=0A unsigned int max_cstate __read_mostly =3D =
ACPI_PROCESSOR_MAX_POWER - 1;=0A@@ -225,7 +224,6 @@ __initcall(cpu_idle_key=
_init);=0A static uint64_t get_stime_tick(void) { return (uint64_t)NOW(); =
}=0A static uint64_t stime_ticks_elapsed(uint64_t t1, uint64_t t2) { =
return t2 - t1; }=0A static uint64_t stime_tick_to_ns(uint64_t ticks) { =
return ticks; }=0A-static uint64_t ns_to_stime_tick(uint64_t ns) { return =
ns; }=0A =0A static uint64_t get_acpi_pm_tick(void) { return (uint64_t)inl(=
pmtmr_ioport); }=0A static uint64_t acpi_pm_ticks_elapsed(uint64_t t1, =
uint64_t t2)=0A@@ -665,7 +663,6 @@ static int cpuidle_init_cpu(int cpu)=0A =
            get_tick =3D get_stime_tick;=0A             ticks_elapsed =3D =
stime_ticks_elapsed;=0A             tick_to_ns =3D stime_tick_to_ns;=0A-   =
         ns_to_tick =3D ns_to_stime_tick;=0A         }=0A =0A         =
acpi_power =3D xzalloc(struct acpi_processor_power);=0A@@ -943,7 +940,6 @@ =
static void set_cx(=0A     cx->latency  =3D xen_cx->latency;=0A     =
cx->power    =3D xen_cx->power;=0A     =0A-    cx->latency_ticks =3D =
ns_to_tick(cx->latency * 1000UL);=0A     cx->target_residency =3D =
cx->latency * latency_factor;=0A     if ( cx->type =3D=3D ACPI_STATE_C1 || =
cx->type =3D=3D ACPI_STATE_C2 )=0A         acpi_power->safe_state =3D =
cx;=0A--- a/xen/include/xen/cpuidle.h=0A+++ b/xen/include/xen/cpuidle.h=0A@=
@ -45,11 +45,10 @@ struct acpi_processor_cx=0A     u8 entry_method; /* =
ACPI_CSTATE_EM_xxx */=0A     u32 address;=0A     u32 latency;=0A-    u32 =
latency_ticks;=0A+    u32 target_residency;=0A     u32 power;=0A     u32 =
usage;=0A     u64 time;=0A-    u32 target_residency;=0A };=0A =0A struct =
acpi_processor_flags=0A
--=__PartF1C0F0D6.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

--=__PartF1C0F0D6.0__=--


From xen-devel-bounces@lists.xen.org Fri Sep 21 10:39:33 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Sep 2012 10:39: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 1TF0dd-0000qN-K1; Fri, 21 Sep 2012 10:39:13 +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 1TF0db-0000pV-UH
	for xen-devel@lists.xen.org; Fri, 21 Sep 2012 10:39:12 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1348223945!4183951!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2772 invoked from network); 21 Sep 2012 10:39: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;
	21 Sep 2012 10:39:05 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 21 Sep 2012 11:39:05 +0100
Message-Id: <505C5FE6020000780009CEB5@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 21 Sep 2012 11:39:02 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__PartF1C0F0D6.0__="
Subject: [Xen-devel] [PATCH 1/2] cpuidle: remove unused latency_ticks member
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<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.

--=__PartF1C0F0D6.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

... and code used only for initializing it.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/arch/x86/acpi/cpu_idle.c
+++ b/xen/arch/x86/acpi/cpu_idle.c
@@ -74,7 +74,6 @@ static void (*lapic_timer_off)(void);
 static void (*lapic_timer_on)(void);
=20
 static uint64_t (*__read_mostly tick_to_ns)(uint64_t) =3D acpi_pm_tick_to_=
ns;
-static uint64_t (*__read_mostly ns_to_tick)(uint64_t) =3D ns_to_acpi_pm_ti=
ck;
=20
 static void (*pm_idle_save) (void) __read_mostly;
 unsigned int max_cstate __read_mostly =3D ACPI_PROCESSOR_MAX_POWER - 1;
@@ -225,7 +224,6 @@ __initcall(cpu_idle_key_init);
 static uint64_t get_stime_tick(void) { return (uint64_t)NOW(); }
 static uint64_t stime_ticks_elapsed(uint64_t t1, uint64_t t2) { return t2 =
- t1; }
 static uint64_t stime_tick_to_ns(uint64_t ticks) { return ticks; }
-static uint64_t ns_to_stime_tick(uint64_t ns) { return ns; }
=20
 static uint64_t get_acpi_pm_tick(void) { return (uint64_t)inl(pmtmr_ioport=
); }
 static uint64_t acpi_pm_ticks_elapsed(uint64_t t1, uint64_t t2)
@@ -665,7 +663,6 @@ static int cpuidle_init_cpu(int cpu)
             get_tick =3D get_stime_tick;
             ticks_elapsed =3D stime_ticks_elapsed;
             tick_to_ns =3D stime_tick_to_ns;
-            ns_to_tick =3D ns_to_stime_tick;
         }
=20
         acpi_power =3D xzalloc(struct acpi_processor_power);
@@ -943,7 +940,6 @@ static void set_cx(
     cx->latency  =3D xen_cx->latency;
     cx->power    =3D xen_cx->power;
    =20
-    cx->latency_ticks =3D ns_to_tick(cx->latency * 1000UL);
     cx->target_residency =3D cx->latency * latency_factor;
     if ( cx->type =3D=3D ACPI_STATE_C1 || cx->type =3D=3D ACPI_STATE_C2 )
         acpi_power->safe_state =3D cx;
--- a/xen/include/xen/cpuidle.h
+++ b/xen/include/xen/cpuidle.h
@@ -45,11 +45,10 @@ struct acpi_processor_cx
     u8 entry_method; /* ACPI_CSTATE_EM_xxx */
     u32 address;
     u32 latency;
-    u32 latency_ticks;
+    u32 target_residency;
     u32 power;
     u32 usage;
     u64 time;
-    u32 target_residency;
 };
=20
 struct acpi_processor_flags




--=__PartF1C0F0D6.0__=
Content-Type: text/plain; name="cpuidle-no-latency_ticks.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="cpuidle-no-latency_ticks.patch"

cpuidle: remove unused latency_ticks member=0A=0A... and code used only =
for initializing it.=0A=0ASigned-off-by: Jan Beulich <jbeulich@suse.com>=0A=
=0A--- a/xen/arch/x86/acpi/cpu_idle.c=0A+++ b/xen/arch/x86/acpi/cpu_idle.c=
=0A@@ -74,7 +74,6 @@ static void (*lapic_timer_off)(void);=0A static void =
(*lapic_timer_on)(void);=0A =0A static uint64_t (*__read_mostly tick_to_ns)=
(uint64_t) =3D acpi_pm_tick_to_ns;=0A-static uint64_t (*__read_mostly =
ns_to_tick)(uint64_t) =3D ns_to_acpi_pm_tick;=0A =0A static void (*pm_idle_=
save) (void) __read_mostly;=0A unsigned int max_cstate __read_mostly =3D =
ACPI_PROCESSOR_MAX_POWER - 1;=0A@@ -225,7 +224,6 @@ __initcall(cpu_idle_key=
_init);=0A static uint64_t get_stime_tick(void) { return (uint64_t)NOW(); =
}=0A static uint64_t stime_ticks_elapsed(uint64_t t1, uint64_t t2) { =
return t2 - t1; }=0A static uint64_t stime_tick_to_ns(uint64_t ticks) { =
return ticks; }=0A-static uint64_t ns_to_stime_tick(uint64_t ns) { return =
ns; }=0A =0A static uint64_t get_acpi_pm_tick(void) { return (uint64_t)inl(=
pmtmr_ioport); }=0A static uint64_t acpi_pm_ticks_elapsed(uint64_t t1, =
uint64_t t2)=0A@@ -665,7 +663,6 @@ static int cpuidle_init_cpu(int cpu)=0A =
            get_tick =3D get_stime_tick;=0A             ticks_elapsed =3D =
stime_ticks_elapsed;=0A             tick_to_ns =3D stime_tick_to_ns;=0A-   =
         ns_to_tick =3D ns_to_stime_tick;=0A         }=0A =0A         =
acpi_power =3D xzalloc(struct acpi_processor_power);=0A@@ -943,7 +940,6 @@ =
static void set_cx(=0A     cx->latency  =3D xen_cx->latency;=0A     =
cx->power    =3D xen_cx->power;=0A     =0A-    cx->latency_ticks =3D =
ns_to_tick(cx->latency * 1000UL);=0A     cx->target_residency =3D =
cx->latency * latency_factor;=0A     if ( cx->type =3D=3D ACPI_STATE_C1 || =
cx->type =3D=3D ACPI_STATE_C2 )=0A         acpi_power->safe_state =3D =
cx;=0A--- a/xen/include/xen/cpuidle.h=0A+++ b/xen/include/xen/cpuidle.h=0A@=
@ -45,11 +45,10 @@ struct acpi_processor_cx=0A     u8 entry_method; /* =
ACPI_CSTATE_EM_xxx */=0A     u32 address;=0A     u32 latency;=0A-    u32 =
latency_ticks;=0A+    u32 target_residency;=0A     u32 power;=0A     u32 =
usage;=0A     u64 time;=0A-    u32 target_residency;=0A };=0A =0A struct =
acpi_processor_flags=0A
--=__PartF1C0F0D6.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

--=__PartF1C0F0D6.0__=--


From xen-devel-bounces@lists.xen.org Fri Sep 21 10:41:24 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Sep 2012 10:41: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 1TF0fQ-00012n-5J; Fri, 21 Sep 2012 10:41:04 +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 1TF0fO-00012T-EB
	for xen-devel@lists.xen.org; Fri, 21 Sep 2012 10:41:02 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1348224052!4904130!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8501 invoked from network); 21 Sep 2012 10:40:52 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-15.tower-27.messagelabs.com with SMTP;
	21 Sep 2012 10:40:52 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 21 Sep 2012 11:40:51 +0100
Message-Id: <505C604F020000780009CEB9@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 21 Sep 2012 11:40: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="=__Part1F2E1E3F.1__="
Cc: Len Brown <lenb@kernel.org>
Subject: [Xen-devel] [PATCH 2/2] x86: introduce MWAIT-based,
 ACPI-less CPU idle 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

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.

--=__Part1F2E1E3F.1__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

This is a port of Linux'es intel-idle driver serving the same purpose.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/docs/misc/xen-command-line.markdown
+++ b/docs/misc/xen-command-line.markdown
@@ -620,6 +620,14 @@ limit is ignored by Xen.
=20
 Specify if the MMConfig space should be enabled.
=20
+### mwait-idle
+> `=3D <boolean>`
+
+> Default: `true`
+
+Use the MWAIT idle driver (with model specific C-state knowledge) instead
+of the ACPI based one.
+
 ### nmi
 > `=3D ignore | dom0 | fatal`
=20
--- a/xen/arch/x86/acpi/cpu_idle.c
+++ b/xen/arch/x86/acpi/cpu_idle.c
@@ -39,7 +39,6 @@
 #include <xen/smp.h>
 #include <xen/guest_access.h>
 #include <xen/keyhandler.h>
-#include <xen/cpuidle.h>
 #include <xen/trace.h>
 #include <xen/sched-if.h>
 #include <xen/irq.h>
@@ -54,6 +53,8 @@
 #include <public/sysctl.h>
 #include <acpi/cpufreq/cpufreq.h>
 #include <asm/apic.h>
+#include <asm/cpuidle.h>
+#include <asm/mwait.h>
 #include <xen/notifier.h>
 #include <xen/cpu.h>
=20
@@ -70,18 +71,18 @@
 #define GET_CC7_RES(val)  GET_HW_RES_IN_NS(0x3FE, val) /* SNB only */
=20
 static void lapic_timer_nop(void) { }
-static void (*lapic_timer_off)(void);
-static void (*lapic_timer_on)(void);
+void (*__read_mostly lapic_timer_off)(void);
+void (*__read_mostly lapic_timer_on)(void);
=20
 static uint64_t (*__read_mostly tick_to_ns)(uint64_t) =3D acpi_pm_tick_to_=
ns;
=20
-static void (*pm_idle_save) (void) __read_mostly;
+void (*__read_mostly pm_idle_save)(void);
 unsigned int max_cstate __read_mostly =3D ACPI_PROCESSOR_MAX_POWER - 1;
 integer_param("max_cstate", max_cstate);
 static bool_t __read_mostly local_apic_timer_c2_ok;
 boolean_param("lapic_timer_c2_ok", local_apic_timer_c2_ok);
=20
-static struct acpi_processor_power *__read_mostly processor_powers[NR_CPUS=
];
+struct acpi_processor_power *__read_mostly processor_powers[NR_CPUS];
=20
 struct hw_residencies
 {
@@ -236,12 +237,10 @@ static uint64_t acpi_pm_ticks_elapsed(ui
         return ((0xFFFFFFFF - t1) + t2 +1);
 }
=20
-static uint64_t (*__read_mostly get_tick)(void) =3D get_acpi_pm_tick;
+uint64_t (*__read_mostly cpuidle_get_tick)(void) =3D get_acpi_pm_tick;
 static uint64_t (*__read_mostly ticks_elapsed)(uint64_t, uint64_t)
     =3D acpi_pm_ticks_elapsed;
=20
-#define MWAIT_ECX_INTERRUPT_BREAK   (0x1)
-
 /*
  * The bit is set iff cpu use monitor/mwait to enter C state
  * with this flag set, CPU can be waken up from C state
@@ -263,7 +262,7 @@ void cpuidle_wakeup_mwait(cpumask_t *mas
     cpumask_andnot(mask, mask, &target);
 }
=20
-static void mwait_idle_with_hints(unsigned long eax, unsigned long ecx)
+void mwait_idle_with_hints(unsigned int eax, unsigned int ecx)
 {
     unsigned int cpu =3D smp_processor_id();
     s_time_t expires =3D per_cpu(timer_deadline, cpu);
@@ -334,7 +333,7 @@ static struct {
     unsigned int count;
 } c3_cpu_status =3D { .lock =3D SPIN_LOCK_UNLOCKED };
=20
-static inline void trace_exit_reason(u32 *irq_traced)
+void trace_exit_reason(u32 *irq_traced)
 {
     if ( unlikely(tb_init_done) )
     {
@@ -354,15 +353,6 @@ static inline void trace_exit_reason(u32
     }
 }
=20
-/* vcpu is urgent if vcpu is polling event channel
- *
- * if urgent vcpu exists, CPU should not enter deep C state
- */
-static int sched_has_urgent_vcpu(void)
-{
-    return atomic_read(&this_cpu(schedule_data).urgent_count);
-}
-
 /*
  * "AAJ72. EOI Transaction May Not be Sent if Software Enters Core C6 =
During=20
  * an Interrupt Service Routine"
@@ -388,10 +378,11 @@ bool_t errata_c6_eoi_workaround(void)
     return (fix_needed && cpu_has_pending_apic_eoi());
 }
=20
-static inline void acpi_update_idle_stats(struct acpi_processor_power =
*power,
-                                          struct acpi_processor_cx *cx,
-                                          int64_t sleep_ticks)
+void update_idle_stats(struct acpi_processor_power *power,
+                       struct acpi_processor_cx *cx,
+                       uint64_t before, uint64_t after)
 {
+    int64_t sleep_ticks =3D ticks_elapsed(before, after);
     /* Interrupts are disabled */
=20
     spin_lock(&power->stat_lock);
@@ -472,19 +463,19 @@ static void acpi_processor_idle(void)
         if ( cx->type =3D=3D ACPI_STATE_C1 || local_apic_timer_c2_ok )
         {
             /* Get start time (ticks) */
-            t1 =3D get_tick();
+            t1 =3D cpuidle_get_tick();
             /* Trace cpu idle entry */
             TRACE_4D(TRC_PM_IDLE_ENTRY, cx->idx, t1, exp, pred);
             /* Invoke C2 */
             acpi_idle_do_entry(cx);
             /* Get end time (ticks) */
-            t2 =3D get_tick();
+            t2 =3D cpuidle_get_tick();
             trace_exit_reason(irq_traced);
             /* 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));
+            update_idle_stats(power, cx, t1, t2);
             /* Re-enable interrupts */
             local_irq_enable();
             break;
@@ -500,7 +491,7 @@ static void acpi_processor_idle(void)
         lapic_timer_off();
=20
         /* Get start time (ticks) */
-        t1 =3D get_tick();
+        t1 =3D cpuidle_get_tick();
         /* Trace cpu idle entry */
         TRACE_4D(TRC_PM_IDLE_ENTRY, cx->idx, t1, exp, pred);
=20
@@ -549,7 +540,7 @@ static void acpi_processor_idle(void)
         }
=20
         /* Get end time (ticks) */
-        t2 =3D get_tick();
+        t2 =3D cpuidle_get_tick();
=20
         /* recovering TSC */
         cstate_restore_tsc();
@@ -559,7 +550,7 @@ static void acpi_processor_idle(void)
                  irq_traced[0], irq_traced[1], irq_traced[2], irq_traced[3=
]);
=20
         /* Update statistics */
-        acpi_update_idle_stats(power, cx, ticks_elapsed(t1, t2));
+        update_idle_stats(power, cx, t1, t2);
         /* Re-enable interrupts */
         local_irq_enable();
         /* recovering APIC */
@@ -586,7 +577,7 @@ static void acpi_processor_idle(void)
         cpuidle_current_governor->reflect(power);
 }
=20
-static void acpi_dead_idle(void)
+void acpi_dead_idle(void)
 {
     struct acpi_processor_power *power;
     struct acpi_processor_cx *cx;
@@ -649,7 +640,7 @@ default_halt:
         halt();
 }
=20
-static int cpuidle_init_cpu(int cpu)
+int cpuidle_init_cpu(unsigned int cpu)
 {
     struct acpi_processor_power *acpi_power;
=20
@@ -660,7 +651,7 @@ static int cpuidle_init_cpu(int cpu)
=20
         if ( cpu =3D=3D 0 && boot_cpu_has(X86_FEATURE_NONSTOP_TSC) )
         {
-            get_tick =3D get_stime_tick;
+            cpuidle_get_tick =3D get_stime_tick;
             ticks_elapsed =3D stime_ticks_elapsed;
             tick_to_ns =3D stime_tick_to_ns;
         }
@@ -685,9 +676,6 @@ static int cpuidle_init_cpu(int cpu)
     return 0;
 }
=20
-#define MWAIT_SUBSTATE_MASK (0xf)
-#define MWAIT_SUBSTATE_SIZE (4)
-
 static int acpi_processor_ffh_cstate_probe(xen_processor_cx_t *cx)
 {
     struct cpuinfo_x86 *c =3D &current_cpu_data;
@@ -1026,6 +1014,9 @@ long set_cx_pminfo(uint32_t cpu, struct=20
     if ( unlikely(!guest_handle_okay(power->states, power->count)) )
         return -EFAULT;
=20
+    if ( pm_idle_save && pm_idle !=3D acpi_processor_idle )
+        return 0;
+
     print_cx_pminfo(cpu, power);
=20
     /* map from acpi_id to cpu_id */
@@ -1195,7 +1186,12 @@ static struct notifier_block cpu_nfb =3D {
 static int __init cpuidle_presmp_init(void)
 {
     void *cpu =3D (void *)(long)smp_processor_id();
-    cpu_callback(&cpu_nfb, CPU_ONLINE, cpu);
+
+    if ( !xen_cpuidle )
+        return 0;
+
+    mwait_idle_init(&cpu_nfb);
+    cpu_nfb.notifier_call(&cpu_nfb, CPU_ONLINE, cpu);
     register_cpu_notifier(&cpu_nfb);
     return 0;
 }
--- a/xen/arch/x86/cpu/Makefile
+++ b/xen/arch/x86/cpu/Makefile
@@ -5,6 +5,7 @@ obj-y +=3D amd.o
 obj-y +=3D common.o
 obj-y +=3D intel.o
 obj-y +=3D intel_cacheinfo.o
+obj-y +=3D mwait-idle.o
=20
 # Keeping around for VIA support (JBeulich)
 # obj-$(x86_32) +=3D centaur.o
--- /dev/null
+++ b/xen/arch/x86/cpu/mwait-idle.c
@@ -0,0 +1,513 @@
+/*
+ * mwait_idle.c - native hardware idle loop for modern processors
+ *
+ * Copyright (c) 2010, Intel Corporation.
+ * Len Brown <len.brown@intel.com>
+ *
+ * This program is free software; you can redistribute it and/or modify =
it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License =
for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License =
along with
+ * this program; if not, write to the Free Software Foundation, Inc.,
+ * 51 Franklin St - Fifth Floor, Boston, MA 02110-1301 USA.
+ */
+
+/*
+ * mwait_idle is a cpuidle driver that loads on specific processors
+ * in lieu of the legacy ACPI processor_idle driver.  The intent is to
+ * make Linux more efficient on these processors, as mwait_idle knows
+ * more than ACPI, as well as make Linux more immune to ACPI BIOS bugs.
+ */
+
+/*
+ * Design Assumptions
+ *
+ * All CPUs have same idle states as boot CPU
+ *
+ * Chipset BM_STS (bus master status) bit is a NOP
+ *	for preventing entry into deep C-states
+ */
+
+/*
+ * Known limitations
+ *
+ * The driver currently initializes for_each_online_cpu() upon load.
+ * It it unaware of subsequent processors hot-added to the system.
+ * This means that if you boot with maxcpus=3Dn and later online
+ * processors above n, those processors will use C1 only.
+ *
+ * ACPI has a .suspend hack to turn off deep C-states during suspend
+ * to avoid complications with the lapic timer workaround.
+ * Have not seen issues with suspend, but may need same workaround here.
+ */
+
+/* un-comment DEBUG to enable pr_debug() statements */
+#define DEBUG
+
+#include <xen/lib.h>
+#include <xen/cpu.h>
+#include <xen/init.h>
+#include <xen/softirq.h>
+#include <xen/trace.h>
+#include <asm/cpuidle.h>
+#include <asm/mwait.h>
+#include <asm/msr.h>
+#include <acpi/cpufreq/cpufreq.h>
+
+#define MWAIT_IDLE_VERSION "0.4"
+#undef PREFIX
+#define PREFIX "mwait-idle: "
+
+#ifdef DEBUG
+# define pr_debug(fmt...) printk(KERN_DEBUG fmt)
+#else
+# define pr_debug(fmt...)
+#endif
+
+static __initdata bool_t no_mwait_idle;
+invbool_param("mwait-idle", no_mwait_idle);
+
+static unsigned int mwait_substates;
+
+#define LAPIC_TIMER_ALWAYS_RELIABLE 0xFFFFFFFF
+/* Reliable LAPIC Timer States, bit 1 for C1 etc. Default to only C1. */
+static unsigned int lapic_timer_reliable_states =3D (1 << 1);
+
+struct idle_cpu {
+	const struct cpuidle_state *state_table;
+
+	/*
+	 * Hardware C-state auto-demotion may not always be optimal.
+	 * Indicate which enable bits to clear here.
+	 */
+	unsigned long auto_demotion_disable_flags;
+};
+
+static const struct idle_cpu *icpu;
+
+static const struct cpuidle_state {
+	char		name[16];
+	unsigned int	flags;
+	unsigned int	exit_latency; /* in US */
+	int		power_usage; /* in mW */
+	unsigned int	target_residency; /* in US */
+} *cpuidle_state_table;
+
+/*
+ * Set this flag for states where the HW flushes the TLB for us
+ * and so we don't need cross-calls to keep it consistent.
+ * If this flag is set, SW flushes the TLB, so even if the
+ * HW doesn't do the flushing, this flag is safe to use.
+ */
+#define CPUIDLE_FLAG_TLB_FLUSHED	0x10000
+
+/*
+ * States are indexed by the cstate number,
+ * which is also the index into the MWAIT hint array.
+ * Thus C0 is a dummy.
+ */
+static const struct cpuidle_state nehalem_cstates[MWAIT_MAX_NUM_CSTATES] =
=3D {
+	{ /* MWAIT C0 */ },
+	{ /* MWAIT C1 */
+		.name =3D "C1-NHM",
+		.exit_latency =3D 3,
+		.target_residency =3D 6,
+	},
+	{ /* MWAIT C2 */
+		.name =3D "C3-NHM",
+		.flags =3D CPUIDLE_FLAG_TLB_FLUSHED,
+		.exit_latency =3D 20,
+		.target_residency =3D 80,
+	},
+	{ /* MWAIT C3 */
+		.name =3D "C6-NHM",
+		.flags =3D CPUIDLE_FLAG_TLB_FLUSHED,
+		.exit_latency =3D 200,
+		.target_residency =3D 800,
+	}
+};
+
+static const struct cpuidle_state snb_cstates[MWAIT_MAX_NUM_CSTATES] =3D =
{
+	{ /* MWAIT C0 */ },
+	{ /* MWAIT C1 */
+		.name =3D "C1-SNB",
+		.exit_latency =3D 1,
+		.target_residency =3D 1,
+	},
+	{ /* MWAIT C2 */
+		.name =3D "C3-SNB",
+		.flags =3D CPUIDLE_FLAG_TLB_FLUSHED,
+		.exit_latency =3D 80,
+		.target_residency =3D 211,
+	},
+	{ /* MWAIT C3 */
+		.name =3D "C6-SNB",
+		.flags =3D CPUIDLE_FLAG_TLB_FLUSHED,
+		.exit_latency =3D 104,
+		.target_residency =3D 345,
+	},
+	{ /* MWAIT C4 */
+		.name =3D "C7-SNB",
+		.flags =3D CPUIDLE_FLAG_TLB_FLUSHED,
+		.exit_latency =3D 109,
+		.target_residency =3D 345,
+	}
+};
+
+static const struct cpuidle_state ivb_cstates[MWAIT_MAX_NUM_CSTATES] =3D =
{
+	{ /* MWAIT C0 */ },
+	{ /* MWAIT C1 */
+		.name =3D "C1-IVB",
+		.exit_latency =3D 1,
+		.target_residency =3D 1,
+	},
+	{ /* MWAIT C2 */
+		.name =3D "C3-IVB",
+		.flags =3D CPUIDLE_FLAG_TLB_FLUSHED,
+		.exit_latency =3D 59,
+		.target_residency =3D 156,
+	},
+	{ /* MWAIT C3 */
+		.name =3D "C6-IVB",
+		.flags =3D CPUIDLE_FLAG_TLB_FLUSHED,
+		.exit_latency =3D 80,
+		.target_residency =3D 300,
+	},
+	{ /* MWAIT C4 */
+		.name =3D "C7-IVB",
+		.flags =3D CPUIDLE_FLAG_TLB_FLUSHED,
+		.exit_latency =3D 87,
+		.target_residency =3D 300,
+	}
+};
+
+static const struct cpuidle_state atom_cstates[MWAIT_MAX_NUM_CSTATES] =3D =
{
+	{ /* MWAIT C0 */ },
+	{ /* MWAIT C1 */
+		.name =3D "C1-ATM",
+		.exit_latency =3D 1,
+		.target_residency =3D 4,
+	},
+	{ /* MWAIT C2 */
+		.name =3D "C2-ATM",
+		.exit_latency =3D 20,
+		.target_residency =3D 80,
+	},
+	{ /* MWAIT C3 */ },
+	{ /* MWAIT C4 */
+		.name =3D "C4-ATM",
+		.flags =3D CPUIDLE_FLAG_TLB_FLUSHED,
+		.exit_latency =3D 100,
+		.target_residency =3D 400,
+	},
+	{ /* MWAIT C5 */ },
+	{ /* MWAIT C6 */
+		.name =3D "C6-ATM",
+		.flags =3D CPUIDLE_FLAG_TLB_FLUSHED,
+		.exit_latency =3D 140,
+		.target_residency =3D 560,
+	}
+};
+
+static u32 get_driver_data(unsigned int cstate)
+{
+	static const u32 driver_data[] =3D {
+		[1] /* MWAIT C1 */ =3D 0x00,
+		[2] /* MWAIT C2 */ =3D 0x10,
+		[3] /* MWAIT C3 */ =3D 0x20,
+		[4] /* MWAIT C4 */ =3D 0x30,
+		[5] /* MWAIT C5 */ =3D 0x40,
+		[6] /* MWAIT C6 */ =3D 0x52,
+	};
+
+	return driver_data[cstate < ARRAY_SIZE(driver_data) ? cstate : 0];
+}
+
+static void mwait_idle(void)
+{
+	unsigned int cpu =3D smp_processor_id();
+	struct acpi_processor_power *power =3D processor_powers[cpu];
+	struct acpi_processor_cx *cx =3D NULL;
+	unsigned int eax, next_state, cstate;
+	u64 before, after;
+	u32 exp =3D 0, pred =3D 0, irq_traced[4] =3D { 0 };
+
+	if (max_cstate > 0 && power && !sched_has_urgent_vcpu() &&
+	    (next_state =3D cpuidle_current_governor->select(power)) > 0) =
{
+		do {
+			cx =3D &power->states[next_state];
+		} while (cx->type > max_cstate && --next_state);
+		if (!next_state)
+			cx =3D NULL;
+		menu_get_trace_data(&exp, &pred);
+	}
+	if (!cx) {
+		if (pm_idle_save)
+			pm_idle_save();
+		else
+			safe_halt();
+		return;
+	}
+
+	cpufreq_dbs_timer_suspend();
+
+	sched_tick_suspend();
+	/* sched_tick_suspend() can raise TIMER_SOFTIRQ. Process it now. =
*/
+	process_pending_softirqs();
+
+	/* Interrupts must be disabled for C2 and higher transitions. */
+	local_irq_disable();
+
+	if (!cpu_is_haltable(cpu)) {
+		local_irq_enable();
+		sched_tick_resume();
+		cpufreq_dbs_timer_resume();
+		return;
+	}
+
+	power->last_state =3D cx;
+	eax =3D cx->address;
+	cstate =3D ((eax >> MWAIT_SUBSTATE_SIZE) & MWAIT_CSTATE_MASK) + 1;
+
+#if 0 /* XXX Can we/do we need to do something similar on Xen? */
+	/*
+	 * leave_mm() to avoid costly and often unnecessary wakeups
+	 * for flushing the user TLB's associated with the active mm.
+	 */
+	if (cpuidle_state_table[].flags & CPUIDLE_FLAG_TLB_FLUSHED)
+		leave_mm(cpu);
+#endif
+
+	if (!(lapic_timer_reliable_states & (1 << cstate)))
+		lapic_timer_off();
+
+	before =3D cpuidle_get_tick();
+	TRACE_4D(TRC_PM_IDLE_ENTRY, cx->idx, before, exp, pred);
+
+	if (cpu_is_haltable(cpu))
+		mwait_idle_with_hints(eax, MWAIT_ECX_INTERRUPT_BREAK);
+
+	after =3D cpuidle_get_tick();
+
+	cstate_restore_tsc();
+	trace_exit_reason(irq_traced);
+	TRACE_6D(TRC_PM_IDLE_EXIT, cx->idx, after,
+		irq_traced[0], irq_traced[1], irq_traced[2], irq_traced[3])=
;
+
+	update_idle_stats(power, cx, before, after);
+	local_irq_enable();
+
+	if (!(lapic_timer_reliable_states & (1 << cstate)))
+		lapic_timer_on();
+
+	/* Now back in C0. */
+	power->last_state =3D &power->states[0];
+
+	sched_tick_resume();
+	cpufreq_dbs_timer_resume();
+
+	if ( cpuidle_current_governor->reflect )
+		cpuidle_current_governor->reflect(power);
+}
+
+static void auto_demotion_disable(void *dummy)
+{
+	u64 msr_bits;
+
+	rdmsrl(MSR_NHM_SNB_PKG_CST_CFG_CTL, msr_bits);
+	msr_bits &=3D ~(icpu->auto_demotion_disable_flags);
+	wrmsrl(MSR_NHM_SNB_PKG_CST_CFG_CTL, msr_bits);
+}
+
+static const struct idle_cpu idle_cpu_nehalem =3D {
+	.state_table =3D nehalem_cstates,
+	.auto_demotion_disable_flags =3D NHM_C1_AUTO_DEMOTE | NHM_C3_AUTO_D=
EMOTE,
+};
+
+static const struct idle_cpu idle_cpu_atom =3D {
+	.state_table =3D atom_cstates,
+};
+
+static const struct idle_cpu idle_cpu_lincroft =3D {
+	.state_table =3D atom_cstates,
+	.auto_demotion_disable_flags =3D ATM_LNC_C6_AUTO_DEMOTE,
+};
+
+static const struct idle_cpu idle_cpu_snb =3D {
+	.state_table =3D snb_cstates,
+};
+
+static const struct idle_cpu idle_cpu_ivb =3D {
+	.state_table =3D ivb_cstates,
+};
+
+#define ICPU(model, cpu) { 6, model, &idle_cpu_##cpu }
+
+static struct intel_idle_id {
+	unsigned int family, model;
+	const struct idle_cpu *data;
+} intel_idle_ids[] __initdata =3D {
+	ICPU(0x1a, nehalem),
+	ICPU(0x1e, nehalem),
+	ICPU(0x1f, nehalem),
+	ICPU(0x25, nehalem),
+	ICPU(0x2c, nehalem),
+	ICPU(0x2e, nehalem),
+	ICPU(0x2f, nehalem),
+	ICPU(0x1c, atom),
+	ICPU(0x26, lincroft),
+	ICPU(0x2a, snb),
+	ICPU(0x2d, snb),
+	ICPU(0x3a, ivb),
+	{}
+};
+
+static int __init mwait_idle_probe(void)
+{
+	unsigned int eax, ebx, ecx;
+	const struct intel_idle_id *id;
+
+	if (boot_cpu_data.x86_vendor !=3D X86_VENDOR_INTEL ||
+	    !boot_cpu_has(X86_FEATURE_MWAIT) ||
+	    boot_cpu_data.cpuid_level < CPUID_MWAIT_LEAF)
+		return -ENODEV;
+
+	for (id =3D intel_idle_ids; id->family; ++id)
+		if (id->family =3D=3D boot_cpu_data.x86 &&
+		    id->model =3D=3D boot_cpu_data.x86_model)
+			break;
+	if (!id->family) {
+		pr_debug(PREFIX "does not run on family %d model %d\n",
+			 boot_cpu_data.x86, boot_cpu_data.x86_model);
+		return -ENODEV;
+	}
+
+	cpuid(CPUID_MWAIT_LEAF, &eax, &ebx, &ecx, &mwait_substates);
+
+	if (!(ecx & CPUID5_ECX_EXTENSIONS_SUPPORTED) ||
+	    !(ecx & CPUID5_ECX_INTERRUPT_BREAK) ||
+	    !mwait_substates)
+		return -ENODEV;
+
+	if (!max_cstate || no_mwait_idle) {
+		pr_debug(PREFIX "disabled\n");
+		return -EPERM;
+	}
+
+	pr_debug(PREFIX "MWAIT substates: %#x\n", mwait_substates);
+
+	icpu =3D id->data;
+	cpuidle_state_table =3D icpu->state_table;
+
+	if (boot_cpu_has(X86_FEATURE_ARAT))
+		lapic_timer_reliable_states =3D LAPIC_TIMER_ALWAYS_RELIABLE=
;
+
+	pr_debug(PREFIX "v" MWAIT_IDLE_VERSION " model %#x\n",
+		 boot_cpu_data.x86_model);
+
+	pr_debug(PREFIX "lapic_timer_reliable_states %#x\n",
+		 lapic_timer_reliable_states);
+	return 0;
+}
+
+static int mwait_idle_cpu_init(struct notifier_block *nfb,
+			       unsigned long action, void *hcpu)
+{
+	unsigned int cpu =3D (unsigned long)hcpu, cstate;
+	struct acpi_processor_power *dev =3D processor_powers[cpu];
+
+	switch (action) {
+	default:
+		return NOTIFY_DONE;
+
+	case CPU_UP_PREPARE:
+		cpuidle_init_cpu(cpu);
+		return NOTIFY_DONE;
+
+	case CPU_ONLINE:
+		if (!dev)
+			return NOTIFY_DONE;
+		break;
+	}
+
+	dev->count =3D 1;
+
+	for (cstate =3D 1; cstate < MWAIT_MAX_NUM_CSTATES; ++cstate) {
+		unsigned int num_substates;
+		struct acpi_processor_cx *cx;
+
+		if (cstate > max_cstate) {
+			printk(PREFIX "max C-state %u reached\n", =
max_cstate);
+			break;
+		}
+
+		/* Does the state exist in CPUID.MWAIT? */
+		num_substates =3D (mwait_substates >> (cstate * 4))
+			& MWAIT_SUBSTATE_MASK;
+		if (!num_substates)
+			continue;
+		/* Is the state not enabled? */
+		if (!cpuidle_state_table[cstate].target_residency) {
+			/* does the driver not know about the state? */
+			if (!pm_idle_save && !*cpuidle_state_table[cstate].=
name)
+				pr_debug(PREFIX "unaware of family %#x =
model %#x MWAIT %u\n",
+					 boot_cpu_data.x86,
+					 boot_cpu_data.x86_model, cstate);
+			continue;
+		}
+
+		if (dev->count >=3D ACPI_PROCESSOR_MAX_POWER) {
+			printk(PREFIX "max C-state count of %u reached\n",
+			       ACPI_PROCESSOR_MAX_POWER);
+			break;
+		}
+
+		if (cstate > 2 && !boot_cpu_has(X86_FEATURE_NONSTOP_TSC)) =
{
+			if (pm_idle_save)
+				continue;
+			setup_clear_cpu_cap(X86_FEATURE_TSC_RELIABLE);
+		}
+
+		cx =3D dev->states + dev->count;
+		cx->type =3D cstate;
+		cx->address =3D get_driver_data(cstate);
+		cx->entry_method =3D ACPI_CSTATE_EM_FFH;
+		cx->power =3D cpuidle_state_table[cstate].power_usage;
+		cx->latency =3D cpuidle_state_table[cstate].exit_latency;
+		cx->target_residency =3D
+			cpuidle_state_table[cstate].target_residency;
+
+		dev->count++;
+	}
+
+	if (icpu->auto_demotion_disable_flags)
+		on_selected_cpus(cpumask_of(cpu), auto_demotion_disable, =
NULL, 1);
+
+	return NOTIFY_DONE;
+}
+
+int __init mwait_idle_init(struct notifier_block *nfb)
+{
+	int err;
+
+	if (pm_idle_save)
+		return -ENODEV;
+
+	err =3D mwait_idle_probe();
+	if (!err) {
+		nfb->notifier_call =3D mwait_idle_cpu_init;
+		mwait_idle_cpu_init(nfb, CPU_UP_PREPARE, NULL);
+
+		pm_idle_save =3D pm_idle;
+		pm_idle =3D mwait_idle;
+		dead_idle =3D acpi_dead_idle;
+	}
+
+	return err;
+}
--- /dev/null
+++ b/xen/include/asm-x86/cpuidle.h
@@ -0,0 +1,35 @@
+#ifndef __ASM_X86_CPUIDLE_H__
+#define __ASM_X86_CPUIDLE_H__
+
+#include <xen/cpuidle.h>
+#include <xen/notifier.h>
+#include <xen/sched.h>
+#include <xen/sched-if.h>
+
+extern struct acpi_processor_power *processor_powers[];
+
+extern void (*pm_idle_save)(void);
+
+extern void (*lapic_timer_off)(void);
+extern void (*lapic_timer_on)(void);
+
+extern uint64_t (*cpuidle_get_tick)(void);
+
+int mwait_idle_init(struct notifier_block *);
+int cpuidle_init_cpu(unsigned int cpu);
+void acpi_dead_idle(void);
+void trace_exit_reason(u32 *irq_traced);
+void update_idle_stats(struct acpi_processor_power *,
+                       struct acpi_processor_cx *, uint64_t, uint64_t);
+
+/*
+ * vcpu is urgent if vcpu is polling event channel
+ *
+ * if urgent vcpu exists, CPU should not enter deep C state
+ */
+static inline int sched_has_urgent_vcpu(void)
+{
+    return atomic_read(&this_cpu(schedule_data).urgent_count);
+}
+
+#endif /* __X86_ASM_CPUIDLE_H__ */
--- a/xen/include/asm-x86/msr-index.h
+++ b/xen/include/asm-x86/msr-index.h
@@ -36,6 +36,11 @@
 #define MSR_IA32_PERFCTR1		0x000000c2
 #define MSR_FSB_FREQ			0x000000cd
=20
+#define MSR_NHM_SNB_PKG_CST_CFG_CTL	0x000000e2
+#define NHM_C3_AUTO_DEMOTE		(1UL << 25)
+#define NHM_C1_AUTO_DEMOTE		(1UL << 26)
+#define ATM_LNC_C6_AUTO_DEMOTE		(1UL << 25)
+
 #define MSR_MTRRcap			0x000000fe
 #define MSR_IA32_BBL_CR_CTL		0x00000119
=20
--- /dev/null
+++ b/xen/include/asm-x86/mwait.h
@@ -0,0 +1,17 @@
+#ifndef __ASM_X86_MWAIT_H__
+#define __ASM_X86_MWAIT_H__
+
+#define MWAIT_SUBSTATE_MASK		0xf
+#define MWAIT_CSTATE_MASK		0xf
+#define MWAIT_SUBSTATE_SIZE		4
+#define MWAIT_MAX_NUM_CSTATES		8
+
+#define CPUID_MWAIT_LEAF		5
+#define CPUID5_ECX_EXTENSIONS_SUPPORTED 0x1
+#define CPUID5_ECX_INTERRUPT_BREAK	0x2
+
+#define MWAIT_ECX_INTERRUPT_BREAK	0x1
+
+void mwait_idle_with_hints(unsigned int eax, unsigned int ecx);
+
+#endif /* __ASM_X86_MWAIT_H__ */



--=__Part1F2E1E3F.1__=
Content-Type: text/plain; name="x86-mwait-idle.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="x86-mwait-idle.patch"

x86: introduce MWAIT-based, ACPI-less CPU idle driver=0A=0AThis is a port =
of Linux'es intel-idle driver serving the same purpose.=0A=0ASigned-off-by:=
 Jan Beulich <jbeulich@suse.com>=0A=0A--- a/docs/misc/xen-command-line.mark=
down=0A+++ b/docs/misc/xen-command-line.markdown=0A@@ -620,6 +620,14 @@ =
limit is ignored by Xen.=0A =0A Specify if the MMConfig space should be =
enabled.=0A =0A+### mwait-idle=0A+> `=3D <boolean>`=0A+=0A+> Default: =
`true`=0A+=0A+Use the MWAIT idle driver (with model specific C-state =
knowledge) instead=0A+of the ACPI based one.=0A+=0A ### nmi=0A > `=3D =
ignore | dom0 | fatal`=0A =0A--- a/xen/arch/x86/acpi/cpu_idle.c=0A+++ =
b/xen/arch/x86/acpi/cpu_idle.c=0A@@ -39,7 +39,6 @@=0A #include <xen/smp.h>=
=0A #include <xen/guest_access.h>=0A #include <xen/keyhandler.h>=0A-#includ=
e <xen/cpuidle.h>=0A #include <xen/trace.h>=0A #include <xen/sched-if.h>=0A=
 #include <xen/irq.h>=0A@@ -54,6 +53,8 @@=0A #include <public/sysctl.h>=0A =
#include <acpi/cpufreq/cpufreq.h>=0A #include <asm/apic.h>=0A+#include =
<asm/cpuidle.h>=0A+#include <asm/mwait.h>=0A #include <xen/notifier.h>=0A =
#include <xen/cpu.h>=0A =0A@@ -70,18 +71,18 @@=0A #define GET_CC7_RES(val) =
 GET_HW_RES_IN_NS(0x3FE, val) /* SNB only */=0A =0A static void lapic_timer=
_nop(void) { }=0A-static void (*lapic_timer_off)(void);=0A-static void =
(*lapic_timer_on)(void);=0A+void (*__read_mostly lapic_timer_off)(void);=0A=
+void (*__read_mostly lapic_timer_on)(void);=0A =0A static uint64_t =
(*__read_mostly tick_to_ns)(uint64_t) =3D acpi_pm_tick_to_ns;=0A =0A-static=
 void (*pm_idle_save) (void) __read_mostly;=0A+void (*__read_mostly =
pm_idle_save)(void);=0A unsigned int max_cstate __read_mostly =3D =
ACPI_PROCESSOR_MAX_POWER - 1;=0A integer_param("max_cstate", max_cstate);=
=0A static bool_t __read_mostly local_apic_timer_c2_ok;=0A boolean_param("l=
apic_timer_c2_ok", local_apic_timer_c2_ok);=0A =0A-static struct acpi_proce=
ssor_power *__read_mostly processor_powers[NR_CPUS];=0A+struct acpi_process=
or_power *__read_mostly processor_powers[NR_CPUS];=0A =0A struct hw_residen=
cies=0A {=0A@@ -236,12 +237,10 @@ static uint64_t acpi_pm_ticks_elapsed(ui=
=0A         return ((0xFFFFFFFF - t1) + t2 +1);=0A }=0A =0A-static =
uint64_t (*__read_mostly get_tick)(void) =3D get_acpi_pm_tick;=0A+uint64_t =
(*__read_mostly cpuidle_get_tick)(void) =3D get_acpi_pm_tick;=0A static =
uint64_t (*__read_mostly ticks_elapsed)(uint64_t, uint64_t)=0A     =3D =
acpi_pm_ticks_elapsed;=0A =0A-#define MWAIT_ECX_INTERRUPT_BREAK   =
(0x1)=0A-=0A /*=0A  * The bit is set iff cpu use monitor/mwait to enter C =
state=0A  * with this flag set, CPU can be waken up from C state=0A@@ =
-263,7 +262,7 @@ void cpuidle_wakeup_mwait(cpumask_t *mas=0A     cpumask_an=
dnot(mask, mask, &target);=0A }=0A =0A-static void mwait_idle_with_hints(un=
signed long eax, unsigned long ecx)=0A+void mwait_idle_with_hints(unsigned =
int eax, unsigned int ecx)=0A {=0A     unsigned int cpu =3D smp_processor_i=
d();=0A     s_time_t expires =3D per_cpu(timer_deadline, cpu);=0A@@ -334,7 =
+333,7 @@ static struct {=0A     unsigned int count;=0A } c3_cpu_status =
=3D { .lock =3D SPIN_LOCK_UNLOCKED };=0A =0A-static inline void trace_exit_=
reason(u32 *irq_traced)=0A+void trace_exit_reason(u32 *irq_traced)=0A {=0A =
    if ( unlikely(tb_init_done) )=0A     {=0A@@ -354,15 +353,6 @@ static =
inline void trace_exit_reason(u32=0A     }=0A }=0A =0A-/* vcpu is urgent =
if vcpu is polling event channel=0A- *=0A- * if urgent vcpu exists, CPU =
should not enter deep C state=0A- */=0A-static int sched_has_urgent_vcpu(vo=
id)=0A-{=0A-    return atomic_read(&this_cpu(schedule_data).urgent_count);=
=0A-}=0A-=0A /*=0A  * "AAJ72. EOI Transaction May Not be Sent if Software =
Enters Core C6 During =0A  * an Interrupt Service Routine"=0A@@ -388,10 =
+378,11 @@ bool_t errata_c6_eoi_workaround(void)=0A     return (fix_needed =
&& cpu_has_pending_apic_eoi());=0A }=0A =0A-static inline void acpi_update_=
idle_stats(struct acpi_processor_power *power,=0A-                         =
                 struct acpi_processor_cx *cx,=0A-                         =
                 int64_t sleep_ticks)=0A+void update_idle_stats(struct =
acpi_processor_power *power,=0A+                       struct acpi_processo=
r_cx *cx,=0A+                       uint64_t before, uint64_t after)=0A =
{=0A+    int64_t sleep_ticks =3D ticks_elapsed(before, after);=0A     /* =
Interrupts are disabled */=0A =0A     spin_lock(&power->stat_lock);=0A@@ =
-472,19 +463,19 @@ static void acpi_processor_idle(void)=0A         if ( =
cx->type =3D=3D ACPI_STATE_C1 || local_apic_timer_c2_ok )=0A         {=0A  =
           /* Get start time (ticks) */=0A-            t1 =3D get_tick();=
=0A+            t1 =3D cpuidle_get_tick();=0A             /* Trace cpu =
idle entry */=0A             TRACE_4D(TRC_PM_IDLE_ENTRY, cx->idx, t1, exp, =
pred);=0A             /* Invoke C2 */=0A             acpi_idle_do_entry(cx)=
;=0A             /* Get end time (ticks) */=0A-            t2 =3D =
get_tick();=0A+            t2 =3D cpuidle_get_tick();=0A             =
trace_exit_reason(irq_traced);=0A             /* Trace cpu idle exit */=0A =
            TRACE_6D(TRC_PM_IDLE_EXIT, cx->idx, t2,=0A                     =
 irq_traced[0], irq_traced[1], irq_traced[2], irq_traced[3]);=0A           =
  /* Update statistics */=0A-            acpi_update_idle_stats(power, cx, =
ticks_elapsed(t1, t2));=0A+            update_idle_stats(power, cx, t1, =
t2);=0A             /* Re-enable interrupts */=0A             local_irq_ena=
ble();=0A             break;=0A@@ -500,7 +491,7 @@ static void acpi_process=
or_idle(void)=0A         lapic_timer_off();=0A =0A         /* Get start =
time (ticks) */=0A-        t1 =3D get_tick();=0A+        t1 =3D cpuidle_get=
_tick();=0A         /* Trace cpu idle entry */=0A         TRACE_4D(TRC_PM_I=
DLE_ENTRY, cx->idx, t1, exp, pred);=0A =0A@@ -549,7 +540,7 @@ static void =
acpi_processor_idle(void)=0A         }=0A =0A         /* Get end time =
(ticks) */=0A-        t2 =3D get_tick();=0A+        t2 =3D cpuidle_get_tick=
();=0A =0A         /* recovering TSC */=0A         cstate_restore_tsc();=0A=
@@ -559,7 +550,7 @@ static void acpi_processor_idle(void)=0A               =
   irq_traced[0], irq_traced[1], irq_traced[2], irq_traced[3]);=0A =0A     =
    /* Update statistics */=0A-        acpi_update_idle_stats(power, cx, =
ticks_elapsed(t1, t2));=0A+        update_idle_stats(power, cx, t1, =
t2);=0A         /* Re-enable interrupts */=0A         local_irq_enable();=
=0A         /* recovering APIC */=0A@@ -586,7 +577,7 @@ static void =
acpi_processor_idle(void)=0A         cpuidle_current_governor->reflect(powe=
r);=0A }=0A =0A-static void acpi_dead_idle(void)=0A+void acpi_dead_idle(voi=
d)=0A {=0A     struct acpi_processor_power *power;=0A     struct acpi_proce=
ssor_cx *cx;=0A@@ -649,7 +640,7 @@ default_halt:=0A         halt();=0A =
}=0A =0A-static int cpuidle_init_cpu(int cpu)=0A+int cpuidle_init_cpu(unsig=
ned int cpu)=0A {=0A     struct acpi_processor_power *acpi_power;=0A =0A@@ =
-660,7 +651,7 @@ static int cpuidle_init_cpu(int cpu)=0A =0A         if ( =
cpu =3D=3D 0 && boot_cpu_has(X86_FEATURE_NONSTOP_TSC) )=0A         {=0A-   =
         get_tick =3D get_stime_tick;=0A+            cpuidle_get_tick =3D =
get_stime_tick;=0A             ticks_elapsed =3D stime_ticks_elapsed;=0A   =
          tick_to_ns =3D stime_tick_to_ns;=0A         }=0A@@ -685,9 +676,6 =
@@ static int cpuidle_init_cpu(int cpu)=0A     return 0;=0A }=0A =0A-#defin=
e MWAIT_SUBSTATE_MASK (0xf)=0A-#define MWAIT_SUBSTATE_SIZE (4)=0A-=0A =
static int acpi_processor_ffh_cstate_probe(xen_processor_cx_t *cx)=0A {=0A =
    struct cpuinfo_x86 *c =3D &current_cpu_data;=0A@@ -1026,6 +1014,9 @@ =
long set_cx_pminfo(uint32_t cpu, struct =0A     if ( unlikely(!guest_handle=
_okay(power->states, power->count)) )=0A         return -EFAULT;=0A =0A+   =
 if ( pm_idle_save && pm_idle !=3D acpi_processor_idle )=0A+        return =
0;=0A+=0A     print_cx_pminfo(cpu, power);=0A =0A     /* map from acpi_id =
to cpu_id */=0A@@ -1195,7 +1186,12 @@ static struct notifier_block cpu_nfb =
=3D {=0A static int __init cpuidle_presmp_init(void)=0A {=0A     void *cpu =
=3D (void *)(long)smp_processor_id();=0A-    cpu_callback(&cpu_nfb, =
CPU_ONLINE, cpu);=0A+=0A+    if ( !xen_cpuidle )=0A+        return =
0;=0A+=0A+    mwait_idle_init(&cpu_nfb);=0A+    cpu_nfb.notifier_call(&cpu_=
nfb, CPU_ONLINE, cpu);=0A     register_cpu_notifier(&cpu_nfb);=0A     =
return 0;=0A }=0A--- a/xen/arch/x86/cpu/Makefile=0A+++ b/xen/arch/x86/cpu/M=
akefile=0A@@ -5,6 +5,7 @@ obj-y +=3D amd.o=0A obj-y +=3D common.o=0A obj-y =
+=3D intel.o=0A obj-y +=3D intel_cacheinfo.o=0A+obj-y +=3D mwait-idle.o=0A =
=0A # Keeping around for VIA support (JBeulich)=0A # obj-$(x86_32) +=3D =
centaur.o=0A--- /dev/null=0A+++ b/xen/arch/x86/cpu/mwait-idle.c=0A@@ -0,0 =
+1,513 @@=0A+/*=0A+ * mwait_idle.c - native hardware idle loop for modern =
processors=0A+ *=0A+ * Copyright (c) 2010, Intel Corporation.=0A+ * Len =
Brown <len.brown@intel.com>=0A+ *=0A+ * This program is free software; you =
can redistribute it and/or modify it=0A+ * under the terms and conditions =
of the GNU General Public License,=0A+ * version 2, as published by the =
Free Software Foundation.=0A+ *=0A+ * This program is distributed in the =
hope it will be useful, but WITHOUT=0A+ * ANY WARRANTY; without even the =
implied warranty of MERCHANTABILITY or=0A+ * FITNESS FOR A PARTICULAR =
PURPOSE.  See the GNU General Public License for=0A+ * more details.=0A+ =
*=0A+ * You should have received a copy of the GNU General Public License =
along with=0A+ * this program; if not, write to the Free Software =
Foundation, Inc.,=0A+ * 51 Franklin St - Fifth Floor, Boston, MA 02110-1301=
 USA.=0A+ */=0A+=0A+/*=0A+ * mwait_idle is a cpuidle driver that loads on =
specific processors=0A+ * in lieu of the legacy ACPI processor_idle =
driver.  The intent is to=0A+ * make Linux more efficient on these =
processors, as mwait_idle knows=0A+ * more than ACPI, as well as make =
Linux more immune to ACPI BIOS bugs.=0A+ */=0A+=0A+/*=0A+ * Design =
Assumptions=0A+ *=0A+ * All CPUs have same idle states as boot CPU=0A+ =
*=0A+ * Chipset BM_STS (bus master status) bit is a NOP=0A+ *	for =
preventing entry into deep C-states=0A+ */=0A+=0A+/*=0A+ * Known limitation=
s=0A+ *=0A+ * The driver currently initializes for_each_online_cpu() upon =
load.=0A+ * It it unaware of subsequent processors hot-added to the =
system.=0A+ * This means that if you boot with maxcpus=3Dn and later =
online=0A+ * processors above n, those processors will use C1 only.=0A+ =
*=0A+ * ACPI has a .suspend hack to turn off deep C-states during =
suspend=0A+ * to avoid complications with the lapic timer workaround.=0A+ =
* Have not seen issues with suspend, but may need same workaround =
here.=0A+ */=0A+=0A+/* un-comment DEBUG to enable pr_debug() statements =
*/=0A+#define DEBUG=0A+=0A+#include <xen/lib.h>=0A+#include <xen/cpu.h>=0A+=
#include <xen/init.h>=0A+#include <xen/softirq.h>=0A+#include <xen/trace.h>=
=0A+#include <asm/cpuidle.h>=0A+#include <asm/mwait.h>=0A+#include =
<asm/msr.h>=0A+#include <acpi/cpufreq/cpufreq.h>=0A+=0A+#define MWAIT_IDLE_=
VERSION "0.4"=0A+#undef PREFIX=0A+#define PREFIX "mwait-idle: "=0A+=0A+#ifd=
ef DEBUG=0A+# define pr_debug(fmt...) printk(KERN_DEBUG fmt)=0A+#else=0A+# =
define pr_debug(fmt...)=0A+#endif=0A+=0A+static __initdata bool_t =
no_mwait_idle;=0A+invbool_param("mwait-idle", no_mwait_idle);=0A+=0A+static=
 unsigned int mwait_substates;=0A+=0A+#define LAPIC_TIMER_ALWAYS_RELIABLE =
0xFFFFFFFF=0A+/* Reliable LAPIC Timer States, bit 1 for C1 etc. Default to =
only C1. */=0A+static unsigned int lapic_timer_reliable_states =3D (1 << =
1);=0A+=0A+struct idle_cpu {=0A+	const struct cpuidle_state =
*state_table;=0A+=0A+	/*=0A+	 * Hardware C-state auto-demotion may not =
always be optimal.=0A+	 * Indicate which enable bits to clear here.=0A+	=
 */=0A+	unsigned long auto_demotion_disable_flags;=0A+};=0A+=0A+static =
const struct idle_cpu *icpu;=0A+=0A+static const struct cpuidle_state =
{=0A+	char		name[16];=0A+	unsigned int	flags;=0A+	=
unsigned int	exit_latency; /* in US */=0A+	int		power_usage=
; /* in mW */=0A+	unsigned int	target_residency; /* in US */=0A+} =
*cpuidle_state_table;=0A+=0A+/*=0A+ * Set this flag for states where the =
HW flushes the TLB for us=0A+ * and so we don't need cross-calls to keep =
it consistent.=0A+ * If this flag is set, SW flushes the TLB, so even if =
the=0A+ * HW doesn't do the flushing, this flag is safe to use.=0A+ =
*/=0A+#define CPUIDLE_FLAG_TLB_FLUSHED	0x10000=0A+=0A+/*=0A+ * States are =
indexed by the cstate number,=0A+ * which is also the index into the MWAIT =
hint array.=0A+ * Thus C0 is a dummy.=0A+ */=0A+static const struct =
cpuidle_state nehalem_cstates[MWAIT_MAX_NUM_CSTATES] =3D {=0A+	{ /* MWAIT =
C0 */ },=0A+	{ /* MWAIT C1 */=0A+		.name =3D "C1-NHM",=0A+		=
.exit_latency =3D 3,=0A+		.target_residency =3D 6,=0A+	=
},=0A+	{ /* MWAIT C2 */=0A+		.name =3D "C3-NHM",=0A+		=
.flags =3D CPUIDLE_FLAG_TLB_FLUSHED,=0A+		.exit_latency =3D =
20,=0A+		.target_residency =3D 80,=0A+	},=0A+	{ /* MWAIT C3 =
*/=0A+		.name =3D "C6-NHM",=0A+		.flags =3D CPUIDLE_FLAG_TLB=
_FLUSHED,=0A+		.exit_latency =3D 200,=0A+		.target_res=
idency =3D 800,=0A+	}=0A+};=0A+=0A+static const struct cpuidle_state =
snb_cstates[MWAIT_MAX_NUM_CSTATES] =3D {=0A+	{ /* MWAIT C0 */ },=0A+	{ =
/* MWAIT C1 */=0A+		.name =3D "C1-SNB",=0A+		.exit_laten=
cy =3D 1,=0A+		.target_residency =3D 1,=0A+	},=0A+	{ /* MWAIT =
C2 */=0A+		.name =3D "C3-SNB",=0A+		.flags =3D =
CPUIDLE_FLAG_TLB_FLUSHED,=0A+		.exit_latency =3D 80,=0A+		=
.target_residency =3D 211,=0A+	},=0A+	{ /* MWAIT C3 */=0A+		=
.name =3D "C6-SNB",=0A+		.flags =3D CPUIDLE_FLAG_TLB_FLUSHED,=0A+	=
	.exit_latency =3D 104,=0A+		.target_residency =3D =
345,=0A+	},=0A+	{ /* MWAIT C4 */=0A+		.name =3D =
"C7-SNB",=0A+		.flags =3D CPUIDLE_FLAG_TLB_FLUSHED,=0A+		=
.exit_latency =3D 109,=0A+		.target_residency =3D 345,=0A+	=
}=0A+};=0A+=0A+static const struct cpuidle_state ivb_cstates[MWAIT_MAX_NUM_=
CSTATES] =3D {=0A+	{ /* MWAIT C0 */ },=0A+	{ /* MWAIT C1 */=0A+		=
.name =3D "C1-IVB",=0A+		.exit_latency =3D 1,=0A+		=
.target_residency =3D 1,=0A+	},=0A+	{ /* MWAIT C2 */=0A+		=
.name =3D "C3-IVB",=0A+		.flags =3D CPUIDLE_FLAG_TLB_FLUSHED,=0A+	=
	.exit_latency =3D 59,=0A+		.target_residency =3D =
156,=0A+	},=0A+	{ /* MWAIT C3 */=0A+		.name =3D =
"C6-IVB",=0A+		.flags =3D CPUIDLE_FLAG_TLB_FLUSHED,=0A+		=
.exit_latency =3D 80,=0A+		.target_residency =3D 300,=0A+	=
},=0A+	{ /* MWAIT C4 */=0A+		.name =3D "C7-IVB",=0A+		=
.flags =3D CPUIDLE_FLAG_TLB_FLUSHED,=0A+		.exit_latency =3D =
87,=0A+		.target_residency =3D 300,=0A+	}=0A+};=0A+=0A+static =
const struct cpuidle_state atom_cstates[MWAIT_MAX_NUM_CSTATES] =3D {=0A+	=
{ /* MWAIT C0 */ },=0A+	{ /* MWAIT C1 */=0A+		.name =3D =
"C1-ATM",=0A+		.exit_latency =3D 1,=0A+		.target_res=
idency =3D 4,=0A+	},=0A+	{ /* MWAIT C2 */=0A+		.name =3D =
"C2-ATM",=0A+		.exit_latency =3D 20,=0A+		.target_res=
idency =3D 80,=0A+	},=0A+	{ /* MWAIT C3 */ },=0A+	{ /* MWAIT C4 =
*/=0A+		.name =3D "C4-ATM",=0A+		.flags =3D CPUIDLE_FLAG_TLB=
_FLUSHED,=0A+		.exit_latency =3D 100,=0A+		.target_res=
idency =3D 400,=0A+	},=0A+	{ /* MWAIT C5 */ },=0A+	{ /* MWAIT C6 =
*/=0A+		.name =3D "C6-ATM",=0A+		.flags =3D CPUIDLE_FLAG_TLB=
_FLUSHED,=0A+		.exit_latency =3D 140,=0A+		.target_res=
idency =3D 560,=0A+	}=0A+};=0A+=0A+static u32 get_driver_data(unsigned =
int cstate)=0A+{=0A+	static const u32 driver_data[] =3D {=0A+		=
[1] /* MWAIT C1 */ =3D 0x00,=0A+		[2] /* MWAIT C2 */ =3D =
0x10,=0A+		[3] /* MWAIT C3 */ =3D 0x20,=0A+		=
[4] /* MWAIT C4 */ =3D 0x30,=0A+		[5] /* MWAIT C5 */ =3D =
0x40,=0A+		[6] /* MWAIT C6 */ =3D 0x52,=0A+	};=0A+=0A+	=
return driver_data[cstate < ARRAY_SIZE(driver_data) ? cstate : 0];=0A+}=0A+=
=0A+static void mwait_idle(void)=0A+{=0A+	unsigned int cpu =3D =
smp_processor_id();=0A+	struct acpi_processor_power *power =3D processor_po=
wers[cpu];=0A+	struct acpi_processor_cx *cx =3D NULL;=0A+	unsigned =
int eax, next_state, cstate;=0A+	u64 before, after;=0A+	u32 exp =
=3D 0, pred =3D 0, irq_traced[4] =3D { 0 };=0A+=0A+	if (max_cstate > 0 =
&& power && !sched_has_urgent_vcpu() &&=0A+	    (next_state =3D =
cpuidle_current_governor->select(power)) > 0) {=0A+		do {=0A+	=
		cx =3D &power->states[next_state];=0A+		} while =
(cx->type > max_cstate && --next_state);=0A+		if (!next_state)=0A=
+			cx =3D NULL;=0A+		menu_get_trace_data=
(&exp, &pred);=0A+	}=0A+	if (!cx) {=0A+		if (pm_idle_save)=
=0A+			pm_idle_save();=0A+		else=0A+		=
	safe_halt();=0A+		return;=0A+	}=0A+=0A+	=
cpufreq_dbs_timer_suspend();=0A+=0A+	sched_tick_suspend();=0A+	/* =
sched_tick_suspend() can raise TIMER_SOFTIRQ. Process it now. */=0A+	=
process_pending_softirqs();=0A+=0A+	/* Interrupts must be disabled for =
C2 and higher transitions. */=0A+	local_irq_disable();=0A+=0A+	if =
(!cpu_is_haltable(cpu)) {=0A+		local_irq_enable();=0A+		=
sched_tick_resume();=0A+		cpufreq_dbs_timer_resume();=0A+		=
return;=0A+	}=0A+=0A+	power->last_state =3D cx;=0A+	eax =3D =
cx->address;=0A+	cstate =3D ((eax >> MWAIT_SUBSTATE_SIZE) & =
MWAIT_CSTATE_MASK) + 1;=0A+=0A+#if 0 /* XXX Can we/do we need to do =
something similar on Xen? */=0A+	/*=0A+	 * leave_mm() to avoid =
costly and often unnecessary wakeups=0A+	 * for flushing the user =
TLB's associated with the active mm.=0A+	 */=0A+	if (cpuidle_state_t=
able[].flags & CPUIDLE_FLAG_TLB_FLUSHED)=0A+		leave_mm(cpu);=0A+#=
endif=0A+=0A+	if (!(lapic_timer_reliable_states & (1 << cstate)))=0A+		=
lapic_timer_off();=0A+=0A+	before =3D cpuidle_get_tick();=0A+	=
TRACE_4D(TRC_PM_IDLE_ENTRY, cx->idx, before, exp, pred);=0A+=0A+	if =
(cpu_is_haltable(cpu))=0A+		mwait_idle_with_hints(eax, =
MWAIT_ECX_INTERRUPT_BREAK);=0A+=0A+	after =3D cpuidle_get_tick();=0A+=
=0A+	cstate_restore_tsc();=0A+	trace_exit_reason(irq_traced);=0A+	=
TRACE_6D(TRC_PM_IDLE_EXIT, cx->idx, after,=0A+		irq_traced[0], =
irq_traced[1], irq_traced[2], irq_traced[3]);=0A+=0A+	update_idle_stats(p=
ower, cx, before, after);=0A+	local_irq_enable();=0A+=0A+	if =
(!(lapic_timer_reliable_states & (1 << cstate)))=0A+		lapic_timer=
_on();=0A+=0A+	/* Now back in C0. */=0A+	power->last_state =3D =
&power->states[0];=0A+=0A+	sched_tick_resume();=0A+	cpufreq_dbs=
_timer_resume();=0A+=0A+	if ( cpuidle_current_governor->reflect =
)=0A+		cpuidle_current_governor->reflect(power);=0A+}=0A+=0A+stati=
c void auto_demotion_disable(void *dummy)=0A+{=0A+	u64 msr_bits;=0A+=
=0A+	rdmsrl(MSR_NHM_SNB_PKG_CST_CFG_CTL, msr_bits);=0A+	msr_bits =
&=3D ~(icpu->auto_demotion_disable_flags);=0A+	wrmsrl(MSR_NHM_SNB_PKG_CST_=
CFG_CTL, msr_bits);=0A+}=0A+=0A+static const struct idle_cpu idle_cpu_nehal=
em =3D {=0A+	.state_table =3D nehalem_cstates,=0A+	.auto_demotion_disa=
ble_flags =3D NHM_C1_AUTO_DEMOTE | NHM_C3_AUTO_DEMOTE,=0A+};=0A+=0A+static =
const struct idle_cpu idle_cpu_atom =3D {=0A+	.state_table =3D atom_cstat=
es,=0A+};=0A+=0A+static const struct idle_cpu idle_cpu_lincroft =3D {=0A+	=
.state_table =3D atom_cstates,=0A+	.auto_demotion_disable_flags =3D =
ATM_LNC_C6_AUTO_DEMOTE,=0A+};=0A+=0A+static const struct idle_cpu =
idle_cpu_snb =3D {=0A+	.state_table =3D snb_cstates,=0A+};=0A+=0A+static =
const struct idle_cpu idle_cpu_ivb =3D {=0A+	.state_table =3D ivb_cstate=
s,=0A+};=0A+=0A+#define ICPU(model, cpu) { 6, model, &idle_cpu_##cpu =
}=0A+=0A+static struct intel_idle_id {=0A+	unsigned int family, =
model;=0A+	const struct idle_cpu *data;=0A+} intel_idle_ids[] =
__initdata =3D {=0A+	ICPU(0x1a, nehalem),=0A+	ICPU(0x1e, =
nehalem),=0A+	ICPU(0x1f, nehalem),=0A+	ICPU(0x25, nehalem),=0A+	=
ICPU(0x2c, nehalem),=0A+	ICPU(0x2e, nehalem),=0A+	ICPU(0x2f, =
nehalem),=0A+	ICPU(0x1c, atom),=0A+	ICPU(0x26, lincroft),=0A+	=
ICPU(0x2a, snb),=0A+	ICPU(0x2d, snb),=0A+	ICPU(0x3a, ivb),=0A+	=
{}=0A+};=0A+=0A+static int __init mwait_idle_probe(void)=0A+{=0A+	=
unsigned int eax, ebx, ecx;=0A+	const struct intel_idle_id *id;=0A+=0A+	if =
(boot_cpu_data.x86_vendor !=3D X86_VENDOR_INTEL ||=0A+	    !boot_cpu_has(X=
86_FEATURE_MWAIT) ||=0A+	    boot_cpu_data.cpuid_level < CPUID_MWAIT=
_LEAF)=0A+		return -ENODEV;=0A+=0A+	for (id =3D intel_idle_ids;=
 id->family; ++id)=0A+		if (id->family =3D=3D boot_cpu_data.x86 =
&&=0A+		    id->model =3D=3D boot_cpu_data.x86_model)=0A+		=
	break;=0A+	if (!id->family) {=0A+		pr_debug(PREFIX =
"does not run on family %d model %d\n",=0A+			 boot_cpu_d=
ata.x86, boot_cpu_data.x86_model);=0A+		return -ENODEV;=0A+	=
}=0A+=0A+	cpuid(CPUID_MWAIT_LEAF, &eax, &ebx, &ecx, &mwait_substates)=
;=0A+=0A+	if (!(ecx & CPUID5_ECX_EXTENSIONS_SUPPORTED) ||=0A+	   =
 !(ecx & CPUID5_ECX_INTERRUPT_BREAK) ||=0A+	    !mwait_substates)=0A+	=
	return -ENODEV;=0A+=0A+	if (!max_cstate || no_mwait_idle) {=0A+		=
pr_debug(PREFIX "disabled\n");=0A+		return -EPERM;=0A+	=
}=0A+=0A+	pr_debug(PREFIX "MWAIT substates: %#x\n", mwait_substates);=
=0A+=0A+	icpu =3D id->data;=0A+	cpuidle_state_table =3D icpu->state=
_table;=0A+=0A+	if (boot_cpu_has(X86_FEATURE_ARAT))=0A+		lapic_timer=
_reliable_states =3D LAPIC_TIMER_ALWAYS_RELIABLE;=0A+=0A+	pr_debug(PR=
EFIX "v" MWAIT_IDLE_VERSION " model %#x\n",=0A+		 boot_cpu_data.x86_=
model);=0A+=0A+	pr_debug(PREFIX "lapic_timer_reliable_states %#x\n",=0A+	=
	 lapic_timer_reliable_states);=0A+	return 0;=0A+}=0A+=0A+stati=
c int mwait_idle_cpu_init(struct notifier_block *nfb,=0A+			=
       unsigned long action, void *hcpu)=0A+{=0A+	unsigned int cpu =
=3D (unsigned long)hcpu, cstate;=0A+	struct acpi_processor_power *dev =
=3D processor_powers[cpu];=0A+=0A+	switch (action) {=0A+	default:=0A=
+		return NOTIFY_DONE;=0A+=0A+	case CPU_UP_PREPARE:=0A+	=
	cpuidle_init_cpu(cpu);=0A+		return NOTIFY_DONE;=0A+=0A+=
	case CPU_ONLINE:=0A+		if (!dev)=0A+			=
return NOTIFY_DONE;=0A+		break;=0A+	}=0A+=0A+	dev->count =
=3D 1;=0A+=0A+	for (cstate =3D 1; cstate < MWAIT_MAX_NUM_CSTATES; =
++cstate) {=0A+		unsigned int num_substates;=0A+		struct =
acpi_processor_cx *cx;=0A+=0A+		if (cstate > max_cstate) {=0A+		=
	printk(PREFIX "max C-state %u reached\n", max_cstate);=0A+		=
	break;=0A+		}=0A+=0A+		/* Does the state =
exist in CPUID.MWAIT? */=0A+		num_substates =3D (mwait_substates =
>> (cstate * 4))=0A+			& MWAIT_SUBSTATE_MASK;=0A+		=
if (!num_substates)=0A+			continue;=0A+		/* Is the =
state not enabled? */=0A+		if (!cpuidle_state_table[cstate].ta=
rget_residency) {=0A+			/* does the driver not know about =
the state? */=0A+			if (!pm_idle_save && !*cpuidle_stat=
e_table[cstate].name)=0A+				pr_debug(PREFIX =
"unaware of family %#x model %#x MWAIT %u\n",=0A+				=
	 boot_cpu_data.x86,=0A+					 boot_cpu_d=
ata.x86_model, cstate);=0A+			continue;=0A+		=
}=0A+=0A+		if (dev->count >=3D ACPI_PROCESSOR_MAX_POWER) =
{=0A+			printk(PREFIX "max C-state count of %u reached\n",=
=0A+			       ACPI_PROCESSOR_MAX_POWER);=0A+			=
break;=0A+		}=0A+=0A+		if (cstate > 2 && =
!boot_cpu_has(X86_FEATURE_NONSTOP_TSC)) {=0A+			if =
(pm_idle_save)=0A+				continue;=0A+			=
setup_clear_cpu_cap(X86_FEATURE_TSC_RELIABLE);=0A+		}=0A+=0A+	=
	cx =3D dev->states + dev->count;=0A+		cx->type =3D =
cstate;=0A+		cx->address =3D get_driver_data(cstate);=0A+		=
cx->entry_method =3D ACPI_CSTATE_EM_FFH;=0A+		cx->power =3D =
cpuidle_state_table[cstate].power_usage;=0A+		cx->latency =3D =
cpuidle_state_table[cstate].exit_latency;=0A+		cx->target_residenc=
y =3D=0A+			cpuidle_state_table[cstate].target_residenc=
y;=0A+=0A+		dev->count++;=0A+	}=0A+=0A+	if =
(icpu->auto_demotion_disable_flags)=0A+		on_selected_cpus(cpumask_of=
(cpu), auto_demotion_disable, NULL, 1);=0A+=0A+	return NOTIFY_DONE;=0A+}=0A=
+=0A+int __init mwait_idle_init(struct notifier_block *nfb)=0A+{=0A+	=
int err;=0A+=0A+	if (pm_idle_save)=0A+		return -ENODEV;=0A+=
=0A+	err =3D mwait_idle_probe();=0A+	if (!err) {=0A+		nfb->notifi=
er_call =3D mwait_idle_cpu_init;=0A+		mwait_idle_cpu_init(nfb, =
CPU_UP_PREPARE, NULL);=0A+=0A+		pm_idle_save =3D pm_idle;=0A+		=
pm_idle =3D mwait_idle;=0A+		dead_idle =3D acpi_dead_idle;=0A+	=
}=0A+=0A+	return err;=0A+}=0A--- /dev/null=0A+++ b/xen/include/asm-x8=
6/cpuidle.h=0A@@ -0,0 +1,35 @@=0A+#ifndef __ASM_X86_CPUIDLE_H__=0A+#define =
__ASM_X86_CPUIDLE_H__=0A+=0A+#include <xen/cpuidle.h>=0A+#include =
<xen/notifier.h>=0A+#include <xen/sched.h>=0A+#include <xen/sched-if.h>=0A+=
=0A+extern struct acpi_processor_power *processor_powers[];=0A+=0A+extern =
void (*pm_idle_save)(void);=0A+=0A+extern void (*lapic_timer_off)(void);=0A=
+extern void (*lapic_timer_on)(void);=0A+=0A+extern uint64_t (*cpuidle_get_=
tick)(void);=0A+=0A+int mwait_idle_init(struct notifier_block *);=0A+int =
cpuidle_init_cpu(unsigned int cpu);=0A+void acpi_dead_idle(void);=0A+void =
trace_exit_reason(u32 *irq_traced);=0A+void update_idle_stats(struct =
acpi_processor_power *,=0A+                       struct acpi_processor_cx =
*, uint64_t, uint64_t);=0A+=0A+/*=0A+ * vcpu is urgent if vcpu is polling =
event channel=0A+ *=0A+ * if urgent vcpu exists, CPU should not enter deep =
C state=0A+ */=0A+static inline int sched_has_urgent_vcpu(void)=0A+{=0A+   =
 return atomic_read(&this_cpu(schedule_data).urgent_count);=0A+}=0A+=0A+#en=
dif /* __X86_ASM_CPUIDLE_H__ */=0A--- a/xen/include/asm-x86/msr-index.h=0A+=
++ b/xen/include/asm-x86/msr-index.h=0A@@ -36,6 +36,11 @@=0A #define =
MSR_IA32_PERFCTR1		0x000000c2=0A #define MSR_FSB_FREQ		=
	0x000000cd=0A =0A+#define MSR_NHM_SNB_PKG_CST_CFG_CTL	0x000000e2=
=0A+#define NHM_C3_AUTO_DEMOTE		(1UL << 25)=0A+#define NHM_C1_AUTO_=
DEMOTE		(1UL << 26)=0A+#define ATM_LNC_C6_AUTO_DEMOTE		=
(1UL << 25)=0A+=0A #define MSR_MTRRcap			0x000000fe=0A =
#define MSR_IA32_BBL_CR_CTL		0x00000119=0A =0A--- /dev/null=0A++=
+ b/xen/include/asm-x86/mwait.h=0A@@ -0,0 +1,17 @@=0A+#ifndef __ASM_X86_MWA=
IT_H__=0A+#define __ASM_X86_MWAIT_H__=0A+=0A+#define MWAIT_SUBSTATE_MASK	=
	0xf=0A+#define MWAIT_CSTATE_MASK		0xf=0A+#define =
MWAIT_SUBSTATE_SIZE		4=0A+#define MWAIT_MAX_NUM_CSTATES		=
8=0A+=0A+#define CPUID_MWAIT_LEAF		5=0A+#define CPUID5_ECX_EXT=
ENSIONS_SUPPORTED 0x1=0A+#define CPUID5_ECX_INTERRUPT_BREAK	0x2=0A+=0A+=
#define MWAIT_ECX_INTERRUPT_BREAK	0x1=0A+=0A+void mwait_idle_with_hin=
ts(unsigned int eax, unsigned int ecx);=0A+=0A+#endif /* __ASM_X86_MWAIT_H_=
_ */=0A
--=__Part1F2E1E3F.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

--=__Part1F2E1E3F.1__=--


From xen-devel-bounces@lists.xen.org Fri Sep 21 10:41:24 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Sep 2012 10:41: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 1TF0fQ-00012n-5J; Fri, 21 Sep 2012 10:41:04 +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 1TF0fO-00012T-EB
	for xen-devel@lists.xen.org; Fri, 21 Sep 2012 10:41:02 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1348224052!4904130!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8501 invoked from network); 21 Sep 2012 10:40:52 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-15.tower-27.messagelabs.com with SMTP;
	21 Sep 2012 10:40:52 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 21 Sep 2012 11:40:51 +0100
Message-Id: <505C604F020000780009CEB9@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 21 Sep 2012 11:40: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="=__Part1F2E1E3F.1__="
Cc: Len Brown <lenb@kernel.org>
Subject: [Xen-devel] [PATCH 2/2] x86: introduce MWAIT-based,
 ACPI-less CPU idle 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

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.

--=__Part1F2E1E3F.1__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

This is a port of Linux'es intel-idle driver serving the same purpose.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/docs/misc/xen-command-line.markdown
+++ b/docs/misc/xen-command-line.markdown
@@ -620,6 +620,14 @@ limit is ignored by Xen.
=20
 Specify if the MMConfig space should be enabled.
=20
+### mwait-idle
+> `=3D <boolean>`
+
+> Default: `true`
+
+Use the MWAIT idle driver (with model specific C-state knowledge) instead
+of the ACPI based one.
+
 ### nmi
 > `=3D ignore | dom0 | fatal`
=20
--- a/xen/arch/x86/acpi/cpu_idle.c
+++ b/xen/arch/x86/acpi/cpu_idle.c
@@ -39,7 +39,6 @@
 #include <xen/smp.h>
 #include <xen/guest_access.h>
 #include <xen/keyhandler.h>
-#include <xen/cpuidle.h>
 #include <xen/trace.h>
 #include <xen/sched-if.h>
 #include <xen/irq.h>
@@ -54,6 +53,8 @@
 #include <public/sysctl.h>
 #include <acpi/cpufreq/cpufreq.h>
 #include <asm/apic.h>
+#include <asm/cpuidle.h>
+#include <asm/mwait.h>
 #include <xen/notifier.h>
 #include <xen/cpu.h>
=20
@@ -70,18 +71,18 @@
 #define GET_CC7_RES(val)  GET_HW_RES_IN_NS(0x3FE, val) /* SNB only */
=20
 static void lapic_timer_nop(void) { }
-static void (*lapic_timer_off)(void);
-static void (*lapic_timer_on)(void);
+void (*__read_mostly lapic_timer_off)(void);
+void (*__read_mostly lapic_timer_on)(void);
=20
 static uint64_t (*__read_mostly tick_to_ns)(uint64_t) =3D acpi_pm_tick_to_=
ns;
=20
-static void (*pm_idle_save) (void) __read_mostly;
+void (*__read_mostly pm_idle_save)(void);
 unsigned int max_cstate __read_mostly =3D ACPI_PROCESSOR_MAX_POWER - 1;
 integer_param("max_cstate", max_cstate);
 static bool_t __read_mostly local_apic_timer_c2_ok;
 boolean_param("lapic_timer_c2_ok", local_apic_timer_c2_ok);
=20
-static struct acpi_processor_power *__read_mostly processor_powers[NR_CPUS=
];
+struct acpi_processor_power *__read_mostly processor_powers[NR_CPUS];
=20
 struct hw_residencies
 {
@@ -236,12 +237,10 @@ static uint64_t acpi_pm_ticks_elapsed(ui
         return ((0xFFFFFFFF - t1) + t2 +1);
 }
=20
-static uint64_t (*__read_mostly get_tick)(void) =3D get_acpi_pm_tick;
+uint64_t (*__read_mostly cpuidle_get_tick)(void) =3D get_acpi_pm_tick;
 static uint64_t (*__read_mostly ticks_elapsed)(uint64_t, uint64_t)
     =3D acpi_pm_ticks_elapsed;
=20
-#define MWAIT_ECX_INTERRUPT_BREAK   (0x1)
-
 /*
  * The bit is set iff cpu use monitor/mwait to enter C state
  * with this flag set, CPU can be waken up from C state
@@ -263,7 +262,7 @@ void cpuidle_wakeup_mwait(cpumask_t *mas
     cpumask_andnot(mask, mask, &target);
 }
=20
-static void mwait_idle_with_hints(unsigned long eax, unsigned long ecx)
+void mwait_idle_with_hints(unsigned int eax, unsigned int ecx)
 {
     unsigned int cpu =3D smp_processor_id();
     s_time_t expires =3D per_cpu(timer_deadline, cpu);
@@ -334,7 +333,7 @@ static struct {
     unsigned int count;
 } c3_cpu_status =3D { .lock =3D SPIN_LOCK_UNLOCKED };
=20
-static inline void trace_exit_reason(u32 *irq_traced)
+void trace_exit_reason(u32 *irq_traced)
 {
     if ( unlikely(tb_init_done) )
     {
@@ -354,15 +353,6 @@ static inline void trace_exit_reason(u32
     }
 }
=20
-/* vcpu is urgent if vcpu is polling event channel
- *
- * if urgent vcpu exists, CPU should not enter deep C state
- */
-static int sched_has_urgent_vcpu(void)
-{
-    return atomic_read(&this_cpu(schedule_data).urgent_count);
-}
-
 /*
  * "AAJ72. EOI Transaction May Not be Sent if Software Enters Core C6 =
During=20
  * an Interrupt Service Routine"
@@ -388,10 +378,11 @@ bool_t errata_c6_eoi_workaround(void)
     return (fix_needed && cpu_has_pending_apic_eoi());
 }
=20
-static inline void acpi_update_idle_stats(struct acpi_processor_power =
*power,
-                                          struct acpi_processor_cx *cx,
-                                          int64_t sleep_ticks)
+void update_idle_stats(struct acpi_processor_power *power,
+                       struct acpi_processor_cx *cx,
+                       uint64_t before, uint64_t after)
 {
+    int64_t sleep_ticks =3D ticks_elapsed(before, after);
     /* Interrupts are disabled */
=20
     spin_lock(&power->stat_lock);
@@ -472,19 +463,19 @@ static void acpi_processor_idle(void)
         if ( cx->type =3D=3D ACPI_STATE_C1 || local_apic_timer_c2_ok )
         {
             /* Get start time (ticks) */
-            t1 =3D get_tick();
+            t1 =3D cpuidle_get_tick();
             /* Trace cpu idle entry */
             TRACE_4D(TRC_PM_IDLE_ENTRY, cx->idx, t1, exp, pred);
             /* Invoke C2 */
             acpi_idle_do_entry(cx);
             /* Get end time (ticks) */
-            t2 =3D get_tick();
+            t2 =3D cpuidle_get_tick();
             trace_exit_reason(irq_traced);
             /* 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));
+            update_idle_stats(power, cx, t1, t2);
             /* Re-enable interrupts */
             local_irq_enable();
             break;
@@ -500,7 +491,7 @@ static void acpi_processor_idle(void)
         lapic_timer_off();
=20
         /* Get start time (ticks) */
-        t1 =3D get_tick();
+        t1 =3D cpuidle_get_tick();
         /* Trace cpu idle entry */
         TRACE_4D(TRC_PM_IDLE_ENTRY, cx->idx, t1, exp, pred);
=20
@@ -549,7 +540,7 @@ static void acpi_processor_idle(void)
         }
=20
         /* Get end time (ticks) */
-        t2 =3D get_tick();
+        t2 =3D cpuidle_get_tick();
=20
         /* recovering TSC */
         cstate_restore_tsc();
@@ -559,7 +550,7 @@ static void acpi_processor_idle(void)
                  irq_traced[0], irq_traced[1], irq_traced[2], irq_traced[3=
]);
=20
         /* Update statistics */
-        acpi_update_idle_stats(power, cx, ticks_elapsed(t1, t2));
+        update_idle_stats(power, cx, t1, t2);
         /* Re-enable interrupts */
         local_irq_enable();
         /* recovering APIC */
@@ -586,7 +577,7 @@ static void acpi_processor_idle(void)
         cpuidle_current_governor->reflect(power);
 }
=20
-static void acpi_dead_idle(void)
+void acpi_dead_idle(void)
 {
     struct acpi_processor_power *power;
     struct acpi_processor_cx *cx;
@@ -649,7 +640,7 @@ default_halt:
         halt();
 }
=20
-static int cpuidle_init_cpu(int cpu)
+int cpuidle_init_cpu(unsigned int cpu)
 {
     struct acpi_processor_power *acpi_power;
=20
@@ -660,7 +651,7 @@ static int cpuidle_init_cpu(int cpu)
=20
         if ( cpu =3D=3D 0 && boot_cpu_has(X86_FEATURE_NONSTOP_TSC) )
         {
-            get_tick =3D get_stime_tick;
+            cpuidle_get_tick =3D get_stime_tick;
             ticks_elapsed =3D stime_ticks_elapsed;
             tick_to_ns =3D stime_tick_to_ns;
         }
@@ -685,9 +676,6 @@ static int cpuidle_init_cpu(int cpu)
     return 0;
 }
=20
-#define MWAIT_SUBSTATE_MASK (0xf)
-#define MWAIT_SUBSTATE_SIZE (4)
-
 static int acpi_processor_ffh_cstate_probe(xen_processor_cx_t *cx)
 {
     struct cpuinfo_x86 *c =3D &current_cpu_data;
@@ -1026,6 +1014,9 @@ long set_cx_pminfo(uint32_t cpu, struct=20
     if ( unlikely(!guest_handle_okay(power->states, power->count)) )
         return -EFAULT;
=20
+    if ( pm_idle_save && pm_idle !=3D acpi_processor_idle )
+        return 0;
+
     print_cx_pminfo(cpu, power);
=20
     /* map from acpi_id to cpu_id */
@@ -1195,7 +1186,12 @@ static struct notifier_block cpu_nfb =3D {
 static int __init cpuidle_presmp_init(void)
 {
     void *cpu =3D (void *)(long)smp_processor_id();
-    cpu_callback(&cpu_nfb, CPU_ONLINE, cpu);
+
+    if ( !xen_cpuidle )
+        return 0;
+
+    mwait_idle_init(&cpu_nfb);
+    cpu_nfb.notifier_call(&cpu_nfb, CPU_ONLINE, cpu);
     register_cpu_notifier(&cpu_nfb);
     return 0;
 }
--- a/xen/arch/x86/cpu/Makefile
+++ b/xen/arch/x86/cpu/Makefile
@@ -5,6 +5,7 @@ obj-y +=3D amd.o
 obj-y +=3D common.o
 obj-y +=3D intel.o
 obj-y +=3D intel_cacheinfo.o
+obj-y +=3D mwait-idle.o
=20
 # Keeping around for VIA support (JBeulich)
 # obj-$(x86_32) +=3D centaur.o
--- /dev/null
+++ b/xen/arch/x86/cpu/mwait-idle.c
@@ -0,0 +1,513 @@
+/*
+ * mwait_idle.c - native hardware idle loop for modern processors
+ *
+ * Copyright (c) 2010, Intel Corporation.
+ * Len Brown <len.brown@intel.com>
+ *
+ * This program is free software; you can redistribute it and/or modify =
it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License =
for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License =
along with
+ * this program; if not, write to the Free Software Foundation, Inc.,
+ * 51 Franklin St - Fifth Floor, Boston, MA 02110-1301 USA.
+ */
+
+/*
+ * mwait_idle is a cpuidle driver that loads on specific processors
+ * in lieu of the legacy ACPI processor_idle driver.  The intent is to
+ * make Linux more efficient on these processors, as mwait_idle knows
+ * more than ACPI, as well as make Linux more immune to ACPI BIOS bugs.
+ */
+
+/*
+ * Design Assumptions
+ *
+ * All CPUs have same idle states as boot CPU
+ *
+ * Chipset BM_STS (bus master status) bit is a NOP
+ *	for preventing entry into deep C-states
+ */
+
+/*
+ * Known limitations
+ *
+ * The driver currently initializes for_each_online_cpu() upon load.
+ * It it unaware of subsequent processors hot-added to the system.
+ * This means that if you boot with maxcpus=3Dn and later online
+ * processors above n, those processors will use C1 only.
+ *
+ * ACPI has a .suspend hack to turn off deep C-states during suspend
+ * to avoid complications with the lapic timer workaround.
+ * Have not seen issues with suspend, but may need same workaround here.
+ */
+
+/* un-comment DEBUG to enable pr_debug() statements */
+#define DEBUG
+
+#include <xen/lib.h>
+#include <xen/cpu.h>
+#include <xen/init.h>
+#include <xen/softirq.h>
+#include <xen/trace.h>
+#include <asm/cpuidle.h>
+#include <asm/mwait.h>
+#include <asm/msr.h>
+#include <acpi/cpufreq/cpufreq.h>
+
+#define MWAIT_IDLE_VERSION "0.4"
+#undef PREFIX
+#define PREFIX "mwait-idle: "
+
+#ifdef DEBUG
+# define pr_debug(fmt...) printk(KERN_DEBUG fmt)
+#else
+# define pr_debug(fmt...)
+#endif
+
+static __initdata bool_t no_mwait_idle;
+invbool_param("mwait-idle", no_mwait_idle);
+
+static unsigned int mwait_substates;
+
+#define LAPIC_TIMER_ALWAYS_RELIABLE 0xFFFFFFFF
+/* Reliable LAPIC Timer States, bit 1 for C1 etc. Default to only C1. */
+static unsigned int lapic_timer_reliable_states =3D (1 << 1);
+
+struct idle_cpu {
+	const struct cpuidle_state *state_table;
+
+	/*
+	 * Hardware C-state auto-demotion may not always be optimal.
+	 * Indicate which enable bits to clear here.
+	 */
+	unsigned long auto_demotion_disable_flags;
+};
+
+static const struct idle_cpu *icpu;
+
+static const struct cpuidle_state {
+	char		name[16];
+	unsigned int	flags;
+	unsigned int	exit_latency; /* in US */
+	int		power_usage; /* in mW */
+	unsigned int	target_residency; /* in US */
+} *cpuidle_state_table;
+
+/*
+ * Set this flag for states where the HW flushes the TLB for us
+ * and so we don't need cross-calls to keep it consistent.
+ * If this flag is set, SW flushes the TLB, so even if the
+ * HW doesn't do the flushing, this flag is safe to use.
+ */
+#define CPUIDLE_FLAG_TLB_FLUSHED	0x10000
+
+/*
+ * States are indexed by the cstate number,
+ * which is also the index into the MWAIT hint array.
+ * Thus C0 is a dummy.
+ */
+static const struct cpuidle_state nehalem_cstates[MWAIT_MAX_NUM_CSTATES] =
=3D {
+	{ /* MWAIT C0 */ },
+	{ /* MWAIT C1 */
+		.name =3D "C1-NHM",
+		.exit_latency =3D 3,
+		.target_residency =3D 6,
+	},
+	{ /* MWAIT C2 */
+		.name =3D "C3-NHM",
+		.flags =3D CPUIDLE_FLAG_TLB_FLUSHED,
+		.exit_latency =3D 20,
+		.target_residency =3D 80,
+	},
+	{ /* MWAIT C3 */
+		.name =3D "C6-NHM",
+		.flags =3D CPUIDLE_FLAG_TLB_FLUSHED,
+		.exit_latency =3D 200,
+		.target_residency =3D 800,
+	}
+};
+
+static const struct cpuidle_state snb_cstates[MWAIT_MAX_NUM_CSTATES] =3D =
{
+	{ /* MWAIT C0 */ },
+	{ /* MWAIT C1 */
+		.name =3D "C1-SNB",
+		.exit_latency =3D 1,
+		.target_residency =3D 1,
+	},
+	{ /* MWAIT C2 */
+		.name =3D "C3-SNB",
+		.flags =3D CPUIDLE_FLAG_TLB_FLUSHED,
+		.exit_latency =3D 80,
+		.target_residency =3D 211,
+	},
+	{ /* MWAIT C3 */
+		.name =3D "C6-SNB",
+		.flags =3D CPUIDLE_FLAG_TLB_FLUSHED,
+		.exit_latency =3D 104,
+		.target_residency =3D 345,
+	},
+	{ /* MWAIT C4 */
+		.name =3D "C7-SNB",
+		.flags =3D CPUIDLE_FLAG_TLB_FLUSHED,
+		.exit_latency =3D 109,
+		.target_residency =3D 345,
+	}
+};
+
+static const struct cpuidle_state ivb_cstates[MWAIT_MAX_NUM_CSTATES] =3D =
{
+	{ /* MWAIT C0 */ },
+	{ /* MWAIT C1 */
+		.name =3D "C1-IVB",
+		.exit_latency =3D 1,
+		.target_residency =3D 1,
+	},
+	{ /* MWAIT C2 */
+		.name =3D "C3-IVB",
+		.flags =3D CPUIDLE_FLAG_TLB_FLUSHED,
+		.exit_latency =3D 59,
+		.target_residency =3D 156,
+	},
+	{ /* MWAIT C3 */
+		.name =3D "C6-IVB",
+		.flags =3D CPUIDLE_FLAG_TLB_FLUSHED,
+		.exit_latency =3D 80,
+		.target_residency =3D 300,
+	},
+	{ /* MWAIT C4 */
+		.name =3D "C7-IVB",
+		.flags =3D CPUIDLE_FLAG_TLB_FLUSHED,
+		.exit_latency =3D 87,
+		.target_residency =3D 300,
+	}
+};
+
+static const struct cpuidle_state atom_cstates[MWAIT_MAX_NUM_CSTATES] =3D =
{
+	{ /* MWAIT C0 */ },
+	{ /* MWAIT C1 */
+		.name =3D "C1-ATM",
+		.exit_latency =3D 1,
+		.target_residency =3D 4,
+	},
+	{ /* MWAIT C2 */
+		.name =3D "C2-ATM",
+		.exit_latency =3D 20,
+		.target_residency =3D 80,
+	},
+	{ /* MWAIT C3 */ },
+	{ /* MWAIT C4 */
+		.name =3D "C4-ATM",
+		.flags =3D CPUIDLE_FLAG_TLB_FLUSHED,
+		.exit_latency =3D 100,
+		.target_residency =3D 400,
+	},
+	{ /* MWAIT C5 */ },
+	{ /* MWAIT C6 */
+		.name =3D "C6-ATM",
+		.flags =3D CPUIDLE_FLAG_TLB_FLUSHED,
+		.exit_latency =3D 140,
+		.target_residency =3D 560,
+	}
+};
+
+static u32 get_driver_data(unsigned int cstate)
+{
+	static const u32 driver_data[] =3D {
+		[1] /* MWAIT C1 */ =3D 0x00,
+		[2] /* MWAIT C2 */ =3D 0x10,
+		[3] /* MWAIT C3 */ =3D 0x20,
+		[4] /* MWAIT C4 */ =3D 0x30,
+		[5] /* MWAIT C5 */ =3D 0x40,
+		[6] /* MWAIT C6 */ =3D 0x52,
+	};
+
+	return driver_data[cstate < ARRAY_SIZE(driver_data) ? cstate : 0];
+}
+
+static void mwait_idle(void)
+{
+	unsigned int cpu =3D smp_processor_id();
+	struct acpi_processor_power *power =3D processor_powers[cpu];
+	struct acpi_processor_cx *cx =3D NULL;
+	unsigned int eax, next_state, cstate;
+	u64 before, after;
+	u32 exp =3D 0, pred =3D 0, irq_traced[4] =3D { 0 };
+
+	if (max_cstate > 0 && power && !sched_has_urgent_vcpu() &&
+	    (next_state =3D cpuidle_current_governor->select(power)) > 0) =
{
+		do {
+			cx =3D &power->states[next_state];
+		} while (cx->type > max_cstate && --next_state);
+		if (!next_state)
+			cx =3D NULL;
+		menu_get_trace_data(&exp, &pred);
+	}
+	if (!cx) {
+		if (pm_idle_save)
+			pm_idle_save();
+		else
+			safe_halt();
+		return;
+	}
+
+	cpufreq_dbs_timer_suspend();
+
+	sched_tick_suspend();
+	/* sched_tick_suspend() can raise TIMER_SOFTIRQ. Process it now. =
*/
+	process_pending_softirqs();
+
+	/* Interrupts must be disabled for C2 and higher transitions. */
+	local_irq_disable();
+
+	if (!cpu_is_haltable(cpu)) {
+		local_irq_enable();
+		sched_tick_resume();
+		cpufreq_dbs_timer_resume();
+		return;
+	}
+
+	power->last_state =3D cx;
+	eax =3D cx->address;
+	cstate =3D ((eax >> MWAIT_SUBSTATE_SIZE) & MWAIT_CSTATE_MASK) + 1;
+
+#if 0 /* XXX Can we/do we need to do something similar on Xen? */
+	/*
+	 * leave_mm() to avoid costly and often unnecessary wakeups
+	 * for flushing the user TLB's associated with the active mm.
+	 */
+	if (cpuidle_state_table[].flags & CPUIDLE_FLAG_TLB_FLUSHED)
+		leave_mm(cpu);
+#endif
+
+	if (!(lapic_timer_reliable_states & (1 << cstate)))
+		lapic_timer_off();
+
+	before =3D cpuidle_get_tick();
+	TRACE_4D(TRC_PM_IDLE_ENTRY, cx->idx, before, exp, pred);
+
+	if (cpu_is_haltable(cpu))
+		mwait_idle_with_hints(eax, MWAIT_ECX_INTERRUPT_BREAK);
+
+	after =3D cpuidle_get_tick();
+
+	cstate_restore_tsc();
+	trace_exit_reason(irq_traced);
+	TRACE_6D(TRC_PM_IDLE_EXIT, cx->idx, after,
+		irq_traced[0], irq_traced[1], irq_traced[2], irq_traced[3])=
;
+
+	update_idle_stats(power, cx, before, after);
+	local_irq_enable();
+
+	if (!(lapic_timer_reliable_states & (1 << cstate)))
+		lapic_timer_on();
+
+	/* Now back in C0. */
+	power->last_state =3D &power->states[0];
+
+	sched_tick_resume();
+	cpufreq_dbs_timer_resume();
+
+	if ( cpuidle_current_governor->reflect )
+		cpuidle_current_governor->reflect(power);
+}
+
+static void auto_demotion_disable(void *dummy)
+{
+	u64 msr_bits;
+
+	rdmsrl(MSR_NHM_SNB_PKG_CST_CFG_CTL, msr_bits);
+	msr_bits &=3D ~(icpu->auto_demotion_disable_flags);
+	wrmsrl(MSR_NHM_SNB_PKG_CST_CFG_CTL, msr_bits);
+}
+
+static const struct idle_cpu idle_cpu_nehalem =3D {
+	.state_table =3D nehalem_cstates,
+	.auto_demotion_disable_flags =3D NHM_C1_AUTO_DEMOTE | NHM_C3_AUTO_D=
EMOTE,
+};
+
+static const struct idle_cpu idle_cpu_atom =3D {
+	.state_table =3D atom_cstates,
+};
+
+static const struct idle_cpu idle_cpu_lincroft =3D {
+	.state_table =3D atom_cstates,
+	.auto_demotion_disable_flags =3D ATM_LNC_C6_AUTO_DEMOTE,
+};
+
+static const struct idle_cpu idle_cpu_snb =3D {
+	.state_table =3D snb_cstates,
+};
+
+static const struct idle_cpu idle_cpu_ivb =3D {
+	.state_table =3D ivb_cstates,
+};
+
+#define ICPU(model, cpu) { 6, model, &idle_cpu_##cpu }
+
+static struct intel_idle_id {
+	unsigned int family, model;
+	const struct idle_cpu *data;
+} intel_idle_ids[] __initdata =3D {
+	ICPU(0x1a, nehalem),
+	ICPU(0x1e, nehalem),
+	ICPU(0x1f, nehalem),
+	ICPU(0x25, nehalem),
+	ICPU(0x2c, nehalem),
+	ICPU(0x2e, nehalem),
+	ICPU(0x2f, nehalem),
+	ICPU(0x1c, atom),
+	ICPU(0x26, lincroft),
+	ICPU(0x2a, snb),
+	ICPU(0x2d, snb),
+	ICPU(0x3a, ivb),
+	{}
+};
+
+static int __init mwait_idle_probe(void)
+{
+	unsigned int eax, ebx, ecx;
+	const struct intel_idle_id *id;
+
+	if (boot_cpu_data.x86_vendor !=3D X86_VENDOR_INTEL ||
+	    !boot_cpu_has(X86_FEATURE_MWAIT) ||
+	    boot_cpu_data.cpuid_level < CPUID_MWAIT_LEAF)
+		return -ENODEV;
+
+	for (id =3D intel_idle_ids; id->family; ++id)
+		if (id->family =3D=3D boot_cpu_data.x86 &&
+		    id->model =3D=3D boot_cpu_data.x86_model)
+			break;
+	if (!id->family) {
+		pr_debug(PREFIX "does not run on family %d model %d\n",
+			 boot_cpu_data.x86, boot_cpu_data.x86_model);
+		return -ENODEV;
+	}
+
+	cpuid(CPUID_MWAIT_LEAF, &eax, &ebx, &ecx, &mwait_substates);
+
+	if (!(ecx & CPUID5_ECX_EXTENSIONS_SUPPORTED) ||
+	    !(ecx & CPUID5_ECX_INTERRUPT_BREAK) ||
+	    !mwait_substates)
+		return -ENODEV;
+
+	if (!max_cstate || no_mwait_idle) {
+		pr_debug(PREFIX "disabled\n");
+		return -EPERM;
+	}
+
+	pr_debug(PREFIX "MWAIT substates: %#x\n", mwait_substates);
+
+	icpu =3D id->data;
+	cpuidle_state_table =3D icpu->state_table;
+
+	if (boot_cpu_has(X86_FEATURE_ARAT))
+		lapic_timer_reliable_states =3D LAPIC_TIMER_ALWAYS_RELIABLE=
;
+
+	pr_debug(PREFIX "v" MWAIT_IDLE_VERSION " model %#x\n",
+		 boot_cpu_data.x86_model);
+
+	pr_debug(PREFIX "lapic_timer_reliable_states %#x\n",
+		 lapic_timer_reliable_states);
+	return 0;
+}
+
+static int mwait_idle_cpu_init(struct notifier_block *nfb,
+			       unsigned long action, void *hcpu)
+{
+	unsigned int cpu =3D (unsigned long)hcpu, cstate;
+	struct acpi_processor_power *dev =3D processor_powers[cpu];
+
+	switch (action) {
+	default:
+		return NOTIFY_DONE;
+
+	case CPU_UP_PREPARE:
+		cpuidle_init_cpu(cpu);
+		return NOTIFY_DONE;
+
+	case CPU_ONLINE:
+		if (!dev)
+			return NOTIFY_DONE;
+		break;
+	}
+
+	dev->count =3D 1;
+
+	for (cstate =3D 1; cstate < MWAIT_MAX_NUM_CSTATES; ++cstate) {
+		unsigned int num_substates;
+		struct acpi_processor_cx *cx;
+
+		if (cstate > max_cstate) {
+			printk(PREFIX "max C-state %u reached\n", =
max_cstate);
+			break;
+		}
+
+		/* Does the state exist in CPUID.MWAIT? */
+		num_substates =3D (mwait_substates >> (cstate * 4))
+			& MWAIT_SUBSTATE_MASK;
+		if (!num_substates)
+			continue;
+		/* Is the state not enabled? */
+		if (!cpuidle_state_table[cstate].target_residency) {
+			/* does the driver not know about the state? */
+			if (!pm_idle_save && !*cpuidle_state_table[cstate].=
name)
+				pr_debug(PREFIX "unaware of family %#x =
model %#x MWAIT %u\n",
+					 boot_cpu_data.x86,
+					 boot_cpu_data.x86_model, cstate);
+			continue;
+		}
+
+		if (dev->count >=3D ACPI_PROCESSOR_MAX_POWER) {
+			printk(PREFIX "max C-state count of %u reached\n",
+			       ACPI_PROCESSOR_MAX_POWER);
+			break;
+		}
+
+		if (cstate > 2 && !boot_cpu_has(X86_FEATURE_NONSTOP_TSC)) =
{
+			if (pm_idle_save)
+				continue;
+			setup_clear_cpu_cap(X86_FEATURE_TSC_RELIABLE);
+		}
+
+		cx =3D dev->states + dev->count;
+		cx->type =3D cstate;
+		cx->address =3D get_driver_data(cstate);
+		cx->entry_method =3D ACPI_CSTATE_EM_FFH;
+		cx->power =3D cpuidle_state_table[cstate].power_usage;
+		cx->latency =3D cpuidle_state_table[cstate].exit_latency;
+		cx->target_residency =3D
+			cpuidle_state_table[cstate].target_residency;
+
+		dev->count++;
+	}
+
+	if (icpu->auto_demotion_disable_flags)
+		on_selected_cpus(cpumask_of(cpu), auto_demotion_disable, =
NULL, 1);
+
+	return NOTIFY_DONE;
+}
+
+int __init mwait_idle_init(struct notifier_block *nfb)
+{
+	int err;
+
+	if (pm_idle_save)
+		return -ENODEV;
+
+	err =3D mwait_idle_probe();
+	if (!err) {
+		nfb->notifier_call =3D mwait_idle_cpu_init;
+		mwait_idle_cpu_init(nfb, CPU_UP_PREPARE, NULL);
+
+		pm_idle_save =3D pm_idle;
+		pm_idle =3D mwait_idle;
+		dead_idle =3D acpi_dead_idle;
+	}
+
+	return err;
+}
--- /dev/null
+++ b/xen/include/asm-x86/cpuidle.h
@@ -0,0 +1,35 @@
+#ifndef __ASM_X86_CPUIDLE_H__
+#define __ASM_X86_CPUIDLE_H__
+
+#include <xen/cpuidle.h>
+#include <xen/notifier.h>
+#include <xen/sched.h>
+#include <xen/sched-if.h>
+
+extern struct acpi_processor_power *processor_powers[];
+
+extern void (*pm_idle_save)(void);
+
+extern void (*lapic_timer_off)(void);
+extern void (*lapic_timer_on)(void);
+
+extern uint64_t (*cpuidle_get_tick)(void);
+
+int mwait_idle_init(struct notifier_block *);
+int cpuidle_init_cpu(unsigned int cpu);
+void acpi_dead_idle(void);
+void trace_exit_reason(u32 *irq_traced);
+void update_idle_stats(struct acpi_processor_power *,
+                       struct acpi_processor_cx *, uint64_t, uint64_t);
+
+/*
+ * vcpu is urgent if vcpu is polling event channel
+ *
+ * if urgent vcpu exists, CPU should not enter deep C state
+ */
+static inline int sched_has_urgent_vcpu(void)
+{
+    return atomic_read(&this_cpu(schedule_data).urgent_count);
+}
+
+#endif /* __X86_ASM_CPUIDLE_H__ */
--- a/xen/include/asm-x86/msr-index.h
+++ b/xen/include/asm-x86/msr-index.h
@@ -36,6 +36,11 @@
 #define MSR_IA32_PERFCTR1		0x000000c2
 #define MSR_FSB_FREQ			0x000000cd
=20
+#define MSR_NHM_SNB_PKG_CST_CFG_CTL	0x000000e2
+#define NHM_C3_AUTO_DEMOTE		(1UL << 25)
+#define NHM_C1_AUTO_DEMOTE		(1UL << 26)
+#define ATM_LNC_C6_AUTO_DEMOTE		(1UL << 25)
+
 #define MSR_MTRRcap			0x000000fe
 #define MSR_IA32_BBL_CR_CTL		0x00000119
=20
--- /dev/null
+++ b/xen/include/asm-x86/mwait.h
@@ -0,0 +1,17 @@
+#ifndef __ASM_X86_MWAIT_H__
+#define __ASM_X86_MWAIT_H__
+
+#define MWAIT_SUBSTATE_MASK		0xf
+#define MWAIT_CSTATE_MASK		0xf
+#define MWAIT_SUBSTATE_SIZE		4
+#define MWAIT_MAX_NUM_CSTATES		8
+
+#define CPUID_MWAIT_LEAF		5
+#define CPUID5_ECX_EXTENSIONS_SUPPORTED 0x1
+#define CPUID5_ECX_INTERRUPT_BREAK	0x2
+
+#define MWAIT_ECX_INTERRUPT_BREAK	0x1
+
+void mwait_idle_with_hints(unsigned int eax, unsigned int ecx);
+
+#endif /* __ASM_X86_MWAIT_H__ */



--=__Part1F2E1E3F.1__=
Content-Type: text/plain; name="x86-mwait-idle.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="x86-mwait-idle.patch"

x86: introduce MWAIT-based, ACPI-less CPU idle driver=0A=0AThis is a port =
of Linux'es intel-idle driver serving the same purpose.=0A=0ASigned-off-by:=
 Jan Beulich <jbeulich@suse.com>=0A=0A--- a/docs/misc/xen-command-line.mark=
down=0A+++ b/docs/misc/xen-command-line.markdown=0A@@ -620,6 +620,14 @@ =
limit is ignored by Xen.=0A =0A Specify if the MMConfig space should be =
enabled.=0A =0A+### mwait-idle=0A+> `=3D <boolean>`=0A+=0A+> Default: =
`true`=0A+=0A+Use the MWAIT idle driver (with model specific C-state =
knowledge) instead=0A+of the ACPI based one.=0A+=0A ### nmi=0A > `=3D =
ignore | dom0 | fatal`=0A =0A--- a/xen/arch/x86/acpi/cpu_idle.c=0A+++ =
b/xen/arch/x86/acpi/cpu_idle.c=0A@@ -39,7 +39,6 @@=0A #include <xen/smp.h>=
=0A #include <xen/guest_access.h>=0A #include <xen/keyhandler.h>=0A-#includ=
e <xen/cpuidle.h>=0A #include <xen/trace.h>=0A #include <xen/sched-if.h>=0A=
 #include <xen/irq.h>=0A@@ -54,6 +53,8 @@=0A #include <public/sysctl.h>=0A =
#include <acpi/cpufreq/cpufreq.h>=0A #include <asm/apic.h>=0A+#include =
<asm/cpuidle.h>=0A+#include <asm/mwait.h>=0A #include <xen/notifier.h>=0A =
#include <xen/cpu.h>=0A =0A@@ -70,18 +71,18 @@=0A #define GET_CC7_RES(val) =
 GET_HW_RES_IN_NS(0x3FE, val) /* SNB only */=0A =0A static void lapic_timer=
_nop(void) { }=0A-static void (*lapic_timer_off)(void);=0A-static void =
(*lapic_timer_on)(void);=0A+void (*__read_mostly lapic_timer_off)(void);=0A=
+void (*__read_mostly lapic_timer_on)(void);=0A =0A static uint64_t =
(*__read_mostly tick_to_ns)(uint64_t) =3D acpi_pm_tick_to_ns;=0A =0A-static=
 void (*pm_idle_save) (void) __read_mostly;=0A+void (*__read_mostly =
pm_idle_save)(void);=0A unsigned int max_cstate __read_mostly =3D =
ACPI_PROCESSOR_MAX_POWER - 1;=0A integer_param("max_cstate", max_cstate);=
=0A static bool_t __read_mostly local_apic_timer_c2_ok;=0A boolean_param("l=
apic_timer_c2_ok", local_apic_timer_c2_ok);=0A =0A-static struct acpi_proce=
ssor_power *__read_mostly processor_powers[NR_CPUS];=0A+struct acpi_process=
or_power *__read_mostly processor_powers[NR_CPUS];=0A =0A struct hw_residen=
cies=0A {=0A@@ -236,12 +237,10 @@ static uint64_t acpi_pm_ticks_elapsed(ui=
=0A         return ((0xFFFFFFFF - t1) + t2 +1);=0A }=0A =0A-static =
uint64_t (*__read_mostly get_tick)(void) =3D get_acpi_pm_tick;=0A+uint64_t =
(*__read_mostly cpuidle_get_tick)(void) =3D get_acpi_pm_tick;=0A static =
uint64_t (*__read_mostly ticks_elapsed)(uint64_t, uint64_t)=0A     =3D =
acpi_pm_ticks_elapsed;=0A =0A-#define MWAIT_ECX_INTERRUPT_BREAK   =
(0x1)=0A-=0A /*=0A  * The bit is set iff cpu use monitor/mwait to enter C =
state=0A  * with this flag set, CPU can be waken up from C state=0A@@ =
-263,7 +262,7 @@ void cpuidle_wakeup_mwait(cpumask_t *mas=0A     cpumask_an=
dnot(mask, mask, &target);=0A }=0A =0A-static void mwait_idle_with_hints(un=
signed long eax, unsigned long ecx)=0A+void mwait_idle_with_hints(unsigned =
int eax, unsigned int ecx)=0A {=0A     unsigned int cpu =3D smp_processor_i=
d();=0A     s_time_t expires =3D per_cpu(timer_deadline, cpu);=0A@@ -334,7 =
+333,7 @@ static struct {=0A     unsigned int count;=0A } c3_cpu_status =
=3D { .lock =3D SPIN_LOCK_UNLOCKED };=0A =0A-static inline void trace_exit_=
reason(u32 *irq_traced)=0A+void trace_exit_reason(u32 *irq_traced)=0A {=0A =
    if ( unlikely(tb_init_done) )=0A     {=0A@@ -354,15 +353,6 @@ static =
inline void trace_exit_reason(u32=0A     }=0A }=0A =0A-/* vcpu is urgent =
if vcpu is polling event channel=0A- *=0A- * if urgent vcpu exists, CPU =
should not enter deep C state=0A- */=0A-static int sched_has_urgent_vcpu(vo=
id)=0A-{=0A-    return atomic_read(&this_cpu(schedule_data).urgent_count);=
=0A-}=0A-=0A /*=0A  * "AAJ72. EOI Transaction May Not be Sent if Software =
Enters Core C6 During =0A  * an Interrupt Service Routine"=0A@@ -388,10 =
+378,11 @@ bool_t errata_c6_eoi_workaround(void)=0A     return (fix_needed =
&& cpu_has_pending_apic_eoi());=0A }=0A =0A-static inline void acpi_update_=
idle_stats(struct acpi_processor_power *power,=0A-                         =
                 struct acpi_processor_cx *cx,=0A-                         =
                 int64_t sleep_ticks)=0A+void update_idle_stats(struct =
acpi_processor_power *power,=0A+                       struct acpi_processo=
r_cx *cx,=0A+                       uint64_t before, uint64_t after)=0A =
{=0A+    int64_t sleep_ticks =3D ticks_elapsed(before, after);=0A     /* =
Interrupts are disabled */=0A =0A     spin_lock(&power->stat_lock);=0A@@ =
-472,19 +463,19 @@ static void acpi_processor_idle(void)=0A         if ( =
cx->type =3D=3D ACPI_STATE_C1 || local_apic_timer_c2_ok )=0A         {=0A  =
           /* Get start time (ticks) */=0A-            t1 =3D get_tick();=
=0A+            t1 =3D cpuidle_get_tick();=0A             /* Trace cpu =
idle entry */=0A             TRACE_4D(TRC_PM_IDLE_ENTRY, cx->idx, t1, exp, =
pred);=0A             /* Invoke C2 */=0A             acpi_idle_do_entry(cx)=
;=0A             /* Get end time (ticks) */=0A-            t2 =3D =
get_tick();=0A+            t2 =3D cpuidle_get_tick();=0A             =
trace_exit_reason(irq_traced);=0A             /* Trace cpu idle exit */=0A =
            TRACE_6D(TRC_PM_IDLE_EXIT, cx->idx, t2,=0A                     =
 irq_traced[0], irq_traced[1], irq_traced[2], irq_traced[3]);=0A           =
  /* Update statistics */=0A-            acpi_update_idle_stats(power, cx, =
ticks_elapsed(t1, t2));=0A+            update_idle_stats(power, cx, t1, =
t2);=0A             /* Re-enable interrupts */=0A             local_irq_ena=
ble();=0A             break;=0A@@ -500,7 +491,7 @@ static void acpi_process=
or_idle(void)=0A         lapic_timer_off();=0A =0A         /* Get start =
time (ticks) */=0A-        t1 =3D get_tick();=0A+        t1 =3D cpuidle_get=
_tick();=0A         /* Trace cpu idle entry */=0A         TRACE_4D(TRC_PM_I=
DLE_ENTRY, cx->idx, t1, exp, pred);=0A =0A@@ -549,7 +540,7 @@ static void =
acpi_processor_idle(void)=0A         }=0A =0A         /* Get end time =
(ticks) */=0A-        t2 =3D get_tick();=0A+        t2 =3D cpuidle_get_tick=
();=0A =0A         /* recovering TSC */=0A         cstate_restore_tsc();=0A=
@@ -559,7 +550,7 @@ static void acpi_processor_idle(void)=0A               =
   irq_traced[0], irq_traced[1], irq_traced[2], irq_traced[3]);=0A =0A     =
    /* Update statistics */=0A-        acpi_update_idle_stats(power, cx, =
ticks_elapsed(t1, t2));=0A+        update_idle_stats(power, cx, t1, =
t2);=0A         /* Re-enable interrupts */=0A         local_irq_enable();=
=0A         /* recovering APIC */=0A@@ -586,7 +577,7 @@ static void =
acpi_processor_idle(void)=0A         cpuidle_current_governor->reflect(powe=
r);=0A }=0A =0A-static void acpi_dead_idle(void)=0A+void acpi_dead_idle(voi=
d)=0A {=0A     struct acpi_processor_power *power;=0A     struct acpi_proce=
ssor_cx *cx;=0A@@ -649,7 +640,7 @@ default_halt:=0A         halt();=0A =
}=0A =0A-static int cpuidle_init_cpu(int cpu)=0A+int cpuidle_init_cpu(unsig=
ned int cpu)=0A {=0A     struct acpi_processor_power *acpi_power;=0A =0A@@ =
-660,7 +651,7 @@ static int cpuidle_init_cpu(int cpu)=0A =0A         if ( =
cpu =3D=3D 0 && boot_cpu_has(X86_FEATURE_NONSTOP_TSC) )=0A         {=0A-   =
         get_tick =3D get_stime_tick;=0A+            cpuidle_get_tick =3D =
get_stime_tick;=0A             ticks_elapsed =3D stime_ticks_elapsed;=0A   =
          tick_to_ns =3D stime_tick_to_ns;=0A         }=0A@@ -685,9 +676,6 =
@@ static int cpuidle_init_cpu(int cpu)=0A     return 0;=0A }=0A =0A-#defin=
e MWAIT_SUBSTATE_MASK (0xf)=0A-#define MWAIT_SUBSTATE_SIZE (4)=0A-=0A =
static int acpi_processor_ffh_cstate_probe(xen_processor_cx_t *cx)=0A {=0A =
    struct cpuinfo_x86 *c =3D &current_cpu_data;=0A@@ -1026,6 +1014,9 @@ =
long set_cx_pminfo(uint32_t cpu, struct =0A     if ( unlikely(!guest_handle=
_okay(power->states, power->count)) )=0A         return -EFAULT;=0A =0A+   =
 if ( pm_idle_save && pm_idle !=3D acpi_processor_idle )=0A+        return =
0;=0A+=0A     print_cx_pminfo(cpu, power);=0A =0A     /* map from acpi_id =
to cpu_id */=0A@@ -1195,7 +1186,12 @@ static struct notifier_block cpu_nfb =
=3D {=0A static int __init cpuidle_presmp_init(void)=0A {=0A     void *cpu =
=3D (void *)(long)smp_processor_id();=0A-    cpu_callback(&cpu_nfb, =
CPU_ONLINE, cpu);=0A+=0A+    if ( !xen_cpuidle )=0A+        return =
0;=0A+=0A+    mwait_idle_init(&cpu_nfb);=0A+    cpu_nfb.notifier_call(&cpu_=
nfb, CPU_ONLINE, cpu);=0A     register_cpu_notifier(&cpu_nfb);=0A     =
return 0;=0A }=0A--- a/xen/arch/x86/cpu/Makefile=0A+++ b/xen/arch/x86/cpu/M=
akefile=0A@@ -5,6 +5,7 @@ obj-y +=3D amd.o=0A obj-y +=3D common.o=0A obj-y =
+=3D intel.o=0A obj-y +=3D intel_cacheinfo.o=0A+obj-y +=3D mwait-idle.o=0A =
=0A # Keeping around for VIA support (JBeulich)=0A # obj-$(x86_32) +=3D =
centaur.o=0A--- /dev/null=0A+++ b/xen/arch/x86/cpu/mwait-idle.c=0A@@ -0,0 =
+1,513 @@=0A+/*=0A+ * mwait_idle.c - native hardware idle loop for modern =
processors=0A+ *=0A+ * Copyright (c) 2010, Intel Corporation.=0A+ * Len =
Brown <len.brown@intel.com>=0A+ *=0A+ * This program is free software; you =
can redistribute it and/or modify it=0A+ * under the terms and conditions =
of the GNU General Public License,=0A+ * version 2, as published by the =
Free Software Foundation.=0A+ *=0A+ * This program is distributed in the =
hope it will be useful, but WITHOUT=0A+ * ANY WARRANTY; without even the =
implied warranty of MERCHANTABILITY or=0A+ * FITNESS FOR A PARTICULAR =
PURPOSE.  See the GNU General Public License for=0A+ * more details.=0A+ =
*=0A+ * You should have received a copy of the GNU General Public License =
along with=0A+ * this program; if not, write to the Free Software =
Foundation, Inc.,=0A+ * 51 Franklin St - Fifth Floor, Boston, MA 02110-1301=
 USA.=0A+ */=0A+=0A+/*=0A+ * mwait_idle is a cpuidle driver that loads on =
specific processors=0A+ * in lieu of the legacy ACPI processor_idle =
driver.  The intent is to=0A+ * make Linux more efficient on these =
processors, as mwait_idle knows=0A+ * more than ACPI, as well as make =
Linux more immune to ACPI BIOS bugs.=0A+ */=0A+=0A+/*=0A+ * Design =
Assumptions=0A+ *=0A+ * All CPUs have same idle states as boot CPU=0A+ =
*=0A+ * Chipset BM_STS (bus master status) bit is a NOP=0A+ *	for =
preventing entry into deep C-states=0A+ */=0A+=0A+/*=0A+ * Known limitation=
s=0A+ *=0A+ * The driver currently initializes for_each_online_cpu() upon =
load.=0A+ * It it unaware of subsequent processors hot-added to the =
system.=0A+ * This means that if you boot with maxcpus=3Dn and later =
online=0A+ * processors above n, those processors will use C1 only.=0A+ =
*=0A+ * ACPI has a .suspend hack to turn off deep C-states during =
suspend=0A+ * to avoid complications with the lapic timer workaround.=0A+ =
* Have not seen issues with suspend, but may need same workaround =
here.=0A+ */=0A+=0A+/* un-comment DEBUG to enable pr_debug() statements =
*/=0A+#define DEBUG=0A+=0A+#include <xen/lib.h>=0A+#include <xen/cpu.h>=0A+=
#include <xen/init.h>=0A+#include <xen/softirq.h>=0A+#include <xen/trace.h>=
=0A+#include <asm/cpuidle.h>=0A+#include <asm/mwait.h>=0A+#include =
<asm/msr.h>=0A+#include <acpi/cpufreq/cpufreq.h>=0A+=0A+#define MWAIT_IDLE_=
VERSION "0.4"=0A+#undef PREFIX=0A+#define PREFIX "mwait-idle: "=0A+=0A+#ifd=
ef DEBUG=0A+# define pr_debug(fmt...) printk(KERN_DEBUG fmt)=0A+#else=0A+# =
define pr_debug(fmt...)=0A+#endif=0A+=0A+static __initdata bool_t =
no_mwait_idle;=0A+invbool_param("mwait-idle", no_mwait_idle);=0A+=0A+static=
 unsigned int mwait_substates;=0A+=0A+#define LAPIC_TIMER_ALWAYS_RELIABLE =
0xFFFFFFFF=0A+/* Reliable LAPIC Timer States, bit 1 for C1 etc. Default to =
only C1. */=0A+static unsigned int lapic_timer_reliable_states =3D (1 << =
1);=0A+=0A+struct idle_cpu {=0A+	const struct cpuidle_state =
*state_table;=0A+=0A+	/*=0A+	 * Hardware C-state auto-demotion may not =
always be optimal.=0A+	 * Indicate which enable bits to clear here.=0A+	=
 */=0A+	unsigned long auto_demotion_disable_flags;=0A+};=0A+=0A+static =
const struct idle_cpu *icpu;=0A+=0A+static const struct cpuidle_state =
{=0A+	char		name[16];=0A+	unsigned int	flags;=0A+	=
unsigned int	exit_latency; /* in US */=0A+	int		power_usage=
; /* in mW */=0A+	unsigned int	target_residency; /* in US */=0A+} =
*cpuidle_state_table;=0A+=0A+/*=0A+ * Set this flag for states where the =
HW flushes the TLB for us=0A+ * and so we don't need cross-calls to keep =
it consistent.=0A+ * If this flag is set, SW flushes the TLB, so even if =
the=0A+ * HW doesn't do the flushing, this flag is safe to use.=0A+ =
*/=0A+#define CPUIDLE_FLAG_TLB_FLUSHED	0x10000=0A+=0A+/*=0A+ * States are =
indexed by the cstate number,=0A+ * which is also the index into the MWAIT =
hint array.=0A+ * Thus C0 is a dummy.=0A+ */=0A+static const struct =
cpuidle_state nehalem_cstates[MWAIT_MAX_NUM_CSTATES] =3D {=0A+	{ /* MWAIT =
C0 */ },=0A+	{ /* MWAIT C1 */=0A+		.name =3D "C1-NHM",=0A+		=
.exit_latency =3D 3,=0A+		.target_residency =3D 6,=0A+	=
},=0A+	{ /* MWAIT C2 */=0A+		.name =3D "C3-NHM",=0A+		=
.flags =3D CPUIDLE_FLAG_TLB_FLUSHED,=0A+		.exit_latency =3D =
20,=0A+		.target_residency =3D 80,=0A+	},=0A+	{ /* MWAIT C3 =
*/=0A+		.name =3D "C6-NHM",=0A+		.flags =3D CPUIDLE_FLAG_TLB=
_FLUSHED,=0A+		.exit_latency =3D 200,=0A+		.target_res=
idency =3D 800,=0A+	}=0A+};=0A+=0A+static const struct cpuidle_state =
snb_cstates[MWAIT_MAX_NUM_CSTATES] =3D {=0A+	{ /* MWAIT C0 */ },=0A+	{ =
/* MWAIT C1 */=0A+		.name =3D "C1-SNB",=0A+		.exit_laten=
cy =3D 1,=0A+		.target_residency =3D 1,=0A+	},=0A+	{ /* MWAIT =
C2 */=0A+		.name =3D "C3-SNB",=0A+		.flags =3D =
CPUIDLE_FLAG_TLB_FLUSHED,=0A+		.exit_latency =3D 80,=0A+		=
.target_residency =3D 211,=0A+	},=0A+	{ /* MWAIT C3 */=0A+		=
.name =3D "C6-SNB",=0A+		.flags =3D CPUIDLE_FLAG_TLB_FLUSHED,=0A+	=
	.exit_latency =3D 104,=0A+		.target_residency =3D =
345,=0A+	},=0A+	{ /* MWAIT C4 */=0A+		.name =3D =
"C7-SNB",=0A+		.flags =3D CPUIDLE_FLAG_TLB_FLUSHED,=0A+		=
.exit_latency =3D 109,=0A+		.target_residency =3D 345,=0A+	=
}=0A+};=0A+=0A+static const struct cpuidle_state ivb_cstates[MWAIT_MAX_NUM_=
CSTATES] =3D {=0A+	{ /* MWAIT C0 */ },=0A+	{ /* MWAIT C1 */=0A+		=
.name =3D "C1-IVB",=0A+		.exit_latency =3D 1,=0A+		=
.target_residency =3D 1,=0A+	},=0A+	{ /* MWAIT C2 */=0A+		=
.name =3D "C3-IVB",=0A+		.flags =3D CPUIDLE_FLAG_TLB_FLUSHED,=0A+	=
	.exit_latency =3D 59,=0A+		.target_residency =3D =
156,=0A+	},=0A+	{ /* MWAIT C3 */=0A+		.name =3D =
"C6-IVB",=0A+		.flags =3D CPUIDLE_FLAG_TLB_FLUSHED,=0A+		=
.exit_latency =3D 80,=0A+		.target_residency =3D 300,=0A+	=
},=0A+	{ /* MWAIT C4 */=0A+		.name =3D "C7-IVB",=0A+		=
.flags =3D CPUIDLE_FLAG_TLB_FLUSHED,=0A+		.exit_latency =3D =
87,=0A+		.target_residency =3D 300,=0A+	}=0A+};=0A+=0A+static =
const struct cpuidle_state atom_cstates[MWAIT_MAX_NUM_CSTATES] =3D {=0A+	=
{ /* MWAIT C0 */ },=0A+	{ /* MWAIT C1 */=0A+		.name =3D =
"C1-ATM",=0A+		.exit_latency =3D 1,=0A+		.target_res=
idency =3D 4,=0A+	},=0A+	{ /* MWAIT C2 */=0A+		.name =3D =
"C2-ATM",=0A+		.exit_latency =3D 20,=0A+		.target_res=
idency =3D 80,=0A+	},=0A+	{ /* MWAIT C3 */ },=0A+	{ /* MWAIT C4 =
*/=0A+		.name =3D "C4-ATM",=0A+		.flags =3D CPUIDLE_FLAG_TLB=
_FLUSHED,=0A+		.exit_latency =3D 100,=0A+		.target_res=
idency =3D 400,=0A+	},=0A+	{ /* MWAIT C5 */ },=0A+	{ /* MWAIT C6 =
*/=0A+		.name =3D "C6-ATM",=0A+		.flags =3D CPUIDLE_FLAG_TLB=
_FLUSHED,=0A+		.exit_latency =3D 140,=0A+		.target_res=
idency =3D 560,=0A+	}=0A+};=0A+=0A+static u32 get_driver_data(unsigned =
int cstate)=0A+{=0A+	static const u32 driver_data[] =3D {=0A+		=
[1] /* MWAIT C1 */ =3D 0x00,=0A+		[2] /* MWAIT C2 */ =3D =
0x10,=0A+		[3] /* MWAIT C3 */ =3D 0x20,=0A+		=
[4] /* MWAIT C4 */ =3D 0x30,=0A+		[5] /* MWAIT C5 */ =3D =
0x40,=0A+		[6] /* MWAIT C6 */ =3D 0x52,=0A+	};=0A+=0A+	=
return driver_data[cstate < ARRAY_SIZE(driver_data) ? cstate : 0];=0A+}=0A+=
=0A+static void mwait_idle(void)=0A+{=0A+	unsigned int cpu =3D =
smp_processor_id();=0A+	struct acpi_processor_power *power =3D processor_po=
wers[cpu];=0A+	struct acpi_processor_cx *cx =3D NULL;=0A+	unsigned =
int eax, next_state, cstate;=0A+	u64 before, after;=0A+	u32 exp =
=3D 0, pred =3D 0, irq_traced[4] =3D { 0 };=0A+=0A+	if (max_cstate > 0 =
&& power && !sched_has_urgent_vcpu() &&=0A+	    (next_state =3D =
cpuidle_current_governor->select(power)) > 0) {=0A+		do {=0A+	=
		cx =3D &power->states[next_state];=0A+		} while =
(cx->type > max_cstate && --next_state);=0A+		if (!next_state)=0A=
+			cx =3D NULL;=0A+		menu_get_trace_data=
(&exp, &pred);=0A+	}=0A+	if (!cx) {=0A+		if (pm_idle_save)=
=0A+			pm_idle_save();=0A+		else=0A+		=
	safe_halt();=0A+		return;=0A+	}=0A+=0A+	=
cpufreq_dbs_timer_suspend();=0A+=0A+	sched_tick_suspend();=0A+	/* =
sched_tick_suspend() can raise TIMER_SOFTIRQ. Process it now. */=0A+	=
process_pending_softirqs();=0A+=0A+	/* Interrupts must be disabled for =
C2 and higher transitions. */=0A+	local_irq_disable();=0A+=0A+	if =
(!cpu_is_haltable(cpu)) {=0A+		local_irq_enable();=0A+		=
sched_tick_resume();=0A+		cpufreq_dbs_timer_resume();=0A+		=
return;=0A+	}=0A+=0A+	power->last_state =3D cx;=0A+	eax =3D =
cx->address;=0A+	cstate =3D ((eax >> MWAIT_SUBSTATE_SIZE) & =
MWAIT_CSTATE_MASK) + 1;=0A+=0A+#if 0 /* XXX Can we/do we need to do =
something similar on Xen? */=0A+	/*=0A+	 * leave_mm() to avoid =
costly and often unnecessary wakeups=0A+	 * for flushing the user =
TLB's associated with the active mm.=0A+	 */=0A+	if (cpuidle_state_t=
able[].flags & CPUIDLE_FLAG_TLB_FLUSHED)=0A+		leave_mm(cpu);=0A+#=
endif=0A+=0A+	if (!(lapic_timer_reliable_states & (1 << cstate)))=0A+		=
lapic_timer_off();=0A+=0A+	before =3D cpuidle_get_tick();=0A+	=
TRACE_4D(TRC_PM_IDLE_ENTRY, cx->idx, before, exp, pred);=0A+=0A+	if =
(cpu_is_haltable(cpu))=0A+		mwait_idle_with_hints(eax, =
MWAIT_ECX_INTERRUPT_BREAK);=0A+=0A+	after =3D cpuidle_get_tick();=0A+=
=0A+	cstate_restore_tsc();=0A+	trace_exit_reason(irq_traced);=0A+	=
TRACE_6D(TRC_PM_IDLE_EXIT, cx->idx, after,=0A+		irq_traced[0], =
irq_traced[1], irq_traced[2], irq_traced[3]);=0A+=0A+	update_idle_stats(p=
ower, cx, before, after);=0A+	local_irq_enable();=0A+=0A+	if =
(!(lapic_timer_reliable_states & (1 << cstate)))=0A+		lapic_timer=
_on();=0A+=0A+	/* Now back in C0. */=0A+	power->last_state =3D =
&power->states[0];=0A+=0A+	sched_tick_resume();=0A+	cpufreq_dbs=
_timer_resume();=0A+=0A+	if ( cpuidle_current_governor->reflect =
)=0A+		cpuidle_current_governor->reflect(power);=0A+}=0A+=0A+stati=
c void auto_demotion_disable(void *dummy)=0A+{=0A+	u64 msr_bits;=0A+=
=0A+	rdmsrl(MSR_NHM_SNB_PKG_CST_CFG_CTL, msr_bits);=0A+	msr_bits =
&=3D ~(icpu->auto_demotion_disable_flags);=0A+	wrmsrl(MSR_NHM_SNB_PKG_CST_=
CFG_CTL, msr_bits);=0A+}=0A+=0A+static const struct idle_cpu idle_cpu_nehal=
em =3D {=0A+	.state_table =3D nehalem_cstates,=0A+	.auto_demotion_disa=
ble_flags =3D NHM_C1_AUTO_DEMOTE | NHM_C3_AUTO_DEMOTE,=0A+};=0A+=0A+static =
const struct idle_cpu idle_cpu_atom =3D {=0A+	.state_table =3D atom_cstat=
es,=0A+};=0A+=0A+static const struct idle_cpu idle_cpu_lincroft =3D {=0A+	=
.state_table =3D atom_cstates,=0A+	.auto_demotion_disable_flags =3D =
ATM_LNC_C6_AUTO_DEMOTE,=0A+};=0A+=0A+static const struct idle_cpu =
idle_cpu_snb =3D {=0A+	.state_table =3D snb_cstates,=0A+};=0A+=0A+static =
const struct idle_cpu idle_cpu_ivb =3D {=0A+	.state_table =3D ivb_cstate=
s,=0A+};=0A+=0A+#define ICPU(model, cpu) { 6, model, &idle_cpu_##cpu =
}=0A+=0A+static struct intel_idle_id {=0A+	unsigned int family, =
model;=0A+	const struct idle_cpu *data;=0A+} intel_idle_ids[] =
__initdata =3D {=0A+	ICPU(0x1a, nehalem),=0A+	ICPU(0x1e, =
nehalem),=0A+	ICPU(0x1f, nehalem),=0A+	ICPU(0x25, nehalem),=0A+	=
ICPU(0x2c, nehalem),=0A+	ICPU(0x2e, nehalem),=0A+	ICPU(0x2f, =
nehalem),=0A+	ICPU(0x1c, atom),=0A+	ICPU(0x26, lincroft),=0A+	=
ICPU(0x2a, snb),=0A+	ICPU(0x2d, snb),=0A+	ICPU(0x3a, ivb),=0A+	=
{}=0A+};=0A+=0A+static int __init mwait_idle_probe(void)=0A+{=0A+	=
unsigned int eax, ebx, ecx;=0A+	const struct intel_idle_id *id;=0A+=0A+	if =
(boot_cpu_data.x86_vendor !=3D X86_VENDOR_INTEL ||=0A+	    !boot_cpu_has(X=
86_FEATURE_MWAIT) ||=0A+	    boot_cpu_data.cpuid_level < CPUID_MWAIT=
_LEAF)=0A+		return -ENODEV;=0A+=0A+	for (id =3D intel_idle_ids;=
 id->family; ++id)=0A+		if (id->family =3D=3D boot_cpu_data.x86 =
&&=0A+		    id->model =3D=3D boot_cpu_data.x86_model)=0A+		=
	break;=0A+	if (!id->family) {=0A+		pr_debug(PREFIX =
"does not run on family %d model %d\n",=0A+			 boot_cpu_d=
ata.x86, boot_cpu_data.x86_model);=0A+		return -ENODEV;=0A+	=
}=0A+=0A+	cpuid(CPUID_MWAIT_LEAF, &eax, &ebx, &ecx, &mwait_substates)=
;=0A+=0A+	if (!(ecx & CPUID5_ECX_EXTENSIONS_SUPPORTED) ||=0A+	   =
 !(ecx & CPUID5_ECX_INTERRUPT_BREAK) ||=0A+	    !mwait_substates)=0A+	=
	return -ENODEV;=0A+=0A+	if (!max_cstate || no_mwait_idle) {=0A+		=
pr_debug(PREFIX "disabled\n");=0A+		return -EPERM;=0A+	=
}=0A+=0A+	pr_debug(PREFIX "MWAIT substates: %#x\n", mwait_substates);=
=0A+=0A+	icpu =3D id->data;=0A+	cpuidle_state_table =3D icpu->state=
_table;=0A+=0A+	if (boot_cpu_has(X86_FEATURE_ARAT))=0A+		lapic_timer=
_reliable_states =3D LAPIC_TIMER_ALWAYS_RELIABLE;=0A+=0A+	pr_debug(PR=
EFIX "v" MWAIT_IDLE_VERSION " model %#x\n",=0A+		 boot_cpu_data.x86_=
model);=0A+=0A+	pr_debug(PREFIX "lapic_timer_reliable_states %#x\n",=0A+	=
	 lapic_timer_reliable_states);=0A+	return 0;=0A+}=0A+=0A+stati=
c int mwait_idle_cpu_init(struct notifier_block *nfb,=0A+			=
       unsigned long action, void *hcpu)=0A+{=0A+	unsigned int cpu =
=3D (unsigned long)hcpu, cstate;=0A+	struct acpi_processor_power *dev =
=3D processor_powers[cpu];=0A+=0A+	switch (action) {=0A+	default:=0A=
+		return NOTIFY_DONE;=0A+=0A+	case CPU_UP_PREPARE:=0A+	=
	cpuidle_init_cpu(cpu);=0A+		return NOTIFY_DONE;=0A+=0A+=
	case CPU_ONLINE:=0A+		if (!dev)=0A+			=
return NOTIFY_DONE;=0A+		break;=0A+	}=0A+=0A+	dev->count =
=3D 1;=0A+=0A+	for (cstate =3D 1; cstate < MWAIT_MAX_NUM_CSTATES; =
++cstate) {=0A+		unsigned int num_substates;=0A+		struct =
acpi_processor_cx *cx;=0A+=0A+		if (cstate > max_cstate) {=0A+		=
	printk(PREFIX "max C-state %u reached\n", max_cstate);=0A+		=
	break;=0A+		}=0A+=0A+		/* Does the state =
exist in CPUID.MWAIT? */=0A+		num_substates =3D (mwait_substates =
>> (cstate * 4))=0A+			& MWAIT_SUBSTATE_MASK;=0A+		=
if (!num_substates)=0A+			continue;=0A+		/* Is the =
state not enabled? */=0A+		if (!cpuidle_state_table[cstate].ta=
rget_residency) {=0A+			/* does the driver not know about =
the state? */=0A+			if (!pm_idle_save && !*cpuidle_stat=
e_table[cstate].name)=0A+				pr_debug(PREFIX =
"unaware of family %#x model %#x MWAIT %u\n",=0A+				=
	 boot_cpu_data.x86,=0A+					 boot_cpu_d=
ata.x86_model, cstate);=0A+			continue;=0A+		=
}=0A+=0A+		if (dev->count >=3D ACPI_PROCESSOR_MAX_POWER) =
{=0A+			printk(PREFIX "max C-state count of %u reached\n",=
=0A+			       ACPI_PROCESSOR_MAX_POWER);=0A+			=
break;=0A+		}=0A+=0A+		if (cstate > 2 && =
!boot_cpu_has(X86_FEATURE_NONSTOP_TSC)) {=0A+			if =
(pm_idle_save)=0A+				continue;=0A+			=
setup_clear_cpu_cap(X86_FEATURE_TSC_RELIABLE);=0A+		}=0A+=0A+	=
	cx =3D dev->states + dev->count;=0A+		cx->type =3D =
cstate;=0A+		cx->address =3D get_driver_data(cstate);=0A+		=
cx->entry_method =3D ACPI_CSTATE_EM_FFH;=0A+		cx->power =3D =
cpuidle_state_table[cstate].power_usage;=0A+		cx->latency =3D =
cpuidle_state_table[cstate].exit_latency;=0A+		cx->target_residenc=
y =3D=0A+			cpuidle_state_table[cstate].target_residenc=
y;=0A+=0A+		dev->count++;=0A+	}=0A+=0A+	if =
(icpu->auto_demotion_disable_flags)=0A+		on_selected_cpus(cpumask_of=
(cpu), auto_demotion_disable, NULL, 1);=0A+=0A+	return NOTIFY_DONE;=0A+}=0A=
+=0A+int __init mwait_idle_init(struct notifier_block *nfb)=0A+{=0A+	=
int err;=0A+=0A+	if (pm_idle_save)=0A+		return -ENODEV;=0A+=
=0A+	err =3D mwait_idle_probe();=0A+	if (!err) {=0A+		nfb->notifi=
er_call =3D mwait_idle_cpu_init;=0A+		mwait_idle_cpu_init(nfb, =
CPU_UP_PREPARE, NULL);=0A+=0A+		pm_idle_save =3D pm_idle;=0A+		=
pm_idle =3D mwait_idle;=0A+		dead_idle =3D acpi_dead_idle;=0A+	=
}=0A+=0A+	return err;=0A+}=0A--- /dev/null=0A+++ b/xen/include/asm-x8=
6/cpuidle.h=0A@@ -0,0 +1,35 @@=0A+#ifndef __ASM_X86_CPUIDLE_H__=0A+#define =
__ASM_X86_CPUIDLE_H__=0A+=0A+#include <xen/cpuidle.h>=0A+#include =
<xen/notifier.h>=0A+#include <xen/sched.h>=0A+#include <xen/sched-if.h>=0A+=
=0A+extern struct acpi_processor_power *processor_powers[];=0A+=0A+extern =
void (*pm_idle_save)(void);=0A+=0A+extern void (*lapic_timer_off)(void);=0A=
+extern void (*lapic_timer_on)(void);=0A+=0A+extern uint64_t (*cpuidle_get_=
tick)(void);=0A+=0A+int mwait_idle_init(struct notifier_block *);=0A+int =
cpuidle_init_cpu(unsigned int cpu);=0A+void acpi_dead_idle(void);=0A+void =
trace_exit_reason(u32 *irq_traced);=0A+void update_idle_stats(struct =
acpi_processor_power *,=0A+                       struct acpi_processor_cx =
*, uint64_t, uint64_t);=0A+=0A+/*=0A+ * vcpu is urgent if vcpu is polling =
event channel=0A+ *=0A+ * if urgent vcpu exists, CPU should not enter deep =
C state=0A+ */=0A+static inline int sched_has_urgent_vcpu(void)=0A+{=0A+   =
 return atomic_read(&this_cpu(schedule_data).urgent_count);=0A+}=0A+=0A+#en=
dif /* __X86_ASM_CPUIDLE_H__ */=0A--- a/xen/include/asm-x86/msr-index.h=0A+=
++ b/xen/include/asm-x86/msr-index.h=0A@@ -36,6 +36,11 @@=0A #define =
MSR_IA32_PERFCTR1		0x000000c2=0A #define MSR_FSB_FREQ		=
	0x000000cd=0A =0A+#define MSR_NHM_SNB_PKG_CST_CFG_CTL	0x000000e2=
=0A+#define NHM_C3_AUTO_DEMOTE		(1UL << 25)=0A+#define NHM_C1_AUTO_=
DEMOTE		(1UL << 26)=0A+#define ATM_LNC_C6_AUTO_DEMOTE		=
(1UL << 25)=0A+=0A #define MSR_MTRRcap			0x000000fe=0A =
#define MSR_IA32_BBL_CR_CTL		0x00000119=0A =0A--- /dev/null=0A++=
+ b/xen/include/asm-x86/mwait.h=0A@@ -0,0 +1,17 @@=0A+#ifndef __ASM_X86_MWA=
IT_H__=0A+#define __ASM_X86_MWAIT_H__=0A+=0A+#define MWAIT_SUBSTATE_MASK	=
	0xf=0A+#define MWAIT_CSTATE_MASK		0xf=0A+#define =
MWAIT_SUBSTATE_SIZE		4=0A+#define MWAIT_MAX_NUM_CSTATES		=
8=0A+=0A+#define CPUID_MWAIT_LEAF		5=0A+#define CPUID5_ECX_EXT=
ENSIONS_SUPPORTED 0x1=0A+#define CPUID5_ECX_INTERRUPT_BREAK	0x2=0A+=0A+=
#define MWAIT_ECX_INTERRUPT_BREAK	0x1=0A+=0A+void mwait_idle_with_hin=
ts(unsigned int eax, unsigned int ecx);=0A+=0A+#endif /* __ASM_X86_MWAIT_H_=
_ */=0A
--=__Part1F2E1E3F.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

--=__Part1F2E1E3F.1__=--


From xen-devel-bounces@lists.xen.org Fri Sep 21 10:45:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Sep 2012 10:45:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TF0j7-0001L9-0s; Fri, 21 Sep 2012 10:44:53 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <George.Dunlap@eu.citrix.com>) id 1TF0j6-0001Kd-6T
	for xen-devel@lists.xen.org; Fri, 21 Sep 2012 10:44:52 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1348224284!10769545!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzAyMzY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19995 invoked from network); 21 Sep 2012 10:44:46 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Sep 2012 10:44:46 -0000
X-IronPort-AV: E=Sophos;i="4.80,462,1344211200"; d="scan'208";a="38706587"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Sep 2012 10:44:44 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1;
	Fri, 21 Sep 2012 06:44: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 1TF0ix-0003BO-Qn;
	Fri, 21 Sep 2012 11:44:43 +0100
Message-ID: <505C4419.6060108@eu.citrix.com>
Date: Fri, 21 Sep 2012 11:40:25 +0100
From: George Dunlap <george.dunlap@eu.citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:14.0) Gecko/20120714 Thunderbird/14.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <CAFLBxZYtmJ_bKFb90r45=C4Pq1-oe5Fy=eygSsQf4BcGj3EqGA@mail.gmail.com>
	<201209191918.35305.hahn@univention.de>
	<CAFLBxZZko72sMVPr9LEyea7E-tNx74qCvRoxqPZ-eWbvhvctgQ@mail.gmail.com>
	<201209201340.52218.hahn@univention.de> <505B88A1.1070701@suse.com>
	<1348217322.3452.0.camel@zakaz.uk.xensource.com>
In-Reply-To: <1348217322.3452.0.camel@zakaz.uk.xensource.com>
Cc: Jim Fehlig <jfehlig@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Philipp Hahn <hahn@univention.de>
Subject: Re: [Xen-devel] Xen 4.3 development 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-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 21/09/12 09:48, Ian Campbell wrote:
> On Thu, 2012-09-20 at 22:20 +0100, Jim Fehlig wrote:
>> But why is libvirt integration listed as a Xen 4.3 feature?  AFAIK, all of this
>> work is in libvirt and really doesn't have much to do with the release of 4.3.
> I think it's useful to track activities undertaken by the community
> during the 4.3 development timeframe even if it is on things which are
> strictly speaking external and/or independent projects.
>
> It makes a bit of sense if you also consider that we might want to
> divert effort from stuff happening for Xen 4.3 "proper" to one of these
> external projects, which makes it useful to be able to prioritise/track
> them next to each other.
>
> Lastly, in this specific case the availability of libvirt bindings ties
> into the xend->xl transition, which makes it interesting as a Xen 4.3
> thing, IYSWIM.
>
> George, since Jim isn't the first to ask this question perhaps it would
> be useful to include an "external" flag on these items and explain in
> the legend why we are tracking them?
Sounds good -- I'll add this to the mail template:

NB: Several of the items on this list marked (external).  These are
not part of the Xen tree, but are directly related to our users'
experience (e.g., work in Linux or qemu) or to integration with other
important projects (e.g., libvirt bindings).  Since all of these are
part of the Xen community work, and comes from the same pool of labor,
it makes sense to track the progress here, even though they won't
explicitly be released as part of 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 Fri Sep 21 10:45:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Sep 2012 10:45:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TF0j7-0001L9-0s; Fri, 21 Sep 2012 10:44:53 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <George.Dunlap@eu.citrix.com>) id 1TF0j6-0001Kd-6T
	for xen-devel@lists.xen.org; Fri, 21 Sep 2012 10:44:52 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1348224284!10769545!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzAyMzY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19995 invoked from network); 21 Sep 2012 10:44:46 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Sep 2012 10:44:46 -0000
X-IronPort-AV: E=Sophos;i="4.80,462,1344211200"; d="scan'208";a="38706587"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Sep 2012 10:44:44 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1;
	Fri, 21 Sep 2012 06:44: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 1TF0ix-0003BO-Qn;
	Fri, 21 Sep 2012 11:44:43 +0100
Message-ID: <505C4419.6060108@eu.citrix.com>
Date: Fri, 21 Sep 2012 11:40:25 +0100
From: George Dunlap <george.dunlap@eu.citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:14.0) Gecko/20120714 Thunderbird/14.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <CAFLBxZYtmJ_bKFb90r45=C4Pq1-oe5Fy=eygSsQf4BcGj3EqGA@mail.gmail.com>
	<201209191918.35305.hahn@univention.de>
	<CAFLBxZZko72sMVPr9LEyea7E-tNx74qCvRoxqPZ-eWbvhvctgQ@mail.gmail.com>
	<201209201340.52218.hahn@univention.de> <505B88A1.1070701@suse.com>
	<1348217322.3452.0.camel@zakaz.uk.xensource.com>
In-Reply-To: <1348217322.3452.0.camel@zakaz.uk.xensource.com>
Cc: Jim Fehlig <jfehlig@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Philipp Hahn <hahn@univention.de>
Subject: Re: [Xen-devel] Xen 4.3 development 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-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 21/09/12 09:48, Ian Campbell wrote:
> On Thu, 2012-09-20 at 22:20 +0100, Jim Fehlig wrote:
>> But why is libvirt integration listed as a Xen 4.3 feature?  AFAIK, all of this
>> work is in libvirt and really doesn't have much to do with the release of 4.3.
> I think it's useful to track activities undertaken by the community
> during the 4.3 development timeframe even if it is on things which are
> strictly speaking external and/or independent projects.
>
> It makes a bit of sense if you also consider that we might want to
> divert effort from stuff happening for Xen 4.3 "proper" to one of these
> external projects, which makes it useful to be able to prioritise/track
> them next to each other.
>
> Lastly, in this specific case the availability of libvirt bindings ties
> into the xend->xl transition, which makes it interesting as a Xen 4.3
> thing, IYSWIM.
>
> George, since Jim isn't the first to ask this question perhaps it would
> be useful to include an "external" flag on these items and explain in
> the legend why we are tracking them?
Sounds good -- I'll add this to the mail template:

NB: Several of the items on this list marked (external).  These are
not part of the Xen tree, but are directly related to our users'
experience (e.g., work in Linux or qemu) or to integration with other
important projects (e.g., libvirt bindings).  Since all of these are
part of the Xen community work, and comes from the same pool of labor,
it makes sense to track the progress here, even though they won't
explicitly be released as part of 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 Fri Sep 21 10:57:21 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Sep 2012 10:57:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TF0us-0001Wq-8c; Fri, 21 Sep 2012 10:57:02 +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 1TF0uq-0001Wl-Sz
	for xen-devel@lists.xen.org; Fri, 21 Sep 2012 10:57:01 +0000
Received: from [85.158.143.99:3170] by server-1.bemta-4.messagelabs.com id
	72/44-05684-CF74C505; Fri, 21 Sep 2012 10:57:00 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1348225018!30660692!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNzY0MjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3902 invoked from network); 21 Sep 2012 10:56:59 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-3.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Sep 2012 10:56:59 -0000
X-IronPort-AV: E=Sophos;i="4.80,462,1344211200"; d="scan'208";a="208907022"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Sep 2012 10:56:58 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1;
	Fri, 21 Sep 2012 06:56:57 -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 1TF0un-0003Lp-Gr;
	Fri, 21 Sep 2012 11:56:57 +0100
Message-ID: <505C46F6.7010206@eu.citrix.com>
Date: Fri, 21 Sep 2012 11:52:38 +0100
From: George Dunlap <george.dunlap@eu.citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:14.0) Gecko/20120714 Thunderbird/14.0
MIME-Version: 1.0
To: Anthony PERARD <anthony.perard@gmail.com>
References: <CAFLBxZYtmJ_bKFb90r45=C4Pq1-oe5Fy=eygSsQf4BcGj3EqGA@mail.gmail.com>
	<CAJJyHj+prTB1bit633+z60Yy8nyzH-8A=FUf485S9Mv6wFnY8A@mail.gmail.com>
In-Reply-To: <CAJJyHj+prTB1bit633+z60Yy8nyzH-8A=FUf485S9Mv6wFnY8A@mail.gmail.com>
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.3 development 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-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 21/09/12 11:38, Anthony PERARD wrote:
>   - pci pass-thru
>     owner: anthony@citrix
>     status: ?
> Support for passthrough a PCI device is done, unless I miss something.
> LibXL in Xen 4.2 support it, but qemu-xen in 4.2 does not. Right now,
> only the last release of QEMU (1.2) support pci passthrough with Xen.
I don't really understand what you mean... do you mean qemu-traditional 
doesn't support pci pass-through in 4.2, or that qemu-upstream doesn't?  
In any case, has everything been done that needs to be done for 
qemu-upstream to have passthrough support for 4.3?
> Also, to use QEMU upstream as default device model, we need implement
> few more feature. I have:
>
> - enable dirtybit tracking during migration
>    status: patches submitted to QEMU and to LibXL.
> - xl cd-{insert,eject}
>    status: intilal implementation submitted
Thanks, I've added these 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 Sep 21 10:57:21 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Sep 2012 10:57:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TF0us-0001Wq-8c; Fri, 21 Sep 2012 10:57:02 +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 1TF0uq-0001Wl-Sz
	for xen-devel@lists.xen.org; Fri, 21 Sep 2012 10:57:01 +0000
Received: from [85.158.143.99:3170] by server-1.bemta-4.messagelabs.com id
	72/44-05684-CF74C505; Fri, 21 Sep 2012 10:57:00 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1348225018!30660692!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNzY0MjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3902 invoked from network); 21 Sep 2012 10:56:59 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-3.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Sep 2012 10:56:59 -0000
X-IronPort-AV: E=Sophos;i="4.80,462,1344211200"; d="scan'208";a="208907022"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Sep 2012 10:56:58 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1;
	Fri, 21 Sep 2012 06:56:57 -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 1TF0un-0003Lp-Gr;
	Fri, 21 Sep 2012 11:56:57 +0100
Message-ID: <505C46F6.7010206@eu.citrix.com>
Date: Fri, 21 Sep 2012 11:52:38 +0100
From: George Dunlap <george.dunlap@eu.citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:14.0) Gecko/20120714 Thunderbird/14.0
MIME-Version: 1.0
To: Anthony PERARD <anthony.perard@gmail.com>
References: <CAFLBxZYtmJ_bKFb90r45=C4Pq1-oe5Fy=eygSsQf4BcGj3EqGA@mail.gmail.com>
	<CAJJyHj+prTB1bit633+z60Yy8nyzH-8A=FUf485S9Mv6wFnY8A@mail.gmail.com>
In-Reply-To: <CAJJyHj+prTB1bit633+z60Yy8nyzH-8A=FUf485S9Mv6wFnY8A@mail.gmail.com>
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.3 development 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-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 21/09/12 11:38, Anthony PERARD wrote:
>   - pci pass-thru
>     owner: anthony@citrix
>     status: ?
> Support for passthrough a PCI device is done, unless I miss something.
> LibXL in Xen 4.2 support it, but qemu-xen in 4.2 does not. Right now,
> only the last release of QEMU (1.2) support pci passthrough with Xen.
I don't really understand what you mean... do you mean qemu-traditional 
doesn't support pci pass-through in 4.2, or that qemu-upstream doesn't?  
In any case, has everything been done that needs to be done for 
qemu-upstream to have passthrough support for 4.3?
> Also, to use QEMU upstream as default device model, we need implement
> few more feature. I have:
>
> - enable dirtybit tracking during migration
>    status: patches submitted to QEMU and to LibXL.
> - xl cd-{insert,eject}
>    status: intilal implementation submitted
Thanks, I've added these 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 Sep 21 11:12:33 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Sep 2012 11:12: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 1TF19X-0001mT-N7; Fri, 21 Sep 2012 11:12:11 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <George.Dunlap@eu.citrix.com>) id 1TF19V-0001mL-DR
	for xen-devel@lists.xen.org; Fri, 21 Sep 2012 11:12:09 +0000
Received: from [85.158.139.211:59660] by server-13.bemta-5.messagelabs.com id
	E1/60-23645-88B4C505; Fri, 21 Sep 2012 11:12:08 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-9.tower-206.messagelabs.com!1348225926!17937231!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNzY0MjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4343 invoked from network); 21 Sep 2012 11:12:08 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-9.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Sep 2012 11:12:08 -0000
X-IronPort-AV: E=Sophos;i="4.80,462,1344211200"; d="scan'208";a="208908587"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Sep 2012 11:12:06 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1;
	Fri, 21 Sep 2012 07:12: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 1TF19R-0003Z7-IW;
	Fri, 21 Sep 2012 12:12:05 +0100
Message-ID: <505C4A82.2040305@eu.citrix.com>
Date: Fri, 21 Sep 2012 12:07:46 +0100
From: George Dunlap <george.dunlap@eu.citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:14.0) Gecko/20120714 Thunderbird/14.0
MIME-Version: 1.0
To: Jim Fehlig <jfehlig@suse.com>
References: <CAFLBxZYtmJ_bKFb90r45=C4Pq1-oe5Fy=eygSsQf4BcGj3EqGA@mail.gmail.com>
	<201209191918.35305.hahn@univention.de>
	<CAFLBxZZko72sMVPr9LEyea7E-tNx74qCvRoxqPZ-eWbvhvctgQ@mail.gmail.com>
	<201209201340.52218.hahn@univention.de> <505B88A1.1070701@suse.com>
In-Reply-To: <505B88A1.1070701@suse.com>
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Philipp Hahn <hahn@univention.de>
Subject: Re: [Xen-devel] Xen 4.3 development 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-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 20/09/12 22:20, Jim Fehlig wrote:
> Chun Yan Liu was working on a patch to implement migration in the libvirt libxl
> driver, but she wasn't able to finish tidying the patch before departing on
> maternity leave.  She recently returned to work and I'd expect a refreshed patch
> soon - after working through her backlog.
>
> But why is libvirt integration listed as a Xen 4.3 feature?  AFAIK, all of this
> work is in libvirt and really doesn't have much to do with the release of 4.3.
For one, as Ian said, we want xl/libxl to be the default toolstack in 
4.3; as soon as possible we want to remove xend.

But from a broader perspective, the idea is for the Xen.org community to 
be thinking strategically about the success of the Xen project as a 
whole.  Things like distro support and libvirt integration are 
absolutely critical to Xen's success in the open-source ecosystem.  So 
while we don't have to do everything ourselves, we want to think about 
what things need to be done, track them to make sure that *someone* does 
them; and be prepared to pick them up ourselves if necessary.  And it 
just makes more sense to track everything on one list.

Does that make sense?

  -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 21 11:12:33 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Sep 2012 11:12: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 1TF19X-0001mT-N7; Fri, 21 Sep 2012 11:12:11 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <George.Dunlap@eu.citrix.com>) id 1TF19V-0001mL-DR
	for xen-devel@lists.xen.org; Fri, 21 Sep 2012 11:12:09 +0000
Received: from [85.158.139.211:59660] by server-13.bemta-5.messagelabs.com id
	E1/60-23645-88B4C505; Fri, 21 Sep 2012 11:12:08 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-9.tower-206.messagelabs.com!1348225926!17937231!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNzY0MjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4343 invoked from network); 21 Sep 2012 11:12:08 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-9.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Sep 2012 11:12:08 -0000
X-IronPort-AV: E=Sophos;i="4.80,462,1344211200"; d="scan'208";a="208908587"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Sep 2012 11:12:06 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1;
	Fri, 21 Sep 2012 07:12: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 1TF19R-0003Z7-IW;
	Fri, 21 Sep 2012 12:12:05 +0100
Message-ID: <505C4A82.2040305@eu.citrix.com>
Date: Fri, 21 Sep 2012 12:07:46 +0100
From: George Dunlap <george.dunlap@eu.citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:14.0) Gecko/20120714 Thunderbird/14.0
MIME-Version: 1.0
To: Jim Fehlig <jfehlig@suse.com>
References: <CAFLBxZYtmJ_bKFb90r45=C4Pq1-oe5Fy=eygSsQf4BcGj3EqGA@mail.gmail.com>
	<201209191918.35305.hahn@univention.de>
	<CAFLBxZZko72sMVPr9LEyea7E-tNx74qCvRoxqPZ-eWbvhvctgQ@mail.gmail.com>
	<201209201340.52218.hahn@univention.de> <505B88A1.1070701@suse.com>
In-Reply-To: <505B88A1.1070701@suse.com>
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Philipp Hahn <hahn@univention.de>
Subject: Re: [Xen-devel] Xen 4.3 development 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-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 20/09/12 22:20, Jim Fehlig wrote:
> Chun Yan Liu was working on a patch to implement migration in the libvirt libxl
> driver, but she wasn't able to finish tidying the patch before departing on
> maternity leave.  She recently returned to work and I'd expect a refreshed patch
> soon - after working through her backlog.
>
> But why is libvirt integration listed as a Xen 4.3 feature?  AFAIK, all of this
> work is in libvirt and really doesn't have much to do with the release of 4.3.
For one, as Ian said, we want xl/libxl to be the default toolstack in 
4.3; as soon as possible we want to remove xend.

But from a broader perspective, the idea is for the Xen.org community to 
be thinking strategically about the success of the Xen project as a 
whole.  Things like distro support and libvirt integration are 
absolutely critical to Xen's success in the open-source ecosystem.  So 
while we don't have to do everything ourselves, we want to think about 
what things need to be done, track them to make sure that *someone* does 
them; and be prepared to pick them up ourselves if necessary.  And it 
just makes more sense to track everything on one list.

Does that make sense?

  -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 21 11:14:46 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Sep 2012 11:14:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TF1Bk-0001rw-8x; Fri, 21 Sep 2012 11:14:28 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony.perard@gmail.com>) id 1TF1Bj-0001rp-Bf
	for xen-devel@lists.xen.org; Fri, 21 Sep 2012 11:14:27 +0000
Received: from [85.158.139.211:3917] by server-8.bemta-5.messagelabs.com id
	C3/EB-30083-21C4C505; Fri, 21 Sep 2012 11:14:26 +0000
X-Env-Sender: anthony.perard@gmail.com
X-Msg-Ref: server-16.tower-206.messagelabs.com!1348226061!19483926!1
X-Originating-IP: [209.85.223.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2420 invoked from network); 21 Sep 2012 11:14:26 -0000
Received: from mail-ie0-f173.google.com (HELO mail-ie0-f173.google.com)
	(209.85.223.173)
	by server-16.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Sep 2012 11:14:26 -0000
Received: by iea17 with SMTP id 17so875282iea.32
	for <xen-devel@lists.xen.org>; Fri, 21 Sep 2012 04:14: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;
	bh=L4uHcfE19+jANRfZCob7nxA71DbYe0AfC7loKBW23CA=;
	b=a+n+53UuQNu0Uii4w5ojuX1Wv/z3ISwSvFWMTXfWXAoJH5ygKIN3HWLnP4iytKHpjp
	MHJ9xwvDRhITjzjPQZUO3NSyIjM2PVvMHb2dDEf0R/d09lISUtrEyrFGsAB5ky4FCu49
	YtxF9Mr/HpjK1qD8knRroCeI31N3JW4HL2D4NKdNn0yfSo96ca/2D1Ga+TA/C96oInfP
	tmDftfhBIo0JPPWkeMIRvFyPaYlGkDnErG6bfMaT1oJ24/RlnlhtOgjZ2w00O4VdSzKh
	PXINimR403BBMPOhvenTRPC8V+RlkbKVC3o2BPwMA5VxRJjK7RsrtxzSpmHcJSdJaOl1
	+zCg==
Received: by 10.50.40.133 with SMTP id x5mr1266008igk.57.1348226061304; Fri,
	21 Sep 2012 04:14:21 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.64.126.131 with HTTP; Fri, 21 Sep 2012 04:13:49 -0700 (PDT)
In-Reply-To: <505C46F6.7010206@eu.citrix.com>
References: <CAFLBxZYtmJ_bKFb90r45=C4Pq1-oe5Fy=eygSsQf4BcGj3EqGA@mail.gmail.com>
	<CAJJyHj+prTB1bit633+z60Yy8nyzH-8A=FUf485S9Mv6wFnY8A@mail.gmail.com>
	<505C46F6.7010206@eu.citrix.com>
From: Anthony PERARD <anthony.perard@gmail.com>
Date: Fri, 21 Sep 2012 12:13:49 +0100
Message-ID: <CAJJyHjL0SVZD6e24xob_p+uitdEF5BHXNFd7-XkZXc-ssYsRgQ@mail.gmail.com>
To: George Dunlap <george.dunlap@eu.citrix.com>
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.3 development 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 Fri, Sep 21, 2012 at 11:52 AM, George Dunlap
<george.dunlap@eu.citrix.com> wrote:
> On 21/09/12 11:38, Anthony PERARD wrote:
>>
>>   - pci pass-thru
>>     owner: anthony@citrix
>>     status: ?
>> Support for passthrough a PCI device is done, unless I miss something.
>> LibXL in Xen 4.2 support it, but qemu-xen in 4.2 does not. Right now,
>> only the last release of QEMU (1.2) support pci passthrough with Xen.
>
> I don't really understand what you mean... do you mean qemu-traditional
> doesn't support pci pass-through in 4.2, or that qemu-upstream doesn't?

I mean the qemu-upstream distributed with Xen 4.2.

> In any case, has everything been done that needs to be done for qemu-upstream
> to have passthrough support for 4.3?

Yes.

-- 
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 Sep 21 11:14:46 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Sep 2012 11:14:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TF1Bk-0001rw-8x; Fri, 21 Sep 2012 11:14:28 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony.perard@gmail.com>) id 1TF1Bj-0001rp-Bf
	for xen-devel@lists.xen.org; Fri, 21 Sep 2012 11:14:27 +0000
Received: from [85.158.139.211:3917] by server-8.bemta-5.messagelabs.com id
	C3/EB-30083-21C4C505; Fri, 21 Sep 2012 11:14:26 +0000
X-Env-Sender: anthony.perard@gmail.com
X-Msg-Ref: server-16.tower-206.messagelabs.com!1348226061!19483926!1
X-Originating-IP: [209.85.223.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2420 invoked from network); 21 Sep 2012 11:14:26 -0000
Received: from mail-ie0-f173.google.com (HELO mail-ie0-f173.google.com)
	(209.85.223.173)
	by server-16.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Sep 2012 11:14:26 -0000
Received: by iea17 with SMTP id 17so875282iea.32
	for <xen-devel@lists.xen.org>; Fri, 21 Sep 2012 04:14: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;
	bh=L4uHcfE19+jANRfZCob7nxA71DbYe0AfC7loKBW23CA=;
	b=a+n+53UuQNu0Uii4w5ojuX1Wv/z3ISwSvFWMTXfWXAoJH5ygKIN3HWLnP4iytKHpjp
	MHJ9xwvDRhITjzjPQZUO3NSyIjM2PVvMHb2dDEf0R/d09lISUtrEyrFGsAB5ky4FCu49
	YtxF9Mr/HpjK1qD8knRroCeI31N3JW4HL2D4NKdNn0yfSo96ca/2D1Ga+TA/C96oInfP
	tmDftfhBIo0JPPWkeMIRvFyPaYlGkDnErG6bfMaT1oJ24/RlnlhtOgjZ2w00O4VdSzKh
	PXINimR403BBMPOhvenTRPC8V+RlkbKVC3o2BPwMA5VxRJjK7RsrtxzSpmHcJSdJaOl1
	+zCg==
Received: by 10.50.40.133 with SMTP id x5mr1266008igk.57.1348226061304; Fri,
	21 Sep 2012 04:14:21 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.64.126.131 with HTTP; Fri, 21 Sep 2012 04:13:49 -0700 (PDT)
In-Reply-To: <505C46F6.7010206@eu.citrix.com>
References: <CAFLBxZYtmJ_bKFb90r45=C4Pq1-oe5Fy=eygSsQf4BcGj3EqGA@mail.gmail.com>
	<CAJJyHj+prTB1bit633+z60Yy8nyzH-8A=FUf485S9Mv6wFnY8A@mail.gmail.com>
	<505C46F6.7010206@eu.citrix.com>
From: Anthony PERARD <anthony.perard@gmail.com>
Date: Fri, 21 Sep 2012 12:13:49 +0100
Message-ID: <CAJJyHjL0SVZD6e24xob_p+uitdEF5BHXNFd7-XkZXc-ssYsRgQ@mail.gmail.com>
To: George Dunlap <george.dunlap@eu.citrix.com>
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.3 development 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 Fri, Sep 21, 2012 at 11:52 AM, George Dunlap
<george.dunlap@eu.citrix.com> wrote:
> On 21/09/12 11:38, Anthony PERARD wrote:
>>
>>   - pci pass-thru
>>     owner: anthony@citrix
>>     status: ?
>> Support for passthrough a PCI device is done, unless I miss something.
>> LibXL in Xen 4.2 support it, but qemu-xen in 4.2 does not. Right now,
>> only the last release of QEMU (1.2) support pci passthrough with Xen.
>
> I don't really understand what you mean... do you mean qemu-traditional
> doesn't support pci pass-through in 4.2, or that qemu-upstream doesn't?

I mean the qemu-upstream distributed with Xen 4.2.

> In any case, has everything been done that needs to be done for qemu-upstream
> to have passthrough support for 4.3?

Yes.

-- 
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 Sep 21 11:15:40 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Sep 2012 11:15:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TF1Ce-0001wE-Na; Fri, 21 Sep 2012 11:15:24 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1TF1Cd-0001w0-5h
	for xen-devel@lists.xensource.com; Fri, 21 Sep 2012 11:15:23 +0000
Received: from [85.158.137.99:30355] by server-6.bemta-3.messagelabs.com id
	BB/00-29694-A4C4C505; Fri, 21 Sep 2012 11:15:22 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-4.tower-217.messagelabs.com!1348226121!18604910!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTA2NjI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22602 invoked from network); 21 Sep 2012 11:15:21 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Sep 2012 11:15:21 -0000
X-IronPort-AV: E=Sophos;i="4.80,462,1344211200"; d="scan'208";a="14687661"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Sep 2012 11: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.279.1; Fri, 21 Sep 2012 12:15:20 +0100
Date: Fri, 21 Sep 2012 12:14:31 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Rob Herring <robherring2@gmail.com>
In-Reply-To: <505B7BEB.6010105@gmail.com>
Message-ID: <alpine.DEB.2.02.1209211211390.29232@kaball.uk.xensource.com>
References: <1348076658-4511-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<505B7BEB.6010105@gmail.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>, Pawel Moll <pawel.moll@arm.com>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Xen-devel] [PATCH] arm: introduce a DTS for Xen unprivileged
 virtual 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 Thu, 20 Sep 2012, Rob Herring wrote:
> On 09/19/2012 12:44 PM, Stefano Stabellini wrote:
> > Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> > CC: Pawel Moll <pawel.moll@arm.com>
> > CC: linux-arm-kernel@lists.infradead.org
> > ---
> >  arch/arm/boot/dts/vexpress-xenvm-4.2.dts |  115 ++++++++++++++++++++++++++++++
> >  arch/arm/mach-vexpress/Makefile.boot     |    3 +-
> >  2 files changed, 117 insertions(+), 1 deletions(-)
> >  create mode 100644 arch/arm/boot/dts/vexpress-xenvm-4.2.dts
> > 
> > diff --git a/arch/arm/boot/dts/vexpress-xenvm-4.2.dts b/arch/arm/boot/dts/vexpress-xenvm-4.2.dts
> > new file mode 100644
> > index 0000000..bfb802c
> > --- /dev/null
> > +++ b/arch/arm/boot/dts/vexpress-xenvm-4.2.dts
> > @@ -0,0 +1,115 @@
> > +/*
> > + * Xen Virtual Machine for unprivileged guests
> > + *
> > + * Based on ARM Ltd. Versatile Express CoreTile Express (single CPU)
> > + * Cortex-A15 MPCore (V2P-CA15)
> > + *
> > + */
> > +
> > +/dts-v1/;
> > +
> > +/include/ "skeleton.dtsi"
> > +
> > +/ {
> > +	model = "XENVM-4.2";
> > +	compatible = "xen,xenvm-4.2", "arm,vexpress";
> > +	interrupt-parent = <&gic>;
> > +
> > +	chosen {
> > +		bootargs = "earlyprintk console=hvc0 root=/dev/xvda init=/sbin/init";
> > +	};
> > +
> > +	cpus {
> > +		#address-cells = <1>;
> > +		#size-cells = <0>;
> > +
> > +		cpu@0 {
> > +			device_type = "cpu";
> > +			compatible = "arm,cortex-a15";
> > +			reg = <0>;
> > +		};
> > +	};
> > +
> > +	memory {
> > +		device_type = "memory";
> > +		reg = <0x80000000 0x08000000>;
> 
> How much guest memory can be supported here?

There are no particular restrictions other than the amount of memory
present on the physical hardware and the memory already used by other
guests.


> I would expect something like the memory size to be filled in by the
> hypervisor. If so, perhaps a note on any fields hypervisor will adjust.
> 

Yes, that's a good idea. Certainly the amount of memory would be
adjusted by the hypervisor. Also the properties of the hypervisor node
and maybe the bootargs could be adjusted too.


> > +	};
> > +
> > +	gic: interrupt-controller@2c001000 {
> > +		compatible = "arm,cortex-a9-gic";
> > +		#interrupt-cells = <3>;
> > +		#address-cells = <0>;
> > +		interrupt-controller;
> > +		reg = <0x2c001000 0x1000>,
> > +		      <0x2c002000 0x100>;
> > +	};
> > +
> > +	timer {
> > +		compatible = "arm,armv7-timer";
> > +		interrupts = <1 13 0xf08>,
> > +			     <1 14 0xf08>,
> > +			     <1 11 0xf08>,
> > +			     <1 10 0xf08>;
> > +	};
> > +
> > +	hypervisor {
> > +		compatible = "xen,xen-4.2", "xen,xen";
> > +		reg = <0xb0000000 0x20000>;
> > +		interrupts = <1 15 0xf08>;
> > +	};
> > +
> > +	motherboard {
> > +		arm,v2m-memory-map = "rs1";
> > +		ranges = <0 0 0x08000000 0x04000000>,
> > +			 <1 0 0x14000000 0x04000000>,
> > +			 <2 0 0x18000000 0x04000000>,
> > +			 <3 0 0x1c000000 0x04000000>,
> > +			 <4 0 0x0c000000 0x04000000>,
> > +			 <5 0 0x10000000 0x04000000>;
> > +
> > +		interrupt-map-mask = <0 0 63>;
> > +		interrupt-map = <0 0  0 &gic 0  0 4>,
> > +				<0 0  1 &gic 0  1 4>,
> > +				<0 0  2 &gic 0  2 4>,
> > +				<0 0  3 &gic 0  3 4>,
> > +				<0 0  4 &gic 0  4 4>,
> > +				<0 0  5 &gic 0  5 4>,
> > +				<0 0  6 &gic 0  6 4>,
> > +				<0 0  7 &gic 0  7 4>,
> > +				<0 0  8 &gic 0  8 4>,
> > +				<0 0  9 &gic 0  9 4>,
> > +				<0 0 10 &gic 0 10 4>,
> > +				<0 0 11 &gic 0 11 4>,
> > +				<0 0 12 &gic 0 12 4>,
> > +				<0 0 13 &gic 0 13 4>,
> > +				<0 0 14 &gic 0 14 4>,
> > +				<0 0 15 &gic 0 15 4>,
> > +				<0 0 16 &gic 0 16 4>,
> > +				<0 0 17 &gic 0 17 4>,
> > +				<0 0 18 &gic 0 18 4>,
> > +				<0 0 19 &gic 0 19 4>,
> > +				<0 0 20 &gic 0 20 4>,
> > +				<0 0 21 &gic 0 21 4>,
> > +				<0 0 22 &gic 0 22 4>,
> > +				<0 0 23 &gic 0 23 4>,
> > +				<0 0 24 &gic 0 24 4>,
> > +				<0 0 25 &gic 0 25 4>,
> > +				<0 0 26 &gic 0 26 4>,
> > +				<0 0 27 &gic 0 27 4>,
> > +				<0 0 28 &gic 0 28 4>,
> > +				<0 0 29 &gic 0 29 4>,
> > +				<0 0 30 &gic 0 30 4>,
> > +				<0 0 31 &gic 0 31 4>,
> > +				<0 0 32 &gic 0 32 4>,
> > +				<0 0 33 &gic 0 33 4>,
> > +				<0 0 34 &gic 0 34 4>,
> > +				<0 0 35 &gic 0 35 4>,
> > +				<0 0 36 &gic 0 36 4>,
> > +				<0 0 37 &gic 0 37 4>,
> > +				<0 0 38 &gic 0 38 4>,
> > +				<0 0 39 &gic 0 39 4>,
> > +				<0 0 40 &gic 0 40 4>,
> > +				<0 0 41 &gic 0 41 4>,
> > +				<0 0 42 &gic 0 42 4>;
> > +	};
> > +};
> > diff --git a/arch/arm/mach-vexpress/Makefile.boot b/arch/arm/mach-vexpress/Makefile.boot
> > index 318d308..5c633c5 100644
> > --- a/arch/arm/mach-vexpress/Makefile.boot
> > +++ b/arch/arm/mach-vexpress/Makefile.boot
> > @@ -7,4 +7,5 @@ initrd_phys-y	:= 0x60800000
> >  dtb-$(CONFIG_ARCH_VEXPRESS_DT)	+= vexpress-v2p-ca5s.dtb \
> >  				   vexpress-v2p-ca9.dtb \
> >  				   vexpress-v2p-ca15-tc1.dtb \
> > -				   vexpress-v2p-ca15_a7.dtb
> > +				   vexpress-v2p-ca15_a7.dtb \
> > +				   vexpress-xenvm-4.2.dtb
> > 
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 21 11:15:40 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Sep 2012 11:15:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TF1Ce-0001wE-Na; Fri, 21 Sep 2012 11:15:24 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1TF1Cd-0001w0-5h
	for xen-devel@lists.xensource.com; Fri, 21 Sep 2012 11:15:23 +0000
Received: from [85.158.137.99:30355] by server-6.bemta-3.messagelabs.com id
	BB/00-29694-A4C4C505; Fri, 21 Sep 2012 11:15:22 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-4.tower-217.messagelabs.com!1348226121!18604910!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTA2NjI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22602 invoked from network); 21 Sep 2012 11:15:21 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Sep 2012 11:15:21 -0000
X-IronPort-AV: E=Sophos;i="4.80,462,1344211200"; d="scan'208";a="14687661"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Sep 2012 11: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.279.1; Fri, 21 Sep 2012 12:15:20 +0100
Date: Fri, 21 Sep 2012 12:14:31 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Rob Herring <robherring2@gmail.com>
In-Reply-To: <505B7BEB.6010105@gmail.com>
Message-ID: <alpine.DEB.2.02.1209211211390.29232@kaball.uk.xensource.com>
References: <1348076658-4511-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<505B7BEB.6010105@gmail.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>, Pawel Moll <pawel.moll@arm.com>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Xen-devel] [PATCH] arm: introduce a DTS for Xen unprivileged
 virtual 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 Thu, 20 Sep 2012, Rob Herring wrote:
> On 09/19/2012 12:44 PM, Stefano Stabellini wrote:
> > Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> > CC: Pawel Moll <pawel.moll@arm.com>
> > CC: linux-arm-kernel@lists.infradead.org
> > ---
> >  arch/arm/boot/dts/vexpress-xenvm-4.2.dts |  115 ++++++++++++++++++++++++++++++
> >  arch/arm/mach-vexpress/Makefile.boot     |    3 +-
> >  2 files changed, 117 insertions(+), 1 deletions(-)
> >  create mode 100644 arch/arm/boot/dts/vexpress-xenvm-4.2.dts
> > 
> > diff --git a/arch/arm/boot/dts/vexpress-xenvm-4.2.dts b/arch/arm/boot/dts/vexpress-xenvm-4.2.dts
> > new file mode 100644
> > index 0000000..bfb802c
> > --- /dev/null
> > +++ b/arch/arm/boot/dts/vexpress-xenvm-4.2.dts
> > @@ -0,0 +1,115 @@
> > +/*
> > + * Xen Virtual Machine for unprivileged guests
> > + *
> > + * Based on ARM Ltd. Versatile Express CoreTile Express (single CPU)
> > + * Cortex-A15 MPCore (V2P-CA15)
> > + *
> > + */
> > +
> > +/dts-v1/;
> > +
> > +/include/ "skeleton.dtsi"
> > +
> > +/ {
> > +	model = "XENVM-4.2";
> > +	compatible = "xen,xenvm-4.2", "arm,vexpress";
> > +	interrupt-parent = <&gic>;
> > +
> > +	chosen {
> > +		bootargs = "earlyprintk console=hvc0 root=/dev/xvda init=/sbin/init";
> > +	};
> > +
> > +	cpus {
> > +		#address-cells = <1>;
> > +		#size-cells = <0>;
> > +
> > +		cpu@0 {
> > +			device_type = "cpu";
> > +			compatible = "arm,cortex-a15";
> > +			reg = <0>;
> > +		};
> > +	};
> > +
> > +	memory {
> > +		device_type = "memory";
> > +		reg = <0x80000000 0x08000000>;
> 
> How much guest memory can be supported here?

There are no particular restrictions other than the amount of memory
present on the physical hardware and the memory already used by other
guests.


> I would expect something like the memory size to be filled in by the
> hypervisor. If so, perhaps a note on any fields hypervisor will adjust.
> 

Yes, that's a good idea. Certainly the amount of memory would be
adjusted by the hypervisor. Also the properties of the hypervisor node
and maybe the bootargs could be adjusted too.


> > +	};
> > +
> > +	gic: interrupt-controller@2c001000 {
> > +		compatible = "arm,cortex-a9-gic";
> > +		#interrupt-cells = <3>;
> > +		#address-cells = <0>;
> > +		interrupt-controller;
> > +		reg = <0x2c001000 0x1000>,
> > +		      <0x2c002000 0x100>;
> > +	};
> > +
> > +	timer {
> > +		compatible = "arm,armv7-timer";
> > +		interrupts = <1 13 0xf08>,
> > +			     <1 14 0xf08>,
> > +			     <1 11 0xf08>,
> > +			     <1 10 0xf08>;
> > +	};
> > +
> > +	hypervisor {
> > +		compatible = "xen,xen-4.2", "xen,xen";
> > +		reg = <0xb0000000 0x20000>;
> > +		interrupts = <1 15 0xf08>;
> > +	};
> > +
> > +	motherboard {
> > +		arm,v2m-memory-map = "rs1";
> > +		ranges = <0 0 0x08000000 0x04000000>,
> > +			 <1 0 0x14000000 0x04000000>,
> > +			 <2 0 0x18000000 0x04000000>,
> > +			 <3 0 0x1c000000 0x04000000>,
> > +			 <4 0 0x0c000000 0x04000000>,
> > +			 <5 0 0x10000000 0x04000000>;
> > +
> > +		interrupt-map-mask = <0 0 63>;
> > +		interrupt-map = <0 0  0 &gic 0  0 4>,
> > +				<0 0  1 &gic 0  1 4>,
> > +				<0 0  2 &gic 0  2 4>,
> > +				<0 0  3 &gic 0  3 4>,
> > +				<0 0  4 &gic 0  4 4>,
> > +				<0 0  5 &gic 0  5 4>,
> > +				<0 0  6 &gic 0  6 4>,
> > +				<0 0  7 &gic 0  7 4>,
> > +				<0 0  8 &gic 0  8 4>,
> > +				<0 0  9 &gic 0  9 4>,
> > +				<0 0 10 &gic 0 10 4>,
> > +				<0 0 11 &gic 0 11 4>,
> > +				<0 0 12 &gic 0 12 4>,
> > +				<0 0 13 &gic 0 13 4>,
> > +				<0 0 14 &gic 0 14 4>,
> > +				<0 0 15 &gic 0 15 4>,
> > +				<0 0 16 &gic 0 16 4>,
> > +				<0 0 17 &gic 0 17 4>,
> > +				<0 0 18 &gic 0 18 4>,
> > +				<0 0 19 &gic 0 19 4>,
> > +				<0 0 20 &gic 0 20 4>,
> > +				<0 0 21 &gic 0 21 4>,
> > +				<0 0 22 &gic 0 22 4>,
> > +				<0 0 23 &gic 0 23 4>,
> > +				<0 0 24 &gic 0 24 4>,
> > +				<0 0 25 &gic 0 25 4>,
> > +				<0 0 26 &gic 0 26 4>,
> > +				<0 0 27 &gic 0 27 4>,
> > +				<0 0 28 &gic 0 28 4>,
> > +				<0 0 29 &gic 0 29 4>,
> > +				<0 0 30 &gic 0 30 4>,
> > +				<0 0 31 &gic 0 31 4>,
> > +				<0 0 32 &gic 0 32 4>,
> > +				<0 0 33 &gic 0 33 4>,
> > +				<0 0 34 &gic 0 34 4>,
> > +				<0 0 35 &gic 0 35 4>,
> > +				<0 0 36 &gic 0 36 4>,
> > +				<0 0 37 &gic 0 37 4>,
> > +				<0 0 38 &gic 0 38 4>,
> > +				<0 0 39 &gic 0 39 4>,
> > +				<0 0 40 &gic 0 40 4>,
> > +				<0 0 41 &gic 0 41 4>,
> > +				<0 0 42 &gic 0 42 4>;
> > +	};
> > +};
> > diff --git a/arch/arm/mach-vexpress/Makefile.boot b/arch/arm/mach-vexpress/Makefile.boot
> > index 318d308..5c633c5 100644
> > --- a/arch/arm/mach-vexpress/Makefile.boot
> > +++ b/arch/arm/mach-vexpress/Makefile.boot
> > @@ -7,4 +7,5 @@ initrd_phys-y	:= 0x60800000
> >  dtb-$(CONFIG_ARCH_VEXPRESS_DT)	+= vexpress-v2p-ca5s.dtb \
> >  				   vexpress-v2p-ca9.dtb \
> >  				   vexpress-v2p-ca15-tc1.dtb \
> > -				   vexpress-v2p-ca15_a7.dtb
> > +				   vexpress-v2p-ca15_a7.dtb \
> > +				   vexpress-xenvm-4.2.dtb
> > 
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 21 11:18:21 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Sep 2012 11:18:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TF1FI-000287-Ao; Fri, 21 Sep 2012 11:18:08 +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 1TF1FG-00027y-G5
	for xen-devel@lists.xensource.com; Fri, 21 Sep 2012 11:18:06 +0000
Received: from [85.158.138.51:41741] by server-5.bemta-3.messagelabs.com id
	30/01-13133-DEC4C505; Fri, 21 Sep 2012 11:18:05 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1348226284!29672561!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTA2NjI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20738 invoked from network); 21 Sep 2012 11:18:05 -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;
	21 Sep 2012 11:18:05 -0000
X-IronPort-AV: E=Sophos;i="4.80,462,1344211200"; d="scan'208";a="14687716"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Sep 2012 11:18: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.279.1; Fri, 21 Sep 2012 12:18:04 +0100
Date: Fri, 21 Sep 2012 12:17:15 +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: <20120920212948.GF27312@konrad-lan.dumpdata.com>
Message-ID: <alpine.DEB.2.02.1209211214520.29232@kaball.uk.xensource.com>
References: <1348076658-4511-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<1348135563.11116.94.camel@hornet>
	<20120920111815.GC2117@linaro.org>
	<20120920212948.GF27312@konrad-lan.dumpdata.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: Dave Martin <dave.martin@linaro.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, Pawel Moll <pawel.moll@arm.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Xen-devel] [PATCH] arm: introduce a DTS for Xen unprivileged
 virtual 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 Thu, 20 Sep 2012, Konrad Rzeszutek Wilk wrote:
> On Thu, Sep 20, 2012 at 12:18:15PM +0100, Dave Martin wrote:
> > On Thu, Sep 20, 2012 at 11:06:03AM +0100, Pawel Moll wrote:
> > > Morning,
> > > 
> > > On Wed, 2012-09-19 at 18:44 +0100, Stefano Stabellini wrote:
> > > > +/dts-v1/;
> > > > +
> > > > +/include/ "skeleton.dtsi"
> > > 
> > > Any particular reason to include skeleton? And I think it would be
> > > better to use #address-cells = <2> and #size-cells = <2>, to be ready
> > > for LPAE addresses...
> > > 
> > > > +/ {
> > > > +	model = "XENVM-4.2";
> > > > +	compatible = "xen,xenvm-4.2", "arm,vexpress";
> > > > +	interrupt-parent = <&gic>;
> > > > +
> > > > +	chosen {
> > > > +		bootargs = "earlyprintk console=hvc0 root=/dev/xvda init=/sbin/init";
> 
> earlyprintk=xen ?
> 

earlyprintk is not "selectable" on ARM (that would be a nice addition
though). It just goes to the configured uart, that is the only piece of
hardware that is being emulated by Xen at the moment.

In any case I have removed anything debug related, including
earlyprintk, from the default bootargs.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 21 11:18:21 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Sep 2012 11:18:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TF1FI-000287-Ao; Fri, 21 Sep 2012 11:18:08 +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 1TF1FG-00027y-G5
	for xen-devel@lists.xensource.com; Fri, 21 Sep 2012 11:18:06 +0000
Received: from [85.158.138.51:41741] by server-5.bemta-3.messagelabs.com id
	30/01-13133-DEC4C505; Fri, 21 Sep 2012 11:18:05 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1348226284!29672561!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTA2NjI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20738 invoked from network); 21 Sep 2012 11:18:05 -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;
	21 Sep 2012 11:18:05 -0000
X-IronPort-AV: E=Sophos;i="4.80,462,1344211200"; d="scan'208";a="14687716"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Sep 2012 11:18: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.279.1; Fri, 21 Sep 2012 12:18:04 +0100
Date: Fri, 21 Sep 2012 12:17:15 +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: <20120920212948.GF27312@konrad-lan.dumpdata.com>
Message-ID: <alpine.DEB.2.02.1209211214520.29232@kaball.uk.xensource.com>
References: <1348076658-4511-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<1348135563.11116.94.camel@hornet>
	<20120920111815.GC2117@linaro.org>
	<20120920212948.GF27312@konrad-lan.dumpdata.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: Dave Martin <dave.martin@linaro.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, Pawel Moll <pawel.moll@arm.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Xen-devel] [PATCH] arm: introduce a DTS for Xen unprivileged
 virtual 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 Thu, 20 Sep 2012, Konrad Rzeszutek Wilk wrote:
> On Thu, Sep 20, 2012 at 12:18:15PM +0100, Dave Martin wrote:
> > On Thu, Sep 20, 2012 at 11:06:03AM +0100, Pawel Moll wrote:
> > > Morning,
> > > 
> > > On Wed, 2012-09-19 at 18:44 +0100, Stefano Stabellini wrote:
> > > > +/dts-v1/;
> > > > +
> > > > +/include/ "skeleton.dtsi"
> > > 
> > > Any particular reason to include skeleton? And I think it would be
> > > better to use #address-cells = <2> and #size-cells = <2>, to be ready
> > > for LPAE addresses...
> > > 
> > > > +/ {
> > > > +	model = "XENVM-4.2";
> > > > +	compatible = "xen,xenvm-4.2", "arm,vexpress";
> > > > +	interrupt-parent = <&gic>;
> > > > +
> > > > +	chosen {
> > > > +		bootargs = "earlyprintk console=hvc0 root=/dev/xvda init=/sbin/init";
> 
> earlyprintk=xen ?
> 

earlyprintk is not "selectable" on ARM (that would be a nice addition
though). It just goes to the configured uart, that is the only piece of
hardware that is being emulated by Xen at the moment.

In any case I have removed anything debug related, including
earlyprintk, from the default bootargs.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 21 11:29:24 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Sep 2012 11:29: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 1TF1Py-0002MD-LS; Fri, 21 Sep 2012 11:29: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 1TF1Pv-0002M5-S3
	for xen-devel@lists.xen.org; Fri, 21 Sep 2012 11:29:08 +0000
Received: from [85.158.143.35:62233] by server-2.bemta-4.messagelabs.com id
	27/28-06610-38F4C505; Fri, 21 Sep 2012 11:29:07 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1348226911!15797013!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29280 invoked from network); 21 Sep 2012 11:28:31 -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;
	21 Sep 2012 11:28:31 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 21 Sep 2012 12:28:30 +0100
Message-Id: <505C6B7C020000780009CF08@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 21 Sep 2012 12:28:28 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part6756664C.0__="
Subject: [Xen-devel] [PATCH] printk: prefer %#x et at over 0x%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.

--=__Part6756664C.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Performance is not an issue with printk(), so let the function do
minimally more work and instead save a byte per affected format
specifier.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- 2012-09-21.orig/xen/arch/x86/acpi/boot.c	2012-09-20 08:44:38.0000000=
00 +0200
+++ 2012-09-21/xen/arch/x86/acpi/boot.c	2012-09-21 10:54:46.000000000 =
+0200
@@ -341,14 +341,14 @@ acpi_fadt_parse_sleep_info(struct acpi_t
 	}
=20
 	if (facs->length < 24) {
-		printk(KERN_ERR PREFIX "Invalid FACS table length: 0x%x",
+		printk(KERN_ERR PREFIX "Invalid FACS table length: %#x",
 			facs->length);
 		goto bad;
 	}
=20
 	if (facs->length < 64)
 		printk(KERN_WARNING PREFIX
-			"FACS is shorter than ACPI spec allow: 0x%x",
+			"FACS is shorter than ACPI spec allow: %#x",
 			facs->length);
=20
 	acpi_sinfo.wakeup_vector =3D facs_pa +=20
--- 2012-09-21.orig/xen/arch/x86/acpi/cpu_idle.c	2012-08-15 =
08:32:43.000000000 +0200
+++ 2012-09-21/xen/arch/x86/acpi/cpu_idle.c	2012-09-21 10:54:46.0000000=
00 +0200
@@ -978,11 +978,11 @@ static void print_cx_pminfo(uint32_t cpu
             return;
        =20
         printk("\tstates[%d]:\n", i);
-        printk("\t\treg.space_id =3D 0x%x\n", state.reg.space_id);
-        printk("\t\treg.bit_width =3D 0x%x\n", state.reg.bit_width);
-        printk("\t\treg.bit_offset =3D 0x%x\n", state.reg.bit_offset);
-        printk("\t\treg.access_size =3D 0x%x\n", state.reg.access_size);
-        printk("\t\treg.address =3D 0x%"PRIx64"\n", state.reg.address);
+        printk("\t\treg.space_id =3D %#x\n", state.reg.space_id);
+        printk("\t\treg.bit_width =3D %#x\n", state.reg.bit_width);
+        printk("\t\treg.bit_offset =3D %#x\n", state.reg.bit_offset);
+        printk("\t\treg.access_size =3D %#x\n", state.reg.access_size);
+        printk("\t\treg.address =3D %#"PRIx64"\n", state.reg.address);
         printk("\t\ttype    =3D %d\n", state.type);
         printk("\t\tlatency =3D %d\n", state.latency);
         printk("\t\tpower   =3D %d\n", state.power);
--- 2012-09-21.orig/xen/arch/x86/apic.c	2012-09-17 09:57:54.000000000 =
+0200
+++ 2012-09-21/xen/arch/x86/apic.c	2012-09-21 10:54:46.000000000 =
+0200
@@ -689,7 +689,7 @@ void __devinit setup_local_APIC(void)
         value =3D apic_read(APIC_ESR);
         if (value !=3D oldvalue)
             apic_printk(APIC_VERBOSE, "ESR value before enabling "
-                        "vector: 0x%08lx  after: 0x%08lx\n",
+                        "vector: %#lx  after: %#lx\n",
                         oldvalue, value);
     } else {
         if (esr_disable)   =20
@@ -1210,7 +1210,7 @@ static int __init calibrate_APIC_clock(v
     bus_cycle  =3D (u32) (1000000000000LL/bus_freq); /* in pico seconds =
*/
     bus_scale  =3D (1000*262144)/bus_cycle;
=20
-    apic_printk(APIC_VERBOSE, "..... bus_scale =3D 0x%08X\n", bus_scale);
+    apic_printk(APIC_VERBOSE, "..... bus_scale =3D %#x\n", bus_scale);
     /* reset APIC to zero timeout value */
     __setup_APIC_LVTT(0);
=20
--- 2012-09-21.orig/xen/arch/x86/cpu/mcheck/mce.c	2012-09-20 =
08:44:38.000000000 +0200
+++ 2012-09-21/xen/arch/x86/cpu/mcheck/mce.c	2012-09-21 10:54:46.0000000=
00 +0200
@@ -1147,7 +1147,7 @@ static int x86_mc_msrinject_verify(struc
         }
=20
         if (reason !=3D NULL) {
-            printk("HV MSR INJECT ERROR: MSR 0x%llx %s\n",
+            printk("HV MSR INJECT ERROR: MSR %#Lx %s\n",
                    (unsigned long long)mci->mcinj_msr[i].reg, reason);
             errs++;
         }
@@ -1191,8 +1191,7 @@ static void x86_mc_msrinject(void *data)
=20
     for (i =3D 0, msr =3D &mci->mcinj_msr[0];
          i < mci->mcinj_count; i++, msr++) {
-        printk("HV MSR INJECT (%s) target %u actual %u MSR 0x%llx "
-               "<-- 0x%llx\n",
+        printk("HV MSR INJECT (%s) target %u actual %u MSR %#Lx <-- =
%#Lx\n",
                intpose ?  "interpose" : "hardware",
                mci->mcinj_cpunr, smp_processor_id(),
                (unsigned long long)msr->reg,
--- 2012-09-21.orig/xen/arch/x86/cpu/mcheck/vmce.c	2012-08-08 =
08:20:09.000000000 +0200
+++ 2012-09-21/xen/arch/x86/cpu/mcheck/vmce.c	2012-09-21 10:54:46.0000000=
00 +0200
@@ -88,7 +88,7 @@ static int bank_mce_rdmsr(const struct v
     case MSR_IA32_MC0_CTL:
         /* stick all 1's to MCi_CTL */
         *val =3D ~0UL;
-        mce_printk(MCE_VERBOSE, "MCE: rdmsr MC%u_CTL 0x%"PRIx64"\n",
+        mce_printk(MCE_VERBOSE, "MCE: rdmsr MC%u_CTL %#"PRIx64"\n",
                    bank, *val);
         break;
     case MSR_IA32_MC0_STATUS:
@@ -102,7 +102,7 @@ static int bank_mce_rdmsr(const struct v
                 *val =3D entry->mci_status;
                 mce_printk(MCE_VERBOSE,
                            "MCE: rd MC%u_STATUS in vMCE# context "
-                           "value 0x%"PRIx64"\n", bank, *val);
+                           "value %#"PRIx64"\n", bank, *val);
             }
         }
         break;
@@ -116,7 +116,7 @@ static int bank_mce_rdmsr(const struct v
                 *val =3D entry->mci_addr;
                 mce_printk(MCE_VERBOSE,
                            "MCE: rdmsr MC%u_ADDR in vMCE# context "
-                           "0x%"PRIx64"\n", bank, *val);
+                           "%#"PRIx64"\n", bank, *val);
             }
         }
         break;
@@ -130,7 +130,7 @@ static int bank_mce_rdmsr(const struct v
                 *val =3D entry->mci_misc;
                 mce_printk(MCE_VERBOSE,
                            "MCE: rd MC%u_MISC in vMCE# context "
-                           "0x%"PRIx64"\n", bank, *val);
+                           "%#"PRIx64"\n", bank, *val);
             }
         }
         break;
@@ -171,18 +171,18 @@ int vmce_rdmsr(uint32_t msr, uint64_t *v
         *val =3D vmce->mcg_status;
         if (*val)
             mce_printk(MCE_VERBOSE,
-                       "MCE: rdmsr MCG_STATUS 0x%"PRIx64"\n", *val);
+                       "MCE: rdmsr MCG_STATUS %#"PRIx64"\n", *val);
         break;
     case MSR_IA32_MCG_CAP:
         *val =3D cur->arch.mcg_cap;
-        mce_printk(MCE_VERBOSE, "MCE: rdmsr MCG_CAP 0x%"PRIx64"\n",
+        mce_printk(MCE_VERBOSE, "MCE: rdmsr MCG_CAP %#"PRIx64"\n",
                    *val);
         break;
     case MSR_IA32_MCG_CTL:
         /* Stick all 1's when CTL support, and 0's when no CTL support */
         if ( cur->arch.mcg_cap & MCG_CTL_P )
             *val =3D ~0ULL;
-        mce_printk(MCE_VERBOSE, "MCE: rdmsr MCG_CTL 0x%"PRIx64"\n", =
*val);
+        mce_printk(MCE_VERBOSE, "MCE: rdmsr MCG_CTL %#"PRIx64"\n", *val);
         break;
     default:
         ret =3D mce_bank_msr(cur, msr) ? bank_mce_rdmsr(cur, msr, val) : =
0;
--- 2012-09-21.orig/xen/arch/x86/cpu/mtrr/generic.c	2011-04-11 =
08:33:59.000000000 +0200
+++ 2012-09-21/xen/arch/x86/cpu/mtrr/generic.c	2012-09-21 10:54:46.0000000=
00 +0200
@@ -410,7 +410,7 @@ int generic_validate_add_page(unsigned l
 	    boot_cpu_data.x86_model =3D=3D 1 &&
 	    boot_cpu_data.x86_mask <=3D 7) {
 		if (base & ((1 << (22 - PAGE_SHIFT)) - 1)) {
-			printk(KERN_WARNING "mtrr: base(0x%lx000) is not 4 =
MiB aligned\n", base);
+			printk(KERN_WARNING "mtrr: base(%#lx000) is not 4 =
MiB aligned\n", base);
 			return -EINVAL;
 		}
 		if (!(base + size < 0x70000 || base > 0x7003F) &&
@@ -427,7 +427,7 @@ int generic_validate_add_page(unsigned l
 	for (lbase =3D base; !(lbase & 1) && (last & 1);
 	     lbase =3D lbase >> 1, last =3D last >> 1) ;
 	if (lbase !=3D last) {
-		printk(KERN_WARNING "mtrr: base(0x%lx000) is not aligned =
on a size(0x%lx000) boundary\n",
+		printk(KERN_WARNING "mtrr: base(%#lx000) is not aligned on =
a size(%#lx000) boundary\n",
 		       base, size);
 		return -EINVAL;
 	}
--- 2012-09-21.orig/xen/arch/x86/cpu/mtrr/main.c	2012-09-21 =
10:32:44.000000000 +0200
+++ 2012-09-21/xen/arch/x86/cpu/mtrr/main.c	2012-09-21 10:54:46.0000000=
00 +0200
@@ -366,8 +366,8 @@ int mtrr_add_page(unsigned long base, un
 					continue;
 			}
 			printk(KERN_WARNING
-			       "mtrr: 0x%lx000,0x%lx000 overlaps existing"
-			       " 0x%lx000,0x%lx000\n", base, size, lbase,
+			       "mtrr: %#lx000,%#lx000 overlaps existing"
+			       " %#lx000,%#lx000\n", base, size, lbase,
 			       lsize);
 			goto out;
 		}
@@ -412,7 +412,7 @@ static int mtrr_check(unsigned long base
 		printk(KERN_WARNING
 			"mtrr: size and base must be multiples of 4 =
kiB\n");
 		printk(KERN_DEBUG
-			"mtrr: size: 0x%lx  base: 0x%lx\n", size, base);
+			"mtrr: size: %#lx  base: %#lx\n", size, base);
 		dump_stack();
 		return -1;
 	}
--- 2012-09-21.orig/xen/arch/x86/domain_build.c	2012-09-14 13:26:34.0000000=
00 +0200
+++ 2012-09-21/xen/arch/x86/domain_build.c	2012-09-21 10:55:47.0000000=
00 +0200
@@ -396,13 +396,13 @@ int __init construct_dom0(
     }
     if (elf_64bit(&elf) && machine =3D=3D EM_X86_64)
         compatible =3D 1;
-    printk(" Dom0 kernel: %s%s, %s, paddr 0x%" PRIx64 " -> 0x%" PRIx64 =
"\n",
+    printk(" Dom0 kernel: %s%s, %s, paddr %#" PRIx64 " -> %#" PRIx64 =
"\n",
            elf_64bit(&elf) ? "64-bit" : "32-bit",
            parms.pae       ? ", PAE"  : "",
            elf_msb(&elf)   ? "msb"    : "lsb",
            elf.pstart, elf.pend);
     if ( elf.bsd_symtab_pstart )
-        printk(" Dom0 symbol map 0x%" PRIx64 " -> 0x%" PRIx64 "\n",
+        printk(" Dom0 symbol map %#" PRIx64 " -> %#" PRIx64 "\n",
                elf.bsd_symtab_pstart, elf.bsd_symtab_pend);
=20
     if ( !compatible )
--- 2012-09-21.orig/xen/arch/x86/hvm/hvm.c	2012-09-20 08:44:38.0000000=
00 +0200
+++ 2012-09-21/xen/arch/x86/hvm/hvm.c	2012-09-21 10:54:46.000000000 =
+0200
@@ -1468,7 +1468,7 @@ int hvm_set_efer(uint64_t value)
     if ( !hvm_efer_valid(v->domain, value, efer_validbits) )
     {
         gdprintk(XENLOG_WARNING, "Trying to set reserved bit in "
-                 "EFER: 0x%"PRIx64"\n", value);
+                 "EFER: %#"PRIx64"\n", value);
         hvm_inject_hw_exception(TRAP_gp_fault, 0);
         return X86EMUL_EXCEPTION;
     }
@@ -4095,7 +4095,7 @@ long do_hvm_op(unsigned long op, XEN_GUE
             {
                 put_gfn(d, pfn);
                 gdprintk(XENLOG_WARNING,
-                         "type for pfn 0x%lx changed to grant while "
+                         "type for pfn %#lx changed to grant while "
                          "we were working?\n", pfn);
                 goto param_fail4;
             }
@@ -4106,7 +4106,7 @@ long do_hvm_op(unsigned long op, XEN_GUE
                 {
                     put_gfn(d, pfn);
                     gdprintk(XENLOG_WARNING,
-                             "type of pfn 0x%lx changed from %d to %d =
while "
+                             "type of pfn %#lx changed from %d to %d =
while "
                              "we were trying to change it to %d\n",
                              pfn, t, nt, memtype[a.hvmmem_type]);
                     goto param_fail4;
--- 2012-09-21.orig/xen/arch/x86/hvm/io.c	2012-07-30 09:49:58.0000000=
00 +0200
+++ 2012-09-21/xen/arch/x86/hvm/io.c	2012-09-21 10:54:46.000000000 =
+0200
@@ -393,7 +393,7 @@ int dpci_ioport_intercept(ioreq_t *p)
=20
     if ( !ioports_access_permitted(d, mport, mport + p->size - 1) )=20
     {
-        gdprintk(XENLOG_ERR, "Error: access to gport=3D0x%x denied!\n",
+        gdprintk(XENLOG_ERR, "Error: access to gport=3D%#x denied!\n",
                  (uint32_t)p->addr);
         return X86EMUL_UNHANDLEABLE;
     }
--- 2012-09-21.orig/xen/arch/x86/hvm/irq.c	2012-09-14 13:26:34.0000000=
00 +0200
+++ 2012-09-21/xen/arch/x86/hvm/irq.c	2012-09-21 10:54:46.000000000 =
+0200
@@ -488,7 +488,7 @@ static void irq_dump(struct domain *d)
            hvm_irq->pci_link_assert_count[1],
            hvm_irq->pci_link_assert_count[2],
            hvm_irq->pci_link_assert_count[3]);
-    printk("Callback via %i:0x%"PRIx32",%s asserted\n",=20
+    printk("Callback via %i:%#"PRIx32",%s asserted\n",
            hvm_irq->callback_via_type, hvm_irq->callback_via.gsi,=20
            hvm_irq->callback_via_asserted ? "" : " not");
 }
--- 2012-09-21.orig/xen/arch/x86/hvm/svm/intr.c	2012-01-20 10:10:22.0000000=
00 +0100
+++ 2012-09-21/xen/arch/x86/hvm/svm/intr.c	2012-09-21 10:54:46.0000000=
00 +0200
@@ -175,7 +175,7 @@ void svm_intr_assist(void)=20
                 /* Guest already enabled an interrupt window. */
                 return;
             default:
-                panic("%s: nestedsvm_vcpu_interrupt can't handle value =
0x%x\n",
+                panic("%s: nestedsvm_vcpu_interrupt can't handle value =
%#x\n",
                     __func__, rc);
             }
         }
--- 2012-09-21.orig/xen/arch/x86/hvm/svm/nestedsvm.c	2012-09-05 =
11:59:49.000000000 +0200
+++ 2012-09-21/xen/arch/x86/hvm/svm/nestedsvm.c	2012-09-21 10:54:46.0000000=
00 +0200
@@ -943,7 +943,7 @@ nsvm_vmcb_guest_intercepts_exitcode(stru
         break;
=20
     default:
-        gdprintk(XENLOG_ERR, "Illegal exitcode 0x%"PRIx64"\n", exitcode);
+        gdprintk(XENLOG_ERR, "Illegal exitcode %#"PRIx64"\n", exitcode);
         BUG();
         break;
     }
@@ -1235,7 +1235,7 @@ int nsvm_wrmsr(struct vcpu *v, unsigned=20
     case MSR_K8_VM_HSAVE_PA:
         if (!nestedsvm_vmcb_isvalid(v, msr_content)) {
             gdprintk(XENLOG_ERR,
-                "MSR_K8_VM_HSAVE_PA value invalid 0x%"PRIx64"\n", =
msr_content);
+                "MSR_K8_VM_HSAVE_PA value invalid %#"PRIx64"\n", =
msr_content);
             ret =3D -1; /* inject #GP */
             break;
         }
@@ -1244,7 +1244,7 @@ int nsvm_wrmsr(struct vcpu *v, unsigned=20
     case MSR_AMD64_TSC_RATIO:
         if ((msr_content & ~TSC_RATIO_RSVD_BITS) !=3D msr_content) {
             gdprintk(XENLOG_ERR,
-                "reserved bits set in MSR_AMD64_TSC_RATIO 0x%"PRIx64"\n",
+                "reserved bits set in MSR_AMD64_TSC_RATIO %#"PRIx64"\n",
                 msr_content);
             ret =3D -1; /* inject #GP */
             break;
--- 2012-09-21.orig/xen/arch/x86/hvm/svm/svm.c	2012-09-17 09:57:54.0000000=
00 +0200
+++ 2012-09-21/xen/arch/x86/hvm/svm/svm.c	2012-09-21 10:54:46.0000000=
00 +0200
@@ -241,7 +241,7 @@ static int svm_vmcb_restore(struct vcpu=20
          ((c->pending_type =3D=3D 1) || (c->pending_type > 6) ||
           (c->pending_reserved !=3D 0)) )
     {
-        gdprintk(XENLOG_ERR, "Invalid pending event 0x%"PRIx32".\n",
+        gdprintk(XENLOG_ERR, "Invalid pending event %#"PRIx32".\n",
                  c->pending_event);
         return -EINVAL;
     }
@@ -254,7 +254,7 @@ static int svm_vmcb_restore(struct vcpu=20
                                      NULL, P2M_ALLOC);
             if ( !page )
             {
-                gdprintk(XENLOG_ERR, "Invalid CR3 value=3D0x%"PRIx64"\n",
+                gdprintk(XENLOG_ERR, "Invalid CR3 value=3D%#"PRIx64"\n",
                          c->cr3);
                 return -EINVAL;
             }
@@ -289,7 +289,7 @@ static int svm_vmcb_restore(struct vcpu=20
=20
     if ( c->pending_valid )=20
     {
-        gdprintk(XENLOG_INFO, "Re-injecting 0x%"PRIx32", 0x%"PRIx32"\n",
+        gdprintk(XENLOG_INFO, "Re-injecting %#"PRIx32", %#"PRIx32"\n",
                  c->pending_event, c->error_code);
=20
         if ( hvm_event_needs_reinjection(c->pending_type, c->pending_vecto=
r) )
@@ -2398,8 +2398,8 @@ void svm_vmexit_handler(struct cpu_user_
=20
     default:
     exit_and_crash:
-        gdprintk(XENLOG_ERR, "unexpected VMEXIT: exit reason =3D =
0x%"PRIx64", "
-                 "exitinfo1 =3D %"PRIx64", exitinfo2 =3D %"PRIx64"\n",
+        gdprintk(XENLOG_ERR, "unexpected VMEXIT: exit reason =3D =
%#"PRIx64", "
+                 "exitinfo1 =3D %#"PRIx64", exitinfo2 =3D %#"PRIx64"\n",
                  exit_reason,=20
                  (u64)vmcb->exitinfo1, (u64)vmcb->exitinfo2);
         domain_crash(v->domain);
--- 2012-09-21.orig/xen/arch/x86/hvm/svm/svmdebug.c	2011-07-11 =
08:32:12.000000000 +0200
+++ 2012-09-21/xen/arch/x86/hvm/svm/svmdebug.c	2012-09-21 10:54:46.0000000=
00 +0200
@@ -32,33 +32,32 @@ static void svm_dump_sel(const char *nam
 void svm_vmcb_dump(const char *from, struct vmcb_struct *vmcb)
 {
     printk("Dumping guest's current state at %s...\n", from);
-    printk("Size of VMCB =3D %d, paddr =3D 0x%016lx, vaddr =3D %p\n",
+    printk("Size of VMCB =3D %d, paddr =3D %#lx, vaddr =3D %p\n",
            (int) sizeof(struct vmcb_struct), virt_to_maddr(vmcb), vmcb);
=20
-    printk("cr_intercepts =3D 0x%08x dr_intercepts =3D 0x%08x "
-           "exception_intercepts =3D 0x%08x\n",=20
+    printk("cr_intercepts =3D %#x dr_intercepts =3D %#x "
+           "exception_intercepts =3D %#x\n",
            vmcb->_cr_intercepts, vmcb->_dr_intercepts,=20
            vmcb->_exception_intercepts);
-    printk("general1_intercepts =3D 0x%08x general2_intercepts =3D =
0x%08x\n",=20
+    printk("general1_intercepts =3D %#x general2_intercepts =3D %#x\n",
            vmcb->_general1_intercepts, vmcb->_general2_intercepts);
-    printk("iopm_base_pa =3D 0x%016llx msrpm_base_pa =3D 0x%016llx =
tsc_offset =3D "
-            "0x%016llx\n",=20
+    printk("iopm_base_pa =3D %#Lx msrpm_base_pa =3D %#Lx tsc_offset =3D =
%#Lx\n",
            (unsigned long long)vmcb->_iopm_base_pa,
            (unsigned long long)vmcb->_msrpm_base_pa,
            (unsigned long long)vmcb->_tsc_offset);
-    printk("tlb_control =3D 0x%08x vintr =3D 0x%016llx interrupt_shadow =
=3D "
-            "0x%016llx\n", vmcb->tlb_control,
+    printk("tlb_control =3D %#x vintr =3D %#Lx interrupt_shadow =3D =
%#Lx\n",
+           vmcb->tlb_control,
            (unsigned long long)vmcb->_vintr.bytes,
            (unsigned long long)vmcb->interrupt_shadow);
-    printk("exitcode =3D 0x%016llx exitintinfo =3D 0x%016llx\n",=20
+    printk("exitcode =3D %#Lx exitintinfo =3D %#Lx\n",
            (unsigned long long)vmcb->exitcode,
            (unsigned long long)vmcb->exitintinfo.bytes);
-    printk("exitinfo1 =3D 0x%016llx exitinfo2 =3D 0x%016llx \n",
+    printk("exitinfo1 =3D %#Lx exitinfo2 =3D %#Lx \n",
            (unsigned long long)vmcb->exitinfo1,
            (unsigned long long)vmcb->exitinfo2);
-    printk("np_enable =3D 0x%016llx guest_asid =3D 0x%03x\n",=20
+    printk("np_enable =3D %Lx guest_asid =3D %#x\n",
            (unsigned long long)vmcb->_np_enable, vmcb->_guest_asid);
-    printk("cpl =3D %d efer =3D 0x%016llx star =3D 0x%016llx lstar =3D =
0x%016llx\n",=20
+    printk("cpl =3D %d efer =3D %#Lx star =3D %#Lx lstar =3D %#Lx\n",
            vmcb->_cpl, (unsigned long long)vmcb->_efer,
            (unsigned long long)vmcb->star, (unsigned long long)vmcb->lstar=
);
     printk("CR0 =3D 0x%016llx CR2 =3D 0x%016llx\n",
@@ -77,7 +76,7 @@ void svm_vmcb_dump(const char *from, str
     printk("KernGSBase =3D 0x%016llx PAT =3D 0x%016llx \n",=20
            (unsigned long long)vmcb->kerngsbase,
            (unsigned long long)vmcb->_g_pat);
-    printk("H_CR3 =3D 0x%016llx CleanBits =3D 0x%08x\n",
+    printk("H_CR3 =3D 0x%016llx CleanBits =3D %#x\n",
            (unsigned long long)vmcb->_h_cr3, vmcb->cleanbits.bytes);
=20
     /* print out all the selectors */
@@ -104,48 +103,48 @@ svm_vmcb_isvalid(const char *from, struc
     } else return 1;
=20
     if ((vmcb->_efer & EFER_SVME) =3D=3D 0) {
-        PRINTF("EFER: SVME bit not set (0x%"PRIx64")\n", vmcb->_efer);
+        PRINTF("EFER: SVME bit not set (%#"PRIx64")\n", vmcb->_efer);
     }
=20
     if ((vmcb->_cr0 & X86_CR0_CD) =3D=3D 0 && (vmcb->_cr0 & X86_CR0_NW) =
!=3D 0) {
-        PRINTF("CR0: CD bit is zero and NW bit set (0x%"PRIx64")\n",
+        PRINTF("CR0: CD bit is zero and NW bit set (%#"PRIx64")\n",
                 vmcb->_cr0);
     }
=20
     if ((vmcb->_cr0 >> 32U) !=3D 0) {
-        PRINTF("CR0: bits [63:32] are not zero (0x%"PRIx64")\n",
+        PRINTF("CR0: bits [63:32] are not zero (%#"PRIx64")\n",
                 vmcb->_cr0);
     }
=20
     if ((vmcb->_cr3 & 0x7) !=3D 0) {
-        PRINTF("CR3: MBZ bits are set (0x%"PRIx64")\n", vmcb->_cr3);
+        PRINTF("CR3: MBZ bits are set (%#"PRIx64")\n", vmcb->_cr3);
     }
     if ((vmcb->_efer & EFER_LMA) && (vmcb->_cr3 & 0xfe) !=3D 0) {
-        PRINTF("CR3: MBZ bits are set (0x%"PRIx64")\n", vmcb->_cr3);
+        PRINTF("CR3: MBZ bits are set (%#"PRIx64")\n", vmcb->_cr3);
     }
=20
     if ((vmcb->_cr4 >> 19U) !=3D 0) {
-        PRINTF("CR4: bits [63:19] are not zero (0x%"PRIx64")\n",
+        PRINTF("CR4: bits [63:19] are not zero (%#"PRIx64")\n",
                 vmcb->_cr4);
     }
=20
     if (((vmcb->_cr4 >> 11U) & 0x7fU) !=3D 0) {
-        PRINTF("CR4: bits [17:11] are not zero (0x%"PRIx64")\n",
+        PRINTF("CR4: bits [17:11] are not zero (%#"PRIx64")\n",
                 vmcb->_cr4);
     }
=20
     if ((vmcb->_dr6 >> 32U) !=3D 0) {
-        PRINTF("DR6: bits [63:32] are not zero (0x%"PRIx64")\n",
+        PRINTF("DR6: bits [63:32] are not zero (%#"PRIx64")\n",
                 vmcb->_dr6);
     }
=20
     if ((vmcb->_dr7 >> 32U) !=3D 0) {
-        PRINTF("DR7: bits [63:32] are not zero (0x%"PRIx64")\n",
+        PRINTF("DR7: bits [63:32] are not zero (%#"PRIx64")\n",
                 vmcb->_dr7);
     }
=20
     if ((vmcb->_efer >> 15U) !=3D 0) {
-        PRINTF("EFER: bits [63:15] are not zero (0x%"PRIx64")\n",
+        PRINTF("EFER: bits [63:15] are not zero (%#"PRIx64")\n",
                 vmcb->_efer);
     }
=20
@@ -168,12 +167,12 @@ svm_vmcb_isvalid(const char *from, struc
     }
=20
     if ((vmcb->_general2_intercepts & GENERAL2_INTERCEPT_VMRUN) =3D=3D 0) =
{
-        PRINTF("GENERAL2_INTERCEPT: VMRUN intercept bit is clear =
(0x%"PRIx32")\n",
+        PRINTF("GENERAL2_INTERCEPT: VMRUN intercept bit is clear =
(%#"PRIx32")\n",
             vmcb->_general2_intercepts);
     }
=20
     if (vmcb->eventinj.fields.resvd1 !=3D 0) {
-        PRINTF("eventinj: MBZ bits are set (0x%"PRIx64")\n",
+        PRINTF("eventinj: MBZ bits are set (%#"PRIx64")\n",
                 vmcb->eventinj.bytes);
     }
=20
--- 2012-09-21.orig/xen/arch/x86/hvm/vlapic.c	2012-09-20 08:44:38.0000000=
00 +0200
+++ 2012-09-21/xen/arch/x86/hvm/vlapic.c	2012-09-21 10:54:46.0000000=
00 +0200
@@ -172,7 +172,7 @@ static uint32_t vlapic_get_ppr(struct vl
         ppr =3D isrv & 0xf0;
=20
     HVM_DBG_LOG(DBG_LEVEL_VLAPIC_INTERRUPT,
-                "vlapic %p, ppr 0x%x, isr 0x%x, isrv 0x%x",
+                "vlapic %p, ppr %#x, isr %#x, isrv %#x",
                 vlapic, ppr, isr, isrv);
=20
     return ppr;
@@ -215,8 +215,8 @@ bool_t vlapic_match_dest(
     struct vlapic *target, struct vlapic *source,
     int short_hand, uint8_t dest, uint8_t dest_mode)
 {
-    HVM_DBG_LOG(DBG_LEVEL_VLAPIC, "target %p, source %p, dest 0x%x, "
-                "dest_mode 0x%x, short_hand 0x%x",
+    HVM_DBG_LOG(DBG_LEVEL_VLAPIC, "target %p, source %p, dest %#x, "
+                "dest_mode %#x, short_hand %#x",
                 target, source, dest, dest_mode, short_hand);
=20
     switch ( short_hand )
@@ -562,20 +562,20 @@ static int vlapic_read(
         break;
=20
     default:
-        gdprintk(XENLOG_ERR, "Local APIC read with len=3D0x%lx, "
+        gdprintk(XENLOG_ERR, "Local APIC read with len=3D%#lx, "
                  "should be 4 instead.\n", len);
         goto exit_and_crash;
     }
=20
-    HVM_DBG_LOG(DBG_LEVEL_VLAPIC, "offset 0x%x with length 0x%lx, "
-                "and the result is 0x%lx", offset, len, result);
+    HVM_DBG_LOG(DBG_LEVEL_VLAPIC, "offset %#x with length %#lx, "
+                "and the result is %#lx", offset, len, result);
=20
  out:
     *pval =3D result;
     return X86EMUL_OKAY;
=20
  unaligned_exit_and_crash:
-    gdprintk(XENLOG_ERR, "Unaligned LAPIC read len=3D0x%lx at offset=3D0x%=
x.\n",
+    gdprintk(XENLOG_ERR, "Unaligned LAPIC read len=3D%#lx at offset=3D%#x.=
\n",
              len, offset);
  exit_and_crash:
     domain_crash(v->domain);
@@ -759,7 +759,7 @@ static int vlapic_reg_write(struct vcpu=20
=20
     case APIC_TDCR:
         vlapic_set_tdcr(vlapic, val & 0xb);
-        HVM_DBG_LOG(DBG_LEVEL_VLAPIC_TIMER, "timer divisor is 0x%x",
+        HVM_DBG_LOG(DBG_LEVEL_VLAPIC_TIMER, "timer divisor is %#x",
                     vlapic->hw.timer_divisor);
         break;
=20
@@ -768,7 +768,7 @@ static int vlapic_reg_write(struct vcpu=20
     }
     if (rc =3D=3D X86EMUL_UNHANDLEABLE)
         gdprintk(XENLOG_DEBUG,
-                "Local APIC Write wrong to register 0x%x\n", offset);
+                "Local APIC Write wrong to register %#x\n", offset);
     return rc;
 }
=20
@@ -781,7 +781,7 @@ static int vlapic_write(struct vcpu *v,=20
=20
     if ( offset !=3D 0xb0 )
         HVM_DBG_LOG(DBG_LEVEL_VLAPIC,
-                    "offset 0x%x with length 0x%lx, and value is 0x%lx",
+                    "offset %#x with length %#lx, and value is %#lx",
                     offset, len, val);
=20
     /*
@@ -827,7 +827,7 @@ static int vlapic_write(struct vcpu *v,=20
     return vlapic_reg_write(v, offset, val);
=20
  unaligned_exit_and_crash:
-    gdprintk(XENLOG_ERR, "Unaligned LAPIC write len=3D0x%lx at offset=3D0x=
%x.\n",
+    gdprintk(XENLOG_ERR, "Unaligned LAPIC write len=3D%#lx at offset=3D%#x=
.\n",
              len, offset);
  exit_and_crash:
     domain_crash(v->domain);
--- 2012-09-21.orig/xen/arch/x86/hvm/vmx/vmcs.c	2012-09-20 08:44:38.0000000=
00 +0200
+++ 2012-09-21/xen/arch/x86/hvm/vmx/vmcs.c	2012-09-21 10:54:46.0000000=
00 +0200
@@ -121,7 +121,7 @@ static u32 adjust_vmx_controls(
 static bool_t cap_check(const char *name, u32 expected, u32 saw)
 {
     if ( saw !=3D expected )
-        printk("VMX %s: saw 0x%08x expected 0x%08x\n", name, saw, =
expected);
+        printk("VMX %s: saw %#x expected %#x\n", name, saw, expected);
     return saw !=3D expected;
 }
=20
--- 2012-09-21.orig/xen/arch/x86/hvm/vmx/vmx.c	2012-09-20 08:44:38.0000000=
00 +0200
+++ 2012-09-21/xen/arch/x86/hvm/vmx/vmx.c	2012-09-21 11:01:46.0000000=
00 +0200
@@ -210,7 +210,7 @@ long_mode_do_msr_read(unsigned int msr,=20
         return HNDL_unhandled;
     }
=20
-    HVM_DBG_LOG(DBG_LEVEL_0, "msr 0x%x content 0x%"PRIx64, msr, *msr_conte=
nt);
+    HVM_DBG_LOG(DBG_LEVEL_0, "msr %#x content %#"PRIx64, msr, *msr_content=
);
=20
     return HNDL_done;
 }
@@ -222,7 +222,7 @@ long_mode_do_msr_write(unsigned int msr,
     struct vmx_msr_state *guest_msr_state =3D &v->arch.hvm_vmx.msr_state;
     struct vmx_msr_state *host_msr_state =3D &this_cpu(host_msr_state);
=20
-    HVM_DBG_LOG(DBG_LEVEL_0, "msr 0x%x content 0x%"PRIx64, msr, msr_conten=
t);
+    HVM_DBG_LOG(DBG_LEVEL_0, "msr %#x content %#"PRIx64, msr, msr_content)=
;
=20
     switch ( msr )
     {
@@ -466,7 +466,7 @@ static int vmx_restore_cr0_cr3(
                                      NULL, P2M_ALLOC);
             if ( !page )
             {
-                gdprintk(XENLOG_ERR, "Invalid CR3 value=3D0x%lx\n", cr3);
+                gdprintk(XENLOG_ERR, "Invalid CR3 value=3D%#lx\n", cr3);
                 return -EINVAL;
             }
         }
@@ -492,7 +492,7 @@ static int vmx_vmcs_restore(struct vcpu=20
          ((c->pending_type =3D=3D 1) || (c->pending_type > 6) ||
           (c->pending_reserved !=3D 0)) )
     {
-        gdprintk(XENLOG_ERR, "Invalid pending event 0x%"PRIx32".\n",
+        gdprintk(XENLOG_ERR, "Invalid pending event %#"PRIx32".\n",
                  c->pending_event);
         return -EINVAL;
     }
@@ -524,7 +524,7 @@ static int vmx_vmcs_restore(struct vcpu=20
=20
     if ( c->pending_valid )
     {
-        gdprintk(XENLOG_INFO, "Re-injecting 0x%"PRIx32", 0x%"PRIx32"\n",
+        gdprintk(XENLOG_INFO, "Re-injecting %#"PRIx32", %#"PRIx32"\n",
                  c->pending_event, c->error_code);
=20
         if ( hvm_event_needs_reinjection(c->pending_type, c->pending_vecto=
r) )
@@ -1789,7 +1789,7 @@ static int is_last_branch_msr(u32 ecx)
=20
 static int vmx_msr_read_intercept(unsigned int msr, uint64_t *msr_content)=

 {
-    HVM_DBG_LOG(DBG_LEVEL_1, "ecx=3D%x", msr);
+    HVM_DBG_LOG(DBG_LEVEL_1, "ecx=3D%#x", msr);
=20
     switch ( msr )
     {
@@ -1854,7 +1854,7 @@ static int vmx_msr_read_intercept(unsign
     }
=20
 done:
-    HVM_DBG_LOG(DBG_LEVEL_1, "returns: ecx=3D%x, msr_value=3D0x%"PRIx64,
+    HVM_DBG_LOG(DBG_LEVEL_1, "returns: ecx=3D%#x, msr_value=3D%#"PRIx64,
                 msr, *msr_content);
     return X86EMUL_OKAY;
=20
@@ -1927,8 +1927,7 @@ static int vmx_msr_write_intercept(unsig
 {
     struct vcpu *v =3D current;
=20
-    HVM_DBG_LOG(DBG_LEVEL_1, "ecx=3D%x, msr_value=3D0x%"PRIx64,
-                msr, msr_content);
+    HVM_DBG_LOG(DBG_LEVEL_1, "ecx=3D%#x, msr_value=3D%#"PRIx64, msr, =
msr_content);
=20
     switch ( msr )
     {
@@ -2107,7 +2106,7 @@ static void vmx_failed_vmentry(unsigned=20
     unsigned long exit_qualification =3D __vmread(EXIT_QUALIFICATION);
     struct vcpu *curr =3D current;
=20
-    printk("Failed vm entry (exit reason 0x%x) ", exit_reason);
+    printk("Failed vm entry (exit reason %#x) ", exit_reason);
     switch ( failed_vmentry_reason )
     {
     case EXIT_REASON_INVALID_GUEST_STATE:
--- 2012-09-21.orig/xen/arch/x86/io_apic.c	2012-09-21 10:32:44.0000000=
00 +0200
+++ 2012-09-21/xen/arch/x86/io_apic.c	2012-09-21 10:54:46.000000000 =
+0200
@@ -2204,7 +2204,7 @@ int io_apic_set_pci_routing (int ioapic,
     entry.vector =3D vector;
=20
     apic_printk(APIC_DEBUG, KERN_DEBUG "IOAPIC[%d]: Set PCI routing entry =
"
-		"(%d-%d -> 0x%x -> IRQ %d Mode:%i Active:%i)\n", ioapic,
+		"(%d-%d -> %#x -> IRQ %d Mode:%i Active:%i)\n", ioapic,
 		mp_ioapics[ioapic].mpc_apicid, pin, entry.vector, irq,
 		edge_level, active_high_low);
=20
--- 2012-09-21.orig/xen/arch/x86/microcode_amd.c	2012-02-10 =
11:25:54.000000000 +0100
+++ 2012-09-21/xen/arch/x86/microcode_amd.c	2012-09-21 10:54:46.0000000=
00 +0200
@@ -88,7 +88,7 @@ static int collect_cpu_info(int cpu, str
=20
     rdmsrl(MSR_AMD_PATCHLEVEL, csig->rev);
=20
-    printk(KERN_DEBUG "microcode: collect_cpu_info: patch_id=3D0x%x\n",
+    printk(KERN_DEBUG "microcode: collect_cpu_info: patch_id=3D%#x\n",
            csig->rev);
=20
     return 0;
@@ -132,7 +132,7 @@ static int microcode_fits(const struct m
         return 0;
=20
     printk(KERN_DEBUG "microcode: CPU%d found a matching microcode "
-           "update with version 0x%x (current=3D0x%x)\n",
+           "update with version %#x (current=3D%#x)\n",
            cpu, mc_header->patch_id, uci->cpu_sig.rev);
=20
     return 1;
@@ -169,7 +169,7 @@ static int apply_microcode(int cpu)
     if ( rev !=3D hdr->patch_id )
     {
         printk(KERN_ERR "microcode: CPU%d update from revision "
-               "0x%x to 0x%x failed\n", cpu, hdr->patch_id, rev);
+               "%#x to %#x failed\n", cpu, hdr->patch_id, rev);
         return -EIO;
     }
=20
--- 2012-09-21.orig/xen/arch/x86/microcode_intel.c	2011-12-12 =
09:01:34.000000000 +0100
+++ 2012-09-21/xen/arch/x86/microcode_intel.c	2012-09-21 10:54:46.0000000=
00 +0200
@@ -122,7 +122,7 @@ static int collect_cpu_info(int cpu_num,
     /* get the current revision from MSR 0x8B */
     rdmsrl(MSR_IA32_UCODE_REV, msr_content);
     csig->rev =3D (uint32_t)(msr_content >> 32);
-    pr_debug("microcode: collect_cpu_info : sig=3D0x%x, pf=3D0x%x, =
rev=3D0x%x\n",
+    pr_debug("microcode: collect_cpu_info : sig=3D%#x, pf=3D%#x, =
rev=3D%#x\n",
              csig->sig, csig->pf, csig->rev);
=20
     return 0;
@@ -264,7 +264,7 @@ static int get_matching_microcode(const=20
     if ( uci->mc.mc_intel && uci->mc.mc_intel->hdr.rev >=3D mc_header->rev=
 )
         return 0;
     pr_debug("microcode: CPU%d found a matching microcode update with"
-             " version 0x%x (current=3D0x%x)\n",
+             " version %#x (current=3D%#x)\n",
              cpu, mc_header->rev, uci->cpu_sig.rev);
     new_mc =3D xmalloc_bytes(total_size);
     if ( new_mc =3D=3D NULL )
@@ -311,11 +311,11 @@ static int apply_microcode(int cpu)
     if ( val[1] !=3D uci->mc.mc_intel->hdr.rev )
     {
         printk(KERN_ERR "microcode: CPU%d update from revision "
-               "0x%x to 0x%x failed\n", cpu_num, uci->cpu_sig.rev, =
val[1]);
+               "%#x to %#x failed\n", cpu_num, uci->cpu_sig.rev, val[1]);
         return -EIO;
     }
     printk(KERN_INFO "microcode: CPU%d updated from revision "
-           "0x%x to 0x%x, date =3D %04x-%02x-%02x \n",
+           "%#x to %#x, date =3D %04x-%02x-%02x \n",
            cpu_num, uci->cpu_sig.rev, val[1],
            uci->mc.mc_intel->hdr.date & 0xffff,
            uci->mc.mc_intel->hdr.date >> 24,
--- 2012-09-21.orig/xen/arch/x86/mm.c	2012-09-14 13:26:34.000000000 =
+0200
+++ 2012-09-21/xen/arch/x86/mm.c	2012-09-21 10:54:46.000000000 =
+0200
@@ -3102,7 +3102,7 @@ long do_mmuext_op(
         }
=20
         default:
-            MEM_LOG("Invalid extended pt command 0x%x", op.cmd);
+            MEM_LOG("Invalid extended pt command %#x", op.cmd);
             rc =3D -ENOSYS;
             okay =3D 0;
             break;
--- 2012-09-21.orig/xen/arch/x86/mm/hap/nested_hap.c	2012-08-08 =
08:20:09.000000000 +0200
+++ 2012-09-21/xen/arch/x86/mm/hap/nested_hap.c	2012-09-21 10:54:46.0000000=
00 +0200
@@ -129,7 +129,7 @@ nestedhap_fix_p2m(struct vcpu *v, struct
=20
     if (rv =3D=3D 0) {
         gdprintk(XENLOG_ERR,
-		"failed to set entry for 0x%"PRIx64" -> 0x%"PRIx64"\n",
+		"failed to set entry for %#"PRIx64" -> %#"PRIx64"\n",
 		L2_gpa, L0_gpa);
         BUG();
     }
--- 2012-09-21.orig/xen/arch/x86/mm/p2m-pt.c	2012-09-14 13:26:34.0000000=
00 +0200
+++ 2012-09-21/xen/arch/x86/mm/p2m-pt.c	2012-09-21 10:54:46.000000000 =
+0200
@@ -110,8 +110,8 @@ p2m_find_entry(void *table, unsigned lon
     index =3D *gfn_remainder >> shift;
     if ( index >=3D max )
     {
-        P2M_DEBUG("gfn=3D0x%lx out of range "
-                  "(gfn_remainder=3D0x%lx shift=3D%d index=3D0x%x =
max=3D0x%x)\n",
+        P2M_DEBUG("gfn=3D%#lx out of range "
+                  "(gfn_remainder=3D%#lx shift=3D%d index=3D%#x max=3D%#x)=
\n",
                   gfn, *gfn_remainder, shift, index, max);
         return NULL;
     }
--- 2012-09-21.orig/xen/arch/x86/mm/shadow/common.c	2012-09-14 =
13:26:34.000000000 +0200
+++ 2012-09-21/xen/arch/x86/mm/shadow/common.c	2012-09-21 10:57:38.0000000=
00 +0200
@@ -872,7 +872,7 @@ static int sh_skip_sync(struct vcpu *v,=20
         return SHADOW_INTERNAL_NAME(sh_safe_not_to_sync, 3)(v, gl1mfn);
     else if ( pg->shadow_flags & SHF_L1_64 )
         return SHADOW_INTERNAL_NAME(sh_safe_not_to_sync, 4)(v, gl1mfn);
-    SHADOW_ERROR("gmfn 0x%lx was OOS but not shadowed as an l1.\n",=20
+    SHADOW_ERROR("gmfn %#lx was OOS but not shadowed as an l1.\n",
                  mfn_x(gl1mfn));
     BUG();
     return 0; /* BUG() is no longer __attribute__((noreturn)). */
@@ -2596,8 +2596,8 @@ void sh_remove_shadows(struct vcpu *v, m
     smfn =3D shadow_hash_lookup(v, mfn_x(gmfn), t);                       =
\
     if ( unlikely(!mfn_valid(smfn)) )                                   \
     {                                                                   \
-        SHADOW_ERROR(": gmfn %#lx has flags 0x%"PRIx32                  \
-                     " but no type-0x%"PRIx32" shadow\n",               \
+        SHADOW_ERROR(": gmfn %#lx has flags %#"PRIx32                   \
+                     " but no type-%#"PRIx32" shadow\n",                \
                      mfn_x(gmfn), (uint32_t)pg->shadow_flags, t);       \
         break;                                                          \
     }                                                                   \
--- 2012-09-21.orig/xen/arch/x86/mm/shadow/multi.c	2012-09-14 =
13:26:34.000000000 +0200
+++ 2012-09-21/xen/arch/x86/mm/shadow/multi.c	2012-09-21 10:54:46.0000000=
00 +0200
@@ -2171,7 +2171,7 @@ static int validate_gl4e(struct vcpu *v,
             // attempt by the guest to write to a xen reserved slot
             //
             SHADOW_PRINTK("%s out-of-range update "
-                           "sl4mfn=3D%05lx index=3D0x%x val=3D%" =
SH_PRI_pte "\n",
+                           "sl4mfn=3D%05lx index=3D%#x val=3D%" SH_PRI_pte=
 "\n",
                            __func__, mfn_x(sl4mfn), shadow_index, =
new_sl4e.l4);
             if ( shadow_l4e_get_flags(new_sl4e) & _PAGE_PRESENT )
             {
--- 2012-09-21.orig/xen/arch/x86/mpparse.c	2012-04-20 09:49:25.0000000=
00 +0200
+++ 2012-09-21/xen/arch/x86/mpparse.c	2012-09-21 10:54:46.000000000 =
+0200
@@ -216,7 +216,7 @@ static void __init MP_ioapic_info (struc
 	if (!(m->mpc_flags & MPC_APIC_USABLE))
 		return;
=20
-	printk(KERN_INFO "I/O APIC #%d Version %d at 0x%X.\n",
+	printk(KERN_INFO "I/O APIC #%d Version %d at %#x.\n",
 		m->mpc_apicid, m->mpc_apicver, m->mpc_apicaddr);
 	if (nr_ioapics >=3D MAX_IO_APICS) {
 		printk(KERN_CRIT "Max # of I/O APICs (%d) exceeded (found =
%d).\n",
@@ -278,7 +278,7 @@ static int __init smp_read_mpc(struct mp
 	unsigned char *mpt=3D((unsigned char *)mpc)+count;
=20
 	if (memcmp(mpc->mpc_signature,MPC_SIGNATURE,4)) {
-		printk(KERN_ERR "SMP mptable: bad signature [0x%x]!\n",
+		printk(KERN_ERR "SMP mptable: bad signature [%#x]!\n",
 			*(u32 *)mpc->mpc_signature);
 		return 0;
 	}
@@ -305,7 +305,7 @@ static int __init smp_read_mpc(struct mp
=20
 	mps_oem_check(mpc, oem, str);
=20
-	printk("APIC at: 0x%X\n",mpc->mpc_lapic);
+	printk("APIC at: %#x\n", mpc->mpc_lapic);
=20
 	/*=20
 	 * Save the local APIC address (it might be non-default) -- but =
only
@@ -881,7 +881,7 @@ void __init mp_register_ioapic (
 	mp_ioapic_routing[idx].gsi_end =3D gsi_base +=20
 		io_apic_get_redir_entries(idx);
=20
-	printk("IOAPIC[%d]: apic_id %d, version %d, address 0x%x, "
+	printk("IOAPIC[%d]: apic_id %d, version %d, address %#x, "
 		"GSI %d-%d\n", idx, mp_ioapics[idx].mpc_apicid,=20
 		mp_ioapics[idx].mpc_apicver, mp_ioapics[idx].mpc_apicaddr,
 		mp_ioapic_routing[idx].gsi_base,
--- 2012-09-21.orig/xen/arch/x86/nmi.c	2012-08-08 08:20:09.000000000 =
+0200
+++ 2012-09-21/xen/arch/x86/nmi.c	2012-09-21 10:54:46.000000000 =
+0200
@@ -245,7 +245,7 @@ static inline void write_watchdog_counte
=20
     do_div(count, nmi_hz);
     if(descr)
-        Dprintk("setting %s to -0x%"PRIx64"\n", descr, count);
+        Dprintk("setting %s to -%#"PRIx64"\n", descr, count);
     wrmsrl(nmi_perfctr_msr, 0 - count);
 }
=20
--- 2012-09-21.orig/xen/arch/x86/oprofile/op_model_athlon.c	2012-09-14 =
13:26:34.000000000 +0200
+++ 2012-09-21/xen/arch/x86/oprofile/op_model_athlon.c	2012-09-21 =
10:54:46.000000000 +0200
@@ -478,7 +478,7 @@ static int __init init_ibs_nmi(void)
 					if (value !=3D (IBSCTL_LVTOFFSETVAL=
 |
 						APIC_EILVT_LVTOFF_IBS)) {
 						printk("Xenoprofile: =
Failed to setup IBS LVT offset, "
-							"IBSCTL =3D =
%#08x\n", value);
+							"IBSCTL =3D =
%#x\n", value);
 						return 1;
 					}
 					nodes++;
@@ -523,7 +523,7 @@ void __init ibs_init(void)
 		return;
 	}
=20
-	printk("Xenoprofile: AMD IBS detected (0x%08x)\n",
+	printk("Xenoprofile: AMD IBS detected (%#x)\n",
 		(unsigned)ibs_caps);
 }
=20
--- 2012-09-21.orig/xen/arch/x86/oprofile/op_model_p4.c	2012-02-10 =
11:25:54.000000000 +0100
+++ 2012-09-21/xen/arch/x86/oprofile/op_model_p4.c	2012-09-21 =
10:54:46.000000000 +0200
@@ -485,8 +485,7 @@ static void pmc_setup_one_p4_counter(uns
 =09
 	/* find our event binding structure. */
 	if (counter_config[ctr].event <=3D 0 || counter_config[ctr].event =
> NUM_EVENTS) {
-		printk(KERN_ERR=20
-		       "oprofile: P4 event code 0x%lx out of range\n",=20
+		printk(KERN_ERR "oprofile: P4 event code %#lx out of =
range\n",
 		       counter_config[ctr].event);
 		return;
 	}
@@ -526,7 +525,7 @@ static void pmc_setup_one_p4_counter(uns
 	}
=20
 	printk(KERN_ERR=20
-	       "oprofile: P4 event code 0x%lx no binding, stag %d ctr =
%d\n",
+	       "oprofile: P4 event code %#lx no binding, stag %d ctr =
%d\n",
 	       counter_config[ctr].event, stag, ctr);
 }
=20
--- 2012-09-21.orig/xen/arch/x86/setup.c	2012-09-17 09:57:54.0000000=
00 +0200
+++ 2012-09-21/xen/arch/x86/setup.c	2012-09-21 11:01:12.000000000 =
+0200
@@ -482,13 +482,13 @@ static void __init kexec_reserve_area(st
=20
     if ( !reserve_e820_ram(e820, kdump_start, kdump_start + kdump_size) )
     {
-        printk("Kdump: DISABLED (failed to reserve %luMB (%lukB) at =
0x%lx)"
+        printk("Kdump: DISABLED (failed to reserve %luMB (%lukB) at =
%#lx)"
                "\n", kdump_size >> 20, kdump_size >> 10, kdump_start);
         kexec_crash_area.start =3D kexec_crash_area.size =3D 0;
     }
     else
     {
-        printk("Kdump: %luMB (%lukB) at 0x%lx\n",
+        printk("Kdump: %luMB (%lukB) at %#lx\n",
                kdump_size >> 20, kdump_size >> 10, kdump_start);
     }
 }
--- 2012-09-21.orig/xen/arch/x86/tboot.c	2012-01-20 10:10:22.0000000=
00 +0100
+++ 2012-09-21/xen/arch/x86/tboot.c	2012-09-21 10:54:46.000000000 =
+0200
@@ -119,12 +119,12 @@ void __init tboot_probe(void)
     g_tboot_shared =3D tboot_shared;
     printk("TBOOT: found shared page at phys addr %lx:\n", p_tboot_shared)=
;
     printk("  version: %d\n", tboot_shared->version);
-    printk("  log_addr: 0x%08x\n", tboot_shared->log_addr);
-    printk("  shutdown_entry: 0x%08x\n", tboot_shared->shutdown_entry);
-    printk("  tboot_base: 0x%08x\n", tboot_shared->tboot_base);
-    printk("  tboot_size: 0x%x\n", tboot_shared->tboot_size);
+    printk("  log_addr: %#x\n", tboot_shared->log_addr);
+    printk("  shutdown_entry: %#x\n", tboot_shared->shutdown_entry);
+    printk("  tboot_base: %#x\n", tboot_shared->tboot_base);
+    printk("  tboot_size: %#x\n", tboot_shared->tboot_size);
     if ( tboot_shared->version >=3D 6 )
-        printk("  flags: 0x%08x\n", tboot_shared->flags);
+        printk("  flags: %#x\n", tboot_shared->flags);
=20
     /* these will be needed by tboot_protect_mem_regions() and/or
        tboot_parse_dmar_table(), so get them now */
@@ -352,7 +352,7 @@ void tboot_shutdown(uint32_t shutdown_ty
                            __PAGE_HYPERVISOR);
     if ( err !=3D 0 )
     {
-        printk("error (0x%x) mapping tboot pages (mfns) @ 0x%x, 0x%x\n", =
err,
+        printk("error (%#x) mapping tboot pages (mfns) @ %#x, %#x\n", =
err,
                map_base, map_size);
         return;
     }
--- 2012-09-21.orig/xen/arch/x86/time.c	2012-09-14 13:26:34.000000000 =
+0200
+++ 2012-09-21/xen/arch/x86/time.c	2012-09-21 10:54:46.000000000 =
+0200
@@ -1955,11 +1955,11 @@ static void dump_softtsc(unsigned char k
         printk("dom%u%s: mode=3D%d",d->domain_id,
                 is_hvm_domain(d) ? "(hvm)" : "", d->arch.tsc_mode);
         if ( d->arch.vtsc_offset )
-            printk(",ofs=3D0x%"PRIx64"",d->arch.vtsc_offset);
+            printk(",ofs=3D%#"PRIx64, d->arch.vtsc_offset);
         if ( d->arch.tsc_khz )
-            printk(",khz=3D%"PRIu32"",d->arch.tsc_khz);
+            printk(",khz=3D%"PRIu32, d->arch.tsc_khz);
         if ( d->arch.incarnation )
-            printk(",inc=3D%"PRIu32"",d->arch.incarnation);
+            printk(",inc=3D%"PRIu32, d->arch.incarnation);
         if ( !(d->arch.vtsc_kerncount | d->arch.vtsc_usercount) )
         {
             printk("\n");
--- 2012-09-21.orig/xen/arch/x86/xstate.c	2012-01-30 10:46:14.0000000=
00 +0100
+++ 2012-09-21/xen/arch/x86/xstate.c	2012-09-21 10:54:46.000000000 =
+0200
@@ -163,7 +163,7 @@ void xstate_init(void)
         xsave_cntxt_size =3D ebx;
         xfeature_mask =3D eax + ((u64)edx << 32);
         xfeature_mask &=3D XCNTXT_MASK;
-        printk("%s: using cntxt_size: 0x%x and states: 0x%"PRIx64"\n",
+        printk("%s: using cntxt_size: %#x and states: %#"PRIx64"\n",
             __func__, xsave_cntxt_size, xfeature_mask);
=20
         /* Check XSAVEOPT feature. */
--- 2012-09-21.orig/xen/common/gdbstub.c	2010-05-20 09:59:27.0000000=
00 +0200
+++ 2012-09-21/xen/common/gdbstub.c	2012-09-21 10:54:46.000000000 =
+0200
@@ -263,7 +263,7 @@ gdb_write_to_packet_hex(unsigned long x,
     case sizeof(u64):
         break;
     default:
-        dbg_printk("WARNING: %s x: 0x%lx int_size: %d\n",
+        dbg_printk("WARNING: %s x: %#lx int_size: %d\n",
                    __func__, x, int_size);
         break;
     }
--- 2012-09-21.orig/xen/common/page_alloc.c	2012-09-14 13:26:34.0000000=
00 +0200
+++ 2012-09-21/xen/common/page_alloc.c	2012-09-21 10:54:46.000000000 =
+0200
@@ -367,7 +367,7 @@ static void __init setup_low_mem_virq(vo
     low_mem_virq_th =3D low_mem_virq_orig =3D 1UL << order;
     low_mem_virq_th_order =3D order;
=20
-    printk("Initial low memory virq threshold set at 0x%lx pages.\n",
+    printk("Initial low memory virq threshold set at %#lx pages.\n",
             low_mem_virq_th);
 }
=20
--- 2012-09-21.orig/xen/common/vsprintf.c	2012-02-10 11:25:54.0000000=
00 +0100
+++ 2012-09-21/xen/common/vsprintf.c	2012-09-21 10:54:46.000000000 =
+0200
@@ -171,10 +171,14 @@ static char *number(
         }
     }
     if (type & SPECIAL) {
-        if (base =3D=3D 16)
+        if (num =3D=3D 0)
+            type &=3D ~SPECIAL;
+        else if (base =3D=3D 16)
             size -=3D 2;
         else if (base =3D=3D 8)
             size--;
+        else
+            type &=3D ~SPECIAL;
     }
     i =3D 0;
     if (num =3D=3D 0)
@@ -197,14 +201,10 @@ static char *number(
         ++buf;
     }
     if (type & SPECIAL) {
-        if (base=3D=3D8) {
-            if (buf <=3D end)
-                *buf =3D '0';
-            ++buf;
-        } else if (base=3D=3D16) {
-            if (buf <=3D end)
-                *buf =3D '0';
-            ++buf;
+        if (buf <=3D end)
+            *buf =3D '0';
+        ++buf;
+        if (base =3D=3D 16) {
             if (buf <=3D end)
                 *buf =3D digits[33];
             ++buf;
--- 2012-09-21.orig/xen/common/xencomm.c	2012-01-24 10:11:51.0000000=
00 +0100
+++ 2012-09-21/xen/common/xencomm.c	2012-09-21 10:54:46.000000000 =
+0200
@@ -58,7 +58,7 @@ xencomm_get_page(unsigned long paddr, st
          * is freed with decrease reservation hypercall at the same time.
          */
         gdprintk(XENLOG_WARNING,
-                 "bad page is passed. paddr 0x%lx maddr 0x%lx\n",
+                 "bad page is passed. paddr %#lx maddr %#lx\n",
                  paddr, maddr);
         return -EFAULT;
     }
@@ -117,7 +117,7 @@ xencomm_ctxt_init(const void *handle, st
     desc =3D xencomm_vaddr((unsigned long)handle, page);
     if ( desc->magic !=3D XENCOMM_MAGIC )
     {
-        printk("%s: error: %p magic was 0x%x\n", __func__, desc, =
desc->magic);
+        printk("%s: error: %p magic was %#x\n", __func__, desc, desc->magi=
c);
         put_page(page);
         return -EINVAL;
     }
--- 2012-09-21.orig/xen/drivers/acpi/numa.c	2012-09-14 13:26:34.0000000=
00 +0200
+++ 2012-09-21/xen/drivers/acpi/numa.c	2012-09-21 10:54:46.000000000 =
+0200
@@ -78,8 +78,8 @@ void __init acpi_table_print_srat_entry(
 			if (srat_rev < 2)
 				proximity_domain &=3D 0xff;
 			ACPI_DEBUG_PRINT((ACPI_DB_INFO,
-					  "SRAT Memory (%#016"PRIx64
-					  " length %#016"PRIx64")"
+					  "SRAT Memory (%#"PRIx64
+					  " length %#"PRIx64")"
 					  " in proximity domain %d =
%s%s\n",
 					  p->base_address, p->length,
 					  proximity_domain,
@@ -108,7 +108,7 @@ void __init acpi_table_print_srat_entry(
 		break;
 	default:
 		printk(KERN_WARNING PREFIX
-		       "Found unsupported SRAT entry (type =3D 0x%x)\n",
+		       "Found unsupported SRAT entry (type =3D %#x)\n",
 		       header->type);
 		break;
 	}
--- 2012-09-21.orig/xen/drivers/acpi/tables.c	2012-09-21 10:32:44.0000000=
00 +0200
+++ 2012-09-21/xen/drivers/acpi/tables.c	2012-09-21 10:54:46.0000000=
00 +0200
@@ -95,7 +95,7 @@ void __init acpi_table_print_madt_entry(
 			if (p->inti_flags  &
 			    ~(ACPI_MADT_POLARITY_MASK | ACPI_MADT_TRIGGER_M=
ASK))
 				printk(KERN_INFO PREFIX
-				       "INT_SRC_OVR unexpected reserved =
flags: 0x%x\n",
+				       "INT_SRC_OVR unexpected reserved =
flags: %#x\n",
 				       p->inti_flags  &
 					~(ACPI_MADT_POLARITY_MASK | =
ACPI_MADT_TRIGGER_MASK));
=20
@@ -119,7 +119,7 @@ void __init acpi_table_print_madt_entry(
 			struct acpi_madt_local_apic_nmi *p =3D
 			    (struct acpi_madt_local_apic_nmi *)header;
 			printk(KERN_INFO PREFIX
-			       "LAPIC_NMI (acpi_id[0x%02x] %s %s lint[0x%x]=
)\n",
+			       "LAPIC_NMI (acpi_id[0x%02x] %s %s lint[%#x])=
\n",
 			       p->processor_id,
 			       mps_inti_flags_polarity[p->inti_flags & =
ACPI_MADT_POLARITY_MASK	],
 			       mps_inti_flags_trigger[(p->inti_flags & =
ACPI_MADT_TRIGGER_MASK) >> 2],
@@ -137,7 +137,7 @@ void __init acpi_table_print_madt_entry(
 			trigger =3D (p->inti_flags & ACPI_MADT_TRIGGER_MASK=
) >> 2;
=20
 			printk(KERN_INFO PREFIX
-			       "X2APIC_NMI (uid[0x%02x] %s %s lint[0x%x])\n=
",
+			       "X2APIC_NMI (uid[0x%02x] %s %s lint[%#x])\n"=
,
 			       p->uid,
 			       mps_inti_flags_polarity[polarity],
 			       mps_inti_flags_trigger[trigger],
@@ -160,7 +160,7 @@ void __init acpi_table_print_madt_entry(
 			struct acpi_madt_io_sapic *p =3D
 			    (struct acpi_madt_io_sapic *)header;
 			printk(KERN_INFO PREFIX
-			       "IOSAPIC (id[0x%x] address[%p] gsi_base[%d])=
\n",
+			       "IOSAPIC (id[%#x] address[%p] gsi_base[%d])\=
n",
 			       p->id, (void *)(unsigned long)p->address,
 			       p->global_irq_base);
 		}
@@ -182,7 +182,7 @@ void __init acpi_table_print_madt_entry(
 			struct acpi_madt_interrupt_source *p =3D
 			    (struct acpi_madt_interrupt_source *)header;
 			printk(KERN_INFO PREFIX
-			       "PLAT_INT_SRC (%s %s type[0x%x] id[0x%04x] =
eid[0x%x] iosapic_vector[0x%x] global_irq[0x%x]\n",
+			       "PLAT_INT_SRC (%s %s type[%#x] id[0x%04x] =
eid[%#x] iosapic_vector[%#x] global_irq[%#x]\n",
 			       mps_inti_flags_polarity[p->inti_flags & =
ACPI_MADT_POLARITY_MASK],
 			       mps_inti_flags_trigger[(p->inti_flags & =
ACPI_MADT_TRIGGER_MASK) >> 2],
 			       p->type, p->id, p->eid, p->io_sapic_vector,
@@ -192,7 +192,7 @@ void __init acpi_table_print_madt_entry(
=20
 	default:
 		printk(KERN_WARNING PREFIX
-		       "Found unsupported MADT entry (type =3D 0x%x)\n",
+		       "Found unsupported MADT entry (type =3D %#x)\n",
 		       header->type);
 		break;
 	}
@@ -242,7 +242,7 @@ acpi_table_parse_entries(char *id,
 		    ((unsigned long)entry + entry->length);
 	}
 	if (max_entries && count > max_entries) {
-		printk(KERN_WARNING PREFIX "[%4.4s:0x%02x] ignored %i =
entries of "
+		printk(KERN_WARNING PREFIX "[%4.4s:%#x] ignored %i entries =
of "
 		       "%i found\n", id, entry_id, count - max_entries, =
count);
 	}
=20
--- 2012-09-21.orig/xen/drivers/acpi/utilities/utglobal.c	2011-03-11 =
10:13:55.000000000 +0100
+++ 2012-09-21/xen/drivers/acpi/utilities/utglobal.c	2012-09-21 =
10:54:46.000000000 +0200
@@ -79,7 +79,7 @@ const char *__init acpi_format_exception
 		/* Exception code was not recognized */
=20
 		ACPI_ERROR((AE_INFO,
-			    "Unknown exception code: 0x%8.8X", status));
+			    "Unknown exception code: %#X", status));
=20
 		exception =3D "UNKNOWN_STATUS_CODE";
 		dump_execution_state();
--- 2012-09-21.orig/xen/drivers/cpufreq/cpufreq.c	2012-09-14 =
13:26:34.000000000 +0200
+++ 2012-09-21/xen/drivers/cpufreq/cpufreq.c	2012-09-21 10:54:46.0000000=
00 +0200
@@ -377,7 +377,7 @@ static void print_PSS(struct xen_process
     printk("\t_PSS: state_count=3D%d\n", count);
     for (i=3D0; i<count; i++){
         printk("\tState%d: %"PRId64"MHz %"PRId64"mW %"PRId64"us "
-               "%"PRId64"us 0x%"PRIx64" 0x%"PRIx64"\n",
+               "%"PRId64"us %#"PRIx64" %#"PRIx64"\n",
                i,
                ptr[i].core_frequency,
                ptr[i].power,
--- 2012-09-21.orig/xen/drivers/passthrough/amd/iommu_acpi.c	2011-12-14 =
10:11:38.000000000 +0100
+++ 2012-09-21/xen/drivers/passthrough/amd/iommu_acpi.c	2012-09-21 =
10:54:46.000000000 +0200
@@ -196,7 +196,7 @@ static int __init register_exclusion_ran
     iommu =3D find_iommu_for_device(seg, bdf);
     if ( !iommu )
     {
-        AMD_IOMMU_DEBUG("IVMD Error: No IOMMU for Dev_Id 0x%x!\n", bdf);
+        AMD_IOMMU_DEBUG("IVMD Error: No IOMMU for Dev_Id %#x!\n", bdf);
         return -ENODEV;
     }
     req =3D ivrs_mappings[bdf].dte_requestor_id;
@@ -278,7 +278,7 @@ static int __init parse_ivmd_device_sele
     bdf =3D ivmd_block->header.device_id;
     if ( bdf >=3D ivrs_bdf_entries )
     {
-        AMD_IOMMU_DEBUG("IVMD Error: Invalid Dev_Id 0x%x\n", bdf);
+        AMD_IOMMU_DEBUG("IVMD Error: Invalid Dev_Id %#x\n", bdf);
         return -ENODEV;
     }
=20
@@ -296,7 +296,7 @@ static int __init parse_ivmd_device_rang
     if ( first_bdf >=3D ivrs_bdf_entries )
     {
         AMD_IOMMU_DEBUG("IVMD Error: "
-                        "Invalid Range_First Dev_Id 0x%x\n", first_bdf);
+                        "Invalid Range_First Dev_Id %#x\n", first_bdf);
         return -ENODEV;
     }
=20
@@ -304,7 +304,7 @@ static int __init parse_ivmd_device_rang
     if ( (last_bdf >=3D ivrs_bdf_entries) || (last_bdf <=3D first_bdf) )
     {
         AMD_IOMMU_DEBUG("IVMD Error: "
-                        "Invalid Range_Last Dev_Id 0x%x\n", last_bdf);
+                        "Invalid Range_Last Dev_Id %#x\n", last_bdf);
         return -ENODEV;
     }
=20
@@ -326,7 +326,7 @@ static int __init parse_ivmd_device_iomm
                                     ivmd_block->aux_data);
     if ( !iommu )
     {
-        AMD_IOMMU_DEBUG("IVMD Error: No IOMMU for Dev_Id 0x%x  Cap =
0x%x\n",
+        AMD_IOMMU_DEBUG("IVMD Error: No IOMMU for Dev_Id %#x Cap %#x\n",
                         ivmd_block->header.device_id, ivmd_block->aux_data=
);
         return -ENODEV;
     }
@@ -351,9 +351,9 @@ static int __init parse_ivmd_block(const
     base =3D start_addr & PAGE_MASK;
     limit =3D (start_addr + mem_length - 1) & PAGE_MASK;
=20
-    AMD_IOMMU_DEBUG("IVMD Block: Type 0x%x\n",ivmd_block->header.type);
-    AMD_IOMMU_DEBUG(" Start_Addr_Phys 0x%lx\n", start_addr);
-    AMD_IOMMU_DEBUG(" Mem_Length 0x%lx\n", mem_length);
+    AMD_IOMMU_DEBUG("IVMD Block: Type %#x\n",ivmd_block->header.type);
+    AMD_IOMMU_DEBUG(" Start_Addr_Phys %#lx\n", start_addr);
+    AMD_IOMMU_DEBUG(" Mem_Length %#lx\n", mem_length);
=20
     if ( ivmd_block->header.flags & ACPI_IVMD_EXCLUSION_RANGE )
         iw =3D ir =3D IOMMU_CONTROL_ENABLED;
@@ -414,7 +414,7 @@ static u16 __init parse_ivhd_device_sele
     bdf =3D select->header.id;
     if ( bdf >=3D ivrs_bdf_entries )
     {
-        AMD_IOMMU_DEBUG("IVHD Error: Invalid Device_Entry Dev_Id 0x%x\n", =
bdf);
+        AMD_IOMMU_DEBUG("IVHD Error: Invalid Device_Entry Dev_Id %#x\n", =
bdf);
         return 0;
     }
=20
@@ -439,7 +439,7 @@ static u16 __init parse_ivhd_device_rang
     if ( range->end.header.type !=3D ACPI_IVRS_TYPE_END )
     {
         AMD_IOMMU_DEBUG("IVHD Error: "
-                        "Invalid Range: End_Type 0x%x\n",
+                        "Invalid Range: End_Type %#x\n",
                         range->end.header.type);
         return 0;
     }
@@ -448,7 +448,7 @@ static u16 __init parse_ivhd_device_rang
     if ( first_bdf >=3D ivrs_bdf_entries )
     {
         AMD_IOMMU_DEBUG("IVHD Error: "
-                        "Invalid Range: First Dev_Id 0x%x\n", first_bdf);
+                        "Invalid Range: First Dev_Id %#x\n", first_bdf);
         return 0;
     }
=20
@@ -456,11 +456,11 @@ static u16 __init parse_ivhd_device_rang
     if ( (last_bdf >=3D ivrs_bdf_entries) || (last_bdf <=3D first_bdf) )
     {
         AMD_IOMMU_DEBUG("IVHD Error: "
-                        "Invalid Range: Last Dev_Id 0x%x\n", last_bdf);
+                        "Invalid Range: Last Dev_Id %#x\n", last_bdf);
         return 0;
     }
=20
-    AMD_IOMMU_DEBUG(" Dev_Id Range: 0x%x -> 0x%x\n", first_bdf, last_bdf);=

+    AMD_IOMMU_DEBUG(" Dev_Id Range: %#x -> %#x\n", first_bdf, last_bdf);
=20
     for ( bdf =3D first_bdf; bdf <=3D last_bdf; bdf++ )
         add_ivrs_mapping_entry(bdf, bdf, range->start.header.data_setting,=

@@ -485,18 +485,18 @@ static u16 __init parse_ivhd_device_alia
     bdf =3D alias->header.id;
     if ( bdf >=3D ivrs_bdf_entries )
     {
-        AMD_IOMMU_DEBUG("IVHD Error: Invalid Device_Entry Dev_Id 0x%x\n", =
bdf);
+        AMD_IOMMU_DEBUG("IVHD Error: Invalid Device_Entry Dev_Id %#x\n", =
bdf);
         return 0;
     }
=20
     alias_id =3D alias->used_id;
     if ( alias_id >=3D ivrs_bdf_entries )
     {
-        AMD_IOMMU_DEBUG("IVHD Error: Invalid Alias Dev_Id 0x%x\n", =
alias_id);
+        AMD_IOMMU_DEBUG("IVHD Error: Invalid Alias Dev_Id %#x\n", =
alias_id);
         return 0;
     }
=20
-    AMD_IOMMU_DEBUG(" Dev_Id Alias: 0x%x\n", alias_id);
+    AMD_IOMMU_DEBUG(" Dev_Id Alias: %#x\n", alias_id);
=20
     add_ivrs_mapping_entry(bdf, alias_id, alias->header.data_setting, =
iommu);
=20
@@ -520,7 +520,7 @@ static u16 __init parse_ivhd_device_alia
     if ( range->end.header.type !=3D ACPI_IVRS_TYPE_END )
     {
         AMD_IOMMU_DEBUG("IVHD Error: "
-                        "Invalid Range: End_Type 0x%x\n",
+                        "Invalid Range: End_Type %#x\n",
                         range->end.header.type);
         return 0;
     }
@@ -529,7 +529,7 @@ static u16 __init parse_ivhd_device_alia
     if ( first_bdf >=3D ivrs_bdf_entries )
     {
         AMD_IOMMU_DEBUG("IVHD Error: "
-                        "Invalid Range: First Dev_Id 0x%x\n", first_bdf);
+                        "Invalid Range: First Dev_Id %#x\n", first_bdf);
         return 0;
     }
=20
@@ -537,19 +537,19 @@ static u16 __init parse_ivhd_device_alia
     if ( last_bdf >=3D ivrs_bdf_entries || last_bdf <=3D first_bdf )
     {
         AMD_IOMMU_DEBUG(
-            "IVHD Error: Invalid Range: Last Dev_Id 0x%x\n", last_bdf);
+            "IVHD Error: Invalid Range: Last Dev_Id %#x\n", last_bdf);
         return 0;
     }
=20
     alias_id =3D range->alias.used_id;
     if ( alias_id >=3D ivrs_bdf_entries )
     {
-        AMD_IOMMU_DEBUG("IVHD Error: Invalid Alias Dev_Id 0x%x\n", =
alias_id);
+        AMD_IOMMU_DEBUG("IVHD Error: Invalid Alias Dev_Id %#x\n", =
alias_id);
         return 0;
     }
=20
-    AMD_IOMMU_DEBUG(" Dev_Id Range: 0x%x -> 0x%x\n", first_bdf, last_bdf);=

-    AMD_IOMMU_DEBUG(" Dev_Id Alias: 0x%x\n", alias_id);
+    AMD_IOMMU_DEBUG(" Dev_Id Range: %#x -> %#x\n", first_bdf, last_bdf);
+    AMD_IOMMU_DEBUG(" Dev_Id Alias: %#x\n", alias_id);
=20
     for ( bdf =3D first_bdf; bdf <=3D last_bdf; bdf++ )
         add_ivrs_mapping_entry(bdf, alias_id, range->alias.header.data_set=
ting,
@@ -574,7 +574,7 @@ static u16 __init parse_ivhd_device_exte
     bdf =3D ext->header.id;
     if ( bdf >=3D ivrs_bdf_entries )
     {
-        AMD_IOMMU_DEBUG("IVHD Error: Invalid Device_Entry Dev_Id 0x%x\n", =
bdf);
+        AMD_IOMMU_DEBUG("IVHD Error: Invalid Device_Entry Dev_Id %#x\n", =
bdf);
         return 0;
     }
=20
@@ -599,7 +599,7 @@ static u16 __init parse_ivhd_device_exte
     if ( range->end.header.type !=3D ACPI_IVRS_TYPE_END )
     {
         AMD_IOMMU_DEBUG("IVHD Error: "
-                        "Invalid Range: End_Type 0x%x\n",
+                        "Invalid Range: End_Type %#x\n",
                         range->end.header.type);
         return 0;
     }
@@ -608,7 +608,7 @@ static u16 __init parse_ivhd_device_exte
     if ( first_bdf >=3D ivrs_bdf_entries )
     {
         AMD_IOMMU_DEBUG("IVHD Error: "
-                        "Invalid Range: First Dev_Id 0x%x\n", first_bdf);
+                        "Invalid Range: First Dev_Id %#x\n", first_bdf);
         return 0;
     }
=20
@@ -616,11 +616,11 @@ static u16 __init parse_ivhd_device_exte
     if ( (last_bdf >=3D ivrs_bdf_entries) || (last_bdf <=3D first_bdf) )
     {
         AMD_IOMMU_DEBUG("IVHD Error: "
-                        "Invalid Range: Last Dev_Id 0x%x\n", last_bdf);
+                        "Invalid Range: Last Dev_Id %#x\n", last_bdf);
         return 0;
     }
=20
-    AMD_IOMMU_DEBUG(" Dev_Id Range: 0x%x -> 0x%x\n",
+    AMD_IOMMU_DEBUG(" Dev_Id Range: %#x -> %#x\n",
                     first_bdf, last_bdf);
=20
     for ( bdf =3D first_bdf; bdf <=3D last_bdf; bdf++ )
@@ -646,7 +646,7 @@ static u16 __init parse_ivhd_device_spec
     bdf =3D special->used_id;
     if ( bdf >=3D ivrs_bdf_entries )
     {
-        AMD_IOMMU_DEBUG("IVHD Error: Invalid Device_Entry Dev_Id 0x%x\n", =
bdf);
+        AMD_IOMMU_DEBUG("IVHD Error: Invalid Device_Entry Dev_Id %#x\n", =
bdf);
         return 0;
     }
=20
@@ -673,7 +673,7 @@ static int __init parse_ivhd_block(const
                                     ivhd_block->capability_offset);
     if ( !iommu )
     {
-        AMD_IOMMU_DEBUG("IVHD Error: No IOMMU for Dev_Id 0x%x  Cap =
0x%x\n",
+        AMD_IOMMU_DEBUG("IVHD Error: No IOMMU for Dev_Id %#x Cap %#x\n",
                         ivhd_block->header.device_id,
                         ivhd_block->capability_offset);
         return -ENODEV;
@@ -687,9 +687,9 @@ static int __init parse_ivhd_block(const
         ivhd_device =3D (const void *)((const u8 *)ivhd_block + block_leng=
th);
=20
         AMD_IOMMU_DEBUG( "IVHD Device Entry:\n");
-        AMD_IOMMU_DEBUG( " Type 0x%x\n", ivhd_device->header.type);
-        AMD_IOMMU_DEBUG( " Dev_Id 0x%x\n", ivhd_device->header.id);
-        AMD_IOMMU_DEBUG( " Flags 0x%x\n", ivhd_device->header.data_setting=
);
+        AMD_IOMMU_DEBUG( " Type %#x\n", ivhd_device->header.type);
+        AMD_IOMMU_DEBUG( " Dev_Id %#x\n", ivhd_device->header.id);
+        AMD_IOMMU_DEBUG( " Flags %#x\n", ivhd_device->header.data_setting)=
;
=20
         switch ( ivhd_device->header.type )
         {
@@ -788,9 +788,9 @@ static void __init dump_acpi_table_heade
         printk("%c", table->signature[i]);
     printk("\n");
=20
-    AMD_IOMMU_DEBUG(" Length 0x%x\n", table->length);
-    AMD_IOMMU_DEBUG(" Revision 0x%x\n", table->revision);
-    AMD_IOMMU_DEBUG(" CheckSum 0x%x\n", table->checksum);
+    AMD_IOMMU_DEBUG(" Length %#x\n", table->length);
+    AMD_IOMMU_DEBUG(" Revision %#x\n", table->revision);
+    AMD_IOMMU_DEBUG(" CheckSum %#x\n", table->checksum);
=20
     AMD_IOMMU_DEBUG(" OEM_Id ");
     for ( i =3D 0; i < ACPI_OEM_ID_SIZE; i++ )
@@ -802,14 +802,14 @@ static void __init dump_acpi_table_heade
         printk("%c", table->oem_table_id[i]);
     printk("\n");
=20
-    AMD_IOMMU_DEBUG(" OEM_Revision 0x%x\n", table->oem_revision);
+    AMD_IOMMU_DEBUG(" OEM_Revision %#x\n", table->oem_revision);
=20
     AMD_IOMMU_DEBUG(" Creator_Id ");
     for ( i =3D 0; i < ACPI_NAME_SIZE; i++ )
         printk("%c", table->asl_compiler_id[i]);
     printk("\n");
=20
-    AMD_IOMMU_DEBUG(" Creator_Revision 0x%x\n",
+    AMD_IOMMU_DEBUG(" Creator_Revision %#x\n",
                     table->asl_compiler_revision);
=20
 }
@@ -832,15 +832,15 @@ static int __init parse_ivrs_table(struc
         ivrs_block =3D (struct acpi_ivrs_header *)((u8 *)table + length);
=20
         AMD_IOMMU_DEBUG("IVRS Block:\n");
-        AMD_IOMMU_DEBUG(" Type 0x%x\n", ivrs_block->type);
-        AMD_IOMMU_DEBUG(" Flags 0x%x\n", ivrs_block->flags);
-        AMD_IOMMU_DEBUG(" Length 0x%x\n", ivrs_block->length);
-        AMD_IOMMU_DEBUG(" Dev_Id 0x%x\n", ivrs_block->device_id);
+        AMD_IOMMU_DEBUG(" Type %#x\n", ivrs_block->type);
+        AMD_IOMMU_DEBUG(" Flags %#x\n", ivrs_block->flags);
+        AMD_IOMMU_DEBUG(" Length %#x\n", ivrs_block->length);
+        AMD_IOMMU_DEBUG(" Dev_Id %#x\n", ivrs_block->device_id);
=20
         if ( table->length < (length + ivrs_block->length) )
         {
             AMD_IOMMU_DEBUG("IVRS Error: "
-                            "Table Length Exceeded: 0x%x -> 0x%lx\n",
+                            "Table Length Exceeded: %#x -> %#lx\n",
                             table->length,
                             (length + ivrs_block->length));
             return -ENODEV;
@@ -867,7 +867,7 @@ static int __init detect_iommu_acpi(stru
         checksum +=3D raw_table[i];
     if ( checksum )
     {
-        AMD_IOMMU_DEBUG("IVRS Error: Invalid Checksum 0x%x\n", checksum);
+        AMD_IOMMU_DEBUG("IVRS Error: Invalid Checksum %#x\n", checksum);
         return -ENODEV;
     }
=20
--- 2012-09-21.orig/xen/drivers/passthrough/amd/iommu_init.c	2012-09-17 =
09:57:54.000000000 +0200
+++ 2012-09-21/xen/drivers/passthrough/amd/iommu_init.c	2012-09-21 =
10:54:46.000000000 +0200
@@ -616,8 +616,8 @@ static void parse_event_log_entry(struct
                                        IOMMU_EVENT_FLAGS_SHIFT);
         addr=3D (u64*) (entry + 2);
         printk(XENLOG_ERR "AMD-Vi: "
-               "%s: domain =3D %d, device id =3D 0x%04x, "
-               "fault address =3D 0x%"PRIx64", flags =3D 0x%03x\n",
+               "%s: domain =3D %d, device id =3D %#x, "
+               "fault address =3D %#"PRIx64", flags =3D %#x\n",
                event_str[code-1], domain_id, device_id, *addr, flags);
=20
         /* Tell the device to stop DMAing; we can't rely on the guest to
--- 2012-09-21.orig/xen/drivers/passthrough/amd/iommu_map.c	2012-09-14 =
13:26:34.000000000 +0200
+++ 2012-09-21/xen/drivers/passthrough/amd/iommu_map.c	2012-09-21 =
10:54:46.000000000 +0200
@@ -795,7 +795,7 @@ void amd_iommu_share_p2m(struct domain *
=20
         /* When sharing p2m with iommu, paging mode =3D 4 */
         hd->paging_mode =3D IOMMU_PAGING_MODE_LEVEL_4;
-        AMD_IOMMU_DEBUG("Share p2m table with iommu: p2m table =3D =
0x%lx\n",
+        AMD_IOMMU_DEBUG("Share p2m table with iommu: p2m table =3D =
%#lx\n",
                         mfn_x(pgd_mfn));
     }
 }
--- 2012-09-21.orig/xen/drivers/passthrough/amd/pci_amd_iommu.c	2012-09-14 =
13:26:34.000000000 +0200
+++ 2012-09-21/xen/drivers/passthrough/amd/pci_amd_iommu.c	2012-09-21 =
10:54:46.000000000 +0200
@@ -121,8 +121,8 @@ static void amd_iommu_setup_domain_devic
=20
         amd_iommu_flush_device(iommu, req_id);
=20
-        AMD_IOMMU_DEBUG("Setup I/O page table: device id =3D 0x%04x, "
-                        "root table =3D 0x%"PRIx64", "
+        AMD_IOMMU_DEBUG("Setup I/O page table: device id =3D %#x, "
+                        "root table =3D %#"PRIx64", "
                         "domain =3D %d, paging mode =3D %d\n", req_id,
                         page_to_maddr(hd->root_table),
                         hd->domain_id, hd->paging_mode);
@@ -314,7 +314,7 @@ void amd_iommu_disable_domain_device(str
=20
         amd_iommu_flush_device(iommu, req_id);
=20
-        AMD_IOMMU_DEBUG("Disable: device id =3D 0x%04x, "
+        AMD_IOMMU_DEBUG("Disable: device id =3D %#x, "
                         "domain =3D %d, paging mode =3D %d\n",
                         req_id,  domain_hvm_iommu(domain)->domain_id,
                         domain_hvm_iommu(domain)->paging_mode);
--- 2012-09-21.orig/xen/drivers/passthrough/vtd/dmar.c	2012-09-14 =
13:26:34.000000000 +0200
+++ 2012-09-21/xen/drivers/passthrough/vtd/dmar.c	2012-09-21 =
10:54:46.000000000 +0200
@@ -381,7 +381,7 @@ static int __init acpi_dmar_check_length
     if ( h->length >=3D min_len )
         return 0;
     dprintk(XENLOG_ERR VTDPREFIX,
-            "Invalid ACPI DMAR entry length: 0x%x\n",
+            "Invalid ACPI DMAR entry length: %#x\n",
             h->length);
     return -EINVAL;
 }
@@ -749,7 +749,7 @@ static int __init acpi_parse_dmar(struct
             break;
         default:
             dprintk(XENLOG_WARNING VTDPREFIX,
-                    "Ignore unknown DMAR structure type (0x%x)\n",
+                    "Ignore unknown DMAR structure type (%#x)\n",
                     entry_header->type);
             break;
         }
--- 2012-09-21.orig/xen/drivers/passthrough/vtd/intremap.c	2012-09-14 =
13:26:34.000000000 +0200
+++ 2012-09-21/xen/drivers/passthrough/vtd/intremap.c	2012-09-21 =
10:54:46.000000000 +0200
@@ -135,7 +135,7 @@ int iommu_supports_eim(void)
         if ( !ioapic_to_drhd(IO_APIC_ID(apic)) )
     {
             dprintk(XENLOG_WARNING VTDPREFIX,
-                    "There is not a DRHD for IOAPIC 0x%x (id: 0x%x)!\n",
+                    "There is not a DRHD for IOAPIC %#x (id: %#x)!\n",
                     apic, IO_APIC_ID(apic));
             return 0;
     }
--- 2012-09-21.orig/xen/drivers/passthrough/vtd/iommu.c	2012-09-17 =
09:57:55.000000000 +0200
+++ 2012-09-21/xen/drivers/passthrough/vtd/iommu.c	2012-09-21 =
10:54:46.000000000 +0200
@@ -2035,7 +2035,7 @@ static int init_vtd_hw(void)
             {
                 iommu_intremap =3D 0;
                 dprintk(XENLOG_ERR VTDPREFIX,
-                    "ioapic_to_iommu: ioapic 0x%x (id: 0x%x) is NULL! "
+                    "ioapic_to_iommu: ioapic %#x (id: %#x) is NULL! "
                     "Will not try to enable Interrupt Remapping.\n",
                     apic, IO_APIC_ID(apic));
                 break;
--- 2012-09-21.orig/xen/drivers/passthrough/vtd/utils.c	2012-09-14 =
13:26:34.000000000 +0200
+++ 2012-09-21/xen/drivers/passthrough/vtd/utils.c	2012-09-21 =
10:54:46.000000000 +0200
@@ -217,7 +217,7 @@ static void dump_iommu_info(unsigned cha
             struct iremap_entry *iremap_entries =3D NULL;
             int print_cnt =3D 0;
=20
-            printk("  Interrupt remapping table (nr_entry=3D0x%x. "
+            printk("  Interrupt remapping table (nr_entry=3D%#x. "
                 "Only dump P=3D1 entries here):\n", nr_entry);
             printk("       SVT  SQ   SID      DST  V  AVL DLM TM RH DM "
                    "FPD P\n");
--- 2012-09-21.orig/xen/drivers/video/vesa.c	2012-09-14 13:26:34.0000000=
00 +0200
+++ 2012-09-21/xen/drivers/video/vesa.c	2012-09-21 10:54:46.000000000 =
+0200
@@ -111,7 +111,7 @@ void __init vesa_init(void)
=20
     vga_puts =3D vesa_redraw_puts;
=20
-    printk(XENLOG_INFO "vesafb: framebuffer at 0x%x, mapped to 0x%p, "
+    printk(XENLOG_INFO "vesafb: framebuffer at %#x, mapped to 0x%p, "
            "using %uk, total %uk\n",
            vlfb_info.lfb_base, lfb,
            vram_remap >> 10, vram_total >> 10);



--=__Part6756664C.0__=
Content-Type: text/plain; name="printk-alternative.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="printk-alternative.patch"

printk: prefer %#x et at over 0x%x=0A=0APerformance is not an issue with =
printk(), so let the function do=0Aminimally more work and instead save a =
byte per affected format=0Aspecifier.=0A=0ASigned-off-by: Jan Beulich =
<jbeulich@suse.com>=0A=0A--- 2012-09-21.orig/xen/arch/x86/acpi/boot.c	=
2012-09-20 08:44:38.000000000 +0200=0A+++ 2012-09-21/xen/arch/x86/acpi/boot=
.c	2012-09-21 10:54:46.000000000 +0200=0A@@ -341,14 +341,14 @@ =
acpi_fadt_parse_sleep_info(struct acpi_t=0A 	}=0A =0A 	if =
(facs->length < 24) {=0A-		printk(KERN_ERR PREFIX "Invalid =
FACS table length: 0x%x",=0A+		printk(KERN_ERR PREFIX "Invalid =
FACS table length: %#x",=0A 			facs->length);=0A 		=
goto bad;=0A 	}=0A =0A 	if (facs->length < 64)=0A 		=
printk(KERN_WARNING PREFIX=0A-			"FACS is shorter than ACPI =
spec allow: 0x%x",=0A+			"FACS is shorter than ACPI spec =
allow: %#x",=0A 			facs->length);=0A =0A 	acpi_sinfo.=
wakeup_vector =3D facs_pa + =0A--- 2012-09-21.orig/xen/arch/x86/acpi/cpu_id=
le.c	2012-08-15 08:32:43.000000000 +0200=0A+++ 2012-09-21/xen/arch/x86/a=
cpi/cpu_idle.c	2012-09-21 10:54:46.000000000 +0200=0A@@ -978,11 +978,11 =
@@ static void print_cx_pminfo(uint32_t cpu=0A             return;=0A      =
   =0A         printk("\tstates[%d]:\n", i);=0A-        printk("\t\treg.spa=
ce_id =3D 0x%x\n", state.reg.space_id);=0A-        printk("\t\treg.bit_widt=
h =3D 0x%x\n", state.reg.bit_width);=0A-        printk("\t\treg.bit_offset =
=3D 0x%x\n", state.reg.bit_offset);=0A-        printk("\t\treg.access_size =
=3D 0x%x\n", state.reg.access_size);=0A-        printk("\t\treg.address =
=3D 0x%"PRIx64"\n", state.reg.address);=0A+        printk("\t\treg.space_id=
 =3D %#x\n", state.reg.space_id);=0A+        printk("\t\treg.bit_width =3D =
%#x\n", state.reg.bit_width);=0A+        printk("\t\treg.bit_offset =3D =
%#x\n", state.reg.bit_offset);=0A+        printk("\t\treg.access_size =3D =
%#x\n", state.reg.access_size);=0A+        printk("\t\treg.address =3D =
%#"PRIx64"\n", state.reg.address);=0A         printk("\t\ttype    =3D =
%d\n", state.type);=0A         printk("\t\tlatency =3D %d\n", state.latency=
);=0A         printk("\t\tpower   =3D %d\n", state.power);=0A--- 2012-09-21=
.orig/xen/arch/x86/apic.c	2012-09-17 09:57:54.000000000 +0200=0A+++ =
2012-09-21/xen/arch/x86/apic.c	2012-09-21 10:54:46.000000000 +0200=0A@@ =
-689,7 +689,7 @@ void __devinit setup_local_APIC(void)=0A         value =
=3D apic_read(APIC_ESR);=0A         if (value !=3D oldvalue)=0A            =
 apic_printk(APIC_VERBOSE, "ESR value before enabling "=0A-                =
        "vector: 0x%08lx  after: 0x%08lx\n",=0A+                        =
"vector: %#lx  after: %#lx\n",=0A                         oldvalue, =
value);=0A     } else {=0A         if (esr_disable)    =0A@@ -1210,7 =
+1210,7 @@ static int __init calibrate_APIC_clock(v=0A     bus_cycle  =3D =
(u32) (1000000000000LL/bus_freq); /* in pico seconds */=0A     bus_scale  =
=3D (1000*262144)/bus_cycle;=0A =0A-    apic_printk(APIC_VERBOSE, "..... =
bus_scale =3D 0x%08X\n", bus_scale);=0A+    apic_printk(APIC_VERBOSE, =
"..... bus_scale =3D %#x\n", bus_scale);=0A     /* reset APIC to zero =
timeout value */=0A     __setup_APIC_LVTT(0);=0A =0A--- 2012-09-21.orig/xen=
/arch/x86/cpu/mcheck/mce.c	2012-09-20 08:44:38.000000000 +0200=0A+++ =
2012-09-21/xen/arch/x86/cpu/mcheck/mce.c	2012-09-21 10:54:46.0000000=
00 +0200=0A@@ -1147,7 +1147,7 @@ static int x86_mc_msrinject_verify(struc=
=0A         }=0A =0A         if (reason !=3D NULL) {=0A-            =
printk("HV MSR INJECT ERROR: MSR 0x%llx %s\n",=0A+            printk("HV =
MSR INJECT ERROR: MSR %#Lx %s\n",=0A                    (unsigned long =
long)mci->mcinj_msr[i].reg, reason);=0A             errs++;=0A         =
}=0A@@ -1191,8 +1191,7 @@ static void x86_mc_msrinject(void *data)=0A =0A  =
   for (i =3D 0, msr =3D &mci->mcinj_msr[0];=0A          i < mci->mcinj_cou=
nt; i++, msr++) {=0A-        printk("HV MSR INJECT (%s) target %u actual =
%u MSR 0x%llx "=0A-               "<-- 0x%llx\n",=0A+        printk("HV =
MSR INJECT (%s) target %u actual %u MSR %#Lx <-- %#Lx\n",=0A               =
 intpose ?  "interpose" : "hardware",=0A                mci->mcinj_cpunr, =
smp_processor_id(),=0A                (unsigned long long)msr->reg,=0A--- =
2012-09-21.orig/xen/arch/x86/cpu/mcheck/vmce.c	2012-08-08 08:20:09.0000000=
00 +0200=0A+++ 2012-09-21/xen/arch/x86/cpu/mcheck/vmce.c	2012-09-21 =
10:54:46.000000000 +0200=0A@@ -88,7 +88,7 @@ static int bank_mce_rdmsr(cons=
t struct v=0A     case MSR_IA32_MC0_CTL:=0A         /* stick all 1's to =
MCi_CTL */=0A         *val =3D ~0UL;=0A-        mce_printk(MCE_VERBOSE, =
"MCE: rdmsr MC%u_CTL 0x%"PRIx64"\n",=0A+        mce_printk(MCE_VERBOSE, =
"MCE: rdmsr MC%u_CTL %#"PRIx64"\n",=0A                    bank, *val);=0A  =
       break;=0A     case MSR_IA32_MC0_STATUS:=0A@@ -102,7 +102,7 @@ =
static int bank_mce_rdmsr(const struct v=0A                 *val =3D =
entry->mci_status;=0A                 mce_printk(MCE_VERBOSE,=0A           =
                 "MCE: rd MC%u_STATUS in vMCE# context "=0A-               =
            "value 0x%"PRIx64"\n", bank, *val);=0A+                        =
   "value %#"PRIx64"\n", bank, *val);=0A             }=0A         }=0A     =
    break;=0A@@ -116,7 +116,7 @@ static int bank_mce_rdmsr(const struct =
v=0A                 *val =3D entry->mci_addr;=0A                 =
mce_printk(MCE_VERBOSE,=0A                            "MCE: rdmsr =
MC%u_ADDR in vMCE# context "=0A-                           "0x%"PRIx64"\n",=
 bank, *val);=0A+                           "%#"PRIx64"\n", bank, =
*val);=0A             }=0A         }=0A         break;=0A@@ -130,7 +130,7 =
@@ static int bank_mce_rdmsr(const struct v=0A                 *val =3D =
entry->mci_misc;=0A                 mce_printk(MCE_VERBOSE,=0A             =
               "MCE: rd MC%u_MISC in vMCE# context "=0A-                   =
        "0x%"PRIx64"\n", bank, *val);=0A+                           =
"%#"PRIx64"\n", bank, *val);=0A             }=0A         }=0A         =
break;=0A@@ -171,18 +171,18 @@ int vmce_rdmsr(uint32_t msr, uint64_t *v=0A =
        *val =3D vmce->mcg_status;=0A         if (*val)=0A             =
mce_printk(MCE_VERBOSE,=0A-                       "MCE: rdmsr MCG_STATUS =
0x%"PRIx64"\n", *val);=0A+                       "MCE: rdmsr MCG_STATUS =
%#"PRIx64"\n", *val);=0A         break;=0A     case MSR_IA32_MCG_CAP:=0A   =
      *val =3D cur->arch.mcg_cap;=0A-        mce_printk(MCE_VERBOSE, "MCE: =
rdmsr MCG_CAP 0x%"PRIx64"\n",=0A+        mce_printk(MCE_VERBOSE, "MCE: =
rdmsr MCG_CAP %#"PRIx64"\n",=0A                    *val);=0A         =
break;=0A     case MSR_IA32_MCG_CTL:=0A         /* Stick all 1's when CTL =
support, and 0's when no CTL support */=0A         if ( cur->arch.mcg_cap =
& MCG_CTL_P )=0A             *val =3D ~0ULL;=0A-        mce_printk(MCE_VERB=
OSE, "MCE: rdmsr MCG_CTL 0x%"PRIx64"\n", *val);=0A+        mce_printk(MCE_V=
ERBOSE, "MCE: rdmsr MCG_CTL %#"PRIx64"\n", *val);=0A         break;=0A     =
default:=0A         ret =3D mce_bank_msr(cur, msr) ? bank_mce_rdmsr(cur, =
msr, val) : 0;=0A--- 2012-09-21.orig/xen/arch/x86/cpu/mtrr/generic.c	=
2011-04-11 08:33:59.000000000 +0200=0A+++ 2012-09-21/xen/arch/x86/cpu/mtrr/=
generic.c	2012-09-21 10:54:46.000000000 +0200=0A@@ -410,7 +410,7 @@ =
int generic_validate_add_page(unsigned l=0A 	    boot_cpu_data.x86_model=
 =3D=3D 1 &&=0A 	    boot_cpu_data.x86_mask <=3D 7) {=0A 		=
if (base & ((1 << (22 - PAGE_SHIFT)) - 1)) {=0A-			=
printk(KERN_WARNING "mtrr: base(0x%lx000) is not 4 MiB aligned\n", =
base);=0A+			printk(KERN_WARNING "mtrr: base(%#lx000) =
is not 4 MiB aligned\n", base);=0A 			return -EINVAL;=0A =
		}=0A 		if (!(base + size < 0x70000 || base > =
0x7003F) &&=0A@@ -427,7 +427,7 @@ int generic_validate_add_page(unsigned =
l=0A 	for (lbase =3D base; !(lbase & 1) && (last & 1);=0A 	     lbase =
=3D lbase >> 1, last =3D last >> 1) ;=0A 	if (lbase !=3D last) {=0A-	=
	printk(KERN_WARNING "mtrr: base(0x%lx000) is not aligned on a =
size(0x%lx000) boundary\n",=0A+		printk(KERN_WARNING "mtrr: =
base(%#lx000) is not aligned on a size(%#lx000) boundary\n",=0A 		=
       base, size);=0A 		return -EINVAL;=0A 	}=0A--- 2012-09-21.=
orig/xen/arch/x86/cpu/mtrr/main.c	2012-09-21 10:32:44.000000000 =
+0200=0A+++ 2012-09-21/xen/arch/x86/cpu/mtrr/main.c	2012-09-21 =
10:54:46.000000000 +0200=0A@@ -366,8 +366,8 @@ int mtrr_add_page(unsigned =
long base, un=0A 					continue;=0A 		=
	}=0A 			printk(KERN_WARNING=0A-			   =
    "mtrr: 0x%lx000,0x%lx000 overlaps existing"=0A-			   =
    " 0x%lx000,0x%lx000\n", base, size, lbase,=0A+			   =
    "mtrr: %#lx000,%#lx000 overlaps existing"=0A+			   =
    " %#lx000,%#lx000\n", base, size, lbase,=0A 			   =
    lsize);=0A 			goto out;=0A 		}=0A@@ -412,7 =
+412,7 @@ static int mtrr_check(unsigned long base=0A 		printk(KERN=
_WARNING=0A 			"mtrr: size and base must be multiples of =
4 kiB\n");=0A 		printk(KERN_DEBUG=0A-			"mtrr: =
size: 0x%lx  base: 0x%lx\n", size, base);=0A+			"mtrr: =
size: %#lx  base: %#lx\n", size, base);=0A 		dump_stack();=0A 	=
	return -1;=0A 	}=0A--- 2012-09-21.orig/xen/arch/x86/domain_build.c=
	2012-09-14 13:26:34.000000000 +0200=0A+++ 2012-09-21/xen/arch/x86/d=
omain_build.c	2012-09-21 10:55:47.000000000 +0200=0A@@ -396,13 +396,13 =
@@ int __init construct_dom0(=0A     }=0A     if (elf_64bit(&elf) && =
machine =3D=3D EM_X86_64)=0A         compatible =3D 1;=0A-    printk(" =
Dom0 kernel: %s%s, %s, paddr 0x%" PRIx64 " -> 0x%" PRIx64 "\n",=0A+    =
printk(" Dom0 kernel: %s%s, %s, paddr %#" PRIx64 " -> %#" PRIx64 "\n",=0A  =
          elf_64bit(&elf) ? "64-bit" : "32-bit",=0A            parms.pae   =
    ? ", PAE"  : "",=0A            elf_msb(&elf)   ? "msb"    : "lsb",=0A  =
          elf.pstart, elf.pend);=0A     if ( elf.bsd_symtab_pstart )=0A-   =
     printk(" Dom0 symbol map 0x%" PRIx64 " -> 0x%" PRIx64 "\n",=0A+       =
 printk(" Dom0 symbol map %#" PRIx64 " -> %#" PRIx64 "\n",=0A              =
  elf.bsd_symtab_pstart, elf.bsd_symtab_pend);=0A =0A     if ( !compatible =
)=0A--- 2012-09-21.orig/xen/arch/x86/hvm/hvm.c	2012-09-20 08:44:38.0000000=
00 +0200=0A+++ 2012-09-21/xen/arch/x86/hvm/hvm.c	2012-09-21 =
10:54:46.000000000 +0200=0A@@ -1468,7 +1468,7 @@ int hvm_set_efer(uint64_t =
value)=0A     if ( !hvm_efer_valid(v->domain, value, efer_validbits) )=0A  =
   {=0A         gdprintk(XENLOG_WARNING, "Trying to set reserved bit in =
"=0A-                 "EFER: 0x%"PRIx64"\n", value);=0A+                 =
"EFER: %#"PRIx64"\n", value);=0A         hvm_inject_hw_exception(TRAP_gp_fa=
ult, 0);=0A         return X86EMUL_EXCEPTION;=0A     }=0A@@ -4095,7 =
+4095,7 @@ long do_hvm_op(unsigned long op, XEN_GUE=0A             {=0A    =
             put_gfn(d, pfn);=0A                 gdprintk(XENLOG_WARNING,=
=0A-                         "type for pfn 0x%lx changed to grant while =
"=0A+                         "type for pfn %#lx changed to grant while =
"=0A                          "we were working?\n", pfn);=0A               =
  goto param_fail4;=0A             }=0A@@ -4106,7 +4106,7 @@ long =
do_hvm_op(unsigned long op, XEN_GUE=0A                 {=0A                =
     put_gfn(d, pfn);=0A                     gdprintk(XENLOG_WARNING,=0A-  =
                           "type of pfn 0x%lx changed from %d to %d while =
"=0A+                             "type of pfn %#lx changed from %d to %d =
while "=0A                              "we were trying to change it to =
%d\n",=0A                              pfn, t, nt, memtype[a.hvmmem_type]);=
=0A                     goto param_fail4;=0A--- 2012-09-21.orig/xen/arch/x8=
6/hvm/io.c	2012-07-30 09:49:58.000000000 +0200=0A+++ 2012-09-21/xen/ar=
ch/x86/hvm/io.c	2012-09-21 10:54:46.000000000 +0200=0A@@ -393,7 +393,7 @@ =
int dpci_ioport_intercept(ioreq_t *p)=0A =0A     if ( !ioports_access_permi=
tted(d, mport, mport + p->size - 1) ) =0A     {=0A-        gdprintk(XENLOG_=
ERR, "Error: access to gport=3D0x%x denied!\n",=0A+        gdprintk(XENLOG_=
ERR, "Error: access to gport=3D%#x denied!\n",=0A                  =
(uint32_t)p->addr);=0A         return X86EMUL_UNHANDLEABLE;=0A     }=0A--- =
2012-09-21.orig/xen/arch/x86/hvm/irq.c	2012-09-14 13:26:34.000000000 =
+0200=0A+++ 2012-09-21/xen/arch/x86/hvm/irq.c	2012-09-21 10:54:46.0000000=
00 +0200=0A@@ -488,7 +488,7 @@ static void irq_dump(struct domain *d)=0A   =
         hvm_irq->pci_link_assert_count[1],=0A            hvm_irq->pci_link=
_assert_count[2],=0A            hvm_irq->pci_link_assert_count[3]);=0A-    =
printk("Callback via %i:0x%"PRIx32",%s asserted\n", =0A+    printk("Callbac=
k via %i:%#"PRIx32",%s asserted\n",=0A            hvm_irq->callback_via_typ=
e, hvm_irq->callback_via.gsi, =0A            hvm_irq->callback_via_asserted=
 ? "" : " not");=0A }=0A--- 2012-09-21.orig/xen/arch/x86/hvm/svm/intr.c	=
2012-01-20 10:10:22.000000000 +0100=0A+++ 2012-09-21/xen/arch/x86/hvm/svm/i=
ntr.c	2012-09-21 10:54:46.000000000 +0200=0A@@ -175,7 +175,7 @@ void =
svm_intr_assist(void) =0A                 /* Guest already enabled an =
interrupt window. */=0A                 return;=0A             default:=0A-=
                panic("%s: nestedsvm_vcpu_interrupt can't handle value =
0x%x\n",=0A+                panic("%s: nestedsvm_vcpu_interrupt can't =
handle value %#x\n",=0A                     __func__, rc);=0A             =
}=0A         }=0A--- 2012-09-21.orig/xen/arch/x86/hvm/svm/nestedsvm.c	=
2012-09-05 11:59:49.000000000 +0200=0A+++ 2012-09-21/xen/arch/x86/hvm/svm/n=
estedsvm.c	2012-09-21 10:54:46.000000000 +0200=0A@@ -943,7 +943,7 @@ =
nsvm_vmcb_guest_intercepts_exitcode(stru=0A         break;=0A =0A     =
default:=0A-        gdprintk(XENLOG_ERR, "Illegal exitcode 0x%"PRIx64"\n", =
exitcode);=0A+        gdprintk(XENLOG_ERR, "Illegal exitcode %#"PRIx64"\n",=
 exitcode);=0A         BUG();=0A         break;=0A     }=0A@@ -1235,7 =
+1235,7 @@ int nsvm_wrmsr(struct vcpu *v, unsigned =0A     case MSR_K8_VM_H=
SAVE_PA:=0A         if (!nestedsvm_vmcb_isvalid(v, msr_content)) {=0A      =
       gdprintk(XENLOG_ERR,=0A-                "MSR_K8_VM_HSAVE_PA value =
invalid 0x%"PRIx64"\n", msr_content);=0A+                "MSR_K8_VM_HSAVE_P=
A value invalid %#"PRIx64"\n", msr_content);=0A             ret =3D -1; /* =
inject #GP */=0A             break;=0A         }=0A@@ -1244,7 +1244,7 @@ =
int nsvm_wrmsr(struct vcpu *v, unsigned =0A     case MSR_AMD64_TSC_RATIO:=
=0A         if ((msr_content & ~TSC_RATIO_RSVD_BITS) !=3D msr_content) =
{=0A             gdprintk(XENLOG_ERR,=0A-                "reserved bits =
set in MSR_AMD64_TSC_RATIO 0x%"PRIx64"\n",=0A+                "reserved =
bits set in MSR_AMD64_TSC_RATIO %#"PRIx64"\n",=0A                 =
msr_content);=0A             ret =3D -1; /* inject #GP */=0A             =
break;=0A--- 2012-09-21.orig/xen/arch/x86/hvm/svm/svm.c	2012-09-17 =
09:57:54.000000000 +0200=0A+++ 2012-09-21/xen/arch/x86/hvm/svm/svm.c	=
2012-09-21 10:54:46.000000000 +0200=0A@@ -241,7 +241,7 @@ static int =
svm_vmcb_restore(struct vcpu =0A          ((c->pending_type =3D=3D 1) || =
(c->pending_type > 6) ||=0A           (c->pending_reserved !=3D 0)) )=0A   =
  {=0A-        gdprintk(XENLOG_ERR, "Invalid pending event 0x%"PRIx32".\n",=
=0A+        gdprintk(XENLOG_ERR, "Invalid pending event %#"PRIx32".\n",=0A =
                 c->pending_event);=0A         return -EINVAL;=0A     =
}=0A@@ -254,7 +254,7 @@ static int svm_vmcb_restore(struct vcpu =0A        =
                              NULL, P2M_ALLOC);=0A             if ( !page =
)=0A             {=0A-                gdprintk(XENLOG_ERR, "Invalid CR3 =
value=3D0x%"PRIx64"\n",=0A+                gdprintk(XENLOG_ERR, "Invalid =
CR3 value=3D%#"PRIx64"\n",=0A                          c->cr3);=0A         =
        return -EINVAL;=0A             }=0A@@ -289,7 +289,7 @@ static int =
svm_vmcb_restore(struct vcpu =0A =0A     if ( c->pending_valid ) =0A     =
{=0A-        gdprintk(XENLOG_INFO, "Re-injecting 0x%"PRIx32", 0x%"PRIx32"\n=
",=0A+        gdprintk(XENLOG_INFO, "Re-injecting %#"PRIx32", %#"PRIx32"\n"=
,=0A                  c->pending_event, c->error_code);=0A =0A         if =
( hvm_event_needs_reinjection(c->pending_type, c->pending_vector) )=0A@@ =
-2398,8 +2398,8 @@ void svm_vmexit_handler(struct cpu_user_=0A =0A     =
default:=0A     exit_and_crash:=0A-        gdprintk(XENLOG_ERR, "unexpected=
 VMEXIT: exit reason =3D 0x%"PRIx64", "=0A-                 "exitinfo1 =3D =
%"PRIx64", exitinfo2 =3D %"PRIx64"\n",=0A+        gdprintk(XENLOG_ERR, =
"unexpected VMEXIT: exit reason =3D %#"PRIx64", "=0A+                 =
"exitinfo1 =3D %#"PRIx64", exitinfo2 =3D %#"PRIx64"\n",=0A                 =
 exit_reason, =0A                  (u64)vmcb->exitinfo1, (u64)vmcb->exitinf=
o2);=0A         domain_crash(v->domain);=0A--- 2012-09-21.orig/xen/arch/x86=
/hvm/svm/svmdebug.c	2011-07-11 08:32:12.000000000 +0200=0A+++ =
2012-09-21/xen/arch/x86/hvm/svm/svmdebug.c	2012-09-21 10:54:46.0000000=
00 +0200=0A@@ -32,33 +32,32 @@ static void svm_dump_sel(const char *nam=0A =
void svm_vmcb_dump(const char *from, struct vmcb_struct *vmcb)=0A {=0A     =
printk("Dumping guest's current state at %s...\n", from);=0A-    printk("Si=
ze of VMCB =3D %d, paddr =3D 0x%016lx, vaddr =3D %p\n",=0A+    printk("Size=
 of VMCB =3D %d, paddr =3D %#lx, vaddr =3D %p\n",=0A            (int) =
sizeof(struct vmcb_struct), virt_to_maddr(vmcb), vmcb);=0A =0A-    =
printk("cr_intercepts =3D 0x%08x dr_intercepts =3D 0x%08x "=0A-           =
"exception_intercepts =3D 0x%08x\n", =0A+    printk("cr_intercepts =3D %#x =
dr_intercepts =3D %#x "=0A+           "exception_intercepts =3D %#x\n",=0A =
           vmcb->_cr_intercepts, vmcb->_dr_intercepts, =0A            =
vmcb->_exception_intercepts);=0A-    printk("general1_intercepts =3D =
0x%08x general2_intercepts =3D 0x%08x\n", =0A+    printk("general1_intercep=
ts =3D %#x general2_intercepts =3D %#x\n",=0A            vmcb->_general1_in=
tercepts, vmcb->_general2_intercepts);=0A-    printk("iopm_base_pa =3D =
0x%016llx msrpm_base_pa =3D 0x%016llx tsc_offset =3D "=0A-            =
"0x%016llx\n", =0A+    printk("iopm_base_pa =3D %#Lx msrpm_base_pa =3D =
%#Lx tsc_offset =3D %#Lx\n",=0A            (unsigned long long)vmcb->_iopm_=
base_pa,=0A            (unsigned long long)vmcb->_msrpm_base_pa,=0A        =
    (unsigned long long)vmcb->_tsc_offset);=0A-    printk("tlb_control =3D =
0x%08x vintr =3D 0x%016llx interrupt_shadow =3D "=0A-            "0x%016llx=
\n", vmcb->tlb_control,=0A+    printk("tlb_control =3D %#x vintr =3D %#Lx =
interrupt_shadow =3D %#Lx\n",=0A+           vmcb->tlb_control,=0A          =
  (unsigned long long)vmcb->_vintr.bytes,=0A            (unsigned long =
long)vmcb->interrupt_shadow);=0A-    printk("exitcode =3D 0x%016llx =
exitintinfo =3D 0x%016llx\n", =0A+    printk("exitcode =3D %#Lx exitintinfo=
 =3D %#Lx\n",=0A            (unsigned long long)vmcb->exitcode,=0A         =
   (unsigned long long)vmcb->exitintinfo.bytes);=0A-    printk("exitinfo1 =
=3D 0x%016llx exitinfo2 =3D 0x%016llx \n",=0A+    printk("exitinfo1 =3D =
%#Lx exitinfo2 =3D %#Lx \n",=0A            (unsigned long long)vmcb->exitin=
fo1,=0A            (unsigned long long)vmcb->exitinfo2);=0A-    printk("np_=
enable =3D 0x%016llx guest_asid =3D 0x%03x\n", =0A+    printk("np_enable =
=3D %Lx guest_asid =3D %#x\n",=0A            (unsigned long long)vmcb->_np_=
enable, vmcb->_guest_asid);=0A-    printk("cpl =3D %d efer =3D 0x%016llx =
star =3D 0x%016llx lstar =3D 0x%016llx\n", =0A+    printk("cpl =3D %d efer =
=3D %#Lx star =3D %#Lx lstar =3D %#Lx\n",=0A            vmcb->_cpl, =
(unsigned long long)vmcb->_efer,=0A            (unsigned long long)vmcb->st=
ar, (unsigned long long)vmcb->lstar);=0A     printk("CR0 =3D 0x%016llx CR2 =
=3D 0x%016llx\n",=0A@@ -77,7 +76,7 @@ void svm_vmcb_dump(const char *from, =
str=0A     printk("KernGSBase =3D 0x%016llx PAT =3D 0x%016llx \n", =0A     =
       (unsigned long long)vmcb->kerngsbase,=0A            (unsigned long =
long)vmcb->_g_pat);=0A-    printk("H_CR3 =3D 0x%016llx CleanBits =3D =
0x%08x\n",=0A+    printk("H_CR3 =3D 0x%016llx CleanBits =3D %#x\n",=0A     =
       (unsigned long long)vmcb->_h_cr3, vmcb->cleanbits.bytes);=0A =0A    =
 /* print out all the selectors */=0A@@ -104,48 +103,48 @@ svm_vmcb_isvalid=
(const char *from, struc=0A     } else return 1;=0A =0A     if ((vmcb->_efe=
r & EFER_SVME) =3D=3D 0) {=0A-        PRINTF("EFER: SVME bit not set =
(0x%"PRIx64")\n", vmcb->_efer);=0A+        PRINTF("EFER: SVME bit not set =
(%#"PRIx64")\n", vmcb->_efer);=0A     }=0A =0A     if ((vmcb->_cr0 & =
X86_CR0_CD) =3D=3D 0 && (vmcb->_cr0 & X86_CR0_NW) !=3D 0) {=0A-        =
PRINTF("CR0: CD bit is zero and NW bit set (0x%"PRIx64")\n",=0A+        =
PRINTF("CR0: CD bit is zero and NW bit set (%#"PRIx64")\n",=0A             =
    vmcb->_cr0);=0A     }=0A =0A     if ((vmcb->_cr0 >> 32U) !=3D 0) {=0A- =
       PRINTF("CR0: bits [63:32] are not zero (0x%"PRIx64")\n",=0A+        =
PRINTF("CR0: bits [63:32] are not zero (%#"PRIx64")\n",=0A                 =
vmcb->_cr0);=0A     }=0A =0A     if ((vmcb->_cr3 & 0x7) !=3D 0) {=0A-      =
  PRINTF("CR3: MBZ bits are set (0x%"PRIx64")\n", vmcb->_cr3);=0A+        =
PRINTF("CR3: MBZ bits are set (%#"PRIx64")\n", vmcb->_cr3);=0A     }=0A    =
 if ((vmcb->_efer & EFER_LMA) && (vmcb->_cr3 & 0xfe) !=3D 0) {=0A-        =
PRINTF("CR3: MBZ bits are set (0x%"PRIx64")\n", vmcb->_cr3);=0A+        =
PRINTF("CR3: MBZ bits are set (%#"PRIx64")\n", vmcb->_cr3);=0A     }=0A =
=0A     if ((vmcb->_cr4 >> 19U) !=3D 0) {=0A-        PRINTF("CR4: bits =
[63:19] are not zero (0x%"PRIx64")\n",=0A+        PRINTF("CR4: bits =
[63:19] are not zero (%#"PRIx64")\n",=0A                 vmcb->_cr4);=0A   =
  }=0A =0A     if (((vmcb->_cr4 >> 11U) & 0x7fU) !=3D 0) {=0A-        =
PRINTF("CR4: bits [17:11] are not zero (0x%"PRIx64")\n",=0A+        =
PRINTF("CR4: bits [17:11] are not zero (%#"PRIx64")\n",=0A                 =
vmcb->_cr4);=0A     }=0A =0A     if ((vmcb->_dr6 >> 32U) !=3D 0) {=0A-     =
   PRINTF("DR6: bits [63:32] are not zero (0x%"PRIx64")\n",=0A+        =
PRINTF("DR6: bits [63:32] are not zero (%#"PRIx64")\n",=0A                 =
vmcb->_dr6);=0A     }=0A =0A     if ((vmcb->_dr7 >> 32U) !=3D 0) {=0A-     =
   PRINTF("DR7: bits [63:32] are not zero (0x%"PRIx64")\n",=0A+        =
PRINTF("DR7: bits [63:32] are not zero (%#"PRIx64")\n",=0A                 =
vmcb->_dr7);=0A     }=0A =0A     if ((vmcb->_efer >> 15U) !=3D 0) {=0A-    =
    PRINTF("EFER: bits [63:15] are not zero (0x%"PRIx64")\n",=0A+        =
PRINTF("EFER: bits [63:15] are not zero (%#"PRIx64")\n",=0A                =
 vmcb->_efer);=0A     }=0A =0A@@ -168,12 +167,12 @@ svm_vmcb_isvalid(const =
char *from, struc=0A     }=0A =0A     if ((vmcb->_general2_intercepts & =
GENERAL2_INTERCEPT_VMRUN) =3D=3D 0) {=0A-        PRINTF("GENERAL2_INTERCEPT=
: VMRUN intercept bit is clear (0x%"PRIx32")\n",=0A+        PRINTF("GENERAL=
2_INTERCEPT: VMRUN intercept bit is clear (%#"PRIx32")\n",=0A             =
vmcb->_general2_intercepts);=0A     }=0A =0A     if (vmcb->eventinj.fields.=
resvd1 !=3D 0) {=0A-        PRINTF("eventinj: MBZ bits are set (0x%"PRIx64"=
)\n",=0A+        PRINTF("eventinj: MBZ bits are set (%#"PRIx64")\n",=0A    =
             vmcb->eventinj.bytes);=0A     }=0A =0A--- 2012-09-21.orig/xen/=
arch/x86/hvm/vlapic.c	2012-09-20 08:44:38.000000000 +0200=0A+++ =
2012-09-21/xen/arch/x86/hvm/vlapic.c	2012-09-21 10:54:46.000000000 =
+0200=0A@@ -172,7 +172,7 @@ static uint32_t vlapic_get_ppr(struct vl=0A    =
     ppr =3D isrv & 0xf0;=0A =0A     HVM_DBG_LOG(DBG_LEVEL_VLAPIC_INTERRUPT=
,=0A-                "vlapic %p, ppr 0x%x, isr 0x%x, isrv 0x%x",=0A+       =
         "vlapic %p, ppr %#x, isr %#x, isrv %#x",=0A                 =
vlapic, ppr, isr, isrv);=0A =0A     return ppr;=0A@@ -215,8 +215,8 @@ =
bool_t vlapic_match_dest(=0A     struct vlapic *target, struct vlapic =
*source,=0A     int short_hand, uint8_t dest, uint8_t dest_mode)=0A {=0A-  =
  HVM_DBG_LOG(DBG_LEVEL_VLAPIC, "target %p, source %p, dest 0x%x, "=0A-    =
            "dest_mode 0x%x, short_hand 0x%x",=0A+    HVM_DBG_LOG(DBG_LEVEL=
_VLAPIC, "target %p, source %p, dest %#x, "=0A+                "dest_mode =
%#x, short_hand %#x",=0A                 target, source, dest, dest_mode, =
short_hand);=0A =0A     switch ( short_hand )=0A@@ -562,20 +562,20 @@ =
static int vlapic_read(=0A         break;=0A =0A     default:=0A-        =
gdprintk(XENLOG_ERR, "Local APIC read with len=3D0x%lx, "=0A+        =
gdprintk(XENLOG_ERR, "Local APIC read with len=3D%#lx, "=0A                =
  "should be 4 instead.\n", len);=0A         goto exit_and_crash;=0A     =
}=0A =0A-    HVM_DBG_LOG(DBG_LEVEL_VLAPIC, "offset 0x%x with length 0x%lx, =
"=0A-                "and the result is 0x%lx", offset, len, result);=0A+  =
  HVM_DBG_LOG(DBG_LEVEL_VLAPIC, "offset %#x with length %#lx, "=0A+        =
        "and the result is %#lx", offset, len, result);=0A =0A  out:=0A    =
 *pval =3D result;=0A     return X86EMUL_OKAY;=0A =0A  unaligned_exit_and_c=
rash:=0A-    gdprintk(XENLOG_ERR, "Unaligned LAPIC read len=3D0x%lx at =
offset=3D0x%x.\n",=0A+    gdprintk(XENLOG_ERR, "Unaligned LAPIC read =
len=3D%#lx at offset=3D%#x.\n",=0A              len, offset);=0A  =
exit_and_crash:=0A     domain_crash(v->domain);=0A@@ -759,7 +759,7 @@ =
static int vlapic_reg_write(struct vcpu =0A =0A     case APIC_TDCR:=0A     =
    vlapic_set_tdcr(vlapic, val & 0xb);=0A-        HVM_DBG_LOG(DBG_LEVEL_VL=
APIC_TIMER, "timer divisor is 0x%x",=0A+        HVM_DBG_LOG(DBG_LEVEL_VLAPI=
C_TIMER, "timer divisor is %#x",=0A                     vlapic->hw.timer_di=
visor);=0A         break;=0A =0A@@ -768,7 +768,7 @@ static int vlapic_reg_w=
rite(struct vcpu =0A     }=0A     if (rc =3D=3D X86EMUL_UNHANDLEABLE)=0A   =
      gdprintk(XENLOG_DEBUG,=0A-                "Local APIC Write wrong to =
register 0x%x\n", offset);=0A+                "Local APIC Write wrong to =
register %#x\n", offset);=0A     return rc;=0A }=0A =0A@@ -781,7 +781,7 @@ =
static int vlapic_write(struct vcpu *v, =0A =0A     if ( offset !=3D 0xb0 =
)=0A         HVM_DBG_LOG(DBG_LEVEL_VLAPIC,=0A-                    "offset =
0x%x with length 0x%lx, and value is 0x%lx",=0A+                    =
"offset %#x with length %#lx, and value is %#lx",=0A                     =
offset, len, val);=0A =0A     /*=0A@@ -827,7 +827,7 @@ static int =
vlapic_write(struct vcpu *v, =0A     return vlapic_reg_write(v, offset, =
val);=0A =0A  unaligned_exit_and_crash:=0A-    gdprintk(XENLOG_ERR, =
"Unaligned LAPIC write len=3D0x%lx at offset=3D0x%x.\n",=0A+    gdprintk(XE=
NLOG_ERR, "Unaligned LAPIC write len=3D%#lx at offset=3D%#x.\n",=0A        =
      len, offset);=0A  exit_and_crash:=0A     domain_crash(v->domain);=0A-=
-- 2012-09-21.orig/xen/arch/x86/hvm/vmx/vmcs.c	2012-09-20 08:44:38.0000000=
00 +0200=0A+++ 2012-09-21/xen/arch/x86/hvm/vmx/vmcs.c	2012-09-21 =
10:54:46.000000000 +0200=0A@@ -121,7 +121,7 @@ static u32 adjust_vmx_contro=
ls(=0A static bool_t cap_check(const char *name, u32 expected, u32 saw)=0A =
{=0A     if ( saw !=3D expected )=0A-        printk("VMX %s: saw 0x%08x =
expected 0x%08x\n", name, saw, expected);=0A+        printk("VMX %s: saw =
%#x expected %#x\n", name, saw, expected);=0A     return saw !=3D =
expected;=0A }=0A =0A--- 2012-09-21.orig/xen/arch/x86/hvm/vmx/vmx.c	=
2012-09-20 08:44:38.000000000 +0200=0A+++ 2012-09-21/xen/arch/x86/hvm/vmx/v=
mx.c	2012-09-21 11:01:46.000000000 +0200=0A@@ -210,7 +210,7 @@ =
long_mode_do_msr_read(unsigned int msr, =0A         return HNDL_unhandled;=
=0A     }=0A =0A-    HVM_DBG_LOG(DBG_LEVEL_0, "msr 0x%x content 0x%"PRIx64,=
 msr, *msr_content);=0A+    HVM_DBG_LOG(DBG_LEVEL_0, "msr %#x content =
%#"PRIx64, msr, *msr_content);=0A =0A     return HNDL_done;=0A }=0A@@ =
-222,7 +222,7 @@ long_mode_do_msr_write(unsigned int msr,=0A     struct =
vmx_msr_state *guest_msr_state =3D &v->arch.hvm_vmx.msr_state;=0A     =
struct vmx_msr_state *host_msr_state =3D &this_cpu(host_msr_state);=0A =
=0A-    HVM_DBG_LOG(DBG_LEVEL_0, "msr 0x%x content 0x%"PRIx64, msr, =
msr_content);=0A+    HVM_DBG_LOG(DBG_LEVEL_0, "msr %#x content %#"PRIx64, =
msr, msr_content);=0A =0A     switch ( msr )=0A     {=0A@@ -466,7 +466,7 =
@@ static int vmx_restore_cr0_cr3(=0A                                      =
NULL, P2M_ALLOC);=0A             if ( !page )=0A             {=0A-         =
       gdprintk(XENLOG_ERR, "Invalid CR3 value=3D0x%lx\n", cr3);=0A+       =
         gdprintk(XENLOG_ERR, "Invalid CR3 value=3D%#lx\n", cr3);=0A       =
          return -EINVAL;=0A             }=0A         }=0A@@ -492,7 +492,7 =
@@ static int vmx_vmcs_restore(struct vcpu =0A          ((c->pending_type =
=3D=3D 1) || (c->pending_type > 6) ||=0A           (c->pending_reserved =
!=3D 0)) )=0A     {=0A-        gdprintk(XENLOG_ERR, "Invalid pending event =
0x%"PRIx32".\n",=0A+        gdprintk(XENLOG_ERR, "Invalid pending event =
%#"PRIx32".\n",=0A                  c->pending_event);=0A         return =
-EINVAL;=0A     }=0A@@ -524,7 +524,7 @@ static int vmx_vmcs_restore(struct =
vcpu =0A =0A     if ( c->pending_valid )=0A     {=0A-        gdprintk(XENLO=
G_INFO, "Re-injecting 0x%"PRIx32", 0x%"PRIx32"\n",=0A+        gdprintk(XENL=
OG_INFO, "Re-injecting %#"PRIx32", %#"PRIx32"\n",=0A                  =
c->pending_event, c->error_code);=0A =0A         if ( hvm_event_needs_reinj=
ection(c->pending_type, c->pending_vector) )=0A@@ -1789,7 +1789,7 @@ =
static int is_last_branch_msr(u32 ecx)=0A =0A static int vmx_msr_read_inter=
cept(unsigned int msr, uint64_t *msr_content)=0A {=0A-    HVM_DBG_LOG(DBG_L=
EVEL_1, "ecx=3D%x", msr);=0A+    HVM_DBG_LOG(DBG_LEVEL_1, "ecx=3D%#x", =
msr);=0A =0A     switch ( msr )=0A     {=0A@@ -1854,7 +1854,7 @@ static =
int vmx_msr_read_intercept(unsign=0A     }=0A =0A done:=0A-    HVM_DBG_LOG(=
DBG_LEVEL_1, "returns: ecx=3D%x, msr_value=3D0x%"PRIx64,=0A+    HVM_DBG_LOG=
(DBG_LEVEL_1, "returns: ecx=3D%#x, msr_value=3D%#"PRIx64,=0A               =
  msr, *msr_content);=0A     return X86EMUL_OKAY;=0A =0A@@ -1927,8 +1927,7 =
@@ static int vmx_msr_write_intercept(unsig=0A {=0A     struct vcpu *v =3D =
current;=0A =0A-    HVM_DBG_LOG(DBG_LEVEL_1, "ecx=3D%x, msr_value=3D0x%"PRI=
x64,=0A-                msr, msr_content);=0A+    HVM_DBG_LOG(DBG_LEVEL_1, =
"ecx=3D%#x, msr_value=3D%#"PRIx64, msr, msr_content);=0A =0A     switch ( =
msr )=0A     {=0A@@ -2107,7 +2106,7 @@ static void vmx_failed_vmentry(unsig=
ned =0A     unsigned long exit_qualification =3D __vmread(EXIT_QUALIFICATIO=
N);=0A     struct vcpu *curr =3D current;=0A =0A-    printk("Failed vm =
entry (exit reason 0x%x) ", exit_reason);=0A+    printk("Failed vm entry =
(exit reason %#x) ", exit_reason);=0A     switch ( failed_vmentry_reason =
)=0A     {=0A     case EXIT_REASON_INVALID_GUEST_STATE:=0A--- 2012-09-21.or=
ig/xen/arch/x86/io_apic.c	2012-09-21 10:32:44.000000000 +0200=0A+++ =
2012-09-21/xen/arch/x86/io_apic.c	2012-09-21 10:54:46.000000000 =
+0200=0A@@ -2204,7 +2204,7 @@ int io_apic_set_pci_routing (int ioapic,=0A  =
   entry.vector =3D vector;=0A =0A     apic_printk(APIC_DEBUG, KERN_DEBUG =
"IOAPIC[%d]: Set PCI routing entry "=0A-		"(%d-%d -> 0x%x -> =
IRQ %d Mode:%i Active:%i)\n", ioapic,=0A+		"(%d-%d -> %#x -> =
IRQ %d Mode:%i Active:%i)\n", ioapic,=0A 		mp_ioapics[ioapic].=
mpc_apicid, pin, entry.vector, irq,=0A 		edge_level, active_high_low=
);=0A =0A--- 2012-09-21.orig/xen/arch/x86/microcode_amd.c	2012-02-10 =
11:25:54.000000000 +0100=0A+++ 2012-09-21/xen/arch/x86/microcode_amd.c	=
2012-09-21 10:54:46.000000000 +0200=0A@@ -88,7 +88,7 @@ static int =
collect_cpu_info(int cpu, str=0A =0A     rdmsrl(MSR_AMD_PATCHLEVEL, =
csig->rev);=0A =0A-    printk(KERN_DEBUG "microcode: collect_cpu_info: =
patch_id=3D0x%x\n",=0A+    printk(KERN_DEBUG "microcode: collect_cpu_info: =
patch_id=3D%#x\n",=0A            csig->rev);=0A =0A     return 0;=0A@@ =
-132,7 +132,7 @@ static int microcode_fits(const struct m=0A         =
return 0;=0A =0A     printk(KERN_DEBUG "microcode: CPU%d found a matching =
microcode "=0A-           "update with version 0x%x (current=3D0x%x)\n",=0A=
+           "update with version %#x (current=3D%#x)\n",=0A            =
cpu, mc_header->patch_id, uci->cpu_sig.rev);=0A =0A     return 1;=0A@@ =
-169,7 +169,7 @@ static int apply_microcode(int cpu)=0A     if ( rev !=3D =
hdr->patch_id )=0A     {=0A         printk(KERN_ERR "microcode: CPU%d =
update from revision "=0A-               "0x%x to 0x%x failed\n", cpu, =
hdr->patch_id, rev);=0A+               "%#x to %#x failed\n", cpu, =
hdr->patch_id, rev);=0A         return -EIO;=0A     }=0A =0A--- 2012-09-21.=
orig/xen/arch/x86/microcode_intel.c	2011-12-12 09:01:34.000000000 =
+0100=0A+++ 2012-09-21/xen/arch/x86/microcode_intel.c	2012-09-21 =
10:54:46.000000000 +0200=0A@@ -122,7 +122,7 @@ static int collect_cpu_info(=
int cpu_num,=0A     /* get the current revision from MSR 0x8B */=0A     =
rdmsrl(MSR_IA32_UCODE_REV, msr_content);=0A     csig->rev =3D (uint32_t)(ms=
r_content >> 32);=0A-    pr_debug("microcode: collect_cpu_info : sig=3D0x%x=
, pf=3D0x%x, rev=3D0x%x\n",=0A+    pr_debug("microcode: collect_cpu_info : =
sig=3D%#x, pf=3D%#x, rev=3D%#x\n",=0A              csig->sig, csig->pf, =
csig->rev);=0A =0A     return 0;=0A@@ -264,7 +264,7 @@ static int =
get_matching_microcode(const =0A     if ( uci->mc.mc_intel && uci->mc.mc_in=
tel->hdr.rev >=3D mc_header->rev )=0A         return 0;=0A     pr_debug("mi=
crocode: CPU%d found a matching microcode update with"=0A-             " =
version 0x%x (current=3D0x%x)\n",=0A+             " version %#x (current=3D=
%#x)\n",=0A              cpu, mc_header->rev, uci->cpu_sig.rev);=0A     =
new_mc =3D xmalloc_bytes(total_size);=0A     if ( new_mc =3D=3D NULL =
)=0A@@ -311,11 +311,11 @@ static int apply_microcode(int cpu)=0A     if ( =
val[1] !=3D uci->mc.mc_intel->hdr.rev )=0A     {=0A         printk(KERN_ERR=
 "microcode: CPU%d update from revision "=0A-               "0x%x to 0x%x =
failed\n", cpu_num, uci->cpu_sig.rev, val[1]);=0A+               "%#x to =
%#x failed\n", cpu_num, uci->cpu_sig.rev, val[1]);=0A         return =
-EIO;=0A     }=0A     printk(KERN_INFO "microcode: CPU%d updated from =
revision "=0A-           "0x%x to 0x%x, date =3D %04x-%02x-%02x \n",=0A+   =
        "%#x to %#x, date =3D %04x-%02x-%02x \n",=0A            cpu_num, =
uci->cpu_sig.rev, val[1],=0A            uci->mc.mc_intel->hdr.date & =
0xffff,=0A            uci->mc.mc_intel->hdr.date >> 24,=0A--- 2012-09-21.or=
ig/xen/arch/x86/mm.c	2012-09-14 13:26:34.000000000 +0200=0A+++ =
2012-09-21/xen/arch/x86/mm.c	2012-09-21 10:54:46.000000000 +0200=0A@@ =
-3102,7 +3102,7 @@ long do_mmuext_op(=0A         }=0A =0A         =
default:=0A-            MEM_LOG("Invalid extended pt command 0x%x", =
op.cmd);=0A+            MEM_LOG("Invalid extended pt command %#x", =
op.cmd);=0A             rc =3D -ENOSYS;=0A             okay =3D 0;=0A      =
       break;=0A--- 2012-09-21.orig/xen/arch/x86/mm/hap/nested_hap.c	=
2012-08-08 08:20:09.000000000 +0200=0A+++ 2012-09-21/xen/arch/x86/mm/hap/ne=
sted_hap.c	2012-09-21 10:54:46.000000000 +0200=0A@@ -129,7 +129,7 @@ =
nestedhap_fix_p2m(struct vcpu *v, struct=0A =0A     if (rv =3D=3D 0) {=0A  =
       gdprintk(XENLOG_ERR,=0A-		"failed to set entry for 0x%"PRIx64=
" -> 0x%"PRIx64"\n",=0A+		"failed to set entry for %#"PRIx64"=
 -> %#"PRIx64"\n",=0A 		L2_gpa, L0_gpa);=0A         BUG();=0A     =
}=0A--- 2012-09-21.orig/xen/arch/x86/mm/p2m-pt.c	2012-09-14 =
13:26:34.000000000 +0200=0A+++ 2012-09-21/xen/arch/x86/mm/p2m-pt.c	=
2012-09-21 10:54:46.000000000 +0200=0A@@ -110,8 +110,8 @@ p2m_find_entry(vo=
id *table, unsigned lon=0A     index =3D *gfn_remainder >> shift;=0A     =
if ( index >=3D max )=0A     {=0A-        P2M_DEBUG("gfn=3D0x%lx out of =
range "=0A-                  "(gfn_remainder=3D0x%lx shift=3D%d index=3D0x%=
x max=3D0x%x)\n",=0A+        P2M_DEBUG("gfn=3D%#lx out of range "=0A+      =
            "(gfn_remainder=3D%#lx shift=3D%d index=3D%#x max=3D%#x)\n",=0A=
                   gfn, *gfn_remainder, shift, index, max);=0A         =
return NULL;=0A     }=0A--- 2012-09-21.orig/xen/arch/x86/mm/shadow/common.c=
	2012-09-14 13:26:34.000000000 +0200=0A+++ 2012-09-21/xen/arch/x86/m=
m/shadow/common.c	2012-09-21 10:57:38.000000000 +0200=0A@@ -872,7 =
+872,7 @@ static int sh_skip_sync(struct vcpu *v, =0A         return =
SHADOW_INTERNAL_NAME(sh_safe_not_to_sync, 3)(v, gl1mfn);=0A     else if ( =
pg->shadow_flags & SHF_L1_64 )=0A         return SHADOW_INTERNAL_NAME(sh_sa=
fe_not_to_sync, 4)(v, gl1mfn);=0A-    SHADOW_ERROR("gmfn 0x%lx was OOS but =
not shadowed as an l1.\n", =0A+    SHADOW_ERROR("gmfn %#lx was OOS but not =
shadowed as an l1.\n",=0A                  mfn_x(gl1mfn));=0A     =
BUG();=0A     return 0; /* BUG() is no longer __attribute__((noreturn)). =
*/=0A@@ -2596,8 +2596,8 @@ void sh_remove_shadows(struct vcpu *v, m=0A     =
smfn =3D shadow_hash_lookup(v, mfn_x(gmfn), t);                       \=0A =
    if ( unlikely(!mfn_valid(smfn)) )                                   =
\=0A     {                                                                 =
  \=0A-        SHADOW_ERROR(": gmfn %#lx has flags 0x%"PRIx32              =
    \=0A-                     " but no type-0x%"PRIx32" shadow\n",         =
      \=0A+        SHADOW_ERROR(": gmfn %#lx has flags %#"PRIx32           =
        \=0A+                     " but no type-%#"PRIx32" shadow\n",      =
          \=0A                      mfn_x(gmfn), (uint32_t)pg->shadow_flags=
, t);       \=0A         break;                                            =
              \=0A     }                                                   =
                \=0A--- 2012-09-21.orig/xen/arch/x86/mm/shadow/multi.c	=
2012-09-14 13:26:34.000000000 +0200=0A+++ 2012-09-21/xen/arch/x86/mm/shadow=
/multi.c	2012-09-21 10:54:46.000000000 +0200=0A@@ -2171,7 +2171,7 =
@@ static int validate_gl4e(struct vcpu *v,=0A             // attempt by =
the guest to write to a xen reserved slot=0A             //=0A             =
SHADOW_PRINTK("%s out-of-range update "=0A-                           =
"sl4mfn=3D%05lx index=3D0x%x val=3D%" SH_PRI_pte "\n",=0A+                 =
          "sl4mfn=3D%05lx index=3D%#x val=3D%" SH_PRI_pte "\n",=0A         =
                   __func__, mfn_x(sl4mfn), shadow_index, new_sl4e.l4);=0A =
            if ( shadow_l4e_get_flags(new_sl4e) & _PAGE_PRESENT )=0A       =
      {=0A--- 2012-09-21.orig/xen/arch/x86/mpparse.c	2012-04-20 =
09:49:25.000000000 +0200=0A+++ 2012-09-21/xen/arch/x86/mpparse.c	=
2012-09-21 10:54:46.000000000 +0200=0A@@ -216,7 +216,7 @@ static void =
__init MP_ioapic_info (struc=0A 	if (!(m->mpc_flags & MPC_APIC_USABL=
E))=0A 		return;=0A =0A-	printk(KERN_INFO "I/O APIC #%d Version %d =
at 0x%X.\n",=0A+	printk(KERN_INFO "I/O APIC #%d Version %d at =
%#x.\n",=0A 		m->mpc_apicid, m->mpc_apicver, m->mpc_apicaddr);=0A=
 	if (nr_ioapics >=3D MAX_IO_APICS) {=0A 		printk(KERN_CRIT =
"Max # of I/O APICs (%d) exceeded (found %d).\n",=0A@@ -278,7 +278,7 @@ =
static int __init smp_read_mpc(struct mp=0A 	unsigned char *mpt=3D((unsi=
gned char *)mpc)+count;=0A =0A 	if (memcmp(mpc->mpc_signature,MPC_SIGNATURE=
,4)) {=0A-		printk(KERN_ERR "SMP mptable: bad signature =
[0x%x]!\n",=0A+		printk(KERN_ERR "SMP mptable: bad signature =
[%#x]!\n",=0A 			*(u32 *)mpc->mpc_signature);=0A 		=
return 0;=0A 	}=0A@@ -305,7 +305,7 @@ static int __init smp_read_mpc(stru=
ct mp=0A =0A 	mps_oem_check(mpc, oem, str);=0A =0A-	printk("APIC at: =
0x%X\n",mpc->mpc_lapic);=0A+	printk("APIC at: %#x\n", mpc->mpc_lapic);=
=0A =0A 	/* =0A 	 * Save the local APIC address (it might be =
non-default) -- but only=0A@@ -881,7 +881,7 @@ void __init mp_register_ioap=
ic (=0A 	mp_ioapic_routing[idx].gsi_end =3D gsi_base + =0A 		=
io_apic_get_redir_entries(idx);=0A =0A-	printk("IOAPIC[%d]: apic_id %d, =
version %d, address 0x%x, "=0A+	printk("IOAPIC[%d]: apic_id %d, version =
%d, address %#x, "=0A 		"GSI %d-%d\n", idx, mp_ioapics[idx].mpc_api=
cid, =0A 		mp_ioapics[idx].mpc_apicver, mp_ioapics[idx].mpc_ap=
icaddr,=0A 		mp_ioapic_routing[idx].gsi_base,=0A--- 2012-09-21.o=
rig/xen/arch/x86/nmi.c	2012-08-08 08:20:09.000000000 +0200=0A+++ =
2012-09-21/xen/arch/x86/nmi.c	2012-09-21 10:54:46.000000000 +0200=0A@@ =
-245,7 +245,7 @@ static inline void write_watchdog_counte=0A =0A     =
do_div(count, nmi_hz);=0A     if(descr)=0A-        Dprintk("setting %s to =
-0x%"PRIx64"\n", descr, count);=0A+        Dprintk("setting %s to =
-%#"PRIx64"\n", descr, count);=0A     wrmsrl(nmi_perfctr_msr, 0 - =
count);=0A }=0A =0A--- 2012-09-21.orig/xen/arch/x86/oprofile/op_model_athlo=
n.c	2012-09-14 13:26:34.000000000 +0200=0A+++ 2012-09-21/xen/arch/x86/o=
profile/op_model_athlon.c	2012-09-21 10:54:46.000000000 +0200=0A@@ =
-478,7 +478,7 @@ static int __init init_ibs_nmi(void)=0A 			=
		if (value !=3D (IBSCTL_LVTOFFSETVAL |=0A 			=
			APIC_EILVT_LVTOFF_IBS)) {=0A 				=
		printk("Xenoprofile: Failed to setup IBS LVT offset, "=0A-	=
						"IBSCTL =3D %#08x\n", =
value);=0A+							"IBSCTL =
=3D %#x\n", value);=0A 						return =
1;=0A 					}=0A 					=
nodes++;=0A@@ -523,7 +523,7 @@ void __init ibs_init(void)=0A 		=
return;=0A 	}=0A =0A-	printk("Xenoprofile: AMD IBS detected =
(0x%08x)\n",=0A+	printk("Xenoprofile: AMD IBS detected (%#x)\n",=0A =
		(unsigned)ibs_caps);=0A }=0A =0A--- 2012-09-21.orig/xen/arc=
h/x86/oprofile/op_model_p4.c	2012-02-10 11:25:54.000000000 +0100=0A+++ =
2012-09-21/xen/arch/x86/oprofile/op_model_p4.c	2012-09-21 10:54:46.0000000=
00 +0200=0A@@ -485,8 +485,7 @@ static void pmc_setup_one_p4_counter(uns=0A =
	=0A 	/* find our event binding structure. */=0A 	if =
(counter_config[ctr].event <=3D 0 || counter_config[ctr].event > NUM_EVENTS=
) {=0A-		printk(KERN_ERR =0A-		       "oprofile: P4 event =
code 0x%lx out of range\n", =0A+		printk(KERN_ERR "oprofile: =
P4 event code %#lx out of range\n",=0A 		       counter_config[ctr].=
event);=0A 		return;=0A 	}=0A@@ -526,7 +525,7 @@ static =
void pmc_setup_one_p4_counter(uns=0A 	}=0A =0A 	printk(KERN_ERR =
=0A-	       "oprofile: P4 event code 0x%lx no binding, stag %d ctr =
%d\n",=0A+	       "oprofile: P4 event code %#lx no binding, stag %d =
ctr %d\n",=0A 	       counter_config[ctr].event, stag, ctr);=0A }=0A =
=0A--- 2012-09-21.orig/xen/arch/x86/setup.c	2012-09-17 09:57:54.0000000=
00 +0200=0A+++ 2012-09-21/xen/arch/x86/setup.c	2012-09-21 11:01:12.0000000=
00 +0200=0A@@ -482,13 +482,13 @@ static void __init kexec_reserve_area(st=
=0A =0A     if ( !reserve_e820_ram(e820, kdump_start, kdump_start + =
kdump_size) )=0A     {=0A-        printk("Kdump: DISABLED (failed to =
reserve %luMB (%lukB) at 0x%lx)"=0A+        printk("Kdump: DISABLED =
(failed to reserve %luMB (%lukB) at %#lx)"=0A                "\n", =
kdump_size >> 20, kdump_size >> 10, kdump_start);=0A         kexec_crash_ar=
ea.start =3D kexec_crash_area.size =3D 0;=0A     }=0A     else=0A     =
{=0A-        printk("Kdump: %luMB (%lukB) at 0x%lx\n",=0A+        =
printk("Kdump: %luMB (%lukB) at %#lx\n",=0A                kdump_size >> =
20, kdump_size >> 10, kdump_start);=0A     }=0A }=0A--- 2012-09-21.orig/xen=
/arch/x86/tboot.c	2012-01-20 10:10:22.000000000 +0100=0A+++ =
2012-09-21/xen/arch/x86/tboot.c	2012-09-21 10:54:46.000000000 +0200=0A@@ =
-119,12 +119,12 @@ void __init tboot_probe(void)=0A     g_tboot_shared =3D =
tboot_shared;=0A     printk("TBOOT: found shared page at phys addr =
%lx:\n", p_tboot_shared);=0A     printk("  version: %d\n", tboot_shared->ve=
rsion);=0A-    printk("  log_addr: 0x%08x\n", tboot_shared->log_addr);=0A- =
   printk("  shutdown_entry: 0x%08x\n", tboot_shared->shutdown_entry);=0A- =
   printk("  tboot_base: 0x%08x\n", tboot_shared->tboot_base);=0A-    =
printk("  tboot_size: 0x%x\n", tboot_shared->tboot_size);=0A+    printk("  =
log_addr: %#x\n", tboot_shared->log_addr);=0A+    printk("  shutdown_entry:=
 %#x\n", tboot_shared->shutdown_entry);=0A+    printk("  tboot_base: =
%#x\n", tboot_shared->tboot_base);=0A+    printk("  tboot_size: %#x\n", =
tboot_shared->tboot_size);=0A     if ( tboot_shared->version >=3D 6 )=0A-  =
      printk("  flags: 0x%08x\n", tboot_shared->flags);=0A+        =
printk("  flags: %#x\n", tboot_shared->flags);=0A =0A     /* these will be =
needed by tboot_protect_mem_regions() and/or=0A        tboot_parse_dmar_tab=
le(), so get them now */=0A@@ -352,7 +352,7 @@ void tboot_shutdown(uint32_t=
 shutdown_ty=0A                            __PAGE_HYPERVISOR);=0A     if ( =
err !=3D 0 )=0A     {=0A-        printk("error (0x%x) mapping tboot pages =
(mfns) @ 0x%x, 0x%x\n", err,=0A+        printk("error (%#x) mapping tboot =
pages (mfns) @ %#x, %#x\n", err,=0A                map_base, map_size);=0A =
        return;=0A     }=0A--- 2012-09-21.orig/xen/arch/x86/time.c	=
2012-09-14 13:26:34.000000000 +0200=0A+++ 2012-09-21/xen/arch/x86/time.c	=
2012-09-21 10:54:46.000000000 +0200=0A@@ -1955,11 +1955,11 @@ static void =
dump_softtsc(unsigned char k=0A         printk("dom%u%s: mode=3D%d",d->doma=
in_id,=0A                 is_hvm_domain(d) ? "(hvm)" : "", d->arch.tsc_mode=
);=0A         if ( d->arch.vtsc_offset )=0A-            printk(",ofs=3D0x%"=
PRIx64"",d->arch.vtsc_offset);=0A+            printk(",ofs=3D%#"PRIx64, =
d->arch.vtsc_offset);=0A         if ( d->arch.tsc_khz )=0A-            =
printk(",khz=3D%"PRIu32"",d->arch.tsc_khz);=0A+            printk(",khz=3D%=
"PRIu32, d->arch.tsc_khz);=0A         if ( d->arch.incarnation )=0A-       =
     printk(",inc=3D%"PRIu32"",d->arch.incarnation);=0A+            =
printk(",inc=3D%"PRIu32, d->arch.incarnation);=0A         if ( !(d->arch.vt=
sc_kerncount | d->arch.vtsc_usercount) )=0A         {=0A             =
printk("\n");=0A--- 2012-09-21.orig/xen/arch/x86/xstate.c	2012-01-30 =
10:46:14.000000000 +0100=0A+++ 2012-09-21/xen/arch/x86/xstate.c	2012-09-21 =
10:54:46.000000000 +0200=0A@@ -163,7 +163,7 @@ void xstate_init(void)=0A   =
      xsave_cntxt_size =3D ebx;=0A         xfeature_mask =3D eax + =
((u64)edx << 32);=0A         xfeature_mask &=3D XCNTXT_MASK;=0A-        =
printk("%s: using cntxt_size: 0x%x and states: 0x%"PRIx64"\n",=0A+        =
printk("%s: using cntxt_size: %#x and states: %#"PRIx64"\n",=0A            =
 __func__, xsave_cntxt_size, xfeature_mask);=0A =0A         /* Check =
XSAVEOPT feature. */=0A--- 2012-09-21.orig/xen/common/gdbstub.c	2010-05-20 =
09:59:27.000000000 +0200=0A+++ 2012-09-21/xen/common/gdbstub.c	2012-09-21 =
10:54:46.000000000 +0200=0A@@ -263,7 +263,7 @@ gdb_write_to_packet_hex(unsi=
gned long x,=0A     case sizeof(u64):=0A         break;=0A     default:=0A-=
        dbg_printk("WARNING: %s x: 0x%lx int_size: %d\n",=0A+        =
dbg_printk("WARNING: %s x: %#lx int_size: %d\n",=0A                    =
__func__, x, int_size);=0A         break;=0A     }=0A--- 2012-09-21.orig/xe=
n/common/page_alloc.c	2012-09-14 13:26:34.000000000 +0200=0A+++ =
2012-09-21/xen/common/page_alloc.c	2012-09-21 10:54:46.000000000 =
+0200=0A@@ -367,7 +367,7 @@ static void __init setup_low_mem_virq(vo=0A    =
 low_mem_virq_th =3D low_mem_virq_orig =3D 1UL << order;=0A     low_mem_vir=
q_th_order =3D order;=0A =0A-    printk("Initial low memory virq threshold =
set at 0x%lx pages.\n",=0A+    printk("Initial low memory virq threshold =
set at %#lx pages.\n",=0A             low_mem_virq_th);=0A }=0A =0A--- =
2012-09-21.orig/xen/common/vsprintf.c	2012-02-10 11:25:54.000000000 =
+0100=0A+++ 2012-09-21/xen/common/vsprintf.c	2012-09-21 10:54:46.0000000=
00 +0200=0A@@ -171,10 +171,14 @@ static char *number(=0A         }=0A     =
}=0A     if (type & SPECIAL) {=0A-        if (base =3D=3D 16)=0A+        =
if (num =3D=3D 0)=0A+            type &=3D ~SPECIAL;=0A+        else if =
(base =3D=3D 16)=0A             size -=3D 2;=0A         else if (base =
=3D=3D 8)=0A             size--;=0A+        else=0A+            type &=3D =
~SPECIAL;=0A     }=0A     i =3D 0;=0A     if (num =3D=3D 0)=0A@@ -197,14 =
+201,10 @@ static char *number(=0A         ++buf;=0A     }=0A     if (type =
& SPECIAL) {=0A-        if (base=3D=3D8) {=0A-            if (buf <=3D =
end)=0A-                *buf =3D '0';=0A-            ++buf;=0A-        } =
else if (base=3D=3D16) {=0A-            if (buf <=3D end)=0A-              =
  *buf =3D '0';=0A-            ++buf;=0A+        if (buf <=3D end)=0A+     =
       *buf =3D '0';=0A+        ++buf;=0A+        if (base =3D=3D 16) {=0A =
            if (buf <=3D end)=0A                 *buf =3D digits[33];=0A   =
          ++buf;=0A--- 2012-09-21.orig/xen/common/xencomm.c	2012-01-24 =
10:11:51.000000000 +0100=0A+++ 2012-09-21/xen/common/xencomm.c	2012-09-21 =
10:54:46.000000000 +0200=0A@@ -58,7 +58,7 @@ xencomm_get_page(unsigned =
long paddr, st=0A          * is freed with decrease reservation hypercall =
at the same time.=0A          */=0A         gdprintk(XENLOG_WARNING,=0A-   =
              "bad page is passed. paddr 0x%lx maddr 0x%lx\n",=0A+         =
        "bad page is passed. paddr %#lx maddr %#lx\n",=0A                  =
paddr, maddr);=0A         return -EFAULT;=0A     }=0A@@ -117,7 +117,7 @@ =
xencomm_ctxt_init(const void *handle, st=0A     desc =3D xencomm_vaddr((uns=
igned long)handle, page);=0A     if ( desc->magic !=3D XENCOMM_MAGIC )=0A  =
   {=0A-        printk("%s: error: %p magic was 0x%x\n", __func__, desc, =
desc->magic);=0A+        printk("%s: error: %p magic was %#x\n", __func__, =
desc, desc->magic);=0A         put_page(page);=0A         return =
-EINVAL;=0A     }=0A--- 2012-09-21.orig/xen/drivers/acpi/numa.c	2012-09-14 =
13:26:34.000000000 +0200=0A+++ 2012-09-21/xen/drivers/acpi/numa.c	=
2012-09-21 10:54:46.000000000 +0200=0A@@ -78,8 +78,8 @@ void __init =
acpi_table_print_srat_entry(=0A 			if (srat_rev < =
2)=0A 				proximity_domain &=3D 0xff;=0A 			=
ACPI_DEBUG_PRINT((ACPI_DB_INFO,=0A-					  =
"SRAT Memory (%#016"PRIx64=0A-					  " length =
%#016"PRIx64")"=0A+					  "SRAT Memory =
(%#"PRIx64=0A+					  " length %#"PRIx64")"=0A =
					  " in proximity domain %d =
%s%s\n",=0A 					  p->base_address, =
p->length,=0A 					  proximity_domain,=0A@@ =
-108,7 +108,7 @@ void __init acpi_table_print_srat_entry(=0A 		=
break;=0A 	default:=0A 		printk(KERN_WARNING PREFIX=0A-		=
       "Found unsupported SRAT entry (type =3D 0x%x)\n",=0A+		   =
    "Found unsupported SRAT entry (type =3D %#x)\n",=0A 		   =
    header->type);=0A 		break;=0A 	}=0A--- 2012-09-21.orig/xen=
/drivers/acpi/tables.c	2012-09-21 10:32:44.000000000 +0200=0A+++ =
2012-09-21/xen/drivers/acpi/tables.c	2012-09-21 10:54:46.000000000 =
+0200=0A@@ -95,7 +95,7 @@ void __init acpi_table_print_madt_entry(=0A 		=
	if (p->inti_flags  &=0A 			    ~(ACPI_MADT_POL=
ARITY_MASK | ACPI_MADT_TRIGGER_MASK))=0A 				=
printk(KERN_INFO PREFIX=0A-				       "INT_SRC_OVR=
 unexpected reserved flags: 0x%x\n",=0A+				   =
    "INT_SRC_OVR unexpected reserved flags: %#x\n",=0A 				=
       p->inti_flags  &=0A 					~(ACPI_MADT=
_POLARITY_MASK | ACPI_MADT_TRIGGER_MASK));=0A =0A@@ -119,7 +119,7 @@ void =
__init acpi_table_print_madt_entry(=0A 			struct acpi_madt_lo=
cal_apic_nmi *p =3D=0A 			    (struct acpi_madt_local_apic_nm=
i *)header;=0A 			printk(KERN_INFO PREFIX=0A-			=
       "LAPIC_NMI (acpi_id[0x%02x] %s %s lint[0x%x])\n",=0A+			=
       "LAPIC_NMI (acpi_id[0x%02x] %s %s lint[%#x])\n",=0A 			=
       p->processor_id,=0A 			       mps_inti_flags_polar=
ity[p->inti_flags & ACPI_MADT_POLARITY_MASK	],=0A 			   =
    mps_inti_flags_trigger[(p->inti_flags & ACPI_MADT_TRIGGER_MASK) >> =
2],=0A@@ -137,7 +137,7 @@ void __init acpi_table_print_madt_entry(=0A 		=
	trigger =3D (p->inti_flags & ACPI_MADT_TRIGGER_MASK) >> 2;=0A =0A 	=
		printk(KERN_INFO PREFIX=0A-			       =
"X2APIC_NMI (uid[0x%02x] %s %s lint[0x%x])\n",=0A+			   =
    "X2APIC_NMI (uid[0x%02x] %s %s lint[%#x])\n",=0A 			   =
    p->uid,=0A 			       mps_inti_flags_polarity[polarity],=
=0A 			       mps_inti_flags_trigger[trigger],=0A@@ =
-160,7 +160,7 @@ void __init acpi_table_print_madt_entry(=0A 			=
struct acpi_madt_io_sapic *p =3D=0A 			    (struct =
acpi_madt_io_sapic *)header;=0A 			printk(KERN_INFO =
PREFIX=0A-			       "IOSAPIC (id[0x%x] address[%p] =
gsi_base[%d])\n",=0A+			       "IOSAPIC (id[%#x] address[%p=
] gsi_base[%d])\n",=0A 			       p->id, (void *)(unsigned =
long)p->address,=0A 			       p->global_irq_base);=0A 		=
}=0A@@ -182,7 +182,7 @@ void __init acpi_table_print_madt_entry(=0A 		=
	struct acpi_madt_interrupt_source *p =3D=0A 			   =
 (struct acpi_madt_interrupt_source *)header;=0A 			=
printk(KERN_INFO PREFIX=0A-			       "PLAT_INT_SRC (%s =
%s type[0x%x] id[0x%04x] eid[0x%x] iosapic_vector[0x%x] global_irq[0x%x]\n"=
,=0A+			       "PLAT_INT_SRC (%s %s type[%#x] id[0x%04x] =
eid[%#x] iosapic_vector[%#x] global_irq[%#x]\n",=0A 			   =
    mps_inti_flags_polarity[p->inti_flags & ACPI_MADT_POLARITY_MASK],=0A 	=
		       mps_inti_flags_trigger[(p->inti_flags & ACPI_MADT_TR=
IGGER_MASK) >> 2],=0A 			       p->type, p->id, p->eid, =
p->io_sapic_vector,=0A@@ -192,7 +192,7 @@ void __init acpi_table_print_madt=
_entry(=0A =0A 	default:=0A 		printk(KERN_WARNING PREFIX=0A-		=
       "Found unsupported MADT entry (type =3D 0x%x)\n",=0A+		   =
    "Found unsupported MADT entry (type =3D %#x)\n",=0A 		   =
    header->type);=0A 		break;=0A 	}=0A@@ -242,7 +242,7 @@ =
acpi_table_parse_entries(char *id,=0A 		    ((unsigned long)entry =
+ entry->length);=0A 	}=0A 	if (max_entries && count > max_entries) =
{=0A-		printk(KERN_WARNING PREFIX "[%4.4s:0x%02x] ignored %i =
entries of "=0A+		printk(KERN_WARNING PREFIX "[%4.4s:%#x] =
ignored %i entries of "=0A 		       "%i found\n", id, entry_id, =
count - max_entries, count);=0A 	}=0A =0A--- 2012-09-21.orig/xen/dri=
vers/acpi/utilities/utglobal.c	2011-03-11 10:13:55.000000000 +0100=0A+++ =
2012-09-21/xen/drivers/acpi/utilities/utglobal.c	2012-09-21 =
10:54:46.000000000 +0200=0A@@ -79,7 +79,7 @@ const char *__init acpi_format=
_exception=0A 		/* Exception code was not recognized */=0A =0A 		=
ACPI_ERROR((AE_INFO,=0A-			    "Unknown exception =
code: 0x%8.8X", status));=0A+			    "Unknown exception =
code: %#X", status));=0A =0A 		exception =3D "UNKNOWN_STATUS_CODE"=
;=0A 		dump_execution_state();=0A--- 2012-09-21.orig/xen/drivers/c=
pufreq/cpufreq.c	2012-09-14 13:26:34.000000000 +0200=0A+++ =
2012-09-21/xen/drivers/cpufreq/cpufreq.c	2012-09-21 10:54:46.0000000=
00 +0200=0A@@ -377,7 +377,7 @@ static void print_PSS(struct xen_process=0A =
    printk("\t_PSS: state_count=3D%d\n", count);=0A     for (i=3D0; =
i<count; i++){=0A         printk("\tState%d: %"PRId64"MHz %"PRId64"mW =
%"PRId64"us "=0A-               "%"PRId64"us 0x%"PRIx64" 0x%"PRIx64"\n",=0A=
+               "%"PRId64"us %#"PRIx64" %#"PRIx64"\n",=0A                =
i,=0A                ptr[i].core_frequency,=0A                ptr[i].power,=
=0A--- 2012-09-21.orig/xen/drivers/passthrough/amd/iommu_acpi.c	2011-12-14 =
10:11:38.000000000 +0100=0A+++ 2012-09-21/xen/drivers/passthrough/amd/iommu=
_acpi.c	2012-09-21 10:54:46.000000000 +0200=0A@@ -196,7 +196,7 @@ static =
int __init register_exclusion_ran=0A     iommu =3D find_iommu_for_device(se=
g, bdf);=0A     if ( !iommu )=0A     {=0A-        AMD_IOMMU_DEBUG("IVMD =
Error: No IOMMU for Dev_Id 0x%x!\n", bdf);=0A+        AMD_IOMMU_DEBUG("IVMD=
 Error: No IOMMU for Dev_Id %#x!\n", bdf);=0A         return -ENODEV;=0A   =
  }=0A     req =3D ivrs_mappings[bdf].dte_requestor_id;=0A@@ -278,7 +278,7 =
@@ static int __init parse_ivmd_device_sele=0A     bdf =3D ivmd_block->head=
er.device_id;=0A     if ( bdf >=3D ivrs_bdf_entries )=0A     {=0A-        =
AMD_IOMMU_DEBUG("IVMD Error: Invalid Dev_Id 0x%x\n", bdf);=0A+        =
AMD_IOMMU_DEBUG("IVMD Error: Invalid Dev_Id %#x\n", bdf);=0A         =
return -ENODEV;=0A     }=0A =0A@@ -296,7 +296,7 @@ static int __init =
parse_ivmd_device_rang=0A     if ( first_bdf >=3D ivrs_bdf_entries )=0A    =
 {=0A         AMD_IOMMU_DEBUG("IVMD Error: "=0A-                        =
"Invalid Range_First Dev_Id 0x%x\n", first_bdf);=0A+                       =
 "Invalid Range_First Dev_Id %#x\n", first_bdf);=0A         return =
-ENODEV;=0A     }=0A =0A@@ -304,7 +304,7 @@ static int __init parse_ivmd_de=
vice_rang=0A     if ( (last_bdf >=3D ivrs_bdf_entries) || (last_bdf <=3D =
first_bdf) )=0A     {=0A         AMD_IOMMU_DEBUG("IVMD Error: "=0A-        =
                "Invalid Range_Last Dev_Id 0x%x\n", last_bdf);=0A+         =
               "Invalid Range_Last Dev_Id %#x\n", last_bdf);=0A         =
return -ENODEV;=0A     }=0A =0A@@ -326,7 +326,7 @@ static int __init =
parse_ivmd_device_iomm=0A                                     ivmd_block->a=
ux_data);=0A     if ( !iommu )=0A     {=0A-        AMD_IOMMU_DEBUG("IVMD =
Error: No IOMMU for Dev_Id 0x%x  Cap 0x%x\n",=0A+        AMD_IOMMU_DEBUG("I=
VMD Error: No IOMMU for Dev_Id %#x Cap %#x\n",=0A                         =
ivmd_block->header.device_id, ivmd_block->aux_data);=0A         return =
-ENODEV;=0A     }=0A@@ -351,9 +351,9 @@ static int __init parse_ivmd_block(=
const=0A     base =3D start_addr & PAGE_MASK;=0A     limit =3D (start_addr =
+ mem_length - 1) & PAGE_MASK;=0A =0A-    AMD_IOMMU_DEBUG("IVMD Block: =
Type 0x%x\n",ivmd_block->header.type);=0A-    AMD_IOMMU_DEBUG(" Start_Addr_=
Phys 0x%lx\n", start_addr);=0A-    AMD_IOMMU_DEBUG(" Mem_Length 0x%lx\n", =
mem_length);=0A+    AMD_IOMMU_DEBUG("IVMD Block: Type %#x\n",ivmd_block->he=
ader.type);=0A+    AMD_IOMMU_DEBUG(" Start_Addr_Phys %#lx\n", start_addr);=
=0A+    AMD_IOMMU_DEBUG(" Mem_Length %#lx\n", mem_length);=0A =0A     if ( =
ivmd_block->header.flags & ACPI_IVMD_EXCLUSION_RANGE )=0A         iw =3D =
ir =3D IOMMU_CONTROL_ENABLED;=0A@@ -414,7 +414,7 @@ static u16 __init =
parse_ivhd_device_sele=0A     bdf =3D select->header.id;=0A     if ( bdf =
>=3D ivrs_bdf_entries )=0A     {=0A-        AMD_IOMMU_DEBUG("IVHD Error: =
Invalid Device_Entry Dev_Id 0x%x\n", bdf);=0A+        AMD_IOMMU_DEBUG("IVHD=
 Error: Invalid Device_Entry Dev_Id %#x\n", bdf);=0A         return 0;=0A  =
   }=0A =0A@@ -439,7 +439,7 @@ static u16 __init parse_ivhd_device_rang=0A =
    if ( range->end.header.type !=3D ACPI_IVRS_TYPE_END )=0A     {=0A      =
   AMD_IOMMU_DEBUG("IVHD Error: "=0A-                        "Invalid =
Range: End_Type 0x%x\n",=0A+                        "Invalid Range: =
End_Type %#x\n",=0A                         range->end.header.type);=0A    =
     return 0;=0A     }=0A@@ -448,7 +448,7 @@ static u16 __init parse_ivhd_=
device_rang=0A     if ( first_bdf >=3D ivrs_bdf_entries )=0A     {=0A      =
   AMD_IOMMU_DEBUG("IVHD Error: "=0A-                        "Invalid =
Range: First Dev_Id 0x%x\n", first_bdf);=0A+                        =
"Invalid Range: First Dev_Id %#x\n", first_bdf);=0A         return 0;=0A   =
  }=0A =0A@@ -456,11 +456,11 @@ static u16 __init parse_ivhd_device_rang=0A=
     if ( (last_bdf >=3D ivrs_bdf_entries) || (last_bdf <=3D first_bdf) =
)=0A     {=0A         AMD_IOMMU_DEBUG("IVHD Error: "=0A-                   =
     "Invalid Range: Last Dev_Id 0x%x\n", last_bdf);=0A+                   =
     "Invalid Range: Last Dev_Id %#x\n", last_bdf);=0A         return =
0;=0A     }=0A =0A-    AMD_IOMMU_DEBUG(" Dev_Id Range: 0x%x -> 0x%x\n", =
first_bdf, last_bdf);=0A+    AMD_IOMMU_DEBUG(" Dev_Id Range: %#x -> =
%#x\n", first_bdf, last_bdf);=0A =0A     for ( bdf =3D first_bdf; bdf <=3D =
last_bdf; bdf++ )=0A         add_ivrs_mapping_entry(bdf, bdf, range->start.=
header.data_setting,=0A@@ -485,18 +485,18 @@ static u16 __init parse_ivhd_d=
evice_alia=0A     bdf =3D alias->header.id;=0A     if ( bdf >=3D ivrs_bdf_e=
ntries )=0A     {=0A-        AMD_IOMMU_DEBUG("IVHD Error: Invalid =
Device_Entry Dev_Id 0x%x\n", bdf);=0A+        AMD_IOMMU_DEBUG("IVHD Error: =
Invalid Device_Entry Dev_Id %#x\n", bdf);=0A         return 0;=0A     }=0A =
=0A     alias_id =3D alias->used_id;=0A     if ( alias_id >=3D ivrs_bdf_ent=
ries )=0A     {=0A-        AMD_IOMMU_DEBUG("IVHD Error: Invalid Alias =
Dev_Id 0x%x\n", alias_id);=0A+        AMD_IOMMU_DEBUG("IVHD Error: Invalid =
Alias Dev_Id %#x\n", alias_id);=0A         return 0;=0A     }=0A =0A-    =
AMD_IOMMU_DEBUG(" Dev_Id Alias: 0x%x\n", alias_id);=0A+    AMD_IOMMU_DEBUG(=
" Dev_Id Alias: %#x\n", alias_id);=0A =0A     add_ivrs_mapping_entry(bdf, =
alias_id, alias->header.data_setting, iommu);=0A =0A@@ -520,7 +520,7 @@ =
static u16 __init parse_ivhd_device_alia=0A     if ( range->end.header.type=
 !=3D ACPI_IVRS_TYPE_END )=0A     {=0A         AMD_IOMMU_DEBUG("IVHD =
Error: "=0A-                        "Invalid Range: End_Type 0x%x\n",=0A+  =
                      "Invalid Range: End_Type %#x\n",=0A                  =
       range->end.header.type);=0A         return 0;=0A     }=0A@@ -529,7 =
+529,7 @@ static u16 __init parse_ivhd_device_alia=0A     if ( first_bdf =
>=3D ivrs_bdf_entries )=0A     {=0A         AMD_IOMMU_DEBUG("IVHD Error: =
"=0A-                        "Invalid Range: First Dev_Id 0x%x\n", =
first_bdf);=0A+                        "Invalid Range: First Dev_Id =
%#x\n", first_bdf);=0A         return 0;=0A     }=0A =0A@@ -537,19 +537,19 =
@@ static u16 __init parse_ivhd_device_alia=0A     if ( last_bdf >=3D =
ivrs_bdf_entries || last_bdf <=3D first_bdf )=0A     {=0A         =
AMD_IOMMU_DEBUG(=0A-            "IVHD Error: Invalid Range: Last Dev_Id =
0x%x\n", last_bdf);=0A+            "IVHD Error: Invalid Range: Last Dev_Id =
%#x\n", last_bdf);=0A         return 0;=0A     }=0A =0A     alias_id =3D =
range->alias.used_id;=0A     if ( alias_id >=3D ivrs_bdf_entries )=0A     =
{=0A-        AMD_IOMMU_DEBUG("IVHD Error: Invalid Alias Dev_Id 0x%x\n", =
alias_id);=0A+        AMD_IOMMU_DEBUG("IVHD Error: Invalid Alias Dev_Id =
%#x\n", alias_id);=0A         return 0;=0A     }=0A =0A-    AMD_IOMMU_DEBUG=
(" Dev_Id Range: 0x%x -> 0x%x\n", first_bdf, last_bdf);=0A-    AMD_IOMMU_DE=
BUG(" Dev_Id Alias: 0x%x\n", alias_id);=0A+    AMD_IOMMU_DEBUG(" Dev_Id =
Range: %#x -> %#x\n", first_bdf, last_bdf);=0A+    AMD_IOMMU_DEBUG(" =
Dev_Id Alias: %#x\n", alias_id);=0A =0A     for ( bdf =3D first_bdf; bdf =
<=3D last_bdf; bdf++ )=0A         add_ivrs_mapping_entry(bdf, alias_id, =
range->alias.header.data_setting,=0A@@ -574,7 +574,7 @@ static u16 __init =
parse_ivhd_device_exte=0A     bdf =3D ext->header.id;=0A     if ( bdf >=3D =
ivrs_bdf_entries )=0A     {=0A-        AMD_IOMMU_DEBUG("IVHD Error: =
Invalid Device_Entry Dev_Id 0x%x\n", bdf);=0A+        AMD_IOMMU_DEBUG("IVHD=
 Error: Invalid Device_Entry Dev_Id %#x\n", bdf);=0A         return 0;=0A  =
   }=0A =0A@@ -599,7 +599,7 @@ static u16 __init parse_ivhd_device_exte=0A =
    if ( range->end.header.type !=3D ACPI_IVRS_TYPE_END )=0A     {=0A      =
   AMD_IOMMU_DEBUG("IVHD Error: "=0A-                        "Invalid =
Range: End_Type 0x%x\n",=0A+                        "Invalid Range: =
End_Type %#x\n",=0A                         range->end.header.type);=0A    =
     return 0;=0A     }=0A@@ -608,7 +608,7 @@ static u16 __init parse_ivhd_=
device_exte=0A     if ( first_bdf >=3D ivrs_bdf_entries )=0A     {=0A      =
   AMD_IOMMU_DEBUG("IVHD Error: "=0A-                        "Invalid =
Range: First Dev_Id 0x%x\n", first_bdf);=0A+                        =
"Invalid Range: First Dev_Id %#x\n", first_bdf);=0A         return 0;=0A   =
  }=0A =0A@@ -616,11 +616,11 @@ static u16 __init parse_ivhd_device_exte=0A=
     if ( (last_bdf >=3D ivrs_bdf_entries) || (last_bdf <=3D first_bdf) =
)=0A     {=0A         AMD_IOMMU_DEBUG("IVHD Error: "=0A-                   =
     "Invalid Range: Last Dev_Id 0x%x\n", last_bdf);=0A+                   =
     "Invalid Range: Last Dev_Id %#x\n", last_bdf);=0A         return =
0;=0A     }=0A =0A-    AMD_IOMMU_DEBUG(" Dev_Id Range: 0x%x -> 0x%x\n",=0A+=
    AMD_IOMMU_DEBUG(" Dev_Id Range: %#x -> %#x\n",=0A                     =
first_bdf, last_bdf);=0A =0A     for ( bdf =3D first_bdf; bdf <=3D =
last_bdf; bdf++ )=0A@@ -646,7 +646,7 @@ static u16 __init parse_ivhd_device=
_spec=0A     bdf =3D special->used_id;=0A     if ( bdf >=3D ivrs_bdf_entrie=
s )=0A     {=0A-        AMD_IOMMU_DEBUG("IVHD Error: Invalid Device_Entry =
Dev_Id 0x%x\n", bdf);=0A+        AMD_IOMMU_DEBUG("IVHD Error: Invalid =
Device_Entry Dev_Id %#x\n", bdf);=0A         return 0;=0A     }=0A =0A@@ =
-673,7 +673,7 @@ static int __init parse_ivhd_block(const=0A               =
                      ivhd_block->capability_offset);=0A     if ( !iommu =
)=0A     {=0A-        AMD_IOMMU_DEBUG("IVHD Error: No IOMMU for Dev_Id =
0x%x  Cap 0x%x\n",=0A+        AMD_IOMMU_DEBUG("IVHD Error: No IOMMU for =
Dev_Id %#x Cap %#x\n",=0A                         ivhd_block->header.device=
_id,=0A                         ivhd_block->capability_offset);=0A         =
return -ENODEV;=0A@@ -687,9 +687,9 @@ static int __init parse_ivhd_block(co=
nst=0A         ivhd_device =3D (const void *)((const u8 *)ivhd_block + =
block_length);=0A =0A         AMD_IOMMU_DEBUG( "IVHD Device Entry:\n");=0A-=
        AMD_IOMMU_DEBUG( " Type 0x%x\n", ivhd_device->header.type);=0A-    =
    AMD_IOMMU_DEBUG( " Dev_Id 0x%x\n", ivhd_device->header.id);=0A-        =
AMD_IOMMU_DEBUG( " Flags 0x%x\n", ivhd_device->header.data_setting);=0A+   =
     AMD_IOMMU_DEBUG( " Type %#x\n", ivhd_device->header.type);=0A+        =
AMD_IOMMU_DEBUG( " Dev_Id %#x\n", ivhd_device->header.id);=0A+        =
AMD_IOMMU_DEBUG( " Flags %#x\n", ivhd_device->header.data_setting);=0A =0A =
        switch ( ivhd_device->header.type )=0A         {=0A@@ -788,9 =
+788,9 @@ static void __init dump_acpi_table_heade=0A         printk("%c", =
table->signature[i]);=0A     printk("\n");=0A =0A-    AMD_IOMMU_DEBUG(" =
Length 0x%x\n", table->length);=0A-    AMD_IOMMU_DEBUG(" Revision 0x%x\n", =
table->revision);=0A-    AMD_IOMMU_DEBUG(" CheckSum 0x%x\n", table->checksu=
m);=0A+    AMD_IOMMU_DEBUG(" Length %#x\n", table->length);=0A+    =
AMD_IOMMU_DEBUG(" Revision %#x\n", table->revision);=0A+    AMD_IOMMU_DEBUG=
(" CheckSum %#x\n", table->checksum);=0A =0A     AMD_IOMMU_DEBUG(" OEM_Id =
");=0A     for ( i =3D 0; i < ACPI_OEM_ID_SIZE; i++ )=0A@@ -802,14 +802,14 =
@@ static void __init dump_acpi_table_heade=0A         printk("%c", =
table->oem_table_id[i]);=0A     printk("\n");=0A =0A-    AMD_IOMMU_DEBUG(" =
OEM_Revision 0x%x\n", table->oem_revision);=0A+    AMD_IOMMU_DEBUG(" =
OEM_Revision %#x\n", table->oem_revision);=0A =0A     AMD_IOMMU_DEBUG(" =
Creator_Id ");=0A     for ( i =3D 0; i < ACPI_NAME_SIZE; i++ )=0A         =
printk("%c", table->asl_compiler_id[i]);=0A     printk("\n");=0A =0A-    =
AMD_IOMMU_DEBUG(" Creator_Revision 0x%x\n",=0A+    AMD_IOMMU_DEBUG(" =
Creator_Revision %#x\n",=0A                     table->asl_compiler_revisio=
n);=0A =0A }=0A@@ -832,15 +832,15 @@ static int __init parse_ivrs_table(str=
uc=0A         ivrs_block =3D (struct acpi_ivrs_header *)((u8 *)table + =
length);=0A =0A         AMD_IOMMU_DEBUG("IVRS Block:\n");=0A-        =
AMD_IOMMU_DEBUG(" Type 0x%x\n", ivrs_block->type);=0A-        AMD_IOMMU_DEB=
UG(" Flags 0x%x\n", ivrs_block->flags);=0A-        AMD_IOMMU_DEBUG(" =
Length 0x%x\n", ivrs_block->length);=0A-        AMD_IOMMU_DEBUG(" Dev_Id =
0x%x\n", ivrs_block->device_id);=0A+        AMD_IOMMU_DEBUG(" Type %#x\n", =
ivrs_block->type);=0A+        AMD_IOMMU_DEBUG(" Flags %#x\n", ivrs_block->f=
lags);=0A+        AMD_IOMMU_DEBUG(" Length %#x\n", ivrs_block->length);=0A+=
        AMD_IOMMU_DEBUG(" Dev_Id %#x\n", ivrs_block->device_id);=0A =0A    =
     if ( table->length < (length + ivrs_block->length) )=0A         {=0A  =
           AMD_IOMMU_DEBUG("IVRS Error: "=0A-                            =
"Table Length Exceeded: 0x%x -> 0x%lx\n",=0A+                            =
"Table Length Exceeded: %#x -> %#lx\n",=0A                             =
table->length,=0A                             (length + ivrs_block->length)=
);=0A             return -ENODEV;=0A@@ -867,7 +867,7 @@ static int __init =
detect_iommu_acpi(stru=0A         checksum +=3D raw_table[i];=0A     if ( =
checksum )=0A     {=0A-        AMD_IOMMU_DEBUG("IVRS Error: Invalid =
Checksum 0x%x\n", checksum);=0A+        AMD_IOMMU_DEBUG("IVRS Error: =
Invalid Checksum %#x\n", checksum);=0A         return -ENODEV;=0A     }=0A =
=0A--- 2012-09-21.orig/xen/drivers/passthrough/amd/iommu_init.c	2012-09-17 =
09:57:54.000000000 +0200=0A+++ 2012-09-21/xen/drivers/passthrough/amd/iommu=
_init.c	2012-09-21 10:54:46.000000000 +0200=0A@@ -616,8 +616,8 @@ static =
void parse_event_log_entry(struct=0A                                       =
 IOMMU_EVENT_FLAGS_SHIFT);=0A         addr=3D (u64*) (entry + 2);=0A       =
  printk(XENLOG_ERR "AMD-Vi: "=0A-               "%s: domain =3D %d, =
device id =3D 0x%04x, "=0A-               "fault address =3D 0x%"PRIx64", =
flags =3D 0x%03x\n",=0A+               "%s: domain =3D %d, device id =3D =
%#x, "=0A+               "fault address =3D %#"PRIx64", flags =3D =
%#x\n",=0A                event_str[code-1], domain_id, device_id, *addr, =
flags);=0A =0A         /* Tell the device to stop DMAing; we can't rely on =
the guest to=0A--- 2012-09-21.orig/xen/drivers/passthrough/amd/iommu_map.c	=
2012-09-14 13:26:34.000000000 +0200=0A+++ 2012-09-21/xen/drivers/passthroug=
h/amd/iommu_map.c	2012-09-21 10:54:46.000000000 +0200=0A@@ -795,7 =
+795,7 @@ void amd_iommu_share_p2m(struct domain *=0A =0A         /* When =
sharing p2m with iommu, paging mode =3D 4 */=0A         hd->paging_mode =
=3D IOMMU_PAGING_MODE_LEVEL_4;=0A-        AMD_IOMMU_DEBUG("Share p2m table =
with iommu: p2m table =3D 0x%lx\n",=0A+        AMD_IOMMU_DEBUG("Share p2m =
table with iommu: p2m table =3D %#lx\n",=0A                         =
mfn_x(pgd_mfn));=0A     }=0A }=0A--- 2012-09-21.orig/xen/drivers/passthroug=
h/amd/pci_amd_iommu.c	2012-09-14 13:26:34.000000000 +0200=0A+++ =
2012-09-21/xen/drivers/passthrough/amd/pci_amd_iommu.c	2012-09-21 =
10:54:46.000000000 +0200=0A@@ -121,8 +121,8 @@ static void amd_iommu_setup_=
domain_devic=0A =0A         amd_iommu_flush_device(iommu, req_id);=0A =0A- =
       AMD_IOMMU_DEBUG("Setup I/O page table: device id =3D 0x%04x, "=0A-  =
                      "root table =3D 0x%"PRIx64", "=0A+        AMD_IOMMU_D=
EBUG("Setup I/O page table: device id =3D %#x, "=0A+                       =
 "root table =3D %#"PRIx64", "=0A                         "domain =3D %d, =
paging mode =3D %d\n", req_id,=0A                         page_to_maddr(hd-=
>root_table),=0A                         hd->domain_id, hd->paging_mode);=
=0A@@ -314,7 +314,7 @@ void amd_iommu_disable_domain_device(str=0A =0A     =
    amd_iommu_flush_device(iommu, req_id);=0A =0A-        AMD_IOMMU_DEBUG("=
Disable: device id =3D 0x%04x, "=0A+        AMD_IOMMU_DEBUG("Disable: =
device id =3D %#x, "=0A                         "domain =3D %d, paging =
mode =3D %d\n",=0A                         req_id,  domain_hvm_iommu(domain=
)->domain_id,=0A                         domain_hvm_iommu(domain)->paging_m=
ode);=0A--- 2012-09-21.orig/xen/drivers/passthrough/vtd/dmar.c	2012-09-14 =
13:26:34.000000000 +0200=0A+++ 2012-09-21/xen/drivers/passthrough/vtd/dmar.=
c	2012-09-21 10:54:46.000000000 +0200=0A@@ -381,7 +381,7 @@ static =
int __init acpi_dmar_check_length=0A     if ( h->length >=3D min_len )=0A  =
       return 0;=0A     dprintk(XENLOG_ERR VTDPREFIX,=0A-            =
"Invalid ACPI DMAR entry length: 0x%x\n",=0A+            "Invalid ACPI =
DMAR entry length: %#x\n",=0A             h->length);=0A     return =
-EINVAL;=0A }=0A@@ -749,7 +749,7 @@ static int __init acpi_parse_dmar(struc=
t=0A             break;=0A         default:=0A             dprintk(XENLOG_W=
ARNING VTDPREFIX,=0A-                    "Ignore unknown DMAR structure =
type (0x%x)\n",=0A+                    "Ignore unknown DMAR structure type =
(%#x)\n",=0A                     entry_header->type);=0A             =
break;=0A         }=0A--- 2012-09-21.orig/xen/drivers/passthrough/vtd/intre=
map.c	2012-09-14 13:26:34.000000000 +0200=0A+++ 2012-09-21/xen/drivers/pa=
ssthrough/vtd/intremap.c	2012-09-21 10:54:46.000000000 +0200=0A@@ =
-135,7 +135,7 @@ int iommu_supports_eim(void)=0A         if ( !ioapic_to_dr=
hd(IO_APIC_ID(apic)) )=0A     {=0A             dprintk(XENLOG_WARNING =
VTDPREFIX,=0A-                    "There is not a DRHD for IOAPIC 0x%x =
(id: 0x%x)!\n",=0A+                    "There is not a DRHD for IOAPIC %#x =
(id: %#x)!\n",=0A                     apic, IO_APIC_ID(apic));=0A          =
   return 0;=0A     }=0A--- 2012-09-21.orig/xen/drivers/passthrough/vtd/iom=
mu.c	2012-09-17 09:57:55.000000000 +0200=0A+++ 2012-09-21/xen/drivers/pa=
ssthrough/vtd/iommu.c	2012-09-21 10:54:46.000000000 +0200=0A@@ -2035,7 =
+2035,7 @@ static int init_vtd_hw(void)=0A             {=0A                =
 iommu_intremap =3D 0;=0A                 dprintk(XENLOG_ERR VTDPREFIX,=0A-=
                    "ioapic_to_iommu: ioapic 0x%x (id: 0x%x) is NULL! =
"=0A+                    "ioapic_to_iommu: ioapic %#x (id: %#x) is NULL! =
"=0A                     "Will not try to enable Interrupt Remapping.\n",=
=0A                     apic, IO_APIC_ID(apic));=0A                 =
break;=0A--- 2012-09-21.orig/xen/drivers/passthrough/vtd/utils.c	=
2012-09-14 13:26:34.000000000 +0200=0A+++ 2012-09-21/xen/drivers/passthroug=
h/vtd/utils.c	2012-09-21 10:54:46.000000000 +0200=0A@@ -217,7 +217,7 @@ =
static void dump_iommu_info(unsigned cha=0A             struct iremap_entry=
 *iremap_entries =3D NULL;=0A             int print_cnt =3D 0;=0A =0A-     =
       printk("  Interrupt remapping table (nr_entry=3D0x%x. "=0A+         =
   printk("  Interrupt remapping table (nr_entry=3D%#x. "=0A               =
  "Only dump P=3D1 entries here):\n", nr_entry);=0A             printk("   =
    SVT  SQ   SID      DST  V  AVL DLM TM RH DM "=0A                    =
"FPD P\n");=0A--- 2012-09-21.orig/xen/drivers/video/vesa.c	2012-09-14 =
13:26:34.000000000 +0200=0A+++ 2012-09-21/xen/drivers/video/vesa.c	=
2012-09-21 10:54:46.000000000 +0200=0A@@ -111,7 +111,7 @@ void __init =
vesa_init(void)=0A =0A     vga_puts =3D vesa_redraw_puts;=0A =0A-    =
printk(XENLOG_INFO "vesafb: framebuffer at 0x%x, mapped to 0x%p, "=0A+    =
printk(XENLOG_INFO "vesafb: framebuffer at %#x, mapped to 0x%p, "=0A       =
     "using %uk, total %uk\n",=0A            vlfb_info.lfb_base, lfb,=0A   =
         vram_remap >> 10, vram_total >> 10);=0A
--=__Part6756664C.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

--=__Part6756664C.0__=--


From xen-devel-bounces@lists.xen.org Fri Sep 21 11:29:24 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Sep 2012 11:29: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 1TF1Py-0002MD-LS; Fri, 21 Sep 2012 11:29: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 1TF1Pv-0002M5-S3
	for xen-devel@lists.xen.org; Fri, 21 Sep 2012 11:29:08 +0000
Received: from [85.158.143.35:62233] by server-2.bemta-4.messagelabs.com id
	27/28-06610-38F4C505; Fri, 21 Sep 2012 11:29:07 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1348226911!15797013!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29280 invoked from network); 21 Sep 2012 11:28:31 -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;
	21 Sep 2012 11:28:31 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 21 Sep 2012 12:28:30 +0100
Message-Id: <505C6B7C020000780009CF08@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 21 Sep 2012 12:28:28 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part6756664C.0__="
Subject: [Xen-devel] [PATCH] printk: prefer %#x et at over 0x%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.

--=__Part6756664C.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Performance is not an issue with printk(), so let the function do
minimally more work and instead save a byte per affected format
specifier.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- 2012-09-21.orig/xen/arch/x86/acpi/boot.c	2012-09-20 08:44:38.0000000=
00 +0200
+++ 2012-09-21/xen/arch/x86/acpi/boot.c	2012-09-21 10:54:46.000000000 =
+0200
@@ -341,14 +341,14 @@ acpi_fadt_parse_sleep_info(struct acpi_t
 	}
=20
 	if (facs->length < 24) {
-		printk(KERN_ERR PREFIX "Invalid FACS table length: 0x%x",
+		printk(KERN_ERR PREFIX "Invalid FACS table length: %#x",
 			facs->length);
 		goto bad;
 	}
=20
 	if (facs->length < 64)
 		printk(KERN_WARNING PREFIX
-			"FACS is shorter than ACPI spec allow: 0x%x",
+			"FACS is shorter than ACPI spec allow: %#x",
 			facs->length);
=20
 	acpi_sinfo.wakeup_vector =3D facs_pa +=20
--- 2012-09-21.orig/xen/arch/x86/acpi/cpu_idle.c	2012-08-15 =
08:32:43.000000000 +0200
+++ 2012-09-21/xen/arch/x86/acpi/cpu_idle.c	2012-09-21 10:54:46.0000000=
00 +0200
@@ -978,11 +978,11 @@ static void print_cx_pminfo(uint32_t cpu
             return;
        =20
         printk("\tstates[%d]:\n", i);
-        printk("\t\treg.space_id =3D 0x%x\n", state.reg.space_id);
-        printk("\t\treg.bit_width =3D 0x%x\n", state.reg.bit_width);
-        printk("\t\treg.bit_offset =3D 0x%x\n", state.reg.bit_offset);
-        printk("\t\treg.access_size =3D 0x%x\n", state.reg.access_size);
-        printk("\t\treg.address =3D 0x%"PRIx64"\n", state.reg.address);
+        printk("\t\treg.space_id =3D %#x\n", state.reg.space_id);
+        printk("\t\treg.bit_width =3D %#x\n", state.reg.bit_width);
+        printk("\t\treg.bit_offset =3D %#x\n", state.reg.bit_offset);
+        printk("\t\treg.access_size =3D %#x\n", state.reg.access_size);
+        printk("\t\treg.address =3D %#"PRIx64"\n", state.reg.address);
         printk("\t\ttype    =3D %d\n", state.type);
         printk("\t\tlatency =3D %d\n", state.latency);
         printk("\t\tpower   =3D %d\n", state.power);
--- 2012-09-21.orig/xen/arch/x86/apic.c	2012-09-17 09:57:54.000000000 =
+0200
+++ 2012-09-21/xen/arch/x86/apic.c	2012-09-21 10:54:46.000000000 =
+0200
@@ -689,7 +689,7 @@ void __devinit setup_local_APIC(void)
         value =3D apic_read(APIC_ESR);
         if (value !=3D oldvalue)
             apic_printk(APIC_VERBOSE, "ESR value before enabling "
-                        "vector: 0x%08lx  after: 0x%08lx\n",
+                        "vector: %#lx  after: %#lx\n",
                         oldvalue, value);
     } else {
         if (esr_disable)   =20
@@ -1210,7 +1210,7 @@ static int __init calibrate_APIC_clock(v
     bus_cycle  =3D (u32) (1000000000000LL/bus_freq); /* in pico seconds =
*/
     bus_scale  =3D (1000*262144)/bus_cycle;
=20
-    apic_printk(APIC_VERBOSE, "..... bus_scale =3D 0x%08X\n", bus_scale);
+    apic_printk(APIC_VERBOSE, "..... bus_scale =3D %#x\n", bus_scale);
     /* reset APIC to zero timeout value */
     __setup_APIC_LVTT(0);
=20
--- 2012-09-21.orig/xen/arch/x86/cpu/mcheck/mce.c	2012-09-20 =
08:44:38.000000000 +0200
+++ 2012-09-21/xen/arch/x86/cpu/mcheck/mce.c	2012-09-21 10:54:46.0000000=
00 +0200
@@ -1147,7 +1147,7 @@ static int x86_mc_msrinject_verify(struc
         }
=20
         if (reason !=3D NULL) {
-            printk("HV MSR INJECT ERROR: MSR 0x%llx %s\n",
+            printk("HV MSR INJECT ERROR: MSR %#Lx %s\n",
                    (unsigned long long)mci->mcinj_msr[i].reg, reason);
             errs++;
         }
@@ -1191,8 +1191,7 @@ static void x86_mc_msrinject(void *data)
=20
     for (i =3D 0, msr =3D &mci->mcinj_msr[0];
          i < mci->mcinj_count; i++, msr++) {
-        printk("HV MSR INJECT (%s) target %u actual %u MSR 0x%llx "
-               "<-- 0x%llx\n",
+        printk("HV MSR INJECT (%s) target %u actual %u MSR %#Lx <-- =
%#Lx\n",
                intpose ?  "interpose" : "hardware",
                mci->mcinj_cpunr, smp_processor_id(),
                (unsigned long long)msr->reg,
--- 2012-09-21.orig/xen/arch/x86/cpu/mcheck/vmce.c	2012-08-08 =
08:20:09.000000000 +0200
+++ 2012-09-21/xen/arch/x86/cpu/mcheck/vmce.c	2012-09-21 10:54:46.0000000=
00 +0200
@@ -88,7 +88,7 @@ static int bank_mce_rdmsr(const struct v
     case MSR_IA32_MC0_CTL:
         /* stick all 1's to MCi_CTL */
         *val =3D ~0UL;
-        mce_printk(MCE_VERBOSE, "MCE: rdmsr MC%u_CTL 0x%"PRIx64"\n",
+        mce_printk(MCE_VERBOSE, "MCE: rdmsr MC%u_CTL %#"PRIx64"\n",
                    bank, *val);
         break;
     case MSR_IA32_MC0_STATUS:
@@ -102,7 +102,7 @@ static int bank_mce_rdmsr(const struct v
                 *val =3D entry->mci_status;
                 mce_printk(MCE_VERBOSE,
                            "MCE: rd MC%u_STATUS in vMCE# context "
-                           "value 0x%"PRIx64"\n", bank, *val);
+                           "value %#"PRIx64"\n", bank, *val);
             }
         }
         break;
@@ -116,7 +116,7 @@ static int bank_mce_rdmsr(const struct v
                 *val =3D entry->mci_addr;
                 mce_printk(MCE_VERBOSE,
                            "MCE: rdmsr MC%u_ADDR in vMCE# context "
-                           "0x%"PRIx64"\n", bank, *val);
+                           "%#"PRIx64"\n", bank, *val);
             }
         }
         break;
@@ -130,7 +130,7 @@ static int bank_mce_rdmsr(const struct v
                 *val =3D entry->mci_misc;
                 mce_printk(MCE_VERBOSE,
                            "MCE: rd MC%u_MISC in vMCE# context "
-                           "0x%"PRIx64"\n", bank, *val);
+                           "%#"PRIx64"\n", bank, *val);
             }
         }
         break;
@@ -171,18 +171,18 @@ int vmce_rdmsr(uint32_t msr, uint64_t *v
         *val =3D vmce->mcg_status;
         if (*val)
             mce_printk(MCE_VERBOSE,
-                       "MCE: rdmsr MCG_STATUS 0x%"PRIx64"\n", *val);
+                       "MCE: rdmsr MCG_STATUS %#"PRIx64"\n", *val);
         break;
     case MSR_IA32_MCG_CAP:
         *val =3D cur->arch.mcg_cap;
-        mce_printk(MCE_VERBOSE, "MCE: rdmsr MCG_CAP 0x%"PRIx64"\n",
+        mce_printk(MCE_VERBOSE, "MCE: rdmsr MCG_CAP %#"PRIx64"\n",
                    *val);
         break;
     case MSR_IA32_MCG_CTL:
         /* Stick all 1's when CTL support, and 0's when no CTL support */
         if ( cur->arch.mcg_cap & MCG_CTL_P )
             *val =3D ~0ULL;
-        mce_printk(MCE_VERBOSE, "MCE: rdmsr MCG_CTL 0x%"PRIx64"\n", =
*val);
+        mce_printk(MCE_VERBOSE, "MCE: rdmsr MCG_CTL %#"PRIx64"\n", *val);
         break;
     default:
         ret =3D mce_bank_msr(cur, msr) ? bank_mce_rdmsr(cur, msr, val) : =
0;
--- 2012-09-21.orig/xen/arch/x86/cpu/mtrr/generic.c	2011-04-11 =
08:33:59.000000000 +0200
+++ 2012-09-21/xen/arch/x86/cpu/mtrr/generic.c	2012-09-21 10:54:46.0000000=
00 +0200
@@ -410,7 +410,7 @@ int generic_validate_add_page(unsigned l
 	    boot_cpu_data.x86_model =3D=3D 1 &&
 	    boot_cpu_data.x86_mask <=3D 7) {
 		if (base & ((1 << (22 - PAGE_SHIFT)) - 1)) {
-			printk(KERN_WARNING "mtrr: base(0x%lx000) is not 4 =
MiB aligned\n", base);
+			printk(KERN_WARNING "mtrr: base(%#lx000) is not 4 =
MiB aligned\n", base);
 			return -EINVAL;
 		}
 		if (!(base + size < 0x70000 || base > 0x7003F) &&
@@ -427,7 +427,7 @@ int generic_validate_add_page(unsigned l
 	for (lbase =3D base; !(lbase & 1) && (last & 1);
 	     lbase =3D lbase >> 1, last =3D last >> 1) ;
 	if (lbase !=3D last) {
-		printk(KERN_WARNING "mtrr: base(0x%lx000) is not aligned =
on a size(0x%lx000) boundary\n",
+		printk(KERN_WARNING "mtrr: base(%#lx000) is not aligned on =
a size(%#lx000) boundary\n",
 		       base, size);
 		return -EINVAL;
 	}
--- 2012-09-21.orig/xen/arch/x86/cpu/mtrr/main.c	2012-09-21 =
10:32:44.000000000 +0200
+++ 2012-09-21/xen/arch/x86/cpu/mtrr/main.c	2012-09-21 10:54:46.0000000=
00 +0200
@@ -366,8 +366,8 @@ int mtrr_add_page(unsigned long base, un
 					continue;
 			}
 			printk(KERN_WARNING
-			       "mtrr: 0x%lx000,0x%lx000 overlaps existing"
-			       " 0x%lx000,0x%lx000\n", base, size, lbase,
+			       "mtrr: %#lx000,%#lx000 overlaps existing"
+			       " %#lx000,%#lx000\n", base, size, lbase,
 			       lsize);
 			goto out;
 		}
@@ -412,7 +412,7 @@ static int mtrr_check(unsigned long base
 		printk(KERN_WARNING
 			"mtrr: size and base must be multiples of 4 =
kiB\n");
 		printk(KERN_DEBUG
-			"mtrr: size: 0x%lx  base: 0x%lx\n", size, base);
+			"mtrr: size: %#lx  base: %#lx\n", size, base);
 		dump_stack();
 		return -1;
 	}
--- 2012-09-21.orig/xen/arch/x86/domain_build.c	2012-09-14 13:26:34.0000000=
00 +0200
+++ 2012-09-21/xen/arch/x86/domain_build.c	2012-09-21 10:55:47.0000000=
00 +0200
@@ -396,13 +396,13 @@ int __init construct_dom0(
     }
     if (elf_64bit(&elf) && machine =3D=3D EM_X86_64)
         compatible =3D 1;
-    printk(" Dom0 kernel: %s%s, %s, paddr 0x%" PRIx64 " -> 0x%" PRIx64 =
"\n",
+    printk(" Dom0 kernel: %s%s, %s, paddr %#" PRIx64 " -> %#" PRIx64 =
"\n",
            elf_64bit(&elf) ? "64-bit" : "32-bit",
            parms.pae       ? ", PAE"  : "",
            elf_msb(&elf)   ? "msb"    : "lsb",
            elf.pstart, elf.pend);
     if ( elf.bsd_symtab_pstart )
-        printk(" Dom0 symbol map 0x%" PRIx64 " -> 0x%" PRIx64 "\n",
+        printk(" Dom0 symbol map %#" PRIx64 " -> %#" PRIx64 "\n",
                elf.bsd_symtab_pstart, elf.bsd_symtab_pend);
=20
     if ( !compatible )
--- 2012-09-21.orig/xen/arch/x86/hvm/hvm.c	2012-09-20 08:44:38.0000000=
00 +0200
+++ 2012-09-21/xen/arch/x86/hvm/hvm.c	2012-09-21 10:54:46.000000000 =
+0200
@@ -1468,7 +1468,7 @@ int hvm_set_efer(uint64_t value)
     if ( !hvm_efer_valid(v->domain, value, efer_validbits) )
     {
         gdprintk(XENLOG_WARNING, "Trying to set reserved bit in "
-                 "EFER: 0x%"PRIx64"\n", value);
+                 "EFER: %#"PRIx64"\n", value);
         hvm_inject_hw_exception(TRAP_gp_fault, 0);
         return X86EMUL_EXCEPTION;
     }
@@ -4095,7 +4095,7 @@ long do_hvm_op(unsigned long op, XEN_GUE
             {
                 put_gfn(d, pfn);
                 gdprintk(XENLOG_WARNING,
-                         "type for pfn 0x%lx changed to grant while "
+                         "type for pfn %#lx changed to grant while "
                          "we were working?\n", pfn);
                 goto param_fail4;
             }
@@ -4106,7 +4106,7 @@ long do_hvm_op(unsigned long op, XEN_GUE
                 {
                     put_gfn(d, pfn);
                     gdprintk(XENLOG_WARNING,
-                             "type of pfn 0x%lx changed from %d to %d =
while "
+                             "type of pfn %#lx changed from %d to %d =
while "
                              "we were trying to change it to %d\n",
                              pfn, t, nt, memtype[a.hvmmem_type]);
                     goto param_fail4;
--- 2012-09-21.orig/xen/arch/x86/hvm/io.c	2012-07-30 09:49:58.0000000=
00 +0200
+++ 2012-09-21/xen/arch/x86/hvm/io.c	2012-09-21 10:54:46.000000000 =
+0200
@@ -393,7 +393,7 @@ int dpci_ioport_intercept(ioreq_t *p)
=20
     if ( !ioports_access_permitted(d, mport, mport + p->size - 1) )=20
     {
-        gdprintk(XENLOG_ERR, "Error: access to gport=3D0x%x denied!\n",
+        gdprintk(XENLOG_ERR, "Error: access to gport=3D%#x denied!\n",
                  (uint32_t)p->addr);
         return X86EMUL_UNHANDLEABLE;
     }
--- 2012-09-21.orig/xen/arch/x86/hvm/irq.c	2012-09-14 13:26:34.0000000=
00 +0200
+++ 2012-09-21/xen/arch/x86/hvm/irq.c	2012-09-21 10:54:46.000000000 =
+0200
@@ -488,7 +488,7 @@ static void irq_dump(struct domain *d)
            hvm_irq->pci_link_assert_count[1],
            hvm_irq->pci_link_assert_count[2],
            hvm_irq->pci_link_assert_count[3]);
-    printk("Callback via %i:0x%"PRIx32",%s asserted\n",=20
+    printk("Callback via %i:%#"PRIx32",%s asserted\n",
            hvm_irq->callback_via_type, hvm_irq->callback_via.gsi,=20
            hvm_irq->callback_via_asserted ? "" : " not");
 }
--- 2012-09-21.orig/xen/arch/x86/hvm/svm/intr.c	2012-01-20 10:10:22.0000000=
00 +0100
+++ 2012-09-21/xen/arch/x86/hvm/svm/intr.c	2012-09-21 10:54:46.0000000=
00 +0200
@@ -175,7 +175,7 @@ void svm_intr_assist(void)=20
                 /* Guest already enabled an interrupt window. */
                 return;
             default:
-                panic("%s: nestedsvm_vcpu_interrupt can't handle value =
0x%x\n",
+                panic("%s: nestedsvm_vcpu_interrupt can't handle value =
%#x\n",
                     __func__, rc);
             }
         }
--- 2012-09-21.orig/xen/arch/x86/hvm/svm/nestedsvm.c	2012-09-05 =
11:59:49.000000000 +0200
+++ 2012-09-21/xen/arch/x86/hvm/svm/nestedsvm.c	2012-09-21 10:54:46.0000000=
00 +0200
@@ -943,7 +943,7 @@ nsvm_vmcb_guest_intercepts_exitcode(stru
         break;
=20
     default:
-        gdprintk(XENLOG_ERR, "Illegal exitcode 0x%"PRIx64"\n", exitcode);
+        gdprintk(XENLOG_ERR, "Illegal exitcode %#"PRIx64"\n", exitcode);
         BUG();
         break;
     }
@@ -1235,7 +1235,7 @@ int nsvm_wrmsr(struct vcpu *v, unsigned=20
     case MSR_K8_VM_HSAVE_PA:
         if (!nestedsvm_vmcb_isvalid(v, msr_content)) {
             gdprintk(XENLOG_ERR,
-                "MSR_K8_VM_HSAVE_PA value invalid 0x%"PRIx64"\n", =
msr_content);
+                "MSR_K8_VM_HSAVE_PA value invalid %#"PRIx64"\n", =
msr_content);
             ret =3D -1; /* inject #GP */
             break;
         }
@@ -1244,7 +1244,7 @@ int nsvm_wrmsr(struct vcpu *v, unsigned=20
     case MSR_AMD64_TSC_RATIO:
         if ((msr_content & ~TSC_RATIO_RSVD_BITS) !=3D msr_content) {
             gdprintk(XENLOG_ERR,
-                "reserved bits set in MSR_AMD64_TSC_RATIO 0x%"PRIx64"\n",
+                "reserved bits set in MSR_AMD64_TSC_RATIO %#"PRIx64"\n",
                 msr_content);
             ret =3D -1; /* inject #GP */
             break;
--- 2012-09-21.orig/xen/arch/x86/hvm/svm/svm.c	2012-09-17 09:57:54.0000000=
00 +0200
+++ 2012-09-21/xen/arch/x86/hvm/svm/svm.c	2012-09-21 10:54:46.0000000=
00 +0200
@@ -241,7 +241,7 @@ static int svm_vmcb_restore(struct vcpu=20
          ((c->pending_type =3D=3D 1) || (c->pending_type > 6) ||
           (c->pending_reserved !=3D 0)) )
     {
-        gdprintk(XENLOG_ERR, "Invalid pending event 0x%"PRIx32".\n",
+        gdprintk(XENLOG_ERR, "Invalid pending event %#"PRIx32".\n",
                  c->pending_event);
         return -EINVAL;
     }
@@ -254,7 +254,7 @@ static int svm_vmcb_restore(struct vcpu=20
                                      NULL, P2M_ALLOC);
             if ( !page )
             {
-                gdprintk(XENLOG_ERR, "Invalid CR3 value=3D0x%"PRIx64"\n",
+                gdprintk(XENLOG_ERR, "Invalid CR3 value=3D%#"PRIx64"\n",
                          c->cr3);
                 return -EINVAL;
             }
@@ -289,7 +289,7 @@ static int svm_vmcb_restore(struct vcpu=20
=20
     if ( c->pending_valid )=20
     {
-        gdprintk(XENLOG_INFO, "Re-injecting 0x%"PRIx32", 0x%"PRIx32"\n",
+        gdprintk(XENLOG_INFO, "Re-injecting %#"PRIx32", %#"PRIx32"\n",
                  c->pending_event, c->error_code);
=20
         if ( hvm_event_needs_reinjection(c->pending_type, c->pending_vecto=
r) )
@@ -2398,8 +2398,8 @@ void svm_vmexit_handler(struct cpu_user_
=20
     default:
     exit_and_crash:
-        gdprintk(XENLOG_ERR, "unexpected VMEXIT: exit reason =3D =
0x%"PRIx64", "
-                 "exitinfo1 =3D %"PRIx64", exitinfo2 =3D %"PRIx64"\n",
+        gdprintk(XENLOG_ERR, "unexpected VMEXIT: exit reason =3D =
%#"PRIx64", "
+                 "exitinfo1 =3D %#"PRIx64", exitinfo2 =3D %#"PRIx64"\n",
                  exit_reason,=20
                  (u64)vmcb->exitinfo1, (u64)vmcb->exitinfo2);
         domain_crash(v->domain);
--- 2012-09-21.orig/xen/arch/x86/hvm/svm/svmdebug.c	2011-07-11 =
08:32:12.000000000 +0200
+++ 2012-09-21/xen/arch/x86/hvm/svm/svmdebug.c	2012-09-21 10:54:46.0000000=
00 +0200
@@ -32,33 +32,32 @@ static void svm_dump_sel(const char *nam
 void svm_vmcb_dump(const char *from, struct vmcb_struct *vmcb)
 {
     printk("Dumping guest's current state at %s...\n", from);
-    printk("Size of VMCB =3D %d, paddr =3D 0x%016lx, vaddr =3D %p\n",
+    printk("Size of VMCB =3D %d, paddr =3D %#lx, vaddr =3D %p\n",
            (int) sizeof(struct vmcb_struct), virt_to_maddr(vmcb), vmcb);
=20
-    printk("cr_intercepts =3D 0x%08x dr_intercepts =3D 0x%08x "
-           "exception_intercepts =3D 0x%08x\n",=20
+    printk("cr_intercepts =3D %#x dr_intercepts =3D %#x "
+           "exception_intercepts =3D %#x\n",
            vmcb->_cr_intercepts, vmcb->_dr_intercepts,=20
            vmcb->_exception_intercepts);
-    printk("general1_intercepts =3D 0x%08x general2_intercepts =3D =
0x%08x\n",=20
+    printk("general1_intercepts =3D %#x general2_intercepts =3D %#x\n",
            vmcb->_general1_intercepts, vmcb->_general2_intercepts);
-    printk("iopm_base_pa =3D 0x%016llx msrpm_base_pa =3D 0x%016llx =
tsc_offset =3D "
-            "0x%016llx\n",=20
+    printk("iopm_base_pa =3D %#Lx msrpm_base_pa =3D %#Lx tsc_offset =3D =
%#Lx\n",
            (unsigned long long)vmcb->_iopm_base_pa,
            (unsigned long long)vmcb->_msrpm_base_pa,
            (unsigned long long)vmcb->_tsc_offset);
-    printk("tlb_control =3D 0x%08x vintr =3D 0x%016llx interrupt_shadow =
=3D "
-            "0x%016llx\n", vmcb->tlb_control,
+    printk("tlb_control =3D %#x vintr =3D %#Lx interrupt_shadow =3D =
%#Lx\n",
+           vmcb->tlb_control,
            (unsigned long long)vmcb->_vintr.bytes,
            (unsigned long long)vmcb->interrupt_shadow);
-    printk("exitcode =3D 0x%016llx exitintinfo =3D 0x%016llx\n",=20
+    printk("exitcode =3D %#Lx exitintinfo =3D %#Lx\n",
            (unsigned long long)vmcb->exitcode,
            (unsigned long long)vmcb->exitintinfo.bytes);
-    printk("exitinfo1 =3D 0x%016llx exitinfo2 =3D 0x%016llx \n",
+    printk("exitinfo1 =3D %#Lx exitinfo2 =3D %#Lx \n",
            (unsigned long long)vmcb->exitinfo1,
            (unsigned long long)vmcb->exitinfo2);
-    printk("np_enable =3D 0x%016llx guest_asid =3D 0x%03x\n",=20
+    printk("np_enable =3D %Lx guest_asid =3D %#x\n",
            (unsigned long long)vmcb->_np_enable, vmcb->_guest_asid);
-    printk("cpl =3D %d efer =3D 0x%016llx star =3D 0x%016llx lstar =3D =
0x%016llx\n",=20
+    printk("cpl =3D %d efer =3D %#Lx star =3D %#Lx lstar =3D %#Lx\n",
            vmcb->_cpl, (unsigned long long)vmcb->_efer,
            (unsigned long long)vmcb->star, (unsigned long long)vmcb->lstar=
);
     printk("CR0 =3D 0x%016llx CR2 =3D 0x%016llx\n",
@@ -77,7 +76,7 @@ void svm_vmcb_dump(const char *from, str
     printk("KernGSBase =3D 0x%016llx PAT =3D 0x%016llx \n",=20
            (unsigned long long)vmcb->kerngsbase,
            (unsigned long long)vmcb->_g_pat);
-    printk("H_CR3 =3D 0x%016llx CleanBits =3D 0x%08x\n",
+    printk("H_CR3 =3D 0x%016llx CleanBits =3D %#x\n",
            (unsigned long long)vmcb->_h_cr3, vmcb->cleanbits.bytes);
=20
     /* print out all the selectors */
@@ -104,48 +103,48 @@ svm_vmcb_isvalid(const char *from, struc
     } else return 1;
=20
     if ((vmcb->_efer & EFER_SVME) =3D=3D 0) {
-        PRINTF("EFER: SVME bit not set (0x%"PRIx64")\n", vmcb->_efer);
+        PRINTF("EFER: SVME bit not set (%#"PRIx64")\n", vmcb->_efer);
     }
=20
     if ((vmcb->_cr0 & X86_CR0_CD) =3D=3D 0 && (vmcb->_cr0 & X86_CR0_NW) =
!=3D 0) {
-        PRINTF("CR0: CD bit is zero and NW bit set (0x%"PRIx64")\n",
+        PRINTF("CR0: CD bit is zero and NW bit set (%#"PRIx64")\n",
                 vmcb->_cr0);
     }
=20
     if ((vmcb->_cr0 >> 32U) !=3D 0) {
-        PRINTF("CR0: bits [63:32] are not zero (0x%"PRIx64")\n",
+        PRINTF("CR0: bits [63:32] are not zero (%#"PRIx64")\n",
                 vmcb->_cr0);
     }
=20
     if ((vmcb->_cr3 & 0x7) !=3D 0) {
-        PRINTF("CR3: MBZ bits are set (0x%"PRIx64")\n", vmcb->_cr3);
+        PRINTF("CR3: MBZ bits are set (%#"PRIx64")\n", vmcb->_cr3);
     }
     if ((vmcb->_efer & EFER_LMA) && (vmcb->_cr3 & 0xfe) !=3D 0) {
-        PRINTF("CR3: MBZ bits are set (0x%"PRIx64")\n", vmcb->_cr3);
+        PRINTF("CR3: MBZ bits are set (%#"PRIx64")\n", vmcb->_cr3);
     }
=20
     if ((vmcb->_cr4 >> 19U) !=3D 0) {
-        PRINTF("CR4: bits [63:19] are not zero (0x%"PRIx64")\n",
+        PRINTF("CR4: bits [63:19] are not zero (%#"PRIx64")\n",
                 vmcb->_cr4);
     }
=20
     if (((vmcb->_cr4 >> 11U) & 0x7fU) !=3D 0) {
-        PRINTF("CR4: bits [17:11] are not zero (0x%"PRIx64")\n",
+        PRINTF("CR4: bits [17:11] are not zero (%#"PRIx64")\n",
                 vmcb->_cr4);
     }
=20
     if ((vmcb->_dr6 >> 32U) !=3D 0) {
-        PRINTF("DR6: bits [63:32] are not zero (0x%"PRIx64")\n",
+        PRINTF("DR6: bits [63:32] are not zero (%#"PRIx64")\n",
                 vmcb->_dr6);
     }
=20
     if ((vmcb->_dr7 >> 32U) !=3D 0) {
-        PRINTF("DR7: bits [63:32] are not zero (0x%"PRIx64")\n",
+        PRINTF("DR7: bits [63:32] are not zero (%#"PRIx64")\n",
                 vmcb->_dr7);
     }
=20
     if ((vmcb->_efer >> 15U) !=3D 0) {
-        PRINTF("EFER: bits [63:15] are not zero (0x%"PRIx64")\n",
+        PRINTF("EFER: bits [63:15] are not zero (%#"PRIx64")\n",
                 vmcb->_efer);
     }
=20
@@ -168,12 +167,12 @@ svm_vmcb_isvalid(const char *from, struc
     }
=20
     if ((vmcb->_general2_intercepts & GENERAL2_INTERCEPT_VMRUN) =3D=3D 0) =
{
-        PRINTF("GENERAL2_INTERCEPT: VMRUN intercept bit is clear =
(0x%"PRIx32")\n",
+        PRINTF("GENERAL2_INTERCEPT: VMRUN intercept bit is clear =
(%#"PRIx32")\n",
             vmcb->_general2_intercepts);
     }
=20
     if (vmcb->eventinj.fields.resvd1 !=3D 0) {
-        PRINTF("eventinj: MBZ bits are set (0x%"PRIx64")\n",
+        PRINTF("eventinj: MBZ bits are set (%#"PRIx64")\n",
                 vmcb->eventinj.bytes);
     }
=20
--- 2012-09-21.orig/xen/arch/x86/hvm/vlapic.c	2012-09-20 08:44:38.0000000=
00 +0200
+++ 2012-09-21/xen/arch/x86/hvm/vlapic.c	2012-09-21 10:54:46.0000000=
00 +0200
@@ -172,7 +172,7 @@ static uint32_t vlapic_get_ppr(struct vl
         ppr =3D isrv & 0xf0;
=20
     HVM_DBG_LOG(DBG_LEVEL_VLAPIC_INTERRUPT,
-                "vlapic %p, ppr 0x%x, isr 0x%x, isrv 0x%x",
+                "vlapic %p, ppr %#x, isr %#x, isrv %#x",
                 vlapic, ppr, isr, isrv);
=20
     return ppr;
@@ -215,8 +215,8 @@ bool_t vlapic_match_dest(
     struct vlapic *target, struct vlapic *source,
     int short_hand, uint8_t dest, uint8_t dest_mode)
 {
-    HVM_DBG_LOG(DBG_LEVEL_VLAPIC, "target %p, source %p, dest 0x%x, "
-                "dest_mode 0x%x, short_hand 0x%x",
+    HVM_DBG_LOG(DBG_LEVEL_VLAPIC, "target %p, source %p, dest %#x, "
+                "dest_mode %#x, short_hand %#x",
                 target, source, dest, dest_mode, short_hand);
=20
     switch ( short_hand )
@@ -562,20 +562,20 @@ static int vlapic_read(
         break;
=20
     default:
-        gdprintk(XENLOG_ERR, "Local APIC read with len=3D0x%lx, "
+        gdprintk(XENLOG_ERR, "Local APIC read with len=3D%#lx, "
                  "should be 4 instead.\n", len);
         goto exit_and_crash;
     }
=20
-    HVM_DBG_LOG(DBG_LEVEL_VLAPIC, "offset 0x%x with length 0x%lx, "
-                "and the result is 0x%lx", offset, len, result);
+    HVM_DBG_LOG(DBG_LEVEL_VLAPIC, "offset %#x with length %#lx, "
+                "and the result is %#lx", offset, len, result);
=20
  out:
     *pval =3D result;
     return X86EMUL_OKAY;
=20
  unaligned_exit_and_crash:
-    gdprintk(XENLOG_ERR, "Unaligned LAPIC read len=3D0x%lx at offset=3D0x%=
x.\n",
+    gdprintk(XENLOG_ERR, "Unaligned LAPIC read len=3D%#lx at offset=3D%#x.=
\n",
              len, offset);
  exit_and_crash:
     domain_crash(v->domain);
@@ -759,7 +759,7 @@ static int vlapic_reg_write(struct vcpu=20
=20
     case APIC_TDCR:
         vlapic_set_tdcr(vlapic, val & 0xb);
-        HVM_DBG_LOG(DBG_LEVEL_VLAPIC_TIMER, "timer divisor is 0x%x",
+        HVM_DBG_LOG(DBG_LEVEL_VLAPIC_TIMER, "timer divisor is %#x",
                     vlapic->hw.timer_divisor);
         break;
=20
@@ -768,7 +768,7 @@ static int vlapic_reg_write(struct vcpu=20
     }
     if (rc =3D=3D X86EMUL_UNHANDLEABLE)
         gdprintk(XENLOG_DEBUG,
-                "Local APIC Write wrong to register 0x%x\n", offset);
+                "Local APIC Write wrong to register %#x\n", offset);
     return rc;
 }
=20
@@ -781,7 +781,7 @@ static int vlapic_write(struct vcpu *v,=20
=20
     if ( offset !=3D 0xb0 )
         HVM_DBG_LOG(DBG_LEVEL_VLAPIC,
-                    "offset 0x%x with length 0x%lx, and value is 0x%lx",
+                    "offset %#x with length %#lx, and value is %#lx",
                     offset, len, val);
=20
     /*
@@ -827,7 +827,7 @@ static int vlapic_write(struct vcpu *v,=20
     return vlapic_reg_write(v, offset, val);
=20
  unaligned_exit_and_crash:
-    gdprintk(XENLOG_ERR, "Unaligned LAPIC write len=3D0x%lx at offset=3D0x=
%x.\n",
+    gdprintk(XENLOG_ERR, "Unaligned LAPIC write len=3D%#lx at offset=3D%#x=
.\n",
              len, offset);
  exit_and_crash:
     domain_crash(v->domain);
--- 2012-09-21.orig/xen/arch/x86/hvm/vmx/vmcs.c	2012-09-20 08:44:38.0000000=
00 +0200
+++ 2012-09-21/xen/arch/x86/hvm/vmx/vmcs.c	2012-09-21 10:54:46.0000000=
00 +0200
@@ -121,7 +121,7 @@ static u32 adjust_vmx_controls(
 static bool_t cap_check(const char *name, u32 expected, u32 saw)
 {
     if ( saw !=3D expected )
-        printk("VMX %s: saw 0x%08x expected 0x%08x\n", name, saw, =
expected);
+        printk("VMX %s: saw %#x expected %#x\n", name, saw, expected);
     return saw !=3D expected;
 }
=20
--- 2012-09-21.orig/xen/arch/x86/hvm/vmx/vmx.c	2012-09-20 08:44:38.0000000=
00 +0200
+++ 2012-09-21/xen/arch/x86/hvm/vmx/vmx.c	2012-09-21 11:01:46.0000000=
00 +0200
@@ -210,7 +210,7 @@ long_mode_do_msr_read(unsigned int msr,=20
         return HNDL_unhandled;
     }
=20
-    HVM_DBG_LOG(DBG_LEVEL_0, "msr 0x%x content 0x%"PRIx64, msr, *msr_conte=
nt);
+    HVM_DBG_LOG(DBG_LEVEL_0, "msr %#x content %#"PRIx64, msr, *msr_content=
);
=20
     return HNDL_done;
 }
@@ -222,7 +222,7 @@ long_mode_do_msr_write(unsigned int msr,
     struct vmx_msr_state *guest_msr_state =3D &v->arch.hvm_vmx.msr_state;
     struct vmx_msr_state *host_msr_state =3D &this_cpu(host_msr_state);
=20
-    HVM_DBG_LOG(DBG_LEVEL_0, "msr 0x%x content 0x%"PRIx64, msr, msr_conten=
t);
+    HVM_DBG_LOG(DBG_LEVEL_0, "msr %#x content %#"PRIx64, msr, msr_content)=
;
=20
     switch ( msr )
     {
@@ -466,7 +466,7 @@ static int vmx_restore_cr0_cr3(
                                      NULL, P2M_ALLOC);
             if ( !page )
             {
-                gdprintk(XENLOG_ERR, "Invalid CR3 value=3D0x%lx\n", cr3);
+                gdprintk(XENLOG_ERR, "Invalid CR3 value=3D%#lx\n", cr3);
                 return -EINVAL;
             }
         }
@@ -492,7 +492,7 @@ static int vmx_vmcs_restore(struct vcpu=20
          ((c->pending_type =3D=3D 1) || (c->pending_type > 6) ||
           (c->pending_reserved !=3D 0)) )
     {
-        gdprintk(XENLOG_ERR, "Invalid pending event 0x%"PRIx32".\n",
+        gdprintk(XENLOG_ERR, "Invalid pending event %#"PRIx32".\n",
                  c->pending_event);
         return -EINVAL;
     }
@@ -524,7 +524,7 @@ static int vmx_vmcs_restore(struct vcpu=20
=20
     if ( c->pending_valid )
     {
-        gdprintk(XENLOG_INFO, "Re-injecting 0x%"PRIx32", 0x%"PRIx32"\n",
+        gdprintk(XENLOG_INFO, "Re-injecting %#"PRIx32", %#"PRIx32"\n",
                  c->pending_event, c->error_code);
=20
         if ( hvm_event_needs_reinjection(c->pending_type, c->pending_vecto=
r) )
@@ -1789,7 +1789,7 @@ static int is_last_branch_msr(u32 ecx)
=20
 static int vmx_msr_read_intercept(unsigned int msr, uint64_t *msr_content)=

 {
-    HVM_DBG_LOG(DBG_LEVEL_1, "ecx=3D%x", msr);
+    HVM_DBG_LOG(DBG_LEVEL_1, "ecx=3D%#x", msr);
=20
     switch ( msr )
     {
@@ -1854,7 +1854,7 @@ static int vmx_msr_read_intercept(unsign
     }
=20
 done:
-    HVM_DBG_LOG(DBG_LEVEL_1, "returns: ecx=3D%x, msr_value=3D0x%"PRIx64,
+    HVM_DBG_LOG(DBG_LEVEL_1, "returns: ecx=3D%#x, msr_value=3D%#"PRIx64,
                 msr, *msr_content);
     return X86EMUL_OKAY;
=20
@@ -1927,8 +1927,7 @@ static int vmx_msr_write_intercept(unsig
 {
     struct vcpu *v =3D current;
=20
-    HVM_DBG_LOG(DBG_LEVEL_1, "ecx=3D%x, msr_value=3D0x%"PRIx64,
-                msr, msr_content);
+    HVM_DBG_LOG(DBG_LEVEL_1, "ecx=3D%#x, msr_value=3D%#"PRIx64, msr, =
msr_content);
=20
     switch ( msr )
     {
@@ -2107,7 +2106,7 @@ static void vmx_failed_vmentry(unsigned=20
     unsigned long exit_qualification =3D __vmread(EXIT_QUALIFICATION);
     struct vcpu *curr =3D current;
=20
-    printk("Failed vm entry (exit reason 0x%x) ", exit_reason);
+    printk("Failed vm entry (exit reason %#x) ", exit_reason);
     switch ( failed_vmentry_reason )
     {
     case EXIT_REASON_INVALID_GUEST_STATE:
--- 2012-09-21.orig/xen/arch/x86/io_apic.c	2012-09-21 10:32:44.0000000=
00 +0200
+++ 2012-09-21/xen/arch/x86/io_apic.c	2012-09-21 10:54:46.000000000 =
+0200
@@ -2204,7 +2204,7 @@ int io_apic_set_pci_routing (int ioapic,
     entry.vector =3D vector;
=20
     apic_printk(APIC_DEBUG, KERN_DEBUG "IOAPIC[%d]: Set PCI routing entry =
"
-		"(%d-%d -> 0x%x -> IRQ %d Mode:%i Active:%i)\n", ioapic,
+		"(%d-%d -> %#x -> IRQ %d Mode:%i Active:%i)\n", ioapic,
 		mp_ioapics[ioapic].mpc_apicid, pin, entry.vector, irq,
 		edge_level, active_high_low);
=20
--- 2012-09-21.orig/xen/arch/x86/microcode_amd.c	2012-02-10 =
11:25:54.000000000 +0100
+++ 2012-09-21/xen/arch/x86/microcode_amd.c	2012-09-21 10:54:46.0000000=
00 +0200
@@ -88,7 +88,7 @@ static int collect_cpu_info(int cpu, str
=20
     rdmsrl(MSR_AMD_PATCHLEVEL, csig->rev);
=20
-    printk(KERN_DEBUG "microcode: collect_cpu_info: patch_id=3D0x%x\n",
+    printk(KERN_DEBUG "microcode: collect_cpu_info: patch_id=3D%#x\n",
            csig->rev);
=20
     return 0;
@@ -132,7 +132,7 @@ static int microcode_fits(const struct m
         return 0;
=20
     printk(KERN_DEBUG "microcode: CPU%d found a matching microcode "
-           "update with version 0x%x (current=3D0x%x)\n",
+           "update with version %#x (current=3D%#x)\n",
            cpu, mc_header->patch_id, uci->cpu_sig.rev);
=20
     return 1;
@@ -169,7 +169,7 @@ static int apply_microcode(int cpu)
     if ( rev !=3D hdr->patch_id )
     {
         printk(KERN_ERR "microcode: CPU%d update from revision "
-               "0x%x to 0x%x failed\n", cpu, hdr->patch_id, rev);
+               "%#x to %#x failed\n", cpu, hdr->patch_id, rev);
         return -EIO;
     }
=20
--- 2012-09-21.orig/xen/arch/x86/microcode_intel.c	2011-12-12 =
09:01:34.000000000 +0100
+++ 2012-09-21/xen/arch/x86/microcode_intel.c	2012-09-21 10:54:46.0000000=
00 +0200
@@ -122,7 +122,7 @@ static int collect_cpu_info(int cpu_num,
     /* get the current revision from MSR 0x8B */
     rdmsrl(MSR_IA32_UCODE_REV, msr_content);
     csig->rev =3D (uint32_t)(msr_content >> 32);
-    pr_debug("microcode: collect_cpu_info : sig=3D0x%x, pf=3D0x%x, =
rev=3D0x%x\n",
+    pr_debug("microcode: collect_cpu_info : sig=3D%#x, pf=3D%#x, =
rev=3D%#x\n",
              csig->sig, csig->pf, csig->rev);
=20
     return 0;
@@ -264,7 +264,7 @@ static int get_matching_microcode(const=20
     if ( uci->mc.mc_intel && uci->mc.mc_intel->hdr.rev >=3D mc_header->rev=
 )
         return 0;
     pr_debug("microcode: CPU%d found a matching microcode update with"
-             " version 0x%x (current=3D0x%x)\n",
+             " version %#x (current=3D%#x)\n",
              cpu, mc_header->rev, uci->cpu_sig.rev);
     new_mc =3D xmalloc_bytes(total_size);
     if ( new_mc =3D=3D NULL )
@@ -311,11 +311,11 @@ static int apply_microcode(int cpu)
     if ( val[1] !=3D uci->mc.mc_intel->hdr.rev )
     {
         printk(KERN_ERR "microcode: CPU%d update from revision "
-               "0x%x to 0x%x failed\n", cpu_num, uci->cpu_sig.rev, =
val[1]);
+               "%#x to %#x failed\n", cpu_num, uci->cpu_sig.rev, val[1]);
         return -EIO;
     }
     printk(KERN_INFO "microcode: CPU%d updated from revision "
-           "0x%x to 0x%x, date =3D %04x-%02x-%02x \n",
+           "%#x to %#x, date =3D %04x-%02x-%02x \n",
            cpu_num, uci->cpu_sig.rev, val[1],
            uci->mc.mc_intel->hdr.date & 0xffff,
            uci->mc.mc_intel->hdr.date >> 24,
--- 2012-09-21.orig/xen/arch/x86/mm.c	2012-09-14 13:26:34.000000000 =
+0200
+++ 2012-09-21/xen/arch/x86/mm.c	2012-09-21 10:54:46.000000000 =
+0200
@@ -3102,7 +3102,7 @@ long do_mmuext_op(
         }
=20
         default:
-            MEM_LOG("Invalid extended pt command 0x%x", op.cmd);
+            MEM_LOG("Invalid extended pt command %#x", op.cmd);
             rc =3D -ENOSYS;
             okay =3D 0;
             break;
--- 2012-09-21.orig/xen/arch/x86/mm/hap/nested_hap.c	2012-08-08 =
08:20:09.000000000 +0200
+++ 2012-09-21/xen/arch/x86/mm/hap/nested_hap.c	2012-09-21 10:54:46.0000000=
00 +0200
@@ -129,7 +129,7 @@ nestedhap_fix_p2m(struct vcpu *v, struct
=20
     if (rv =3D=3D 0) {
         gdprintk(XENLOG_ERR,
-		"failed to set entry for 0x%"PRIx64" -> 0x%"PRIx64"\n",
+		"failed to set entry for %#"PRIx64" -> %#"PRIx64"\n",
 		L2_gpa, L0_gpa);
         BUG();
     }
--- 2012-09-21.orig/xen/arch/x86/mm/p2m-pt.c	2012-09-14 13:26:34.0000000=
00 +0200
+++ 2012-09-21/xen/arch/x86/mm/p2m-pt.c	2012-09-21 10:54:46.000000000 =
+0200
@@ -110,8 +110,8 @@ p2m_find_entry(void *table, unsigned lon
     index =3D *gfn_remainder >> shift;
     if ( index >=3D max )
     {
-        P2M_DEBUG("gfn=3D0x%lx out of range "
-                  "(gfn_remainder=3D0x%lx shift=3D%d index=3D0x%x =
max=3D0x%x)\n",
+        P2M_DEBUG("gfn=3D%#lx out of range "
+                  "(gfn_remainder=3D%#lx shift=3D%d index=3D%#x max=3D%#x)=
\n",
                   gfn, *gfn_remainder, shift, index, max);
         return NULL;
     }
--- 2012-09-21.orig/xen/arch/x86/mm/shadow/common.c	2012-09-14 =
13:26:34.000000000 +0200
+++ 2012-09-21/xen/arch/x86/mm/shadow/common.c	2012-09-21 10:57:38.0000000=
00 +0200
@@ -872,7 +872,7 @@ static int sh_skip_sync(struct vcpu *v,=20
         return SHADOW_INTERNAL_NAME(sh_safe_not_to_sync, 3)(v, gl1mfn);
     else if ( pg->shadow_flags & SHF_L1_64 )
         return SHADOW_INTERNAL_NAME(sh_safe_not_to_sync, 4)(v, gl1mfn);
-    SHADOW_ERROR("gmfn 0x%lx was OOS but not shadowed as an l1.\n",=20
+    SHADOW_ERROR("gmfn %#lx was OOS but not shadowed as an l1.\n",
                  mfn_x(gl1mfn));
     BUG();
     return 0; /* BUG() is no longer __attribute__((noreturn)). */
@@ -2596,8 +2596,8 @@ void sh_remove_shadows(struct vcpu *v, m
     smfn =3D shadow_hash_lookup(v, mfn_x(gmfn), t);                       =
\
     if ( unlikely(!mfn_valid(smfn)) )                                   \
     {                                                                   \
-        SHADOW_ERROR(": gmfn %#lx has flags 0x%"PRIx32                  \
-                     " but no type-0x%"PRIx32" shadow\n",               \
+        SHADOW_ERROR(": gmfn %#lx has flags %#"PRIx32                   \
+                     " but no type-%#"PRIx32" shadow\n",                \
                      mfn_x(gmfn), (uint32_t)pg->shadow_flags, t);       \
         break;                                                          \
     }                                                                   \
--- 2012-09-21.orig/xen/arch/x86/mm/shadow/multi.c	2012-09-14 =
13:26:34.000000000 +0200
+++ 2012-09-21/xen/arch/x86/mm/shadow/multi.c	2012-09-21 10:54:46.0000000=
00 +0200
@@ -2171,7 +2171,7 @@ static int validate_gl4e(struct vcpu *v,
             // attempt by the guest to write to a xen reserved slot
             //
             SHADOW_PRINTK("%s out-of-range update "
-                           "sl4mfn=3D%05lx index=3D0x%x val=3D%" =
SH_PRI_pte "\n",
+                           "sl4mfn=3D%05lx index=3D%#x val=3D%" SH_PRI_pte=
 "\n",
                            __func__, mfn_x(sl4mfn), shadow_index, =
new_sl4e.l4);
             if ( shadow_l4e_get_flags(new_sl4e) & _PAGE_PRESENT )
             {
--- 2012-09-21.orig/xen/arch/x86/mpparse.c	2012-04-20 09:49:25.0000000=
00 +0200
+++ 2012-09-21/xen/arch/x86/mpparse.c	2012-09-21 10:54:46.000000000 =
+0200
@@ -216,7 +216,7 @@ static void __init MP_ioapic_info (struc
 	if (!(m->mpc_flags & MPC_APIC_USABLE))
 		return;
=20
-	printk(KERN_INFO "I/O APIC #%d Version %d at 0x%X.\n",
+	printk(KERN_INFO "I/O APIC #%d Version %d at %#x.\n",
 		m->mpc_apicid, m->mpc_apicver, m->mpc_apicaddr);
 	if (nr_ioapics >=3D MAX_IO_APICS) {
 		printk(KERN_CRIT "Max # of I/O APICs (%d) exceeded (found =
%d).\n",
@@ -278,7 +278,7 @@ static int __init smp_read_mpc(struct mp
 	unsigned char *mpt=3D((unsigned char *)mpc)+count;
=20
 	if (memcmp(mpc->mpc_signature,MPC_SIGNATURE,4)) {
-		printk(KERN_ERR "SMP mptable: bad signature [0x%x]!\n",
+		printk(KERN_ERR "SMP mptable: bad signature [%#x]!\n",
 			*(u32 *)mpc->mpc_signature);
 		return 0;
 	}
@@ -305,7 +305,7 @@ static int __init smp_read_mpc(struct mp
=20
 	mps_oem_check(mpc, oem, str);
=20
-	printk("APIC at: 0x%X\n",mpc->mpc_lapic);
+	printk("APIC at: %#x\n", mpc->mpc_lapic);
=20
 	/*=20
 	 * Save the local APIC address (it might be non-default) -- but =
only
@@ -881,7 +881,7 @@ void __init mp_register_ioapic (
 	mp_ioapic_routing[idx].gsi_end =3D gsi_base +=20
 		io_apic_get_redir_entries(idx);
=20
-	printk("IOAPIC[%d]: apic_id %d, version %d, address 0x%x, "
+	printk("IOAPIC[%d]: apic_id %d, version %d, address %#x, "
 		"GSI %d-%d\n", idx, mp_ioapics[idx].mpc_apicid,=20
 		mp_ioapics[idx].mpc_apicver, mp_ioapics[idx].mpc_apicaddr,
 		mp_ioapic_routing[idx].gsi_base,
--- 2012-09-21.orig/xen/arch/x86/nmi.c	2012-08-08 08:20:09.000000000 =
+0200
+++ 2012-09-21/xen/arch/x86/nmi.c	2012-09-21 10:54:46.000000000 =
+0200
@@ -245,7 +245,7 @@ static inline void write_watchdog_counte
=20
     do_div(count, nmi_hz);
     if(descr)
-        Dprintk("setting %s to -0x%"PRIx64"\n", descr, count);
+        Dprintk("setting %s to -%#"PRIx64"\n", descr, count);
     wrmsrl(nmi_perfctr_msr, 0 - count);
 }
=20
--- 2012-09-21.orig/xen/arch/x86/oprofile/op_model_athlon.c	2012-09-14 =
13:26:34.000000000 +0200
+++ 2012-09-21/xen/arch/x86/oprofile/op_model_athlon.c	2012-09-21 =
10:54:46.000000000 +0200
@@ -478,7 +478,7 @@ static int __init init_ibs_nmi(void)
 					if (value !=3D (IBSCTL_LVTOFFSETVAL=
 |
 						APIC_EILVT_LVTOFF_IBS)) {
 						printk("Xenoprofile: =
Failed to setup IBS LVT offset, "
-							"IBSCTL =3D =
%#08x\n", value);
+							"IBSCTL =3D =
%#x\n", value);
 						return 1;
 					}
 					nodes++;
@@ -523,7 +523,7 @@ void __init ibs_init(void)
 		return;
 	}
=20
-	printk("Xenoprofile: AMD IBS detected (0x%08x)\n",
+	printk("Xenoprofile: AMD IBS detected (%#x)\n",
 		(unsigned)ibs_caps);
 }
=20
--- 2012-09-21.orig/xen/arch/x86/oprofile/op_model_p4.c	2012-02-10 =
11:25:54.000000000 +0100
+++ 2012-09-21/xen/arch/x86/oprofile/op_model_p4.c	2012-09-21 =
10:54:46.000000000 +0200
@@ -485,8 +485,7 @@ static void pmc_setup_one_p4_counter(uns
 =09
 	/* find our event binding structure. */
 	if (counter_config[ctr].event <=3D 0 || counter_config[ctr].event =
> NUM_EVENTS) {
-		printk(KERN_ERR=20
-		       "oprofile: P4 event code 0x%lx out of range\n",=20
+		printk(KERN_ERR "oprofile: P4 event code %#lx out of =
range\n",
 		       counter_config[ctr].event);
 		return;
 	}
@@ -526,7 +525,7 @@ static void pmc_setup_one_p4_counter(uns
 	}
=20
 	printk(KERN_ERR=20
-	       "oprofile: P4 event code 0x%lx no binding, stag %d ctr =
%d\n",
+	       "oprofile: P4 event code %#lx no binding, stag %d ctr =
%d\n",
 	       counter_config[ctr].event, stag, ctr);
 }
=20
--- 2012-09-21.orig/xen/arch/x86/setup.c	2012-09-17 09:57:54.0000000=
00 +0200
+++ 2012-09-21/xen/arch/x86/setup.c	2012-09-21 11:01:12.000000000 =
+0200
@@ -482,13 +482,13 @@ static void __init kexec_reserve_area(st
=20
     if ( !reserve_e820_ram(e820, kdump_start, kdump_start + kdump_size) )
     {
-        printk("Kdump: DISABLED (failed to reserve %luMB (%lukB) at =
0x%lx)"
+        printk("Kdump: DISABLED (failed to reserve %luMB (%lukB) at =
%#lx)"
                "\n", kdump_size >> 20, kdump_size >> 10, kdump_start);
         kexec_crash_area.start =3D kexec_crash_area.size =3D 0;
     }
     else
     {
-        printk("Kdump: %luMB (%lukB) at 0x%lx\n",
+        printk("Kdump: %luMB (%lukB) at %#lx\n",
                kdump_size >> 20, kdump_size >> 10, kdump_start);
     }
 }
--- 2012-09-21.orig/xen/arch/x86/tboot.c	2012-01-20 10:10:22.0000000=
00 +0100
+++ 2012-09-21/xen/arch/x86/tboot.c	2012-09-21 10:54:46.000000000 =
+0200
@@ -119,12 +119,12 @@ void __init tboot_probe(void)
     g_tboot_shared =3D tboot_shared;
     printk("TBOOT: found shared page at phys addr %lx:\n", p_tboot_shared)=
;
     printk("  version: %d\n", tboot_shared->version);
-    printk("  log_addr: 0x%08x\n", tboot_shared->log_addr);
-    printk("  shutdown_entry: 0x%08x\n", tboot_shared->shutdown_entry);
-    printk("  tboot_base: 0x%08x\n", tboot_shared->tboot_base);
-    printk("  tboot_size: 0x%x\n", tboot_shared->tboot_size);
+    printk("  log_addr: %#x\n", tboot_shared->log_addr);
+    printk("  shutdown_entry: %#x\n", tboot_shared->shutdown_entry);
+    printk("  tboot_base: %#x\n", tboot_shared->tboot_base);
+    printk("  tboot_size: %#x\n", tboot_shared->tboot_size);
     if ( tboot_shared->version >=3D 6 )
-        printk("  flags: 0x%08x\n", tboot_shared->flags);
+        printk("  flags: %#x\n", tboot_shared->flags);
=20
     /* these will be needed by tboot_protect_mem_regions() and/or
        tboot_parse_dmar_table(), so get them now */
@@ -352,7 +352,7 @@ void tboot_shutdown(uint32_t shutdown_ty
                            __PAGE_HYPERVISOR);
     if ( err !=3D 0 )
     {
-        printk("error (0x%x) mapping tboot pages (mfns) @ 0x%x, 0x%x\n", =
err,
+        printk("error (%#x) mapping tboot pages (mfns) @ %#x, %#x\n", =
err,
                map_base, map_size);
         return;
     }
--- 2012-09-21.orig/xen/arch/x86/time.c	2012-09-14 13:26:34.000000000 =
+0200
+++ 2012-09-21/xen/arch/x86/time.c	2012-09-21 10:54:46.000000000 =
+0200
@@ -1955,11 +1955,11 @@ static void dump_softtsc(unsigned char k
         printk("dom%u%s: mode=3D%d",d->domain_id,
                 is_hvm_domain(d) ? "(hvm)" : "", d->arch.tsc_mode);
         if ( d->arch.vtsc_offset )
-            printk(",ofs=3D0x%"PRIx64"",d->arch.vtsc_offset);
+            printk(",ofs=3D%#"PRIx64, d->arch.vtsc_offset);
         if ( d->arch.tsc_khz )
-            printk(",khz=3D%"PRIu32"",d->arch.tsc_khz);
+            printk(",khz=3D%"PRIu32, d->arch.tsc_khz);
         if ( d->arch.incarnation )
-            printk(",inc=3D%"PRIu32"",d->arch.incarnation);
+            printk(",inc=3D%"PRIu32, d->arch.incarnation);
         if ( !(d->arch.vtsc_kerncount | d->arch.vtsc_usercount) )
         {
             printk("\n");
--- 2012-09-21.orig/xen/arch/x86/xstate.c	2012-01-30 10:46:14.0000000=
00 +0100
+++ 2012-09-21/xen/arch/x86/xstate.c	2012-09-21 10:54:46.000000000 =
+0200
@@ -163,7 +163,7 @@ void xstate_init(void)
         xsave_cntxt_size =3D ebx;
         xfeature_mask =3D eax + ((u64)edx << 32);
         xfeature_mask &=3D XCNTXT_MASK;
-        printk("%s: using cntxt_size: 0x%x and states: 0x%"PRIx64"\n",
+        printk("%s: using cntxt_size: %#x and states: %#"PRIx64"\n",
             __func__, xsave_cntxt_size, xfeature_mask);
=20
         /* Check XSAVEOPT feature. */
--- 2012-09-21.orig/xen/common/gdbstub.c	2010-05-20 09:59:27.0000000=
00 +0200
+++ 2012-09-21/xen/common/gdbstub.c	2012-09-21 10:54:46.000000000 =
+0200
@@ -263,7 +263,7 @@ gdb_write_to_packet_hex(unsigned long x,
     case sizeof(u64):
         break;
     default:
-        dbg_printk("WARNING: %s x: 0x%lx int_size: %d\n",
+        dbg_printk("WARNING: %s x: %#lx int_size: %d\n",
                    __func__, x, int_size);
         break;
     }
--- 2012-09-21.orig/xen/common/page_alloc.c	2012-09-14 13:26:34.0000000=
00 +0200
+++ 2012-09-21/xen/common/page_alloc.c	2012-09-21 10:54:46.000000000 =
+0200
@@ -367,7 +367,7 @@ static void __init setup_low_mem_virq(vo
     low_mem_virq_th =3D low_mem_virq_orig =3D 1UL << order;
     low_mem_virq_th_order =3D order;
=20
-    printk("Initial low memory virq threshold set at 0x%lx pages.\n",
+    printk("Initial low memory virq threshold set at %#lx pages.\n",
             low_mem_virq_th);
 }
=20
--- 2012-09-21.orig/xen/common/vsprintf.c	2012-02-10 11:25:54.0000000=
00 +0100
+++ 2012-09-21/xen/common/vsprintf.c	2012-09-21 10:54:46.000000000 =
+0200
@@ -171,10 +171,14 @@ static char *number(
         }
     }
     if (type & SPECIAL) {
-        if (base =3D=3D 16)
+        if (num =3D=3D 0)
+            type &=3D ~SPECIAL;
+        else if (base =3D=3D 16)
             size -=3D 2;
         else if (base =3D=3D 8)
             size--;
+        else
+            type &=3D ~SPECIAL;
     }
     i =3D 0;
     if (num =3D=3D 0)
@@ -197,14 +201,10 @@ static char *number(
         ++buf;
     }
     if (type & SPECIAL) {
-        if (base=3D=3D8) {
-            if (buf <=3D end)
-                *buf =3D '0';
-            ++buf;
-        } else if (base=3D=3D16) {
-            if (buf <=3D end)
-                *buf =3D '0';
-            ++buf;
+        if (buf <=3D end)
+            *buf =3D '0';
+        ++buf;
+        if (base =3D=3D 16) {
             if (buf <=3D end)
                 *buf =3D digits[33];
             ++buf;
--- 2012-09-21.orig/xen/common/xencomm.c	2012-01-24 10:11:51.0000000=
00 +0100
+++ 2012-09-21/xen/common/xencomm.c	2012-09-21 10:54:46.000000000 =
+0200
@@ -58,7 +58,7 @@ xencomm_get_page(unsigned long paddr, st
          * is freed with decrease reservation hypercall at the same time.
          */
         gdprintk(XENLOG_WARNING,
-                 "bad page is passed. paddr 0x%lx maddr 0x%lx\n",
+                 "bad page is passed. paddr %#lx maddr %#lx\n",
                  paddr, maddr);
         return -EFAULT;
     }
@@ -117,7 +117,7 @@ xencomm_ctxt_init(const void *handle, st
     desc =3D xencomm_vaddr((unsigned long)handle, page);
     if ( desc->magic !=3D XENCOMM_MAGIC )
     {
-        printk("%s: error: %p magic was 0x%x\n", __func__, desc, =
desc->magic);
+        printk("%s: error: %p magic was %#x\n", __func__, desc, desc->magi=
c);
         put_page(page);
         return -EINVAL;
     }
--- 2012-09-21.orig/xen/drivers/acpi/numa.c	2012-09-14 13:26:34.0000000=
00 +0200
+++ 2012-09-21/xen/drivers/acpi/numa.c	2012-09-21 10:54:46.000000000 =
+0200
@@ -78,8 +78,8 @@ void __init acpi_table_print_srat_entry(
 			if (srat_rev < 2)
 				proximity_domain &=3D 0xff;
 			ACPI_DEBUG_PRINT((ACPI_DB_INFO,
-					  "SRAT Memory (%#016"PRIx64
-					  " length %#016"PRIx64")"
+					  "SRAT Memory (%#"PRIx64
+					  " length %#"PRIx64")"
 					  " in proximity domain %d =
%s%s\n",
 					  p->base_address, p->length,
 					  proximity_domain,
@@ -108,7 +108,7 @@ void __init acpi_table_print_srat_entry(
 		break;
 	default:
 		printk(KERN_WARNING PREFIX
-		       "Found unsupported SRAT entry (type =3D 0x%x)\n",
+		       "Found unsupported SRAT entry (type =3D %#x)\n",
 		       header->type);
 		break;
 	}
--- 2012-09-21.orig/xen/drivers/acpi/tables.c	2012-09-21 10:32:44.0000000=
00 +0200
+++ 2012-09-21/xen/drivers/acpi/tables.c	2012-09-21 10:54:46.0000000=
00 +0200
@@ -95,7 +95,7 @@ void __init acpi_table_print_madt_entry(
 			if (p->inti_flags  &
 			    ~(ACPI_MADT_POLARITY_MASK | ACPI_MADT_TRIGGER_M=
ASK))
 				printk(KERN_INFO PREFIX
-				       "INT_SRC_OVR unexpected reserved =
flags: 0x%x\n",
+				       "INT_SRC_OVR unexpected reserved =
flags: %#x\n",
 				       p->inti_flags  &
 					~(ACPI_MADT_POLARITY_MASK | =
ACPI_MADT_TRIGGER_MASK));
=20
@@ -119,7 +119,7 @@ void __init acpi_table_print_madt_entry(
 			struct acpi_madt_local_apic_nmi *p =3D
 			    (struct acpi_madt_local_apic_nmi *)header;
 			printk(KERN_INFO PREFIX
-			       "LAPIC_NMI (acpi_id[0x%02x] %s %s lint[0x%x]=
)\n",
+			       "LAPIC_NMI (acpi_id[0x%02x] %s %s lint[%#x])=
\n",
 			       p->processor_id,
 			       mps_inti_flags_polarity[p->inti_flags & =
ACPI_MADT_POLARITY_MASK	],
 			       mps_inti_flags_trigger[(p->inti_flags & =
ACPI_MADT_TRIGGER_MASK) >> 2],
@@ -137,7 +137,7 @@ void __init acpi_table_print_madt_entry(
 			trigger =3D (p->inti_flags & ACPI_MADT_TRIGGER_MASK=
) >> 2;
=20
 			printk(KERN_INFO PREFIX
-			       "X2APIC_NMI (uid[0x%02x] %s %s lint[0x%x])\n=
",
+			       "X2APIC_NMI (uid[0x%02x] %s %s lint[%#x])\n"=
,
 			       p->uid,
 			       mps_inti_flags_polarity[polarity],
 			       mps_inti_flags_trigger[trigger],
@@ -160,7 +160,7 @@ void __init acpi_table_print_madt_entry(
 			struct acpi_madt_io_sapic *p =3D
 			    (struct acpi_madt_io_sapic *)header;
 			printk(KERN_INFO PREFIX
-			       "IOSAPIC (id[0x%x] address[%p] gsi_base[%d])=
\n",
+			       "IOSAPIC (id[%#x] address[%p] gsi_base[%d])\=
n",
 			       p->id, (void *)(unsigned long)p->address,
 			       p->global_irq_base);
 		}
@@ -182,7 +182,7 @@ void __init acpi_table_print_madt_entry(
 			struct acpi_madt_interrupt_source *p =3D
 			    (struct acpi_madt_interrupt_source *)header;
 			printk(KERN_INFO PREFIX
-			       "PLAT_INT_SRC (%s %s type[0x%x] id[0x%04x] =
eid[0x%x] iosapic_vector[0x%x] global_irq[0x%x]\n",
+			       "PLAT_INT_SRC (%s %s type[%#x] id[0x%04x] =
eid[%#x] iosapic_vector[%#x] global_irq[%#x]\n",
 			       mps_inti_flags_polarity[p->inti_flags & =
ACPI_MADT_POLARITY_MASK],
 			       mps_inti_flags_trigger[(p->inti_flags & =
ACPI_MADT_TRIGGER_MASK) >> 2],
 			       p->type, p->id, p->eid, p->io_sapic_vector,
@@ -192,7 +192,7 @@ void __init acpi_table_print_madt_entry(
=20
 	default:
 		printk(KERN_WARNING PREFIX
-		       "Found unsupported MADT entry (type =3D 0x%x)\n",
+		       "Found unsupported MADT entry (type =3D %#x)\n",
 		       header->type);
 		break;
 	}
@@ -242,7 +242,7 @@ acpi_table_parse_entries(char *id,
 		    ((unsigned long)entry + entry->length);
 	}
 	if (max_entries && count > max_entries) {
-		printk(KERN_WARNING PREFIX "[%4.4s:0x%02x] ignored %i =
entries of "
+		printk(KERN_WARNING PREFIX "[%4.4s:%#x] ignored %i entries =
of "
 		       "%i found\n", id, entry_id, count - max_entries, =
count);
 	}
=20
--- 2012-09-21.orig/xen/drivers/acpi/utilities/utglobal.c	2011-03-11 =
10:13:55.000000000 +0100
+++ 2012-09-21/xen/drivers/acpi/utilities/utglobal.c	2012-09-21 =
10:54:46.000000000 +0200
@@ -79,7 +79,7 @@ const char *__init acpi_format_exception
 		/* Exception code was not recognized */
=20
 		ACPI_ERROR((AE_INFO,
-			    "Unknown exception code: 0x%8.8X", status));
+			    "Unknown exception code: %#X", status));
=20
 		exception =3D "UNKNOWN_STATUS_CODE";
 		dump_execution_state();
--- 2012-09-21.orig/xen/drivers/cpufreq/cpufreq.c	2012-09-14 =
13:26:34.000000000 +0200
+++ 2012-09-21/xen/drivers/cpufreq/cpufreq.c	2012-09-21 10:54:46.0000000=
00 +0200
@@ -377,7 +377,7 @@ static void print_PSS(struct xen_process
     printk("\t_PSS: state_count=3D%d\n", count);
     for (i=3D0; i<count; i++){
         printk("\tState%d: %"PRId64"MHz %"PRId64"mW %"PRId64"us "
-               "%"PRId64"us 0x%"PRIx64" 0x%"PRIx64"\n",
+               "%"PRId64"us %#"PRIx64" %#"PRIx64"\n",
                i,
                ptr[i].core_frequency,
                ptr[i].power,
--- 2012-09-21.orig/xen/drivers/passthrough/amd/iommu_acpi.c	2011-12-14 =
10:11:38.000000000 +0100
+++ 2012-09-21/xen/drivers/passthrough/amd/iommu_acpi.c	2012-09-21 =
10:54:46.000000000 +0200
@@ -196,7 +196,7 @@ static int __init register_exclusion_ran
     iommu =3D find_iommu_for_device(seg, bdf);
     if ( !iommu )
     {
-        AMD_IOMMU_DEBUG("IVMD Error: No IOMMU for Dev_Id 0x%x!\n", bdf);
+        AMD_IOMMU_DEBUG("IVMD Error: No IOMMU for Dev_Id %#x!\n", bdf);
         return -ENODEV;
     }
     req =3D ivrs_mappings[bdf].dte_requestor_id;
@@ -278,7 +278,7 @@ static int __init parse_ivmd_device_sele
     bdf =3D ivmd_block->header.device_id;
     if ( bdf >=3D ivrs_bdf_entries )
     {
-        AMD_IOMMU_DEBUG("IVMD Error: Invalid Dev_Id 0x%x\n", bdf);
+        AMD_IOMMU_DEBUG("IVMD Error: Invalid Dev_Id %#x\n", bdf);
         return -ENODEV;
     }
=20
@@ -296,7 +296,7 @@ static int __init parse_ivmd_device_rang
     if ( first_bdf >=3D ivrs_bdf_entries )
     {
         AMD_IOMMU_DEBUG("IVMD Error: "
-                        "Invalid Range_First Dev_Id 0x%x\n", first_bdf);
+                        "Invalid Range_First Dev_Id %#x\n", first_bdf);
         return -ENODEV;
     }
=20
@@ -304,7 +304,7 @@ static int __init parse_ivmd_device_rang
     if ( (last_bdf >=3D ivrs_bdf_entries) || (last_bdf <=3D first_bdf) )
     {
         AMD_IOMMU_DEBUG("IVMD Error: "
-                        "Invalid Range_Last Dev_Id 0x%x\n", last_bdf);
+                        "Invalid Range_Last Dev_Id %#x\n", last_bdf);
         return -ENODEV;
     }
=20
@@ -326,7 +326,7 @@ static int __init parse_ivmd_device_iomm
                                     ivmd_block->aux_data);
     if ( !iommu )
     {
-        AMD_IOMMU_DEBUG("IVMD Error: No IOMMU for Dev_Id 0x%x  Cap =
0x%x\n",
+        AMD_IOMMU_DEBUG("IVMD Error: No IOMMU for Dev_Id %#x Cap %#x\n",
                         ivmd_block->header.device_id, ivmd_block->aux_data=
);
         return -ENODEV;
     }
@@ -351,9 +351,9 @@ static int __init parse_ivmd_block(const
     base =3D start_addr & PAGE_MASK;
     limit =3D (start_addr + mem_length - 1) & PAGE_MASK;
=20
-    AMD_IOMMU_DEBUG("IVMD Block: Type 0x%x\n",ivmd_block->header.type);
-    AMD_IOMMU_DEBUG(" Start_Addr_Phys 0x%lx\n", start_addr);
-    AMD_IOMMU_DEBUG(" Mem_Length 0x%lx\n", mem_length);
+    AMD_IOMMU_DEBUG("IVMD Block: Type %#x\n",ivmd_block->header.type);
+    AMD_IOMMU_DEBUG(" Start_Addr_Phys %#lx\n", start_addr);
+    AMD_IOMMU_DEBUG(" Mem_Length %#lx\n", mem_length);
=20
     if ( ivmd_block->header.flags & ACPI_IVMD_EXCLUSION_RANGE )
         iw =3D ir =3D IOMMU_CONTROL_ENABLED;
@@ -414,7 +414,7 @@ static u16 __init parse_ivhd_device_sele
     bdf =3D select->header.id;
     if ( bdf >=3D ivrs_bdf_entries )
     {
-        AMD_IOMMU_DEBUG("IVHD Error: Invalid Device_Entry Dev_Id 0x%x\n", =
bdf);
+        AMD_IOMMU_DEBUG("IVHD Error: Invalid Device_Entry Dev_Id %#x\n", =
bdf);
         return 0;
     }
=20
@@ -439,7 +439,7 @@ static u16 __init parse_ivhd_device_rang
     if ( range->end.header.type !=3D ACPI_IVRS_TYPE_END )
     {
         AMD_IOMMU_DEBUG("IVHD Error: "
-                        "Invalid Range: End_Type 0x%x\n",
+                        "Invalid Range: End_Type %#x\n",
                         range->end.header.type);
         return 0;
     }
@@ -448,7 +448,7 @@ static u16 __init parse_ivhd_device_rang
     if ( first_bdf >=3D ivrs_bdf_entries )
     {
         AMD_IOMMU_DEBUG("IVHD Error: "
-                        "Invalid Range: First Dev_Id 0x%x\n", first_bdf);
+                        "Invalid Range: First Dev_Id %#x\n", first_bdf);
         return 0;
     }
=20
@@ -456,11 +456,11 @@ static u16 __init parse_ivhd_device_rang
     if ( (last_bdf >=3D ivrs_bdf_entries) || (last_bdf <=3D first_bdf) )
     {
         AMD_IOMMU_DEBUG("IVHD Error: "
-                        "Invalid Range: Last Dev_Id 0x%x\n", last_bdf);
+                        "Invalid Range: Last Dev_Id %#x\n", last_bdf);
         return 0;
     }
=20
-    AMD_IOMMU_DEBUG(" Dev_Id Range: 0x%x -> 0x%x\n", first_bdf, last_bdf);=

+    AMD_IOMMU_DEBUG(" Dev_Id Range: %#x -> %#x\n", first_bdf, last_bdf);
=20
     for ( bdf =3D first_bdf; bdf <=3D last_bdf; bdf++ )
         add_ivrs_mapping_entry(bdf, bdf, range->start.header.data_setting,=

@@ -485,18 +485,18 @@ static u16 __init parse_ivhd_device_alia
     bdf =3D alias->header.id;
     if ( bdf >=3D ivrs_bdf_entries )
     {
-        AMD_IOMMU_DEBUG("IVHD Error: Invalid Device_Entry Dev_Id 0x%x\n", =
bdf);
+        AMD_IOMMU_DEBUG("IVHD Error: Invalid Device_Entry Dev_Id %#x\n", =
bdf);
         return 0;
     }
=20
     alias_id =3D alias->used_id;
     if ( alias_id >=3D ivrs_bdf_entries )
     {
-        AMD_IOMMU_DEBUG("IVHD Error: Invalid Alias Dev_Id 0x%x\n", =
alias_id);
+        AMD_IOMMU_DEBUG("IVHD Error: Invalid Alias Dev_Id %#x\n", =
alias_id);
         return 0;
     }
=20
-    AMD_IOMMU_DEBUG(" Dev_Id Alias: 0x%x\n", alias_id);
+    AMD_IOMMU_DEBUG(" Dev_Id Alias: %#x\n", alias_id);
=20
     add_ivrs_mapping_entry(bdf, alias_id, alias->header.data_setting, =
iommu);
=20
@@ -520,7 +520,7 @@ static u16 __init parse_ivhd_device_alia
     if ( range->end.header.type !=3D ACPI_IVRS_TYPE_END )
     {
         AMD_IOMMU_DEBUG("IVHD Error: "
-                        "Invalid Range: End_Type 0x%x\n",
+                        "Invalid Range: End_Type %#x\n",
                         range->end.header.type);
         return 0;
     }
@@ -529,7 +529,7 @@ static u16 __init parse_ivhd_device_alia
     if ( first_bdf >=3D ivrs_bdf_entries )
     {
         AMD_IOMMU_DEBUG("IVHD Error: "
-                        "Invalid Range: First Dev_Id 0x%x\n", first_bdf);
+                        "Invalid Range: First Dev_Id %#x\n", first_bdf);
         return 0;
     }
=20
@@ -537,19 +537,19 @@ static u16 __init parse_ivhd_device_alia
     if ( last_bdf >=3D ivrs_bdf_entries || last_bdf <=3D first_bdf )
     {
         AMD_IOMMU_DEBUG(
-            "IVHD Error: Invalid Range: Last Dev_Id 0x%x\n", last_bdf);
+            "IVHD Error: Invalid Range: Last Dev_Id %#x\n", last_bdf);
         return 0;
     }
=20
     alias_id =3D range->alias.used_id;
     if ( alias_id >=3D ivrs_bdf_entries )
     {
-        AMD_IOMMU_DEBUG("IVHD Error: Invalid Alias Dev_Id 0x%x\n", =
alias_id);
+        AMD_IOMMU_DEBUG("IVHD Error: Invalid Alias Dev_Id %#x\n", =
alias_id);
         return 0;
     }
=20
-    AMD_IOMMU_DEBUG(" Dev_Id Range: 0x%x -> 0x%x\n", first_bdf, last_bdf);=

-    AMD_IOMMU_DEBUG(" Dev_Id Alias: 0x%x\n", alias_id);
+    AMD_IOMMU_DEBUG(" Dev_Id Range: %#x -> %#x\n", first_bdf, last_bdf);
+    AMD_IOMMU_DEBUG(" Dev_Id Alias: %#x\n", alias_id);
=20
     for ( bdf =3D first_bdf; bdf <=3D last_bdf; bdf++ )
         add_ivrs_mapping_entry(bdf, alias_id, range->alias.header.data_set=
ting,
@@ -574,7 +574,7 @@ static u16 __init parse_ivhd_device_exte
     bdf =3D ext->header.id;
     if ( bdf >=3D ivrs_bdf_entries )
     {
-        AMD_IOMMU_DEBUG("IVHD Error: Invalid Device_Entry Dev_Id 0x%x\n", =
bdf);
+        AMD_IOMMU_DEBUG("IVHD Error: Invalid Device_Entry Dev_Id %#x\n", =
bdf);
         return 0;
     }
=20
@@ -599,7 +599,7 @@ static u16 __init parse_ivhd_device_exte
     if ( range->end.header.type !=3D ACPI_IVRS_TYPE_END )
     {
         AMD_IOMMU_DEBUG("IVHD Error: "
-                        "Invalid Range: End_Type 0x%x\n",
+                        "Invalid Range: End_Type %#x\n",
                         range->end.header.type);
         return 0;
     }
@@ -608,7 +608,7 @@ static u16 __init parse_ivhd_device_exte
     if ( first_bdf >=3D ivrs_bdf_entries )
     {
         AMD_IOMMU_DEBUG("IVHD Error: "
-                        "Invalid Range: First Dev_Id 0x%x\n", first_bdf);
+                        "Invalid Range: First Dev_Id %#x\n", first_bdf);
         return 0;
     }
=20
@@ -616,11 +616,11 @@ static u16 __init parse_ivhd_device_exte
     if ( (last_bdf >=3D ivrs_bdf_entries) || (last_bdf <=3D first_bdf) )
     {
         AMD_IOMMU_DEBUG("IVHD Error: "
-                        "Invalid Range: Last Dev_Id 0x%x\n", last_bdf);
+                        "Invalid Range: Last Dev_Id %#x\n", last_bdf);
         return 0;
     }
=20
-    AMD_IOMMU_DEBUG(" Dev_Id Range: 0x%x -> 0x%x\n",
+    AMD_IOMMU_DEBUG(" Dev_Id Range: %#x -> %#x\n",
                     first_bdf, last_bdf);
=20
     for ( bdf =3D first_bdf; bdf <=3D last_bdf; bdf++ )
@@ -646,7 +646,7 @@ static u16 __init parse_ivhd_device_spec
     bdf =3D special->used_id;
     if ( bdf >=3D ivrs_bdf_entries )
     {
-        AMD_IOMMU_DEBUG("IVHD Error: Invalid Device_Entry Dev_Id 0x%x\n", =
bdf);
+        AMD_IOMMU_DEBUG("IVHD Error: Invalid Device_Entry Dev_Id %#x\n", =
bdf);
         return 0;
     }
=20
@@ -673,7 +673,7 @@ static int __init parse_ivhd_block(const
                                     ivhd_block->capability_offset);
     if ( !iommu )
     {
-        AMD_IOMMU_DEBUG("IVHD Error: No IOMMU for Dev_Id 0x%x  Cap =
0x%x\n",
+        AMD_IOMMU_DEBUG("IVHD Error: No IOMMU for Dev_Id %#x Cap %#x\n",
                         ivhd_block->header.device_id,
                         ivhd_block->capability_offset);
         return -ENODEV;
@@ -687,9 +687,9 @@ static int __init parse_ivhd_block(const
         ivhd_device =3D (const void *)((const u8 *)ivhd_block + block_leng=
th);
=20
         AMD_IOMMU_DEBUG( "IVHD Device Entry:\n");
-        AMD_IOMMU_DEBUG( " Type 0x%x\n", ivhd_device->header.type);
-        AMD_IOMMU_DEBUG( " Dev_Id 0x%x\n", ivhd_device->header.id);
-        AMD_IOMMU_DEBUG( " Flags 0x%x\n", ivhd_device->header.data_setting=
);
+        AMD_IOMMU_DEBUG( " Type %#x\n", ivhd_device->header.type);
+        AMD_IOMMU_DEBUG( " Dev_Id %#x\n", ivhd_device->header.id);
+        AMD_IOMMU_DEBUG( " Flags %#x\n", ivhd_device->header.data_setting)=
;
=20
         switch ( ivhd_device->header.type )
         {
@@ -788,9 +788,9 @@ static void __init dump_acpi_table_heade
         printk("%c", table->signature[i]);
     printk("\n");
=20
-    AMD_IOMMU_DEBUG(" Length 0x%x\n", table->length);
-    AMD_IOMMU_DEBUG(" Revision 0x%x\n", table->revision);
-    AMD_IOMMU_DEBUG(" CheckSum 0x%x\n", table->checksum);
+    AMD_IOMMU_DEBUG(" Length %#x\n", table->length);
+    AMD_IOMMU_DEBUG(" Revision %#x\n", table->revision);
+    AMD_IOMMU_DEBUG(" CheckSum %#x\n", table->checksum);
=20
     AMD_IOMMU_DEBUG(" OEM_Id ");
     for ( i =3D 0; i < ACPI_OEM_ID_SIZE; i++ )
@@ -802,14 +802,14 @@ static void __init dump_acpi_table_heade
         printk("%c", table->oem_table_id[i]);
     printk("\n");
=20
-    AMD_IOMMU_DEBUG(" OEM_Revision 0x%x\n", table->oem_revision);
+    AMD_IOMMU_DEBUG(" OEM_Revision %#x\n", table->oem_revision);
=20
     AMD_IOMMU_DEBUG(" Creator_Id ");
     for ( i =3D 0; i < ACPI_NAME_SIZE; i++ )
         printk("%c", table->asl_compiler_id[i]);
     printk("\n");
=20
-    AMD_IOMMU_DEBUG(" Creator_Revision 0x%x\n",
+    AMD_IOMMU_DEBUG(" Creator_Revision %#x\n",
                     table->asl_compiler_revision);
=20
 }
@@ -832,15 +832,15 @@ static int __init parse_ivrs_table(struc
         ivrs_block =3D (struct acpi_ivrs_header *)((u8 *)table + length);
=20
         AMD_IOMMU_DEBUG("IVRS Block:\n");
-        AMD_IOMMU_DEBUG(" Type 0x%x\n", ivrs_block->type);
-        AMD_IOMMU_DEBUG(" Flags 0x%x\n", ivrs_block->flags);
-        AMD_IOMMU_DEBUG(" Length 0x%x\n", ivrs_block->length);
-        AMD_IOMMU_DEBUG(" Dev_Id 0x%x\n", ivrs_block->device_id);
+        AMD_IOMMU_DEBUG(" Type %#x\n", ivrs_block->type);
+        AMD_IOMMU_DEBUG(" Flags %#x\n", ivrs_block->flags);
+        AMD_IOMMU_DEBUG(" Length %#x\n", ivrs_block->length);
+        AMD_IOMMU_DEBUG(" Dev_Id %#x\n", ivrs_block->device_id);
=20
         if ( table->length < (length + ivrs_block->length) )
         {
             AMD_IOMMU_DEBUG("IVRS Error: "
-                            "Table Length Exceeded: 0x%x -> 0x%lx\n",
+                            "Table Length Exceeded: %#x -> %#lx\n",
                             table->length,
                             (length + ivrs_block->length));
             return -ENODEV;
@@ -867,7 +867,7 @@ static int __init detect_iommu_acpi(stru
         checksum +=3D raw_table[i];
     if ( checksum )
     {
-        AMD_IOMMU_DEBUG("IVRS Error: Invalid Checksum 0x%x\n", checksum);
+        AMD_IOMMU_DEBUG("IVRS Error: Invalid Checksum %#x\n", checksum);
         return -ENODEV;
     }
=20
--- 2012-09-21.orig/xen/drivers/passthrough/amd/iommu_init.c	2012-09-17 =
09:57:54.000000000 +0200
+++ 2012-09-21/xen/drivers/passthrough/amd/iommu_init.c	2012-09-21 =
10:54:46.000000000 +0200
@@ -616,8 +616,8 @@ static void parse_event_log_entry(struct
                                        IOMMU_EVENT_FLAGS_SHIFT);
         addr=3D (u64*) (entry + 2);
         printk(XENLOG_ERR "AMD-Vi: "
-               "%s: domain =3D %d, device id =3D 0x%04x, "
-               "fault address =3D 0x%"PRIx64", flags =3D 0x%03x\n",
+               "%s: domain =3D %d, device id =3D %#x, "
+               "fault address =3D %#"PRIx64", flags =3D %#x\n",
                event_str[code-1], domain_id, device_id, *addr, flags);
=20
         /* Tell the device to stop DMAing; we can't rely on the guest to
--- 2012-09-21.orig/xen/drivers/passthrough/amd/iommu_map.c	2012-09-14 =
13:26:34.000000000 +0200
+++ 2012-09-21/xen/drivers/passthrough/amd/iommu_map.c	2012-09-21 =
10:54:46.000000000 +0200
@@ -795,7 +795,7 @@ void amd_iommu_share_p2m(struct domain *
=20
         /* When sharing p2m with iommu, paging mode =3D 4 */
         hd->paging_mode =3D IOMMU_PAGING_MODE_LEVEL_4;
-        AMD_IOMMU_DEBUG("Share p2m table with iommu: p2m table =3D =
0x%lx\n",
+        AMD_IOMMU_DEBUG("Share p2m table with iommu: p2m table =3D =
%#lx\n",
                         mfn_x(pgd_mfn));
     }
 }
--- 2012-09-21.orig/xen/drivers/passthrough/amd/pci_amd_iommu.c	2012-09-14 =
13:26:34.000000000 +0200
+++ 2012-09-21/xen/drivers/passthrough/amd/pci_amd_iommu.c	2012-09-21 =
10:54:46.000000000 +0200
@@ -121,8 +121,8 @@ static void amd_iommu_setup_domain_devic
=20
         amd_iommu_flush_device(iommu, req_id);
=20
-        AMD_IOMMU_DEBUG("Setup I/O page table: device id =3D 0x%04x, "
-                        "root table =3D 0x%"PRIx64", "
+        AMD_IOMMU_DEBUG("Setup I/O page table: device id =3D %#x, "
+                        "root table =3D %#"PRIx64", "
                         "domain =3D %d, paging mode =3D %d\n", req_id,
                         page_to_maddr(hd->root_table),
                         hd->domain_id, hd->paging_mode);
@@ -314,7 +314,7 @@ void amd_iommu_disable_domain_device(str
=20
         amd_iommu_flush_device(iommu, req_id);
=20
-        AMD_IOMMU_DEBUG("Disable: device id =3D 0x%04x, "
+        AMD_IOMMU_DEBUG("Disable: device id =3D %#x, "
                         "domain =3D %d, paging mode =3D %d\n",
                         req_id,  domain_hvm_iommu(domain)->domain_id,
                         domain_hvm_iommu(domain)->paging_mode);
--- 2012-09-21.orig/xen/drivers/passthrough/vtd/dmar.c	2012-09-14 =
13:26:34.000000000 +0200
+++ 2012-09-21/xen/drivers/passthrough/vtd/dmar.c	2012-09-21 =
10:54:46.000000000 +0200
@@ -381,7 +381,7 @@ static int __init acpi_dmar_check_length
     if ( h->length >=3D min_len )
         return 0;
     dprintk(XENLOG_ERR VTDPREFIX,
-            "Invalid ACPI DMAR entry length: 0x%x\n",
+            "Invalid ACPI DMAR entry length: %#x\n",
             h->length);
     return -EINVAL;
 }
@@ -749,7 +749,7 @@ static int __init acpi_parse_dmar(struct
             break;
         default:
             dprintk(XENLOG_WARNING VTDPREFIX,
-                    "Ignore unknown DMAR structure type (0x%x)\n",
+                    "Ignore unknown DMAR structure type (%#x)\n",
                     entry_header->type);
             break;
         }
--- 2012-09-21.orig/xen/drivers/passthrough/vtd/intremap.c	2012-09-14 =
13:26:34.000000000 +0200
+++ 2012-09-21/xen/drivers/passthrough/vtd/intremap.c	2012-09-21 =
10:54:46.000000000 +0200
@@ -135,7 +135,7 @@ int iommu_supports_eim(void)
         if ( !ioapic_to_drhd(IO_APIC_ID(apic)) )
     {
             dprintk(XENLOG_WARNING VTDPREFIX,
-                    "There is not a DRHD for IOAPIC 0x%x (id: 0x%x)!\n",
+                    "There is not a DRHD for IOAPIC %#x (id: %#x)!\n",
                     apic, IO_APIC_ID(apic));
             return 0;
     }
--- 2012-09-21.orig/xen/drivers/passthrough/vtd/iommu.c	2012-09-17 =
09:57:55.000000000 +0200
+++ 2012-09-21/xen/drivers/passthrough/vtd/iommu.c	2012-09-21 =
10:54:46.000000000 +0200
@@ -2035,7 +2035,7 @@ static int init_vtd_hw(void)
             {
                 iommu_intremap =3D 0;
                 dprintk(XENLOG_ERR VTDPREFIX,
-                    "ioapic_to_iommu: ioapic 0x%x (id: 0x%x) is NULL! "
+                    "ioapic_to_iommu: ioapic %#x (id: %#x) is NULL! "
                     "Will not try to enable Interrupt Remapping.\n",
                     apic, IO_APIC_ID(apic));
                 break;
--- 2012-09-21.orig/xen/drivers/passthrough/vtd/utils.c	2012-09-14 =
13:26:34.000000000 +0200
+++ 2012-09-21/xen/drivers/passthrough/vtd/utils.c	2012-09-21 =
10:54:46.000000000 +0200
@@ -217,7 +217,7 @@ static void dump_iommu_info(unsigned cha
             struct iremap_entry *iremap_entries =3D NULL;
             int print_cnt =3D 0;
=20
-            printk("  Interrupt remapping table (nr_entry=3D0x%x. "
+            printk("  Interrupt remapping table (nr_entry=3D%#x. "
                 "Only dump P=3D1 entries here):\n", nr_entry);
             printk("       SVT  SQ   SID      DST  V  AVL DLM TM RH DM "
                    "FPD P\n");
--- 2012-09-21.orig/xen/drivers/video/vesa.c	2012-09-14 13:26:34.0000000=
00 +0200
+++ 2012-09-21/xen/drivers/video/vesa.c	2012-09-21 10:54:46.000000000 =
+0200
@@ -111,7 +111,7 @@ void __init vesa_init(void)
=20
     vga_puts =3D vesa_redraw_puts;
=20
-    printk(XENLOG_INFO "vesafb: framebuffer at 0x%x, mapped to 0x%p, "
+    printk(XENLOG_INFO "vesafb: framebuffer at %#x, mapped to 0x%p, "
            "using %uk, total %uk\n",
            vlfb_info.lfb_base, lfb,
            vram_remap >> 10, vram_total >> 10);



--=__Part6756664C.0__=
Content-Type: text/plain; name="printk-alternative.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="printk-alternative.patch"

printk: prefer %#x et at over 0x%x=0A=0APerformance is not an issue with =
printk(), so let the function do=0Aminimally more work and instead save a =
byte per affected format=0Aspecifier.=0A=0ASigned-off-by: Jan Beulich =
<jbeulich@suse.com>=0A=0A--- 2012-09-21.orig/xen/arch/x86/acpi/boot.c	=
2012-09-20 08:44:38.000000000 +0200=0A+++ 2012-09-21/xen/arch/x86/acpi/boot=
.c	2012-09-21 10:54:46.000000000 +0200=0A@@ -341,14 +341,14 @@ =
acpi_fadt_parse_sleep_info(struct acpi_t=0A 	}=0A =0A 	if =
(facs->length < 24) {=0A-		printk(KERN_ERR PREFIX "Invalid =
FACS table length: 0x%x",=0A+		printk(KERN_ERR PREFIX "Invalid =
FACS table length: %#x",=0A 			facs->length);=0A 		=
goto bad;=0A 	}=0A =0A 	if (facs->length < 64)=0A 		=
printk(KERN_WARNING PREFIX=0A-			"FACS is shorter than ACPI =
spec allow: 0x%x",=0A+			"FACS is shorter than ACPI spec =
allow: %#x",=0A 			facs->length);=0A =0A 	acpi_sinfo.=
wakeup_vector =3D facs_pa + =0A--- 2012-09-21.orig/xen/arch/x86/acpi/cpu_id=
le.c	2012-08-15 08:32:43.000000000 +0200=0A+++ 2012-09-21/xen/arch/x86/a=
cpi/cpu_idle.c	2012-09-21 10:54:46.000000000 +0200=0A@@ -978,11 +978,11 =
@@ static void print_cx_pminfo(uint32_t cpu=0A             return;=0A      =
   =0A         printk("\tstates[%d]:\n", i);=0A-        printk("\t\treg.spa=
ce_id =3D 0x%x\n", state.reg.space_id);=0A-        printk("\t\treg.bit_widt=
h =3D 0x%x\n", state.reg.bit_width);=0A-        printk("\t\treg.bit_offset =
=3D 0x%x\n", state.reg.bit_offset);=0A-        printk("\t\treg.access_size =
=3D 0x%x\n", state.reg.access_size);=0A-        printk("\t\treg.address =
=3D 0x%"PRIx64"\n", state.reg.address);=0A+        printk("\t\treg.space_id=
 =3D %#x\n", state.reg.space_id);=0A+        printk("\t\treg.bit_width =3D =
%#x\n", state.reg.bit_width);=0A+        printk("\t\treg.bit_offset =3D =
%#x\n", state.reg.bit_offset);=0A+        printk("\t\treg.access_size =3D =
%#x\n", state.reg.access_size);=0A+        printk("\t\treg.address =3D =
%#"PRIx64"\n", state.reg.address);=0A         printk("\t\ttype    =3D =
%d\n", state.type);=0A         printk("\t\tlatency =3D %d\n", state.latency=
);=0A         printk("\t\tpower   =3D %d\n", state.power);=0A--- 2012-09-21=
.orig/xen/arch/x86/apic.c	2012-09-17 09:57:54.000000000 +0200=0A+++ =
2012-09-21/xen/arch/x86/apic.c	2012-09-21 10:54:46.000000000 +0200=0A@@ =
-689,7 +689,7 @@ void __devinit setup_local_APIC(void)=0A         value =
=3D apic_read(APIC_ESR);=0A         if (value !=3D oldvalue)=0A            =
 apic_printk(APIC_VERBOSE, "ESR value before enabling "=0A-                =
        "vector: 0x%08lx  after: 0x%08lx\n",=0A+                        =
"vector: %#lx  after: %#lx\n",=0A                         oldvalue, =
value);=0A     } else {=0A         if (esr_disable)    =0A@@ -1210,7 =
+1210,7 @@ static int __init calibrate_APIC_clock(v=0A     bus_cycle  =3D =
(u32) (1000000000000LL/bus_freq); /* in pico seconds */=0A     bus_scale  =
=3D (1000*262144)/bus_cycle;=0A =0A-    apic_printk(APIC_VERBOSE, "..... =
bus_scale =3D 0x%08X\n", bus_scale);=0A+    apic_printk(APIC_VERBOSE, =
"..... bus_scale =3D %#x\n", bus_scale);=0A     /* reset APIC to zero =
timeout value */=0A     __setup_APIC_LVTT(0);=0A =0A--- 2012-09-21.orig/xen=
/arch/x86/cpu/mcheck/mce.c	2012-09-20 08:44:38.000000000 +0200=0A+++ =
2012-09-21/xen/arch/x86/cpu/mcheck/mce.c	2012-09-21 10:54:46.0000000=
00 +0200=0A@@ -1147,7 +1147,7 @@ static int x86_mc_msrinject_verify(struc=
=0A         }=0A =0A         if (reason !=3D NULL) {=0A-            =
printk("HV MSR INJECT ERROR: MSR 0x%llx %s\n",=0A+            printk("HV =
MSR INJECT ERROR: MSR %#Lx %s\n",=0A                    (unsigned long =
long)mci->mcinj_msr[i].reg, reason);=0A             errs++;=0A         =
}=0A@@ -1191,8 +1191,7 @@ static void x86_mc_msrinject(void *data)=0A =0A  =
   for (i =3D 0, msr =3D &mci->mcinj_msr[0];=0A          i < mci->mcinj_cou=
nt; i++, msr++) {=0A-        printk("HV MSR INJECT (%s) target %u actual =
%u MSR 0x%llx "=0A-               "<-- 0x%llx\n",=0A+        printk("HV =
MSR INJECT (%s) target %u actual %u MSR %#Lx <-- %#Lx\n",=0A               =
 intpose ?  "interpose" : "hardware",=0A                mci->mcinj_cpunr, =
smp_processor_id(),=0A                (unsigned long long)msr->reg,=0A--- =
2012-09-21.orig/xen/arch/x86/cpu/mcheck/vmce.c	2012-08-08 08:20:09.0000000=
00 +0200=0A+++ 2012-09-21/xen/arch/x86/cpu/mcheck/vmce.c	2012-09-21 =
10:54:46.000000000 +0200=0A@@ -88,7 +88,7 @@ static int bank_mce_rdmsr(cons=
t struct v=0A     case MSR_IA32_MC0_CTL:=0A         /* stick all 1's to =
MCi_CTL */=0A         *val =3D ~0UL;=0A-        mce_printk(MCE_VERBOSE, =
"MCE: rdmsr MC%u_CTL 0x%"PRIx64"\n",=0A+        mce_printk(MCE_VERBOSE, =
"MCE: rdmsr MC%u_CTL %#"PRIx64"\n",=0A                    bank, *val);=0A  =
       break;=0A     case MSR_IA32_MC0_STATUS:=0A@@ -102,7 +102,7 @@ =
static int bank_mce_rdmsr(const struct v=0A                 *val =3D =
entry->mci_status;=0A                 mce_printk(MCE_VERBOSE,=0A           =
                 "MCE: rd MC%u_STATUS in vMCE# context "=0A-               =
            "value 0x%"PRIx64"\n", bank, *val);=0A+                        =
   "value %#"PRIx64"\n", bank, *val);=0A             }=0A         }=0A     =
    break;=0A@@ -116,7 +116,7 @@ static int bank_mce_rdmsr(const struct =
v=0A                 *val =3D entry->mci_addr;=0A                 =
mce_printk(MCE_VERBOSE,=0A                            "MCE: rdmsr =
MC%u_ADDR in vMCE# context "=0A-                           "0x%"PRIx64"\n",=
 bank, *val);=0A+                           "%#"PRIx64"\n", bank, =
*val);=0A             }=0A         }=0A         break;=0A@@ -130,7 +130,7 =
@@ static int bank_mce_rdmsr(const struct v=0A                 *val =3D =
entry->mci_misc;=0A                 mce_printk(MCE_VERBOSE,=0A             =
               "MCE: rd MC%u_MISC in vMCE# context "=0A-                   =
        "0x%"PRIx64"\n", bank, *val);=0A+                           =
"%#"PRIx64"\n", bank, *val);=0A             }=0A         }=0A         =
break;=0A@@ -171,18 +171,18 @@ int vmce_rdmsr(uint32_t msr, uint64_t *v=0A =
        *val =3D vmce->mcg_status;=0A         if (*val)=0A             =
mce_printk(MCE_VERBOSE,=0A-                       "MCE: rdmsr MCG_STATUS =
0x%"PRIx64"\n", *val);=0A+                       "MCE: rdmsr MCG_STATUS =
%#"PRIx64"\n", *val);=0A         break;=0A     case MSR_IA32_MCG_CAP:=0A   =
      *val =3D cur->arch.mcg_cap;=0A-        mce_printk(MCE_VERBOSE, "MCE: =
rdmsr MCG_CAP 0x%"PRIx64"\n",=0A+        mce_printk(MCE_VERBOSE, "MCE: =
rdmsr MCG_CAP %#"PRIx64"\n",=0A                    *val);=0A         =
break;=0A     case MSR_IA32_MCG_CTL:=0A         /* Stick all 1's when CTL =
support, and 0's when no CTL support */=0A         if ( cur->arch.mcg_cap =
& MCG_CTL_P )=0A             *val =3D ~0ULL;=0A-        mce_printk(MCE_VERB=
OSE, "MCE: rdmsr MCG_CTL 0x%"PRIx64"\n", *val);=0A+        mce_printk(MCE_V=
ERBOSE, "MCE: rdmsr MCG_CTL %#"PRIx64"\n", *val);=0A         break;=0A     =
default:=0A         ret =3D mce_bank_msr(cur, msr) ? bank_mce_rdmsr(cur, =
msr, val) : 0;=0A--- 2012-09-21.orig/xen/arch/x86/cpu/mtrr/generic.c	=
2011-04-11 08:33:59.000000000 +0200=0A+++ 2012-09-21/xen/arch/x86/cpu/mtrr/=
generic.c	2012-09-21 10:54:46.000000000 +0200=0A@@ -410,7 +410,7 @@ =
int generic_validate_add_page(unsigned l=0A 	    boot_cpu_data.x86_model=
 =3D=3D 1 &&=0A 	    boot_cpu_data.x86_mask <=3D 7) {=0A 		=
if (base & ((1 << (22 - PAGE_SHIFT)) - 1)) {=0A-			=
printk(KERN_WARNING "mtrr: base(0x%lx000) is not 4 MiB aligned\n", =
base);=0A+			printk(KERN_WARNING "mtrr: base(%#lx000) =
is not 4 MiB aligned\n", base);=0A 			return -EINVAL;=0A =
		}=0A 		if (!(base + size < 0x70000 || base > =
0x7003F) &&=0A@@ -427,7 +427,7 @@ int generic_validate_add_page(unsigned =
l=0A 	for (lbase =3D base; !(lbase & 1) && (last & 1);=0A 	     lbase =
=3D lbase >> 1, last =3D last >> 1) ;=0A 	if (lbase !=3D last) {=0A-	=
	printk(KERN_WARNING "mtrr: base(0x%lx000) is not aligned on a =
size(0x%lx000) boundary\n",=0A+		printk(KERN_WARNING "mtrr: =
base(%#lx000) is not aligned on a size(%#lx000) boundary\n",=0A 		=
       base, size);=0A 		return -EINVAL;=0A 	}=0A--- 2012-09-21.=
orig/xen/arch/x86/cpu/mtrr/main.c	2012-09-21 10:32:44.000000000 =
+0200=0A+++ 2012-09-21/xen/arch/x86/cpu/mtrr/main.c	2012-09-21 =
10:54:46.000000000 +0200=0A@@ -366,8 +366,8 @@ int mtrr_add_page(unsigned =
long base, un=0A 					continue;=0A 		=
	}=0A 			printk(KERN_WARNING=0A-			   =
    "mtrr: 0x%lx000,0x%lx000 overlaps existing"=0A-			   =
    " 0x%lx000,0x%lx000\n", base, size, lbase,=0A+			   =
    "mtrr: %#lx000,%#lx000 overlaps existing"=0A+			   =
    " %#lx000,%#lx000\n", base, size, lbase,=0A 			   =
    lsize);=0A 			goto out;=0A 		}=0A@@ -412,7 =
+412,7 @@ static int mtrr_check(unsigned long base=0A 		printk(KERN=
_WARNING=0A 			"mtrr: size and base must be multiples of =
4 kiB\n");=0A 		printk(KERN_DEBUG=0A-			"mtrr: =
size: 0x%lx  base: 0x%lx\n", size, base);=0A+			"mtrr: =
size: %#lx  base: %#lx\n", size, base);=0A 		dump_stack();=0A 	=
	return -1;=0A 	}=0A--- 2012-09-21.orig/xen/arch/x86/domain_build.c=
	2012-09-14 13:26:34.000000000 +0200=0A+++ 2012-09-21/xen/arch/x86/d=
omain_build.c	2012-09-21 10:55:47.000000000 +0200=0A@@ -396,13 +396,13 =
@@ int __init construct_dom0(=0A     }=0A     if (elf_64bit(&elf) && =
machine =3D=3D EM_X86_64)=0A         compatible =3D 1;=0A-    printk(" =
Dom0 kernel: %s%s, %s, paddr 0x%" PRIx64 " -> 0x%" PRIx64 "\n",=0A+    =
printk(" Dom0 kernel: %s%s, %s, paddr %#" PRIx64 " -> %#" PRIx64 "\n",=0A  =
          elf_64bit(&elf) ? "64-bit" : "32-bit",=0A            parms.pae   =
    ? ", PAE"  : "",=0A            elf_msb(&elf)   ? "msb"    : "lsb",=0A  =
          elf.pstart, elf.pend);=0A     if ( elf.bsd_symtab_pstart )=0A-   =
     printk(" Dom0 symbol map 0x%" PRIx64 " -> 0x%" PRIx64 "\n",=0A+       =
 printk(" Dom0 symbol map %#" PRIx64 " -> %#" PRIx64 "\n",=0A              =
  elf.bsd_symtab_pstart, elf.bsd_symtab_pend);=0A =0A     if ( !compatible =
)=0A--- 2012-09-21.orig/xen/arch/x86/hvm/hvm.c	2012-09-20 08:44:38.0000000=
00 +0200=0A+++ 2012-09-21/xen/arch/x86/hvm/hvm.c	2012-09-21 =
10:54:46.000000000 +0200=0A@@ -1468,7 +1468,7 @@ int hvm_set_efer(uint64_t =
value)=0A     if ( !hvm_efer_valid(v->domain, value, efer_validbits) )=0A  =
   {=0A         gdprintk(XENLOG_WARNING, "Trying to set reserved bit in =
"=0A-                 "EFER: 0x%"PRIx64"\n", value);=0A+                 =
"EFER: %#"PRIx64"\n", value);=0A         hvm_inject_hw_exception(TRAP_gp_fa=
ult, 0);=0A         return X86EMUL_EXCEPTION;=0A     }=0A@@ -4095,7 =
+4095,7 @@ long do_hvm_op(unsigned long op, XEN_GUE=0A             {=0A    =
             put_gfn(d, pfn);=0A                 gdprintk(XENLOG_WARNING,=
=0A-                         "type for pfn 0x%lx changed to grant while =
"=0A+                         "type for pfn %#lx changed to grant while =
"=0A                          "we were working?\n", pfn);=0A               =
  goto param_fail4;=0A             }=0A@@ -4106,7 +4106,7 @@ long =
do_hvm_op(unsigned long op, XEN_GUE=0A                 {=0A                =
     put_gfn(d, pfn);=0A                     gdprintk(XENLOG_WARNING,=0A-  =
                           "type of pfn 0x%lx changed from %d to %d while =
"=0A+                             "type of pfn %#lx changed from %d to %d =
while "=0A                              "we were trying to change it to =
%d\n",=0A                              pfn, t, nt, memtype[a.hvmmem_type]);=
=0A                     goto param_fail4;=0A--- 2012-09-21.orig/xen/arch/x8=
6/hvm/io.c	2012-07-30 09:49:58.000000000 +0200=0A+++ 2012-09-21/xen/ar=
ch/x86/hvm/io.c	2012-09-21 10:54:46.000000000 +0200=0A@@ -393,7 +393,7 @@ =
int dpci_ioport_intercept(ioreq_t *p)=0A =0A     if ( !ioports_access_permi=
tted(d, mport, mport + p->size - 1) ) =0A     {=0A-        gdprintk(XENLOG_=
ERR, "Error: access to gport=3D0x%x denied!\n",=0A+        gdprintk(XENLOG_=
ERR, "Error: access to gport=3D%#x denied!\n",=0A                  =
(uint32_t)p->addr);=0A         return X86EMUL_UNHANDLEABLE;=0A     }=0A--- =
2012-09-21.orig/xen/arch/x86/hvm/irq.c	2012-09-14 13:26:34.000000000 =
+0200=0A+++ 2012-09-21/xen/arch/x86/hvm/irq.c	2012-09-21 10:54:46.0000000=
00 +0200=0A@@ -488,7 +488,7 @@ static void irq_dump(struct domain *d)=0A   =
         hvm_irq->pci_link_assert_count[1],=0A            hvm_irq->pci_link=
_assert_count[2],=0A            hvm_irq->pci_link_assert_count[3]);=0A-    =
printk("Callback via %i:0x%"PRIx32",%s asserted\n", =0A+    printk("Callbac=
k via %i:%#"PRIx32",%s asserted\n",=0A            hvm_irq->callback_via_typ=
e, hvm_irq->callback_via.gsi, =0A            hvm_irq->callback_via_asserted=
 ? "" : " not");=0A }=0A--- 2012-09-21.orig/xen/arch/x86/hvm/svm/intr.c	=
2012-01-20 10:10:22.000000000 +0100=0A+++ 2012-09-21/xen/arch/x86/hvm/svm/i=
ntr.c	2012-09-21 10:54:46.000000000 +0200=0A@@ -175,7 +175,7 @@ void =
svm_intr_assist(void) =0A                 /* Guest already enabled an =
interrupt window. */=0A                 return;=0A             default:=0A-=
                panic("%s: nestedsvm_vcpu_interrupt can't handle value =
0x%x\n",=0A+                panic("%s: nestedsvm_vcpu_interrupt can't =
handle value %#x\n",=0A                     __func__, rc);=0A             =
}=0A         }=0A--- 2012-09-21.orig/xen/arch/x86/hvm/svm/nestedsvm.c	=
2012-09-05 11:59:49.000000000 +0200=0A+++ 2012-09-21/xen/arch/x86/hvm/svm/n=
estedsvm.c	2012-09-21 10:54:46.000000000 +0200=0A@@ -943,7 +943,7 @@ =
nsvm_vmcb_guest_intercepts_exitcode(stru=0A         break;=0A =0A     =
default:=0A-        gdprintk(XENLOG_ERR, "Illegal exitcode 0x%"PRIx64"\n", =
exitcode);=0A+        gdprintk(XENLOG_ERR, "Illegal exitcode %#"PRIx64"\n",=
 exitcode);=0A         BUG();=0A         break;=0A     }=0A@@ -1235,7 =
+1235,7 @@ int nsvm_wrmsr(struct vcpu *v, unsigned =0A     case MSR_K8_VM_H=
SAVE_PA:=0A         if (!nestedsvm_vmcb_isvalid(v, msr_content)) {=0A      =
       gdprintk(XENLOG_ERR,=0A-                "MSR_K8_VM_HSAVE_PA value =
invalid 0x%"PRIx64"\n", msr_content);=0A+                "MSR_K8_VM_HSAVE_P=
A value invalid %#"PRIx64"\n", msr_content);=0A             ret =3D -1; /* =
inject #GP */=0A             break;=0A         }=0A@@ -1244,7 +1244,7 @@ =
int nsvm_wrmsr(struct vcpu *v, unsigned =0A     case MSR_AMD64_TSC_RATIO:=
=0A         if ((msr_content & ~TSC_RATIO_RSVD_BITS) !=3D msr_content) =
{=0A             gdprintk(XENLOG_ERR,=0A-                "reserved bits =
set in MSR_AMD64_TSC_RATIO 0x%"PRIx64"\n",=0A+                "reserved =
bits set in MSR_AMD64_TSC_RATIO %#"PRIx64"\n",=0A                 =
msr_content);=0A             ret =3D -1; /* inject #GP */=0A             =
break;=0A--- 2012-09-21.orig/xen/arch/x86/hvm/svm/svm.c	2012-09-17 =
09:57:54.000000000 +0200=0A+++ 2012-09-21/xen/arch/x86/hvm/svm/svm.c	=
2012-09-21 10:54:46.000000000 +0200=0A@@ -241,7 +241,7 @@ static int =
svm_vmcb_restore(struct vcpu =0A          ((c->pending_type =3D=3D 1) || =
(c->pending_type > 6) ||=0A           (c->pending_reserved !=3D 0)) )=0A   =
  {=0A-        gdprintk(XENLOG_ERR, "Invalid pending event 0x%"PRIx32".\n",=
=0A+        gdprintk(XENLOG_ERR, "Invalid pending event %#"PRIx32".\n",=0A =
                 c->pending_event);=0A         return -EINVAL;=0A     =
}=0A@@ -254,7 +254,7 @@ static int svm_vmcb_restore(struct vcpu =0A        =
                              NULL, P2M_ALLOC);=0A             if ( !page =
)=0A             {=0A-                gdprintk(XENLOG_ERR, "Invalid CR3 =
value=3D0x%"PRIx64"\n",=0A+                gdprintk(XENLOG_ERR, "Invalid =
CR3 value=3D%#"PRIx64"\n",=0A                          c->cr3);=0A         =
        return -EINVAL;=0A             }=0A@@ -289,7 +289,7 @@ static int =
svm_vmcb_restore(struct vcpu =0A =0A     if ( c->pending_valid ) =0A     =
{=0A-        gdprintk(XENLOG_INFO, "Re-injecting 0x%"PRIx32", 0x%"PRIx32"\n=
",=0A+        gdprintk(XENLOG_INFO, "Re-injecting %#"PRIx32", %#"PRIx32"\n"=
,=0A                  c->pending_event, c->error_code);=0A =0A         if =
( hvm_event_needs_reinjection(c->pending_type, c->pending_vector) )=0A@@ =
-2398,8 +2398,8 @@ void svm_vmexit_handler(struct cpu_user_=0A =0A     =
default:=0A     exit_and_crash:=0A-        gdprintk(XENLOG_ERR, "unexpected=
 VMEXIT: exit reason =3D 0x%"PRIx64", "=0A-                 "exitinfo1 =3D =
%"PRIx64", exitinfo2 =3D %"PRIx64"\n",=0A+        gdprintk(XENLOG_ERR, =
"unexpected VMEXIT: exit reason =3D %#"PRIx64", "=0A+                 =
"exitinfo1 =3D %#"PRIx64", exitinfo2 =3D %#"PRIx64"\n",=0A                 =
 exit_reason, =0A                  (u64)vmcb->exitinfo1, (u64)vmcb->exitinf=
o2);=0A         domain_crash(v->domain);=0A--- 2012-09-21.orig/xen/arch/x86=
/hvm/svm/svmdebug.c	2011-07-11 08:32:12.000000000 +0200=0A+++ =
2012-09-21/xen/arch/x86/hvm/svm/svmdebug.c	2012-09-21 10:54:46.0000000=
00 +0200=0A@@ -32,33 +32,32 @@ static void svm_dump_sel(const char *nam=0A =
void svm_vmcb_dump(const char *from, struct vmcb_struct *vmcb)=0A {=0A     =
printk("Dumping guest's current state at %s...\n", from);=0A-    printk("Si=
ze of VMCB =3D %d, paddr =3D 0x%016lx, vaddr =3D %p\n",=0A+    printk("Size=
 of VMCB =3D %d, paddr =3D %#lx, vaddr =3D %p\n",=0A            (int) =
sizeof(struct vmcb_struct), virt_to_maddr(vmcb), vmcb);=0A =0A-    =
printk("cr_intercepts =3D 0x%08x dr_intercepts =3D 0x%08x "=0A-           =
"exception_intercepts =3D 0x%08x\n", =0A+    printk("cr_intercepts =3D %#x =
dr_intercepts =3D %#x "=0A+           "exception_intercepts =3D %#x\n",=0A =
           vmcb->_cr_intercepts, vmcb->_dr_intercepts, =0A            =
vmcb->_exception_intercepts);=0A-    printk("general1_intercepts =3D =
0x%08x general2_intercepts =3D 0x%08x\n", =0A+    printk("general1_intercep=
ts =3D %#x general2_intercepts =3D %#x\n",=0A            vmcb->_general1_in=
tercepts, vmcb->_general2_intercepts);=0A-    printk("iopm_base_pa =3D =
0x%016llx msrpm_base_pa =3D 0x%016llx tsc_offset =3D "=0A-            =
"0x%016llx\n", =0A+    printk("iopm_base_pa =3D %#Lx msrpm_base_pa =3D =
%#Lx tsc_offset =3D %#Lx\n",=0A            (unsigned long long)vmcb->_iopm_=
base_pa,=0A            (unsigned long long)vmcb->_msrpm_base_pa,=0A        =
    (unsigned long long)vmcb->_tsc_offset);=0A-    printk("tlb_control =3D =
0x%08x vintr =3D 0x%016llx interrupt_shadow =3D "=0A-            "0x%016llx=
\n", vmcb->tlb_control,=0A+    printk("tlb_control =3D %#x vintr =3D %#Lx =
interrupt_shadow =3D %#Lx\n",=0A+           vmcb->tlb_control,=0A          =
  (unsigned long long)vmcb->_vintr.bytes,=0A            (unsigned long =
long)vmcb->interrupt_shadow);=0A-    printk("exitcode =3D 0x%016llx =
exitintinfo =3D 0x%016llx\n", =0A+    printk("exitcode =3D %#Lx exitintinfo=
 =3D %#Lx\n",=0A            (unsigned long long)vmcb->exitcode,=0A         =
   (unsigned long long)vmcb->exitintinfo.bytes);=0A-    printk("exitinfo1 =
=3D 0x%016llx exitinfo2 =3D 0x%016llx \n",=0A+    printk("exitinfo1 =3D =
%#Lx exitinfo2 =3D %#Lx \n",=0A            (unsigned long long)vmcb->exitin=
fo1,=0A            (unsigned long long)vmcb->exitinfo2);=0A-    printk("np_=
enable =3D 0x%016llx guest_asid =3D 0x%03x\n", =0A+    printk("np_enable =
=3D %Lx guest_asid =3D %#x\n",=0A            (unsigned long long)vmcb->_np_=
enable, vmcb->_guest_asid);=0A-    printk("cpl =3D %d efer =3D 0x%016llx =
star =3D 0x%016llx lstar =3D 0x%016llx\n", =0A+    printk("cpl =3D %d efer =
=3D %#Lx star =3D %#Lx lstar =3D %#Lx\n",=0A            vmcb->_cpl, =
(unsigned long long)vmcb->_efer,=0A            (unsigned long long)vmcb->st=
ar, (unsigned long long)vmcb->lstar);=0A     printk("CR0 =3D 0x%016llx CR2 =
=3D 0x%016llx\n",=0A@@ -77,7 +76,7 @@ void svm_vmcb_dump(const char *from, =
str=0A     printk("KernGSBase =3D 0x%016llx PAT =3D 0x%016llx \n", =0A     =
       (unsigned long long)vmcb->kerngsbase,=0A            (unsigned long =
long)vmcb->_g_pat);=0A-    printk("H_CR3 =3D 0x%016llx CleanBits =3D =
0x%08x\n",=0A+    printk("H_CR3 =3D 0x%016llx CleanBits =3D %#x\n",=0A     =
       (unsigned long long)vmcb->_h_cr3, vmcb->cleanbits.bytes);=0A =0A    =
 /* print out all the selectors */=0A@@ -104,48 +103,48 @@ svm_vmcb_isvalid=
(const char *from, struc=0A     } else return 1;=0A =0A     if ((vmcb->_efe=
r & EFER_SVME) =3D=3D 0) {=0A-        PRINTF("EFER: SVME bit not set =
(0x%"PRIx64")\n", vmcb->_efer);=0A+        PRINTF("EFER: SVME bit not set =
(%#"PRIx64")\n", vmcb->_efer);=0A     }=0A =0A     if ((vmcb->_cr0 & =
X86_CR0_CD) =3D=3D 0 && (vmcb->_cr0 & X86_CR0_NW) !=3D 0) {=0A-        =
PRINTF("CR0: CD bit is zero and NW bit set (0x%"PRIx64")\n",=0A+        =
PRINTF("CR0: CD bit is zero and NW bit set (%#"PRIx64")\n",=0A             =
    vmcb->_cr0);=0A     }=0A =0A     if ((vmcb->_cr0 >> 32U) !=3D 0) {=0A- =
       PRINTF("CR0: bits [63:32] are not zero (0x%"PRIx64")\n",=0A+        =
PRINTF("CR0: bits [63:32] are not zero (%#"PRIx64")\n",=0A                 =
vmcb->_cr0);=0A     }=0A =0A     if ((vmcb->_cr3 & 0x7) !=3D 0) {=0A-      =
  PRINTF("CR3: MBZ bits are set (0x%"PRIx64")\n", vmcb->_cr3);=0A+        =
PRINTF("CR3: MBZ bits are set (%#"PRIx64")\n", vmcb->_cr3);=0A     }=0A    =
 if ((vmcb->_efer & EFER_LMA) && (vmcb->_cr3 & 0xfe) !=3D 0) {=0A-        =
PRINTF("CR3: MBZ bits are set (0x%"PRIx64")\n", vmcb->_cr3);=0A+        =
PRINTF("CR3: MBZ bits are set (%#"PRIx64")\n", vmcb->_cr3);=0A     }=0A =
=0A     if ((vmcb->_cr4 >> 19U) !=3D 0) {=0A-        PRINTF("CR4: bits =
[63:19] are not zero (0x%"PRIx64")\n",=0A+        PRINTF("CR4: bits =
[63:19] are not zero (%#"PRIx64")\n",=0A                 vmcb->_cr4);=0A   =
  }=0A =0A     if (((vmcb->_cr4 >> 11U) & 0x7fU) !=3D 0) {=0A-        =
PRINTF("CR4: bits [17:11] are not zero (0x%"PRIx64")\n",=0A+        =
PRINTF("CR4: bits [17:11] are not zero (%#"PRIx64")\n",=0A                 =
vmcb->_cr4);=0A     }=0A =0A     if ((vmcb->_dr6 >> 32U) !=3D 0) {=0A-     =
   PRINTF("DR6: bits [63:32] are not zero (0x%"PRIx64")\n",=0A+        =
PRINTF("DR6: bits [63:32] are not zero (%#"PRIx64")\n",=0A                 =
vmcb->_dr6);=0A     }=0A =0A     if ((vmcb->_dr7 >> 32U) !=3D 0) {=0A-     =
   PRINTF("DR7: bits [63:32] are not zero (0x%"PRIx64")\n",=0A+        =
PRINTF("DR7: bits [63:32] are not zero (%#"PRIx64")\n",=0A                 =
vmcb->_dr7);=0A     }=0A =0A     if ((vmcb->_efer >> 15U) !=3D 0) {=0A-    =
    PRINTF("EFER: bits [63:15] are not zero (0x%"PRIx64")\n",=0A+        =
PRINTF("EFER: bits [63:15] are not zero (%#"PRIx64")\n",=0A                =
 vmcb->_efer);=0A     }=0A =0A@@ -168,12 +167,12 @@ svm_vmcb_isvalid(const =
char *from, struc=0A     }=0A =0A     if ((vmcb->_general2_intercepts & =
GENERAL2_INTERCEPT_VMRUN) =3D=3D 0) {=0A-        PRINTF("GENERAL2_INTERCEPT=
: VMRUN intercept bit is clear (0x%"PRIx32")\n",=0A+        PRINTF("GENERAL=
2_INTERCEPT: VMRUN intercept bit is clear (%#"PRIx32")\n",=0A             =
vmcb->_general2_intercepts);=0A     }=0A =0A     if (vmcb->eventinj.fields.=
resvd1 !=3D 0) {=0A-        PRINTF("eventinj: MBZ bits are set (0x%"PRIx64"=
)\n",=0A+        PRINTF("eventinj: MBZ bits are set (%#"PRIx64")\n",=0A    =
             vmcb->eventinj.bytes);=0A     }=0A =0A--- 2012-09-21.orig/xen/=
arch/x86/hvm/vlapic.c	2012-09-20 08:44:38.000000000 +0200=0A+++ =
2012-09-21/xen/arch/x86/hvm/vlapic.c	2012-09-21 10:54:46.000000000 =
+0200=0A@@ -172,7 +172,7 @@ static uint32_t vlapic_get_ppr(struct vl=0A    =
     ppr =3D isrv & 0xf0;=0A =0A     HVM_DBG_LOG(DBG_LEVEL_VLAPIC_INTERRUPT=
,=0A-                "vlapic %p, ppr 0x%x, isr 0x%x, isrv 0x%x",=0A+       =
         "vlapic %p, ppr %#x, isr %#x, isrv %#x",=0A                 =
vlapic, ppr, isr, isrv);=0A =0A     return ppr;=0A@@ -215,8 +215,8 @@ =
bool_t vlapic_match_dest(=0A     struct vlapic *target, struct vlapic =
*source,=0A     int short_hand, uint8_t dest, uint8_t dest_mode)=0A {=0A-  =
  HVM_DBG_LOG(DBG_LEVEL_VLAPIC, "target %p, source %p, dest 0x%x, "=0A-    =
            "dest_mode 0x%x, short_hand 0x%x",=0A+    HVM_DBG_LOG(DBG_LEVEL=
_VLAPIC, "target %p, source %p, dest %#x, "=0A+                "dest_mode =
%#x, short_hand %#x",=0A                 target, source, dest, dest_mode, =
short_hand);=0A =0A     switch ( short_hand )=0A@@ -562,20 +562,20 @@ =
static int vlapic_read(=0A         break;=0A =0A     default:=0A-        =
gdprintk(XENLOG_ERR, "Local APIC read with len=3D0x%lx, "=0A+        =
gdprintk(XENLOG_ERR, "Local APIC read with len=3D%#lx, "=0A                =
  "should be 4 instead.\n", len);=0A         goto exit_and_crash;=0A     =
}=0A =0A-    HVM_DBG_LOG(DBG_LEVEL_VLAPIC, "offset 0x%x with length 0x%lx, =
"=0A-                "and the result is 0x%lx", offset, len, result);=0A+  =
  HVM_DBG_LOG(DBG_LEVEL_VLAPIC, "offset %#x with length %#lx, "=0A+        =
        "and the result is %#lx", offset, len, result);=0A =0A  out:=0A    =
 *pval =3D result;=0A     return X86EMUL_OKAY;=0A =0A  unaligned_exit_and_c=
rash:=0A-    gdprintk(XENLOG_ERR, "Unaligned LAPIC read len=3D0x%lx at =
offset=3D0x%x.\n",=0A+    gdprintk(XENLOG_ERR, "Unaligned LAPIC read =
len=3D%#lx at offset=3D%#x.\n",=0A              len, offset);=0A  =
exit_and_crash:=0A     domain_crash(v->domain);=0A@@ -759,7 +759,7 @@ =
static int vlapic_reg_write(struct vcpu =0A =0A     case APIC_TDCR:=0A     =
    vlapic_set_tdcr(vlapic, val & 0xb);=0A-        HVM_DBG_LOG(DBG_LEVEL_VL=
APIC_TIMER, "timer divisor is 0x%x",=0A+        HVM_DBG_LOG(DBG_LEVEL_VLAPI=
C_TIMER, "timer divisor is %#x",=0A                     vlapic->hw.timer_di=
visor);=0A         break;=0A =0A@@ -768,7 +768,7 @@ static int vlapic_reg_w=
rite(struct vcpu =0A     }=0A     if (rc =3D=3D X86EMUL_UNHANDLEABLE)=0A   =
      gdprintk(XENLOG_DEBUG,=0A-                "Local APIC Write wrong to =
register 0x%x\n", offset);=0A+                "Local APIC Write wrong to =
register %#x\n", offset);=0A     return rc;=0A }=0A =0A@@ -781,7 +781,7 @@ =
static int vlapic_write(struct vcpu *v, =0A =0A     if ( offset !=3D 0xb0 =
)=0A         HVM_DBG_LOG(DBG_LEVEL_VLAPIC,=0A-                    "offset =
0x%x with length 0x%lx, and value is 0x%lx",=0A+                    =
"offset %#x with length %#lx, and value is %#lx",=0A                     =
offset, len, val);=0A =0A     /*=0A@@ -827,7 +827,7 @@ static int =
vlapic_write(struct vcpu *v, =0A     return vlapic_reg_write(v, offset, =
val);=0A =0A  unaligned_exit_and_crash:=0A-    gdprintk(XENLOG_ERR, =
"Unaligned LAPIC write len=3D0x%lx at offset=3D0x%x.\n",=0A+    gdprintk(XE=
NLOG_ERR, "Unaligned LAPIC write len=3D%#lx at offset=3D%#x.\n",=0A        =
      len, offset);=0A  exit_and_crash:=0A     domain_crash(v->domain);=0A-=
-- 2012-09-21.orig/xen/arch/x86/hvm/vmx/vmcs.c	2012-09-20 08:44:38.0000000=
00 +0200=0A+++ 2012-09-21/xen/arch/x86/hvm/vmx/vmcs.c	2012-09-21 =
10:54:46.000000000 +0200=0A@@ -121,7 +121,7 @@ static u32 adjust_vmx_contro=
ls(=0A static bool_t cap_check(const char *name, u32 expected, u32 saw)=0A =
{=0A     if ( saw !=3D expected )=0A-        printk("VMX %s: saw 0x%08x =
expected 0x%08x\n", name, saw, expected);=0A+        printk("VMX %s: saw =
%#x expected %#x\n", name, saw, expected);=0A     return saw !=3D =
expected;=0A }=0A =0A--- 2012-09-21.orig/xen/arch/x86/hvm/vmx/vmx.c	=
2012-09-20 08:44:38.000000000 +0200=0A+++ 2012-09-21/xen/arch/x86/hvm/vmx/v=
mx.c	2012-09-21 11:01:46.000000000 +0200=0A@@ -210,7 +210,7 @@ =
long_mode_do_msr_read(unsigned int msr, =0A         return HNDL_unhandled;=
=0A     }=0A =0A-    HVM_DBG_LOG(DBG_LEVEL_0, "msr 0x%x content 0x%"PRIx64,=
 msr, *msr_content);=0A+    HVM_DBG_LOG(DBG_LEVEL_0, "msr %#x content =
%#"PRIx64, msr, *msr_content);=0A =0A     return HNDL_done;=0A }=0A@@ =
-222,7 +222,7 @@ long_mode_do_msr_write(unsigned int msr,=0A     struct =
vmx_msr_state *guest_msr_state =3D &v->arch.hvm_vmx.msr_state;=0A     =
struct vmx_msr_state *host_msr_state =3D &this_cpu(host_msr_state);=0A =
=0A-    HVM_DBG_LOG(DBG_LEVEL_0, "msr 0x%x content 0x%"PRIx64, msr, =
msr_content);=0A+    HVM_DBG_LOG(DBG_LEVEL_0, "msr %#x content %#"PRIx64, =
msr, msr_content);=0A =0A     switch ( msr )=0A     {=0A@@ -466,7 +466,7 =
@@ static int vmx_restore_cr0_cr3(=0A                                      =
NULL, P2M_ALLOC);=0A             if ( !page )=0A             {=0A-         =
       gdprintk(XENLOG_ERR, "Invalid CR3 value=3D0x%lx\n", cr3);=0A+       =
         gdprintk(XENLOG_ERR, "Invalid CR3 value=3D%#lx\n", cr3);=0A       =
          return -EINVAL;=0A             }=0A         }=0A@@ -492,7 +492,7 =
@@ static int vmx_vmcs_restore(struct vcpu =0A          ((c->pending_type =
=3D=3D 1) || (c->pending_type > 6) ||=0A           (c->pending_reserved =
!=3D 0)) )=0A     {=0A-        gdprintk(XENLOG_ERR, "Invalid pending event =
0x%"PRIx32".\n",=0A+        gdprintk(XENLOG_ERR, "Invalid pending event =
%#"PRIx32".\n",=0A                  c->pending_event);=0A         return =
-EINVAL;=0A     }=0A@@ -524,7 +524,7 @@ static int vmx_vmcs_restore(struct =
vcpu =0A =0A     if ( c->pending_valid )=0A     {=0A-        gdprintk(XENLO=
G_INFO, "Re-injecting 0x%"PRIx32", 0x%"PRIx32"\n",=0A+        gdprintk(XENL=
OG_INFO, "Re-injecting %#"PRIx32", %#"PRIx32"\n",=0A                  =
c->pending_event, c->error_code);=0A =0A         if ( hvm_event_needs_reinj=
ection(c->pending_type, c->pending_vector) )=0A@@ -1789,7 +1789,7 @@ =
static int is_last_branch_msr(u32 ecx)=0A =0A static int vmx_msr_read_inter=
cept(unsigned int msr, uint64_t *msr_content)=0A {=0A-    HVM_DBG_LOG(DBG_L=
EVEL_1, "ecx=3D%x", msr);=0A+    HVM_DBG_LOG(DBG_LEVEL_1, "ecx=3D%#x", =
msr);=0A =0A     switch ( msr )=0A     {=0A@@ -1854,7 +1854,7 @@ static =
int vmx_msr_read_intercept(unsign=0A     }=0A =0A done:=0A-    HVM_DBG_LOG(=
DBG_LEVEL_1, "returns: ecx=3D%x, msr_value=3D0x%"PRIx64,=0A+    HVM_DBG_LOG=
(DBG_LEVEL_1, "returns: ecx=3D%#x, msr_value=3D%#"PRIx64,=0A               =
  msr, *msr_content);=0A     return X86EMUL_OKAY;=0A =0A@@ -1927,8 +1927,7 =
@@ static int vmx_msr_write_intercept(unsig=0A {=0A     struct vcpu *v =3D =
current;=0A =0A-    HVM_DBG_LOG(DBG_LEVEL_1, "ecx=3D%x, msr_value=3D0x%"PRI=
x64,=0A-                msr, msr_content);=0A+    HVM_DBG_LOG(DBG_LEVEL_1, =
"ecx=3D%#x, msr_value=3D%#"PRIx64, msr, msr_content);=0A =0A     switch ( =
msr )=0A     {=0A@@ -2107,7 +2106,7 @@ static void vmx_failed_vmentry(unsig=
ned =0A     unsigned long exit_qualification =3D __vmread(EXIT_QUALIFICATIO=
N);=0A     struct vcpu *curr =3D current;=0A =0A-    printk("Failed vm =
entry (exit reason 0x%x) ", exit_reason);=0A+    printk("Failed vm entry =
(exit reason %#x) ", exit_reason);=0A     switch ( failed_vmentry_reason =
)=0A     {=0A     case EXIT_REASON_INVALID_GUEST_STATE:=0A--- 2012-09-21.or=
ig/xen/arch/x86/io_apic.c	2012-09-21 10:32:44.000000000 +0200=0A+++ =
2012-09-21/xen/arch/x86/io_apic.c	2012-09-21 10:54:46.000000000 =
+0200=0A@@ -2204,7 +2204,7 @@ int io_apic_set_pci_routing (int ioapic,=0A  =
   entry.vector =3D vector;=0A =0A     apic_printk(APIC_DEBUG, KERN_DEBUG =
"IOAPIC[%d]: Set PCI routing entry "=0A-		"(%d-%d -> 0x%x -> =
IRQ %d Mode:%i Active:%i)\n", ioapic,=0A+		"(%d-%d -> %#x -> =
IRQ %d Mode:%i Active:%i)\n", ioapic,=0A 		mp_ioapics[ioapic].=
mpc_apicid, pin, entry.vector, irq,=0A 		edge_level, active_high_low=
);=0A =0A--- 2012-09-21.orig/xen/arch/x86/microcode_amd.c	2012-02-10 =
11:25:54.000000000 +0100=0A+++ 2012-09-21/xen/arch/x86/microcode_amd.c	=
2012-09-21 10:54:46.000000000 +0200=0A@@ -88,7 +88,7 @@ static int =
collect_cpu_info(int cpu, str=0A =0A     rdmsrl(MSR_AMD_PATCHLEVEL, =
csig->rev);=0A =0A-    printk(KERN_DEBUG "microcode: collect_cpu_info: =
patch_id=3D0x%x\n",=0A+    printk(KERN_DEBUG "microcode: collect_cpu_info: =
patch_id=3D%#x\n",=0A            csig->rev);=0A =0A     return 0;=0A@@ =
-132,7 +132,7 @@ static int microcode_fits(const struct m=0A         =
return 0;=0A =0A     printk(KERN_DEBUG "microcode: CPU%d found a matching =
microcode "=0A-           "update with version 0x%x (current=3D0x%x)\n",=0A=
+           "update with version %#x (current=3D%#x)\n",=0A            =
cpu, mc_header->patch_id, uci->cpu_sig.rev);=0A =0A     return 1;=0A@@ =
-169,7 +169,7 @@ static int apply_microcode(int cpu)=0A     if ( rev !=3D =
hdr->patch_id )=0A     {=0A         printk(KERN_ERR "microcode: CPU%d =
update from revision "=0A-               "0x%x to 0x%x failed\n", cpu, =
hdr->patch_id, rev);=0A+               "%#x to %#x failed\n", cpu, =
hdr->patch_id, rev);=0A         return -EIO;=0A     }=0A =0A--- 2012-09-21.=
orig/xen/arch/x86/microcode_intel.c	2011-12-12 09:01:34.000000000 =
+0100=0A+++ 2012-09-21/xen/arch/x86/microcode_intel.c	2012-09-21 =
10:54:46.000000000 +0200=0A@@ -122,7 +122,7 @@ static int collect_cpu_info(=
int cpu_num,=0A     /* get the current revision from MSR 0x8B */=0A     =
rdmsrl(MSR_IA32_UCODE_REV, msr_content);=0A     csig->rev =3D (uint32_t)(ms=
r_content >> 32);=0A-    pr_debug("microcode: collect_cpu_info : sig=3D0x%x=
, pf=3D0x%x, rev=3D0x%x\n",=0A+    pr_debug("microcode: collect_cpu_info : =
sig=3D%#x, pf=3D%#x, rev=3D%#x\n",=0A              csig->sig, csig->pf, =
csig->rev);=0A =0A     return 0;=0A@@ -264,7 +264,7 @@ static int =
get_matching_microcode(const =0A     if ( uci->mc.mc_intel && uci->mc.mc_in=
tel->hdr.rev >=3D mc_header->rev )=0A         return 0;=0A     pr_debug("mi=
crocode: CPU%d found a matching microcode update with"=0A-             " =
version 0x%x (current=3D0x%x)\n",=0A+             " version %#x (current=3D=
%#x)\n",=0A              cpu, mc_header->rev, uci->cpu_sig.rev);=0A     =
new_mc =3D xmalloc_bytes(total_size);=0A     if ( new_mc =3D=3D NULL =
)=0A@@ -311,11 +311,11 @@ static int apply_microcode(int cpu)=0A     if ( =
val[1] !=3D uci->mc.mc_intel->hdr.rev )=0A     {=0A         printk(KERN_ERR=
 "microcode: CPU%d update from revision "=0A-               "0x%x to 0x%x =
failed\n", cpu_num, uci->cpu_sig.rev, val[1]);=0A+               "%#x to =
%#x failed\n", cpu_num, uci->cpu_sig.rev, val[1]);=0A         return =
-EIO;=0A     }=0A     printk(KERN_INFO "microcode: CPU%d updated from =
revision "=0A-           "0x%x to 0x%x, date =3D %04x-%02x-%02x \n",=0A+   =
        "%#x to %#x, date =3D %04x-%02x-%02x \n",=0A            cpu_num, =
uci->cpu_sig.rev, val[1],=0A            uci->mc.mc_intel->hdr.date & =
0xffff,=0A            uci->mc.mc_intel->hdr.date >> 24,=0A--- 2012-09-21.or=
ig/xen/arch/x86/mm.c	2012-09-14 13:26:34.000000000 +0200=0A+++ =
2012-09-21/xen/arch/x86/mm.c	2012-09-21 10:54:46.000000000 +0200=0A@@ =
-3102,7 +3102,7 @@ long do_mmuext_op(=0A         }=0A =0A         =
default:=0A-            MEM_LOG("Invalid extended pt command 0x%x", =
op.cmd);=0A+            MEM_LOG("Invalid extended pt command %#x", =
op.cmd);=0A             rc =3D -ENOSYS;=0A             okay =3D 0;=0A      =
       break;=0A--- 2012-09-21.orig/xen/arch/x86/mm/hap/nested_hap.c	=
2012-08-08 08:20:09.000000000 +0200=0A+++ 2012-09-21/xen/arch/x86/mm/hap/ne=
sted_hap.c	2012-09-21 10:54:46.000000000 +0200=0A@@ -129,7 +129,7 @@ =
nestedhap_fix_p2m(struct vcpu *v, struct=0A =0A     if (rv =3D=3D 0) {=0A  =
       gdprintk(XENLOG_ERR,=0A-		"failed to set entry for 0x%"PRIx64=
" -> 0x%"PRIx64"\n",=0A+		"failed to set entry for %#"PRIx64"=
 -> %#"PRIx64"\n",=0A 		L2_gpa, L0_gpa);=0A         BUG();=0A     =
}=0A--- 2012-09-21.orig/xen/arch/x86/mm/p2m-pt.c	2012-09-14 =
13:26:34.000000000 +0200=0A+++ 2012-09-21/xen/arch/x86/mm/p2m-pt.c	=
2012-09-21 10:54:46.000000000 +0200=0A@@ -110,8 +110,8 @@ p2m_find_entry(vo=
id *table, unsigned lon=0A     index =3D *gfn_remainder >> shift;=0A     =
if ( index >=3D max )=0A     {=0A-        P2M_DEBUG("gfn=3D0x%lx out of =
range "=0A-                  "(gfn_remainder=3D0x%lx shift=3D%d index=3D0x%=
x max=3D0x%x)\n",=0A+        P2M_DEBUG("gfn=3D%#lx out of range "=0A+      =
            "(gfn_remainder=3D%#lx shift=3D%d index=3D%#x max=3D%#x)\n",=0A=
                   gfn, *gfn_remainder, shift, index, max);=0A         =
return NULL;=0A     }=0A--- 2012-09-21.orig/xen/arch/x86/mm/shadow/common.c=
	2012-09-14 13:26:34.000000000 +0200=0A+++ 2012-09-21/xen/arch/x86/m=
m/shadow/common.c	2012-09-21 10:57:38.000000000 +0200=0A@@ -872,7 =
+872,7 @@ static int sh_skip_sync(struct vcpu *v, =0A         return =
SHADOW_INTERNAL_NAME(sh_safe_not_to_sync, 3)(v, gl1mfn);=0A     else if ( =
pg->shadow_flags & SHF_L1_64 )=0A         return SHADOW_INTERNAL_NAME(sh_sa=
fe_not_to_sync, 4)(v, gl1mfn);=0A-    SHADOW_ERROR("gmfn 0x%lx was OOS but =
not shadowed as an l1.\n", =0A+    SHADOW_ERROR("gmfn %#lx was OOS but not =
shadowed as an l1.\n",=0A                  mfn_x(gl1mfn));=0A     =
BUG();=0A     return 0; /* BUG() is no longer __attribute__((noreturn)). =
*/=0A@@ -2596,8 +2596,8 @@ void sh_remove_shadows(struct vcpu *v, m=0A     =
smfn =3D shadow_hash_lookup(v, mfn_x(gmfn), t);                       \=0A =
    if ( unlikely(!mfn_valid(smfn)) )                                   =
\=0A     {                                                                 =
  \=0A-        SHADOW_ERROR(": gmfn %#lx has flags 0x%"PRIx32              =
    \=0A-                     " but no type-0x%"PRIx32" shadow\n",         =
      \=0A+        SHADOW_ERROR(": gmfn %#lx has flags %#"PRIx32           =
        \=0A+                     " but no type-%#"PRIx32" shadow\n",      =
          \=0A                      mfn_x(gmfn), (uint32_t)pg->shadow_flags=
, t);       \=0A         break;                                            =
              \=0A     }                                                   =
                \=0A--- 2012-09-21.orig/xen/arch/x86/mm/shadow/multi.c	=
2012-09-14 13:26:34.000000000 +0200=0A+++ 2012-09-21/xen/arch/x86/mm/shadow=
/multi.c	2012-09-21 10:54:46.000000000 +0200=0A@@ -2171,7 +2171,7 =
@@ static int validate_gl4e(struct vcpu *v,=0A             // attempt by =
the guest to write to a xen reserved slot=0A             //=0A             =
SHADOW_PRINTK("%s out-of-range update "=0A-                           =
"sl4mfn=3D%05lx index=3D0x%x val=3D%" SH_PRI_pte "\n",=0A+                 =
          "sl4mfn=3D%05lx index=3D%#x val=3D%" SH_PRI_pte "\n",=0A         =
                   __func__, mfn_x(sl4mfn), shadow_index, new_sl4e.l4);=0A =
            if ( shadow_l4e_get_flags(new_sl4e) & _PAGE_PRESENT )=0A       =
      {=0A--- 2012-09-21.orig/xen/arch/x86/mpparse.c	2012-04-20 =
09:49:25.000000000 +0200=0A+++ 2012-09-21/xen/arch/x86/mpparse.c	=
2012-09-21 10:54:46.000000000 +0200=0A@@ -216,7 +216,7 @@ static void =
__init MP_ioapic_info (struc=0A 	if (!(m->mpc_flags & MPC_APIC_USABL=
E))=0A 		return;=0A =0A-	printk(KERN_INFO "I/O APIC #%d Version %d =
at 0x%X.\n",=0A+	printk(KERN_INFO "I/O APIC #%d Version %d at =
%#x.\n",=0A 		m->mpc_apicid, m->mpc_apicver, m->mpc_apicaddr);=0A=
 	if (nr_ioapics >=3D MAX_IO_APICS) {=0A 		printk(KERN_CRIT =
"Max # of I/O APICs (%d) exceeded (found %d).\n",=0A@@ -278,7 +278,7 @@ =
static int __init smp_read_mpc(struct mp=0A 	unsigned char *mpt=3D((unsi=
gned char *)mpc)+count;=0A =0A 	if (memcmp(mpc->mpc_signature,MPC_SIGNATURE=
,4)) {=0A-		printk(KERN_ERR "SMP mptable: bad signature =
[0x%x]!\n",=0A+		printk(KERN_ERR "SMP mptable: bad signature =
[%#x]!\n",=0A 			*(u32 *)mpc->mpc_signature);=0A 		=
return 0;=0A 	}=0A@@ -305,7 +305,7 @@ static int __init smp_read_mpc(stru=
ct mp=0A =0A 	mps_oem_check(mpc, oem, str);=0A =0A-	printk("APIC at: =
0x%X\n",mpc->mpc_lapic);=0A+	printk("APIC at: %#x\n", mpc->mpc_lapic);=
=0A =0A 	/* =0A 	 * Save the local APIC address (it might be =
non-default) -- but only=0A@@ -881,7 +881,7 @@ void __init mp_register_ioap=
ic (=0A 	mp_ioapic_routing[idx].gsi_end =3D gsi_base + =0A 		=
io_apic_get_redir_entries(idx);=0A =0A-	printk("IOAPIC[%d]: apic_id %d, =
version %d, address 0x%x, "=0A+	printk("IOAPIC[%d]: apic_id %d, version =
%d, address %#x, "=0A 		"GSI %d-%d\n", idx, mp_ioapics[idx].mpc_api=
cid, =0A 		mp_ioapics[idx].mpc_apicver, mp_ioapics[idx].mpc_ap=
icaddr,=0A 		mp_ioapic_routing[idx].gsi_base,=0A--- 2012-09-21.o=
rig/xen/arch/x86/nmi.c	2012-08-08 08:20:09.000000000 +0200=0A+++ =
2012-09-21/xen/arch/x86/nmi.c	2012-09-21 10:54:46.000000000 +0200=0A@@ =
-245,7 +245,7 @@ static inline void write_watchdog_counte=0A =0A     =
do_div(count, nmi_hz);=0A     if(descr)=0A-        Dprintk("setting %s to =
-0x%"PRIx64"\n", descr, count);=0A+        Dprintk("setting %s to =
-%#"PRIx64"\n", descr, count);=0A     wrmsrl(nmi_perfctr_msr, 0 - =
count);=0A }=0A =0A--- 2012-09-21.orig/xen/arch/x86/oprofile/op_model_athlo=
n.c	2012-09-14 13:26:34.000000000 +0200=0A+++ 2012-09-21/xen/arch/x86/o=
profile/op_model_athlon.c	2012-09-21 10:54:46.000000000 +0200=0A@@ =
-478,7 +478,7 @@ static int __init init_ibs_nmi(void)=0A 			=
		if (value !=3D (IBSCTL_LVTOFFSETVAL |=0A 			=
			APIC_EILVT_LVTOFF_IBS)) {=0A 				=
		printk("Xenoprofile: Failed to setup IBS LVT offset, "=0A-	=
						"IBSCTL =3D %#08x\n", =
value);=0A+							"IBSCTL =
=3D %#x\n", value);=0A 						return =
1;=0A 					}=0A 					=
nodes++;=0A@@ -523,7 +523,7 @@ void __init ibs_init(void)=0A 		=
return;=0A 	}=0A =0A-	printk("Xenoprofile: AMD IBS detected =
(0x%08x)\n",=0A+	printk("Xenoprofile: AMD IBS detected (%#x)\n",=0A =
		(unsigned)ibs_caps);=0A }=0A =0A--- 2012-09-21.orig/xen/arc=
h/x86/oprofile/op_model_p4.c	2012-02-10 11:25:54.000000000 +0100=0A+++ =
2012-09-21/xen/arch/x86/oprofile/op_model_p4.c	2012-09-21 10:54:46.0000000=
00 +0200=0A@@ -485,8 +485,7 @@ static void pmc_setup_one_p4_counter(uns=0A =
	=0A 	/* find our event binding structure. */=0A 	if =
(counter_config[ctr].event <=3D 0 || counter_config[ctr].event > NUM_EVENTS=
) {=0A-		printk(KERN_ERR =0A-		       "oprofile: P4 event =
code 0x%lx out of range\n", =0A+		printk(KERN_ERR "oprofile: =
P4 event code %#lx out of range\n",=0A 		       counter_config[ctr].=
event);=0A 		return;=0A 	}=0A@@ -526,7 +525,7 @@ static =
void pmc_setup_one_p4_counter(uns=0A 	}=0A =0A 	printk(KERN_ERR =
=0A-	       "oprofile: P4 event code 0x%lx no binding, stag %d ctr =
%d\n",=0A+	       "oprofile: P4 event code %#lx no binding, stag %d =
ctr %d\n",=0A 	       counter_config[ctr].event, stag, ctr);=0A }=0A =
=0A--- 2012-09-21.orig/xen/arch/x86/setup.c	2012-09-17 09:57:54.0000000=
00 +0200=0A+++ 2012-09-21/xen/arch/x86/setup.c	2012-09-21 11:01:12.0000000=
00 +0200=0A@@ -482,13 +482,13 @@ static void __init kexec_reserve_area(st=
=0A =0A     if ( !reserve_e820_ram(e820, kdump_start, kdump_start + =
kdump_size) )=0A     {=0A-        printk("Kdump: DISABLED (failed to =
reserve %luMB (%lukB) at 0x%lx)"=0A+        printk("Kdump: DISABLED =
(failed to reserve %luMB (%lukB) at %#lx)"=0A                "\n", =
kdump_size >> 20, kdump_size >> 10, kdump_start);=0A         kexec_crash_ar=
ea.start =3D kexec_crash_area.size =3D 0;=0A     }=0A     else=0A     =
{=0A-        printk("Kdump: %luMB (%lukB) at 0x%lx\n",=0A+        =
printk("Kdump: %luMB (%lukB) at %#lx\n",=0A                kdump_size >> =
20, kdump_size >> 10, kdump_start);=0A     }=0A }=0A--- 2012-09-21.orig/xen=
/arch/x86/tboot.c	2012-01-20 10:10:22.000000000 +0100=0A+++ =
2012-09-21/xen/arch/x86/tboot.c	2012-09-21 10:54:46.000000000 +0200=0A@@ =
-119,12 +119,12 @@ void __init tboot_probe(void)=0A     g_tboot_shared =3D =
tboot_shared;=0A     printk("TBOOT: found shared page at phys addr =
%lx:\n", p_tboot_shared);=0A     printk("  version: %d\n", tboot_shared->ve=
rsion);=0A-    printk("  log_addr: 0x%08x\n", tboot_shared->log_addr);=0A- =
   printk("  shutdown_entry: 0x%08x\n", tboot_shared->shutdown_entry);=0A- =
   printk("  tboot_base: 0x%08x\n", tboot_shared->tboot_base);=0A-    =
printk("  tboot_size: 0x%x\n", tboot_shared->tboot_size);=0A+    printk("  =
log_addr: %#x\n", tboot_shared->log_addr);=0A+    printk("  shutdown_entry:=
 %#x\n", tboot_shared->shutdown_entry);=0A+    printk("  tboot_base: =
%#x\n", tboot_shared->tboot_base);=0A+    printk("  tboot_size: %#x\n", =
tboot_shared->tboot_size);=0A     if ( tboot_shared->version >=3D 6 )=0A-  =
      printk("  flags: 0x%08x\n", tboot_shared->flags);=0A+        =
printk("  flags: %#x\n", tboot_shared->flags);=0A =0A     /* these will be =
needed by tboot_protect_mem_regions() and/or=0A        tboot_parse_dmar_tab=
le(), so get them now */=0A@@ -352,7 +352,7 @@ void tboot_shutdown(uint32_t=
 shutdown_ty=0A                            __PAGE_HYPERVISOR);=0A     if ( =
err !=3D 0 )=0A     {=0A-        printk("error (0x%x) mapping tboot pages =
(mfns) @ 0x%x, 0x%x\n", err,=0A+        printk("error (%#x) mapping tboot =
pages (mfns) @ %#x, %#x\n", err,=0A                map_base, map_size);=0A =
        return;=0A     }=0A--- 2012-09-21.orig/xen/arch/x86/time.c	=
2012-09-14 13:26:34.000000000 +0200=0A+++ 2012-09-21/xen/arch/x86/time.c	=
2012-09-21 10:54:46.000000000 +0200=0A@@ -1955,11 +1955,11 @@ static void =
dump_softtsc(unsigned char k=0A         printk("dom%u%s: mode=3D%d",d->doma=
in_id,=0A                 is_hvm_domain(d) ? "(hvm)" : "", d->arch.tsc_mode=
);=0A         if ( d->arch.vtsc_offset )=0A-            printk(",ofs=3D0x%"=
PRIx64"",d->arch.vtsc_offset);=0A+            printk(",ofs=3D%#"PRIx64, =
d->arch.vtsc_offset);=0A         if ( d->arch.tsc_khz )=0A-            =
printk(",khz=3D%"PRIu32"",d->arch.tsc_khz);=0A+            printk(",khz=3D%=
"PRIu32, d->arch.tsc_khz);=0A         if ( d->arch.incarnation )=0A-       =
     printk(",inc=3D%"PRIu32"",d->arch.incarnation);=0A+            =
printk(",inc=3D%"PRIu32, d->arch.incarnation);=0A         if ( !(d->arch.vt=
sc_kerncount | d->arch.vtsc_usercount) )=0A         {=0A             =
printk("\n");=0A--- 2012-09-21.orig/xen/arch/x86/xstate.c	2012-01-30 =
10:46:14.000000000 +0100=0A+++ 2012-09-21/xen/arch/x86/xstate.c	2012-09-21 =
10:54:46.000000000 +0200=0A@@ -163,7 +163,7 @@ void xstate_init(void)=0A   =
      xsave_cntxt_size =3D ebx;=0A         xfeature_mask =3D eax + =
((u64)edx << 32);=0A         xfeature_mask &=3D XCNTXT_MASK;=0A-        =
printk("%s: using cntxt_size: 0x%x and states: 0x%"PRIx64"\n",=0A+        =
printk("%s: using cntxt_size: %#x and states: %#"PRIx64"\n",=0A            =
 __func__, xsave_cntxt_size, xfeature_mask);=0A =0A         /* Check =
XSAVEOPT feature. */=0A--- 2012-09-21.orig/xen/common/gdbstub.c	2010-05-20 =
09:59:27.000000000 +0200=0A+++ 2012-09-21/xen/common/gdbstub.c	2012-09-21 =
10:54:46.000000000 +0200=0A@@ -263,7 +263,7 @@ gdb_write_to_packet_hex(unsi=
gned long x,=0A     case sizeof(u64):=0A         break;=0A     default:=0A-=
        dbg_printk("WARNING: %s x: 0x%lx int_size: %d\n",=0A+        =
dbg_printk("WARNING: %s x: %#lx int_size: %d\n",=0A                    =
__func__, x, int_size);=0A         break;=0A     }=0A--- 2012-09-21.orig/xe=
n/common/page_alloc.c	2012-09-14 13:26:34.000000000 +0200=0A+++ =
2012-09-21/xen/common/page_alloc.c	2012-09-21 10:54:46.000000000 =
+0200=0A@@ -367,7 +367,7 @@ static void __init setup_low_mem_virq(vo=0A    =
 low_mem_virq_th =3D low_mem_virq_orig =3D 1UL << order;=0A     low_mem_vir=
q_th_order =3D order;=0A =0A-    printk("Initial low memory virq threshold =
set at 0x%lx pages.\n",=0A+    printk("Initial low memory virq threshold =
set at %#lx pages.\n",=0A             low_mem_virq_th);=0A }=0A =0A--- =
2012-09-21.orig/xen/common/vsprintf.c	2012-02-10 11:25:54.000000000 =
+0100=0A+++ 2012-09-21/xen/common/vsprintf.c	2012-09-21 10:54:46.0000000=
00 +0200=0A@@ -171,10 +171,14 @@ static char *number(=0A         }=0A     =
}=0A     if (type & SPECIAL) {=0A-        if (base =3D=3D 16)=0A+        =
if (num =3D=3D 0)=0A+            type &=3D ~SPECIAL;=0A+        else if =
(base =3D=3D 16)=0A             size -=3D 2;=0A         else if (base =
=3D=3D 8)=0A             size--;=0A+        else=0A+            type &=3D =
~SPECIAL;=0A     }=0A     i =3D 0;=0A     if (num =3D=3D 0)=0A@@ -197,14 =
+201,10 @@ static char *number(=0A         ++buf;=0A     }=0A     if (type =
& SPECIAL) {=0A-        if (base=3D=3D8) {=0A-            if (buf <=3D =
end)=0A-                *buf =3D '0';=0A-            ++buf;=0A-        } =
else if (base=3D=3D16) {=0A-            if (buf <=3D end)=0A-              =
  *buf =3D '0';=0A-            ++buf;=0A+        if (buf <=3D end)=0A+     =
       *buf =3D '0';=0A+        ++buf;=0A+        if (base =3D=3D 16) {=0A =
            if (buf <=3D end)=0A                 *buf =3D digits[33];=0A   =
          ++buf;=0A--- 2012-09-21.orig/xen/common/xencomm.c	2012-01-24 =
10:11:51.000000000 +0100=0A+++ 2012-09-21/xen/common/xencomm.c	2012-09-21 =
10:54:46.000000000 +0200=0A@@ -58,7 +58,7 @@ xencomm_get_page(unsigned =
long paddr, st=0A          * is freed with decrease reservation hypercall =
at the same time.=0A          */=0A         gdprintk(XENLOG_WARNING,=0A-   =
              "bad page is passed. paddr 0x%lx maddr 0x%lx\n",=0A+         =
        "bad page is passed. paddr %#lx maddr %#lx\n",=0A                  =
paddr, maddr);=0A         return -EFAULT;=0A     }=0A@@ -117,7 +117,7 @@ =
xencomm_ctxt_init(const void *handle, st=0A     desc =3D xencomm_vaddr((uns=
igned long)handle, page);=0A     if ( desc->magic !=3D XENCOMM_MAGIC )=0A  =
   {=0A-        printk("%s: error: %p magic was 0x%x\n", __func__, desc, =
desc->magic);=0A+        printk("%s: error: %p magic was %#x\n", __func__, =
desc, desc->magic);=0A         put_page(page);=0A         return =
-EINVAL;=0A     }=0A--- 2012-09-21.orig/xen/drivers/acpi/numa.c	2012-09-14 =
13:26:34.000000000 +0200=0A+++ 2012-09-21/xen/drivers/acpi/numa.c	=
2012-09-21 10:54:46.000000000 +0200=0A@@ -78,8 +78,8 @@ void __init =
acpi_table_print_srat_entry(=0A 			if (srat_rev < =
2)=0A 				proximity_domain &=3D 0xff;=0A 			=
ACPI_DEBUG_PRINT((ACPI_DB_INFO,=0A-					  =
"SRAT Memory (%#016"PRIx64=0A-					  " length =
%#016"PRIx64")"=0A+					  "SRAT Memory =
(%#"PRIx64=0A+					  " length %#"PRIx64")"=0A =
					  " in proximity domain %d =
%s%s\n",=0A 					  p->base_address, =
p->length,=0A 					  proximity_domain,=0A@@ =
-108,7 +108,7 @@ void __init acpi_table_print_srat_entry(=0A 		=
break;=0A 	default:=0A 		printk(KERN_WARNING PREFIX=0A-		=
       "Found unsupported SRAT entry (type =3D 0x%x)\n",=0A+		   =
    "Found unsupported SRAT entry (type =3D %#x)\n",=0A 		   =
    header->type);=0A 		break;=0A 	}=0A--- 2012-09-21.orig/xen=
/drivers/acpi/tables.c	2012-09-21 10:32:44.000000000 +0200=0A+++ =
2012-09-21/xen/drivers/acpi/tables.c	2012-09-21 10:54:46.000000000 =
+0200=0A@@ -95,7 +95,7 @@ void __init acpi_table_print_madt_entry(=0A 		=
	if (p->inti_flags  &=0A 			    ~(ACPI_MADT_POL=
ARITY_MASK | ACPI_MADT_TRIGGER_MASK))=0A 				=
printk(KERN_INFO PREFIX=0A-				       "INT_SRC_OVR=
 unexpected reserved flags: 0x%x\n",=0A+				   =
    "INT_SRC_OVR unexpected reserved flags: %#x\n",=0A 				=
       p->inti_flags  &=0A 					~(ACPI_MADT=
_POLARITY_MASK | ACPI_MADT_TRIGGER_MASK));=0A =0A@@ -119,7 +119,7 @@ void =
__init acpi_table_print_madt_entry(=0A 			struct acpi_madt_lo=
cal_apic_nmi *p =3D=0A 			    (struct acpi_madt_local_apic_nm=
i *)header;=0A 			printk(KERN_INFO PREFIX=0A-			=
       "LAPIC_NMI (acpi_id[0x%02x] %s %s lint[0x%x])\n",=0A+			=
       "LAPIC_NMI (acpi_id[0x%02x] %s %s lint[%#x])\n",=0A 			=
       p->processor_id,=0A 			       mps_inti_flags_polar=
ity[p->inti_flags & ACPI_MADT_POLARITY_MASK	],=0A 			   =
    mps_inti_flags_trigger[(p->inti_flags & ACPI_MADT_TRIGGER_MASK) >> =
2],=0A@@ -137,7 +137,7 @@ void __init acpi_table_print_madt_entry(=0A 		=
	trigger =3D (p->inti_flags & ACPI_MADT_TRIGGER_MASK) >> 2;=0A =0A 	=
		printk(KERN_INFO PREFIX=0A-			       =
"X2APIC_NMI (uid[0x%02x] %s %s lint[0x%x])\n",=0A+			   =
    "X2APIC_NMI (uid[0x%02x] %s %s lint[%#x])\n",=0A 			   =
    p->uid,=0A 			       mps_inti_flags_polarity[polarity],=
=0A 			       mps_inti_flags_trigger[trigger],=0A@@ =
-160,7 +160,7 @@ void __init acpi_table_print_madt_entry(=0A 			=
struct acpi_madt_io_sapic *p =3D=0A 			    (struct =
acpi_madt_io_sapic *)header;=0A 			printk(KERN_INFO =
PREFIX=0A-			       "IOSAPIC (id[0x%x] address[%p] =
gsi_base[%d])\n",=0A+			       "IOSAPIC (id[%#x] address[%p=
] gsi_base[%d])\n",=0A 			       p->id, (void *)(unsigned =
long)p->address,=0A 			       p->global_irq_base);=0A 		=
}=0A@@ -182,7 +182,7 @@ void __init acpi_table_print_madt_entry(=0A 		=
	struct acpi_madt_interrupt_source *p =3D=0A 			   =
 (struct acpi_madt_interrupt_source *)header;=0A 			=
printk(KERN_INFO PREFIX=0A-			       "PLAT_INT_SRC (%s =
%s type[0x%x] id[0x%04x] eid[0x%x] iosapic_vector[0x%x] global_irq[0x%x]\n"=
,=0A+			       "PLAT_INT_SRC (%s %s type[%#x] id[0x%04x] =
eid[%#x] iosapic_vector[%#x] global_irq[%#x]\n",=0A 			   =
    mps_inti_flags_polarity[p->inti_flags & ACPI_MADT_POLARITY_MASK],=0A 	=
		       mps_inti_flags_trigger[(p->inti_flags & ACPI_MADT_TR=
IGGER_MASK) >> 2],=0A 			       p->type, p->id, p->eid, =
p->io_sapic_vector,=0A@@ -192,7 +192,7 @@ void __init acpi_table_print_madt=
_entry(=0A =0A 	default:=0A 		printk(KERN_WARNING PREFIX=0A-		=
       "Found unsupported MADT entry (type =3D 0x%x)\n",=0A+		   =
    "Found unsupported MADT entry (type =3D %#x)\n",=0A 		   =
    header->type);=0A 		break;=0A 	}=0A@@ -242,7 +242,7 @@ =
acpi_table_parse_entries(char *id,=0A 		    ((unsigned long)entry =
+ entry->length);=0A 	}=0A 	if (max_entries && count > max_entries) =
{=0A-		printk(KERN_WARNING PREFIX "[%4.4s:0x%02x] ignored %i =
entries of "=0A+		printk(KERN_WARNING PREFIX "[%4.4s:%#x] =
ignored %i entries of "=0A 		       "%i found\n", id, entry_id, =
count - max_entries, count);=0A 	}=0A =0A--- 2012-09-21.orig/xen/dri=
vers/acpi/utilities/utglobal.c	2011-03-11 10:13:55.000000000 +0100=0A+++ =
2012-09-21/xen/drivers/acpi/utilities/utglobal.c	2012-09-21 =
10:54:46.000000000 +0200=0A@@ -79,7 +79,7 @@ const char *__init acpi_format=
_exception=0A 		/* Exception code was not recognized */=0A =0A 		=
ACPI_ERROR((AE_INFO,=0A-			    "Unknown exception =
code: 0x%8.8X", status));=0A+			    "Unknown exception =
code: %#X", status));=0A =0A 		exception =3D "UNKNOWN_STATUS_CODE"=
;=0A 		dump_execution_state();=0A--- 2012-09-21.orig/xen/drivers/c=
pufreq/cpufreq.c	2012-09-14 13:26:34.000000000 +0200=0A+++ =
2012-09-21/xen/drivers/cpufreq/cpufreq.c	2012-09-21 10:54:46.0000000=
00 +0200=0A@@ -377,7 +377,7 @@ static void print_PSS(struct xen_process=0A =
    printk("\t_PSS: state_count=3D%d\n", count);=0A     for (i=3D0; =
i<count; i++){=0A         printk("\tState%d: %"PRId64"MHz %"PRId64"mW =
%"PRId64"us "=0A-               "%"PRId64"us 0x%"PRIx64" 0x%"PRIx64"\n",=0A=
+               "%"PRId64"us %#"PRIx64" %#"PRIx64"\n",=0A                =
i,=0A                ptr[i].core_frequency,=0A                ptr[i].power,=
=0A--- 2012-09-21.orig/xen/drivers/passthrough/amd/iommu_acpi.c	2011-12-14 =
10:11:38.000000000 +0100=0A+++ 2012-09-21/xen/drivers/passthrough/amd/iommu=
_acpi.c	2012-09-21 10:54:46.000000000 +0200=0A@@ -196,7 +196,7 @@ static =
int __init register_exclusion_ran=0A     iommu =3D find_iommu_for_device(se=
g, bdf);=0A     if ( !iommu )=0A     {=0A-        AMD_IOMMU_DEBUG("IVMD =
Error: No IOMMU for Dev_Id 0x%x!\n", bdf);=0A+        AMD_IOMMU_DEBUG("IVMD=
 Error: No IOMMU for Dev_Id %#x!\n", bdf);=0A         return -ENODEV;=0A   =
  }=0A     req =3D ivrs_mappings[bdf].dte_requestor_id;=0A@@ -278,7 +278,7 =
@@ static int __init parse_ivmd_device_sele=0A     bdf =3D ivmd_block->head=
er.device_id;=0A     if ( bdf >=3D ivrs_bdf_entries )=0A     {=0A-        =
AMD_IOMMU_DEBUG("IVMD Error: Invalid Dev_Id 0x%x\n", bdf);=0A+        =
AMD_IOMMU_DEBUG("IVMD Error: Invalid Dev_Id %#x\n", bdf);=0A         =
return -ENODEV;=0A     }=0A =0A@@ -296,7 +296,7 @@ static int __init =
parse_ivmd_device_rang=0A     if ( first_bdf >=3D ivrs_bdf_entries )=0A    =
 {=0A         AMD_IOMMU_DEBUG("IVMD Error: "=0A-                        =
"Invalid Range_First Dev_Id 0x%x\n", first_bdf);=0A+                       =
 "Invalid Range_First Dev_Id %#x\n", first_bdf);=0A         return =
-ENODEV;=0A     }=0A =0A@@ -304,7 +304,7 @@ static int __init parse_ivmd_de=
vice_rang=0A     if ( (last_bdf >=3D ivrs_bdf_entries) || (last_bdf <=3D =
first_bdf) )=0A     {=0A         AMD_IOMMU_DEBUG("IVMD Error: "=0A-        =
                "Invalid Range_Last Dev_Id 0x%x\n", last_bdf);=0A+         =
               "Invalid Range_Last Dev_Id %#x\n", last_bdf);=0A         =
return -ENODEV;=0A     }=0A =0A@@ -326,7 +326,7 @@ static int __init =
parse_ivmd_device_iomm=0A                                     ivmd_block->a=
ux_data);=0A     if ( !iommu )=0A     {=0A-        AMD_IOMMU_DEBUG("IVMD =
Error: No IOMMU for Dev_Id 0x%x  Cap 0x%x\n",=0A+        AMD_IOMMU_DEBUG("I=
VMD Error: No IOMMU for Dev_Id %#x Cap %#x\n",=0A                         =
ivmd_block->header.device_id, ivmd_block->aux_data);=0A         return =
-ENODEV;=0A     }=0A@@ -351,9 +351,9 @@ static int __init parse_ivmd_block(=
const=0A     base =3D start_addr & PAGE_MASK;=0A     limit =3D (start_addr =
+ mem_length - 1) & PAGE_MASK;=0A =0A-    AMD_IOMMU_DEBUG("IVMD Block: =
Type 0x%x\n",ivmd_block->header.type);=0A-    AMD_IOMMU_DEBUG(" Start_Addr_=
Phys 0x%lx\n", start_addr);=0A-    AMD_IOMMU_DEBUG(" Mem_Length 0x%lx\n", =
mem_length);=0A+    AMD_IOMMU_DEBUG("IVMD Block: Type %#x\n",ivmd_block->he=
ader.type);=0A+    AMD_IOMMU_DEBUG(" Start_Addr_Phys %#lx\n", start_addr);=
=0A+    AMD_IOMMU_DEBUG(" Mem_Length %#lx\n", mem_length);=0A =0A     if ( =
ivmd_block->header.flags & ACPI_IVMD_EXCLUSION_RANGE )=0A         iw =3D =
ir =3D IOMMU_CONTROL_ENABLED;=0A@@ -414,7 +414,7 @@ static u16 __init =
parse_ivhd_device_sele=0A     bdf =3D select->header.id;=0A     if ( bdf =
>=3D ivrs_bdf_entries )=0A     {=0A-        AMD_IOMMU_DEBUG("IVHD Error: =
Invalid Device_Entry Dev_Id 0x%x\n", bdf);=0A+        AMD_IOMMU_DEBUG("IVHD=
 Error: Invalid Device_Entry Dev_Id %#x\n", bdf);=0A         return 0;=0A  =
   }=0A =0A@@ -439,7 +439,7 @@ static u16 __init parse_ivhd_device_rang=0A =
    if ( range->end.header.type !=3D ACPI_IVRS_TYPE_END )=0A     {=0A      =
   AMD_IOMMU_DEBUG("IVHD Error: "=0A-                        "Invalid =
Range: End_Type 0x%x\n",=0A+                        "Invalid Range: =
End_Type %#x\n",=0A                         range->end.header.type);=0A    =
     return 0;=0A     }=0A@@ -448,7 +448,7 @@ static u16 __init parse_ivhd_=
device_rang=0A     if ( first_bdf >=3D ivrs_bdf_entries )=0A     {=0A      =
   AMD_IOMMU_DEBUG("IVHD Error: "=0A-                        "Invalid =
Range: First Dev_Id 0x%x\n", first_bdf);=0A+                        =
"Invalid Range: First Dev_Id %#x\n", first_bdf);=0A         return 0;=0A   =
  }=0A =0A@@ -456,11 +456,11 @@ static u16 __init parse_ivhd_device_rang=0A=
     if ( (last_bdf >=3D ivrs_bdf_entries) || (last_bdf <=3D first_bdf) =
)=0A     {=0A         AMD_IOMMU_DEBUG("IVHD Error: "=0A-                   =
     "Invalid Range: Last Dev_Id 0x%x\n", last_bdf);=0A+                   =
     "Invalid Range: Last Dev_Id %#x\n", last_bdf);=0A         return =
0;=0A     }=0A =0A-    AMD_IOMMU_DEBUG(" Dev_Id Range: 0x%x -> 0x%x\n", =
first_bdf, last_bdf);=0A+    AMD_IOMMU_DEBUG(" Dev_Id Range: %#x -> =
%#x\n", first_bdf, last_bdf);=0A =0A     for ( bdf =3D first_bdf; bdf <=3D =
last_bdf; bdf++ )=0A         add_ivrs_mapping_entry(bdf, bdf, range->start.=
header.data_setting,=0A@@ -485,18 +485,18 @@ static u16 __init parse_ivhd_d=
evice_alia=0A     bdf =3D alias->header.id;=0A     if ( bdf >=3D ivrs_bdf_e=
ntries )=0A     {=0A-        AMD_IOMMU_DEBUG("IVHD Error: Invalid =
Device_Entry Dev_Id 0x%x\n", bdf);=0A+        AMD_IOMMU_DEBUG("IVHD Error: =
Invalid Device_Entry Dev_Id %#x\n", bdf);=0A         return 0;=0A     }=0A =
=0A     alias_id =3D alias->used_id;=0A     if ( alias_id >=3D ivrs_bdf_ent=
ries )=0A     {=0A-        AMD_IOMMU_DEBUG("IVHD Error: Invalid Alias =
Dev_Id 0x%x\n", alias_id);=0A+        AMD_IOMMU_DEBUG("IVHD Error: Invalid =
Alias Dev_Id %#x\n", alias_id);=0A         return 0;=0A     }=0A =0A-    =
AMD_IOMMU_DEBUG(" Dev_Id Alias: 0x%x\n", alias_id);=0A+    AMD_IOMMU_DEBUG(=
" Dev_Id Alias: %#x\n", alias_id);=0A =0A     add_ivrs_mapping_entry(bdf, =
alias_id, alias->header.data_setting, iommu);=0A =0A@@ -520,7 +520,7 @@ =
static u16 __init parse_ivhd_device_alia=0A     if ( range->end.header.type=
 !=3D ACPI_IVRS_TYPE_END )=0A     {=0A         AMD_IOMMU_DEBUG("IVHD =
Error: "=0A-                        "Invalid Range: End_Type 0x%x\n",=0A+  =
                      "Invalid Range: End_Type %#x\n",=0A                  =
       range->end.header.type);=0A         return 0;=0A     }=0A@@ -529,7 =
+529,7 @@ static u16 __init parse_ivhd_device_alia=0A     if ( first_bdf =
>=3D ivrs_bdf_entries )=0A     {=0A         AMD_IOMMU_DEBUG("IVHD Error: =
"=0A-                        "Invalid Range: First Dev_Id 0x%x\n", =
first_bdf);=0A+                        "Invalid Range: First Dev_Id =
%#x\n", first_bdf);=0A         return 0;=0A     }=0A =0A@@ -537,19 +537,19 =
@@ static u16 __init parse_ivhd_device_alia=0A     if ( last_bdf >=3D =
ivrs_bdf_entries || last_bdf <=3D first_bdf )=0A     {=0A         =
AMD_IOMMU_DEBUG(=0A-            "IVHD Error: Invalid Range: Last Dev_Id =
0x%x\n", last_bdf);=0A+            "IVHD Error: Invalid Range: Last Dev_Id =
%#x\n", last_bdf);=0A         return 0;=0A     }=0A =0A     alias_id =3D =
range->alias.used_id;=0A     if ( alias_id >=3D ivrs_bdf_entries )=0A     =
{=0A-        AMD_IOMMU_DEBUG("IVHD Error: Invalid Alias Dev_Id 0x%x\n", =
alias_id);=0A+        AMD_IOMMU_DEBUG("IVHD Error: Invalid Alias Dev_Id =
%#x\n", alias_id);=0A         return 0;=0A     }=0A =0A-    AMD_IOMMU_DEBUG=
(" Dev_Id Range: 0x%x -> 0x%x\n", first_bdf, last_bdf);=0A-    AMD_IOMMU_DE=
BUG(" Dev_Id Alias: 0x%x\n", alias_id);=0A+    AMD_IOMMU_DEBUG(" Dev_Id =
Range: %#x -> %#x\n", first_bdf, last_bdf);=0A+    AMD_IOMMU_DEBUG(" =
Dev_Id Alias: %#x\n", alias_id);=0A =0A     for ( bdf =3D first_bdf; bdf =
<=3D last_bdf; bdf++ )=0A         add_ivrs_mapping_entry(bdf, alias_id, =
range->alias.header.data_setting,=0A@@ -574,7 +574,7 @@ static u16 __init =
parse_ivhd_device_exte=0A     bdf =3D ext->header.id;=0A     if ( bdf >=3D =
ivrs_bdf_entries )=0A     {=0A-        AMD_IOMMU_DEBUG("IVHD Error: =
Invalid Device_Entry Dev_Id 0x%x\n", bdf);=0A+        AMD_IOMMU_DEBUG("IVHD=
 Error: Invalid Device_Entry Dev_Id %#x\n", bdf);=0A         return 0;=0A  =
   }=0A =0A@@ -599,7 +599,7 @@ static u16 __init parse_ivhd_device_exte=0A =
    if ( range->end.header.type !=3D ACPI_IVRS_TYPE_END )=0A     {=0A      =
   AMD_IOMMU_DEBUG("IVHD Error: "=0A-                        "Invalid =
Range: End_Type 0x%x\n",=0A+                        "Invalid Range: =
End_Type %#x\n",=0A                         range->end.header.type);=0A    =
     return 0;=0A     }=0A@@ -608,7 +608,7 @@ static u16 __init parse_ivhd_=
device_exte=0A     if ( first_bdf >=3D ivrs_bdf_entries )=0A     {=0A      =
   AMD_IOMMU_DEBUG("IVHD Error: "=0A-                        "Invalid =
Range: First Dev_Id 0x%x\n", first_bdf);=0A+                        =
"Invalid Range: First Dev_Id %#x\n", first_bdf);=0A         return 0;=0A   =
  }=0A =0A@@ -616,11 +616,11 @@ static u16 __init parse_ivhd_device_exte=0A=
     if ( (last_bdf >=3D ivrs_bdf_entries) || (last_bdf <=3D first_bdf) =
)=0A     {=0A         AMD_IOMMU_DEBUG("IVHD Error: "=0A-                   =
     "Invalid Range: Last Dev_Id 0x%x\n", last_bdf);=0A+                   =
     "Invalid Range: Last Dev_Id %#x\n", last_bdf);=0A         return =
0;=0A     }=0A =0A-    AMD_IOMMU_DEBUG(" Dev_Id Range: 0x%x -> 0x%x\n",=0A+=
    AMD_IOMMU_DEBUG(" Dev_Id Range: %#x -> %#x\n",=0A                     =
first_bdf, last_bdf);=0A =0A     for ( bdf =3D first_bdf; bdf <=3D =
last_bdf; bdf++ )=0A@@ -646,7 +646,7 @@ static u16 __init parse_ivhd_device=
_spec=0A     bdf =3D special->used_id;=0A     if ( bdf >=3D ivrs_bdf_entrie=
s )=0A     {=0A-        AMD_IOMMU_DEBUG("IVHD Error: Invalid Device_Entry =
Dev_Id 0x%x\n", bdf);=0A+        AMD_IOMMU_DEBUG("IVHD Error: Invalid =
Device_Entry Dev_Id %#x\n", bdf);=0A         return 0;=0A     }=0A =0A@@ =
-673,7 +673,7 @@ static int __init parse_ivhd_block(const=0A               =
                      ivhd_block->capability_offset);=0A     if ( !iommu =
)=0A     {=0A-        AMD_IOMMU_DEBUG("IVHD Error: No IOMMU for Dev_Id =
0x%x  Cap 0x%x\n",=0A+        AMD_IOMMU_DEBUG("IVHD Error: No IOMMU for =
Dev_Id %#x Cap %#x\n",=0A                         ivhd_block->header.device=
_id,=0A                         ivhd_block->capability_offset);=0A         =
return -ENODEV;=0A@@ -687,9 +687,9 @@ static int __init parse_ivhd_block(co=
nst=0A         ivhd_device =3D (const void *)((const u8 *)ivhd_block + =
block_length);=0A =0A         AMD_IOMMU_DEBUG( "IVHD Device Entry:\n");=0A-=
        AMD_IOMMU_DEBUG( " Type 0x%x\n", ivhd_device->header.type);=0A-    =
    AMD_IOMMU_DEBUG( " Dev_Id 0x%x\n", ivhd_device->header.id);=0A-        =
AMD_IOMMU_DEBUG( " Flags 0x%x\n", ivhd_device->header.data_setting);=0A+   =
     AMD_IOMMU_DEBUG( " Type %#x\n", ivhd_device->header.type);=0A+        =
AMD_IOMMU_DEBUG( " Dev_Id %#x\n", ivhd_device->header.id);=0A+        =
AMD_IOMMU_DEBUG( " Flags %#x\n", ivhd_device->header.data_setting);=0A =0A =
        switch ( ivhd_device->header.type )=0A         {=0A@@ -788,9 =
+788,9 @@ static void __init dump_acpi_table_heade=0A         printk("%c", =
table->signature[i]);=0A     printk("\n");=0A =0A-    AMD_IOMMU_DEBUG(" =
Length 0x%x\n", table->length);=0A-    AMD_IOMMU_DEBUG(" Revision 0x%x\n", =
table->revision);=0A-    AMD_IOMMU_DEBUG(" CheckSum 0x%x\n", table->checksu=
m);=0A+    AMD_IOMMU_DEBUG(" Length %#x\n", table->length);=0A+    =
AMD_IOMMU_DEBUG(" Revision %#x\n", table->revision);=0A+    AMD_IOMMU_DEBUG=
(" CheckSum %#x\n", table->checksum);=0A =0A     AMD_IOMMU_DEBUG(" OEM_Id =
");=0A     for ( i =3D 0; i < ACPI_OEM_ID_SIZE; i++ )=0A@@ -802,14 +802,14 =
@@ static void __init dump_acpi_table_heade=0A         printk("%c", =
table->oem_table_id[i]);=0A     printk("\n");=0A =0A-    AMD_IOMMU_DEBUG(" =
OEM_Revision 0x%x\n", table->oem_revision);=0A+    AMD_IOMMU_DEBUG(" =
OEM_Revision %#x\n", table->oem_revision);=0A =0A     AMD_IOMMU_DEBUG(" =
Creator_Id ");=0A     for ( i =3D 0; i < ACPI_NAME_SIZE; i++ )=0A         =
printk("%c", table->asl_compiler_id[i]);=0A     printk("\n");=0A =0A-    =
AMD_IOMMU_DEBUG(" Creator_Revision 0x%x\n",=0A+    AMD_IOMMU_DEBUG(" =
Creator_Revision %#x\n",=0A                     table->asl_compiler_revisio=
n);=0A =0A }=0A@@ -832,15 +832,15 @@ static int __init parse_ivrs_table(str=
uc=0A         ivrs_block =3D (struct acpi_ivrs_header *)((u8 *)table + =
length);=0A =0A         AMD_IOMMU_DEBUG("IVRS Block:\n");=0A-        =
AMD_IOMMU_DEBUG(" Type 0x%x\n", ivrs_block->type);=0A-        AMD_IOMMU_DEB=
UG(" Flags 0x%x\n", ivrs_block->flags);=0A-        AMD_IOMMU_DEBUG(" =
Length 0x%x\n", ivrs_block->length);=0A-        AMD_IOMMU_DEBUG(" Dev_Id =
0x%x\n", ivrs_block->device_id);=0A+        AMD_IOMMU_DEBUG(" Type %#x\n", =
ivrs_block->type);=0A+        AMD_IOMMU_DEBUG(" Flags %#x\n", ivrs_block->f=
lags);=0A+        AMD_IOMMU_DEBUG(" Length %#x\n", ivrs_block->length);=0A+=
        AMD_IOMMU_DEBUG(" Dev_Id %#x\n", ivrs_block->device_id);=0A =0A    =
     if ( table->length < (length + ivrs_block->length) )=0A         {=0A  =
           AMD_IOMMU_DEBUG("IVRS Error: "=0A-                            =
"Table Length Exceeded: 0x%x -> 0x%lx\n",=0A+                            =
"Table Length Exceeded: %#x -> %#lx\n",=0A                             =
table->length,=0A                             (length + ivrs_block->length)=
);=0A             return -ENODEV;=0A@@ -867,7 +867,7 @@ static int __init =
detect_iommu_acpi(stru=0A         checksum +=3D raw_table[i];=0A     if ( =
checksum )=0A     {=0A-        AMD_IOMMU_DEBUG("IVRS Error: Invalid =
Checksum 0x%x\n", checksum);=0A+        AMD_IOMMU_DEBUG("IVRS Error: =
Invalid Checksum %#x\n", checksum);=0A         return -ENODEV;=0A     }=0A =
=0A--- 2012-09-21.orig/xen/drivers/passthrough/amd/iommu_init.c	2012-09-17 =
09:57:54.000000000 +0200=0A+++ 2012-09-21/xen/drivers/passthrough/amd/iommu=
_init.c	2012-09-21 10:54:46.000000000 +0200=0A@@ -616,8 +616,8 @@ static =
void parse_event_log_entry(struct=0A                                       =
 IOMMU_EVENT_FLAGS_SHIFT);=0A         addr=3D (u64*) (entry + 2);=0A       =
  printk(XENLOG_ERR "AMD-Vi: "=0A-               "%s: domain =3D %d, =
device id =3D 0x%04x, "=0A-               "fault address =3D 0x%"PRIx64", =
flags =3D 0x%03x\n",=0A+               "%s: domain =3D %d, device id =3D =
%#x, "=0A+               "fault address =3D %#"PRIx64", flags =3D =
%#x\n",=0A                event_str[code-1], domain_id, device_id, *addr, =
flags);=0A =0A         /* Tell the device to stop DMAing; we can't rely on =
the guest to=0A--- 2012-09-21.orig/xen/drivers/passthrough/amd/iommu_map.c	=
2012-09-14 13:26:34.000000000 +0200=0A+++ 2012-09-21/xen/drivers/passthroug=
h/amd/iommu_map.c	2012-09-21 10:54:46.000000000 +0200=0A@@ -795,7 =
+795,7 @@ void amd_iommu_share_p2m(struct domain *=0A =0A         /* When =
sharing p2m with iommu, paging mode =3D 4 */=0A         hd->paging_mode =
=3D IOMMU_PAGING_MODE_LEVEL_4;=0A-        AMD_IOMMU_DEBUG("Share p2m table =
with iommu: p2m table =3D 0x%lx\n",=0A+        AMD_IOMMU_DEBUG("Share p2m =
table with iommu: p2m table =3D %#lx\n",=0A                         =
mfn_x(pgd_mfn));=0A     }=0A }=0A--- 2012-09-21.orig/xen/drivers/passthroug=
h/amd/pci_amd_iommu.c	2012-09-14 13:26:34.000000000 +0200=0A+++ =
2012-09-21/xen/drivers/passthrough/amd/pci_amd_iommu.c	2012-09-21 =
10:54:46.000000000 +0200=0A@@ -121,8 +121,8 @@ static void amd_iommu_setup_=
domain_devic=0A =0A         amd_iommu_flush_device(iommu, req_id);=0A =0A- =
       AMD_IOMMU_DEBUG("Setup I/O page table: device id =3D 0x%04x, "=0A-  =
                      "root table =3D 0x%"PRIx64", "=0A+        AMD_IOMMU_D=
EBUG("Setup I/O page table: device id =3D %#x, "=0A+                       =
 "root table =3D %#"PRIx64", "=0A                         "domain =3D %d, =
paging mode =3D %d\n", req_id,=0A                         page_to_maddr(hd-=
>root_table),=0A                         hd->domain_id, hd->paging_mode);=
=0A@@ -314,7 +314,7 @@ void amd_iommu_disable_domain_device(str=0A =0A     =
    amd_iommu_flush_device(iommu, req_id);=0A =0A-        AMD_IOMMU_DEBUG("=
Disable: device id =3D 0x%04x, "=0A+        AMD_IOMMU_DEBUG("Disable: =
device id =3D %#x, "=0A                         "domain =3D %d, paging =
mode =3D %d\n",=0A                         req_id,  domain_hvm_iommu(domain=
)->domain_id,=0A                         domain_hvm_iommu(domain)->paging_m=
ode);=0A--- 2012-09-21.orig/xen/drivers/passthrough/vtd/dmar.c	2012-09-14 =
13:26:34.000000000 +0200=0A+++ 2012-09-21/xen/drivers/passthrough/vtd/dmar.=
c	2012-09-21 10:54:46.000000000 +0200=0A@@ -381,7 +381,7 @@ static =
int __init acpi_dmar_check_length=0A     if ( h->length >=3D min_len )=0A  =
       return 0;=0A     dprintk(XENLOG_ERR VTDPREFIX,=0A-            =
"Invalid ACPI DMAR entry length: 0x%x\n",=0A+            "Invalid ACPI =
DMAR entry length: %#x\n",=0A             h->length);=0A     return =
-EINVAL;=0A }=0A@@ -749,7 +749,7 @@ static int __init acpi_parse_dmar(struc=
t=0A             break;=0A         default:=0A             dprintk(XENLOG_W=
ARNING VTDPREFIX,=0A-                    "Ignore unknown DMAR structure =
type (0x%x)\n",=0A+                    "Ignore unknown DMAR structure type =
(%#x)\n",=0A                     entry_header->type);=0A             =
break;=0A         }=0A--- 2012-09-21.orig/xen/drivers/passthrough/vtd/intre=
map.c	2012-09-14 13:26:34.000000000 +0200=0A+++ 2012-09-21/xen/drivers/pa=
ssthrough/vtd/intremap.c	2012-09-21 10:54:46.000000000 +0200=0A@@ =
-135,7 +135,7 @@ int iommu_supports_eim(void)=0A         if ( !ioapic_to_dr=
hd(IO_APIC_ID(apic)) )=0A     {=0A             dprintk(XENLOG_WARNING =
VTDPREFIX,=0A-                    "There is not a DRHD for IOAPIC 0x%x =
(id: 0x%x)!\n",=0A+                    "There is not a DRHD for IOAPIC %#x =
(id: %#x)!\n",=0A                     apic, IO_APIC_ID(apic));=0A          =
   return 0;=0A     }=0A--- 2012-09-21.orig/xen/drivers/passthrough/vtd/iom=
mu.c	2012-09-17 09:57:55.000000000 +0200=0A+++ 2012-09-21/xen/drivers/pa=
ssthrough/vtd/iommu.c	2012-09-21 10:54:46.000000000 +0200=0A@@ -2035,7 =
+2035,7 @@ static int init_vtd_hw(void)=0A             {=0A                =
 iommu_intremap =3D 0;=0A                 dprintk(XENLOG_ERR VTDPREFIX,=0A-=
                    "ioapic_to_iommu: ioapic 0x%x (id: 0x%x) is NULL! =
"=0A+                    "ioapic_to_iommu: ioapic %#x (id: %#x) is NULL! =
"=0A                     "Will not try to enable Interrupt Remapping.\n",=
=0A                     apic, IO_APIC_ID(apic));=0A                 =
break;=0A--- 2012-09-21.orig/xen/drivers/passthrough/vtd/utils.c	=
2012-09-14 13:26:34.000000000 +0200=0A+++ 2012-09-21/xen/drivers/passthroug=
h/vtd/utils.c	2012-09-21 10:54:46.000000000 +0200=0A@@ -217,7 +217,7 @@ =
static void dump_iommu_info(unsigned cha=0A             struct iremap_entry=
 *iremap_entries =3D NULL;=0A             int print_cnt =3D 0;=0A =0A-     =
       printk("  Interrupt remapping table (nr_entry=3D0x%x. "=0A+         =
   printk("  Interrupt remapping table (nr_entry=3D%#x. "=0A               =
  "Only dump P=3D1 entries here):\n", nr_entry);=0A             printk("   =
    SVT  SQ   SID      DST  V  AVL DLM TM RH DM "=0A                    =
"FPD P\n");=0A--- 2012-09-21.orig/xen/drivers/video/vesa.c	2012-09-14 =
13:26:34.000000000 +0200=0A+++ 2012-09-21/xen/drivers/video/vesa.c	=
2012-09-21 10:54:46.000000000 +0200=0A@@ -111,7 +111,7 @@ void __init =
vesa_init(void)=0A =0A     vga_puts =3D vesa_redraw_puts;=0A =0A-    =
printk(XENLOG_INFO "vesafb: framebuffer at 0x%x, mapped to 0x%p, "=0A+    =
printk(XENLOG_INFO "vesafb: framebuffer at %#x, mapped to 0x%p, "=0A       =
     "using %uk, total %uk\n",=0A            vlfb_info.lfb_base, lfb,=0A   =
         vram_remap >> 10, vram_total >> 10);=0A
--=__Part6756664C.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

--=__Part6756664C.0__=--


From xen-devel-bounces@lists.xen.org Fri Sep 21 11:33:27 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Sep 2012 11:33:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TF1Tt-0002Ua-Lp; Fri, 21 Sep 2012 11:33: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 1TF1Ts-0002US-2c
	for xen-devel@lists.xen.org; Fri, 21 Sep 2012 11:33:12 +0000
Received: from [85.158.143.35:32511] by server-2.bemta-4.messagelabs.com id
	83/CE-06610-7705C505; Fri, 21 Sep 2012 11:33:11 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1348227189!17916188!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5009 invoked from network); 21 Sep 2012 11:33:09 -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 Sep 2012 11:33:09 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 21 Sep 2012 12:33:09 +0100
Message-Id: <505C6C93020000780009CF0C@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 21 Sep 2012 12:33:07 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part57665663.0__="
Subject: [Xen-devel] [PATCH] x86: replace literal numbers
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
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.

--=__Part57665663.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

In various cases, 256 was being used instead of NR_VECTORS or a derived
ARRAY_SIZE() expression. In one case (guest_has_trap_callback()), a
wrong (unrelated) constant was used instead of NR_VECTORS.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -368,8 +368,9 @@ int switch_compat(struct domain *d)
=20
 static inline bool_t standalone_trap_ctxt(struct vcpu *v)
 {
-    BUILD_BUG_ON(256 * sizeof(*v->arch.pv_vcpu.trap_ctxt) > PAGE_SIZE);
-    return 256 * sizeof(*v->arch.pv_vcpu.trap_ctxt) + sizeof(*v) > =
PAGE_SIZE;
+    BUILD_BUG_ON(NR_VECTORS * sizeof(*v->arch.pv_vcpu.trap_ctxt) > =
PAGE_SIZE);
+    return NR_VECTORS * sizeof(*v->arch.pv_vcpu.trap_ctxt) + sizeof(*v)
+           > PAGE_SIZE;
 }
=20
 int vcpu_initialise(struct vcpu *v)
@@ -426,7 +427,7 @@ int vcpu_initialise(struct vcpu *v)
         }
         else
             v->arch.pv_vcpu.trap_ctxt =3D (void *)v + PAGE_SIZE -
-                256 * sizeof(*v->arch.pv_vcpu.trap_ctxt);
+                NR_VECTORS * sizeof(*v->arch.pv_vcpu.trap_ctxt);
=20
         /* PV guests by default have a 100Hz ticker. */
         v->periodic_period =3D MILLISECS(10);
@@ -701,7 +702,7 @@ int arch_set_info_guest(
             fixup_guest_stack_selector(d, c.nat->kernel_ss);
             fixup_guest_code_selector(d, c.nat->user_regs.cs);
=20
-            for ( i =3D 0; i < 256; i++ )
+            for ( i =3D 0; i < ARRAY_SIZE(c.nat->trap_ctxt); i++ )
             {
                 if ( !is_canonical_address(c.nat->trap_ctxt[i].address) )
                     return -EINVAL;
@@ -724,7 +725,7 @@ int arch_set_info_guest(
             fixup_guest_code_selector(d, c.cmp->event_callback_cs);
             fixup_guest_code_selector(d, c.cmp->failsafe_callback_cs);
=20
-            for ( i =3D 0; i < 256; i++ )
+            for ( i =3D 0; i < ARRAY_SIZE(c.cmp->trap_ctxt); i++ )
                 fixup_guest_code_selector(d, c.cmp->trap_ctxt[i].cs);
=20
             /* LDT safety checks. */
--- a/xen/arch/x86/traps.c
+++ b/xen/arch/x86/traps.c
@@ -3542,7 +3542,7 @@ int guest_has_trap_callback(struct domai
     BUG_ON(vcpuid >=3D d->max_vcpus);
=20
     /* Sanity check - XXX should be more fine grained. */
-    BUG_ON(trap_nr > TRAP_syscall);
+    BUG_ON(trap_nr >=3D NR_VECTORS);
=20
     v =3D d->vcpu[vcpuid];
     t =3D &v->arch.pv_vcpu.trap_ctxt[trap_nr];
@@ -3610,7 +3610,7 @@ long do_set_trap_table(XEN_GUEST_HANDLE(
     /* If no table is presented then clear the entire virtual IDT. */
     if ( guest_handle_is_null(traps) )
     {
-        memset(dst, 0, 256 * sizeof(*dst));
+        memset(dst, 0, NR_VECTORS * sizeof(*dst));
         init_int80_direct_trap(curr);
         return 0;
     }
--- a/xen/arch/x86/x86_64/compat/traps.c
+++ b/xen/arch/x86/x86_64/compat/traps.c
@@ -317,7 +317,7 @@ int compat_set_trap_table(XEN_GUEST_HAND
     /* If no table is presented then clear the entire virtual IDT. */
     if ( guest_handle_is_null(traps) )
     {
-        memset(dst, 0, 256 * sizeof(*dst));
+        memset(dst, 0, NR_VECTORS * sizeof(*dst));
         return 0;
     }
=20




--=__Part57665663.0__=
Content-Type: text/plain; name="x86-use-NR_VECTORS.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="x86-use-NR_VECTORS.patch"

x86: replace literal numbers=0A=0AIn various cases, 256 was being used =
instead of NR_VECTORS or a derived=0AARRAY_SIZE() expression. In one case =
(guest_has_trap_callback()), a=0Awrong (unrelated) constant was used =
instead of NR_VECTORS.=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@@ =
-368,8 +368,9 @@ int switch_compat(struct domain *d)=0A =0A static inline =
bool_t standalone_trap_ctxt(struct vcpu *v)=0A {=0A-    BUILD_BUG_ON(256 * =
sizeof(*v->arch.pv_vcpu.trap_ctxt) > PAGE_SIZE);=0A-    return 256 * =
sizeof(*v->arch.pv_vcpu.trap_ctxt) + sizeof(*v) > PAGE_SIZE;=0A+    =
BUILD_BUG_ON(NR_VECTORS * sizeof(*v->arch.pv_vcpu.trap_ctxt) > PAGE_SIZE);=
=0A+    return NR_VECTORS * sizeof(*v->arch.pv_vcpu.trap_ctxt) + sizeof(*v)=
=0A+           > PAGE_SIZE;=0A }=0A =0A int vcpu_initialise(struct vcpu =
*v)=0A@@ -426,7 +427,7 @@ int vcpu_initialise(struct vcpu *v)=0A         =
}=0A         else=0A             v->arch.pv_vcpu.trap_ctxt =3D (void *)v + =
PAGE_SIZE -=0A-                256 * sizeof(*v->arch.pv_vcpu.trap_ctxt);=0A=
+                NR_VECTORS * sizeof(*v->arch.pv_vcpu.trap_ctxt);=0A =0A   =
      /* PV guests by default have a 100Hz ticker. */=0A         v->periodi=
c_period =3D MILLISECS(10);=0A@@ -701,7 +702,7 @@ int arch_set_info_guest(=
=0A             fixup_guest_stack_selector(d, c.nat->kernel_ss);=0A        =
     fixup_guest_code_selector(d, c.nat->user_regs.cs);=0A =0A-            =
for ( i =3D 0; i < 256; i++ )=0A+            for ( i =3D 0; i < ARRAY_SIZE(=
c.nat->trap_ctxt); i++ )=0A             {=0A                 if ( =
!is_canonical_address(c.nat->trap_ctxt[i].address) )=0A                    =
 return -EINVAL;=0A@@ -724,7 +725,7 @@ int arch_set_info_guest(=0A         =
    fixup_guest_code_selector(d, c.cmp->event_callback_cs);=0A             =
fixup_guest_code_selector(d, c.cmp->failsafe_callback_cs);=0A =0A-         =
   for ( i =3D 0; i < 256; i++ )=0A+            for ( i =3D 0; i < =
ARRAY_SIZE(c.cmp->trap_ctxt); i++ )=0A                 fixup_guest_code_sel=
ector(d, c.cmp->trap_ctxt[i].cs);=0A =0A             /* LDT safety checks. =
*/=0A--- a/xen/arch/x86/traps.c=0A+++ b/xen/arch/x86/traps.c=0A@@ -3542,7 =
+3542,7 @@ int guest_has_trap_callback(struct domai=0A     BUG_ON(vcpuid =
>=3D d->max_vcpus);=0A =0A     /* Sanity check - XXX should be more fine =
grained. */=0A-    BUG_ON(trap_nr > TRAP_syscall);=0A+    BUG_ON(trap_nr =
>=3D NR_VECTORS);=0A =0A     v =3D d->vcpu[vcpuid];=0A     t =3D &v->arch.p=
v_vcpu.trap_ctxt[trap_nr];=0A@@ -3610,7 +3610,7 @@ long do_set_trap_table(X=
EN_GUEST_HANDLE(=0A     /* If no table is presented then clear the entire =
virtual IDT. */=0A     if ( guest_handle_is_null(traps) )=0A     {=0A-     =
   memset(dst, 0, 256 * sizeof(*dst));=0A+        memset(dst, 0, NR_VECTORS=
 * sizeof(*dst));=0A         init_int80_direct_trap(curr);=0A         =
return 0;=0A     }=0A--- a/xen/arch/x86/x86_64/compat/traps.c=0A+++ =
b/xen/arch/x86/x86_64/compat/traps.c=0A@@ -317,7 +317,7 @@ int compat_set_t=
rap_table(XEN_GUEST_HAND=0A     /* If no table is presented then clear the =
entire virtual IDT. */=0A     if ( guest_handle_is_null(traps) )=0A     =
{=0A-        memset(dst, 0, 256 * sizeof(*dst));=0A+        memset(dst, 0, =
NR_VECTORS * sizeof(*dst));=0A         return 0;=0A     }=0A =0A
--=__Part57665663.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

--=__Part57665663.0__=--


From xen-devel-bounces@lists.xen.org Fri Sep 21 11:33:27 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Sep 2012 11:33:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TF1Tt-0002Ua-Lp; Fri, 21 Sep 2012 11:33: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 1TF1Ts-0002US-2c
	for xen-devel@lists.xen.org; Fri, 21 Sep 2012 11:33:12 +0000
Received: from [85.158.143.35:32511] by server-2.bemta-4.messagelabs.com id
	83/CE-06610-7705C505; Fri, 21 Sep 2012 11:33:11 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1348227189!17916188!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5009 invoked from network); 21 Sep 2012 11:33:09 -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 Sep 2012 11:33:09 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 21 Sep 2012 12:33:09 +0100
Message-Id: <505C6C93020000780009CF0C@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 21 Sep 2012 12:33:07 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part57665663.0__="
Subject: [Xen-devel] [PATCH] x86: replace literal numbers
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
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.

--=__Part57665663.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

In various cases, 256 was being used instead of NR_VECTORS or a derived
ARRAY_SIZE() expression. In one case (guest_has_trap_callback()), a
wrong (unrelated) constant was used instead of NR_VECTORS.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -368,8 +368,9 @@ int switch_compat(struct domain *d)
=20
 static inline bool_t standalone_trap_ctxt(struct vcpu *v)
 {
-    BUILD_BUG_ON(256 * sizeof(*v->arch.pv_vcpu.trap_ctxt) > PAGE_SIZE);
-    return 256 * sizeof(*v->arch.pv_vcpu.trap_ctxt) + sizeof(*v) > =
PAGE_SIZE;
+    BUILD_BUG_ON(NR_VECTORS * sizeof(*v->arch.pv_vcpu.trap_ctxt) > =
PAGE_SIZE);
+    return NR_VECTORS * sizeof(*v->arch.pv_vcpu.trap_ctxt) + sizeof(*v)
+           > PAGE_SIZE;
 }
=20
 int vcpu_initialise(struct vcpu *v)
@@ -426,7 +427,7 @@ int vcpu_initialise(struct vcpu *v)
         }
         else
             v->arch.pv_vcpu.trap_ctxt =3D (void *)v + PAGE_SIZE -
-                256 * sizeof(*v->arch.pv_vcpu.trap_ctxt);
+                NR_VECTORS * sizeof(*v->arch.pv_vcpu.trap_ctxt);
=20
         /* PV guests by default have a 100Hz ticker. */
         v->periodic_period =3D MILLISECS(10);
@@ -701,7 +702,7 @@ int arch_set_info_guest(
             fixup_guest_stack_selector(d, c.nat->kernel_ss);
             fixup_guest_code_selector(d, c.nat->user_regs.cs);
=20
-            for ( i =3D 0; i < 256; i++ )
+            for ( i =3D 0; i < ARRAY_SIZE(c.nat->trap_ctxt); i++ )
             {
                 if ( !is_canonical_address(c.nat->trap_ctxt[i].address) )
                     return -EINVAL;
@@ -724,7 +725,7 @@ int arch_set_info_guest(
             fixup_guest_code_selector(d, c.cmp->event_callback_cs);
             fixup_guest_code_selector(d, c.cmp->failsafe_callback_cs);
=20
-            for ( i =3D 0; i < 256; i++ )
+            for ( i =3D 0; i < ARRAY_SIZE(c.cmp->trap_ctxt); i++ )
                 fixup_guest_code_selector(d, c.cmp->trap_ctxt[i].cs);
=20
             /* LDT safety checks. */
--- a/xen/arch/x86/traps.c
+++ b/xen/arch/x86/traps.c
@@ -3542,7 +3542,7 @@ int guest_has_trap_callback(struct domai
     BUG_ON(vcpuid >=3D d->max_vcpus);
=20
     /* Sanity check - XXX should be more fine grained. */
-    BUG_ON(trap_nr > TRAP_syscall);
+    BUG_ON(trap_nr >=3D NR_VECTORS);
=20
     v =3D d->vcpu[vcpuid];
     t =3D &v->arch.pv_vcpu.trap_ctxt[trap_nr];
@@ -3610,7 +3610,7 @@ long do_set_trap_table(XEN_GUEST_HANDLE(
     /* If no table is presented then clear the entire virtual IDT. */
     if ( guest_handle_is_null(traps) )
     {
-        memset(dst, 0, 256 * sizeof(*dst));
+        memset(dst, 0, NR_VECTORS * sizeof(*dst));
         init_int80_direct_trap(curr);
         return 0;
     }
--- a/xen/arch/x86/x86_64/compat/traps.c
+++ b/xen/arch/x86/x86_64/compat/traps.c
@@ -317,7 +317,7 @@ int compat_set_trap_table(XEN_GUEST_HAND
     /* If no table is presented then clear the entire virtual IDT. */
     if ( guest_handle_is_null(traps) )
     {
-        memset(dst, 0, 256 * sizeof(*dst));
+        memset(dst, 0, NR_VECTORS * sizeof(*dst));
         return 0;
     }
=20




--=__Part57665663.0__=
Content-Type: text/plain; name="x86-use-NR_VECTORS.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="x86-use-NR_VECTORS.patch"

x86: replace literal numbers=0A=0AIn various cases, 256 was being used =
instead of NR_VECTORS or a derived=0AARRAY_SIZE() expression. In one case =
(guest_has_trap_callback()), a=0Awrong (unrelated) constant was used =
instead of NR_VECTORS.=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@@ =
-368,8 +368,9 @@ int switch_compat(struct domain *d)=0A =0A static inline =
bool_t standalone_trap_ctxt(struct vcpu *v)=0A {=0A-    BUILD_BUG_ON(256 * =
sizeof(*v->arch.pv_vcpu.trap_ctxt) > PAGE_SIZE);=0A-    return 256 * =
sizeof(*v->arch.pv_vcpu.trap_ctxt) + sizeof(*v) > PAGE_SIZE;=0A+    =
BUILD_BUG_ON(NR_VECTORS * sizeof(*v->arch.pv_vcpu.trap_ctxt) > PAGE_SIZE);=
=0A+    return NR_VECTORS * sizeof(*v->arch.pv_vcpu.trap_ctxt) + sizeof(*v)=
=0A+           > PAGE_SIZE;=0A }=0A =0A int vcpu_initialise(struct vcpu =
*v)=0A@@ -426,7 +427,7 @@ int vcpu_initialise(struct vcpu *v)=0A         =
}=0A         else=0A             v->arch.pv_vcpu.trap_ctxt =3D (void *)v + =
PAGE_SIZE -=0A-                256 * sizeof(*v->arch.pv_vcpu.trap_ctxt);=0A=
+                NR_VECTORS * sizeof(*v->arch.pv_vcpu.trap_ctxt);=0A =0A   =
      /* PV guests by default have a 100Hz ticker. */=0A         v->periodi=
c_period =3D MILLISECS(10);=0A@@ -701,7 +702,7 @@ int arch_set_info_guest(=
=0A             fixup_guest_stack_selector(d, c.nat->kernel_ss);=0A        =
     fixup_guest_code_selector(d, c.nat->user_regs.cs);=0A =0A-            =
for ( i =3D 0; i < 256; i++ )=0A+            for ( i =3D 0; i < ARRAY_SIZE(=
c.nat->trap_ctxt); i++ )=0A             {=0A                 if ( =
!is_canonical_address(c.nat->trap_ctxt[i].address) )=0A                    =
 return -EINVAL;=0A@@ -724,7 +725,7 @@ int arch_set_info_guest(=0A         =
    fixup_guest_code_selector(d, c.cmp->event_callback_cs);=0A             =
fixup_guest_code_selector(d, c.cmp->failsafe_callback_cs);=0A =0A-         =
   for ( i =3D 0; i < 256; i++ )=0A+            for ( i =3D 0; i < =
ARRAY_SIZE(c.cmp->trap_ctxt); i++ )=0A                 fixup_guest_code_sel=
ector(d, c.cmp->trap_ctxt[i].cs);=0A =0A             /* LDT safety checks. =
*/=0A--- a/xen/arch/x86/traps.c=0A+++ b/xen/arch/x86/traps.c=0A@@ -3542,7 =
+3542,7 @@ int guest_has_trap_callback(struct domai=0A     BUG_ON(vcpuid =
>=3D d->max_vcpus);=0A =0A     /* Sanity check - XXX should be more fine =
grained. */=0A-    BUG_ON(trap_nr > TRAP_syscall);=0A+    BUG_ON(trap_nr =
>=3D NR_VECTORS);=0A =0A     v =3D d->vcpu[vcpuid];=0A     t =3D &v->arch.p=
v_vcpu.trap_ctxt[trap_nr];=0A@@ -3610,7 +3610,7 @@ long do_set_trap_table(X=
EN_GUEST_HANDLE(=0A     /* If no table is presented then clear the entire =
virtual IDT. */=0A     if ( guest_handle_is_null(traps) )=0A     {=0A-     =
   memset(dst, 0, 256 * sizeof(*dst));=0A+        memset(dst, 0, NR_VECTORS=
 * sizeof(*dst));=0A         init_int80_direct_trap(curr);=0A         =
return 0;=0A     }=0A--- a/xen/arch/x86/x86_64/compat/traps.c=0A+++ =
b/xen/arch/x86/x86_64/compat/traps.c=0A@@ -317,7 +317,7 @@ int compat_set_t=
rap_table(XEN_GUEST_HAND=0A     /* If no table is presented then clear the =
entire virtual IDT. */=0A     if ( guest_handle_is_null(traps) )=0A     =
{=0A-        memset(dst, 0, 256 * sizeof(*dst));=0A+        memset(dst, 0, =
NR_VECTORS * sizeof(*dst));=0A         return 0;=0A     }=0A =0A
--=__Part57665663.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

--=__Part57665663.0__=--


From xen-devel-bounces@lists.xen.org Fri Sep 21 11:35:34 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Sep 2012 11: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 1TF1Vw-0002bv-72; Fri, 21 Sep 2012 11:35:20 +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 1TF1Vu-0002bi-PW
	for xen-devel@lists.xen.org; Fri, 21 Sep 2012 11:35:19 +0000
Received: from [85.158.137.99:42113] by server-13.bemta-3.messagelabs.com id
	3B/16-01606-6F05C505; Fri, 21 Sep 2012 11:35:18 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-2.tower-217.messagelabs.com!1348227317!18485961!1
X-Originating-IP: [74.125.83.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12148 invoked from network); 21 Sep 2012 11:35:17 -0000
Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com)
	(74.125.83.45)
	by server-2.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Sep 2012 11:35:17 -0000
Received: by eeke53 with SMTP id e53so1518866eek.32
	for <xen-devel@lists.xen.org>; Fri, 21 Sep 2012 04:35: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:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=o4LmNl8tLOcyOWb7FoEvnajjSgLItptRLk12APvUlXU=;
	b=nS4ZNadVUfwMWw5tTtAfCcP096a3v+80bILYQ5SNx8y73lYREev1jua21QyQHIPPhB
	Q0pyMU/zOGZmsSYbnXAEKwea20/b9GldEUZFIzK5ix2vaIvJZp92S1g4XxPwXTIRqwBY
	o+mqlb4LFy0k1T3/9SwYJHkd4EKGXXCbUkzkd2ZpINbzoKQq8pgLZRvNQzXkbmp4+RaJ
	3c7sbDFKH050H2hmkOx3YsoR6cigE6TpgBDUp33CDHBypYsAau09W8Vxfw44orUolz28
	Tww2xM7oBXAAFwoqQYH9WICFOYNYEQ5BeF/EIzNffovf07eSb6KL2FoIdvEkImp2Orh3
	dirw==
Received: by 10.14.4.201 with SMTP id 49mr5942682eej.0.1348227316825;
	Fri, 21 Sep 2012 04:35:16 -0700 (PDT)
Received: from [192.168.1.3] (host86-167-82-156.range86-167.btcentralplus.com.
	[86.167.82.156])
	by mx.google.com with ESMTPS id k41sm23174546eep.13.2012.09.21.04.35.14
	(version=SSLv3 cipher=OTHER); Fri, 21 Sep 2012 04:35:16 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.33.0.120411
Date: Fri, 21 Sep 2012 12:35:12 +0100
From: Keir Fraser <keir@xen.org>
To: Jan Beulich <JBeulich@suse.com>,
	xen-devel <xen-devel@lists.xen.org>
Message-ID: <CC820F80.4C961%keir@xen.org>
Thread-Topic: [Xen-devel] [PATCH 0/2] cpuidle adjustments
Thread-Index: Ac2X7SlTrpxiYdUF50+BmQrOxACHEQ==
In-Reply-To: <505C5FB7020000780009CEB0@nat28.tlf.novell.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] [PATCH 0/2] cpuidle adjustments
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 21/09/2012 11:38, "Jan Beulich" <JBeulich@suse.com> wrote:

> 1: remove unused latency_ticks member
> 2: x86: introduce MWAIT-based, ACPI-less CPU idle driver
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Acked-by: Keir Fraser <keir@xen.org>

> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 21 11:35:34 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Sep 2012 11: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 1TF1Vw-0002bv-72; Fri, 21 Sep 2012 11:35:20 +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 1TF1Vu-0002bi-PW
	for xen-devel@lists.xen.org; Fri, 21 Sep 2012 11:35:19 +0000
Received: from [85.158.137.99:42113] by server-13.bemta-3.messagelabs.com id
	3B/16-01606-6F05C505; Fri, 21 Sep 2012 11:35:18 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-2.tower-217.messagelabs.com!1348227317!18485961!1
X-Originating-IP: [74.125.83.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12148 invoked from network); 21 Sep 2012 11:35:17 -0000
Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com)
	(74.125.83.45)
	by server-2.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Sep 2012 11:35:17 -0000
Received: by eeke53 with SMTP id e53so1518866eek.32
	for <xen-devel@lists.xen.org>; Fri, 21 Sep 2012 04:35: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:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=o4LmNl8tLOcyOWb7FoEvnajjSgLItptRLk12APvUlXU=;
	b=nS4ZNadVUfwMWw5tTtAfCcP096a3v+80bILYQ5SNx8y73lYREev1jua21QyQHIPPhB
	Q0pyMU/zOGZmsSYbnXAEKwea20/b9GldEUZFIzK5ix2vaIvJZp92S1g4XxPwXTIRqwBY
	o+mqlb4LFy0k1T3/9SwYJHkd4EKGXXCbUkzkd2ZpINbzoKQq8pgLZRvNQzXkbmp4+RaJ
	3c7sbDFKH050H2hmkOx3YsoR6cigE6TpgBDUp33CDHBypYsAau09W8Vxfw44orUolz28
	Tww2xM7oBXAAFwoqQYH9WICFOYNYEQ5BeF/EIzNffovf07eSb6KL2FoIdvEkImp2Orh3
	dirw==
Received: by 10.14.4.201 with SMTP id 49mr5942682eej.0.1348227316825;
	Fri, 21 Sep 2012 04:35:16 -0700 (PDT)
Received: from [192.168.1.3] (host86-167-82-156.range86-167.btcentralplus.com.
	[86.167.82.156])
	by mx.google.com with ESMTPS id k41sm23174546eep.13.2012.09.21.04.35.14
	(version=SSLv3 cipher=OTHER); Fri, 21 Sep 2012 04:35:16 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.33.0.120411
Date: Fri, 21 Sep 2012 12:35:12 +0100
From: Keir Fraser <keir@xen.org>
To: Jan Beulich <JBeulich@suse.com>,
	xen-devel <xen-devel@lists.xen.org>
Message-ID: <CC820F80.4C961%keir@xen.org>
Thread-Topic: [Xen-devel] [PATCH 0/2] cpuidle adjustments
Thread-Index: Ac2X7SlTrpxiYdUF50+BmQrOxACHEQ==
In-Reply-To: <505C5FB7020000780009CEB0@nat28.tlf.novell.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] [PATCH 0/2] cpuidle adjustments
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 21/09/2012 11:38, "Jan Beulich" <JBeulich@suse.com> wrote:

> 1: remove unused latency_ticks member
> 2: x86: introduce MWAIT-based, ACPI-less CPU idle driver
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Acked-by: Keir Fraser <keir@xen.org>

> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 21 11:36:54 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Sep 2012 11:36: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 1TF1XH-0002j5-Mm; Fri, 21 Sep 2012 11:36: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 1TF1XG-0002iw-8w
	for xen-devel@lists.xen.org; Fri, 21 Sep 2012 11:36:42 +0000
Received: from [85.158.139.83:14207] by server-1.bemta-5.messagelabs.com id
	41/00-04809-9415C505; Fri, 21 Sep 2012 11:36:41 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1348227397!27259691!1
X-Originating-IP: [74.125.83.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3898 invoked from network); 21 Sep 2012 11:36:37 -0000
Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com)
	(74.125.83.45)
	by server-14.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Sep 2012 11:36:37 -0000
Received: by eeke53 with SMTP id e53so1519550eek.32
	for <xen-devel@lists.xen.org>; Fri, 21 Sep 2012 04:36:37 -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=pJsphc8VUArMGZt4gPBeiWOXYO6z2nhAjQESxK0oPFs=;
	b=CJcORN/xDm6g2KO/BvJEJL8dvZbIEgAE3FOmDEgSd67v8L6qDnOENVJBacRqIArYxF
	uo8sFOOqdZFkyo4jIO3enWzNMCryW61FW6Jy64I0M71OfQ94+5cD8l7uDezA9kJviCiq
	DDJ8/aKWLd5R/BRPCcRNDSSQGQFPZJklKqtQxusHo7qXjfUqGBHanTn5cBUZpbjyDgBJ
	kks+0WR7LH7K3zjLOZZglReufeYdYM9y3f+WA4rHwBeAiglegUuqq6WKJRbvhICHiCWq
	ymqln7ZIyLNJy2GiqIbCiSF4tjxYXqs0uP6ydCJxdrmFutJgMwmDKnjuN/PbhB4KPmU0
	NZMA==
Received: by 10.14.204.72 with SMTP id g48mr5842812eeo.45.1348227397576;
	Fri, 21 Sep 2012 04:36:37 -0700 (PDT)
Received: from [192.168.1.3] (host86-167-82-156.range86-167.btcentralplus.com.
	[86.167.82.156])
	by mx.google.com with ESMTPS id i41sm23236741eem.7.2012.09.21.04.36.32
	(version=SSLv3 cipher=OTHER); Fri, 21 Sep 2012 04:36:36 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.33.0.120411
Date: Fri, 21 Sep 2012 12:36:27 +0100
From: Keir Fraser <keir@xen.org>
To: Jan Beulich <JBeulich@suse.com>,
	xen-devel <xen-devel@lists.xen.org>
Message-ID: <CC820FCB.4C962%keir@xen.org>
Thread-Topic: [Xen-devel] [PATCH] printk: prefer %#x et at over 0x%x
Thread-Index: Ac2X7VYH+qFzog5NZEaTGkLWkKvH2A==
In-Reply-To: <505C6B7C020000780009CF08@nat28.tlf.novell.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] [PATCH] printk: prefer %#x et at over 0x%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 21/09/2012 12:28, "Jan Beulich" <JBeulich@suse.com> wrote:

> Performance is not an issue with printk(), so let the function do
> minimally more work and instead save a byte per affected format
> specifier.

I didn't know about the '#' prefix when I first started sprinkling '0x' all
around.

> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Acked-by: Keir Fraser <keir@xen.org>

> --- 2012-09-21.orig/xen/arch/x86/acpi/boot.c 2012-09-20 08:44:38.000000000
> +0200
> +++ 012-09-21/xen/arch/x86/acpi/boot.c 2012-09-21 10:54:46.000000000 +0200
> @@ -341,14 +341,14 @@ cpi_fadt_parse_sleep_info(struct acpi_t
> }
>  
> if (facs->length < 24) {
> -  printk(KERN_ERR PREFIX "Invalid FACS table length: 0x%x",
> +  printk(KERN_ERR PREFIX "Invalid FACS table length: %#x",
> facs->length);
> goto bad;
> }
>  
> if (facs->length < 64)
> printk(KERN_WARNING PREFIX
> -   "FACS is shorter than ACPI spec allow: 0x%x",
> +   "FACS is shorter than ACPI spec allow: %#x",
> facs->length);
>  
> acpi_sinfo.wakeup_vector = facs_pa +
> --- 2012-09-21.orig/xen/arch/x86/acpi/cpu_idlec 2012-08-15 08:32:43.000000000
> +0200
> +++ 2012-09-21/xen/arch/x86/acpi/cpu_idle.c 2012-09-21 1054:46.000000000
> +0200
> @@ -978,11 +978,11 @@ static void print_cx_pminfo(uint32_t cpu
>              return;
>          
>          printk("\tstates[%d]:\n", i);
> -        printk("\t\treg.space_id = 0x%x\n", state.reg.space_id);
> -        printk("\t\treg.bit_width = 0x%x\n", state.reg.bit_width);
> -        printk("\t\treg.bit_offset = 0x%x\n", state.reg.bit_offset);
> -        printk("\t\treg.access_size = 0x%x\n", state.reg.access_size);
> -        printk("\t\treg.address = 0x%"PRIx64"\n", state.reg.address);
> +        printk("\t\treg.space_id = %#x\n", state.reg.space_id);
> +        printk("\t\treg.bit_width = %#x\n", state.reg.bit_width);
> +        printk("\t\treg.bit_offset = %#x\n", state.reg.bit_offset);
> +        printk("\t\treg.access_size = %#x\n", state.reg.access_size);
> +        printk("\t\treg.address = %#"PRIx64"\n", state.reg.address);
>          printk("\t\ttype    = %d\n", state.type);
>          printk("\t\tlatency = %d\n", state.latency);
>          printk("\t\tpower   = %d\n", state.power);
> --- 2012-09-21.orig/xen/arch/x86/apic.c 2012-09-17 09:5:54.000000000 +0200
> +++ 2012-09-21/xen/arch/x86/apic.c 2012-09-21 10:54:46.000000000 +020
> @@ -689,7 +689,7 @@ void __devinit setup_local_APIC(void)
>          value = apic_read(APIC_ESR);
>          if (value != oldvalue)
>              apic_printk(APIC_VERBOSE, "ESR value before enabling "
> -                        "vector: 0x%08lx  after: 0x%08lx\n",
> +                        "vector: %#lx  after: %#lx\n",
>                          oldvalue, value);
>      } else {
>          if (esr_disable)
> @@ -1210,7 +1210,7 @@ static int __init calibrate_APIC_clock(v
>      bus_cycle  = (u32) (1000000000000LL/bus_freq); /* in pico seconds */
>      bus_scale  = (1000*262144)/bus_cycle;
>  
> -    apic_printk(APIC_VERBOSE, "..... bus_scale = 0x%08X\n", bus_scale);
> +    apic_printk(APIC_VERBOSE, "..... bus_scale = %#x\n", bus_scale);
>      /* reset APIC to zero timeout valu */
>      __setup_APIC_LVTT(0);
>  
> --- 2012-09-21.orig/xen/arch/x86/cpu/mcheck/mce.c 2012-9-20
> 08:44:38.000000000 +0200
> +++ 2012-09-21/xen/arch/x86/cpu/mcheck/mce.c 2012-09-21 10:54:46.000000000
> +0200
> @@ -1147,7 +1147,7 @@ static int x86_mc_msrinject_verify(struc
>          }
>  
>          if (reason != NULL) {
> -            printk("HV MSR INJECT ERROR: MSR 0x%llx %s\n",
> +            printk("HV MSR INJECT ERROR: MSR %#Lx %s\n",
>                     (unsigned long long)mci->mcinj_msr[i].reg, reason);
>              errs++;
>          }
> @@ -1191,8 +1191,7 @@ satic void x86_mc_msrinject(void *data)
>  
>      for (i = 0, msr = &mci->mcinj_msr[0];
>          i < mci->mcinj_count; i++, msr++) {
> -        printk("HV MSR INJECT (%s) target %u actual %u MSR 0x%llx "
> -               "<-- 0x%llx\n",
> +        printk("HV MSR INJECT (%s) target %u actual %u MSR %#Lx <-- %#Lx\n",
>                 intpose ?  "interpose" : "hardware",
>                 mci->mcinj_cpunr, smp_processor_id(),
>                 (unsigned long long)msr->reg,
> --- 2012-09-21.orig/xen/arch/x86/cpu/mcheck/vmce.c 2012-08-08
> 08:20:09.000000000 +0200
> +++ 2012-09-21/xen/arch/x86/cpu/mcheck/vmce.c 2012-09-21 10:54:46.00000000
> +0200
> @@ -88,7 +88,7 @@ static int bank_mce_rdmsr(const struct v
>      case MS_IA32_MC0_CTL:
>          /* stick all 1's to MCi_CTL */
>          *val = ~0UL;
> -        mce_printk(MCE_VERBOSE, "MCE: rdmsr MC%u_CTL 0x%"PRIx64"\n",
> +        mce_printk(MCE_VERBOSE, "MCE: rdmsr MC%u_CTL %#"PRIx64"\n",
>                     bank, *val);
>          break;
>      case MSR_IA32_MC0_STATUS:
> @@ -102,7 +102,7 @@ static int bank_mce_rdmsr(const struct v
>                  *val = entry->mci_status;
>                  mce_printk(MCE_VERBOSE,
>                             "MCE: rd MC%u_STATUS in vMCE# context "
> -                           "value 0x%"PRI64"\n", bank, *val);
> +                           "value %#"PRIx64"\n", bank, *val);
>              }
>          }
>          break;
> @@ -116,7 +116,7 @@ static int bank_mce_rdmsr(const struct v
>                  *val = entry->mci_addr;
>                  mce_printk(MCE_VERBOSE,
>                             "MCE: rdmsr MC%u_ADDR in vMCE# context "
> -                           "0x%"PRIx64"\n", bank, *val);
> +                           "%#"PRIx64"\n", bank, *val);
>              }
>          }
>          break;
> @@ -130,7 +130,7 @@ static int bank_mce_rdmsr(const struct v
>                  *val = entry->mci_misc;
>                  mce_printk(MCE_VERBOSE,
>                             "MCE: rd MC%u_MISC in vMCE# context "
> -                           "0x%"PRIx64"\n", bank, *val);
> +                           "%#"PRIx64"\n", bank, *val);
>              }
>          }
>          break;
> @@ -171,18 +171,18 @@ int vmce_rdmsr(uint32_t msr, uint64_t *v
>          *val = vmce->mcg_status;
>          if (*val)
>              mce_printk(MCE_VERBOSE,
> -                       "MCE: rdmsr MCG_STATUS 0x%"PRIx64"\n", *val);
> +                       "MCE: rdmsr MCG_STATUS %#"PRIx64"\n", *val);
>          break;
>      case MSR_IA32_MCG_CAP:
>          *val = cur->arch.mcg_cap;
> -        mce_printk(MCE_VERBOSE, "MCE: rdmsr MCG_CAP 0x%"PRIx64"\n",
> +        mce_printk(MCE_VERBOSE, "MCE: rdmsr MCG_CAP %#"PRIx64"\n",
>                     *val);
>          break;
>      case MSR_IA32_MCG_CTL:
>          /* Stick all 1's when CTL support, and 0's when no CTL support */
>          if ( cur->arch.mcg_cap & MCG_CTL_P )
>              *val = ~0ULL;
> -        mce_printk(MCE_VERBOSE, "MCE: rdmsr MCG_CTL 0x%"PRIx64"\n", *val);
> +        mce_printk(MCE_VERBOSE, "MCE: rdmsr MCG_CTL %#"PRIx64"\n", *val);
>          break;
>      default:
>          ret = mce_bank_msr(cur, msr) ? bank_mce_rdmsr(cur, msr, val) : 0;
> --- 2012-09-21.orig/xen/arch/x86/cpu/mtrr/generic.c 2011-04-11
> 08:33:59.000000000 +0200
> +++ 2012-09-21/xen/arch/x86/cpu/mtrr/generic.c 2012-09-21 10:54:46.000000000
> +0200
> @@ -410,7 +410,7 @@ int generic_validate_add_page(unsigned l
>    boot_cpu_data.x86_model == 1 &&
>    boot_cpu_data.x86_mask <= 7) {
> if (base & ((1 << (22 - PAGE_SHIFT)) - 1)) {
> -   printk(KERN_WARNING "mtrr: base(0x%lx000) is not 4 MiB aligned\n", base);
> +   printk(KERN_WARNING "mtrr: base(%#lx000) is not 4 MiB aligned\n", base);
> return -EINVAL;
> }
> if (!(base + size < 0x70000 || base > 0x7003F) &&
> @@ -427,7 +427,7 @@ int generic_validate_add_page(unsigned l
> for (lbase = base; !(lbase & 1) && (last & 1);
>     lbase = lbase >> 1, last = last >> 1) ;
> if (lbase != last) {
> -  printk(KERN_WARNING "mtrr: base(0x%lx000) is not aligned on a
> size(0x%lx000) boundary\n",
> +  printk(KERN_WARNING "mtrr: base(%#lx000) is not aligned on a size(%#lx000)
> boundary\n",
>       base, size);
> return -EINVAL;
> }
> --- 2012-09-21.orig/xen/arch/x86/cpu/mtrr/main.c 2012-09-21 10:32:44.000000000
> +0200
> +++ 2012-09-21/xen/arch/x86/cpu/mtrr/main.c 2012-09-21 10:54:46.000000000
> +0200
> @@ -366,8 +366,8 @@ int mtrr_add_page(unsigned long base, un
> continue;
> }
> printk(KERN_WARNING
> -          "mtrr: 0x%lx000,0x%lx000 overlaps existing"
> -          " 0x%lx000,0x%lx000\n", base, size, lbase,
> +          "mtrr: %#lx000,%#lx000 overlaps existing"
> +          " %#lx000,%#lx000\n", base, size, lbase,
>       lsize);
> goto out;
> }
> @@ -412,7 +412,7 @@ static int mtrr_check(unsigned long base
> printk(KERN_WARNING
> "mtrr: size and base must be multiples of 4 kiB\n");
> printk(KERN_DEBUG
> -   "mtrr: size: 0x%lx  base: 0x%lx\n", size, base);
> +   "mtrr: size: %#lx  base: %#lx\n", size, base);
> dump_stack();
> return -1;
> }
> --- 2012-09-21.orig/xen/arch/x86/domain_build.c 2012-09-14 13:26:34.000000000
> +0200
> +++ 2012-09-21/xen/arch/x86/domain_build.c 2012-09-21 10:55:47.000000000 +0200
> @@ -396,13 +396,13 @@ int __init construct_dom0(
>      }
>      if (elf_64bit(&elf) && machine == EM_X86_64)
>          compatible = 1;
> -    printk(" Dom0 kernel: %s%s, %s, paddr 0x%" PRIx64 " -> 0x%" PRIx64 "\n",
> +    printk(" Dom0 kernel: %s%s, %s, paddr %#" PRIx64 " -> %#" PRIx64 "\n",
>             elf_64bit(&elf) ? "64-bit" : "32-bit",
>             parms.pae       ? ", PAE"  : "",
>             elf_msb(&elf)   ? "msb"    : "lsb",
>             elf.pstart, elf.pend);
>      if ( elf.bsd_symtab_pstart )
> -        printk(" Dom0 symbol map 0x%" PRIx64 " -> 0x%" PRIx64 "\n",
> +        printk(" Dom0 symbol map %#" PRIx64 " -> %#" PRIx64 "\n",
>                 elf.bsd_symtab_pstart, elf.bsd_symtab_pend);
>  
>      if ( !compatible )
> --- 2012-09-21.orig/xen/arch/x86/hvm/hvm.c 2012-09-20 08:44:38.000000000 +0200
> +++ 2012-09-21/xen/arch/x86/hvm/hvm.c 2012-09-21 10:54:46.000000000 +0200
> @@ -1468,7 +1468,7 @@ int hvm_set_efer(uint64_t value)
>      if ( !hvm_efer_valid(v->domain, value, efer_validbits) )
>      {
>          gdprintk(XENLOG_WARNING, "Trying to set reserved bit in "
> -                 "EFER: 0x%"PRIx64"\n", value);
> +                 "EFER: %#"PRIx64"\n", value);
>          hvm_inject_hw_exception(TRAP_gp_fault, 0);
>          return X86EMUL_EXCEPTION;
>      }
> @@ -4095,7 +4095,7 @@ long do_hvm_op(unsigned long op, XEN_GUE
>              {
>                  put_gfn(d, pfn);
>                  gdprintk(XENLOG_WARNING,
> -                         "type for pfn 0x%lx changed to grant while "
> +                         "type for pfn %#lx changed to grant while "
>                           "we were working?\n", pfn);
>                  goto param_fail4;
>              }
> @@ -4106,7 +4106,7 @@ long do_hvm_op(unsigned long op, XEN_GUE
>                  {
>                      put_gfn(d, pfn);
>                      gdprintk(XENLOG_WARNING,
> -                             "type of pfn 0x%lx changed from %d to %d while "
> +                             "type of pfn %#lx changed from %d to %d while "
>                               "we were trying to change it to %d\n",
>                               pfn, t, nt, memtype[a.hvmmem_type]);
>                      goto param_fail4;
> --- 2012-09-21.orig/xen/arch/x86/hvm/io.c 2012-07-30 09:49:58.000000000 +0200
> +++ 2012-09-21/xen/arch/x86/hvm/io.c 2012-09-21 10:54:46.000000000 +0200
> @@ -393,7 +393,7 @@ int dpci_ioport_intercept(ioreq_t *p)
>  
>      if ( !ioports_access_permitted(d, mport, mport + p->size - 1) )
>      {
> -        gdprintk(XENLOG_ERR, "Error: access to gport=0x%x denied!\n",
> +        gdprintk(XENLOG_ERR, "Error: access to gport=%#x denied!\n",
>                   (uint32_t)p->addr);
>          return X86EMUL_UNHANDLEABLE;
>      }
> --- 2012-09-21.orig/xen/arch/x86/hvm/irq.c 2012-09-14 13:26:34.000000000 +0200
> +++ 2012-09-21/xen/arch/x86/hvm/irq.c 2012-09-21 10:54:46.000000000 +0200
> @@ -488,7 +488,7 @@ static void irq_dump(struct domain *d)
>             hvm_irq->pci_link_assert_count[1],
>             hvm_irq->pci_link_assert_count[2],
>             hvm_irq->pci_link_assert_count[3]);
> -    printk("Callback via %i:0x%"PRIx32",%s asserted\n",
> +    printk("Callback via %i:%#"PRIx32",%s asserted\n",
>             hvm_irq->callback_via_type, hvm_irq->callback_via.gsi,
>             hvm_irq->callback_via_asserted ? "" : " not");
>  }
> --- 2012-09-21.orig/xen/arch/x86/hvm/svm/intr.c 2012-01-20 10:10:22.000000000
> +0100
> +++ 2012-09-21/xen/arch/x86/hvm/svm/intr.c 2012-09-21 10:54:46.000000000 +0200
> @@ -175,7 +175,7 @@ void svm_intr_assist(void)
>                  /* Guest already enabled an interrupt window. */
>                  return;
>              default:
> -                panic("%s: nestedsvm_vcpu_interrupt can't handle value
> 0x%x\n",
> +                panic("%s: nestedsvm_vcpu_interrupt can't handle value
> %#x\n",
>                      __func__, rc);
>              }
>          }
> --- 2012-09-21.orig/xen/arch/x86/hvm/svm/nestedsvm.c 2012-09-05
> 11:59:49.000000000 +0200
> +++ 2012-09-21/xen/arch/x86/hvm/svm/nestedsvm.c 2012-09-21 10:54:46.000000000
> +0200
> @@ -943,7 +943,7 @@ nsvm_vmcb_guest_intercepts_exitcode(stru
>          break;
>  
>      default:
> -        gdprintk(XENLOG_ERR, "Illegal exitcode 0x%"PRIx64"\n", exitcode);
> +        gdprintk(XENLOG_ERR, "Illegal exitcode %#"PRIx64"\n", exitcode);
>          BUG();
>          break;
>      }
> @@ -1235,7 +1235,7 @@ int nsvm_wrmsr(struct vcpu *v, unsigned
>      case MSR_K8_VM_HSAVE_PA:
>          if (!nestedsvm_vmcb_isvalid(v, msr_content)) {
>              gdprintk(XENLOG_ERR,
> -                "MSR_K8_VM_HSAVE_PA value invalid 0x%"PRIx64"\n",
> msr_content);
> +                "MSR_K8_VM_HSAVE_PA value invalid %#"PRIx64"\n",
> msr_content);
>              ret = -1; /* inject #GP */
>              break;
>          }
> @@ -1244,7 +1244,7 @@ int nsvm_wrmsr(struct vcpu *v, unsigned
>      case MSR_AMD64_TSC_RATIO:
>          if ((msr_content & ~TSC_RATIO_RSVD_BITS) != msr_content) {
>              gdprintk(XENLOG_ERR,
> -                "reserved bits set in MSR_AMD64_TSC_RATIO 0x%"PRIx64"\n",
> +                "reserved bits set in MSR_AMD64_TSC_RATIO %#"PRIx64"\n",
>                  msr_content);
>              ret = -1; /* inject #GP */
>              break;
> --- 2012-09-21.orig/xen/arch/x86/hvm/svm/svm.c 2012-09-17 09:57:54.000000000
> +0200
> +++ 2012-09-21/xen/arch/x86/hvm/svm/svm.c 2012-09-21 10:54:46.000000000 +0200
> @@ -241,7 +241,7 @@ static int svm_vmcb_restore(struct vcpu
>           ((c->pending_type == 1) || (c->pending_type > 6) ||
>            (c->pending_reserved != 0)) )
>      {
> -        gdprintk(XENLOG_ERR, "Invalid pending event 0x%"PRIx32".\n",
> +        gdprintk(XENLOG_ERR, "Invalid pending event %#"PRIx32".\n",
>                   c->pending_event);
>          return -EINVAL;
>      }
> @@ -254,7 +254,7 @@ static int svm_vmcb_restore(struct vcpu
>                                       NULL, P2M_ALLOC);
>              if ( !page )
>              {
> -                gdprintk(XENLOG_ERR, "Invalid CR3 value=0x%"PRIx64"\n",
> +                gdprintk(XENLOG_ERR, "Invalid CR3 value=%#"PRIx64"\n",
>                           c->cr3);
>                  return -EINVAL;
>              }
> @@ -289,7 +289,7 @@ static int svm_vmcb_restore(struct vcpu
>  
>      if ( c->pending_valid )
>      {
> -        gdprintk(XENLOG_INFO, "Re-injecting 0x%"PRIx32", 0x%"PRIx32"\n",
> +        gdprintk(XENLOG_INFO, "Re-injecting %#"PRIx32", %#"PRIx32"\n",
>                   c->pending_event, c->error_code);
>  
>          if ( hvm_event_needs_reinjection(c->pending_type, c->pending_vector)
> )
> @@ -2398,8 +2398,8 @@ void svm_vmexit_handler(struct cpu_user_
>  
>      default:
>      exit_and_crash:
> -        gdprintk(XENLOG_ERR, "unexpected VMEXIT: exit reason = 0x%"PRIx64", "
> -                 "exitinfo1 = %"PRIx64", exitinfo2 = %"PRIx64"\n",
> +        gdprintk(XENLOG_ERR, "unexpected VMEXIT: exit reason = %#"PRIx64", "
> +                 "exitinfo1 = %#"PRIx64", exitinfo2 = %#"PRIx64"\n",
>                   exit_reason,
>                   (u64)vmcb->exitinfo1, (u64)vmcb->exitinfo2);
>          domain_crash(v->domain);
> --- 2012-09-21.orig/xen/arch/x86/hvm/svm/svmdebug.c 2011-07-11
> 08:32:12.000000000 +0200
> +++ 2012-09-21/xen/arch/x86/hvm/svm/svmdebug.c 2012-09-21 10:54:46.000000000
> +0200
> @@ -32,33 +32,32 @@ static void svm_dump_sel(const char *nam
>  void svm_vmcb_dump(const char *from, struct vmcb_struct *vmcb)
>  {
>      printk("Dumping guest's current state at %s...\n", from);
> -    printk("Size of VMCB = %d, paddr = 0x%016lx, vaddr = %p\n",
> +    printk("Size of VMCB = %d, paddr = %#lx, vaddr = %p\n",
>             (int) sizeof(struct vmcb_struct), virt_to_maddr(vmcb), vmcb);
>  
> -    printk("cr_intercepts = 0x%08x dr_intercepts = 0x%08x "
> -           "exception_intercepts = 0x%08x\n",
> +    printk("cr_intercepts = %#x dr_intercepts = %#x "
> +           "exception_intercepts = %#x\n",
>             vmcb->_cr_intercepts, vmcb->_dr_intercepts,
>             vmcb->_exception_intercepts);
> -    printk("general1_intercepts = 0x%08x general2_intercepts = 0x%08x\n",
> +    printk("general1_intercepts = %#x general2_intercepts = %#x\n",
>             vmcb->_general1_intercepts, vmcb->_general2_intercepts);
> -    printk("iopm_base_pa = 0x%016llx msrpm_base_pa = 0x%016llx tsc_offset = "
> -            "0x%016llx\n",
> +    printk("iopm_base_pa = %#Lx msrpm_base_pa = %#Lx tsc_offset = %#Lx\n",
>             (unsigned long long)vmcb->_iopm_base_pa,
>             (unsigned long long)vmcb->_msrpm_base_pa,
>             (unsigned long long)vmcb->_tsc_offset);
> -    printk("tlb_control = 0x%08x vintr = 0x%016llx interrupt_shadow = "
> -            "0x%016llx\n", vmcb->tlb_control,
> +    printk("tlb_control = %#x vintr = %#Lx interrupt_shadow = %#Lx\n",
> +           vmcb->tlb_control,
>             (unsigned long long)vmcb->_vintr.bytes,
>             (unsigned long long)vmcb->interrupt_shadow);
> -    printk("exitcode = 0x%016llx exitintinfo = 0x%016llx\n",
> +    printk("exitcode = %#Lx exitintinfo = %#Lx\n",
>             (unsigned long long)vmcb->exitcode,
>             (unsigned long long)vmcb->exitintinfo.bytes);
> -    printk("exitinfo1 = 0x%016llx exitinfo2 = 0x%016llx \n",
> +    printk("exitinfo1 = %#Lx exitinfo2 = %#Lx \n",
>             (unsigned long long)vmcb->exitinfo1,
>             (unsigned long long)vmcb->exitinfo2);
> -    printk("np_enable = 0x%016llx guest_asid = 0x%03x\n",
> +    printk("np_enable = %Lx guest_asid = %#x\n",
>             (unsigned long long)vmcb->_np_enable, vmcb->_guest_asid);
> -    printk("cpl = %d efer = 0x%016llx star = 0x%016llx lstar = 0x%016llx\n",
> +    printk("cpl = %d efer = %#Lx star = %#Lx lstar = %#Lx\n",
>             vmcb->_cpl, (unsigned long long)vmcb->_efer,
>             (unsigned long long)vmcb->star, (unsigned long long)vmcb->lstar);
>      printk("CR0 = 0x%016llx CR2 = 0x%016llx\n",
> @@ -77,7 +76,7 @@ void svm_vmcb_dump(const char *from, str
>      printk("KernGSBase = 0x%016llx PAT = 0x%016llx \n",
>             (unsigned long long)vmcb->kerngsbase,
>             (unsigned long long)vmcb->_g_pat);
> -    printk("H_CR3 = 0x%016llx CleanBits = 0x%08x\n",
> +    printk("H_CR3 = 0x%016llx CleanBits = %#x\n",
>             (unsigned long long)vmcb->_h_cr3, vmcb->cleanbits.bytes);
>  
>      /* print out all the selectors */
> @@ -104,48 +103,48 @@ svm_vmcb_isvalid(const char *from, struc
>      } else return 1;
>  
>      if ((vmcb->_efer & EFER_SVME) == 0) {
> -        PRINTF("EFER: SVME bit not set (0x%"PRIx64")\n", vmcb->_efer);
> +        PRINTF("EFER: SVME bit not set (%#"PRIx64")\n", vmcb->_efer);
>      }
>  
>      if ((vmcb->_cr0 & X86_CR0_CD) == 0 && (vmcb->_cr0 & X86_CR0_NW) != 0) {
> -        PRINTF("CR0: CD bit is zero and NW bit set (0x%"PRIx64")\n",
> +        PRINTF("CR0: CD bit is zero and NW bit set (%#"PRIx64")\n",
>                  vmcb->_cr0);
>      }
>  
>      if ((vmcb->_cr0 >> 32U) != 0) {
> -        PRINTF("CR0: bits [63:32] are not zero (0x%"PRIx64")\n",
> +        PRINTF("CR0: bits [63:32] are not zero (%#"PRIx64")\n",
>                  vmcb->_cr0);
>      }
>  
>      if ((vmcb->_cr3 & 0x7) != 0) {
> -        PRINTF("CR3: MBZ bits are set (0x%"PRIx64")\n", vmcb->_cr3);
> +        PRINTF("CR3: MBZ bits are set (%#"PRIx64")\n", vmcb->_cr3);
>      }
>      if ((vmcb->_efer & EFER_LMA) && (vmcb->_cr3 & 0xfe) != 0) {
> -        PRINTF("CR3: MBZ bits are set (0x%"PRIx64")\n", vmcb->_cr3);
> +        PRINTF("CR3: MBZ bits are set (%#"PRIx64")\n", vmcb->_cr3);
>      }
>  
>      if ((vmcb->_cr4 >> 19U) != 0) {
> -        PRINTF("CR4: bits [63:19] are not zero (0x%"PRIx64")\n",
> +        PRINTF("CR4: bits [63:19] are not zero (%#"PRIx64")\n",
>                  vmcb->_cr4);
>      }
>  
>      if (((vmcb->_cr4 >> 11U) & 0x7fU) != 0) {
> -        PRINTF("CR4: bits [17:11] are not zero (0x%"PRIx64")\n",
> +        PRINTF("CR4: bits [17:11] are not zero (%#"PRIx64")\n",
>                  vmcb->_cr4);
>      }
>  
>      if ((vmcb->_dr6 >> 32U) != 0) {
> -        PRINTF("DR6: bits [63:32] are not zero (0x%"PRIx64")\n",
> +        PRINTF("DR6: bits [63:32] are not zero (%#"PRIx64")\n",
>                  vmcb->_dr6);
>      }
>  
>      if ((vmcb->_dr7 >> 32U) != 0) {
> -        PRINTF("DR7: bits [63:32] are not zero (0x%"PRIx64")\n",
> +        PRINTF("DR7: bits [63:32] are not zero (%#"PRIx64")\n",
>                  vmcb->_dr7);
>      }
>  
>      if ((vmcb->_efer >> 15U) != 0) {
> -        PRINTF("EFER: bits [63:15] are not zero (0x%"PRIx64")\n",
> +        PRINTF("EFER: bits [63:15] are not zero (%#"PRIx64")\n",
>                  vmcb->_efer);
>      }
>  
> @@ -168,12 +167,12 @@ svm_vmcb_isvalid(const char *from, struc
>      }
>  
>      if ((vmcb->_general2_intercepts & GENERAL2_INTERCEPT_VMRUN) == 0) {
> -        PRINTF("GENERAL2_INTERCEPT: VMRUN intercept bit is clear
> (0x%"PRIx32")\n",
> +        PRINTF("GENERAL2_INTERCEPT: VMRUN intercept bit is clear
> (%#"PRIx32")\n",
>              vmcb->_general2_intercepts);
>      }
>  
>      if (vmcb->eventinj.fields.resvd1 != 0) {
> -        PRINTF("eventinj: MBZ bits are set (0x%"PRIx64")\n",
> +        PRINTF("eventinj: MBZ bits are set (%#"PRIx64")\n",
>                  vmcb->eventinj.bytes);
>      }
>  
> --- 2012-09-21.orig/xen/arch/x86/hvm/vlapic.c 2012-09-20 08:44:38.000000000
> +0200
> +++ 2012-09-21/xen/arch/x86/hvm/vlapic.c 2012-09-21 10:54:46.000000000 +0200
> @@ -172,7 +172,7 @@ static uint32_t vlapic_get_ppr(struct vl
>          ppr = isrv & 0xf0;
>  
>      HVM_DBG_LOG(DBG_LEVEL_VLAPIC_INTERRUPT,
> -                "vlapic %p, ppr 0x%x, isr 0x%x, isrv 0x%x",
> +                "vlapic %p, ppr %#x, isr %#x, isrv %#x",
>                  vlapic, ppr, isr, isrv);
>  
>      return ppr;
> @@ -215,8 +215,8 @@ bool_t vlapic_match_dest(
>      struct vlapic *target, struct vlapic *source,
>      int short_hand, uint8_t dest, uint8_t dest_mode)
>  {
> -    HVM_DBG_LOG(DBG_LEVEL_VLAPIC, "target %p, source %p, dest 0x%x, "
> -                "dest_mode 0x%x, short_hand 0x%x",
> +    HVM_DBG_LOG(DBG_LEVEL_VLAPIC, "target %p, source %p, dest %#x, "
> +                "dest_mode %#x, short_hand %#x",
>                  target, source, dest, dest_mode, short_hand);
>  
>      switch ( short_hand )
> @@ -562,20 +562,20 @@ static int vlapic_read(
>          break;
>  
>      default:
> -        gdprintk(XENLOG_ERR, "Local APIC read with len=0x%lx, "
> +        gdprintk(XENLOG_ERR, "Local APIC read with len=%#lx, "
>                   "should be 4 instead.\n", len);
>          goto exit_and_crash;
>      }
>  
> -    HVM_DBG_LOG(DBG_LEVEL_VLAPIC, "offset 0x%x with length 0x%lx, "
> -                "and the result is 0x%lx", offset, len, result);
> +    HVM_DBG_LOG(DBG_LEVEL_VLAPIC, "offset %#x with length %#lx, "
> +                "and the result is %#lx", offset, len, result);
>  
>   out:
>      *pval = result;
>      return X86EMUL_OKAY;
>  
>   unaligned_exit_and_crash:
> -    gdprintk(XENLOG_ERR, "Unaligned LAPIC read len=0x%lx at offset=0x%x.\n",
> +    gdprintk(XENLOG_ERR, "Unaligned LAPIC read len=%#lx at offset=%#x.\n",
>               len, offset);
>   exit_and_crash:
>      domain_crash(v->domain);
> @@ -759,7 +759,7 @@ static int vlapic_reg_write(struct vcpu
>  
>      case APIC_TDCR:
>          vlapic_set_tdcr(vlapic, val & 0xb);
> -        HVM_DBG_LOG(DBG_LEVEL_VLAPIC_TIMER, "timer divisor is 0x%x",
> +        HVM_DBG_LOG(DBG_LEVEL_VLAPIC_TIMER, "timer divisor is %#x",
>                      vlapic->hw.timer_divisor);
>          break;
>  
> @@ -768,7 +768,7 @@ static int vlapic_reg_write(struct vcpu
>      }
>      if (rc == X86EMUL_UNHANDLEABLE)
>          gdprintk(XENLOG_DEBUG,
> -                "Local APIC Write wrong to register 0x%x\n", offset);
> +                "Local APIC Write wrong to register %#x\n", offset);
>      return rc;
>  }
>  
> @@ -781,7 +781,7 @@ static int vlapic_write(struct vcpu *v,
>  
>      if ( offset != 0xb0 )
>          HVM_DBG_LOG(DBG_LEVEL_VLAPIC,
> -                    "offset 0x%x with length 0x%lx, and value is 0x%lx",
> +                    "offset %#x with length %#lx, and value is %#lx",
>                      offset, len, val);
>  
>      /*
> @@ -827,7 +827,7 @@ static int vlapic_write(struct vcpu *v,
>      return vlapic_reg_write(v, offset, val);
>  
>   unaligned_exit_and_crash:
> -    gdprintk(XENLOG_ERR, "Unaligned LAPIC write len=0x%lx at offset=0x%x.\n",
> +    gdprintk(XENLOG_ERR, "Unaligned LAPIC write len=%#lx at offset=%#x.\n",
>               len, offset);
>   exit_and_crash:
>      domain_crash(v->domain);
> --- 2012-09-21.orig/xen/arch/x86/hvm/vmx/vmcs.c 2012-09-20 08:44:38.000000000
> +0200
> +++ 2012-09-21/xen/arch/x86/hvm/vmx/vmcs.c 2012-09-21 10:54:46.000000000 +0200
> @@ -121,7 +121,7 @@ static u32 adjust_vmx_controls(
>  static bool_t cap_check(const char *name, u32 expected, u32 saw)
>  {
>      if ( saw != expected )
> -        printk("VMX %s: saw 0x%08x expected 0x%08x\n", name, saw, expected);
> +        printk("VMX %s: saw %#x expected %#x\n", name, saw, expected);
>      return saw != expected;
>  }
>  
> --- 2012-09-21.orig/xen/arch/x86/hvm/vmx/vmx.c 2012-09-20 08:44:38.000000000
> +0200
> +++ 2012-09-21/xen/arch/x86/hvm/vmx/vmx.c 2012-09-21 11:01:46.000000000 +0200
> @@ -210,7 +210,7 @@ long_mode_do_msr_read(unsigned int msr,
>          return HNDL_unhandled;
>      }
>  
> -    HVM_DBG_LOG(DBG_LEVEL_0, "msr 0x%x content 0x%"PRIx64, msr,
> *msr_content);
> +    HVM_DBG_LOG(DBG_LEVEL_0, "msr %#x content %#"PRIx64, msr, *msr_content);
>  
>      return HNDL_done;
>  }
> @@ -222,7 +222,7 @@ long_mode_do_msr_write(unsigned int msr,
>      struct vmx_msr_state *guest_msr_state = &v->arch.hvm_vmx.msr_state;
>      struct vmx_msr_state *host_msr_state = &this_cpu(host_msr_state);
>  
> -    HVM_DBG_LOG(DBG_LEVEL_0, "msr 0x%x content 0x%"PRIx64, msr, msr_content);
> +    HVM_DBG_LOG(DBG_LEVEL_0, "msr %#x content %#"PRIx64, msr, msr_content);
>  
>      switch ( msr )
>      {
> @@ -466,7 +466,7 @@ static int vmx_restore_cr0_cr3(
>                                       NULL, P2M_ALLOC);
>              if ( !page )
>              {
> -                gdprintk(XENLOG_ERR, "Invalid CR3 value=0x%lx\n", cr3);
> +                gdprintk(XENLOG_ERR, "Invalid CR3 value=%#lx\n", cr3);
>                  return -EINVAL;
>              }
>          }
> @@ -492,7 +492,7 @@ static int vmx_vmcs_restore(struct vcpu
>           ((c->pending_type == 1) || (c->pending_type > 6) ||
>            (c->pending_reserved != 0)) )
>      {
> -        gdprintk(XENLOG_ERR, "Invalid pending event 0x%"PRIx32".\n",
> +        gdprintk(XENLOG_ERR, "Invalid pending event %#"PRIx32".\n",
>                   c->pending_event);
>          return -EINVAL;
>      }
> @@ -524,7 +524,7 @@ static int vmx_vmcs_restore(struct vcpu
>  
>      if ( c->pending_valid )
>      {
> -        gdprintk(XENLOG_INFO, "Re-injecting 0x%"PRIx32", 0x%"PRIx32"\n",
> +        gdprintk(XENLOG_INFO, "Re-injecting %#"PRIx32", %#"PRIx32"\n",
>                   c->pending_event, c->error_code);
>  
>          if ( hvm_event_needs_reinjection(c->pending_type, c->pending_vector)
> )
> @@ -1789,7 +1789,7 @@ static int is_last_branch_msr(u32 ecx)
>  
>  static int vmx_msr_read_intercept(unsigned int msr, uint64_t *msr_content)
>  {
> -    HVM_DBG_LOG(DBG_LEVEL_1, "ecx=%x", msr);
> +    HVM_DBG_LOG(DBG_LEVEL_1, "ecx=%#x", msr);
>  
>      switch ( msr )
>      {
> @@ -1854,7 +1854,7 @@ static int vmx_msr_read_intercept(unsign
>      }
>  
>  done:
> -    HVM_DBG_LOG(DBG_LEVEL_1, "returns: ecx=%x, msr_value=0x%"PRIx64,
> +    HVM_DBG_LOG(DBG_LEVEL_1, "returns: ecx=%#x, msr_value=%#"PRIx64,
>                  msr, *msr_content);
>      return X86EMUL_OKAY;
>  
> @@ -1927,8 +1927,7 @@ static int vmx_msr_write_intercept(unsig
>  {
>      struct vcpu *v = current;
>  
> -    HVM_DBG_LOG(DBG_LEVEL_1, "ecx=%x, msr_value=0x%"PRIx64,
> -                msr, msr_content);
> +    HVM_DBG_LOG(DBG_LEVEL_1, "ecx=%#x, msr_value=%#"PRIx64, msr,
> msr_content);
>  
>      switch ( msr )
>      {
> @@ -2107,7 +2106,7 @@ static void vmx_failed_vmentry(unsigned
>      unsigned long exit_qualification = __vmread(EXIT_QUALIFICATION);
>      struct vcpu *curr = current;
>  
> -    printk("Failed vm entry (exit reason 0x%x) ", exit_reason);
> +    printk("Failed vm entry (exit reason %#x) ", exit_reason);
>      switch ( failed_vmentry_reason )
>      {
>      case EXIT_REASON_INVALID_GUEST_STATE:
> --- 2012-09-21.orig/xen/arch/x86/io_apic.c 2012-09-21 10:32:44.000000000 +0200
> +++ 2012-09-21/xen/arch/x86/io_apic.c 2012-09-21 10:54:46.000000000 +0200
> @@ -2204,7 +2204,7 @@ int io_apic_set_pci_routing (int ioapic,
>      entry.vector = vector;
>  
>      apic_printk(APIC_DEBUG, KERN_DEBUG "IOAPIC[%d]: Set PCI routing entry "
> -  "(%d-%d -> 0x%x -> IRQ %d Mode:%i Active:%i)\n", ioapic,
> +  "(%d-%d -> %#x -> IRQ %d Mode:%i Active:%i)\n", ioapic,
> mp_ioapics[ioapic].mpc_apicid, pin, entry.vector, irq,
> edge_level, active_high_low);
>  
> --- 2012-09-21.orig/xen/arch/x86/microcode_amd.c 2012-02-10 11:25:54.000000000
> +0100
> +++ 2012-09-21/xen/arch/x86/microcode_amd.c 2012-09-21 10:54:46.000000000
> +0200
> @@ -88,7 +88,7 @@ static int collect_cpu_info(int cpu, str
>  
>      rdmsrl(MSR_AMD_PATCHLEVEL, csig->rev);
>  
> -    printk(KERN_DEBUG "microcode: collect_cpu_info: patch_id=0x%x\n",
> +    printk(KERN_DEBUG "microcode: collect_cpu_info: patch_id=%#x\n",
>             csig->rev);
>  
>      return 0;
> @@ -132,7 +132,7 @@ static int microcode_fits(const struct m
>          return 0;
>  
>      printk(KERN_DEBUG "microcode: CPU%d found a matching microcode "
> -           "update with version 0x%x (current=0x%x)\n",
> +           "update with version %#x (current=%#x)\n",
>             cpu, mc_header->patch_id, uci->cpu_sig.rev);
>  
>      return 1;
> @@ -169,7 +169,7 @@ static int apply_microcode(int cpu)
>      if ( rev != hdr->patch_id )
>      {
>          printk(KERN_ERR "microcode: CPU%d update from revision "
> -               "0x%x to 0x%x failed\n", cpu, hdr->patch_id, rev);
> +               "%#x to %#x failed\n", cpu, hdr->patch_id, rev);
>          return -EIO;
>      }
>  
> --- 2012-09-21.orig/xen/arch/x86/microcode_intel.c 2011-12-12
> 09:01:34.000000000 +0100
> +++ 2012-09-21/xen/arch/x86/microcode_intel.c 2012-09-21 10:54:46.000000000
> +0200
> @@ -122,7 +122,7 @@ static int collect_cpu_info(int cpu_num,
>      /* get the current revision from MSR 0x8B */
>      rdmsrl(MSR_IA32_UCODE_REV, msr_content);
>      csig->rev = (uint32_t)(msr_content >> 32);
> -    pr_debug("microcode: collect_cpu_info : sig=0x%x, pf=0x%x, rev=0x%x\n",
> +    pr_debug("microcode: collect_cpu_info : sig=%#x, pf=%#x, rev=%#x\n",
>               csig->sig, csig->pf, csig->rev);
>  
>      return 0;
> @@ -264,7 +264,7 @@ static int get_matching_microcode(const
>      if ( uci->mc.mc_intel && uci->mc.mc_intel->hdr.rev >= mc_header->rev )
>          return 0;
>      pr_debug("microcode: CPU%d found a matching microcode update with"
> -             " version 0x%x (current=0x%x)\n",
> +             " version %#x (current=%#x)\n",
>               cpu, mc_header->rev, uci->cpu_sig.rev);
>      new_mc = xmalloc_bytes(total_size);
>      if ( new_mc == NULL )
> @@ -311,11 +311,11 @@ static int apply_microcode(int cpu)
>      if ( val[1] != uci->mc.mc_intel->hdr.rev )
>      {
>          printk(KERN_ERR "microcode: CPU%d update from revision "
> -               "0x%x to 0x%x failed\n", cpu_num, uci->cpu_sig.rev, val[1]);
> +               "%#x to %#x failed\n", cpu_num, uci->cpu_sig.rev, val[1]);
>          return -EIO;
>      }
>      printk(KERN_INFO "microcode: CPU%d updated from revision "
> -           "0x%x to 0x%x, date = %04x-%02x-%02x \n",
> +           "%#x to %#x, date = %04x-%02x-%02x \n",
>             cpu_num, uci->cpu_sig.rev, val[1],
>             uci->mc.mc_intel->hdr.date & 0xffff,
>             uci->mc.mc_intel->hdr.date >> 24,
> --- 2012-09-21.orig/xen/arch/x86/mm.c 2012-09-14 13:26:34.000000000 +0200
> +++ 2012-09-21/xen/arch/x86/mm.c 2012-09-21 10:54:46.000000000 +0200
> @@ -3102,7 +3102,7 @@ long do_mmuext_op(
>          }
>  
>          default:
> -            MEM_LOG("Invalid extended pt command 0x%x", op.cmd);
> +            MEM_LOG("Invalid extended pt command %#x", op.cmd);
>              rc = -ENOSYS;
>              okay = 0;
>              break;
> --- 2012-09-21.orig/xen/arch/x86/mm/hap/nested_hap.c 2012-08-08 
> 08:20:09.000000000 +0200
> +++ 2012-09-21/xen/arch/x86/mm/hap/nested_hap.c 2012-09-21 10:54:46.000000000 
> +0200
> @@ -129,7 +129,7 @@ nestedhap_fix_p2m(struct vcpu *v, struct
>  
>      if (rv == 0) {
>          gdprintk(XENLOG_ERR,
> -  "failed to set entry for 0x%"PRIx64" -> 0x%"PRIx64"\n",
> +  "failed to set entry for %#"PRIx64" -> %#"PRIx64"\n",
> L2_gpa, L0_gpa);
>          BUG();
>      }
> --- 2012-09-21.orig/xen/arch/x86/mm/p2m-pt.c 2012-09-14 13:26:34.000000000 
> +0200
> +++ 2012-09-21/xen/arch/x86/mm/p2m-pt.c 2012-09-21 10:54:46.000000000 +0200
> @@ -110,8 +110,8 @@ p2m_find_entry(void *table, unsigned lon
>      index = *gfn_remainder >> shift;
>      if ( index >= max )
>      {
> -        P2M_DEBUG("gfn=0x%lx out of range "
> -                  "(gfn_remainder=0x%lx shift=%d index=0x%x max=0x%x)\n",
> +        P2M_DEBUG("gfn=%#lx out of range "
> +                  "(gfn_remainder=%#lx shift=%d index=%#x max=%#x)\n",
>                    gfn, *gfn_remainder, shift, index, max);
>          return NULL;
>      }
> --- 2012-09-21.orig/xen/arch/x86/mm/shadow/common.c 2012-09-14 
> 13:26:34.000000000 +0200
> +++ 2012-09-21/xen/arch/x86/mm/shadow/common.c 2012-09-21 10:57:38.000000000 
> +0200
> @@ -872,7 +872,7 @@ static int sh_skip_sync(struct vcpu *v, 
>          return SHADOW_INTERNAL_NAME(sh_safe_not_to_sync, 3)(v, gl1mfn);
>      else if ( pg->shadow_flags & SHF_L1_64 )
>          return SHADOW_INTERNAL_NAME(sh_safe_not_to_sync, 4)(v, gl1mfn);
> -    SHADOW_ERROR("gmfn 0x%lx was OOS but not shadowed as an l1.\n", 
> +    SHADOW_ERROR("gmfn %#lx was OOS but not shadowed as an l1.\n",
>                   mfn_x(gl1mfn));
>      BUG();
>      return 0; /* BUG() is no longer __attribute__((noreturn)). */
> @@ -2596,8 +2596,8 @@ void sh_remove_shadows(struct vcpu *v, m
>      smfn = shadow_hash_lookup(v, mfn_x(gmfn), t);                       \
>      if ( unlikely(!mfn_valid(smfn)) )                                   \
>      {                                                                   \
> -        SHADOW_ERROR(": gmfn %#lx has flags 0x%"PRIx32                  \
> -                     " but no type-0x%"PRIx32" shadow\n",               \
> +        SHADOW_ERROR(": gmfn %#lx has flags %#"PRIx32                   \
> +                     " but no type-%#"PRIx32" shadow\n",                \
>                       mfn_x(gmfn), (uint32_t)pg->shadow_flags, t);       \
>          break;                                                          \
>      }                                                                   \
> --- 2012-09-21.orig/xen/arch/x86/mm/shadow/multi.c 2012-09-14 
> 13:26:34.000000000 +0200
> +++ 2012-09-21/xen/arch/x86/mm/shadow/multi.c 2012-09-21 10:54:46.000000000 
> +0200
> @@ -2171,7 +2171,7 @@ static int validate_gl4e(struct vcpu *v,
>              // attempt by the guest to write to a xen reserved slot
>              //
>              SHADOW_PRINTK("%s out-of-range update "
> -                           "sl4mfn=%05lx index=0x%x val=%" SH_PRI_pte "\n",
> +                           "sl4mfn=%05lx index=%#x val=%" SH_PRI_pte "\n",
>                             __func__, mfn_x(sl4mfn), shadow_index, 
> new_sl4e.l4);
>              if ( shadow_l4e_get_flags(new_sl4e) & _PAGE_PRESENT )
>              {
> --- 2012-09-21.orig/xen/arch/x86/mpparse.c 2012-04-20 09:49:25.000000000 +0200
> +++ 2012-09-21/xen/arch/x86/mpparse.c 2012-09-21 10:54:46.000000000 +0200
> @@ -216,7 +216,7 @@ static void __init MP_ioapic_info (struc
> if (!(m->mpc_flags & MPC_APIC_USABLE))
> return;
>  
> - printk(KERN_INFO "I/O APIC #%d Version %d at 0x%X.\n",
> + printk(KERN_INFO "I/O APIC #%d Version %d at %#x.\n",
> m->mpc_apicid, m->mpc_apicver, m->mpc_apicaddr);
> if (nr_ioapics >= MAX_IO_APICS) {
> printk(KERN_CRIT "Max # of I/O APICs (%d) exceeded (found %d).\n",
> @@ -278,7 +278,7 @@ static int __init smp_read_mpc(struct mp
> unsigned char *mpt=((unsigned char *)mpc)+count;
>  
> if (memcmp(mpc->mpc_signature,MPC_SIGNATURE,4)) {
> -  printk(KERN_ERR "SMP mptable: bad signature [0x%x]!\n",
> +  printk(KERN_ERR "SMP mptable: bad signature [%#x]!\n",
> *(u32 *)mpc->mpc_signature);
> return 0;
> }
> @@ -305,7 +305,7 @@ static int __init smp_read_mpc(struct mp
>  
> mps_oem_check(mpc, oem, str);
>  
> - printk("APIC at: 0x%X\n",mpc->mpc_lapic);
> + printk("APIC at: %#x\n", mpc->mpc_lapic);
>  
> /* 
> * Save the local APIC address (it might be non-default) -- but only
> @@ -881,7 +881,7 @@ void __init mp_register_ioapic (
> mp_ioapic_routing[idx].gsi_end = gsi_base + 
> io_apic_get_redir_entries(idx);
>  
> - printk("IOAPIC[%d]: apic_id %d, version %d, address 0x%x, "
> + printk("IOAPIC[%d]: apic_id %d, version %d, address %#x, "
> "GSI %d-%d\n", idx, mp_ioapics[idx].mpc_apicid, 
> mp_ioapics[idx].mpc_apicver, mp_ioapics[idx].mpc_apicaddr,
> mp_ioapic_routing[idx].gsi_base,
> --- 2012-09-21.orig/xen/arch/x86/nmi.c 2012-08-08 08:20:09.000000000 +0200
> +++ 2012-09-21/xen/arch/x86/nmi.c 2012-09-21 10:54:46.000000000 +0200
> @@ -245,7 +245,7 @@ static inline void write_watchdog_counte
>  
>      do_div(count, nmi_hz);
>      if(descr)
> -        Dprintk("setting %s to -0x%"PRIx64"\n", descr, count);
> +        Dprintk("setting %s to -%#"PRIx64"\n", descr, count);
>      wrmsrl(nmi_perfctr_msr, 0 - count);
>  }
>  
> --- 2012-09-21.orig/xen/arch/x86/oprofile/op_model_athlon.c 2012-09-14 
> 13:26:34.000000000 +0200
> +++ 2012-09-21/xen/arch/x86/oprofile/op_model_athlon.c 2012-09-21 
> 10:54:46.000000000 +0200
> @@ -478,7 +478,7 @@ static int __init init_ibs_nmi(void)
> if (value != (IBSCTL_LVTOFFSETVAL |
> APIC_EILVT_LVTOFF_IBS)) {
> printk("Xenoprofile: Failed to setup IBS LVT offset, "
> -       "IBSCTL = %#08x\n", value);
> +       "IBSCTL = %#x\n", value);
> return 1;
> }
> nodes++;
> @@ -523,7 +523,7 @@ void __init ibs_init(void)
> return;
> }
>  
> - printk("Xenoprofile: AMD IBS detected (0x%08x)\n",
> + printk("Xenoprofile: AMD IBS detected (%#x)\n",
> (unsigned)ibs_caps);
>  }
>  
> --- 2012-09-21.orig/xen/arch/x86/oprofile/op_model_p4.c 2012-02-10 
> 11:25:54.000000000 +0100
> +++ 2012-09-21/xen/arch/x86/oprofile/op_model_p4.c 2012-09-21 
> 10:54:46.000000000 +0200
> @@ -485,8 +485,7 @@ static void pmc_setup_one_p4_counter(uns
> 
> /* find our event binding structure. */
> if (counter_config[ctr].event <= 0 || counter_config[ctr].event > NUM_EVENTS) 
> {
> -  printk(KERN_ERR 
> -         "oprofile: P4 event code 0x%lx out of range\n", 
> +  printk(KERN_ERR "oprofile: P4 event code %#lx out of range\n",
>       counter_config[ctr].event);
> return;
> }
> @@ -526,7 +525,7 @@ static void pmc_setup_one_p4_counter(uns
> }
>  
> printk(KERN_ERR 
> -        "oprofile: P4 event code 0x%lx no binding, stag %d ctr %d\n",
> +        "oprofile: P4 event code %#lx no binding, stag %d ctr %d\n",
>       counter_config[ctr].event, stag, ctr);
>  }
>  
> --- 2012-09-21.orig/xen/arch/x86/setup.c 2012-09-17 09:57:54.000000000 +0200
> +++ 2012-09-21/xen/arch/x86/setup.c 2012-09-21 11:01:12.000000000 +0200
> @@ -482,13 +482,13 @@ static void __init kexec_reserve_area(st
>  
>      if ( !reserve_e820_ram(e820, kdump_start, kdump_start + kdump_size) )
>      {
> -        printk("Kdump: DISABLED (failed to reserve %luMB (%lukB) at 0x%lx)"
> +        printk("Kdump: DISABLED (failed to reserve %luMB (%lukB) at %#lx)"
>                 "\n", kdump_size >> 20, kdump_size >> 10, kdump_start);
>          kexec_crash_area.start = kexec_crash_area.size = 0;
>      }
>      else
>      {
> -        printk("Kdump: %luMB (%lukB) at 0x%lx\n",
> +        printk("Kdump: %luMB (%lukB) at %#lx\n",
>                 kdump_size >> 20, kdump_size >> 10, kdump_start);
>      }
>  }
> --- 2012-09-21.orig/xen/arch/x86/tboot.c 2012-01-20 10:10:22.000000000 +0100
> +++ 2012-09-21/xen/arch/x86/tboot.c 2012-09-21 10:54:46.000000000 +0200
> @@ -119,12 +119,12 @@ void __init tboot_probe(void)
>      g_tboot_shared = tboot_shared;
>      printk("TBOOT: found shared page at phys addr %lx:\n", p_tboot_shared);
>      printk("  version: %d\n", tboot_shared->version);
> -    printk("  log_addr: 0x%08x\n", tboot_shared->log_addr);
> -    printk("  shutdown_entry: 0x%08x\n", tboot_shared->shutdown_entry);
> -    printk("  tboot_base: 0x%08x\n", tboot_shared->tboot_base);
> -    printk("  tboot_size: 0x%x\n", tboot_shared->tboot_size);
> +    printk("  log_addr: %#x\n", tboot_shared->log_addr);
> +    printk("  shutdown_entry: %#x\n", tboot_shared->shutdown_entry);
> +    printk("  tboot_base: %#x\n", tboot_shared->tboot_base);
> +    printk("  tboot_size: %#x\n", tboot_shared->tboot_size);
>      if ( tboot_shared->version >= 6 )
> -        printk("  flags: 0x%08x\n", tboot_shared->flags);
> +        printk("  flags: %#x\n", tboot_shared->flags);
>  
>      /* these will be needed by tboot_protect_mem_regions() and/or
>         tboot_parse_dmar_table(), so get them now */
> @@ -352,7 +352,7 @@ void tboot_shutdown(uint32_t shutdown_ty
>                             __PAGE_HYPERVISOR);
>      if ( err != 0 )
>      {
> -        printk("error (0x%x) mapping tboot pages (mfns) @ 0x%x, 0x%x\n", err,
> +        printk("error (%#x) mapping tboot pages (mfns) @ %#x, %#x\n", err,
>                 map_base, map_size);
>          return;
>      }
> --- 2012-09-21.orig/xen/arch/x86/time.c 2012-09-14 13:26:34.000000000 +0200
> +++ 2012-09-21/xen/arch/x86/time.c 2012-09-21 10:54:46.000000000 +0200
> @@ -1955,11 +1955,11 @@ static void dump_softtsc(unsigned char k
>          printk("dom%u%s: mode=%d",d->domain_id,
>                  is_hvm_domain(d) ? "(hvm)" : "", d->arch.tsc_mode);
>          if ( d->arch.vtsc_offset )
> -            printk(",ofs=0x%"PRIx64"",d->arch.vtsc_offset);
> +            printk(",ofs=%#"PRIx64, d->arch.vtsc_offset);
>          if ( d->arch.tsc_khz )
> -            printk(",khz=%"PRIu32"",d->arch.tsc_khz);
> +            printk(",khz=%"PRIu32, d->arch.tsc_khz);
>          if ( d->arch.incarnation )
> -            printk(",inc=%"PRIu32"",d->arch.incarnation);
> +            printk(",inc=%"PRIu32, d->arch.incarnation);
>          if ( !(d->arch.vtsc_kerncount | d->arch.vtsc_usercount) )
>          {
>              printk("\n");
> --- 2012-09-21.orig/xen/arch/x86/xstate.c 2012-01-30 10:46:14.000000000 +0100
> +++ 2012-09-21/xen/arch/x86/xstate.c 2012-09-21 10:54:46.000000000 +0200
> @@ -163,7 +163,7 @@ void xstate_init(void)
>          xsave_cntxt_size = ebx;
>          xfeature_mask = eax + ((u64)edx << 32);
>          xfeature_mask &= XCNTXT_MASK;
> -        printk("%s: using cntxt_size: 0x%x and states: 0x%"PRIx64"\n",
> +        printk("%s: using cntxt_size: %#x and states: %#"PRIx64"\n",
>              __func__, xsave_cntxt_size, xfeature_mask);
>  
>          /* Check XSAVEOPT feature. */
> --- 2012-09-21.orig/xen/common/gdbstub.c 2010-05-20 09:59:27.000000000 +0200
> +++ 2012-09-21/xen/common/gdbstub.c 2012-09-21 10:54:46.000000000 +0200
> @@ -263,7 +263,7 @@ gdb_write_to_packet_hex(unsigned long x,
>      case sizeof(u64):
>          break;
>      default:
> -        dbg_printk("WARNING: %s x: 0x%lx int_size: %d\n",
> +        dbg_printk("WARNING: %s x: %#lx int_size: %d\n",
>                     __func__, x, int_size);
>          break;
>      }
> --- 2012-09-21.orig/xen/common/page_alloc.c 2012-09-14 13:26:34.000000000 
> +0200
> +++ 2012-09-21/xen/common/page_alloc.c 2012-09-21 10:54:46.000000000 +0200
> @@ -367,7 +367,7 @@ static void __init setup_low_mem_virq(vo
>      low_mem_virq_th = low_mem_virq_orig = 1UL << order;
>      low_mem_virq_th_order = order;
>  
> -    printk("Initial low memory virq threshold set at 0x%lx pages.\n",
> +    printk("Initial low memory virq threshold set at %#lx pages.\n",
>              low_mem_virq_th);
>  }
>  
> --- 2012-09-21.orig/xen/common/vsprintf.c 2012-02-10 11:25:54.000000000 +0100
> +++ 2012-09-21/xen/common/vsprintf.c 2012-09-21 10:54:46.000000000 +0200
> @@ -171,10 +171,14 @@ static char *number(
>          }
>      }
>      if (type & SPECIAL) {
> -        if (base == 16)
> +        if (num == 0)
> +            type &= ~SPECIAL;
> +        else if (base == 16)
>              size -= 2;
>          else if (base == 8)
>              size--;
> +        else
> +            type &= ~SPECIAL;
>      }
>      i = 0;
>      if (num == 0)
> @@ -197,14 +201,10 @@ static char *number(
>          ++buf;
>      }
>      if (type & SPECIAL) {
> -        if (base==8) {
> -            if (buf <= end)
> -                *buf = '0';
> -            ++buf;
> -        } else if (base==16) {
> -            if (buf <= end)
> -                *buf = '0';
> -            ++buf;
> +        if (buf <= end)
> +            *buf = '0';
> +        ++buf;
> +        if (base == 16) {
>              if (buf <= end)
>                  *buf = digits[33];
>              ++buf;
> --- 2012-09-21.orig/xen/common/xencomm.c 2012-01-24 10:11:51.000000000 +0100
> +++ 2012-09-21/xen/common/xencomm.c 2012-09-21 10:54:46.000000000 +0200
> @@ -58,7 +58,7 @@ xencomm_get_page(unsigned long paddr, st
>           * is freed with decrease reservation hypercall at the same time.
>           */
>          gdprintk(XENLOG_WARNING,
> -                 "bad page is passed. paddr 0x%lx maddr 0x%lx\n",
> +                 "bad page is passed. paddr %#lx maddr %#lx\n",
>                   paddr, maddr);
>          return -EFAULT;
>      }
> @@ -117,7 +117,7 @@ xencomm_ctxt_init(const void *handle, st
>      desc = xencomm_vaddr((unsigned long)handle, page);
>      if ( desc->magic != XENCOMM_MAGIC )
>      {
> -        printk("%s: error: %p magic was 0x%x\n", __func__, desc, 
> desc->magic);
> +        printk("%s: error: %p magic was %#x\n", __func__, desc, desc->magic);
>          put_page(page);
>          return -EINVAL;
>      }
> --- 2012-09-21.orig/xen/drivers/acpi/numa.c 2012-09-14 13:26:34.000000000 
> +0200
> +++ 2012-09-21/xen/drivers/acpi/numa.c 2012-09-21 10:54:46.000000000 +0200
> @@ -78,8 +78,8 @@ void __init acpi_table_print_srat_entry(
> if (srat_rev < 2)
> proximity_domain &= 0xff;
> ACPI_DEBUG_PRINT((ACPI_DB_INFO,
> -       "SRAT Memory (%#016"PRIx64
> -       " length %#016"PRIx64")"
> +       "SRAT Memory (%#"PRIx64
> +       " length %#"PRIx64")"
>  " in proximity domain %d %s%s\n",
>  p->base_address, p->length,
>  proximity_domain,
> @@ -108,7 +108,7 @@ void __init acpi_table_print_srat_entry(
> break;
> default:
> printk(KERN_WARNING PREFIX
> -         "Found unsupported SRAT entry (type = 0x%x)\n",
> +         "Found unsupported SRAT entry (type = %#x)\n",
>       header->type);
> break;
> }
> --- 2012-09-21.orig/xen/drivers/acpi/tables.c 2012-09-21 10:32:44.000000000 
> +0200
> +++ 2012-09-21/xen/drivers/acpi/tables.c 2012-09-21 10:54:46.000000000 +0200
> @@ -95,7 +95,7 @@ void __init acpi_table_print_madt_entry(
> if (p->inti_flags  &
>    ~(ACPI_MADT_POLARITY_MASK | ACPI_MADT_TRIGGER_MASK))
> printk(KERN_INFO PREFIX
> -           "INT_SRC_OVR unexpected reserved flags: 0x%x\n",
> +           "INT_SRC_OVR unexpected reserved flags: %#x\n",
>       p->inti_flags  &
> ~(ACPI_MADT_POLARITY_MASK | ACPI_MADT_TRIGGER_MASK));
>  
> @@ -119,7 +119,7 @@ void __init acpi_table_print_madt_entry(
> struct acpi_madt_local_apic_nmi *p =
>    (struct acpi_madt_local_apic_nmi *)header;
> printk(KERN_INFO PREFIX
> -          "LAPIC_NMI (acpi_id[0x%02x] %s %s lint[0x%x])\n",
> +          "LAPIC_NMI (acpi_id[0x%02x] %s %s lint[%#x])\n",
>       p->processor_id,
>       mps_inti_flags_polarity[p->inti_flags & ACPI_MADT_POLARITY_MASK ],
>       mps_inti_flags_trigger[(p->inti_flags & ACPI_MADT_TRIGGER_MASK) >> 2],
> @@ -137,7 +137,7 @@ void __init acpi_table_print_madt_entry(
> trigger = (p->inti_flags & ACPI_MADT_TRIGGER_MASK) >> 2;
>  
> printk(KERN_INFO PREFIX
> -          "X2APIC_NMI (uid[0x%02x] %s %s lint[0x%x])\n",
> +          "X2APIC_NMI (uid[0x%02x] %s %s lint[%#x])\n",
>       p->uid,
>       mps_inti_flags_polarity[polarity],
>       mps_inti_flags_trigger[trigger],
> @@ -160,7 +160,7 @@ void __init acpi_table_print_madt_entry(
> struct acpi_madt_io_sapic *p =
>    (struct acpi_madt_io_sapic *)header;
> printk(KERN_INFO PREFIX
> -          "IOSAPIC (id[0x%x] address[%p] gsi_base[%d])\n",
> +          "IOSAPIC (id[%#x] address[%p] gsi_base[%d])\n",
>       p->id, (void *)(unsigned long)p->address,
>       p->global_irq_base);
> }
> @@ -182,7 +182,7 @@ void __init acpi_table_print_madt_entry(
> struct acpi_madt_interrupt_source *p =
>    (struct acpi_madt_interrupt_source *)header;
> printk(KERN_INFO PREFIX
> -          "PLAT_INT_SRC (%s %s type[0x%x] id[0x%04x] eid[0x%x] 
> iosapic_vector[0x%x] global_irq[0x%x]\n",
> +          "PLAT_INT_SRC (%s %s type[%#x] id[0x%04x] eid[%#x] 
> iosapic_vector[%#x] global_irq[%#x]\n",
>       mps_inti_flags_polarity[p->inti_flags & ACPI_MADT_POLARITY_MASK],
>       mps_inti_flags_trigger[(p->inti_flags & ACPI_MADT_TRIGGER_MASK) >> 2],
>       p->type, p->id, p->eid, p->io_sapic_vector,
> @@ -192,7 +192,7 @@ void __init acpi_table_print_madt_entry(
>  
> default:
> printk(KERN_WARNING PREFIX
> -         "Found unsupported MADT entry (type = 0x%x)\n",
> +         "Found unsupported MADT entry (type = %#x)\n",
>       header->type);
> break;
> }
> @@ -242,7 +242,7 @@ acpi_table_parse_entries(char *id,
>    ((unsigned long)entry + entry->length);
> }
> if (max_entries && count > max_entries) {
> -  printk(KERN_WARNING PREFIX "[%4.4s:0x%02x] ignored %i entries of "
> +  printk(KERN_WARNING PREFIX "[%4.4s:%#x] ignored %i entries of "
>       "%i found\n", id, entry_id, count - max_entries, count);
> }
>  
> --- 2012-09-21.orig/xen/drivers/acpi/utilities/utglobal.c 2011-03-11 
> 10:13:55.000000000 +0100
> +++ 2012-09-21/xen/drivers/acpi/utilities/utglobal.c 2012-09-21 
> 10:54:46.000000000 +0200
> @@ -79,7 +79,7 @@ const char *__init acpi_format_exception
> /* Exception code was not recognized */
>  
> ACPI_ERROR((AE_INFO,
> -       "Unknown exception code: 0x%8.8X", status));
> +       "Unknown exception code: %#X", status));
>  
> exception = "UNKNOWN_STATUS_CODE";
> dump_execution_state();
> --- 2012-09-21.orig/xen/drivers/cpufreq/cpufreq.c 2012-09-14 
> 13:26:34.000000000 +0200
> +++ 2012-09-21/xen/drivers/cpufreq/cpufreq.c 2012-09-21 10:54:46.000000000 
> +0200
> @@ -377,7 +377,7 @@ static void print_PSS(struct xen_process
>      printk("\t_PSS: state_count=%d\n", count);
>      for (i=0; i<count; i++){
>          printk("\tState%d: %"PRId64"MHz %"PRId64"mW %"PRId64"us "
> -               "%"PRId64"us 0x%"PRIx64" 0x%"PRIx64"\n",
> +               "%"PRId64"us %#"PRIx64" %#"PRIx64"\n",
>                 i,
>                 ptr[i].core_frequency,
>                 ptr[i].power,
> --- 2012-09-21.orig/xen/drivers/passthrough/amd/iommu_acpi.c 2011-12-14 
> 10:11:38.000000000 +0100
> +++ 2012-09-21/xen/drivers/passthrough/amd/iommu_acpi.c 2012-09-21 
> 10:54:46.000000000 +0200
> @@ -196,7 +196,7 @@ static int __init register_exclusion_ran
>      iommu = find_iommu_for_device(seg, bdf);
>      if ( !iommu )
>      {
> -        AMD_IOMMU_DEBUG("IVMD Error: No IOMMU for Dev_Id 0x%x!\n", bdf);
> +        AMD_IOMMU_DEBUG("IVMD Error: No IOMMU for Dev_Id %#x!\n", bdf);
>          return -ENODEV;
>      }
>      req = ivrs_mappings[bdf].dte_requestor_id;
> @@ -278,7 +278,7 @@ static int __init parse_ivmd_device_sele
>      bdf = ivmd_block->header.device_id;
>      if ( bdf >= ivrs_bdf_entries )
>      {
> -        AMD_IOMMU_DEBUG("IVMD Error: Invalid Dev_Id 0x%x\n", bdf);
> +        AMD_IOMMU_DEBUG("IVMD Error: Invalid Dev_Id %#x\n", bdf);
>          return -ENODEV;
>      }
>  
> @@ -296,7 +296,7 @@ static int __init parse_ivmd_device_rang
>      if ( first_bdf >= ivrs_bdf_entries )
>      {
>          AMD_IOMMU_DEBUG("IVMD Error: "
> -                        "Invalid Range_First Dev_Id 0x%x\n", first_bdf);
> +                        "Invalid Range_First Dev_Id %#x\n", first_bdf);
>          return -ENODEV;
>      }
>  
> @@ -304,7 +304,7 @@ static int __init parse_ivmd_device_rang
>      if ( (last_bdf >= ivrs_bdf_entries) || (last_bdf <= first_bdf) )
>      {
>          AMD_IOMMU_DEBUG("IVMD Error: "
> -                        "Invalid Range_Last Dev_Id 0x%x\n", last_bdf);
> +                        "Invalid Range_Last Dev_Id %#x\n", last_bdf);
>          return -ENODEV;
>      }
>  
> @@ -326,7 +326,7 @@ static int __init parse_ivmd_device_iomm
>                                      ivmd_block->aux_data);
>      if ( !iommu )
>      {
> -        AMD_IOMMU_DEBUG("IVMD Error: No IOMMU for Dev_Id 0x%x  Cap 0x%x\n",
> +        AMD_IOMMU_DEBUG("IVMD Error: No IOMMU for Dev_Id %#x Cap %#x\n",
>                          ivmd_block->header.device_id, ivmd_block->aux_data);
>          return -ENODEV;
>      }
> @@ -351,9 +351,9 @@ static int __init parse_ivmd_block(const
>      base = start_addr & PAGE_MASK;
>      limit = (start_addr + mem_length - 1) & PAGE_MASK;
>  
> -    AMD_IOMMU_DEBUG("IVMD Block: Type 0x%x\n",ivmd_block->header.type);
> -    AMD_IOMMU_DEBUG(" Start_Addr_Phys 0x%lx\n", start_addr);
> -    AMD_IOMMU_DEBUG(" Mem_Length 0x%lx\n", mem_length);
> +    AMD_IOMMU_DEBUG("IVMD Block: Type %#x\n",ivmd_block->header.type);
> +    AMD_IOMMU_DEBUG(" Start_Addr_Phys %#lx\n", start_addr);
> +    AMD_IOMMU_DEBUG(" Mem_Length %#lx\n", mem_length);
>  
>      if ( ivmd_block->header.flags & ACPI_IVMD_EXCLUSION_RANGE )
>          iw = ir = IOMMU_CONTROL_ENABLED;
> @@ -414,7 +414,7 @@ static u16 __init parse_ivhd_device_sele
>      bdf = select->header.id;
>      if ( bdf >= ivrs_bdf_entries )
>      {
> -        AMD_IOMMU_DEBUG("IVHD Error: Invalid Device_Entry Dev_Id 0x%x\n", 
> bdf);
> +        AMD_IOMMU_DEBUG("IVHD Error: Invalid Device_Entry Dev_Id %#x\n", 
> bdf);
>          return 0;
>      }
>  
> @@ -439,7 +439,7 @@ static u16 __init parse_ivhd_device_rang
>      if ( range->end.header.type != ACPI_IVRS_TYPE_END )
>      {
>          AMD_IOMMU_DEBUG("IVHD Error: "
> -                        "Invalid Range: End_Type 0x%x\n",
> +                        "Invalid Range: End_Type %#x\n",
>                          range->end.header.type);
>          return 0;
>      }
> @@ -448,7 +448,7 @@ static u16 __init parse_ivhd_device_rang
>      if ( first_bdf >= ivrs_bdf_entries )
>      {
>          AMD_IOMMU_DEBUG("IVHD Error: "
> -                        "Invalid Range: First Dev_Id 0x%x\n", first_bdf);
> +                        "Invalid Range: First Dev_Id %#x\n", first_bdf);
>          return 0;
>      }
>  
> @@ -456,11 +456,11 @@ static u16 __init parse_ivhd_device_rang
>      if ( (last_bdf >= ivrs_bdf_entries) || (last_bdf <= first_bdf) )
>      {
>          AMD_IOMMU_DEBUG("IVHD Error: "
> -                        "Invalid Range: Last Dev_Id 0x%x\n", last_bdf);
> +                        "Invalid Range: Last Dev_Id %#x\n", last_bdf);
>          return 0;
>      }
>  
> -    AMD_IOMMU_DEBUG(" Dev_Id Range: 0x%x -> 0x%x\n", first_bdf, last_bdf);
> +    AMD_IOMMU_DEBUG(" Dev_Id Range: %#x -> %#x\n", first_bdf, last_bdf);
>  
>      for ( bdf = first_bdf; bdf <= last_bdf; bdf++ )
>          add_ivrs_mapping_entry(bdf, bdf, range->start.header.data_setting,
> @@ -485,18 +485,18 @@ static u16 __init parse_ivhd_device_alia
>      bdf = alias->header.id;
>      if ( bdf >= ivrs_bdf_entries )
>      {
> -        AMD_IOMMU_DEBUG("IVHD Error: Invalid Device_Entry Dev_Id 0x%x\n", 
> bdf);
> +        AMD_IOMMU_DEBUG("IVHD Error: Invalid Device_Entry Dev_Id %#x\n", 
> bdf);
>          return 0;
>      }
>  
>      alias_id = alias->used_id;
>      if ( alias_id >= ivrs_bdf_entries )
>      {
> -        AMD_IOMMU_DEBUG("IVHD Error: Invalid Alias Dev_Id 0x%x\n", alias_id);
> +        AMD_IOMMU_DEBUG("IVHD Error: Invalid Alias Dev_Id %#x\n", alias_id);
>          return 0;
>      }
>  
> -    AMD_IOMMU_DEBUG(" Dev_Id Alias: 0x%x\n", alias_id);
> +    AMD_IOMMU_DEBUG(" Dev_Id Alias: %#x\n", alias_id);
>  
>      add_ivrs_mapping_entry(bdf, alias_id, alias->header.data_setting, iommu);
>  
> @@ -520,7 +520,7 @@ static u16 __init parse_ivhd_device_alia
>      if ( range->end.header.type != ACPI_IVRS_TYPE_END )
>      {
>          AMD_IOMMU_DEBUG("IVHD Error: "
> -                        "Invalid Range: End_Type 0x%x\n",
> +                        "Invalid Range: End_Type %#x\n",
>                          range->end.header.type);
>          return 0;
>      }
> @@ -529,7 +529,7 @@ static u16 __init parse_ivhd_device_alia
>      if ( first_bdf >= ivrs_bdf_entries )
>      {
>          AMD_IOMMU_DEBUG("IVHD Error: "
> -                        "Invalid Range: First Dev_Id 0x%x\n", first_bdf);
> +                        "Invalid Range: First Dev_Id %#x\n", first_bdf);
>          return 0;
>      }
>  
> @@ -537,19 +537,19 @@ static u16 __init parse_ivhd_device_alia
>      if ( last_bdf >= ivrs_bdf_entries || last_bdf <= first_bdf )
>      {
>          AMD_IOMMU_DEBUG(
> -            "IVHD Error: Invalid Range: Last Dev_Id 0x%x\n", last_bdf);
> +            "IVHD Error: Invalid Range: Last Dev_Id %#x\n", last_bdf);
>          return 0;
>      }
>  
>      alias_id = range->alias.used_id;
>      if ( alias_id >= ivrs_bdf_entries )
>      {
> -        AMD_IOMMU_DEBUG("IVHD Error: Invalid Alias Dev_Id 0x%x\n", alias_id);
> +        AMD_IOMMU_DEBUG("IVHD Error: Invalid Alias Dev_Id %#x\n", alias_id);
>          return 0;
>      }
>  
> -    AMD_IOMMU_DEBUG(" Dev_Id Range: 0x%x -> 0x%x\n", first_bdf, last_bdf);
> -    AMD_IOMMU_DEBUG(" Dev_Id Alias: 0x%x\n", alias_id);
> +    AMD_IOMMU_DEBUG(" Dev_Id Range: %#x -> %#x\n", first_bdf, last_bdf);
> +    AMD_IOMMU_DEBUG(" Dev_Id Alias: %#x\n", alias_id);
>  
>      for ( bdf = first_bdf; bdf <= last_bdf; bdf++ )
>          add_ivrs_mapping_entry(bdf, alias_id, 
> range->alias.header.data_setting,
> @@ -574,7 +574,7 @@ static u16 __init parse_ivhd_device_exte
>      bdf = ext->header.id;
>      if ( bdf >= ivrs_bdf_entries )
>      {
> -        AMD_IOMMU_DEBUG("IVHD Error: Invalid Device_Entry Dev_Id 0x%x\n", 
> bdf);
> +        AMD_IOMMU_DEBUG("IVHD Error: Invalid Device_Entry Dev_Id %#x\n", 
> bdf);
>          return 0;
>      }
>  
> @@ -599,7 +599,7 @@ static u16 __init parse_ivhd_device_exte
>      if ( range->end.header.type != ACPI_IVRS_TYPE_END )
>      {
>          AMD_IOMMU_DEBUG("IVHD Error: "
> -                        "Invalid Range: End_Type 0x%x\n",
> +                        "Invalid Range: End_Type %#x\n",
>                          range->end.header.type);
>          return 0;
>      }
> @@ -608,7 +608,7 @@ static u16 __init parse_ivhd_device_exte
>      if ( first_bdf >= ivrs_bdf_entries )
>      {
>          AMD_IOMMU_DEBUG("IVHD Error: "
> -                        "Invalid Range: First Dev_Id 0x%x\n", first_bdf);
> +                        "Invalid Range: First Dev_Id %#x\n", first_bdf);
>          return 0;
>      }
>  
> @@ -616,11 +616,11 @@ static u16 __init parse_ivhd_device_exte
>      if ( (last_bdf >= ivrs_bdf_entries) || (last_bdf <= first_bdf) )
>      {
>          AMD_IOMMU_DEBUG("IVHD Error: "
> -                        "Invalid Range: Last Dev_Id 0x%x\n", last_bdf);
> +                        "Invalid Range: Last Dev_Id %#x\n", last_bdf);
>          return 0;
>      }
>  
> -    AMD_IOMMU_DEBUG(" Dev_Id Range: 0x%x -> 0x%x\n",
> +    AMD_IOMMU_DEBUG(" Dev_Id Range: %#x -> %#x\n",
>                      first_bdf, last_bdf);
>  
>      for ( bdf = first_bdf; bdf <= last_bdf; bdf++ )
> @@ -646,7 +646,7 @@ static u16 __init parse_ivhd_device_spec
>      bdf = special->used_id;
>      if ( bdf >= ivrs_bdf_entries )
>      {
> -        AMD_IOMMU_DEBUG("IVHD Error: Invalid Device_Entry Dev_Id 0x%x\n", 
> bdf);
> +        AMD_IOMMU_DEBUG("IVHD Error: Invalid Device_Entry Dev_Id %#x\n", 
> bdf);
>          return 0;
>      }
>  
> @@ -673,7 +673,7 @@ static int __init parse_ivhd_block(const
>                                      ivhd_block->capability_offset);
>      if ( !iommu )
>      {
> -        AMD_IOMMU_DEBUG("IVHD Error: No IOMMU for Dev_Id 0x%x  Cap 0x%x\n",
> +        AMD_IOMMU_DEBUG("IVHD Error: No IOMMU for Dev_Id %#x Cap %#x\n",
>                          ivhd_block->header.device_id,
>                          ivhd_block->capability_offset);
>          return -ENODEV;
> @@ -687,9 +687,9 @@ static int __init parse_ivhd_block(const
>          ivhd_device = (const void *)((const u8 *)ivhd_block + block_length);
>  
>          AMD_IOMMU_DEBUG( "IVHD Device Entry:\n");
> -        AMD_IOMMU_DEBUG( " Type 0x%x\n", ivhd_device->header.type);
> -        AMD_IOMMU_DEBUG( " Dev_Id 0x%x\n", ivhd_device->header.id);
> -        AMD_IOMMU_DEBUG( " Flags 0x%x\n", ivhd_device->header.data_setting);
> +        AMD_IOMMU_DEBUG( " Type %#x\n", ivhd_device->header.type);
> +        AMD_IOMMU_DEBUG( " Dev_Id %#x\n", ivhd_device->header.id);
> +        AMD_IOMMU_DEBUG( " Flags %#x\n", ivhd_device->header.data_setting);
>  
>          switch ( ivhd_device->header.type )
>          {
> @@ -788,9 +788,9 @@ static void __init dump_acpi_table_heade
>          printk("%c", table->signature[i]);
>      printk("\n");
>  
> -    AMD_IOMMU_DEBUG(" Length 0x%x\n", table->length);
> -    AMD_IOMMU_DEBUG(" Revision 0x%x\n", table->revision);
> -    AMD_IOMMU_DEBUG(" CheckSum 0x%x\n", table->checksum);
> +    AMD_IOMMU_DEBUG(" Length %#x\n", table->length);
> +    AMD_IOMMU_DEBUG(" Revision %#x\n", table->revision);
> +    AMD_IOMMU_DEBUG(" CheckSum %#x\n", table->checksum);
>  
>      AMD_IOMMU_DEBUG(" OEM_Id ");
>      for ( i = 0; i < ACPI_OEM_ID_SIZE; i++ )
> @@ -802,14 +802,14 @@ static void __init dump_acpi_table_heade
>          printk("%c", table->oem_table_id[i]);
>      printk("\n");
>  
> -    AMD_IOMMU_DEBUG(" OEM_Revision 0x%x\n", table->oem_revision);
> +    AMD_IOMMU_DEBUG(" OEM_Revision %#x\n", table->oem_revision);
>  
>      AMD_IOMMU_DEBUG(" Creator_Id ");
>      for ( i = 0; i < ACPI_NAME_SIZE; i++ )
>          printk("%c", table->asl_compiler_id[i]);
>      printk("\n");
>  
> -    AMD_IOMMU_DEBUG(" Creator_Revision 0x%x\n",
> +    AMD_IOMMU_DEBUG(" Creator_Revision %#x\n",
>                      table->asl_compiler_revision);
>  
>  }
> @@ -832,15 +832,15 @@ static int __init parse_ivrs_table(struc
>          ivrs_block = (struct acpi_ivrs_header *)((u8 *)table + length);
>  
>          AMD_IOMMU_DEBUG("IVRS Block:\n");
> -        AMD_IOMMU_DEBUG(" Type 0x%x\n", ivrs_block->type);
> -        AMD_IOMMU_DEBUG(" Flags 0x%x\n", ivrs_block->flags);
> -        AMD_IOMMU_DEBUG(" Length 0x%x\n", ivrs_block->length);
> -        AMD_IOMMU_DEBUG(" Dev_Id 0x%x\n", ivrs_block->device_id);
> +        AMD_IOMMU_DEBUG(" Type %#x\n", ivrs_block->type);
> +        AMD_IOMMU_DEBUG(" Flags %#x\n", ivrs_block->flags);
> +        AMD_IOMMU_DEBUG(" Length %#x\n", ivrs_block->length);
> +        AMD_IOMMU_DEBUG(" Dev_Id %#x\n", ivrs_block->device_id);
>  
>          if ( table->length < (length + ivrs_block->length) )
>          {
>              AMD_IOMMU_DEBUG("IVRS Error: "
> -                            "Table Length Exceeded: 0x%x -> 0x%lx\n",
> +                            "Table Length Exceeded: %#x -> %#lx\n",
>                              table->length,
>                              (length + ivrs_block->length));
>              return -ENODEV;
> @@ -867,7 +867,7 @@ static int __init detect_iommu_acpi(stru
>          checksum += raw_table[i];
>      if ( checksum )
>      {
> -        AMD_IOMMU_DEBUG("IVRS Error: Invalid Checksum 0x%x\n", checksum);
> +        AMD_IOMMU_DEBUG("IVRS Error: Invalid Checksum %#x\n", checksum);
>          return -ENODEV;
>      }
>  
> --- 2012-09-21.orig/xen/drivers/passthrough/amd/iommu_init.c 2012-09-17 
> 09:57:54.000000000 +0200
> +++ 2012-09-21/xen/drivers/passthrough/amd/iommu_init.c 2012-09-21 
> 10:54:46.000000000 +0200
> @@ -616,8 +616,8 @@ static void parse_event_log_entry(struct
>                                         IOMMU_EVENT_FLAGS_SHIFT);
>          addr= (u64*) (entry + 2);
>          printk(XENLOG_ERR "AMD-Vi: "
> -               "%s: domain = %d, device id = 0x%04x, "
> -               "fault address = 0x%"PRIx64", flags = 0x%03x\n",
> +               "%s: domain = %d, device id = %#x, "
> +               "fault address = %#"PRIx64", flags = %#x\n",
>                 event_str[code-1], domain_id, device_id, *addr, flags);
>  
>          /* Tell the device to stop DMAing; we can't rely on the guest to
> --- 2012-09-21.orig/xen/drivers/passthrough/amd/iommu_map.c 2012-09-14 
> 13:26:34.000000000 +0200
> +++ 2012-09-21/xen/drivers/passthrough/amd/iommu_map.c 2012-09-21 
> 10:54:46.000000000 +0200
> @@ -795,7 +795,7 @@ void amd_iommu_share_p2m(struct domain *
>  
>          /* When sharing p2m with iommu, paging mode = 4 */
>          hd->paging_mode = IOMMU_PAGING_MODE_LEVEL_4;
> -        AMD_IOMMU_DEBUG("Share p2m table with iommu: p2m table = 0x%lx\n",
> +        AMD_IOMMU_DEBUG("Share p2m table with iommu: p2m table = %#lx\n",
>                          mfn_x(pgd_mfn));
>      }
>  }
> --- 2012-09-21.orig/xen/drivers/passthrough/amd/pci_amd_iommu.c 2012-09-14 
> 13:26:34.000000000 +0200
> +++ 2012-09-21/xen/drivers/passthrough/amd/pci_amd_iommu.c 2012-09-21 
> 10:54:46.000000000 +0200
> @@ -121,8 +121,8 @@ static void amd_iommu_setup_domain_devic
>  
>          amd_iommu_flush_device(iommu, req_id);
>  
> -        AMD_IOMMU_DEBUG("Setup I/O page table: device id = 0x%04x, "
> -                        "root table = 0x%"PRIx64", "
> +        AMD_IOMMU_DEBUG("Setup I/O page table: device id = %#x, "
> +                        "root table = %#"PRIx64", "
>                          "domain = %d, paging mode = %d\n", req_id,
>                          page_to_maddr(hd->root_table),
>                          hd->domain_id, hd->paging_mode);
> @@ -314,7 +314,7 @@ void amd_iommu_disable_domain_device(str
>  
>          amd_iommu_flush_device(iommu, req_id);
>  
> -        AMD_IOMMU_DEBUG("Disable: device id = 0x%04x, "
> +        AMD_IOMMU_DEBUG("Disable: device id = %#x, "
>                          "domain = %d, paging mode = %d\n",
>                          req_id,  domain_hvm_iommu(domain)->domain_id,
>                          domain_hvm_iommu(domain)->paging_mode);
> --- 2012-09-21.orig/xen/drivers/passthrough/vtd/dmar.c 2012-09-14 
> 13:26:34.000000000 +0200
> +++ 2012-09-21/xen/drivers/passthrough/vtd/dmar.c 2012-09-21 
> 10:54:46.000000000 +0200
> @@ -381,7 +381,7 @@ static int __init acpi_dmar_check_length
>      if ( h->length >= min_len )
>          return 0;
>      dprintk(XENLOG_ERR VTDPREFIX,
> -            "Invalid ACPI DMAR entry length: 0x%x\n",
> +            "Invalid ACPI DMAR entry length: %#x\n",
>              h->length);
>      return -EINVAL;
>  }
> @@ -749,7 +749,7 @@ static int __init acpi_parse_dmar(struct
>              break;
>          default:
>              dprintk(XENLOG_WARNING VTDPREFIX,
> -                    "Ignore unknown DMAR structure type (0x%x)\n",
> +                    "Ignore unknown DMAR structure type (%#x)\n",
>                      entry_header->type);
>              break;
>          }
> --- 2012-09-21.orig/xen/drivers/passthrough/vtd/intremap.c 2012-09-14 
> 13:26:34.000000000 +0200
> +++ 2012-09-21/xen/drivers/passthrough/vtd/intremap.c 2012-09-21 
> 10:54:46.000000000 +0200
> @@ -135,7 +135,7 @@ int iommu_supports_eim(void)
>          if ( !ioapic_to_drhd(IO_APIC_ID(apic)) )
>      {
>              dprintk(XENLOG_WARNING VTDPREFIX,
> -                    "There is not a DRHD for IOAPIC 0x%x (id: 0x%x)!\n",
> +                    "There is not a DRHD for IOAPIC %#x (id: %#x)!\n",
>                      apic, IO_APIC_ID(apic));
>              return 0;
>      }
> --- 2012-09-21.orig/xen/drivers/passthrough/vtd/iommu.c 2012-09-17 
> 09:57:55.000000000 +0200
> +++ 2012-09-21/xen/drivers/passthrough/vtd/iommu.c 2012-09-21 
> 10:54:46.000000000 +0200
> @@ -2035,7 +2035,7 @@ static int init_vtd_hw(void)
>              {
>                  iommu_intremap = 0;
>                  dprintk(XENLOG_ERR VTDPREFIX,
> -                    "ioapic_to_iommu: ioapic 0x%x (id: 0x%x) is NULL! "
> +                    "ioapic_to_iommu: ioapic %#x (id: %#x) is NULL! "
>                      "Will not try to enable Interrupt Remapping.\n",
>                      apic, IO_APIC_ID(apic));
>                  break;
> --- 2012-09-21.orig/xen/drivers/passthrough/vtd/utils.c 2012-09-14 
> 13:26:34.000000000 +0200
> +++ 2012-09-21/xen/drivers/passthrough/vtd/utils.c 2012-09-21 
> 10:54:46.000000000 +0200
> @@ -217,7 +217,7 @@ static void dump_iommu_info(unsigned cha
>              struct iremap_entry *iremap_entries = NULL;
>              int print_cnt = 0;
>  
> -            printk("  Interrupt remapping table (nr_entry=0x%x. "
> +            printk("  Interrupt remapping table (nr_entry=%#x. "
>                  "Only dump P=1 entries here):\n", nr_entry);
>              printk("       SVT  SQ   SID      DST  V  AVL DLM TM RH DM "
>                     "FPD P\n");
> --- 2012-09-21.orig/xen/drivers/video/vesa.c 2012-09-14 13:26:34.000000000 
> +0200
> +++ 2012-09-21/xen/drivers/video/vesa.c 2012-09-21 10:54:46.000000000 +0200
> @@ -111,7 +111,7 @@ void __init vesa_init(void)
>  
>      vga_puts = vesa_redraw_puts;
>  
> -    printk(XENLOG_INFO "vesafb: framebuffer at 0x%x, mapped to 0x%p, "
> +    printk(XENLOG_INFO "vesafb: framebuffer at %#x, mapped to 0x%p, "
>             "using %uk, total %uk\n",
>             vlfb_info.lfb_base, lfb,
>             vram_remap >> 10, vram_total >> 10);
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Sep 21 11:36:54 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Sep 2012 11:36: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 1TF1XH-0002j5-Mm; Fri, 21 Sep 2012 11:36: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 1TF1XG-0002iw-8w
	for xen-devel@lists.xen.org; Fri, 21 Sep 2012 11:36:42 +0000
Received: from [85.158.139.83:14207] by server-1.bemta-5.messagelabs.com id
	41/00-04809-9415C505; Fri, 21 Sep 2012 11:36:41 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1348227397!27259691!1
X-Originating-IP: [74.125.83.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3898 invoked from network); 21 Sep 2012 11:36:37 -0000
Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com)
	(74.125.83.45)
	by server-14.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Sep 2012 11:36:37 -0000
Received: by eeke53 with SMTP id e53so1519550eek.32
	for <xen-devel@lists.xen.org>; Fri, 21 Sep 2012 04:36:37 -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=pJsphc8VUArMGZt4gPBeiWOXYO6z2nhAjQESxK0oPFs=;
	b=CJcORN/xDm6g2KO/BvJEJL8dvZbIEgAE3FOmDEgSd67v8L6qDnOENVJBacRqIArYxF
	uo8sFOOqdZFkyo4jIO3enWzNMCryW61FW6Jy64I0M71OfQ94+5cD8l7uDezA9kJviCiq
	DDJ8/aKWLd5R/BRPCcRNDSSQGQFPZJklKqtQxusHo7qXjfUqGBHanTn5cBUZpbjyDgBJ
	kks+0WR7LH7K3zjLOZZglReufeYdYM9y3f+WA4rHwBeAiglegUuqq6WKJRbvhICHiCWq
	ymqln7ZIyLNJy2GiqIbCiSF4tjxYXqs0uP6ydCJxdrmFutJgMwmDKnjuN/PbhB4KPmU0
	NZMA==
Received: by 10.14.204.72 with SMTP id g48mr5842812eeo.45.1348227397576;
	Fri, 21 Sep 2012 04:36:37 -0700 (PDT)
Received: from [192.168.1.3] (host86-167-82-156.range86-167.btcentralplus.com.
	[86.167.82.156])
	by mx.google.com with ESMTPS id i41sm23236741eem.7.2012.09.21.04.36.32
	(version=SSLv3 cipher=OTHER); Fri, 21 Sep 2012 04:36:36 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.33.0.120411
Date: Fri, 21 Sep 2012 12:36:27 +0100
From: Keir Fraser <keir@xen.org>
To: Jan Beulich <JBeulich@suse.com>,
	xen-devel <xen-devel@lists.xen.org>
Message-ID: <CC820FCB.4C962%keir@xen.org>
Thread-Topic: [Xen-devel] [PATCH] printk: prefer %#x et at over 0x%x
Thread-Index: Ac2X7VYH+qFzog5NZEaTGkLWkKvH2A==
In-Reply-To: <505C6B7C020000780009CF08@nat28.tlf.novell.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] [PATCH] printk: prefer %#x et at over 0x%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 21/09/2012 12:28, "Jan Beulich" <JBeulich@suse.com> wrote:

> Performance is not an issue with printk(), so let the function do
> minimally more work and instead save a byte per affected format
> specifier.

I didn't know about the '#' prefix when I first started sprinkling '0x' all
around.

> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Acked-by: Keir Fraser <keir@xen.org>

> --- 2012-09-21.orig/xen/arch/x86/acpi/boot.c 2012-09-20 08:44:38.000000000
> +0200
> +++ 012-09-21/xen/arch/x86/acpi/boot.c 2012-09-21 10:54:46.000000000 +0200
> @@ -341,14 +341,14 @@ cpi_fadt_parse_sleep_info(struct acpi_t
> }
>  
> if (facs->length < 24) {
> -  printk(KERN_ERR PREFIX "Invalid FACS table length: 0x%x",
> +  printk(KERN_ERR PREFIX "Invalid FACS table length: %#x",
> facs->length);
> goto bad;
> }
>  
> if (facs->length < 64)
> printk(KERN_WARNING PREFIX
> -   "FACS is shorter than ACPI spec allow: 0x%x",
> +   "FACS is shorter than ACPI spec allow: %#x",
> facs->length);
>  
> acpi_sinfo.wakeup_vector = facs_pa +
> --- 2012-09-21.orig/xen/arch/x86/acpi/cpu_idlec 2012-08-15 08:32:43.000000000
> +0200
> +++ 2012-09-21/xen/arch/x86/acpi/cpu_idle.c 2012-09-21 1054:46.000000000
> +0200
> @@ -978,11 +978,11 @@ static void print_cx_pminfo(uint32_t cpu
>              return;
>          
>          printk("\tstates[%d]:\n", i);
> -        printk("\t\treg.space_id = 0x%x\n", state.reg.space_id);
> -        printk("\t\treg.bit_width = 0x%x\n", state.reg.bit_width);
> -        printk("\t\treg.bit_offset = 0x%x\n", state.reg.bit_offset);
> -        printk("\t\treg.access_size = 0x%x\n", state.reg.access_size);
> -        printk("\t\treg.address = 0x%"PRIx64"\n", state.reg.address);
> +        printk("\t\treg.space_id = %#x\n", state.reg.space_id);
> +        printk("\t\treg.bit_width = %#x\n", state.reg.bit_width);
> +        printk("\t\treg.bit_offset = %#x\n", state.reg.bit_offset);
> +        printk("\t\treg.access_size = %#x\n", state.reg.access_size);
> +        printk("\t\treg.address = %#"PRIx64"\n", state.reg.address);
>          printk("\t\ttype    = %d\n", state.type);
>          printk("\t\tlatency = %d\n", state.latency);
>          printk("\t\tpower   = %d\n", state.power);
> --- 2012-09-21.orig/xen/arch/x86/apic.c 2012-09-17 09:5:54.000000000 +0200
> +++ 2012-09-21/xen/arch/x86/apic.c 2012-09-21 10:54:46.000000000 +020
> @@ -689,7 +689,7 @@ void __devinit setup_local_APIC(void)
>          value = apic_read(APIC_ESR);
>          if (value != oldvalue)
>              apic_printk(APIC_VERBOSE, "ESR value before enabling "
> -                        "vector: 0x%08lx  after: 0x%08lx\n",
> +                        "vector: %#lx  after: %#lx\n",
>                          oldvalue, value);
>      } else {
>          if (esr_disable)
> @@ -1210,7 +1210,7 @@ static int __init calibrate_APIC_clock(v
>      bus_cycle  = (u32) (1000000000000LL/bus_freq); /* in pico seconds */
>      bus_scale  = (1000*262144)/bus_cycle;
>  
> -    apic_printk(APIC_VERBOSE, "..... bus_scale = 0x%08X\n", bus_scale);
> +    apic_printk(APIC_VERBOSE, "..... bus_scale = %#x\n", bus_scale);
>      /* reset APIC to zero timeout valu */
>      __setup_APIC_LVTT(0);
>  
> --- 2012-09-21.orig/xen/arch/x86/cpu/mcheck/mce.c 2012-9-20
> 08:44:38.000000000 +0200
> +++ 2012-09-21/xen/arch/x86/cpu/mcheck/mce.c 2012-09-21 10:54:46.000000000
> +0200
> @@ -1147,7 +1147,7 @@ static int x86_mc_msrinject_verify(struc
>          }
>  
>          if (reason != NULL) {
> -            printk("HV MSR INJECT ERROR: MSR 0x%llx %s\n",
> +            printk("HV MSR INJECT ERROR: MSR %#Lx %s\n",
>                     (unsigned long long)mci->mcinj_msr[i].reg, reason);
>              errs++;
>          }
> @@ -1191,8 +1191,7 @@ satic void x86_mc_msrinject(void *data)
>  
>      for (i = 0, msr = &mci->mcinj_msr[0];
>          i < mci->mcinj_count; i++, msr++) {
> -        printk("HV MSR INJECT (%s) target %u actual %u MSR 0x%llx "
> -               "<-- 0x%llx\n",
> +        printk("HV MSR INJECT (%s) target %u actual %u MSR %#Lx <-- %#Lx\n",
>                 intpose ?  "interpose" : "hardware",
>                 mci->mcinj_cpunr, smp_processor_id(),
>                 (unsigned long long)msr->reg,
> --- 2012-09-21.orig/xen/arch/x86/cpu/mcheck/vmce.c 2012-08-08
> 08:20:09.000000000 +0200
> +++ 2012-09-21/xen/arch/x86/cpu/mcheck/vmce.c 2012-09-21 10:54:46.00000000
> +0200
> @@ -88,7 +88,7 @@ static int bank_mce_rdmsr(const struct v
>      case MS_IA32_MC0_CTL:
>          /* stick all 1's to MCi_CTL */
>          *val = ~0UL;
> -        mce_printk(MCE_VERBOSE, "MCE: rdmsr MC%u_CTL 0x%"PRIx64"\n",
> +        mce_printk(MCE_VERBOSE, "MCE: rdmsr MC%u_CTL %#"PRIx64"\n",
>                     bank, *val);
>          break;
>      case MSR_IA32_MC0_STATUS:
> @@ -102,7 +102,7 @@ static int bank_mce_rdmsr(const struct v
>                  *val = entry->mci_status;
>                  mce_printk(MCE_VERBOSE,
>                             "MCE: rd MC%u_STATUS in vMCE# context "
> -                           "value 0x%"PRI64"\n", bank, *val);
> +                           "value %#"PRIx64"\n", bank, *val);
>              }
>          }
>          break;
> @@ -116,7 +116,7 @@ static int bank_mce_rdmsr(const struct v
>                  *val = entry->mci_addr;
>                  mce_printk(MCE_VERBOSE,
>                             "MCE: rdmsr MC%u_ADDR in vMCE# context "
> -                           "0x%"PRIx64"\n", bank, *val);
> +                           "%#"PRIx64"\n", bank, *val);
>              }
>          }
>          break;
> @@ -130,7 +130,7 @@ static int bank_mce_rdmsr(const struct v
>                  *val = entry->mci_misc;
>                  mce_printk(MCE_VERBOSE,
>                             "MCE: rd MC%u_MISC in vMCE# context "
> -                           "0x%"PRIx64"\n", bank, *val);
> +                           "%#"PRIx64"\n", bank, *val);
>              }
>          }
>          break;
> @@ -171,18 +171,18 @@ int vmce_rdmsr(uint32_t msr, uint64_t *v
>          *val = vmce->mcg_status;
>          if (*val)
>              mce_printk(MCE_VERBOSE,
> -                       "MCE: rdmsr MCG_STATUS 0x%"PRIx64"\n", *val);
> +                       "MCE: rdmsr MCG_STATUS %#"PRIx64"\n", *val);
>          break;
>      case MSR_IA32_MCG_CAP:
>          *val = cur->arch.mcg_cap;
> -        mce_printk(MCE_VERBOSE, "MCE: rdmsr MCG_CAP 0x%"PRIx64"\n",
> +        mce_printk(MCE_VERBOSE, "MCE: rdmsr MCG_CAP %#"PRIx64"\n",
>                     *val);
>          break;
>      case MSR_IA32_MCG_CTL:
>          /* Stick all 1's when CTL support, and 0's when no CTL support */
>          if ( cur->arch.mcg_cap & MCG_CTL_P )
>              *val = ~0ULL;
> -        mce_printk(MCE_VERBOSE, "MCE: rdmsr MCG_CTL 0x%"PRIx64"\n", *val);
> +        mce_printk(MCE_VERBOSE, "MCE: rdmsr MCG_CTL %#"PRIx64"\n", *val);
>          break;
>      default:
>          ret = mce_bank_msr(cur, msr) ? bank_mce_rdmsr(cur, msr, val) : 0;
> --- 2012-09-21.orig/xen/arch/x86/cpu/mtrr/generic.c 2011-04-11
> 08:33:59.000000000 +0200
> +++ 2012-09-21/xen/arch/x86/cpu/mtrr/generic.c 2012-09-21 10:54:46.000000000
> +0200
> @@ -410,7 +410,7 @@ int generic_validate_add_page(unsigned l
>    boot_cpu_data.x86_model == 1 &&
>    boot_cpu_data.x86_mask <= 7) {
> if (base & ((1 << (22 - PAGE_SHIFT)) - 1)) {
> -   printk(KERN_WARNING "mtrr: base(0x%lx000) is not 4 MiB aligned\n", base);
> +   printk(KERN_WARNING "mtrr: base(%#lx000) is not 4 MiB aligned\n", base);
> return -EINVAL;
> }
> if (!(base + size < 0x70000 || base > 0x7003F) &&
> @@ -427,7 +427,7 @@ int generic_validate_add_page(unsigned l
> for (lbase = base; !(lbase & 1) && (last & 1);
>     lbase = lbase >> 1, last = last >> 1) ;
> if (lbase != last) {
> -  printk(KERN_WARNING "mtrr: base(0x%lx000) is not aligned on a
> size(0x%lx000) boundary\n",
> +  printk(KERN_WARNING "mtrr: base(%#lx000) is not aligned on a size(%#lx000)
> boundary\n",
>       base, size);
> return -EINVAL;
> }
> --- 2012-09-21.orig/xen/arch/x86/cpu/mtrr/main.c 2012-09-21 10:32:44.000000000
> +0200
> +++ 2012-09-21/xen/arch/x86/cpu/mtrr/main.c 2012-09-21 10:54:46.000000000
> +0200
> @@ -366,8 +366,8 @@ int mtrr_add_page(unsigned long base, un
> continue;
> }
> printk(KERN_WARNING
> -          "mtrr: 0x%lx000,0x%lx000 overlaps existing"
> -          " 0x%lx000,0x%lx000\n", base, size, lbase,
> +          "mtrr: %#lx000,%#lx000 overlaps existing"
> +          " %#lx000,%#lx000\n", base, size, lbase,
>       lsize);
> goto out;
> }
> @@ -412,7 +412,7 @@ static int mtrr_check(unsigned long base
> printk(KERN_WARNING
> "mtrr: size and base must be multiples of 4 kiB\n");
> printk(KERN_DEBUG
> -   "mtrr: size: 0x%lx  base: 0x%lx\n", size, base);
> +   "mtrr: size: %#lx  base: %#lx\n", size, base);
> dump_stack();
> return -1;
> }
> --- 2012-09-21.orig/xen/arch/x86/domain_build.c 2012-09-14 13:26:34.000000000
> +0200
> +++ 2012-09-21/xen/arch/x86/domain_build.c 2012-09-21 10:55:47.000000000 +0200
> @@ -396,13 +396,13 @@ int __init construct_dom0(
>      }
>      if (elf_64bit(&elf) && machine == EM_X86_64)
>          compatible = 1;
> -    printk(" Dom0 kernel: %s%s, %s, paddr 0x%" PRIx64 " -> 0x%" PRIx64 "\n",
> +    printk(" Dom0 kernel: %s%s, %s, paddr %#" PRIx64 " -> %#" PRIx64 "\n",
>             elf_64bit(&elf) ? "64-bit" : "32-bit",
>             parms.pae       ? ", PAE"  : "",
>             elf_msb(&elf)   ? "msb"    : "lsb",
>             elf.pstart, elf.pend);
>      if ( elf.bsd_symtab_pstart )
> -        printk(" Dom0 symbol map 0x%" PRIx64 " -> 0x%" PRIx64 "\n",
> +        printk(" Dom0 symbol map %#" PRIx64 " -> %#" PRIx64 "\n",
>                 elf.bsd_symtab_pstart, elf.bsd_symtab_pend);
>  
>      if ( !compatible )
> --- 2012-09-21.orig/xen/arch/x86/hvm/hvm.c 2012-09-20 08:44:38.000000000 +0200
> +++ 2012-09-21/xen/arch/x86/hvm/hvm.c 2012-09-21 10:54:46.000000000 +0200
> @@ -1468,7 +1468,7 @@ int hvm_set_efer(uint64_t value)
>      if ( !hvm_efer_valid(v->domain, value, efer_validbits) )
>      {
>          gdprintk(XENLOG_WARNING, "Trying to set reserved bit in "
> -                 "EFER: 0x%"PRIx64"\n", value);
> +                 "EFER: %#"PRIx64"\n", value);
>          hvm_inject_hw_exception(TRAP_gp_fault, 0);
>          return X86EMUL_EXCEPTION;
>      }
> @@ -4095,7 +4095,7 @@ long do_hvm_op(unsigned long op, XEN_GUE
>              {
>                  put_gfn(d, pfn);
>                  gdprintk(XENLOG_WARNING,
> -                         "type for pfn 0x%lx changed to grant while "
> +                         "type for pfn %#lx changed to grant while "
>                           "we were working?\n", pfn);
>                  goto param_fail4;
>              }
> @@ -4106,7 +4106,7 @@ long do_hvm_op(unsigned long op, XEN_GUE
>                  {
>                      put_gfn(d, pfn);
>                      gdprintk(XENLOG_WARNING,
> -                             "type of pfn 0x%lx changed from %d to %d while "
> +                             "type of pfn %#lx changed from %d to %d while "
>                               "we were trying to change it to %d\n",
>                               pfn, t, nt, memtype[a.hvmmem_type]);
>                      goto param_fail4;
> --- 2012-09-21.orig/xen/arch/x86/hvm/io.c 2012-07-30 09:49:58.000000000 +0200
> +++ 2012-09-21/xen/arch/x86/hvm/io.c 2012-09-21 10:54:46.000000000 +0200
> @@ -393,7 +393,7 @@ int dpci_ioport_intercept(ioreq_t *p)
>  
>      if ( !ioports_access_permitted(d, mport, mport + p->size - 1) )
>      {
> -        gdprintk(XENLOG_ERR, "Error: access to gport=0x%x denied!\n",
> +        gdprintk(XENLOG_ERR, "Error: access to gport=%#x denied!\n",
>                   (uint32_t)p->addr);
>          return X86EMUL_UNHANDLEABLE;
>      }
> --- 2012-09-21.orig/xen/arch/x86/hvm/irq.c 2012-09-14 13:26:34.000000000 +0200
> +++ 2012-09-21/xen/arch/x86/hvm/irq.c 2012-09-21 10:54:46.000000000 +0200
> @@ -488,7 +488,7 @@ static void irq_dump(struct domain *d)
>             hvm_irq->pci_link_assert_count[1],
>             hvm_irq->pci_link_assert_count[2],
>             hvm_irq->pci_link_assert_count[3]);
> -    printk("Callback via %i:0x%"PRIx32",%s asserted\n",
> +    printk("Callback via %i:%#"PRIx32",%s asserted\n",
>             hvm_irq->callback_via_type, hvm_irq->callback_via.gsi,
>             hvm_irq->callback_via_asserted ? "" : " not");
>  }
> --- 2012-09-21.orig/xen/arch/x86/hvm/svm/intr.c 2012-01-20 10:10:22.000000000
> +0100
> +++ 2012-09-21/xen/arch/x86/hvm/svm/intr.c 2012-09-21 10:54:46.000000000 +0200
> @@ -175,7 +175,7 @@ void svm_intr_assist(void)
>                  /* Guest already enabled an interrupt window. */
>                  return;
>              default:
> -                panic("%s: nestedsvm_vcpu_interrupt can't handle value
> 0x%x\n",
> +                panic("%s: nestedsvm_vcpu_interrupt can't handle value
> %#x\n",
>                      __func__, rc);
>              }
>          }
> --- 2012-09-21.orig/xen/arch/x86/hvm/svm/nestedsvm.c 2012-09-05
> 11:59:49.000000000 +0200
> +++ 2012-09-21/xen/arch/x86/hvm/svm/nestedsvm.c 2012-09-21 10:54:46.000000000
> +0200
> @@ -943,7 +943,7 @@ nsvm_vmcb_guest_intercepts_exitcode(stru
>          break;
>  
>      default:
> -        gdprintk(XENLOG_ERR, "Illegal exitcode 0x%"PRIx64"\n", exitcode);
> +        gdprintk(XENLOG_ERR, "Illegal exitcode %#"PRIx64"\n", exitcode);
>          BUG();
>          break;
>      }
> @@ -1235,7 +1235,7 @@ int nsvm_wrmsr(struct vcpu *v, unsigned
>      case MSR_K8_VM_HSAVE_PA:
>          if (!nestedsvm_vmcb_isvalid(v, msr_content)) {
>              gdprintk(XENLOG_ERR,
> -                "MSR_K8_VM_HSAVE_PA value invalid 0x%"PRIx64"\n",
> msr_content);
> +                "MSR_K8_VM_HSAVE_PA value invalid %#"PRIx64"\n",
> msr_content);
>              ret = -1; /* inject #GP */
>              break;
>          }
> @@ -1244,7 +1244,7 @@ int nsvm_wrmsr(struct vcpu *v, unsigned
>      case MSR_AMD64_TSC_RATIO:
>          if ((msr_content & ~TSC_RATIO_RSVD_BITS) != msr_content) {
>              gdprintk(XENLOG_ERR,
> -                "reserved bits set in MSR_AMD64_TSC_RATIO 0x%"PRIx64"\n",
> +                "reserved bits set in MSR_AMD64_TSC_RATIO %#"PRIx64"\n",
>                  msr_content);
>              ret = -1; /* inject #GP */
>              break;
> --- 2012-09-21.orig/xen/arch/x86/hvm/svm/svm.c 2012-09-17 09:57:54.000000000
> +0200
> +++ 2012-09-21/xen/arch/x86/hvm/svm/svm.c 2012-09-21 10:54:46.000000000 +0200
> @@ -241,7 +241,7 @@ static int svm_vmcb_restore(struct vcpu
>           ((c->pending_type == 1) || (c->pending_type > 6) ||
>            (c->pending_reserved != 0)) )
>      {
> -        gdprintk(XENLOG_ERR, "Invalid pending event 0x%"PRIx32".\n",
> +        gdprintk(XENLOG_ERR, "Invalid pending event %#"PRIx32".\n",
>                   c->pending_event);
>          return -EINVAL;
>      }
> @@ -254,7 +254,7 @@ static int svm_vmcb_restore(struct vcpu
>                                       NULL, P2M_ALLOC);
>              if ( !page )
>              {
> -                gdprintk(XENLOG_ERR, "Invalid CR3 value=0x%"PRIx64"\n",
> +                gdprintk(XENLOG_ERR, "Invalid CR3 value=%#"PRIx64"\n",
>                           c->cr3);
>                  return -EINVAL;
>              }
> @@ -289,7 +289,7 @@ static int svm_vmcb_restore(struct vcpu
>  
>      if ( c->pending_valid )
>      {
> -        gdprintk(XENLOG_INFO, "Re-injecting 0x%"PRIx32", 0x%"PRIx32"\n",
> +        gdprintk(XENLOG_INFO, "Re-injecting %#"PRIx32", %#"PRIx32"\n",
>                   c->pending_event, c->error_code);
>  
>          if ( hvm_event_needs_reinjection(c->pending_type, c->pending_vector)
> )
> @@ -2398,8 +2398,8 @@ void svm_vmexit_handler(struct cpu_user_
>  
>      default:
>      exit_and_crash:
> -        gdprintk(XENLOG_ERR, "unexpected VMEXIT: exit reason = 0x%"PRIx64", "
> -                 "exitinfo1 = %"PRIx64", exitinfo2 = %"PRIx64"\n",
> +        gdprintk(XENLOG_ERR, "unexpected VMEXIT: exit reason = %#"PRIx64", "
> +                 "exitinfo1 = %#"PRIx64", exitinfo2 = %#"PRIx64"\n",
>                   exit_reason,
>                   (u64)vmcb->exitinfo1, (u64)vmcb->exitinfo2);
>          domain_crash(v->domain);
> --- 2012-09-21.orig/xen/arch/x86/hvm/svm/svmdebug.c 2011-07-11
> 08:32:12.000000000 +0200
> +++ 2012-09-21/xen/arch/x86/hvm/svm/svmdebug.c 2012-09-21 10:54:46.000000000
> +0200
> @@ -32,33 +32,32 @@ static void svm_dump_sel(const char *nam
>  void svm_vmcb_dump(const char *from, struct vmcb_struct *vmcb)
>  {
>      printk("Dumping guest's current state at %s...\n", from);
> -    printk("Size of VMCB = %d, paddr = 0x%016lx, vaddr = %p\n",
> +    printk("Size of VMCB = %d, paddr = %#lx, vaddr = %p\n",
>             (int) sizeof(struct vmcb_struct), virt_to_maddr(vmcb), vmcb);
>  
> -    printk("cr_intercepts = 0x%08x dr_intercepts = 0x%08x "
> -           "exception_intercepts = 0x%08x\n",
> +    printk("cr_intercepts = %#x dr_intercepts = %#x "
> +           "exception_intercepts = %#x\n",
>             vmcb->_cr_intercepts, vmcb->_dr_intercepts,
>             vmcb->_exception_intercepts);
> -    printk("general1_intercepts = 0x%08x general2_intercepts = 0x%08x\n",
> +    printk("general1_intercepts = %#x general2_intercepts = %#x\n",
>             vmcb->_general1_intercepts, vmcb->_general2_intercepts);
> -    printk("iopm_base_pa = 0x%016llx msrpm_base_pa = 0x%016llx tsc_offset = "
> -            "0x%016llx\n",
> +    printk("iopm_base_pa = %#Lx msrpm_base_pa = %#Lx tsc_offset = %#Lx\n",
>             (unsigned long long)vmcb->_iopm_base_pa,
>             (unsigned long long)vmcb->_msrpm_base_pa,
>             (unsigned long long)vmcb->_tsc_offset);
> -    printk("tlb_control = 0x%08x vintr = 0x%016llx interrupt_shadow = "
> -            "0x%016llx\n", vmcb->tlb_control,
> +    printk("tlb_control = %#x vintr = %#Lx interrupt_shadow = %#Lx\n",
> +           vmcb->tlb_control,
>             (unsigned long long)vmcb->_vintr.bytes,
>             (unsigned long long)vmcb->interrupt_shadow);
> -    printk("exitcode = 0x%016llx exitintinfo = 0x%016llx\n",
> +    printk("exitcode = %#Lx exitintinfo = %#Lx\n",
>             (unsigned long long)vmcb->exitcode,
>             (unsigned long long)vmcb->exitintinfo.bytes);
> -    printk("exitinfo1 = 0x%016llx exitinfo2 = 0x%016llx \n",
> +    printk("exitinfo1 = %#Lx exitinfo2 = %#Lx \n",
>             (unsigned long long)vmcb->exitinfo1,
>             (unsigned long long)vmcb->exitinfo2);
> -    printk("np_enable = 0x%016llx guest_asid = 0x%03x\n",
> +    printk("np_enable = %Lx guest_asid = %#x\n",
>             (unsigned long long)vmcb->_np_enable, vmcb->_guest_asid);
> -    printk("cpl = %d efer = 0x%016llx star = 0x%016llx lstar = 0x%016llx\n",
> +    printk("cpl = %d efer = %#Lx star = %#Lx lstar = %#Lx\n",
>             vmcb->_cpl, (unsigned long long)vmcb->_efer,
>             (unsigned long long)vmcb->star, (unsigned long long)vmcb->lstar);
>      printk("CR0 = 0x%016llx CR2 = 0x%016llx\n",
> @@ -77,7 +76,7 @@ void svm_vmcb_dump(const char *from, str
>      printk("KernGSBase = 0x%016llx PAT = 0x%016llx \n",
>             (unsigned long long)vmcb->kerngsbase,
>             (unsigned long long)vmcb->_g_pat);
> -    printk("H_CR3 = 0x%016llx CleanBits = 0x%08x\n",
> +    printk("H_CR3 = 0x%016llx CleanBits = %#x\n",
>             (unsigned long long)vmcb->_h_cr3, vmcb->cleanbits.bytes);
>  
>      /* print out all the selectors */
> @@ -104,48 +103,48 @@ svm_vmcb_isvalid(const char *from, struc
>      } else return 1;
>  
>      if ((vmcb->_efer & EFER_SVME) == 0) {
> -        PRINTF("EFER: SVME bit not set (0x%"PRIx64")\n", vmcb->_efer);
> +        PRINTF("EFER: SVME bit not set (%#"PRIx64")\n", vmcb->_efer);
>      }
>  
>      if ((vmcb->_cr0 & X86_CR0_CD) == 0 && (vmcb->_cr0 & X86_CR0_NW) != 0) {
> -        PRINTF("CR0: CD bit is zero and NW bit set (0x%"PRIx64")\n",
> +        PRINTF("CR0: CD bit is zero and NW bit set (%#"PRIx64")\n",
>                  vmcb->_cr0);
>      }
>  
>      if ((vmcb->_cr0 >> 32U) != 0) {
> -        PRINTF("CR0: bits [63:32] are not zero (0x%"PRIx64")\n",
> +        PRINTF("CR0: bits [63:32] are not zero (%#"PRIx64")\n",
>                  vmcb->_cr0);
>      }
>  
>      if ((vmcb->_cr3 & 0x7) != 0) {
> -        PRINTF("CR3: MBZ bits are set (0x%"PRIx64")\n", vmcb->_cr3);
> +        PRINTF("CR3: MBZ bits are set (%#"PRIx64")\n", vmcb->_cr3);
>      }
>      if ((vmcb->_efer & EFER_LMA) && (vmcb->_cr3 & 0xfe) != 0) {
> -        PRINTF("CR3: MBZ bits are set (0x%"PRIx64")\n", vmcb->_cr3);
> +        PRINTF("CR3: MBZ bits are set (%#"PRIx64")\n", vmcb->_cr3);
>      }
>  
>      if ((vmcb->_cr4 >> 19U) != 0) {
> -        PRINTF("CR4: bits [63:19] are not zero (0x%"PRIx64")\n",
> +        PRINTF("CR4: bits [63:19] are not zero (%#"PRIx64")\n",
>                  vmcb->_cr4);
>      }
>  
>      if (((vmcb->_cr4 >> 11U) & 0x7fU) != 0) {
> -        PRINTF("CR4: bits [17:11] are not zero (0x%"PRIx64")\n",
> +        PRINTF("CR4: bits [17:11] are not zero (%#"PRIx64")\n",
>                  vmcb->_cr4);
>      }
>  
>      if ((vmcb->_dr6 >> 32U) != 0) {
> -        PRINTF("DR6: bits [63:32] are not zero (0x%"PRIx64")\n",
> +        PRINTF("DR6: bits [63:32] are not zero (%#"PRIx64")\n",
>                  vmcb->_dr6);
>      }
>  
>      if ((vmcb->_dr7 >> 32U) != 0) {
> -        PRINTF("DR7: bits [63:32] are not zero (0x%"PRIx64")\n",
> +        PRINTF("DR7: bits [63:32] are not zero (%#"PRIx64")\n",
>                  vmcb->_dr7);
>      }
>  
>      if ((vmcb->_efer >> 15U) != 0) {
> -        PRINTF("EFER: bits [63:15] are not zero (0x%"PRIx64")\n",
> +        PRINTF("EFER: bits [63:15] are not zero (%#"PRIx64")\n",
>                  vmcb->_efer);
>      }
>  
> @@ -168,12 +167,12 @@ svm_vmcb_isvalid(const char *from, struc
>      }
>  
>      if ((vmcb->_general2_intercepts & GENERAL2_INTERCEPT_VMRUN) == 0) {
> -        PRINTF("GENERAL2_INTERCEPT: VMRUN intercept bit is clear
> (0x%"PRIx32")\n",
> +        PRINTF("GENERAL2_INTERCEPT: VMRUN intercept bit is clear
> (%#"PRIx32")\n",
>              vmcb->_general2_intercepts);
>      }
>  
>      if (vmcb->eventinj.fields.resvd1 != 0) {
> -        PRINTF("eventinj: MBZ bits are set (0x%"PRIx64")\n",
> +        PRINTF("eventinj: MBZ bits are set (%#"PRIx64")\n",
>                  vmcb->eventinj.bytes);
>      }
>  
> --- 2012-09-21.orig/xen/arch/x86/hvm/vlapic.c 2012-09-20 08:44:38.000000000
> +0200
> +++ 2012-09-21/xen/arch/x86/hvm/vlapic.c 2012-09-21 10:54:46.000000000 +0200
> @@ -172,7 +172,7 @@ static uint32_t vlapic_get_ppr(struct vl
>          ppr = isrv & 0xf0;
>  
>      HVM_DBG_LOG(DBG_LEVEL_VLAPIC_INTERRUPT,
> -                "vlapic %p, ppr 0x%x, isr 0x%x, isrv 0x%x",
> +                "vlapic %p, ppr %#x, isr %#x, isrv %#x",
>                  vlapic, ppr, isr, isrv);
>  
>      return ppr;
> @@ -215,8 +215,8 @@ bool_t vlapic_match_dest(
>      struct vlapic *target, struct vlapic *source,
>      int short_hand, uint8_t dest, uint8_t dest_mode)
>  {
> -    HVM_DBG_LOG(DBG_LEVEL_VLAPIC, "target %p, source %p, dest 0x%x, "
> -                "dest_mode 0x%x, short_hand 0x%x",
> +    HVM_DBG_LOG(DBG_LEVEL_VLAPIC, "target %p, source %p, dest %#x, "
> +                "dest_mode %#x, short_hand %#x",
>                  target, source, dest, dest_mode, short_hand);
>  
>      switch ( short_hand )
> @@ -562,20 +562,20 @@ static int vlapic_read(
>          break;
>  
>      default:
> -        gdprintk(XENLOG_ERR, "Local APIC read with len=0x%lx, "
> +        gdprintk(XENLOG_ERR, "Local APIC read with len=%#lx, "
>                   "should be 4 instead.\n", len);
>          goto exit_and_crash;
>      }
>  
> -    HVM_DBG_LOG(DBG_LEVEL_VLAPIC, "offset 0x%x with length 0x%lx, "
> -                "and the result is 0x%lx", offset, len, result);
> +    HVM_DBG_LOG(DBG_LEVEL_VLAPIC, "offset %#x with length %#lx, "
> +                "and the result is %#lx", offset, len, result);
>  
>   out:
>      *pval = result;
>      return X86EMUL_OKAY;
>  
>   unaligned_exit_and_crash:
> -    gdprintk(XENLOG_ERR, "Unaligned LAPIC read len=0x%lx at offset=0x%x.\n",
> +    gdprintk(XENLOG_ERR, "Unaligned LAPIC read len=%#lx at offset=%#x.\n",
>               len, offset);
>   exit_and_crash:
>      domain_crash(v->domain);
> @@ -759,7 +759,7 @@ static int vlapic_reg_write(struct vcpu
>  
>      case APIC_TDCR:
>          vlapic_set_tdcr(vlapic, val & 0xb);
> -        HVM_DBG_LOG(DBG_LEVEL_VLAPIC_TIMER, "timer divisor is 0x%x",
> +        HVM_DBG_LOG(DBG_LEVEL_VLAPIC_TIMER, "timer divisor is %#x",
>                      vlapic->hw.timer_divisor);
>          break;
>  
> @@ -768,7 +768,7 @@ static int vlapic_reg_write(struct vcpu
>      }
>      if (rc == X86EMUL_UNHANDLEABLE)
>          gdprintk(XENLOG_DEBUG,
> -                "Local APIC Write wrong to register 0x%x\n", offset);
> +                "Local APIC Write wrong to register %#x\n", offset);
>      return rc;
>  }
>  
> @@ -781,7 +781,7 @@ static int vlapic_write(struct vcpu *v,
>  
>      if ( offset != 0xb0 )
>          HVM_DBG_LOG(DBG_LEVEL_VLAPIC,
> -                    "offset 0x%x with length 0x%lx, and value is 0x%lx",
> +                    "offset %#x with length %#lx, and value is %#lx",
>                      offset, len, val);
>  
>      /*
> @@ -827,7 +827,7 @@ static int vlapic_write(struct vcpu *v,
>      return vlapic_reg_write(v, offset, val);
>  
>   unaligned_exit_and_crash:
> -    gdprintk(XENLOG_ERR, "Unaligned LAPIC write len=0x%lx at offset=0x%x.\n",
> +    gdprintk(XENLOG_ERR, "Unaligned LAPIC write len=%#lx at offset=%#x.\n",
>               len, offset);
>   exit_and_crash:
>      domain_crash(v->domain);
> --- 2012-09-21.orig/xen/arch/x86/hvm/vmx/vmcs.c 2012-09-20 08:44:38.000000000
> +0200
> +++ 2012-09-21/xen/arch/x86/hvm/vmx/vmcs.c 2012-09-21 10:54:46.000000000 +0200
> @@ -121,7 +121,7 @@ static u32 adjust_vmx_controls(
>  static bool_t cap_check(const char *name, u32 expected, u32 saw)
>  {
>      if ( saw != expected )
> -        printk("VMX %s: saw 0x%08x expected 0x%08x\n", name, saw, expected);
> +        printk("VMX %s: saw %#x expected %#x\n", name, saw, expected);
>      return saw != expected;
>  }
>  
> --- 2012-09-21.orig/xen/arch/x86/hvm/vmx/vmx.c 2012-09-20 08:44:38.000000000
> +0200
> +++ 2012-09-21/xen/arch/x86/hvm/vmx/vmx.c 2012-09-21 11:01:46.000000000 +0200
> @@ -210,7 +210,7 @@ long_mode_do_msr_read(unsigned int msr,
>          return HNDL_unhandled;
>      }
>  
> -    HVM_DBG_LOG(DBG_LEVEL_0, "msr 0x%x content 0x%"PRIx64, msr,
> *msr_content);
> +    HVM_DBG_LOG(DBG_LEVEL_0, "msr %#x content %#"PRIx64, msr, *msr_content);
>  
>      return HNDL_done;
>  }
> @@ -222,7 +222,7 @@ long_mode_do_msr_write(unsigned int msr,
>      struct vmx_msr_state *guest_msr_state = &v->arch.hvm_vmx.msr_state;
>      struct vmx_msr_state *host_msr_state = &this_cpu(host_msr_state);
>  
> -    HVM_DBG_LOG(DBG_LEVEL_0, "msr 0x%x content 0x%"PRIx64, msr, msr_content);
> +    HVM_DBG_LOG(DBG_LEVEL_0, "msr %#x content %#"PRIx64, msr, msr_content);
>  
>      switch ( msr )
>      {
> @@ -466,7 +466,7 @@ static int vmx_restore_cr0_cr3(
>                                       NULL, P2M_ALLOC);
>              if ( !page )
>              {
> -                gdprintk(XENLOG_ERR, "Invalid CR3 value=0x%lx\n", cr3);
> +                gdprintk(XENLOG_ERR, "Invalid CR3 value=%#lx\n", cr3);
>                  return -EINVAL;
>              }
>          }
> @@ -492,7 +492,7 @@ static int vmx_vmcs_restore(struct vcpu
>           ((c->pending_type == 1) || (c->pending_type > 6) ||
>            (c->pending_reserved != 0)) )
>      {
> -        gdprintk(XENLOG_ERR, "Invalid pending event 0x%"PRIx32".\n",
> +        gdprintk(XENLOG_ERR, "Invalid pending event %#"PRIx32".\n",
>                   c->pending_event);
>          return -EINVAL;
>      }
> @@ -524,7 +524,7 @@ static int vmx_vmcs_restore(struct vcpu
>  
>      if ( c->pending_valid )
>      {
> -        gdprintk(XENLOG_INFO, "Re-injecting 0x%"PRIx32", 0x%"PRIx32"\n",
> +        gdprintk(XENLOG_INFO, "Re-injecting %#"PRIx32", %#"PRIx32"\n",
>                   c->pending_event, c->error_code);
>  
>          if ( hvm_event_needs_reinjection(c->pending_type, c->pending_vector)
> )
> @@ -1789,7 +1789,7 @@ static int is_last_branch_msr(u32 ecx)
>  
>  static int vmx_msr_read_intercept(unsigned int msr, uint64_t *msr_content)
>  {
> -    HVM_DBG_LOG(DBG_LEVEL_1, "ecx=%x", msr);
> +    HVM_DBG_LOG(DBG_LEVEL_1, "ecx=%#x", msr);
>  
>      switch ( msr )
>      {
> @@ -1854,7 +1854,7 @@ static int vmx_msr_read_intercept(unsign
>      }
>  
>  done:
> -    HVM_DBG_LOG(DBG_LEVEL_1, "returns: ecx=%x, msr_value=0x%"PRIx64,
> +    HVM_DBG_LOG(DBG_LEVEL_1, "returns: ecx=%#x, msr_value=%#"PRIx64,
>                  msr, *msr_content);
>      return X86EMUL_OKAY;
>  
> @@ -1927,8 +1927,7 @@ static int vmx_msr_write_intercept(unsig
>  {
>      struct vcpu *v = current;
>  
> -    HVM_DBG_LOG(DBG_LEVEL_1, "ecx=%x, msr_value=0x%"PRIx64,
> -                msr, msr_content);
> +    HVM_DBG_LOG(DBG_LEVEL_1, "ecx=%#x, msr_value=%#"PRIx64, msr,
> msr_content);
>  
>      switch ( msr )
>      {
> @@ -2107,7 +2106,7 @@ static void vmx_failed_vmentry(unsigned
>      unsigned long exit_qualification = __vmread(EXIT_QUALIFICATION);
>      struct vcpu *curr = current;
>  
> -    printk("Failed vm entry (exit reason 0x%x) ", exit_reason);
> +    printk("Failed vm entry (exit reason %#x) ", exit_reason);
>      switch ( failed_vmentry_reason )
>      {
>      case EXIT_REASON_INVALID_GUEST_STATE:
> --- 2012-09-21.orig/xen/arch/x86/io_apic.c 2012-09-21 10:32:44.000000000 +0200
> +++ 2012-09-21/xen/arch/x86/io_apic.c 2012-09-21 10:54:46.000000000 +0200
> @@ -2204,7 +2204,7 @@ int io_apic_set_pci_routing (int ioapic,
>      entry.vector = vector;
>  
>      apic_printk(APIC_DEBUG, KERN_DEBUG "IOAPIC[%d]: Set PCI routing entry "
> -  "(%d-%d -> 0x%x -> IRQ %d Mode:%i Active:%i)\n", ioapic,
> +  "(%d-%d -> %#x -> IRQ %d Mode:%i Active:%i)\n", ioapic,
> mp_ioapics[ioapic].mpc_apicid, pin, entry.vector, irq,
> edge_level, active_high_low);
>  
> --- 2012-09-21.orig/xen/arch/x86/microcode_amd.c 2012-02-10 11:25:54.000000000
> +0100
> +++ 2012-09-21/xen/arch/x86/microcode_amd.c 2012-09-21 10:54:46.000000000
> +0200
> @@ -88,7 +88,7 @@ static int collect_cpu_info(int cpu, str
>  
>      rdmsrl(MSR_AMD_PATCHLEVEL, csig->rev);
>  
> -    printk(KERN_DEBUG "microcode: collect_cpu_info: patch_id=0x%x\n",
> +    printk(KERN_DEBUG "microcode: collect_cpu_info: patch_id=%#x\n",
>             csig->rev);
>  
>      return 0;
> @@ -132,7 +132,7 @@ static int microcode_fits(const struct m
>          return 0;
>  
>      printk(KERN_DEBUG "microcode: CPU%d found a matching microcode "
> -           "update with version 0x%x (current=0x%x)\n",
> +           "update with version %#x (current=%#x)\n",
>             cpu, mc_header->patch_id, uci->cpu_sig.rev);
>  
>      return 1;
> @@ -169,7 +169,7 @@ static int apply_microcode(int cpu)
>      if ( rev != hdr->patch_id )
>      {
>          printk(KERN_ERR "microcode: CPU%d update from revision "
> -               "0x%x to 0x%x failed\n", cpu, hdr->patch_id, rev);
> +               "%#x to %#x failed\n", cpu, hdr->patch_id, rev);
>          return -EIO;
>      }
>  
> --- 2012-09-21.orig/xen/arch/x86/microcode_intel.c 2011-12-12
> 09:01:34.000000000 +0100
> +++ 2012-09-21/xen/arch/x86/microcode_intel.c 2012-09-21 10:54:46.000000000
> +0200
> @@ -122,7 +122,7 @@ static int collect_cpu_info(int cpu_num,
>      /* get the current revision from MSR 0x8B */
>      rdmsrl(MSR_IA32_UCODE_REV, msr_content);
>      csig->rev = (uint32_t)(msr_content >> 32);
> -    pr_debug("microcode: collect_cpu_info : sig=0x%x, pf=0x%x, rev=0x%x\n",
> +    pr_debug("microcode: collect_cpu_info : sig=%#x, pf=%#x, rev=%#x\n",
>               csig->sig, csig->pf, csig->rev);
>  
>      return 0;
> @@ -264,7 +264,7 @@ static int get_matching_microcode(const
>      if ( uci->mc.mc_intel && uci->mc.mc_intel->hdr.rev >= mc_header->rev )
>          return 0;
>      pr_debug("microcode: CPU%d found a matching microcode update with"
> -             " version 0x%x (current=0x%x)\n",
> +             " version %#x (current=%#x)\n",
>               cpu, mc_header->rev, uci->cpu_sig.rev);
>      new_mc = xmalloc_bytes(total_size);
>      if ( new_mc == NULL )
> @@ -311,11 +311,11 @@ static int apply_microcode(int cpu)
>      if ( val[1] != uci->mc.mc_intel->hdr.rev )
>      {
>          printk(KERN_ERR "microcode: CPU%d update from revision "
> -               "0x%x to 0x%x failed\n", cpu_num, uci->cpu_sig.rev, val[1]);
> +               "%#x to %#x failed\n", cpu_num, uci->cpu_sig.rev, val[1]);
>          return -EIO;
>      }
>      printk(KERN_INFO "microcode: CPU%d updated from revision "
> -           "0x%x to 0x%x, date = %04x-%02x-%02x \n",
> +           "%#x to %#x, date = %04x-%02x-%02x \n",
>             cpu_num, uci->cpu_sig.rev, val[1],
>             uci->mc.mc_intel->hdr.date & 0xffff,
>             uci->mc.mc_intel->hdr.date >> 24,
> --- 2012-09-21.orig/xen/arch/x86/mm.c 2012-09-14 13:26:34.000000000 +0200
> +++ 2012-09-21/xen/arch/x86/mm.c 2012-09-21 10:54:46.000000000 +0200
> @@ -3102,7 +3102,7 @@ long do_mmuext_op(
>          }
>  
>          default:
> -            MEM_LOG("Invalid extended pt command 0x%x", op.cmd);
> +            MEM_LOG("Invalid extended pt command %#x", op.cmd);
>              rc = -ENOSYS;
>              okay = 0;
>              break;
> --- 2012-09-21.orig/xen/arch/x86/mm/hap/nested_hap.c 2012-08-08 
> 08:20:09.000000000 +0200
> +++ 2012-09-21/xen/arch/x86/mm/hap/nested_hap.c 2012-09-21 10:54:46.000000000 
> +0200
> @@ -129,7 +129,7 @@ nestedhap_fix_p2m(struct vcpu *v, struct
>  
>      if (rv == 0) {
>          gdprintk(XENLOG_ERR,
> -  "failed to set entry for 0x%"PRIx64" -> 0x%"PRIx64"\n",
> +  "failed to set entry for %#"PRIx64" -> %#"PRIx64"\n",
> L2_gpa, L0_gpa);
>          BUG();
>      }
> --- 2012-09-21.orig/xen/arch/x86/mm/p2m-pt.c 2012-09-14 13:26:34.000000000 
> +0200
> +++ 2012-09-21/xen/arch/x86/mm/p2m-pt.c 2012-09-21 10:54:46.000000000 +0200
> @@ -110,8 +110,8 @@ p2m_find_entry(void *table, unsigned lon
>      index = *gfn_remainder >> shift;
>      if ( index >= max )
>      {
> -        P2M_DEBUG("gfn=0x%lx out of range "
> -                  "(gfn_remainder=0x%lx shift=%d index=0x%x max=0x%x)\n",
> +        P2M_DEBUG("gfn=%#lx out of range "
> +                  "(gfn_remainder=%#lx shift=%d index=%#x max=%#x)\n",
>                    gfn, *gfn_remainder, shift, index, max);
>          return NULL;
>      }
> --- 2012-09-21.orig/xen/arch/x86/mm/shadow/common.c 2012-09-14 
> 13:26:34.000000000 +0200
> +++ 2012-09-21/xen/arch/x86/mm/shadow/common.c 2012-09-21 10:57:38.000000000 
> +0200
> @@ -872,7 +872,7 @@ static int sh_skip_sync(struct vcpu *v, 
>          return SHADOW_INTERNAL_NAME(sh_safe_not_to_sync, 3)(v, gl1mfn);
>      else if ( pg->shadow_flags & SHF_L1_64 )
>          return SHADOW_INTERNAL_NAME(sh_safe_not_to_sync, 4)(v, gl1mfn);
> -    SHADOW_ERROR("gmfn 0x%lx was OOS but not shadowed as an l1.\n", 
> +    SHADOW_ERROR("gmfn %#lx was OOS but not shadowed as an l1.\n",
>                   mfn_x(gl1mfn));
>      BUG();
>      return 0; /* BUG() is no longer __attribute__((noreturn)). */
> @@ -2596,8 +2596,8 @@ void sh_remove_shadows(struct vcpu *v, m
>      smfn = shadow_hash_lookup(v, mfn_x(gmfn), t);                       \
>      if ( unlikely(!mfn_valid(smfn)) )                                   \
>      {                                                                   \
> -        SHADOW_ERROR(": gmfn %#lx has flags 0x%"PRIx32                  \
> -                     " but no type-0x%"PRIx32" shadow\n",               \
> +        SHADOW_ERROR(": gmfn %#lx has flags %#"PRIx32                   \
> +                     " but no type-%#"PRIx32" shadow\n",                \
>                       mfn_x(gmfn), (uint32_t)pg->shadow_flags, t);       \
>          break;                                                          \
>      }                                                                   \
> --- 2012-09-21.orig/xen/arch/x86/mm/shadow/multi.c 2012-09-14 
> 13:26:34.000000000 +0200
> +++ 2012-09-21/xen/arch/x86/mm/shadow/multi.c 2012-09-21 10:54:46.000000000 
> +0200
> @@ -2171,7 +2171,7 @@ static int validate_gl4e(struct vcpu *v,
>              // attempt by the guest to write to a xen reserved slot
>              //
>              SHADOW_PRINTK("%s out-of-range update "
> -                           "sl4mfn=%05lx index=0x%x val=%" SH_PRI_pte "\n",
> +                           "sl4mfn=%05lx index=%#x val=%" SH_PRI_pte "\n",
>                             __func__, mfn_x(sl4mfn), shadow_index, 
> new_sl4e.l4);
>              if ( shadow_l4e_get_flags(new_sl4e) & _PAGE_PRESENT )
>              {
> --- 2012-09-21.orig/xen/arch/x86/mpparse.c 2012-04-20 09:49:25.000000000 +0200
> +++ 2012-09-21/xen/arch/x86/mpparse.c 2012-09-21 10:54:46.000000000 +0200
> @@ -216,7 +216,7 @@ static void __init MP_ioapic_info (struc
> if (!(m->mpc_flags & MPC_APIC_USABLE))
> return;
>  
> - printk(KERN_INFO "I/O APIC #%d Version %d at 0x%X.\n",
> + printk(KERN_INFO "I/O APIC #%d Version %d at %#x.\n",
> m->mpc_apicid, m->mpc_apicver, m->mpc_apicaddr);
> if (nr_ioapics >= MAX_IO_APICS) {
> printk(KERN_CRIT "Max # of I/O APICs (%d) exceeded (found %d).\n",
> @@ -278,7 +278,7 @@ static int __init smp_read_mpc(struct mp
> unsigned char *mpt=((unsigned char *)mpc)+count;
>  
> if (memcmp(mpc->mpc_signature,MPC_SIGNATURE,4)) {
> -  printk(KERN_ERR "SMP mptable: bad signature [0x%x]!\n",
> +  printk(KERN_ERR "SMP mptable: bad signature [%#x]!\n",
> *(u32 *)mpc->mpc_signature);
> return 0;
> }
> @@ -305,7 +305,7 @@ static int __init smp_read_mpc(struct mp
>  
> mps_oem_check(mpc, oem, str);
>  
> - printk("APIC at: 0x%X\n",mpc->mpc_lapic);
> + printk("APIC at: %#x\n", mpc->mpc_lapic);
>  
> /* 
> * Save the local APIC address (it might be non-default) -- but only
> @@ -881,7 +881,7 @@ void __init mp_register_ioapic (
> mp_ioapic_routing[idx].gsi_end = gsi_base + 
> io_apic_get_redir_entries(idx);
>  
> - printk("IOAPIC[%d]: apic_id %d, version %d, address 0x%x, "
> + printk("IOAPIC[%d]: apic_id %d, version %d, address %#x, "
> "GSI %d-%d\n", idx, mp_ioapics[idx].mpc_apicid, 
> mp_ioapics[idx].mpc_apicver, mp_ioapics[idx].mpc_apicaddr,
> mp_ioapic_routing[idx].gsi_base,
> --- 2012-09-21.orig/xen/arch/x86/nmi.c 2012-08-08 08:20:09.000000000 +0200
> +++ 2012-09-21/xen/arch/x86/nmi.c 2012-09-21 10:54:46.000000000 +0200
> @@ -245,7 +245,7 @@ static inline void write_watchdog_counte
>  
>      do_div(count, nmi_hz);
>      if(descr)
> -        Dprintk("setting %s to -0x%"PRIx64"\n", descr, count);
> +        Dprintk("setting %s to -%#"PRIx64"\n", descr, count);
>      wrmsrl(nmi_perfctr_msr, 0 - count);
>  }
>  
> --- 2012-09-21.orig/xen/arch/x86/oprofile/op_model_athlon.c 2012-09-14 
> 13:26:34.000000000 +0200
> +++ 2012-09-21/xen/arch/x86/oprofile/op_model_athlon.c 2012-09-21 
> 10:54:46.000000000 +0200
> @@ -478,7 +478,7 @@ static int __init init_ibs_nmi(void)
> if (value != (IBSCTL_LVTOFFSETVAL |
> APIC_EILVT_LVTOFF_IBS)) {
> printk("Xenoprofile: Failed to setup IBS LVT offset, "
> -       "IBSCTL = %#08x\n", value);
> +       "IBSCTL = %#x\n", value);
> return 1;
> }
> nodes++;
> @@ -523,7 +523,7 @@ void __init ibs_init(void)
> return;
> }
>  
> - printk("Xenoprofile: AMD IBS detected (0x%08x)\n",
> + printk("Xenoprofile: AMD IBS detected (%#x)\n",
> (unsigned)ibs_caps);
>  }
>  
> --- 2012-09-21.orig/xen/arch/x86/oprofile/op_model_p4.c 2012-02-10 
> 11:25:54.000000000 +0100
> +++ 2012-09-21/xen/arch/x86/oprofile/op_model_p4.c 2012-09-21 
> 10:54:46.000000000 +0200
> @@ -485,8 +485,7 @@ static void pmc_setup_one_p4_counter(uns
> 
> /* find our event binding structure. */
> if (counter_config[ctr].event <= 0 || counter_config[ctr].event > NUM_EVENTS) 
> {
> -  printk(KERN_ERR 
> -         "oprofile: P4 event code 0x%lx out of range\n", 
> +  printk(KERN_ERR "oprofile: P4 event code %#lx out of range\n",
>       counter_config[ctr].event);
> return;
> }
> @@ -526,7 +525,7 @@ static void pmc_setup_one_p4_counter(uns
> }
>  
> printk(KERN_ERR 
> -        "oprofile: P4 event code 0x%lx no binding, stag %d ctr %d\n",
> +        "oprofile: P4 event code %#lx no binding, stag %d ctr %d\n",
>       counter_config[ctr].event, stag, ctr);
>  }
>  
> --- 2012-09-21.orig/xen/arch/x86/setup.c 2012-09-17 09:57:54.000000000 +0200
> +++ 2012-09-21/xen/arch/x86/setup.c 2012-09-21 11:01:12.000000000 +0200
> @@ -482,13 +482,13 @@ static void __init kexec_reserve_area(st
>  
>      if ( !reserve_e820_ram(e820, kdump_start, kdump_start + kdump_size) )
>      {
> -        printk("Kdump: DISABLED (failed to reserve %luMB (%lukB) at 0x%lx)"
> +        printk("Kdump: DISABLED (failed to reserve %luMB (%lukB) at %#lx)"
>                 "\n", kdump_size >> 20, kdump_size >> 10, kdump_start);
>          kexec_crash_area.start = kexec_crash_area.size = 0;
>      }
>      else
>      {
> -        printk("Kdump: %luMB (%lukB) at 0x%lx\n",
> +        printk("Kdump: %luMB (%lukB) at %#lx\n",
>                 kdump_size >> 20, kdump_size >> 10, kdump_start);
>      }
>  }
> --- 2012-09-21.orig/xen/arch/x86/tboot.c 2012-01-20 10:10:22.000000000 +0100
> +++ 2012-09-21/xen/arch/x86/tboot.c 2012-09-21 10:54:46.000000000 +0200
> @@ -119,12 +119,12 @@ void __init tboot_probe(void)
>      g_tboot_shared = tboot_shared;
>      printk("TBOOT: found shared page at phys addr %lx:\n", p_tboot_shared);
>      printk("  version: %d\n", tboot_shared->version);
> -    printk("  log_addr: 0x%08x\n", tboot_shared->log_addr);
> -    printk("  shutdown_entry: 0x%08x\n", tboot_shared->shutdown_entry);
> -    printk("  tboot_base: 0x%08x\n", tboot_shared->tboot_base);
> -    printk("  tboot_size: 0x%x\n", tboot_shared->tboot_size);
> +    printk("  log_addr: %#x\n", tboot_shared->log_addr);
> +    printk("  shutdown_entry: %#x\n", tboot_shared->shutdown_entry);
> +    printk("  tboot_base: %#x\n", tboot_shared->tboot_base);
> +    printk("  tboot_size: %#x\n", tboot_shared->tboot_size);
>      if ( tboot_shared->version >= 6 )
> -        printk("  flags: 0x%08x\n", tboot_shared->flags);
> +        printk("  flags: %#x\n", tboot_shared->flags);
>  
>      /* these will be needed by tboot_protect_mem_regions() and/or
>         tboot_parse_dmar_table(), so get them now */
> @@ -352,7 +352,7 @@ void tboot_shutdown(uint32_t shutdown_ty
>                             __PAGE_HYPERVISOR);
>      if ( err != 0 )
>      {
> -        printk("error (0x%x) mapping tboot pages (mfns) @ 0x%x, 0x%x\n", err,
> +        printk("error (%#x) mapping tboot pages (mfns) @ %#x, %#x\n", err,
>                 map_base, map_size);
>          return;
>      }
> --- 2012-09-21.orig/xen/arch/x86/time.c 2012-09-14 13:26:34.000000000 +0200
> +++ 2012-09-21/xen/arch/x86/time.c 2012-09-21 10:54:46.000000000 +0200
> @@ -1955,11 +1955,11 @@ static void dump_softtsc(unsigned char k
>          printk("dom%u%s: mode=%d",d->domain_id,
>                  is_hvm_domain(d) ? "(hvm)" : "", d->arch.tsc_mode);
>          if ( d->arch.vtsc_offset )
> -            printk(",ofs=0x%"PRIx64"",d->arch.vtsc_offset);
> +            printk(",ofs=%#"PRIx64, d->arch.vtsc_offset);
>          if ( d->arch.tsc_khz )
> -            printk(",khz=%"PRIu32"",d->arch.tsc_khz);
> +            printk(",khz=%"PRIu32, d->arch.tsc_khz);
>          if ( d->arch.incarnation )
> -            printk(",inc=%"PRIu32"",d->arch.incarnation);
> +            printk(",inc=%"PRIu32, d->arch.incarnation);
>          if ( !(d->arch.vtsc_kerncount | d->arch.vtsc_usercount) )
>          {
>              printk("\n");
> --- 2012-09-21.orig/xen/arch/x86/xstate.c 2012-01-30 10:46:14.000000000 +0100
> +++ 2012-09-21/xen/arch/x86/xstate.c 2012-09-21 10:54:46.000000000 +0200
> @@ -163,7 +163,7 @@ void xstate_init(void)
>          xsave_cntxt_size = ebx;
>          xfeature_mask = eax + ((u64)edx << 32);
>          xfeature_mask &= XCNTXT_MASK;
> -        printk("%s: using cntxt_size: 0x%x and states: 0x%"PRIx64"\n",
> +        printk("%s: using cntxt_size: %#x and states: %#"PRIx64"\n",
>              __func__, xsave_cntxt_size, xfeature_mask);
>  
>          /* Check XSAVEOPT feature. */
> --- 2012-09-21.orig/xen/common/gdbstub.c 2010-05-20 09:59:27.000000000 +0200
> +++ 2012-09-21/xen/common/gdbstub.c 2012-09-21 10:54:46.000000000 +0200
> @@ -263,7 +263,7 @@ gdb_write_to_packet_hex(unsigned long x,
>      case sizeof(u64):
>          break;
>      default:
> -        dbg_printk("WARNING: %s x: 0x%lx int_size: %d\n",
> +        dbg_printk("WARNING: %s x: %#lx int_size: %d\n",
>                     __func__, x, int_size);
>          break;
>      }
> --- 2012-09-21.orig/xen/common/page_alloc.c 2012-09-14 13:26:34.000000000 
> +0200
> +++ 2012-09-21/xen/common/page_alloc.c 2012-09-21 10:54:46.000000000 +0200
> @@ -367,7 +367,7 @@ static void __init setup_low_mem_virq(vo
>      low_mem_virq_th = low_mem_virq_orig = 1UL << order;
>      low_mem_virq_th_order = order;
>  
> -    printk("Initial low memory virq threshold set at 0x%lx pages.\n",
> +    printk("Initial low memory virq threshold set at %#lx pages.\n",
>              low_mem_virq_th);
>  }
>  
> --- 2012-09-21.orig/xen/common/vsprintf.c 2012-02-10 11:25:54.000000000 +0100
> +++ 2012-09-21/xen/common/vsprintf.c 2012-09-21 10:54:46.000000000 +0200
> @@ -171,10 +171,14 @@ static char *number(
>          }
>      }
>      if (type & SPECIAL) {
> -        if (base == 16)
> +        if (num == 0)
> +            type &= ~SPECIAL;
> +        else if (base == 16)
>              size -= 2;
>          else if (base == 8)
>              size--;
> +        else
> +            type &= ~SPECIAL;
>      }
>      i = 0;
>      if (num == 0)
> @@ -197,14 +201,10 @@ static char *number(
>          ++buf;
>      }
>      if (type & SPECIAL) {
> -        if (base==8) {
> -            if (buf <= end)
> -                *buf = '0';
> -            ++buf;
> -        } else if (base==16) {
> -            if (buf <= end)
> -                *buf = '0';
> -            ++buf;
> +        if (buf <= end)
> +            *buf = '0';
> +        ++buf;
> +        if (base == 16) {
>              if (buf <= end)
>                  *buf = digits[33];
>              ++buf;
> --- 2012-09-21.orig/xen/common/xencomm.c 2012-01-24 10:11:51.000000000 +0100
> +++ 2012-09-21/xen/common/xencomm.c 2012-09-21 10:54:46.000000000 +0200
> @@ -58,7 +58,7 @@ xencomm_get_page(unsigned long paddr, st
>           * is freed with decrease reservation hypercall at the same time.
>           */
>          gdprintk(XENLOG_WARNING,
> -                 "bad page is passed. paddr 0x%lx maddr 0x%lx\n",
> +                 "bad page is passed. paddr %#lx maddr %#lx\n",
>                   paddr, maddr);
>          return -EFAULT;
>      }
> @@ -117,7 +117,7 @@ xencomm_ctxt_init(const void *handle, st
>      desc = xencomm_vaddr((unsigned long)handle, page);
>      if ( desc->magic != XENCOMM_MAGIC )
>      {
> -        printk("%s: error: %p magic was 0x%x\n", __func__, desc, 
> desc->magic);
> +        printk("%s: error: %p magic was %#x\n", __func__, desc, desc->magic);
>          put_page(page);
>          return -EINVAL;
>      }
> --- 2012-09-21.orig/xen/drivers/acpi/numa.c 2012-09-14 13:26:34.000000000 
> +0200
> +++ 2012-09-21/xen/drivers/acpi/numa.c 2012-09-21 10:54:46.000000000 +0200
> @@ -78,8 +78,8 @@ void __init acpi_table_print_srat_entry(
> if (srat_rev < 2)
> proximity_domain &= 0xff;
> ACPI_DEBUG_PRINT((ACPI_DB_INFO,
> -       "SRAT Memory (%#016"PRIx64
> -       " length %#016"PRIx64")"
> +       "SRAT Memory (%#"PRIx64
> +       " length %#"PRIx64")"
>  " in proximity domain %d %s%s\n",
>  p->base_address, p->length,
>  proximity_domain,
> @@ -108,7 +108,7 @@ void __init acpi_table_print_srat_entry(
> break;
> default:
> printk(KERN_WARNING PREFIX
> -         "Found unsupported SRAT entry (type = 0x%x)\n",
> +         "Found unsupported SRAT entry (type = %#x)\n",
>       header->type);
> break;
> }
> --- 2012-09-21.orig/xen/drivers/acpi/tables.c 2012-09-21 10:32:44.000000000 
> +0200
> +++ 2012-09-21/xen/drivers/acpi/tables.c 2012-09-21 10:54:46.000000000 +0200
> @@ -95,7 +95,7 @@ void __init acpi_table_print_madt_entry(
> if (p->inti_flags  &
>    ~(ACPI_MADT_POLARITY_MASK | ACPI_MADT_TRIGGER_MASK))
> printk(KERN_INFO PREFIX
> -           "INT_SRC_OVR unexpected reserved flags: 0x%x\n",
> +           "INT_SRC_OVR unexpected reserved flags: %#x\n",
>       p->inti_flags  &
> ~(ACPI_MADT_POLARITY_MASK | ACPI_MADT_TRIGGER_MASK));
>  
> @@ -119,7 +119,7 @@ void __init acpi_table_print_madt_entry(
> struct acpi_madt_local_apic_nmi *p =
>    (struct acpi_madt_local_apic_nmi *)header;
> printk(KERN_INFO PREFIX
> -          "LAPIC_NMI (acpi_id[0x%02x] %s %s lint[0x%x])\n",
> +          "LAPIC_NMI (acpi_id[0x%02x] %s %s lint[%#x])\n",
>       p->processor_id,
>       mps_inti_flags_polarity[p->inti_flags & ACPI_MADT_POLARITY_MASK ],
>       mps_inti_flags_trigger[(p->inti_flags & ACPI_MADT_TRIGGER_MASK) >> 2],
> @@ -137,7 +137,7 @@ void __init acpi_table_print_madt_entry(
> trigger = (p->inti_flags & ACPI_MADT_TRIGGER_MASK) >> 2;
>  
> printk(KERN_INFO PREFIX
> -          "X2APIC_NMI (uid[0x%02x] %s %s lint[0x%x])\n",
> +          "X2APIC_NMI (uid[0x%02x] %s %s lint[%#x])\n",
>       p->uid,
>       mps_inti_flags_polarity[polarity],
>       mps_inti_flags_trigger[trigger],
> @@ -160,7 +160,7 @@ void __init acpi_table_print_madt_entry(
> struct acpi_madt_io_sapic *p =
>    (struct acpi_madt_io_sapic *)header;
> printk(KERN_INFO PREFIX
> -          "IOSAPIC (id[0x%x] address[%p] gsi_base[%d])\n",
> +          "IOSAPIC (id[%#x] address[%p] gsi_base[%d])\n",
>       p->id, (void *)(unsigned long)p->address,
>       p->global_irq_base);
> }
> @@ -182,7 +182,7 @@ void __init acpi_table_print_madt_entry(
> struct acpi_madt_interrupt_source *p =
>    (struct acpi_madt_interrupt_source *)header;
> printk(KERN_INFO PREFIX
> -          "PLAT_INT_SRC (%s %s type[0x%x] id[0x%04x] eid[0x%x] 
> iosapic_vector[0x%x] global_irq[0x%x]\n",
> +          "PLAT_INT_SRC (%s %s type[%#x] id[0x%04x] eid[%#x] 
> iosapic_vector[%#x] global_irq[%#x]\n",
>       mps_inti_flags_polarity[p->inti_flags & ACPI_MADT_POLARITY_MASK],
>       mps_inti_flags_trigger[(p->inti_flags & ACPI_MADT_TRIGGER_MASK) >> 2],
>       p->type, p->id, p->eid, p->io_sapic_vector,
> @@ -192,7 +192,7 @@ void __init acpi_table_print_madt_entry(
>  
> default:
> printk(KERN_WARNING PREFIX
> -         "Found unsupported MADT entry (type = 0x%x)\n",
> +         "Found unsupported MADT entry (type = %#x)\n",
>       header->type);
> break;
> }
> @@ -242,7 +242,7 @@ acpi_table_parse_entries(char *id,
>    ((unsigned long)entry + entry->length);
> }
> if (max_entries && count > max_entries) {
> -  printk(KERN_WARNING PREFIX "[%4.4s:0x%02x] ignored %i entries of "
> +  printk(KERN_WARNING PREFIX "[%4.4s:%#x] ignored %i entries of "
>       "%i found\n", id, entry_id, count - max_entries, count);
> }
>  
> --- 2012-09-21.orig/xen/drivers/acpi/utilities/utglobal.c 2011-03-11 
> 10:13:55.000000000 +0100
> +++ 2012-09-21/xen/drivers/acpi/utilities/utglobal.c 2012-09-21 
> 10:54:46.000000000 +0200
> @@ -79,7 +79,7 @@ const char *__init acpi_format_exception
> /* Exception code was not recognized */
>  
> ACPI_ERROR((AE_INFO,
> -       "Unknown exception code: 0x%8.8X", status));
> +       "Unknown exception code: %#X", status));
>  
> exception = "UNKNOWN_STATUS_CODE";
> dump_execution_state();
> --- 2012-09-21.orig/xen/drivers/cpufreq/cpufreq.c 2012-09-14 
> 13:26:34.000000000 +0200
> +++ 2012-09-21/xen/drivers/cpufreq/cpufreq.c 2012-09-21 10:54:46.000000000 
> +0200
> @@ -377,7 +377,7 @@ static void print_PSS(struct xen_process
>      printk("\t_PSS: state_count=%d\n", count);
>      for (i=0; i<count; i++){
>          printk("\tState%d: %"PRId64"MHz %"PRId64"mW %"PRId64"us "
> -               "%"PRId64"us 0x%"PRIx64" 0x%"PRIx64"\n",
> +               "%"PRId64"us %#"PRIx64" %#"PRIx64"\n",
>                 i,
>                 ptr[i].core_frequency,
>                 ptr[i].power,
> --- 2012-09-21.orig/xen/drivers/passthrough/amd/iommu_acpi.c 2011-12-14 
> 10:11:38.000000000 +0100
> +++ 2012-09-21/xen/drivers/passthrough/amd/iommu_acpi.c 2012-09-21 
> 10:54:46.000000000 +0200
> @@ -196,7 +196,7 @@ static int __init register_exclusion_ran
>      iommu = find_iommu_for_device(seg, bdf);
>      if ( !iommu )
>      {
> -        AMD_IOMMU_DEBUG("IVMD Error: No IOMMU for Dev_Id 0x%x!\n", bdf);
> +        AMD_IOMMU_DEBUG("IVMD Error: No IOMMU for Dev_Id %#x!\n", bdf);
>          return -ENODEV;
>      }
>      req = ivrs_mappings[bdf].dte_requestor_id;
> @@ -278,7 +278,7 @@ static int __init parse_ivmd_device_sele
>      bdf = ivmd_block->header.device_id;
>      if ( bdf >= ivrs_bdf_entries )
>      {
> -        AMD_IOMMU_DEBUG("IVMD Error: Invalid Dev_Id 0x%x\n", bdf);
> +        AMD_IOMMU_DEBUG("IVMD Error: Invalid Dev_Id %#x\n", bdf);
>          return -ENODEV;
>      }
>  
> @@ -296,7 +296,7 @@ static int __init parse_ivmd_device_rang
>      if ( first_bdf >= ivrs_bdf_entries )
>      {
>          AMD_IOMMU_DEBUG("IVMD Error: "
> -                        "Invalid Range_First Dev_Id 0x%x\n", first_bdf);
> +                        "Invalid Range_First Dev_Id %#x\n", first_bdf);
>          return -ENODEV;
>      }
>  
> @@ -304,7 +304,7 @@ static int __init parse_ivmd_device_rang
>      if ( (last_bdf >= ivrs_bdf_entries) || (last_bdf <= first_bdf) )
>      {
>          AMD_IOMMU_DEBUG("IVMD Error: "
> -                        "Invalid Range_Last Dev_Id 0x%x\n", last_bdf);
> +                        "Invalid Range_Last Dev_Id %#x\n", last_bdf);
>          return -ENODEV;
>      }
>  
> @@ -326,7 +326,7 @@ static int __init parse_ivmd_device_iomm
>                                      ivmd_block->aux_data);
>      if ( !iommu )
>      {
> -        AMD_IOMMU_DEBUG("IVMD Error: No IOMMU for Dev_Id 0x%x  Cap 0x%x\n",
> +        AMD_IOMMU_DEBUG("IVMD Error: No IOMMU for Dev_Id %#x Cap %#x\n",
>                          ivmd_block->header.device_id, ivmd_block->aux_data);
>          return -ENODEV;
>      }
> @@ -351,9 +351,9 @@ static int __init parse_ivmd_block(const
>      base = start_addr & PAGE_MASK;
>      limit = (start_addr + mem_length - 1) & PAGE_MASK;
>  
> -    AMD_IOMMU_DEBUG("IVMD Block: Type 0x%x\n",ivmd_block->header.type);
> -    AMD_IOMMU_DEBUG(" Start_Addr_Phys 0x%lx\n", start_addr);
> -    AMD_IOMMU_DEBUG(" Mem_Length 0x%lx\n", mem_length);
> +    AMD_IOMMU_DEBUG("IVMD Block: Type %#x\n",ivmd_block->header.type);
> +    AMD_IOMMU_DEBUG(" Start_Addr_Phys %#lx\n", start_addr);
> +    AMD_IOMMU_DEBUG(" Mem_Length %#lx\n", mem_length);
>  
>      if ( ivmd_block->header.flags & ACPI_IVMD_EXCLUSION_RANGE )
>          iw = ir = IOMMU_CONTROL_ENABLED;
> @@ -414,7 +414,7 @@ static u16 __init parse_ivhd_device_sele
>      bdf = select->header.id;
>      if ( bdf >= ivrs_bdf_entries )
>      {
> -        AMD_IOMMU_DEBUG("IVHD Error: Invalid Device_Entry Dev_Id 0x%x\n", 
> bdf);
> +        AMD_IOMMU_DEBUG("IVHD Error: Invalid Device_Entry Dev_Id %#x\n", 
> bdf);
>          return 0;
>      }
>  
> @@ -439,7 +439,7 @@ static u16 __init parse_ivhd_device_rang
>      if ( range->end.header.type != ACPI_IVRS_TYPE_END )
>      {
>          AMD_IOMMU_DEBUG("IVHD Error: "
> -                        "Invalid Range: End_Type 0x%x\n",
> +                        "Invalid Range: End_Type %#x\n",
>                          range->end.header.type);
>          return 0;
>      }
> @@ -448,7 +448,7 @@ static u16 __init parse_ivhd_device_rang
>      if ( first_bdf >= ivrs_bdf_entries )
>      {
>          AMD_IOMMU_DEBUG("IVHD Error: "
> -                        "Invalid Range: First Dev_Id 0x%x\n", first_bdf);
> +                        "Invalid Range: First Dev_Id %#x\n", first_bdf);
>          return 0;
>      }
>  
> @@ -456,11 +456,11 @@ static u16 __init parse_ivhd_device_rang
>      if ( (last_bdf >= ivrs_bdf_entries) || (last_bdf <= first_bdf) )
>      {
>          AMD_IOMMU_DEBUG("IVHD Error: "
> -                        "Invalid Range: Last Dev_Id 0x%x\n", last_bdf);
> +                        "Invalid Range: Last Dev_Id %#x\n", last_bdf);
>          return 0;
>      }
>  
> -    AMD_IOMMU_DEBUG(" Dev_Id Range: 0x%x -> 0x%x\n", first_bdf, last_bdf);
> +    AMD_IOMMU_DEBUG(" Dev_Id Range: %#x -> %#x\n", first_bdf, last_bdf);
>  
>      for ( bdf = first_bdf; bdf <= last_bdf; bdf++ )
>          add_ivrs_mapping_entry(bdf, bdf, range->start.header.data_setting,
> @@ -485,18 +485,18 @@ static u16 __init parse_ivhd_device_alia
>      bdf = alias->header.id;
>      if ( bdf >= ivrs_bdf_entries )
>      {
> -        AMD_IOMMU_DEBUG("IVHD Error: Invalid Device_Entry Dev_Id 0x%x\n", 
> bdf);
> +        AMD_IOMMU_DEBUG("IVHD Error: Invalid Device_Entry Dev_Id %#x\n", 
> bdf);
>          return 0;
>      }
>  
>      alias_id = alias->used_id;
>      if ( alias_id >= ivrs_bdf_entries )
>      {
> -        AMD_IOMMU_DEBUG("IVHD Error: Invalid Alias Dev_Id 0x%x\n", alias_id);
> +        AMD_IOMMU_DEBUG("IVHD Error: Invalid Alias Dev_Id %#x\n", alias_id);
>          return 0;
>      }
>  
> -    AMD_IOMMU_DEBUG(" Dev_Id Alias: 0x%x\n", alias_id);
> +    AMD_IOMMU_DEBUG(" Dev_Id Alias: %#x\n", alias_id);
>  
>      add_ivrs_mapping_entry(bdf, alias_id, alias->header.data_setting, iommu);
>  
> @@ -520,7 +520,7 @@ static u16 __init parse_ivhd_device_alia
>      if ( range->end.header.type != ACPI_IVRS_TYPE_END )
>      {
>          AMD_IOMMU_DEBUG("IVHD Error: "
> -                        "Invalid Range: End_Type 0x%x\n",
> +                        "Invalid Range: End_Type %#x\n",
>                          range->end.header.type);
>          return 0;
>      }
> @@ -529,7 +529,7 @@ static u16 __init parse_ivhd_device_alia
>      if ( first_bdf >= ivrs_bdf_entries )
>      {
>          AMD_IOMMU_DEBUG("IVHD Error: "
> -                        "Invalid Range: First Dev_Id 0x%x\n", first_bdf);
> +                        "Invalid Range: First Dev_Id %#x\n", first_bdf);
>          return 0;
>      }
>  
> @@ -537,19 +537,19 @@ static u16 __init parse_ivhd_device_alia
>      if ( last_bdf >= ivrs_bdf_entries || last_bdf <= first_bdf )
>      {
>          AMD_IOMMU_DEBUG(
> -            "IVHD Error: Invalid Range: Last Dev_Id 0x%x\n", last_bdf);
> +            "IVHD Error: Invalid Range: Last Dev_Id %#x\n", last_bdf);
>          return 0;
>      }
>  
>      alias_id = range->alias.used_id;
>      if ( alias_id >= ivrs_bdf_entries )
>      {
> -        AMD_IOMMU_DEBUG("IVHD Error: Invalid Alias Dev_Id 0x%x\n", alias_id);
> +        AMD_IOMMU_DEBUG("IVHD Error: Invalid Alias Dev_Id %#x\n", alias_id);
>          return 0;
>      }
>  
> -    AMD_IOMMU_DEBUG(" Dev_Id Range: 0x%x -> 0x%x\n", first_bdf, last_bdf);
> -    AMD_IOMMU_DEBUG(" Dev_Id Alias: 0x%x\n", alias_id);
> +    AMD_IOMMU_DEBUG(" Dev_Id Range: %#x -> %#x\n", first_bdf, last_bdf);
> +    AMD_IOMMU_DEBUG(" Dev_Id Alias: %#x\n", alias_id);
>  
>      for ( bdf = first_bdf; bdf <= last_bdf; bdf++ )
>          add_ivrs_mapping_entry(bdf, alias_id, 
> range->alias.header.data_setting,
> @@ -574,7 +574,7 @@ static u16 __init parse_ivhd_device_exte
>      bdf = ext->header.id;
>      if ( bdf >= ivrs_bdf_entries )
>      {
> -        AMD_IOMMU_DEBUG("IVHD Error: Invalid Device_Entry Dev_Id 0x%x\n", 
> bdf);
> +        AMD_IOMMU_DEBUG("IVHD Error: Invalid Device_Entry Dev_Id %#x\n", 
> bdf);
>          return 0;
>      }
>  
> @@ -599,7 +599,7 @@ static u16 __init parse_ivhd_device_exte
>      if ( range->end.header.type != ACPI_IVRS_TYPE_END )
>      {
>          AMD_IOMMU_DEBUG("IVHD Error: "
> -                        "Invalid Range: End_Type 0x%x\n",
> +                        "Invalid Range: End_Type %#x\n",
>                          range->end.header.type);
>          return 0;
>      }
> @@ -608,7 +608,7 @@ static u16 __init parse_ivhd_device_exte
>      if ( first_bdf >= ivrs_bdf_entries )
>      {
>          AMD_IOMMU_DEBUG("IVHD Error: "
> -                        "Invalid Range: First Dev_Id 0x%x\n", first_bdf);
> +                        "Invalid Range: First Dev_Id %#x\n", first_bdf);
>          return 0;
>      }
>  
> @@ -616,11 +616,11 @@ static u16 __init parse_ivhd_device_exte
>      if ( (last_bdf >= ivrs_bdf_entries) || (last_bdf <= first_bdf) )
>      {
>          AMD_IOMMU_DEBUG("IVHD Error: "
> -                        "Invalid Range: Last Dev_Id 0x%x\n", last_bdf);
> +                        "Invalid Range: Last Dev_Id %#x\n", last_bdf);
>          return 0;
>      }
>  
> -    AMD_IOMMU_DEBUG(" Dev_Id Range: 0x%x -> 0x%x\n",
> +    AMD_IOMMU_DEBUG(" Dev_Id Range: %#x -> %#x\n",
>                      first_bdf, last_bdf);
>  
>      for ( bdf = first_bdf; bdf <= last_bdf; bdf++ )
> @@ -646,7 +646,7 @@ static u16 __init parse_ivhd_device_spec
>      bdf = special->used_id;
>      if ( bdf >= ivrs_bdf_entries )
>      {
> -        AMD_IOMMU_DEBUG("IVHD Error: Invalid Device_Entry Dev_Id 0x%x\n", 
> bdf);
> +        AMD_IOMMU_DEBUG("IVHD Error: Invalid Device_Entry Dev_Id %#x\n", 
> bdf);
>          return 0;
>      }
>  
> @@ -673,7 +673,7 @@ static int __init parse_ivhd_block(const
>                                      ivhd_block->capability_offset);
>      if ( !iommu )
>      {
> -        AMD_IOMMU_DEBUG("IVHD Error: No IOMMU for Dev_Id 0x%x  Cap 0x%x\n",
> +        AMD_IOMMU_DEBUG("IVHD Error: No IOMMU for Dev_Id %#x Cap %#x\n",
>                          ivhd_block->header.device_id,
>                          ivhd_block->capability_offset);
>          return -ENODEV;
> @@ -687,9 +687,9 @@ static int __init parse_ivhd_block(const
>          ivhd_device = (const void *)((const u8 *)ivhd_block + block_length);
>  
>          AMD_IOMMU_DEBUG( "IVHD Device Entry:\n");
> -        AMD_IOMMU_DEBUG( " Type 0x%x\n", ivhd_device->header.type);
> -        AMD_IOMMU_DEBUG( " Dev_Id 0x%x\n", ivhd_device->header.id);
> -        AMD_IOMMU_DEBUG( " Flags 0x%x\n", ivhd_device->header.data_setting);
> +        AMD_IOMMU_DEBUG( " Type %#x\n", ivhd_device->header.type);
> +        AMD_IOMMU_DEBUG( " Dev_Id %#x\n", ivhd_device->header.id);
> +        AMD_IOMMU_DEBUG( " Flags %#x\n", ivhd_device->header.data_setting);
>  
>          switch ( ivhd_device->header.type )
>          {
> @@ -788,9 +788,9 @@ static void __init dump_acpi_table_heade
>          printk("%c", table->signature[i]);
>      printk("\n");
>  
> -    AMD_IOMMU_DEBUG(" Length 0x%x\n", table->length);
> -    AMD_IOMMU_DEBUG(" Revision 0x%x\n", table->revision);
> -    AMD_IOMMU_DEBUG(" CheckSum 0x%x\n", table->checksum);
> +    AMD_IOMMU_DEBUG(" Length %#x\n", table->length);
> +    AMD_IOMMU_DEBUG(" Revision %#x\n", table->revision);
> +    AMD_IOMMU_DEBUG(" CheckSum %#x\n", table->checksum);
>  
>      AMD_IOMMU_DEBUG(" OEM_Id ");
>      for ( i = 0; i < ACPI_OEM_ID_SIZE; i++ )
> @@ -802,14 +802,14 @@ static void __init dump_acpi_table_heade
>          printk("%c", table->oem_table_id[i]);
>      printk("\n");
>  
> -    AMD_IOMMU_DEBUG(" OEM_Revision 0x%x\n", table->oem_revision);
> +    AMD_IOMMU_DEBUG(" OEM_Revision %#x\n", table->oem_revision);
>  
>      AMD_IOMMU_DEBUG(" Creator_Id ");
>      for ( i = 0; i < ACPI_NAME_SIZE; i++ )
>          printk("%c", table->asl_compiler_id[i]);
>      printk("\n");
>  
> -    AMD_IOMMU_DEBUG(" Creator_Revision 0x%x\n",
> +    AMD_IOMMU_DEBUG(" Creator_Revision %#x\n",
>                      table->asl_compiler_revision);
>  
>  }
> @@ -832,15 +832,15 @@ static int __init parse_ivrs_table(struc
>          ivrs_block = (struct acpi_ivrs_header *)((u8 *)table + length);
>  
>          AMD_IOMMU_DEBUG("IVRS Block:\n");
> -        AMD_IOMMU_DEBUG(" Type 0x%x\n", ivrs_block->type);
> -        AMD_IOMMU_DEBUG(" Flags 0x%x\n", ivrs_block->flags);
> -        AMD_IOMMU_DEBUG(" Length 0x%x\n", ivrs_block->length);
> -        AMD_IOMMU_DEBUG(" Dev_Id 0x%x\n", ivrs_block->device_id);
> +        AMD_IOMMU_DEBUG(" Type %#x\n", ivrs_block->type);
> +        AMD_IOMMU_DEBUG(" Flags %#x\n", ivrs_block->flags);
> +        AMD_IOMMU_DEBUG(" Length %#x\n", ivrs_block->length);
> +        AMD_IOMMU_DEBUG(" Dev_Id %#x\n", ivrs_block->device_id);
>  
>          if ( table->length < (length + ivrs_block->length) )
>          {
>              AMD_IOMMU_DEBUG("IVRS Error: "
> -                            "Table Length Exceeded: 0x%x -> 0x%lx\n",
> +                            "Table Length Exceeded: %#x -> %#lx\n",
>                              table->length,
>                              (length + ivrs_block->length));
>              return -ENODEV;
> @@ -867,7 +867,7 @@ static int __init detect_iommu_acpi(stru
>          checksum += raw_table[i];
>      if ( checksum )
>      {
> -        AMD_IOMMU_DEBUG("IVRS Error: Invalid Checksum 0x%x\n", checksum);
> +        AMD_IOMMU_DEBUG("IVRS Error: Invalid Checksum %#x\n", checksum);
>          return -ENODEV;
>      }
>  
> --- 2012-09-21.orig/xen/drivers/passthrough/amd/iommu_init.c 2012-09-17 
> 09:57:54.000000000 +0200
> +++ 2012-09-21/xen/drivers/passthrough/amd/iommu_init.c 2012-09-21 
> 10:54:46.000000000 +0200
> @@ -616,8 +616,8 @@ static void parse_event_log_entry(struct
>                                         IOMMU_EVENT_FLAGS_SHIFT);
>          addr= (u64*) (entry + 2);
>          printk(XENLOG_ERR "AMD-Vi: "
> -               "%s: domain = %d, device id = 0x%04x, "
> -               "fault address = 0x%"PRIx64", flags = 0x%03x\n",
> +               "%s: domain = %d, device id = %#x, "
> +               "fault address = %#"PRIx64", flags = %#x\n",
>                 event_str[code-1], domain_id, device_id, *addr, flags);
>  
>          /* Tell the device to stop DMAing; we can't rely on the guest to
> --- 2012-09-21.orig/xen/drivers/passthrough/amd/iommu_map.c 2012-09-14 
> 13:26:34.000000000 +0200
> +++ 2012-09-21/xen/drivers/passthrough/amd/iommu_map.c 2012-09-21 
> 10:54:46.000000000 +0200
> @@ -795,7 +795,7 @@ void amd_iommu_share_p2m(struct domain *
>  
>          /* When sharing p2m with iommu, paging mode = 4 */
>          hd->paging_mode = IOMMU_PAGING_MODE_LEVEL_4;
> -        AMD_IOMMU_DEBUG("Share p2m table with iommu: p2m table = 0x%lx\n",
> +        AMD_IOMMU_DEBUG("Share p2m table with iommu: p2m table = %#lx\n",
>                          mfn_x(pgd_mfn));
>      }
>  }
> --- 2012-09-21.orig/xen/drivers/passthrough/amd/pci_amd_iommu.c 2012-09-14 
> 13:26:34.000000000 +0200
> +++ 2012-09-21/xen/drivers/passthrough/amd/pci_amd_iommu.c 2012-09-21 
> 10:54:46.000000000 +0200
> @@ -121,8 +121,8 @@ static void amd_iommu_setup_domain_devic
>  
>          amd_iommu_flush_device(iommu, req_id);
>  
> -        AMD_IOMMU_DEBUG("Setup I/O page table: device id = 0x%04x, "
> -                        "root table = 0x%"PRIx64", "
> +        AMD_IOMMU_DEBUG("Setup I/O page table: device id = %#x, "
> +                        "root table = %#"PRIx64", "
>                          "domain = %d, paging mode = %d\n", req_id,
>                          page_to_maddr(hd->root_table),
>                          hd->domain_id, hd->paging_mode);
> @@ -314,7 +314,7 @@ void amd_iommu_disable_domain_device(str
>  
>          amd_iommu_flush_device(iommu, req_id);
>  
> -        AMD_IOMMU_DEBUG("Disable: device id = 0x%04x, "
> +        AMD_IOMMU_DEBUG("Disable: device id = %#x, "
>                          "domain = %d, paging mode = %d\n",
>                          req_id,  domain_hvm_iommu(domain)->domain_id,
>                          domain_hvm_iommu(domain)->paging_mode);
> --- 2012-09-21.orig/xen/drivers/passthrough/vtd/dmar.c 2012-09-14 
> 13:26:34.000000000 +0200
> +++ 2012-09-21/xen/drivers/passthrough/vtd/dmar.c 2012-09-21 
> 10:54:46.000000000 +0200
> @@ -381,7 +381,7 @@ static int __init acpi_dmar_check_length
>      if ( h->length >= min_len )
>          return 0;
>      dprintk(XENLOG_ERR VTDPREFIX,
> -            "Invalid ACPI DMAR entry length: 0x%x\n",
> +            "Invalid ACPI DMAR entry length: %#x\n",
>              h->length);
>      return -EINVAL;
>  }
> @@ -749,7 +749,7 @@ static int __init acpi_parse_dmar(struct
>              break;
>          default:
>              dprintk(XENLOG_WARNING VTDPREFIX,
> -                    "Ignore unknown DMAR structure type (0x%x)\n",
> +                    "Ignore unknown DMAR structure type (%#x)\n",
>                      entry_header->type);
>              break;
>          }
> --- 2012-09-21.orig/xen/drivers/passthrough/vtd/intremap.c 2012-09-14 
> 13:26:34.000000000 +0200
> +++ 2012-09-21/xen/drivers/passthrough/vtd/intremap.c 2012-09-21 
> 10:54:46.000000000 +0200
> @@ -135,7 +135,7 @@ int iommu_supports_eim(void)
>          if ( !ioapic_to_drhd(IO_APIC_ID(apic)) )
>      {
>              dprintk(XENLOG_WARNING VTDPREFIX,
> -                    "There is not a DRHD for IOAPIC 0x%x (id: 0x%x)!\n",
> +                    "There is not a DRHD for IOAPIC %#x (id: %#x)!\n",
>                      apic, IO_APIC_ID(apic));
>              return 0;
>      }
> --- 2012-09-21.orig/xen/drivers/passthrough/vtd/iommu.c 2012-09-17 
> 09:57:55.000000000 +0200
> +++ 2012-09-21/xen/drivers/passthrough/vtd/iommu.c 2012-09-21 
> 10:54:46.000000000 +0200
> @@ -2035,7 +2035,7 @@ static int init_vtd_hw(void)
>              {
>                  iommu_intremap = 0;
>                  dprintk(XENLOG_ERR VTDPREFIX,
> -                    "ioapic_to_iommu: ioapic 0x%x (id: 0x%x) is NULL! "
> +                    "ioapic_to_iommu: ioapic %#x (id: %#x) is NULL! "
>                      "Will not try to enable Interrupt Remapping.\n",
>                      apic, IO_APIC_ID(apic));
>                  break;
> --- 2012-09-21.orig/xen/drivers/passthrough/vtd/utils.c 2012-09-14 
> 13:26:34.000000000 +0200
> +++ 2012-09-21/xen/drivers/passthrough/vtd/utils.c 2012-09-21 
> 10:54:46.000000000 +0200
> @@ -217,7 +217,7 @@ static void dump_iommu_info(unsigned cha
>              struct iremap_entry *iremap_entries = NULL;
>              int print_cnt = 0;
>  
> -            printk("  Interrupt remapping table (nr_entry=0x%x. "
> +            printk("  Interrupt remapping table (nr_entry=%#x. "
>                  "Only dump P=1 entries here):\n", nr_entry);
>              printk("       SVT  SQ   SID      DST  V  AVL DLM TM RH DM "
>                     "FPD P\n");
> --- 2012-09-21.orig/xen/drivers/video/vesa.c 2012-09-14 13:26:34.000000000 
> +0200
> +++ 2012-09-21/xen/drivers/video/vesa.c 2012-09-21 10:54:46.000000000 +0200
> @@ -111,7 +111,7 @@ void __init vesa_init(void)
>  
>      vga_puts = vesa_redraw_puts;
>  
> -    printk(XENLOG_INFO "vesafb: framebuffer at 0x%x, mapped to 0x%p, "
> +    printk(XENLOG_INFO "vesafb: framebuffer at %#x, mapped to 0x%p, "
>             "using %uk, total %uk\n",
>             vlfb_info.lfb_base, lfb,
>             vram_remap >> 10, vram_total >> 10);
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Sep 21 11:40:52 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Sep 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 1TF1b4-00030D-Iw; Fri, 21 Sep 2012 11:40: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 1TF1b3-000307-8t
	for xen-devel@lists.xen.org; Fri, 21 Sep 2012 11:40:37 +0000
Received: from [85.158.143.99:38512] by server-1.bemta-4.messagelabs.com id
	A0/86-05684-4325C505; Fri, 21 Sep 2012 11:40:36 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1348227634!20023693!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTA2NjI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22290 invoked from network); 21 Sep 2012 11:40:35 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Sep 2012 11:40:35 -0000
X-IronPort-AV: E=Sophos;i="4.80,462,1344211200"; d="scan'208";a="14688231"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Sep 2012 11:40: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.279.1;
	Fri, 21 Sep 2012 12:40:34 +0100
Message-ID: <1348227633.3452.16.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Fri, 21 Sep 2012 12:40:33 +0100
In-Reply-To: <505C6B7C020000780009CF08@nat28.tlf.novell.com>
References: <505C6B7C020000780009CF08@nat28.tlf.novell.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] printk: prefer %#x et at over 0x%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 Fri, 2012-09-21 at 12:28 +0100, Jan Beulich wrote:
> --- 2012-09-21.orig/xen/arch/x86/apic.c 2012-09-17 09:57:54.000000000 +0200
> +++ 2012-09-21/xen/arch/x86/apic.c      2012-09-21 10:54:46.000000000 +0200
> @@ -689,7 +689,7 @@ void __devinit setup_local_APIC(void)
>          value = apic_read(APIC_ESR);
>          if (value != oldvalue)
>              apic_printk(APIC_VERBOSE, "ESR value before enabling "
> -                        "vector: 0x%08lx  after: 0x%08lx\n",
> +                        "vector: %#lx  after: %#lx\n",

This is dropping the 0 padding?

Perhaps deliberate, I just mention it because of my next comment...

> --- 2012-09-21.orig/xen/arch/x86/cpu/mcheck/vmce.c      2012-08-08 08:20:09.000000000 +0200
> +++ 2012-09-21/xen/arch/x86/cpu/mcheck/vmce.c   2012-09-21 10:54:46.000000000 +0200
> @@ -88,7 +88,7 @@ static int bank_mce_rdmsr(const struct v
>      case MSR_IA32_MC0_CTL:
>          /* stick all 1's to MCi_CTL */
>          *val = ~0UL;
> -        mce_printk(MCE_VERBOSE, "MCE: rdmsr MC%u_CTL 0x%"PRIx64"\n",
> +        mce_printk(MCE_VERBOSE, "MCE: rdmsr MC%u_CTL %#"PRIx64"\n",

PRIx64 is something like "016llx".

Tim pointed out to me that "%#010x" renders the number 0 as 0000000000
rather than 0x00000000 which was more likely what was desired.

This is apparently a deliberate "feature" of printf (or at least it is
standardized)

Also in the %#"PRIx64" case the width is 016 which is 2 too few once you
include the 0x.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 21 11:40:52 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Sep 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 1TF1b4-00030D-Iw; Fri, 21 Sep 2012 11:40: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 1TF1b3-000307-8t
	for xen-devel@lists.xen.org; Fri, 21 Sep 2012 11:40:37 +0000
Received: from [85.158.143.99:38512] by server-1.bemta-4.messagelabs.com id
	A0/86-05684-4325C505; Fri, 21 Sep 2012 11:40:36 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1348227634!20023693!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTA2NjI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22290 invoked from network); 21 Sep 2012 11:40:35 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Sep 2012 11:40:35 -0000
X-IronPort-AV: E=Sophos;i="4.80,462,1344211200"; d="scan'208";a="14688231"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Sep 2012 11:40: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.279.1;
	Fri, 21 Sep 2012 12:40:34 +0100
Message-ID: <1348227633.3452.16.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Fri, 21 Sep 2012 12:40:33 +0100
In-Reply-To: <505C6B7C020000780009CF08@nat28.tlf.novell.com>
References: <505C6B7C020000780009CF08@nat28.tlf.novell.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] printk: prefer %#x et at over 0x%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 Fri, 2012-09-21 at 12:28 +0100, Jan Beulich wrote:
> --- 2012-09-21.orig/xen/arch/x86/apic.c 2012-09-17 09:57:54.000000000 +0200
> +++ 2012-09-21/xen/arch/x86/apic.c      2012-09-21 10:54:46.000000000 +0200
> @@ -689,7 +689,7 @@ void __devinit setup_local_APIC(void)
>          value = apic_read(APIC_ESR);
>          if (value != oldvalue)
>              apic_printk(APIC_VERBOSE, "ESR value before enabling "
> -                        "vector: 0x%08lx  after: 0x%08lx\n",
> +                        "vector: %#lx  after: %#lx\n",

This is dropping the 0 padding?

Perhaps deliberate, I just mention it because of my next comment...

> --- 2012-09-21.orig/xen/arch/x86/cpu/mcheck/vmce.c      2012-08-08 08:20:09.000000000 +0200
> +++ 2012-09-21/xen/arch/x86/cpu/mcheck/vmce.c   2012-09-21 10:54:46.000000000 +0200
> @@ -88,7 +88,7 @@ static int bank_mce_rdmsr(const struct v
>      case MSR_IA32_MC0_CTL:
>          /* stick all 1's to MCi_CTL */
>          *val = ~0UL;
> -        mce_printk(MCE_VERBOSE, "MCE: rdmsr MC%u_CTL 0x%"PRIx64"\n",
> +        mce_printk(MCE_VERBOSE, "MCE: rdmsr MC%u_CTL %#"PRIx64"\n",

PRIx64 is something like "016llx".

Tim pointed out to me that "%#010x" renders the number 0 as 0000000000
rather than 0x00000000 which was more likely what was desired.

This is apparently a deliberate "feature" of printf (or at least it is
standardized)

Also in the %#"PRIx64" case the width is 016 which is 2 too few once you
include the 0x.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 21 11:41:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Sep 2012 11:41: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 1TF1bU-00033G-Vz; Fri, 21 Sep 2012 11:41:04 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1TF1bT-00032y-G5
	for xen-devel@lists.xen.org; Fri, 21 Sep 2012 11:41:03 +0000
Received: from [85.158.139.211:33406] by server-13.bemta-5.messagelabs.com id
	1A/CE-23645-E425C505; Fri, 21 Sep 2012 11:41:02 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-12.tower-206.messagelabs.com!1348227660!18453167!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4760 invoked from network); 21 Sep 2012 11:41:01 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-12.tower-206.messagelabs.com with SMTP;
	21 Sep 2012 11:41:01 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 21 Sep 2012 12:41:00 +0100
Message-Id: <505C6E68020000780009CF34@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 21 Sep 2012 12:40:56 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part6E5F6F58.0__="
Subject: [Xen-devel] [PATCH] x86: enable VIA CPU 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

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.

--=__Part6E5F6F58.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Newer VIA CPUs have both 64-bit and VMX support. Enable them to be
recognized for these purposes, at once stripping off any 32-bit CPU
only bits from the respective CPU support file.

This particularly implies untying the VMX =3D=3D Intel assumption in a few
places.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

---
Note that my testing of this functionality wasn't as wide as I would
have hoped it to be, since the box I was provided only survived the
first few days - meanwhile it doesn't stay up long enough to just build
hypervisor and tools. Therefore, further fixes to fully support these
CPUs may be needed as the VIA folks themselves get to test that code.

--- a/xen/arch/x86/acpi/suspend.c
+++ b/xen/arch/x86/acpi/suspend.c
@@ -32,7 +32,8 @@ void save_rest_processor_state(void)
     rdmsrl(MSR_SHADOW_GS_BASE, saved_kernel_gs_base);
     rdmsrl(MSR_CSTAR, saved_cstar);
     rdmsrl(MSR_LSTAR, saved_lstar);
-    if ( boot_cpu_data.x86_vendor =3D=3D X86_VENDOR_INTEL )
+    if ( boot_cpu_data.x86_vendor =3D=3D X86_VENDOR_INTEL ||
+         boot_cpu_data.x86_vendor =3D=3D X86_VENDOR_CENTAUR )
     {
         rdmsrl(MSR_IA32_SYSENTER_ESP, saved_sysenter_esp);
         rdmsrl(MSR_IA32_SYSENTER_EIP, saved_sysenter_eip);
@@ -59,7 +60,8 @@ void restore_rest_processor_state(void)
     wrmsrl(MSR_GS_BASE, saved_gs_base);
     wrmsrl(MSR_SHADOW_GS_BASE, saved_kernel_gs_base);
=20
-    if ( boot_cpu_data.x86_vendor =3D=3D X86_VENDOR_INTEL )
+    if ( boot_cpu_data.x86_vendor =3D=3D X86_VENDOR_INTEL ||
+         boot_cpu_data.x86_vendor =3D=3D X86_VENDOR_CENTAUR )
     {
         /* Recover sysenter MSRs */
         wrmsrl(MSR_IA32_SYSENTER_ESP, saved_sysenter_esp);
--- a/xen/arch/x86/cpu/Makefile
+++ b/xen/arch/x86/cpu/Makefile
@@ -2,10 +2,8 @@ subdir-y +=3D mcheck
 subdir-y +=3D mtrr
=20
 obj-y +=3D amd.o
+obj-y +=3D centaur.o
 obj-y +=3D common.o
 obj-y +=3D intel.o
 obj-y +=3D intel_cacheinfo.o
 obj-y +=3D mwait-idle.o
-
-# Keeping around for VIA support (JBeulich)
-# obj-$(x86_32) +=3D centaur.o
--- a/xen/arch/x86/cpu/centaur.c
+++ b/xen/arch/x86/cpu/centaur.c
@@ -45,51 +45,25 @@ static void __init init_c3(struct cpuinf
 		c->x86_capability[5] =3D cpuid_edx(0xC0000001);
 	}
=20
-	/* Cyrix III family needs CX8 & PGE explicity enabled. */
-	if (c->x86_model >=3D6 && c->x86_model <=3D 9) {
-		rdmsrl(MSR_VIA_FCR, msr_content);
-		wrmsrl(MSR_VIA_FCR, msr_content | (1ULL << 1 | 1ULL << =
7));
-		set_bit(X86_FEATURE_CX8, c->x86_capability);
+	if (c->x86 =3D=3D 0x6 && c->x86_model >=3D 0xf) {
+		c->x86_cache_alignment =3D c->x86_clflush_size * 2;
+		set_bit(X86_FEATURE_CONSTANT_TSC, c->x86_capability);
 	}
=20
-	/* Before Nehemiah, the C3's had 3dNOW! */
-	if (c->x86_model >=3D6 && c->x86_model <9)
-		set_bit(X86_FEATURE_3DNOW, c->x86_capability);
-
 	get_model_name(c);
 	display_cacheinfo(c);
 }
=20
 static void __init init_centaur(struct cpuinfo_x86 *c)
 {
-	/* Bit 31 in normal CPUID used for nonstandard 3DNow ID;
-	   3DNow is IDd by bit 31 in extended CPUID (1*32+31) anyway */
-	clear_bit(0*32+31, c->x86_capability);
-
 	if (c->x86 =3D=3D 6)
 		init_c3(c);
 }
=20
-static unsigned int centaur_size_cache(struct cpuinfo_x86 * c, unsigned =
int size)
-{
-	/* VIA C3 CPUs (670-68F) need further shifting. */
-	if ((c->x86 =3D=3D 6) && ((c->x86_model =3D=3D 7) || (c->x86_model =
=3D=3D 8)))
-		size >>=3D 8;
-
-	/* VIA also screwed up Nehemiah stepping 1, and made
-	   it return '65KB' instead of '64KB'
-	   - Note, it seems this may only be in engineering samples. */
-	if ((c->x86=3D=3D6) && (c->x86_model=3D=3D9) && (c->x86_mask=3D=3D1=
) && (size=3D=3D65))
-		size -=3D1;
-
-	return size;
-}
-
 static struct cpu_dev centaur_cpu_dev __cpuinitdata =3D {
 	.c_vendor	=3D "Centaur",
 	.c_ident	=3D { "CentaurHauls" },
 	.c_init		=3D init_centaur,
-	.c_size_cache	=3D centaur_size_cache,
 };
=20
 int __init centaur_init_cpu(void)
@@ -97,5 +71,3 @@ int __init centaur_init_cpu(void)
 	cpu_devs[X86_VENDOR_CENTAUR] =3D &centaur_cpu_dev;
 	return 0;
 }
-
-//early_arch_initcall(centaur_init_cpu);
--- a/xen/arch/x86/cpu/common.c
+++ b/xen/arch/x86/cpu/common.c
@@ -567,6 +567,7 @@ void __init early_cpu_init(void)
 {
 	intel_cpu_init();
 	amd_init_cpu();
+	centaur_init_cpu();
 	early_cpu_detect();
 }
 /*
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -114,6 +114,7 @@ static int __init hvm_enable(void)
     switch ( boot_cpu_data.x86_vendor )
     {
     case X86_VENDOR_INTEL:
+    case X86_VENDOR_CENTAUR:
         fns =3D start_vmx();
         break;
     case X86_VENDOR_AMD:
--- a/xen/arch/x86/hvm/nestedhvm.c
+++ b/xen/arch/x86/hvm/nestedhvm.c
@@ -151,13 +151,15 @@ nestedhvm_is_n2(struct vcpu *v)
 static int __init
 nestedhvm_setup(void)
 {
-    /* Same format and size as hvm_io_bitmap (Intel needs only 2 pages). =
*/
-    unsigned int nr =3D (boot_cpu_data.x86_vendor =3D=3D X86_VENDOR_INTEL)=
 ? 2 : 3;
-    unsigned int i, order =3D get_order_from_pages(nr);
+    unsigned int i, nr, order;
=20
     if ( !hvm_funcs.name )
         return 0;
=20
+    /* Same format and size as hvm_io_bitmap (VMX needs only 2 pages). */
+    nr =3D !strcmp(hvm_funcs.name, "VMX") ? 2 : 3;
+    order =3D get_order_from_pages(nr);
+
     /* shadow_io_bitmaps can't be declared static because
      *   they must fulfill hw requirements (page aligned section)
      *   and doing so triggers the ASSERT(va >=3D XEN_VIRT_START)
--- a/xen/arch/x86/hvm/viridian.c
+++ b/xen/arch/x86/hvm/viridian.c
@@ -156,8 +156,7 @@ static void enable_hypercall_page(struct
     *(u32 *)(p + 1) =3D 0x80000000;
     *(u8  *)(p + 5) =3D 0x0f; /* vmcall/vmmcall */
     *(u8  *)(p + 6) =3D 0x01;
-    *(u8  *)(p + 7) =3D ((boot_cpu_data.x86_vendor =3D=3D X86_VENDOR_INTEL=
)
-                       ? 0xc1 : 0xd9);
+    *(u8  *)(p + 7) =3D (!strcmp(hvm_funcs.name, "VMX") ? 0xc1 : 0xd9);
     *(u8  *)(p + 8) =3D 0xc3; /* ret */
     memset(p + 9, 0xcc, PAGE_SIZE - 9); /* int3, int3, ... */
=20
--- a/xen/arch/x86/mm/mem_event.c
+++ b/xen/arch/x86/mm/mem_event.c
@@ -608,7 +608,7 @@ int mem_event_domctl(struct domain *d, x
                 break;
=20
             /* Currently only EPT is supported */
-            if ( boot_cpu_data.x86_vendor !=3D X86_VENDOR_INTEL )
+            if ( strcmp(hvm_funcs.name, "VMX") )
                 break;
=20
             rc =3D mem_event_enable(d, mec, med, _VPF_mem_access,=20
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -83,7 +83,7 @@ static void p2m_initialise(struct domain
=20
     p2m->cr3 =3D CR3_EADDR;
=20
-    if ( hap_enabled(d) && (boot_cpu_data.x86_vendor =3D=3D X86_VENDOR_INT=
EL) )
+    if ( hap_enabled(d) && !strcmp(hvm_funcs.name, "VMX") )
         ept_p2m_init(p2m);
     else
         p2m_pt_init(p2m);
--- a/xen/arch/x86/x86_64/traps.c
+++ b/xen/arch/x86/x86_64/traps.c
@@ -399,7 +399,8 @@ void __devinit subarch_percpu_traps_init
     wrmsrl(MSR_LSTAR, (unsigned long)stack);
     stack +=3D write_stack_trampoline(stack, stack_bottom, FLAT_KERNEL_CS6=
4);
=20
-    if ( boot_cpu_data.x86_vendor =3D=3D X86_VENDOR_INTEL )
+    if ( boot_cpu_data.x86_vendor =3D=3D X86_VENDOR_INTEL ||
+         boot_cpu_data.x86_vendor =3D=3D X86_VENDOR_CENTAUR )
     {
         /* SYSENTER entry. */
         wrmsrl(MSR_IA32_SYSENTER_ESP, (unsigned long)stack_bottom);



--=__Part6E5F6F58.0__=
Content-Type: text/plain; name="x86-Centaur.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="x86-Centaur.patch"

x86: enable VIA CPU support=0A=0ANewer VIA CPUs have both 64-bit and VMX =
support. Enable them to be=0Arecognized for these purposes, at once =
stripping off any 32-bit CPU=0Aonly bits from the respective CPU support =
file.=0A=0AThis particularly implies untying the VMX =3D=3D Intel =
assumption in a few=0Aplaces.=0A=0ASigned-off-by: Jan Beulich <jbeulich@sus=
e.com>=0A=0A---=0ANote that my testing of this functionality wasn't as =
wide as I would=0Ahave hoped it to be, since the box I was provided only =
survived the=0Afirst few days - meanwhile it doesn't stay up long enough =
to just build=0Ahypervisor and tools. Therefore, further fixes to fully =
support these=0ACPUs may be needed as the VIA folks themselves get to test =
that code.=0A=0A--- a/xen/arch/x86/acpi/suspend.c=0A+++ b/xen/arch/x86/acpi=
/suspend.c=0A@@ -32,7 +32,8 @@ void save_rest_processor_state(void)=0A     =
rdmsrl(MSR_SHADOW_GS_BASE, saved_kernel_gs_base);=0A     rdmsrl(MSR_CSTAR, =
saved_cstar);=0A     rdmsrl(MSR_LSTAR, saved_lstar);=0A-    if ( boot_cpu_d=
ata.x86_vendor =3D=3D X86_VENDOR_INTEL )=0A+    if ( boot_cpu_data.x86_vend=
or =3D=3D X86_VENDOR_INTEL ||=0A+         boot_cpu_data.x86_vendor =3D=3D =
X86_VENDOR_CENTAUR )=0A     {=0A         rdmsrl(MSR_IA32_SYSENTER_ESP, =
saved_sysenter_esp);=0A         rdmsrl(MSR_IA32_SYSENTER_EIP, saved_sysente=
r_eip);=0A@@ -59,7 +60,8 @@ void restore_rest_processor_state(void)=0A     =
wrmsrl(MSR_GS_BASE, saved_gs_base);=0A     wrmsrl(MSR_SHADOW_GS_BASE, =
saved_kernel_gs_base);=0A =0A-    if ( boot_cpu_data.x86_vendor =3D=3D =
X86_VENDOR_INTEL )=0A+    if ( boot_cpu_data.x86_vendor =3D=3D X86_VENDOR_I=
NTEL ||=0A+         boot_cpu_data.x86_vendor =3D=3D X86_VENDOR_CENTAUR =
)=0A     {=0A         /* Recover sysenter MSRs */=0A         wrmsrl(MSR_IA3=
2_SYSENTER_ESP, saved_sysenter_esp);=0A--- a/xen/arch/x86/cpu/Makefile=0A++=
+ b/xen/arch/x86/cpu/Makefile=0A@@ -2,10 +2,8 @@ subdir-y +=3D mcheck=0A =
subdir-y +=3D mtrr=0A =0A obj-y +=3D amd.o=0A+obj-y +=3D centaur.o=0A =
obj-y +=3D common.o=0A obj-y +=3D intel.o=0A obj-y +=3D intel_cacheinfo.o=
=0A obj-y +=3D mwait-idle.o=0A-=0A-# Keeping around for VIA support =
(JBeulich)=0A-# obj-$(x86_32) +=3D centaur.o=0A--- a/xen/arch/x86/cpu/centa=
ur.c=0A+++ b/xen/arch/x86/cpu/centaur.c=0A@@ -45,51 +45,25 @@ static void =
__init init_c3(struct cpuinf=0A 		c->x86_capability[5] =3D =
cpuid_edx(0xC0000001);=0A 	}=0A =0A-	/* Cyrix III family needs =
CX8 & PGE explicity enabled. */=0A-	if (c->x86_model >=3D6 && =
c->x86_model <=3D 9) {=0A-		rdmsrl(MSR_VIA_FCR, msr_content);=
=0A-		wrmsrl(MSR_VIA_FCR, msr_content | (1ULL << 1 | 1ULL << =
7));=0A-		set_bit(X86_FEATURE_CX8, c->x86_capability);=0A+	=
if (c->x86 =3D=3D 0x6 && c->x86_model >=3D 0xf) {=0A+		c->x86_cach=
e_alignment =3D c->x86_clflush_size * 2;=0A+		set_bit(X86_FEATURE=
_CONSTANT_TSC, c->x86_capability);=0A 	}=0A =0A-	/* Before =
Nehemiah, the C3's had 3dNOW! */=0A-	if (c->x86_model >=3D6 && =
c->x86_model <9)=0A-		set_bit(X86_FEATURE_3DNOW, c->x86_capabilit=
y);=0A-=0A 	get_model_name(c);=0A 	display_cacheinfo(c);=0A }=0A =0A =
static void __init init_centaur(struct cpuinfo_x86 *c)=0A {=0A-	/* Bit 31 =
in normal CPUID used for nonstandard 3DNow ID;=0A-	   3DNow is IDd by =
bit 31 in extended CPUID (1*32+31) anyway */=0A-	clear_bit(0*32+31, =
c->x86_capability);=0A-=0A 	if (c->x86 =3D=3D 6)=0A 		=
init_c3(c);=0A }=0A =0A-static unsigned int centaur_size_cache(struct =
cpuinfo_x86 * c, unsigned int size)=0A-{=0A-	/* VIA C3 CPUs (670-68F) =
need further shifting. */=0A-	if ((c->x86 =3D=3D 6) && ((c->x86_model =
=3D=3D 7) || (c->x86_model =3D=3D 8)))=0A-		size >>=3D =
8;=0A-=0A-	/* VIA also screwed up Nehemiah stepping 1, and made=0A-	=
   it return '65KB' instead of '64KB'=0A-	   - Note, it seems this =
may only be in engineering samples. */=0A-	if ((c->x86=3D=3D6) && =
(c->x86_model=3D=3D9) && (c->x86_mask=3D=3D1) && (size=3D=3D65))=0A-		=
size -=3D1;=0A-=0A-	return size;=0A-}=0A-=0A static struct cpu_dev =
centaur_cpu_dev __cpuinitdata =3D {=0A 	.c_vendor	=3D "Centaur",=0A 	=
.c_ident	=3D { "CentaurHauls" },=0A 	.c_init		=3D =
init_centaur,=0A-	.c_size_cache	=3D centaur_size_cache,=0A };=0A =
=0A int __init centaur_init_cpu(void)=0A@@ -97,5 +71,3 @@ int __init =
centaur_init_cpu(void)=0A 	cpu_devs[X86_VENDOR_CENTAUR] =3D &centaur_c=
pu_dev;=0A 	return 0;=0A }=0A-=0A-//early_arch_initcall(centaur_init_cp=
u);=0A--- a/xen/arch/x86/cpu/common.c=0A+++ b/xen/arch/x86/cpu/common.c=0A@=
@ -567,6 +567,7 @@ void __init early_cpu_init(void)=0A {=0A 	intel_cpu_i=
nit();=0A 	amd_init_cpu();=0A+	centaur_init_cpu();=0A 	early_cpu_d=
etect();=0A }=0A /*=0A--- a/xen/arch/x86/hvm/hvm.c=0A+++ b/xen/arch/x86/hvm=
/hvm.c=0A@@ -114,6 +114,7 @@ static int __init hvm_enable(void)=0A     =
switch ( boot_cpu_data.x86_vendor )=0A     {=0A     case X86_VENDOR_INTEL:=
=0A+    case X86_VENDOR_CENTAUR:=0A         fns =3D start_vmx();=0A        =
 break;=0A     case X86_VENDOR_AMD:=0A--- a/xen/arch/x86/hvm/nestedhvm.c=0A=
+++ b/xen/arch/x86/hvm/nestedhvm.c=0A@@ -151,13 +151,15 @@ nestedhvm_is_n2(=
struct vcpu *v)=0A static int __init=0A nestedhvm_setup(void)=0A {=0A-    =
/* Same format and size as hvm_io_bitmap (Intel needs only 2 pages). =
*/=0A-    unsigned int nr =3D (boot_cpu_data.x86_vendor =3D=3D X86_VENDOR_I=
NTEL) ? 2 : 3;=0A-    unsigned int i, order =3D get_order_from_pages(nr);=
=0A+    unsigned int i, nr, order;=0A =0A     if ( !hvm_funcs.name )=0A    =
     return 0;=0A =0A+    /* Same format and size as hvm_io_bitmap (VMX =
needs only 2 pages). */=0A+    nr =3D !strcmp(hvm_funcs.name, "VMX") ? 2 : =
3;=0A+    order =3D get_order_from_pages(nr);=0A+=0A     /* shadow_io_bitma=
ps can't be declared static because=0A      *   they must fulfill hw =
requirements (page aligned section)=0A      *   and doing so triggers the =
ASSERT(va >=3D XEN_VIRT_START)=0A--- a/xen/arch/x86/hvm/viridian.c=0A+++ =
b/xen/arch/x86/hvm/viridian.c=0A@@ -156,8 +156,7 @@ static void enable_hype=
rcall_page(struct=0A     *(u32 *)(p + 1) =3D 0x80000000;=0A     *(u8  *)(p =
+ 5) =3D 0x0f; /* vmcall/vmmcall */=0A     *(u8  *)(p + 6) =3D 0x01;=0A-   =
 *(u8  *)(p + 7) =3D ((boot_cpu_data.x86_vendor =3D=3D X86_VENDOR_INTEL)=0A=
-                       ? 0xc1 : 0xd9);=0A+    *(u8  *)(p + 7) =3D =
(!strcmp(hvm_funcs.name, "VMX") ? 0xc1 : 0xd9);=0A     *(u8  *)(p + 8) =3D =
0xc3; /* ret */=0A     memset(p + 9, 0xcc, PAGE_SIZE - 9); /* int3, int3, =
... */=0A =0A--- a/xen/arch/x86/mm/mem_event.c=0A+++ b/xen/arch/x86/mm/mem_=
event.c=0A@@ -608,7 +608,7 @@ int mem_event_domctl(struct domain *d, x=0A  =
               break;=0A =0A             /* Currently only EPT is =
supported */=0A-            if ( boot_cpu_data.x86_vendor !=3D X86_VENDOR_I=
NTEL )=0A+            if ( strcmp(hvm_funcs.name, "VMX") )=0A              =
   break;=0A =0A             rc =3D mem_event_enable(d, mec, med, =
_VPF_mem_access, =0A--- a/xen/arch/x86/mm/p2m.c=0A+++ b/xen/arch/x86/mm/p2m=
.c=0A@@ -83,7 +83,7 @@ static void p2m_initialise(struct domain=0A =0A     =
p2m->cr3 =3D CR3_EADDR;=0A =0A-    if ( hap_enabled(d) && (boot_cpu_data.x8=
6_vendor =3D=3D X86_VENDOR_INTEL) )=0A+    if ( hap_enabled(d) && =
!strcmp(hvm_funcs.name, "VMX") )=0A         ept_p2m_init(p2m);=0A     =
else=0A         p2m_pt_init(p2m);=0A--- a/xen/arch/x86/x86_64/traps.c=0A+++=
 b/xen/arch/x86/x86_64/traps.c=0A@@ -399,7 +399,8 @@ void __devinit =
subarch_percpu_traps_init=0A     wrmsrl(MSR_LSTAR, (unsigned long)stack);=
=0A     stack +=3D write_stack_trampoline(stack, stack_bottom, FLAT_KERNEL_=
CS64);=0A =0A-    if ( boot_cpu_data.x86_vendor =3D=3D X86_VENDOR_INTEL =
)=0A+    if ( boot_cpu_data.x86_vendor =3D=3D X86_VENDOR_INTEL ||=0A+      =
   boot_cpu_data.x86_vendor =3D=3D X86_VENDOR_CENTAUR )=0A     {=0A        =
 /* SYSENTER entry. */=0A         wrmsrl(MSR_IA32_SYSENTER_ESP, (unsigned =
long)stack_bottom);=0A
--=__Part6E5F6F58.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

--=__Part6E5F6F58.0__=--


From xen-devel-bounces@lists.xen.org Fri Sep 21 11:41:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Sep 2012 11:41: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 1TF1bU-00033G-Vz; Fri, 21 Sep 2012 11:41:04 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1TF1bT-00032y-G5
	for xen-devel@lists.xen.org; Fri, 21 Sep 2012 11:41:03 +0000
Received: from [85.158.139.211:33406] by server-13.bemta-5.messagelabs.com id
	1A/CE-23645-E425C505; Fri, 21 Sep 2012 11:41:02 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-12.tower-206.messagelabs.com!1348227660!18453167!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4760 invoked from network); 21 Sep 2012 11:41:01 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-12.tower-206.messagelabs.com with SMTP;
	21 Sep 2012 11:41:01 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 21 Sep 2012 12:41:00 +0100
Message-Id: <505C6E68020000780009CF34@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 21 Sep 2012 12:40:56 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part6E5F6F58.0__="
Subject: [Xen-devel] [PATCH] x86: enable VIA CPU 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

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.

--=__Part6E5F6F58.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Newer VIA CPUs have both 64-bit and VMX support. Enable them to be
recognized for these purposes, at once stripping off any 32-bit CPU
only bits from the respective CPU support file.

This particularly implies untying the VMX =3D=3D Intel assumption in a few
places.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

---
Note that my testing of this functionality wasn't as wide as I would
have hoped it to be, since the box I was provided only survived the
first few days - meanwhile it doesn't stay up long enough to just build
hypervisor and tools. Therefore, further fixes to fully support these
CPUs may be needed as the VIA folks themselves get to test that code.

--- a/xen/arch/x86/acpi/suspend.c
+++ b/xen/arch/x86/acpi/suspend.c
@@ -32,7 +32,8 @@ void save_rest_processor_state(void)
     rdmsrl(MSR_SHADOW_GS_BASE, saved_kernel_gs_base);
     rdmsrl(MSR_CSTAR, saved_cstar);
     rdmsrl(MSR_LSTAR, saved_lstar);
-    if ( boot_cpu_data.x86_vendor =3D=3D X86_VENDOR_INTEL )
+    if ( boot_cpu_data.x86_vendor =3D=3D X86_VENDOR_INTEL ||
+         boot_cpu_data.x86_vendor =3D=3D X86_VENDOR_CENTAUR )
     {
         rdmsrl(MSR_IA32_SYSENTER_ESP, saved_sysenter_esp);
         rdmsrl(MSR_IA32_SYSENTER_EIP, saved_sysenter_eip);
@@ -59,7 +60,8 @@ void restore_rest_processor_state(void)
     wrmsrl(MSR_GS_BASE, saved_gs_base);
     wrmsrl(MSR_SHADOW_GS_BASE, saved_kernel_gs_base);
=20
-    if ( boot_cpu_data.x86_vendor =3D=3D X86_VENDOR_INTEL )
+    if ( boot_cpu_data.x86_vendor =3D=3D X86_VENDOR_INTEL ||
+         boot_cpu_data.x86_vendor =3D=3D X86_VENDOR_CENTAUR )
     {
         /* Recover sysenter MSRs */
         wrmsrl(MSR_IA32_SYSENTER_ESP, saved_sysenter_esp);
--- a/xen/arch/x86/cpu/Makefile
+++ b/xen/arch/x86/cpu/Makefile
@@ -2,10 +2,8 @@ subdir-y +=3D mcheck
 subdir-y +=3D mtrr
=20
 obj-y +=3D amd.o
+obj-y +=3D centaur.o
 obj-y +=3D common.o
 obj-y +=3D intel.o
 obj-y +=3D intel_cacheinfo.o
 obj-y +=3D mwait-idle.o
-
-# Keeping around for VIA support (JBeulich)
-# obj-$(x86_32) +=3D centaur.o
--- a/xen/arch/x86/cpu/centaur.c
+++ b/xen/arch/x86/cpu/centaur.c
@@ -45,51 +45,25 @@ static void __init init_c3(struct cpuinf
 		c->x86_capability[5] =3D cpuid_edx(0xC0000001);
 	}
=20
-	/* Cyrix III family needs CX8 & PGE explicity enabled. */
-	if (c->x86_model >=3D6 && c->x86_model <=3D 9) {
-		rdmsrl(MSR_VIA_FCR, msr_content);
-		wrmsrl(MSR_VIA_FCR, msr_content | (1ULL << 1 | 1ULL << =
7));
-		set_bit(X86_FEATURE_CX8, c->x86_capability);
+	if (c->x86 =3D=3D 0x6 && c->x86_model >=3D 0xf) {
+		c->x86_cache_alignment =3D c->x86_clflush_size * 2;
+		set_bit(X86_FEATURE_CONSTANT_TSC, c->x86_capability);
 	}
=20
-	/* Before Nehemiah, the C3's had 3dNOW! */
-	if (c->x86_model >=3D6 && c->x86_model <9)
-		set_bit(X86_FEATURE_3DNOW, c->x86_capability);
-
 	get_model_name(c);
 	display_cacheinfo(c);
 }
=20
 static void __init init_centaur(struct cpuinfo_x86 *c)
 {
-	/* Bit 31 in normal CPUID used for nonstandard 3DNow ID;
-	   3DNow is IDd by bit 31 in extended CPUID (1*32+31) anyway */
-	clear_bit(0*32+31, c->x86_capability);
-
 	if (c->x86 =3D=3D 6)
 		init_c3(c);
 }
=20
-static unsigned int centaur_size_cache(struct cpuinfo_x86 * c, unsigned =
int size)
-{
-	/* VIA C3 CPUs (670-68F) need further shifting. */
-	if ((c->x86 =3D=3D 6) && ((c->x86_model =3D=3D 7) || (c->x86_model =
=3D=3D 8)))
-		size >>=3D 8;
-
-	/* VIA also screwed up Nehemiah stepping 1, and made
-	   it return '65KB' instead of '64KB'
-	   - Note, it seems this may only be in engineering samples. */
-	if ((c->x86=3D=3D6) && (c->x86_model=3D=3D9) && (c->x86_mask=3D=3D1=
) && (size=3D=3D65))
-		size -=3D1;
-
-	return size;
-}
-
 static struct cpu_dev centaur_cpu_dev __cpuinitdata =3D {
 	.c_vendor	=3D "Centaur",
 	.c_ident	=3D { "CentaurHauls" },
 	.c_init		=3D init_centaur,
-	.c_size_cache	=3D centaur_size_cache,
 };
=20
 int __init centaur_init_cpu(void)
@@ -97,5 +71,3 @@ int __init centaur_init_cpu(void)
 	cpu_devs[X86_VENDOR_CENTAUR] =3D &centaur_cpu_dev;
 	return 0;
 }
-
-//early_arch_initcall(centaur_init_cpu);
--- a/xen/arch/x86/cpu/common.c
+++ b/xen/arch/x86/cpu/common.c
@@ -567,6 +567,7 @@ void __init early_cpu_init(void)
 {
 	intel_cpu_init();
 	amd_init_cpu();
+	centaur_init_cpu();
 	early_cpu_detect();
 }
 /*
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -114,6 +114,7 @@ static int __init hvm_enable(void)
     switch ( boot_cpu_data.x86_vendor )
     {
     case X86_VENDOR_INTEL:
+    case X86_VENDOR_CENTAUR:
         fns =3D start_vmx();
         break;
     case X86_VENDOR_AMD:
--- a/xen/arch/x86/hvm/nestedhvm.c
+++ b/xen/arch/x86/hvm/nestedhvm.c
@@ -151,13 +151,15 @@ nestedhvm_is_n2(struct vcpu *v)
 static int __init
 nestedhvm_setup(void)
 {
-    /* Same format and size as hvm_io_bitmap (Intel needs only 2 pages). =
*/
-    unsigned int nr =3D (boot_cpu_data.x86_vendor =3D=3D X86_VENDOR_INTEL)=
 ? 2 : 3;
-    unsigned int i, order =3D get_order_from_pages(nr);
+    unsigned int i, nr, order;
=20
     if ( !hvm_funcs.name )
         return 0;
=20
+    /* Same format and size as hvm_io_bitmap (VMX needs only 2 pages). */
+    nr =3D !strcmp(hvm_funcs.name, "VMX") ? 2 : 3;
+    order =3D get_order_from_pages(nr);
+
     /* shadow_io_bitmaps can't be declared static because
      *   they must fulfill hw requirements (page aligned section)
      *   and doing so triggers the ASSERT(va >=3D XEN_VIRT_START)
--- a/xen/arch/x86/hvm/viridian.c
+++ b/xen/arch/x86/hvm/viridian.c
@@ -156,8 +156,7 @@ static void enable_hypercall_page(struct
     *(u32 *)(p + 1) =3D 0x80000000;
     *(u8  *)(p + 5) =3D 0x0f; /* vmcall/vmmcall */
     *(u8  *)(p + 6) =3D 0x01;
-    *(u8  *)(p + 7) =3D ((boot_cpu_data.x86_vendor =3D=3D X86_VENDOR_INTEL=
)
-                       ? 0xc1 : 0xd9);
+    *(u8  *)(p + 7) =3D (!strcmp(hvm_funcs.name, "VMX") ? 0xc1 : 0xd9);
     *(u8  *)(p + 8) =3D 0xc3; /* ret */
     memset(p + 9, 0xcc, PAGE_SIZE - 9); /* int3, int3, ... */
=20
--- a/xen/arch/x86/mm/mem_event.c
+++ b/xen/arch/x86/mm/mem_event.c
@@ -608,7 +608,7 @@ int mem_event_domctl(struct domain *d, x
                 break;
=20
             /* Currently only EPT is supported */
-            if ( boot_cpu_data.x86_vendor !=3D X86_VENDOR_INTEL )
+            if ( strcmp(hvm_funcs.name, "VMX") )
                 break;
=20
             rc =3D mem_event_enable(d, mec, med, _VPF_mem_access,=20
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -83,7 +83,7 @@ static void p2m_initialise(struct domain
=20
     p2m->cr3 =3D CR3_EADDR;
=20
-    if ( hap_enabled(d) && (boot_cpu_data.x86_vendor =3D=3D X86_VENDOR_INT=
EL) )
+    if ( hap_enabled(d) && !strcmp(hvm_funcs.name, "VMX") )
         ept_p2m_init(p2m);
     else
         p2m_pt_init(p2m);
--- a/xen/arch/x86/x86_64/traps.c
+++ b/xen/arch/x86/x86_64/traps.c
@@ -399,7 +399,8 @@ void __devinit subarch_percpu_traps_init
     wrmsrl(MSR_LSTAR, (unsigned long)stack);
     stack +=3D write_stack_trampoline(stack, stack_bottom, FLAT_KERNEL_CS6=
4);
=20
-    if ( boot_cpu_data.x86_vendor =3D=3D X86_VENDOR_INTEL )
+    if ( boot_cpu_data.x86_vendor =3D=3D X86_VENDOR_INTEL ||
+         boot_cpu_data.x86_vendor =3D=3D X86_VENDOR_CENTAUR )
     {
         /* SYSENTER entry. */
         wrmsrl(MSR_IA32_SYSENTER_ESP, (unsigned long)stack_bottom);



--=__Part6E5F6F58.0__=
Content-Type: text/plain; name="x86-Centaur.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="x86-Centaur.patch"

x86: enable VIA CPU support=0A=0ANewer VIA CPUs have both 64-bit and VMX =
support. Enable them to be=0Arecognized for these purposes, at once =
stripping off any 32-bit CPU=0Aonly bits from the respective CPU support =
file.=0A=0AThis particularly implies untying the VMX =3D=3D Intel =
assumption in a few=0Aplaces.=0A=0ASigned-off-by: Jan Beulich <jbeulich@sus=
e.com>=0A=0A---=0ANote that my testing of this functionality wasn't as =
wide as I would=0Ahave hoped it to be, since the box I was provided only =
survived the=0Afirst few days - meanwhile it doesn't stay up long enough =
to just build=0Ahypervisor and tools. Therefore, further fixes to fully =
support these=0ACPUs may be needed as the VIA folks themselves get to test =
that code.=0A=0A--- a/xen/arch/x86/acpi/suspend.c=0A+++ b/xen/arch/x86/acpi=
/suspend.c=0A@@ -32,7 +32,8 @@ void save_rest_processor_state(void)=0A     =
rdmsrl(MSR_SHADOW_GS_BASE, saved_kernel_gs_base);=0A     rdmsrl(MSR_CSTAR, =
saved_cstar);=0A     rdmsrl(MSR_LSTAR, saved_lstar);=0A-    if ( boot_cpu_d=
ata.x86_vendor =3D=3D X86_VENDOR_INTEL )=0A+    if ( boot_cpu_data.x86_vend=
or =3D=3D X86_VENDOR_INTEL ||=0A+         boot_cpu_data.x86_vendor =3D=3D =
X86_VENDOR_CENTAUR )=0A     {=0A         rdmsrl(MSR_IA32_SYSENTER_ESP, =
saved_sysenter_esp);=0A         rdmsrl(MSR_IA32_SYSENTER_EIP, saved_sysente=
r_eip);=0A@@ -59,7 +60,8 @@ void restore_rest_processor_state(void)=0A     =
wrmsrl(MSR_GS_BASE, saved_gs_base);=0A     wrmsrl(MSR_SHADOW_GS_BASE, =
saved_kernel_gs_base);=0A =0A-    if ( boot_cpu_data.x86_vendor =3D=3D =
X86_VENDOR_INTEL )=0A+    if ( boot_cpu_data.x86_vendor =3D=3D X86_VENDOR_I=
NTEL ||=0A+         boot_cpu_data.x86_vendor =3D=3D X86_VENDOR_CENTAUR =
)=0A     {=0A         /* Recover sysenter MSRs */=0A         wrmsrl(MSR_IA3=
2_SYSENTER_ESP, saved_sysenter_esp);=0A--- a/xen/arch/x86/cpu/Makefile=0A++=
+ b/xen/arch/x86/cpu/Makefile=0A@@ -2,10 +2,8 @@ subdir-y +=3D mcheck=0A =
subdir-y +=3D mtrr=0A =0A obj-y +=3D amd.o=0A+obj-y +=3D centaur.o=0A =
obj-y +=3D common.o=0A obj-y +=3D intel.o=0A obj-y +=3D intel_cacheinfo.o=
=0A obj-y +=3D mwait-idle.o=0A-=0A-# Keeping around for VIA support =
(JBeulich)=0A-# obj-$(x86_32) +=3D centaur.o=0A--- a/xen/arch/x86/cpu/centa=
ur.c=0A+++ b/xen/arch/x86/cpu/centaur.c=0A@@ -45,51 +45,25 @@ static void =
__init init_c3(struct cpuinf=0A 		c->x86_capability[5] =3D =
cpuid_edx(0xC0000001);=0A 	}=0A =0A-	/* Cyrix III family needs =
CX8 & PGE explicity enabled. */=0A-	if (c->x86_model >=3D6 && =
c->x86_model <=3D 9) {=0A-		rdmsrl(MSR_VIA_FCR, msr_content);=
=0A-		wrmsrl(MSR_VIA_FCR, msr_content | (1ULL << 1 | 1ULL << =
7));=0A-		set_bit(X86_FEATURE_CX8, c->x86_capability);=0A+	=
if (c->x86 =3D=3D 0x6 && c->x86_model >=3D 0xf) {=0A+		c->x86_cach=
e_alignment =3D c->x86_clflush_size * 2;=0A+		set_bit(X86_FEATURE=
_CONSTANT_TSC, c->x86_capability);=0A 	}=0A =0A-	/* Before =
Nehemiah, the C3's had 3dNOW! */=0A-	if (c->x86_model >=3D6 && =
c->x86_model <9)=0A-		set_bit(X86_FEATURE_3DNOW, c->x86_capabilit=
y);=0A-=0A 	get_model_name(c);=0A 	display_cacheinfo(c);=0A }=0A =0A =
static void __init init_centaur(struct cpuinfo_x86 *c)=0A {=0A-	/* Bit 31 =
in normal CPUID used for nonstandard 3DNow ID;=0A-	   3DNow is IDd by =
bit 31 in extended CPUID (1*32+31) anyway */=0A-	clear_bit(0*32+31, =
c->x86_capability);=0A-=0A 	if (c->x86 =3D=3D 6)=0A 		=
init_c3(c);=0A }=0A =0A-static unsigned int centaur_size_cache(struct =
cpuinfo_x86 * c, unsigned int size)=0A-{=0A-	/* VIA C3 CPUs (670-68F) =
need further shifting. */=0A-	if ((c->x86 =3D=3D 6) && ((c->x86_model =
=3D=3D 7) || (c->x86_model =3D=3D 8)))=0A-		size >>=3D =
8;=0A-=0A-	/* VIA also screwed up Nehemiah stepping 1, and made=0A-	=
   it return '65KB' instead of '64KB'=0A-	   - Note, it seems this =
may only be in engineering samples. */=0A-	if ((c->x86=3D=3D6) && =
(c->x86_model=3D=3D9) && (c->x86_mask=3D=3D1) && (size=3D=3D65))=0A-		=
size -=3D1;=0A-=0A-	return size;=0A-}=0A-=0A static struct cpu_dev =
centaur_cpu_dev __cpuinitdata =3D {=0A 	.c_vendor	=3D "Centaur",=0A 	=
.c_ident	=3D { "CentaurHauls" },=0A 	.c_init		=3D =
init_centaur,=0A-	.c_size_cache	=3D centaur_size_cache,=0A };=0A =
=0A int __init centaur_init_cpu(void)=0A@@ -97,5 +71,3 @@ int __init =
centaur_init_cpu(void)=0A 	cpu_devs[X86_VENDOR_CENTAUR] =3D &centaur_c=
pu_dev;=0A 	return 0;=0A }=0A-=0A-//early_arch_initcall(centaur_init_cp=
u);=0A--- a/xen/arch/x86/cpu/common.c=0A+++ b/xen/arch/x86/cpu/common.c=0A@=
@ -567,6 +567,7 @@ void __init early_cpu_init(void)=0A {=0A 	intel_cpu_i=
nit();=0A 	amd_init_cpu();=0A+	centaur_init_cpu();=0A 	early_cpu_d=
etect();=0A }=0A /*=0A--- a/xen/arch/x86/hvm/hvm.c=0A+++ b/xen/arch/x86/hvm=
/hvm.c=0A@@ -114,6 +114,7 @@ static int __init hvm_enable(void)=0A     =
switch ( boot_cpu_data.x86_vendor )=0A     {=0A     case X86_VENDOR_INTEL:=
=0A+    case X86_VENDOR_CENTAUR:=0A         fns =3D start_vmx();=0A        =
 break;=0A     case X86_VENDOR_AMD:=0A--- a/xen/arch/x86/hvm/nestedhvm.c=0A=
+++ b/xen/arch/x86/hvm/nestedhvm.c=0A@@ -151,13 +151,15 @@ nestedhvm_is_n2(=
struct vcpu *v)=0A static int __init=0A nestedhvm_setup(void)=0A {=0A-    =
/* Same format and size as hvm_io_bitmap (Intel needs only 2 pages). =
*/=0A-    unsigned int nr =3D (boot_cpu_data.x86_vendor =3D=3D X86_VENDOR_I=
NTEL) ? 2 : 3;=0A-    unsigned int i, order =3D get_order_from_pages(nr);=
=0A+    unsigned int i, nr, order;=0A =0A     if ( !hvm_funcs.name )=0A    =
     return 0;=0A =0A+    /* Same format and size as hvm_io_bitmap (VMX =
needs only 2 pages). */=0A+    nr =3D !strcmp(hvm_funcs.name, "VMX") ? 2 : =
3;=0A+    order =3D get_order_from_pages(nr);=0A+=0A     /* shadow_io_bitma=
ps can't be declared static because=0A      *   they must fulfill hw =
requirements (page aligned section)=0A      *   and doing so triggers the =
ASSERT(va >=3D XEN_VIRT_START)=0A--- a/xen/arch/x86/hvm/viridian.c=0A+++ =
b/xen/arch/x86/hvm/viridian.c=0A@@ -156,8 +156,7 @@ static void enable_hype=
rcall_page(struct=0A     *(u32 *)(p + 1) =3D 0x80000000;=0A     *(u8  *)(p =
+ 5) =3D 0x0f; /* vmcall/vmmcall */=0A     *(u8  *)(p + 6) =3D 0x01;=0A-   =
 *(u8  *)(p + 7) =3D ((boot_cpu_data.x86_vendor =3D=3D X86_VENDOR_INTEL)=0A=
-                       ? 0xc1 : 0xd9);=0A+    *(u8  *)(p + 7) =3D =
(!strcmp(hvm_funcs.name, "VMX") ? 0xc1 : 0xd9);=0A     *(u8  *)(p + 8) =3D =
0xc3; /* ret */=0A     memset(p + 9, 0xcc, PAGE_SIZE - 9); /* int3, int3, =
... */=0A =0A--- a/xen/arch/x86/mm/mem_event.c=0A+++ b/xen/arch/x86/mm/mem_=
event.c=0A@@ -608,7 +608,7 @@ int mem_event_domctl(struct domain *d, x=0A  =
               break;=0A =0A             /* Currently only EPT is =
supported */=0A-            if ( boot_cpu_data.x86_vendor !=3D X86_VENDOR_I=
NTEL )=0A+            if ( strcmp(hvm_funcs.name, "VMX") )=0A              =
   break;=0A =0A             rc =3D mem_event_enable(d, mec, med, =
_VPF_mem_access, =0A--- a/xen/arch/x86/mm/p2m.c=0A+++ b/xen/arch/x86/mm/p2m=
.c=0A@@ -83,7 +83,7 @@ static void p2m_initialise(struct domain=0A =0A     =
p2m->cr3 =3D CR3_EADDR;=0A =0A-    if ( hap_enabled(d) && (boot_cpu_data.x8=
6_vendor =3D=3D X86_VENDOR_INTEL) )=0A+    if ( hap_enabled(d) && =
!strcmp(hvm_funcs.name, "VMX") )=0A         ept_p2m_init(p2m);=0A     =
else=0A         p2m_pt_init(p2m);=0A--- a/xen/arch/x86/x86_64/traps.c=0A+++=
 b/xen/arch/x86/x86_64/traps.c=0A@@ -399,7 +399,8 @@ void __devinit =
subarch_percpu_traps_init=0A     wrmsrl(MSR_LSTAR, (unsigned long)stack);=
=0A     stack +=3D write_stack_trampoline(stack, stack_bottom, FLAT_KERNEL_=
CS64);=0A =0A-    if ( boot_cpu_data.x86_vendor =3D=3D X86_VENDOR_INTEL =
)=0A+    if ( boot_cpu_data.x86_vendor =3D=3D X86_VENDOR_INTEL ||=0A+      =
   boot_cpu_data.x86_vendor =3D=3D X86_VENDOR_CENTAUR )=0A     {=0A        =
 /* SYSENTER entry. */=0A         wrmsrl(MSR_IA32_SYSENTER_ESP, (unsigned =
long)stack_bottom);=0A
--=__Part6E5F6F58.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

--=__Part6E5F6F58.0__=--


From xen-devel-bounces@lists.xen.org Fri Sep 21 11:52:25 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Sep 2012 11:52:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TF1mD-0003LS-7A; Fri, 21 Sep 2012 11:52:09 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1TF1mB-0003LN-SU
	for xen-devel@lists.xen.org; Fri, 21 Sep 2012 11:52:08 +0000
Received: from [85.158.143.99:49327] by server-2.bemta-4.messagelabs.com id
	2E/A9-06610-7E45C505; Fri, 21 Sep 2012 11:52:07 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1348228326!21474619!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9590 invoked from network); 21 Sep 2012 11:52:06 -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;
	21 Sep 2012 11:52:06 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 21 Sep 2012 12:52:06 +0100
Message-Id: <505C7102020000780009CF5B@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 21 Sep 2012 12:52:02 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Campbell" <Ian.Campbell@citrix.com>
References: <505C6B7C020000780009CF08@nat28.tlf.novell.com>
	<1348227633.3452.16.camel@zakaz.uk.xensource.com>
In-Reply-To: <1348227633.3452.16.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] printk: prefer %#x et at over 0x%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 21.09.12 at 13:40, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> On Fri, 2012-09-21 at 12:28 +0100, Jan Beulich wrote:
>> --- 2012-09-21.orig/xen/arch/x86/apic.c 2012-09-17 09:57:54.000000000 +0200
>> +++ 2012-09-21/xen/arch/x86/apic.c      2012-09-21 10:54:46.000000000 +0200
>> @@ -689,7 +689,7 @@ void __devinit setup_local_APIC(void)
>>          value = apic_read(APIC_ESR);
>>          if (value != oldvalue)
>>              apic_printk(APIC_VERBOSE, "ESR value before enabling "
>> -                        "vector: 0x%08lx  after: 0x%08lx\n",
>> +                        "vector: %#lx  after: %#lx\n",
> 
> This is dropping the 0 padding?
> 
> Perhaps deliberate, I just mention it because of my next comment...

Yes - there's no need for the full width printing here. I did take
care not to replace the format in cases where the zero-padding
would be useful.

>> --- 2012-09-21.orig/xen/arch/x86/cpu/mcheck/vmce.c      2012-08-08 08:20:09.000000000 +0200
>> +++ 2012-09-21/xen/arch/x86/cpu/mcheck/vmce.c   2012-09-21 10:54:46.000000000 +0200
>> @@ -88,7 +88,7 @@ static int bank_mce_rdmsr(const struct v
>>      case MSR_IA32_MC0_CTL:
>>          /* stick all 1's to MCi_CTL */
>>          *val = ~0UL;
>> -        mce_printk(MCE_VERBOSE, "MCE: rdmsr MC%u_CTL 0x%"PRIx64"\n",
>> +        mce_printk(MCE_VERBOSE, "MCE: rdmsr MC%u_CTL %#"PRIx64"\n",
> 
> PRIx64 is something like "016llx".

No - it's just "llx" or "lx". Are you perhaps mixing this up with
PRIpaddr?

> Tim pointed out to me that "%#010x" renders the number 0 as 0000000000
> rather than 0x00000000 which was more likely what was desired.
> 
> This is apparently a deliberate "feature" of printf (or at least it is
> standardized)
> 
> Also in the %#"PRIx64" case the width is 016 which is 2 too few once you
> include the 0x.

Indeed, that would be the case if PRIx64 was defined you thought
it would be.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 21 11:52:25 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Sep 2012 11:52:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TF1mD-0003LS-7A; Fri, 21 Sep 2012 11:52:09 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1TF1mB-0003LN-SU
	for xen-devel@lists.xen.org; Fri, 21 Sep 2012 11:52:08 +0000
Received: from [85.158.143.99:49327] by server-2.bemta-4.messagelabs.com id
	2E/A9-06610-7E45C505; Fri, 21 Sep 2012 11:52:07 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1348228326!21474619!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9590 invoked from network); 21 Sep 2012 11:52:06 -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;
	21 Sep 2012 11:52:06 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 21 Sep 2012 12:52:06 +0100
Message-Id: <505C7102020000780009CF5B@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 21 Sep 2012 12:52:02 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Campbell" <Ian.Campbell@citrix.com>
References: <505C6B7C020000780009CF08@nat28.tlf.novell.com>
	<1348227633.3452.16.camel@zakaz.uk.xensource.com>
In-Reply-To: <1348227633.3452.16.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] printk: prefer %#x et at over 0x%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 21.09.12 at 13:40, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> On Fri, 2012-09-21 at 12:28 +0100, Jan Beulich wrote:
>> --- 2012-09-21.orig/xen/arch/x86/apic.c 2012-09-17 09:57:54.000000000 +0200
>> +++ 2012-09-21/xen/arch/x86/apic.c      2012-09-21 10:54:46.000000000 +0200
>> @@ -689,7 +689,7 @@ void __devinit setup_local_APIC(void)
>>          value = apic_read(APIC_ESR);
>>          if (value != oldvalue)
>>              apic_printk(APIC_VERBOSE, "ESR value before enabling "
>> -                        "vector: 0x%08lx  after: 0x%08lx\n",
>> +                        "vector: %#lx  after: %#lx\n",
> 
> This is dropping the 0 padding?
> 
> Perhaps deliberate, I just mention it because of my next comment...

Yes - there's no need for the full width printing here. I did take
care not to replace the format in cases where the zero-padding
would be useful.

>> --- 2012-09-21.orig/xen/arch/x86/cpu/mcheck/vmce.c      2012-08-08 08:20:09.000000000 +0200
>> +++ 2012-09-21/xen/arch/x86/cpu/mcheck/vmce.c   2012-09-21 10:54:46.000000000 +0200
>> @@ -88,7 +88,7 @@ static int bank_mce_rdmsr(const struct v
>>      case MSR_IA32_MC0_CTL:
>>          /* stick all 1's to MCi_CTL */
>>          *val = ~0UL;
>> -        mce_printk(MCE_VERBOSE, "MCE: rdmsr MC%u_CTL 0x%"PRIx64"\n",
>> +        mce_printk(MCE_VERBOSE, "MCE: rdmsr MC%u_CTL %#"PRIx64"\n",
> 
> PRIx64 is something like "016llx".

No - it's just "llx" or "lx". Are you perhaps mixing this up with
PRIpaddr?

> Tim pointed out to me that "%#010x" renders the number 0 as 0000000000
> rather than 0x00000000 which was more likely what was desired.
> 
> This is apparently a deliberate "feature" of printf (or at least it is
> standardized)
> 
> Also in the %#"PRIx64" case the width is 016 which is 2 too few once you
> include the 0x.

Indeed, that would be the case if PRIx64 was defined you thought
it would be.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 21 12:00:20 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Sep 2012 12:00:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TF1to-0003Vg-CN; Fri, 21 Sep 2012 12: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 1TF1tn-0003Vb-4V
	for xen-devel@lists.xen.org; Fri, 21 Sep 2012 11:59:59 +0000
Received: from [85.158.143.35:53179] by server-3.bemta-4.messagelabs.com id
	EB/AB-10986-EB65C505; Fri, 21 Sep 2012 11:59:58 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1348228677!15801627!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19583 invoked from network); 21 Sep 2012 11:58:03 -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;
	21 Sep 2012 11:58:03 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 21 Sep 2012 12:57:58 +0100
Message-Id: <505C7262020000780009CF66@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 21 Sep 2012 12:57:54 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part60516152.0__="
Subject: [Xen-devel] [PATCH] x86: eliminate code affecting only
 64-bit-incapable CPUs
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
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.

--=__Part60516152.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/arch/x86/cpu/common.c
+++ b/xen/arch/x86/cpu/common.c
@@ -15,9 +15,6 @@
=20
 #include "cpu.h"
=20
-static int cachesize_override __cpuinitdata =3D -1;
-size_param("cachesize", cachesize_override);
-
 static bool_t __cpuinitdata use_xsave =3D 1;
 boolean_param("xsave", use_xsave);
=20
@@ -120,17 +117,6 @@ void __cpuinit display_cacheinfo(struct=20
 	ecx =3D cpuid_ecx(0x80000006);
 	l2size =3D ecx >> 16;
 =09
-	/* do processor-specific cache resizing */
-	if (this_cpu->c_size_cache)
-		l2size =3D this_cpu->c_size_cache(c,l2size);
-
-	/* Allow user to override all this if necessary. */
-	if (cachesize_override !=3D -1)
-		l2size =3D cachesize_override;
-
-	if ( l2size =3D=3D 0 )
-		return;		/* Again, no L2 cache is possible */
-
 	c->x86_cache_size =3D l2size;
=20
 	if (opt_cpu_info)
@@ -138,32 +124,6 @@ void __cpuinit display_cacheinfo(struct=20
 		       l2size, ecx & 0xFF);
 }
=20
-/* Naming convention should be: <Name> [(<Codename>)] */
-/* This table only is used unless init_<vendor>() below doesn't set it; =
*/
-/* in particular, if CPUID levels 0x80000002..4 are supported, this isn't =
used */
-
-/* Look up CPU names by table lookup. */
-static char __cpuinit *table_lookup_model(struct cpuinfo_x86 *c)
-{
-	struct cpu_model_info *info;
-
-	if ( c->x86_model >=3D 16 )
-		return NULL;	/* Range check */
-
-	if (!this_cpu)
-		return NULL;
-
-	info =3D this_cpu->c_models;
-
-	while (info && info->family) {
-		if (info->family =3D=3D c->x86)
-			return info->model_names[c->x86_model];
-		info++;
-	}
-	return NULL;		/* Not found */
-}
-
-
 static void __cpuinit get_cpu_vendor(struct cpuinfo_x86 *c, int early)
 {
 	char *v =3D c->x86_vendor_id;
@@ -356,14 +316,9 @@ void __cpuinit identify_cpu(struct cpuin
=20
 	/* If the model name is still unset, do table lookup. */
 	if ( !c->x86_model_id[0] ) {
-		char *p;
-		p =3D table_lookup_model(c);
-		if ( p )
-			safe_strcpy(c->x86_model_id, p);
-		else
-			/* Last resort... */
-			snprintf(c->x86_model_id, sizeof(c->x86_model_id),
-				"%02x/%02x", c->x86_vendor, c->x86_model);
+		/* Last resort... */
+		snprintf(c->x86_model_id, sizeof(c->x86_model_id),
+			"%02x/%02x", c->x86_vendor, c->x86_model);
 	}
=20
 	/* Now the feature flags better reflect actual CPU features! */
--- a/xen/arch/x86/cpu/cpu.h
+++ b/xen/arch/x86/cpu/cpu.h
@@ -1,10 +1,3 @@
-
-struct cpu_model_info {
-	int vendor;
-	int family;
-	char *model_names[16];
-};
-
 /* attempt to consolidate cpu attributes */
 struct cpu_dev {
 	char	* c_vendor;
@@ -12,11 +5,8 @@ struct cpu_dev {
 	/* some have two possibilities for cpuid string */
 	char	* c_ident[2];=09
=20
-	struct		cpu_model_info c_models[4];
-
 	void		(*c_init)(struct cpuinfo_x86 * c);
 	void		(*c_identify)(struct cpuinfo_x86 * c);
-	unsigned int	(*c_size_cache)(struct cpuinfo_x86 * c, unsigned =
int size);
 };
=20
 extern struct cpu_dev * cpu_devs [X86_VENDOR_NUM];
--- a/xen/arch/x86/cpu/intel.c
+++ b/xen/arch/x86/cpu/intel.c
@@ -292,49 +292,10 @@ static void __devinit init_intel(struct=20
 		set_bit(X86_FEATURE_ARAT, c->x86_capability);
 }
=20
-
-static unsigned int intel_size_cache(struct cpuinfo_x86 * c, unsigned int =
size)
-{
-	/* Intel PIII Tualatin. This comes in two flavours.
-	 * One has 256kb of cache, the other 512. We have no way
-	 * to determine which, so we use a boottime override
-	 * for the 512kb model, and assume 256 otherwise.
-	 */
-	if ((c->x86 =3D=3D 6) && (c->x86_model =3D=3D 11) && (size =3D=3D =
0))
-		size =3D 256;
-	return size;
-}
-
 static struct cpu_dev intel_cpu_dev __cpuinitdata =3D {
 	.c_vendor	=3D "Intel",
 	.c_ident 	=3D { "GenuineIntel" },
-	.c_models =3D {
-		{ .vendor =3D X86_VENDOR_INTEL, .family =3D 6, .model_names=
 =3D
-		  {=20
-			  [0] =3D "Pentium Pro A-step",
-			  [1] =3D "Pentium Pro",=20
-			  [3] =3D "Pentium II (Klamath)",=20
-			  [4] =3D "Pentium II (Deschutes)",=20
-			  [5] =3D "Pentium II (Deschutes)",=20
-			  [6] =3D "Mobile Pentium II",
-			  [7] =3D "Pentium III (Katmai)",=20
-			  [8] =3D "Pentium III (Coppermine)",=20
-			  [10] =3D "Pentium III (Cascades)",
-			  [11] =3D "Pentium III (Tualatin)",
-		  }
-		},
-		{ .vendor =3D X86_VENDOR_INTEL, .family =3D 15, .model_name=
s =3D
-		  {
-			  [0] =3D "Pentium 4 (Unknown)",
-			  [1] =3D "Pentium 4 (Willamette)",
-			  [2] =3D "Pentium 4 (Northwood)",
-			  [4] =3D "Pentium 4 (Foster)",
-			  [5] =3D "Pentium 4 (Foster)",
-		  }
-		},
-	},
 	.c_init		=3D init_intel,
-	.c_size_cache	=3D intel_size_cache,
 };
=20
 int __init intel_cpu_init(void)



--=__Part60516152.0__=
Content-Type: text/plain; name="x86-cpu-32bit-only-pieces.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="x86-cpu-32bit-only-pieces.patch"

x86: eliminate code affecting only 64-bit-incapable CPUs=0A=0ASigned-off-by=
: Jan Beulich <jbeulich@suse.com>=0A=0A--- a/xen/arch/x86/cpu/common.c=0A++=
+ b/xen/arch/x86/cpu/common.c=0A@@ -15,9 +15,6 @@=0A =0A #include =
"cpu.h"=0A =0A-static int cachesize_override __cpuinitdata =3D -1;=0A-size_=
param("cachesize", cachesize_override);=0A-=0A static bool_t __cpuinitdata =
use_xsave =3D 1;=0A boolean_param("xsave", use_xsave);=0A =0A@@ -120,17 =
+117,6 @@ void __cpuinit display_cacheinfo(struct =0A 	ecx =3D cpuid_ecx(0=
x80000006);=0A 	l2size =3D ecx >> 16;=0A 	=0A-	/* do processor-spe=
cific cache resizing */=0A-	if (this_cpu->c_size_cache)=0A-		=
l2size =3D this_cpu->c_size_cache(c,l2size);=0A-=0A-	/* Allow user to =
override all this if necessary. */=0A-	if (cachesize_override !=3D =
-1)=0A-		l2size =3D cachesize_override;=0A-=0A-	if ( l2size =3D=3D =
0 )=0A-		return;		/* Again, no L2 cache is possible =
*/=0A-=0A 	c->x86_cache_size =3D l2size;=0A =0A 	if (opt_cpu_info)=
=0A@@ -138,32 +124,6 @@ void __cpuinit display_cacheinfo(struct =0A 		=
       l2size, ecx & 0xFF);=0A }=0A =0A-/* Naming convention should be: =
<Name> [(<Codename>)] */=0A-/* This table only is used unless init_<vendor>=
() below doesn't set it; */=0A-/* in particular, if CPUID levels 0x80000002=
..4 are supported, this isn't used */=0A-=0A-/* Look up CPU names by table =
lookup. */=0A-static char __cpuinit *table_lookup_model(struct cpuinfo_x86 =
*c)=0A-{=0A-	struct cpu_model_info *info;=0A-=0A-	if ( c->x86_model =
>=3D 16 )=0A-		return NULL;	/* Range check */=0A-=0A-	if =
(!this_cpu)=0A-		return NULL;=0A-=0A-	info =3D this_cpu->c_models=
;=0A-=0A-	while (info && info->family) {=0A-		if =
(info->family =3D=3D c->x86)=0A-			return info->model_=
names[c->x86_model];=0A-		info++;=0A-	}=0A-	return =
NULL;		/* Not found */=0A-}=0A-=0A-=0A static void __cpuinit =
get_cpu_vendor(struct cpuinfo_x86 *c, int early)=0A {=0A 	char *v =
=3D c->x86_vendor_id;=0A@@ -356,14 +316,9 @@ void __cpuinit identify_cpu(st=
ruct cpuin=0A =0A 	/* If the model name is still unset, do table =
lookup. */=0A 	if ( !c->x86_model_id[0] ) {=0A-		char =
*p;=0A-		p =3D table_lookup_model(c);=0A-		if ( p =
)=0A-			safe_strcpy(c->x86_model_id, p);=0A-		=
else=0A-			/* Last resort... */=0A-			=
snprintf(c->x86_model_id, sizeof(c->x86_model_id),=0A-				=
"%02x/%02x", c->x86_vendor, c->x86_model);=0A+		/* Last resort... =
*/=0A+		snprintf(c->x86_model_id, sizeof(c->x86_model_id),=0A+		=
	"%02x/%02x", c->x86_vendor, c->x86_model);=0A 	}=0A =0A 	/* =
Now the feature flags better reflect actual CPU features! */=0A--- =
a/xen/arch/x86/cpu/cpu.h=0A+++ b/xen/arch/x86/cpu/cpu.h=0A@@ -1,10 +1,3 =
@@=0A-=0A-struct cpu_model_info {=0A-	int vendor;=0A-	int family;=0A-	=
char *model_names[16];=0A-};=0A-=0A /* attempt to consolidate cpu =
attributes */=0A struct cpu_dev {=0A 	char	* c_vendor;=0A@@ -12,11 =
+5,8 @@ struct cpu_dev {=0A 	/* some have two possibilities for cpuid =
string */=0A 	char	* c_ident[2];	=0A =0A-	struct		=
cpu_model_info c_models[4];=0A-=0A 	void		(*c_init)(struct =
cpuinfo_x86 * c);=0A 	void		(*c_identify)(struct cpuinfo_x86 * =
c);=0A-	unsigned int	(*c_size_cache)(struct cpuinfo_x86 * c, unsigned =
int size);=0A };=0A =0A extern struct cpu_dev * cpu_devs [X86_VENDOR_NUM];=
=0A--- a/xen/arch/x86/cpu/intel.c=0A+++ b/xen/arch/x86/cpu/intel.c=0A@@ =
-292,49 +292,10 @@ static void __devinit init_intel(struct =0A 		=
set_bit(X86_FEATURE_ARAT, c->x86_capability);=0A }=0A =0A-=0A-static =
unsigned int intel_size_cache(struct cpuinfo_x86 * c, unsigned int =
size)=0A-{=0A-	/* Intel PIII Tualatin. This comes in two flavours.=0A-	 * =
One has 256kb of cache, the other 512. We have no way=0A-	 * to =
determine which, so we use a boottime override=0A-	 * for the 512kb =
model, and assume 256 otherwise.=0A-	 */=0A-	if ((c->x86 =3D=3D 6) && =
(c->x86_model =3D=3D 11) && (size =3D=3D 0))=0A-		size =3D =
256;=0A-	return size;=0A-}=0A-=0A static struct cpu_dev intel_cpu_de=
v __cpuinitdata =3D {=0A 	.c_vendor	=3D "Intel",=0A 	=
.c_ident 	=3D { "GenuineIntel" },=0A-	.c_models =3D {=0A-		=
{ .vendor =3D X86_VENDOR_INTEL, .family =3D 6, .model_names =3D=0A-		=
  { =0A-			  [0] =3D "Pentium Pro A-step",=0A-		=
	  [1] =3D "Pentium Pro", =0A-			  [3] =3D "Pentium =
II (Klamath)", =0A-			  [4] =3D "Pentium II (Deschutes)",=
 =0A-			  [5] =3D "Pentium II (Deschutes)", =0A-		=
	  [6] =3D "Mobile Pentium II",=0A-			  [7] =3D =
"Pentium III (Katmai)", =0A-			  [8] =3D "Pentium III =
(Coppermine)", =0A-			  [10] =3D "Pentium III (Cascades)"=
,=0A-			  [11] =3D "Pentium III (Tualatin)",=0A-		=
  }=0A-		},=0A-		{ .vendor =3D X86_VENDOR_INTEL, .family =
=3D 15, .model_names =3D=0A-		  {=0A-			  [0] =3D =
"Pentium 4 (Unknown)",=0A-			  [1] =3D "Pentium 4 =
(Willamette)",=0A-			  [2] =3D "Pentium 4 (Northwood)",=
=0A-			  [4] =3D "Pentium 4 (Foster)",=0A-			=
  [5] =3D "Pentium 4 (Foster)",=0A-		  }=0A-		},=0A-	=
},=0A 	.c_init		=3D init_intel,=0A-	.c_size_cache	=3D =
intel_size_cache,=0A };=0A =0A int __init intel_cpu_init(void)=0A
--=__Part60516152.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

--=__Part60516152.0__=--


From xen-devel-bounces@lists.xen.org Fri Sep 21 12:00:20 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Sep 2012 12:00:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TF1to-0003Vg-CN; Fri, 21 Sep 2012 12: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 1TF1tn-0003Vb-4V
	for xen-devel@lists.xen.org; Fri, 21 Sep 2012 11:59:59 +0000
Received: from [85.158.143.35:53179] by server-3.bemta-4.messagelabs.com id
	EB/AB-10986-EB65C505; Fri, 21 Sep 2012 11:59:58 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1348228677!15801627!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19583 invoked from network); 21 Sep 2012 11:58:03 -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;
	21 Sep 2012 11:58:03 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 21 Sep 2012 12:57:58 +0100
Message-Id: <505C7262020000780009CF66@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 21 Sep 2012 12:57:54 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part60516152.0__="
Subject: [Xen-devel] [PATCH] x86: eliminate code affecting only
 64-bit-incapable CPUs
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
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.

--=__Part60516152.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/arch/x86/cpu/common.c
+++ b/xen/arch/x86/cpu/common.c
@@ -15,9 +15,6 @@
=20
 #include "cpu.h"
=20
-static int cachesize_override __cpuinitdata =3D -1;
-size_param("cachesize", cachesize_override);
-
 static bool_t __cpuinitdata use_xsave =3D 1;
 boolean_param("xsave", use_xsave);
=20
@@ -120,17 +117,6 @@ void __cpuinit display_cacheinfo(struct=20
 	ecx =3D cpuid_ecx(0x80000006);
 	l2size =3D ecx >> 16;
 =09
-	/* do processor-specific cache resizing */
-	if (this_cpu->c_size_cache)
-		l2size =3D this_cpu->c_size_cache(c,l2size);
-
-	/* Allow user to override all this if necessary. */
-	if (cachesize_override !=3D -1)
-		l2size =3D cachesize_override;
-
-	if ( l2size =3D=3D 0 )
-		return;		/* Again, no L2 cache is possible */
-
 	c->x86_cache_size =3D l2size;
=20
 	if (opt_cpu_info)
@@ -138,32 +124,6 @@ void __cpuinit display_cacheinfo(struct=20
 		       l2size, ecx & 0xFF);
 }
=20
-/* Naming convention should be: <Name> [(<Codename>)] */
-/* This table only is used unless init_<vendor>() below doesn't set it; =
*/
-/* in particular, if CPUID levels 0x80000002..4 are supported, this isn't =
used */
-
-/* Look up CPU names by table lookup. */
-static char __cpuinit *table_lookup_model(struct cpuinfo_x86 *c)
-{
-	struct cpu_model_info *info;
-
-	if ( c->x86_model >=3D 16 )
-		return NULL;	/* Range check */
-
-	if (!this_cpu)
-		return NULL;
-
-	info =3D this_cpu->c_models;
-
-	while (info && info->family) {
-		if (info->family =3D=3D c->x86)
-			return info->model_names[c->x86_model];
-		info++;
-	}
-	return NULL;		/* Not found */
-}
-
-
 static void __cpuinit get_cpu_vendor(struct cpuinfo_x86 *c, int early)
 {
 	char *v =3D c->x86_vendor_id;
@@ -356,14 +316,9 @@ void __cpuinit identify_cpu(struct cpuin
=20
 	/* If the model name is still unset, do table lookup. */
 	if ( !c->x86_model_id[0] ) {
-		char *p;
-		p =3D table_lookup_model(c);
-		if ( p )
-			safe_strcpy(c->x86_model_id, p);
-		else
-			/* Last resort... */
-			snprintf(c->x86_model_id, sizeof(c->x86_model_id),
-				"%02x/%02x", c->x86_vendor, c->x86_model);
+		/* Last resort... */
+		snprintf(c->x86_model_id, sizeof(c->x86_model_id),
+			"%02x/%02x", c->x86_vendor, c->x86_model);
 	}
=20
 	/* Now the feature flags better reflect actual CPU features! */
--- a/xen/arch/x86/cpu/cpu.h
+++ b/xen/arch/x86/cpu/cpu.h
@@ -1,10 +1,3 @@
-
-struct cpu_model_info {
-	int vendor;
-	int family;
-	char *model_names[16];
-};
-
 /* attempt to consolidate cpu attributes */
 struct cpu_dev {
 	char	* c_vendor;
@@ -12,11 +5,8 @@ struct cpu_dev {
 	/* some have two possibilities for cpuid string */
 	char	* c_ident[2];=09
=20
-	struct		cpu_model_info c_models[4];
-
 	void		(*c_init)(struct cpuinfo_x86 * c);
 	void		(*c_identify)(struct cpuinfo_x86 * c);
-	unsigned int	(*c_size_cache)(struct cpuinfo_x86 * c, unsigned =
int size);
 };
=20
 extern struct cpu_dev * cpu_devs [X86_VENDOR_NUM];
--- a/xen/arch/x86/cpu/intel.c
+++ b/xen/arch/x86/cpu/intel.c
@@ -292,49 +292,10 @@ static void __devinit init_intel(struct=20
 		set_bit(X86_FEATURE_ARAT, c->x86_capability);
 }
=20
-
-static unsigned int intel_size_cache(struct cpuinfo_x86 * c, unsigned int =
size)
-{
-	/* Intel PIII Tualatin. This comes in two flavours.
-	 * One has 256kb of cache, the other 512. We have no way
-	 * to determine which, so we use a boottime override
-	 * for the 512kb model, and assume 256 otherwise.
-	 */
-	if ((c->x86 =3D=3D 6) && (c->x86_model =3D=3D 11) && (size =3D=3D =
0))
-		size =3D 256;
-	return size;
-}
-
 static struct cpu_dev intel_cpu_dev __cpuinitdata =3D {
 	.c_vendor	=3D "Intel",
 	.c_ident 	=3D { "GenuineIntel" },
-	.c_models =3D {
-		{ .vendor =3D X86_VENDOR_INTEL, .family =3D 6, .model_names=
 =3D
-		  {=20
-			  [0] =3D "Pentium Pro A-step",
-			  [1] =3D "Pentium Pro",=20
-			  [3] =3D "Pentium II (Klamath)",=20
-			  [4] =3D "Pentium II (Deschutes)",=20
-			  [5] =3D "Pentium II (Deschutes)",=20
-			  [6] =3D "Mobile Pentium II",
-			  [7] =3D "Pentium III (Katmai)",=20
-			  [8] =3D "Pentium III (Coppermine)",=20
-			  [10] =3D "Pentium III (Cascades)",
-			  [11] =3D "Pentium III (Tualatin)",
-		  }
-		},
-		{ .vendor =3D X86_VENDOR_INTEL, .family =3D 15, .model_name=
s =3D
-		  {
-			  [0] =3D "Pentium 4 (Unknown)",
-			  [1] =3D "Pentium 4 (Willamette)",
-			  [2] =3D "Pentium 4 (Northwood)",
-			  [4] =3D "Pentium 4 (Foster)",
-			  [5] =3D "Pentium 4 (Foster)",
-		  }
-		},
-	},
 	.c_init		=3D init_intel,
-	.c_size_cache	=3D intel_size_cache,
 };
=20
 int __init intel_cpu_init(void)



--=__Part60516152.0__=
Content-Type: text/plain; name="x86-cpu-32bit-only-pieces.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="x86-cpu-32bit-only-pieces.patch"

x86: eliminate code affecting only 64-bit-incapable CPUs=0A=0ASigned-off-by=
: Jan Beulich <jbeulich@suse.com>=0A=0A--- a/xen/arch/x86/cpu/common.c=0A++=
+ b/xen/arch/x86/cpu/common.c=0A@@ -15,9 +15,6 @@=0A =0A #include =
"cpu.h"=0A =0A-static int cachesize_override __cpuinitdata =3D -1;=0A-size_=
param("cachesize", cachesize_override);=0A-=0A static bool_t __cpuinitdata =
use_xsave =3D 1;=0A boolean_param("xsave", use_xsave);=0A =0A@@ -120,17 =
+117,6 @@ void __cpuinit display_cacheinfo(struct =0A 	ecx =3D cpuid_ecx(0=
x80000006);=0A 	l2size =3D ecx >> 16;=0A 	=0A-	/* do processor-spe=
cific cache resizing */=0A-	if (this_cpu->c_size_cache)=0A-		=
l2size =3D this_cpu->c_size_cache(c,l2size);=0A-=0A-	/* Allow user to =
override all this if necessary. */=0A-	if (cachesize_override !=3D =
-1)=0A-		l2size =3D cachesize_override;=0A-=0A-	if ( l2size =3D=3D =
0 )=0A-		return;		/* Again, no L2 cache is possible =
*/=0A-=0A 	c->x86_cache_size =3D l2size;=0A =0A 	if (opt_cpu_info)=
=0A@@ -138,32 +124,6 @@ void __cpuinit display_cacheinfo(struct =0A 		=
       l2size, ecx & 0xFF);=0A }=0A =0A-/* Naming convention should be: =
<Name> [(<Codename>)] */=0A-/* This table only is used unless init_<vendor>=
() below doesn't set it; */=0A-/* in particular, if CPUID levels 0x80000002=
..4 are supported, this isn't used */=0A-=0A-/* Look up CPU names by table =
lookup. */=0A-static char __cpuinit *table_lookup_model(struct cpuinfo_x86 =
*c)=0A-{=0A-	struct cpu_model_info *info;=0A-=0A-	if ( c->x86_model =
>=3D 16 )=0A-		return NULL;	/* Range check */=0A-=0A-	if =
(!this_cpu)=0A-		return NULL;=0A-=0A-	info =3D this_cpu->c_models=
;=0A-=0A-	while (info && info->family) {=0A-		if =
(info->family =3D=3D c->x86)=0A-			return info->model_=
names[c->x86_model];=0A-		info++;=0A-	}=0A-	return =
NULL;		/* Not found */=0A-}=0A-=0A-=0A static void __cpuinit =
get_cpu_vendor(struct cpuinfo_x86 *c, int early)=0A {=0A 	char *v =
=3D c->x86_vendor_id;=0A@@ -356,14 +316,9 @@ void __cpuinit identify_cpu(st=
ruct cpuin=0A =0A 	/* If the model name is still unset, do table =
lookup. */=0A 	if ( !c->x86_model_id[0] ) {=0A-		char =
*p;=0A-		p =3D table_lookup_model(c);=0A-		if ( p =
)=0A-			safe_strcpy(c->x86_model_id, p);=0A-		=
else=0A-			/* Last resort... */=0A-			=
snprintf(c->x86_model_id, sizeof(c->x86_model_id),=0A-				=
"%02x/%02x", c->x86_vendor, c->x86_model);=0A+		/* Last resort... =
*/=0A+		snprintf(c->x86_model_id, sizeof(c->x86_model_id),=0A+		=
	"%02x/%02x", c->x86_vendor, c->x86_model);=0A 	}=0A =0A 	/* =
Now the feature flags better reflect actual CPU features! */=0A--- =
a/xen/arch/x86/cpu/cpu.h=0A+++ b/xen/arch/x86/cpu/cpu.h=0A@@ -1,10 +1,3 =
@@=0A-=0A-struct cpu_model_info {=0A-	int vendor;=0A-	int family;=0A-	=
char *model_names[16];=0A-};=0A-=0A /* attempt to consolidate cpu =
attributes */=0A struct cpu_dev {=0A 	char	* c_vendor;=0A@@ -12,11 =
+5,8 @@ struct cpu_dev {=0A 	/* some have two possibilities for cpuid =
string */=0A 	char	* c_ident[2];	=0A =0A-	struct		=
cpu_model_info c_models[4];=0A-=0A 	void		(*c_init)(struct =
cpuinfo_x86 * c);=0A 	void		(*c_identify)(struct cpuinfo_x86 * =
c);=0A-	unsigned int	(*c_size_cache)(struct cpuinfo_x86 * c, unsigned =
int size);=0A };=0A =0A extern struct cpu_dev * cpu_devs [X86_VENDOR_NUM];=
=0A--- a/xen/arch/x86/cpu/intel.c=0A+++ b/xen/arch/x86/cpu/intel.c=0A@@ =
-292,49 +292,10 @@ static void __devinit init_intel(struct =0A 		=
set_bit(X86_FEATURE_ARAT, c->x86_capability);=0A }=0A =0A-=0A-static =
unsigned int intel_size_cache(struct cpuinfo_x86 * c, unsigned int =
size)=0A-{=0A-	/* Intel PIII Tualatin. This comes in two flavours.=0A-	 * =
One has 256kb of cache, the other 512. We have no way=0A-	 * to =
determine which, so we use a boottime override=0A-	 * for the 512kb =
model, and assume 256 otherwise.=0A-	 */=0A-	if ((c->x86 =3D=3D 6) && =
(c->x86_model =3D=3D 11) && (size =3D=3D 0))=0A-		size =3D =
256;=0A-	return size;=0A-}=0A-=0A static struct cpu_dev intel_cpu_de=
v __cpuinitdata =3D {=0A 	.c_vendor	=3D "Intel",=0A 	=
.c_ident 	=3D { "GenuineIntel" },=0A-	.c_models =3D {=0A-		=
{ .vendor =3D X86_VENDOR_INTEL, .family =3D 6, .model_names =3D=0A-		=
  { =0A-			  [0] =3D "Pentium Pro A-step",=0A-		=
	  [1] =3D "Pentium Pro", =0A-			  [3] =3D "Pentium =
II (Klamath)", =0A-			  [4] =3D "Pentium II (Deschutes)",=
 =0A-			  [5] =3D "Pentium II (Deschutes)", =0A-		=
	  [6] =3D "Mobile Pentium II",=0A-			  [7] =3D =
"Pentium III (Katmai)", =0A-			  [8] =3D "Pentium III =
(Coppermine)", =0A-			  [10] =3D "Pentium III (Cascades)"=
,=0A-			  [11] =3D "Pentium III (Tualatin)",=0A-		=
  }=0A-		},=0A-		{ .vendor =3D X86_VENDOR_INTEL, .family =
=3D 15, .model_names =3D=0A-		  {=0A-			  [0] =3D =
"Pentium 4 (Unknown)",=0A-			  [1] =3D "Pentium 4 =
(Willamette)",=0A-			  [2] =3D "Pentium 4 (Northwood)",=
=0A-			  [4] =3D "Pentium 4 (Foster)",=0A-			=
  [5] =3D "Pentium 4 (Foster)",=0A-		  }=0A-		},=0A-	=
},=0A 	.c_init		=3D init_intel,=0A-	.c_size_cache	=3D =
intel_size_cache,=0A };=0A =0A int __init intel_cpu_init(void)=0A
--=__Part60516152.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

--=__Part60516152.0__=--


From xen-devel-bounces@lists.xen.org Fri Sep 21 12:17:42 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Sep 2012 12:17:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TF2Ac-0003uS-3S; Fri, 21 Sep 2012 12:17: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 1TF2Aa-0003uN-HO
	for xen-devel@lists.xen.org; Fri, 21 Sep 2012 12:17:20 +0000
Received: from [85.158.137.99:64774] by server-12.bemta-3.messagelabs.com id
	98/4B-10384-FCA5C505; Fri, 21 Sep 2012 12:17:19 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-2.tower-217.messagelabs.com!1348229839!18492342!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2222 invoked from network); 21 Sep 2012 12:17:19 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-2.tower-217.messagelabs.com with SMTP;
	21 Sep 2012 12:17:19 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 21 Sep 2012 13:17:19 +0100
Message-Id: <505C76EB020000780009CF8B@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 21 Sep 2012 13:17:15 +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 0/4] x86: assembly 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

1: enhance rsp-relative calculations
2: use compiler visible "add" instead of inline assembly "or" in get_cpu_info()
3: slightly streamline __prepare_to_wait() inline assembly
4: clean up interrupt stub generation

Note that some of this may look less worthwhile now that the
unification of 32- and 64-bit code isn't an aspect anymore, but
I think the net result is still an improvement, so I decided to
retain and post these patches unchanged (apart from dropping
the 32-bit specific pieces).

Signed-off-by: Jan Beulich <jbeulich@suse.com>


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 21 12:17:42 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Sep 2012 12:17:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TF2Ac-0003uS-3S; Fri, 21 Sep 2012 12:17: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 1TF2Aa-0003uN-HO
	for xen-devel@lists.xen.org; Fri, 21 Sep 2012 12:17:20 +0000
Received: from [85.158.137.99:64774] by server-12.bemta-3.messagelabs.com id
	98/4B-10384-FCA5C505; Fri, 21 Sep 2012 12:17:19 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-2.tower-217.messagelabs.com!1348229839!18492342!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2222 invoked from network); 21 Sep 2012 12:17:19 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-2.tower-217.messagelabs.com with SMTP;
	21 Sep 2012 12:17:19 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 21 Sep 2012 13:17:19 +0100
Message-Id: <505C76EB020000780009CF8B@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 21 Sep 2012 13:17:15 +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 0/4] x86: assembly 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

1: enhance rsp-relative calculations
2: use compiler visible "add" instead of inline assembly "or" in get_cpu_info()
3: slightly streamline __prepare_to_wait() inline assembly
4: clean up interrupt stub generation

Note that some of this may look less worthwhile now that the
unification of 32- and 64-bit code isn't an aspect anymore, but
I think the net result is still an improvement, so I decided to
retain and post these patches unchanged (apart from dropping
the 32-bit specific pieces).

Signed-off-by: Jan Beulich <jbeulich@suse.com>


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 21 12:20:58 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Sep 2012 12:20:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TF2Dp-00041T-N7; Fri, 21 Sep 2012 12:20:41 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1TF2Do-00041K-Op
	for xen-devel@lists.xen.org; Fri, 21 Sep 2012 12:20:40 +0000
Received: from [85.158.137.99:13308] by server-11.bemta-3.messagelabs.com id
	C7/1C-30250-79B5C505; Fri, 21 Sep 2012 12:20:39 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-12.tower-217.messagelabs.com!1348230039!15478562!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=UPPERCASE_25_50
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27981 invoked from network); 21 Sep 2012 12:20:39 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-12.tower-217.messagelabs.com with SMTP;
	21 Sep 2012 12:20:39 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 21 Sep 2012 13:20:39 +0100
Message-Id: <505C77B2020000780009CF98@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 21 Sep 2012 13:20:34 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
References: <505C76EB020000780009CF8B@nat28.tlf.novell.com>
In-Reply-To: <505C76EB020000780009CF8B@nat28.tlf.novell.com>
Mime-Version: 1.0
Content-Disposition: inline
Subject: [Xen-devel] [PATCH 1/4] x86: enhance rsp-relative calculations
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 use of "or" in GET_CPUINFO_FIELD so far wasn't ideal, as it doesn't
lend itself to folding this operation with a possibly subsequent one
(e.g. the well known mov+add=lea conversion). Split out the sub-
operations, and shorten assembly code slightly with this.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/arch/x86/x86_64/entry.S
+++ b/xen/arch/x86/x86_64/entry.S
@@ -445,10 +445,10 @@ domain_crash_synchronous_string:
 
 ENTRY(domain_crash_synchronous)
         # Get out of the guest-save area of the stack.
-        GET_CPUINFO_FIELD(CPUINFO_guest_cpu_user_regs,%rax)
-        movq  %rax,%rsp
+        GET_STACK_BASE(%rax)
+        leaq  STACK_CPUINFO_FIELD(guest_cpu_user_regs)(%rax),%rsp
         # create_bounce_frame() temporarily clobbers CS.RPL. Fix up.
-        GET_CURRENT(%rax)
+        __GET_CURRENT(%rax)
         movq  VCPU_domain(%rax),%rax
         testb $1,DOMAIN_is_32bit_pv(%rax)
         setz  %al
@@ -622,7 +622,7 @@ handle_ist_exception:
         testb $3,UREGS_cs(%rsp)
         jz    1f
         /* Interrupted guest context. Copy the context to stack bottom. */
-        GET_CPUINFO_FIELD(CPUINFO_guest_cpu_user_regs,%rdi)
+        GET_CPUINFO_FIELD(guest_cpu_user_regs,%rdi)
         movq  %rsp,%rsi
         movl  $UREGS_kernel_sizeof/8,%ecx
         movq  %rdi,%rsp
--- a/xen/include/asm-x86/asm_defns.h
+++ b/xen/include/asm-x86/asm_defns.h
@@ -44,6 +44,21 @@ void ret_from_intr(void);
         .subsection 0;            \
         .Llikely.tag:
 
+#define STACK_CPUINFO_FIELD(field) (STACK_SIZE-CPUINFO_sizeof+CPUINFO_##field)
+#define GET_STACK_BASE(reg)                       \
+        movq $~(STACK_SIZE-1),reg;                \
+        andq %rsp,reg
+
+#define GET_CPUINFO_FIELD(field, reg)             \
+        GET_STACK_BASE(reg);                      \
+        addq $STACK_CPUINFO_FIELD(field),reg
+
+#define __GET_CURRENT(reg)                        \
+        movq STACK_CPUINFO_FIELD(current_vcpu)(reg),reg
+#define GET_CURRENT(reg)                          \
+        GET_STACK_BASE(reg);                      \
+        __GET_CURRENT(reg)
+
 #endif
 
 #endif /* __X86_ASM_DEFNS_H__ */
--- a/xen/include/asm-x86/x86_64/asm_defns.h
+++ b/xen/include/asm-x86/x86_64/asm_defns.h
@@ -111,14 +111,6 @@ STR(IRQ) #nr "_interrupt:\n\t"          
     "movl $"#nr",4(%rsp)\n\t"                   \
     "jmp common_interrupt");
 
-#define GET_CPUINFO_FIELD(field,reg)                    \
-        movq $~(STACK_SIZE-1),reg;                      \
-        andq %rsp,reg;                                  \
-        orq  $(STACK_SIZE-CPUINFO_sizeof+field),reg;
-#define GET_CURRENT(reg)                                \
-        GET_CPUINFO_FIELD(CPUINFO_current_vcpu,reg)     \
-        movq (reg),reg;
-
 #ifdef __ASSEMBLY__
 # define _ASM_EX(p) p-.
 #else




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 21 12:20:58 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Sep 2012 12:20:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TF2Dp-00041T-N7; Fri, 21 Sep 2012 12:20:41 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1TF2Do-00041K-Op
	for xen-devel@lists.xen.org; Fri, 21 Sep 2012 12:20:40 +0000
Received: from [85.158.137.99:13308] by server-11.bemta-3.messagelabs.com id
	C7/1C-30250-79B5C505; Fri, 21 Sep 2012 12:20:39 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-12.tower-217.messagelabs.com!1348230039!15478562!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=UPPERCASE_25_50
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27981 invoked from network); 21 Sep 2012 12:20:39 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-12.tower-217.messagelabs.com with SMTP;
	21 Sep 2012 12:20:39 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 21 Sep 2012 13:20:39 +0100
Message-Id: <505C77B2020000780009CF98@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 21 Sep 2012 13:20:34 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
References: <505C76EB020000780009CF8B@nat28.tlf.novell.com>
In-Reply-To: <505C76EB020000780009CF8B@nat28.tlf.novell.com>
Mime-Version: 1.0
Content-Disposition: inline
Subject: [Xen-devel] [PATCH 1/4] x86: enhance rsp-relative calculations
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 use of "or" in GET_CPUINFO_FIELD so far wasn't ideal, as it doesn't
lend itself to folding this operation with a possibly subsequent one
(e.g. the well known mov+add=lea conversion). Split out the sub-
operations, and shorten assembly code slightly with this.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/arch/x86/x86_64/entry.S
+++ b/xen/arch/x86/x86_64/entry.S
@@ -445,10 +445,10 @@ domain_crash_synchronous_string:
 
 ENTRY(domain_crash_synchronous)
         # Get out of the guest-save area of the stack.
-        GET_CPUINFO_FIELD(CPUINFO_guest_cpu_user_regs,%rax)
-        movq  %rax,%rsp
+        GET_STACK_BASE(%rax)
+        leaq  STACK_CPUINFO_FIELD(guest_cpu_user_regs)(%rax),%rsp
         # create_bounce_frame() temporarily clobbers CS.RPL. Fix up.
-        GET_CURRENT(%rax)
+        __GET_CURRENT(%rax)
         movq  VCPU_domain(%rax),%rax
         testb $1,DOMAIN_is_32bit_pv(%rax)
         setz  %al
@@ -622,7 +622,7 @@ handle_ist_exception:
         testb $3,UREGS_cs(%rsp)
         jz    1f
         /* Interrupted guest context. Copy the context to stack bottom. */
-        GET_CPUINFO_FIELD(CPUINFO_guest_cpu_user_regs,%rdi)
+        GET_CPUINFO_FIELD(guest_cpu_user_regs,%rdi)
         movq  %rsp,%rsi
         movl  $UREGS_kernel_sizeof/8,%ecx
         movq  %rdi,%rsp
--- a/xen/include/asm-x86/asm_defns.h
+++ b/xen/include/asm-x86/asm_defns.h
@@ -44,6 +44,21 @@ void ret_from_intr(void);
         .subsection 0;            \
         .Llikely.tag:
 
+#define STACK_CPUINFO_FIELD(field) (STACK_SIZE-CPUINFO_sizeof+CPUINFO_##field)
+#define GET_STACK_BASE(reg)                       \
+        movq $~(STACK_SIZE-1),reg;                \
+        andq %rsp,reg
+
+#define GET_CPUINFO_FIELD(field, reg)             \
+        GET_STACK_BASE(reg);                      \
+        addq $STACK_CPUINFO_FIELD(field),reg
+
+#define __GET_CURRENT(reg)                        \
+        movq STACK_CPUINFO_FIELD(current_vcpu)(reg),reg
+#define GET_CURRENT(reg)                          \
+        GET_STACK_BASE(reg);                      \
+        __GET_CURRENT(reg)
+
 #endif
 
 #endif /* __X86_ASM_DEFNS_H__ */
--- a/xen/include/asm-x86/x86_64/asm_defns.h
+++ b/xen/include/asm-x86/x86_64/asm_defns.h
@@ -111,14 +111,6 @@ STR(IRQ) #nr "_interrupt:\n\t"          
     "movl $"#nr",4(%rsp)\n\t"                   \
     "jmp common_interrupt");
 
-#define GET_CPUINFO_FIELD(field,reg)                    \
-        movq $~(STACK_SIZE-1),reg;                      \
-        andq %rsp,reg;                                  \
-        orq  $(STACK_SIZE-CPUINFO_sizeof+field),reg;
-#define GET_CURRENT(reg)                                \
-        GET_CPUINFO_FIELD(CPUINFO_current_vcpu,reg)     \
-        movq (reg),reg;
-
 #ifdef __ASSEMBLY__
 # define _ASM_EX(p) p-.
 #else




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 21 12:21:49 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Sep 2012 12:21:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TF2Eg-00045i-56; Fri, 21 Sep 2012 12:21:34 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1TF2Ef-00045T-00
	for xen-devel@lists.xen.org; Fri, 21 Sep 2012 12:21:33 +0000
Received: from [85.158.137.99:50389] by server-14.bemta-3.messagelabs.com id
	E9/28-21431-CCB5C505; Fri, 21 Sep 2012 12:21:32 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-3.tower-217.messagelabs.com!1348230091!13542593!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3423 invoked from network); 21 Sep 2012 12:21:31 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-3.tower-217.messagelabs.com with SMTP;
	21 Sep 2012 12:21:31 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 21 Sep 2012 13:21:31 +0100
Message-Id: <505C77E6020000780009CF9C@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 21 Sep 2012 13:21:26 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
References: <505C76EB020000780009CF8B@nat28.tlf.novell.com>
In-Reply-To: <505C76EB020000780009CF8B@nat28.tlf.novell.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__PartE9D8E8D6.0__="
Subject: [Xen-devel] [PATCH 2/4] x86: use compiler visible "add" instead of
 inline assembly "or" in get_cpu_info()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
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.

--=__PartE9D8E8D6.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

This follows the same idea as the previous patch, just that the effect
is much more visible here: With a half-way [dr]ecent gcc this reduced
.text size by over 12k for me.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/include/asm-x86/current.h
+++ b/xen/include/asm-x86/current.h
@@ -25,12 +25,9 @@ struct cpu_info {
=20
 static inline struct cpu_info *get_cpu_info(void)
 {
-    struct cpu_info *cpu_info;
-    __asm__ ( "and %%"__OP"sp,%0; or %2,%0"
-              : "=3Dr" (cpu_info)
-              : "0" (~(STACK_SIZE-1)), "i" (STACK_SIZE-sizeof(struct =
cpu_info))
-        );
-    return cpu_info;
+    unsigned long tos;
+    __asm__ ( "and %%rsp,%0" : "=3Dr" (tos) : "0" (~(STACK_SIZE-1)) );
+    return (struct cpu_info *)(tos + STACK_SIZE) - 1;
 }
=20
 #define get_current()         (get_cpu_info()->current_vcpu)




--=__PartE9D8E8D6.0__=
Content-Type: text/plain; name="x86-get_cpu_info-add.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="x86-get_cpu_info-add.patch"

x86: use compiler visible "add" instead of inline assembly "or" in =
get_cpu_info()=0A=0AThis follows the same idea as the previous patch, just =
that the effect=0Ais much more visible here: With a half-way [dr]ecent gcc =
this reduced=0A.text size by over 12k for me.=0A=0ASigned-off-by: Jan =
Beulich <jbeulich@suse.com>=0A=0A--- a/xen/include/asm-x86/current.h=0A+++ =
b/xen/include/asm-x86/current.h=0A@@ -25,12 +25,9 @@ struct cpu_info {=0A =
=0A static inline struct cpu_info *get_cpu_info(void)=0A {=0A-    struct =
cpu_info *cpu_info;=0A-    __asm__ ( "and %%"__OP"sp,%0; or %2,%0"=0A-     =
         : "=3Dr" (cpu_info)=0A-              : "0" (~(STACK_SIZE-1)), "i" =
(STACK_SIZE-sizeof(struct cpu_info))=0A-        );=0A-    return =
cpu_info;=0A+    unsigned long tos;=0A+    __asm__ ( "and %%rsp,%0" : =
"=3Dr" (tos) : "0" (~(STACK_SIZE-1)) );=0A+    return (struct cpu_info =
*)(tos + STACK_SIZE) - 1;=0A }=0A =0A #define get_current()         =
(get_cpu_info()->current_vcpu)=0A
--=__PartE9D8E8D6.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

--=__PartE9D8E8D6.0__=--


From xen-devel-bounces@lists.xen.org Fri Sep 21 12:21:49 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Sep 2012 12:21:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TF2Eg-00045i-56; Fri, 21 Sep 2012 12:21:34 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1TF2Ef-00045T-00
	for xen-devel@lists.xen.org; Fri, 21 Sep 2012 12:21:33 +0000
Received: from [85.158.137.99:50389] by server-14.bemta-3.messagelabs.com id
	E9/28-21431-CCB5C505; Fri, 21 Sep 2012 12:21:32 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-3.tower-217.messagelabs.com!1348230091!13542593!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3423 invoked from network); 21 Sep 2012 12:21:31 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-3.tower-217.messagelabs.com with SMTP;
	21 Sep 2012 12:21:31 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 21 Sep 2012 13:21:31 +0100
Message-Id: <505C77E6020000780009CF9C@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 21 Sep 2012 13:21:26 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
References: <505C76EB020000780009CF8B@nat28.tlf.novell.com>
In-Reply-To: <505C76EB020000780009CF8B@nat28.tlf.novell.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__PartE9D8E8D6.0__="
Subject: [Xen-devel] [PATCH 2/4] x86: use compiler visible "add" instead of
 inline assembly "or" in get_cpu_info()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
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.

--=__PartE9D8E8D6.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

This follows the same idea as the previous patch, just that the effect
is much more visible here: With a half-way [dr]ecent gcc this reduced
.text size by over 12k for me.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/include/asm-x86/current.h
+++ b/xen/include/asm-x86/current.h
@@ -25,12 +25,9 @@ struct cpu_info {
=20
 static inline struct cpu_info *get_cpu_info(void)
 {
-    struct cpu_info *cpu_info;
-    __asm__ ( "and %%"__OP"sp,%0; or %2,%0"
-              : "=3Dr" (cpu_info)
-              : "0" (~(STACK_SIZE-1)), "i" (STACK_SIZE-sizeof(struct =
cpu_info))
-        );
-    return cpu_info;
+    unsigned long tos;
+    __asm__ ( "and %%rsp,%0" : "=3Dr" (tos) : "0" (~(STACK_SIZE-1)) );
+    return (struct cpu_info *)(tos + STACK_SIZE) - 1;
 }
=20
 #define get_current()         (get_cpu_info()->current_vcpu)




--=__PartE9D8E8D6.0__=
Content-Type: text/plain; name="x86-get_cpu_info-add.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="x86-get_cpu_info-add.patch"

x86: use compiler visible "add" instead of inline assembly "or" in =
get_cpu_info()=0A=0AThis follows the same idea as the previous patch, just =
that the effect=0Ais much more visible here: With a half-way [dr]ecent gcc =
this reduced=0A.text size by over 12k for me.=0A=0ASigned-off-by: Jan =
Beulich <jbeulich@suse.com>=0A=0A--- a/xen/include/asm-x86/current.h=0A+++ =
b/xen/include/asm-x86/current.h=0A@@ -25,12 +25,9 @@ struct cpu_info {=0A =
=0A static inline struct cpu_info *get_cpu_info(void)=0A {=0A-    struct =
cpu_info *cpu_info;=0A-    __asm__ ( "and %%"__OP"sp,%0; or %2,%0"=0A-     =
         : "=3Dr" (cpu_info)=0A-              : "0" (~(STACK_SIZE-1)), "i" =
(STACK_SIZE-sizeof(struct cpu_info))=0A-        );=0A-    return =
cpu_info;=0A+    unsigned long tos;=0A+    __asm__ ( "and %%rsp,%0" : =
"=3Dr" (tos) : "0" (~(STACK_SIZE-1)) );=0A+    return (struct cpu_info =
*)(tos + STACK_SIZE) - 1;=0A }=0A =0A #define get_current()         =
(get_cpu_info()->current_vcpu)=0A
--=__PartE9D8E8D6.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

--=__PartE9D8E8D6.0__=--


From xen-devel-bounces@lists.xen.org Fri Sep 21 12:22:19 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Sep 2012 12: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 1TF2FE-00049w-Ju; Fri, 21 Sep 2012 12:22:08 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1TF2FD-00049j-Bd
	for xen-devel@lists.xen.org; Fri, 21 Sep 2012 12:22:07 +0000
Received: from [85.158.137.99:56802] by server-5.bemta-3.messagelabs.com id
	8E/CC-13133-EEB5C505; Fri, 21 Sep 2012 12:22:06 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-6.tower-217.messagelabs.com!1348230125!13473049!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14797 invoked from network); 21 Sep 2012 12:22:05 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-6.tower-217.messagelabs.com with SMTP;
	21 Sep 2012 12:22:05 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 21 Sep 2012 13:22:05 +0100
Message-Id: <505C780A020000780009CFA0@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 21 Sep 2012 13:22:02 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
References: <505C76EB020000780009CF8B@nat28.tlf.novell.com>
In-Reply-To: <505C76EB020000780009CF8B@nat28.tlf.novell.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__PartC5F4C4FA.0__="
Subject: [Xen-devel] [PATCH 3/4] x86: slightly streamline
 __prepare_to_wait() inline assembly
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<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.

--=__PartC5F4C4FA.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/common/wait.c
+++ b/xen/common/wait.c
@@ -143,15 +143,13 @@ static void __prepare_to_wait(struct wai
         "push %%rax; push %%rbx; push %%rdx; "
         "push %%rbp; push %%r8; push %%r9; push %%r10; push %%r11; "
         "push %%r12; push %%r13; push %%r14; push %%r15; call 1f; "
-        "1: mov %%rsp,%%rsi; addq $2f-1b,(%%rsp); "
-        "sub %%rsi,%%rcx; cmp %3,%%rcx; jbe 2f; "
-        "xor %%esi,%%esi; jmp 3f; "
-        "2: rep movsb; mov %%rsp,%%rsi; 3: pop %%rax; "
+        "1: addq $2f-1b,(%%rsp); sub %%esp,%%ecx; cmp %3,%%ecx; jbe 3f; "
+        "mov %%rsp,%%rsi; 2: rep movsb; mov %%rsp,%%rsi; 3: pop %%rax; "
         "pop %%r15; pop %%r14; pop %%r13; pop %%r12; "
         "pop %%r11; pop %%r10; pop %%r9; pop %%r8; "
         "pop %%rbp; pop %%rdx; pop %%rbx; pop %%rax"
         : "=3D&S" (wqv->esp), "=3D&c" (dummy), "=3D&D" (dummy)
-        : "i" (PAGE_SIZE), "1" (cpu_info), "2" (wqv->stack)
+        : "i" (PAGE_SIZE), "0" (0), "1" (cpu_info), "2" (wqv->stack)
         : "memory" );
=20
     if ( unlikely(wqv->esp =3D=3D 0) )




--=__PartC5F4C4FA.0__=
Content-Type: text/plain; name="x86-wait-simplify.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="x86-wait-simplify.patch"

x86: slightly streamline __prepare_to_wait() inline assembly=0A=0ASigned-of=
f-by: Jan Beulich <jbeulich@suse.com>=0A=0A--- a/xen/common/wait.c=0A+++ =
b/xen/common/wait.c=0A@@ -143,15 +143,13 @@ static void __prepare_to_wait(s=
truct wai=0A         "push %%rax; push %%rbx; push %%rdx; "=0A         =
"push %%rbp; push %%r8; push %%r9; push %%r10; push %%r11; "=0A         =
"push %%r12; push %%r13; push %%r14; push %%r15; call 1f; "=0A-        "1: =
mov %%rsp,%%rsi; addq $2f-1b,(%%rsp); "=0A-        "sub %%rsi,%%rcx; cmp =
%3,%%rcx; jbe 2f; "=0A-        "xor %%esi,%%esi; jmp 3f; "=0A-        "2: =
rep movsb; mov %%rsp,%%rsi; 3: pop %%rax; "=0A+        "1: addq $2f-1b,(%%r=
sp); sub %%esp,%%ecx; cmp %3,%%ecx; jbe 3f; "=0A+        "mov %%rsp,%%rsi; =
2: rep movsb; mov %%rsp,%%rsi; 3: pop %%rax; "=0A         "pop %%r15; pop =
%%r14; pop %%r13; pop %%r12; "=0A         "pop %%r11; pop %%r10; pop %%r9; =
pop %%r8; "=0A         "pop %%rbp; pop %%rdx; pop %%rbx; pop %%rax"=0A     =
    : "=3D&S" (wqv->esp), "=3D&c" (dummy), "=3D&D" (dummy)=0A-        : =
"i" (PAGE_SIZE), "1" (cpu_info), "2" (wqv->stack)=0A+        : "i" =
(PAGE_SIZE), "0" (0), "1" (cpu_info), "2" (wqv->stack)=0A         : =
"memory" );=0A =0A     if ( unlikely(wqv->esp =3D=3D 0) )=0A
--=__PartC5F4C4FA.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

--=__PartC5F4C4FA.0__=--


From xen-devel-bounces@lists.xen.org Fri Sep 21 12:22:19 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Sep 2012 12: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 1TF2FE-00049w-Ju; Fri, 21 Sep 2012 12:22:08 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1TF2FD-00049j-Bd
	for xen-devel@lists.xen.org; Fri, 21 Sep 2012 12:22:07 +0000
Received: from [85.158.137.99:56802] by server-5.bemta-3.messagelabs.com id
	8E/CC-13133-EEB5C505; Fri, 21 Sep 2012 12:22:06 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-6.tower-217.messagelabs.com!1348230125!13473049!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14797 invoked from network); 21 Sep 2012 12:22:05 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-6.tower-217.messagelabs.com with SMTP;
	21 Sep 2012 12:22:05 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 21 Sep 2012 13:22:05 +0100
Message-Id: <505C780A020000780009CFA0@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 21 Sep 2012 13:22:02 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
References: <505C76EB020000780009CF8B@nat28.tlf.novell.com>
In-Reply-To: <505C76EB020000780009CF8B@nat28.tlf.novell.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__PartC5F4C4FA.0__="
Subject: [Xen-devel] [PATCH 3/4] x86: slightly streamline
 __prepare_to_wait() inline assembly
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<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.

--=__PartC5F4C4FA.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/common/wait.c
+++ b/xen/common/wait.c
@@ -143,15 +143,13 @@ static void __prepare_to_wait(struct wai
         "push %%rax; push %%rbx; push %%rdx; "
         "push %%rbp; push %%r8; push %%r9; push %%r10; push %%r11; "
         "push %%r12; push %%r13; push %%r14; push %%r15; call 1f; "
-        "1: mov %%rsp,%%rsi; addq $2f-1b,(%%rsp); "
-        "sub %%rsi,%%rcx; cmp %3,%%rcx; jbe 2f; "
-        "xor %%esi,%%esi; jmp 3f; "
-        "2: rep movsb; mov %%rsp,%%rsi; 3: pop %%rax; "
+        "1: addq $2f-1b,(%%rsp); sub %%esp,%%ecx; cmp %3,%%ecx; jbe 3f; "
+        "mov %%rsp,%%rsi; 2: rep movsb; mov %%rsp,%%rsi; 3: pop %%rax; "
         "pop %%r15; pop %%r14; pop %%r13; pop %%r12; "
         "pop %%r11; pop %%r10; pop %%r9; pop %%r8; "
         "pop %%rbp; pop %%rdx; pop %%rbx; pop %%rax"
         : "=3D&S" (wqv->esp), "=3D&c" (dummy), "=3D&D" (dummy)
-        : "i" (PAGE_SIZE), "1" (cpu_info), "2" (wqv->stack)
+        : "i" (PAGE_SIZE), "0" (0), "1" (cpu_info), "2" (wqv->stack)
         : "memory" );
=20
     if ( unlikely(wqv->esp =3D=3D 0) )




--=__PartC5F4C4FA.0__=
Content-Type: text/plain; name="x86-wait-simplify.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="x86-wait-simplify.patch"

x86: slightly streamline __prepare_to_wait() inline assembly=0A=0ASigned-of=
f-by: Jan Beulich <jbeulich@suse.com>=0A=0A--- a/xen/common/wait.c=0A+++ =
b/xen/common/wait.c=0A@@ -143,15 +143,13 @@ static void __prepare_to_wait(s=
truct wai=0A         "push %%rax; push %%rbx; push %%rdx; "=0A         =
"push %%rbp; push %%r8; push %%r9; push %%r10; push %%r11; "=0A         =
"push %%r12; push %%r13; push %%r14; push %%r15; call 1f; "=0A-        "1: =
mov %%rsp,%%rsi; addq $2f-1b,(%%rsp); "=0A-        "sub %%rsi,%%rcx; cmp =
%3,%%rcx; jbe 2f; "=0A-        "xor %%esi,%%esi; jmp 3f; "=0A-        "2: =
rep movsb; mov %%rsp,%%rsi; 3: pop %%rax; "=0A+        "1: addq $2f-1b,(%%r=
sp); sub %%esp,%%ecx; cmp %3,%%ecx; jbe 3f; "=0A+        "mov %%rsp,%%rsi; =
2: rep movsb; mov %%rsp,%%rsi; 3: pop %%rax; "=0A         "pop %%r15; pop =
%%r14; pop %%r13; pop %%r12; "=0A         "pop %%r11; pop %%r10; pop %%r9; =
pop %%r8; "=0A         "pop %%rbp; pop %%rdx; pop %%rbx; pop %%rax"=0A     =
    : "=3D&S" (wqv->esp), "=3D&c" (dummy), "=3D&D" (dummy)=0A-        : =
"i" (PAGE_SIZE), "1" (cpu_info), "2" (wqv->stack)=0A+        : "i" =
(PAGE_SIZE), "0" (0), "1" (cpu_info), "2" (wqv->stack)=0A         : =
"memory" );=0A =0A     if ( unlikely(wqv->esp =3D=3D 0) )=0A
--=__PartC5F4C4FA.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

--=__PartC5F4C4FA.0__=--


From xen-devel-bounces@lists.xen.org Fri Sep 21 12:22:54 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Sep 2012 12:22:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TF2Fp-0004FO-12; Fri, 21 Sep 2012 12:22:45 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1TF2Fn-0004FA-Py
	for xen-devel@lists.xen.org; Fri, 21 Sep 2012 12:22:44 +0000
Received: from [85.158.137.99:28964] by server-5.bemta-3.messagelabs.com id
	77/9D-13133-21C5C505; Fri, 21 Sep 2012 12:22:42 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-3.tower-217.messagelabs.com!1348230161!13542767!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=UPPERCASE_25_50
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6750 invoked from network); 21 Sep 2012 12:22:41 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-3.tower-217.messagelabs.com with SMTP;
	21 Sep 2012 12:22:41 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 21 Sep 2012 13:22:41 +0100
Message-Id: <505C782E020000780009CFA4@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 21 Sep 2012 13:22:38 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
References: <505C76EB020000780009CF8B@nat28.tlf.novell.com>
In-Reply-To: <505C76EB020000780009CF8B@nat28.tlf.novell.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part2617271E.0__="
Subject: [Xen-devel] [PATCH 4/4] x86: clean up interrupt stub generation
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<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.

--=__Part2617271E.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Apart from moving some code that is only used here from the header file
to the actual source one, this also
- moves interrupt[] into .init.data,
- prevents generating (unused) stubs for vectors below
  FIRST_DYNAMIC_VECTOR, and
- shortens and sanitizes the names of the stubs.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/arch/x86/i8259.c
+++ b/xen/arch/x86/i8259.c
@@ -37,26 +37,35 @@ __asm__(".section .text");
=20
 BUILD_COMMON_IRQ()
=20
-#define BI(x,y) \
-    BUILD_IRQ(x##y)
+#define IRQ_NAME(nr) VEC##nr##_interrupt
+
+#define BI(nr)                                           \
+void IRQ_NAME(nr)(void);                                 \
+__asm__(                                                 \
+".if " STR(0x##nr) " >=3D " STR(FIRST_DYNAMIC_VECTOR) "\n" \
+__ALIGN_STR "\n"                                         \
+STR(IRQ_NAME(nr)) ":\n\t"                                \
+BUILD_IRQ(0x##nr) "\n"                                   \
+".else\n"                                                \
+".equ " STR(IRQ_NAME(nr)) ", 0\n"                        \
+".endif\n")
=20
 #define BUILD_16_IRQS(x) \
-    BI(x,0) BI(x,1) BI(x,2) BI(x,3) \
-    BI(x,4) BI(x,5) BI(x,6) BI(x,7) \
-    BI(x,8) BI(x,9) BI(x,a) BI(x,b) \
-    BI(x,c) BI(x,d) BI(x,e) BI(x,f)
-
-BUILD_16_IRQS(0x0) BUILD_16_IRQS(0x1) BUILD_16_IRQS(0x2) BUILD_16_IRQS(0x3=
)
-BUILD_16_IRQS(0x4) BUILD_16_IRQS(0x5) BUILD_16_IRQS(0x6) BUILD_16_IRQS(0x7=
)
-BUILD_16_IRQS(0x8) BUILD_16_IRQS(0x9) BUILD_16_IRQS(0xa) BUILD_16_IRQS(0xb=
)
-BUILD_16_IRQS(0xc) BUILD_16_IRQS(0xd) BUILD_16_IRQS(0xe) BUILD_16_IRQS(0xf=
)
+    BI(x##0); BI(x##1); BI(x##2); BI(x##3); \
+    BI(x##4); BI(x##5); BI(x##6); BI(x##7); \
+    BI(x##8); BI(x##9); BI(x##a); BI(x##b); \
+    BI(x##c); BI(x##d); BI(x##e); BI(x##f)
+
+BUILD_16_IRQS(0); BUILD_16_IRQS(1); BUILD_16_IRQS(2); BUILD_16_IRQS(3);
+BUILD_16_IRQS(4); BUILD_16_IRQS(5); BUILD_16_IRQS(6); BUILD_16_IRQS(7);
+BUILD_16_IRQS(8); BUILD_16_IRQS(9); BUILD_16_IRQS(a); BUILD_16_IRQS(b);
+BUILD_16_IRQS(c); BUILD_16_IRQS(d); BUILD_16_IRQS(e); BUILD_16_IRQS(f);
=20
 #undef BUILD_16_IRQS
 #undef BI
=20
=20
-#define IRQ(x,y) \
-    IRQ##x##y##_interrupt
+#define IRQ(x,y) IRQ_NAME(x##y)
=20
 #define IRQLIST_16(x) \
     IRQ(x,0), IRQ(x,1), IRQ(x,2), IRQ(x,3), \
@@ -64,12 +73,12 @@ BUILD_16_IRQS(0xc) BUILD_16_IRQS(0xd) BU
     IRQ(x,8), IRQ(x,9), IRQ(x,a), IRQ(x,b), \
     IRQ(x,c), IRQ(x,d), IRQ(x,e), IRQ(x,f)
=20
-    static void (*interrupt[])(void) =3D {
-        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)=
,
-        IRQLIST_16(0xc), IRQLIST_16(0xd), IRQLIST_16(0xe), IRQLIST_16(0xf)=

-    };
+static void (*__initdata interrupt[NR_VECTORS])(void) =3D {
+    IRQLIST_16(0), IRQLIST_16(1), IRQLIST_16(2), IRQLIST_16(3),
+    IRQLIST_16(4), IRQLIST_16(5), IRQLIST_16(6), IRQLIST_16(7),
+    IRQLIST_16(8), IRQLIST_16(9), IRQLIST_16(a), IRQLIST_16(b),
+    IRQLIST_16(c), IRQLIST_16(d), IRQLIST_16(e), IRQLIST_16(f)
+};
=20
 #undef IRQ
 #undef IRQLIST_16
@@ -400,6 +409,7 @@ void __init init_IRQ(void)
     {
         if (vector =3D=3D HYPERCALL_VECTOR || vector =3D=3D LEGACY_SYSCALL=
_VECTOR)
             continue;
+        BUG_ON(!interrupt[vector]);
         set_intr_gate(vector, interrupt[vector]);
     }
=20
--- a/xen/include/asm-x86/x86_64/asm_defns.h
+++ b/xen/include/asm-x86/x86_64/asm_defns.h
@@ -99,17 +99,10 @@ __asm__(                               =20
     "callq " STR(do_IRQ) "\n\t"                 \
     "jmp ret_from_intr\n");
=20
-#define IRQ_NAME2(nr) nr##_interrupt(void)
-#define IRQ_NAME(nr) IRQ_NAME2(IRQ##nr)
-
 #define BUILD_IRQ(nr)                           \
-void IRQ_NAME(nr);                   \
-__asm__(                                        \
-"\n"__ALIGN_STR"\n"                             \
-STR(IRQ) #nr "_interrupt:\n\t"                  \
     "pushq $0\n\t"                              \
     "movl $"#nr",4(%rsp)\n\t"                   \
-    "jmp common_interrupt");
+    "jmp common_interrupt"
=20
 #ifdef __ASSEMBLY__
 # define _ASM_EX(p) p-.



--=__Part2617271E.0__=
Content-Type: text/plain; name="x86-interrupt-stubs.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="x86-interrupt-stubs.patch"

x86: clean up interrupt stub generation=0A=0AApart from moving some code =
that is only used here from the header file=0Ato the actual source one, =
this also=0A- moves interrupt[] into .init.data,=0A- prevents generating =
(unused) stubs for vectors below=0A  FIRST_DYNAMIC_VECTOR, and=0A- =
shortens and sanitizes the names of the stubs.=0A=0ASigned-off-by: Jan =
Beulich <jbeulich@suse.com>=0A=0A--- a/xen/arch/x86/i8259.c=0A+++ =
b/xen/arch/x86/i8259.c=0A@@ -37,26 +37,35 @@ __asm__(".section .text");=0A =
=0A BUILD_COMMON_IRQ()=0A =0A-#define BI(x,y) \=0A-    BUILD_IRQ(x##y)=0A+#=
define IRQ_NAME(nr) VEC##nr##_interrupt=0A+=0A+#define BI(nr)              =
                             \=0A+void IRQ_NAME(nr)(void);                 =
                \=0A+__asm__(                                              =
   \=0A+".if " STR(0x##nr) " >=3D " STR(FIRST_DYNAMIC_VECTOR) "\n" =
\=0A+__ALIGN_STR "\n"                                         \=0A+STR(IRQ_=
NAME(nr)) ":\n\t"                                \=0A+BUILD_IRQ(0x##nr) =
"\n"                                   \=0A+".else\n"                      =
                          \=0A+".equ " STR(IRQ_NAME(nr)) ", 0\n"           =
             \=0A+".endif\n")=0A =0A #define BUILD_16_IRQS(x) \=0A-    =
BI(x,0) BI(x,1) BI(x,2) BI(x,3) \=0A-    BI(x,4) BI(x,5) BI(x,6) BI(x,7) =
\=0A-    BI(x,8) BI(x,9) BI(x,a) BI(x,b) \=0A-    BI(x,c) BI(x,d) BI(x,e) =
BI(x,f)=0A-=0A-BUILD_16_IRQS(0x0) BUILD_16_IRQS(0x1) BUILD_16_IRQS(0x2) =
BUILD_16_IRQS(0x3)=0A-BUILD_16_IRQS(0x4) BUILD_16_IRQS(0x5) BUILD_16_IRQS(0=
x6) BUILD_16_IRQS(0x7)=0A-BUILD_16_IRQS(0x8) BUILD_16_IRQS(0x9) BUILD_16_IR=
QS(0xa) BUILD_16_IRQS(0xb)=0A-BUILD_16_IRQS(0xc) BUILD_16_IRQS(0xd) =
BUILD_16_IRQS(0xe) BUILD_16_IRQS(0xf)=0A+    BI(x##0); BI(x##1); BI(x##2); =
BI(x##3); \=0A+    BI(x##4); BI(x##5); BI(x##6); BI(x##7); \=0A+    =
BI(x##8); BI(x##9); BI(x##a); BI(x##b); \=0A+    BI(x##c); BI(x##d); =
BI(x##e); BI(x##f)=0A+=0A+BUILD_16_IRQS(0); BUILD_16_IRQS(1); BUILD_16_IRQS=
(2); BUILD_16_IRQS(3);=0A+BUILD_16_IRQS(4); BUILD_16_IRQS(5); BUILD_16_IRQS=
(6); BUILD_16_IRQS(7);=0A+BUILD_16_IRQS(8); BUILD_16_IRQS(9); BUILD_16_IRQS=
(a); BUILD_16_IRQS(b);=0A+BUILD_16_IRQS(c); BUILD_16_IRQS(d); BUILD_16_IRQS=
(e); BUILD_16_IRQS(f);=0A =0A #undef BUILD_16_IRQS=0A #undef BI=0A =0A =
=0A-#define IRQ(x,y) \=0A-    IRQ##x##y##_interrupt=0A+#define IRQ(x,y) =
IRQ_NAME(x##y)=0A =0A #define IRQLIST_16(x) \=0A     IRQ(x,0), IRQ(x,1), =
IRQ(x,2), IRQ(x,3), \=0A@@ -64,12 +73,12 @@ BUILD_16_IRQS(0xc) BUILD_16_IRQ=
S(0xd) BU=0A     IRQ(x,8), IRQ(x,9), IRQ(x,a), IRQ(x,b), \=0A     =
IRQ(x,c), IRQ(x,d), IRQ(x,e), IRQ(x,f)=0A =0A-    static void (*interrupt[]=
)(void) =3D {=0A-        IRQLIST_16(0x0), IRQLIST_16(0x1), IRQLIST_16(0x2),=
 IRQLIST_16(0x3),=0A-        IRQLIST_16(0x4), IRQLIST_16(0x5), IRQLIST_16(0=
x6), IRQLIST_16(0x7),=0A-        IRQLIST_16(0x8), IRQLIST_16(0x9), =
IRQLIST_16(0xa), IRQLIST_16(0xb),=0A-        IRQLIST_16(0xc), IRQLIST_16(0x=
d), IRQLIST_16(0xe), IRQLIST_16(0xf)=0A-    };=0A+static void (*__initdata =
interrupt[NR_VECTORS])(void) =3D {=0A+    IRQLIST_16(0), IRQLIST_16(1), =
IRQLIST_16(2), IRQLIST_16(3),=0A+    IRQLIST_16(4), IRQLIST_16(5), =
IRQLIST_16(6), IRQLIST_16(7),=0A+    IRQLIST_16(8), IRQLIST_16(9), =
IRQLIST_16(a), IRQLIST_16(b),=0A+    IRQLIST_16(c), IRQLIST_16(d), =
IRQLIST_16(e), IRQLIST_16(f)=0A+};=0A =0A #undef IRQ=0A #undef IRQLIST_16=
=0A@@ -400,6 +409,7 @@ void __init init_IRQ(void)=0A     {=0A         if =
(vector =3D=3D HYPERCALL_VECTOR || vector =3D=3D LEGACY_SYSCALL_VECTOR)=0A =
            continue;=0A+        BUG_ON(!interrupt[vector]);=0A         =
set_intr_gate(vector, interrupt[vector]);=0A     }=0A =0A--- a/xen/include/=
asm-x86/x86_64/asm_defns.h=0A+++ b/xen/include/asm-x86/x86_64/asm_defns.h=
=0A@@ -99,17 +99,10 @@ __asm__(                                =0A     =
"callq " STR(do_IRQ) "\n\t"                 \=0A     "jmp ret_from_intr\n")=
;=0A =0A-#define IRQ_NAME2(nr) nr##_interrupt(void)=0A-#define IRQ_NAME(nr)=
 IRQ_NAME2(IRQ##nr)=0A-=0A #define BUILD_IRQ(nr)                           =
\=0A-void IRQ_NAME(nr);                   \=0A-__asm__(                    =
                    \=0A-"\n"__ALIGN_STR"\n"                             =
\=0A-STR(IRQ) #nr "_interrupt:\n\t"                  \=0A     "pushq =
$0\n\t"                              \=0A     "movl $"#nr",4(%rsp)\n\t"    =
               \=0A-    "jmp common_interrupt");=0A+    "jmp common_interru=
pt"=0A =0A #ifdef __ASSEMBLY__=0A # define _ASM_EX(p) p-.=0A
--=__Part2617271E.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

--=__Part2617271E.0__=--


From xen-devel-bounces@lists.xen.org Fri Sep 21 12:22:54 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Sep 2012 12:22:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TF2Fp-0004FO-12; Fri, 21 Sep 2012 12:22:45 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1TF2Fn-0004FA-Py
	for xen-devel@lists.xen.org; Fri, 21 Sep 2012 12:22:44 +0000
Received: from [85.158.137.99:28964] by server-5.bemta-3.messagelabs.com id
	77/9D-13133-21C5C505; Fri, 21 Sep 2012 12:22:42 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-3.tower-217.messagelabs.com!1348230161!13542767!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=UPPERCASE_25_50
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6750 invoked from network); 21 Sep 2012 12:22:41 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-3.tower-217.messagelabs.com with SMTP;
	21 Sep 2012 12:22:41 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 21 Sep 2012 13:22:41 +0100
Message-Id: <505C782E020000780009CFA4@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 21 Sep 2012 13:22:38 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
References: <505C76EB020000780009CF8B@nat28.tlf.novell.com>
In-Reply-To: <505C76EB020000780009CF8B@nat28.tlf.novell.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part2617271E.0__="
Subject: [Xen-devel] [PATCH 4/4] x86: clean up interrupt stub generation
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<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.

--=__Part2617271E.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Apart from moving some code that is only used here from the header file
to the actual source one, this also
- moves interrupt[] into .init.data,
- prevents generating (unused) stubs for vectors below
  FIRST_DYNAMIC_VECTOR, and
- shortens and sanitizes the names of the stubs.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/arch/x86/i8259.c
+++ b/xen/arch/x86/i8259.c
@@ -37,26 +37,35 @@ __asm__(".section .text");
=20
 BUILD_COMMON_IRQ()
=20
-#define BI(x,y) \
-    BUILD_IRQ(x##y)
+#define IRQ_NAME(nr) VEC##nr##_interrupt
+
+#define BI(nr)                                           \
+void IRQ_NAME(nr)(void);                                 \
+__asm__(                                                 \
+".if " STR(0x##nr) " >=3D " STR(FIRST_DYNAMIC_VECTOR) "\n" \
+__ALIGN_STR "\n"                                         \
+STR(IRQ_NAME(nr)) ":\n\t"                                \
+BUILD_IRQ(0x##nr) "\n"                                   \
+".else\n"                                                \
+".equ " STR(IRQ_NAME(nr)) ", 0\n"                        \
+".endif\n")
=20
 #define BUILD_16_IRQS(x) \
-    BI(x,0) BI(x,1) BI(x,2) BI(x,3) \
-    BI(x,4) BI(x,5) BI(x,6) BI(x,7) \
-    BI(x,8) BI(x,9) BI(x,a) BI(x,b) \
-    BI(x,c) BI(x,d) BI(x,e) BI(x,f)
-
-BUILD_16_IRQS(0x0) BUILD_16_IRQS(0x1) BUILD_16_IRQS(0x2) BUILD_16_IRQS(0x3=
)
-BUILD_16_IRQS(0x4) BUILD_16_IRQS(0x5) BUILD_16_IRQS(0x6) BUILD_16_IRQS(0x7=
)
-BUILD_16_IRQS(0x8) BUILD_16_IRQS(0x9) BUILD_16_IRQS(0xa) BUILD_16_IRQS(0xb=
)
-BUILD_16_IRQS(0xc) BUILD_16_IRQS(0xd) BUILD_16_IRQS(0xe) BUILD_16_IRQS(0xf=
)
+    BI(x##0); BI(x##1); BI(x##2); BI(x##3); \
+    BI(x##4); BI(x##5); BI(x##6); BI(x##7); \
+    BI(x##8); BI(x##9); BI(x##a); BI(x##b); \
+    BI(x##c); BI(x##d); BI(x##e); BI(x##f)
+
+BUILD_16_IRQS(0); BUILD_16_IRQS(1); BUILD_16_IRQS(2); BUILD_16_IRQS(3);
+BUILD_16_IRQS(4); BUILD_16_IRQS(5); BUILD_16_IRQS(6); BUILD_16_IRQS(7);
+BUILD_16_IRQS(8); BUILD_16_IRQS(9); BUILD_16_IRQS(a); BUILD_16_IRQS(b);
+BUILD_16_IRQS(c); BUILD_16_IRQS(d); BUILD_16_IRQS(e); BUILD_16_IRQS(f);
=20
 #undef BUILD_16_IRQS
 #undef BI
=20
=20
-#define IRQ(x,y) \
-    IRQ##x##y##_interrupt
+#define IRQ(x,y) IRQ_NAME(x##y)
=20
 #define IRQLIST_16(x) \
     IRQ(x,0), IRQ(x,1), IRQ(x,2), IRQ(x,3), \
@@ -64,12 +73,12 @@ BUILD_16_IRQS(0xc) BUILD_16_IRQS(0xd) BU
     IRQ(x,8), IRQ(x,9), IRQ(x,a), IRQ(x,b), \
     IRQ(x,c), IRQ(x,d), IRQ(x,e), IRQ(x,f)
=20
-    static void (*interrupt[])(void) =3D {
-        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)=
,
-        IRQLIST_16(0xc), IRQLIST_16(0xd), IRQLIST_16(0xe), IRQLIST_16(0xf)=

-    };
+static void (*__initdata interrupt[NR_VECTORS])(void) =3D {
+    IRQLIST_16(0), IRQLIST_16(1), IRQLIST_16(2), IRQLIST_16(3),
+    IRQLIST_16(4), IRQLIST_16(5), IRQLIST_16(6), IRQLIST_16(7),
+    IRQLIST_16(8), IRQLIST_16(9), IRQLIST_16(a), IRQLIST_16(b),
+    IRQLIST_16(c), IRQLIST_16(d), IRQLIST_16(e), IRQLIST_16(f)
+};
=20
 #undef IRQ
 #undef IRQLIST_16
@@ -400,6 +409,7 @@ void __init init_IRQ(void)
     {
         if (vector =3D=3D HYPERCALL_VECTOR || vector =3D=3D LEGACY_SYSCALL=
_VECTOR)
             continue;
+        BUG_ON(!interrupt[vector]);
         set_intr_gate(vector, interrupt[vector]);
     }
=20
--- a/xen/include/asm-x86/x86_64/asm_defns.h
+++ b/xen/include/asm-x86/x86_64/asm_defns.h
@@ -99,17 +99,10 @@ __asm__(                               =20
     "callq " STR(do_IRQ) "\n\t"                 \
     "jmp ret_from_intr\n");
=20
-#define IRQ_NAME2(nr) nr##_interrupt(void)
-#define IRQ_NAME(nr) IRQ_NAME2(IRQ##nr)
-
 #define BUILD_IRQ(nr)                           \
-void IRQ_NAME(nr);                   \
-__asm__(                                        \
-"\n"__ALIGN_STR"\n"                             \
-STR(IRQ) #nr "_interrupt:\n\t"                  \
     "pushq $0\n\t"                              \
     "movl $"#nr",4(%rsp)\n\t"                   \
-    "jmp common_interrupt");
+    "jmp common_interrupt"
=20
 #ifdef __ASSEMBLY__
 # define _ASM_EX(p) p-.



--=__Part2617271E.0__=
Content-Type: text/plain; name="x86-interrupt-stubs.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="x86-interrupt-stubs.patch"

x86: clean up interrupt stub generation=0A=0AApart from moving some code =
that is only used here from the header file=0Ato the actual source one, =
this also=0A- moves interrupt[] into .init.data,=0A- prevents generating =
(unused) stubs for vectors below=0A  FIRST_DYNAMIC_VECTOR, and=0A- =
shortens and sanitizes the names of the stubs.=0A=0ASigned-off-by: Jan =
Beulich <jbeulich@suse.com>=0A=0A--- a/xen/arch/x86/i8259.c=0A+++ =
b/xen/arch/x86/i8259.c=0A@@ -37,26 +37,35 @@ __asm__(".section .text");=0A =
=0A BUILD_COMMON_IRQ()=0A =0A-#define BI(x,y) \=0A-    BUILD_IRQ(x##y)=0A+#=
define IRQ_NAME(nr) VEC##nr##_interrupt=0A+=0A+#define BI(nr)              =
                             \=0A+void IRQ_NAME(nr)(void);                 =
                \=0A+__asm__(                                              =
   \=0A+".if " STR(0x##nr) " >=3D " STR(FIRST_DYNAMIC_VECTOR) "\n" =
\=0A+__ALIGN_STR "\n"                                         \=0A+STR(IRQ_=
NAME(nr)) ":\n\t"                                \=0A+BUILD_IRQ(0x##nr) =
"\n"                                   \=0A+".else\n"                      =
                          \=0A+".equ " STR(IRQ_NAME(nr)) ", 0\n"           =
             \=0A+".endif\n")=0A =0A #define BUILD_16_IRQS(x) \=0A-    =
BI(x,0) BI(x,1) BI(x,2) BI(x,3) \=0A-    BI(x,4) BI(x,5) BI(x,6) BI(x,7) =
\=0A-    BI(x,8) BI(x,9) BI(x,a) BI(x,b) \=0A-    BI(x,c) BI(x,d) BI(x,e) =
BI(x,f)=0A-=0A-BUILD_16_IRQS(0x0) BUILD_16_IRQS(0x1) BUILD_16_IRQS(0x2) =
BUILD_16_IRQS(0x3)=0A-BUILD_16_IRQS(0x4) BUILD_16_IRQS(0x5) BUILD_16_IRQS(0=
x6) BUILD_16_IRQS(0x7)=0A-BUILD_16_IRQS(0x8) BUILD_16_IRQS(0x9) BUILD_16_IR=
QS(0xa) BUILD_16_IRQS(0xb)=0A-BUILD_16_IRQS(0xc) BUILD_16_IRQS(0xd) =
BUILD_16_IRQS(0xe) BUILD_16_IRQS(0xf)=0A+    BI(x##0); BI(x##1); BI(x##2); =
BI(x##3); \=0A+    BI(x##4); BI(x##5); BI(x##6); BI(x##7); \=0A+    =
BI(x##8); BI(x##9); BI(x##a); BI(x##b); \=0A+    BI(x##c); BI(x##d); =
BI(x##e); BI(x##f)=0A+=0A+BUILD_16_IRQS(0); BUILD_16_IRQS(1); BUILD_16_IRQS=
(2); BUILD_16_IRQS(3);=0A+BUILD_16_IRQS(4); BUILD_16_IRQS(5); BUILD_16_IRQS=
(6); BUILD_16_IRQS(7);=0A+BUILD_16_IRQS(8); BUILD_16_IRQS(9); BUILD_16_IRQS=
(a); BUILD_16_IRQS(b);=0A+BUILD_16_IRQS(c); BUILD_16_IRQS(d); BUILD_16_IRQS=
(e); BUILD_16_IRQS(f);=0A =0A #undef BUILD_16_IRQS=0A #undef BI=0A =0A =
=0A-#define IRQ(x,y) \=0A-    IRQ##x##y##_interrupt=0A+#define IRQ(x,y) =
IRQ_NAME(x##y)=0A =0A #define IRQLIST_16(x) \=0A     IRQ(x,0), IRQ(x,1), =
IRQ(x,2), IRQ(x,3), \=0A@@ -64,12 +73,12 @@ BUILD_16_IRQS(0xc) BUILD_16_IRQ=
S(0xd) BU=0A     IRQ(x,8), IRQ(x,9), IRQ(x,a), IRQ(x,b), \=0A     =
IRQ(x,c), IRQ(x,d), IRQ(x,e), IRQ(x,f)=0A =0A-    static void (*interrupt[]=
)(void) =3D {=0A-        IRQLIST_16(0x0), IRQLIST_16(0x1), IRQLIST_16(0x2),=
 IRQLIST_16(0x3),=0A-        IRQLIST_16(0x4), IRQLIST_16(0x5), IRQLIST_16(0=
x6), IRQLIST_16(0x7),=0A-        IRQLIST_16(0x8), IRQLIST_16(0x9), =
IRQLIST_16(0xa), IRQLIST_16(0xb),=0A-        IRQLIST_16(0xc), IRQLIST_16(0x=
d), IRQLIST_16(0xe), IRQLIST_16(0xf)=0A-    };=0A+static void (*__initdata =
interrupt[NR_VECTORS])(void) =3D {=0A+    IRQLIST_16(0), IRQLIST_16(1), =
IRQLIST_16(2), IRQLIST_16(3),=0A+    IRQLIST_16(4), IRQLIST_16(5), =
IRQLIST_16(6), IRQLIST_16(7),=0A+    IRQLIST_16(8), IRQLIST_16(9), =
IRQLIST_16(a), IRQLIST_16(b),=0A+    IRQLIST_16(c), IRQLIST_16(d), =
IRQLIST_16(e), IRQLIST_16(f)=0A+};=0A =0A #undef IRQ=0A #undef IRQLIST_16=
=0A@@ -400,6 +409,7 @@ void __init init_IRQ(void)=0A     {=0A         if =
(vector =3D=3D HYPERCALL_VECTOR || vector =3D=3D LEGACY_SYSCALL_VECTOR)=0A =
            continue;=0A+        BUG_ON(!interrupt[vector]);=0A         =
set_intr_gate(vector, interrupt[vector]);=0A     }=0A =0A--- a/xen/include/=
asm-x86/x86_64/asm_defns.h=0A+++ b/xen/include/asm-x86/x86_64/asm_defns.h=
=0A@@ -99,17 +99,10 @@ __asm__(                                =0A     =
"callq " STR(do_IRQ) "\n\t"                 \=0A     "jmp ret_from_intr\n")=
;=0A =0A-#define IRQ_NAME2(nr) nr##_interrupt(void)=0A-#define IRQ_NAME(nr)=
 IRQ_NAME2(IRQ##nr)=0A-=0A #define BUILD_IRQ(nr)                           =
\=0A-void IRQ_NAME(nr);                   \=0A-__asm__(                    =
                    \=0A-"\n"__ALIGN_STR"\n"                             =
\=0A-STR(IRQ) #nr "_interrupt:\n\t"                  \=0A     "pushq =
$0\n\t"                              \=0A     "movl $"#nr",4(%rsp)\n\t"    =
               \=0A-    "jmp common_interrupt");=0A+    "jmp common_interru=
pt"=0A =0A #ifdef __ASSEMBLY__=0A # define _ASM_EX(p) p-.=0A
--=__Part2617271E.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

--=__Part2617271E.0__=--


From xen-devel-bounces@lists.xen.org Fri Sep 21 12:24:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Sep 2012 12: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 1TF2Gx-0004PW-Gb; Fri, 21 Sep 2012 12:23:55 +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 1TF2Gw-0004PJ-1v
	for xen-devel@lists.xen.org; Fri, 21 Sep 2012 12:23:54 +0000
Received: from [85.158.143.35:52554] by server-3.bemta-4.messagelabs.com id
	BD/3F-10986-95C5C505; Fri, 21 Sep 2012 12:23:53 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1348230231!11193308!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNzY0MjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9208 invoked from network); 21 Sep 2012 12:23:52 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-10.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Sep 2012 12:23:52 -0000
X-IronPort-AV: E=Sophos;i="4.80,462,1344211200"; d="scan'208";a="208913861"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Sep 2012 12:23:50 +0000
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.279.1; Fri, 21 Sep 2012
	08:23:49 -0400
Message-ID: <505C5C54.4060100@citrix.com>
Date: Fri, 21 Sep 2012 13:23:48 +0100
From: David Vrabel <david.vrabel@citrix.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.1.16) Gecko/20120428 Iceowl/1.0b1 Icedove/3.0.11
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <1348051887-21885-1-git-send-email-oliver.chick@citrix.com>	<505AF126.2050806@citrix.com>	<1348140637.24539.32.camel@oliverchick-Precision-WorkStation-T3400>
	<505B1EB9020000780009CA6E@nat28.tlf.novell.com>
In-Reply-To: <505B1EB9020000780009CA6E@nat28.tlf.novell.com>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Oliver Chick <oliver.chick@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	David Vrabel <david.vrabel@citrix.com>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH] Persistent grant maps for xen blk drivers
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 20/09/12 12:48, Jan Beulich wrote:
>>>> On 20.09.12 at 13:30, Oliver Chick <oliver.chick@citrix.com> wrote:
>> The memory overhead, and fallback mode points are related:
>> -Firstly, it turns out that the overhead is actually 2.75MB, not 11MB
>> per device. I made a mistake (pointed out by Jan) as the maximum number
>> of requests that can fit into a single-page ring is 64, not 256.
>> -Clearly, this still scales linearly. So the problem of memory footprint
>> will occur with more VMs, or block devices.
>> -Whilst 2.75MB per device is probably acceptable (?), if we start using
>> multipage rings, then we might not want to have
>> BLKIF_MAX_PERS_REQUESTS_PER_DEVICE==__RING_SIZE, as this will cause the
>> memory overhead to increase. This is why I have implemented the
>> 'fallback' mode. With a multipage ring, it seems reasonable to want the
>> first $x$ grefs seen by blkback to be treated as persistent, and any
>> later ones to be non-persistent. Does that seem sensible?
> 
>>From a resource usage pov, perhaps. But this will get the guest
> entirely unpredictable performance. Plus I don't think 11Mb of
> _virtual_ space is unacceptable overhead in a 64-bit kernel. If
> you really want/need this in a 32-bit one, then perhaps some
> other alternatives would be needed (and persistent grants may
> not be the right approach there in the first place).

It's not just virtual space.  blkback in pvops kernels allocates its
pages from the balloon and if there aren't enough ballooned out pages it
has to allocate real pages (releasing the MFN back to Xen).

Classic kernels didn't need to do this as there was an API for allocate
new "empty" struct page's that get mapped into kernel space.

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 21 12:24:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Sep 2012 12: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 1TF2Gx-0004PW-Gb; Fri, 21 Sep 2012 12:23:55 +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 1TF2Gw-0004PJ-1v
	for xen-devel@lists.xen.org; Fri, 21 Sep 2012 12:23:54 +0000
Received: from [85.158.143.35:52554] by server-3.bemta-4.messagelabs.com id
	BD/3F-10986-95C5C505; Fri, 21 Sep 2012 12:23:53 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1348230231!11193308!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNzY0MjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9208 invoked from network); 21 Sep 2012 12:23:52 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-10.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Sep 2012 12:23:52 -0000
X-IronPort-AV: E=Sophos;i="4.80,462,1344211200"; d="scan'208";a="208913861"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Sep 2012 12:23:50 +0000
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.279.1; Fri, 21 Sep 2012
	08:23:49 -0400
Message-ID: <505C5C54.4060100@citrix.com>
Date: Fri, 21 Sep 2012 13:23:48 +0100
From: David Vrabel <david.vrabel@citrix.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.1.16) Gecko/20120428 Iceowl/1.0b1 Icedove/3.0.11
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <1348051887-21885-1-git-send-email-oliver.chick@citrix.com>	<505AF126.2050806@citrix.com>	<1348140637.24539.32.camel@oliverchick-Precision-WorkStation-T3400>
	<505B1EB9020000780009CA6E@nat28.tlf.novell.com>
In-Reply-To: <505B1EB9020000780009CA6E@nat28.tlf.novell.com>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Oliver Chick <oliver.chick@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	David Vrabel <david.vrabel@citrix.com>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH] Persistent grant maps for xen blk drivers
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 20/09/12 12:48, Jan Beulich wrote:
>>>> On 20.09.12 at 13:30, Oliver Chick <oliver.chick@citrix.com> wrote:
>> The memory overhead, and fallback mode points are related:
>> -Firstly, it turns out that the overhead is actually 2.75MB, not 11MB
>> per device. I made a mistake (pointed out by Jan) as the maximum number
>> of requests that can fit into a single-page ring is 64, not 256.
>> -Clearly, this still scales linearly. So the problem of memory footprint
>> will occur with more VMs, or block devices.
>> -Whilst 2.75MB per device is probably acceptable (?), if we start using
>> multipage rings, then we might not want to have
>> BLKIF_MAX_PERS_REQUESTS_PER_DEVICE==__RING_SIZE, as this will cause the
>> memory overhead to increase. This is why I have implemented the
>> 'fallback' mode. With a multipage ring, it seems reasonable to want the
>> first $x$ grefs seen by blkback to be treated as persistent, and any
>> later ones to be non-persistent. Does that seem sensible?
> 
>>From a resource usage pov, perhaps. But this will get the guest
> entirely unpredictable performance. Plus I don't think 11Mb of
> _virtual_ space is unacceptable overhead in a 64-bit kernel. If
> you really want/need this in a 32-bit one, then perhaps some
> other alternatives would be needed (and persistent grants may
> not be the right approach there in the first place).

It's not just virtual space.  blkback in pvops kernels allocates its
pages from the balloon and if there aren't enough ballooned out pages it
has to allocate real pages (releasing the MFN back to Xen).

Classic kernels didn't need to do this as there was an API for allocate
new "empty" struct page's that get mapped into kernel space.

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 21 12:44:24 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Sep 2012 12: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 1TF2aU-0004s1-NR; Fri, 21 Sep 2012 12:44: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 1TF2aS-0004rw-Oq
	for xen-devel@lists.xen.org; Fri, 21 Sep 2012 12:44:04 +0000
Received: from [85.158.138.51:12334] by server-11.bemta-3.messagelabs.com id
	08/21-30250-3116C505; Fri, 21 Sep 2012 12:44:03 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1348231443!23541006!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTA2NjI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10918 invoked from network); 21 Sep 2012 12:44:03 -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;
	21 Sep 2012 12:44:03 -0000
X-IronPort-AV: E=Sophos;i="4.80,462,1344211200"; d="scan'208";a="14689829"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Sep 2012 12:44: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.279.1;
	Fri, 21 Sep 2012 13:44:03 +0100
Message-ID: <1348231441.3452.20.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Fri, 21 Sep 2012 13:44:01 +0100
In-Reply-To: <505C7102020000780009CF5B@nat28.tlf.novell.com>
References: <505C6B7C020000780009CF08@nat28.tlf.novell.com>
	<1348227633.3452.16.camel@zakaz.uk.xensource.com>
	<505C7102020000780009CF5B@nat28.tlf.novell.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] printk: prefer %#x et at over 0x%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 Fri, 2012-09-21 at 12:52 +0100, Jan Beulich wrote:
> > PRIx64 is something like "016llx".
> 
> No - it's just "llx" or "lx". Are you perhaps mixing this up with
> PRIpaddr?

Ah, yes, I expect I am.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 21 12:44:24 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Sep 2012 12: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 1TF2aU-0004s1-NR; Fri, 21 Sep 2012 12:44: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 1TF2aS-0004rw-Oq
	for xen-devel@lists.xen.org; Fri, 21 Sep 2012 12:44:04 +0000
Received: from [85.158.138.51:12334] by server-11.bemta-3.messagelabs.com id
	08/21-30250-3116C505; Fri, 21 Sep 2012 12:44:03 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1348231443!23541006!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTA2NjI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10918 invoked from network); 21 Sep 2012 12:44:03 -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;
	21 Sep 2012 12:44:03 -0000
X-IronPort-AV: E=Sophos;i="4.80,462,1344211200"; d="scan'208";a="14689829"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Sep 2012 12:44: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.279.1;
	Fri, 21 Sep 2012 13:44:03 +0100
Message-ID: <1348231441.3452.20.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Fri, 21 Sep 2012 13:44:01 +0100
In-Reply-To: <505C7102020000780009CF5B@nat28.tlf.novell.com>
References: <505C6B7C020000780009CF08@nat28.tlf.novell.com>
	<1348227633.3452.16.camel@zakaz.uk.xensource.com>
	<505C7102020000780009CF5B@nat28.tlf.novell.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] printk: prefer %#x et at over 0x%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 Fri, 2012-09-21 at 12:52 +0100, Jan Beulich wrote:
> > PRIx64 is something like "016llx".
> 
> No - it's just "llx" or "lx". Are you perhaps mixing this up with
> PRIpaddr?

Ah, yes, I expect I am.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 21 12:56:19 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Sep 2012 12:56:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TF2m2-00051w-UW; Fri, 21 Sep 2012 12:56:02 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1TF2m0-00051r-Sx
	for xen-devel@lists.xen.org; Fri, 21 Sep 2012 12:56:01 +0000
Received: from [85.158.138.51:38648] by server-7.bemta-3.messagelabs.com id
	0D/8C-32000-FD36C505; Fri, 21 Sep 2012 12:55:59 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1348232158!23440535!1
X-Originating-IP: [209.85.215.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-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11638 invoked from network); 21 Sep 2012 12:55:59 -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 Sep 2012 12:55:59 -0000
Received: by eaac13 with SMTP id c13so1153819eaa.32
	for <xen-devel@lists.xen.org>; Fri, 21 Sep 2012 05:55:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=user-agent:date:subject:from:to:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=KThSefOLHSkckOE88+htoJCLf3HpqUS6F9+Z8m9osFY=;
	b=fbQKYurDNePczgofE429yYE9EMy1XQEf6mjdzTsoApeaAxXJrmRIzwWgBj3TeBJC7I
	qgjcjl47c3R3pjKwHgRGH55MRRSvu/O+puOB4U3SJFWlkPgV40cl68WLlD6bnNsnyS2k
	CvogSEWPRdkzY2SBycxPkApV4/7i8thZ3U6mzjSeSjgoY/3Lz+46aKRTzJ3ntZpP5i1S
	DDFuQ5mIG+Bwc2ufBc7LX0PAsqFehZ2ySLH9VC+y/uppapLVsCYnlaei7YdfqUk7a5nq
	LC5xfZqhKlElb8vukZhbftb8u31Qz8eqMw8gk+21RpRXTQQzF/8T7Cu6YxvU3VgZvOqV
	EK0A==
Received: by 10.14.179.136 with SMTP id h8mr6118967eem.6.1348232158751;
	Fri, 21 Sep 2012 05:55:58 -0700 (PDT)
Received: from [192.168.1.69] (host86-167-82-156.range86-167.btcentralplus.com.
	[86.167.82.156])
	by mx.google.com with ESMTPS id k49sm23804348een.4.2012.09.21.05.55.57
	(version=SSLv3 cipher=OTHER); Fri, 21 Sep 2012 05:55:58 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Fri, 21 Sep 2012 13:55:54 +0100
From: Keir Fraser <keir.xen@gmail.com>
To: Jan Beulich <JBeulich@suse.com>,
	xen-devel <xen-devel@lists.xen.org>
Message-ID: <CC82226A.3F5F0%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [PATCH] x86: enable VIA CPU support
Thread-Index: Ac2X+G9iccJtlm1nDE2dQQZeAncKwQ==
In-Reply-To: <505C6E68020000780009CF34@nat28.tlf.novell.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] [PATCH] x86: enable VIA CPU 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 21/09/2012 12:40, "Jan Beulich" <JBeulich@suse.com> wrote:

> Newer VIA CPUs have both 64-bit and VMX support. Enable them to be
> recognized for these purposes, at once stripping off any 32-bit CPU
> only bits from the respective CPU support file.
> 
> This particularly implies untying the VMX == Intel assumption in a few
> places.

Why can't we use 'cpu_has_vmx' instead of your strcmp construct?

It strikes me if it's safe to use in the one place it already is
(HVM_CR4_GUEST_RESERVED_BITS) then it should be safe for your use too. If
it's not then it's probably unsafe in its current use, and we should change
the definition of cpu_has_vmx in a preparatory patch.

 -- Keir

> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> 
> ---
> Note that my testing of this functionality wasn't as wide as I would
> have hoped it to be, since the box I was provided only survived the
> first few days - meanwhile it doesn't stay up long enough to just build
> hypervisor and tools. Therefore, further fixes to fully support these
> CPUs may be needed as the VIA folks themselves get to test that code.
> 
> --- a/xen/arch/x86/acpi/suspend.c
> +++ b/xen/arch/x86/acpi/suspend.c
> @@ -32,7 +32,8 @@ void save_rest_processor_state(void)
>      rdmsrl(MSR_SHADOW_GS_BASE, saved_kernel_gs_base);
>      rdmsrl(MSR_CSTAR, saved_cstar);
>      rdmsrl(MSR_LSTAR, saved_lstar);
> -    if ( boot_cpu_data.x86_vendor == X86_VENDOR_INTEL )
> +    if ( boot_cpu_data.x86_vendor == X86_VENDOR_INTEL ||
> +         boot_cpu_data.x86_vendor == X86_VENDOR_CENTAUR )
>      {
>          rdmsrl(MSR_IA32_SYSENTER_ESP, saved_sysenter_esp);
>          rdmsrl(MSR_IA32_SYSENTER_EIP, saved_sysenter_eip);
> @@ -59,7 +60,8 @@ void restore_rest_processor_state(void)
>      wrmsrl(MSR_GS_BASE, saved_gs_base);
>      wrmsrl(MSR_SHADOW_GS_BASE, saved_kernel_gs_base);
>  
> -    if ( boot_cpu_data.x86_vendor == X86_VENDOR_INTEL )
> +    if ( boot_cpu_data.x86_vendor == X86_VENDOR_INTEL ||
> +         boot_cpu_data.x86_vendor == X86_VENDOR_CENTAUR )
>      {
>          /* Recover sysenter MSRs */
>          wrmsrl(MSR_IA32_SYSENTER_ESP, saved_sysenter_esp);
> --- a/xen/arch/x86/cpu/Makefile
> +++ b/xen/arch/x86/cpu/Makefile
> @@ -2,10 +2,8 @@ subdir-y += mcheck
>  subdir-y += mtrr
>  
>  obj-y += amd.o
> +obj-y += centaur.o
>  obj-y += common.o
>  obj-y += intel.o
>  obj-y += intel_cacheinfo.o
>  obj-y += mwait-idle.o
> -
> -# Keeping around for VIA support (JBeulich)
> -# obj-$(x86_32) += centaur.o
> --- a/xen/arch/x86/cpu/centaur.c
> +++ b/xen/arch/x86/cpu/centaur.c
> @@ -45,51 +45,25 @@ static void __init init_c3(struct cpuinf
> c->x86_capability[5] = cpuid_edx(0xC0000001);
> }
>  
> - /* Cyrix III family needs CX8 & PGE explicity enabled. */
> - if (c->x86_model >=6 && c->x86_model <= 9) {
> -  rdmsrl(MSR_VIA_FCR, msr_content);
> -  wrmsrl(MSR_VIA_FCR, msr_content | (1ULL << 1 | 1ULL << 7));
> -  set_bit(X86_FEATURE_CX8, c->x86_capability);
> + if (c->x86 == 0x6 && c->x86_model >= 0xf) {
> +  c->x86_cache_alignment = c->x86_clflush_size * 2;
> +  set_bit(X86_FEATURE_CONSTANT_TSC, c->x86_capability);
> }
>  
> - /* Before Nehemiah, the C3's had 3dNOW! */
> - if (c->x86_model >=6 && c->x86_model <9)
> -  set_bit(X86_FEATURE_3DNOW, c->x86_capability);
> -
> get_model_name(c);
> display_cacheinfo(c);
>  }
>  
>  static void __init init_centaur(struct cpuinfo_x86 *c)
>  {
> - /* Bit 31 in normal CPUID used for nonstandard 3DNow ID;
> -    3DNow is IDd by bit 31 in extended CPUID (1*32+31) anyway */
> - clear_bit(0*32+31, c->x86_capability);
> -
> if (c->x86 == 6)
> init_c3(c);
>  }
>  
> -static unsigned int centaur_size_cache(struct cpuinfo_x86 * c, unsigned int
> size)
> -{
> - /* VIA C3 CPUs (670-68F) need further shifting. */
> - if ((c->x86 == 6) && ((c->x86_model == 7) || (c->x86_model == 8)))
> -  size >>= 8;
> -
> - /* VIA also screwed up Nehemiah stepping 1, and made
> -    it return '65KB' instead of '64KB'
> -    - Note, it seems this may only be in engineering samples. */
> - if ((c->x86==6) && (c->x86_model==9) && (c->x86_mask==1) && (size==65))
> -  size -=1;
> -
> - return size;
> -}
> -
>  static struct cpu_dev centaur_cpu_dev __cpuinitdata = {
> .c_vendor = "Centaur",
> .c_ident = { "CentaurHauls" },
> .c_init  = init_centaur,
> - .c_size_cache = centaur_size_cache,
>  };
>  
>  int __init centaur_init_cpu(void)
> @@ -97,5 +71,3 @@ int __init centaur_init_cpu(void)
> cpu_devs[X86_VENDOR_CENTAUR] = &centaur_cpu_dev;
> return 0;
>  }
> -
> -//early_arch_initcall(centaur_init_cpu);
> --- a/xen/arch/x86/cpu/common.c
> +++ b/xen/arch/x86/cpu/common.c
> @@ -567,6 +567,7 @@ void __init early_cpu_init(void)
>  {
> intel_cpu_init();
> amd_init_cpu();
> + centaur_init_cpu();
> early_cpu_detect();
>  }
>  /*
> --- a/xen/arch/x86/hvm/hvm.c
> +++ b/xen/arch/x86/hvm/hvm.c
> @@ -114,6 +114,7 @@ static int __init hvm_enable(void)
>      switch ( boot_cpu_data.x86_vendor )
>      {
>      case X86_VENDOR_INTEL:
> +    case X86_VENDOR_CENTAUR:
>          fns = start_vmx();
>          break;
>      case X86_VENDOR_AMD:
> --- a/xen/arch/x86/hvm/nestedhvm.c
> +++ b/xen/arch/x86/hvm/nestedhvm.c
> @@ -151,13 +151,15 @@ nestedhvm_is_n2(struct vcpu *v)
>  static int __init
>  nestedhvm_setup(void)
>  {
> -    /* Same format and size as hvm_io_bitmap (Intel needs only 2 pages). */
> -    unsigned int nr = (boot_cpu_data.x86_vendor == X86_VENDOR_INTEL) ? 2 : 3;
> -    unsigned int i, order = get_order_from_pages(nr);
> +    unsigned int i, nr, order;
>  
>      if ( !hvm_funcs.name )
>          return 0;
>  
> +    /* Same format and size as hvm_io_bitmap (VMX needs only 2 pages). */
> +    nr = !strcmp(hvm_funcs.name, "VMX") ? 2 : 3;
> +    order = get_order_from_pages(nr);
> +
>      /* shadow_io_bitmaps can't be declared static because
>       *   they must fulfill hw requirements (page aligned section)
>       *   and doing so triggers the ASSERT(va >= XEN_VIRT_START)
> --- a/xen/arch/x86/hvm/viridian.c
> +++ b/xen/arch/x86/hvm/viridian.c
> @@ -156,8 +156,7 @@ static void enable_hypercall_page(struct
>      *(u32 *)(p + 1) = 0x80000000;
>      *(u8  *)(p + 5) = 0x0f; /* vmcall/vmmcall */
>      *(u8  *)(p + 6) = 0x01;
> -    *(u8  *)(p + 7) = ((boot_cpu_data.x86_vendor == X86_VENDOR_INTEL)
> -                       ? 0xc1 : 0xd9);
> +    *(u8  *)(p + 7) = (!strcmp(hvm_funcs.name, "VMX") ? 0xc1 : 0xd9);
>      *(u8  *)(p + 8) = 0xc3; /* ret */
>      memset(p + 9, 0xcc, PAGE_SIZE - 9); /* int3, int3, ... */
>  
> --- a/xen/arch/x86/mm/mem_event.c
> +++ b/xen/arch/x86/mm/mem_event.c
> @@ -608,7 +608,7 @@ int mem_event_domctl(struct domain *d, x
>                  break;
>  
>              /* Currently only EPT is supported */
> -            if ( boot_cpu_data.x86_vendor != X86_VENDOR_INTEL )
> +            if ( strcmp(hvm_funcs.name, "VMX") )
>                  break;
>  
>              rc = mem_event_enable(d, mec, med, _VPF_mem_access,
> --- a/xen/arch/x86/mm/p2m.c
> +++ b/xen/arch/x86/mm/p2m.c
> @@ -83,7 +83,7 @@ static void p2m_initialise(struct domain
>  
>      p2m->cr3 = CR3_EADDR;
>  
> -    if ( hap_enabled(d) && (boot_cpu_data.x86_vendor == X86_VENDOR_INTEL) )
> +    if ( hap_enabled(d) && !strcmp(hvm_funcs.name, "VMX") )
>          ept_p2m_init(p2m);
>      else
>          p2m_pt_init(p2m);
> --- a/xen/arch/x86/x86_64/traps.c
> +++ b/xen/arch/x86/x86_64/traps.c
> @@ -399,7 +399,8 @@ void __devinit subarch_percpu_traps_init
>      wrmsrl(MSR_LSTAR, (unsigned long)stack);
>      stack += write_stack_trampoline(stack, stack_bottom, FLAT_KERNEL_CS64);
>  
> -    if ( boot_cpu_data.x86_vendor == X86_VENDOR_INTEL )
> +    if ( boot_cpu_data.x86_vendor == X86_VENDOR_INTEL ||
> +         boot_cpu_data.x86_vendor == X86_VENDOR_CENTAUR )
>      {
>          /* SYSENTER entry. */
>          wrmsrl(MSR_IA32_SYSENTER_ESP, (unsigned long)stack_bottom);
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Sep 21 12:56:19 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Sep 2012 12:56:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TF2m2-00051w-UW; Fri, 21 Sep 2012 12:56:02 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1TF2m0-00051r-Sx
	for xen-devel@lists.xen.org; Fri, 21 Sep 2012 12:56:01 +0000
Received: from [85.158.138.51:38648] by server-7.bemta-3.messagelabs.com id
	0D/8C-32000-FD36C505; Fri, 21 Sep 2012 12:55:59 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1348232158!23440535!1
X-Originating-IP: [209.85.215.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-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11638 invoked from network); 21 Sep 2012 12:55:59 -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 Sep 2012 12:55:59 -0000
Received: by eaac13 with SMTP id c13so1153819eaa.32
	for <xen-devel@lists.xen.org>; Fri, 21 Sep 2012 05:55:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=user-agent:date:subject:from:to:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=KThSefOLHSkckOE88+htoJCLf3HpqUS6F9+Z8m9osFY=;
	b=fbQKYurDNePczgofE429yYE9EMy1XQEf6mjdzTsoApeaAxXJrmRIzwWgBj3TeBJC7I
	qgjcjl47c3R3pjKwHgRGH55MRRSvu/O+puOB4U3SJFWlkPgV40cl68WLlD6bnNsnyS2k
	CvogSEWPRdkzY2SBycxPkApV4/7i8thZ3U6mzjSeSjgoY/3Lz+46aKRTzJ3ntZpP5i1S
	DDFuQ5mIG+Bwc2ufBc7LX0PAsqFehZ2ySLH9VC+y/uppapLVsCYnlaei7YdfqUk7a5nq
	LC5xfZqhKlElb8vukZhbftb8u31Qz8eqMw8gk+21RpRXTQQzF/8T7Cu6YxvU3VgZvOqV
	EK0A==
Received: by 10.14.179.136 with SMTP id h8mr6118967eem.6.1348232158751;
	Fri, 21 Sep 2012 05:55:58 -0700 (PDT)
Received: from [192.168.1.69] (host86-167-82-156.range86-167.btcentralplus.com.
	[86.167.82.156])
	by mx.google.com with ESMTPS id k49sm23804348een.4.2012.09.21.05.55.57
	(version=SSLv3 cipher=OTHER); Fri, 21 Sep 2012 05:55:58 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Fri, 21 Sep 2012 13:55:54 +0100
From: Keir Fraser <keir.xen@gmail.com>
To: Jan Beulich <JBeulich@suse.com>,
	xen-devel <xen-devel@lists.xen.org>
Message-ID: <CC82226A.3F5F0%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [PATCH] x86: enable VIA CPU support
Thread-Index: Ac2X+G9iccJtlm1nDE2dQQZeAncKwQ==
In-Reply-To: <505C6E68020000780009CF34@nat28.tlf.novell.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] [PATCH] x86: enable VIA CPU 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 21/09/2012 12:40, "Jan Beulich" <JBeulich@suse.com> wrote:

> Newer VIA CPUs have both 64-bit and VMX support. Enable them to be
> recognized for these purposes, at once stripping off any 32-bit CPU
> only bits from the respective CPU support file.
> 
> This particularly implies untying the VMX == Intel assumption in a few
> places.

Why can't we use 'cpu_has_vmx' instead of your strcmp construct?

It strikes me if it's safe to use in the one place it already is
(HVM_CR4_GUEST_RESERVED_BITS) then it should be safe for your use too. If
it's not then it's probably unsafe in its current use, and we should change
the definition of cpu_has_vmx in a preparatory patch.

 -- Keir

> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> 
> ---
> Note that my testing of this functionality wasn't as wide as I would
> have hoped it to be, since the box I was provided only survived the
> first few days - meanwhile it doesn't stay up long enough to just build
> hypervisor and tools. Therefore, further fixes to fully support these
> CPUs may be needed as the VIA folks themselves get to test that code.
> 
> --- a/xen/arch/x86/acpi/suspend.c
> +++ b/xen/arch/x86/acpi/suspend.c
> @@ -32,7 +32,8 @@ void save_rest_processor_state(void)
>      rdmsrl(MSR_SHADOW_GS_BASE, saved_kernel_gs_base);
>      rdmsrl(MSR_CSTAR, saved_cstar);
>      rdmsrl(MSR_LSTAR, saved_lstar);
> -    if ( boot_cpu_data.x86_vendor == X86_VENDOR_INTEL )
> +    if ( boot_cpu_data.x86_vendor == X86_VENDOR_INTEL ||
> +         boot_cpu_data.x86_vendor == X86_VENDOR_CENTAUR )
>      {
>          rdmsrl(MSR_IA32_SYSENTER_ESP, saved_sysenter_esp);
>          rdmsrl(MSR_IA32_SYSENTER_EIP, saved_sysenter_eip);
> @@ -59,7 +60,8 @@ void restore_rest_processor_state(void)
>      wrmsrl(MSR_GS_BASE, saved_gs_base);
>      wrmsrl(MSR_SHADOW_GS_BASE, saved_kernel_gs_base);
>  
> -    if ( boot_cpu_data.x86_vendor == X86_VENDOR_INTEL )
> +    if ( boot_cpu_data.x86_vendor == X86_VENDOR_INTEL ||
> +         boot_cpu_data.x86_vendor == X86_VENDOR_CENTAUR )
>      {
>          /* Recover sysenter MSRs */
>          wrmsrl(MSR_IA32_SYSENTER_ESP, saved_sysenter_esp);
> --- a/xen/arch/x86/cpu/Makefile
> +++ b/xen/arch/x86/cpu/Makefile
> @@ -2,10 +2,8 @@ subdir-y += mcheck
>  subdir-y += mtrr
>  
>  obj-y += amd.o
> +obj-y += centaur.o
>  obj-y += common.o
>  obj-y += intel.o
>  obj-y += intel_cacheinfo.o
>  obj-y += mwait-idle.o
> -
> -# Keeping around for VIA support (JBeulich)
> -# obj-$(x86_32) += centaur.o
> --- a/xen/arch/x86/cpu/centaur.c
> +++ b/xen/arch/x86/cpu/centaur.c
> @@ -45,51 +45,25 @@ static void __init init_c3(struct cpuinf
> c->x86_capability[5] = cpuid_edx(0xC0000001);
> }
>  
> - /* Cyrix III family needs CX8 & PGE explicity enabled. */
> - if (c->x86_model >=6 && c->x86_model <= 9) {
> -  rdmsrl(MSR_VIA_FCR, msr_content);
> -  wrmsrl(MSR_VIA_FCR, msr_content | (1ULL << 1 | 1ULL << 7));
> -  set_bit(X86_FEATURE_CX8, c->x86_capability);
> + if (c->x86 == 0x6 && c->x86_model >= 0xf) {
> +  c->x86_cache_alignment = c->x86_clflush_size * 2;
> +  set_bit(X86_FEATURE_CONSTANT_TSC, c->x86_capability);
> }
>  
> - /* Before Nehemiah, the C3's had 3dNOW! */
> - if (c->x86_model >=6 && c->x86_model <9)
> -  set_bit(X86_FEATURE_3DNOW, c->x86_capability);
> -
> get_model_name(c);
> display_cacheinfo(c);
>  }
>  
>  static void __init init_centaur(struct cpuinfo_x86 *c)
>  {
> - /* Bit 31 in normal CPUID used for nonstandard 3DNow ID;
> -    3DNow is IDd by bit 31 in extended CPUID (1*32+31) anyway */
> - clear_bit(0*32+31, c->x86_capability);
> -
> if (c->x86 == 6)
> init_c3(c);
>  }
>  
> -static unsigned int centaur_size_cache(struct cpuinfo_x86 * c, unsigned int
> size)
> -{
> - /* VIA C3 CPUs (670-68F) need further shifting. */
> - if ((c->x86 == 6) && ((c->x86_model == 7) || (c->x86_model == 8)))
> -  size >>= 8;
> -
> - /* VIA also screwed up Nehemiah stepping 1, and made
> -    it return '65KB' instead of '64KB'
> -    - Note, it seems this may only be in engineering samples. */
> - if ((c->x86==6) && (c->x86_model==9) && (c->x86_mask==1) && (size==65))
> -  size -=1;
> -
> - return size;
> -}
> -
>  static struct cpu_dev centaur_cpu_dev __cpuinitdata = {
> .c_vendor = "Centaur",
> .c_ident = { "CentaurHauls" },
> .c_init  = init_centaur,
> - .c_size_cache = centaur_size_cache,
>  };
>  
>  int __init centaur_init_cpu(void)
> @@ -97,5 +71,3 @@ int __init centaur_init_cpu(void)
> cpu_devs[X86_VENDOR_CENTAUR] = &centaur_cpu_dev;
> return 0;
>  }
> -
> -//early_arch_initcall(centaur_init_cpu);
> --- a/xen/arch/x86/cpu/common.c
> +++ b/xen/arch/x86/cpu/common.c
> @@ -567,6 +567,7 @@ void __init early_cpu_init(void)
>  {
> intel_cpu_init();
> amd_init_cpu();
> + centaur_init_cpu();
> early_cpu_detect();
>  }
>  /*
> --- a/xen/arch/x86/hvm/hvm.c
> +++ b/xen/arch/x86/hvm/hvm.c
> @@ -114,6 +114,7 @@ static int __init hvm_enable(void)
>      switch ( boot_cpu_data.x86_vendor )
>      {
>      case X86_VENDOR_INTEL:
> +    case X86_VENDOR_CENTAUR:
>          fns = start_vmx();
>          break;
>      case X86_VENDOR_AMD:
> --- a/xen/arch/x86/hvm/nestedhvm.c
> +++ b/xen/arch/x86/hvm/nestedhvm.c
> @@ -151,13 +151,15 @@ nestedhvm_is_n2(struct vcpu *v)
>  static int __init
>  nestedhvm_setup(void)
>  {
> -    /* Same format and size as hvm_io_bitmap (Intel needs only 2 pages). */
> -    unsigned int nr = (boot_cpu_data.x86_vendor == X86_VENDOR_INTEL) ? 2 : 3;
> -    unsigned int i, order = get_order_from_pages(nr);
> +    unsigned int i, nr, order;
>  
>      if ( !hvm_funcs.name )
>          return 0;
>  
> +    /* Same format and size as hvm_io_bitmap (VMX needs only 2 pages). */
> +    nr = !strcmp(hvm_funcs.name, "VMX") ? 2 : 3;
> +    order = get_order_from_pages(nr);
> +
>      /* shadow_io_bitmaps can't be declared static because
>       *   they must fulfill hw requirements (page aligned section)
>       *   and doing so triggers the ASSERT(va >= XEN_VIRT_START)
> --- a/xen/arch/x86/hvm/viridian.c
> +++ b/xen/arch/x86/hvm/viridian.c
> @@ -156,8 +156,7 @@ static void enable_hypercall_page(struct
>      *(u32 *)(p + 1) = 0x80000000;
>      *(u8  *)(p + 5) = 0x0f; /* vmcall/vmmcall */
>      *(u8  *)(p + 6) = 0x01;
> -    *(u8  *)(p + 7) = ((boot_cpu_data.x86_vendor == X86_VENDOR_INTEL)
> -                       ? 0xc1 : 0xd9);
> +    *(u8  *)(p + 7) = (!strcmp(hvm_funcs.name, "VMX") ? 0xc1 : 0xd9);
>      *(u8  *)(p + 8) = 0xc3; /* ret */
>      memset(p + 9, 0xcc, PAGE_SIZE - 9); /* int3, int3, ... */
>  
> --- a/xen/arch/x86/mm/mem_event.c
> +++ b/xen/arch/x86/mm/mem_event.c
> @@ -608,7 +608,7 @@ int mem_event_domctl(struct domain *d, x
>                  break;
>  
>              /* Currently only EPT is supported */
> -            if ( boot_cpu_data.x86_vendor != X86_VENDOR_INTEL )
> +            if ( strcmp(hvm_funcs.name, "VMX") )
>                  break;
>  
>              rc = mem_event_enable(d, mec, med, _VPF_mem_access,
> --- a/xen/arch/x86/mm/p2m.c
> +++ b/xen/arch/x86/mm/p2m.c
> @@ -83,7 +83,7 @@ static void p2m_initialise(struct domain
>  
>      p2m->cr3 = CR3_EADDR;
>  
> -    if ( hap_enabled(d) && (boot_cpu_data.x86_vendor == X86_VENDOR_INTEL) )
> +    if ( hap_enabled(d) && !strcmp(hvm_funcs.name, "VMX") )
>          ept_p2m_init(p2m);
>      else
>          p2m_pt_init(p2m);
> --- a/xen/arch/x86/x86_64/traps.c
> +++ b/xen/arch/x86/x86_64/traps.c
> @@ -399,7 +399,8 @@ void __devinit subarch_percpu_traps_init
>      wrmsrl(MSR_LSTAR, (unsigned long)stack);
>      stack += write_stack_trampoline(stack, stack_bottom, FLAT_KERNEL_CS64);
>  
> -    if ( boot_cpu_data.x86_vendor == X86_VENDOR_INTEL )
> +    if ( boot_cpu_data.x86_vendor == X86_VENDOR_INTEL ||
> +         boot_cpu_data.x86_vendor == X86_VENDOR_CENTAUR )
>      {
>          /* SYSENTER entry. */
>          wrmsrl(MSR_IA32_SYSENTER_ESP, (unsigned long)stack_bottom);
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Sep 21 12:56:43 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Sep 2012 12:56:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TF2mR-00053m-Bf; Fri, 21 Sep 2012 12:56: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 1TF2mP-00053W-Tc
	for xen-devel@lists.xen.org; Fri, 21 Sep 2012 12:56:26 +0000
Received: from [85.158.138.51:28316] by server-5.bemta-3.messagelabs.com id
	0E/BC-13133-9F36C505; Fri, 21 Sep 2012 12:56:25 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1348232158!23440535!2
X-Originating-IP: [209.85.215.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-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18523 invoked from network); 21 Sep 2012 12:56:24 -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 Sep 2012 12:56:24 -0000
Received: by mail-ey0-f173.google.com with SMTP id c13so1153819eaa.32
	for <xen-devel@lists.xen.org>; Fri, 21 Sep 2012 05:56:24 -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=73iLVeWd3MZ4wcPZMvnsEZolIEcOHUrq6D1rMeJBpQU=;
	b=czCreg0AhaxOMy6qd89Osc1dRN79/0bGy0TfFRxHnEubK1vr3uGeRH+XcB1nr493LJ
	VOyrmoEb7YFvcefK1Qn2oThriKgWflom58pf3xh/8F/Q7KmHhMVNm87q/vvuty4dRXbZ
	cD9qKg3AXpSb8w8sUtQg7GomvDzr8MPD8hu0MwiR8SajLQ6WkUfdndxXkx0GZ/TfWrfA
	99j/GKQyyAx7yX7TQUdN8CueH9cniqXsav+BRq0IMWZ6X5igp9hmB20MFUqLWDQAiC4m
	z2j5FcVzRfCm3PA9lfWwvSN2QV368rCRZ1Zbl7hAOtmWQMmkzsjv+GhGw2Pi6HBvPgho
	gdrQ==
Received: by 10.14.179.137 with SMTP id h9mr6211780eem.22.1348232184242;
	Fri, 21 Sep 2012 05:56:24 -0700 (PDT)
Received: from [192.168.1.69] (host86-167-82-156.range86-167.btcentralplus.com.
	[86.167.82.156])
	by mx.google.com with ESMTPS id u8sm23746564eel.11.2012.09.21.05.56.19
	(version=SSLv3 cipher=OTHER); Fri, 21 Sep 2012 05:56:23 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Fri, 21 Sep 2012 13:56:17 +0100
From: Keir Fraser <keir.xen@gmail.com>
To: Jan Beulich <JBeulich@suse.com>,
	xen-devel <xen-devel@lists.xen.org>
Message-ID: <CC822281.3F5F1%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [PATCH] x86: eliminate code affecting only
	64-bit-incapable CPUs
Thread-Index: Ac2X+H0X4RMFc2Jam0GkZYjcGRhezg==
In-Reply-To: <505C7262020000780009CF66@nat28.tlf.novell.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] [PATCH] x86: eliminate code affecting only
 64-bit-incapable CPUs
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/09/2012 12:57, "Jan Beulich" <JBeulich@suse.com> wrote:

> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Acked-by: Keir Fraser <keir@xen.org>

> --- a/xen/arch/x86/cpu/common.c
> +++ b/xen/arch/x86/cpu/common.c
> @@ -15,9 +15,6 @@
>  
>  #include "cpu.h"
>  
> -static int cachesize_override __cpuinitdata = -1;
> -size_param("cachesize", cachesize_override);
> -
>  static bool_t __cpuinitdata use_xsave = 1;
>  boolean_param("xsave", use_xsave);
>  
> @@ -120,17 +117,6 @@ void __cpuinit display_cacheinfo(struct
> ecx = cpuid_ecx(0x80000006);
> l2size = ecx >> 16;
> 
> - /* do processor-specific cache resizing */
> - if (this_cpu->c_size_cache)
> -  l2size = this_cpu->c_size_cache(c,l2size);
> -
> - /* Allow user to override all this if necessary. */
> - if (cachesize_override != -1)
> -  l2size = cachesize_override;
> -
> - if ( l2size == 0 )
> -  return;  /* Again, no L2 cache is possible */
> -
> c->x86_cache_size = l2size;
>  
> if (opt_cpu_info)
> @@ -138,32 +124,6 @@ void __cpuinit display_cacheinfo(struct
>       l2size, ecx & 0xFF);
>  }
>  
> -/* Naming convention should be: <Name> [(<Codename>)] */
> -/* This table only is used unless init_<vendor>() below doesn't set it; */
> -/* in particular, if CPUID levels 0x80000002..4 are supported, this isn't
> used */
> -
> -/* Look up CPU names by table lookup. */
> -static char __cpuinit *table_lookup_model(struct cpuinfo_x86 *c)
> -{
> - struct cpu_model_info *info;
> -
> - if ( c->x86_model >= 16 )
> -  return NULL; /* Range check */
> -
> - if (!this_cpu)
> -  return NULL;
> -
> - info = this_cpu->c_models;
> -
> - while (info && info->family) {
> -  if (info->family == c->x86)
> -   return info->model_names[c->x86_model];
> -  info++;
> - }
> - return NULL;  /* Not found */
> -}
> -
> -
>  static void __cpuinit get_cpu_vendor(struct cpuinfo_x86 *c, int early)
>  {
> char *v = c->x86_vendor_id;
> @@ -356,14 +316,9 @@ void __cpuinit identify_cpu(struct cpuin
>  
> /* If the model name is still unset, do table lookup. */
> if ( !c->x86_model_id[0] ) {
> -  char *p;
> -  p = table_lookup_model(c);
> -  if ( p )
> -   safe_strcpy(c->x86_model_id, p);
> -  else
> -   /* Last resort... */
> -   snprintf(c->x86_model_id, sizeof(c->x86_model_id),
> -    "%02x/%02x", c->x86_vendor, c->x86_model);
> +  /* Last resort... */
> +  snprintf(c->x86_model_id, sizeof(c->x86_model_id),
> +   "%02x/%02x", c->x86_vendor, c->x86_model);
> }
>  
> /* Now the feature flags better reflect actual CPU features! */
> --- a/xen/arch/x86/cpu/cpu.h
> +++ b/xen/arch/x86/cpu/cpu.h
> @@ -1,10 +1,3 @@
> -
> -struct cpu_model_info {
> - int vendor;
> - int family;
> - char *model_names[16];
> -};
> -
>  /* attempt to consolidate cpu attributes */
>  struct cpu_dev {
> char * c_vendor;
> @@ -12,11 +5,8 @@ struct cpu_dev {
> /* some have two possibilities for cpuid string */
> char * c_ident[2]; 
>  
> - struct  cpu_model_info c_models[4];
> -
> void  (*c_init)(struct cpuinfo_x86 * c);
> void  (*c_identify)(struct cpuinfo_x86 * c);
> - unsigned int (*c_size_cache)(struct cpuinfo_x86 * c, unsigned int size);
>  };
>  
>  extern struct cpu_dev * cpu_devs [X86_VENDOR_NUM];
> --- a/xen/arch/x86/cpu/intel.c
> +++ b/xen/arch/x86/cpu/intel.c
> @@ -292,49 +292,10 @@ static void __devinit init_intel(struct
> set_bit(X86_FEATURE_ARAT, c->x86_capability);
>  }
>  
> -
> -static unsigned int intel_size_cache(struct cpuinfo_x86 * c, unsigned int
> size)
> -{
> - /* Intel PIII Tualatin. This comes in two flavours.
> -  * One has 256kb of cache, the other 512. We have no way
> -  * to determine which, so we use a boottime override
> -  * for the 512kb model, and assume 256 otherwise.
> -  */
> - if ((c->x86 == 6) && (c->x86_model == 11) && (size == 0))
> -  size = 256;
> - return size;
> -}
> -
>  static struct cpu_dev intel_cpu_dev __cpuinitdata = {
> .c_vendor = "Intel",
> .c_ident  = { "GenuineIntel" },
> - .c_models = {
> -  { .vendor = X86_VENDOR_INTEL, .family = 6, .model_names =
> -    { 
> -     [0] = "Pentium Pro A-step",
> -     [1] = "Pentium Pro",
> -     [3] = "Pentium II (Klamath)",
> -     [4] = "Pentium II (Deschutes)",
> -     [5] = "Pentium II (Deschutes)",
> -     [6] = "Mobile Pentium II",
> -     [7] = "Pentium III (Katmai)",
> -     [8] = "Pentium III (Coppermine)",
> -     [10] = "Pentium III (Cascades)",
> -     [11] = "Pentium III (Tualatin)",
> -    }
> -  },
> -  { .vendor = X86_VENDOR_INTEL, .family = 15, .model_names =
> -    {
> -     [0] = "Pentium 4 (Unknown)",
> -     [1] = "Pentium 4 (Willamette)",
> -     [2] = "Pentium 4 (Northwood)",
> -     [4] = "Pentium 4 (Foster)",
> -     [5] = "Pentium 4 (Foster)",
> -    }
> -  },
> - },
> .c_init  = init_intel,
> - .c_size_cache = intel_size_cache,
>  };
>  
>  int __init intel_cpu_init(void)
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 21 12:56:43 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Sep 2012 12:56:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TF2mR-00053m-Bf; Fri, 21 Sep 2012 12:56: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 1TF2mP-00053W-Tc
	for xen-devel@lists.xen.org; Fri, 21 Sep 2012 12:56:26 +0000
Received: from [85.158.138.51:28316] by server-5.bemta-3.messagelabs.com id
	0E/BC-13133-9F36C505; Fri, 21 Sep 2012 12:56:25 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1348232158!23440535!2
X-Originating-IP: [209.85.215.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-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18523 invoked from network); 21 Sep 2012 12:56:24 -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 Sep 2012 12:56:24 -0000
Received: by mail-ey0-f173.google.com with SMTP id c13so1153819eaa.32
	for <xen-devel@lists.xen.org>; Fri, 21 Sep 2012 05:56:24 -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=73iLVeWd3MZ4wcPZMvnsEZolIEcOHUrq6D1rMeJBpQU=;
	b=czCreg0AhaxOMy6qd89Osc1dRN79/0bGy0TfFRxHnEubK1vr3uGeRH+XcB1nr493LJ
	VOyrmoEb7YFvcefK1Qn2oThriKgWflom58pf3xh/8F/Q7KmHhMVNm87q/vvuty4dRXbZ
	cD9qKg3AXpSb8w8sUtQg7GomvDzr8MPD8hu0MwiR8SajLQ6WkUfdndxXkx0GZ/TfWrfA
	99j/GKQyyAx7yX7TQUdN8CueH9cniqXsav+BRq0IMWZ6X5igp9hmB20MFUqLWDQAiC4m
	z2j5FcVzRfCm3PA9lfWwvSN2QV368rCRZ1Zbl7hAOtmWQMmkzsjv+GhGw2Pi6HBvPgho
	gdrQ==
Received: by 10.14.179.137 with SMTP id h9mr6211780eem.22.1348232184242;
	Fri, 21 Sep 2012 05:56:24 -0700 (PDT)
Received: from [192.168.1.69] (host86-167-82-156.range86-167.btcentralplus.com.
	[86.167.82.156])
	by mx.google.com with ESMTPS id u8sm23746564eel.11.2012.09.21.05.56.19
	(version=SSLv3 cipher=OTHER); Fri, 21 Sep 2012 05:56:23 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Fri, 21 Sep 2012 13:56:17 +0100
From: Keir Fraser <keir.xen@gmail.com>
To: Jan Beulich <JBeulich@suse.com>,
	xen-devel <xen-devel@lists.xen.org>
Message-ID: <CC822281.3F5F1%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [PATCH] x86: eliminate code affecting only
	64-bit-incapable CPUs
Thread-Index: Ac2X+H0X4RMFc2Jam0GkZYjcGRhezg==
In-Reply-To: <505C7262020000780009CF66@nat28.tlf.novell.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] [PATCH] x86: eliminate code affecting only
 64-bit-incapable CPUs
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/09/2012 12:57, "Jan Beulich" <JBeulich@suse.com> wrote:

> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Acked-by: Keir Fraser <keir@xen.org>

> --- a/xen/arch/x86/cpu/common.c
> +++ b/xen/arch/x86/cpu/common.c
> @@ -15,9 +15,6 @@
>  
>  #include "cpu.h"
>  
> -static int cachesize_override __cpuinitdata = -1;
> -size_param("cachesize", cachesize_override);
> -
>  static bool_t __cpuinitdata use_xsave = 1;
>  boolean_param("xsave", use_xsave);
>  
> @@ -120,17 +117,6 @@ void __cpuinit display_cacheinfo(struct
> ecx = cpuid_ecx(0x80000006);
> l2size = ecx >> 16;
> 
> - /* do processor-specific cache resizing */
> - if (this_cpu->c_size_cache)
> -  l2size = this_cpu->c_size_cache(c,l2size);
> -
> - /* Allow user to override all this if necessary. */
> - if (cachesize_override != -1)
> -  l2size = cachesize_override;
> -
> - if ( l2size == 0 )
> -  return;  /* Again, no L2 cache is possible */
> -
> c->x86_cache_size = l2size;
>  
> if (opt_cpu_info)
> @@ -138,32 +124,6 @@ void __cpuinit display_cacheinfo(struct
>       l2size, ecx & 0xFF);
>  }
>  
> -/* Naming convention should be: <Name> [(<Codename>)] */
> -/* This table only is used unless init_<vendor>() below doesn't set it; */
> -/* in particular, if CPUID levels 0x80000002..4 are supported, this isn't
> used */
> -
> -/* Look up CPU names by table lookup. */
> -static char __cpuinit *table_lookup_model(struct cpuinfo_x86 *c)
> -{
> - struct cpu_model_info *info;
> -
> - if ( c->x86_model >= 16 )
> -  return NULL; /* Range check */
> -
> - if (!this_cpu)
> -  return NULL;
> -
> - info = this_cpu->c_models;
> -
> - while (info && info->family) {
> -  if (info->family == c->x86)
> -   return info->model_names[c->x86_model];
> -  info++;
> - }
> - return NULL;  /* Not found */
> -}
> -
> -
>  static void __cpuinit get_cpu_vendor(struct cpuinfo_x86 *c, int early)
>  {
> char *v = c->x86_vendor_id;
> @@ -356,14 +316,9 @@ void __cpuinit identify_cpu(struct cpuin
>  
> /* If the model name is still unset, do table lookup. */
> if ( !c->x86_model_id[0] ) {
> -  char *p;
> -  p = table_lookup_model(c);
> -  if ( p )
> -   safe_strcpy(c->x86_model_id, p);
> -  else
> -   /* Last resort... */
> -   snprintf(c->x86_model_id, sizeof(c->x86_model_id),
> -    "%02x/%02x", c->x86_vendor, c->x86_model);
> +  /* Last resort... */
> +  snprintf(c->x86_model_id, sizeof(c->x86_model_id),
> +   "%02x/%02x", c->x86_vendor, c->x86_model);
> }
>  
> /* Now the feature flags better reflect actual CPU features! */
> --- a/xen/arch/x86/cpu/cpu.h
> +++ b/xen/arch/x86/cpu/cpu.h
> @@ -1,10 +1,3 @@
> -
> -struct cpu_model_info {
> - int vendor;
> - int family;
> - char *model_names[16];
> -};
> -
>  /* attempt to consolidate cpu attributes */
>  struct cpu_dev {
> char * c_vendor;
> @@ -12,11 +5,8 @@ struct cpu_dev {
> /* some have two possibilities for cpuid string */
> char * c_ident[2]; 
>  
> - struct  cpu_model_info c_models[4];
> -
> void  (*c_init)(struct cpuinfo_x86 * c);
> void  (*c_identify)(struct cpuinfo_x86 * c);
> - unsigned int (*c_size_cache)(struct cpuinfo_x86 * c, unsigned int size);
>  };
>  
>  extern struct cpu_dev * cpu_devs [X86_VENDOR_NUM];
> --- a/xen/arch/x86/cpu/intel.c
> +++ b/xen/arch/x86/cpu/intel.c
> @@ -292,49 +292,10 @@ static void __devinit init_intel(struct
> set_bit(X86_FEATURE_ARAT, c->x86_capability);
>  }
>  
> -
> -static unsigned int intel_size_cache(struct cpuinfo_x86 * c, unsigned int
> size)
> -{
> - /* Intel PIII Tualatin. This comes in two flavours.
> -  * One has 256kb of cache, the other 512. We have no way
> -  * to determine which, so we use a boottime override
> -  * for the 512kb model, and assume 256 otherwise.
> -  */
> - if ((c->x86 == 6) && (c->x86_model == 11) && (size == 0))
> -  size = 256;
> - return size;
> -}
> -
>  static struct cpu_dev intel_cpu_dev __cpuinitdata = {
> .c_vendor = "Intel",
> .c_ident  = { "GenuineIntel" },
> - .c_models = {
> -  { .vendor = X86_VENDOR_INTEL, .family = 6, .model_names =
> -    { 
> -     [0] = "Pentium Pro A-step",
> -     [1] = "Pentium Pro",
> -     [3] = "Pentium II (Klamath)",
> -     [4] = "Pentium II (Deschutes)",
> -     [5] = "Pentium II (Deschutes)",
> -     [6] = "Mobile Pentium II",
> -     [7] = "Pentium III (Katmai)",
> -     [8] = "Pentium III (Coppermine)",
> -     [10] = "Pentium III (Cascades)",
> -     [11] = "Pentium III (Tualatin)",
> -    }
> -  },
> -  { .vendor = X86_VENDOR_INTEL, .family = 15, .model_names =
> -    {
> -     [0] = "Pentium 4 (Unknown)",
> -     [1] = "Pentium 4 (Willamette)",
> -     [2] = "Pentium 4 (Northwood)",
> -     [4] = "Pentium 4 (Foster)",
> -     [5] = "Pentium 4 (Foster)",
> -    }
> -  },
> - },
> .c_init  = init_intel,
> - .c_size_cache = intel_size_cache,
>  };
>  
>  int __init intel_cpu_init(void)
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 21 12:57:01 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Sep 2012 12:57:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TF2mk-000568-P1; Fri, 21 Sep 2012 12:56:46 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1TF2mj-00055l-8j
	for xen-devel@lists.xen.org; Fri, 21 Sep 2012 12:56:45 +0000
Received: from [85.158.143.35:22848] by server-3.bemta-4.messagelabs.com id
	11/0D-10986-C046C505; Fri, 21 Sep 2012 12:56:44 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1348232203!19309395!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-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23019 invoked from network); 21 Sep 2012 12:56:44 -0000
Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com)
	(74.125.83.45)
	by server-6.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Sep 2012 12:56:44 -0000
Received: by eeke53 with SMTP id e53so1563197eek.32
	for <xen-devel@lists.xen.org>; Fri, 21 Sep 2012 05:56:43 -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=daTt7ZENr7ytVz7+22QeJydnczCGOf4dvXrMXz3KPiU=;
	b=IPcQ1Ehl4VQeiLJq4ZRu0/PsHD/vw24C7h46544Bm3jF/mcCfJYMFilDuKqt2uwcHw
	gO2ifqeL4+IVXVn3n+AcsPdTSJiuhjo3OwvKhqHcffCCxR/rcRMaZkhTlN6tbpqRZHpT
	u2W0TFdcu6mQezgV8ppq0hxfvfWQVe3cNNmDlr1jlZBfXvHbXB077kPweG4Qma3Ckzcy
	rhPuurP284OA0Rh3sWA/z03jA3jNHGSJOKTTlHIyweiuT3WTO6Qcmho+RE5L0Eg8Glbh
	vVc9v8BAyJPLC1y1hXjgRnngWVUTw9eHdkazpYJLPngVYW+O/xwIC/uKja4VTqr35Mqk
	PCMg==
Received: by 10.14.180.65 with SMTP id i41mr6153750eem.10.1348232203584;
	Fri, 21 Sep 2012 05:56:43 -0700 (PDT)
Received: from [192.168.1.69] (host86-167-82-156.range86-167.btcentralplus.com.
	[86.167.82.156])
	by mx.google.com with ESMTPS id k41sm23734266eep.13.2012.09.21.05.56.42
	(version=SSLv3 cipher=OTHER); Fri, 21 Sep 2012 05:56:43 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Fri, 21 Sep 2012 13:56:41 +0100
From: Keir Fraser <keir.xen@gmail.com>
To: Jan Beulich <JBeulich@suse.com>,
	xen-devel <xen-devel@lists.xen.org>
Message-ID: <CC822299.3F5F2%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [PATCH 0/4] x86: assembly improvements
Thread-Index: Ac2X+ItlrGeRZfdfe0yXiVWsw9oqEw==
In-Reply-To: <505C76EB020000780009CF8B@nat28.tlf.novell.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] [PATCH 0/4] x86: assembly improvements
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 21/09/2012 13:17, "Jan Beulich" <JBeulich@suse.com> wrote:

> 1: enhance rsp-relative calculations
> 2: use compiler visible "add" instead of inline assembly "or" in
> get_cpu_info()
> 3: slightly streamline __prepare_to_wait() inline assembly
> 4: clean up interrupt stub generation
> 
> Note that some of this may look less worthwhile now that the
> unification of 32- and 64-bit code isn't an aspect anymore, but
> I think the net result is still an improvement, so I decided to
> retain and post these patches unchanged (apart from dropping
> the 32-bit specific pieces).
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

I don't see anything really contentious here.

Acked-by: Keir Fraser <keir@xen.org>

> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 21 12:57:01 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Sep 2012 12:57:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TF2mk-000568-P1; Fri, 21 Sep 2012 12:56:46 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1TF2mj-00055l-8j
	for xen-devel@lists.xen.org; Fri, 21 Sep 2012 12:56:45 +0000
Received: from [85.158.143.35:22848] by server-3.bemta-4.messagelabs.com id
	11/0D-10986-C046C505; Fri, 21 Sep 2012 12:56:44 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1348232203!19309395!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-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23019 invoked from network); 21 Sep 2012 12:56:44 -0000
Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com)
	(74.125.83.45)
	by server-6.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Sep 2012 12:56:44 -0000
Received: by eeke53 with SMTP id e53so1563197eek.32
	for <xen-devel@lists.xen.org>; Fri, 21 Sep 2012 05:56:43 -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=daTt7ZENr7ytVz7+22QeJydnczCGOf4dvXrMXz3KPiU=;
	b=IPcQ1Ehl4VQeiLJq4ZRu0/PsHD/vw24C7h46544Bm3jF/mcCfJYMFilDuKqt2uwcHw
	gO2ifqeL4+IVXVn3n+AcsPdTSJiuhjo3OwvKhqHcffCCxR/rcRMaZkhTlN6tbpqRZHpT
	u2W0TFdcu6mQezgV8ppq0hxfvfWQVe3cNNmDlr1jlZBfXvHbXB077kPweG4Qma3Ckzcy
	rhPuurP284OA0Rh3sWA/z03jA3jNHGSJOKTTlHIyweiuT3WTO6Qcmho+RE5L0Eg8Glbh
	vVc9v8BAyJPLC1y1hXjgRnngWVUTw9eHdkazpYJLPngVYW+O/xwIC/uKja4VTqr35Mqk
	PCMg==
Received: by 10.14.180.65 with SMTP id i41mr6153750eem.10.1348232203584;
	Fri, 21 Sep 2012 05:56:43 -0700 (PDT)
Received: from [192.168.1.69] (host86-167-82-156.range86-167.btcentralplus.com.
	[86.167.82.156])
	by mx.google.com with ESMTPS id k41sm23734266eep.13.2012.09.21.05.56.42
	(version=SSLv3 cipher=OTHER); Fri, 21 Sep 2012 05:56:43 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Fri, 21 Sep 2012 13:56:41 +0100
From: Keir Fraser <keir.xen@gmail.com>
To: Jan Beulich <JBeulich@suse.com>,
	xen-devel <xen-devel@lists.xen.org>
Message-ID: <CC822299.3F5F2%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [PATCH 0/4] x86: assembly improvements
Thread-Index: Ac2X+ItlrGeRZfdfe0yXiVWsw9oqEw==
In-Reply-To: <505C76EB020000780009CF8B@nat28.tlf.novell.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] [PATCH 0/4] x86: assembly improvements
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 21/09/2012 13:17, "Jan Beulich" <JBeulich@suse.com> wrote:

> 1: enhance rsp-relative calculations
> 2: use compiler visible "add" instead of inline assembly "or" in
> get_cpu_info()
> 3: slightly streamline __prepare_to_wait() inline assembly
> 4: clean up interrupt stub generation
> 
> Note that some of this may look less worthwhile now that the
> unification of 32- and 64-bit code isn't an aspect anymore, but
> I think the net result is still an improvement, so I decided to
> retain and post these patches unchanged (apart from dropping
> the 32-bit specific pieces).
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

I don't see anything really contentious here.

Acked-by: Keir Fraser <keir@xen.org>

> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 21 13:14:46 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Sep 2012 13:14:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TF33x-0006Do-Mj; Fri, 21 Sep 2012 13:14:33 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <techno.geek.0x01@gmail.com>) id 1TF31k-00066v-3T
	for xen-devel@lists.xen.org; Fri, 21 Sep 2012 13:12:16 +0000
Received: from [85.158.139.211:65018] by server-16.bemta-5.messagelabs.com id
	10/34-11718-FA76C505; Fri, 21 Sep 2012 13:12:15 +0000
X-Env-Sender: techno.geek.0x01@gmail.com
X-Msg-Ref: server-3.tower-206.messagelabs.com!1348233134!19453421!1
X-Originating-IP: [74.125.82.41]
X-SpamReason: No, hits=0.9 required=7.0 tests=HTML_40_50,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28506 invoked from network); 21 Sep 2012 13:12:14 -0000
Received: from mail-wg0-f41.google.com (HELO mail-wg0-f41.google.com)
	(74.125.82.41)
	by server-3.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Sep 2012 13:12:14 -0000
Received: by wgbds1 with SMTP id ds1so1165754wgb.2
	for <xen-devel@lists.xen.org>; Fri, 21 Sep 2012 06:12:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:date:message-id:subject:from:to:content-type;
	bh=Z0qqd/VCbHjdEzyqBJQxceeGZdX8lecXMEPNCsIGpSs=;
	b=zRmiNdB2TT057fgyfVQgrH2ALS+2+gtLDID2IuzmCZKH1y0GvB+fM20O3rYwO3DUFk
	+uMR/zrfH9fHt0kkii5qe6ez7rn221nwzHgl6erG/Bx7ZPHH0r6LeUJbFY8aHb/j3Tac
	E9MK8AqhErTD+AEE/iq0p7gLMasYowvQtUGvi15zf2nYKtHGogklSE7sDGSSxIDwR5WS
	86BuoTuvPfgLW0jx03sl/yLdeJ7VYn8QHwSwVU+ARWOJjzBzrG8D8ZkRJWI28QTXRMJm
	qm/Lb7/s00cZ9Sq5go3mf7nhPJS17Nfh6PO032j4Uo97/oRjsqCLMukIyJXqW8yHQxFY
	mc3A==
MIME-Version: 1.0
Received: by 10.180.105.130 with SMTP id gm2mr4522098wib.6.1348233134384; Fri,
	21 Sep 2012 06:12:14 -0700 (PDT)
Received: by 10.216.162.131 with HTTP; Fri, 21 Sep 2012 06:12:14 -0700 (PDT)
Date: Fri, 21 Sep 2012 21:12:14 +0800
Message-ID: <CALHMb0dTaR0NCQ1XdfrZ00NXGe0DpKXMNAG0vvZrpNMkLxti6A@mail.gmail.com>
From: Yaogun Wen <techno.geek.0x01@gmail.com>
To: xen-devel@lists.xen.org
X-Mailman-Approved-At: Fri, 21 Sep 2012 13:14:32 +0000
Subject: [Xen-devel] The use of evtchn_upcall_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: multipart/mixed; boundary="===============6683055506675510964=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============6683055506675510964==
Content-Type: multipart/alternative; boundary=f46d044281040ca73b04ca35fd1b

--f46d044281040ca73b04ca35fd1b
Content-Type: text/plain; charset=ISO-8859-1

Hi, everyone
When I trace code of hypervisor, I can't find the use of evtchn_upcall_mask.
As the comment in include/public/xen.h, evtchn_upcall_mask is read before
making an event upcall to the guest.
After I search the mailing lists, I find the following changelog:

[XEN] Replace direct common-code access of evtchn_upcall_mask with
local_event_delivery_*
accessors.<http://xen.markmail.org/message/4ushwnkx6mhlcz42?q=evtchn_set_pending&page=18>
diff -r ea4829e30092 -r ddc25d4ebf60 xen/common/event_channel.c ---
a/xen/common/event_channel.c Sat Jun 10 11:05:11 2006 +0100 +++
b/xen/common/event_channel.c Sat Jun 10 11:07:11 2006 +0100 @@ -499,7
+499,7 @@ void evtchn_set_pending(struct vcpu *v, evtchn_notify(v); } else
if ( unlikely(test_bit(_VCPUF_blocked, &v->vcpu_flags) && - v->vcpu_info->*
evtchn_upcall_mask*) ) + !local_event_delivery_is_enabled()) )

[XEN] Fix SCHEDOP_poll to work even when event channels are not bound to
the polling VCPU.<http://xen.markmail.org/search/?q=local_event_delivery_is_enabled#query:local_event_delivery_is_enabled%20order%3Adate-backward+page:2+mid:pjznbfjzcp4sw33d+state:results>
diff -r d7543cff88ae -r aced0ee216aa xen/common/event_channel.c ---
a/xen/common/event_channel.c Sun Jun 11 14:33:16 2006 +0100 +++
b/xen/common/event_channel.c Sun Jun 11 19:23:31 2006 +0100 @@ -498,14
+498,14 @@ void evtchn_set_pending(struct vcpu *v, { evtchn_notify(v); } -
else if ( unlikely(test_bit(_VCPUF_blocked, &v->vcpu_flags) && - *!
local_event_delivery_is_enabled*()) ) - { - /* - * Blocked and masked will
usually mean that the VCPU executed - * SCHEDOP_poll. Kick the VCPU in case
this port is in its poll list. - */ - vcpu_unblock(v); + + /* Check if some
VCPU might be polling for this event. */ + if (
unlikely(test_bit(_DOMF_polling, &d->domain_flags)) && +
likely(test_and_clear_bit(_DOMF_polling, &d->domain_flags)) ) + { +
for_each_vcpu ( d, v ) + if ( test_and_clear_bit(_VCPUF_polling,
&v->vcpu_flags) ) + vcpu_unblock(v); } }

I think evtchn_set_pending() is the function to decide whether to make an
event upcall to the guest, and the first patch is the last patch which I
see evtchn_upcall_mask in evtchn_set_pending().
I also find that local_event_delivery_is_enabled() is not used in
hypervisor.
I don't know if i understand this part correctly, it seems
that evtchn_upcall_mask is useless.
Can somebody tell me the use of evtchn_upcall_mask?
Any suggestions will be greatly appreciated, thanks in advance.

-- 
Best regards,

Yao-Jing Wen

--f46d044281040ca73b04ca35fd1b
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi, everyone<div>When I trace code of hypervisor, I can&#39;t find the use =
of=A0evtchn_upcall_mask.</div><div>As the comment in include/public/xen.h,=
=A0evtchn_upcall_mask is read=A0before making an event upcall to the guest.=
</div>


<div>After I search the mailing lists, I find the following changelog:</div=
><div><br></div><div><span style=3D"font-size:14px;white-space:pre-wrap;fon=
t-family:Arial,Helvetica,&#39;Luxi Sans&#39;,sans-serif"><a href=3D"http://=
xen.markmail.org/message/4ushwnkx6mhlcz42?q=3Devtchn_set_pending&amp;page=
=3D18" target=3D"_blank">[XEN] Replace direct common-code access of evtchn_=
upcall_mask with local_event_delivery_* accessors.</a></span></div>


<div><span style=3D"font-family:Arial,Helvetica,&#39;Luxi Sans&#39;,sans-se=
rif;font-size:14px;white-space:pre-wrap"><span>diff -r ea4829e30092 -r ddc2=
5d4ebf60 xen/common/event_channel.c
--- a/xen/common/event_channel.c	Sat Jun 10 11:05:11 2006 +0100
+++ b/xen/common/event_channel.c	Sat Jun 10 11:07:11 2006 +0100
@@ -499,7 +499,7 @@ void </span><span style=3D"padding-left:2px;padding-rig=
ht:2px;padding-top:2px;padding-bottom:2px">evtchn_set_pending</span><span>(=
struct vcpu *v,=20
         evtchn_notify(v);
     }
     else if ( unlikely(test_bit(_VCPUF_blocked, &amp;v-&gt;vcpu_flags) &am=
p;&amp;
-                       v-&gt;vcpu_info-&gt;<b><i>evtchn_upcall_mask</i></b=
>) )
+                       !local_event_delivery_is_enabled()) )</span></span>=
<font face=3D"Arial, Helvetica, &#39;Luxi Sans&#39;, sans-serif"><span styl=
e=3D"font-size:14px;white-space:pre-wrap"><br clear=3D"all">
</span></font><div><br></div><div><span style=3D"font-size:14px;white-space=
:pre-wrap;font-family:Arial,Helvetica,&#39;Luxi Sans&#39;,sans-serif"><a hr=
ef=3D"http://xen.markmail.org/search/?q=3Dlocal_event_delivery_is_enabled#q=
uery:local_event_delivery_is_enabled%20order%3Adate-backward+page:2+mid:pjz=
nbfjzcp4sw33d+state:results" target=3D"_blank">[XEN] Fix SCHEDOP_poll to wo=
rk even when event channels are not bound to the polling VCPU.</a></span></=
div>


<div><span style=3D"font-size:14px;white-space:pre-wrap;font-family:Arial,H=
elvetica,&#39;Luxi Sans&#39;,sans-serif">diff -r d7543cff88ae -r aced0ee216=
aa xen/common/event_channel.c
--- a/xen/common/event_channel.c	Sun Jun 11 14:33:16 2006 +0100
+++ b/xen/common/event_channel.c	Sun Jun 11 19:23:31 2006 +0100
@@ -498,14 +498,14 @@ void evtchn_set_pending(struct vcpu *v,=20
     {
         evtchn_notify(v);
     }
-    else if ( unlikely(test_bit(_VCPUF_blocked, &amp;v-&gt;vcpu_flags) &am=
p;&amp;
-                      </span><span style=3D"font-size:14px;white-space:pre=
-wrap;font-family:Arial,Helvetica,&#39;Luxi Sans&#39;,sans-serif"> <b><i>!<=
span style=3D"padding-top:2px;padding-right:2px;padding-bottom:2px;padding-=
left:2px">local_event_delivery_is_enabled</span></i></b>(</span><span style=
=3D"font-size:14px;white-space:pre-wrap;font-family:Arial,Helvetica,&#39;Lu=
xi Sans&#39;,sans-serif">)) )
-    {
-        /*
-         * Blocked and masked will usually mean that the VCPU executed=20
-         * SCHEDOP_poll. Kick the VCPU in case this port is in its poll li=
st.
-         */
-        vcpu_unblock(v);
+   =20
+    /* Check if some VCPU might be polling for this event. */
+    if ( unlikely(test_bit(_DOMF_polling, &amp;d-&gt;domain_flags)) &amp;&=
amp;
+         likely(test_and_clear_bit(_DOMF_polling, &amp;d-&gt;domain_flags)=
) )
+    {
+        for_each_vcpu ( d, v )
+            if ( test_and_clear_bit(_VCPUF_polling, &amp;v-&gt;vcpu_flags)=
 )
+                vcpu_unblock(v);
     }
 }</span></div><div><br></div><div>I think=A0<span style=3D"font-size:14px;=
white-space:pre-wrap;font-family:Arial,Helvetica,&#39;Luxi Sans&#39;,sans-s=
erif">evtchn_set_pending() is the function to decide whether to make=A0</sp=
an>an event upcall to the guest, and the first patch is the last patch whic=
h I see=A0evtchn_upcall_mask in=A0<span style=3D"font-size:14px;white-space=
:pre-wrap;font-family:Arial,Helvetica,&#39;Luxi Sans&#39;,sans-serif">evtch=
n_set_pending()</span>.</div>


<div>I also find that=A0local_event_delivery_is_enabled() is not used in hy=
pervisor.</div><div>I don&#39;t know if i understand this part correctly, i=
t seems that=A0evtchn_upcall_mask is useless.</div><div>Can somebody tell m=
e the use of evtchn_upcall_mask?</div>
<div><span class=3D"Apple-style-span" style=3D"color:rgb(34,34,34);font-fam=
ily:arial,sans-serif;font-size:13px;background-color:rgb(255,255,255)">Any =
suggestions will be greatly appreciated, thanks in advance.</span></div>
<div><br></div>-- <br>Best regards,<br><br>Yao-Jing Wen<br>
</div>

--f46d044281040ca73b04ca35fd1b--


--===============6683055506675510964==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============6683055506675510964==--


From xen-devel-bounces@lists.xen.org Fri Sep 21 13:14:46 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Sep 2012 13:14:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TF33x-0006Do-Mj; Fri, 21 Sep 2012 13:14:33 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <techno.geek.0x01@gmail.com>) id 1TF31k-00066v-3T
	for xen-devel@lists.xen.org; Fri, 21 Sep 2012 13:12:16 +0000
Received: from [85.158.139.211:65018] by server-16.bemta-5.messagelabs.com id
	10/34-11718-FA76C505; Fri, 21 Sep 2012 13:12:15 +0000
X-Env-Sender: techno.geek.0x01@gmail.com
X-Msg-Ref: server-3.tower-206.messagelabs.com!1348233134!19453421!1
X-Originating-IP: [74.125.82.41]
X-SpamReason: No, hits=0.9 required=7.0 tests=HTML_40_50,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28506 invoked from network); 21 Sep 2012 13:12:14 -0000
Received: from mail-wg0-f41.google.com (HELO mail-wg0-f41.google.com)
	(74.125.82.41)
	by server-3.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Sep 2012 13:12:14 -0000
Received: by wgbds1 with SMTP id ds1so1165754wgb.2
	for <xen-devel@lists.xen.org>; Fri, 21 Sep 2012 06:12:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:date:message-id:subject:from:to:content-type;
	bh=Z0qqd/VCbHjdEzyqBJQxceeGZdX8lecXMEPNCsIGpSs=;
	b=zRmiNdB2TT057fgyfVQgrH2ALS+2+gtLDID2IuzmCZKH1y0GvB+fM20O3rYwO3DUFk
	+uMR/zrfH9fHt0kkii5qe6ez7rn221nwzHgl6erG/Bx7ZPHH0r6LeUJbFY8aHb/j3Tac
	E9MK8AqhErTD+AEE/iq0p7gLMasYowvQtUGvi15zf2nYKtHGogklSE7sDGSSxIDwR5WS
	86BuoTuvPfgLW0jx03sl/yLdeJ7VYn8QHwSwVU+ARWOJjzBzrG8D8ZkRJWI28QTXRMJm
	qm/Lb7/s00cZ9Sq5go3mf7nhPJS17Nfh6PO032j4Uo97/oRjsqCLMukIyJXqW8yHQxFY
	mc3A==
MIME-Version: 1.0
Received: by 10.180.105.130 with SMTP id gm2mr4522098wib.6.1348233134384; Fri,
	21 Sep 2012 06:12:14 -0700 (PDT)
Received: by 10.216.162.131 with HTTP; Fri, 21 Sep 2012 06:12:14 -0700 (PDT)
Date: Fri, 21 Sep 2012 21:12:14 +0800
Message-ID: <CALHMb0dTaR0NCQ1XdfrZ00NXGe0DpKXMNAG0vvZrpNMkLxti6A@mail.gmail.com>
From: Yaogun Wen <techno.geek.0x01@gmail.com>
To: xen-devel@lists.xen.org
X-Mailman-Approved-At: Fri, 21 Sep 2012 13:14:32 +0000
Subject: [Xen-devel] The use of evtchn_upcall_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: multipart/mixed; boundary="===============6683055506675510964=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============6683055506675510964==
Content-Type: multipart/alternative; boundary=f46d044281040ca73b04ca35fd1b

--f46d044281040ca73b04ca35fd1b
Content-Type: text/plain; charset=ISO-8859-1

Hi, everyone
When I trace code of hypervisor, I can't find the use of evtchn_upcall_mask.
As the comment in include/public/xen.h, evtchn_upcall_mask is read before
making an event upcall to the guest.
After I search the mailing lists, I find the following changelog:

[XEN] Replace direct common-code access of evtchn_upcall_mask with
local_event_delivery_*
accessors.<http://xen.markmail.org/message/4ushwnkx6mhlcz42?q=evtchn_set_pending&page=18>
diff -r ea4829e30092 -r ddc25d4ebf60 xen/common/event_channel.c ---
a/xen/common/event_channel.c Sat Jun 10 11:05:11 2006 +0100 +++
b/xen/common/event_channel.c Sat Jun 10 11:07:11 2006 +0100 @@ -499,7
+499,7 @@ void evtchn_set_pending(struct vcpu *v, evtchn_notify(v); } else
if ( unlikely(test_bit(_VCPUF_blocked, &v->vcpu_flags) && - v->vcpu_info->*
evtchn_upcall_mask*) ) + !local_event_delivery_is_enabled()) )

[XEN] Fix SCHEDOP_poll to work even when event channels are not bound to
the polling VCPU.<http://xen.markmail.org/search/?q=local_event_delivery_is_enabled#query:local_event_delivery_is_enabled%20order%3Adate-backward+page:2+mid:pjznbfjzcp4sw33d+state:results>
diff -r d7543cff88ae -r aced0ee216aa xen/common/event_channel.c ---
a/xen/common/event_channel.c Sun Jun 11 14:33:16 2006 +0100 +++
b/xen/common/event_channel.c Sun Jun 11 19:23:31 2006 +0100 @@ -498,14
+498,14 @@ void evtchn_set_pending(struct vcpu *v, { evtchn_notify(v); } -
else if ( unlikely(test_bit(_VCPUF_blocked, &v->vcpu_flags) && - *!
local_event_delivery_is_enabled*()) ) - { - /* - * Blocked and masked will
usually mean that the VCPU executed - * SCHEDOP_poll. Kick the VCPU in case
this port is in its poll list. - */ - vcpu_unblock(v); + + /* Check if some
VCPU might be polling for this event. */ + if (
unlikely(test_bit(_DOMF_polling, &d->domain_flags)) && +
likely(test_and_clear_bit(_DOMF_polling, &d->domain_flags)) ) + { +
for_each_vcpu ( d, v ) + if ( test_and_clear_bit(_VCPUF_polling,
&v->vcpu_flags) ) + vcpu_unblock(v); } }

I think evtchn_set_pending() is the function to decide whether to make an
event upcall to the guest, and the first patch is the last patch which I
see evtchn_upcall_mask in evtchn_set_pending().
I also find that local_event_delivery_is_enabled() is not used in
hypervisor.
I don't know if i understand this part correctly, it seems
that evtchn_upcall_mask is useless.
Can somebody tell me the use of evtchn_upcall_mask?
Any suggestions will be greatly appreciated, thanks in advance.

-- 
Best regards,

Yao-Jing Wen

--f46d044281040ca73b04ca35fd1b
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi, everyone<div>When I trace code of hypervisor, I can&#39;t find the use =
of=A0evtchn_upcall_mask.</div><div>As the comment in include/public/xen.h,=
=A0evtchn_upcall_mask is read=A0before making an event upcall to the guest.=
</div>


<div>After I search the mailing lists, I find the following changelog:</div=
><div><br></div><div><span style=3D"font-size:14px;white-space:pre-wrap;fon=
t-family:Arial,Helvetica,&#39;Luxi Sans&#39;,sans-serif"><a href=3D"http://=
xen.markmail.org/message/4ushwnkx6mhlcz42?q=3Devtchn_set_pending&amp;page=
=3D18" target=3D"_blank">[XEN] Replace direct common-code access of evtchn_=
upcall_mask with local_event_delivery_* accessors.</a></span></div>


<div><span style=3D"font-family:Arial,Helvetica,&#39;Luxi Sans&#39;,sans-se=
rif;font-size:14px;white-space:pre-wrap"><span>diff -r ea4829e30092 -r ddc2=
5d4ebf60 xen/common/event_channel.c
--- a/xen/common/event_channel.c	Sat Jun 10 11:05:11 2006 +0100
+++ b/xen/common/event_channel.c	Sat Jun 10 11:07:11 2006 +0100
@@ -499,7 +499,7 @@ void </span><span style=3D"padding-left:2px;padding-rig=
ht:2px;padding-top:2px;padding-bottom:2px">evtchn_set_pending</span><span>(=
struct vcpu *v,=20
         evtchn_notify(v);
     }
     else if ( unlikely(test_bit(_VCPUF_blocked, &amp;v-&gt;vcpu_flags) &am=
p;&amp;
-                       v-&gt;vcpu_info-&gt;<b><i>evtchn_upcall_mask</i></b=
>) )
+                       !local_event_delivery_is_enabled()) )</span></span>=
<font face=3D"Arial, Helvetica, &#39;Luxi Sans&#39;, sans-serif"><span styl=
e=3D"font-size:14px;white-space:pre-wrap"><br clear=3D"all">
</span></font><div><br></div><div><span style=3D"font-size:14px;white-space=
:pre-wrap;font-family:Arial,Helvetica,&#39;Luxi Sans&#39;,sans-serif"><a hr=
ef=3D"http://xen.markmail.org/search/?q=3Dlocal_event_delivery_is_enabled#q=
uery:local_event_delivery_is_enabled%20order%3Adate-backward+page:2+mid:pjz=
nbfjzcp4sw33d+state:results" target=3D"_blank">[XEN] Fix SCHEDOP_poll to wo=
rk even when event channels are not bound to the polling VCPU.</a></span></=
div>


<div><span style=3D"font-size:14px;white-space:pre-wrap;font-family:Arial,H=
elvetica,&#39;Luxi Sans&#39;,sans-serif">diff -r d7543cff88ae -r aced0ee216=
aa xen/common/event_channel.c
--- a/xen/common/event_channel.c	Sun Jun 11 14:33:16 2006 +0100
+++ b/xen/common/event_channel.c	Sun Jun 11 19:23:31 2006 +0100
@@ -498,14 +498,14 @@ void evtchn_set_pending(struct vcpu *v,=20
     {
         evtchn_notify(v);
     }
-    else if ( unlikely(test_bit(_VCPUF_blocked, &amp;v-&gt;vcpu_flags) &am=
p;&amp;
-                      </span><span style=3D"font-size:14px;white-space:pre=
-wrap;font-family:Arial,Helvetica,&#39;Luxi Sans&#39;,sans-serif"> <b><i>!<=
span style=3D"padding-top:2px;padding-right:2px;padding-bottom:2px;padding-=
left:2px">local_event_delivery_is_enabled</span></i></b>(</span><span style=
=3D"font-size:14px;white-space:pre-wrap;font-family:Arial,Helvetica,&#39;Lu=
xi Sans&#39;,sans-serif">)) )
-    {
-        /*
-         * Blocked and masked will usually mean that the VCPU executed=20
-         * SCHEDOP_poll. Kick the VCPU in case this port is in its poll li=
st.
-         */
-        vcpu_unblock(v);
+   =20
+    /* Check if some VCPU might be polling for this event. */
+    if ( unlikely(test_bit(_DOMF_polling, &amp;d-&gt;domain_flags)) &amp;&=
amp;
+         likely(test_and_clear_bit(_DOMF_polling, &amp;d-&gt;domain_flags)=
) )
+    {
+        for_each_vcpu ( d, v )
+            if ( test_and_clear_bit(_VCPUF_polling, &amp;v-&gt;vcpu_flags)=
 )
+                vcpu_unblock(v);
     }
 }</span></div><div><br></div><div>I think=A0<span style=3D"font-size:14px;=
white-space:pre-wrap;font-family:Arial,Helvetica,&#39;Luxi Sans&#39;,sans-s=
erif">evtchn_set_pending() is the function to decide whether to make=A0</sp=
an>an event upcall to the guest, and the first patch is the last patch whic=
h I see=A0evtchn_upcall_mask in=A0<span style=3D"font-size:14px;white-space=
:pre-wrap;font-family:Arial,Helvetica,&#39;Luxi Sans&#39;,sans-serif">evtch=
n_set_pending()</span>.</div>


<div>I also find that=A0local_event_delivery_is_enabled() is not used in hy=
pervisor.</div><div>I don&#39;t know if i understand this part correctly, i=
t seems that=A0evtchn_upcall_mask is useless.</div><div>Can somebody tell m=
e the use of evtchn_upcall_mask?</div>
<div><span class=3D"Apple-style-span" style=3D"color:rgb(34,34,34);font-fam=
ily:arial,sans-serif;font-size:13px;background-color:rgb(255,255,255)">Any =
suggestions will be greatly appreciated, thanks in advance.</span></div>
<div><br></div>-- <br>Best regards,<br><br>Yao-Jing Wen<br>
</div>

--f46d044281040ca73b04ca35fd1b--


--===============6683055506675510964==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============6683055506675510964==--


From xen-devel-bounces@lists.xen.org Fri Sep 21 13:23:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Sep 2012 13: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 1TF3C5-0006fx-1T; Fri, 21 Sep 2012 13:22:57 +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 1TF3C2-0006fR-UR
	for xen-devel@lists.xen.org; Fri, 21 Sep 2012 13:22:55 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1348233767!11906733!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22396 invoked from network); 21 Sep 2012 13:22:47 -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;
	21 Sep 2012 13:22:47 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 21 Sep 2012 14:22:56 +0100
Message-Id: <505C8641020000780009D025@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 21 Sep 2012 14:22:41 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Keir Fraser" <keir.xen@gmail.com>
References: <505C6E68020000780009CF34@nat28.tlf.novell.com>
	<CC82226A.3F5F0%keir.xen@gmail.com>
In-Reply-To: <CC82226A.3F5F0%keir.xen@gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] x86: enable VIA CPU 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 21.09.12 at 14:55, Keir Fraser <keir.xen@gmail.com> wrote:
> On 21/09/2012 12:40, "Jan Beulich" <JBeulich@suse.com> wrote:
> 
>> Newer VIA CPUs have both 64-bit and VMX support. Enable them to be
>> recognized for these purposes, at once stripping off any 32-bit CPU
>> only bits from the respective CPU support file.
>> 
>> This particularly implies untying the VMX == Intel assumption in a few
>> places.
> 
> Why can't we use 'cpu_has_vmx' instead of your strcmp construct?

Honestly, I didn't even notice we had this (if it's there, I would
have expected it to be used instead of vendor checks).

> It strikes me if it's safe to use in the one place it already is
> (HVM_CR4_GUEST_RESERVED_BITS) then it should be safe for your use too. If
> it's not then it's probably unsafe in its current use, and we should change
> the definition of cpu_has_vmx in a preparatory patch.

Indeed - I'll adjust the patch accordingly.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 21 13:23:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Sep 2012 13: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 1TF3C5-0006fx-1T; Fri, 21 Sep 2012 13:22:57 +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 1TF3C2-0006fR-UR
	for xen-devel@lists.xen.org; Fri, 21 Sep 2012 13:22:55 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1348233767!11906733!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22396 invoked from network); 21 Sep 2012 13:22:47 -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;
	21 Sep 2012 13:22:47 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 21 Sep 2012 14:22:56 +0100
Message-Id: <505C8641020000780009D025@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 21 Sep 2012 14:22:41 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Keir Fraser" <keir.xen@gmail.com>
References: <505C6E68020000780009CF34@nat28.tlf.novell.com>
	<CC82226A.3F5F0%keir.xen@gmail.com>
In-Reply-To: <CC82226A.3F5F0%keir.xen@gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] x86: enable VIA CPU 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 21.09.12 at 14:55, Keir Fraser <keir.xen@gmail.com> wrote:
> On 21/09/2012 12:40, "Jan Beulich" <JBeulich@suse.com> wrote:
> 
>> Newer VIA CPUs have both 64-bit and VMX support. Enable them to be
>> recognized for these purposes, at once stripping off any 32-bit CPU
>> only bits from the respective CPU support file.
>> 
>> This particularly implies untying the VMX == Intel assumption in a few
>> places.
> 
> Why can't we use 'cpu_has_vmx' instead of your strcmp construct?

Honestly, I didn't even notice we had this (if it's there, I would
have expected it to be used instead of vendor checks).

> It strikes me if it's safe to use in the one place it already is
> (HVM_CR4_GUEST_RESERVED_BITS) then it should be safe for your use too. If
> it's not then it's probably unsafe in its current use, and we should change
> the definition of cpu_has_vmx in a preparatory patch.

Indeed - I'll adjust the patch accordingly.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 21 13:25:28 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Sep 2012 13:25: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 1TF3EI-0006pe-Ig; Fri, 21 Sep 2012 13:25:14 +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 1TF3EH-0006pP-95
	for xen-devel@lists.xen.org; Fri, 21 Sep 2012 13:25:13 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1348233906!4899006!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTA2NjI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19927 invoked from network); 21 Sep 2012 13:25:07 -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;
	21 Sep 2012 13:25:07 -0000
X-IronPort-AV: E=Sophos;i="4.80,462,1344211200"; d="scan'208";a="14690820"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Sep 2012 13:24: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.279.1;
	Fri, 21 Sep 2012 14:24:46 +0100
Message-ID: <1348233884.3452.22.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Yaogun Wen <techno.geek.0x01@gmail.com>
Date: Fri, 21 Sep 2012 14:24:44 +0100
In-Reply-To: <CALHMb0dTaR0NCQ1XdfrZ00NXGe0DpKXMNAG0vvZrpNMkLxti6A@mail.gmail.com>
References: <CALHMb0dTaR0NCQ1XdfrZ00NXGe0DpKXMNAG0vvZrpNMkLxti6A@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] The use of evtchn_upcall_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, 2012-09-21 at 14:12 +0100, Yaogun Wen wrote:
> I don't know if i understand this part correctly, it seems that
> evtchn_upcall_mask is useless. 

It is read from assembly code (entry.S) accessed via
VCPUINFO_upcall_mask which is defined using the asm-offsets.c mechanism.

local_event_delivery_is_enabled seems to be redundant these days.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 21 13:25:28 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Sep 2012 13:25: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 1TF3EI-0006pe-Ig; Fri, 21 Sep 2012 13:25:14 +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 1TF3EH-0006pP-95
	for xen-devel@lists.xen.org; Fri, 21 Sep 2012 13:25:13 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1348233906!4899006!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTA2NjI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19927 invoked from network); 21 Sep 2012 13:25:07 -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;
	21 Sep 2012 13:25:07 -0000
X-IronPort-AV: E=Sophos;i="4.80,462,1344211200"; d="scan'208";a="14690820"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Sep 2012 13:24: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.279.1;
	Fri, 21 Sep 2012 14:24:46 +0100
Message-ID: <1348233884.3452.22.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Yaogun Wen <techno.geek.0x01@gmail.com>
Date: Fri, 21 Sep 2012 14:24:44 +0100
In-Reply-To: <CALHMb0dTaR0NCQ1XdfrZ00NXGe0DpKXMNAG0vvZrpNMkLxti6A@mail.gmail.com>
References: <CALHMb0dTaR0NCQ1XdfrZ00NXGe0DpKXMNAG0vvZrpNMkLxti6A@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] The use of evtchn_upcall_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, 2012-09-21 at 14:12 +0100, Yaogun Wen wrote:
> I don't know if i understand this part correctly, it seems that
> evtchn_upcall_mask is useless. 

It is read from assembly code (entry.S) accessed via
VCPUINFO_upcall_mask which is defined using the asm-offsets.c mechanism.

local_event_delivery_is_enabled seems to be redundant these days.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 21 13:30:11 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Sep 2012 13:30: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 1TF3Ir-00073d-9G; Fri, 21 Sep 2012 13:29:57 +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 1TF3Ip-00073Q-Ez
	for xen-devel@lists.xen.org; Fri, 21 Sep 2012 13:29:55 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1348234189!11907641!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22103 invoked from network); 21 Sep 2012 13:29:49 -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;
	21 Sep 2012 13:29:49 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 21 Sep 2012 14:30:02 +0100
Message-Id: <505C87EB020000780009D02F@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 21 Sep 2012 14:29:47 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Yaogun Wen" <techno.geek.0x01@gmail.com>
References: <CALHMb0dTaR0NCQ1XdfrZ00NXGe0DpKXMNAG0vvZrpNMkLxti6A@mail.gmail.com>
In-Reply-To: <CALHMb0dTaR0NCQ1XdfrZ00NXGe0DpKXMNAG0vvZrpNMkLxti6A@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] The use of evtchn_upcall_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 21.09.12 at 15:12, Yaogun Wen <techno.geek.0x01@gmail.com> wrote:
> I think evtchn_set_pending() is the function to decide whether to make an
> event upcall to the guest, and the first patch is the last patch which I
> see evtchn_upcall_mask in evtchn_set_pending().

Setting an event channel pending isn't tied to the channel being
unmasked - in particular, for polled event channels, one would
keep them masked permanently, yet still expect events to be
signaled. The mask really controls whether an upcall is actually
permitted (just like EFLAGS.IF controls whether interrupts can
be injected).

> I don't know if i understand this part correctly, it seems
> that evtchn_upcall_mask is useless.
> Can somebody tell me the use of evtchn_upcall_mask?

If you're looking at current -unstable, then you may get
confused by c/s 25875:dd40b43f16bc ("x86: use only a single
branch for upcall-pending exit path checks") - this one removes
explicit uses of VCPUINFO_upcall_mask, leveraging the fact
that the field is adjacent to VCPUINFO_upcall_pending.

If you're looking at 4.2 or earlier, I'm unclear about your
confusion.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 21 13:30:11 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Sep 2012 13:30: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 1TF3Ir-00073d-9G; Fri, 21 Sep 2012 13:29:57 +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 1TF3Ip-00073Q-Ez
	for xen-devel@lists.xen.org; Fri, 21 Sep 2012 13:29:55 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1348234189!11907641!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22103 invoked from network); 21 Sep 2012 13:29:49 -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;
	21 Sep 2012 13:29:49 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 21 Sep 2012 14:30:02 +0100
Message-Id: <505C87EB020000780009D02F@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 21 Sep 2012 14:29:47 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Yaogun Wen" <techno.geek.0x01@gmail.com>
References: <CALHMb0dTaR0NCQ1XdfrZ00NXGe0DpKXMNAG0vvZrpNMkLxti6A@mail.gmail.com>
In-Reply-To: <CALHMb0dTaR0NCQ1XdfrZ00NXGe0DpKXMNAG0vvZrpNMkLxti6A@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] The use of evtchn_upcall_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 21.09.12 at 15:12, Yaogun Wen <techno.geek.0x01@gmail.com> wrote:
> I think evtchn_set_pending() is the function to decide whether to make an
> event upcall to the guest, and the first patch is the last patch which I
> see evtchn_upcall_mask in evtchn_set_pending().

Setting an event channel pending isn't tied to the channel being
unmasked - in particular, for polled event channels, one would
keep them masked permanently, yet still expect events to be
signaled. The mask really controls whether an upcall is actually
permitted (just like EFLAGS.IF controls whether interrupts can
be injected).

> I don't know if i understand this part correctly, it seems
> that evtchn_upcall_mask is useless.
> Can somebody tell me the use of evtchn_upcall_mask?

If you're looking at current -unstable, then you may get
confused by c/s 25875:dd40b43f16bc ("x86: use only a single
branch for upcall-pending exit path checks") - this one removes
explicit uses of VCPUINFO_upcall_mask, leveraging the fact
that the field is adjacent to VCPUINFO_upcall_pending.

If you're looking at 4.2 or earlier, I'm unclear about your
confusion.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 21 13:40:02 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Sep 2012 13:40: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 1TF3SL-0007HN-DM; Fri, 21 Sep 2012 13:39:45 +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 1TF3SK-0007HI-1y
	for xen-devel@lists.xen.org; Fri, 21 Sep 2012 13:39:44 +0000
Received: from [85.158.139.211:60435] by server-7.bemta-5.messagelabs.com id
	0B/FD-19703-F1E6C505; Fri, 21 Sep 2012 13:39:43 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1348234781!19011925!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzU2MzI0\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23785 invoked from network); 21 Sep 2012 13:39:42 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-7.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 21 Sep 2012 13:39: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 q8LDdYP2005771
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 21 Sep 2012 13:39:34 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
	q8LDdWR9007120
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 21 Sep 2012 13:39:33 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
	q8LDdWfk018673; Fri, 21 Sep 2012 08:39:32 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 21 Sep 2012 06:39:32 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id E8EF8402EC; Fri, 21 Sep 2012 09:28:36 -0400 (EDT)
Date: Fri, 21 Sep 2012 09:28:36 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: davem@davemloft.net
Message-ID: <20120921132836.GA13090@phenom.dumpdata.com>
References: <1347632819-13684-1-git-send-email-andres@lagarcavilla.org>
	<1347869865.14977.15.camel@zakaz.uk.xensource.com>
	<5B5132A4-93B2-41D0-B1A6-048810565DB5@gridcentric.ca>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <5B5132A4-93B2-41D0-B1A6-048810565DB5@gridcentric.ca>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: Ian Campbell <Ian.Campbell@citrix.com>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	xen-devel <xen-devel@lists.xen.org>,
	David Vrabel <david.vrabel@citrix.com>, David Miller <davem@davemloft.net>,
	Andres Lagar-Cavilla <andres@lagarcavilla.org>
Subject: Re: [Xen-devel] [PATCH] Xen backend support for paged out grant
	targets V4.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> >> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
> > 
> > Acked-by: Ian Campbell <ian.campbell@citrix.com>
> > 
> > Since this is more about grant tables than netback this should probably
> > go via Konrad rather than Dave, is that OK with you Dave?
> 
> If that is the case hopefully Konrad can deal with the two typos? Otherwise happy to re-spin the patch.
> Thanks!

David, I pulled it in my tree since the only changes it does to drivers/net/xen-* is
change the name of the function to call in the bowels of grant API.

HYPERVISOR_grant_table_op(GNTTABOP_copy, netbk->tx_copy_ops, nr_gops);
to
gnttab_batch_copy(netbk->tx_copy_ops, nr_gops);

Hope that is OK - if not I can prep a branch that has patches that this depends
on that you can pull.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 21 13:40:02 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Sep 2012 13:40: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 1TF3SL-0007HN-DM; Fri, 21 Sep 2012 13:39:45 +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 1TF3SK-0007HI-1y
	for xen-devel@lists.xen.org; Fri, 21 Sep 2012 13:39:44 +0000
Received: from [85.158.139.211:60435] by server-7.bemta-5.messagelabs.com id
	0B/FD-19703-F1E6C505; Fri, 21 Sep 2012 13:39:43 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1348234781!19011925!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzU2MzI0\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23785 invoked from network); 21 Sep 2012 13:39:42 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-7.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 21 Sep 2012 13:39: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 q8LDdYP2005771
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 21 Sep 2012 13:39:34 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
	q8LDdWR9007120
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 21 Sep 2012 13:39:33 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
	q8LDdWfk018673; Fri, 21 Sep 2012 08:39:32 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 21 Sep 2012 06:39:32 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id E8EF8402EC; Fri, 21 Sep 2012 09:28:36 -0400 (EDT)
Date: Fri, 21 Sep 2012 09:28:36 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: davem@davemloft.net
Message-ID: <20120921132836.GA13090@phenom.dumpdata.com>
References: <1347632819-13684-1-git-send-email-andres@lagarcavilla.org>
	<1347869865.14977.15.camel@zakaz.uk.xensource.com>
	<5B5132A4-93B2-41D0-B1A6-048810565DB5@gridcentric.ca>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <5B5132A4-93B2-41D0-B1A6-048810565DB5@gridcentric.ca>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: Ian Campbell <Ian.Campbell@citrix.com>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	xen-devel <xen-devel@lists.xen.org>,
	David Vrabel <david.vrabel@citrix.com>, David Miller <davem@davemloft.net>,
	Andres Lagar-Cavilla <andres@lagarcavilla.org>
Subject: Re: [Xen-devel] [PATCH] Xen backend support for paged out grant
	targets V4.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> >> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
> > 
> > Acked-by: Ian Campbell <ian.campbell@citrix.com>
> > 
> > Since this is more about grant tables than netback this should probably
> > go via Konrad rather than Dave, is that OK with you Dave?
> 
> If that is the case hopefully Konrad can deal with the two typos? Otherwise happy to re-spin the patch.
> Thanks!

David, I pulled it in my tree since the only changes it does to drivers/net/xen-* is
change the name of the function to call in the bowels of grant API.

HYPERVISOR_grant_table_op(GNTTABOP_copy, netbk->tx_copy_ops, nr_gops);
to
gnttab_batch_copy(netbk->tx_copy_ops, nr_gops);

Hope that is OK - if not I can prep a branch that has patches that this depends
on that you can pull.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 21 13:43:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Sep 2012 13:43:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TF3VS-0007NR-18; Fri, 21 Sep 2012 13:42:58 +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 1TF3VQ-0007NK-Nu
	for xen-devel@lists.xensource.com; Fri, 21 Sep 2012 13:42:56 +0000
Received: from [85.158.139.211:33374] by server-8.bemta-5.messagelabs.com id
	BA/18-30083-FDE6C505; Fri, 21 Sep 2012 13:42:55 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-15.tower-206.messagelabs.com!1348234973!19519288!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDc2NjM1OA==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25355 invoked from network); 21 Sep 2012 13:42:55 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-15.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 21 Sep 2012 13:42: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 q8LDgoC5021566
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 21 Sep 2012 13:42:51 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
	q8LDgnpV018633
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 21 Sep 2012 13:42:49 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
	q8LDgmEv020980; Fri, 21 Sep 2012 08:42:48 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 21 Sep 2012 06:42:48 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 7625D402EC; Fri, 21 Sep 2012 09:31:53 -0400 (EDT)
Date: Fri, 21 Sep 2012 09:31:53 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Linus Torvalds <torvalds@linux-foundation.org>,
	linux-kernel@vger.kernel.org
Message-ID: <20120921133153.GA13227@phenom.dumpdata.com>
MIME-Version: 1.0
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: xen-devel@lists.xensource.com
Subject: [Xen-devel] [GIT PULL] (xen) stable/for-linus-3.6-rc6-tag.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============3085357288739529913=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--===============3085357288739529913==
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="NzB8fVQJ5HfG6fxh"
Content-Disposition: inline


--NzB8fVQJ5HfG6fxh
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline


Hey Linus,

Please git pull the following two bug-fixes from:

 git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git stable/for-linus-3.6-rc6-tag

which has two bug-fixes. One is a bootup that we had ignored until we found
that on DL380 G6 it was needed. The other is more recent - in v3.5 we added
batching for M2P override (Machine Frame Number -> Physical Frame Number), but
the original MFN was saved in an incorrect structure - and we would oops/restore
when restoring with the old MFN. Both of them CC the stable train. Please pull!

Konrad Rzeszutek Wilk (1):
      xen/boot: Disable BIOS SMP MP table search.

Stefano Stabellini (1):
      xen/m2p: do not reuse kmap_op->dev_bus_addr

arch/x86/include/asm/xen/page.h     |    3 ++-
 arch/x86/xen/enlighten.c            |    4 ++++
 arch/x86/xen/p2m.c                  |   27 +++++++++++----------------
 drivers/block/xen-blkback/blkback.c |    2 +-
 drivers/xen/gntdev.c                |    5 +++--
 drivers/xen/grant-table.c           |    6 ++++--
 include/xen/grant_table.h           |    3 ++-
 7 files changed, 27 insertions(+), 23 deletions(-)

--NzB8fVQJ5HfG6fxh
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iQEcBAEBAgAGBQJQXGw3AAoJEFjIrFwIi8fJizUIAKdZSdxmQ4Dajm3UnPUbmUuk
u3CGIovXWZ6hmkqv6DBy+Y6+tn91QgePYtEfvHJ7J5DPPj60Cb/VZ/XRagGGPvMy
BC7LmPESkGzMrw+jzMlCPi1FmhJmVX7KSm5i7b85ejazPhQFwooJD169kAzwUJ1M
bfuxHl69VBuQIEPb0giLEO2soql+A+YDGYPMPcOxExv3NrHHi2F4czW8QIzkKUEe
eYHtylVM5zmkLZHVhk15uPG7Fx1aHI/iiY3w8tDcobbYTnbkMPSVXRdIAXV7cIZW
3dZAHctk9Vsqgj2uWVoOyzOTeaNBrWcnrUZ/BCDCBD2+e8Vu0Zgl5VUw3Xd3TDg=
=dsf9
-----END PGP SIGNATURE-----

--NzB8fVQJ5HfG6fxh--


--===============3085357288739529913==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============3085357288739529913==--


From xen-devel-bounces@lists.xen.org Fri Sep 21 13:43:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Sep 2012 13:43:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TF3VS-0007NR-18; Fri, 21 Sep 2012 13:42:58 +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 1TF3VQ-0007NK-Nu
	for xen-devel@lists.xensource.com; Fri, 21 Sep 2012 13:42:56 +0000
Received: from [85.158.139.211:33374] by server-8.bemta-5.messagelabs.com id
	BA/18-30083-FDE6C505; Fri, 21 Sep 2012 13:42:55 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-15.tower-206.messagelabs.com!1348234973!19519288!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDc2NjM1OA==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25355 invoked from network); 21 Sep 2012 13:42:55 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-15.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 21 Sep 2012 13:42: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 q8LDgoC5021566
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 21 Sep 2012 13:42:51 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
	q8LDgnpV018633
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 21 Sep 2012 13:42:49 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
	q8LDgmEv020980; Fri, 21 Sep 2012 08:42:48 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 21 Sep 2012 06:42:48 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 7625D402EC; Fri, 21 Sep 2012 09:31:53 -0400 (EDT)
Date: Fri, 21 Sep 2012 09:31:53 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Linus Torvalds <torvalds@linux-foundation.org>,
	linux-kernel@vger.kernel.org
Message-ID: <20120921133153.GA13227@phenom.dumpdata.com>
MIME-Version: 1.0
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: xen-devel@lists.xensource.com
Subject: [Xen-devel] [GIT PULL] (xen) stable/for-linus-3.6-rc6-tag.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============3085357288739529913=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--===============3085357288739529913==
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="NzB8fVQJ5HfG6fxh"
Content-Disposition: inline


--NzB8fVQJ5HfG6fxh
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline


Hey Linus,

Please git pull the following two bug-fixes from:

 git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git stable/for-linus-3.6-rc6-tag

which has two bug-fixes. One is a bootup that we had ignored until we found
that on DL380 G6 it was needed. The other is more recent - in v3.5 we added
batching for M2P override (Machine Frame Number -> Physical Frame Number), but
the original MFN was saved in an incorrect structure - and we would oops/restore
when restoring with the old MFN. Both of them CC the stable train. Please pull!

Konrad Rzeszutek Wilk (1):
      xen/boot: Disable BIOS SMP MP table search.

Stefano Stabellini (1):
      xen/m2p: do not reuse kmap_op->dev_bus_addr

arch/x86/include/asm/xen/page.h     |    3 ++-
 arch/x86/xen/enlighten.c            |    4 ++++
 arch/x86/xen/p2m.c                  |   27 +++++++++++----------------
 drivers/block/xen-blkback/blkback.c |    2 +-
 drivers/xen/gntdev.c                |    5 +++--
 drivers/xen/grant-table.c           |    6 ++++--
 include/xen/grant_table.h           |    3 ++-
 7 files changed, 27 insertions(+), 23 deletions(-)

--NzB8fVQJ5HfG6fxh
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iQEcBAEBAgAGBQJQXGw3AAoJEFjIrFwIi8fJizUIAKdZSdxmQ4Dajm3UnPUbmUuk
u3CGIovXWZ6hmkqv6DBy+Y6+tn91QgePYtEfvHJ7J5DPPj60Cb/VZ/XRagGGPvMy
BC7LmPESkGzMrw+jzMlCPi1FmhJmVX7KSm5i7b85ejazPhQFwooJD169kAzwUJ1M
bfuxHl69VBuQIEPb0giLEO2soql+A+YDGYPMPcOxExv3NrHHi2F4czW8QIzkKUEe
eYHtylVM5zmkLZHVhk15uPG7Fx1aHI/iiY3w8tDcobbYTnbkMPSVXRdIAXV7cIZW
3dZAHctk9Vsqgj2uWVoOyzOTeaNBrWcnrUZ/BCDCBD2+e8Vu0Zgl5VUw3Xd3TDg=
=dsf9
-----END PGP SIGNATURE-----

--NzB8fVQJ5HfG6fxh--


--===============3085357288739529913==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============3085357288739529913==--


From xen-devel-bounces@lists.xen.org Fri Sep 21 13:47:29 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Sep 2012 13:47: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 1TF3Za-0007Y9-N5; Fri, 21 Sep 2012 13:47:14 +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 1TF3ZZ-0007Y3-16
	for xen-devel@lists.xensource.com; Fri, 21 Sep 2012 13:47:13 +0000
Received: from [85.158.139.211:6028] by server-11.bemta-5.messagelabs.com id
	58/69-24658-0EF6C505; Fri, 21 Sep 2012 13:47:12 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-11.tower-206.messagelabs.com!1348235230!19478352!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDc2NjM1OA==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17451 invoked from network); 21 Sep 2012 13:47:11 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-11.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 21 Sep 2012 13:47:11 -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 q8LDl7qR030298
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 21 Sep 2012 13:47:08 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q8LDl6ou000954
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 21 Sep 2012 13:47:07 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
	q8LDl6mV011055; Fri, 21 Sep 2012 08:47:06 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 21 Sep 2012 06:47:06 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 37199402EC; Fri, 21 Sep 2012 09:36:11 -0400 (EDT)
Date: Fri, 21 Sep 2012 09:36:11 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Oliver Chick <oliver.chick@citrix.com>
Message-ID: <20120921133611.GD13227@phenom.dumpdata.com>
References: <1348218258-4418-1-git-send-email-oliver.chick@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1348218258-4418-1-git-send-email-oliver.chick@citrix.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: Re: [Xen-devel] [PATCH] Change xen_vbd's flush_support and
 discard_secure to have type unsigned int, rather than bool
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Sep 21, 2012 at 10:04:18AM +0100, Oliver Chick wrote:
> Changing the type of bdev parameters to be unsigned int :1, rather than bool.
> This is more consistent with the types of other features in the block drivers.

Thanks. Put in my for-jens branch.
> 
> Signed-off-by: Oliver Chick <oliver.chick@citrix.com>
> ---
>  drivers/block/xen-blkback/common.h |    4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/block/xen-blkback/common.h b/drivers/block/xen-blkback/common.h
> index 9ad3b5e..9a54623 100644
> --- a/drivers/block/xen-blkback/common.h
> +++ b/drivers/block/xen-blkback/common.h
> @@ -158,8 +158,8 @@ struct xen_vbd {
>  	struct block_device	*bdev;
>  	/* Cached size parameter. */
>  	sector_t		size;
> -	bool			flush_support;
> -	bool			discard_secure;
> +	unsigned int		flush_support:1;
> +	unsigned int		discard_secure:1;
>  };
>  
>  struct backend_info;
> -- 
> 1.7.9.5

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 21 13:47:29 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Sep 2012 13:47: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 1TF3Za-0007Y9-N5; Fri, 21 Sep 2012 13:47:14 +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 1TF3ZZ-0007Y3-16
	for xen-devel@lists.xensource.com; Fri, 21 Sep 2012 13:47:13 +0000
Received: from [85.158.139.211:6028] by server-11.bemta-5.messagelabs.com id
	58/69-24658-0EF6C505; Fri, 21 Sep 2012 13:47:12 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-11.tower-206.messagelabs.com!1348235230!19478352!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDc2NjM1OA==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17451 invoked from network); 21 Sep 2012 13:47:11 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-11.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 21 Sep 2012 13:47:11 -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 q8LDl7qR030298
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 21 Sep 2012 13:47:08 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q8LDl6ou000954
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 21 Sep 2012 13:47:07 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
	q8LDl6mV011055; Fri, 21 Sep 2012 08:47:06 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 21 Sep 2012 06:47:06 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 37199402EC; Fri, 21 Sep 2012 09:36:11 -0400 (EDT)
Date: Fri, 21 Sep 2012 09:36:11 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Oliver Chick <oliver.chick@citrix.com>
Message-ID: <20120921133611.GD13227@phenom.dumpdata.com>
References: <1348218258-4418-1-git-send-email-oliver.chick@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1348218258-4418-1-git-send-email-oliver.chick@citrix.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: Re: [Xen-devel] [PATCH] Change xen_vbd's flush_support and
 discard_secure to have type unsigned int, rather than bool
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Sep 21, 2012 at 10:04:18AM +0100, Oliver Chick wrote:
> Changing the type of bdev parameters to be unsigned int :1, rather than bool.
> This is more consistent with the types of other features in the block drivers.

Thanks. Put in my for-jens branch.
> 
> Signed-off-by: Oliver Chick <oliver.chick@citrix.com>
> ---
>  drivers/block/xen-blkback/common.h |    4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/block/xen-blkback/common.h b/drivers/block/xen-blkback/common.h
> index 9ad3b5e..9a54623 100644
> --- a/drivers/block/xen-blkback/common.h
> +++ b/drivers/block/xen-blkback/common.h
> @@ -158,8 +158,8 @@ struct xen_vbd {
>  	struct block_device	*bdev;
>  	/* Cached size parameter. */
>  	sector_t		size;
> -	bool			flush_support;
> -	bool			discard_secure;
> +	unsigned int		flush_support:1;
> +	unsigned int		discard_secure:1;
>  };
>  
>  struct backend_info;
> -- 
> 1.7.9.5

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 21 14:02:01 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Sep 2012 14:02: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 1TF3nf-0007nQ-4g; Fri, 21 Sep 2012 14:01:47 +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 1TF3nd-0007nL-Dt
	for xen-devel@lists.xen.org; Fri, 21 Sep 2012 14:01:45 +0000
Received: from [85.158.143.35:37968] by server-3.bemta-4.messagelabs.com id
	3A/FA-10986-8437C505; Fri, 21 Sep 2012 14:01:44 +0000
X-Env-Sender: Christoph.Egger@amd.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1348236101!8327194!1
X-Originating-IP: [216.32.180.184]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32644 invoked from network); 21 Sep 2012 14:01:43 -0000
Received: from co1ehsobe001.messaging.microsoft.com (HELO
	co1outboundpool.messaging.microsoft.com) (216.32.180.184)
	by server-2.tower-21.messagelabs.com with AES128-SHA encrypted SMTP;
	21 Sep 2012 14:01:43 -0000
Received: from mail172-co1-R.bigfish.com (10.243.78.237) by
	CO1EHSOBE013.bigfish.com (10.243.66.76) with Microsoft SMTP Server id
	14.1.225.23; Fri, 21 Sep 2012 14:01:41 +0000
Received: from mail172-co1 (localhost [127.0.0.1])	by
	mail172-co1-R.bigfish.com (Postfix) with ESMTP id 1010E5C03F6	for
	<xen-devel@lists.xen.org>; Fri, 21 Sep 2012 14:01:41 +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(zzc85fhc85dhzz1202h1d1ah1d2ahzz8275bhz2dh668h839hd25he5bhf0ah107ah1288h12a5h12bdh137ah34h1155h)
Received: from mail172-co1 (localhost.localdomain [127.0.0.1]) by mail172-co1
	(MessageSwitch) id 1348236099667984_25032;
	Fri, 21 Sep 2012 14:01:39 +0000 (UTC)
Received: from CO1EHSMHS021.bigfish.com (unknown [10.243.78.245])	by
	mail172-co1.bigfish.com (Postfix) with ESMTP id 96D4A5A0117	for
	<xen-devel@lists.xen.org>; Fri, 21 Sep 2012 14:01:39 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	CO1EHSMHS021.bigfish.com (10.243.66.31) with Microsoft SMTP Server id
	14.1.225.23; Fri, 21 Sep 2012 14:01:36 +0000
X-WSS-ID: 0MAPDMM-01-ATN-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 22D3510280C6	for <xen-devel@lists.xen.org>;
	Fri, 21 Sep 2012 09:01:34 -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, 21 Sep 2012 09:01:47 -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, 21 Sep 2012 09:01:34 -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, 21 Sep 2012
	10:01:32 -0400
Message-ID: <505C733B.50205@amd.com>
Date: Fri, 21 Sep 2012 16:01:31 +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="------------090209060906050805000502"
X-OriginatorOrg: amd.com
Subject: [Xen-devel] [PATCH] nestedsvm: fix paging mode
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--------------090209060906050805000502
Content-Type: text/plain; charset="ISO-8859-15"
Content-Transfer-Encoding: 7bit


On VMRUN and VMEXIT emulation update the paging mode
for Shadow-on-Nested. This allows Xen to walk the
l1 hypervisors shadow page table correctly.
Problem found with 64bit Win7 and 32bit XPMode where
Win7 switches forth and back between long mode and
PAE legacy pagetables.

Signed-off-by: Christoph Egger <Christoph.Egger@amd.com>

P.S.: Please apply this patch to xen-4.2-testing as well.


-- 
---to satisfy European Law for business letters:
Advanced Micro Devices GmbH
Einsteinring 24, 85689 Dornach b. Muenchen
Geschaeftsfuehrer: Alberto Bozzo
Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen
Registergericht Muenchen, HRB Nr. 43632

--------------090209060906050805000502
Content-Type: text/plain; charset="us-ascii"; name="xen_nh_paging.diff"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="xen_nh_paging.diff"
Content-Description: xen_nh_paging.diff

diff -r ef514a30fd70 xen/arch/x86/hvm/svm/nestedsvm.c
--- a/xen/arch/x86/hvm/svm/nestedsvm.c	Fri Sep 21 13:25:22 2012 +0200
+++ b/xen/arch/x86/hvm/svm/nestedsvm.c	Fri Sep 21 14:44:13 2012 +0200
@@ -745,6 +745,11 @@ nsvm_vcpu_vmrun(struct vcpu *v, struct c
         return 1;
     }
 
+    /* If we use nested paging and l1 guest uses shadow paging ... */
+    if (paging_mode_hap(v->domain) && !nestedhvm_paging_mode_hap(v))
+        /* ... update the paging modes. */
+        paging_update_paging_modes(v);
+
     nv->nv_vmswitch_in_progress = 0;
     return 0;
 }
@@ -1412,6 +1417,11 @@ nestedsvm_vcpu_vmexit(struct vcpu *v, st
      */
     rc = nhvm_vcpu_vmexit(v, regs, exitcode);
 
+    /* If we use nested paging and l1 guest uses shadow paging ... */
+    if (paging_mode_hap(v->domain) && !nestedhvm_paging_mode_hap(v))
+        /* ... update the paging modes. */
+        paging_update_paging_modes(v);
+
     nv->nv_vmswitch_in_progress = 0;
 
     if (rc)

--------------090209060906050805000502
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--------------090209060906050805000502--


From xen-devel-bounces@lists.xen.org Fri Sep 21 14:02:01 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Sep 2012 14:02: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 1TF3nf-0007nQ-4g; Fri, 21 Sep 2012 14:01:47 +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 1TF3nd-0007nL-Dt
	for xen-devel@lists.xen.org; Fri, 21 Sep 2012 14:01:45 +0000
Received: from [85.158.143.35:37968] by server-3.bemta-4.messagelabs.com id
	3A/FA-10986-8437C505; Fri, 21 Sep 2012 14:01:44 +0000
X-Env-Sender: Christoph.Egger@amd.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1348236101!8327194!1
X-Originating-IP: [216.32.180.184]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32644 invoked from network); 21 Sep 2012 14:01:43 -0000
Received: from co1ehsobe001.messaging.microsoft.com (HELO
	co1outboundpool.messaging.microsoft.com) (216.32.180.184)
	by server-2.tower-21.messagelabs.com with AES128-SHA encrypted SMTP;
	21 Sep 2012 14:01:43 -0000
Received: from mail172-co1-R.bigfish.com (10.243.78.237) by
	CO1EHSOBE013.bigfish.com (10.243.66.76) with Microsoft SMTP Server id
	14.1.225.23; Fri, 21 Sep 2012 14:01:41 +0000
Received: from mail172-co1 (localhost [127.0.0.1])	by
	mail172-co1-R.bigfish.com (Postfix) with ESMTP id 1010E5C03F6	for
	<xen-devel@lists.xen.org>; Fri, 21 Sep 2012 14:01:41 +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(zzc85fhc85dhzz1202h1d1ah1d2ahzz8275bhz2dh668h839hd25he5bhf0ah107ah1288h12a5h12bdh137ah34h1155h)
Received: from mail172-co1 (localhost.localdomain [127.0.0.1]) by mail172-co1
	(MessageSwitch) id 1348236099667984_25032;
	Fri, 21 Sep 2012 14:01:39 +0000 (UTC)
Received: from CO1EHSMHS021.bigfish.com (unknown [10.243.78.245])	by
	mail172-co1.bigfish.com (Postfix) with ESMTP id 96D4A5A0117	for
	<xen-devel@lists.xen.org>; Fri, 21 Sep 2012 14:01:39 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	CO1EHSMHS021.bigfish.com (10.243.66.31) with Microsoft SMTP Server id
	14.1.225.23; Fri, 21 Sep 2012 14:01:36 +0000
X-WSS-ID: 0MAPDMM-01-ATN-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 22D3510280C6	for <xen-devel@lists.xen.org>;
	Fri, 21 Sep 2012 09:01:34 -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, 21 Sep 2012 09:01:47 -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, 21 Sep 2012 09:01:34 -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, 21 Sep 2012
	10:01:32 -0400
Message-ID: <505C733B.50205@amd.com>
Date: Fri, 21 Sep 2012 16:01:31 +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="------------090209060906050805000502"
X-OriginatorOrg: amd.com
Subject: [Xen-devel] [PATCH] nestedsvm: fix paging mode
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--------------090209060906050805000502
Content-Type: text/plain; charset="ISO-8859-15"
Content-Transfer-Encoding: 7bit


On VMRUN and VMEXIT emulation update the paging mode
for Shadow-on-Nested. This allows Xen to walk the
l1 hypervisors shadow page table correctly.
Problem found with 64bit Win7 and 32bit XPMode where
Win7 switches forth and back between long mode and
PAE legacy pagetables.

Signed-off-by: Christoph Egger <Christoph.Egger@amd.com>

P.S.: Please apply this patch to xen-4.2-testing as well.


-- 
---to satisfy European Law for business letters:
Advanced Micro Devices GmbH
Einsteinring 24, 85689 Dornach b. Muenchen
Geschaeftsfuehrer: Alberto Bozzo
Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen
Registergericht Muenchen, HRB Nr. 43632

--------------090209060906050805000502
Content-Type: text/plain; charset="us-ascii"; name="xen_nh_paging.diff"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="xen_nh_paging.diff"
Content-Description: xen_nh_paging.diff

diff -r ef514a30fd70 xen/arch/x86/hvm/svm/nestedsvm.c
--- a/xen/arch/x86/hvm/svm/nestedsvm.c	Fri Sep 21 13:25:22 2012 +0200
+++ b/xen/arch/x86/hvm/svm/nestedsvm.c	Fri Sep 21 14:44:13 2012 +0200
@@ -745,6 +745,11 @@ nsvm_vcpu_vmrun(struct vcpu *v, struct c
         return 1;
     }
 
+    /* If we use nested paging and l1 guest uses shadow paging ... */
+    if (paging_mode_hap(v->domain) && !nestedhvm_paging_mode_hap(v))
+        /* ... update the paging modes. */
+        paging_update_paging_modes(v);
+
     nv->nv_vmswitch_in_progress = 0;
     return 0;
 }
@@ -1412,6 +1417,11 @@ nestedsvm_vcpu_vmexit(struct vcpu *v, st
      */
     rc = nhvm_vcpu_vmexit(v, regs, exitcode);
 
+    /* If we use nested paging and l1 guest uses shadow paging ... */
+    if (paging_mode_hap(v->domain) && !nestedhvm_paging_mode_hap(v))
+        /* ... update the paging modes. */
+        paging_update_paging_modes(v);
+
     nv->nv_vmswitch_in_progress = 0;
 
     if (rc)

--------------090209060906050805000502
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--------------090209060906050805000502--


From xen-devel-bounces@lists.xen.org Fri Sep 21 14:25:06 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Sep 2012 14:25:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TF49r-00086r-AV; Fri, 21 Sep 2012 14:24:43 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1TF49q-00086m-8I
	for xen-devel@lists.xen.org; Fri, 21 Sep 2012 14:24:42 +0000
Received: from [85.158.138.51:7006] by server-15.bemta-3.messagelabs.com id
	A3/EB-09665-9A87C505; Fri, 21 Sep 2012 14:24:41 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1348237480!31446617!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18923 invoked from network); 21 Sep 2012 14:24:40 -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;
	21 Sep 2012 14:24:40 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 21 Sep 2012 15:25:53 +0100
Message-Id: <505C94B3020000780009D06A@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 21 Sep 2012 15:24:19 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Keir Fraser" <keir.xen@gmail.com>
References: <505C6E68020000780009CF34@nat28.tlf.novell.com>
	<CC82226A.3F5F0%keir.xen@gmail.com>
In-Reply-To: <CC82226A.3F5F0%keir.xen@gmail.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part9FAE9E83.1__="
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: [Xen-devel] [PATCH, v2] x86: enable VIA CPU 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

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.

--=__Part9FAE9E83.1__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Newer VIA CPUs have both 64-bit and VMX support. Enable them to be
recognized for these purposes, at once stripping off any 32-bit CPU
only bits from the respective CPU support file.

This particularly implies untying the VMX =3D=3D Intel assumption in a few
places.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

---
v2: Use cpu_has_vmx instead of comparing hvm_funcs.name, as suggested
    by Keir. Extend this to also use this and cpu_has_svm in
    hvm_enable(), making the respective open coded checks in
    start_{svm,vmx}() unnecessary.

Note that my testing of this functionality wasn't as wide as I would
have hoped it to be, since the box I was provided only survived the
first few days - meanwhile it doesn't stay up long enough to just build
hypervisor and tools. Therefore, further fixes to fully support these
CPUs may be needed as the VIA folks themselves get to test that code.

--- a/xen/arch/x86/acpi/suspend.c
+++ b/xen/arch/x86/acpi/suspend.c
@@ -32,7 +32,8 @@ void save_rest_processor_state(void)
     rdmsrl(MSR_SHADOW_GS_BASE, saved_kernel_gs_base);
     rdmsrl(MSR_CSTAR, saved_cstar);
     rdmsrl(MSR_LSTAR, saved_lstar);
-    if ( boot_cpu_data.x86_vendor =3D=3D X86_VENDOR_INTEL )
+    if ( boot_cpu_data.x86_vendor =3D=3D X86_VENDOR_INTEL ||
+         boot_cpu_data.x86_vendor =3D=3D X86_VENDOR_CENTAUR )
     {
         rdmsrl(MSR_IA32_SYSENTER_ESP, saved_sysenter_esp);
         rdmsrl(MSR_IA32_SYSENTER_EIP, saved_sysenter_eip);
@@ -59,7 +60,8 @@ void restore_rest_processor_state(void)
     wrmsrl(MSR_GS_BASE, saved_gs_base);
     wrmsrl(MSR_SHADOW_GS_BASE, saved_kernel_gs_base);
=20
-    if ( boot_cpu_data.x86_vendor =3D=3D X86_VENDOR_INTEL )
+    if ( boot_cpu_data.x86_vendor =3D=3D X86_VENDOR_INTEL ||
+         boot_cpu_data.x86_vendor =3D=3D X86_VENDOR_CENTAUR )
     {
         /* Recover sysenter MSRs */
         wrmsrl(MSR_IA32_SYSENTER_ESP, saved_sysenter_esp);
--- a/xen/arch/x86/cpu/Makefile
+++ b/xen/arch/x86/cpu/Makefile
@@ -2,10 +2,8 @@ subdir-y +=3D mcheck
 subdir-y +=3D mtrr
=20
 obj-y +=3D amd.o
+obj-y +=3D centaur.o
 obj-y +=3D common.o
 obj-y +=3D intel.o
 obj-y +=3D intel_cacheinfo.o
 obj-y +=3D mwait-idle.o
-
-# Keeping around for VIA support (JBeulich)
-# obj-$(x86_32) +=3D centaur.o
--- a/xen/arch/x86/cpu/centaur.c
+++ b/xen/arch/x86/cpu/centaur.c
@@ -45,51 +45,25 @@ static void __init init_c3(struct cpuinf
 		c->x86_capability[5] =3D cpuid_edx(0xC0000001);
 	}
=20
-	/* Cyrix III family needs CX8 & PGE explicity enabled. */
-	if (c->x86_model >=3D6 && c->x86_model <=3D 9) {
-		rdmsrl(MSR_VIA_FCR, msr_content);
-		wrmsrl(MSR_VIA_FCR, msr_content | (1ULL << 1 | 1ULL << =
7));
-		set_bit(X86_FEATURE_CX8, c->x86_capability);
+	if (c->x86 =3D=3D 0x6 && c->x86_model >=3D 0xf) {
+		c->x86_cache_alignment =3D c->x86_clflush_size * 2;
+		set_bit(X86_FEATURE_CONSTANT_TSC, c->x86_capability);
 	}
=20
-	/* Before Nehemiah, the C3's had 3dNOW! */
-	if (c->x86_model >=3D6 && c->x86_model <9)
-		set_bit(X86_FEATURE_3DNOW, c->x86_capability);
-
 	get_model_name(c);
 	display_cacheinfo(c);
 }
=20
 static void __init init_centaur(struct cpuinfo_x86 *c)
 {
-	/* Bit 31 in normal CPUID used for nonstandard 3DNow ID;
-	   3DNow is IDd by bit 31 in extended CPUID (1*32+31) anyway */
-	clear_bit(0*32+31, c->x86_capability);
-
 	if (c->x86 =3D=3D 6)
 		init_c3(c);
 }
=20
-static unsigned int centaur_size_cache(struct cpuinfo_x86 * c, unsigned =
int size)
-{
-	/* VIA C3 CPUs (670-68F) need further shifting. */
-	if ((c->x86 =3D=3D 6) && ((c->x86_model =3D=3D 7) || (c->x86_model =
=3D=3D 8)))
-		size >>=3D 8;
-
-	/* VIA also screwed up Nehemiah stepping 1, and made
-	   it return '65KB' instead of '64KB'
-	   - Note, it seems this may only be in engineering samples. */
-	if ((c->x86=3D=3D6) && (c->x86_model=3D=3D9) && (c->x86_mask=3D=3D1=
) && (size=3D=3D65))
-		size -=3D1;
-
-	return size;
-}
-
 static struct cpu_dev centaur_cpu_dev __cpuinitdata =3D {
 	.c_vendor	=3D "Centaur",
 	.c_ident	=3D { "CentaurHauls" },
 	.c_init		=3D init_centaur,
-	.c_size_cache	=3D centaur_size_cache,
 };
=20
 int __init centaur_init_cpu(void)
@@ -97,5 +71,3 @@ int __init centaur_init_cpu(void)
 	cpu_devs[X86_VENDOR_CENTAUR] =3D &centaur_cpu_dev;
 	return 0;
 }
-
-//early_arch_initcall(centaur_init_cpu);
--- a/xen/arch/x86/cpu/common.c
+++ b/xen/arch/x86/cpu/common.c
@@ -522,6 +522,7 @@ void __init early_cpu_init(void)
 {
 	intel_cpu_init();
 	amd_init_cpu();
+	centaur_init_cpu();
 	early_cpu_detect();
 }
 /*
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -111,17 +111,10 @@ static int __init hvm_enable(void)
 {
     struct hvm_function_table *fns =3D NULL;
=20
-    switch ( boot_cpu_data.x86_vendor )
-    {
-    case X86_VENDOR_INTEL:
+    if ( cpu_has_vmx )
         fns =3D start_vmx();
-        break;
-    case X86_VENDOR_AMD:
+    else if ( cpu_has_svm )
         fns =3D start_svm();
-        break;
-    default:
-        break;
-    }
=20
     if ( fns =3D=3D NULL )
         return 0;
--- a/xen/arch/x86/hvm/nestedhvm.c
+++ b/xen/arch/x86/hvm/nestedhvm.c
@@ -152,7 +152,7 @@ static int __init
 nestedhvm_setup(void)
 {
     /* Same format and size as hvm_io_bitmap (Intel needs only 2 pages). =
*/
-    unsigned int nr =3D (boot_cpu_data.x86_vendor =3D=3D X86_VENDOR_INTEL)=
 ? 2 : 3;
+    unsigned nr =3D cpu_has_vmx ? 2 : 3;
     unsigned int i, order =3D get_order_from_pages(nr);
=20
     if ( !hvm_funcs.name )
--- a/xen/arch/x86/hvm/svm/svm.c
+++ b/xen/arch/x86/hvm/svm/svm.c
@@ -1240,9 +1240,6 @@ struct hvm_function_table * __init start
 {
     bool_t printed =3D 0;
=20
-    if ( !test_bit(X86_FEATURE_SVM, &boot_cpu_data.x86_capability) )
-        return NULL;
-
     svm_host_osvw_reset();
=20
     if ( svm_cpu_up() )
--- a/xen/arch/x86/hvm/viridian.c
+++ b/xen/arch/x86/hvm/viridian.c
@@ -156,8 +156,7 @@ static void enable_hypercall_page(struct
     *(u32 *)(p + 1) =3D 0x80000000;
     *(u8  *)(p + 5) =3D 0x0f; /* vmcall/vmmcall */
     *(u8  *)(p + 6) =3D 0x01;
-    *(u8  *)(p + 7) =3D ((boot_cpu_data.x86_vendor =3D=3D X86_VENDOR_INTEL=
)
-                       ? 0xc1 : 0xd9);
+    *(u8  *)(p + 7) =3D (cpu_has_vmx ? 0xc1 : 0xd9);
     *(u8  *)(p + 8) =3D 0xc3; /* ret */
     memset(p + 9, 0xcc, PAGE_SIZE - 9); /* int3, int3, ... */
=20
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -1516,9 +1516,6 @@ static struct hvm_function_table __read_
=20
 struct hvm_function_table * __init start_vmx(void)
 {
-    if ( !test_bit(X86_FEATURE_VMXE, &boot_cpu_data.x86_capability) )
-        return NULL;
-
     set_in_cr4(X86_CR4_VMXE);
=20
     if ( vmx_cpu_up() )
--- a/xen/arch/x86/mm/mem_event.c
+++ b/xen/arch/x86/mm/mem_event.c
@@ -608,7 +608,7 @@ int mem_event_domctl(struct domain *d, x
                 break;
=20
             /* Currently only EPT is supported */
-            if ( boot_cpu_data.x86_vendor !=3D X86_VENDOR_INTEL )
+            if ( !cpu_has_vmx )
                 break;
=20
             rc =3D mem_event_enable(d, mec, med, _VPF_mem_access,=20
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -83,7 +83,7 @@ static void p2m_initialise(struct domain
=20
     p2m->cr3 =3D CR3_EADDR;
=20
-    if ( hap_enabled(d) && (boot_cpu_data.x86_vendor =3D=3D X86_VENDOR_INT=
EL) )
+    if ( hap_enabled(d) && cpu_has_vmx )
         ept_p2m_init(p2m);
     else
         p2m_pt_init(p2m);
--- a/xen/arch/x86/x86_64/traps.c
+++ b/xen/arch/x86/x86_64/traps.c
@@ -399,7 +399,8 @@ void __devinit subarch_percpu_traps_init
     wrmsrl(MSR_LSTAR, (unsigned long)stack);
     stack +=3D write_stack_trampoline(stack, stack_bottom, FLAT_KERNEL_CS6=
4);
=20
-    if ( boot_cpu_data.x86_vendor =3D=3D X86_VENDOR_INTEL )
+    if ( boot_cpu_data.x86_vendor =3D=3D X86_VENDOR_INTEL ||
+         boot_cpu_data.x86_vendor =3D=3D X86_VENDOR_CENTAUR )
     {
         /* SYSENTER entry. */
         wrmsrl(MSR_IA32_SYSENTER_ESP, (unsigned long)stack_bottom);



--=__Part9FAE9E83.1__=
Content-Type: text/plain; name="x86-Centaur.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="x86-Centaur.patch"

x86: enable VIA CPU support=0A=0ANewer VIA CPUs have both 64-bit and VMX =
support. Enable them to be=0Arecognized for these purposes, at once =
stripping off any 32-bit CPU=0Aonly bits from the respective CPU support =
file.=0A=0AThis particularly implies untying the VMX =3D=3D Intel =
assumption in a few=0Aplaces.=0A=0ASigned-off-by: Jan Beulich <jbeulich@sus=
e.com>=0A=0A---=0Av2: Use cpu_has_vmx instead of comparing hvm_funcs.name, =
as suggested=0A    by Keir. Extend this to also use this and cpu_has_svm =
in=0A    hvm_enable(), making the respective open coded checks in=0A    =
start_{svm,vmx}() unnecessary.=0A=0ANote that my testing of this functional=
ity wasn't as wide as I would=0Ahave hoped it to be, since the box I was =
provided only survived the=0Afirst few days - meanwhile it doesn't stay up =
long enough to just build=0Ahypervisor and tools. Therefore, further fixes =
to fully support these=0ACPUs may be needed as the VIA folks themselves =
get to test that code.=0A=0A--- a/xen/arch/x86/acpi/suspend.c=0A+++ =
b/xen/arch/x86/acpi/suspend.c=0A@@ -32,7 +32,8 @@ void save_rest_processor_=
state(void)=0A     rdmsrl(MSR_SHADOW_GS_BASE, saved_kernel_gs_base);=0A    =
 rdmsrl(MSR_CSTAR, saved_cstar);=0A     rdmsrl(MSR_LSTAR, saved_lstar);=0A-=
    if ( boot_cpu_data.x86_vendor =3D=3D X86_VENDOR_INTEL )=0A+    if ( =
boot_cpu_data.x86_vendor =3D=3D X86_VENDOR_INTEL ||=0A+         boot_cpu_da=
ta.x86_vendor =3D=3D X86_VENDOR_CENTAUR )=0A     {=0A         rdmsrl(MSR_IA=
32_SYSENTER_ESP, saved_sysenter_esp);=0A         rdmsrl(MSR_IA32_SYSENTER_E=
IP, saved_sysenter_eip);=0A@@ -59,7 +60,8 @@ void restore_rest_processor_st=
ate(void)=0A     wrmsrl(MSR_GS_BASE, saved_gs_base);=0A     wrmsrl(MSR_SHAD=
OW_GS_BASE, saved_kernel_gs_base);=0A =0A-    if ( boot_cpu_data.x86_vendor=
 =3D=3D X86_VENDOR_INTEL )=0A+    if ( boot_cpu_data.x86_vendor =3D=3D =
X86_VENDOR_INTEL ||=0A+         boot_cpu_data.x86_vendor =3D=3D X86_VENDOR_=
CENTAUR )=0A     {=0A         /* Recover sysenter MSRs */=0A         =
wrmsrl(MSR_IA32_SYSENTER_ESP, saved_sysenter_esp);=0A--- a/xen/arch/x86/cpu=
/Makefile=0A+++ b/xen/arch/x86/cpu/Makefile=0A@@ -2,10 +2,8 @@ subdir-y =
+=3D mcheck=0A subdir-y +=3D mtrr=0A =0A obj-y +=3D amd.o=0A+obj-y +=3D =
centaur.o=0A obj-y +=3D common.o=0A obj-y +=3D intel.o=0A obj-y +=3D =
intel_cacheinfo.o=0A obj-y +=3D mwait-idle.o=0A-=0A-# Keeping around for =
VIA support (JBeulich)=0A-# obj-$(x86_32) +=3D centaur.o=0A--- a/xen/arch/x=
86/cpu/centaur.c=0A+++ b/xen/arch/x86/cpu/centaur.c=0A@@ -45,51 +45,25 @@ =
static void __init init_c3(struct cpuinf=0A 		c->x86_capability[5=
] =3D cpuid_edx(0xC0000001);=0A 	}=0A =0A-	/* Cyrix III =
family needs CX8 & PGE explicity enabled. */=0A-	if (c->x86_model =
>=3D6 && c->x86_model <=3D 9) {=0A-		rdmsrl(MSR_VIA_FCR, =
msr_content);=0A-		wrmsrl(MSR_VIA_FCR, msr_content | (1ULL << =
1 | 1ULL << 7));=0A-		set_bit(X86_FEATURE_CX8, c->x86_capability)=
;=0A+	if (c->x86 =3D=3D 0x6 && c->x86_model >=3D 0xf) {=0A+		=
c->x86_cache_alignment =3D c->x86_clflush_size * 2;=0A+		set_bit(X86=
_FEATURE_CONSTANT_TSC, c->x86_capability);=0A 	}=0A =0A-	/* Before =
Nehemiah, the C3's had 3dNOW! */=0A-	if (c->x86_model >=3D6 && =
c->x86_model <9)=0A-		set_bit(X86_FEATURE_3DNOW, c->x86_capabilit=
y);=0A-=0A 	get_model_name(c);=0A 	display_cacheinfo(c);=0A }=0A =0A =
static void __init init_centaur(struct cpuinfo_x86 *c)=0A {=0A-	/* Bit 31 =
in normal CPUID used for nonstandard 3DNow ID;=0A-	   3DNow is IDd by =
bit 31 in extended CPUID (1*32+31) anyway */=0A-	clear_bit(0*32+31, =
c->x86_capability);=0A-=0A 	if (c->x86 =3D=3D 6)=0A 		=
init_c3(c);=0A }=0A =0A-static unsigned int centaur_size_cache(struct =
cpuinfo_x86 * c, unsigned int size)=0A-{=0A-	/* VIA C3 CPUs (670-68F) =
need further shifting. */=0A-	if ((c->x86 =3D=3D 6) && ((c->x86_model =
=3D=3D 7) || (c->x86_model =3D=3D 8)))=0A-		size >>=3D =
8;=0A-=0A-	/* VIA also screwed up Nehemiah stepping 1, and made=0A-	=
   it return '65KB' instead of '64KB'=0A-	   - Note, it seems this =
may only be in engineering samples. */=0A-	if ((c->x86=3D=3D6) && =
(c->x86_model=3D=3D9) && (c->x86_mask=3D=3D1) && (size=3D=3D65))=0A-		=
size -=3D1;=0A-=0A-	return size;=0A-}=0A-=0A static struct cpu_dev =
centaur_cpu_dev __cpuinitdata =3D {=0A 	.c_vendor	=3D "Centaur",=0A 	=
.c_ident	=3D { "CentaurHauls" },=0A 	.c_init		=3D =
init_centaur,=0A-	.c_size_cache	=3D centaur_size_cache,=0A };=0A =
=0A int __init centaur_init_cpu(void)=0A@@ -97,5 +71,3 @@ int __init =
centaur_init_cpu(void)=0A 	cpu_devs[X86_VENDOR_CENTAUR] =3D &centaur_c=
pu_dev;=0A 	return 0;=0A }=0A-=0A-//early_arch_initcall(centaur_init_cp=
u);=0A--- a/xen/arch/x86/cpu/common.c=0A+++ b/xen/arch/x86/cpu/common.c=0A@=
@ -522,6 +522,7 @@ void __init early_cpu_init(void)=0A {=0A 	intel_cpu_i=
nit();=0A 	amd_init_cpu();=0A+	centaur_init_cpu();=0A 	early_cpu_d=
etect();=0A }=0A /*=0A--- a/xen/arch/x86/hvm/hvm.c=0A+++ b/xen/arch/x86/hvm=
/hvm.c=0A@@ -111,17 +111,10 @@ static int __init hvm_enable(void)=0A {=0A  =
   struct hvm_function_table *fns =3D NULL;=0A =0A-    switch ( boot_cpu_da=
ta.x86_vendor )=0A-    {=0A-    case X86_VENDOR_INTEL:=0A+    if ( =
cpu_has_vmx )=0A         fns =3D start_vmx();=0A-        break;=0A-    =
case X86_VENDOR_AMD:=0A+    else if ( cpu_has_svm )=0A         fns =3D =
start_svm();=0A-        break;=0A-    default:=0A-        break;=0A-    =
}=0A =0A     if ( fns =3D=3D NULL )=0A         return 0;=0A--- a/xen/arch/x=
86/hvm/nestedhvm.c=0A+++ b/xen/arch/x86/hvm/nestedhvm.c=0A@@ -152,7 +152,7 =
@@ static int __init=0A nestedhvm_setup(void)=0A {=0A     /* Same format =
and size as hvm_io_bitmap (Intel needs only 2 pages). */=0A-    unsigned =
int nr =3D (boot_cpu_data.x86_vendor =3D=3D X86_VENDOR_INTEL) ? 2 : 3;=0A+ =
   unsigned nr =3D cpu_has_vmx ? 2 : 3;=0A     unsigned int i, order =3D =
get_order_from_pages(nr);=0A =0A     if ( !hvm_funcs.name )=0A--- =
a/xen/arch/x86/hvm/svm/svm.c=0A+++ b/xen/arch/x86/hvm/svm/svm.c=0A@@ =
-1240,9 +1240,6 @@ struct hvm_function_table * __init start=0A {=0A     =
bool_t printed =3D 0;=0A =0A-    if ( !test_bit(X86_FEATURE_SVM, &boot_cpu_=
data.x86_capability) )=0A-        return NULL;=0A-=0A     svm_host_osvw_res=
et();=0A =0A     if ( svm_cpu_up() )=0A--- a/xen/arch/x86/hvm/viridian.c=0A=
+++ b/xen/arch/x86/hvm/viridian.c=0A@@ -156,8 +156,7 @@ static void =
enable_hypercall_page(struct=0A     *(u32 *)(p + 1) =3D 0x80000000;=0A     =
*(u8  *)(p + 5) =3D 0x0f; /* vmcall/vmmcall */=0A     *(u8  *)(p + 6) =3D =
0x01;=0A-    *(u8  *)(p + 7) =3D ((boot_cpu_data.x86_vendor =3D=3D =
X86_VENDOR_INTEL)=0A-                       ? 0xc1 : 0xd9);=0A+    *(u8  =
*)(p + 7) =3D (cpu_has_vmx ? 0xc1 : 0xd9);=0A     *(u8  *)(p + 8) =3D =
0xc3; /* ret */=0A     memset(p + 9, 0xcc, PAGE_SIZE - 9); /* int3, int3, =
... */=0A =0A--- a/xen/arch/x86/hvm/vmx/vmx.c=0A+++ b/xen/arch/x86/hvm/vmx/=
vmx.c=0A@@ -1516,9 +1516,6 @@ static struct hvm_function_table __read_=0A =
=0A struct hvm_function_table * __init start_vmx(void)=0A {=0A-    if ( =
!test_bit(X86_FEATURE_VMXE, &boot_cpu_data.x86_capability) )=0A-        =
return NULL;=0A-=0A     set_in_cr4(X86_CR4_VMXE);=0A =0A     if ( =
vmx_cpu_up() )=0A--- a/xen/arch/x86/mm/mem_event.c=0A+++ b/xen/arch/x86/mm/=
mem_event.c=0A@@ -608,7 +608,7 @@ int mem_event_domctl(struct domain *d, =
x=0A                 break;=0A =0A             /* Currently only EPT is =
supported */=0A-            if ( boot_cpu_data.x86_vendor !=3D X86_VENDOR_I=
NTEL )=0A+            if ( !cpu_has_vmx )=0A                 break;=0A =0A =
            rc =3D mem_event_enable(d, mec, med, _VPF_mem_access, =0A--- =
a/xen/arch/x86/mm/p2m.c=0A+++ b/xen/arch/x86/mm/p2m.c=0A@@ -83,7 +83,7 @@ =
static void p2m_initialise(struct domain=0A =0A     p2m->cr3 =3D CR3_EADDR;=
=0A =0A-    if ( hap_enabled(d) && (boot_cpu_data.x86_vendor =3D=3D =
X86_VENDOR_INTEL) )=0A+    if ( hap_enabled(d) && cpu_has_vmx )=0A         =
ept_p2m_init(p2m);=0A     else=0A         p2m_pt_init(p2m);=0A--- =
a/xen/arch/x86/x86_64/traps.c=0A+++ b/xen/arch/x86/x86_64/traps.c=0A@@ =
-399,7 +399,8 @@ void __devinit subarch_percpu_traps_init=0A     wrmsrl(MSR=
_LSTAR, (unsigned long)stack);=0A     stack +=3D write_stack_trampoline(sta=
ck, stack_bottom, FLAT_KERNEL_CS64);=0A =0A-    if ( boot_cpu_data.x86_vend=
or =3D=3D X86_VENDOR_INTEL )=0A+    if ( boot_cpu_data.x86_vendor =3D=3D =
X86_VENDOR_INTEL ||=0A+         boot_cpu_data.x86_vendor =3D=3D X86_VENDOR_=
CENTAUR )=0A     {=0A         /* SYSENTER entry. */=0A         wrmsrl(MSR_I=
A32_SYSENTER_ESP, (unsigned long)stack_bottom);=0A
--=__Part9FAE9E83.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

--=__Part9FAE9E83.1__=--


From xen-devel-bounces@lists.xen.org Fri Sep 21 14:25:06 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Sep 2012 14:25:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TF49r-00086r-AV; Fri, 21 Sep 2012 14:24:43 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1TF49q-00086m-8I
	for xen-devel@lists.xen.org; Fri, 21 Sep 2012 14:24:42 +0000
Received: from [85.158.138.51:7006] by server-15.bemta-3.messagelabs.com id
	A3/EB-09665-9A87C505; Fri, 21 Sep 2012 14:24:41 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1348237480!31446617!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18923 invoked from network); 21 Sep 2012 14:24:40 -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;
	21 Sep 2012 14:24:40 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 21 Sep 2012 15:25:53 +0100
Message-Id: <505C94B3020000780009D06A@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 21 Sep 2012 15:24:19 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Keir Fraser" <keir.xen@gmail.com>
References: <505C6E68020000780009CF34@nat28.tlf.novell.com>
	<CC82226A.3F5F0%keir.xen@gmail.com>
In-Reply-To: <CC82226A.3F5F0%keir.xen@gmail.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part9FAE9E83.1__="
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: [Xen-devel] [PATCH, v2] x86: enable VIA CPU 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

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.

--=__Part9FAE9E83.1__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Newer VIA CPUs have both 64-bit and VMX support. Enable them to be
recognized for these purposes, at once stripping off any 32-bit CPU
only bits from the respective CPU support file.

This particularly implies untying the VMX =3D=3D Intel assumption in a few
places.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

---
v2: Use cpu_has_vmx instead of comparing hvm_funcs.name, as suggested
    by Keir. Extend this to also use this and cpu_has_svm in
    hvm_enable(), making the respective open coded checks in
    start_{svm,vmx}() unnecessary.

Note that my testing of this functionality wasn't as wide as I would
have hoped it to be, since the box I was provided only survived the
first few days - meanwhile it doesn't stay up long enough to just build
hypervisor and tools. Therefore, further fixes to fully support these
CPUs may be needed as the VIA folks themselves get to test that code.

--- a/xen/arch/x86/acpi/suspend.c
+++ b/xen/arch/x86/acpi/suspend.c
@@ -32,7 +32,8 @@ void save_rest_processor_state(void)
     rdmsrl(MSR_SHADOW_GS_BASE, saved_kernel_gs_base);
     rdmsrl(MSR_CSTAR, saved_cstar);
     rdmsrl(MSR_LSTAR, saved_lstar);
-    if ( boot_cpu_data.x86_vendor =3D=3D X86_VENDOR_INTEL )
+    if ( boot_cpu_data.x86_vendor =3D=3D X86_VENDOR_INTEL ||
+         boot_cpu_data.x86_vendor =3D=3D X86_VENDOR_CENTAUR )
     {
         rdmsrl(MSR_IA32_SYSENTER_ESP, saved_sysenter_esp);
         rdmsrl(MSR_IA32_SYSENTER_EIP, saved_sysenter_eip);
@@ -59,7 +60,8 @@ void restore_rest_processor_state(void)
     wrmsrl(MSR_GS_BASE, saved_gs_base);
     wrmsrl(MSR_SHADOW_GS_BASE, saved_kernel_gs_base);
=20
-    if ( boot_cpu_data.x86_vendor =3D=3D X86_VENDOR_INTEL )
+    if ( boot_cpu_data.x86_vendor =3D=3D X86_VENDOR_INTEL ||
+         boot_cpu_data.x86_vendor =3D=3D X86_VENDOR_CENTAUR )
     {
         /* Recover sysenter MSRs */
         wrmsrl(MSR_IA32_SYSENTER_ESP, saved_sysenter_esp);
--- a/xen/arch/x86/cpu/Makefile
+++ b/xen/arch/x86/cpu/Makefile
@@ -2,10 +2,8 @@ subdir-y +=3D mcheck
 subdir-y +=3D mtrr
=20
 obj-y +=3D amd.o
+obj-y +=3D centaur.o
 obj-y +=3D common.o
 obj-y +=3D intel.o
 obj-y +=3D intel_cacheinfo.o
 obj-y +=3D mwait-idle.o
-
-# Keeping around for VIA support (JBeulich)
-# obj-$(x86_32) +=3D centaur.o
--- a/xen/arch/x86/cpu/centaur.c
+++ b/xen/arch/x86/cpu/centaur.c
@@ -45,51 +45,25 @@ static void __init init_c3(struct cpuinf
 		c->x86_capability[5] =3D cpuid_edx(0xC0000001);
 	}
=20
-	/* Cyrix III family needs CX8 & PGE explicity enabled. */
-	if (c->x86_model >=3D6 && c->x86_model <=3D 9) {
-		rdmsrl(MSR_VIA_FCR, msr_content);
-		wrmsrl(MSR_VIA_FCR, msr_content | (1ULL << 1 | 1ULL << =
7));
-		set_bit(X86_FEATURE_CX8, c->x86_capability);
+	if (c->x86 =3D=3D 0x6 && c->x86_model >=3D 0xf) {
+		c->x86_cache_alignment =3D c->x86_clflush_size * 2;
+		set_bit(X86_FEATURE_CONSTANT_TSC, c->x86_capability);
 	}
=20
-	/* Before Nehemiah, the C3's had 3dNOW! */
-	if (c->x86_model >=3D6 && c->x86_model <9)
-		set_bit(X86_FEATURE_3DNOW, c->x86_capability);
-
 	get_model_name(c);
 	display_cacheinfo(c);
 }
=20
 static void __init init_centaur(struct cpuinfo_x86 *c)
 {
-	/* Bit 31 in normal CPUID used for nonstandard 3DNow ID;
-	   3DNow is IDd by bit 31 in extended CPUID (1*32+31) anyway */
-	clear_bit(0*32+31, c->x86_capability);
-
 	if (c->x86 =3D=3D 6)
 		init_c3(c);
 }
=20
-static unsigned int centaur_size_cache(struct cpuinfo_x86 * c, unsigned =
int size)
-{
-	/* VIA C3 CPUs (670-68F) need further shifting. */
-	if ((c->x86 =3D=3D 6) && ((c->x86_model =3D=3D 7) || (c->x86_model =
=3D=3D 8)))
-		size >>=3D 8;
-
-	/* VIA also screwed up Nehemiah stepping 1, and made
-	   it return '65KB' instead of '64KB'
-	   - Note, it seems this may only be in engineering samples. */
-	if ((c->x86=3D=3D6) && (c->x86_model=3D=3D9) && (c->x86_mask=3D=3D1=
) && (size=3D=3D65))
-		size -=3D1;
-
-	return size;
-}
-
 static struct cpu_dev centaur_cpu_dev __cpuinitdata =3D {
 	.c_vendor	=3D "Centaur",
 	.c_ident	=3D { "CentaurHauls" },
 	.c_init		=3D init_centaur,
-	.c_size_cache	=3D centaur_size_cache,
 };
=20
 int __init centaur_init_cpu(void)
@@ -97,5 +71,3 @@ int __init centaur_init_cpu(void)
 	cpu_devs[X86_VENDOR_CENTAUR] =3D &centaur_cpu_dev;
 	return 0;
 }
-
-//early_arch_initcall(centaur_init_cpu);
--- a/xen/arch/x86/cpu/common.c
+++ b/xen/arch/x86/cpu/common.c
@@ -522,6 +522,7 @@ void __init early_cpu_init(void)
 {
 	intel_cpu_init();
 	amd_init_cpu();
+	centaur_init_cpu();
 	early_cpu_detect();
 }
 /*
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -111,17 +111,10 @@ static int __init hvm_enable(void)
 {
     struct hvm_function_table *fns =3D NULL;
=20
-    switch ( boot_cpu_data.x86_vendor )
-    {
-    case X86_VENDOR_INTEL:
+    if ( cpu_has_vmx )
         fns =3D start_vmx();
-        break;
-    case X86_VENDOR_AMD:
+    else if ( cpu_has_svm )
         fns =3D start_svm();
-        break;
-    default:
-        break;
-    }
=20
     if ( fns =3D=3D NULL )
         return 0;
--- a/xen/arch/x86/hvm/nestedhvm.c
+++ b/xen/arch/x86/hvm/nestedhvm.c
@@ -152,7 +152,7 @@ static int __init
 nestedhvm_setup(void)
 {
     /* Same format and size as hvm_io_bitmap (Intel needs only 2 pages). =
*/
-    unsigned int nr =3D (boot_cpu_data.x86_vendor =3D=3D X86_VENDOR_INTEL)=
 ? 2 : 3;
+    unsigned nr =3D cpu_has_vmx ? 2 : 3;
     unsigned int i, order =3D get_order_from_pages(nr);
=20
     if ( !hvm_funcs.name )
--- a/xen/arch/x86/hvm/svm/svm.c
+++ b/xen/arch/x86/hvm/svm/svm.c
@@ -1240,9 +1240,6 @@ struct hvm_function_table * __init start
 {
     bool_t printed =3D 0;
=20
-    if ( !test_bit(X86_FEATURE_SVM, &boot_cpu_data.x86_capability) )
-        return NULL;
-
     svm_host_osvw_reset();
=20
     if ( svm_cpu_up() )
--- a/xen/arch/x86/hvm/viridian.c
+++ b/xen/arch/x86/hvm/viridian.c
@@ -156,8 +156,7 @@ static void enable_hypercall_page(struct
     *(u32 *)(p + 1) =3D 0x80000000;
     *(u8  *)(p + 5) =3D 0x0f; /* vmcall/vmmcall */
     *(u8  *)(p + 6) =3D 0x01;
-    *(u8  *)(p + 7) =3D ((boot_cpu_data.x86_vendor =3D=3D X86_VENDOR_INTEL=
)
-                       ? 0xc1 : 0xd9);
+    *(u8  *)(p + 7) =3D (cpu_has_vmx ? 0xc1 : 0xd9);
     *(u8  *)(p + 8) =3D 0xc3; /* ret */
     memset(p + 9, 0xcc, PAGE_SIZE - 9); /* int3, int3, ... */
=20
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -1516,9 +1516,6 @@ static struct hvm_function_table __read_
=20
 struct hvm_function_table * __init start_vmx(void)
 {
-    if ( !test_bit(X86_FEATURE_VMXE, &boot_cpu_data.x86_capability) )
-        return NULL;
-
     set_in_cr4(X86_CR4_VMXE);
=20
     if ( vmx_cpu_up() )
--- a/xen/arch/x86/mm/mem_event.c
+++ b/xen/arch/x86/mm/mem_event.c
@@ -608,7 +608,7 @@ int mem_event_domctl(struct domain *d, x
                 break;
=20
             /* Currently only EPT is supported */
-            if ( boot_cpu_data.x86_vendor !=3D X86_VENDOR_INTEL )
+            if ( !cpu_has_vmx )
                 break;
=20
             rc =3D mem_event_enable(d, mec, med, _VPF_mem_access,=20
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -83,7 +83,7 @@ static void p2m_initialise(struct domain
=20
     p2m->cr3 =3D CR3_EADDR;
=20
-    if ( hap_enabled(d) && (boot_cpu_data.x86_vendor =3D=3D X86_VENDOR_INT=
EL) )
+    if ( hap_enabled(d) && cpu_has_vmx )
         ept_p2m_init(p2m);
     else
         p2m_pt_init(p2m);
--- a/xen/arch/x86/x86_64/traps.c
+++ b/xen/arch/x86/x86_64/traps.c
@@ -399,7 +399,8 @@ void __devinit subarch_percpu_traps_init
     wrmsrl(MSR_LSTAR, (unsigned long)stack);
     stack +=3D write_stack_trampoline(stack, stack_bottom, FLAT_KERNEL_CS6=
4);
=20
-    if ( boot_cpu_data.x86_vendor =3D=3D X86_VENDOR_INTEL )
+    if ( boot_cpu_data.x86_vendor =3D=3D X86_VENDOR_INTEL ||
+         boot_cpu_data.x86_vendor =3D=3D X86_VENDOR_CENTAUR )
     {
         /* SYSENTER entry. */
         wrmsrl(MSR_IA32_SYSENTER_ESP, (unsigned long)stack_bottom);



--=__Part9FAE9E83.1__=
Content-Type: text/plain; name="x86-Centaur.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="x86-Centaur.patch"

x86: enable VIA CPU support=0A=0ANewer VIA CPUs have both 64-bit and VMX =
support. Enable them to be=0Arecognized for these purposes, at once =
stripping off any 32-bit CPU=0Aonly bits from the respective CPU support =
file.=0A=0AThis particularly implies untying the VMX =3D=3D Intel =
assumption in a few=0Aplaces.=0A=0ASigned-off-by: Jan Beulich <jbeulich@sus=
e.com>=0A=0A---=0Av2: Use cpu_has_vmx instead of comparing hvm_funcs.name, =
as suggested=0A    by Keir. Extend this to also use this and cpu_has_svm =
in=0A    hvm_enable(), making the respective open coded checks in=0A    =
start_{svm,vmx}() unnecessary.=0A=0ANote that my testing of this functional=
ity wasn't as wide as I would=0Ahave hoped it to be, since the box I was =
provided only survived the=0Afirst few days - meanwhile it doesn't stay up =
long enough to just build=0Ahypervisor and tools. Therefore, further fixes =
to fully support these=0ACPUs may be needed as the VIA folks themselves =
get to test that code.=0A=0A--- a/xen/arch/x86/acpi/suspend.c=0A+++ =
b/xen/arch/x86/acpi/suspend.c=0A@@ -32,7 +32,8 @@ void save_rest_processor_=
state(void)=0A     rdmsrl(MSR_SHADOW_GS_BASE, saved_kernel_gs_base);=0A    =
 rdmsrl(MSR_CSTAR, saved_cstar);=0A     rdmsrl(MSR_LSTAR, saved_lstar);=0A-=
    if ( boot_cpu_data.x86_vendor =3D=3D X86_VENDOR_INTEL )=0A+    if ( =
boot_cpu_data.x86_vendor =3D=3D X86_VENDOR_INTEL ||=0A+         boot_cpu_da=
ta.x86_vendor =3D=3D X86_VENDOR_CENTAUR )=0A     {=0A         rdmsrl(MSR_IA=
32_SYSENTER_ESP, saved_sysenter_esp);=0A         rdmsrl(MSR_IA32_SYSENTER_E=
IP, saved_sysenter_eip);=0A@@ -59,7 +60,8 @@ void restore_rest_processor_st=
ate(void)=0A     wrmsrl(MSR_GS_BASE, saved_gs_base);=0A     wrmsrl(MSR_SHAD=
OW_GS_BASE, saved_kernel_gs_base);=0A =0A-    if ( boot_cpu_data.x86_vendor=
 =3D=3D X86_VENDOR_INTEL )=0A+    if ( boot_cpu_data.x86_vendor =3D=3D =
X86_VENDOR_INTEL ||=0A+         boot_cpu_data.x86_vendor =3D=3D X86_VENDOR_=
CENTAUR )=0A     {=0A         /* Recover sysenter MSRs */=0A         =
wrmsrl(MSR_IA32_SYSENTER_ESP, saved_sysenter_esp);=0A--- a/xen/arch/x86/cpu=
/Makefile=0A+++ b/xen/arch/x86/cpu/Makefile=0A@@ -2,10 +2,8 @@ subdir-y =
+=3D mcheck=0A subdir-y +=3D mtrr=0A =0A obj-y +=3D amd.o=0A+obj-y +=3D =
centaur.o=0A obj-y +=3D common.o=0A obj-y +=3D intel.o=0A obj-y +=3D =
intel_cacheinfo.o=0A obj-y +=3D mwait-idle.o=0A-=0A-# Keeping around for =
VIA support (JBeulich)=0A-# obj-$(x86_32) +=3D centaur.o=0A--- a/xen/arch/x=
86/cpu/centaur.c=0A+++ b/xen/arch/x86/cpu/centaur.c=0A@@ -45,51 +45,25 @@ =
static void __init init_c3(struct cpuinf=0A 		c->x86_capability[5=
] =3D cpuid_edx(0xC0000001);=0A 	}=0A =0A-	/* Cyrix III =
family needs CX8 & PGE explicity enabled. */=0A-	if (c->x86_model =
>=3D6 && c->x86_model <=3D 9) {=0A-		rdmsrl(MSR_VIA_FCR, =
msr_content);=0A-		wrmsrl(MSR_VIA_FCR, msr_content | (1ULL << =
1 | 1ULL << 7));=0A-		set_bit(X86_FEATURE_CX8, c->x86_capability)=
;=0A+	if (c->x86 =3D=3D 0x6 && c->x86_model >=3D 0xf) {=0A+		=
c->x86_cache_alignment =3D c->x86_clflush_size * 2;=0A+		set_bit(X86=
_FEATURE_CONSTANT_TSC, c->x86_capability);=0A 	}=0A =0A-	/* Before =
Nehemiah, the C3's had 3dNOW! */=0A-	if (c->x86_model >=3D6 && =
c->x86_model <9)=0A-		set_bit(X86_FEATURE_3DNOW, c->x86_capabilit=
y);=0A-=0A 	get_model_name(c);=0A 	display_cacheinfo(c);=0A }=0A =0A =
static void __init init_centaur(struct cpuinfo_x86 *c)=0A {=0A-	/* Bit 31 =
in normal CPUID used for nonstandard 3DNow ID;=0A-	   3DNow is IDd by =
bit 31 in extended CPUID (1*32+31) anyway */=0A-	clear_bit(0*32+31, =
c->x86_capability);=0A-=0A 	if (c->x86 =3D=3D 6)=0A 		=
init_c3(c);=0A }=0A =0A-static unsigned int centaur_size_cache(struct =
cpuinfo_x86 * c, unsigned int size)=0A-{=0A-	/* VIA C3 CPUs (670-68F) =
need further shifting. */=0A-	if ((c->x86 =3D=3D 6) && ((c->x86_model =
=3D=3D 7) || (c->x86_model =3D=3D 8)))=0A-		size >>=3D =
8;=0A-=0A-	/* VIA also screwed up Nehemiah stepping 1, and made=0A-	=
   it return '65KB' instead of '64KB'=0A-	   - Note, it seems this =
may only be in engineering samples. */=0A-	if ((c->x86=3D=3D6) && =
(c->x86_model=3D=3D9) && (c->x86_mask=3D=3D1) && (size=3D=3D65))=0A-		=
size -=3D1;=0A-=0A-	return size;=0A-}=0A-=0A static struct cpu_dev =
centaur_cpu_dev __cpuinitdata =3D {=0A 	.c_vendor	=3D "Centaur",=0A 	=
.c_ident	=3D { "CentaurHauls" },=0A 	.c_init		=3D =
init_centaur,=0A-	.c_size_cache	=3D centaur_size_cache,=0A };=0A =
=0A int __init centaur_init_cpu(void)=0A@@ -97,5 +71,3 @@ int __init =
centaur_init_cpu(void)=0A 	cpu_devs[X86_VENDOR_CENTAUR] =3D &centaur_c=
pu_dev;=0A 	return 0;=0A }=0A-=0A-//early_arch_initcall(centaur_init_cp=
u);=0A--- a/xen/arch/x86/cpu/common.c=0A+++ b/xen/arch/x86/cpu/common.c=0A@=
@ -522,6 +522,7 @@ void __init early_cpu_init(void)=0A {=0A 	intel_cpu_i=
nit();=0A 	amd_init_cpu();=0A+	centaur_init_cpu();=0A 	early_cpu_d=
etect();=0A }=0A /*=0A--- a/xen/arch/x86/hvm/hvm.c=0A+++ b/xen/arch/x86/hvm=
/hvm.c=0A@@ -111,17 +111,10 @@ static int __init hvm_enable(void)=0A {=0A  =
   struct hvm_function_table *fns =3D NULL;=0A =0A-    switch ( boot_cpu_da=
ta.x86_vendor )=0A-    {=0A-    case X86_VENDOR_INTEL:=0A+    if ( =
cpu_has_vmx )=0A         fns =3D start_vmx();=0A-        break;=0A-    =
case X86_VENDOR_AMD:=0A+    else if ( cpu_has_svm )=0A         fns =3D =
start_svm();=0A-        break;=0A-    default:=0A-        break;=0A-    =
}=0A =0A     if ( fns =3D=3D NULL )=0A         return 0;=0A--- a/xen/arch/x=
86/hvm/nestedhvm.c=0A+++ b/xen/arch/x86/hvm/nestedhvm.c=0A@@ -152,7 +152,7 =
@@ static int __init=0A nestedhvm_setup(void)=0A {=0A     /* Same format =
and size as hvm_io_bitmap (Intel needs only 2 pages). */=0A-    unsigned =
int nr =3D (boot_cpu_data.x86_vendor =3D=3D X86_VENDOR_INTEL) ? 2 : 3;=0A+ =
   unsigned nr =3D cpu_has_vmx ? 2 : 3;=0A     unsigned int i, order =3D =
get_order_from_pages(nr);=0A =0A     if ( !hvm_funcs.name )=0A--- =
a/xen/arch/x86/hvm/svm/svm.c=0A+++ b/xen/arch/x86/hvm/svm/svm.c=0A@@ =
-1240,9 +1240,6 @@ struct hvm_function_table * __init start=0A {=0A     =
bool_t printed =3D 0;=0A =0A-    if ( !test_bit(X86_FEATURE_SVM, &boot_cpu_=
data.x86_capability) )=0A-        return NULL;=0A-=0A     svm_host_osvw_res=
et();=0A =0A     if ( svm_cpu_up() )=0A--- a/xen/arch/x86/hvm/viridian.c=0A=
+++ b/xen/arch/x86/hvm/viridian.c=0A@@ -156,8 +156,7 @@ static void =
enable_hypercall_page(struct=0A     *(u32 *)(p + 1) =3D 0x80000000;=0A     =
*(u8  *)(p + 5) =3D 0x0f; /* vmcall/vmmcall */=0A     *(u8  *)(p + 6) =3D =
0x01;=0A-    *(u8  *)(p + 7) =3D ((boot_cpu_data.x86_vendor =3D=3D =
X86_VENDOR_INTEL)=0A-                       ? 0xc1 : 0xd9);=0A+    *(u8  =
*)(p + 7) =3D (cpu_has_vmx ? 0xc1 : 0xd9);=0A     *(u8  *)(p + 8) =3D =
0xc3; /* ret */=0A     memset(p + 9, 0xcc, PAGE_SIZE - 9); /* int3, int3, =
... */=0A =0A--- a/xen/arch/x86/hvm/vmx/vmx.c=0A+++ b/xen/arch/x86/hvm/vmx/=
vmx.c=0A@@ -1516,9 +1516,6 @@ static struct hvm_function_table __read_=0A =
=0A struct hvm_function_table * __init start_vmx(void)=0A {=0A-    if ( =
!test_bit(X86_FEATURE_VMXE, &boot_cpu_data.x86_capability) )=0A-        =
return NULL;=0A-=0A     set_in_cr4(X86_CR4_VMXE);=0A =0A     if ( =
vmx_cpu_up() )=0A--- a/xen/arch/x86/mm/mem_event.c=0A+++ b/xen/arch/x86/mm/=
mem_event.c=0A@@ -608,7 +608,7 @@ int mem_event_domctl(struct domain *d, =
x=0A                 break;=0A =0A             /* Currently only EPT is =
supported */=0A-            if ( boot_cpu_data.x86_vendor !=3D X86_VENDOR_I=
NTEL )=0A+            if ( !cpu_has_vmx )=0A                 break;=0A =0A =
            rc =3D mem_event_enable(d, mec, med, _VPF_mem_access, =0A--- =
a/xen/arch/x86/mm/p2m.c=0A+++ b/xen/arch/x86/mm/p2m.c=0A@@ -83,7 +83,7 @@ =
static void p2m_initialise(struct domain=0A =0A     p2m->cr3 =3D CR3_EADDR;=
=0A =0A-    if ( hap_enabled(d) && (boot_cpu_data.x86_vendor =3D=3D =
X86_VENDOR_INTEL) )=0A+    if ( hap_enabled(d) && cpu_has_vmx )=0A         =
ept_p2m_init(p2m);=0A     else=0A         p2m_pt_init(p2m);=0A--- =
a/xen/arch/x86/x86_64/traps.c=0A+++ b/xen/arch/x86/x86_64/traps.c=0A@@ =
-399,7 +399,8 @@ void __devinit subarch_percpu_traps_init=0A     wrmsrl(MSR=
_LSTAR, (unsigned long)stack);=0A     stack +=3D write_stack_trampoline(sta=
ck, stack_bottom, FLAT_KERNEL_CS64);=0A =0A-    if ( boot_cpu_data.x86_vend=
or =3D=3D X86_VENDOR_INTEL )=0A+    if ( boot_cpu_data.x86_vendor =3D=3D =
X86_VENDOR_INTEL ||=0A+         boot_cpu_data.x86_vendor =3D=3D X86_VENDOR_=
CENTAUR )=0A     {=0A         /* SYSENTER entry. */=0A         wrmsrl(MSR_I=
A32_SYSENTER_ESP, (unsigned long)stack_bottom);=0A
--=__Part9FAE9E83.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

--=__Part9FAE9E83.1__=--


From xen-devel-bounces@lists.xen.org Fri Sep 21 14:30:39 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Sep 2012 14:30:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TF4FF-0008Gw-9s; Fri, 21 Sep 2012 14:30:17 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony.perard@gmail.com>) id 1TF4FD-0008Gn-Gt
	for xen-devel@lists.xen.org; Fri, 21 Sep 2012 14:30:15 +0000
Received: from [85.158.137.99:7480] by server-9.bemta-3.messagelabs.com id
	F4/3D-15390-6F97C505; Fri, 21 Sep 2012 14:30:14 +0000
X-Env-Sender: anthony.perard@gmail.com
X-Msg-Ref: server-3.tower-217.messagelabs.com!1348237812!13562265!1
X-Originating-IP: [209.85.223.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24213 invoked from network); 21 Sep 2012 14:30:13 -0000
Received: from mail-ie0-f173.google.com (HELO mail-ie0-f173.google.com)
	(209.85.223.173)
	by server-3.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Sep 2012 14:30:13 -0000
Received: by iea17 with SMTP id 17so1445796iea.32
	for <xen-devel@lists.xen.org>; Fri, 21 Sep 2012 07:30: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:from:date
	:x-google-sender-auth:message-id:subject:to:cc:content-type;
	bh=qxfjUsZOKPPfIAOFRjUl8SE84vIcUSFg1m8pueRqqsI=;
	b=CcvoeWv5/Wag3GS4VuJjrbaBleltQqfmAMt+wRXJT6ViicYBwNsoxuWULhjM2aVslm
	O+8yL+dRXnW2Ory/Yosvg6TyN5wjFoHzEhvG50MTPDp8pUXA5iV+KlR6PmqC5hUT8ahX
	+bRnJDrAAszfQhqC8Ptr9j3BYKupjablj+1J3gy9yeK2U/LwQZrlty99Pg7kVdpOGjmw
	JJQyDms7V5NdK3HrhGA8C2fXkbGih0LDlJoy5oO7c1j9mnkIa4A4BZu7vZcr11Bi1QIj
	wfyXVXvqHt7/jFOUi6bLFGSYL49R9qQstVtz2TsjqLDmG8b66dnl4i9xYXxRVhazbelS
	DYIw==
Received: by 10.43.16.67 with SMTP id px3mr4086952icb.17.1348237811678; Fri,
	21 Sep 2012 07:30:11 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.64.126.131 with HTTP; Fri, 21 Sep 2012 07:29:40 -0700 (PDT)
In-Reply-To: <alpine.DEB.2.02.1209201328030.29232@kaball.uk.xensource.com>
References: <1348139574-23324-1-git-send-email-anthony.perard@citrix.com>
	<1348139574-23324-3-git-send-email-anthony.perard@citrix.com>
	<alpine.DEB.2.02.1209201328030.29232@kaball.uk.xensource.com>
From: Anthony PERARD <anthony.perard@citrix.com>
Date: Fri, 21 Sep 2012 15:29:40 +0100
X-Google-Sender-Auth: 3sfHMHQDQJKBxFxTgMZbWqtXsGw
Message-ID: <CAJJyHj+T0x-1sTJvVRJVTP6Q4oUDEBPQ_9S5yS1tQZj_VVx8Sg@mail.gmail.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: QEMU-devel <qemu-devel@nongnu.org>, Xen Devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [Qemu-devel] [PATCH V3 2/5] xen: Introduce
	xen_modified_memory.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Sep 20, 2012 at 1:29 PM, Stefano Stabellini
<stefano.stabellini@eu.citrix.com> wrote:
>
>> +void xen_modified_memory(ram_addr_t start, ram_addr_t length)
>> +{
>> +    if (unlikely(xen_in_migration)) {
>> +        int rc;
>> +        ram_addr_t start_pfn, nb_pages;
>> +
>> +        if (length == 0) {
>> +            length = TARGET_PAGE_SIZE;
>> +        }
>> +        start_pfn = start >> TARGET_PAGE_BITS;
>> +        nb_pages = ((start + length + TARGET_PAGE_SIZE - 1) >> TARGET_PAGE_BITS)
>> +            - start_pfn;
>> +        rc = xc_hvm_modified_memory(xen_xc, xen_domid, start_pfn, nb_pages);
>> +        if (rc) {
>> +            fprintf(stderr, "%s failed for "RAM_ADDR_FMT" ("RAM_ADDR_FMT
>> +                    "): %i, %s\n", __func__,
>> +                    start, nb_pages, rc, strerror(-rc));
>
> a would prefer a more sane way of splitting this sentence in lines

Will do.

-- 
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 Sep 21 14:30:39 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Sep 2012 14:30:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TF4FF-0008Gw-9s; Fri, 21 Sep 2012 14:30:17 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony.perard@gmail.com>) id 1TF4FD-0008Gn-Gt
	for xen-devel@lists.xen.org; Fri, 21 Sep 2012 14:30:15 +0000
Received: from [85.158.137.99:7480] by server-9.bemta-3.messagelabs.com id
	F4/3D-15390-6F97C505; Fri, 21 Sep 2012 14:30:14 +0000
X-Env-Sender: anthony.perard@gmail.com
X-Msg-Ref: server-3.tower-217.messagelabs.com!1348237812!13562265!1
X-Originating-IP: [209.85.223.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24213 invoked from network); 21 Sep 2012 14:30:13 -0000
Received: from mail-ie0-f173.google.com (HELO mail-ie0-f173.google.com)
	(209.85.223.173)
	by server-3.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Sep 2012 14:30:13 -0000
Received: by iea17 with SMTP id 17so1445796iea.32
	for <xen-devel@lists.xen.org>; Fri, 21 Sep 2012 07:30: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:from:date
	:x-google-sender-auth:message-id:subject:to:cc:content-type;
	bh=qxfjUsZOKPPfIAOFRjUl8SE84vIcUSFg1m8pueRqqsI=;
	b=CcvoeWv5/Wag3GS4VuJjrbaBleltQqfmAMt+wRXJT6ViicYBwNsoxuWULhjM2aVslm
	O+8yL+dRXnW2Ory/Yosvg6TyN5wjFoHzEhvG50MTPDp8pUXA5iV+KlR6PmqC5hUT8ahX
	+bRnJDrAAszfQhqC8Ptr9j3BYKupjablj+1J3gy9yeK2U/LwQZrlty99Pg7kVdpOGjmw
	JJQyDms7V5NdK3HrhGA8C2fXkbGih0LDlJoy5oO7c1j9mnkIa4A4BZu7vZcr11Bi1QIj
	wfyXVXvqHt7/jFOUi6bLFGSYL49R9qQstVtz2TsjqLDmG8b66dnl4i9xYXxRVhazbelS
	DYIw==
Received: by 10.43.16.67 with SMTP id px3mr4086952icb.17.1348237811678; Fri,
	21 Sep 2012 07:30:11 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.64.126.131 with HTTP; Fri, 21 Sep 2012 07:29:40 -0700 (PDT)
In-Reply-To: <alpine.DEB.2.02.1209201328030.29232@kaball.uk.xensource.com>
References: <1348139574-23324-1-git-send-email-anthony.perard@citrix.com>
	<1348139574-23324-3-git-send-email-anthony.perard@citrix.com>
	<alpine.DEB.2.02.1209201328030.29232@kaball.uk.xensource.com>
From: Anthony PERARD <anthony.perard@citrix.com>
Date: Fri, 21 Sep 2012 15:29:40 +0100
X-Google-Sender-Auth: 3sfHMHQDQJKBxFxTgMZbWqtXsGw
Message-ID: <CAJJyHj+T0x-1sTJvVRJVTP6Q4oUDEBPQ_9S5yS1tQZj_VVx8Sg@mail.gmail.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: QEMU-devel <qemu-devel@nongnu.org>, Xen Devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [Qemu-devel] [PATCH V3 2/5] xen: Introduce
	xen_modified_memory.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Sep 20, 2012 at 1:29 PM, Stefano Stabellini
<stefano.stabellini@eu.citrix.com> wrote:
>
>> +void xen_modified_memory(ram_addr_t start, ram_addr_t length)
>> +{
>> +    if (unlikely(xen_in_migration)) {
>> +        int rc;
>> +        ram_addr_t start_pfn, nb_pages;
>> +
>> +        if (length == 0) {
>> +            length = TARGET_PAGE_SIZE;
>> +        }
>> +        start_pfn = start >> TARGET_PAGE_BITS;
>> +        nb_pages = ((start + length + TARGET_PAGE_SIZE - 1) >> TARGET_PAGE_BITS)
>> +            - start_pfn;
>> +        rc = xc_hvm_modified_memory(xen_xc, xen_domid, start_pfn, nb_pages);
>> +        if (rc) {
>> +            fprintf(stderr, "%s failed for "RAM_ADDR_FMT" ("RAM_ADDR_FMT
>> +                    "): %i, %s\n", __func__,
>> +                    start, nb_pages, rc, strerror(-rc));
>
> a would prefer a more sane way of splitting this sentence in lines

Will do.

-- 
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 Sep 21 14:34:46 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Sep 2012 14:34:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TF4JK-0008RE-VW; Fri, 21 Sep 2012 14:34:30 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony.perard@gmail.com>) id 1TF4JI-0008R1-Pz
	for xen-devel@lists.xen.org; Fri, 21 Sep 2012 14:34:29 +0000
Received: from [85.158.138.51:7846] by server-11.bemta-3.messagelabs.com id
	01/3C-30250-3FA7C505; Fri, 21 Sep 2012 14:34:27 +0000
X-Env-Sender: anthony.perard@gmail.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1348238066!29802260!1
X-Originating-IP: [209.85.223.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6284 invoked from network); 21 Sep 2012 14:34:27 -0000
Received: from mail-ie0-f173.google.com (HELO mail-ie0-f173.google.com)
	(209.85.223.173)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Sep 2012 14:34:27 -0000
Received: by iea17 with SMTP id 17so1460763iea.32
	for <xen-devel@lists.xen.org>; Fri, 21 Sep 2012 07:34: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:from:date
	:x-google-sender-auth:message-id:subject:to:cc:content-type;
	bh=RbQ5SFkyR6FWGY9zF25sQEVdJNrYhj55tQfDAqEY1GI=;
	b=co56w5lqHQVDDe1z8fLGFQDyP9ln0lhlcmb+2Il8V23QZnFT75S6C1bl+DHLd/fs1k
	TG+WLfHjIpNJCb1DrQW2JeT0yE44lGQFRW50rRr5dwmOxf5C6Y3XkksZqCD2EoCtPotY
	eOuVm0FR7Ns/zRDt+BNBTRxgLojwofAivACTfT5dSbzA0+IjMucZio1yLqPGKF238qsV
	T4n6IVF4JKfc9mw4IfuGe5GQmNtRt4J99jjbrPNiB+HwW4sBNHQpqSTUOHQ6kW59A9YY
	vxKihg0p2NmbIQfjh7ZTmLrSJKxYopslYfDhRluJ0A9bTMtpHPMIqfBARou643E8j5PN
	1lUA==
Received: by 10.50.76.133 with SMTP id k5mr1860923igw.23.1348238065732; Fri,
	21 Sep 2012 07:34:25 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.64.126.131 with HTTP; Fri, 21 Sep 2012 07:33:55 -0700 (PDT)
In-Reply-To: <alpine.DEB.2.02.1209201330340.29232@kaball.uk.xensource.com>
References: <1348139574-23324-1-git-send-email-anthony.perard@citrix.com>
	<1348139574-23324-6-git-send-email-anthony.perard@citrix.com>
	<alpine.DEB.2.02.1209201330340.29232@kaball.uk.xensource.com>
From: Anthony PERARD <anthony.perard@citrix.com>
Date: Fri, 21 Sep 2012 15:33:55 +0100
X-Google-Sender-Auth: Pq2ZKnttR5QAW_k9llQs8M3sEOE
Message-ID: <CAJJyHjKCqCdaHu_DOUiS7gb6MpFMzXKAT1U9K=WACntB1xYrqA@mail.gmail.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: QEMU-devel <qemu-devel@nongnu.org>, Xen Devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [Qemu-devel] [PATCH V3 5/5] xen: Set the vram dirty
	when an error occur.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Sep 20, 2012 at 1:31 PM, Stefano Stabellini
<stefano.stabellini@eu.citrix.com> wrote:
> On Thu, 20 Sep 2012, Anthony PERARD wrote:
>> If the call to xc_hvm_track_dirty_vram() fails, then we set dirtybit on all the
>> video ram. This case happens during migration, but we don't need a special case
>> for live migration with patch.
>
> Just as a reference, what is this special case for live migration that
> you are talking about? A pointer to the qemu-xen-traditional code would
> be welcomed here.

It was in the previous iteration of this patches series, qemu-trad
does not have a special case for migration, but a fail of the xc_ call
result in the vram to be marked as dirty.

-- 
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 Sep 21 14:34:46 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Sep 2012 14:34:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TF4JK-0008RE-VW; Fri, 21 Sep 2012 14:34:30 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony.perard@gmail.com>) id 1TF4JI-0008R1-Pz
	for xen-devel@lists.xen.org; Fri, 21 Sep 2012 14:34:29 +0000
Received: from [85.158.138.51:7846] by server-11.bemta-3.messagelabs.com id
	01/3C-30250-3FA7C505; Fri, 21 Sep 2012 14:34:27 +0000
X-Env-Sender: anthony.perard@gmail.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1348238066!29802260!1
X-Originating-IP: [209.85.223.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6284 invoked from network); 21 Sep 2012 14:34:27 -0000
Received: from mail-ie0-f173.google.com (HELO mail-ie0-f173.google.com)
	(209.85.223.173)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Sep 2012 14:34:27 -0000
Received: by iea17 with SMTP id 17so1460763iea.32
	for <xen-devel@lists.xen.org>; Fri, 21 Sep 2012 07:34: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:from:date
	:x-google-sender-auth:message-id:subject:to:cc:content-type;
	bh=RbQ5SFkyR6FWGY9zF25sQEVdJNrYhj55tQfDAqEY1GI=;
	b=co56w5lqHQVDDe1z8fLGFQDyP9ln0lhlcmb+2Il8V23QZnFT75S6C1bl+DHLd/fs1k
	TG+WLfHjIpNJCb1DrQW2JeT0yE44lGQFRW50rRr5dwmOxf5C6Y3XkksZqCD2EoCtPotY
	eOuVm0FR7Ns/zRDt+BNBTRxgLojwofAivACTfT5dSbzA0+IjMucZio1yLqPGKF238qsV
	T4n6IVF4JKfc9mw4IfuGe5GQmNtRt4J99jjbrPNiB+HwW4sBNHQpqSTUOHQ6kW59A9YY
	vxKihg0p2NmbIQfjh7ZTmLrSJKxYopslYfDhRluJ0A9bTMtpHPMIqfBARou643E8j5PN
	1lUA==
Received: by 10.50.76.133 with SMTP id k5mr1860923igw.23.1348238065732; Fri,
	21 Sep 2012 07:34:25 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.64.126.131 with HTTP; Fri, 21 Sep 2012 07:33:55 -0700 (PDT)
In-Reply-To: <alpine.DEB.2.02.1209201330340.29232@kaball.uk.xensource.com>
References: <1348139574-23324-1-git-send-email-anthony.perard@citrix.com>
	<1348139574-23324-6-git-send-email-anthony.perard@citrix.com>
	<alpine.DEB.2.02.1209201330340.29232@kaball.uk.xensource.com>
From: Anthony PERARD <anthony.perard@citrix.com>
Date: Fri, 21 Sep 2012 15:33:55 +0100
X-Google-Sender-Auth: Pq2ZKnttR5QAW_k9llQs8M3sEOE
Message-ID: <CAJJyHjKCqCdaHu_DOUiS7gb6MpFMzXKAT1U9K=WACntB1xYrqA@mail.gmail.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: QEMU-devel <qemu-devel@nongnu.org>, Xen Devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [Qemu-devel] [PATCH V3 5/5] xen: Set the vram dirty
	when an error occur.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Sep 20, 2012 at 1:31 PM, Stefano Stabellini
<stefano.stabellini@eu.citrix.com> wrote:
> On Thu, 20 Sep 2012, Anthony PERARD wrote:
>> If the call to xc_hvm_track_dirty_vram() fails, then we set dirtybit on all the
>> video ram. This case happens during migration, but we don't need a special case
>> for live migration with patch.
>
> Just as a reference, what is this special case for live migration that
> you are talking about? A pointer to the qemu-xen-traditional code would
> be welcomed here.

It was in the previous iteration of this patches series, qemu-trad
does not have a special case for migration, but a fail of the xc_ call
result in the vram to be marked as dirty.

-- 
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 Sep 21 14:39:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Sep 2012 14:39:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TF4NS-0000A2-LP; Fri, 21 Sep 2012 14:38:46 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1TF4NR-00009x-OA
	for xen-devel@lists.xen.org; Fri, 21 Sep 2012 14:38:46 +0000
Received: from [85.158.143.35:41540] by server-1.bemta-4.messagelabs.com id
	C6/52-05684-4FB7C505; Fri, 21 Sep 2012 14:38:44 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1348238322!12525187!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzU2MzI0\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12200 invoked from network); 21 Sep 2012 14:38:44 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-11.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 21 Sep 2012 14:38:44 -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 q8LEcepK027058
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 21 Sep 2012 14:38: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
	q8LEcdNr017946
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 21 Sep 2012 14:38:40 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
	q8LEcdkr031797; Fri, 21 Sep 2012 09:38:39 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 21 Sep 2012 07:38:39 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 6A89E402F0; Fri, 21 Sep 2012 10:27:33 -0400 (EDT)
Date: Fri, 21 Sep 2012 10:27:33 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: David Vrabel <david.vrabel@citrix.com>
Message-ID: <20120921142733.GB3389@phenom.dumpdata.com>
References: <1348051887-21885-1-git-send-email-oliver.chick@citrix.com>
	<505AF126.2050806@citrix.com>
	<1348140637.24539.32.camel@oliverchick-Precision-WorkStation-T3400>
	<505B1EB9020000780009CA6E@nat28.tlf.novell.com>
	<505C5C54.4060100@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <505C5C54.4060100@citrix.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: Oliver Chick <oliver.chick@citrix.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Jan Beulich <JBeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] Persistent grant maps for xen blk drivers
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Sep 21, 2012 at 01:23:48PM +0100, David Vrabel wrote:
> On 20/09/12 12:48, Jan Beulich wrote:
> >>>> On 20.09.12 at 13:30, Oliver Chick <oliver.chick@citrix.com> wrote:
> >> The memory overhead, and fallback mode points are related:
> >> -Firstly, it turns out that the overhead is actually 2.75MB, not 11MB
> >> per device. I made a mistake (pointed out by Jan) as the maximum number
> >> of requests that can fit into a single-page ring is 64, not 256.
> >> -Clearly, this still scales linearly. So the problem of memory footprint
> >> will occur with more VMs, or block devices.
> >> -Whilst 2.75MB per device is probably acceptable (?), if we start using
> >> multipage rings, then we might not want to have
> >> BLKIF_MAX_PERS_REQUESTS_PER_DEVICE==__RING_SIZE, as this will cause the
> >> memory overhead to increase. This is why I have implemented the
> >> 'fallback' mode. With a multipage ring, it seems reasonable to want the
> >> first $x$ grefs seen by blkback to be treated as persistent, and any
> >> later ones to be non-persistent. Does that seem sensible?
> > 
> >>From a resource usage pov, perhaps. But this will get the guest
> > entirely unpredictable performance. Plus I don't think 11Mb of
> > _virtual_ space is unacceptable overhead in a 64-bit kernel. If
> > you really want/need this in a 32-bit one, then perhaps some
> > other alternatives would be needed (and persistent grants may
> > not be the right approach there in the first place).
> 
> It's not just virtual space.  blkback in pvops kernels allocates its
> pages from the balloon and if there aren't enough ballooned out pages it
> has to allocate real pages (releasing the MFN back to Xen).
> 
> Classic kernels didn't need to do this as there was an API for allocate
> new "empty" struct page's that get mapped into kernel space.

Can we ressurect/implement that in the new pvops? We could use the memory
hotplug mechanism to allocate "non-existent" memory. 
> 
> David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 21 14:39:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Sep 2012 14:39:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TF4NS-0000A2-LP; Fri, 21 Sep 2012 14:38:46 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1TF4NR-00009x-OA
	for xen-devel@lists.xen.org; Fri, 21 Sep 2012 14:38:46 +0000
Received: from [85.158.143.35:41540] by server-1.bemta-4.messagelabs.com id
	C6/52-05684-4FB7C505; Fri, 21 Sep 2012 14:38:44 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1348238322!12525187!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzU2MzI0\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12200 invoked from network); 21 Sep 2012 14:38:44 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-11.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 21 Sep 2012 14:38:44 -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 q8LEcepK027058
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 21 Sep 2012 14:38: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
	q8LEcdNr017946
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 21 Sep 2012 14:38:40 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
	q8LEcdkr031797; Fri, 21 Sep 2012 09:38:39 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 21 Sep 2012 07:38:39 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 6A89E402F0; Fri, 21 Sep 2012 10:27:33 -0400 (EDT)
Date: Fri, 21 Sep 2012 10:27:33 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: David Vrabel <david.vrabel@citrix.com>
Message-ID: <20120921142733.GB3389@phenom.dumpdata.com>
References: <1348051887-21885-1-git-send-email-oliver.chick@citrix.com>
	<505AF126.2050806@citrix.com>
	<1348140637.24539.32.camel@oliverchick-Precision-WorkStation-T3400>
	<505B1EB9020000780009CA6E@nat28.tlf.novell.com>
	<505C5C54.4060100@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <505C5C54.4060100@citrix.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: Oliver Chick <oliver.chick@citrix.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Jan Beulich <JBeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] Persistent grant maps for xen blk drivers
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Sep 21, 2012 at 01:23:48PM +0100, David Vrabel wrote:
> On 20/09/12 12:48, Jan Beulich wrote:
> >>>> On 20.09.12 at 13:30, Oliver Chick <oliver.chick@citrix.com> wrote:
> >> The memory overhead, and fallback mode points are related:
> >> -Firstly, it turns out that the overhead is actually 2.75MB, not 11MB
> >> per device. I made a mistake (pointed out by Jan) as the maximum number
> >> of requests that can fit into a single-page ring is 64, not 256.
> >> -Clearly, this still scales linearly. So the problem of memory footprint
> >> will occur with more VMs, or block devices.
> >> -Whilst 2.75MB per device is probably acceptable (?), if we start using
> >> multipage rings, then we might not want to have
> >> BLKIF_MAX_PERS_REQUESTS_PER_DEVICE==__RING_SIZE, as this will cause the
> >> memory overhead to increase. This is why I have implemented the
> >> 'fallback' mode. With a multipage ring, it seems reasonable to want the
> >> first $x$ grefs seen by blkback to be treated as persistent, and any
> >> later ones to be non-persistent. Does that seem sensible?
> > 
> >>From a resource usage pov, perhaps. But this will get the guest
> > entirely unpredictable performance. Plus I don't think 11Mb of
> > _virtual_ space is unacceptable overhead in a 64-bit kernel. If
> > you really want/need this in a 32-bit one, then perhaps some
> > other alternatives would be needed (and persistent grants may
> > not be the right approach there in the first place).
> 
> It's not just virtual space.  blkback in pvops kernels allocates its
> pages from the balloon and if there aren't enough ballooned out pages it
> has to allocate real pages (releasing the MFN back to Xen).
> 
> Classic kernels didn't need to do this as there was an API for allocate
> new "empty" struct page's that get mapped into kernel space.

Can we ressurect/implement that in the new pvops? We could use the memory
hotplug mechanism to allocate "non-existent" memory. 
> 
> David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 21 14:39:06 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Sep 2012 14:39: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 1TF4Na-0000AX-26; Fri, 21 Sep 2012 14:38:54 +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 1TF4NZ-0000AE-0W
	for xen-devel@lists.xen.org; Fri, 21 Sep 2012 14:38:53 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1348238262!8509667!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDc2NjM1OA==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22988 invoked from network); 21 Sep 2012 14:37:43 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-5.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 21 Sep 2012 14:37: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 q8LEbcZ3006511
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 21 Sep 2012 14:37:39 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q8LEbbm8019280
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 21 Sep 2012 14:37:38 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
	q8LEbbqO019158; Fri, 21 Sep 2012 09:37:37 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 21 Sep 2012 07:37:37 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id A6B2A402F0; Fri, 21 Sep 2012 10:26:30 -0400 (EDT)
Date: Fri, 21 Sep 2012 10:26:30 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120921142630.GA3389@phenom.dumpdata.com>
References: <1348051887-21885-1-git-send-email-oliver.chick@citrix.com>
	<505AF126.2050806@citrix.com>
	<1348140637.24539.32.camel@oliverchick-Precision-WorkStation-T3400>
	<505B1EB9020000780009CA6E@nat28.tlf.novell.com>
	<20120920134951.GC1998@localhost.localdomain>
	<1348150422.24539.58.camel@oliverchick-Precision-WorkStation-T3400>
	<20120920212407.GD27312@konrad-lan.dumpdata.com>
	<1348215044.26501.70.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1348215044.26501.70.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: "Oliver Chick \(Intern\)" <oliver.chick@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Jan Beulich <JBeulich@suse.com>, David Vrabel <david.vrabel@citrix.com>
Subject: Re: [Xen-devel] [PATCH] Persistent grant maps for xen blk drivers
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Sep 21, 2012 at 09:10:44AM +0100, Ian Campbell wrote:
> On Thu, 2012-09-20 at 22:24 +0100, Konrad Rzeszutek Wilk wrote:
> > On Thu, Sep 20, 2012 at 03:13:42PM +0100, Oliver Chick wrote:
> > > On Thu, 2012-09-20 at 14:49 +0100, Konrad Rzeszutek Wilk wrote:
> > > > On Thu, Sep 20, 2012 at 12:48:41PM +0100, Jan Beulich wrote:
> > > > > >>> On 20.09.12 at 13:30, Oliver Chick <oliver.chick@citrix.com> wrote:
> > > > > > The memory overhead, and fallback mode points are related:
> > > > > > -Firstly, it turns out that the overhead is actually 2.75MB, not 11MB
> > > > > > per device. I made a mistake (pointed out by Jan) as the maximum number
> > > > > > of requests that can fit into a single-page ring is 64, not 256.
> > > > > > -Clearly, this still scales linearly. So the problem of memory footprint
> > > > > > will occur with more VMs, or block devices.
> > > > > > -Whilst 2.75MB per device is probably acceptable (?), if we start using
> > > > > > multipage rings, then we might not want to have
> > > > > > BLKIF_MAX_PERS_REQUESTS_PER_DEVICE==__RING_SIZE, as this will cause the
> > > > > > memory overhead to increase. This is why I have implemented the
> > > > > > 'fallback' mode. With a multipage ring, it seems reasonable to want the
> > > > > > first $x$ grefs seen by blkback to be treated as persistent, and any
> > > > > > later ones to be non-persistent. Does that seem sensible?
> > > > > 
> > > > > From a resource usage pov, perhaps. But this will get the guest
> > > > > entirely unpredictable performance. Plus I don't think 11Mb of
> > > > 
> > > > Wouldn't it fall back to the older performance?
> > > 
> > > I guess it would be a bit more complex than that. It would be worse than
> > > the new performance because the grefs that get processed by the
> > > 'fallback' mode will cause TLB shootdowns. But any early grefs will
> > > still be processed by the persistent mode, so won't have shootdowns.
> > > Therefore, depending on the ratio of {persistent grants}:{non-persistent
> > > grants), allocated by blkfront, the performance will be somewhere
> > > inbetween the two extremes.
> > > 
> > > I guess that the choice is between
> > > 1) Compiling blk{front,back} with a pre-determined number of persistent
> > > grants, and failing if this limit is exceeded. This seems rather
> > > unflexible, as blk{front,back} must then both both use the same version,
> > > or you will get failures.
> > > 2 (current setup)) Have a recommended maximum number of
> > > persistently-mapped pages, and going into a 'fallback' mode if blkfront
> > > exceeds this limit.
> > > 3) Having blkback inform blkfront on startup as to how many grefs it is
> > > willing to persistently-map. We then hit the same question again though:
> > > what should be do if blkfront ignores this limit?
> > 
> > How about 2 and 3 together?
> 
> I think 1 is fine for a "phase 1" implementation, especially taking into
> consideration that the end of Oliver's internship is next week.

Ah yes. Lets do one and then we can deal with 2 later on. At the
same time when netback persistent grants come online. Seems like
both backends will have to deal with this.
> 
> Also it seems that the cases where there might be some disconnect
> between the number of persistent grants supported by the backend and the
> number of requests from the frontend are currently theoretical or
> predicated on the existence of unmerged or as yet unwritten patches.
> 
> So lets say, for now, that the default number of persistent grants is
> the same as the number of slots in the ring and that it is a bug for
> netfront to try and use more than that if it has signed up to the use of
> persistent grants. netback is at liberty to fail such "overflow"
> requests. In practice this can't happen with the current implementations
> given the default specified above.

OK.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 21 14:39:06 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Sep 2012 14:39: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 1TF4Na-0000AX-26; Fri, 21 Sep 2012 14:38:54 +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 1TF4NZ-0000AE-0W
	for xen-devel@lists.xen.org; Fri, 21 Sep 2012 14:38:53 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1348238262!8509667!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDc2NjM1OA==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22988 invoked from network); 21 Sep 2012 14:37:43 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-5.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 21 Sep 2012 14:37: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 q8LEbcZ3006511
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 21 Sep 2012 14:37:39 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q8LEbbm8019280
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 21 Sep 2012 14:37:38 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
	q8LEbbqO019158; Fri, 21 Sep 2012 09:37:37 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 21 Sep 2012 07:37:37 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id A6B2A402F0; Fri, 21 Sep 2012 10:26:30 -0400 (EDT)
Date: Fri, 21 Sep 2012 10:26:30 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120921142630.GA3389@phenom.dumpdata.com>
References: <1348051887-21885-1-git-send-email-oliver.chick@citrix.com>
	<505AF126.2050806@citrix.com>
	<1348140637.24539.32.camel@oliverchick-Precision-WorkStation-T3400>
	<505B1EB9020000780009CA6E@nat28.tlf.novell.com>
	<20120920134951.GC1998@localhost.localdomain>
	<1348150422.24539.58.camel@oliverchick-Precision-WorkStation-T3400>
	<20120920212407.GD27312@konrad-lan.dumpdata.com>
	<1348215044.26501.70.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1348215044.26501.70.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: "Oliver Chick \(Intern\)" <oliver.chick@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Jan Beulich <JBeulich@suse.com>, David Vrabel <david.vrabel@citrix.com>
Subject: Re: [Xen-devel] [PATCH] Persistent grant maps for xen blk drivers
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Sep 21, 2012 at 09:10:44AM +0100, Ian Campbell wrote:
> On Thu, 2012-09-20 at 22:24 +0100, Konrad Rzeszutek Wilk wrote:
> > On Thu, Sep 20, 2012 at 03:13:42PM +0100, Oliver Chick wrote:
> > > On Thu, 2012-09-20 at 14:49 +0100, Konrad Rzeszutek Wilk wrote:
> > > > On Thu, Sep 20, 2012 at 12:48:41PM +0100, Jan Beulich wrote:
> > > > > >>> On 20.09.12 at 13:30, Oliver Chick <oliver.chick@citrix.com> wrote:
> > > > > > The memory overhead, and fallback mode points are related:
> > > > > > -Firstly, it turns out that the overhead is actually 2.75MB, not 11MB
> > > > > > per device. I made a mistake (pointed out by Jan) as the maximum number
> > > > > > of requests that can fit into a single-page ring is 64, not 256.
> > > > > > -Clearly, this still scales linearly. So the problem of memory footprint
> > > > > > will occur with more VMs, or block devices.
> > > > > > -Whilst 2.75MB per device is probably acceptable (?), if we start using
> > > > > > multipage rings, then we might not want to have
> > > > > > BLKIF_MAX_PERS_REQUESTS_PER_DEVICE==__RING_SIZE, as this will cause the
> > > > > > memory overhead to increase. This is why I have implemented the
> > > > > > 'fallback' mode. With a multipage ring, it seems reasonable to want the
> > > > > > first $x$ grefs seen by blkback to be treated as persistent, and any
> > > > > > later ones to be non-persistent. Does that seem sensible?
> > > > > 
> > > > > From a resource usage pov, perhaps. But this will get the guest
> > > > > entirely unpredictable performance. Plus I don't think 11Mb of
> > > > 
> > > > Wouldn't it fall back to the older performance?
> > > 
> > > I guess it would be a bit more complex than that. It would be worse than
> > > the new performance because the grefs that get processed by the
> > > 'fallback' mode will cause TLB shootdowns. But any early grefs will
> > > still be processed by the persistent mode, so won't have shootdowns.
> > > Therefore, depending on the ratio of {persistent grants}:{non-persistent
> > > grants), allocated by blkfront, the performance will be somewhere
> > > inbetween the two extremes.
> > > 
> > > I guess that the choice is between
> > > 1) Compiling blk{front,back} with a pre-determined number of persistent
> > > grants, and failing if this limit is exceeded. This seems rather
> > > unflexible, as blk{front,back} must then both both use the same version,
> > > or you will get failures.
> > > 2 (current setup)) Have a recommended maximum number of
> > > persistently-mapped pages, and going into a 'fallback' mode if blkfront
> > > exceeds this limit.
> > > 3) Having blkback inform blkfront on startup as to how many grefs it is
> > > willing to persistently-map. We then hit the same question again though:
> > > what should be do if blkfront ignores this limit?
> > 
> > How about 2 and 3 together?
> 
> I think 1 is fine for a "phase 1" implementation, especially taking into
> consideration that the end of Oliver's internship is next week.

Ah yes. Lets do one and then we can deal with 2 later on. At the
same time when netback persistent grants come online. Seems like
both backends will have to deal with this.
> 
> Also it seems that the cases where there might be some disconnect
> between the number of persistent grants supported by the backend and the
> number of requests from the frontend are currently theoretical or
> predicated on the existence of unmerged or as yet unwritten patches.
> 
> So lets say, for now, that the default number of persistent grants is
> the same as the number of slots in the ring and that it is a bug for
> netfront to try and use more than that if it has signed up to the use of
> persistent grants. netback is at liberty to fail such "overflow"
> requests. In practice this can't happen with the current implementations
> given the default specified above.

OK.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 21 14:45:17 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Sep 2012 14:45:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TF4TQ-0000T2-SL; Fri, 21 Sep 2012 14:44:56 +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 1TF4TO-0000Sx-Pt
	for xen-devel@lists.xen.org; Fri, 21 Sep 2012 14:44:55 +0000
Received: from [85.158.138.51:12468] by server-16.bemta-3.messagelabs.com id
	51/78-31776-66D7C505; Fri, 21 Sep 2012 14:44:54 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1348238692!23558781!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-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8182 invoked from network); 21 Sep 2012 14:44:53 -0000
Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com)
	(74.125.83.45)
	by server-12.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Sep 2012 14:44:53 -0000
Received: by eeke53 with SMTP id e53so1629173eek.32
	for <xen-devel@lists.xen.org>; Fri, 21 Sep 2012 07:44:52 -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=+ZVhZiu8ScuGhlaA3SQmsvLCI5pFat8hlUAwNlZws1k=;
	b=Ym7o6JgOy0KTeqIOlmGrFWhi0/LmyYy+2+8CzeIv9wtgMa/4975x8qPl6b8cpCEKPh
	rMKLBviEF0Bo+1vP68rabfwVMpfY5VbAS4SUSX/qWu3XZonXt0Vm1MtrDYS0W7/58Q8f
	1AFjv4qajq10ntwAOzs5bA78Xvkd/a0eC5QGDTXepAnbMHh/OLpFV0HgUr+bA+h6bl49
	zgITE8UysaCVEEESpy71v2MNRtwKDVz/oHoWE/EN4SqthRFqv/h6hVDMclVFT0z+DcDU
	aDhxOV+9Jk7ayDzfsmVtUmIEOXPngf5Zr/YSCYM6tX8inWTr560Gy7ncHQiJ5WKlDy3/
	qDgg==
Received: by 10.14.203.70 with SMTP id e46mr6748673eeo.2.1348238692688;
	Fri, 21 Sep 2012 07:44:52 -0700 (PDT)
Received: from [192.168.1.3] (host86-167-82-156.range86-167.btcentralplus.com.
	[86.167.82.156])
	by mx.google.com with ESMTPS id y1sm24595744eel.0.2012.09.21.07.44.51
	(version=SSLv3 cipher=OTHER); Fri, 21 Sep 2012 07:44:52 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.33.0.120411
Date: Fri, 21 Sep 2012 15:44:48 +0100
From: Keir Fraser <keir@xen.org>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <CC823BF0.4C984%keir@xen.org>
Thread-Topic: [PATCH, v2] x86: enable VIA CPU support
Thread-Index: Ac2YB6XzKaofWiuv2US5DAiQqI4LyA==
In-Reply-To: <505C94B3020000780009D06A@nat28.tlf.novell.com>
Mime-version: 1.0
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH, v2] x86: enable VIA CPU 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 21/09/2012 15:24, "Jan Beulich" <JBeulich@suse.com> wrote:

> Newer VIA CPUs have both 64-bit and VMX support. Enable them to be
> recognized for these purposes, at once stripping off any 32-bit CPU
> only bits from the respective CPU support file.
> 
> This particularly implies untying the VMX == Intel assumption in a few
> places.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Acked-by: Keir Fraser <keir@xen.org>

> ---
> v2: Use cpu_has_vmx instead of comparing hvm_funcs.name, as suggested
>     by Keir. Extend this to also use this and cpu_has_svm in
>     hvm_enable(), making the respective open coded checks in
>     start_{svm,vmx}() unnecessary.
> 
> Note that my testing of this functionality wasn't as wide as I would
> have hoped it to be, since the box I was provided only survived the
> first few days - meanwhile it doesn't stay up long enough to just build
> hypervisor and tools. Therefore, further fixes to fully support these
> CPUs may be needed as the VIA folks themselves get to test that code.
> 
> --- a/xen/arch/x86/acpi/suspend.c
> +++ b/xen/arch/x86/acpi/suspend.c
> @@ -32,7 +32,8 @@ void save_rest_processor_state(void)
>      rdmsrl(MSR_SHADOW_GS_BASE, saved_kernel_gs_base);
>      rdmsrl(MSR_CSTAR, saved_cstar);
>      rdmsrl(MSR_LSTAR, saved_lstar);
> -    if ( boot_cpu_data.x86_vendor == X86_VENDOR_INTEL )
> +    if ( boot_cpu_data.x86_vendor == X86_VENDOR_INTEL ||
> +         boot_cpu_data.x86_vendor == X86_VENDOR_CENTAUR )
>      {
>          rdmsrl(MSR_IA32_SYSENTER_ESP, saved_sysenter_esp);
>          rdmsrl(MSR_IA32_SYSENTER_EIP, saved_sysenter_eip);
> @@ -59,7 +60,8 @@ void restore_rest_processor_state(void)
>      wrmsrl(MSR_GS_BASE, saved_gs_base);
>      wrmsrl(MSR_SHADOW_GS_BASE, saved_kernel_gs_base);
>  
> -    if ( boot_cpu_data.x86_vendor == X86_VENDOR_INTEL )
> +    if ( boot_cpu_data.x86_vendor == X86_VENDOR_INTEL ||
> +         boot_cpu_data.x86_vendor == X86_VENDOR_CENTAUR )
>      {
>          /* Recover sysenter MSRs */
>          wrmsrl(MSR_IA32_SYSENTER_ESP, saved_sysenter_esp);
> --- a/xen/arch/x86/cpu/Makefile
> +++ b/xen/arch/x86/cpu/Makefile
> @@ -2,10 +2,8 @@ subdir-y += mcheck
>  subdir-y += mtrr
>  
>  obj-y += amd.o
> +obj-y += centaur.o
>  obj-y += common.o
>  obj-y += intel.o
>  obj-y += intel_cacheinfo.o
>  obj-y += mwait-idle.o
> -
> -# Keeping around for VIA support (JBeulich)
> -# obj-$(x86_32) += centaur.o
> --- a/xen/arch/x86/cpu/centaur.c
> +++ b/xen/arch/x86/cpu/centaur.c
> @@ -45,51 +45,25 @@ static void __init init_c3(struct cpuinf
> c->x86_capability[5] = cpuid_edx(0xC0000001);
> }
>  
> - /* Cyrix III family needs CX8 & PGE explicity enabled. */
> - if (c->x86_model >=6 && c->x86_model <= 9) {
> -  rdmsrl(MSR_VIA_FCR, msr_content);
> -  wrmsrl(MSR_VIA_FCR, msr_content | (1ULL << 1 | 1ULL << 7));
> -  set_bit(X86_FEATURE_CX8, c->x86_capability);
> + if (c->x86 == 0x6 && c->x86_model >= 0xf) {
> +  c->x86_cache_alignment = c->x86_clflush_size * 2;
> +  set_bit(X86_FEATURE_CONSTANT_TSC, c->x86_capability);
> }
>  
> - /* Before Nehemiah, the C3's had 3dNOW! */
> - if (c->x86_model >=6 && c->x86_model <9)
> -  set_bit(X86_FEATURE_3DNOW, c->x86_capability);
> -
> get_model_name(c);
> display_cacheinfo(c);
>  }
>  
>  static void __init init_centaur(struct cpuinfo_x86 *c)
>  {
> - /* Bit 31 in normal CPUID used for nonstandard 3DNow ID;
> -    3DNow is IDd by bit 31 in extended CPUID (1*32+31) anyway */
> - clear_bit(0*32+31, c->x86_capability);
> -
> if (c->x86 == 6)
> init_c3(c);
>  }
>  
> -static unsigned int centaur_size_cache(struct cpuinfo_x86 * c, unsigned int
> size)
> -{
> - /* VIA C3 CPUs (670-68F) need further shifting. */
> - if ((c->x86 == 6) && ((c->x86_model == 7) || (c->x86_model == 8)))
> -  size >>= 8;
> -
> - /* VIA also screwed up Nehemiah stepping 1, and made
> -    it return '65KB' instead of '64KB'
> -    - Note, it seems this may only be in engineering samples. */
> - if ((c->x86==6) && (c->x86_model==9) && (c->x86_mask==1) && (size==65))
> -  size -=1;
> -
> - return size;
> -}
> -
>  static struct cpu_dev centaur_cpu_dev __cpuinitdata = {
> .c_vendor = "Centaur",
> .c_ident = { "CentaurHauls" },
> .c_init  = init_centaur,
> - .c_size_cache = centaur_size_cache,
>  };
>  
>  int __init centaur_init_cpu(void)
> @@ -97,5 +71,3 @@ int __init centaur_init_cpu(void)
> cpu_devs[X86_VENDOR_CENTAUR] = &centaur_cpu_dev;
> return 0;
>  }
> -
> -//early_arch_initcall(centaur_init_cpu);
> --- a/xen/arch/x86/cpu/common.c
> +++ b/xen/arch/x86/cpu/common.c
> @@ -522,6 +522,7 @@ void __init early_cpu_init(void)
>  {
> intel_cpu_init();
> amd_init_cpu();
> + centaur_init_cpu();
> early_cpu_detect();
>  }
>  /*
> --- a/xen/arch/x86/hvm/hvm.c
> +++ b/xen/arch/x86/hvm/hvm.c
> @@ -111,17 +111,10 @@ static int __init hvm_enable(void)
>  {
>      struct hvm_function_table *fns = NULL;
>  
> -    switch ( boot_cpu_data.x86_vendor )
> -    {
> -    case X86_VENDOR_INTEL:
> +    if ( cpu_has_vmx )
>          fns = start_vmx();
> -        break;
> -    case X86_VENDOR_AMD:
> +    else if ( cpu_has_svm )
>          fns = start_svm();
> -        break;
> -    default:
> -        break;
> -    }
>  
>      if ( fns == NULL )
>          return 0;
> --- a/xen/arch/x86/hvm/nestedhvm.c
> +++ b/xen/arch/x86/hvm/nestedhvm.c
> @@ -152,7 +152,7 @@ static int __init
>  nestedhvm_setup(void)
>  {
>      /* Same format and size as hvm_io_bitmap (Intel needs only 2 pages). */
> -    unsigned int nr = (boot_cpu_data.x86_vendor == X86_VENDOR_INTEL) ? 2 : 3;
> +    unsigned nr = cpu_has_vmx ? 2 : 3;
>      unsigned int i, order = get_order_from_pages(nr);
>  
>      if ( !hvm_funcs.name )
> --- a/xen/arch/x86/hvm/svm/svm.c
> +++ b/xen/arch/x86/hvm/svm/svm.c
> @@ -1240,9 +1240,6 @@ struct hvm_function_table * __init start
>  {
>      bool_t printed = 0;
>  
> -    if ( !test_bit(X86_FEATURE_SVM, &boot_cpu_data.x86_capability) )
> -        return NULL;
> -
>      svm_host_osvw_reset();
>  
>      if ( svm_cpu_up() )
> --- a/xen/arch/x86/hvm/viridian.c
> +++ b/xen/arch/x86/hvm/viridian.c
> @@ -156,8 +156,7 @@ static void enable_hypercall_page(struct
>      *(u32 *)(p + 1) = 0x80000000;
>      *(u8  *)(p + 5) = 0x0f; /* vmcall/vmmcall */
>      *(u8  *)(p + 6) = 0x01;
> -    *(u8  *)(p + 7) = ((boot_cpu_data.x86_vendor == X86_VENDOR_INTEL)
> -                       ? 0xc1 : 0xd9);
> +    *(u8  *)(p + 7) = (cpu_has_vmx ? 0xc1 : 0xd9);
>      *(u8  *)(p + 8) = 0xc3; /* ret */
>      memset(p + 9, 0xcc, PAGE_SIZE - 9); /* int3, int3, ... */
>  
> --- a/xen/arch/x86/hvm/vmx/vmx.c
> +++ b/xen/arch/x86/hvm/vmx/vmx.c
> @@ -1516,9 +1516,6 @@ static struct hvm_function_table __read_
>  
>  struct hvm_function_table * __init start_vmx(void)
>  {
> -    if ( !test_bit(X86_FEATURE_VMXE, &boot_cpu_data.x86_capability) )
> -        return NULL;
> -
>      set_in_cr4(X86_CR4_VMXE);
>  
>      if ( vmx_cpu_up() )
> --- a/xen/arch/x86/mm/mem_event.c
> +++ b/xen/arch/x86/mm/mem_event.c
> @@ -608,7 +608,7 @@ int mem_event_domctl(struct domain *d, x
>                  break;
>  
>              /* Currently only EPT is supported */
> -            if ( boot_cpu_data.x86_vendor != X86_VENDOR_INTEL )
> +            if ( !cpu_has_vmx )
>                  break;
>  
>              rc = mem_event_enable(d, mec, med, _VPF_mem_access,
> --- a/xen/arch/x86/mm/p2m.c
> +++ b/xen/arch/x86/mm/p2m.c
> @@ -83,7 +83,7 @@ static void p2m_initialise(struct domain
>  
>      p2m->cr3 = CR3_EADDR;
>  
> -    if ( hap_enabled(d) && (boot_cpu_data.x86_vendor == X86_VENDOR_INTEL) )
> +    if ( hap_enabled(d) && cpu_has_vmx )
>          ept_p2m_init(p2m);
>      else
>          p2m_pt_init(p2m);
> --- a/xen/arch/x86/x86_64/traps.c
> +++ b/xen/arch/x86/x86_64/traps.c
> @@ -399,7 +399,8 @@ void __devinit subarch_percpu_traps_init
>      wrmsrl(MSR_LSTAR, (unsigned long)stack);
>      stack += write_stack_trampoline(stack, stack_bottom, FLAT_KERNEL_CS64);
>  
> -    if ( boot_cpu_data.x86_vendor == X86_VENDOR_INTEL )
> +    if ( boot_cpu_data.x86_vendor == X86_VENDOR_INTEL ||
> +         boot_cpu_data.x86_vendor == X86_VENDOR_CENTAUR )
>      {
>          /* SYSENTER entry. */
>          wrmsrl(MSR_IA32_SYSENTER_ESP, (unsigned long)stack_bottom);
> 
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 21 14:45:17 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Sep 2012 14:45:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TF4TQ-0000T2-SL; Fri, 21 Sep 2012 14:44:56 +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 1TF4TO-0000Sx-Pt
	for xen-devel@lists.xen.org; Fri, 21 Sep 2012 14:44:55 +0000
Received: from [85.158.138.51:12468] by server-16.bemta-3.messagelabs.com id
	51/78-31776-66D7C505; Fri, 21 Sep 2012 14:44:54 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1348238692!23558781!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-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8182 invoked from network); 21 Sep 2012 14:44:53 -0000
Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com)
	(74.125.83.45)
	by server-12.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Sep 2012 14:44:53 -0000
Received: by eeke53 with SMTP id e53so1629173eek.32
	for <xen-devel@lists.xen.org>; Fri, 21 Sep 2012 07:44:52 -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=+ZVhZiu8ScuGhlaA3SQmsvLCI5pFat8hlUAwNlZws1k=;
	b=Ym7o6JgOy0KTeqIOlmGrFWhi0/LmyYy+2+8CzeIv9wtgMa/4975x8qPl6b8cpCEKPh
	rMKLBviEF0Bo+1vP68rabfwVMpfY5VbAS4SUSX/qWu3XZonXt0Vm1MtrDYS0W7/58Q8f
	1AFjv4qajq10ntwAOzs5bA78Xvkd/a0eC5QGDTXepAnbMHh/OLpFV0HgUr+bA+h6bl49
	zgITE8UysaCVEEESpy71v2MNRtwKDVz/oHoWE/EN4SqthRFqv/h6hVDMclVFT0z+DcDU
	aDhxOV+9Jk7ayDzfsmVtUmIEOXPngf5Zr/YSCYM6tX8inWTr560Gy7ncHQiJ5WKlDy3/
	qDgg==
Received: by 10.14.203.70 with SMTP id e46mr6748673eeo.2.1348238692688;
	Fri, 21 Sep 2012 07:44:52 -0700 (PDT)
Received: from [192.168.1.3] (host86-167-82-156.range86-167.btcentralplus.com.
	[86.167.82.156])
	by mx.google.com with ESMTPS id y1sm24595744eel.0.2012.09.21.07.44.51
	(version=SSLv3 cipher=OTHER); Fri, 21 Sep 2012 07:44:52 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.33.0.120411
Date: Fri, 21 Sep 2012 15:44:48 +0100
From: Keir Fraser <keir@xen.org>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <CC823BF0.4C984%keir@xen.org>
Thread-Topic: [PATCH, v2] x86: enable VIA CPU support
Thread-Index: Ac2YB6XzKaofWiuv2US5DAiQqI4LyA==
In-Reply-To: <505C94B3020000780009D06A@nat28.tlf.novell.com>
Mime-version: 1.0
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH, v2] x86: enable VIA CPU 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 21/09/2012 15:24, "Jan Beulich" <JBeulich@suse.com> wrote:

> Newer VIA CPUs have both 64-bit and VMX support. Enable them to be
> recognized for these purposes, at once stripping off any 32-bit CPU
> only bits from the respective CPU support file.
> 
> This particularly implies untying the VMX == Intel assumption in a few
> places.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Acked-by: Keir Fraser <keir@xen.org>

> ---
> v2: Use cpu_has_vmx instead of comparing hvm_funcs.name, as suggested
>     by Keir. Extend this to also use this and cpu_has_svm in
>     hvm_enable(), making the respective open coded checks in
>     start_{svm,vmx}() unnecessary.
> 
> Note that my testing of this functionality wasn't as wide as I would
> have hoped it to be, since the box I was provided only survived the
> first few days - meanwhile it doesn't stay up long enough to just build
> hypervisor and tools. Therefore, further fixes to fully support these
> CPUs may be needed as the VIA folks themselves get to test that code.
> 
> --- a/xen/arch/x86/acpi/suspend.c
> +++ b/xen/arch/x86/acpi/suspend.c
> @@ -32,7 +32,8 @@ void save_rest_processor_state(void)
>      rdmsrl(MSR_SHADOW_GS_BASE, saved_kernel_gs_base);
>      rdmsrl(MSR_CSTAR, saved_cstar);
>      rdmsrl(MSR_LSTAR, saved_lstar);
> -    if ( boot_cpu_data.x86_vendor == X86_VENDOR_INTEL )
> +    if ( boot_cpu_data.x86_vendor == X86_VENDOR_INTEL ||
> +         boot_cpu_data.x86_vendor == X86_VENDOR_CENTAUR )
>      {
>          rdmsrl(MSR_IA32_SYSENTER_ESP, saved_sysenter_esp);
>          rdmsrl(MSR_IA32_SYSENTER_EIP, saved_sysenter_eip);
> @@ -59,7 +60,8 @@ void restore_rest_processor_state(void)
>      wrmsrl(MSR_GS_BASE, saved_gs_base);
>      wrmsrl(MSR_SHADOW_GS_BASE, saved_kernel_gs_base);
>  
> -    if ( boot_cpu_data.x86_vendor == X86_VENDOR_INTEL )
> +    if ( boot_cpu_data.x86_vendor == X86_VENDOR_INTEL ||
> +         boot_cpu_data.x86_vendor == X86_VENDOR_CENTAUR )
>      {
>          /* Recover sysenter MSRs */
>          wrmsrl(MSR_IA32_SYSENTER_ESP, saved_sysenter_esp);
> --- a/xen/arch/x86/cpu/Makefile
> +++ b/xen/arch/x86/cpu/Makefile
> @@ -2,10 +2,8 @@ subdir-y += mcheck
>  subdir-y += mtrr
>  
>  obj-y += amd.o
> +obj-y += centaur.o
>  obj-y += common.o
>  obj-y += intel.o
>  obj-y += intel_cacheinfo.o
>  obj-y += mwait-idle.o
> -
> -# Keeping around for VIA support (JBeulich)
> -# obj-$(x86_32) += centaur.o
> --- a/xen/arch/x86/cpu/centaur.c
> +++ b/xen/arch/x86/cpu/centaur.c
> @@ -45,51 +45,25 @@ static void __init init_c3(struct cpuinf
> c->x86_capability[5] = cpuid_edx(0xC0000001);
> }
>  
> - /* Cyrix III family needs CX8 & PGE explicity enabled. */
> - if (c->x86_model >=6 && c->x86_model <= 9) {
> -  rdmsrl(MSR_VIA_FCR, msr_content);
> -  wrmsrl(MSR_VIA_FCR, msr_content | (1ULL << 1 | 1ULL << 7));
> -  set_bit(X86_FEATURE_CX8, c->x86_capability);
> + if (c->x86 == 0x6 && c->x86_model >= 0xf) {
> +  c->x86_cache_alignment = c->x86_clflush_size * 2;
> +  set_bit(X86_FEATURE_CONSTANT_TSC, c->x86_capability);
> }
>  
> - /* Before Nehemiah, the C3's had 3dNOW! */
> - if (c->x86_model >=6 && c->x86_model <9)
> -  set_bit(X86_FEATURE_3DNOW, c->x86_capability);
> -
> get_model_name(c);
> display_cacheinfo(c);
>  }
>  
>  static void __init init_centaur(struct cpuinfo_x86 *c)
>  {
> - /* Bit 31 in normal CPUID used for nonstandard 3DNow ID;
> -    3DNow is IDd by bit 31 in extended CPUID (1*32+31) anyway */
> - clear_bit(0*32+31, c->x86_capability);
> -
> if (c->x86 == 6)
> init_c3(c);
>  }
>  
> -static unsigned int centaur_size_cache(struct cpuinfo_x86 * c, unsigned int
> size)
> -{
> - /* VIA C3 CPUs (670-68F) need further shifting. */
> - if ((c->x86 == 6) && ((c->x86_model == 7) || (c->x86_model == 8)))
> -  size >>= 8;
> -
> - /* VIA also screwed up Nehemiah stepping 1, and made
> -    it return '65KB' instead of '64KB'
> -    - Note, it seems this may only be in engineering samples. */
> - if ((c->x86==6) && (c->x86_model==9) && (c->x86_mask==1) && (size==65))
> -  size -=1;
> -
> - return size;
> -}
> -
>  static struct cpu_dev centaur_cpu_dev __cpuinitdata = {
> .c_vendor = "Centaur",
> .c_ident = { "CentaurHauls" },
> .c_init  = init_centaur,
> - .c_size_cache = centaur_size_cache,
>  };
>  
>  int __init centaur_init_cpu(void)
> @@ -97,5 +71,3 @@ int __init centaur_init_cpu(void)
> cpu_devs[X86_VENDOR_CENTAUR] = &centaur_cpu_dev;
> return 0;
>  }
> -
> -//early_arch_initcall(centaur_init_cpu);
> --- a/xen/arch/x86/cpu/common.c
> +++ b/xen/arch/x86/cpu/common.c
> @@ -522,6 +522,7 @@ void __init early_cpu_init(void)
>  {
> intel_cpu_init();
> amd_init_cpu();
> + centaur_init_cpu();
> early_cpu_detect();
>  }
>  /*
> --- a/xen/arch/x86/hvm/hvm.c
> +++ b/xen/arch/x86/hvm/hvm.c
> @@ -111,17 +111,10 @@ static int __init hvm_enable(void)
>  {
>      struct hvm_function_table *fns = NULL;
>  
> -    switch ( boot_cpu_data.x86_vendor )
> -    {
> -    case X86_VENDOR_INTEL:
> +    if ( cpu_has_vmx )
>          fns = start_vmx();
> -        break;
> -    case X86_VENDOR_AMD:
> +    else if ( cpu_has_svm )
>          fns = start_svm();
> -        break;
> -    default:
> -        break;
> -    }
>  
>      if ( fns == NULL )
>          return 0;
> --- a/xen/arch/x86/hvm/nestedhvm.c
> +++ b/xen/arch/x86/hvm/nestedhvm.c
> @@ -152,7 +152,7 @@ static int __init
>  nestedhvm_setup(void)
>  {
>      /* Same format and size as hvm_io_bitmap (Intel needs only 2 pages). */
> -    unsigned int nr = (boot_cpu_data.x86_vendor == X86_VENDOR_INTEL) ? 2 : 3;
> +    unsigned nr = cpu_has_vmx ? 2 : 3;
>      unsigned int i, order = get_order_from_pages(nr);
>  
>      if ( !hvm_funcs.name )
> --- a/xen/arch/x86/hvm/svm/svm.c
> +++ b/xen/arch/x86/hvm/svm/svm.c
> @@ -1240,9 +1240,6 @@ struct hvm_function_table * __init start
>  {
>      bool_t printed = 0;
>  
> -    if ( !test_bit(X86_FEATURE_SVM, &boot_cpu_data.x86_capability) )
> -        return NULL;
> -
>      svm_host_osvw_reset();
>  
>      if ( svm_cpu_up() )
> --- a/xen/arch/x86/hvm/viridian.c
> +++ b/xen/arch/x86/hvm/viridian.c
> @@ -156,8 +156,7 @@ static void enable_hypercall_page(struct
>      *(u32 *)(p + 1) = 0x80000000;
>      *(u8  *)(p + 5) = 0x0f; /* vmcall/vmmcall */
>      *(u8  *)(p + 6) = 0x01;
> -    *(u8  *)(p + 7) = ((boot_cpu_data.x86_vendor == X86_VENDOR_INTEL)
> -                       ? 0xc1 : 0xd9);
> +    *(u8  *)(p + 7) = (cpu_has_vmx ? 0xc1 : 0xd9);
>      *(u8  *)(p + 8) = 0xc3; /* ret */
>      memset(p + 9, 0xcc, PAGE_SIZE - 9); /* int3, int3, ... */
>  
> --- a/xen/arch/x86/hvm/vmx/vmx.c
> +++ b/xen/arch/x86/hvm/vmx/vmx.c
> @@ -1516,9 +1516,6 @@ static struct hvm_function_table __read_
>  
>  struct hvm_function_table * __init start_vmx(void)
>  {
> -    if ( !test_bit(X86_FEATURE_VMXE, &boot_cpu_data.x86_capability) )
> -        return NULL;
> -
>      set_in_cr4(X86_CR4_VMXE);
>  
>      if ( vmx_cpu_up() )
> --- a/xen/arch/x86/mm/mem_event.c
> +++ b/xen/arch/x86/mm/mem_event.c
> @@ -608,7 +608,7 @@ int mem_event_domctl(struct domain *d, x
>                  break;
>  
>              /* Currently only EPT is supported */
> -            if ( boot_cpu_data.x86_vendor != X86_VENDOR_INTEL )
> +            if ( !cpu_has_vmx )
>                  break;
>  
>              rc = mem_event_enable(d, mec, med, _VPF_mem_access,
> --- a/xen/arch/x86/mm/p2m.c
> +++ b/xen/arch/x86/mm/p2m.c
> @@ -83,7 +83,7 @@ static void p2m_initialise(struct domain
>  
>      p2m->cr3 = CR3_EADDR;
>  
> -    if ( hap_enabled(d) && (boot_cpu_data.x86_vendor == X86_VENDOR_INTEL) )
> +    if ( hap_enabled(d) && cpu_has_vmx )
>          ept_p2m_init(p2m);
>      else
>          p2m_pt_init(p2m);
> --- a/xen/arch/x86/x86_64/traps.c
> +++ b/xen/arch/x86/x86_64/traps.c
> @@ -399,7 +399,8 @@ void __devinit subarch_percpu_traps_init
>      wrmsrl(MSR_LSTAR, (unsigned long)stack);
>      stack += write_stack_trampoline(stack, stack_bottom, FLAT_KERNEL_CS64);
>  
> -    if ( boot_cpu_data.x86_vendor == X86_VENDOR_INTEL )
> +    if ( boot_cpu_data.x86_vendor == X86_VENDOR_INTEL ||
> +         boot_cpu_data.x86_vendor == X86_VENDOR_CENTAUR )
>      {
>          /* SYSENTER entry. */
>          wrmsrl(MSR_IA32_SYSENTER_ESP, (unsigned long)stack_bottom);
> 
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 21 14:46:00 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Sep 2012 14: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 1TF4UB-0000WG-Ef; Fri, 21 Sep 2012 14:45:43 +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 1TF4UA-0000W8-L9
	for xen-devel@lists.xen.org; Fri, 21 Sep 2012 14:45:42 +0000
Received: from [85.158.139.211:18829] by server-5.bemta-5.messagelabs.com id
	97/94-30514-59D7C505; Fri, 21 Sep 2012 14:45:41 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-16.tower-206.messagelabs.com!1348238740!19514819!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDc2NjM1OA==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10208 invoked from network); 21 Sep 2012 14:45:41 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-16.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 21 Sep 2012 14:45:41 -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 q8LEjbYx015537
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK)
	for <xen-devel@lists.xen.org>; Fri, 21 Sep 2012 14:45:38 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
	q8LEja4d026706
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for <xen-devel@lists.xen.org>; Fri, 21 Sep 2012 14:45:37 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
	q8LEjaVJ005901
	for <xen-devel@lists.xen.org>; Fri, 21 Sep 2012 09:45:36 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 21 Sep 2012 07:45:36 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 39DD4402F0; Fri, 21 Sep 2012 10:34:30 -0400 (EDT)
Date: Fri, 21 Sep 2012 10:34:30 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Zhenzhong Duan <zhenzhong.duan@oracle.com>
Message-ID: <20120921143430.GA3522@phenom.dumpdata.com>
References: <505C3647.1030003@oracle.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <505C3647.1030003@oracle.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: Dan Magenheimer <dan.magenheimer@oracle.com>, Feng Jin <joe.jin@oracle.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] an issue with 'xm save'
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Sep 21, 2012 at 05:41:27PM +0800, Zhenzhong Duan wrote:
> Hi maintainers,
> 
> I found there is an issue when 'xm save' a pvm guest. See below:
> 
> When I do save then restore once, CPU(%) in xentop showed around 99%.
> When I do that second time, CPU(%) showed 199%
> 
> top in dom0 showed:
>     PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
>    20946 root      18  -2 10984 1284  964 S 19.8  0.3   0:48.93 block
>    4939 root      18  -2 10984 1288  964 S 19.5  0.3   1:34.68 block
> 
> I could kill the block process, then all look normal again.

What is the 'block' process? If you attach 'perf' to it do you get an idea
of what it is spinning at?

> 
> xen and xen-tools are both generated with xen-unstable.
> I tried xl, but it segfault.

It segfaulted? When doing 'xl save'  or 'xl resume'? Or just allocating
the guest?

> I also tried ovm3.1.1(xen-4.1.2-18.el5.1 and xen-tools-4.1.2-18.el5.1),
> can't reproduce.

So the issue is only present with Xen-unstable?

Did you clear _any_ older Xen libraries/tools when you installed Xen-unstable?

> 
> Did anybody see similar issue before? Any fix already there?
> thanks
> zduan
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 21 14:46:00 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Sep 2012 14: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 1TF4UB-0000WG-Ef; Fri, 21 Sep 2012 14:45:43 +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 1TF4UA-0000W8-L9
	for xen-devel@lists.xen.org; Fri, 21 Sep 2012 14:45:42 +0000
Received: from [85.158.139.211:18829] by server-5.bemta-5.messagelabs.com id
	97/94-30514-59D7C505; Fri, 21 Sep 2012 14:45:41 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-16.tower-206.messagelabs.com!1348238740!19514819!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDc2NjM1OA==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10208 invoked from network); 21 Sep 2012 14:45:41 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-16.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 21 Sep 2012 14:45:41 -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 q8LEjbYx015537
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK)
	for <xen-devel@lists.xen.org>; Fri, 21 Sep 2012 14:45:38 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
	q8LEja4d026706
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for <xen-devel@lists.xen.org>; Fri, 21 Sep 2012 14:45:37 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
	q8LEjaVJ005901
	for <xen-devel@lists.xen.org>; Fri, 21 Sep 2012 09:45:36 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 21 Sep 2012 07:45:36 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 39DD4402F0; Fri, 21 Sep 2012 10:34:30 -0400 (EDT)
Date: Fri, 21 Sep 2012 10:34:30 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Zhenzhong Duan <zhenzhong.duan@oracle.com>
Message-ID: <20120921143430.GA3522@phenom.dumpdata.com>
References: <505C3647.1030003@oracle.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <505C3647.1030003@oracle.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: Dan Magenheimer <dan.magenheimer@oracle.com>, Feng Jin <joe.jin@oracle.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] an issue with 'xm save'
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Sep 21, 2012 at 05:41:27PM +0800, Zhenzhong Duan wrote:
> Hi maintainers,
> 
> I found there is an issue when 'xm save' a pvm guest. See below:
> 
> When I do save then restore once, CPU(%) in xentop showed around 99%.
> When I do that second time, CPU(%) showed 199%
> 
> top in dom0 showed:
>     PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
>    20946 root      18  -2 10984 1284  964 S 19.8  0.3   0:48.93 block
>    4939 root      18  -2 10984 1288  964 S 19.5  0.3   1:34.68 block
> 
> I could kill the block process, then all look normal again.

What is the 'block' process? If you attach 'perf' to it do you get an idea
of what it is spinning at?

> 
> xen and xen-tools are both generated with xen-unstable.
> I tried xl, but it segfault.

It segfaulted? When doing 'xl save'  or 'xl resume'? Or just allocating
the guest?

> I also tried ovm3.1.1(xen-4.1.2-18.el5.1 and xen-tools-4.1.2-18.el5.1),
> can't reproduce.

So the issue is only present with Xen-unstable?

Did you clear _any_ older Xen libraries/tools when you installed Xen-unstable?

> 
> Did anybody see similar issue before? Any fix already there?
> thanks
> zduan
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 21 15:46:31 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Sep 2012 15:46: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 1TF5QZ-0001en-RE; Fri, 21 Sep 2012 15:46: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 1TF5QX-0001ei-Ki
	for xen-devel@lists.xen.org; Fri, 21 Sep 2012 15:46:01 +0000
Received: from [85.158.143.99:18848] by server-3.bemta-4.messagelabs.com id
	DE/4B-10986-8BB8C505; Fri, 21 Sep 2012 15:46:00 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1348242352!24869863!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTA2NjI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7715 invoked from network); 21 Sep 2012 15:45:52 -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;
	21 Sep 2012 15:45:52 -0000
X-IronPort-AV: E=Sophos;i="4.80,463,1344211200"; d="scan'208";a="14694089"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Sep 2012 15:45: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.279.1; Fri, 21 Sep 2012 16:45: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
	1TF5QN-0002H3-89; Fri, 21 Sep 2012 15:45:51 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1TF5QN-0003OH-4K;
	Fri, 21 Sep 2012 16:45:51 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20572.35759.42063.973125@mariner.uk.xensource.com>
Date: Fri, 21 Sep 2012 16:45:51 +0100
To: Julien Grall <julien.grall@citrix.com>
In-Reply-To: <1348049147-16752-1-git-send-email-julien.grall@citrix.com>
References: <1348049147-16752-1-git-send-email-julien.grall@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] libxenstore: filter watch events in libxenstore
 when we unwatch
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Julien Grall writes ("[PATCH] libxenstore: filter watch events in libxenstore when we unwatch"):
> XenStore puts in queued watch events via a thread and notifies the user.
> Sometimes xs_unwatch is called before all related message is read. The use
> case is non-threaded libevent, we have two event A and B:
>     - Event A will destroy something and call xs_unwatch;
>     - Event B is used to notify that a node has changed in XenStore.
> As the event is called one by one, event A can be handled before event B.
> So on next xs_watch_read the user could retrieve an unwatch token and
> a segfault occured if the token store the pointer of the structure
> (ie: "backend:0xcafe").

Missing from the explanation here is why your patch is sufficient to
avoid the race.  The answer is as follows (and should probably be in
the commit message):

While on entry to xs_unwatch, there may be an event on its way from
xenstored (eg in the ring or in the local kernel), all such events
will definitely come before the reply to the unwatch command.  So at
the point where the unwatch reply has been processed (after xs_talkv),
any such now-deleted watch events will definitely have made it to
libxenstore's queue where we can remove them.

As for other threads in the same process: if two threads call
xs_read_watch and xs_unwatch, it is acceptable for the xs_read_watch
to return the event being deleted.  What is not allowed is for an
xs_read_watch entered after xs_unwatch returns to return the deleted
event, and this code does indeed ensure that.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
(for the explanation)

Now for some comments on the patch:

> +	/* Filter the watch list to remove potential message */
> +	mutex_lock(&h->watch_mutex);
> +
> +	if (list_empty(&h->watch_list)) {
> +		mutex_unlock(&h->watch_mutex);
> +		return res;
> +	}

I think this check is unnecessary.  If the list is empty then walking
it is trivially a no-op.

> +	list_for_each_entry_safe(msg, tmsg, &h->watch_list, list) {
> +		assert(msg->hdr.type == XS_WATCH_EVENT);
> +
> +		strings = msg->body;
> +		num_strings = xs_count_strings(strings, msg->hdr.len);

The num_strings thing is obsolete.  There will always be two strings.
Also xs_count_strings walks the array.

> +		for (i = 0; i < num_strings; i++) {
> +			if (i == XS_WATCH_TOKEN && !strcmp (token, strings)) {

This is rather odd.  It amounts to:

   for (i= blah blah) { if (i==FIXED_VALUE) { ..i.. } }

> +				list_del(&msg->list);
> +				free(msg);
> +				break;
> +			}
> +			strings = strings + strlen (strings) + 1;

You need to check the path as well as the token, since it is legal to
set up multiple watches on different paths with the same token.

I think you can then do away with the calculation of "strings", at
least mostly.

> +	/* Clear the pipe token if there are no more pending watches. */
> +	if (list_empty(&h->watch_list) && (h->watch_pipe[0] != -1)) {
> +		while (read(h->watch_pipe[0], &c, 1) != 1)
> +			continue;
> +	}

I'm not convinced this is necessary.  Don't callers already need to
cope with potential spurious signallings of the watch pipe ?

In any case it's clone-and-hack: the same 3/4 lines occur elsewhere.
If we keep this in the patch it should be made into a function.

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 Sep 21 15:46:31 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Sep 2012 15:46: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 1TF5QZ-0001en-RE; Fri, 21 Sep 2012 15:46: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 1TF5QX-0001ei-Ki
	for xen-devel@lists.xen.org; Fri, 21 Sep 2012 15:46:01 +0000
Received: from [85.158.143.99:18848] by server-3.bemta-4.messagelabs.com id
	DE/4B-10986-8BB8C505; Fri, 21 Sep 2012 15:46:00 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1348242352!24869863!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTA2NjI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7715 invoked from network); 21 Sep 2012 15:45:52 -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;
	21 Sep 2012 15:45:52 -0000
X-IronPort-AV: E=Sophos;i="4.80,463,1344211200"; d="scan'208";a="14694089"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Sep 2012 15:45: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.279.1; Fri, 21 Sep 2012 16:45: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
	1TF5QN-0002H3-89; Fri, 21 Sep 2012 15:45:51 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1TF5QN-0003OH-4K;
	Fri, 21 Sep 2012 16:45:51 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20572.35759.42063.973125@mariner.uk.xensource.com>
Date: Fri, 21 Sep 2012 16:45:51 +0100
To: Julien Grall <julien.grall@citrix.com>
In-Reply-To: <1348049147-16752-1-git-send-email-julien.grall@citrix.com>
References: <1348049147-16752-1-git-send-email-julien.grall@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] libxenstore: filter watch events in libxenstore
 when we unwatch
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Julien Grall writes ("[PATCH] libxenstore: filter watch events in libxenstore when we unwatch"):
> XenStore puts in queued watch events via a thread and notifies the user.
> Sometimes xs_unwatch is called before all related message is read. The use
> case is non-threaded libevent, we have two event A and B:
>     - Event A will destroy something and call xs_unwatch;
>     - Event B is used to notify that a node has changed in XenStore.
> As the event is called one by one, event A can be handled before event B.
> So on next xs_watch_read the user could retrieve an unwatch token and
> a segfault occured if the token store the pointer of the structure
> (ie: "backend:0xcafe").

Missing from the explanation here is why your patch is sufficient to
avoid the race.  The answer is as follows (and should probably be in
the commit message):

While on entry to xs_unwatch, there may be an event on its way from
xenstored (eg in the ring or in the local kernel), all such events
will definitely come before the reply to the unwatch command.  So at
the point where the unwatch reply has been processed (after xs_talkv),
any such now-deleted watch events will definitely have made it to
libxenstore's queue where we can remove them.

As for other threads in the same process: if two threads call
xs_read_watch and xs_unwatch, it is acceptable for the xs_read_watch
to return the event being deleted.  What is not allowed is for an
xs_read_watch entered after xs_unwatch returns to return the deleted
event, and this code does indeed ensure that.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
(for the explanation)

Now for some comments on the patch:

> +	/* Filter the watch list to remove potential message */
> +	mutex_lock(&h->watch_mutex);
> +
> +	if (list_empty(&h->watch_list)) {
> +		mutex_unlock(&h->watch_mutex);
> +		return res;
> +	}

I think this check is unnecessary.  If the list is empty then walking
it is trivially a no-op.

> +	list_for_each_entry_safe(msg, tmsg, &h->watch_list, list) {
> +		assert(msg->hdr.type == XS_WATCH_EVENT);
> +
> +		strings = msg->body;
> +		num_strings = xs_count_strings(strings, msg->hdr.len);

The num_strings thing is obsolete.  There will always be two strings.
Also xs_count_strings walks the array.

> +		for (i = 0; i < num_strings; i++) {
> +			if (i == XS_WATCH_TOKEN && !strcmp (token, strings)) {

This is rather odd.  It amounts to:

   for (i= blah blah) { if (i==FIXED_VALUE) { ..i.. } }

> +				list_del(&msg->list);
> +				free(msg);
> +				break;
> +			}
> +			strings = strings + strlen (strings) + 1;

You need to check the path as well as the token, since it is legal to
set up multiple watches on different paths with the same token.

I think you can then do away with the calculation of "strings", at
least mostly.

> +	/* Clear the pipe token if there are no more pending watches. */
> +	if (list_empty(&h->watch_list) && (h->watch_pipe[0] != -1)) {
> +		while (read(h->watch_pipe[0], &c, 1) != 1)
> +			continue;
> +	}

I'm not convinced this is necessary.  Don't callers already need to
cope with potential spurious signallings of the watch pipe ?

In any case it's clone-and-hack: the same 3/4 lines occur elsewhere.
If we keep this in the patch it should be made into a function.

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 Sep 21 15:53:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Sep 2012 15:53: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 1TF5XD-0001pH-QM; Fri, 21 Sep 2012 15:52:55 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <oliver.chick@citrix.com>) id 1TF5XC-0001pB-0s
	for xen-devel@lists.xen.org; Fri, 21 Sep 2012 15:52:54 +0000
Received: from [85.158.138.51:7924] by server-12.bemta-3.messagelabs.com id
	39/45-10384-45D8C505; Fri, 21 Sep 2012 15:52:52 +0000
X-Env-Sender: oliver.chick@citrix.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1348242770!23897382!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzAyMzY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18496 invoked from network); 21 Sep 2012 15:52:51 -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;
	21 Sep 2012 15:52:51 -0000
X-IronPort-AV: E=Sophos;i="4.80,463,1344211200"; d="scan'208";a="38742075"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Sep 2012 15:52:49 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1;
	Fri, 21 Sep 2012 11:52:49 -0400
Received: from leeni.uk.xensource.com ([10.80.2.50]
	helo=oliverchick-Precision-WorkStation-T3400.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<oliver.chick@citrix.com>)	id 1TF5X6-0007zH-KN;
	Fri, 21 Sep 2012 16:52:48 +0100
From: Oliver Chick <oliver.chick@citrix.com>
To: xen-devel@lists.xen.org, linux-kernel@vger.kernel.org,
	konrad.wilk@oracle.com
Date: Fri, 21 Sep 2012 16:52:47 +0100
Message-ID: <1348242767-23732-1-git-send-email-oliver.chick@citrix.com>
X-Mailer: git-send-email 1.7.9.5
MIME-Version: 1.0
Cc: Oliver Chick <oliver.chick@citrix.com>
Subject: [Xen-devel] [PATCH v2] Persistent grant maps for xen blk drivers
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This patch implements persistent grants for the xen-blk{front,back}
mechanism. The effect of this change is to reduce the number of unmap
operations performed, since they cause a (costly) TLB shootdown. This
allows the I/O performance to scale better when a large number of VMs
are performing I/O.

Previously, the blkfront driver was supplied a bvec[] from the request
queue. This was granted to dom0; dom0 performed the I/O and wrote
directly into the grant-mapped memory and unmapped it; blkfront then
removed foreign access for that grant. The cost of unmapping scales
badly with the number of CPUs in Dom0. An experiment showed that when
Dom0 has 24 VCPUs, and guests are performing parallel I/O to a
ramdisk, the IPIs from performing unmap's is a bottleneck at 5 guests
(at which point 650,000 IOPS are being performed in total). If more
than 5 guests are used, the performance declines. By 10 guests, only
400,000 IOPS are being performed.

This patch improves performance by only unmapping when the connection
between blkfront and back is broken.

On startup, blk{front,back} use xenbus to communicate their ability to
perform 'feature-persistent'. Iff both ends have this ability,
persistent mode is used.

To perform a read, in persistent mode, blkfront uses a separate pool
of pages that it maps to dom0. When a request comes in, blkfront
transmutes the request so that blkback will write into one of these
free pages. Blkback keeps note of which grefs it has already
mapped. When a new ring request comes to blkback, it looks to see if
it has already mapped that page. If so, it will not map it again. If
the page hasn't been previously mapped, it is mapped now, and a record
is kept of this mapping. Blkback proceeds as usual. When blkfront is
notified that blkback has completed a request, it memcpy's from the
shared memory, into the bvec supplied. A record that the {gref, page}
tuple is mapped, and not inflight is kept.

Writes are similar, except that the memcpy is peformed from the
supplied bvecs, into the shared pages, before the request is put onto
the ring.

Blkback has to store a mapping of grefs=>{page mapped to by gref} in
an array. As the grefs are not known apriori, and provide no
guarantees on their ordering, we have to perform a linear search
through this array to find the page, for every gref we receive. The
overhead of this is low, however future work might want to use a more
efficient data structure to reduce this O(n) operation.

We (ijc, and myself) have introduced a new constant,
BLKIF_MAX_PERSISTENT_REQUESTS_PER_DEV. This is to prevent a malicious
guest from attempting a DoS, by supplying fresh grefs, causing the
Dom0 kernel from to map excessively. This is currently set to 64---the
maximum number of entires in the ring. As the number of inflight
requests <= size of ring, 64 is also the maximum sensible size (for
single page rings---this constant may need to be made dynamic when
multipage rings takeoff). This introduces a maximum overhead of 2.75MB
of mapped memory, per block device.  If the guest exceeds the limit,
it is either buggy or malicious. We treat this in one of two ways:

1) If we have mapped < BLKIF_MAX_SEGMENTS_PER_REQUEST *
BLKIF_MAX_PERSISTENT_REQUESTS_PER_DEV pages, we will persistently map
the grefs. This can occur is previous requests have not used all
BLKIF_MAX_SEGMENTS_PER_REQUEST segments.
 2) Otherwise, we revert to non-persistent grants for all future grefs.

In writing this patch, the question arrises as to if the additional
cost of performing memcpys in the guest (to/from the pool of granted
pages) outweigh the gains of not performing TLB shootdowns. The answer
to that question is `no'. There appears to be very little, if any
additional cost to the guest of using persistent grants. There is
perhaps a small saving, from the reduced number of hypercalls
performed in granting, and ending foreign access.

Signed-off-by: Oliver Chick <oliver.chick@citrix.com>
---

Changes since v1:

 * Maximum number of persistent grants per device now 64, rather than
   256, as this is the actual maxmimum request in a (1 page) ring.
 * If blkfront supplies more grefs than it is meant to, to blkback,
   blkback will fail to process them. This gives more predictable
   pefromance.
 * Use of `pers' as an abbreviation has been removed, in favour of the
   more clear `persistent'.
 * Fixed potential leak where we allocate space to store information
   about persistent grants, but fail to alloc a page for the grant.
 * Moved frontend persistent gnt feature information into vbd
 * Check that offset+length < page size in blkfront.
 * Minor variable renames, as suggested by Konrad
 * Added some comments documenting code, as suggested by Konrad

 drivers/block/xen-blkback/blkback.c |  166 ++++++++++++++++++++++++---
 drivers/block/xen-blkback/common.h  |   16 +++
 drivers/block/xen-blkback/xenbus.c  |   21 +++-
 drivers/block/xen-blkfront.c        |  211 +++++++++++++++++++++++++++++++----
 include/xen/interface/io/blkif.h    |   13 +++
 5 files changed, 385 insertions(+), 42 deletions(-)

diff --git a/drivers/block/xen-blkback/blkback.c b/drivers/block/xen-blkback/blkback.c
index 73f196c..8ac8d3f 100644
--- a/drivers/block/xen-blkback/blkback.c
+++ b/drivers/block/xen-blkback/blkback.c
@@ -78,6 +78,7 @@ struct pending_req {
 	unsigned short		operation;
 	int			status;
 	struct list_head	free_list;
+	unsigned int		flag_persistent:1;
 };
 
 #define BLKBACK_INVALID_HANDLE (~0)
@@ -128,6 +129,26 @@ static int dispatch_rw_block_io(struct xen_blkif *blkif,
 static void make_response(struct xen_blkif *blkif, u64 id,
 			  unsigned short op, int st);
 
+static void add_persistent_gnt(struct persistent_gnt *persistent_gnt,
+			       struct xen_blkif *blkif)
+{
+	BUG_ON(blkif->persistent_gnt_c >=
+	       BLKIF_MAX_PERSISTENT_REQUESTS_PER_DEV *
+	       BLKIF_MAX_SEGMENTS_PER_REQUEST);
+	blkif->persistent_gnts[blkif->persistent_gnt_c++] = persistent_gnt;
+}
+
+static struct persistent_gnt *get_persistent_gnt(struct xen_blkif *blkif,
+						 grant_ref_t gref)
+{
+	int i;
+
+	for (i = 0; i < blkif->persistent_gnt_c; i++)
+		if (gref == blkif->persistent_gnts[i]->gnt)
+			return blkif->persistent_gnts[i];
+	return NULL;
+}
+
 /*
  * Retrieve from the 'pending_reqs' a free pending_req structure to be used.
  */
@@ -274,6 +295,12 @@ int xen_blkif_schedule(void *arg)
 {
 	struct xen_blkif *blkif = arg;
 	struct xen_vbd *vbd = &blkif->vbd;
+	struct gnttab_unmap_grant_ref unmap[BLKIF_MAX_SEGMENTS_PER_REQUEST];
+	struct page *pages[BLKIF_MAX_SEGMENTS_PER_REQUEST];
+	struct persistent_gnt *persistent_gnt;
+	int i;
+	int ret = 0;
+	int segs_to_unmap;
 
 	xen_blkif_get(blkif);
 
@@ -301,6 +328,31 @@ int xen_blkif_schedule(void *arg)
 			print_stats(blkif);
 	}
 
+	/* Free all persistent grant pages */
+
+	while ((segs_to_unmap = min(BLKIF_MAX_SEGMENTS_PER_REQUEST,
+				    blkif->persistent_gnt_c))) {
+
+		for (i = 0; i < segs_to_unmap; i++) {
+			persistent_gnt = blkif->persistent_gnts
+				[blkif->persistent_gnt_c - i - 1];
+
+			gnttab_set_unmap_op(&unmap[i],
+					    pfn_to_kaddr(page_to_pfn(
+							     persistent_gnt->page)),
+					    GNTMAP_host_map,
+					    persistent_gnt->handle);
+
+			pages[i] = persistent_gnt->page;
+		}
+
+		ret = gnttab_unmap_refs(unmap, pages, segs_to_unmap, false);
+		BUG_ON(ret);
+
+		blkif->persistent_gnt_c -= segs_to_unmap;
+
+	}
+
 	if (log_stats)
 		print_stats(blkif);
 
@@ -343,13 +395,31 @@ static void xen_blkbk_unmap(struct pending_req *req)
 
 static int xen_blkbk_map(struct blkif_request *req,
 			 struct pending_req *pending_req,
-			 struct seg_buf seg[])
+			 struct seg_buf seg[],
+			 struct page *pages[])
 {
 	struct gnttab_map_grant_ref map[BLKIF_MAX_SEGMENTS_PER_REQUEST];
+	struct persistent_gnt
+		*new_persistent_gnts[BLKIF_MAX_SEGMENTS_PER_REQUEST];
+	struct persistent_gnt *persistent_gnts[BLKIF_MAX_SEGMENTS_PER_REQUEST];
+	struct page *pages_to_gnt[BLKIF_MAX_SEGMENTS_PER_REQUEST];
+	struct persistent_gnt *persistent_gnt;
+	phys_addr_t addr;
 	int i;
+	int new_map;
 	int nseg = req->u.rw.nr_segments;
+	int segs_to_map = 0;
 	int ret = 0;
+	int use_persistent_gnts;
+
+	use_persistent_gnts = (pending_req->blkif->vbd.feature_gnt_persistent);
+
+	if (pending_req->blkif->persistent_gnt_c >=
+	    BLKIF_MAX_SEGMENTS_PER_REQUEST *
+	    BLKIF_MAX_PERSISTENT_REQUESTS_PER_DEV)
+		return -EIO;
 
+	pending_req->flag_persistent = use_persistent_gnts;
 	/*
 	 * Fill out preq.nr_sects with proper amount of sectors, and setup
 	 * assign map[..] with the PFN of the page in our domain with the
@@ -358,36 +428,97 @@ static int xen_blkbk_map(struct blkif_request *req,
 	for (i = 0; i < nseg; i++) {
 		uint32_t flags;
 
+		if (use_persistent_gnts) {
+			persistent_gnt = get_persistent_gnt(
+				pending_req->blkif,
+				req->u.rw.seg[i].gref);
+			if (!persistent_gnt) {
+				new_map = 1;
+				persistent_gnt = kmalloc(
+					sizeof(struct persistent_gnt),
+					GFP_KERNEL);
+				if (!persistent_gnt)
+					return -ENOMEM;
+				persistent_gnt->page = alloc_page(GFP_KERNEL);
+				if (!persistent_gnt->page) {
+					kfree(persistent_gnt);
+					return -ENOMEM;
+				}
+				persistent_gnt->gnt = req->u.rw.seg[i].gref;
+
+				pages_to_gnt[segs_to_map] =
+					persistent_gnt->page;
+				new_persistent_gnts[segs_to_map] =
+					persistent_gnt;
+
+				add_persistent_gnt(persistent_gnt,
+						   pending_req->blkif);
+
+			} else {
+				new_map = 0;
+			}
+			pages[i] = persistent_gnt->page;
+			addr = (unsigned long) pfn_to_kaddr(
+				page_to_pfn(persistent_gnt->page));
+			persistent_gnts[i] = persistent_gnt;
+		} else {
+			new_map = 1;
+			pages[i] = blkbk->pending_page(pending_req, i);
+			addr = vaddr(pending_req, i);
+			pages_to_gnt[i] = blkbk->pending_page(pending_req, i);
+		}
+
 		flags = GNTMAP_host_map;
-		if (pending_req->operation != BLKIF_OP_READ)
+		if (!use_persistent_gnts &&
+		    (pending_req->operation != BLKIF_OP_READ))
 			flags |= GNTMAP_readonly;
-		gnttab_set_map_op(&map[i], vaddr(pending_req, i), flags,
-				  req->u.rw.seg[i].gref,
-				  pending_req->blkif->domid);
+		if (new_map) {
+			gnttab_set_map_op(&map[segs_to_map++], addr,
+					  flags, req->u.rw.seg[i].gref,
+					  pending_req->blkif->domid);
+		}
 	}
 
-	ret = gnttab_map_refs(map, NULL, &blkbk->pending_page(pending_req, 0), nseg);
-	BUG_ON(ret);
+	if (segs_to_map) {
+		ret = gnttab_map_refs(map, NULL, pages_to_gnt, segs_to_map);
+		BUG_ON(ret);
+	}
 
 	/*
 	 * Now swizzle the MFN in our domain with the MFN from the other domain
 	 * so that when we access vaddr(pending_req,i) it has the contents of
 	 * the page from the other domain.
 	 */
-	for (i = 0; i < nseg; i++) {
+	for (i = 0; i < segs_to_map; i++) {
 		if (unlikely(map[i].status != 0)) {
 			pr_debug(DRV_PFX "invalid buffer -- could not remap it\n");
 			map[i].handle = BLKBACK_INVALID_HANDLE;
 			ret |= 1;
 		}
 
-		pending_handle(pending_req, i) = map[i].handle;
+		if (use_persistent_gnts) {
+			/* store the `out' values from map */
+		    pending_req->blkif->persistent_gnts
+			[pending_req->blkif->persistent_gnt_c - segs_to_map +
+			 i]->handle = map[i].handle;
+			new_persistent_gnts[i]->dev_bus_addr =
+				map[i].dev_bus_addr;
+		}
 
 		if (ret)
 			continue;
-
-		seg[i].buf  = map[i].dev_bus_addr |
-			(req->u.rw.seg[i].first_sect << 9);
+	}
+	for (i = 0; i < nseg; i++) {
+		if (use_persistent_gnts) {
+			pending_handle(pending_req, i) =
+				persistent_gnts[i]->handle;
+			seg[i].buf = persistent_gnts[i]->dev_bus_addr |
+				(req->u.rw.seg[i].first_sect << 9);
+		} else {
+			pending_handle(pending_req, i) = map[i].handle;
+			seg[i].buf = map[i].dev_bus_addr |
+				(req->u.rw.seg[i].first_sect << 9);
+		}
 	}
 	return ret;
 }
@@ -468,7 +599,8 @@ static void __end_block_io_op(struct pending_req *pending_req, int error)
 	 * the proper response on the ring.
 	 */
 	if (atomic_dec_and_test(&pending_req->pendcnt)) {
-		xen_blkbk_unmap(pending_req);
+		if (!pending_req->flag_persistent)
+			xen_blkbk_unmap(pending_req);
 		make_response(pending_req->blkif, pending_req->id,
 			      pending_req->operation, pending_req->status);
 		xen_blkif_put(pending_req->blkif);
@@ -590,6 +722,7 @@ static int dispatch_rw_block_io(struct xen_blkif *blkif,
 	int operation;
 	struct blk_plug plug;
 	bool drain = false;
+	struct page *pages[BLKIF_MAX_SEGMENTS_PER_REQUEST];
 
 	switch (req->operation) {
 	case BLKIF_OP_READ:
@@ -676,7 +809,7 @@ static int dispatch_rw_block_io(struct xen_blkif *blkif,
 	 * the hypercall to unmap the grants - that is all done in
 	 * xen_blkbk_unmap.
 	 */
-	if (xen_blkbk_map(req, pending_req, seg))
+	if (xen_blkbk_map(req, pending_req, seg, pages))
 		goto fail_flush;
 
 	/*
@@ -688,7 +821,7 @@ static int dispatch_rw_block_io(struct xen_blkif *blkif,
 	for (i = 0; i < nseg; i++) {
 		while ((bio == NULL) ||
 		       (bio_add_page(bio,
-				     blkbk->pending_page(pending_req, i),
+				     pages[i],
 				     seg[i].nsec << 9,
 				     seg[i].buf & ~PAGE_MASK) == 0)) {
 
@@ -743,7 +876,8 @@ static int dispatch_rw_block_io(struct xen_blkif *blkif,
 	return 0;
 
  fail_flush:
-	xen_blkbk_unmap(pending_req);
+	if (!blkif->vbd.feature_gnt_persistent)
+		xen_blkbk_unmap(pending_req);
  fail_response:
 	/* Haven't submitted any bio's yet. */
 	make_response(blkif, req->u.rw.id, req->operation, BLKIF_RSP_ERROR);
diff --git a/drivers/block/xen-blkback/common.h b/drivers/block/xen-blkback/common.h
index 9ad3b5e..0b7e049 100644
--- a/drivers/block/xen-blkback/common.h
+++ b/drivers/block/xen-blkback/common.h
@@ -160,10 +160,20 @@ struct xen_vbd {
 	sector_t		size;
 	bool			flush_support;
 	bool			discard_secure;
+
+	unsigned int		feature_gnt_persistent:1;
 };
 
 struct backend_info;
 
+
+struct persistent_gnt {
+	struct page *page;
+	grant_ref_t gnt;
+	grant_handle_t handle;
+	uint64_t dev_bus_addr;
+};
+
 struct xen_blkif {
 	/* Unique identifier for this interface. */
 	domid_t			domid;
@@ -190,6 +200,12 @@ struct xen_blkif {
 	struct task_struct	*xenblkd;
 	unsigned int		waiting_reqs;
 
+	/* frontend feature information */
+	struct persistent_gnt	*persistent_gnts
+					[BLKIF_MAX_PERSISTENT_REQUESTS_PER_DEV
+					 * BLKIF_MAX_SEGMENTS_PER_REQUEST];
+	unsigned int		persistent_gnt_c;
+
 	/* statistics */
 	unsigned long		st_print;
 	int			st_rd_req;
diff --git a/drivers/block/xen-blkback/xenbus.c b/drivers/block/xen-blkback/xenbus.c
index 4f66171..473e416 100644
--- a/drivers/block/xen-blkback/xenbus.c
+++ b/drivers/block/xen-blkback/xenbus.c
@@ -681,6 +681,13 @@ again:
 		goto abort;
 	}
 
+	err = xenbus_printf(xbt, dev->nodename, "feature-persistent-grants",
+			    "%d", 1);
+	if (err) {
+		dev_warn(&dev->dev, "writing persistent grants feature");
+		goto abort;
+	}
+
 	/* FIXME: use a typename instead */
 	err = xenbus_printf(xbt, dev->nodename, "info", "%u",
 			    be->blkif->vbd.type |
@@ -721,6 +728,7 @@ static int connect_ring(struct backend_info *be)
 	struct xenbus_device *dev = be->dev;
 	unsigned long ring_ref;
 	unsigned int evtchn;
+	u8 pers_grants;
 	char protocol[64] = "";
 	int err;
 
@@ -750,8 +758,17 @@ static int connect_ring(struct backend_info *be)
 		xenbus_dev_fatal(dev, err, "unknown fe protocol %s", protocol);
 		return -1;
 	}
-	pr_info(DRV_PFX "ring-ref %ld, event-channel %d, protocol %d (%s)\n",
-		ring_ref, evtchn, be->blkif->blk_protocol, protocol);
+	err = xenbus_gather(XBT_NIL, dev->otherend,
+			    "feature-persistent-grants", "%d",
+			    &pers_grants, NULL);
+	if (err)
+		pers_grants = 0;
+
+	be->blkif->vbd.feature_gnt_persistent = pers_grants;
+
+	pr_info(DRV_PFX "ring-ref %ld, event-channel %d, protocol %d (%s) persistent %d\n",
+		ring_ref, evtchn, be->blkif->blk_protocol, protocol,
+		pers_grants);
 
 	/* Map the shared frame, irq etc. */
 	err = xen_blkif_map(be->blkif, ring_ref, evtchn);
diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c
index 2c2d2e5..9606c5a 100644
--- a/drivers/block/xen-blkfront.c
+++ b/drivers/block/xen-blkfront.c
@@ -64,10 +64,17 @@ enum blkif_state {
 	BLKIF_STATE_SUSPENDED,
 };
 
+struct gnt_list {
+	grant_ref_t gref;
+	unsigned long pfn;
+	struct gnt_list *tail;
+};
+
 struct blk_shadow {
 	struct blkif_request req;
 	struct request *request;
 	unsigned long frame[BLKIF_MAX_SEGMENTS_PER_REQUEST];
+	struct gnt_list *grants_used[BLKIF_MAX_SEGMENTS_PER_REQUEST];
 };
 
 static DEFINE_MUTEX(blkfront_mutex);
@@ -97,11 +104,14 @@ struct blkfront_info
 	struct work_struct work;
 	struct gnttab_free_callback callback;
 	struct blk_shadow shadow[BLK_RING_SIZE];
+	struct gnt_list *persistent_gnts;
+	unsigned int persistent_gnts_c;
 	unsigned long shadow_free;
 	unsigned int feature_flush;
 	unsigned int flush_op;
 	unsigned int feature_discard:1;
 	unsigned int feature_secdiscard:1;
+	unsigned int feature_persistent:1;
 	unsigned int discard_granularity;
 	unsigned int discard_alignment;
 	int is_ready;
@@ -287,21 +297,42 @@ static int blkif_queue_request(struct request *req)
 	unsigned long id;
 	unsigned int fsect, lsect;
 	int i, ref;
+
+	/*
+	 * stores if we have negotiated with the backend, agreeing to use
+	 * persistent grants.
+	 */
+	int use_persistent_gnts;
+
+	/*
+	 * Used when doing persistent grants to store if we are able to queue
+	 * the request by just using existing persistent grants (0), or if we
+	 * have to get new grants, as there are not sufficiently many free.
+	 */
+	int new_persistent_gnts;
 	grant_ref_t gref_head;
+	struct page *granted_page;
+	struct gnt_list *gnt_list_entry;
 	struct scatterlist *sg;
 
 	if (unlikely(info->connected != BLKIF_STATE_CONNECTED))
 		return 1;
 
-	if (gnttab_alloc_grant_references(
-		BLKIF_MAX_SEGMENTS_PER_REQUEST, &gref_head) < 0) {
-		gnttab_request_free_callback(
-			&info->callback,
-			blkif_restart_queue_callback,
-			info,
-			BLKIF_MAX_SEGMENTS_PER_REQUEST);
-		return 1;
-	}
+	use_persistent_gnts = info->feature_persistent;
+
+	if (info->persistent_gnts_c < BLKIF_MAX_SEGMENTS_PER_REQUEST) {
+		new_persistent_gnts = 1;
+		if (gnttab_alloc_grant_references(
+			    BLKIF_MAX_SEGMENTS_PER_REQUEST, &gref_head) < 0) {
+			gnttab_request_free_callback(
+				&info->callback,
+				blkif_restart_queue_callback,
+				info,
+				BLKIF_MAX_SEGMENTS_PER_REQUEST);
+			return 1;
+		}
+	} else
+		new_persistent_gnts = 0;
 
 	/* Fill out a communications ring structure. */
 	ring_req = RING_GET_REQUEST(&info->ring, info->ring.req_prod_pvt);
@@ -341,20 +372,83 @@ static int blkif_queue_request(struct request *req)
 		       BLKIF_MAX_SEGMENTS_PER_REQUEST);
 
 		for_each_sg(info->sg, sg, ring_req->u.rw.nr_segments, i) {
-			buffer_mfn = pfn_to_mfn(page_to_pfn(sg_page(sg)));
 			fsect = sg->offset >> 9;
 			lsect = fsect + (sg->length >> 9) - 1;
-			/* install a grant reference. */
-			ref = gnttab_claim_grant_reference(&gref_head);
-			BUG_ON(ref == -ENOSPC);
 
-			gnttab_grant_foreign_access_ref(
+			if (use_persistent_gnts && info->persistent_gnts_c) {
+				gnt_list_entry = info->persistent_gnts;
+
+				info->persistent_gnts = info->persistent_gnts->
+					tail;
+				ref = gnt_list_entry->gref;
+				buffer_mfn = pfn_to_mfn(gnt_list_entry->pfn);
+				info->persistent_gnts_c--;
+			} else {
+				ref = gnttab_claim_grant_reference(&gref_head);
+				BUG_ON(ref == -ENOSPC);
+
+				if (use_persistent_gnts) {
+					gnt_list_entry =
+						kmalloc(sizeof(struct gnt_list),
+								 GFP_ATOMIC);
+					if (!gnt_list_entry)
+						return -ENOMEM;
+
+					granted_page = alloc_page(GFP_ATOMIC);
+					if (!granted_page) {
+						kfree(gnt_list_entry);
+						return -ENOMEM;
+					}
+
+					gnt_list_entry->pfn =
+						page_to_pfn(granted_page);
+					gnt_list_entry->gref = ref;
+				} else
+					granted_page = sg_page(sg);
+
+				buffer_mfn = pfn_to_mfn(page_to_pfn(
+								granted_page));
+				gnttab_grant_foreign_access_ref(
 					ref,
 					info->xbdev->otherend_id,
 					buffer_mfn,
+					!use_persistent_gnts &&
 					rq_data_dir(req));
+			}
+
+			if (use_persistent_gnts)
+				info->shadow[id].grants_used[i] =
+					gnt_list_entry;
+
+			if (use_persistent_gnts && rq_data_dir(req)) {
+				char *bvec_data;
+				void *shared_data;
+
+				BUG_ON(sg->offset + sg->length > PAGE_SIZE);
+
+				shared_data = kmap_atomic(
+					pfn_to_page(gnt_list_entry->pfn));
+				bvec_data = kmap_atomic(sg_page(sg));
+
+				/*
+				 * this does not wipe data stored outside the
+				 * range sg->offset..sg->offset+sg->length.
+				 * Therefore, blkback *could* see data from
+				 * previous requests. This is OK as long as
+				 * persistent grants are shared with just one
+				 * domain. It may need refactoring if This
+				 * changes
+				 */
+				memcpy(shared_data + sg->offset,
+				       bvec_data   + sg->offset,
+				       sg->length);
+
+				kunmap_atomic(bvec_data);
+				kunmap_atomic(shared_data);
+			}
 
 			info->shadow[id].frame[i] = mfn_to_pfn(buffer_mfn);
+
 			ring_req->u.rw.seg[i] =
 					(struct blkif_request_segment) {
 						.gref       = ref,
@@ -368,7 +462,8 @@ static int blkif_queue_request(struct request *req)
 	/* Keep a private copy so we can reissue requests when recovering. */
 	info->shadow[id].req = *ring_req;
 
-	gnttab_free_grant_references(gref_head);
+	if (new_persistent_gnts)
+		gnttab_free_grant_references(gref_head);
 
 	return 0;
 }
@@ -480,12 +575,13 @@ static int xlvbd_init_blk_queue(struct gendisk *gd, u16 sector_size)
 static void xlvbd_flush(struct blkfront_info *info)
 {
 	blk_queue_flush(info->rq, info->feature_flush);
-	printk(KERN_INFO "blkfront: %s: %s: %s\n",
+	printk(KERN_INFO "blkfront: %s: %s: %s %s\n",
 	       info->gd->disk_name,
 	       info->flush_op == BLKIF_OP_WRITE_BARRIER ?
 		"barrier" : (info->flush_op == BLKIF_OP_FLUSH_DISKCACHE ?
 		"flush diskcache" : "barrier or flush"),
-	       info->feature_flush ? "enabled" : "disabled");
+	       info->feature_flush ? "enabled" : "disabled",
+	       info->feature_persistent ? "persistent" : "non-persistent");
 }
 
 static int xen_translate_vdev(int vdevice, int *minor, unsigned int *offset)
@@ -707,6 +803,8 @@ static void blkif_restart_queue(struct work_struct *work)
 
 static void blkif_free(struct blkfront_info *info, int suspend)
 {
+	struct gnt_list *persistent_gnt;
+
 	/* Prevent new requests being issued until we fix things up. */
 	spin_lock_irq(&info->io_lock);
 	info->connected = suspend ?
@@ -714,6 +812,15 @@ static void blkif_free(struct blkfront_info *info, int suspend)
 	/* No more blkif_request(). */
 	if (info->rq)
 		blk_stop_queue(info->rq);
+
+	/* Remove all persistent grants */
+	while (info->persistent_gnts) {
+		persistent_gnt = info->persistent_gnts;
+		info->persistent_gnts = persistent_gnt->tail;
+		gnttab_end_foreign_access(persistent_gnt->gref, 0, 0UL);
+		kfree(persistent_gnt);
+	}
+
 	/* No more gnttab callback work. */
 	gnttab_cancel_free_callback(&info->callback);
 	spin_unlock_irq(&info->io_lock);
@@ -734,13 +841,47 @@ static void blkif_free(struct blkfront_info *info, int suspend)
 
 }
 
-static void blkif_completion(struct blk_shadow *s)
+static void blkif_completion(struct blk_shadow *s, struct blkfront_info *info,
+			     struct blkif_response *bret)
 {
 	int i;
-	/* Do not let BLKIF_OP_DISCARD as nr_segment is in the same place
-	 * flag. */
-	for (i = 0; i < s->req.u.rw.nr_segments; i++)
-		gnttab_end_foreign_access(s->req.u.rw.seg[i].gref, 0, 0UL);
+	struct gnt_list *new_gnt_list_entry;
+	struct bio_vec *bvec;
+	struct req_iterator iter;
+	unsigned long flags;
+	char *bvec_data;
+	void *shared_data;
+
+
+	if (info->feature_persistent == 0) {
+		/* Do not let BLKIF_OP_DISCARD as nr_segment is in the same
+		 * place flag. */
+		for (i = 0; i < s->req.u.rw.nr_segments; i++)
+			gnttab_end_foreign_access(s->req.u.rw.seg[i].gref,
+						  0, 0UL);
+		return;
+	}
+
+	i = 0;
+	if (bret->operation == BLKIF_OP_READ)
+		rq_for_each_segment(bvec, s->request, iter) {
+			BUG_ON(bvec->bv_offset + bvec->bv_len > PAGE_SIZE);
+
+			shared_data = kmap_atomic
+				(pfn_to_page(s->grants_used[i++]->pfn));
+			bvec_data = bvec_kmap_irq(bvec, &flags);
+			memcpy(bvec_data, shared_data + bvec->bv_offset,
+			       bvec->bv_len);
+			bvec_kunmap_irq(bvec_data, &flags);
+			kunmap_atomic(shared_data);
+		}
+	/* Add the persistent grant into the list of free grants */
+	for (i = 0; i < s->req.u.rw.nr_segments; i++) {
+		new_gnt_list_entry = s->grants_used[i];
+		new_gnt_list_entry->tail = info->persistent_gnts;
+		info->persistent_gnts = new_gnt_list_entry;
+		info->persistent_gnts_c++;
+	}
 }
 
 static irqreturn_t blkif_interrupt(int irq, void *dev_id)
@@ -783,7 +924,7 @@ static irqreturn_t blkif_interrupt(int irq, void *dev_id)
 		req  = info->shadow[id].request;
 
 		if (bret->operation != BLKIF_OP_DISCARD)
-			blkif_completion(&info->shadow[id]);
+			blkif_completion(&info->shadow[id], info, bret);
 
 		if (add_id_to_freelist(info, id)) {
 			WARN(1, "%s: response to %s (id %ld) couldn't be recycled!\n",
@@ -942,6 +1083,13 @@ again:
 		message = "writing protocol";
 		goto abort_transaction;
 	}
+	err = xenbus_printf(xbt, dev->nodename,
+			    "feature-persistent-grants", "%d", 1);
+	if (err) {
+		dev_warn(&dev->dev,
+			 "writing persistent grants feature to xenbus");
+		info->feature_persistent = 0;
+	}
 
 	err = xenbus_transaction_end(xbt, 0);
 	if (err) {
@@ -1029,6 +1177,7 @@ static int blkfront_probe(struct xenbus_device *dev,
 	spin_lock_init(&info->io_lock);
 	info->xbdev = dev;
 	info->vdevice = vdevice;
+	info->persistent_gnts_c = 0;
 	info->connected = BLKIF_STATE_DISCONNECTED;
 	INIT_WORK(&info->work, blkif_restart_queue);
 
@@ -1093,6 +1242,7 @@ static int blkif_recover(struct blkfront_info *info)
 					req->u.rw.seg[j].gref,
 					info->xbdev->otherend_id,
 					pfn_to_mfn(info->shadow[req->u.rw.id].frame[j]),
+					!info->feature_persistent &&
 					rq_data_dir(info->shadow[req->u.rw.id].request));
 		}
 		info->shadow[req->u.rw.id].req = *req;
@@ -1225,7 +1375,7 @@ static void blkfront_connect(struct blkfront_info *info)
 	unsigned long sector_size;
 	unsigned int binfo;
 	int err;
-	int barrier, flush, discard;
+	int barrier, flush, discard, persistent;
 
 	switch (info->connected) {
 	case BLKIF_STATE_CONNECTED:
@@ -1296,6 +1446,19 @@ static void blkfront_connect(struct blkfront_info *info)
 		info->flush_op = BLKIF_OP_FLUSH_DISKCACHE;
 	}
 
+	/*
+	 * Are we dealing with an old blkback that will unmap
+	 * all grefs?
+	 */
+	err = xenbus_gather(XBT_NIL, info->xbdev->otherend,
+			    "feature-persistent-grants", "%d", &persistent,
+			    NULL);
+
+	if (err)
+		info->feature_persistent = 0;
+	else
+		info->feature_persistent = persistent;
+
 	err = xenbus_gather(XBT_NIL, info->xbdev->otherend,
 			    "feature-discard", "%d", &discard,
 			    NULL);
diff --git a/include/xen/interface/io/blkif.h b/include/xen/interface/io/blkif.h
index ee338bf..9048df1 100644
--- a/include/xen/interface/io/blkif.h
+++ b/include/xen/interface/io/blkif.h
@@ -109,6 +109,19 @@ typedef uint64_t blkif_sector_t;
  */
 #define BLKIF_MAX_SEGMENTS_PER_REQUEST 11
 
+/*
+ * Maximum number of inflight requests that can be sent by from
+ * blkfront, and will be guaranteed to be persistently mapped.
+ * BLKIF_MAX_SEGMENTS_PER_REQUEST *
+ * BLKIF_MAX_PERSISTENT_REQUESTS_PER_DEV is the maximum number of
+ * pages that blkback will persistently map. This is set to be the size
+ * of the ring, as this is a limit on the number of requests that can
+ * be inflight at any one time. 64 imposes an overhead of 2.75MB of
+ * mapped kernel space per interface.
+ */
+#define BLKIF_MAX_PERSISTENT_REQUESTS_PER_DEV 64
+
+
 struct blkif_request_rw {
 	uint8_t        nr_segments;  /* number of segments                   */
 	blkif_vdev_t   handle;       /* only for read/write requests         */
-- 
1.7.9.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 21 15:53:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Sep 2012 15:53: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 1TF5XD-0001pH-QM; Fri, 21 Sep 2012 15:52:55 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <oliver.chick@citrix.com>) id 1TF5XC-0001pB-0s
	for xen-devel@lists.xen.org; Fri, 21 Sep 2012 15:52:54 +0000
Received: from [85.158.138.51:7924] by server-12.bemta-3.messagelabs.com id
	39/45-10384-45D8C505; Fri, 21 Sep 2012 15:52:52 +0000
X-Env-Sender: oliver.chick@citrix.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1348242770!23897382!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzAyMzY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18496 invoked from network); 21 Sep 2012 15:52:51 -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;
	21 Sep 2012 15:52:51 -0000
X-IronPort-AV: E=Sophos;i="4.80,463,1344211200"; d="scan'208";a="38742075"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Sep 2012 15:52:49 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1;
	Fri, 21 Sep 2012 11:52:49 -0400
Received: from leeni.uk.xensource.com ([10.80.2.50]
	helo=oliverchick-Precision-WorkStation-T3400.uk.xensource.com)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<oliver.chick@citrix.com>)	id 1TF5X6-0007zH-KN;
	Fri, 21 Sep 2012 16:52:48 +0100
From: Oliver Chick <oliver.chick@citrix.com>
To: xen-devel@lists.xen.org, linux-kernel@vger.kernel.org,
	konrad.wilk@oracle.com
Date: Fri, 21 Sep 2012 16:52:47 +0100
Message-ID: <1348242767-23732-1-git-send-email-oliver.chick@citrix.com>
X-Mailer: git-send-email 1.7.9.5
MIME-Version: 1.0
Cc: Oliver Chick <oliver.chick@citrix.com>
Subject: [Xen-devel] [PATCH v2] Persistent grant maps for xen blk drivers
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This patch implements persistent grants for the xen-blk{front,back}
mechanism. The effect of this change is to reduce the number of unmap
operations performed, since they cause a (costly) TLB shootdown. This
allows the I/O performance to scale better when a large number of VMs
are performing I/O.

Previously, the blkfront driver was supplied a bvec[] from the request
queue. This was granted to dom0; dom0 performed the I/O and wrote
directly into the grant-mapped memory and unmapped it; blkfront then
removed foreign access for that grant. The cost of unmapping scales
badly with the number of CPUs in Dom0. An experiment showed that when
Dom0 has 24 VCPUs, and guests are performing parallel I/O to a
ramdisk, the IPIs from performing unmap's is a bottleneck at 5 guests
(at which point 650,000 IOPS are being performed in total). If more
than 5 guests are used, the performance declines. By 10 guests, only
400,000 IOPS are being performed.

This patch improves performance by only unmapping when the connection
between blkfront and back is broken.

On startup, blk{front,back} use xenbus to communicate their ability to
perform 'feature-persistent'. Iff both ends have this ability,
persistent mode is used.

To perform a read, in persistent mode, blkfront uses a separate pool
of pages that it maps to dom0. When a request comes in, blkfront
transmutes the request so that blkback will write into one of these
free pages. Blkback keeps note of which grefs it has already
mapped. When a new ring request comes to blkback, it looks to see if
it has already mapped that page. If so, it will not map it again. If
the page hasn't been previously mapped, it is mapped now, and a record
is kept of this mapping. Blkback proceeds as usual. When blkfront is
notified that blkback has completed a request, it memcpy's from the
shared memory, into the bvec supplied. A record that the {gref, page}
tuple is mapped, and not inflight is kept.

Writes are similar, except that the memcpy is peformed from the
supplied bvecs, into the shared pages, before the request is put onto
the ring.

Blkback has to store a mapping of grefs=>{page mapped to by gref} in
an array. As the grefs are not known apriori, and provide no
guarantees on their ordering, we have to perform a linear search
through this array to find the page, for every gref we receive. The
overhead of this is low, however future work might want to use a more
efficient data structure to reduce this O(n) operation.

We (ijc, and myself) have introduced a new constant,
BLKIF_MAX_PERSISTENT_REQUESTS_PER_DEV. This is to prevent a malicious
guest from attempting a DoS, by supplying fresh grefs, causing the
Dom0 kernel from to map excessively. This is currently set to 64---the
maximum number of entires in the ring. As the number of inflight
requests <= size of ring, 64 is also the maximum sensible size (for
single page rings---this constant may need to be made dynamic when
multipage rings takeoff). This introduces a maximum overhead of 2.75MB
of mapped memory, per block device.  If the guest exceeds the limit,
it is either buggy or malicious. We treat this in one of two ways:

1) If we have mapped < BLKIF_MAX_SEGMENTS_PER_REQUEST *
BLKIF_MAX_PERSISTENT_REQUESTS_PER_DEV pages, we will persistently map
the grefs. This can occur is previous requests have not used all
BLKIF_MAX_SEGMENTS_PER_REQUEST segments.
 2) Otherwise, we revert to non-persistent grants for all future grefs.

In writing this patch, the question arrises as to if the additional
cost of performing memcpys in the guest (to/from the pool of granted
pages) outweigh the gains of not performing TLB shootdowns. The answer
to that question is `no'. There appears to be very little, if any
additional cost to the guest of using persistent grants. There is
perhaps a small saving, from the reduced number of hypercalls
performed in granting, and ending foreign access.

Signed-off-by: Oliver Chick <oliver.chick@citrix.com>
---

Changes since v1:

 * Maximum number of persistent grants per device now 64, rather than
   256, as this is the actual maxmimum request in a (1 page) ring.
 * If blkfront supplies more grefs than it is meant to, to blkback,
   blkback will fail to process them. This gives more predictable
   pefromance.
 * Use of `pers' as an abbreviation has been removed, in favour of the
   more clear `persistent'.
 * Fixed potential leak where we allocate space to store information
   about persistent grants, but fail to alloc a page for the grant.
 * Moved frontend persistent gnt feature information into vbd
 * Check that offset+length < page size in blkfront.
 * Minor variable renames, as suggested by Konrad
 * Added some comments documenting code, as suggested by Konrad

 drivers/block/xen-blkback/blkback.c |  166 ++++++++++++++++++++++++---
 drivers/block/xen-blkback/common.h  |   16 +++
 drivers/block/xen-blkback/xenbus.c  |   21 +++-
 drivers/block/xen-blkfront.c        |  211 +++++++++++++++++++++++++++++++----
 include/xen/interface/io/blkif.h    |   13 +++
 5 files changed, 385 insertions(+), 42 deletions(-)

diff --git a/drivers/block/xen-blkback/blkback.c b/drivers/block/xen-blkback/blkback.c
index 73f196c..8ac8d3f 100644
--- a/drivers/block/xen-blkback/blkback.c
+++ b/drivers/block/xen-blkback/blkback.c
@@ -78,6 +78,7 @@ struct pending_req {
 	unsigned short		operation;
 	int			status;
 	struct list_head	free_list;
+	unsigned int		flag_persistent:1;
 };
 
 #define BLKBACK_INVALID_HANDLE (~0)
@@ -128,6 +129,26 @@ static int dispatch_rw_block_io(struct xen_blkif *blkif,
 static void make_response(struct xen_blkif *blkif, u64 id,
 			  unsigned short op, int st);
 
+static void add_persistent_gnt(struct persistent_gnt *persistent_gnt,
+			       struct xen_blkif *blkif)
+{
+	BUG_ON(blkif->persistent_gnt_c >=
+	       BLKIF_MAX_PERSISTENT_REQUESTS_PER_DEV *
+	       BLKIF_MAX_SEGMENTS_PER_REQUEST);
+	blkif->persistent_gnts[blkif->persistent_gnt_c++] = persistent_gnt;
+}
+
+static struct persistent_gnt *get_persistent_gnt(struct xen_blkif *blkif,
+						 grant_ref_t gref)
+{
+	int i;
+
+	for (i = 0; i < blkif->persistent_gnt_c; i++)
+		if (gref == blkif->persistent_gnts[i]->gnt)
+			return blkif->persistent_gnts[i];
+	return NULL;
+}
+
 /*
  * Retrieve from the 'pending_reqs' a free pending_req structure to be used.
  */
@@ -274,6 +295,12 @@ int xen_blkif_schedule(void *arg)
 {
 	struct xen_blkif *blkif = arg;
 	struct xen_vbd *vbd = &blkif->vbd;
+	struct gnttab_unmap_grant_ref unmap[BLKIF_MAX_SEGMENTS_PER_REQUEST];
+	struct page *pages[BLKIF_MAX_SEGMENTS_PER_REQUEST];
+	struct persistent_gnt *persistent_gnt;
+	int i;
+	int ret = 0;
+	int segs_to_unmap;
 
 	xen_blkif_get(blkif);
 
@@ -301,6 +328,31 @@ int xen_blkif_schedule(void *arg)
 			print_stats(blkif);
 	}
 
+	/* Free all persistent grant pages */
+
+	while ((segs_to_unmap = min(BLKIF_MAX_SEGMENTS_PER_REQUEST,
+				    blkif->persistent_gnt_c))) {
+
+		for (i = 0; i < segs_to_unmap; i++) {
+			persistent_gnt = blkif->persistent_gnts
+				[blkif->persistent_gnt_c - i - 1];
+
+			gnttab_set_unmap_op(&unmap[i],
+					    pfn_to_kaddr(page_to_pfn(
+							     persistent_gnt->page)),
+					    GNTMAP_host_map,
+					    persistent_gnt->handle);
+
+			pages[i] = persistent_gnt->page;
+		}
+
+		ret = gnttab_unmap_refs(unmap, pages, segs_to_unmap, false);
+		BUG_ON(ret);
+
+		blkif->persistent_gnt_c -= segs_to_unmap;
+
+	}
+
 	if (log_stats)
 		print_stats(blkif);
 
@@ -343,13 +395,31 @@ static void xen_blkbk_unmap(struct pending_req *req)
 
 static int xen_blkbk_map(struct blkif_request *req,
 			 struct pending_req *pending_req,
-			 struct seg_buf seg[])
+			 struct seg_buf seg[],
+			 struct page *pages[])
 {
 	struct gnttab_map_grant_ref map[BLKIF_MAX_SEGMENTS_PER_REQUEST];
+	struct persistent_gnt
+		*new_persistent_gnts[BLKIF_MAX_SEGMENTS_PER_REQUEST];
+	struct persistent_gnt *persistent_gnts[BLKIF_MAX_SEGMENTS_PER_REQUEST];
+	struct page *pages_to_gnt[BLKIF_MAX_SEGMENTS_PER_REQUEST];
+	struct persistent_gnt *persistent_gnt;
+	phys_addr_t addr;
 	int i;
+	int new_map;
 	int nseg = req->u.rw.nr_segments;
+	int segs_to_map = 0;
 	int ret = 0;
+	int use_persistent_gnts;
+
+	use_persistent_gnts = (pending_req->blkif->vbd.feature_gnt_persistent);
+
+	if (pending_req->blkif->persistent_gnt_c >=
+	    BLKIF_MAX_SEGMENTS_PER_REQUEST *
+	    BLKIF_MAX_PERSISTENT_REQUESTS_PER_DEV)
+		return -EIO;
 
+	pending_req->flag_persistent = use_persistent_gnts;
 	/*
 	 * Fill out preq.nr_sects with proper amount of sectors, and setup
 	 * assign map[..] with the PFN of the page in our domain with the
@@ -358,36 +428,97 @@ static int xen_blkbk_map(struct blkif_request *req,
 	for (i = 0; i < nseg; i++) {
 		uint32_t flags;
 
+		if (use_persistent_gnts) {
+			persistent_gnt = get_persistent_gnt(
+				pending_req->blkif,
+				req->u.rw.seg[i].gref);
+			if (!persistent_gnt) {
+				new_map = 1;
+				persistent_gnt = kmalloc(
+					sizeof(struct persistent_gnt),
+					GFP_KERNEL);
+				if (!persistent_gnt)
+					return -ENOMEM;
+				persistent_gnt->page = alloc_page(GFP_KERNEL);
+				if (!persistent_gnt->page) {
+					kfree(persistent_gnt);
+					return -ENOMEM;
+				}
+				persistent_gnt->gnt = req->u.rw.seg[i].gref;
+
+				pages_to_gnt[segs_to_map] =
+					persistent_gnt->page;
+				new_persistent_gnts[segs_to_map] =
+					persistent_gnt;
+
+				add_persistent_gnt(persistent_gnt,
+						   pending_req->blkif);
+
+			} else {
+				new_map = 0;
+			}
+			pages[i] = persistent_gnt->page;
+			addr = (unsigned long) pfn_to_kaddr(
+				page_to_pfn(persistent_gnt->page));
+			persistent_gnts[i] = persistent_gnt;
+		} else {
+			new_map = 1;
+			pages[i] = blkbk->pending_page(pending_req, i);
+			addr = vaddr(pending_req, i);
+			pages_to_gnt[i] = blkbk->pending_page(pending_req, i);
+		}
+
 		flags = GNTMAP_host_map;
-		if (pending_req->operation != BLKIF_OP_READ)
+		if (!use_persistent_gnts &&
+		    (pending_req->operation != BLKIF_OP_READ))
 			flags |= GNTMAP_readonly;
-		gnttab_set_map_op(&map[i], vaddr(pending_req, i), flags,
-				  req->u.rw.seg[i].gref,
-				  pending_req->blkif->domid);
+		if (new_map) {
+			gnttab_set_map_op(&map[segs_to_map++], addr,
+					  flags, req->u.rw.seg[i].gref,
+					  pending_req->blkif->domid);
+		}
 	}
 
-	ret = gnttab_map_refs(map, NULL, &blkbk->pending_page(pending_req, 0), nseg);
-	BUG_ON(ret);
+	if (segs_to_map) {
+		ret = gnttab_map_refs(map, NULL, pages_to_gnt, segs_to_map);
+		BUG_ON(ret);
+	}
 
 	/*
 	 * Now swizzle the MFN in our domain with the MFN from the other domain
 	 * so that when we access vaddr(pending_req,i) it has the contents of
 	 * the page from the other domain.
 	 */
-	for (i = 0; i < nseg; i++) {
+	for (i = 0; i < segs_to_map; i++) {
 		if (unlikely(map[i].status != 0)) {
 			pr_debug(DRV_PFX "invalid buffer -- could not remap it\n");
 			map[i].handle = BLKBACK_INVALID_HANDLE;
 			ret |= 1;
 		}
 
-		pending_handle(pending_req, i) = map[i].handle;
+		if (use_persistent_gnts) {
+			/* store the `out' values from map */
+		    pending_req->blkif->persistent_gnts
+			[pending_req->blkif->persistent_gnt_c - segs_to_map +
+			 i]->handle = map[i].handle;
+			new_persistent_gnts[i]->dev_bus_addr =
+				map[i].dev_bus_addr;
+		}
 
 		if (ret)
 			continue;
-
-		seg[i].buf  = map[i].dev_bus_addr |
-			(req->u.rw.seg[i].first_sect << 9);
+	}
+	for (i = 0; i < nseg; i++) {
+		if (use_persistent_gnts) {
+			pending_handle(pending_req, i) =
+				persistent_gnts[i]->handle;
+			seg[i].buf = persistent_gnts[i]->dev_bus_addr |
+				(req->u.rw.seg[i].first_sect << 9);
+		} else {
+			pending_handle(pending_req, i) = map[i].handle;
+			seg[i].buf = map[i].dev_bus_addr |
+				(req->u.rw.seg[i].first_sect << 9);
+		}
 	}
 	return ret;
 }
@@ -468,7 +599,8 @@ static void __end_block_io_op(struct pending_req *pending_req, int error)
 	 * the proper response on the ring.
 	 */
 	if (atomic_dec_and_test(&pending_req->pendcnt)) {
-		xen_blkbk_unmap(pending_req);
+		if (!pending_req->flag_persistent)
+			xen_blkbk_unmap(pending_req);
 		make_response(pending_req->blkif, pending_req->id,
 			      pending_req->operation, pending_req->status);
 		xen_blkif_put(pending_req->blkif);
@@ -590,6 +722,7 @@ static int dispatch_rw_block_io(struct xen_blkif *blkif,
 	int operation;
 	struct blk_plug plug;
 	bool drain = false;
+	struct page *pages[BLKIF_MAX_SEGMENTS_PER_REQUEST];
 
 	switch (req->operation) {
 	case BLKIF_OP_READ:
@@ -676,7 +809,7 @@ static int dispatch_rw_block_io(struct xen_blkif *blkif,
 	 * the hypercall to unmap the grants - that is all done in
 	 * xen_blkbk_unmap.
 	 */
-	if (xen_blkbk_map(req, pending_req, seg))
+	if (xen_blkbk_map(req, pending_req, seg, pages))
 		goto fail_flush;
 
 	/*
@@ -688,7 +821,7 @@ static int dispatch_rw_block_io(struct xen_blkif *blkif,
 	for (i = 0; i < nseg; i++) {
 		while ((bio == NULL) ||
 		       (bio_add_page(bio,
-				     blkbk->pending_page(pending_req, i),
+				     pages[i],
 				     seg[i].nsec << 9,
 				     seg[i].buf & ~PAGE_MASK) == 0)) {
 
@@ -743,7 +876,8 @@ static int dispatch_rw_block_io(struct xen_blkif *blkif,
 	return 0;
 
  fail_flush:
-	xen_blkbk_unmap(pending_req);
+	if (!blkif->vbd.feature_gnt_persistent)
+		xen_blkbk_unmap(pending_req);
  fail_response:
 	/* Haven't submitted any bio's yet. */
 	make_response(blkif, req->u.rw.id, req->operation, BLKIF_RSP_ERROR);
diff --git a/drivers/block/xen-blkback/common.h b/drivers/block/xen-blkback/common.h
index 9ad3b5e..0b7e049 100644
--- a/drivers/block/xen-blkback/common.h
+++ b/drivers/block/xen-blkback/common.h
@@ -160,10 +160,20 @@ struct xen_vbd {
 	sector_t		size;
 	bool			flush_support;
 	bool			discard_secure;
+
+	unsigned int		feature_gnt_persistent:1;
 };
 
 struct backend_info;
 
+
+struct persistent_gnt {
+	struct page *page;
+	grant_ref_t gnt;
+	grant_handle_t handle;
+	uint64_t dev_bus_addr;
+};
+
 struct xen_blkif {
 	/* Unique identifier for this interface. */
 	domid_t			domid;
@@ -190,6 +200,12 @@ struct xen_blkif {
 	struct task_struct	*xenblkd;
 	unsigned int		waiting_reqs;
 
+	/* frontend feature information */
+	struct persistent_gnt	*persistent_gnts
+					[BLKIF_MAX_PERSISTENT_REQUESTS_PER_DEV
+					 * BLKIF_MAX_SEGMENTS_PER_REQUEST];
+	unsigned int		persistent_gnt_c;
+
 	/* statistics */
 	unsigned long		st_print;
 	int			st_rd_req;
diff --git a/drivers/block/xen-blkback/xenbus.c b/drivers/block/xen-blkback/xenbus.c
index 4f66171..473e416 100644
--- a/drivers/block/xen-blkback/xenbus.c
+++ b/drivers/block/xen-blkback/xenbus.c
@@ -681,6 +681,13 @@ again:
 		goto abort;
 	}
 
+	err = xenbus_printf(xbt, dev->nodename, "feature-persistent-grants",
+			    "%d", 1);
+	if (err) {
+		dev_warn(&dev->dev, "writing persistent grants feature");
+		goto abort;
+	}
+
 	/* FIXME: use a typename instead */
 	err = xenbus_printf(xbt, dev->nodename, "info", "%u",
 			    be->blkif->vbd.type |
@@ -721,6 +728,7 @@ static int connect_ring(struct backend_info *be)
 	struct xenbus_device *dev = be->dev;
 	unsigned long ring_ref;
 	unsigned int evtchn;
+	u8 pers_grants;
 	char protocol[64] = "";
 	int err;
 
@@ -750,8 +758,17 @@ static int connect_ring(struct backend_info *be)
 		xenbus_dev_fatal(dev, err, "unknown fe protocol %s", protocol);
 		return -1;
 	}
-	pr_info(DRV_PFX "ring-ref %ld, event-channel %d, protocol %d (%s)\n",
-		ring_ref, evtchn, be->blkif->blk_protocol, protocol);
+	err = xenbus_gather(XBT_NIL, dev->otherend,
+			    "feature-persistent-grants", "%d",
+			    &pers_grants, NULL);
+	if (err)
+		pers_grants = 0;
+
+	be->blkif->vbd.feature_gnt_persistent = pers_grants;
+
+	pr_info(DRV_PFX "ring-ref %ld, event-channel %d, protocol %d (%s) persistent %d\n",
+		ring_ref, evtchn, be->blkif->blk_protocol, protocol,
+		pers_grants);
 
 	/* Map the shared frame, irq etc. */
 	err = xen_blkif_map(be->blkif, ring_ref, evtchn);
diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c
index 2c2d2e5..9606c5a 100644
--- a/drivers/block/xen-blkfront.c
+++ b/drivers/block/xen-blkfront.c
@@ -64,10 +64,17 @@ enum blkif_state {
 	BLKIF_STATE_SUSPENDED,
 };
 
+struct gnt_list {
+	grant_ref_t gref;
+	unsigned long pfn;
+	struct gnt_list *tail;
+};
+
 struct blk_shadow {
 	struct blkif_request req;
 	struct request *request;
 	unsigned long frame[BLKIF_MAX_SEGMENTS_PER_REQUEST];
+	struct gnt_list *grants_used[BLKIF_MAX_SEGMENTS_PER_REQUEST];
 };
 
 static DEFINE_MUTEX(blkfront_mutex);
@@ -97,11 +104,14 @@ struct blkfront_info
 	struct work_struct work;
 	struct gnttab_free_callback callback;
 	struct blk_shadow shadow[BLK_RING_SIZE];
+	struct gnt_list *persistent_gnts;
+	unsigned int persistent_gnts_c;
 	unsigned long shadow_free;
 	unsigned int feature_flush;
 	unsigned int flush_op;
 	unsigned int feature_discard:1;
 	unsigned int feature_secdiscard:1;
+	unsigned int feature_persistent:1;
 	unsigned int discard_granularity;
 	unsigned int discard_alignment;
 	int is_ready;
@@ -287,21 +297,42 @@ static int blkif_queue_request(struct request *req)
 	unsigned long id;
 	unsigned int fsect, lsect;
 	int i, ref;
+
+	/*
+	 * stores if we have negotiated with the backend, agreeing to use
+	 * persistent grants.
+	 */
+	int use_persistent_gnts;
+
+	/*
+	 * Used when doing persistent grants to store if we are able to queue
+	 * the request by just using existing persistent grants (0), or if we
+	 * have to get new grants, as there are not sufficiently many free.
+	 */
+	int new_persistent_gnts;
 	grant_ref_t gref_head;
+	struct page *granted_page;
+	struct gnt_list *gnt_list_entry;
 	struct scatterlist *sg;
 
 	if (unlikely(info->connected != BLKIF_STATE_CONNECTED))
 		return 1;
 
-	if (gnttab_alloc_grant_references(
-		BLKIF_MAX_SEGMENTS_PER_REQUEST, &gref_head) < 0) {
-		gnttab_request_free_callback(
-			&info->callback,
-			blkif_restart_queue_callback,
-			info,
-			BLKIF_MAX_SEGMENTS_PER_REQUEST);
-		return 1;
-	}
+	use_persistent_gnts = info->feature_persistent;
+
+	if (info->persistent_gnts_c < BLKIF_MAX_SEGMENTS_PER_REQUEST) {
+		new_persistent_gnts = 1;
+		if (gnttab_alloc_grant_references(
+			    BLKIF_MAX_SEGMENTS_PER_REQUEST, &gref_head) < 0) {
+			gnttab_request_free_callback(
+				&info->callback,
+				blkif_restart_queue_callback,
+				info,
+				BLKIF_MAX_SEGMENTS_PER_REQUEST);
+			return 1;
+		}
+	} else
+		new_persistent_gnts = 0;
 
 	/* Fill out a communications ring structure. */
 	ring_req = RING_GET_REQUEST(&info->ring, info->ring.req_prod_pvt);
@@ -341,20 +372,83 @@ static int blkif_queue_request(struct request *req)
 		       BLKIF_MAX_SEGMENTS_PER_REQUEST);
 
 		for_each_sg(info->sg, sg, ring_req->u.rw.nr_segments, i) {
-			buffer_mfn = pfn_to_mfn(page_to_pfn(sg_page(sg)));
 			fsect = sg->offset >> 9;
 			lsect = fsect + (sg->length >> 9) - 1;
-			/* install a grant reference. */
-			ref = gnttab_claim_grant_reference(&gref_head);
-			BUG_ON(ref == -ENOSPC);
 
-			gnttab_grant_foreign_access_ref(
+			if (use_persistent_gnts && info->persistent_gnts_c) {
+				gnt_list_entry = info->persistent_gnts;
+
+				info->persistent_gnts = info->persistent_gnts->
+					tail;
+				ref = gnt_list_entry->gref;
+				buffer_mfn = pfn_to_mfn(gnt_list_entry->pfn);
+				info->persistent_gnts_c--;
+			} else {
+				ref = gnttab_claim_grant_reference(&gref_head);
+				BUG_ON(ref == -ENOSPC);
+
+				if (use_persistent_gnts) {
+					gnt_list_entry =
+						kmalloc(sizeof(struct gnt_list),
+								 GFP_ATOMIC);
+					if (!gnt_list_entry)
+						return -ENOMEM;
+
+					granted_page = alloc_page(GFP_ATOMIC);
+					if (!granted_page) {
+						kfree(gnt_list_entry);
+						return -ENOMEM;
+					}
+
+					gnt_list_entry->pfn =
+						page_to_pfn(granted_page);
+					gnt_list_entry->gref = ref;
+				} else
+					granted_page = sg_page(sg);
+
+				buffer_mfn = pfn_to_mfn(page_to_pfn(
+								granted_page));
+				gnttab_grant_foreign_access_ref(
 					ref,
 					info->xbdev->otherend_id,
 					buffer_mfn,
+					!use_persistent_gnts &&
 					rq_data_dir(req));
+			}
+
+			if (use_persistent_gnts)
+				info->shadow[id].grants_used[i] =
+					gnt_list_entry;
+
+			if (use_persistent_gnts && rq_data_dir(req)) {
+				char *bvec_data;
+				void *shared_data;
+
+				BUG_ON(sg->offset + sg->length > PAGE_SIZE);
+
+				shared_data = kmap_atomic(
+					pfn_to_page(gnt_list_entry->pfn));
+				bvec_data = kmap_atomic(sg_page(sg));
+
+				/*
+				 * this does not wipe data stored outside the
+				 * range sg->offset..sg->offset+sg->length.
+				 * Therefore, blkback *could* see data from
+				 * previous requests. This is OK as long as
+				 * persistent grants are shared with just one
+				 * domain. It may need refactoring if This
+				 * changes
+				 */
+				memcpy(shared_data + sg->offset,
+				       bvec_data   + sg->offset,
+				       sg->length);
+
+				kunmap_atomic(bvec_data);
+				kunmap_atomic(shared_data);
+			}
 
 			info->shadow[id].frame[i] = mfn_to_pfn(buffer_mfn);
+
 			ring_req->u.rw.seg[i] =
 					(struct blkif_request_segment) {
 						.gref       = ref,
@@ -368,7 +462,8 @@ static int blkif_queue_request(struct request *req)
 	/* Keep a private copy so we can reissue requests when recovering. */
 	info->shadow[id].req = *ring_req;
 
-	gnttab_free_grant_references(gref_head);
+	if (new_persistent_gnts)
+		gnttab_free_grant_references(gref_head);
 
 	return 0;
 }
@@ -480,12 +575,13 @@ static int xlvbd_init_blk_queue(struct gendisk *gd, u16 sector_size)
 static void xlvbd_flush(struct blkfront_info *info)
 {
 	blk_queue_flush(info->rq, info->feature_flush);
-	printk(KERN_INFO "blkfront: %s: %s: %s\n",
+	printk(KERN_INFO "blkfront: %s: %s: %s %s\n",
 	       info->gd->disk_name,
 	       info->flush_op == BLKIF_OP_WRITE_BARRIER ?
 		"barrier" : (info->flush_op == BLKIF_OP_FLUSH_DISKCACHE ?
 		"flush diskcache" : "barrier or flush"),
-	       info->feature_flush ? "enabled" : "disabled");
+	       info->feature_flush ? "enabled" : "disabled",
+	       info->feature_persistent ? "persistent" : "non-persistent");
 }
 
 static int xen_translate_vdev(int vdevice, int *minor, unsigned int *offset)
@@ -707,6 +803,8 @@ static void blkif_restart_queue(struct work_struct *work)
 
 static void blkif_free(struct blkfront_info *info, int suspend)
 {
+	struct gnt_list *persistent_gnt;
+
 	/* Prevent new requests being issued until we fix things up. */
 	spin_lock_irq(&info->io_lock);
 	info->connected = suspend ?
@@ -714,6 +812,15 @@ static void blkif_free(struct blkfront_info *info, int suspend)
 	/* No more blkif_request(). */
 	if (info->rq)
 		blk_stop_queue(info->rq);
+
+	/* Remove all persistent grants */
+	while (info->persistent_gnts) {
+		persistent_gnt = info->persistent_gnts;
+		info->persistent_gnts = persistent_gnt->tail;
+		gnttab_end_foreign_access(persistent_gnt->gref, 0, 0UL);
+		kfree(persistent_gnt);
+	}
+
 	/* No more gnttab callback work. */
 	gnttab_cancel_free_callback(&info->callback);
 	spin_unlock_irq(&info->io_lock);
@@ -734,13 +841,47 @@ static void blkif_free(struct blkfront_info *info, int suspend)
 
 }
 
-static void blkif_completion(struct blk_shadow *s)
+static void blkif_completion(struct blk_shadow *s, struct blkfront_info *info,
+			     struct blkif_response *bret)
 {
 	int i;
-	/* Do not let BLKIF_OP_DISCARD as nr_segment is in the same place
-	 * flag. */
-	for (i = 0; i < s->req.u.rw.nr_segments; i++)
-		gnttab_end_foreign_access(s->req.u.rw.seg[i].gref, 0, 0UL);
+	struct gnt_list *new_gnt_list_entry;
+	struct bio_vec *bvec;
+	struct req_iterator iter;
+	unsigned long flags;
+	char *bvec_data;
+	void *shared_data;
+
+
+	if (info->feature_persistent == 0) {
+		/* Do not let BLKIF_OP_DISCARD as nr_segment is in the same
+		 * place flag. */
+		for (i = 0; i < s->req.u.rw.nr_segments; i++)
+			gnttab_end_foreign_access(s->req.u.rw.seg[i].gref,
+						  0, 0UL);
+		return;
+	}
+
+	i = 0;
+	if (bret->operation == BLKIF_OP_READ)
+		rq_for_each_segment(bvec, s->request, iter) {
+			BUG_ON(bvec->bv_offset + bvec->bv_len > PAGE_SIZE);
+
+			shared_data = kmap_atomic
+				(pfn_to_page(s->grants_used[i++]->pfn));
+			bvec_data = bvec_kmap_irq(bvec, &flags);
+			memcpy(bvec_data, shared_data + bvec->bv_offset,
+			       bvec->bv_len);
+			bvec_kunmap_irq(bvec_data, &flags);
+			kunmap_atomic(shared_data);
+		}
+	/* Add the persistent grant into the list of free grants */
+	for (i = 0; i < s->req.u.rw.nr_segments; i++) {
+		new_gnt_list_entry = s->grants_used[i];
+		new_gnt_list_entry->tail = info->persistent_gnts;
+		info->persistent_gnts = new_gnt_list_entry;
+		info->persistent_gnts_c++;
+	}
 }
 
 static irqreturn_t blkif_interrupt(int irq, void *dev_id)
@@ -783,7 +924,7 @@ static irqreturn_t blkif_interrupt(int irq, void *dev_id)
 		req  = info->shadow[id].request;
 
 		if (bret->operation != BLKIF_OP_DISCARD)
-			blkif_completion(&info->shadow[id]);
+			blkif_completion(&info->shadow[id], info, bret);
 
 		if (add_id_to_freelist(info, id)) {
 			WARN(1, "%s: response to %s (id %ld) couldn't be recycled!\n",
@@ -942,6 +1083,13 @@ again:
 		message = "writing protocol";
 		goto abort_transaction;
 	}
+	err = xenbus_printf(xbt, dev->nodename,
+			    "feature-persistent-grants", "%d", 1);
+	if (err) {
+		dev_warn(&dev->dev,
+			 "writing persistent grants feature to xenbus");
+		info->feature_persistent = 0;
+	}
 
 	err = xenbus_transaction_end(xbt, 0);
 	if (err) {
@@ -1029,6 +1177,7 @@ static int blkfront_probe(struct xenbus_device *dev,
 	spin_lock_init(&info->io_lock);
 	info->xbdev = dev;
 	info->vdevice = vdevice;
+	info->persistent_gnts_c = 0;
 	info->connected = BLKIF_STATE_DISCONNECTED;
 	INIT_WORK(&info->work, blkif_restart_queue);
 
@@ -1093,6 +1242,7 @@ static int blkif_recover(struct blkfront_info *info)
 					req->u.rw.seg[j].gref,
 					info->xbdev->otherend_id,
 					pfn_to_mfn(info->shadow[req->u.rw.id].frame[j]),
+					!info->feature_persistent &&
 					rq_data_dir(info->shadow[req->u.rw.id].request));
 		}
 		info->shadow[req->u.rw.id].req = *req;
@@ -1225,7 +1375,7 @@ static void blkfront_connect(struct blkfront_info *info)
 	unsigned long sector_size;
 	unsigned int binfo;
 	int err;
-	int barrier, flush, discard;
+	int barrier, flush, discard, persistent;
 
 	switch (info->connected) {
 	case BLKIF_STATE_CONNECTED:
@@ -1296,6 +1446,19 @@ static void blkfront_connect(struct blkfront_info *info)
 		info->flush_op = BLKIF_OP_FLUSH_DISKCACHE;
 	}
 
+	/*
+	 * Are we dealing with an old blkback that will unmap
+	 * all grefs?
+	 */
+	err = xenbus_gather(XBT_NIL, info->xbdev->otherend,
+			    "feature-persistent-grants", "%d", &persistent,
+			    NULL);
+
+	if (err)
+		info->feature_persistent = 0;
+	else
+		info->feature_persistent = persistent;
+
 	err = xenbus_gather(XBT_NIL, info->xbdev->otherend,
 			    "feature-discard", "%d", &discard,
 			    NULL);
diff --git a/include/xen/interface/io/blkif.h b/include/xen/interface/io/blkif.h
index ee338bf..9048df1 100644
--- a/include/xen/interface/io/blkif.h
+++ b/include/xen/interface/io/blkif.h
@@ -109,6 +109,19 @@ typedef uint64_t blkif_sector_t;
  */
 #define BLKIF_MAX_SEGMENTS_PER_REQUEST 11
 
+/*
+ * Maximum number of inflight requests that can be sent by from
+ * blkfront, and will be guaranteed to be persistently mapped.
+ * BLKIF_MAX_SEGMENTS_PER_REQUEST *
+ * BLKIF_MAX_PERSISTENT_REQUESTS_PER_DEV is the maximum number of
+ * pages that blkback will persistently map. This is set to be the size
+ * of the ring, as this is a limit on the number of requests that can
+ * be inflight at any one time. 64 imposes an overhead of 2.75MB of
+ * mapped kernel space per interface.
+ */
+#define BLKIF_MAX_PERSISTENT_REQUESTS_PER_DEV 64
+
+
 struct blkif_request_rw {
 	uint8_t        nr_segments;  /* number of segments                   */
 	blkif_vdev_t   handle;       /* only for read/write requests         */
-- 
1.7.9.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 21 16:05:37 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Sep 2012 16:05: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 1TF5jI-0002rz-RK; Fri, 21 Sep 2012 16:05:24 +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 1TF5jH-0002rS-SA
	for xen-devel@lists.xensource.com; Fri, 21 Sep 2012 16:05:24 +0000
Received: from [85.158.139.211:36848] by server-12.bemta-5.messagelabs.com id
	E5/36-22670-3409C505; Fri, 21 Sep 2012 16:05:23 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-6.tower-206.messagelabs.com!1348243518!19492455!4
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzAyMzY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24020 invoked from network); 21 Sep 2012 16:05:22 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-6.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Sep 2012 16:05:22 -0000
X-IronPort-AV: E=Sophos;i="4.80,463,1344211200"; d="scan'208";a="38744204"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Sep 2012 16:04:52 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1;
	Fri, 21 Sep 2012 12:04:51 -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 1TF5il-0008Al-Fo;
	Fri, 21 Sep 2012 17:04:51 +0100
From: David Vrabel <david.vrabel@citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 21 Sep 2012 17:04:24 +0100
Message-ID: <1348243464-15903-7-git-send-email-david.vrabel@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1348243464-15903-1-git-send-email-david.vrabel@citrix.com>
References: <1348243464-15903-1-git-send-email-david.vrabel@citrix.com>
MIME-Version: 1.0
Cc: linux-kernel@vger.kernel.org, David Vrabel <david.vrabel@citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: [Xen-devel] [PATCH 6/6] xen/hvc: handle backend CLOSED without
	CLOSING
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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>

Backend drivers shouldn't transistion to CLOSED unless the frontend is
CLOSED.  If a backend does transition to CLOSED too soon then the
frontend may not see the CLOSING state and will not properly shutdown.

So, treat an unexpected backend CLOSED state the same as CLOSING.

Signed-off-by: David Vrabel <david.vrabel@citrix.com>
---
 drivers/tty/hvc/hvc_xen.c |    5 ++++-
 1 files changed, 4 insertions(+), 1 deletions(-)

diff --git a/drivers/tty/hvc/hvc_xen.c b/drivers/tty/hvc/hvc_xen.c
index 1e456dc..82901fb 100644
--- a/drivers/tty/hvc/hvc_xen.c
+++ b/drivers/tty/hvc/hvc_xen.c
@@ -476,7 +476,6 @@ static void xencons_backend_changed(struct xenbus_device *dev,
 	case XenbusStateInitialising:
 	case XenbusStateInitialised:
 	case XenbusStateUnknown:
-	case XenbusStateClosed:
 		break;
 
 	case XenbusStateInitWait:
@@ -486,6 +485,10 @@ static void xencons_backend_changed(struct xenbus_device *dev,
 		xenbus_switch_state(dev, XenbusStateConnected);
 		break;
 
+	case XenbusStateClosed:
+		if (dev->state == XenbusStateClosed)
+			break;
+		/* Missed the backend's CLOSING state -- fallthrough */
 	case XenbusStateClosing:
 		xenbus_frontend_closed(dev);
 		break;
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 21 16:05:37 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Sep 2012 16:05: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 1TF5jI-0002rz-RK; Fri, 21 Sep 2012 16:05:24 +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 1TF5jH-0002rS-SA
	for xen-devel@lists.xensource.com; Fri, 21 Sep 2012 16:05:24 +0000
Received: from [85.158.139.211:36848] by server-12.bemta-5.messagelabs.com id
	E5/36-22670-3409C505; Fri, 21 Sep 2012 16:05:23 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-6.tower-206.messagelabs.com!1348243518!19492455!4
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzAyMzY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24020 invoked from network); 21 Sep 2012 16:05:22 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-6.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Sep 2012 16:05:22 -0000
X-IronPort-AV: E=Sophos;i="4.80,463,1344211200"; d="scan'208";a="38744204"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Sep 2012 16:04:52 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1;
	Fri, 21 Sep 2012 12:04:51 -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 1TF5il-0008Al-Fo;
	Fri, 21 Sep 2012 17:04:51 +0100
From: David Vrabel <david.vrabel@citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 21 Sep 2012 17:04:24 +0100
Message-ID: <1348243464-15903-7-git-send-email-david.vrabel@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1348243464-15903-1-git-send-email-david.vrabel@citrix.com>
References: <1348243464-15903-1-git-send-email-david.vrabel@citrix.com>
MIME-Version: 1.0
Cc: linux-kernel@vger.kernel.org, David Vrabel <david.vrabel@citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: [Xen-devel] [PATCH 6/6] xen/hvc: handle backend CLOSED without
	CLOSING
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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>

Backend drivers shouldn't transistion to CLOSED unless the frontend is
CLOSED.  If a backend does transition to CLOSED too soon then the
frontend may not see the CLOSING state and will not properly shutdown.

So, treat an unexpected backend CLOSED state the same as CLOSING.

Signed-off-by: David Vrabel <david.vrabel@citrix.com>
---
 drivers/tty/hvc/hvc_xen.c |    5 ++++-
 1 files changed, 4 insertions(+), 1 deletions(-)

diff --git a/drivers/tty/hvc/hvc_xen.c b/drivers/tty/hvc/hvc_xen.c
index 1e456dc..82901fb 100644
--- a/drivers/tty/hvc/hvc_xen.c
+++ b/drivers/tty/hvc/hvc_xen.c
@@ -476,7 +476,6 @@ static void xencons_backend_changed(struct xenbus_device *dev,
 	case XenbusStateInitialising:
 	case XenbusStateInitialised:
 	case XenbusStateUnknown:
-	case XenbusStateClosed:
 		break;
 
 	case XenbusStateInitWait:
@@ -486,6 +485,10 @@ static void xencons_backend_changed(struct xenbus_device *dev,
 		xenbus_switch_state(dev, XenbusStateConnected);
 		break;
 
+	case XenbusStateClosed:
+		if (dev->state == XenbusStateClosed)
+			break;
+		/* Missed the backend's CLOSING state -- fallthrough */
 	case XenbusStateClosing:
 		xenbus_frontend_closed(dev);
 		break;
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 21 16:05:37 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Sep 2012 16:05: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 1TF5jG-0002rI-JQ; Fri, 21 Sep 2012 16:05:22 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1TF5jF-0002r7-Ef
	for xen-devel@lists.xensource.com; Fri, 21 Sep 2012 16:05:21 +0000
Received: from [85.158.139.211:55147] by server-11.bemta-5.messagelabs.com id
	BA/50-24658-0409C505; Fri, 21 Sep 2012 16:05:20 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-6.tower-206.messagelabs.com!1348243518!19492455!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzAyMzY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23872 invoked from network); 21 Sep 2012 16:05:20 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-6.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Sep 2012 16:05:20 -0000
X-IronPort-AV: E=Sophos;i="4.80,463,1344211200"; d="scan'208";a="38744194"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Sep 2012 16:04:49 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1;
	Fri, 21 Sep 2012 12:04:48 -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 1TF5ii-0008Al-FO;
	Fri, 21 Sep 2012 17:04:48 +0100
From: David Vrabel <david.vrabel@citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 21 Sep 2012 17:04:18 +0100
Message-ID: <1348243464-15903-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, David Vrabel <david.vrabel@citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: [Xen-devel] [PATCH 0/6] xen: frontend devices should handle missed
	backend CLOSING
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

The series makes all the Xen frontend drivers handle the backend
transitioning to CLOSED without the frontend having previously seen
the backend in the CLOSING state.

Backends shouldn't do this but some do.  e.g., if the host is
XenServer and the toolstack decides to do a forced shutdown of a VBD,
then the blkfront may miss the CLOSING transition and the /dev/xvdX
device will not be destroyed which prevents it being reused.

I have seen systems that ended up in this state but it's not clear if
this was the actual cause.  However, I think in general it's a good
thing to thing to improve the handling of unexpected state
transitions.

Konrad, I've split this into a patch per frontend in case each patch
should go via a different maintainer.  But if you'd prefer, I can roll
this up into one patch to via your Xen tree.

David


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 21 16:05:37 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Sep 2012 16:05: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 1TF5jG-0002rI-JQ; Fri, 21 Sep 2012 16:05:22 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1TF5jF-0002r7-Ef
	for xen-devel@lists.xensource.com; Fri, 21 Sep 2012 16:05:21 +0000
Received: from [85.158.139.211:55147] by server-11.bemta-5.messagelabs.com id
	BA/50-24658-0409C505; Fri, 21 Sep 2012 16:05:20 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-6.tower-206.messagelabs.com!1348243518!19492455!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzAyMzY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23872 invoked from network); 21 Sep 2012 16:05:20 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-6.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Sep 2012 16:05:20 -0000
X-IronPort-AV: E=Sophos;i="4.80,463,1344211200"; d="scan'208";a="38744194"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Sep 2012 16:04:49 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1;
	Fri, 21 Sep 2012 12:04:48 -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 1TF5ii-0008Al-FO;
	Fri, 21 Sep 2012 17:04:48 +0100
From: David Vrabel <david.vrabel@citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 21 Sep 2012 17:04:18 +0100
Message-ID: <1348243464-15903-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, David Vrabel <david.vrabel@citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: [Xen-devel] [PATCH 0/6] xen: frontend devices should handle missed
	backend CLOSING
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

The series makes all the Xen frontend drivers handle the backend
transitioning to CLOSED without the frontend having previously seen
the backend in the CLOSING state.

Backends shouldn't do this but some do.  e.g., if the host is
XenServer and the toolstack decides to do a forced shutdown of a VBD,
then the blkfront may miss the CLOSING transition and the /dev/xvdX
device will not be destroyed which prevents it being reused.

I have seen systems that ended up in this state but it's not clear if
this was the actual cause.  However, I think in general it's a good
thing to thing to improve the handling of unexpected state
transitions.

Konrad, I've split this into a patch per frontend in case each patch
should go via a different maintainer.  But if you'd prefer, I can roll
this up into one patch to via your Xen tree.

David


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 21 16:05:37 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Sep 2012 16:05: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 1TF5jI-0002rn-Ej; Fri, 21 Sep 2012 16:05:24 +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 1TF5jH-0002rN-6l
	for xen-devel@lists.xensource.com; Fri, 21 Sep 2012 16:05:23 +0000
Received: from [85.158.139.211:36808] by server-16.bemta-5.messagelabs.com id
	D0/78-11718-2409C505; Fri, 21 Sep 2012 16:05:22 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-6.tower-206.messagelabs.com!1348243518!19492455!3
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzAyMzY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23969 invoked from network); 21 Sep 2012 16:05:21 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-6.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Sep 2012 16:05:21 -0000
X-IronPort-AV: E=Sophos;i="4.80,463,1344211200"; d="scan'208";a="38744202"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Sep 2012 16:04:52 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1;
	Fri, 21 Sep 2012 12:04:51 -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 1TF5il-0008Al-Dm;
	Fri, 21 Sep 2012 17:04:51 +0100
From: David Vrabel <david.vrabel@citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 21 Sep 2012 17:04:20 +0100
Message-ID: <1348243464-15903-3-git-send-email-david.vrabel@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1348243464-15903-1-git-send-email-david.vrabel@citrix.com>
References: <1348243464-15903-1-git-send-email-david.vrabel@citrix.com>
MIME-Version: 1.0
Cc: linux-kernel@vger.kernel.org, David Vrabel <david.vrabel@citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: [Xen-devel] [PATCH 2/6] xen-blkfront: handle backend CLOSED without
	CLOSING
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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>

Backend drivers shouldn't transistion to CLOSED unless the frontend is
CLOSED.  If a backend does transition to CLOSED too soon then the
frontend may not see the CLOSING state and will not properly shutdown.

So, treat an unexpected backend CLOSED state the same as CLOSING.

Signed-off-by: David Vrabel <david.vrabel@citrix.com>
---
 drivers/block/xen-blkfront.c |    5 ++++-
 1 files changed, 4 insertions(+), 1 deletions(-)

diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c
index 2c2d2e5..8da12a9 100644
--- a/drivers/block/xen-blkfront.c
+++ b/drivers/block/xen-blkfront.c
@@ -1340,13 +1340,16 @@ static void blkback_changed(struct xenbus_device *dev,
 	case XenbusStateReconfiguring:
 	case XenbusStateReconfigured:
 	case XenbusStateUnknown:
-	case XenbusStateClosed:
 		break;
 
 	case XenbusStateConnected:
 		blkfront_connect(info);
 		break;
 
+	case XenbusStateClosed:
+		if (dev->state == XenbusStateClosed)
+			break;
+		/* Missed the backend's Closing state -- fallthrough */
 	case XenbusStateClosing:
 		blkfront_closing(info);
 		break;
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 21 16:05:37 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Sep 2012 16:05: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 1TF5jI-0002rn-Ej; Fri, 21 Sep 2012 16:05:24 +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 1TF5jH-0002rN-6l
	for xen-devel@lists.xensource.com; Fri, 21 Sep 2012 16:05:23 +0000
Received: from [85.158.139.211:36808] by server-16.bemta-5.messagelabs.com id
	D0/78-11718-2409C505; Fri, 21 Sep 2012 16:05:22 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-6.tower-206.messagelabs.com!1348243518!19492455!3
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzAyMzY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23969 invoked from network); 21 Sep 2012 16:05:21 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-6.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Sep 2012 16:05:21 -0000
X-IronPort-AV: E=Sophos;i="4.80,463,1344211200"; d="scan'208";a="38744202"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Sep 2012 16:04:52 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1;
	Fri, 21 Sep 2012 12:04:51 -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 1TF5il-0008Al-Dm;
	Fri, 21 Sep 2012 17:04:51 +0100
From: David Vrabel <david.vrabel@citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 21 Sep 2012 17:04:20 +0100
Message-ID: <1348243464-15903-3-git-send-email-david.vrabel@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1348243464-15903-1-git-send-email-david.vrabel@citrix.com>
References: <1348243464-15903-1-git-send-email-david.vrabel@citrix.com>
MIME-Version: 1.0
Cc: linux-kernel@vger.kernel.org, David Vrabel <david.vrabel@citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: [Xen-devel] [PATCH 2/6] xen-blkfront: handle backend CLOSED without
	CLOSING
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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>

Backend drivers shouldn't transistion to CLOSED unless the frontend is
CLOSED.  If a backend does transition to CLOSED too soon then the
frontend may not see the CLOSING state and will not properly shutdown.

So, treat an unexpected backend CLOSED state the same as CLOSING.

Signed-off-by: David Vrabel <david.vrabel@citrix.com>
---
 drivers/block/xen-blkfront.c |    5 ++++-
 1 files changed, 4 insertions(+), 1 deletions(-)

diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c
index 2c2d2e5..8da12a9 100644
--- a/drivers/block/xen-blkfront.c
+++ b/drivers/block/xen-blkfront.c
@@ -1340,13 +1340,16 @@ static void blkback_changed(struct xenbus_device *dev,
 	case XenbusStateReconfiguring:
 	case XenbusStateReconfigured:
 	case XenbusStateUnknown:
-	case XenbusStateClosed:
 		break;
 
 	case XenbusStateConnected:
 		blkfront_connect(info);
 		break;
 
+	case XenbusStateClosed:
+		if (dev->state == XenbusStateClosed)
+			break;
+		/* Missed the backend's Closing state -- fallthrough */
 	case XenbusStateClosing:
 		blkfront_closing(info);
 		break;
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 21 16:05:37 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Sep 2012 16:05: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 1TF5jK-0002sT-A2; Fri, 21 Sep 2012 16:05:26 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1TF5jI-0002rj-Ot
	for xen-devel@lists.xensource.com; Fri, 21 Sep 2012 16:05:24 +0000
Received: from [85.158.139.211:36887] by server-3.bemta-5.messagelabs.com id
	8E/A8-21836-3409C505; Fri, 21 Sep 2012 16:05:23 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-6.tower-206.messagelabs.com!1348243518!19492455!5
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzAyMzY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24036 invoked from network); 21 Sep 2012 16:05:23 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-6.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Sep 2012 16:05:23 -0000
X-IronPort-AV: E=Sophos;i="4.80,463,1344211200"; d="scan'208";a="38744206"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Sep 2012 16:04:52 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1;
	Fri, 21 Sep 2012 12:04:51 -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 1TF5il-0008Al-DG;
	Fri, 21 Sep 2012 17:04:51 +0100
From: David Vrabel <david.vrabel@citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 21 Sep 2012 17:04:19 +0100
Message-ID: <1348243464-15903-2-git-send-email-david.vrabel@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1348243464-15903-1-git-send-email-david.vrabel@citrix.com>
References: <1348243464-15903-1-git-send-email-david.vrabel@citrix.com>
MIME-Version: 1.0
Cc: linux-kernel@vger.kernel.org, Ian Campbell <ian.campbell@citrix.com>,
	netdev@vger.kernel.org, David Vrabel <david.vrabel@citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: [Xen-devel] [PATCH 1/6] xen-netfront: handle backend CLOSED without
	CLOSING
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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>

Backend drivers shouldn't transistion to CLOSED unless the frontend is
CLOSED.  If a backend does transition to CLOSED too soon then the
frontend may not see the CLOSING state and will not properly shutdown.

So, treat an unexpected backend CLOSED state the same as CLOSING.

Signed-off-by: David Vrabel <david.vrabel@citrix.com>
Cc: Ian Campbell <ian.campbell@citrix.com>
Cc: <netdev@vger.kernel.org>
---
 drivers/net/xen-netfront.c |    5 ++++-
 1 files changed, 4 insertions(+), 1 deletions(-)

diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c
index 3089990..843533a 100644
--- a/drivers/net/xen-netfront.c
+++ b/drivers/net/xen-netfront.c
@@ -1719,7 +1719,6 @@ static void netback_changed(struct xenbus_device *dev,
 	case XenbusStateReconfiguring:
 	case XenbusStateReconfigured:
 	case XenbusStateUnknown:
-	case XenbusStateClosed:
 		break;
 
 	case XenbusStateInitWait:
@@ -1734,6 +1733,10 @@ static void netback_changed(struct xenbus_device *dev,
 		netif_notify_peers(netdev);
 		break;
 
+	case XenbusStateClosed:
+		if (dev->state == XenbusStateClosed)
+			break;
+		/* Missed the backend's CLOSING state -- fallthrough */
 	case XenbusStateClosing:
 		xenbus_frontend_closed(dev);
 		break;
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 21 16:05:37 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Sep 2012 16:05: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 1TF5jK-0002sT-A2; Fri, 21 Sep 2012 16:05:26 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1TF5jI-0002rj-Ot
	for xen-devel@lists.xensource.com; Fri, 21 Sep 2012 16:05:24 +0000
Received: from [85.158.139.211:36887] by server-3.bemta-5.messagelabs.com id
	8E/A8-21836-3409C505; Fri, 21 Sep 2012 16:05:23 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-6.tower-206.messagelabs.com!1348243518!19492455!5
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzAyMzY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24036 invoked from network); 21 Sep 2012 16:05:23 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-6.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Sep 2012 16:05:23 -0000
X-IronPort-AV: E=Sophos;i="4.80,463,1344211200"; d="scan'208";a="38744206"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Sep 2012 16:04:52 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1;
	Fri, 21 Sep 2012 12:04:51 -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 1TF5il-0008Al-DG;
	Fri, 21 Sep 2012 17:04:51 +0100
From: David Vrabel <david.vrabel@citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 21 Sep 2012 17:04:19 +0100
Message-ID: <1348243464-15903-2-git-send-email-david.vrabel@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1348243464-15903-1-git-send-email-david.vrabel@citrix.com>
References: <1348243464-15903-1-git-send-email-david.vrabel@citrix.com>
MIME-Version: 1.0
Cc: linux-kernel@vger.kernel.org, Ian Campbell <ian.campbell@citrix.com>,
	netdev@vger.kernel.org, David Vrabel <david.vrabel@citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: [Xen-devel] [PATCH 1/6] xen-netfront: handle backend CLOSED without
	CLOSING
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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>

Backend drivers shouldn't transistion to CLOSED unless the frontend is
CLOSED.  If a backend does transition to CLOSED too soon then the
frontend may not see the CLOSING state and will not properly shutdown.

So, treat an unexpected backend CLOSED state the same as CLOSING.

Signed-off-by: David Vrabel <david.vrabel@citrix.com>
Cc: Ian Campbell <ian.campbell@citrix.com>
Cc: <netdev@vger.kernel.org>
---
 drivers/net/xen-netfront.c |    5 ++++-
 1 files changed, 4 insertions(+), 1 deletions(-)

diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c
index 3089990..843533a 100644
--- a/drivers/net/xen-netfront.c
+++ b/drivers/net/xen-netfront.c
@@ -1719,7 +1719,6 @@ static void netback_changed(struct xenbus_device *dev,
 	case XenbusStateReconfiguring:
 	case XenbusStateReconfigured:
 	case XenbusStateUnknown:
-	case XenbusStateClosed:
 		break;
 
 	case XenbusStateInitWait:
@@ -1734,6 +1733,10 @@ static void netback_changed(struct xenbus_device *dev,
 		netif_notify_peers(netdev);
 		break;
 
+	case XenbusStateClosed:
+		if (dev->state == XenbusStateClosed)
+			break;
+		/* Missed the backend's CLOSING state -- fallthrough */
 	case XenbusStateClosing:
 		xenbus_frontend_closed(dev);
 		break;
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 21 16:05:37 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Sep 2012 16:05: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 1TF5jH-0002ra-Vx; Fri, 21 Sep 2012 16:05:23 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1TF5jG-0002rD-7C
	for xen-devel@lists.xensource.com; Fri, 21 Sep 2012 16:05:22 +0000
Received: from [85.158.139.211:10137] by server-13.bemta-5.messagelabs.com id
	78/EA-23645-1409C505; Fri, 21 Sep 2012 16:05:21 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-6.tower-206.messagelabs.com!1348243518!19492455!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzAyMzY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23930 invoked from network); 21 Sep 2012 16:05:20 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-6.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Sep 2012 16:05:20 -0000
X-IronPort-AV: E=Sophos;i="4.80,463,1344211200"; d="scan'208";a="38744201"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Sep 2012 16:04:52 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1;
	Fri, 21 Sep 2012 12:04:51 -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 1TF5il-0008Al-FK;
	Fri, 21 Sep 2012 17:04:51 +0100
From: David Vrabel <david.vrabel@citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 21 Sep 2012 17:04:23 +0100
Message-ID: <1348243464-15903-6-git-send-email-david.vrabel@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1348243464-15903-1-git-send-email-david.vrabel@citrix.com>
References: <1348243464-15903-1-git-send-email-david.vrabel@citrix.com>
MIME-Version: 1.0
Cc: linux-kernel@vger.kernel.org, linux-input@vger.kernel.org,
	David Vrabel <david.vrabel@citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: [Xen-devel] [PATCH 5/6] xen-kbdfront: handle backend CLOSED without
	CLOSING
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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>

Backend drivers shouldn't transistion to CLOSED unless the frontend is
CLOSED.  If a backend does transition to CLOSED too soon then the
frontend may not see the CLOSING state and will not properly shutdown.

So, treat an unexpected backend CLOSED state the same as CLOSING.

Signed-off-by: David Vrabel <david.vrabel@citrix.com>
Cc: <linux-input@vger.kernel.org>
---
 drivers/input/misc/xen-kbdfront.c |    5 ++++-
 1 files changed, 4 insertions(+), 1 deletions(-)

diff --git a/drivers/input/misc/xen-kbdfront.c b/drivers/input/misc/xen-kbdfront.c
index 02ca868..6f7d990 100644
--- a/drivers/input/misc/xen-kbdfront.c
+++ b/drivers/input/misc/xen-kbdfront.c
@@ -311,7 +311,6 @@ static void xenkbd_backend_changed(struct xenbus_device *dev,
 	case XenbusStateReconfiguring:
 	case XenbusStateReconfigured:
 	case XenbusStateUnknown:
-	case XenbusStateClosed:
 		break;
 
 	case XenbusStateInitWait:
@@ -350,6 +349,10 @@ InitWait:
 
 		break;
 
+	case XenbusStateClosed:
+		if (dev->state == XenbusStateClosed)
+			break;
+		/* Missed the backend's CLOSING state -- fallthrough */
 	case XenbusStateClosing:
 		xenbus_frontend_closed(dev);
 		break;
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 21 16:05:37 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Sep 2012 16:05: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 1TF5jH-0002ra-Vx; Fri, 21 Sep 2012 16:05:23 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1TF5jG-0002rD-7C
	for xen-devel@lists.xensource.com; Fri, 21 Sep 2012 16:05:22 +0000
Received: from [85.158.139.211:10137] by server-13.bemta-5.messagelabs.com id
	78/EA-23645-1409C505; Fri, 21 Sep 2012 16:05:21 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-6.tower-206.messagelabs.com!1348243518!19492455!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzAyMzY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23930 invoked from network); 21 Sep 2012 16:05:20 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-6.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Sep 2012 16:05:20 -0000
X-IronPort-AV: E=Sophos;i="4.80,463,1344211200"; d="scan'208";a="38744201"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Sep 2012 16:04:52 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1;
	Fri, 21 Sep 2012 12:04:51 -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 1TF5il-0008Al-FK;
	Fri, 21 Sep 2012 17:04:51 +0100
From: David Vrabel <david.vrabel@citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 21 Sep 2012 17:04:23 +0100
Message-ID: <1348243464-15903-6-git-send-email-david.vrabel@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1348243464-15903-1-git-send-email-david.vrabel@citrix.com>
References: <1348243464-15903-1-git-send-email-david.vrabel@citrix.com>
MIME-Version: 1.0
Cc: linux-kernel@vger.kernel.org, linux-input@vger.kernel.org,
	David Vrabel <david.vrabel@citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: [Xen-devel] [PATCH 5/6] xen-kbdfront: handle backend CLOSED without
	CLOSING
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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>

Backend drivers shouldn't transistion to CLOSED unless the frontend is
CLOSED.  If a backend does transition to CLOSED too soon then the
frontend may not see the CLOSING state and will not properly shutdown.

So, treat an unexpected backend CLOSED state the same as CLOSING.

Signed-off-by: David Vrabel <david.vrabel@citrix.com>
Cc: <linux-input@vger.kernel.org>
---
 drivers/input/misc/xen-kbdfront.c |    5 ++++-
 1 files changed, 4 insertions(+), 1 deletions(-)

diff --git a/drivers/input/misc/xen-kbdfront.c b/drivers/input/misc/xen-kbdfront.c
index 02ca868..6f7d990 100644
--- a/drivers/input/misc/xen-kbdfront.c
+++ b/drivers/input/misc/xen-kbdfront.c
@@ -311,7 +311,6 @@ static void xenkbd_backend_changed(struct xenbus_device *dev,
 	case XenbusStateReconfiguring:
 	case XenbusStateReconfigured:
 	case XenbusStateUnknown:
-	case XenbusStateClosed:
 		break;
 
 	case XenbusStateInitWait:
@@ -350,6 +349,10 @@ InitWait:
 
 		break;
 
+	case XenbusStateClosed:
+		if (dev->state == XenbusStateClosed)
+			break;
+		/* Missed the backend's CLOSING state -- fallthrough */
 	case XenbusStateClosing:
 		xenbus_frontend_closed(dev);
 		break;
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 21 16:05:37 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Sep 2012 16:05: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 1TF5jK-0002sd-N8; Fri, 21 Sep 2012 16:05:26 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1TF5jJ-0002ru-0v
	for xen-devel@lists.xensource.com; Fri, 21 Sep 2012 16:05:25 +0000
Received: from [85.158.139.83:51715] by server-15.bemta-5.messagelabs.com id
	80/29-23541-4409C505; Fri, 21 Sep 2012 16:05:24 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1348243521!27301423!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzAyMzY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11465 invoked from network); 21 Sep 2012 16:05:22 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-14.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Sep 2012 16:05:22 -0000
X-IronPort-AV: E=Sophos;i="4.80,463,1344211200"; d="scan'208";a="38744205"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Sep 2012 16:04:52 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1;
	Fri, 21 Sep 2012 12:04:51 -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 1TF5il-0008Al-Ep;
	Fri, 21 Sep 2012 17:04:51 +0100
From: David Vrabel <david.vrabel@citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 21 Sep 2012 17:04:22 +0100
Message-ID: <1348243464-15903-5-git-send-email-david.vrabel@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1348243464-15903-1-git-send-email-david.vrabel@citrix.com>
References: <1348243464-15903-1-git-send-email-david.vrabel@citrix.com>
MIME-Version: 1.0
Cc: linux-kernel@vger.kernel.org, linux-fbdev@vger.kernel.org,
	David Vrabel <david.vrabel@citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: [Xen-devel] [PATCH 4/6] xen-fbfront: handle backend CLOSED without
	CLOSING
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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>

Backend drivers shouldn't transistion to CLOSED unless the frontend is
CLOSED.  If a backend does transition to CLOSED too soon then the
frontend may not see the CLOSING state and will not properly shutdown.

So, treat an unexpected backend CLOSED state the same as CLOSING.

Signed-off-by: David Vrabel <david.vrabel@citrix.com>
Cc: <linux-fbdev@vger.kernel.org>
---
 drivers/video/xen-fbfront.c |    5 ++++-
 1 files changed, 4 insertions(+), 1 deletions(-)

diff --git a/drivers/video/xen-fbfront.c b/drivers/video/xen-fbfront.c
index b7f5173..917bb56 100644
--- a/drivers/video/xen-fbfront.c
+++ b/drivers/video/xen-fbfront.c
@@ -641,7 +641,6 @@ static void xenfb_backend_changed(struct xenbus_device *dev,
 	case XenbusStateReconfiguring:
 	case XenbusStateReconfigured:
 	case XenbusStateUnknown:
-	case XenbusStateClosed:
 		break;
 
 	case XenbusStateInitWait:
@@ -670,6 +669,10 @@ InitWait:
 		info->feature_resize = val;
 		break;
 
+	case XenbusStateClosed:
+		if (dev->state == XenbusStateClosed)
+			break;
+		/* Missed the backend's CLOSING state -- fallthrough */
 	case XenbusStateClosing:
 		xenbus_frontend_closed(dev);
 		break;
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 21 16:05:37 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Sep 2012 16:05: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 1TF5jK-0002sd-N8; Fri, 21 Sep 2012 16:05:26 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1TF5jJ-0002ru-0v
	for xen-devel@lists.xensource.com; Fri, 21 Sep 2012 16:05:25 +0000
Received: from [85.158.139.83:51715] by server-15.bemta-5.messagelabs.com id
	80/29-23541-4409C505; Fri, 21 Sep 2012 16:05:24 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1348243521!27301423!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzAyMzY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11465 invoked from network); 21 Sep 2012 16:05:22 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-14.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Sep 2012 16:05:22 -0000
X-IronPort-AV: E=Sophos;i="4.80,463,1344211200"; d="scan'208";a="38744205"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Sep 2012 16:04:52 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1;
	Fri, 21 Sep 2012 12:04:51 -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 1TF5il-0008Al-Ep;
	Fri, 21 Sep 2012 17:04:51 +0100
From: David Vrabel <david.vrabel@citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 21 Sep 2012 17:04:22 +0100
Message-ID: <1348243464-15903-5-git-send-email-david.vrabel@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1348243464-15903-1-git-send-email-david.vrabel@citrix.com>
References: <1348243464-15903-1-git-send-email-david.vrabel@citrix.com>
MIME-Version: 1.0
Cc: linux-kernel@vger.kernel.org, linux-fbdev@vger.kernel.org,
	David Vrabel <david.vrabel@citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: [Xen-devel] [PATCH 4/6] xen-fbfront: handle backend CLOSED without
	CLOSING
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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>

Backend drivers shouldn't transistion to CLOSED unless the frontend is
CLOSED.  If a backend does transition to CLOSED too soon then the
frontend may not see the CLOSING state and will not properly shutdown.

So, treat an unexpected backend CLOSED state the same as CLOSING.

Signed-off-by: David Vrabel <david.vrabel@citrix.com>
Cc: <linux-fbdev@vger.kernel.org>
---
 drivers/video/xen-fbfront.c |    5 ++++-
 1 files changed, 4 insertions(+), 1 deletions(-)

diff --git a/drivers/video/xen-fbfront.c b/drivers/video/xen-fbfront.c
index b7f5173..917bb56 100644
--- a/drivers/video/xen-fbfront.c
+++ b/drivers/video/xen-fbfront.c
@@ -641,7 +641,6 @@ static void xenfb_backend_changed(struct xenbus_device *dev,
 	case XenbusStateReconfiguring:
 	case XenbusStateReconfigured:
 	case XenbusStateUnknown:
-	case XenbusStateClosed:
 		break;
 
 	case XenbusStateInitWait:
@@ -670,6 +669,10 @@ InitWait:
 		info->feature_resize = val;
 		break;
 
+	case XenbusStateClosed:
+		if (dev->state == XenbusStateClosed)
+			break;
+		/* Missed the backend's CLOSING state -- fallthrough */
 	case XenbusStateClosing:
 		xenbus_frontend_closed(dev);
 		break;
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 21 16:05:37 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Sep 2012 16:05: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 1TF5jL-0002sq-5B; Fri, 21 Sep 2012 16:05:27 +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 1TF5jJ-0002rj-8e
	for xen-devel@lists.xensource.com; Fri, 21 Sep 2012 16:05:25 +0000
Received: from [85.158.139.83:51735] by server-3.bemta-5.messagelabs.com id
	63/B8-21836-4409C505; Fri, 21 Sep 2012 16:05:24 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1348243521!27301423!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzAyMzY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11549 invoked from network); 21 Sep 2012 16:05:23 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-14.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Sep 2012 16:05:23 -0000
X-IronPort-AV: E=Sophos;i="4.80,463,1344211200"; d="scan'208";a="38744203"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Sep 2012 16:04:52 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1;
	Fri, 21 Sep 2012 12:04:51 -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 1TF5il-0008Al-EI;
	Fri, 21 Sep 2012 17:04:51 +0100
From: David Vrabel <david.vrabel@citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 21 Sep 2012 17:04:21 +0100
Message-ID: <1348243464-15903-4-git-send-email-david.vrabel@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1348243464-15903-1-git-send-email-david.vrabel@citrix.com>
References: <1348243464-15903-1-git-send-email-david.vrabel@citrix.com>
MIME-Version: 1.0
Cc: linux-kernel@vger.kernel.org, David Vrabel <david.vrabel@citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: [Xen-devel] [PATCH 3/6] xen-pcifront: handle backend CLOSED without
	CLOSING
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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>

Backend drivers shouldn't transistion to CLOSED unless the frontend is
CLOSED.  If a backend does transition to CLOSED too soon then the
frontend may not see the CLOSING state and will not properly shutdown.

So, treat an unexpected backend CLOSED state the same as CLOSING.

Signed-off-by: David Vrabel <david.vrabel@citrix.com>
---
 drivers/pci/xen-pcifront.c |    5 ++++-
 1 files changed, 4 insertions(+), 1 deletions(-)

diff --git a/drivers/pci/xen-pcifront.c b/drivers/pci/xen-pcifront.c
index d6cc62c..b5692c3 100644
--- a/drivers/pci/xen-pcifront.c
+++ b/drivers/pci/xen-pcifront.c
@@ -1069,13 +1069,16 @@ static void __init_refok pcifront_backend_changed(struct xenbus_device *xdev,
 	case XenbusStateInitialising:
 	case XenbusStateInitWait:
 	case XenbusStateInitialised:
-	case XenbusStateClosed:
 		break;
 
 	case XenbusStateConnected:
 		pcifront_try_connect(pdev);
 		break;
 
+	case XenbusStateClosed:
+		if (xdev->state == XenbusStateClosed)
+			break;
+		/* Missed the backend's CLOSING state -- fallthrough */
 	case XenbusStateClosing:
 		dev_warn(&xdev->dev, "backend going away!\n");
 		pcifront_try_disconnect(pdev);
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 21 16:05:37 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Sep 2012 16:05: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 1TF5jL-0002sq-5B; Fri, 21 Sep 2012 16:05:27 +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 1TF5jJ-0002rj-8e
	for xen-devel@lists.xensource.com; Fri, 21 Sep 2012 16:05:25 +0000
Received: from [85.158.139.83:51735] by server-3.bemta-5.messagelabs.com id
	63/B8-21836-4409C505; Fri, 21 Sep 2012 16:05:24 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1348243521!27301423!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzAyMzY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11549 invoked from network); 21 Sep 2012 16:05:23 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-14.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Sep 2012 16:05:23 -0000
X-IronPort-AV: E=Sophos;i="4.80,463,1344211200"; d="scan'208";a="38744203"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Sep 2012 16:04:52 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1;
	Fri, 21 Sep 2012 12:04:51 -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 1TF5il-0008Al-EI;
	Fri, 21 Sep 2012 17:04:51 +0100
From: David Vrabel <david.vrabel@citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 21 Sep 2012 17:04:21 +0100
Message-ID: <1348243464-15903-4-git-send-email-david.vrabel@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1348243464-15903-1-git-send-email-david.vrabel@citrix.com>
References: <1348243464-15903-1-git-send-email-david.vrabel@citrix.com>
MIME-Version: 1.0
Cc: linux-kernel@vger.kernel.org, David Vrabel <david.vrabel@citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: [Xen-devel] [PATCH 3/6] xen-pcifront: handle backend CLOSED without
	CLOSING
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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>

Backend drivers shouldn't transistion to CLOSED unless the frontend is
CLOSED.  If a backend does transition to CLOSED too soon then the
frontend may not see the CLOSING state and will not properly shutdown.

So, treat an unexpected backend CLOSED state the same as CLOSING.

Signed-off-by: David Vrabel <david.vrabel@citrix.com>
---
 drivers/pci/xen-pcifront.c |    5 ++++-
 1 files changed, 4 insertions(+), 1 deletions(-)

diff --git a/drivers/pci/xen-pcifront.c b/drivers/pci/xen-pcifront.c
index d6cc62c..b5692c3 100644
--- a/drivers/pci/xen-pcifront.c
+++ b/drivers/pci/xen-pcifront.c
@@ -1069,13 +1069,16 @@ static void __init_refok pcifront_backend_changed(struct xenbus_device *xdev,
 	case XenbusStateInitialising:
 	case XenbusStateInitWait:
 	case XenbusStateInitialised:
-	case XenbusStateClosed:
 		break;
 
 	case XenbusStateConnected:
 		pcifront_try_connect(pdev);
 		break;
 
+	case XenbusStateClosed:
+		if (xdev->state == XenbusStateClosed)
+			break;
+		/* Missed the backend's CLOSING state -- fallthrough */
 	case XenbusStateClosing:
 		dev_warn(&xdev->dev, "backend going away!\n");
 		pcifront_try_disconnect(pdev);
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 21 16:18:01 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Sep 2012 16:18: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 1TF5vD-00046E-EY; Fri, 21 Sep 2012 16:17:43 +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 1TF5vB-000469-IP
	for xen-devel@lists.xen.org; Fri, 21 Sep 2012 16:17:41 +0000
Received: from [85.158.139.83:52938] by server-4.bemta-5.messagelabs.com id
	F2/09-23042-4239C505; Fri, 21 Sep 2012 16:17:40 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1348244259!31245318!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzAyMzY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7213 invoked from network); 21 Sep 2012 16:17:40 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-5.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Sep 2012 16:17:40 -0000
X-IronPort-AV: E=Sophos;i="4.80,463,1344211200"; d="scan'208";a="38746322"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Sep 2012 16:17:38 +0000
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.279.1; Fri, 21 Sep 2012
	12:17:38 -0400
Message-ID: <505C9320.8030905@citrix.com>
Date: Fri, 21 Sep 2012 17:17:36 +0100
From: David Vrabel <david.vrabel@citrix.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.1.16) Gecko/20120428 Iceowl/1.0b1 Icedove/3.0.11
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
References: <1348051887-21885-1-git-send-email-oliver.chick@citrix.com>	<505AF126.2050806@citrix.com>	<1348140637.24539.32.camel@oliverchick-Precision-WorkStation-T3400>	<505B1EB9020000780009CA6E@nat28.tlf.novell.com>	<505C5C54.4060100@citrix.com>
	<20120921142733.GB3389@phenom.dumpdata.com>
In-Reply-To: <20120921142733.GB3389@phenom.dumpdata.com>
Cc: Oliver Chick <oliver.chick@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	David Vrabel <david.vrabel@citrix.com>, Jan Beulich <JBeulich@suse.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [Xen-devel] [PATCH] Persistent grant maps for xen blk drivers
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 21/09/12 15:27, Konrad Rzeszutek Wilk wrote:
> On Fri, Sep 21, 2012 at 01:23:48PM +0100, David Vrabel wrote:
>>
>> It's not just virtual space.  blkback in pvops kernels allocates its
>> pages from the balloon and if there aren't enough ballooned out pages it
>> has to allocate real pages (releasing the MFN back to Xen).
>>
>> Classic kernels didn't need to do this as there was an API for allocate
>> new "empty" struct page's that get mapped into kernel space.
> 
> Can we ressurect/implement that in the new pvops? We could use the memory
> hotplug mechanism to allocate "non-existent" memory. 

I don't see why not.  Provided the limitations are documented I wouldn't
make merging the persistent grant stuff dependent on it.

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 21 16:18:01 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Sep 2012 16:18: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 1TF5vD-00046E-EY; Fri, 21 Sep 2012 16:17:43 +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 1TF5vB-000469-IP
	for xen-devel@lists.xen.org; Fri, 21 Sep 2012 16:17:41 +0000
Received: from [85.158.139.83:52938] by server-4.bemta-5.messagelabs.com id
	F2/09-23042-4239C505; Fri, 21 Sep 2012 16:17:40 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1348244259!31245318!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzAyMzY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7213 invoked from network); 21 Sep 2012 16:17:40 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-5.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Sep 2012 16:17:40 -0000
X-IronPort-AV: E=Sophos;i="4.80,463,1344211200"; d="scan'208";a="38746322"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Sep 2012 16:17:38 +0000
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.279.1; Fri, 21 Sep 2012
	12:17:38 -0400
Message-ID: <505C9320.8030905@citrix.com>
Date: Fri, 21 Sep 2012 17:17:36 +0100
From: David Vrabel <david.vrabel@citrix.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.1.16) Gecko/20120428 Iceowl/1.0b1 Icedove/3.0.11
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
References: <1348051887-21885-1-git-send-email-oliver.chick@citrix.com>	<505AF126.2050806@citrix.com>	<1348140637.24539.32.camel@oliverchick-Precision-WorkStation-T3400>	<505B1EB9020000780009CA6E@nat28.tlf.novell.com>	<505C5C54.4060100@citrix.com>
	<20120921142733.GB3389@phenom.dumpdata.com>
In-Reply-To: <20120921142733.GB3389@phenom.dumpdata.com>
Cc: Oliver Chick <oliver.chick@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	David Vrabel <david.vrabel@citrix.com>, Jan Beulich <JBeulich@suse.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [Xen-devel] [PATCH] Persistent grant maps for xen blk drivers
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 21/09/12 15:27, Konrad Rzeszutek Wilk wrote:
> On Fri, Sep 21, 2012 at 01:23:48PM +0100, David Vrabel wrote:
>>
>> It's not just virtual space.  blkback in pvops kernels allocates its
>> pages from the balloon and if there aren't enough ballooned out pages it
>> has to allocate real pages (releasing the MFN back to Xen).
>>
>> Classic kernels didn't need to do this as there was an API for allocate
>> new "empty" struct page's that get mapped into kernel space.
> 
> Can we ressurect/implement that in the new pvops? We could use the memory
> hotplug mechanism to allocate "non-existent" memory. 

I don't see why not.  Provided the limitations are documented I wouldn't
make merging the persistent grant stuff dependent on it.

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 21 16:18:07 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Sep 2012 16: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 1TF5vR-00047k-14; Fri, 21 Sep 2012 16:17:57 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <julien.grall@citrix.com>) id 1TF5vQ-00047a-2z
	for xen-devel@lists.xen.org; Fri, 21 Sep 2012 16:17:56 +0000
Received: from [85.158.137.99:10041] by server-5.bemta-3.messagelabs.com id
	25/F9-13133-3339C505; Fri, 21 Sep 2012 16:17:55 +0000
X-Env-Sender: julien.grall@citrix.com
X-Msg-Ref: server-13.tower-217.messagelabs.com!1348244273!18661896!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNzY0MjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13171 invoked from network); 21 Sep 2012 16:17:54 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-13.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Sep 2012 16:17:54 -0000
X-IronPort-AV: E=Sophos;i="4.80,463,1344211200"; d="scan'208";a="208943446"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Sep 2012 16:17:52 +0000
Received: from [10.80.248.240] (10.80.248.240) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1; Fri, 21 Sep 2012
	12:17:51 -0400
Message-ID: <505C941F.6080903@citrix.com>
Date: Fri, 21 Sep 2012 17:21:51 +0100
From: Julien Grall <julien.grall@citrix.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US;
	rv:1.9.1.16) Gecko/20120726 Icedove/3.0.11
MIME-Version: 1.0
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
References: <1348049147-16752-1-git-send-email-julien.grall@citrix.com>
	<20572.35759.42063.973125@mariner.uk.xensource.com>
In-Reply-To: <20572.35759.42063.973125@mariner.uk.xensource.com>
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] libxenstore: filter watch events in
 libxenstore when we unwatch
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 09/21/2012 04:45 PM, Ian Jackson wrote:

> Julien Grall writes ("[PATCH] libxenstore: filter watch events in libxenstore when we unwatch"):
>> XenStore puts in queued watch events via a thread and notifies the user.
>> Sometimes xs_unwatch is called before all related message is read. The use
>> case is non-threaded libevent, we have two event A and B:
>>     - Event A will destroy something and call xs_unwatch;
>>     - Event B is used to notify that a node has changed in XenStore.
>> As the event is called one by one, event A can be handled before event B.
>> So on next xs_watch_read the user could retrieve an unwatch token and
>> a segfault occured if the token store the pointer of the structure
>> (ie: "backend:0xcafe").
> 
> Missing from the explanation here is why your patch is sufficient to
> avoid the race.  The answer is as follows (and should probably be in
> the commit message):
> 
> While on entry to xs_unwatch, there may be an event on its way from
> xenstored (eg in the ring or in the local kernel), all such events
> will definitely come before the reply to the unwatch command.  So at
> the point where the unwatch reply has been processed (after xs_talkv),
> any such now-deleted watch events will definitely have made it to
> libxenstore's queue where we can remove them.
> 
> As for other threads in the same process: if two threads call
> xs_read_watch and xs_unwatch, it is acceptable for the xs_read_watch
> to return the event being deleted.  What is not allowed is for an
> xs_read_watch entered after xs_unwatch returns to return the deleted
> event, and this code does indeed ensure that.
> 
> Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
> (for the explanation)
> 
> Now for some comments on the patch:
> 
>> +	/* Filter the watch list to remove potential message */
>> +	mutex_lock(&h->watch_mutex);
>> +
>> +	if (list_empty(&h->watch_list)) {
>> +		mutex_unlock(&h->watch_mutex);
>> +		return res;
>> +	}
> 
> I think this check is unnecessary.  If the list is empty then walking
> it is trivially a no-op.

It's usefull, if we need to clean the pipe (see explanation below).
Otherwise, the read will block and we want to avoid that on
mono-threaded (I don't consider xenstore thread).

>> +	list_for_each_entry_safe(msg, tmsg, &h->watch_list, list) {
>> +		assert(msg->hdr.type == XS_WATCH_EVENT);
>> +
>> +		strings = msg->body;
>> +		num_strings = xs_count_strings(strings, msg->hdr.len);
> 
> The num_strings thing is obsolete.  There will always be two strings.
> Also xs_count_strings walks the array.

We can't assume that XS_WATCH_EVENT will always equal to 2. So we need
to browse until we find the right string. I use xs_count_strings because
it allows to not take care of the length message in the loop.

>> +		for (i = 0; i < num_strings; i++) {
>> +			if (i == XS_WATCH_TOKEN && !strcmp (token, strings)) {
> 
> This is rather odd.  It amounts to:
> 
>    for (i= blah blah) { if (i==FIXED_VALUE) { ..i.. } }
> 
>> +				list_del(&msg->list);
>> +				free(msg);
>> +				break;
>> +			}
>> +			strings = strings + strlen (strings) + 1;
> 
> You need to check the path as well as the token, since it is legal to
> set up multiple watches on different paths with the same token.
> 
> I think you can then do away with the calculation of "strings", at
> least mostly.
> 
>> +	/* Clear the pipe token if there are no more pending watches. */
>> +	if (list_empty(&h->watch_list) && (h->watch_pipe[0] != -1)) {
>> +		while (read(h->watch_pipe[0], &c, 1) != 1)
>> +			continue;
>> +	}
> 
> I'm not convinced this is necessary.  Don't callers already need to
> cope with potential spurious signallings of the watch pipe ?


I base my code on xs_read_watch. As I understand xs_read_watch, it will
wait on a condition until the list is not empty.
So if the list is empty and not the pipe, an event can occur and block
the application (with xs_read_watch).

Sincerely yours,

Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 21 16:18:07 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Sep 2012 16: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 1TF5vR-00047k-14; Fri, 21 Sep 2012 16:17:57 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <julien.grall@citrix.com>) id 1TF5vQ-00047a-2z
	for xen-devel@lists.xen.org; Fri, 21 Sep 2012 16:17:56 +0000
Received: from [85.158.137.99:10041] by server-5.bemta-3.messagelabs.com id
	25/F9-13133-3339C505; Fri, 21 Sep 2012 16:17:55 +0000
X-Env-Sender: julien.grall@citrix.com
X-Msg-Ref: server-13.tower-217.messagelabs.com!1348244273!18661896!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNzY0MjQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13171 invoked from network); 21 Sep 2012 16:17:54 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-13.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Sep 2012 16:17:54 -0000
X-IronPort-AV: E=Sophos;i="4.80,463,1344211200"; d="scan'208";a="208943446"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Sep 2012 16:17:52 +0000
Received: from [10.80.248.240] (10.80.248.240) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1; Fri, 21 Sep 2012
	12:17:51 -0400
Message-ID: <505C941F.6080903@citrix.com>
Date: Fri, 21 Sep 2012 17:21:51 +0100
From: Julien Grall <julien.grall@citrix.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US;
	rv:1.9.1.16) Gecko/20120726 Icedove/3.0.11
MIME-Version: 1.0
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
References: <1348049147-16752-1-git-send-email-julien.grall@citrix.com>
	<20572.35759.42063.973125@mariner.uk.xensource.com>
In-Reply-To: <20572.35759.42063.973125@mariner.uk.xensource.com>
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] libxenstore: filter watch events in
 libxenstore when we unwatch
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 09/21/2012 04:45 PM, Ian Jackson wrote:

> Julien Grall writes ("[PATCH] libxenstore: filter watch events in libxenstore when we unwatch"):
>> XenStore puts in queued watch events via a thread and notifies the user.
>> Sometimes xs_unwatch is called before all related message is read. The use
>> case is non-threaded libevent, we have two event A and B:
>>     - Event A will destroy something and call xs_unwatch;
>>     - Event B is used to notify that a node has changed in XenStore.
>> As the event is called one by one, event A can be handled before event B.
>> So on next xs_watch_read the user could retrieve an unwatch token and
>> a segfault occured if the token store the pointer of the structure
>> (ie: "backend:0xcafe").
> 
> Missing from the explanation here is why your patch is sufficient to
> avoid the race.  The answer is as follows (and should probably be in
> the commit message):
> 
> While on entry to xs_unwatch, there may be an event on its way from
> xenstored (eg in the ring or in the local kernel), all such events
> will definitely come before the reply to the unwatch command.  So at
> the point where the unwatch reply has been processed (after xs_talkv),
> any such now-deleted watch events will definitely have made it to
> libxenstore's queue where we can remove them.
> 
> As for other threads in the same process: if two threads call
> xs_read_watch and xs_unwatch, it is acceptable for the xs_read_watch
> to return the event being deleted.  What is not allowed is for an
> xs_read_watch entered after xs_unwatch returns to return the deleted
> event, and this code does indeed ensure that.
> 
> Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
> (for the explanation)
> 
> Now for some comments on the patch:
> 
>> +	/* Filter the watch list to remove potential message */
>> +	mutex_lock(&h->watch_mutex);
>> +
>> +	if (list_empty(&h->watch_list)) {
>> +		mutex_unlock(&h->watch_mutex);
>> +		return res;
>> +	}
> 
> I think this check is unnecessary.  If the list is empty then walking
> it is trivially a no-op.

It's usefull, if we need to clean the pipe (see explanation below).
Otherwise, the read will block and we want to avoid that on
mono-threaded (I don't consider xenstore thread).

>> +	list_for_each_entry_safe(msg, tmsg, &h->watch_list, list) {
>> +		assert(msg->hdr.type == XS_WATCH_EVENT);
>> +
>> +		strings = msg->body;
>> +		num_strings = xs_count_strings(strings, msg->hdr.len);
> 
> The num_strings thing is obsolete.  There will always be two strings.
> Also xs_count_strings walks the array.

We can't assume that XS_WATCH_EVENT will always equal to 2. So we need
to browse until we find the right string. I use xs_count_strings because
it allows to not take care of the length message in the loop.

>> +		for (i = 0; i < num_strings; i++) {
>> +			if (i == XS_WATCH_TOKEN && !strcmp (token, strings)) {
> 
> This is rather odd.  It amounts to:
> 
>    for (i= blah blah) { if (i==FIXED_VALUE) { ..i.. } }
> 
>> +				list_del(&msg->list);
>> +				free(msg);
>> +				break;
>> +			}
>> +			strings = strings + strlen (strings) + 1;
> 
> You need to check the path as well as the token, since it is legal to
> set up multiple watches on different paths with the same token.
> 
> I think you can then do away with the calculation of "strings", at
> least mostly.
> 
>> +	/* Clear the pipe token if there are no more pending watches. */
>> +	if (list_empty(&h->watch_list) && (h->watch_pipe[0] != -1)) {
>> +		while (read(h->watch_pipe[0], &c, 1) != 1)
>> +			continue;
>> +	}
> 
> I'm not convinced this is necessary.  Don't callers already need to
> cope with potential spurious signallings of the watch pipe ?


I base my code on xs_read_watch. As I understand xs_read_watch, it will
wait on a condition until the list is not empty.
So if the list is empty and not the pipe, an event can occur and block
the application (with xs_read_watch).

Sincerely yours,

Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 21 16:29:16 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Sep 2012 16:29: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 1TF668-0004R6-BA; Fri, 21 Sep 2012 16:29:00 +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 1TF667-0004R1-Ev
	for xen-devel@lists.xen.org; Fri, 21 Sep 2012 16:28:59 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1348244933!6356558!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTA2NjI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32243 invoked from network); 21 Sep 2012 16:28: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;
	21 Sep 2012 16:28:53 -0000
X-IronPort-AV: E=Sophos;i="4.80,463,1344211200"; d="scan'208";a="14695128"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Sep 2012 16:28: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.279.1; Fri, 21 Sep 2012 17:28: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
	1TF65h-0002kB-HZ; Fri, 21 Sep 2012 16:28:33 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1TF65h-0003Sf-Dj;
	Fri, 21 Sep 2012 17:28:33 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20572.38321.326083.184425@mariner.uk.xensource.com>
Date: Fri, 21 Sep 2012 17:28:33 +0100
To: Julien Grall <julien.grall@citrix.com>
In-Reply-To: <505C941F.6080903@citrix.com>
References: <1348049147-16752-1-git-send-email-julien.grall@citrix.com>
	<20572.35759.42063.973125@mariner.uk.xensource.com>
	<505C941F.6080903@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] libxenstore: filter watch events in
 libxenstore when we unwatch
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Julien Grall writes ("Re: [PATCH] libxenstore: filter watch events in libxenstore when we unwatch"):
> On 09/21/2012 04:45 PM, Ian Jackson wrote:
> > The num_strings thing is obsolete.  There will always be two strings.
> > Also xs_count_strings walks the array.
> 
> We can't assume that XS_WATCH_EVENT will always equal to 2. So we need
> to browse until we find the right string. I use xs_count_strings because
> it allows to not take care of the length message in the loop.

You mean XS_WATCH_TOKEN.  And yes, we can assume that XS_WATCH_TOKEN
will always equal 1.  What is obsolete is the idea that it might be
anything different.

> >> +	/* Clear the pipe token if there are no more pending watches. */
> >> +	if (list_empty(&h->watch_list) && (h->watch_pipe[0] != -1)) {
> >> +		while (read(h->watch_pipe[0], &c, 1) != 1)
> >> +			continue;
> >> +	}
> > 
> > I'm not convinced this is necessary.  Don't callers already need to
> > cope with potential spurious signallings of the watch pipe ?
> 
> I base my code on xs_read_watch. As I understand xs_read_watch, it will
> wait on a condition until the list is not empty.
> So if the list is empty and not the pipe, an event can occur and block
> the application (with xs_read_watch).

xs_read_watch can only be correctly be used if you are determined to
wait, right there, until a particular watch turns up.

If you are using xs_fileno, you must do as the comment says:
 * Callers should, after xs_fileno has become readable, repeatedly
 * call xs_check_watch until it returns NULL and sets errno to EAGAIN.
 * (If the fd became readable, xs_check_watch is allowed to make it no
 * longer show up as readable even if future calls to xs_check_watch
 * will return more watch events.)

I agree that the comments in xenstore.h about this are less than
clear.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 21 16:29:16 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Sep 2012 16:29: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 1TF668-0004R6-BA; Fri, 21 Sep 2012 16:29:00 +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 1TF667-0004R1-Ev
	for xen-devel@lists.xen.org; Fri, 21 Sep 2012 16:28:59 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1348244933!6356558!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTA2NjI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32243 invoked from network); 21 Sep 2012 16:28: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;
	21 Sep 2012 16:28:53 -0000
X-IronPort-AV: E=Sophos;i="4.80,463,1344211200"; d="scan'208";a="14695128"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Sep 2012 16:28: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.279.1; Fri, 21 Sep 2012 17:28: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
	1TF65h-0002kB-HZ; Fri, 21 Sep 2012 16:28:33 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1TF65h-0003Sf-Dj;
	Fri, 21 Sep 2012 17:28:33 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20572.38321.326083.184425@mariner.uk.xensource.com>
Date: Fri, 21 Sep 2012 17:28:33 +0100
To: Julien Grall <julien.grall@citrix.com>
In-Reply-To: <505C941F.6080903@citrix.com>
References: <1348049147-16752-1-git-send-email-julien.grall@citrix.com>
	<20572.35759.42063.973125@mariner.uk.xensource.com>
	<505C941F.6080903@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] libxenstore: filter watch events in
 libxenstore when we unwatch
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Julien Grall writes ("Re: [PATCH] libxenstore: filter watch events in libxenstore when we unwatch"):
> On 09/21/2012 04:45 PM, Ian Jackson wrote:
> > The num_strings thing is obsolete.  There will always be two strings.
> > Also xs_count_strings walks the array.
> 
> We can't assume that XS_WATCH_EVENT will always equal to 2. So we need
> to browse until we find the right string. I use xs_count_strings because
> it allows to not take care of the length message in the loop.

You mean XS_WATCH_TOKEN.  And yes, we can assume that XS_WATCH_TOKEN
will always equal 1.  What is obsolete is the idea that it might be
anything different.

> >> +	/* Clear the pipe token if there are no more pending watches. */
> >> +	if (list_empty(&h->watch_list) && (h->watch_pipe[0] != -1)) {
> >> +		while (read(h->watch_pipe[0], &c, 1) != 1)
> >> +			continue;
> >> +	}
> > 
> > I'm not convinced this is necessary.  Don't callers already need to
> > cope with potential spurious signallings of the watch pipe ?
> 
> I base my code on xs_read_watch. As I understand xs_read_watch, it will
> wait on a condition until the list is not empty.
> So if the list is empty and not the pipe, an event can occur and block
> the application (with xs_read_watch).

xs_read_watch can only be correctly be used if you are determined to
wait, right there, until a particular watch turns up.

If you are using xs_fileno, you must do as the comment says:
 * Callers should, after xs_fileno has become readable, repeatedly
 * call xs_check_watch until it returns NULL and sets errno to EAGAIN.
 * (If the fd became readable, xs_check_watch is allowed to make it no
 * longer show up as readable even if future calls to xs_check_watch
 * will return more watch events.)

I agree that the comments in xenstore.h about this are less than
clear.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 21 16:45:34 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Sep 2012 16:45: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 1TF6Lv-00053d-IG; Fri, 21 Sep 2012 16:45:19 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ketuzsezr@gmail.com>) id 1TF6Lu-00053X-FI
	for xen-devel@lists.xen.org; Fri, 21 Sep 2012 16:45:18 +0000
Received: from [85.158.143.99:55600] by server-3.bemta-4.messagelabs.com id
	72/67-10986-D999C505; Fri, 21 Sep 2012 16:45:17 +0000
X-Env-Sender: ketuzsezr@gmail.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1348245915!24875761!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-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24850 invoked from network); 21 Sep 2012 16:45:16 -0000
Received: from mail-qc0-f173.google.com (HELO mail-qc0-f173.google.com)
	(209.85.216.173)
	by server-10.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Sep 2012 16:45:16 -0000
Received: by qcab12 with SMTP id b12so3543474qca.32
	for <xen-devel@lists.xen.org>; Fri, 21 Sep 2012 09:45:15 -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=TVlFRJNByff3NQBarRSnC44+tI8QO+/iSmGY8I2f47g=;
	b=rpbdG9XmOxJnzB4etiCgXwJ/x2avTD4MaOlSnLx6aLOW0/ygjEVBArF4210ybtTBvH
	+IXBuRCmOUfnVr8rYv44u7jP1Yru8JhKfcK2eVXJf34JsALb3cfBc7GHxyLWA/giVseo
	bHokEJgwEMTZU9Qi02u1sP9vLmwJ2eqEe0d1FE48xfrbXUDM0Bi6a8xyAa2t4RSsvNz8
	tlFLmAV28VgXXEyWftdoAdP5Ohvl2QbyHMUlh4V3WFSbMafvXrGF5MFZy4IkOE1FeRSD
	O95ZQaz92iTJIsBg0XRvXOJunSKaiuBD7d6fXU95oBGi6VOP3L4OVCd0u9CidZgr9NiC
	DyKg==
Received: by 10.229.136.72 with SMTP id q8mr3653501qct.134.1348245914963;
	Fri, 21 Sep 2012 09:45:14 -0700 (PDT)
Received: from phenom.dumpdata.com
	(50-195-21-189-static.hfc.comcastbusiness.net. [50.195.21.189])
	by mx.google.com with ESMTPS id g18sm10721464qan.1.2012.09.21.09.45.13
	(version=TLSv1/SSLv3 cipher=OTHER);
	Fri, 21 Sep 2012 09:45:14 -0700 (PDT)
Date: Fri, 21 Sep 2012 12:34:07 -0400
From: Konrad Rzeszutek Wilk <konrad@kernel.org>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20120921163406.GC4780@phenom.dumpdata.com>
References: <504F3F8A020000780009A8F9@nat28.tlf.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <504F3F8A020000780009A8F9@nat28.tlf.novell.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] x86: retrieve keyboard shift status flags
 from BIOS
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Sep 11, 2012 at 12:41:30PM +0100, Jan Beulich wrote:
> Recent Linux tries to make use of this, and has no way of getting at
> these bits without Xen assisting it.
> 
> There doesn't appear to be a way to obtain the same information from
> UEFI.

And here is a variant for the upstream:

>From 21b4fdf0592156ac3020f5c492139368dcdfcf71 Mon Sep 17 00:00:00 2001
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Fri, 21 Sep 2012 12:30:35 -0400
Subject: [PATCH] xen/x86: retrieve keyboard shift status flags from
 hypervisor.

The xen c/s 25873 allows the hypervisor to retrieve the NUMLOCK flag.
With this patch, the Linux kernel can get the state according to the
data in the BIOS.

Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 arch/x86/xen/enlighten.c         |    8 ++++++++
 include/xen/interface/platform.h |    3 +++
 2 files changed, 11 insertions(+), 0 deletions(-)

diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
index 9642d4a..89a7c57 100644
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -1441,11 +1441,19 @@ asmlinkage void __init xen_start_kernel(void)
 		const struct dom0_vga_console_info *info =
 			(void *)((char *)xen_start_info +
 				 xen_start_info->console.dom0.info_off);
+		struct xen_platform_op op = {
+			.cmd = XENPF_firmware_info,
+			.interface_version = XENPF_INTERFACE_VERSION,
+			.u.firmware_info.type = XEN_FW_KBD_SHIFT_FLAGS,
+		};
 
 		xen_init_vga(info, xen_start_info->console.dom0.info_size);
 		xen_start_info->console.domU.mfn = 0;
 		xen_start_info->console.domU.evtchn = 0;
 
+		if (HYPERVISOR_dom0_op(&op) == 0)
+			boot_params.kbd_status = op.u.firmware_info.u.kbd_shift_flags;
+
 		xen_init_apic();
 
 		/* Make sure ACS will be enabled */
diff --git a/include/xen/interface/platform.h b/include/xen/interface/platform.h
index 61fa661..81eee3b 100644
--- a/include/xen/interface/platform.h
+++ b/include/xen/interface/platform.h
@@ -112,6 +112,7 @@ DEFINE_GUEST_HANDLE_STRUCT(xenpf_platform_quirk_t);
 #define XEN_FW_DISK_INFO          1 /* from int 13 AH=08/41/48 */
 #define XEN_FW_DISK_MBR_SIGNATURE 2 /* from MBR offset 0x1b8 */
 #define XEN_FW_VBEDDC_INFO        3 /* from int 10 AX=4f15 */
+#define XEN_FW_KBD_SHIFT_FLAGS    5 /* Int16, Fn02: Get keyboard shift flags. */
 struct xenpf_firmware_info {
 	/* IN variables. */
 	uint32_t type;
@@ -142,6 +143,8 @@ struct xenpf_firmware_info {
 			/* must refer to 128-byte buffer */
 			GUEST_HANDLE(uchar) edid;
 		} vbeddc_info; /* XEN_FW_VBEDDC_INFO */
+		uint8_t kbd_shift_flags; /* XEN_FW_KBD_SHIFT_FLAGS */
+
 	} u;
 };
 DEFINE_GUEST_HANDLE_STRUCT(xenpf_firmware_info_t);
-- 
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 Sep 21 16:45:34 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Sep 2012 16:45: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 1TF6Lv-00053d-IG; Fri, 21 Sep 2012 16:45:19 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ketuzsezr@gmail.com>) id 1TF6Lu-00053X-FI
	for xen-devel@lists.xen.org; Fri, 21 Sep 2012 16:45:18 +0000
Received: from [85.158.143.99:55600] by server-3.bemta-4.messagelabs.com id
	72/67-10986-D999C505; Fri, 21 Sep 2012 16:45:17 +0000
X-Env-Sender: ketuzsezr@gmail.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1348245915!24875761!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-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24850 invoked from network); 21 Sep 2012 16:45:16 -0000
Received: from mail-qc0-f173.google.com (HELO mail-qc0-f173.google.com)
	(209.85.216.173)
	by server-10.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Sep 2012 16:45:16 -0000
Received: by qcab12 with SMTP id b12so3543474qca.32
	for <xen-devel@lists.xen.org>; Fri, 21 Sep 2012 09:45:15 -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=TVlFRJNByff3NQBarRSnC44+tI8QO+/iSmGY8I2f47g=;
	b=rpbdG9XmOxJnzB4etiCgXwJ/x2avTD4MaOlSnLx6aLOW0/ygjEVBArF4210ybtTBvH
	+IXBuRCmOUfnVr8rYv44u7jP1Yru8JhKfcK2eVXJf34JsALb3cfBc7GHxyLWA/giVseo
	bHokEJgwEMTZU9Qi02u1sP9vLmwJ2eqEe0d1FE48xfrbXUDM0Bi6a8xyAa2t4RSsvNz8
	tlFLmAV28VgXXEyWftdoAdP5Ohvl2QbyHMUlh4V3WFSbMafvXrGF5MFZy4IkOE1FeRSD
	O95ZQaz92iTJIsBg0XRvXOJunSKaiuBD7d6fXU95oBGi6VOP3L4OVCd0u9CidZgr9NiC
	DyKg==
Received: by 10.229.136.72 with SMTP id q8mr3653501qct.134.1348245914963;
	Fri, 21 Sep 2012 09:45:14 -0700 (PDT)
Received: from phenom.dumpdata.com
	(50-195-21-189-static.hfc.comcastbusiness.net. [50.195.21.189])
	by mx.google.com with ESMTPS id g18sm10721464qan.1.2012.09.21.09.45.13
	(version=TLSv1/SSLv3 cipher=OTHER);
	Fri, 21 Sep 2012 09:45:14 -0700 (PDT)
Date: Fri, 21 Sep 2012 12:34:07 -0400
From: Konrad Rzeszutek Wilk <konrad@kernel.org>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20120921163406.GC4780@phenom.dumpdata.com>
References: <504F3F8A020000780009A8F9@nat28.tlf.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <504F3F8A020000780009A8F9@nat28.tlf.novell.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] x86: retrieve keyboard shift status flags
 from BIOS
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Sep 11, 2012 at 12:41:30PM +0100, Jan Beulich wrote:
> Recent Linux tries to make use of this, and has no way of getting at
> these bits without Xen assisting it.
> 
> There doesn't appear to be a way to obtain the same information from
> UEFI.

And here is a variant for the upstream:

>From 21b4fdf0592156ac3020f5c492139368dcdfcf71 Mon Sep 17 00:00:00 2001
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Fri, 21 Sep 2012 12:30:35 -0400
Subject: [PATCH] xen/x86: retrieve keyboard shift status flags from
 hypervisor.

The xen c/s 25873 allows the hypervisor to retrieve the NUMLOCK flag.
With this patch, the Linux kernel can get the state according to the
data in the BIOS.

Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 arch/x86/xen/enlighten.c         |    8 ++++++++
 include/xen/interface/platform.h |    3 +++
 2 files changed, 11 insertions(+), 0 deletions(-)

diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
index 9642d4a..89a7c57 100644
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -1441,11 +1441,19 @@ asmlinkage void __init xen_start_kernel(void)
 		const struct dom0_vga_console_info *info =
 			(void *)((char *)xen_start_info +
 				 xen_start_info->console.dom0.info_off);
+		struct xen_platform_op op = {
+			.cmd = XENPF_firmware_info,
+			.interface_version = XENPF_INTERFACE_VERSION,
+			.u.firmware_info.type = XEN_FW_KBD_SHIFT_FLAGS,
+		};
 
 		xen_init_vga(info, xen_start_info->console.dom0.info_size);
 		xen_start_info->console.domU.mfn = 0;
 		xen_start_info->console.domU.evtchn = 0;
 
+		if (HYPERVISOR_dom0_op(&op) == 0)
+			boot_params.kbd_status = op.u.firmware_info.u.kbd_shift_flags;
+
 		xen_init_apic();
 
 		/* Make sure ACS will be enabled */
diff --git a/include/xen/interface/platform.h b/include/xen/interface/platform.h
index 61fa661..81eee3b 100644
--- a/include/xen/interface/platform.h
+++ b/include/xen/interface/platform.h
@@ -112,6 +112,7 @@ DEFINE_GUEST_HANDLE_STRUCT(xenpf_platform_quirk_t);
 #define XEN_FW_DISK_INFO          1 /* from int 13 AH=08/41/48 */
 #define XEN_FW_DISK_MBR_SIGNATURE 2 /* from MBR offset 0x1b8 */
 #define XEN_FW_VBEDDC_INFO        3 /* from int 10 AX=4f15 */
+#define XEN_FW_KBD_SHIFT_FLAGS    5 /* Int16, Fn02: Get keyboard shift flags. */
 struct xenpf_firmware_info {
 	/* IN variables. */
 	uint32_t type;
@@ -142,6 +143,8 @@ struct xenpf_firmware_info {
 			/* must refer to 128-byte buffer */
 			GUEST_HANDLE(uchar) edid;
 		} vbeddc_info; /* XEN_FW_VBEDDC_INFO */
+		uint8_t kbd_shift_flags; /* XEN_FW_KBD_SHIFT_FLAGS */
+
 	} u;
 };
 DEFINE_GUEST_HANDLE_STRUCT(xenpf_firmware_info_t);
-- 
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 Sep 21 17:06:48 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Sep 2012 17: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 1TF6gN-0005W4-Gv; Fri, 21 Sep 2012 17:06:27 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <pawel.moll@arm.com>) id 1TF6gM-0005Vz-G6
	for xen-devel@lists.xensource.com; Fri, 21 Sep 2012 17:06:26 +0000
Received: from [85.158.143.99:14582] by server-3.bemta-4.messagelabs.com id
	E2/D4-10986-19E9C505; Fri, 21 Sep 2012 17:06:25 +0000
X-Env-Sender: pawel.moll@arm.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1348247184!26012450!1
X-Originating-IP: [91.220.42.44]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogOTEuMjIwLjQyLjQ0ID0+IDMwMDEzMQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21350 invoked from network); 21 Sep 2012 17:06:25 -0000
Received: from service87.mimecast.com (HELO service87.mimecast.com)
	(91.220.42.44) by server-4.tower-216.messagelabs.com with SMTP;
	21 Sep 2012 17:06:25 -0000
Received: from cam-owa1.Emea.Arm.com (fw-tnat.cambridge.arm.com
	[217.140.96.21]) by service87.mimecast.com;
	Fri, 21 Sep 2012 18:06:24 +0100
Received: from [10.1.205.42] ([10.1.255.212]) by cam-owa1.Emea.Arm.com with
	Microsoft SMTPSVC(6.0.3790.0); Fri, 21 Sep 2012 18:06:22 +0100
Message-ID: <1348247182.11116.245.camel@hornet>
From: Pawel Moll <pawel.moll@arm.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Fri, 21 Sep 2012 18:06:22 +0100
In-Reply-To: <1348156062-11476-1-git-send-email-stefano.stabellini@eu.citrix.com>
References: <1348156062-11476-1-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: Evolution 3.2.3-0ubuntu6
Mime-Version: 1.0
X-OriginalArrivalTime: 21 Sep 2012 17:06:22.0760 (UTC)
	FILETIME=[6D38F280:01CD981B]
X-MC-Unique: 112092118062401301
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Ian.Campbell@citrix.com" <Ian.Campbell@citrix.com>,
	Arnd Bergmann <arnd@arndb.de>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Xen-devel] [PATCH v2] arm: introduce a DTS for Xen
 unprivileged virtual 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 Thu, 2012-09-20 at 16:47 +0100, Stefano Stabellini wrote:
> Given that the xenvm machine is based on vexpress but with an extremely
> limited selection of peripherals (the guest is supposed to use virtual
> devices instead), add "xen,xenvm" to the list of compatible machines in
> mach-vexpress.
> 
> 
> Changes in v2:
> 
> - remove include skeleton;
> - use #address-cells = <2> and #size-cells = <2>;
> - remove the debug bootargs;
> - use memory@80000000 instead of memory;
> - remove the ranges and interrupt-map from the motherboard node;
> - set the machine compatible to "xen,xenvm-4.2", "xen,xenvm";
> - rename the dts file to xenvm-4.2.dts;
> - add "xen,xenvm" to the list of compatible DT strings to mach-vexpress.
> 
> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> CC: Pawel Moll <pawel.moll@arm.com>
> CC: Arnd Bergmann <arnd@arndb.de>
> ---
>  arch/arm/boot/dts/xenvm-4.2.dts      |   64 ++++++++++++++++++++++++++++++++++
>  arch/arm/mach-vexpress/Makefile.boot |    3 +-
>  arch/arm/mach-vexpress/v2m.c         |    1 +
>  3 files changed, 67 insertions(+), 1 deletions(-)
>  create mode 100644 arch/arm/boot/dts/xenvm-4.2.dts

I'm still not 100% convinced that the DTS is really necessary there, but
as to the v2m.c change:

Acked-by: Pawel Moll <pawel.moll@arm.com>

Cheers!

Pawel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 21 17:06:48 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Sep 2012 17: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 1TF6gN-0005W4-Gv; Fri, 21 Sep 2012 17:06:27 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <pawel.moll@arm.com>) id 1TF6gM-0005Vz-G6
	for xen-devel@lists.xensource.com; Fri, 21 Sep 2012 17:06:26 +0000
Received: from [85.158.143.99:14582] by server-3.bemta-4.messagelabs.com id
	E2/D4-10986-19E9C505; Fri, 21 Sep 2012 17:06:25 +0000
X-Env-Sender: pawel.moll@arm.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1348247184!26012450!1
X-Originating-IP: [91.220.42.44]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogOTEuMjIwLjQyLjQ0ID0+IDMwMDEzMQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21350 invoked from network); 21 Sep 2012 17:06:25 -0000
Received: from service87.mimecast.com (HELO service87.mimecast.com)
	(91.220.42.44) by server-4.tower-216.messagelabs.com with SMTP;
	21 Sep 2012 17:06:25 -0000
Received: from cam-owa1.Emea.Arm.com (fw-tnat.cambridge.arm.com
	[217.140.96.21]) by service87.mimecast.com;
	Fri, 21 Sep 2012 18:06:24 +0100
Received: from [10.1.205.42] ([10.1.255.212]) by cam-owa1.Emea.Arm.com with
	Microsoft SMTPSVC(6.0.3790.0); Fri, 21 Sep 2012 18:06:22 +0100
Message-ID: <1348247182.11116.245.camel@hornet>
From: Pawel Moll <pawel.moll@arm.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Fri, 21 Sep 2012 18:06:22 +0100
In-Reply-To: <1348156062-11476-1-git-send-email-stefano.stabellini@eu.citrix.com>
References: <1348156062-11476-1-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: Evolution 3.2.3-0ubuntu6
Mime-Version: 1.0
X-OriginalArrivalTime: 21 Sep 2012 17:06:22.0760 (UTC)
	FILETIME=[6D38F280:01CD981B]
X-MC-Unique: 112092118062401301
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Ian.Campbell@citrix.com" <Ian.Campbell@citrix.com>,
	Arnd Bergmann <arnd@arndb.de>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Xen-devel] [PATCH v2] arm: introduce a DTS for Xen
 unprivileged virtual 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 Thu, 2012-09-20 at 16:47 +0100, Stefano Stabellini wrote:
> Given that the xenvm machine is based on vexpress but with an extremely
> limited selection of peripherals (the guest is supposed to use virtual
> devices instead), add "xen,xenvm" to the list of compatible machines in
> mach-vexpress.
> 
> 
> Changes in v2:
> 
> - remove include skeleton;
> - use #address-cells = <2> and #size-cells = <2>;
> - remove the debug bootargs;
> - use memory@80000000 instead of memory;
> - remove the ranges and interrupt-map from the motherboard node;
> - set the machine compatible to "xen,xenvm-4.2", "xen,xenvm";
> - rename the dts file to xenvm-4.2.dts;
> - add "xen,xenvm" to the list of compatible DT strings to mach-vexpress.
> 
> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> CC: Pawel Moll <pawel.moll@arm.com>
> CC: Arnd Bergmann <arnd@arndb.de>
> ---
>  arch/arm/boot/dts/xenvm-4.2.dts      |   64 ++++++++++++++++++++++++++++++++++
>  arch/arm/mach-vexpress/Makefile.boot |    3 +-
>  arch/arm/mach-vexpress/v2m.c         |    1 +
>  3 files changed, 67 insertions(+), 1 deletions(-)
>  create mode 100644 arch/arm/boot/dts/xenvm-4.2.dts

I'm still not 100% convinced that the DTS is really necessary there, but
as to the v2m.c change:

Acked-by: Pawel Moll <pawel.moll@arm.com>

Cheers!

Pawel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 21 17:21:50 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Sep 2012 17: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 1TF6uy-00060C-L9; Fri, 21 Sep 2012 17:21:32 +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 1TF6ux-0005zn-Aj
	for xen-devel@lists.xensource.com; Fri, 21 Sep 2012 17:21:31 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1348248082!6360870!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzU2MzI0\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32625 invoked from network); 21 Sep 2012 17:21:24 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-6.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 21 Sep 2012 17:21:24 -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 q8LHLK2G001269
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 21 Sep 2012 17:21:21 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q8LHLJog027507
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 21 Sep 2012 17:21:20 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
	q8LHLJwX014460; Fri, 21 Sep 2012 12:21:19 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 21 Sep 2012 10:21:19 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 87DDB402EC; Fri, 21 Sep 2012 13:10:13 -0400 (EDT)
Date: Fri, 21 Sep 2012 13:10:13 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: David Vrabel <david.vrabel@citrix.com>
Message-ID: <20120921171013.GA9201@phenom.dumpdata.com>
References: <1348243464-15903-1-git-send-email-david.vrabel@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1348243464-15903-1-git-send-email-david.vrabel@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 0/6] xen: frontend devices should handle
 missed backend CLOSING
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Sep 21, 2012 at 05:04:18PM +0100, David Vrabel wrote:
> The series makes all the Xen frontend drivers handle the backend
> transitioning to CLOSED without the frontend having previously seen
> the backend in the CLOSING state.
> 
> Backends shouldn't do this but some do.  e.g., if the host is
> XenServer and the toolstack decides to do a forced shutdown of a VBD,
> then the blkfront may miss the CLOSING transition and the /dev/xvdX
> device will not be destroyed which prevents it being reused.
> 
> I have seen systems that ended up in this state but it's not clear if
> this was the actual cause.  However, I think in general it's a good
> thing to thing to improve the handling of unexpected state
> transitions.
> 
> Konrad, I've split this into a patch per frontend in case each patch
> should go via a different maintainer.  But if you'd prefer, I can roll
> this up into one patch to via your Xen tree.

I like the split-up. Can you repost them with the different maintainers
CC (scripts/get_maintainers.pl) and with Acked-by from me on them?

> 
> David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 21 17:21:50 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Sep 2012 17: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 1TF6uy-00060C-L9; Fri, 21 Sep 2012 17:21:32 +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 1TF6ux-0005zn-Aj
	for xen-devel@lists.xensource.com; Fri, 21 Sep 2012 17:21:31 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1348248082!6360870!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzU2MzI0\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32625 invoked from network); 21 Sep 2012 17:21:24 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-6.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 21 Sep 2012 17:21:24 -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 q8LHLK2G001269
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 21 Sep 2012 17:21:21 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q8LHLJog027507
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 21 Sep 2012 17:21:20 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
	q8LHLJwX014460; Fri, 21 Sep 2012 12:21:19 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 21 Sep 2012 10:21:19 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 87DDB402EC; Fri, 21 Sep 2012 13:10:13 -0400 (EDT)
Date: Fri, 21 Sep 2012 13:10:13 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: David Vrabel <david.vrabel@citrix.com>
Message-ID: <20120921171013.GA9201@phenom.dumpdata.com>
References: <1348243464-15903-1-git-send-email-david.vrabel@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1348243464-15903-1-git-send-email-david.vrabel@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 0/6] xen: frontend devices should handle
 missed backend CLOSING
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Sep 21, 2012 at 05:04:18PM +0100, David Vrabel wrote:
> The series makes all the Xen frontend drivers handle the backend
> transitioning to CLOSED without the frontend having previously seen
> the backend in the CLOSING state.
> 
> Backends shouldn't do this but some do.  e.g., if the host is
> XenServer and the toolstack decides to do a forced shutdown of a VBD,
> then the blkfront may miss the CLOSING transition and the /dev/xvdX
> device will not be destroyed which prevents it being reused.
> 
> I have seen systems that ended up in this state but it's not clear if
> this was the actual cause.  However, I think in general it's a good
> thing to thing to improve the handling of unexpected state
> transitions.
> 
> Konrad, I've split this into a patch per frontend in case each patch
> should go via a different maintainer.  But if you'd prefer, I can roll
> this up into one patch to via your Xen tree.

I like the split-up. Can you repost them with the different maintainers
CC (scripts/get_maintainers.pl) and with Acked-by from me on them?

> 
> David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 21 17:24:49 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Sep 2012 17:24:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TF6xt-0006E1-BR; Fri, 21 Sep 2012 17:24:33 +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 1TF6xr-0006Ds-UG
	for xen-devel@lists.xen.org; Fri, 21 Sep 2012 17:24:32 +0000
Received: from [85.158.138.51:52242] by server-11.bemta-3.messagelabs.com id
	51/2F-30250-FC2AC505; Fri, 21 Sep 2012 17:24:31 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1348248269!31465316!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzU2MzI0\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17586 invoked from network); 21 Sep 2012 17:24:30 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-8.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 21 Sep 2012 17:24:30 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q8LHOCaR005971
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 21 Sep 2012 17:24:13 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q8LHOBEJ006670
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 21 Sep 2012 17:24:11 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
	q8LHOBwW027967; Fri, 21 Sep 2012 12:24:11 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 21 Sep 2012 10:24:11 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 145B4402EC; Fri, 21 Sep 2012 13:13:05 -0400 (EDT)
Date: Fri, 21 Sep 2012 13:13:05 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: David Vrabel <david.vrabel@citrix.com>
Message-ID: <20120921171304.GB9201@phenom.dumpdata.com>
References: <1348051887-21885-1-git-send-email-oliver.chick@citrix.com>
	<505AF126.2050806@citrix.com>
	<1348140637.24539.32.camel@oliverchick-Precision-WorkStation-T3400>
	<505B1EB9020000780009CA6E@nat28.tlf.novell.com>
	<505C5C54.4060100@citrix.com>
	<20120921142733.GB3389@phenom.dumpdata.com>
	<505C9320.8030905@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <505C9320.8030905@citrix.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: Oliver Chick <oliver.chick@citrix.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Jan Beulich <JBeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] Persistent grant maps for xen blk drivers
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Sep 21, 2012 at 05:17:36PM +0100, David Vrabel wrote:
> On 21/09/12 15:27, Konrad Rzeszutek Wilk wrote:
> > On Fri, Sep 21, 2012 at 01:23:48PM +0100, David Vrabel wrote:
> >>
> >> It's not just virtual space.  blkback in pvops kernels allocates its
> >> pages from the balloon and if there aren't enough ballooned out pages it
> >> has to allocate real pages (releasing the MFN back to Xen).
> >>
> >> Classic kernels didn't need to do this as there was an API for allocate
> >> new "empty" struct page's that get mapped into kernel space.
> > 
> > Can we ressurect/implement that in the new pvops? We could use the memory
> > hotplug mechanism to allocate "non-existent" memory. 
> 
> I don't see why not.  Provided the limitations are documented I wouldn't
> make merging the persistent grant stuff dependent on it.

I was thinking about this in the future and not delay this [persistent grants].
> 
> David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 21 17:24:49 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Sep 2012 17:24:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TF6xt-0006E1-BR; Fri, 21 Sep 2012 17:24:33 +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 1TF6xr-0006Ds-UG
	for xen-devel@lists.xen.org; Fri, 21 Sep 2012 17:24:32 +0000
Received: from [85.158.138.51:52242] by server-11.bemta-3.messagelabs.com id
	51/2F-30250-FC2AC505; Fri, 21 Sep 2012 17:24:31 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1348248269!31465316!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzU2MzI0\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17586 invoked from network); 21 Sep 2012 17:24:30 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-8.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 21 Sep 2012 17:24:30 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q8LHOCaR005971
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 21 Sep 2012 17:24:13 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q8LHOBEJ006670
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 21 Sep 2012 17:24:11 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
	q8LHOBwW027967; Fri, 21 Sep 2012 12:24:11 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 21 Sep 2012 10:24:11 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 145B4402EC; Fri, 21 Sep 2012 13:13:05 -0400 (EDT)
Date: Fri, 21 Sep 2012 13:13:05 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: David Vrabel <david.vrabel@citrix.com>
Message-ID: <20120921171304.GB9201@phenom.dumpdata.com>
References: <1348051887-21885-1-git-send-email-oliver.chick@citrix.com>
	<505AF126.2050806@citrix.com>
	<1348140637.24539.32.camel@oliverchick-Precision-WorkStation-T3400>
	<505B1EB9020000780009CA6E@nat28.tlf.novell.com>
	<505C5C54.4060100@citrix.com>
	<20120921142733.GB3389@phenom.dumpdata.com>
	<505C9320.8030905@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <505C9320.8030905@citrix.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: Oliver Chick <oliver.chick@citrix.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Jan Beulich <JBeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] Persistent grant maps for xen blk drivers
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Sep 21, 2012 at 05:17:36PM +0100, David Vrabel wrote:
> On 21/09/12 15:27, Konrad Rzeszutek Wilk wrote:
> > On Fri, Sep 21, 2012 at 01:23:48PM +0100, David Vrabel wrote:
> >>
> >> It's not just virtual space.  blkback in pvops kernels allocates its
> >> pages from the balloon and if there aren't enough ballooned out pages it
> >> has to allocate real pages (releasing the MFN back to Xen).
> >>
> >> Classic kernels didn't need to do this as there was an API for allocate
> >> new "empty" struct page's that get mapped into kernel space.
> > 
> > Can we ressurect/implement that in the new pvops? We could use the memory
> > hotplug mechanism to allocate "non-existent" memory. 
> 
> I don't see why not.  Provided the limitations are documented I wouldn't
> make merging the persistent grant stuff dependent on it.

I was thinking about this in the future and not delay this [persistent grants].
> 
> David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 21 17:40:38 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Sep 2012 17: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 1TF7D9-0006p4-HN; Fri, 21 Sep 2012 17:40:19 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ketuzsezr@gmail.com>) id 1TF7D8-0006or-Np
	for xen-devel@lists.xensource.com; Fri, 21 Sep 2012 17:40:18 +0000
X-Env-Sender: ketuzsezr@gmail.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1348249210!6741377!1
X-Originating-IP: [209.85.216.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22227 invoked from network); 21 Sep 2012 17:40:11 -0000
Received: from mail-qa0-f43.google.com (HELO mail-qa0-f43.google.com)
	(209.85.216.43)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Sep 2012 17:40:11 -0000
Received: by qatk31 with SMTP id k31so1729032qat.9
	for <xen-devel@lists.xensource.com>;
	Fri, 21 Sep 2012 10:40:10 -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=RtUxBjZuy9fhwYkT/peSE1hC0eIO+CQd6/C/tKwp6tc=;
	b=uwzAmEb9dLC6IkbwZkib4g6Q4KsuRKiz8Wu8b+vVUOA9ww9TpzlRR4d8ezxpa1LlgI
	oDXSCzOLn3qoa8K6XTEIBI5cNXvWwhGpGOwaDuzfNnhnhAMVGd2Cqu+M4roJalWhAbE1
	jpRJvmgesciwoMfHaohrPgFn6PQ7kYmMngPHWp3c2lGvww36TVLeHx+gVLrhaD3pcUSj
	PgdvGFziecdVq55ztc5Da2BrMjfRzTOt38Cj0Nokgw26J1+i0fMhk90eyh/o9sfXfTKo
	pCJX33LBBXZ4aO2y1xcWgNiAY5k1Z8NdkWJ+ZEpFPvSWrcUO4ZhOVsi4kh2hIgUC+ecX
	UATw==
Received: by 10.224.115.208 with SMTP id j16mr14011355qaq.54.1348249210490;
	Fri, 21 Sep 2012 10:40:10 -0700 (PDT)
Received: from phenom.dumpdata.com
	(50-195-21-189-static.hfc.comcastbusiness.net. [50.195.21.189])
	by mx.google.com with ESMTPS id m4sm13294515qak.6.2012.09.21.10.40.09
	(version=TLSv1/SSLv3 cipher=OTHER);
	Fri, 21 Sep 2012 10:40:09 -0700 (PDT)
Date: Fri, 21 Sep 2012 13:29:02 -0400
From: Konrad Rzeszutek Wilk <konrad@kernel.org>
To: John Krstev <john.krstev@gmail.com>
Message-ID: <20120921172901.GA6821@phenom.dumpdata.com>
References: <CA+LkAa=RHJCtpncP8AUSeR8Te3ZLMvRctuZqnv_NwUkCQ-im8Q@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CA+LkAa=RHJCtpncP8AUSeR8Te3ZLMvRctuZqnv_NwUkCQ-im8Q@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] Xen + DVB = not working. memory allocation 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 Fri, Sep 21, 2012 at 01:02:23PM +1000, John Krstev wrote:
> Hi Konrad,

Hey John,

Please next time also include xen-devel on the To header. I've done that
for you.
> 
> I refer to your patch at:
> http://lists.xen.org/archives/html/xen-devel/2012-01/msg01927.html
> which I found reading
> http://www.gossamer-threads.com/lists/xen/devel/256197
> 
> I have a winfast DVT 2000H (cx88) DVB card which is not able to
> scan/watch digital TV when running under Xen.

Did you first try running it under baremetal Linux (using a Live CD for
example?) Did it work there?

How does it not work? Can you program it? Is this under a guest or the
main kernel? When it wsa not working, did you try all the debug
options enable (http://wiki.xen.org/wiki/XenSerialConsole) to
 see if there is anthing being reported?

> 
> I've tried installing the above patch to the 3.6-rc6 kernel, but did
> not seem to help.
> 
> Apologies if this has been asked before (I wasn't able to find another
> patch), but is there a patch to get this (suspected vmalloc_32) fixed
> and DVB card working?

Eventually yes.
> 
> FYI I'm running 64 bit 3.5-rc6 and xen 4.3-unstable.

3.5-rc6 or 3.6-rc6?
I presume the latter?
> 
> Thank you! :)
> 
> Regards,
> 
> John
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 21 17:40:38 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Sep 2012 17: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 1TF7D9-0006p4-HN; Fri, 21 Sep 2012 17:40:19 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ketuzsezr@gmail.com>) id 1TF7D8-0006or-Np
	for xen-devel@lists.xensource.com; Fri, 21 Sep 2012 17:40:18 +0000
X-Env-Sender: ketuzsezr@gmail.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1348249210!6741377!1
X-Originating-IP: [209.85.216.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22227 invoked from network); 21 Sep 2012 17:40:11 -0000
Received: from mail-qa0-f43.google.com (HELO mail-qa0-f43.google.com)
	(209.85.216.43)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Sep 2012 17:40:11 -0000
Received: by qatk31 with SMTP id k31so1729032qat.9
	for <xen-devel@lists.xensource.com>;
	Fri, 21 Sep 2012 10:40:10 -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=RtUxBjZuy9fhwYkT/peSE1hC0eIO+CQd6/C/tKwp6tc=;
	b=uwzAmEb9dLC6IkbwZkib4g6Q4KsuRKiz8Wu8b+vVUOA9ww9TpzlRR4d8ezxpa1LlgI
	oDXSCzOLn3qoa8K6XTEIBI5cNXvWwhGpGOwaDuzfNnhnhAMVGd2Cqu+M4roJalWhAbE1
	jpRJvmgesciwoMfHaohrPgFn6PQ7kYmMngPHWp3c2lGvww36TVLeHx+gVLrhaD3pcUSj
	PgdvGFziecdVq55ztc5Da2BrMjfRzTOt38Cj0Nokgw26J1+i0fMhk90eyh/o9sfXfTKo
	pCJX33LBBXZ4aO2y1xcWgNiAY5k1Z8NdkWJ+ZEpFPvSWrcUO4ZhOVsi4kh2hIgUC+ecX
	UATw==
Received: by 10.224.115.208 with SMTP id j16mr14011355qaq.54.1348249210490;
	Fri, 21 Sep 2012 10:40:10 -0700 (PDT)
Received: from phenom.dumpdata.com
	(50-195-21-189-static.hfc.comcastbusiness.net. [50.195.21.189])
	by mx.google.com with ESMTPS id m4sm13294515qak.6.2012.09.21.10.40.09
	(version=TLSv1/SSLv3 cipher=OTHER);
	Fri, 21 Sep 2012 10:40:09 -0700 (PDT)
Date: Fri, 21 Sep 2012 13:29:02 -0400
From: Konrad Rzeszutek Wilk <konrad@kernel.org>
To: John Krstev <john.krstev@gmail.com>
Message-ID: <20120921172901.GA6821@phenom.dumpdata.com>
References: <CA+LkAa=RHJCtpncP8AUSeR8Te3ZLMvRctuZqnv_NwUkCQ-im8Q@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CA+LkAa=RHJCtpncP8AUSeR8Te3ZLMvRctuZqnv_NwUkCQ-im8Q@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] Xen + DVB = not working. memory allocation 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 Fri, Sep 21, 2012 at 01:02:23PM +1000, John Krstev wrote:
> Hi Konrad,

Hey John,

Please next time also include xen-devel on the To header. I've done that
for you.
> 
> I refer to your patch at:
> http://lists.xen.org/archives/html/xen-devel/2012-01/msg01927.html
> which I found reading
> http://www.gossamer-threads.com/lists/xen/devel/256197
> 
> I have a winfast DVT 2000H (cx88) DVB card which is not able to
> scan/watch digital TV when running under Xen.

Did you first try running it under baremetal Linux (using a Live CD for
example?) Did it work there?

How does it not work? Can you program it? Is this under a guest or the
main kernel? When it wsa not working, did you try all the debug
options enable (http://wiki.xen.org/wiki/XenSerialConsole) to
 see if there is anthing being reported?

> 
> I've tried installing the above patch to the 3.6-rc6 kernel, but did
> not seem to help.
> 
> Apologies if this has been asked before (I wasn't able to find another
> patch), but is there a patch to get this (suspected vmalloc_32) fixed
> and DVB card working?

Eventually yes.
> 
> FYI I'm running 64 bit 3.5-rc6 and xen 4.3-unstable.

3.5-rc6 or 3.6-rc6?
I presume the latter?
> 
> Thank you! :)
> 
> Regards,
> 
> John
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 21 17:48:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Sep 2012 17: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 1TF7KX-00077M-KJ; Fri, 21 Sep 2012 17:47:57 +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 1TF7KV-00077G-QE
	for xen-devel@lists.xen.org; Fri, 21 Sep 2012 17:47:56 +0000
Received: from [85.158.143.99:58750] by server-2.bemta-4.messagelabs.com id
	F8/F4-06610-B48AC505; Fri, 21 Sep 2012 17:47:55 +0000
X-Env-Sender: Andre.Przywara@amd.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1348249673!30710119!1
X-Originating-IP: [216.32.180.30]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5320 invoked from network); 21 Sep 2012 17:47:54 -0000
Received: from va3ehsobe010.messaging.microsoft.com (HELO
	va3outboundpool.messaging.microsoft.com) (216.32.180.30)
	by server-3.tower-216.messagelabs.com with AES128-SHA encrypted SMTP;
	21 Sep 2012 17:47:54 -0000
Received: from mail148-va3-R.bigfish.com (10.7.14.249) by
	VA3EHSOBE005.bigfish.com (10.7.40.25) with Microsoft SMTP Server id
	14.1.225.23; Fri, 21 Sep 2012 17:47:52 +0000
Received: from mail148-va3 (localhost [127.0.0.1])	by
	mail148-va3-R.bigfish.com (Postfix) with ESMTP id BE7274C0242;
	Fri, 21 Sep 2012 17:47: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: -2
X-BigFish: VPS-2(z551bizbb2dI98dI9371I1432Id6eahd6f1izz1202h1d1ah1d2ahzz8275bhz2dh668h839hd25he5bhf0ah107ah1288h12a5h12a9h12bdh137ah1155h)
Received: from mail148-va3 (localhost.localdomain [127.0.0.1]) by mail148-va3
	(MessageSwitch) id 1348249670623187_9835;
	Fri, 21 Sep 2012 17:47:50 +0000 (UTC)
Received: from VA3EHSMHS029.bigfish.com (unknown [10.7.14.238])	by
	mail148-va3.bigfish.com (Postfix) with ESMTP id 95B6F3E0172;
	Fri, 21 Sep 2012 17:47:50 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	VA3EHSMHS029.bigfish.com (10.7.99.39) with Microsoft SMTP Server id
	14.1.225.23; Fri, 21 Sep 2012 17:47:49 +0000
X-WSS-ID: 0MAPO3L-02-N5R-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 2D3E3C8007;	Fri, 21 Sep 2012 12:47:44 -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;
	Fri, 21 Sep 2012 12:48:07 -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;
	Fri, 21 Sep 2012 12:47:46 -0500
Received: from [10.224.148.43] (10.224.148.43) by storexhtp02.amd.com
	(172.24.4.4) with Microsoft SMTP Server id 8.3.213.0; Fri, 21 Sep 2012
	13:47:45 -0400
Message-ID: <505CA8AB.6000808@amd.com>
Date: Fri, 21 Sep 2012 19:49:31 +0200
From: Andre Przywara <andre.przywara@amd.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.26) Gecko/20120131 Lightning/1.0b2 Thunderbird/3.1.18
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
References: <501BC20F.3040205@amd.com>
	<20120803123628.GB10670@andromeda.dapyr.net>
	<20120817142237.GA8467@phenom.dumpdata.com>
In-Reply-To: <20120817142237.GA8467@phenom.dumpdata.com>
X-OriginatorOrg: amd.com
Cc: Konrad Rzeszutek Wilk <konrad@darnok.org>,
	Jeremy Fitzhardinge <jeremy@goop.org>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Dom0 crash with old style AMD NUMA detection
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-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/17/2012 04:22 PM, Konrad Rzeszutek Wilk wrote:
> On Fri, Aug 03, 2012 at 08:36:28AM -0400, Konrad Rzeszutek Wilk wrote:
>> On Fri, Aug 03, 2012 at 02:20:31PM +0200, Andre Przywara wrote:

Sorry Konrad, almost forgot.
Comment (and Ack) below...

>>> we see Dom0 crashes due to the kernel detecting the NUMA topology not by
>>> ACPI, but directly from the northbridge (CONFIG_AMD_NUMA).
>>>
>>> This will detect the actual NUMA config of the physical machine, but
>>> will crash about the mismatch with Dom0's virtual memory. Variation of
>>> the theme: Dom0 sees what it's not supposed to see.
>>>
>>> This happens with the said config option enabled and on a machine where
>>> this scanning is still enabled (K8 and Fam10h, not Bulldozer class)
>>>
>>> We have this dump then:
>>> [    0.000000] NUMA: Warning: node ids are out of bound, from=-1 to=-1
>>> distance=10
>>> [    0.000000] Scanning NUMA topology in Northbridge 24
>>> [    0.000000] Number of physical nodes 4
>>> [    0.000000] Node 0 MemBase 0000000000000000 Limit 0000000040000000
>>> [    0.000000] Node 1 MemBase 0000000040000000 Limit 0000000138000000
>>> [    0.000000] Node 2 MemBase 0000000138000000 Limit 00000001f8000000
>>> [    0.000000] Node 3 MemBase 00000001f8000000 Limit 0000000238000000
>>> [    0.000000] Initmem setup node 0 0000000000000000-0000000040000000
>>> [    0.000000]   NODE_DATA [000000003ffd9000 - 000000003fffffff]
>>> [    0.000000] Initmem setup node 1 0000000040000000-0000000138000000
>>> [    0.000000]   NODE_DATA [0000000137fd9000 - 0000000137ffffff]
>>> [    0.000000] Initmem setup node 2 0000000138000000-00000001f8000000
>>> [    0.000000]   NODE_DATA [00000001f095e000 - 00000001f0984fff]
>>> [    0.000000] Initmem setup node 3 00000001f8000000-0000000238000000
>>> [    0.000000] Cannot find 159744 bytes in node 3
>>> [    0.000000] BUG: unable to handle kernel NULL pointer dereference at
>>> (null)
>>> [    0.000000] IP: [<ffffffff81d220e6>] __alloc_bootmem_node+0x43/0x96
>>> [    0.000000] PGD 0
>>> [    0.000000] Oops: 0000 [#1] SMP
>>> [    0.000000] CPU 0
>>> [    0.000000] Modules linked in:
>>> [    0.000000]
>>> [    0.000000] Pid: 0, comm: swapper Not tainted 3.3.6 #1 AMD Dinar/Dinar
>>> [    0.000000] RIP: e030:[<ffffffff81d220e6>]  [<ffffffff81d220e6>]
>>> __alloc_bootmem_node+0x43/0x96
>>> [    0.000000] RSP: e02b:ffffffff81c01de8  EFLAGS: 00010046
>>> [    0.000000] RAX: 0000000000000000 RBX: 00000000000000c0 RCX:
>>> 0000000000000000
>>> [    0.000000] RDX: 0000000000000040 RSI: 00000000000000c0 RDI:
>>> 0000000000000000
>>> [    0.000000] RBP: ffffffff81c01e08 R08: 0000000000000000 R09:
>>> 0000000000000000
>>> [    0.000000] R10: 0000000000098000 R11: 0000000000000000 R12:
>>> 0000000000000000
>>> [    0.000000] R13: 0000000000000000 R14: 0000000000000040 R15:
>>> 0000000000000003
>>> [    0.000000] FS:  0000000000000000(0000) GS:ffffffff81ced000(0000)
>>> knlGS:0000000000000000
>>> [    0.000000] CS:  e033 DS: 0000 ES: 0000 CR0: 0000000080050033
>>> [    0.000000] CR2: 0000000000000000 CR3: 0000000001c05000 CR4:
>>> 0000000000000660
>>> [    0.000000] DR0: 0000000000000000 DR1: 0000000000000000 DR2:
>>> 0000000000000000
>>> [    0.000000] DR3: 0000000000000000 DR6: 0000000000000000 DR7:
>>> 0000000000000000
>>> [    0.000000] Process swapper (pid: 0, threadinfo ffffffff81c00000,
>>> task ffffffff81c0d020)
>>> [    0.000000] Stack:
>>> [    0.000000]  00000000000000c0 0000000000000003 0000000000000000
>>> 000000000000003f
>>> [    0.000000]  ffffffff81c01e68 ffffffff81d23024 0000000000400000
>>> 0000000000000002
>>> [    0.000000]  0000000000080000 ffff8801f055e000 ffff8801f055e1f8
>>> 0000000000000000
>>> [    0.000000] Call Trace:
>>> [    0.000000]  [<ffffffff81d23024>]
>>> sparse_early_usemaps_alloc_node+0x64/0x178
>>> [    0.000000]  [<ffffffff81d23348>] sparse_init+0xe4/0x25a
>>> [    0.000000]  [<ffffffff81d16840>] paging_init+0x13/0x22
>>> [    0.000000]  [<ffffffff81d07fbb>] setup_arch+0x9c6/0xa9b
>>> [    0.000000]  [<ffffffff81683954>] ? printk+0x3c/0x3e
>>> [    0.000000]  [<ffffffff81d01a38>] start_kernel+0xe5/0x468
>>> [    0.000000]  [<ffffffff81d012cf>] x86_64_start_reservations+0xba/0xc1
>>> [    0.000000]  [<ffffffff81007153>] ? xen_setup_runstate_info+0x2c/0x36
>>> [    0.000000]  [<ffffffff81d050ee>] xen_start_kernel+0x565/0x56c
>>> [    0.000000] Code: 79 bc 3e ff 85 c0 74 23 80 3d 19 e9 21 00 00 75 59
>>> be 2a
>>> 01 00 00 48 c7 c7 d0 55 a8 81 e8 b6 dc 31 ff c6 05 ff e8 21 00 01 eb 3f
>>> <41>  8b
>>> bc 24 60 60 02 00 49 83 c8 ff 4c 89 e9 4c 89 f2 48 89 de
>>> [    0.000000] RIP  [<ffffffff81d220e6>] __alloc_bootmem_node+0x43/0x96
>>> [    0.000000]  RSP<ffffffff81c01de8>
>>> [    0.000000] CR2: 0000000000000000
>>> [    0.000000] ---[ end trace a7919e7f17c0a725 ]---
>>> [    0.000000] Kernel panic - not syncing: Attempted to kill the idle task!
>>> (XEN) Domain 0 crashed: 'noreboot' set - not rebooting.
>>>
>>>
>>>
>>> The obvious solution would be to explicitly deny northbridge scanning
>>> when running as Dom0, though I am not sure how to implement this without
>>> upsetting the other kernel folks about "that crappy Xen thing" again ;-)
>>
>> Heh.
>> Is there a numa=0 option that could be used to override it to turn it
>> off?
>
> Not compile tested.. but was thinking something like this:
>
> diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c
> index 43fd630..838cc1f 100644
> --- a/arch/x86/xen/setup.c
> +++ b/arch/x86/xen/setup.c
> @@ -17,6 +17,7 @@
>   #include<asm/e820.h>
>   #include<asm/setup.h>
>   #include<asm/acpi.h>
> +#include<asm/numa.h>
>   #include<asm/xen/hypervisor.h>
>   #include<asm/xen/hypercall.h>
>
> @@ -528,4 +529,7 @@ void __init xen_arch_setup(void)
>   	disable_cpufreq();
>   	WARN_ON(set_pm_idle_to_default());
>   	fiddle_vdso();
> +#ifdef CONFIG_NUMA
> +	numa_off = 1;
> +#endif
>   }
>

Acked-by: Andre Przywara <andre.przywara@amd.com>

I compiled and boot-tested this on my (single node ;-) test box.
First bare-metal, dmesg: No NUMA configuration found
Then again, but with numa=off on the cmd-line: NUMA turned off
Then under Xen as Dom0 kernel: NUMA turned off

So the code behaves under Xen as one would have explicitly specified 
numa=off, which is what we want.
I couldn't get hold of the test machine (old K8 server) that the bug was 
once triggered, that's why I'm reluctant to give my Tested-by.
Will try this ASAP.

Regards,
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 Fri Sep 21 17:48:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Sep 2012 17: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 1TF7KX-00077M-KJ; Fri, 21 Sep 2012 17:47:57 +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 1TF7KV-00077G-QE
	for xen-devel@lists.xen.org; Fri, 21 Sep 2012 17:47:56 +0000
Received: from [85.158.143.99:58750] by server-2.bemta-4.messagelabs.com id
	F8/F4-06610-B48AC505; Fri, 21 Sep 2012 17:47:55 +0000
X-Env-Sender: Andre.Przywara@amd.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1348249673!30710119!1
X-Originating-IP: [216.32.180.30]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5320 invoked from network); 21 Sep 2012 17:47:54 -0000
Received: from va3ehsobe010.messaging.microsoft.com (HELO
	va3outboundpool.messaging.microsoft.com) (216.32.180.30)
	by server-3.tower-216.messagelabs.com with AES128-SHA encrypted SMTP;
	21 Sep 2012 17:47:54 -0000
Received: from mail148-va3-R.bigfish.com (10.7.14.249) by
	VA3EHSOBE005.bigfish.com (10.7.40.25) with Microsoft SMTP Server id
	14.1.225.23; Fri, 21 Sep 2012 17:47:52 +0000
Received: from mail148-va3 (localhost [127.0.0.1])	by
	mail148-va3-R.bigfish.com (Postfix) with ESMTP id BE7274C0242;
	Fri, 21 Sep 2012 17:47: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: -2
X-BigFish: VPS-2(z551bizbb2dI98dI9371I1432Id6eahd6f1izz1202h1d1ah1d2ahzz8275bhz2dh668h839hd25he5bhf0ah107ah1288h12a5h12a9h12bdh137ah1155h)
Received: from mail148-va3 (localhost.localdomain [127.0.0.1]) by mail148-va3
	(MessageSwitch) id 1348249670623187_9835;
	Fri, 21 Sep 2012 17:47:50 +0000 (UTC)
Received: from VA3EHSMHS029.bigfish.com (unknown [10.7.14.238])	by
	mail148-va3.bigfish.com (Postfix) with ESMTP id 95B6F3E0172;
	Fri, 21 Sep 2012 17:47:50 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	VA3EHSMHS029.bigfish.com (10.7.99.39) with Microsoft SMTP Server id
	14.1.225.23; Fri, 21 Sep 2012 17:47:49 +0000
X-WSS-ID: 0MAPO3L-02-N5R-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 2D3E3C8007;	Fri, 21 Sep 2012 12:47:44 -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;
	Fri, 21 Sep 2012 12:48:07 -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;
	Fri, 21 Sep 2012 12:47:46 -0500
Received: from [10.224.148.43] (10.224.148.43) by storexhtp02.amd.com
	(172.24.4.4) with Microsoft SMTP Server id 8.3.213.0; Fri, 21 Sep 2012
	13:47:45 -0400
Message-ID: <505CA8AB.6000808@amd.com>
Date: Fri, 21 Sep 2012 19:49:31 +0200
From: Andre Przywara <andre.przywara@amd.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.26) Gecko/20120131 Lightning/1.0b2 Thunderbird/3.1.18
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
References: <501BC20F.3040205@amd.com>
	<20120803123628.GB10670@andromeda.dapyr.net>
	<20120817142237.GA8467@phenom.dumpdata.com>
In-Reply-To: <20120817142237.GA8467@phenom.dumpdata.com>
X-OriginatorOrg: amd.com
Cc: Konrad Rzeszutek Wilk <konrad@darnok.org>,
	Jeremy Fitzhardinge <jeremy@goop.org>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Dom0 crash with old style AMD NUMA detection
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-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/17/2012 04:22 PM, Konrad Rzeszutek Wilk wrote:
> On Fri, Aug 03, 2012 at 08:36:28AM -0400, Konrad Rzeszutek Wilk wrote:
>> On Fri, Aug 03, 2012 at 02:20:31PM +0200, Andre Przywara wrote:

Sorry Konrad, almost forgot.
Comment (and Ack) below...

>>> we see Dom0 crashes due to the kernel detecting the NUMA topology not by
>>> ACPI, but directly from the northbridge (CONFIG_AMD_NUMA).
>>>
>>> This will detect the actual NUMA config of the physical machine, but
>>> will crash about the mismatch with Dom0's virtual memory. Variation of
>>> the theme: Dom0 sees what it's not supposed to see.
>>>
>>> This happens with the said config option enabled and on a machine where
>>> this scanning is still enabled (K8 and Fam10h, not Bulldozer class)
>>>
>>> We have this dump then:
>>> [    0.000000] NUMA: Warning: node ids are out of bound, from=-1 to=-1
>>> distance=10
>>> [    0.000000] Scanning NUMA topology in Northbridge 24
>>> [    0.000000] Number of physical nodes 4
>>> [    0.000000] Node 0 MemBase 0000000000000000 Limit 0000000040000000
>>> [    0.000000] Node 1 MemBase 0000000040000000 Limit 0000000138000000
>>> [    0.000000] Node 2 MemBase 0000000138000000 Limit 00000001f8000000
>>> [    0.000000] Node 3 MemBase 00000001f8000000 Limit 0000000238000000
>>> [    0.000000] Initmem setup node 0 0000000000000000-0000000040000000
>>> [    0.000000]   NODE_DATA [000000003ffd9000 - 000000003fffffff]
>>> [    0.000000] Initmem setup node 1 0000000040000000-0000000138000000
>>> [    0.000000]   NODE_DATA [0000000137fd9000 - 0000000137ffffff]
>>> [    0.000000] Initmem setup node 2 0000000138000000-00000001f8000000
>>> [    0.000000]   NODE_DATA [00000001f095e000 - 00000001f0984fff]
>>> [    0.000000] Initmem setup node 3 00000001f8000000-0000000238000000
>>> [    0.000000] Cannot find 159744 bytes in node 3
>>> [    0.000000] BUG: unable to handle kernel NULL pointer dereference at
>>> (null)
>>> [    0.000000] IP: [<ffffffff81d220e6>] __alloc_bootmem_node+0x43/0x96
>>> [    0.000000] PGD 0
>>> [    0.000000] Oops: 0000 [#1] SMP
>>> [    0.000000] CPU 0
>>> [    0.000000] Modules linked in:
>>> [    0.000000]
>>> [    0.000000] Pid: 0, comm: swapper Not tainted 3.3.6 #1 AMD Dinar/Dinar
>>> [    0.000000] RIP: e030:[<ffffffff81d220e6>]  [<ffffffff81d220e6>]
>>> __alloc_bootmem_node+0x43/0x96
>>> [    0.000000] RSP: e02b:ffffffff81c01de8  EFLAGS: 00010046
>>> [    0.000000] RAX: 0000000000000000 RBX: 00000000000000c0 RCX:
>>> 0000000000000000
>>> [    0.000000] RDX: 0000000000000040 RSI: 00000000000000c0 RDI:
>>> 0000000000000000
>>> [    0.000000] RBP: ffffffff81c01e08 R08: 0000000000000000 R09:
>>> 0000000000000000
>>> [    0.000000] R10: 0000000000098000 R11: 0000000000000000 R12:
>>> 0000000000000000
>>> [    0.000000] R13: 0000000000000000 R14: 0000000000000040 R15:
>>> 0000000000000003
>>> [    0.000000] FS:  0000000000000000(0000) GS:ffffffff81ced000(0000)
>>> knlGS:0000000000000000
>>> [    0.000000] CS:  e033 DS: 0000 ES: 0000 CR0: 0000000080050033
>>> [    0.000000] CR2: 0000000000000000 CR3: 0000000001c05000 CR4:
>>> 0000000000000660
>>> [    0.000000] DR0: 0000000000000000 DR1: 0000000000000000 DR2:
>>> 0000000000000000
>>> [    0.000000] DR3: 0000000000000000 DR6: 0000000000000000 DR7:
>>> 0000000000000000
>>> [    0.000000] Process swapper (pid: 0, threadinfo ffffffff81c00000,
>>> task ffffffff81c0d020)
>>> [    0.000000] Stack:
>>> [    0.000000]  00000000000000c0 0000000000000003 0000000000000000
>>> 000000000000003f
>>> [    0.000000]  ffffffff81c01e68 ffffffff81d23024 0000000000400000
>>> 0000000000000002
>>> [    0.000000]  0000000000080000 ffff8801f055e000 ffff8801f055e1f8
>>> 0000000000000000
>>> [    0.000000] Call Trace:
>>> [    0.000000]  [<ffffffff81d23024>]
>>> sparse_early_usemaps_alloc_node+0x64/0x178
>>> [    0.000000]  [<ffffffff81d23348>] sparse_init+0xe4/0x25a
>>> [    0.000000]  [<ffffffff81d16840>] paging_init+0x13/0x22
>>> [    0.000000]  [<ffffffff81d07fbb>] setup_arch+0x9c6/0xa9b
>>> [    0.000000]  [<ffffffff81683954>] ? printk+0x3c/0x3e
>>> [    0.000000]  [<ffffffff81d01a38>] start_kernel+0xe5/0x468
>>> [    0.000000]  [<ffffffff81d012cf>] x86_64_start_reservations+0xba/0xc1
>>> [    0.000000]  [<ffffffff81007153>] ? xen_setup_runstate_info+0x2c/0x36
>>> [    0.000000]  [<ffffffff81d050ee>] xen_start_kernel+0x565/0x56c
>>> [    0.000000] Code: 79 bc 3e ff 85 c0 74 23 80 3d 19 e9 21 00 00 75 59
>>> be 2a
>>> 01 00 00 48 c7 c7 d0 55 a8 81 e8 b6 dc 31 ff c6 05 ff e8 21 00 01 eb 3f
>>> <41>  8b
>>> bc 24 60 60 02 00 49 83 c8 ff 4c 89 e9 4c 89 f2 48 89 de
>>> [    0.000000] RIP  [<ffffffff81d220e6>] __alloc_bootmem_node+0x43/0x96
>>> [    0.000000]  RSP<ffffffff81c01de8>
>>> [    0.000000] CR2: 0000000000000000
>>> [    0.000000] ---[ end trace a7919e7f17c0a725 ]---
>>> [    0.000000] Kernel panic - not syncing: Attempted to kill the idle task!
>>> (XEN) Domain 0 crashed: 'noreboot' set - not rebooting.
>>>
>>>
>>>
>>> The obvious solution would be to explicitly deny northbridge scanning
>>> when running as Dom0, though I am not sure how to implement this without
>>> upsetting the other kernel folks about "that crappy Xen thing" again ;-)
>>
>> Heh.
>> Is there a numa=0 option that could be used to override it to turn it
>> off?
>
> Not compile tested.. but was thinking something like this:
>
> diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c
> index 43fd630..838cc1f 100644
> --- a/arch/x86/xen/setup.c
> +++ b/arch/x86/xen/setup.c
> @@ -17,6 +17,7 @@
>   #include<asm/e820.h>
>   #include<asm/setup.h>
>   #include<asm/acpi.h>
> +#include<asm/numa.h>
>   #include<asm/xen/hypervisor.h>
>   #include<asm/xen/hypercall.h>
>
> @@ -528,4 +529,7 @@ void __init xen_arch_setup(void)
>   	disable_cpufreq();
>   	WARN_ON(set_pm_idle_to_default());
>   	fiddle_vdso();
> +#ifdef CONFIG_NUMA
> +	numa_off = 1;
> +#endif
>   }
>

Acked-by: Andre Przywara <andre.przywara@amd.com>

I compiled and boot-tested this on my (single node ;-) test box.
First bare-metal, dmesg: No NUMA configuration found
Then again, but with numa=off on the cmd-line: NUMA turned off
Then under Xen as Dom0 kernel: NUMA turned off

So the code behaves under Xen as one would have explicitly specified 
numa=off, which is what we want.
I couldn't get hold of the test machine (old K8 server) that the bug was 
once triggered, that's why I'm reluctant to give my Tested-by.
Will try this ASAP.

Regards,
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 Fri Sep 21 18:00:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Sep 2012 18:00:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TF7Vy-0007Zd-Fe; Fri, 21 Sep 2012 17:59:46 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ketuzsezr@gmail.com>) id 1TF7Vx-0007ZX-9w
	for xen-devel@lists.xen.org; Fri, 21 Sep 2012 17:59:45 +0000
Received: from [85.158.143.99:24188] by server-3.bemta-4.messagelabs.com id
	86/A0-10986-01BAC505; Fri, 21 Sep 2012 17:59:44 +0000
X-Env-Sender: ketuzsezr@gmail.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1348250382!26016073!1
X-Originating-IP: [209.85.216.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15108 invoked from network); 21 Sep 2012 17:59:43 -0000
Received: from mail-qc0-f173.google.com (HELO mail-qc0-f173.google.com)
	(209.85.216.173)
	by server-4.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Sep 2012 17:59:43 -0000
Received: by qcab12 with SMTP id b12so3617331qca.32
	for <xen-devel@lists.xen.org>; Fri, 21 Sep 2012 10:59:42 -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=ZOza0TliaPz+6EHXRvsMFppHAY6wHy5UPUenV96WSbc=;
	b=Dq2MXD4w5vjHItJyGHNQa2CPYMwVR1SVVvgDq047ow1Q7LrUw2LtrJo6gZFdXbDyMt
	Gur2LBMOgkoBlc23kKFqyNfPicQzVn/8vpSbF2E2eg7JyB8DDfupCrlZdeb31r136qkV
	7CULuwSkLr5ly5wDDTQKsub8hgD5/CivjPD9PhW9wvJFzi+ah1qBZZ4KbKzwCfGSlFy+
	SE8vPA+3Nl04p/NHE+OpuqxjJI7TO4mc0JWETdfMPw4LNrnxogrkbAZ9YYWByrocetim
	M13MkUdnadZmjTNivsqvQq/adB0P9awXKG5XfOVoo+l4unE6RpKIUuXk0dAqfgF9mR3B
	fxJw==
Received: by 10.224.52.139 with SMTP id i11mr14128802qag.11.1348250382307;
	Fri, 21 Sep 2012 10:59:42 -0700 (PDT)
Received: from phenom.dumpdata.com
	(50-195-21-189-static.hfc.comcastbusiness.net. [50.195.21.189])
	by mx.google.com with ESMTPS id b5sm9247842qao.13.2012.09.21.10.59.41
	(version=TLSv1/SSLv3 cipher=OTHER);
	Fri, 21 Sep 2012 10:59:41 -0700 (PDT)
Date: Fri, 21 Sep 2012 13:48:34 -0400
From: Konrad Rzeszutek Wilk <konrad@kernel.org>
To: Andre Przywara <andre.przywara@amd.com>
Message-ID: <20120921174833.GC6821@phenom.dumpdata.com>
References: <501BC20F.3040205@amd.com>
	<20120803123628.GB10670@andromeda.dapyr.net>
	<20120817142237.GA8467@phenom.dumpdata.com>
	<505CA8AB.6000808@amd.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <505CA8AB.6000808@amd.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: Konrad Rzeszutek Wilk <konrad@darnok.org>,
	Jeremy Fitzhardinge <jeremy@goop.org>, xen-devel <xen-devel@lists.xen.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] Dom0 crash with old style AMD NUMA detection
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> Acked-by: Andre Przywara <andre.przywara@amd.com>
> 
> I compiled and boot-tested this on my (single node ;-) test box.
> First bare-metal, dmesg: No NUMA configuration found
> Then again, but with numa=off on the cmd-line: NUMA turned off
> Then under Xen as Dom0 kernel: NUMA turned off
> 
> So the code behaves under Xen as one would have explicitly specified
> numa=off, which is what we want.

Right.
> I couldn't get hold of the test machine (old K8 server) that the bug
> was once triggered, that's why I'm reluctant to give my Tested-by.
> Will try this ASAP.

OK, will wait with this - it would be a bit silly if the patch did not
fix the issue :-)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 21 18:00:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Sep 2012 18:00:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TF7Vy-0007Zd-Fe; Fri, 21 Sep 2012 17:59:46 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ketuzsezr@gmail.com>) id 1TF7Vx-0007ZX-9w
	for xen-devel@lists.xen.org; Fri, 21 Sep 2012 17:59:45 +0000
Received: from [85.158.143.99:24188] by server-3.bemta-4.messagelabs.com id
	86/A0-10986-01BAC505; Fri, 21 Sep 2012 17:59:44 +0000
X-Env-Sender: ketuzsezr@gmail.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1348250382!26016073!1
X-Originating-IP: [209.85.216.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15108 invoked from network); 21 Sep 2012 17:59:43 -0000
Received: from mail-qc0-f173.google.com (HELO mail-qc0-f173.google.com)
	(209.85.216.173)
	by server-4.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Sep 2012 17:59:43 -0000
Received: by qcab12 with SMTP id b12so3617331qca.32
	for <xen-devel@lists.xen.org>; Fri, 21 Sep 2012 10:59:42 -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=ZOza0TliaPz+6EHXRvsMFppHAY6wHy5UPUenV96WSbc=;
	b=Dq2MXD4w5vjHItJyGHNQa2CPYMwVR1SVVvgDq047ow1Q7LrUw2LtrJo6gZFdXbDyMt
	Gur2LBMOgkoBlc23kKFqyNfPicQzVn/8vpSbF2E2eg7JyB8DDfupCrlZdeb31r136qkV
	7CULuwSkLr5ly5wDDTQKsub8hgD5/CivjPD9PhW9wvJFzi+ah1qBZZ4KbKzwCfGSlFy+
	SE8vPA+3Nl04p/NHE+OpuqxjJI7TO4mc0JWETdfMPw4LNrnxogrkbAZ9YYWByrocetim
	M13MkUdnadZmjTNivsqvQq/adB0P9awXKG5XfOVoo+l4unE6RpKIUuXk0dAqfgF9mR3B
	fxJw==
Received: by 10.224.52.139 with SMTP id i11mr14128802qag.11.1348250382307;
	Fri, 21 Sep 2012 10:59:42 -0700 (PDT)
Received: from phenom.dumpdata.com
	(50-195-21-189-static.hfc.comcastbusiness.net. [50.195.21.189])
	by mx.google.com with ESMTPS id b5sm9247842qao.13.2012.09.21.10.59.41
	(version=TLSv1/SSLv3 cipher=OTHER);
	Fri, 21 Sep 2012 10:59:41 -0700 (PDT)
Date: Fri, 21 Sep 2012 13:48:34 -0400
From: Konrad Rzeszutek Wilk <konrad@kernel.org>
To: Andre Przywara <andre.przywara@amd.com>
Message-ID: <20120921174833.GC6821@phenom.dumpdata.com>
References: <501BC20F.3040205@amd.com>
	<20120803123628.GB10670@andromeda.dapyr.net>
	<20120817142237.GA8467@phenom.dumpdata.com>
	<505CA8AB.6000808@amd.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <505CA8AB.6000808@amd.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: Konrad Rzeszutek Wilk <konrad@darnok.org>,
	Jeremy Fitzhardinge <jeremy@goop.org>, xen-devel <xen-devel@lists.xen.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] Dom0 crash with old style AMD NUMA detection
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> Acked-by: Andre Przywara <andre.przywara@amd.com>
> 
> I compiled and boot-tested this on my (single node ;-) test box.
> First bare-metal, dmesg: No NUMA configuration found
> Then again, but with numa=off on the cmd-line: NUMA turned off
> Then under Xen as Dom0 kernel: NUMA turned off
> 
> So the code behaves under Xen as one would have explicitly specified
> numa=off, which is what we want.

Right.
> I couldn't get hold of the test machine (old K8 server) that the bug
> was once triggered, that's why I'm reluctant to give my Tested-by.
> Will try this ASAP.

OK, will wait with this - it would be a bit silly if the patch did not
fix the issue :-)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 21 18:21:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Sep 2012 18: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 1TF7qE-0008C9-UK; Fri, 21 Sep 2012 18:20:42 +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 1TF7qD-0008C3-L3
	for xen-devel@lists.xen.org; Fri, 21 Sep 2012 18:20:41 +0000
Received: from [85.158.139.83:2444] by server-8.bemta-5.messagelabs.com id
	33/3D-30083-8FFAC505; Fri, 21 Sep 2012 18:20:40 +0000
X-Env-Sender: ben.guthro@gmail.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1348251636!31055101!1
X-Originating-IP: [209.85.223.173]
X-SpamReason: No, hits=0.9 required=7.0 tests=BODY_RANDOM_LONG,
	HTML_30_40,HTML_MESSAGE,RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32522 invoked from network); 21 Sep 2012 18:20:38 -0000
Received: from mail-ie0-f173.google.com (HELO mail-ie0-f173.google.com)
	(209.85.223.173)
	by server-13.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Sep 2012 18:20:38 -0000
Received: by iea17 with SMTP id 17so2191091iea.32
	for <xen-devel@lists.xen.org>; Fri, 21 Sep 2012 11:20: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=trNu6hEYqv178BxH9U4aZ9xSYKSnL4MlRUjvQhi3P4o=;
	b=ZJKufMK9zwGSyuCWDDIeJ4PblLY30ZmfjKEF6bM7dN5nvC/8MgMDxqtWblTAIbCypy
	f3rC9bL8ozooe2Vxb2oW2oWmAodwFIn/KMNC2UVI1qMR8wBY/2Sw8LwyukXTsXEv7Oq1
	RyeUn/WnOIAh5ksCVqBkG6LUf/T8F0SPSPT+pZ44Ify9tn6j0Lsd1Uz8fCKJ32P6qK86
	2Tb9qS+9TLlFRlMlDceVTv9mLR8CWgCtdYTVfGvzvb4oMsMpcXQqwNdjN93Iyg6fKB3W
	APCgsndR/pXul3rIbclFN21ZvrgSOrZIvhA8SmVKahhlB8Fw25/Qp6kFuBeZkZjdWMIs
	abtg==
MIME-Version: 1.0
Received: by 10.50.106.233 with SMTP id gx9mr2413167igb.49.1348251636473; Fri,
	21 Sep 2012 11:20:36 -0700 (PDT)
Received: by 10.64.55.132 with HTTP; Fri, 21 Sep 2012 11:20:36 -0700 (PDT)
In-Reply-To: <505C29B3020000780009CDA2@nat28.tlf.novell.com>
References: <CAOvdn6Xn1ZnontBO0KoJE9hgBsW-a1rR2EhWYEpgbbrELkXZNw@mail.gmail.com>
	<CC80728B.3F362%keir.xen@gmail.com>
	<505AE9DB020000780009C813@nat28.tlf.novell.com>
	<CAOvdn6VF+1KP0EkzwkoAEoc=B2bcLUWteOM8HmN-cj_YosN-pw@mail.gmail.com>
	<CAOvdn6XFy_Teo0x8rBYvY1j+=ZEDAeE4bZ359nVOtgUyb=ZJig@mail.gmail.com>
	<505C29B3020000780009CDA2@nat28.tlf.novell.com>
Date: Fri, 21 Sep 2012 14:20:36 -0400
X-Google-Sender-Auth: 0-GKm9Ufkr16W4C39QXlCzQBcf4
Message-ID: <CAOvdn6XKPOMNn6AjuYvZvPXRRJffN3po5GXe1Yh1-m0hisMK_w@mail.gmail.com>
From: Ben Guthro <ben@guthro.net>
To: Jan Beulich <JBeulich@suse.com>
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Keir Fraser <keir.xen@gmail.com>, john.baboval@citrix.com,
	Thomas Goetz <thomas.goetz@citrix.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen4.2 S3 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: multipart/mixed; boundary="===============1632004108630714376=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============1632004108630714376==
Content-Type: multipart/alternative; boundary=e89a8f2343b3dc1f9404ca3a4bcb

--e89a8f2343b3dc1f9404ca3a4bcb
Content-Type: text/plain; charset=ISO-8859-1

On Fri, Sep 21, 2012 at 2:47 AM, Jan Beulich <JBeulich@suse.com> wrote:

>
> That's because CPU1 is stuck in cpu_init() (in the infinite loop after
> printing "CPU#1 already initialized!"), as Keir pointed out yesterday.
>
>
I've done some more tracing on this, and instrumented cpu_init(),
cpu_uninit() - and found something I cannot quite explain.
I was most interested in the cpu_initialized mask, set just above these two
functions (and only used in those two functions)

I convert  cpu_initialized to a string, using cpumask_scnprintf - and print
it out when it is read, or written in these two functions.

When CPU1 is being torn down, the cpumask bit gets cleared for CPU1, and I
am able to print this to the console to verify.
However, when the machine is returning from S3, and going through cpu_init
- the bit is set again.

Could this be an issue of caches not being flushed?

I see that the last thing done before acpi_enter_sleep_state actually
writes PM1A_CONTROL / PM1B_CONTROL to enter S3 is a ACPI_FLUSH_CPU_CACHE()

This analysis seems unlikely, at this point...but I'm not sure what to make
of the data other than a cache issue.

Am I "barking up the wrong tree" here?

--e89a8f2343b3dc1f9404ca3a4bcb
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br><br><div class=3D"gmail_quote">On Fri, Sep 21, 2012 at 2:47 AM, Jan Beu=
lich <span dir=3D"ltr">&lt;<a href=3D"mailto:JBeulich@suse.com" target=3D"_=
blank">JBeulich@suse.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmai=
l_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left=
:1ex">
<div class=3D"im"><br></div>That&#39;s because CPU1 is stuck in cpu_init() =
(in the infinite loop after<br>
printing &quot;CPU#1 already initialized!&quot;), as Keir pointed out yeste=
rday.<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br></font></span></blockquo=
te><div><br></div><div>I&#39;ve done some more tracing on this, and instrum=
ented cpu_init(), cpu_uninit() - and found something I cannot quite explain=
.</div>
<div>I was most interested in the cpu_initialized mask, set just above thes=
e two functions (and only used in those two functions)</div><div><br></div>=
<div>I convert =A0cpu_initialized to a string, using=A0cpumask_scnprintf - =
and print it out when it is read, or written in these two functions.</div>
<div><br></div><div>When CPU1 is being torn down, the cpumask bit gets clea=
red for CPU1, and I am able to print this to the console to verify.</div><d=
iv>However, when the machine is returning from S3, and going through cpu_in=
it - the bit is set again.</div>
<div><br></div><div>Could this be an issue of caches not being flushed?</di=
v><div><br></div><div>I see that the last thing done before=A0acpi_enter_sl=
eep_state actually writes=A0PM1A_CONTROL /=A0PM1B_CONTROL to enter S3 is a=
=A0ACPI_FLUSH_CPU_CACHE()</div>
<div><br></div><div>This analysis seems unlikely, at this point...but I&#39=
;m not sure what to make of the data other than a cache issue.</div><div><b=
r></div><div>Am I &quot;barking up the wrong tree&quot; here?</div><div>
<br></div></div>

--e89a8f2343b3dc1f9404ca3a4bcb--


--===============1632004108630714376==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============1632004108630714376==--


From xen-devel-bounces@lists.xen.org Fri Sep 21 18:21:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Sep 2012 18: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 1TF7qE-0008C9-UK; Fri, 21 Sep 2012 18:20:42 +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 1TF7qD-0008C3-L3
	for xen-devel@lists.xen.org; Fri, 21 Sep 2012 18:20:41 +0000
Received: from [85.158.139.83:2444] by server-8.bemta-5.messagelabs.com id
	33/3D-30083-8FFAC505; Fri, 21 Sep 2012 18:20:40 +0000
X-Env-Sender: ben.guthro@gmail.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1348251636!31055101!1
X-Originating-IP: [209.85.223.173]
X-SpamReason: No, hits=0.9 required=7.0 tests=BODY_RANDOM_LONG,
	HTML_30_40,HTML_MESSAGE,RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32522 invoked from network); 21 Sep 2012 18:20:38 -0000
Received: from mail-ie0-f173.google.com (HELO mail-ie0-f173.google.com)
	(209.85.223.173)
	by server-13.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Sep 2012 18:20:38 -0000
Received: by iea17 with SMTP id 17so2191091iea.32
	for <xen-devel@lists.xen.org>; Fri, 21 Sep 2012 11:20: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=trNu6hEYqv178BxH9U4aZ9xSYKSnL4MlRUjvQhi3P4o=;
	b=ZJKufMK9zwGSyuCWDDIeJ4PblLY30ZmfjKEF6bM7dN5nvC/8MgMDxqtWblTAIbCypy
	f3rC9bL8ozooe2Vxb2oW2oWmAodwFIn/KMNC2UVI1qMR8wBY/2Sw8LwyukXTsXEv7Oq1
	RyeUn/WnOIAh5ksCVqBkG6LUf/T8F0SPSPT+pZ44Ify9tn6j0Lsd1Uz8fCKJ32P6qK86
	2Tb9qS+9TLlFRlMlDceVTv9mLR8CWgCtdYTVfGvzvb4oMsMpcXQqwNdjN93Iyg6fKB3W
	APCgsndR/pXul3rIbclFN21ZvrgSOrZIvhA8SmVKahhlB8Fw25/Qp6kFuBeZkZjdWMIs
	abtg==
MIME-Version: 1.0
Received: by 10.50.106.233 with SMTP id gx9mr2413167igb.49.1348251636473; Fri,
	21 Sep 2012 11:20:36 -0700 (PDT)
Received: by 10.64.55.132 with HTTP; Fri, 21 Sep 2012 11:20:36 -0700 (PDT)
In-Reply-To: <505C29B3020000780009CDA2@nat28.tlf.novell.com>
References: <CAOvdn6Xn1ZnontBO0KoJE9hgBsW-a1rR2EhWYEpgbbrELkXZNw@mail.gmail.com>
	<CC80728B.3F362%keir.xen@gmail.com>
	<505AE9DB020000780009C813@nat28.tlf.novell.com>
	<CAOvdn6VF+1KP0EkzwkoAEoc=B2bcLUWteOM8HmN-cj_YosN-pw@mail.gmail.com>
	<CAOvdn6XFy_Teo0x8rBYvY1j+=ZEDAeE4bZ359nVOtgUyb=ZJig@mail.gmail.com>
	<505C29B3020000780009CDA2@nat28.tlf.novell.com>
Date: Fri, 21 Sep 2012 14:20:36 -0400
X-Google-Sender-Auth: 0-GKm9Ufkr16W4C39QXlCzQBcf4
Message-ID: <CAOvdn6XKPOMNn6AjuYvZvPXRRJffN3po5GXe1Yh1-m0hisMK_w@mail.gmail.com>
From: Ben Guthro <ben@guthro.net>
To: Jan Beulich <JBeulich@suse.com>
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Keir Fraser <keir.xen@gmail.com>, john.baboval@citrix.com,
	Thomas Goetz <thomas.goetz@citrix.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen4.2 S3 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: multipart/mixed; boundary="===============1632004108630714376=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============1632004108630714376==
Content-Type: multipart/alternative; boundary=e89a8f2343b3dc1f9404ca3a4bcb

--e89a8f2343b3dc1f9404ca3a4bcb
Content-Type: text/plain; charset=ISO-8859-1

On Fri, Sep 21, 2012 at 2:47 AM, Jan Beulich <JBeulich@suse.com> wrote:

>
> That's because CPU1 is stuck in cpu_init() (in the infinite loop after
> printing "CPU#1 already initialized!"), as Keir pointed out yesterday.
>
>
I've done some more tracing on this, and instrumented cpu_init(),
cpu_uninit() - and found something I cannot quite explain.
I was most interested in the cpu_initialized mask, set just above these two
functions (and only used in those two functions)

I convert  cpu_initialized to a string, using cpumask_scnprintf - and print
it out when it is read, or written in these two functions.

When CPU1 is being torn down, the cpumask bit gets cleared for CPU1, and I
am able to print this to the console to verify.
However, when the machine is returning from S3, and going through cpu_init
- the bit is set again.

Could this be an issue of caches not being flushed?

I see that the last thing done before acpi_enter_sleep_state actually
writes PM1A_CONTROL / PM1B_CONTROL to enter S3 is a ACPI_FLUSH_CPU_CACHE()

This analysis seems unlikely, at this point...but I'm not sure what to make
of the data other than a cache issue.

Am I "barking up the wrong tree" here?

--e89a8f2343b3dc1f9404ca3a4bcb
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br><br><div class=3D"gmail_quote">On Fri, Sep 21, 2012 at 2:47 AM, Jan Beu=
lich <span dir=3D"ltr">&lt;<a href=3D"mailto:JBeulich@suse.com" target=3D"_=
blank">JBeulich@suse.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmai=
l_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left=
:1ex">
<div class=3D"im"><br></div>That&#39;s because CPU1 is stuck in cpu_init() =
(in the infinite loop after<br>
printing &quot;CPU#1 already initialized!&quot;), as Keir pointed out yeste=
rday.<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br></font></span></blockquo=
te><div><br></div><div>I&#39;ve done some more tracing on this, and instrum=
ented cpu_init(), cpu_uninit() - and found something I cannot quite explain=
.</div>
<div>I was most interested in the cpu_initialized mask, set just above thes=
e two functions (and only used in those two functions)</div><div><br></div>=
<div>I convert =A0cpu_initialized to a string, using=A0cpumask_scnprintf - =
and print it out when it is read, or written in these two functions.</div>
<div><br></div><div>When CPU1 is being torn down, the cpumask bit gets clea=
red for CPU1, and I am able to print this to the console to verify.</div><d=
iv>However, when the machine is returning from S3, and going through cpu_in=
it - the bit is set again.</div>
<div><br></div><div>Could this be an issue of caches not being flushed?</di=
v><div><br></div><div>I see that the last thing done before=A0acpi_enter_sl=
eep_state actually writes=A0PM1A_CONTROL /=A0PM1B_CONTROL to enter S3 is a=
=A0ACPI_FLUSH_CPU_CACHE()</div>
<div><br></div><div>This analysis seems unlikely, at this point...but I&#39=
;m not sure what to make of the data other than a cache issue.</div><div><b=
r></div><div>Am I &quot;barking up the wrong tree&quot; here?</div><div>
<br></div></div>

--e89a8f2343b3dc1f9404ca3a4bcb--


--===============1632004108630714376==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============1632004108630714376==--


From xen-devel-bounces@lists.xen.org Fri Sep 21 18:43:02 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Sep 2012 18: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 1TF8BW-0000hC-OO; Fri, 21 Sep 2012 18:42:42 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1TF8BV-0000gZ-4W
	for xen-devel@lists.xen.org; Fri, 21 Sep 2012 18:42:41 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1348252954!4238183!1
X-Originating-IP: [209.85.215.173]
X-SpamReason: No, hits=0.4 required=7.0 tests=MIME_QP_LONG_LINE,
  RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2650 invoked from network); 21 Sep 2012 18:42:35 -0000
Received: from mail-ey0-f173.google.com (HELO mail-ey0-f173.google.com)
	(209.85.215.173)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Sep 2012 18:42:35 -0000
Received: by eaac13 with SMTP id c13so1275915eaa.32
	for <xen-devel@lists.xen.org>; Fri, 21 Sep 2012 11:42:34 -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=Q0opaXVRy7ZG+9G03mUQt2ml8DaYLsbNhq6p+ZFx1M8=;
	b=PIZqWV4bMGJGmgz9auoLd9HlfqVSTTHsFAy29exImU8FbSXJzLrwubpgE8pljw+l9P
	wY1PR5P+p/Rfw5Z8e+GBLnuOGO+eLu1YrleYEmZ7E2kXsryBcKa7DHdDVikCYiQUzfY/
	aeYRDqpGQO7w3PIbgdOdF+jEQ2nkK5x27pQgWENiORnLzPxtCGBBNQtpUxvSeXPc3gf/
	5Aujty8AFfqHccsYN+NCgmicTMg6bO86PvafEJI02wAGY/0nuXxvE84NUv6zJvZ3AOO9
	dxf6Jop6XEW74DGW5wYMkZlx+IkJijCf/n6eRKtyL0cbutFUzX8YKsA0SfBNC6q3WxCb
	gBig==
Received: by 10.14.179.200 with SMTP id h48mr7459949eem.12.1348252954394;
	Fri, 21 Sep 2012 11:42:34 -0700 (PDT)
Received: from [192.168.1.3] (host86-167-82-156.range86-167.btcentralplus.com.
	[86.167.82.156])
	by mx.google.com with ESMTPS id 46sm25906367eef.17.2012.09.21.11.42.30
	(version=SSLv3 cipher=OTHER); Fri, 21 Sep 2012 11:42:33 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.33.0.120411
Date: Fri, 21 Sep 2012 19:42:24 +0100
From: Keir Fraser <keir@xen.org>
To: Ben Guthro <ben@guthro.net>,
	Jan Beulich <JBeulich@suse.com>
Message-ID: <CC8273A0.4C9DD%keir@xen.org>
Thread-Topic: [Xen-devel] Xen4.2 S3 regression?
Thread-Index: Ac2YKNcwGGYsPt1Oo0qUjsMgLZSXZw==
In-Reply-To: <CAOvdn6XKPOMNn6AjuYvZvPXRRJffN3po5GXe1Yh1-m0hisMK_w@mail.gmail.com>
Mime-version: 1.0
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>, john.baboval@citrix.com,
	Thomas Goetz <thomas.goetz@citrix.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen4.2 S3 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="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 21/09/2012 19:20, "Ben Guthro" <ben@guthro.net> wrote:

> =

> =

> On Fri, Sep 21, 2012 at 2:47 AM, Jan Beulich <JBeulich@suse.com> wrote:
>> =

>> That's because CPU1 is stuck in cpu_init() (in the infinite loop after
>> printing "CPU#1 already initialized!"), as Keir pointed out yesterday.
>> =

> =

> I've done some more tracing on this, and instrumented cpu_init(), cpu_uni=
nit()
> - and found something I cannot quite explain.
> I was most interested in the cpu_initialized mask, set just above these t=
wo
> functions (and only used in those two functions)
> =

> I convert =A0cpu_initialized to a string, using=A0cpumask_scnprintf - and=
 print it
> out when it is read, or written in these two functions.
> =

> When CPU1 is being torn down, the cpumask bit gets cleared for CPU1, and =
I am
> able to print this to the console to verify.
> However, when the machine is returning from S3, and going through cpu_ini=
t -
> the bit is set again.
> =

> Could this be an issue of caches not being flushed?
> =

> I see that the last thing done before=A0acpi_enter_sleep_state actually
> writes=A0PM1A_CONTROL /=A0PM1B_CONTROL to enter S3 is a=A0ACPI_FLUSH_CPU_=
CACHE()
> =

> This analysis seems unlikely, at this point...but I'm not sure what to ma=
ke of
> the data other than a cache issue.
> =

> Am I "barking up the wrong tree" here?

Perhaps not. Try dumping it immediately before and after the actual S3
sleep. Since you probably can't print to serial line at that point, you
could just take a copy of the bitmap and print them both shortly after S3
resume. Then if it still looks bad, or the problem magically resolves with
the extra printing, you can suspect cache flush a bit more strongly.
However, WBINVD (which is what ACPI_FLUSH_CPU_CACHE() is) should be enough.

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 21 18:43:02 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Sep 2012 18: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 1TF8BW-0000hC-OO; Fri, 21 Sep 2012 18:42:42 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1TF8BV-0000gZ-4W
	for xen-devel@lists.xen.org; Fri, 21 Sep 2012 18:42:41 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1348252954!4238183!1
X-Originating-IP: [209.85.215.173]
X-SpamReason: No, hits=0.4 required=7.0 tests=MIME_QP_LONG_LINE,
  RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2650 invoked from network); 21 Sep 2012 18:42:35 -0000
Received: from mail-ey0-f173.google.com (HELO mail-ey0-f173.google.com)
	(209.85.215.173)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Sep 2012 18:42:35 -0000
Received: by eaac13 with SMTP id c13so1275915eaa.32
	for <xen-devel@lists.xen.org>; Fri, 21 Sep 2012 11:42:34 -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=Q0opaXVRy7ZG+9G03mUQt2ml8DaYLsbNhq6p+ZFx1M8=;
	b=PIZqWV4bMGJGmgz9auoLd9HlfqVSTTHsFAy29exImU8FbSXJzLrwubpgE8pljw+l9P
	wY1PR5P+p/Rfw5Z8e+GBLnuOGO+eLu1YrleYEmZ7E2kXsryBcKa7DHdDVikCYiQUzfY/
	aeYRDqpGQO7w3PIbgdOdF+jEQ2nkK5x27pQgWENiORnLzPxtCGBBNQtpUxvSeXPc3gf/
	5Aujty8AFfqHccsYN+NCgmicTMg6bO86PvafEJI02wAGY/0nuXxvE84NUv6zJvZ3AOO9
	dxf6Jop6XEW74DGW5wYMkZlx+IkJijCf/n6eRKtyL0cbutFUzX8YKsA0SfBNC6q3WxCb
	gBig==
Received: by 10.14.179.200 with SMTP id h48mr7459949eem.12.1348252954394;
	Fri, 21 Sep 2012 11:42:34 -0700 (PDT)
Received: from [192.168.1.3] (host86-167-82-156.range86-167.btcentralplus.com.
	[86.167.82.156])
	by mx.google.com with ESMTPS id 46sm25906367eef.17.2012.09.21.11.42.30
	(version=SSLv3 cipher=OTHER); Fri, 21 Sep 2012 11:42:33 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.33.0.120411
Date: Fri, 21 Sep 2012 19:42:24 +0100
From: Keir Fraser <keir@xen.org>
To: Ben Guthro <ben@guthro.net>,
	Jan Beulich <JBeulich@suse.com>
Message-ID: <CC8273A0.4C9DD%keir@xen.org>
Thread-Topic: [Xen-devel] Xen4.2 S3 regression?
Thread-Index: Ac2YKNcwGGYsPt1Oo0qUjsMgLZSXZw==
In-Reply-To: <CAOvdn6XKPOMNn6AjuYvZvPXRRJffN3po5GXe1Yh1-m0hisMK_w@mail.gmail.com>
Mime-version: 1.0
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>, john.baboval@citrix.com,
	Thomas Goetz <thomas.goetz@citrix.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen4.2 S3 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="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 21/09/2012 19:20, "Ben Guthro" <ben@guthro.net> wrote:

> =

> =

> On Fri, Sep 21, 2012 at 2:47 AM, Jan Beulich <JBeulich@suse.com> wrote:
>> =

>> That's because CPU1 is stuck in cpu_init() (in the infinite loop after
>> printing "CPU#1 already initialized!"), as Keir pointed out yesterday.
>> =

> =

> I've done some more tracing on this, and instrumented cpu_init(), cpu_uni=
nit()
> - and found something I cannot quite explain.
> I was most interested in the cpu_initialized mask, set just above these t=
wo
> functions (and only used in those two functions)
> =

> I convert =A0cpu_initialized to a string, using=A0cpumask_scnprintf - and=
 print it
> out when it is read, or written in these two functions.
> =

> When CPU1 is being torn down, the cpumask bit gets cleared for CPU1, and =
I am
> able to print this to the console to verify.
> However, when the machine is returning from S3, and going through cpu_ini=
t -
> the bit is set again.
> =

> Could this be an issue of caches not being flushed?
> =

> I see that the last thing done before=A0acpi_enter_sleep_state actually
> writes=A0PM1A_CONTROL /=A0PM1B_CONTROL to enter S3 is a=A0ACPI_FLUSH_CPU_=
CACHE()
> =

> This analysis seems unlikely, at this point...but I'm not sure what to ma=
ke of
> the data other than a cache issue.
> =

> Am I "barking up the wrong tree" here?

Perhaps not. Try dumping it immediately before and after the actual S3
sleep. Since you probably can't print to serial line at that point, you
could just take a copy of the bitmap and print them both shortly after S3
resume. Then if it still looks bad, or the problem magically resolves with
the extra printing, you can suspect cache flush a bit more strongly.
However, WBINVD (which is what ACPI_FLUSH_CPU_CACHE() is) should be enough.

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 21 18:50:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Sep 2012 18: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 1TF8J4-00014l-Pd; Fri, 21 Sep 2012 18:50:30 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <matthew.fioravante@jhuapl.edu>) id 1TF8J2-00014f-P7
	for xen-devel@lists.xensource.com; Fri, 21 Sep 2012 18:50:28 +0000
Received: from [85.158.138.51:37724] by server-8.bemta-3.messagelabs.com id
	53/9B-24700-4F6BC505; Fri, 21 Sep 2012 18:50:28 +0000
X-Env-Sender: matthew.fioravante@jhuapl.edu
X-Msg-Ref: server-11.tower-174.messagelabs.com!1348253425!31495360!1
X-Originating-IP: [128.244.251.36]
X-SpamReason: No, hits=0.0 required=7.0 tests=HTML_MESSAGE, UNPARSEABLE_RELAY
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9827 invoked from network); 21 Sep 2012 18:50:26 -0000
Received: from pilot.jhuapl.edu (HELO jhuapl.edu) (128.244.251.36)
	by server-11.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 21 Sep 2012 18:50:26 -0000
Received: from ([128.244.207.89])
	by pilot.jhuapl.edu with ESMTP with TLS id 63GHCH1.153408464;
	Fri, 21 Sep 2012 14:50:18 -0400
Message-ID: <505CB69D.6070203@jhuapl.edu>
Date: Fri, 21 Sep 2012 14:49:01 -0400
From: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120827 Thunderbird/15.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>, 
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
X-Enigmail-Version: 1.4.4
Subject: [Xen-devel] PATCH [base vtpm and libxl patches 0/6]
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1847460024785158106=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a cryptographically signed message in MIME format.

--===============1847460024785158106==
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms060005000704030804060404"

This is a cryptographically signed message in MIME format.

--------------ms060005000704030804060404
Content-Type: multipart/alternative;
 boundary="------------020403060403070504040206"

This is a multi-part message in MIME format.
--------------020403060403070504040206
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

So it looks like I was basing my patches off of this tree
git://xenbits.xen.org/xen-unstable.git
which is not actually xen-unstable. I rebased and reworked my patches
off of the correct tree
git://xenbits.xen.org/xen.git

What follows are the vtpmd, vtpm_manager, and libxl patches. All of the
mini-os patches apply cleanly to the latest xen so I won't be
resubmitting those unless you all would want me to.

Anyway, patches incoming..

--------------020403060403070504040206
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<html>
  <head>

    <meta http-equiv=3D"content-type" content=3D"text/html; charset=3DISO=
-8859-1">
  </head>
  <body bgcolor=3D"#FFFFFF" text=3D"#000000">
    So it looks like I was basing my patches off of this tree <span
      style=3D"color: rgb(0, 0, 0); font-family: sans-serif; font-size:
      13px; font-style: normal; font-variant: normal; font-weight:
      normal; letter-spacing: normal; line-height: normal; orphans: 2;
      text-align: -webkit-auto; text-indent: 0px; text-transform: none;
      white-space: normal; widows: 2; word-spacing: 0px;
      -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px;
      background-color: rgb(255, 255, 255); display: inline !important;
      float: none; ">git://xenbits.xen.org/xen-unstable.git </span><br>
    which is not actually xen-unstable. I rebased and reworked my
    patches off of the correct tree<br>
    <span style=3D"color: rgb(0, 0, 0); font-family: sans-serif;
      font-size: 13px; font-style: normal; font-variant: normal;
      font-weight: normal; letter-spacing: normal; line-height: normal;
      orphans: 2; text-align: -webkit-auto; text-indent: 0px;
      text-transform: none; white-space: normal; widows: 2;
      word-spacing: 0px; -webkit-text-size-adjust: auto;
      -webkit-text-stroke-width: 0px; background-color: rgb(255, 255,
      255); display: inline !important; float: none; ">git://xenbits.xen.=
org/xen.git
    </span><br>
    <br>
    What follows are the vtpmd, vtpm_manager, and libxl patches. All of
    the mini-os patches apply cleanly to the latest xen so I won't be
    resubmitting those unless you all would want me to.<br>
    <br>
    Anyway, patches incoming..<br>
    <span style=3D"color: rgb(0, 0, 0); font-family: sans-serif;
      font-size: 13px; font-style: normal; font-variant: normal;
      font-weight: normal; letter-spacing: normal; line-height: normal;
      orphans: 2; text-align: -webkit-auto; text-indent: 0px;
      text-transform: none; white-space: normal; widows: 2;
      word-spacing: 0px; -webkit-text-size-adjust: auto;
      -webkit-text-stroke-width: 0px; background-color: rgb(255, 255,
      255); display: inline !important; float: none; "></span>
  </body>
</html>

--------------020403060403070504040206--

--------------ms060005000704030804060404
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIDyjCC
A8YwggMvoAMCAQICBD/xyf0wDQYJKoZIhvcNAQEFBQAwLzELMAkGA1UEBhMCVVMxDzANBgNV
BAoTBkpIVUFQTDEPMA0GA1UECxMGQklTRENBMB4XDTEwMDYxMTE4MjIwNloXDTEzMDYxMTE4
NTIwNlowZjELMAkGA1UEBhMCVVMxDzANBgNVBAoTBkpIVUFQTDEPMA0GA1UECxMGUGVvcGxl
MTUwFgYDVQQLEw9WUE5Hcm91cC1CSVNEQ0EwGwYDVQQDExRNYXR0aGV3IEUgRmlvcmF2YW50
ZTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAnpbwVSP6o1Nb5lcW7dd3yTo9iBJdi7qz
4nANOMFPK7JOy5npKN1iiousl28U/scUJES55gPwAWYJK3uVyQAsA4adgDKi5DoD1UHDQEwp
bY7iHLJeq0NPr4BqYNqnCFPbE6HC8zSJrr4qKn+gVUQT39SIFqdiIPJwZL8FYTRQ/zsCAwEA
AaOCAbYwggGyMAsGA1UdDwQEAwIHgDArBgNVHRAEJDAigA8yMDEwMDYxMTE4MjIwNlqBDzIw
MTIwNzE3MjI1MjA2WjAbBg0rBgEEAbMlCwMBAQEBBAoWCGZpb3JhbWUxMBsGDSsGAQQBsyUL
AwEBAQIEChIIMDAxMDQyNjEwWAYJYIZIAYb6ax4BBEsMSVRoZSBwcml2YXRlIGtleSBjb3Jy
ZXNwb25kaW5nIHRvIHRoaXMgY2VydGlmaWNhdGUgbWF5IGhhdmUgYmVlbiBleHBvcnRlZC4w
KAYDVR0RBCEwH4EdTWF0dGhldy5GaW9yYXZhbnRlQGpodWFwbC5lZHUwUgYDVR0fBEswSTBH
oEWgQ6RBMD8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJU0RD
QTEOMAwGA1UEAxMFQ1JMNTYwHwYDVR0jBBgwFoAUCDUpmxH52EU2CyWmF2EJMB1yqeswHQYD
VR0OBBYEFO6LYxg6r9wHZ+zdQtBHn1dZ/YTNMAkGA1UdEwQCMAAwGQYJKoZIhvZ9B0EABAww
ChsEVjcuMQMCBLAwDQYJKoZIhvcNAQEFBQADgYEAJO9HQh4YNChVLzuZqK5ARJARD8JoujGZ
fdo75quvg2jXFQe2sEjvLnxJZgm/pv8fdZakq48CWwjYHKuvIp7sDjTEsQfo+y7SpN/N2NvJ
WU5SqfK1VgYtNLRRoGJUB5Q1aZ+Dg95g3kqpyfpUMISJL8IKVLtJVfN4fggFVUYZ9wwxggGr
MIIBpwIBATA3MC8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJ
U0RDQQIEP/HJ/TAJBgUrDgMCGgUAoIHLMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ
KoZIhvcNAQkFMQ8XDTEyMDkyMTE4NDkwMVowIwYJKoZIhvcNAQkEMRYEFNlIbl3yj+8uUC6J
j/Ngvh7uxr5oMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAK
BggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI
KoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEgYAPVIsQzqVY+/i7dsvvjZT+XgHurslIyEsy
jxaBPxMhgoz4flWuwuXffIb+MYb+F/agbImDb5P8r5b06WoLizJZ4T6VmwCnfBjlY0GpVTBr
LiFrufhecfMbz+mqxbAPw1dWeQ5MMP8VnzN2us1ugGH6VRXiVyosfabSpDunpGU7xAAAAAAA
AA==
--------------ms060005000704030804060404--


--===============1847460024785158106==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============1847460024785158106==--


From xen-devel-bounces@lists.xen.org Fri Sep 21 18:50:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Sep 2012 18: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 1TF8J4-00014l-Pd; Fri, 21 Sep 2012 18:50:30 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <matthew.fioravante@jhuapl.edu>) id 1TF8J2-00014f-P7
	for xen-devel@lists.xensource.com; Fri, 21 Sep 2012 18:50:28 +0000
Received: from [85.158.138.51:37724] by server-8.bemta-3.messagelabs.com id
	53/9B-24700-4F6BC505; Fri, 21 Sep 2012 18:50:28 +0000
X-Env-Sender: matthew.fioravante@jhuapl.edu
X-Msg-Ref: server-11.tower-174.messagelabs.com!1348253425!31495360!1
X-Originating-IP: [128.244.251.36]
X-SpamReason: No, hits=0.0 required=7.0 tests=HTML_MESSAGE, UNPARSEABLE_RELAY
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9827 invoked from network); 21 Sep 2012 18:50:26 -0000
Received: from pilot.jhuapl.edu (HELO jhuapl.edu) (128.244.251.36)
	by server-11.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 21 Sep 2012 18:50:26 -0000
Received: from ([128.244.207.89])
	by pilot.jhuapl.edu with ESMTP with TLS id 63GHCH1.153408464;
	Fri, 21 Sep 2012 14:50:18 -0400
Message-ID: <505CB69D.6070203@jhuapl.edu>
Date: Fri, 21 Sep 2012 14:49:01 -0400
From: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120827 Thunderbird/15.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>, 
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
X-Enigmail-Version: 1.4.4
Subject: [Xen-devel] PATCH [base vtpm and libxl patches 0/6]
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1847460024785158106=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a cryptographically signed message in MIME format.

--===============1847460024785158106==
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms060005000704030804060404"

This is a cryptographically signed message in MIME format.

--------------ms060005000704030804060404
Content-Type: multipart/alternative;
 boundary="------------020403060403070504040206"

This is a multi-part message in MIME format.
--------------020403060403070504040206
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

So it looks like I was basing my patches off of this tree
git://xenbits.xen.org/xen-unstable.git
which is not actually xen-unstable. I rebased and reworked my patches
off of the correct tree
git://xenbits.xen.org/xen.git

What follows are the vtpmd, vtpm_manager, and libxl patches. All of the
mini-os patches apply cleanly to the latest xen so I won't be
resubmitting those unless you all would want me to.

Anyway, patches incoming..

--------------020403060403070504040206
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<html>
  <head>

    <meta http-equiv=3D"content-type" content=3D"text/html; charset=3DISO=
-8859-1">
  </head>
  <body bgcolor=3D"#FFFFFF" text=3D"#000000">
    So it looks like I was basing my patches off of this tree <span
      style=3D"color: rgb(0, 0, 0); font-family: sans-serif; font-size:
      13px; font-style: normal; font-variant: normal; font-weight:
      normal; letter-spacing: normal; line-height: normal; orphans: 2;
      text-align: -webkit-auto; text-indent: 0px; text-transform: none;
      white-space: normal; widows: 2; word-spacing: 0px;
      -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px;
      background-color: rgb(255, 255, 255); display: inline !important;
      float: none; ">git://xenbits.xen.org/xen-unstable.git </span><br>
    which is not actually xen-unstable. I rebased and reworked my
    patches off of the correct tree<br>
    <span style=3D"color: rgb(0, 0, 0); font-family: sans-serif;
      font-size: 13px; font-style: normal; font-variant: normal;
      font-weight: normal; letter-spacing: normal; line-height: normal;
      orphans: 2; text-align: -webkit-auto; text-indent: 0px;
      text-transform: none; white-space: normal; widows: 2;
      word-spacing: 0px; -webkit-text-size-adjust: auto;
      -webkit-text-stroke-width: 0px; background-color: rgb(255, 255,
      255); display: inline !important; float: none; ">git://xenbits.xen.=
org/xen.git
    </span><br>
    <br>
    What follows are the vtpmd, vtpm_manager, and libxl patches. All of
    the mini-os patches apply cleanly to the latest xen so I won't be
    resubmitting those unless you all would want me to.<br>
    <br>
    Anyway, patches incoming..<br>
    <span style=3D"color: rgb(0, 0, 0); font-family: sans-serif;
      font-size: 13px; font-style: normal; font-variant: normal;
      font-weight: normal; letter-spacing: normal; line-height: normal;
      orphans: 2; text-align: -webkit-auto; text-indent: 0px;
      text-transform: none; white-space: normal; widows: 2;
      word-spacing: 0px; -webkit-text-size-adjust: auto;
      -webkit-text-stroke-width: 0px; background-color: rgb(255, 255,
      255); display: inline !important; float: none; "></span>
  </body>
</html>

--------------020403060403070504040206--

--------------ms060005000704030804060404
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIDyjCC
A8YwggMvoAMCAQICBD/xyf0wDQYJKoZIhvcNAQEFBQAwLzELMAkGA1UEBhMCVVMxDzANBgNV
BAoTBkpIVUFQTDEPMA0GA1UECxMGQklTRENBMB4XDTEwMDYxMTE4MjIwNloXDTEzMDYxMTE4
NTIwNlowZjELMAkGA1UEBhMCVVMxDzANBgNVBAoTBkpIVUFQTDEPMA0GA1UECxMGUGVvcGxl
MTUwFgYDVQQLEw9WUE5Hcm91cC1CSVNEQ0EwGwYDVQQDExRNYXR0aGV3IEUgRmlvcmF2YW50
ZTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAnpbwVSP6o1Nb5lcW7dd3yTo9iBJdi7qz
4nANOMFPK7JOy5npKN1iiousl28U/scUJES55gPwAWYJK3uVyQAsA4adgDKi5DoD1UHDQEwp
bY7iHLJeq0NPr4BqYNqnCFPbE6HC8zSJrr4qKn+gVUQT39SIFqdiIPJwZL8FYTRQ/zsCAwEA
AaOCAbYwggGyMAsGA1UdDwQEAwIHgDArBgNVHRAEJDAigA8yMDEwMDYxMTE4MjIwNlqBDzIw
MTIwNzE3MjI1MjA2WjAbBg0rBgEEAbMlCwMBAQEBBAoWCGZpb3JhbWUxMBsGDSsGAQQBsyUL
AwEBAQIEChIIMDAxMDQyNjEwWAYJYIZIAYb6ax4BBEsMSVRoZSBwcml2YXRlIGtleSBjb3Jy
ZXNwb25kaW5nIHRvIHRoaXMgY2VydGlmaWNhdGUgbWF5IGhhdmUgYmVlbiBleHBvcnRlZC4w
KAYDVR0RBCEwH4EdTWF0dGhldy5GaW9yYXZhbnRlQGpodWFwbC5lZHUwUgYDVR0fBEswSTBH
oEWgQ6RBMD8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJU0RD
QTEOMAwGA1UEAxMFQ1JMNTYwHwYDVR0jBBgwFoAUCDUpmxH52EU2CyWmF2EJMB1yqeswHQYD
VR0OBBYEFO6LYxg6r9wHZ+zdQtBHn1dZ/YTNMAkGA1UdEwQCMAAwGQYJKoZIhvZ9B0EABAww
ChsEVjcuMQMCBLAwDQYJKoZIhvcNAQEFBQADgYEAJO9HQh4YNChVLzuZqK5ARJARD8JoujGZ
fdo75quvg2jXFQe2sEjvLnxJZgm/pv8fdZakq48CWwjYHKuvIp7sDjTEsQfo+y7SpN/N2NvJ
WU5SqfK1VgYtNLRRoGJUB5Q1aZ+Dg95g3kqpyfpUMISJL8IKVLtJVfN4fggFVUYZ9wwxggGr
MIIBpwIBATA3MC8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJ
U0RDQQIEP/HJ/TAJBgUrDgMCGgUAoIHLMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ
KoZIhvcNAQkFMQ8XDTEyMDkyMTE4NDkwMVowIwYJKoZIhvcNAQkEMRYEFNlIbl3yj+8uUC6J
j/Ngvh7uxr5oMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAK
BggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI
KoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEgYAPVIsQzqVY+/i7dsvvjZT+XgHurslIyEsy
jxaBPxMhgoz4flWuwuXffIb+MYb+F/agbImDb5P8r5b06WoLizJZ4T6VmwCnfBjlY0GpVTBr
LiFrufhecfMbz+mqxbAPw1dWeQ5MMP8VnzN2us1ugGH6VRXiVyosfabSpDunpGU7xAAAAAAA
AA==
--------------ms060005000704030804060404--


--===============1847460024785158106==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============1847460024785158106==--


From xen-devel-bounces@lists.xen.org Fri Sep 21 18:52:56 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Sep 2012 18:52:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TF8LB-0001DV-Er; Fri, 21 Sep 2012 18:52: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 1TF8LA-0001DN-9I
	for xen-devel@lists.xen.org; Fri, 21 Sep 2012 18:52:40 +0000
Received: from [85.158.143.99:14815] by server-1.bemta-4.messagelabs.com id
	39/3F-05684-777BC505; Fri, 21 Sep 2012 18:52:39 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1348253557!25183462!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzU2MzI0\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12826 invoked from network); 21 Sep 2012 18:52:38 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-7.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 21 Sep 2012 18:52:38 -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 q8LIqWLk012607
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 21 Sep 2012 18:52:33 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
	q8LIqUI0007922
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 21 Sep 2012 18:52:30 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
	q8LIqTqJ024876; Fri, 21 Sep 2012 13:52:29 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 21 Sep 2012 11:52:29 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id B1176402EC; Fri, 21 Sep 2012 14:41:23 -0400 (EDT)
Date: Fri, 21 Sep 2012 14:41:23 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Oliver Chick <oliver.chick@citrix.com>
Message-ID: <20120921184123.GA27502@phenom.dumpdata.com>
References: <1348242767-23732-1-git-send-email-oliver.chick@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1348242767-23732-1-git-send-email-oliver.chick@citrix.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: linux-kernel@vger.kernel.org, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH v2] Persistent grant maps for xen blk drivers
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Sep 21, 2012 at 04:52:47PM +0100, Oliver Chick wrote:
> This patch implements persistent grants for the xen-blk{front,back}
> mechanism. The effect of this change is to reduce the number of unmap
> operations performed, since they cause a (costly) TLB shootdown. This
> allows the I/O performance to scale better when a large number of VMs
> are performing I/O.

So I applied your patch to my #linux-next and I got this (the dom0 is the
same as the domU)
I get this when using an PVHVM (*)and PV guest:
# fdisk /dev/xvda
[   28.594049] BUG: unable to handle kernel NULL pointer dereference at 0000000000000008
[   28.595028] IP: [<ffffffffa003fe9a>] blkif_interrupt+0x3aa/0x5d0 [xen_blkfront]
[   28.595028] PGD dcaf0067 PUD 7fb5e067 PMD 0 
[   28.595028] Oops: 0000 [#1] SMP 
[   28.595028] Modules linked in: iscsi_boot_sysfs iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi libcrc32c crc32c sg sr_mod cdrom ata_generic ata_piix crc32c_intel libata scsi_mod xen_blkfront xen_netfront fb_sys_fops sysimgblt sysfillrect syscopyarea xen_kbdfront xenfs xen_privcmd [last unloaded: dump_dma]
[   28.595028] CPU 0 
[   28.595028] Pid: 0, comm: swapper/0 Tainted: G           O 3.6.0-rc6upstream-00196-ge45cba2 #1 Xen HVM domU
[   28.595028] RIP: 0010:[<ffffffffa003fe9a>]  [<ffffffffa003fe9a>] blkif_interrupt+0x3aa/0x5d0 [xen_blkfront]
[   28.595028] RSP: 0018:ffff88010fc03da8  EFLAGS: 00010002
[   28.595028] RAX: 0000000000000000 RBX: ffffffff81a00000 RCX: ffff88010af5f140
[   28.595028] RDX: ffff88010af5f080 RSI: ffff8800dbbf8210 RDI: ffff8800dc679c00
[   28.595028] RBP: ffff88010fc03e28 R08: 0000000000000001 R09: 0000000000000011
[   28.595028] R10: 0000000000000000 R11: 0000000000000000 R12: 6db6db6db6db6db7
[   28.595028] R13: ffff88010af5f1a8 R14: 0000000000000004 R15: 0000000000000000
[   28.595028] FS:  0000000000000000(0000) GS:ffff88010fc00000(0000) knlGS:0000000000000000
[   28.595028] CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
[   28.595028] CR2: 0000000000000008 CR3: 00000000d4ac0000 CR4: 00000000000006f0
[   28.595028] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[   28.595028] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[   28.595028] Process swapper/0 (pid: 0, threadinfo ffffffff81a00000, task ffffffff81a13420)
[   28.595028] Stack:
[   28.595028]  0000000000000086 ffff8800d9951060 ffff8800d9953000 0000000881376d09
[   28.595028]  0000000000000008 0000000a81376f2d 0000000000000000 ffff8800dbbf8210
[   28.595028]  ffff8800dbbf8000 ffff88010af5f140 ffff88010fc03e08 ffff8800dcc4e3c0
[   28.595028] Call Trace:
[   28.595028]  <IRQ> 
[   28.595028]  [<ffffffff8110dcdc>] handle_irq_event_percpu+0x7c/0x240
[   28.595028]  [<ffffffff8110df02>] handle_irq_event+0x62/0x90
[   28.595028]  [<ffffffff8111178e>] handle_edge_irq+0x8e/0x160
[   28.595028]  [<ffffffff81376ac4>] __xen_evtchn_do_upcall+0x1c4/0x2a0
[   28.595028]  [<ffffffff813775ba>] xen_evtchn_do_upcall+0x2a/0x40
[   28.595028]  [<ffffffff816314ba>] xen_hvm_callback_vector+0x6a/0x70
[   28.595028]  <EOI> 
[   28.595028]  [<ffffffff8107b3a6>] ? native_safe_halt+0x6/0x10
[   28.595028]  [<ffffffff810555da>] default_idle+0x4a/0x210
[   28.595028]  [<ffffffff81054d79>] cpu_idle+0x99/0xe0
[   28.595028]  [<ffffffff816015da>] rest_init+0x8a/0xa0
[   28.595028]  [<ffffffff81abcd72>] start_kernel+0x383/0x390
[   28.595028]  [<ffffffff81abc80d>] ? kernel_init+0x1e8/0x1e8
[   28.595028]  [<ffffffff81abc356>] x86_64_start_reservations+0x131/0x136
[   28.595028]  [<ffffffff81abc45e>] x86_64_start_kernel+0x103/0x112
[   28.595028] Code: 00 49 83 c5 10 41 8b 45 08 41 03 45 0c 3d 00 10 00 00 0f 87 7e 01 00 00 48 8b 75 b8 49 63 c6 41 83 c6 01 48 8b 84 c6 d0 00 00 00 <48> 8b 40 08 83 43 1c 01 48 8d 14 c5 00 00 00 00 48 c1 e0 06 48 
[   28.595028] RIP  [<ffffffffa003fe9a>] blkif_interrupt+0x3aa/0x5d0 [xen_blkfront]
[   28.595028]  RSP <ffff88010fc03da8>
[   28.595028] CR2: 0000000000000008
[   28.595028] ---[ end trace 49f5630a34777570 ]---
[   28.595028] Kernel panic - not syncing: Fatal exception in interrupt
[   28.595028] Rebooting in 60 seconds..

*: With a PVHVM guest I get

[  261.927218] privcmd_fault: vma=ffff88002a31dce8 7f4edc095000-7f4edc195000, pgoff=c8, uv=00007f4edc15d000

thought if I applied your patch on top of v3.6-rc6 I didn't see the privcmd_fault but
I did see the guest crash.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 21 18:52:56 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Sep 2012 18:52:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TF8LB-0001DV-Er; Fri, 21 Sep 2012 18:52: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 1TF8LA-0001DN-9I
	for xen-devel@lists.xen.org; Fri, 21 Sep 2012 18:52:40 +0000
Received: from [85.158.143.99:14815] by server-1.bemta-4.messagelabs.com id
	39/3F-05684-777BC505; Fri, 21 Sep 2012 18:52:39 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1348253557!25183462!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzU2MzI0\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12826 invoked from network); 21 Sep 2012 18:52:38 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-7.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 21 Sep 2012 18:52:38 -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 q8LIqWLk012607
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 21 Sep 2012 18:52:33 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
	q8LIqUI0007922
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 21 Sep 2012 18:52:30 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
	q8LIqTqJ024876; Fri, 21 Sep 2012 13:52:29 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 21 Sep 2012 11:52:29 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id B1176402EC; Fri, 21 Sep 2012 14:41:23 -0400 (EDT)
Date: Fri, 21 Sep 2012 14:41:23 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Oliver Chick <oliver.chick@citrix.com>
Message-ID: <20120921184123.GA27502@phenom.dumpdata.com>
References: <1348242767-23732-1-git-send-email-oliver.chick@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1348242767-23732-1-git-send-email-oliver.chick@citrix.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: linux-kernel@vger.kernel.org, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH v2] Persistent grant maps for xen blk drivers
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Sep 21, 2012 at 04:52:47PM +0100, Oliver Chick wrote:
> This patch implements persistent grants for the xen-blk{front,back}
> mechanism. The effect of this change is to reduce the number of unmap
> operations performed, since they cause a (costly) TLB shootdown. This
> allows the I/O performance to scale better when a large number of VMs
> are performing I/O.

So I applied your patch to my #linux-next and I got this (the dom0 is the
same as the domU)
I get this when using an PVHVM (*)and PV guest:
# fdisk /dev/xvda
[   28.594049] BUG: unable to handle kernel NULL pointer dereference at 0000000000000008
[   28.595028] IP: [<ffffffffa003fe9a>] blkif_interrupt+0x3aa/0x5d0 [xen_blkfront]
[   28.595028] PGD dcaf0067 PUD 7fb5e067 PMD 0 
[   28.595028] Oops: 0000 [#1] SMP 
[   28.595028] Modules linked in: iscsi_boot_sysfs iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi libcrc32c crc32c sg sr_mod cdrom ata_generic ata_piix crc32c_intel libata scsi_mod xen_blkfront xen_netfront fb_sys_fops sysimgblt sysfillrect syscopyarea xen_kbdfront xenfs xen_privcmd [last unloaded: dump_dma]
[   28.595028] CPU 0 
[   28.595028] Pid: 0, comm: swapper/0 Tainted: G           O 3.6.0-rc6upstream-00196-ge45cba2 #1 Xen HVM domU
[   28.595028] RIP: 0010:[<ffffffffa003fe9a>]  [<ffffffffa003fe9a>] blkif_interrupt+0x3aa/0x5d0 [xen_blkfront]
[   28.595028] RSP: 0018:ffff88010fc03da8  EFLAGS: 00010002
[   28.595028] RAX: 0000000000000000 RBX: ffffffff81a00000 RCX: ffff88010af5f140
[   28.595028] RDX: ffff88010af5f080 RSI: ffff8800dbbf8210 RDI: ffff8800dc679c00
[   28.595028] RBP: ffff88010fc03e28 R08: 0000000000000001 R09: 0000000000000011
[   28.595028] R10: 0000000000000000 R11: 0000000000000000 R12: 6db6db6db6db6db7
[   28.595028] R13: ffff88010af5f1a8 R14: 0000000000000004 R15: 0000000000000000
[   28.595028] FS:  0000000000000000(0000) GS:ffff88010fc00000(0000) knlGS:0000000000000000
[   28.595028] CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
[   28.595028] CR2: 0000000000000008 CR3: 00000000d4ac0000 CR4: 00000000000006f0
[   28.595028] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[   28.595028] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[   28.595028] Process swapper/0 (pid: 0, threadinfo ffffffff81a00000, task ffffffff81a13420)
[   28.595028] Stack:
[   28.595028]  0000000000000086 ffff8800d9951060 ffff8800d9953000 0000000881376d09
[   28.595028]  0000000000000008 0000000a81376f2d 0000000000000000 ffff8800dbbf8210
[   28.595028]  ffff8800dbbf8000 ffff88010af5f140 ffff88010fc03e08 ffff8800dcc4e3c0
[   28.595028] Call Trace:
[   28.595028]  <IRQ> 
[   28.595028]  [<ffffffff8110dcdc>] handle_irq_event_percpu+0x7c/0x240
[   28.595028]  [<ffffffff8110df02>] handle_irq_event+0x62/0x90
[   28.595028]  [<ffffffff8111178e>] handle_edge_irq+0x8e/0x160
[   28.595028]  [<ffffffff81376ac4>] __xen_evtchn_do_upcall+0x1c4/0x2a0
[   28.595028]  [<ffffffff813775ba>] xen_evtchn_do_upcall+0x2a/0x40
[   28.595028]  [<ffffffff816314ba>] xen_hvm_callback_vector+0x6a/0x70
[   28.595028]  <EOI> 
[   28.595028]  [<ffffffff8107b3a6>] ? native_safe_halt+0x6/0x10
[   28.595028]  [<ffffffff810555da>] default_idle+0x4a/0x210
[   28.595028]  [<ffffffff81054d79>] cpu_idle+0x99/0xe0
[   28.595028]  [<ffffffff816015da>] rest_init+0x8a/0xa0
[   28.595028]  [<ffffffff81abcd72>] start_kernel+0x383/0x390
[   28.595028]  [<ffffffff81abc80d>] ? kernel_init+0x1e8/0x1e8
[   28.595028]  [<ffffffff81abc356>] x86_64_start_reservations+0x131/0x136
[   28.595028]  [<ffffffff81abc45e>] x86_64_start_kernel+0x103/0x112
[   28.595028] Code: 00 49 83 c5 10 41 8b 45 08 41 03 45 0c 3d 00 10 00 00 0f 87 7e 01 00 00 48 8b 75 b8 49 63 c6 41 83 c6 01 48 8b 84 c6 d0 00 00 00 <48> 8b 40 08 83 43 1c 01 48 8d 14 c5 00 00 00 00 48 c1 e0 06 48 
[   28.595028] RIP  [<ffffffffa003fe9a>] blkif_interrupt+0x3aa/0x5d0 [xen_blkfront]
[   28.595028]  RSP <ffff88010fc03da8>
[   28.595028] CR2: 0000000000000008
[   28.595028] ---[ end trace 49f5630a34777570 ]---
[   28.595028] Kernel panic - not syncing: Fatal exception in interrupt
[   28.595028] Rebooting in 60 seconds..

*: With a PVHVM guest I get

[  261.927218] privcmd_fault: vma=ffff88002a31dce8 7f4edc095000-7f4edc195000, pgoff=c8, uv=00007f4edc15d000

thought if I applied your patch on top of v3.6-rc6 I didn't see the privcmd_fault but
I did see the guest crash.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 21 18:54:51 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Sep 2012 18:54:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TF8N4-0001Mk-0p; Fri, 21 Sep 2012 18:54:38 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <matthew.fioravante@jhuapl.edu>) id 1TF8N1-0001MY-UW
	for xen-devel@lists.xensource.com; Fri, 21 Sep 2012 18:54:36 +0000
Received: from [85.158.143.99:12142] by server-2.bemta-4.messagelabs.com id
	48/D1-06610-BE7BC505; Fri, 21 Sep 2012 18:54:35 +0000
X-Env-Sender: matthew.fioravante@jhuapl.edu
X-Msg-Ref: server-9.tower-216.messagelabs.com!1348253667!31338649!1
X-Originating-IP: [128.244.251.36]
X-SpamReason: No, hits=0.0 required=7.0 tests=UNPARSEABLE_RELAY
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6898 invoked from network); 21 Sep 2012 18:54:28 -0000
Received: from pilot.jhuapl.edu (HELO jhuapl.edu) (128.244.251.36)
	by server-9.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 21 Sep 2012 18:54:28 -0000
Received: from ([128.244.207.89])
	by pilot.jhuapl.edu with ESMTP with TLS id 63GHCH1.153408747;
	Fri, 21 Sep 2012 14:54:23 -0400
Message-ID: <505CB793.1010405@jhuapl.edu>
Date: Fri, 21 Sep 2012 14:53:07 -0400
From: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120827 Thunderbird/15.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>, 
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
X-Enigmail-Version: 1.4.4
Subject: [Xen-devel] PATCH [base vtpm and libxl patches 1/6] Upgrade vtpmd
 from 0.5.1 to 0.7.4
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============6507152100997419522=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a cryptographically signed message in MIME format.

--===============6507152100997419522==
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms070902070202080609000704"

This is a cryptographically signed message in MIME format.

--------------ms070902070202080609000704
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Update vtpmd from 0.5.1 to 0.7.4. Also adds checks for cmake
and gmp to the configure script if vtpm is enabled.

Signed off by Matthew Fioravante matthew.fioravante@jhuapl.edu

---
Changed since previous:
* added checks for libgmp and gmp.h if vtpm is enabled
* small documentation updates

diff --git a/tools/configure.ac b/tools/configure.ac
--- a/tools/configure.ac
+++ b/tools/configure.ac
@@ -72,6 +72,7 @@ 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])
+AC_ARG_VAR([CMAKE], [Path to cmake binary])
=20
 # Checks for programs.
 AC_PROG_CC
@@ -101,6 +102,9 @@ AS_IF([echo "$PYTHON" | grep -q "^/"], [
 AX_PATH_PROG_OR_FAIL([PYTHONPATH], [$PYTHON])
 AX_CHECK_PYTHON_VERSION([2], [3])
  AX_CHECK_PYTHON_DEVEL()
+AS_IF([test "x$vtpm" =3D "xy"], [
+    AX_PATH_PROG_OR_FAIL([CMAKE], [cmake])
+])
 AX_PATH_PROG_OR_FAIL([XGETTEXT], [xgettext])
 dnl as86, ld86, bcc and iasl are only required when the host system is
x86*.
 dnl "host" here means the platform on which the hypervisor and tools is
@@ -142,6 +146,10 @@ AC_CHECK_LIB([yajl], [yajl_alloc], [],
 AC_CHECK_LIB([z], [deflateCopy], [], [AC_MSG_ERROR([Could not find zlib]=
)])
 AC_CHECK_LIB([iconv], [libiconv_open], [libiconv=3D"y"], [libiconv=3D"n"=
])
 AC_SUBST(libiconv)
+AS_IF([test "x$vtpm" =3D "xy"], [
+    AC_CHECK_HEADER([gmp.h], [], [AC_MSG_ERROR([Could not find gmp.h])])=

+    AC_CHECK_LIB([gmp], [__gmpz_init], [], [AC_MSG_ERROR([Could not
find libgmp])])
+])
=20
 # Checks for header files.
 AC_CHECK_HEADERS([yajl/yajl_version.h])
diff --git a/tools/vtpm/Makefile b/tools/vtpm/Makefile
--- a/tools/vtpm/Makefile
+++ b/tools/vtpm/Makefile
@@ -1,19 +1,15 @@
 XEN_ROOT =3D $(CURDIR)/../..
+include $(XEN_ROOT)/tools/Rules.mk
=20
-# Base definitions and rules
-include $(XEN_ROOT)/tools/vtpm/Rules.mk
-
-# Dir name for emulator (as dom0 tpm driver)
-TPM_EMULATOR_DIR =3D tpm_emulator
 # Dir name for vtpm instance
 VTPM_DIR =3D vtpm
-ORIG_DIR =3D orig
=20
 # Emulator tarball name
-TPM_EMULATOR_NAME =3D tpm_emulator-0.5.1
+TPM_EMULATOR_URL =3D http://download.berlios.de/tpm-emulator
+TPM_EMULATOR_NAME =3D tpm_emulator-0.7.4
 TPM_EMULATOR_TARFILE =3D $(TPM_EMULATOR_NAME).tar.gz
=20
-GMP_HEADER =3D /usr/include/gmp.h
+VTPM_PATCH =3D vtpm-0.7.4.patch
=20
 .PHONY: all
 all: build
@@ -23,52 +19,39 @@ build: build_sub
=20
 .PHONY: install
 install: build
-    $(MAKE) -C $(VTPM_DIR) install-recursive
+    $(INSTALL_PROG) -m 0755 $(VTPM_DIR)/build/tpmd/unix/tpmd
$(DESTDIR)$(BINDIR)/vtpmd
=20
 .PHONY: clean
 clean:
-    @if [ -d $(TPM_EMULATOR_DIR) ]; \
-        then $(MAKE) -C $(TPM_EMULATOR_DIR) clean; \
-    fi
-    @if [ -d $(VTPM_DIR) ]; \
-        then $(MAKE) -C $(VTPM_DIR) clean; \
+    @-if [ -d $(VTPM_DIR)/build ]; \
+        then $(MAKE) -C $(VTPM_DIR)/build clean; \
     fi
=20
-.PHONY: mrproper
-mrproper:
-    rm -f $(TPM_EMULATOR_TARFILE) tpm_emulator.patch.old vtpm.patch.old
-    rm -rf $(TPM_EMULATOR_DIR) $(VTPM_DIR) $(ORIG_DIR)
+.PHONY: distclean
+mdistclean:
+    rm -f $(TPM_EMULATOR_TARFILE)
+    rm -rf $(VTPM_DIR) $(ORIG_DIR)
=20
 # Download Swiss emulator
 $(TPM_EMULATOR_TARFILE):
-    wget http://download.berlios.de/tpm-emulator/$(TPM_EMULATOR_TARFILE)=

+    wget $(TPM_EMULATOR_URL)/$(TPM_EMULATOR_TARFILE)
=20
 # Create vtpm dirs
-$(VTPM_DIR)/tpmd/tpmd: $(TPM_EMULATOR_TARFILE) vtpm-0.5.1.patch
+$(VTPM_DIR)/build: $(TPM_EMULATOR_TARFILE) $(VTPM_PATCH)
     rm -rf $(VTPM_DIR)
     tar -xzf $(TPM_EMULATOR_TARFILE)
     mv $(TPM_EMULATOR_NAME) $(VTPM_DIR)
-
     set -e; cd $(VTPM_DIR); \
-    patch -p1 < ../vtpm-0.5.1.patch; \
-    patch -p1 < ../vtpm-0.5.1-LDLIBS.patch
+    patch -p1 < ../$(VTPM_PATCH);
+    mkdir $@
+    touch $@
=20
-orig: $(TPM_EMULATOR_TARFILE)
-    mkdir $(ORIG_DIR);
-    set -e; cd $(ORIG_DIR); \
-    tar -xzf ../$(TPM_EMULATOR_TARFILE);
-
-updatepatches: clean orig
-    find $(VTPM_DIR) -name "*.orig" -print | xargs rm -f;
-    mv vtpm.patch vtpm.patch.old;
-    diff -uprN $(TPM_EMULATOR_DIR) $(VTPM_DIR) > vtpm.patch || true;
+$(VTPM_DIR)/build/Makefile: $(VTPM_DIR)/build
+    set -e; cd $(VTPM_DIR)/build; \
+    cmake -DCMAKE_INSTALL_PREFIX=3D${PREFIX} ..
+    touch $@
=20
 .PHONY: build_sub
-build_sub: $(VTPM_DIR)/tpmd/tpmd
-    set -e; if [ -e $(GMP_HEADER) ]; then \
-        $(MAKE) -C $(VTPM_DIR) version; \
-        $(MAKE) -C $(VTPM_DIR) all-recursive; \
-    else \
-        echo "=3D=3D=3D Unable to build VTPMs. libgmp could not be found=
=2E"; \
-    fi
-
+build_sub: $(VTPM_DIR)/build/Makefile
+    set -e; \
+    cd $(VTPM_DIR)/build; $(MAKE) tpmd
diff --git a/tools/vtpm/README b/tools/vtpm/README
--- a/tools/vtpm/README
+++ b/tools/vtpm/README
@@ -1,27 +1,19 @@
=20
 Directory Structure
 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
-tools/vtpm/tpm_emulator-0.2b.tar.gz    -> TPM Emulator downloaded at
build time that will
+tools/vtpm/tpm_emulator-0.7.4.tar.gz   -> TPM Emulator downloaded at
build time that will
                                           be patched and used for our vt=
pms
-tools/vtpm/vtpm.patch                  -> patch applied to tpm_emulator
to make vtpm
+tools/vtpm/vtpm-0.7.4.patch             -> patch applied to
tpm_emulator to make vtpm
 tools/vtpm/vtpm/                       -> (created on build)
tpm_emulator moved to ring 3,
                                           listens on a pair of fifos
for TPM commands,
                                           persistent state is sent via
named fifo to vtpm
                                             manager, which encrypts it
and protects it.
-tools/vtpm/tpm_emulator.patch          -> To allow for debugging and
testing on non-TPM
-                                          platforms, this patches the
emulator to allow
-                                          it to be inserted into the
dom0 kernel
-tools/vtpm/tpm_emulator-0.2            -> (created on build) directory
containing patched emulator
-
-Compile Flags
-=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
-VTPM_MULTI_VM                -> Defined (not finished): VTPMs run in
their own VMs
-                                Not Defined (default): VTPMs are process=
es
+tools/vtpm/tpm_emulator-0.7.4          -> (created on build) directory
containing patched emulator
=20
 Requirements
 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
 - xen-unstable
-- IBM frontend/backend vtpm driver patch
+- IBM frontend/backend vtpm driver patch for the linux kernel
 - vtpm_managerd
 - GNU MP Big number library (GMP)
=20
@@ -42,4 +34,4 @@ vtpmd Flow (for vtpm_manager. vtpmd never run by defaul=
t)
=20
 tpm_emulator flow
 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
-Read documentation in tpm_emulator-0.2 directory
+Read documentation in tpm_emulator directory
diff --git a/tools/vtpm/Rules.mk b/tools/vtpm/Rules.mk
--- a/tools/vtpm/Rules.mk
+++ /dev/null
@@ -1,26 +0,0 @@
-# Base definitions and rules (XEN_ROOT must be defined in including
Makefile)
-include $(XEN_ROOT)/tools/Rules.mk
-
-#
-# Tool definitions
-#
-
-# General compiler flags
-CFLAGS   =3D -Werror -g3
-
-# Generic project files
-HDRS    =3D $(wildcard *.h)
-SRCS    =3D $(wildcard *.c)
-OBJS    =3D $(patsubst %.c,%.o,$(SRCS))
-
-# Generic (non-header) dependencies
-$(SRCS): Makefile $(XEN_ROOT)/tools/Rules.mk
$(XEN_ROOT)/tools/vtpm/Rules.mk
-
-$(OBJS): $(SRCS)
-
--include $(DEPS)
-
-BUILD_EMULATOR =3D y
-
-# Make sure these are just rules
-.PHONY : all build install clean
diff --git a/tools/vtpm/tpm_emulator.patch b/tools/vtpm/tpm_emulator.patc=
h
--- a/tools/vtpm/tpm_emulator.patch
+++ /dev/null
@@ -1,1919 +0,0 @@
-diff -uprN orig/tpm_emulator-0.4/AUTHORS tpm_emulator/AUTHORS
---- orig/tpm_emulator-0.4/AUTHORS    2006-06-23 03:37:07.000000000 -0700=

-+++ tpm_emulator/AUTHORS    2006-07-24 14:35:35.000000000 -0700
-@@ -1,2 +1,3 @@
- Mario Strasser <mast@gmx.net>
- Heiko Stamer <stamer@gaos.org> [DAA]
-+INTEL Corp <> [Dropped to Ring3]
-diff -uprN orig/tpm_emulator-0.4/ChangeLog tpm_emulator/ChangeLog
---- orig/tpm_emulator-0.4/ChangeLog    2006-06-23 03:37:07.000000000 -07=
00
-+++ tpm_emulator/ChangeLog    2006-07-24 14:35:35.000000000 -0700
-@@ -1,3 +1,6 @@
-+????-??-?? Intel Corp
-+    * Moved module out of kernel to run as a ring 3 app
-+
- 2006-06-23  Mario Strasser <mast@gmx.net>
-     * tpm_startup.c: behaviour of ST_CLEAR and storage of
-         persistent data adapted
-diff -uprN orig/tpm_emulator-0.4/crypto/gmp_kernel_wrapper.c
tpm_emulator/crypto/gmp_kernel_wrapper.c
---- orig/tpm_emulator-0.4/crypto/gmp_kernel_wrapper.c    2006-06-23
03:37:07.000000000 -0700
-+++ tpm_emulator/crypto/gmp_kernel_wrapper.c    2006-07-24
14:35:35.000000000 -0700
-@@ -1,5 +1,6 @@
- /* Software-Based Trusted Platform Module (TPM) Emulator for Linux
-  * Copyright (C) 2004 Mario Strasser <mast@gmx.net>,
-+ * Copyright (C) 2005 INTEL Corp
-  *
-  * This module is free software; you can redistribute it and/or modify
-  * it under the terms of the GNU General Public License as published
-@@ -24,15 +25,10 @@ int __gmp_junk;
- void __attribute__ ((regparm(0))) __gmp_assert_fail(const char *filenam=
e,
-   int linenum, const char *expr)
- {
--  panic(KERN_CRIT TPM_MODULE_NAME "%s:%d: GNU MP assertion failed: %s\n=
",
-+  error("%s:%d: GNU MP assertion failed: %s\n",
-     filename, linenum, expr);
- }
-
--void __attribute__ ((regparm(0))) abort(void)
--{
--  panic(KERN_CRIT TPM_MODULE_NAME "GNU MP abort() was called\n");
--}
--
- /* overwrite GNU MP random functions (used by mpz/millerrabin.c) */
-
- void __attribute__ ((regparm(0))) gmp_randinit(gmp_randstate_t rstate,
-@@ -77,20 +73,19 @@ void __attribute__ ((regparm(0))) mpz_ur
-
- void __attribute__ ((regparm(0))) *kernel_allocate(size_t size)
- {
--  void *ret  =3D (void*)kmalloc(size, GFP_KERNEL);
--  if (!ret) panic(KERN_CRIT TPM_MODULE_NAME
--    "GMP: cannot allocate memory (size=3D%u)\n", size);
-+  void *ret  =3D (void*)malloc(size);
-+  if (!ret) error("GMP: cannot allocate memory (size=3D%Zu)\n", size);
-   return ret;
- }
-
- void __attribute__ ((regparm(0))) *kernel_reallocate(void *oldptr,
-   size_t old_size, size_t new_size)
- {
--  void *ret =3D (void*)kmalloc(new_size, GFP_KERNEL);
--  if (!ret) panic(KERN_CRIT TPM_MODULE_NAME "GMP: Cannot reallocate
memory "
--    "(old_size=3D%u new_size=3D%u)\n", old_size, new_size);
-+  void *ret =3D (void*)malloc(new_size);
-+  if (!ret) error("GMP: Cannot reallocate memory "
-+    "(old_size=3D%Zu new_size=3D%Zu)\n", old_size, new_size);
-   memcpy(ret, oldptr, old_size);
--  kfree(oldptr);
-+  free(oldptr);
-   return ret;
- }
-
-@@ -99,7 +94,7 @@ void __attribute__ ((regparm(0))) kernel
-   /* overwrite used memory */
-   if (blk_ptr !=3D NULL) {
-     memset(blk_ptr, 0, blk_size);
--    kfree(blk_ptr);
-+    free(blk_ptr);
-   }
- }
-
-diff -uprN orig/tpm_emulator-0.4/crypto/rsa.c tpm_emulator/crypto/rsa.c
---- orig/tpm_emulator-0.4/crypto/rsa.c    2006-06-23 03:37:07.000000000
-0700
-+++ tpm_emulator/crypto/rsa.c    2006-07-24 14:35:35.000000000 -0700
-@@ -1,5 +1,6 @@
- /* Software-Based Trusted Platform Module (TPM) Emulator for Linux
-  * Copyright (C) 2004 Mario Strasser <mast@gmx.net>,
-+ * Copyright (C) 2005 INTEL Corp
-  *
-  * This module is free software; you can redistribute it and/or modify
-  * it under the terms of the GNU General Public License as published
-@@ -381,7 +382,7 @@ static int encode_message(int type, uint
-       msg[0] =3D 0x00;
-       get_random_bytes(&msg[1], SHA1_DIGEST_LENGTH);
-       sha1_init(&ctx);
--      sha1_update(&ctx, "TCPA", 4);
-+      sha1_update(&ctx, (uint8_t *) "TCPA", 4);
-       sha1_final(&ctx, &msg[1 + SHA1_DIGEST_LENGTH]);
-       memset(&msg[1 + 2 * SHA1_DIGEST_LENGTH], 0x00,
-         msg_len - data_len - 2 * SHA1_DIGEST_LENGTH - 2);
-@@ -429,7 +430,7 @@ static int decode_message(int type, uint
-       mask_generation(&msg[1], SHA1_DIGEST_LENGTH,
-         &msg[1 + SHA1_DIGEST_LENGTH], msg_len - SHA1_DIGEST_LENGTH - 1)=
;
-       sha1_init(&ctx);
--      sha1_update(&ctx, "TCPA", 4);
-+      sha1_update(&ctx, (uint8_t *) "TCPA", 4);
-       sha1_final(&ctx, &msg[1]);
-       if (memcmp(&msg[1], &msg[1 + SHA1_DIGEST_LENGTH],
-           SHA1_DIGEST_LENGTH) !=3D 0) return -1;
-diff -uprN orig/tpm_emulator-0.4/linux_module.c tpm_emulator/linux_modul=
e.c
---- orig/tpm_emulator-0.4/linux_module.c    2006-06-23
03:37:07.000000000 -0700
-+++ tpm_emulator/linux_module.c    1969-12-31 16:00:00.000000000 -0800
-@@ -1,195 +0,0 @@
--/* Software-Based Trusted Platform Module (TPM) Emulator for Linux
-- * Copyright (C) 2004 Mario Strasser <mast@gmx.net>,
-- *
-- * This module 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.=20
-- *
-- * This module 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.
-- *
-- * $Id: linux_module.c 91 2006-03-13 13:51:41Z mast $
-- */
--
--#include <linux/module.h>
--#include <linux/kernel.h>
--#include <linux/init.h>
--#include <linux/miscdevice.h>
--#include <linux/poll.h>
--#include "linux_module.h"
--#include "tpm/tpm_emulator.h"
--
--MODULE_LICENSE("GPL");
--MODULE_AUTHOR("Mario Strasser <mast@gmx.net>");
--MODULE_DESCRIPTION("Trusted Platform Module (TPM) Emulator");
--MODULE_SUPPORTED_DEVICE(TPM_DEVICE_NAME);
--
--/* module startup parameters */
--char *startup =3D "save";
--module_param(startup, charp, 0444);
--MODULE_PARM_DESC(startup, " Sets the startup mode of the TPM. "
--  "Possible values are 'clear', 'save' (default) and 'deactivated.");
--char *storage_file =3D "/var/tpm/tpm_emulator-1.2.0.2";
--module_param(storage_file, charp, 0644);
--MODULE_PARM_DESC(storage_file, " Sets the persistent-data storage "
--  "file of the TPM.");
--
--/* TPM lock */
--static struct semaphore tpm_mutex;
--
--/* TPM command response */
--static struct {
--  uint8_t *data;
--  uint32_t size;
--} tpm_response;
--
--/* module state */
--#define STATE_IS_OPEN 0
--static uint32_t module_state;
--static struct timespec old_time;
--
--static int tpm_open(struct inode *inode, struct file *file)
--{
--  debug("%s()", __FUNCTION__);
--  if (test_and_set_bit(STATE_IS_OPEN, (void*)&module_state)) return
-EBUSY;
--  return 0;
--}
--
--static int tpm_release(struct inode *inode, struct file *file)
--{
--  debug("%s()", __FUNCTION__);
--  clear_bit(STATE_IS_OPEN, (void*)&module_state);
--  down(&tpm_mutex);
--  if (tpm_response.data !=3D NULL) {
--    kfree(tpm_response.data);
--    tpm_response.data =3D NULL;
--  }
--  up(&tpm_mutex);
--  return 0;
--}
--
--static ssize_t tpm_read(struct file *file, char *buf, size_t count,
loff_t *ppos)
--{
--  debug("%s(%d)", __FUNCTION__, count);
--  down(&tpm_mutex);
--  if (tpm_response.data !=3D NULL) {
--    count =3D min(count, (size_t)tpm_response.size - (size_t)*ppos);
--    count -=3D copy_to_user(buf, &tpm_response.data[*ppos], count);
--    *ppos +=3D count;
--    if ((size_t)tpm_response.size =3D=3D (size_t)*ppos) {
--      kfree(tpm_response.data);
--      tpm_response.data =3D NULL;
--    }
--  } else {
--    count =3D 0;
--  }
--  up(&tpm_mutex);
--  return count;
--}
--
--static ssize_t tpm_write(struct file *file, const char *buf, size_t
count, loff_t *ppos)
--{
--  debug("%s(%d)", __FUNCTION__, count);
--  down(&tpm_mutex);
--  *ppos =3D 0;
--  if (tpm_response.data !=3D NULL) kfree(tpm_response.data);
--  if (tpm_handle_command(buf, count, &tpm_response.data,
--                         &tpm_response.size) !=3D 0) {
--    count =3D -EILSEQ;
--    tpm_response.data =3D NULL;
--  }
--  up(&tpm_mutex);
--  return count;
--}
--
--#define TPMIOC_CANCEL   _IO('T', 0x00)
--#define TPMIOC_TRANSMIT _IO('T', 0x01)
--
--static int tpm_ioctl(struct inode *inode, struct file *file, unsigned
int cmd, unsigned long arg)
--{
--  debug("%s(%d, %p)", __FUNCTION__, cmd, (char*)arg);
--  if (cmd =3D=3D TPMIOC_TRANSMIT) {
--    uint32_t count =3D ntohl(*(uint32_t*)(arg + 2));
--    down(&tpm_mutex);
--    if (tpm_response.data !=3D NULL) kfree(tpm_response.data);
--    if (tpm_handle_command((char*)arg, count, &tpm_response.data,
--                           &tpm_response.size) =3D=3D 0) {
--      tpm_response.size -=3D copy_to_user((char*)arg, tpm_response.data=
,
--                            tpm_response.size);
--      kfree(tpm_response.data);
--      tpm_response.data =3D NULL;
--    } else {
--      tpm_response.size =3D 0;
--      tpm_response.data =3D NULL;
--    }
--    up(&tpm_mutex);
--    return tpm_response.size;
--  }
--  return -1;
--}
--
--struct file_operations fops =3D {
--  .owner   =3D THIS_MODULE,
--  .open    =3D tpm_open,
--  .release =3D tpm_release,
--  .read    =3D tpm_read,
--  .write   =3D tpm_write,
--  .ioctl   =3D tpm_ioctl,
--};
--
--static struct miscdevice tpm_dev =3D {
--  .minor      =3D TPM_DEVICE_MINOR,
--  .name       =3D TPM_DEVICE_NAME,
--  .fops       =3D &fops,
--};
--
--int __init init_tpm_module(void)
--{
--  int res =3D misc_register(&tpm_dev);
--  if (res !=3D 0) {
--    error("misc_register() failed for minor %d\n", TPM_DEVICE_MINOR);
--    return res;
--  }
--  /* initialize variables */
--  sema_init(&tpm_mutex, 1);
--  module_state =3D 0;
--  tpm_response.data =3D NULL;
--  old_time =3D current_kernel_time();
--  /* initialize TPM emulator */
--  if (!strcmp(startup, "clear")) {
--    tpm_emulator_init(1);
--  } else if (!strcmp(startup, "save")) {
--    tpm_emulator_init(2);
--  } else if (!strcmp(startup, "deactivated")) {
--    tpm_emulator_init(3);
--  } else {
--    error("invalid startup mode '%s'; must be 'clear', "
--      "'save' (default) or 'deactivated", startup);
--    misc_deregister(&tpm_dev);
--    return -EINVAL;
--  }
--  return 0;
--}
--
--void __exit cleanup_tpm_module(void)
--{
--  tpm_emulator_shutdown();
--  misc_deregister(&tpm_dev);
--  if (tpm_response.data !=3D NULL) kfree(tpm_response.data);
--}
--
--module_init(init_tpm_module);
--module_exit(cleanup_tpm_module);
--
--uint64_t tpm_get_ticks(void)
--{
--  struct timespec new_time =3D current_kernel_time();
--  uint64_t ticks =3D (uint64_t)(new_time.tv_sec - old_time.tv_sec) * 10=
00000
--                   + (new_time.tv_nsec - old_time.tv_nsec) / 1000;
--  old_time =3D new_time;
--  return (ticks > 0) ? ticks : 1;
--}
--
-diff -uprN orig/tpm_emulator-0.4/linux_module.h tpm_emulator/linux_modul=
e.h
---- orig/tpm_emulator-0.4/linux_module.h    2006-06-23
03:37:07.000000000 -0700
-+++ tpm_emulator/linux_module.h    2006-07-24 14:35:35.000000000 -0700
-@@ -1,5 +1,6 @@
- /* Software-Based Trusted Platform Module (TPM) Emulator for Linux
-  * Copyright (C) 2004 Mario Strasser <mast@gmx.net>,
-+ * Copyright (C) 2005 INTEL Corp
-  *
-  * This module is free software; you can redistribute it and/or modify
-  * it under the terms of the GNU General Public License as published
-@@ -17,54 +18,62 @@
- #ifndef _LINUX_MODULE_H_
- #define _LINUX_MODULE_H_
-
--#include <linux/version.h>
--#include <linux/kernel.h>
--#include <linux/slab.h>
-+#include <malloc.h>
-+#include <stdint.h>
-+#include <stdio.h>
-+#include <string.h>
- #include <linux/types.h>
--#include <linux/string.h>
--#include <linux/random.h>
--#include <linux/time.h>
--#include <asm/byteorder.h>
-
--/* module settings */
-+#include <endian.h>
-+#define __BYTEORDER_HAS_U64__
-+#ifdef LITTLE_ENDIAN
-+ #include <linux/byteorder/little_endian.h>
-+#else
-+ #include <linux/byteorder/big_endian.h>
-+#endif
-
-+/* module settings */
-+#define min(A,B) ((A)<(B)?(A):(B))
-+#ifndef STR
- #define STR(s) __STR__(s)
- #define __STR__(s) #s
-+#endif
- #include "tpm_version.h"
-
- #define TPM_DEVICE_MINOR  224
- #define TPM_DEVICE_NAME   "tpm"
- #define TPM_MODULE_NAME   "tpm_emulator"
-
--/* debug and log output functions */
--
- #ifdef DEBUG
--#define debug(fmt, ...) printk(KERN_DEBUG "%s %s:%d: Debug: " fmt "\n",=
 \
--                        TPM_MODULE_NAME, __FILE__, __LINE__, ##
__VA_ARGS__)
-+#define debug(fmt, ...) printf("TPMD: %s:%d: Debug: " fmt "\n", \
-+                        __FILE__, __LINE__, ## __VA_ARGS__)
- #else
- #define debug(fmt, ...)
- #endif
--#define info(fmt, ...)  printk(KERN_INFO "%s %s:%d: Info: " fmt "\n", \=

--                        TPM_MODULE_NAME, __FILE__, __LINE__, ##
__VA_ARGS__)
--#define error(fmt, ...) printk(KERN_ERR "%s %s:%d: Error: " fmt "\n", \=

--                        TPM_MODULE_NAME, __FILE__, __LINE__, ##
__VA_ARGS__)
--#define alert(fmt, ...) printk(KERN_ALERT "%s %s:%d: Alert: " fmt "\n",=
 \
--                        TPM_MODULE_NAME, __FILE__, __LINE__, ##
__VA_ARGS__)
-+#define info(fmt, ...)  printf("TPMD: %s:%d: Info: " fmt "\n", \
-+                        __FILE__, __LINE__, ## __VA_ARGS__)
-+#define error(fmt, ...) printf("TPMD: %s:%d: Error: " fmt "\n", \
-+                        __FILE__, __LINE__, ## __VA_ARGS__)
-+#define alert(fmt, ...) printf("TPMD: %s:%d: Alert: " fmt "\n", \
-+                        __FILE__, __LINE__, ## __VA_ARGS__)
-
- /* memory allocation */
-
- static inline void *tpm_malloc(size_t size)
- {
--  return kmalloc(size, GFP_KERNEL);=20
-+  return malloc(size);=20
- }
-
- static inline void tpm_free(const void *ptr)
- {
--  if (ptr !=3D NULL) kfree(ptr);
-+  if (ptr !=3D NULL) free( (void *) ptr);
- }
-
- /* random numbers */
-
-+//FIXME;
-+void get_random_bytes(void *buf, int nbytes);
-+
- static inline void tpm_get_random_bytes(void *buf, int nbytes)
- {
-   get_random_bytes(buf, nbytes);
-@@ -84,9 +93,9 @@ uint64_t tpm_get_ticks(void);
- #define CPU_TO_LE16(x) __cpu_to_le16(x)
-
- #define BE64_TO_CPU(x) __be64_to_cpu(x)
--#define LE64_TO_CPU(x) __be64_to_cpu(x)
-+#define LE64_TO_CPU(x) __le64_to_cpu(x)
- #define BE32_TO_CPU(x) __be32_to_cpu(x)
--#define LE32_TO_CPU(x) __be32_to_cpu(x)
-+#define LE32_TO_CPU(x) __le32_to_cpu(x)
- #define BE16_TO_CPU(x) __be16_to_cpu(x)
- #define LE16_TO_CPU(x) __le16_to_cpu(x)
-
-diff -uprN orig/tpm_emulator-0.4/Makefile tpm_emulator/Makefile
---- orig/tpm_emulator-0.4/Makefile    2006-06-23 03:37:07.000000000 -070=
0
-+++ tpm_emulator/Makefile    2006-07-24 14:35:35.000000000 -0700
-@@ -1,24 +1,40 @@
- # Software-Based Trusted Platform Module (TPM) Emulator for Linux
- # Copyright (C) 2004 Mario Strasser <mast@gmx.net>
-+# Copyright (C) 2006 INTEL Corp.
- #
- # $Id: Makefile 115 2006-06-23 10:36:44Z mast $
-
--# kernel settings
--KERNEL_RELEASE :=3D $(shell uname -r)
--KERNEL_BUILD   :=3D /lib/modules/$(KERNEL_RELEASE)/build
--MOD_SUBDIR     :=3D misc
-+COMPILE_ARCH    ?=3D $(shell uname -m | sed -e s/i.86/x86_32/)
-
- # module settings
--MODULE_NAME    :=3D tpm_emulator
-+BIN            :=3D tpm_emulator
- VERSION_MAJOR  :=3D 0
- VERSION_MINOR  :=3D 4
- VERSION_BUILD  :=3D $(shell date +"%s")
-
--# enable/disable DEBUG messages
--EXTRA_CFLAGS   +=3D -Wall -DDEBUG -g=20
-+# Installation program and options
-+INSTALL         =3D install
-+INSTALL_PROG    =3D $(INSTALL) -m0755
-+INSTALL_DIR     =3D $(INSTALL) -d -m0755
-+
-+# Xen tools installation directory
-+TOOLS_INSTALL_DIR =3D $(DESTDIR)/usr/bin
-+
-+CC      :=3D gcc
-+CFLAGS  +=3D -g -Wall $(INCLUDE) -DDEBUG
-+CFLAGS  +=3D -I. -Itpm
-+
-+# Is the simulator running in it's own vm?
-+#CFLAGS +=3D -DVTPM_MULTI_VM
-+
-+ifeq ($(COMPILE_ARCH),x86_64)
-+LIBDIR =3D lib64
-+else
-+LIBDIR =3D lib
-+endif
-
- # GNU MP configuration
--GMP_LIB        :=3D /usr/lib/libgmp.a
-+GMP_LIB        :=3D /usr/$(LIBDIR)/libgmp.a
- GMP_HEADER     :=3D /usr/include/gmp.h
-
- # sources and objects
-@@ -27,38 +43,32 @@ DIRS           :=3D . crypto tpm
- SRCS           :=3D $(foreach dir, $(DIRS), $(wildcard $(src)/$(dir)/*.=
c))
- OBJS           :=3D $(patsubst %.c, %.o, $(SRCS))
- SRCS           +=3D $(foreach dir, $(DIRS), $(wildcard $(src)/$(dir)/*.=
h))
--DISTSRC        :=3D ./README ./AUTHORS ./ChangeLog ./Makefile $(SRCS)
--DISTDIR        :=3D tpm_emulator-$(VERSION_MAJOR).$(VERSION_MINOR)
-
--obj-m               :=3D $(MODULE_NAME).o
--$(MODULE_NAME)-objs :=3D $(patsubst $(src)/%.o, %.o, $(OBJS))
crypto/libgmp.a
-+obj-m               :=3D $(BIN)
-+$(BIN)-objs :=3D $(patsubst $(src)/%.o, %.o, $(OBJS)) crypto/libgmp.a
-
- EXTRA_CFLAGS   +=3D -I$(src) -I$(src)/crypto -I$(src)/tpm
-
- # do not print "Entering directory ..."
- MAKEFLAGS      +=3D --no-print-directory
-
--all:    $(src)/crypto/gmp.h $(src)/crypto/libgmp.a version
--    @$(MAKE) -C $(KERNEL_BUILD) M=3D$(CURDIR) modules
-+all: $(BIN)
-
--install:
--    @$(MAKE) -C $(KERNEL_BUILD) M=3D$(CURDIR) modules_install
--    test -d /var/tpm || mkdir /var/tpm
--    test -c /dev/tpm || mknod /dev/tpm c 10 224
--    chmod 666 /dev/tpm
--    depmod -a
-+$(BIN):    $(src)/crypto/gmp.h $(src)/crypto/libgmp.a version $(SRCS)
$(OBJS)
-+    $(CC) $(CFLAGS) $(OBJS) $(src)/crypto/libgmp.a -o $(BIN)
-+
-+%.o: %.c
-+    $(CC) $(CFLAGS) -c $< -o $@
-+
-+install: $(BIN)
-+    $(INSTALL_PROG) $(BIN) $(TOOLS_INSTALL_DIR)
-+    @if [ ! -d "/var/tpm" ]; then mkdir /var/tpm; fi
-
- clean:
--    @$(MAKE) -C $(KERNEL_BUILD) M=3D$(CURDIR) clean
--    rm -f $(src)/crypto/gmp.h $(src)/crypto/libgmp.a
-+    rm -f $(src)/crypto/gmp.h $(src)/crypto/libgmp.a $(OBJS)
-
--dist:    $(DISTSRC)
--    rm -rf $(DISTDIR)
--    mkdir $(DISTDIR)
--    cp --parents $(DISTSRC) $(DISTDIR)/
--    rm -f $(DISTDIR)/crypto/gmp.h
--    tar -chzf $(DISTDIR).tar.gz $(DISTDIR)
--    rm -rf $(DISTDIR)
-+mrproper: clean
-+    rm -f $(BIN) tpm_version.h
-
- $(src)/crypto/libgmp.a:
-     test -f $(src)/crypto/libgmp.a || ln -s $(GMP_LIB)
$(src)/crypto/libgmp.a
-@@ -88,4 +98,3 @@ version:
-     @echo "#endif /* _TPM_VERSION_H_ */" >> $(src)/tpm_version.h
-
- .PHONY: all install clean dist gmp version
--
-diff -uprN orig/tpm_emulator-0.4/README tpm_emulator/README
---- orig/tpm_emulator-0.4/README    2006-06-23 03:37:07.000000000 -0700
-+++ tpm_emulator/README    2006-07-24 14:35:35.000000000 -0700
-@@ -13,7 +13,8 @@ $Id: README 113 2006-06-18 12:38:13Z hst
- Copyright
- -----------------------------------------------------------------------=
---
- Copyright (C) 2004 Mario Strasser <mast@gmx.net> and Swiss Federal
--Institute of Technology (ETH) Zurich.
-+                   Institute of Technology (ETH) Zurich.
-+Copyright (C) 2005 INTEL Corp
-             =20
- 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
-@@ -43,6 +44,12 @@ Example:
- GMP_LIB        :=3D /usr/lib/libgmp.a
- GMP_HEADER     :=3D /usr/include/gmp.h
-
-+GNU MP Library on 64 bit Systems
-+-----------------------------------------------------------------------=
---
-+Some 64-bit kernels have problems with importing the user-space gmp
-+library (/usr/lib*/libgmp.a) into kernel space.  These kernels will
require
-+that the gmp library be recompiled for kernel space with -mcmodel=3Dker=
nel.
-+
- Installation
- -----------------------------------------------------------------------=
---
- The compilation and installation process uses the build environment for=

-diff -uprN orig/tpm_emulator-0.4/tpm/tpm_capability.c
tpm_emulator/tpm/tpm_capability.c
---- orig/tpm_emulator-0.4/tpm/tpm_capability.c    2006-06-23
19:37:07.000000000 +0900
-+++ tpm_emulator/tpm/tpm_capability.c    2007-12-28 22:50:19.000000000
+0900
-@@ -701,7 +701,10 @@ TPM_RESULT TPM_GetCapabilityOwner(TPM_VE
-   TPM_RESULT res;
- =20
-   info("TPM_GetCapabilityOwner()");
--=20
-+
-+  if (!tpmData.permanent.flags.owned) {
-+    return TPM_NOSRK;
-+  }
-   /* Verify owner authorization */
-   res =3D tpm_verify_auth(auth1, tpmData.permanent.data.ownerAuth,
TPM_KH_OWNER);
-   if (res !=3D TPM_SUCCESS) return res;
-diff -uprN orig/tpm_emulator-0.4/tpm/tpm_cmd_handler.c
tpm_emulator/tpm/tpm_cmd_handler.c
---- orig/tpm_emulator-0.4/tpm/tpm_cmd_handler.c    2006-06-23
19:37:07.000000000 +0900
-+++ tpm_emulator/tpm/tpm_cmd_handler.c    2007-09-12 20:23:00.000000000
+0900
-@@ -565,7 +565,7 @@ static TPM_RESULT execute_TPM_Seal(TPM_R
-   if (tpm_unmarshal_TPM_KEY_HANDLE(&ptr, &len, &keyHandle)
-       || tpm_unmarshal_TPM_ENCAUTH(&ptr, &len, &encAuth)
-       || tpm_unmarshal_UINT32(&ptr, &len, &pcrInfoSize)
--      || tpm_unmarshal_TPM_PCR_INFO(&ptr, &len, &pcrInfo)
-+      || (pcrInfoSize >0 && tpm_unmarshal_TPM_PCR_INFO(&ptr, &len,
&pcrInfo))
-       || tpm_unmarshal_UINT32(&ptr, &len, &inDataSize)
-       || tpm_unmarshal_BLOB(&ptr, &len, &inData, inDataSize)
-       || len !=3D 0) return TPM_BAD_PARAMETER;
-@@ -798,7 +798,7 @@ static TPM_RESULT execute_TPM_Sealx(TPM_
-   if (tpm_unmarshal_TPM_KEY_HANDLE(&ptr, &len, &keyHandle)
-       || tpm_unmarshal_TPM_ENCAUTH(&ptr, &len, &encAuth)
-       || tpm_unmarshal_UINT32(&ptr, &len, &pcrInfoSize)
--      || tpm_unmarshal_TPM_PCR_INFO(&ptr, &len, &pcrInfo)
-+      || (pcrInfoSize > 0 && tpm_unmarshal_TPM_PCR_INFO(&ptr, &len,
&pcrInfo))
-       || tpm_unmarshal_UINT32(&ptr, &len, &inDataSize)
-       || tpm_unmarshal_BLOB(&ptr, &len, &inData, inDataSize)
-       || len !=3D 0) return TPM_BAD_PARAMETER;
-diff -uprN orig/tpm_emulator-0.4/tpm/tpm_credentials.c
tpm_emulator/tpm/tpm_credentials.c
---- orig/tpm_emulator-0.4/tpm/tpm_credentials.c    2006-06-23
19:37:07.000000000 +0900
-+++ tpm_emulator/tpm/tpm_credentials.c    2007-09-12 20:23:30.000000000
+0900
-@@ -47,20 +47,20 @@ int tpm_compute_pubkey_checksum(TPM_NONC
-
- TPM_RESULT tpm_get_pubek(TPM_PUBKEY *pubEndorsementKey)
- {
--  UINT32 key_length;
-+  size_t key_length;
-   if (!tpmData.permanent.data.endorsementKey.size) return
TPM_NO_ENDORSEMENT;
-   /* setup TPM_PUBKEY structure */
--  key_length =3D tpmData.permanent.data.endorsementKey.size;
--  pubEndorsementKey->pubKey.keyLength =3D key_length >> 3;
-+  pubEndorsementKey->pubKey.keyLength =3D
tpmData.permanent.data.endorsementKey.size >> 3;
-   pubEndorsementKey->pubKey.key =3D
tpm_malloc(pubEndorsementKey->pubKey.keyLength);
-   if (pubEndorsementKey->pubKey.key =3D=3D NULL) return TPM_FAIL;
-   rsa_export_modulus(&tpmData.permanent.data.endorsementKey,
--    pubEndorsementKey->pubKey.key,
--    &pubEndorsementKey->pubKey.keyLength);
-+             pubEndorsementKey->pubKey.key,
-+             &key_length);
-+  pubEndorsementKey->pubKey.keyLength =3D key_length;
-   pubEndorsementKey->algorithmParms.algorithmID =3D TPM_ALG_RSA;
-   pubEndorsementKey->algorithmParms.encScheme =3D
TPM_ES_RSAESOAEP_SHA1_MGF1;
-   pubEndorsementKey->algorithmParms.sigScheme =3D TPM_SS_NONE;
--  pubEndorsementKey->algorithmParms.parms.rsa.keyLength =3D key_length;=

-+  pubEndorsementKey->algorithmParms.parms.rsa.keyLength =3D key_length =
<< 3;
-   pubEndorsementKey->algorithmParms.parms.rsa.numPrimes =3D 2;
-   pubEndorsementKey->algorithmParms.parms.rsa.exponentSize =3D 0;
-   pubEndorsementKey->algorithmParms.parms.rsa.exponent =3D NULL;
-@@ -175,6 +175,7 @@ TPM_RESULT TPM_OwnerReadInternalPub(TPM_
- {
-   TPM_RESULT res;
-   TPM_KEY_DATA *srk =3D &tpmData.permanent.data.srk;
-+  size_t key_length;
-   info("TPM_OwnerReadInternalPub()");
-   /* verify authorization */
-   res =3D tpm_verify_auth(auth1, tpmData.permanent.data.ownerAuth,
TPM_KH_OWNER);
-@@ -186,7 +187,8 @@ TPM_RESULT TPM_OwnerReadInternalPub(TPM_
-     publicPortion->pubKey.key =3D
tpm_malloc(publicPortion->pubKey.keyLength);
-     if (publicPortion->pubKey.key =3D=3D NULL) return TPM_FAIL;
-     rsa_export_modulus(&srk->key, publicPortion->pubKey.key,
--      &publicPortion->pubKey.keyLength);
-+      &key_length);
-+    publicPortion->pubKey.keyLength =3D key_length;
-     publicPortion->algorithmParms.algorithmID =3D TPM_ALG_RSA;
-     publicPortion->algorithmParms.encScheme =3D srk->encScheme;
-     publicPortion->algorithmParms.sigScheme =3D srk->sigScheme;
-diff -uprN orig/tpm_emulator-0.4/tpm/tpm_crypto.c
tpm_emulator/tpm/tpm_crypto.c
---- orig/tpm_emulator-0.4/tpm/tpm_crypto.c    2006-06-23
03:37:07.000000000 -0700
-+++ tpm_emulator/tpm/tpm_crypto.c    2006-07-24 14:35:35.000000000 -0700=

-@@ -182,7 +182,8 @@ TPM_RESULT TPM_CertifyKey(TPM_KEY_HANDLE
-   TPM_KEY_DATA *cert, *key;
-   sha1_ctx_t sha1_ctx;
-   BYTE *buf, *p;
--  UINT32 length;
-+  UINT32 length32;
-+  size_t length;
-   info("TPM_CertifyKey()");
-   /* get keys */
-   cert =3D tpm_get_key(certHandle);
-@@ -264,14 +265,15 @@ TPM_RESULT TPM_CertifyKey(TPM_KEY_HANDLE
-   /* compute the digest of the CERTIFY_INFO[2] structure and sign it */=

-   length =3D sizeof_TPM_CERTIFY_INFO((*certifyInfo));
-   p =3D buf =3D tpm_malloc(length);
-+  length32=3D(UINT32) length;
-   if (buf =3D=3D NULL
--      || tpm_marshal_TPM_CERTIFY_INFO(&p, &length, certifyInfo)) {
-+      || tpm_marshal_TPM_CERTIFY_INFO(&p, &length32, certifyInfo)) {
-     free_TPM_KEY_PARMS(certifyInfo->algorithmParms);
-     return TPM_FAIL;
-   }
-   length =3D sizeof_TPM_CERTIFY_INFO((*certifyInfo));
-   sha1_init(&sha1_ctx);
--  sha1_update(&sha1_ctx, buf, length);
-+  sha1_update(&sha1_ctx, buf, (size_t) length);
-   sha1_final(&sha1_ctx, buf);
-   res =3D tpm_sign(cert, auth1, FALSE, buf, SHA1_DIGEST_LENGTH, outData=
,
outDataSize);
-   tpm_free(buf);
-@@ -292,7 +294,8 @@ TPM_RESULT TPM_CertifyKey2(TPM_KEY_HANDL
-   TPM_KEY_DATA *cert, *key;
-   sha1_ctx_t sha1_ctx;
-   BYTE *buf, *p;
--  UINT32 length;
-+  size_t length;
-+  UINT32 length32;
-   info("TPM_CertifyKey2()");
-   /* get keys */
-   cert =3D tpm_get_key(certHandle);
-@@ -362,8 +365,9 @@ TPM_RESULT TPM_CertifyKey2(TPM_KEY_HANDL
-   /* compute the digest of the CERTIFY_INFO[2] structure and sign it */=

-   length =3D sizeof_TPM_CERTIFY_INFO((*certifyInfo));
-   p =3D buf =3D tpm_malloc(length);
-+  length32 =3D (UINT32) length;
-   if (buf =3D=3D NULL
--      || tpm_marshal_TPM_CERTIFY_INFO(&p, &length, certifyInfo)) {
-+      || tpm_marshal_TPM_CERTIFY_INFO(&p, &length32, certifyInfo)) {
-     free_TPM_KEY_PARMS(certifyInfo->algorithmParms);
-     return TPM_FAIL;
-   }
-diff -uprN orig/tpm_emulator-0.4/tpm/tpm_daa.c tpm_emulator/tpm/tpm_daa.=
c
---- orig/tpm_emulator-0.4/tpm/tpm_daa.c    2006-06-23
03:37:07.000000000 -0700
-+++ tpm_emulator/tpm/tpm_daa.c    2006-07-24 14:35:35.000000000 -0700
-@@ -716,14 +716,14 @@ TPM_RESULT TPM_DAA_Join(TPM_HANDLE handl
-           sizeof(session->DAA_tpmSpecific.DAA_rekey));
-       sha1_update(&sha1, (BYTE*) &session->DAA_tpmSpecific.DAA_count,
-           sizeof(session->DAA_tpmSpecific.DAA_count));
--      sha1_update(&sha1, "\x00", 1);
-+      sha1_update(&sha1, (BYTE *) "\x00", 1);
-       sha1_final(&sha1, scratch);
-       sha1_init(&sha1);
-       sha1_update(&sha1, (BYTE*) &session->DAA_tpmSpecific.DAA_rekey,
-           sizeof(session->DAA_tpmSpecific.DAA_rekey));
-       sha1_update(&sha1, (BYTE*) &session->DAA_tpmSpecific.DAA_count,
-           sizeof(session->DAA_tpmSpecific.DAA_count));
--      sha1_update(&sha1, "\x01", 1);
-+      sha1_update(&sha1, (BYTE *) "\x01", 1);
-       sha1_final(&sha1, scratch + SHA1_DIGEST_LENGTH);
-       mpz_init(f), mpz_init(q);
-       mpz_import(f, 2 * SHA1_DIGEST_LENGTH, 1, 1, 0, 0, scratch);
-@@ -805,14 +805,14 @@ TPM_RESULT TPM_DAA_Join(TPM_HANDLE handl
-           sizeof(session->DAA_tpmSpecific.DAA_rekey));
-       sha1_update(&sha1, (BYTE*) &session->DAA_tpmSpecific.DAA_count,
-           sizeof(session->DAA_tpmSpecific.DAA_count));
--      sha1_update(&sha1, "\x00", 1);
-+      sha1_update(&sha1, (BYTE *) "\x00", 1);
-       sha1_final(&sha1, scratch);
-       sha1_init(&sha1);
-       sha1_update(&sha1, (BYTE*) &session->DAA_tpmSpecific.DAA_rekey,
-           sizeof(session->DAA_tpmSpecific.DAA_rekey));
-       sha1_update(&sha1, (BYTE*) &session->DAA_tpmSpecific.DAA_count,
-           sizeof(session->DAA_tpmSpecific.DAA_count));
--      sha1_update(&sha1, "\x01", 1);
-+      sha1_update(&sha1, (BYTE *) "\x01", 1);
-       sha1_final(&sha1, scratch + SHA1_DIGEST_LENGTH);
-       mpz_init(f), mpz_init(q);
-       mpz_import(f, 2 * SHA1_DIGEST_LENGTH, 1, 1, 0, 0, scratch);
-@@ -1489,14 +1489,14 @@ TPM_RESULT TPM_DAA_Join(TPM_HANDLE handl
-           sizeof(session->DAA_tpmSpecific.DAA_rekey));
-       sha1_update(&sha1, (BYTE*) &session->DAA_tpmSpecific.DAA_count,
-           sizeof(session->DAA_tpmSpecific.DAA_count));
--      sha1_update(&sha1, "\x00", 1);
-+      sha1_update(&sha1, (BYTE *) "\x00", 1);
-       sha1_final(&sha1, scratch);
-       sha1_init(&sha1);
-       sha1_update(&sha1, (BYTE*) &session->DAA_tpmSpecific.DAA_rekey,
-           sizeof(session->DAA_tpmSpecific.DAA_rekey));
-       sha1_update(&sha1, (BYTE*) &session->DAA_tpmSpecific.DAA_count,
-           sizeof(session->DAA_tpmSpecific.DAA_count));
--      sha1_update(&sha1, "\x01", 1);
-+      sha1_update(&sha1, (BYTE *) "\x01", 1);
-       sha1_final(&sha1, scratch + SHA1_DIGEST_LENGTH);
-       mpz_init(f), mpz_init(q);
-       mpz_import(f, 2 * SHA1_DIGEST_LENGTH, 1, 1, 0, 0, scratch);
-@@ -1712,14 +1712,14 @@ TPM_RESULT TPM_DAA_Join(TPM_HANDLE handl
-           sizeof(session->DAA_tpmSpecific.DAA_rekey));
-       sha1_update(&sha1, (BYTE*) &session->DAA_tpmSpecific.DAA_count,
-           sizeof(session->DAA_tpmSpecific.DAA_count));
--      sha1_update(&sha1, "\x00", 1);
-+      sha1_update(&sha1, (BYTE *) "\x00", 1);
-       sha1_final(&sha1, scratch);
-       sha1_init(&sha1);
-       sha1_update(&sha1, (BYTE*) &session->DAA_tpmSpecific.DAA_rekey,
-           sizeof(session->DAA_tpmSpecific.DAA_rekey));
-       sha1_update(&sha1, (BYTE*) &session->DAA_tpmSpecific.DAA_count,
-           sizeof(session->DAA_tpmSpecific.DAA_count));
--      sha1_update(&sha1, "\x01", 1);
-+      sha1_update(&sha1, (BYTE *) "\x01", 1);
-       sha1_final(&sha1, scratch + SHA1_DIGEST_LENGTH);
-       mpz_init(f), mpz_init(q);
-       mpz_import(f, 2 * SHA1_DIGEST_LENGTH, 1, 1, 0, 0, scratch);
-@@ -1793,14 +1793,14 @@ TPM_RESULT TPM_DAA_Join(TPM_HANDLE handl
-           sizeof(session->DAA_tpmSpecific.DAA_rekey));
-       sha1_update(&sha1, (BYTE*) &session->DAA_tpmSpecific.DAA_count,
-           sizeof(session->DAA_tpmSpecific.DAA_count));
--      sha1_update(&sha1, "\x00", 1);
-+      sha1_update(&sha1, (BYTE *) "\x00", 1);
-       sha1_final(&sha1, scratch);
-       sha1_init(&sha1);
-       sha1_update(&sha1, (BYTE*) &session->DAA_tpmSpecific.DAA_rekey,
-           sizeof(session->DAA_tpmSpecific.DAA_rekey));
-       sha1_update(&sha1, (BYTE*) &session->DAA_tpmSpecific.DAA_count,
-           sizeof(session->DAA_tpmSpecific.DAA_count));
--      sha1_update(&sha1, "\x01", 1);
-+      sha1_update(&sha1, (BYTE *) "\x01", 1);
-       sha1_final(&sha1, scratch + SHA1_DIGEST_LENGTH);
-       mpz_init(f), mpz_init(q);
-       mpz_import(f, 2 * SHA1_DIGEST_LENGTH, 1, 1, 0, 0, scratch);
-@@ -2918,14 +2918,14 @@ TPM_RESULT TPM_DAA_Sign(TPM_HANDLE handl
-           sizeof(session->DAA_tpmSpecific.DAA_rekey));
-       sha1_update(&sha1, (BYTE*) &session->DAA_tpmSpecific.DAA_count,
-           sizeof(session->DAA_tpmSpecific.DAA_count));
--      sha1_update(&sha1, "\x00", 1);
-+      sha1_update(&sha1, (BYTE *) "\x00", 1);
-       sha1_final(&sha1, scratch);
-       sha1_init(&sha1);
-       sha1_update(&sha1, (BYTE*) &session->DAA_tpmSpecific.DAA_rekey,
-           sizeof(session->DAA_tpmSpecific.DAA_rekey));
-       sha1_update(&sha1, (BYTE*) &session->DAA_tpmSpecific.DAA_count,
-           sizeof(session->DAA_tpmSpecific.DAA_count));
--      sha1_update(&sha1, "\x01", 1);
-+      sha1_update(&sha1, (BYTE *) "\x01", 1);
-       sha1_final(&sha1, scratch + SHA1_DIGEST_LENGTH);
-       mpz_init(f), mpz_init(q);
-       mpz_import(f, 2 * SHA1_DIGEST_LENGTH, 1, 1, 0, 0, scratch);
-@@ -3143,7 +3143,7 @@ TPM_RESULT TPM_DAA_Sign(TPM_HANDLE handl
-         sha1_init(&sha1);
-         sha1_update(&sha1, (BYTE*) &session->DAA_session.DAA_digest,
-           sizeof(session->DAA_session.DAA_digest));
--        sha1_update(&sha1, "\x01", 1);
-+        sha1_update(&sha1, (BYTE *) "\x01", 1);
-         sha1_update(&sha1, inputData1, inputSize1);
-         sha1_final(&sha1, (BYTE*) &session->DAA_session.DAA_digest);
-       }
-@@ -3172,7 +3172,7 @@ TPM_RESULT TPM_DAA_Sign(TPM_HANDLE handl
-         sha1_init(&sha1);
-         sha1_update(&sha1, (BYTE*) &session->DAA_session.DAA_digest,
-           sizeof(session->DAA_session.DAA_digest));
--        sha1_update(&sha1, "\x00", 1);
-+        sha1_update(&sha1, (BYTE*) "\x00", 1);
-         rsa_export_modulus(&aikData->key, scratch, &size);
-         sha1_update(&sha1, scratch, size);
-         sha1_final(&sha1, (BYTE*) &session->DAA_session.DAA_digest);
-@@ -3229,14 +3229,14 @@ TPM_RESULT TPM_DAA_Sign(TPM_HANDLE handl
-           sizeof(session->DAA_tpmSpecific.DAA_rekey));
-       sha1_update(&sha1, (BYTE*) &session->DAA_tpmSpecific.DAA_count,
-           sizeof(session->DAA_tpmSpecific.DAA_count));
--      sha1_update(&sha1, "\x00", 1);
-+      sha1_update(&sha1, (BYTE *) "\x00", 1);
-       sha1_final(&sha1, scratch);
-       sha1_init(&sha1);
-       sha1_update(&sha1, (BYTE*) &session->DAA_tpmSpecific.DAA_rekey,
-           sizeof(session->DAA_tpmSpecific.DAA_rekey));
-       sha1_update(&sha1, (BYTE*) &session->DAA_tpmSpecific.DAA_count,
-           sizeof(session->DAA_tpmSpecific.DAA_count));
--      sha1_update(&sha1, "\x01", 1);
-+      sha1_update(&sha1, (BYTE *) "\x01", 1);
-       sha1_final(&sha1, scratch + SHA1_DIGEST_LENGTH);
-       mpz_init(f), mpz_init(q);
-       mpz_import(f, 2 * SHA1_DIGEST_LENGTH, 1, 1, 0, 0, scratch);
-@@ -3309,14 +3309,14 @@ TPM_RESULT TPM_DAA_Sign(TPM_HANDLE handl
-           sizeof(session->DAA_tpmSpecific.DAA_rekey));
-       sha1_update(&sha1, (BYTE*) &session->DAA_tpmSpecific.DAA_count,
-           sizeof(session->DAA_tpmSpecific.DAA_count));
--      sha1_update(&sha1, "\x00", 1);
-+      sha1_update(&sha1, (BYTE *) "\x00", 1);
-       sha1_final(&sha1, scratch);
-       sha1_init(&sha1);
-       sha1_update(&sha1, (BYTE*) &session->DAA_tpmSpecific.DAA_rekey,
-           sizeof(session->DAA_tpmSpecific.DAA_rekey));
-       sha1_update(&sha1, (BYTE*) &session->DAA_tpmSpecific.DAA_count,
-           sizeof(session->DAA_tpmSpecific.DAA_count));
--      sha1_update(&sha1, "\x01", 1);
-+      sha1_update(&sha1, (BYTE *) "\x01", 1);
-       sha1_final(&sha1, scratch + SHA1_DIGEST_LENGTH);
-       mpz_init(f), mpz_init(q);
-       mpz_import(f, 2 * SHA1_DIGEST_LENGTH, 1, 1, 0, 0, scratch);
-diff -uprN orig/tpm_emulator-0.4/tpm/tpm_data.c tpm_emulator/tpm/tpm_dat=
a.c
---- orig/tpm_emulator-0.4/tpm/tpm_data.c    2006-06-23
03:37:07.000000000 -0700
-+++ tpm_emulator/tpm/tpm_data.c    2006-07-24 14:35:35.000000000 -0700
-@@ -40,6 +40,7 @@ static inline void init_pcr_attr(int pcr
- void tpm_init_data(void)
- {
-   /* endorsement key */
-+#ifndef TPM_GENERATE_EK
-   uint8_t ek_n[] =3D=20
"\xa8\xdb\xa9\x42\xa8\xf3\xb8\x06\x85\x90\x76\x93\xad\xf7"
-     "\x74\xec\x3f\xd3\x3d\x9d\xe8\x2e\xff\x15\xed\x0e\xce\x5f\x93"
-     "\x92\xeb\xd1\x96\x2b\x72\x18\x81\x79\x12\x9d\x9c\x40\xd7\x1a"
-@@ -77,6 +78,8 @@ void tpm_init_data(void)
-     "\xd1\xc0\x8b\x5b\xa2\x2e\xa7\x15\xca\x50\x75\x10\x48\x9c\x2b"
-     "\x18\xb9\x67\x8f\x5d\x64\xc3\x28\x9f\x2f\x16\x2f\x08\xda\x47"
-     "\xec\x86\x43\x0c\x80\x99\x07\x34\x0f";
-+#endif
-+
-   int i;
-   /* reset all data to NULL, FALSE or 0 */
-   memset(&tpmData, 0, sizeof(tpmData));
-@@ -152,44 +155,43 @@ void tpm_release_data(void)
-
- #ifdef TPM_STORE_TO_FILE
-
--#include <linux/fs.h>
--#include <linux/unistd.h>
--#include <asm/uaccess.h>
-+#include <sys/types.h>
-+#include <sys/stat.h>
-+#include <fcntl.h>
-+#include <unistd.h>
-
- #define TPM_STORAGE_FILE "/var/tpm/tpm_emulator-1.2."
STR(VERSION_MAJOR) "." STR(VERSION_MINOR)
-
- static int write_to_file(uint8_t *data, size_t data_length)
- {
-   int res;
--  struct file *fp;
--  mm_segment_t old_fs =3D get_fs();
--  fp =3D filp_open(TPM_STORAGE_FILE, O_WRONLY | O_TRUNC | O_CREAT,
S_IRUSR | S_IWUSR);
--  if (IS_ERR(fp)) return -1;
--  set_fs(get_ds());
--  res =3D fp->f_op->write(fp, data, data_length, &fp->f_pos);
--  set_fs(old_fs);
--  filp_close(fp, NULL);
-+  int fp;
-+  fp =3D open(TPM_STORAGE_FILE, O_WRONLY | O_TRUNC | O_CREAT, S_IRUSR |=

S_IWUSR);
-+  res =3D write(fp, data, data_length);
-+  close(fp);
-   return (res =3D=3D data_length) ? 0 : -1;
- }
-
- static int read_from_file(uint8_t **data, size_t *data_length)
- {
-   int res;
--  struct file *fp;
--  mm_segment_t old_fs =3D get_fs();
--  fp =3D filp_open(TPM_STORAGE_FILE, O_RDONLY, 0);
--  if (IS_ERR(fp)) return -1;
--  *data_length =3D (size_t)fp->f_dentry->d_inode->i_size;
--  /* *data_length =3D i_size_read(fp->f_dentry->d_inode); */
-+  int fp, file_status;
-+  struct stat file_info;
-+  fp =3D open(TPM_STORAGE_FILE, O_RDONLY, 0);
-+  file_status =3D fstat(fp, &file_info);
-+  if (file_status < 0) {
-+    close(fp);
-+    return -1;
-+  }
-+
-+  *data_length =3D file_info.st_size;
-   *data =3D tpm_malloc(*data_length);
-   if (*data =3D=3D NULL) {
--    filp_close(fp, NULL);
-+    close(fp);
-     return -1;
-   }
--  set_fs(get_ds());
--  res =3D fp->f_op->read(fp, *data, *data_length, &fp->f_pos);
--  set_fs(old_fs);
--  filp_close(fp, NULL);
-+  res =3D read(fp, *data, *data_length);
-+  close(fp);
-   if (res !=3D *data_length) {
-     tpm_free(*data);
-     return -1;
-@@ -216,23 +218,30 @@ static int read_from_file(uint8_t **data
- int tpm_store_permanent_data(void)
- {
-   uint8_t *buf, *ptr;
--  size_t buf_length, len;
-+  UINT32 buf_length, len;
-
-   /* marshal data */
--  buf_length =3D len =3D sizeof_TPM_STCLEAR_FLAGS(tpmData.stclear.flags=
)
--    + sizeof_TPM_PERMANENT_FLAGS(tpmData.permanent.flags) + 2
--    + sizeof_TPM_PERMANENT_DATA(tpmData.permanent.data);
-+  buf_length =3D len =3D 4 + sizeof_TPM_STCLEAR_FLAGS(tpmData.stclear.f=
lags)
-+    + sizeof_TPM_PERMANENT_FLAGS(tpmData.permanent.flags)
-+    + sizeof_TPM_STANY_FLAGS(tpmData.stany.flags) + 2
-+    + sizeof_TPM_STCLEAR_DATA(tpmData.stclear.data)
-+    + sizeof_TPM_PERMANENT_DATA(tpmData.permanent.data)
-+    + sizeof_TPM_STANY_DATA(tpmData.stany.data);
-   buf =3D ptr =3D tpm_malloc(buf_length);
-   if (buf =3D=3D NULL
-       || tpm_marshal_TPM_VERSION(&ptr, &len,
&tpmData.permanent.data.version)
-       || tpm_marshal_TPM_STCLEAR_FLAGS(&ptr, &len, &tpmData.stclear.fla=
gs)
-       || tpm_marshal_TPM_PERMANENT_FLAGS(&ptr, &len,
&tpmData.permanent.flags)
-+      || tpm_marshal_TPM_STANY_FLAGS(&ptr, &len, &tpmData.stany.flags)
-       || tpm_marshal_BOOL(&ptr, &len,
tpmData.permanent.flags.selfTestSucceeded)
-       || tpm_marshal_BOOL(&ptr, &len, tpmData.permanent.flags.owned)
--      || tpm_marshal_TPM_PERMANENT_DATA(&ptr, &len,
&tpmData.permanent.data)) {
-+      || tpm_marshal_TPM_STCLEAR_DATA(&ptr, &len, &tpmData.stclear.data=
)
-+      || tpm_marshal_TPM_PERMANENT_DATA(&ptr, &len,
&tpmData.permanent.data)
-+      || tpm_marshal_TPM_STANY_DATA(&ptr, &len, &tpmData.stany.data)) {=

-     tpm_free(buf);
-     return -1;
-   }
-+
-   if (write_to_file(buf, buf_length - len)) {
-     tpm_free(buf);
-     return -1;
-@@ -244,31 +253,36 @@ int tpm_store_permanent_data(void)
- int tpm_restore_permanent_data(void)
- {
-   uint8_t *buf, *ptr;
--  size_t buf_length, len;
-+  size_t buf_length;
-+  UINT32 len;
-   TPM_VERSION ver;
-
-   /* read data */
-   if (read_from_file(&buf, &buf_length)) return -1;
-   ptr =3D buf;
--  len =3D buf_length;
-+  len =3D (uint32_t) buf_length;
-   /* unmarshal data */
-   if (tpm_unmarshal_TPM_VERSION(&ptr, &len, &ver)
-       || memcmp(&ver, &tpmData.permanent.data.version,
sizeof(TPM_VERSION))
-       || tpm_unmarshal_TPM_STCLEAR_FLAGS(&ptr, &len,
&tpmData.stclear.flags)
-       || tpm_unmarshal_TPM_PERMANENT_FLAGS(&ptr, &len,
&tpmData.permanent.flags)
-+      || tpm_unmarshal_TPM_STANY_FLAGS(&ptr, &len, &tpmData.stany.flags=
)
-       || tpm_unmarshal_BOOL(&ptr, &len,
&tpmData.permanent.flags.selfTestSucceeded)
-       || tpm_unmarshal_BOOL(&ptr, &len, &tpmData.permanent.flags.owned)=

--      || tpm_unmarshal_TPM_PERMANENT_DATA(&ptr, &len,
&tpmData.permanent.data)) {
-+      || tpm_unmarshal_TPM_STCLEAR_DATA(&ptr, &len, &tpmData.stclear.da=
ta)
-+      || tpm_unmarshal_TPM_PERMANENT_DATA(&ptr, &len,
&tpmData.permanent.data)
-+      || tpm_unmarshal_TPM_STANY_DATA(&ptr, &len, &tpmData.stany.data))=
 {
-     tpm_free(buf);
-     return -1;
-   }
-+
-   tpm_free(buf);
-   return 0;
- }
-
- int tpm_erase_permanent_data(void)
- {
--  int res =3D write_to_file("", 0);
-+  int res =3D write_to_file((uint8_t *) "", 0);
-   return res;
- }
-
-diff -uprN orig/tpm_emulator-0.4/tpm/tpm_deprecated.c
tpm_emulator/tpm/tpm_deprecated.c
---- orig/tpm_emulator-0.4/tpm/tpm_deprecated.c    2006-06-23
03:37:07.000000000 -0700
-+++ tpm_emulator/tpm/tpm_deprecated.c    2006-07-24 14:35:35.000000000
-0700
-@@ -1,6 +1,7 @@
- /* Software-Based Trusted Platform Module (TPM) Emulator for Linux
-  * Copyright (C) 2004 Mario Strasser <mast@gmx.net>,
-  *                    Swiss Federal Institute of Technology (ETH) Zuric=
h
-+ * Copyright (C) 2005 INTEL Corp
-  *
-  * This module is free software; you can redistribute it and/or modify
-  * it under the terms of the GNU General Public License as published
-@@ -50,7 +51,7 @@ TPM_RESULT TPM_SaveKeyContext(TPM_KEY_HA
-   BYTE *ptr;
-   UINT32 len;
-   info("TPM_SaveKeyContext()");
--  res =3D TPM_SaveContext(keyHandle, TPM_RT_KEY, "SaveKeyContext..",
-+  res =3D TPM_SaveContext(keyHandle, TPM_RT_KEY, (BYTE*)"SaveKeyContext=
=2E.",
-                         keyContextSize, &contextBlob);
-   if (res !=3D TPM_SUCCESS) return res;
-   len =3D *keyContextSize;
-@@ -82,7 +83,7 @@ TPM_RESULT TPM_SaveAuthContext(TPM_AUTHH
-   BYTE *ptr;
-   UINT32 len;
-   info("TPM_SaveAuthContext()");
--  res =3D TPM_SaveContext(authHandle, TPM_RT_KEY, "SaveAuthContext.",
-+  res =3D TPM_SaveContext(authHandle, TPM_RT_KEY,
(BYTE*)"SaveAuthContext.",
-                         authContextSize, &contextBlob);
-   if (res !=3D TPM_SUCCESS) return res;
-   len =3D *authContextSize;
-diff -uprN orig/tpm_emulator-0.4/tpm/tpm_emulator.h
tpm_emulator/tpm/tpm_emulator.h
---- orig/tpm_emulator-0.4/tpm/tpm_emulator.h    2006-06-23
03:37:07.000000000 -0700
-+++ tpm_emulator/tpm/tpm_emulator.h    2006-07-24 14:35:35.000000000 -07=
00
-@@ -1,5 +1,6 @@
- /* Software-Based Trusted Platform Module (TPM) Emulator for Linux
-  * Copyright (C) 2004 Mario Strasser <mast@gmx.net>,
-+ * Copyright (C) 2005 INTEL Corp
-  *
-  * This module is free software; you can redistribute it and/or modify
-  * it under the terms of the GNU General Public License as published
-@@ -22,7 +23,8 @@
- /* TPM configuration */
- #define TPM_STORE_TO_FILE       1
- #undef  TPM_STRONG_PERSISTENCE
--#undef  TPM_GENERATE_EK
-+//#undef  TPM_GENERATE_EK
-+#define  TPM_GENERATE_EK
- #undef  TPM_GENERATE_SEED_DAA
-
- #define TPM_MANUFACTURER 0x4554485A /* 'ETHZ' */      =20
-diff -uprN orig/tpm_emulator-0.4/tpm/tpm_marshalling.c
tpm_emulator/tpm/tpm_marshalling.c
---- orig/tpm_emulator-0.4/tpm/tpm_marshalling.c    2006-06-23
03:37:07.000000000 -0700
-+++ tpm_emulator/tpm/tpm_marshalling.c    2006-07-24 14:35:35.000000000
-0700
-@@ -1312,7 +1312,7 @@ int tpm_unmarshal_TPM_STANY_FLAGS(BYTE *
-
- int tpm_marshal_RSA(BYTE **ptr, UINT32 *length, rsa_private_key_t *v)
- {
--  UINT32 m_len, e_len, q_len;
-+  size_t m_len, e_len, q_len;
-   if (*length < sizeof_RSA((*v))) return -1;
-   if (v->size > 0) {
-     rsa_export_modulus(v, &(*ptr)[6], &m_len);
-@@ -1460,6 +1460,66 @@ int tpm_unmarshal_TPM_PERMANENT_DATA(BYT
-   return 0;
- }
-
-+int tpm_marshal_TPM_STCLEAR_DATA(BYTE **ptr, UINT32 *length,
TPM_STCLEAR_DATA *v)
-+{
-+  if (tpm_marshal_TPM_STRUCTURE_TAG(ptr, length, v->tag)
-+    || tpm_marshal_TPM_NONCE(ptr, length, &v->contextNonceKey)
-+    || tpm_marshal_TPM_COUNT_ID(ptr, length, v->countID) ) return -1;
-+
-+  return 0;
-+}
-+
-+int tpm_unmarshal_TPM_STCLEAR_DATA(BYTE **ptr, UINT32 *length,
TPM_STCLEAR_DATA *v)
-+{
-+  if (tpm_unmarshal_TPM_STRUCTURE_TAG(ptr, length, &v->tag)
-+    || tpm_unmarshal_TPM_NONCE(ptr, length, &v->contextNonceKey)
-+    || tpm_unmarshal_TPM_COUNT_ID(ptr, length, &v->countID) ) return -1=
;
-+
-+  return 0;
-+}
-+
-+int tpm_marshal_TPM_STANY_DATA(BYTE **ptr, UINT32 *length,
TPM_STANY_DATA *v)
-+{
-+  UINT32 i;
-+  if (tpm_marshal_TPM_STRUCTURE_TAG(ptr, length, v->tag)
-+    || tpm_marshal_TPM_NONCE(ptr, length, &v->contextNonceSession)
-+    || tpm_marshal_TPM_DIGEST(ptr, length, &v->auditDigest)
-+    || tpm_marshal_BOOL(ptr, length, v->auditSession)
-+    || tpm_marshal_TPM_CURRENT_TICKS(ptr, length, &v->currentTicks)
-+    || tpm_marshal_UINT32(ptr, length, v->contextCount)
-+    || tpm_marshal_UINT32_ARRAY(ptr, length, v->contextList,
TPM_MAX_SESSION_LIST)) return -1;
-+  for (i =3D 0; i < TPM_MAX_SESSIONS; i++) {
-+    if (tpm_marshal_TPM_SESSION_DATA(ptr, length, &v->sessions[i]))
return -1;
-+  }
-+  for (i =3D 0; i < TPM_MAX_SESSIONS_DAA; i++) {
-+    if (tpm_marshal_TPM_DAA_SESSION_DATA(ptr, length,
&v->sessionsDAA[i])) return -1;
-+  }
-+  if (tpm_marshal_TPM_TRANSHANDLE(ptr, length, v->transExclusive))
return -1;
-+
-+  return 0;
-+}
-+
-+int tpm_unmarshal_TPM_STANY_DATA(BYTE **ptr, UINT32 *length,
TPM_STANY_DATA *v)
-+{
-+  UINT32 i;
-+  if (tpm_unmarshal_TPM_STRUCTURE_TAG(ptr, length, &v->tag)
-+    || tpm_unmarshal_TPM_NONCE(ptr, length, &v->contextNonceSession)
-+    || tpm_unmarshal_TPM_DIGEST(ptr, length, &v->auditDigest)
-+    || tpm_unmarshal_BOOL(ptr, length, &v->auditSession)
-+    || tpm_unmarshal_TPM_CURRENT_TICKS(ptr, length, &v->currentTicks)
-+    || tpm_unmarshal_UINT32(ptr, length, &v->contextCount)
-+    || tpm_unmarshal_UINT32_ARRAY(ptr, length, v->contextList,
TPM_MAX_SESSION_LIST)) return -1;
-+  for (i =3D 0; i < TPM_MAX_SESSIONS; i++) {
-+    if (tpm_unmarshal_TPM_SESSION_DATA(ptr, length, &v->sessions[i]))
return -1;
-+  }
-+  for (i =3D 0; i < TPM_MAX_SESSIONS_DAA; i++) {
-+    if (tpm_unmarshal_TPM_DAA_SESSION_DATA(ptr, length,
&v->sessionsDAA[i])) return -1;
-+  }
-+  if (tpm_unmarshal_TPM_TRANSHANDLE(ptr, length, &v->transExclusive))
return -1;
-+
-+  return 0;
-+}
-+
- int tpm_marshal_TPM_SESSION_DATA(BYTE **ptr, UINT32 *length,
TPM_SESSION_DATA *v)
- {
-   if (tpm_marshal_BYTE(ptr, length, v->type)
-diff -uprN orig/tpm_emulator-0.4/tpm/tpm_marshalling.h
tpm_emulator/tpm/tpm_marshalling.h
---- orig/tpm_emulator-0.4/tpm/tpm_marshalling.h    2006-06-23
03:37:07.000000000 -0700
-+++ tpm_emulator/tpm/tpm_marshalling.h    2006-07-24 14:35:35.000000000
-0700
-@@ -432,6 +432,12 @@ int tpm_unmarshal_TPM_KEY_DATA(BYTE **pt
- int tpm_marshal_TPM_PERMANENT_DATA(BYTE **ptr, UINT32 *length,
TPM_PERMANENT_DATA *);
- int tpm_unmarshal_TPM_PERMANENT_DATA(BYTE **ptr, UINT32 *length,
TPM_PERMANENT_DATA *);
-
-+int tpm_marshal_TPM_STCLEAR_DATA(BYTE **ptr, UINT32 *length,
TPM_STCLEAR_DATA *v);
-+int tpm_unmarshal_TPM_STCLEAR_DATA(BYTE **ptr, UINT32 *length,
TPM_STCLEAR_DATA *v);
-+
-+int tpm_marshal_TPM_STANY_DATA(BYTE **ptr, UINT32 *length,
TPM_STANY_DATA *v);
-+int tpm_unmarshal_TPM_STANY_DATA(BYTE **ptr, UINT32 *length,
TPM_STANY_DATA *v);
-+
- int tpm_marshal_TPM_SESSION_DATA(BYTE **ptr, UINT32 *length,
TPM_SESSION_DATA *v);
- int tpm_unmarshal_TPM_SESSION_DATA(BYTE **ptr, UINT32 *length,
TPM_SESSION_DATA *v);
-
-diff -uprN orig/tpm_emulator-0.4/tpm/tpm_owner.c
tpm_emulator/tpm/tpm_owner.c
---- orig/tpm_emulator-0.4/tpm/tpm_owner.c    2006-06-23
03:37:07.000000000 -0700
-+++ tpm_emulator/tpm/tpm_owner.c    2006-07-24 14:35:35.000000000 -0700
-@@ -108,7 +108,7 @@ TPM_RESULT TPM_TakeOwnership(TPM_PROTOCO
-   TPM_RESULT res;
-   rsa_private_key_t *ek =3D &tpmData.permanent.data.endorsementKey;
-   TPM_KEY_DATA *srk =3D &tpmData.permanent.data.srk;
--  UINT32 buf_size =3D ek->size >> 3;
-+  size_t buf_size =3D ek->size >> 3, key_length;
-   BYTE buf[buf_size];
-
-   info("TPM_TakeOwnership()");
-@@ -173,7 +173,8 @@ TPM_RESULT TPM_TakeOwnership(TPM_PROTOCO
-     return TPM_FAIL;
-   }
-   rsa_export_modulus(&srk->key, srkPub->pubKey.key,
--    &srkPub->pubKey.keyLength);
-+             &key_length);
-+  srkPub->pubKey.keyLength =3D (UINT32) key_length;
-   /* setup tpmProof and set state to owned */
-   tpm_get_random_bytes(tpmData.permanent.data.tpmProof.nonce,
-     sizeof(tpmData.permanent.data.tpmProof.nonce));
-diff -uprN orig/tpm_emulator-0.4/tpm/tpm_startup.c
tpm_emulator/tpm/tpm_startup.c
---- orig/tpm_emulator-0.4/tpm/tpm_startup.c    2006-06-23
03:37:07.000000000 -0700
-+++ tpm_emulator/tpm/tpm_startup.c    2006-07-24 14:35:35.000000000 -070=
0
-@@ -41,26 +41,29 @@ void TPM_Init(TPM_STARTUP_TYPE startupTy
- TPM_RESULT TPM_Startup(TPM_STARTUP_TYPE startupType)
- {
-   int i;
-+  int restore_fail;
-   info("TPM_Startup(%d)", startupType);
-   if (tpmData.stany.flags.postInitialise =3D=3D FALSE) return
TPM_INVALID_POSTINIT;
--  /* reset STANY_FLAGS */
--  SET_TO_ZERO(&tpmData.stany.flags);
--  tpmData.stany.flags.tag =3D TPM_TAG_STANY_FLAGS;
--  /* reset STANY_DATA (invalidates ALL sessions) */
--  SET_TO_ZERO(&tpmData.stany.data);
--  tpmData.stany.data.tag =3D TPM_TAG_STANY_DATA;
--  /* init session-context nonce */
--  SET_TO_RAND(&tpmData.stany.data.contextNonceSession);
-+
-+  /* try and restore state to get EK, SRK, etc */
-+  restore_fail =3D tpm_restore_permanent_data();
-+
-   /* set data and flags according to the given startup type */
-   if (startupType =3D=3D TPM_ST_CLEAR) {
--    /* if available, restore permanent data */
--    tpm_restore_permanent_data();
-+    /* reset STANY_FLAGS */
-+    SET_TO_ZERO(&tpmData.stany.flags);
-+    tpmData.stany.flags.tag =3D TPM_TAG_STANY_FLAGS;
-+    /* reset STANY_DATA (invalidates ALL sessions) */
-+    SET_TO_ZERO(&tpmData.stany.data);
-+    tpmData.stany.data.tag =3D TPM_TAG_STANY_DATA;
-+    /* init session-context nonce */
-+    SET_TO_RAND(&tpmData.stany.data.contextNonceSession);
-     /* reset PCR values */
-     for (i =3D 0; i < TPM_NUM_PCR; i++) {
--      if (tpmData.permanent.data.pcrAttrib[i].pcrReset)
--        SET_TO_ZERO(tpmData.permanent.data.pcrValue[i].digest);
-+      if (!tpmData.permanent.data.pcrAttrib[i].pcrReset)
-+        SET_TO_ZERO(&tpmData.permanent.data.pcrValue[i].digest);
-       else
--        SET_TO_0xFF(tpmData.permanent.data.pcrValue[i].digest);
-+        SET_TO_0xFF(&tpmData.permanent.data.pcrValue[i].digest);
-     }
-     /* reset STCLEAR_FLAGS */
-     SET_TO_ZERO(&tpmData.stclear.flags);
-@@ -79,7 +82,8 @@ TPM_RESULT TPM_Startup(TPM_STARTUP_TYPE
-     /* init key-context nonce */
-     SET_TO_RAND(&tpmData.stclear.data.contextNonceKey);
-   } else if (startupType =3D=3D TPM_ST_STATE) {
--    if (tpm_restore_permanent_data()) {
-+    /* restore must have been successful for TPM_ST_STATE */
-+    if (restore_fail) {
-       error("restoring permanent data failed");
-       tpmData.permanent.data.testResult =3D
"tpm_restore_permanent_data() failed";
-       tpmData.permanent.flags.selfTestSucceeded =3D FALSE;
-diff -uprN orig/tpm_emulator-0.4/tpm/tpm_storage.c
tpm_emulator/tpm/tpm_storage.c
---- orig/tpm_emulator-0.4/tpm/tpm_storage.c    2006-06-23
03:37:07.000000000 -0700
-+++ tpm_emulator/tpm/tpm_storage.c    2006-07-24 14:35:35.000000000 -070=
0
-@@ -58,6 +58,7 @@ int encrypt_sealed_data(TPM_KEY_DATA *ke
-                         BYTE *enc, UINT32 *enc_size)
- {
-   UINT32 len;
-+  size_t enc_size32 =3D *enc_size;
-   BYTE *buf, *ptr;
-   rsa_public_key_t pub_key;
-   int scheme;
-@@ -72,7 +73,7 @@ int encrypt_sealed_data(TPM_KEY_DATA *ke
-   if (buf =3D=3D NULL
-       || tpm_marshal_TPM_SEALED_DATA(&ptr, &len, seal)
-       || rsa_encrypt(&pub_key, scheme, buf,
sizeof_TPM_SEALED_DATA((*seal)),
--                     enc, enc_size)) {
-+                     enc, &enc_size32)) {
-     tpm_free(buf);
-     rsa_release_public_key(&pub_key);
-     return -1;
-@@ -85,7 +86,8 @@ int encrypt_sealed_data(TPM_KEY_DATA *ke
- int decrypt_sealed_data(TPM_KEY_DATA *key, BYTE *enc, UINT32 enc_size,
-                         TPM_SEALED_DATA *seal, BYTE **buf)
- {
--  UINT32 len;
-+  size_t len;
-+  UINT32 len32;
-   BYTE *ptr;
-   int scheme;
-   switch (key->encScheme) {
-@@ -96,8 +98,12 @@ int decrypt_sealed_data(TPM_KEY_DATA *ke
-   len =3D enc_size;
-   *buf =3D ptr =3D tpm_malloc(len);
-   if (*buf =3D=3D NULL
--      || rsa_decrypt(&key->key, scheme, enc, enc_size, *buf, &len)
--      || tpm_unmarshal_TPM_SEALED_DATA(&ptr, &len, seal)) {
-+      || rsa_decrypt(&key->key, scheme, enc, enc_size, *buf, &len) ){
-+    tpm_free(*buf);
-+    return -1;
-+  }
-+  len32 =3D len;
-+  if (tpm_unmarshal_TPM_SEALED_DATA(&ptr, &len32, seal)) {
-     tpm_free(*buf);
-     return -1;
-   }
-@@ -240,11 +246,12 @@ TPM_RESULT TPM_Unseal(TPM_KEY_HANDLE par
-
- TPM_RESULT TPM_UnBind(TPM_KEY_HANDLE keyHandle, UINT32 inDataSize,
-                       BYTE *inData, TPM_AUTH *auth1,
--                      UINT32 *outDataSize, BYTE **outData)
-+                      UINT32 *outDataSize32, BYTE **outData)
- {
-   TPM_RESULT res;
-   TPM_KEY_DATA *key;
-   int scheme;
-+  size_t outDataSize;
- =20
-   info("TPM_UnBind()");
-   /* get key */
-@@ -262,8 +269,8 @@ TPM_RESULT TPM_UnBind(TPM_KEY_HANDLE key
-   /* the size of the input data muss be greater than zero */
-   if (inDataSize =3D=3D 0) return TPM_BAD_PARAMETER;
-   /* decrypt data */
--  *outDataSize =3D inDataSize;
--  *outData =3D tpm_malloc(*outDataSize);
-+  outDataSize =3D inDataSize;
-+  *outData =3D tpm_malloc(outDataSize);
-   if (*outData =3D=3D NULL) return TPM_NOSPACE;
-   switch (key->encScheme) {
-     case TPM_ES_RSAESOAEP_SHA1_MGF1: scheme =3D RSA_ES_OAEP_SHA1; break=
;
-@@ -271,20 +278,21 @@ TPM_RESULT TPM_UnBind(TPM_KEY_HANDLE key
-     default: tpm_free(*outData); return TPM_DECRYPT_ERROR;
-   }
-   if (rsa_decrypt(&key->key, scheme, inData, inDataSize,
--      *outData, outDataSize)) {
-+      *outData, &outDataSize)) {
-     tpm_free(*outData);
-     return TPM_DECRYPT_ERROR;
-   }
-   /* verify data if it is of type TPM_BOUND_DATA */
-   if (key->encScheme =3D=3D TPM_ES_RSAESOAEP_SHA1_MGF1
-       || key->keyUsage !=3D TPM_KEY_LEGACY) {
--    if (*outDataSize < 5 || memcmp(*outData, "\x01\x01\00\x00\x02", 5)
!=3D 0) {
-+    if (outDataSize < 5 || memcmp(*outData, "\x01\x01\00\x00\x02", 5)
!=3D 0) {
-       tpm_free(*outData);
-       return TPM_DECRYPT_ERROR;
-     }
--    *outDataSize -=3D 5;
--    memmove(*outData, &(*outData)[5], *outDataSize);
-+    outDataSize -=3D 5;
-+    memmove(*outData, &(*outData)[5], outDataSize);
-   }
-+  *outDataSize32 =3D (UINT32) outDataSize;
-   return TPM_SUCCESS;
- }
-
-@@ -334,12 +342,13 @@ int compute_pubkey_digest(TPM_PUBKEY *ke
- }
-
- int encrypt_private_key(TPM_KEY_DATA *key, TPM_STORE_ASYMKEY *store,
--                        BYTE *enc, UINT32 *enc_size)
-+                        BYTE *enc, UINT32 *enc_size32)
- {
-   UINT32 len;
-   BYTE *buf, *ptr;
-   rsa_public_key_t pub_key;
-   int scheme;
-+  size_t enc_size;
-   switch (key->encScheme) {
-     case TPM_ES_RSAESOAEP_SHA1_MGF1: scheme =3D RSA_ES_OAEP_SHA1; break=
;
-     case TPM_ES_RSAESPKCSv15: scheme =3D RSA_ES_PKCSV15; break;
-@@ -351,11 +360,12 @@ int encrypt_private_key(TPM_KEY_DATA *ke
-   if (buf =3D=3D NULL
-       || tpm_marshal_TPM_STORE_ASYMKEY(&ptr, &len, store)
-       || rsa_encrypt(&pub_key, scheme, buf,
sizeof_TPM_STORE_ASYMKEY((*store)),
--                     enc, enc_size)) {
-+                     enc, &enc_size)) {
-     tpm_free(buf);
-     rsa_release_public_key(&pub_key);
-     return -1;
-   }
-+  *enc_size32 =3D (UINT32) enc_size;
-   tpm_free(buf);
-   rsa_release_public_key(&pub_key);
-   return 0;
-@@ -364,7 +374,8 @@ int encrypt_private_key(TPM_KEY_DATA *ke
- int decrypt_private_key(TPM_KEY_DATA *key, BYTE *enc, UINT32 enc_size,
-                         TPM_STORE_ASYMKEY *store, BYTE **buf)
- {
--  UINT32 len;
-+  UINT32 len32;
-+  size_t len;
-   BYTE *ptr;
-   int scheme;
-   switch (key->encScheme) {
-@@ -375,8 +386,12 @@ int decrypt_private_key(TPM_KEY_DATA *ke
-   len =3D enc_size;
-   *buf =3D ptr =3D tpm_malloc(len);
-   if (*buf =3D=3D NULL
--      || rsa_decrypt(&key->key, scheme, enc, enc_size, *buf, &len)
--      || tpm_unmarshal_TPM_STORE_ASYMKEY(&ptr, &len, store)) {
-+      || rsa_decrypt(&key->key, scheme, enc, enc_size, *buf, &len) ) {
-+    tpm_free(*buf);
-+    return -1;
-+  }
-+  len32 =3D (UINT32) len;
-+  if (tpm_unmarshal_TPM_STORE_ASYMKEY(&ptr, &len32, store)) {=20
-     tpm_free(*buf);
-     return -1;
-   }
-@@ -394,7 +409,7 @@ TPM_RESULT TPM_CreateWrapKey(TPM_KEY_HAN
-   TPM_SESSION_DATA *session;
-   TPM_STORE_ASYMKEY store;
-   rsa_private_key_t rsa;
--  UINT32 key_length;
-+  size_t key_length;
-
-   info("TPM_CreateWrapKey()");
-   /* get parent key */
-@@ -450,11 +465,11 @@ TPM_RESULT TPM_CreateWrapKey(TPM_KEY_HAN
-     }
-   }
-   /* generate key and store it */
--  key_length =3D keyInfo->algorithmParms.parms.rsa.keyLength;
--  if (rsa_generate_key(&rsa, key_length)) return TPM_FAIL;
--  wrappedKey->pubKey.keyLength =3D key_length >> 3;
-+  if (rsa_generate_key(&rsa,
keyInfo->algorithmParms.parms.rsa.keyLength))
-+    return TPM_FAIL;
-+  wrappedKey->pubKey.keyLength =3D
keyInfo->algorithmParms.parms.rsa.keyLength >> 3;
-   wrappedKey->pubKey.key =3D tpm_malloc(wrappedKey->pubKey.keyLength);
--  store.privKey.keyLength =3D key_length >> 4;
-+  store.privKey.keyLength =3D
keyInfo->algorithmParms.parms.rsa.keyLength >> 4;
-   store.privKey.key =3D tpm_malloc(store.privKey.keyLength);
-   wrappedKey->encDataSize =3D parent->key.size >> 3;
-   wrappedKey->encData =3D tpm_malloc(wrappedKey->encDataSize);
-@@ -466,9 +481,11 @@ TPM_RESULT TPM_CreateWrapKey(TPM_KEY_HAN
-     tpm_free(wrappedKey->encData);
-     return TPM_NOSPACE;
-   }
--  rsa_export_modulus(&rsa, wrappedKey->pubKey.key,
--    &wrappedKey->pubKey.keyLength);
--  rsa_export_prime1(&rsa, store.privKey.key, &store.privKey.keyLength);=

-+  rsa_export_modulus(&rsa, wrappedKey->pubKey.key,
-+             &key_length);
-+  wrappedKey->pubKey.keyLength =3D (UINT32) key_length;
-+  rsa_export_prime1(&rsa, store.privKey.key, &key_length);
-+  store.privKey.keyLength =3D (UINT32) key_length;
-   rsa_release_private_key(&rsa);
-   /* compute the digest of the wrapped key (without encData) */
-   if (compute_key_digest(wrappedKey, &store.pubDataDigest)) {
-@@ -602,6 +619,7 @@ TPM_RESULT TPM_LoadKey2(TPM_KEY_HANDLE p
-
- int tpm_setup_key_parms(TPM_KEY_DATA *key, TPM_KEY_PARMS *parms)
- {
-+  size_t key_length;
-   parms->algorithmID =3D TPM_ALG_RSA;
-   parms->encScheme =3D key->encScheme;
-   parms->sigScheme =3D key->sigScheme;
-@@ -611,7 +629,8 @@ int tpm_setup_key_parms(TPM_KEY_DATA *ke
-   parms->parms.rsa.exponent =3D tpm_malloc(parms->parms.rsa.exponentSiz=
e);
-   if (parms->parms.rsa.exponent =3D=3D NULL) return -1;
-   rsa_export_exponent(&key->key, parms->parms.rsa.exponent,
--    &parms->parms.rsa.exponentSize);
-+    &key_length);
-+  parms->parms.rsa.exponentSize =3D (UINT32) key_length;
-   parms->parmSize =3D 12 + parms->parms.rsa.exponentSize;
-   return 0;
- }
-@@ -622,6 +641,7 @@ TPM_RESULT TPM_GetPubKey(TPM_KEY_HANDLE
-   TPM_RESULT res;
-   TPM_KEY_DATA *key;
-   TPM_DIGEST digest;
-+  size_t key_length;
-   info("TPM_GetPubKey()");
-   /* get key */
-   if (keyHandle =3D=3D TPM_KH_SRK
-@@ -650,8 +670,8 @@ TPM_RESULT TPM_GetPubKey(TPM_KEY_HANDLE
-   pubKey->pubKey.keyLength =3D key->key.size >> 3;
-   pubKey->pubKey.key =3D tpm_malloc(pubKey->pubKey.keyLength);
-   if (pubKey->pubKey.key =3D=3D NULL) return TPM_NOSPACE;
--  rsa_export_modulus(&key->key, pubKey->pubKey.key,
--    &pubKey->pubKey.keyLength);
-+  rsa_export_modulus(&key->key, pubKey->pubKey.key, &key_length);
-+  pubKey->pubKey.keyLength =3D (UINT32) key_length;
-   if (tpm_setup_key_parms(key, &pubKey->algorithmParms) !=3D 0) {
-     error("TPM_GetPubKey(): tpm_setup_key_parms() failed.");
-     tpm_free(pubKey->pubKey.key);
-diff -uprN orig/tpm_emulator-0.4/tpm/tpm_structures.h
tpm_emulator/tpm/tpm_structures.h
---- orig/tpm_emulator-0.4/tpm/tpm_structures.h    2006-06-23
03:37:07.000000000 -0700
-+++ tpm_emulator/tpm/tpm_structures.h    2006-07-24 14:35:35.000000000
-0700
-@@ -1958,6 +1958,7 @@ typedef struct tdTPM_DAA_ISSUER {
-   TPM_DIGEST DAA_digest_gamma;
-   BYTE DAA_generic_q[26];
- } TPM_DAA_ISSUER;
-+#define sizeof_TPM_DAA_ISSUER(s) (2 + (20 * 6) + 26 )
-
- /*
-  * TPM_DAA_TPM ([TPM_Part2], Section 22.4)
-@@ -1973,6 +1974,7 @@ typedef struct tdTPM_DAA_TPM {
-   TPM_DIGEST DAA_rekey;
-   UINT32 DAA_count;
- } TPM_DAA_TPM;
-+#define sizeof_TPM_DAA_TPM(s) (2 + (4 * 20) + 4)
-
- /*
-  * TPM_DAA_CONTEXT ([TPM_Part2], Section 22.5)
-@@ -1987,6 +1989,7 @@ typedef struct tdTPM_DAA_CONTEXT {
-   BYTE DAA_scratch[256];
-   BYTE DAA_stage;
- } TPM_DAA_CONTEXT;
-+#define sizeof_TPM_DAA_CONTEXT(s) (2 + (3 * 20) + 256 + 1)
-
- /*
-  * TPM_DAA_JOINDATA ([TPM_Part2], Section 22.6)
-@@ -1998,6 +2001,7 @@ typedef struct tdTPM_DAA_JOINDATA {
-   BYTE DAA_join_u1[138];
-   TPM_DIGEST DAA_digest_n0;
- } TPM_DAA_JOINDATA;
-+#define sizeof_TPM_DAA_JOINDATA(s) (1 + 1 + 20)
-
- /*
-  * TPM_DAA_BLOB ([TPM_Part2], Section 22.8)
-@@ -2202,6 +2206,7 @@ typedef struct tdTPM_STCLEAR_DATA {
-   //UINT32 ownerReference;
-   //BOOL disableResetLock;
- } TPM_STCLEAR_DATA;
-+#define sizeof_TPM_STCLEAR_DATA(s) (2 + 20 + 4)
-
- /*
-  * TPM_SESSION_DATA
-@@ -2238,6 +2243,11 @@ typedef struct tdTPM_DAA_SESSION_DATA {
-   TPM_DAA_JOINDATA DAA_joinSession;
-   TPM_HANDLE handle;
- } TPM_DAA_SESSION_DATA;
-+#define sizeof_TPM_DAA_SESSION_DATA(s) ( 1 \
-+  + sizeof_TPM_DAA_ISSUER(s.DAA_issuerSettings) \
-+  + sizeof_TPM_DAA_TPM(s.DAA_tpmSpecific) \
-+  + sizeof_TPM_DAA_CONTEXT(s.DAA_session) \
-+  + sizeof_TPM_DAA_JOINDATA(s.DAA_joinSession) + 4)
-
- /*
-  * TPM_STANY_DATA ([TPM_Part2], Section 7.6)
-@@ -2262,6 +2272,11 @@ typedef struct tdTPM_STANY_DATA {
-   TPM_DAAHANDLE currentDAA;
-   TPM_TRANSHANDLE transExclusive;
- } TPM_STANY_DATA;
-+#define sizeof_TPM_STANY_DATA(s) (2 + 20 + 20 + 1 \
-+  + sizeof_TPM_CURRENT_TICKS(s.currentTicks) \
-+  + 4 + (4 * TPM_MAX_SESSION_LIST) \
-+  + (sizeof_TPM_SESSION_DATA(s.sessions[0]) * TPM_MAX_SESSION_LIST) \
-+  + (sizeof_TPM_DAA_SESSION_DATA(s.sessionsDAA[0]) *
TPM_MAX_SESSIONS_DAA) + 4)
-
- /*
-  * TPM_DATA
-diff -uprN orig/tpm_emulator-0.4/tpm/tpm_testing.c
tpm_emulator/tpm/tpm_testing.c
---- orig/tpm_emulator-0.4/tpm/tpm_testing.c    2006-06-23
03:37:07.000000000 -0700
-+++ tpm_emulator/tpm/tpm_testing.c    2006-07-24 14:35:35.000000000 -070=
0
-@@ -1,6 +1,7 @@
- /* Software-Based Trusted Platform Module (TPM) Emulator for Linux
-  * Copyright (C) 2004 Mario Strasser <mast@gmx.net>,
-  *                    Swiss Federal Institute of Technology (ETH) Zuric=
h
-+ * Copyright (C) 2005 INTEL Corp
-  *
-  * This module is free software; you can redistribute it and/or modify
-  * it under the terms of the GNU General Public License as published
-@@ -95,24 +96,24 @@ static int tpm_test_sha1(void)
-   struct {
-     uint8_t *data; uint32_t repetitions; uint8_t *digest;
-   } test_cases[] =3D  {{
--    "abc", 1,
--  =20
"\xA9\x99\x3E\x36\x47\x06\x81\x6A\xBA\x3E\x25\x71\x78\x50\xC2\x6C\x9C\xD0=
\xD8\x9D"
-+    (uint8_t*)"abc", 1,
-+  =20
(uint8_t*)"\xA9\x99\x3E\x36\x47\x06\x81\x6A\xBA\x3E\x25\x71\x78\x50\xC2\x=
6C\x9C\xD0\xD8\x9D"
-   }, {
--    "abcdbcdecdefdefgefghfghighijhijkijkljklmklmnlmnomnopnopq", 1,
--  =20
"\x84\x98\x3E\x44\x1C\x3B\xD2\x6E\xBA\xAE\x4A\xA1\xF9\x51\x29\xE5\xE5\x46=
\x70\xF1"
-+  =20
(uint8_t*)"abcdbcdecdefdefgefghfghighijhijkijkljklmklmnlmnomnopnopq", 1,
-+  =20
(uint8_t*)"\x84\x98\x3E\x44\x1C\x3B\xD2\x6E\xBA\xAE\x4A\xA1\xF9\x51\x29\x=
E5\xE5\x46\x70\xF1"
-   }, {
--    "a", 1000000,
--  =20
"\x34\xAA\x97\x3C\xD4\xC4\xDA\xA4\xF6\x1E\xEB\x2B\xDB\xAD\x27\x31\x65\x34=
\x01\x6F"
-+    (uint8_t*)"a", 1000000,
-+  =20
(uint8_t*)"\x34\xAA\x97\x3C\xD4\xC4\xDA\xA4\xF6\x1E\xEB\x2B\xDB\xAD\x27\x=
31\x65\x34\x01\x6F"
-   }, {
--  =20
"0123456701234567012345670123456701234567012345670123456701234567", 10,
--  =20
"\xDE\xA3\x56\xA2\xCD\xDD\x90\xC7\xA7\xEC\xED\xC5\xEB\xB5\x63\x93\x4F\x46=
\x04\x52"
-+  =20
(uint8_t*)"01234567012345670123456701234567012345670123456701234567012345=
67",
10,
-+  =20
(uint8_t*)"\xDE\xA3\x56\xA2\xCD\xDD\x90\xC7\xA7\xEC\xED\xC5\xEB\xB5\x63\x=
93\x4F\x46\x04\x52"
-   }};
-
-   debug("tpm_test_sha1()");
-   for (i =3D 0; i < sizeof(test_cases) / sizeof(test_cases[0]); i++) {
-     sha1_init(&ctx);
-     for (j =3D 0; j < test_cases[i].repetitions; j++)
--      sha1_update(&ctx, test_cases[i].data, strlen(test_cases[i].data))=
;
-+      sha1_update(&ctx, test_cases[i].data,
strlen((char*)test_cases[i].data));
-     sha1_final(&ctx, digest);
-     if (memcmp(digest, test_cases[i].digest, SHA1_DIGEST_LENGTH) !=3D 0=
)
return -1;
-   }
-@@ -128,41 +129,41 @@ static int tpm_test_hmac(void)
-   struct {
-     uint8_t *key, key_len, *data, data_len, *digest;
-   } test_cases[] =3D {{
--    "\x0b", 20, "Hi There", 8,
--  =20
"\xb6\x17\x31\x86\x55\x05\x72\x64\xe2\x8b\xc0\xb6\xfb\x37\x8c\x8e\xf1\x46=
\xbe\x00"
-+    (uint8_t*)"\x0b", 20, (uint8_t*)"Hi There", 8,
-+  =20
(uint8_t*)"\xb6\x17\x31\x86\x55\x05\x72\x64\xe2\x8b\xc0\xb6\xfb\x37\x8c\x=
8e\xf1\x46\xbe\x00"
-   }, {
--    "Jefe", 4, "what do ya want for nothing?", 28,
--  =20
"\xef\xfc\xdf\x6a\xe5\xeb\x2f\xa2\xd2\x74\x16\xd5\xf1\x84\xdf\x9c\x25\x9a=
\x7c\x79"
-+    (uint8_t*)"Jefe", 4, (uint8_t*)"what do ya want for nothing?", 28,
-+  =20
(uint8_t*)"\xef\xfc\xdf\x6a\xe5\xeb\x2f\xa2\xd2\x74\x16\xd5\xf1\x84\xdf\x=
9c\x25\x9a\x7c\x79"
-   }, {
--    "\xaa", 20, "\xdd", 50,
--  =20
"\x12\x5d\x73\x42\xb9\xac\x11\xcd\x91\xa3\x9a\xf4\x8a\xa1\x7b\x4f\x63\xf1=
\x75\xd3"
-+    (uint8_t*)"\xaa", 20, (uint8_t*)"\xdd", 50,
-+  =20
(uint8_t*)"\x12\x5d\x73\x42\xb9\xac\x11\xcd\x91\xa3\x9a\xf4\x8a\xa1\x7b\x=
4f\x63\xf1\x75\xd3"
-   }, {
--  =20
"\x01\x02\x03\x04\x05\x06\x07\x08\x09\x0a\x0b\x0c\x0d\x0e\x0f\x10\x11\x12=
\x13\x14"
--    "\x15\x16\x17\x18\x19", 25, "\xcd", 50,
--  =20
"\x4c\x90\x07\xf4\x02\x62\x50\xc6\xbc\x84\x14\xf9\xbf\x50\xc8\x6c\x2d\x72=
\x35\xda"
-+  =20
(uint8_t*)"\x01\x02\x03\x04\x05\x06\x07\x08\x09\x0a\x0b\x0c\x0d\x0e\x0f\x=
10\x11\x12\x13\x14"
-+    "\x15\x16\x17\x18\x19", 25, (uint8_t*)"\xcd", 50,
-+  =20
(uint8_t*)"\x4c\x90\x07\xf4\x02\x62\x50\xc6\xbc\x84\x14\xf9\xbf\x50\xc8\x=
6c\x2d\x72\x35\xda"
-   }, {
--    "\x0c", 20, "Test With Truncation", 20,
--  =20
"\x4c\x1a\x03\x42\x4b\x55\xe0\x7f\xe7\xf2\x7b\xe1\xd5\x8b\xb9\x32\x4a\x9a=
\x5a\x04"
-+    (uint8_t*)"\x0c", 20, (uint8_t*)"Test With Truncation", 20,
-+  =20
(uint8_t*)"\x4c\x1a\x03\x42\x4b\x55\xe0\x7f\xe7\xf2\x7b\xe1\xd5\x8b\xb9\x=
32\x4a\x9a\x5a\x04"
-   }, {
--    "\xaa", 80, "Test Using Larger Than Block-Size Key - Hash Key
First", 54,
--  =20
"\xaa\x4a\xe5\xe1\x52\x72\xd0\x0e\x95\x70\x56\x37\xce\x8a\x3b\x55\xed\x40=
\x21\x12"
-+    (uint8_t*)"\xaa", 80, (uint8_t*)"Test Using Larger Than Block-Size
Key - Hash Key First", 54,
-+  =20
(uint8_t*)"\xaa\x4a\xe5\xe1\x52\x72\xd0\x0e\x95\x70\x56\x37\xce\x8a\x3b\x=
55\xed\x40\x21\x12"
-   }, {
--    "\xaa", 80,
--    "Test Using Larger Than Block-Size Key and Larger Than One
Block-Size Data", 73,
--  =20
"\xe8\xe9\x9d\x0f\x45\x23\x7d\x78\x6d\x6b\xba\xa7\x96\x5c\x78\x08\xbb\xff=
\x1a\x91"
-+    (uint8_t*)"\xaa", 80,
-+    (uint8_t*)"Test Using Larger Than Block-Size Key and Larger Than
One Block-Size Data", 73,
-+  =20
(uint8_t*)"\xe8\xe9\x9d\x0f\x45\x23\x7d\x78\x6d\x6b\xba\xa7\x96\x5c\x78\x=
08\xbb\xff\x1a\x91"
-   }};
-
-   debug("tpm_test_hmac()");
-   for (i =3D 0; i < sizeof(test_cases) / sizeof(test_cases[0]); i++) {
--    if (strlen(test_cases[i].key) < test_cases[i].key_len) {
-+    if (strlen((char*)test_cases[i].key) < test_cases[i].key_len) {
-       uint8_t key[test_cases[i].key_len];
-       memset(key, test_cases[i].key[0], test_cases[i].key_len);
-       hmac_init(&ctx, key, test_cases[i].key_len);
-     } else {
-       hmac_init(&ctx, test_cases[i].key, test_cases[i].key_len);
-     }
--    for (j =3D 0; j < test_cases[i].data_len; j +=3D
strlen(test_cases[i].data)) {
--      hmac_update(&ctx, test_cases[i].data, strlen(test_cases[i].data))=
;
-+    for (j =3D 0; j < test_cases[i].data_len; j +=3D
strlen((char*)test_cases[i].data)) {
-+      hmac_update(&ctx, test_cases[i].data,
strlen((char*)test_cases[i].data));
-     }
-     hmac_final(&ctx, digest);
-     if (memcmp(digest, test_cases[i].digest, SHA1_DIGEST_LENGTH) !=3D 0=
)
return -1;
-@@ -173,9 +174,9 @@ static int tpm_test_hmac(void)
- static int tpm_test_rsa_EK(void)
- {
-   int res =3D 0;
--  char *data =3D "RSA PKCS #1 v1.5 Test-String";
-+  uint8_t *data =3D (uint8_t*)"RSA PKCS #1 v1.5 Test-String";
-   uint8_t buf[256];
--  size_t buf_len, data_len =3D strlen(data);
-+  size_t buf_len, data_len =3D strlen((char*)data);
-   rsa_private_key_t priv_key;
-   rsa_public_key_t pub_key;
-
-diff -uprN orig/tpm_emulator-0.4/tpm/tpm_ticks.c
tpm_emulator/tpm/tpm_ticks.c
---- orig/tpm_emulator-0.4/tpm/tpm_ticks.c    2006-06-23
03:37:07.000000000 -0700
-+++ tpm_emulator/tpm/tpm_ticks.c    2006-07-24 14:35:35.000000000 -0700
-@@ -1,6 +1,7 @@
- /* Software-Based Trusted Platform Module (TPM) Emulator for Linux
-  * Copyright (C) 2004 Mario Strasser <mast@gmx.net>,
-  *                    Swiss Federal Institute of Technology (ETH) Zuric=
h
-+ * Copyright (C) 2005 INTEL Corp
-  *
-  * This module is free software; you can redistribute it and/or modify
-  * it under the terms of the GNU General Public License as published
-@@ -39,9 +40,7 @@ TPM_RESULT TPM_SetTickType(TPM_TICKTYPE
- TPM_RESULT TPM_GetTicks(TPM_CURRENT_TICKS *currentTime)
- {
-   info("TPM_GetTicks()");
--  memcpy(currentTime, &tpmData.stany.data.currentTicks,
--    sizeof(TPM_CURRENT_TICKS));
--  return TPM_SUCCESS;
-+  return TPM_DISABLED_CMD;
- }
-
- TPM_RESULT TPM_TickStampBlob(TPM_KEY_HANDLE keyHandle, TPM_NONCE
*antiReplay,
-@@ -49,64 +48,11 @@ TPM_RESULT TPM_TickStampBlob(TPM_KEY_HAN
-                              TPM_CURRENT_TICKS *currentTicks,
-                              UINT32 *sigSize, BYTE **sig)
- {
--  TPM_RESULT res;
--  TPM_KEY_DATA *key;
--  BYTE *info, *p;
--  UINT32 info_length, length;
-   info("TPM_TickStampBlob()");
--  /* get key */
--  key =3D tpm_get_key(keyHandle);
--  if (key =3D=3D NULL) return TPM_INVALID_KEYHANDLE;
--  /* verify authorization */
--  res =3D tpm_verify_auth(auth1, key->usageAuth, keyHandle);
--  if (res !=3D TPM_SUCCESS) return res;
--  if (key->keyUsage !=3D TPM_KEY_SIGNING && key->keyUsage !=3D TPM_KEY_=
LEGACY
--      && key->keyUsage !=3D TPM_KEY_IDENTITY) return TPM_INVALID_KEYUSA=
GE;
--  /* get current ticks */
--  TPM_GetTicks(currentTicks);
--  /* sign data using signature scheme PKCS1_SHA1 and TPM_SIGN_INFO
container */
--  *sigSize =3D key->key.size >> 3;
--  *sig =3D tpm_malloc(*sigSize);
--  if (*sig =3D=3D NULL) return TPM_FAIL;
--  /* setup TPM_SIGN_INFO structure */
--  info_length =3D 30 + sizeof(TPM_DIGEST) +
sizeof_TPM_CURRENT_TICKS(currentTicks);
--  info =3D tpm_malloc(info_length);
--  if (info =3D=3D NULL) {
--    tpm_free(*sig);
--    return TPM_FAIL;
--  }
--  memcpy(&info[0], "\x05\x00TSTP", 6);
--  memcpy(&info[6], antiReplay->nonce, 20);
--  *(UINT32*)&info[26] =3D CPU_TO_BE32(20
--                        + sizeof_TPM_CURRENT_TICKS(currentTicks));
--  memcpy(&info[30], digestToStamp->digest, sizeof(TPM_DIGEST));
--  p =3D &info[30 + sizeof(TPM_DIGEST)];
--  length =3D sizeof_TPM_CURRENT_TICKS(currentTicks);
--  if (tpm_marshal_TPM_CURRENT_TICKS(&p, &length, currentTicks)
--      || rsa_sign(&key->key, RSA_SSA_PKCS1_SHA1, info, info_length,
*sig)) { =20
--    tpm_free(*sig);
--    tpm_free(info);
--    return TPM_FAIL;
--  }
--  return TPM_SUCCESS;
-+  return TPM_DISABLED_CMD;
- }
-
- void tpm_update_ticks(void)
- {
--  if (tpmData.stany.data.currentTicks.tag =3D=3D 0) {
--    tpmData.stany.data.currentTicks.tag =3D TPM_TAG_CURRENT_TICKS;
--    tpmData.stany.data.currentTicks.currentTicks +=3D tpm_get_ticks();
--/* removed since v1.2 rev 94
--    tpmData.stany.data.currentTicks.tickType =3D
tpmData.permanent.data.tickType;
--*/
--    tpm_get_random_bytes(tpmData.stany.data.currentTicks.tickNonce.nonc=
e,
--      sizeof(TPM_NONCE));
--    tpmData.stany.data.currentTicks.tickRate =3D 1;
--/* removed since v1.2 rev 94
--    tpmData.stany.data.currentTicks.tickSecurity =3D TICK_SEC_NO_CHECK;=

--*/
--  } else {
--    tpmData.stany.data.currentTicks.currentTicks +=3D tpm_get_ticks(); =
=20
--  }
- }
-
-diff -uprN orig/tpm_emulator-0.4/tpm/tpm_transport.c
tpm_emulator/tpm/tpm_transport.c
---- orig/tpm_emulator-0.4/tpm/tpm_transport.c    2006-06-23
03:37:07.000000000 -0700
-+++ tpm_emulator/tpm/tpm_transport.c    2006-07-24 14:35:35.000000000 -0=
700
-@@ -189,7 +189,7 @@ static void decrypt_wrapped_command(BYTE
-     sha1_init(&sha1);
-     sha1_update(&sha1, auth->nonceEven.nonce,
sizeof(auth->nonceEven.nonce));
-     sha1_update(&sha1, auth->nonceOdd.nonce,
sizeof(auth->nonceOdd.nonce));
--    sha1_update(&sha1, "in", 2);
-+    sha1_update(&sha1, (BYTE*)"in", 2);
-     sha1_update(&sha1, secret, sizeof(TPM_SECRET));
-     j =3D CPU_TO_BE32(i);
-     sha1_update(&sha1, (BYTE*)&j, 4);
-@@ -211,7 +211,7 @@ static void encrypt_wrapped_command(BYTE
-     sha1_init(&sha1);
-     sha1_update(&sha1, auth->nonceEven.nonce,
sizeof(auth->nonceEven.nonce));
-     sha1_update(&sha1, auth->nonceOdd.nonce,
sizeof(auth->nonceOdd.nonce));
--    sha1_update(&sha1, "out", 3);
-+    sha1_update(&sha1, (BYTE*)"out", 3);
-     sha1_update(&sha1, secret, sizeof(TPM_SECRET));
-     j =3D CPU_TO_BE32(i);
-     sha1_update(&sha1, (BYTE*)&j, 4);
-diff -uprN orig/tpm_emulator-0.4/tpmd.c tpm_emulator/tpmd.c
---- orig/tpm_emulator-0.4/tpmd.c    1969-12-31 16:00:00.000000000 -0800
-+++ tpm_emulator/tpmd.c    2006-07-24 14:35:35.000000000 -0700
-@@ -0,0 +1,156 @@
-+/* Software-Based Trusted Platform Module (TPM) Emulator for Linux
-+ * Copyright (C) 2005 INTEL Corp
-+ *
-+ * This module 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 module is distributed in the hope that it will be useful,
-+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
-+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
-+ * GNU General Public License for more details.
-+ *
-+ */
-+
-+#include <stdio.h>
-+#include <stdlib.h>
-+#include <unistd.h>
-+#include <string.h>
-+#include <sys/types.h>
-+#include <sys/stat.h>
-+#include <fcntl.h>
-+#include <sys/time.h>
-+
-+#include "tpm_emulator.h"
-+
-+#define TPM_RX_FNAME "/var/tpm/tpm_in.fifo"
-+#define TPM_TX_FNAME "/var/tpm/tpm_out.fifo"
-+
-+#define BUFFER_SIZE 2048
-+
-+static int devurandom=3D0;
-+    =20
-+void get_random_bytes(void *buf, int nbytes) {
-+=20
-+  if (devurandom =3D=3D 0) {
-+    devurandom =3D open("/dev/urandom", O_RDONLY);
-+  }
-+
-+  if (read(devurandom, buf, nbytes) !=3D nbytes) {
-+      printf("Can't get random number.\n");
-+      exit(-1);
-+  }
-+}
-+
-+uint64_t tpm_get_ticks(void)
-+{
-+  //struct timeval tv;
-+  //int gettimeofday(&tv, struct timezone *tz);
-+  return 0;
-+}
-+
-+int main(int argc, char **argv)
-+{
-+  uint8_t in[BUFFER_SIZE], *out;
-+  uint32_t out_size;
-+  int in_size, written;
-+  int i;
-+  struct stat file_info;
-+
-+  int tpm_tx_fh=3D-1, tpm_rx_fh=3D-1;
-+  if (argc < 2) {
-+    printf("Usage: tpmd clear|save|deactivated\n" );
-+      return -1;
-+  }
-+
-+  /* initialize TPM emulator */
-+  if (!strcmp(argv[1], "clear")) {
-+    printf("Initializing tpm: %s\n", argv[1]);
-+    tpm_emulator_init(1);
-+  } else if (!strcmp(argv[1], "save")) {
-+    printf("Initializing tpm: %s\n", argv[1]);
-+    tpm_emulator_init(2);
-+  } else if (!strcmp(argv[1], "deactivated")) {
-+    printf("Initializing tpm: %s\n", argv[1]);
-+    tpm_emulator_init(3);
-+  } else {
-+    printf("invalid startup mode '%s'; must be 'clear', "
-+      "'save' (default) or 'deactivated", argv[1]);
-+    return -1;
-+  }
-+
-+  if ( stat(TPM_RX_FNAME, &file_info) =3D=3D -1) {
-+    if ( mkfifo(TPM_RX_FNAME, S_IWUSR | S_IRUSR ) ) {
-+      printf("Failed to create fifo %s.\n", TPM_RX_FNAME);
-+      return -1;
-+    }
-+  }
-+
-+  if ( stat(TPM_TX_FNAME, &file_info) =3D=3D -1) {
-+    if ( mkfifo(TPM_TX_FNAME, S_IWUSR | S_IRUSR ) ) {
-+      printf("Failed to create fifo %s.\n", TPM_TX_FNAME);
-+      return -1;
-+    }
-+  }
-+
-+  while (1) {
-+abort_command:
-+    if (tpm_rx_fh < 0) {
-+      tpm_rx_fh =3D open(TPM_RX_FNAME, O_RDONLY);
-+    }
-+  =20
-+    if (tpm_rx_fh < 0) {
-+      printf("ERROR: failed to open devices to listen to guest.\n");
-+      return -1;
-+    }
-+  =20
-+    if (tpm_tx_fh < 0) {
-+      tpm_tx_fh =3D open(TPM_TX_FNAME, O_WRONLY);
-+    }
-+
-+    if (tpm_tx_fh < 0) {
-+      printf("ERROR: failed to open devices to respond to guest.\n");
-+      return -1;
-+    }
-+
-+    in_size =3D read(tpm_rx_fh, in, BUFFER_SIZE);
-+    if (in_size < 6) { // Magic size of minium TPM command
-+      printf("Recv[%d] to small: 0x", in_size);
-+      if (in_size <=3D 0) {
-+          close(tpm_rx_fh);
-+          tpm_rx_fh =3D -1;
-+          goto abort_command;
-+      }
-+    } else {
-+      printf("Recv[%d]: 0x", in_size);
-+      for (i=3D0; i< in_size; i++)
-+        printf("%x ", in[i]);
-+      printf("\n");
-+    }
-+
-+  =20
-+    if (tpm_handle_command(in, in_size, &out, &out_size) !=3D 0) {
-+        printf("ERROR: Handler Failed.\n");
-+    }
-+
-+    written =3D write(tpm_tx_fh, out, out_size);
-+
-+    if (written !=3D out_size ) {
-+      printf("ERROR: Part of response not written %d/%d.\nAttempt: ",
written, out_size);
-+    } else {
-+      printf("Sent[%Zu]: ", out_size);
-+    }
-+    for (i=3D0; i< out_size; i++)
-+      printf("%x ", out[i]);
-+    printf("\n");
-+    tpm_free(out);
-+
-+  } // loop
-+
-+  tpm_emulator_shutdown();
-+
-+  close(tpm_tx_fh);
-+  close(tpm_rx_fh);
-+
-+}
-Binary files orig/tpm_emulator-0.4/tpm_emulator and
tpm_emulator/tpm_emulator differ
-diff -uprN orig/tpm_emulator-0.4/tpm_version.h tpm_emulator/tpm_version.=
h
---- orig/tpm_emulator-0.4/tpm_version.h    2006-06-23
03:37:07.000000000 -0700
-+++ tpm_emulator/tpm_version.h    2006-07-24 14:35:41.000000000 -0700
-@@ -2,5 +2,5 @@
- #define _TPM_VERSION_H_
- #define VERSION_MAJOR 0
- #define VERSION_MINOR 4
--#define VERSION_BUILD 1151058734
-+#define VERSION_BUILD 1153776940
- #endif /* _TPM_VERSION_H_ */
diff --git a/tools/vtpm/vtpm-0.5.1-LDLIBS.patch
b/tools/vtpm/vtpm-0.5.1-LDLIBS.patch
--- a/tools/vtpm/vtpm-0.5.1-LDLIBS.patch
+++ /dev/null
@@ -1,12 +0,0 @@
-diff -Naurp tpm_emulator-0.5.1/tpmd/Makefile
tpm_emulator-0.5.1/tpmd/Makefile
---- tpm_emulator-0.5.1/tpmd/Makefile
-+++ tpm_emulator-0.5.1/tpmd/Makefile
-@@ -8,7 +8,7 @@ WFLAGS  :=3D -Wall -Wno-unused -Wpointer-a
-            #WFLAGS  +=3D -Wextra -Wcast-qual -Wmissing-prototypes
-Wmissing-declarations -Wstrict-aliasing
- CFLAGS  +=3D $(WFLAGS) -g -I.. -I. -O2 -fno-strict-aliasing
- CFLAGS  +=3D -I../../../../tools/vtpm_manager/manager
--LDFLAGS +=3D -lgmp
-+LDLIBS  +=3D -lgmp
-
- BINDIR  :=3D /usr/bin/
-
diff --git a/tools/vtpm/vtpm-0.5.1.patch b/tools/vtpm/vtpm-0.5.1.patch
--- a/tools/vtpm/vtpm-0.5.1.patch
+++ /dev/null
@@ -1,766 +0,0 @@
-diff -Naurp tpm_emulator-0.5.1/Makefile tpm5-test/Makefile
---- tpm_emulator-0.5.1/Makefile    2008-02-14 03:22:48.000000000 -0500
-+++ tpm5-test/Makefile    2009-07-15 09:45:28.000000000 -0400
-@@ -10,7 +10,7 @@ VERSION_MINOR  :=3D 5
- VERSION_BUILD  :=3D $(shell date +"%s")
- VERSION_SUFFIX :=3D .1
-
--SUBDIRS :=3D tpmd tpmd_dev tddl
-+SUBDIRS :=3D tpmd
-
- all: version all-recursive
-
-@@ -48,12 +48,12 @@ user_install: user
- modules_install: modules
-     @$(MAKE) -C tpmd_dev install || exit -1
-
--DIRS    :=3D . tpm crypto tpmd tpmd_dev tddl tpmd_dev_openbsd
-+DIRS    :=3D . tpm crypto tpmd
- DISTSRC :=3D $(foreach dir, $(DIRS), $(wildcard $(dir)/*.c))
- DISTSRC +=3D $(foreach dir, $(DIRS), $(wildcard $(dir)/*.h))
--DIRS    :=3D . tpmd tpmd_dev tddl tpmd_dev_openbsd
-+DIRS    :=3D . tpmd
- DISTSRC +=3D $(foreach dir, $(DIRS), $(dir)/Makefile)
--DISTSRC +=3D ./README ./AUTHORS ./ChangeLog tpmd_dev/tpmd_dev.rules.in
-+DISTSRC +=3D ./README ./AUTHORS ./ChangeLog
- DISTDIR :=3D tpm_emulator-$(VERSION_MAJOR).$(VERSION_MINOR)$(VERSION_SU=
FFIX)
-
- dist: $(DISTSRC)
-diff -Naurp tpm_emulator-0.5.1/tpm/tpm_capability.c
tpm5-test/tpm/tpm_capability.c
---- tpm_emulator-0.5.1/tpm/tpm_capability.c    2008-02-14
03:22:48.000000000 -0500
-+++ tpm5-test/tpm/tpm_capability.c    2009-07-16 12:04:20.000000000 -040=
0
-@@ -136,8 +136,19 @@ static TPM_RESULT cap_property(UINT32 su
-
-     case TPM_CAP_PROP_TIS_TIMEOUT:
-       debug("[TPM_CAP_PROP_TIS_TIMEOUT]");
--      /* TODO: TPM_CAP_PROP_TIS_TIMEOUT */
--      return TPM_FAIL;
-+      /* TODO: TPM_CAP_PROP_TIS_TIMEOUT: Measure these values and
determine correct ones */
-+      UINT32 len =3D *respSize =3D 16;
-+      BYTE *ptr =3D *resp =3D tpm_malloc(*respSize);
-+      if (ptr =3D=3D NULL ||
-+          tpm_marshal_UINT32(&ptr, &len, 200000) ||
-+          tpm_marshal_UINT32(&ptr, &len, 200000) ||
-+          tpm_marshal_UINT32(&ptr, &len, 200000) ||
-+          tpm_marshal_UINT32(&ptr, &len, 200000)) {
-+        tpm_free(*resp);
-+        return TPM_FAIL;
-+      }
-+      return TPM_SUCCESS;
-+
-
-     case TPM_CAP_PROP_STARTUP_EFFECT:
-       debug("[TPM_CAP_PROP_STARTUP_EFFECT]");
-@@ -189,8 +200,12 @@ static TPM_RESULT cap_property(UINT32 su
-
-     case TPM_CAP_PROP_DURATION:
-       debug("[TPM_CAP_PROP_DURATION]");
--      /* TODO: TPM_CAP_PROP_DURATION */
--      return TPM_FAIL;
-+      /* TODO: TPM_CAP_PROP_DURATION: Measure these values and return
accurate ones */
-+      BYTE dur[]=3D
{0x0,0x0,0x0,0xc,0x0,0x7,0xa1,0x20,0x0,0x1e,0x84,0x80,0x11,0xe1,0xa3,0x0}=
;
-+      *respSize =3D 16;
-+      *resp =3D tpm_malloc(*respSize);
-+      memcpy(*resp,dur,16);
-+
-
-     case TPM_CAP_PROP_ACTIVE_COUNTER:
-       debug("[TPM_CAP_PROP_ACTIVE_COUNTER]");
-diff -Naurp tpm_emulator-0.5.1/tpmd/Makefile tpm5-test/tpmd/Makefile
---- tpm_emulator-0.5.1/tpmd/Makefile    2008-02-14 03:22:48.000000000 -0=
500
-+++ tpm5-test/tpmd/Makefile    2009-07-16 12:08:26.000000000 -0400
-@@ -8,9 +8,10 @@ WFLAGS  :=3D -Wall -Wno-unused -Wpointer-a
-            -Wwrite-strings -Wsign-compare -Wno-multichar
-            #WFLAGS  +=3D -Wextra -Wcast-qual -Wmissing-prototypes
-Wmissing-declarations -Wstrict-aliasing
- CFLAGS  +=3D $(WFLAGS) -g -I.. -I. -O2 -fno-strict-aliasing
-+CFLAGS  +=3D -I../../../../tools/vtpm_manager/manager
- LDFLAGS +=3D -lgmp
-
--BINDIR  :=3D /usr/sbin/
-+BINDIR  :=3D /usr/bin/
-
- TPMD    :=3D tpmd
- DIRS    :=3D ../tpm ../crypto
-@@ -18,6 +19,8 @@ SRCS    :=3D $(foreach dir, $(DIRS), $(wil
- OBJS    :=3D $(patsubst %.c, %.o, $(SRCS))
- OBJS    :=3D $(foreach dir, $(DIRS), $(patsubst $(dir)/%.o, %.o,
$(filter $(dir)/%.o, $(OBJS))))
-
-+VTPM_BIN :=3D vtpmd
-+
- vpath %.c $(strip $(DIRS))
-
- all: $(TPMD)
-@@ -32,10 +35,8 @@ TPMD_GROUP ?=3D tss
- INSTALL    ?=3D install
-
- install: $(TPMD)
--    $(INSTALL) -m 755 -o $(TPMD_USER) -g $(TPMD_GROUP) -d
$(DESTDIR)/var/lib/tpm
--    $(INSTALL) -m 755 -o $(TPMD_USER) -g $(TPMD_GROUP) -d
$(DESTDIR)/var/run/tpm
-     $(INSTALL) -D -d $(DESTDIR)/$(BINDIR)
--    $(INSTALL) -m 755 $(TPMD) $(DESTDIR)/$(BINDIR)
-+    $(INSTALL) -m 755 $(TPMD) $(DESTDIR)/$(BINDIR)/$(VTPM_BIN)
-
- .PHONY: all clean install
-
-diff -Naurp tpm_emulator-0.5.1/tpmd/tpmd.c tpm5-test/tpmd/tpmd.c
---- tpm_emulator-0.5.1/tpmd/tpmd.c    2008-02-14 03:22:48.000000000 -050=
0
-+++ tpm5-test/tpmd/tpmd.c    2009-07-16 11:19:05.000000000 -0400
-@@ -32,6 +32,9 @@
- #include <grp.h>
- #include "tpm_emulator_config.h"
- #include "tpm/tpm_emulator.h"
-+#include "tpm/tpm_structures.h"
-+#include "tpm/tpm_marshalling.h"
-+#include "vtpm_manager.h"
-
- #define TPM_DAEMON_NAME     "tpmd"
- #define TPM_CMD_BUF_SIZE    4096
-@@ -39,6 +42,24 @@
- #define TPM_RANDOM_DEVICE   "/dev/urandom"
- #undef  TPM_MKDIRS
-
-+#ifdef VTPM_MULTI_VM
-+ #define DEV_BE "/dev/vtpm"
-+ #define DEV_FE "/dev/tpm"
-+#else
-+ #define PVM_RX_FIFO_D "/var/vtpm/fifos/tpm_cmd_to_%d.fifo"
-+ #define PVM_TX_FIFO "/var/vtpm/fifos/tpm_rsp_from_all.fifo"
-+ #define HVM_RX_FIFO_D "/var/vtpm/socks/%d.socket"
-+
-+ #define VTPM_RX_FIFO_D "/var/vtpm/fifos/vtpm_rsp_to_%d.fifo"
-+ #define VTPM_TX_FIFO "/var/vtpm/fifos/vtpm_cmd_from_all.fifo"
-+
-+ static char *vtpm_rx_name=3DNULL;
-+#endif
-+
-+ static int vtpm_tx_fh=3D-1, vtpm_rx_fh=3D-1;
-+
-+#define BUFFER_SIZE 2048
-+
- static volatile int stopflag =3D 0;
- static int is_daemon =3D 0;
- static int opt_debug =3D 0;
-@@ -49,6 +70,8 @@ static const char *opt_storage_file =3D "/
- static uid_t opt_uid =3D 0;
- static gid_t opt_gid =3D 0;
- static int tpm_startup =3D 2;
-+static int vtpm_type =3D VTPM_TYPE_PVM;
-+int dmi_id =3D 0;
- static int rand_fh;
-
- void tpm_log(int priority, const char *fmt, ...)
-@@ -90,56 +113,241 @@ uint64_t tpm_get_ticks(void)
-
- int tpm_write_to_file(uint8_t *data, size_t data_length)
- {
--    int fh;
--    ssize_t res;
--    fh =3D open(opt_storage_file, O_WRONLY | O_TRUNC | O_CREAT, S_IRUSR=

| S_IWUSR);
--    if (fh < 0) return -1;
--    while (data_length > 0) {
--        res =3D write(fh, data, data_length);
--    if (res < 0) {
--        close(fh);
--        return -1;
--    }
--    data_length -=3D res;
--    data +=3D res;
-+  int res, out_data_size, in_header_size;
-+  BYTE *ptr, *out_data, *in_header;
-+  UINT32 result, len, in_rsp_size;
-+  UINT16 tag =3D VTPM_TAG_REQ;
-+  =20
-+  printf("Saving NVM\n");
-+  if (vtpm_tx_fh < 0) {
-+#ifdef VTPM_MUTLI_VM
-+    vtpm_tx_fh =3D open(DEV_FE, O_RDWR);
-+#else
-+    vtpm_tx_fh =3D open(VTPM_TX_FIFO, O_WRONLY);
-+#endif
-+  }
-+
-+  if (vtpm_tx_fh < 0) {
-+        return -1;
-+  }
-+
-+  // Send request to VTPM Manager to encrypt data
-+#ifdef VTPM_MUTLI_VM
-+  out_data_size =3D len =3D VTPM_COMMAND_HEADER_SIZE_CLT + data_length;=

-+#else
-+  out_data_size =3D len =3D VTPM_COMMAND_HEADER_SIZE_SRV + data_length;=

-+#endif
-+=20
-+  out_data =3D ptr =3D (BYTE *) malloc(len);
-+
-+  if (ptr =3D=3D NULL
-+#ifndef VTPM_MUTLI_VM
-+      || tpm_marshal_UINT32(&ptr, &len, dmi_id)
-+#endif
-+      || tpm_marshal_UINT16(&ptr, &len, tag)
-+#ifdef VTPM_MUTLI_VM
-+      || tpm_marshal_UINT32(&ptr, &len, out_data_size)
-+#else
-+      || tpm_marshal_UINT32(&ptr, &len, out_data_size - sizeof(uint32_t=
))
-+#endif=20
-+      || tpm_marshal_UINT32(&ptr, &len, VTPM_ORD_SAVENVM)
-+      || tpm_marshal_BYTE_ARRAY(&ptr, &len, data, data_length)) {
-+    free(out_data);
-+    return -1;
-+  }
-+=20
-+  printf("\tSending SaveNVM Command.\n");
-+  res =3D write(vtpm_tx_fh, out_data, out_data_size);
-+  free(out_data);
-+  if (res !=3D out_data_size) return -1;
-+
-+  if (vtpm_rx_fh < 0) {
-+#ifdef VTPM_MUTLI_VM
-+    vtpm_rx_fh =3D vtpm_tx_fh
-+#else
-+    if (vtpm_rx_name =3D=3D NULL) {
-+      vtpm_rx_name =3D malloc(10 + strlen(VTPM_RX_FIFO_D));
-+      sprintf(vtpm_rx_name, VTPM_RX_FIFO_D, (uint32_t) dmi_id);
-     }
--    close(fh);
--    return 0;
-+    vtpm_rx_fh =3D open(vtpm_rx_name, O_RDONLY);
-+#endif
-+  }
-+
-+  if (vtpm_rx_fh < 0) {
-+        return -1;
-+  }
-+=20
-+  // Read Header of response so we can get the size & status
-+#ifdef VTPM_MUTLI_VM
-+  in_header_size =3D len =3D VTPM_COMMAND_HEADER_SIZE_CLT;
-+#else
-+  in_header_size =3D len =3D VTPM_COMMAND_HEADER_SIZE_SRV;
-+#endif
-+  in_header =3D ptr =3D malloc(in_header_size);
-+=20
-+  printf("\tReading SaveNVM header.\n");
-+  res =3D read(vtpm_rx_fh, in_header, in_header_size);
-+
-+  if ( (res !=3D in_header_size)
-+#ifndef VTPM_MUTLI_VM
-+       || tpm_unmarshal_UINT32(&ptr, &len, (UINT32*)&dmi_id)
-+#endif
-+       || tpm_unmarshal_UINT16(&ptr, &len, &tag)
-+       || tpm_unmarshal_UINT32(&ptr, &len, &in_rsp_size)
-+       || tpm_unmarshal_UINT32(&ptr, &len, &result) ) {
-+      free(in_header);
-+      return -1;
-+  }
-+  free(in_header);
-+=20
-+  if (result !=3D VTPM_SUCCESS) {
-+      return -1;=20
-+  }
-+
-+#ifdef VTPM_MUTLI_VM
-+  close(vtpm_tx_fh); close(vtpm_rx_fh);
-+#endif
-+    =20
-+  printf("\tFinishing up SaveNVM\n");
-+  return (0);
- }
-
- int tpm_read_from_file(uint8_t **data, size_t *data_length)
- {
--    int fh;
--    ssize_t res;
--    size_t total_length;
--    fh =3D open(opt_storage_file, O_RDONLY);
--    if (fh < 0) return -1;
--    total_length =3D lseek(fh, 0, SEEK_END);
--    lseek(fh, 0, SEEK_SET);
--    *data =3D tpm_malloc(total_length);
--    if (*data =3D=3D NULL) {
--        close(fh);
--        return -1;
--    }
--    *data_length =3D 0;
--    while (total_length > 0) {
--        res =3D read(fh, &(*data)[*data_length], total_length);
--    if (res < 0) {
--        close(fh);
--        tpm_free(*data);
--        return -1;
--    }
--        *data_length +=3D res;
--    total_length -=3D res;
-+  int res, out_data_size, in_header_size;
-+  uint8_t *ptr, *out_data, *in_header;
-+  UINT16 tag =3D VTPM_TAG_REQ;
-+  UINT32 len, in_rsp_size, result;
-+#ifdef VTPM_MUTLI_VM
-+    int vtpm_rx_fh, vtpm_tx_fh;
-+#endif
-+  =20
-+  printf("Loading NVM.\n");
-+  if (vtpm_tx_fh < 0) {
-+#ifdef VTPM_MUTLI_VM
-+    vtpm_tx_fh =3D open(DEV_FE, O_RDWR);
-+#else
-+    vtpm_tx_fh =3D open(VTPM_TX_FIFO, O_WRONLY);
-+#endif
-+  }
-+
-+  if (vtpm_tx_fh < 0) {
-+    printf("Error in read_from_file:301\n");
-+        return -1;
-+  }
-+
-+  // Send request to VTPM Manager to encrypt data
-+#ifdef VTPM_MUTLI_VM
-+  out_data_size =3D len =3D VTPM_COMMAND_HEADER_SIZE_CLT;
-+#else
-+  out_data_size =3D len =3D VTPM_COMMAND_HEADER_SIZE_SRV;
-+#endif
-+  out_data =3D ptr =3D (BYTE *) malloc(len);
-+
-+  if (ptr =3D=3D NULL
-+#ifndef VTPM_MUTLI_VM
-+      || tpm_marshal_UINT32(&ptr, &len, dmi_id)
-+#endif=20
-+      || tpm_marshal_UINT16(&ptr, &len, tag)
-+#ifdef VTPM_MUTLI_VM
-+      || tpm_marshal_UINT32(&ptr, &len, out_data_size)
-+#else
-+      || tpm_marshal_UINT32(&ptr, &len, out_data_size - sizeof(uint32_t=
))
-+#endif
-+      || tpm_marshal_UINT32(&ptr, &len, VTPM_ORD_LOADNVM)) {
-+    free(out_data);
-+    printf("Error in read_from_file:325\n");
-+
-+    return -1;
-+  }
-+
-+  printf("\tSending LoadNVM command\n");
-+  res =3D write(vtpm_tx_fh, out_data, out_data_size);
-+  free(out_data);
-+  if (res !=3D out_data_size)
-+    {
-+    printf("Error in read_from_file:335\n");
-+    return -1;
-+    }
-+
-+    if (vtpm_rx_fh < 0) {
-+#ifdef VTPM_MUTLI_VM
-+    vtpm_rx_fh =3D vtpm_tx_fh;
-+#else
-+    if (vtpm_rx_name =3D=3D NULL) {
-+      vtpm_rx_name =3D malloc(10 + strlen(VTPM_RX_FIFO_D));
-+      sprintf(vtpm_rx_name, VTPM_RX_FIFO_D, (uint32_t) dmi_id);
-     }
--    close(fh);
--    return 0;
-+    vtpm_rx_fh =3D open(vtpm_rx_name, O_RDONLY);
-+#endif
-+  }
-+
-+  if (vtpm_rx_fh < 0) {
-+    printf("Error in read_from_file:352\n");  =20
-+    return -1;
-+  }
-+=20
-+  // Read Header of response so we can get the size & status
-+#ifdef VTPM_MUTLI_VM
-+  in_header_size =3D len =3D VTPM_COMMAND_HEADER_SIZE_CLT;
-+#else
-+  in_header_size =3D len =3D VTPM_COMMAND_HEADER_SIZE_SRV;
-+#endif
-+  in_header =3D ptr =3D malloc(in_header_size);
-+=20
-+  printf("\tReading LoadNVM header\n");
-+  res =3D read(vtpm_rx_fh, in_header, in_header_size);
-+
-+  if ( (res !=3D in_header_size)
-+#ifndef VTPM_MUTLI_VM
-+       || tpm_unmarshal_UINT32(&ptr, &len, (UINT32*)&dmi_id)
-+#endif
-+       || tpm_unmarshal_UINT16(&ptr, &len, &tag)
-+       || tpm_unmarshal_UINT32(&ptr, &len, &in_rsp_size)
-+       || tpm_unmarshal_UINT32(&ptr, &len, &result) ) {
-+      free(in_header);
-+      printf("Error in read_from_file:375\n");   =20
-+      return -1;
-+  }
-+  free(in_header);
-+=20
-+  if (result !=3D VTPM_SUCCESS) {
-+    printf("Error in read_from_file:381\n");
-+    return -1;=20
-+  }
-+
-+  // Read Encrypted data from VTPM Manager
-+  *data_length =3D in_rsp_size - VTPM_COMMAND_HEADER_SIZE_CLT;
-+  *data =3D (uint8_t *) malloc(*data_length);
-+
-+  printf("\tReading clear data from LoadNVM.\n");
-+  res =3D read(vtpm_rx_fh, *data, *data_length);
-+#ifdef VTPM_MUTLI_VM
-+  close(vtpm_rx_fh);close(vtpm_tx_fh);
-+#endif
-+  =20
-+  printf("\tReturing from loading NVM\n");
-+  if (res !=3D (int)*data_length) {
-+      free(*data);
-+      printf("Error in read_from_file:398\n");
-+      return -1;
-+  } else {
-+      return 0;
-+  }
-+
-+
-+  =20
- }
-
- static void print_usage(char *name)
- {
-     printf("usage: %s [-d] [-f] [-s storage file] [-u unix socket name]=
 "
--           "[-o user name] [-g group name] [-h] [startup mode]\n", name=
);
-+           "[-o user name] [-g group name] [-h]"
-+#ifdef VTPM_MULTI_VM
-+       "clear|save|deactivated\n", name);
-+#else
-+       "clear|save|deactivated pvm|hvm vtpmid\n", name);
-+#endif
-     printf("  d : enable debug mode\n");
-     printf("  f : forces the application to run in the foreground\n");
-     printf("  s : storage file to use (default: %s)\n", opt_storage_fil=
e);
-@@ -205,7 +413,13 @@ static void parse_options(int argc, char
-                 exit(EXIT_SUCCESS);
-         }
-     }
--    if (optind < argc) {
-+    /*Make sure we have all required options*/
-+#ifdef VTPM_MULTI_VM
-+#define EXTRA_OPTS 0
-+#else
-+#define EXTRA_OPTS 2
-+#endif
-+    if (optind < argc - EXTRA_OPTS ) {
-         debug("startup mode =3D '%s'", argv[optind]);
-         if (!strcmp(argv[optind], "clear")) {
-             tpm_startup =3D 1;
-@@ -219,6 +433,25 @@ static void parse_options(int argc, char
-             print_usage(argv[0]);
-             exit(EXIT_SUCCESS);
-         }
-+#ifndef VTPM_MULTI_VM
-+        ++optind;
-+    if(!strcmp(argv[optind], "pvm")) {
-+        vtpm_type =3D VTPM_TYPE_PVM;    // Get commands from vTPM
Manager through fifo
-+    } else if (!strcmp(argv[optind], "hvm")) {
-+        vtpm_type =3D VTPM_TYPE_HVM;    // Get commands from qemu via s=
ocket
-+        } else {
-+        error("Invalid vm mode '%s'; must be 'pvm', "
-+            "or 'hvm' ", argv[optind]);
-+        print_usage(argv[0]);
-+        exit(EXIT_SUCCESS);
-+    }
-+        ++optind;
-+    dmi_id =3D atoi(argv[optind]);
-+#endif
-+    } else {
-+    error("Invalid number of arguments");
-+    print_usage(argv[0]);
-+    exit(EXIT_SUCCESS);
-     }
- }
-
-@@ -348,93 +581,180 @@ static int init_socket(const char *name)
-
- static void main_loop(void)
- {
--    int sock, fh, res;
--    int32_t in_len;
-+    int32_t in_len, written;
-     uint32_t out_len;
--    uint8_t in[TPM_CMD_BUF_SIZE], *out;
-+    uint8_t in[TPM_CMD_BUF_SIZE], *out, *addressed_out;
-+    int guest_id=3D-1;
-+    int i;
-+    char *vtpm_rx_file=3DNULL;
-+    int res;
-+
-+#ifndef VTPM_MULTI_VM
-+    int sockfd =3D -1;
-     struct sockaddr_un addr;
--    socklen_t addr_len;
--    fd_set rfds;
--    struct timeval tv;
-+    struct sockaddr_un client_addr;
-+    unsigned int client_length;
-+#endif
-+
-+    int vtpm_tx_fh=3D-1, vtpm_rx_fh=3D-1;
-+
-+#ifndef VTPM_MULTI_VM
-+  if (vtpm_type =3D=3D VTPM_TYPE_PVM) {
-+    vtpm_rx_file =3D malloc(10 + strlen(PVM_RX_FIFO_D));
-+    sprintf(vtpm_rx_file, PVM_RX_FIFO_D, (uint32_t) dmi_id);
-+  } else {
-+    vtpm_rx_file =3D malloc(10 + strlen(HVM_RX_FIFO_D));
-+    sprintf(vtpm_rx_file, HVM_RX_FIFO_D, (uint32_t) dmi_id);
-+
-+    if ( (sockfd =3D socket(PF_UNIX,SOCK_STREAM,0)) < 0) {
-+          error("Unable to create socket. errno =3D %d\n", errno);
-+      exit (-1);
-+    }
-+
-+    memset(&addr, 0, sizeof(addr));
-+    addr.sun_family =3D AF_UNIX;
-+    strcpy(addr.sun_path,vtpm_rx_file );
-+    unlink(addr.sun_path);
-+  }
-+#endif
-
-     info("staring main loop");
--    /* open UNIX socket */
--    sock =3D init_socket(opt_socket_name);
--    if (sock < 0) exit(EXIT_FAILURE);
-     /* init tpm emulator */
--    debug("initializing TPM emulator: %d", tpm_startup);
-+#ifdef VTPM_MULTI_VM
-+    debug("initializing TPM emulator: state=3D%d", tpm_startup);
-+#else
-+    debug("initializing TPM emulator: state=3D%d, type=3D%d, id=3D%d",
tpm_startup, vtpm_type, dmi_id);
-+#endif
-     tpm_emulator_init(tpm_startup);
-     /* start command processing */
-     while (!stopflag) {
-         /* wait for incomming connections */
-         debug("waiting for connections...");
--        FD_ZERO(&rfds);
--        FD_SET(sock, &rfds);
--        tv.tv_sec =3D 10;
--        tv.tv_usec =3D 0;
--        res =3D select(sock + 1, &rfds, NULL, NULL, &tv);
--        if (res < 0) {
--            error("select(sock) failed: %s", strerror(errno));
--            break;
--        } else if (res =3D=3D 0) {
--            continue;
--        }
--        addr_len =3D sizeof(addr);
--        fh =3D accept(sock, (struct sockaddr*)&addr, &addr_len);
--        if (fh < 0) {
--            error("accept() failed: %s", strerror(errno));
--            continue;
--        }
-+    if (vtpm_rx_fh < 0) {
-+#ifdef VTPM_MUTLI_VM
-+        vtpm_rx_fh =3D open(DEV_BE, O_RDWR);
-+#else
-+        if (vtpm_type =3D=3D VTPM_TYPE_PVM)
-+        {
-+        vtpm_rx_fh =3D open(vtpm_rx_file, O_RDONLY);
-+        } else {
-+        if (bind(sockfd, (struct sockaddr *)&addr, sizeof(addr)) < 0) {=

-+            error("Unable to bind(). errno =3D %d\n", errno);
-+            exit (-1);
-+        }
-+
-+        if (listen(sockfd, 10) <0) {
-+            error("Unable to listen(). errno =3D %d\n", errno);
-+            exit (-1);
-+        }
-+
-+         memset(&client_addr, 0, sizeof(client_addr));
-+         client_length =3D sizeof(client_addr);
-+
-+         vtpm_rx_fh =3D vtpm_tx_fh =3D accept(sockfd, (struct sockaddr
*)&client_addr, &client_length);
-+        }
-+#endif
-+    }
-+  =20
-+    /*Error Checking*/
-+    if (vtpm_rx_fh < 0) {
-+      error("Failed to open devices to listen to guest.\n");
-+      exit(-1);
-+    }
-+
-         /* receive and handle commands */
-         in_len =3D 0;
-         do {
-             debug("waiting for commands...");
--            FD_ZERO(&rfds);
--            FD_SET(fh, &rfds);
--            tv.tv_sec =3D TPM_COMMAND_TIMEOUT;
--            tv.tv_usec =3D 0;
--            res =3D select(fh + 1, &rfds, NULL, NULL, &tv);
--            if (res < 0) {
--                error("select(fh) failed: %s", strerror(errno));
--                close(fh);
--                break;
--            } else if (res =3D=3D 0) {
--#ifdef TPMD_DISCONNECT_IDLE_CLIENTS      =20
--                info("connection closed due to inactivity");
--                close(fh);
--                break;
--#else      =20
--                continue;
--#endif      =20
--            }
--            in_len =3D read(fh, in, sizeof(in));
--            if (in_len > 0) {
-+
-+            in_len =3D read(vtpm_rx_fh, in, sizeof(in));
-+        /*Magic size of minimum TPM command is 6*/
-+        //FIXME Magic size check may not be required anymore
-+            if (in_len < 6) {
-+        info("Recv incomplete command of %d bytes.", in_len);
-+        if (in_len <=3D 0) {
-+            close(vtpm_rx_fh);
-+            vtpm_rx_fh =3D -1;
-+            continue;
-+                 }
-+        } else {
-+        /*Debug Printouts*/
-                 debug("received %d bytes", in_len);
-+        debug_nostop("Recv[%d]: 0x", in_len);
-+        for (i=3D0; i< in_len; i++)
-+            debug_more("%x ", in[i]);
-+        debug_more("\n");
-+        /*Multiple Guest check*/
-+        if (guest_id =3D=3D -1) {
-+            guest_id =3D *((int32_t *) in);
-+        } else {
-+            if (guest_id !=3D *((int32_t *) in) ) {
-+            error("WARNING: More than one guest attached\n");
-+            }
-+        }
-+
-+        /*Open tx handle now*/
-+        if (vtpm_tx_fh < 0) {
-+#ifdef VTPM_MUTLI_VM
-+            vtpm_tx_fh =3D open(DEV_BE, O_RDWR);
-+            vtpm_rx_fh =3D vtpm_tx_fh;
-+#else
-+            if (vtpm_type =3D=3D VTPM_TYPE_PVM) {
-+            vtpm_tx_fh =3D open(PVM_TX_FIFO, O_WRONLY);
-+                 } // No need to open the other direction for HVM
-+#endif
-+        }
-+        if (vtpm_tx_fh < 0) {
-+          error("Failed to open devices to respond to guest.\n");
-+          exit(-1);
-+        }
-+
-+        /*Handle the TPM command now*/
-                 out =3D NULL;
--                res =3D tpm_handle_command(in, in_len, &out, &out_len);=

-+                res =3D tpm_handle_command(in + sizeof(uint32_t), in_le=
n
- sizeof(uint32_t), &out, &out_len);
-                 if (res < 0) {
-                     error("tpm_handle_command() failed");
-                 } else {
-                     debug("sending %d bytes", out_len);
-+            //FIXME this prepending may or may not be needed
-+            /*Prepend the first 4 bytes of the in buffer.. why?*/
-+            addressed_out =3D (uint8_t *) tpm_malloc(sizeof(uint32_t) +=

out_len);
-+            *(uint32_t *) addressed_out =3D *(uint32_t *) in;
-+            memcpy(addressed_out + sizeof(uint32_t), out, out_len);
-+            out_len +=3D sizeof(uint32_t);
-+            /*End Prepend*/
-+
-+            /*Perform write operation now*/
-                     while (out_len > 0) {
--                        res =3D write(fh, out, out_len);
-+                        res =3D write(vtpm_tx_fh, addressed_out, out_le=
n);
-+
-                         if (res < 0) {
-                             error("write(%d) failed: %s", out_len,
strerror(errno));
-                             break;
--                        }
-+                        } else {
-+              debug_nostop("Sent[%Zu]: ", out_len);
-+              for (i=3D0; (unsigned int)i< out_len; i++)
-+                debug_more("%x ", addressed_out[i]);
-+              debug_more("\n");
-+            }
-                         out_len    -=3D res;
-                     }
-                     tpm_free(out);
-+            tpm_free(addressed_out);
-                 }
-             }
-         } while (in_len > 0);
--        close(fh);
-+        //close(fh);
-     }
-+  =20
-     /* shutdown tpm emulator */
-     tpm_emulator_shutdown();
--    /* close socket */
--    close(sock);
--    unlink(opt_socket_name);
-+    /* Close handles */
-+    close(vtpm_tx_fh);
-+#ifndef VTPM_MULTI_VM
-+    close(vtpm_rx_fh);
-+    free(vtpm_rx_file);
-+#endif
-     info("main loop stopped");
- }
-
-@@ -450,12 +770,13 @@ int main(int argc, char **argv)
-     /* open random device */
-     init_random();
-     /* init signal handlers */
--    init_signal_handler();
-+    //init_signal_handler();
-     /* unless requested otherwiese, fork and daemonize process */
--    if (!opt_foreground) daemonize();
-+    //if (!opt_foreground) daemonize();
-     /* start main processing loop */
-     main_loop();
-     info("stopping TPM Emulator daemon");
-     closelog();
-     return 0;
- }
-+
-diff -Naurp tpm_emulator-0.5.1/tpmd/tpm_emulator_config.h
tpm5-test/tpmd/tpm_emulator_config.h
---- tpm_emulator-0.5.1/tpmd/tpm_emulator_config.h    2008-02-14
03:22:48.000000000 -0500
-+++ tpm5-test/tpmd/tpm_emulator_config.h    2009-07-16
11:25:26.000000000 -0400
-@@ -29,23 +29,28 @@
-
- /* TPM emulator configuration */
-
--#undef  TPM_STRONG_PERSISTENCE
--#undef  TPM_GENERATE_EK
-+#define  TPM_STRONG_PERSISTENCE
-+#define  TPM_GENERATE_EK
- #undef  TPM_GENERATE_SEED_DAA
- #undef  TPM_MEMORY_ALIGNMENT_MANDATORY
-
-+extern int dmi_id;
-+
- /* log macros */
-
- void tpm_log(int priority, const char *fmt, ...);
-
--#define debug(fmt, ...) tpm_log(LOG_DEBUG, "%s:%d: Debug: " fmt "\n", \=

--                                __FILE__, __LINE__, ## __VA_ARGS__)
--#define info(fmt, ...)  tpm_log(LOG_INFO, "%s:%d: Info: " fmt "\n", \
--                                __FILE__, __LINE__, ## __VA_ARGS__)
--#define error(fmt, ...) tpm_log(LOG_ERR, "%s:%d: Error: " fmt "\n", \
--                                __FILE__, __LINE__, ## __VA_ARGS__)
--#define alert(fmt, ...) tpm_log(LOG_ALERT, "%s:%d: Alert: " fmt "\n", \=

--                                __FILE__, __LINE__, ## __VA_ARGS__)
-+#define debug(fmt, ...) tpm_log(LOG_DEBUG, "VTPMD[%d]: %s:%d: Debug: "
fmt "\n", \
-+                                dmi_id, __FILE__, __LINE__, ##
__VA_ARGS__)
-+#define info(fmt, ...)  tpm_log(LOG_INFO, "VTPMD[%d]: %s:%d: Info: "
fmt "\n", \
-+                                dmi_id, __FILE__, __LINE__, ##
__VA_ARGS__)
-+#define error(fmt, ...) tpm_log(LOG_ERR, "VTPMD[%d]: %s:%d: Error: "
fmt "\n", \
-+                                dmi_id, __FILE__, __LINE__, ##
__VA_ARGS__)
-+#define alert(fmt, ...) tpm_log(LOG_ALERT, "VTPMD[%d]: %s:%d: Alert: "
fmt "\n", \
-+                                dmi_id, __FILE__, __LINE__, ##
__VA_ARGS__)
-+#define debug_nostop(fmt, ...) tpm_log(LOG_DEBUG, "VTPMD[%d]: %s:%d:
Debug: " fmt, \
-+                                dmi_id, __FILE__, __LINE__, ##
__VA_ARGS__)
-+#define debug_more(fmt, ...) tpm_log(LOG_DEBUG, fmt, ## __VA_ARGS__)
-
- /*  min/max macros that also do strict type-checking */
-
diff --git a/tools/vtpm/vtpm-0.7.4.patch b/tools/vtpm/vtpm-0.7.4.patch
--- /dev/null
+++ b/tools/vtpm/vtpm-0.7.4.patch
@@ -0,0 +1,1138 @@
+diff -Naur tpm_emulator-0.7.4-orig/CMakeLists.txt
tpm_emulator-0.7.4/CMakeLists.txt
+--- tpm_emulator-0.7.4-orig/CMakeLists.txt    2012-09-17
13:16:27.832582475 -0400
++++ tpm_emulator-0.7.4/CMakeLists.txt    2012-09-17 13:16:41.621654594
-0400
+@@ -63,6 +63,7 @@
+ # include root directories
+ include_directories(${CMAKE_SOURCE_DIR})
+ include_directories(${CMAKE_BINARY_DIR})
++include_directories(../../vtpm_manager/manager)
+
+ # add internal libraries
+ add_subdirectory(tpm)
+diff -Naur tpm_emulator-0.7.4-orig/CMakeLists.txt.orig
tpm_emulator-0.7.4/CMakeLists.txt.orig
+--- tpm_emulator-0.7.4-orig/CMakeLists.txt.orig    1969-12-31
19:00:00.000000000 -0500
++++ tpm_emulator-0.7.4/CMakeLists.txt.orig    2011-12-20
13:30:06.000000000 -0500
+@@ -0,0 +1,80 @@
++# Software-based Trusted Platform Module (TPM) Emulator
++# Copyright (C) 2004-2010 Mario Strasser <mast@gmx.net>
++#
++# $Id: CMakeLists.txt 475 2011-12-20 18:21:19Z mast $
++
++project(TPM_Emulator C)
++
++cmake_minimum_required(VERSION 2.4)
++set(CMAKE_ALLOW_LOOSE_LOOP_CONSTRUCTS true)
++if(COMMAND cmake_policy)
++cmake_policy(SET CMP0003 NEW)
++endif()
++
++# enforce out of source build
++string(COMPARE EQUAL "${CMAKE_SOURCE_DIR}" "${CMAKE_BINARY_DIR}"
IS_INSOURCE)
++if(IS_INSOURCE)
++    message(FATAL_ERROR "${PROJECT_NAME} requires an out of source
build.")
++endif()
++
++# set project and build version
++set(${PROJECT_NAME}_VERSION_MAJOR 0)
++set(${PROJECT_NAME}_VERSION_MINOR 7)
++string(REGEX REPLACE ".*Revision: ([0-9]+).*" "\\1"
${PROJECT_NAME}_VERSION_BUILD "$Revision: 475 $")
++
++# create project configuration
++if(WIN32)
++STRING(REGEX REPLACE "\\\\" "/" PROGRAMFILES
"$ENV{PROGRAMFILES}/${PROJECT_NAME}")
++set(TPM_LOG_FILE "${PROGRAMFILES}/tpmd.log")
++set(TPM_STORAGE_NAME
"${PROGRAMFILES}/tpm_emulator-1_2_${${PROJECT_NAME}_VERSION_MAJOR}_${${PR=
OJECT_NAME}_VERSION_MINOR}")
++set(TPM_DEVICE_NAME "//./pipe/tpmd:0")
++elseif(APPLE)
++set(TPM_LOG_FILE "/private/var/log/tpmd.log")
++set(TPM_SOCKET_NAME "/private/var/run/tpm/tpmd_socket:0")
++set(TPM_STORAGE_NAME
"/private/var/lib/tpm/tpm_emulator-1_2_${${PROJECT_NAME}_VERSION_MAJOR}_$=
{${PROJECT_NAME}_VERSION_MINOR}")
++set(TPM_DEVICE_NAME "/dev/tpm")
++else()
++set(TPM_LOG_FILE "/var/log/tpmd.log")
++set(TPM_SOCKET_NAME "/var/run/tpm/tpmd_socket:0")
++set(TPM_STORAGE_NAME
"/var/lib/tpm/tpm_emulator-1_2_${${PROJECT_NAME}_VERSION_MAJOR}_${${PROJE=
CT_NAME}_VERSION_MINOR}")
++set(TPM_DEVICE_NAME "/dev/tpm")
++endif()
++configure_file(${CMAKE_CURRENT_SOURCE_DIR}/config.h.in
${CMAKE_CURRENT_BINARY_DIR}/config.h)
++add_definitions(-Wall -Werror -Wno-unused-parameter -Wpointer-arith
-Wcast-align -Wwrite-strings)
++if("${CMAKE_SYSTEM}" MATCHES "Linux")
++    add_definitions(-Wextra)
++endif()
++if(USE_OPENSSL)
++    add_definitions(-DUSE_OPENSSL)
++endif()
++include_directories("/opt/local/include")
++link_directories("/opt/local/lib")
++
++# configure CPack
++set(CPACK_PACKAGE_VERSION_MAJOR ${${PROJECT_NAME}_VERSION_MAJOR})
++set(CPACK_PACKAGE_VERSION_MINOR ${${PROJECT_NAME}_VERSION_MINOR})
++set(CPACK_SOURCE_PACKAGE_FILE_NAME
"tpm_emulator-${CPACK_PACKAGE_VERSION_MAJOR}.${CPACK_PACKAGE_VERSION_MINO=
R}.4")
++set(CPACK_SOURCE_GENERATOR "TGZ")
++set(CPACK_SOURCE_IGNORE_FILES ".svn/" "/build/" "/.project" "/.cproject=
")
++set(CPACK_GENERATOR "ZIP")
++set(CPACK_SET_DESTDIR ON)
++include(CPack)
++
++# include root directories
++include_directories(${CMAKE_SOURCE_DIR})
++include_directories(${CMAKE_BINARY_DIR})
++
++# add internal libraries
++add_subdirectory(tpm)
++add_subdirectory(mtm)
++add_subdirectory(crypto)
++
++# add TDDL
++add_subdirectory(tddl)
++
++# add kernel modules
++add_subdirectory(tpmd_dev)
++
++# add executables
++add_subdirectory(tpmd)
++
+diff -Naur tpm_emulator-0.7.4-orig/tpm/tpm_emulator_extern.h
tpm_emulator-0.7.4/tpm/tpm_emulator_extern.h
+--- tpm_emulator-0.7.4-orig/tpm/tpm_emulator_extern.h    2012-09-17
13:16:27.834582486 -0400
++++ tpm_emulator-0.7.4/tpm/tpm_emulator_extern.h    2012-09-17
13:16:41.621654594 -0400
+@@ -29,6 +29,8 @@
+   TPM_LOG_ERROR
+ };
+
++extern int dmi_id;
++
+ void (*tpm_log)(int priority, const char *fmt, ...);
+
+ #if defined(_WIN32) || defined(_WIN64)
+@@ -37,12 +39,16 @@
+ #define __BFILE__ ((strrchr(__FILE__, '/') ? : __FILE__ - 1) + 1)
+ #endif
+
+-#define debug(fmt, ...) tpm_log(TPM_LOG_DEBUG, "%s:%d: Debug: " fmt
"\n", \
+-                                __BFILE__, __LINE__, ## __VA_ARGS__)
+-#define info(fmt, ...)  tpm_log(TPM_LOG_INFO, "%s:%d: Info: " fmt "\n",=
 \
+-                                __BFILE__, __LINE__, ## __VA_ARGS__)
+-#define error(fmt, ...) tpm_log(TPM_LOG_ERROR, "%s:%d: Error: " fmt
"\n", \
+-                                __BFILE__, __LINE__, ## __VA_ARGS__)
++#define debug(fmt, ...) tpm_log(TPM_LOG_DEBUG, "VTPMD[%d]: %s:%d:
Debug: " fmt "\n", \
++                                dmi_id, __BFILE__, __LINE__, ##
__VA_ARGS__)
++#define info(fmt, ...)  tpm_log(TPM_LOG_INFO, "VTPMD[%d]: %s:%d: Info:
" fmt "\n", \
++                                dmi_id, __BFILE__, __LINE__, ##
__VA_ARGS__)
++#define error(fmt, ...) tpm_log(TPM_LOG_ERROR, "VTPMD[%d]: %s:%d:
Error: " fmt "\n", \
++                                dmi_id, __BFILE__, __LINE__, ##
__VA_ARGS__)
++#define debug_nostop(fmt, ...) tpm_log(TPM_LOG_DEBUG, "VTPMD[%d]:
%s:%d: Debug: " fmt, \
++                                dmi_id, __BFILE__, __LINE__, ##
__VA_ARGS__)
++#define debug_more(fmt, ...) tpm_log(TPM_LOG_DEBUG, fmt, ## __VA_ARGS__=
)
++
+ /* initialization */
+ int (*tpm_extern_init)(void);
+ void (*tpm_extern_release)(void);
+diff -Naur tpm_emulator-0.7.4-orig/tpmd/unix/tpmd.c
tpm_emulator-0.7.4/tpmd/unix/tpmd.c
+--- tpm_emulator-0.7.4-orig/tpmd/unix/tpmd.c    2012-09-17
13:16:27.839582511 -0400
++++ tpm_emulator-0.7.4/tpmd/unix/tpmd.c    2012-09-17
13:16:41.623654604 -0400
+@@ -30,9 +30,31 @@
+ #include <grp.h>
+ #include "config.h"
+ #include "tpm/tpm_emulator.h"
++#include "tpm/tpm_structures.h"
++#include "tpm/tpm_marshalling.h"
++#include "vtpm_manager.h"
+
+ #define TPM_COMMAND_TIMEOUT 30
+
++#define TPM_DAEMON_NAME     "tpmd"
++#define TPM_CMD_BUF_SIZE    4096
++#define TPM_RANDOM_DEVICE   "/dev/urandom"
++#undef  TPM_MKDIRS
++
++#define PVM_RX_FIFO_D "/var/vtpm/fifos/tpm_cmd_to_%d.fifo"
++#define PVM_TX_FIFO "/var/vtpm/fifos/tpm_rsp_from_all.fifo"
++#define HVM_RX_FIFO_D "/var/vtpm/socks/%d.socket"
++
++#define VTPM_RX_FIFO_D "/var/vtpm/fifos/vtpm_rsp_to_%d.fifo"
++#define VTPM_TX_FIFO "/var/vtpm/fifos/vtpm_cmd_from_all.fifo"
++
++static char *vtpm_rx_name=3DNULL;
++
++static int vtpm_tx_fh=3D-1, vtpm_rx_fh=3D-1;
++
++#define BUFFER_SIZE 2048
++
++
+ static volatile int stopflag =3D 0;
+ static int is_daemon =3D 0;
+ static int opt_debug =3D 0;
+@@ -44,6 +66,9 @@
+ static uint32_t tpm_config =3D 0;
+ extern const char *tpm_storage_file;
+
++static int vtpm_type =3D VTPM_TYPE_PVM;
++int dmi_id;
++
+ void my_log(int priority, const char *fmt, ...)
+ {
+     va_list ap, bp;
+@@ -156,35 +181,218 @@
+             exit(EXIT_SUCCESS);
+         }
+     } else {
+-        /* if no startup mode is given assume save if a configuration
+-           file is available, clear otherwise */
+-        int fh =3D open(tpm_storage_file, O_RDONLY);
+-        if (fh < 0) {
+-            tpm_startup =3D 1;
+-            info("no startup mode was specified; asuming 'clear'");
+-        } else {
+-            tpm_startup =3D 2;
+-            close(fh);
+-        }
++       tpm_startup =3D 1;
++       info("no startup mode was specified; asuming 'clear'");
+     }
++    /* GET VM TYPE */
++    ++optind;
++    if (optind < argc) {
++       if(!strcmp(argv[optind], "pvm")) {
++      vtpm_type =3D VTPM_TYPE_PVM;      // Get commands from vTPM
Manager through fifo
++       } else if (!strcmp(argv[optind], "hvm")) {
++      vtpm_type =3D VTPM_TYPE_HVM;      // Get commands from qemu via s=
ocket
++       } else {
++      error("Invalid vm mode '%s'; must be 'pvm', "
++        "or 'hvm' ", argv[optind]);
++      print_usage(argv[0]);
++      exit(EXIT_SUCCESS);
++       }
++    } else {
++       vtpm_type =3D VTPM_TYPE_PVM;
++       info("no vm mode specified; assuming 'pvm'");
++    }
++    /* GET DMI ID */
++    ++optind;
++    if(optind >=3D argc || sscanf(argv[optind], "%d", &dmi_id) !=3D 1) =
{
++       error("Missing or non-integer dmi_id specified!");
++       print_usage(argv[0]);
++       exit(EXIT_SUCCESS);
++    }
++}
++
++int vtpm_write_to_file(uint8_t *data, size_t data_length)
++{
++  int res, out_data_size, in_header_size;
++  BYTE *ptr, *out_data, *in_header;
++  UINT32 result, len, in_rsp_size;
++  UINT16 tag =3D VTPM_TAG_REQ;
++
++  printf("Saving NVM\n");
++  if (vtpm_tx_fh < 0) {
++     vtpm_tx_fh =3D open(VTPM_TX_FIFO, O_WRONLY);
++  }
++
++  if (vtpm_tx_fh < 0) {
++                return -1;
++  }
++
++  // Send request to VTPM Manager to encrypt data
++  out_data_size =3D len =3D VTPM_COMMAND_HEADER_SIZE_SRV + data_length;=

++
++  out_data =3D ptr =3D (BYTE *) malloc(len);
++
++  if (ptr =3D=3D NULL
++    || tpm_marshal_UINT32(&ptr, &len, dmi_id)
++    || tpm_marshal_UINT16(&ptr, &len, tag)
++    || tpm_marshal_UINT32(&ptr, &len, out_data_size - sizeof(uint32_t))=

++    || tpm_marshal_UINT32(&ptr, &len, VTPM_ORD_SAVENVM)
++    || tpm_marshal_BYTE_ARRAY(&ptr, &len, data, data_length)) {
++     free(out_data);
++     return -1;
++  }
++
++  printf("\tSending SaveNVM Command.\n");
++  res =3D write(vtpm_tx_fh, out_data, out_data_size);
++  free(out_data);
++  if (res !=3D out_data_size) return -1;
++
++  if (vtpm_rx_fh < 0) {
++    if (vtpm_rx_name =3D=3D NULL) {
++      vtpm_rx_name =3D malloc(10 + strlen(VTPM_RX_FIFO_D));
++      sprintf(vtpm_rx_name, VTPM_RX_FIFO_D, (uint32_t) dmi_id);
++    }
++        vtpm_rx_fh =3D open(vtpm_rx_name, O_RDONLY);
++  }
++
++  if (vtpm_rx_fh < 0) {
++                return -1;
++  }
++
++  // Read Header of response so we can get the size & status
++  in_header_size =3D len =3D VTPM_COMMAND_HEADER_SIZE_SRV;
++  in_header =3D ptr =3D malloc(in_header_size);
++
++  printf("\tReading SaveNVM header.\n");
++  res =3D read(vtpm_rx_fh, in_header, in_header_size);
++
++  if ( (res !=3D in_header_size)
++    || tpm_unmarshal_UINT32(&ptr, &len, (UINT32*)&dmi_id)
++    || tpm_unmarshal_UINT16(&ptr, &len, &tag)
++    || tpm_unmarshal_UINT32(&ptr, &len, &in_rsp_size)
++    || tpm_unmarshal_UINT32(&ptr, &len, &result) ) {
++     free(in_header);
++     return -1;
++  }
++  free(in_header);
++
++  if (result !=3D VTPM_SUCCESS) {
++      return -1;
++  }
++
++  printf("\tFinishing up SaveNVM\n");
++  return (0);
++}
++
++int vtpm_read_from_file(uint8_t **data, size_t *data_length)
++{
++   int res, out_data_size, in_header_size;
++   uint8_t *ptr, *out_data, *in_header;
++   UINT16 tag =3D VTPM_TAG_REQ;
++   UINT32 len, in_rsp_size, result;
++
++   printf("Loading NVM.\n");
++   if (vtpm_tx_fh < 0) {
++      vtpm_tx_fh =3D open(VTPM_TX_FIFO, O_WRONLY);
++   }
++
++   if (vtpm_tx_fh < 0) {
++      printf("Error in read_from_file:301\n");
++      return -1;
++   }
++
++   // Send request to VTPM Manager to encrypt data
++   out_data_size =3D len =3D VTPM_COMMAND_HEADER_SIZE_SRV;
++   out_data =3D ptr =3D (BYTE *) malloc(len);
++
++   if (ptr =3D=3D NULL
++     || tpm_marshal_UINT32(&ptr, &len, dmi_id)
++     || tpm_marshal_UINT16(&ptr, &len, tag)
++     || tpm_marshal_UINT32(&ptr, &len, out_data_size - sizeof(uint32_t)=
)
++     || tpm_marshal_UINT32(&ptr, &len, VTPM_ORD_LOADNVM)) {
++      free(out_data);
++      printf("Error in read_from_file:325\n");
++
++      return -1;
++   }
++
++   printf("\tSending LoadNVM command\n");
++   res =3D write(vtpm_tx_fh, out_data, out_data_size);
++   free(out_data);
++   if (res !=3D out_data_size)
++   {
++      printf("Error in read_from_file:335\n");
++      return -1;
++   }
++
++   if (vtpm_rx_fh < 0) {
++      if (vtpm_rx_name =3D=3D NULL) {
++     vtpm_rx_name =3D malloc(10 + strlen(VTPM_RX_FIFO_D));
++     sprintf(vtpm_rx_name, VTPM_RX_FIFO_D, (uint32_t) dmi_id);
++      }
++      vtpm_rx_fh =3D open(vtpm_rx_name, O_RDONLY);
++   }
++
++   if (vtpm_rx_fh < 0) {
++      printf("Error in read_from_file:352\n");
++      return -1;
++   }
++
++   // Read Header of response so we can get the size & status
++   in_header_size =3D len =3D VTPM_COMMAND_HEADER_SIZE_SRV;
++   in_header =3D ptr =3D malloc(in_header_size);
++
++   printf("\tReading LoadNVM header\n");
++   res =3D read(vtpm_rx_fh, in_header, in_header_size);
++
++   if ( (res !=3D in_header_size)
++     || tpm_unmarshal_UINT32(&ptr, &len, (UINT32*)&dmi_id)
++     || tpm_unmarshal_UINT16(&ptr, &len, &tag)
++     || tpm_unmarshal_UINT32(&ptr, &len, &in_rsp_size)
++     || tpm_unmarshal_UINT32(&ptr, &len, &result) ) {
++      free(in_header);
++      printf("Error in read_from_file:375\n");
++      return -1;
++   }
++   free(in_header);
++
++   if (result !=3D VTPM_SUCCESS) {
++      printf("Error in read_from_file:381\n");
++      return -1;
++   }
++
++   // Read Encrypted data from VTPM Manager
++   *data_length =3D in_rsp_size - VTPM_COMMAND_HEADER_SIZE_CLT;
++   *data =3D (uint8_t *) malloc(*data_length);
++
++   printf("\tReading clear data from LoadNVM.\n");
++   res =3D read(vtpm_rx_fh, *data, *data_length);
++
++   printf("\tReturing from loading NVM\n");
++   if (res !=3D (int)*data_length) {
++      free(*data);
++      printf("Error in read_from_file:398\n");
++      return -1;
++   } else {
++      return 0;
++   }
+ }
+
+ static void switch_uid_gid(void)
+ {
+-    if (opt_gid !=3D getgid()) {
+-        info("switching effective group ID to %d", opt_gid);
+-        if (setgid(opt_gid) =3D=3D -1) {
+-            error("switching effective group ID to %d failed: %s",
opt_gid, strerror(errno));
+-            exit(EXIT_FAILURE);
+-        }
+-    }
+-    if (opt_uid !=3D getuid()) {
+-        info("switching effective user ID to %d", opt_uid);
+-        if (setuid(opt_uid) =3D=3D -1) {
+-            error("switching effective user ID to %d failed: %s",
opt_uid, strerror(errno));
+-            exit(EXIT_FAILURE);
+-        }
+-    }
++   if (opt_gid !=3D getgid()) {
++      info("switching effective group ID to %d", opt_gid);
++      if (setgid(opt_gid) =3D=3D -1) {
++     error("switching effective group ID to %d failed: %s", opt_gid,
strerror(errno));
++     exit(EXIT_FAILURE);
++      }
++   }
++   if (opt_uid !=3D getuid()) {
++      info("switching effective user ID to %d", opt_uid);
++      if (setuid(opt_uid) =3D=3D -1) {
++     error("switching effective user ID to %d failed: %s", opt_uid,
strerror(errno));
++     exit(EXIT_FAILURE);
++      }
++   }
+ }
+
+ static void signal_handler(int sig)
+@@ -214,174 +422,175 @@
+     }
+ }
+
+-static void daemonize(void)
+-{
+-    pid_t sid, pid;
+-    info("daemonizing process");
+-    pid =3D fork();
+-    if (pid < 0) {
+-        error("fork() failed: %s", strerror(errno));
+-        exit(EXIT_FAILURE);
+-    }
+-    if (pid > 0) exit(EXIT_SUCCESS);
+-    pid =3D getpid();
+-    sid =3D setsid();
+-    if (sid < 0) {
+-        error("setsid() failed: %s", strerror(errno));
+-        exit(EXIT_FAILURE);
+-    }
+-    if (chdir("/") < 0) {
+-        error("chdir() failed: %s", strerror(errno));
+-        exit(EXIT_FAILURE);
+-    }
+-    close(STDIN_FILENO);
+-    close(STDOUT_FILENO);
+-    close(STDERR_FILENO);
+-    is_daemon =3D 1;
+-    info("process was successfully daemonized: pid=3D%d sid=3D%d", pid,=
 sid);
+-}
+-
+-static int mkdirs(const char *path)
+-{
+-    char *copy =3D strdup(path);
+-    char *p =3D strchr(copy + 1, '/');
+-    while (p !=3D NULL) {
+-        *p =3D '\0';
+-        if ((mkdir(copy, 0755) =3D=3D -1) && (errno !=3D EEXIST)) {
+-            free(copy);
+-            return errno;
+-        }
+-        *p =3D '/';
+-        p =3D strchr(p + 1, '/');
+-    }
+-    free(copy);
+-    return 0;
+-}
+-
+-static int init_socket(const char *name)
+-{
+-    int sock;
+-    struct sockaddr_un addr;
+-    info("initializing socket %s", name);
+-    sock =3D socket(AF_UNIX, SOCK_STREAM, 0);
+-    if (sock < 0) {
+-        error("socket(AF_UNIX) failed: %s", strerror(errno));
+-        return -1;
+-    }
+-    mkdirs(name);
+-    addr.sun_family =3D AF_UNIX;
+-    strncpy(addr.sun_path, name, sizeof(addr.sun_path));
+-    umask(0177);
+-    if (bind(sock, (struct sockaddr*)&addr, sizeof(addr)) < 0) {
+-        error("bind(%s) failed: %s", addr.sun_path, strerror(errno));
+-        close(sock);
+-        return -1;
+-    }
+-    listen(sock, 1);
+-    return sock;
+-}
+-
+ static void main_loop(void)
+ {
+-    int sock, fh, res;
+     int32_t in_len;
+     uint32_t out_len;
+-    uint8_t in[TPM_CMD_BUF_SIZE], *out;
++    uint8_t in[TPM_CMD_BUF_SIZE], *out, *addressed_out;
++    int guest_id=3D-1;
++    int i;
++    char *vtpm_rx_file=3DNULL;
++    int res;
++
++    int sockfd =3D -1;
+     struct sockaddr_un addr;
+-    socklen_t addr_len;
+-    fd_set rfds;
+-    struct timeval tv;
++    struct sockaddr_un client_addr;
++    unsigned int client_length;
++
++    int vtpm_tx_fh=3D-1, vtpm_rx_fh=3D-1;
++
++  if (vtpm_type =3D=3D VTPM_TYPE_PVM) {
++    vtpm_rx_file =3D malloc(10 + strlen(PVM_RX_FIFO_D));
++    sprintf(vtpm_rx_file, PVM_RX_FIFO_D, (uint32_t) dmi_id);
++  } else {
++    vtpm_rx_file =3D malloc(10 + strlen(HVM_RX_FIFO_D));
++    sprintf(vtpm_rx_file, HVM_RX_FIFO_D, (uint32_t) dmi_id);
++
++    if ( (sockfd =3D socket(PF_UNIX,SOCK_STREAM,0)) < 0) {
++          error("Unable to create socket. errno =3D %d\n", errno);
++      exit (-1);
++    }
++
++    memset(&addr, 0, sizeof(addr));
++    addr.sun_family =3D AF_UNIX;
++    strcpy(addr.sun_path,vtpm_rx_file );
++    unlink(addr.sun_path);
++  }
+
+     info("staring main loop");
+-    /* open UNIX socket */
+-    sock =3D init_socket(opt_socket_name);
+-    if (sock < 0) exit(EXIT_FAILURE);
+     /* init tpm emulator */
+-    debug("initializing TPM emulator");
+-    if (tpm_emulator_init(tpm_startup, tpm_config) !=3D 0) {
+-        error("tpm_emulator_init() failed");
+-        close(sock);
+-        unlink(opt_socket_name);
+-        exit(EXIT_FAILURE);
+-    }
++    debug("initializing TPM emulator: state=3D%d, type=3D%d, id=3D%d",
tpm_startup, vtpm_type, dmi_id);
++    /* Set config flags that must be on for vtpm operation */
++    tpm_config |=3D TPM_CONF_STRONG_PERSISTENCE;
++    tpm_config &=3D ~TPM_CONF_USE_INTERNAL_PRNG;
++    tpm_config |=3D TPM_CONF_GENERATE_EK;
++    tpm_config |=3D TPM_CONF_GENERATE_SEED_DAA;
++    /*Start the emulator */
++    tpm_emulator_init(tpm_startup, tpm_config);
+     /* start command processing */
+     while (!stopflag) {
+         /* wait for incomming connections */
+         debug("waiting for connections...");
+-        FD_ZERO(&rfds);
+-        FD_SET(sock, &rfds);
+-        tv.tv_sec =3D 10;
+-        tv.tv_usec =3D 0;
+-        res =3D select(sock + 1, &rfds, NULL, NULL, &tv);
+-        if (res < 0) {
+-            error("select(sock) failed: %s", strerror(errno));
+-            break;
+-        } else if (res =3D=3D 0) {
+-            continue;
++        if (vtpm_rx_fh < 0) {
++            if (vtpm_type =3D=3D VTPM_TYPE_PVM)
++            {
++                vtpm_rx_fh =3D open(vtpm_rx_file, O_RDONLY);
++            } else {
++                if (bind(sockfd, (struct sockaddr *)&addr,
sizeof(addr)) < 0) {
++                    error("Unable to bind(). errno =3D %d\n", errno);
++                    exit (-1);
++                }
++
++                if (listen(sockfd, 10) <0) {
++                    error("Unable to listen(). errno =3D %d\n", errno);=

++                    exit (-1);
++                }
++
++                 memset(&client_addr, 0, sizeof(client_addr));
++                 client_length =3D sizeof(client_addr);
++
++                 vtpm_rx_fh =3D vtpm_tx_fh =3D accept(sockfd, (struct
sockaddr *)&client_addr, &client_length);
++            }
+         }
+-        addr_len =3D sizeof(addr);
+-        fh =3D accept(sock, (struct sockaddr*)&addr, &addr_len);
+-        if (fh < 0) {
+-            error("accept() failed: %s", strerror(errno));
+-            continue;
++
++        /*Error Checking*/
++        if (vtpm_rx_fh < 0) {
++          error("Failed to open devices to listen to guest.\n");
++          exit(-1);
+         }
++
+         /* receive and handle commands */
+         in_len =3D 0;
+         do {
+             debug("waiting for commands...");
+-            FD_ZERO(&rfds);
+-            FD_SET(fh, &rfds);
+-            tv.tv_sec =3D TPM_COMMAND_TIMEOUT;
+-            tv.tv_usec =3D 0;
+-            res =3D select(fh + 1, &rfds, NULL, NULL, &tv);
+-            if (res < 0) {
+-                error("select(fh) failed: %s", strerror(errno));
+-                close(fh);
+-                break;
+-            } else if (res =3D=3D 0) {
+-#ifdef TPMD_DISCONNECT_IDLE_CLIENTS
+-                info("connection closed due to inactivity");
+-                close(fh);
+-                break;
+-#else
+-                continue;
+-#endif
+-            }
+-            in_len =3D read(fh, in, sizeof(in));
+-            if (in_len > 0) {
++
++            in_len =3D read(vtpm_rx_fh, in, sizeof(in));
++            /*Magic size of minimum TPM command is 6*/
++            if (in_len < 6) {
++                info("Recv incomplete command of %d bytes.", in_len);
++                if (in_len <=3D 0) {
++                    close(vtpm_rx_fh);
++                    vtpm_rx_fh =3D -1;
++                    continue;
++                 }
++            } else {
++                /*Debug Printouts*/
+                 debug("received %d bytes", in_len);
++                debug_nostop("Recv[%d]: 0x", in_len);
++                for (i=3D0; i< in_len; i++)
++                    debug_more("%02x ", in[i]);
++                debug_more("\n");
++                /*Multiple Guest check*/
++                if (guest_id =3D=3D -1) {
++                    guest_id =3D *((int32_t *) in);
++                } else {
++                    if (guest_id !=3D *((int32_t *) in) ) {
++                        error("WARNING: More than one guest attached\n"=
);
++                    }
++                }
++
++                /*Open tx handle now*/
++                if (vtpm_tx_fh < 0) {
++                    if (vtpm_type =3D=3D VTPM_TYPE_PVM) {
++                        vtpm_tx_fh =3D open(PVM_TX_FIFO, O_WRONLY);
++                    } // No need to open the other direction for HVM
++                }
++                if (vtpm_tx_fh < 0) {
++                  error("Failed to open devices to respond to guest.\n"=
);
++                  exit(-1);
++                }
++
++                /*Handle the TPM command now*/
+                 out =3D NULL;
+-                res =3D tpm_handle_command(in, in_len, &out, &out_len);=

++                res =3D tpm_handle_command(in + sizeof(uint32_t), in_le=
n
- sizeof(uint32_t), &out, &out_len);
+                 if (res < 0) {
+                     error("tpm_handle_command() failed");
+                 } else {
+                     debug("sending %d bytes", out_len);
+-                    uint32_t len =3D 0;
+-                    while (len < out_len) {
+-                        res =3D write(fh, &out[len], out_len - len);
++            //Prepend the dmi_id
++                    addressed_out =3D (uint8_t *)
tpm_malloc(sizeof(uint32_t) + out_len);
++                    *(uint32_t *) addressed_out =3D *(uint32_t *) in;
++                    memcpy(addressed_out + sizeof(uint32_t), out,
out_len);
++                    out_len +=3D sizeof(uint32_t);
++                    /*End Prepend*/
++
++                    /*Perform write operation now*/
++                    while (out_len > 0) {
++                        res =3D write(vtpm_tx_fh, addressed_out, out_le=
n);
++
+                         if (res < 0) {
+-                            error("write(%d) failed: %s",
+-                                  out_len - len, strerror(errno));
++                            error("write(%d) failed: %s", out_len,
strerror(errno));
+                             break;
++                        } else {
++                          debug_nostop("Sent[%Zu]: ", out_len);
++                          for (i=3D0; (unsigned int)i< out_len; i++)
++                            debug_more("%02x ", addressed_out[i]);
++                          debug_more("\n");
+                         }
+-                        len +=3D res;
++                        out_len -=3D res;
+                     }
+                     tpm_free(out);
++                    tpm_free(addressed_out);
+                 }
+             }
+         } while (in_len > 0);
+-        close(fh);
+     }
++
+     /* shutdown tpm emulator */
+     tpm_emulator_shutdown();
+-    /* close socket */
+-    close(sock);
+-    unlink(opt_socket_name);
++    /* Close handles */
++    close(vtpm_tx_fh);
++    close(vtpm_rx_fh);
++    free(vtpm_rx_file);
+     info("main loop stopped");
+ }
+
+ int main(int argc, char **argv)
+ {
++    //Set load/store functions
++    tpm_write_to_storage =3D vtpm_write_to_file;
++    tpm_read_from_storage =3D vtpm_read_from_file;
++
+     openlog(argv[0], 0, LOG_DAEMON);
+     setlogmask(~LOG_MASK(LOG_DEBUG));
+     syslog(LOG_INFO, "--- separator ---\n");
+@@ -393,8 +602,6 @@
+     switch_uid_gid();
+     /* init signal handlers */
+     init_signal_handler();
+-    /* unless requested otherwiese, fork and daemonize process */
+-    if (!opt_foreground) daemonize();
+     /* start main processing loop */
+     main_loop();
+     info("stopping TPM Emulator daemon");
+diff -Naur tpm_emulator-0.7.4-orig/tpmd/unix/tpmd.c.orig
tpm_emulator-0.7.4/tpmd/unix/tpmd.c.orig
+--- tpm_emulator-0.7.4-orig/tpmd/unix/tpmd.c.orig    1969-12-31
19:00:00.000000000 -0500
++++ tpm_emulator-0.7.4/tpmd/unix/tpmd.c.orig    2011-12-20
13:30:06.000000000 -0500
+@@ -0,0 +1,403 @@
++/* Software-based Trusted Platform Module (TPM) Emulator
++ * Copyright (C) 2004-2010 Mario Strasser <mast@gmx.net>
++ *
++ * 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.
++ *
++ * $Id: tpmd.c 463 2011-06-08 14:25:04Z mast $
++ */
++
++#include <stdio.h>
++#include <stdlib.h>
++#include <unistd.h>
++#include <signal.h>
++#include <string.h>
++#include <errno.h>
++#include <syslog.h>
++#include <stdarg.h>
++#include <fcntl.h>
++#include <sys/stat.h>
++#include <sys/socket.h>
++#include <sys/un.h>
++#include <pwd.h>
++#include <grp.h>
++#include "config.h"
++#include "tpm/tpm_emulator.h"
++
++#define TPM_COMMAND_TIMEOUT 30
++
++static volatile int stopflag =3D 0;
++static int is_daemon =3D 0;
++static int opt_debug =3D 0;
++static int opt_foreground =3D 0;
++static const char *opt_socket_name =3D TPM_SOCKET_NAME;
++static uid_t opt_uid =3D 0;
++static gid_t opt_gid =3D 0;
++static int tpm_startup =3D 2;
++static uint32_t tpm_config =3D 0;
++extern const char *tpm_storage_file;
++
++void my_log(int priority, const char *fmt, ...)
++{
++    va_list ap, bp;
++    va_start(ap, fmt);
++    va_copy(bp, ap);
++    switch (priority) {
++      case TPM_LOG_DEBUG:
++        vsyslog(LOG_DEBUG, fmt, ap);
++        break;
++      case TPM_LOG_ERROR:
++        vsyslog(LOG_ERR, fmt, ap);
++        break;
++      case TPM_LOG_INFO:
++      default:
++        vsyslog(LOG_INFO, fmt, ap);
++        break;
++    }
++    va_end(ap);
++    if (!is_daemon && (priority !=3D TPM_LOG_DEBUG || opt_debug)) {
++        vprintf(fmt, bp);
++    }
++    va_end(bp);
++}
++
++static void print_usage(char *name)
++{
++    printf("usage: %s [-d] [-f] [-s storage file] [-u unix socket name]=
 "
++           "[-o user name] [-g group name] [-h] [startup mode]\n", name=
);
++    printf("  d : enable debug mode\n");
++    printf("  f : forces the application to run in the foreground\n");
++    printf("  s : storage file to use (default: %s)\n", tpm_storage_fil=
e);
++    printf("  u : unix socket name to use (default: %s)\n",
opt_socket_name);
++    printf("  o : effective user the application should run as\n");
++    printf("  g : effective group the application should run as\n");
++    printf("  h : print this help message\n");
++    printf("  startup mode : must be 'clear', "
++           "'save' (default) or 'deactivated\n");
++}
++
++static void parse_options(int argc, char **argv)
++{
++    char c;
++    struct passwd *pwd;
++    struct group *grp;
++    opt_uid =3D getuid();
++    opt_gid =3D getgid();
++    info("parsing options");
++    while ((c =3D getopt (argc, argv, "dfs:u:o:g:c:h")) !=3D -1) {
++        debug("handling option '-%c'", c);
++        switch (c) {
++            case 'd':
++                opt_debug =3D 1;
++                setlogmask(setlogmask(0) | LOG_MASK(LOG_DEBUG));
++                debug("debug mode enabled");
++                break;
++            case 'f':
++                debug("application is forced to run in foreground");
++                opt_foreground =3D 1;
++                break;
++            case 's':
++                tpm_storage_file =3D optarg;
++                debug("using storage file '%s'", tpm_storage_file);
++                break;
++            case 'u':
++                opt_socket_name =3D optarg;
++                debug("using unix socket '%s'", opt_socket_name);
++                break;
++            case 'o':
++                pwd  =3D getpwnam(optarg);
++                if (pwd =3D=3D NULL) {
++                    error("invalid user name '%s'\n", optarg);
++                    exit(EXIT_FAILURE);
++                }
++                opt_uid =3D pwd->pw_uid;
++                break;
++            case 'g':
++                grp  =3D getgrnam(optarg);
++                if (grp =3D=3D NULL) {
++                    error("invalid group name '%s'\n", optarg);
++                    exit(EXIT_FAILURE);
++                }
++                opt_gid =3D grp->gr_gid;
++                break;
++            case 'c':
++                tpm_config =3D strtol(optarg, NULL, 0);
++                debug("tpm_config =3D %04x", tpm_config);
++                break;
++            case '?':
++                error("unknown option '-%c'", optopt);
++                print_usage(argv[0]);
++                exit(EXIT_FAILURE);
++            case 'h':
++            default:
++                print_usage(argv[0]);
++                exit(EXIT_SUCCESS);
++        }
++    }
++    if (optind < argc) {
++        debug("startup mode =3D '%s'", argv[optind]);
++        if (!strcmp(argv[optind], "clear")) {
++            tpm_startup =3D 1;
++        } else if (!strcmp(argv[optind], "save")) {
++            tpm_startup =3D 2;
++        } else if (!strcmp(argv[optind], "deactivated")) {
++            tpm_startup =3D 3;
++        } else {
++            error("invalid startup mode '%s'; must be 'clear', "
++                  "'save' (default) or 'deactivated", argv[optind]);
++            print_usage(argv[0]);
++            exit(EXIT_SUCCESS);
++        }
++    } else {
++        /* if no startup mode is given assume save if a configuration
++           file is available, clear otherwise */
++        int fh =3D open(tpm_storage_file, O_RDONLY);
++        if (fh < 0) {
++            tpm_startup =3D 1;
++            info("no startup mode was specified; asuming 'clear'");
++        } else {
++            tpm_startup =3D 2;
++            close(fh);
++        }
++    }
++}
++
++static void switch_uid_gid(void)
++{
++    if (opt_gid !=3D getgid()) {
++        info("switching effective group ID to %d", opt_gid);
++        if (setgid(opt_gid) =3D=3D -1) {
++            error("switching effective group ID to %d failed: %s",
opt_gid, strerror(errno));
++            exit(EXIT_FAILURE);
++        }
++    }
++    if (opt_uid !=3D getuid()) {
++        info("switching effective user ID to %d", opt_uid);
++        if (setuid(opt_uid) =3D=3D -1) {
++            error("switching effective user ID to %d failed: %s",
opt_uid, strerror(errno));
++            exit(EXIT_FAILURE);
++        }
++    }
++}
++
++static void signal_handler(int sig)
++{
++    info("signal received: %d", sig);
++    if (sig =3D=3D SIGTERM || sig =3D=3D SIGQUIT || sig =3D=3D SIGINT) =
stopflag =3D 1;
++}
++
++static void init_signal_handler(void)
++{
++    info("installing signal handlers");
++    if (signal(SIGTERM, signal_handler) =3D=3D SIG_ERR) {
++        error("signal(SIGTERM) failed: %s", strerror(errno));
++        exit(EXIT_FAILURE);
++    }
++    if (signal(SIGQUIT, signal_handler) =3D=3D SIG_ERR) {
++        error("signal(SIGQUIT) failed: %s", strerror(errno));
++        exit(EXIT_FAILURE);
++    }
++    if (signal(SIGINT, signal_handler) =3D=3D SIG_ERR) {
++        error("signal(SIGINT) failed: %s", strerror(errno));
++        exit(EXIT_FAILURE);
++    }
++    if (signal(SIGPIPE, signal_handler) =3D=3D SIG_ERR) {
++        error("signal(SIGPIPE) failed: %s", strerror(errno));
++        exit(EXIT_FAILURE);
++    }
++}
++
++static void daemonize(void)
++{
++    pid_t sid, pid;
++    info("daemonizing process");
++    pid =3D fork();
++    if (pid < 0) {
++        error("fork() failed: %s", strerror(errno));
++        exit(EXIT_FAILURE);
++    }
++    if (pid > 0) exit(EXIT_SUCCESS);
++    pid =3D getpid();
++    sid =3D setsid();
++    if (sid < 0) {
++        error("setsid() failed: %s", strerror(errno));
++        exit(EXIT_FAILURE);
++    }
++    if (chdir("/") < 0) {
++        error("chdir() failed: %s", strerror(errno));
++        exit(EXIT_FAILURE);
++    }
++    close(STDIN_FILENO);
++    close(STDOUT_FILENO);
++    close(STDERR_FILENO);
++    is_daemon =3D 1;
++    info("process was successfully daemonized: pid=3D%d sid=3D%d", pid,=
 sid);
++}
++
++static int mkdirs(const char *path)
++{
++    char *copy =3D strdup(path);
++    char *p =3D strchr(copy + 1, '/');
++    while (p !=3D NULL) {
++        *p =3D '\0';
++        if ((mkdir(copy, 0755) =3D=3D -1) && (errno !=3D EEXIST)) {
++            free(copy);
++            return errno;
++        }
++        *p =3D '/';
++        p =3D strchr(p + 1, '/');
++    }
++    free(copy);
++    return 0;
++}
++
++static int init_socket(const char *name)
++{
++    int sock;
++    struct sockaddr_un addr;
++    info("initializing socket %s", name);
++    sock =3D socket(AF_UNIX, SOCK_STREAM, 0);
++    if (sock < 0) {
++        error("socket(AF_UNIX) failed: %s", strerror(errno));
++        return -1;
++    }
++    mkdirs(name);
++    addr.sun_family =3D AF_UNIX;
++    strncpy(addr.sun_path, name, sizeof(addr.sun_path));
++    umask(0177);
++    if (bind(sock, (struct sockaddr*)&addr, sizeof(addr)) < 0) {
++        error("bind(%s) failed: %s", addr.sun_path, strerror(errno));
++        close(sock);
++        return -1;
++    }
++    listen(sock, 1);
++    return sock;
++}
++
++static void main_loop(void)
++{
++    int sock, fh, res;
++    int32_t in_len;
++    uint32_t out_len;
++    uint8_t in[TPM_CMD_BUF_SIZE], *out;
++    struct sockaddr_un addr;
++    socklen_t addr_len;
++    fd_set rfds;
++    struct timeval tv;
++
++    info("staring main loop");
++    /* open UNIX socket */
++    sock =3D init_socket(opt_socket_name);
++    if (sock < 0) exit(EXIT_FAILURE);
++    /* init tpm emulator */
++    debug("initializing TPM emulator");
++    if (tpm_emulator_init(tpm_startup, tpm_config) !=3D 0) {
++        error("tpm_emulator_init() failed");
++        close(sock);
++        unlink(opt_socket_name);
++        exit(EXIT_FAILURE);
++    }
++    /* start command processing */
++    while (!stopflag) {
++        /* wait for incomming connections */
++        debug("waiting for connections...");
++        FD_ZERO(&rfds);
++        FD_SET(sock, &rfds);
++        tv.tv_sec =3D 10;
++        tv.tv_usec =3D 0;
++        res =3D select(sock + 1, &rfds, NULL, NULL, &tv);
++        if (res < 0) {
++            error("select(sock) failed: %s", strerror(errno));
++            break;
++        } else if (res =3D=3D 0) {
++            continue;
++        }
++        addr_len =3D sizeof(addr);
++        fh =3D accept(sock, (struct sockaddr*)&addr, &addr_len);
++        if (fh < 0) {
++            error("accept() failed: %s", strerror(errno));
++            continue;
++        }
++        /* receive and handle commands */
++        in_len =3D 0;
++        do {
++            debug("waiting for commands...");
++            FD_ZERO(&rfds);
++            FD_SET(fh, &rfds);
++            tv.tv_sec =3D TPM_COMMAND_TIMEOUT;
++            tv.tv_usec =3D 0;
++            res =3D select(fh + 1, &rfds, NULL, NULL, &tv);
++            if (res < 0) {
++                error("select(fh) failed: %s", strerror(errno));
++                close(fh);
++                break;
++            } else if (res =3D=3D 0) {
++#ifdef TPMD_DISCONNECT_IDLE_CLIENTS
++                info("connection closed due to inactivity");
++                close(fh);
++                break;
++#else
++                continue;
++#endif
++            }
++            in_len =3D read(fh, in, sizeof(in));
++            if (in_len > 0) {
++                debug("received %d bytes", in_len);
++                out =3D NULL;
++                res =3D tpm_handle_command(in, in_len, &out, &out_len);=

++                if (res < 0) {
++                    error("tpm_handle_command() failed");
++                } else {
++                    debug("sending %d bytes", out_len);
++                    uint32_t len =3D 0;
++                    while (len < out_len) {
++                        res =3D write(fh, &out[len], out_len - len);
++                        if (res < 0) {
++                            error("write(%d) failed: %s",
++                                  out_len - len, strerror(errno));
++                            break;
++                        }
++                        len +=3D res;
++                    }
++                    tpm_free(out);
++                }
++            }
++        } while (in_len > 0);
++        close(fh);
++    }
++    /* shutdown tpm emulator */
++    tpm_emulator_shutdown();
++    /* close socket */
++    close(sock);
++    unlink(opt_socket_name);
++    info("main loop stopped");
++}
++
++int main(int argc, char **argv)
++{
++    openlog(argv[0], 0, LOG_DAEMON);
++    setlogmask(~LOG_MASK(LOG_DEBUG));
++    syslog(LOG_INFO, "--- separator ---\n");
++    tpm_log =3D my_log;
++    info("starting TPM Emulator daemon (1.2.%d.%d-%d)",
++         VERSION_MAJOR, VERSION_MINOR, VERSION_BUILD);
++    parse_options(argc, argv);
++    /* switch uid/gid if required */
++    switch_uid_gid();
++    /* init signal handlers */
++    init_signal_handler();
++    /* unless requested otherwiese, fork and daemonize process */
++    if (!opt_foreground) daemonize();
++    /* start main processing loop */
++    main_loop();
++    info("stopping TPM Emulator daemon");
++    closelog();
++    return EXIT_SUCCESS;
++}
diff --git a/tools/vtpm/vtpm.patch b/tools/vtpm/vtpm.patch
--- a/tools/vtpm/vtpm.patch
+++ /dev/null
@@ -1,716 +0,0 @@
-diff -uprN tpm_emulator/AUTHORS vtpm/AUTHORS
---- tpm_emulator/AUTHORS    2006-12-08 12:51:29.000000000 -0800
-+++ vtpm/AUTHORS    2006-12-13 16:38:52.000000000 -0800
-@@ -1,3 +1,3 @@
- Mario Strasser <mast@gmx.net>
- Heiko Stamer <stamer@gaos.org> [DAA]
--INTEL Corp <> [Dropped to Ring3]
-+INTEL Corp <> [VTPM Extensions]
-diff -uprN tpm_emulator/ChangeLog vtpm/ChangeLog
---- tpm_emulator/ChangeLog    2006-12-08 12:51:29.000000000 -0800
-+++ vtpm/ChangeLog    2006-12-13 16:38:52.000000000 -0800
-@@ -1,5 +1,6 @@
- ????-??-?? Intel Corp
-     * Moved module out of kernel to run as a ring 3 app
-+    * Modified save_to_file and load_from_file to call xen VTPM manager=

-
- 2006-06-23  Mario Strasser <mast@gmx.net>
-     * tpm_startup.c: behaviour of ST_CLEAR and storage of
-diff -uprN tpm_emulator/linux_module.h vtpm/linux_module.h
---- tpm_emulator/linux_module.h    2006-12-08 12:51:29.000000000 -0800
-+++ vtpm/linux_module.h    2007-01-09 14:49:06.000000000 -0800
-@@ -44,18 +44,26 @@
- #define TPM_DEVICE_NAME   "tpm"
- #define TPM_MODULE_NAME   "tpm_emulator"
-
-+/* debug and log output functions */
-+extern int dmi_id;
-+
- #ifdef DEBUG
--#define debug(fmt, ...) printf("TPMD: %s:%d: Debug: " fmt "\n", \
--                        __FILE__, __LINE__, ## __VA_ARGS__)
-+#define debug(fmt, ...) printf("TPMD[%d]: %s:%d: Debug: " fmt "\n", \
-+                        dmi_id, __FILE__, __LINE__, ## __VA_ARGS__)
-+#define debug_nostop(fmt, ...) printf("TPMD[%d]: %s:%d: Debug: " fmt, \=

-+                        dmi_id, __FILE__, __LINE__, ## __VA_ARGS__)
-+#define debug_more(fmt, ...) printf( fmt, ## __VA_ARGS__ )
- #else
- #define debug(fmt, ...)
-+#define debug_nostop(fmt, ...)
-+#define debug_more(fmt, ...)
- #endif
--#define info(fmt, ...)  printf("TPMD: %s:%d: Info: " fmt "\n", \
--                        __FILE__, __LINE__, ## __VA_ARGS__)
--#define error(fmt, ...) printf("TPMD: %s:%d: Error: " fmt "\n", \
--                        __FILE__, __LINE__, ## __VA_ARGS__)
--#define alert(fmt, ...) printf("TPMD: %s:%d: Alert: " fmt "\n", \
--                        __FILE__, __LINE__, ## __VA_ARGS__)
-+#define info(fmt, ...)  printf("TPMD[%d]: %s:%d: Info: " fmt "\n", \
-+                        dmi_id, __FILE__, __LINE__, ## __VA_ARGS__)
-+#define error(fmt, ...) printf("TPMD[%d]: %s:%d: Error: " fmt "\n", \
-+                        dmi_id, __FILE__, __LINE__, ## __VA_ARGS__)
-+#define alert(fmt, ...) printf("TPMD[%d]: %s:%d: Alert: " fmt "\n", \
-+                        dmi_id, __FILE__, __LINE__, ## __VA_ARGS__)
-
- /* memory allocation */
-
-diff -uprN tpm_emulator/Makefile vtpm/Makefile
---- tpm_emulator/Makefile    2006-12-08 12:51:29.000000000 -0800
-+++ vtpm/Makefile    2006-12-13 16:38:52.000000000 -0800
-@@ -7,7 +7,7 @@
- COMPILE_ARCH    ?=3D $(shell uname -m | sed -e s/i.86/x86_32/)
-
- # module settings
--BIN            :=3D tpm_emulator
-+BIN            :=3D vtpmd
- VERSION_MAJOR  :=3D 0
- VERSION_MINOR  :=3D 4
- VERSION_BUILD  :=3D $(shell date +"%s")
-@@ -22,7 +22,7 @@ TOOLS_INSTALL_DIR =3D $(DESTDIR)/usr/bin
-
- CC      :=3D gcc
- CFLAGS  +=3D -g -Wall $(INCLUDE) -DDEBUG
--CFLAGS  +=3D -I. -Itpm
-+CFLAGS  +=3D -I. -Itpm -I../../vtpm_manager/manager
-
- # Is the simulator running in it's own vm?
- #CFLAGS +=3D -DVTPM_MULTI_VM
-@@ -62,7 +62,6 @@ $(BIN):    $(src)/crypto/gmp.h $(src)/crypt
-
- install: $(BIN)
-     $(INSTALL_PROG) $(BIN) $(TOOLS_INSTALL_DIR)
--    @if [ ! -d "/var/tpm" ]; then mkdir /var/tpm; fi
-
- clean:
-     rm -f $(src)/crypto/gmp.h $(src)/crypto/libgmp.a $(OBJS)
-@@ -98,3 +97,4 @@ version:
-     @echo "#endif /* _TPM_VERSION_H_ */" >> $(src)/tpm_version.h
-
- .PHONY: all install clean dist gmp version
-+
-diff -uprN tpm_emulator/tpm/tpm_capability.c vtpm/tpm/tpm_capability.c
---- tpm_emulator/tpm/tpm_capability.c    2006-06-23 03:37:07.000000000
-0700
-+++ vtpm/tpm/tpm_capability.c    2007-01-10 10:00:49.000000000 -0800
-@@ -136,8 +136,18 @@ static TPM_RESULT cap_property(UINT32 su
-
-     case TPM_CAP_PROP_TIS_TIMEOUT:
-       debug("[TPM_CAP_PROP_TIS_TIMEOUT]");
--      /* TODO: TPM_CAP_PROP_TIS_TIMEOUT */
--      return TPM_FAIL;
-+      /* TODO: TPM_CAP_PROP_TIS_TIMEOUT: Measure these values and
determine correct ones */
-+      UINT32 len =3D *respSize =3D 16;
-+      BYTE *ptr =3D *resp =3D tpm_malloc(*respSize);
-+      if (ptr =3D=3D NULL ||
-+          tpm_marshal_UINT32(&ptr, &len, 200000) ||
-+          tpm_marshal_UINT32(&ptr, &len, 200000) ||
-+          tpm_marshal_UINT32(&ptr, &len, 200000) ||
-+          tpm_marshal_UINT32(&ptr, &len, 200000)) {
-+        tpm_free(*resp);
-+        return TPM_FAIL;
-+      }
-+      return TPM_SUCCESS;
-
-     case TPM_CAP_PROP_STARTUP_EFFECT:
-       debug("[TPM_CAP_PROP_STARTUP_EFFECT]");
-@@ -190,7 +200,11 @@ static TPM_RESULT cap_property(UINT32 su
-
-     case TPM_CAP_PROP_DURATION:
-       debug("[TPM_CAP_PROP_DURATION]");
--      /* TODO: TPM_CAP_PROP_DURATION */
-+      /* TODO: TPM_CAP_PROP_DURATION: Measure these values and return
accurate ones */
-+      BYTE dur[]=3D
{0x0,0x0,0x0,0xc,0x0,0x7,0xa1,0x20,0x0,0x1e,0x84,0x80,0x11,0xe1,0xa3,0x0}=
;
-+      *respSize =3D 16;
-+      *resp =3D tpm_malloc(*respSize);
-+      memcpy(*resp,dur,16);
-       return TPM_FAIL;
-
-     case TPM_CAP_PROP_ACTIVE_COUNTER:
-diff -uprN tpm_emulator/tpm/tpm_cmd_handler.c vtpm/tpm/tpm_cmd_handler.c=

---- tpm_emulator/tpm/tpm_cmd_handler.c    2008-02-27 16:35:41.000000000
-0500
-+++ vtpm/tpm/tpm_cmd_handler.c    2008-02-28 14:43:28.000000000 -0500
-@@ -94,12 +94,18 @@ void tpm_compute_out_param_digest(TPM_CO
-   sha1_ctx_t sha1;
-   UINT32 res =3D CPU_TO_BE32(rsp->result);
-   UINT32 ord =3D CPU_TO_BE32(ordinal);
-+  UINT32 offset =3D 0;
-
-   /* compute SHA1 hash */
-   sha1_init(&sha1);
-   sha1_update(&sha1, (BYTE*)&res, 4);
-   sha1_update(&sha1, (BYTE*)&ord, 4);
--  sha1_update(&sha1, rsp->param, rsp->paramSize);
-+  if (ordinal =3D=3D TPM_ORD_LoadKey2) {
-+      offset =3D 4;
-+  }
-+  if (rsp->paramSize - offset > 0) {
-+      sha1_update(&sha1, rsp->param + offset, rsp->paramSize - offset);=

-+  }
-   sha1_final(&sha1, rsp->auth1->digest);
-   if (rsp->auth2 !=3D NULL) memcpy(rsp->auth2->digest,
-     rsp->auth1->digest, sizeof(rsp->auth1->digest));
-diff -uprN tpm_emulator/tpm/tpm_data.c vtpm/tpm/tpm_data.c
---- tpm_emulator/tpm/tpm_data.c    2008-02-27 16:35:41.000000000 -0500
-+++ vtpm/tpm/tpm_data.c    2008-02-27 16:35:40.000000000 -0500
-@@ -1,6 +1,7 @@
- /* Software-Based Trusted Platform Module (TPM) Emulator for Linux
-  * Copyright (C) 2004 Mario Strasser <mast@gmx.net>,
-  *                    Swiss Federal Institute of Technology (ETH) Zuric=
h
-+ * Copyright (C) 2005 INTEL Corp
-  *
-  * This module is free software; you can redistribute it and/or modify
-  * it under the terms of the GNU General Public License as published
-@@ -15,10 +16,15 @@
-  * $Id: tpm_data.c 98 2006-05-07 14:16:29Z hstamer $
-  */
-
-+#include <sys/types.h>
-+#include <sys/stat.h>
-+#include <fcntl.h>
-+#include <unistd.h>
-+
- #include "tpm_emulator.h"
- #include "tpm_structures.h"
- #include "tpm_marshalling.h"
--#include "linux_module.h"
-+#include "vtpm_manager.h"
-
- TPM_DATA tpmData;
-
-@@ -158,45 +164,232 @@ void tpm_release_data(void)
- #include <sys/types.h>
- #include <sys/stat.h>
- #include <fcntl.h>
--#include <unistd.h>
-
--#define TPM_STORAGE_FILE "/var/tpm/tpm_emulator-1.2."
STR(VERSION_MAJOR) "." STR(VERSION_MINOR)
-+ static int vtpm_tx_fh=3D-1, vtpm_rx_fh=3D-1;
-+
-+#ifdef VTPM_MUTLI_VM
-+ #define DEV_FE "/dev/tpm"
-+#else
-+ #define VTPM_RX_FIFO_D  "/var/vtpm/fifos/vtpm_rsp_to_%d.fifo"
-+ #define VTPM_TX_FIFO  "/var/vtpm/fifos/vtpm_cmd_from_all.fifo"
-+
-+ extern int dmi_id;
-+ static char *vtpm_rx_name=3DNULL;
-+#endif
-
- static int write_to_file(uint8_t *data, size_t data_length)
- {
--  int res;
--  int fp;
--  fp =3D open(TPM_STORAGE_FILE, O_WRONLY | O_TRUNC | O_CREAT, S_IRUSR |=

S_IWUSR);
--  res =3D write(fp, data, data_length);
--  close(fp);
--  return (res =3D=3D data_length) ? 0 : -1;
-+  int res, out_data_size, in_header_size;
-+  BYTE *ptr, *out_data, *in_header;
-+  UINT32 result, len, in_rsp_size;
-+  UINT16 tag =3D VTPM_TAG_REQ;
-+  =20
-+  printf("Saving NVM\n");
-+  if (vtpm_tx_fh < 0) {
-+#ifdef VTPM_MUTLI_VM
-+    vtpm_tx_fh =3D open(DEV_FE, O_RDWR);
-+#else
-+    vtpm_tx_fh =3D open(VTPM_TX_FIFO, O_WRONLY);
-+#endif
-+  }
-+
-+  if (vtpm_tx_fh < 0) {
-+        return -1;
-+  }
-+
-+  // Send request to VTPM Manager to encrypt data
-+#ifdef VTPM_MUTLI_VM
-+  out_data_size =3D len =3D VTPM_COMMAND_HEADER_SIZE_CLT + data_length;=

-+#else
-+  out_data_size =3D len =3D VTPM_COMMAND_HEADER_SIZE_SRV + data_length;=

-+#endif
-+=20
-+  out_data =3D ptr =3D (BYTE *) malloc(len);
-+
-+  if (ptr =3D=3D NULL
-+#ifndef VTPM_MUTLI_VM
-+      || tpm_marshal_UINT32(&ptr, &len, dmi_id)
-+#endif
-+      || tpm_marshal_UINT16(&ptr, &len, tag)
-+#ifdef VTPM_MUTLI_VM
-+      || tpm_marshal_UINT32(&ptr, &len, out_data_size)
-+#else
-+      || tpm_marshal_UINT32(&ptr, &len, out_data_size - sizeof(uint32_t=
))
-+#endif=20
-+      || tpm_marshal_UINT32(&ptr, &len, VTPM_ORD_SAVENVM)
-+      || tpm_marshal_BYTE_ARRAY(&ptr, &len, data, data_length)) {
-+    free(out_data);
-+    return -1;
-+  }
-+=20
-+  printf("\tSending SaveNVM Command.\n");
-+  res =3D write(vtpm_tx_fh, out_data, out_data_size);
-+  free(out_data);
-+  if (res !=3D out_data_size) return -1;
-+
-+  if (vtpm_rx_fh < 0) {
-+#ifdef VTPM_MUTLI_VM
-+    vtpm_rx_fh =3D vtpm_tx_fh
-+#else
-+    if (vtpm_rx_name =3D=3D NULL) {
-+      vtpm_rx_name =3D malloc(10 + strlen(VTPM_RX_FIFO_D));
-+      sprintf(vtpm_rx_name, VTPM_RX_FIFO_D, (uint32_t) dmi_id);
-+    }
-+    vtpm_rx_fh =3D open(vtpm_rx_name, O_RDONLY);
-+#endif
-+  }
-+
-+  if (vtpm_rx_fh < 0) {
-+        return -1;
-+  }
-+=20
-+  // Read Header of response so we can get the size & status
-+#ifdef VTPM_MUTLI_VM
-+  in_header_size =3D len =3D VTPM_COMMAND_HEADER_SIZE_CLT;
-+#else
-+  in_header_size =3D len =3D VTPM_COMMAND_HEADER_SIZE_SRV;
-+#endif
-+  in_header =3D ptr =3D malloc(in_header_size);
-+=20
-+  printf("\tReading SaveNVM header.\n");
-+  res =3D read(vtpm_rx_fh, in_header, in_header_size);
-+
-+  if ( (res !=3D in_header_size)
-+#ifndef VTPM_MUTLI_VM
-+       || tpm_unmarshal_UINT32(&ptr, &len, (UINT32*)&dmi_id)
-+#endif
-+       || tpm_unmarshal_UINT16(&ptr, &len, &tag)
-+       || tpm_unmarshal_UINT32(&ptr, &len, &in_rsp_size)
-+       || tpm_unmarshal_UINT32(&ptr, &len, &result) ) {
-+      free(in_header);
-+      return -1;
-+  }
-+  free(in_header);
-+=20
-+  if (result !=3D VTPM_SUCCESS) {
-+      return -1;=20
-+  }
-+
-+#ifdef VTPM_MUTLI_VM
-+  close(vtpm_tx_fh); close(vtpm_rx_fh);
-+#endif
-+    =20
-+  printf("\tFinishing up SaveNVM\n");
-+  return (0);
- }
-
- static int read_from_file(uint8_t **data, size_t *data_length)
- {
--  int res;
--  int fp, file_status;
--  struct stat file_info;
--  fp =3D open(TPM_STORAGE_FILE, O_RDONLY, 0);
--  file_status =3D fstat(fp, &file_info);
--  if (file_status < 0) {
--    close(fp);
--    return -1;
--  }
-+  int res, out_data_size, in_header_size;
-+  uint8_t *ptr, *out_data, *in_header;
-+  UINT16 tag =3D VTPM_TAG_REQ;
-+  UINT32 len, in_rsp_size, result;
-+#ifdef VTPM_MUTLI_VM
-+    int vtpm_rx_fh, vtpm_tx_fh;
-+#endif
-+  =20
-+  printf("Loading NVM.\n");
-+  if (vtpm_tx_fh < 0) {
-+#ifdef VTPM_MUTLI_VM
-+    vtpm_tx_fh =3D open(DEV_FE, O_RDWR);
-+#else
-+    vtpm_tx_fh =3D open(VTPM_TX_FIFO, O_WRONLY);
-+#endif
-+  }
-
--  *data_length =3D file_info.st_size;
--  *data =3D tpm_malloc(*data_length);
--  if (*data =3D=3D NULL) {
--    close(fp);
-+  if (vtpm_tx_fh < 0) {
-+        return -1;
-+  }
-+
-+  // Send request to VTPM Manager to encrypt data
-+#ifdef VTPM_MUTLI_VM
-+  out_data_size =3D len =3D VTPM_COMMAND_HEADER_SIZE_CLT;
-+#else
-+  out_data_size =3D len =3D VTPM_COMMAND_HEADER_SIZE_SRV;
-+#endif
-+  out_data =3D ptr =3D (BYTE *) malloc(len);
-+
-+  if (ptr =3D=3D NULL
-+#ifndef VTPM_MUTLI_VM
-+      || tpm_marshal_UINT32(&ptr, &len, dmi_id)
-+#endif=20
-+      || tpm_marshal_UINT16(&ptr, &len, tag)
-+#ifdef VTPM_MUTLI_VM
-+      || tpm_marshal_UINT32(&ptr, &len, out_data_size)
-+#else
-+      || tpm_marshal_UINT32(&ptr, &len, out_data_size - sizeof(uint32_t=
))
-+#endif
-+      || tpm_marshal_UINT32(&ptr, &len, VTPM_ORD_LOADNVM)) {
-+    free(out_data);
-     return -1;
-   }
--  res =3D read(fp, *data, *data_length);
--  close(fp);
-+
-+  printf("\tSending LoadNVM command\n");
-+  res =3D write(vtpm_tx_fh, out_data, out_data_size);
-+  free(out_data);
-+  if (res !=3D out_data_size) return -1;
-+
-+    if (vtpm_rx_fh < 0) {
-+#ifdef VTPM_MUTLI_VM
-+    vtpm_rx_fh =3D vtpm_tx_fh;
-+#else
-+    if (vtpm_rx_name =3D=3D NULL) {
-+      vtpm_rx_name =3D malloc(10 + strlen(VTPM_RX_FIFO_D));
-+      sprintf(vtpm_rx_name, VTPM_RX_FIFO_D, (uint32_t) dmi_id);
-+    }
-+    vtpm_rx_fh =3D open(vtpm_rx_name, O_RDONLY);
-+#endif
-+  }
-+
-+  if (vtpm_rx_fh < 0) {
-+        return -1;
-+  }
-+=20
-+  // Read Header of response so we can get the size & status
-+#ifdef VTPM_MUTLI_VM
-+  in_header_size =3D len =3D VTPM_COMMAND_HEADER_SIZE_CLT;
-+#else
-+  in_header_size =3D len =3D VTPM_COMMAND_HEADER_SIZE_SRV;
-+#endif
-+  in_header =3D ptr =3D malloc(in_header_size);
-+=20
-+  printf("\tReading LoadNVM header\n");
-+  res =3D read(vtpm_rx_fh, in_header, in_header_size);
-+
-+  if ( (res !=3D in_header_size)
-+#ifndef VTPM_MUTLI_VM
-+       || tpm_unmarshal_UINT32(&ptr, &len, (UINT32*)&dmi_id)
-+#endif
-+       || tpm_unmarshal_UINT16(&ptr, &len, &tag)
-+       || tpm_unmarshal_UINT32(&ptr, &len, &in_rsp_size)
-+       || tpm_unmarshal_UINT32(&ptr, &len, &result) ) {
-+      free(in_header);
-+      return -1;
-+  }
-+  free(in_header);
-+=20
-+  if (result !=3D VTPM_SUCCESS) {
-+      return -1;=20
-+  }
-+
-+  // Read Encrypted data from VTPM Manager
-+  *data_length =3D in_rsp_size - VTPM_COMMAND_HEADER_SIZE_CLT;
-+  *data =3D (uint8_t *) malloc(*data_length);
-+
-+  printf("\tReading clear data from LoadNVM.\n");
-+  res =3D read(vtpm_rx_fh, *data, *data_length);
-+#ifdef VTPM_MUTLI_VM
-+  close(vtpm_rx_fh);close(vtpm_tx_fh);
-+#endif
-+  =20
-+  printf("\tReturing from loading NVM\n");
-   if (res !=3D *data_length) {
--    tpm_free(*data);
--    return -1;
-+      free(*data);
-+      return -1;
-+  } else {
-+      return 0;
-   }
--  return 0;
-+
- }
-
- #else
-diff -uprN tpm_emulator/tpmd.c vtpm/tpmd.c
---- tpm_emulator/tpmd.c    2006-12-08 12:51:29.000000000 -0800
-+++ vtpm/tpmd.c    2007-01-09 14:48:56.000000000 -0800
-@@ -21,12 +21,24 @@
- #include <sys/stat.h>
- #include <fcntl.h>
- #include <sys/time.h>
-+#include <sys/socket.h>
-+#include <sys/un.h>
-+#include <errno.h>
-
- #include "tpm_emulator.h"
-+#include "vtpm_manager.h"
-
--#define TPM_RX_FNAME "/var/tpm/tpm_in.fifo"
--#define TPM_TX_FNAME "/var/tpm/tpm_out.fifo"
-+#ifdef VTPM_MULTI_VM
-+ #define DEV_BE "/dev/vtpm"
-+#else
-+ #define PVM_RX_FIFO_D "/var/vtpm/fifos/tpm_cmd_to_%d.fifo"
-+ #define PVM_TX_FIFO "/var/vtpm/fifos/tpm_rsp_from_all.fifo"
-
-+ #define HVM_RX_FIFO_D "/var/vtpm/socks/%d.socket"
-+#endif
-+
-+ int dmi_id;
-+                      =20
- #define BUFFER_SIZE 2048
-
- static int devurandom=3D0;
-@@ -38,7 +50,7 @@ void get_random_bytes(void *buf, int nby
-   }
-
-   if (read(devurandom, buf, nbytes) !=3D nbytes) {
--      printf("Can't get random number.\n");
-+      error("Can't get random number.\n");
-       exit(-1);
-   }
- }
-@@ -52,105 +64,182 @@ uint64_t tpm_get_ticks(void)
-
- int main(int argc, char **argv)
- {
--  uint8_t in[BUFFER_SIZE], *out;
-+  uint8_t type, in[BUFFER_SIZE], *out, *addressed_out;
-+  char *vtpm_rx_file=3DNULL;
-   uint32_t out_size;
-   int in_size, written;
--  int i;
--  struct stat file_info;
-+  int i, guest_id=3D-1;
-
--  int tpm_tx_fh=3D-1, tpm_rx_fh=3D-1;
-+#ifndef VTPM_MULTI_VM
-+  int sockfd =3D -1;
-+  struct sockaddr_un addr;
-+  struct sockaddr_un client_addr;
-+  unsigned int client_length;
-+
-+#endif
-+
-+  int vtpm_tx_fh=3D-1, vtpm_rx_fh=3D-1;
-+#ifdef VTPM_MULTI_VM
-   if (argc < 2) {
--    printf("Usage: tpmd clear|save|deactivated\n" );
-+    error("Usage: tpmd clear|save|deactivated\n" );
-+#else
-+  if (argc < 4) {
-+    error("Usage: tpmd clear|save|deactivated pvm|hvm vtpmid\n" );
-+#endif
-       return -1;
-   }
-
-+#ifndef VTPM_MULTI_VM
-+  /* setup type of vm */
-+  if (!strcmp(argv[2], "pvm")) {
-+    type =3D VTPM_TYPE_PVM; // Get commands from vTPM Manager through f=
ifo
-+  } else if (!strcmp(argv[2], "hvm")) {
-+    type =3D VTPM_TYPE_HVM; // Get commands from qemu via socket
-+  } else {
-+    error("invalid vTPM type '%s'.\n", argv[2]);
-+  }
-+
-+  dmi_id =3D atoi(argv[3]);
-+
-+  if (type =3D=3D VTPM_TYPE_PVM) {
-+    vtpm_rx_file =3D malloc(10 + strlen(PVM_RX_FIFO_D));
-+    sprintf(vtpm_rx_file, PVM_RX_FIFO_D, (uint32_t) dmi_id);
-+  } else {
-+    vtpm_rx_file =3D malloc(10 + strlen(HVM_RX_FIFO_D));
-+    sprintf(vtpm_rx_file, HVM_RX_FIFO_D, (uint32_t) dmi_id);
-+
-+    if ( (sockfd =3D socket(PF_UNIX,SOCK_STREAM,0)) < 0) {
-+          error("Unable to create socket. errno =3D %d\n", errno);
-+      exit (-1);
-+    }
-+
-+    memset(&addr, 0, sizeof(addr));
-+    addr.sun_family =3D AF_UNIX;
-+    strcpy(addr.sun_path,vtpm_rx_file );
-+    unlink(addr.sun_path);
-+  }
-+#endif
-+
-+#ifdef VTPM_MULTI_VM
-+  info("Initializing tpm state: %s\n", argv[1]);
-+#else
-+  info("Initializing tpm state: %s, type: %s, id: %d\n", argv[1],
argv[2], dmi_id);
-+#endif
-+
-   /* initialize TPM emulator */
-   if (!strcmp(argv[1], "clear")) {
--    printf("Initializing tpm: %s\n", argv[1]);
-     tpm_emulator_init(1);
--  } else if (!strcmp(argv[1], "save")) {
--    printf("Initializing tpm: %s\n", argv[1]);
-+  } else if (!strcmp(argv[1], "save")) {
-     tpm_emulator_init(2);
-   } else if (!strcmp(argv[1], "deactivated")) {
--    printf("Initializing tpm: %s\n", argv[1]);
-     tpm_emulator_init(3);
-   } else {
--    printf("invalid startup mode '%s'; must be 'clear', "
-+    error("invalid startup mode '%s'; must be 'clear', "
-       "'save' (default) or 'deactivated", argv[1]);
-     return -1;
-   }
--
--  if ( stat(TPM_RX_FNAME, &file_info) =3D=3D -1) {
--    if ( mkfifo(TPM_RX_FNAME, S_IWUSR | S_IRUSR ) ) {
--      printf("Failed to create fifo %s.\n", TPM_RX_FNAME);
--      return -1;
--    }
--  }
--
--  if ( stat(TPM_TX_FNAME, &file_info) =3D=3D -1) {
--    if ( mkfifo(TPM_TX_FNAME, S_IWUSR | S_IRUSR ) ) {
--      printf("Failed to create fifo %s.\n", TPM_TX_FNAME);
--      return -1;
--    }
--  }
--
-+=20
-   while (1) {
- abort_command:
--    if (tpm_rx_fh < 0) {
--      tpm_rx_fh =3D open(TPM_RX_FNAME, O_RDONLY);
-+    if (vtpm_rx_fh < 0) {
-+#ifdef VTPM_MUTLI_VM
-+      vtpm_rx_fh =3D open(DEV_BE, O_RDWR);
-+#else
-+      if (type =3D=3D VTPM_TYPE_PVM) {
-+        vtpm_rx_fh =3D open(vtpm_rx_file, O_RDONLY);
-+      } else {
-+        if (bind(sockfd, (struct sockaddr *)&addr, sizeof(addr)) < 0) {=

-+          error("Unable to bind(). errno =3D %d\n", errno);
-+          exit (-1);
-+        }
-+
-+        if (listen(sockfd, 10) <0) {
-+          error("Unable to listen(). errno =3D %d\n", errno);
-+          exit (-1);
-+        }
-+
-+        memset(&client_addr, 0, sizeof(client_addr));
-+        client_length =3D sizeof(client_addr);
-+
-+        vtpm_rx_fh =3D vtpm_tx_fh =3D accept(sockfd, (struct sockaddr
*)&client_addr, &client_length);
-+      }
-+#endif
-     }
-   =20
--    if (tpm_rx_fh < 0) {
--      printf("ERROR: failed to open devices to listen to guest.\n");
-+    if (vtpm_rx_fh < 0) {
-+      error("Failed to open devices to listen to guest.\n");
-       return -1;
-     }
-   =20
--    if (tpm_tx_fh < 0) {
--      tpm_tx_fh =3D open(TPM_TX_FNAME, O_WRONLY);
--    }
--
--    if (tpm_tx_fh < 0) {
--      printf("ERROR: failed to open devices to respond to guest.\n");
--      return -1;
--    }
--
--    in_size =3D read(tpm_rx_fh, in, BUFFER_SIZE);
-+    in_size =3D read(vtpm_rx_fh, in, BUFFER_SIZE);
-     if (in_size < 6) { // Magic size of minium TPM command
--      printf("Recv[%d] to small: 0x", in_size);
-+      info("Recv incomplete command of %d bytes.", in_size);
-       if (in_size <=3D 0) {
--          close(tpm_rx_fh);
--          tpm_rx_fh =3D -1;
-+          close(vtpm_rx_fh);
-+          vtpm_rx_fh =3D -1;
-           goto abort_command;
-       }
-     } else {
--      printf("Recv[%d]: 0x", in_size);
-+      debug_nostop("Recv[%d]: 0x", in_size);
-       for (i=3D0; i< in_size; i++)
--        printf("%x ", in[i]);
--      printf("\n");
-+        debug_more("%x ", in[i]);
-+      debug_more("\n");
-     }
-
--  =20
--    if (tpm_handle_command(in, in_size, &out, &out_size) !=3D 0) {
--        printf("ERROR: Handler Failed.\n");
-+    if (guest_id =3D=3D -1) {
-+        guest_id =3D *((uint32_t *) in);
-+    } else {
-+        if (guest_id !=3D *((uint32_t *) in) ) {
-+            error("WARNING: More than one guest attached\n");
-+        }
-+    }
-+
-+    if (vtpm_tx_fh < 0) {
-+#ifdef VTPM_MUTLI_VM
-+      vtpm_tx_fh =3D open(DEV_BE, O_RDWR);
-+      vtpm_rx_fh =3D vtpm_tx_fh;
-+#else
-+      if (type =3D=3D VTPM_TYPE_PVM) {
-+        vtpm_tx_fh =3D open(PVM_TX_FIFO, O_WRONLY);
-+      } // No need to open the other direction for HVM
-+#endif
-+    }
-+
-+    if (vtpm_tx_fh < 0) {
-+      error("Failed to open devices to respond to guest.\n");
-+      return -1;
-+    }
-+
-+    // Handle the command, but skip the domain id header  =20
-+    if (tpm_handle_command(in + sizeof(uint32_t), in_size -
sizeof(uint32_t), &out, &out_size) !=3D 0) {
-+      error("Handler Failed.\n");
-     }
-
--    written =3D write(tpm_tx_fh, out, out_size);
-+    addressed_out =3D (uint8_t *) tpm_malloc(sizeof(uint32_t) + out_siz=
e);
-+    *(uint32_t *) addressed_out =3D *(uint32_t *) in;
-+    memcpy(addressed_out + sizeof(uint32_t), out, out_size);
-+
-+    written =3D write(vtpm_tx_fh, addressed_out, out_size +
sizeof(uint32_t));
-
--    if (written !=3D out_size ) {
--      printf("ERROR: Part of response not written %d/%d.\nAttempt: ",
written, out_size);
-+    if (written !=3D out_size + sizeof(uint32_t)) {
-+      error("Part of response not written %d/%d.\n", written, out_size)=
;
-     } else {
--      printf("Sent[%Zu]: ", out_size);
-+      debug_nostop("Sent[%Zu]: ", out_size + sizeof(uint32_t));
-+      for (i=3D0; i< out_size+ sizeof(uint32_t); i++)
-+        debug_more("%x ", addressed_out[i]);
-+      debug_more("\n");
-     }
--    for (i=3D0; i< out_size; i++)
--      printf("%x ", out[i]);
--    printf("\n");
-     tpm_free(out);
-+    tpm_free(addressed_out);
-
-   } // loop
-
-   tpm_emulator_shutdown();
-
--  close(tpm_tx_fh);
--  close(tpm_rx_fh);
-+  close(vtpm_tx_fh);
-+#ifndef VTPM_MUTLI_VM
-+  close(vtpm_rx_fh);
-+  free (vtpm_rx_file);
-+#endif
-
- }





--------------ms070902070202080609000704
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIDyjCC
A8YwggMvoAMCAQICBD/xyf0wDQYJKoZIhvcNAQEFBQAwLzELMAkGA1UEBhMCVVMxDzANBgNV
BAoTBkpIVUFQTDEPMA0GA1UECxMGQklTRENBMB4XDTEwMDYxMTE4MjIwNloXDTEzMDYxMTE4
NTIwNlowZjELMAkGA1UEBhMCVVMxDzANBgNVBAoTBkpIVUFQTDEPMA0GA1UECxMGUGVvcGxl
MTUwFgYDVQQLEw9WUE5Hcm91cC1CSVNEQ0EwGwYDVQQDExRNYXR0aGV3IEUgRmlvcmF2YW50
ZTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAnpbwVSP6o1Nb5lcW7dd3yTo9iBJdi7qz
4nANOMFPK7JOy5npKN1iiousl28U/scUJES55gPwAWYJK3uVyQAsA4adgDKi5DoD1UHDQEwp
bY7iHLJeq0NPr4BqYNqnCFPbE6HC8zSJrr4qKn+gVUQT39SIFqdiIPJwZL8FYTRQ/zsCAwEA
AaOCAbYwggGyMAsGA1UdDwQEAwIHgDArBgNVHRAEJDAigA8yMDEwMDYxMTE4MjIwNlqBDzIw
MTIwNzE3MjI1MjA2WjAbBg0rBgEEAbMlCwMBAQEBBAoWCGZpb3JhbWUxMBsGDSsGAQQBsyUL
AwEBAQIEChIIMDAxMDQyNjEwWAYJYIZIAYb6ax4BBEsMSVRoZSBwcml2YXRlIGtleSBjb3Jy
ZXNwb25kaW5nIHRvIHRoaXMgY2VydGlmaWNhdGUgbWF5IGhhdmUgYmVlbiBleHBvcnRlZC4w
KAYDVR0RBCEwH4EdTWF0dGhldy5GaW9yYXZhbnRlQGpodWFwbC5lZHUwUgYDVR0fBEswSTBH
oEWgQ6RBMD8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJU0RD
QTEOMAwGA1UEAxMFQ1JMNTYwHwYDVR0jBBgwFoAUCDUpmxH52EU2CyWmF2EJMB1yqeswHQYD
VR0OBBYEFO6LYxg6r9wHZ+zdQtBHn1dZ/YTNMAkGA1UdEwQCMAAwGQYJKoZIhvZ9B0EABAww
ChsEVjcuMQMCBLAwDQYJKoZIhvcNAQEFBQADgYEAJO9HQh4YNChVLzuZqK5ARJARD8JoujGZ
fdo75quvg2jXFQe2sEjvLnxJZgm/pv8fdZakq48CWwjYHKuvIp7sDjTEsQfo+y7SpN/N2NvJ
WU5SqfK1VgYtNLRRoGJUB5Q1aZ+Dg95g3kqpyfpUMISJL8IKVLtJVfN4fggFVUYZ9wwxggGr
MIIBpwIBATA3MC8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJ
U0RDQQIEP/HJ/TAJBgUrDgMCGgUAoIHLMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ
KoZIhvcNAQkFMQ8XDTEyMDkyMTE4NTMwN1owIwYJKoZIhvcNAQkEMRYEFAyyf/i0y5rKwLIJ
rSvOqtpgwzLiMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAK
BggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI
KoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEgYAf9k9WKsOvnXozAPYht+KER/zQFGkL6OKp
fCyytOQZ5UDB9dtD5LXRHCvVGxN/4TARW0Tor1gM44sp/Xyfto5V6ql8XFnqTDXeMSzZWihO
NDyXwx5IJqhrZSGSh5HbD06t7Eej507GJcIotchx59NGzp0j5YRlMd1OLNq3QmkaBQAAAAAA
AA==
--------------ms070902070202080609000704--


--===============6507152100997419522==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============6507152100997419522==--


From xen-devel-bounces@lists.xen.org Fri Sep 21 18:54:51 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Sep 2012 18:54:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TF8N4-0001Mk-0p; Fri, 21 Sep 2012 18:54:38 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <matthew.fioravante@jhuapl.edu>) id 1TF8N1-0001MY-UW
	for xen-devel@lists.xensource.com; Fri, 21 Sep 2012 18:54:36 +0000
Received: from [85.158.143.99:12142] by server-2.bemta-4.messagelabs.com id
	48/D1-06610-BE7BC505; Fri, 21 Sep 2012 18:54:35 +0000
X-Env-Sender: matthew.fioravante@jhuapl.edu
X-Msg-Ref: server-9.tower-216.messagelabs.com!1348253667!31338649!1
X-Originating-IP: [128.244.251.36]
X-SpamReason: No, hits=0.0 required=7.0 tests=UNPARSEABLE_RELAY
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6898 invoked from network); 21 Sep 2012 18:54:28 -0000
Received: from pilot.jhuapl.edu (HELO jhuapl.edu) (128.244.251.36)
	by server-9.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 21 Sep 2012 18:54:28 -0000
Received: from ([128.244.207.89])
	by pilot.jhuapl.edu with ESMTP with TLS id 63GHCH1.153408747;
	Fri, 21 Sep 2012 14:54:23 -0400
Message-ID: <505CB793.1010405@jhuapl.edu>
Date: Fri, 21 Sep 2012 14:53:07 -0400
From: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120827 Thunderbird/15.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>, 
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
X-Enigmail-Version: 1.4.4
Subject: [Xen-devel] PATCH [base vtpm and libxl patches 1/6] Upgrade vtpmd
 from 0.5.1 to 0.7.4
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============6507152100997419522=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a cryptographically signed message in MIME format.

--===============6507152100997419522==
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms070902070202080609000704"

This is a cryptographically signed message in MIME format.

--------------ms070902070202080609000704
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Update vtpmd from 0.5.1 to 0.7.4. Also adds checks for cmake
and gmp to the configure script if vtpm is enabled.

Signed off by Matthew Fioravante matthew.fioravante@jhuapl.edu

---
Changed since previous:
* added checks for libgmp and gmp.h if vtpm is enabled
* small documentation updates

diff --git a/tools/configure.ac b/tools/configure.ac
--- a/tools/configure.ac
+++ b/tools/configure.ac
@@ -72,6 +72,7 @@ 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])
+AC_ARG_VAR([CMAKE], [Path to cmake binary])
=20
 # Checks for programs.
 AC_PROG_CC
@@ -101,6 +102,9 @@ AS_IF([echo "$PYTHON" | grep -q "^/"], [
 AX_PATH_PROG_OR_FAIL([PYTHONPATH], [$PYTHON])
 AX_CHECK_PYTHON_VERSION([2], [3])
  AX_CHECK_PYTHON_DEVEL()
+AS_IF([test "x$vtpm" =3D "xy"], [
+    AX_PATH_PROG_OR_FAIL([CMAKE], [cmake])
+])
 AX_PATH_PROG_OR_FAIL([XGETTEXT], [xgettext])
 dnl as86, ld86, bcc and iasl are only required when the host system is
x86*.
 dnl "host" here means the platform on which the hypervisor and tools is
@@ -142,6 +146,10 @@ AC_CHECK_LIB([yajl], [yajl_alloc], [],
 AC_CHECK_LIB([z], [deflateCopy], [], [AC_MSG_ERROR([Could not find zlib]=
)])
 AC_CHECK_LIB([iconv], [libiconv_open], [libiconv=3D"y"], [libiconv=3D"n"=
])
 AC_SUBST(libiconv)
+AS_IF([test "x$vtpm" =3D "xy"], [
+    AC_CHECK_HEADER([gmp.h], [], [AC_MSG_ERROR([Could not find gmp.h])])=

+    AC_CHECK_LIB([gmp], [__gmpz_init], [], [AC_MSG_ERROR([Could not
find libgmp])])
+])
=20
 # Checks for header files.
 AC_CHECK_HEADERS([yajl/yajl_version.h])
diff --git a/tools/vtpm/Makefile b/tools/vtpm/Makefile
--- a/tools/vtpm/Makefile
+++ b/tools/vtpm/Makefile
@@ -1,19 +1,15 @@
 XEN_ROOT =3D $(CURDIR)/../..
+include $(XEN_ROOT)/tools/Rules.mk
=20
-# Base definitions and rules
-include $(XEN_ROOT)/tools/vtpm/Rules.mk
-
-# Dir name for emulator (as dom0 tpm driver)
-TPM_EMULATOR_DIR =3D tpm_emulator
 # Dir name for vtpm instance
 VTPM_DIR =3D vtpm
-ORIG_DIR =3D orig
=20
 # Emulator tarball name
-TPM_EMULATOR_NAME =3D tpm_emulator-0.5.1
+TPM_EMULATOR_URL =3D http://download.berlios.de/tpm-emulator
+TPM_EMULATOR_NAME =3D tpm_emulator-0.7.4
 TPM_EMULATOR_TARFILE =3D $(TPM_EMULATOR_NAME).tar.gz
=20
-GMP_HEADER =3D /usr/include/gmp.h
+VTPM_PATCH =3D vtpm-0.7.4.patch
=20
 .PHONY: all
 all: build
@@ -23,52 +19,39 @@ build: build_sub
=20
 .PHONY: install
 install: build
-    $(MAKE) -C $(VTPM_DIR) install-recursive
+    $(INSTALL_PROG) -m 0755 $(VTPM_DIR)/build/tpmd/unix/tpmd
$(DESTDIR)$(BINDIR)/vtpmd
=20
 .PHONY: clean
 clean:
-    @if [ -d $(TPM_EMULATOR_DIR) ]; \
-        then $(MAKE) -C $(TPM_EMULATOR_DIR) clean; \
-    fi
-    @if [ -d $(VTPM_DIR) ]; \
-        then $(MAKE) -C $(VTPM_DIR) clean; \
+    @-if [ -d $(VTPM_DIR)/build ]; \
+        then $(MAKE) -C $(VTPM_DIR)/build clean; \
     fi
=20
-.PHONY: mrproper
-mrproper:
-    rm -f $(TPM_EMULATOR_TARFILE) tpm_emulator.patch.old vtpm.patch.old
-    rm -rf $(TPM_EMULATOR_DIR) $(VTPM_DIR) $(ORIG_DIR)
+.PHONY: distclean
+mdistclean:
+    rm -f $(TPM_EMULATOR_TARFILE)
+    rm -rf $(VTPM_DIR) $(ORIG_DIR)
=20
 # Download Swiss emulator
 $(TPM_EMULATOR_TARFILE):
-    wget http://download.berlios.de/tpm-emulator/$(TPM_EMULATOR_TARFILE)=

+    wget $(TPM_EMULATOR_URL)/$(TPM_EMULATOR_TARFILE)
=20
 # Create vtpm dirs
-$(VTPM_DIR)/tpmd/tpmd: $(TPM_EMULATOR_TARFILE) vtpm-0.5.1.patch
+$(VTPM_DIR)/build: $(TPM_EMULATOR_TARFILE) $(VTPM_PATCH)
     rm -rf $(VTPM_DIR)
     tar -xzf $(TPM_EMULATOR_TARFILE)
     mv $(TPM_EMULATOR_NAME) $(VTPM_DIR)
-
     set -e; cd $(VTPM_DIR); \
-    patch -p1 < ../vtpm-0.5.1.patch; \
-    patch -p1 < ../vtpm-0.5.1-LDLIBS.patch
+    patch -p1 < ../$(VTPM_PATCH);
+    mkdir $@
+    touch $@
=20
-orig: $(TPM_EMULATOR_TARFILE)
-    mkdir $(ORIG_DIR);
-    set -e; cd $(ORIG_DIR); \
-    tar -xzf ../$(TPM_EMULATOR_TARFILE);
-
-updatepatches: clean orig
-    find $(VTPM_DIR) -name "*.orig" -print | xargs rm -f;
-    mv vtpm.patch vtpm.patch.old;
-    diff -uprN $(TPM_EMULATOR_DIR) $(VTPM_DIR) > vtpm.patch || true;
+$(VTPM_DIR)/build/Makefile: $(VTPM_DIR)/build
+    set -e; cd $(VTPM_DIR)/build; \
+    cmake -DCMAKE_INSTALL_PREFIX=3D${PREFIX} ..
+    touch $@
=20
 .PHONY: build_sub
-build_sub: $(VTPM_DIR)/tpmd/tpmd
-    set -e; if [ -e $(GMP_HEADER) ]; then \
-        $(MAKE) -C $(VTPM_DIR) version; \
-        $(MAKE) -C $(VTPM_DIR) all-recursive; \
-    else \
-        echo "=3D=3D=3D Unable to build VTPMs. libgmp could not be found=
=2E"; \
-    fi
-
+build_sub: $(VTPM_DIR)/build/Makefile
+    set -e; \
+    cd $(VTPM_DIR)/build; $(MAKE) tpmd
diff --git a/tools/vtpm/README b/tools/vtpm/README
--- a/tools/vtpm/README
+++ b/tools/vtpm/README
@@ -1,27 +1,19 @@
=20
 Directory Structure
 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
-tools/vtpm/tpm_emulator-0.2b.tar.gz    -> TPM Emulator downloaded at
build time that will
+tools/vtpm/tpm_emulator-0.7.4.tar.gz   -> TPM Emulator downloaded at
build time that will
                                           be patched and used for our vt=
pms
-tools/vtpm/vtpm.patch                  -> patch applied to tpm_emulator
to make vtpm
+tools/vtpm/vtpm-0.7.4.patch             -> patch applied to
tpm_emulator to make vtpm
 tools/vtpm/vtpm/                       -> (created on build)
tpm_emulator moved to ring 3,
                                           listens on a pair of fifos
for TPM commands,
                                           persistent state is sent via
named fifo to vtpm
                                             manager, which encrypts it
and protects it.
-tools/vtpm/tpm_emulator.patch          -> To allow for debugging and
testing on non-TPM
-                                          platforms, this patches the
emulator to allow
-                                          it to be inserted into the
dom0 kernel
-tools/vtpm/tpm_emulator-0.2            -> (created on build) directory
containing patched emulator
-
-Compile Flags
-=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
-VTPM_MULTI_VM                -> Defined (not finished): VTPMs run in
their own VMs
-                                Not Defined (default): VTPMs are process=
es
+tools/vtpm/tpm_emulator-0.7.4          -> (created on build) directory
containing patched emulator
=20
 Requirements
 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
 - xen-unstable
-- IBM frontend/backend vtpm driver patch
+- IBM frontend/backend vtpm driver patch for the linux kernel
 - vtpm_managerd
 - GNU MP Big number library (GMP)
=20
@@ -42,4 +34,4 @@ vtpmd Flow (for vtpm_manager. vtpmd never run by defaul=
t)
=20
 tpm_emulator flow
 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
-Read documentation in tpm_emulator-0.2 directory
+Read documentation in tpm_emulator directory
diff --git a/tools/vtpm/Rules.mk b/tools/vtpm/Rules.mk
--- a/tools/vtpm/Rules.mk
+++ /dev/null
@@ -1,26 +0,0 @@
-# Base definitions and rules (XEN_ROOT must be defined in including
Makefile)
-include $(XEN_ROOT)/tools/Rules.mk
-
-#
-# Tool definitions
-#
-
-# General compiler flags
-CFLAGS   =3D -Werror -g3
-
-# Generic project files
-HDRS    =3D $(wildcard *.h)
-SRCS    =3D $(wildcard *.c)
-OBJS    =3D $(patsubst %.c,%.o,$(SRCS))
-
-# Generic (non-header) dependencies
-$(SRCS): Makefile $(XEN_ROOT)/tools/Rules.mk
$(XEN_ROOT)/tools/vtpm/Rules.mk
-
-$(OBJS): $(SRCS)
-
--include $(DEPS)
-
-BUILD_EMULATOR =3D y
-
-# Make sure these are just rules
-.PHONY : all build install clean
diff --git a/tools/vtpm/tpm_emulator.patch b/tools/vtpm/tpm_emulator.patc=
h
--- a/tools/vtpm/tpm_emulator.patch
+++ /dev/null
@@ -1,1919 +0,0 @@
-diff -uprN orig/tpm_emulator-0.4/AUTHORS tpm_emulator/AUTHORS
---- orig/tpm_emulator-0.4/AUTHORS    2006-06-23 03:37:07.000000000 -0700=

-+++ tpm_emulator/AUTHORS    2006-07-24 14:35:35.000000000 -0700
-@@ -1,2 +1,3 @@
- Mario Strasser <mast@gmx.net>
- Heiko Stamer <stamer@gaos.org> [DAA]
-+INTEL Corp <> [Dropped to Ring3]
-diff -uprN orig/tpm_emulator-0.4/ChangeLog tpm_emulator/ChangeLog
---- orig/tpm_emulator-0.4/ChangeLog    2006-06-23 03:37:07.000000000 -07=
00
-+++ tpm_emulator/ChangeLog    2006-07-24 14:35:35.000000000 -0700
-@@ -1,3 +1,6 @@
-+????-??-?? Intel Corp
-+    * Moved module out of kernel to run as a ring 3 app
-+
- 2006-06-23  Mario Strasser <mast@gmx.net>
-     * tpm_startup.c: behaviour of ST_CLEAR and storage of
-         persistent data adapted
-diff -uprN orig/tpm_emulator-0.4/crypto/gmp_kernel_wrapper.c
tpm_emulator/crypto/gmp_kernel_wrapper.c
---- orig/tpm_emulator-0.4/crypto/gmp_kernel_wrapper.c    2006-06-23
03:37:07.000000000 -0700
-+++ tpm_emulator/crypto/gmp_kernel_wrapper.c    2006-07-24
14:35:35.000000000 -0700
-@@ -1,5 +1,6 @@
- /* Software-Based Trusted Platform Module (TPM) Emulator for Linux
-  * Copyright (C) 2004 Mario Strasser <mast@gmx.net>,
-+ * Copyright (C) 2005 INTEL Corp
-  *
-  * This module is free software; you can redistribute it and/or modify
-  * it under the terms of the GNU General Public License as published
-@@ -24,15 +25,10 @@ int __gmp_junk;
- void __attribute__ ((regparm(0))) __gmp_assert_fail(const char *filenam=
e,
-   int linenum, const char *expr)
- {
--  panic(KERN_CRIT TPM_MODULE_NAME "%s:%d: GNU MP assertion failed: %s\n=
",
-+  error("%s:%d: GNU MP assertion failed: %s\n",
-     filename, linenum, expr);
- }
-
--void __attribute__ ((regparm(0))) abort(void)
--{
--  panic(KERN_CRIT TPM_MODULE_NAME "GNU MP abort() was called\n");
--}
--
- /* overwrite GNU MP random functions (used by mpz/millerrabin.c) */
-
- void __attribute__ ((regparm(0))) gmp_randinit(gmp_randstate_t rstate,
-@@ -77,20 +73,19 @@ void __attribute__ ((regparm(0))) mpz_ur
-
- void __attribute__ ((regparm(0))) *kernel_allocate(size_t size)
- {
--  void *ret  =3D (void*)kmalloc(size, GFP_KERNEL);
--  if (!ret) panic(KERN_CRIT TPM_MODULE_NAME
--    "GMP: cannot allocate memory (size=3D%u)\n", size);
-+  void *ret  =3D (void*)malloc(size);
-+  if (!ret) error("GMP: cannot allocate memory (size=3D%Zu)\n", size);
-   return ret;
- }
-
- void __attribute__ ((regparm(0))) *kernel_reallocate(void *oldptr,
-   size_t old_size, size_t new_size)
- {
--  void *ret =3D (void*)kmalloc(new_size, GFP_KERNEL);
--  if (!ret) panic(KERN_CRIT TPM_MODULE_NAME "GMP: Cannot reallocate
memory "
--    "(old_size=3D%u new_size=3D%u)\n", old_size, new_size);
-+  void *ret =3D (void*)malloc(new_size);
-+  if (!ret) error("GMP: Cannot reallocate memory "
-+    "(old_size=3D%Zu new_size=3D%Zu)\n", old_size, new_size);
-   memcpy(ret, oldptr, old_size);
--  kfree(oldptr);
-+  free(oldptr);
-   return ret;
- }
-
-@@ -99,7 +94,7 @@ void __attribute__ ((regparm(0))) kernel
-   /* overwrite used memory */
-   if (blk_ptr !=3D NULL) {
-     memset(blk_ptr, 0, blk_size);
--    kfree(blk_ptr);
-+    free(blk_ptr);
-   }
- }
-
-diff -uprN orig/tpm_emulator-0.4/crypto/rsa.c tpm_emulator/crypto/rsa.c
---- orig/tpm_emulator-0.4/crypto/rsa.c    2006-06-23 03:37:07.000000000
-0700
-+++ tpm_emulator/crypto/rsa.c    2006-07-24 14:35:35.000000000 -0700
-@@ -1,5 +1,6 @@
- /* Software-Based Trusted Platform Module (TPM) Emulator for Linux
-  * Copyright (C) 2004 Mario Strasser <mast@gmx.net>,
-+ * Copyright (C) 2005 INTEL Corp
-  *
-  * This module is free software; you can redistribute it and/or modify
-  * it under the terms of the GNU General Public License as published
-@@ -381,7 +382,7 @@ static int encode_message(int type, uint
-       msg[0] =3D 0x00;
-       get_random_bytes(&msg[1], SHA1_DIGEST_LENGTH);
-       sha1_init(&ctx);
--      sha1_update(&ctx, "TCPA", 4);
-+      sha1_update(&ctx, (uint8_t *) "TCPA", 4);
-       sha1_final(&ctx, &msg[1 + SHA1_DIGEST_LENGTH]);
-       memset(&msg[1 + 2 * SHA1_DIGEST_LENGTH], 0x00,
-         msg_len - data_len - 2 * SHA1_DIGEST_LENGTH - 2);
-@@ -429,7 +430,7 @@ static int decode_message(int type, uint
-       mask_generation(&msg[1], SHA1_DIGEST_LENGTH,
-         &msg[1 + SHA1_DIGEST_LENGTH], msg_len - SHA1_DIGEST_LENGTH - 1)=
;
-       sha1_init(&ctx);
--      sha1_update(&ctx, "TCPA", 4);
-+      sha1_update(&ctx, (uint8_t *) "TCPA", 4);
-       sha1_final(&ctx, &msg[1]);
-       if (memcmp(&msg[1], &msg[1 + SHA1_DIGEST_LENGTH],
-           SHA1_DIGEST_LENGTH) !=3D 0) return -1;
-diff -uprN orig/tpm_emulator-0.4/linux_module.c tpm_emulator/linux_modul=
e.c
---- orig/tpm_emulator-0.4/linux_module.c    2006-06-23
03:37:07.000000000 -0700
-+++ tpm_emulator/linux_module.c    1969-12-31 16:00:00.000000000 -0800
-@@ -1,195 +0,0 @@
--/* Software-Based Trusted Platform Module (TPM) Emulator for Linux
-- * Copyright (C) 2004 Mario Strasser <mast@gmx.net>,
-- *
-- * This module 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.=20
-- *
-- * This module 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.
-- *
-- * $Id: linux_module.c 91 2006-03-13 13:51:41Z mast $
-- */
--
--#include <linux/module.h>
--#include <linux/kernel.h>
--#include <linux/init.h>
--#include <linux/miscdevice.h>
--#include <linux/poll.h>
--#include "linux_module.h"
--#include "tpm/tpm_emulator.h"
--
--MODULE_LICENSE("GPL");
--MODULE_AUTHOR("Mario Strasser <mast@gmx.net>");
--MODULE_DESCRIPTION("Trusted Platform Module (TPM) Emulator");
--MODULE_SUPPORTED_DEVICE(TPM_DEVICE_NAME);
--
--/* module startup parameters */
--char *startup =3D "save";
--module_param(startup, charp, 0444);
--MODULE_PARM_DESC(startup, " Sets the startup mode of the TPM. "
--  "Possible values are 'clear', 'save' (default) and 'deactivated.");
--char *storage_file =3D "/var/tpm/tpm_emulator-1.2.0.2";
--module_param(storage_file, charp, 0644);
--MODULE_PARM_DESC(storage_file, " Sets the persistent-data storage "
--  "file of the TPM.");
--
--/* TPM lock */
--static struct semaphore tpm_mutex;
--
--/* TPM command response */
--static struct {
--  uint8_t *data;
--  uint32_t size;
--} tpm_response;
--
--/* module state */
--#define STATE_IS_OPEN 0
--static uint32_t module_state;
--static struct timespec old_time;
--
--static int tpm_open(struct inode *inode, struct file *file)
--{
--  debug("%s()", __FUNCTION__);
--  if (test_and_set_bit(STATE_IS_OPEN, (void*)&module_state)) return
-EBUSY;
--  return 0;
--}
--
--static int tpm_release(struct inode *inode, struct file *file)
--{
--  debug("%s()", __FUNCTION__);
--  clear_bit(STATE_IS_OPEN, (void*)&module_state);
--  down(&tpm_mutex);
--  if (tpm_response.data !=3D NULL) {
--    kfree(tpm_response.data);
--    tpm_response.data =3D NULL;
--  }
--  up(&tpm_mutex);
--  return 0;
--}
--
--static ssize_t tpm_read(struct file *file, char *buf, size_t count,
loff_t *ppos)
--{
--  debug("%s(%d)", __FUNCTION__, count);
--  down(&tpm_mutex);
--  if (tpm_response.data !=3D NULL) {
--    count =3D min(count, (size_t)tpm_response.size - (size_t)*ppos);
--    count -=3D copy_to_user(buf, &tpm_response.data[*ppos], count);
--    *ppos +=3D count;
--    if ((size_t)tpm_response.size =3D=3D (size_t)*ppos) {
--      kfree(tpm_response.data);
--      tpm_response.data =3D NULL;
--    }
--  } else {
--    count =3D 0;
--  }
--  up(&tpm_mutex);
--  return count;
--}
--
--static ssize_t tpm_write(struct file *file, const char *buf, size_t
count, loff_t *ppos)
--{
--  debug("%s(%d)", __FUNCTION__, count);
--  down(&tpm_mutex);
--  *ppos =3D 0;
--  if (tpm_response.data !=3D NULL) kfree(tpm_response.data);
--  if (tpm_handle_command(buf, count, &tpm_response.data,
--                         &tpm_response.size) !=3D 0) {
--    count =3D -EILSEQ;
--    tpm_response.data =3D NULL;
--  }
--  up(&tpm_mutex);
--  return count;
--}
--
--#define TPMIOC_CANCEL   _IO('T', 0x00)
--#define TPMIOC_TRANSMIT _IO('T', 0x01)
--
--static int tpm_ioctl(struct inode *inode, struct file *file, unsigned
int cmd, unsigned long arg)
--{
--  debug("%s(%d, %p)", __FUNCTION__, cmd, (char*)arg);
--  if (cmd =3D=3D TPMIOC_TRANSMIT) {
--    uint32_t count =3D ntohl(*(uint32_t*)(arg + 2));
--    down(&tpm_mutex);
--    if (tpm_response.data !=3D NULL) kfree(tpm_response.data);
--    if (tpm_handle_command((char*)arg, count, &tpm_response.data,
--                           &tpm_response.size) =3D=3D 0) {
--      tpm_response.size -=3D copy_to_user((char*)arg, tpm_response.data=
,
--                            tpm_response.size);
--      kfree(tpm_response.data);
--      tpm_response.data =3D NULL;
--    } else {
--      tpm_response.size =3D 0;
--      tpm_response.data =3D NULL;
--    }
--    up(&tpm_mutex);
--    return tpm_response.size;
--  }
--  return -1;
--}
--
--struct file_operations fops =3D {
--  .owner   =3D THIS_MODULE,
--  .open    =3D tpm_open,
--  .release =3D tpm_release,
--  .read    =3D tpm_read,
--  .write   =3D tpm_write,
--  .ioctl   =3D tpm_ioctl,
--};
--
--static struct miscdevice tpm_dev =3D {
--  .minor      =3D TPM_DEVICE_MINOR,
--  .name       =3D TPM_DEVICE_NAME,
--  .fops       =3D &fops,
--};
--
--int __init init_tpm_module(void)
--{
--  int res =3D misc_register(&tpm_dev);
--  if (res !=3D 0) {
--    error("misc_register() failed for minor %d\n", TPM_DEVICE_MINOR);
--    return res;
--  }
--  /* initialize variables */
--  sema_init(&tpm_mutex, 1);
--  module_state =3D 0;
--  tpm_response.data =3D NULL;
--  old_time =3D current_kernel_time();
--  /* initialize TPM emulator */
--  if (!strcmp(startup, "clear")) {
--    tpm_emulator_init(1);
--  } else if (!strcmp(startup, "save")) {
--    tpm_emulator_init(2);
--  } else if (!strcmp(startup, "deactivated")) {
--    tpm_emulator_init(3);
--  } else {
--    error("invalid startup mode '%s'; must be 'clear', "
--      "'save' (default) or 'deactivated", startup);
--    misc_deregister(&tpm_dev);
--    return -EINVAL;
--  }
--  return 0;
--}
--
--void __exit cleanup_tpm_module(void)
--{
--  tpm_emulator_shutdown();
--  misc_deregister(&tpm_dev);
--  if (tpm_response.data !=3D NULL) kfree(tpm_response.data);
--}
--
--module_init(init_tpm_module);
--module_exit(cleanup_tpm_module);
--
--uint64_t tpm_get_ticks(void)
--{
--  struct timespec new_time =3D current_kernel_time();
--  uint64_t ticks =3D (uint64_t)(new_time.tv_sec - old_time.tv_sec) * 10=
00000
--                   + (new_time.tv_nsec - old_time.tv_nsec) / 1000;
--  old_time =3D new_time;
--  return (ticks > 0) ? ticks : 1;
--}
--
-diff -uprN orig/tpm_emulator-0.4/linux_module.h tpm_emulator/linux_modul=
e.h
---- orig/tpm_emulator-0.4/linux_module.h    2006-06-23
03:37:07.000000000 -0700
-+++ tpm_emulator/linux_module.h    2006-07-24 14:35:35.000000000 -0700
-@@ -1,5 +1,6 @@
- /* Software-Based Trusted Platform Module (TPM) Emulator for Linux
-  * Copyright (C) 2004 Mario Strasser <mast@gmx.net>,
-+ * Copyright (C) 2005 INTEL Corp
-  *
-  * This module is free software; you can redistribute it and/or modify
-  * it under the terms of the GNU General Public License as published
-@@ -17,54 +18,62 @@
- #ifndef _LINUX_MODULE_H_
- #define _LINUX_MODULE_H_
-
--#include <linux/version.h>
--#include <linux/kernel.h>
--#include <linux/slab.h>
-+#include <malloc.h>
-+#include <stdint.h>
-+#include <stdio.h>
-+#include <string.h>
- #include <linux/types.h>
--#include <linux/string.h>
--#include <linux/random.h>
--#include <linux/time.h>
--#include <asm/byteorder.h>
-
--/* module settings */
-+#include <endian.h>
-+#define __BYTEORDER_HAS_U64__
-+#ifdef LITTLE_ENDIAN
-+ #include <linux/byteorder/little_endian.h>
-+#else
-+ #include <linux/byteorder/big_endian.h>
-+#endif
-
-+/* module settings */
-+#define min(A,B) ((A)<(B)?(A):(B))
-+#ifndef STR
- #define STR(s) __STR__(s)
- #define __STR__(s) #s
-+#endif
- #include "tpm_version.h"
-
- #define TPM_DEVICE_MINOR  224
- #define TPM_DEVICE_NAME   "tpm"
- #define TPM_MODULE_NAME   "tpm_emulator"
-
--/* debug and log output functions */
--
- #ifdef DEBUG
--#define debug(fmt, ...) printk(KERN_DEBUG "%s %s:%d: Debug: " fmt "\n",=
 \
--                        TPM_MODULE_NAME, __FILE__, __LINE__, ##
__VA_ARGS__)
-+#define debug(fmt, ...) printf("TPMD: %s:%d: Debug: " fmt "\n", \
-+                        __FILE__, __LINE__, ## __VA_ARGS__)
- #else
- #define debug(fmt, ...)
- #endif
--#define info(fmt, ...)  printk(KERN_INFO "%s %s:%d: Info: " fmt "\n", \=

--                        TPM_MODULE_NAME, __FILE__, __LINE__, ##
__VA_ARGS__)
--#define error(fmt, ...) printk(KERN_ERR "%s %s:%d: Error: " fmt "\n", \=

--                        TPM_MODULE_NAME, __FILE__, __LINE__, ##
__VA_ARGS__)
--#define alert(fmt, ...) printk(KERN_ALERT "%s %s:%d: Alert: " fmt "\n",=
 \
--                        TPM_MODULE_NAME, __FILE__, __LINE__, ##
__VA_ARGS__)
-+#define info(fmt, ...)  printf("TPMD: %s:%d: Info: " fmt "\n", \
-+                        __FILE__, __LINE__, ## __VA_ARGS__)
-+#define error(fmt, ...) printf("TPMD: %s:%d: Error: " fmt "\n", \
-+                        __FILE__, __LINE__, ## __VA_ARGS__)
-+#define alert(fmt, ...) printf("TPMD: %s:%d: Alert: " fmt "\n", \
-+                        __FILE__, __LINE__, ## __VA_ARGS__)
-
- /* memory allocation */
-
- static inline void *tpm_malloc(size_t size)
- {
--  return kmalloc(size, GFP_KERNEL);=20
-+  return malloc(size);=20
- }
-
- static inline void tpm_free(const void *ptr)
- {
--  if (ptr !=3D NULL) kfree(ptr);
-+  if (ptr !=3D NULL) free( (void *) ptr);
- }
-
- /* random numbers */
-
-+//FIXME;
-+void get_random_bytes(void *buf, int nbytes);
-+
- static inline void tpm_get_random_bytes(void *buf, int nbytes)
- {
-   get_random_bytes(buf, nbytes);
-@@ -84,9 +93,9 @@ uint64_t tpm_get_ticks(void);
- #define CPU_TO_LE16(x) __cpu_to_le16(x)
-
- #define BE64_TO_CPU(x) __be64_to_cpu(x)
--#define LE64_TO_CPU(x) __be64_to_cpu(x)
-+#define LE64_TO_CPU(x) __le64_to_cpu(x)
- #define BE32_TO_CPU(x) __be32_to_cpu(x)
--#define LE32_TO_CPU(x) __be32_to_cpu(x)
-+#define LE32_TO_CPU(x) __le32_to_cpu(x)
- #define BE16_TO_CPU(x) __be16_to_cpu(x)
- #define LE16_TO_CPU(x) __le16_to_cpu(x)
-
-diff -uprN orig/tpm_emulator-0.4/Makefile tpm_emulator/Makefile
---- orig/tpm_emulator-0.4/Makefile    2006-06-23 03:37:07.000000000 -070=
0
-+++ tpm_emulator/Makefile    2006-07-24 14:35:35.000000000 -0700
-@@ -1,24 +1,40 @@
- # Software-Based Trusted Platform Module (TPM) Emulator for Linux
- # Copyright (C) 2004 Mario Strasser <mast@gmx.net>
-+# Copyright (C) 2006 INTEL Corp.
- #
- # $Id: Makefile 115 2006-06-23 10:36:44Z mast $
-
--# kernel settings
--KERNEL_RELEASE :=3D $(shell uname -r)
--KERNEL_BUILD   :=3D /lib/modules/$(KERNEL_RELEASE)/build
--MOD_SUBDIR     :=3D misc
-+COMPILE_ARCH    ?=3D $(shell uname -m | sed -e s/i.86/x86_32/)
-
- # module settings
--MODULE_NAME    :=3D tpm_emulator
-+BIN            :=3D tpm_emulator
- VERSION_MAJOR  :=3D 0
- VERSION_MINOR  :=3D 4
- VERSION_BUILD  :=3D $(shell date +"%s")
-
--# enable/disable DEBUG messages
--EXTRA_CFLAGS   +=3D -Wall -DDEBUG -g=20
-+# Installation program and options
-+INSTALL         =3D install
-+INSTALL_PROG    =3D $(INSTALL) -m0755
-+INSTALL_DIR     =3D $(INSTALL) -d -m0755
-+
-+# Xen tools installation directory
-+TOOLS_INSTALL_DIR =3D $(DESTDIR)/usr/bin
-+
-+CC      :=3D gcc
-+CFLAGS  +=3D -g -Wall $(INCLUDE) -DDEBUG
-+CFLAGS  +=3D -I. -Itpm
-+
-+# Is the simulator running in it's own vm?
-+#CFLAGS +=3D -DVTPM_MULTI_VM
-+
-+ifeq ($(COMPILE_ARCH),x86_64)
-+LIBDIR =3D lib64
-+else
-+LIBDIR =3D lib
-+endif
-
- # GNU MP configuration
--GMP_LIB        :=3D /usr/lib/libgmp.a
-+GMP_LIB        :=3D /usr/$(LIBDIR)/libgmp.a
- GMP_HEADER     :=3D /usr/include/gmp.h
-
- # sources and objects
-@@ -27,38 +43,32 @@ DIRS           :=3D . crypto tpm
- SRCS           :=3D $(foreach dir, $(DIRS), $(wildcard $(src)/$(dir)/*.=
c))
- OBJS           :=3D $(patsubst %.c, %.o, $(SRCS))
- SRCS           +=3D $(foreach dir, $(DIRS), $(wildcard $(src)/$(dir)/*.=
h))
--DISTSRC        :=3D ./README ./AUTHORS ./ChangeLog ./Makefile $(SRCS)
--DISTDIR        :=3D tpm_emulator-$(VERSION_MAJOR).$(VERSION_MINOR)
-
--obj-m               :=3D $(MODULE_NAME).o
--$(MODULE_NAME)-objs :=3D $(patsubst $(src)/%.o, %.o, $(OBJS))
crypto/libgmp.a
-+obj-m               :=3D $(BIN)
-+$(BIN)-objs :=3D $(patsubst $(src)/%.o, %.o, $(OBJS)) crypto/libgmp.a
-
- EXTRA_CFLAGS   +=3D -I$(src) -I$(src)/crypto -I$(src)/tpm
-
- # do not print "Entering directory ..."
- MAKEFLAGS      +=3D --no-print-directory
-
--all:    $(src)/crypto/gmp.h $(src)/crypto/libgmp.a version
--    @$(MAKE) -C $(KERNEL_BUILD) M=3D$(CURDIR) modules
-+all: $(BIN)
-
--install:
--    @$(MAKE) -C $(KERNEL_BUILD) M=3D$(CURDIR) modules_install
--    test -d /var/tpm || mkdir /var/tpm
--    test -c /dev/tpm || mknod /dev/tpm c 10 224
--    chmod 666 /dev/tpm
--    depmod -a
-+$(BIN):    $(src)/crypto/gmp.h $(src)/crypto/libgmp.a version $(SRCS)
$(OBJS)
-+    $(CC) $(CFLAGS) $(OBJS) $(src)/crypto/libgmp.a -o $(BIN)
-+
-+%.o: %.c
-+    $(CC) $(CFLAGS) -c $< -o $@
-+
-+install: $(BIN)
-+    $(INSTALL_PROG) $(BIN) $(TOOLS_INSTALL_DIR)
-+    @if [ ! -d "/var/tpm" ]; then mkdir /var/tpm; fi
-
- clean:
--    @$(MAKE) -C $(KERNEL_BUILD) M=3D$(CURDIR) clean
--    rm -f $(src)/crypto/gmp.h $(src)/crypto/libgmp.a
-+    rm -f $(src)/crypto/gmp.h $(src)/crypto/libgmp.a $(OBJS)
-
--dist:    $(DISTSRC)
--    rm -rf $(DISTDIR)
--    mkdir $(DISTDIR)
--    cp --parents $(DISTSRC) $(DISTDIR)/
--    rm -f $(DISTDIR)/crypto/gmp.h
--    tar -chzf $(DISTDIR).tar.gz $(DISTDIR)
--    rm -rf $(DISTDIR)
-+mrproper: clean
-+    rm -f $(BIN) tpm_version.h
-
- $(src)/crypto/libgmp.a:
-     test -f $(src)/crypto/libgmp.a || ln -s $(GMP_LIB)
$(src)/crypto/libgmp.a
-@@ -88,4 +98,3 @@ version:
-     @echo "#endif /* _TPM_VERSION_H_ */" >> $(src)/tpm_version.h
-
- .PHONY: all install clean dist gmp version
--
-diff -uprN orig/tpm_emulator-0.4/README tpm_emulator/README
---- orig/tpm_emulator-0.4/README    2006-06-23 03:37:07.000000000 -0700
-+++ tpm_emulator/README    2006-07-24 14:35:35.000000000 -0700
-@@ -13,7 +13,8 @@ $Id: README 113 2006-06-18 12:38:13Z hst
- Copyright
- -----------------------------------------------------------------------=
---
- Copyright (C) 2004 Mario Strasser <mast@gmx.net> and Swiss Federal
--Institute of Technology (ETH) Zurich.
-+                   Institute of Technology (ETH) Zurich.
-+Copyright (C) 2005 INTEL Corp
-             =20
- 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
-@@ -43,6 +44,12 @@ Example:
- GMP_LIB        :=3D /usr/lib/libgmp.a
- GMP_HEADER     :=3D /usr/include/gmp.h
-
-+GNU MP Library on 64 bit Systems
-+-----------------------------------------------------------------------=
---
-+Some 64-bit kernels have problems with importing the user-space gmp
-+library (/usr/lib*/libgmp.a) into kernel space.  These kernels will
require
-+that the gmp library be recompiled for kernel space with -mcmodel=3Dker=
nel.
-+
- Installation
- -----------------------------------------------------------------------=
---
- The compilation and installation process uses the build environment for=

-diff -uprN orig/tpm_emulator-0.4/tpm/tpm_capability.c
tpm_emulator/tpm/tpm_capability.c
---- orig/tpm_emulator-0.4/tpm/tpm_capability.c    2006-06-23
19:37:07.000000000 +0900
-+++ tpm_emulator/tpm/tpm_capability.c    2007-12-28 22:50:19.000000000
+0900
-@@ -701,7 +701,10 @@ TPM_RESULT TPM_GetCapabilityOwner(TPM_VE
-   TPM_RESULT res;
- =20
-   info("TPM_GetCapabilityOwner()");
--=20
-+
-+  if (!tpmData.permanent.flags.owned) {
-+    return TPM_NOSRK;
-+  }
-   /* Verify owner authorization */
-   res =3D tpm_verify_auth(auth1, tpmData.permanent.data.ownerAuth,
TPM_KH_OWNER);
-   if (res !=3D TPM_SUCCESS) return res;
-diff -uprN orig/tpm_emulator-0.4/tpm/tpm_cmd_handler.c
tpm_emulator/tpm/tpm_cmd_handler.c
---- orig/tpm_emulator-0.4/tpm/tpm_cmd_handler.c    2006-06-23
19:37:07.000000000 +0900
-+++ tpm_emulator/tpm/tpm_cmd_handler.c    2007-09-12 20:23:00.000000000
+0900
-@@ -565,7 +565,7 @@ static TPM_RESULT execute_TPM_Seal(TPM_R
-   if (tpm_unmarshal_TPM_KEY_HANDLE(&ptr, &len, &keyHandle)
-       || tpm_unmarshal_TPM_ENCAUTH(&ptr, &len, &encAuth)
-       || tpm_unmarshal_UINT32(&ptr, &len, &pcrInfoSize)
--      || tpm_unmarshal_TPM_PCR_INFO(&ptr, &len, &pcrInfo)
-+      || (pcrInfoSize >0 && tpm_unmarshal_TPM_PCR_INFO(&ptr, &len,
&pcrInfo))
-       || tpm_unmarshal_UINT32(&ptr, &len, &inDataSize)
-       || tpm_unmarshal_BLOB(&ptr, &len, &inData, inDataSize)
-       || len !=3D 0) return TPM_BAD_PARAMETER;
-@@ -798,7 +798,7 @@ static TPM_RESULT execute_TPM_Sealx(TPM_
-   if (tpm_unmarshal_TPM_KEY_HANDLE(&ptr, &len, &keyHandle)
-       || tpm_unmarshal_TPM_ENCAUTH(&ptr, &len, &encAuth)
-       || tpm_unmarshal_UINT32(&ptr, &len, &pcrInfoSize)
--      || tpm_unmarshal_TPM_PCR_INFO(&ptr, &len, &pcrInfo)
-+      || (pcrInfoSize > 0 && tpm_unmarshal_TPM_PCR_INFO(&ptr, &len,
&pcrInfo))
-       || tpm_unmarshal_UINT32(&ptr, &len, &inDataSize)
-       || tpm_unmarshal_BLOB(&ptr, &len, &inData, inDataSize)
-       || len !=3D 0) return TPM_BAD_PARAMETER;
-diff -uprN orig/tpm_emulator-0.4/tpm/tpm_credentials.c
tpm_emulator/tpm/tpm_credentials.c
---- orig/tpm_emulator-0.4/tpm/tpm_credentials.c    2006-06-23
19:37:07.000000000 +0900
-+++ tpm_emulator/tpm/tpm_credentials.c    2007-09-12 20:23:30.000000000
+0900
-@@ -47,20 +47,20 @@ int tpm_compute_pubkey_checksum(TPM_NONC
-
- TPM_RESULT tpm_get_pubek(TPM_PUBKEY *pubEndorsementKey)
- {
--  UINT32 key_length;
-+  size_t key_length;
-   if (!tpmData.permanent.data.endorsementKey.size) return
TPM_NO_ENDORSEMENT;
-   /* setup TPM_PUBKEY structure */
--  key_length =3D tpmData.permanent.data.endorsementKey.size;
--  pubEndorsementKey->pubKey.keyLength =3D key_length >> 3;
-+  pubEndorsementKey->pubKey.keyLength =3D
tpmData.permanent.data.endorsementKey.size >> 3;
-   pubEndorsementKey->pubKey.key =3D
tpm_malloc(pubEndorsementKey->pubKey.keyLength);
-   if (pubEndorsementKey->pubKey.key =3D=3D NULL) return TPM_FAIL;
-   rsa_export_modulus(&tpmData.permanent.data.endorsementKey,
--    pubEndorsementKey->pubKey.key,
--    &pubEndorsementKey->pubKey.keyLength);
-+             pubEndorsementKey->pubKey.key,
-+             &key_length);
-+  pubEndorsementKey->pubKey.keyLength =3D key_length;
-   pubEndorsementKey->algorithmParms.algorithmID =3D TPM_ALG_RSA;
-   pubEndorsementKey->algorithmParms.encScheme =3D
TPM_ES_RSAESOAEP_SHA1_MGF1;
-   pubEndorsementKey->algorithmParms.sigScheme =3D TPM_SS_NONE;
--  pubEndorsementKey->algorithmParms.parms.rsa.keyLength =3D key_length;=

-+  pubEndorsementKey->algorithmParms.parms.rsa.keyLength =3D key_length =
<< 3;
-   pubEndorsementKey->algorithmParms.parms.rsa.numPrimes =3D 2;
-   pubEndorsementKey->algorithmParms.parms.rsa.exponentSize =3D 0;
-   pubEndorsementKey->algorithmParms.parms.rsa.exponent =3D NULL;
-@@ -175,6 +175,7 @@ TPM_RESULT TPM_OwnerReadInternalPub(TPM_
- {
-   TPM_RESULT res;
-   TPM_KEY_DATA *srk =3D &tpmData.permanent.data.srk;
-+  size_t key_length;
-   info("TPM_OwnerReadInternalPub()");
-   /* verify authorization */
-   res =3D tpm_verify_auth(auth1, tpmData.permanent.data.ownerAuth,
TPM_KH_OWNER);
-@@ -186,7 +187,8 @@ TPM_RESULT TPM_OwnerReadInternalPub(TPM_
-     publicPortion->pubKey.key =3D
tpm_malloc(publicPortion->pubKey.keyLength);
-     if (publicPortion->pubKey.key =3D=3D NULL) return TPM_FAIL;
-     rsa_export_modulus(&srk->key, publicPortion->pubKey.key,
--      &publicPortion->pubKey.keyLength);
-+      &key_length);
-+    publicPortion->pubKey.keyLength =3D key_length;
-     publicPortion->algorithmParms.algorithmID =3D TPM_ALG_RSA;
-     publicPortion->algorithmParms.encScheme =3D srk->encScheme;
-     publicPortion->algorithmParms.sigScheme =3D srk->sigScheme;
-diff -uprN orig/tpm_emulator-0.4/tpm/tpm_crypto.c
tpm_emulator/tpm/tpm_crypto.c
---- orig/tpm_emulator-0.4/tpm/tpm_crypto.c    2006-06-23
03:37:07.000000000 -0700
-+++ tpm_emulator/tpm/tpm_crypto.c    2006-07-24 14:35:35.000000000 -0700=

-@@ -182,7 +182,8 @@ TPM_RESULT TPM_CertifyKey(TPM_KEY_HANDLE
-   TPM_KEY_DATA *cert, *key;
-   sha1_ctx_t sha1_ctx;
-   BYTE *buf, *p;
--  UINT32 length;
-+  UINT32 length32;
-+  size_t length;
-   info("TPM_CertifyKey()");
-   /* get keys */
-   cert =3D tpm_get_key(certHandle);
-@@ -264,14 +265,15 @@ TPM_RESULT TPM_CertifyKey(TPM_KEY_HANDLE
-   /* compute the digest of the CERTIFY_INFO[2] structure and sign it */=

-   length =3D sizeof_TPM_CERTIFY_INFO((*certifyInfo));
-   p =3D buf =3D tpm_malloc(length);
-+  length32=3D(UINT32) length;
-   if (buf =3D=3D NULL
--      || tpm_marshal_TPM_CERTIFY_INFO(&p, &length, certifyInfo)) {
-+      || tpm_marshal_TPM_CERTIFY_INFO(&p, &length32, certifyInfo)) {
-     free_TPM_KEY_PARMS(certifyInfo->algorithmParms);
-     return TPM_FAIL;
-   }
-   length =3D sizeof_TPM_CERTIFY_INFO((*certifyInfo));
-   sha1_init(&sha1_ctx);
--  sha1_update(&sha1_ctx, buf, length);
-+  sha1_update(&sha1_ctx, buf, (size_t) length);
-   sha1_final(&sha1_ctx, buf);
-   res =3D tpm_sign(cert, auth1, FALSE, buf, SHA1_DIGEST_LENGTH, outData=
,
outDataSize);
-   tpm_free(buf);
-@@ -292,7 +294,8 @@ TPM_RESULT TPM_CertifyKey2(TPM_KEY_HANDL
-   TPM_KEY_DATA *cert, *key;
-   sha1_ctx_t sha1_ctx;
-   BYTE *buf, *p;
--  UINT32 length;
-+  size_t length;
-+  UINT32 length32;
-   info("TPM_CertifyKey2()");
-   /* get keys */
-   cert =3D tpm_get_key(certHandle);
-@@ -362,8 +365,9 @@ TPM_RESULT TPM_CertifyKey2(TPM_KEY_HANDL
-   /* compute the digest of the CERTIFY_INFO[2] structure and sign it */=

-   length =3D sizeof_TPM_CERTIFY_INFO((*certifyInfo));
-   p =3D buf =3D tpm_malloc(length);
-+  length32 =3D (UINT32) length;
-   if (buf =3D=3D NULL
--      || tpm_marshal_TPM_CERTIFY_INFO(&p, &length, certifyInfo)) {
-+      || tpm_marshal_TPM_CERTIFY_INFO(&p, &length32, certifyInfo)) {
-     free_TPM_KEY_PARMS(certifyInfo->algorithmParms);
-     return TPM_FAIL;
-   }
-diff -uprN orig/tpm_emulator-0.4/tpm/tpm_daa.c tpm_emulator/tpm/tpm_daa.=
c
---- orig/tpm_emulator-0.4/tpm/tpm_daa.c    2006-06-23
03:37:07.000000000 -0700
-+++ tpm_emulator/tpm/tpm_daa.c    2006-07-24 14:35:35.000000000 -0700
-@@ -716,14 +716,14 @@ TPM_RESULT TPM_DAA_Join(TPM_HANDLE handl
-           sizeof(session->DAA_tpmSpecific.DAA_rekey));
-       sha1_update(&sha1, (BYTE*) &session->DAA_tpmSpecific.DAA_count,
-           sizeof(session->DAA_tpmSpecific.DAA_count));
--      sha1_update(&sha1, "\x00", 1);
-+      sha1_update(&sha1, (BYTE *) "\x00", 1);
-       sha1_final(&sha1, scratch);
-       sha1_init(&sha1);
-       sha1_update(&sha1, (BYTE*) &session->DAA_tpmSpecific.DAA_rekey,
-           sizeof(session->DAA_tpmSpecific.DAA_rekey));
-       sha1_update(&sha1, (BYTE*) &session->DAA_tpmSpecific.DAA_count,
-           sizeof(session->DAA_tpmSpecific.DAA_count));
--      sha1_update(&sha1, "\x01", 1);
-+      sha1_update(&sha1, (BYTE *) "\x01", 1);
-       sha1_final(&sha1, scratch + SHA1_DIGEST_LENGTH);
-       mpz_init(f), mpz_init(q);
-       mpz_import(f, 2 * SHA1_DIGEST_LENGTH, 1, 1, 0, 0, scratch);
-@@ -805,14 +805,14 @@ TPM_RESULT TPM_DAA_Join(TPM_HANDLE handl
-           sizeof(session->DAA_tpmSpecific.DAA_rekey));
-       sha1_update(&sha1, (BYTE*) &session->DAA_tpmSpecific.DAA_count,
-           sizeof(session->DAA_tpmSpecific.DAA_count));
--      sha1_update(&sha1, "\x00", 1);
-+      sha1_update(&sha1, (BYTE *) "\x00", 1);
-       sha1_final(&sha1, scratch);
-       sha1_init(&sha1);
-       sha1_update(&sha1, (BYTE*) &session->DAA_tpmSpecific.DAA_rekey,
-           sizeof(session->DAA_tpmSpecific.DAA_rekey));
-       sha1_update(&sha1, (BYTE*) &session->DAA_tpmSpecific.DAA_count,
-           sizeof(session->DAA_tpmSpecific.DAA_count));
--      sha1_update(&sha1, "\x01", 1);
-+      sha1_update(&sha1, (BYTE *) "\x01", 1);
-       sha1_final(&sha1, scratch + SHA1_DIGEST_LENGTH);
-       mpz_init(f), mpz_init(q);
-       mpz_import(f, 2 * SHA1_DIGEST_LENGTH, 1, 1, 0, 0, scratch);
-@@ -1489,14 +1489,14 @@ TPM_RESULT TPM_DAA_Join(TPM_HANDLE handl
-           sizeof(session->DAA_tpmSpecific.DAA_rekey));
-       sha1_update(&sha1, (BYTE*) &session->DAA_tpmSpecific.DAA_count,
-           sizeof(session->DAA_tpmSpecific.DAA_count));
--      sha1_update(&sha1, "\x00", 1);
-+      sha1_update(&sha1, (BYTE *) "\x00", 1);
-       sha1_final(&sha1, scratch);
-       sha1_init(&sha1);
-       sha1_update(&sha1, (BYTE*) &session->DAA_tpmSpecific.DAA_rekey,
-           sizeof(session->DAA_tpmSpecific.DAA_rekey));
-       sha1_update(&sha1, (BYTE*) &session->DAA_tpmSpecific.DAA_count,
-           sizeof(session->DAA_tpmSpecific.DAA_count));
--      sha1_update(&sha1, "\x01", 1);
-+      sha1_update(&sha1, (BYTE *) "\x01", 1);
-       sha1_final(&sha1, scratch + SHA1_DIGEST_LENGTH);
-       mpz_init(f), mpz_init(q);
-       mpz_import(f, 2 * SHA1_DIGEST_LENGTH, 1, 1, 0, 0, scratch);
-@@ -1712,14 +1712,14 @@ TPM_RESULT TPM_DAA_Join(TPM_HANDLE handl
-           sizeof(session->DAA_tpmSpecific.DAA_rekey));
-       sha1_update(&sha1, (BYTE*) &session->DAA_tpmSpecific.DAA_count,
-           sizeof(session->DAA_tpmSpecific.DAA_count));
--      sha1_update(&sha1, "\x00", 1);
-+      sha1_update(&sha1, (BYTE *) "\x00", 1);
-       sha1_final(&sha1, scratch);
-       sha1_init(&sha1);
-       sha1_update(&sha1, (BYTE*) &session->DAA_tpmSpecific.DAA_rekey,
-           sizeof(session->DAA_tpmSpecific.DAA_rekey));
-       sha1_update(&sha1, (BYTE*) &session->DAA_tpmSpecific.DAA_count,
-           sizeof(session->DAA_tpmSpecific.DAA_count));
--      sha1_update(&sha1, "\x01", 1);
-+      sha1_update(&sha1, (BYTE *) "\x01", 1);
-       sha1_final(&sha1, scratch + SHA1_DIGEST_LENGTH);
-       mpz_init(f), mpz_init(q);
-       mpz_import(f, 2 * SHA1_DIGEST_LENGTH, 1, 1, 0, 0, scratch);
-@@ -1793,14 +1793,14 @@ TPM_RESULT TPM_DAA_Join(TPM_HANDLE handl
-           sizeof(session->DAA_tpmSpecific.DAA_rekey));
-       sha1_update(&sha1, (BYTE*) &session->DAA_tpmSpecific.DAA_count,
-           sizeof(session->DAA_tpmSpecific.DAA_count));
--      sha1_update(&sha1, "\x00", 1);
-+      sha1_update(&sha1, (BYTE *) "\x00", 1);
-       sha1_final(&sha1, scratch);
-       sha1_init(&sha1);
-       sha1_update(&sha1, (BYTE*) &session->DAA_tpmSpecific.DAA_rekey,
-           sizeof(session->DAA_tpmSpecific.DAA_rekey));
-       sha1_update(&sha1, (BYTE*) &session->DAA_tpmSpecific.DAA_count,
-           sizeof(session->DAA_tpmSpecific.DAA_count));
--      sha1_update(&sha1, "\x01", 1);
-+      sha1_update(&sha1, (BYTE *) "\x01", 1);
-       sha1_final(&sha1, scratch + SHA1_DIGEST_LENGTH);
-       mpz_init(f), mpz_init(q);
-       mpz_import(f, 2 * SHA1_DIGEST_LENGTH, 1, 1, 0, 0, scratch);
-@@ -2918,14 +2918,14 @@ TPM_RESULT TPM_DAA_Sign(TPM_HANDLE handl
-           sizeof(session->DAA_tpmSpecific.DAA_rekey));
-       sha1_update(&sha1, (BYTE*) &session->DAA_tpmSpecific.DAA_count,
-           sizeof(session->DAA_tpmSpecific.DAA_count));
--      sha1_update(&sha1, "\x00", 1);
-+      sha1_update(&sha1, (BYTE *) "\x00", 1);
-       sha1_final(&sha1, scratch);
-       sha1_init(&sha1);
-       sha1_update(&sha1, (BYTE*) &session->DAA_tpmSpecific.DAA_rekey,
-           sizeof(session->DAA_tpmSpecific.DAA_rekey));
-       sha1_update(&sha1, (BYTE*) &session->DAA_tpmSpecific.DAA_count,
-           sizeof(session->DAA_tpmSpecific.DAA_count));
--      sha1_update(&sha1, "\x01", 1);
-+      sha1_update(&sha1, (BYTE *) "\x01", 1);
-       sha1_final(&sha1, scratch + SHA1_DIGEST_LENGTH);
-       mpz_init(f), mpz_init(q);
-       mpz_import(f, 2 * SHA1_DIGEST_LENGTH, 1, 1, 0, 0, scratch);
-@@ -3143,7 +3143,7 @@ TPM_RESULT TPM_DAA_Sign(TPM_HANDLE handl
-         sha1_init(&sha1);
-         sha1_update(&sha1, (BYTE*) &session->DAA_session.DAA_digest,
-           sizeof(session->DAA_session.DAA_digest));
--        sha1_update(&sha1, "\x01", 1);
-+        sha1_update(&sha1, (BYTE *) "\x01", 1);
-         sha1_update(&sha1, inputData1, inputSize1);
-         sha1_final(&sha1, (BYTE*) &session->DAA_session.DAA_digest);
-       }
-@@ -3172,7 +3172,7 @@ TPM_RESULT TPM_DAA_Sign(TPM_HANDLE handl
-         sha1_init(&sha1);
-         sha1_update(&sha1, (BYTE*) &session->DAA_session.DAA_digest,
-           sizeof(session->DAA_session.DAA_digest));
--        sha1_update(&sha1, "\x00", 1);
-+        sha1_update(&sha1, (BYTE*) "\x00", 1);
-         rsa_export_modulus(&aikData->key, scratch, &size);
-         sha1_update(&sha1, scratch, size);
-         sha1_final(&sha1, (BYTE*) &session->DAA_session.DAA_digest);
-@@ -3229,14 +3229,14 @@ TPM_RESULT TPM_DAA_Sign(TPM_HANDLE handl
-           sizeof(session->DAA_tpmSpecific.DAA_rekey));
-       sha1_update(&sha1, (BYTE*) &session->DAA_tpmSpecific.DAA_count,
-           sizeof(session->DAA_tpmSpecific.DAA_count));
--      sha1_update(&sha1, "\x00", 1);
-+      sha1_update(&sha1, (BYTE *) "\x00", 1);
-       sha1_final(&sha1, scratch);
-       sha1_init(&sha1);
-       sha1_update(&sha1, (BYTE*) &session->DAA_tpmSpecific.DAA_rekey,
-           sizeof(session->DAA_tpmSpecific.DAA_rekey));
-       sha1_update(&sha1, (BYTE*) &session->DAA_tpmSpecific.DAA_count,
-           sizeof(session->DAA_tpmSpecific.DAA_count));
--      sha1_update(&sha1, "\x01", 1);
-+      sha1_update(&sha1, (BYTE *) "\x01", 1);
-       sha1_final(&sha1, scratch + SHA1_DIGEST_LENGTH);
-       mpz_init(f), mpz_init(q);
-       mpz_import(f, 2 * SHA1_DIGEST_LENGTH, 1, 1, 0, 0, scratch);
-@@ -3309,14 +3309,14 @@ TPM_RESULT TPM_DAA_Sign(TPM_HANDLE handl
-           sizeof(session->DAA_tpmSpecific.DAA_rekey));
-       sha1_update(&sha1, (BYTE*) &session->DAA_tpmSpecific.DAA_count,
-           sizeof(session->DAA_tpmSpecific.DAA_count));
--      sha1_update(&sha1, "\x00", 1);
-+      sha1_update(&sha1, (BYTE *) "\x00", 1);
-       sha1_final(&sha1, scratch);
-       sha1_init(&sha1);
-       sha1_update(&sha1, (BYTE*) &session->DAA_tpmSpecific.DAA_rekey,
-           sizeof(session->DAA_tpmSpecific.DAA_rekey));
-       sha1_update(&sha1, (BYTE*) &session->DAA_tpmSpecific.DAA_count,
-           sizeof(session->DAA_tpmSpecific.DAA_count));
--      sha1_update(&sha1, "\x01", 1);
-+      sha1_update(&sha1, (BYTE *) "\x01", 1);
-       sha1_final(&sha1, scratch + SHA1_DIGEST_LENGTH);
-       mpz_init(f), mpz_init(q);
-       mpz_import(f, 2 * SHA1_DIGEST_LENGTH, 1, 1, 0, 0, scratch);
-diff -uprN orig/tpm_emulator-0.4/tpm/tpm_data.c tpm_emulator/tpm/tpm_dat=
a.c
---- orig/tpm_emulator-0.4/tpm/tpm_data.c    2006-06-23
03:37:07.000000000 -0700
-+++ tpm_emulator/tpm/tpm_data.c    2006-07-24 14:35:35.000000000 -0700
-@@ -40,6 +40,7 @@ static inline void init_pcr_attr(int pcr
- void tpm_init_data(void)
- {
-   /* endorsement key */
-+#ifndef TPM_GENERATE_EK
-   uint8_t ek_n[] =3D=20
"\xa8\xdb\xa9\x42\xa8\xf3\xb8\x06\x85\x90\x76\x93\xad\xf7"
-     "\x74\xec\x3f\xd3\x3d\x9d\xe8\x2e\xff\x15\xed\x0e\xce\x5f\x93"
-     "\x92\xeb\xd1\x96\x2b\x72\x18\x81\x79\x12\x9d\x9c\x40\xd7\x1a"
-@@ -77,6 +78,8 @@ void tpm_init_data(void)
-     "\xd1\xc0\x8b\x5b\xa2\x2e\xa7\x15\xca\x50\x75\x10\x48\x9c\x2b"
-     "\x18\xb9\x67\x8f\x5d\x64\xc3\x28\x9f\x2f\x16\x2f\x08\xda\x47"
-     "\xec\x86\x43\x0c\x80\x99\x07\x34\x0f";
-+#endif
-+
-   int i;
-   /* reset all data to NULL, FALSE or 0 */
-   memset(&tpmData, 0, sizeof(tpmData));
-@@ -152,44 +155,43 @@ void tpm_release_data(void)
-
- #ifdef TPM_STORE_TO_FILE
-
--#include <linux/fs.h>
--#include <linux/unistd.h>
--#include <asm/uaccess.h>
-+#include <sys/types.h>
-+#include <sys/stat.h>
-+#include <fcntl.h>
-+#include <unistd.h>
-
- #define TPM_STORAGE_FILE "/var/tpm/tpm_emulator-1.2."
STR(VERSION_MAJOR) "." STR(VERSION_MINOR)
-
- static int write_to_file(uint8_t *data, size_t data_length)
- {
-   int res;
--  struct file *fp;
--  mm_segment_t old_fs =3D get_fs();
--  fp =3D filp_open(TPM_STORAGE_FILE, O_WRONLY | O_TRUNC | O_CREAT,
S_IRUSR | S_IWUSR);
--  if (IS_ERR(fp)) return -1;
--  set_fs(get_ds());
--  res =3D fp->f_op->write(fp, data, data_length, &fp->f_pos);
--  set_fs(old_fs);
--  filp_close(fp, NULL);
-+  int fp;
-+  fp =3D open(TPM_STORAGE_FILE, O_WRONLY | O_TRUNC | O_CREAT, S_IRUSR |=

S_IWUSR);
-+  res =3D write(fp, data, data_length);
-+  close(fp);
-   return (res =3D=3D data_length) ? 0 : -1;
- }
-
- static int read_from_file(uint8_t **data, size_t *data_length)
- {
-   int res;
--  struct file *fp;
--  mm_segment_t old_fs =3D get_fs();
--  fp =3D filp_open(TPM_STORAGE_FILE, O_RDONLY, 0);
--  if (IS_ERR(fp)) return -1;
--  *data_length =3D (size_t)fp->f_dentry->d_inode->i_size;
--  /* *data_length =3D i_size_read(fp->f_dentry->d_inode); */
-+  int fp, file_status;
-+  struct stat file_info;
-+  fp =3D open(TPM_STORAGE_FILE, O_RDONLY, 0);
-+  file_status =3D fstat(fp, &file_info);
-+  if (file_status < 0) {
-+    close(fp);
-+    return -1;
-+  }
-+
-+  *data_length =3D file_info.st_size;
-   *data =3D tpm_malloc(*data_length);
-   if (*data =3D=3D NULL) {
--    filp_close(fp, NULL);
-+    close(fp);
-     return -1;
-   }
--  set_fs(get_ds());
--  res =3D fp->f_op->read(fp, *data, *data_length, &fp->f_pos);
--  set_fs(old_fs);
--  filp_close(fp, NULL);
-+  res =3D read(fp, *data, *data_length);
-+  close(fp);
-   if (res !=3D *data_length) {
-     tpm_free(*data);
-     return -1;
-@@ -216,23 +218,30 @@ static int read_from_file(uint8_t **data
- int tpm_store_permanent_data(void)
- {
-   uint8_t *buf, *ptr;
--  size_t buf_length, len;
-+  UINT32 buf_length, len;
-
-   /* marshal data */
--  buf_length =3D len =3D sizeof_TPM_STCLEAR_FLAGS(tpmData.stclear.flags=
)
--    + sizeof_TPM_PERMANENT_FLAGS(tpmData.permanent.flags) + 2
--    + sizeof_TPM_PERMANENT_DATA(tpmData.permanent.data);
-+  buf_length =3D len =3D 4 + sizeof_TPM_STCLEAR_FLAGS(tpmData.stclear.f=
lags)
-+    + sizeof_TPM_PERMANENT_FLAGS(tpmData.permanent.flags)
-+    + sizeof_TPM_STANY_FLAGS(tpmData.stany.flags) + 2
-+    + sizeof_TPM_STCLEAR_DATA(tpmData.stclear.data)
-+    + sizeof_TPM_PERMANENT_DATA(tpmData.permanent.data)
-+    + sizeof_TPM_STANY_DATA(tpmData.stany.data);
-   buf =3D ptr =3D tpm_malloc(buf_length);
-   if (buf =3D=3D NULL
-       || tpm_marshal_TPM_VERSION(&ptr, &len,
&tpmData.permanent.data.version)
-       || tpm_marshal_TPM_STCLEAR_FLAGS(&ptr, &len, &tpmData.stclear.fla=
gs)
-       || tpm_marshal_TPM_PERMANENT_FLAGS(&ptr, &len,
&tpmData.permanent.flags)
-+      || tpm_marshal_TPM_STANY_FLAGS(&ptr, &len, &tpmData.stany.flags)
-       || tpm_marshal_BOOL(&ptr, &len,
tpmData.permanent.flags.selfTestSucceeded)
-       || tpm_marshal_BOOL(&ptr, &len, tpmData.permanent.flags.owned)
--      || tpm_marshal_TPM_PERMANENT_DATA(&ptr, &len,
&tpmData.permanent.data)) {
-+      || tpm_marshal_TPM_STCLEAR_DATA(&ptr, &len, &tpmData.stclear.data=
)
-+      || tpm_marshal_TPM_PERMANENT_DATA(&ptr, &len,
&tpmData.permanent.data)
-+      || tpm_marshal_TPM_STANY_DATA(&ptr, &len, &tpmData.stany.data)) {=

-     tpm_free(buf);
-     return -1;
-   }
-+
-   if (write_to_file(buf, buf_length - len)) {
-     tpm_free(buf);
-     return -1;
-@@ -244,31 +253,36 @@ int tpm_store_permanent_data(void)
- int tpm_restore_permanent_data(void)
- {
-   uint8_t *buf, *ptr;
--  size_t buf_length, len;
-+  size_t buf_length;
-+  UINT32 len;
-   TPM_VERSION ver;
-
-   /* read data */
-   if (read_from_file(&buf, &buf_length)) return -1;
-   ptr =3D buf;
--  len =3D buf_length;
-+  len =3D (uint32_t) buf_length;
-   /* unmarshal data */
-   if (tpm_unmarshal_TPM_VERSION(&ptr, &len, &ver)
-       || memcmp(&ver, &tpmData.permanent.data.version,
sizeof(TPM_VERSION))
-       || tpm_unmarshal_TPM_STCLEAR_FLAGS(&ptr, &len,
&tpmData.stclear.flags)
-       || tpm_unmarshal_TPM_PERMANENT_FLAGS(&ptr, &len,
&tpmData.permanent.flags)
-+      || tpm_unmarshal_TPM_STANY_FLAGS(&ptr, &len, &tpmData.stany.flags=
)
-       || tpm_unmarshal_BOOL(&ptr, &len,
&tpmData.permanent.flags.selfTestSucceeded)
-       || tpm_unmarshal_BOOL(&ptr, &len, &tpmData.permanent.flags.owned)=

--      || tpm_unmarshal_TPM_PERMANENT_DATA(&ptr, &len,
&tpmData.permanent.data)) {
-+      || tpm_unmarshal_TPM_STCLEAR_DATA(&ptr, &len, &tpmData.stclear.da=
ta)
-+      || tpm_unmarshal_TPM_PERMANENT_DATA(&ptr, &len,
&tpmData.permanent.data)
-+      || tpm_unmarshal_TPM_STANY_DATA(&ptr, &len, &tpmData.stany.data))=
 {
-     tpm_free(buf);
-     return -1;
-   }
-+
-   tpm_free(buf);
-   return 0;
- }
-
- int tpm_erase_permanent_data(void)
- {
--  int res =3D write_to_file("", 0);
-+  int res =3D write_to_file((uint8_t *) "", 0);
-   return res;
- }
-
-diff -uprN orig/tpm_emulator-0.4/tpm/tpm_deprecated.c
tpm_emulator/tpm/tpm_deprecated.c
---- orig/tpm_emulator-0.4/tpm/tpm_deprecated.c    2006-06-23
03:37:07.000000000 -0700
-+++ tpm_emulator/tpm/tpm_deprecated.c    2006-07-24 14:35:35.000000000
-0700
-@@ -1,6 +1,7 @@
- /* Software-Based Trusted Platform Module (TPM) Emulator for Linux
-  * Copyright (C) 2004 Mario Strasser <mast@gmx.net>,
-  *                    Swiss Federal Institute of Technology (ETH) Zuric=
h
-+ * Copyright (C) 2005 INTEL Corp
-  *
-  * This module is free software; you can redistribute it and/or modify
-  * it under the terms of the GNU General Public License as published
-@@ -50,7 +51,7 @@ TPM_RESULT TPM_SaveKeyContext(TPM_KEY_HA
-   BYTE *ptr;
-   UINT32 len;
-   info("TPM_SaveKeyContext()");
--  res =3D TPM_SaveContext(keyHandle, TPM_RT_KEY, "SaveKeyContext..",
-+  res =3D TPM_SaveContext(keyHandle, TPM_RT_KEY, (BYTE*)"SaveKeyContext=
=2E.",
-                         keyContextSize, &contextBlob);
-   if (res !=3D TPM_SUCCESS) return res;
-   len =3D *keyContextSize;
-@@ -82,7 +83,7 @@ TPM_RESULT TPM_SaveAuthContext(TPM_AUTHH
-   BYTE *ptr;
-   UINT32 len;
-   info("TPM_SaveAuthContext()");
--  res =3D TPM_SaveContext(authHandle, TPM_RT_KEY, "SaveAuthContext.",
-+  res =3D TPM_SaveContext(authHandle, TPM_RT_KEY,
(BYTE*)"SaveAuthContext.",
-                         authContextSize, &contextBlob);
-   if (res !=3D TPM_SUCCESS) return res;
-   len =3D *authContextSize;
-diff -uprN orig/tpm_emulator-0.4/tpm/tpm_emulator.h
tpm_emulator/tpm/tpm_emulator.h
---- orig/tpm_emulator-0.4/tpm/tpm_emulator.h    2006-06-23
03:37:07.000000000 -0700
-+++ tpm_emulator/tpm/tpm_emulator.h    2006-07-24 14:35:35.000000000 -07=
00
-@@ -1,5 +1,6 @@
- /* Software-Based Trusted Platform Module (TPM) Emulator for Linux
-  * Copyright (C) 2004 Mario Strasser <mast@gmx.net>,
-+ * Copyright (C) 2005 INTEL Corp
-  *
-  * This module is free software; you can redistribute it and/or modify
-  * it under the terms of the GNU General Public License as published
-@@ -22,7 +23,8 @@
- /* TPM configuration */
- #define TPM_STORE_TO_FILE       1
- #undef  TPM_STRONG_PERSISTENCE
--#undef  TPM_GENERATE_EK
-+//#undef  TPM_GENERATE_EK
-+#define  TPM_GENERATE_EK
- #undef  TPM_GENERATE_SEED_DAA
-
- #define TPM_MANUFACTURER 0x4554485A /* 'ETHZ' */      =20
-diff -uprN orig/tpm_emulator-0.4/tpm/tpm_marshalling.c
tpm_emulator/tpm/tpm_marshalling.c
---- orig/tpm_emulator-0.4/tpm/tpm_marshalling.c    2006-06-23
03:37:07.000000000 -0700
-+++ tpm_emulator/tpm/tpm_marshalling.c    2006-07-24 14:35:35.000000000
-0700
-@@ -1312,7 +1312,7 @@ int tpm_unmarshal_TPM_STANY_FLAGS(BYTE *
-
- int tpm_marshal_RSA(BYTE **ptr, UINT32 *length, rsa_private_key_t *v)
- {
--  UINT32 m_len, e_len, q_len;
-+  size_t m_len, e_len, q_len;
-   if (*length < sizeof_RSA((*v))) return -1;
-   if (v->size > 0) {
-     rsa_export_modulus(v, &(*ptr)[6], &m_len);
-@@ -1460,6 +1460,66 @@ int tpm_unmarshal_TPM_PERMANENT_DATA(BYT
-   return 0;
- }
-
-+int tpm_marshal_TPM_STCLEAR_DATA(BYTE **ptr, UINT32 *length,
TPM_STCLEAR_DATA *v)
-+{
-+  if (tpm_marshal_TPM_STRUCTURE_TAG(ptr, length, v->tag)
-+    || tpm_marshal_TPM_NONCE(ptr, length, &v->contextNonceKey)
-+    || tpm_marshal_TPM_COUNT_ID(ptr, length, v->countID) ) return -1;
-+
-+  return 0;
-+}
-+
-+int tpm_unmarshal_TPM_STCLEAR_DATA(BYTE **ptr, UINT32 *length,
TPM_STCLEAR_DATA *v)
-+{
-+  if (tpm_unmarshal_TPM_STRUCTURE_TAG(ptr, length, &v->tag)
-+    || tpm_unmarshal_TPM_NONCE(ptr, length, &v->contextNonceKey)
-+    || tpm_unmarshal_TPM_COUNT_ID(ptr, length, &v->countID) ) return -1=
;
-+
-+  return 0;
-+}
-+
-+int tpm_marshal_TPM_STANY_DATA(BYTE **ptr, UINT32 *length,
TPM_STANY_DATA *v)
-+{
-+  UINT32 i;
-+  if (tpm_marshal_TPM_STRUCTURE_TAG(ptr, length, v->tag)
-+    || tpm_marshal_TPM_NONCE(ptr, length, &v->contextNonceSession)
-+    || tpm_marshal_TPM_DIGEST(ptr, length, &v->auditDigest)
-+    || tpm_marshal_BOOL(ptr, length, v->auditSession)
-+    || tpm_marshal_TPM_CURRENT_TICKS(ptr, length, &v->currentTicks)
-+    || tpm_marshal_UINT32(ptr, length, v->contextCount)
-+    || tpm_marshal_UINT32_ARRAY(ptr, length, v->contextList,
TPM_MAX_SESSION_LIST)) return -1;
-+  for (i =3D 0; i < TPM_MAX_SESSIONS; i++) {
-+    if (tpm_marshal_TPM_SESSION_DATA(ptr, length, &v->sessions[i]))
return -1;
-+  }
-+  for (i =3D 0; i < TPM_MAX_SESSIONS_DAA; i++) {
-+    if (tpm_marshal_TPM_DAA_SESSION_DATA(ptr, length,
&v->sessionsDAA[i])) return -1;
-+  }
-+  if (tpm_marshal_TPM_TRANSHANDLE(ptr, length, v->transExclusive))
return -1;
-+
-+  return 0;
-+}
-+
-+int tpm_unmarshal_TPM_STANY_DATA(BYTE **ptr, UINT32 *length,
TPM_STANY_DATA *v)
-+{
-+  UINT32 i;
-+  if (tpm_unmarshal_TPM_STRUCTURE_TAG(ptr, length, &v->tag)
-+    || tpm_unmarshal_TPM_NONCE(ptr, length, &v->contextNonceSession)
-+    || tpm_unmarshal_TPM_DIGEST(ptr, length, &v->auditDigest)
-+    || tpm_unmarshal_BOOL(ptr, length, &v->auditSession)
-+    || tpm_unmarshal_TPM_CURRENT_TICKS(ptr, length, &v->currentTicks)
-+    || tpm_unmarshal_UINT32(ptr, length, &v->contextCount)
-+    || tpm_unmarshal_UINT32_ARRAY(ptr, length, v->contextList,
TPM_MAX_SESSION_LIST)) return -1;
-+  for (i =3D 0; i < TPM_MAX_SESSIONS; i++) {
-+    if (tpm_unmarshal_TPM_SESSION_DATA(ptr, length, &v->sessions[i]))
return -1;
-+  }
-+  for (i =3D 0; i < TPM_MAX_SESSIONS_DAA; i++) {
-+    if (tpm_unmarshal_TPM_DAA_SESSION_DATA(ptr, length,
&v->sessionsDAA[i])) return -1;
-+  }
-+  if (tpm_unmarshal_TPM_TRANSHANDLE(ptr, length, &v->transExclusive))
return -1;
-+
-+  return 0;
-+}
-+
- int tpm_marshal_TPM_SESSION_DATA(BYTE **ptr, UINT32 *length,
TPM_SESSION_DATA *v)
- {
-   if (tpm_marshal_BYTE(ptr, length, v->type)
-diff -uprN orig/tpm_emulator-0.4/tpm/tpm_marshalling.h
tpm_emulator/tpm/tpm_marshalling.h
---- orig/tpm_emulator-0.4/tpm/tpm_marshalling.h    2006-06-23
03:37:07.000000000 -0700
-+++ tpm_emulator/tpm/tpm_marshalling.h    2006-07-24 14:35:35.000000000
-0700
-@@ -432,6 +432,12 @@ int tpm_unmarshal_TPM_KEY_DATA(BYTE **pt
- int tpm_marshal_TPM_PERMANENT_DATA(BYTE **ptr, UINT32 *length,
TPM_PERMANENT_DATA *);
- int tpm_unmarshal_TPM_PERMANENT_DATA(BYTE **ptr, UINT32 *length,
TPM_PERMANENT_DATA *);
-
-+int tpm_marshal_TPM_STCLEAR_DATA(BYTE **ptr, UINT32 *length,
TPM_STCLEAR_DATA *v);
-+int tpm_unmarshal_TPM_STCLEAR_DATA(BYTE **ptr, UINT32 *length,
TPM_STCLEAR_DATA *v);
-+
-+int tpm_marshal_TPM_STANY_DATA(BYTE **ptr, UINT32 *length,
TPM_STANY_DATA *v);
-+int tpm_unmarshal_TPM_STANY_DATA(BYTE **ptr, UINT32 *length,
TPM_STANY_DATA *v);
-+
- int tpm_marshal_TPM_SESSION_DATA(BYTE **ptr, UINT32 *length,
TPM_SESSION_DATA *v);
- int tpm_unmarshal_TPM_SESSION_DATA(BYTE **ptr, UINT32 *length,
TPM_SESSION_DATA *v);
-
-diff -uprN orig/tpm_emulator-0.4/tpm/tpm_owner.c
tpm_emulator/tpm/tpm_owner.c
---- orig/tpm_emulator-0.4/tpm/tpm_owner.c    2006-06-23
03:37:07.000000000 -0700
-+++ tpm_emulator/tpm/tpm_owner.c    2006-07-24 14:35:35.000000000 -0700
-@@ -108,7 +108,7 @@ TPM_RESULT TPM_TakeOwnership(TPM_PROTOCO
-   TPM_RESULT res;
-   rsa_private_key_t *ek =3D &tpmData.permanent.data.endorsementKey;
-   TPM_KEY_DATA *srk =3D &tpmData.permanent.data.srk;
--  UINT32 buf_size =3D ek->size >> 3;
-+  size_t buf_size =3D ek->size >> 3, key_length;
-   BYTE buf[buf_size];
-
-   info("TPM_TakeOwnership()");
-@@ -173,7 +173,8 @@ TPM_RESULT TPM_TakeOwnership(TPM_PROTOCO
-     return TPM_FAIL;
-   }
-   rsa_export_modulus(&srk->key, srkPub->pubKey.key,
--    &srkPub->pubKey.keyLength);
-+             &key_length);
-+  srkPub->pubKey.keyLength =3D (UINT32) key_length;
-   /* setup tpmProof and set state to owned */
-   tpm_get_random_bytes(tpmData.permanent.data.tpmProof.nonce,
-     sizeof(tpmData.permanent.data.tpmProof.nonce));
-diff -uprN orig/tpm_emulator-0.4/tpm/tpm_startup.c
tpm_emulator/tpm/tpm_startup.c
---- orig/tpm_emulator-0.4/tpm/tpm_startup.c    2006-06-23
03:37:07.000000000 -0700
-+++ tpm_emulator/tpm/tpm_startup.c    2006-07-24 14:35:35.000000000 -070=
0
-@@ -41,26 +41,29 @@ void TPM_Init(TPM_STARTUP_TYPE startupTy
- TPM_RESULT TPM_Startup(TPM_STARTUP_TYPE startupType)
- {
-   int i;
-+  int restore_fail;
-   info("TPM_Startup(%d)", startupType);
-   if (tpmData.stany.flags.postInitialise =3D=3D FALSE) return
TPM_INVALID_POSTINIT;
--  /* reset STANY_FLAGS */
--  SET_TO_ZERO(&tpmData.stany.flags);
--  tpmData.stany.flags.tag =3D TPM_TAG_STANY_FLAGS;
--  /* reset STANY_DATA (invalidates ALL sessions) */
--  SET_TO_ZERO(&tpmData.stany.data);
--  tpmData.stany.data.tag =3D TPM_TAG_STANY_DATA;
--  /* init session-context nonce */
--  SET_TO_RAND(&tpmData.stany.data.contextNonceSession);
-+
-+  /* try and restore state to get EK, SRK, etc */
-+  restore_fail =3D tpm_restore_permanent_data();
-+
-   /* set data and flags according to the given startup type */
-   if (startupType =3D=3D TPM_ST_CLEAR) {
--    /* if available, restore permanent data */
--    tpm_restore_permanent_data();
-+    /* reset STANY_FLAGS */
-+    SET_TO_ZERO(&tpmData.stany.flags);
-+    tpmData.stany.flags.tag =3D TPM_TAG_STANY_FLAGS;
-+    /* reset STANY_DATA (invalidates ALL sessions) */
-+    SET_TO_ZERO(&tpmData.stany.data);
-+    tpmData.stany.data.tag =3D TPM_TAG_STANY_DATA;
-+    /* init session-context nonce */
-+    SET_TO_RAND(&tpmData.stany.data.contextNonceSession);
-     /* reset PCR values */
-     for (i =3D 0; i < TPM_NUM_PCR; i++) {
--      if (tpmData.permanent.data.pcrAttrib[i].pcrReset)
--        SET_TO_ZERO(tpmData.permanent.data.pcrValue[i].digest);
-+      if (!tpmData.permanent.data.pcrAttrib[i].pcrReset)
-+        SET_TO_ZERO(&tpmData.permanent.data.pcrValue[i].digest);
-       else
--        SET_TO_0xFF(tpmData.permanent.data.pcrValue[i].digest);
-+        SET_TO_0xFF(&tpmData.permanent.data.pcrValue[i].digest);
-     }
-     /* reset STCLEAR_FLAGS */
-     SET_TO_ZERO(&tpmData.stclear.flags);
-@@ -79,7 +82,8 @@ TPM_RESULT TPM_Startup(TPM_STARTUP_TYPE
-     /* init key-context nonce */
-     SET_TO_RAND(&tpmData.stclear.data.contextNonceKey);
-   } else if (startupType =3D=3D TPM_ST_STATE) {
--    if (tpm_restore_permanent_data()) {
-+    /* restore must have been successful for TPM_ST_STATE */
-+    if (restore_fail) {
-       error("restoring permanent data failed");
-       tpmData.permanent.data.testResult =3D
"tpm_restore_permanent_data() failed";
-       tpmData.permanent.flags.selfTestSucceeded =3D FALSE;
-diff -uprN orig/tpm_emulator-0.4/tpm/tpm_storage.c
tpm_emulator/tpm/tpm_storage.c
---- orig/tpm_emulator-0.4/tpm/tpm_storage.c    2006-06-23
03:37:07.000000000 -0700
-+++ tpm_emulator/tpm/tpm_storage.c    2006-07-24 14:35:35.000000000 -070=
0
-@@ -58,6 +58,7 @@ int encrypt_sealed_data(TPM_KEY_DATA *ke
-                         BYTE *enc, UINT32 *enc_size)
- {
-   UINT32 len;
-+  size_t enc_size32 =3D *enc_size;
-   BYTE *buf, *ptr;
-   rsa_public_key_t pub_key;
-   int scheme;
-@@ -72,7 +73,7 @@ int encrypt_sealed_data(TPM_KEY_DATA *ke
-   if (buf =3D=3D NULL
-       || tpm_marshal_TPM_SEALED_DATA(&ptr, &len, seal)
-       || rsa_encrypt(&pub_key, scheme, buf,
sizeof_TPM_SEALED_DATA((*seal)),
--                     enc, enc_size)) {
-+                     enc, &enc_size32)) {
-     tpm_free(buf);
-     rsa_release_public_key(&pub_key);
-     return -1;
-@@ -85,7 +86,8 @@ int encrypt_sealed_data(TPM_KEY_DATA *ke
- int decrypt_sealed_data(TPM_KEY_DATA *key, BYTE *enc, UINT32 enc_size,
-                         TPM_SEALED_DATA *seal, BYTE **buf)
- {
--  UINT32 len;
-+  size_t len;
-+  UINT32 len32;
-   BYTE *ptr;
-   int scheme;
-   switch (key->encScheme) {
-@@ -96,8 +98,12 @@ int decrypt_sealed_data(TPM_KEY_DATA *ke
-   len =3D enc_size;
-   *buf =3D ptr =3D tpm_malloc(len);
-   if (*buf =3D=3D NULL
--      || rsa_decrypt(&key->key, scheme, enc, enc_size, *buf, &len)
--      || tpm_unmarshal_TPM_SEALED_DATA(&ptr, &len, seal)) {
-+      || rsa_decrypt(&key->key, scheme, enc, enc_size, *buf, &len) ){
-+    tpm_free(*buf);
-+    return -1;
-+  }
-+  len32 =3D len;
-+  if (tpm_unmarshal_TPM_SEALED_DATA(&ptr, &len32, seal)) {
-     tpm_free(*buf);
-     return -1;
-   }
-@@ -240,11 +246,12 @@ TPM_RESULT TPM_Unseal(TPM_KEY_HANDLE par
-
- TPM_RESULT TPM_UnBind(TPM_KEY_HANDLE keyHandle, UINT32 inDataSize,
-                       BYTE *inData, TPM_AUTH *auth1,
--                      UINT32 *outDataSize, BYTE **outData)
-+                      UINT32 *outDataSize32, BYTE **outData)
- {
-   TPM_RESULT res;
-   TPM_KEY_DATA *key;
-   int scheme;
-+  size_t outDataSize;
- =20
-   info("TPM_UnBind()");
-   /* get key */
-@@ -262,8 +269,8 @@ TPM_RESULT TPM_UnBind(TPM_KEY_HANDLE key
-   /* the size of the input data muss be greater than zero */
-   if (inDataSize =3D=3D 0) return TPM_BAD_PARAMETER;
-   /* decrypt data */
--  *outDataSize =3D inDataSize;
--  *outData =3D tpm_malloc(*outDataSize);
-+  outDataSize =3D inDataSize;
-+  *outData =3D tpm_malloc(outDataSize);
-   if (*outData =3D=3D NULL) return TPM_NOSPACE;
-   switch (key->encScheme) {
-     case TPM_ES_RSAESOAEP_SHA1_MGF1: scheme =3D RSA_ES_OAEP_SHA1; break=
;
-@@ -271,20 +278,21 @@ TPM_RESULT TPM_UnBind(TPM_KEY_HANDLE key
-     default: tpm_free(*outData); return TPM_DECRYPT_ERROR;
-   }
-   if (rsa_decrypt(&key->key, scheme, inData, inDataSize,
--      *outData, outDataSize)) {
-+      *outData, &outDataSize)) {
-     tpm_free(*outData);
-     return TPM_DECRYPT_ERROR;
-   }
-   /* verify data if it is of type TPM_BOUND_DATA */
-   if (key->encScheme =3D=3D TPM_ES_RSAESOAEP_SHA1_MGF1
-       || key->keyUsage !=3D TPM_KEY_LEGACY) {
--    if (*outDataSize < 5 || memcmp(*outData, "\x01\x01\00\x00\x02", 5)
!=3D 0) {
-+    if (outDataSize < 5 || memcmp(*outData, "\x01\x01\00\x00\x02", 5)
!=3D 0) {
-       tpm_free(*outData);
-       return TPM_DECRYPT_ERROR;
-     }
--    *outDataSize -=3D 5;
--    memmove(*outData, &(*outData)[5], *outDataSize);
-+    outDataSize -=3D 5;
-+    memmove(*outData, &(*outData)[5], outDataSize);
-   }
-+  *outDataSize32 =3D (UINT32) outDataSize;
-   return TPM_SUCCESS;
- }
-
-@@ -334,12 +342,13 @@ int compute_pubkey_digest(TPM_PUBKEY *ke
- }
-
- int encrypt_private_key(TPM_KEY_DATA *key, TPM_STORE_ASYMKEY *store,
--                        BYTE *enc, UINT32 *enc_size)
-+                        BYTE *enc, UINT32 *enc_size32)
- {
-   UINT32 len;
-   BYTE *buf, *ptr;
-   rsa_public_key_t pub_key;
-   int scheme;
-+  size_t enc_size;
-   switch (key->encScheme) {
-     case TPM_ES_RSAESOAEP_SHA1_MGF1: scheme =3D RSA_ES_OAEP_SHA1; break=
;
-     case TPM_ES_RSAESPKCSv15: scheme =3D RSA_ES_PKCSV15; break;
-@@ -351,11 +360,12 @@ int encrypt_private_key(TPM_KEY_DATA *ke
-   if (buf =3D=3D NULL
-       || tpm_marshal_TPM_STORE_ASYMKEY(&ptr, &len, store)
-       || rsa_encrypt(&pub_key, scheme, buf,
sizeof_TPM_STORE_ASYMKEY((*store)),
--                     enc, enc_size)) {
-+                     enc, &enc_size)) {
-     tpm_free(buf);
-     rsa_release_public_key(&pub_key);
-     return -1;
-   }
-+  *enc_size32 =3D (UINT32) enc_size;
-   tpm_free(buf);
-   rsa_release_public_key(&pub_key);
-   return 0;
-@@ -364,7 +374,8 @@ int encrypt_private_key(TPM_KEY_DATA *ke
- int decrypt_private_key(TPM_KEY_DATA *key, BYTE *enc, UINT32 enc_size,
-                         TPM_STORE_ASYMKEY *store, BYTE **buf)
- {
--  UINT32 len;
-+  UINT32 len32;
-+  size_t len;
-   BYTE *ptr;
-   int scheme;
-   switch (key->encScheme) {
-@@ -375,8 +386,12 @@ int decrypt_private_key(TPM_KEY_DATA *ke
-   len =3D enc_size;
-   *buf =3D ptr =3D tpm_malloc(len);
-   if (*buf =3D=3D NULL
--      || rsa_decrypt(&key->key, scheme, enc, enc_size, *buf, &len)
--      || tpm_unmarshal_TPM_STORE_ASYMKEY(&ptr, &len, store)) {
-+      || rsa_decrypt(&key->key, scheme, enc, enc_size, *buf, &len) ) {
-+    tpm_free(*buf);
-+    return -1;
-+  }
-+  len32 =3D (UINT32) len;
-+  if (tpm_unmarshal_TPM_STORE_ASYMKEY(&ptr, &len32, store)) {=20
-     tpm_free(*buf);
-     return -1;
-   }
-@@ -394,7 +409,7 @@ TPM_RESULT TPM_CreateWrapKey(TPM_KEY_HAN
-   TPM_SESSION_DATA *session;
-   TPM_STORE_ASYMKEY store;
-   rsa_private_key_t rsa;
--  UINT32 key_length;
-+  size_t key_length;
-
-   info("TPM_CreateWrapKey()");
-   /* get parent key */
-@@ -450,11 +465,11 @@ TPM_RESULT TPM_CreateWrapKey(TPM_KEY_HAN
-     }
-   }
-   /* generate key and store it */
--  key_length =3D keyInfo->algorithmParms.parms.rsa.keyLength;
--  if (rsa_generate_key(&rsa, key_length)) return TPM_FAIL;
--  wrappedKey->pubKey.keyLength =3D key_length >> 3;
-+  if (rsa_generate_key(&rsa,
keyInfo->algorithmParms.parms.rsa.keyLength))
-+    return TPM_FAIL;
-+  wrappedKey->pubKey.keyLength =3D
keyInfo->algorithmParms.parms.rsa.keyLength >> 3;
-   wrappedKey->pubKey.key =3D tpm_malloc(wrappedKey->pubKey.keyLength);
--  store.privKey.keyLength =3D key_length >> 4;
-+  store.privKey.keyLength =3D
keyInfo->algorithmParms.parms.rsa.keyLength >> 4;
-   store.privKey.key =3D tpm_malloc(store.privKey.keyLength);
-   wrappedKey->encDataSize =3D parent->key.size >> 3;
-   wrappedKey->encData =3D tpm_malloc(wrappedKey->encDataSize);
-@@ -466,9 +481,11 @@ TPM_RESULT TPM_CreateWrapKey(TPM_KEY_HAN
-     tpm_free(wrappedKey->encData);
-     return TPM_NOSPACE;
-   }
--  rsa_export_modulus(&rsa, wrappedKey->pubKey.key,
--    &wrappedKey->pubKey.keyLength);
--  rsa_export_prime1(&rsa, store.privKey.key, &store.privKey.keyLength);=

-+  rsa_export_modulus(&rsa, wrappedKey->pubKey.key,
-+             &key_length);
-+  wrappedKey->pubKey.keyLength =3D (UINT32) key_length;
-+  rsa_export_prime1(&rsa, store.privKey.key, &key_length);
-+  store.privKey.keyLength =3D (UINT32) key_length;
-   rsa_release_private_key(&rsa);
-   /* compute the digest of the wrapped key (without encData) */
-   if (compute_key_digest(wrappedKey, &store.pubDataDigest)) {
-@@ -602,6 +619,7 @@ TPM_RESULT TPM_LoadKey2(TPM_KEY_HANDLE p
-
- int tpm_setup_key_parms(TPM_KEY_DATA *key, TPM_KEY_PARMS *parms)
- {
-+  size_t key_length;
-   parms->algorithmID =3D TPM_ALG_RSA;
-   parms->encScheme =3D key->encScheme;
-   parms->sigScheme =3D key->sigScheme;
-@@ -611,7 +629,8 @@ int tpm_setup_key_parms(TPM_KEY_DATA *ke
-   parms->parms.rsa.exponent =3D tpm_malloc(parms->parms.rsa.exponentSiz=
e);
-   if (parms->parms.rsa.exponent =3D=3D NULL) return -1;
-   rsa_export_exponent(&key->key, parms->parms.rsa.exponent,
--    &parms->parms.rsa.exponentSize);
-+    &key_length);
-+  parms->parms.rsa.exponentSize =3D (UINT32) key_length;
-   parms->parmSize =3D 12 + parms->parms.rsa.exponentSize;
-   return 0;
- }
-@@ -622,6 +641,7 @@ TPM_RESULT TPM_GetPubKey(TPM_KEY_HANDLE
-   TPM_RESULT res;
-   TPM_KEY_DATA *key;
-   TPM_DIGEST digest;
-+  size_t key_length;
-   info("TPM_GetPubKey()");
-   /* get key */
-   if (keyHandle =3D=3D TPM_KH_SRK
-@@ -650,8 +670,8 @@ TPM_RESULT TPM_GetPubKey(TPM_KEY_HANDLE
-   pubKey->pubKey.keyLength =3D key->key.size >> 3;
-   pubKey->pubKey.key =3D tpm_malloc(pubKey->pubKey.keyLength);
-   if (pubKey->pubKey.key =3D=3D NULL) return TPM_NOSPACE;
--  rsa_export_modulus(&key->key, pubKey->pubKey.key,
--    &pubKey->pubKey.keyLength);
-+  rsa_export_modulus(&key->key, pubKey->pubKey.key, &key_length);
-+  pubKey->pubKey.keyLength =3D (UINT32) key_length;
-   if (tpm_setup_key_parms(key, &pubKey->algorithmParms) !=3D 0) {
-     error("TPM_GetPubKey(): tpm_setup_key_parms() failed.");
-     tpm_free(pubKey->pubKey.key);
-diff -uprN orig/tpm_emulator-0.4/tpm/tpm_structures.h
tpm_emulator/tpm/tpm_structures.h
---- orig/tpm_emulator-0.4/tpm/tpm_structures.h    2006-06-23
03:37:07.000000000 -0700
-+++ tpm_emulator/tpm/tpm_structures.h    2006-07-24 14:35:35.000000000
-0700
-@@ -1958,6 +1958,7 @@ typedef struct tdTPM_DAA_ISSUER {
-   TPM_DIGEST DAA_digest_gamma;
-   BYTE DAA_generic_q[26];
- } TPM_DAA_ISSUER;
-+#define sizeof_TPM_DAA_ISSUER(s) (2 + (20 * 6) + 26 )
-
- /*
-  * TPM_DAA_TPM ([TPM_Part2], Section 22.4)
-@@ -1973,6 +1974,7 @@ typedef struct tdTPM_DAA_TPM {
-   TPM_DIGEST DAA_rekey;
-   UINT32 DAA_count;
- } TPM_DAA_TPM;
-+#define sizeof_TPM_DAA_TPM(s) (2 + (4 * 20) + 4)
-
- /*
-  * TPM_DAA_CONTEXT ([TPM_Part2], Section 22.5)
-@@ -1987,6 +1989,7 @@ typedef struct tdTPM_DAA_CONTEXT {
-   BYTE DAA_scratch[256];
-   BYTE DAA_stage;
- } TPM_DAA_CONTEXT;
-+#define sizeof_TPM_DAA_CONTEXT(s) (2 + (3 * 20) + 256 + 1)
-
- /*
-  * TPM_DAA_JOINDATA ([TPM_Part2], Section 22.6)
-@@ -1998,6 +2001,7 @@ typedef struct tdTPM_DAA_JOINDATA {
-   BYTE DAA_join_u1[138];
-   TPM_DIGEST DAA_digest_n0;
- } TPM_DAA_JOINDATA;
-+#define sizeof_TPM_DAA_JOINDATA(s) (1 + 1 + 20)
-
- /*
-  * TPM_DAA_BLOB ([TPM_Part2], Section 22.8)
-@@ -2202,6 +2206,7 @@ typedef struct tdTPM_STCLEAR_DATA {
-   //UINT32 ownerReference;
-   //BOOL disableResetLock;
- } TPM_STCLEAR_DATA;
-+#define sizeof_TPM_STCLEAR_DATA(s) (2 + 20 + 4)
-
- /*
-  * TPM_SESSION_DATA
-@@ -2238,6 +2243,11 @@ typedef struct tdTPM_DAA_SESSION_DATA {
-   TPM_DAA_JOINDATA DAA_joinSession;
-   TPM_HANDLE handle;
- } TPM_DAA_SESSION_DATA;
-+#define sizeof_TPM_DAA_SESSION_DATA(s) ( 1 \
-+  + sizeof_TPM_DAA_ISSUER(s.DAA_issuerSettings) \
-+  + sizeof_TPM_DAA_TPM(s.DAA_tpmSpecific) \
-+  + sizeof_TPM_DAA_CONTEXT(s.DAA_session) \
-+  + sizeof_TPM_DAA_JOINDATA(s.DAA_joinSession) + 4)
-
- /*
-  * TPM_STANY_DATA ([TPM_Part2], Section 7.6)
-@@ -2262,6 +2272,11 @@ typedef struct tdTPM_STANY_DATA {
-   TPM_DAAHANDLE currentDAA;
-   TPM_TRANSHANDLE transExclusive;
- } TPM_STANY_DATA;
-+#define sizeof_TPM_STANY_DATA(s) (2 + 20 + 20 + 1 \
-+  + sizeof_TPM_CURRENT_TICKS(s.currentTicks) \
-+  + 4 + (4 * TPM_MAX_SESSION_LIST) \
-+  + (sizeof_TPM_SESSION_DATA(s.sessions[0]) * TPM_MAX_SESSION_LIST) \
-+  + (sizeof_TPM_DAA_SESSION_DATA(s.sessionsDAA[0]) *
TPM_MAX_SESSIONS_DAA) + 4)
-
- /*
-  * TPM_DATA
-diff -uprN orig/tpm_emulator-0.4/tpm/tpm_testing.c
tpm_emulator/tpm/tpm_testing.c
---- orig/tpm_emulator-0.4/tpm/tpm_testing.c    2006-06-23
03:37:07.000000000 -0700
-+++ tpm_emulator/tpm/tpm_testing.c    2006-07-24 14:35:35.000000000 -070=
0
-@@ -1,6 +1,7 @@
- /* Software-Based Trusted Platform Module (TPM) Emulator for Linux
-  * Copyright (C) 2004 Mario Strasser <mast@gmx.net>,
-  *                    Swiss Federal Institute of Technology (ETH) Zuric=
h
-+ * Copyright (C) 2005 INTEL Corp
-  *
-  * This module is free software; you can redistribute it and/or modify
-  * it under the terms of the GNU General Public License as published
-@@ -95,24 +96,24 @@ static int tpm_test_sha1(void)
-   struct {
-     uint8_t *data; uint32_t repetitions; uint8_t *digest;
-   } test_cases[] =3D  {{
--    "abc", 1,
--  =20
"\xA9\x99\x3E\x36\x47\x06\x81\x6A\xBA\x3E\x25\x71\x78\x50\xC2\x6C\x9C\xD0=
\xD8\x9D"
-+    (uint8_t*)"abc", 1,
-+  =20
(uint8_t*)"\xA9\x99\x3E\x36\x47\x06\x81\x6A\xBA\x3E\x25\x71\x78\x50\xC2\x=
6C\x9C\xD0\xD8\x9D"
-   }, {
--    "abcdbcdecdefdefgefghfghighijhijkijkljklmklmnlmnomnopnopq", 1,
--  =20
"\x84\x98\x3E\x44\x1C\x3B\xD2\x6E\xBA\xAE\x4A\xA1\xF9\x51\x29\xE5\xE5\x46=
\x70\xF1"
-+  =20
(uint8_t*)"abcdbcdecdefdefgefghfghighijhijkijkljklmklmnlmnomnopnopq", 1,
-+  =20
(uint8_t*)"\x84\x98\x3E\x44\x1C\x3B\xD2\x6E\xBA\xAE\x4A\xA1\xF9\x51\x29\x=
E5\xE5\x46\x70\xF1"
-   }, {
--    "a", 1000000,
--  =20
"\x34\xAA\x97\x3C\xD4\xC4\xDA\xA4\xF6\x1E\xEB\x2B\xDB\xAD\x27\x31\x65\x34=
\x01\x6F"
-+    (uint8_t*)"a", 1000000,
-+  =20
(uint8_t*)"\x34\xAA\x97\x3C\xD4\xC4\xDA\xA4\xF6\x1E\xEB\x2B\xDB\xAD\x27\x=
31\x65\x34\x01\x6F"
-   }, {
--  =20
"0123456701234567012345670123456701234567012345670123456701234567", 10,
--  =20
"\xDE\xA3\x56\xA2\xCD\xDD\x90\xC7\xA7\xEC\xED\xC5\xEB\xB5\x63\x93\x4F\x46=
\x04\x52"
-+  =20
(uint8_t*)"01234567012345670123456701234567012345670123456701234567012345=
67",
10,
-+  =20
(uint8_t*)"\xDE\xA3\x56\xA2\xCD\xDD\x90\xC7\xA7\xEC\xED\xC5\xEB\xB5\x63\x=
93\x4F\x46\x04\x52"
-   }};
-
-   debug("tpm_test_sha1()");
-   for (i =3D 0; i < sizeof(test_cases) / sizeof(test_cases[0]); i++) {
-     sha1_init(&ctx);
-     for (j =3D 0; j < test_cases[i].repetitions; j++)
--      sha1_update(&ctx, test_cases[i].data, strlen(test_cases[i].data))=
;
-+      sha1_update(&ctx, test_cases[i].data,
strlen((char*)test_cases[i].data));
-     sha1_final(&ctx, digest);
-     if (memcmp(digest, test_cases[i].digest, SHA1_DIGEST_LENGTH) !=3D 0=
)
return -1;
-   }
-@@ -128,41 +129,41 @@ static int tpm_test_hmac(void)
-   struct {
-     uint8_t *key, key_len, *data, data_len, *digest;
-   } test_cases[] =3D {{
--    "\x0b", 20, "Hi There", 8,
--  =20
"\xb6\x17\x31\x86\x55\x05\x72\x64\xe2\x8b\xc0\xb6\xfb\x37\x8c\x8e\xf1\x46=
\xbe\x00"
-+    (uint8_t*)"\x0b", 20, (uint8_t*)"Hi There", 8,
-+  =20
(uint8_t*)"\xb6\x17\x31\x86\x55\x05\x72\x64\xe2\x8b\xc0\xb6\xfb\x37\x8c\x=
8e\xf1\x46\xbe\x00"
-   }, {
--    "Jefe", 4, "what do ya want for nothing?", 28,
--  =20
"\xef\xfc\xdf\x6a\xe5\xeb\x2f\xa2\xd2\x74\x16\xd5\xf1\x84\xdf\x9c\x25\x9a=
\x7c\x79"
-+    (uint8_t*)"Jefe", 4, (uint8_t*)"what do ya want for nothing?", 28,
-+  =20
(uint8_t*)"\xef\xfc\xdf\x6a\xe5\xeb\x2f\xa2\xd2\x74\x16\xd5\xf1\x84\xdf\x=
9c\x25\x9a\x7c\x79"
-   }, {
--    "\xaa", 20, "\xdd", 50,
--  =20
"\x12\x5d\x73\x42\xb9\xac\x11\xcd\x91\xa3\x9a\xf4\x8a\xa1\x7b\x4f\x63\xf1=
\x75\xd3"
-+    (uint8_t*)"\xaa", 20, (uint8_t*)"\xdd", 50,
-+  =20
(uint8_t*)"\x12\x5d\x73\x42\xb9\xac\x11\xcd\x91\xa3\x9a\xf4\x8a\xa1\x7b\x=
4f\x63\xf1\x75\xd3"
-   }, {
--  =20
"\x01\x02\x03\x04\x05\x06\x07\x08\x09\x0a\x0b\x0c\x0d\x0e\x0f\x10\x11\x12=
\x13\x14"
--    "\x15\x16\x17\x18\x19", 25, "\xcd", 50,
--  =20
"\x4c\x90\x07\xf4\x02\x62\x50\xc6\xbc\x84\x14\xf9\xbf\x50\xc8\x6c\x2d\x72=
\x35\xda"
-+  =20
(uint8_t*)"\x01\x02\x03\x04\x05\x06\x07\x08\x09\x0a\x0b\x0c\x0d\x0e\x0f\x=
10\x11\x12\x13\x14"
-+    "\x15\x16\x17\x18\x19", 25, (uint8_t*)"\xcd", 50,
-+  =20
(uint8_t*)"\x4c\x90\x07\xf4\x02\x62\x50\xc6\xbc\x84\x14\xf9\xbf\x50\xc8\x=
6c\x2d\x72\x35\xda"
-   }, {
--    "\x0c", 20, "Test With Truncation", 20,
--  =20
"\x4c\x1a\x03\x42\x4b\x55\xe0\x7f\xe7\xf2\x7b\xe1\xd5\x8b\xb9\x32\x4a\x9a=
\x5a\x04"
-+    (uint8_t*)"\x0c", 20, (uint8_t*)"Test With Truncation", 20,
-+  =20
(uint8_t*)"\x4c\x1a\x03\x42\x4b\x55\xe0\x7f\xe7\xf2\x7b\xe1\xd5\x8b\xb9\x=
32\x4a\x9a\x5a\x04"
-   }, {
--    "\xaa", 80, "Test Using Larger Than Block-Size Key - Hash Key
First", 54,
--  =20
"\xaa\x4a\xe5\xe1\x52\x72\xd0\x0e\x95\x70\x56\x37\xce\x8a\x3b\x55\xed\x40=
\x21\x12"
-+    (uint8_t*)"\xaa", 80, (uint8_t*)"Test Using Larger Than Block-Size
Key - Hash Key First", 54,
-+  =20
(uint8_t*)"\xaa\x4a\xe5\xe1\x52\x72\xd0\x0e\x95\x70\x56\x37\xce\x8a\x3b\x=
55\xed\x40\x21\x12"
-   }, {
--    "\xaa", 80,
--    "Test Using Larger Than Block-Size Key and Larger Than One
Block-Size Data", 73,
--  =20
"\xe8\xe9\x9d\x0f\x45\x23\x7d\x78\x6d\x6b\xba\xa7\x96\x5c\x78\x08\xbb\xff=
\x1a\x91"
-+    (uint8_t*)"\xaa", 80,
-+    (uint8_t*)"Test Using Larger Than Block-Size Key and Larger Than
One Block-Size Data", 73,
-+  =20
(uint8_t*)"\xe8\xe9\x9d\x0f\x45\x23\x7d\x78\x6d\x6b\xba\xa7\x96\x5c\x78\x=
08\xbb\xff\x1a\x91"
-   }};
-
-   debug("tpm_test_hmac()");
-   for (i =3D 0; i < sizeof(test_cases) / sizeof(test_cases[0]); i++) {
--    if (strlen(test_cases[i].key) < test_cases[i].key_len) {
-+    if (strlen((char*)test_cases[i].key) < test_cases[i].key_len) {
-       uint8_t key[test_cases[i].key_len];
-       memset(key, test_cases[i].key[0], test_cases[i].key_len);
-       hmac_init(&ctx, key, test_cases[i].key_len);
-     } else {
-       hmac_init(&ctx, test_cases[i].key, test_cases[i].key_len);
-     }
--    for (j =3D 0; j < test_cases[i].data_len; j +=3D
strlen(test_cases[i].data)) {
--      hmac_update(&ctx, test_cases[i].data, strlen(test_cases[i].data))=
;
-+    for (j =3D 0; j < test_cases[i].data_len; j +=3D
strlen((char*)test_cases[i].data)) {
-+      hmac_update(&ctx, test_cases[i].data,
strlen((char*)test_cases[i].data));
-     }
-     hmac_final(&ctx, digest);
-     if (memcmp(digest, test_cases[i].digest, SHA1_DIGEST_LENGTH) !=3D 0=
)
return -1;
-@@ -173,9 +174,9 @@ static int tpm_test_hmac(void)
- static int tpm_test_rsa_EK(void)
- {
-   int res =3D 0;
--  char *data =3D "RSA PKCS #1 v1.5 Test-String";
-+  uint8_t *data =3D (uint8_t*)"RSA PKCS #1 v1.5 Test-String";
-   uint8_t buf[256];
--  size_t buf_len, data_len =3D strlen(data);
-+  size_t buf_len, data_len =3D strlen((char*)data);
-   rsa_private_key_t priv_key;
-   rsa_public_key_t pub_key;
-
-diff -uprN orig/tpm_emulator-0.4/tpm/tpm_ticks.c
tpm_emulator/tpm/tpm_ticks.c
---- orig/tpm_emulator-0.4/tpm/tpm_ticks.c    2006-06-23
03:37:07.000000000 -0700
-+++ tpm_emulator/tpm/tpm_ticks.c    2006-07-24 14:35:35.000000000 -0700
-@@ -1,6 +1,7 @@
- /* Software-Based Trusted Platform Module (TPM) Emulator for Linux
-  * Copyright (C) 2004 Mario Strasser <mast@gmx.net>,
-  *                    Swiss Federal Institute of Technology (ETH) Zuric=
h
-+ * Copyright (C) 2005 INTEL Corp
-  *
-  * This module is free software; you can redistribute it and/or modify
-  * it under the terms of the GNU General Public License as published
-@@ -39,9 +40,7 @@ TPM_RESULT TPM_SetTickType(TPM_TICKTYPE
- TPM_RESULT TPM_GetTicks(TPM_CURRENT_TICKS *currentTime)
- {
-   info("TPM_GetTicks()");
--  memcpy(currentTime, &tpmData.stany.data.currentTicks,
--    sizeof(TPM_CURRENT_TICKS));
--  return TPM_SUCCESS;
-+  return TPM_DISABLED_CMD;
- }
-
- TPM_RESULT TPM_TickStampBlob(TPM_KEY_HANDLE keyHandle, TPM_NONCE
*antiReplay,
-@@ -49,64 +48,11 @@ TPM_RESULT TPM_TickStampBlob(TPM_KEY_HAN
-                              TPM_CURRENT_TICKS *currentTicks,
-                              UINT32 *sigSize, BYTE **sig)
- {
--  TPM_RESULT res;
--  TPM_KEY_DATA *key;
--  BYTE *info, *p;
--  UINT32 info_length, length;
-   info("TPM_TickStampBlob()");
--  /* get key */
--  key =3D tpm_get_key(keyHandle);
--  if (key =3D=3D NULL) return TPM_INVALID_KEYHANDLE;
--  /* verify authorization */
--  res =3D tpm_verify_auth(auth1, key->usageAuth, keyHandle);
--  if (res !=3D TPM_SUCCESS) return res;
--  if (key->keyUsage !=3D TPM_KEY_SIGNING && key->keyUsage !=3D TPM_KEY_=
LEGACY
--      && key->keyUsage !=3D TPM_KEY_IDENTITY) return TPM_INVALID_KEYUSA=
GE;
--  /* get current ticks */
--  TPM_GetTicks(currentTicks);
--  /* sign data using signature scheme PKCS1_SHA1 and TPM_SIGN_INFO
container */
--  *sigSize =3D key->key.size >> 3;
--  *sig =3D tpm_malloc(*sigSize);
--  if (*sig =3D=3D NULL) return TPM_FAIL;
--  /* setup TPM_SIGN_INFO structure */
--  info_length =3D 30 + sizeof(TPM_DIGEST) +
sizeof_TPM_CURRENT_TICKS(currentTicks);
--  info =3D tpm_malloc(info_length);
--  if (info =3D=3D NULL) {
--    tpm_free(*sig);
--    return TPM_FAIL;
--  }
--  memcpy(&info[0], "\x05\x00TSTP", 6);
--  memcpy(&info[6], antiReplay->nonce, 20);
--  *(UINT32*)&info[26] =3D CPU_TO_BE32(20
--                        + sizeof_TPM_CURRENT_TICKS(currentTicks));
--  memcpy(&info[30], digestToStamp->digest, sizeof(TPM_DIGEST));
--  p =3D &info[30 + sizeof(TPM_DIGEST)];
--  length =3D sizeof_TPM_CURRENT_TICKS(currentTicks);
--  if (tpm_marshal_TPM_CURRENT_TICKS(&p, &length, currentTicks)
--      || rsa_sign(&key->key, RSA_SSA_PKCS1_SHA1, info, info_length,
*sig)) { =20
--    tpm_free(*sig);
--    tpm_free(info);
--    return TPM_FAIL;
--  }
--  return TPM_SUCCESS;
-+  return TPM_DISABLED_CMD;
- }
-
- void tpm_update_ticks(void)
- {
--  if (tpmData.stany.data.currentTicks.tag =3D=3D 0) {
--    tpmData.stany.data.currentTicks.tag =3D TPM_TAG_CURRENT_TICKS;
--    tpmData.stany.data.currentTicks.currentTicks +=3D tpm_get_ticks();
--/* removed since v1.2 rev 94
--    tpmData.stany.data.currentTicks.tickType =3D
tpmData.permanent.data.tickType;
--*/
--    tpm_get_random_bytes(tpmData.stany.data.currentTicks.tickNonce.nonc=
e,
--      sizeof(TPM_NONCE));
--    tpmData.stany.data.currentTicks.tickRate =3D 1;
--/* removed since v1.2 rev 94
--    tpmData.stany.data.currentTicks.tickSecurity =3D TICK_SEC_NO_CHECK;=

--*/
--  } else {
--    tpmData.stany.data.currentTicks.currentTicks +=3D tpm_get_ticks(); =
=20
--  }
- }
-
-diff -uprN orig/tpm_emulator-0.4/tpm/tpm_transport.c
tpm_emulator/tpm/tpm_transport.c
---- orig/tpm_emulator-0.4/tpm/tpm_transport.c    2006-06-23
03:37:07.000000000 -0700
-+++ tpm_emulator/tpm/tpm_transport.c    2006-07-24 14:35:35.000000000 -0=
700
-@@ -189,7 +189,7 @@ static void decrypt_wrapped_command(BYTE
-     sha1_init(&sha1);
-     sha1_update(&sha1, auth->nonceEven.nonce,
sizeof(auth->nonceEven.nonce));
-     sha1_update(&sha1, auth->nonceOdd.nonce,
sizeof(auth->nonceOdd.nonce));
--    sha1_update(&sha1, "in", 2);
-+    sha1_update(&sha1, (BYTE*)"in", 2);
-     sha1_update(&sha1, secret, sizeof(TPM_SECRET));
-     j =3D CPU_TO_BE32(i);
-     sha1_update(&sha1, (BYTE*)&j, 4);
-@@ -211,7 +211,7 @@ static void encrypt_wrapped_command(BYTE
-     sha1_init(&sha1);
-     sha1_update(&sha1, auth->nonceEven.nonce,
sizeof(auth->nonceEven.nonce));
-     sha1_update(&sha1, auth->nonceOdd.nonce,
sizeof(auth->nonceOdd.nonce));
--    sha1_update(&sha1, "out", 3);
-+    sha1_update(&sha1, (BYTE*)"out", 3);
-     sha1_update(&sha1, secret, sizeof(TPM_SECRET));
-     j =3D CPU_TO_BE32(i);
-     sha1_update(&sha1, (BYTE*)&j, 4);
-diff -uprN orig/tpm_emulator-0.4/tpmd.c tpm_emulator/tpmd.c
---- orig/tpm_emulator-0.4/tpmd.c    1969-12-31 16:00:00.000000000 -0800
-+++ tpm_emulator/tpmd.c    2006-07-24 14:35:35.000000000 -0700
-@@ -0,0 +1,156 @@
-+/* Software-Based Trusted Platform Module (TPM) Emulator for Linux
-+ * Copyright (C) 2005 INTEL Corp
-+ *
-+ * This module 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 module is distributed in the hope that it will be useful,
-+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
-+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
-+ * GNU General Public License for more details.
-+ *
-+ */
-+
-+#include <stdio.h>
-+#include <stdlib.h>
-+#include <unistd.h>
-+#include <string.h>
-+#include <sys/types.h>
-+#include <sys/stat.h>
-+#include <fcntl.h>
-+#include <sys/time.h>
-+
-+#include "tpm_emulator.h"
-+
-+#define TPM_RX_FNAME "/var/tpm/tpm_in.fifo"
-+#define TPM_TX_FNAME "/var/tpm/tpm_out.fifo"
-+
-+#define BUFFER_SIZE 2048
-+
-+static int devurandom=3D0;
-+    =20
-+void get_random_bytes(void *buf, int nbytes) {
-+=20
-+  if (devurandom =3D=3D 0) {
-+    devurandom =3D open("/dev/urandom", O_RDONLY);
-+  }
-+
-+  if (read(devurandom, buf, nbytes) !=3D nbytes) {
-+      printf("Can't get random number.\n");
-+      exit(-1);
-+  }
-+}
-+
-+uint64_t tpm_get_ticks(void)
-+{
-+  //struct timeval tv;
-+  //int gettimeofday(&tv, struct timezone *tz);
-+  return 0;
-+}
-+
-+int main(int argc, char **argv)
-+{
-+  uint8_t in[BUFFER_SIZE], *out;
-+  uint32_t out_size;
-+  int in_size, written;
-+  int i;
-+  struct stat file_info;
-+
-+  int tpm_tx_fh=3D-1, tpm_rx_fh=3D-1;
-+  if (argc < 2) {
-+    printf("Usage: tpmd clear|save|deactivated\n" );
-+      return -1;
-+  }
-+
-+  /* initialize TPM emulator */
-+  if (!strcmp(argv[1], "clear")) {
-+    printf("Initializing tpm: %s\n", argv[1]);
-+    tpm_emulator_init(1);
-+  } else if (!strcmp(argv[1], "save")) {
-+    printf("Initializing tpm: %s\n", argv[1]);
-+    tpm_emulator_init(2);
-+  } else if (!strcmp(argv[1], "deactivated")) {
-+    printf("Initializing tpm: %s\n", argv[1]);
-+    tpm_emulator_init(3);
-+  } else {
-+    printf("invalid startup mode '%s'; must be 'clear', "
-+      "'save' (default) or 'deactivated", argv[1]);
-+    return -1;
-+  }
-+
-+  if ( stat(TPM_RX_FNAME, &file_info) =3D=3D -1) {
-+    if ( mkfifo(TPM_RX_FNAME, S_IWUSR | S_IRUSR ) ) {
-+      printf("Failed to create fifo %s.\n", TPM_RX_FNAME);
-+      return -1;
-+    }
-+  }
-+
-+  if ( stat(TPM_TX_FNAME, &file_info) =3D=3D -1) {
-+    if ( mkfifo(TPM_TX_FNAME, S_IWUSR | S_IRUSR ) ) {
-+      printf("Failed to create fifo %s.\n", TPM_TX_FNAME);
-+      return -1;
-+    }
-+  }
-+
-+  while (1) {
-+abort_command:
-+    if (tpm_rx_fh < 0) {
-+      tpm_rx_fh =3D open(TPM_RX_FNAME, O_RDONLY);
-+    }
-+  =20
-+    if (tpm_rx_fh < 0) {
-+      printf("ERROR: failed to open devices to listen to guest.\n");
-+      return -1;
-+    }
-+  =20
-+    if (tpm_tx_fh < 0) {
-+      tpm_tx_fh =3D open(TPM_TX_FNAME, O_WRONLY);
-+    }
-+
-+    if (tpm_tx_fh < 0) {
-+      printf("ERROR: failed to open devices to respond to guest.\n");
-+      return -1;
-+    }
-+
-+    in_size =3D read(tpm_rx_fh, in, BUFFER_SIZE);
-+    if (in_size < 6) { // Magic size of minium TPM command
-+      printf("Recv[%d] to small: 0x", in_size);
-+      if (in_size <=3D 0) {
-+          close(tpm_rx_fh);
-+          tpm_rx_fh =3D -1;
-+          goto abort_command;
-+      }
-+    } else {
-+      printf("Recv[%d]: 0x", in_size);
-+      for (i=3D0; i< in_size; i++)
-+        printf("%x ", in[i]);
-+      printf("\n");
-+    }
-+
-+  =20
-+    if (tpm_handle_command(in, in_size, &out, &out_size) !=3D 0) {
-+        printf("ERROR: Handler Failed.\n");
-+    }
-+
-+    written =3D write(tpm_tx_fh, out, out_size);
-+
-+    if (written !=3D out_size ) {
-+      printf("ERROR: Part of response not written %d/%d.\nAttempt: ",
written, out_size);
-+    } else {
-+      printf("Sent[%Zu]: ", out_size);
-+    }
-+    for (i=3D0; i< out_size; i++)
-+      printf("%x ", out[i]);
-+    printf("\n");
-+    tpm_free(out);
-+
-+  } // loop
-+
-+  tpm_emulator_shutdown();
-+
-+  close(tpm_tx_fh);
-+  close(tpm_rx_fh);
-+
-+}
-Binary files orig/tpm_emulator-0.4/tpm_emulator and
tpm_emulator/tpm_emulator differ
-diff -uprN orig/tpm_emulator-0.4/tpm_version.h tpm_emulator/tpm_version.=
h
---- orig/tpm_emulator-0.4/tpm_version.h    2006-06-23
03:37:07.000000000 -0700
-+++ tpm_emulator/tpm_version.h    2006-07-24 14:35:41.000000000 -0700
-@@ -2,5 +2,5 @@
- #define _TPM_VERSION_H_
- #define VERSION_MAJOR 0
- #define VERSION_MINOR 4
--#define VERSION_BUILD 1151058734
-+#define VERSION_BUILD 1153776940
- #endif /* _TPM_VERSION_H_ */
diff --git a/tools/vtpm/vtpm-0.5.1-LDLIBS.patch
b/tools/vtpm/vtpm-0.5.1-LDLIBS.patch
--- a/tools/vtpm/vtpm-0.5.1-LDLIBS.patch
+++ /dev/null
@@ -1,12 +0,0 @@
-diff -Naurp tpm_emulator-0.5.1/tpmd/Makefile
tpm_emulator-0.5.1/tpmd/Makefile
---- tpm_emulator-0.5.1/tpmd/Makefile
-+++ tpm_emulator-0.5.1/tpmd/Makefile
-@@ -8,7 +8,7 @@ WFLAGS  :=3D -Wall -Wno-unused -Wpointer-a
-            #WFLAGS  +=3D -Wextra -Wcast-qual -Wmissing-prototypes
-Wmissing-declarations -Wstrict-aliasing
- CFLAGS  +=3D $(WFLAGS) -g -I.. -I. -O2 -fno-strict-aliasing
- CFLAGS  +=3D -I../../../../tools/vtpm_manager/manager
--LDFLAGS +=3D -lgmp
-+LDLIBS  +=3D -lgmp
-
- BINDIR  :=3D /usr/bin/
-
diff --git a/tools/vtpm/vtpm-0.5.1.patch b/tools/vtpm/vtpm-0.5.1.patch
--- a/tools/vtpm/vtpm-0.5.1.patch
+++ /dev/null
@@ -1,766 +0,0 @@
-diff -Naurp tpm_emulator-0.5.1/Makefile tpm5-test/Makefile
---- tpm_emulator-0.5.1/Makefile    2008-02-14 03:22:48.000000000 -0500
-+++ tpm5-test/Makefile    2009-07-15 09:45:28.000000000 -0400
-@@ -10,7 +10,7 @@ VERSION_MINOR  :=3D 5
- VERSION_BUILD  :=3D $(shell date +"%s")
- VERSION_SUFFIX :=3D .1
-
--SUBDIRS :=3D tpmd tpmd_dev tddl
-+SUBDIRS :=3D tpmd
-
- all: version all-recursive
-
-@@ -48,12 +48,12 @@ user_install: user
- modules_install: modules
-     @$(MAKE) -C tpmd_dev install || exit -1
-
--DIRS    :=3D . tpm crypto tpmd tpmd_dev tddl tpmd_dev_openbsd
-+DIRS    :=3D . tpm crypto tpmd
- DISTSRC :=3D $(foreach dir, $(DIRS), $(wildcard $(dir)/*.c))
- DISTSRC +=3D $(foreach dir, $(DIRS), $(wildcard $(dir)/*.h))
--DIRS    :=3D . tpmd tpmd_dev tddl tpmd_dev_openbsd
-+DIRS    :=3D . tpmd
- DISTSRC +=3D $(foreach dir, $(DIRS), $(dir)/Makefile)
--DISTSRC +=3D ./README ./AUTHORS ./ChangeLog tpmd_dev/tpmd_dev.rules.in
-+DISTSRC +=3D ./README ./AUTHORS ./ChangeLog
- DISTDIR :=3D tpm_emulator-$(VERSION_MAJOR).$(VERSION_MINOR)$(VERSION_SU=
FFIX)
-
- dist: $(DISTSRC)
-diff -Naurp tpm_emulator-0.5.1/tpm/tpm_capability.c
tpm5-test/tpm/tpm_capability.c
---- tpm_emulator-0.5.1/tpm/tpm_capability.c    2008-02-14
03:22:48.000000000 -0500
-+++ tpm5-test/tpm/tpm_capability.c    2009-07-16 12:04:20.000000000 -040=
0
-@@ -136,8 +136,19 @@ static TPM_RESULT cap_property(UINT32 su
-
-     case TPM_CAP_PROP_TIS_TIMEOUT:
-       debug("[TPM_CAP_PROP_TIS_TIMEOUT]");
--      /* TODO: TPM_CAP_PROP_TIS_TIMEOUT */
--      return TPM_FAIL;
-+      /* TODO: TPM_CAP_PROP_TIS_TIMEOUT: Measure these values and
determine correct ones */
-+      UINT32 len =3D *respSize =3D 16;
-+      BYTE *ptr =3D *resp =3D tpm_malloc(*respSize);
-+      if (ptr =3D=3D NULL ||
-+          tpm_marshal_UINT32(&ptr, &len, 200000) ||
-+          tpm_marshal_UINT32(&ptr, &len, 200000) ||
-+          tpm_marshal_UINT32(&ptr, &len, 200000) ||
-+          tpm_marshal_UINT32(&ptr, &len, 200000)) {
-+        tpm_free(*resp);
-+        return TPM_FAIL;
-+      }
-+      return TPM_SUCCESS;
-+
-
-     case TPM_CAP_PROP_STARTUP_EFFECT:
-       debug("[TPM_CAP_PROP_STARTUP_EFFECT]");
-@@ -189,8 +200,12 @@ static TPM_RESULT cap_property(UINT32 su
-
-     case TPM_CAP_PROP_DURATION:
-       debug("[TPM_CAP_PROP_DURATION]");
--      /* TODO: TPM_CAP_PROP_DURATION */
--      return TPM_FAIL;
-+      /* TODO: TPM_CAP_PROP_DURATION: Measure these values and return
accurate ones */
-+      BYTE dur[]=3D
{0x0,0x0,0x0,0xc,0x0,0x7,0xa1,0x20,0x0,0x1e,0x84,0x80,0x11,0xe1,0xa3,0x0}=
;
-+      *respSize =3D 16;
-+      *resp =3D tpm_malloc(*respSize);
-+      memcpy(*resp,dur,16);
-+
-
-     case TPM_CAP_PROP_ACTIVE_COUNTER:
-       debug("[TPM_CAP_PROP_ACTIVE_COUNTER]");
-diff -Naurp tpm_emulator-0.5.1/tpmd/Makefile tpm5-test/tpmd/Makefile
---- tpm_emulator-0.5.1/tpmd/Makefile    2008-02-14 03:22:48.000000000 -0=
500
-+++ tpm5-test/tpmd/Makefile    2009-07-16 12:08:26.000000000 -0400
-@@ -8,9 +8,10 @@ WFLAGS  :=3D -Wall -Wno-unused -Wpointer-a
-            -Wwrite-strings -Wsign-compare -Wno-multichar
-            #WFLAGS  +=3D -Wextra -Wcast-qual -Wmissing-prototypes
-Wmissing-declarations -Wstrict-aliasing
- CFLAGS  +=3D $(WFLAGS) -g -I.. -I. -O2 -fno-strict-aliasing
-+CFLAGS  +=3D -I../../../../tools/vtpm_manager/manager
- LDFLAGS +=3D -lgmp
-
--BINDIR  :=3D /usr/sbin/
-+BINDIR  :=3D /usr/bin/
-
- TPMD    :=3D tpmd
- DIRS    :=3D ../tpm ../crypto
-@@ -18,6 +19,8 @@ SRCS    :=3D $(foreach dir, $(DIRS), $(wil
- OBJS    :=3D $(patsubst %.c, %.o, $(SRCS))
- OBJS    :=3D $(foreach dir, $(DIRS), $(patsubst $(dir)/%.o, %.o,
$(filter $(dir)/%.o, $(OBJS))))
-
-+VTPM_BIN :=3D vtpmd
-+
- vpath %.c $(strip $(DIRS))
-
- all: $(TPMD)
-@@ -32,10 +35,8 @@ TPMD_GROUP ?=3D tss
- INSTALL    ?=3D install
-
- install: $(TPMD)
--    $(INSTALL) -m 755 -o $(TPMD_USER) -g $(TPMD_GROUP) -d
$(DESTDIR)/var/lib/tpm
--    $(INSTALL) -m 755 -o $(TPMD_USER) -g $(TPMD_GROUP) -d
$(DESTDIR)/var/run/tpm
-     $(INSTALL) -D -d $(DESTDIR)/$(BINDIR)
--    $(INSTALL) -m 755 $(TPMD) $(DESTDIR)/$(BINDIR)
-+    $(INSTALL) -m 755 $(TPMD) $(DESTDIR)/$(BINDIR)/$(VTPM_BIN)
-
- .PHONY: all clean install
-
-diff -Naurp tpm_emulator-0.5.1/tpmd/tpmd.c tpm5-test/tpmd/tpmd.c
---- tpm_emulator-0.5.1/tpmd/tpmd.c    2008-02-14 03:22:48.000000000 -050=
0
-+++ tpm5-test/tpmd/tpmd.c    2009-07-16 11:19:05.000000000 -0400
-@@ -32,6 +32,9 @@
- #include <grp.h>
- #include "tpm_emulator_config.h"
- #include "tpm/tpm_emulator.h"
-+#include "tpm/tpm_structures.h"
-+#include "tpm/tpm_marshalling.h"
-+#include "vtpm_manager.h"
-
- #define TPM_DAEMON_NAME     "tpmd"
- #define TPM_CMD_BUF_SIZE    4096
-@@ -39,6 +42,24 @@
- #define TPM_RANDOM_DEVICE   "/dev/urandom"
- #undef  TPM_MKDIRS
-
-+#ifdef VTPM_MULTI_VM
-+ #define DEV_BE "/dev/vtpm"
-+ #define DEV_FE "/dev/tpm"
-+#else
-+ #define PVM_RX_FIFO_D "/var/vtpm/fifos/tpm_cmd_to_%d.fifo"
-+ #define PVM_TX_FIFO "/var/vtpm/fifos/tpm_rsp_from_all.fifo"
-+ #define HVM_RX_FIFO_D "/var/vtpm/socks/%d.socket"
-+
-+ #define VTPM_RX_FIFO_D "/var/vtpm/fifos/vtpm_rsp_to_%d.fifo"
-+ #define VTPM_TX_FIFO "/var/vtpm/fifos/vtpm_cmd_from_all.fifo"
-+
-+ static char *vtpm_rx_name=3DNULL;
-+#endif
-+
-+ static int vtpm_tx_fh=3D-1, vtpm_rx_fh=3D-1;
-+
-+#define BUFFER_SIZE 2048
-+
- static volatile int stopflag =3D 0;
- static int is_daemon =3D 0;
- static int opt_debug =3D 0;
-@@ -49,6 +70,8 @@ static const char *opt_storage_file =3D "/
- static uid_t opt_uid =3D 0;
- static gid_t opt_gid =3D 0;
- static int tpm_startup =3D 2;
-+static int vtpm_type =3D VTPM_TYPE_PVM;
-+int dmi_id =3D 0;
- static int rand_fh;
-
- void tpm_log(int priority, const char *fmt, ...)
-@@ -90,56 +113,241 @@ uint64_t tpm_get_ticks(void)
-
- int tpm_write_to_file(uint8_t *data, size_t data_length)
- {
--    int fh;
--    ssize_t res;
--    fh =3D open(opt_storage_file, O_WRONLY | O_TRUNC | O_CREAT, S_IRUSR=

| S_IWUSR);
--    if (fh < 0) return -1;
--    while (data_length > 0) {
--        res =3D write(fh, data, data_length);
--    if (res < 0) {
--        close(fh);
--        return -1;
--    }
--    data_length -=3D res;
--    data +=3D res;
-+  int res, out_data_size, in_header_size;
-+  BYTE *ptr, *out_data, *in_header;
-+  UINT32 result, len, in_rsp_size;
-+  UINT16 tag =3D VTPM_TAG_REQ;
-+  =20
-+  printf("Saving NVM\n");
-+  if (vtpm_tx_fh < 0) {
-+#ifdef VTPM_MUTLI_VM
-+    vtpm_tx_fh =3D open(DEV_FE, O_RDWR);
-+#else
-+    vtpm_tx_fh =3D open(VTPM_TX_FIFO, O_WRONLY);
-+#endif
-+  }
-+
-+  if (vtpm_tx_fh < 0) {
-+        return -1;
-+  }
-+
-+  // Send request to VTPM Manager to encrypt data
-+#ifdef VTPM_MUTLI_VM
-+  out_data_size =3D len =3D VTPM_COMMAND_HEADER_SIZE_CLT + data_length;=

-+#else
-+  out_data_size =3D len =3D VTPM_COMMAND_HEADER_SIZE_SRV + data_length;=

-+#endif
-+=20
-+  out_data =3D ptr =3D (BYTE *) malloc(len);
-+
-+  if (ptr =3D=3D NULL
-+#ifndef VTPM_MUTLI_VM
-+      || tpm_marshal_UINT32(&ptr, &len, dmi_id)
-+#endif
-+      || tpm_marshal_UINT16(&ptr, &len, tag)
-+#ifdef VTPM_MUTLI_VM
-+      || tpm_marshal_UINT32(&ptr, &len, out_data_size)
-+#else
-+      || tpm_marshal_UINT32(&ptr, &len, out_data_size - sizeof(uint32_t=
))
-+#endif=20
-+      || tpm_marshal_UINT32(&ptr, &len, VTPM_ORD_SAVENVM)
-+      || tpm_marshal_BYTE_ARRAY(&ptr, &len, data, data_length)) {
-+    free(out_data);
-+    return -1;
-+  }
-+=20
-+  printf("\tSending SaveNVM Command.\n");
-+  res =3D write(vtpm_tx_fh, out_data, out_data_size);
-+  free(out_data);
-+  if (res !=3D out_data_size) return -1;
-+
-+  if (vtpm_rx_fh < 0) {
-+#ifdef VTPM_MUTLI_VM
-+    vtpm_rx_fh =3D vtpm_tx_fh
-+#else
-+    if (vtpm_rx_name =3D=3D NULL) {
-+      vtpm_rx_name =3D malloc(10 + strlen(VTPM_RX_FIFO_D));
-+      sprintf(vtpm_rx_name, VTPM_RX_FIFO_D, (uint32_t) dmi_id);
-     }
--    close(fh);
--    return 0;
-+    vtpm_rx_fh =3D open(vtpm_rx_name, O_RDONLY);
-+#endif
-+  }
-+
-+  if (vtpm_rx_fh < 0) {
-+        return -1;
-+  }
-+=20
-+  // Read Header of response so we can get the size & status
-+#ifdef VTPM_MUTLI_VM
-+  in_header_size =3D len =3D VTPM_COMMAND_HEADER_SIZE_CLT;
-+#else
-+  in_header_size =3D len =3D VTPM_COMMAND_HEADER_SIZE_SRV;
-+#endif
-+  in_header =3D ptr =3D malloc(in_header_size);
-+=20
-+  printf("\tReading SaveNVM header.\n");
-+  res =3D read(vtpm_rx_fh, in_header, in_header_size);
-+
-+  if ( (res !=3D in_header_size)
-+#ifndef VTPM_MUTLI_VM
-+       || tpm_unmarshal_UINT32(&ptr, &len, (UINT32*)&dmi_id)
-+#endif
-+       || tpm_unmarshal_UINT16(&ptr, &len, &tag)
-+       || tpm_unmarshal_UINT32(&ptr, &len, &in_rsp_size)
-+       || tpm_unmarshal_UINT32(&ptr, &len, &result) ) {
-+      free(in_header);
-+      return -1;
-+  }
-+  free(in_header);
-+=20
-+  if (result !=3D VTPM_SUCCESS) {
-+      return -1;=20
-+  }
-+
-+#ifdef VTPM_MUTLI_VM
-+  close(vtpm_tx_fh); close(vtpm_rx_fh);
-+#endif
-+    =20
-+  printf("\tFinishing up SaveNVM\n");
-+  return (0);
- }
-
- int tpm_read_from_file(uint8_t **data, size_t *data_length)
- {
--    int fh;
--    ssize_t res;
--    size_t total_length;
--    fh =3D open(opt_storage_file, O_RDONLY);
--    if (fh < 0) return -1;
--    total_length =3D lseek(fh, 0, SEEK_END);
--    lseek(fh, 0, SEEK_SET);
--    *data =3D tpm_malloc(total_length);
--    if (*data =3D=3D NULL) {
--        close(fh);
--        return -1;
--    }
--    *data_length =3D 0;
--    while (total_length > 0) {
--        res =3D read(fh, &(*data)[*data_length], total_length);
--    if (res < 0) {
--        close(fh);
--        tpm_free(*data);
--        return -1;
--    }
--        *data_length +=3D res;
--    total_length -=3D res;
-+  int res, out_data_size, in_header_size;
-+  uint8_t *ptr, *out_data, *in_header;
-+  UINT16 tag =3D VTPM_TAG_REQ;
-+  UINT32 len, in_rsp_size, result;
-+#ifdef VTPM_MUTLI_VM
-+    int vtpm_rx_fh, vtpm_tx_fh;
-+#endif
-+  =20
-+  printf("Loading NVM.\n");
-+  if (vtpm_tx_fh < 0) {
-+#ifdef VTPM_MUTLI_VM
-+    vtpm_tx_fh =3D open(DEV_FE, O_RDWR);
-+#else
-+    vtpm_tx_fh =3D open(VTPM_TX_FIFO, O_WRONLY);
-+#endif
-+  }
-+
-+  if (vtpm_tx_fh < 0) {
-+    printf("Error in read_from_file:301\n");
-+        return -1;
-+  }
-+
-+  // Send request to VTPM Manager to encrypt data
-+#ifdef VTPM_MUTLI_VM
-+  out_data_size =3D len =3D VTPM_COMMAND_HEADER_SIZE_CLT;
-+#else
-+  out_data_size =3D len =3D VTPM_COMMAND_HEADER_SIZE_SRV;
-+#endif
-+  out_data =3D ptr =3D (BYTE *) malloc(len);
-+
-+  if (ptr =3D=3D NULL
-+#ifndef VTPM_MUTLI_VM
-+      || tpm_marshal_UINT32(&ptr, &len, dmi_id)
-+#endif=20
-+      || tpm_marshal_UINT16(&ptr, &len, tag)
-+#ifdef VTPM_MUTLI_VM
-+      || tpm_marshal_UINT32(&ptr, &len, out_data_size)
-+#else
-+      || tpm_marshal_UINT32(&ptr, &len, out_data_size - sizeof(uint32_t=
))
-+#endif
-+      || tpm_marshal_UINT32(&ptr, &len, VTPM_ORD_LOADNVM)) {
-+    free(out_data);
-+    printf("Error in read_from_file:325\n");
-+
-+    return -1;
-+  }
-+
-+  printf("\tSending LoadNVM command\n");
-+  res =3D write(vtpm_tx_fh, out_data, out_data_size);
-+  free(out_data);
-+  if (res !=3D out_data_size)
-+    {
-+    printf("Error in read_from_file:335\n");
-+    return -1;
-+    }
-+
-+    if (vtpm_rx_fh < 0) {
-+#ifdef VTPM_MUTLI_VM
-+    vtpm_rx_fh =3D vtpm_tx_fh;
-+#else
-+    if (vtpm_rx_name =3D=3D NULL) {
-+      vtpm_rx_name =3D malloc(10 + strlen(VTPM_RX_FIFO_D));
-+      sprintf(vtpm_rx_name, VTPM_RX_FIFO_D, (uint32_t) dmi_id);
-     }
--    close(fh);
--    return 0;
-+    vtpm_rx_fh =3D open(vtpm_rx_name, O_RDONLY);
-+#endif
-+  }
-+
-+  if (vtpm_rx_fh < 0) {
-+    printf("Error in read_from_file:352\n");  =20
-+    return -1;
-+  }
-+=20
-+  // Read Header of response so we can get the size & status
-+#ifdef VTPM_MUTLI_VM
-+  in_header_size =3D len =3D VTPM_COMMAND_HEADER_SIZE_CLT;
-+#else
-+  in_header_size =3D len =3D VTPM_COMMAND_HEADER_SIZE_SRV;
-+#endif
-+  in_header =3D ptr =3D malloc(in_header_size);
-+=20
-+  printf("\tReading LoadNVM header\n");
-+  res =3D read(vtpm_rx_fh, in_header, in_header_size);
-+
-+  if ( (res !=3D in_header_size)
-+#ifndef VTPM_MUTLI_VM
-+       || tpm_unmarshal_UINT32(&ptr, &len, (UINT32*)&dmi_id)
-+#endif
-+       || tpm_unmarshal_UINT16(&ptr, &len, &tag)
-+       || tpm_unmarshal_UINT32(&ptr, &len, &in_rsp_size)
-+       || tpm_unmarshal_UINT32(&ptr, &len, &result) ) {
-+      free(in_header);
-+      printf("Error in read_from_file:375\n");   =20
-+      return -1;
-+  }
-+  free(in_header);
-+=20
-+  if (result !=3D VTPM_SUCCESS) {
-+    printf("Error in read_from_file:381\n");
-+    return -1;=20
-+  }
-+
-+  // Read Encrypted data from VTPM Manager
-+  *data_length =3D in_rsp_size - VTPM_COMMAND_HEADER_SIZE_CLT;
-+  *data =3D (uint8_t *) malloc(*data_length);
-+
-+  printf("\tReading clear data from LoadNVM.\n");
-+  res =3D read(vtpm_rx_fh, *data, *data_length);
-+#ifdef VTPM_MUTLI_VM
-+  close(vtpm_rx_fh);close(vtpm_tx_fh);
-+#endif
-+  =20
-+  printf("\tReturing from loading NVM\n");
-+  if (res !=3D (int)*data_length) {
-+      free(*data);
-+      printf("Error in read_from_file:398\n");
-+      return -1;
-+  } else {
-+      return 0;
-+  }
-+
-+
-+  =20
- }
-
- static void print_usage(char *name)
- {
-     printf("usage: %s [-d] [-f] [-s storage file] [-u unix socket name]=
 "
--           "[-o user name] [-g group name] [-h] [startup mode]\n", name=
);
-+           "[-o user name] [-g group name] [-h]"
-+#ifdef VTPM_MULTI_VM
-+       "clear|save|deactivated\n", name);
-+#else
-+       "clear|save|deactivated pvm|hvm vtpmid\n", name);
-+#endif
-     printf("  d : enable debug mode\n");
-     printf("  f : forces the application to run in the foreground\n");
-     printf("  s : storage file to use (default: %s)\n", opt_storage_fil=
e);
-@@ -205,7 +413,13 @@ static void parse_options(int argc, char
-                 exit(EXIT_SUCCESS);
-         }
-     }
--    if (optind < argc) {
-+    /*Make sure we have all required options*/
-+#ifdef VTPM_MULTI_VM
-+#define EXTRA_OPTS 0
-+#else
-+#define EXTRA_OPTS 2
-+#endif
-+    if (optind < argc - EXTRA_OPTS ) {
-         debug("startup mode =3D '%s'", argv[optind]);
-         if (!strcmp(argv[optind], "clear")) {
-             tpm_startup =3D 1;
-@@ -219,6 +433,25 @@ static void parse_options(int argc, char
-             print_usage(argv[0]);
-             exit(EXIT_SUCCESS);
-         }
-+#ifndef VTPM_MULTI_VM
-+        ++optind;
-+    if(!strcmp(argv[optind], "pvm")) {
-+        vtpm_type =3D VTPM_TYPE_PVM;    // Get commands from vTPM
Manager through fifo
-+    } else if (!strcmp(argv[optind], "hvm")) {
-+        vtpm_type =3D VTPM_TYPE_HVM;    // Get commands from qemu via s=
ocket
-+        } else {
-+        error("Invalid vm mode '%s'; must be 'pvm', "
-+            "or 'hvm' ", argv[optind]);
-+        print_usage(argv[0]);
-+        exit(EXIT_SUCCESS);
-+    }
-+        ++optind;
-+    dmi_id =3D atoi(argv[optind]);
-+#endif
-+    } else {
-+    error("Invalid number of arguments");
-+    print_usage(argv[0]);
-+    exit(EXIT_SUCCESS);
-     }
- }
-
-@@ -348,93 +581,180 @@ static int init_socket(const char *name)
-
- static void main_loop(void)
- {
--    int sock, fh, res;
--    int32_t in_len;
-+    int32_t in_len, written;
-     uint32_t out_len;
--    uint8_t in[TPM_CMD_BUF_SIZE], *out;
-+    uint8_t in[TPM_CMD_BUF_SIZE], *out, *addressed_out;
-+    int guest_id=3D-1;
-+    int i;
-+    char *vtpm_rx_file=3DNULL;
-+    int res;
-+
-+#ifndef VTPM_MULTI_VM
-+    int sockfd =3D -1;
-     struct sockaddr_un addr;
--    socklen_t addr_len;
--    fd_set rfds;
--    struct timeval tv;
-+    struct sockaddr_un client_addr;
-+    unsigned int client_length;
-+#endif
-+
-+    int vtpm_tx_fh=3D-1, vtpm_rx_fh=3D-1;
-+
-+#ifndef VTPM_MULTI_VM
-+  if (vtpm_type =3D=3D VTPM_TYPE_PVM) {
-+    vtpm_rx_file =3D malloc(10 + strlen(PVM_RX_FIFO_D));
-+    sprintf(vtpm_rx_file, PVM_RX_FIFO_D, (uint32_t) dmi_id);
-+  } else {
-+    vtpm_rx_file =3D malloc(10 + strlen(HVM_RX_FIFO_D));
-+    sprintf(vtpm_rx_file, HVM_RX_FIFO_D, (uint32_t) dmi_id);
-+
-+    if ( (sockfd =3D socket(PF_UNIX,SOCK_STREAM,0)) < 0) {
-+          error("Unable to create socket. errno =3D %d\n", errno);
-+      exit (-1);
-+    }
-+
-+    memset(&addr, 0, sizeof(addr));
-+    addr.sun_family =3D AF_UNIX;
-+    strcpy(addr.sun_path,vtpm_rx_file );
-+    unlink(addr.sun_path);
-+  }
-+#endif
-
-     info("staring main loop");
--    /* open UNIX socket */
--    sock =3D init_socket(opt_socket_name);
--    if (sock < 0) exit(EXIT_FAILURE);
-     /* init tpm emulator */
--    debug("initializing TPM emulator: %d", tpm_startup);
-+#ifdef VTPM_MULTI_VM
-+    debug("initializing TPM emulator: state=3D%d", tpm_startup);
-+#else
-+    debug("initializing TPM emulator: state=3D%d, type=3D%d, id=3D%d",
tpm_startup, vtpm_type, dmi_id);
-+#endif
-     tpm_emulator_init(tpm_startup);
-     /* start command processing */
-     while (!stopflag) {
-         /* wait for incomming connections */
-         debug("waiting for connections...");
--        FD_ZERO(&rfds);
--        FD_SET(sock, &rfds);
--        tv.tv_sec =3D 10;
--        tv.tv_usec =3D 0;
--        res =3D select(sock + 1, &rfds, NULL, NULL, &tv);
--        if (res < 0) {
--            error("select(sock) failed: %s", strerror(errno));
--            break;
--        } else if (res =3D=3D 0) {
--            continue;
--        }
--        addr_len =3D sizeof(addr);
--        fh =3D accept(sock, (struct sockaddr*)&addr, &addr_len);
--        if (fh < 0) {
--            error("accept() failed: %s", strerror(errno));
--            continue;
--        }
-+    if (vtpm_rx_fh < 0) {
-+#ifdef VTPM_MUTLI_VM
-+        vtpm_rx_fh =3D open(DEV_BE, O_RDWR);
-+#else
-+        if (vtpm_type =3D=3D VTPM_TYPE_PVM)
-+        {
-+        vtpm_rx_fh =3D open(vtpm_rx_file, O_RDONLY);
-+        } else {
-+        if (bind(sockfd, (struct sockaddr *)&addr, sizeof(addr)) < 0) {=

-+            error("Unable to bind(). errno =3D %d\n", errno);
-+            exit (-1);
-+        }
-+
-+        if (listen(sockfd, 10) <0) {
-+            error("Unable to listen(). errno =3D %d\n", errno);
-+            exit (-1);
-+        }
-+
-+         memset(&client_addr, 0, sizeof(client_addr));
-+         client_length =3D sizeof(client_addr);
-+
-+         vtpm_rx_fh =3D vtpm_tx_fh =3D accept(sockfd, (struct sockaddr
*)&client_addr, &client_length);
-+        }
-+#endif
-+    }
-+  =20
-+    /*Error Checking*/
-+    if (vtpm_rx_fh < 0) {
-+      error("Failed to open devices to listen to guest.\n");
-+      exit(-1);
-+    }
-+
-         /* receive and handle commands */
-         in_len =3D 0;
-         do {
-             debug("waiting for commands...");
--            FD_ZERO(&rfds);
--            FD_SET(fh, &rfds);
--            tv.tv_sec =3D TPM_COMMAND_TIMEOUT;
--            tv.tv_usec =3D 0;
--            res =3D select(fh + 1, &rfds, NULL, NULL, &tv);
--            if (res < 0) {
--                error("select(fh) failed: %s", strerror(errno));
--                close(fh);
--                break;
--            } else if (res =3D=3D 0) {
--#ifdef TPMD_DISCONNECT_IDLE_CLIENTS      =20
--                info("connection closed due to inactivity");
--                close(fh);
--                break;
--#else      =20
--                continue;
--#endif      =20
--            }
--            in_len =3D read(fh, in, sizeof(in));
--            if (in_len > 0) {
-+
-+            in_len =3D read(vtpm_rx_fh, in, sizeof(in));
-+        /*Magic size of minimum TPM command is 6*/
-+        //FIXME Magic size check may not be required anymore
-+            if (in_len < 6) {
-+        info("Recv incomplete command of %d bytes.", in_len);
-+        if (in_len <=3D 0) {
-+            close(vtpm_rx_fh);
-+            vtpm_rx_fh =3D -1;
-+            continue;
-+                 }
-+        } else {
-+        /*Debug Printouts*/
-                 debug("received %d bytes", in_len);
-+        debug_nostop("Recv[%d]: 0x", in_len);
-+        for (i=3D0; i< in_len; i++)
-+            debug_more("%x ", in[i]);
-+        debug_more("\n");
-+        /*Multiple Guest check*/
-+        if (guest_id =3D=3D -1) {
-+            guest_id =3D *((int32_t *) in);
-+        } else {
-+            if (guest_id !=3D *((int32_t *) in) ) {
-+            error("WARNING: More than one guest attached\n");
-+            }
-+        }
-+
-+        /*Open tx handle now*/
-+        if (vtpm_tx_fh < 0) {
-+#ifdef VTPM_MUTLI_VM
-+            vtpm_tx_fh =3D open(DEV_BE, O_RDWR);
-+            vtpm_rx_fh =3D vtpm_tx_fh;
-+#else
-+            if (vtpm_type =3D=3D VTPM_TYPE_PVM) {
-+            vtpm_tx_fh =3D open(PVM_TX_FIFO, O_WRONLY);
-+                 } // No need to open the other direction for HVM
-+#endif
-+        }
-+        if (vtpm_tx_fh < 0) {
-+          error("Failed to open devices to respond to guest.\n");
-+          exit(-1);
-+        }
-+
-+        /*Handle the TPM command now*/
-                 out =3D NULL;
--                res =3D tpm_handle_command(in, in_len, &out, &out_len);=

-+                res =3D tpm_handle_command(in + sizeof(uint32_t), in_le=
n
- sizeof(uint32_t), &out, &out_len);
-                 if (res < 0) {
-                     error("tpm_handle_command() failed");
-                 } else {
-                     debug("sending %d bytes", out_len);
-+            //FIXME this prepending may or may not be needed
-+            /*Prepend the first 4 bytes of the in buffer.. why?*/
-+            addressed_out =3D (uint8_t *) tpm_malloc(sizeof(uint32_t) +=

out_len);
-+            *(uint32_t *) addressed_out =3D *(uint32_t *) in;
-+            memcpy(addressed_out + sizeof(uint32_t), out, out_len);
-+            out_len +=3D sizeof(uint32_t);
-+            /*End Prepend*/
-+
-+            /*Perform write operation now*/
-                     while (out_len > 0) {
--                        res =3D write(fh, out, out_len);
-+                        res =3D write(vtpm_tx_fh, addressed_out, out_le=
n);
-+
-                         if (res < 0) {
-                             error("write(%d) failed: %s", out_len,
strerror(errno));
-                             break;
--                        }
-+                        } else {
-+              debug_nostop("Sent[%Zu]: ", out_len);
-+              for (i=3D0; (unsigned int)i< out_len; i++)
-+                debug_more("%x ", addressed_out[i]);
-+              debug_more("\n");
-+            }
-                         out_len    -=3D res;
-                     }
-                     tpm_free(out);
-+            tpm_free(addressed_out);
-                 }
-             }
-         } while (in_len > 0);
--        close(fh);
-+        //close(fh);
-     }
-+  =20
-     /* shutdown tpm emulator */
-     tpm_emulator_shutdown();
--    /* close socket */
--    close(sock);
--    unlink(opt_socket_name);
-+    /* Close handles */
-+    close(vtpm_tx_fh);
-+#ifndef VTPM_MULTI_VM
-+    close(vtpm_rx_fh);
-+    free(vtpm_rx_file);
-+#endif
-     info("main loop stopped");
- }
-
-@@ -450,12 +770,13 @@ int main(int argc, char **argv)
-     /* open random device */
-     init_random();
-     /* init signal handlers */
--    init_signal_handler();
-+    //init_signal_handler();
-     /* unless requested otherwiese, fork and daemonize process */
--    if (!opt_foreground) daemonize();
-+    //if (!opt_foreground) daemonize();
-     /* start main processing loop */
-     main_loop();
-     info("stopping TPM Emulator daemon");
-     closelog();
-     return 0;
- }
-+
-diff -Naurp tpm_emulator-0.5.1/tpmd/tpm_emulator_config.h
tpm5-test/tpmd/tpm_emulator_config.h
---- tpm_emulator-0.5.1/tpmd/tpm_emulator_config.h    2008-02-14
03:22:48.000000000 -0500
-+++ tpm5-test/tpmd/tpm_emulator_config.h    2009-07-16
11:25:26.000000000 -0400
-@@ -29,23 +29,28 @@
-
- /* TPM emulator configuration */
-
--#undef  TPM_STRONG_PERSISTENCE
--#undef  TPM_GENERATE_EK
-+#define  TPM_STRONG_PERSISTENCE
-+#define  TPM_GENERATE_EK
- #undef  TPM_GENERATE_SEED_DAA
- #undef  TPM_MEMORY_ALIGNMENT_MANDATORY
-
-+extern int dmi_id;
-+
- /* log macros */
-
- void tpm_log(int priority, const char *fmt, ...);
-
--#define debug(fmt, ...) tpm_log(LOG_DEBUG, "%s:%d: Debug: " fmt "\n", \=

--                                __FILE__, __LINE__, ## __VA_ARGS__)
--#define info(fmt, ...)  tpm_log(LOG_INFO, "%s:%d: Info: " fmt "\n", \
--                                __FILE__, __LINE__, ## __VA_ARGS__)
--#define error(fmt, ...) tpm_log(LOG_ERR, "%s:%d: Error: " fmt "\n", \
--                                __FILE__, __LINE__, ## __VA_ARGS__)
--#define alert(fmt, ...) tpm_log(LOG_ALERT, "%s:%d: Alert: " fmt "\n", \=

--                                __FILE__, __LINE__, ## __VA_ARGS__)
-+#define debug(fmt, ...) tpm_log(LOG_DEBUG, "VTPMD[%d]: %s:%d: Debug: "
fmt "\n", \
-+                                dmi_id, __FILE__, __LINE__, ##
__VA_ARGS__)
-+#define info(fmt, ...)  tpm_log(LOG_INFO, "VTPMD[%d]: %s:%d: Info: "
fmt "\n", \
-+                                dmi_id, __FILE__, __LINE__, ##
__VA_ARGS__)
-+#define error(fmt, ...) tpm_log(LOG_ERR, "VTPMD[%d]: %s:%d: Error: "
fmt "\n", \
-+                                dmi_id, __FILE__, __LINE__, ##
__VA_ARGS__)
-+#define alert(fmt, ...) tpm_log(LOG_ALERT, "VTPMD[%d]: %s:%d: Alert: "
fmt "\n", \
-+                                dmi_id, __FILE__, __LINE__, ##
__VA_ARGS__)
-+#define debug_nostop(fmt, ...) tpm_log(LOG_DEBUG, "VTPMD[%d]: %s:%d:
Debug: " fmt, \
-+                                dmi_id, __FILE__, __LINE__, ##
__VA_ARGS__)
-+#define debug_more(fmt, ...) tpm_log(LOG_DEBUG, fmt, ## __VA_ARGS__)
-
- /*  min/max macros that also do strict type-checking */
-
diff --git a/tools/vtpm/vtpm-0.7.4.patch b/tools/vtpm/vtpm-0.7.4.patch
--- /dev/null
+++ b/tools/vtpm/vtpm-0.7.4.patch
@@ -0,0 +1,1138 @@
+diff -Naur tpm_emulator-0.7.4-orig/CMakeLists.txt
tpm_emulator-0.7.4/CMakeLists.txt
+--- tpm_emulator-0.7.4-orig/CMakeLists.txt    2012-09-17
13:16:27.832582475 -0400
++++ tpm_emulator-0.7.4/CMakeLists.txt    2012-09-17 13:16:41.621654594
-0400
+@@ -63,6 +63,7 @@
+ # include root directories
+ include_directories(${CMAKE_SOURCE_DIR})
+ include_directories(${CMAKE_BINARY_DIR})
++include_directories(../../vtpm_manager/manager)
+
+ # add internal libraries
+ add_subdirectory(tpm)
+diff -Naur tpm_emulator-0.7.4-orig/CMakeLists.txt.orig
tpm_emulator-0.7.4/CMakeLists.txt.orig
+--- tpm_emulator-0.7.4-orig/CMakeLists.txt.orig    1969-12-31
19:00:00.000000000 -0500
++++ tpm_emulator-0.7.4/CMakeLists.txt.orig    2011-12-20
13:30:06.000000000 -0500
+@@ -0,0 +1,80 @@
++# Software-based Trusted Platform Module (TPM) Emulator
++# Copyright (C) 2004-2010 Mario Strasser <mast@gmx.net>
++#
++# $Id: CMakeLists.txt 475 2011-12-20 18:21:19Z mast $
++
++project(TPM_Emulator C)
++
++cmake_minimum_required(VERSION 2.4)
++set(CMAKE_ALLOW_LOOSE_LOOP_CONSTRUCTS true)
++if(COMMAND cmake_policy)
++cmake_policy(SET CMP0003 NEW)
++endif()
++
++# enforce out of source build
++string(COMPARE EQUAL "${CMAKE_SOURCE_DIR}" "${CMAKE_BINARY_DIR}"
IS_INSOURCE)
++if(IS_INSOURCE)
++    message(FATAL_ERROR "${PROJECT_NAME} requires an out of source
build.")
++endif()
++
++# set project and build version
++set(${PROJECT_NAME}_VERSION_MAJOR 0)
++set(${PROJECT_NAME}_VERSION_MINOR 7)
++string(REGEX REPLACE ".*Revision: ([0-9]+).*" "\\1"
${PROJECT_NAME}_VERSION_BUILD "$Revision: 475 $")
++
++# create project configuration
++if(WIN32)
++STRING(REGEX REPLACE "\\\\" "/" PROGRAMFILES
"$ENV{PROGRAMFILES}/${PROJECT_NAME}")
++set(TPM_LOG_FILE "${PROGRAMFILES}/tpmd.log")
++set(TPM_STORAGE_NAME
"${PROGRAMFILES}/tpm_emulator-1_2_${${PROJECT_NAME}_VERSION_MAJOR}_${${PR=
OJECT_NAME}_VERSION_MINOR}")
++set(TPM_DEVICE_NAME "//./pipe/tpmd:0")
++elseif(APPLE)
++set(TPM_LOG_FILE "/private/var/log/tpmd.log")
++set(TPM_SOCKET_NAME "/private/var/run/tpm/tpmd_socket:0")
++set(TPM_STORAGE_NAME
"/private/var/lib/tpm/tpm_emulator-1_2_${${PROJECT_NAME}_VERSION_MAJOR}_$=
{${PROJECT_NAME}_VERSION_MINOR}")
++set(TPM_DEVICE_NAME "/dev/tpm")
++else()
++set(TPM_LOG_FILE "/var/log/tpmd.log")
++set(TPM_SOCKET_NAME "/var/run/tpm/tpmd_socket:0")
++set(TPM_STORAGE_NAME
"/var/lib/tpm/tpm_emulator-1_2_${${PROJECT_NAME}_VERSION_MAJOR}_${${PROJE=
CT_NAME}_VERSION_MINOR}")
++set(TPM_DEVICE_NAME "/dev/tpm")
++endif()
++configure_file(${CMAKE_CURRENT_SOURCE_DIR}/config.h.in
${CMAKE_CURRENT_BINARY_DIR}/config.h)
++add_definitions(-Wall -Werror -Wno-unused-parameter -Wpointer-arith
-Wcast-align -Wwrite-strings)
++if("${CMAKE_SYSTEM}" MATCHES "Linux")
++    add_definitions(-Wextra)
++endif()
++if(USE_OPENSSL)
++    add_definitions(-DUSE_OPENSSL)
++endif()
++include_directories("/opt/local/include")
++link_directories("/opt/local/lib")
++
++# configure CPack
++set(CPACK_PACKAGE_VERSION_MAJOR ${${PROJECT_NAME}_VERSION_MAJOR})
++set(CPACK_PACKAGE_VERSION_MINOR ${${PROJECT_NAME}_VERSION_MINOR})
++set(CPACK_SOURCE_PACKAGE_FILE_NAME
"tpm_emulator-${CPACK_PACKAGE_VERSION_MAJOR}.${CPACK_PACKAGE_VERSION_MINO=
R}.4")
++set(CPACK_SOURCE_GENERATOR "TGZ")
++set(CPACK_SOURCE_IGNORE_FILES ".svn/" "/build/" "/.project" "/.cproject=
")
++set(CPACK_GENERATOR "ZIP")
++set(CPACK_SET_DESTDIR ON)
++include(CPack)
++
++# include root directories
++include_directories(${CMAKE_SOURCE_DIR})
++include_directories(${CMAKE_BINARY_DIR})
++
++# add internal libraries
++add_subdirectory(tpm)
++add_subdirectory(mtm)
++add_subdirectory(crypto)
++
++# add TDDL
++add_subdirectory(tddl)
++
++# add kernel modules
++add_subdirectory(tpmd_dev)
++
++# add executables
++add_subdirectory(tpmd)
++
+diff -Naur tpm_emulator-0.7.4-orig/tpm/tpm_emulator_extern.h
tpm_emulator-0.7.4/tpm/tpm_emulator_extern.h
+--- tpm_emulator-0.7.4-orig/tpm/tpm_emulator_extern.h    2012-09-17
13:16:27.834582486 -0400
++++ tpm_emulator-0.7.4/tpm/tpm_emulator_extern.h    2012-09-17
13:16:41.621654594 -0400
+@@ -29,6 +29,8 @@
+   TPM_LOG_ERROR
+ };
+
++extern int dmi_id;
++
+ void (*tpm_log)(int priority, const char *fmt, ...);
+
+ #if defined(_WIN32) || defined(_WIN64)
+@@ -37,12 +39,16 @@
+ #define __BFILE__ ((strrchr(__FILE__, '/') ? : __FILE__ - 1) + 1)
+ #endif
+
+-#define debug(fmt, ...) tpm_log(TPM_LOG_DEBUG, "%s:%d: Debug: " fmt
"\n", \
+-                                __BFILE__, __LINE__, ## __VA_ARGS__)
+-#define info(fmt, ...)  tpm_log(TPM_LOG_INFO, "%s:%d: Info: " fmt "\n",=
 \
+-                                __BFILE__, __LINE__, ## __VA_ARGS__)
+-#define error(fmt, ...) tpm_log(TPM_LOG_ERROR, "%s:%d: Error: " fmt
"\n", \
+-                                __BFILE__, __LINE__, ## __VA_ARGS__)
++#define debug(fmt, ...) tpm_log(TPM_LOG_DEBUG, "VTPMD[%d]: %s:%d:
Debug: " fmt "\n", \
++                                dmi_id, __BFILE__, __LINE__, ##
__VA_ARGS__)
++#define info(fmt, ...)  tpm_log(TPM_LOG_INFO, "VTPMD[%d]: %s:%d: Info:
" fmt "\n", \
++                                dmi_id, __BFILE__, __LINE__, ##
__VA_ARGS__)
++#define error(fmt, ...) tpm_log(TPM_LOG_ERROR, "VTPMD[%d]: %s:%d:
Error: " fmt "\n", \
++                                dmi_id, __BFILE__, __LINE__, ##
__VA_ARGS__)
++#define debug_nostop(fmt, ...) tpm_log(TPM_LOG_DEBUG, "VTPMD[%d]:
%s:%d: Debug: " fmt, \
++                                dmi_id, __BFILE__, __LINE__, ##
__VA_ARGS__)
++#define debug_more(fmt, ...) tpm_log(TPM_LOG_DEBUG, fmt, ## __VA_ARGS__=
)
++
+ /* initialization */
+ int (*tpm_extern_init)(void);
+ void (*tpm_extern_release)(void);
+diff -Naur tpm_emulator-0.7.4-orig/tpmd/unix/tpmd.c
tpm_emulator-0.7.4/tpmd/unix/tpmd.c
+--- tpm_emulator-0.7.4-orig/tpmd/unix/tpmd.c    2012-09-17
13:16:27.839582511 -0400
++++ tpm_emulator-0.7.4/tpmd/unix/tpmd.c    2012-09-17
13:16:41.623654604 -0400
+@@ -30,9 +30,31 @@
+ #include <grp.h>
+ #include "config.h"
+ #include "tpm/tpm_emulator.h"
++#include "tpm/tpm_structures.h"
++#include "tpm/tpm_marshalling.h"
++#include "vtpm_manager.h"
+
+ #define TPM_COMMAND_TIMEOUT 30
+
++#define TPM_DAEMON_NAME     "tpmd"
++#define TPM_CMD_BUF_SIZE    4096
++#define TPM_RANDOM_DEVICE   "/dev/urandom"
++#undef  TPM_MKDIRS
++
++#define PVM_RX_FIFO_D "/var/vtpm/fifos/tpm_cmd_to_%d.fifo"
++#define PVM_TX_FIFO "/var/vtpm/fifos/tpm_rsp_from_all.fifo"
++#define HVM_RX_FIFO_D "/var/vtpm/socks/%d.socket"
++
++#define VTPM_RX_FIFO_D "/var/vtpm/fifos/vtpm_rsp_to_%d.fifo"
++#define VTPM_TX_FIFO "/var/vtpm/fifos/vtpm_cmd_from_all.fifo"
++
++static char *vtpm_rx_name=3DNULL;
++
++static int vtpm_tx_fh=3D-1, vtpm_rx_fh=3D-1;
++
++#define BUFFER_SIZE 2048
++
++
+ static volatile int stopflag =3D 0;
+ static int is_daemon =3D 0;
+ static int opt_debug =3D 0;
+@@ -44,6 +66,9 @@
+ static uint32_t tpm_config =3D 0;
+ extern const char *tpm_storage_file;
+
++static int vtpm_type =3D VTPM_TYPE_PVM;
++int dmi_id;
++
+ void my_log(int priority, const char *fmt, ...)
+ {
+     va_list ap, bp;
+@@ -156,35 +181,218 @@
+             exit(EXIT_SUCCESS);
+         }
+     } else {
+-        /* if no startup mode is given assume save if a configuration
+-           file is available, clear otherwise */
+-        int fh =3D open(tpm_storage_file, O_RDONLY);
+-        if (fh < 0) {
+-            tpm_startup =3D 1;
+-            info("no startup mode was specified; asuming 'clear'");
+-        } else {
+-            tpm_startup =3D 2;
+-            close(fh);
+-        }
++       tpm_startup =3D 1;
++       info("no startup mode was specified; asuming 'clear'");
+     }
++    /* GET VM TYPE */
++    ++optind;
++    if (optind < argc) {
++       if(!strcmp(argv[optind], "pvm")) {
++      vtpm_type =3D VTPM_TYPE_PVM;      // Get commands from vTPM
Manager through fifo
++       } else if (!strcmp(argv[optind], "hvm")) {
++      vtpm_type =3D VTPM_TYPE_HVM;      // Get commands from qemu via s=
ocket
++       } else {
++      error("Invalid vm mode '%s'; must be 'pvm', "
++        "or 'hvm' ", argv[optind]);
++      print_usage(argv[0]);
++      exit(EXIT_SUCCESS);
++       }
++    } else {
++       vtpm_type =3D VTPM_TYPE_PVM;
++       info("no vm mode specified; assuming 'pvm'");
++    }
++    /* GET DMI ID */
++    ++optind;
++    if(optind >=3D argc || sscanf(argv[optind], "%d", &dmi_id) !=3D 1) =
{
++       error("Missing or non-integer dmi_id specified!");
++       print_usage(argv[0]);
++       exit(EXIT_SUCCESS);
++    }
++}
++
++int vtpm_write_to_file(uint8_t *data, size_t data_length)
++{
++  int res, out_data_size, in_header_size;
++  BYTE *ptr, *out_data, *in_header;
++  UINT32 result, len, in_rsp_size;
++  UINT16 tag =3D VTPM_TAG_REQ;
++
++  printf("Saving NVM\n");
++  if (vtpm_tx_fh < 0) {
++     vtpm_tx_fh =3D open(VTPM_TX_FIFO, O_WRONLY);
++  }
++
++  if (vtpm_tx_fh < 0) {
++                return -1;
++  }
++
++  // Send request to VTPM Manager to encrypt data
++  out_data_size =3D len =3D VTPM_COMMAND_HEADER_SIZE_SRV + data_length;=

++
++  out_data =3D ptr =3D (BYTE *) malloc(len);
++
++  if (ptr =3D=3D NULL
++    || tpm_marshal_UINT32(&ptr, &len, dmi_id)
++    || tpm_marshal_UINT16(&ptr, &len, tag)
++    || tpm_marshal_UINT32(&ptr, &len, out_data_size - sizeof(uint32_t))=

++    || tpm_marshal_UINT32(&ptr, &len, VTPM_ORD_SAVENVM)
++    || tpm_marshal_BYTE_ARRAY(&ptr, &len, data, data_length)) {
++     free(out_data);
++     return -1;
++  }
++
++  printf("\tSending SaveNVM Command.\n");
++  res =3D write(vtpm_tx_fh, out_data, out_data_size);
++  free(out_data);
++  if (res !=3D out_data_size) return -1;
++
++  if (vtpm_rx_fh < 0) {
++    if (vtpm_rx_name =3D=3D NULL) {
++      vtpm_rx_name =3D malloc(10 + strlen(VTPM_RX_FIFO_D));
++      sprintf(vtpm_rx_name, VTPM_RX_FIFO_D, (uint32_t) dmi_id);
++    }
++        vtpm_rx_fh =3D open(vtpm_rx_name, O_RDONLY);
++  }
++
++  if (vtpm_rx_fh < 0) {
++                return -1;
++  }
++
++  // Read Header of response so we can get the size & status
++  in_header_size =3D len =3D VTPM_COMMAND_HEADER_SIZE_SRV;
++  in_header =3D ptr =3D malloc(in_header_size);
++
++  printf("\tReading SaveNVM header.\n");
++  res =3D read(vtpm_rx_fh, in_header, in_header_size);
++
++  if ( (res !=3D in_header_size)
++    || tpm_unmarshal_UINT32(&ptr, &len, (UINT32*)&dmi_id)
++    || tpm_unmarshal_UINT16(&ptr, &len, &tag)
++    || tpm_unmarshal_UINT32(&ptr, &len, &in_rsp_size)
++    || tpm_unmarshal_UINT32(&ptr, &len, &result) ) {
++     free(in_header);
++     return -1;
++  }
++  free(in_header);
++
++  if (result !=3D VTPM_SUCCESS) {
++      return -1;
++  }
++
++  printf("\tFinishing up SaveNVM\n");
++  return (0);
++}
++
++int vtpm_read_from_file(uint8_t **data, size_t *data_length)
++{
++   int res, out_data_size, in_header_size;
++   uint8_t *ptr, *out_data, *in_header;
++   UINT16 tag =3D VTPM_TAG_REQ;
++   UINT32 len, in_rsp_size, result;
++
++   printf("Loading NVM.\n");
++   if (vtpm_tx_fh < 0) {
++      vtpm_tx_fh =3D open(VTPM_TX_FIFO, O_WRONLY);
++   }
++
++   if (vtpm_tx_fh < 0) {
++      printf("Error in read_from_file:301\n");
++      return -1;
++   }
++
++   // Send request to VTPM Manager to encrypt data
++   out_data_size =3D len =3D VTPM_COMMAND_HEADER_SIZE_SRV;
++   out_data =3D ptr =3D (BYTE *) malloc(len);
++
++   if (ptr =3D=3D NULL
++     || tpm_marshal_UINT32(&ptr, &len, dmi_id)
++     || tpm_marshal_UINT16(&ptr, &len, tag)
++     || tpm_marshal_UINT32(&ptr, &len, out_data_size - sizeof(uint32_t)=
)
++     || tpm_marshal_UINT32(&ptr, &len, VTPM_ORD_LOADNVM)) {
++      free(out_data);
++      printf("Error in read_from_file:325\n");
++
++      return -1;
++   }
++
++   printf("\tSending LoadNVM command\n");
++   res =3D write(vtpm_tx_fh, out_data, out_data_size);
++   free(out_data);
++   if (res !=3D out_data_size)
++   {
++      printf("Error in read_from_file:335\n");
++      return -1;
++   }
++
++   if (vtpm_rx_fh < 0) {
++      if (vtpm_rx_name =3D=3D NULL) {
++     vtpm_rx_name =3D malloc(10 + strlen(VTPM_RX_FIFO_D));
++     sprintf(vtpm_rx_name, VTPM_RX_FIFO_D, (uint32_t) dmi_id);
++      }
++      vtpm_rx_fh =3D open(vtpm_rx_name, O_RDONLY);
++   }
++
++   if (vtpm_rx_fh < 0) {
++      printf("Error in read_from_file:352\n");
++      return -1;
++   }
++
++   // Read Header of response so we can get the size & status
++   in_header_size =3D len =3D VTPM_COMMAND_HEADER_SIZE_SRV;
++   in_header =3D ptr =3D malloc(in_header_size);
++
++   printf("\tReading LoadNVM header\n");
++   res =3D read(vtpm_rx_fh, in_header, in_header_size);
++
++   if ( (res !=3D in_header_size)
++     || tpm_unmarshal_UINT32(&ptr, &len, (UINT32*)&dmi_id)
++     || tpm_unmarshal_UINT16(&ptr, &len, &tag)
++     || tpm_unmarshal_UINT32(&ptr, &len, &in_rsp_size)
++     || tpm_unmarshal_UINT32(&ptr, &len, &result) ) {
++      free(in_header);
++      printf("Error in read_from_file:375\n");
++      return -1;
++   }
++   free(in_header);
++
++   if (result !=3D VTPM_SUCCESS) {
++      printf("Error in read_from_file:381\n");
++      return -1;
++   }
++
++   // Read Encrypted data from VTPM Manager
++   *data_length =3D in_rsp_size - VTPM_COMMAND_HEADER_SIZE_CLT;
++   *data =3D (uint8_t *) malloc(*data_length);
++
++   printf("\tReading clear data from LoadNVM.\n");
++   res =3D read(vtpm_rx_fh, *data, *data_length);
++
++   printf("\tReturing from loading NVM\n");
++   if (res !=3D (int)*data_length) {
++      free(*data);
++      printf("Error in read_from_file:398\n");
++      return -1;
++   } else {
++      return 0;
++   }
+ }
+
+ static void switch_uid_gid(void)
+ {
+-    if (opt_gid !=3D getgid()) {
+-        info("switching effective group ID to %d", opt_gid);
+-        if (setgid(opt_gid) =3D=3D -1) {
+-            error("switching effective group ID to %d failed: %s",
opt_gid, strerror(errno));
+-            exit(EXIT_FAILURE);
+-        }
+-    }
+-    if (opt_uid !=3D getuid()) {
+-        info("switching effective user ID to %d", opt_uid);
+-        if (setuid(opt_uid) =3D=3D -1) {
+-            error("switching effective user ID to %d failed: %s",
opt_uid, strerror(errno));
+-            exit(EXIT_FAILURE);
+-        }
+-    }
++   if (opt_gid !=3D getgid()) {
++      info("switching effective group ID to %d", opt_gid);
++      if (setgid(opt_gid) =3D=3D -1) {
++     error("switching effective group ID to %d failed: %s", opt_gid,
strerror(errno));
++     exit(EXIT_FAILURE);
++      }
++   }
++   if (opt_uid !=3D getuid()) {
++      info("switching effective user ID to %d", opt_uid);
++      if (setuid(opt_uid) =3D=3D -1) {
++     error("switching effective user ID to %d failed: %s", opt_uid,
strerror(errno));
++     exit(EXIT_FAILURE);
++      }
++   }
+ }
+
+ static void signal_handler(int sig)
+@@ -214,174 +422,175 @@
+     }
+ }
+
+-static void daemonize(void)
+-{
+-    pid_t sid, pid;
+-    info("daemonizing process");
+-    pid =3D fork();
+-    if (pid < 0) {
+-        error("fork() failed: %s", strerror(errno));
+-        exit(EXIT_FAILURE);
+-    }
+-    if (pid > 0) exit(EXIT_SUCCESS);
+-    pid =3D getpid();
+-    sid =3D setsid();
+-    if (sid < 0) {
+-        error("setsid() failed: %s", strerror(errno));
+-        exit(EXIT_FAILURE);
+-    }
+-    if (chdir("/") < 0) {
+-        error("chdir() failed: %s", strerror(errno));
+-        exit(EXIT_FAILURE);
+-    }
+-    close(STDIN_FILENO);
+-    close(STDOUT_FILENO);
+-    close(STDERR_FILENO);
+-    is_daemon =3D 1;
+-    info("process was successfully daemonized: pid=3D%d sid=3D%d", pid,=
 sid);
+-}
+-
+-static int mkdirs(const char *path)
+-{
+-    char *copy =3D strdup(path);
+-    char *p =3D strchr(copy + 1, '/');
+-    while (p !=3D NULL) {
+-        *p =3D '\0';
+-        if ((mkdir(copy, 0755) =3D=3D -1) && (errno !=3D EEXIST)) {
+-            free(copy);
+-            return errno;
+-        }
+-        *p =3D '/';
+-        p =3D strchr(p + 1, '/');
+-    }
+-    free(copy);
+-    return 0;
+-}
+-
+-static int init_socket(const char *name)
+-{
+-    int sock;
+-    struct sockaddr_un addr;
+-    info("initializing socket %s", name);
+-    sock =3D socket(AF_UNIX, SOCK_STREAM, 0);
+-    if (sock < 0) {
+-        error("socket(AF_UNIX) failed: %s", strerror(errno));
+-        return -1;
+-    }
+-    mkdirs(name);
+-    addr.sun_family =3D AF_UNIX;
+-    strncpy(addr.sun_path, name, sizeof(addr.sun_path));
+-    umask(0177);
+-    if (bind(sock, (struct sockaddr*)&addr, sizeof(addr)) < 0) {
+-        error("bind(%s) failed: %s", addr.sun_path, strerror(errno));
+-        close(sock);
+-        return -1;
+-    }
+-    listen(sock, 1);
+-    return sock;
+-}
+-
+ static void main_loop(void)
+ {
+-    int sock, fh, res;
+     int32_t in_len;
+     uint32_t out_len;
+-    uint8_t in[TPM_CMD_BUF_SIZE], *out;
++    uint8_t in[TPM_CMD_BUF_SIZE], *out, *addressed_out;
++    int guest_id=3D-1;
++    int i;
++    char *vtpm_rx_file=3DNULL;
++    int res;
++
++    int sockfd =3D -1;
+     struct sockaddr_un addr;
+-    socklen_t addr_len;
+-    fd_set rfds;
+-    struct timeval tv;
++    struct sockaddr_un client_addr;
++    unsigned int client_length;
++
++    int vtpm_tx_fh=3D-1, vtpm_rx_fh=3D-1;
++
++  if (vtpm_type =3D=3D VTPM_TYPE_PVM) {
++    vtpm_rx_file =3D malloc(10 + strlen(PVM_RX_FIFO_D));
++    sprintf(vtpm_rx_file, PVM_RX_FIFO_D, (uint32_t) dmi_id);
++  } else {
++    vtpm_rx_file =3D malloc(10 + strlen(HVM_RX_FIFO_D));
++    sprintf(vtpm_rx_file, HVM_RX_FIFO_D, (uint32_t) dmi_id);
++
++    if ( (sockfd =3D socket(PF_UNIX,SOCK_STREAM,0)) < 0) {
++          error("Unable to create socket. errno =3D %d\n", errno);
++      exit (-1);
++    }
++
++    memset(&addr, 0, sizeof(addr));
++    addr.sun_family =3D AF_UNIX;
++    strcpy(addr.sun_path,vtpm_rx_file );
++    unlink(addr.sun_path);
++  }
+
+     info("staring main loop");
+-    /* open UNIX socket */
+-    sock =3D init_socket(opt_socket_name);
+-    if (sock < 0) exit(EXIT_FAILURE);
+     /* init tpm emulator */
+-    debug("initializing TPM emulator");
+-    if (tpm_emulator_init(tpm_startup, tpm_config) !=3D 0) {
+-        error("tpm_emulator_init() failed");
+-        close(sock);
+-        unlink(opt_socket_name);
+-        exit(EXIT_FAILURE);
+-    }
++    debug("initializing TPM emulator: state=3D%d, type=3D%d, id=3D%d",
tpm_startup, vtpm_type, dmi_id);
++    /* Set config flags that must be on for vtpm operation */
++    tpm_config |=3D TPM_CONF_STRONG_PERSISTENCE;
++    tpm_config &=3D ~TPM_CONF_USE_INTERNAL_PRNG;
++    tpm_config |=3D TPM_CONF_GENERATE_EK;
++    tpm_config |=3D TPM_CONF_GENERATE_SEED_DAA;
++    /*Start the emulator */
++    tpm_emulator_init(tpm_startup, tpm_config);
+     /* start command processing */
+     while (!stopflag) {
+         /* wait for incomming connections */
+         debug("waiting for connections...");
+-        FD_ZERO(&rfds);
+-        FD_SET(sock, &rfds);
+-        tv.tv_sec =3D 10;
+-        tv.tv_usec =3D 0;
+-        res =3D select(sock + 1, &rfds, NULL, NULL, &tv);
+-        if (res < 0) {
+-            error("select(sock) failed: %s", strerror(errno));
+-            break;
+-        } else if (res =3D=3D 0) {
+-            continue;
++        if (vtpm_rx_fh < 0) {
++            if (vtpm_type =3D=3D VTPM_TYPE_PVM)
++            {
++                vtpm_rx_fh =3D open(vtpm_rx_file, O_RDONLY);
++            } else {
++                if (bind(sockfd, (struct sockaddr *)&addr,
sizeof(addr)) < 0) {
++                    error("Unable to bind(). errno =3D %d\n", errno);
++                    exit (-1);
++                }
++
++                if (listen(sockfd, 10) <0) {
++                    error("Unable to listen(). errno =3D %d\n", errno);=

++                    exit (-1);
++                }
++
++                 memset(&client_addr, 0, sizeof(client_addr));
++                 client_length =3D sizeof(client_addr);
++
++                 vtpm_rx_fh =3D vtpm_tx_fh =3D accept(sockfd, (struct
sockaddr *)&client_addr, &client_length);
++            }
+         }
+-        addr_len =3D sizeof(addr);
+-        fh =3D accept(sock, (struct sockaddr*)&addr, &addr_len);
+-        if (fh < 0) {
+-            error("accept() failed: %s", strerror(errno));
+-            continue;
++
++        /*Error Checking*/
++        if (vtpm_rx_fh < 0) {
++          error("Failed to open devices to listen to guest.\n");
++          exit(-1);
+         }
++
+         /* receive and handle commands */
+         in_len =3D 0;
+         do {
+             debug("waiting for commands...");
+-            FD_ZERO(&rfds);
+-            FD_SET(fh, &rfds);
+-            tv.tv_sec =3D TPM_COMMAND_TIMEOUT;
+-            tv.tv_usec =3D 0;
+-            res =3D select(fh + 1, &rfds, NULL, NULL, &tv);
+-            if (res < 0) {
+-                error("select(fh) failed: %s", strerror(errno));
+-                close(fh);
+-                break;
+-            } else if (res =3D=3D 0) {
+-#ifdef TPMD_DISCONNECT_IDLE_CLIENTS
+-                info("connection closed due to inactivity");
+-                close(fh);
+-                break;
+-#else
+-                continue;
+-#endif
+-            }
+-            in_len =3D read(fh, in, sizeof(in));
+-            if (in_len > 0) {
++
++            in_len =3D read(vtpm_rx_fh, in, sizeof(in));
++            /*Magic size of minimum TPM command is 6*/
++            if (in_len < 6) {
++                info("Recv incomplete command of %d bytes.", in_len);
++                if (in_len <=3D 0) {
++                    close(vtpm_rx_fh);
++                    vtpm_rx_fh =3D -1;
++                    continue;
++                 }
++            } else {
++                /*Debug Printouts*/
+                 debug("received %d bytes", in_len);
++                debug_nostop("Recv[%d]: 0x", in_len);
++                for (i=3D0; i< in_len; i++)
++                    debug_more("%02x ", in[i]);
++                debug_more("\n");
++                /*Multiple Guest check*/
++                if (guest_id =3D=3D -1) {
++                    guest_id =3D *((int32_t *) in);
++                } else {
++                    if (guest_id !=3D *((int32_t *) in) ) {
++                        error("WARNING: More than one guest attached\n"=
);
++                    }
++                }
++
++                /*Open tx handle now*/
++                if (vtpm_tx_fh < 0) {
++                    if (vtpm_type =3D=3D VTPM_TYPE_PVM) {
++                        vtpm_tx_fh =3D open(PVM_TX_FIFO, O_WRONLY);
++                    } // No need to open the other direction for HVM
++                }
++                if (vtpm_tx_fh < 0) {
++                  error("Failed to open devices to respond to guest.\n"=
);
++                  exit(-1);
++                }
++
++                /*Handle the TPM command now*/
+                 out =3D NULL;
+-                res =3D tpm_handle_command(in, in_len, &out, &out_len);=

++                res =3D tpm_handle_command(in + sizeof(uint32_t), in_le=
n
- sizeof(uint32_t), &out, &out_len);
+                 if (res < 0) {
+                     error("tpm_handle_command() failed");
+                 } else {
+                     debug("sending %d bytes", out_len);
+-                    uint32_t len =3D 0;
+-                    while (len < out_len) {
+-                        res =3D write(fh, &out[len], out_len - len);
++            //Prepend the dmi_id
++                    addressed_out =3D (uint8_t *)
tpm_malloc(sizeof(uint32_t) + out_len);
++                    *(uint32_t *) addressed_out =3D *(uint32_t *) in;
++                    memcpy(addressed_out + sizeof(uint32_t), out,
out_len);
++                    out_len +=3D sizeof(uint32_t);
++                    /*End Prepend*/
++
++                    /*Perform write operation now*/
++                    while (out_len > 0) {
++                        res =3D write(vtpm_tx_fh, addressed_out, out_le=
n);
++
+                         if (res < 0) {
+-                            error("write(%d) failed: %s",
+-                                  out_len - len, strerror(errno));
++                            error("write(%d) failed: %s", out_len,
strerror(errno));
+                             break;
++                        } else {
++                          debug_nostop("Sent[%Zu]: ", out_len);
++                          for (i=3D0; (unsigned int)i< out_len; i++)
++                            debug_more("%02x ", addressed_out[i]);
++                          debug_more("\n");
+                         }
+-                        len +=3D res;
++                        out_len -=3D res;
+                     }
+                     tpm_free(out);
++                    tpm_free(addressed_out);
+                 }
+             }
+         } while (in_len > 0);
+-        close(fh);
+     }
++
+     /* shutdown tpm emulator */
+     tpm_emulator_shutdown();
+-    /* close socket */
+-    close(sock);
+-    unlink(opt_socket_name);
++    /* Close handles */
++    close(vtpm_tx_fh);
++    close(vtpm_rx_fh);
++    free(vtpm_rx_file);
+     info("main loop stopped");
+ }
+
+ int main(int argc, char **argv)
+ {
++    //Set load/store functions
++    tpm_write_to_storage =3D vtpm_write_to_file;
++    tpm_read_from_storage =3D vtpm_read_from_file;
++
+     openlog(argv[0], 0, LOG_DAEMON);
+     setlogmask(~LOG_MASK(LOG_DEBUG));
+     syslog(LOG_INFO, "--- separator ---\n");
+@@ -393,8 +602,6 @@
+     switch_uid_gid();
+     /* init signal handlers */
+     init_signal_handler();
+-    /* unless requested otherwiese, fork and daemonize process */
+-    if (!opt_foreground) daemonize();
+     /* start main processing loop */
+     main_loop();
+     info("stopping TPM Emulator daemon");
+diff -Naur tpm_emulator-0.7.4-orig/tpmd/unix/tpmd.c.orig
tpm_emulator-0.7.4/tpmd/unix/tpmd.c.orig
+--- tpm_emulator-0.7.4-orig/tpmd/unix/tpmd.c.orig    1969-12-31
19:00:00.000000000 -0500
++++ tpm_emulator-0.7.4/tpmd/unix/tpmd.c.orig    2011-12-20
13:30:06.000000000 -0500
+@@ -0,0 +1,403 @@
++/* Software-based Trusted Platform Module (TPM) Emulator
++ * Copyright (C) 2004-2010 Mario Strasser <mast@gmx.net>
++ *
++ * 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.
++ *
++ * $Id: tpmd.c 463 2011-06-08 14:25:04Z mast $
++ */
++
++#include <stdio.h>
++#include <stdlib.h>
++#include <unistd.h>
++#include <signal.h>
++#include <string.h>
++#include <errno.h>
++#include <syslog.h>
++#include <stdarg.h>
++#include <fcntl.h>
++#include <sys/stat.h>
++#include <sys/socket.h>
++#include <sys/un.h>
++#include <pwd.h>
++#include <grp.h>
++#include "config.h"
++#include "tpm/tpm_emulator.h"
++
++#define TPM_COMMAND_TIMEOUT 30
++
++static volatile int stopflag =3D 0;
++static int is_daemon =3D 0;
++static int opt_debug =3D 0;
++static int opt_foreground =3D 0;
++static const char *opt_socket_name =3D TPM_SOCKET_NAME;
++static uid_t opt_uid =3D 0;
++static gid_t opt_gid =3D 0;
++static int tpm_startup =3D 2;
++static uint32_t tpm_config =3D 0;
++extern const char *tpm_storage_file;
++
++void my_log(int priority, const char *fmt, ...)
++{
++    va_list ap, bp;
++    va_start(ap, fmt);
++    va_copy(bp, ap);
++    switch (priority) {
++      case TPM_LOG_DEBUG:
++        vsyslog(LOG_DEBUG, fmt, ap);
++        break;
++      case TPM_LOG_ERROR:
++        vsyslog(LOG_ERR, fmt, ap);
++        break;
++      case TPM_LOG_INFO:
++      default:
++        vsyslog(LOG_INFO, fmt, ap);
++        break;
++    }
++    va_end(ap);
++    if (!is_daemon && (priority !=3D TPM_LOG_DEBUG || opt_debug)) {
++        vprintf(fmt, bp);
++    }
++    va_end(bp);
++}
++
++static void print_usage(char *name)
++{
++    printf("usage: %s [-d] [-f] [-s storage file] [-u unix socket name]=
 "
++           "[-o user name] [-g group name] [-h] [startup mode]\n", name=
);
++    printf("  d : enable debug mode\n");
++    printf("  f : forces the application to run in the foreground\n");
++    printf("  s : storage file to use (default: %s)\n", tpm_storage_fil=
e);
++    printf("  u : unix socket name to use (default: %s)\n",
opt_socket_name);
++    printf("  o : effective user the application should run as\n");
++    printf("  g : effective group the application should run as\n");
++    printf("  h : print this help message\n");
++    printf("  startup mode : must be 'clear', "
++           "'save' (default) or 'deactivated\n");
++}
++
++static void parse_options(int argc, char **argv)
++{
++    char c;
++    struct passwd *pwd;
++    struct group *grp;
++    opt_uid =3D getuid();
++    opt_gid =3D getgid();
++    info("parsing options");
++    while ((c =3D getopt (argc, argv, "dfs:u:o:g:c:h")) !=3D -1) {
++        debug("handling option '-%c'", c);
++        switch (c) {
++            case 'd':
++                opt_debug =3D 1;
++                setlogmask(setlogmask(0) | LOG_MASK(LOG_DEBUG));
++                debug("debug mode enabled");
++                break;
++            case 'f':
++                debug("application is forced to run in foreground");
++                opt_foreground =3D 1;
++                break;
++            case 's':
++                tpm_storage_file =3D optarg;
++                debug("using storage file '%s'", tpm_storage_file);
++                break;
++            case 'u':
++                opt_socket_name =3D optarg;
++                debug("using unix socket '%s'", opt_socket_name);
++                break;
++            case 'o':
++                pwd  =3D getpwnam(optarg);
++                if (pwd =3D=3D NULL) {
++                    error("invalid user name '%s'\n", optarg);
++                    exit(EXIT_FAILURE);
++                }
++                opt_uid =3D pwd->pw_uid;
++                break;
++            case 'g':
++                grp  =3D getgrnam(optarg);
++                if (grp =3D=3D NULL) {
++                    error("invalid group name '%s'\n", optarg);
++                    exit(EXIT_FAILURE);
++                }
++                opt_gid =3D grp->gr_gid;
++                break;
++            case 'c':
++                tpm_config =3D strtol(optarg, NULL, 0);
++                debug("tpm_config =3D %04x", tpm_config);
++                break;
++            case '?':
++                error("unknown option '-%c'", optopt);
++                print_usage(argv[0]);
++                exit(EXIT_FAILURE);
++            case 'h':
++            default:
++                print_usage(argv[0]);
++                exit(EXIT_SUCCESS);
++        }
++    }
++    if (optind < argc) {
++        debug("startup mode =3D '%s'", argv[optind]);
++        if (!strcmp(argv[optind], "clear")) {
++            tpm_startup =3D 1;
++        } else if (!strcmp(argv[optind], "save")) {
++            tpm_startup =3D 2;
++        } else if (!strcmp(argv[optind], "deactivated")) {
++            tpm_startup =3D 3;
++        } else {
++            error("invalid startup mode '%s'; must be 'clear', "
++                  "'save' (default) or 'deactivated", argv[optind]);
++            print_usage(argv[0]);
++            exit(EXIT_SUCCESS);
++        }
++    } else {
++        /* if no startup mode is given assume save if a configuration
++           file is available, clear otherwise */
++        int fh =3D open(tpm_storage_file, O_RDONLY);
++        if (fh < 0) {
++            tpm_startup =3D 1;
++            info("no startup mode was specified; asuming 'clear'");
++        } else {
++            tpm_startup =3D 2;
++            close(fh);
++        }
++    }
++}
++
++static void switch_uid_gid(void)
++{
++    if (opt_gid !=3D getgid()) {
++        info("switching effective group ID to %d", opt_gid);
++        if (setgid(opt_gid) =3D=3D -1) {
++            error("switching effective group ID to %d failed: %s",
opt_gid, strerror(errno));
++            exit(EXIT_FAILURE);
++        }
++    }
++    if (opt_uid !=3D getuid()) {
++        info("switching effective user ID to %d", opt_uid);
++        if (setuid(opt_uid) =3D=3D -1) {
++            error("switching effective user ID to %d failed: %s",
opt_uid, strerror(errno));
++            exit(EXIT_FAILURE);
++        }
++    }
++}
++
++static void signal_handler(int sig)
++{
++    info("signal received: %d", sig);
++    if (sig =3D=3D SIGTERM || sig =3D=3D SIGQUIT || sig =3D=3D SIGINT) =
stopflag =3D 1;
++}
++
++static void init_signal_handler(void)
++{
++    info("installing signal handlers");
++    if (signal(SIGTERM, signal_handler) =3D=3D SIG_ERR) {
++        error("signal(SIGTERM) failed: %s", strerror(errno));
++        exit(EXIT_FAILURE);
++    }
++    if (signal(SIGQUIT, signal_handler) =3D=3D SIG_ERR) {
++        error("signal(SIGQUIT) failed: %s", strerror(errno));
++        exit(EXIT_FAILURE);
++    }
++    if (signal(SIGINT, signal_handler) =3D=3D SIG_ERR) {
++        error("signal(SIGINT) failed: %s", strerror(errno));
++        exit(EXIT_FAILURE);
++    }
++    if (signal(SIGPIPE, signal_handler) =3D=3D SIG_ERR) {
++        error("signal(SIGPIPE) failed: %s", strerror(errno));
++        exit(EXIT_FAILURE);
++    }
++}
++
++static void daemonize(void)
++{
++    pid_t sid, pid;
++    info("daemonizing process");
++    pid =3D fork();
++    if (pid < 0) {
++        error("fork() failed: %s", strerror(errno));
++        exit(EXIT_FAILURE);
++    }
++    if (pid > 0) exit(EXIT_SUCCESS);
++    pid =3D getpid();
++    sid =3D setsid();
++    if (sid < 0) {
++        error("setsid() failed: %s", strerror(errno));
++        exit(EXIT_FAILURE);
++    }
++    if (chdir("/") < 0) {
++        error("chdir() failed: %s", strerror(errno));
++        exit(EXIT_FAILURE);
++    }
++    close(STDIN_FILENO);
++    close(STDOUT_FILENO);
++    close(STDERR_FILENO);
++    is_daemon =3D 1;
++    info("process was successfully daemonized: pid=3D%d sid=3D%d", pid,=
 sid);
++}
++
++static int mkdirs(const char *path)
++{
++    char *copy =3D strdup(path);
++    char *p =3D strchr(copy + 1, '/');
++    while (p !=3D NULL) {
++        *p =3D '\0';
++        if ((mkdir(copy, 0755) =3D=3D -1) && (errno !=3D EEXIST)) {
++            free(copy);
++            return errno;
++        }
++        *p =3D '/';
++        p =3D strchr(p + 1, '/');
++    }
++    free(copy);
++    return 0;
++}
++
++static int init_socket(const char *name)
++{
++    int sock;
++    struct sockaddr_un addr;
++    info("initializing socket %s", name);
++    sock =3D socket(AF_UNIX, SOCK_STREAM, 0);
++    if (sock < 0) {
++        error("socket(AF_UNIX) failed: %s", strerror(errno));
++        return -1;
++    }
++    mkdirs(name);
++    addr.sun_family =3D AF_UNIX;
++    strncpy(addr.sun_path, name, sizeof(addr.sun_path));
++    umask(0177);
++    if (bind(sock, (struct sockaddr*)&addr, sizeof(addr)) < 0) {
++        error("bind(%s) failed: %s", addr.sun_path, strerror(errno));
++        close(sock);
++        return -1;
++    }
++    listen(sock, 1);
++    return sock;
++}
++
++static void main_loop(void)
++{
++    int sock, fh, res;
++    int32_t in_len;
++    uint32_t out_len;
++    uint8_t in[TPM_CMD_BUF_SIZE], *out;
++    struct sockaddr_un addr;
++    socklen_t addr_len;
++    fd_set rfds;
++    struct timeval tv;
++
++    info("staring main loop");
++    /* open UNIX socket */
++    sock =3D init_socket(opt_socket_name);
++    if (sock < 0) exit(EXIT_FAILURE);
++    /* init tpm emulator */
++    debug("initializing TPM emulator");
++    if (tpm_emulator_init(tpm_startup, tpm_config) !=3D 0) {
++        error("tpm_emulator_init() failed");
++        close(sock);
++        unlink(opt_socket_name);
++        exit(EXIT_FAILURE);
++    }
++    /* start command processing */
++    while (!stopflag) {
++        /* wait for incomming connections */
++        debug("waiting for connections...");
++        FD_ZERO(&rfds);
++        FD_SET(sock, &rfds);
++        tv.tv_sec =3D 10;
++        tv.tv_usec =3D 0;
++        res =3D select(sock + 1, &rfds, NULL, NULL, &tv);
++        if (res < 0) {
++            error("select(sock) failed: %s", strerror(errno));
++            break;
++        } else if (res =3D=3D 0) {
++            continue;
++        }
++        addr_len =3D sizeof(addr);
++        fh =3D accept(sock, (struct sockaddr*)&addr, &addr_len);
++        if (fh < 0) {
++            error("accept() failed: %s", strerror(errno));
++            continue;
++        }
++        /* receive and handle commands */
++        in_len =3D 0;
++        do {
++            debug("waiting for commands...");
++            FD_ZERO(&rfds);
++            FD_SET(fh, &rfds);
++            tv.tv_sec =3D TPM_COMMAND_TIMEOUT;
++            tv.tv_usec =3D 0;
++            res =3D select(fh + 1, &rfds, NULL, NULL, &tv);
++            if (res < 0) {
++                error("select(fh) failed: %s", strerror(errno));
++                close(fh);
++                break;
++            } else if (res =3D=3D 0) {
++#ifdef TPMD_DISCONNECT_IDLE_CLIENTS
++                info("connection closed due to inactivity");
++                close(fh);
++                break;
++#else
++                continue;
++#endif
++            }
++            in_len =3D read(fh, in, sizeof(in));
++            if (in_len > 0) {
++                debug("received %d bytes", in_len);
++                out =3D NULL;
++                res =3D tpm_handle_command(in, in_len, &out, &out_len);=

++                if (res < 0) {
++                    error("tpm_handle_command() failed");
++                } else {
++                    debug("sending %d bytes", out_len);
++                    uint32_t len =3D 0;
++                    while (len < out_len) {
++                        res =3D write(fh, &out[len], out_len - len);
++                        if (res < 0) {
++                            error("write(%d) failed: %s",
++                                  out_len - len, strerror(errno));
++                            break;
++                        }
++                        len +=3D res;
++                    }
++                    tpm_free(out);
++                }
++            }
++        } while (in_len > 0);
++        close(fh);
++    }
++    /* shutdown tpm emulator */
++    tpm_emulator_shutdown();
++    /* close socket */
++    close(sock);
++    unlink(opt_socket_name);
++    info("main loop stopped");
++}
++
++int main(int argc, char **argv)
++{
++    openlog(argv[0], 0, LOG_DAEMON);
++    setlogmask(~LOG_MASK(LOG_DEBUG));
++    syslog(LOG_INFO, "--- separator ---\n");
++    tpm_log =3D my_log;
++    info("starting TPM Emulator daemon (1.2.%d.%d-%d)",
++         VERSION_MAJOR, VERSION_MINOR, VERSION_BUILD);
++    parse_options(argc, argv);
++    /* switch uid/gid if required */
++    switch_uid_gid();
++    /* init signal handlers */
++    init_signal_handler();
++    /* unless requested otherwiese, fork and daemonize process */
++    if (!opt_foreground) daemonize();
++    /* start main processing loop */
++    main_loop();
++    info("stopping TPM Emulator daemon");
++    closelog();
++    return EXIT_SUCCESS;
++}
diff --git a/tools/vtpm/vtpm.patch b/tools/vtpm/vtpm.patch
--- a/tools/vtpm/vtpm.patch
+++ /dev/null
@@ -1,716 +0,0 @@
-diff -uprN tpm_emulator/AUTHORS vtpm/AUTHORS
---- tpm_emulator/AUTHORS    2006-12-08 12:51:29.000000000 -0800
-+++ vtpm/AUTHORS    2006-12-13 16:38:52.000000000 -0800
-@@ -1,3 +1,3 @@
- Mario Strasser <mast@gmx.net>
- Heiko Stamer <stamer@gaos.org> [DAA]
--INTEL Corp <> [Dropped to Ring3]
-+INTEL Corp <> [VTPM Extensions]
-diff -uprN tpm_emulator/ChangeLog vtpm/ChangeLog
---- tpm_emulator/ChangeLog    2006-12-08 12:51:29.000000000 -0800
-+++ vtpm/ChangeLog    2006-12-13 16:38:52.000000000 -0800
-@@ -1,5 +1,6 @@
- ????-??-?? Intel Corp
-     * Moved module out of kernel to run as a ring 3 app
-+    * Modified save_to_file and load_from_file to call xen VTPM manager=

-
- 2006-06-23  Mario Strasser <mast@gmx.net>
-     * tpm_startup.c: behaviour of ST_CLEAR and storage of
-diff -uprN tpm_emulator/linux_module.h vtpm/linux_module.h
---- tpm_emulator/linux_module.h    2006-12-08 12:51:29.000000000 -0800
-+++ vtpm/linux_module.h    2007-01-09 14:49:06.000000000 -0800
-@@ -44,18 +44,26 @@
- #define TPM_DEVICE_NAME   "tpm"
- #define TPM_MODULE_NAME   "tpm_emulator"
-
-+/* debug and log output functions */
-+extern int dmi_id;
-+
- #ifdef DEBUG
--#define debug(fmt, ...) printf("TPMD: %s:%d: Debug: " fmt "\n", \
--                        __FILE__, __LINE__, ## __VA_ARGS__)
-+#define debug(fmt, ...) printf("TPMD[%d]: %s:%d: Debug: " fmt "\n", \
-+                        dmi_id, __FILE__, __LINE__, ## __VA_ARGS__)
-+#define debug_nostop(fmt, ...) printf("TPMD[%d]: %s:%d: Debug: " fmt, \=

-+                        dmi_id, __FILE__, __LINE__, ## __VA_ARGS__)
-+#define debug_more(fmt, ...) printf( fmt, ## __VA_ARGS__ )
- #else
- #define debug(fmt, ...)
-+#define debug_nostop(fmt, ...)
-+#define debug_more(fmt, ...)
- #endif
--#define info(fmt, ...)  printf("TPMD: %s:%d: Info: " fmt "\n", \
--                        __FILE__, __LINE__, ## __VA_ARGS__)
--#define error(fmt, ...) printf("TPMD: %s:%d: Error: " fmt "\n", \
--                        __FILE__, __LINE__, ## __VA_ARGS__)
--#define alert(fmt, ...) printf("TPMD: %s:%d: Alert: " fmt "\n", \
--                        __FILE__, __LINE__, ## __VA_ARGS__)
-+#define info(fmt, ...)  printf("TPMD[%d]: %s:%d: Info: " fmt "\n", \
-+                        dmi_id, __FILE__, __LINE__, ## __VA_ARGS__)
-+#define error(fmt, ...) printf("TPMD[%d]: %s:%d: Error: " fmt "\n", \
-+                        dmi_id, __FILE__, __LINE__, ## __VA_ARGS__)
-+#define alert(fmt, ...) printf("TPMD[%d]: %s:%d: Alert: " fmt "\n", \
-+                        dmi_id, __FILE__, __LINE__, ## __VA_ARGS__)
-
- /* memory allocation */
-
-diff -uprN tpm_emulator/Makefile vtpm/Makefile
---- tpm_emulator/Makefile    2006-12-08 12:51:29.000000000 -0800
-+++ vtpm/Makefile    2006-12-13 16:38:52.000000000 -0800
-@@ -7,7 +7,7 @@
- COMPILE_ARCH    ?=3D $(shell uname -m | sed -e s/i.86/x86_32/)
-
- # module settings
--BIN            :=3D tpm_emulator
-+BIN            :=3D vtpmd
- VERSION_MAJOR  :=3D 0
- VERSION_MINOR  :=3D 4
- VERSION_BUILD  :=3D $(shell date +"%s")
-@@ -22,7 +22,7 @@ TOOLS_INSTALL_DIR =3D $(DESTDIR)/usr/bin
-
- CC      :=3D gcc
- CFLAGS  +=3D -g -Wall $(INCLUDE) -DDEBUG
--CFLAGS  +=3D -I. -Itpm
-+CFLAGS  +=3D -I. -Itpm -I../../vtpm_manager/manager
-
- # Is the simulator running in it's own vm?
- #CFLAGS +=3D -DVTPM_MULTI_VM
-@@ -62,7 +62,6 @@ $(BIN):    $(src)/crypto/gmp.h $(src)/crypt
-
- install: $(BIN)
-     $(INSTALL_PROG) $(BIN) $(TOOLS_INSTALL_DIR)
--    @if [ ! -d "/var/tpm" ]; then mkdir /var/tpm; fi
-
- clean:
-     rm -f $(src)/crypto/gmp.h $(src)/crypto/libgmp.a $(OBJS)
-@@ -98,3 +97,4 @@ version:
-     @echo "#endif /* _TPM_VERSION_H_ */" >> $(src)/tpm_version.h
-
- .PHONY: all install clean dist gmp version
-+
-diff -uprN tpm_emulator/tpm/tpm_capability.c vtpm/tpm/tpm_capability.c
---- tpm_emulator/tpm/tpm_capability.c    2006-06-23 03:37:07.000000000
-0700
-+++ vtpm/tpm/tpm_capability.c    2007-01-10 10:00:49.000000000 -0800
-@@ -136,8 +136,18 @@ static TPM_RESULT cap_property(UINT32 su
-
-     case TPM_CAP_PROP_TIS_TIMEOUT:
-       debug("[TPM_CAP_PROP_TIS_TIMEOUT]");
--      /* TODO: TPM_CAP_PROP_TIS_TIMEOUT */
--      return TPM_FAIL;
-+      /* TODO: TPM_CAP_PROP_TIS_TIMEOUT: Measure these values and
determine correct ones */
-+      UINT32 len =3D *respSize =3D 16;
-+      BYTE *ptr =3D *resp =3D tpm_malloc(*respSize);
-+      if (ptr =3D=3D NULL ||
-+          tpm_marshal_UINT32(&ptr, &len, 200000) ||
-+          tpm_marshal_UINT32(&ptr, &len, 200000) ||
-+          tpm_marshal_UINT32(&ptr, &len, 200000) ||
-+          tpm_marshal_UINT32(&ptr, &len, 200000)) {
-+        tpm_free(*resp);
-+        return TPM_FAIL;
-+      }
-+      return TPM_SUCCESS;
-
-     case TPM_CAP_PROP_STARTUP_EFFECT:
-       debug("[TPM_CAP_PROP_STARTUP_EFFECT]");
-@@ -190,7 +200,11 @@ static TPM_RESULT cap_property(UINT32 su
-
-     case TPM_CAP_PROP_DURATION:
-       debug("[TPM_CAP_PROP_DURATION]");
--      /* TODO: TPM_CAP_PROP_DURATION */
-+      /* TODO: TPM_CAP_PROP_DURATION: Measure these values and return
accurate ones */
-+      BYTE dur[]=3D
{0x0,0x0,0x0,0xc,0x0,0x7,0xa1,0x20,0x0,0x1e,0x84,0x80,0x11,0xe1,0xa3,0x0}=
;
-+      *respSize =3D 16;
-+      *resp =3D tpm_malloc(*respSize);
-+      memcpy(*resp,dur,16);
-       return TPM_FAIL;
-
-     case TPM_CAP_PROP_ACTIVE_COUNTER:
-diff -uprN tpm_emulator/tpm/tpm_cmd_handler.c vtpm/tpm/tpm_cmd_handler.c=

---- tpm_emulator/tpm/tpm_cmd_handler.c    2008-02-27 16:35:41.000000000
-0500
-+++ vtpm/tpm/tpm_cmd_handler.c    2008-02-28 14:43:28.000000000 -0500
-@@ -94,12 +94,18 @@ void tpm_compute_out_param_digest(TPM_CO
-   sha1_ctx_t sha1;
-   UINT32 res =3D CPU_TO_BE32(rsp->result);
-   UINT32 ord =3D CPU_TO_BE32(ordinal);
-+  UINT32 offset =3D 0;
-
-   /* compute SHA1 hash */
-   sha1_init(&sha1);
-   sha1_update(&sha1, (BYTE*)&res, 4);
-   sha1_update(&sha1, (BYTE*)&ord, 4);
--  sha1_update(&sha1, rsp->param, rsp->paramSize);
-+  if (ordinal =3D=3D TPM_ORD_LoadKey2) {
-+      offset =3D 4;
-+  }
-+  if (rsp->paramSize - offset > 0) {
-+      sha1_update(&sha1, rsp->param + offset, rsp->paramSize - offset);=

-+  }
-   sha1_final(&sha1, rsp->auth1->digest);
-   if (rsp->auth2 !=3D NULL) memcpy(rsp->auth2->digest,
-     rsp->auth1->digest, sizeof(rsp->auth1->digest));
-diff -uprN tpm_emulator/tpm/tpm_data.c vtpm/tpm/tpm_data.c
---- tpm_emulator/tpm/tpm_data.c    2008-02-27 16:35:41.000000000 -0500
-+++ vtpm/tpm/tpm_data.c    2008-02-27 16:35:40.000000000 -0500
-@@ -1,6 +1,7 @@
- /* Software-Based Trusted Platform Module (TPM) Emulator for Linux
-  * Copyright (C) 2004 Mario Strasser <mast@gmx.net>,
-  *                    Swiss Federal Institute of Technology (ETH) Zuric=
h
-+ * Copyright (C) 2005 INTEL Corp
-  *
-  * This module is free software; you can redistribute it and/or modify
-  * it under the terms of the GNU General Public License as published
-@@ -15,10 +16,15 @@
-  * $Id: tpm_data.c 98 2006-05-07 14:16:29Z hstamer $
-  */
-
-+#include <sys/types.h>
-+#include <sys/stat.h>
-+#include <fcntl.h>
-+#include <unistd.h>
-+
- #include "tpm_emulator.h"
- #include "tpm_structures.h"
- #include "tpm_marshalling.h"
--#include "linux_module.h"
-+#include "vtpm_manager.h"
-
- TPM_DATA tpmData;
-
-@@ -158,45 +164,232 @@ void tpm_release_data(void)
- #include <sys/types.h>
- #include <sys/stat.h>
- #include <fcntl.h>
--#include <unistd.h>
-
--#define TPM_STORAGE_FILE "/var/tpm/tpm_emulator-1.2."
STR(VERSION_MAJOR) "." STR(VERSION_MINOR)
-+ static int vtpm_tx_fh=3D-1, vtpm_rx_fh=3D-1;
-+
-+#ifdef VTPM_MUTLI_VM
-+ #define DEV_FE "/dev/tpm"
-+#else
-+ #define VTPM_RX_FIFO_D  "/var/vtpm/fifos/vtpm_rsp_to_%d.fifo"
-+ #define VTPM_TX_FIFO  "/var/vtpm/fifos/vtpm_cmd_from_all.fifo"
-+
-+ extern int dmi_id;
-+ static char *vtpm_rx_name=3DNULL;
-+#endif
-
- static int write_to_file(uint8_t *data, size_t data_length)
- {
--  int res;
--  int fp;
--  fp =3D open(TPM_STORAGE_FILE, O_WRONLY | O_TRUNC | O_CREAT, S_IRUSR |=

S_IWUSR);
--  res =3D write(fp, data, data_length);
--  close(fp);
--  return (res =3D=3D data_length) ? 0 : -1;
-+  int res, out_data_size, in_header_size;
-+  BYTE *ptr, *out_data, *in_header;
-+  UINT32 result, len, in_rsp_size;
-+  UINT16 tag =3D VTPM_TAG_REQ;
-+  =20
-+  printf("Saving NVM\n");
-+  if (vtpm_tx_fh < 0) {
-+#ifdef VTPM_MUTLI_VM
-+    vtpm_tx_fh =3D open(DEV_FE, O_RDWR);
-+#else
-+    vtpm_tx_fh =3D open(VTPM_TX_FIFO, O_WRONLY);
-+#endif
-+  }
-+
-+  if (vtpm_tx_fh < 0) {
-+        return -1;
-+  }
-+
-+  // Send request to VTPM Manager to encrypt data
-+#ifdef VTPM_MUTLI_VM
-+  out_data_size =3D len =3D VTPM_COMMAND_HEADER_SIZE_CLT + data_length;=

-+#else
-+  out_data_size =3D len =3D VTPM_COMMAND_HEADER_SIZE_SRV + data_length;=

-+#endif
-+=20
-+  out_data =3D ptr =3D (BYTE *) malloc(len);
-+
-+  if (ptr =3D=3D NULL
-+#ifndef VTPM_MUTLI_VM
-+      || tpm_marshal_UINT32(&ptr, &len, dmi_id)
-+#endif
-+      || tpm_marshal_UINT16(&ptr, &len, tag)
-+#ifdef VTPM_MUTLI_VM
-+      || tpm_marshal_UINT32(&ptr, &len, out_data_size)
-+#else
-+      || tpm_marshal_UINT32(&ptr, &len, out_data_size - sizeof(uint32_t=
))
-+#endif=20
-+      || tpm_marshal_UINT32(&ptr, &len, VTPM_ORD_SAVENVM)
-+      || tpm_marshal_BYTE_ARRAY(&ptr, &len, data, data_length)) {
-+    free(out_data);
-+    return -1;
-+  }
-+=20
-+  printf("\tSending SaveNVM Command.\n");
-+  res =3D write(vtpm_tx_fh, out_data, out_data_size);
-+  free(out_data);
-+  if (res !=3D out_data_size) return -1;
-+
-+  if (vtpm_rx_fh < 0) {
-+#ifdef VTPM_MUTLI_VM
-+    vtpm_rx_fh =3D vtpm_tx_fh
-+#else
-+    if (vtpm_rx_name =3D=3D NULL) {
-+      vtpm_rx_name =3D malloc(10 + strlen(VTPM_RX_FIFO_D));
-+      sprintf(vtpm_rx_name, VTPM_RX_FIFO_D, (uint32_t) dmi_id);
-+    }
-+    vtpm_rx_fh =3D open(vtpm_rx_name, O_RDONLY);
-+#endif
-+  }
-+
-+  if (vtpm_rx_fh < 0) {
-+        return -1;
-+  }
-+=20
-+  // Read Header of response so we can get the size & status
-+#ifdef VTPM_MUTLI_VM
-+  in_header_size =3D len =3D VTPM_COMMAND_HEADER_SIZE_CLT;
-+#else
-+  in_header_size =3D len =3D VTPM_COMMAND_HEADER_SIZE_SRV;
-+#endif
-+  in_header =3D ptr =3D malloc(in_header_size);
-+=20
-+  printf("\tReading SaveNVM header.\n");
-+  res =3D read(vtpm_rx_fh, in_header, in_header_size);
-+
-+  if ( (res !=3D in_header_size)
-+#ifndef VTPM_MUTLI_VM
-+       || tpm_unmarshal_UINT32(&ptr, &len, (UINT32*)&dmi_id)
-+#endif
-+       || tpm_unmarshal_UINT16(&ptr, &len, &tag)
-+       || tpm_unmarshal_UINT32(&ptr, &len, &in_rsp_size)
-+       || tpm_unmarshal_UINT32(&ptr, &len, &result) ) {
-+      free(in_header);
-+      return -1;
-+  }
-+  free(in_header);
-+=20
-+  if (result !=3D VTPM_SUCCESS) {
-+      return -1;=20
-+  }
-+
-+#ifdef VTPM_MUTLI_VM
-+  close(vtpm_tx_fh); close(vtpm_rx_fh);
-+#endif
-+    =20
-+  printf("\tFinishing up SaveNVM\n");
-+  return (0);
- }
-
- static int read_from_file(uint8_t **data, size_t *data_length)
- {
--  int res;
--  int fp, file_status;
--  struct stat file_info;
--  fp =3D open(TPM_STORAGE_FILE, O_RDONLY, 0);
--  file_status =3D fstat(fp, &file_info);
--  if (file_status < 0) {
--    close(fp);
--    return -1;
--  }
-+  int res, out_data_size, in_header_size;
-+  uint8_t *ptr, *out_data, *in_header;
-+  UINT16 tag =3D VTPM_TAG_REQ;
-+  UINT32 len, in_rsp_size, result;
-+#ifdef VTPM_MUTLI_VM
-+    int vtpm_rx_fh, vtpm_tx_fh;
-+#endif
-+  =20
-+  printf("Loading NVM.\n");
-+  if (vtpm_tx_fh < 0) {
-+#ifdef VTPM_MUTLI_VM
-+    vtpm_tx_fh =3D open(DEV_FE, O_RDWR);
-+#else
-+    vtpm_tx_fh =3D open(VTPM_TX_FIFO, O_WRONLY);
-+#endif
-+  }
-
--  *data_length =3D file_info.st_size;
--  *data =3D tpm_malloc(*data_length);
--  if (*data =3D=3D NULL) {
--    close(fp);
-+  if (vtpm_tx_fh < 0) {
-+        return -1;
-+  }
-+
-+  // Send request to VTPM Manager to encrypt data
-+#ifdef VTPM_MUTLI_VM
-+  out_data_size =3D len =3D VTPM_COMMAND_HEADER_SIZE_CLT;
-+#else
-+  out_data_size =3D len =3D VTPM_COMMAND_HEADER_SIZE_SRV;
-+#endif
-+  out_data =3D ptr =3D (BYTE *) malloc(len);
-+
-+  if (ptr =3D=3D NULL
-+#ifndef VTPM_MUTLI_VM
-+      || tpm_marshal_UINT32(&ptr, &len, dmi_id)
-+#endif=20
-+      || tpm_marshal_UINT16(&ptr, &len, tag)
-+#ifdef VTPM_MUTLI_VM
-+      || tpm_marshal_UINT32(&ptr, &len, out_data_size)
-+#else
-+      || tpm_marshal_UINT32(&ptr, &len, out_data_size - sizeof(uint32_t=
))
-+#endif
-+      || tpm_marshal_UINT32(&ptr, &len, VTPM_ORD_LOADNVM)) {
-+    free(out_data);
-     return -1;
-   }
--  res =3D read(fp, *data, *data_length);
--  close(fp);
-+
-+  printf("\tSending LoadNVM command\n");
-+  res =3D write(vtpm_tx_fh, out_data, out_data_size);
-+  free(out_data);
-+  if (res !=3D out_data_size) return -1;
-+
-+    if (vtpm_rx_fh < 0) {
-+#ifdef VTPM_MUTLI_VM
-+    vtpm_rx_fh =3D vtpm_tx_fh;
-+#else
-+    if (vtpm_rx_name =3D=3D NULL) {
-+      vtpm_rx_name =3D malloc(10 + strlen(VTPM_RX_FIFO_D));
-+      sprintf(vtpm_rx_name, VTPM_RX_FIFO_D, (uint32_t) dmi_id);
-+    }
-+    vtpm_rx_fh =3D open(vtpm_rx_name, O_RDONLY);
-+#endif
-+  }
-+
-+  if (vtpm_rx_fh < 0) {
-+        return -1;
-+  }
-+=20
-+  // Read Header of response so we can get the size & status
-+#ifdef VTPM_MUTLI_VM
-+  in_header_size =3D len =3D VTPM_COMMAND_HEADER_SIZE_CLT;
-+#else
-+  in_header_size =3D len =3D VTPM_COMMAND_HEADER_SIZE_SRV;
-+#endif
-+  in_header =3D ptr =3D malloc(in_header_size);
-+=20
-+  printf("\tReading LoadNVM header\n");
-+  res =3D read(vtpm_rx_fh, in_header, in_header_size);
-+
-+  if ( (res !=3D in_header_size)
-+#ifndef VTPM_MUTLI_VM
-+       || tpm_unmarshal_UINT32(&ptr, &len, (UINT32*)&dmi_id)
-+#endif
-+       || tpm_unmarshal_UINT16(&ptr, &len, &tag)
-+       || tpm_unmarshal_UINT32(&ptr, &len, &in_rsp_size)
-+       || tpm_unmarshal_UINT32(&ptr, &len, &result) ) {
-+      free(in_header);
-+      return -1;
-+  }
-+  free(in_header);
-+=20
-+  if (result !=3D VTPM_SUCCESS) {
-+      return -1;=20
-+  }
-+
-+  // Read Encrypted data from VTPM Manager
-+  *data_length =3D in_rsp_size - VTPM_COMMAND_HEADER_SIZE_CLT;
-+  *data =3D (uint8_t *) malloc(*data_length);
-+
-+  printf("\tReading clear data from LoadNVM.\n");
-+  res =3D read(vtpm_rx_fh, *data, *data_length);
-+#ifdef VTPM_MUTLI_VM
-+  close(vtpm_rx_fh);close(vtpm_tx_fh);
-+#endif
-+  =20
-+  printf("\tReturing from loading NVM\n");
-   if (res !=3D *data_length) {
--    tpm_free(*data);
--    return -1;
-+      free(*data);
-+      return -1;
-+  } else {
-+      return 0;
-   }
--  return 0;
-+
- }
-
- #else
-diff -uprN tpm_emulator/tpmd.c vtpm/tpmd.c
---- tpm_emulator/tpmd.c    2006-12-08 12:51:29.000000000 -0800
-+++ vtpm/tpmd.c    2007-01-09 14:48:56.000000000 -0800
-@@ -21,12 +21,24 @@
- #include <sys/stat.h>
- #include <fcntl.h>
- #include <sys/time.h>
-+#include <sys/socket.h>
-+#include <sys/un.h>
-+#include <errno.h>
-
- #include "tpm_emulator.h"
-+#include "vtpm_manager.h"
-
--#define TPM_RX_FNAME "/var/tpm/tpm_in.fifo"
--#define TPM_TX_FNAME "/var/tpm/tpm_out.fifo"
-+#ifdef VTPM_MULTI_VM
-+ #define DEV_BE "/dev/vtpm"
-+#else
-+ #define PVM_RX_FIFO_D "/var/vtpm/fifos/tpm_cmd_to_%d.fifo"
-+ #define PVM_TX_FIFO "/var/vtpm/fifos/tpm_rsp_from_all.fifo"
-
-+ #define HVM_RX_FIFO_D "/var/vtpm/socks/%d.socket"
-+#endif
-+
-+ int dmi_id;
-+                      =20
- #define BUFFER_SIZE 2048
-
- static int devurandom=3D0;
-@@ -38,7 +50,7 @@ void get_random_bytes(void *buf, int nby
-   }
-
-   if (read(devurandom, buf, nbytes) !=3D nbytes) {
--      printf("Can't get random number.\n");
-+      error("Can't get random number.\n");
-       exit(-1);
-   }
- }
-@@ -52,105 +64,182 @@ uint64_t tpm_get_ticks(void)
-
- int main(int argc, char **argv)
- {
--  uint8_t in[BUFFER_SIZE], *out;
-+  uint8_t type, in[BUFFER_SIZE], *out, *addressed_out;
-+  char *vtpm_rx_file=3DNULL;
-   uint32_t out_size;
-   int in_size, written;
--  int i;
--  struct stat file_info;
-+  int i, guest_id=3D-1;
-
--  int tpm_tx_fh=3D-1, tpm_rx_fh=3D-1;
-+#ifndef VTPM_MULTI_VM
-+  int sockfd =3D -1;
-+  struct sockaddr_un addr;
-+  struct sockaddr_un client_addr;
-+  unsigned int client_length;
-+
-+#endif
-+
-+  int vtpm_tx_fh=3D-1, vtpm_rx_fh=3D-1;
-+#ifdef VTPM_MULTI_VM
-   if (argc < 2) {
--    printf("Usage: tpmd clear|save|deactivated\n" );
-+    error("Usage: tpmd clear|save|deactivated\n" );
-+#else
-+  if (argc < 4) {
-+    error("Usage: tpmd clear|save|deactivated pvm|hvm vtpmid\n" );
-+#endif
-       return -1;
-   }
-
-+#ifndef VTPM_MULTI_VM
-+  /* setup type of vm */
-+  if (!strcmp(argv[2], "pvm")) {
-+    type =3D VTPM_TYPE_PVM; // Get commands from vTPM Manager through f=
ifo
-+  } else if (!strcmp(argv[2], "hvm")) {
-+    type =3D VTPM_TYPE_HVM; // Get commands from qemu via socket
-+  } else {
-+    error("invalid vTPM type '%s'.\n", argv[2]);
-+  }
-+
-+  dmi_id =3D atoi(argv[3]);
-+
-+  if (type =3D=3D VTPM_TYPE_PVM) {
-+    vtpm_rx_file =3D malloc(10 + strlen(PVM_RX_FIFO_D));
-+    sprintf(vtpm_rx_file, PVM_RX_FIFO_D, (uint32_t) dmi_id);
-+  } else {
-+    vtpm_rx_file =3D malloc(10 + strlen(HVM_RX_FIFO_D));
-+    sprintf(vtpm_rx_file, HVM_RX_FIFO_D, (uint32_t) dmi_id);
-+
-+    if ( (sockfd =3D socket(PF_UNIX,SOCK_STREAM,0)) < 0) {
-+          error("Unable to create socket. errno =3D %d\n", errno);
-+      exit (-1);
-+    }
-+
-+    memset(&addr, 0, sizeof(addr));
-+    addr.sun_family =3D AF_UNIX;
-+    strcpy(addr.sun_path,vtpm_rx_file );
-+    unlink(addr.sun_path);
-+  }
-+#endif
-+
-+#ifdef VTPM_MULTI_VM
-+  info("Initializing tpm state: %s\n", argv[1]);
-+#else
-+  info("Initializing tpm state: %s, type: %s, id: %d\n", argv[1],
argv[2], dmi_id);
-+#endif
-+
-   /* initialize TPM emulator */
-   if (!strcmp(argv[1], "clear")) {
--    printf("Initializing tpm: %s\n", argv[1]);
-     tpm_emulator_init(1);
--  } else if (!strcmp(argv[1], "save")) {
--    printf("Initializing tpm: %s\n", argv[1]);
-+  } else if (!strcmp(argv[1], "save")) {
-     tpm_emulator_init(2);
-   } else if (!strcmp(argv[1], "deactivated")) {
--    printf("Initializing tpm: %s\n", argv[1]);
-     tpm_emulator_init(3);
-   } else {
--    printf("invalid startup mode '%s'; must be 'clear', "
-+    error("invalid startup mode '%s'; must be 'clear', "
-       "'save' (default) or 'deactivated", argv[1]);
-     return -1;
-   }
--
--  if ( stat(TPM_RX_FNAME, &file_info) =3D=3D -1) {
--    if ( mkfifo(TPM_RX_FNAME, S_IWUSR | S_IRUSR ) ) {
--      printf("Failed to create fifo %s.\n", TPM_RX_FNAME);
--      return -1;
--    }
--  }
--
--  if ( stat(TPM_TX_FNAME, &file_info) =3D=3D -1) {
--    if ( mkfifo(TPM_TX_FNAME, S_IWUSR | S_IRUSR ) ) {
--      printf("Failed to create fifo %s.\n", TPM_TX_FNAME);
--      return -1;
--    }
--  }
--
-+=20
-   while (1) {
- abort_command:
--    if (tpm_rx_fh < 0) {
--      tpm_rx_fh =3D open(TPM_RX_FNAME, O_RDONLY);
-+    if (vtpm_rx_fh < 0) {
-+#ifdef VTPM_MUTLI_VM
-+      vtpm_rx_fh =3D open(DEV_BE, O_RDWR);
-+#else
-+      if (type =3D=3D VTPM_TYPE_PVM) {
-+        vtpm_rx_fh =3D open(vtpm_rx_file, O_RDONLY);
-+      } else {
-+        if (bind(sockfd, (struct sockaddr *)&addr, sizeof(addr)) < 0) {=

-+          error("Unable to bind(). errno =3D %d\n", errno);
-+          exit (-1);
-+        }
-+
-+        if (listen(sockfd, 10) <0) {
-+          error("Unable to listen(). errno =3D %d\n", errno);
-+          exit (-1);
-+        }
-+
-+        memset(&client_addr, 0, sizeof(client_addr));
-+        client_length =3D sizeof(client_addr);
-+
-+        vtpm_rx_fh =3D vtpm_tx_fh =3D accept(sockfd, (struct sockaddr
*)&client_addr, &client_length);
-+      }
-+#endif
-     }
-   =20
--    if (tpm_rx_fh < 0) {
--      printf("ERROR: failed to open devices to listen to guest.\n");
-+    if (vtpm_rx_fh < 0) {
-+      error("Failed to open devices to listen to guest.\n");
-       return -1;
-     }
-   =20
--    if (tpm_tx_fh < 0) {
--      tpm_tx_fh =3D open(TPM_TX_FNAME, O_WRONLY);
--    }
--
--    if (tpm_tx_fh < 0) {
--      printf("ERROR: failed to open devices to respond to guest.\n");
--      return -1;
--    }
--
--    in_size =3D read(tpm_rx_fh, in, BUFFER_SIZE);
-+    in_size =3D read(vtpm_rx_fh, in, BUFFER_SIZE);
-     if (in_size < 6) { // Magic size of minium TPM command
--      printf("Recv[%d] to small: 0x", in_size);
-+      info("Recv incomplete command of %d bytes.", in_size);
-       if (in_size <=3D 0) {
--          close(tpm_rx_fh);
--          tpm_rx_fh =3D -1;
-+          close(vtpm_rx_fh);
-+          vtpm_rx_fh =3D -1;
-           goto abort_command;
-       }
-     } else {
--      printf("Recv[%d]: 0x", in_size);
-+      debug_nostop("Recv[%d]: 0x", in_size);
-       for (i=3D0; i< in_size; i++)
--        printf("%x ", in[i]);
--      printf("\n");
-+        debug_more("%x ", in[i]);
-+      debug_more("\n");
-     }
-
--  =20
--    if (tpm_handle_command(in, in_size, &out, &out_size) !=3D 0) {
--        printf("ERROR: Handler Failed.\n");
-+    if (guest_id =3D=3D -1) {
-+        guest_id =3D *((uint32_t *) in);
-+    } else {
-+        if (guest_id !=3D *((uint32_t *) in) ) {
-+            error("WARNING: More than one guest attached\n");
-+        }
-+    }
-+
-+    if (vtpm_tx_fh < 0) {
-+#ifdef VTPM_MUTLI_VM
-+      vtpm_tx_fh =3D open(DEV_BE, O_RDWR);
-+      vtpm_rx_fh =3D vtpm_tx_fh;
-+#else
-+      if (type =3D=3D VTPM_TYPE_PVM) {
-+        vtpm_tx_fh =3D open(PVM_TX_FIFO, O_WRONLY);
-+      } // No need to open the other direction for HVM
-+#endif
-+    }
-+
-+    if (vtpm_tx_fh < 0) {
-+      error("Failed to open devices to respond to guest.\n");
-+      return -1;
-+    }
-+
-+    // Handle the command, but skip the domain id header  =20
-+    if (tpm_handle_command(in + sizeof(uint32_t), in_size -
sizeof(uint32_t), &out, &out_size) !=3D 0) {
-+      error("Handler Failed.\n");
-     }
-
--    written =3D write(tpm_tx_fh, out, out_size);
-+    addressed_out =3D (uint8_t *) tpm_malloc(sizeof(uint32_t) + out_siz=
e);
-+    *(uint32_t *) addressed_out =3D *(uint32_t *) in;
-+    memcpy(addressed_out + sizeof(uint32_t), out, out_size);
-+
-+    written =3D write(vtpm_tx_fh, addressed_out, out_size +
sizeof(uint32_t));
-
--    if (written !=3D out_size ) {
--      printf("ERROR: Part of response not written %d/%d.\nAttempt: ",
written, out_size);
-+    if (written !=3D out_size + sizeof(uint32_t)) {
-+      error("Part of response not written %d/%d.\n", written, out_size)=
;
-     } else {
--      printf("Sent[%Zu]: ", out_size);
-+      debug_nostop("Sent[%Zu]: ", out_size + sizeof(uint32_t));
-+      for (i=3D0; i< out_size+ sizeof(uint32_t); i++)
-+        debug_more("%x ", addressed_out[i]);
-+      debug_more("\n");
-     }
--    for (i=3D0; i< out_size; i++)
--      printf("%x ", out[i]);
--    printf("\n");
-     tpm_free(out);
-+    tpm_free(addressed_out);
-
-   } // loop
-
-   tpm_emulator_shutdown();
-
--  close(tpm_tx_fh);
--  close(tpm_rx_fh);
-+  close(vtpm_tx_fh);
-+#ifndef VTPM_MUTLI_VM
-+  close(vtpm_rx_fh);
-+  free (vtpm_rx_file);
-+#endif
-
- }





--------------ms070902070202080609000704
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIDyjCC
A8YwggMvoAMCAQICBD/xyf0wDQYJKoZIhvcNAQEFBQAwLzELMAkGA1UEBhMCVVMxDzANBgNV
BAoTBkpIVUFQTDEPMA0GA1UECxMGQklTRENBMB4XDTEwMDYxMTE4MjIwNloXDTEzMDYxMTE4
NTIwNlowZjELMAkGA1UEBhMCVVMxDzANBgNVBAoTBkpIVUFQTDEPMA0GA1UECxMGUGVvcGxl
MTUwFgYDVQQLEw9WUE5Hcm91cC1CSVNEQ0EwGwYDVQQDExRNYXR0aGV3IEUgRmlvcmF2YW50
ZTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAnpbwVSP6o1Nb5lcW7dd3yTo9iBJdi7qz
4nANOMFPK7JOy5npKN1iiousl28U/scUJES55gPwAWYJK3uVyQAsA4adgDKi5DoD1UHDQEwp
bY7iHLJeq0NPr4BqYNqnCFPbE6HC8zSJrr4qKn+gVUQT39SIFqdiIPJwZL8FYTRQ/zsCAwEA
AaOCAbYwggGyMAsGA1UdDwQEAwIHgDArBgNVHRAEJDAigA8yMDEwMDYxMTE4MjIwNlqBDzIw
MTIwNzE3MjI1MjA2WjAbBg0rBgEEAbMlCwMBAQEBBAoWCGZpb3JhbWUxMBsGDSsGAQQBsyUL
AwEBAQIEChIIMDAxMDQyNjEwWAYJYIZIAYb6ax4BBEsMSVRoZSBwcml2YXRlIGtleSBjb3Jy
ZXNwb25kaW5nIHRvIHRoaXMgY2VydGlmaWNhdGUgbWF5IGhhdmUgYmVlbiBleHBvcnRlZC4w
KAYDVR0RBCEwH4EdTWF0dGhldy5GaW9yYXZhbnRlQGpodWFwbC5lZHUwUgYDVR0fBEswSTBH
oEWgQ6RBMD8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJU0RD
QTEOMAwGA1UEAxMFQ1JMNTYwHwYDVR0jBBgwFoAUCDUpmxH52EU2CyWmF2EJMB1yqeswHQYD
VR0OBBYEFO6LYxg6r9wHZ+zdQtBHn1dZ/YTNMAkGA1UdEwQCMAAwGQYJKoZIhvZ9B0EABAww
ChsEVjcuMQMCBLAwDQYJKoZIhvcNAQEFBQADgYEAJO9HQh4YNChVLzuZqK5ARJARD8JoujGZ
fdo75quvg2jXFQe2sEjvLnxJZgm/pv8fdZakq48CWwjYHKuvIp7sDjTEsQfo+y7SpN/N2NvJ
WU5SqfK1VgYtNLRRoGJUB5Q1aZ+Dg95g3kqpyfpUMISJL8IKVLtJVfN4fggFVUYZ9wwxggGr
MIIBpwIBATA3MC8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJ
U0RDQQIEP/HJ/TAJBgUrDgMCGgUAoIHLMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ
KoZIhvcNAQkFMQ8XDTEyMDkyMTE4NTMwN1owIwYJKoZIhvcNAQkEMRYEFAyyf/i0y5rKwLIJ
rSvOqtpgwzLiMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAK
BggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI
KoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEgYAf9k9WKsOvnXozAPYht+KER/zQFGkL6OKp
fCyytOQZ5UDB9dtD5LXRHCvVGxN/4TARW0Tor1gM44sp/Xyfto5V6ql8XFnqTDXeMSzZWihO
NDyXwx5IJqhrZSGSh5HbD06t7Eej507GJcIotchx59NGzp0j5YRlMd1OLNq3QmkaBQAAAAAA
AA==
--------------ms070902070202080609000704--


--===============6507152100997419522==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============6507152100997419522==--


From xen-devel-bounces@lists.xen.org Fri Sep 21 18:58:55 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Sep 2012 18: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 1TF8R0-0001Zi-5m; Fri, 21 Sep 2012 18:58:42 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <matthew.fioravante@jhuapl.edu>) id 1TF8Qx-0001Zb-Fl
	for xen-devel@lists.xensource.com; Fri, 21 Sep 2012 18:58:40 +0000
Received: from [85.158.139.211:57965] by server-1.bemta-5.messagelabs.com id
	88/ED-04809-ED8BC505; Fri, 21 Sep 2012 18:58:38 +0000
X-Env-Sender: matthew.fioravante@jhuapl.edu
X-Msg-Ref: server-14.tower-206.messagelabs.com!1348253911!19446186!1
X-Originating-IP: [128.244.251.36]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG,
	UNPARSEABLE_RELAY,UPPERCASE_25_50
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23699 invoked from network); 21 Sep 2012 18:58:32 -0000
Received: from pilot.jhuapl.edu (HELO jhuapl.edu) (128.244.251.36)
	by server-14.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 21 Sep 2012 18:58:32 -0000
Received: from ([128.244.207.89])
	by pilot.jhuapl.edu with ESMTP with TLS id 63GHCH1.153409040;
	Fri, 21 Sep 2012 14:58:27 -0400
Message-ID: <505CB887.4090905@jhuapl.edu>
Date: Fri, 21 Sep 2012 14:57:11 -0400
From: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120827 Thunderbird/15.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>, 
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
X-Enigmail-Version: 1.4.4
Subject: [Xen-devel] PATCH [base vtpm and libxl patches 2/6] Bug fixes and
 breakout of vtpm_manager functionality
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1454697601346146772=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a cryptographically signed message in MIME format.

--===============1454697601346146772==
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms010302090205070800070309"

This is a cryptographically signed message in MIME format.

--------------ms010302090205070800070309
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Fix numerous memory leaks, IO deadlocks, and other bugs that make
vtpm_manager barely usable. Also breakout the vtpm_manager compilation
into separate libraries to facilitate reusing parts of it in mini-os
domains. Finally, add new programs for communicating with the manager
correctly to avoid IO deadlock errors.

Signed off by Matthew Fioravante matthew.fioravante@jhuapl.edu

---
Changed since previous:
* rebased off of latest xen-unstable

diff --git a/tools/vtpm_manager/Makefile b/tools/vtpm_manager/Makefile
--- a/tools/vtpm_manager/Makefile
+++ b/tools/vtpm_manager/Makefile
@@ -1,9 +1,9 @@
-XEN_ROOT =3D $(CURDIR)/../..
+XEN_ROOT =3D $(realpath ../..)
=20
 # Base definitions and rules
-include $(XEN_ROOT)/tools/vtpm_manager/Rules.mk
+include Rules.mk
=20
-SUBDIRS        =3D crypto tcs util manager migration
+SUBDIRS        =3D crypto tcs util manager migration vtpmmgrtalk vtpmcon=
nd
 OPENSSL_HEADER    =3D /usr/include/openssl/crypto.h
=20
 .PHONY: all clean install
diff --git a/tools/vtpm_manager/README b/tools/vtpm_manager/README
--- a/tools/vtpm_manager/README
+++ b/tools/vtpm_manager/README
@@ -43,9 +43,6 @@ Compile Flags
 LOGGING_MODULES              -> How extensive logging happens
                                 see util/log.h for more info
=20
-VTPM_MULTI_VM                -> Defined: VTPMs run in their own VMs
-                                Not Defined (default): VTPMs are process=
es
-
 # Debugging flags that may disappear without notice in the future
=20
 DUMMY_BACKEND                -> vtpm_manager listens on /tmp/in.fifo and=

@@ -59,6 +56,10 @@ WELL_KNOWN_OWNER_AUTH        -> Rather than randomly
generating the password for
                                 lost. However this has no protection
from malicious app
                                 issuing a TPM_OwnerClear to wipe the TPM=

=20
+VTPM_STUBDOM             -> vtpm_manager runs in vtpm_stubdom mode with
+                vtpm instances running in mini-os domains
+                (see: stubdom/vtpm/README for details)
+
 Requirements
 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
 - xen-unstable
diff --git a/tools/vtpm_manager/Rules.mk b/tools/vtpm_manager/Rules.mk
--- a/tools/vtpm_manager/Rules.mk
+++ b/tools/vtpm_manager/Rules.mk
@@ -6,7 +6,7 @@ include $(XEN_ROOT)/tools/Rules.mk
 #
=20
 # General compiler flags
-CFLAGS    =3D -Werror -g3
+CFLAGS    =3D -Werror -g3 -I.
=20
 # Generic project files
 HDRS    =3D $(wildcard *.h)
@@ -31,18 +31,18 @@ $(OBJS): $(SRCS)
 CFLAGS +=3D -D_GNU_SOURCE
=20
 # Logging Level. See utils/tools.h for usage
-CFLAGS +=3D
-DLOGGING_MODULES=3D"(BITMASK(VTPM_LOG_TCS)|BITMASK(VTPM_LOG_VTSP)|BITMAS=
K(VTPM_LOG_VTPM))"
+#CFLAGS +=3D
-DLOGGING_MODULES=3D"(BITMASK(VTPM_LOG_TCS)|BITMASK(VTPM_LOG_VTSP)|BITMAS=
K(VTPM_LOG_VTPM))"
=20
 # Silent Mode
 #CFLAGS +=3D -DLOGGING_MODULES=3D0x0
-#CFLAGS +=3D -DLOGGING_MODULES=3D0xff
-
-# Use frontend/backend pairs between manager & DMs?
-#CFLAGS +=3D -DVTPM_MULTI_VM
+CFLAGS +=3D -DLOGGING_MODULES=3D0xff
=20
 # vtpm_manager listens on fifo's rather than backend
 #CFLAGS +=3D -DDUMMY_BACKEND
=20
+# Build for use with vtpm-stubdom
+#CFLAGS +=3D -DVTPM_STUBDOM
+
 # TCS talks to fifo's rather than /dev/tpm. TPM Emulator assumed on fifo=
s
 #CFLAGS +=3D -DDUMMY_TPM
=20
@@ -52,8 +52,3 @@ CFLAGS +=3D
-DLOGGING_MODULES=3D"(BITMASK(VTPM_LOG_TCS)|BITMASK(VTPM_LOG_VTSP)|BITMA
 # Fixed OwnerAuth
 #CFLAGS +=3D -DWELL_KNOWN_OWNER_AUTH
=20
-# Include
-CFLAGS +=3D -I$(XEN_ROOT)/tools/vtpm_manager/crypto
-CFLAGS +=3D -I$(XEN_ROOT)/tools/vtpm_manager/util
-CFLAGS +=3D -I$(XEN_ROOT)/tools/vtpm_manager/tcs
-CFLAGS +=3D -I$(XEN_ROOT)/tools/vtpm_manager/manager
diff --git a/tools/vtpm_manager/crypto/Makefile
b/tools/vtpm_manager/crypto/Makefile
--- a/tools/vtpm_manager/crypto/Makefile
+++ b/tools/vtpm_manager/crypto/Makefile
@@ -1,5 +1,9 @@
-XEN_ROOT =3D $(CURDIR)/../../..
-include $(XEN_ROOT)/tools/vtpm_manager/Rules.mk
+XEN_ROOT =3D $(realpath ../../..)
+include ../Rules.mk
+
+CFLAGS +=3D -I../util
+CFLAGS +=3D -I../tcs
+CFLAGS +=3D -I../manager
=20
 BIN        =3D libtcpaCrypto.a
=20
diff --git a/tools/vtpm_manager/crypto/crypto.c
b/tools/vtpm_manager/crypto/crypto.c
--- a/tools/vtpm_manager/crypto/crypto.c
+++ b/tools/vtpm_manager/crypto/crypto.c
@@ -45,6 +45,8 @@
 #include "crypto.h"
 #include "log.h"
=20
+extern const EVP_CIPHER * SYM_CIPHER;
+
 /**
  * Initialize cryptography library
  * @rand: random seed
@@ -83,6 +85,6 @@ void Crypto_GetRandom(void* data, int size) {
   result =3D RAND_pseudo_bytes((BYTE*) data, size);
 =20
   if (result <=3D 0)
-    vtpmlogerror (VTPM_LOG_CRYPTO, "RAND_pseudo_bytes failed: %s\n",
-         ERR_error_string (ERR_get_error(), NULL));
+    vtpmlogerror (VTPM_LOG_CRYPTO, "RAND_pseudo_bytes failed: rc=3D%d
errstr=3D%s\n",
+      result, ERR_error_string (ERR_get_error(), NULL));
 }
diff --git a/tools/vtpm_manager/crypto/crypto.h
b/tools/vtpm_manager/crypto/crypto.h
--- a/tools/vtpm_manager/crypto/crypto.h
+++ b/tools/vtpm_manager/crypto/crypto.h
@@ -76,7 +76,7 @@ typedef struct CRYPTO_INFO {
=20
 void Crypto_Init(const BYTE* rand, int size);
=20
-void Crypto_Exit();
+void Crypto_Exit(void);
=20
 void Crypto_GetRandom(void* data, int size);
=20
@@ -127,6 +127,8 @@ void Crypto_RSABuildCryptoInfoPublic(   /*[IN]*/
UINT32 pubExpSize,
                                         /*[IN]*/ BYTE *modulus,
                                         CRYPTO_INFO* cryptoInfo);
=20
+void Crypto_RSACryptoInfoFree(CRYPTO_INFO* cryptoInfo);
+
 //
 // symmetric pack and unpack operations
 //
diff --git a/tools/vtpm_manager/crypto/rsa.c
b/tools/vtpm_manager/crypto/rsa.c
--- a/tools/vtpm_manager/crypto/rsa.c
+++ b/tools/vtpm_manager/crypto/rsa.c
@@ -149,6 +149,10 @@ void Crypto_RSABuildCryptoInfoPublic(   /*[IN]*/
UINT32 pubExpSize,
 =20
 }
=20
+void Crypto_RSACryptoInfoFree(CRYPTO_INFO* cryptoInfo) {
+   RSA_free(cryptoInfo->keyInfo);
+}
+
 int Crypto_RSAEnc(  CRYPTO_INFO *key,
             UINT32 inDataSize,
             BYTE *inData,
@@ -161,6 +165,7 @@ int Crypto_RSAEnc(  CRYPTO_INFO *key,
   =20
   if (paddedData =3D=3D NULL)
     return -1;
+  memset(paddedData, 0, sizeof(BYTE) * paddedDataSize);
=20
   *outDataSize =3D 0;
 =20
diff --git a/tools/vtpm_manager/crypto/sym_crypto.c
b/tools/vtpm_manager/crypto/sym_crypto.c
--- a/tools/vtpm_manager/crypto/sym_crypto.c
+++ b/tools/vtpm_manager/crypto/sym_crypto.c
@@ -41,8 +41,16 @@
 #include <openssl/rand.h>
=20
 #include "tcg.h"
+#include "log.h"
 #include "sym_crypto.h"
=20
+struct symkey_t {
+  buffer_t key;
+
+  EVP_CIPHER_CTX context;
+  const EVP_CIPHER * cipher;
+};
+
 typedef enum crypt_op_type_t {
   CRYPT_ENCRYPT,
   CRYPT_DECRYPT
@@ -61,19 +69,22 @@ const EVP_CIPHER * SYM_CIPHER =3D NULL;
 const BYTE ZERO_IV[EVP_MAX_IV_LENGTH] =3D {0};
=20
=20
-TPM_RESULT Crypto_symcrypto_initkey (symkey_t * key, const buffer_t*
keybits) {
+TPM_RESULT Crypto_symcrypto_initkey (symkey_t ** key, const buffer_t*
keybits) {
   TPM_RESULT status =3D TPM_SUCCESS;
 =20
-  EVP_CIPHER_CTX_init (&key->context);
+  *key =3D malloc(sizeof(symkey_t));
+
+  EVP_CIPHER_CTX_init (&(*key)->context);
 =20
-  key->cipher =3D SYM_CIPHER;
+  (*key)->cipher =3D SYM_CIPHER;
 =20
-  TPMTRYRETURN( buffer_init_copy (&key->key, keybits));
+  TPMTRYRETURN( buffer_init_copy (&(*key)->key, keybits));
   =20
   goto egress;
 =20
  abort_egress:
-  EVP_CIPHER_CTX_cleanup (&key->context);
+  EVP_CIPHER_CTX_cleanup (&(*key)->context);
+  free(key);
 =20
  egress:
 =20
@@ -82,19 +93,21 @@ TPM_RESULT Crypto_symcrypto_initkey (symkey_t * key,
const buffer_t* keybits) {
=20
=20
=20
-TPM_RESULT Crypto_symcrypto_genkey (symkey_t * key) {
+TPM_RESULT Crypto_symcrypto_genkey (symkey_t ** key) {
   int res;
   TPM_RESULT status =3D TPM_SUCCESS;
+
+  *key =3D malloc(sizeof(symkey_t));
 =20
   // hmm, EVP_CIPHER_CTX_init does not return a value
-  EVP_CIPHER_CTX_init (&key->context);
+  EVP_CIPHER_CTX_init (&(*key)->context);
 =20
-  key->cipher =3D SYM_CIPHER;
+  (*key)->cipher =3D SYM_CIPHER;
 =20
-  TPMTRYRETURN( buffer_init (&key->key,
EVP_CIPHER_key_length(key->cipher), NULL)) ;
+  TPMTRYRETURN( buffer_init (&(*key)->key,
EVP_CIPHER_key_length((*key)->cipher), NULL)) ;
 =20
   // and generate the key material
-  res =3D RAND_pseudo_bytes (key->key.bytes, key->key.size);
+  res =3D RAND_pseudo_bytes ((*key)->key.bytes, (*key)->key.size);
   if (res < 0)
     ERRORDIE (TPM_SHORTRANDOM);
 =20
@@ -102,8 +115,9 @@ TPM_RESULT Crypto_symcrypto_genkey (symkey_t * key) {=

   goto egress;
 =20
  abort_egress:
-  EVP_CIPHER_CTX_cleanup (&key->context);
-  buffer_free (&key->key);
+  EVP_CIPHER_CTX_cleanup (&(*key)->context);
+  buffer_free (&(*key)->key);
+  free(key);
 =20
  egress:
   return status;=20
@@ -119,11 +133,11 @@ TPM_RESULT Crypto_symcrypto_encrypt (symkey_t* key,=

 =20
   buffer_init_const (&iv, EVP_MAX_IV_LENGTH, ZERO_IV);
 =20
-  buffer_init (o_cipher,
-           clear->size +
-           EVP_CIPHER_iv_length(key->cipher) +
-           EVP_CIPHER_block_size (key->cipher),
-                 0);
+  TPMTRYRETURN( buffer_init (o_cipher,
+                  clear->size +
+                  EVP_CIPHER_iv_length(key->cipher) +
+                  EVP_CIPHER_block_size (key->cipher),
+                 0) );
 =20
   // copy the IV into the front
   buffer_copy (o_cipher, &iv);
@@ -139,6 +153,7 @@ TPM_RESULT Crypto_symcrypto_encrypt (symkey_t* key,
   goto egress;
 =20
  abort_egress:
+  buffer_free(o_cipher);
 =20
  egress:
 =20
@@ -170,7 +185,7 @@ TPM_RESULT Crypto_symcrypto_decrypt (symkey_t* key,
 =20
   // and decrypt
   TPMTRYRETURN ( ossl_symcrypto_op (key, &cipher_alias, &iv, o_clear,
CRYPT_DECRYPT) );
-=20
+
   goto egress;
 =20
  abort_egress:
@@ -188,6 +203,8 @@ TPM_RESULT Crypto_symcrypto_freekey (symkey_t * key) =
{
   buffer_free (&key->key);
 =20
   EVP_CIPHER_CTX_cleanup (&key->context);
+
+  free(key);
 =20
   return TPM_SUCCESS;
 }
@@ -235,3 +252,8 @@ TPM_RESULT ossl_symcrypto_op (symkey_t* key,
 =20
   return status;
 }
+
+buffer_t* Crypto_symkey_getkey(symkey_t* key)
+{
+   return &key->key;
+}
diff --git a/tools/vtpm_manager/crypto/sym_crypto.h
b/tools/vtpm_manager/crypto/sym_crypto.h
--- a/tools/vtpm_manager/crypto/sym_crypto.h
+++ b/tools/vtpm_manager/crypto/sym_crypto.h
@@ -40,21 +40,15 @@
 #ifndef _SYM_CRYPTO_H
 #define _SYM_CRYPTO_H
=20
-#include <openssl/evp.h>
 #include "buffer.h"
=20
-typedef struct symkey_t {
-  buffer_t key;
-=20
-  EVP_CIPHER_CTX context;
-  const EVP_CIPHER * cipher;
-} symkey_t;
+typedef struct symkey_t symkey_t;
=20
-extern const EVP_CIPHER * SYM_CIPHER;
+//Allocates a symkey with random bits
+TPM_RESULT Crypto_symcrypto_genkey (symkey_t ** key);
=20
-TPM_RESULT Crypto_symcrypto_genkey (symkey_t * key);
-
-TPM_RESULT Crypto_symcrypto_initkey (symkey_t * key, const buffer_t*
keybits);
+//Allocates a symkey with given keybits
+TPM_RESULT Crypto_symcrypto_initkey (symkey_t ** key, const buffer_t*
keybits);
=20
=20
 // these functions will allocate their output buffers
@@ -66,7 +60,10 @@ TPM_RESULT Crypto_symcrypto_decrypt (symkey_t* key,
                               const buffer_t* cipher,
                               buffer_t* o_clear);
=20
-// only free the internal parts, not the 'key' ptr
+//Frees the symkey
 TPM_RESULT Crypto_symcrypto_freekey (symkey_t * key);
=20
+//Get the raw key byte buffer
+buffer_t* Crypto_symkey_getkey(symkey_t* key);
+
 #endif /* _SYM_CRYPTO_H */
diff --git a/tools/vtpm_manager/manager/Makefile
b/tools/vtpm_manager/manager/Makefile
--- a/tools/vtpm_manager/manager/Makefile
+++ b/tools/vtpm_manager/manager/Makefile
@@ -1,7 +1,18 @@
-XEN_ROOT =3D $(CURDIR)/../../..
-include $(XEN_ROOT)/tools/vtpm_manager/Rules.mk
+XEN_ROOT =3D $(realpath ../../..)
+include ../Rules.mk
+
+CFLAGS +=3D -I../crypto
+CFLAGS +=3D -I../util
+CFLAGS +=3D -I../tcs
+
+
+MAINS         :=3D vtpmd.o
+MGRLIB         :=3D libvtpmmanager.a
+VTSPOBJS    :=3D vtsp.o
+VTSPLIB        :=3D libvtsp.a
+BIN        :=3D vtpm_managerd
+OBJS         :=3D $(filter-out $(MAINS) $(VTSPOBJS), $(OBJS))
=20
-BIN        =3D vtpm_managerd
=20
 .PHONY: all
 all: build
@@ -28,8 +39,14 @@ clean:
 mrproper: clean
     rm -f *~
=20
-$(BIN): $(OBJS)
-    $(CC) $(LDFLAGS) $^ $(LIBS) -o $@
+$(BIN): $(MAINS) $(MGRLIB) $(VTSPLIB)
+    $(CC) $(CFLAGS) $(LDFLAGS) $^ $(LIBS) -o $@
+
+$(VTSPLIB): $(VTSPOBJS)
+    $(AR) rcs $@ $^
+
+$(MGRLIB): $(OBJS)
+    $(AR) rcs $@ $^
=20
 # libraries
 LIBS +=3D ../tcs/libTCS.a ../util/libTCGUtils.a ../crypto/libtcpaCrypto.=
a
diff --git a/tools/vtpm_manager/manager/dmictl.c
b/tools/vtpm_manager/manager/dmictl.c
--- a/tools/vtpm_manager/manager/dmictl.c
+++ b/tools/vtpm_manager/manager/dmictl.c
@@ -40,6 +40,9 @@
 #include <stdio.h>
 #include <unistd.h>
 #include <string.h>
+#include <fcntl.h>
+#include <inttypes.h>
+#include <stdlib.h>
=20
 #include "vtpmpriv.h"
 #include "bsg.h"
@@ -51,6 +54,13 @@
=20
 #define TPM_EMULATOR_PATH "/usr/bin/vtpmd"
=20
+#ifndef VTPM_STUBDOM
+// This is needed to all extra_close_dmi to close this to prevent a
+// broken pipe when no DMIs are left.
+vtpm_ipc_handle_t *g_rx_tpm_ipc_h;
+#endif
+
+
 // if dmi_res is non-null, then return a pointer to new object.
 // Also, this does not fill in the measurements. They should be filled b=
y
 // design dependent code or saveNVM
@@ -81,7 +91,7 @@ TPM_RESULT init_dmi(UINT32 dmi_id, BYTE dmi_type,
VTPM_DMI_RESOURCE **dmi_res) {
=20
   // install into map
   if (!hashtable_insert(vtpm_globals->dmi_map, dmi_id_key, new_dmi)){
-    vtpmlogerror(VTPM_LOG_VTPM, "Failed to insert instance into table.
Aborting.\n", dmi_id);
+    vtpmlogerror(VTPM_LOG_VTPM, "Failed to insert instance %" PRIu32
"into table. Aborting.\n", dmi_id);
     status =3D TPM_FAIL;
     goto abort_egress;
   }
@@ -116,6 +126,161 @@ TPM_RESULT close_dmi(VTPM_DMI_RESOURCE *dmi_res) {
=20
   return (VTPM_Close_DMI_Extra(dmi_res) );
 }
+
+void free_dmi(VTPM_DMI_RESOURCE *dmi_res) {
+   if(dmi_res !=3D NULL) {
+      free(dmi_res->NVMLocation);
+   }
+   free(dmi_res);
+}
+
+TPM_RESULT VTPM_New_DMI_Extra(VTPM_DMI_RESOURCE *dmi_res, BYTE vm_type,
BYTE startup_mode) {
+
+  TPM_RESULT status =3D TPM_SUCCESS;
+#ifndef VTPM_STUBDOM
+  int fh;
+  char dmi_id_str[11]; // UINT32s are up to 10 digits + NULL
+  char *tx_vtpm_name, *tx_tpm_name, *vm_type_string;
+  struct stat file_info;
+
+  if (dmi_res->dmi_id =3D=3D VTPM_CTL_DM) {
+    dmi_res->tx_tpm_ipc_h =3D NULL;
+    dmi_res->rx_tpm_ipc_h =3D NULL;
+    dmi_res->tx_vtpm_ipc_h =3D NULL;
+    dmi_res->rx_vtpm_ipc_h =3D NULL;
+  } else {
+    // Create a pair of fifo pipes
+    dmi_res->rx_tpm_ipc_h =3D NULL;
+    dmi_res->rx_vtpm_ipc_h =3D NULL;
+
+    if ( ((dmi_res->tx_tpm_ipc_h =3D (vtpm_ipc_handle_t *) malloc
(sizeof(vtpm_ipc_handle_t))) =3D=3D NULL ) ||
+         ((dmi_res->tx_vtpm_ipc_h =3D(vtpm_ipc_handle_t *) malloc
(sizeof(vtpm_ipc_handle_t))) =3D=3D NULL ) ||
+         ((tx_tpm_name =3D (char *) malloc(11 +
strlen(VTPM_TX_TPM_FNAME))) =3D=3D NULL ) ||
+         ((tx_vtpm_name =3D(char *) malloc(11 +
strlen(VTPM_TX_VTPM_FNAME))) =3D=3D NULL) ) {
+      status =3DTPM_RESOURCES;
+      goto abort_egress;
+    }
+
+    sprintf(tx_tpm_name, VTPM_TX_TPM_FNAME, (uint32_t) dmi_res->dmi_id);=

+    sprintf(tx_vtpm_name, VTPM_TX_VTPM_FNAME, (uint32_t) dmi_res->dmi_id=
);
+
+    if ( (vtpm_ipc_init(dmi_res->tx_tpm_ipc_h, tx_tpm_name, O_WRONLY |
O_NONBLOCK, TRUE, FALSE) !=3D 0) ||
+         (vtpm_ipc_init(dmi_res->tx_vtpm_ipc_h, tx_vtpm_name, O_WRONLY,
TRUE, FALSE) !=3D 0) ) { //FIXME: O_NONBLOCK?
+      status =3D TPM_IOERROR;
+      goto abort_egress;
+    }
+
+    // Measure DMI
+    // FIXME: This will measure DMI. Until then use a fixed
DMI_Measurement value
+    // Also, this mechanism is specific to 1 VM architecture.
+    /*
+    fh =3D open(TPM_EMULATOR_PATH, O_RDONLY);
+    stat_ret =3D fstat(fh, &file_stat);
+    if (stat_ret =3D=3D 0)
+      dmi_size =3D file_stat.st_size;
+    else {
+      vtpmlogerror(VTPM_LOG_VTPM, "Could not open vtpmd!!\n");
+      status =3D TPM_IOERROR;
+      goto abort_egress;
+    }
+    dmi_buffer
+    */
+    memset(&dmi_res->DMI_measurement, 0xcc, sizeof(TPM_DIGEST));
+
+    if (vm_type =3D=3D VTPM_TYPE_PVM)
+      vm_type_string =3D (BYTE *)&VTPM_TYPE_PVM_STRING;
+    else
+      vm_type_string =3D (BYTE *)&VTPM_TYPE_HVM_STRING;
+
+    // Launch DMI
+    sprintf(dmi_id_str, "%d", (int) dmi_res->dmi_id);
+#ifdef MANUAL_DM_LAUNCH
+    vtpmlogerror(VTPM_LOG_VTPM, "Manually start VTPM with dmi=3D%s
now.\n", dmi_id_str);
+    dmi_res->dmi_pid =3D 0;
+#else
+    pid_t pid =3D fork();
+
+    if (pid =3D=3D -1) {
+      vtpmlogerror(VTPM_LOG_VTPM, "Could not fork to launch vtpm\n");
+      status =3D TPM_RESOURCES;
+      goto abort_egress;
+    } else if (pid =3D=3D 0) {
+      switch (startup_mode) {
+      case TPM_ST_CLEAR:
+        execl (TPM_EMULATOR_PATH, "vtpmd", "clear", vm_type_string,
dmi_id_str, NULL);
+        break;
+      case TPM_ST_STATE:
+        execl (TPM_EMULATOR_PATH, "vtpmd", "save", vm_type_string,
dmi_id_str, NULL);
+        break;
+      case TPM_ST_DEACTIVATED:
+        execl (TPM_EMULATOR_PATH, "vtpmd", "deactivated",
vm_type_string, dmi_id_str, NULL);
+        break;
+      default:
+        status =3D TPM_BAD_PARAMETER;
+        goto abort_egress;
+      }
+
+      // Returning from these at all is an error.
+      vtpmlogerror(VTPM_LOG_VTPM, "Could not exec to launch vtpm\n");
+    } else {
+      dmi_res->dmi_pid =3D pid;
+      vtpmloginfo(VTPM_LOG_VTPM, "Launching DMI on PID =3D %d\n", pid);
+    }
+#endif // MANUAL_DM_LAUNCH
+
+  } // If DMI =3D VTPM_CTL_DM
+    status =3D TPM_SUCCESS;
+#endif
+
+abort_egress:
+    //FIXME: Everything should be freed here
+  return (status);
+}
+
+TPM_RESULT VTPM_Close_DMI_Extra(VTPM_DMI_RESOURCE *dmi_res) {
+  TPM_RESULT status =3D TPM_SUCCESS;
+
+#ifndef VTPM_STUBDOM
+  if (vtpm_globals->connected_dmis =3D=3D 0) {
+    // No more DMI's connected. Close fifo to prevent a broken pipe.
+    // This is hackish. Need to think of another way.
+    vtpm_ipc_close(g_rx_tpm_ipc_h);
+  }
+
+
+  if (dmi_res->dmi_id !=3D VTPM_CTL_DM) {
+    vtpm_ipc_close(dmi_res->tx_tpm_ipc_h);
+    vtpm_ipc_close(dmi_res->tx_vtpm_ipc_h);
+
+    free(dmi_res->tx_tpm_ipc_h->name);
+    free(dmi_res->tx_vtpm_ipc_h->name);
+    free(dmi_res->tx_tpm_ipc_h);
+    free(dmi_res->tx_vtpm_ipc_h);
+
+#ifndef MANUAL_DM_LAUNCH
+    if (dmi_res->dmi_id !=3D VTPM_CTL_DM) {
+      if (dmi_res->dmi_pid !=3D 0) {
+        vtpmloginfo(VTPM_LOG_VTPM, "Killing dmi on pid %d.\n",
dmi_res->dmi_pid);
+        if (kill(dmi_res->dmi_pid, SIGKILL) !=3D0) {
+          vtpmloginfo(VTPM_LOG_VTPM, "DMI on pid %d is already
dead.\n", dmi_res->dmi_pid);
+        } else if (waitpid(dmi_res->dmi_pid, NULL, 0) !=3D
dmi_res->dmi_pid) {
+          vtpmlogerror(VTPM_LOG_VTPM, "DMI on pid %d failed to
stop.\n", dmi_res->dmi_pid);
+          status =3D TPM_FAIL;
+        }
+      } else {
+        vtpmlogerror(VTPM_LOG_VTPM, "Could not kill dmi because it's
pid was 0.\n");
+        status =3D TPM_FAIL;
+      }
+    }
+#endif
+
+  } //endif ! dom0
+#endif
+  return status;
+}
+
+
+
   =20
 TPM_RESULT VTPM_Handle_New_DMI(const buffer_t *param_buf) {
 =20
@@ -254,7 +419,7 @@ TPM_RESULT VTPM_Handle_Delete_DMI( const buffer_t
*param_buf) {
 =20
   // Close DMI first
   TPMTRYRETURN(close_dmi( dmi_res ));
-  free ( dmi_res );
+  free_dmi(dmi_res);
   =20
   status=3DTPM_SUCCESS;  =20
   goto egress;
diff --git a/tools/vtpm_manager/manager/migration.c
b/tools/vtpm_manager/manager/migration.c
--- a/tools/vtpm_manager/manager/migration.c
+++ b/tools/vtpm_manager/manager/migration.c
@@ -40,6 +40,7 @@
 #include <stdio.h>
 #include <unistd.h>
 #include <string.h>
+#include <stdlib.h>
=20
 #include "vtpmpriv.h"
 #include "bsg.h"
@@ -263,7 +264,7 @@ TPM_RESULT VTPM_Handle_Get_Migration_key( const
buffer_t *param_buf,
 TPM_RESULT VTPM_Handle_Load_Migration_key( const buffer_t *param_buf,
                                            buffer_t *result_buf) {
=20
-  TPM_RESULT status=3DTPM_FAIL;
+  TPM_RESULT status=3DTPM_SUCCESS;
   VTPM_MIGKEY_LIST *mig_key;
=20
   vtpmloginfo(VTPM_LOG_VTPM, "Loading Migration Public Key.\n");
@@ -303,5 +304,5 @@ TPM_RESULT VTPM_Handle_Load_Migration_key( const
buffer_t *param_buf,
   free(pubkey_exp_pack.data);
   free(pubkey_mod_pack.data);
=20
-  return TPM_SUCCESS;
+  return status;
 }
diff --git a/tools/vtpm_manager/manager/securestorage.c
b/tools/vtpm_manager/manager/securestorage.c
--- a/tools/vtpm_manager/manager/securestorage.c
+++ b/tools/vtpm_manager/manager/securestorage.c
@@ -42,7 +42,7 @@
 #include <fcntl.h>
 #include <unistd.h>
 #include <string.h>
-
+#include <stdlib.h>
 #include "tcg.h"
 #include "vtpm_manager.h"
 #include "vtpmpriv.h"
@@ -58,7 +58,7 @@ TPM_RESULT envelope_encrypt(const buffer_t     *inbuf,
                             CRYPTO_INFO        *asymkey,
                             buffer_t           *sealed_data) {
   TPM_RESULT status =3D TPM_SUCCESS;
-  symkey_t    symkey;
+  symkey_t    *symkey;
   buffer_t    data_cipher =3D NULL_BUF,
               symkey_cipher =3D NULL_BUF;
 =20
@@ -69,14 +69,14 @@ TPM_RESULT envelope_encrypt(const buffer_t     *inbuf=
,
   for (i=3D0; i< buffer_len(inbuf); i++)
     vtpmloginfomore(VTPM_LOG_VTPM_DEEP, "%x ", inbuf->bytes[i]);
   vtpmloginfomore(VTPM_LOG_VTPM_DEEP, "\n");
-=20
+
   // Generate a sym key and encrypt state with it
   TPMTRY(TPM_ENCRYPT_ERROR, Crypto_symcrypto_genkey (&symkey) );
-  TPMTRY(TPM_ENCRYPT_ERROR, Crypto_symcrypto_encrypt (&symkey, inbuf,
&data_cipher) );
+  TPMTRY(TPM_ENCRYPT_ERROR, Crypto_symcrypto_encrypt (symkey, inbuf,
&data_cipher) );
 =20
   // Encrypt symmetric key
   TPMTRYRETURN( VTSP_Bind(    asymkey,
-                  &symkey.key,
+                  Crypto_symkey_getkey(symkey),
                   &symkey_cipher) );
 =20
   // Create output blob: symkey_size + symkey_cipher +
state_cipher_size + state_cipher
@@ -86,8 +86,9 @@ TPM_RESULT envelope_encrypt(const buffer_t     *inbuf,
 =20
   data_cipher32.size =3D buffer_len(&data_cipher);
   data_cipher32.data =3D data_cipher.bytes;
-=20
+
   TPMTRYRETURN( buffer_init(sealed_data, 2 * sizeof(UINT32) +
symkey_cipher32.size + data_cipher32.size, NULL));
+  memset(sealed_data->bytes, 0, sealed_data->size);
 =20
   BSG_PackList(sealed_data->bytes, 2,
            BSG_TPM_SIZE32_DATA, &symkey_cipher32,
@@ -109,11 +110,37 @@ TPM_RESULT envelope_encrypt(const buffer_t     *inb=
uf,
 =20
   buffer_free ( &data_cipher);
   buffer_free ( &symkey_cipher);
-  Crypto_symcrypto_freekey (&symkey);
+  Crypto_symcrypto_freekey (symkey);
 =20
   return status;
 }
=20
+TPM_RESULT symkey_encrypt(const buffer_t     *inbuf,
+                            CRYPTO_INFO        *asymkey,
+                            buffer_t           *sealed_key) {
+  buffer_t symkey_cipher =3D NULL_BUF;
+  struct pack_constbuf_t symkey_cipher32;
+  TPM_RESULT status =3D TPM_SUCCESS;
+
+  // Encrypt symmetric key
+  TPMTRYRETURN( VTSP_Bind(    asymkey,
+                  inbuf,
+                  &symkey_cipher));
+
+  symkey_cipher32.size =3D buffer_len(&symkey_cipher);
+  symkey_cipher32.data =3D symkey_cipher.bytes;
+
+  TPMTRYRETURN( buffer_init(sealed_key, sizeof(UINT32) +
symkey_cipher32.size, NULL));
+  BSG_PackList(sealed_key->bytes, 1,
+           BSG_TPM_SIZE32_DATA, &symkey_cipher32);
+  goto egress;
+abort_egress:
+egress:
+  buffer_free( &symkey_cipher);
+  return status;
+}
+
+
 TPM_RESULT envelope_decrypt(const buffer_t     *cipher,
                             TCS_CONTEXT_HANDLE TCSContext,
                 TPM_HANDLE         keyHandle,
@@ -121,15 +148,13 @@ TPM_RESULT envelope_decrypt(const buffer_t   =20
*cipher,
                             buffer_t           *unsealed_data) {
=20
   TPM_RESULT status =3D TPM_SUCCESS;
-  symkey_t    symkey;
+  symkey_t    *symkey;
   buffer_t    data_cipher =3D NULL_BUF,
               symkey_clear =3D NULL_BUF,
               symkey_cipher =3D NULL_BUF;
-  struct pack_buf_t symkey_cipher32, data_cipher32;
+  struct pack_buf_t symkey_cipher32 =3D NULL_PACK_BUF, data_cipher32 =3D=

NULL_PACK_BUF;
   int i;
=20
-  memset(&symkey, 0, sizeof(symkey_t));
-
   vtpmloginfo(VTPM_LOG_VTPM_DEEP, "Envelope Decrypt Input[%d]: 0x",
buffer_len(cipher) );
   for (i=3D0; i< buffer_len(cipher); i++)
     vtpmloginfomore(VTPM_LOG_VTPM_DEEP, "%x ", cipher->bytes[i]);
@@ -159,7 +184,7 @@ TPM_RESULT envelope_decrypt(const buffer_t     *ciphe=
r,
   Crypto_symcrypto_initkey (&symkey, &symkey_clear);
 =20
   // Decrypt State
-  TPMTRY(TPM_DECRYPT_ERROR, Crypto_symcrypto_decrypt (&symkey,
&data_cipher, unsealed_data) );
+  TPMTRY(TPM_DECRYPT_ERROR, Crypto_symcrypto_decrypt (symkey,
&data_cipher, unsealed_data) );
=20
   vtpmloginfo(VTPM_LOG_VTPM_DEEP, "Envelope Decrypte Output[%d]: 0x",
buffer_len(unsealed_data));
   for (i=3D0; i< buffer_len(unsealed_data); i++)
@@ -175,26 +200,64 @@ TPM_RESULT envelope_decrypt(const buffer_t   =20
*cipher,
   buffer_free ( &data_cipher);
   buffer_free ( &symkey_clear);
   buffer_free ( &symkey_cipher);
-  Crypto_symcrypto_freekey (&symkey);
+  BSG_Destroy(BSG_TPM_SIZE32_DATA, &symkey_cipher32);
+  BSG_Destroy(BSG_TPM_SIZE32_DATA, &data_cipher32);
+  Crypto_symcrypto_freekey (symkey);
+
 =20
   return status;
 }
=20
+TPM_RESULT symkey_decrypt(const buffer_t     *cipher,
+                            TCS_CONTEXT_HANDLE TCSContext,
+                TPM_HANDLE         keyHandle,
+                const TPM_AUTHDATA *key_usage_auth,
+                            buffer_t           *symkey_clear) {
+
+  TPM_RESULT status =3D TPM_SUCCESS;
+  buffer_t    symkey_cipher =3D NULL_BUF;
+  struct pack_buf_t symkey_cipher32 =3D NULL_PACK_BUF;
+
+  BSG_UnpackList(cipher->bytes, 1,
+         BSG_TPM_SIZE32_DATA, &symkey_cipher32);
+
+  TPMTRYRETURN( buffer_init_alias_convert (&symkey_cipher,
+                           symkey_cipher32.size,
+                           symkey_cipher32.data) );
+
+  // Decrypt Symmetric Key
+  TPMTRYRETURN( VTSP_Unbind(  TCSContext,
+                  keyHandle,
+                  &symkey_cipher,
+                  key_usage_auth,
+                  symkey_clear,
+                  &(vtpm_globals->keyAuth) ) );
+
+  goto egress;
+ abort_egress:
+  vtpmlogerror(VTPM_LOG_VTPM, "Failed to decrypt symmetric key
status=3D%d\n.", status);
+
+ egress:
+  BSG_Destroy(BSG_TPM_SIZE32_DATA, &symkey_cipher32);
+  return status;
+}
+
 TPM_RESULT VTPM_Handle_Save_NVM(VTPM_DMI_RESOURCE *myDMI,
                 const buffer_t *inbuf,
                 buffer_t *outbuf) {
 =20
   TPM_RESULT status =3D TPM_SUCCESS;
-  int fh;
+  int fh =3D -1;
   long bytes_written;
   buffer_t sealed_NVM =3D NULL_BUF;
-=20
-  vtpmloginfo(VTPM_LOG_VTPM_DEEP, "Saving %d bytes of NVM.\n",
buffer_len(inbuf));
+  const buffer_t* nvmbuf =3D inbuf;
=20
-  TPMTRYRETURN( envelope_encrypt(inbuf,
+  vtpmloginfo(VTPM_LOG_VTPM_DEEP, "Saving %d bytes of NVM.\n",
buffer_len(nvmbuf));
+
+  TPMTRYRETURN( envelope_encrypt(nvmbuf,
                                  &vtpm_globals->storageKey,
                                  &sealed_NVM) );
-                =20
+
   // Write sealed blob off disk from NVMLocation
   // TODO: How to properly return from these. Do we care if we return
failure
   //       after writing the file? We can't get the old one back.
@@ -205,7 +268,6 @@ TPM_RESULT VTPM_Handle_Save_NVM(VTPM_DMI_RESOURCE
*myDMI,
     status =3D TPM_IOERROR;
     goto abort_egress;
   }
-  close(fh);
 =20
   Crypto_SHA1Full (sealed_NVM.bytes, buffer_len(&sealed_NVM), (BYTE *)
&myDMI->NVM_measurement); =20
 =20
@@ -215,6 +277,7 @@ TPM_RESULT VTPM_Handle_Save_NVM(VTPM_DMI_RESOURCE
*myDMI,
   vtpmlogerror(VTPM_LOG_VTPM, "Failed to save NVM\n.");
 =20
  egress:
+  close(fh);
   buffer_free(&sealed_NVM);
   return status;
 }
@@ -229,7 +292,8 @@ TPM_RESULT VTPM_Handle_Load_NVM(VTPM_DMI_RESOURCE
*myDMI,
=20
   buffer_t sealed_NVM =3D NULL_BUF;
   long fh_size;
-  int fh, stat_ret, i;
+  int fh =3D -1;
+  int stat_ret, i;
   struct stat file_stat;
   TPM_DIGEST sealedNVMHash;
  =20
@@ -241,6 +305,7 @@ TPM_RESULT VTPM_Handle_Load_NVM(VTPM_DMI_RESOURCE
*myDMI,
 =20
   //Read sealed blob off disk from NVMLocation
   fh =3D open(myDMI->NVMLocation, O_RDONLY);
+  printf("Filename: %s\n", myDMI->NVMLocation);
   stat_ret =3D fstat(fh, &file_stat);
   if (stat_ret =3D=3D 0)
     fh_size =3D file_stat.st_size;
@@ -254,7 +319,6 @@ TPM_RESULT VTPM_Handle_Load_NVM(VTPM_DMI_RESOURCE
*myDMI,
     status =3D TPM_IOERROR;
     goto abort_egress;
   }
-  close(fh);
 =20
   vtpmloginfo(VTPM_LOG_VTPM_DEEP, "Load_NVMing[%d],\n",
buffer_len(&sealed_NVM));
 =20
@@ -289,14 +353,128 @@ TPM_RESULT VTPM_Handle_Load_NVM(VTPM_DMI_RESOURCE
*myDMI,
 =20
  egress:
   buffer_free( &sealed_NVM );
+  close(fh);
+
+  return status;
+}
+
+TPM_RESULT VTPM_Handle_Load_HashKey(VTPM_DMI_RESOURCE *myDMI,
+                const buffer_t    *inbuf,
+                buffer_t          *outbuf) {
+
+  TPM_RESULT status =3D TPM_SUCCESS;
+
+  buffer_t sealed_NVM =3D NULL_BUF;
+  long fh_size;
+  int fh =3D -1;
+  int stat_ret, i;
+  struct stat file_stat;
+  TPM_DIGEST sealedNVMHash;
+
+  if (myDMI->NVMLocation =3D=3D NULL) {
+    vtpmlogerror(VTPM_LOG_VTPM, "Unable to load NVM because the file
name NULL.\n");
+    status =3D TPM_AUTHFAIL;
+    goto abort_egress;
+  }
+
+  //Read sealed blob off disk from NVMLocation
+  fh =3D open(myDMI->NVMLocation, O_RDONLY);
+  printf("Filename: %s\n", myDMI->NVMLocation);
+  stat_ret =3D fstat(fh, &file_stat);
+  if (stat_ret =3D=3D 0)
+    fh_size =3D file_stat.st_size;
+  else {
+    status =3D TPM_IOERROR;
+    goto abort_egress;
+  }
+
+  TPMTRYRETURN( buffer_init( &sealed_NVM, fh_size, NULL) );
+  if (read(fh, sealed_NVM.bytes, buffer_len(&sealed_NVM)) !=3D fh_size) =
{
+    status =3D TPM_IOERROR;
+    goto abort_egress;
+  }
+
+  vtpmloginfo(VTPM_LOG_VTPM_DEEP, "Loading %d byte encryption key,\n",
buffer_len(&sealed_NVM));
+
+  Crypto_SHA1Full(sealed_NVM.bytes, buffer_len(&sealed_NVM), (BYTE *)
&sealedNVMHash);
+
+  // Verify measurement of sealed blob.
+  if (memcmp(&sealedNVMHash, &myDMI->NVM_measurement,
sizeof(TPM_DIGEST)) ) {
+    vtpmlogerror(VTPM_LOG_VTPM, "VTPM LoadKey NVM measurement check
failed.\n");
+    vtpmloginfo(VTPM_LOG_VTPM_DEEP, "Correct hash: ");
+    for (i=3D0; i< sizeof(TPM_DIGEST); i++)
+      vtpmloginfomore(VTPM_LOG_VTPM_DEEP, "%x ",
((BYTE*)&myDMI->NVM_measurement)[i]);
+    vtpmloginfomore(VTPM_LOG_VTPM_DEEP, "\n");
+
+    vtpmloginfo(VTPM_LOG_VTPM_DEEP, "Measured hash: ");
+    for (i=3D0; i< sizeof(TPM_DIGEST); i++)
+      vtpmloginfomore(VTPM_LOG_VTPM_DEEP, "%x ",
((BYTE*)&sealedNVMHash)[i]);
+    vtpmloginfomore(VTPM_LOG_VTPM_DEEP, "\n");
+
+    status =3D TPM_AUTHFAIL;
+    goto abort_egress;
+  }
+
+  //Decrypt the key into the output buffer
+  TPMTRYRETURN( symkey_decrypt(&sealed_NVM,
+                                 myDMI->TCSContext,
+                 vtpm_globals->storageKeyHandle,
+                     (const
TPM_AUTHDATA*)&vtpm_globals->storage_key_usage_auth,
+                                 outbuf) );
+  goto egress;
+
+ abort_egress:
+  vtpmlogerror(VTPM_LOG_VTPM, "Failed to load Key\n.");
+
+ egress:
+  buffer_free( &sealed_NVM );
+  close(fh);
+
+  return status;
+}
+
+TPM_RESULT VTPM_Handle_Save_HashKey(VTPM_DMI_RESOURCE *myDMI,
+                                 const buffer_t    *inbuf,
+                 buffer_t          *outbuf) {
+  TPM_RESULT status =3D TPM_SUCCESS;
+  int fh =3D -1;
+  long bytes_written;
+  buffer_t sealed_key =3D NULL_BUF;
+
+  TPMTRYRETURN( symkey_encrypt(inbuf,
+                                 &vtpm_globals->storageKey,
+                                 &sealed_key) );
+
+  vtpmloginfo(VTPM_LOG_VTPM_DEEP, "Saving %d byte Encryption Key.\n",
buffer_len(inbuf));
+
+  // Write sealed blob off disk from NVMLocation
+  // TODO: How to properly return from these. Do we care if we return
failure
+  //       after writing the file? We can't get the old one back.
+  // TODO: Backup old file and try and recover that way.
+  fh =3D open(myDMI->NVMLocation, O_WRONLY | O_CREAT | O_TRUNC, S_IREAD =
|
S_IWRITE);
+  if ( (bytes_written =3D write(fh, sealed_key.bytes,
buffer_len(&sealed_key) ) !=3D (long) buffer_len(&sealed_key))) {
+    vtpmlogerror(VTPM_LOG_VTPM, "We just overwrote a DMI_NVM and failed
to finish. %ld/%ld bytes.\n", bytes_written, (long)buffer_len(&sealed_key=
));
+    status =3D TPM_IOERROR;
+    goto abort_egress;
+  }
 =20
+  Crypto_SHA1Full (sealed_key.bytes, buffer_len(&sealed_key), (BYTE *)
&myDMI->NVM_measurement);
+
+  goto egress;
+
+ abort_egress:
+  vtpmlogerror(VTPM_LOG_VTPM, "Failed to save Key\n.");
+
+ egress:
+  close(fh);
+  buffer_free(&sealed_key);
   return status;
 }
=20
=20
 TPM_RESULT VTPM_SaveManagerData(void) {
   TPM_RESULT status=3DTPM_SUCCESS;
-  int fh, dmis=3D-1;
+  int fh =3D -1, dmis=3D-1;
=20
   BYTE *flat_boot_key=3DNULL, *flat_dmis=3DNULL, *flat_enc=3DNULL;
   buffer_t clear_flat_global=3DNULL_BUF, enc_flat_global=3DNULL_BUF;
@@ -364,6 +542,7 @@ TPM_RESULT VTPM_SaveManagerData(void) {
                                         BSG_TPM_DIGEST,
&dmi_res->DMI_measurement);
=20
     } while (hashtable_iterator_advance(dmi_itr));
+    free(dmi_itr);
   }
=20
   fh =3D open(STATE_FILE, O_WRONLY | O_CREAT, S_IREAD | S_IWRITE);
@@ -389,6 +568,7 @@ TPM_RESULT VTPM_SaveManagerData(void) {
=20
   free(flat_boot_key);
   free(flat_enc);
+  buffer_free(&clear_flat_global);
   buffer_free(&enc_flat_global);
   free(flat_dmis);
   close(fh);
@@ -403,9 +583,10 @@ TPM_RESULT VTPM_LoadManagerData(void) {
   int fh, stat_ret, dmis=3D0;
   long fh_size =3D 0, step_size;
   BYTE *flat_table=3DNULL;
-  buffer_t  unsealed_data, enc_table_abuf;
-  struct pack_buf_t storage_key_pack, boot_key_pack;
-  UINT32 *dmi_id_key, enc_size;
+  buffer_t  unsealed_data =3D NULL_BUF;
+  buffer_t enc_table_abuf;
+  struct pack_buf_t storage_key_pack =3D NULL_PACK_BUF, boot_key_pack =3D=

NULL_PACK_BUF;
+  UINT32 enc_size;
   BYTE vtpm_manager_gen;
=20
   VTPM_DMI_RESOURCE *dmi_res;
@@ -438,9 +619,9 @@ TPM_RESULT VTPM_LoadManagerData(void) {
                               BSG_TPM_SIZE32_DATA, &boot_key_pack,
                               BSG_TYPE_UINT32, &enc_size);
=20
-  TPMTRYRETURN(buffer_init(&vtpm_globals->bootKeyWrap, 0, 0) );
   TPMTRYRETURN(buffer_init_alias_convert(&enc_table_abuf, enc_size,
flat_table + step_size) );
-  TPMTRYRETURN(buffer_append_raw(&vtpm_globals->bootKeyWrap,
boot_key_pack.size, boot_key_pack.data) );
+  TPMTRYRETURN(buffer_init(&vtpm_globals->bootKeyWrap,
boot_key_pack.size, boot_key_pack.data) );
+
=20
   //Load Boot Key
   TPMTRYRETURN( VTSP_LoadKey( vtpm_globals->manager_tcs_handle,
@@ -471,8 +652,8 @@ TPM_RESULT VTPM_LoadManagerData(void) {
                   BSG_TPM_SECRET,   &vtpm_globals->storage_key_usage_aut=
h,
                   BSG_TPM_SIZE32_DATA, &storage_key_pack);
=20
-  TPMTRYRETURN(buffer_init(&vtpm_globals->storageKeyWrap, 0, 0) );
-  TPMTRYRETURN(buffer_append_raw(&vtpm_globals->storageKeyWrap,
storage_key_pack.size, storage_key_pack.data) );
+  TPMTRYRETURN(buffer_init(&vtpm_globals->storageKeyWrap,
storage_key_pack.size, storage_key_pack.data) );
+
=20
   // Per DMI values to be saved
   while ( step_size < fh_size ){
@@ -501,7 +682,10 @@ TPM_RESULT VTPM_LoadManagerData(void) {
  abort_egress:
   vtpmlogerror(VTPM_LOG_VTPM, "Failed to load service data with error =3D=

%s\n", tpm_get_error_name(status));
  egress:
+  BSG_Destroy(BSG_TPM_SIZE32_DATA, &boot_key_pack);
+  BSG_Destroy(BSG_TPM_SIZE32_DATA, &storage_key_pack);
=20
+  buffer_free(&unsealed_data);
   free(flat_table);
   close(fh);
=20
diff --git a/tools/vtpm_manager/manager/vtpm_ipc.c
b/tools/vtpm_manager/manager/vtpm_ipc.c
--- a/tools/vtpm_manager/manager/vtpm_ipc.c
+++ b/tools/vtpm_manager/manager/vtpm_ipc.c
@@ -36,26 +36,49 @@
 //
 // =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
=20
+#include <sys/types.h>
 #include <sys/stat.h>
+#include <fcntl.h>
+#include <unistd.h>
+#include <sys/select.h>
 #include "vtpm_ipc.h"
 #include "vtpmpriv.h"
 #include "log.h"
=20
-int vtpm_ipc_init(vtpm_ipc_handle_t *ipc_h, char* name, int flags, BOOL
create) {
+volatile sig_atomic_t IPC_QUIT_FLAG =3D 0;
+
+const static struct timeval TIMEOUT =3D {
+   .tv_sec =3D 1,
+   .tv_usec =3D 0
+};
+
+int vtpm_ipc_init(vtpm_ipc_handle_t *ipc_h, char* name, int flags, BOOL
create, BOOL preopen) {
+  int rc;
+
   ipc_h->name =3D name;
   ipc_h->flags =3D flags;
   ipc_h->fh =3D VTPM_IPC_CLOSED;
=20
-  if (create)
-    return(vtpm_ipc_create(ipc_h));
-  else
-    return 0;
+  if (create) {
+    if((rc =3D vtpm_ipc_create(ipc_h) !=3D 0)) {
+       return rc;
+    }
+  }
+
+  if(preopen) {
+    ipc_h->fh =3D open(ipc_h->name, ipc_h->flags);
+    if ( ipc_h->fh =3D=3D VTPM_IPC_CLOSED ) {
+       vtpmlogerror(VTPM_LOG_VTPM, "VTPM ERROR: Can't open %s\n",
ipc_h->name);
+       return -1;
+    }
+  }
+  return 0;
+
 }
=20
 // Create the file that needs opening. Used only for FIFOs
 // FYI: This may cause problems in other file IO schemes. We'll see.
 int vtpm_ipc_create(vtpm_ipc_handle_t *ipc_h) {
-  int fh;
   struct stat file_info;
=20
   if ((!ipc_h) || (!ipc_h->name))
@@ -68,8 +91,6 @@ int vtpm_ipc_create(vtpm_ipc_handle_t *ipc_h) {
     }
   }
=20
-  ipc_h->fh =3D VTPM_IPC_CLOSED;
-
   return 0;
 }
=20
@@ -78,6 +99,8 @@ int vtpm_ipc_create(vtpm_ipc_handle_t *ipc_h) {
 int vtpm_ipc_read(vtpm_ipc_handle_t *ipc_h, vtpm_ipc_handle_t
*alt_ipc_h, BYTE *bytes, UINT32 size){
   vtpm_ipc_handle_t *my_ipc_h;
   int result;
+  fd_set fds;
+  struct timeval timeout;
 =20
   if (ipc_h) {
     my_ipc_h =3D ipc_h;
@@ -94,9 +117,19 @@ int vtpm_ipc_read(vtpm_ipc_handle_t *ipc_h,
vtpm_ipc_handle_t *alt_ipc_h, BYTE *
     return -1;
   }
=20
+  FD_ZERO(&fds);
+  while(!FD_ISSET( my_ipc_h->fh, &fds )) {
+     timeout =3D TIMEOUT;
+     if (IPC_QUIT_FLAG) {
+    return -1;
+     }
+     FD_SET(my_ipc_h->fh, &fds);
+     select(my_ipc_h->fh + 1, &fds, NULL, NULL, &timeout);
+  }
+
   result =3D read(my_ipc_h->fh, bytes, size);
   if (result < 0) {
-    my_ipc_h->fh =3D VTPM_IPC_CLOSED;
+     my_ipc_h->fh =3D VTPM_IPC_CLOSED;
   }
=20
   return (result);
@@ -106,6 +139,8 @@ int vtpm_ipc_read(vtpm_ipc_handle_t *ipc_h,
vtpm_ipc_handle_t *alt_ipc_h, BYTE *
 int vtpm_ipc_write(vtpm_ipc_handle_t *ipc_h, vtpm_ipc_handle_t
*alt_ipc_h, BYTE *bytes, UINT32 size) {
   vtpm_ipc_handle_t *my_ipc_h;
   int result;
+  fd_set fds;
+  struct timeval timeout;
=20
   if (ipc_h) {
     my_ipc_h =3D ipc_h;
@@ -122,6 +157,16 @@ int vtpm_ipc_write(vtpm_ipc_handle_t *ipc_h,
vtpm_ipc_handle_t *alt_ipc_h, BYTE
     return -1;
   }
=20
+  FD_ZERO(&fds);
+  while(!FD_ISSET( my_ipc_h->fh, &fds )) {
+     timeout =3D TIMEOUT;
+     if (IPC_QUIT_FLAG) {
+    return -1;
+     }
+     FD_SET(my_ipc_h->fh, &fds);
+     select(my_ipc_h->fh + 1, NULL, &fds, NULL, &timeout);
+  }
+
   result =3D write(my_ipc_h->fh, bytes, size);
   if (result < 0) {
     my_ipc_h->fh =3D VTPM_IPC_CLOSED;
diff --git a/tools/vtpm_manager/manager/vtpm_ipc.h
b/tools/vtpm_manager/manager/vtpm_ipc.h
--- a/tools/vtpm_manager/manager/vtpm_ipc.h
+++ b/tools/vtpm_manager/manager/vtpm_ipc.h
@@ -39,10 +39,14 @@
 #ifndef __VTPM_IO_H__
 #define __VTPM_IO_H__
=20
+#include <signal.h>
+
 #include "tcg.h"
=20
 #define VTPM_IPC_CLOSED -1
=20
+extern volatile sig_atomic_t IPC_QUIT_FLAG;
+
 // Represents an (somewhat) abstracted io handle.
 typedef struct vtpm_ipc_handle_t {
   int fh;              // IO handle.
@@ -53,7 +57,7 @@ typedef struct vtpm_ipc_handle_t {
 } vtpm_ipc_handle_t;
=20
=20
-int vtpm_ipc_init(vtpm_ipc_handle_t *ioh, char* name, int flags, BOOL
create);
+int vtpm_ipc_init(vtpm_ipc_handle_t *ioh, char* name, int flags, BOOL
create, BOOL preopen);
=20
 // Create the file that needs opening. Used only for FIFOs
 // FYI: This may cause problems in other file IO schemes. We'll see.
diff --git a/tools/vtpm_manager/manager/vtpm_lock.c
b/tools/vtpm_manager/manager/vtpm_lock.c
--- a/tools/vtpm_manager/manager/vtpm_lock.c
+++ b/tools/vtpm_manager/manager/vtpm_lock.c
@@ -40,24 +40,24 @@
=20
 static pthread_rwlock_t vtpm_lock;
=20
-void vtpm_lock_init() {
+void vtpm_lock_init(void) {
=20
   pthread_rwlock_init( &vtpm_lock, NULL);
 }
=20
-void vtpm_lock_destroy(){
+void vtpm_lock_destroy(void){
   pthread_rwlock_destroy(&vtpm_lock);
 }
=20
-void vtpm_lock_rdlock(){
+void vtpm_lock_rdlock(void){
   pthread_rwlock_rdlock(&vtpm_lock);
 }
=20
-void vtpm_lock_wrlock(){
+void vtpm_lock_wrlock(void){
   pthread_rwlock_wrlock(&vtpm_lock);
 }
=20
-void vtpm_lock_unlock(){
+void vtpm_lock_unlock(void){
   pthread_rwlock_unlock(&vtpm_lock);
 }
=20
diff --git a/tools/vtpm_manager/manager/vtpm_lock.h
b/tools/vtpm_manager/manager/vtpm_lock.h
--- a/tools/vtpm_manager/manager/vtpm_lock.h
+++ b/tools/vtpm_manager/manager/vtpm_lock.h
@@ -38,11 +38,11 @@
 #ifndef __VTPM_LOCK_H__
 #define __VTPM_LOCK_H__
=20
-void vtpm_lock_init();
-void vtpm_lock_destroy();
+void vtpm_lock_init(void);
+void vtpm_lock_destroy(void);
=20
-void vtpm_lock_rdlock();
-void vtpm_lock_wrlock();
-void vtpm_lock_unlock();
+void vtpm_lock_rdlock(void);
+void vtpm_lock_wrlock(void);
+void vtpm_lock_unlock(void);
=20
 #endif
diff --git a/tools/vtpm_manager/manager/vtpm_manager.c
b/tools/vtpm_manager/manager/vtpm_manager.c
--- a/tools/vtpm_manager/manager/vtpm_manager.c
+++ b/tools/vtpm_manager/manager/vtpm_manager.c
@@ -40,10 +40,12 @@
 #include <stdio.h>
 #include <unistd.h>
 #include <string.h>
+#include <stdlib.h>
=20
 #include "vtpm_manager.h"
 #include "vtpmpriv.h"
 #include "vtsp.h"
+#include "tpmddl.h"
 #include "bsg.h"
 #include "hashtable.h"
 #include "hashtable_itr.h"
@@ -54,8 +56,8 @@
 VTPM_GLOBALS *vtpm_globals=3DNULL;
=20
 // --------------------------- Well Known Auths ------------------------=
--
-const TPM_AUTHDATA SRK_AUTH =3D {0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
0xff, 0xff, 0xff, 0xff,
-                                  0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
0xff, 0xff, 0xff, 0xff};
+const TPM_AUTHDATA SRK_AUTH =3D {0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00,
+                                  0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00};
=20
 #ifdef WELL_KNOWN_OWNER_AUTH
 static BYTE FIXED_OWNER_AUTH[20] =3D  {0xff, 0xff, 0xff, 0xff, 0xff,
0xff, 0xff, 0xff, 0xff, 0xff,
@@ -74,7 +76,6 @@ static int equals32(void *k1, void *k2) {
 }
=20
 // --------------------------- Functions ------------------------------
-
 TPM_RESULT VTPM_Create_Manager(){
 =20
   TPM_RESULT status =3D TPM_SUCCESS;
@@ -104,6 +105,7 @@ TPM_RESULT VTPM_Create_Manager(){
     TPMTRYRETURN(VTSP_DisablePubekRead(vtpm_globals->manager_tcs_handle,=

                                        (const
TPM_AUTHDATA*)&vtpm_globals->owner_usage_auth,=20
                                        &vtpm_globals->keyAuth));   =20
+    Crypto_RSACryptoInfoFree(&ek_cryptoInfo);
   } else {
     vtpmloginfo(VTPM_LOG_VTPM, "Failed to readEK meaning TPM has an
owner. Creating Keys off existing SRK.\n");
   }
@@ -181,7 +183,7 @@ TPM_RESULT VTPM_Create_Manager(){
 }
=20
 ////////////////////////////////////////////////////////////////////////=
///////
-TPM_RESULT VTPM_Init_Manager() {
+TPM_RESULT VTPM_Init_Manager(void) {
   TPM_RESULT status =3D TPM_FAIL, serviceStatus; =20
   BYTE *randomsead;
   UINT32 randomsize=3D256;
@@ -203,6 +205,11 @@ TPM_RESULT VTPM_Init_Manager() {
   vtpm_globals->manager_tcs_handle =3D 0;
=20
   TPMTRYRETURN(TCS_create());
+
+  // Blow away all stale handles left in the tpm
+  if(TDDL_FlushAllResources() !=3D TPM_SUCCESS) {
+     vtpmlogerror(VTPM_LOG_VTPM, "VTPM_FlushResources failed,
continuing anyway..\n");
+  }
 =20
   // Create TCS Context for service
   TPMTRYRETURN( TCS_OpenContext(&vtpm_globals->manager_tcs_handle ) );
@@ -228,7 +235,7 @@ TPM_RESULT VTPM_Init_Manager() {
     TPMTRYRETURN( VTPM_Create_Manager() );  =20
     TPMTRYRETURN( VTPM_SaveManagerData() );
   } else if (serviceStatus !=3D TPM_SUCCESS) {
-    vtpmlogerror(VTPM_LOG_VTPM, "Failed to read existing manager file");=

+    vtpmlogerror(VTPM_LOG_VTPM, "Failed to read existing manager file\n"=
);
     exit(1);
   }
=20
@@ -254,7 +261,7 @@ TPM_RESULT VTPM_Init_Manager() {
 }
=20
 ////////////////////////////////////////////////////////////////////////=
///////

-void VTPM_Stop_Manager() {
+void VTPM_Stop_Manager(void) {
   VTPM_DMI_RESOURCE *dmi_res;
   struct hashtable_itr *dmi_itr;
 =20
@@ -267,7 +274,7 @@ void VTPM_Stop_Manager() {
     close_dmi( dmi_res ); // Not really interested in return code
     =20
     } while (hashtable_iterator_advance(dmi_itr));
-        free (dmi_itr);
+    free (dmi_itr);
   }
 =20
   if ( VTPM_SaveManagerData() !=3D TPM_SUCCESS )
@@ -276,7 +283,21 @@ void VTPM_Stop_Manager() {
   TCS_CloseContext(vtpm_globals->manager_tcs_handle);
   TCS_destroy();
 =20
-  hashtable_destroy(vtpm_globals->dmi_map, 1);
+  if (hashtable_count(vtpm_globals->dmi_map) > 0) {
+    dmi_itr =3D hashtable_iterator(vtpm_globals->dmi_map);
+    do {
+      dmi_res =3D (VTPM_DMI_RESOURCE *) hashtable_iterator_value(dmi_itr=
);
+      free_dmi(dmi_res);
+    } while (hashtable_iterator_advance(dmi_itr));
+    free (dmi_itr);
+  }
+  hashtable_destroy(vtpm_globals->dmi_map, 0);
+
+  /* Cleanup resources */
+  Crypto_RSACryptoInfoFree(&vtpm_globals->bootKey);
+  Crypto_RSACryptoInfoFree(&vtpm_globals->storageKey);
+  buffer_free(&vtpm_globals->bootKeyWrap);
+  buffer_free(&vtpm_globals->storageKeyWrap);
   free(vtpm_globals);
 =20
   Crypto_Exit();
diff --git a/tools/vtpm_manager/manager/vtpm_manager.h
b/tools/vtpm_manager/manager/vtpm_manager.h
--- a/tools/vtpm_manager/manager/vtpm_manager.h
+++ b/tools/vtpm_manager/manager/vtpm_manager.h
@@ -61,6 +61,8 @@
 #define VTPM_ORD_TPMCOMMAND   (VTPM_ORD_BASE + 3) // DMI issues HW TPM
Command
 #define VTPM_ORD_GET_MIG_KEY  (VTPM_ORD_BASE + 4) // Get manager's
migration key
 #define VTPM_ORD_LOAD_MIG_KEY (VTPM_ORD_BASE + 5) // load dest
migration key
+#define VTPM_ORD_SAVEHASHKEY      (VTPM_ORD_BASE + 7) // DMI requests
encryption key for persistent storage
+#define VTPM_ORD_LOADHASHKEY      (VTPM_ORD_BASE + 8) // DMI requests
symkey to be regenerated
=20
 // Priviledged VTPM Commands (From management console)
 #define VTPM_ORD_OPEN         (VTPM_PRIV_BASE + 1) // Creates/reopens DM=
I
@@ -147,4 +149,23 @@ VTPM_TPMCommand
=20
 *********************************************************************/
=20
+#ifndef VTPM_STUBDOM
+#define TPM_EMULATOR_PATH "/usr/bin/vtpmd"
+#endif
+
+#define VTPM_BE_FNAME          "/dev/vtpm"
+#define VTPM_DUMMY_TX_BE_FNAME "/var/vtpm/fifos/dummy_out.fifo"
+#define VTPM_DUMMY_RX_BE_FNAME "/var/vtpm/fifos/dummy_in.fifo"
+#ifndef VTPM_STUBDOM
+#define VTPM_TX_TPM_FNAME      "/var/vtpm/fifos/tpm_cmd_to_%d.fifo"
+#define VTPM_RX_TPM_FNAME      "/var/vtpm/fifos/tpm_rsp_from_all.fifo"
+#define VTPM_TX_VTPM_FNAME     "/var/vtpm/fifos/vtpm_rsp_to_%d.fifo"
+#define VTPM_RX_VTPM_FNAME     "/var/vtpm/fifos/vtpm_cmd_from_all.fifo"
+#endif
+#define VTPM_TX_HP_FNAME       "/var/vtpm/fifos/to_console.fifo"
+#define VTPM_RX_HP_FNAME       "/var/vtpm/fifos/from_console.fifo"
+
+#define VTPM_TYPE_PVM_STRING "pvm"
+#define VTPM_TYPE_HVM_STRING "hvm"
+
 #endif //_VTPM_MANAGER_H_
diff --git a/tools/vtpm_manager/manager/vtpm_manager_handler.c
b/tools/vtpm_manager/manager/vtpm_manager_handler.c
--- a/tools/vtpm_manager/manager/vtpm_manager_handler.c
+++ b/tools/vtpm_manager/manager/vtpm_manager_handler.c
@@ -41,6 +41,8 @@
 #include <unistd.h>
 #include <string.h>
 #include <errno.h>
+#include <signal.h>
+#include <stdlib.h>
=20
 #include "vtpm_manager.h"
 #include "vtpmpriv.h"
@@ -50,26 +52,13 @@
 #include "hashtable_itr.h"
 #include "log.h"
 #include "buffer.h"
+#include "vtpm_manager_handler.h"
=20
 #define vtpmhandlerloginfo(module,fmt,args...) vtpmloginfo (module,
"[%s]: " fmt, thread_name, ##args );
 #define vtpmhandlerloginfomore(module,fmt,args...) vtpmloginfomore
(module, fmt, ##args );
 #define vtpmhandlerlogerror(module,fmt,args...) vtpmlogerror (module,
"[%s]: " fmt, thread_name, ##args );
=20
-// ---------------------- Prototypes -------------------
-TPM_RESULT vtpm_manager_handle_vtpm_cmd(VTPM_DMI_RESOURCE *dmi_res,
-                    TPM_COMMAND_CODE ord,
-                    buffer_t *command_buf,
-                    buffer_t *result_buf,
-                                        BOOL is_priv,
-                                        char *thread_name);
-
-TPM_RESULT vtpm_manager_handle_tpm_cmd(vtpm_ipc_handle_t *tx_ipc_h,
-                                       vtpm_ipc_handle_t *rx_ipc_h,
-                                       VTPM_DMI_RESOURCE *dmi_res,
-                                       BYTE *cmd_header,
-                                       buffer_t *param_buf,
-                                       buffer_t *result_buf,
-                                       char *thread_name);
+volatile sig_atomic_t HANDLER_QUIT_FLAG =3D 0;
=20
 TPM_RESULT VTPM_Manager_Handler( vtpm_ipc_handle_t *tx_ipc_h,
                                  vtpm_ipc_handle_t *rx_ipc_h,
@@ -80,12 +69,13 @@ TPM_RESULT VTPM_Manager_Handler( vtpm_ipc_handle_t
*tx_ipc_h,
                                  char *thread_name) {
   TPM_RESULT      status =3D  TPM_FAIL; // Should never return
   UINT32          dmi, in_param_size, cmd_size, out_param_size,
out_message_size, reply_size;
-  BYTE            *cmd_header=3DNULL, *in_param=3DNULL, *out_message=3DN=
ULL,
*reply;
+  BYTE            *cmd_header=3DNULL, *in_param=3DNULL, *out_header=3DNU=
LL,
*reply;
   buffer_t        *command_buf=3DNULL, *result_buf=3DNULL;
   TPM_TAG         tag;
   TPM_COMMAND_CODE ord;
   VTPM_DMI_RESOURCE *dmi_res;
   int  size_read, size_write, i;
+  int locked;
   BOOL add_header=3DTRUE; // This indicates to prepend a header on
result_buf before sending
 =20
   cmd_header =3D (BYTE *) malloc(VTPM_COMMAND_HEADER_SIZE_SRV);
@@ -93,7 +83,11 @@ TPM_RESULT VTPM_Manager_Handler( vtpm_ipc_handle_t
*tx_ipc_h,
   result_buf =3D (buffer_t *) malloc(sizeof(buffer_t));
=20
   // ------------------------ Main Loop --------------------------------=

-  while(1) {
+  while(!HANDLER_QUIT_FLAG) {
+    locked =3D 0;
+
+    buffer_init(command_buf, 0, NULL);
+    buffer_init(result_buf, 0, NULL);
   =20
     vtpmhandlerloginfo(VTPM_LOG_VTPM, "%s waiting for messages.\n",
thread_name);
=20
@@ -106,7 +100,9 @@ TPM_RESULT VTPM_Manager_Handler( vtpm_ipc_handle_t
*tx_ipc_h,
       for (i=3D0; i<size_read; i++)
     vtpmhandlerloginfomore(VTPM_LOG_VTPM_DEEP, "%x ", cmd_header[i]);
     } else {
-      vtpmhandlerlogerror(VTPM_LOG_VTPM, "%s can't read from ipc.
Errono =3D %d. Aborting... \n", thread_name, errno);
+      if (!IPC_QUIT_FLAG) {
+    vtpmhandlerlogerror(VTPM_LOG_VTPM, "%s can't read from ipc. Errono
=3D %d. Aborting... \n", thread_name, errno);
+      }
       goto abort_command;
     }
=20
@@ -155,6 +151,7 @@ TPM_RESULT VTPM_Manager_Handler( vtpm_ipc_handle_t
*tx_ipc_h,
       vtpmhandlerlogerror(VTPM_LOG_VTPM, "Failed to setup buffers.
Aborting...\n");
       goto abort_command;
     }
+    result_buf->is_owner =3D TRUE;
   =20
     // -------------- Dispatch Commands to Handlers -----------
     if ((tag =3D=3D VTPM_TAG_REQ) && (ord & VTPM_PRIV_MASK)) {
@@ -162,6 +159,7 @@ TPM_RESULT VTPM_Manager_Handler( vtpm_ipc_handle_t
*tx_ipc_h,
     } else {
       vtpm_lock_rdlock();
     }
+    locked =3D 1;
=20
     if ( !(dmi_res =3D (VTPM_DMI_RESOURCE *)
hashtable_search(vtpm_globals->dmi_map, &dmi)) ||
          (!dmi_res->connected) ) {
@@ -174,10 +172,22 @@ TPM_RESULT VTPM_Manager_Handler( vtpm_ipc_handle_t
*tx_ipc_h,
     if (tag =3D=3D VTPM_TAG_REQ) {
   =20
       status =3D vtpm_manager_handle_vtpm_cmd(dmi_res, ord, command_buf,=

result_buf, is_priv, thread_name);
+      result_buf->is_owner =3D TRUE;
=20
     } else { // This is not a VTPM Command at all.
       if (fw_tpm) {
+#ifdef VTPM_STUBDOM
+    /* In stubdom mode, we allow the vtpm domains to send raw tpm
commands down the pipe
+     * They can also just embed their tpm commands inside VTPM commands
if they wish to*/
+
+    /* Stick the header back onto the raw command (minus the dmiid) */
+    buffer_prepend_raw(command_buf, VTPM_COMMAND_HEADER_SIZE_CLT,
cmd_header + sizeof(UINT32));
+    status =3D VTPM_Handle_TPM_Command(dmi_res, command_buf, result_buf)=
;
+#else
+    /* In normal mode, this is used for the guest to forward a raw
command to the vtpm process */
         status =3D vtpm_manager_handle_tpm_cmd(fw_tx_ipc_h, fw_rx_ipc_h,=

dmi_res, cmd_header, command_buf, result_buf, thread_name);
+#endif
+        result_buf->is_owner =3D TRUE;
=20
         // This means calling the DMI failed, not that the cmd failed
in the DMI
         // Since the return will be interpretted by a TPM app, all
errors are IO_ERRORs to the app
@@ -207,36 +217,42 @@ TPM_RESULT VTPM_Manager_Handler( vtpm_ipc_handle_t
*tx_ipc_h,
     // ------------------- Respond to Sender ------------------
=20
     // Errors while handling responses jump here to reply with error
messages
-    // NOTE: Currently there are no recoverable errors in multi-VM
mode. If one
-    //       is added to the code, this ifdef should be removed.
-    //       Also note this is NOT referring to errors in commands, but
rather
-    //       this is about I/O errors and such.
-#ifndef VTPM_MULTI_VM
- abort_with_error:
-#endif
+abort_with_error:
  =20
     if (add_header) {
       // Prepend VTPM header with destination DM stamped
       out_param_size =3D buffer_len(result_buf);
       out_message_size =3D VTPM_COMMAND_HEADER_SIZE_CLT + out_param_size=
;
-      reply_size =3D VTPM_COMMAND_HEADER_SIZE_SRV + out_param_size;
-      out_message =3D (BYTE *) malloc (reply_size);
-      reply =3D out_message;
+      out_header =3D (BYTE *) malloc (VTPM_COMMAND_HEADER_SIZE_SRV);
   =20
-      BSG_PackList(out_message, 4,
+      BSG_PackList(out_header, 4,
            BSG_TYPE_UINT32, (BYTE *) &dmi,
            BSG_TPM_TAG, (BYTE *) &tag,
            BSG_TYPE_UINT32, (BYTE *) &out_message_size,
            BSG_TPM_RESULT, (BYTE *) &status);
   =20
-      if (buffer_len(result_buf) > 0)
-        memcpy(out_message + VTPM_COMMAND_HEADER_SIZE_SRV,
result_buf->bytes, out_param_size);
-      //Note: Send message + dmi_id
+      buffer_prepend_raw(result_buf, VTPM_COMMAND_HEADER_SIZE_SRV,
out_header);
+      free(out_header);
     } else {
-      reply =3D result_buf->bytes;
-      reply_size =3D buffer_len(result_buf);
+#ifdef VTPM_STUBDOM
+       //In stubdom mode, we need to always prepend the dmiid so the
raw command can be returned to the right domain
+       out_header =3D (BYTE*) malloc(sizeof(UINT32));
+       BSG_PackList(out_header, 1,
+         BSG_TYPE_UINT32, (BYTE*) &dmi);
+       buffer_prepend_raw(result_buf, sizeof(UINT32), out_header);
+       free(out_header);
+#endif
     }=20
+    reply =3D result_buf->bytes;
+    reply_size =3D buffer_len(result_buf);
+#ifndef VTPM_STUBDOM
     size_write =3D vtpm_ipc_write(tx_ipc_h, (dmi_res ?
dmi_res->tx_vtpm_ipc_h : NULL), reply, reply_size );
+#else
+    if(reply_size >=3D 4096) {
+       vtpmhandlerlogerror(VTPM_LOG_VTPM, "MESSAGE TOO BIG!!!");
+    }
+    size_write =3D vtpm_ipc_write(tx_ipc_h, NULL, reply, reply_size );
+#endif
     if (size_write > 0) {
       vtpmhandlerloginfo(VTPM_LOG_VTPM_DEEP, "SENT: 0x");
       for (i=3D0; i < reply_size; i++)
@@ -247,7 +263,6 @@ TPM_RESULT VTPM_Manager_Handler( vtpm_ipc_handle_t
*tx_ipc_h,
       vtpmhandlerlogerror(VTPM_LOG_VTPM, "%s had error writing to ipc.
Aborting... \n", thread_name);
       goto abort_command;
     }
-    free(out_message); out_message=3DNULL;
   =20
     if (size_write < (int)reply_size) {
       vtpmhandlerlogerror(VTPM_LOG_VTPM, "%s unable to write full
command to ipc (%d/%d)\n", thread_name, size_write, reply_size);
@@ -264,14 +279,22 @@ TPM_RESULT VTPM_Manager_Handler( vtpm_ipc_handle_t
*tx_ipc_h,
     buffer_free(command_buf);
=20
     // If we have a write lock, save the manager table
-    if ((tag =3D=3D VTPM_TAG_REQ) && (ord & VTPM_PRIV_MASK) &&
+    if (locked && (tag =3D=3D VTPM_TAG_REQ) && (ord & VTPM_PRIV_MASK) &&=

         (VTPM_SaveManagerData() !=3D TPM_SUCCESS) ) {
        vtpmhandlerlogerror(VTPM_LOG_VTPM, "ERROR: Unable to save
manager data.\n");
     }
=20
-    vtpm_lock_unlock();
+    if(locked) {
+       vtpm_lock_unlock();
+    }
     add_header =3D TRUE; // Reset to the default
   } // End while(1)
+
+  free(cmd_header);
+  free(command_buf);
+  free(result_buf);
+
+  vtpmhandlerloginfo(VTPM_LOG_VTPM, "exiting\n", thread_name);
 =20
 }
=20
@@ -313,6 +336,16 @@ TPM_RESULT
vtpm_manager_handle_vtpm_cmd(VTPM_DMI_RESOURCE *dmi_res,
     status =3D VTPM_Handle_Load_Migration_key(command_buf,
                                            result_buf);
     break;
+  case VTPM_ORD_SAVEHASHKEY:
+    status =3D VTPM_Handle_Save_HashKey(dmi_res,
+                   command_buf,
+                   result_buf);
+    break;
+  case VTPM_ORD_LOADHASHKEY:
+    status =3D VTPM_Handle_Load_HashKey(dmi_res,
+                   command_buf,
+                   result_buf);
+    break;
  =20
   default:
     // Privileged handlers can do maintanance
@@ -350,6 +383,7 @@ TPM_RESULT
vtpm_manager_handle_vtpm_cmd(VTPM_DMI_RESOURCE *dmi_res,
   return(status);
 }
     =20
+#ifndef VTPM_STUBDOM
 /////////////////////////////////////////////////////////////////////
 TPM_RESULT vtpm_manager_handle_tpm_cmd(vtpm_ipc_handle_t *tx_ipc_h,
                                        vtpm_ipc_handle_t *rx_ipc_h,
@@ -485,4 +519,5 @@ TPM_RESULT
vtpm_manager_handle_tpm_cmd(vtpm_ipc_handle_t *tx_ipc_h,
=20
   return status;
 }
+#endif
=20
diff --git a/tools/vtpm_manager/manager/vtpm_manager_handler.h
b/tools/vtpm_manager/manager/vtpm_manager_handler.h
--- /dev/null
+++ b/tools/vtpm_manager/manager/vtpm_manager_handler.h
@@ -0,0 +1,21 @@
+#ifndef VTPM_MANAGER_HANDLER_H
+#define VTPM_MANAGER_HANDLER_H
+// ---------------------- Prototypes -------------------
+TPM_RESULT vtpm_manager_handle_vtpm_cmd(VTPM_DMI_RESOURCE *dmi_res,
+                    TPM_COMMAND_CODE ord,
+                    buffer_t *command_buf,
+                    buffer_t *result_buf,
+                                        BOOL is_priv,
+                                        char *thread_name);
+
+#ifndef VTPM_STUBDOM
+TPM_RESULT vtpm_manager_handle_tpm_cmd(vtpm_ipc_handle_t *tx_ipc_h,
+                                       vtpm_ipc_handle_t *rx_ipc_h,
+                                       VTPM_DMI_RESOURCE *dmi_res,
+                                       BYTE *cmd_header,
+                                       buffer_t *param_buf,
+                                       buffer_t *result_buf,
+                                       char *thread_name);
+#endif
+
+#endif
diff --git a/tools/vtpm_manager/manager/vtpmd.c
b/tools/vtpm_manager/manager/vtpmd.c
--- a/tools/vtpm_manager/manager/vtpmd.c
+++ b/tools/vtpm_manager/manager/vtpmd.c
@@ -45,27 +45,13 @@
 #include <signal.h>
 #include <string.h>
 #include <pthread.h>
+#include <stdlib.h>
 #include "vtpm_manager.h"
 #include "vtpmpriv.h"
 #include "tcg.h"
 #include "log.h"
 #include "vtpm_ipc.h"
=20
-#define TPM_EMULATOR_PATH "/usr/bin/vtpmd"
-
-#define VTPM_BE_FNAME          "/dev/vtpm"
-#define VTPM_DUMMY_TX_BE_FNAME "/var/vtpm/fifos/dummy_out.fifo"
-#define VTPM_DUMMY_RX_BE_FNAME "/var/vtpm/fifos/dummy_in.fifo"
-#define VTPM_TX_TPM_FNAME      "/var/vtpm/fifos/tpm_cmd_to_%d.fifo"
-#define VTPM_RX_TPM_FNAME      "/var/vtpm/fifos/tpm_rsp_from_all.fifo"
-#define VTPM_TX_VTPM_FNAME     "/var/vtpm/fifos/vtpm_rsp_to_%d.fifo"
-#define VTPM_RX_VTPM_FNAME     "/var/vtpm/fifos/vtpm_cmd_from_all.fifo"
-#define VTPM_TX_HP_FNAME       "/var/vtpm/fifos/to_console.fifo"
-#define VTPM_RX_HP_FNAME       "/var/vtpm/fifos/from_console.fifo"
-
-#define VTPM_TYPE_PVM_STRING "pvm"
-#define VTPM_TYPE_HVM_STRING "hvm"
-
 struct vtpm_thread_params_s {
   vtpm_ipc_handle_t *tx_ipc_h;
   vtpm_ipc_handle_t *rx_ipc_h;
@@ -76,180 +62,46 @@ struct vtpm_thread_params_s {
   char *thread_name;
 };
=20
+static pthread_t           master_thread;
+static pthread_t           be_thread;
+static pthread_t           hp_thread;
+#ifndef VTPM_STUBDOM
+static pthread_t           dmi_thread;
+#endif
+
+
+#ifndef VTPM_STUBDOM
 // This is needed to all extra_close_dmi to close this to prevent a
 // broken pipe when no DMIs are left.
-static vtpm_ipc_handle_t *g_rx_tpm_ipc_h;
+extern vtpm_ipc_handle_t *g_rx_tpm_ipc_h;
+#endif
=20
 void *vtpm_manager_thread(void *arg_void) {
-  TPM_RESULT *status =3D (TPM_RESULT *) malloc(sizeof(TPM_RESULT) );
   struct vtpm_thread_params_s *arg =3D (struct vtpm_thread_params_s *)
arg_void;
=20
-  *status =3D VTPM_Manager_Handler(arg->tx_ipc_h, arg->rx_ipc_h,
+  VTPM_Manager_Handler(arg->tx_ipc_h, arg->rx_ipc_h,
                                  arg->fw_tpm, arg->fw_tx_ipc_h,
arg->fw_rx_ipc_h,
                                  arg->is_priv, arg->thread_name);
=20
-  return (status);
+  return NULL;
 }
=20
-
-void signal_handler(int reason) {
-  if (pthread_equal(pthread_self(), vtpm_globals->master_pid)) {
-    vtpmloginfo(VTPM_LOG_VTPM, "VTPM Manager shutting down for signal
%d.\n", reason);
-  } else {
-    // For old Linux Thread machines, signals are delivered to each
thread. Deal with them.
-    vtpmloginfo(VTPM_LOG_VTPM, "Child shutting down\n");
-    pthread_exit(NULL);
+void signal_handler(int signal) {
+  if (pthread_equal(pthread_self(), master_thread)) {
+    vtpmloginfo(VTPM_LOG_VTPM, "VTPM Manager shutting down for signal
%s(%d). Please wait..\n", strsignal(signal), signal);
+    HANDLER_QUIT_FLAG =3D IPC_QUIT_FLAG =3D 1;
   }
-
-  VTPM_Stop_Manager();
-  exit(-1);
 }
=20
 struct sigaction ctl_c_handler;
=20
-TPM_RESULT VTPM_New_DMI_Extra(VTPM_DMI_RESOURCE *dmi_res, BYTE vm_type,
BYTE startup_mode) {
-
-  TPM_RESULT status =3D TPM_SUCCESS;
-  int fh;
-  char dmi_id_str[11]; // UINT32s are up to 10 digits + NULL
-  char *tx_vtpm_name, *tx_tpm_name, *vm_type_string;
-  struct stat file_info;
-
-  if (dmi_res->dmi_id =3D=3D VTPM_CTL_DM) {
-    dmi_res->tx_tpm_ipc_h =3D NULL;
-    dmi_res->rx_tpm_ipc_h =3D NULL;
-    dmi_res->tx_vtpm_ipc_h =3D NULL;
-    dmi_res->rx_vtpm_ipc_h =3D NULL;
-  } else {
-    // Create a pair of fifo pipes
-    dmi_res->rx_tpm_ipc_h =3D NULL;
-    dmi_res->rx_vtpm_ipc_h =3D NULL;
-
-    if ( ((dmi_res->tx_tpm_ipc_h =3D (vtpm_ipc_handle_t *) malloc
(sizeof(vtpm_ipc_handle_t))) =3D=3D NULL ) ||
-         ((dmi_res->tx_vtpm_ipc_h =3D(vtpm_ipc_handle_t *) malloc
(sizeof(vtpm_ipc_handle_t))) =3D=3D NULL ) ||
-         ((tx_tpm_name =3D (char *) malloc(11 +
strlen(VTPM_TX_TPM_FNAME))) =3D=3D NULL ) ||
-         ((tx_vtpm_name =3D(char *) malloc(11 +
strlen(VTPM_TX_VTPM_FNAME))) =3D=3D NULL) ) {
-      status =3DTPM_RESOURCES;
-      goto abort_egress;
-    }
-
-    sprintf(tx_tpm_name, VTPM_TX_TPM_FNAME, (uint32_t) dmi_res->dmi_id);=

-    sprintf(tx_vtpm_name, VTPM_TX_VTPM_FNAME, (uint32_t) dmi_res->dmi_id=
);
-
-    if ( (vtpm_ipc_init(dmi_res->tx_tpm_ipc_h, tx_tpm_name, O_WRONLY |
O_NONBLOCK, TRUE) !=3D 0) ||
-         (vtpm_ipc_init(dmi_res->tx_vtpm_ipc_h, tx_vtpm_name, O_WRONLY,
TRUE) !=3D 0) ) { //FIXME: O_NONBLOCK?
-      status =3D TPM_IOERROR;
-      goto abort_egress;
-    }
-
-    // Measure DMI
-    // FIXME: This will measure DMI. Until then use a fixed
DMI_Measurement value
-    // Also, this mechanism is specific to 1 VM architecture.
-    /*
-    fh =3D open(TPM_EMULATOR_PATH, O_RDONLY);
-    stat_ret =3D fstat(fh, &file_stat);
-    if (stat_ret =3D=3D 0)
-      dmi_size =3D file_stat.st_size;
-    else {
-      vtpmlogerror(VTPM_LOG_VTPM, "Could not open vtpmd!!\n");
-      status =3D TPM_IOERROR;
-      goto abort_egress;
-    }
-    dmi_buffer
-    */
-    memset(&dmi_res->DMI_measurement, 0xcc, sizeof(TPM_DIGEST));
-
-    if (vm_type =3D=3D VTPM_TYPE_PVM)
-      vm_type_string =3D (BYTE *)&VTPM_TYPE_PVM_STRING;
-    else
-      vm_type_string =3D (BYTE *)&VTPM_TYPE_HVM_STRING;
-
-    // Launch DMI
-    sprintf(dmi_id_str, "%d", (int) dmi_res->dmi_id);
-#ifdef MANUAL_DM_LAUNCH
-    vtpmlogerror(VTPM_LOG_VTPM, "Manually start VTPM with dmi=3D%s
now.\n", dmi_id_str);
-    dmi_res->dmi_pid =3D 0;
-#else
-    pid_t pid =3D fork();
-
-    if (pid =3D=3D -1) {
-      vtpmlogerror(VTPM_LOG_VTPM, "Could not fork to launch vtpm\n");
-      status =3D TPM_RESOURCES;
-      goto abort_egress;
-    } else if (pid =3D=3D 0) {
-      switch (startup_mode) {
-      case TPM_ST_CLEAR:
-        execl (TPM_EMULATOR_PATH, "vtpmd", "clear", vm_type_string,
dmi_id_str, NULL);
-        break;
-      case TPM_ST_STATE:
-        execl (TPM_EMULATOR_PATH, "vtpmd", "save", vm_type_string,
dmi_id_str, NULL);
-        break;
-      case TPM_ST_DEACTIVATED:
-        execl (TPM_EMULATOR_PATH, "vtpmd", "deactivated",
vm_type_string, dmi_id_str, NULL);
-        break;
-      default:
-        status =3D TPM_BAD_PARAMETER;
-        goto abort_egress;
-      }
-
-      // Returning from these at all is an error.
-      vtpmlogerror(VTPM_LOG_VTPM, "Could not exec to launch vtpm\n");
-    } else {
-      dmi_res->dmi_pid =3D pid;
-      vtpmloginfo(VTPM_LOG_VTPM, "Launching DMI on PID =3D %d\n", pid);
-    }
-#endif // MANUAL_DM_LAUNCH
-
-  } // If DMI =3D VTPM_CTL_DM
-    status =3D TPM_SUCCESS;
-
-abort_egress:
-  return (status);
-}
-
-TPM_RESULT VTPM_Close_DMI_Extra(VTPM_DMI_RESOURCE *dmi_res) {
-  TPM_RESULT status =3D TPM_SUCCESS;
-
-  if (vtpm_globals->connected_dmis =3D=3D 0) {
-    // No more DMI's connected. Close fifo to prevent a broken pipe.
-    // This is hackish. Need to think of another way.
-    vtpm_ipc_close(g_rx_tpm_ipc_h);
-  }
-
-=20
-  if (dmi_res->dmi_id !=3D VTPM_CTL_DM) {
-    vtpm_ipc_close(dmi_res->tx_tpm_ipc_h);
-    vtpm_ipc_close(dmi_res->tx_vtpm_ipc_h);
-
-    free(dmi_res->tx_tpm_ipc_h->name);
-    free(dmi_res->tx_vtpm_ipc_h->name);
-
-#ifndef MANUAL_DM_LAUNCH
-    if (dmi_res->dmi_id !=3D VTPM_CTL_DM) {
-      if (dmi_res->dmi_pid !=3D 0) {
-        vtpmloginfo(VTPM_LOG_VTPM, "Killing dmi on pid %d.\n",
dmi_res->dmi_pid);
-        if (kill(dmi_res->dmi_pid, SIGKILL) !=3D0) {
-          vtpmloginfo(VTPM_LOG_VTPM, "DMI on pid %d is already
dead.\n", dmi_res->dmi_pid);
-        } else if (waitpid(dmi_res->dmi_pid, NULL, 0) !=3D
dmi_res->dmi_pid) {
-          vtpmlogerror(VTPM_LOG_VTPM, "DMI on pid %d failed to
stop.\n", dmi_res->dmi_pid);
-          status =3D TPM_FAIL;
-        }
-      } else {
-        vtpmlogerror(VTPM_LOG_VTPM, "Could not kill dmi because it's
pid was 0.\n");
-        status =3D TPM_FAIL;
-      }
-    }
-#endif
-
-  } //endif ! dom0
-  return status;
-}
-
-
 int main(int argc, char **argv) {
-  vtpm_ipc_handle_t *tx_be_ipc_h, *rx_be_ipc_h, rx_tpm_ipc_h,
rx_vtpm_ipc_h, tx_hp_ipc_h, rx_hp_ipc_h;
-  struct vtpm_thread_params_s be_thread_params, dmi_thread_params,
hp_thread_params;
-  pthread_t be_thread, dmi_thread, hp_thread;
+  vtpm_ipc_handle_t *tx_be_ipc_h, *rx_be_ipc_h, tx_hp_ipc_h, rx_hp_ipc_h=
;
+  struct vtpm_thread_params_s be_thread_params, hp_thread_params;
+#ifndef VTPM_STUBDOM
+  vtpm_ipc_handle_t rx_tpm_ipc_h, rx_vtpm_ipc_h;
+  struct vtpm_thread_params_s dmi_thread_params;
+#endif
=20
 #ifdef DUMMY_BACKEND
   vtpm_ipc_handle_t tx_dummy_ipc_h, rx_dummy_ipc_h;
@@ -258,34 +110,28 @@ int main(int argc, char **argv) {
 #endif
=20
   vtpmloginfo(VTPM_LOG_VTPM, "Starting VTPM.\n");
-
-  // -------------------- Initialize Manager -----------------
-  if (VTPM_Init_Manager() !=3D TPM_SUCCESS) {
-    vtpmlogerror(VTPM_LOG_VTPM, "Closing vtpmd due to error during
startup.\n");
-    return -1;
-  }
-=20
+
   // -------------------- Setup Ctrl+C Handlers --------------
   ctl_c_handler.sa_handler =3D signal_handler;
   sigemptyset(&ctl_c_handler.sa_mask);
   ctl_c_handler.sa_flags =3D 0;  =20
 =20
-  if (sigaction(SIGINT, &ctl_c_handler, NULL) =3D=3D -1)
+  if ((sigaction(SIGINT, &ctl_c_handler, NULL) =3D=3D -1)
+    || (sigaction(SIGQUIT, &ctl_c_handler, NULL) =3D=3D -1)
+    || (sigaction(SIGHUP, &ctl_c_handler, NULL) =3D=3D -1) ) // For easi=
er
debugging with gdb
+  {
     vtpmlogerror(VTPM_LOG_VTPM, "Could not install SIGINT handler.
Ctl+break will not stop manager gently.\n");
+  }
 =20
-  // For easier debuggin with gdb
-  if (sigaction(SIGHUP, &ctl_c_handler, NULL) =3D=3D -1)
-    vtpmlogerror(VTPM_LOG_VTPM, "Could not install SIGHUP handler.
Ctl+break will not stop manager gently.\n");  =20
-=20
+  //Block all signals for child threads
   sigset_t sig_mask;
-  sigemptyset(&sig_mask);
-  sigaddset(&sig_mask, SIGPIPE);
-  sigprocmask(SIG_BLOCK, &sig_mask, NULL);
+  sigfillset(&sig_mask);
+  pthread_sigmask(SIG_SETMASK, &sig_mask, NULL);
 =20
   // ------------------- Set up file ipc structures ----------
 #ifdef DUMMY_BACKEND
-  if ( (vtpm_ipc_init(&tx_dummy_ipc_h, VTPM_DUMMY_TX_BE_FNAME, O_RDWR,
TRUE) !=3D 0) ||
-       (vtpm_ipc_init(&rx_dummy_ipc_h, VTPM_DUMMY_RX_BE_FNAME, O_RDWR,
TRUE) !=3D 0) ) {
+  if ( (vtpm_ipc_init(&tx_dummy_ipc_h, VTPM_DUMMY_TX_BE_FNAME, O_RDWR,
TRUE, FALSE) !=3D 0) ||
+       (vtpm_ipc_init(&rx_dummy_ipc_h, VTPM_DUMMY_RX_BE_FNAME, O_RDWR,
TRUE, FALSE) !=3D 0) ) {
=20
     vtpmlogerror(VTPM_LOG_VTPM, "Unable to create Dummy BE FIFOs.\n");
     exit(-1);
@@ -294,21 +140,29 @@ int main(int argc, char **argv) {
   tx_be_ipc_h =3D &tx_dummy_ipc_h;
   rx_be_ipc_h =3D &rx_dummy_ipc_h;
 #else
-  vtpm_ipc_init(&real_be_ipc_h, VTPM_BE_FNAME, O_RDWR, FALSE);
+  if(vtpm_ipc_init(&real_be_ipc_h, VTPM_BE_FNAME, O_RDWR, FALSE, TRUE)
!=3D 0) {
+     vtpmlogerror(VTPM_LOG_VTPM, "Unable to open backend device "
VTPM_BE_FNAME "\n");
+     exit(-1);
+  }
=20
   tx_be_ipc_h =3D &real_be_ipc_h;
   rx_be_ipc_h =3D &real_be_ipc_h;
 #endif
=20
-  if ( (vtpm_ipc_init(&rx_tpm_ipc_h, VTPM_RX_TPM_FNAME, O_RDONLY, TRUE)
!=3D 0) ||
-       (vtpm_ipc_init(&rx_vtpm_ipc_h, VTPM_RX_VTPM_FNAME, O_RDWR, TRUE)
!=3D 0) || //FIXME: O_RDONLY?
-       (vtpm_ipc_init(&tx_hp_ipc_h,  VTPM_TX_HP_FNAME, O_RDWR, TRUE) !=3D=

0)    ||
-       (vtpm_ipc_init(&rx_hp_ipc_h,  VTPM_RX_HP_FNAME, O_RDWR, TRUE) !=3D=

0) ) {
+  if (
+#ifndef VTPM_STUBDOM
+       (vtpm_ipc_init(&rx_tpm_ipc_h, VTPM_RX_TPM_FNAME, O_RDONLY, TRUE,
FALSE) !=3D 0) ||
+       (vtpm_ipc_init(&rx_vtpm_ipc_h, VTPM_RX_VTPM_FNAME, O_RDWR, TRUE,
FALSE) !=3D 0) || //FIXME: O_RDONLY?
+#endif
+       (vtpm_ipc_init(&tx_hp_ipc_h,  VTPM_TX_HP_FNAME, O_RDWR, TRUE,
TRUE) !=3D 0)    ||
+       (vtpm_ipc_init(&rx_hp_ipc_h,  VTPM_RX_HP_FNAME, O_RDWR, TRUE,
TRUE) !=3D 0) ) {
     vtpmlogerror(VTPM_LOG_VTPM, "Unable to create initial FIFOs.\n");
     exit(-1);
   }
=20
+#ifndef VTPM_STUBDOM
   g_rx_tpm_ipc_h =3D &rx_tpm_ipc_h;
+#endif
=20
   // -------------------- Set up thread params -------------
=20
@@ -316,10 +170,15 @@ int main(int argc, char **argv) {
   be_thread_params.rx_ipc_h =3D rx_be_ipc_h;
   be_thread_params.fw_tpm =3D TRUE;
   be_thread_params.fw_tx_ipc_h =3D NULL;
+#ifndef VTPM_STUBDOM
   be_thread_params.fw_rx_ipc_h =3D &rx_tpm_ipc_h;
+#else
+  be_thread_params.fw_rx_ipc_h =3D NULL;
+#endif
   be_thread_params.is_priv =3D FALSE;
   be_thread_params.thread_name =3D "Backend Listener";
=20
+#ifndef VTPM_STUBDOM
   dmi_thread_params.tx_ipc_h =3D NULL;
   dmi_thread_params.rx_ipc_h =3D &rx_vtpm_ipc_h;
   dmi_thread_params.fw_tpm =3D FALSE;
@@ -327,6 +186,7 @@ int main(int argc, char **argv) {
   dmi_thread_params.fw_rx_ipc_h =3D NULL;
   dmi_thread_params.is_priv =3D FALSE;
   dmi_thread_params.thread_name =3D "VTPM Listener";
+#endif
=20
   hp_thread_params.tx_ipc_h =3D &tx_hp_ipc_h;
   hp_thread_params.rx_ipc_h =3D &rx_hp_ipc_h;
@@ -336,34 +196,50 @@ int main(int argc, char **argv) {
   hp_thread_params.is_priv =3D TRUE;
   hp_thread_params.thread_name =3D "Hotplug Listener";
=20
+  // -------------------- Initialize Manager -----------------
+  if (VTPM_Init_Manager() !=3D TPM_SUCCESS) {
+    vtpmlogerror(VTPM_LOG_VTPM, "Closing vtpmd due to error during
startup.\n");
+    return -1;
+  }
+
+
   // --------------------- Launch Threads -----------------
=20
   vtpm_lock_init();
=20
-  vtpm_globals->master_pid =3D pthread_self();
+  master_thread =3D pthread_self();
+
 =20
   if (pthread_create(&be_thread, NULL, vtpm_manager_thread,
&be_thread_params) !=3D 0) {
     vtpmlogerror(VTPM_LOG_VTPM, "Failed to launch BE Thread.\n");
     exit(-1);
   }
 =20
+#ifndef VTPM_STUBDOM
   if (pthread_create(&dmi_thread, NULL, vtpm_manager_thread,
&dmi_thread_params) !=3D 0) {
     vtpmlogerror(VTPM_LOG_VTPM, "Failed to launch DMI Thread.\n");
     exit(-1);
   }
-
+#endif
=20
   if (pthread_create(&hp_thread, NULL, vtpm_manager_thread,
&hp_thread_params) !=3D 0) {
     vtpmlogerror(VTPM_LOG_VTPM, "Failed to launch HP Thread.\n");
     exit(-1);
   }
=20
+  //Turn signals back on for the master thread only
+  sigemptyset(&sig_mask);
+  sigaddset(&sig_mask, SIGPIPE);
+  pthread_sigmask(SIG_SETMASK, &sig_mask, NULL);
+
   //Join the other threads until exit time.
   pthread_join(be_thread, NULL);
+#ifndef VTPM_STUBDOM
   pthread_join(dmi_thread, NULL);
+#endif
   pthread_join(hp_thread, NULL);
=20
-  vtpmlogerror(VTPM_LOG_VTPM, "VTPM Manager shut down unexpectedly.\n");=

+  vtpmloginfo(VTPM_LOG_VTPM, "VTPM Manager shutting down...\n");
=20
   VTPM_Stop_Manager();
   vtpm_lock_destroy();
diff --git a/tools/vtpm_manager/manager/vtpmpriv.h
b/tools/vtpm_manager/manager/vtpmpriv.h
--- a/tools/vtpm_manager/manager/vtpmpriv.h
+++ b/tools/vtpm_manager/manager/vtpmpriv.h
@@ -40,6 +40,8 @@
 #ifndef __VTPMPRIV_H__
 #define __VTPMPRIV_H__
=20
+#include <signal.h>
+
 #include "vtpm_manager.h"
 #include "tcg.h"
 #include "tcs.h"
@@ -54,16 +56,19 @@
 #define DMI_NVM_FILE       "/var/vtpm/vtpm_dm_%d.data"
 #define VTPM_CTL_DM        0
=20
+extern volatile sig_atomic_t HANDLER_QUIT_FLAG;
+
 // ------------------------ Private Structures -----------------------
 typedef struct VTPM_DMI_RESOURCE_T {
+#ifndef VTPM_STUBDOM
   // I/O info for Manager to talk to DMI's and controllers
   vtpm_ipc_handle_t      *tx_vtpm_ipc_h;    // TX VTPM Results to DMI
   vtpm_ipc_handle_t      *rx_vtpm_ipc_h;    // RX VTPM Commands from DMI=

   vtpm_ipc_handle_t      *tx_tpm_ipc_h;     // TX TPM Commands to DMI
   vtpm_ipc_handle_t      *rx_tpm_ipc_h;     // RX TPM Results from DMI
+
+  pid_t                  dmi_pid;
=20
-#ifndef VTPM_MULTI_VM
-  pid_t                 dmi_pid;
 #endif
=20
   // Non-persistent Information
@@ -77,6 +82,9 @@ typedef struct VTPM_DMI_RESOURCE_T {
   BYTE                  dmi_type;
   TPM_DIGEST            NVM_measurement;  // Equal to the SHA1 of the bl=
ob
   TPM_DIGEST            DMI_measurement;  // Correct measurement of the
owning DMI
+
+  char* uuid;
+
 } VTPM_DMI_RESOURCE;
=20
 typedef struct tdVTPM_MIGKEY_LIST {
@@ -89,10 +97,6 @@ typedef struct tdVTPM_MIGKEY_LIST {
=20
 typedef struct tdVTPM_GLOBALS {
   // Non-persistent data
-#ifndef VTPM_MULTI_VM
-  pid_t               master_pid;
-#endif
-
   int                 connected_dmis;     // To close guest_rx when no
dmis are connected
=20
   struct hashtable    *dmi_map;               // Table of all DMI's
known indexed by persistent instance #
@@ -123,8 +127,8 @@ extern VTPM_GLOBALS *vtpm_globals;   // Key info and
DMI states
 extern const TPM_AUTHDATA SRK_AUTH;  // SRK Well Known Auth Value
=20
 // ********************** VTPM Functions *************************
-TPM_RESULT VTPM_Init_Manager(); // Start VTPM Service
-void VTPM_Stop_Manager();  // Stop VTPM Service
+TPM_RESULT VTPM_Init_Manager(void); // Start VTPM Service
+void VTPM_Stop_Manager(void);  // Stop VTPM Service
 TPM_RESULT VTPM_Manager_Handler(vtpm_ipc_handle_t *tx_ipc_h,
                                 vtpm_ipc_handle_t *rx_ipc_h,
                                 BOOL fw_tpm,   // Should forward TPM cmd=
s
@@ -143,6 +147,11 @@ TPM_RESULT VTPM_Handle_Save_NVM(     =20
VTPM_DMI_RESOURCE *myDMI,
                                         const buffer_t *inbuf,
                                         buffer_t *outbuf);
=20
+TPM_RESULT VTPM_Handle_Get_NVM_Size(   VTPM_DMI_RESOURCE *myDMI,
+                                        const buffer_t *inbuf,
+                                        buffer_t *outbuf);
+
+
 TPM_RESULT VTPM_Handle_TPM_Command(    VTPM_DMI_RESOURCE *dmi,
                                         buffer_t *inbuf,
                                         buffer_t *outbuf);
@@ -173,6 +182,9 @@ TPM_RESULT VTPM_Close_DMI_Extra(VTPM_DMI_RESOURCE
*dmi_res);
 TPM_RESULT close_dmi(VTPM_DMI_RESOURCE *dmi_res);
 TPM_RESULT init_dmi(UINT32 dmi_id, BYTE type,  VTPM_DMI_RESOURCE
**dmi_res);
=20
+/* Free's dmi_res and all of it's resources */
+void free_dmi(VTPM_DMI_RESOURCE *dmi_res);
+
 TPM_RESULT envelope_encrypt(const buffer_t     *inbuf,
                              CRYPTO_INFO        *asymkey,
                              buffer_t           *sealed_data);
@@ -183,4 +195,14 @@ TPM_RESULT envelope_decrypt(const buffer_t     *ciph=
er,
                             const TPM_AUTHDATA *key_usage_auth,
                             buffer_t           *unsealed_data);
=20
+TPM_RESULT symkey_encrypt(const buffer_t     *inbuf,
+                            CRYPTO_INFO        *asymkey,
+                            buffer_t           *sealed_key);
+
+TPM_RESULT symkey_decrypt(const buffer_t     *cipher,
+                            TCS_CONTEXT_HANDLE TCSContext,
+                TPM_HANDLE         keyHandle,
+                const TPM_AUTHDATA *key_usage_auth,
+                            buffer_t           *symkey_clear);
+
 #endif // __VTPMPRIV_H__
diff --git a/tools/vtpm_manager/manager/vtsp.c
b/tools/vtpm_manager/manager/vtsp.c
--- a/tools/vtpm_manager/manager/vtsp.c
+++ b/tools/vtpm_manager/manager/vtsp.c
@@ -38,6 +38,7 @@
 // =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
=20
 #include <string.h>
+#include <stdlib.h>
 #include "tcg.h"
 #include "tcs.h"
 #include "bsg.h"
@@ -312,7 +313,7 @@ TPM_RESULT VTSP_TakeOwnership(   const
TCS_CONTEXT_HANDLE hContext,
   TPM_PROTOCOL_ID proto_id =3D TPM_PID_OWNER;
   BYTE *new_srk;
 =20
-  BYTE *paramText;        // Digest to make Auth.
+  BYTE *paramText =3D NULL;        // Digest to make Auth.
   UINT32 paramTextSize;
 =20
   // vars for srkpubkey parameter
@@ -458,7 +459,7 @@ TPM_RESULT VTSP_CreateWrapKey(  const
TCS_CONTEXT_HANDLE hContext,
   vtpmloginfo(VTPM_LOG_VTSP, "Creating new key of type %d.\n", usage);
 =20
   // vars for Calculate encUsageAuth
-  BYTE *paramText;    =20
+  BYTE *paramText =3D NULL;
   UINT32 paramTextSize;
 =20
   // vars for Calculate encUsageAuth
@@ -567,8 +568,7 @@ TPM_RESULT VTSP_CreateWrapKey(  const
TCS_CONTEXT_HANDLE hContext,
                 osapSharedSecret, auth, 0) );
 =20
   // Unpack/return key structure
-  TPMTRYRETURN(buffer_init(pubKeyBuf, 0, 0) );
-  TPMTRYRETURN(buffer_append_raw(pubKeyBuf, newKeyText.size,
newKeyText.data) );
+  TPMTRYRETURN(buffer_init(pubKeyBuf, newKeyText.size, newKeyText.data) =
);
 =20
   goto egress;
 =20
@@ -664,6 +664,7 @@ TPM_RESULT VTSP_LoadKey(const TCS_CONTEXT_HANDLE  =20
hContext,
   =20
     // Destroy rsaKeyParms
     BSG_Destroy(BSG_TPM_RSA_KEY_PARMS, &rsaKeyParms);
+    BSG_Destroy(BSG_TPM_KEY, &newKey);
   =20
     // Set encryption scheme
     cryptoinfo->encScheme =3D CRYPTO_ES_RSAESOAEP_SHA1_MGF1;
@@ -733,8 +734,7 @@ TPM_RESULT VTSP_Unbind( const TCS_CONTEXT_HANDLE  =20
hContext,
                 hContext) );
 =20
   // Unpack/return key structure
-  TPMTRYRETURN(buffer_init(clear_data, 0, 0));
-  TPMTRYRETURN(buffer_append_raw (clear_data, clear_data_size,
clear_data_text) );
+  TPMTRYRETURN(buffer_init(clear_data, clear_data_size, clear_data_text)=
 );
 =20
   goto egress;
 =20
@@ -793,8 +793,7 @@ TPM_RESULT VTSP_Bind(   CRYPTO_INFO *cryptoInfo,
     vtpmlogerror(VTPM_LOG_VTSP, "Enc buffer just overflowed.\n");
   }
 =20
-  buffer_init(outData, 0, NULL);
-  buffer_append_raw(outData, out_tmp_size, out_tmp);
+  buffer_init(outData, out_tmp_size, out_tmp);
 =20
   vtpmloginfo(VTPM_LOG_TXDATA, "Bind Generated[%d] =3D 0x", out_tmp_size=
);
   for(i =3D 0 ; i < out_tmp_size ; i++) {
@@ -1005,8 +1004,6 @@ TPM_RESULT VTSP_SaveState( const
TCS_CONTEXT_HANDLE    hContext) {
=20
   vtpmloginfo(VTPM_LOG_VTSP, "Calling TPM_SaveState.\n");
=20
-  TPM_RESULT status =3D TPM_SUCCESS;
-
   // Call TCS
   return ( TCSP_SaveState ( hContext ) );
=20
diff --git a/tools/vtpm_manager/manager/vtsp.h
b/tools/vtpm_manager/manager/vtsp.h
--- a/tools/vtpm_manager/manager/vtsp.h
+++ b/tools/vtpm_manager/manager/vtsp.h
@@ -42,6 +42,7 @@
=20
 #include "tcg.h"
 #include "tcs.h"
+#include "crypto.h"
=20
 #define KEY_BUFFER_SIZE 2048
=20
diff --git a/tools/vtpm_manager/migration/Makefile
b/tools/vtpm_manager/migration/Makefile
--- a/tools/vtpm_manager/migration/Makefile
+++ b/tools/vtpm_manager/migration/Makefile
@@ -1,5 +1,11 @@
-XEN_ROOT =3D $(CURDIR)/../../..
-include $(XEN_ROOT)/tools/vtpm_manager/Rules.mk
+XEN_ROOT =3D $(realpath ../../..)
+include ../Rules.mk
+
+CFLAGS +=3D -I../crypto
+CFLAGS +=3D -I../util
+CFLAGS +=3D -I../tcs
+CFLAGS +=3D -I../manager
+
=20
 VPATH =3D ../manager
=20
@@ -33,10 +39,10 @@ mrproper: clean
     rm -f *~
=20
 $(BIND): $(OBJSD)
-    $(CC) $(LDFLAGS) $^ $(LIBS) -o $@
+    $(CC) $(CFLAGS) $(LDFLAGS) $^ $(LIBS) -o $@
=20
 $(BINC): $(OBJSC)
-    $(CC) $(LDFLAGS) $^ $(LIBS) -o $@
+    $(CC) $(CFLAGS) $(LDFLAGS) $^ $(LIBS) -o $@
=20
 # libraries
 LIBS +=3D ../util/libTCGUtils.a
diff --git a/tools/vtpm_manager/migration/vtpm_manager_if.c
b/tools/vtpm_manager/migration/vtpm_manager_if.c
--- a/tools/vtpm_manager/migration/vtpm_manager_if.c
+++ b/tools/vtpm_manager/migration/vtpm_manager_if.c
@@ -50,15 +50,12 @@
 #include "vtpm_migrator.h"
 #include "vtpm_manager.h"
=20
-#define VTPM_TX_HP_FNAME       "/var/vtpm/fifos/from_console.fifo"
-#define VTPM_RX_HP_FNAME       "/var/vtpm/fifos/to_console.fifo"
-
 static vtpm_ipc_handle_t tx_ipc_h, rx_ipc_h;
=20
 TPM_RESULT vtpm_manager_open(){
=20
-  if ( (vtpm_ipc_init(&tx_ipc_h,  VTPM_TX_HP_FNAME, O_RDWR, TRUE) !=3D 0=
)
||  //FIXME: wronly
-       (vtpm_ipc_init(&rx_ipc_h,  VTPM_RX_HP_FNAME, O_RDWR, TRUE) !=3D 0=
)
) { //FIXME: rdonly
+  if ( (vtpm_ipc_init(&tx_ipc_h,  VTPM_TX_HP_FNAME, O_RDWR, TRUE, TRUE)
!=3D 0) ||  //FIXME: wronly
+       (vtpm_ipc_init(&rx_ipc_h,  VTPM_RX_HP_FNAME, O_RDWR, TRUE, TRUE)
!=3D 0) ) { //FIXME: rdonly
     vtpmlogerror(VTPM_LOG_VTPM, "Unable to connect to vtpm_manager.\n");=

     return TPM_IOERROR;
   }
diff --git a/tools/vtpm_manager/tcs/Makefile
b/tools/vtpm_manager/tcs/Makefile
--- a/tools/vtpm_manager/tcs/Makefile
+++ b/tools/vtpm_manager/tcs/Makefile
@@ -1,5 +1,10 @@
-XEN_ROOT =3D $(CURDIR)/../../..
-include $(XEN_ROOT)/tools/vtpm_manager/Rules.mk
+XEN_ROOT =3D $(realpath ../../..)
+include ../Rules.mk
+
+CFLAGS +=3D -I../crypto
+CFLAGS +=3D -I../util
+CFLAGS +=3D -I../manager
+
=20
 BIN        =3D libTCS.a
=20
diff --git a/tools/vtpm_manager/tcs/contextmgr.c
b/tools/vtpm_manager/tcs/contextmgr.c
--- a/tools/vtpm_manager/tcs/contextmgr.c
+++ b/tools/vtpm_manager/tcs/contextmgr.c
@@ -195,6 +195,7 @@ BOOL DeleteHandleFromList(   TCS_CONTEXT_HANDLE
hContext, // in
=20
 BOOL FreeHandleList(    CONTEXT_HANDLE*     pContextHandle) { // in
   HANDLE_LIST* pCurrentHandle;
+  HANDLE_LIST* pNext;
   BOOL returncode =3D TRUE;
 =20
   vtpmloginfo(VTPM_LOG_TCS_DEEP, "Freeing all handles for context\n");
@@ -205,6 +206,7 @@ BOOL FreeHandleList(    CONTEXT_HANDLE*   =20
pContextHandle) { // in
   pCurrentHandle =3D pContextHandle->pHandleList;
   while (pCurrentHandle !=3D NULL) {
   =20
+    pNext =3D pCurrentHandle->pNextHandle;
     switch (pCurrentHandle->type) {
     case TPM_RT_KEY:
       returncode =3D returncode && !TCSP_EvictKey(pContextHandle->handle=
,
pCurrentHandle->handle);
@@ -216,7 +218,7 @@ BOOL FreeHandleList(    CONTEXT_HANDLE*   =20
pContextHandle) { // in
       returncode =3D FALSE;
     }
   =20
-    pCurrentHandle =3D pCurrentHandle->pNextHandle;
+    pCurrentHandle =3D pNext;
   =20
   }
 =20
diff --git a/tools/vtpm_manager/tcs/tcs.c b/tools/vtpm_manager/tcs/tcs.c
--- a/tools/vtpm_manager/tcs/tcs.c
+++ b/tools/vtpm_manager/tcs/tcs.c
@@ -77,7 +77,7 @@ CONTEXT_HANDLE *LookupContext( TCS_CONTEXT_HANDLE=20
hContext) {
 //
-------------------------------------------------------------------------=
--------
 // Initialization/Uninitialization SubComponent API
 //
-------------------------------------------------------------------------=
--------
-TPM_RESULT TCS_create() {
+TPM_RESULT TCS_create(void) {
   TDDL_RESULT hRes =3D TDDL_E_FAIL;
   TPM_RESULT result =3D TPM_FAIL;
 =20
@@ -101,7 +101,7 @@ TPM_RESULT TCS_create() {
 }
=20
=20
-void TCS_destroy()
+void TCS_destroy(void)
 {
   TCS_m_nCount--;
 =20
@@ -113,14 +113,13 @@ void TCS_destroy()
     TCS_CONTEXT_HANDLE  *hContext;
   =20
     // Close all the TCS contexts. TCS should evict keys based on this
-    if (hashtable_count(context_ht) > 0) {
+    while (hashtable_count(context_ht) > 0) {
       context_itr =3D hashtable_iterator(context_ht);
-      do {
-        hContext =3D (TCS_CONTEXT_HANDLE *)
hashtable_iterator_key(context_itr);
-    if (TCS_CloseContext(*hContext) !=3D TPM_SUCCESS)
-        vtpmlogerror(VTPM_LOG_TCS, "Failed to close context %d
properly.\n", *hContext);
+
+      hContext =3D (TCS_CONTEXT_HANDLE *)
hashtable_iterator_key(context_itr);
+      if (TCS_CloseContext(*hContext) !=3D TPM_SUCCESS)
+        vtpmlogerror(VTPM_LOG_TCS, "Failed to close context %d
properly.\n", *hContext);
     =20
-      } while (hashtable_iterator_advance(context_itr));
       free(context_itr);
     }
     hashtable_destroy(context_ht, 1);
@@ -534,6 +533,10 @@ TPM_RESULT TCSP_TerminateHandle(TCS_CONTEXT_HANDLE
hContext, // in
               BSG_TYPE_UINT32, &handle);
   // fill paramSize again as we now have the correct size
   BSG_Pack(BSG_TYPE_UINT32, &InLength, InBuf+2);
+
+  if (!DeleteHandleFromList(hContext, handle)) {
+    vtpmlogerror(VTPM_LOG_TCS, "KeyHandle not removed from list\n");
+  }
 =20
   // call the TPM driver
   if ((hRes =3D TDDL_TransmitData(InBuf, InLength, OutBuf, &OutLength))
@@ -545,9 +548,6 @@ TPM_RESULT TCSP_TerminateHandle(TCS_CONTEXT_HANDLE
hContext, // in
                BSG_TYPE_UINT32, &paramSize,
                BSG_TPM_COMMAND_CODE, &returnCode);
   =20
-    if (!DeleteHandleFromList(hContext, handle))
-      vtpmlogerror(VTPM_LOG_TCS, "KeyHandle not removed from list\n");
-     =20
   =20
     if (returnCode =3D=3D TPM_SUCCESS && tag =3D=3D TPM_TAG_RSP_COMMAND)=
 {
       // Print debug info
@@ -882,6 +882,7 @@ TPM_RESULT TCSP_CreateWrapKey(TCS_CONTEXT_HANDLE
hContext,   // in
     =20
       memcpy(*prgbKey, tempBuf, *pcKeySize);
     =20
+      BSG_Destroy(BSG_TPM_KEY, &wrappedKey);
       vtpmloginfo(VTPM_LOG_TCS_DEEP, "Received paramSize : %d\n",
paramSize);
     } else
       vtpmlogerror(VTPM_LOG_TCS, "TCSP_CreateWrapKey Failed with return
code %s\n", tpm_get_error_name(returnCode));
@@ -980,6 +981,10 @@ TPM_RESULT TCSP_EvictKey(TCS_CONTEXT_HANDLE
hContext, // in
   BSG_Pack(BSG_TYPE_UINT32, &InLength, InBuf+2);
 =20
   vtpmloginfo(VTPM_LOG_TCS_DEEP, "Sending paramSize =3D %d\n", InLength)=
;
+
+  if (!DeleteHandleFromList(hContext, hKey)) {
+    vtpmlogerror(VTPM_LOG_TCS, "KeyHandle not removed from list\n");
+  }
 =20
   // call the TPM driver
   if ((hRes =3D TDDL_TransmitData(InBuf, InLength, OutBuf, &OutLength))
=3D=3D TDDL_SUCCESS) {
@@ -989,10 +994,6 @@ TPM_RESULT TCSP_EvictKey(TCS_CONTEXT_HANDLE
hContext, // in
                BSG_TYPE_UINT32, &paramSize,
                BSG_TPM_COMMAND_CODE, &returnCode);
   =20
-    if (!DeleteHandleFromList(hContext, hKey)) {
-      vtpmlogerror(VTPM_LOG_TCS, "KeyHandle not removed from list\n");
-    }    =20
-  =20
     if (returnCode =3D=3D TPM_SUCCESS && tag =3D=3D TPM_TAG_RSP_COMMAND)=
 {
       vtpmloginfo(VTPM_LOG_TCS_DEEP, "Received paramSize : %d\n",
paramSize);
     } else {
@@ -1019,7 +1020,7 @@ TPM_RESULT TCSP_GetRandom(TCS_CONTEXT_HANDLE
hContext,  // in
   TDDL_UINT32  OutLength =3D TCPA_MAX_BUFFER_LENGTH;
 =20
   // check input params
-  if (bytesRequested =3D=3D NULL || *randomBytes =3D=3D NULL){
+  if (bytesRequested =3D=3D NULL || randomBytes =3D=3D NULL){
     return TPM_BAD_PARAMETER;
   }
 =20
diff --git a/tools/vtpm_manager/tcs/tcs.h b/tools/vtpm_manager/tcs/tcs.h
--- a/tools/vtpm_manager/tcs/tcs.h
+++ b/tools/vtpm_manager/tcs/tcs.h
@@ -50,8 +50,8 @@
 // Exposed API
 // ------------------------------------------------------------------
=20
-TPM_RESULT TCS_create();
-void TCS_destroy();
+TPM_RESULT TCS_create(void);
+void TCS_destroy(void);
=20
 TPM_RESULT TCS_OpenContext( /* OUT */ TCS_CONTEXT_HANDLE* hContext );
=20
diff --git a/tools/vtpm_manager/tcs/tpmddl.c
b/tools/vtpm_manager/tcs/tpmddl.c
--- /dev/null
+++ b/tools/vtpm_manager/tcs/tpmddl.c
@@ -0,0 +1,167 @@
+/*
+ * Copyright (c) 2010-2012 United States Government, as represented by
+ * the Secretary of Defense.  All rights reserved.
+ *
+ * THIS SOFTWARE AND ITS DOCUMENTATION ARE PROVIDED AS IS AND WITHOUT
+ * ANY EXPRESS OR IMPLIED WARRANTIES WHATSOEVER. ALL WARRANTIES
+ * INCLUDING, BUT NOT LIMITED TO, PERFORMANCE, MERCHANTABILITY, FITNESS
+ * FOR A PARTICULAR  PURPOSE, AND NONINFRINGEMENT ARE HEREBY
+ * DISCLAIMED. USERS ASSUME THE ENTIRE RISK AND LIABILITY OF USING THE
+ * SOFTWARE.
+ */
+
+#include <string.h>
+#include "tpmddl.h"
+#include "tcs.h"
+#include "bsg.h"
+#include "log.h"
+
+#define MIN(X,Y) ((X) < (Y) ? (X) : (Y))
+
+TDDL_RESULT TDDL_GetCapability( TDDL_UINT32 cap,
+      TDDL_UINT32 sub,
+      TDDL_BYTE* buffer,
+      TDDL_UINT32* size)
+{
+   TDDL_RESULT status;
+
+   TPM_TAG tag =3D TPM_TAG_RQU_COMMAND;
+   UINT32 paramsize =3D 22;
+   UINT32 outsize;
+   TPM_COMMAND_CODE ord =3D TPM_ORD_GetCapability;
+   UINT32 subcapsize =3D 4;
+
+   BYTE inbuf[TCPA_MAX_BUFFER_LENGTH];
+   BYTE outbuf[TCPA_MAX_BUFFER_LENGTH];
+
+   int offset;
+
+   BSG_PackList(inbuf, 6,
+     BSG_TPM_TAG, &(tag),
+     BSG_TYPE_UINT32, &(paramsize),
+     BSG_TPM_COMMAND_CODE, &(ord),
+     BSG_TYPE_UINT32, &(cap),
+     BSG_TYPE_UINT32, &(subcapsize),
+     BSG_TYPE_UINT32, &(sub)
+     );
+
+   //Send the command, get the response
+   TPMTRYRETURN(TDDL_TransmitData( inbuf, paramsize, outbuf, &outsize));=

+
+   offset =3D BSG_UnpackList(outbuf, 4,
+     BSG_TPM_TAG, &(tag),
+     BSG_TYPE_UINT32, &(paramsize),
+     BSG_TPM_RESULT, &(status),
+     BSG_TYPE_UINT32, size
+     );
+   if (status !=3D TPM_SUCCESS || tag !=3D TPM_TAG_RSP_COMMAND) {
+      return status;
+   }
+   if(*size >=3D TCPA_MAX_BUFFER_LENGTH - offset) {
+      return TPM_FAIL;
+   }
+   memcpy(buffer, outbuf + offset, *size);
+
+abort_egress:
+   return status;
+}
+
+TDDL_RESULT TDDL_FlushSpecific(TDDL_UINT32 handle, TDDL_UINT32 res) {
+    /* FIXME: Add code here to check if TPM_FlushSpecific is not
supported (on 1.1 only TPMS?)
+    * If this is the case then we need to use TPM_EvictKey for key handl=
es
+    * and TPM_Terminate_Handle/TPM_Reset for auth handles */
+   TDDL_RESULT status;
+
+   TPM_TAG tag =3D TPM_TAG_RQU_COMMAND;
+   UINT32 paramsize =3D 18;
+   TPM_COMMAND_CODE ord =3D TPM_ORD_FlushSpecific;
+
+   BYTE inbuf[TCPA_MAX_BUFFER_LENGTH];
+   BYTE outbuf[TCPA_MAX_BUFFER_LENGTH];
+   UINT32 outsize;
+
+   int offset;
+
+   BSG_PackList(inbuf, 5,
+     BSG_TPM_TAG, &(tag),
+     BSG_TYPE_UINT32, &(paramsize),
+     BSG_TPM_COMMAND_CODE, &(ord),
+     BSG_TPM_HANDLE, &(handle),
+     BSG_TPM_RESOURCE_TYPE, &(res)
+     );
+
+   //Send command
+   TPMTRYRETURN(TDDL_TransmitData( inbuf, paramsize, outbuf, &outsize ))=
;
+
+   offset =3D BSG_UnpackList(outbuf, 4,
+     BSG_TPM_TAG, &(tag),
+     BSG_TYPE_UINT32, &(paramsize),
+     BSG_TPM_RESULT, &(status)
+     );
+
+abort_egress:
+   return status;
+
+}
+
+TDDL_RESULT TDDL_FlushAllResources(void) {
+  TDDL_RESULT status =3D TPM_SUCCESS;
+
+  TDDL_BYTE buf[TCPA_MAX_BUFFER_LENGTH];
+  TDDL_UINT32 bufsiz;
+
+  UINT16 packedsz;
+  int size;
+  UINT32 handle;
+  BYTE* ptr;
+
+  int i, j;
+
+#define RLISTSZ 6
+  TPM_RESOURCE_TYPE reslist[RLISTSZ] =3D { TPM_RT_KEY, TPM_RT_AUTH,
TPM_RT_TRANS, TPM_RT_COUNTER, TPM_RT_DAA_TPM, TPM_RT_CONTEXT };
+
+  //Iterate through each resource type and flush all handles
+  for(i =3D 0; i < RLISTSZ; ++i) {
+     TPM_RESOURCE_TYPE res =3D reslist[i];
+     // Get list of current key handles
+     if((status =3D TDDL_GetCapability( TPM_CAP_HANDLE, res, buf,
&bufsiz)) !=3D TPM_SUCCESS) {
+    //This can happen if the resource type is not supported
+    //If this happens just silently skip the resource type
+    if(status =3D=3D TPM_BAD_MODE) {
+       status =3D TPM_SUCCESS;
+       continue;
+    //Otherwise we just fail
+    } else {
+       TPMTRYRETURN(status);
+    }
+     }
+
+#if 0
+     //DEBUG PRINTOUTS
+     printf("TPM_GetCapability(TPM_CAP_HANDLE, %lu)\n", (unsigned long)
res);
+     for(j =3D 0; j < bufsiz; ++j) {
+    printf("%02X ", buf[j]);
+     }
+     printf("\n");
+#endif
+
+     ptr =3D buf;
+     ptr +=3D BSG_Unpack(BSG_TYPE_UINT16, ptr, &(packedsz));
+     size =3D packedsz;
+
+     //Flush each handle
+     if(size) {
+    vtpmloginfo(VTPM_LOG_VTPM, "Flushing %u handle(s) of type %lu\n",
size, (unsigned long) res);
+    for(j =3D 0; j < size; ++j) {
+       ptr +=3D BSG_Unpack(BSG_TPM_HANDLE, ptr, &(handle));
+       TPMTRYRETURN(TDDL_FlushSpecific(handle, res));
+    }
+     }
+
+  }
+
+  goto egress;
+abort_egress:
+egress:
+  return status;
+}
diff --git a/tools/vtpm_manager/tcs/tpmddl.h
b/tools/vtpm_manager/tcs/tpmddl.h
--- a/tools/vtpm_manager/tcs/tpmddl.h
+++ b/tools/vtpm_manager/tcs/tpmddl.h
@@ -50,13 +50,14 @@ typedef unsigned int TDDL_UINT32;
 typedef TDDL_UINT32 TDDL_RESULT;
 typedef unsigned char TDDL_BYTE;
=20
-TDDL_RESULT TDDL_Open();
-void TDDL_Close();
+TDDL_RESULT TDDL_Open(void);
+TDDL_RESULT TDDL_Open_use_fd(int fd);
+void TDDL_Close(void);
 TDDL_RESULT TDDL_TransmitData( TDDL_BYTE* in,
                    TDDL_UINT32 insize,
                    TDDL_BYTE* out,
                    TDDL_UINT32* outsize);
-TDDL_RESULT TDDL_GetStatus();
+TDDL_RESULT TDDL_GetStatus(void);
 TDDL_RESULT TDDL_GetCapability( TDDL_UINT32 cap,
                 TDDL_UINT32 sub,
                 TDDL_BYTE* buffer,
@@ -66,4 +67,10 @@ TDDL_RESULT TDDL_SetCapability( TDDL_UINT32 cap,
                 TDDL_BYTE* buffer,
                 TDDL_UINT32* size);
=20
+TDDL_RESULT TDDL_FlushSpecific(TDDL_UINT32 handle,
+                TDDL_UINT32 res);
+
+TDDL_RESULT TDDL_FlushAllResources(void);
+
+
 #endif // __TPMDDL_H__
diff --git a/tools/vtpm_manager/tcs/transmit.c
b/tools/vtpm_manager/tcs/transmit.c
--- a/tools/vtpm_manager/tcs/transmit.c
+++ b/tools/vtpm_manager/tcs/transmit.c
@@ -104,12 +104,13 @@ TDDL_TransmitData( TDDL_BYTE* in,
   return status;
 }
=20
-TPM_RESULT TDDL_Open() {
+TDDL_RESULT TDDL_Open(void) {
 =20
   TDDL_RESULT status =3D TDDL_SUCCESS;
 =20
+  /* If tpm device is already open just silently return success */
   if (g_TDDL_open)
-    return TPM_FAIL;
+    return TPM_SUCCESS;
=20
 #ifdef DUMMY_TPM=20
   *g_rx_fdp =3D open (TPM_RX_FNAME, O_RDWR);
@@ -117,7 +118,7 @@ TPM_RESULT TDDL_Open() {
=20
   g_tx_fd =3D open (TPM_TX_FNAME, O_RDWR);
   if (g_tx_fd < 0) {
-    vtpmlogerror(VTPM_LOG_TXDATA, "TPM open failed");
+    vtpmlogerror(VTPM_LOG_TXDATA, "TPM open failed\n");
     return TPM_IOERROR;
   }
 =20
@@ -126,7 +127,20 @@ TPM_RESULT TDDL_Open() {
   return status;
 }
=20
-void TDDL_Close() {
+TDDL_RESULT TDDL_Open_use_fd(int fd) {
+   TDDL_RESULT status =3D TDDL_SUCCESS;
+
+   if(g_TDDL_open)
+      return TPM_FAIL;
+
+   g_tx_fd =3D fd;
+
+   g_TDDL_open =3D 1;
+
+   return status;
+}
+
+void TDDL_Close(void) {
   if (! g_TDDL_open)
         return;
=20
diff --git a/tools/vtpm_manager/util/Makefile
b/tools/vtpm_manager/util/Makefile
--- a/tools/vtpm_manager/util/Makefile
+++ b/tools/vtpm_manager/util/Makefile
@@ -1,5 +1,10 @@
-XEN_ROOT =3D $(CURDIR)/../../..
-include $(XEN_ROOT)/tools/vtpm_manager/Rules.mk
+XEN_ROOT =3D $(realpath ../../..)
+include ../Rules.mk
+
+CFLAGS +=3D -I../crypto
+CFLAGS +=3D -I../tcs
+CFLAGS +=3D -I../manager
+
=20
 BIN        =3D libTCGUtils.a
=20
diff --git a/tools/vtpm_manager/util/bsg.c b/tools/vtpm_manager/util/bsg.=
c
--- a/tools/vtpm_manager/util/bsg.c
+++ b/tools/vtpm_manager/util/bsg.c
@@ -41,6 +41,7 @@
 #include <string.h>
 #include <stdarg.h>
 #include <malloc.h>
+#include <stdlib.h>
 #include "tcg.h"
 #include "crypto.h"
 #include "bsg.h"
@@ -317,7 +318,7 @@ static const BSG_Format* find_format (BSG_Type t) {
 // FIXME: should have a function be passed in here which is called if
the test
 // fails. Then the caller can decide what to do: abort, notify, whatever=

 //
-BOOL BSG_static_selfcheck ()
+BOOL BSG_static_selfcheck (void)
 {
   int i;
=20
diff --git a/tools/vtpm_manager/util/bsg.h b/tools/vtpm_manager/util/bsg.=
h
--- a/tools/vtpm_manager/util/bsg.h
+++ b/tools/vtpm_manager/util/bsg.h
@@ -161,6 +161,6 @@ TPM_RESULT BSG_DestroyTuple (int numParams,
pack_tuple_t params[]);
 void BSG_PackConst(BSG_UINT32 val, int size, BSG_BYTE* dst);
 BSG_UINT32 BSG_UnpackConst(const BSG_BYTE* src, int size);
=20
-BOOL BSG_static_selfcheck ();
+BOOL BSG_static_selfcheck (void);
=20
 #endif
diff --git a/tools/vtpm_manager/util/buffer.c
b/tools/vtpm_manager/util/buffer.c
--- a/tools/vtpm_manager/util/buffer.c
+++ b/tools/vtpm_manager/util/buffer.c
@@ -40,6 +40,7 @@
=20
 #include "tcg.h"
 #include "bsg.h"
+#include "log.h"
 #include "buffer.h"
=20
 static TPM_RESULT buffer_priv_realloc (buffer_t * buf, tpm_size_t newsiz=
e);
@@ -51,6 +52,7 @@ static TPM_RESULT buffer_priv_realloc (buffer_t * buf,
tpm_size_t newsize);
 TPM_RESULT buffer_init (buffer_t * buf, tpm_size_t initsize, const
BYTE* initval) {
   if (initsize =3D=3D 0) {
     memset(buf, 0, sizeof(*buf));
+    buf->bytes =3D NULL;
     return TPM_SUCCESS;
   }
 =20
@@ -62,8 +64,11 @@ TPM_RESULT buffer_init (buffer_t * buf, tpm_size_t
initsize, const BYTE* initval
   buf->size =3D initsize;
   buf->alloc_size =3D initsize;
 =20
-  if (initval)
+  if (initval) {
     memcpy (buf->bytes, initval, initsize);
+  } else {
+     memset(buf->bytes, 0, initsize);
+  }
 =20
   buf->is_owner =3D TRUE;
 =20
@@ -190,6 +195,29 @@ TPM_RESULT buffer_append_raw (buffer_t * buf,
tpm_size_t len, const BYTE* bytes)
   return status;
 }
=20
+TPM_RESULT buffer_prepend_raw(buffer_t * buf, tpm_size_t len, const
BYTE* bytes) {
+  TPM_RESULT status =3D TPM_SUCCESS;
+
+  if (buf->alloc_size < buf->size + len) {
+    TPMTRYRETURN( buffer_priv_realloc (buf, buf->size + len) );
+  }
+
+  if(buf->size > 0) {
+    memmove(buf->bytes + len, buf->bytes, buf->size);
+  }
+  memcpy(buf->bytes, bytes, len);
+
+  buf->size +=3D len;
+
+  goto egress;
+
+ abort_egress:
+
+ egress:
+
+  return status;
+}
+
 tpm_size_t buffer_len (const buffer_t* buf) {
   return buf->size;
 }
@@ -199,7 +227,6 @@ TPM_RESULT buffer_free (buffer_t * buf) {
     free (buf->bytes);
     buf->bytes =3D NULL;
     buf->size =3D buf->alloc_size =3D 0;
- =20
   }
 =20
   return TPM_SUCCESS;
@@ -224,3 +251,13 @@ TPM_RESULT buffer_priv_realloc (buffer_t * buf,
tpm_size_t newsize) {
 =20
   return TPM_SUCCESS;
 }
+
+TPM_RESULT buffer_truncate(buffer_t* buf, tpm_size_t len)
+{
+   if(len <=3D buf->size) {
+      buf->size =3D len;
+      return TPM_SUCCESS;
+   }
+
+   return TPM_FAIL;
+}
diff --git a/tools/vtpm_manager/util/buffer.h
b/tools/vtpm_manager/util/buffer.h
--- a/tools/vtpm_manager/util/buffer.h
+++ b/tools/vtpm_manager/util/buffer.h
@@ -92,4 +92,9 @@ TPM_RESULT buffer_free (buffer_t * buf);
=20
 TPM_RESULT buffer_append_raw (buffer_t * buf, tpm_size_t len, const
BYTE* bytes);
=20
+TPM_RESULT buffer_prepend_raw(buffer_t * buf, tpm_size_t len, const
BYTE* bytes);
+
+//Reduce the size of the buffer, if len > buffer size returns an error
+TPM_RESULT buffer_truncate(buffer_t* buf, tpm_size_t len);
+
 #endif // _TOOLS_H_
diff --git a/tools/vtpm_manager/util/hashtable.c
b/tools/vtpm_manager/util/hashtable.c
--- a/tools/vtpm_manager/util/hashtable.c
+++ b/tools/vtpm_manager/util/hashtable.c
@@ -32,12 +32,6 @@
  * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
 */
=20
-/*
- * There are duplicates of this code in:
- *  - tools/xenstore/hashtable.c
- *  - tools/blktap2/drivers/hashtable.c
- */
-
 #include "hashtable.h"
 #include "hashtable_private.h"
 #include <stdlib.h>
diff --git a/tools/vtpm_manager/util/hashtable.h
b/tools/vtpm_manager/util/hashtable.h
--- a/tools/vtpm_manager/util/hashtable.h
+++ b/tools/vtpm_manager/util/hashtable.h
@@ -32,11 +32,6 @@
  * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
 */
=20
-/*
- * There are duplicates of this code in:
- *  - tools/xenstore/hashtable.h
- *  - tools/blktap2/drivers/hashtable.h
- */
=20
 #ifndef __HASHTABLE_CWC22_H__
 #define __HASHTABLE_CWC22_H__
diff --git a/tools/vtpm_manager/util/hashtable_itr.c
b/tools/vtpm_manager/util/hashtable_itr.c
--- a/tools/vtpm_manager/util/hashtable_itr.c
+++ b/tools/vtpm_manager/util/hashtable_itr.c
@@ -32,11 +32,6 @@
  * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
 */
=20
-/*
- * There are duplicates of this code in:
- *  - tools/blktap2/drivers/hashtable_itr.c
- */
-
 #include "hashtable.h"
 #include "hashtable_private.h"
 #include "hashtable_itr.h"
diff --git a/tools/vtpm_manager/util/hashtable_itr.h
b/tools/vtpm_manager/util/hashtable_itr.h
--- a/tools/vtpm_manager/util/hashtable_itr.h
+++ b/tools/vtpm_manager/util/hashtable_itr.h
@@ -32,11 +32,6 @@
  * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
 */
=20
-/*
- * There are duplicates of this code in:
- *  - tools/blktap2/drivers/hashtable_itr.h
- */
-
=20
 #ifndef __HASHTABLE_ITR_CWC22__
 #define __HASHTABLE_ITR_CWC22__
diff --git a/tools/vtpm_manager/util/hashtable_private.h
b/tools/vtpm_manager/util/hashtable_private.h
--- a/tools/vtpm_manager/util/hashtable_private.h
+++ b/tools/vtpm_manager/util/hashtable_private.h
@@ -32,12 +32,6 @@
  * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
 */
=20
-/*
- * There are duplicates of this code in:
- *  - tools/xenstore/hashtable_private.h
- *  - tools/blktap2/drivers/hashtable_private.h
- */
-
 #ifndef __HASHTABLE_PRIVATE_CWC22_H__
 #define __HASHTABLE_PRIVATE_CWC22_H__
=20
diff --git a/tools/vtpm_manager/util/log.c b/tools/vtpm_manager/util/log.=
c
--- a/tools/vtpm_manager/util/log.c
+++ b/tools/vtpm_manager/util/log.c
@@ -38,6 +38,17 @@
 #include "buffer.h"
 #include "tcg.h"
=20
+char *module_names[] =3D { "",
+                                "CRYPTO",
+                                "BSG",
+                                "TXDATA",
+                                "TCS",
+                                "TCS",
+                                "VTSP",
+                                "VTPM",
+                                "VTPM",
+                                "VTSP"
+                              };
 // Helper code for the consts, eg. to produce messages for error codes.
=20
 typedef struct error_code_entry_t {
diff --git a/tools/vtpm_manager/util/log.h b/tools/vtpm_manager/util/log.=
h
--- a/tools/vtpm_manager/util/log.h
+++ b/tools/vtpm_manager/util/log.h
@@ -36,6 +36,8 @@
=20
 #include <stdint.h>             // for uint32_t
 #include <stddef.h>             // for pointer NULL
+#include <stdio.h>
+#include <tcg.h>
=20
 // =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D LOGGING =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
=20
@@ -50,17 +52,7 @@
 #define VTPM_LOG_VTPM_DEEP   8
 #define VTPM_LOG_VTSP_DEEP   9
=20
-static char *module_names[] =3D { "",
-                                "CRYPTO",
-                                "BSG",
-                                "TXDATA",
-                                "TCS",
-                                "TCS",
-                                "VTSP",
-                                "VTPM",
-                                "VTPM",
-                                "VTSP"
-                              };
+extern char *module_names[];
=20
 // Default to standard logging
 #ifndef LOGGING_MODULES
diff --git a/tools/vtpm_manager/util/tcg.h b/tools/vtpm_manager/util/tcg.=
h
--- a/tools/vtpm_manager/util/tcg.h
+++ b/tools/vtpm_manager/util/tcg.h
@@ -197,6 +197,7 @@ typedef struct pack_buf_t {
   UINT32 size;
   BYTE * data;
 } pack_buf_t;
+#define NULL_PACK_BUF {0,0}
=20
 typedef struct pack_constbuf_t {
   UINT32 size;
@@ -295,6 +296,35 @@ typedef struct pack_constbuf_t {
 #define TPM_ORD_LoadKeyContext           (181UL + TPM_PROTECTED_ORDINAL)=

 #define TPM_ORD_SaveAuthContext          (182UL + TPM_PROTECTED_ORDINAL)=

 #define TPM_ORD_LoadAuthContext          (183UL + TPM_PROTECTED_ORDINAL)=

+#define TPM_ORD_SaveContext                      (184UL +
TPM_PROTECTED_ORDINAL)
+#define TPM_ORD_LoadContext                      (185UL +
TPM_PROTECTED_ORDINAL)
+#define TPM_ORD_FlushSpecific                    (186UL +
TPM_PROTECTED_ORDINAL)
+#define TPM_ORD_PCR_Reset                        (200UL +
TPM_PROTECTED_ORDINAL)
+#define TPM_ORD_NV_DefineSpace                   (204UL +
TPM_PROTECTED_ORDINAL)
+#define TPM_ORD_NV_WriteValue                    (205UL +
TPM_PROTECTED_ORDINAL)
+#define TPM_ORD_NV_WriteValueAuth                (206UL +
TPM_PROTECTED_ORDINAL)
+#define TPM_ORD_NV_ReadValue                     (207UL +
TPM_PROTECTED_ORDINAL)
+#define TPM_ORD_NV_ReadValueAuth                 (208UL +
TPM_PROTECTED_ORDINAL)
+#define TPM_ORD_Delegate_UpdateVerification      (209UL +
TPM_PROTECTED_ORDINAL)
+#define TPM_ORD_Delegate_Manage                  (210UL +
TPM_PROTECTED_ORDINAL)
+#define TPM_ORD_Delegate_CreateKeyDelegation     (212UL +
TPM_PROTECTED_ORDINAL)
+#define TPM_ORD_Delegate_CreateOwnerDelegation   (213UL +
TPM_PROTECTED_ORDINAL)
+#define TPM_ORD_Delegate_VerifyDelegation        (214UL +
TPM_PROTECTED_ORDINAL)
+#define TPM_ORD_Delegate_LoadOwnerDelegation     (216UL +
TPM_PROTECTED_ORDINAL)
+#define TPM_ORD_Delegate_ReadAuth                (217UL +
TPM_PROTECTED_ORDINAL)
+#define TPM_ORD_Delegate_ReadTable               (219UL +
TPM_PROTECTED_ORDINAL)
+#define TPM_ORD_CreateCounter                    (220UL +
TPM_PROTECTED_ORDINAL)
+#define TPM_ORD_IncrementCounter                 (221UL +
TPM_PROTECTED_ORDINAL)
+#define TPM_ORD_ReadCounter                      (222UL +
TPM_PROTECTED_ORDINAL)
+#define TPM_ORD_ReleaseCounter                   (223UL +
TPM_PROTECTED_ORDINAL)
+#define TPM_ORD_ReleaseCounterOwner              (224UL +
TPM_PROTECTED_ORDINAL)
+#define TPM_ORD_EstablishTransport               (230UL +
TPM_PROTECTED_ORDINAL)
+#define TPM_ORD_ExecuteTransport                 (231UL +
TPM_PROTECTED_ORDINAL)
+#define TPM_ORD_ReleaseTransportSigned           (232UL +
TPM_PROTECTED_ORDINAL)
+#define TPM_ORD_GetTicks                         (241UL +
TPM_PROTECTED_ORDINAL)
+#define TPM_ORD_TickStampBlob                    (242UL +
TPM_PROTECTED_ORDINAL)
+#define TPM_ORD_MAX                              (256UL +
TPM_PROTECTED_ORDINAL)
+
 #define TSC_ORD_PhysicalPresence         (10UL + TPM_CONNECTION_ORDINAL)=

=20
=20
@@ -419,8 +449,16 @@ typedef struct pack_constbuf_t {
 /// TPM_ResourceTypes
 #define TPM_RT_KEY      0x00000001
 #define TPM_RT_AUTH     0x00000002
+#define TPM_RT_HASH     0x00000003
 #define TPM_RT_TRANS    0x00000004
 #define TPM_RT_CONTEXT  0x00000005
+#define TPM_RT_COUNTER  0x00000006
+#define TPM_RT_DELEGATE 0x00000007
+#define TPM_RT_DAA_TPM  0x00000008
+#define TPM_RT_DAA_V0   0x00000009
+#define TPM_RT_DAA_V1   0x0000000A
+
+
=20
 // TPM_PROTOCOL_ID values
 #define TPM_PID_OIAP 0x0001
@@ -447,6 +485,64 @@ typedef struct pack_constbuf_t {
 #define TPM_SS_RSASSAPKCS1v15_SHA1 0x0002
 #define TPM_SS_RSASSAPKCS1v15_DER 0x0003
=20
+/*
+ * TPM_CAPABILITY_AREA Values for TPM_GetCapability ([TPM_Part2],
Section 21.1)
+ */
+#define TPM_CAP_ORD                     0x00000001
+#define TPM_CAP_ALG                     0x00000002
+#define TPM_CAP_PID                     0x00000003
+#define TPM_CAP_FLAG                    0x00000004
+#define TPM_CAP_PROPERTY                0x00000005
+#define TPM_CAP_VERSION                 0x00000006
+#define TPM_CAP_KEY_HANDLE              0x00000007
+#define TPM_CAP_CHECK_LOADED            0x00000008
+#define TPM_CAP_SYM_MODE                0x00000009
+#define TPM_CAP_KEY_STATUS              0x0000000C
+#define TPM_CAP_NV_LIST                 0x0000000D
+#define TPM_CAP_MFR                     0x00000010
+#define TPM_CAP_NV_INDEX                0x00000011
+#define TPM_CAP_TRANS_ALG               0x00000012
+#define TPM_CAP_HANDLE                  0x00000014
+#define TPM_CAP_TRANS_ES                0x00000015
+#define TPM_CAP_AUTH_ENCRYPT            0x00000017
+#define TPM_CAP_SELECT_SIZE             0x00000018
+#define TPM_CAP_DA_LOGIC                0x00000019
+#define TPM_CAP_VERSION_VAL             0x0000001A
+
+/* subCap definitions ([TPM_Part2], Section 21.2) */
+#define TPM_CAP_PROP_PCR                0x00000101
+#define TPM_CAP_PROP_DIR                0x00000102
+#define TPM_CAP_PROP_MANUFACTURER       0x00000103
+#define TPM_CAP_PROP_KEYS               0x00000104
+#define TPM_CAP_PROP_MIN_COUNTER        0x00000107
+#define TPM_CAP_FLAG_PERMANENT          0x00000108
+#define TPM_CAP_FLAG_VOLATILE           0x00000109
+#define TPM_CAP_PROP_AUTHSESS           0x0000010A
+#define TPM_CAP_PROP_TRANSESS           0x0000010B
+#define TPM_CAP_PROP_COUNTERS           0x0000010C
+#define TPM_CAP_PROP_MAX_AUTHSESS       0x0000010D
+#define TPM_CAP_PROP_MAX_TRANSESS       0x0000010E
+#define TPM_CAP_PROP_MAX_COUNTERS       0x0000010F
+#define TPM_CAP_PROP_MAX_KEYS           0x00000110
+#define TPM_CAP_PROP_OWNER              0x00000111
+#define TPM_CAP_PROP_CONTEXT            0x00000112
+#define TPM_CAP_PROP_MAX_CONTEXT        0x00000113
+#define TPM_CAP_PROP_FAMILYROWS         0x00000114
+#define TPM_CAP_PROP_TIS_TIMEOUT        0x00000115
+#define TPM_CAP_PROP_STARTUP_EFFECT     0x00000116
+#define TPM_CAP_PROP_DELEGATE_ROW       0x00000117
+#define TPM_CAP_PROP_MAX_DAASESS        0x00000119
+#define TPM_CAP_PROP_DAASESS            0x0000011A
+#define TPM_CAP_PROP_CONTEXT_DIST       0x0000011B
+#define TPM_CAP_PROP_DAA_INTERRUPT      0x0000011C
+#define TPM_CAP_PROP_SESSIONS           0x0000011D
+#define TPM_CAP_PROP_MAX_SESSIONS       0x0000011E
+#define TPM_CAP_PROP_CMK_RESTRICTION    0x0000011F
+#define TPM_CAP_PROP_DURATION           0x00000120
+#define TPM_CAP_PROP_ACTIVE_COUNTER     0x00000122
+#define TPM_CAP_PROP_MAX_NV_AVAILABLE   0x00000123
+#define TPM_CAP_PROP_INPUT_BUFFER       0x00000124
+
 // TPM_KEY_USAGE values
 #define TPM_KEY_EK 0x0000
 #define TPM_KEY_SIGNING 0x0010
diff --git a/tools/vtpm_manager/vtpmconnd/Makefile
b/tools/vtpm_manager/vtpmconnd/Makefile
--- /dev/null
+++ b/tools/vtpm_manager/vtpmconnd/Makefile
@@ -0,0 +1,30 @@
+# Copyright (c) 2010-2012 United States Government, as represented by
+# the Secretary of Defense.  All rights reserved.
+#
+# THIS SOFTWARE AND ITS DOCUMENTATION ARE PROVIDED AS IS AND WITHOUT
+# ANY EXPRESS OR IMPLIED WARRANTIES WHATSOEVER. ALL WARRANTIES
+# INCLUDING, BUT NOT LIMITED TO, PERFORMANCE, MERCHANTABILITY, FITNESS
+# FOR A PARTICULAR  PURPOSE, AND NONINFRINGEMENT ARE HEREBY
+# DISCLAIMED. USERS ASSUME THE ENTIRE RISK AND LIABILITY OF USING THE
+# SOFTWARE.
+#
+
+XEN_ROOT =3D $(realpath ../../..)
+include ../Rules.mk
+
+BIN=3Dvtpmconnd
+OBJS=3Dvtpmconnd.o
+CFLAGS=3D-O2 -Wall
+
+all: ${BIN}
+
+${BIN}: ${OBJS}
+    gcc -o $@ $<
+
+install: ${BIN}
+    install -m 0755 ${BIN} $(DESTDIR)$(BINDIR)/$(BIN)
+
+.PHONY: mrproper
+mrproper: clean
+clean:
+    -rm ${BIN} ${OBJS}
diff --git a/tools/vtpm_manager/vtpmconnd/vtpmconnd.c
b/tools/vtpm_manager/vtpmconnd/vtpmconnd.c
--- /dev/null
+++ b/tools/vtpm_manager/vtpmconnd/vtpmconnd.c
@@ -0,0 +1,253 @@
+/*
+ * Copyright (c) 2010-2012 United States Government, as represented by
+ * the Secretary of Defense.  All rights reserved.
+ *
+ * THIS SOFTWARE AND ITS DOCUMENTATION ARE PROVIDED AS IS AND WITHOUT
+ * ANY EXPRESS OR IMPLIED WARRANTIES WHATSOEVER. ALL WARRANTIES
+ * INCLUDING, BUT NOT LIMITED TO, PERFORMANCE, MERCHANTABILITY, FITNESS
+ * FOR A PARTICULAR  PURPOSE, AND NONINFRINGEMENT ARE HEREBY
+ * DISCLAIMED. USERS ASSUME THE ENTIRE RISK AND LIABILITY OF USING THE
+ * SOFTWARE.
+ */
+
+#include <stdio.h>
+#include <string.h>
+#include <errno.h>
+#include <getopt.h>
+#include <stdint.h>
+#include <unistd.h>
+#include <fcntl.h>
+#include <signal.h>
+#include <ctype.h>
+#include "../manager/vtpm_manager.h"
+
+#define VTPM_BE "/dev/vtpm"
+#define TPM_DEV "/dev/tpm0"
+#define MAX_CMD 4096
+#define DEVNULL "/dev/null"
+#define TPM_SUCCESS_RESP "\x00\x00\x00\x00" "\x01\xC1"
"\x00\x00\x00\x00" "\x00\x00\x00\x00"
+#define TPM_SUCCESS_RESPLEN 14
+
+static int quit =3D 0;
+
+struct Opts {
+   const char* vtpmbe;
+   const char* tpmdev;
+   int verbosity;
+   int daemon;
+};
+
+struct Opts opts =3D {
+   .vtpmbe =3D VTPM_BE,
+   .tpmdev =3D TPM_DEV,
+   .verbosity =3D 0,
+   .daemon =3D 1,
+};
+
+void usage(char* argv0) {
+fprintf(stderr, "Usage:\n \
+\t%s [options] [tpm device node]\n\
+\n\
+-h\t\tdisplay usage message\n\
+-v\t\tturn up verbosity level\n\
+-t <FILE>\tuse FILE for tpm device (default " TPM_DEV ")\n\
+-b <FILE>\tset vtpm backend device to FILE (default: " VTPM_BE ")\n\
+-f\t\trun in the foreground\n",
+argv0
+);
+}
+
+void sighandler(int signum) {
+   quit =3D 1;
+}
+
+int main_loop(int vbefd, int tpmfd) {
+   uint8_t buf[MAX_CMD];
+   ssize_t size, wrote;
+   int i;
+
+   while(!quit) {
+      /* Wait for cmd from vtpm_manager */
+      if((size =3D read(vbefd, buf, MAX_CMD)) < 0) {
+     if(errno =3D=3D EFAULT) {
+        if(opts.verbosity > 0) {
+           fprintf(stderr, "read() failed with error: %s, non-fatal\n",
strerror(errno));
+        }
+        continue;
+     }
+     fprintf(stderr,"Error reading from %s, (%s)\n", opts.vtpmbe,
strerror(errno));
+     return 1;
+      }
+      if(opts.verbosity > 0) {
+     printf("\nvtpm_manager req(%ld):", (long) size);
+     for(i =3D 0; i < size; ++i) {
+        printf(" %02X", buf[i]);
+     }
+     printf("\n");
+      }
+
+      if(quit) {
+     break;
+      }
+
+      /* Forward the cmd to the tpm, exclude the dmi id */
+      if((wrote =3D write(tpmfd, buf + 4, size - 4)) !=3D size - 4) {
+     fprintf(stderr,"Error writing to %s, (%s)\n", opts.tpmdev,
strerror(errno));
+     return 1;
+      }
+
+      if(quit) {
+     break;
+      }
+
+      /* Wait for response from tpm */
+      if((size =3D read(tpmfd, buf + 4, MAX_CMD - 4)) < 0) {
+     fprintf(stderr,"Error reading from %s, (%s)\n", opts.tpmdev,
strerror(errno));
+     return 1;
+      }
+      if(opts.verbosity > 0) {
+     printf("tpm resp(%ld):", (long) size);
+     for(i =3D 0; i < size + 4; ++i) {
+        printf(" %02X", buf[i]);
+     }
+     printf("\n");
+      }
+
+      if(quit) {
+     break;
+      }
+
+      /* Send response back to vtpm_manager */
+      if((wrote =3D write(vbefd, buf, size + 4)) !=3D size + 4) {
+     fprintf(stderr, "Error writing to %s, (%s)\n", opts.vtpmbe,
strerror(errno));
+     return 1;
+      }
+   }
+
+   return 0;
+
+}
+
+int main(int argc, char** argv)
+{
+   int rc;
+   int vbefd, tpmfd;
+   int c;
+   int fd =3D -1;
+   struct sigaction sig;
+   pid_t pid;
+
+   /* Do cmdline opts */
+   opterr =3D 0;
+
+   while ((c =3D getopt (argc, argv, "hfvb:t:")) !=3D -1)
+   {
+      switch (c)
+      {
+     case 'h':
+        usage(argv[0]);
+        return 0;
+     case 'f':
+        opts.daemon =3D 0;
+        break;
+     case 'v':
+        ++opts.verbosity;
+        break;
+     case 'b':
+        opts.vtpmbe =3D optarg;
+        break;
+     case 't':
+        opts.tpmdev =3D optarg;
+        break;
+     case '?':
+        if (optopt =3D=3D 'c')
+           fprintf (stderr, "Option -%c requires an argument.\n", optopt=
);
+        else if (isprint (optopt))
+           fprintf (stderr, "Unknown option `-%c'.\n", optopt);
+        else
+           fprintf (stderr,
+             "Unknown option character `\\x%x'.\n",
+             optopt);
+            usage(argv[0]);
+        return 1;
+     default:
+        return 1;
+      }
+   }
+
+   /* DAEMONIZE */
+   if(opts.daemon) {
+      pid =3D fork();
+      if(pid < 0) {
+     fprintf(stderr, "failed to daemonize! fork() failed : %s\n",
strerror(errno));
+     return 1;
+      }
+
+      if (pid > 0) {
+     return 0;
+      }
+   }
+
+
+   /* SIGNAL HANDLING */
+   sig.sa_handler =3D sighandler;
+   sigemptyset(&sig.sa_mask);
+   sig.sa_flags =3D 0;
+
+   sigaction(SIGINT, &sig, NULL);
+   sigaction(SIGQUIT, &sig, NULL);
+   sigaction(SIGTERM, &sig, NULL);
+
+   /* FAKE OUT THE HOTPLUG SYSTEM */
+   /* Whenever hotplug writes a message let it go to dev null */
+   if(remove(VTPM_RX_HP_FNAME) !=3D 0 && errno !=3D ENOENT) {
+      fprintf(stderr, "Unable to remove %s : %s\n", VTPM_RX_HP_FNAME,
strerror(errno));
+      return -1;
+   }
+   if(symlink(DEVNULL, VTPM_RX_HP_FNAME) !=3D 0) {
+      fprintf(stderr, "Unable to create symlink %s -> %s : %s\n",
VTPM_RX_HP_FNAME, DEVNULL, strerror(errno));
+   }
+
+   /* Whenever hotplug tries to read a response, always return success *=
/
+   if(remove(VTPM_TX_HP_FNAME) !=3D 0 && errno !=3D ENOENT) {
+      fprintf(stderr, "Unable to remove %s : %s\n", VTPM_TX_HP_FNAME,
strerror(errno));
+      return -1;
+   }
+   if((fd =3D open(VTPM_TX_HP_FNAME, O_CREAT | O_WRONLY, S_IRUSR |
S_IWUSR)) < 0) {
+      fprintf(stderr, "Unable to open %s for writing : %s\n",
VTPM_TX_HP_FNAME, strerror(errno));
+      return -1;
+   }
+   if(write(fd, TPM_SUCCESS_RESP, TPM_SUCCESS_RESPLEN) !=3D
TPM_SUCCESS_RESPLEN) {
+      fprintf(stderr, "Unable to write to %s : %s\n", VTPM_TX_HP_FNAME,
strerror(errno));
+      return -1;
+   }
+   close(fd);
+   /* HOTPLUG FAKE OUT DONE */
+
+   /* Open the backend and tpm device */
+   if((vbefd =3D open(opts.vtpmbe, O_RDWR)) < 0) {
+      fprintf(stderr, "Unable to open `%s', (%s)\n", opts.vtpmbe,
strerror(errno));
+      return 1;
+   }
+   if((tpmfd =3D open(opts.tpmdev, O_RDWR)) < 0) {
+      fprintf(stderr, "Unable to open `%s', (%s)\n", opts.tpmdev,
strerror(errno));
+      return 1;
+   }
+   if(opts.verbosity > 0) {
+      fprintf(stderr, "Connected to vtpm backend: %s\n", opts.vtpmbe);
+      fprintf(stderr, "Connected to tpm: %s\n", opts.tpmdev);
+   }
+
+   rc =3D main_loop(vbefd, tpmfd);
+
+   close(vbefd);
+   close(tpmfd);
+
+   remove(VTPM_RX_HP_FNAME);
+   remove(VTPM_TX_HP_FNAME);
+
+
+   return rc;
+
+
+}
diff --git a/tools/vtpm_manager/vtpmmgrtalk/Makefile
b/tools/vtpm_manager/vtpmmgrtalk/Makefile
--- /dev/null
+++ b/tools/vtpm_manager/vtpmmgrtalk/Makefile
@@ -0,0 +1,35 @@
+# Copyright (c) 2010-2012 United States Government, as represented by
+# the Secretary of Defense.  All rights reserved.
+#
+# THIS SOFTWARE AND ITS DOCUMENTATION ARE PROVIDED AS IS AND WITHOUT
+# ANY EXPRESS OR IMPLIED WARRANTIES WHATSOEVER. ALL WARRANTIES
+# INCLUDING, BUT NOT LIMITED TO, PERFORMANCE, MERCHANTABILITY, FITNESS
+# FOR A PARTICULAR  PURPOSE, AND NONINFRINGEMENT ARE HEREBY
+# DISCLAIMED. USERS ASSUME THE ENTIRE RISK AND LIABILITY OF USING THE
+# SOFTWARE.
+#
+
+XEN_ROOT =3D $(realpath ../../..)
+include ../Rules.mk
+
+BIN=3Dvtpmmgrtalk
+OBJS=3Dvtpmmgrtalk.o
+CFLAGS=3D-Wall -O2 -g
+CFLAGS +=3D -I../crypto
+CFLAGS +=3D -I../util
+CFLAGS +=3D -I../tcs
+CFLAGS +=3D -I../manager
+
+
+all: ${BIN}
+
+${BIN}: ${OBJS}
+    gcc -o $@ $<
+
+install: all
+    install -m 0755 ${BIN} $(DESTDIR)$(BINDIR)/$(BIN)
+
+.PHONY: mrproper
+mrproper: clean
+clean:
+    rm -f ${BIN} ${OBJS}
diff --git a/tools/vtpm_manager/vtpmmgrtalk/vtpmmgrtalk.c
b/tools/vtpm_manager/vtpmmgrtalk/vtpmmgrtalk.c
--- /dev/null
+++ b/tools/vtpm_manager/vtpmmgrtalk/vtpmmgrtalk.c
@@ -0,0 +1,105 @@
+/*
+ * Copyright (c) 2010-2012 United States Government, as represented by
+ * the Secretary of Defense.  All rights reserved.
+ *
+ * THIS SOFTWARE AND ITS DOCUMENTATION ARE PROVIDED AS IS AND WITHOUT
+ * ANY EXPRESS OR IMPLIED WARRANTIES WHATSOEVER. ALL WARRANTIES
+ * INCLUDING, BUT NOT LIMITED TO, PERFORMANCE, MERCHANTABILITY, FITNESS
+ * FOR A PARTICULAR  PURPOSE, AND NONINFRINGEMENT ARE HEREBY
+ * DISCLAIMED. USERS ASSUME THE ENTIRE RISK AND LIABILITY OF USING THE
+ * SOFTWARE.
+ */
+#include <unistd.h>
+#include <fcntl.h>
+#include <sys/file.h>
+#include <stdio.h>
+#include <errno.h>
+#include <string.h>
+#include <stdint.h>
+
+#include "../manager/vtpm_manager.h"
+
+int main(int argc, char** argv) {
+   int wfd, rfd;
+   uint8_t buf[COMMAND_BUFFER_SIZE];
+   ssize_t size;
+   int i, c;
+   int rc =3D 0;
+
+   const char* wfile =3D VTPM_RX_HP_FNAME;
+   const char* rfile =3D VTPM_TX_HP_FNAME;
+
+   /* Open for writing in non-blocking mode and exit if
+    * the manager is not waiting on the other side */
+   if((wfd =3D open(wfile, O_WRONLY | O_NONBLOCK)) < 0) {
+      fprintf(stderr, "Error opening %s for writing : %s\n",
wfile,strerror(errno));
+      return 1;
+   }
+   /* Set the pipe back to blocking mode */
+   fcntl(wfd, F_SETFL, 0);
+
+   /* Open the read pipe */
+   if((rfd =3D open(rfile, O_RDONLY)) < 0) {
+      close(wfd);
+      fprintf(stderr, "Error opening %s for reading : %s\n",
rfile,strerror(errno));
+      return 1;
+   }
+
+   /*Grab the ASCII hex input from stdin and convert to binary */
+   for(i =3D 0; i < COMMAND_BUFFER_SIZE; ++i) {
+      c =3D scanf("%02hhX", buf + i);
+      if(c =3D=3D EOF) {
+     break;
+      } else if ( c !=3D 1) {
+     fprintf(stderr, "Malformed Input! Use ASCII hex!\n");
+     rc =3D 1;
+     goto quit;
+      }
+   }
+   size =3D i;
+
+   /* Send request to the manager only if a request was actually given *=
/
+   if(size > 0) {
+      /* Lock the pipes for reading/writing */
+      if(flock(wfd, LOCK_EX)) {
+     fprintf(stderr, "Unable to lock %s : %s\n", wfile, strerror(errno))=
;
+     rc =3D 1;
+     goto quit;
+      }
+      if(flock(rfd, LOCK_EX)) {
+     fprintf(stderr, "Unable to lock %s : %s\n", wfile, strerror(errno))=
;
+     rc =3D 1;
+     goto quit;
+      }
+
+      /* Write the binary data to the pipe */
+      if(write(wfd, buf, size) !=3D size) {
+     fprintf(stderr, "Error writing to %s : %s\n", wfile, strerror(errno=
));
+     rc =3D 1;
+     goto quit;
+      }
+
+      /* Read the response from the manager */
+      size =3D read(rfd, buf, COMMAND_BUFFER_SIZE);
+      if(size < 0) {
+     fprintf(stderr, "Error reading %s : %s\n", rfile, strerror(errno));=

+     rc =3D 1;
+     goto quit;
+      }
+      /* Output the hex */
+      for(i =3D 0; i < size; ++i) {
+     printf("%02X", buf[i]);
+      }
+      fprintf(stderr,"\n");
+
+      /* Unlock the pipes */
+      flock(rfd, LOCK_UN);
+      flock(wfd, LOCK_UN);
+   }
+
+   rc =3D 0;
+quit:
+   close(rfd);
+   close(wfd);
+   return rc;
+}



--------------ms010302090205070800070309
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIDyjCC
A8YwggMvoAMCAQICBD/xyf0wDQYJKoZIhvcNAQEFBQAwLzELMAkGA1UEBhMCVVMxDzANBgNV
BAoTBkpIVUFQTDEPMA0GA1UECxMGQklTRENBMB4XDTEwMDYxMTE4MjIwNloXDTEzMDYxMTE4
NTIwNlowZjELMAkGA1UEBhMCVVMxDzANBgNVBAoTBkpIVUFQTDEPMA0GA1UECxMGUGVvcGxl
MTUwFgYDVQQLEw9WUE5Hcm91cC1CSVNEQ0EwGwYDVQQDExRNYXR0aGV3IEUgRmlvcmF2YW50
ZTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAnpbwVSP6o1Nb5lcW7dd3yTo9iBJdi7qz
4nANOMFPK7JOy5npKN1iiousl28U/scUJES55gPwAWYJK3uVyQAsA4adgDKi5DoD1UHDQEwp
bY7iHLJeq0NPr4BqYNqnCFPbE6HC8zSJrr4qKn+gVUQT39SIFqdiIPJwZL8FYTRQ/zsCAwEA
AaOCAbYwggGyMAsGA1UdDwQEAwIHgDArBgNVHRAEJDAigA8yMDEwMDYxMTE4MjIwNlqBDzIw
MTIwNzE3MjI1MjA2WjAbBg0rBgEEAbMlCwMBAQEBBAoWCGZpb3JhbWUxMBsGDSsGAQQBsyUL
AwEBAQIEChIIMDAxMDQyNjEwWAYJYIZIAYb6ax4BBEsMSVRoZSBwcml2YXRlIGtleSBjb3Jy
ZXNwb25kaW5nIHRvIHRoaXMgY2VydGlmaWNhdGUgbWF5IGhhdmUgYmVlbiBleHBvcnRlZC4w
KAYDVR0RBCEwH4EdTWF0dGhldy5GaW9yYXZhbnRlQGpodWFwbC5lZHUwUgYDVR0fBEswSTBH
oEWgQ6RBMD8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJU0RD
QTEOMAwGA1UEAxMFQ1JMNTYwHwYDVR0jBBgwFoAUCDUpmxH52EU2CyWmF2EJMB1yqeswHQYD
VR0OBBYEFO6LYxg6r9wHZ+zdQtBHn1dZ/YTNMAkGA1UdEwQCMAAwGQYJKoZIhvZ9B0EABAww
ChsEVjcuMQMCBLAwDQYJKoZIhvcNAQEFBQADgYEAJO9HQh4YNChVLzuZqK5ARJARD8JoujGZ
fdo75quvg2jXFQe2sEjvLnxJZgm/pv8fdZakq48CWwjYHKuvIp7sDjTEsQfo+y7SpN/N2NvJ
WU5SqfK1VgYtNLRRoGJUB5Q1aZ+Dg95g3kqpyfpUMISJL8IKVLtJVfN4fggFVUYZ9wwxggGr
MIIBpwIBATA3MC8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJ
U0RDQQIEP/HJ/TAJBgUrDgMCGgUAoIHLMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ
KoZIhvcNAQkFMQ8XDTEyMDkyMTE4NTcxMVowIwYJKoZIhvcNAQkEMRYEFKPbujyMaoD5Y/bw
vdjKJ+sfR8uVMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAK
BggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI
KoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEgYAy62HJSShxKuwnVe5wH8mywUyWOUYtBWIT
JX3Gayph3FS8wW1gBX3XvFcHGxT2B+wqKKl7pKppwgXNuoHETxxnQk/GL4hHPAy40ErilrZr
9NV3V8HG43ti05+B9GhjWQTskih2BxQ4IGUOcMhBL2agyfj1ICxzDnyLtpiR3Yn21QAAAAAA
AA==
--------------ms010302090205070800070309--


--===============1454697601346146772==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============1454697601346146772==--


From xen-devel-bounces@lists.xen.org Fri Sep 21 18:58:55 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Sep 2012 18: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 1TF8R0-0001Zi-5m; Fri, 21 Sep 2012 18:58:42 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <matthew.fioravante@jhuapl.edu>) id 1TF8Qx-0001Zb-Fl
	for xen-devel@lists.xensource.com; Fri, 21 Sep 2012 18:58:40 +0000
Received: from [85.158.139.211:57965] by server-1.bemta-5.messagelabs.com id
	88/ED-04809-ED8BC505; Fri, 21 Sep 2012 18:58:38 +0000
X-Env-Sender: matthew.fioravante@jhuapl.edu
X-Msg-Ref: server-14.tower-206.messagelabs.com!1348253911!19446186!1
X-Originating-IP: [128.244.251.36]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG,
	UNPARSEABLE_RELAY,UPPERCASE_25_50
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23699 invoked from network); 21 Sep 2012 18:58:32 -0000
Received: from pilot.jhuapl.edu (HELO jhuapl.edu) (128.244.251.36)
	by server-14.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 21 Sep 2012 18:58:32 -0000
Received: from ([128.244.207.89])
	by pilot.jhuapl.edu with ESMTP with TLS id 63GHCH1.153409040;
	Fri, 21 Sep 2012 14:58:27 -0400
Message-ID: <505CB887.4090905@jhuapl.edu>
Date: Fri, 21 Sep 2012 14:57:11 -0400
From: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120827 Thunderbird/15.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>, 
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
X-Enigmail-Version: 1.4.4
Subject: [Xen-devel] PATCH [base vtpm and libxl patches 2/6] Bug fixes and
 breakout of vtpm_manager functionality
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1454697601346146772=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a cryptographically signed message in MIME format.

--===============1454697601346146772==
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms010302090205070800070309"

This is a cryptographically signed message in MIME format.

--------------ms010302090205070800070309
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Fix numerous memory leaks, IO deadlocks, and other bugs that make
vtpm_manager barely usable. Also breakout the vtpm_manager compilation
into separate libraries to facilitate reusing parts of it in mini-os
domains. Finally, add new programs for communicating with the manager
correctly to avoid IO deadlock errors.

Signed off by Matthew Fioravante matthew.fioravante@jhuapl.edu

---
Changed since previous:
* rebased off of latest xen-unstable

diff --git a/tools/vtpm_manager/Makefile b/tools/vtpm_manager/Makefile
--- a/tools/vtpm_manager/Makefile
+++ b/tools/vtpm_manager/Makefile
@@ -1,9 +1,9 @@
-XEN_ROOT =3D $(CURDIR)/../..
+XEN_ROOT =3D $(realpath ../..)
=20
 # Base definitions and rules
-include $(XEN_ROOT)/tools/vtpm_manager/Rules.mk
+include Rules.mk
=20
-SUBDIRS        =3D crypto tcs util manager migration
+SUBDIRS        =3D crypto tcs util manager migration vtpmmgrtalk vtpmcon=
nd
 OPENSSL_HEADER    =3D /usr/include/openssl/crypto.h
=20
 .PHONY: all clean install
diff --git a/tools/vtpm_manager/README b/tools/vtpm_manager/README
--- a/tools/vtpm_manager/README
+++ b/tools/vtpm_manager/README
@@ -43,9 +43,6 @@ Compile Flags
 LOGGING_MODULES              -> How extensive logging happens
                                 see util/log.h for more info
=20
-VTPM_MULTI_VM                -> Defined: VTPMs run in their own VMs
-                                Not Defined (default): VTPMs are process=
es
-
 # Debugging flags that may disappear without notice in the future
=20
 DUMMY_BACKEND                -> vtpm_manager listens on /tmp/in.fifo and=

@@ -59,6 +56,10 @@ WELL_KNOWN_OWNER_AUTH        -> Rather than randomly
generating the password for
                                 lost. However this has no protection
from malicious app
                                 issuing a TPM_OwnerClear to wipe the TPM=

=20
+VTPM_STUBDOM             -> vtpm_manager runs in vtpm_stubdom mode with
+                vtpm instances running in mini-os domains
+                (see: stubdom/vtpm/README for details)
+
 Requirements
 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
 - xen-unstable
diff --git a/tools/vtpm_manager/Rules.mk b/tools/vtpm_manager/Rules.mk
--- a/tools/vtpm_manager/Rules.mk
+++ b/tools/vtpm_manager/Rules.mk
@@ -6,7 +6,7 @@ include $(XEN_ROOT)/tools/Rules.mk
 #
=20
 # General compiler flags
-CFLAGS    =3D -Werror -g3
+CFLAGS    =3D -Werror -g3 -I.
=20
 # Generic project files
 HDRS    =3D $(wildcard *.h)
@@ -31,18 +31,18 @@ $(OBJS): $(SRCS)
 CFLAGS +=3D -D_GNU_SOURCE
=20
 # Logging Level. See utils/tools.h for usage
-CFLAGS +=3D
-DLOGGING_MODULES=3D"(BITMASK(VTPM_LOG_TCS)|BITMASK(VTPM_LOG_VTSP)|BITMAS=
K(VTPM_LOG_VTPM))"
+#CFLAGS +=3D
-DLOGGING_MODULES=3D"(BITMASK(VTPM_LOG_TCS)|BITMASK(VTPM_LOG_VTSP)|BITMAS=
K(VTPM_LOG_VTPM))"
=20
 # Silent Mode
 #CFLAGS +=3D -DLOGGING_MODULES=3D0x0
-#CFLAGS +=3D -DLOGGING_MODULES=3D0xff
-
-# Use frontend/backend pairs between manager & DMs?
-#CFLAGS +=3D -DVTPM_MULTI_VM
+CFLAGS +=3D -DLOGGING_MODULES=3D0xff
=20
 # vtpm_manager listens on fifo's rather than backend
 #CFLAGS +=3D -DDUMMY_BACKEND
=20
+# Build for use with vtpm-stubdom
+#CFLAGS +=3D -DVTPM_STUBDOM
+
 # TCS talks to fifo's rather than /dev/tpm. TPM Emulator assumed on fifo=
s
 #CFLAGS +=3D -DDUMMY_TPM
=20
@@ -52,8 +52,3 @@ CFLAGS +=3D
-DLOGGING_MODULES=3D"(BITMASK(VTPM_LOG_TCS)|BITMASK(VTPM_LOG_VTSP)|BITMA
 # Fixed OwnerAuth
 #CFLAGS +=3D -DWELL_KNOWN_OWNER_AUTH
=20
-# Include
-CFLAGS +=3D -I$(XEN_ROOT)/tools/vtpm_manager/crypto
-CFLAGS +=3D -I$(XEN_ROOT)/tools/vtpm_manager/util
-CFLAGS +=3D -I$(XEN_ROOT)/tools/vtpm_manager/tcs
-CFLAGS +=3D -I$(XEN_ROOT)/tools/vtpm_manager/manager
diff --git a/tools/vtpm_manager/crypto/Makefile
b/tools/vtpm_manager/crypto/Makefile
--- a/tools/vtpm_manager/crypto/Makefile
+++ b/tools/vtpm_manager/crypto/Makefile
@@ -1,5 +1,9 @@
-XEN_ROOT =3D $(CURDIR)/../../..
-include $(XEN_ROOT)/tools/vtpm_manager/Rules.mk
+XEN_ROOT =3D $(realpath ../../..)
+include ../Rules.mk
+
+CFLAGS +=3D -I../util
+CFLAGS +=3D -I../tcs
+CFLAGS +=3D -I../manager
=20
 BIN        =3D libtcpaCrypto.a
=20
diff --git a/tools/vtpm_manager/crypto/crypto.c
b/tools/vtpm_manager/crypto/crypto.c
--- a/tools/vtpm_manager/crypto/crypto.c
+++ b/tools/vtpm_manager/crypto/crypto.c
@@ -45,6 +45,8 @@
 #include "crypto.h"
 #include "log.h"
=20
+extern const EVP_CIPHER * SYM_CIPHER;
+
 /**
  * Initialize cryptography library
  * @rand: random seed
@@ -83,6 +85,6 @@ void Crypto_GetRandom(void* data, int size) {
   result =3D RAND_pseudo_bytes((BYTE*) data, size);
 =20
   if (result <=3D 0)
-    vtpmlogerror (VTPM_LOG_CRYPTO, "RAND_pseudo_bytes failed: %s\n",
-         ERR_error_string (ERR_get_error(), NULL));
+    vtpmlogerror (VTPM_LOG_CRYPTO, "RAND_pseudo_bytes failed: rc=3D%d
errstr=3D%s\n",
+      result, ERR_error_string (ERR_get_error(), NULL));
 }
diff --git a/tools/vtpm_manager/crypto/crypto.h
b/tools/vtpm_manager/crypto/crypto.h
--- a/tools/vtpm_manager/crypto/crypto.h
+++ b/tools/vtpm_manager/crypto/crypto.h
@@ -76,7 +76,7 @@ typedef struct CRYPTO_INFO {
=20
 void Crypto_Init(const BYTE* rand, int size);
=20
-void Crypto_Exit();
+void Crypto_Exit(void);
=20
 void Crypto_GetRandom(void* data, int size);
=20
@@ -127,6 +127,8 @@ void Crypto_RSABuildCryptoInfoPublic(   /*[IN]*/
UINT32 pubExpSize,
                                         /*[IN]*/ BYTE *modulus,
                                         CRYPTO_INFO* cryptoInfo);
=20
+void Crypto_RSACryptoInfoFree(CRYPTO_INFO* cryptoInfo);
+
 //
 // symmetric pack and unpack operations
 //
diff --git a/tools/vtpm_manager/crypto/rsa.c
b/tools/vtpm_manager/crypto/rsa.c
--- a/tools/vtpm_manager/crypto/rsa.c
+++ b/tools/vtpm_manager/crypto/rsa.c
@@ -149,6 +149,10 @@ void Crypto_RSABuildCryptoInfoPublic(   /*[IN]*/
UINT32 pubExpSize,
 =20
 }
=20
+void Crypto_RSACryptoInfoFree(CRYPTO_INFO* cryptoInfo) {
+   RSA_free(cryptoInfo->keyInfo);
+}
+
 int Crypto_RSAEnc(  CRYPTO_INFO *key,
             UINT32 inDataSize,
             BYTE *inData,
@@ -161,6 +165,7 @@ int Crypto_RSAEnc(  CRYPTO_INFO *key,
   =20
   if (paddedData =3D=3D NULL)
     return -1;
+  memset(paddedData, 0, sizeof(BYTE) * paddedDataSize);
=20
   *outDataSize =3D 0;
 =20
diff --git a/tools/vtpm_manager/crypto/sym_crypto.c
b/tools/vtpm_manager/crypto/sym_crypto.c
--- a/tools/vtpm_manager/crypto/sym_crypto.c
+++ b/tools/vtpm_manager/crypto/sym_crypto.c
@@ -41,8 +41,16 @@
 #include <openssl/rand.h>
=20
 #include "tcg.h"
+#include "log.h"
 #include "sym_crypto.h"
=20
+struct symkey_t {
+  buffer_t key;
+
+  EVP_CIPHER_CTX context;
+  const EVP_CIPHER * cipher;
+};
+
 typedef enum crypt_op_type_t {
   CRYPT_ENCRYPT,
   CRYPT_DECRYPT
@@ -61,19 +69,22 @@ const EVP_CIPHER * SYM_CIPHER =3D NULL;
 const BYTE ZERO_IV[EVP_MAX_IV_LENGTH] =3D {0};
=20
=20
-TPM_RESULT Crypto_symcrypto_initkey (symkey_t * key, const buffer_t*
keybits) {
+TPM_RESULT Crypto_symcrypto_initkey (symkey_t ** key, const buffer_t*
keybits) {
   TPM_RESULT status =3D TPM_SUCCESS;
 =20
-  EVP_CIPHER_CTX_init (&key->context);
+  *key =3D malloc(sizeof(symkey_t));
+
+  EVP_CIPHER_CTX_init (&(*key)->context);
 =20
-  key->cipher =3D SYM_CIPHER;
+  (*key)->cipher =3D SYM_CIPHER;
 =20
-  TPMTRYRETURN( buffer_init_copy (&key->key, keybits));
+  TPMTRYRETURN( buffer_init_copy (&(*key)->key, keybits));
   =20
   goto egress;
 =20
  abort_egress:
-  EVP_CIPHER_CTX_cleanup (&key->context);
+  EVP_CIPHER_CTX_cleanup (&(*key)->context);
+  free(key);
 =20
  egress:
 =20
@@ -82,19 +93,21 @@ TPM_RESULT Crypto_symcrypto_initkey (symkey_t * key,
const buffer_t* keybits) {
=20
=20
=20
-TPM_RESULT Crypto_symcrypto_genkey (symkey_t * key) {
+TPM_RESULT Crypto_symcrypto_genkey (symkey_t ** key) {
   int res;
   TPM_RESULT status =3D TPM_SUCCESS;
+
+  *key =3D malloc(sizeof(symkey_t));
 =20
   // hmm, EVP_CIPHER_CTX_init does not return a value
-  EVP_CIPHER_CTX_init (&key->context);
+  EVP_CIPHER_CTX_init (&(*key)->context);
 =20
-  key->cipher =3D SYM_CIPHER;
+  (*key)->cipher =3D SYM_CIPHER;
 =20
-  TPMTRYRETURN( buffer_init (&key->key,
EVP_CIPHER_key_length(key->cipher), NULL)) ;
+  TPMTRYRETURN( buffer_init (&(*key)->key,
EVP_CIPHER_key_length((*key)->cipher), NULL)) ;
 =20
   // and generate the key material
-  res =3D RAND_pseudo_bytes (key->key.bytes, key->key.size);
+  res =3D RAND_pseudo_bytes ((*key)->key.bytes, (*key)->key.size);
   if (res < 0)
     ERRORDIE (TPM_SHORTRANDOM);
 =20
@@ -102,8 +115,9 @@ TPM_RESULT Crypto_symcrypto_genkey (symkey_t * key) {=

   goto egress;
 =20
  abort_egress:
-  EVP_CIPHER_CTX_cleanup (&key->context);
-  buffer_free (&key->key);
+  EVP_CIPHER_CTX_cleanup (&(*key)->context);
+  buffer_free (&(*key)->key);
+  free(key);
 =20
  egress:
   return status;=20
@@ -119,11 +133,11 @@ TPM_RESULT Crypto_symcrypto_encrypt (symkey_t* key,=

 =20
   buffer_init_const (&iv, EVP_MAX_IV_LENGTH, ZERO_IV);
 =20
-  buffer_init (o_cipher,
-           clear->size +
-           EVP_CIPHER_iv_length(key->cipher) +
-           EVP_CIPHER_block_size (key->cipher),
-                 0);
+  TPMTRYRETURN( buffer_init (o_cipher,
+                  clear->size +
+                  EVP_CIPHER_iv_length(key->cipher) +
+                  EVP_CIPHER_block_size (key->cipher),
+                 0) );
 =20
   // copy the IV into the front
   buffer_copy (o_cipher, &iv);
@@ -139,6 +153,7 @@ TPM_RESULT Crypto_symcrypto_encrypt (symkey_t* key,
   goto egress;
 =20
  abort_egress:
+  buffer_free(o_cipher);
 =20
  egress:
 =20
@@ -170,7 +185,7 @@ TPM_RESULT Crypto_symcrypto_decrypt (symkey_t* key,
 =20
   // and decrypt
   TPMTRYRETURN ( ossl_symcrypto_op (key, &cipher_alias, &iv, o_clear,
CRYPT_DECRYPT) );
-=20
+
   goto egress;
 =20
  abort_egress:
@@ -188,6 +203,8 @@ TPM_RESULT Crypto_symcrypto_freekey (symkey_t * key) =
{
   buffer_free (&key->key);
 =20
   EVP_CIPHER_CTX_cleanup (&key->context);
+
+  free(key);
 =20
   return TPM_SUCCESS;
 }
@@ -235,3 +252,8 @@ TPM_RESULT ossl_symcrypto_op (symkey_t* key,
 =20
   return status;
 }
+
+buffer_t* Crypto_symkey_getkey(symkey_t* key)
+{
+   return &key->key;
+}
diff --git a/tools/vtpm_manager/crypto/sym_crypto.h
b/tools/vtpm_manager/crypto/sym_crypto.h
--- a/tools/vtpm_manager/crypto/sym_crypto.h
+++ b/tools/vtpm_manager/crypto/sym_crypto.h
@@ -40,21 +40,15 @@
 #ifndef _SYM_CRYPTO_H
 #define _SYM_CRYPTO_H
=20
-#include <openssl/evp.h>
 #include "buffer.h"
=20
-typedef struct symkey_t {
-  buffer_t key;
-=20
-  EVP_CIPHER_CTX context;
-  const EVP_CIPHER * cipher;
-} symkey_t;
+typedef struct symkey_t symkey_t;
=20
-extern const EVP_CIPHER * SYM_CIPHER;
+//Allocates a symkey with random bits
+TPM_RESULT Crypto_symcrypto_genkey (symkey_t ** key);
=20
-TPM_RESULT Crypto_symcrypto_genkey (symkey_t * key);
-
-TPM_RESULT Crypto_symcrypto_initkey (symkey_t * key, const buffer_t*
keybits);
+//Allocates a symkey with given keybits
+TPM_RESULT Crypto_symcrypto_initkey (symkey_t ** key, const buffer_t*
keybits);
=20
=20
 // these functions will allocate their output buffers
@@ -66,7 +60,10 @@ TPM_RESULT Crypto_symcrypto_decrypt (symkey_t* key,
                               const buffer_t* cipher,
                               buffer_t* o_clear);
=20
-// only free the internal parts, not the 'key' ptr
+//Frees the symkey
 TPM_RESULT Crypto_symcrypto_freekey (symkey_t * key);
=20
+//Get the raw key byte buffer
+buffer_t* Crypto_symkey_getkey(symkey_t* key);
+
 #endif /* _SYM_CRYPTO_H */
diff --git a/tools/vtpm_manager/manager/Makefile
b/tools/vtpm_manager/manager/Makefile
--- a/tools/vtpm_manager/manager/Makefile
+++ b/tools/vtpm_manager/manager/Makefile
@@ -1,7 +1,18 @@
-XEN_ROOT =3D $(CURDIR)/../../..
-include $(XEN_ROOT)/tools/vtpm_manager/Rules.mk
+XEN_ROOT =3D $(realpath ../../..)
+include ../Rules.mk
+
+CFLAGS +=3D -I../crypto
+CFLAGS +=3D -I../util
+CFLAGS +=3D -I../tcs
+
+
+MAINS         :=3D vtpmd.o
+MGRLIB         :=3D libvtpmmanager.a
+VTSPOBJS    :=3D vtsp.o
+VTSPLIB        :=3D libvtsp.a
+BIN        :=3D vtpm_managerd
+OBJS         :=3D $(filter-out $(MAINS) $(VTSPOBJS), $(OBJS))
=20
-BIN        =3D vtpm_managerd
=20
 .PHONY: all
 all: build
@@ -28,8 +39,14 @@ clean:
 mrproper: clean
     rm -f *~
=20
-$(BIN): $(OBJS)
-    $(CC) $(LDFLAGS) $^ $(LIBS) -o $@
+$(BIN): $(MAINS) $(MGRLIB) $(VTSPLIB)
+    $(CC) $(CFLAGS) $(LDFLAGS) $^ $(LIBS) -o $@
+
+$(VTSPLIB): $(VTSPOBJS)
+    $(AR) rcs $@ $^
+
+$(MGRLIB): $(OBJS)
+    $(AR) rcs $@ $^
=20
 # libraries
 LIBS +=3D ../tcs/libTCS.a ../util/libTCGUtils.a ../crypto/libtcpaCrypto.=
a
diff --git a/tools/vtpm_manager/manager/dmictl.c
b/tools/vtpm_manager/manager/dmictl.c
--- a/tools/vtpm_manager/manager/dmictl.c
+++ b/tools/vtpm_manager/manager/dmictl.c
@@ -40,6 +40,9 @@
 #include <stdio.h>
 #include <unistd.h>
 #include <string.h>
+#include <fcntl.h>
+#include <inttypes.h>
+#include <stdlib.h>
=20
 #include "vtpmpriv.h"
 #include "bsg.h"
@@ -51,6 +54,13 @@
=20
 #define TPM_EMULATOR_PATH "/usr/bin/vtpmd"
=20
+#ifndef VTPM_STUBDOM
+// This is needed to all extra_close_dmi to close this to prevent a
+// broken pipe when no DMIs are left.
+vtpm_ipc_handle_t *g_rx_tpm_ipc_h;
+#endif
+
+
 // if dmi_res is non-null, then return a pointer to new object.
 // Also, this does not fill in the measurements. They should be filled b=
y
 // design dependent code or saveNVM
@@ -81,7 +91,7 @@ TPM_RESULT init_dmi(UINT32 dmi_id, BYTE dmi_type,
VTPM_DMI_RESOURCE **dmi_res) {
=20
   // install into map
   if (!hashtable_insert(vtpm_globals->dmi_map, dmi_id_key, new_dmi)){
-    vtpmlogerror(VTPM_LOG_VTPM, "Failed to insert instance into table.
Aborting.\n", dmi_id);
+    vtpmlogerror(VTPM_LOG_VTPM, "Failed to insert instance %" PRIu32
"into table. Aborting.\n", dmi_id);
     status =3D TPM_FAIL;
     goto abort_egress;
   }
@@ -116,6 +126,161 @@ TPM_RESULT close_dmi(VTPM_DMI_RESOURCE *dmi_res) {
=20
   return (VTPM_Close_DMI_Extra(dmi_res) );
 }
+
+void free_dmi(VTPM_DMI_RESOURCE *dmi_res) {
+   if(dmi_res !=3D NULL) {
+      free(dmi_res->NVMLocation);
+   }
+   free(dmi_res);
+}
+
+TPM_RESULT VTPM_New_DMI_Extra(VTPM_DMI_RESOURCE *dmi_res, BYTE vm_type,
BYTE startup_mode) {
+
+  TPM_RESULT status =3D TPM_SUCCESS;
+#ifndef VTPM_STUBDOM
+  int fh;
+  char dmi_id_str[11]; // UINT32s are up to 10 digits + NULL
+  char *tx_vtpm_name, *tx_tpm_name, *vm_type_string;
+  struct stat file_info;
+
+  if (dmi_res->dmi_id =3D=3D VTPM_CTL_DM) {
+    dmi_res->tx_tpm_ipc_h =3D NULL;
+    dmi_res->rx_tpm_ipc_h =3D NULL;
+    dmi_res->tx_vtpm_ipc_h =3D NULL;
+    dmi_res->rx_vtpm_ipc_h =3D NULL;
+  } else {
+    // Create a pair of fifo pipes
+    dmi_res->rx_tpm_ipc_h =3D NULL;
+    dmi_res->rx_vtpm_ipc_h =3D NULL;
+
+    if ( ((dmi_res->tx_tpm_ipc_h =3D (vtpm_ipc_handle_t *) malloc
(sizeof(vtpm_ipc_handle_t))) =3D=3D NULL ) ||
+         ((dmi_res->tx_vtpm_ipc_h =3D(vtpm_ipc_handle_t *) malloc
(sizeof(vtpm_ipc_handle_t))) =3D=3D NULL ) ||
+         ((tx_tpm_name =3D (char *) malloc(11 +
strlen(VTPM_TX_TPM_FNAME))) =3D=3D NULL ) ||
+         ((tx_vtpm_name =3D(char *) malloc(11 +
strlen(VTPM_TX_VTPM_FNAME))) =3D=3D NULL) ) {
+      status =3DTPM_RESOURCES;
+      goto abort_egress;
+    }
+
+    sprintf(tx_tpm_name, VTPM_TX_TPM_FNAME, (uint32_t) dmi_res->dmi_id);=

+    sprintf(tx_vtpm_name, VTPM_TX_VTPM_FNAME, (uint32_t) dmi_res->dmi_id=
);
+
+    if ( (vtpm_ipc_init(dmi_res->tx_tpm_ipc_h, tx_tpm_name, O_WRONLY |
O_NONBLOCK, TRUE, FALSE) !=3D 0) ||
+         (vtpm_ipc_init(dmi_res->tx_vtpm_ipc_h, tx_vtpm_name, O_WRONLY,
TRUE, FALSE) !=3D 0) ) { //FIXME: O_NONBLOCK?
+      status =3D TPM_IOERROR;
+      goto abort_egress;
+    }
+
+    // Measure DMI
+    // FIXME: This will measure DMI. Until then use a fixed
DMI_Measurement value
+    // Also, this mechanism is specific to 1 VM architecture.
+    /*
+    fh =3D open(TPM_EMULATOR_PATH, O_RDONLY);
+    stat_ret =3D fstat(fh, &file_stat);
+    if (stat_ret =3D=3D 0)
+      dmi_size =3D file_stat.st_size;
+    else {
+      vtpmlogerror(VTPM_LOG_VTPM, "Could not open vtpmd!!\n");
+      status =3D TPM_IOERROR;
+      goto abort_egress;
+    }
+    dmi_buffer
+    */
+    memset(&dmi_res->DMI_measurement, 0xcc, sizeof(TPM_DIGEST));
+
+    if (vm_type =3D=3D VTPM_TYPE_PVM)
+      vm_type_string =3D (BYTE *)&VTPM_TYPE_PVM_STRING;
+    else
+      vm_type_string =3D (BYTE *)&VTPM_TYPE_HVM_STRING;
+
+    // Launch DMI
+    sprintf(dmi_id_str, "%d", (int) dmi_res->dmi_id);
+#ifdef MANUAL_DM_LAUNCH
+    vtpmlogerror(VTPM_LOG_VTPM, "Manually start VTPM with dmi=3D%s
now.\n", dmi_id_str);
+    dmi_res->dmi_pid =3D 0;
+#else
+    pid_t pid =3D fork();
+
+    if (pid =3D=3D -1) {
+      vtpmlogerror(VTPM_LOG_VTPM, "Could not fork to launch vtpm\n");
+      status =3D TPM_RESOURCES;
+      goto abort_egress;
+    } else if (pid =3D=3D 0) {
+      switch (startup_mode) {
+      case TPM_ST_CLEAR:
+        execl (TPM_EMULATOR_PATH, "vtpmd", "clear", vm_type_string,
dmi_id_str, NULL);
+        break;
+      case TPM_ST_STATE:
+        execl (TPM_EMULATOR_PATH, "vtpmd", "save", vm_type_string,
dmi_id_str, NULL);
+        break;
+      case TPM_ST_DEACTIVATED:
+        execl (TPM_EMULATOR_PATH, "vtpmd", "deactivated",
vm_type_string, dmi_id_str, NULL);
+        break;
+      default:
+        status =3D TPM_BAD_PARAMETER;
+        goto abort_egress;
+      }
+
+      // Returning from these at all is an error.
+      vtpmlogerror(VTPM_LOG_VTPM, "Could not exec to launch vtpm\n");
+    } else {
+      dmi_res->dmi_pid =3D pid;
+      vtpmloginfo(VTPM_LOG_VTPM, "Launching DMI on PID =3D %d\n", pid);
+    }
+#endif // MANUAL_DM_LAUNCH
+
+  } // If DMI =3D VTPM_CTL_DM
+    status =3D TPM_SUCCESS;
+#endif
+
+abort_egress:
+    //FIXME: Everything should be freed here
+  return (status);
+}
+
+TPM_RESULT VTPM_Close_DMI_Extra(VTPM_DMI_RESOURCE *dmi_res) {
+  TPM_RESULT status =3D TPM_SUCCESS;
+
+#ifndef VTPM_STUBDOM
+  if (vtpm_globals->connected_dmis =3D=3D 0) {
+    // No more DMI's connected. Close fifo to prevent a broken pipe.
+    // This is hackish. Need to think of another way.
+    vtpm_ipc_close(g_rx_tpm_ipc_h);
+  }
+
+
+  if (dmi_res->dmi_id !=3D VTPM_CTL_DM) {
+    vtpm_ipc_close(dmi_res->tx_tpm_ipc_h);
+    vtpm_ipc_close(dmi_res->tx_vtpm_ipc_h);
+
+    free(dmi_res->tx_tpm_ipc_h->name);
+    free(dmi_res->tx_vtpm_ipc_h->name);
+    free(dmi_res->tx_tpm_ipc_h);
+    free(dmi_res->tx_vtpm_ipc_h);
+
+#ifndef MANUAL_DM_LAUNCH
+    if (dmi_res->dmi_id !=3D VTPM_CTL_DM) {
+      if (dmi_res->dmi_pid !=3D 0) {
+        vtpmloginfo(VTPM_LOG_VTPM, "Killing dmi on pid %d.\n",
dmi_res->dmi_pid);
+        if (kill(dmi_res->dmi_pid, SIGKILL) !=3D0) {
+          vtpmloginfo(VTPM_LOG_VTPM, "DMI on pid %d is already
dead.\n", dmi_res->dmi_pid);
+        } else if (waitpid(dmi_res->dmi_pid, NULL, 0) !=3D
dmi_res->dmi_pid) {
+          vtpmlogerror(VTPM_LOG_VTPM, "DMI on pid %d failed to
stop.\n", dmi_res->dmi_pid);
+          status =3D TPM_FAIL;
+        }
+      } else {
+        vtpmlogerror(VTPM_LOG_VTPM, "Could not kill dmi because it's
pid was 0.\n");
+        status =3D TPM_FAIL;
+      }
+    }
+#endif
+
+  } //endif ! dom0
+#endif
+  return status;
+}
+
+
+
   =20
 TPM_RESULT VTPM_Handle_New_DMI(const buffer_t *param_buf) {
 =20
@@ -254,7 +419,7 @@ TPM_RESULT VTPM_Handle_Delete_DMI( const buffer_t
*param_buf) {
 =20
   // Close DMI first
   TPMTRYRETURN(close_dmi( dmi_res ));
-  free ( dmi_res );
+  free_dmi(dmi_res);
   =20
   status=3DTPM_SUCCESS;  =20
   goto egress;
diff --git a/tools/vtpm_manager/manager/migration.c
b/tools/vtpm_manager/manager/migration.c
--- a/tools/vtpm_manager/manager/migration.c
+++ b/tools/vtpm_manager/manager/migration.c
@@ -40,6 +40,7 @@
 #include <stdio.h>
 #include <unistd.h>
 #include <string.h>
+#include <stdlib.h>
=20
 #include "vtpmpriv.h"
 #include "bsg.h"
@@ -263,7 +264,7 @@ TPM_RESULT VTPM_Handle_Get_Migration_key( const
buffer_t *param_buf,
 TPM_RESULT VTPM_Handle_Load_Migration_key( const buffer_t *param_buf,
                                            buffer_t *result_buf) {
=20
-  TPM_RESULT status=3DTPM_FAIL;
+  TPM_RESULT status=3DTPM_SUCCESS;
   VTPM_MIGKEY_LIST *mig_key;
=20
   vtpmloginfo(VTPM_LOG_VTPM, "Loading Migration Public Key.\n");
@@ -303,5 +304,5 @@ TPM_RESULT VTPM_Handle_Load_Migration_key( const
buffer_t *param_buf,
   free(pubkey_exp_pack.data);
   free(pubkey_mod_pack.data);
=20
-  return TPM_SUCCESS;
+  return status;
 }
diff --git a/tools/vtpm_manager/manager/securestorage.c
b/tools/vtpm_manager/manager/securestorage.c
--- a/tools/vtpm_manager/manager/securestorage.c
+++ b/tools/vtpm_manager/manager/securestorage.c
@@ -42,7 +42,7 @@
 #include <fcntl.h>
 #include <unistd.h>
 #include <string.h>
-
+#include <stdlib.h>
 #include "tcg.h"
 #include "vtpm_manager.h"
 #include "vtpmpriv.h"
@@ -58,7 +58,7 @@ TPM_RESULT envelope_encrypt(const buffer_t     *inbuf,
                             CRYPTO_INFO        *asymkey,
                             buffer_t           *sealed_data) {
   TPM_RESULT status =3D TPM_SUCCESS;
-  symkey_t    symkey;
+  symkey_t    *symkey;
   buffer_t    data_cipher =3D NULL_BUF,
               symkey_cipher =3D NULL_BUF;
 =20
@@ -69,14 +69,14 @@ TPM_RESULT envelope_encrypt(const buffer_t     *inbuf=
,
   for (i=3D0; i< buffer_len(inbuf); i++)
     vtpmloginfomore(VTPM_LOG_VTPM_DEEP, "%x ", inbuf->bytes[i]);
   vtpmloginfomore(VTPM_LOG_VTPM_DEEP, "\n");
-=20
+
   // Generate a sym key and encrypt state with it
   TPMTRY(TPM_ENCRYPT_ERROR, Crypto_symcrypto_genkey (&symkey) );
-  TPMTRY(TPM_ENCRYPT_ERROR, Crypto_symcrypto_encrypt (&symkey, inbuf,
&data_cipher) );
+  TPMTRY(TPM_ENCRYPT_ERROR, Crypto_symcrypto_encrypt (symkey, inbuf,
&data_cipher) );
 =20
   // Encrypt symmetric key
   TPMTRYRETURN( VTSP_Bind(    asymkey,
-                  &symkey.key,
+                  Crypto_symkey_getkey(symkey),
                   &symkey_cipher) );
 =20
   // Create output blob: symkey_size + symkey_cipher +
state_cipher_size + state_cipher
@@ -86,8 +86,9 @@ TPM_RESULT envelope_encrypt(const buffer_t     *inbuf,
 =20
   data_cipher32.size =3D buffer_len(&data_cipher);
   data_cipher32.data =3D data_cipher.bytes;
-=20
+
   TPMTRYRETURN( buffer_init(sealed_data, 2 * sizeof(UINT32) +
symkey_cipher32.size + data_cipher32.size, NULL));
+  memset(sealed_data->bytes, 0, sealed_data->size);
 =20
   BSG_PackList(sealed_data->bytes, 2,
            BSG_TPM_SIZE32_DATA, &symkey_cipher32,
@@ -109,11 +110,37 @@ TPM_RESULT envelope_encrypt(const buffer_t     *inb=
uf,
 =20
   buffer_free ( &data_cipher);
   buffer_free ( &symkey_cipher);
-  Crypto_symcrypto_freekey (&symkey);
+  Crypto_symcrypto_freekey (symkey);
 =20
   return status;
 }
=20
+TPM_RESULT symkey_encrypt(const buffer_t     *inbuf,
+                            CRYPTO_INFO        *asymkey,
+                            buffer_t           *sealed_key) {
+  buffer_t symkey_cipher =3D NULL_BUF;
+  struct pack_constbuf_t symkey_cipher32;
+  TPM_RESULT status =3D TPM_SUCCESS;
+
+  // Encrypt symmetric key
+  TPMTRYRETURN( VTSP_Bind(    asymkey,
+                  inbuf,
+                  &symkey_cipher));
+
+  symkey_cipher32.size =3D buffer_len(&symkey_cipher);
+  symkey_cipher32.data =3D symkey_cipher.bytes;
+
+  TPMTRYRETURN( buffer_init(sealed_key, sizeof(UINT32) +
symkey_cipher32.size, NULL));
+  BSG_PackList(sealed_key->bytes, 1,
+           BSG_TPM_SIZE32_DATA, &symkey_cipher32);
+  goto egress;
+abort_egress:
+egress:
+  buffer_free( &symkey_cipher);
+  return status;
+}
+
+
 TPM_RESULT envelope_decrypt(const buffer_t     *cipher,
                             TCS_CONTEXT_HANDLE TCSContext,
                 TPM_HANDLE         keyHandle,
@@ -121,15 +148,13 @@ TPM_RESULT envelope_decrypt(const buffer_t   =20
*cipher,
                             buffer_t           *unsealed_data) {
=20
   TPM_RESULT status =3D TPM_SUCCESS;
-  symkey_t    symkey;
+  symkey_t    *symkey;
   buffer_t    data_cipher =3D NULL_BUF,
               symkey_clear =3D NULL_BUF,
               symkey_cipher =3D NULL_BUF;
-  struct pack_buf_t symkey_cipher32, data_cipher32;
+  struct pack_buf_t symkey_cipher32 =3D NULL_PACK_BUF, data_cipher32 =3D=

NULL_PACK_BUF;
   int i;
=20
-  memset(&symkey, 0, sizeof(symkey_t));
-
   vtpmloginfo(VTPM_LOG_VTPM_DEEP, "Envelope Decrypt Input[%d]: 0x",
buffer_len(cipher) );
   for (i=3D0; i< buffer_len(cipher); i++)
     vtpmloginfomore(VTPM_LOG_VTPM_DEEP, "%x ", cipher->bytes[i]);
@@ -159,7 +184,7 @@ TPM_RESULT envelope_decrypt(const buffer_t     *ciphe=
r,
   Crypto_symcrypto_initkey (&symkey, &symkey_clear);
 =20
   // Decrypt State
-  TPMTRY(TPM_DECRYPT_ERROR, Crypto_symcrypto_decrypt (&symkey,
&data_cipher, unsealed_data) );
+  TPMTRY(TPM_DECRYPT_ERROR, Crypto_symcrypto_decrypt (symkey,
&data_cipher, unsealed_data) );
=20
   vtpmloginfo(VTPM_LOG_VTPM_DEEP, "Envelope Decrypte Output[%d]: 0x",
buffer_len(unsealed_data));
   for (i=3D0; i< buffer_len(unsealed_data); i++)
@@ -175,26 +200,64 @@ TPM_RESULT envelope_decrypt(const buffer_t   =20
*cipher,
   buffer_free ( &data_cipher);
   buffer_free ( &symkey_clear);
   buffer_free ( &symkey_cipher);
-  Crypto_symcrypto_freekey (&symkey);
+  BSG_Destroy(BSG_TPM_SIZE32_DATA, &symkey_cipher32);
+  BSG_Destroy(BSG_TPM_SIZE32_DATA, &data_cipher32);
+  Crypto_symcrypto_freekey (symkey);
+
 =20
   return status;
 }
=20
+TPM_RESULT symkey_decrypt(const buffer_t     *cipher,
+                            TCS_CONTEXT_HANDLE TCSContext,
+                TPM_HANDLE         keyHandle,
+                const TPM_AUTHDATA *key_usage_auth,
+                            buffer_t           *symkey_clear) {
+
+  TPM_RESULT status =3D TPM_SUCCESS;
+  buffer_t    symkey_cipher =3D NULL_BUF;
+  struct pack_buf_t symkey_cipher32 =3D NULL_PACK_BUF;
+
+  BSG_UnpackList(cipher->bytes, 1,
+         BSG_TPM_SIZE32_DATA, &symkey_cipher32);
+
+  TPMTRYRETURN( buffer_init_alias_convert (&symkey_cipher,
+                           symkey_cipher32.size,
+                           symkey_cipher32.data) );
+
+  // Decrypt Symmetric Key
+  TPMTRYRETURN( VTSP_Unbind(  TCSContext,
+                  keyHandle,
+                  &symkey_cipher,
+                  key_usage_auth,
+                  symkey_clear,
+                  &(vtpm_globals->keyAuth) ) );
+
+  goto egress;
+ abort_egress:
+  vtpmlogerror(VTPM_LOG_VTPM, "Failed to decrypt symmetric key
status=3D%d\n.", status);
+
+ egress:
+  BSG_Destroy(BSG_TPM_SIZE32_DATA, &symkey_cipher32);
+  return status;
+}
+
 TPM_RESULT VTPM_Handle_Save_NVM(VTPM_DMI_RESOURCE *myDMI,
                 const buffer_t *inbuf,
                 buffer_t *outbuf) {
 =20
   TPM_RESULT status =3D TPM_SUCCESS;
-  int fh;
+  int fh =3D -1;
   long bytes_written;
   buffer_t sealed_NVM =3D NULL_BUF;
-=20
-  vtpmloginfo(VTPM_LOG_VTPM_DEEP, "Saving %d bytes of NVM.\n",
buffer_len(inbuf));
+  const buffer_t* nvmbuf =3D inbuf;
=20
-  TPMTRYRETURN( envelope_encrypt(inbuf,
+  vtpmloginfo(VTPM_LOG_VTPM_DEEP, "Saving %d bytes of NVM.\n",
buffer_len(nvmbuf));
+
+  TPMTRYRETURN( envelope_encrypt(nvmbuf,
                                  &vtpm_globals->storageKey,
                                  &sealed_NVM) );
-                =20
+
   // Write sealed blob off disk from NVMLocation
   // TODO: How to properly return from these. Do we care if we return
failure
   //       after writing the file? We can't get the old one back.
@@ -205,7 +268,6 @@ TPM_RESULT VTPM_Handle_Save_NVM(VTPM_DMI_RESOURCE
*myDMI,
     status =3D TPM_IOERROR;
     goto abort_egress;
   }
-  close(fh);
 =20
   Crypto_SHA1Full (sealed_NVM.bytes, buffer_len(&sealed_NVM), (BYTE *)
&myDMI->NVM_measurement); =20
 =20
@@ -215,6 +277,7 @@ TPM_RESULT VTPM_Handle_Save_NVM(VTPM_DMI_RESOURCE
*myDMI,
   vtpmlogerror(VTPM_LOG_VTPM, "Failed to save NVM\n.");
 =20
  egress:
+  close(fh);
   buffer_free(&sealed_NVM);
   return status;
 }
@@ -229,7 +292,8 @@ TPM_RESULT VTPM_Handle_Load_NVM(VTPM_DMI_RESOURCE
*myDMI,
=20
   buffer_t sealed_NVM =3D NULL_BUF;
   long fh_size;
-  int fh, stat_ret, i;
+  int fh =3D -1;
+  int stat_ret, i;
   struct stat file_stat;
   TPM_DIGEST sealedNVMHash;
  =20
@@ -241,6 +305,7 @@ TPM_RESULT VTPM_Handle_Load_NVM(VTPM_DMI_RESOURCE
*myDMI,
 =20
   //Read sealed blob off disk from NVMLocation
   fh =3D open(myDMI->NVMLocation, O_RDONLY);
+  printf("Filename: %s\n", myDMI->NVMLocation);
   stat_ret =3D fstat(fh, &file_stat);
   if (stat_ret =3D=3D 0)
     fh_size =3D file_stat.st_size;
@@ -254,7 +319,6 @@ TPM_RESULT VTPM_Handle_Load_NVM(VTPM_DMI_RESOURCE
*myDMI,
     status =3D TPM_IOERROR;
     goto abort_egress;
   }
-  close(fh);
 =20
   vtpmloginfo(VTPM_LOG_VTPM_DEEP, "Load_NVMing[%d],\n",
buffer_len(&sealed_NVM));
 =20
@@ -289,14 +353,128 @@ TPM_RESULT VTPM_Handle_Load_NVM(VTPM_DMI_RESOURCE
*myDMI,
 =20
  egress:
   buffer_free( &sealed_NVM );
+  close(fh);
+
+  return status;
+}
+
+TPM_RESULT VTPM_Handle_Load_HashKey(VTPM_DMI_RESOURCE *myDMI,
+                const buffer_t    *inbuf,
+                buffer_t          *outbuf) {
+
+  TPM_RESULT status =3D TPM_SUCCESS;
+
+  buffer_t sealed_NVM =3D NULL_BUF;
+  long fh_size;
+  int fh =3D -1;
+  int stat_ret, i;
+  struct stat file_stat;
+  TPM_DIGEST sealedNVMHash;
+
+  if (myDMI->NVMLocation =3D=3D NULL) {
+    vtpmlogerror(VTPM_LOG_VTPM, "Unable to load NVM because the file
name NULL.\n");
+    status =3D TPM_AUTHFAIL;
+    goto abort_egress;
+  }
+
+  //Read sealed blob off disk from NVMLocation
+  fh =3D open(myDMI->NVMLocation, O_RDONLY);
+  printf("Filename: %s\n", myDMI->NVMLocation);
+  stat_ret =3D fstat(fh, &file_stat);
+  if (stat_ret =3D=3D 0)
+    fh_size =3D file_stat.st_size;
+  else {
+    status =3D TPM_IOERROR;
+    goto abort_egress;
+  }
+
+  TPMTRYRETURN( buffer_init( &sealed_NVM, fh_size, NULL) );
+  if (read(fh, sealed_NVM.bytes, buffer_len(&sealed_NVM)) !=3D fh_size) =
{
+    status =3D TPM_IOERROR;
+    goto abort_egress;
+  }
+
+  vtpmloginfo(VTPM_LOG_VTPM_DEEP, "Loading %d byte encryption key,\n",
buffer_len(&sealed_NVM));
+
+  Crypto_SHA1Full(sealed_NVM.bytes, buffer_len(&sealed_NVM), (BYTE *)
&sealedNVMHash);
+
+  // Verify measurement of sealed blob.
+  if (memcmp(&sealedNVMHash, &myDMI->NVM_measurement,
sizeof(TPM_DIGEST)) ) {
+    vtpmlogerror(VTPM_LOG_VTPM, "VTPM LoadKey NVM measurement check
failed.\n");
+    vtpmloginfo(VTPM_LOG_VTPM_DEEP, "Correct hash: ");
+    for (i=3D0; i< sizeof(TPM_DIGEST); i++)
+      vtpmloginfomore(VTPM_LOG_VTPM_DEEP, "%x ",
((BYTE*)&myDMI->NVM_measurement)[i]);
+    vtpmloginfomore(VTPM_LOG_VTPM_DEEP, "\n");
+
+    vtpmloginfo(VTPM_LOG_VTPM_DEEP, "Measured hash: ");
+    for (i=3D0; i< sizeof(TPM_DIGEST); i++)
+      vtpmloginfomore(VTPM_LOG_VTPM_DEEP, "%x ",
((BYTE*)&sealedNVMHash)[i]);
+    vtpmloginfomore(VTPM_LOG_VTPM_DEEP, "\n");
+
+    status =3D TPM_AUTHFAIL;
+    goto abort_egress;
+  }
+
+  //Decrypt the key into the output buffer
+  TPMTRYRETURN( symkey_decrypt(&sealed_NVM,
+                                 myDMI->TCSContext,
+                 vtpm_globals->storageKeyHandle,
+                     (const
TPM_AUTHDATA*)&vtpm_globals->storage_key_usage_auth,
+                                 outbuf) );
+  goto egress;
+
+ abort_egress:
+  vtpmlogerror(VTPM_LOG_VTPM, "Failed to load Key\n.");
+
+ egress:
+  buffer_free( &sealed_NVM );
+  close(fh);
+
+  return status;
+}
+
+TPM_RESULT VTPM_Handle_Save_HashKey(VTPM_DMI_RESOURCE *myDMI,
+                                 const buffer_t    *inbuf,
+                 buffer_t          *outbuf) {
+  TPM_RESULT status =3D TPM_SUCCESS;
+  int fh =3D -1;
+  long bytes_written;
+  buffer_t sealed_key =3D NULL_BUF;
+
+  TPMTRYRETURN( symkey_encrypt(inbuf,
+                                 &vtpm_globals->storageKey,
+                                 &sealed_key) );
+
+  vtpmloginfo(VTPM_LOG_VTPM_DEEP, "Saving %d byte Encryption Key.\n",
buffer_len(inbuf));
+
+  // Write sealed blob off disk from NVMLocation
+  // TODO: How to properly return from these. Do we care if we return
failure
+  //       after writing the file? We can't get the old one back.
+  // TODO: Backup old file and try and recover that way.
+  fh =3D open(myDMI->NVMLocation, O_WRONLY | O_CREAT | O_TRUNC, S_IREAD =
|
S_IWRITE);
+  if ( (bytes_written =3D write(fh, sealed_key.bytes,
buffer_len(&sealed_key) ) !=3D (long) buffer_len(&sealed_key))) {
+    vtpmlogerror(VTPM_LOG_VTPM, "We just overwrote a DMI_NVM and failed
to finish. %ld/%ld bytes.\n", bytes_written, (long)buffer_len(&sealed_key=
));
+    status =3D TPM_IOERROR;
+    goto abort_egress;
+  }
 =20
+  Crypto_SHA1Full (sealed_key.bytes, buffer_len(&sealed_key), (BYTE *)
&myDMI->NVM_measurement);
+
+  goto egress;
+
+ abort_egress:
+  vtpmlogerror(VTPM_LOG_VTPM, "Failed to save Key\n.");
+
+ egress:
+  close(fh);
+  buffer_free(&sealed_key);
   return status;
 }
=20
=20
 TPM_RESULT VTPM_SaveManagerData(void) {
   TPM_RESULT status=3DTPM_SUCCESS;
-  int fh, dmis=3D-1;
+  int fh =3D -1, dmis=3D-1;
=20
   BYTE *flat_boot_key=3DNULL, *flat_dmis=3DNULL, *flat_enc=3DNULL;
   buffer_t clear_flat_global=3DNULL_BUF, enc_flat_global=3DNULL_BUF;
@@ -364,6 +542,7 @@ TPM_RESULT VTPM_SaveManagerData(void) {
                                         BSG_TPM_DIGEST,
&dmi_res->DMI_measurement);
=20
     } while (hashtable_iterator_advance(dmi_itr));
+    free(dmi_itr);
   }
=20
   fh =3D open(STATE_FILE, O_WRONLY | O_CREAT, S_IREAD | S_IWRITE);
@@ -389,6 +568,7 @@ TPM_RESULT VTPM_SaveManagerData(void) {
=20
   free(flat_boot_key);
   free(flat_enc);
+  buffer_free(&clear_flat_global);
   buffer_free(&enc_flat_global);
   free(flat_dmis);
   close(fh);
@@ -403,9 +583,10 @@ TPM_RESULT VTPM_LoadManagerData(void) {
   int fh, stat_ret, dmis=3D0;
   long fh_size =3D 0, step_size;
   BYTE *flat_table=3DNULL;
-  buffer_t  unsealed_data, enc_table_abuf;
-  struct pack_buf_t storage_key_pack, boot_key_pack;
-  UINT32 *dmi_id_key, enc_size;
+  buffer_t  unsealed_data =3D NULL_BUF;
+  buffer_t enc_table_abuf;
+  struct pack_buf_t storage_key_pack =3D NULL_PACK_BUF, boot_key_pack =3D=

NULL_PACK_BUF;
+  UINT32 enc_size;
   BYTE vtpm_manager_gen;
=20
   VTPM_DMI_RESOURCE *dmi_res;
@@ -438,9 +619,9 @@ TPM_RESULT VTPM_LoadManagerData(void) {
                               BSG_TPM_SIZE32_DATA, &boot_key_pack,
                               BSG_TYPE_UINT32, &enc_size);
=20
-  TPMTRYRETURN(buffer_init(&vtpm_globals->bootKeyWrap, 0, 0) );
   TPMTRYRETURN(buffer_init_alias_convert(&enc_table_abuf, enc_size,
flat_table + step_size) );
-  TPMTRYRETURN(buffer_append_raw(&vtpm_globals->bootKeyWrap,
boot_key_pack.size, boot_key_pack.data) );
+  TPMTRYRETURN(buffer_init(&vtpm_globals->bootKeyWrap,
boot_key_pack.size, boot_key_pack.data) );
+
=20
   //Load Boot Key
   TPMTRYRETURN( VTSP_LoadKey( vtpm_globals->manager_tcs_handle,
@@ -471,8 +652,8 @@ TPM_RESULT VTPM_LoadManagerData(void) {
                   BSG_TPM_SECRET,   &vtpm_globals->storage_key_usage_aut=
h,
                   BSG_TPM_SIZE32_DATA, &storage_key_pack);
=20
-  TPMTRYRETURN(buffer_init(&vtpm_globals->storageKeyWrap, 0, 0) );
-  TPMTRYRETURN(buffer_append_raw(&vtpm_globals->storageKeyWrap,
storage_key_pack.size, storage_key_pack.data) );
+  TPMTRYRETURN(buffer_init(&vtpm_globals->storageKeyWrap,
storage_key_pack.size, storage_key_pack.data) );
+
=20
   // Per DMI values to be saved
   while ( step_size < fh_size ){
@@ -501,7 +682,10 @@ TPM_RESULT VTPM_LoadManagerData(void) {
  abort_egress:
   vtpmlogerror(VTPM_LOG_VTPM, "Failed to load service data with error =3D=

%s\n", tpm_get_error_name(status));
  egress:
+  BSG_Destroy(BSG_TPM_SIZE32_DATA, &boot_key_pack);
+  BSG_Destroy(BSG_TPM_SIZE32_DATA, &storage_key_pack);
=20
+  buffer_free(&unsealed_data);
   free(flat_table);
   close(fh);
=20
diff --git a/tools/vtpm_manager/manager/vtpm_ipc.c
b/tools/vtpm_manager/manager/vtpm_ipc.c
--- a/tools/vtpm_manager/manager/vtpm_ipc.c
+++ b/tools/vtpm_manager/manager/vtpm_ipc.c
@@ -36,26 +36,49 @@
 //
 // =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
=20
+#include <sys/types.h>
 #include <sys/stat.h>
+#include <fcntl.h>
+#include <unistd.h>
+#include <sys/select.h>
 #include "vtpm_ipc.h"
 #include "vtpmpriv.h"
 #include "log.h"
=20
-int vtpm_ipc_init(vtpm_ipc_handle_t *ipc_h, char* name, int flags, BOOL
create) {
+volatile sig_atomic_t IPC_QUIT_FLAG =3D 0;
+
+const static struct timeval TIMEOUT =3D {
+   .tv_sec =3D 1,
+   .tv_usec =3D 0
+};
+
+int vtpm_ipc_init(vtpm_ipc_handle_t *ipc_h, char* name, int flags, BOOL
create, BOOL preopen) {
+  int rc;
+
   ipc_h->name =3D name;
   ipc_h->flags =3D flags;
   ipc_h->fh =3D VTPM_IPC_CLOSED;
=20
-  if (create)
-    return(vtpm_ipc_create(ipc_h));
-  else
-    return 0;
+  if (create) {
+    if((rc =3D vtpm_ipc_create(ipc_h) !=3D 0)) {
+       return rc;
+    }
+  }
+
+  if(preopen) {
+    ipc_h->fh =3D open(ipc_h->name, ipc_h->flags);
+    if ( ipc_h->fh =3D=3D VTPM_IPC_CLOSED ) {
+       vtpmlogerror(VTPM_LOG_VTPM, "VTPM ERROR: Can't open %s\n",
ipc_h->name);
+       return -1;
+    }
+  }
+  return 0;
+
 }
=20
 // Create the file that needs opening. Used only for FIFOs
 // FYI: This may cause problems in other file IO schemes. We'll see.
 int vtpm_ipc_create(vtpm_ipc_handle_t *ipc_h) {
-  int fh;
   struct stat file_info;
=20
   if ((!ipc_h) || (!ipc_h->name))
@@ -68,8 +91,6 @@ int vtpm_ipc_create(vtpm_ipc_handle_t *ipc_h) {
     }
   }
=20
-  ipc_h->fh =3D VTPM_IPC_CLOSED;
-
   return 0;
 }
=20
@@ -78,6 +99,8 @@ int vtpm_ipc_create(vtpm_ipc_handle_t *ipc_h) {
 int vtpm_ipc_read(vtpm_ipc_handle_t *ipc_h, vtpm_ipc_handle_t
*alt_ipc_h, BYTE *bytes, UINT32 size){
   vtpm_ipc_handle_t *my_ipc_h;
   int result;
+  fd_set fds;
+  struct timeval timeout;
 =20
   if (ipc_h) {
     my_ipc_h =3D ipc_h;
@@ -94,9 +117,19 @@ int vtpm_ipc_read(vtpm_ipc_handle_t *ipc_h,
vtpm_ipc_handle_t *alt_ipc_h, BYTE *
     return -1;
   }
=20
+  FD_ZERO(&fds);
+  while(!FD_ISSET( my_ipc_h->fh, &fds )) {
+     timeout =3D TIMEOUT;
+     if (IPC_QUIT_FLAG) {
+    return -1;
+     }
+     FD_SET(my_ipc_h->fh, &fds);
+     select(my_ipc_h->fh + 1, &fds, NULL, NULL, &timeout);
+  }
+
   result =3D read(my_ipc_h->fh, bytes, size);
   if (result < 0) {
-    my_ipc_h->fh =3D VTPM_IPC_CLOSED;
+     my_ipc_h->fh =3D VTPM_IPC_CLOSED;
   }
=20
   return (result);
@@ -106,6 +139,8 @@ int vtpm_ipc_read(vtpm_ipc_handle_t *ipc_h,
vtpm_ipc_handle_t *alt_ipc_h, BYTE *
 int vtpm_ipc_write(vtpm_ipc_handle_t *ipc_h, vtpm_ipc_handle_t
*alt_ipc_h, BYTE *bytes, UINT32 size) {
   vtpm_ipc_handle_t *my_ipc_h;
   int result;
+  fd_set fds;
+  struct timeval timeout;
=20
   if (ipc_h) {
     my_ipc_h =3D ipc_h;
@@ -122,6 +157,16 @@ int vtpm_ipc_write(vtpm_ipc_handle_t *ipc_h,
vtpm_ipc_handle_t *alt_ipc_h, BYTE
     return -1;
   }
=20
+  FD_ZERO(&fds);
+  while(!FD_ISSET( my_ipc_h->fh, &fds )) {
+     timeout =3D TIMEOUT;
+     if (IPC_QUIT_FLAG) {
+    return -1;
+     }
+     FD_SET(my_ipc_h->fh, &fds);
+     select(my_ipc_h->fh + 1, NULL, &fds, NULL, &timeout);
+  }
+
   result =3D write(my_ipc_h->fh, bytes, size);
   if (result < 0) {
     my_ipc_h->fh =3D VTPM_IPC_CLOSED;
diff --git a/tools/vtpm_manager/manager/vtpm_ipc.h
b/tools/vtpm_manager/manager/vtpm_ipc.h
--- a/tools/vtpm_manager/manager/vtpm_ipc.h
+++ b/tools/vtpm_manager/manager/vtpm_ipc.h
@@ -39,10 +39,14 @@
 #ifndef __VTPM_IO_H__
 #define __VTPM_IO_H__
=20
+#include <signal.h>
+
 #include "tcg.h"
=20
 #define VTPM_IPC_CLOSED -1
=20
+extern volatile sig_atomic_t IPC_QUIT_FLAG;
+
 // Represents an (somewhat) abstracted io handle.
 typedef struct vtpm_ipc_handle_t {
   int fh;              // IO handle.
@@ -53,7 +57,7 @@ typedef struct vtpm_ipc_handle_t {
 } vtpm_ipc_handle_t;
=20
=20
-int vtpm_ipc_init(vtpm_ipc_handle_t *ioh, char* name, int flags, BOOL
create);
+int vtpm_ipc_init(vtpm_ipc_handle_t *ioh, char* name, int flags, BOOL
create, BOOL preopen);
=20
 // Create the file that needs opening. Used only for FIFOs
 // FYI: This may cause problems in other file IO schemes. We'll see.
diff --git a/tools/vtpm_manager/manager/vtpm_lock.c
b/tools/vtpm_manager/manager/vtpm_lock.c
--- a/tools/vtpm_manager/manager/vtpm_lock.c
+++ b/tools/vtpm_manager/manager/vtpm_lock.c
@@ -40,24 +40,24 @@
=20
 static pthread_rwlock_t vtpm_lock;
=20
-void vtpm_lock_init() {
+void vtpm_lock_init(void) {
=20
   pthread_rwlock_init( &vtpm_lock, NULL);
 }
=20
-void vtpm_lock_destroy(){
+void vtpm_lock_destroy(void){
   pthread_rwlock_destroy(&vtpm_lock);
 }
=20
-void vtpm_lock_rdlock(){
+void vtpm_lock_rdlock(void){
   pthread_rwlock_rdlock(&vtpm_lock);
 }
=20
-void vtpm_lock_wrlock(){
+void vtpm_lock_wrlock(void){
   pthread_rwlock_wrlock(&vtpm_lock);
 }
=20
-void vtpm_lock_unlock(){
+void vtpm_lock_unlock(void){
   pthread_rwlock_unlock(&vtpm_lock);
 }
=20
diff --git a/tools/vtpm_manager/manager/vtpm_lock.h
b/tools/vtpm_manager/manager/vtpm_lock.h
--- a/tools/vtpm_manager/manager/vtpm_lock.h
+++ b/tools/vtpm_manager/manager/vtpm_lock.h
@@ -38,11 +38,11 @@
 #ifndef __VTPM_LOCK_H__
 #define __VTPM_LOCK_H__
=20
-void vtpm_lock_init();
-void vtpm_lock_destroy();
+void vtpm_lock_init(void);
+void vtpm_lock_destroy(void);
=20
-void vtpm_lock_rdlock();
-void vtpm_lock_wrlock();
-void vtpm_lock_unlock();
+void vtpm_lock_rdlock(void);
+void vtpm_lock_wrlock(void);
+void vtpm_lock_unlock(void);
=20
 #endif
diff --git a/tools/vtpm_manager/manager/vtpm_manager.c
b/tools/vtpm_manager/manager/vtpm_manager.c
--- a/tools/vtpm_manager/manager/vtpm_manager.c
+++ b/tools/vtpm_manager/manager/vtpm_manager.c
@@ -40,10 +40,12 @@
 #include <stdio.h>
 #include <unistd.h>
 #include <string.h>
+#include <stdlib.h>
=20
 #include "vtpm_manager.h"
 #include "vtpmpriv.h"
 #include "vtsp.h"
+#include "tpmddl.h"
 #include "bsg.h"
 #include "hashtable.h"
 #include "hashtable_itr.h"
@@ -54,8 +56,8 @@
 VTPM_GLOBALS *vtpm_globals=3DNULL;
=20
 // --------------------------- Well Known Auths ------------------------=
--
-const TPM_AUTHDATA SRK_AUTH =3D {0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
0xff, 0xff, 0xff, 0xff,
-                                  0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
0xff, 0xff, 0xff, 0xff};
+const TPM_AUTHDATA SRK_AUTH =3D {0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00,
+                                  0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00};
=20
 #ifdef WELL_KNOWN_OWNER_AUTH
 static BYTE FIXED_OWNER_AUTH[20] =3D  {0xff, 0xff, 0xff, 0xff, 0xff,
0xff, 0xff, 0xff, 0xff, 0xff,
@@ -74,7 +76,6 @@ static int equals32(void *k1, void *k2) {
 }
=20
 // --------------------------- Functions ------------------------------
-
 TPM_RESULT VTPM_Create_Manager(){
 =20
   TPM_RESULT status =3D TPM_SUCCESS;
@@ -104,6 +105,7 @@ TPM_RESULT VTPM_Create_Manager(){
     TPMTRYRETURN(VTSP_DisablePubekRead(vtpm_globals->manager_tcs_handle,=

                                        (const
TPM_AUTHDATA*)&vtpm_globals->owner_usage_auth,=20
                                        &vtpm_globals->keyAuth));   =20
+    Crypto_RSACryptoInfoFree(&ek_cryptoInfo);
   } else {
     vtpmloginfo(VTPM_LOG_VTPM, "Failed to readEK meaning TPM has an
owner. Creating Keys off existing SRK.\n");
   }
@@ -181,7 +183,7 @@ TPM_RESULT VTPM_Create_Manager(){
 }
=20
 ////////////////////////////////////////////////////////////////////////=
///////
-TPM_RESULT VTPM_Init_Manager() {
+TPM_RESULT VTPM_Init_Manager(void) {
   TPM_RESULT status =3D TPM_FAIL, serviceStatus; =20
   BYTE *randomsead;
   UINT32 randomsize=3D256;
@@ -203,6 +205,11 @@ TPM_RESULT VTPM_Init_Manager() {
   vtpm_globals->manager_tcs_handle =3D 0;
=20
   TPMTRYRETURN(TCS_create());
+
+  // Blow away all stale handles left in the tpm
+  if(TDDL_FlushAllResources() !=3D TPM_SUCCESS) {
+     vtpmlogerror(VTPM_LOG_VTPM, "VTPM_FlushResources failed,
continuing anyway..\n");
+  }
 =20
   // Create TCS Context for service
   TPMTRYRETURN( TCS_OpenContext(&vtpm_globals->manager_tcs_handle ) );
@@ -228,7 +235,7 @@ TPM_RESULT VTPM_Init_Manager() {
     TPMTRYRETURN( VTPM_Create_Manager() );  =20
     TPMTRYRETURN( VTPM_SaveManagerData() );
   } else if (serviceStatus !=3D TPM_SUCCESS) {
-    vtpmlogerror(VTPM_LOG_VTPM, "Failed to read existing manager file");=

+    vtpmlogerror(VTPM_LOG_VTPM, "Failed to read existing manager file\n"=
);
     exit(1);
   }
=20
@@ -254,7 +261,7 @@ TPM_RESULT VTPM_Init_Manager() {
 }
=20
 ////////////////////////////////////////////////////////////////////////=
///////

-void VTPM_Stop_Manager() {
+void VTPM_Stop_Manager(void) {
   VTPM_DMI_RESOURCE *dmi_res;
   struct hashtable_itr *dmi_itr;
 =20
@@ -267,7 +274,7 @@ void VTPM_Stop_Manager() {
     close_dmi( dmi_res ); // Not really interested in return code
     =20
     } while (hashtable_iterator_advance(dmi_itr));
-        free (dmi_itr);
+    free (dmi_itr);
   }
 =20
   if ( VTPM_SaveManagerData() !=3D TPM_SUCCESS )
@@ -276,7 +283,21 @@ void VTPM_Stop_Manager() {
   TCS_CloseContext(vtpm_globals->manager_tcs_handle);
   TCS_destroy();
 =20
-  hashtable_destroy(vtpm_globals->dmi_map, 1);
+  if (hashtable_count(vtpm_globals->dmi_map) > 0) {
+    dmi_itr =3D hashtable_iterator(vtpm_globals->dmi_map);
+    do {
+      dmi_res =3D (VTPM_DMI_RESOURCE *) hashtable_iterator_value(dmi_itr=
);
+      free_dmi(dmi_res);
+    } while (hashtable_iterator_advance(dmi_itr));
+    free (dmi_itr);
+  }
+  hashtable_destroy(vtpm_globals->dmi_map, 0);
+
+  /* Cleanup resources */
+  Crypto_RSACryptoInfoFree(&vtpm_globals->bootKey);
+  Crypto_RSACryptoInfoFree(&vtpm_globals->storageKey);
+  buffer_free(&vtpm_globals->bootKeyWrap);
+  buffer_free(&vtpm_globals->storageKeyWrap);
   free(vtpm_globals);
 =20
   Crypto_Exit();
diff --git a/tools/vtpm_manager/manager/vtpm_manager.h
b/tools/vtpm_manager/manager/vtpm_manager.h
--- a/tools/vtpm_manager/manager/vtpm_manager.h
+++ b/tools/vtpm_manager/manager/vtpm_manager.h
@@ -61,6 +61,8 @@
 #define VTPM_ORD_TPMCOMMAND   (VTPM_ORD_BASE + 3) // DMI issues HW TPM
Command
 #define VTPM_ORD_GET_MIG_KEY  (VTPM_ORD_BASE + 4) // Get manager's
migration key
 #define VTPM_ORD_LOAD_MIG_KEY (VTPM_ORD_BASE + 5) // load dest
migration key
+#define VTPM_ORD_SAVEHASHKEY      (VTPM_ORD_BASE + 7) // DMI requests
encryption key for persistent storage
+#define VTPM_ORD_LOADHASHKEY      (VTPM_ORD_BASE + 8) // DMI requests
symkey to be regenerated
=20
 // Priviledged VTPM Commands (From management console)
 #define VTPM_ORD_OPEN         (VTPM_PRIV_BASE + 1) // Creates/reopens DM=
I
@@ -147,4 +149,23 @@ VTPM_TPMCommand
=20
 *********************************************************************/
=20
+#ifndef VTPM_STUBDOM
+#define TPM_EMULATOR_PATH "/usr/bin/vtpmd"
+#endif
+
+#define VTPM_BE_FNAME          "/dev/vtpm"
+#define VTPM_DUMMY_TX_BE_FNAME "/var/vtpm/fifos/dummy_out.fifo"
+#define VTPM_DUMMY_RX_BE_FNAME "/var/vtpm/fifos/dummy_in.fifo"
+#ifndef VTPM_STUBDOM
+#define VTPM_TX_TPM_FNAME      "/var/vtpm/fifos/tpm_cmd_to_%d.fifo"
+#define VTPM_RX_TPM_FNAME      "/var/vtpm/fifos/tpm_rsp_from_all.fifo"
+#define VTPM_TX_VTPM_FNAME     "/var/vtpm/fifos/vtpm_rsp_to_%d.fifo"
+#define VTPM_RX_VTPM_FNAME     "/var/vtpm/fifos/vtpm_cmd_from_all.fifo"
+#endif
+#define VTPM_TX_HP_FNAME       "/var/vtpm/fifos/to_console.fifo"
+#define VTPM_RX_HP_FNAME       "/var/vtpm/fifos/from_console.fifo"
+
+#define VTPM_TYPE_PVM_STRING "pvm"
+#define VTPM_TYPE_HVM_STRING "hvm"
+
 #endif //_VTPM_MANAGER_H_
diff --git a/tools/vtpm_manager/manager/vtpm_manager_handler.c
b/tools/vtpm_manager/manager/vtpm_manager_handler.c
--- a/tools/vtpm_manager/manager/vtpm_manager_handler.c
+++ b/tools/vtpm_manager/manager/vtpm_manager_handler.c
@@ -41,6 +41,8 @@
 #include <unistd.h>
 #include <string.h>
 #include <errno.h>
+#include <signal.h>
+#include <stdlib.h>
=20
 #include "vtpm_manager.h"
 #include "vtpmpriv.h"
@@ -50,26 +52,13 @@
 #include "hashtable_itr.h"
 #include "log.h"
 #include "buffer.h"
+#include "vtpm_manager_handler.h"
=20
 #define vtpmhandlerloginfo(module,fmt,args...) vtpmloginfo (module,
"[%s]: " fmt, thread_name, ##args );
 #define vtpmhandlerloginfomore(module,fmt,args...) vtpmloginfomore
(module, fmt, ##args );
 #define vtpmhandlerlogerror(module,fmt,args...) vtpmlogerror (module,
"[%s]: " fmt, thread_name, ##args );
=20
-// ---------------------- Prototypes -------------------
-TPM_RESULT vtpm_manager_handle_vtpm_cmd(VTPM_DMI_RESOURCE *dmi_res,
-                    TPM_COMMAND_CODE ord,
-                    buffer_t *command_buf,
-                    buffer_t *result_buf,
-                                        BOOL is_priv,
-                                        char *thread_name);
-
-TPM_RESULT vtpm_manager_handle_tpm_cmd(vtpm_ipc_handle_t *tx_ipc_h,
-                                       vtpm_ipc_handle_t *rx_ipc_h,
-                                       VTPM_DMI_RESOURCE *dmi_res,
-                                       BYTE *cmd_header,
-                                       buffer_t *param_buf,
-                                       buffer_t *result_buf,
-                                       char *thread_name);
+volatile sig_atomic_t HANDLER_QUIT_FLAG =3D 0;
=20
 TPM_RESULT VTPM_Manager_Handler( vtpm_ipc_handle_t *tx_ipc_h,
                                  vtpm_ipc_handle_t *rx_ipc_h,
@@ -80,12 +69,13 @@ TPM_RESULT VTPM_Manager_Handler( vtpm_ipc_handle_t
*tx_ipc_h,
                                  char *thread_name) {
   TPM_RESULT      status =3D  TPM_FAIL; // Should never return
   UINT32          dmi, in_param_size, cmd_size, out_param_size,
out_message_size, reply_size;
-  BYTE            *cmd_header=3DNULL, *in_param=3DNULL, *out_message=3DN=
ULL,
*reply;
+  BYTE            *cmd_header=3DNULL, *in_param=3DNULL, *out_header=3DNU=
LL,
*reply;
   buffer_t        *command_buf=3DNULL, *result_buf=3DNULL;
   TPM_TAG         tag;
   TPM_COMMAND_CODE ord;
   VTPM_DMI_RESOURCE *dmi_res;
   int  size_read, size_write, i;
+  int locked;
   BOOL add_header=3DTRUE; // This indicates to prepend a header on
result_buf before sending
 =20
   cmd_header =3D (BYTE *) malloc(VTPM_COMMAND_HEADER_SIZE_SRV);
@@ -93,7 +83,11 @@ TPM_RESULT VTPM_Manager_Handler( vtpm_ipc_handle_t
*tx_ipc_h,
   result_buf =3D (buffer_t *) malloc(sizeof(buffer_t));
=20
   // ------------------------ Main Loop --------------------------------=

-  while(1) {
+  while(!HANDLER_QUIT_FLAG) {
+    locked =3D 0;
+
+    buffer_init(command_buf, 0, NULL);
+    buffer_init(result_buf, 0, NULL);
   =20
     vtpmhandlerloginfo(VTPM_LOG_VTPM, "%s waiting for messages.\n",
thread_name);
=20
@@ -106,7 +100,9 @@ TPM_RESULT VTPM_Manager_Handler( vtpm_ipc_handle_t
*tx_ipc_h,
       for (i=3D0; i<size_read; i++)
     vtpmhandlerloginfomore(VTPM_LOG_VTPM_DEEP, "%x ", cmd_header[i]);
     } else {
-      vtpmhandlerlogerror(VTPM_LOG_VTPM, "%s can't read from ipc.
Errono =3D %d. Aborting... \n", thread_name, errno);
+      if (!IPC_QUIT_FLAG) {
+    vtpmhandlerlogerror(VTPM_LOG_VTPM, "%s can't read from ipc. Errono
=3D %d. Aborting... \n", thread_name, errno);
+      }
       goto abort_command;
     }
=20
@@ -155,6 +151,7 @@ TPM_RESULT VTPM_Manager_Handler( vtpm_ipc_handle_t
*tx_ipc_h,
       vtpmhandlerlogerror(VTPM_LOG_VTPM, "Failed to setup buffers.
Aborting...\n");
       goto abort_command;
     }
+    result_buf->is_owner =3D TRUE;
   =20
     // -------------- Dispatch Commands to Handlers -----------
     if ((tag =3D=3D VTPM_TAG_REQ) && (ord & VTPM_PRIV_MASK)) {
@@ -162,6 +159,7 @@ TPM_RESULT VTPM_Manager_Handler( vtpm_ipc_handle_t
*tx_ipc_h,
     } else {
       vtpm_lock_rdlock();
     }
+    locked =3D 1;
=20
     if ( !(dmi_res =3D (VTPM_DMI_RESOURCE *)
hashtable_search(vtpm_globals->dmi_map, &dmi)) ||
          (!dmi_res->connected) ) {
@@ -174,10 +172,22 @@ TPM_RESULT VTPM_Manager_Handler( vtpm_ipc_handle_t
*tx_ipc_h,
     if (tag =3D=3D VTPM_TAG_REQ) {
   =20
       status =3D vtpm_manager_handle_vtpm_cmd(dmi_res, ord, command_buf,=

result_buf, is_priv, thread_name);
+      result_buf->is_owner =3D TRUE;
=20
     } else { // This is not a VTPM Command at all.
       if (fw_tpm) {
+#ifdef VTPM_STUBDOM
+    /* In stubdom mode, we allow the vtpm domains to send raw tpm
commands down the pipe
+     * They can also just embed their tpm commands inside VTPM commands
if they wish to*/
+
+    /* Stick the header back onto the raw command (minus the dmiid) */
+    buffer_prepend_raw(command_buf, VTPM_COMMAND_HEADER_SIZE_CLT,
cmd_header + sizeof(UINT32));
+    status =3D VTPM_Handle_TPM_Command(dmi_res, command_buf, result_buf)=
;
+#else
+    /* In normal mode, this is used for the guest to forward a raw
command to the vtpm process */
         status =3D vtpm_manager_handle_tpm_cmd(fw_tx_ipc_h, fw_rx_ipc_h,=

dmi_res, cmd_header, command_buf, result_buf, thread_name);
+#endif
+        result_buf->is_owner =3D TRUE;
=20
         // This means calling the DMI failed, not that the cmd failed
in the DMI
         // Since the return will be interpretted by a TPM app, all
errors are IO_ERRORs to the app
@@ -207,36 +217,42 @@ TPM_RESULT VTPM_Manager_Handler( vtpm_ipc_handle_t
*tx_ipc_h,
     // ------------------- Respond to Sender ------------------
=20
     // Errors while handling responses jump here to reply with error
messages
-    // NOTE: Currently there are no recoverable errors in multi-VM
mode. If one
-    //       is added to the code, this ifdef should be removed.
-    //       Also note this is NOT referring to errors in commands, but
rather
-    //       this is about I/O errors and such.
-#ifndef VTPM_MULTI_VM
- abort_with_error:
-#endif
+abort_with_error:
  =20
     if (add_header) {
       // Prepend VTPM header with destination DM stamped
       out_param_size =3D buffer_len(result_buf);
       out_message_size =3D VTPM_COMMAND_HEADER_SIZE_CLT + out_param_size=
;
-      reply_size =3D VTPM_COMMAND_HEADER_SIZE_SRV + out_param_size;
-      out_message =3D (BYTE *) malloc (reply_size);
-      reply =3D out_message;
+      out_header =3D (BYTE *) malloc (VTPM_COMMAND_HEADER_SIZE_SRV);
   =20
-      BSG_PackList(out_message, 4,
+      BSG_PackList(out_header, 4,
            BSG_TYPE_UINT32, (BYTE *) &dmi,
            BSG_TPM_TAG, (BYTE *) &tag,
            BSG_TYPE_UINT32, (BYTE *) &out_message_size,
            BSG_TPM_RESULT, (BYTE *) &status);
   =20
-      if (buffer_len(result_buf) > 0)
-        memcpy(out_message + VTPM_COMMAND_HEADER_SIZE_SRV,
result_buf->bytes, out_param_size);
-      //Note: Send message + dmi_id
+      buffer_prepend_raw(result_buf, VTPM_COMMAND_HEADER_SIZE_SRV,
out_header);
+      free(out_header);
     } else {
-      reply =3D result_buf->bytes;
-      reply_size =3D buffer_len(result_buf);
+#ifdef VTPM_STUBDOM
+       //In stubdom mode, we need to always prepend the dmiid so the
raw command can be returned to the right domain
+       out_header =3D (BYTE*) malloc(sizeof(UINT32));
+       BSG_PackList(out_header, 1,
+         BSG_TYPE_UINT32, (BYTE*) &dmi);
+       buffer_prepend_raw(result_buf, sizeof(UINT32), out_header);
+       free(out_header);
+#endif
     }=20
+    reply =3D result_buf->bytes;
+    reply_size =3D buffer_len(result_buf);
+#ifndef VTPM_STUBDOM
     size_write =3D vtpm_ipc_write(tx_ipc_h, (dmi_res ?
dmi_res->tx_vtpm_ipc_h : NULL), reply, reply_size );
+#else
+    if(reply_size >=3D 4096) {
+       vtpmhandlerlogerror(VTPM_LOG_VTPM, "MESSAGE TOO BIG!!!");
+    }
+    size_write =3D vtpm_ipc_write(tx_ipc_h, NULL, reply, reply_size );
+#endif
     if (size_write > 0) {
       vtpmhandlerloginfo(VTPM_LOG_VTPM_DEEP, "SENT: 0x");
       for (i=3D0; i < reply_size; i++)
@@ -247,7 +263,6 @@ TPM_RESULT VTPM_Manager_Handler( vtpm_ipc_handle_t
*tx_ipc_h,
       vtpmhandlerlogerror(VTPM_LOG_VTPM, "%s had error writing to ipc.
Aborting... \n", thread_name);
       goto abort_command;
     }
-    free(out_message); out_message=3DNULL;
   =20
     if (size_write < (int)reply_size) {
       vtpmhandlerlogerror(VTPM_LOG_VTPM, "%s unable to write full
command to ipc (%d/%d)\n", thread_name, size_write, reply_size);
@@ -264,14 +279,22 @@ TPM_RESULT VTPM_Manager_Handler( vtpm_ipc_handle_t
*tx_ipc_h,
     buffer_free(command_buf);
=20
     // If we have a write lock, save the manager table
-    if ((tag =3D=3D VTPM_TAG_REQ) && (ord & VTPM_PRIV_MASK) &&
+    if (locked && (tag =3D=3D VTPM_TAG_REQ) && (ord & VTPM_PRIV_MASK) &&=

         (VTPM_SaveManagerData() !=3D TPM_SUCCESS) ) {
        vtpmhandlerlogerror(VTPM_LOG_VTPM, "ERROR: Unable to save
manager data.\n");
     }
=20
-    vtpm_lock_unlock();
+    if(locked) {
+       vtpm_lock_unlock();
+    }
     add_header =3D TRUE; // Reset to the default
   } // End while(1)
+
+  free(cmd_header);
+  free(command_buf);
+  free(result_buf);
+
+  vtpmhandlerloginfo(VTPM_LOG_VTPM, "exiting\n", thread_name);
 =20
 }
=20
@@ -313,6 +336,16 @@ TPM_RESULT
vtpm_manager_handle_vtpm_cmd(VTPM_DMI_RESOURCE *dmi_res,
     status =3D VTPM_Handle_Load_Migration_key(command_buf,
                                            result_buf);
     break;
+  case VTPM_ORD_SAVEHASHKEY:
+    status =3D VTPM_Handle_Save_HashKey(dmi_res,
+                   command_buf,
+                   result_buf);
+    break;
+  case VTPM_ORD_LOADHASHKEY:
+    status =3D VTPM_Handle_Load_HashKey(dmi_res,
+                   command_buf,
+                   result_buf);
+    break;
  =20
   default:
     // Privileged handlers can do maintanance
@@ -350,6 +383,7 @@ TPM_RESULT
vtpm_manager_handle_vtpm_cmd(VTPM_DMI_RESOURCE *dmi_res,
   return(status);
 }
     =20
+#ifndef VTPM_STUBDOM
 /////////////////////////////////////////////////////////////////////
 TPM_RESULT vtpm_manager_handle_tpm_cmd(vtpm_ipc_handle_t *tx_ipc_h,
                                        vtpm_ipc_handle_t *rx_ipc_h,
@@ -485,4 +519,5 @@ TPM_RESULT
vtpm_manager_handle_tpm_cmd(vtpm_ipc_handle_t *tx_ipc_h,
=20
   return status;
 }
+#endif
=20
diff --git a/tools/vtpm_manager/manager/vtpm_manager_handler.h
b/tools/vtpm_manager/manager/vtpm_manager_handler.h
--- /dev/null
+++ b/tools/vtpm_manager/manager/vtpm_manager_handler.h
@@ -0,0 +1,21 @@
+#ifndef VTPM_MANAGER_HANDLER_H
+#define VTPM_MANAGER_HANDLER_H
+// ---------------------- Prototypes -------------------
+TPM_RESULT vtpm_manager_handle_vtpm_cmd(VTPM_DMI_RESOURCE *dmi_res,
+                    TPM_COMMAND_CODE ord,
+                    buffer_t *command_buf,
+                    buffer_t *result_buf,
+                                        BOOL is_priv,
+                                        char *thread_name);
+
+#ifndef VTPM_STUBDOM
+TPM_RESULT vtpm_manager_handle_tpm_cmd(vtpm_ipc_handle_t *tx_ipc_h,
+                                       vtpm_ipc_handle_t *rx_ipc_h,
+                                       VTPM_DMI_RESOURCE *dmi_res,
+                                       BYTE *cmd_header,
+                                       buffer_t *param_buf,
+                                       buffer_t *result_buf,
+                                       char *thread_name);
+#endif
+
+#endif
diff --git a/tools/vtpm_manager/manager/vtpmd.c
b/tools/vtpm_manager/manager/vtpmd.c
--- a/tools/vtpm_manager/manager/vtpmd.c
+++ b/tools/vtpm_manager/manager/vtpmd.c
@@ -45,27 +45,13 @@
 #include <signal.h>
 #include <string.h>
 #include <pthread.h>
+#include <stdlib.h>
 #include "vtpm_manager.h"
 #include "vtpmpriv.h"
 #include "tcg.h"
 #include "log.h"
 #include "vtpm_ipc.h"
=20
-#define TPM_EMULATOR_PATH "/usr/bin/vtpmd"
-
-#define VTPM_BE_FNAME          "/dev/vtpm"
-#define VTPM_DUMMY_TX_BE_FNAME "/var/vtpm/fifos/dummy_out.fifo"
-#define VTPM_DUMMY_RX_BE_FNAME "/var/vtpm/fifos/dummy_in.fifo"
-#define VTPM_TX_TPM_FNAME      "/var/vtpm/fifos/tpm_cmd_to_%d.fifo"
-#define VTPM_RX_TPM_FNAME      "/var/vtpm/fifos/tpm_rsp_from_all.fifo"
-#define VTPM_TX_VTPM_FNAME     "/var/vtpm/fifos/vtpm_rsp_to_%d.fifo"
-#define VTPM_RX_VTPM_FNAME     "/var/vtpm/fifos/vtpm_cmd_from_all.fifo"
-#define VTPM_TX_HP_FNAME       "/var/vtpm/fifos/to_console.fifo"
-#define VTPM_RX_HP_FNAME       "/var/vtpm/fifos/from_console.fifo"
-
-#define VTPM_TYPE_PVM_STRING "pvm"
-#define VTPM_TYPE_HVM_STRING "hvm"
-
 struct vtpm_thread_params_s {
   vtpm_ipc_handle_t *tx_ipc_h;
   vtpm_ipc_handle_t *rx_ipc_h;
@@ -76,180 +62,46 @@ struct vtpm_thread_params_s {
   char *thread_name;
 };
=20
+static pthread_t           master_thread;
+static pthread_t           be_thread;
+static pthread_t           hp_thread;
+#ifndef VTPM_STUBDOM
+static pthread_t           dmi_thread;
+#endif
+
+
+#ifndef VTPM_STUBDOM
 // This is needed to all extra_close_dmi to close this to prevent a
 // broken pipe when no DMIs are left.
-static vtpm_ipc_handle_t *g_rx_tpm_ipc_h;
+extern vtpm_ipc_handle_t *g_rx_tpm_ipc_h;
+#endif
=20
 void *vtpm_manager_thread(void *arg_void) {
-  TPM_RESULT *status =3D (TPM_RESULT *) malloc(sizeof(TPM_RESULT) );
   struct vtpm_thread_params_s *arg =3D (struct vtpm_thread_params_s *)
arg_void;
=20
-  *status =3D VTPM_Manager_Handler(arg->tx_ipc_h, arg->rx_ipc_h,
+  VTPM_Manager_Handler(arg->tx_ipc_h, arg->rx_ipc_h,
                                  arg->fw_tpm, arg->fw_tx_ipc_h,
arg->fw_rx_ipc_h,
                                  arg->is_priv, arg->thread_name);
=20
-  return (status);
+  return NULL;
 }
=20
-
-void signal_handler(int reason) {
-  if (pthread_equal(pthread_self(), vtpm_globals->master_pid)) {
-    vtpmloginfo(VTPM_LOG_VTPM, "VTPM Manager shutting down for signal
%d.\n", reason);
-  } else {
-    // For old Linux Thread machines, signals are delivered to each
thread. Deal with them.
-    vtpmloginfo(VTPM_LOG_VTPM, "Child shutting down\n");
-    pthread_exit(NULL);
+void signal_handler(int signal) {
+  if (pthread_equal(pthread_self(), master_thread)) {
+    vtpmloginfo(VTPM_LOG_VTPM, "VTPM Manager shutting down for signal
%s(%d). Please wait..\n", strsignal(signal), signal);
+    HANDLER_QUIT_FLAG =3D IPC_QUIT_FLAG =3D 1;
   }
-
-  VTPM_Stop_Manager();
-  exit(-1);
 }
=20
 struct sigaction ctl_c_handler;
=20
-TPM_RESULT VTPM_New_DMI_Extra(VTPM_DMI_RESOURCE *dmi_res, BYTE vm_type,
BYTE startup_mode) {
-
-  TPM_RESULT status =3D TPM_SUCCESS;
-  int fh;
-  char dmi_id_str[11]; // UINT32s are up to 10 digits + NULL
-  char *tx_vtpm_name, *tx_tpm_name, *vm_type_string;
-  struct stat file_info;
-
-  if (dmi_res->dmi_id =3D=3D VTPM_CTL_DM) {
-    dmi_res->tx_tpm_ipc_h =3D NULL;
-    dmi_res->rx_tpm_ipc_h =3D NULL;
-    dmi_res->tx_vtpm_ipc_h =3D NULL;
-    dmi_res->rx_vtpm_ipc_h =3D NULL;
-  } else {
-    // Create a pair of fifo pipes
-    dmi_res->rx_tpm_ipc_h =3D NULL;
-    dmi_res->rx_vtpm_ipc_h =3D NULL;
-
-    if ( ((dmi_res->tx_tpm_ipc_h =3D (vtpm_ipc_handle_t *) malloc
(sizeof(vtpm_ipc_handle_t))) =3D=3D NULL ) ||
-         ((dmi_res->tx_vtpm_ipc_h =3D(vtpm_ipc_handle_t *) malloc
(sizeof(vtpm_ipc_handle_t))) =3D=3D NULL ) ||
-         ((tx_tpm_name =3D (char *) malloc(11 +
strlen(VTPM_TX_TPM_FNAME))) =3D=3D NULL ) ||
-         ((tx_vtpm_name =3D(char *) malloc(11 +
strlen(VTPM_TX_VTPM_FNAME))) =3D=3D NULL) ) {
-      status =3DTPM_RESOURCES;
-      goto abort_egress;
-    }
-
-    sprintf(tx_tpm_name, VTPM_TX_TPM_FNAME, (uint32_t) dmi_res->dmi_id);=

-    sprintf(tx_vtpm_name, VTPM_TX_VTPM_FNAME, (uint32_t) dmi_res->dmi_id=
);
-
-    if ( (vtpm_ipc_init(dmi_res->tx_tpm_ipc_h, tx_tpm_name, O_WRONLY |
O_NONBLOCK, TRUE) !=3D 0) ||
-         (vtpm_ipc_init(dmi_res->tx_vtpm_ipc_h, tx_vtpm_name, O_WRONLY,
TRUE) !=3D 0) ) { //FIXME: O_NONBLOCK?
-      status =3D TPM_IOERROR;
-      goto abort_egress;
-    }
-
-    // Measure DMI
-    // FIXME: This will measure DMI. Until then use a fixed
DMI_Measurement value
-    // Also, this mechanism is specific to 1 VM architecture.
-    /*
-    fh =3D open(TPM_EMULATOR_PATH, O_RDONLY);
-    stat_ret =3D fstat(fh, &file_stat);
-    if (stat_ret =3D=3D 0)
-      dmi_size =3D file_stat.st_size;
-    else {
-      vtpmlogerror(VTPM_LOG_VTPM, "Could not open vtpmd!!\n");
-      status =3D TPM_IOERROR;
-      goto abort_egress;
-    }
-    dmi_buffer
-    */
-    memset(&dmi_res->DMI_measurement, 0xcc, sizeof(TPM_DIGEST));
-
-    if (vm_type =3D=3D VTPM_TYPE_PVM)
-      vm_type_string =3D (BYTE *)&VTPM_TYPE_PVM_STRING;
-    else
-      vm_type_string =3D (BYTE *)&VTPM_TYPE_HVM_STRING;
-
-    // Launch DMI
-    sprintf(dmi_id_str, "%d", (int) dmi_res->dmi_id);
-#ifdef MANUAL_DM_LAUNCH
-    vtpmlogerror(VTPM_LOG_VTPM, "Manually start VTPM with dmi=3D%s
now.\n", dmi_id_str);
-    dmi_res->dmi_pid =3D 0;
-#else
-    pid_t pid =3D fork();
-
-    if (pid =3D=3D -1) {
-      vtpmlogerror(VTPM_LOG_VTPM, "Could not fork to launch vtpm\n");
-      status =3D TPM_RESOURCES;
-      goto abort_egress;
-    } else if (pid =3D=3D 0) {
-      switch (startup_mode) {
-      case TPM_ST_CLEAR:
-        execl (TPM_EMULATOR_PATH, "vtpmd", "clear", vm_type_string,
dmi_id_str, NULL);
-        break;
-      case TPM_ST_STATE:
-        execl (TPM_EMULATOR_PATH, "vtpmd", "save", vm_type_string,
dmi_id_str, NULL);
-        break;
-      case TPM_ST_DEACTIVATED:
-        execl (TPM_EMULATOR_PATH, "vtpmd", "deactivated",
vm_type_string, dmi_id_str, NULL);
-        break;
-      default:
-        status =3D TPM_BAD_PARAMETER;
-        goto abort_egress;
-      }
-
-      // Returning from these at all is an error.
-      vtpmlogerror(VTPM_LOG_VTPM, "Could not exec to launch vtpm\n");
-    } else {
-      dmi_res->dmi_pid =3D pid;
-      vtpmloginfo(VTPM_LOG_VTPM, "Launching DMI on PID =3D %d\n", pid);
-    }
-#endif // MANUAL_DM_LAUNCH
-
-  } // If DMI =3D VTPM_CTL_DM
-    status =3D TPM_SUCCESS;
-
-abort_egress:
-  return (status);
-}
-
-TPM_RESULT VTPM_Close_DMI_Extra(VTPM_DMI_RESOURCE *dmi_res) {
-  TPM_RESULT status =3D TPM_SUCCESS;
-
-  if (vtpm_globals->connected_dmis =3D=3D 0) {
-    // No more DMI's connected. Close fifo to prevent a broken pipe.
-    // This is hackish. Need to think of another way.
-    vtpm_ipc_close(g_rx_tpm_ipc_h);
-  }
-
-=20
-  if (dmi_res->dmi_id !=3D VTPM_CTL_DM) {
-    vtpm_ipc_close(dmi_res->tx_tpm_ipc_h);
-    vtpm_ipc_close(dmi_res->tx_vtpm_ipc_h);
-
-    free(dmi_res->tx_tpm_ipc_h->name);
-    free(dmi_res->tx_vtpm_ipc_h->name);
-
-#ifndef MANUAL_DM_LAUNCH
-    if (dmi_res->dmi_id !=3D VTPM_CTL_DM) {
-      if (dmi_res->dmi_pid !=3D 0) {
-        vtpmloginfo(VTPM_LOG_VTPM, "Killing dmi on pid %d.\n",
dmi_res->dmi_pid);
-        if (kill(dmi_res->dmi_pid, SIGKILL) !=3D0) {
-          vtpmloginfo(VTPM_LOG_VTPM, "DMI on pid %d is already
dead.\n", dmi_res->dmi_pid);
-        } else if (waitpid(dmi_res->dmi_pid, NULL, 0) !=3D
dmi_res->dmi_pid) {
-          vtpmlogerror(VTPM_LOG_VTPM, "DMI on pid %d failed to
stop.\n", dmi_res->dmi_pid);
-          status =3D TPM_FAIL;
-        }
-      } else {
-        vtpmlogerror(VTPM_LOG_VTPM, "Could not kill dmi because it's
pid was 0.\n");
-        status =3D TPM_FAIL;
-      }
-    }
-#endif
-
-  } //endif ! dom0
-  return status;
-}
-
-
 int main(int argc, char **argv) {
-  vtpm_ipc_handle_t *tx_be_ipc_h, *rx_be_ipc_h, rx_tpm_ipc_h,
rx_vtpm_ipc_h, tx_hp_ipc_h, rx_hp_ipc_h;
-  struct vtpm_thread_params_s be_thread_params, dmi_thread_params,
hp_thread_params;
-  pthread_t be_thread, dmi_thread, hp_thread;
+  vtpm_ipc_handle_t *tx_be_ipc_h, *rx_be_ipc_h, tx_hp_ipc_h, rx_hp_ipc_h=
;
+  struct vtpm_thread_params_s be_thread_params, hp_thread_params;
+#ifndef VTPM_STUBDOM
+  vtpm_ipc_handle_t rx_tpm_ipc_h, rx_vtpm_ipc_h;
+  struct vtpm_thread_params_s dmi_thread_params;
+#endif
=20
 #ifdef DUMMY_BACKEND
   vtpm_ipc_handle_t tx_dummy_ipc_h, rx_dummy_ipc_h;
@@ -258,34 +110,28 @@ int main(int argc, char **argv) {
 #endif
=20
   vtpmloginfo(VTPM_LOG_VTPM, "Starting VTPM.\n");
-
-  // -------------------- Initialize Manager -----------------
-  if (VTPM_Init_Manager() !=3D TPM_SUCCESS) {
-    vtpmlogerror(VTPM_LOG_VTPM, "Closing vtpmd due to error during
startup.\n");
-    return -1;
-  }
-=20
+
   // -------------------- Setup Ctrl+C Handlers --------------
   ctl_c_handler.sa_handler =3D signal_handler;
   sigemptyset(&ctl_c_handler.sa_mask);
   ctl_c_handler.sa_flags =3D 0;  =20
 =20
-  if (sigaction(SIGINT, &ctl_c_handler, NULL) =3D=3D -1)
+  if ((sigaction(SIGINT, &ctl_c_handler, NULL) =3D=3D -1)
+    || (sigaction(SIGQUIT, &ctl_c_handler, NULL) =3D=3D -1)
+    || (sigaction(SIGHUP, &ctl_c_handler, NULL) =3D=3D -1) ) // For easi=
er
debugging with gdb
+  {
     vtpmlogerror(VTPM_LOG_VTPM, "Could not install SIGINT handler.
Ctl+break will not stop manager gently.\n");
+  }
 =20
-  // For easier debuggin with gdb
-  if (sigaction(SIGHUP, &ctl_c_handler, NULL) =3D=3D -1)
-    vtpmlogerror(VTPM_LOG_VTPM, "Could not install SIGHUP handler.
Ctl+break will not stop manager gently.\n");  =20
-=20
+  //Block all signals for child threads
   sigset_t sig_mask;
-  sigemptyset(&sig_mask);
-  sigaddset(&sig_mask, SIGPIPE);
-  sigprocmask(SIG_BLOCK, &sig_mask, NULL);
+  sigfillset(&sig_mask);
+  pthread_sigmask(SIG_SETMASK, &sig_mask, NULL);
 =20
   // ------------------- Set up file ipc structures ----------
 #ifdef DUMMY_BACKEND
-  if ( (vtpm_ipc_init(&tx_dummy_ipc_h, VTPM_DUMMY_TX_BE_FNAME, O_RDWR,
TRUE) !=3D 0) ||
-       (vtpm_ipc_init(&rx_dummy_ipc_h, VTPM_DUMMY_RX_BE_FNAME, O_RDWR,
TRUE) !=3D 0) ) {
+  if ( (vtpm_ipc_init(&tx_dummy_ipc_h, VTPM_DUMMY_TX_BE_FNAME, O_RDWR,
TRUE, FALSE) !=3D 0) ||
+       (vtpm_ipc_init(&rx_dummy_ipc_h, VTPM_DUMMY_RX_BE_FNAME, O_RDWR,
TRUE, FALSE) !=3D 0) ) {
=20
     vtpmlogerror(VTPM_LOG_VTPM, "Unable to create Dummy BE FIFOs.\n");
     exit(-1);
@@ -294,21 +140,29 @@ int main(int argc, char **argv) {
   tx_be_ipc_h =3D &tx_dummy_ipc_h;
   rx_be_ipc_h =3D &rx_dummy_ipc_h;
 #else
-  vtpm_ipc_init(&real_be_ipc_h, VTPM_BE_FNAME, O_RDWR, FALSE);
+  if(vtpm_ipc_init(&real_be_ipc_h, VTPM_BE_FNAME, O_RDWR, FALSE, TRUE)
!=3D 0) {
+     vtpmlogerror(VTPM_LOG_VTPM, "Unable to open backend device "
VTPM_BE_FNAME "\n");
+     exit(-1);
+  }
=20
   tx_be_ipc_h =3D &real_be_ipc_h;
   rx_be_ipc_h =3D &real_be_ipc_h;
 #endif
=20
-  if ( (vtpm_ipc_init(&rx_tpm_ipc_h, VTPM_RX_TPM_FNAME, O_RDONLY, TRUE)
!=3D 0) ||
-       (vtpm_ipc_init(&rx_vtpm_ipc_h, VTPM_RX_VTPM_FNAME, O_RDWR, TRUE)
!=3D 0) || //FIXME: O_RDONLY?
-       (vtpm_ipc_init(&tx_hp_ipc_h,  VTPM_TX_HP_FNAME, O_RDWR, TRUE) !=3D=

0)    ||
-       (vtpm_ipc_init(&rx_hp_ipc_h,  VTPM_RX_HP_FNAME, O_RDWR, TRUE) !=3D=

0) ) {
+  if (
+#ifndef VTPM_STUBDOM
+       (vtpm_ipc_init(&rx_tpm_ipc_h, VTPM_RX_TPM_FNAME, O_RDONLY, TRUE,
FALSE) !=3D 0) ||
+       (vtpm_ipc_init(&rx_vtpm_ipc_h, VTPM_RX_VTPM_FNAME, O_RDWR, TRUE,
FALSE) !=3D 0) || //FIXME: O_RDONLY?
+#endif
+       (vtpm_ipc_init(&tx_hp_ipc_h,  VTPM_TX_HP_FNAME, O_RDWR, TRUE,
TRUE) !=3D 0)    ||
+       (vtpm_ipc_init(&rx_hp_ipc_h,  VTPM_RX_HP_FNAME, O_RDWR, TRUE,
TRUE) !=3D 0) ) {
     vtpmlogerror(VTPM_LOG_VTPM, "Unable to create initial FIFOs.\n");
     exit(-1);
   }
=20
+#ifndef VTPM_STUBDOM
   g_rx_tpm_ipc_h =3D &rx_tpm_ipc_h;
+#endif
=20
   // -------------------- Set up thread params -------------
=20
@@ -316,10 +170,15 @@ int main(int argc, char **argv) {
   be_thread_params.rx_ipc_h =3D rx_be_ipc_h;
   be_thread_params.fw_tpm =3D TRUE;
   be_thread_params.fw_tx_ipc_h =3D NULL;
+#ifndef VTPM_STUBDOM
   be_thread_params.fw_rx_ipc_h =3D &rx_tpm_ipc_h;
+#else
+  be_thread_params.fw_rx_ipc_h =3D NULL;
+#endif
   be_thread_params.is_priv =3D FALSE;
   be_thread_params.thread_name =3D "Backend Listener";
=20
+#ifndef VTPM_STUBDOM
   dmi_thread_params.tx_ipc_h =3D NULL;
   dmi_thread_params.rx_ipc_h =3D &rx_vtpm_ipc_h;
   dmi_thread_params.fw_tpm =3D FALSE;
@@ -327,6 +186,7 @@ int main(int argc, char **argv) {
   dmi_thread_params.fw_rx_ipc_h =3D NULL;
   dmi_thread_params.is_priv =3D FALSE;
   dmi_thread_params.thread_name =3D "VTPM Listener";
+#endif
=20
   hp_thread_params.tx_ipc_h =3D &tx_hp_ipc_h;
   hp_thread_params.rx_ipc_h =3D &rx_hp_ipc_h;
@@ -336,34 +196,50 @@ int main(int argc, char **argv) {
   hp_thread_params.is_priv =3D TRUE;
   hp_thread_params.thread_name =3D "Hotplug Listener";
=20
+  // -------------------- Initialize Manager -----------------
+  if (VTPM_Init_Manager() !=3D TPM_SUCCESS) {
+    vtpmlogerror(VTPM_LOG_VTPM, "Closing vtpmd due to error during
startup.\n");
+    return -1;
+  }
+
+
   // --------------------- Launch Threads -----------------
=20
   vtpm_lock_init();
=20
-  vtpm_globals->master_pid =3D pthread_self();
+  master_thread =3D pthread_self();
+
 =20
   if (pthread_create(&be_thread, NULL, vtpm_manager_thread,
&be_thread_params) !=3D 0) {
     vtpmlogerror(VTPM_LOG_VTPM, "Failed to launch BE Thread.\n");
     exit(-1);
   }
 =20
+#ifndef VTPM_STUBDOM
   if (pthread_create(&dmi_thread, NULL, vtpm_manager_thread,
&dmi_thread_params) !=3D 0) {
     vtpmlogerror(VTPM_LOG_VTPM, "Failed to launch DMI Thread.\n");
     exit(-1);
   }
-
+#endif
=20
   if (pthread_create(&hp_thread, NULL, vtpm_manager_thread,
&hp_thread_params) !=3D 0) {
     vtpmlogerror(VTPM_LOG_VTPM, "Failed to launch HP Thread.\n");
     exit(-1);
   }
=20
+  //Turn signals back on for the master thread only
+  sigemptyset(&sig_mask);
+  sigaddset(&sig_mask, SIGPIPE);
+  pthread_sigmask(SIG_SETMASK, &sig_mask, NULL);
+
   //Join the other threads until exit time.
   pthread_join(be_thread, NULL);
+#ifndef VTPM_STUBDOM
   pthread_join(dmi_thread, NULL);
+#endif
   pthread_join(hp_thread, NULL);
=20
-  vtpmlogerror(VTPM_LOG_VTPM, "VTPM Manager shut down unexpectedly.\n");=

+  vtpmloginfo(VTPM_LOG_VTPM, "VTPM Manager shutting down...\n");
=20
   VTPM_Stop_Manager();
   vtpm_lock_destroy();
diff --git a/tools/vtpm_manager/manager/vtpmpriv.h
b/tools/vtpm_manager/manager/vtpmpriv.h
--- a/tools/vtpm_manager/manager/vtpmpriv.h
+++ b/tools/vtpm_manager/manager/vtpmpriv.h
@@ -40,6 +40,8 @@
 #ifndef __VTPMPRIV_H__
 #define __VTPMPRIV_H__
=20
+#include <signal.h>
+
 #include "vtpm_manager.h"
 #include "tcg.h"
 #include "tcs.h"
@@ -54,16 +56,19 @@
 #define DMI_NVM_FILE       "/var/vtpm/vtpm_dm_%d.data"
 #define VTPM_CTL_DM        0
=20
+extern volatile sig_atomic_t HANDLER_QUIT_FLAG;
+
 // ------------------------ Private Structures -----------------------
 typedef struct VTPM_DMI_RESOURCE_T {
+#ifndef VTPM_STUBDOM
   // I/O info for Manager to talk to DMI's and controllers
   vtpm_ipc_handle_t      *tx_vtpm_ipc_h;    // TX VTPM Results to DMI
   vtpm_ipc_handle_t      *rx_vtpm_ipc_h;    // RX VTPM Commands from DMI=

   vtpm_ipc_handle_t      *tx_tpm_ipc_h;     // TX TPM Commands to DMI
   vtpm_ipc_handle_t      *rx_tpm_ipc_h;     // RX TPM Results from DMI
+
+  pid_t                  dmi_pid;
=20
-#ifndef VTPM_MULTI_VM
-  pid_t                 dmi_pid;
 #endif
=20
   // Non-persistent Information
@@ -77,6 +82,9 @@ typedef struct VTPM_DMI_RESOURCE_T {
   BYTE                  dmi_type;
   TPM_DIGEST            NVM_measurement;  // Equal to the SHA1 of the bl=
ob
   TPM_DIGEST            DMI_measurement;  // Correct measurement of the
owning DMI
+
+  char* uuid;
+
 } VTPM_DMI_RESOURCE;
=20
 typedef struct tdVTPM_MIGKEY_LIST {
@@ -89,10 +97,6 @@ typedef struct tdVTPM_MIGKEY_LIST {
=20
 typedef struct tdVTPM_GLOBALS {
   // Non-persistent data
-#ifndef VTPM_MULTI_VM
-  pid_t               master_pid;
-#endif
-
   int                 connected_dmis;     // To close guest_rx when no
dmis are connected
=20
   struct hashtable    *dmi_map;               // Table of all DMI's
known indexed by persistent instance #
@@ -123,8 +127,8 @@ extern VTPM_GLOBALS *vtpm_globals;   // Key info and
DMI states
 extern const TPM_AUTHDATA SRK_AUTH;  // SRK Well Known Auth Value
=20
 // ********************** VTPM Functions *************************
-TPM_RESULT VTPM_Init_Manager(); // Start VTPM Service
-void VTPM_Stop_Manager();  // Stop VTPM Service
+TPM_RESULT VTPM_Init_Manager(void); // Start VTPM Service
+void VTPM_Stop_Manager(void);  // Stop VTPM Service
 TPM_RESULT VTPM_Manager_Handler(vtpm_ipc_handle_t *tx_ipc_h,
                                 vtpm_ipc_handle_t *rx_ipc_h,
                                 BOOL fw_tpm,   // Should forward TPM cmd=
s
@@ -143,6 +147,11 @@ TPM_RESULT VTPM_Handle_Save_NVM(     =20
VTPM_DMI_RESOURCE *myDMI,
                                         const buffer_t *inbuf,
                                         buffer_t *outbuf);
=20
+TPM_RESULT VTPM_Handle_Get_NVM_Size(   VTPM_DMI_RESOURCE *myDMI,
+                                        const buffer_t *inbuf,
+                                        buffer_t *outbuf);
+
+
 TPM_RESULT VTPM_Handle_TPM_Command(    VTPM_DMI_RESOURCE *dmi,
                                         buffer_t *inbuf,
                                         buffer_t *outbuf);
@@ -173,6 +182,9 @@ TPM_RESULT VTPM_Close_DMI_Extra(VTPM_DMI_RESOURCE
*dmi_res);
 TPM_RESULT close_dmi(VTPM_DMI_RESOURCE *dmi_res);
 TPM_RESULT init_dmi(UINT32 dmi_id, BYTE type,  VTPM_DMI_RESOURCE
**dmi_res);
=20
+/* Free's dmi_res and all of it's resources */
+void free_dmi(VTPM_DMI_RESOURCE *dmi_res);
+
 TPM_RESULT envelope_encrypt(const buffer_t     *inbuf,
                              CRYPTO_INFO        *asymkey,
                              buffer_t           *sealed_data);
@@ -183,4 +195,14 @@ TPM_RESULT envelope_decrypt(const buffer_t     *ciph=
er,
                             const TPM_AUTHDATA *key_usage_auth,
                             buffer_t           *unsealed_data);
=20
+TPM_RESULT symkey_encrypt(const buffer_t     *inbuf,
+                            CRYPTO_INFO        *asymkey,
+                            buffer_t           *sealed_key);
+
+TPM_RESULT symkey_decrypt(const buffer_t     *cipher,
+                            TCS_CONTEXT_HANDLE TCSContext,
+                TPM_HANDLE         keyHandle,
+                const TPM_AUTHDATA *key_usage_auth,
+                            buffer_t           *symkey_clear);
+
 #endif // __VTPMPRIV_H__
diff --git a/tools/vtpm_manager/manager/vtsp.c
b/tools/vtpm_manager/manager/vtsp.c
--- a/tools/vtpm_manager/manager/vtsp.c
+++ b/tools/vtpm_manager/manager/vtsp.c
@@ -38,6 +38,7 @@
 // =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
=20
 #include <string.h>
+#include <stdlib.h>
 #include "tcg.h"
 #include "tcs.h"
 #include "bsg.h"
@@ -312,7 +313,7 @@ TPM_RESULT VTSP_TakeOwnership(   const
TCS_CONTEXT_HANDLE hContext,
   TPM_PROTOCOL_ID proto_id =3D TPM_PID_OWNER;
   BYTE *new_srk;
 =20
-  BYTE *paramText;        // Digest to make Auth.
+  BYTE *paramText =3D NULL;        // Digest to make Auth.
   UINT32 paramTextSize;
 =20
   // vars for srkpubkey parameter
@@ -458,7 +459,7 @@ TPM_RESULT VTSP_CreateWrapKey(  const
TCS_CONTEXT_HANDLE hContext,
   vtpmloginfo(VTPM_LOG_VTSP, "Creating new key of type %d.\n", usage);
 =20
   // vars for Calculate encUsageAuth
-  BYTE *paramText;    =20
+  BYTE *paramText =3D NULL;
   UINT32 paramTextSize;
 =20
   // vars for Calculate encUsageAuth
@@ -567,8 +568,7 @@ TPM_RESULT VTSP_CreateWrapKey(  const
TCS_CONTEXT_HANDLE hContext,
                 osapSharedSecret, auth, 0) );
 =20
   // Unpack/return key structure
-  TPMTRYRETURN(buffer_init(pubKeyBuf, 0, 0) );
-  TPMTRYRETURN(buffer_append_raw(pubKeyBuf, newKeyText.size,
newKeyText.data) );
+  TPMTRYRETURN(buffer_init(pubKeyBuf, newKeyText.size, newKeyText.data) =
);
 =20
   goto egress;
 =20
@@ -664,6 +664,7 @@ TPM_RESULT VTSP_LoadKey(const TCS_CONTEXT_HANDLE  =20
hContext,
   =20
     // Destroy rsaKeyParms
     BSG_Destroy(BSG_TPM_RSA_KEY_PARMS, &rsaKeyParms);
+    BSG_Destroy(BSG_TPM_KEY, &newKey);
   =20
     // Set encryption scheme
     cryptoinfo->encScheme =3D CRYPTO_ES_RSAESOAEP_SHA1_MGF1;
@@ -733,8 +734,7 @@ TPM_RESULT VTSP_Unbind( const TCS_CONTEXT_HANDLE  =20
hContext,
                 hContext) );
 =20
   // Unpack/return key structure
-  TPMTRYRETURN(buffer_init(clear_data, 0, 0));
-  TPMTRYRETURN(buffer_append_raw (clear_data, clear_data_size,
clear_data_text) );
+  TPMTRYRETURN(buffer_init(clear_data, clear_data_size, clear_data_text)=
 );
 =20
   goto egress;
 =20
@@ -793,8 +793,7 @@ TPM_RESULT VTSP_Bind(   CRYPTO_INFO *cryptoInfo,
     vtpmlogerror(VTPM_LOG_VTSP, "Enc buffer just overflowed.\n");
   }
 =20
-  buffer_init(outData, 0, NULL);
-  buffer_append_raw(outData, out_tmp_size, out_tmp);
+  buffer_init(outData, out_tmp_size, out_tmp);
 =20
   vtpmloginfo(VTPM_LOG_TXDATA, "Bind Generated[%d] =3D 0x", out_tmp_size=
);
   for(i =3D 0 ; i < out_tmp_size ; i++) {
@@ -1005,8 +1004,6 @@ TPM_RESULT VTSP_SaveState( const
TCS_CONTEXT_HANDLE    hContext) {
=20
   vtpmloginfo(VTPM_LOG_VTSP, "Calling TPM_SaveState.\n");
=20
-  TPM_RESULT status =3D TPM_SUCCESS;
-
   // Call TCS
   return ( TCSP_SaveState ( hContext ) );
=20
diff --git a/tools/vtpm_manager/manager/vtsp.h
b/tools/vtpm_manager/manager/vtsp.h
--- a/tools/vtpm_manager/manager/vtsp.h
+++ b/tools/vtpm_manager/manager/vtsp.h
@@ -42,6 +42,7 @@
=20
 #include "tcg.h"
 #include "tcs.h"
+#include "crypto.h"
=20
 #define KEY_BUFFER_SIZE 2048
=20
diff --git a/tools/vtpm_manager/migration/Makefile
b/tools/vtpm_manager/migration/Makefile
--- a/tools/vtpm_manager/migration/Makefile
+++ b/tools/vtpm_manager/migration/Makefile
@@ -1,5 +1,11 @@
-XEN_ROOT =3D $(CURDIR)/../../..
-include $(XEN_ROOT)/tools/vtpm_manager/Rules.mk
+XEN_ROOT =3D $(realpath ../../..)
+include ../Rules.mk
+
+CFLAGS +=3D -I../crypto
+CFLAGS +=3D -I../util
+CFLAGS +=3D -I../tcs
+CFLAGS +=3D -I../manager
+
=20
 VPATH =3D ../manager
=20
@@ -33,10 +39,10 @@ mrproper: clean
     rm -f *~
=20
 $(BIND): $(OBJSD)
-    $(CC) $(LDFLAGS) $^ $(LIBS) -o $@
+    $(CC) $(CFLAGS) $(LDFLAGS) $^ $(LIBS) -o $@
=20
 $(BINC): $(OBJSC)
-    $(CC) $(LDFLAGS) $^ $(LIBS) -o $@
+    $(CC) $(CFLAGS) $(LDFLAGS) $^ $(LIBS) -o $@
=20
 # libraries
 LIBS +=3D ../util/libTCGUtils.a
diff --git a/tools/vtpm_manager/migration/vtpm_manager_if.c
b/tools/vtpm_manager/migration/vtpm_manager_if.c
--- a/tools/vtpm_manager/migration/vtpm_manager_if.c
+++ b/tools/vtpm_manager/migration/vtpm_manager_if.c
@@ -50,15 +50,12 @@
 #include "vtpm_migrator.h"
 #include "vtpm_manager.h"
=20
-#define VTPM_TX_HP_FNAME       "/var/vtpm/fifos/from_console.fifo"
-#define VTPM_RX_HP_FNAME       "/var/vtpm/fifos/to_console.fifo"
-
 static vtpm_ipc_handle_t tx_ipc_h, rx_ipc_h;
=20
 TPM_RESULT vtpm_manager_open(){
=20
-  if ( (vtpm_ipc_init(&tx_ipc_h,  VTPM_TX_HP_FNAME, O_RDWR, TRUE) !=3D 0=
)
||  //FIXME: wronly
-       (vtpm_ipc_init(&rx_ipc_h,  VTPM_RX_HP_FNAME, O_RDWR, TRUE) !=3D 0=
)
) { //FIXME: rdonly
+  if ( (vtpm_ipc_init(&tx_ipc_h,  VTPM_TX_HP_FNAME, O_RDWR, TRUE, TRUE)
!=3D 0) ||  //FIXME: wronly
+       (vtpm_ipc_init(&rx_ipc_h,  VTPM_RX_HP_FNAME, O_RDWR, TRUE, TRUE)
!=3D 0) ) { //FIXME: rdonly
     vtpmlogerror(VTPM_LOG_VTPM, "Unable to connect to vtpm_manager.\n");=

     return TPM_IOERROR;
   }
diff --git a/tools/vtpm_manager/tcs/Makefile
b/tools/vtpm_manager/tcs/Makefile
--- a/tools/vtpm_manager/tcs/Makefile
+++ b/tools/vtpm_manager/tcs/Makefile
@@ -1,5 +1,10 @@
-XEN_ROOT =3D $(CURDIR)/../../..
-include $(XEN_ROOT)/tools/vtpm_manager/Rules.mk
+XEN_ROOT =3D $(realpath ../../..)
+include ../Rules.mk
+
+CFLAGS +=3D -I../crypto
+CFLAGS +=3D -I../util
+CFLAGS +=3D -I../manager
+
=20
 BIN        =3D libTCS.a
=20
diff --git a/tools/vtpm_manager/tcs/contextmgr.c
b/tools/vtpm_manager/tcs/contextmgr.c
--- a/tools/vtpm_manager/tcs/contextmgr.c
+++ b/tools/vtpm_manager/tcs/contextmgr.c
@@ -195,6 +195,7 @@ BOOL DeleteHandleFromList(   TCS_CONTEXT_HANDLE
hContext, // in
=20
 BOOL FreeHandleList(    CONTEXT_HANDLE*     pContextHandle) { // in
   HANDLE_LIST* pCurrentHandle;
+  HANDLE_LIST* pNext;
   BOOL returncode =3D TRUE;
 =20
   vtpmloginfo(VTPM_LOG_TCS_DEEP, "Freeing all handles for context\n");
@@ -205,6 +206,7 @@ BOOL FreeHandleList(    CONTEXT_HANDLE*   =20
pContextHandle) { // in
   pCurrentHandle =3D pContextHandle->pHandleList;
   while (pCurrentHandle !=3D NULL) {
   =20
+    pNext =3D pCurrentHandle->pNextHandle;
     switch (pCurrentHandle->type) {
     case TPM_RT_KEY:
       returncode =3D returncode && !TCSP_EvictKey(pContextHandle->handle=
,
pCurrentHandle->handle);
@@ -216,7 +218,7 @@ BOOL FreeHandleList(    CONTEXT_HANDLE*   =20
pContextHandle) { // in
       returncode =3D FALSE;
     }
   =20
-    pCurrentHandle =3D pCurrentHandle->pNextHandle;
+    pCurrentHandle =3D pNext;
   =20
   }
 =20
diff --git a/tools/vtpm_manager/tcs/tcs.c b/tools/vtpm_manager/tcs/tcs.c
--- a/tools/vtpm_manager/tcs/tcs.c
+++ b/tools/vtpm_manager/tcs/tcs.c
@@ -77,7 +77,7 @@ CONTEXT_HANDLE *LookupContext( TCS_CONTEXT_HANDLE=20
hContext) {
 //
-------------------------------------------------------------------------=
--------
 // Initialization/Uninitialization SubComponent API
 //
-------------------------------------------------------------------------=
--------
-TPM_RESULT TCS_create() {
+TPM_RESULT TCS_create(void) {
   TDDL_RESULT hRes =3D TDDL_E_FAIL;
   TPM_RESULT result =3D TPM_FAIL;
 =20
@@ -101,7 +101,7 @@ TPM_RESULT TCS_create() {
 }
=20
=20
-void TCS_destroy()
+void TCS_destroy(void)
 {
   TCS_m_nCount--;
 =20
@@ -113,14 +113,13 @@ void TCS_destroy()
     TCS_CONTEXT_HANDLE  *hContext;
   =20
     // Close all the TCS contexts. TCS should evict keys based on this
-    if (hashtable_count(context_ht) > 0) {
+    while (hashtable_count(context_ht) > 0) {
       context_itr =3D hashtable_iterator(context_ht);
-      do {
-        hContext =3D (TCS_CONTEXT_HANDLE *)
hashtable_iterator_key(context_itr);
-    if (TCS_CloseContext(*hContext) !=3D TPM_SUCCESS)
-        vtpmlogerror(VTPM_LOG_TCS, "Failed to close context %d
properly.\n", *hContext);
+
+      hContext =3D (TCS_CONTEXT_HANDLE *)
hashtable_iterator_key(context_itr);
+      if (TCS_CloseContext(*hContext) !=3D TPM_SUCCESS)
+        vtpmlogerror(VTPM_LOG_TCS, "Failed to close context %d
properly.\n", *hContext);
     =20
-      } while (hashtable_iterator_advance(context_itr));
       free(context_itr);
     }
     hashtable_destroy(context_ht, 1);
@@ -534,6 +533,10 @@ TPM_RESULT TCSP_TerminateHandle(TCS_CONTEXT_HANDLE
hContext, // in
               BSG_TYPE_UINT32, &handle);
   // fill paramSize again as we now have the correct size
   BSG_Pack(BSG_TYPE_UINT32, &InLength, InBuf+2);
+
+  if (!DeleteHandleFromList(hContext, handle)) {
+    vtpmlogerror(VTPM_LOG_TCS, "KeyHandle not removed from list\n");
+  }
 =20
   // call the TPM driver
   if ((hRes =3D TDDL_TransmitData(InBuf, InLength, OutBuf, &OutLength))
@@ -545,9 +548,6 @@ TPM_RESULT TCSP_TerminateHandle(TCS_CONTEXT_HANDLE
hContext, // in
                BSG_TYPE_UINT32, &paramSize,
                BSG_TPM_COMMAND_CODE, &returnCode);
   =20
-    if (!DeleteHandleFromList(hContext, handle))
-      vtpmlogerror(VTPM_LOG_TCS, "KeyHandle not removed from list\n");
-     =20
   =20
     if (returnCode =3D=3D TPM_SUCCESS && tag =3D=3D TPM_TAG_RSP_COMMAND)=
 {
       // Print debug info
@@ -882,6 +882,7 @@ TPM_RESULT TCSP_CreateWrapKey(TCS_CONTEXT_HANDLE
hContext,   // in
     =20
       memcpy(*prgbKey, tempBuf, *pcKeySize);
     =20
+      BSG_Destroy(BSG_TPM_KEY, &wrappedKey);
       vtpmloginfo(VTPM_LOG_TCS_DEEP, "Received paramSize : %d\n",
paramSize);
     } else
       vtpmlogerror(VTPM_LOG_TCS, "TCSP_CreateWrapKey Failed with return
code %s\n", tpm_get_error_name(returnCode));
@@ -980,6 +981,10 @@ TPM_RESULT TCSP_EvictKey(TCS_CONTEXT_HANDLE
hContext, // in
   BSG_Pack(BSG_TYPE_UINT32, &InLength, InBuf+2);
 =20
   vtpmloginfo(VTPM_LOG_TCS_DEEP, "Sending paramSize =3D %d\n", InLength)=
;
+
+  if (!DeleteHandleFromList(hContext, hKey)) {
+    vtpmlogerror(VTPM_LOG_TCS, "KeyHandle not removed from list\n");
+  }
 =20
   // call the TPM driver
   if ((hRes =3D TDDL_TransmitData(InBuf, InLength, OutBuf, &OutLength))
=3D=3D TDDL_SUCCESS) {
@@ -989,10 +994,6 @@ TPM_RESULT TCSP_EvictKey(TCS_CONTEXT_HANDLE
hContext, // in
                BSG_TYPE_UINT32, &paramSize,
                BSG_TPM_COMMAND_CODE, &returnCode);
   =20
-    if (!DeleteHandleFromList(hContext, hKey)) {
-      vtpmlogerror(VTPM_LOG_TCS, "KeyHandle not removed from list\n");
-    }    =20
-  =20
     if (returnCode =3D=3D TPM_SUCCESS && tag =3D=3D TPM_TAG_RSP_COMMAND)=
 {
       vtpmloginfo(VTPM_LOG_TCS_DEEP, "Received paramSize : %d\n",
paramSize);
     } else {
@@ -1019,7 +1020,7 @@ TPM_RESULT TCSP_GetRandom(TCS_CONTEXT_HANDLE
hContext,  // in
   TDDL_UINT32  OutLength =3D TCPA_MAX_BUFFER_LENGTH;
 =20
   // check input params
-  if (bytesRequested =3D=3D NULL || *randomBytes =3D=3D NULL){
+  if (bytesRequested =3D=3D NULL || randomBytes =3D=3D NULL){
     return TPM_BAD_PARAMETER;
   }
 =20
diff --git a/tools/vtpm_manager/tcs/tcs.h b/tools/vtpm_manager/tcs/tcs.h
--- a/tools/vtpm_manager/tcs/tcs.h
+++ b/tools/vtpm_manager/tcs/tcs.h
@@ -50,8 +50,8 @@
 // Exposed API
 // ------------------------------------------------------------------
=20
-TPM_RESULT TCS_create();
-void TCS_destroy();
+TPM_RESULT TCS_create(void);
+void TCS_destroy(void);
=20
 TPM_RESULT TCS_OpenContext( /* OUT */ TCS_CONTEXT_HANDLE* hContext );
=20
diff --git a/tools/vtpm_manager/tcs/tpmddl.c
b/tools/vtpm_manager/tcs/tpmddl.c
--- /dev/null
+++ b/tools/vtpm_manager/tcs/tpmddl.c
@@ -0,0 +1,167 @@
+/*
+ * Copyright (c) 2010-2012 United States Government, as represented by
+ * the Secretary of Defense.  All rights reserved.
+ *
+ * THIS SOFTWARE AND ITS DOCUMENTATION ARE PROVIDED AS IS AND WITHOUT
+ * ANY EXPRESS OR IMPLIED WARRANTIES WHATSOEVER. ALL WARRANTIES
+ * INCLUDING, BUT NOT LIMITED TO, PERFORMANCE, MERCHANTABILITY, FITNESS
+ * FOR A PARTICULAR  PURPOSE, AND NONINFRINGEMENT ARE HEREBY
+ * DISCLAIMED. USERS ASSUME THE ENTIRE RISK AND LIABILITY OF USING THE
+ * SOFTWARE.
+ */
+
+#include <string.h>
+#include "tpmddl.h"
+#include "tcs.h"
+#include "bsg.h"
+#include "log.h"
+
+#define MIN(X,Y) ((X) < (Y) ? (X) : (Y))
+
+TDDL_RESULT TDDL_GetCapability( TDDL_UINT32 cap,
+      TDDL_UINT32 sub,
+      TDDL_BYTE* buffer,
+      TDDL_UINT32* size)
+{
+   TDDL_RESULT status;
+
+   TPM_TAG tag =3D TPM_TAG_RQU_COMMAND;
+   UINT32 paramsize =3D 22;
+   UINT32 outsize;
+   TPM_COMMAND_CODE ord =3D TPM_ORD_GetCapability;
+   UINT32 subcapsize =3D 4;
+
+   BYTE inbuf[TCPA_MAX_BUFFER_LENGTH];
+   BYTE outbuf[TCPA_MAX_BUFFER_LENGTH];
+
+   int offset;
+
+   BSG_PackList(inbuf, 6,
+     BSG_TPM_TAG, &(tag),
+     BSG_TYPE_UINT32, &(paramsize),
+     BSG_TPM_COMMAND_CODE, &(ord),
+     BSG_TYPE_UINT32, &(cap),
+     BSG_TYPE_UINT32, &(subcapsize),
+     BSG_TYPE_UINT32, &(sub)
+     );
+
+   //Send the command, get the response
+   TPMTRYRETURN(TDDL_TransmitData( inbuf, paramsize, outbuf, &outsize));=

+
+   offset =3D BSG_UnpackList(outbuf, 4,
+     BSG_TPM_TAG, &(tag),
+     BSG_TYPE_UINT32, &(paramsize),
+     BSG_TPM_RESULT, &(status),
+     BSG_TYPE_UINT32, size
+     );
+   if (status !=3D TPM_SUCCESS || tag !=3D TPM_TAG_RSP_COMMAND) {
+      return status;
+   }
+   if(*size >=3D TCPA_MAX_BUFFER_LENGTH - offset) {
+      return TPM_FAIL;
+   }
+   memcpy(buffer, outbuf + offset, *size);
+
+abort_egress:
+   return status;
+}
+
+TDDL_RESULT TDDL_FlushSpecific(TDDL_UINT32 handle, TDDL_UINT32 res) {
+    /* FIXME: Add code here to check if TPM_FlushSpecific is not
supported (on 1.1 only TPMS?)
+    * If this is the case then we need to use TPM_EvictKey for key handl=
es
+    * and TPM_Terminate_Handle/TPM_Reset for auth handles */
+   TDDL_RESULT status;
+
+   TPM_TAG tag =3D TPM_TAG_RQU_COMMAND;
+   UINT32 paramsize =3D 18;
+   TPM_COMMAND_CODE ord =3D TPM_ORD_FlushSpecific;
+
+   BYTE inbuf[TCPA_MAX_BUFFER_LENGTH];
+   BYTE outbuf[TCPA_MAX_BUFFER_LENGTH];
+   UINT32 outsize;
+
+   int offset;
+
+   BSG_PackList(inbuf, 5,
+     BSG_TPM_TAG, &(tag),
+     BSG_TYPE_UINT32, &(paramsize),
+     BSG_TPM_COMMAND_CODE, &(ord),
+     BSG_TPM_HANDLE, &(handle),
+     BSG_TPM_RESOURCE_TYPE, &(res)
+     );
+
+   //Send command
+   TPMTRYRETURN(TDDL_TransmitData( inbuf, paramsize, outbuf, &outsize ))=
;
+
+   offset =3D BSG_UnpackList(outbuf, 4,
+     BSG_TPM_TAG, &(tag),
+     BSG_TYPE_UINT32, &(paramsize),
+     BSG_TPM_RESULT, &(status)
+     );
+
+abort_egress:
+   return status;
+
+}
+
+TDDL_RESULT TDDL_FlushAllResources(void) {
+  TDDL_RESULT status =3D TPM_SUCCESS;
+
+  TDDL_BYTE buf[TCPA_MAX_BUFFER_LENGTH];
+  TDDL_UINT32 bufsiz;
+
+  UINT16 packedsz;
+  int size;
+  UINT32 handle;
+  BYTE* ptr;
+
+  int i, j;
+
+#define RLISTSZ 6
+  TPM_RESOURCE_TYPE reslist[RLISTSZ] =3D { TPM_RT_KEY, TPM_RT_AUTH,
TPM_RT_TRANS, TPM_RT_COUNTER, TPM_RT_DAA_TPM, TPM_RT_CONTEXT };
+
+  //Iterate through each resource type and flush all handles
+  for(i =3D 0; i < RLISTSZ; ++i) {
+     TPM_RESOURCE_TYPE res =3D reslist[i];
+     // Get list of current key handles
+     if((status =3D TDDL_GetCapability( TPM_CAP_HANDLE, res, buf,
&bufsiz)) !=3D TPM_SUCCESS) {
+    //This can happen if the resource type is not supported
+    //If this happens just silently skip the resource type
+    if(status =3D=3D TPM_BAD_MODE) {
+       status =3D TPM_SUCCESS;
+       continue;
+    //Otherwise we just fail
+    } else {
+       TPMTRYRETURN(status);
+    }
+     }
+
+#if 0
+     //DEBUG PRINTOUTS
+     printf("TPM_GetCapability(TPM_CAP_HANDLE, %lu)\n", (unsigned long)
res);
+     for(j =3D 0; j < bufsiz; ++j) {
+    printf("%02X ", buf[j]);
+     }
+     printf("\n");
+#endif
+
+     ptr =3D buf;
+     ptr +=3D BSG_Unpack(BSG_TYPE_UINT16, ptr, &(packedsz));
+     size =3D packedsz;
+
+     //Flush each handle
+     if(size) {
+    vtpmloginfo(VTPM_LOG_VTPM, "Flushing %u handle(s) of type %lu\n",
size, (unsigned long) res);
+    for(j =3D 0; j < size; ++j) {
+       ptr +=3D BSG_Unpack(BSG_TPM_HANDLE, ptr, &(handle));
+       TPMTRYRETURN(TDDL_FlushSpecific(handle, res));
+    }
+     }
+
+  }
+
+  goto egress;
+abort_egress:
+egress:
+  return status;
+}
diff --git a/tools/vtpm_manager/tcs/tpmddl.h
b/tools/vtpm_manager/tcs/tpmddl.h
--- a/tools/vtpm_manager/tcs/tpmddl.h
+++ b/tools/vtpm_manager/tcs/tpmddl.h
@@ -50,13 +50,14 @@ typedef unsigned int TDDL_UINT32;
 typedef TDDL_UINT32 TDDL_RESULT;
 typedef unsigned char TDDL_BYTE;
=20
-TDDL_RESULT TDDL_Open();
-void TDDL_Close();
+TDDL_RESULT TDDL_Open(void);
+TDDL_RESULT TDDL_Open_use_fd(int fd);
+void TDDL_Close(void);
 TDDL_RESULT TDDL_TransmitData( TDDL_BYTE* in,
                    TDDL_UINT32 insize,
                    TDDL_BYTE* out,
                    TDDL_UINT32* outsize);
-TDDL_RESULT TDDL_GetStatus();
+TDDL_RESULT TDDL_GetStatus(void);
 TDDL_RESULT TDDL_GetCapability( TDDL_UINT32 cap,
                 TDDL_UINT32 sub,
                 TDDL_BYTE* buffer,
@@ -66,4 +67,10 @@ TDDL_RESULT TDDL_SetCapability( TDDL_UINT32 cap,
                 TDDL_BYTE* buffer,
                 TDDL_UINT32* size);
=20
+TDDL_RESULT TDDL_FlushSpecific(TDDL_UINT32 handle,
+                TDDL_UINT32 res);
+
+TDDL_RESULT TDDL_FlushAllResources(void);
+
+
 #endif // __TPMDDL_H__
diff --git a/tools/vtpm_manager/tcs/transmit.c
b/tools/vtpm_manager/tcs/transmit.c
--- a/tools/vtpm_manager/tcs/transmit.c
+++ b/tools/vtpm_manager/tcs/transmit.c
@@ -104,12 +104,13 @@ TDDL_TransmitData( TDDL_BYTE* in,
   return status;
 }
=20
-TPM_RESULT TDDL_Open() {
+TDDL_RESULT TDDL_Open(void) {
 =20
   TDDL_RESULT status =3D TDDL_SUCCESS;
 =20
+  /* If tpm device is already open just silently return success */
   if (g_TDDL_open)
-    return TPM_FAIL;
+    return TPM_SUCCESS;
=20
 #ifdef DUMMY_TPM=20
   *g_rx_fdp =3D open (TPM_RX_FNAME, O_RDWR);
@@ -117,7 +118,7 @@ TPM_RESULT TDDL_Open() {
=20
   g_tx_fd =3D open (TPM_TX_FNAME, O_RDWR);
   if (g_tx_fd < 0) {
-    vtpmlogerror(VTPM_LOG_TXDATA, "TPM open failed");
+    vtpmlogerror(VTPM_LOG_TXDATA, "TPM open failed\n");
     return TPM_IOERROR;
   }
 =20
@@ -126,7 +127,20 @@ TPM_RESULT TDDL_Open() {
   return status;
 }
=20
-void TDDL_Close() {
+TDDL_RESULT TDDL_Open_use_fd(int fd) {
+   TDDL_RESULT status =3D TDDL_SUCCESS;
+
+   if(g_TDDL_open)
+      return TPM_FAIL;
+
+   g_tx_fd =3D fd;
+
+   g_TDDL_open =3D 1;
+
+   return status;
+}
+
+void TDDL_Close(void) {
   if (! g_TDDL_open)
         return;
=20
diff --git a/tools/vtpm_manager/util/Makefile
b/tools/vtpm_manager/util/Makefile
--- a/tools/vtpm_manager/util/Makefile
+++ b/tools/vtpm_manager/util/Makefile
@@ -1,5 +1,10 @@
-XEN_ROOT =3D $(CURDIR)/../../..
-include $(XEN_ROOT)/tools/vtpm_manager/Rules.mk
+XEN_ROOT =3D $(realpath ../../..)
+include ../Rules.mk
+
+CFLAGS +=3D -I../crypto
+CFLAGS +=3D -I../tcs
+CFLAGS +=3D -I../manager
+
=20
 BIN        =3D libTCGUtils.a
=20
diff --git a/tools/vtpm_manager/util/bsg.c b/tools/vtpm_manager/util/bsg.=
c
--- a/tools/vtpm_manager/util/bsg.c
+++ b/tools/vtpm_manager/util/bsg.c
@@ -41,6 +41,7 @@
 #include <string.h>
 #include <stdarg.h>
 #include <malloc.h>
+#include <stdlib.h>
 #include "tcg.h"
 #include "crypto.h"
 #include "bsg.h"
@@ -317,7 +318,7 @@ static const BSG_Format* find_format (BSG_Type t) {
 // FIXME: should have a function be passed in here which is called if
the test
 // fails. Then the caller can decide what to do: abort, notify, whatever=

 //
-BOOL BSG_static_selfcheck ()
+BOOL BSG_static_selfcheck (void)
 {
   int i;
=20
diff --git a/tools/vtpm_manager/util/bsg.h b/tools/vtpm_manager/util/bsg.=
h
--- a/tools/vtpm_manager/util/bsg.h
+++ b/tools/vtpm_manager/util/bsg.h
@@ -161,6 +161,6 @@ TPM_RESULT BSG_DestroyTuple (int numParams,
pack_tuple_t params[]);
 void BSG_PackConst(BSG_UINT32 val, int size, BSG_BYTE* dst);
 BSG_UINT32 BSG_UnpackConst(const BSG_BYTE* src, int size);
=20
-BOOL BSG_static_selfcheck ();
+BOOL BSG_static_selfcheck (void);
=20
 #endif
diff --git a/tools/vtpm_manager/util/buffer.c
b/tools/vtpm_manager/util/buffer.c
--- a/tools/vtpm_manager/util/buffer.c
+++ b/tools/vtpm_manager/util/buffer.c
@@ -40,6 +40,7 @@
=20
 #include "tcg.h"
 #include "bsg.h"
+#include "log.h"
 #include "buffer.h"
=20
 static TPM_RESULT buffer_priv_realloc (buffer_t * buf, tpm_size_t newsiz=
e);
@@ -51,6 +52,7 @@ static TPM_RESULT buffer_priv_realloc (buffer_t * buf,
tpm_size_t newsize);
 TPM_RESULT buffer_init (buffer_t * buf, tpm_size_t initsize, const
BYTE* initval) {
   if (initsize =3D=3D 0) {
     memset(buf, 0, sizeof(*buf));
+    buf->bytes =3D NULL;
     return TPM_SUCCESS;
   }
 =20
@@ -62,8 +64,11 @@ TPM_RESULT buffer_init (buffer_t * buf, tpm_size_t
initsize, const BYTE* initval
   buf->size =3D initsize;
   buf->alloc_size =3D initsize;
 =20
-  if (initval)
+  if (initval) {
     memcpy (buf->bytes, initval, initsize);
+  } else {
+     memset(buf->bytes, 0, initsize);
+  }
 =20
   buf->is_owner =3D TRUE;
 =20
@@ -190,6 +195,29 @@ TPM_RESULT buffer_append_raw (buffer_t * buf,
tpm_size_t len, const BYTE* bytes)
   return status;
 }
=20
+TPM_RESULT buffer_prepend_raw(buffer_t * buf, tpm_size_t len, const
BYTE* bytes) {
+  TPM_RESULT status =3D TPM_SUCCESS;
+
+  if (buf->alloc_size < buf->size + len) {
+    TPMTRYRETURN( buffer_priv_realloc (buf, buf->size + len) );
+  }
+
+  if(buf->size > 0) {
+    memmove(buf->bytes + len, buf->bytes, buf->size);
+  }
+  memcpy(buf->bytes, bytes, len);
+
+  buf->size +=3D len;
+
+  goto egress;
+
+ abort_egress:
+
+ egress:
+
+  return status;
+}
+
 tpm_size_t buffer_len (const buffer_t* buf) {
   return buf->size;
 }
@@ -199,7 +227,6 @@ TPM_RESULT buffer_free (buffer_t * buf) {
     free (buf->bytes);
     buf->bytes =3D NULL;
     buf->size =3D buf->alloc_size =3D 0;
- =20
   }
 =20
   return TPM_SUCCESS;
@@ -224,3 +251,13 @@ TPM_RESULT buffer_priv_realloc (buffer_t * buf,
tpm_size_t newsize) {
 =20
   return TPM_SUCCESS;
 }
+
+TPM_RESULT buffer_truncate(buffer_t* buf, tpm_size_t len)
+{
+   if(len <=3D buf->size) {
+      buf->size =3D len;
+      return TPM_SUCCESS;
+   }
+
+   return TPM_FAIL;
+}
diff --git a/tools/vtpm_manager/util/buffer.h
b/tools/vtpm_manager/util/buffer.h
--- a/tools/vtpm_manager/util/buffer.h
+++ b/tools/vtpm_manager/util/buffer.h
@@ -92,4 +92,9 @@ TPM_RESULT buffer_free (buffer_t * buf);
=20
 TPM_RESULT buffer_append_raw (buffer_t * buf, tpm_size_t len, const
BYTE* bytes);
=20
+TPM_RESULT buffer_prepend_raw(buffer_t * buf, tpm_size_t len, const
BYTE* bytes);
+
+//Reduce the size of the buffer, if len > buffer size returns an error
+TPM_RESULT buffer_truncate(buffer_t* buf, tpm_size_t len);
+
 #endif // _TOOLS_H_
diff --git a/tools/vtpm_manager/util/hashtable.c
b/tools/vtpm_manager/util/hashtable.c
--- a/tools/vtpm_manager/util/hashtable.c
+++ b/tools/vtpm_manager/util/hashtable.c
@@ -32,12 +32,6 @@
  * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
 */
=20
-/*
- * There are duplicates of this code in:
- *  - tools/xenstore/hashtable.c
- *  - tools/blktap2/drivers/hashtable.c
- */
-
 #include "hashtable.h"
 #include "hashtable_private.h"
 #include <stdlib.h>
diff --git a/tools/vtpm_manager/util/hashtable.h
b/tools/vtpm_manager/util/hashtable.h
--- a/tools/vtpm_manager/util/hashtable.h
+++ b/tools/vtpm_manager/util/hashtable.h
@@ -32,11 +32,6 @@
  * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
 */
=20
-/*
- * There are duplicates of this code in:
- *  - tools/xenstore/hashtable.h
- *  - tools/blktap2/drivers/hashtable.h
- */
=20
 #ifndef __HASHTABLE_CWC22_H__
 #define __HASHTABLE_CWC22_H__
diff --git a/tools/vtpm_manager/util/hashtable_itr.c
b/tools/vtpm_manager/util/hashtable_itr.c
--- a/tools/vtpm_manager/util/hashtable_itr.c
+++ b/tools/vtpm_manager/util/hashtable_itr.c
@@ -32,11 +32,6 @@
  * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
 */
=20
-/*
- * There are duplicates of this code in:
- *  - tools/blktap2/drivers/hashtable_itr.c
- */
-
 #include "hashtable.h"
 #include "hashtable_private.h"
 #include "hashtable_itr.h"
diff --git a/tools/vtpm_manager/util/hashtable_itr.h
b/tools/vtpm_manager/util/hashtable_itr.h
--- a/tools/vtpm_manager/util/hashtable_itr.h
+++ b/tools/vtpm_manager/util/hashtable_itr.h
@@ -32,11 +32,6 @@
  * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
 */
=20
-/*
- * There are duplicates of this code in:
- *  - tools/blktap2/drivers/hashtable_itr.h
- */
-
=20
 #ifndef __HASHTABLE_ITR_CWC22__
 #define __HASHTABLE_ITR_CWC22__
diff --git a/tools/vtpm_manager/util/hashtable_private.h
b/tools/vtpm_manager/util/hashtable_private.h
--- a/tools/vtpm_manager/util/hashtable_private.h
+++ b/tools/vtpm_manager/util/hashtable_private.h
@@ -32,12 +32,6 @@
  * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
 */
=20
-/*
- * There are duplicates of this code in:
- *  - tools/xenstore/hashtable_private.h
- *  - tools/blktap2/drivers/hashtable_private.h
- */
-
 #ifndef __HASHTABLE_PRIVATE_CWC22_H__
 #define __HASHTABLE_PRIVATE_CWC22_H__
=20
diff --git a/tools/vtpm_manager/util/log.c b/tools/vtpm_manager/util/log.=
c
--- a/tools/vtpm_manager/util/log.c
+++ b/tools/vtpm_manager/util/log.c
@@ -38,6 +38,17 @@
 #include "buffer.h"
 #include "tcg.h"
=20
+char *module_names[] =3D { "",
+                                "CRYPTO",
+                                "BSG",
+                                "TXDATA",
+                                "TCS",
+                                "TCS",
+                                "VTSP",
+                                "VTPM",
+                                "VTPM",
+                                "VTSP"
+                              };
 // Helper code for the consts, eg. to produce messages for error codes.
=20
 typedef struct error_code_entry_t {
diff --git a/tools/vtpm_manager/util/log.h b/tools/vtpm_manager/util/log.=
h
--- a/tools/vtpm_manager/util/log.h
+++ b/tools/vtpm_manager/util/log.h
@@ -36,6 +36,8 @@
=20
 #include <stdint.h>             // for uint32_t
 #include <stddef.h>             // for pointer NULL
+#include <stdio.h>
+#include <tcg.h>
=20
 // =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D LOGGING =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
=20
@@ -50,17 +52,7 @@
 #define VTPM_LOG_VTPM_DEEP   8
 #define VTPM_LOG_VTSP_DEEP   9
=20
-static char *module_names[] =3D { "",
-                                "CRYPTO",
-                                "BSG",
-                                "TXDATA",
-                                "TCS",
-                                "TCS",
-                                "VTSP",
-                                "VTPM",
-                                "VTPM",
-                                "VTSP"
-                              };
+extern char *module_names[];
=20
 // Default to standard logging
 #ifndef LOGGING_MODULES
diff --git a/tools/vtpm_manager/util/tcg.h b/tools/vtpm_manager/util/tcg.=
h
--- a/tools/vtpm_manager/util/tcg.h
+++ b/tools/vtpm_manager/util/tcg.h
@@ -197,6 +197,7 @@ typedef struct pack_buf_t {
   UINT32 size;
   BYTE * data;
 } pack_buf_t;
+#define NULL_PACK_BUF {0,0}
=20
 typedef struct pack_constbuf_t {
   UINT32 size;
@@ -295,6 +296,35 @@ typedef struct pack_constbuf_t {
 #define TPM_ORD_LoadKeyContext           (181UL + TPM_PROTECTED_ORDINAL)=

 #define TPM_ORD_SaveAuthContext          (182UL + TPM_PROTECTED_ORDINAL)=

 #define TPM_ORD_LoadAuthContext          (183UL + TPM_PROTECTED_ORDINAL)=

+#define TPM_ORD_SaveContext                      (184UL +
TPM_PROTECTED_ORDINAL)
+#define TPM_ORD_LoadContext                      (185UL +
TPM_PROTECTED_ORDINAL)
+#define TPM_ORD_FlushSpecific                    (186UL +
TPM_PROTECTED_ORDINAL)
+#define TPM_ORD_PCR_Reset                        (200UL +
TPM_PROTECTED_ORDINAL)
+#define TPM_ORD_NV_DefineSpace                   (204UL +
TPM_PROTECTED_ORDINAL)
+#define TPM_ORD_NV_WriteValue                    (205UL +
TPM_PROTECTED_ORDINAL)
+#define TPM_ORD_NV_WriteValueAuth                (206UL +
TPM_PROTECTED_ORDINAL)
+#define TPM_ORD_NV_ReadValue                     (207UL +
TPM_PROTECTED_ORDINAL)
+#define TPM_ORD_NV_ReadValueAuth                 (208UL +
TPM_PROTECTED_ORDINAL)
+#define TPM_ORD_Delegate_UpdateVerification      (209UL +
TPM_PROTECTED_ORDINAL)
+#define TPM_ORD_Delegate_Manage                  (210UL +
TPM_PROTECTED_ORDINAL)
+#define TPM_ORD_Delegate_CreateKeyDelegation     (212UL +
TPM_PROTECTED_ORDINAL)
+#define TPM_ORD_Delegate_CreateOwnerDelegation   (213UL +
TPM_PROTECTED_ORDINAL)
+#define TPM_ORD_Delegate_VerifyDelegation        (214UL +
TPM_PROTECTED_ORDINAL)
+#define TPM_ORD_Delegate_LoadOwnerDelegation     (216UL +
TPM_PROTECTED_ORDINAL)
+#define TPM_ORD_Delegate_ReadAuth                (217UL +
TPM_PROTECTED_ORDINAL)
+#define TPM_ORD_Delegate_ReadTable               (219UL +
TPM_PROTECTED_ORDINAL)
+#define TPM_ORD_CreateCounter                    (220UL +
TPM_PROTECTED_ORDINAL)
+#define TPM_ORD_IncrementCounter                 (221UL +
TPM_PROTECTED_ORDINAL)
+#define TPM_ORD_ReadCounter                      (222UL +
TPM_PROTECTED_ORDINAL)
+#define TPM_ORD_ReleaseCounter                   (223UL +
TPM_PROTECTED_ORDINAL)
+#define TPM_ORD_ReleaseCounterOwner              (224UL +
TPM_PROTECTED_ORDINAL)
+#define TPM_ORD_EstablishTransport               (230UL +
TPM_PROTECTED_ORDINAL)
+#define TPM_ORD_ExecuteTransport                 (231UL +
TPM_PROTECTED_ORDINAL)
+#define TPM_ORD_ReleaseTransportSigned           (232UL +
TPM_PROTECTED_ORDINAL)
+#define TPM_ORD_GetTicks                         (241UL +
TPM_PROTECTED_ORDINAL)
+#define TPM_ORD_TickStampBlob                    (242UL +
TPM_PROTECTED_ORDINAL)
+#define TPM_ORD_MAX                              (256UL +
TPM_PROTECTED_ORDINAL)
+
 #define TSC_ORD_PhysicalPresence         (10UL + TPM_CONNECTION_ORDINAL)=

=20
=20
@@ -419,8 +449,16 @@ typedef struct pack_constbuf_t {
 /// TPM_ResourceTypes
 #define TPM_RT_KEY      0x00000001
 #define TPM_RT_AUTH     0x00000002
+#define TPM_RT_HASH     0x00000003
 #define TPM_RT_TRANS    0x00000004
 #define TPM_RT_CONTEXT  0x00000005
+#define TPM_RT_COUNTER  0x00000006
+#define TPM_RT_DELEGATE 0x00000007
+#define TPM_RT_DAA_TPM  0x00000008
+#define TPM_RT_DAA_V0   0x00000009
+#define TPM_RT_DAA_V1   0x0000000A
+
+
=20
 // TPM_PROTOCOL_ID values
 #define TPM_PID_OIAP 0x0001
@@ -447,6 +485,64 @@ typedef struct pack_constbuf_t {
 #define TPM_SS_RSASSAPKCS1v15_SHA1 0x0002
 #define TPM_SS_RSASSAPKCS1v15_DER 0x0003
=20
+/*
+ * TPM_CAPABILITY_AREA Values for TPM_GetCapability ([TPM_Part2],
Section 21.1)
+ */
+#define TPM_CAP_ORD                     0x00000001
+#define TPM_CAP_ALG                     0x00000002
+#define TPM_CAP_PID                     0x00000003
+#define TPM_CAP_FLAG                    0x00000004
+#define TPM_CAP_PROPERTY                0x00000005
+#define TPM_CAP_VERSION                 0x00000006
+#define TPM_CAP_KEY_HANDLE              0x00000007
+#define TPM_CAP_CHECK_LOADED            0x00000008
+#define TPM_CAP_SYM_MODE                0x00000009
+#define TPM_CAP_KEY_STATUS              0x0000000C
+#define TPM_CAP_NV_LIST                 0x0000000D
+#define TPM_CAP_MFR                     0x00000010
+#define TPM_CAP_NV_INDEX                0x00000011
+#define TPM_CAP_TRANS_ALG               0x00000012
+#define TPM_CAP_HANDLE                  0x00000014
+#define TPM_CAP_TRANS_ES                0x00000015
+#define TPM_CAP_AUTH_ENCRYPT            0x00000017
+#define TPM_CAP_SELECT_SIZE             0x00000018
+#define TPM_CAP_DA_LOGIC                0x00000019
+#define TPM_CAP_VERSION_VAL             0x0000001A
+
+/* subCap definitions ([TPM_Part2], Section 21.2) */
+#define TPM_CAP_PROP_PCR                0x00000101
+#define TPM_CAP_PROP_DIR                0x00000102
+#define TPM_CAP_PROP_MANUFACTURER       0x00000103
+#define TPM_CAP_PROP_KEYS               0x00000104
+#define TPM_CAP_PROP_MIN_COUNTER        0x00000107
+#define TPM_CAP_FLAG_PERMANENT          0x00000108
+#define TPM_CAP_FLAG_VOLATILE           0x00000109
+#define TPM_CAP_PROP_AUTHSESS           0x0000010A
+#define TPM_CAP_PROP_TRANSESS           0x0000010B
+#define TPM_CAP_PROP_COUNTERS           0x0000010C
+#define TPM_CAP_PROP_MAX_AUTHSESS       0x0000010D
+#define TPM_CAP_PROP_MAX_TRANSESS       0x0000010E
+#define TPM_CAP_PROP_MAX_COUNTERS       0x0000010F
+#define TPM_CAP_PROP_MAX_KEYS           0x00000110
+#define TPM_CAP_PROP_OWNER              0x00000111
+#define TPM_CAP_PROP_CONTEXT            0x00000112
+#define TPM_CAP_PROP_MAX_CONTEXT        0x00000113
+#define TPM_CAP_PROP_FAMILYROWS         0x00000114
+#define TPM_CAP_PROP_TIS_TIMEOUT        0x00000115
+#define TPM_CAP_PROP_STARTUP_EFFECT     0x00000116
+#define TPM_CAP_PROP_DELEGATE_ROW       0x00000117
+#define TPM_CAP_PROP_MAX_DAASESS        0x00000119
+#define TPM_CAP_PROP_DAASESS            0x0000011A
+#define TPM_CAP_PROP_CONTEXT_DIST       0x0000011B
+#define TPM_CAP_PROP_DAA_INTERRUPT      0x0000011C
+#define TPM_CAP_PROP_SESSIONS           0x0000011D
+#define TPM_CAP_PROP_MAX_SESSIONS       0x0000011E
+#define TPM_CAP_PROP_CMK_RESTRICTION    0x0000011F
+#define TPM_CAP_PROP_DURATION           0x00000120
+#define TPM_CAP_PROP_ACTIVE_COUNTER     0x00000122
+#define TPM_CAP_PROP_MAX_NV_AVAILABLE   0x00000123
+#define TPM_CAP_PROP_INPUT_BUFFER       0x00000124
+
 // TPM_KEY_USAGE values
 #define TPM_KEY_EK 0x0000
 #define TPM_KEY_SIGNING 0x0010
diff --git a/tools/vtpm_manager/vtpmconnd/Makefile
b/tools/vtpm_manager/vtpmconnd/Makefile
--- /dev/null
+++ b/tools/vtpm_manager/vtpmconnd/Makefile
@@ -0,0 +1,30 @@
+# Copyright (c) 2010-2012 United States Government, as represented by
+# the Secretary of Defense.  All rights reserved.
+#
+# THIS SOFTWARE AND ITS DOCUMENTATION ARE PROVIDED AS IS AND WITHOUT
+# ANY EXPRESS OR IMPLIED WARRANTIES WHATSOEVER. ALL WARRANTIES
+# INCLUDING, BUT NOT LIMITED TO, PERFORMANCE, MERCHANTABILITY, FITNESS
+# FOR A PARTICULAR  PURPOSE, AND NONINFRINGEMENT ARE HEREBY
+# DISCLAIMED. USERS ASSUME THE ENTIRE RISK AND LIABILITY OF USING THE
+# SOFTWARE.
+#
+
+XEN_ROOT =3D $(realpath ../../..)
+include ../Rules.mk
+
+BIN=3Dvtpmconnd
+OBJS=3Dvtpmconnd.o
+CFLAGS=3D-O2 -Wall
+
+all: ${BIN}
+
+${BIN}: ${OBJS}
+    gcc -o $@ $<
+
+install: ${BIN}
+    install -m 0755 ${BIN} $(DESTDIR)$(BINDIR)/$(BIN)
+
+.PHONY: mrproper
+mrproper: clean
+clean:
+    -rm ${BIN} ${OBJS}
diff --git a/tools/vtpm_manager/vtpmconnd/vtpmconnd.c
b/tools/vtpm_manager/vtpmconnd/vtpmconnd.c
--- /dev/null
+++ b/tools/vtpm_manager/vtpmconnd/vtpmconnd.c
@@ -0,0 +1,253 @@
+/*
+ * Copyright (c) 2010-2012 United States Government, as represented by
+ * the Secretary of Defense.  All rights reserved.
+ *
+ * THIS SOFTWARE AND ITS DOCUMENTATION ARE PROVIDED AS IS AND WITHOUT
+ * ANY EXPRESS OR IMPLIED WARRANTIES WHATSOEVER. ALL WARRANTIES
+ * INCLUDING, BUT NOT LIMITED TO, PERFORMANCE, MERCHANTABILITY, FITNESS
+ * FOR A PARTICULAR  PURPOSE, AND NONINFRINGEMENT ARE HEREBY
+ * DISCLAIMED. USERS ASSUME THE ENTIRE RISK AND LIABILITY OF USING THE
+ * SOFTWARE.
+ */
+
+#include <stdio.h>
+#include <string.h>
+#include <errno.h>
+#include <getopt.h>
+#include <stdint.h>
+#include <unistd.h>
+#include <fcntl.h>
+#include <signal.h>
+#include <ctype.h>
+#include "../manager/vtpm_manager.h"
+
+#define VTPM_BE "/dev/vtpm"
+#define TPM_DEV "/dev/tpm0"
+#define MAX_CMD 4096
+#define DEVNULL "/dev/null"
+#define TPM_SUCCESS_RESP "\x00\x00\x00\x00" "\x01\xC1"
"\x00\x00\x00\x00" "\x00\x00\x00\x00"
+#define TPM_SUCCESS_RESPLEN 14
+
+static int quit =3D 0;
+
+struct Opts {
+   const char* vtpmbe;
+   const char* tpmdev;
+   int verbosity;
+   int daemon;
+};
+
+struct Opts opts =3D {
+   .vtpmbe =3D VTPM_BE,
+   .tpmdev =3D TPM_DEV,
+   .verbosity =3D 0,
+   .daemon =3D 1,
+};
+
+void usage(char* argv0) {
+fprintf(stderr, "Usage:\n \
+\t%s [options] [tpm device node]\n\
+\n\
+-h\t\tdisplay usage message\n\
+-v\t\tturn up verbosity level\n\
+-t <FILE>\tuse FILE for tpm device (default " TPM_DEV ")\n\
+-b <FILE>\tset vtpm backend device to FILE (default: " VTPM_BE ")\n\
+-f\t\trun in the foreground\n",
+argv0
+);
+}
+
+void sighandler(int signum) {
+   quit =3D 1;
+}
+
+int main_loop(int vbefd, int tpmfd) {
+   uint8_t buf[MAX_CMD];
+   ssize_t size, wrote;
+   int i;
+
+   while(!quit) {
+      /* Wait for cmd from vtpm_manager */
+      if((size =3D read(vbefd, buf, MAX_CMD)) < 0) {
+     if(errno =3D=3D EFAULT) {
+        if(opts.verbosity > 0) {
+           fprintf(stderr, "read() failed with error: %s, non-fatal\n",
strerror(errno));
+        }
+        continue;
+     }
+     fprintf(stderr,"Error reading from %s, (%s)\n", opts.vtpmbe,
strerror(errno));
+     return 1;
+      }
+      if(opts.verbosity > 0) {
+     printf("\nvtpm_manager req(%ld):", (long) size);
+     for(i =3D 0; i < size; ++i) {
+        printf(" %02X", buf[i]);
+     }
+     printf("\n");
+      }
+
+      if(quit) {
+     break;
+      }
+
+      /* Forward the cmd to the tpm, exclude the dmi id */
+      if((wrote =3D write(tpmfd, buf + 4, size - 4)) !=3D size - 4) {
+     fprintf(stderr,"Error writing to %s, (%s)\n", opts.tpmdev,
strerror(errno));
+     return 1;
+      }
+
+      if(quit) {
+     break;
+      }
+
+      /* Wait for response from tpm */
+      if((size =3D read(tpmfd, buf + 4, MAX_CMD - 4)) < 0) {
+     fprintf(stderr,"Error reading from %s, (%s)\n", opts.tpmdev,
strerror(errno));
+     return 1;
+      }
+      if(opts.verbosity > 0) {
+     printf("tpm resp(%ld):", (long) size);
+     for(i =3D 0; i < size + 4; ++i) {
+        printf(" %02X", buf[i]);
+     }
+     printf("\n");
+      }
+
+      if(quit) {
+     break;
+      }
+
+      /* Send response back to vtpm_manager */
+      if((wrote =3D write(vbefd, buf, size + 4)) !=3D size + 4) {
+     fprintf(stderr, "Error writing to %s, (%s)\n", opts.vtpmbe,
strerror(errno));
+     return 1;
+      }
+   }
+
+   return 0;
+
+}
+
+int main(int argc, char** argv)
+{
+   int rc;
+   int vbefd, tpmfd;
+   int c;
+   int fd =3D -1;
+   struct sigaction sig;
+   pid_t pid;
+
+   /* Do cmdline opts */
+   opterr =3D 0;
+
+   while ((c =3D getopt (argc, argv, "hfvb:t:")) !=3D -1)
+   {
+      switch (c)
+      {
+     case 'h':
+        usage(argv[0]);
+        return 0;
+     case 'f':
+        opts.daemon =3D 0;
+        break;
+     case 'v':
+        ++opts.verbosity;
+        break;
+     case 'b':
+        opts.vtpmbe =3D optarg;
+        break;
+     case 't':
+        opts.tpmdev =3D optarg;
+        break;
+     case '?':
+        if (optopt =3D=3D 'c')
+           fprintf (stderr, "Option -%c requires an argument.\n", optopt=
);
+        else if (isprint (optopt))
+           fprintf (stderr, "Unknown option `-%c'.\n", optopt);
+        else
+           fprintf (stderr,
+             "Unknown option character `\\x%x'.\n",
+             optopt);
+            usage(argv[0]);
+        return 1;
+     default:
+        return 1;
+      }
+   }
+
+   /* DAEMONIZE */
+   if(opts.daemon) {
+      pid =3D fork();
+      if(pid < 0) {
+     fprintf(stderr, "failed to daemonize! fork() failed : %s\n",
strerror(errno));
+     return 1;
+      }
+
+      if (pid > 0) {
+     return 0;
+      }
+   }
+
+
+   /* SIGNAL HANDLING */
+   sig.sa_handler =3D sighandler;
+   sigemptyset(&sig.sa_mask);
+   sig.sa_flags =3D 0;
+
+   sigaction(SIGINT, &sig, NULL);
+   sigaction(SIGQUIT, &sig, NULL);
+   sigaction(SIGTERM, &sig, NULL);
+
+   /* FAKE OUT THE HOTPLUG SYSTEM */
+   /* Whenever hotplug writes a message let it go to dev null */
+   if(remove(VTPM_RX_HP_FNAME) !=3D 0 && errno !=3D ENOENT) {
+      fprintf(stderr, "Unable to remove %s : %s\n", VTPM_RX_HP_FNAME,
strerror(errno));
+      return -1;
+   }
+   if(symlink(DEVNULL, VTPM_RX_HP_FNAME) !=3D 0) {
+      fprintf(stderr, "Unable to create symlink %s -> %s : %s\n",
VTPM_RX_HP_FNAME, DEVNULL, strerror(errno));
+   }
+
+   /* Whenever hotplug tries to read a response, always return success *=
/
+   if(remove(VTPM_TX_HP_FNAME) !=3D 0 && errno !=3D ENOENT) {
+      fprintf(stderr, "Unable to remove %s : %s\n", VTPM_TX_HP_FNAME,
strerror(errno));
+      return -1;
+   }
+   if((fd =3D open(VTPM_TX_HP_FNAME, O_CREAT | O_WRONLY, S_IRUSR |
S_IWUSR)) < 0) {
+      fprintf(stderr, "Unable to open %s for writing : %s\n",
VTPM_TX_HP_FNAME, strerror(errno));
+      return -1;
+   }
+   if(write(fd, TPM_SUCCESS_RESP, TPM_SUCCESS_RESPLEN) !=3D
TPM_SUCCESS_RESPLEN) {
+      fprintf(stderr, "Unable to write to %s : %s\n", VTPM_TX_HP_FNAME,
strerror(errno));
+      return -1;
+   }
+   close(fd);
+   /* HOTPLUG FAKE OUT DONE */
+
+   /* Open the backend and tpm device */
+   if((vbefd =3D open(opts.vtpmbe, O_RDWR)) < 0) {
+      fprintf(stderr, "Unable to open `%s', (%s)\n", opts.vtpmbe,
strerror(errno));
+      return 1;
+   }
+   if((tpmfd =3D open(opts.tpmdev, O_RDWR)) < 0) {
+      fprintf(stderr, "Unable to open `%s', (%s)\n", opts.tpmdev,
strerror(errno));
+      return 1;
+   }
+   if(opts.verbosity > 0) {
+      fprintf(stderr, "Connected to vtpm backend: %s\n", opts.vtpmbe);
+      fprintf(stderr, "Connected to tpm: %s\n", opts.tpmdev);
+   }
+
+   rc =3D main_loop(vbefd, tpmfd);
+
+   close(vbefd);
+   close(tpmfd);
+
+   remove(VTPM_RX_HP_FNAME);
+   remove(VTPM_TX_HP_FNAME);
+
+
+   return rc;
+
+
+}
diff --git a/tools/vtpm_manager/vtpmmgrtalk/Makefile
b/tools/vtpm_manager/vtpmmgrtalk/Makefile
--- /dev/null
+++ b/tools/vtpm_manager/vtpmmgrtalk/Makefile
@@ -0,0 +1,35 @@
+# Copyright (c) 2010-2012 United States Government, as represented by
+# the Secretary of Defense.  All rights reserved.
+#
+# THIS SOFTWARE AND ITS DOCUMENTATION ARE PROVIDED AS IS AND WITHOUT
+# ANY EXPRESS OR IMPLIED WARRANTIES WHATSOEVER. ALL WARRANTIES
+# INCLUDING, BUT NOT LIMITED TO, PERFORMANCE, MERCHANTABILITY, FITNESS
+# FOR A PARTICULAR  PURPOSE, AND NONINFRINGEMENT ARE HEREBY
+# DISCLAIMED. USERS ASSUME THE ENTIRE RISK AND LIABILITY OF USING THE
+# SOFTWARE.
+#
+
+XEN_ROOT =3D $(realpath ../../..)
+include ../Rules.mk
+
+BIN=3Dvtpmmgrtalk
+OBJS=3Dvtpmmgrtalk.o
+CFLAGS=3D-Wall -O2 -g
+CFLAGS +=3D -I../crypto
+CFLAGS +=3D -I../util
+CFLAGS +=3D -I../tcs
+CFLAGS +=3D -I../manager
+
+
+all: ${BIN}
+
+${BIN}: ${OBJS}
+    gcc -o $@ $<
+
+install: all
+    install -m 0755 ${BIN} $(DESTDIR)$(BINDIR)/$(BIN)
+
+.PHONY: mrproper
+mrproper: clean
+clean:
+    rm -f ${BIN} ${OBJS}
diff --git a/tools/vtpm_manager/vtpmmgrtalk/vtpmmgrtalk.c
b/tools/vtpm_manager/vtpmmgrtalk/vtpmmgrtalk.c
--- /dev/null
+++ b/tools/vtpm_manager/vtpmmgrtalk/vtpmmgrtalk.c
@@ -0,0 +1,105 @@
+/*
+ * Copyright (c) 2010-2012 United States Government, as represented by
+ * the Secretary of Defense.  All rights reserved.
+ *
+ * THIS SOFTWARE AND ITS DOCUMENTATION ARE PROVIDED AS IS AND WITHOUT
+ * ANY EXPRESS OR IMPLIED WARRANTIES WHATSOEVER. ALL WARRANTIES
+ * INCLUDING, BUT NOT LIMITED TO, PERFORMANCE, MERCHANTABILITY, FITNESS
+ * FOR A PARTICULAR  PURPOSE, AND NONINFRINGEMENT ARE HEREBY
+ * DISCLAIMED. USERS ASSUME THE ENTIRE RISK AND LIABILITY OF USING THE
+ * SOFTWARE.
+ */
+#include <unistd.h>
+#include <fcntl.h>
+#include <sys/file.h>
+#include <stdio.h>
+#include <errno.h>
+#include <string.h>
+#include <stdint.h>
+
+#include "../manager/vtpm_manager.h"
+
+int main(int argc, char** argv) {
+   int wfd, rfd;
+   uint8_t buf[COMMAND_BUFFER_SIZE];
+   ssize_t size;
+   int i, c;
+   int rc =3D 0;
+
+   const char* wfile =3D VTPM_RX_HP_FNAME;
+   const char* rfile =3D VTPM_TX_HP_FNAME;
+
+   /* Open for writing in non-blocking mode and exit if
+    * the manager is not waiting on the other side */
+   if((wfd =3D open(wfile, O_WRONLY | O_NONBLOCK)) < 0) {
+      fprintf(stderr, "Error opening %s for writing : %s\n",
wfile,strerror(errno));
+      return 1;
+   }
+   /* Set the pipe back to blocking mode */
+   fcntl(wfd, F_SETFL, 0);
+
+   /* Open the read pipe */
+   if((rfd =3D open(rfile, O_RDONLY)) < 0) {
+      close(wfd);
+      fprintf(stderr, "Error opening %s for reading : %s\n",
rfile,strerror(errno));
+      return 1;
+   }
+
+   /*Grab the ASCII hex input from stdin and convert to binary */
+   for(i =3D 0; i < COMMAND_BUFFER_SIZE; ++i) {
+      c =3D scanf("%02hhX", buf + i);
+      if(c =3D=3D EOF) {
+     break;
+      } else if ( c !=3D 1) {
+     fprintf(stderr, "Malformed Input! Use ASCII hex!\n");
+     rc =3D 1;
+     goto quit;
+      }
+   }
+   size =3D i;
+
+   /* Send request to the manager only if a request was actually given *=
/
+   if(size > 0) {
+      /* Lock the pipes for reading/writing */
+      if(flock(wfd, LOCK_EX)) {
+     fprintf(stderr, "Unable to lock %s : %s\n", wfile, strerror(errno))=
;
+     rc =3D 1;
+     goto quit;
+      }
+      if(flock(rfd, LOCK_EX)) {
+     fprintf(stderr, "Unable to lock %s : %s\n", wfile, strerror(errno))=
;
+     rc =3D 1;
+     goto quit;
+      }
+
+      /* Write the binary data to the pipe */
+      if(write(wfd, buf, size) !=3D size) {
+     fprintf(stderr, "Error writing to %s : %s\n", wfile, strerror(errno=
));
+     rc =3D 1;
+     goto quit;
+      }
+
+      /* Read the response from the manager */
+      size =3D read(rfd, buf, COMMAND_BUFFER_SIZE);
+      if(size < 0) {
+     fprintf(stderr, "Error reading %s : %s\n", rfile, strerror(errno));=

+     rc =3D 1;
+     goto quit;
+      }
+      /* Output the hex */
+      for(i =3D 0; i < size; ++i) {
+     printf("%02X", buf[i]);
+      }
+      fprintf(stderr,"\n");
+
+      /* Unlock the pipes */
+      flock(rfd, LOCK_UN);
+      flock(wfd, LOCK_UN);
+   }
+
+   rc =3D 0;
+quit:
+   close(rfd);
+   close(wfd);
+   return rc;
+}



--------------ms010302090205070800070309
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIDyjCC
A8YwggMvoAMCAQICBD/xyf0wDQYJKoZIhvcNAQEFBQAwLzELMAkGA1UEBhMCVVMxDzANBgNV
BAoTBkpIVUFQTDEPMA0GA1UECxMGQklTRENBMB4XDTEwMDYxMTE4MjIwNloXDTEzMDYxMTE4
NTIwNlowZjELMAkGA1UEBhMCVVMxDzANBgNVBAoTBkpIVUFQTDEPMA0GA1UECxMGUGVvcGxl
MTUwFgYDVQQLEw9WUE5Hcm91cC1CSVNEQ0EwGwYDVQQDExRNYXR0aGV3IEUgRmlvcmF2YW50
ZTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAnpbwVSP6o1Nb5lcW7dd3yTo9iBJdi7qz
4nANOMFPK7JOy5npKN1iiousl28U/scUJES55gPwAWYJK3uVyQAsA4adgDKi5DoD1UHDQEwp
bY7iHLJeq0NPr4BqYNqnCFPbE6HC8zSJrr4qKn+gVUQT39SIFqdiIPJwZL8FYTRQ/zsCAwEA
AaOCAbYwggGyMAsGA1UdDwQEAwIHgDArBgNVHRAEJDAigA8yMDEwMDYxMTE4MjIwNlqBDzIw
MTIwNzE3MjI1MjA2WjAbBg0rBgEEAbMlCwMBAQEBBAoWCGZpb3JhbWUxMBsGDSsGAQQBsyUL
AwEBAQIEChIIMDAxMDQyNjEwWAYJYIZIAYb6ax4BBEsMSVRoZSBwcml2YXRlIGtleSBjb3Jy
ZXNwb25kaW5nIHRvIHRoaXMgY2VydGlmaWNhdGUgbWF5IGhhdmUgYmVlbiBleHBvcnRlZC4w
KAYDVR0RBCEwH4EdTWF0dGhldy5GaW9yYXZhbnRlQGpodWFwbC5lZHUwUgYDVR0fBEswSTBH
oEWgQ6RBMD8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJU0RD
QTEOMAwGA1UEAxMFQ1JMNTYwHwYDVR0jBBgwFoAUCDUpmxH52EU2CyWmF2EJMB1yqeswHQYD
VR0OBBYEFO6LYxg6r9wHZ+zdQtBHn1dZ/YTNMAkGA1UdEwQCMAAwGQYJKoZIhvZ9B0EABAww
ChsEVjcuMQMCBLAwDQYJKoZIhvcNAQEFBQADgYEAJO9HQh4YNChVLzuZqK5ARJARD8JoujGZ
fdo75quvg2jXFQe2sEjvLnxJZgm/pv8fdZakq48CWwjYHKuvIp7sDjTEsQfo+y7SpN/N2NvJ
WU5SqfK1VgYtNLRRoGJUB5Q1aZ+Dg95g3kqpyfpUMISJL8IKVLtJVfN4fggFVUYZ9wwxggGr
MIIBpwIBATA3MC8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJ
U0RDQQIEP/HJ/TAJBgUrDgMCGgUAoIHLMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ
KoZIhvcNAQkFMQ8XDTEyMDkyMTE4NTcxMVowIwYJKoZIhvcNAQkEMRYEFKPbujyMaoD5Y/bw
vdjKJ+sfR8uVMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAK
BggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI
KoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEgYAy62HJSShxKuwnVe5wH8mywUyWOUYtBWIT
JX3Gayph3FS8wW1gBX3XvFcHGxT2B+wqKKl7pKppwgXNuoHETxxnQk/GL4hHPAy40ErilrZr
9NV3V8HG43ti05+B9GhjWQTskih2BxQ4IGUOcMhBL2agyfj1ICxzDnyLtpiR3Yn21QAAAAAA
AA==
--------------ms010302090205070800070309--


--===============1454697601346146772==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============1454697601346146772==--


From xen-devel-bounces@lists.xen.org Fri Sep 21 19:01:27 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Sep 2012 19:01:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TF8TQ-0001k7-2y; Fri, 21 Sep 2012 19:01:12 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <matthew.fioravante@jhuapl.edu>) id 1TF8TO-0001jp-6i
	for xen-devel@lists.xensource.com; Fri, 21 Sep 2012 19:01:10 +0000
X-Env-Sender: matthew.fioravante@jhuapl.edu
X-Msg-Ref: server-13.tower-27.messagelabs.com!1348254057!10824585!1
X-Originating-IP: [128.244.251.36]
X-SpamReason: No, hits=0.0 required=7.0 tests=UNPARSEABLE_RELAY
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 600 invoked from network); 21 Sep 2012 19:00:58 -0000
Received: from pilot.jhuapl.edu (HELO jhuapl.edu) (128.244.251.36)
	by server-13.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 21 Sep 2012 19:00:58 -0000
Received: from ([128.244.207.89])
	by pilot.jhuapl.edu with ESMTP with TLS id 63GHCH1.153409181;
	Fri, 21 Sep 2012 15:00:52 -0400
Message-ID: <505CB918.3030108@jhuapl.edu>
Date: Fri, 21 Sep 2012 14:59:36 -0400
From: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120827 Thunderbird/15.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>, 
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
X-Enigmail-Version: 1.4.4
Subject: [Xen-devel] PATCH [base vtpm and libxl patches 3/6] Fix bugs in
 vtpm 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: multipart/mixed; boundary="===============5118848930475565357=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a cryptographically signed message in MIME format.

--===============5118848930475565357==
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms090205080600060307050201"

This is a cryptographically signed message in MIME format.

--------------ms090205080600060307050201
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

This patch fixes IO deadlocks in the vtpm hotplug scripts.

Signed off by: Matthew Fioravante matthew.fioravante@jhuapl.edu

---
Changed since previous:
* rebased off of latest xen stable
* replaced instances of gawk with awk

diff --git a/tools/hotplug/Linux/vtpm b/tools/hotplug/Linux/vtpm
--- a/tools/hotplug/Linux/vtpm
+++ b/tools/hotplug/Linux/vtpm
@@ -1,22 +1,18 @@
 #!/bin/bash
=20
+export PATH=3D$PATH:/usr/sbin:/sbin
+
 dir=3D$(dirname "$0")
 . "$dir/vtpm-hotplug-common.sh"
=20
-vtpm_fatal_error=3D0
-
 case "$command" in
   add)
     vtpm_create_instance
+    success
   ;;
   remove)
     vtpm_remove_instance
+    success
   ;;
 esac
=20
-if [ $vtpm_fatal_error -eq 0 ]; then
-    log debug "Successful vTPM operation '$command'."
-    success
-else
-    fatal "Error while executing vTPM operation '$command'."
-fi
diff --git a/tools/hotplug/Linux/vtpm-common.sh
b/tools/hotplug/Linux/vtpm-common.sh
--- a/tools/hotplug/Linux/vtpm-common.sh
+++ b/tools/hotplug/Linux/vtpm-common.sh
@@ -276,12 +276,10 @@ function vtpm_create_instance () {
=20
         vtpm_create $instance
=20
-        if [ $vtpm_fatal_error -eq 0 ]; then
-            if [ "$uuid" !=3D "" ]; then
-                vtpmdb_add_instance $uuid $instance
-            else
-                vtpmdb_add_instance $domname $instance
-            fi
+        if [ "$uuid" !=3D "" ]; then
+            vtpmdb_add_instance $uuid $instance
+        else
+            vtpmdb_add_instance $domname $instance
         fi
     else
         if [ "$reason" =3D=3D "resume" ]; then
@@ -290,7 +288,6 @@ function vtpm_create_instance () {
             vtpm_start $instance
         fi
     fi
-
     release_lock vtpmdb
=20
     xenstore_write $XENBUS_PATH/instance $instance
@@ -322,8 +319,8 @@ function vtpm_remove_instance () {
     if [ "$instance" !=3D "0" ]; then
         vtpm_suspend $instance
     fi
-
     release_lock vtpmdb
+
 }
=20
=20
diff --git a/tools/hotplug/Linux/vtpm-delete
b/tools/hotplug/Linux/vtpm-delete
--- a/tools/hotplug/Linux/vtpm-delete
+++ b/tools/hotplug/Linux/vtpm-delete
@@ -5,6 +5,8 @@
 # or
 # vtpm-delete --vmname <vm name>
=20
+export PATH=3D$PATH:/usr/sbin:/sbin
+
 dir=3D$(dirname "$0")
 . "$dir/vtpm-common.sh"
=20
diff --git a/tools/hotplug/Linux/vtpm-impl b/tools/hotplug/Linux/vtpm-imp=
l
--- a/tools/hotplug/Linux/vtpm-impl
+++ b/tools/hotplug/Linux/vtpm-impl
@@ -32,14 +32,16 @@
 # OF THE POSSIBILITY OF SUCH DAMAGE.
 # =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
=20
-#            |        SRC        |    TAG  |      CMD SIZE     |      =20
ORD       |mtype|strt
-TPM_CMD_OPEN=3D\\x00\\x00\\x00\\x00\\x01\\xc1\\x00\\x00\\x00\\x11\\x01\\=
x00\\x00\\x01\\x01\\x01
-TPM_CMD_RESM=3D\\x00\\x00\\x00\\x00\\x01\\xc1\\x00\\x00\\x00\\x11\\x01\\=
x00\\x00\\x01\\x01\\x02
-TPM_CMD_CLOS=3D\\x00\\x00\\x00\\x00\\x01\\xc1\\x00\\x00\\x00\\x0e\\x01\\=
x00\\x00\\x02
-TPM_CMD_DELE=3D\\x00\\x00\\x00\\x00\\x01\\xc1\\x00\\x00\\x00\\x0e\\x01\\=
x00\\x00\\x03
+export PATH=3D$PATH:/usr/sbin:/sbin
=20
-TPM_TYPE_PVM=3D\\x01
-TPM_TYPE_HVM=3D\\x02
+#             | SRC  |TAG| CMD SZ|| ORD  |mtype|strt
+TPM_CMD_OPEN=3D"0000000001C100000011010000010101"
+TPM_CMD_RESM=3D"0000000001C100000011010000010102"
+TPM_CMD_CLOS=3D"0000000001C10000000E01000002"
+TPM_CMD_DELE=3D"0000000001C10000000E01000003"
+
+TPM_TYPE_PVM=3D01
+TPM_TYPE_HVM=3D02
=20
 TPM_SUCCESS=3D00000000
=20
@@ -70,24 +72,19 @@ function vtpm_manager_cmd() {
  local inst=3D$2;
  local inst_bin=3D$(hex32_to_bin $inst);
=20
- claim_lock vtpm_mgr
-
- #send cmd to vtpm_manager
- printf "$cmd$inst_bin" > $TX_VTPM_MANAGER
-
- #recv response
- set +e
- local resp_hex=3D`dd skip=3D10 bs=3D1 count=3D4 if=3D$RX_VTPM_MANAGER 2=
>
/dev/null | xxd -ps`
- set -e
+ local resp_hex
+ #send cmd to vtpm_manager and get response
+ if ! resp_hex=3D`echo "$cmd$(str_to_hex32 $inst)" | vtpmmgrtalk `; then=

+   release_lock vtpmdb
+   fatal "Error communicating with vTPM Manager"
+ fi
=20
- release_lock vtpm_mgr
+ resp_hex=3D`echo $resp_hex | cut -b 21-`
=20
  #return whether the command was successful
- if [ $resp_hex -ne $TPM_SUCCESS ]; then
-   vtpm_fatal_error=3D1
-   false
-  else
-   true
+ if [ "$resp_hex" !=3D "$TPM_SUCCESS" ]; then
+   release_lock vtpmdb
+   fatal "vTPM Manager returned failure code $resp_hex"
  fi
 }
=20
@@ -142,13 +139,8 @@ function vtpm_suspend() {
=20
 function vtpm_delete() {
  local inst=3D$1
- if $(vtpm_manager_cmd $TPM_CMD_DELE $inst); then
-   rm -f /var/vtpm/vtpm_dm_$1.data
-   true
- else
-   vtpm_fatal_error=3D1
-   false
- fi
+ $(vtpm_manager_cmd $TPM_CMD_DELE $inst)
+ rm -f /var/vtpm/vtpm_dm_$1.data
 }
=20
 # Perform a migration step. This function differentiates between migrati=
on
diff --git a/tools/python/xen/xend/server/tpmif.py
b/tools/python/xen/xend/server/tpmif.py
--- a/tools/python/xen/xend/server/tpmif.py
+++ b/tools/python/xen/xend/server/tpmif.py
@@ -44,6 +44,22 @@ class TPMifController(DevController):
         DevController.__init__(self, vm)
=20
=20
+    def createDevice(self, config):
+        #Disable hotplug scripts if backend is not dom0
+        import xen.xend.XendDomain
+        xd =3D xen.xend.XendDomain.instance()
+        backdom_name =3D config.get('backend')
+        if backdom_name is None:
+            backdom =3D xen.xend.XendDomain.DOM0_ID
+        else:
+            bd =3D xd.domain_lookup_nr(backdom_name)
+            backdom =3D bd.getDomid()
+
+    if backdom !=3D xen.xend.XendDomain.DOM0_ID:
+       self.hotplug =3D False
+
+        return DevController.createDevice(self, config)
+
     def getDeviceDetails(self, config):
         """@see DevController.getDeviceDetails"""
=20



--------------ms090205080600060307050201
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIDyjCC
A8YwggMvoAMCAQICBD/xyf0wDQYJKoZIhvcNAQEFBQAwLzELMAkGA1UEBhMCVVMxDzANBgNV
BAoTBkpIVUFQTDEPMA0GA1UECxMGQklTRENBMB4XDTEwMDYxMTE4MjIwNloXDTEzMDYxMTE4
NTIwNlowZjELMAkGA1UEBhMCVVMxDzANBgNVBAoTBkpIVUFQTDEPMA0GA1UECxMGUGVvcGxl
MTUwFgYDVQQLEw9WUE5Hcm91cC1CSVNEQ0EwGwYDVQQDExRNYXR0aGV3IEUgRmlvcmF2YW50
ZTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAnpbwVSP6o1Nb5lcW7dd3yTo9iBJdi7qz
4nANOMFPK7JOy5npKN1iiousl28U/scUJES55gPwAWYJK3uVyQAsA4adgDKi5DoD1UHDQEwp
bY7iHLJeq0NPr4BqYNqnCFPbE6HC8zSJrr4qKn+gVUQT39SIFqdiIPJwZL8FYTRQ/zsCAwEA
AaOCAbYwggGyMAsGA1UdDwQEAwIHgDArBgNVHRAEJDAigA8yMDEwMDYxMTE4MjIwNlqBDzIw
MTIwNzE3MjI1MjA2WjAbBg0rBgEEAbMlCwMBAQEBBAoWCGZpb3JhbWUxMBsGDSsGAQQBsyUL
AwEBAQIEChIIMDAxMDQyNjEwWAYJYIZIAYb6ax4BBEsMSVRoZSBwcml2YXRlIGtleSBjb3Jy
ZXNwb25kaW5nIHRvIHRoaXMgY2VydGlmaWNhdGUgbWF5IGhhdmUgYmVlbiBleHBvcnRlZC4w
KAYDVR0RBCEwH4EdTWF0dGhldy5GaW9yYXZhbnRlQGpodWFwbC5lZHUwUgYDVR0fBEswSTBH
oEWgQ6RBMD8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJU0RD
QTEOMAwGA1UEAxMFQ1JMNTYwHwYDVR0jBBgwFoAUCDUpmxH52EU2CyWmF2EJMB1yqeswHQYD
VR0OBBYEFO6LYxg6r9wHZ+zdQtBHn1dZ/YTNMAkGA1UdEwQCMAAwGQYJKoZIhvZ9B0EABAww
ChsEVjcuMQMCBLAwDQYJKoZIhvcNAQEFBQADgYEAJO9HQh4YNChVLzuZqK5ARJARD8JoujGZ
fdo75quvg2jXFQe2sEjvLnxJZgm/pv8fdZakq48CWwjYHKuvIp7sDjTEsQfo+y7SpN/N2NvJ
WU5SqfK1VgYtNLRRoGJUB5Q1aZ+Dg95g3kqpyfpUMISJL8IKVLtJVfN4fggFVUYZ9wwxggGr
MIIBpwIBATA3MC8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJ
U0RDQQIEP/HJ/TAJBgUrDgMCGgUAoIHLMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ
KoZIhvcNAQkFMQ8XDTEyMDkyMTE4NTkzNlowIwYJKoZIhvcNAQkEMRYEFNS9Wbkgqt0VdTVF
PqBElVCCXpG3MGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAK
BggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI
KoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEgYBSEJrzcNkRMXqnsnuPA4b0cZIGe8anovqS
Lw5pcBa66gao51yCLr6dNDmd+y9b23PDSdot2ONLuvjJ+L/54oNGU52WxVMu5ckKIRFY8UwF
ndDB+2OvubpiYtkW/AMCLU9LDMTIkOhWlQQDTAWhgHi2xfD7XgVEVCb5dQHesPf56QAAAAAA
AA==
--------------ms090205080600060307050201--


--===============5118848930475565357==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============5118848930475565357==--


From xen-devel-bounces@lists.xen.org Fri Sep 21 19:01:27 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Sep 2012 19:01:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TF8TQ-0001k7-2y; Fri, 21 Sep 2012 19:01:12 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <matthew.fioravante@jhuapl.edu>) id 1TF8TO-0001jp-6i
	for xen-devel@lists.xensource.com; Fri, 21 Sep 2012 19:01:10 +0000
X-Env-Sender: matthew.fioravante@jhuapl.edu
X-Msg-Ref: server-13.tower-27.messagelabs.com!1348254057!10824585!1
X-Originating-IP: [128.244.251.36]
X-SpamReason: No, hits=0.0 required=7.0 tests=UNPARSEABLE_RELAY
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 600 invoked from network); 21 Sep 2012 19:00:58 -0000
Received: from pilot.jhuapl.edu (HELO jhuapl.edu) (128.244.251.36)
	by server-13.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 21 Sep 2012 19:00:58 -0000
Received: from ([128.244.207.89])
	by pilot.jhuapl.edu with ESMTP with TLS id 63GHCH1.153409181;
	Fri, 21 Sep 2012 15:00:52 -0400
Message-ID: <505CB918.3030108@jhuapl.edu>
Date: Fri, 21 Sep 2012 14:59:36 -0400
From: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120827 Thunderbird/15.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>, 
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
X-Enigmail-Version: 1.4.4
Subject: [Xen-devel] PATCH [base vtpm and libxl patches 3/6] Fix bugs in
 vtpm 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: multipart/mixed; boundary="===============5118848930475565357=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a cryptographically signed message in MIME format.

--===============5118848930475565357==
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms090205080600060307050201"

This is a cryptographically signed message in MIME format.

--------------ms090205080600060307050201
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

This patch fixes IO deadlocks in the vtpm hotplug scripts.

Signed off by: Matthew Fioravante matthew.fioravante@jhuapl.edu

---
Changed since previous:
* rebased off of latest xen stable
* replaced instances of gawk with awk

diff --git a/tools/hotplug/Linux/vtpm b/tools/hotplug/Linux/vtpm
--- a/tools/hotplug/Linux/vtpm
+++ b/tools/hotplug/Linux/vtpm
@@ -1,22 +1,18 @@
 #!/bin/bash
=20
+export PATH=3D$PATH:/usr/sbin:/sbin
+
 dir=3D$(dirname "$0")
 . "$dir/vtpm-hotplug-common.sh"
=20
-vtpm_fatal_error=3D0
-
 case "$command" in
   add)
     vtpm_create_instance
+    success
   ;;
   remove)
     vtpm_remove_instance
+    success
   ;;
 esac
=20
-if [ $vtpm_fatal_error -eq 0 ]; then
-    log debug "Successful vTPM operation '$command'."
-    success
-else
-    fatal "Error while executing vTPM operation '$command'."
-fi
diff --git a/tools/hotplug/Linux/vtpm-common.sh
b/tools/hotplug/Linux/vtpm-common.sh
--- a/tools/hotplug/Linux/vtpm-common.sh
+++ b/tools/hotplug/Linux/vtpm-common.sh
@@ -276,12 +276,10 @@ function vtpm_create_instance () {
=20
         vtpm_create $instance
=20
-        if [ $vtpm_fatal_error -eq 0 ]; then
-            if [ "$uuid" !=3D "" ]; then
-                vtpmdb_add_instance $uuid $instance
-            else
-                vtpmdb_add_instance $domname $instance
-            fi
+        if [ "$uuid" !=3D "" ]; then
+            vtpmdb_add_instance $uuid $instance
+        else
+            vtpmdb_add_instance $domname $instance
         fi
     else
         if [ "$reason" =3D=3D "resume" ]; then
@@ -290,7 +288,6 @@ function vtpm_create_instance () {
             vtpm_start $instance
         fi
     fi
-
     release_lock vtpmdb
=20
     xenstore_write $XENBUS_PATH/instance $instance
@@ -322,8 +319,8 @@ function vtpm_remove_instance () {
     if [ "$instance" !=3D "0" ]; then
         vtpm_suspend $instance
     fi
-
     release_lock vtpmdb
+
 }
=20
=20
diff --git a/tools/hotplug/Linux/vtpm-delete
b/tools/hotplug/Linux/vtpm-delete
--- a/tools/hotplug/Linux/vtpm-delete
+++ b/tools/hotplug/Linux/vtpm-delete
@@ -5,6 +5,8 @@
 # or
 # vtpm-delete --vmname <vm name>
=20
+export PATH=3D$PATH:/usr/sbin:/sbin
+
 dir=3D$(dirname "$0")
 . "$dir/vtpm-common.sh"
=20
diff --git a/tools/hotplug/Linux/vtpm-impl b/tools/hotplug/Linux/vtpm-imp=
l
--- a/tools/hotplug/Linux/vtpm-impl
+++ b/tools/hotplug/Linux/vtpm-impl
@@ -32,14 +32,16 @@
 # OF THE POSSIBILITY OF SUCH DAMAGE.
 # =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
=20
-#            |        SRC        |    TAG  |      CMD SIZE     |      =20
ORD       |mtype|strt
-TPM_CMD_OPEN=3D\\x00\\x00\\x00\\x00\\x01\\xc1\\x00\\x00\\x00\\x11\\x01\\=
x00\\x00\\x01\\x01\\x01
-TPM_CMD_RESM=3D\\x00\\x00\\x00\\x00\\x01\\xc1\\x00\\x00\\x00\\x11\\x01\\=
x00\\x00\\x01\\x01\\x02
-TPM_CMD_CLOS=3D\\x00\\x00\\x00\\x00\\x01\\xc1\\x00\\x00\\x00\\x0e\\x01\\=
x00\\x00\\x02
-TPM_CMD_DELE=3D\\x00\\x00\\x00\\x00\\x01\\xc1\\x00\\x00\\x00\\x0e\\x01\\=
x00\\x00\\x03
+export PATH=3D$PATH:/usr/sbin:/sbin
=20
-TPM_TYPE_PVM=3D\\x01
-TPM_TYPE_HVM=3D\\x02
+#             | SRC  |TAG| CMD SZ|| ORD  |mtype|strt
+TPM_CMD_OPEN=3D"0000000001C100000011010000010101"
+TPM_CMD_RESM=3D"0000000001C100000011010000010102"
+TPM_CMD_CLOS=3D"0000000001C10000000E01000002"
+TPM_CMD_DELE=3D"0000000001C10000000E01000003"
+
+TPM_TYPE_PVM=3D01
+TPM_TYPE_HVM=3D02
=20
 TPM_SUCCESS=3D00000000
=20
@@ -70,24 +72,19 @@ function vtpm_manager_cmd() {
  local inst=3D$2;
  local inst_bin=3D$(hex32_to_bin $inst);
=20
- claim_lock vtpm_mgr
-
- #send cmd to vtpm_manager
- printf "$cmd$inst_bin" > $TX_VTPM_MANAGER
-
- #recv response
- set +e
- local resp_hex=3D`dd skip=3D10 bs=3D1 count=3D4 if=3D$RX_VTPM_MANAGER 2=
>
/dev/null | xxd -ps`
- set -e
+ local resp_hex
+ #send cmd to vtpm_manager and get response
+ if ! resp_hex=3D`echo "$cmd$(str_to_hex32 $inst)" | vtpmmgrtalk `; then=

+   release_lock vtpmdb
+   fatal "Error communicating with vTPM Manager"
+ fi
=20
- release_lock vtpm_mgr
+ resp_hex=3D`echo $resp_hex | cut -b 21-`
=20
  #return whether the command was successful
- if [ $resp_hex -ne $TPM_SUCCESS ]; then
-   vtpm_fatal_error=3D1
-   false
-  else
-   true
+ if [ "$resp_hex" !=3D "$TPM_SUCCESS" ]; then
+   release_lock vtpmdb
+   fatal "vTPM Manager returned failure code $resp_hex"
  fi
 }
=20
@@ -142,13 +139,8 @@ function vtpm_suspend() {
=20
 function vtpm_delete() {
  local inst=3D$1
- if $(vtpm_manager_cmd $TPM_CMD_DELE $inst); then
-   rm -f /var/vtpm/vtpm_dm_$1.data
-   true
- else
-   vtpm_fatal_error=3D1
-   false
- fi
+ $(vtpm_manager_cmd $TPM_CMD_DELE $inst)
+ rm -f /var/vtpm/vtpm_dm_$1.data
 }
=20
 # Perform a migration step. This function differentiates between migrati=
on
diff --git a/tools/python/xen/xend/server/tpmif.py
b/tools/python/xen/xend/server/tpmif.py
--- a/tools/python/xen/xend/server/tpmif.py
+++ b/tools/python/xen/xend/server/tpmif.py
@@ -44,6 +44,22 @@ class TPMifController(DevController):
         DevController.__init__(self, vm)
=20
=20
+    def createDevice(self, config):
+        #Disable hotplug scripts if backend is not dom0
+        import xen.xend.XendDomain
+        xd =3D xen.xend.XendDomain.instance()
+        backdom_name =3D config.get('backend')
+        if backdom_name is None:
+            backdom =3D xen.xend.XendDomain.DOM0_ID
+        else:
+            bd =3D xd.domain_lookup_nr(backdom_name)
+            backdom =3D bd.getDomid()
+
+    if backdom !=3D xen.xend.XendDomain.DOM0_ID:
+       self.hotplug =3D False
+
+        return DevController.createDevice(self, config)
+
     def getDeviceDetails(self, config):
         """@see DevController.getDeviceDetails"""
=20



--------------ms090205080600060307050201
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIDyjCC
A8YwggMvoAMCAQICBD/xyf0wDQYJKoZIhvcNAQEFBQAwLzELMAkGA1UEBhMCVVMxDzANBgNV
BAoTBkpIVUFQTDEPMA0GA1UECxMGQklTRENBMB4XDTEwMDYxMTE4MjIwNloXDTEzMDYxMTE4
NTIwNlowZjELMAkGA1UEBhMCVVMxDzANBgNVBAoTBkpIVUFQTDEPMA0GA1UECxMGUGVvcGxl
MTUwFgYDVQQLEw9WUE5Hcm91cC1CSVNEQ0EwGwYDVQQDExRNYXR0aGV3IEUgRmlvcmF2YW50
ZTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAnpbwVSP6o1Nb5lcW7dd3yTo9iBJdi7qz
4nANOMFPK7JOy5npKN1iiousl28U/scUJES55gPwAWYJK3uVyQAsA4adgDKi5DoD1UHDQEwp
bY7iHLJeq0NPr4BqYNqnCFPbE6HC8zSJrr4qKn+gVUQT39SIFqdiIPJwZL8FYTRQ/zsCAwEA
AaOCAbYwggGyMAsGA1UdDwQEAwIHgDArBgNVHRAEJDAigA8yMDEwMDYxMTE4MjIwNlqBDzIw
MTIwNzE3MjI1MjA2WjAbBg0rBgEEAbMlCwMBAQEBBAoWCGZpb3JhbWUxMBsGDSsGAQQBsyUL
AwEBAQIEChIIMDAxMDQyNjEwWAYJYIZIAYb6ax4BBEsMSVRoZSBwcml2YXRlIGtleSBjb3Jy
ZXNwb25kaW5nIHRvIHRoaXMgY2VydGlmaWNhdGUgbWF5IGhhdmUgYmVlbiBleHBvcnRlZC4w
KAYDVR0RBCEwH4EdTWF0dGhldy5GaW9yYXZhbnRlQGpodWFwbC5lZHUwUgYDVR0fBEswSTBH
oEWgQ6RBMD8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJU0RD
QTEOMAwGA1UEAxMFQ1JMNTYwHwYDVR0jBBgwFoAUCDUpmxH52EU2CyWmF2EJMB1yqeswHQYD
VR0OBBYEFO6LYxg6r9wHZ+zdQtBHn1dZ/YTNMAkGA1UdEwQCMAAwGQYJKoZIhvZ9B0EABAww
ChsEVjcuMQMCBLAwDQYJKoZIhvcNAQEFBQADgYEAJO9HQh4YNChVLzuZqK5ARJARD8JoujGZ
fdo75quvg2jXFQe2sEjvLnxJZgm/pv8fdZakq48CWwjYHKuvIp7sDjTEsQfo+y7SpN/N2NvJ
WU5SqfK1VgYtNLRRoGJUB5Q1aZ+Dg95g3kqpyfpUMISJL8IKVLtJVfN4fggFVUYZ9wwxggGr
MIIBpwIBATA3MC8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJ
U0RDQQIEP/HJ/TAJBgUrDgMCGgUAoIHLMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ
KoZIhvcNAQkFMQ8XDTEyMDkyMTE4NTkzNlowIwYJKoZIhvcNAQkEMRYEFNS9Wbkgqt0VdTVF
PqBElVCCXpG3MGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAK
BggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI
KoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEgYBSEJrzcNkRMXqnsnuPA4b0cZIGe8anovqS
Lw5pcBa66gao51yCLr6dNDmd+y9b23PDSdot2ONLuvjJ+L/54oNGU52WxVMu5ckKIRFY8UwF
ndDB+2OvubpiYtkW/AMCLU9LDMTIkOhWlQQDTAWhgHi2xfD7XgVEVCb5dQHesPf56QAAAAAA
AA==
--------------ms090205080600060307050201--


--===============5118848930475565357==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============5118848930475565357==--


From xen-devel-bounces@lists.xen.org Fri Sep 21 19:04:31 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Sep 2012 19: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 1TF8WQ-0001yt-NP; Fri, 21 Sep 2012 19:04:18 +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 1TF8WP-0001ym-F6
	for xen-devel@lists.xen.org; Fri, 21 Sep 2012 19:04:17 +0000
Received: from [85.158.139.211:46734] by server-6.bemta-5.messagelabs.com id
	F6/80-21336-03ABC505; Fri, 21 Sep 2012 19:04:16 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-9.tower-206.messagelabs.com!1348254254!17990967!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzU2MzI0\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15621 invoked from network); 21 Sep 2012 19:04:16 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-9.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 21 Sep 2012 19:04:16 -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 q8LJ482L024999
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 21 Sep 2012 19:04:09 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
	q8LJ46Lo027856
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 21 Sep 2012 19:04:08 GMT
Received: from abhmt104.oracle.com (abhmt104.oracle.com [141.146.116.56])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q8LJ45Ts021361; Fri, 21 Sep 2012 14:04:05 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 21 Sep 2012 12:04:05 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id EE63B402EC; Fri, 21 Sep 2012 14:52:58 -0400 (EDT)
Date: Fri, 21 Sep 2012 14:52:58 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Andres Lagar-Cavilla <andreslc@gridcentric.ca>
Message-ID: <20120921185258.GA4931@phenom.dumpdata.com>
References: <1347632819-13684-1-git-send-email-andres@lagarcavilla.org>
	<1347869865.14977.15.camel@zakaz.uk.xensource.com>
	<5B5132A4-93B2-41D0-B1A6-048810565DB5@gridcentric.ca>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <5B5132A4-93B2-41D0-B1A6-048810565DB5@gridcentric.ca>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: Ian Campbell <Ian.Campbell@citrix.com>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	xen-devel <xen-devel@lists.xen.org>,
	David Vrabel <david.vrabel@citrix.com>, David Miller <davem@davemloft.net>,
	Andres Lagar-Cavilla <andres@lagarcavilla.org>
Subject: Re: [Xen-devel] [PATCH] Xen backend support for paged out grant
	targets V4.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gTW9uLCBTZXAgMTcsIDIwMTIgYXQgMDU6Mjk6MjRBTSAtMDQwMCwgQW5kcmVzIExhZ2FyLUNh
dmlsbGEgd3JvdGU6Cj4gT24gU2VwIDE3LCAyMDEyLCBhdCA0OjE3IEFNLCBJYW4gQ2FtcGJlbGwg
d3JvdGU6Cj4gCj4gPiAoSSB0aGluayBJIGZvcmdvdCB0byBoaXQgc2VuZCBvbiB0aGlzIG9uIEZy
aWRheSwgc29ycnkuIEFsc28KPiA+IHMveGVuLmxpc3RzLm9yZy9saXN0cy54ZW4ub3JnIGluIHRo
ZSBDQyBsaW5l4oCmKQo+IEknbSBvbiBhIHJvbGwgaGVyZeKApgo+IAo+ID4gCj4gPiBPbiBGcmks
IDIwMTItMDktMTQgYXQgMTU6MjYgKzAxMDAsIEFuZHJlcyBMYWdhci1DYXZpbGxhIHdyb3RlOgo+
ID4+IFNpbmNlIFhlbi00LjIsIGh2bSBkb21haW5zIG1heSBoYXZlIHBvcnRpb25zIG9mIHRoZWly
IG1lbW9yeSBwYWdlZCBvdXQuIFdoZW4gYQo+ID4+IGZvcmVpZ24gZG9tYWluIChzdWNoIGFzIGRv
bTApIGF0dGVtcHRzIHRvIG1hcCB0aGVzZSBmcmFtZXMsIHRoZSBtYXAgd2lsbAo+ID4+IGluaXRp
YWxseSBmYWlsLiBUaGUgaHlwZXJ2aXNvciByZXR1cm5zIGEgc3VpdGFibGUgZXJybm8sIGFuZCBr
aWNrcyBhbgo+ID4+IGFzeW5jaHJvbm91cyBwYWdlLWluIG9wZXJhdGlvbiBjYXJyaWVkIG91dCBi
eSBhIGhlbHBlci4gVGhlIGZvcmVpZ24gZG9tYWluIGlzCj4gPj4gZXhwZWN0ZWQgdG8gcmV0cnkg
dGhlIG1hcHBpbmcgb3BlcmF0aW9uIHVudGlsIGl0IGV2ZW50dWFsbHkgc3VjY2VlZHMuIFRoZQo+
ID4+IGZvcmVpZ24gZG9tYWluIGlzIG5vdCBwdXQgdG8gc2xlZXAgYmVjYXVzZSBpdHNlbGYgY291
bGQgYmUgdGhlIG9uZSBydW5uaW5nIHRoZQo+ID4+IHBhZ2VyIGFzc2lzdCAodHlwaWNhbCBzY2Vu
YXJpbyBmb3IgZG9tMCkuCj4gPj4gCj4gPj4gVGhpcyBwYXRjaCBhZGRzIHN1cHBvcnQgZm9yIHRo
aXMgbWVjaGFuaXNtIGZvciBiYWNrZW5kIGRyaXZlcnMgdXNpbmcgZ3JhbnQKPiA+PiBtYXBwaW5n
IGFuZCBjb3B5aW5nIG9wZXJhdGlvbnMuIFNwZWNpZmljYWxseSwgdGhpcyBjb3ZlcnMgdGhlIGJs
a2JhY2sgYW5kCj4gPj4gZ250ZGV2IGRyaXZlcnMgKHdoaWNoIG1hcCBmb3JlZ2luIGdyYW50cyks
IGFuZCB0aGUgbmV0YmFjayBkcml2ZXIgKHdoaWNoIGNvcGllcwo+ID4gCj4gPiAgICAgICAgICAg
ICAgICAgICAgICAgICAgIGZvcmVpZ24KPiA+IAo+ID4+IGZvcmVpZ24gZ3JhbnRzKS4KPiA+PiAK
PiA+PiAqIEFkZCBhIHJldHJ5IG1ldGhvZCBmb3IgZ3JhbnRzIHRoYXQgZmFpbCB3aXRoIEdOVFNU
X2VhZ2FpbiAoaS5lLiBiZWNhdXNlIHRoZQo+ID4+ICB0YXJnZXQgZm9yZWdpbiBmcmFtZSBpcyBw
YWdlZCBvdXQpLgo+ID4gCj4gPiAgICAgICAgICBmb3JlaWduCj4gPiAKPiA+PiAqIEluc2VydCBo
b29rcyB3aXRoIGFwcHJvcHJpYXRlIHdyYXBwZXJzIGluIHRoZSBhZm9yZW1lbnRpb25lZCBkcml2
ZXJzLgo+ID4+IAo+ID4+IFRoZSByZXRyeSBsb29wIGlzIG9ubHkgaW52b2tlZCBpZiB0aGUgZ3Jh
bnQgb3BlcmF0aW9uIHN0YXR1cyBpcyBHTlRTVF9lYWdhaW4uCj4gPj4gSXQgZ3VhcmFudGVlcyB0
byBsZWF2ZSBhIG5ldyBzdGF0dXMgY29kZSBkaWZmZXJlbnQgZnJvbSBHTlRTVF9lYWdhaW4uIEFu
eSBvdGhlcgo+ID4+IHN0YXR1cyBjb2RlIHJlc3VsdHMgaW4gaWRlbnRpY2FsIGNvZGUgZXhlY3V0
aW9uIGFzIGJlZm9yZS4KPiA+PiAKPiA+PiBUaGUgcmV0cnkgbG9vcCBwZXJmb3JtcyAyNTYgYXR0
ZW1wdHMgd2l0aCBpbmNyZWFzaW5nIHRpbWUgaW50ZXJ2YWxzIHRocm91Z2ggYQo+ID4+IDMyIHNl
Y29uZCBwZXJpb2QuIEl0IHVzZXMgbXNsZWVwIHRvIHlpZWxkIHdoaWxlIHdhaXRpbmcgZm9yIHRo
ZSBuZXh0IHJldHJ5Lgo+ID4gWy4uLl0KPiA+PiBTaWduZWQtb2ZmLWJ5OiBBbmRyZXMgTGFnYXIt
Q2F2aWxsYSA8YW5kcmVzQGxhZ2FyY2F2aWxsYS5vcmc+Cj4gPiAKPiA+IEFja2VkLWJ5OiBJYW4g
Q2FtcGJlbGwgPGlhbi5jYW1wYmVsbEBjaXRyaXguY29tPgo+ID4gCj4gPiBTaW5jZSB0aGlzIGlz
IG1vcmUgYWJvdXQgZ3JhbnQgdGFibGVzIHRoYW4gbmV0YmFjayB0aGlzIHNob3VsZCBwcm9iYWJs
eQo+ID4gZ28gdmlhIEtvbnJhZCByYXRoZXIgdGhhbiBEYXZlLCBpcyB0aGF0IE9LIHdpdGggeW91
IERhdmU/Cj4gCj4gSWYgdGhhdCBpcyB0aGUgY2FzZSBob3BlZnVsbHkgS29ucmFkIGNhbiBkZWFs
IHdpdGggdGhlIHR3byB0eXBvcz8gT3RoZXJ3aXNlIGhhcHB5IHRvIHJlLXNwaW4gdGhlIHBhdGNo
LgoKU28gd2l0aCB0aGlzIHBhdGNoIHdoZW4gSSBsYXVuY2ggYW4gUFZIVk0gZ3Vlc3Qgb24gWGVu
IDQuMSBJIGdldCB0aGlzCmluIHRoZSBpbml0aWFsIGRvbWFpbiBhbmQgdGhlIGd1ZXN0IGlzIGNy
YXNoZWQ6CgpbICAyNjEuOTI3MjE4XSBwcml2Y21kX2ZhdWx0OiB2bWE9ZmZmZjg4MDAyYTMxZGNl
OCA3ZjRlZGMwOTUwMDAtN2Y0ZWRjMTk1MDAwLCBwZ29mZj1jOCwgdXY9MDAwMDdmNGVkYzE1ZDAw
MAoKZ3Vlc3QgY29uZmlnOgo+IG1vcmUgL21udC9sYWIvbGF0ZXN0L2h2bS54bSAKa2VybmVsID0g
Ii91c3IvbGliL3hlbi9ib290L2h2bWxvYWRlciIKYnVpbGRlcj0naHZtJwptZW1vcnk9MTAyNAoj
bWF4bWVtPTEwMjQKbWF4dmNwdXMgPSAyCnNlcmlhbD0ncHR5Jwp2Y3B1cyA9IDIKZGlzayA9IFsg
J2ZpbGU6L21udC9sYWIvbGF0ZXN0L3Jvb3RfaW1hZ2UuaXNvLGhkYzpjZHJvbSxyJ10KYm9vdD0i
ZG4iCiN2aWYgPSBbICd0eXBlPWlvZW11LG1vZGVsPWUxMDAwLG1hYz0wMDowRjo0QjowMDowMDo3
MSwgYnJpZGdlPXN3aXRjaCcgXQp2aWYgPSBbICd0eXBlPW5ldGZyb250LCBicmlkZ2U9c3dpdGNo
JyBdCiN2ZmIgPSBbICd2bmM9MSwgdm5jbGlzdGVuPTAuMC4wLjAgLHZuY3VudXNlZD0xJ10Kdm5j
PTEKdm5jbGlzdGVuPSIwLjAuMC4wIgp1c2I9MQp4ZW5fcGxhdGZvcm1fcGNpPTEKCgoKX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxp
bmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwOi8vbGlzdHMueGVuLm9yZy94ZW4t
ZGV2ZWwK

From xen-devel-bounces@lists.xen.org Fri Sep 21 19:04:31 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Sep 2012 19: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 1TF8WQ-0001yt-NP; Fri, 21 Sep 2012 19:04:18 +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 1TF8WP-0001ym-F6
	for xen-devel@lists.xen.org; Fri, 21 Sep 2012 19:04:17 +0000
Received: from [85.158.139.211:46734] by server-6.bemta-5.messagelabs.com id
	F6/80-21336-03ABC505; Fri, 21 Sep 2012 19:04:16 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-9.tower-206.messagelabs.com!1348254254!17990967!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzU2MzI0\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15621 invoked from network); 21 Sep 2012 19:04:16 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-9.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 21 Sep 2012 19:04:16 -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 q8LJ482L024999
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 21 Sep 2012 19:04:09 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
	q8LJ46Lo027856
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 21 Sep 2012 19:04:08 GMT
Received: from abhmt104.oracle.com (abhmt104.oracle.com [141.146.116.56])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q8LJ45Ts021361; Fri, 21 Sep 2012 14:04:05 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 21 Sep 2012 12:04:05 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id EE63B402EC; Fri, 21 Sep 2012 14:52:58 -0400 (EDT)
Date: Fri, 21 Sep 2012 14:52:58 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Andres Lagar-Cavilla <andreslc@gridcentric.ca>
Message-ID: <20120921185258.GA4931@phenom.dumpdata.com>
References: <1347632819-13684-1-git-send-email-andres@lagarcavilla.org>
	<1347869865.14977.15.camel@zakaz.uk.xensource.com>
	<5B5132A4-93B2-41D0-B1A6-048810565DB5@gridcentric.ca>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <5B5132A4-93B2-41D0-B1A6-048810565DB5@gridcentric.ca>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: Ian Campbell <Ian.Campbell@citrix.com>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	xen-devel <xen-devel@lists.xen.org>,
	David Vrabel <david.vrabel@citrix.com>, David Miller <davem@davemloft.net>,
	Andres Lagar-Cavilla <andres@lagarcavilla.org>
Subject: Re: [Xen-devel] [PATCH] Xen backend support for paged out grant
	targets V4.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gTW9uLCBTZXAgMTcsIDIwMTIgYXQgMDU6Mjk6MjRBTSAtMDQwMCwgQW5kcmVzIExhZ2FyLUNh
dmlsbGEgd3JvdGU6Cj4gT24gU2VwIDE3LCAyMDEyLCBhdCA0OjE3IEFNLCBJYW4gQ2FtcGJlbGwg
d3JvdGU6Cj4gCj4gPiAoSSB0aGluayBJIGZvcmdvdCB0byBoaXQgc2VuZCBvbiB0aGlzIG9uIEZy
aWRheSwgc29ycnkuIEFsc28KPiA+IHMveGVuLmxpc3RzLm9yZy9saXN0cy54ZW4ub3JnIGluIHRo
ZSBDQyBsaW5l4oCmKQo+IEknbSBvbiBhIHJvbGwgaGVyZeKApgo+IAo+ID4gCj4gPiBPbiBGcmks
IDIwMTItMDktMTQgYXQgMTU6MjYgKzAxMDAsIEFuZHJlcyBMYWdhci1DYXZpbGxhIHdyb3RlOgo+
ID4+IFNpbmNlIFhlbi00LjIsIGh2bSBkb21haW5zIG1heSBoYXZlIHBvcnRpb25zIG9mIHRoZWly
IG1lbW9yeSBwYWdlZCBvdXQuIFdoZW4gYQo+ID4+IGZvcmVpZ24gZG9tYWluIChzdWNoIGFzIGRv
bTApIGF0dGVtcHRzIHRvIG1hcCB0aGVzZSBmcmFtZXMsIHRoZSBtYXAgd2lsbAo+ID4+IGluaXRp
YWxseSBmYWlsLiBUaGUgaHlwZXJ2aXNvciByZXR1cm5zIGEgc3VpdGFibGUgZXJybm8sIGFuZCBr
aWNrcyBhbgo+ID4+IGFzeW5jaHJvbm91cyBwYWdlLWluIG9wZXJhdGlvbiBjYXJyaWVkIG91dCBi
eSBhIGhlbHBlci4gVGhlIGZvcmVpZ24gZG9tYWluIGlzCj4gPj4gZXhwZWN0ZWQgdG8gcmV0cnkg
dGhlIG1hcHBpbmcgb3BlcmF0aW9uIHVudGlsIGl0IGV2ZW50dWFsbHkgc3VjY2VlZHMuIFRoZQo+
ID4+IGZvcmVpZ24gZG9tYWluIGlzIG5vdCBwdXQgdG8gc2xlZXAgYmVjYXVzZSBpdHNlbGYgY291
bGQgYmUgdGhlIG9uZSBydW5uaW5nIHRoZQo+ID4+IHBhZ2VyIGFzc2lzdCAodHlwaWNhbCBzY2Vu
YXJpbyBmb3IgZG9tMCkuCj4gPj4gCj4gPj4gVGhpcyBwYXRjaCBhZGRzIHN1cHBvcnQgZm9yIHRo
aXMgbWVjaGFuaXNtIGZvciBiYWNrZW5kIGRyaXZlcnMgdXNpbmcgZ3JhbnQKPiA+PiBtYXBwaW5n
IGFuZCBjb3B5aW5nIG9wZXJhdGlvbnMuIFNwZWNpZmljYWxseSwgdGhpcyBjb3ZlcnMgdGhlIGJs
a2JhY2sgYW5kCj4gPj4gZ250ZGV2IGRyaXZlcnMgKHdoaWNoIG1hcCBmb3JlZ2luIGdyYW50cyks
IGFuZCB0aGUgbmV0YmFjayBkcml2ZXIgKHdoaWNoIGNvcGllcwo+ID4gCj4gPiAgICAgICAgICAg
ICAgICAgICAgICAgICAgIGZvcmVpZ24KPiA+IAo+ID4+IGZvcmVpZ24gZ3JhbnRzKS4KPiA+PiAK
PiA+PiAqIEFkZCBhIHJldHJ5IG1ldGhvZCBmb3IgZ3JhbnRzIHRoYXQgZmFpbCB3aXRoIEdOVFNU
X2VhZ2FpbiAoaS5lLiBiZWNhdXNlIHRoZQo+ID4+ICB0YXJnZXQgZm9yZWdpbiBmcmFtZSBpcyBw
YWdlZCBvdXQpLgo+ID4gCj4gPiAgICAgICAgICBmb3JlaWduCj4gPiAKPiA+PiAqIEluc2VydCBo
b29rcyB3aXRoIGFwcHJvcHJpYXRlIHdyYXBwZXJzIGluIHRoZSBhZm9yZW1lbnRpb25lZCBkcml2
ZXJzLgo+ID4+IAo+ID4+IFRoZSByZXRyeSBsb29wIGlzIG9ubHkgaW52b2tlZCBpZiB0aGUgZ3Jh
bnQgb3BlcmF0aW9uIHN0YXR1cyBpcyBHTlRTVF9lYWdhaW4uCj4gPj4gSXQgZ3VhcmFudGVlcyB0
byBsZWF2ZSBhIG5ldyBzdGF0dXMgY29kZSBkaWZmZXJlbnQgZnJvbSBHTlRTVF9lYWdhaW4uIEFu
eSBvdGhlcgo+ID4+IHN0YXR1cyBjb2RlIHJlc3VsdHMgaW4gaWRlbnRpY2FsIGNvZGUgZXhlY3V0
aW9uIGFzIGJlZm9yZS4KPiA+PiAKPiA+PiBUaGUgcmV0cnkgbG9vcCBwZXJmb3JtcyAyNTYgYXR0
ZW1wdHMgd2l0aCBpbmNyZWFzaW5nIHRpbWUgaW50ZXJ2YWxzIHRocm91Z2ggYQo+ID4+IDMyIHNl
Y29uZCBwZXJpb2QuIEl0IHVzZXMgbXNsZWVwIHRvIHlpZWxkIHdoaWxlIHdhaXRpbmcgZm9yIHRo
ZSBuZXh0IHJldHJ5Lgo+ID4gWy4uLl0KPiA+PiBTaWduZWQtb2ZmLWJ5OiBBbmRyZXMgTGFnYXIt
Q2F2aWxsYSA8YW5kcmVzQGxhZ2FyY2F2aWxsYS5vcmc+Cj4gPiAKPiA+IEFja2VkLWJ5OiBJYW4g
Q2FtcGJlbGwgPGlhbi5jYW1wYmVsbEBjaXRyaXguY29tPgo+ID4gCj4gPiBTaW5jZSB0aGlzIGlz
IG1vcmUgYWJvdXQgZ3JhbnQgdGFibGVzIHRoYW4gbmV0YmFjayB0aGlzIHNob3VsZCBwcm9iYWJs
eQo+ID4gZ28gdmlhIEtvbnJhZCByYXRoZXIgdGhhbiBEYXZlLCBpcyB0aGF0IE9LIHdpdGggeW91
IERhdmU/Cj4gCj4gSWYgdGhhdCBpcyB0aGUgY2FzZSBob3BlZnVsbHkgS29ucmFkIGNhbiBkZWFs
IHdpdGggdGhlIHR3byB0eXBvcz8gT3RoZXJ3aXNlIGhhcHB5IHRvIHJlLXNwaW4gdGhlIHBhdGNo
LgoKU28gd2l0aCB0aGlzIHBhdGNoIHdoZW4gSSBsYXVuY2ggYW4gUFZIVk0gZ3Vlc3Qgb24gWGVu
IDQuMSBJIGdldCB0aGlzCmluIHRoZSBpbml0aWFsIGRvbWFpbiBhbmQgdGhlIGd1ZXN0IGlzIGNy
YXNoZWQ6CgpbICAyNjEuOTI3MjE4XSBwcml2Y21kX2ZhdWx0OiB2bWE9ZmZmZjg4MDAyYTMxZGNl
OCA3ZjRlZGMwOTUwMDAtN2Y0ZWRjMTk1MDAwLCBwZ29mZj1jOCwgdXY9MDAwMDdmNGVkYzE1ZDAw
MAoKZ3Vlc3QgY29uZmlnOgo+IG1vcmUgL21udC9sYWIvbGF0ZXN0L2h2bS54bSAKa2VybmVsID0g
Ii91c3IvbGliL3hlbi9ib290L2h2bWxvYWRlciIKYnVpbGRlcj0naHZtJwptZW1vcnk9MTAyNAoj
bWF4bWVtPTEwMjQKbWF4dmNwdXMgPSAyCnNlcmlhbD0ncHR5Jwp2Y3B1cyA9IDIKZGlzayA9IFsg
J2ZpbGU6L21udC9sYWIvbGF0ZXN0L3Jvb3RfaW1hZ2UuaXNvLGhkYzpjZHJvbSxyJ10KYm9vdD0i
ZG4iCiN2aWYgPSBbICd0eXBlPWlvZW11LG1vZGVsPWUxMDAwLG1hYz0wMDowRjo0QjowMDowMDo3
MSwgYnJpZGdlPXN3aXRjaCcgXQp2aWYgPSBbICd0eXBlPW5ldGZyb250LCBicmlkZ2U9c3dpdGNo
JyBdCiN2ZmIgPSBbICd2bmM9MSwgdm5jbGlzdGVuPTAuMC4wLjAgLHZuY3VudXNlZD0xJ10Kdm5j
PTEKdm5jbGlzdGVuPSIwLjAuMC4wIgp1c2I9MQp4ZW5fcGxhdGZvcm1fcGNpPTEKCgoKX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxp
bmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwOi8vbGlzdHMueGVuLm9yZy94ZW4t
ZGV2ZWwK

From xen-devel-bounces@lists.xen.org Fri Sep 21 19:04:34 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Sep 2012 19: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 1TF8WV-0001zN-3p; Fri, 21 Sep 2012 19:04: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 1TF8WT-0001zA-QD
	for xen-devel@lists.xensource.com; Fri, 21 Sep 2012 19:04:22 +0000
Received: from [85.158.139.83:12552] by server-3.bemta-5.messagelabs.com id
	74/47-21836-53ABC505; Fri, 21 Sep 2012 19:04:21 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1348254260!27641308!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTA2NjI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10479 invoked from network); 21 Sep 2012 19:04:20 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Sep 2012 19:04:20 -0000
X-IronPort-AV: E=Sophos;i="4.80,463,1344211200"; d="scan'208";a="14697051"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Sep 2012 19:04: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.279.1; Fri, 21 Sep 2012 20:04: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 1TF8WQ-0004rY-Jz;
	Fri, 21 Sep 2012 19:04:18 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1TF8WQ-0000GQ-B9;
	Fri, 21 Sep 2012 20:04:18 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-13826-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 21 Sep 2012 20:04:18 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13826: regressions - trouble:
	broken/fail/pass
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 13826 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13826/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-win-vcpus1  5 xen-boot                 fail REGR. vs. 13825
 test-amd64-i386-qemuu-rhel6hvm-intel  5 xen-boot          fail REGR. vs. 13825
 test-amd64-i386-win-vcpus1    5 xen-boot                  fail REGR. vs. 13825
 test-amd64-i386-xl-winxpsp3-vcpus1 12 guest-localmigrate/x10 fail REGR. vs. 13825
 test-amd64-i386-xl-win7-amd64  5 xen-boot                 fail REGR. vs. 13825
 test-amd64-amd64-win          5 xen-boot                  fail REGR. vs. 13825
 test-amd64-amd64-xl-winxpsp3  5 xen-boot                  fail REGR. vs. 13825
 test-amd64-i386-pair          8 xen-boot/dst_host         fail REGR. vs. 13825
 test-amd64-i386-pair          7 xen-boot/src_host         fail REGR. vs. 13825

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore            fail   like 13825
 test-amd64-amd64-xl-sedf      3 host-install(3)              broken like 13825
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail like 13825
 test-amd64-amd64-xl-pcipt-intel  5 xen-boot               fail REGR. vs. 13825
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail like 13823

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  32187301ecc5
baseline version:
 xen                  d364becfb083

------------------------------------------------------------
People who touched revisions under test:
  Jan Beulich <jbeulich@suse.com>
  Keir Fraser <keir@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-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                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-amd64-amd64-xl-sedf                                     broken  
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-amd64-amd64-xl-win                                      fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
changeset:   25937:32187301ecc5
tag:         tip
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Sep 21 15:20:21 2012 +0200
    
    x86: eliminate code affecting only 64-bit-incapable CPUs
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   25936:c8873f13cec3
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Sep 21 14:25:12 2012 +0200
    
    printk: prefer %#x et at over 0x%x
    
    Performance is not an issue with printk(), so let the function do
    minimally more work and instead save a byte per affected format
    specifier.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   25935:1e6e6b49b4ac
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Sep 21 13:47:18 2012 +0200
    
    x86: introduce MWAIT-based, ACPI-less CPU idle driver
    
    This is a port of Linux'es intel-idle driver serving the same purpose.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   25934:8eab91903e71
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Sep 21 13:45:08 2012 +0200
    
    cpuidle: remove unused latency_ticks member
    
    ... and code used only for initializing it.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   25933:d364becfb083
user:        Jan Beulich <jbeulich@suse.com>
date:        Thu Sep 20 13:31:19 2012 +0200
    
    introduce guest_handle_for_field()
    
    This helper turns a field of a GUEST_HANDLE in a GUEST_HANDLE.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    
    
(qemu changes not included)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 21 19:04:34 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Sep 2012 19: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 1TF8WV-0001zN-3p; Fri, 21 Sep 2012 19:04: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 1TF8WT-0001zA-QD
	for xen-devel@lists.xensource.com; Fri, 21 Sep 2012 19:04:22 +0000
Received: from [85.158.139.83:12552] by server-3.bemta-5.messagelabs.com id
	74/47-21836-53ABC505; Fri, 21 Sep 2012 19:04:21 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1348254260!27641308!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTA2NjI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10479 invoked from network); 21 Sep 2012 19:04:20 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Sep 2012 19:04:20 -0000
X-IronPort-AV: E=Sophos;i="4.80,463,1344211200"; d="scan'208";a="14697051"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Sep 2012 19:04: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.279.1; Fri, 21 Sep 2012 20:04: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 1TF8WQ-0004rY-Jz;
	Fri, 21 Sep 2012 19:04:18 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1TF8WQ-0000GQ-B9;
	Fri, 21 Sep 2012 20:04:18 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-13826-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 21 Sep 2012 20:04:18 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13826: regressions - trouble:
	broken/fail/pass
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 13826 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13826/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-win-vcpus1  5 xen-boot                 fail REGR. vs. 13825
 test-amd64-i386-qemuu-rhel6hvm-intel  5 xen-boot          fail REGR. vs. 13825
 test-amd64-i386-win-vcpus1    5 xen-boot                  fail REGR. vs. 13825
 test-amd64-i386-xl-winxpsp3-vcpus1 12 guest-localmigrate/x10 fail REGR. vs. 13825
 test-amd64-i386-xl-win7-amd64  5 xen-boot                 fail REGR. vs. 13825
 test-amd64-amd64-win          5 xen-boot                  fail REGR. vs. 13825
 test-amd64-amd64-xl-winxpsp3  5 xen-boot                  fail REGR. vs. 13825
 test-amd64-i386-pair          8 xen-boot/dst_host         fail REGR. vs. 13825
 test-amd64-i386-pair          7 xen-boot/src_host         fail REGR. vs. 13825

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore            fail   like 13825
 test-amd64-amd64-xl-sedf      3 host-install(3)              broken like 13825
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail like 13825
 test-amd64-amd64-xl-pcipt-intel  5 xen-boot               fail REGR. vs. 13825
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail like 13823

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  32187301ecc5
baseline version:
 xen                  d364becfb083

------------------------------------------------------------
People who touched revisions under test:
  Jan Beulich <jbeulich@suse.com>
  Keir Fraser <keir@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-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                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-amd64-amd64-xl-sedf                                     broken  
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-amd64-amd64-xl-win                                      fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
changeset:   25937:32187301ecc5
tag:         tip
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Sep 21 15:20:21 2012 +0200
    
    x86: eliminate code affecting only 64-bit-incapable CPUs
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   25936:c8873f13cec3
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Sep 21 14:25:12 2012 +0200
    
    printk: prefer %#x et at over 0x%x
    
    Performance is not an issue with printk(), so let the function do
    minimally more work and instead save a byte per affected format
    specifier.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   25935:1e6e6b49b4ac
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Sep 21 13:47:18 2012 +0200
    
    x86: introduce MWAIT-based, ACPI-less CPU idle driver
    
    This is a port of Linux'es intel-idle driver serving the same purpose.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   25934:8eab91903e71
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Sep 21 13:45:08 2012 +0200
    
    cpuidle: remove unused latency_ticks member
    
    ... and code used only for initializing it.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   25933:d364becfb083
user:        Jan Beulich <jbeulich@suse.com>
date:        Thu Sep 20 13:31:19 2012 +0200
    
    introduce guest_handle_for_field()
    
    This helper turns a field of a GUEST_HANDLE in a GUEST_HANDLE.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    
    
(qemu changes not included)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 21 19:05:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Sep 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 1TF8X2-00025Q-I5; Fri, 21 Sep 2012 19:04:56 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <matthew.fioravante@jhuapl.edu>) id 1TF8X0-000251-Ok
	for xen-devel@lists.xensource.com; Fri, 21 Sep 2012 19:04:55 +0000
Received: from [85.158.143.99:31341] by server-2.bemta-4.messagelabs.com id
	A1/26-06610-65ABC505; Fri, 21 Sep 2012 19:04:54 +0000
X-Env-Sender: matthew.fioravante@jhuapl.edu
X-Msg-Ref: server-13.tower-216.messagelabs.com!1348254292!30394320!1
X-Originating-IP: [128.244.251.36]
X-SpamReason: No, hits=0.0 required=7.0 tests=UNPARSEABLE_RELAY
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4242 invoked from network); 21 Sep 2012 19:04:53 -0000
Received: from pilot.jhuapl.edu (HELO jhuapl.edu) (128.244.251.36)
	by server-13.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 21 Sep 2012 19:04:53 -0000
Received: from ([128.244.207.89])
	by pilot.jhuapl.edu with ESMTP with TLS id 63GHCH1.153409466;
	Fri, 21 Sep 2012 15:04:46 -0400
Message-ID: <505CBA02.5040308@jhuapl.edu>
Date: Fri, 21 Sep 2012 15:03:30 -0400
From: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120827 Thunderbird/15.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>, 
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
X-Enigmail-Version: 1.4.4
Subject: [Xen-devel] PATCH [base vtpm and libxl patches 4/6] add iomem
	support to libxl
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============6140264157049664486=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a cryptographically signed message in MIME format.

--===============6140264157049664486==
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms010307090605040108050602"

This is a cryptographically signed message in MIME format.

--------------ms010307090605040108050602
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Add support for mapping hardware io memory into domains via domain
config files.
The syntax is

iomem=3D[PAGE,NUM_PAGES]

Signed off by Matthew Fioravante: matthew.fioravante@jhuapl.edu

---
Changes from previous
* Rebased onto latest xen-unstable
* Rewrote the feature to mimic the style used by iports and irqs in
current libxl
* Updated xl.cfg manpage
* removed the redundant "allow" field, its not used by irq or ioports
either.
* fixed whitespace errors

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
@@ -496,6 +496,16 @@ is given in hexadecimal and may either a span e.g.
C<2f8-2ff>
 It is recommended to use this option only for trusted VMs under
 administrator control.
=20
+=3Ditem B<iomem=3D[ "IOMEM_START,NUM_PAGES", "IOMEM_START,NUM_PAGES", ..=
=2E ]>
+
+Allow guest to access specific hardware I/O memory pages. B<IOMEM_START>=

+is a physical page number given in hexadecimal. B<NUM_PAGES> is the numb=
er
+of pages (given as a decimal integer) beginning with B<START_PAGE> to
allow access.
+
+It is recommended to use this option only for trusted VMs under
+administrator control.
+
+
 =3Ditem B<irqs=3D[ NUMBER, NUMBER, ... ]>
=20
 Allow a guest to access specific physical IRQs.
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
@@ -963,6 +963,24 @@ static void domcreate_launch_dm(libxl__egc *egc,
libxl__multidev *multidev,
         }
     }
=20
+    for (i =3D 0; i < d_config->b_info.num_iomem; i++) {
+        libxl_iomem_range *io =3D &d_config->b_info.iomem[i];
+
+        LOG(DEBUG, "dom%d iomem %"PRIx64"-%"PRIx64,
+            domid, io->start, io->start + io->number - 1);
+
+        ret =3D xc_domain_iomem_permission(CTX->xch, domid,
+                                          io->start, io->number, 1);
+        if ( ret<0 ){
+            LOGE(ERROR,
+                 "failed give dom%d access to iomem range
%"PRIx64"-%"PRIx64,
+                 domid, io->start, io->start + io->number - 1);
+            ret =3D ERROR_FAIL;
+        }
+    }
+
+
+
     for (i =3D 0; i < d_config->num_nics; i++) {
         /* We have to init the nic here, because we still haven't
          * called libxl_device_nic_add at this point, but qemu needs
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
@@ -140,6 +140,11 @@ libxl_ioport_range =3D Struct("ioport_range", [
     ("number", uint32),
     ])
=20
+libxl_iomem_range =3D Struct("iomem_range", [
+    ("start", uint64),
+    ("number", uint64),
+    ])
+
 libxl_vga_interface_info =3D Struct("vga_interface_info", [
     ("kind",    libxl_vga_interface_type),
     ])
@@ -284,6 +289,7 @@ libxl_domain_build_info =3D Struct("domain_build_info=
",[
=20
     ("ioports",          Array(libxl_ioport_range, "num_ioports")),
     ("irqs",             Array(uint32, "num_irqs")),
+    ("iomem",            Array(libxl_iomem_range, "num_iomem")),
=20
     ("u", KeyedUnion(None, libxl_domain_type, "type",
                 [("hvm", Struct(None, [("firmware",         string),
diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -574,8 +574,8 @@ static void parse_config_data(const char *config_sour=
ce,
     long l;
     XLU_Config *config;
     XLU_ConfigList *cpus, *vbds, *nics, *pcis, *cvfbs, *cpuids;
-    XLU_ConfigList *ioports, *irqs;
-    int num_ioports, num_irqs;
+    XLU_ConfigList *ioports, *irqs, *iomem;
+    int num_ioports, num_irqs, num_iomem;
     int pci_power_mgmt =3D 0;
     int pci_msitranslate =3D 0;
     int pci_permissive =3D 0;
@@ -1005,6 +1005,30 @@ static void parse_config_data(const char
*config_source,
         }
     }
=20
+    if (!xlu_cfg_get_list(config, "iomem", &iomem, &num_iomem, 0)) {
+        b_info->num_iomem =3D num_iomem;
+        b_info->iomem =3D calloc(num_iomem, sizeof(*b_info->iomem));
+        if (b_info->iomem =3D=3D NULL) {
+            fprintf(stderr, "unable to allocate memory for iomem\n");
+            exit(-1);
+        }
+        for (i =3D 0; i < num_iomem; i++) {
+            buf =3D xlu_cfg_get_listitem (iomem, i);
+            if (!buf) {
+                fprintf(stderr,
+                        "xl: Unable to get element %d in iomem list\n", =
i);
+                exit(1);
+            }
+            if(sscanf(buf, "%" SCNx64",%" SCNu64,
&b_info->iomem[i].start, &b_info->iomem[i].number) !=3D 2) {
+               fprintf(stderr,
+                       "xl: Invalid argument parsing iomem: %s\n", buf);=

+               exit(1);
+            }
+        }
+    }
+
+
+
     if (!xlu_cfg_get_list (config, "disk", &vbds, 0, 0)) {
         d_config->num_disks =3D 0;
         d_config->disks =3D NULL;



--------------ms010307090605040108050602
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIDyjCC
A8YwggMvoAMCAQICBD/xyf0wDQYJKoZIhvcNAQEFBQAwLzELMAkGA1UEBhMCVVMxDzANBgNV
BAoTBkpIVUFQTDEPMA0GA1UECxMGQklTRENBMB4XDTEwMDYxMTE4MjIwNloXDTEzMDYxMTE4
NTIwNlowZjELMAkGA1UEBhMCVVMxDzANBgNVBAoTBkpIVUFQTDEPMA0GA1UECxMGUGVvcGxl
MTUwFgYDVQQLEw9WUE5Hcm91cC1CSVNEQ0EwGwYDVQQDExRNYXR0aGV3IEUgRmlvcmF2YW50
ZTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAnpbwVSP6o1Nb5lcW7dd3yTo9iBJdi7qz
4nANOMFPK7JOy5npKN1iiousl28U/scUJES55gPwAWYJK3uVyQAsA4adgDKi5DoD1UHDQEwp
bY7iHLJeq0NPr4BqYNqnCFPbE6HC8zSJrr4qKn+gVUQT39SIFqdiIPJwZL8FYTRQ/zsCAwEA
AaOCAbYwggGyMAsGA1UdDwQEAwIHgDArBgNVHRAEJDAigA8yMDEwMDYxMTE4MjIwNlqBDzIw
MTIwNzE3MjI1MjA2WjAbBg0rBgEEAbMlCwMBAQEBBAoWCGZpb3JhbWUxMBsGDSsGAQQBsyUL
AwEBAQIEChIIMDAxMDQyNjEwWAYJYIZIAYb6ax4BBEsMSVRoZSBwcml2YXRlIGtleSBjb3Jy
ZXNwb25kaW5nIHRvIHRoaXMgY2VydGlmaWNhdGUgbWF5IGhhdmUgYmVlbiBleHBvcnRlZC4w
KAYDVR0RBCEwH4EdTWF0dGhldy5GaW9yYXZhbnRlQGpodWFwbC5lZHUwUgYDVR0fBEswSTBH
oEWgQ6RBMD8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJU0RD
QTEOMAwGA1UEAxMFQ1JMNTYwHwYDVR0jBBgwFoAUCDUpmxH52EU2CyWmF2EJMB1yqeswHQYD
VR0OBBYEFO6LYxg6r9wHZ+zdQtBHn1dZ/YTNMAkGA1UdEwQCMAAwGQYJKoZIhvZ9B0EABAww
ChsEVjcuMQMCBLAwDQYJKoZIhvcNAQEFBQADgYEAJO9HQh4YNChVLzuZqK5ARJARD8JoujGZ
fdo75quvg2jXFQe2sEjvLnxJZgm/pv8fdZakq48CWwjYHKuvIp7sDjTEsQfo+y7SpN/N2NvJ
WU5SqfK1VgYtNLRRoGJUB5Q1aZ+Dg95g3kqpyfpUMISJL8IKVLtJVfN4fggFVUYZ9wwxggGr
MIIBpwIBATA3MC8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJ
U0RDQQIEP/HJ/TAJBgUrDgMCGgUAoIHLMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ
KoZIhvcNAQkFMQ8XDTEyMDkyMTE5MDMzMFowIwYJKoZIhvcNAQkEMRYEFHFBmLeuH8fO6os9
B6BEPFzBcGxhMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAK
BggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI
KoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEgYAsOCGHNNcYuIdNXfiR6LSonZonRN1vguga
zSNgw1ok+06L8WAh0fW314FCTTkuhtdn/m/Z8w5q31uaH6ozxjGZKsjeueLpxHcw1FSoHWvQ
iMVI478yNxrCv+ZGLXbYbEXZ3fARxpCUPgEXWcGHddfbtTcTFx6I2ib5WkYbjja7zAAAAAAA
AA==
--------------ms010307090605040108050602--


--===============6140264157049664486==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============6140264157049664486==--


From xen-devel-bounces@lists.xen.org Fri Sep 21 19:05:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Sep 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 1TF8X2-00025Q-I5; Fri, 21 Sep 2012 19:04:56 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <matthew.fioravante@jhuapl.edu>) id 1TF8X0-000251-Ok
	for xen-devel@lists.xensource.com; Fri, 21 Sep 2012 19:04:55 +0000
Received: from [85.158.143.99:31341] by server-2.bemta-4.messagelabs.com id
	A1/26-06610-65ABC505; Fri, 21 Sep 2012 19:04:54 +0000
X-Env-Sender: matthew.fioravante@jhuapl.edu
X-Msg-Ref: server-13.tower-216.messagelabs.com!1348254292!30394320!1
X-Originating-IP: [128.244.251.36]
X-SpamReason: No, hits=0.0 required=7.0 tests=UNPARSEABLE_RELAY
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4242 invoked from network); 21 Sep 2012 19:04:53 -0000
Received: from pilot.jhuapl.edu (HELO jhuapl.edu) (128.244.251.36)
	by server-13.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 21 Sep 2012 19:04:53 -0000
Received: from ([128.244.207.89])
	by pilot.jhuapl.edu with ESMTP with TLS id 63GHCH1.153409466;
	Fri, 21 Sep 2012 15:04:46 -0400
Message-ID: <505CBA02.5040308@jhuapl.edu>
Date: Fri, 21 Sep 2012 15:03:30 -0400
From: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120827 Thunderbird/15.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>, 
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
X-Enigmail-Version: 1.4.4
Subject: [Xen-devel] PATCH [base vtpm and libxl patches 4/6] add iomem
	support to libxl
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============6140264157049664486=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a cryptographically signed message in MIME format.

--===============6140264157049664486==
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms010307090605040108050602"

This is a cryptographically signed message in MIME format.

--------------ms010307090605040108050602
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Add support for mapping hardware io memory into domains via domain
config files.
The syntax is

iomem=3D[PAGE,NUM_PAGES]

Signed off by Matthew Fioravante: matthew.fioravante@jhuapl.edu

---
Changes from previous
* Rebased onto latest xen-unstable
* Rewrote the feature to mimic the style used by iports and irqs in
current libxl
* Updated xl.cfg manpage
* removed the redundant "allow" field, its not used by irq or ioports
either.
* fixed whitespace errors

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
@@ -496,6 +496,16 @@ is given in hexadecimal and may either a span e.g.
C<2f8-2ff>
 It is recommended to use this option only for trusted VMs under
 administrator control.
=20
+=3Ditem B<iomem=3D[ "IOMEM_START,NUM_PAGES", "IOMEM_START,NUM_PAGES", ..=
=2E ]>
+
+Allow guest to access specific hardware I/O memory pages. B<IOMEM_START>=

+is a physical page number given in hexadecimal. B<NUM_PAGES> is the numb=
er
+of pages (given as a decimal integer) beginning with B<START_PAGE> to
allow access.
+
+It is recommended to use this option only for trusted VMs under
+administrator control.
+
+
 =3Ditem B<irqs=3D[ NUMBER, NUMBER, ... ]>
=20
 Allow a guest to access specific physical IRQs.
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
@@ -963,6 +963,24 @@ static void domcreate_launch_dm(libxl__egc *egc,
libxl__multidev *multidev,
         }
     }
=20
+    for (i =3D 0; i < d_config->b_info.num_iomem; i++) {
+        libxl_iomem_range *io =3D &d_config->b_info.iomem[i];
+
+        LOG(DEBUG, "dom%d iomem %"PRIx64"-%"PRIx64,
+            domid, io->start, io->start + io->number - 1);
+
+        ret =3D xc_domain_iomem_permission(CTX->xch, domid,
+                                          io->start, io->number, 1);
+        if ( ret<0 ){
+            LOGE(ERROR,
+                 "failed give dom%d access to iomem range
%"PRIx64"-%"PRIx64,
+                 domid, io->start, io->start + io->number - 1);
+            ret =3D ERROR_FAIL;
+        }
+    }
+
+
+
     for (i =3D 0; i < d_config->num_nics; i++) {
         /* We have to init the nic here, because we still haven't
          * called libxl_device_nic_add at this point, but qemu needs
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
@@ -140,6 +140,11 @@ libxl_ioport_range =3D Struct("ioport_range", [
     ("number", uint32),
     ])
=20
+libxl_iomem_range =3D Struct("iomem_range", [
+    ("start", uint64),
+    ("number", uint64),
+    ])
+
 libxl_vga_interface_info =3D Struct("vga_interface_info", [
     ("kind",    libxl_vga_interface_type),
     ])
@@ -284,6 +289,7 @@ libxl_domain_build_info =3D Struct("domain_build_info=
",[
=20
     ("ioports",          Array(libxl_ioport_range, "num_ioports")),
     ("irqs",             Array(uint32, "num_irqs")),
+    ("iomem",            Array(libxl_iomem_range, "num_iomem")),
=20
     ("u", KeyedUnion(None, libxl_domain_type, "type",
                 [("hvm", Struct(None, [("firmware",         string),
diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -574,8 +574,8 @@ static void parse_config_data(const char *config_sour=
ce,
     long l;
     XLU_Config *config;
     XLU_ConfigList *cpus, *vbds, *nics, *pcis, *cvfbs, *cpuids;
-    XLU_ConfigList *ioports, *irqs;
-    int num_ioports, num_irqs;
+    XLU_ConfigList *ioports, *irqs, *iomem;
+    int num_ioports, num_irqs, num_iomem;
     int pci_power_mgmt =3D 0;
     int pci_msitranslate =3D 0;
     int pci_permissive =3D 0;
@@ -1005,6 +1005,30 @@ static void parse_config_data(const char
*config_source,
         }
     }
=20
+    if (!xlu_cfg_get_list(config, "iomem", &iomem, &num_iomem, 0)) {
+        b_info->num_iomem =3D num_iomem;
+        b_info->iomem =3D calloc(num_iomem, sizeof(*b_info->iomem));
+        if (b_info->iomem =3D=3D NULL) {
+            fprintf(stderr, "unable to allocate memory for iomem\n");
+            exit(-1);
+        }
+        for (i =3D 0; i < num_iomem; i++) {
+            buf =3D xlu_cfg_get_listitem (iomem, i);
+            if (!buf) {
+                fprintf(stderr,
+                        "xl: Unable to get element %d in iomem list\n", =
i);
+                exit(1);
+            }
+            if(sscanf(buf, "%" SCNx64",%" SCNu64,
&b_info->iomem[i].start, &b_info->iomem[i].number) !=3D 2) {
+               fprintf(stderr,
+                       "xl: Invalid argument parsing iomem: %s\n", buf);=

+               exit(1);
+            }
+        }
+    }
+
+
+
     if (!xlu_cfg_get_list (config, "disk", &vbds, 0, 0)) {
         d_config->num_disks =3D 0;
         d_config->disks =3D NULL;



--------------ms010307090605040108050602
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIDyjCC
A8YwggMvoAMCAQICBD/xyf0wDQYJKoZIhvcNAQEFBQAwLzELMAkGA1UEBhMCVVMxDzANBgNV
BAoTBkpIVUFQTDEPMA0GA1UECxMGQklTRENBMB4XDTEwMDYxMTE4MjIwNloXDTEzMDYxMTE4
NTIwNlowZjELMAkGA1UEBhMCVVMxDzANBgNVBAoTBkpIVUFQTDEPMA0GA1UECxMGUGVvcGxl
MTUwFgYDVQQLEw9WUE5Hcm91cC1CSVNEQ0EwGwYDVQQDExRNYXR0aGV3IEUgRmlvcmF2YW50
ZTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAnpbwVSP6o1Nb5lcW7dd3yTo9iBJdi7qz
4nANOMFPK7JOy5npKN1iiousl28U/scUJES55gPwAWYJK3uVyQAsA4adgDKi5DoD1UHDQEwp
bY7iHLJeq0NPr4BqYNqnCFPbE6HC8zSJrr4qKn+gVUQT39SIFqdiIPJwZL8FYTRQ/zsCAwEA
AaOCAbYwggGyMAsGA1UdDwQEAwIHgDArBgNVHRAEJDAigA8yMDEwMDYxMTE4MjIwNlqBDzIw
MTIwNzE3MjI1MjA2WjAbBg0rBgEEAbMlCwMBAQEBBAoWCGZpb3JhbWUxMBsGDSsGAQQBsyUL
AwEBAQIEChIIMDAxMDQyNjEwWAYJYIZIAYb6ax4BBEsMSVRoZSBwcml2YXRlIGtleSBjb3Jy
ZXNwb25kaW5nIHRvIHRoaXMgY2VydGlmaWNhdGUgbWF5IGhhdmUgYmVlbiBleHBvcnRlZC4w
KAYDVR0RBCEwH4EdTWF0dGhldy5GaW9yYXZhbnRlQGpodWFwbC5lZHUwUgYDVR0fBEswSTBH
oEWgQ6RBMD8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJU0RD
QTEOMAwGA1UEAxMFQ1JMNTYwHwYDVR0jBBgwFoAUCDUpmxH52EU2CyWmF2EJMB1yqeswHQYD
VR0OBBYEFO6LYxg6r9wHZ+zdQtBHn1dZ/YTNMAkGA1UdEwQCMAAwGQYJKoZIhvZ9B0EABAww
ChsEVjcuMQMCBLAwDQYJKoZIhvcNAQEFBQADgYEAJO9HQh4YNChVLzuZqK5ARJARD8JoujGZ
fdo75quvg2jXFQe2sEjvLnxJZgm/pv8fdZakq48CWwjYHKuvIp7sDjTEsQfo+y7SpN/N2NvJ
WU5SqfK1VgYtNLRRoGJUB5Q1aZ+Dg95g3kqpyfpUMISJL8IKVLtJVfN4fggFVUYZ9wwxggGr
MIIBpwIBATA3MC8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJ
U0RDQQIEP/HJ/TAJBgUrDgMCGgUAoIHLMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ
KoZIhvcNAQkFMQ8XDTEyMDkyMTE5MDMzMFowIwYJKoZIhvcNAQkEMRYEFHFBmLeuH8fO6os9
B6BEPFzBcGxhMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAK
BggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI
KoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEgYAsOCGHNNcYuIdNXfiR6LSonZonRN1vguga
zSNgw1ok+06L8WAh0fW314FCTTkuhtdn/m/Z8w5q31uaH6ozxjGZKsjeueLpxHcw1FSoHWvQ
iMVI478yNxrCv+ZGLXbYbEXZ3fARxpCUPgEXWcGHddfbtTcTFx6I2ib5WkYbjja7zAAAAAAA
AA==
--------------ms010307090605040108050602--


--===============6140264157049664486==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============6140264157049664486==--


From xen-devel-bounces@lists.xen.org Fri Sep 21 19:08:06 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Sep 2012 19:08:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TF8Zc-0002OD-AZ; Fri, 21 Sep 2012 19:07:36 +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 1TF8Za-0002Nw-Az
	for xen-devel@lists.xen.org; Fri, 21 Sep 2012 19:07:34 +0000
Received: from [85.158.138.51:15650] by server-10.bemta-3.messagelabs.com id
	68/F5-10411-5FABC505; Fri, 21 Sep 2012 19:07:33 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1348254451!23911918!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzU2MzI0\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12433 invoked from network); 21 Sep 2012 19:07:33 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-10.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 21 Sep 2012 19:07:33 -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 q8LJ7TRg028107
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 21 Sep 2012 19:07:30 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
	q8LJ7Ta1017979
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 21 Sep 2012 19:07: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
	q8LJ7SVS004024; Fri, 21 Sep 2012 14:07:28 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 21 Sep 2012 12:07:28 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 16ABE402EC; Fri, 21 Sep 2012 14:56:23 -0400 (EDT)
Date: Fri, 21 Sep 2012 14:56:23 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Oliver Chick <oliver.chick@citrix.com>
Message-ID: <20120921185622.GA5042@phenom.dumpdata.com>
References: <1348242767-23732-1-git-send-email-oliver.chick@citrix.com>
	<20120921184123.GA27502@phenom.dumpdata.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120921184123.GA27502@phenom.dumpdata.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: linux-kernel@vger.kernel.org, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH v2] Persistent grant maps for xen blk drivers
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> *: With a PVHVM guest I get
> 
> [  261.927218] privcmd_fault: vma=ffff88002a31dce8 7f4edc095000-7f4edc195000, pgoff=c8, uv=00007f4edc15d000
> 
> thought if I applied your patch on top of v3.6-rc6 I didn't see the privcmd_fault but
> I did see the guest crash.

And that is due to c571898ffc24a1768e1b2dabeac0fc7dd4c14601 which I've reverted in my
#linux-next branch

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 21 19:08:06 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Sep 2012 19:08:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TF8Zc-0002OD-AZ; Fri, 21 Sep 2012 19:07:36 +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 1TF8Za-0002Nw-Az
	for xen-devel@lists.xen.org; Fri, 21 Sep 2012 19:07:34 +0000
Received: from [85.158.138.51:15650] by server-10.bemta-3.messagelabs.com id
	68/F5-10411-5FABC505; Fri, 21 Sep 2012 19:07:33 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1348254451!23911918!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzU2MzI0\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12433 invoked from network); 21 Sep 2012 19:07:33 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-10.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 21 Sep 2012 19:07:33 -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 q8LJ7TRg028107
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 21 Sep 2012 19:07:30 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
	q8LJ7Ta1017979
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 21 Sep 2012 19:07: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
	q8LJ7SVS004024; Fri, 21 Sep 2012 14:07:28 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 21 Sep 2012 12:07:28 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 16ABE402EC; Fri, 21 Sep 2012 14:56:23 -0400 (EDT)
Date: Fri, 21 Sep 2012 14:56:23 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Oliver Chick <oliver.chick@citrix.com>
Message-ID: <20120921185622.GA5042@phenom.dumpdata.com>
References: <1348242767-23732-1-git-send-email-oliver.chick@citrix.com>
	<20120921184123.GA27502@phenom.dumpdata.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120921184123.GA27502@phenom.dumpdata.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: linux-kernel@vger.kernel.org, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH v2] Persistent grant maps for xen blk drivers
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> *: With a PVHVM guest I get
> 
> [  261.927218] privcmd_fault: vma=ffff88002a31dce8 7f4edc095000-7f4edc195000, pgoff=c8, uv=00007f4edc15d000
> 
> thought if I applied your patch on top of v3.6-rc6 I didn't see the privcmd_fault but
> I did see the guest crash.

And that is due to c571898ffc24a1768e1b2dabeac0fc7dd4c14601 which I've reverted in my
#linux-next branch

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 21 19:12:32 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Sep 2012 19: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 1TF8eD-0002cd-1P; Fri, 21 Sep 2012 19:12:21 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mukesh.rathor@oracle.com>) id 1TF8eC-0002cW-BX
	for Xen-devel@lists.xensource.com; Fri, 21 Sep 2012 19:12:20 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1348254733!10516396!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzU2MzI0\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22938 invoked from network); 21 Sep 2012 19:12:14 -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; 21 Sep 2012 19:12:14 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q8LJC50W001002
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 21 Sep 2012 19:12:06 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
	q8LJC4j4011694
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 21 Sep 2012 19:12:05 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
	q8LJC46Z006085; Fri, 21 Sep 2012 14:12:04 -0500
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 21 Sep 2012 12:12:03 -0700
Date: Fri, 21 Sep 2012 12:12:02 -0700
From: Mukesh Rathor <mukesh.rathor@oracle.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, "stefano.stabellini@eu.citrix.com"
	<stefano.stabellini@eu.citrix.com>
Message-ID: <20120921121202.3163c379@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]
Subject: [Xen-devel] [PATCH v1 0/8]: PVH (PV guest with extensions)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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,

Ok, I've made all the changes from prev RFC patch submission. Tested
all the combinations. The patches are a bit smaller from before, and
couldn't be separated like before, so I can't state whats different in
each patch. But, it's not too bad to review now.

As before, they were built on top of
fc6bdb59a501740b28ed3b616641a22c8dc5dd31 from the following tree:
        
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git

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 Sep 21 19:12:32 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Sep 2012 19: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 1TF8eD-0002cd-1P; Fri, 21 Sep 2012 19:12:21 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mukesh.rathor@oracle.com>) id 1TF8eC-0002cW-BX
	for Xen-devel@lists.xensource.com; Fri, 21 Sep 2012 19:12:20 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1348254733!10516396!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzU2MzI0\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22938 invoked from network); 21 Sep 2012 19:12:14 -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; 21 Sep 2012 19:12:14 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q8LJC50W001002
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 21 Sep 2012 19:12:06 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
	q8LJC4j4011694
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 21 Sep 2012 19:12:05 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
	q8LJC46Z006085; Fri, 21 Sep 2012 14:12:04 -0500
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 21 Sep 2012 12:12:03 -0700
Date: Fri, 21 Sep 2012 12:12:02 -0700
From: Mukesh Rathor <mukesh.rathor@oracle.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, "stefano.stabellini@eu.citrix.com"
	<stefano.stabellini@eu.citrix.com>
Message-ID: <20120921121202.3163c379@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]
Subject: [Xen-devel] [PATCH v1 0/8]: PVH (PV guest with extensions)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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,

Ok, I've made all the changes from prev RFC patch submission. Tested
all the combinations. The patches are a bit smaller from before, and
couldn't be separated like before, so I can't state whats different in
each patch. But, it's not too bad to review now.

As before, they were built on top of
fc6bdb59a501740b28ed3b616641a22c8dc5dd31 from the following tree:
        
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git

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 Sep 21 19:15:37 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Sep 2012 19:15:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TF8hA-0002jm-KN; Fri, 21 Sep 2012 19:15:24 +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 1TF8h8-0002jc-R2
	for Xen-devel@lists.xensource.com; Fri, 21 Sep 2012 19:15:23 +0000
Received: from [85.158.139.83:57314] by server-13.bemta-5.messagelabs.com id
	98/CF-23645-ACCBC505; Fri, 21 Sep 2012 19:15:22 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1348254919!27642011!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDc2NjM1OA==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27613 invoked from network); 21 Sep 2012 19:15:21 -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; 21 Sep 2012 19:15:21 -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 q8LJFDUU019393
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 21 Sep 2012 19:15:14 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
	q8LJFCcO018142
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 21 Sep 2012 19:15:13 GMT
Received: from abhmt109.oracle.com (abhmt109.oracle.com [141.146.116.61])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q8LJFCSl008150; Fri, 21 Sep 2012 14:15:12 -0500
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 21 Sep 2012 12:15:12 -0700
Date: Fri, 21 Sep 2012 12:15:11 -0700
From: Mukesh Rathor <mukesh.rathor@oracle.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, "stefano.stabellini@eu.citrix.com"
	<stefano.stabellini@eu.citrix.com>
Message-ID: <20120921121511.30001c08@mantra.us.oracle.com>
Organization: Oracle Corporation
X-Mailer: Claws Mail 3.7.6 (GTK+ 2.18.9; x86_64-redhat-linux-gnu)
Mime-Version: 1.0
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Subject: [Xen-devel] [PATCH v1 1/8]: PVH  basic and hader file 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

---
 arch/x86/include/asm/xen/interface.h |    8 +++++++-
 arch/x86/include/asm/xen/page.h      |    3 +++
 arch/x86/xen/irq.c                   |    5 ++++-
 arch/x86/xen/p2m.c                   |    2 +-
 drivers/xen/cpu_hotplug.c            |    4 +++-
 drivers/xen/events.c                 |   12 ++++++++----
 drivers/xen/xenbus/xenbus_client.c   |    2 +-
 drivers/xen/xenbus/xenbus_probe.c    |    6 +++++-
 include/xen/interface/memory.h       |   27 +++++++++++++++++++++++++++
 include/xen/interface/physdev.h      |   10 ++++++++++
 10 files changed, 69 insertions(+), 10 deletions(-)

diff --git a/arch/x86/include/asm/xen/interface.h b/arch/x86/include/asm/xen/interface.h
index cbf0c9d..1d22131 100644
--- a/arch/x86/include/asm/xen/interface.h
+++ b/arch/x86/include/asm/xen/interface.h
@@ -136,7 +136,13 @@ struct vcpu_guest_context {
     struct cpu_user_regs user_regs;         /* User-level CPU registers     */
     struct trap_info trap_ctxt[256];        /* Virtual IDT                  */
     unsigned long ldt_base, ldt_ents;       /* LDT (linear address, # ents) */
-    unsigned long gdt_frames[16], gdt_ents; /* GDT (machine frames, # ents) */
+    union {
+	struct {
+		/* PV: GDT (machine frames, # ents).*/
+		unsigned long gdt_frames[16], gdt_ents;
+	};
+	unsigned long gdtaddr, gdtsz;	    /* PVH: GDTR addr and size */
+    };
     unsigned long kernel_ss, kernel_sp;     /* Virtual TSS (only SS1/SP1)   */
     /* NB. User pagetable on x86/64 is placed in ctrlreg[1]. */
     unsigned long ctrlreg[8];               /* CR0-CR7 (control registers)  */
diff --git a/arch/x86/include/asm/xen/page.h b/arch/x86/include/asm/xen/page.h
index 93971e8..d1cfb96 100644
--- a/arch/x86/include/asm/xen/page.h
+++ b/arch/x86/include/asm/xen/page.h
@@ -158,6 +158,9 @@ static inline xpaddr_t machine_to_phys(xmaddr_t machine)
 static inline unsigned long mfn_to_local_pfn(unsigned long mfn)
 {
 	unsigned long pfn = mfn_to_pfn(mfn);
+
+	if (xen_feature(XENFEAT_auto_translated_physmap))
+		return mfn;
 	if (get_phys_to_machine(pfn) != mfn)
 		return -1; /* force !pfn_valid() */
 	return pfn;
diff --git a/arch/x86/xen/irq.c b/arch/x86/xen/irq.c
index 1573376..31959a7 100644
--- a/arch/x86/xen/irq.c
+++ b/arch/x86/xen/irq.c
@@ -5,6 +5,7 @@
 #include <xen/interface/xen.h>
 #include <xen/interface/sched.h>
 #include <xen/interface/vcpu.h>
+#include <xen/features.h>
 
 #include <asm/xen/hypercall.h>
 #include <asm/xen/hypervisor.h>
@@ -128,6 +129,8 @@ static const struct pv_irq_ops xen_irq_ops __initconst = {
 
 void __init xen_init_irq_ops(void)
 {
-	pv_irq_ops = xen_irq_ops;
+	/* For PVH we use default pv_irq_ops settings */
+	if (!xen_feature(XENFEAT_hvm_callback_vector))
+		pv_irq_ops = xen_irq_ops;
 	x86_init.irqs.intr_init = xen_init_IRQ;
 }
diff --git a/arch/x86/xen/p2m.c b/arch/x86/xen/p2m.c
index 64effdc..a954f83 100644
--- a/arch/x86/xen/p2m.c
+++ b/arch/x86/xen/p2m.c
@@ -626,7 +626,7 @@ bool __set_phys_to_machine(unsigned long pfn, unsigned long mfn)
 {
 	unsigned topidx, mididx, idx;
 
-	if (unlikely(xen_feature(XENFEAT_auto_translated_physmap))) {
+	if (xen_feature(XENFEAT_auto_translated_physmap)) {
 		BUG_ON(pfn != mfn && mfn != INVALID_P2M_ENTRY);
 		return true;
 	}
diff --git a/drivers/xen/cpu_hotplug.c b/drivers/xen/cpu_hotplug.c
index 4dcfced..de6bcf9 100644
--- a/drivers/xen/cpu_hotplug.c
+++ b/drivers/xen/cpu_hotplug.c
@@ -2,6 +2,7 @@
 
 #include <xen/xen.h>
 #include <xen/xenbus.h>
+#include <xen/features.h>
 
 #include <asm/xen/hypervisor.h>
 #include <asm/cpu.h>
@@ -100,7 +101,8 @@ static int __init setup_vcpu_hotplug_event(void)
 	static struct notifier_block xsn_cpu = {
 		.notifier_call = setup_cpu_watcher };
 
-	if (!xen_pv_domain())
+	/* PVH TBD/FIXME: future work */
+	if (!xen_pv_domain() || xen_feature(XENFEAT_auto_translated_physmap))
 		return -ENODEV;
 
 	register_xenstore_notifier(&xsn_cpu);
diff --git a/drivers/xen/events.c b/drivers/xen/events.c
index 7595581..f656791 100644
--- a/drivers/xen/events.c
+++ b/drivers/xen/events.c
@@ -1755,7 +1755,7 @@ int xen_set_callback_via(uint64_t via)
 }
 EXPORT_SYMBOL_GPL(xen_set_callback_via);
 
-#ifdef CONFIG_XEN_PVHVM
+
 /* Vector callbacks are better than PCI interrupts to receive event
  * channel notifications because we can receive vector callbacks on any
  * vcpu and we don't need PCI support or APIC interactions. */
@@ -1779,9 +1779,6 @@ void xen_callback_vector(void)
 			alloc_intr_gate(XEN_HVM_EVTCHN_CALLBACK, xen_hvm_callback_vector);
 	}
 }
-#else
-void xen_callback_vector(void) {}
-#endif
 
 void __init xen_init_IRQ(void)
 {
@@ -1814,6 +1811,13 @@ void __init xen_init_IRQ(void)
 		if (xen_initial_domain())
 			pci_xen_initial_domain();
 
+		if (xen_feature(XENFEAT_hvm_callback_vector)) {
+			xen_callback_vector();
+			return;
+		}
+
+		/* PVH: TBD/FIXME: debug and fix eio map to work with pvh */
+
 		pirq_eoi_map = (void *)__get_free_page(GFP_KERNEL|__GFP_ZERO);
 		eoi_gmfn.gmfn = virt_to_mfn(pirq_eoi_map);
 		rc = HYPERVISOR_physdev_op(PHYSDEVOP_pirq_eoi_gmfn_v2, &eoi_gmfn);
diff --git a/drivers/xen/xenbus/xenbus_client.c b/drivers/xen/xenbus/xenbus_client.c
index b3e146e..a81e66b 100644
--- a/drivers/xen/xenbus/xenbus_client.c
+++ b/drivers/xen/xenbus/xenbus_client.c
@@ -743,7 +743,7 @@ static const struct xenbus_ring_ops ring_ops_hvm = {
 
 void __init xenbus_ring_ops_init(void)
 {
-	if (xen_pv_domain())
+	if (xen_pv_domain() && !xen_feature(XENFEAT_auto_translated_physmap))
 		ring_ops = &ring_ops_pv;
 	else
 		ring_ops = &ring_ops_hvm;
diff --git a/drivers/xen/xenbus/xenbus_probe.c b/drivers/xen/xenbus/xenbus_probe.c
index b793723..481dc72 100644
--- a/drivers/xen/xenbus/xenbus_probe.c
+++ b/drivers/xen/xenbus/xenbus_probe.c
@@ -749,7 +749,11 @@ static int __init xenbus_init(void)
 			if (err)
 				goto out_error;
 		}
-		xen_store_interface = mfn_to_virt(xen_store_mfn);
+                if (xen_feature(XENFEAT_auto_translated_physmap))
+			/* mfn is actually a pfn */
+			xen_store_interface = __va(xen_store_mfn<<PAGE_SHIFT);
+		else
+			xen_store_interface = mfn_to_virt(xen_store_mfn);
 	}
 
 	/* Initialize the interface to xenstore. */
diff --git a/include/xen/interface/memory.h b/include/xen/interface/memory.h
index eac3ce1..f150fa1c 100644
--- a/include/xen/interface/memory.h
+++ b/include/xen/interface/memory.h
@@ -163,11 +163,22 @@ struct xen_add_to_physmap {
     /* Which domain to change the mapping for. */
     domid_t domid;
 
+    union {
+        /* Number of pages to go through for gmfn_range */
+        uint16_t    size;
+	/* IFF XENMAPSPACE_gmfn_foreign */
+        domid_t foreign_domid;
+    } u;
     /* 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 */
+#define XENMAPSPACE_gmfn_foreign 4 /* GMFN from another guest */
     unsigned int space;
 
+#define XENMAPIDX_grant_table_status 0x80000000
+
     /* Index into source mapping space. */
     unsigned long idx;
 
@@ -234,4 +245,20 @@ DEFINE_GUEST_HANDLE_STRUCT(xen_memory_map);
  * during a driver critical region.
  */
 extern spinlock_t xen_reservation_lock;
+
+/*
+ * Unmaps the page appearing at a particular GPFN from the specified guest's
+ * pseudophysical address space.
+ * arg == addr of xen_remove_from_physmap_t.
+ */
+#define XENMEM_remove_from_physmap      15
+struct xen_remove_from_physmap {
+    /* Which domain to change the mapping for. */
+    domid_t domid;
+
+    /* GPFN of the current mapping of the page. */
+    unsigned long     gpfn;
+};
+DEFINE_GUEST_HANDLE_STRUCT(xen_remove_from_physmap);
+
 #endif /* __XEN_PUBLIC_MEMORY_H__ */
diff --git a/include/xen/interface/physdev.h b/include/xen/interface/physdev.h
index 9ce788d..80f792e 100644
--- a/include/xen/interface/physdev.h
+++ b/include/xen/interface/physdev.h
@@ -258,6 +258,16 @@ struct physdev_pci_device {
     uint8_t devfn;
 };
 
+#define PHYSDEVOP_pvh_map_iomem        29
+struct physdev_map_iomem {
+    /* IN */
+    uint64_t first_gfn;
+    uint64_t first_mfn;
+    uint32_t nr_mfns;
+    uint32_t add_mapping;        /* 1 == add mapping;  0 == unmap */
+
+};
+
 /*
  * Notify that some PIRQ-bound event channels have been unmasked.
  * ** This command is obsolete since interface version 0x00030202 and is **
-- 
1.7.2.3


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 21 19:15:37 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Sep 2012 19:15:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TF8hA-0002jm-KN; Fri, 21 Sep 2012 19:15:24 +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 1TF8h8-0002jc-R2
	for Xen-devel@lists.xensource.com; Fri, 21 Sep 2012 19:15:23 +0000
Received: from [85.158.139.83:57314] by server-13.bemta-5.messagelabs.com id
	98/CF-23645-ACCBC505; Fri, 21 Sep 2012 19:15:22 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1348254919!27642011!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDc2NjM1OA==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27613 invoked from network); 21 Sep 2012 19:15:21 -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; 21 Sep 2012 19:15:21 -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 q8LJFDUU019393
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 21 Sep 2012 19:15:14 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
	q8LJFCcO018142
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 21 Sep 2012 19:15:13 GMT
Received: from abhmt109.oracle.com (abhmt109.oracle.com [141.146.116.61])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q8LJFCSl008150; Fri, 21 Sep 2012 14:15:12 -0500
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 21 Sep 2012 12:15:12 -0700
Date: Fri, 21 Sep 2012 12:15:11 -0700
From: Mukesh Rathor <mukesh.rathor@oracle.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, "stefano.stabellini@eu.citrix.com"
	<stefano.stabellini@eu.citrix.com>
Message-ID: <20120921121511.30001c08@mantra.us.oracle.com>
Organization: Oracle Corporation
X-Mailer: Claws Mail 3.7.6 (GTK+ 2.18.9; x86_64-redhat-linux-gnu)
Mime-Version: 1.0
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Subject: [Xen-devel] [PATCH v1 1/8]: PVH  basic and hader file 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

---
 arch/x86/include/asm/xen/interface.h |    8 +++++++-
 arch/x86/include/asm/xen/page.h      |    3 +++
 arch/x86/xen/irq.c                   |    5 ++++-
 arch/x86/xen/p2m.c                   |    2 +-
 drivers/xen/cpu_hotplug.c            |    4 +++-
 drivers/xen/events.c                 |   12 ++++++++----
 drivers/xen/xenbus/xenbus_client.c   |    2 +-
 drivers/xen/xenbus/xenbus_probe.c    |    6 +++++-
 include/xen/interface/memory.h       |   27 +++++++++++++++++++++++++++
 include/xen/interface/physdev.h      |   10 ++++++++++
 10 files changed, 69 insertions(+), 10 deletions(-)

diff --git a/arch/x86/include/asm/xen/interface.h b/arch/x86/include/asm/xen/interface.h
index cbf0c9d..1d22131 100644
--- a/arch/x86/include/asm/xen/interface.h
+++ b/arch/x86/include/asm/xen/interface.h
@@ -136,7 +136,13 @@ struct vcpu_guest_context {
     struct cpu_user_regs user_regs;         /* User-level CPU registers     */
     struct trap_info trap_ctxt[256];        /* Virtual IDT                  */
     unsigned long ldt_base, ldt_ents;       /* LDT (linear address, # ents) */
-    unsigned long gdt_frames[16], gdt_ents; /* GDT (machine frames, # ents) */
+    union {
+	struct {
+		/* PV: GDT (machine frames, # ents).*/
+		unsigned long gdt_frames[16], gdt_ents;
+	};
+	unsigned long gdtaddr, gdtsz;	    /* PVH: GDTR addr and size */
+    };
     unsigned long kernel_ss, kernel_sp;     /* Virtual TSS (only SS1/SP1)   */
     /* NB. User pagetable on x86/64 is placed in ctrlreg[1]. */
     unsigned long ctrlreg[8];               /* CR0-CR7 (control registers)  */
diff --git a/arch/x86/include/asm/xen/page.h b/arch/x86/include/asm/xen/page.h
index 93971e8..d1cfb96 100644
--- a/arch/x86/include/asm/xen/page.h
+++ b/arch/x86/include/asm/xen/page.h
@@ -158,6 +158,9 @@ static inline xpaddr_t machine_to_phys(xmaddr_t machine)
 static inline unsigned long mfn_to_local_pfn(unsigned long mfn)
 {
 	unsigned long pfn = mfn_to_pfn(mfn);
+
+	if (xen_feature(XENFEAT_auto_translated_physmap))
+		return mfn;
 	if (get_phys_to_machine(pfn) != mfn)
 		return -1; /* force !pfn_valid() */
 	return pfn;
diff --git a/arch/x86/xen/irq.c b/arch/x86/xen/irq.c
index 1573376..31959a7 100644
--- a/arch/x86/xen/irq.c
+++ b/arch/x86/xen/irq.c
@@ -5,6 +5,7 @@
 #include <xen/interface/xen.h>
 #include <xen/interface/sched.h>
 #include <xen/interface/vcpu.h>
+#include <xen/features.h>
 
 #include <asm/xen/hypercall.h>
 #include <asm/xen/hypervisor.h>
@@ -128,6 +129,8 @@ static const struct pv_irq_ops xen_irq_ops __initconst = {
 
 void __init xen_init_irq_ops(void)
 {
-	pv_irq_ops = xen_irq_ops;
+	/* For PVH we use default pv_irq_ops settings */
+	if (!xen_feature(XENFEAT_hvm_callback_vector))
+		pv_irq_ops = xen_irq_ops;
 	x86_init.irqs.intr_init = xen_init_IRQ;
 }
diff --git a/arch/x86/xen/p2m.c b/arch/x86/xen/p2m.c
index 64effdc..a954f83 100644
--- a/arch/x86/xen/p2m.c
+++ b/arch/x86/xen/p2m.c
@@ -626,7 +626,7 @@ bool __set_phys_to_machine(unsigned long pfn, unsigned long mfn)
 {
 	unsigned topidx, mididx, idx;
 
-	if (unlikely(xen_feature(XENFEAT_auto_translated_physmap))) {
+	if (xen_feature(XENFEAT_auto_translated_physmap)) {
 		BUG_ON(pfn != mfn && mfn != INVALID_P2M_ENTRY);
 		return true;
 	}
diff --git a/drivers/xen/cpu_hotplug.c b/drivers/xen/cpu_hotplug.c
index 4dcfced..de6bcf9 100644
--- a/drivers/xen/cpu_hotplug.c
+++ b/drivers/xen/cpu_hotplug.c
@@ -2,6 +2,7 @@
 
 #include <xen/xen.h>
 #include <xen/xenbus.h>
+#include <xen/features.h>
 
 #include <asm/xen/hypervisor.h>
 #include <asm/cpu.h>
@@ -100,7 +101,8 @@ static int __init setup_vcpu_hotplug_event(void)
 	static struct notifier_block xsn_cpu = {
 		.notifier_call = setup_cpu_watcher };
 
-	if (!xen_pv_domain())
+	/* PVH TBD/FIXME: future work */
+	if (!xen_pv_domain() || xen_feature(XENFEAT_auto_translated_physmap))
 		return -ENODEV;
 
 	register_xenstore_notifier(&xsn_cpu);
diff --git a/drivers/xen/events.c b/drivers/xen/events.c
index 7595581..f656791 100644
--- a/drivers/xen/events.c
+++ b/drivers/xen/events.c
@@ -1755,7 +1755,7 @@ int xen_set_callback_via(uint64_t via)
 }
 EXPORT_SYMBOL_GPL(xen_set_callback_via);
 
-#ifdef CONFIG_XEN_PVHVM
+
 /* Vector callbacks are better than PCI interrupts to receive event
  * channel notifications because we can receive vector callbacks on any
  * vcpu and we don't need PCI support or APIC interactions. */
@@ -1779,9 +1779,6 @@ void xen_callback_vector(void)
 			alloc_intr_gate(XEN_HVM_EVTCHN_CALLBACK, xen_hvm_callback_vector);
 	}
 }
-#else
-void xen_callback_vector(void) {}
-#endif
 
 void __init xen_init_IRQ(void)
 {
@@ -1814,6 +1811,13 @@ void __init xen_init_IRQ(void)
 		if (xen_initial_domain())
 			pci_xen_initial_domain();
 
+		if (xen_feature(XENFEAT_hvm_callback_vector)) {
+			xen_callback_vector();
+			return;
+		}
+
+		/* PVH: TBD/FIXME: debug and fix eio map to work with pvh */
+
 		pirq_eoi_map = (void *)__get_free_page(GFP_KERNEL|__GFP_ZERO);
 		eoi_gmfn.gmfn = virt_to_mfn(pirq_eoi_map);
 		rc = HYPERVISOR_physdev_op(PHYSDEVOP_pirq_eoi_gmfn_v2, &eoi_gmfn);
diff --git a/drivers/xen/xenbus/xenbus_client.c b/drivers/xen/xenbus/xenbus_client.c
index b3e146e..a81e66b 100644
--- a/drivers/xen/xenbus/xenbus_client.c
+++ b/drivers/xen/xenbus/xenbus_client.c
@@ -743,7 +743,7 @@ static const struct xenbus_ring_ops ring_ops_hvm = {
 
 void __init xenbus_ring_ops_init(void)
 {
-	if (xen_pv_domain())
+	if (xen_pv_domain() && !xen_feature(XENFEAT_auto_translated_physmap))
 		ring_ops = &ring_ops_pv;
 	else
 		ring_ops = &ring_ops_hvm;
diff --git a/drivers/xen/xenbus/xenbus_probe.c b/drivers/xen/xenbus/xenbus_probe.c
index b793723..481dc72 100644
--- a/drivers/xen/xenbus/xenbus_probe.c
+++ b/drivers/xen/xenbus/xenbus_probe.c
@@ -749,7 +749,11 @@ static int __init xenbus_init(void)
 			if (err)
 				goto out_error;
 		}
-		xen_store_interface = mfn_to_virt(xen_store_mfn);
+                if (xen_feature(XENFEAT_auto_translated_physmap))
+			/* mfn is actually a pfn */
+			xen_store_interface = __va(xen_store_mfn<<PAGE_SHIFT);
+		else
+			xen_store_interface = mfn_to_virt(xen_store_mfn);
 	}
 
 	/* Initialize the interface to xenstore. */
diff --git a/include/xen/interface/memory.h b/include/xen/interface/memory.h
index eac3ce1..f150fa1c 100644
--- a/include/xen/interface/memory.h
+++ b/include/xen/interface/memory.h
@@ -163,11 +163,22 @@ struct xen_add_to_physmap {
     /* Which domain to change the mapping for. */
     domid_t domid;
 
+    union {
+        /* Number of pages to go through for gmfn_range */
+        uint16_t    size;
+	/* IFF XENMAPSPACE_gmfn_foreign */
+        domid_t foreign_domid;
+    } u;
     /* 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 */
+#define XENMAPSPACE_gmfn_foreign 4 /* GMFN from another guest */
     unsigned int space;
 
+#define XENMAPIDX_grant_table_status 0x80000000
+
     /* Index into source mapping space. */
     unsigned long idx;
 
@@ -234,4 +245,20 @@ DEFINE_GUEST_HANDLE_STRUCT(xen_memory_map);
  * during a driver critical region.
  */
 extern spinlock_t xen_reservation_lock;
+
+/*
+ * Unmaps the page appearing at a particular GPFN from the specified guest's
+ * pseudophysical address space.
+ * arg == addr of xen_remove_from_physmap_t.
+ */
+#define XENMEM_remove_from_physmap      15
+struct xen_remove_from_physmap {
+    /* Which domain to change the mapping for. */
+    domid_t domid;
+
+    /* GPFN of the current mapping of the page. */
+    unsigned long     gpfn;
+};
+DEFINE_GUEST_HANDLE_STRUCT(xen_remove_from_physmap);
+
 #endif /* __XEN_PUBLIC_MEMORY_H__ */
diff --git a/include/xen/interface/physdev.h b/include/xen/interface/physdev.h
index 9ce788d..80f792e 100644
--- a/include/xen/interface/physdev.h
+++ b/include/xen/interface/physdev.h
@@ -258,6 +258,16 @@ struct physdev_pci_device {
     uint8_t devfn;
 };
 
+#define PHYSDEVOP_pvh_map_iomem        29
+struct physdev_map_iomem {
+    /* IN */
+    uint64_t first_gfn;
+    uint64_t first_mfn;
+    uint32_t nr_mfns;
+    uint32_t add_mapping;        /* 1 == add mapping;  0 == unmap */
+
+};
+
 /*
  * Notify that some PIRQ-bound event channels have been unmasked.
  * ** This command is obsolete since interface version 0x00030202 and is **
-- 
1.7.2.3


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 21 19:16:16 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Sep 2012 19:16:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TF8hr-0002nI-2B; Fri, 21 Sep 2012 19:16:07 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mukesh.rathor@oracle.com>) id 1TF8hp-0002n8-J0
	for Xen-devel@lists.xensource.com; Fri, 21 Sep 2012 19:16:05 +0000
Received: from [85.158.143.99:52868] by server-3.bemta-4.messagelabs.com id
	73/B0-10986-4FCBC505; Fri, 21 Sep 2012 19:16:04 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1348254962!31340053!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzU2MzI0\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30281 invoked from network); 21 Sep 2012 19:16:04 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-9.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 21 Sep 2012 19:16:04 -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 q8LJFw8r005746
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 21 Sep 2012 19:15:59 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
	q8LJFwHj005638
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 21 Sep 2012 19:15:58 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
	q8LJFwaM009941; Fri, 21 Sep 2012 14:15:58 -0500
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 21 Sep 2012 12:15:58 -0700
Date: Fri, 21 Sep 2012 12:15:56 -0700
From: Mukesh Rathor <mukesh.rathor@oracle.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, "stefano.stabellini@eu.citrix.com"
	<stefano.stabellini@eu.citrix.com>
Message-ID: <20120921121556.1a0ea8af@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] [PATCH v1 2/8]: PVH mmu 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


---
 arch/x86/xen/mmu.c    |  180 +++++++++++++++++++++++++++++++++++++++++++++++--
 arch/x86/xen/mmu.h    |    2 +
 include/xen/xen-ops.h |   12 +++-
 3 files changed, 188 insertions(+), 6 deletions(-)

diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c
index b65a761..9b5a5ef 100644
--- a/arch/x86/xen/mmu.c
+++ b/arch/x86/xen/mmu.c
@@ -73,6 +73,7 @@
 #include <xen/interface/version.h>
 #include <xen/interface/memory.h>
 #include <xen/hvc-console.h>
+#include <xen/balloon.h>
 
 #include "multicalls.h"
 #include "mmu.h"
@@ -330,6 +331,26 @@ static void xen_set_pte(pte_t *ptep, pte_t pteval)
 	__xen_set_pte(ptep, pteval);
 }
 
+void xen_set_clr_mmio_pvh_pte(unsigned long pfn, unsigned long mfn, 
+			      int nr_mfns, int add_mapping)
+{
+	struct physdev_map_iomem iomem;
+
+	iomem.first_gfn = pfn;
+	iomem.first_mfn = mfn;
+	iomem.nr_mfns = nr_mfns;
+	iomem.add_mapping = add_mapping;
+
+	if (HYPERVISOR_physdev_op(PHYSDEVOP_pvh_map_iomem, &iomem))
+		BUG();
+}
+
+static void xen_dom0pvh_set_pte_at(struct mm_struct *mm, unsigned long addr,
+		    		   pte_t *ptep, pte_t pteval)
+{
+	native_set_pte(ptep, pteval);
+}
+
 static void xen_set_pte_at(struct mm_struct *mm, unsigned long addr,
 		    pte_t *ptep, pte_t pteval)
 {
@@ -1197,6 +1218,10 @@ static void xen_post_allocator_init(void);
 static void __init xen_pagetable_setup_done(pgd_t *base)
 {
 	xen_setup_shared_info();
+
+	if (xen_feature(XENFEAT_auto_translated_physmap))
+		return;
+
 	xen_post_allocator_init();
 }
 
@@ -1455,6 +1480,10 @@ static void __init xen_set_pte_init(pte_t *ptep, pte_t pte)
 static void pin_pagetable_pfn(unsigned cmd, unsigned long pfn)
 {
 	struct mmuext_op op;
+
+	if (xen_feature(XENFEAT_writable_page_tables))
+		return;
+
 	op.cmd = cmd;
 	op.arg1.mfn = pfn_to_mfn(pfn);
 	if (HYPERVISOR_mmuext_op(&op, 1, NULL, DOMID_SELF))
@@ -1652,6 +1681,10 @@ static void set_page_prot(void *addr, pgprot_t prot)
 	unsigned long pfn = __pa(addr) >> PAGE_SHIFT;
 	pte_t pte = pfn_pte(pfn, prot);
 
+	/* recall for PVH, page tables are native. */
+	if (xen_feature(XENFEAT_auto_translated_physmap))
+		return;
+
 	if (HYPERVISOR_update_va_mapping((unsigned long)addr, pte, 0))
 		BUG();
 }
@@ -1729,6 +1762,9 @@ static void convert_pfn_mfn(void *v)
 	pte_t *pte = v;
 	int i;
 
+	if (xen_feature(XENFEAT_auto_translated_physmap))
+		return;
+
 	/* All levels are converted the same way, so just treat them
 	   as ptes. */
 	for (i = 0; i < PTRS_PER_PTE; i++)
@@ -1745,6 +1781,7 @@ static void convert_pfn_mfn(void *v)
  * but that's enough to get __va working.  We need to fill in the rest
  * of the physical mapping once some sort of allocator has been set
  * up.
+ * NOTE: for PVH, the page tables are native.
  */
 pgd_t * __init xen_setup_kernel_pagetable(pgd_t *pgd,
 					 unsigned long max_pfn)
@@ -1802,9 +1839,13 @@ pgd_t * __init xen_setup_kernel_pagetable(pgd_t *pgd,
 	 * structure to attach it to, so make sure we just set kernel
 	 * pgd.
 	 */
-	xen_mc_batch();
-	__xen_write_cr3(true, __pa(pgd));
-	xen_mc_issue(PARAVIRT_LAZY_CPU);
+	if (xen_feature(XENFEAT_writable_page_tables)) {
+		native_write_cr3(__pa(pgd));
+	} else {
+		xen_mc_batch();
+		__xen_write_cr3(true, __pa(pgd));
+		xen_mc_issue(PARAVIRT_LAZY_CPU);
+	}
 
 	memblock_reserve(__pa(xen_start_info->pt_base),
 			 xen_start_info->nr_pt_frames * PAGE_SIZE);
@@ -2067,9 +2108,21 @@ static const struct pv_mmu_ops xen_mmu_ops __initconst = {
 
 void __init xen_init_mmu_ops(void)
 {
+	x86_init.paging.pagetable_setup_done = xen_pagetable_setup_done;
+
+	if (xen_feature(XENFEAT_auto_translated_physmap)) {
+		pv_mmu_ops.flush_tlb_others = xen_flush_tlb_others;
+
+		/* set_pte* for PCI devices to map iomem. */
+		if (xen_initial_domain()) {
+			pv_mmu_ops.set_pte = native_set_pte;
+			pv_mmu_ops.set_pte_at = xen_dom0pvh_set_pte_at;
+		}
+		return;
+	}
+
 	x86_init.mapping.pagetable_reserve = xen_mapping_pagetable_reserve;
 	x86_init.paging.pagetable_setup_start = xen_pagetable_setup_start;
-	x86_init.paging.pagetable_setup_done = xen_pagetable_setup_done;
 	pv_mmu_ops = xen_mmu_ops;
 
 	memset(dummy_mapping, 0xff, PAGE_SIZE);
@@ -2305,6 +2358,92 @@ void __init xen_hvm_init_mmu_ops(void)
 }
 #endif
 
+/* Map foreign gmfn, fgmfn, to local pfn, lpfn. This for the user space 
+ * creating new guest on PVH dom0 and needs to map domU pages. 
+ */
+static int pvh_add_to_xen_p2m(unsigned long lpfn, unsigned long fgmfn,
+			      unsigned int domid)
+{
+	int rc;
+	struct xen_add_to_physmap xatp = { .u.foreign_domid = domid };
+
+	xatp.gpfn = lpfn;
+	xatp.idx = fgmfn;
+	xatp.domid = DOMID_SELF;
+	xatp.space = XENMAPSPACE_gmfn_foreign;
+	rc = HYPERVISOR_memory_op(XENMEM_add_to_physmap, &xatp);
+	if (rc)
+		pr_warn("d0: Failed to map pfn to mfn rc:%d pfn:%lx mfn:%lx\n", 
+			rc, lpfn, fgmfn); 
+	return rc;
+}
+
+int pvh_rem_xen_p2m(unsigned long spfn, int count)
+{
+	struct xen_remove_from_physmap xrp;
+	int i, rc;
+
+	for (i=0; i < count; i++) {
+		xrp.domid = DOMID_SELF;
+		xrp.gpfn = spfn+i;
+		rc = HYPERVISOR_memory_op(XENMEM_remove_from_physmap, &xrp);
+		if (rc) {
+			pr_warn("Failed to unmap pfn:%lx rc:%d done:%d\n",
+				spfn+i, rc, i);
+			return 1;
+		}
+	}
+	return 0;
+}
+EXPORT_SYMBOL_GPL(pvh_rem_xen_p2m);
+
+struct pvh_remap_data {
+	unsigned long fgmfn;		/* foreign domain's gmfn */
+	pgprot_t prot;
+	domid_t  domid;
+	struct xen_pvh_pfn_info *pvhinfop;
+};
+
+static int pvh_map_pte_fn(pte_t *ptep, pgtable_t token, unsigned long addr, 
+			void *data)
+{
+	int rc;
+	struct pvh_remap_data *remapp = data;
+	struct xen_pvh_pfn_info *pvhp = remapp->pvhinfop;
+	unsigned long pfn = page_to_pfn(pvhp->pi_paga[pvhp->pi_next_todo++]);
+	pte_t pteval = pte_mkspecial(pfn_pte(pfn, remapp->prot));
+
+	if ((rc=pvh_add_to_xen_p2m(pfn, remapp->fgmfn, remapp->domid)))
+		return rc;
+	native_set_pte(ptep, pteval);
+
+	return 0;
+}
+
+/* The only caller at moment passes one gmfn at a time.
+ * PVH TBD/FIXME: expand this in future to honor batch requests.
+ */
+static int pvh_remap_gmfn_range(struct vm_area_struct *vma,
+				unsigned long addr, unsigned long mfn, int nr,
+				pgprot_t prot, unsigned domid,
+				struct xen_pvh_pfn_info *pvhp)
+{
+	int err;
+	struct pvh_remap_data pvhdata;
+
+	if (nr > 1)
+		return -EINVAL;
+
+	pvhdata.fgmfn = mfn;
+	pvhdata.prot = prot;
+	pvhdata.domid = domid;
+	pvhdata.pvhinfop = pvhp;
+	err = apply_to_page_range(vma->vm_mm, addr, nr << PAGE_SHIFT,
+				  pvh_map_pte_fn, &pvhdata);
+	flush_tlb_all();
+	return err;
+}
+
 #define REMAP_BATCH_SIZE 16
 
 struct remap_data {
@@ -2329,7 +2468,9 @@ static int remap_area_mfn_pte_fn(pte_t *ptep, pgtable_t token,
 int xen_remap_domain_mfn_range(struct vm_area_struct *vma,
 			       unsigned long addr,
 			       unsigned long mfn, int nr,
-			       pgprot_t prot, unsigned domid)
+			       pgprot_t prot, unsigned domid,
+			       struct xen_pvh_pfn_info *pvhp)
+
 {
 	struct remap_data rmd;
 	struct mmu_update mmu_update[REMAP_BATCH_SIZE];
@@ -2342,6 +2483,12 @@ int xen_remap_domain_mfn_range(struct vm_area_struct *vma,
 	BUG_ON(!((vma->vm_flags & (VM_PFNMAP | VM_RESERVED | VM_IO)) ==
 				(VM_PFNMAP | VM_RESERVED | VM_IO)));
 
+	if (xen_feature(XENFEAT_auto_translated_physmap)) {
+		/* We need to update the local page tables and the xen HAP */
+		return pvh_remap_gmfn_range(vma, addr, mfn, nr, prot, domid,
+					    pvhp);
+	}
+
 	rmd.mfn = mfn;
 	rmd.prot = prot;
 
@@ -2371,3 +2518,26 @@ out:
 	return err;
 }
 EXPORT_SYMBOL_GPL(xen_remap_domain_mfn_range);
+
+/* Returns: Number of pages unmapped */
+int xen_unmap_domain_mfn_range(struct vm_area_struct *vma,
+			       struct xen_pvh_pfn_info *pvhp)
+{
+	int count = 0;
+
+	if (!pvhp || !xen_feature(XENFEAT_auto_translated_physmap))
+		return 0;
+
+	while (pvhp->pi_next_todo--) {
+		unsigned long pfn;
+
+		/* the mmu has already cleaned up the process mmu resources at
+		 * this point (lookup_address will return NULL). */
+		pfn = page_to_pfn(pvhp->pi_paga[pvhp->pi_next_todo]);
+		pvh_rem_xen_p2m(pfn, 1);
+		count++;
+	}
+	flush_tlb_all();
+	return count;
+}
+EXPORT_SYMBOL_GPL(xen_unmap_domain_mfn_range);
diff --git a/arch/x86/xen/mmu.h b/arch/x86/xen/mmu.h
index 73809bb..6d0bb56 100644
--- a/arch/x86/xen/mmu.h
+++ b/arch/x86/xen/mmu.h
@@ -23,4 +23,6 @@ unsigned long xen_read_cr2_direct(void);
 
 extern void xen_init_mmu_ops(void);
 extern void xen_hvm_init_mmu_ops(void);
+extern void xen_set_clr_mmio_pvh_pte(unsigned long pfn, unsigned long mfn,
+				     int nr_mfns, int add_mapping);
 #endif	/* _XEN_MMU_H */
diff --git a/include/xen/xen-ops.h b/include/xen/xen-ops.h
index 6a198e4..6c5ad83 100644
--- a/include/xen/xen-ops.h
+++ b/include/xen/xen-ops.h
@@ -24,9 +24,19 @@ int xen_create_contiguous_region(unsigned long vstart, unsigned int order,
 void xen_destroy_contiguous_region(unsigned long vstart, unsigned int order);
 
 struct vm_area_struct;
+struct xen_pvh_pfn_info;
 int xen_remap_domain_mfn_range(struct vm_area_struct *vma,
 			       unsigned long addr,
 			       unsigned long mfn, int nr,
-			       pgprot_t prot, unsigned domid);
+			       pgprot_t prot, unsigned domid,
+			       struct xen_pvh_pfn_info *pvhp);
+int xen_unmap_domain_mfn_range(struct vm_area_struct *vma,
+			       struct xen_pvh_pfn_info *pvhp);
+
+struct xen_pvh_pfn_info {
+	struct page **pi_paga;		/* pfn info page array */
+	int 	      pi_num_pgs;
+	int 	      pi_next_todo;
+};
 
 #endif /* INCLUDE_XEN_OPS_H */
-- 
1.7.2.3


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 21 19:16:16 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Sep 2012 19:16:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TF8hr-0002nI-2B; Fri, 21 Sep 2012 19:16:07 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mukesh.rathor@oracle.com>) id 1TF8hp-0002n8-J0
	for Xen-devel@lists.xensource.com; Fri, 21 Sep 2012 19:16:05 +0000
Received: from [85.158.143.99:52868] by server-3.bemta-4.messagelabs.com id
	73/B0-10986-4FCBC505; Fri, 21 Sep 2012 19:16:04 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1348254962!31340053!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzU2MzI0\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30281 invoked from network); 21 Sep 2012 19:16:04 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-9.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 21 Sep 2012 19:16:04 -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 q8LJFw8r005746
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 21 Sep 2012 19:15:59 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
	q8LJFwHj005638
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 21 Sep 2012 19:15:58 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
	q8LJFwaM009941; Fri, 21 Sep 2012 14:15:58 -0500
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 21 Sep 2012 12:15:58 -0700
Date: Fri, 21 Sep 2012 12:15:56 -0700
From: Mukesh Rathor <mukesh.rathor@oracle.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, "stefano.stabellini@eu.citrix.com"
	<stefano.stabellini@eu.citrix.com>
Message-ID: <20120921121556.1a0ea8af@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] [PATCH v1 2/8]: PVH mmu 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


---
 arch/x86/xen/mmu.c    |  180 +++++++++++++++++++++++++++++++++++++++++++++++--
 arch/x86/xen/mmu.h    |    2 +
 include/xen/xen-ops.h |   12 +++-
 3 files changed, 188 insertions(+), 6 deletions(-)

diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c
index b65a761..9b5a5ef 100644
--- a/arch/x86/xen/mmu.c
+++ b/arch/x86/xen/mmu.c
@@ -73,6 +73,7 @@
 #include <xen/interface/version.h>
 #include <xen/interface/memory.h>
 #include <xen/hvc-console.h>
+#include <xen/balloon.h>
 
 #include "multicalls.h"
 #include "mmu.h"
@@ -330,6 +331,26 @@ static void xen_set_pte(pte_t *ptep, pte_t pteval)
 	__xen_set_pte(ptep, pteval);
 }
 
+void xen_set_clr_mmio_pvh_pte(unsigned long pfn, unsigned long mfn, 
+			      int nr_mfns, int add_mapping)
+{
+	struct physdev_map_iomem iomem;
+
+	iomem.first_gfn = pfn;
+	iomem.first_mfn = mfn;
+	iomem.nr_mfns = nr_mfns;
+	iomem.add_mapping = add_mapping;
+
+	if (HYPERVISOR_physdev_op(PHYSDEVOP_pvh_map_iomem, &iomem))
+		BUG();
+}
+
+static void xen_dom0pvh_set_pte_at(struct mm_struct *mm, unsigned long addr,
+		    		   pte_t *ptep, pte_t pteval)
+{
+	native_set_pte(ptep, pteval);
+}
+
 static void xen_set_pte_at(struct mm_struct *mm, unsigned long addr,
 		    pte_t *ptep, pte_t pteval)
 {
@@ -1197,6 +1218,10 @@ static void xen_post_allocator_init(void);
 static void __init xen_pagetable_setup_done(pgd_t *base)
 {
 	xen_setup_shared_info();
+
+	if (xen_feature(XENFEAT_auto_translated_physmap))
+		return;
+
 	xen_post_allocator_init();
 }
 
@@ -1455,6 +1480,10 @@ static void __init xen_set_pte_init(pte_t *ptep, pte_t pte)
 static void pin_pagetable_pfn(unsigned cmd, unsigned long pfn)
 {
 	struct mmuext_op op;
+
+	if (xen_feature(XENFEAT_writable_page_tables))
+		return;
+
 	op.cmd = cmd;
 	op.arg1.mfn = pfn_to_mfn(pfn);
 	if (HYPERVISOR_mmuext_op(&op, 1, NULL, DOMID_SELF))
@@ -1652,6 +1681,10 @@ static void set_page_prot(void *addr, pgprot_t prot)
 	unsigned long pfn = __pa(addr) >> PAGE_SHIFT;
 	pte_t pte = pfn_pte(pfn, prot);
 
+	/* recall for PVH, page tables are native. */
+	if (xen_feature(XENFEAT_auto_translated_physmap))
+		return;
+
 	if (HYPERVISOR_update_va_mapping((unsigned long)addr, pte, 0))
 		BUG();
 }
@@ -1729,6 +1762,9 @@ static void convert_pfn_mfn(void *v)
 	pte_t *pte = v;
 	int i;
 
+	if (xen_feature(XENFEAT_auto_translated_physmap))
+		return;
+
 	/* All levels are converted the same way, so just treat them
 	   as ptes. */
 	for (i = 0; i < PTRS_PER_PTE; i++)
@@ -1745,6 +1781,7 @@ static void convert_pfn_mfn(void *v)
  * but that's enough to get __va working.  We need to fill in the rest
  * of the physical mapping once some sort of allocator has been set
  * up.
+ * NOTE: for PVH, the page tables are native.
  */
 pgd_t * __init xen_setup_kernel_pagetable(pgd_t *pgd,
 					 unsigned long max_pfn)
@@ -1802,9 +1839,13 @@ pgd_t * __init xen_setup_kernel_pagetable(pgd_t *pgd,
 	 * structure to attach it to, so make sure we just set kernel
 	 * pgd.
 	 */
-	xen_mc_batch();
-	__xen_write_cr3(true, __pa(pgd));
-	xen_mc_issue(PARAVIRT_LAZY_CPU);
+	if (xen_feature(XENFEAT_writable_page_tables)) {
+		native_write_cr3(__pa(pgd));
+	} else {
+		xen_mc_batch();
+		__xen_write_cr3(true, __pa(pgd));
+		xen_mc_issue(PARAVIRT_LAZY_CPU);
+	}
 
 	memblock_reserve(__pa(xen_start_info->pt_base),
 			 xen_start_info->nr_pt_frames * PAGE_SIZE);
@@ -2067,9 +2108,21 @@ static const struct pv_mmu_ops xen_mmu_ops __initconst = {
 
 void __init xen_init_mmu_ops(void)
 {
+	x86_init.paging.pagetable_setup_done = xen_pagetable_setup_done;
+
+	if (xen_feature(XENFEAT_auto_translated_physmap)) {
+		pv_mmu_ops.flush_tlb_others = xen_flush_tlb_others;
+
+		/* set_pte* for PCI devices to map iomem. */
+		if (xen_initial_domain()) {
+			pv_mmu_ops.set_pte = native_set_pte;
+			pv_mmu_ops.set_pte_at = xen_dom0pvh_set_pte_at;
+		}
+		return;
+	}
+
 	x86_init.mapping.pagetable_reserve = xen_mapping_pagetable_reserve;
 	x86_init.paging.pagetable_setup_start = xen_pagetable_setup_start;
-	x86_init.paging.pagetable_setup_done = xen_pagetable_setup_done;
 	pv_mmu_ops = xen_mmu_ops;
 
 	memset(dummy_mapping, 0xff, PAGE_SIZE);
@@ -2305,6 +2358,92 @@ void __init xen_hvm_init_mmu_ops(void)
 }
 #endif
 
+/* Map foreign gmfn, fgmfn, to local pfn, lpfn. This for the user space 
+ * creating new guest on PVH dom0 and needs to map domU pages. 
+ */
+static int pvh_add_to_xen_p2m(unsigned long lpfn, unsigned long fgmfn,
+			      unsigned int domid)
+{
+	int rc;
+	struct xen_add_to_physmap xatp = { .u.foreign_domid = domid };
+
+	xatp.gpfn = lpfn;
+	xatp.idx = fgmfn;
+	xatp.domid = DOMID_SELF;
+	xatp.space = XENMAPSPACE_gmfn_foreign;
+	rc = HYPERVISOR_memory_op(XENMEM_add_to_physmap, &xatp);
+	if (rc)
+		pr_warn("d0: Failed to map pfn to mfn rc:%d pfn:%lx mfn:%lx\n", 
+			rc, lpfn, fgmfn); 
+	return rc;
+}
+
+int pvh_rem_xen_p2m(unsigned long spfn, int count)
+{
+	struct xen_remove_from_physmap xrp;
+	int i, rc;
+
+	for (i=0; i < count; i++) {
+		xrp.domid = DOMID_SELF;
+		xrp.gpfn = spfn+i;
+		rc = HYPERVISOR_memory_op(XENMEM_remove_from_physmap, &xrp);
+		if (rc) {
+			pr_warn("Failed to unmap pfn:%lx rc:%d done:%d\n",
+				spfn+i, rc, i);
+			return 1;
+		}
+	}
+	return 0;
+}
+EXPORT_SYMBOL_GPL(pvh_rem_xen_p2m);
+
+struct pvh_remap_data {
+	unsigned long fgmfn;		/* foreign domain's gmfn */
+	pgprot_t prot;
+	domid_t  domid;
+	struct xen_pvh_pfn_info *pvhinfop;
+};
+
+static int pvh_map_pte_fn(pte_t *ptep, pgtable_t token, unsigned long addr, 
+			void *data)
+{
+	int rc;
+	struct pvh_remap_data *remapp = data;
+	struct xen_pvh_pfn_info *pvhp = remapp->pvhinfop;
+	unsigned long pfn = page_to_pfn(pvhp->pi_paga[pvhp->pi_next_todo++]);
+	pte_t pteval = pte_mkspecial(pfn_pte(pfn, remapp->prot));
+
+	if ((rc=pvh_add_to_xen_p2m(pfn, remapp->fgmfn, remapp->domid)))
+		return rc;
+	native_set_pte(ptep, pteval);
+
+	return 0;
+}
+
+/* The only caller at moment passes one gmfn at a time.
+ * PVH TBD/FIXME: expand this in future to honor batch requests.
+ */
+static int pvh_remap_gmfn_range(struct vm_area_struct *vma,
+				unsigned long addr, unsigned long mfn, int nr,
+				pgprot_t prot, unsigned domid,
+				struct xen_pvh_pfn_info *pvhp)
+{
+	int err;
+	struct pvh_remap_data pvhdata;
+
+	if (nr > 1)
+		return -EINVAL;
+
+	pvhdata.fgmfn = mfn;
+	pvhdata.prot = prot;
+	pvhdata.domid = domid;
+	pvhdata.pvhinfop = pvhp;
+	err = apply_to_page_range(vma->vm_mm, addr, nr << PAGE_SHIFT,
+				  pvh_map_pte_fn, &pvhdata);
+	flush_tlb_all();
+	return err;
+}
+
 #define REMAP_BATCH_SIZE 16
 
 struct remap_data {
@@ -2329,7 +2468,9 @@ static int remap_area_mfn_pte_fn(pte_t *ptep, pgtable_t token,
 int xen_remap_domain_mfn_range(struct vm_area_struct *vma,
 			       unsigned long addr,
 			       unsigned long mfn, int nr,
-			       pgprot_t prot, unsigned domid)
+			       pgprot_t prot, unsigned domid,
+			       struct xen_pvh_pfn_info *pvhp)
+
 {
 	struct remap_data rmd;
 	struct mmu_update mmu_update[REMAP_BATCH_SIZE];
@@ -2342,6 +2483,12 @@ int xen_remap_domain_mfn_range(struct vm_area_struct *vma,
 	BUG_ON(!((vma->vm_flags & (VM_PFNMAP | VM_RESERVED | VM_IO)) ==
 				(VM_PFNMAP | VM_RESERVED | VM_IO)));
 
+	if (xen_feature(XENFEAT_auto_translated_physmap)) {
+		/* We need to update the local page tables and the xen HAP */
+		return pvh_remap_gmfn_range(vma, addr, mfn, nr, prot, domid,
+					    pvhp);
+	}
+
 	rmd.mfn = mfn;
 	rmd.prot = prot;
 
@@ -2371,3 +2518,26 @@ out:
 	return err;
 }
 EXPORT_SYMBOL_GPL(xen_remap_domain_mfn_range);
+
+/* Returns: Number of pages unmapped */
+int xen_unmap_domain_mfn_range(struct vm_area_struct *vma,
+			       struct xen_pvh_pfn_info *pvhp)
+{
+	int count = 0;
+
+	if (!pvhp || !xen_feature(XENFEAT_auto_translated_physmap))
+		return 0;
+
+	while (pvhp->pi_next_todo--) {
+		unsigned long pfn;
+
+		/* the mmu has already cleaned up the process mmu resources at
+		 * this point (lookup_address will return NULL). */
+		pfn = page_to_pfn(pvhp->pi_paga[pvhp->pi_next_todo]);
+		pvh_rem_xen_p2m(pfn, 1);
+		count++;
+	}
+	flush_tlb_all();
+	return count;
+}
+EXPORT_SYMBOL_GPL(xen_unmap_domain_mfn_range);
diff --git a/arch/x86/xen/mmu.h b/arch/x86/xen/mmu.h
index 73809bb..6d0bb56 100644
--- a/arch/x86/xen/mmu.h
+++ b/arch/x86/xen/mmu.h
@@ -23,4 +23,6 @@ unsigned long xen_read_cr2_direct(void);
 
 extern void xen_init_mmu_ops(void);
 extern void xen_hvm_init_mmu_ops(void);
+extern void xen_set_clr_mmio_pvh_pte(unsigned long pfn, unsigned long mfn,
+				     int nr_mfns, int add_mapping);
 #endif	/* _XEN_MMU_H */
diff --git a/include/xen/xen-ops.h b/include/xen/xen-ops.h
index 6a198e4..6c5ad83 100644
--- a/include/xen/xen-ops.h
+++ b/include/xen/xen-ops.h
@@ -24,9 +24,19 @@ int xen_create_contiguous_region(unsigned long vstart, unsigned int order,
 void xen_destroy_contiguous_region(unsigned long vstart, unsigned int order);
 
 struct vm_area_struct;
+struct xen_pvh_pfn_info;
 int xen_remap_domain_mfn_range(struct vm_area_struct *vma,
 			       unsigned long addr,
 			       unsigned long mfn, int nr,
-			       pgprot_t prot, unsigned domid);
+			       pgprot_t prot, unsigned domid,
+			       struct xen_pvh_pfn_info *pvhp);
+int xen_unmap_domain_mfn_range(struct vm_area_struct *vma,
+			       struct xen_pvh_pfn_info *pvhp);
+
+struct xen_pvh_pfn_info {
+	struct page **pi_paga;		/* pfn info page array */
+	int 	      pi_num_pgs;
+	int 	      pi_next_todo;
+};
 
 #endif /* INCLUDE_XEN_OPS_H */
-- 
1.7.2.3


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 21 19:17:23 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Sep 2012 19:17: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 1TF8it-0002wG-N6; Fri, 21 Sep 2012 19:17:11 +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 1TF8is-0002w5-Ui
	for Xen-devel@lists.xensource.com; Fri, 21 Sep 2012 19:17:11 +0000
Received: from [85.158.139.211:45311] by server-15.bemta-5.messagelabs.com id
	EB/3F-23541-63DBC505; Fri, 21 Sep 2012 19:17:10 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-11.tower-206.messagelabs.com!1348255028!19508578!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzU2MzI0\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9730 invoked from network); 21 Sep 2012 19:17:09 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-11.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 21 Sep 2012 19:17:09 -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 q8LJH3mQ007248
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 21 Sep 2012 19:17:04 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
	q8LJH38J021437
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 21 Sep 2012 19:17:03 GMT
Received: from abhmt109.oracle.com (abhmt109.oracle.com [141.146.116.61])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q8LJH26d009412; Fri, 21 Sep 2012 14:17:02 -0500
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 21 Sep 2012 12:17:02 -0700
Date: Fri, 21 Sep 2012 12:16:59 -0700
From: Mukesh Rathor <mukesh.rathor@oracle.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, "stefano.stabellini@eu.citrix.com"
	<stefano.stabellini@eu.citrix.com>
Message-ID: <20120921121659.5a723de9@mantra.us.oracle.com>
Organization: Oracle Corporation
X-Mailer: Claws Mail 3.7.6 (GTK+ 2.18.9; x86_64-redhat-linux-gnu)
Mime-Version: 1.0
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Subject: [Xen-devel] [PATCH v1 3/8]: PVH startup changes (enlighten.c)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

	
---
 arch/x86/xen/enlighten.c |   99 ++++++++++++++++++++++++++++++++++++---------
 1 files changed, 79 insertions(+), 20 deletions(-)

diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
index bf4bda6..98f1798 100644
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -45,6 +45,7 @@
 #include <xen/hvm.h>
 #include <xen/hvc-console.h>
 #include <xen/acpi.h>
+#include <xen/features.h>
 
 #include <asm/paravirt.h>
 #include <asm/apic.h>
@@ -105,6 +106,9 @@ RESERVE_BRK(shared_info_page_brk, PAGE_SIZE);
 __read_mostly int xen_have_vector_callback;
 EXPORT_SYMBOL_GPL(xen_have_vector_callback);
 
+#define xen_pvh_domain() (xen_pv_domain() && \
+			  xen_feature(XENFEAT_auto_translated_physmap) && \
+			  xen_have_vector_callback)
 /*
  * Point at some empty memory to start with. We map the real shared_info
  * page as soon as fixmap is up and running.
@@ -139,6 +143,8 @@ struct tls_descs {
  */
 static DEFINE_PER_CPU(struct tls_descs, shadow_tls_desc);
 
+static void __init xen_hvm_init_shared_info(void);
+
 static void clamp_max_cpus(void)
 {
 #ifdef CONFIG_SMP
@@ -217,8 +223,9 @@ static void __init xen_banner(void)
 	struct xen_extraversion extra;
 	HYPERVISOR_xen_version(XENVER_extraversion, &extra);
 
-	printk(KERN_INFO "Booting paravirtualized kernel on %s\n",
-	       pv_info.name);
+	printk(KERN_INFO "Booting paravirtualized kernel %son %s\n",
+		xen_feature(XENFEAT_auto_translated_physmap) ?
+			"with PVH extensions " : "", pv_info.name);
 	printk(KERN_INFO "Xen version: %d.%d%s%s\n",
 	       version >> 16, version & 0xffff, extra.extraversion,
 	       xen_feature(XENFEAT_mmu_pt_update_preserve_ad) ? " (preserve-AD)" : "");
@@ -271,12 +278,15 @@ static void xen_cpuid(unsigned int *ax, unsigned int *bx,
 		break;
 	}
 
-	asm(XEN_EMULATE_PREFIX "cpuid"
-		: "=a" (*ax),
-		  "=b" (*bx),
-		  "=c" (*cx),
-		  "=d" (*dx)
-		: "0" (*ax), "2" (*cx));
+	if (xen_pvh_domain())
+		native_cpuid(ax, bx, cx, dx);
+	else
+		asm(XEN_EMULATE_PREFIX "cpuid"
+			: "=a" (*ax),
+			"=b" (*bx),
+			"=c" (*cx),
+			"=d" (*dx)
+			: "0" (*ax), "2" (*cx));
 
 	*bx &= maskebx;
 	*cx &= maskecx;
@@ -1034,6 +1044,10 @@ static int xen_write_msr_safe(unsigned int msr, unsigned low, unsigned high)
 
 void xen_setup_shared_info(void)
 {
+	/* do later in xen_pvh_guest_init() when extend_brk is properly setup*/
+	if (xen_pvh_domain() && xen_initial_domain())
+		return;
+
 	if (!xen_feature(XENFEAT_auto_translated_physmap)) {
 		set_fixmap(FIX_PARAVIRT_BOOTMAP,
 			   xen_start_info->shared_info);
@@ -1044,6 +1058,10 @@ void xen_setup_shared_info(void)
 		HYPERVISOR_shared_info =
 			(struct shared_info *)__va(xen_start_info->shared_info);
 
+	/* PVH TBD/FIXME: vcpu info placement in phase 2 */
+	if (xen_pvh_domain())
+		return;
+
 #ifndef CONFIG_SMP
 	/* In UP this is as good a place as any to set up shared info */
 	xen_setup_vcpu_info_placement();
@@ -1274,6 +1292,11 @@ static const struct machine_ops xen_machine_ops __initconst = {
  */
 static void __init xen_setup_stackprotector(void)
 {
+	/* PVH TBD/FIXME: investigate setup_stack_canary_segment */
+	if (xen_feature(XENFEAT_auto_translated_physmap)) {
+		switch_to_new_gdt(0);
+		return;
+	}
 	pv_cpu_ops.write_gdt_entry = xen_write_gdt_entry_boot;
 	pv_cpu_ops.load_gdt = xen_load_gdt_boot;
 
@@ -1284,6 +1307,31 @@ static void __init xen_setup_stackprotector(void)
 	pv_cpu_ops.load_gdt = xen_load_gdt;
 }
 
+static void __init xen_pvh_guest_init(void)
+{
+	/* PVH TBD/FIXME: for now just disable this. */
+	have_vcpu_info_placement = 0;
+
+        /* for domU, the library sets start_info.shared_info to pfn, but for
+         * dom0, it contains mfn. we need to get the pfn for shared_info. PVH
+	 * uses HVM code in many places */
+	if (xen_initial_domain())
+		xen_hvm_init_shared_info();
+}
+
+static void __init xen_pvh_early_guest_init(void)
+{
+	if (xen_feature(XENFEAT_hvm_callback_vector))
+		xen_have_vector_callback = 1;
+
+#ifdef CONFIG_X86_32
+	if (xen_feature(XENFEAT_auto_translated_physmap)) {
+		xen_raw_printk("ERROR: 32bit PVH guests are not supported\n");
+		BUG();
+	}
+#endif
+}
+
 /* First C function to be called on Xen boot */
 asmlinkage void __init xen_start_kernel(void)
 {
@@ -1296,13 +1344,18 @@ asmlinkage void __init xen_start_kernel(void)
 
 	xen_domain_type = XEN_PV_DOMAIN;
 
+	xen_setup_features();
+	xen_pvh_early_guest_init();
 	xen_setup_machphys_mapping();
 
 	/* Install Xen paravirt ops */
 	pv_info = xen_info;
 	pv_init_ops = xen_init_ops;
-	pv_cpu_ops = xen_cpu_ops;
 	pv_apic_ops = xen_apic_ops;
+	if (xen_pvh_domain())
+		pv_cpu_ops.cpuid = xen_cpuid;
+	else
+		pv_cpu_ops = xen_cpu_ops;
 
 	x86_init.resources.memory_setup = xen_memory_setup;
 	x86_init.oem.arch_setup = xen_arch_setup;
@@ -1334,8 +1387,6 @@ asmlinkage void __init xen_start_kernel(void)
 	/* Work out if we support NX */
 	x86_configure_nx();
 
-	xen_setup_features();
-
 	/* Get mfn list */
 	if (!xen_feature(XENFEAT_auto_translated_physmap))
 		xen_build_dynamic_phys_to_machine();
@@ -1408,14 +1459,18 @@ asmlinkage void __init xen_start_kernel(void)
 	/* set the limit of our address space */
 	xen_reserve_top();
 
-	/* We used to do this in xen_arch_setup, but that is too late on AMD
-	 * were early_cpu_init (run before ->arch_setup()) calls early_amd_init
-	 * which pokes 0xcf8 port.
-	 */
-	set_iopl.iopl = 1;
-	rc = HYPERVISOR_physdev_op(PHYSDEVOP_set_iopl, &set_iopl);
-	if (rc != 0)
-		xen_raw_printk("physdev_op failed %d\n", rc);
+	/* PVH: runs at default kernel iopl of 0 */
+	if (!xen_pvh_domain()) {
+		/*
+		 * We used to do this in xen_arch_setup, but that is too late
+		 * on AMD were early_cpu_init (run before ->arch_setup()) calls
+		 * early_amd_init which pokes 0xcf8 port.
+		 */
+		set_iopl.iopl = 1;
+		rc = HYPERVISOR_physdev_op(PHYSDEVOP_set_iopl, &set_iopl);
+		if (rc != 0)
+			xen_raw_printk("physdev_op failed %d\n", rc);
+	}
 
 #ifdef CONFIG_X86_32
 	/* set up basic CPUID stuff */
@@ -1462,6 +1517,9 @@ asmlinkage void __init xen_start_kernel(void)
 
 	xen_setup_runstate_info(0);
 
+	if (xen_pvh_domain())
+		xen_pvh_guest_init();
+
 	/* Start the world */
 #ifdef CONFIG_X86_32
 	i386_start_kernel();
@@ -1585,7 +1643,8 @@ static struct syscore_ops xen_hvm_syscore_ops = {
 };
 #endif
 
-/* Use a pfn in RAM, may move to MMIO before kexec. */
+/* Use a pfn in RAM, may move to MMIO before kexec.
+ * This function also called for PVH dom0 */
 static void __init xen_hvm_init_shared_info(void)
 {
 	/* Remember pointer for resume */
-- 
1.7.2.3


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 21 19:17:23 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Sep 2012 19:17: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 1TF8it-0002wG-N6; Fri, 21 Sep 2012 19:17:11 +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 1TF8is-0002w5-Ui
	for Xen-devel@lists.xensource.com; Fri, 21 Sep 2012 19:17:11 +0000
Received: from [85.158.139.211:45311] by server-15.bemta-5.messagelabs.com id
	EB/3F-23541-63DBC505; Fri, 21 Sep 2012 19:17:10 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-11.tower-206.messagelabs.com!1348255028!19508578!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzU2MzI0\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9730 invoked from network); 21 Sep 2012 19:17:09 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-11.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 21 Sep 2012 19:17:09 -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 q8LJH3mQ007248
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 21 Sep 2012 19:17:04 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
	q8LJH38J021437
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 21 Sep 2012 19:17:03 GMT
Received: from abhmt109.oracle.com (abhmt109.oracle.com [141.146.116.61])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q8LJH26d009412; Fri, 21 Sep 2012 14:17:02 -0500
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 21 Sep 2012 12:17:02 -0700
Date: Fri, 21 Sep 2012 12:16:59 -0700
From: Mukesh Rathor <mukesh.rathor@oracle.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, "stefano.stabellini@eu.citrix.com"
	<stefano.stabellini@eu.citrix.com>
Message-ID: <20120921121659.5a723de9@mantra.us.oracle.com>
Organization: Oracle Corporation
X-Mailer: Claws Mail 3.7.6 (GTK+ 2.18.9; x86_64-redhat-linux-gnu)
Mime-Version: 1.0
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Subject: [Xen-devel] [PATCH v1 3/8]: PVH startup changes (enlighten.c)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

	
---
 arch/x86/xen/enlighten.c |   99 ++++++++++++++++++++++++++++++++++++---------
 1 files changed, 79 insertions(+), 20 deletions(-)

diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
index bf4bda6..98f1798 100644
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -45,6 +45,7 @@
 #include <xen/hvm.h>
 #include <xen/hvc-console.h>
 #include <xen/acpi.h>
+#include <xen/features.h>
 
 #include <asm/paravirt.h>
 #include <asm/apic.h>
@@ -105,6 +106,9 @@ RESERVE_BRK(shared_info_page_brk, PAGE_SIZE);
 __read_mostly int xen_have_vector_callback;
 EXPORT_SYMBOL_GPL(xen_have_vector_callback);
 
+#define xen_pvh_domain() (xen_pv_domain() && \
+			  xen_feature(XENFEAT_auto_translated_physmap) && \
+			  xen_have_vector_callback)
 /*
  * Point at some empty memory to start with. We map the real shared_info
  * page as soon as fixmap is up and running.
@@ -139,6 +143,8 @@ struct tls_descs {
  */
 static DEFINE_PER_CPU(struct tls_descs, shadow_tls_desc);
 
+static void __init xen_hvm_init_shared_info(void);
+
 static void clamp_max_cpus(void)
 {
 #ifdef CONFIG_SMP
@@ -217,8 +223,9 @@ static void __init xen_banner(void)
 	struct xen_extraversion extra;
 	HYPERVISOR_xen_version(XENVER_extraversion, &extra);
 
-	printk(KERN_INFO "Booting paravirtualized kernel on %s\n",
-	       pv_info.name);
+	printk(KERN_INFO "Booting paravirtualized kernel %son %s\n",
+		xen_feature(XENFEAT_auto_translated_physmap) ?
+			"with PVH extensions " : "", pv_info.name);
 	printk(KERN_INFO "Xen version: %d.%d%s%s\n",
 	       version >> 16, version & 0xffff, extra.extraversion,
 	       xen_feature(XENFEAT_mmu_pt_update_preserve_ad) ? " (preserve-AD)" : "");
@@ -271,12 +278,15 @@ static void xen_cpuid(unsigned int *ax, unsigned int *bx,
 		break;
 	}
 
-	asm(XEN_EMULATE_PREFIX "cpuid"
-		: "=a" (*ax),
-		  "=b" (*bx),
-		  "=c" (*cx),
-		  "=d" (*dx)
-		: "0" (*ax), "2" (*cx));
+	if (xen_pvh_domain())
+		native_cpuid(ax, bx, cx, dx);
+	else
+		asm(XEN_EMULATE_PREFIX "cpuid"
+			: "=a" (*ax),
+			"=b" (*bx),
+			"=c" (*cx),
+			"=d" (*dx)
+			: "0" (*ax), "2" (*cx));
 
 	*bx &= maskebx;
 	*cx &= maskecx;
@@ -1034,6 +1044,10 @@ static int xen_write_msr_safe(unsigned int msr, unsigned low, unsigned high)
 
 void xen_setup_shared_info(void)
 {
+	/* do later in xen_pvh_guest_init() when extend_brk is properly setup*/
+	if (xen_pvh_domain() && xen_initial_domain())
+		return;
+
 	if (!xen_feature(XENFEAT_auto_translated_physmap)) {
 		set_fixmap(FIX_PARAVIRT_BOOTMAP,
 			   xen_start_info->shared_info);
@@ -1044,6 +1058,10 @@ void xen_setup_shared_info(void)
 		HYPERVISOR_shared_info =
 			(struct shared_info *)__va(xen_start_info->shared_info);
 
+	/* PVH TBD/FIXME: vcpu info placement in phase 2 */
+	if (xen_pvh_domain())
+		return;
+
 #ifndef CONFIG_SMP
 	/* In UP this is as good a place as any to set up shared info */
 	xen_setup_vcpu_info_placement();
@@ -1274,6 +1292,11 @@ static const struct machine_ops xen_machine_ops __initconst = {
  */
 static void __init xen_setup_stackprotector(void)
 {
+	/* PVH TBD/FIXME: investigate setup_stack_canary_segment */
+	if (xen_feature(XENFEAT_auto_translated_physmap)) {
+		switch_to_new_gdt(0);
+		return;
+	}
 	pv_cpu_ops.write_gdt_entry = xen_write_gdt_entry_boot;
 	pv_cpu_ops.load_gdt = xen_load_gdt_boot;
 
@@ -1284,6 +1307,31 @@ static void __init xen_setup_stackprotector(void)
 	pv_cpu_ops.load_gdt = xen_load_gdt;
 }
 
+static void __init xen_pvh_guest_init(void)
+{
+	/* PVH TBD/FIXME: for now just disable this. */
+	have_vcpu_info_placement = 0;
+
+        /* for domU, the library sets start_info.shared_info to pfn, but for
+         * dom0, it contains mfn. we need to get the pfn for shared_info. PVH
+	 * uses HVM code in many places */
+	if (xen_initial_domain())
+		xen_hvm_init_shared_info();
+}
+
+static void __init xen_pvh_early_guest_init(void)
+{
+	if (xen_feature(XENFEAT_hvm_callback_vector))
+		xen_have_vector_callback = 1;
+
+#ifdef CONFIG_X86_32
+	if (xen_feature(XENFEAT_auto_translated_physmap)) {
+		xen_raw_printk("ERROR: 32bit PVH guests are not supported\n");
+		BUG();
+	}
+#endif
+}
+
 /* First C function to be called on Xen boot */
 asmlinkage void __init xen_start_kernel(void)
 {
@@ -1296,13 +1344,18 @@ asmlinkage void __init xen_start_kernel(void)
 
 	xen_domain_type = XEN_PV_DOMAIN;
 
+	xen_setup_features();
+	xen_pvh_early_guest_init();
 	xen_setup_machphys_mapping();
 
 	/* Install Xen paravirt ops */
 	pv_info = xen_info;
 	pv_init_ops = xen_init_ops;
-	pv_cpu_ops = xen_cpu_ops;
 	pv_apic_ops = xen_apic_ops;
+	if (xen_pvh_domain())
+		pv_cpu_ops.cpuid = xen_cpuid;
+	else
+		pv_cpu_ops = xen_cpu_ops;
 
 	x86_init.resources.memory_setup = xen_memory_setup;
 	x86_init.oem.arch_setup = xen_arch_setup;
@@ -1334,8 +1387,6 @@ asmlinkage void __init xen_start_kernel(void)
 	/* Work out if we support NX */
 	x86_configure_nx();
 
-	xen_setup_features();
-
 	/* Get mfn list */
 	if (!xen_feature(XENFEAT_auto_translated_physmap))
 		xen_build_dynamic_phys_to_machine();
@@ -1408,14 +1459,18 @@ asmlinkage void __init xen_start_kernel(void)
 	/* set the limit of our address space */
 	xen_reserve_top();
 
-	/* We used to do this in xen_arch_setup, but that is too late on AMD
-	 * were early_cpu_init (run before ->arch_setup()) calls early_amd_init
-	 * which pokes 0xcf8 port.
-	 */
-	set_iopl.iopl = 1;
-	rc = HYPERVISOR_physdev_op(PHYSDEVOP_set_iopl, &set_iopl);
-	if (rc != 0)
-		xen_raw_printk("physdev_op failed %d\n", rc);
+	/* PVH: runs at default kernel iopl of 0 */
+	if (!xen_pvh_domain()) {
+		/*
+		 * We used to do this in xen_arch_setup, but that is too late
+		 * on AMD were early_cpu_init (run before ->arch_setup()) calls
+		 * early_amd_init which pokes 0xcf8 port.
+		 */
+		set_iopl.iopl = 1;
+		rc = HYPERVISOR_physdev_op(PHYSDEVOP_set_iopl, &set_iopl);
+		if (rc != 0)
+			xen_raw_printk("physdev_op failed %d\n", rc);
+	}
 
 #ifdef CONFIG_X86_32
 	/* set up basic CPUID stuff */
@@ -1462,6 +1517,9 @@ asmlinkage void __init xen_start_kernel(void)
 
 	xen_setup_runstate_info(0);
 
+	if (xen_pvh_domain())
+		xen_pvh_guest_init();
+
 	/* Start the world */
 #ifdef CONFIG_X86_32
 	i386_start_kernel();
@@ -1585,7 +1643,8 @@ static struct syscore_ops xen_hvm_syscore_ops = {
 };
 #endif
 
-/* Use a pfn in RAM, may move to MMIO before kexec. */
+/* Use a pfn in RAM, may move to MMIO before kexec.
+ * This function also called for PVH dom0 */
 static void __init xen_hvm_init_shared_info(void)
 {
 	/* Remember pointer for resume */
-- 
1.7.2.3


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 21 19:18:17 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Sep 2012 19:18:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TF8jm-00033W-9f; Fri, 21 Sep 2012 19:18:06 +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 1TF8jk-00033F-Q9
	for Xen-devel@lists.xensource.com; Fri, 21 Sep 2012 19:18:05 +0000
Received: from [85.158.138.51:63320] by server-6.bemta-3.messagelabs.com id
	2F/CF-29694-B6DBC505; Fri, 21 Sep 2012 19:18:03 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1348255082!29725701!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDc2NjM1OA==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 440 invoked from network); 21 Sep 2012 19:18:03 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-15.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 21 Sep 2012 19:18:03 -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 q8LJHtdp022008
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 21 Sep 2012 19:17:55 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
	q8LJHst2008721
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 21 Sep 2012 19:17:55 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
	q8LJHsT8030916; Fri, 21 Sep 2012 14:17:54 -0500
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 21 Sep 2012 12:17:54 -0700
Date: Fri, 21 Sep 2012 12:17:52 -0700
From: Mukesh Rathor <mukesh.rathor@oracle.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, "stefano.stabellini@eu.citrix.com"
	<stefano.stabellini@eu.citrix.com>
Message-ID: <20120921121752.5fa80b35@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] [PATCH v1 4/8]: PVH setup 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


---
 arch/x86/xen/setup.c |   51 ++++++++++++++++++++++++++++++++++++++++++-------
 1 files changed, 43 insertions(+), 8 deletions(-)

diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c
index ead8557..fba442e 100644
--- a/arch/x86/xen/setup.c
+++ b/arch/x86/xen/setup.c
@@ -26,6 +26,7 @@
 #include <xen/interface/memory.h>
 #include <xen/interface/physdev.h>
 #include <xen/features.h>
+#include "mmu.h"
 #include "xen-ops.h"
 #include "vdso.h"
 
@@ -222,6 +223,26 @@ static void __init xen_set_identity_and_release_chunk(
 	*identity += set_phys_range_identity(start_pfn, end_pfn);
 }
 
+/* For PVH, the pfns [0..MAX] are mapped to mfn's in the EPT/NPT. The mfns
+ * are released as part of this 1:1 mapping hypercall back to the dom heap. We
+ * don't use the xen_do_chunk() PV does above because when P2M/EPT/NPT is 
+ * updated, the mfns are already lost as part of the p2m update.
+ * Also, we map the entire IO space, ie, beyond max_pfn_mapped.
+ */
+static void __init xen_pvh_identity_map_chunk(unsigned long start_pfn,
+		unsigned long end_pfn, unsigned long *released, 
+		unsigned long *identity)
+{
+	unsigned long pfn;
+	int numpfns=1, add_mapping=1;
+
+	for (pfn = start_pfn; pfn < end_pfn; pfn++)
+		xen_set_clr_mmio_pvh_pte(pfn, pfn, numpfns, add_mapping);
+
+	*released += end_pfn - start_pfn;
+	*identity += end_pfn - start_pfn;
+}
+
 static unsigned long __init xen_set_identity_and_release(
 	const struct e820entry *list, size_t map_size, unsigned long nr_pages)
 {
@@ -230,6 +251,7 @@ static unsigned long __init xen_set_identity_and_release(
 	unsigned long identity = 0;
 	const struct e820entry *entry;
 	int i;
+	int xlated_phys = xen_feature(XENFEAT_auto_translated_physmap);
 
 	/*
 	 * Combine non-RAM regions and gaps until a RAM region (or the
@@ -251,11 +273,16 @@ static unsigned long __init xen_set_identity_and_release(
 			if (entry->type == E820_RAM)
 				end_pfn = PFN_UP(entry->addr);
 
-			if (start_pfn < end_pfn)
-				xen_set_identity_and_release_chunk(
-					start_pfn, end_pfn, nr_pages,
-					&released, &identity);
-
+			if (start_pfn < end_pfn) {
+				if (xlated_phys) {
+					xen_pvh_identity_map_chunk(start_pfn, 
+						end_pfn, &released, &identity);
+				} else {
+					xen_set_identity_and_release_chunk(
+						start_pfn, end_pfn, nr_pages,
+						&released, &identity);
+				}
+			}
 			start = end;
 		}
 	}
@@ -500,10 +527,9 @@ void __cpuinit xen_enable_syscall(void)
 #endif /* CONFIG_X86_64 */
 }
 
-void __init xen_arch_setup(void)
+/* Non auto translated PV domain, ie, it's not PVH. */
+static __init void inline xen_non_pvh_arch_setup(void)
 {
-	xen_panic_handler_init();
-
 	HYPERVISOR_vm_assist(VMASST_CMD_enable, VMASST_TYPE_4gb_segments);
 	HYPERVISOR_vm_assist(VMASST_CMD_enable, VMASST_TYPE_writable_pagetables);
 
@@ -517,6 +543,15 @@ void __init xen_arch_setup(void)
 
 	xen_enable_sysenter();
 	xen_enable_syscall();
+}
+
+/* This function not called for HVM domain */
+void __init xen_arch_setup(void)
+{
+	xen_panic_handler_init();
+
+	if (!xen_feature(XENFEAT_auto_translated_physmap))
+		xen_non_pvh_arch_setup();
 
 #ifdef CONFIG_ACPI
 	if (!(xen_start_info->flags & SIF_INITDOMAIN)) {
-- 
1.7.2.3


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 21 19:18:17 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Sep 2012 19:18:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TF8jm-00033W-9f; Fri, 21 Sep 2012 19:18:06 +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 1TF8jk-00033F-Q9
	for Xen-devel@lists.xensource.com; Fri, 21 Sep 2012 19:18:05 +0000
Received: from [85.158.138.51:63320] by server-6.bemta-3.messagelabs.com id
	2F/CF-29694-B6DBC505; Fri, 21 Sep 2012 19:18:03 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1348255082!29725701!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDc2NjM1OA==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 440 invoked from network); 21 Sep 2012 19:18:03 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-15.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 21 Sep 2012 19:18:03 -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 q8LJHtdp022008
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 21 Sep 2012 19:17:55 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
	q8LJHst2008721
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 21 Sep 2012 19:17:55 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
	q8LJHsT8030916; Fri, 21 Sep 2012 14:17:54 -0500
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 21 Sep 2012 12:17:54 -0700
Date: Fri, 21 Sep 2012 12:17:52 -0700
From: Mukesh Rathor <mukesh.rathor@oracle.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, "stefano.stabellini@eu.citrix.com"
	<stefano.stabellini@eu.citrix.com>
Message-ID: <20120921121752.5fa80b35@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] [PATCH v1 4/8]: PVH setup 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


---
 arch/x86/xen/setup.c |   51 ++++++++++++++++++++++++++++++++++++++++++-------
 1 files changed, 43 insertions(+), 8 deletions(-)

diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c
index ead8557..fba442e 100644
--- a/arch/x86/xen/setup.c
+++ b/arch/x86/xen/setup.c
@@ -26,6 +26,7 @@
 #include <xen/interface/memory.h>
 #include <xen/interface/physdev.h>
 #include <xen/features.h>
+#include "mmu.h"
 #include "xen-ops.h"
 #include "vdso.h"
 
@@ -222,6 +223,26 @@ static void __init xen_set_identity_and_release_chunk(
 	*identity += set_phys_range_identity(start_pfn, end_pfn);
 }
 
+/* For PVH, the pfns [0..MAX] are mapped to mfn's in the EPT/NPT. The mfns
+ * are released as part of this 1:1 mapping hypercall back to the dom heap. We
+ * don't use the xen_do_chunk() PV does above because when P2M/EPT/NPT is 
+ * updated, the mfns are already lost as part of the p2m update.
+ * Also, we map the entire IO space, ie, beyond max_pfn_mapped.
+ */
+static void __init xen_pvh_identity_map_chunk(unsigned long start_pfn,
+		unsigned long end_pfn, unsigned long *released, 
+		unsigned long *identity)
+{
+	unsigned long pfn;
+	int numpfns=1, add_mapping=1;
+
+	for (pfn = start_pfn; pfn < end_pfn; pfn++)
+		xen_set_clr_mmio_pvh_pte(pfn, pfn, numpfns, add_mapping);
+
+	*released += end_pfn - start_pfn;
+	*identity += end_pfn - start_pfn;
+}
+
 static unsigned long __init xen_set_identity_and_release(
 	const struct e820entry *list, size_t map_size, unsigned long nr_pages)
 {
@@ -230,6 +251,7 @@ static unsigned long __init xen_set_identity_and_release(
 	unsigned long identity = 0;
 	const struct e820entry *entry;
 	int i;
+	int xlated_phys = xen_feature(XENFEAT_auto_translated_physmap);
 
 	/*
 	 * Combine non-RAM regions and gaps until a RAM region (or the
@@ -251,11 +273,16 @@ static unsigned long __init xen_set_identity_and_release(
 			if (entry->type == E820_RAM)
 				end_pfn = PFN_UP(entry->addr);
 
-			if (start_pfn < end_pfn)
-				xen_set_identity_and_release_chunk(
-					start_pfn, end_pfn, nr_pages,
-					&released, &identity);
-
+			if (start_pfn < end_pfn) {
+				if (xlated_phys) {
+					xen_pvh_identity_map_chunk(start_pfn, 
+						end_pfn, &released, &identity);
+				} else {
+					xen_set_identity_and_release_chunk(
+						start_pfn, end_pfn, nr_pages,
+						&released, &identity);
+				}
+			}
 			start = end;
 		}
 	}
@@ -500,10 +527,9 @@ void __cpuinit xen_enable_syscall(void)
 #endif /* CONFIG_X86_64 */
 }
 
-void __init xen_arch_setup(void)
+/* Non auto translated PV domain, ie, it's not PVH. */
+static __init void inline xen_non_pvh_arch_setup(void)
 {
-	xen_panic_handler_init();
-
 	HYPERVISOR_vm_assist(VMASST_CMD_enable, VMASST_TYPE_4gb_segments);
 	HYPERVISOR_vm_assist(VMASST_CMD_enable, VMASST_TYPE_writable_pagetables);
 
@@ -517,6 +543,15 @@ void __init xen_arch_setup(void)
 
 	xen_enable_sysenter();
 	xen_enable_syscall();
+}
+
+/* This function not called for HVM domain */
+void __init xen_arch_setup(void)
+{
+	xen_panic_handler_init();
+
+	if (!xen_feature(XENFEAT_auto_translated_physmap))
+		xen_non_pvh_arch_setup();
 
 #ifdef CONFIG_ACPI
 	if (!(xen_start_info->flags & SIF_INITDOMAIN)) {
-- 
1.7.2.3


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 21 19:18:52 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Sep 2012 19: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 1TF8kP-00039C-Nh; Fri, 21 Sep 2012 19:18:45 +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 1TF8kN-00038t-TG
	for Xen-devel@lists.xensource.com; Fri, 21 Sep 2012 19:18:44 +0000
Received: from [85.158.143.99:57815] by server-1.bemta-4.messagelabs.com id
	EA/99-05684-39DBC505; Fri, 21 Sep 2012 19:18:43 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1348255121!21695112!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDc2NjM1OA==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21891 invoked from network); 21 Sep 2012 19:18: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; 21 Sep 2012 19:18:42 -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 q8LJIb7q023011
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 21 Sep 2012 19:18:37 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q8LJIaGb010335
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 21 Sep 2012 19:18:37 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
	q8LJIaEw031336; Fri, 21 Sep 2012 14:18:36 -0500
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 21 Sep 2012 12:18:36 -0700
Date: Fri, 21 Sep 2012 12:18:35 -0700
From: Mukesh Rathor <mukesh.rathor@oracle.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
	"stefano.stabellini@eu.citrix.com" <stefano.stabellini@eu.citrix.com>, Ian
	Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120921121835.300851d8@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] [PATCH v1 5/8]: PVH smp 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


---
 arch/x86/xen/smp.c |   75 ++++++++++++++++++++++++++++++++++------------------
 1 files changed, 49 insertions(+), 26 deletions(-)

diff --git a/arch/x86/xen/smp.c b/arch/x86/xen/smp.c
index f58dca7..e1e8582 100644
--- a/arch/x86/xen/smp.c
+++ b/arch/x86/xen/smp.c
@@ -68,9 +68,11 @@ static void __cpuinit cpu_bringup(void)
 	touch_softlockup_watchdog();
 	preempt_disable();
 
-	xen_enable_sysenter();
-	xen_enable_syscall();
-
+	/* PVH runs in ring 0 and allows us to do native syscalls. Yay! */
+	if (!xen_feature(XENFEAT_supervisor_mode_kernel)) {
+		xen_enable_sysenter();
+		xen_enable_syscall();
+	}
 	cpu = smp_processor_id();
 	smp_store_cpu_info(cpu);
 	cpu_data(cpu).x86_max_cores = 1;
@@ -230,10 +232,11 @@ static void __init xen_smp_prepare_boot_cpu(void)
 	BUG_ON(smp_processor_id() != 0);
 	native_smp_prepare_boot_cpu();
 
-	/* We've switched to the "real" per-cpu gdt, so make sure the
-	   old memory can be recycled */
-	make_lowmem_page_readwrite(xen_initial_gdt);
-
+	if (!xen_feature(XENFEAT_writable_page_tables)) {
+		/* We've switched to the "real" per-cpu gdt, so make sure the
+	   	 * old memory can be recycled */
+		make_lowmem_page_readwrite(xen_initial_gdt);
+	}
 	xen_filter_cpu_maps();
 	xen_setup_vcpu_info_placement();
 }
@@ -300,8 +303,6 @@ cpu_initialize_context(unsigned int cpu, struct task_struct *idle)
 	gdt = get_cpu_gdt_table(cpu);
 
 	ctxt->flags = VGCF_IN_KERNEL;
-	ctxt->user_regs.ds = __USER_DS;
-	ctxt->user_regs.es = __USER_DS;
 	ctxt->user_regs.ss = __KERNEL_DS;
 #ifdef CONFIG_X86_32
 	ctxt->user_regs.fs = __KERNEL_PERCPU;
@@ -310,35 +311,57 @@ cpu_initialize_context(unsigned int cpu, struct task_struct *idle)
 	ctxt->gs_base_kernel = per_cpu_offset(cpu);
 #endif
 	ctxt->user_regs.eip = (unsigned long)cpu_bringup_and_idle;
-	ctxt->user_regs.eflags = 0x1000; /* IOPL_RING1 */
 
 	memset(&ctxt->fpu_ctxt, 0, sizeof(ctxt->fpu_ctxt));
 
-	xen_copy_trap_info(ctxt->trap_ctxt);
+	/* check for autoxlated to get it right for 32bit kernel */
+	if (xen_feature(XENFEAT_auto_translated_physmap) &&
+	    xen_feature(XENFEAT_supervisor_mode_kernel)) {
 
-	ctxt->ldt_ents = 0;
+		ctxt->user_regs.ds = __KERNEL_DS;
+		ctxt->user_regs.es = 0;
+		ctxt->user_regs.gs = 0;
 
-	BUG_ON((unsigned long)gdt & ~PAGE_MASK);
+		ctxt->gdt_frames[0] = (unsigned long)gdt;
+		ctxt->gdt_ents = (unsigned long)(GDT_SIZE - 1);
 
-	gdt_mfn = arbitrary_virt_to_mfn(gdt);
-	make_lowmem_page_readonly(gdt);
-	make_lowmem_page_readonly(mfn_to_virt(gdt_mfn));
+#ifdef CONFIG_X86_64
+		/* Note: PVH is not supported on x86_32. */
+		ctxt->gs_base_user = (unsigned long)
+		                         per_cpu(irq_stack_union.gs_base, cpu);
+#endif
+	} else {
+		ctxt->user_regs.eflags = 0x1000; /* IOPL_RING1 */
+		ctxt->user_regs.ds = __USER_DS;
+		ctxt->user_regs.es = __USER_DS;
 
-	ctxt->gdt_frames[0] = gdt_mfn;
-	ctxt->gdt_ents      = GDT_ENTRIES;
+		xen_copy_trap_info(ctxt->trap_ctxt);
 
-	ctxt->user_regs.cs = __KERNEL_CS;
-	ctxt->user_regs.esp = idle->thread.sp0 - sizeof(struct pt_regs);
+		ctxt->ldt_ents = 0;
 
-	ctxt->kernel_ss = __KERNEL_DS;
-	ctxt->kernel_sp = idle->thread.sp0;
+		BUG_ON((unsigned long)gdt & ~PAGE_MASK);
+
+		gdt_mfn = arbitrary_virt_to_mfn(gdt);
+		make_lowmem_page_readonly(gdt);
+		make_lowmem_page_readonly(mfn_to_virt(gdt_mfn));
+
+		ctxt->gdt_frames[0] = gdt_mfn;
+		ctxt->gdt_ents      = GDT_ENTRIES;
+
+		ctxt->kernel_ss = __KERNEL_DS;
+		ctxt->kernel_sp = idle->thread.sp0;
 
 #ifdef CONFIG_X86_32
-	ctxt->event_callback_cs     = __KERNEL_CS;
-	ctxt->failsafe_callback_cs  = __KERNEL_CS;
+		ctxt->event_callback_cs     = __KERNEL_CS;
+		ctxt->failsafe_callback_cs  = __KERNEL_CS;
 #endif
-	ctxt->event_callback_eip    = (unsigned long)xen_hypervisor_callback;
-	ctxt->failsafe_callback_eip = (unsigned long)xen_failsafe_callback;
+		ctxt->event_callback_eip    = 
+					(unsigned long)xen_hypervisor_callback;
+		ctxt->failsafe_callback_eip = 
+					(unsigned long)xen_failsafe_callback;
+	}
+	ctxt->user_regs.cs = __KERNEL_CS;
+	ctxt->user_regs.esp = idle->thread.sp0 - sizeof(struct pt_regs);
 
 	per_cpu(xen_cr3, cpu) = __pa(swapper_pg_dir);
 	ctxt->ctrlreg[3] = xen_pfn_to_cr3(virt_to_mfn(swapper_pg_dir));
-- 
1.7.2.3


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 21 19:18:52 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Sep 2012 19: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 1TF8kP-00039C-Nh; Fri, 21 Sep 2012 19:18:45 +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 1TF8kN-00038t-TG
	for Xen-devel@lists.xensource.com; Fri, 21 Sep 2012 19:18:44 +0000
Received: from [85.158.143.99:57815] by server-1.bemta-4.messagelabs.com id
	EA/99-05684-39DBC505; Fri, 21 Sep 2012 19:18:43 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1348255121!21695112!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDc2NjM1OA==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21891 invoked from network); 21 Sep 2012 19:18: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; 21 Sep 2012 19:18:42 -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 q8LJIb7q023011
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 21 Sep 2012 19:18:37 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q8LJIaGb010335
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 21 Sep 2012 19:18:37 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
	q8LJIaEw031336; Fri, 21 Sep 2012 14:18:36 -0500
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 21 Sep 2012 12:18:36 -0700
Date: Fri, 21 Sep 2012 12:18:35 -0700
From: Mukesh Rathor <mukesh.rathor@oracle.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
	"stefano.stabellini@eu.citrix.com" <stefano.stabellini@eu.citrix.com>, Ian
	Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120921121835.300851d8@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] [PATCH v1 5/8]: PVH smp 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


---
 arch/x86/xen/smp.c |   75 ++++++++++++++++++++++++++++++++++------------------
 1 files changed, 49 insertions(+), 26 deletions(-)

diff --git a/arch/x86/xen/smp.c b/arch/x86/xen/smp.c
index f58dca7..e1e8582 100644
--- a/arch/x86/xen/smp.c
+++ b/arch/x86/xen/smp.c
@@ -68,9 +68,11 @@ static void __cpuinit cpu_bringup(void)
 	touch_softlockup_watchdog();
 	preempt_disable();
 
-	xen_enable_sysenter();
-	xen_enable_syscall();
-
+	/* PVH runs in ring 0 and allows us to do native syscalls. Yay! */
+	if (!xen_feature(XENFEAT_supervisor_mode_kernel)) {
+		xen_enable_sysenter();
+		xen_enable_syscall();
+	}
 	cpu = smp_processor_id();
 	smp_store_cpu_info(cpu);
 	cpu_data(cpu).x86_max_cores = 1;
@@ -230,10 +232,11 @@ static void __init xen_smp_prepare_boot_cpu(void)
 	BUG_ON(smp_processor_id() != 0);
 	native_smp_prepare_boot_cpu();
 
-	/* We've switched to the "real" per-cpu gdt, so make sure the
-	   old memory can be recycled */
-	make_lowmem_page_readwrite(xen_initial_gdt);
-
+	if (!xen_feature(XENFEAT_writable_page_tables)) {
+		/* We've switched to the "real" per-cpu gdt, so make sure the
+	   	 * old memory can be recycled */
+		make_lowmem_page_readwrite(xen_initial_gdt);
+	}
 	xen_filter_cpu_maps();
 	xen_setup_vcpu_info_placement();
 }
@@ -300,8 +303,6 @@ cpu_initialize_context(unsigned int cpu, struct task_struct *idle)
 	gdt = get_cpu_gdt_table(cpu);
 
 	ctxt->flags = VGCF_IN_KERNEL;
-	ctxt->user_regs.ds = __USER_DS;
-	ctxt->user_regs.es = __USER_DS;
 	ctxt->user_regs.ss = __KERNEL_DS;
 #ifdef CONFIG_X86_32
 	ctxt->user_regs.fs = __KERNEL_PERCPU;
@@ -310,35 +311,57 @@ cpu_initialize_context(unsigned int cpu, struct task_struct *idle)
 	ctxt->gs_base_kernel = per_cpu_offset(cpu);
 #endif
 	ctxt->user_regs.eip = (unsigned long)cpu_bringup_and_idle;
-	ctxt->user_regs.eflags = 0x1000; /* IOPL_RING1 */
 
 	memset(&ctxt->fpu_ctxt, 0, sizeof(ctxt->fpu_ctxt));
 
-	xen_copy_trap_info(ctxt->trap_ctxt);
+	/* check for autoxlated to get it right for 32bit kernel */
+	if (xen_feature(XENFEAT_auto_translated_physmap) &&
+	    xen_feature(XENFEAT_supervisor_mode_kernel)) {
 
-	ctxt->ldt_ents = 0;
+		ctxt->user_regs.ds = __KERNEL_DS;
+		ctxt->user_regs.es = 0;
+		ctxt->user_regs.gs = 0;
 
-	BUG_ON((unsigned long)gdt & ~PAGE_MASK);
+		ctxt->gdt_frames[0] = (unsigned long)gdt;
+		ctxt->gdt_ents = (unsigned long)(GDT_SIZE - 1);
 
-	gdt_mfn = arbitrary_virt_to_mfn(gdt);
-	make_lowmem_page_readonly(gdt);
-	make_lowmem_page_readonly(mfn_to_virt(gdt_mfn));
+#ifdef CONFIG_X86_64
+		/* Note: PVH is not supported on x86_32. */
+		ctxt->gs_base_user = (unsigned long)
+		                         per_cpu(irq_stack_union.gs_base, cpu);
+#endif
+	} else {
+		ctxt->user_regs.eflags = 0x1000; /* IOPL_RING1 */
+		ctxt->user_regs.ds = __USER_DS;
+		ctxt->user_regs.es = __USER_DS;
 
-	ctxt->gdt_frames[0] = gdt_mfn;
-	ctxt->gdt_ents      = GDT_ENTRIES;
+		xen_copy_trap_info(ctxt->trap_ctxt);
 
-	ctxt->user_regs.cs = __KERNEL_CS;
-	ctxt->user_regs.esp = idle->thread.sp0 - sizeof(struct pt_regs);
+		ctxt->ldt_ents = 0;
 
-	ctxt->kernel_ss = __KERNEL_DS;
-	ctxt->kernel_sp = idle->thread.sp0;
+		BUG_ON((unsigned long)gdt & ~PAGE_MASK);
+
+		gdt_mfn = arbitrary_virt_to_mfn(gdt);
+		make_lowmem_page_readonly(gdt);
+		make_lowmem_page_readonly(mfn_to_virt(gdt_mfn));
+
+		ctxt->gdt_frames[0] = gdt_mfn;
+		ctxt->gdt_ents      = GDT_ENTRIES;
+
+		ctxt->kernel_ss = __KERNEL_DS;
+		ctxt->kernel_sp = idle->thread.sp0;
 
 #ifdef CONFIG_X86_32
-	ctxt->event_callback_cs     = __KERNEL_CS;
-	ctxt->failsafe_callback_cs  = __KERNEL_CS;
+		ctxt->event_callback_cs     = __KERNEL_CS;
+		ctxt->failsafe_callback_cs  = __KERNEL_CS;
 #endif
-	ctxt->event_callback_eip    = (unsigned long)xen_hypervisor_callback;
-	ctxt->failsafe_callback_eip = (unsigned long)xen_failsafe_callback;
+		ctxt->event_callback_eip    = 
+					(unsigned long)xen_hypervisor_callback;
+		ctxt->failsafe_callback_eip = 
+					(unsigned long)xen_failsafe_callback;
+	}
+	ctxt->user_regs.cs = __KERNEL_CS;
+	ctxt->user_regs.esp = idle->thread.sp0 - sizeof(struct pt_regs);
 
 	per_cpu(xen_cr3, cpu) = __pa(swapper_pg_dir);
 	ctxt->ctrlreg[3] = xen_pfn_to_cr3(virt_to_mfn(swapper_pg_dir));
-- 
1.7.2.3


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 21 19:19:50 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Sep 2012 19:19: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 1TF8lM-0003Ia-5z; Fri, 21 Sep 2012 19:19:44 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mukesh.rathor@oracle.com>) id 1TF8lK-0003He-Of
	for Xen-devel@lists.xensource.com; Fri, 21 Sep 2012 19:19:43 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1348255175!8618826!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDc2NjM1OA==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1323 invoked from network); 21 Sep 2012 19:19:36 -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 Sep 2012 19:19:36 -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 q8LJJUwh024059
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 21 Sep 2012 19:19:31 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q8LJJUYZ012271
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 21 Sep 2012 19:19:30 GMT
Received: from abhmt102.oracle.com (abhmt102.oracle.com [141.146.116.54])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q8LJJTtA031890; Fri, 21 Sep 2012 14:19:30 -0500
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 21 Sep 2012 12:19:29 -0700
Date: Fri, 21 Sep 2012 12:19:28 -0700
From: Mukesh Rathor <mukesh.rathor@oracle.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, "stefano.stabellini@eu.citrix.com"
	<stefano.stabellini@eu.citrix.com>
Message-ID: <20120921121928.1c5765bc@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] [PATCH v1 6/8]: PVH ballooning and grant 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


---
 drivers/xen/balloon.c     |   35 ++++++++++++++++++++++++++++-------
 drivers/xen/gntdev.c      |    3 ++-
 drivers/xen/grant-table.c |   25 +++++++++++++++++++++----
 3 files changed, 51 insertions(+), 12 deletions(-)

diff --git a/drivers/xen/balloon.c b/drivers/xen/balloon.c
index 31ab82f..85a6917 100644
--- a/drivers/xen/balloon.c
+++ b/drivers/xen/balloon.c
@@ -358,10 +358,21 @@ static enum bp_state increase_reservation(unsigned long nr_pages)
 		BUG_ON(!xen_feature(XENFEAT_auto_translated_physmap) &&
 		       phys_to_machine_mapping_valid(pfn));
 
-		set_phys_to_machine(pfn, frame_list[i]);
+		if (xen_pv_domain() && 
+		    xen_feature(XENFEAT_auto_translated_physmap)) {
+			/* PVH: we just need to update native page table */
+			pte_t *ptep;
+			unsigned int level;
+			void *addr = __va(pfn << PAGE_SHIFT);
+			ptep = lookup_address((unsigned long)addr, &level);
+			set_pte(ptep, pfn_pte(pfn, PAGE_KERNEL));
+		} else
+			set_phys_to_machine(pfn, frame_list[i]);
 
 		/* Link back into the page tables if not highmem. */
-		if (xen_pv_domain() && !PageHighMem(page)) {
+		if (xen_pv_domain() && !PageHighMem(page) && 
+		    !xen_feature(XENFEAT_auto_translated_physmap)) {
+
 			int ret;
 			ret = HYPERVISOR_update_va_mapping(
 				(unsigned long)__va(pfn << PAGE_SHIFT),
@@ -418,12 +429,21 @@ static enum bp_state decrease_reservation(unsigned long nr_pages, gfp_t gfp)
 		scrub_page(page);
 
 		if (xen_pv_domain() && !PageHighMem(page)) {
-			ret = HYPERVISOR_update_va_mapping(
-				(unsigned long)__va(pfn << PAGE_SHIFT),
-				__pte_ma(0), 0);
-			BUG_ON(ret);
+			if (xen_feature(XENFEAT_auto_translated_physmap)) {
+				unsigned int level;
+				pte_t *ptep;
+				void *addr = __va(pfn << PAGE_SHIFT);
+				ptep = lookup_address((unsigned long)addr, 
+							&level);
+				set_pte(ptep, __pte(0));
+
+			} else {
+				ret = HYPERVISOR_update_va_mapping(
+					(unsigned long)__va(pfn << PAGE_SHIFT),
+					__pte_ma(0), 0);
+				BUG_ON(ret);
+			}
 		}
-
 	}
 
 	/* Ensure that ballooned highmem pages don't have kmaps. */
@@ -433,6 +453,7 @@ static enum bp_state decrease_reservation(unsigned long nr_pages, gfp_t gfp)
 	/* No more mappings: invalidate P2M and add to balloon. */
 	for (i = 0; i < nr_pages; i++) {
 		pfn = mfn_to_pfn(frame_list[i]);
+		/* PVH note: following will noop for auto translated */
 		__set_phys_to_machine(pfn, INVALID_P2M_ENTRY);
 		balloon_append(pfn_to_page(pfn));
 	}
diff --git a/drivers/xen/gntdev.c b/drivers/xen/gntdev.c
index 1ffd03b..35d1e3c 100644
--- a/drivers/xen/gntdev.c
+++ b/drivers/xen/gntdev.c
@@ -802,7 +802,8 @@ static int __init gntdev_init(void)
 	if (!xen_domain())
 		return -ENODEV;
 
-	use_ptemod = xen_pv_domain();
+	use_ptemod = xen_pv_domain() && 
+		     !xen_feature(XENFEAT_auto_translated_physmap);
 
 	err = misc_register(&gntdev_miscdev);
 	if (err != 0) {
diff --git a/drivers/xen/grant-table.c b/drivers/xen/grant-table.c
index 0bfc1ef..d831d52 100644
--- a/drivers/xen/grant-table.c
+++ b/drivers/xen/grant-table.c
@@ -974,14 +974,19 @@ static void gnttab_unmap_frames_v2(void)
 static int gnttab_map(unsigned int start_idx, unsigned int end_idx)
 {
 	struct gnttab_setup_table setup;
-	unsigned long *frames;
+	unsigned long *frames, start_gpfn;
 	unsigned int nr_gframes = end_idx + 1;
 	int rc;
 
-	if (xen_hvm_domain()) {
+	if (xen_hvm_domain() || xen_feature(XENFEAT_auto_translated_physmap)) {
 		struct xen_add_to_physmap xatp;
 		unsigned int i = end_idx;
 		rc = 0;
+
+		if (xen_hvm_domain())
+			start_gpfn = xen_hvm_resume_frames >> PAGE_SHIFT;
+		else
+			start_gpfn = virt_to_pfn(gnttab_shared.addr);
 		/*
 		 * Loop backwards, so that the first hypercall has the largest
 		 * index, ensuring that the table will grow only once.
@@ -990,7 +995,7 @@ static int gnttab_map(unsigned int start_idx, unsigned int end_idx)
 			xatp.domid = DOMID_SELF;
 			xatp.idx = i;
 			xatp.space = XENMAPSPACE_grant_table;
-			xatp.gpfn = (xen_hvm_resume_frames >> PAGE_SHIFT) + i;
+			xatp.gpfn = start_gpfn + i;
 			rc = HYPERVISOR_memory_op(XENMEM_add_to_physmap, &xatp);
 			if (rc != 0) {
 				printk(KERN_WARNING
@@ -1053,7 +1058,7 @@ static void gnttab_request_version(void)
 	int rc;
 	struct gnttab_set_version gsv;
 
-	if (xen_hvm_domain())
+	if (xen_hvm_domain() || xen_feature(XENFEAT_auto_translated_physmap))
 		gsv.version = 1;
 	else
 		gsv.version = 2;
@@ -1081,12 +1086,24 @@ static void gnttab_request_version(void)
 int gnttab_resume(void)
 {
 	unsigned int max_nr_gframes;
+	char *kmsg="Failed to kmalloc pages for pv in hvm grant frames\n";
 
 	gnttab_request_version();
 	max_nr_gframes = gnttab_max_grant_frames();
 	if (max_nr_gframes < nr_grant_frames)
 		return -ENOSYS;
 
+	/* PVH note: xen will free existing kmalloc'd mfn in 
+	 * XENMEM_add_to_physmap */
+	if (xen_pv_domain() && xen_feature(XENFEAT_auto_translated_physmap) && 
+	    !gnttab_shared.addr) {
+		gnttab_shared.addr =
+			kmalloc(max_nr_gframes * PAGE_SIZE, GFP_KERNEL);
+		if ( !gnttab_shared.addr ) {
+			printk(KERN_WARNING "%s", kmsg);
+			return -ENOMEM;
+		}
+	}
 	if (xen_pv_domain())
 		return gnttab_map(0, nr_grant_frames - 1);
 
-- 
1.7.2.3


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 21 19:19:50 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Sep 2012 19:19: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 1TF8lM-0003Ia-5z; Fri, 21 Sep 2012 19:19:44 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mukesh.rathor@oracle.com>) id 1TF8lK-0003He-Of
	for Xen-devel@lists.xensource.com; Fri, 21 Sep 2012 19:19:43 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1348255175!8618826!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDc2NjM1OA==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1323 invoked from network); 21 Sep 2012 19:19:36 -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 Sep 2012 19:19:36 -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 q8LJJUwh024059
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 21 Sep 2012 19:19:31 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q8LJJUYZ012271
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 21 Sep 2012 19:19:30 GMT
Received: from abhmt102.oracle.com (abhmt102.oracle.com [141.146.116.54])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q8LJJTtA031890; Fri, 21 Sep 2012 14:19:30 -0500
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 21 Sep 2012 12:19:29 -0700
Date: Fri, 21 Sep 2012 12:19:28 -0700
From: Mukesh Rathor <mukesh.rathor@oracle.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, "stefano.stabellini@eu.citrix.com"
	<stefano.stabellini@eu.citrix.com>
Message-ID: <20120921121928.1c5765bc@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] [PATCH v1 6/8]: PVH ballooning and grant 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


---
 drivers/xen/balloon.c     |   35 ++++++++++++++++++++++++++++-------
 drivers/xen/gntdev.c      |    3 ++-
 drivers/xen/grant-table.c |   25 +++++++++++++++++++++----
 3 files changed, 51 insertions(+), 12 deletions(-)

diff --git a/drivers/xen/balloon.c b/drivers/xen/balloon.c
index 31ab82f..85a6917 100644
--- a/drivers/xen/balloon.c
+++ b/drivers/xen/balloon.c
@@ -358,10 +358,21 @@ static enum bp_state increase_reservation(unsigned long nr_pages)
 		BUG_ON(!xen_feature(XENFEAT_auto_translated_physmap) &&
 		       phys_to_machine_mapping_valid(pfn));
 
-		set_phys_to_machine(pfn, frame_list[i]);
+		if (xen_pv_domain() && 
+		    xen_feature(XENFEAT_auto_translated_physmap)) {
+			/* PVH: we just need to update native page table */
+			pte_t *ptep;
+			unsigned int level;
+			void *addr = __va(pfn << PAGE_SHIFT);
+			ptep = lookup_address((unsigned long)addr, &level);
+			set_pte(ptep, pfn_pte(pfn, PAGE_KERNEL));
+		} else
+			set_phys_to_machine(pfn, frame_list[i]);
 
 		/* Link back into the page tables if not highmem. */
-		if (xen_pv_domain() && !PageHighMem(page)) {
+		if (xen_pv_domain() && !PageHighMem(page) && 
+		    !xen_feature(XENFEAT_auto_translated_physmap)) {
+
 			int ret;
 			ret = HYPERVISOR_update_va_mapping(
 				(unsigned long)__va(pfn << PAGE_SHIFT),
@@ -418,12 +429,21 @@ static enum bp_state decrease_reservation(unsigned long nr_pages, gfp_t gfp)
 		scrub_page(page);
 
 		if (xen_pv_domain() && !PageHighMem(page)) {
-			ret = HYPERVISOR_update_va_mapping(
-				(unsigned long)__va(pfn << PAGE_SHIFT),
-				__pte_ma(0), 0);
-			BUG_ON(ret);
+			if (xen_feature(XENFEAT_auto_translated_physmap)) {
+				unsigned int level;
+				pte_t *ptep;
+				void *addr = __va(pfn << PAGE_SHIFT);
+				ptep = lookup_address((unsigned long)addr, 
+							&level);
+				set_pte(ptep, __pte(0));
+
+			} else {
+				ret = HYPERVISOR_update_va_mapping(
+					(unsigned long)__va(pfn << PAGE_SHIFT),
+					__pte_ma(0), 0);
+				BUG_ON(ret);
+			}
 		}
-
 	}
 
 	/* Ensure that ballooned highmem pages don't have kmaps. */
@@ -433,6 +453,7 @@ static enum bp_state decrease_reservation(unsigned long nr_pages, gfp_t gfp)
 	/* No more mappings: invalidate P2M and add to balloon. */
 	for (i = 0; i < nr_pages; i++) {
 		pfn = mfn_to_pfn(frame_list[i]);
+		/* PVH note: following will noop for auto translated */
 		__set_phys_to_machine(pfn, INVALID_P2M_ENTRY);
 		balloon_append(pfn_to_page(pfn));
 	}
diff --git a/drivers/xen/gntdev.c b/drivers/xen/gntdev.c
index 1ffd03b..35d1e3c 100644
--- a/drivers/xen/gntdev.c
+++ b/drivers/xen/gntdev.c
@@ -802,7 +802,8 @@ static int __init gntdev_init(void)
 	if (!xen_domain())
 		return -ENODEV;
 
-	use_ptemod = xen_pv_domain();
+	use_ptemod = xen_pv_domain() && 
+		     !xen_feature(XENFEAT_auto_translated_physmap);
 
 	err = misc_register(&gntdev_miscdev);
 	if (err != 0) {
diff --git a/drivers/xen/grant-table.c b/drivers/xen/grant-table.c
index 0bfc1ef..d831d52 100644
--- a/drivers/xen/grant-table.c
+++ b/drivers/xen/grant-table.c
@@ -974,14 +974,19 @@ static void gnttab_unmap_frames_v2(void)
 static int gnttab_map(unsigned int start_idx, unsigned int end_idx)
 {
 	struct gnttab_setup_table setup;
-	unsigned long *frames;
+	unsigned long *frames, start_gpfn;
 	unsigned int nr_gframes = end_idx + 1;
 	int rc;
 
-	if (xen_hvm_domain()) {
+	if (xen_hvm_domain() || xen_feature(XENFEAT_auto_translated_physmap)) {
 		struct xen_add_to_physmap xatp;
 		unsigned int i = end_idx;
 		rc = 0;
+
+		if (xen_hvm_domain())
+			start_gpfn = xen_hvm_resume_frames >> PAGE_SHIFT;
+		else
+			start_gpfn = virt_to_pfn(gnttab_shared.addr);
 		/*
 		 * Loop backwards, so that the first hypercall has the largest
 		 * index, ensuring that the table will grow only once.
@@ -990,7 +995,7 @@ static int gnttab_map(unsigned int start_idx, unsigned int end_idx)
 			xatp.domid = DOMID_SELF;
 			xatp.idx = i;
 			xatp.space = XENMAPSPACE_grant_table;
-			xatp.gpfn = (xen_hvm_resume_frames >> PAGE_SHIFT) + i;
+			xatp.gpfn = start_gpfn + i;
 			rc = HYPERVISOR_memory_op(XENMEM_add_to_physmap, &xatp);
 			if (rc != 0) {
 				printk(KERN_WARNING
@@ -1053,7 +1058,7 @@ static void gnttab_request_version(void)
 	int rc;
 	struct gnttab_set_version gsv;
 
-	if (xen_hvm_domain())
+	if (xen_hvm_domain() || xen_feature(XENFEAT_auto_translated_physmap))
 		gsv.version = 1;
 	else
 		gsv.version = 2;
@@ -1081,12 +1086,24 @@ static void gnttab_request_version(void)
 int gnttab_resume(void)
 {
 	unsigned int max_nr_gframes;
+	char *kmsg="Failed to kmalloc pages for pv in hvm grant frames\n";
 
 	gnttab_request_version();
 	max_nr_gframes = gnttab_max_grant_frames();
 	if (max_nr_gframes < nr_grant_frames)
 		return -ENOSYS;
 
+	/* PVH note: xen will free existing kmalloc'd mfn in 
+	 * XENMEM_add_to_physmap */
+	if (xen_pv_domain() && xen_feature(XENFEAT_auto_translated_physmap) && 
+	    !gnttab_shared.addr) {
+		gnttab_shared.addr =
+			kmalloc(max_nr_gframes * PAGE_SIZE, GFP_KERNEL);
+		if ( !gnttab_shared.addr ) {
+			printk(KERN_WARNING "%s", kmsg);
+			return -ENOMEM;
+		}
+	}
 	if (xen_pv_domain())
 		return gnttab_map(0, nr_grant_frames - 1);
 
-- 
1.7.2.3


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 21 19:21:46 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Sep 2012 19:21:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TF8nD-0003Yr-SH; Fri, 21 Sep 2012 19:21:39 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mukesh.rathor@oracle.com>) id 1TF8nC-0003YA-FC
	for Xen-devel@lists.xensource.com; Fri, 21 Sep 2012 19:21:38 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1348255290!11902624!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDc2NjM1OA==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29545 invoked from network); 21 Sep 2012 19:21:31 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-2.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 21 Sep 2012 19:21:31 -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 q8LJLPbs025982
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 21 Sep 2012 19:21:26 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q8LJLPQo028484
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 21 Sep 2012 19:21:25 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
	q8LJLP7B000822; Fri, 21 Sep 2012 14:21:25 -0500
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 21 Sep 2012 12:21:24 -0700
Date: Fri, 21 Sep 2012 12:21:23 -0700
From: Mukesh Rathor <mukesh.rathor@oracle.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, "stefano.stabellini@eu.citrix.com"
	<stefano.stabellini@eu.citrix.com>
Message-ID: <20120921122123.33489ce1@mantra.us.oracle.com>
Organization: Oracle Corporation
X-Mailer: Claws Mail 3.7.6 (GTK+ 2.18.9; x86_64-redhat-linux-gnu)
Mime-Version: 1.0
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Subject: [Xen-devel] [PATCH v1 7/8]: PVH privcmd 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


---
 drivers/xen/privcmd.c |   77 ++++++++++++++++++++++++++++++++++++++++++++----
 1 files changed, 70 insertions(+), 7 deletions(-)

diff --git a/drivers/xen/privcmd.c b/drivers/xen/privcmd.c
index ccee0f1..195d89f 100644
--- a/drivers/xen/privcmd.c
+++ b/drivers/xen/privcmd.c
@@ -33,6 +33,7 @@
 #include <xen/features.h>
 #include <xen/page.h>
 #include <xen/xen-ops.h>
+#include <xen/balloon.h>
 
 #include "privcmd.h"
 
@@ -178,7 +179,7 @@ static int mmap_mfn_range(void *data, void *state)
 					msg->va & PAGE_MASK,
 					msg->mfn, msg->npages,
 					vma->vm_page_prot,
-					st->domain);
+					st->domain, NULL);
 	if (rc < 0)
 		return rc;
 
@@ -199,6 +200,10 @@ static long privcmd_ioctl_mmap(void __user *udata)
 	if (!xen_initial_domain())
 		return -EPERM;
 
+	/* PVH: TBD/FIXME. For now we only support privcmd_ioctl_mmap_batch */
+	if (xen_pv_domain() && xen_feature(XENFEAT_auto_translated_physmap))
+		return -ENOSYS;
+
 	if (copy_from_user(&mmapcmd, udata, sizeof(mmapcmd)))
 		return -EFAULT;
 
@@ -251,13 +256,18 @@ struct mmap_batch_state {
 	xen_pfn_t __user *user;
 };
 
+/* PVH dom0 fyi: if domU being created is PV, then mfn is mfn(addr on bus). If 
+ * it's PVH then mfn is pfn (input to HAP). */
 static int mmap_batch_fn(void *data, void *state)
 {
 	xen_pfn_t *mfnp = data;
 	struct mmap_batch_state *st = state;
+	struct vm_area_struct *vma = st->vma;
+	struct xen_pvh_pfn_info *pvhp = vma ? vma->vm_private_data : NULL;
 
-	if (xen_remap_domain_mfn_range(st->vma, st->va & PAGE_MASK, *mfnp, 1,
-				       st->vma->vm_page_prot, st->domain) < 0) {
+	if (xen_remap_domain_mfn_range(vma, st->va & PAGE_MASK, *mfnp, 1,
+				       vma->vm_page_prot, st->domain, 
+				       pvhp) < 0) {
 		*mfnp |= 0xf0000000U;
 		st->err++;
 	}
@@ -274,6 +284,40 @@ static int mmap_return_errors(void *data, void *state)
 	return put_user(*mfnp, st->user++);
 }
 
+/* Allocate pfns that are then mapped with gmfns from foreign domid. Update
+ * the vma with the page info to use later.
+ * Returns: 0 if success, otherwise -errno
+ */ 
+static int pvh_privcmd_resv_pfns(struct vm_area_struct *vma, int numpgs)
+{
+	int rc;
+	struct xen_pvh_pfn_info *pvhp;
+
+	pvhp = kzalloc(sizeof(struct xen_pvh_pfn_info), GFP_KERNEL);
+	if (pvhp == NULL)
+		return -ENOMEM;
+
+	pvhp->pi_paga = kcalloc(numpgs, sizeof(pvhp->pi_paga[0]), GFP_KERNEL);
+	if (pvhp->pi_paga == NULL) {
+		kfree(pvhp);
+		return -ENOMEM;
+	}
+
+	rc = alloc_xenballooned_pages(numpgs, pvhp->pi_paga, 0);
+	if (rc != 0) {
+		pr_warn("%s Could not alloc %d pfns rc:%d\n", __FUNCTION__, 
+			numpgs, rc);
+		kfree(pvhp->pi_paga);
+		kfree(pvhp);
+		return -ENOMEM;
+	}
+	pvhp->pi_num_pgs = numpgs;
+	BUG_ON(vma->vm_private_data != (void *)1);
+	vma->vm_private_data = pvhp;
+
+	return 0;
+}
+
 static struct vm_operations_struct privcmd_vm_ops;
 
 static long privcmd_ioctl_mmap_batch(void __user *udata)
@@ -315,6 +359,12 @@ static long privcmd_ioctl_mmap_batch(void __user *udata)
 		goto out;
 	}
 
+	if (xen_pv_domain() && xen_feature(XENFEAT_auto_translated_physmap)) {
+		if ((ret=pvh_privcmd_resv_pfns(vma, m.num))) {
+			up_write(&mm->mmap_sem);
+			goto out;
+		}
+	}
 	state.domain = m.dom;
 	state.vma = vma;
 	state.va = m.addr;
@@ -365,6 +415,22 @@ static long privcmd_ioctl(struct file *file,
 	return ret;
 }
 
+static void privcmd_close(struct vm_area_struct *vma)
+{
+	int count;
+	struct xen_pvh_pfn_info *pvhp = vma ? vma->vm_private_data : NULL;
+
+	if (!xen_pv_domain()  || !pvhp ||
+	    !xen_feature(XENFEAT_auto_translated_physmap))
+		return;
+
+	count = xen_unmap_domain_mfn_range(vma, pvhp);
+	while (count--)
+		free_xenballooned_pages(1, &pvhp->pi_paga[count]);
+	kfree(pvhp->pi_paga);
+	kfree(pvhp);
+}
+
 static int privcmd_fault(struct vm_area_struct *vma, struct vm_fault *vmf)
 {
 	printk(KERN_DEBUG "privcmd_fault: vma=%p %lx-%lx, pgoff=%lx, uv=%p\n",
@@ -375,15 +441,12 @@ static int privcmd_fault(struct vm_area_struct *vma, struct vm_fault *vmf)
 }
 
 static struct vm_operations_struct privcmd_vm_ops = {
+	.close = privcmd_close,
 	.fault = privcmd_fault
 };
 
 static int privcmd_mmap(struct file *file, struct vm_area_struct *vma)
 {
-	/* Unsupported for auto-translate guests. */
-	if (xen_feature(XENFEAT_auto_translated_physmap))
-		return -ENOSYS;
-
 	/* DONTCOPY is essential for Xen because copy_page_range doesn't know
 	 * how to recreate these mappings */
 	vma->vm_flags |= VM_RESERVED | VM_IO | VM_DONTCOPY | VM_PFNMAP;
-- 
1.7.2.3


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 21 19:21:46 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Sep 2012 19:21:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TF8nD-0003Yr-SH; Fri, 21 Sep 2012 19:21:39 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mukesh.rathor@oracle.com>) id 1TF8nC-0003YA-FC
	for Xen-devel@lists.xensource.com; Fri, 21 Sep 2012 19:21:38 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1348255290!11902624!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDc2NjM1OA==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29545 invoked from network); 21 Sep 2012 19:21:31 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-2.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 21 Sep 2012 19:21:31 -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 q8LJLPbs025982
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 21 Sep 2012 19:21:26 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q8LJLPQo028484
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 21 Sep 2012 19:21:25 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
	q8LJLP7B000822; Fri, 21 Sep 2012 14:21:25 -0500
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 21 Sep 2012 12:21:24 -0700
Date: Fri, 21 Sep 2012 12:21:23 -0700
From: Mukesh Rathor <mukesh.rathor@oracle.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, "stefano.stabellini@eu.citrix.com"
	<stefano.stabellini@eu.citrix.com>
Message-ID: <20120921122123.33489ce1@mantra.us.oracle.com>
Organization: Oracle Corporation
X-Mailer: Claws Mail 3.7.6 (GTK+ 2.18.9; x86_64-redhat-linux-gnu)
Mime-Version: 1.0
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Subject: [Xen-devel] [PATCH v1 7/8]: PVH privcmd 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


---
 drivers/xen/privcmd.c |   77 ++++++++++++++++++++++++++++++++++++++++++++----
 1 files changed, 70 insertions(+), 7 deletions(-)

diff --git a/drivers/xen/privcmd.c b/drivers/xen/privcmd.c
index ccee0f1..195d89f 100644
--- a/drivers/xen/privcmd.c
+++ b/drivers/xen/privcmd.c
@@ -33,6 +33,7 @@
 #include <xen/features.h>
 #include <xen/page.h>
 #include <xen/xen-ops.h>
+#include <xen/balloon.h>
 
 #include "privcmd.h"
 
@@ -178,7 +179,7 @@ static int mmap_mfn_range(void *data, void *state)
 					msg->va & PAGE_MASK,
 					msg->mfn, msg->npages,
 					vma->vm_page_prot,
-					st->domain);
+					st->domain, NULL);
 	if (rc < 0)
 		return rc;
 
@@ -199,6 +200,10 @@ static long privcmd_ioctl_mmap(void __user *udata)
 	if (!xen_initial_domain())
 		return -EPERM;
 
+	/* PVH: TBD/FIXME. For now we only support privcmd_ioctl_mmap_batch */
+	if (xen_pv_domain() && xen_feature(XENFEAT_auto_translated_physmap))
+		return -ENOSYS;
+
 	if (copy_from_user(&mmapcmd, udata, sizeof(mmapcmd)))
 		return -EFAULT;
 
@@ -251,13 +256,18 @@ struct mmap_batch_state {
 	xen_pfn_t __user *user;
 };
 
+/* PVH dom0 fyi: if domU being created is PV, then mfn is mfn(addr on bus). If 
+ * it's PVH then mfn is pfn (input to HAP). */
 static int mmap_batch_fn(void *data, void *state)
 {
 	xen_pfn_t *mfnp = data;
 	struct mmap_batch_state *st = state;
+	struct vm_area_struct *vma = st->vma;
+	struct xen_pvh_pfn_info *pvhp = vma ? vma->vm_private_data : NULL;
 
-	if (xen_remap_domain_mfn_range(st->vma, st->va & PAGE_MASK, *mfnp, 1,
-				       st->vma->vm_page_prot, st->domain) < 0) {
+	if (xen_remap_domain_mfn_range(vma, st->va & PAGE_MASK, *mfnp, 1,
+				       vma->vm_page_prot, st->domain, 
+				       pvhp) < 0) {
 		*mfnp |= 0xf0000000U;
 		st->err++;
 	}
@@ -274,6 +284,40 @@ static int mmap_return_errors(void *data, void *state)
 	return put_user(*mfnp, st->user++);
 }
 
+/* Allocate pfns that are then mapped with gmfns from foreign domid. Update
+ * the vma with the page info to use later.
+ * Returns: 0 if success, otherwise -errno
+ */ 
+static int pvh_privcmd_resv_pfns(struct vm_area_struct *vma, int numpgs)
+{
+	int rc;
+	struct xen_pvh_pfn_info *pvhp;
+
+	pvhp = kzalloc(sizeof(struct xen_pvh_pfn_info), GFP_KERNEL);
+	if (pvhp == NULL)
+		return -ENOMEM;
+
+	pvhp->pi_paga = kcalloc(numpgs, sizeof(pvhp->pi_paga[0]), GFP_KERNEL);
+	if (pvhp->pi_paga == NULL) {
+		kfree(pvhp);
+		return -ENOMEM;
+	}
+
+	rc = alloc_xenballooned_pages(numpgs, pvhp->pi_paga, 0);
+	if (rc != 0) {
+		pr_warn("%s Could not alloc %d pfns rc:%d\n", __FUNCTION__, 
+			numpgs, rc);
+		kfree(pvhp->pi_paga);
+		kfree(pvhp);
+		return -ENOMEM;
+	}
+	pvhp->pi_num_pgs = numpgs;
+	BUG_ON(vma->vm_private_data != (void *)1);
+	vma->vm_private_data = pvhp;
+
+	return 0;
+}
+
 static struct vm_operations_struct privcmd_vm_ops;
 
 static long privcmd_ioctl_mmap_batch(void __user *udata)
@@ -315,6 +359,12 @@ static long privcmd_ioctl_mmap_batch(void __user *udata)
 		goto out;
 	}
 
+	if (xen_pv_domain() && xen_feature(XENFEAT_auto_translated_physmap)) {
+		if ((ret=pvh_privcmd_resv_pfns(vma, m.num))) {
+			up_write(&mm->mmap_sem);
+			goto out;
+		}
+	}
 	state.domain = m.dom;
 	state.vma = vma;
 	state.va = m.addr;
@@ -365,6 +415,22 @@ static long privcmd_ioctl(struct file *file,
 	return ret;
 }
 
+static void privcmd_close(struct vm_area_struct *vma)
+{
+	int count;
+	struct xen_pvh_pfn_info *pvhp = vma ? vma->vm_private_data : NULL;
+
+	if (!xen_pv_domain()  || !pvhp ||
+	    !xen_feature(XENFEAT_auto_translated_physmap))
+		return;
+
+	count = xen_unmap_domain_mfn_range(vma, pvhp);
+	while (count--)
+		free_xenballooned_pages(1, &pvhp->pi_paga[count]);
+	kfree(pvhp->pi_paga);
+	kfree(pvhp);
+}
+
 static int privcmd_fault(struct vm_area_struct *vma, struct vm_fault *vmf)
 {
 	printk(KERN_DEBUG "privcmd_fault: vma=%p %lx-%lx, pgoff=%lx, uv=%p\n",
@@ -375,15 +441,12 @@ static int privcmd_fault(struct vm_area_struct *vma, struct vm_fault *vmf)
 }
 
 static struct vm_operations_struct privcmd_vm_ops = {
+	.close = privcmd_close,
 	.fault = privcmd_fault
 };
 
 static int privcmd_mmap(struct file *file, struct vm_area_struct *vma)
 {
-	/* Unsupported for auto-translate guests. */
-	if (xen_feature(XENFEAT_auto_translated_physmap))
-		return -ENOSYS;
-
 	/* DONTCOPY is essential for Xen because copy_page_range doesn't know
 	 * how to recreate these mappings */
 	vma->vm_flags |= VM_RESERVED | VM_IO | VM_DONTCOPY | VM_PFNMAP;
-- 
1.7.2.3


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 21 19:22:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Sep 2012 19:22:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TF8nU-0003bZ-Ai; Fri, 21 Sep 2012 19:21:56 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <matthew.fioravante@jhuapl.edu>) id 1TF8nS-0003bN-VT
	for xen-devel@lists.xensource.com; Fri, 21 Sep 2012 19:21:55 +0000
Received: from [85.158.139.211:49614] by server-13.bemta-5.messagelabs.com id
	5B/24-23645-25EBC505; Fri, 21 Sep 2012 19:21:54 +0000
X-Env-Sender: matthew.fioravante@jhuapl.edu
X-Msg-Ref: server-14.tower-206.messagelabs.com!1348255312!19447762!1
X-Originating-IP: [128.244.251.36]
X-SpamReason: No, hits=0.0 required=7.0 tests=UNPARSEABLE_RELAY
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29203 invoked from network); 21 Sep 2012 19:21:53 -0000
Received: from pilot.jhuapl.edu (HELO jhuapl.edu) (128.244.251.36)
	by server-14.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 21 Sep 2012 19:21:53 -0000
Received: from ([128.244.207.89])
	by pilot.jhuapl.edu with ESMTP with TLS id 63GHCH1.153410654;
	Fri, 21 Sep 2012 15:21:45 -0400
Message-ID: <505CBDFD.5070408@jhuapl.edu>
Date: Fri, 21 Sep 2012 15:20:29 -0400
From: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120827 Thunderbird/15.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>, 
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
X-Enigmail-Version: 1.4.4
Subject: Re: [Xen-devel] [PATCH xm/xl enhancements for vptm 5/6] make devid
	a libxl 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: multipart/mixed; boundary="===============7368445545268721159=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a cryptographically signed message in MIME format.

--===============7368445545268721159==
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms010502040707090806020203"

This is a cryptographically signed message in MIME format.

--------------ms010502040707090806020203
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

This fixes a bug in libxl where device ids are not initialized properly.
The devid field for each device is set to be an integer type which are
always initialized to 0.

This makes the xl DEV-attach commands always fail to add more than one
device, because each time the device id is initialized to 0, when it
should be initialized to -1, which in the code will trigger a search for
free id.

Signed off by Matthew Fioravante matthew.fioravante@jhuapl.edu

---
* Rebased off of latest xen-unstable
* Fixed whitespace errors

diff --git a/tools/libxl/gentest.py b/tools/libxl/gentest.py
--- a/tools/libxl/gentest.py
+++ b/tools/libxl/gentest.py
@@ -60,7 +60,7 @@ def gen_rand_init(ty, v, indent =3D "    ", parent =3D =
None):
                                         passby=3Didl.PASS_BY_REFERENCE))=

     elif ty.typename in ["libxl_uuid", "libxl_mac", "libxl_hwcap"]:
         s +=3D "rand_bytes((uint8_t *)%s, sizeof(*%s));\n" % (v,v)
-    elif ty.typename in ["libxl_domid"] or isinstance(ty, idl.Number):
+    elif ty.typename in ["libxl_domid", "libxl_devid"] or
isinstance(ty, idl.Number):
         s +=3D "%s =3D rand() %% (sizeof(%s)*8);\n" % \
              (ty.pass_arg(v, parent is None),
               ty.pass_arg(v, parent is None))
diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -307,6 +307,7 @@ void libxl_cpuid_dispose(libxl_cpuid_policy_list
*cpuid_list);
 #define LIBXL_PCI_FUNC_ALL (~0U)
=20
 typedef uint32_t libxl_domid;
+typedef int libxl_devid;
=20
 /*
  * Formatting Enumerations.
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
@@ -8,6 +8,7 @@ namespace("libxl_")
 libxl_defbool =3D Builtin("defbool", passby=3DPASS_BY_REFERENCE)
=20
 libxl_domid =3D Builtin("domid", json_fn =3D "yajl_gen_integer",
autogenerate_json =3D False)
+libxl_devid =3D Builtin("devid", json_fn =3D "yajl_gen_integer",
autogenerate_json =3D False, signed =3D True, init_val=3D"-1")
 libxl_uuid =3D Builtin("uuid", passby=3DPASS_BY_REFERENCE)
 libxl_mac =3D Builtin("mac", passby=3DPASS_BY_REFERENCE)
 libxl_bitmap =3D Builtin("bitmap", dispose_fn=3D"libxl_bitmap_dispose",
passby=3DPASS_BY_REFERENCE)
@@ -343,7 +344,7 @@ libxl_domain_build_info =3D Struct("domain_build_info=
",[
=20
 libxl_device_vfb =3D Struct("device_vfb", [
     ("backend_domid", libxl_domid),
-    ("devid",         integer),
+    ("devid",         libxl_devid),
     ("vnc",           libxl_vnc_info),
     ("sdl",           libxl_sdl_info),
     # set keyboard layout, default is en-us keyboard
@@ -352,7 +353,7 @@ libxl_device_vfb =3D Struct("device_vfb", [
=20
 libxl_device_vkb =3D Struct("device_vkb", [
     ("backend_domid", libxl_domid),
-    ("devid", integer),
+    ("devid", libxl_devid),
     ])
=20
 libxl_device_disk =3D Struct("device_disk", [
@@ -369,7 +370,7 @@ libxl_device_disk =3D Struct("device_disk", [
=20
 libxl_device_nic =3D Struct("device_nic", [
     ("backend_domid", libxl_domid),
-    ("devid", integer),
+    ("devid", libxl_devid),
     ("mtu", integer),
     ("model", string),
     ("mac", libxl_mac),
@@ -399,7 +400,7 @@ libxl_diskinfo =3D Struct("diskinfo", [
     ("backend_id", uint32),
     ("frontend", string),
     ("frontend_id", uint32),
-    ("devid", integer),
+    ("devid", libxl_devid),
     ("state", integer),
     ("evtch", integer),
     ("rref", integer),
@@ -410,7 +411,7 @@ libxl_nicinfo =3D Struct("nicinfo", [
     ("backend_id", uint32),
     ("frontend", string),
     ("frontend_id", uint32),
-    ("devid", integer),
+    ("devid", libxl_devid),
     ("state", integer),
     ("evtch", integer),
     ("rref_tx", integer),
diff --git a/tools/ocaml/libs/xc/xenctrl.ml b/tools/ocaml/libs/xc/xenctrl=
=2Eml
--- a/tools/ocaml/libs/xc/xenctrl.ml
+++ b/tools/ocaml/libs/xc/xenctrl.ml
@@ -16,6 +16,7 @@
=20
 (** *)
 type domid =3D int
+type devid =3D int
=20
 (* ** xenctrl.h ** *)
=20
diff --git a/tools/ocaml/libs/xc/xenctrl.mli
b/tools/ocaml/libs/xc/xenctrl.mli
--- a/tools/ocaml/libs/xc/xenctrl.mli
+++ b/tools/ocaml/libs/xc/xenctrl.mli
@@ -15,6 +15,7 @@
  *)
=20
 type domid =3D int
+type devid =3D int
 type vcpuinfo =3D {
   online : bool;
   blocked : bool;
diff --git a/tools/ocaml/libs/xl/genwrap.py b/tools/ocaml/libs/xl/genwrap=
=2Epy
--- a/tools/ocaml/libs/xl/genwrap.py
+++ b/tools/ocaml/libs/xl/genwrap.py
@@ -10,6 +10,7 @@ builtins =3D {
     "int":                  ("int",                    "%(c)s =3D
Int_val(%(o)s)",            "Val_int(%(c)s)"  ),
     "char *":               ("string",                 "%(c)s =3D
dup_String_val(gc, %(o)s)", "caml_copy_string(%(c)s)"),
     "libxl_domid":          ("domid",                  "%(c)s =3D
Int_val(%(o)s)",            "Val_int(%(c)s)"  ),
+    "libxl_devid":          ("devid",                  "%(c)s =3D
Int_val(%(o)s)",            "Val_int(%(c)s)"  ),
     "libxl_defbool":        ("bool option",            "%(c)s =3D
Defbool_val(%(o)s)",        "Val_defbool(%(c)s)" ),
     "libxl_uuid":           ("int array",              "Uuid_val(gc,
lg, &%(c)s, %(o)s)",   "Val_uuid(&%(c)s)"),
     "libxl_key_value_list": ("(string * string) list",
None,                                None),
@@ -41,8 +42,8 @@ def stub_fn_name(ty, name):
     return "stub_xl_%s_%s" % (ty.rawname,name)
   =20
 def ocaml_type_of(ty):
-    if ty.rawname =3D=3D "domid":
-        return "domid"
+    if ty.rawname in ["domid","devid"]:
+        return ty.rawname
     elif isinstance(ty,idl.UInt):
         if ty.width in [8, 16]:
             # handle as ints
diff --git a/tools/ocaml/libs/xl/xenlight.ml.in
b/tools/ocaml/libs/xl/xenlight.ml.in
--- a/tools/ocaml/libs/xl/xenlight.ml.in
+++ b/tools/ocaml/libs/xl/xenlight.ml.in
@@ -16,6 +16,7 @@
 exception Error of string
=20
 type domid =3D int
+type devid =3D int
=20
 (* @@LIBXL_TYPES@@ *)
=20
diff --git a/tools/ocaml/libs/xl/xenlight.mli.in
b/tools/ocaml/libs/xl/xenlight.mli.in
--- a/tools/ocaml/libs/xl/xenlight.mli.in
+++ b/tools/ocaml/libs/xl/xenlight.mli.in
@@ -16,6 +16,7 @@
 exception Error of string
=20
 type domid =3D int
+type devid =3D int
=20
 (* @@LIBXL_TYPES@@ *)
=20
diff --git a/tools/ocaml/libs/xs/xs.ml b/tools/ocaml/libs/xs/xs.ml
--- a/tools/ocaml/libs/xs/xs.ml
+++ b/tools/ocaml/libs/xs/xs.ml
@@ -17,6 +17,7 @@
 type perms =3D Xsraw.perms
 type con =3D Xsraw.con
 type domid =3D int
+type devid =3D int
=20
 type xsh =3D
 {
diff --git a/tools/ocaml/libs/xs/xs.mli b/tools/ocaml/libs/xs/xs.mli
--- a/tools/ocaml/libs/xs/xs.mli
+++ b/tools/ocaml/libs/xs/xs.mli
@@ -27,6 +27,7 @@ exception Failed_to_connect
 type perms =3D Xsraw.perms
=20
 type domid =3D int
+type devid =3D int
 type con
=20
 type xsh =3D {
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
@@ -281,6 +281,11 @@ int attrib__libxl_domid_set(PyObject *v,
libxl_domid *domid) {
     return 0;
 }
=20
+int attrib__libxl_devid_set(PyObject *v, libxl_devid *devid) {
+   *devid =3D PyInt_AsLong(v);
+   return 0;
+}
+
 int attrib__struct_in_addr_set(PyObject *v, struct in_addr *pptr)
 {
     PyErr_SetString(PyExc_NotImplementedError, "Setting in_addr");
@@ -342,6 +347,10 @@ PyObject *attrib__libxl_domid_get(libxl_domid *domid=
) {
     return PyInt_FromLong(*domid);
 }
=20
+PyObject *attrib__libxl_devid_get(libxl_devid *devid) {
+    return PyInt_FromLong(*devid);
+}
+
 PyObject *attrib__struct_in_addr_get(struct in_addr *pptr)
 {
     PyErr_SetString(PyExc_NotImplementedError, "Getting in_addr");



--------------ms010502040707090806020203
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIDyjCC
A8YwggMvoAMCAQICBD/xyf0wDQYJKoZIhvcNAQEFBQAwLzELMAkGA1UEBhMCVVMxDzANBgNV
BAoTBkpIVUFQTDEPMA0GA1UECxMGQklTRENBMB4XDTEwMDYxMTE4MjIwNloXDTEzMDYxMTE4
NTIwNlowZjELMAkGA1UEBhMCVVMxDzANBgNVBAoTBkpIVUFQTDEPMA0GA1UECxMGUGVvcGxl
MTUwFgYDVQQLEw9WUE5Hcm91cC1CSVNEQ0EwGwYDVQQDExRNYXR0aGV3IEUgRmlvcmF2YW50
ZTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAnpbwVSP6o1Nb5lcW7dd3yTo9iBJdi7qz
4nANOMFPK7JOy5npKN1iiousl28U/scUJES55gPwAWYJK3uVyQAsA4adgDKi5DoD1UHDQEwp
bY7iHLJeq0NPr4BqYNqnCFPbE6HC8zSJrr4qKn+gVUQT39SIFqdiIPJwZL8FYTRQ/zsCAwEA
AaOCAbYwggGyMAsGA1UdDwQEAwIHgDArBgNVHRAEJDAigA8yMDEwMDYxMTE4MjIwNlqBDzIw
MTIwNzE3MjI1MjA2WjAbBg0rBgEEAbMlCwMBAQEBBAoWCGZpb3JhbWUxMBsGDSsGAQQBsyUL
AwEBAQIEChIIMDAxMDQyNjEwWAYJYIZIAYb6ax4BBEsMSVRoZSBwcml2YXRlIGtleSBjb3Jy
ZXNwb25kaW5nIHRvIHRoaXMgY2VydGlmaWNhdGUgbWF5IGhhdmUgYmVlbiBleHBvcnRlZC4w
KAYDVR0RBCEwH4EdTWF0dGhldy5GaW9yYXZhbnRlQGpodWFwbC5lZHUwUgYDVR0fBEswSTBH
oEWgQ6RBMD8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJU0RD
QTEOMAwGA1UEAxMFQ1JMNTYwHwYDVR0jBBgwFoAUCDUpmxH52EU2CyWmF2EJMB1yqeswHQYD
VR0OBBYEFO6LYxg6r9wHZ+zdQtBHn1dZ/YTNMAkGA1UdEwQCMAAwGQYJKoZIhvZ9B0EABAww
ChsEVjcuMQMCBLAwDQYJKoZIhvcNAQEFBQADgYEAJO9HQh4YNChVLzuZqK5ARJARD8JoujGZ
fdo75quvg2jXFQe2sEjvLnxJZgm/pv8fdZakq48CWwjYHKuvIp7sDjTEsQfo+y7SpN/N2NvJ
WU5SqfK1VgYtNLRRoGJUB5Q1aZ+Dg95g3kqpyfpUMISJL8IKVLtJVfN4fggFVUYZ9wwxggGr
MIIBpwIBATA3MC8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJ
U0RDQQIEP/HJ/TAJBgUrDgMCGgUAoIHLMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ
KoZIhvcNAQkFMQ8XDTEyMDkyMTE5MjAyOVowIwYJKoZIhvcNAQkEMRYEFN+5/5ZY6dsVgXhU
Ye45yPpLVQ+MMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAK
BggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI
KoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEgYAp/aaTjD6Ynciz2mqCO0fxFURGe5HPYc8X
oBEcd8mpyzeLamn+XUyT+ujM9+OZFVCkGXn0rs7qHF5a7XbDBkuiqIiBFyp9/ZOFskohecIL
HRPsR0Z12Ik+khHXbLwvcYw/h/T5M4Y/a0k408u4ntyl3t60+TisK7vkMyzcQldxzwAAAAAA
AA==
--------------ms010502040707090806020203--


--===============7368445545268721159==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============7368445545268721159==--


From xen-devel-bounces@lists.xen.org Fri Sep 21 19:22:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Sep 2012 19:22:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TF8nU-0003bZ-Ai; Fri, 21 Sep 2012 19:21:56 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <matthew.fioravante@jhuapl.edu>) id 1TF8nS-0003bN-VT
	for xen-devel@lists.xensource.com; Fri, 21 Sep 2012 19:21:55 +0000
Received: from [85.158.139.211:49614] by server-13.bemta-5.messagelabs.com id
	5B/24-23645-25EBC505; Fri, 21 Sep 2012 19:21:54 +0000
X-Env-Sender: matthew.fioravante@jhuapl.edu
X-Msg-Ref: server-14.tower-206.messagelabs.com!1348255312!19447762!1
X-Originating-IP: [128.244.251.36]
X-SpamReason: No, hits=0.0 required=7.0 tests=UNPARSEABLE_RELAY
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29203 invoked from network); 21 Sep 2012 19:21:53 -0000
Received: from pilot.jhuapl.edu (HELO jhuapl.edu) (128.244.251.36)
	by server-14.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 21 Sep 2012 19:21:53 -0000
Received: from ([128.244.207.89])
	by pilot.jhuapl.edu with ESMTP with TLS id 63GHCH1.153410654;
	Fri, 21 Sep 2012 15:21:45 -0400
Message-ID: <505CBDFD.5070408@jhuapl.edu>
Date: Fri, 21 Sep 2012 15:20:29 -0400
From: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120827 Thunderbird/15.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>, 
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
X-Enigmail-Version: 1.4.4
Subject: Re: [Xen-devel] [PATCH xm/xl enhancements for vptm 5/6] make devid
	a libxl 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: multipart/mixed; boundary="===============7368445545268721159=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a cryptographically signed message in MIME format.

--===============7368445545268721159==
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms010502040707090806020203"

This is a cryptographically signed message in MIME format.

--------------ms010502040707090806020203
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

This fixes a bug in libxl where device ids are not initialized properly.
The devid field for each device is set to be an integer type which are
always initialized to 0.

This makes the xl DEV-attach commands always fail to add more than one
device, because each time the device id is initialized to 0, when it
should be initialized to -1, which in the code will trigger a search for
free id.

Signed off by Matthew Fioravante matthew.fioravante@jhuapl.edu

---
* Rebased off of latest xen-unstable
* Fixed whitespace errors

diff --git a/tools/libxl/gentest.py b/tools/libxl/gentest.py
--- a/tools/libxl/gentest.py
+++ b/tools/libxl/gentest.py
@@ -60,7 +60,7 @@ def gen_rand_init(ty, v, indent =3D "    ", parent =3D =
None):
                                         passby=3Didl.PASS_BY_REFERENCE))=

     elif ty.typename in ["libxl_uuid", "libxl_mac", "libxl_hwcap"]:
         s +=3D "rand_bytes((uint8_t *)%s, sizeof(*%s));\n" % (v,v)
-    elif ty.typename in ["libxl_domid"] or isinstance(ty, idl.Number):
+    elif ty.typename in ["libxl_domid", "libxl_devid"] or
isinstance(ty, idl.Number):
         s +=3D "%s =3D rand() %% (sizeof(%s)*8);\n" % \
              (ty.pass_arg(v, parent is None),
               ty.pass_arg(v, parent is None))
diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -307,6 +307,7 @@ void libxl_cpuid_dispose(libxl_cpuid_policy_list
*cpuid_list);
 #define LIBXL_PCI_FUNC_ALL (~0U)
=20
 typedef uint32_t libxl_domid;
+typedef int libxl_devid;
=20
 /*
  * Formatting Enumerations.
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
@@ -8,6 +8,7 @@ namespace("libxl_")
 libxl_defbool =3D Builtin("defbool", passby=3DPASS_BY_REFERENCE)
=20
 libxl_domid =3D Builtin("domid", json_fn =3D "yajl_gen_integer",
autogenerate_json =3D False)
+libxl_devid =3D Builtin("devid", json_fn =3D "yajl_gen_integer",
autogenerate_json =3D False, signed =3D True, init_val=3D"-1")
 libxl_uuid =3D Builtin("uuid", passby=3DPASS_BY_REFERENCE)
 libxl_mac =3D Builtin("mac", passby=3DPASS_BY_REFERENCE)
 libxl_bitmap =3D Builtin("bitmap", dispose_fn=3D"libxl_bitmap_dispose",
passby=3DPASS_BY_REFERENCE)
@@ -343,7 +344,7 @@ libxl_domain_build_info =3D Struct("domain_build_info=
",[
=20
 libxl_device_vfb =3D Struct("device_vfb", [
     ("backend_domid", libxl_domid),
-    ("devid",         integer),
+    ("devid",         libxl_devid),
     ("vnc",           libxl_vnc_info),
     ("sdl",           libxl_sdl_info),
     # set keyboard layout, default is en-us keyboard
@@ -352,7 +353,7 @@ libxl_device_vfb =3D Struct("device_vfb", [
=20
 libxl_device_vkb =3D Struct("device_vkb", [
     ("backend_domid", libxl_domid),
-    ("devid", integer),
+    ("devid", libxl_devid),
     ])
=20
 libxl_device_disk =3D Struct("device_disk", [
@@ -369,7 +370,7 @@ libxl_device_disk =3D Struct("device_disk", [
=20
 libxl_device_nic =3D Struct("device_nic", [
     ("backend_domid", libxl_domid),
-    ("devid", integer),
+    ("devid", libxl_devid),
     ("mtu", integer),
     ("model", string),
     ("mac", libxl_mac),
@@ -399,7 +400,7 @@ libxl_diskinfo =3D Struct("diskinfo", [
     ("backend_id", uint32),
     ("frontend", string),
     ("frontend_id", uint32),
-    ("devid", integer),
+    ("devid", libxl_devid),
     ("state", integer),
     ("evtch", integer),
     ("rref", integer),
@@ -410,7 +411,7 @@ libxl_nicinfo =3D Struct("nicinfo", [
     ("backend_id", uint32),
     ("frontend", string),
     ("frontend_id", uint32),
-    ("devid", integer),
+    ("devid", libxl_devid),
     ("state", integer),
     ("evtch", integer),
     ("rref_tx", integer),
diff --git a/tools/ocaml/libs/xc/xenctrl.ml b/tools/ocaml/libs/xc/xenctrl=
=2Eml
--- a/tools/ocaml/libs/xc/xenctrl.ml
+++ b/tools/ocaml/libs/xc/xenctrl.ml
@@ -16,6 +16,7 @@
=20
 (** *)
 type domid =3D int
+type devid =3D int
=20
 (* ** xenctrl.h ** *)
=20
diff --git a/tools/ocaml/libs/xc/xenctrl.mli
b/tools/ocaml/libs/xc/xenctrl.mli
--- a/tools/ocaml/libs/xc/xenctrl.mli
+++ b/tools/ocaml/libs/xc/xenctrl.mli
@@ -15,6 +15,7 @@
  *)
=20
 type domid =3D int
+type devid =3D int
 type vcpuinfo =3D {
   online : bool;
   blocked : bool;
diff --git a/tools/ocaml/libs/xl/genwrap.py b/tools/ocaml/libs/xl/genwrap=
=2Epy
--- a/tools/ocaml/libs/xl/genwrap.py
+++ b/tools/ocaml/libs/xl/genwrap.py
@@ -10,6 +10,7 @@ builtins =3D {
     "int":                  ("int",                    "%(c)s =3D
Int_val(%(o)s)",            "Val_int(%(c)s)"  ),
     "char *":               ("string",                 "%(c)s =3D
dup_String_val(gc, %(o)s)", "caml_copy_string(%(c)s)"),
     "libxl_domid":          ("domid",                  "%(c)s =3D
Int_val(%(o)s)",            "Val_int(%(c)s)"  ),
+    "libxl_devid":          ("devid",                  "%(c)s =3D
Int_val(%(o)s)",            "Val_int(%(c)s)"  ),
     "libxl_defbool":        ("bool option",            "%(c)s =3D
Defbool_val(%(o)s)",        "Val_defbool(%(c)s)" ),
     "libxl_uuid":           ("int array",              "Uuid_val(gc,
lg, &%(c)s, %(o)s)",   "Val_uuid(&%(c)s)"),
     "libxl_key_value_list": ("(string * string) list",
None,                                None),
@@ -41,8 +42,8 @@ def stub_fn_name(ty, name):
     return "stub_xl_%s_%s" % (ty.rawname,name)
   =20
 def ocaml_type_of(ty):
-    if ty.rawname =3D=3D "domid":
-        return "domid"
+    if ty.rawname in ["domid","devid"]:
+        return ty.rawname
     elif isinstance(ty,idl.UInt):
         if ty.width in [8, 16]:
             # handle as ints
diff --git a/tools/ocaml/libs/xl/xenlight.ml.in
b/tools/ocaml/libs/xl/xenlight.ml.in
--- a/tools/ocaml/libs/xl/xenlight.ml.in
+++ b/tools/ocaml/libs/xl/xenlight.ml.in
@@ -16,6 +16,7 @@
 exception Error of string
=20
 type domid =3D int
+type devid =3D int
=20
 (* @@LIBXL_TYPES@@ *)
=20
diff --git a/tools/ocaml/libs/xl/xenlight.mli.in
b/tools/ocaml/libs/xl/xenlight.mli.in
--- a/tools/ocaml/libs/xl/xenlight.mli.in
+++ b/tools/ocaml/libs/xl/xenlight.mli.in
@@ -16,6 +16,7 @@
 exception Error of string
=20
 type domid =3D int
+type devid =3D int
=20
 (* @@LIBXL_TYPES@@ *)
=20
diff --git a/tools/ocaml/libs/xs/xs.ml b/tools/ocaml/libs/xs/xs.ml
--- a/tools/ocaml/libs/xs/xs.ml
+++ b/tools/ocaml/libs/xs/xs.ml
@@ -17,6 +17,7 @@
 type perms =3D Xsraw.perms
 type con =3D Xsraw.con
 type domid =3D int
+type devid =3D int
=20
 type xsh =3D
 {
diff --git a/tools/ocaml/libs/xs/xs.mli b/tools/ocaml/libs/xs/xs.mli
--- a/tools/ocaml/libs/xs/xs.mli
+++ b/tools/ocaml/libs/xs/xs.mli
@@ -27,6 +27,7 @@ exception Failed_to_connect
 type perms =3D Xsraw.perms
=20
 type domid =3D int
+type devid =3D int
 type con
=20
 type xsh =3D {
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
@@ -281,6 +281,11 @@ int attrib__libxl_domid_set(PyObject *v,
libxl_domid *domid) {
     return 0;
 }
=20
+int attrib__libxl_devid_set(PyObject *v, libxl_devid *devid) {
+   *devid =3D PyInt_AsLong(v);
+   return 0;
+}
+
 int attrib__struct_in_addr_set(PyObject *v, struct in_addr *pptr)
 {
     PyErr_SetString(PyExc_NotImplementedError, "Setting in_addr");
@@ -342,6 +347,10 @@ PyObject *attrib__libxl_domid_get(libxl_domid *domid=
) {
     return PyInt_FromLong(*domid);
 }
=20
+PyObject *attrib__libxl_devid_get(libxl_devid *devid) {
+    return PyInt_FromLong(*devid);
+}
+
 PyObject *attrib__struct_in_addr_get(struct in_addr *pptr)
 {
     PyErr_SetString(PyExc_NotImplementedError, "Getting in_addr");



--------------ms010502040707090806020203
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIDyjCC
A8YwggMvoAMCAQICBD/xyf0wDQYJKoZIhvcNAQEFBQAwLzELMAkGA1UEBhMCVVMxDzANBgNV
BAoTBkpIVUFQTDEPMA0GA1UECxMGQklTRENBMB4XDTEwMDYxMTE4MjIwNloXDTEzMDYxMTE4
NTIwNlowZjELMAkGA1UEBhMCVVMxDzANBgNVBAoTBkpIVUFQTDEPMA0GA1UECxMGUGVvcGxl
MTUwFgYDVQQLEw9WUE5Hcm91cC1CSVNEQ0EwGwYDVQQDExRNYXR0aGV3IEUgRmlvcmF2YW50
ZTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAnpbwVSP6o1Nb5lcW7dd3yTo9iBJdi7qz
4nANOMFPK7JOy5npKN1iiousl28U/scUJES55gPwAWYJK3uVyQAsA4adgDKi5DoD1UHDQEwp
bY7iHLJeq0NPr4BqYNqnCFPbE6HC8zSJrr4qKn+gVUQT39SIFqdiIPJwZL8FYTRQ/zsCAwEA
AaOCAbYwggGyMAsGA1UdDwQEAwIHgDArBgNVHRAEJDAigA8yMDEwMDYxMTE4MjIwNlqBDzIw
MTIwNzE3MjI1MjA2WjAbBg0rBgEEAbMlCwMBAQEBBAoWCGZpb3JhbWUxMBsGDSsGAQQBsyUL
AwEBAQIEChIIMDAxMDQyNjEwWAYJYIZIAYb6ax4BBEsMSVRoZSBwcml2YXRlIGtleSBjb3Jy
ZXNwb25kaW5nIHRvIHRoaXMgY2VydGlmaWNhdGUgbWF5IGhhdmUgYmVlbiBleHBvcnRlZC4w
KAYDVR0RBCEwH4EdTWF0dGhldy5GaW9yYXZhbnRlQGpodWFwbC5lZHUwUgYDVR0fBEswSTBH
oEWgQ6RBMD8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJU0RD
QTEOMAwGA1UEAxMFQ1JMNTYwHwYDVR0jBBgwFoAUCDUpmxH52EU2CyWmF2EJMB1yqeswHQYD
VR0OBBYEFO6LYxg6r9wHZ+zdQtBHn1dZ/YTNMAkGA1UdEwQCMAAwGQYJKoZIhvZ9B0EABAww
ChsEVjcuMQMCBLAwDQYJKoZIhvcNAQEFBQADgYEAJO9HQh4YNChVLzuZqK5ARJARD8JoujGZ
fdo75quvg2jXFQe2sEjvLnxJZgm/pv8fdZakq48CWwjYHKuvIp7sDjTEsQfo+y7SpN/N2NvJ
WU5SqfK1VgYtNLRRoGJUB5Q1aZ+Dg95g3kqpyfpUMISJL8IKVLtJVfN4fggFVUYZ9wwxggGr
MIIBpwIBATA3MC8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJ
U0RDQQIEP/HJ/TAJBgUrDgMCGgUAoIHLMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ
KoZIhvcNAQkFMQ8XDTEyMDkyMTE5MjAyOVowIwYJKoZIhvcNAQkEMRYEFN+5/5ZY6dsVgXhU
Ye45yPpLVQ+MMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAK
BggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI
KoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEgYAp/aaTjD6Ynciz2mqCO0fxFURGe5HPYc8X
oBEcd8mpyzeLamn+XUyT+ujM9+OZFVCkGXn0rs7qHF5a7XbDBkuiqIiBFyp9/ZOFskohecIL
HRPsR0Z12Ik+khHXbLwvcYw/h/T5M4Y/a0k408u4ntyl3t60+TisK7vkMyzcQldxzwAAAAAA
AA==
--------------ms010502040707090806020203--


--===============7368445545268721159==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============7368445545268721159==--


From xen-devel-bounces@lists.xen.org Fri Sep 21 19:22:22 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Sep 2012 19: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 1TF8no-0003g4-OV; Fri, 21 Sep 2012 19:22:16 +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 1TF8nm-0003fd-Tx
	for Xen-devel@lists.xensource.com; Fri, 21 Sep 2012 19:22:15 +0000
Received: from [85.158.143.35:63535] by server-3.bemta-4.messagelabs.com id
	70/03-10986-66EBC505; Fri, 21 Sep 2012 19:22:14 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1348255332!11244153!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDc2NjM1OA==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28516 invoked from network); 21 Sep 2012 19:22:13 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-10.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 21 Sep 2012 19:22:13 -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 q8LJM7pT026847
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 21 Sep 2012 19:22: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
	q8LJM6c3018952
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 21 Sep 2012 19:22:07 GMT
Received: from abhmt117.oracle.com (abhmt117.oracle.com [141.146.116.69])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q8LJM6aw012715; Fri, 21 Sep 2012 14:22:06 -0500
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 21 Sep 2012 12:22:06 -0700
Date: Fri, 21 Sep 2012 12:22:05 -0700
From: Mukesh Rathor <mukesh.rathor@oracle.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, "stefano.stabellini@eu.citrix.com"
	<stefano.stabellini@eu.citrix.com>
Message-ID: <20120921122205.6ea7979e@mantra.us.oracle.com>
Organization: Oracle Corporation
X-Mailer: Claws Mail 3.7.6 (GTK+ 2.18.9; x86_64-redhat-linux-gnu)
Mime-Version: 1.0
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Subject: [Xen-devel] [PATCH v1 8/8]: PVH NONE
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

There are 7 patches and not 8. Sorry, please ignore this.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 21 19:22:22 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Sep 2012 19: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 1TF8no-0003g4-OV; Fri, 21 Sep 2012 19:22:16 +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 1TF8nm-0003fd-Tx
	for Xen-devel@lists.xensource.com; Fri, 21 Sep 2012 19:22:15 +0000
Received: from [85.158.143.35:63535] by server-3.bemta-4.messagelabs.com id
	70/03-10986-66EBC505; Fri, 21 Sep 2012 19:22:14 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1348255332!11244153!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDc2NjM1OA==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28516 invoked from network); 21 Sep 2012 19:22:13 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-10.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 21 Sep 2012 19:22:13 -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 q8LJM7pT026847
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 21 Sep 2012 19:22: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
	q8LJM6c3018952
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 21 Sep 2012 19:22:07 GMT
Received: from abhmt117.oracle.com (abhmt117.oracle.com [141.146.116.69])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q8LJM6aw012715; Fri, 21 Sep 2012 14:22:06 -0500
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 21 Sep 2012 12:22:06 -0700
Date: Fri, 21 Sep 2012 12:22:05 -0700
From: Mukesh Rathor <mukesh.rathor@oracle.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, "stefano.stabellini@eu.citrix.com"
	<stefano.stabellini@eu.citrix.com>
Message-ID: <20120921122205.6ea7979e@mantra.us.oracle.com>
Organization: Oracle Corporation
X-Mailer: Claws Mail 3.7.6 (GTK+ 2.18.9; x86_64-redhat-linux-gnu)
Mime-Version: 1.0
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Subject: [Xen-devel] [PATCH v1 8/8]: PVH NONE
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

There are 7 patches and not 8. Sorry, please ignore this.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 21 19:25:06 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Sep 2012 19:25:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TF8qR-0003zn-C4; Fri, 21 Sep 2012 19:24:59 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <matthew.fioravante@jhuapl.edu>) id 1TF8qP-0003ze-Td
	for xen-devel@lists.xensource.com; Fri, 21 Sep 2012 19:24:58 +0000
Received: from [85.158.143.99:7277] by server-2.bemta-4.messagelabs.com id
	7F/AD-06610-90FBC505; Fri, 21 Sep 2012 19:24:57 +0000
X-Env-Sender: matthew.fioravante@jhuapl.edu
X-Msg-Ref: server-16.tower-216.messagelabs.com!1348255493!20073090!1
X-Originating-IP: [128.244.251.36]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG,
	UNPARSEABLE_RELAY
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30326 invoked from network); 21 Sep 2012 19:24:55 -0000
Received: from pilot.jhuapl.edu (HELO jhuapl.edu) (128.244.251.36)
	by server-16.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 21 Sep 2012 19:24:55 -0000
Received: from ([128.244.207.89])
	by pilot.jhuapl.edu with ESMTP with TLS id 63GHCH1.153410928;
	Fri, 21 Sep 2012 15:24:48 -0400
Message-ID: <505CBEB4.8060105@jhuapl.edu>
Date: Fri, 21 Sep 2012 15:23:32 -0400
From: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120827 Thunderbird/15.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>, 
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
X-Enigmail-Version: 1.4.4
Subject: Re: [Xen-devel] [PATCH xm/xl enhancements for vptm 6/6] add vtpm
	support to libxl
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============8538936571305762314=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a cryptographically signed message in MIME format.

--===============8538936571305762314==
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms090802060603040405080700"

This is a cryptographically signed message in MIME format.

--------------ms090802060603040405080700
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Add support for vtpm=3D["VTPM_SPEC",...] to domain config files. Also add=

commands vtpm-attach, vtpm-list, and vtpm-detach.

Signed off by Matthew Fioravante matthew.fioravante@jhuapl.edu

---
Changes since previous:
* Rebased to latest xen
* Updated xl.cfg and xl manpages

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
@@ -298,6 +298,35 @@ 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>.
=20
+=3Ditem B<vtpm=3D[ "VTPM_SPEC_STRING", "VTPM_SPEC_STRING", ...]>
+
+Specifies the virtual trusted platform module to be
+provided to the guest. Please see F<docs/misc/vtpm.txt>
+for more details.
+
+Each B<VTPM_SPEC_STRING> is a comma-separated list of C<KEY=3DVALUE>
+settings, from the following list:
+
+=3Dover 4
+
+=3Ditem C<backend=3DDOMAIN>
+
+Specify the backend domain name of id. This value must be
+set if you are using the vtpm domain model. If this domain
+is a guest, the backend should be set to the vtpm domain name.
+If this domain is a vtpm, the backend should be set to the
+vtpm manager domain name. The default value is domain 0,
+which should be used if you are running the vtpm process model.
+
+=3Ditem C<uuid=3DUUID>
+
+Specify the uuid of this vtpm device. The uuid is used to uniquely
+identify the vtpm device. You can create one using the uuidgen
+program on unix systems. If left unspecified, a new uuid
+will be randomly generated everytime the domain boots.
+
+=3Dback
+
 =3Ditem B<vfb=3D[ "VFB_SPEC_STRING", "VFB_SPEC_STRING", ...]>
=20
 Specifies the paravirtual framebuffer devices which should be supplied
diff --git a/docs/man/xl.pod.1 b/docs/man/xl.pod.1
--- a/docs/man/xl.pod.1
+++ b/docs/man/xl.pod.1
@@ -1101,6 +1101,31 @@ List virtual network interfaces for a domain.
=20
 =3Dback
=20
+=3Dhead2 VTPM DEVICES
+
+=3Dover 4
+
+=3Ditem B<vtpm-attach> I<domain-id> I<vtpm-device>
+
+Creates a new vtpm device in the domain specified by I<domain-id>.
+I<vtpm-device> describes the device to attach, using the same format as =
the
+B<vtpm> string in the domain config file. See L<xl.cfg> for
+more information.
+
+=3Ditem B<vtpm-detach> I<domain-id> I<devid|uuid>
+
+Removes the vtpm device from the domain specified by I<domain-id>.
+I<devid> is the numeric device id given to the virtual trusted
+platform module device. You will need to run B<xl vtpm-list> to
determine that number.
+Alternatively the I<uuid> of the vtpm can be used to
+select the virtual device to detach.
+
+=3Ditem B<vtpm-list> I<domain-id>
+
+List virtual trusted platform modules for a domain.
+
+=3Dback
+
 =3Dhead1 PCI PASS-THROUGH
=20
 =3Dover 4
diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -1726,6 +1726,246 @@ out:
 }
=20
 /***********************************************************************=
*******/
+int libxl__device_vtpm_setdefault(libxl__gc *gc, libxl_device_vtpm *vtpm=
)
+{
+   if(libxl_uuid_is_nil(&vtpm->uuid)) {
+      libxl_uuid_generate(&vtpm->uuid);
+   }
+   return 0;
+}
+
+static int libxl__device_from_vtpm(libxl__gc *gc, uint32_t domid,
+                                   libxl_device_vtpm *vtpm,
+                                   libxl__device *device)
+{
+   device->backend_devid   =3D vtpm->devid;
+   device->backend_domid   =3D vtpm->backend_domid;
+   device->backend_kind    =3D LIBXL__DEVICE_KIND_VTPM;
+   device->devid           =3D vtpm->devid;
+   device->domid           =3D domid;
+   device->kind            =3D LIBXL__DEVICE_KIND_VTPM;
+
+   return 0;
+}
+
+void libxl__device_vtpm_add(libxl__egc *egc, uint32_t domid,
+                           libxl_device_vtpm *vtpm,
+                           libxl__ao_device *aodev)
+{
+    STATE_AO_GC(aodev->ao);
+    flexarray_t *front;
+    flexarray_t *back;
+    libxl__device *device;
+    char *dompath, **l;
+    unsigned int nb, rc;
+
+    rc =3D libxl__device_vtpm_setdefault(gc, vtpm);
+    if (rc) goto out;
+
+    front =3D flexarray_make(16, 1);
+    if (!front) {
+        rc =3D ERROR_NOMEM;
+        goto out;
+    }
+    back =3D flexarray_make(16, 1);
+    if (!back) {
+        rc =3D ERROR_NOMEM;
+        goto out;
+    }
+
+    if(vtpm->devid =3D=3D -1) {
+        if (!(dompath =3D libxl__xs_get_dompath(gc, domid))) {
+            rc =3D ERROR_FAIL;
+            goto out_free;
+        }
+        l =3D libxl__xs_directory(gc, XBT_NULL, libxl__sprintf(gc,
"%s/device/vtpm", dompath), &nb);
+        if(l =3D=3D NULL || nb =3D=3D 0) {
+            vtpm->devid =3D 0;
+        } else {
+            vtpm->devid =3D strtoul(l[nb - 1], NULL, 10) + 1;
+        }
+    }
+
+    GCNEW(device);
+    rc =3D libxl__device_from_vtpm(gc, domid, vtpm, device);
+    if ( rc !=3D 0 ) goto out_free;
+
+    flexarray_append(back, "frontend-id");
+    flexarray_append(back, libxl__sprintf(gc, "%d", domid));
+    flexarray_append(back, "online");
+    flexarray_append(back, "1");
+    flexarray_append(back, "state");
+    flexarray_append(back, libxl__sprintf(gc, "%d", 1));
+
+    flexarray_append(back, "uuid");
+    flexarray_append(back, libxl__sprintf(gc, LIBXL_UUID_FMT,
LIBXL_UUID_BYTES(vtpm->uuid)));
+    flexarray_append(back, "instance"); /* MAYBE CAN GET RID OF THIS */
+    flexarray_append(back, "0");
+    flexarray_append(back, "pref_instance"); /* MAYBE CAN GET RID OF
THIS */
+    flexarray_append(back, "0");
+    flexarray_append(back, "resume");
+    flexarray_append(back, "False");
+    flexarray_append(back, "ready"); /* MAYBE CAN GET RID OF THIS */
+    flexarray_append(back, "1");
+
+    flexarray_append(front, "backend-id");
+    flexarray_append(front, libxl__sprintf(gc, "%d", vtpm->backend_domid=
));
+    flexarray_append(front, "state");
+    flexarray_append(front, libxl__sprintf(gc, "%d", 1));
+    flexarray_append(front, "handle");
+    flexarray_append(front, libxl__sprintf(gc, "%d", vtpm->devid));
+
+    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));
+
+    aodev->dev =3D device;
+    aodev->action =3D DEVICE_CONNECT;
+    libxl__wait_device_connection(egc, aodev);
+
+    rc =3D 0;
+out_free:
+    flexarray_free(back);
+    flexarray_free(front);
+out:
+    aodev->rc =3D rc;
+    if(rc) aodev->callback(egc, aodev);
+    return;
+}
+
+static void libxl__device_vtpm_from_xs_fe(libxl__gc *gc,
+                                          const char* fe_path,
+                                          libxl_device_vtpm *vtpm)
+{
+   char* tmp;
+
+   memset(vtpm, 0, sizeof(*vtpm));
+   tmp =3D libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/handle",
fe_path));
+   if (tmp) {
+      vtpm->devid =3D atoi(tmp);
+   }
+   tmp =3D libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc,
"%s/backend-id", fe_path));
+   if(tmp) {
+      vtpm->backend_domid =3D atoi(tmp);
+   }
+   tmp =3D libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/uuid",
fe_path));
+   if(tmp) {
+      libxl_uuid_from_string(&(vtpm->uuid), tmp);
+   }
+}
+
+libxl_device_vtpm *libxl_device_vtpm_list(libxl_ctx *ctx, uint32_t
domid, int *num)
+{
+    GC_INIT(ctx);
+
+    libxl_device_vtpm* vtpms =3D NULL;
+    char* fe_path =3D NULL;
+    char** dir =3D NULL;
+    unsigned int ndirs =3D 0;
+
+    *num =3D 0;
+
+    fe_path =3D libxl__sprintf(gc, "%s/device/vtpm",
libxl__xs_get_dompath(gc, domid));
+    dir =3D libxl__xs_directory(gc, XBT_NULL, fe_path, &ndirs);
+    if(dir) {
+       vtpms =3D malloc(sizeof(*vtpms) * ndirs);
+       libxl_device_vtpm* vtpm;
+       libxl_device_vtpm* end =3D vtpms + ndirs;
+       for(vtpm =3D vtpms; vtpm < end; ++vtpm, ++dir) {
+          const char* path =3D libxl__sprintf(gc, "%s/%s", fe_path, *dir=
);
+          libxl__device_vtpm_from_xs_fe(gc, path, vtpm);
+       }
+    }
+    *num =3D ndirs;
+
+    GC_FREE;
+    return vtpms;
+}
+
+int libxl_device_vtpm_getinfo(libxl_ctx *ctx, uint32_t domid,
+                               libxl_device_vtpm *vtpm, libxl_vtpminfo
*vtpminfo)
+{
+    GC_INIT(ctx);
+    char *dompath, *vtpmpath;
+    char *val;
+    int rc =3D 0;
+
+    libxl_vtpminfo_init(vtpminfo);
+    dompath =3D libxl__xs_get_dompath(gc, domid);
+    vtpminfo->devid =3D vtpm->devid;
+
+    vtpmpath =3D libxl__sprintf(gc, "%s/device/vtpm/%d", dompath,
vtpminfo->devid);
+    vtpminfo->backend =3D xs_read(ctx->xsh, XBT_NULL,
+                                libxl__sprintf(gc, "%s/backend",
vtpmpath), NULL);
+    if (!vtpminfo->backend) {
+        goto err;
+    }
+    if(!libxl__xs_read(gc, XBT_NULL, vtpminfo->backend)) {
+       goto err;
+    }
+
+    val =3D libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc,
"%s/backend-id", vtpmpath));
+    vtpminfo->backend_id =3D val ? strtoul(val, NULL, 10) : -1;
+    val =3D libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/state",
vtpmpath));
+    vtpminfo->state =3D val ? strtoul(val, NULL, 10) : -1;
+    val =3D libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc,
"%s/event-channel", vtpmpath));
+    vtpminfo->evtch =3D val ? strtoul(val, NULL, 10) : -1;
+    val =3D libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc,
"%s/ring-ref", vtpmpath));
+    vtpminfo->rref =3D val ? strtoul(val, NULL, 10) : -1;
+    vtpminfo->frontend =3D xs_read(ctx->xsh, XBT_NULL,
+                                 libxl__sprintf(gc, "%s/frontend",
vtpminfo->backend), NULL);
+    val =3D libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc,
"%s/frontend-id", vtpminfo->backend));
+    vtpminfo->frontend_id =3D val ? strtoul(val, NULL, 10) : -1;
+
+    val =3D libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/uuid",
vtpminfo->backend));
+    if(val =3D=3D NULL) {
+       LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "%s/uuid does not exist!\n",
vtpminfo->backend);
+       goto err;
+    }
+    if(libxl_uuid_from_string(&(vtpminfo->uuid), val)) {
+       LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "%s/uuid is a malformed uuid??
(%s) Probably a bug!\n", vtpminfo->backend, val);
+       goto err;
+    }
+
+    goto exit;
+err:
+    rc =3D ERROR_FAIL;
+exit:
+    GC_FREE;
+    return rc;
+}
+
+int libxl_devid_to_device_vtpm(libxl_ctx *ctx, uint32_t domid,
+                              int devid, libxl_device_vtpm *vtpm)
+{
+    libxl_device_vtpm *vtpms;
+    int nb, i;
+    int rc;
+
+    vtpms =3D libxl_device_vtpm_list(ctx, domid, &nb);
+    if (!vtpms)
+        return ERROR_FAIL;
+
+    memset(vtpm, 0, sizeof (libxl_device_vtpm));
+    rc =3D 1;
+    for (i =3D 0; i < nb; ++i) {
+        if(devid =3D=3D vtpms[i].devid) {
+            vtpm->backend_domid =3D vtpms[i].backend_domid;
+            vtpm->devid =3D vtpms[i].devid;
+            libxl_uuid_copy(&vtpm->uuid, &vtpms[i].uuid);
+            rc =3D 0;
+            break;
+        }
+    }
+
+    for (i=3D0; i<nb; i++)
+        libxl_device_vtpm_dispose(&vtpms[i]);
+    free(vtpms);
+    return rc;
+}
+
+
+/***********************************************************************=
*******/
=20
 int libxl__device_disk_setdefault(libxl__gc *gc, libxl_device_disk *disk=
)
 {
@@ -3174,6 +3414,10 @@ DEFINE_DEVICE_REMOVE(vkb, destroy, 1)
 DEFINE_DEVICE_REMOVE(vfb, remove, 0)
 DEFINE_DEVICE_REMOVE(vfb, destroy, 1)
=20
+/* vtpm */
+DEFINE_DEVICE_REMOVE(vtpm, remove, 0)
+DEFINE_DEVICE_REMOVE(vtpm, destroy, 1)
+
 #undef DEFINE_DEVICE_REMOVE
=20
 /***********************************************************************=
*******/
@@ -3208,6 +3452,9 @@ DEFINE_DEVICE_ADD(disk)
 /* nic */
 DEFINE_DEVICE_ADD(nic)
=20
+/* vtpm */
+DEFINE_DEVICE_ADD(vtpm)
+
 #undef DEFINE_DEVICE_ADD
=20
 /***********************************************************************=
*******/
diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -478,13 +478,14 @@ typedef struct {
     libxl_domain_create_info c_info;
     libxl_domain_build_info b_info;
=20
-    int num_disks, num_nics, num_pcidevs, num_vfbs, num_vkbs;
+    int num_disks, num_nics, num_pcidevs, num_vfbs, num_vkbs, num_vtpms;=

=20
     libxl_device_disk *disks;
     libxl_device_nic *nics;
     libxl_device_pci *pcidevs;
     libxl_device_vfb *vfbs;
     libxl_device_vkb *vkbs;
+    libxl_device_vtpm *vtpms;
=20
     libxl_action_on_shutdown on_poweroff;
     libxl_action_on_shutdown on_reboot;
@@ -745,6 +746,23 @@ 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,
                               libxl_device_nic *nic, libxl_nicinfo
*nicinfo);
=20
+/* Virtual TPMs */
+int libxl_device_vtpm_add(libxl_ctx *ctx, uint32_t domid,
libxl_device_vtpm *vtpm,
+                          const libxl_asyncop_how *ao_how)
+                          LIBXL_EXTERNAL_CALLERS_ONLY;
+int libxl_device_vtpm_remove(libxl_ctx *ctx, uint32_t domid,
+                            libxl_device_vtpm *vtpm,
+                            const libxl_asyncop_how *ao_how)
+                            LIBXL_EXTERNAL_CALLERS_ONLY;
+int libxl_device_vtpm_destroy(libxl_ctx *ctx, uint32_t domid,
+                              libxl_device_vtpm *vtpm,
+                              const libxl_asyncop_how *ao_how)
+                              LIBXL_EXTERNAL_CALLERS_ONLY;
+
+libxl_device_vtpm *libxl_device_vtpm_list(libxl_ctx *ctx, uint32_t
domid, int *num);
+int libxl_device_vtpm_getinfo(libxl_ctx *ctx, uint32_t domid,
+                               libxl_device_vtpm *vtpm, libxl_vtpminfo
*vtpminfo);
+
 /* Keyboard */
 int libxl_device_vkb_add(libxl_ctx *ctx, uint32_t domid,
libxl_device_vkb *vkb,
                          const libxl_asyncop_how *ao_how)
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
@@ -55,6 +55,10 @@ void libxl_domain_config_dispose(libxl_domain_config
*d_config)
         libxl_device_vkb_dispose(&d_config->vkbs[i]);
     free(d_config->vkbs);
=20
+    for (i=3D0; i<d_config->num_vtpms; i++)
+       libxl_device_vtpm_dispose(&d_config->vtpms[i]);
+    free(d_config->vtpms);
+
     libxl_domain_create_info_dispose(&d_config->c_info);
     libxl_domain_build_info_dispose(&d_config->b_info);
 }
@@ -601,6 +605,8 @@ static void domcreate_bootloader_done(libxl__egc *egc=
,
 static void domcreate_launch_dm(libxl__egc *egc, libxl__multidev *aodevs=
,
                                 int ret);
=20
+static void domcreate_attach_vtpms(libxl__egc *egc, libxl__multidev
*multidev,
+                                   int ret);
 static void domcreate_attach_pci(libxl__egc *egc, libxl__multidev *aodev=
s,
                                  int ret);
=20
@@ -1084,13 +1090,13 @@ static void
domcreate_devmodel_started(libxl__egc *egc,
     if (d_config->num_nics > 0) {
         /* Attach nics */
         libxl__multidev_begin(ao, &dcs->multidev);
-        dcs->multidev.callback =3D domcreate_attach_pci;
+        dcs->multidev.callback =3D domcreate_attach_vtpms;
         libxl__add_nics(egc, ao, domid, d_config, &dcs->multidev);
         libxl__multidev_prepared(egc, &dcs->multidev, 0);
         return;
     }
=20
-    domcreate_attach_pci(egc, &dcs->multidev, 0);
+    domcreate_attach_vtpms(egc, &dcs->multidev, 0);
     return;
=20
 error_out:
@@ -1098,6 +1104,36 @@ error_out:
     domcreate_complete(egc, dcs, ret);
 }
=20
+static void domcreate_attach_vtpms(libxl__egc *egc, libxl__multidev
*multidev, int ret) {
+   libxl__domain_create_state *dcs =3D CONTAINER_OF(multidev, *dcs,
multidev);
+   STATE_AO_GC(dcs->ao);
+   int domid =3D dcs->guest_domid;
+
+   libxl_domain_config* const d_config =3D dcs->guest_config;
+
+   if(ret) {
+      LOG(ERROR, "unable to add nic devices");
+      goto error_out;
+   }
+
+    /* Plug nic interfaces */
+    if (d_config->num_vtpms > 0) {
+        /* Attach nics */
+        libxl__multidev_begin(ao, &dcs->multidev);
+        dcs->multidev.callback =3D domcreate_attach_pci;
+        libxl__add_vtpms(egc, ao, domid, d_config, &dcs->multidev);
+        libxl__multidev_prepared(egc, &dcs->multidev, 0);
+        return;
+    }
+
+   domcreate_attach_pci(egc, multidev, 0);
+   return;
+
+error_out:
+   assert(ret);
+   domcreate_complete(egc, dcs, ret);
+}
+
 static void domcreate_attach_pci(libxl__egc *egc, libxl__multidev
*multidev,
                                  int ret)
 {
@@ -1111,7 +1147,7 @@ static void domcreate_attach_pci(libxl__egc *egc,
libxl__multidev *multidev,
     libxl_domain_config *const d_config =3D dcs->guest_config;
=20
     if (ret) {
-        LOG(ERROR, "unable to add nic devices");
+        LOG(ERROR, "unable to add vtpm devices");
         goto error_out;
     }
=20
diff --git a/tools/libxl/libxl_device.c b/tools/libxl/libxl_device.c
--- a/tools/libxl/libxl_device.c
+++ b/tools/libxl/libxl_device.c
@@ -515,6 +515,7 @@ void libxl__multidev_prepared(libxl__egc *egc,
=20
 DEFINE_DEVICES_ADD(disk)
 DEFINE_DEVICES_ADD(nic)
+DEFINE_DEVICES_ADD(vtpm)
=20
 #undef DEFINE_DEVICES_ADD
=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
@@ -954,6 +954,7 @@ _hidden int libxl__device_disk_setdefault(libxl__gc *=
gc,
                                           libxl_device_disk *disk);
 _hidden int libxl__device_nic_setdefault(libxl__gc *gc,
libxl_device_nic *nic,
                                          uint32_t domid);
+_hidden int libxl__device_vtpm_setdefault(libxl__gc *gc,
libxl_device_vtpm *vtpm);
 _hidden int libxl__device_vfb_setdefault(libxl__gc *gc,
libxl_device_vfb *vfb);
 _hidden int libxl__device_vkb_setdefault(libxl__gc *gc,
libxl_device_vkb *vkb);
 _hidden int libxl__device_pci_setdefault(libxl__gc *gc,
libxl_device_pci *pci);
@@ -1975,6 +1976,10 @@ _hidden void libxl__device_nic_add(libxl__egc
*egc, uint32_t domid,
                                    libxl_device_nic *nic,
                                    libxl__ao_device *aodev);
=20
+_hidden void libxl__device_vtpm_add(libxl__egc *egc, uint32_t domid,
+                                   libxl_device_vtpm *vtpm,
+                                   libxl__ao_device *aodev);
+
 /* Internal function to connect a vkb device */
 _hidden int libxl__device_vkb_add(libxl__gc *gc, uint32_t domid,
                                   libxl_device_vkb *vkb);
@@ -2407,6 +2412,10 @@ _hidden void libxl__add_nics(libxl__egc *egc,
libxl__ao *ao, uint32_t domid,
                              libxl_domain_config *d_config,
                              libxl__multidev *multidev);
=20
+_hidden void libxl__add_vtpms(libxl__egc *egc, libxl__ao *ao, uint32_t
domid,
+                             libxl_domain_config *d_config,
+                             libxl__multidev *multidev);
+
 /*----- device model creation -----*/
=20
 /* First layer; wraps libxl__spawn_spawn. */
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
@@ -395,6 +395,12 @@ libxl_device_pci =3D Struct("device_pci", [
     ("permissive", bool),
     ])
=20
+libxl_device_vtpm =3D Struct("device_vtpm", [
+    ("backend_domid",    libxl_domid),
+    ("devid",            libxl_devid),
+    ("uuid",             libxl_uuid),
+])
+
 libxl_diskinfo =3D Struct("diskinfo", [
     ("backend", string),
     ("backend_id", uint32),
@@ -418,6 +424,18 @@ libxl_nicinfo =3D Struct("nicinfo", [
     ("rref_rx", integer),
     ], dir=3DDIR_OUT)
=20
+libxl_vtpminfo =3D Struct("vtpminfo", [
+    ("backend", string),
+    ("backend_id", uint32),
+    ("frontend", string),
+    ("frontend_id", uint32),
+    ("devid", libxl_devid),
+    ("state", integer),
+    ("evtch", integer),
+    ("rref", integer),
+    ("uuid", libxl_uuid),
+    ], dir=3DDIR_OUT)
+
 libxl_vcpuinfo =3D Struct("vcpuinfo", [
     ("vcpuid", uint32),
     ("cpu", uint32),
diff --git a/tools/libxl/libxl_types_internal.idl
b/tools/libxl/libxl_types_internal.idl
--- a/tools/libxl/libxl_types_internal.idl
+++ b/tools/libxl/libxl_types_internal.idl
@@ -19,6 +19,7 @@ libxl__device_kind =3D Enumeration("device_kind", [
     (5, "VFB"),
     (6, "VKBD"),
     (7, "CONSOLE"),
+    (8, "VTPM"),
     ])
=20
 libxl__console_backend =3D Enumeration("console_backend", [
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
@@ -463,6 +463,35 @@ int libxl_pipe(libxl_ctx *ctx, int pipes[2])
     return 0;
 }
=20
+int libxl_uuid_to_device_vtpm(libxl_ctx *ctx, uint32_t domid,
+                            libxl_uuid* uuid, libxl_device_vtpm *vtpm)
+{
+    libxl_device_vtpm *vtpms;
+    int nb, i;
+    int rc;
+
+    vtpms =3D libxl_device_vtpm_list(ctx, domid, &nb);
+    if (!vtpms)
+        return ERROR_FAIL;
+
+    memset(vtpm, 0, sizeof (libxl_device_vtpm));
+    rc =3D 1;
+    for (i =3D 0; i < nb; ++i) {
+        if(!libxl_uuid_compare(uuid, &vtpms[i].uuid)) {
+            vtpm->backend_domid =3D vtpms[i].backend_domid;
+            vtpm->devid =3D vtpms[i].devid;
+            libxl_uuid_copy(&vtpm->uuid, &vtpms[i].uuid);
+            rc =3D 0;
+            break;
+        }
+    }
+
+    for (i=3D0; i<nb; i++)
+        libxl_device_vtpm_dispose(&vtpms[i]);
+    free(vtpms);
+    return rc;
+}
+
 int libxl_mac_to_device_nic(libxl_ctx *ctx, uint32_t domid,
                             const char *mac, libxl_device_nic *nic)
 {
diff --git a/tools/libxl/libxl_utils.h b/tools/libxl/libxl_utils.h
--- a/tools/libxl/libxl_utils.h
+++ b/tools/libxl/libxl_utils.h
@@ -64,6 +64,11 @@ int libxl_devid_to_device_nic(libxl_ctx *ctx,
uint32_t domid, int devid,
 int libxl_vdev_to_device_disk(libxl_ctx *ctx, uint32_t domid, const
char *vdev,
                                libxl_device_disk *disk);
=20
+int libxl_uuid_to_device_vtpm(libxl_ctx *ctx, uint32_t domid,
+                               libxl_uuid *uuid, libxl_device_vtpm *vtpm=
);
+int libxl_devid_to_device_vtpm(libxl_ctx *ctx, uint32_t domid,
+                               int devid, libxl_device_vtpm *vtpm);
+
 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. */
diff --git a/tools/libxl/xl.h b/tools/libxl/xl.h
--- a/tools/libxl/xl.h
+++ b/tools/libxl/xl.h
@@ -79,6 +79,9 @@ int main_networkdetach(int argc, char **argv);
 int main_blockattach(int argc, char **argv);
 int main_blocklist(int argc, char **argv);
 int main_blockdetach(int argc, char **argv);
+int main_vtpmattach(int argc, char **argv);
+int main_vtpmlist(int argc, char **argv);
+int main_vtpmdetach(int argc, char **argv);
 int main_uptime(int argc, char **argv);
 int main_tmem_list(int argc, char **argv);
 int main_tmem_freeze(int argc, char **argv);
diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -573,7 +573,7 @@ static void parse_config_data(const char *config_sour=
ce,
     const char *buf;
     long l;
     XLU_Config *config;
-    XLU_ConfigList *cpus, *vbds, *nics, *pcis, *cvfbs, *cpuids;
+    XLU_ConfigList *cpus, *vbds, *nics, *pcis, *cvfbs, *cpuids, *vtpms;
     XLU_ConfigList *ioports, *irqs, *iomem;
     int num_ioports, num_irqs, num_iomem;
     int pci_power_mgmt =3D 0;
@@ -1045,6 +1045,47 @@ static void parse_config_data(const char
*config_source,
         }
     }
=20
+    if (!xlu_cfg_get_list(config, "vtpm", &vtpms, 0, 0)) {
+        d_config->num_vtpms =3D 0;
+        d_config->vtpms =3D NULL;
+        while ((buf =3D xlu_cfg_get_listitem (vtpms,
d_config->num_vtpms)) !=3D NULL) {
+            libxl_device_vtpm *vtpm;
+            char * buf2 =3D strdup(buf);
+            char *p, *p2;
+
+            d_config->vtpms =3D (libxl_device_vtpm *)
realloc(d_config->vtpms, sizeof(libxl_device_vtpm) *
(d_config->num_vtpms+1));
+            vtpm =3D d_config->vtpms + d_config->num_vtpms;
+            libxl_device_vtpm_init(vtpm);
+            vtpm->devid =3D d_config->num_vtpms;
+
+            p =3D strtok(buf2, ",");
+            if (!p)
+                goto skip_vtpm;
+            do {
+                while(*p =3D=3D ' ')
+                    ++p;
+                if ((p2 =3D strchr(p, '=3D')) =3D=3D NULL)
+                    break;
+                *p2 =3D '\0';
+                if (!strcmp(p, "backend")) {
+                    if(domain_qualifier_to_domid(p2 + 1,
&(vtpm->backend_domid), 0))
+                    {
+                        fprintf(stderr, "Specified backend domain does
not exist, defaulting to Dom0\n");
+                        vtpm->backend_domid =3D 0;
+                    }
+                } else if(!strcmp(p, "uuid")) {
+                    if( libxl_uuid_from_string(&vtpm->uuid, p2 + 1) ) {
+                        fprintf(stderr, "Failed to parse vtpm UUID:
%s\n", p2 + 1);
+                        exit(1);
+                    }
+                }
+            } while ((p =3D strtok(NULL, ",")) !=3D NULL);
+skip_vtpm:
+            free(buf2);
+            d_config->num_vtpms++;
+        }
+    }
+
     if (!xlu_cfg_get_list (config, "vif", &nics, 0, 0)) {
         d_config->num_nics =3D 0;
         d_config->nics =3D NULL;
@@ -1070,7 +1111,7 @@ static void parse_config_data(const char
*config_source,
=20
             p =3D strtok(buf2, ",");
             if (!p)
-                goto skip;
+                goto skip_nic;
             do {
                 while (*p =3D=3D ' ')
                     p++;
@@ -1134,7 +1175,7 @@ static void parse_config_data(const char
*config_source,
                     fprintf(stderr, "the accel parameter for vifs is
currently not supported\n");
                 }
             } while ((p =3D strtok(NULL, ",")) !=3D NULL);
-skip:
+skip_nic:
             free(buf2);
             d_config->num_nics++;
         }
@@ -5570,6 +5611,131 @@ int main_blockdetach(int argc, char **argv)
     return rc;
 }
=20
+int main_vtpmattach(int argc, char **argv)
+{
+    int opt;
+    libxl_device_vtpm vtpm;
+    char *oparg;
+    unsigned int val;
+    uint32_t domid;
+
+    if ((opt =3D def_getopt(argc, argv, "", "vtpm-attach", 1)) !=3D -1)
+        return opt;
+
+    if (domain_qualifier_to_domid(argv[optind], &domid, 0) < 0) {
+        fprintf(stderr, "%s is an invalid domain identifier\n",
argv[optind]);
+        return 1;
+    }
+    ++optind;
+
+    libxl_device_vtpm_init(&vtpm);
+    for (argv +=3D optind, argc -=3D optind; argc > 0; ++argv, --argc) {=

+        if (MATCH_OPTION("uuid", *argv, oparg)) {
+            if(libxl_uuid_from_string(&(vtpm.uuid), oparg)) {
+                fprintf(stderr, "Invalid uuid specified (%s)\n", oparg);=

+                return 1;
+            }
+        } else if (MATCH_OPTION("backend", *argv, oparg)) {
+            if(domain_qualifier_to_domid(oparg, &val, 0)) {
+                fprintf(stderr, "Specified backend domain does not
exist, defaulting to Dom0\n");
+                val =3D 0;
+            }
+            vtpm.backend_domid =3D val;
+        } else {
+            fprintf(stderr, "unrecognized argument `%s'\n", *argv);
+            return 1;
+        }
+    }
+
+    if(dryrun_only) {
+       char* json =3D libxl_device_vtpm_to_json(ctx, &vtpm);
+       printf("vtpm: %s\n", json);
+       free(json);
+       libxl_device_vtpm_dispose(&vtpm);
+       if (ferror(stdout) || fflush(stdout)) { perror("stdout");
exit(-1); }
+       return 0;
+    }
+
+    if (libxl_device_vtpm_add(ctx, domid, &vtpm, 0)) {
+        fprintf(stderr, "libxl_device_vtpm_add failed.\n");
+        return 1;
+    }
+    libxl_device_vtpm_dispose(&vtpm);
+    return 0;
+}
+
+int main_vtpmlist(int argc, char **argv)
+{
+    int opt;
+    libxl_device_vtpm *vtpms;
+    libxl_vtpminfo vtpminfo;
+    int nb, i;
+
+    if ((opt =3D def_getopt(argc, argv, "", "vtpm-list", 1)) !=3D -1)
+        return opt;
+
+    /*      Idx  BE   UUID   Hdl  Sta  evch rref  BE-path */
+    printf("%-3s %-2s %-36s %-6s %-5s %-6s %-5s %-10s\n",
+           "Idx", "BE", "Uuid", "handle", "state", "evt-ch",
"ring-ref", "BE-path");
+    for (argv +=3D optind, argc -=3D optind; argc > 0; --argc, ++argv) {=

+        uint32_t domid;
+        if (domain_qualifier_to_domid(*argv, &domid, 0) < 0) {
+            fprintf(stderr, "%s is an invalid domain identifier\n", *arg=
v);
+            continue;
+        }
+        if (!(vtpms =3D libxl_device_vtpm_list(ctx, domid, &nb))) {
+            continue;
+        }
+        for (i =3D 0; i < nb; ++i) {
+           if(!libxl_device_vtpm_getinfo(ctx, domid, &vtpms[i],
&vtpminfo)) {
+              /*      Idx  BE     UUID             Hdl Sta evch rref
BE-path*/
+              printf("%-3d %-2d " LIBXL_UUID_FMT " %6d %5d %6d %8d
%-30s\n",
+                    vtpminfo.devid, vtpminfo.backend_id,
+                    LIBXL_UUID_BYTES(vtpminfo.uuid),
+                    vtpminfo.devid, vtpminfo.state, vtpminfo.evtch,
+                    vtpminfo.rref, vtpminfo.backend);
+
+              libxl_vtpminfo_dispose(&vtpminfo);
+           }
+           libxl_device_vtpm_dispose(&vtpms[i]);
+        }
+        free(vtpms);
+    }
+    return 0;
+}
+
+int main_vtpmdetach(int argc, char **argv)
+{
+    uint32_t domid;
+    int opt, rc=3D0;
+    libxl_device_vtpm vtpm;
+    libxl_uuid uuid;
+
+    if ((opt =3D def_getopt(argc, argv, "", "vtpm-detach", 2)) !=3D -1)
+        return opt;
+
+    domid =3D find_domain(argv[optind]);
+
+    if ( libxl_uuid_from_string(&uuid, argv[optind+1])) {
+        if (libxl_devid_to_device_vtpm(ctx, domid,
atoi(argv[optind+1]), &vtpm)) {
+            fprintf(stderr, "Unknown device %s.\n", argv[optind+1]);
+            return 1;
+        }
+    } else {
+        if (libxl_uuid_to_device_vtpm(ctx, domid, &uuid, &vtpm)) {
+            fprintf(stderr, "Unknown device %s.\n", argv[optind+1]);
+            return 1;
+        }
+    }
+    rc =3D libxl_device_vtpm_remove(ctx, domid, &vtpm, 0);
+    if (rc) {
+        fprintf(stderr, "libxl_device_vtpm_remove failed.\n");
+    }
+    libxl_device_vtpm_dispose(&vtpm);
+    return rc;
+}
+
+
 static char *uptime_to_string(unsigned long uptime, int short_mode)
 {
     int sec, min, hour, day;
diff --git a/tools/libxl/xl_cmdtable.c b/tools/libxl/xl_cmdtable.c
--- a/tools/libxl/xl_cmdtable.c
+++ b/tools/libxl/xl_cmdtable.c
@@ -338,6 +338,21 @@ struct cmd_spec cmd_table[] =3D {
       "Destroy a domain's virtual block device",
       "<Domain> <DevId>",
     },
+    { "vtpm-attach",
+      &main_vtpmattach, 0, 1,
+      "Create a new virtual TPM device",
+      "<Domain> [uuid=3D<uuid>] [backend=3D<BackDomain>]",
+    },
+    { "vtpm-list",
+      &main_vtpmlist, 0, 0,
+      "List virtual TPM devices for a domain",
+      "<Domain(s)>",
+    },
+    { "vtpm-detach",
+      &main_vtpmdetach, 0, 1,
+      "Destroy a domain's virtual TPM device",
+      "<Domain> <DevId|uuid>",
+    },
     { "uptime",
       &main_uptime, 0, 0,
       "Print uptime for all/some domains",



--------------ms090802060603040405080700
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIDyjCC
A8YwggMvoAMCAQICBD/xyf0wDQYJKoZIhvcNAQEFBQAwLzELMAkGA1UEBhMCVVMxDzANBgNV
BAoTBkpIVUFQTDEPMA0GA1UECxMGQklTRENBMB4XDTEwMDYxMTE4MjIwNloXDTEzMDYxMTE4
NTIwNlowZjELMAkGA1UEBhMCVVMxDzANBgNVBAoTBkpIVUFQTDEPMA0GA1UECxMGUGVvcGxl
MTUwFgYDVQQLEw9WUE5Hcm91cC1CSVNEQ0EwGwYDVQQDExRNYXR0aGV3IEUgRmlvcmF2YW50
ZTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAnpbwVSP6o1Nb5lcW7dd3yTo9iBJdi7qz
4nANOMFPK7JOy5npKN1iiousl28U/scUJES55gPwAWYJK3uVyQAsA4adgDKi5DoD1UHDQEwp
bY7iHLJeq0NPr4BqYNqnCFPbE6HC8zSJrr4qKn+gVUQT39SIFqdiIPJwZL8FYTRQ/zsCAwEA
AaOCAbYwggGyMAsGA1UdDwQEAwIHgDArBgNVHRAEJDAigA8yMDEwMDYxMTE4MjIwNlqBDzIw
MTIwNzE3MjI1MjA2WjAbBg0rBgEEAbMlCwMBAQEBBAoWCGZpb3JhbWUxMBsGDSsGAQQBsyUL
AwEBAQIEChIIMDAxMDQyNjEwWAYJYIZIAYb6ax4BBEsMSVRoZSBwcml2YXRlIGtleSBjb3Jy
ZXNwb25kaW5nIHRvIHRoaXMgY2VydGlmaWNhdGUgbWF5IGhhdmUgYmVlbiBleHBvcnRlZC4w
KAYDVR0RBCEwH4EdTWF0dGhldy5GaW9yYXZhbnRlQGpodWFwbC5lZHUwUgYDVR0fBEswSTBH
oEWgQ6RBMD8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJU0RD
QTEOMAwGA1UEAxMFQ1JMNTYwHwYDVR0jBBgwFoAUCDUpmxH52EU2CyWmF2EJMB1yqeswHQYD
VR0OBBYEFO6LYxg6r9wHZ+zdQtBHn1dZ/YTNMAkGA1UdEwQCMAAwGQYJKoZIhvZ9B0EABAww
ChsEVjcuMQMCBLAwDQYJKoZIhvcNAQEFBQADgYEAJO9HQh4YNChVLzuZqK5ARJARD8JoujGZ
fdo75quvg2jXFQe2sEjvLnxJZgm/pv8fdZakq48CWwjYHKuvIp7sDjTEsQfo+y7SpN/N2NvJ
WU5SqfK1VgYtNLRRoGJUB5Q1aZ+Dg95g3kqpyfpUMISJL8IKVLtJVfN4fggFVUYZ9wwxggGr
MIIBpwIBATA3MC8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJ
U0RDQQIEP/HJ/TAJBgUrDgMCGgUAoIHLMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ
KoZIhvcNAQkFMQ8XDTEyMDkyMTE5MjMzMlowIwYJKoZIhvcNAQkEMRYEFMTa7jHuXlTem+lk
SKikj8SEHmf/MGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAK
BggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI
KoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEgYCc35JMUfZQWjiUss/NIUV/qd9RO4Pvg9yq
0VEuMqy/NMLxi7hw0RLlFlpw30XwpDYWQtp3hxHtcvAAaEuQ5q8kUZvFQM/LXnn+AxpaE+Cc
U2Afqjd3GsMquSBaoF+5sIb8xQ/0IKp6qWvKJG9C4NRLC4ctxawkP7Pv2QgZpxoq3AAAAAAA
AA==
--------------ms090802060603040405080700--


--===============8538936571305762314==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============8538936571305762314==--


From xen-devel-bounces@lists.xen.org Fri Sep 21 19:25:06 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Sep 2012 19:25:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TF8qR-0003zn-C4; Fri, 21 Sep 2012 19:24:59 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <matthew.fioravante@jhuapl.edu>) id 1TF8qP-0003ze-Td
	for xen-devel@lists.xensource.com; Fri, 21 Sep 2012 19:24:58 +0000
Received: from [85.158.143.99:7277] by server-2.bemta-4.messagelabs.com id
	7F/AD-06610-90FBC505; Fri, 21 Sep 2012 19:24:57 +0000
X-Env-Sender: matthew.fioravante@jhuapl.edu
X-Msg-Ref: server-16.tower-216.messagelabs.com!1348255493!20073090!1
X-Originating-IP: [128.244.251.36]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG,
	UNPARSEABLE_RELAY
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30326 invoked from network); 21 Sep 2012 19:24:55 -0000
Received: from pilot.jhuapl.edu (HELO jhuapl.edu) (128.244.251.36)
	by server-16.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 21 Sep 2012 19:24:55 -0000
Received: from ([128.244.207.89])
	by pilot.jhuapl.edu with ESMTP with TLS id 63GHCH1.153410928;
	Fri, 21 Sep 2012 15:24:48 -0400
Message-ID: <505CBEB4.8060105@jhuapl.edu>
Date: Fri, 21 Sep 2012 15:23:32 -0400
From: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120827 Thunderbird/15.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>, 
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
X-Enigmail-Version: 1.4.4
Subject: Re: [Xen-devel] [PATCH xm/xl enhancements for vptm 6/6] add vtpm
	support to libxl
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============8538936571305762314=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a cryptographically signed message in MIME format.

--===============8538936571305762314==
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms090802060603040405080700"

This is a cryptographically signed message in MIME format.

--------------ms090802060603040405080700
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Add support for vtpm=3D["VTPM_SPEC",...] to domain config files. Also add=

commands vtpm-attach, vtpm-list, and vtpm-detach.

Signed off by Matthew Fioravante matthew.fioravante@jhuapl.edu

---
Changes since previous:
* Rebased to latest xen
* Updated xl.cfg and xl manpages

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
@@ -298,6 +298,35 @@ 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>.
=20
+=3Ditem B<vtpm=3D[ "VTPM_SPEC_STRING", "VTPM_SPEC_STRING", ...]>
+
+Specifies the virtual trusted platform module to be
+provided to the guest. Please see F<docs/misc/vtpm.txt>
+for more details.
+
+Each B<VTPM_SPEC_STRING> is a comma-separated list of C<KEY=3DVALUE>
+settings, from the following list:
+
+=3Dover 4
+
+=3Ditem C<backend=3DDOMAIN>
+
+Specify the backend domain name of id. This value must be
+set if you are using the vtpm domain model. If this domain
+is a guest, the backend should be set to the vtpm domain name.
+If this domain is a vtpm, the backend should be set to the
+vtpm manager domain name. The default value is domain 0,
+which should be used if you are running the vtpm process model.
+
+=3Ditem C<uuid=3DUUID>
+
+Specify the uuid of this vtpm device. The uuid is used to uniquely
+identify the vtpm device. You can create one using the uuidgen
+program on unix systems. If left unspecified, a new uuid
+will be randomly generated everytime the domain boots.
+
+=3Dback
+
 =3Ditem B<vfb=3D[ "VFB_SPEC_STRING", "VFB_SPEC_STRING", ...]>
=20
 Specifies the paravirtual framebuffer devices which should be supplied
diff --git a/docs/man/xl.pod.1 b/docs/man/xl.pod.1
--- a/docs/man/xl.pod.1
+++ b/docs/man/xl.pod.1
@@ -1101,6 +1101,31 @@ List virtual network interfaces for a domain.
=20
 =3Dback
=20
+=3Dhead2 VTPM DEVICES
+
+=3Dover 4
+
+=3Ditem B<vtpm-attach> I<domain-id> I<vtpm-device>
+
+Creates a new vtpm device in the domain specified by I<domain-id>.
+I<vtpm-device> describes the device to attach, using the same format as =
the
+B<vtpm> string in the domain config file. See L<xl.cfg> for
+more information.
+
+=3Ditem B<vtpm-detach> I<domain-id> I<devid|uuid>
+
+Removes the vtpm device from the domain specified by I<domain-id>.
+I<devid> is the numeric device id given to the virtual trusted
+platform module device. You will need to run B<xl vtpm-list> to
determine that number.
+Alternatively the I<uuid> of the vtpm can be used to
+select the virtual device to detach.
+
+=3Ditem B<vtpm-list> I<domain-id>
+
+List virtual trusted platform modules for a domain.
+
+=3Dback
+
 =3Dhead1 PCI PASS-THROUGH
=20
 =3Dover 4
diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -1726,6 +1726,246 @@ out:
 }
=20
 /***********************************************************************=
*******/
+int libxl__device_vtpm_setdefault(libxl__gc *gc, libxl_device_vtpm *vtpm=
)
+{
+   if(libxl_uuid_is_nil(&vtpm->uuid)) {
+      libxl_uuid_generate(&vtpm->uuid);
+   }
+   return 0;
+}
+
+static int libxl__device_from_vtpm(libxl__gc *gc, uint32_t domid,
+                                   libxl_device_vtpm *vtpm,
+                                   libxl__device *device)
+{
+   device->backend_devid   =3D vtpm->devid;
+   device->backend_domid   =3D vtpm->backend_domid;
+   device->backend_kind    =3D LIBXL__DEVICE_KIND_VTPM;
+   device->devid           =3D vtpm->devid;
+   device->domid           =3D domid;
+   device->kind            =3D LIBXL__DEVICE_KIND_VTPM;
+
+   return 0;
+}
+
+void libxl__device_vtpm_add(libxl__egc *egc, uint32_t domid,
+                           libxl_device_vtpm *vtpm,
+                           libxl__ao_device *aodev)
+{
+    STATE_AO_GC(aodev->ao);
+    flexarray_t *front;
+    flexarray_t *back;
+    libxl__device *device;
+    char *dompath, **l;
+    unsigned int nb, rc;
+
+    rc =3D libxl__device_vtpm_setdefault(gc, vtpm);
+    if (rc) goto out;
+
+    front =3D flexarray_make(16, 1);
+    if (!front) {
+        rc =3D ERROR_NOMEM;
+        goto out;
+    }
+    back =3D flexarray_make(16, 1);
+    if (!back) {
+        rc =3D ERROR_NOMEM;
+        goto out;
+    }
+
+    if(vtpm->devid =3D=3D -1) {
+        if (!(dompath =3D libxl__xs_get_dompath(gc, domid))) {
+            rc =3D ERROR_FAIL;
+            goto out_free;
+        }
+        l =3D libxl__xs_directory(gc, XBT_NULL, libxl__sprintf(gc,
"%s/device/vtpm", dompath), &nb);
+        if(l =3D=3D NULL || nb =3D=3D 0) {
+            vtpm->devid =3D 0;
+        } else {
+            vtpm->devid =3D strtoul(l[nb - 1], NULL, 10) + 1;
+        }
+    }
+
+    GCNEW(device);
+    rc =3D libxl__device_from_vtpm(gc, domid, vtpm, device);
+    if ( rc !=3D 0 ) goto out_free;
+
+    flexarray_append(back, "frontend-id");
+    flexarray_append(back, libxl__sprintf(gc, "%d", domid));
+    flexarray_append(back, "online");
+    flexarray_append(back, "1");
+    flexarray_append(back, "state");
+    flexarray_append(back, libxl__sprintf(gc, "%d", 1));
+
+    flexarray_append(back, "uuid");
+    flexarray_append(back, libxl__sprintf(gc, LIBXL_UUID_FMT,
LIBXL_UUID_BYTES(vtpm->uuid)));
+    flexarray_append(back, "instance"); /* MAYBE CAN GET RID OF THIS */
+    flexarray_append(back, "0");
+    flexarray_append(back, "pref_instance"); /* MAYBE CAN GET RID OF
THIS */
+    flexarray_append(back, "0");
+    flexarray_append(back, "resume");
+    flexarray_append(back, "False");
+    flexarray_append(back, "ready"); /* MAYBE CAN GET RID OF THIS */
+    flexarray_append(back, "1");
+
+    flexarray_append(front, "backend-id");
+    flexarray_append(front, libxl__sprintf(gc, "%d", vtpm->backend_domid=
));
+    flexarray_append(front, "state");
+    flexarray_append(front, libxl__sprintf(gc, "%d", 1));
+    flexarray_append(front, "handle");
+    flexarray_append(front, libxl__sprintf(gc, "%d", vtpm->devid));
+
+    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));
+
+    aodev->dev =3D device;
+    aodev->action =3D DEVICE_CONNECT;
+    libxl__wait_device_connection(egc, aodev);
+
+    rc =3D 0;
+out_free:
+    flexarray_free(back);
+    flexarray_free(front);
+out:
+    aodev->rc =3D rc;
+    if(rc) aodev->callback(egc, aodev);
+    return;
+}
+
+static void libxl__device_vtpm_from_xs_fe(libxl__gc *gc,
+                                          const char* fe_path,
+                                          libxl_device_vtpm *vtpm)
+{
+   char* tmp;
+
+   memset(vtpm, 0, sizeof(*vtpm));
+   tmp =3D libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/handle",
fe_path));
+   if (tmp) {
+      vtpm->devid =3D atoi(tmp);
+   }
+   tmp =3D libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc,
"%s/backend-id", fe_path));
+   if(tmp) {
+      vtpm->backend_domid =3D atoi(tmp);
+   }
+   tmp =3D libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/uuid",
fe_path));
+   if(tmp) {
+      libxl_uuid_from_string(&(vtpm->uuid), tmp);
+   }
+}
+
+libxl_device_vtpm *libxl_device_vtpm_list(libxl_ctx *ctx, uint32_t
domid, int *num)
+{
+    GC_INIT(ctx);
+
+    libxl_device_vtpm* vtpms =3D NULL;
+    char* fe_path =3D NULL;
+    char** dir =3D NULL;
+    unsigned int ndirs =3D 0;
+
+    *num =3D 0;
+
+    fe_path =3D libxl__sprintf(gc, "%s/device/vtpm",
libxl__xs_get_dompath(gc, domid));
+    dir =3D libxl__xs_directory(gc, XBT_NULL, fe_path, &ndirs);
+    if(dir) {
+       vtpms =3D malloc(sizeof(*vtpms) * ndirs);
+       libxl_device_vtpm* vtpm;
+       libxl_device_vtpm* end =3D vtpms + ndirs;
+       for(vtpm =3D vtpms; vtpm < end; ++vtpm, ++dir) {
+          const char* path =3D libxl__sprintf(gc, "%s/%s", fe_path, *dir=
);
+          libxl__device_vtpm_from_xs_fe(gc, path, vtpm);
+       }
+    }
+    *num =3D ndirs;
+
+    GC_FREE;
+    return vtpms;
+}
+
+int libxl_device_vtpm_getinfo(libxl_ctx *ctx, uint32_t domid,
+                               libxl_device_vtpm *vtpm, libxl_vtpminfo
*vtpminfo)
+{
+    GC_INIT(ctx);
+    char *dompath, *vtpmpath;
+    char *val;
+    int rc =3D 0;
+
+    libxl_vtpminfo_init(vtpminfo);
+    dompath =3D libxl__xs_get_dompath(gc, domid);
+    vtpminfo->devid =3D vtpm->devid;
+
+    vtpmpath =3D libxl__sprintf(gc, "%s/device/vtpm/%d", dompath,
vtpminfo->devid);
+    vtpminfo->backend =3D xs_read(ctx->xsh, XBT_NULL,
+                                libxl__sprintf(gc, "%s/backend",
vtpmpath), NULL);
+    if (!vtpminfo->backend) {
+        goto err;
+    }
+    if(!libxl__xs_read(gc, XBT_NULL, vtpminfo->backend)) {
+       goto err;
+    }
+
+    val =3D libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc,
"%s/backend-id", vtpmpath));
+    vtpminfo->backend_id =3D val ? strtoul(val, NULL, 10) : -1;
+    val =3D libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/state",
vtpmpath));
+    vtpminfo->state =3D val ? strtoul(val, NULL, 10) : -1;
+    val =3D libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc,
"%s/event-channel", vtpmpath));
+    vtpminfo->evtch =3D val ? strtoul(val, NULL, 10) : -1;
+    val =3D libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc,
"%s/ring-ref", vtpmpath));
+    vtpminfo->rref =3D val ? strtoul(val, NULL, 10) : -1;
+    vtpminfo->frontend =3D xs_read(ctx->xsh, XBT_NULL,
+                                 libxl__sprintf(gc, "%s/frontend",
vtpminfo->backend), NULL);
+    val =3D libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc,
"%s/frontend-id", vtpminfo->backend));
+    vtpminfo->frontend_id =3D val ? strtoul(val, NULL, 10) : -1;
+
+    val =3D libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/uuid",
vtpminfo->backend));
+    if(val =3D=3D NULL) {
+       LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "%s/uuid does not exist!\n",
vtpminfo->backend);
+       goto err;
+    }
+    if(libxl_uuid_from_string(&(vtpminfo->uuid), val)) {
+       LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "%s/uuid is a malformed uuid??
(%s) Probably a bug!\n", vtpminfo->backend, val);
+       goto err;
+    }
+
+    goto exit;
+err:
+    rc =3D ERROR_FAIL;
+exit:
+    GC_FREE;
+    return rc;
+}
+
+int libxl_devid_to_device_vtpm(libxl_ctx *ctx, uint32_t domid,
+                              int devid, libxl_device_vtpm *vtpm)
+{
+    libxl_device_vtpm *vtpms;
+    int nb, i;
+    int rc;
+
+    vtpms =3D libxl_device_vtpm_list(ctx, domid, &nb);
+    if (!vtpms)
+        return ERROR_FAIL;
+
+    memset(vtpm, 0, sizeof (libxl_device_vtpm));
+    rc =3D 1;
+    for (i =3D 0; i < nb; ++i) {
+        if(devid =3D=3D vtpms[i].devid) {
+            vtpm->backend_domid =3D vtpms[i].backend_domid;
+            vtpm->devid =3D vtpms[i].devid;
+            libxl_uuid_copy(&vtpm->uuid, &vtpms[i].uuid);
+            rc =3D 0;
+            break;
+        }
+    }
+
+    for (i=3D0; i<nb; i++)
+        libxl_device_vtpm_dispose(&vtpms[i]);
+    free(vtpms);
+    return rc;
+}
+
+
+/***********************************************************************=
*******/
=20
 int libxl__device_disk_setdefault(libxl__gc *gc, libxl_device_disk *disk=
)
 {
@@ -3174,6 +3414,10 @@ DEFINE_DEVICE_REMOVE(vkb, destroy, 1)
 DEFINE_DEVICE_REMOVE(vfb, remove, 0)
 DEFINE_DEVICE_REMOVE(vfb, destroy, 1)
=20
+/* vtpm */
+DEFINE_DEVICE_REMOVE(vtpm, remove, 0)
+DEFINE_DEVICE_REMOVE(vtpm, destroy, 1)
+
 #undef DEFINE_DEVICE_REMOVE
=20
 /***********************************************************************=
*******/
@@ -3208,6 +3452,9 @@ DEFINE_DEVICE_ADD(disk)
 /* nic */
 DEFINE_DEVICE_ADD(nic)
=20
+/* vtpm */
+DEFINE_DEVICE_ADD(vtpm)
+
 #undef DEFINE_DEVICE_ADD
=20
 /***********************************************************************=
*******/
diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -478,13 +478,14 @@ typedef struct {
     libxl_domain_create_info c_info;
     libxl_domain_build_info b_info;
=20
-    int num_disks, num_nics, num_pcidevs, num_vfbs, num_vkbs;
+    int num_disks, num_nics, num_pcidevs, num_vfbs, num_vkbs, num_vtpms;=

=20
     libxl_device_disk *disks;
     libxl_device_nic *nics;
     libxl_device_pci *pcidevs;
     libxl_device_vfb *vfbs;
     libxl_device_vkb *vkbs;
+    libxl_device_vtpm *vtpms;
=20
     libxl_action_on_shutdown on_poweroff;
     libxl_action_on_shutdown on_reboot;
@@ -745,6 +746,23 @@ 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,
                               libxl_device_nic *nic, libxl_nicinfo
*nicinfo);
=20
+/* Virtual TPMs */
+int libxl_device_vtpm_add(libxl_ctx *ctx, uint32_t domid,
libxl_device_vtpm *vtpm,
+                          const libxl_asyncop_how *ao_how)
+                          LIBXL_EXTERNAL_CALLERS_ONLY;
+int libxl_device_vtpm_remove(libxl_ctx *ctx, uint32_t domid,
+                            libxl_device_vtpm *vtpm,
+                            const libxl_asyncop_how *ao_how)
+                            LIBXL_EXTERNAL_CALLERS_ONLY;
+int libxl_device_vtpm_destroy(libxl_ctx *ctx, uint32_t domid,
+                              libxl_device_vtpm *vtpm,
+                              const libxl_asyncop_how *ao_how)
+                              LIBXL_EXTERNAL_CALLERS_ONLY;
+
+libxl_device_vtpm *libxl_device_vtpm_list(libxl_ctx *ctx, uint32_t
domid, int *num);
+int libxl_device_vtpm_getinfo(libxl_ctx *ctx, uint32_t domid,
+                               libxl_device_vtpm *vtpm, libxl_vtpminfo
*vtpminfo);
+
 /* Keyboard */
 int libxl_device_vkb_add(libxl_ctx *ctx, uint32_t domid,
libxl_device_vkb *vkb,
                          const libxl_asyncop_how *ao_how)
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
@@ -55,6 +55,10 @@ void libxl_domain_config_dispose(libxl_domain_config
*d_config)
         libxl_device_vkb_dispose(&d_config->vkbs[i]);
     free(d_config->vkbs);
=20
+    for (i=3D0; i<d_config->num_vtpms; i++)
+       libxl_device_vtpm_dispose(&d_config->vtpms[i]);
+    free(d_config->vtpms);
+
     libxl_domain_create_info_dispose(&d_config->c_info);
     libxl_domain_build_info_dispose(&d_config->b_info);
 }
@@ -601,6 +605,8 @@ static void domcreate_bootloader_done(libxl__egc *egc=
,
 static void domcreate_launch_dm(libxl__egc *egc, libxl__multidev *aodevs=
,
                                 int ret);
=20
+static void domcreate_attach_vtpms(libxl__egc *egc, libxl__multidev
*multidev,
+                                   int ret);
 static void domcreate_attach_pci(libxl__egc *egc, libxl__multidev *aodev=
s,
                                  int ret);
=20
@@ -1084,13 +1090,13 @@ static void
domcreate_devmodel_started(libxl__egc *egc,
     if (d_config->num_nics > 0) {
         /* Attach nics */
         libxl__multidev_begin(ao, &dcs->multidev);
-        dcs->multidev.callback =3D domcreate_attach_pci;
+        dcs->multidev.callback =3D domcreate_attach_vtpms;
         libxl__add_nics(egc, ao, domid, d_config, &dcs->multidev);
         libxl__multidev_prepared(egc, &dcs->multidev, 0);
         return;
     }
=20
-    domcreate_attach_pci(egc, &dcs->multidev, 0);
+    domcreate_attach_vtpms(egc, &dcs->multidev, 0);
     return;
=20
 error_out:
@@ -1098,6 +1104,36 @@ error_out:
     domcreate_complete(egc, dcs, ret);
 }
=20
+static void domcreate_attach_vtpms(libxl__egc *egc, libxl__multidev
*multidev, int ret) {
+   libxl__domain_create_state *dcs =3D CONTAINER_OF(multidev, *dcs,
multidev);
+   STATE_AO_GC(dcs->ao);
+   int domid =3D dcs->guest_domid;
+
+   libxl_domain_config* const d_config =3D dcs->guest_config;
+
+   if(ret) {
+      LOG(ERROR, "unable to add nic devices");
+      goto error_out;
+   }
+
+    /* Plug nic interfaces */
+    if (d_config->num_vtpms > 0) {
+        /* Attach nics */
+        libxl__multidev_begin(ao, &dcs->multidev);
+        dcs->multidev.callback =3D domcreate_attach_pci;
+        libxl__add_vtpms(egc, ao, domid, d_config, &dcs->multidev);
+        libxl__multidev_prepared(egc, &dcs->multidev, 0);
+        return;
+    }
+
+   domcreate_attach_pci(egc, multidev, 0);
+   return;
+
+error_out:
+   assert(ret);
+   domcreate_complete(egc, dcs, ret);
+}
+
 static void domcreate_attach_pci(libxl__egc *egc, libxl__multidev
*multidev,
                                  int ret)
 {
@@ -1111,7 +1147,7 @@ static void domcreate_attach_pci(libxl__egc *egc,
libxl__multidev *multidev,
     libxl_domain_config *const d_config =3D dcs->guest_config;
=20
     if (ret) {
-        LOG(ERROR, "unable to add nic devices");
+        LOG(ERROR, "unable to add vtpm devices");
         goto error_out;
     }
=20
diff --git a/tools/libxl/libxl_device.c b/tools/libxl/libxl_device.c
--- a/tools/libxl/libxl_device.c
+++ b/tools/libxl/libxl_device.c
@@ -515,6 +515,7 @@ void libxl__multidev_prepared(libxl__egc *egc,
=20
 DEFINE_DEVICES_ADD(disk)
 DEFINE_DEVICES_ADD(nic)
+DEFINE_DEVICES_ADD(vtpm)
=20
 #undef DEFINE_DEVICES_ADD
=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
@@ -954,6 +954,7 @@ _hidden int libxl__device_disk_setdefault(libxl__gc *=
gc,
                                           libxl_device_disk *disk);
 _hidden int libxl__device_nic_setdefault(libxl__gc *gc,
libxl_device_nic *nic,
                                          uint32_t domid);
+_hidden int libxl__device_vtpm_setdefault(libxl__gc *gc,
libxl_device_vtpm *vtpm);
 _hidden int libxl__device_vfb_setdefault(libxl__gc *gc,
libxl_device_vfb *vfb);
 _hidden int libxl__device_vkb_setdefault(libxl__gc *gc,
libxl_device_vkb *vkb);
 _hidden int libxl__device_pci_setdefault(libxl__gc *gc,
libxl_device_pci *pci);
@@ -1975,6 +1976,10 @@ _hidden void libxl__device_nic_add(libxl__egc
*egc, uint32_t domid,
                                    libxl_device_nic *nic,
                                    libxl__ao_device *aodev);
=20
+_hidden void libxl__device_vtpm_add(libxl__egc *egc, uint32_t domid,
+                                   libxl_device_vtpm *vtpm,
+                                   libxl__ao_device *aodev);
+
 /* Internal function to connect a vkb device */
 _hidden int libxl__device_vkb_add(libxl__gc *gc, uint32_t domid,
                                   libxl_device_vkb *vkb);
@@ -2407,6 +2412,10 @@ _hidden void libxl__add_nics(libxl__egc *egc,
libxl__ao *ao, uint32_t domid,
                              libxl_domain_config *d_config,
                              libxl__multidev *multidev);
=20
+_hidden void libxl__add_vtpms(libxl__egc *egc, libxl__ao *ao, uint32_t
domid,
+                             libxl_domain_config *d_config,
+                             libxl__multidev *multidev);
+
 /*----- device model creation -----*/
=20
 /* First layer; wraps libxl__spawn_spawn. */
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
@@ -395,6 +395,12 @@ libxl_device_pci =3D Struct("device_pci", [
     ("permissive", bool),
     ])
=20
+libxl_device_vtpm =3D Struct("device_vtpm", [
+    ("backend_domid",    libxl_domid),
+    ("devid",            libxl_devid),
+    ("uuid",             libxl_uuid),
+])
+
 libxl_diskinfo =3D Struct("diskinfo", [
     ("backend", string),
     ("backend_id", uint32),
@@ -418,6 +424,18 @@ libxl_nicinfo =3D Struct("nicinfo", [
     ("rref_rx", integer),
     ], dir=3DDIR_OUT)
=20
+libxl_vtpminfo =3D Struct("vtpminfo", [
+    ("backend", string),
+    ("backend_id", uint32),
+    ("frontend", string),
+    ("frontend_id", uint32),
+    ("devid", libxl_devid),
+    ("state", integer),
+    ("evtch", integer),
+    ("rref", integer),
+    ("uuid", libxl_uuid),
+    ], dir=3DDIR_OUT)
+
 libxl_vcpuinfo =3D Struct("vcpuinfo", [
     ("vcpuid", uint32),
     ("cpu", uint32),
diff --git a/tools/libxl/libxl_types_internal.idl
b/tools/libxl/libxl_types_internal.idl
--- a/tools/libxl/libxl_types_internal.idl
+++ b/tools/libxl/libxl_types_internal.idl
@@ -19,6 +19,7 @@ libxl__device_kind =3D Enumeration("device_kind", [
     (5, "VFB"),
     (6, "VKBD"),
     (7, "CONSOLE"),
+    (8, "VTPM"),
     ])
=20
 libxl__console_backend =3D Enumeration("console_backend", [
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
@@ -463,6 +463,35 @@ int libxl_pipe(libxl_ctx *ctx, int pipes[2])
     return 0;
 }
=20
+int libxl_uuid_to_device_vtpm(libxl_ctx *ctx, uint32_t domid,
+                            libxl_uuid* uuid, libxl_device_vtpm *vtpm)
+{
+    libxl_device_vtpm *vtpms;
+    int nb, i;
+    int rc;
+
+    vtpms =3D libxl_device_vtpm_list(ctx, domid, &nb);
+    if (!vtpms)
+        return ERROR_FAIL;
+
+    memset(vtpm, 0, sizeof (libxl_device_vtpm));
+    rc =3D 1;
+    for (i =3D 0; i < nb; ++i) {
+        if(!libxl_uuid_compare(uuid, &vtpms[i].uuid)) {
+            vtpm->backend_domid =3D vtpms[i].backend_domid;
+            vtpm->devid =3D vtpms[i].devid;
+            libxl_uuid_copy(&vtpm->uuid, &vtpms[i].uuid);
+            rc =3D 0;
+            break;
+        }
+    }
+
+    for (i=3D0; i<nb; i++)
+        libxl_device_vtpm_dispose(&vtpms[i]);
+    free(vtpms);
+    return rc;
+}
+
 int libxl_mac_to_device_nic(libxl_ctx *ctx, uint32_t domid,
                             const char *mac, libxl_device_nic *nic)
 {
diff --git a/tools/libxl/libxl_utils.h b/tools/libxl/libxl_utils.h
--- a/tools/libxl/libxl_utils.h
+++ b/tools/libxl/libxl_utils.h
@@ -64,6 +64,11 @@ int libxl_devid_to_device_nic(libxl_ctx *ctx,
uint32_t domid, int devid,
 int libxl_vdev_to_device_disk(libxl_ctx *ctx, uint32_t domid, const
char *vdev,
                                libxl_device_disk *disk);
=20
+int libxl_uuid_to_device_vtpm(libxl_ctx *ctx, uint32_t domid,
+                               libxl_uuid *uuid, libxl_device_vtpm *vtpm=
);
+int libxl_devid_to_device_vtpm(libxl_ctx *ctx, uint32_t domid,
+                               int devid, libxl_device_vtpm *vtpm);
+
 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. */
diff --git a/tools/libxl/xl.h b/tools/libxl/xl.h
--- a/tools/libxl/xl.h
+++ b/tools/libxl/xl.h
@@ -79,6 +79,9 @@ int main_networkdetach(int argc, char **argv);
 int main_blockattach(int argc, char **argv);
 int main_blocklist(int argc, char **argv);
 int main_blockdetach(int argc, char **argv);
+int main_vtpmattach(int argc, char **argv);
+int main_vtpmlist(int argc, char **argv);
+int main_vtpmdetach(int argc, char **argv);
 int main_uptime(int argc, char **argv);
 int main_tmem_list(int argc, char **argv);
 int main_tmem_freeze(int argc, char **argv);
diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -573,7 +573,7 @@ static void parse_config_data(const char *config_sour=
ce,
     const char *buf;
     long l;
     XLU_Config *config;
-    XLU_ConfigList *cpus, *vbds, *nics, *pcis, *cvfbs, *cpuids;
+    XLU_ConfigList *cpus, *vbds, *nics, *pcis, *cvfbs, *cpuids, *vtpms;
     XLU_ConfigList *ioports, *irqs, *iomem;
     int num_ioports, num_irqs, num_iomem;
     int pci_power_mgmt =3D 0;
@@ -1045,6 +1045,47 @@ static void parse_config_data(const char
*config_source,
         }
     }
=20
+    if (!xlu_cfg_get_list(config, "vtpm", &vtpms, 0, 0)) {
+        d_config->num_vtpms =3D 0;
+        d_config->vtpms =3D NULL;
+        while ((buf =3D xlu_cfg_get_listitem (vtpms,
d_config->num_vtpms)) !=3D NULL) {
+            libxl_device_vtpm *vtpm;
+            char * buf2 =3D strdup(buf);
+            char *p, *p2;
+
+            d_config->vtpms =3D (libxl_device_vtpm *)
realloc(d_config->vtpms, sizeof(libxl_device_vtpm) *
(d_config->num_vtpms+1));
+            vtpm =3D d_config->vtpms + d_config->num_vtpms;
+            libxl_device_vtpm_init(vtpm);
+            vtpm->devid =3D d_config->num_vtpms;
+
+            p =3D strtok(buf2, ",");
+            if (!p)
+                goto skip_vtpm;
+            do {
+                while(*p =3D=3D ' ')
+                    ++p;
+                if ((p2 =3D strchr(p, '=3D')) =3D=3D NULL)
+                    break;
+                *p2 =3D '\0';
+                if (!strcmp(p, "backend")) {
+                    if(domain_qualifier_to_domid(p2 + 1,
&(vtpm->backend_domid), 0))
+                    {
+                        fprintf(stderr, "Specified backend domain does
not exist, defaulting to Dom0\n");
+                        vtpm->backend_domid =3D 0;
+                    }
+                } else if(!strcmp(p, "uuid")) {
+                    if( libxl_uuid_from_string(&vtpm->uuid, p2 + 1) ) {
+                        fprintf(stderr, "Failed to parse vtpm UUID:
%s\n", p2 + 1);
+                        exit(1);
+                    }
+                }
+            } while ((p =3D strtok(NULL, ",")) !=3D NULL);
+skip_vtpm:
+            free(buf2);
+            d_config->num_vtpms++;
+        }
+    }
+
     if (!xlu_cfg_get_list (config, "vif", &nics, 0, 0)) {
         d_config->num_nics =3D 0;
         d_config->nics =3D NULL;
@@ -1070,7 +1111,7 @@ static void parse_config_data(const char
*config_source,
=20
             p =3D strtok(buf2, ",");
             if (!p)
-                goto skip;
+                goto skip_nic;
             do {
                 while (*p =3D=3D ' ')
                     p++;
@@ -1134,7 +1175,7 @@ static void parse_config_data(const char
*config_source,
                     fprintf(stderr, "the accel parameter for vifs is
currently not supported\n");
                 }
             } while ((p =3D strtok(NULL, ",")) !=3D NULL);
-skip:
+skip_nic:
             free(buf2);
             d_config->num_nics++;
         }
@@ -5570,6 +5611,131 @@ int main_blockdetach(int argc, char **argv)
     return rc;
 }
=20
+int main_vtpmattach(int argc, char **argv)
+{
+    int opt;
+    libxl_device_vtpm vtpm;
+    char *oparg;
+    unsigned int val;
+    uint32_t domid;
+
+    if ((opt =3D def_getopt(argc, argv, "", "vtpm-attach", 1)) !=3D -1)
+        return opt;
+
+    if (domain_qualifier_to_domid(argv[optind], &domid, 0) < 0) {
+        fprintf(stderr, "%s is an invalid domain identifier\n",
argv[optind]);
+        return 1;
+    }
+    ++optind;
+
+    libxl_device_vtpm_init(&vtpm);
+    for (argv +=3D optind, argc -=3D optind; argc > 0; ++argv, --argc) {=

+        if (MATCH_OPTION("uuid", *argv, oparg)) {
+            if(libxl_uuid_from_string(&(vtpm.uuid), oparg)) {
+                fprintf(stderr, "Invalid uuid specified (%s)\n", oparg);=

+                return 1;
+            }
+        } else if (MATCH_OPTION("backend", *argv, oparg)) {
+            if(domain_qualifier_to_domid(oparg, &val, 0)) {
+                fprintf(stderr, "Specified backend domain does not
exist, defaulting to Dom0\n");
+                val =3D 0;
+            }
+            vtpm.backend_domid =3D val;
+        } else {
+            fprintf(stderr, "unrecognized argument `%s'\n", *argv);
+            return 1;
+        }
+    }
+
+    if(dryrun_only) {
+       char* json =3D libxl_device_vtpm_to_json(ctx, &vtpm);
+       printf("vtpm: %s\n", json);
+       free(json);
+       libxl_device_vtpm_dispose(&vtpm);
+       if (ferror(stdout) || fflush(stdout)) { perror("stdout");
exit(-1); }
+       return 0;
+    }
+
+    if (libxl_device_vtpm_add(ctx, domid, &vtpm, 0)) {
+        fprintf(stderr, "libxl_device_vtpm_add failed.\n");
+        return 1;
+    }
+    libxl_device_vtpm_dispose(&vtpm);
+    return 0;
+}
+
+int main_vtpmlist(int argc, char **argv)
+{
+    int opt;
+    libxl_device_vtpm *vtpms;
+    libxl_vtpminfo vtpminfo;
+    int nb, i;
+
+    if ((opt =3D def_getopt(argc, argv, "", "vtpm-list", 1)) !=3D -1)
+        return opt;
+
+    /*      Idx  BE   UUID   Hdl  Sta  evch rref  BE-path */
+    printf("%-3s %-2s %-36s %-6s %-5s %-6s %-5s %-10s\n",
+           "Idx", "BE", "Uuid", "handle", "state", "evt-ch",
"ring-ref", "BE-path");
+    for (argv +=3D optind, argc -=3D optind; argc > 0; --argc, ++argv) {=

+        uint32_t domid;
+        if (domain_qualifier_to_domid(*argv, &domid, 0) < 0) {
+            fprintf(stderr, "%s is an invalid domain identifier\n", *arg=
v);
+            continue;
+        }
+        if (!(vtpms =3D libxl_device_vtpm_list(ctx, domid, &nb))) {
+            continue;
+        }
+        for (i =3D 0; i < nb; ++i) {
+           if(!libxl_device_vtpm_getinfo(ctx, domid, &vtpms[i],
&vtpminfo)) {
+              /*      Idx  BE     UUID             Hdl Sta evch rref
BE-path*/
+              printf("%-3d %-2d " LIBXL_UUID_FMT " %6d %5d %6d %8d
%-30s\n",
+                    vtpminfo.devid, vtpminfo.backend_id,
+                    LIBXL_UUID_BYTES(vtpminfo.uuid),
+                    vtpminfo.devid, vtpminfo.state, vtpminfo.evtch,
+                    vtpminfo.rref, vtpminfo.backend);
+
+              libxl_vtpminfo_dispose(&vtpminfo);
+           }
+           libxl_device_vtpm_dispose(&vtpms[i]);
+        }
+        free(vtpms);
+    }
+    return 0;
+}
+
+int main_vtpmdetach(int argc, char **argv)
+{
+    uint32_t domid;
+    int opt, rc=3D0;
+    libxl_device_vtpm vtpm;
+    libxl_uuid uuid;
+
+    if ((opt =3D def_getopt(argc, argv, "", "vtpm-detach", 2)) !=3D -1)
+        return opt;
+
+    domid =3D find_domain(argv[optind]);
+
+    if ( libxl_uuid_from_string(&uuid, argv[optind+1])) {
+        if (libxl_devid_to_device_vtpm(ctx, domid,
atoi(argv[optind+1]), &vtpm)) {
+            fprintf(stderr, "Unknown device %s.\n", argv[optind+1]);
+            return 1;
+        }
+    } else {
+        if (libxl_uuid_to_device_vtpm(ctx, domid, &uuid, &vtpm)) {
+            fprintf(stderr, "Unknown device %s.\n", argv[optind+1]);
+            return 1;
+        }
+    }
+    rc =3D libxl_device_vtpm_remove(ctx, domid, &vtpm, 0);
+    if (rc) {
+        fprintf(stderr, "libxl_device_vtpm_remove failed.\n");
+    }
+    libxl_device_vtpm_dispose(&vtpm);
+    return rc;
+}
+
+
 static char *uptime_to_string(unsigned long uptime, int short_mode)
 {
     int sec, min, hour, day;
diff --git a/tools/libxl/xl_cmdtable.c b/tools/libxl/xl_cmdtable.c
--- a/tools/libxl/xl_cmdtable.c
+++ b/tools/libxl/xl_cmdtable.c
@@ -338,6 +338,21 @@ struct cmd_spec cmd_table[] =3D {
       "Destroy a domain's virtual block device",
       "<Domain> <DevId>",
     },
+    { "vtpm-attach",
+      &main_vtpmattach, 0, 1,
+      "Create a new virtual TPM device",
+      "<Domain> [uuid=3D<uuid>] [backend=3D<BackDomain>]",
+    },
+    { "vtpm-list",
+      &main_vtpmlist, 0, 0,
+      "List virtual TPM devices for a domain",
+      "<Domain(s)>",
+    },
+    { "vtpm-detach",
+      &main_vtpmdetach, 0, 1,
+      "Destroy a domain's virtual TPM device",
+      "<Domain> <DevId|uuid>",
+    },
     { "uptime",
       &main_uptime, 0, 0,
       "Print uptime for all/some domains",



--------------ms090802060603040405080700
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIDyjCC
A8YwggMvoAMCAQICBD/xyf0wDQYJKoZIhvcNAQEFBQAwLzELMAkGA1UEBhMCVVMxDzANBgNV
BAoTBkpIVUFQTDEPMA0GA1UECxMGQklTRENBMB4XDTEwMDYxMTE4MjIwNloXDTEzMDYxMTE4
NTIwNlowZjELMAkGA1UEBhMCVVMxDzANBgNVBAoTBkpIVUFQTDEPMA0GA1UECxMGUGVvcGxl
MTUwFgYDVQQLEw9WUE5Hcm91cC1CSVNEQ0EwGwYDVQQDExRNYXR0aGV3IEUgRmlvcmF2YW50
ZTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAnpbwVSP6o1Nb5lcW7dd3yTo9iBJdi7qz
4nANOMFPK7JOy5npKN1iiousl28U/scUJES55gPwAWYJK3uVyQAsA4adgDKi5DoD1UHDQEwp
bY7iHLJeq0NPr4BqYNqnCFPbE6HC8zSJrr4qKn+gVUQT39SIFqdiIPJwZL8FYTRQ/zsCAwEA
AaOCAbYwggGyMAsGA1UdDwQEAwIHgDArBgNVHRAEJDAigA8yMDEwMDYxMTE4MjIwNlqBDzIw
MTIwNzE3MjI1MjA2WjAbBg0rBgEEAbMlCwMBAQEBBAoWCGZpb3JhbWUxMBsGDSsGAQQBsyUL
AwEBAQIEChIIMDAxMDQyNjEwWAYJYIZIAYb6ax4BBEsMSVRoZSBwcml2YXRlIGtleSBjb3Jy
ZXNwb25kaW5nIHRvIHRoaXMgY2VydGlmaWNhdGUgbWF5IGhhdmUgYmVlbiBleHBvcnRlZC4w
KAYDVR0RBCEwH4EdTWF0dGhldy5GaW9yYXZhbnRlQGpodWFwbC5lZHUwUgYDVR0fBEswSTBH
oEWgQ6RBMD8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJU0RD
QTEOMAwGA1UEAxMFQ1JMNTYwHwYDVR0jBBgwFoAUCDUpmxH52EU2CyWmF2EJMB1yqeswHQYD
VR0OBBYEFO6LYxg6r9wHZ+zdQtBHn1dZ/YTNMAkGA1UdEwQCMAAwGQYJKoZIhvZ9B0EABAww
ChsEVjcuMQMCBLAwDQYJKoZIhvcNAQEFBQADgYEAJO9HQh4YNChVLzuZqK5ARJARD8JoujGZ
fdo75quvg2jXFQe2sEjvLnxJZgm/pv8fdZakq48CWwjYHKuvIp7sDjTEsQfo+y7SpN/N2NvJ
WU5SqfK1VgYtNLRRoGJUB5Q1aZ+Dg95g3kqpyfpUMISJL8IKVLtJVfN4fggFVUYZ9wwxggGr
MIIBpwIBATA3MC8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJ
U0RDQQIEP/HJ/TAJBgUrDgMCGgUAoIHLMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ
KoZIhvcNAQkFMQ8XDTEyMDkyMTE5MjMzMlowIwYJKoZIhvcNAQkEMRYEFMTa7jHuXlTem+lk
SKikj8SEHmf/MGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAK
BggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI
KoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEgYCc35JMUfZQWjiUss/NIUV/qd9RO4Pvg9yq
0VEuMqy/NMLxi7hw0RLlFlpw30XwpDYWQtp3hxHtcvAAaEuQ5q8kUZvFQM/LXnn+AxpaE+Cc
U2Afqjd3GsMquSBaoF+5sIb8xQ/0IKp6qWvKJG9C4NRLC4ctxawkP7Pv2QgZpxoq3AAAAAAA
AA==
--------------ms090802060603040405080700--


--===============8538936571305762314==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============8538936571305762314==--


From xen-devel-bounces@lists.xen.org Fri Sep 21 19:28:31 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Sep 2012 19:28:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TF8tj-0004CF-73; Fri, 21 Sep 2012 19:28:23 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <matthew.fioravante@jhuapl.edu>) id 1TF8th-0004CA-JQ
	for xen-devel@lists.xensource.com; Fri, 21 Sep 2012 19:28:21 +0000
Received: from [85.158.139.83:12701] by server-4.bemta-5.messagelabs.com id
	F9/D7-23042-4DFBC505; Fri, 21 Sep 2012 19:28:20 +0000
X-Env-Sender: matthew.fioravante@jhuapl.edu
X-Msg-Ref: server-7.tower-182.messagelabs.com!1348255698!27642915!1
X-Originating-IP: [128.244.251.36]
X-SpamReason: No, hits=0.0 required=7.0 tests=UNPARSEABLE_RELAY
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22335 invoked from network); 21 Sep 2012 19:28:19 -0000
Received: from pilot.jhuapl.edu (HELO jhuapl.edu) (128.244.251.36)
	by server-7.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 21 Sep 2012 19:28:19 -0000
Received: from ([128.244.207.89])
	by pilot.jhuapl.edu with ESMTP with TLS id 63GHCH1.153411180;
	Fri, 21 Sep 2012 15:28:15 -0400
Message-ID: <505CBF82.3070101@jhuapl.edu>
Date: Fri, 21 Sep 2012 15:26:58 -0400
From: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120827 Thunderbird/15.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <5058B8DB.5040109@jhuapl.edu>
	<1348057160.14977.98.camel@zakaz.uk.xensource.com>
In-Reply-To: <1348057160.14977.98.camel@zakaz.uk.xensource.com>
X-Enigmail-Version: 1.4.4
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH xm/xl enhancements for vptm 1/6] xl make
 devid a libxl 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: multipart/mixed; boundary="===============2646327067926037264=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a cryptographically signed message in MIME format.

--===============2646327067926037264==
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms020501080502070900080009"

This is a cryptographically signed message in MIME format.

--------------ms020501080502070900080009
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 09/19/2012 08:19 AM, Ian Campbell wrote:
> On Tue, 2012-09-18 at 19:09 +0100, Matthew Fioravante wrote:
>> diff --git a/tools/ocaml/libs/xc/xenctrl.ml b/tools/ocaml/libs/xc/xenc=
trl.ml
>> --- a/tools/ocaml/libs/xc/xenctrl.ml
>> +++ b/tools/ocaml/libs/xc/xenctrl.ml
>> @@ -16,6 +16,7 @@
>> =20
>>  (** *)
>>  type domid =3D int
>> +type devid =3D int
> I don't think libxc exposes the notion of a devid, does it?
>
> In which case there's no need to have a type for it here or in the .mli=
=2E
Unfortunately it looks like the ocaml makefiles build their list of
types by using the libxl_types.idl system. Ocaml xs currently won't
compile without this.
>> diff --git a/tools/ocaml/libs/xs/xs.ml b/tools/ocaml/libs/xs/xs.ml
>> --- a/tools/ocaml/libs/xs/xs.ml
>> +++ b/tools/ocaml/libs/xs/xs.ml
>> @@ -17,6 +17,7 @@
>>  type perms =3D Xsraw.perms
>>  type con =3D Xsraw.con
>>  type domid =3D int
>> +type devid =3D int
> Likewise xenstore doesn't have a devid either AFAIK.
Same as above
>> 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
> Are you basing your patches on xen-unstable? I ask because this file
> isn't built there and so I wonder how you noticed it to change it.
I based it off of the xen-unstable tree on git, which I now realize is
the wrong tree.
> Ian.
>
The whole purpose of this patch is initialize device ids to -1 instead
of zero and the only way I could come up to do that cleanly within
libxl's type system was to create a new type. Is there another better
way to fix this problem? As long as device ids are initialized to zero,
all the xl DEVICE-attach commands will fail for attaching more than 1
device.



--------------ms020501080502070900080009
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIDyjCC
A8YwggMvoAMCAQICBD/xyf0wDQYJKoZIhvcNAQEFBQAwLzELMAkGA1UEBhMCVVMxDzANBgNV
BAoTBkpIVUFQTDEPMA0GA1UECxMGQklTRENBMB4XDTEwMDYxMTE4MjIwNloXDTEzMDYxMTE4
NTIwNlowZjELMAkGA1UEBhMCVVMxDzANBgNVBAoTBkpIVUFQTDEPMA0GA1UECxMGUGVvcGxl
MTUwFgYDVQQLEw9WUE5Hcm91cC1CSVNEQ0EwGwYDVQQDExRNYXR0aGV3IEUgRmlvcmF2YW50
ZTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAnpbwVSP6o1Nb5lcW7dd3yTo9iBJdi7qz
4nANOMFPK7JOy5npKN1iiousl28U/scUJES55gPwAWYJK3uVyQAsA4adgDKi5DoD1UHDQEwp
bY7iHLJeq0NPr4BqYNqnCFPbE6HC8zSJrr4qKn+gVUQT39SIFqdiIPJwZL8FYTRQ/zsCAwEA
AaOCAbYwggGyMAsGA1UdDwQEAwIHgDArBgNVHRAEJDAigA8yMDEwMDYxMTE4MjIwNlqBDzIw
MTIwNzE3MjI1MjA2WjAbBg0rBgEEAbMlCwMBAQEBBAoWCGZpb3JhbWUxMBsGDSsGAQQBsyUL
AwEBAQIEChIIMDAxMDQyNjEwWAYJYIZIAYb6ax4BBEsMSVRoZSBwcml2YXRlIGtleSBjb3Jy
ZXNwb25kaW5nIHRvIHRoaXMgY2VydGlmaWNhdGUgbWF5IGhhdmUgYmVlbiBleHBvcnRlZC4w
KAYDVR0RBCEwH4EdTWF0dGhldy5GaW9yYXZhbnRlQGpodWFwbC5lZHUwUgYDVR0fBEswSTBH
oEWgQ6RBMD8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJU0RD
QTEOMAwGA1UEAxMFQ1JMNTYwHwYDVR0jBBgwFoAUCDUpmxH52EU2CyWmF2EJMB1yqeswHQYD
VR0OBBYEFO6LYxg6r9wHZ+zdQtBHn1dZ/YTNMAkGA1UdEwQCMAAwGQYJKoZIhvZ9B0EABAww
ChsEVjcuMQMCBLAwDQYJKoZIhvcNAQEFBQADgYEAJO9HQh4YNChVLzuZqK5ARJARD8JoujGZ
fdo75quvg2jXFQe2sEjvLnxJZgm/pv8fdZakq48CWwjYHKuvIp7sDjTEsQfo+y7SpN/N2NvJ
WU5SqfK1VgYtNLRRoGJUB5Q1aZ+Dg95g3kqpyfpUMISJL8IKVLtJVfN4fggFVUYZ9wwxggGr
MIIBpwIBATA3MC8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJ
U0RDQQIEP/HJ/TAJBgUrDgMCGgUAoIHLMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ
KoZIhvcNAQkFMQ8XDTEyMDkyMTE5MjY1OFowIwYJKoZIhvcNAQkEMRYEFLTsG3qMbEsKFigW
gkMDfp1sA6TzMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAK
BggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI
KoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEgYAHjY9Sc7qKNSfIwrz3bZIbqB6UWmcYKIpd
ymFJpQtfngBROryv8sSGP+uGADf2SKJp/K7p9yardjSZZauUjHVpKWSkQ8sCehewmzhynwOt
tP9PvymMBZrXqqFEptGAVbSuk9O4MEMCQ716fMtira79kAat7VEGbLmbmUSFRoK0XwAAAAAA
AA==
--------------ms020501080502070900080009--


--===============2646327067926037264==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============2646327067926037264==--


From xen-devel-bounces@lists.xen.org Fri Sep 21 19:28:31 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Sep 2012 19:28:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TF8tj-0004CF-73; Fri, 21 Sep 2012 19:28:23 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <matthew.fioravante@jhuapl.edu>) id 1TF8th-0004CA-JQ
	for xen-devel@lists.xensource.com; Fri, 21 Sep 2012 19:28:21 +0000
Received: from [85.158.139.83:12701] by server-4.bemta-5.messagelabs.com id
	F9/D7-23042-4DFBC505; Fri, 21 Sep 2012 19:28:20 +0000
X-Env-Sender: matthew.fioravante@jhuapl.edu
X-Msg-Ref: server-7.tower-182.messagelabs.com!1348255698!27642915!1
X-Originating-IP: [128.244.251.36]
X-SpamReason: No, hits=0.0 required=7.0 tests=UNPARSEABLE_RELAY
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22335 invoked from network); 21 Sep 2012 19:28:19 -0000
Received: from pilot.jhuapl.edu (HELO jhuapl.edu) (128.244.251.36)
	by server-7.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 21 Sep 2012 19:28:19 -0000
Received: from ([128.244.207.89])
	by pilot.jhuapl.edu with ESMTP with TLS id 63GHCH1.153411180;
	Fri, 21 Sep 2012 15:28:15 -0400
Message-ID: <505CBF82.3070101@jhuapl.edu>
Date: Fri, 21 Sep 2012 15:26:58 -0400
From: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120827 Thunderbird/15.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <5058B8DB.5040109@jhuapl.edu>
	<1348057160.14977.98.camel@zakaz.uk.xensource.com>
In-Reply-To: <1348057160.14977.98.camel@zakaz.uk.xensource.com>
X-Enigmail-Version: 1.4.4
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH xm/xl enhancements for vptm 1/6] xl make
 devid a libxl 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: multipart/mixed; boundary="===============2646327067926037264=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a cryptographically signed message in MIME format.

--===============2646327067926037264==
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms020501080502070900080009"

This is a cryptographically signed message in MIME format.

--------------ms020501080502070900080009
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 09/19/2012 08:19 AM, Ian Campbell wrote:
> On Tue, 2012-09-18 at 19:09 +0100, Matthew Fioravante wrote:
>> diff --git a/tools/ocaml/libs/xc/xenctrl.ml b/tools/ocaml/libs/xc/xenc=
trl.ml
>> --- a/tools/ocaml/libs/xc/xenctrl.ml
>> +++ b/tools/ocaml/libs/xc/xenctrl.ml
>> @@ -16,6 +16,7 @@
>> =20
>>  (** *)
>>  type domid =3D int
>> +type devid =3D int
> I don't think libxc exposes the notion of a devid, does it?
>
> In which case there's no need to have a type for it here or in the .mli=
=2E
Unfortunately it looks like the ocaml makefiles build their list of
types by using the libxl_types.idl system. Ocaml xs currently won't
compile without this.
>> diff --git a/tools/ocaml/libs/xs/xs.ml b/tools/ocaml/libs/xs/xs.ml
>> --- a/tools/ocaml/libs/xs/xs.ml
>> +++ b/tools/ocaml/libs/xs/xs.ml
>> @@ -17,6 +17,7 @@
>>  type perms =3D Xsraw.perms
>>  type con =3D Xsraw.con
>>  type domid =3D int
>> +type devid =3D int
> Likewise xenstore doesn't have a devid either AFAIK.
Same as above
>> 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
> Are you basing your patches on xen-unstable? I ask because this file
> isn't built there and so I wonder how you noticed it to change it.
I based it off of the xen-unstable tree on git, which I now realize is
the wrong tree.
> Ian.
>
The whole purpose of this patch is initialize device ids to -1 instead
of zero and the only way I could come up to do that cleanly within
libxl's type system was to create a new type. Is there another better
way to fix this problem? As long as device ids are initialized to zero,
all the xl DEVICE-attach commands will fail for attaching more than 1
device.



--------------ms020501080502070900080009
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIDyjCC
A8YwggMvoAMCAQICBD/xyf0wDQYJKoZIhvcNAQEFBQAwLzELMAkGA1UEBhMCVVMxDzANBgNV
BAoTBkpIVUFQTDEPMA0GA1UECxMGQklTRENBMB4XDTEwMDYxMTE4MjIwNloXDTEzMDYxMTE4
NTIwNlowZjELMAkGA1UEBhMCVVMxDzANBgNVBAoTBkpIVUFQTDEPMA0GA1UECxMGUGVvcGxl
MTUwFgYDVQQLEw9WUE5Hcm91cC1CSVNEQ0EwGwYDVQQDExRNYXR0aGV3IEUgRmlvcmF2YW50
ZTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAnpbwVSP6o1Nb5lcW7dd3yTo9iBJdi7qz
4nANOMFPK7JOy5npKN1iiousl28U/scUJES55gPwAWYJK3uVyQAsA4adgDKi5DoD1UHDQEwp
bY7iHLJeq0NPr4BqYNqnCFPbE6HC8zSJrr4qKn+gVUQT39SIFqdiIPJwZL8FYTRQ/zsCAwEA
AaOCAbYwggGyMAsGA1UdDwQEAwIHgDArBgNVHRAEJDAigA8yMDEwMDYxMTE4MjIwNlqBDzIw
MTIwNzE3MjI1MjA2WjAbBg0rBgEEAbMlCwMBAQEBBAoWCGZpb3JhbWUxMBsGDSsGAQQBsyUL
AwEBAQIEChIIMDAxMDQyNjEwWAYJYIZIAYb6ax4BBEsMSVRoZSBwcml2YXRlIGtleSBjb3Jy
ZXNwb25kaW5nIHRvIHRoaXMgY2VydGlmaWNhdGUgbWF5IGhhdmUgYmVlbiBleHBvcnRlZC4w
KAYDVR0RBCEwH4EdTWF0dGhldy5GaW9yYXZhbnRlQGpodWFwbC5lZHUwUgYDVR0fBEswSTBH
oEWgQ6RBMD8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJU0RD
QTEOMAwGA1UEAxMFQ1JMNTYwHwYDVR0jBBgwFoAUCDUpmxH52EU2CyWmF2EJMB1yqeswHQYD
VR0OBBYEFO6LYxg6r9wHZ+zdQtBHn1dZ/YTNMAkGA1UdEwQCMAAwGQYJKoZIhvZ9B0EABAww
ChsEVjcuMQMCBLAwDQYJKoZIhvcNAQEFBQADgYEAJO9HQh4YNChVLzuZqK5ARJARD8JoujGZ
fdo75quvg2jXFQe2sEjvLnxJZgm/pv8fdZakq48CWwjYHKuvIp7sDjTEsQfo+y7SpN/N2NvJ
WU5SqfK1VgYtNLRRoGJUB5Q1aZ+Dg95g3kqpyfpUMISJL8IKVLtJVfN4fggFVUYZ9wwxggGr
MIIBpwIBATA3MC8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJ
U0RDQQIEP/HJ/TAJBgUrDgMCGgUAoIHLMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ
KoZIhvcNAQkFMQ8XDTEyMDkyMTE5MjY1OFowIwYJKoZIhvcNAQkEMRYEFLTsG3qMbEsKFigW
gkMDfp1sA6TzMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAK
BggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI
KoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEgYAHjY9Sc7qKNSfIwrz3bZIbqB6UWmcYKIpd
ymFJpQtfngBROryv8sSGP+uGADf2SKJp/K7p9yardjSZZauUjHVpKWSkQ8sCehewmzhynwOt
tP9PvymMBZrXqqFEptGAVbSuk9O4MEMCQ716fMtira79kAat7VEGbLmbmUSFRoK0XwAAAAAA
AA==
--------------ms020501080502070900080009--


--===============2646327067926037264==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============2646327067926037264==--


From xen-devel-bounces@lists.xen.org Fri Sep 21 19:30:16 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Sep 2012 19: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 1TF8vP-0004IQ-NT; Fri, 21 Sep 2012 19:30:07 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andres.lagarcavilla@gmail.com>) id 1TF8vO-0004IH-B0
	for xen-devel@lists.xen.org; Fri, 21 Sep 2012 19:30:06 +0000
Received: from [85.158.139.211:28016] by server-2.bemta-5.messagelabs.com id
	B1/B0-11456-D30CC505; Fri, 21 Sep 2012 19:30:05 +0000
X-Env-Sender: andres.lagarcavilla@gmail.com
X-Msg-Ref: server-12.tower-206.messagelabs.com!1348255802!18501910!1
X-Originating-IP: [209.85.223.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14777 invoked from network); 21 Sep 2012 19:30:04 -0000
Received: from mail-ie0-f173.google.com (HELO mail-ie0-f173.google.com)
	(209.85.223.173)
	by server-12.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Sep 2012 19:30:04 -0000
Received: by iea17 with SMTP id 17so2384449iea.32
	for <xen-devel@lists.xen.org>; Fri, 21 Sep 2012 12:30:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=subject:mime-version:content-type:from:in-reply-to:date:cc
	:content-transfer-encoding:message-id:references:to:x-mailer;
	bh=83QR3YY++4kQrasLiVeMTughtBu6TGkSeEXjMMZJio4=;
	b=K15a85cjZYW1SETpW61u5sWldswFrFviJUVjdZJXoFRULJY+zBur9hXUmZPvTSz+y1
	DQV5Dgv8EJOZ49ToW5XbU9LFwUFrpKP7r4fK3kYdUAqA4RNRqRVNrGQvrlod0KPPBzFA
	EyZJNy8n9ElSm/trn8esGLEWmgKLILf37mm6nkydp2uzwBlSqTFlW1r3PG1qRqIb4MYq
	uYWLJicTd8Kx8Ukrp8/3AYv+kzloT9MDgvrDsZJIzhV3oljZuBksu4yNg/7laYWbl6WK
	EDgnmJ19nJcZkeg5iy3/LzuMw71R2haidlTTBYUszMGa08ILGTIMx9SloHG2vWAyWrQI
	p/dQ==
Received: by 10.50.57.225 with SMTP id l1mr2654799igq.29.1348255802138;
	Fri, 21 Sep 2012 12:30:02 -0700 (PDT)
Received: from [192.168.7.210] ([206.223.182.18])
	by mx.google.com with ESMTPS id wg9sm2331074igb.0.2012.09.21.12.30.00
	(version=TLSv1/SSLv3 cipher=OTHER);
	Fri, 21 Sep 2012 12:30:01 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1278)
From: Andres Lagar-Cavilla <andres.lagarcavilla@gmail.com>
In-Reply-To: <20120921185258.GA4931@phenom.dumpdata.com>
Date: Fri, 21 Sep 2012 15:30:01 -0400
Message-Id: <ACFBD23A-6B32-47F3-B71A-37F4557FDE47@gmail.com>
References: <1347632819-13684-1-git-send-email-andres@lagarcavilla.org>
	<1347869865.14977.15.camel@zakaz.uk.xensource.com>
	<5B5132A4-93B2-41D0-B1A6-048810565DB5@gridcentric.ca>
	<20120921185258.GA4931@phenom.dumpdata.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
X-Mailer: Apple Mail (2.1278)
Cc: Ian Campbell <Ian.Campbell@citrix.com>,
	Andres Lagar-Cavilla <andreslc@gridcentric.ca>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	xen-devel <xen-devel@lists.xen.org>,
	David Vrabel <david.vrabel@citrix.com>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	David Miller <davem@davemloft.net>,
	Andres Lagar-Cavilla <andres@lagarcavilla.org>
Subject: Re: [Xen-devel] [PATCH] Xen backend support for paged out grant
	targets V4.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <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 Sep 21, 2012, at 2:52 PM, Konrad Rzeszutek Wilk wrote:

> On Mon, Sep 17, 2012 at 05:29:24AM -0400, Andres Lagar-Cavilla wrote:
>> On Sep 17, 2012, at 4:17 AM, Ian Campbell wrote:
>> =

>>> (I think I forgot to hit send on this on Friday, sorry. Also
>>> s/xen.lists.org/lists.xen.org in the CC line=85)
>> I'm on a roll here=85
>> =

>>> =

>>> On Fri, 2012-09-14 at 15:26 +0100, Andres Lagar-Cavilla wrote:
>>>> Since Xen-4.2, hvm domains may have portions of their memory paged out=
. When a
>>>> foreign domain (such as dom0) attempts to map these frames, the map wi=
ll
>>>> initially fail. The hypervisor returns a suitable errno, and kicks an
>>>> asynchronous page-in operation carried out by a helper. The foreign do=
main is
>>>> expected to retry the mapping operation until it eventually succeeds. =
The
>>>> foreign domain is not put to sleep because itself could be the one run=
ning the
>>>> pager assist (typical scenario for dom0).
>>>> =

>>>> This patch adds support for this mechanism for backend drivers using g=
rant
>>>> mapping and copying operations. Specifically, this covers the blkback =
and
>>>> gntdev drivers (which map foregin grants), and the netback driver (whi=
ch copies
>>> =

>>>                          foreign
>>> =

>>>> foreign grants).
>>>> =

>>>> * Add a retry method for grants that fail with GNTST_eagain (i.e. beca=
use the
>>>> target foregin frame is paged out).
>>> =

>>>         foreign
>>> =

>>>> * Insert hooks with appropriate wrappers in the aforementioned drivers.
>>>> =

>>>> The retry loop is only invoked if the grant operation status is GNTST_=
eagain.
>>>> It guarantees to leave a new status code different from GNTST_eagain. =
Any other
>>>> status code results in identical code execution as before.
>>>> =

>>>> The retry loop performs 256 attempts with increasing time intervals th=
rough a
>>>> 32 second period. It uses msleep to yield while waiting for the next r=
etry.
>>> [...]
>>>> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
>>> =

>>> Acked-by: Ian Campbell <ian.campbell@citrix.com>
>>> =

>>> Since this is more about grant tables than netback this should probably
>>> go via Konrad rather than Dave, is that OK with you Dave?
>> =

>> If that is the case hopefully Konrad can deal with the two typos? Otherw=
ise happy to re-spin the patch.
> =

> So with this patch when I launch an PVHVM guest on Xen 4.1 I get this
> in the initial domain and the guest is crashed:
> =

> [  261.927218] privcmd_fault: vma=3Dffff88002a31dce8 7f4edc095000-7f4edc1=
95000, pgoff=3Dc8, uv=3D00007f4edc15d000

With this patch? Or with the mmapbatch v2? This is a page fault in a foreig=
n-mapped VMA. Not touched by this grant backend patch we are talking about.

Does the hypervisor dump anything to its console?

At which point during xc_hvm_build do you see this? (or elsewhere in the to=
olstack?)

Thanks
Andres

> =

> guest config:
>> more /mnt/lab/latest/hvm.xm =

> kernel =3D "/usr/lib/xen/boot/hvmloader"
> builder=3D'hvm'
> memory=3D1024
> #maxmem=3D1024
> maxvcpus =3D 2
> serial=3D'pty'
> vcpus =3D 2
> disk =3D [ 'file:/mnt/lab/latest/root_image.iso,hdc:cdrom,r']
> boot=3D"dn"
> #vif =3D [ 'type=3Dioemu,model=3De1000,mac=3D00:0F:4B:00:00:71, bridge=3D=
switch' ]
> vif =3D [ 'type=3Dnetfront, bridge=3Dswitch' ]
> #vfb =3D [ 'vnc=3D1, vnclisten=3D0.0.0.0 ,vncunused=3D1']
> vnc=3D1
> vnclisten=3D"0.0.0.0"
> usb=3D1
> xen_platform_pci=3D1
> =

> =



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 21 19:30:16 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Sep 2012 19: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 1TF8vP-0004IQ-NT; Fri, 21 Sep 2012 19:30:07 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andres.lagarcavilla@gmail.com>) id 1TF8vO-0004IH-B0
	for xen-devel@lists.xen.org; Fri, 21 Sep 2012 19:30:06 +0000
Received: from [85.158.139.211:28016] by server-2.bemta-5.messagelabs.com id
	B1/B0-11456-D30CC505; Fri, 21 Sep 2012 19:30:05 +0000
X-Env-Sender: andres.lagarcavilla@gmail.com
X-Msg-Ref: server-12.tower-206.messagelabs.com!1348255802!18501910!1
X-Originating-IP: [209.85.223.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14777 invoked from network); 21 Sep 2012 19:30:04 -0000
Received: from mail-ie0-f173.google.com (HELO mail-ie0-f173.google.com)
	(209.85.223.173)
	by server-12.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Sep 2012 19:30:04 -0000
Received: by iea17 with SMTP id 17so2384449iea.32
	for <xen-devel@lists.xen.org>; Fri, 21 Sep 2012 12:30:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=subject:mime-version:content-type:from:in-reply-to:date:cc
	:content-transfer-encoding:message-id:references:to:x-mailer;
	bh=83QR3YY++4kQrasLiVeMTughtBu6TGkSeEXjMMZJio4=;
	b=K15a85cjZYW1SETpW61u5sWldswFrFviJUVjdZJXoFRULJY+zBur9hXUmZPvTSz+y1
	DQV5Dgv8EJOZ49ToW5XbU9LFwUFrpKP7r4fK3kYdUAqA4RNRqRVNrGQvrlod0KPPBzFA
	EyZJNy8n9ElSm/trn8esGLEWmgKLILf37mm6nkydp2uzwBlSqTFlW1r3PG1qRqIb4MYq
	uYWLJicTd8Kx8Ukrp8/3AYv+kzloT9MDgvrDsZJIzhV3oljZuBksu4yNg/7laYWbl6WK
	EDgnmJ19nJcZkeg5iy3/LzuMw71R2haidlTTBYUszMGa08ILGTIMx9SloHG2vWAyWrQI
	p/dQ==
Received: by 10.50.57.225 with SMTP id l1mr2654799igq.29.1348255802138;
	Fri, 21 Sep 2012 12:30:02 -0700 (PDT)
Received: from [192.168.7.210] ([206.223.182.18])
	by mx.google.com with ESMTPS id wg9sm2331074igb.0.2012.09.21.12.30.00
	(version=TLSv1/SSLv3 cipher=OTHER);
	Fri, 21 Sep 2012 12:30:01 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1278)
From: Andres Lagar-Cavilla <andres.lagarcavilla@gmail.com>
In-Reply-To: <20120921185258.GA4931@phenom.dumpdata.com>
Date: Fri, 21 Sep 2012 15:30:01 -0400
Message-Id: <ACFBD23A-6B32-47F3-B71A-37F4557FDE47@gmail.com>
References: <1347632819-13684-1-git-send-email-andres@lagarcavilla.org>
	<1347869865.14977.15.camel@zakaz.uk.xensource.com>
	<5B5132A4-93B2-41D0-B1A6-048810565DB5@gridcentric.ca>
	<20120921185258.GA4931@phenom.dumpdata.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
X-Mailer: Apple Mail (2.1278)
Cc: Ian Campbell <Ian.Campbell@citrix.com>,
	Andres Lagar-Cavilla <andreslc@gridcentric.ca>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	xen-devel <xen-devel@lists.xen.org>,
	David Vrabel <david.vrabel@citrix.com>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	David Miller <davem@davemloft.net>,
	Andres Lagar-Cavilla <andres@lagarcavilla.org>
Subject: Re: [Xen-devel] [PATCH] Xen backend support for paged out grant
	targets V4.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <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 Sep 21, 2012, at 2:52 PM, Konrad Rzeszutek Wilk wrote:

> On Mon, Sep 17, 2012 at 05:29:24AM -0400, Andres Lagar-Cavilla wrote:
>> On Sep 17, 2012, at 4:17 AM, Ian Campbell wrote:
>> =

>>> (I think I forgot to hit send on this on Friday, sorry. Also
>>> s/xen.lists.org/lists.xen.org in the CC line=85)
>> I'm on a roll here=85
>> =

>>> =

>>> On Fri, 2012-09-14 at 15:26 +0100, Andres Lagar-Cavilla wrote:
>>>> Since Xen-4.2, hvm domains may have portions of their memory paged out=
. When a
>>>> foreign domain (such as dom0) attempts to map these frames, the map wi=
ll
>>>> initially fail. The hypervisor returns a suitable errno, and kicks an
>>>> asynchronous page-in operation carried out by a helper. The foreign do=
main is
>>>> expected to retry the mapping operation until it eventually succeeds. =
The
>>>> foreign domain is not put to sleep because itself could be the one run=
ning the
>>>> pager assist (typical scenario for dom0).
>>>> =

>>>> This patch adds support for this mechanism for backend drivers using g=
rant
>>>> mapping and copying operations. Specifically, this covers the blkback =
and
>>>> gntdev drivers (which map foregin grants), and the netback driver (whi=
ch copies
>>> =

>>>                          foreign
>>> =

>>>> foreign grants).
>>>> =

>>>> * Add a retry method for grants that fail with GNTST_eagain (i.e. beca=
use the
>>>> target foregin frame is paged out).
>>> =

>>>         foreign
>>> =

>>>> * Insert hooks with appropriate wrappers in the aforementioned drivers.
>>>> =

>>>> The retry loop is only invoked if the grant operation status is GNTST_=
eagain.
>>>> It guarantees to leave a new status code different from GNTST_eagain. =
Any other
>>>> status code results in identical code execution as before.
>>>> =

>>>> The retry loop performs 256 attempts with increasing time intervals th=
rough a
>>>> 32 second period. It uses msleep to yield while waiting for the next r=
etry.
>>> [...]
>>>> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
>>> =

>>> Acked-by: Ian Campbell <ian.campbell@citrix.com>
>>> =

>>> Since this is more about grant tables than netback this should probably
>>> go via Konrad rather than Dave, is that OK with you Dave?
>> =

>> If that is the case hopefully Konrad can deal with the two typos? Otherw=
ise happy to re-spin the patch.
> =

> So with this patch when I launch an PVHVM guest on Xen 4.1 I get this
> in the initial domain and the guest is crashed:
> =

> [  261.927218] privcmd_fault: vma=3Dffff88002a31dce8 7f4edc095000-7f4edc1=
95000, pgoff=3Dc8, uv=3D00007f4edc15d000

With this patch? Or with the mmapbatch v2? This is a page fault in a foreig=
n-mapped VMA. Not touched by this grant backend patch we are talking about.

Does the hypervisor dump anything to its console?

At which point during xc_hvm_build do you see this? (or elsewhere in the to=
olstack?)

Thanks
Andres

> =

> guest config:
>> more /mnt/lab/latest/hvm.xm =

> kernel =3D "/usr/lib/xen/boot/hvmloader"
> builder=3D'hvm'
> memory=3D1024
> #maxmem=3D1024
> maxvcpus =3D 2
> serial=3D'pty'
> vcpus =3D 2
> disk =3D [ 'file:/mnt/lab/latest/root_image.iso,hdc:cdrom,r']
> boot=3D"dn"
> #vif =3D [ 'type=3Dioemu,model=3De1000,mac=3D00:0F:4B:00:00:71, bridge=3D=
switch' ]
> vif =3D [ 'type=3Dnetfront, bridge=3Dswitch' ]
> #vfb =3D [ 'vnc=3D1, vnclisten=3D0.0.0.0 ,vncunused=3D1']
> vnc=3D1
> vnclisten=3D"0.0.0.0"
> usb=3D1
> xen_platform_pci=3D1
> =

> =



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 21 19:36:41 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Sep 2012 19:36: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 1TF91Y-0004WN-IW; Fri, 21 Sep 2012 19:36:28 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <matthew.fioravante@jhuapl.edu>) id 1TF91X-0004WI-5x
	for xen-devel@lists.xensource.com; Fri, 21 Sep 2012 19:36:27 +0000
Received: from [85.158.143.35:29120] by server-2.bemta-4.messagelabs.com id
	AD/F1-06610-AB1CC505; Fri, 21 Sep 2012 19:36:26 +0000
X-Env-Sender: matthew.fioravante@jhuapl.edu
X-Msg-Ref: server-13.tower-21.messagelabs.com!1348256182!17977433!1
X-Originating-IP: [128.244.251.36]
X-SpamReason: No, hits=0.9 required=7.0 tests=HTML_10_20,HTML_MESSAGE,
	UNPARSEABLE_RELAY
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9076 invoked from network); 21 Sep 2012 19:36:24 -0000
Received: from pilot.jhuapl.edu (HELO jhuapl.edu) (128.244.251.36)
	by server-13.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 21 Sep 2012 19:36:24 -0000
Received: from ([128.244.207.89])
	by pilot.jhuapl.edu with ESMTP with TLS id 63GHCH1.153411681;
	Fri, 21 Sep 2012 15:36:17 -0400
Message-ID: <505CC165.4070008@jhuapl.edu>
Date: Fri, 21 Sep 2012 15:35:01 -0400
From: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120827 Thunderbird/15.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>, 
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
X-Enigmail-Version: 1.4.4
Subject: [Xen-devel] PATCH [base vtpm and libxl patches 5/6] make devid a
 libxl 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: multipart/mixed; boundary="===============6884317037923313743=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a cryptographically signed message in MIME format.

--===============6884317037923313743==
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms080401000809080303050808"

This is a cryptographically signed message in MIME format.

--------------ms080401000809080303050808
Content-Type: multipart/alternative;
 boundary="------------020203040005020104040406"

This is a multi-part message in MIME format.
--------------020203040005020104040406
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

This fixes a bug in libxl where device ids are not initialized properly.
The devid field for each device is set to be an integer type which are
always initialized to 0.

This makes the xl DEV-attach commands always fail to add more than one
device, because each time the device id is initialized to 0, when it
should be initialized to -1, which in the code will trigger a search for
free id.

Signed off by Matthew Fioravante matthew.fioravante@jhuapl.edu

---
* Rebased off of latest xen-unstable
* Fixed whitespace errors
* Copy and paste error in email title

diff --git a/tools/libxl/gentest.py b/tools/libxl/gentest.py
--- a/tools/libxl/gentest.py
+++ b/tools/libxl/gentest.py
@@ -60,7 +60,7 @@ def gen_rand_init(ty, v, indent =3D "    ", parent =3D =
None):
                                         passby=3Didl.PASS_BY_REFERENCE))=

     elif ty.typename in ["libxl_uuid", "libxl_mac", "libxl_hwcap"]:
         s +=3D "rand_bytes((uint8_t *)%s, sizeof(*%s));\n" % (v,v)
-    elif ty.typename in ["libxl_domid"] or isinstance(ty, idl.Number):
+    elif ty.typename in ["libxl_domid", "libxl_devid"] or isinstance(ty,=
 idl.Number):
         s +=3D "%s =3D rand() %% (sizeof(%s)*8);\n" % \
              (ty.pass_arg(v, parent is None),
               ty.pass_arg(v, parent is None))
diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -307,6 +307,7 @@ void libxl_cpuid_dispose(libxl_cpuid_policy_list *cpu=
id_list);
 #define LIBXL_PCI_FUNC_ALL (~0U)
=20
 typedef uint32_t libxl_domid;
+typedef int libxl_devid;
=20
 /*
  * Formatting Enumerations.
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
@@ -8,6 +8,7 @@ namespace("libxl_")
 libxl_defbool =3D Builtin("defbool", passby=3DPASS_BY_REFERENCE)
=20
 libxl_domid =3D Builtin("domid", json_fn =3D "yajl_gen_integer", autogen=
erate_json =3D False)
+libxl_devid =3D Builtin("devid", json_fn =3D "yajl_gen_integer", autogen=
erate_json =3D False, signed =3D True, init_val=3D"-1")
 libxl_uuid =3D Builtin("uuid", passby=3DPASS_BY_REFERENCE)
 libxl_mac =3D Builtin("mac", passby=3DPASS_BY_REFERENCE)
 libxl_bitmap =3D Builtin("bitmap", dispose_fn=3D"libxl_bitmap_dispose", =
passby=3DPASS_BY_REFERENCE)
@@ -343,7 +344,7 @@ libxl_domain_build_info =3D Struct("domain_build_info=
",[
=20
 libxl_device_vfb =3D Struct("device_vfb", [
     ("backend_domid", libxl_domid),
-    ("devid",         integer),
+    ("devid",         libxl_devid),
     ("vnc",           libxl_vnc_info),
     ("sdl",           libxl_sdl_info),
     # set keyboard layout, default is en-us keyboard
@@ -352,7 +353,7 @@ libxl_device_vfb =3D Struct("device_vfb", [
=20
 libxl_device_vkb =3D Struct("device_vkb", [
     ("backend_domid", libxl_domid),
-    ("devid", integer),
+    ("devid", libxl_devid),
     ])
=20
 libxl_device_disk =3D Struct("device_disk", [
@@ -369,7 +370,7 @@ libxl_device_disk =3D Struct("device_disk", [
=20
 libxl_device_nic =3D Struct("device_nic", [
     ("backend_domid", libxl_domid),
-    ("devid", integer),
+    ("devid", libxl_devid),
     ("mtu", integer),
     ("model", string),
     ("mac", libxl_mac),
@@ -399,7 +400,7 @@ libxl_diskinfo =3D Struct("diskinfo", [
     ("backend_id", uint32),
     ("frontend", string),
     ("frontend_id", uint32),
-    ("devid", integer),
+    ("devid", libxl_devid),
     ("state", integer),
     ("evtch", integer),
     ("rref", integer),
@@ -410,7 +411,7 @@ libxl_nicinfo =3D Struct("nicinfo", [
     ("backend_id", uint32),
     ("frontend", string),
     ("frontend_id", uint32),
-    ("devid", integer),
+    ("devid", libxl_devid),
     ("state", integer),
     ("evtch", integer),
     ("rref_tx", integer),
diff --git a/tools/ocaml/libs/xc/xenctrl.ml b/tools/ocaml/libs/xc/xenctrl=
=2Eml
--- a/tools/ocaml/libs/xc/xenctrl.ml
+++ b/tools/ocaml/libs/xc/xenctrl.ml
@@ -16,6 +16,7 @@
=20
 (** *)
 type domid =3D int
+type devid =3D int
=20
 (* ** xenctrl.h ** *)
=20
diff --git a/tools/ocaml/libs/xc/xenctrl.mli b/tools/ocaml/libs/xc/xenctr=
l.mli
--- a/tools/ocaml/libs/xc/xenctrl.mli
+++ b/tools/ocaml/libs/xc/xenctrl.mli
@@ -15,6 +15,7 @@
  *)
=20
 type domid =3D int
+type devid =3D int
 type vcpuinfo =3D {
   online : bool;
   blocked : bool;
diff --git a/tools/ocaml/libs/xl/genwrap.py b/tools/ocaml/libs/xl/genwrap=
=2Epy
--- a/tools/ocaml/libs/xl/genwrap.py
+++ b/tools/ocaml/libs/xl/genwrap.py
@@ -10,6 +10,7 @@ builtins =3D {
     "int":                  ("int",                    "%(c)s =3D Int_va=
l(%(o)s)",            "Val_int(%(c)s)"  ),
     "char *":               ("string",                 "%(c)s =3D dup_St=
ring_val(gc, %(o)s)", "caml_copy_string(%(c)s)"),
     "libxl_domid":          ("domid",                  "%(c)s =3D Int_va=
l(%(o)s)",            "Val_int(%(c)s)"  ),
+    "libxl_devid":          ("devid",                  "%(c)s =3D Int_va=
l(%(o)s)",            "Val_int(%(c)s)"  ),
     "libxl_defbool":        ("bool option",            "%(c)s =3D Defboo=
l_val(%(o)s)",        "Val_defbool(%(c)s)" ),
     "libxl_uuid":           ("int array",              "Uuid_val(gc, lg,=
 &%(c)s, %(o)s)",   "Val_uuid(&%(c)s)"),
     "libxl_key_value_list": ("(string * string) list", None,            =
                    None),
@@ -41,8 +42,8 @@ def stub_fn_name(ty, name):
     return "stub_xl_%s_%s" % (ty.rawname,name)
    =20
 def ocaml_type_of(ty):
-    if ty.rawname =3D=3D "domid":
-        return "domid"
+    if ty.rawname in ["domid","devid"]:
+        return ty.rawname
     elif isinstance(ty,idl.UInt):
         if ty.width in [8, 16]:
             # handle as ints
diff --git a/tools/ocaml/libs/xl/xenlight.ml.in b/tools/ocaml/libs/xl/xen=
light.ml.in
--- a/tools/ocaml/libs/xl/xenlight.ml.in
+++ b/tools/ocaml/libs/xl/xenlight.ml.in
@@ -16,6 +16,7 @@
 exception Error of string
=20
 type domid =3D int
+type devid =3D int
=20
 (* @@LIBXL_TYPES@@ *)
=20
diff --git a/tools/ocaml/libs/xl/xenlight.mli.in b/tools/ocaml/libs/xl/xe=
nlight.mli.in
--- a/tools/ocaml/libs/xl/xenlight.mli.in
+++ b/tools/ocaml/libs/xl/xenlight.mli.in
@@ -16,6 +16,7 @@
 exception Error of string
=20
 type domid =3D int
+type devid =3D int
=20
 (* @@LIBXL_TYPES@@ *)
=20
diff --git a/tools/ocaml/libs/xs/xs.ml b/tools/ocaml/libs/xs/xs.ml
--- a/tools/ocaml/libs/xs/xs.ml
+++ b/tools/ocaml/libs/xs/xs.ml
@@ -17,6 +17,7 @@
 type perms =3D Xsraw.perms
 type con =3D Xsraw.con
 type domid =3D int
+type devid =3D int
=20
 type xsh =3D
 {
diff --git a/tools/ocaml/libs/xs/xs.mli b/tools/ocaml/libs/xs/xs.mli
--- a/tools/ocaml/libs/xs/xs.mli
+++ b/tools/ocaml/libs/xs/xs.mli
@@ -27,6 +27,7 @@ exception Failed_to_connect
 type perms =3D Xsraw.perms
=20
 type domid =3D int
+type devid =3D int
 type con
=20
 type xsh =3D {
diff --git a/tools/python/xen/lowlevel/xl/xl.c b/tools/python/xen/lowleve=
l/xl/xl.c
--- a/tools/python/xen/lowlevel/xl/xl.c
+++ b/tools/python/xen/lowlevel/xl/xl.c
@@ -281,6 +281,11 @@ int attrib__libxl_domid_set(PyObject *v, libxl_domid=
 *domid) {
     return 0;
 }
=20
+int attrib__libxl_devid_set(PyObject *v, libxl_devid *devid) {
+   *devid =3D PyInt_AsLong(v);
+   return 0;
+}
+
 int attrib__struct_in_addr_set(PyObject *v, struct in_addr *pptr)
 {
     PyErr_SetString(PyExc_NotImplementedError, "Setting in_addr");
@@ -342,6 +347,10 @@ PyObject *attrib__libxl_domid_get(libxl_domid *domid=
) {
     return PyInt_FromLong(*domid);
 }
=20
+PyObject *attrib__libxl_devid_get(libxl_devid *devid) {
+    return PyInt_FromLong(*devid);
+}
+
 PyObject *attrib__struct_in_addr_get(struct in_addr *pptr)
 {
     PyErr_SetString(PyExc_NotImplementedError, "Getting in_addr");



--------------020203040005020104040406
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<html>
  <head>

    <meta http-equiv=3D"content-type" content=3D"text/html; charset=3DISO=
-8859-1">
  </head>
  <body bgcolor=3D"#FFFFFF" text=3D"#000000">
    <div class=3D"moz-text-plain" wrap=3D"true" graphical-quote=3D"true"
      style=3D"font-family: -moz-fixed; font-size: 12px;" lang=3D"x-weste=
rn">
      <pre wrap=3D"">This fixes a bug in libxl where device ids are not i=
nitialized properly.
The devid field for each device is set to be an integer type which are
always initialized to 0.

This makes the xl DEV-attach commands always fail to add more than one
device, because each time the device id is initialized to 0, when it
should be initialized to -1, which in the code will trigger a search for
free id.

Signed off by Matthew Fioravante <a class=3D"moz-txt-link-abbreviated" hr=
ef=3D"mailto:matthew.fioravante@jhuapl.edu">matthew.fioravante@jhuapl.edu=
</a>

---
* Rebased off of latest xen-unstable
* Fixed whitespace errors
* Copy and paste error in email title

diff --git a/tools/libxl/gentest.py b/tools/libxl/gentest.py
--- a/tools/libxl/gentest.py
+++ b/tools/libxl/gentest.py
@@ -60,7 +60,7 @@ def gen_rand_init(ty, v, indent =3D "    ", parent =3D =
None):
                                         passby=3Didl.PASS_BY_REFERENCE))=

     elif ty.typename in ["libxl_uuid", "libxl_mac", "libxl_hwcap"]:
         s +=3D "rand_bytes((uint8_t *)%s, sizeof(*%s));\n" % (v,v)
-    elif ty.typename in ["libxl_domid"] or isinstance(ty, idl.Number):
+    elif ty.typename in ["libxl_domid", "libxl_devid"] or isinstance(ty,=
 idl.Number):
         s +=3D "%s =3D rand() %% (sizeof(%s)*8);\n" % \
              (ty.pass_arg(v, parent is None),
               ty.pass_arg(v, parent is None))
diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -307,6 +307,7 @@ void libxl_cpuid_dispose(libxl_cpuid_policy_list *cpu=
id_list);
 #define LIBXL_PCI_FUNC_ALL (~0U)
=20
 typedef uint32_t libxl_domid;
+typedef int libxl_devid;
=20
 /*
  * Formatting Enumerations.
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
@@ -8,6 +8,7 @@ namespace("libxl_")
 libxl_defbool =3D Builtin("defbool", passby=3DPASS_BY_REFERENCE)
=20
 libxl_domid =3D Builtin("domid", json_fn =3D "yajl_gen_integer", autogen=
erate_json =3D False)
+libxl_devid =3D Builtin("devid", json_fn =3D "yajl_gen_integer", autogen=
erate_json =3D False, signed =3D True, init_val=3D"-1")
 libxl_uuid =3D Builtin("uuid", passby=3DPASS_BY_REFERENCE)
 libxl_mac =3D Builtin("mac", passby=3DPASS_BY_REFERENCE)
 libxl_bitmap =3D Builtin("bitmap", dispose_fn=3D"libxl_bitmap_dispose", =
passby=3DPASS_BY_REFERENCE)
@@ -343,7 +344,7 @@ libxl_domain_build_info =3D Struct("domain_build_info=
",[
=20
 libxl_device_vfb =3D Struct("device_vfb", [
     ("backend_domid", libxl_domid),
-    ("devid",         integer),
+    ("devid",         libxl_devid),
     ("vnc",           libxl_vnc_info),
     ("sdl",           libxl_sdl_info),
     # set keyboard layout, default is en-us keyboard
@@ -352,7 +353,7 @@ libxl_device_vfb =3D Struct("device_vfb", [
=20
 libxl_device_vkb =3D Struct("device_vkb", [
     ("backend_domid", libxl_domid),
-    ("devid", integer),
+    ("devid", libxl_devid),
     ])
=20
 libxl_device_disk =3D Struct("device_disk", [
@@ -369,7 +370,7 @@ libxl_device_disk =3D Struct("device_disk", [
=20
 libxl_device_nic =3D Struct("device_nic", [
     ("backend_domid", libxl_domid),
-    ("devid", integer),
+    ("devid", libxl_devid),
     ("mtu", integer),
     ("model", string),
     ("mac", libxl_mac),
@@ -399,7 +400,7 @@ libxl_diskinfo =3D Struct("diskinfo", [
     ("backend_id", uint32),
     ("frontend", string),
     ("frontend_id", uint32),
-    ("devid", integer),
+    ("devid", libxl_devid),
     ("state", integer),
     ("evtch", integer),
     ("rref", integer),
@@ -410,7 +411,7 @@ libxl_nicinfo =3D Struct("nicinfo", [
     ("backend_id", uint32),
     ("frontend", string),
     ("frontend_id", uint32),
-    ("devid", integer),
+    ("devid", libxl_devid),
     ("state", integer),
     ("evtch", integer),
     ("rref_tx", integer),
diff --git a/tools/ocaml/libs/xc/xenctrl.ml b/tools/ocaml/libs/xc/xenctrl=
=2Eml
--- a/tools/ocaml/libs/xc/xenctrl.ml
+++ b/tools/ocaml/libs/xc/xenctrl.ml
@@ -16,6 +16,7 @@
=20
 (** *)
 type domid =3D int
+type devid =3D int
=20
 (* ** xenctrl.h ** *)
=20
diff --git a/tools/ocaml/libs/xc/xenctrl.mli b/tools/ocaml/libs/xc/xenctr=
l.mli
--- a/tools/ocaml/libs/xc/xenctrl.mli
+++ b/tools/ocaml/libs/xc/xenctrl.mli
@@ -15,6 +15,7 @@
  *)
=20
 type domid =3D int
+type devid =3D int
 type vcpuinfo =3D {
   online : bool;
   blocked : bool;
diff --git a/tools/ocaml/libs/xl/genwrap.py b/tools/ocaml/libs/xl/genwrap=
=2Epy
--- a/tools/ocaml/libs/xl/genwrap.py
+++ b/tools/ocaml/libs/xl/genwrap.py
@@ -10,6 +10,7 @@ builtins =3D {
     "int":                  ("int",                    "%(c)s =3D Int_va=
l(%(o)s)",            "Val_int(%(c)s)"  ),
     "char *":               ("string",                 "%(c)s =3D dup_St=
ring_val(gc, %(o)s)", "caml_copy_string(%(c)s)"),
     "libxl_domid":          ("domid",                  "%(c)s =3D Int_va=
l(%(o)s)",            "Val_int(%(c)s)"  ),
+    "libxl_devid":          ("devid",                  "%(c)s =3D Int_va=
l(%(o)s)",            "Val_int(%(c)s)"  ),
     "libxl_defbool":        ("bool option",            "%(c)s =3D Defboo=
l_val(%(o)s)",        "Val_defbool(%(c)s)" ),
     "libxl_uuid":           ("int array",              "Uuid_val(gc, lg,=
 &amp;%(c)s, %(o)s)",   "Val_uuid(&amp;%(c)s)"),
     "libxl_key_value_list": ("(string * string) list", None,            =
                    None),
@@ -41,8 +42,8 @@ def stub_fn_name(ty, name):
     return "stub_xl_%s_%s" % (ty.rawname,name)
    =20
 def ocaml_type_of(ty):
-    if ty.rawname =3D=3D "domid":
-        return "domid"
+    if ty.rawname in ["domid","devid"]:
+        return ty.rawname
     elif isinstance(ty,idl.UInt):
         if ty.width in [8, 16]:
             # handle as ints
diff --git a/tools/ocaml/libs/xl/xenlight.ml.in b/tools/ocaml/libs/xl/xen=
light.ml.in
--- a/tools/ocaml/libs/xl/xenlight.ml.in
+++ b/tools/ocaml/libs/xl/xenlight.ml.in
@@ -16,6 +16,7 @@
 exception Error of string
=20
 type domid =3D int
+type devid =3D int
=20
 (* @@LIBXL_TYPES@@ *)
=20
diff --git a/tools/ocaml/libs/xl/xenlight.mli.in b/tools/ocaml/libs/xl/xe=
nlight.mli.in
--- a/tools/ocaml/libs/xl/xenlight.mli.in
+++ b/tools/ocaml/libs/xl/xenlight.mli.in
@@ -16,6 +16,7 @@
 exception Error of string
=20
 type domid =3D int
+type devid =3D int
=20
 (* @@LIBXL_TYPES@@ *)
=20
diff --git a/tools/ocaml/libs/xs/xs.ml b/tools/ocaml/libs/xs/xs.ml
--- a/tools/ocaml/libs/xs/xs.ml
+++ b/tools/ocaml/libs/xs/xs.ml
@@ -17,6 +17,7 @@
 type perms =3D Xsraw.perms
 type con =3D Xsraw.con
 type domid =3D int
+type devid =3D int
=20
 type xsh =3D
 {
diff --git a/tools/ocaml/libs/xs/xs.mli b/tools/ocaml/libs/xs/xs.mli
--- a/tools/ocaml/libs/xs/xs.mli
+++ b/tools/ocaml/libs/xs/xs.mli
@@ -27,6 +27,7 @@ exception Failed_to_connect
 type perms =3D Xsraw.perms
=20
 type domid =3D int
+type devid =3D int
 type con
=20
 type xsh =3D {
diff --git a/tools/python/xen/lowlevel/xl/xl.c b/tools/python/xen/lowleve=
l/xl/xl.c
--- a/tools/python/xen/lowlevel/xl/xl.c
+++ b/tools/python/xen/lowlevel/xl/xl.c
@@ -281,6 +281,11 @@ int attrib__libxl_domid_set(PyObject *v, libxl_domid=
 *domid) {
     return 0;
 }
=20
+int attrib__libxl_devid_set(PyObject *v, libxl_devid *devid) {
+   *devid =3D PyInt_AsLong(v);
+   return 0;
+}
+
 int attrib__struct_in_addr_set(PyObject *v, struct in_addr *pptr)
 {
     PyErr_SetString(PyExc_NotImplementedError, "Setting in_addr");
@@ -342,6 +347,10 @@ PyObject *attrib__libxl_domid_get(libxl_domid *domid=
) {
     return PyInt_FromLong(*domid);
 }
=20
+PyObject *attrib__libxl_devid_get(libxl_devid *devid) {
+    return PyInt_FromLong(*devid);
+}
+
 PyObject *attrib__struct_in_addr_get(struct in_addr *pptr)
 {
     PyErr_SetString(PyExc_NotImplementedError, "Getting in_addr");


</pre>
    </div>
  </body>
</html>

--------------020203040005020104040406--

--------------ms080401000809080303050808
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIDyjCC
A8YwggMvoAMCAQICBD/xyf0wDQYJKoZIhvcNAQEFBQAwLzELMAkGA1UEBhMCVVMxDzANBgNV
BAoTBkpIVUFQTDEPMA0GA1UECxMGQklTRENBMB4XDTEwMDYxMTE4MjIwNloXDTEzMDYxMTE4
NTIwNlowZjELMAkGA1UEBhMCVVMxDzANBgNVBAoTBkpIVUFQTDEPMA0GA1UECxMGUGVvcGxl
MTUwFgYDVQQLEw9WUE5Hcm91cC1CSVNEQ0EwGwYDVQQDExRNYXR0aGV3IEUgRmlvcmF2YW50
ZTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAnpbwVSP6o1Nb5lcW7dd3yTo9iBJdi7qz
4nANOMFPK7JOy5npKN1iiousl28U/scUJES55gPwAWYJK3uVyQAsA4adgDKi5DoD1UHDQEwp
bY7iHLJeq0NPr4BqYNqnCFPbE6HC8zSJrr4qKn+gVUQT39SIFqdiIPJwZL8FYTRQ/zsCAwEA
AaOCAbYwggGyMAsGA1UdDwQEAwIHgDArBgNVHRAEJDAigA8yMDEwMDYxMTE4MjIwNlqBDzIw
MTIwNzE3MjI1MjA2WjAbBg0rBgEEAbMlCwMBAQEBBAoWCGZpb3JhbWUxMBsGDSsGAQQBsyUL
AwEBAQIEChIIMDAxMDQyNjEwWAYJYIZIAYb6ax4BBEsMSVRoZSBwcml2YXRlIGtleSBjb3Jy
ZXNwb25kaW5nIHRvIHRoaXMgY2VydGlmaWNhdGUgbWF5IGhhdmUgYmVlbiBleHBvcnRlZC4w
KAYDVR0RBCEwH4EdTWF0dGhldy5GaW9yYXZhbnRlQGpodWFwbC5lZHUwUgYDVR0fBEswSTBH
oEWgQ6RBMD8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJU0RD
QTEOMAwGA1UEAxMFQ1JMNTYwHwYDVR0jBBgwFoAUCDUpmxH52EU2CyWmF2EJMB1yqeswHQYD
VR0OBBYEFO6LYxg6r9wHZ+zdQtBHn1dZ/YTNMAkGA1UdEwQCMAAwGQYJKoZIhvZ9B0EABAww
ChsEVjcuMQMCBLAwDQYJKoZIhvcNAQEFBQADgYEAJO9HQh4YNChVLzuZqK5ARJARD8JoujGZ
fdo75quvg2jXFQe2sEjvLnxJZgm/pv8fdZakq48CWwjYHKuvIp7sDjTEsQfo+y7SpN/N2NvJ
WU5SqfK1VgYtNLRRoGJUB5Q1aZ+Dg95g3kqpyfpUMISJL8IKVLtJVfN4fggFVUYZ9wwxggGr
MIIBpwIBATA3MC8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJ
U0RDQQIEP/HJ/TAJBgUrDgMCGgUAoIHLMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ
KoZIhvcNAQkFMQ8XDTEyMDkyMTE5MzUwMVowIwYJKoZIhvcNAQkEMRYEFIBoTADupeFhA0kC
/GbXfopLt2H3MGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAK
BggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI
KoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEgYBQHshhD94s0Pua39xgDZbux81pIYNbC9kF
eMkP43T8unkqXFgQQ3tZrjMVSbu0lKCVUrv+HaBUTotmd7oT9TWiWHa94+sVsq+Jge1YP+jI
vq/yvAYjnfA7qqaa23aqAlyBMf1kB5GuB6Hipekt7JA9JvNxtwopWBLbGCPmzLC90AAAAAAA
AA==
--------------ms080401000809080303050808--


--===============6884317037923313743==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============6884317037923313743==--


From xen-devel-bounces@lists.xen.org Fri Sep 21 19:36:41 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Sep 2012 19:36: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 1TF91Y-0004WN-IW; Fri, 21 Sep 2012 19:36:28 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <matthew.fioravante@jhuapl.edu>) id 1TF91X-0004WI-5x
	for xen-devel@lists.xensource.com; Fri, 21 Sep 2012 19:36:27 +0000
Received: from [85.158.143.35:29120] by server-2.bemta-4.messagelabs.com id
	AD/F1-06610-AB1CC505; Fri, 21 Sep 2012 19:36:26 +0000
X-Env-Sender: matthew.fioravante@jhuapl.edu
X-Msg-Ref: server-13.tower-21.messagelabs.com!1348256182!17977433!1
X-Originating-IP: [128.244.251.36]
X-SpamReason: No, hits=0.9 required=7.0 tests=HTML_10_20,HTML_MESSAGE,
	UNPARSEABLE_RELAY
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9076 invoked from network); 21 Sep 2012 19:36:24 -0000
Received: from pilot.jhuapl.edu (HELO jhuapl.edu) (128.244.251.36)
	by server-13.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 21 Sep 2012 19:36:24 -0000
Received: from ([128.244.207.89])
	by pilot.jhuapl.edu with ESMTP with TLS id 63GHCH1.153411681;
	Fri, 21 Sep 2012 15:36:17 -0400
Message-ID: <505CC165.4070008@jhuapl.edu>
Date: Fri, 21 Sep 2012 15:35:01 -0400
From: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120827 Thunderbird/15.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>, 
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
X-Enigmail-Version: 1.4.4
Subject: [Xen-devel] PATCH [base vtpm and libxl patches 5/6] make devid a
 libxl 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: multipart/mixed; boundary="===============6884317037923313743=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a cryptographically signed message in MIME format.

--===============6884317037923313743==
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms080401000809080303050808"

This is a cryptographically signed message in MIME format.

--------------ms080401000809080303050808
Content-Type: multipart/alternative;
 boundary="------------020203040005020104040406"

This is a multi-part message in MIME format.
--------------020203040005020104040406
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

This fixes a bug in libxl where device ids are not initialized properly.
The devid field for each device is set to be an integer type which are
always initialized to 0.

This makes the xl DEV-attach commands always fail to add more than one
device, because each time the device id is initialized to 0, when it
should be initialized to -1, which in the code will trigger a search for
free id.

Signed off by Matthew Fioravante matthew.fioravante@jhuapl.edu

---
* Rebased off of latest xen-unstable
* Fixed whitespace errors
* Copy and paste error in email title

diff --git a/tools/libxl/gentest.py b/tools/libxl/gentest.py
--- a/tools/libxl/gentest.py
+++ b/tools/libxl/gentest.py
@@ -60,7 +60,7 @@ def gen_rand_init(ty, v, indent =3D "    ", parent =3D =
None):
                                         passby=3Didl.PASS_BY_REFERENCE))=

     elif ty.typename in ["libxl_uuid", "libxl_mac", "libxl_hwcap"]:
         s +=3D "rand_bytes((uint8_t *)%s, sizeof(*%s));\n" % (v,v)
-    elif ty.typename in ["libxl_domid"] or isinstance(ty, idl.Number):
+    elif ty.typename in ["libxl_domid", "libxl_devid"] or isinstance(ty,=
 idl.Number):
         s +=3D "%s =3D rand() %% (sizeof(%s)*8);\n" % \
              (ty.pass_arg(v, parent is None),
               ty.pass_arg(v, parent is None))
diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -307,6 +307,7 @@ void libxl_cpuid_dispose(libxl_cpuid_policy_list *cpu=
id_list);
 #define LIBXL_PCI_FUNC_ALL (~0U)
=20
 typedef uint32_t libxl_domid;
+typedef int libxl_devid;
=20
 /*
  * Formatting Enumerations.
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
@@ -8,6 +8,7 @@ namespace("libxl_")
 libxl_defbool =3D Builtin("defbool", passby=3DPASS_BY_REFERENCE)
=20
 libxl_domid =3D Builtin("domid", json_fn =3D "yajl_gen_integer", autogen=
erate_json =3D False)
+libxl_devid =3D Builtin("devid", json_fn =3D "yajl_gen_integer", autogen=
erate_json =3D False, signed =3D True, init_val=3D"-1")
 libxl_uuid =3D Builtin("uuid", passby=3DPASS_BY_REFERENCE)
 libxl_mac =3D Builtin("mac", passby=3DPASS_BY_REFERENCE)
 libxl_bitmap =3D Builtin("bitmap", dispose_fn=3D"libxl_bitmap_dispose", =
passby=3DPASS_BY_REFERENCE)
@@ -343,7 +344,7 @@ libxl_domain_build_info =3D Struct("domain_build_info=
",[
=20
 libxl_device_vfb =3D Struct("device_vfb", [
     ("backend_domid", libxl_domid),
-    ("devid",         integer),
+    ("devid",         libxl_devid),
     ("vnc",           libxl_vnc_info),
     ("sdl",           libxl_sdl_info),
     # set keyboard layout, default is en-us keyboard
@@ -352,7 +353,7 @@ libxl_device_vfb =3D Struct("device_vfb", [
=20
 libxl_device_vkb =3D Struct("device_vkb", [
     ("backend_domid", libxl_domid),
-    ("devid", integer),
+    ("devid", libxl_devid),
     ])
=20
 libxl_device_disk =3D Struct("device_disk", [
@@ -369,7 +370,7 @@ libxl_device_disk =3D Struct("device_disk", [
=20
 libxl_device_nic =3D Struct("device_nic", [
     ("backend_domid", libxl_domid),
-    ("devid", integer),
+    ("devid", libxl_devid),
     ("mtu", integer),
     ("model", string),
     ("mac", libxl_mac),
@@ -399,7 +400,7 @@ libxl_diskinfo =3D Struct("diskinfo", [
     ("backend_id", uint32),
     ("frontend", string),
     ("frontend_id", uint32),
-    ("devid", integer),
+    ("devid", libxl_devid),
     ("state", integer),
     ("evtch", integer),
     ("rref", integer),
@@ -410,7 +411,7 @@ libxl_nicinfo =3D Struct("nicinfo", [
     ("backend_id", uint32),
     ("frontend", string),
     ("frontend_id", uint32),
-    ("devid", integer),
+    ("devid", libxl_devid),
     ("state", integer),
     ("evtch", integer),
     ("rref_tx", integer),
diff --git a/tools/ocaml/libs/xc/xenctrl.ml b/tools/ocaml/libs/xc/xenctrl=
=2Eml
--- a/tools/ocaml/libs/xc/xenctrl.ml
+++ b/tools/ocaml/libs/xc/xenctrl.ml
@@ -16,6 +16,7 @@
=20
 (** *)
 type domid =3D int
+type devid =3D int
=20
 (* ** xenctrl.h ** *)
=20
diff --git a/tools/ocaml/libs/xc/xenctrl.mli b/tools/ocaml/libs/xc/xenctr=
l.mli
--- a/tools/ocaml/libs/xc/xenctrl.mli
+++ b/tools/ocaml/libs/xc/xenctrl.mli
@@ -15,6 +15,7 @@
  *)
=20
 type domid =3D int
+type devid =3D int
 type vcpuinfo =3D {
   online : bool;
   blocked : bool;
diff --git a/tools/ocaml/libs/xl/genwrap.py b/tools/ocaml/libs/xl/genwrap=
=2Epy
--- a/tools/ocaml/libs/xl/genwrap.py
+++ b/tools/ocaml/libs/xl/genwrap.py
@@ -10,6 +10,7 @@ builtins =3D {
     "int":                  ("int",                    "%(c)s =3D Int_va=
l(%(o)s)",            "Val_int(%(c)s)"  ),
     "char *":               ("string",                 "%(c)s =3D dup_St=
ring_val(gc, %(o)s)", "caml_copy_string(%(c)s)"),
     "libxl_domid":          ("domid",                  "%(c)s =3D Int_va=
l(%(o)s)",            "Val_int(%(c)s)"  ),
+    "libxl_devid":          ("devid",                  "%(c)s =3D Int_va=
l(%(o)s)",            "Val_int(%(c)s)"  ),
     "libxl_defbool":        ("bool option",            "%(c)s =3D Defboo=
l_val(%(o)s)",        "Val_defbool(%(c)s)" ),
     "libxl_uuid":           ("int array",              "Uuid_val(gc, lg,=
 &%(c)s, %(o)s)",   "Val_uuid(&%(c)s)"),
     "libxl_key_value_list": ("(string * string) list", None,            =
                    None),
@@ -41,8 +42,8 @@ def stub_fn_name(ty, name):
     return "stub_xl_%s_%s" % (ty.rawname,name)
    =20
 def ocaml_type_of(ty):
-    if ty.rawname =3D=3D "domid":
-        return "domid"
+    if ty.rawname in ["domid","devid"]:
+        return ty.rawname
     elif isinstance(ty,idl.UInt):
         if ty.width in [8, 16]:
             # handle as ints
diff --git a/tools/ocaml/libs/xl/xenlight.ml.in b/tools/ocaml/libs/xl/xen=
light.ml.in
--- a/tools/ocaml/libs/xl/xenlight.ml.in
+++ b/tools/ocaml/libs/xl/xenlight.ml.in
@@ -16,6 +16,7 @@
 exception Error of string
=20
 type domid =3D int
+type devid =3D int
=20
 (* @@LIBXL_TYPES@@ *)
=20
diff --git a/tools/ocaml/libs/xl/xenlight.mli.in b/tools/ocaml/libs/xl/xe=
nlight.mli.in
--- a/tools/ocaml/libs/xl/xenlight.mli.in
+++ b/tools/ocaml/libs/xl/xenlight.mli.in
@@ -16,6 +16,7 @@
 exception Error of string
=20
 type domid =3D int
+type devid =3D int
=20
 (* @@LIBXL_TYPES@@ *)
=20
diff --git a/tools/ocaml/libs/xs/xs.ml b/tools/ocaml/libs/xs/xs.ml
--- a/tools/ocaml/libs/xs/xs.ml
+++ b/tools/ocaml/libs/xs/xs.ml
@@ -17,6 +17,7 @@
 type perms =3D Xsraw.perms
 type con =3D Xsraw.con
 type domid =3D int
+type devid =3D int
=20
 type xsh =3D
 {
diff --git a/tools/ocaml/libs/xs/xs.mli b/tools/ocaml/libs/xs/xs.mli
--- a/tools/ocaml/libs/xs/xs.mli
+++ b/tools/ocaml/libs/xs/xs.mli
@@ -27,6 +27,7 @@ exception Failed_to_connect
 type perms =3D Xsraw.perms
=20
 type domid =3D int
+type devid =3D int
 type con
=20
 type xsh =3D {
diff --git a/tools/python/xen/lowlevel/xl/xl.c b/tools/python/xen/lowleve=
l/xl/xl.c
--- a/tools/python/xen/lowlevel/xl/xl.c
+++ b/tools/python/xen/lowlevel/xl/xl.c
@@ -281,6 +281,11 @@ int attrib__libxl_domid_set(PyObject *v, libxl_domid=
 *domid) {
     return 0;
 }
=20
+int attrib__libxl_devid_set(PyObject *v, libxl_devid *devid) {
+   *devid =3D PyInt_AsLong(v);
+   return 0;
+}
+
 int attrib__struct_in_addr_set(PyObject *v, struct in_addr *pptr)
 {
     PyErr_SetString(PyExc_NotImplementedError, "Setting in_addr");
@@ -342,6 +347,10 @@ PyObject *attrib__libxl_domid_get(libxl_domid *domid=
) {
     return PyInt_FromLong(*domid);
 }
=20
+PyObject *attrib__libxl_devid_get(libxl_devid *devid) {
+    return PyInt_FromLong(*devid);
+}
+
 PyObject *attrib__struct_in_addr_get(struct in_addr *pptr)
 {
     PyErr_SetString(PyExc_NotImplementedError, "Getting in_addr");



--------------020203040005020104040406
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<html>
  <head>

    <meta http-equiv=3D"content-type" content=3D"text/html; charset=3DISO=
-8859-1">
  </head>
  <body bgcolor=3D"#FFFFFF" text=3D"#000000">
    <div class=3D"moz-text-plain" wrap=3D"true" graphical-quote=3D"true"
      style=3D"font-family: -moz-fixed; font-size: 12px;" lang=3D"x-weste=
rn">
      <pre wrap=3D"">This fixes a bug in libxl where device ids are not i=
nitialized properly.
The devid field for each device is set to be an integer type which are
always initialized to 0.

This makes the xl DEV-attach commands always fail to add more than one
device, because each time the device id is initialized to 0, when it
should be initialized to -1, which in the code will trigger a search for
free id.

Signed off by Matthew Fioravante <a class=3D"moz-txt-link-abbreviated" hr=
ef=3D"mailto:matthew.fioravante@jhuapl.edu">matthew.fioravante@jhuapl.edu=
</a>

---
* Rebased off of latest xen-unstable
* Fixed whitespace errors
* Copy and paste error in email title

diff --git a/tools/libxl/gentest.py b/tools/libxl/gentest.py
--- a/tools/libxl/gentest.py
+++ b/tools/libxl/gentest.py
@@ -60,7 +60,7 @@ def gen_rand_init(ty, v, indent =3D "    ", parent =3D =
None):
                                         passby=3Didl.PASS_BY_REFERENCE))=

     elif ty.typename in ["libxl_uuid", "libxl_mac", "libxl_hwcap"]:
         s +=3D "rand_bytes((uint8_t *)%s, sizeof(*%s));\n" % (v,v)
-    elif ty.typename in ["libxl_domid"] or isinstance(ty, idl.Number):
+    elif ty.typename in ["libxl_domid", "libxl_devid"] or isinstance(ty,=
 idl.Number):
         s +=3D "%s =3D rand() %% (sizeof(%s)*8);\n" % \
              (ty.pass_arg(v, parent is None),
               ty.pass_arg(v, parent is None))
diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -307,6 +307,7 @@ void libxl_cpuid_dispose(libxl_cpuid_policy_list *cpu=
id_list);
 #define LIBXL_PCI_FUNC_ALL (~0U)
=20
 typedef uint32_t libxl_domid;
+typedef int libxl_devid;
=20
 /*
  * Formatting Enumerations.
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
@@ -8,6 +8,7 @@ namespace("libxl_")
 libxl_defbool =3D Builtin("defbool", passby=3DPASS_BY_REFERENCE)
=20
 libxl_domid =3D Builtin("domid", json_fn =3D "yajl_gen_integer", autogen=
erate_json =3D False)
+libxl_devid =3D Builtin("devid", json_fn =3D "yajl_gen_integer", autogen=
erate_json =3D False, signed =3D True, init_val=3D"-1")
 libxl_uuid =3D Builtin("uuid", passby=3DPASS_BY_REFERENCE)
 libxl_mac =3D Builtin("mac", passby=3DPASS_BY_REFERENCE)
 libxl_bitmap =3D Builtin("bitmap", dispose_fn=3D"libxl_bitmap_dispose", =
passby=3DPASS_BY_REFERENCE)
@@ -343,7 +344,7 @@ libxl_domain_build_info =3D Struct("domain_build_info=
",[
=20
 libxl_device_vfb =3D Struct("device_vfb", [
     ("backend_domid", libxl_domid),
-    ("devid",         integer),
+    ("devid",         libxl_devid),
     ("vnc",           libxl_vnc_info),
     ("sdl",           libxl_sdl_info),
     # set keyboard layout, default is en-us keyboard
@@ -352,7 +353,7 @@ libxl_device_vfb =3D Struct("device_vfb", [
=20
 libxl_device_vkb =3D Struct("device_vkb", [
     ("backend_domid", libxl_domid),
-    ("devid", integer),
+    ("devid", libxl_devid),
     ])
=20
 libxl_device_disk =3D Struct("device_disk", [
@@ -369,7 +370,7 @@ libxl_device_disk =3D Struct("device_disk", [
=20
 libxl_device_nic =3D Struct("device_nic", [
     ("backend_domid", libxl_domid),
-    ("devid", integer),
+    ("devid", libxl_devid),
     ("mtu", integer),
     ("model", string),
     ("mac", libxl_mac),
@@ -399,7 +400,7 @@ libxl_diskinfo =3D Struct("diskinfo", [
     ("backend_id", uint32),
     ("frontend", string),
     ("frontend_id", uint32),
-    ("devid", integer),
+    ("devid", libxl_devid),
     ("state", integer),
     ("evtch", integer),
     ("rref", integer),
@@ -410,7 +411,7 @@ libxl_nicinfo =3D Struct("nicinfo", [
     ("backend_id", uint32),
     ("frontend", string),
     ("frontend_id", uint32),
-    ("devid", integer),
+    ("devid", libxl_devid),
     ("state", integer),
     ("evtch", integer),
     ("rref_tx", integer),
diff --git a/tools/ocaml/libs/xc/xenctrl.ml b/tools/ocaml/libs/xc/xenctrl=
=2Eml
--- a/tools/ocaml/libs/xc/xenctrl.ml
+++ b/tools/ocaml/libs/xc/xenctrl.ml
@@ -16,6 +16,7 @@
=20
 (** *)
 type domid =3D int
+type devid =3D int
=20
 (* ** xenctrl.h ** *)
=20
diff --git a/tools/ocaml/libs/xc/xenctrl.mli b/tools/ocaml/libs/xc/xenctr=
l.mli
--- a/tools/ocaml/libs/xc/xenctrl.mli
+++ b/tools/ocaml/libs/xc/xenctrl.mli
@@ -15,6 +15,7 @@
  *)
=20
 type domid =3D int
+type devid =3D int
 type vcpuinfo =3D {
   online : bool;
   blocked : bool;
diff --git a/tools/ocaml/libs/xl/genwrap.py b/tools/ocaml/libs/xl/genwrap=
=2Epy
--- a/tools/ocaml/libs/xl/genwrap.py
+++ b/tools/ocaml/libs/xl/genwrap.py
@@ -10,6 +10,7 @@ builtins =3D {
     "int":                  ("int",                    "%(c)s =3D Int_va=
l(%(o)s)",            "Val_int(%(c)s)"  ),
     "char *":               ("string",                 "%(c)s =3D dup_St=
ring_val(gc, %(o)s)", "caml_copy_string(%(c)s)"),
     "libxl_domid":          ("domid",                  "%(c)s =3D Int_va=
l(%(o)s)",            "Val_int(%(c)s)"  ),
+    "libxl_devid":          ("devid",                  "%(c)s =3D Int_va=
l(%(o)s)",            "Val_int(%(c)s)"  ),
     "libxl_defbool":        ("bool option",            "%(c)s =3D Defboo=
l_val(%(o)s)",        "Val_defbool(%(c)s)" ),
     "libxl_uuid":           ("int array",              "Uuid_val(gc, lg,=
 &amp;%(c)s, %(o)s)",   "Val_uuid(&amp;%(c)s)"),
     "libxl_key_value_list": ("(string * string) list", None,            =
                    None),
@@ -41,8 +42,8 @@ def stub_fn_name(ty, name):
     return "stub_xl_%s_%s" % (ty.rawname,name)
    =20
 def ocaml_type_of(ty):
-    if ty.rawname =3D=3D "domid":
-        return "domid"
+    if ty.rawname in ["domid","devid"]:
+        return ty.rawname
     elif isinstance(ty,idl.UInt):
         if ty.width in [8, 16]:
             # handle as ints
diff --git a/tools/ocaml/libs/xl/xenlight.ml.in b/tools/ocaml/libs/xl/xen=
light.ml.in
--- a/tools/ocaml/libs/xl/xenlight.ml.in
+++ b/tools/ocaml/libs/xl/xenlight.ml.in
@@ -16,6 +16,7 @@
 exception Error of string
=20
 type domid =3D int
+type devid =3D int
=20
 (* @@LIBXL_TYPES@@ *)
=20
diff --git a/tools/ocaml/libs/xl/xenlight.mli.in b/tools/ocaml/libs/xl/xe=
nlight.mli.in
--- a/tools/ocaml/libs/xl/xenlight.mli.in
+++ b/tools/ocaml/libs/xl/xenlight.mli.in
@@ -16,6 +16,7 @@
 exception Error of string
=20
 type domid =3D int
+type devid =3D int
=20
 (* @@LIBXL_TYPES@@ *)
=20
diff --git a/tools/ocaml/libs/xs/xs.ml b/tools/ocaml/libs/xs/xs.ml
--- a/tools/ocaml/libs/xs/xs.ml
+++ b/tools/ocaml/libs/xs/xs.ml
@@ -17,6 +17,7 @@
 type perms =3D Xsraw.perms
 type con =3D Xsraw.con
 type domid =3D int
+type devid =3D int
=20
 type xsh =3D
 {
diff --git a/tools/ocaml/libs/xs/xs.mli b/tools/ocaml/libs/xs/xs.mli
--- a/tools/ocaml/libs/xs/xs.mli
+++ b/tools/ocaml/libs/xs/xs.mli
@@ -27,6 +27,7 @@ exception Failed_to_connect
 type perms =3D Xsraw.perms
=20
 type domid =3D int
+type devid =3D int
 type con
=20
 type xsh =3D {
diff --git a/tools/python/xen/lowlevel/xl/xl.c b/tools/python/xen/lowleve=
l/xl/xl.c
--- a/tools/python/xen/lowlevel/xl/xl.c
+++ b/tools/python/xen/lowlevel/xl/xl.c
@@ -281,6 +281,11 @@ int attrib__libxl_domid_set(PyObject *v, libxl_domid=
 *domid) {
     return 0;
 }
=20
+int attrib__libxl_devid_set(PyObject *v, libxl_devid *devid) {
+   *devid =3D PyInt_AsLong(v);
+   return 0;
+}
+
 int attrib__struct_in_addr_set(PyObject *v, struct in_addr *pptr)
 {
     PyErr_SetString(PyExc_NotImplementedError, "Setting in_addr");
@@ -342,6 +347,10 @@ PyObject *attrib__libxl_domid_get(libxl_domid *domid=
) {
     return PyInt_FromLong(*domid);
 }
=20
+PyObject *attrib__libxl_devid_get(libxl_devid *devid) {
+    return PyInt_FromLong(*devid);
+}
+
 PyObject *attrib__struct_in_addr_get(struct in_addr *pptr)
 {
     PyErr_SetString(PyExc_NotImplementedError, "Getting in_addr");


</pre>
    </div>
  </body>
</html>

--------------020203040005020104040406--

--------------ms080401000809080303050808
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIDyjCC
A8YwggMvoAMCAQICBD/xyf0wDQYJKoZIhvcNAQEFBQAwLzELMAkGA1UEBhMCVVMxDzANBgNV
BAoTBkpIVUFQTDEPMA0GA1UECxMGQklTRENBMB4XDTEwMDYxMTE4MjIwNloXDTEzMDYxMTE4
NTIwNlowZjELMAkGA1UEBhMCVVMxDzANBgNVBAoTBkpIVUFQTDEPMA0GA1UECxMGUGVvcGxl
MTUwFgYDVQQLEw9WUE5Hcm91cC1CSVNEQ0EwGwYDVQQDExRNYXR0aGV3IEUgRmlvcmF2YW50
ZTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAnpbwVSP6o1Nb5lcW7dd3yTo9iBJdi7qz
4nANOMFPK7JOy5npKN1iiousl28U/scUJES55gPwAWYJK3uVyQAsA4adgDKi5DoD1UHDQEwp
bY7iHLJeq0NPr4BqYNqnCFPbE6HC8zSJrr4qKn+gVUQT39SIFqdiIPJwZL8FYTRQ/zsCAwEA
AaOCAbYwggGyMAsGA1UdDwQEAwIHgDArBgNVHRAEJDAigA8yMDEwMDYxMTE4MjIwNlqBDzIw
MTIwNzE3MjI1MjA2WjAbBg0rBgEEAbMlCwMBAQEBBAoWCGZpb3JhbWUxMBsGDSsGAQQBsyUL
AwEBAQIEChIIMDAxMDQyNjEwWAYJYIZIAYb6ax4BBEsMSVRoZSBwcml2YXRlIGtleSBjb3Jy
ZXNwb25kaW5nIHRvIHRoaXMgY2VydGlmaWNhdGUgbWF5IGhhdmUgYmVlbiBleHBvcnRlZC4w
KAYDVR0RBCEwH4EdTWF0dGhldy5GaW9yYXZhbnRlQGpodWFwbC5lZHUwUgYDVR0fBEswSTBH
oEWgQ6RBMD8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJU0RD
QTEOMAwGA1UEAxMFQ1JMNTYwHwYDVR0jBBgwFoAUCDUpmxH52EU2CyWmF2EJMB1yqeswHQYD
VR0OBBYEFO6LYxg6r9wHZ+zdQtBHn1dZ/YTNMAkGA1UdEwQCMAAwGQYJKoZIhvZ9B0EABAww
ChsEVjcuMQMCBLAwDQYJKoZIhvcNAQEFBQADgYEAJO9HQh4YNChVLzuZqK5ARJARD8JoujGZ
fdo75quvg2jXFQe2sEjvLnxJZgm/pv8fdZakq48CWwjYHKuvIp7sDjTEsQfo+y7SpN/N2NvJ
WU5SqfK1VgYtNLRRoGJUB5Q1aZ+Dg95g3kqpyfpUMISJL8IKVLtJVfN4fggFVUYZ9wwxggGr
MIIBpwIBATA3MC8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJ
U0RDQQIEP/HJ/TAJBgUrDgMCGgUAoIHLMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ
KoZIhvcNAQkFMQ8XDTEyMDkyMTE5MzUwMVowIwYJKoZIhvcNAQkEMRYEFIBoTADupeFhA0kC
/GbXfopLt2H3MGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAK
BggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI
KoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEgYBQHshhD94s0Pua39xgDZbux81pIYNbC9kF
eMkP43T8unkqXFgQQ3tZrjMVSbu0lKCVUrv+HaBUTotmd7oT9TWiWHa94+sVsq+Jge1YP+jI
vq/yvAYjnfA7qqaa23aqAlyBMf1kB5GuB6Hipekt7JA9JvNxtwopWBLbGCPmzLC90AAAAAAA
AA==
--------------ms080401000809080303050808--


--===============6884317037923313743==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============6884317037923313743==--


From xen-devel-bounces@lists.xen.org Fri Sep 21 19:37:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Sep 2012 19:37:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TF92r-0004dE-8I; Fri, 21 Sep 2012 19:37:49 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <matthew.fioravante@jhuapl.edu>) id 1TF92p-0004ct-A3
	for xen-devel@lists.xensource.com; Fri, 21 Sep 2012 19:37:47 +0000
Received: from [85.158.143.99:30026] by server-3.bemta-4.messagelabs.com id
	C2/A8-10986-A02CC505; Fri, 21 Sep 2012 19:37:46 +0000
X-Env-Sender: matthew.fioravante@jhuapl.edu
X-Msg-Ref: server-10.tower-216.messagelabs.com!1348256263!24887588!1
X-Originating-IP: [128.244.251.36]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG,
	UNPARSEABLE_RELAY
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20686 invoked from network); 21 Sep 2012 19:37:44 -0000
Received: from pilot.jhuapl.edu (HELO jhuapl.edu) (128.244.251.36)
	by server-10.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 21 Sep 2012 19:37:44 -0000
Received: from ([128.244.207.89])
	by pilot.jhuapl.edu with ESMTP with TLS id 63GHCH1.153411787;
	Fri, 21 Sep 2012 15:37:39 -0400
Message-ID: <505CC1B7.3080709@jhuapl.edu>
Date: Fri, 21 Sep 2012 15:36:23 -0400
From: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120827 Thunderbird/15.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>, 
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
X-Enigmail-Version: 1.4.4
Subject: [Xen-devel] PATCH [base vtpm and libxl patches 6/6] add vtpm
	support to libxl
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============4087893607776326327=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a cryptographically signed message in MIME format.

--===============4087893607776326327==
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms060907090204020808090605"

This is a cryptographically signed message in MIME format.

--------------ms060907090204020808090605
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Add support for vtpm=3D["VTPM_SPEC",...] to domain config files. Also add=

commands vtpm-attach, vtpm-list, and vtpm-detach.

Signed off by Matthew Fioravante matthew.fioravante@jhuapl.edu

---
Changes since previous:
* Rebased to latest xen
* Updated xl.cfg and xl manpages

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
@@ -298,6 +298,35 @@ Specifies the networking provision (both emulated ne=
twork adapters,
 and Xen virtual interfaces) to provided to the guest.  See
 F<docs/misc/xl-network-configuration.markdown>.
=20
+=3Ditem B<vtpm=3D[ "VTPM_SPEC_STRING", "VTPM_SPEC_STRING", ...]>
+
+Specifies the virtual trusted platform module to be
+provided to the guest. Please see F<docs/misc/vtpm.txt>
+for more details.
+
+Each B<VTPM_SPEC_STRING> is a comma-separated list of C<KEY=3DVALUE>
+settings, from the following list:
+
+=3Dover 4
+
+=3Ditem C<backend=3DDOMAIN>
+
+Specify the backend domain name of id. This value must be
+set if you are using the vtpm domain model. If this domain
+is a guest, the backend should be set to the vtpm domain name.
+If this domain is a vtpm, the backend should be set to the
+vtpm manager domain name. The default value is domain 0,
+which should be used if you are running the vtpm process model.
+
+=3Ditem C<uuid=3DUUID>
+
+Specify the uuid of this vtpm device. The uuid is used to uniquely
+identify the vtpm device. You can create one using the uuidgen
+program on unix systems. If left unspecified, a new uuid
+will be randomly generated everytime the domain boots.
+
+=3Dback
+
 =3Ditem B<vfb=3D[ "VFB_SPEC_STRING", "VFB_SPEC_STRING", ...]>
=20
 Specifies the paravirtual framebuffer devices which should be supplied
diff --git a/docs/man/xl.pod.1 b/docs/man/xl.pod.1
--- a/docs/man/xl.pod.1
+++ b/docs/man/xl.pod.1
@@ -1101,6 +1101,31 @@ List virtual network interfaces for a domain.
=20
 =3Dback
=20
+=3Dhead2 VTPM DEVICES
+
+=3Dover 4
+
+=3Ditem B<vtpm-attach> I<domain-id> I<vtpm-device>
+
+Creates a new vtpm device in the domain specified by I<domain-id>.
+I<vtpm-device> describes the device to attach, using the same format as =
the
+B<vtpm> string in the domain config file. See L<xl.cfg> for
+more information.
+
+=3Ditem B<vtpm-detach> I<domain-id> I<devid|uuid>
+
+Removes the vtpm device from the domain specified by I<domain-id>.
+I<devid> is the numeric device id given to the virtual trusted
+platform module device. You will need to run B<xl vtpm-list> to determin=
e that number.
+Alternatively the I<uuid> of the vtpm can be used to
+select the virtual device to detach.
+
+=3Ditem B<vtpm-list> I<domain-id>
+
+List virtual trusted platform modules for a domain.
+
+=3Dback
+
 =3Dhead1 PCI PASS-THROUGH
=20
 =3Dover 4
diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -1726,6 +1726,246 @@ out:
 }
=20
 /***********************************************************************=
*******/
+int libxl__device_vtpm_setdefault(libxl__gc *gc, libxl_device_vtpm *vtpm=
)
+{
+   if(libxl_uuid_is_nil(&vtpm->uuid)) {
+      libxl_uuid_generate(&vtpm->uuid);
+   }
+   return 0;
+}
+
+static int libxl__device_from_vtpm(libxl__gc *gc, uint32_t domid,
+                                   libxl_device_vtpm *vtpm,
+                                   libxl__device *device)
+{
+   device->backend_devid   =3D vtpm->devid;
+   device->backend_domid   =3D vtpm->backend_domid;
+   device->backend_kind    =3D LIBXL__DEVICE_KIND_VTPM;
+   device->devid           =3D vtpm->devid;
+   device->domid           =3D domid;
+   device->kind            =3D LIBXL__DEVICE_KIND_VTPM;
+
+   return 0;
+}
+
+void libxl__device_vtpm_add(libxl__egc *egc, uint32_t domid,
+                           libxl_device_vtpm *vtpm,
+                           libxl__ao_device *aodev)
+{
+    STATE_AO_GC(aodev->ao);
+    flexarray_t *front;
+    flexarray_t *back;
+    libxl__device *device;
+    char *dompath, **l;
+    unsigned int nb, rc;
+
+    rc =3D libxl__device_vtpm_setdefault(gc, vtpm);
+    if (rc) goto out;
+
+    front =3D flexarray_make(16, 1);
+    if (!front) {
+        rc =3D ERROR_NOMEM;
+        goto out;
+    }
+    back =3D flexarray_make(16, 1);
+    if (!back) {
+        rc =3D ERROR_NOMEM;
+        goto out;
+    }
+
+    if(vtpm->devid =3D=3D -1) {
+        if (!(dompath =3D libxl__xs_get_dompath(gc, domid))) {
+            rc =3D ERROR_FAIL;
+            goto out_free;
+        }
+        l =3D libxl__xs_directory(gc, XBT_NULL, libxl__sprintf(gc, "%s/d=
evice/vtpm", dompath), &nb);
+        if(l =3D=3D NULL || nb =3D=3D 0) {
+            vtpm->devid =3D 0;
+        } else {
+            vtpm->devid =3D strtoul(l[nb - 1], NULL, 10) + 1;
+        }
+    }
+
+    GCNEW(device);
+    rc =3D libxl__device_from_vtpm(gc, domid, vtpm, device);
+    if ( rc !=3D 0 ) goto out_free;
+
+    flexarray_append(back, "frontend-id");
+    flexarray_append(back, libxl__sprintf(gc, "%d", domid));
+    flexarray_append(back, "online");
+    flexarray_append(back, "1");
+    flexarray_append(back, "state");
+    flexarray_append(back, libxl__sprintf(gc, "%d", 1));
+
+    flexarray_append(back, "uuid");
+    flexarray_append(back, libxl__sprintf(gc, LIBXL_UUID_FMT, LIBXL_UUID=
_BYTES(vtpm->uuid)));
+    flexarray_append(back, "instance"); /* MAYBE CAN GET RID OF THIS */
+    flexarray_append(back, "0");
+    flexarray_append(back, "pref_instance"); /* MAYBE CAN GET RID OF THI=
S */
+    flexarray_append(back, "0");
+    flexarray_append(back, "resume");
+    flexarray_append(back, "False");
+    flexarray_append(back, "ready"); /* MAYBE CAN GET RID OF THIS */
+    flexarray_append(back, "1");
+
+    flexarray_append(front, "backend-id");
+    flexarray_append(front, libxl__sprintf(gc, "%d", vtpm->backend_domid=
));
+    flexarray_append(front, "state");
+    flexarray_append(front, libxl__sprintf(gc, "%d", 1));
+    flexarray_append(front, "handle");
+    flexarray_append(front, libxl__sprintf(gc, "%d", vtpm->devid));
+
+    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));
+
+    aodev->dev =3D device;
+    aodev->action =3D DEVICE_CONNECT;
+    libxl__wait_device_connection(egc, aodev);
+
+    rc =3D 0;
+out_free:
+    flexarray_free(back);
+    flexarray_free(front);
+out:
+    aodev->rc =3D rc;
+    if(rc) aodev->callback(egc, aodev);
+    return;
+}
+
+static void libxl__device_vtpm_from_xs_fe(libxl__gc *gc,
+                                          const char* fe_path,
+                                          libxl_device_vtpm *vtpm)
+{
+   char* tmp;
+
+   memset(vtpm, 0, sizeof(*vtpm));
+   tmp =3D libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/handle", =
fe_path));
+   if (tmp) {
+      vtpm->devid =3D atoi(tmp);
+   }
+   tmp =3D libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/backend-i=
d", fe_path));
+   if(tmp) {
+      vtpm->backend_domid =3D atoi(tmp);
+   }
+   tmp =3D libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/uuid", fe=
_path));
+   if(tmp) {
+      libxl_uuid_from_string(&(vtpm->uuid), tmp);
+   }
+}
+
+libxl_device_vtpm *libxl_device_vtpm_list(libxl_ctx *ctx, uint32_t domid=
, int *num)
+{
+    GC_INIT(ctx);
+
+    libxl_device_vtpm* vtpms =3D NULL;
+    char* fe_path =3D NULL;
+    char** dir =3D NULL;
+    unsigned int ndirs =3D 0;
+
+    *num =3D 0;
+
+    fe_path =3D libxl__sprintf(gc, "%s/device/vtpm", libxl__xs_get_dompa=
th(gc, domid));
+    dir =3D libxl__xs_directory(gc, XBT_NULL, fe_path, &ndirs);
+    if(dir) {
+       vtpms =3D malloc(sizeof(*vtpms) * ndirs);
+       libxl_device_vtpm* vtpm;
+       libxl_device_vtpm* end =3D vtpms + ndirs;
+       for(vtpm =3D vtpms; vtpm < end; ++vtpm, ++dir) {
+          const char* path =3D libxl__sprintf(gc, "%s/%s", fe_path, *dir=
);
+          libxl__device_vtpm_from_xs_fe(gc, path, vtpm);
+       }
+    }
+    *num =3D ndirs;
+
+    GC_FREE;
+    return vtpms;
+}
+
+int libxl_device_vtpm_getinfo(libxl_ctx *ctx, uint32_t domid,
+                               libxl_device_vtpm *vtpm, libxl_vtpminfo *=
vtpminfo)
+{
+    GC_INIT(ctx);
+    char *dompath, *vtpmpath;
+    char *val;
+    int rc =3D 0;
+
+    libxl_vtpminfo_init(vtpminfo);
+    dompath =3D libxl__xs_get_dompath(gc, domid);
+    vtpminfo->devid =3D vtpm->devid;
+
+    vtpmpath =3D libxl__sprintf(gc, "%s/device/vtpm/%d", dompath, vtpmin=
fo->devid);
+    vtpminfo->backend =3D xs_read(ctx->xsh, XBT_NULL,
+                                libxl__sprintf(gc, "%s/backend", vtpmpat=
h), NULL);
+    if (!vtpminfo->backend) {
+        goto err;
+    }
+    if(!libxl__xs_read(gc, XBT_NULL, vtpminfo->backend)) {
+       goto err;
+    }
+
+    val =3D libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/backend-=
id", vtpmpath));
+    vtpminfo->backend_id =3D val ? strtoul(val, NULL, 10) : -1;
+    val =3D libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/state", =
vtpmpath));
+    vtpminfo->state =3D val ? strtoul(val, NULL, 10) : -1;
+    val =3D libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/event-ch=
annel", vtpmpath));
+    vtpminfo->evtch =3D val ? strtoul(val, NULL, 10) : -1;
+    val =3D libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/ring-ref=
", vtpmpath));
+    vtpminfo->rref =3D val ? strtoul(val, NULL, 10) : -1;
+    vtpminfo->frontend =3D xs_read(ctx->xsh, XBT_NULL,
+                                 libxl__sprintf(gc, "%s/frontend", vtpmi=
nfo->backend), NULL);
+    val =3D libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/frontend=
-id", vtpminfo->backend));
+    vtpminfo->frontend_id =3D val ? strtoul(val, NULL, 10) : -1;
+
+    val =3D libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/uuid", v=
tpminfo->backend));
+    if(val =3D=3D NULL) {
+       LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "%s/uuid does not exist!\n", vt=
pminfo->backend);
+       goto err;
+    }
+    if(libxl_uuid_from_string(&(vtpminfo->uuid), val)) {
+       LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "%s/uuid is a malformed uuid?? =
(%s) Probably a bug!\n", vtpminfo->backend, val);
+       goto err;
+    }
+
+    goto exit;
+err:
+    rc =3D ERROR_FAIL;
+exit:
+    GC_FREE;
+    return rc;
+}
+
+int libxl_devid_to_device_vtpm(libxl_ctx *ctx, uint32_t domid,
+                              int devid, libxl_device_vtpm *vtpm)
+{
+    libxl_device_vtpm *vtpms;
+    int nb, i;
+    int rc;
+
+    vtpms =3D libxl_device_vtpm_list(ctx, domid, &nb);
+    if (!vtpms)
+        return ERROR_FAIL;
+
+    memset(vtpm, 0, sizeof (libxl_device_vtpm));
+    rc =3D 1;
+    for (i =3D 0; i < nb; ++i) {
+        if(devid =3D=3D vtpms[i].devid) {
+            vtpm->backend_domid =3D vtpms[i].backend_domid;
+            vtpm->devid =3D vtpms[i].devid;
+            libxl_uuid_copy(&vtpm->uuid, &vtpms[i].uuid);
+            rc =3D 0;
+            break;
+        }
+    }
+
+    for (i=3D0; i<nb; i++)
+        libxl_device_vtpm_dispose(&vtpms[i]);
+    free(vtpms);
+    return rc;
+}
+
+
+/***********************************************************************=
*******/
=20
 int libxl__device_disk_setdefault(libxl__gc *gc, libxl_device_disk *disk=
)
 {
@@ -3174,6 +3414,10 @@ DEFINE_DEVICE_REMOVE(vkb, destroy, 1)
 DEFINE_DEVICE_REMOVE(vfb, remove, 0)
 DEFINE_DEVICE_REMOVE(vfb, destroy, 1)
=20
+/* vtpm */
+DEFINE_DEVICE_REMOVE(vtpm, remove, 0)
+DEFINE_DEVICE_REMOVE(vtpm, destroy, 1)
+
 #undef DEFINE_DEVICE_REMOVE
=20
 /***********************************************************************=
*******/
@@ -3208,6 +3452,9 @@ DEFINE_DEVICE_ADD(disk)
 /* nic */
 DEFINE_DEVICE_ADD(nic)
=20
+/* vtpm */
+DEFINE_DEVICE_ADD(vtpm)
+
 #undef DEFINE_DEVICE_ADD
=20
 /***********************************************************************=
*******/
diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -478,13 +478,14 @@ typedef struct {
     libxl_domain_create_info c_info;
     libxl_domain_build_info b_info;
=20
-    int num_disks, num_nics, num_pcidevs, num_vfbs, num_vkbs;
+    int num_disks, num_nics, num_pcidevs, num_vfbs, num_vkbs, num_vtpms;=

=20
     libxl_device_disk *disks;
     libxl_device_nic *nics;
     libxl_device_pci *pcidevs;
     libxl_device_vfb *vfbs;
     libxl_device_vkb *vkbs;
+    libxl_device_vtpm *vtpms;
=20
     libxl_action_on_shutdown on_poweroff;
     libxl_action_on_shutdown on_reboot;
@@ -745,6 +746,23 @@ libxl_device_nic *libxl_device_nic_list(libxl_ctx *c=
tx, uint32_t domid, int *num
 int libxl_device_nic_getinfo(libxl_ctx *ctx, uint32_t domid,
                               libxl_device_nic *nic, libxl_nicinfo *nici=
nfo);
=20
+/* Virtual TPMs */
+int libxl_device_vtpm_add(libxl_ctx *ctx, uint32_t domid, libxl_device_v=
tpm *vtpm,
+                          const libxl_asyncop_how *ao_how)
+                          LIBXL_EXTERNAL_CALLERS_ONLY;
+int libxl_device_vtpm_remove(libxl_ctx *ctx, uint32_t domid,
+                            libxl_device_vtpm *vtpm,
+                            const libxl_asyncop_how *ao_how)
+                            LIBXL_EXTERNAL_CALLERS_ONLY;
+int libxl_device_vtpm_destroy(libxl_ctx *ctx, uint32_t domid,
+                              libxl_device_vtpm *vtpm,
+                              const libxl_asyncop_how *ao_how)
+                              LIBXL_EXTERNAL_CALLERS_ONLY;
+
+libxl_device_vtpm *libxl_device_vtpm_list(libxl_ctx *ctx, uint32_t domid=
, int *num);
+int libxl_device_vtpm_getinfo(libxl_ctx *ctx, uint32_t domid,
+                               libxl_device_vtpm *vtpm, libxl_vtpminfo *=
vtpminfo);
+
 /* Keyboard */
 int libxl_device_vkb_add(libxl_ctx *ctx, uint32_t domid, libxl_device_vk=
b *vkb,
                          const libxl_asyncop_how *ao_how)
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
@@ -55,6 +55,10 @@ void libxl_domain_config_dispose(libxl_domain_config *=
d_config)
         libxl_device_vkb_dispose(&d_config->vkbs[i]);
     free(d_config->vkbs);
=20
+    for (i=3D0; i<d_config->num_vtpms; i++)
+       libxl_device_vtpm_dispose(&d_config->vtpms[i]);
+    free(d_config->vtpms);
+
     libxl_domain_create_info_dispose(&d_config->c_info);
     libxl_domain_build_info_dispose(&d_config->b_info);
 }
@@ -601,6 +605,8 @@ static void domcreate_bootloader_done(libxl__egc *egc=
,
 static void domcreate_launch_dm(libxl__egc *egc, libxl__multidev *aodevs=
,
                                 int ret);
=20
+static void domcreate_attach_vtpms(libxl__egc *egc, libxl__multidev *mul=
tidev,
+                                   int ret);
 static void domcreate_attach_pci(libxl__egc *egc, libxl__multidev *aodev=
s,
                                  int ret);
=20
@@ -1084,13 +1090,13 @@ static void domcreate_devmodel_started(libxl__egc=
 *egc,
     if (d_config->num_nics > 0) {
         /* Attach nics */
         libxl__multidev_begin(ao, &dcs->multidev);
-        dcs->multidev.callback =3D domcreate_attach_pci;
+        dcs->multidev.callback =3D domcreate_attach_vtpms;
         libxl__add_nics(egc, ao, domid, d_config, &dcs->multidev);
         libxl__multidev_prepared(egc, &dcs->multidev, 0);
         return;
     }
=20
-    domcreate_attach_pci(egc, &dcs->multidev, 0);
+    domcreate_attach_vtpms(egc, &dcs->multidev, 0);
     return;
=20
 error_out:
@@ -1098,6 +1104,36 @@ error_out:
     domcreate_complete(egc, dcs, ret);
 }
=20
+static void domcreate_attach_vtpms(libxl__egc *egc, libxl__multidev *mul=
tidev, int ret) {
+   libxl__domain_create_state *dcs =3D CONTAINER_OF(multidev, *dcs, mult=
idev);
+   STATE_AO_GC(dcs->ao);
+   int domid =3D dcs->guest_domid;
+
+   libxl_domain_config* const d_config =3D dcs->guest_config;
+
+   if(ret) {
+      LOG(ERROR, "unable to add nic devices");
+      goto error_out;
+   }
+
+    /* Plug nic interfaces */
+    if (d_config->num_vtpms > 0) {
+        /* Attach nics */
+        libxl__multidev_begin(ao, &dcs->multidev);
+        dcs->multidev.callback =3D domcreate_attach_pci;
+        libxl__add_vtpms(egc, ao, domid, d_config, &dcs->multidev);
+        libxl__multidev_prepared(egc, &dcs->multidev, 0);
+        return;
+    }
+
+   domcreate_attach_pci(egc, multidev, 0);
+   return;
+
+error_out:
+   assert(ret);
+   domcreate_complete(egc, dcs, ret);
+}
+
 static void domcreate_attach_pci(libxl__egc *egc, libxl__multidev *multi=
dev,
                                  int ret)
 {
@@ -1111,7 +1147,7 @@ static void domcreate_attach_pci(libxl__egc *egc, l=
ibxl__multidev *multidev,
     libxl_domain_config *const d_config =3D dcs->guest_config;
=20
     if (ret) {
-        LOG(ERROR, "unable to add nic devices");
+        LOG(ERROR, "unable to add vtpm devices");
         goto error_out;
     }
=20
diff --git a/tools/libxl/libxl_device.c b/tools/libxl/libxl_device.c
--- a/tools/libxl/libxl_device.c
+++ b/tools/libxl/libxl_device.c
@@ -515,6 +515,7 @@ void libxl__multidev_prepared(libxl__egc *egc,
=20
 DEFINE_DEVICES_ADD(disk)
 DEFINE_DEVICES_ADD(nic)
+DEFINE_DEVICES_ADD(vtpm)
=20
 #undef DEFINE_DEVICES_ADD
=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
@@ -954,6 +954,7 @@ _hidden int libxl__device_disk_setdefault(libxl__gc *=
gc,
                                           libxl_device_disk *disk);
 _hidden int libxl__device_nic_setdefault(libxl__gc *gc, libxl_device_nic=
 *nic,
                                          uint32_t domid);
+_hidden int libxl__device_vtpm_setdefault(libxl__gc *gc, libxl_device_vt=
pm *vtpm);
 _hidden int libxl__device_vfb_setdefault(libxl__gc *gc, libxl_device_vfb=
 *vfb);
 _hidden int libxl__device_vkb_setdefault(libxl__gc *gc, libxl_device_vkb=
 *vkb);
 _hidden int libxl__device_pci_setdefault(libxl__gc *gc, libxl_device_pci=
 *pci);
@@ -1975,6 +1976,10 @@ _hidden void libxl__device_nic_add(libxl__egc *egc=
, uint32_t domid,
                                    libxl_device_nic *nic,
                                    libxl__ao_device *aodev);
=20
+_hidden void libxl__device_vtpm_add(libxl__egc *egc, uint32_t domid,
+                                   libxl_device_vtpm *vtpm,
+                                   libxl__ao_device *aodev);
+
 /* Internal function to connect a vkb device */
 _hidden int libxl__device_vkb_add(libxl__gc *gc, uint32_t domid,
                                   libxl_device_vkb *vkb);
@@ -2407,6 +2412,10 @@ _hidden void libxl__add_nics(libxl__egc *egc, libx=
l__ao *ao, uint32_t domid,
                              libxl_domain_config *d_config,
                              libxl__multidev *multidev);
=20
+_hidden void libxl__add_vtpms(libxl__egc *egc, libxl__ao *ao, uint32_t d=
omid,
+                             libxl_domain_config *d_config,
+                             libxl__multidev *multidev);
+
 /*----- device model creation -----*/
=20
 /* First layer; wraps libxl__spawn_spawn. */
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
@@ -395,6 +395,12 @@ libxl_device_pci =3D Struct("device_pci", [
     ("permissive", bool),
     ])
=20
+libxl_device_vtpm =3D Struct("device_vtpm", [
+    ("backend_domid",    libxl_domid),
+    ("devid",            libxl_devid),
+    ("uuid",             libxl_uuid),
+])
+
 libxl_diskinfo =3D Struct("diskinfo", [
     ("backend", string),
     ("backend_id", uint32),
@@ -418,6 +424,18 @@ libxl_nicinfo =3D Struct("nicinfo", [
     ("rref_rx", integer),
     ], dir=3DDIR_OUT)
=20
+libxl_vtpminfo =3D Struct("vtpminfo", [
+    ("backend", string),
+    ("backend_id", uint32),
+    ("frontend", string),
+    ("frontend_id", uint32),
+    ("devid", libxl_devid),
+    ("state", integer),
+    ("evtch", integer),
+    ("rref", integer),
+    ("uuid", libxl_uuid),
+    ], dir=3DDIR_OUT)
+
 libxl_vcpuinfo =3D Struct("vcpuinfo", [
     ("vcpuid", uint32),
     ("cpu", uint32),
diff --git a/tools/libxl/libxl_types_internal.idl b/tools/libxl/libxl_typ=
es_internal.idl
--- a/tools/libxl/libxl_types_internal.idl
+++ b/tools/libxl/libxl_types_internal.idl
@@ -19,6 +19,7 @@ libxl__device_kind =3D Enumeration("device_kind", [
     (5, "VFB"),
     (6, "VKBD"),
     (7, "CONSOLE"),
+    (8, "VTPM"),
     ])
=20
 libxl__console_backend =3D Enumeration("console_backend", [
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
@@ -463,6 +463,35 @@ int libxl_pipe(libxl_ctx *ctx, int pipes[2])
     return 0;
 }
=20
+int libxl_uuid_to_device_vtpm(libxl_ctx *ctx, uint32_t domid,
+                            libxl_uuid* uuid, libxl_device_vtpm *vtpm)
+{
+    libxl_device_vtpm *vtpms;
+    int nb, i;
+    int rc;
+
+    vtpms =3D libxl_device_vtpm_list(ctx, domid, &nb);
+    if (!vtpms)
+        return ERROR_FAIL;
+
+    memset(vtpm, 0, sizeof (libxl_device_vtpm));
+    rc =3D 1;
+    for (i =3D 0; i < nb; ++i) {
+        if(!libxl_uuid_compare(uuid, &vtpms[i].uuid)) {
+            vtpm->backend_domid =3D vtpms[i].backend_domid;
+            vtpm->devid =3D vtpms[i].devid;
+            libxl_uuid_copy(&vtpm->uuid, &vtpms[i].uuid);
+            rc =3D 0;
+            break;
+        }
+    }
+
+    for (i=3D0; i<nb; i++)
+        libxl_device_vtpm_dispose(&vtpms[i]);
+    free(vtpms);
+    return rc;
+}
+
 int libxl_mac_to_device_nic(libxl_ctx *ctx, uint32_t domid,
                             const char *mac, libxl_device_nic *nic)
 {
diff --git a/tools/libxl/libxl_utils.h b/tools/libxl/libxl_utils.h
--- a/tools/libxl/libxl_utils.h
+++ b/tools/libxl/libxl_utils.h
@@ -64,6 +64,11 @@ int libxl_devid_to_device_nic(libxl_ctx *ctx, uint32_t=
 domid, int devid,
 int libxl_vdev_to_device_disk(libxl_ctx *ctx, uint32_t domid, const char=
 *vdev,
                                libxl_device_disk *disk);
=20
+int libxl_uuid_to_device_vtpm(libxl_ctx *ctx, uint32_t domid,
+                               libxl_uuid *uuid, libxl_device_vtpm *vtpm=
);
+int libxl_devid_to_device_vtpm(libxl_ctx *ctx, uint32_t domid,
+                               int devid, libxl_device_vtpm *vtpm);
+
 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. */
diff --git a/tools/libxl/xl.h b/tools/libxl/xl.h
--- a/tools/libxl/xl.h
+++ b/tools/libxl/xl.h
@@ -79,6 +79,9 @@ int main_networkdetach(int argc, char **argv);
 int main_blockattach(int argc, char **argv);
 int main_blocklist(int argc, char **argv);
 int main_blockdetach(int argc, char **argv);
+int main_vtpmattach(int argc, char **argv);
+int main_vtpmlist(int argc, char **argv);
+int main_vtpmdetach(int argc, char **argv);
 int main_uptime(int argc, char **argv);
 int main_tmem_list(int argc, char **argv);
 int main_tmem_freeze(int argc, char **argv);
diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -573,7 +573,7 @@ static void parse_config_data(const char *config_sour=
ce,
     const char *buf;
     long l;
     XLU_Config *config;
-    XLU_ConfigList *cpus, *vbds, *nics, *pcis, *cvfbs, *cpuids;
+    XLU_ConfigList *cpus, *vbds, *nics, *pcis, *cvfbs, *cpuids, *vtpms;
     XLU_ConfigList *ioports, *irqs, *iomem;
     int num_ioports, num_irqs, num_iomem;
     int pci_power_mgmt =3D 0;
@@ -1045,6 +1045,47 @@ static void parse_config_data(const char *config_s=
ource,
         }
     }
=20
+    if (!xlu_cfg_get_list(config, "vtpm", &vtpms, 0, 0)) {
+        d_config->num_vtpms =3D 0;
+        d_config->vtpms =3D NULL;
+        while ((buf =3D xlu_cfg_get_listitem (vtpms, d_config->num_vtpms=
)) !=3D NULL) {
+            libxl_device_vtpm *vtpm;
+            char * buf2 =3D strdup(buf);
+            char *p, *p2;
+
+            d_config->vtpms =3D (libxl_device_vtpm *) realloc(d_config->=
vtpms, sizeof(libxl_device_vtpm) * (d_config->num_vtpms+1));
+            vtpm =3D d_config->vtpms + d_config->num_vtpms;
+            libxl_device_vtpm_init(vtpm);
+            vtpm->devid =3D d_config->num_vtpms;
+
+            p =3D strtok(buf2, ",");
+            if (!p)
+                goto skip_vtpm;
+            do {
+                while(*p =3D=3D ' ')
+                    ++p;
+                if ((p2 =3D strchr(p, '=3D')) =3D=3D NULL)
+                    break;
+                *p2 =3D '\0';
+                if (!strcmp(p, "backend")) {
+                    if(domain_qualifier_to_domid(p2 + 1, &(vtpm->backend=
_domid), 0))
+                    {
+                        fprintf(stderr, "Specified backend domain does n=
ot exist, defaulting to Dom0\n");
+                        vtpm->backend_domid =3D 0;
+                    }
+                } else if(!strcmp(p, "uuid")) {
+                    if( libxl_uuid_from_string(&vtpm->uuid, p2 + 1) ) {
+                        fprintf(stderr, "Failed to parse vtpm UUID: %s\n=
", p2 + 1);
+                        exit(1);
+                    }
+                }
+            } while ((p =3D strtok(NULL, ",")) !=3D NULL);
+skip_vtpm:
+            free(buf2);
+            d_config->num_vtpms++;
+        }
+    }
+
     if (!xlu_cfg_get_list (config, "vif", &nics, 0, 0)) {
         d_config->num_nics =3D 0;
         d_config->nics =3D NULL;
@@ -1070,7 +1111,7 @@ static void parse_config_data(const char *config_so=
urce,
=20
             p =3D strtok(buf2, ",");
             if (!p)
-                goto skip;
+                goto skip_nic;
             do {
                 while (*p =3D=3D ' ')
                     p++;
@@ -1134,7 +1175,7 @@ static void parse_config_data(const char *config_so=
urce,
                     fprintf(stderr, "the accel parameter for vifs is cur=
rently not supported\n");
                 }
             } while ((p =3D strtok(NULL, ",")) !=3D NULL);
-skip:
+skip_nic:
             free(buf2);
             d_config->num_nics++;
         }
@@ -5570,6 +5611,131 @@ int main_blockdetach(int argc, char **argv)
     return rc;
 }
=20
+int main_vtpmattach(int argc, char **argv)
+{
+    int opt;
+    libxl_device_vtpm vtpm;
+    char *oparg;
+    unsigned int val;
+    uint32_t domid;
+
+    if ((opt =3D def_getopt(argc, argv, "", "vtpm-attach", 1)) !=3D -1)
+        return opt;
+
+    if (domain_qualifier_to_domid(argv[optind], &domid, 0) < 0) {
+        fprintf(stderr, "%s is an invalid domain identifier\n", argv[opt=
ind]);
+        return 1;
+    }
+    ++optind;
+
+    libxl_device_vtpm_init(&vtpm);
+    for (argv +=3D optind, argc -=3D optind; argc > 0; ++argv, --argc) {=

+        if (MATCH_OPTION("uuid", *argv, oparg)) {
+            if(libxl_uuid_from_string(&(vtpm.uuid), oparg)) {
+                fprintf(stderr, "Invalid uuid specified (%s)\n", oparg);=

+                return 1;
+            }
+        } else if (MATCH_OPTION("backend", *argv, oparg)) {
+            if(domain_qualifier_to_domid(oparg, &val, 0)) {
+                fprintf(stderr, "Specified backend domain does not exist=
, defaulting to Dom0\n");
+                val =3D 0;
+            }
+            vtpm.backend_domid =3D val;
+        } else {
+            fprintf(stderr, "unrecognized argument `%s'\n", *argv);
+            return 1;
+        }
+    }
+
+    if(dryrun_only) {
+       char* json =3D libxl_device_vtpm_to_json(ctx, &vtpm);
+       printf("vtpm: %s\n", json);
+       free(json);
+       libxl_device_vtpm_dispose(&vtpm);
+       if (ferror(stdout) || fflush(stdout)) { perror("stdout"); exit(-1=
); }
+       return 0;
+    }
+
+    if (libxl_device_vtpm_add(ctx, domid, &vtpm, 0)) {
+        fprintf(stderr, "libxl_device_vtpm_add failed.\n");
+        return 1;
+    }
+    libxl_device_vtpm_dispose(&vtpm);
+    return 0;
+}
+
+int main_vtpmlist(int argc, char **argv)
+{
+    int opt;
+    libxl_device_vtpm *vtpms;
+    libxl_vtpminfo vtpminfo;
+    int nb, i;
+
+    if ((opt =3D def_getopt(argc, argv, "", "vtpm-list", 1)) !=3D -1)
+        return opt;
+
+    /*      Idx  BE   UUID   Hdl  Sta  evch rref  BE-path */
+    printf("%-3s %-2s %-36s %-6s %-5s %-6s %-5s %-10s\n",
+           "Idx", "BE", "Uuid", "handle", "state", "evt-ch", "ring-ref",=
 "BE-path");
+    for (argv +=3D optind, argc -=3D optind; argc > 0; --argc, ++argv) {=

+        uint32_t domid;
+        if (domain_qualifier_to_domid(*argv, &domid, 0) < 0) {
+            fprintf(stderr, "%s is an invalid domain identifier\n", *arg=
v);
+            continue;
+        }
+        if (!(vtpms =3D libxl_device_vtpm_list(ctx, domid, &nb))) {
+            continue;
+        }
+        for (i =3D 0; i < nb; ++i) {
+           if(!libxl_device_vtpm_getinfo(ctx, domid, &vtpms[i], &vtpminf=
o)) {
+              /*      Idx  BE     UUID             Hdl Sta evch rref BE-=
path*/
+              printf("%-3d %-2d " LIBXL_UUID_FMT " %6d %5d %6d %8d %-30s=
\n",
+                    vtpminfo.devid, vtpminfo.backend_id,
+                    LIBXL_UUID_BYTES(vtpminfo.uuid),
+                    vtpminfo.devid, vtpminfo.state, vtpminfo.evtch,
+                    vtpminfo.rref, vtpminfo.backend);
+
+              libxl_vtpminfo_dispose(&vtpminfo);
+           }
+           libxl_device_vtpm_dispose(&vtpms[i]);
+        }
+        free(vtpms);
+    }
+    return 0;
+}
+
+int main_vtpmdetach(int argc, char **argv)
+{
+    uint32_t domid;
+    int opt, rc=3D0;
+    libxl_device_vtpm vtpm;
+    libxl_uuid uuid;
+
+    if ((opt =3D def_getopt(argc, argv, "", "vtpm-detach", 2)) !=3D -1)
+        return opt;
+
+    domid =3D find_domain(argv[optind]);
+
+    if ( libxl_uuid_from_string(&uuid, argv[optind+1])) {
+        if (libxl_devid_to_device_vtpm(ctx, domid, atoi(argv[optind+1]),=
 &vtpm)) {
+            fprintf(stderr, "Unknown device %s.\n", argv[optind+1]);
+            return 1;
+        }
+    } else {
+        if (libxl_uuid_to_device_vtpm(ctx, domid, &uuid, &vtpm)) {
+            fprintf(stderr, "Unknown device %s.\n", argv[optind+1]);
+            return 1;
+        }
+    }
+    rc =3D libxl_device_vtpm_remove(ctx, domid, &vtpm, 0);
+    if (rc) {
+        fprintf(stderr, "libxl_device_vtpm_remove failed.\n");
+    }
+    libxl_device_vtpm_dispose(&vtpm);
+    return rc;
+}
+
+
 static char *uptime_to_string(unsigned long uptime, int short_mode)
 {
     int sec, min, hour, day;
diff --git a/tools/libxl/xl_cmdtable.c b/tools/libxl/xl_cmdtable.c
--- a/tools/libxl/xl_cmdtable.c
+++ b/tools/libxl/xl_cmdtable.c
@@ -338,6 +338,21 @@ struct cmd_spec cmd_table[] =3D {
       "Destroy a domain's virtual block device",
       "<Domain> <DevId>",
     },
+    { "vtpm-attach",
+      &main_vtpmattach, 0, 1,
+      "Create a new virtual TPM device",
+      "<Domain> [uuid=3D<uuid>] [backend=3D<BackDomain>]",
+    },
+    { "vtpm-list",
+      &main_vtpmlist, 0, 0,
+      "List virtual TPM devices for a domain",
+      "<Domain(s)>",
+    },
+    { "vtpm-detach",
+      &main_vtpmdetach, 0, 1,
+      "Destroy a domain's virtual TPM device",
+      "<Domain> <DevId|uuid>",
+    },
     { "uptime",
       &main_uptime, 0, 0,
       "Print uptime for all/some domains",



--------------ms060907090204020808090605
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIDyjCC
A8YwggMvoAMCAQICBD/xyf0wDQYJKoZIhvcNAQEFBQAwLzELMAkGA1UEBhMCVVMxDzANBgNV
BAoTBkpIVUFQTDEPMA0GA1UECxMGQklTRENBMB4XDTEwMDYxMTE4MjIwNloXDTEzMDYxMTE4
NTIwNlowZjELMAkGA1UEBhMCVVMxDzANBgNVBAoTBkpIVUFQTDEPMA0GA1UECxMGUGVvcGxl
MTUwFgYDVQQLEw9WUE5Hcm91cC1CSVNEQ0EwGwYDVQQDExRNYXR0aGV3IEUgRmlvcmF2YW50
ZTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAnpbwVSP6o1Nb5lcW7dd3yTo9iBJdi7qz
4nANOMFPK7JOy5npKN1iiousl28U/scUJES55gPwAWYJK3uVyQAsA4adgDKi5DoD1UHDQEwp
bY7iHLJeq0NPr4BqYNqnCFPbE6HC8zSJrr4qKn+gVUQT39SIFqdiIPJwZL8FYTRQ/zsCAwEA
AaOCAbYwggGyMAsGA1UdDwQEAwIHgDArBgNVHRAEJDAigA8yMDEwMDYxMTE4MjIwNlqBDzIw
MTIwNzE3MjI1MjA2WjAbBg0rBgEEAbMlCwMBAQEBBAoWCGZpb3JhbWUxMBsGDSsGAQQBsyUL
AwEBAQIEChIIMDAxMDQyNjEwWAYJYIZIAYb6ax4BBEsMSVRoZSBwcml2YXRlIGtleSBjb3Jy
ZXNwb25kaW5nIHRvIHRoaXMgY2VydGlmaWNhdGUgbWF5IGhhdmUgYmVlbiBleHBvcnRlZC4w
KAYDVR0RBCEwH4EdTWF0dGhldy5GaW9yYXZhbnRlQGpodWFwbC5lZHUwUgYDVR0fBEswSTBH
oEWgQ6RBMD8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJU0RD
QTEOMAwGA1UEAxMFQ1JMNTYwHwYDVR0jBBgwFoAUCDUpmxH52EU2CyWmF2EJMB1yqeswHQYD
VR0OBBYEFO6LYxg6r9wHZ+zdQtBHn1dZ/YTNMAkGA1UdEwQCMAAwGQYJKoZIhvZ9B0EABAww
ChsEVjcuMQMCBLAwDQYJKoZIhvcNAQEFBQADgYEAJO9HQh4YNChVLzuZqK5ARJARD8JoujGZ
fdo75quvg2jXFQe2sEjvLnxJZgm/pv8fdZakq48CWwjYHKuvIp7sDjTEsQfo+y7SpN/N2NvJ
WU5SqfK1VgYtNLRRoGJUB5Q1aZ+Dg95g3kqpyfpUMISJL8IKVLtJVfN4fggFVUYZ9wwxggGr
MIIBpwIBATA3MC8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJ
U0RDQQIEP/HJ/TAJBgUrDgMCGgUAoIHLMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ
KoZIhvcNAQkFMQ8XDTEyMDkyMTE5MzYyM1owIwYJKoZIhvcNAQkEMRYEFCgLS5NZS4NhsqAc
n5ObiAzF0zSwMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAK
BggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI
KoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEgYCM6pkhpJy6Z+rRx2OAM7X5ax28MYST40wQ
eyqcS9sJ2wkkgazhiMe5QsK0PCuGYqSkSDLSHcXxhtM+S1qG9yeLVxJc+mX2wH6H/lyHMjJi
9qyz3vkqdsdK4oEsOLv4qo36IR5h1IFZTpzLlFZio7wbUMYldUx7Hxs8zrR6fEUD8QAAAAAA
AA==
--------------ms060907090204020808090605--


--===============4087893607776326327==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============4087893607776326327==--


From xen-devel-bounces@lists.xen.org Fri Sep 21 19:37:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Sep 2012 19:37:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TF92r-0004dE-8I; Fri, 21 Sep 2012 19:37:49 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <matthew.fioravante@jhuapl.edu>) id 1TF92p-0004ct-A3
	for xen-devel@lists.xensource.com; Fri, 21 Sep 2012 19:37:47 +0000
Received: from [85.158.143.99:30026] by server-3.bemta-4.messagelabs.com id
	C2/A8-10986-A02CC505; Fri, 21 Sep 2012 19:37:46 +0000
X-Env-Sender: matthew.fioravante@jhuapl.edu
X-Msg-Ref: server-10.tower-216.messagelabs.com!1348256263!24887588!1
X-Originating-IP: [128.244.251.36]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG,
	UNPARSEABLE_RELAY
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20686 invoked from network); 21 Sep 2012 19:37:44 -0000
Received: from pilot.jhuapl.edu (HELO jhuapl.edu) (128.244.251.36)
	by server-10.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 21 Sep 2012 19:37:44 -0000
Received: from ([128.244.207.89])
	by pilot.jhuapl.edu with ESMTP with TLS id 63GHCH1.153411787;
	Fri, 21 Sep 2012 15:37:39 -0400
Message-ID: <505CC1B7.3080709@jhuapl.edu>
Date: Fri, 21 Sep 2012 15:36:23 -0400
From: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120827 Thunderbird/15.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>, 
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
X-Enigmail-Version: 1.4.4
Subject: [Xen-devel] PATCH [base vtpm and libxl patches 6/6] add vtpm
	support to libxl
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============4087893607776326327=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a cryptographically signed message in MIME format.

--===============4087893607776326327==
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms060907090204020808090605"

This is a cryptographically signed message in MIME format.

--------------ms060907090204020808090605
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Add support for vtpm=3D["VTPM_SPEC",...] to domain config files. Also add=

commands vtpm-attach, vtpm-list, and vtpm-detach.

Signed off by Matthew Fioravante matthew.fioravante@jhuapl.edu

---
Changes since previous:
* Rebased to latest xen
* Updated xl.cfg and xl manpages

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
@@ -298,6 +298,35 @@ Specifies the networking provision (both emulated ne=
twork adapters,
 and Xen virtual interfaces) to provided to the guest.  See
 F<docs/misc/xl-network-configuration.markdown>.
=20
+=3Ditem B<vtpm=3D[ "VTPM_SPEC_STRING", "VTPM_SPEC_STRING", ...]>
+
+Specifies the virtual trusted platform module to be
+provided to the guest. Please see F<docs/misc/vtpm.txt>
+for more details.
+
+Each B<VTPM_SPEC_STRING> is a comma-separated list of C<KEY=3DVALUE>
+settings, from the following list:
+
+=3Dover 4
+
+=3Ditem C<backend=3DDOMAIN>
+
+Specify the backend domain name of id. This value must be
+set if you are using the vtpm domain model. If this domain
+is a guest, the backend should be set to the vtpm domain name.
+If this domain is a vtpm, the backend should be set to the
+vtpm manager domain name. The default value is domain 0,
+which should be used if you are running the vtpm process model.
+
+=3Ditem C<uuid=3DUUID>
+
+Specify the uuid of this vtpm device. The uuid is used to uniquely
+identify the vtpm device. You can create one using the uuidgen
+program on unix systems. If left unspecified, a new uuid
+will be randomly generated everytime the domain boots.
+
+=3Dback
+
 =3Ditem B<vfb=3D[ "VFB_SPEC_STRING", "VFB_SPEC_STRING", ...]>
=20
 Specifies the paravirtual framebuffer devices which should be supplied
diff --git a/docs/man/xl.pod.1 b/docs/man/xl.pod.1
--- a/docs/man/xl.pod.1
+++ b/docs/man/xl.pod.1
@@ -1101,6 +1101,31 @@ List virtual network interfaces for a domain.
=20
 =3Dback
=20
+=3Dhead2 VTPM DEVICES
+
+=3Dover 4
+
+=3Ditem B<vtpm-attach> I<domain-id> I<vtpm-device>
+
+Creates a new vtpm device in the domain specified by I<domain-id>.
+I<vtpm-device> describes the device to attach, using the same format as =
the
+B<vtpm> string in the domain config file. See L<xl.cfg> for
+more information.
+
+=3Ditem B<vtpm-detach> I<domain-id> I<devid|uuid>
+
+Removes the vtpm device from the domain specified by I<domain-id>.
+I<devid> is the numeric device id given to the virtual trusted
+platform module device. You will need to run B<xl vtpm-list> to determin=
e that number.
+Alternatively the I<uuid> of the vtpm can be used to
+select the virtual device to detach.
+
+=3Ditem B<vtpm-list> I<domain-id>
+
+List virtual trusted platform modules for a domain.
+
+=3Dback
+
 =3Dhead1 PCI PASS-THROUGH
=20
 =3Dover 4
diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -1726,6 +1726,246 @@ out:
 }
=20
 /***********************************************************************=
*******/
+int libxl__device_vtpm_setdefault(libxl__gc *gc, libxl_device_vtpm *vtpm=
)
+{
+   if(libxl_uuid_is_nil(&vtpm->uuid)) {
+      libxl_uuid_generate(&vtpm->uuid);
+   }
+   return 0;
+}
+
+static int libxl__device_from_vtpm(libxl__gc *gc, uint32_t domid,
+                                   libxl_device_vtpm *vtpm,
+                                   libxl__device *device)
+{
+   device->backend_devid   =3D vtpm->devid;
+   device->backend_domid   =3D vtpm->backend_domid;
+   device->backend_kind    =3D LIBXL__DEVICE_KIND_VTPM;
+   device->devid           =3D vtpm->devid;
+   device->domid           =3D domid;
+   device->kind            =3D LIBXL__DEVICE_KIND_VTPM;
+
+   return 0;
+}
+
+void libxl__device_vtpm_add(libxl__egc *egc, uint32_t domid,
+                           libxl_device_vtpm *vtpm,
+                           libxl__ao_device *aodev)
+{
+    STATE_AO_GC(aodev->ao);
+    flexarray_t *front;
+    flexarray_t *back;
+    libxl__device *device;
+    char *dompath, **l;
+    unsigned int nb, rc;
+
+    rc =3D libxl__device_vtpm_setdefault(gc, vtpm);
+    if (rc) goto out;
+
+    front =3D flexarray_make(16, 1);
+    if (!front) {
+        rc =3D ERROR_NOMEM;
+        goto out;
+    }
+    back =3D flexarray_make(16, 1);
+    if (!back) {
+        rc =3D ERROR_NOMEM;
+        goto out;
+    }
+
+    if(vtpm->devid =3D=3D -1) {
+        if (!(dompath =3D libxl__xs_get_dompath(gc, domid))) {
+            rc =3D ERROR_FAIL;
+            goto out_free;
+        }
+        l =3D libxl__xs_directory(gc, XBT_NULL, libxl__sprintf(gc, "%s/d=
evice/vtpm", dompath), &nb);
+        if(l =3D=3D NULL || nb =3D=3D 0) {
+            vtpm->devid =3D 0;
+        } else {
+            vtpm->devid =3D strtoul(l[nb - 1], NULL, 10) + 1;
+        }
+    }
+
+    GCNEW(device);
+    rc =3D libxl__device_from_vtpm(gc, domid, vtpm, device);
+    if ( rc !=3D 0 ) goto out_free;
+
+    flexarray_append(back, "frontend-id");
+    flexarray_append(back, libxl__sprintf(gc, "%d", domid));
+    flexarray_append(back, "online");
+    flexarray_append(back, "1");
+    flexarray_append(back, "state");
+    flexarray_append(back, libxl__sprintf(gc, "%d", 1));
+
+    flexarray_append(back, "uuid");
+    flexarray_append(back, libxl__sprintf(gc, LIBXL_UUID_FMT, LIBXL_UUID=
_BYTES(vtpm->uuid)));
+    flexarray_append(back, "instance"); /* MAYBE CAN GET RID OF THIS */
+    flexarray_append(back, "0");
+    flexarray_append(back, "pref_instance"); /* MAYBE CAN GET RID OF THI=
S */
+    flexarray_append(back, "0");
+    flexarray_append(back, "resume");
+    flexarray_append(back, "False");
+    flexarray_append(back, "ready"); /* MAYBE CAN GET RID OF THIS */
+    flexarray_append(back, "1");
+
+    flexarray_append(front, "backend-id");
+    flexarray_append(front, libxl__sprintf(gc, "%d", vtpm->backend_domid=
));
+    flexarray_append(front, "state");
+    flexarray_append(front, libxl__sprintf(gc, "%d", 1));
+    flexarray_append(front, "handle");
+    flexarray_append(front, libxl__sprintf(gc, "%d", vtpm->devid));
+
+    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));
+
+    aodev->dev =3D device;
+    aodev->action =3D DEVICE_CONNECT;
+    libxl__wait_device_connection(egc, aodev);
+
+    rc =3D 0;
+out_free:
+    flexarray_free(back);
+    flexarray_free(front);
+out:
+    aodev->rc =3D rc;
+    if(rc) aodev->callback(egc, aodev);
+    return;
+}
+
+static void libxl__device_vtpm_from_xs_fe(libxl__gc *gc,
+                                          const char* fe_path,
+                                          libxl_device_vtpm *vtpm)
+{
+   char* tmp;
+
+   memset(vtpm, 0, sizeof(*vtpm));
+   tmp =3D libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/handle", =
fe_path));
+   if (tmp) {
+      vtpm->devid =3D atoi(tmp);
+   }
+   tmp =3D libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/backend-i=
d", fe_path));
+   if(tmp) {
+      vtpm->backend_domid =3D atoi(tmp);
+   }
+   tmp =3D libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/uuid", fe=
_path));
+   if(tmp) {
+      libxl_uuid_from_string(&(vtpm->uuid), tmp);
+   }
+}
+
+libxl_device_vtpm *libxl_device_vtpm_list(libxl_ctx *ctx, uint32_t domid=
, int *num)
+{
+    GC_INIT(ctx);
+
+    libxl_device_vtpm* vtpms =3D NULL;
+    char* fe_path =3D NULL;
+    char** dir =3D NULL;
+    unsigned int ndirs =3D 0;
+
+    *num =3D 0;
+
+    fe_path =3D libxl__sprintf(gc, "%s/device/vtpm", libxl__xs_get_dompa=
th(gc, domid));
+    dir =3D libxl__xs_directory(gc, XBT_NULL, fe_path, &ndirs);
+    if(dir) {
+       vtpms =3D malloc(sizeof(*vtpms) * ndirs);
+       libxl_device_vtpm* vtpm;
+       libxl_device_vtpm* end =3D vtpms + ndirs;
+       for(vtpm =3D vtpms; vtpm < end; ++vtpm, ++dir) {
+          const char* path =3D libxl__sprintf(gc, "%s/%s", fe_path, *dir=
);
+          libxl__device_vtpm_from_xs_fe(gc, path, vtpm);
+       }
+    }
+    *num =3D ndirs;
+
+    GC_FREE;
+    return vtpms;
+}
+
+int libxl_device_vtpm_getinfo(libxl_ctx *ctx, uint32_t domid,
+                               libxl_device_vtpm *vtpm, libxl_vtpminfo *=
vtpminfo)
+{
+    GC_INIT(ctx);
+    char *dompath, *vtpmpath;
+    char *val;
+    int rc =3D 0;
+
+    libxl_vtpminfo_init(vtpminfo);
+    dompath =3D libxl__xs_get_dompath(gc, domid);
+    vtpminfo->devid =3D vtpm->devid;
+
+    vtpmpath =3D libxl__sprintf(gc, "%s/device/vtpm/%d", dompath, vtpmin=
fo->devid);
+    vtpminfo->backend =3D xs_read(ctx->xsh, XBT_NULL,
+                                libxl__sprintf(gc, "%s/backend", vtpmpat=
h), NULL);
+    if (!vtpminfo->backend) {
+        goto err;
+    }
+    if(!libxl__xs_read(gc, XBT_NULL, vtpminfo->backend)) {
+       goto err;
+    }
+
+    val =3D libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/backend-=
id", vtpmpath));
+    vtpminfo->backend_id =3D val ? strtoul(val, NULL, 10) : -1;
+    val =3D libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/state", =
vtpmpath));
+    vtpminfo->state =3D val ? strtoul(val, NULL, 10) : -1;
+    val =3D libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/event-ch=
annel", vtpmpath));
+    vtpminfo->evtch =3D val ? strtoul(val, NULL, 10) : -1;
+    val =3D libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/ring-ref=
", vtpmpath));
+    vtpminfo->rref =3D val ? strtoul(val, NULL, 10) : -1;
+    vtpminfo->frontend =3D xs_read(ctx->xsh, XBT_NULL,
+                                 libxl__sprintf(gc, "%s/frontend", vtpmi=
nfo->backend), NULL);
+    val =3D libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/frontend=
-id", vtpminfo->backend));
+    vtpminfo->frontend_id =3D val ? strtoul(val, NULL, 10) : -1;
+
+    val =3D libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/uuid", v=
tpminfo->backend));
+    if(val =3D=3D NULL) {
+       LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "%s/uuid does not exist!\n", vt=
pminfo->backend);
+       goto err;
+    }
+    if(libxl_uuid_from_string(&(vtpminfo->uuid), val)) {
+       LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "%s/uuid is a malformed uuid?? =
(%s) Probably a bug!\n", vtpminfo->backend, val);
+       goto err;
+    }
+
+    goto exit;
+err:
+    rc =3D ERROR_FAIL;
+exit:
+    GC_FREE;
+    return rc;
+}
+
+int libxl_devid_to_device_vtpm(libxl_ctx *ctx, uint32_t domid,
+                              int devid, libxl_device_vtpm *vtpm)
+{
+    libxl_device_vtpm *vtpms;
+    int nb, i;
+    int rc;
+
+    vtpms =3D libxl_device_vtpm_list(ctx, domid, &nb);
+    if (!vtpms)
+        return ERROR_FAIL;
+
+    memset(vtpm, 0, sizeof (libxl_device_vtpm));
+    rc =3D 1;
+    for (i =3D 0; i < nb; ++i) {
+        if(devid =3D=3D vtpms[i].devid) {
+            vtpm->backend_domid =3D vtpms[i].backend_domid;
+            vtpm->devid =3D vtpms[i].devid;
+            libxl_uuid_copy(&vtpm->uuid, &vtpms[i].uuid);
+            rc =3D 0;
+            break;
+        }
+    }
+
+    for (i=3D0; i<nb; i++)
+        libxl_device_vtpm_dispose(&vtpms[i]);
+    free(vtpms);
+    return rc;
+}
+
+
+/***********************************************************************=
*******/
=20
 int libxl__device_disk_setdefault(libxl__gc *gc, libxl_device_disk *disk=
)
 {
@@ -3174,6 +3414,10 @@ DEFINE_DEVICE_REMOVE(vkb, destroy, 1)
 DEFINE_DEVICE_REMOVE(vfb, remove, 0)
 DEFINE_DEVICE_REMOVE(vfb, destroy, 1)
=20
+/* vtpm */
+DEFINE_DEVICE_REMOVE(vtpm, remove, 0)
+DEFINE_DEVICE_REMOVE(vtpm, destroy, 1)
+
 #undef DEFINE_DEVICE_REMOVE
=20
 /***********************************************************************=
*******/
@@ -3208,6 +3452,9 @@ DEFINE_DEVICE_ADD(disk)
 /* nic */
 DEFINE_DEVICE_ADD(nic)
=20
+/* vtpm */
+DEFINE_DEVICE_ADD(vtpm)
+
 #undef DEFINE_DEVICE_ADD
=20
 /***********************************************************************=
*******/
diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -478,13 +478,14 @@ typedef struct {
     libxl_domain_create_info c_info;
     libxl_domain_build_info b_info;
=20
-    int num_disks, num_nics, num_pcidevs, num_vfbs, num_vkbs;
+    int num_disks, num_nics, num_pcidevs, num_vfbs, num_vkbs, num_vtpms;=

=20
     libxl_device_disk *disks;
     libxl_device_nic *nics;
     libxl_device_pci *pcidevs;
     libxl_device_vfb *vfbs;
     libxl_device_vkb *vkbs;
+    libxl_device_vtpm *vtpms;
=20
     libxl_action_on_shutdown on_poweroff;
     libxl_action_on_shutdown on_reboot;
@@ -745,6 +746,23 @@ libxl_device_nic *libxl_device_nic_list(libxl_ctx *c=
tx, uint32_t domid, int *num
 int libxl_device_nic_getinfo(libxl_ctx *ctx, uint32_t domid,
                               libxl_device_nic *nic, libxl_nicinfo *nici=
nfo);
=20
+/* Virtual TPMs */
+int libxl_device_vtpm_add(libxl_ctx *ctx, uint32_t domid, libxl_device_v=
tpm *vtpm,
+                          const libxl_asyncop_how *ao_how)
+                          LIBXL_EXTERNAL_CALLERS_ONLY;
+int libxl_device_vtpm_remove(libxl_ctx *ctx, uint32_t domid,
+                            libxl_device_vtpm *vtpm,
+                            const libxl_asyncop_how *ao_how)
+                            LIBXL_EXTERNAL_CALLERS_ONLY;
+int libxl_device_vtpm_destroy(libxl_ctx *ctx, uint32_t domid,
+                              libxl_device_vtpm *vtpm,
+                              const libxl_asyncop_how *ao_how)
+                              LIBXL_EXTERNAL_CALLERS_ONLY;
+
+libxl_device_vtpm *libxl_device_vtpm_list(libxl_ctx *ctx, uint32_t domid=
, int *num);
+int libxl_device_vtpm_getinfo(libxl_ctx *ctx, uint32_t domid,
+                               libxl_device_vtpm *vtpm, libxl_vtpminfo *=
vtpminfo);
+
 /* Keyboard */
 int libxl_device_vkb_add(libxl_ctx *ctx, uint32_t domid, libxl_device_vk=
b *vkb,
                          const libxl_asyncop_how *ao_how)
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
@@ -55,6 +55,10 @@ void libxl_domain_config_dispose(libxl_domain_config *=
d_config)
         libxl_device_vkb_dispose(&d_config->vkbs[i]);
     free(d_config->vkbs);
=20
+    for (i=3D0; i<d_config->num_vtpms; i++)
+       libxl_device_vtpm_dispose(&d_config->vtpms[i]);
+    free(d_config->vtpms);
+
     libxl_domain_create_info_dispose(&d_config->c_info);
     libxl_domain_build_info_dispose(&d_config->b_info);
 }
@@ -601,6 +605,8 @@ static void domcreate_bootloader_done(libxl__egc *egc=
,
 static void domcreate_launch_dm(libxl__egc *egc, libxl__multidev *aodevs=
,
                                 int ret);
=20
+static void domcreate_attach_vtpms(libxl__egc *egc, libxl__multidev *mul=
tidev,
+                                   int ret);
 static void domcreate_attach_pci(libxl__egc *egc, libxl__multidev *aodev=
s,
                                  int ret);
=20
@@ -1084,13 +1090,13 @@ static void domcreate_devmodel_started(libxl__egc=
 *egc,
     if (d_config->num_nics > 0) {
         /* Attach nics */
         libxl__multidev_begin(ao, &dcs->multidev);
-        dcs->multidev.callback =3D domcreate_attach_pci;
+        dcs->multidev.callback =3D domcreate_attach_vtpms;
         libxl__add_nics(egc, ao, domid, d_config, &dcs->multidev);
         libxl__multidev_prepared(egc, &dcs->multidev, 0);
         return;
     }
=20
-    domcreate_attach_pci(egc, &dcs->multidev, 0);
+    domcreate_attach_vtpms(egc, &dcs->multidev, 0);
     return;
=20
 error_out:
@@ -1098,6 +1104,36 @@ error_out:
     domcreate_complete(egc, dcs, ret);
 }
=20
+static void domcreate_attach_vtpms(libxl__egc *egc, libxl__multidev *mul=
tidev, int ret) {
+   libxl__domain_create_state *dcs =3D CONTAINER_OF(multidev, *dcs, mult=
idev);
+   STATE_AO_GC(dcs->ao);
+   int domid =3D dcs->guest_domid;
+
+   libxl_domain_config* const d_config =3D dcs->guest_config;
+
+   if(ret) {
+      LOG(ERROR, "unable to add nic devices");
+      goto error_out;
+   }
+
+    /* Plug nic interfaces */
+    if (d_config->num_vtpms > 0) {
+        /* Attach nics */
+        libxl__multidev_begin(ao, &dcs->multidev);
+        dcs->multidev.callback =3D domcreate_attach_pci;
+        libxl__add_vtpms(egc, ao, domid, d_config, &dcs->multidev);
+        libxl__multidev_prepared(egc, &dcs->multidev, 0);
+        return;
+    }
+
+   domcreate_attach_pci(egc, multidev, 0);
+   return;
+
+error_out:
+   assert(ret);
+   domcreate_complete(egc, dcs, ret);
+}
+
 static void domcreate_attach_pci(libxl__egc *egc, libxl__multidev *multi=
dev,
                                  int ret)
 {
@@ -1111,7 +1147,7 @@ static void domcreate_attach_pci(libxl__egc *egc, l=
ibxl__multidev *multidev,
     libxl_domain_config *const d_config =3D dcs->guest_config;
=20
     if (ret) {
-        LOG(ERROR, "unable to add nic devices");
+        LOG(ERROR, "unable to add vtpm devices");
         goto error_out;
     }
=20
diff --git a/tools/libxl/libxl_device.c b/tools/libxl/libxl_device.c
--- a/tools/libxl/libxl_device.c
+++ b/tools/libxl/libxl_device.c
@@ -515,6 +515,7 @@ void libxl__multidev_prepared(libxl__egc *egc,
=20
 DEFINE_DEVICES_ADD(disk)
 DEFINE_DEVICES_ADD(nic)
+DEFINE_DEVICES_ADD(vtpm)
=20
 #undef DEFINE_DEVICES_ADD
=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
@@ -954,6 +954,7 @@ _hidden int libxl__device_disk_setdefault(libxl__gc *=
gc,
                                           libxl_device_disk *disk);
 _hidden int libxl__device_nic_setdefault(libxl__gc *gc, libxl_device_nic=
 *nic,
                                          uint32_t domid);
+_hidden int libxl__device_vtpm_setdefault(libxl__gc *gc, libxl_device_vt=
pm *vtpm);
 _hidden int libxl__device_vfb_setdefault(libxl__gc *gc, libxl_device_vfb=
 *vfb);
 _hidden int libxl__device_vkb_setdefault(libxl__gc *gc, libxl_device_vkb=
 *vkb);
 _hidden int libxl__device_pci_setdefault(libxl__gc *gc, libxl_device_pci=
 *pci);
@@ -1975,6 +1976,10 @@ _hidden void libxl__device_nic_add(libxl__egc *egc=
, uint32_t domid,
                                    libxl_device_nic *nic,
                                    libxl__ao_device *aodev);
=20
+_hidden void libxl__device_vtpm_add(libxl__egc *egc, uint32_t domid,
+                                   libxl_device_vtpm *vtpm,
+                                   libxl__ao_device *aodev);
+
 /* Internal function to connect a vkb device */
 _hidden int libxl__device_vkb_add(libxl__gc *gc, uint32_t domid,
                                   libxl_device_vkb *vkb);
@@ -2407,6 +2412,10 @@ _hidden void libxl__add_nics(libxl__egc *egc, libx=
l__ao *ao, uint32_t domid,
                              libxl_domain_config *d_config,
                              libxl__multidev *multidev);
=20
+_hidden void libxl__add_vtpms(libxl__egc *egc, libxl__ao *ao, uint32_t d=
omid,
+                             libxl_domain_config *d_config,
+                             libxl__multidev *multidev);
+
 /*----- device model creation -----*/
=20
 /* First layer; wraps libxl__spawn_spawn. */
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
@@ -395,6 +395,12 @@ libxl_device_pci =3D Struct("device_pci", [
     ("permissive", bool),
     ])
=20
+libxl_device_vtpm =3D Struct("device_vtpm", [
+    ("backend_domid",    libxl_domid),
+    ("devid",            libxl_devid),
+    ("uuid",             libxl_uuid),
+])
+
 libxl_diskinfo =3D Struct("diskinfo", [
     ("backend", string),
     ("backend_id", uint32),
@@ -418,6 +424,18 @@ libxl_nicinfo =3D Struct("nicinfo", [
     ("rref_rx", integer),
     ], dir=3DDIR_OUT)
=20
+libxl_vtpminfo =3D Struct("vtpminfo", [
+    ("backend", string),
+    ("backend_id", uint32),
+    ("frontend", string),
+    ("frontend_id", uint32),
+    ("devid", libxl_devid),
+    ("state", integer),
+    ("evtch", integer),
+    ("rref", integer),
+    ("uuid", libxl_uuid),
+    ], dir=3DDIR_OUT)
+
 libxl_vcpuinfo =3D Struct("vcpuinfo", [
     ("vcpuid", uint32),
     ("cpu", uint32),
diff --git a/tools/libxl/libxl_types_internal.idl b/tools/libxl/libxl_typ=
es_internal.idl
--- a/tools/libxl/libxl_types_internal.idl
+++ b/tools/libxl/libxl_types_internal.idl
@@ -19,6 +19,7 @@ libxl__device_kind =3D Enumeration("device_kind", [
     (5, "VFB"),
     (6, "VKBD"),
     (7, "CONSOLE"),
+    (8, "VTPM"),
     ])
=20
 libxl__console_backend =3D Enumeration("console_backend", [
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
@@ -463,6 +463,35 @@ int libxl_pipe(libxl_ctx *ctx, int pipes[2])
     return 0;
 }
=20
+int libxl_uuid_to_device_vtpm(libxl_ctx *ctx, uint32_t domid,
+                            libxl_uuid* uuid, libxl_device_vtpm *vtpm)
+{
+    libxl_device_vtpm *vtpms;
+    int nb, i;
+    int rc;
+
+    vtpms =3D libxl_device_vtpm_list(ctx, domid, &nb);
+    if (!vtpms)
+        return ERROR_FAIL;
+
+    memset(vtpm, 0, sizeof (libxl_device_vtpm));
+    rc =3D 1;
+    for (i =3D 0; i < nb; ++i) {
+        if(!libxl_uuid_compare(uuid, &vtpms[i].uuid)) {
+            vtpm->backend_domid =3D vtpms[i].backend_domid;
+            vtpm->devid =3D vtpms[i].devid;
+            libxl_uuid_copy(&vtpm->uuid, &vtpms[i].uuid);
+            rc =3D 0;
+            break;
+        }
+    }
+
+    for (i=3D0; i<nb; i++)
+        libxl_device_vtpm_dispose(&vtpms[i]);
+    free(vtpms);
+    return rc;
+}
+
 int libxl_mac_to_device_nic(libxl_ctx *ctx, uint32_t domid,
                             const char *mac, libxl_device_nic *nic)
 {
diff --git a/tools/libxl/libxl_utils.h b/tools/libxl/libxl_utils.h
--- a/tools/libxl/libxl_utils.h
+++ b/tools/libxl/libxl_utils.h
@@ -64,6 +64,11 @@ int libxl_devid_to_device_nic(libxl_ctx *ctx, uint32_t=
 domid, int devid,
 int libxl_vdev_to_device_disk(libxl_ctx *ctx, uint32_t domid, const char=
 *vdev,
                                libxl_device_disk *disk);
=20
+int libxl_uuid_to_device_vtpm(libxl_ctx *ctx, uint32_t domid,
+                               libxl_uuid *uuid, libxl_device_vtpm *vtpm=
);
+int libxl_devid_to_device_vtpm(libxl_ctx *ctx, uint32_t domid,
+                               int devid, libxl_device_vtpm *vtpm);
+
 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. */
diff --git a/tools/libxl/xl.h b/tools/libxl/xl.h
--- a/tools/libxl/xl.h
+++ b/tools/libxl/xl.h
@@ -79,6 +79,9 @@ int main_networkdetach(int argc, char **argv);
 int main_blockattach(int argc, char **argv);
 int main_blocklist(int argc, char **argv);
 int main_blockdetach(int argc, char **argv);
+int main_vtpmattach(int argc, char **argv);
+int main_vtpmlist(int argc, char **argv);
+int main_vtpmdetach(int argc, char **argv);
 int main_uptime(int argc, char **argv);
 int main_tmem_list(int argc, char **argv);
 int main_tmem_freeze(int argc, char **argv);
diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -573,7 +573,7 @@ static void parse_config_data(const char *config_sour=
ce,
     const char *buf;
     long l;
     XLU_Config *config;
-    XLU_ConfigList *cpus, *vbds, *nics, *pcis, *cvfbs, *cpuids;
+    XLU_ConfigList *cpus, *vbds, *nics, *pcis, *cvfbs, *cpuids, *vtpms;
     XLU_ConfigList *ioports, *irqs, *iomem;
     int num_ioports, num_irqs, num_iomem;
     int pci_power_mgmt =3D 0;
@@ -1045,6 +1045,47 @@ static void parse_config_data(const char *config_s=
ource,
         }
     }
=20
+    if (!xlu_cfg_get_list(config, "vtpm", &vtpms, 0, 0)) {
+        d_config->num_vtpms =3D 0;
+        d_config->vtpms =3D NULL;
+        while ((buf =3D xlu_cfg_get_listitem (vtpms, d_config->num_vtpms=
)) !=3D NULL) {
+            libxl_device_vtpm *vtpm;
+            char * buf2 =3D strdup(buf);
+            char *p, *p2;
+
+            d_config->vtpms =3D (libxl_device_vtpm *) realloc(d_config->=
vtpms, sizeof(libxl_device_vtpm) * (d_config->num_vtpms+1));
+            vtpm =3D d_config->vtpms + d_config->num_vtpms;
+            libxl_device_vtpm_init(vtpm);
+            vtpm->devid =3D d_config->num_vtpms;
+
+            p =3D strtok(buf2, ",");
+            if (!p)
+                goto skip_vtpm;
+            do {
+                while(*p =3D=3D ' ')
+                    ++p;
+                if ((p2 =3D strchr(p, '=3D')) =3D=3D NULL)
+                    break;
+                *p2 =3D '\0';
+                if (!strcmp(p, "backend")) {
+                    if(domain_qualifier_to_domid(p2 + 1, &(vtpm->backend=
_domid), 0))
+                    {
+                        fprintf(stderr, "Specified backend domain does n=
ot exist, defaulting to Dom0\n");
+                        vtpm->backend_domid =3D 0;
+                    }
+                } else if(!strcmp(p, "uuid")) {
+                    if( libxl_uuid_from_string(&vtpm->uuid, p2 + 1) ) {
+                        fprintf(stderr, "Failed to parse vtpm UUID: %s\n=
", p2 + 1);
+                        exit(1);
+                    }
+                }
+            } while ((p =3D strtok(NULL, ",")) !=3D NULL);
+skip_vtpm:
+            free(buf2);
+            d_config->num_vtpms++;
+        }
+    }
+
     if (!xlu_cfg_get_list (config, "vif", &nics, 0, 0)) {
         d_config->num_nics =3D 0;
         d_config->nics =3D NULL;
@@ -1070,7 +1111,7 @@ static void parse_config_data(const char *config_so=
urce,
=20
             p =3D strtok(buf2, ",");
             if (!p)
-                goto skip;
+                goto skip_nic;
             do {
                 while (*p =3D=3D ' ')
                     p++;
@@ -1134,7 +1175,7 @@ static void parse_config_data(const char *config_so=
urce,
                     fprintf(stderr, "the accel parameter for vifs is cur=
rently not supported\n");
                 }
             } while ((p =3D strtok(NULL, ",")) !=3D NULL);
-skip:
+skip_nic:
             free(buf2);
             d_config->num_nics++;
         }
@@ -5570,6 +5611,131 @@ int main_blockdetach(int argc, char **argv)
     return rc;
 }
=20
+int main_vtpmattach(int argc, char **argv)
+{
+    int opt;
+    libxl_device_vtpm vtpm;
+    char *oparg;
+    unsigned int val;
+    uint32_t domid;
+
+    if ((opt =3D def_getopt(argc, argv, "", "vtpm-attach", 1)) !=3D -1)
+        return opt;
+
+    if (domain_qualifier_to_domid(argv[optind], &domid, 0) < 0) {
+        fprintf(stderr, "%s is an invalid domain identifier\n", argv[opt=
ind]);
+        return 1;
+    }
+    ++optind;
+
+    libxl_device_vtpm_init(&vtpm);
+    for (argv +=3D optind, argc -=3D optind; argc > 0; ++argv, --argc) {=

+        if (MATCH_OPTION("uuid", *argv, oparg)) {
+            if(libxl_uuid_from_string(&(vtpm.uuid), oparg)) {
+                fprintf(stderr, "Invalid uuid specified (%s)\n", oparg);=

+                return 1;
+            }
+        } else if (MATCH_OPTION("backend", *argv, oparg)) {
+            if(domain_qualifier_to_domid(oparg, &val, 0)) {
+                fprintf(stderr, "Specified backend domain does not exist=
, defaulting to Dom0\n");
+                val =3D 0;
+            }
+            vtpm.backend_domid =3D val;
+        } else {
+            fprintf(stderr, "unrecognized argument `%s'\n", *argv);
+            return 1;
+        }
+    }
+
+    if(dryrun_only) {
+       char* json =3D libxl_device_vtpm_to_json(ctx, &vtpm);
+       printf("vtpm: %s\n", json);
+       free(json);
+       libxl_device_vtpm_dispose(&vtpm);
+       if (ferror(stdout) || fflush(stdout)) { perror("stdout"); exit(-1=
); }
+       return 0;
+    }
+
+    if (libxl_device_vtpm_add(ctx, domid, &vtpm, 0)) {
+        fprintf(stderr, "libxl_device_vtpm_add failed.\n");
+        return 1;
+    }
+    libxl_device_vtpm_dispose(&vtpm);
+    return 0;
+}
+
+int main_vtpmlist(int argc, char **argv)
+{
+    int opt;
+    libxl_device_vtpm *vtpms;
+    libxl_vtpminfo vtpminfo;
+    int nb, i;
+
+    if ((opt =3D def_getopt(argc, argv, "", "vtpm-list", 1)) !=3D -1)
+        return opt;
+
+    /*      Idx  BE   UUID   Hdl  Sta  evch rref  BE-path */
+    printf("%-3s %-2s %-36s %-6s %-5s %-6s %-5s %-10s\n",
+           "Idx", "BE", "Uuid", "handle", "state", "evt-ch", "ring-ref",=
 "BE-path");
+    for (argv +=3D optind, argc -=3D optind; argc > 0; --argc, ++argv) {=

+        uint32_t domid;
+        if (domain_qualifier_to_domid(*argv, &domid, 0) < 0) {
+            fprintf(stderr, "%s is an invalid domain identifier\n", *arg=
v);
+            continue;
+        }
+        if (!(vtpms =3D libxl_device_vtpm_list(ctx, domid, &nb))) {
+            continue;
+        }
+        for (i =3D 0; i < nb; ++i) {
+           if(!libxl_device_vtpm_getinfo(ctx, domid, &vtpms[i], &vtpminf=
o)) {
+              /*      Idx  BE     UUID             Hdl Sta evch rref BE-=
path*/
+              printf("%-3d %-2d " LIBXL_UUID_FMT " %6d %5d %6d %8d %-30s=
\n",
+                    vtpminfo.devid, vtpminfo.backend_id,
+                    LIBXL_UUID_BYTES(vtpminfo.uuid),
+                    vtpminfo.devid, vtpminfo.state, vtpminfo.evtch,
+                    vtpminfo.rref, vtpminfo.backend);
+
+              libxl_vtpminfo_dispose(&vtpminfo);
+           }
+           libxl_device_vtpm_dispose(&vtpms[i]);
+        }
+        free(vtpms);
+    }
+    return 0;
+}
+
+int main_vtpmdetach(int argc, char **argv)
+{
+    uint32_t domid;
+    int opt, rc=3D0;
+    libxl_device_vtpm vtpm;
+    libxl_uuid uuid;
+
+    if ((opt =3D def_getopt(argc, argv, "", "vtpm-detach", 2)) !=3D -1)
+        return opt;
+
+    domid =3D find_domain(argv[optind]);
+
+    if ( libxl_uuid_from_string(&uuid, argv[optind+1])) {
+        if (libxl_devid_to_device_vtpm(ctx, domid, atoi(argv[optind+1]),=
 &vtpm)) {
+            fprintf(stderr, "Unknown device %s.\n", argv[optind+1]);
+            return 1;
+        }
+    } else {
+        if (libxl_uuid_to_device_vtpm(ctx, domid, &uuid, &vtpm)) {
+            fprintf(stderr, "Unknown device %s.\n", argv[optind+1]);
+            return 1;
+        }
+    }
+    rc =3D libxl_device_vtpm_remove(ctx, domid, &vtpm, 0);
+    if (rc) {
+        fprintf(stderr, "libxl_device_vtpm_remove failed.\n");
+    }
+    libxl_device_vtpm_dispose(&vtpm);
+    return rc;
+}
+
+
 static char *uptime_to_string(unsigned long uptime, int short_mode)
 {
     int sec, min, hour, day;
diff --git a/tools/libxl/xl_cmdtable.c b/tools/libxl/xl_cmdtable.c
--- a/tools/libxl/xl_cmdtable.c
+++ b/tools/libxl/xl_cmdtable.c
@@ -338,6 +338,21 @@ struct cmd_spec cmd_table[] =3D {
       "Destroy a domain's virtual block device",
       "<Domain> <DevId>",
     },
+    { "vtpm-attach",
+      &main_vtpmattach, 0, 1,
+      "Create a new virtual TPM device",
+      "<Domain> [uuid=3D<uuid>] [backend=3D<BackDomain>]",
+    },
+    { "vtpm-list",
+      &main_vtpmlist, 0, 0,
+      "List virtual TPM devices for a domain",
+      "<Domain(s)>",
+    },
+    { "vtpm-detach",
+      &main_vtpmdetach, 0, 1,
+      "Destroy a domain's virtual TPM device",
+      "<Domain> <DevId|uuid>",
+    },
     { "uptime",
       &main_uptime, 0, 0,
       "Print uptime for all/some domains",



--------------ms060907090204020808090605
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIDyjCC
A8YwggMvoAMCAQICBD/xyf0wDQYJKoZIhvcNAQEFBQAwLzELMAkGA1UEBhMCVVMxDzANBgNV
BAoTBkpIVUFQTDEPMA0GA1UECxMGQklTRENBMB4XDTEwMDYxMTE4MjIwNloXDTEzMDYxMTE4
NTIwNlowZjELMAkGA1UEBhMCVVMxDzANBgNVBAoTBkpIVUFQTDEPMA0GA1UECxMGUGVvcGxl
MTUwFgYDVQQLEw9WUE5Hcm91cC1CSVNEQ0EwGwYDVQQDExRNYXR0aGV3IEUgRmlvcmF2YW50
ZTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAnpbwVSP6o1Nb5lcW7dd3yTo9iBJdi7qz
4nANOMFPK7JOy5npKN1iiousl28U/scUJES55gPwAWYJK3uVyQAsA4adgDKi5DoD1UHDQEwp
bY7iHLJeq0NPr4BqYNqnCFPbE6HC8zSJrr4qKn+gVUQT39SIFqdiIPJwZL8FYTRQ/zsCAwEA
AaOCAbYwggGyMAsGA1UdDwQEAwIHgDArBgNVHRAEJDAigA8yMDEwMDYxMTE4MjIwNlqBDzIw
MTIwNzE3MjI1MjA2WjAbBg0rBgEEAbMlCwMBAQEBBAoWCGZpb3JhbWUxMBsGDSsGAQQBsyUL
AwEBAQIEChIIMDAxMDQyNjEwWAYJYIZIAYb6ax4BBEsMSVRoZSBwcml2YXRlIGtleSBjb3Jy
ZXNwb25kaW5nIHRvIHRoaXMgY2VydGlmaWNhdGUgbWF5IGhhdmUgYmVlbiBleHBvcnRlZC4w
KAYDVR0RBCEwH4EdTWF0dGhldy5GaW9yYXZhbnRlQGpodWFwbC5lZHUwUgYDVR0fBEswSTBH
oEWgQ6RBMD8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJU0RD
QTEOMAwGA1UEAxMFQ1JMNTYwHwYDVR0jBBgwFoAUCDUpmxH52EU2CyWmF2EJMB1yqeswHQYD
VR0OBBYEFO6LYxg6r9wHZ+zdQtBHn1dZ/YTNMAkGA1UdEwQCMAAwGQYJKoZIhvZ9B0EABAww
ChsEVjcuMQMCBLAwDQYJKoZIhvcNAQEFBQADgYEAJO9HQh4YNChVLzuZqK5ARJARD8JoujGZ
fdo75quvg2jXFQe2sEjvLnxJZgm/pv8fdZakq48CWwjYHKuvIp7sDjTEsQfo+y7SpN/N2NvJ
WU5SqfK1VgYtNLRRoGJUB5Q1aZ+Dg95g3kqpyfpUMISJL8IKVLtJVfN4fggFVUYZ9wwxggGr
MIIBpwIBATA3MC8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJ
U0RDQQIEP/HJ/TAJBgUrDgMCGgUAoIHLMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ
KoZIhvcNAQkFMQ8XDTEyMDkyMTE5MzYyM1owIwYJKoZIhvcNAQkEMRYEFCgLS5NZS4NhsqAc
n5ObiAzF0zSwMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAK
BggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI
KoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEgYCM6pkhpJy6Z+rRx2OAM7X5ax28MYST40wQ
eyqcS9sJ2wkkgazhiMe5QsK0PCuGYqSkSDLSHcXxhtM+S1qG9yeLVxJc+mX2wH6H/lyHMjJi
9qyz3vkqdsdK4oEsOLv4qo36IR5h1IFZTpzLlFZio7wbUMYldUx7Hxs8zrR6fEUD8QAAAAAA
AA==
--------------ms060907090204020808090605--


--===============4087893607776326327==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============4087893607776326327==--


From xen-devel-bounces@lists.xen.org Fri Sep 21 20:17:10 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Sep 2012 20:17:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TF9eY-0005Di-SX; Fri, 21 Sep 2012 20:16: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 1TF9eX-0005Da-Ld
	for xen-devel@lists.xen.org; Fri, 21 Sep 2012 20:16:45 +0000
Received: from [85.158.139.211:55943] by server-12.bemta-5.messagelabs.com id
	98/53-30479-D2BCC505; Fri, 21 Sep 2012 20:16:45 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-6.tower-206.messagelabs.com!1348258602!19509869!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzU2MzI0\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28148 invoked from network); 21 Sep 2012 20:16:44 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-6.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 21 Sep 2012 20:16:44 -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 q8LKGT3s009109
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 21 Sep 2012 20:16:30 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q8LKGS7g006747
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 21 Sep 2012 20:16:28 GMT
Received: from abhmt119.oracle.com (abhmt119.oracle.com [141.146.116.71])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q8LKGRVG017499; Fri, 21 Sep 2012 15:16:27 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 21 Sep 2012 13:16:27 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 2AFF5402EC; Fri, 21 Sep 2012 16:05:21 -0400 (EDT)
Date: Fri, 21 Sep 2012 16:05:21 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Andres Lagar-Cavilla <andres.lagarcavilla@gmail.com>
Message-ID: <20120921200521.GA20408@phenom.dumpdata.com>
References: <1347632819-13684-1-git-send-email-andres@lagarcavilla.org>
	<1347869865.14977.15.camel@zakaz.uk.xensource.com>
	<5B5132A4-93B2-41D0-B1A6-048810565DB5@gridcentric.ca>
	<20120921185258.GA4931@phenom.dumpdata.com>
	<ACFBD23A-6B32-47F3-B71A-37F4557FDE47@gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <ACFBD23A-6B32-47F3-B71A-37F4557FDE47@gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: Ian Campbell <Ian.Campbell@citrix.com>,
	Andres Lagar-Cavilla <andreslc@gridcentric.ca>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	xen-devel <xen-devel@lists.xen.org>,
	David Vrabel <david.vrabel@citrix.com>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	David Miller <davem@davemloft.net>,
	Andres Lagar-Cavilla <andres@lagarcavilla.org>
Subject: Re: [Xen-devel] [PATCH] Xen backend support for paged out grant
	targets V4.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gRnJpLCBTZXAgMjEsIDIwMTIgYXQgMDM6MzA6MDFQTSAtMDQwMCwgQW5kcmVzIExhZ2FyLUNh
dmlsbGEgd3JvdGU6Cj4gT24gU2VwIDIxLCAyMDEyLCBhdCAyOjUyIFBNLCBLb25yYWQgUnplc3p1
dGVrIFdpbGsgd3JvdGU6Cj4gCj4gPiBPbiBNb24sIFNlcCAxNywgMjAxMiBhdCAwNToyOToyNEFN
IC0wNDAwLCBBbmRyZXMgTGFnYXItQ2F2aWxsYSB3cm90ZToKPiA+PiBPbiBTZXAgMTcsIDIwMTIs
IGF0IDQ6MTcgQU0sIElhbiBDYW1wYmVsbCB3cm90ZToKPiA+PiAKPiA+Pj4gKEkgdGhpbmsgSSBm
b3Jnb3QgdG8gaGl0IHNlbmQgb24gdGhpcyBvbiBGcmlkYXksIHNvcnJ5LiBBbHNvCj4gPj4+IHMv
eGVuLmxpc3RzLm9yZy9saXN0cy54ZW4ub3JnIGluIHRoZSBDQyBsaW5l4oCmKQo+ID4+IEknbSBv
biBhIHJvbGwgaGVyZeKApgo+ID4+IAo+ID4+PiAKPiA+Pj4gT24gRnJpLCAyMDEyLTA5LTE0IGF0
IDE1OjI2ICswMTAwLCBBbmRyZXMgTGFnYXItQ2F2aWxsYSB3cm90ZToKPiA+Pj4+IFNpbmNlIFhl
bi00LjIsIGh2bSBkb21haW5zIG1heSBoYXZlIHBvcnRpb25zIG9mIHRoZWlyIG1lbW9yeSBwYWdl
ZCBvdXQuIFdoZW4gYQo+ID4+Pj4gZm9yZWlnbiBkb21haW4gKHN1Y2ggYXMgZG9tMCkgYXR0ZW1w
dHMgdG8gbWFwIHRoZXNlIGZyYW1lcywgdGhlIG1hcCB3aWxsCj4gPj4+PiBpbml0aWFsbHkgZmFp
bC4gVGhlIGh5cGVydmlzb3IgcmV0dXJucyBhIHN1aXRhYmxlIGVycm5vLCBhbmQga2lja3MgYW4K
PiA+Pj4+IGFzeW5jaHJvbm91cyBwYWdlLWluIG9wZXJhdGlvbiBjYXJyaWVkIG91dCBieSBhIGhl
bHBlci4gVGhlIGZvcmVpZ24gZG9tYWluIGlzCj4gPj4+PiBleHBlY3RlZCB0byByZXRyeSB0aGUg
bWFwcGluZyBvcGVyYXRpb24gdW50aWwgaXQgZXZlbnR1YWxseSBzdWNjZWVkcy4gVGhlCj4gPj4+
PiBmb3JlaWduIGRvbWFpbiBpcyBub3QgcHV0IHRvIHNsZWVwIGJlY2F1c2UgaXRzZWxmIGNvdWxk
IGJlIHRoZSBvbmUgcnVubmluZyB0aGUKPiA+Pj4+IHBhZ2VyIGFzc2lzdCAodHlwaWNhbCBzY2Vu
YXJpbyBmb3IgZG9tMCkuCj4gPj4+PiAKPiA+Pj4+IFRoaXMgcGF0Y2ggYWRkcyBzdXBwb3J0IGZv
ciB0aGlzIG1lY2hhbmlzbSBmb3IgYmFja2VuZCBkcml2ZXJzIHVzaW5nIGdyYW50Cj4gPj4+PiBt
YXBwaW5nIGFuZCBjb3B5aW5nIG9wZXJhdGlvbnMuIFNwZWNpZmljYWxseSwgdGhpcyBjb3ZlcnMg
dGhlIGJsa2JhY2sgYW5kCj4gPj4+PiBnbnRkZXYgZHJpdmVycyAod2hpY2ggbWFwIGZvcmVnaW4g
Z3JhbnRzKSwgYW5kIHRoZSBuZXRiYWNrIGRyaXZlciAod2hpY2ggY29waWVzCj4gPj4+IAo+ID4+
PiAgICAgICAgICAgICAgICAgICAgICAgICAgZm9yZWlnbgo+ID4+PiAKPiA+Pj4+IGZvcmVpZ24g
Z3JhbnRzKS4KPiA+Pj4+IAo+ID4+Pj4gKiBBZGQgYSByZXRyeSBtZXRob2QgZm9yIGdyYW50cyB0
aGF0IGZhaWwgd2l0aCBHTlRTVF9lYWdhaW4gKGkuZS4gYmVjYXVzZSB0aGUKPiA+Pj4+IHRhcmdl
dCBmb3JlZ2luIGZyYW1lIGlzIHBhZ2VkIG91dCkuCj4gPj4+IAo+ID4+PiAgICAgICAgIGZvcmVp
Z24KPiA+Pj4gCj4gPj4+PiAqIEluc2VydCBob29rcyB3aXRoIGFwcHJvcHJpYXRlIHdyYXBwZXJz
IGluIHRoZSBhZm9yZW1lbnRpb25lZCBkcml2ZXJzLgo+ID4+Pj4gCj4gPj4+PiBUaGUgcmV0cnkg
bG9vcCBpcyBvbmx5IGludm9rZWQgaWYgdGhlIGdyYW50IG9wZXJhdGlvbiBzdGF0dXMgaXMgR05U
U1RfZWFnYWluLgo+ID4+Pj4gSXQgZ3VhcmFudGVlcyB0byBsZWF2ZSBhIG5ldyBzdGF0dXMgY29k
ZSBkaWZmZXJlbnQgZnJvbSBHTlRTVF9lYWdhaW4uIEFueSBvdGhlcgo+ID4+Pj4gc3RhdHVzIGNv
ZGUgcmVzdWx0cyBpbiBpZGVudGljYWwgY29kZSBleGVjdXRpb24gYXMgYmVmb3JlLgo+ID4+Pj4g
Cj4gPj4+PiBUaGUgcmV0cnkgbG9vcCBwZXJmb3JtcyAyNTYgYXR0ZW1wdHMgd2l0aCBpbmNyZWFz
aW5nIHRpbWUgaW50ZXJ2YWxzIHRocm91Z2ggYQo+ID4+Pj4gMzIgc2Vjb25kIHBlcmlvZC4gSXQg
dXNlcyBtc2xlZXAgdG8geWllbGQgd2hpbGUgd2FpdGluZyBmb3IgdGhlIG5leHQgcmV0cnkuCj4g
Pj4+IFsuLi5dCj4gPj4+PiBTaWduZWQtb2ZmLWJ5OiBBbmRyZXMgTGFnYXItQ2F2aWxsYSA8YW5k
cmVzQGxhZ2FyY2F2aWxsYS5vcmc+Cj4gPj4+IAo+ID4+PiBBY2tlZC1ieTogSWFuIENhbXBiZWxs
IDxpYW4uY2FtcGJlbGxAY2l0cml4LmNvbT4KPiA+Pj4gCj4gPj4+IFNpbmNlIHRoaXMgaXMgbW9y
ZSBhYm91dCBncmFudCB0YWJsZXMgdGhhbiBuZXRiYWNrIHRoaXMgc2hvdWxkIHByb2JhYmx5Cj4g
Pj4+IGdvIHZpYSBLb25yYWQgcmF0aGVyIHRoYW4gRGF2ZSwgaXMgdGhhdCBPSyB3aXRoIHlvdSBE
YXZlPwo+ID4+IAo+ID4+IElmIHRoYXQgaXMgdGhlIGNhc2UgaG9wZWZ1bGx5IEtvbnJhZCBjYW4g
ZGVhbCB3aXRoIHRoZSB0d28gdHlwb3M/IE90aGVyd2lzZSBoYXBweSB0byByZS1zcGluIHRoZSBw
YXRjaC4KPiA+IAo+ID4gU28gd2l0aCB0aGlzIHBhdGNoIHdoZW4gSSBsYXVuY2ggYW4gUFZIVk0g
Z3Vlc3Qgb24gWGVuIDQuMSBJIGdldCB0aGlzCj4gPiBpbiB0aGUgaW5pdGlhbCBkb21haW4gYW5k
IHRoZSBndWVzdCBpcyBjcmFzaGVkOgo+ID4gCj4gPiBbICAyNjEuOTI3MjE4XSBwcml2Y21kX2Zh
dWx0OiB2bWE9ZmZmZjg4MDAyYTMxZGNlOCA3ZjRlZGMwOTUwMDAtN2Y0ZWRjMTk1MDAwLCBwZ29m
Zj1jOCwgdXY9MDAwMDdmNGVkYzE1ZDAwMAo+IAo+IFdpdGggdGhpcyBwYXRjaD8gT3Igd2l0aCB0
aGUgbW1hcGJhdGNoIHYyPyBUaGlzIGlzIGEgcGFnZSBmYXVsdCBpbiBhIGZvcmVpZ24tbWFwcGVk
IFZNQS4gTm90IHRvdWNoZWQgYnkgdGhpcyBncmFudCBiYWNrZW5kIHBhdGNoIHdlIGFyZSB0YWxr
aW5nIGFib3V0LgoKVGhpcyBwYXRjaC4gQnV0IEkgYWxzbyBoYWQgYSBtb2RpZmllZCBibGtiYWNr
LiBTbyBsZXQgbWUgZG91YmxlIGNoZWNrCnRoYXQgaXQgaXMgbm90IHRoZSBwZXJzaXN0ZW50IGdy
YW50cyBhbmQgdGhpcyBwYXRjaCBkb2luZyBzb21ldGhpbmcgbmF1Z2h0eS4KCj4gCj4gRG9lcyB0
aGUgaHlwZXJ2aXNvciBkdW1wIGFueXRoaW5nIHRvIGl0cyBjb25zb2xlPwo+IAo+IEF0IHdoaWNo
IHBvaW50IGR1cmluZyB4Y19odm1fYnVpbGQgZG8geW91IHNlZSB0aGlzPyAob3IgZWxzZXdoZXJl
IGluIHRoZSB0b29sc3RhY2s/KQoKTm8gaWRlYS4gRGlkbid0IGV4YW1pbmUgdGhhdCBtdWNoLgoK
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVs
IG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwOi8vbGlzdHMueGVuLm9y
Zy94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xen.org Fri Sep 21 20:17:10 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Sep 2012 20:17:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TF9eY-0005Di-SX; Fri, 21 Sep 2012 20:16: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 1TF9eX-0005Da-Ld
	for xen-devel@lists.xen.org; Fri, 21 Sep 2012 20:16:45 +0000
Received: from [85.158.139.211:55943] by server-12.bemta-5.messagelabs.com id
	98/53-30479-D2BCC505; Fri, 21 Sep 2012 20:16:45 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-6.tower-206.messagelabs.com!1348258602!19509869!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzU2MzI0\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28148 invoked from network); 21 Sep 2012 20:16:44 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-6.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 21 Sep 2012 20:16:44 -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 q8LKGT3s009109
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 21 Sep 2012 20:16:30 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q8LKGS7g006747
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 21 Sep 2012 20:16:28 GMT
Received: from abhmt119.oracle.com (abhmt119.oracle.com [141.146.116.71])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q8LKGRVG017499; Fri, 21 Sep 2012 15:16:27 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 21 Sep 2012 13:16:27 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 2AFF5402EC; Fri, 21 Sep 2012 16:05:21 -0400 (EDT)
Date: Fri, 21 Sep 2012 16:05:21 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Andres Lagar-Cavilla <andres.lagarcavilla@gmail.com>
Message-ID: <20120921200521.GA20408@phenom.dumpdata.com>
References: <1347632819-13684-1-git-send-email-andres@lagarcavilla.org>
	<1347869865.14977.15.camel@zakaz.uk.xensource.com>
	<5B5132A4-93B2-41D0-B1A6-048810565DB5@gridcentric.ca>
	<20120921185258.GA4931@phenom.dumpdata.com>
	<ACFBD23A-6B32-47F3-B71A-37F4557FDE47@gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <ACFBD23A-6B32-47F3-B71A-37F4557FDE47@gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: Ian Campbell <Ian.Campbell@citrix.com>,
	Andres Lagar-Cavilla <andreslc@gridcentric.ca>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	xen-devel <xen-devel@lists.xen.org>,
	David Vrabel <david.vrabel@citrix.com>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	David Miller <davem@davemloft.net>,
	Andres Lagar-Cavilla <andres@lagarcavilla.org>
Subject: Re: [Xen-devel] [PATCH] Xen backend support for paged out grant
	targets V4.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gRnJpLCBTZXAgMjEsIDIwMTIgYXQgMDM6MzA6MDFQTSAtMDQwMCwgQW5kcmVzIExhZ2FyLUNh
dmlsbGEgd3JvdGU6Cj4gT24gU2VwIDIxLCAyMDEyLCBhdCAyOjUyIFBNLCBLb25yYWQgUnplc3p1
dGVrIFdpbGsgd3JvdGU6Cj4gCj4gPiBPbiBNb24sIFNlcCAxNywgMjAxMiBhdCAwNToyOToyNEFN
IC0wNDAwLCBBbmRyZXMgTGFnYXItQ2F2aWxsYSB3cm90ZToKPiA+PiBPbiBTZXAgMTcsIDIwMTIs
IGF0IDQ6MTcgQU0sIElhbiBDYW1wYmVsbCB3cm90ZToKPiA+PiAKPiA+Pj4gKEkgdGhpbmsgSSBm
b3Jnb3QgdG8gaGl0IHNlbmQgb24gdGhpcyBvbiBGcmlkYXksIHNvcnJ5LiBBbHNvCj4gPj4+IHMv
eGVuLmxpc3RzLm9yZy9saXN0cy54ZW4ub3JnIGluIHRoZSBDQyBsaW5l4oCmKQo+ID4+IEknbSBv
biBhIHJvbGwgaGVyZeKApgo+ID4+IAo+ID4+PiAKPiA+Pj4gT24gRnJpLCAyMDEyLTA5LTE0IGF0
IDE1OjI2ICswMTAwLCBBbmRyZXMgTGFnYXItQ2F2aWxsYSB3cm90ZToKPiA+Pj4+IFNpbmNlIFhl
bi00LjIsIGh2bSBkb21haW5zIG1heSBoYXZlIHBvcnRpb25zIG9mIHRoZWlyIG1lbW9yeSBwYWdl
ZCBvdXQuIFdoZW4gYQo+ID4+Pj4gZm9yZWlnbiBkb21haW4gKHN1Y2ggYXMgZG9tMCkgYXR0ZW1w
dHMgdG8gbWFwIHRoZXNlIGZyYW1lcywgdGhlIG1hcCB3aWxsCj4gPj4+PiBpbml0aWFsbHkgZmFp
bC4gVGhlIGh5cGVydmlzb3IgcmV0dXJucyBhIHN1aXRhYmxlIGVycm5vLCBhbmQga2lja3MgYW4K
PiA+Pj4+IGFzeW5jaHJvbm91cyBwYWdlLWluIG9wZXJhdGlvbiBjYXJyaWVkIG91dCBieSBhIGhl
bHBlci4gVGhlIGZvcmVpZ24gZG9tYWluIGlzCj4gPj4+PiBleHBlY3RlZCB0byByZXRyeSB0aGUg
bWFwcGluZyBvcGVyYXRpb24gdW50aWwgaXQgZXZlbnR1YWxseSBzdWNjZWVkcy4gVGhlCj4gPj4+
PiBmb3JlaWduIGRvbWFpbiBpcyBub3QgcHV0IHRvIHNsZWVwIGJlY2F1c2UgaXRzZWxmIGNvdWxk
IGJlIHRoZSBvbmUgcnVubmluZyB0aGUKPiA+Pj4+IHBhZ2VyIGFzc2lzdCAodHlwaWNhbCBzY2Vu
YXJpbyBmb3IgZG9tMCkuCj4gPj4+PiAKPiA+Pj4+IFRoaXMgcGF0Y2ggYWRkcyBzdXBwb3J0IGZv
ciB0aGlzIG1lY2hhbmlzbSBmb3IgYmFja2VuZCBkcml2ZXJzIHVzaW5nIGdyYW50Cj4gPj4+PiBt
YXBwaW5nIGFuZCBjb3B5aW5nIG9wZXJhdGlvbnMuIFNwZWNpZmljYWxseSwgdGhpcyBjb3ZlcnMg
dGhlIGJsa2JhY2sgYW5kCj4gPj4+PiBnbnRkZXYgZHJpdmVycyAod2hpY2ggbWFwIGZvcmVnaW4g
Z3JhbnRzKSwgYW5kIHRoZSBuZXRiYWNrIGRyaXZlciAod2hpY2ggY29waWVzCj4gPj4+IAo+ID4+
PiAgICAgICAgICAgICAgICAgICAgICAgICAgZm9yZWlnbgo+ID4+PiAKPiA+Pj4+IGZvcmVpZ24g
Z3JhbnRzKS4KPiA+Pj4+IAo+ID4+Pj4gKiBBZGQgYSByZXRyeSBtZXRob2QgZm9yIGdyYW50cyB0
aGF0IGZhaWwgd2l0aCBHTlRTVF9lYWdhaW4gKGkuZS4gYmVjYXVzZSB0aGUKPiA+Pj4+IHRhcmdl
dCBmb3JlZ2luIGZyYW1lIGlzIHBhZ2VkIG91dCkuCj4gPj4+IAo+ID4+PiAgICAgICAgIGZvcmVp
Z24KPiA+Pj4gCj4gPj4+PiAqIEluc2VydCBob29rcyB3aXRoIGFwcHJvcHJpYXRlIHdyYXBwZXJz
IGluIHRoZSBhZm9yZW1lbnRpb25lZCBkcml2ZXJzLgo+ID4+Pj4gCj4gPj4+PiBUaGUgcmV0cnkg
bG9vcCBpcyBvbmx5IGludm9rZWQgaWYgdGhlIGdyYW50IG9wZXJhdGlvbiBzdGF0dXMgaXMgR05U
U1RfZWFnYWluLgo+ID4+Pj4gSXQgZ3VhcmFudGVlcyB0byBsZWF2ZSBhIG5ldyBzdGF0dXMgY29k
ZSBkaWZmZXJlbnQgZnJvbSBHTlRTVF9lYWdhaW4uIEFueSBvdGhlcgo+ID4+Pj4gc3RhdHVzIGNv
ZGUgcmVzdWx0cyBpbiBpZGVudGljYWwgY29kZSBleGVjdXRpb24gYXMgYmVmb3JlLgo+ID4+Pj4g
Cj4gPj4+PiBUaGUgcmV0cnkgbG9vcCBwZXJmb3JtcyAyNTYgYXR0ZW1wdHMgd2l0aCBpbmNyZWFz
aW5nIHRpbWUgaW50ZXJ2YWxzIHRocm91Z2ggYQo+ID4+Pj4gMzIgc2Vjb25kIHBlcmlvZC4gSXQg
dXNlcyBtc2xlZXAgdG8geWllbGQgd2hpbGUgd2FpdGluZyBmb3IgdGhlIG5leHQgcmV0cnkuCj4g
Pj4+IFsuLi5dCj4gPj4+PiBTaWduZWQtb2ZmLWJ5OiBBbmRyZXMgTGFnYXItQ2F2aWxsYSA8YW5k
cmVzQGxhZ2FyY2F2aWxsYS5vcmc+Cj4gPj4+IAo+ID4+PiBBY2tlZC1ieTogSWFuIENhbXBiZWxs
IDxpYW4uY2FtcGJlbGxAY2l0cml4LmNvbT4KPiA+Pj4gCj4gPj4+IFNpbmNlIHRoaXMgaXMgbW9y
ZSBhYm91dCBncmFudCB0YWJsZXMgdGhhbiBuZXRiYWNrIHRoaXMgc2hvdWxkIHByb2JhYmx5Cj4g
Pj4+IGdvIHZpYSBLb25yYWQgcmF0aGVyIHRoYW4gRGF2ZSwgaXMgdGhhdCBPSyB3aXRoIHlvdSBE
YXZlPwo+ID4+IAo+ID4+IElmIHRoYXQgaXMgdGhlIGNhc2UgaG9wZWZ1bGx5IEtvbnJhZCBjYW4g
ZGVhbCB3aXRoIHRoZSB0d28gdHlwb3M/IE90aGVyd2lzZSBoYXBweSB0byByZS1zcGluIHRoZSBw
YXRjaC4KPiA+IAo+ID4gU28gd2l0aCB0aGlzIHBhdGNoIHdoZW4gSSBsYXVuY2ggYW4gUFZIVk0g
Z3Vlc3Qgb24gWGVuIDQuMSBJIGdldCB0aGlzCj4gPiBpbiB0aGUgaW5pdGlhbCBkb21haW4gYW5k
IHRoZSBndWVzdCBpcyBjcmFzaGVkOgo+ID4gCj4gPiBbICAyNjEuOTI3MjE4XSBwcml2Y21kX2Zh
dWx0OiB2bWE9ZmZmZjg4MDAyYTMxZGNlOCA3ZjRlZGMwOTUwMDAtN2Y0ZWRjMTk1MDAwLCBwZ29m
Zj1jOCwgdXY9MDAwMDdmNGVkYzE1ZDAwMAo+IAo+IFdpdGggdGhpcyBwYXRjaD8gT3Igd2l0aCB0
aGUgbW1hcGJhdGNoIHYyPyBUaGlzIGlzIGEgcGFnZSBmYXVsdCBpbiBhIGZvcmVpZ24tbWFwcGVk
IFZNQS4gTm90IHRvdWNoZWQgYnkgdGhpcyBncmFudCBiYWNrZW5kIHBhdGNoIHdlIGFyZSB0YWxr
aW5nIGFib3V0LgoKVGhpcyBwYXRjaC4gQnV0IEkgYWxzbyBoYWQgYSBtb2RpZmllZCBibGtiYWNr
LiBTbyBsZXQgbWUgZG91YmxlIGNoZWNrCnRoYXQgaXQgaXMgbm90IHRoZSBwZXJzaXN0ZW50IGdy
YW50cyBhbmQgdGhpcyBwYXRjaCBkb2luZyBzb21ldGhpbmcgbmF1Z2h0eS4KCj4gCj4gRG9lcyB0
aGUgaHlwZXJ2aXNvciBkdW1wIGFueXRoaW5nIHRvIGl0cyBjb25zb2xlPwo+IAo+IEF0IHdoaWNo
IHBvaW50IGR1cmluZyB4Y19odm1fYnVpbGQgZG8geW91IHNlZSB0aGlzPyAob3IgZWxzZXdoZXJl
IGluIHRoZSB0b29sc3RhY2s/KQoKTm8gaWRlYS4gRGlkbid0IGV4YW1pbmUgdGhhdCBtdWNoLgoK
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVs
IG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwOi8vbGlzdHMueGVuLm9y
Zy94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xen.org Fri Sep 21 20:57:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Sep 2012 20:57:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TFAHB-0005ow-Oz; Fri, 21 Sep 2012 20:56:41 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1TFAH9-0005or-WF
	for xen-devel@lists.xen.org; Fri, 21 Sep 2012 20:56:40 +0000
Received: from [85.158.139.211:19265] by server-16.bemta-5.messagelabs.com id
	3F/85-11718-784DC505; Fri, 21 Sep 2012 20:56:39 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-9.tower-206.messagelabs.com!1348260997!17997507!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzU2MzI0\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19771 invoked from network); 21 Sep 2012 20:56:38 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-9.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 21 Sep 2012 20:56: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 q8LKuSuZ017777
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 21 Sep 2012 20:56:29 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q8LKuSYI010166
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 21 Sep 2012 20:56:28 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
	q8LKuRe0010966; Fri, 21 Sep 2012 15:56:27 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 21 Sep 2012 13:56:27 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 32673402EC; Fri, 21 Sep 2012 16:45:21 -0400 (EDT)
Date: Fri, 21 Sep 2012 16:45:21 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Andres Lagar-Cavilla <andres.lagarcavilla@gmail.com>
Message-ID: <20120921204521.GA30614@phenom.dumpdata.com>
References: <1347632819-13684-1-git-send-email-andres@lagarcavilla.org>
	<1347869865.14977.15.camel@zakaz.uk.xensource.com>
	<5B5132A4-93B2-41D0-B1A6-048810565DB5@gridcentric.ca>
	<20120921185258.GA4931@phenom.dumpdata.com>
	<ACFBD23A-6B32-47F3-B71A-37F4557FDE47@gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <ACFBD23A-6B32-47F3-B71A-37F4557FDE47@gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: Ian Campbell <Ian.Campbell@citrix.com>,
	Andres Lagar-Cavilla <andreslc@gridcentric.ca>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	xen-devel <xen-devel@lists.xen.org>,
	David Vrabel <david.vrabel@citrix.com>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	David Miller <davem@davemloft.net>,
	Andres Lagar-Cavilla <andres@lagarcavilla.org>
Subject: Re: [Xen-devel] [PATCH] Xen backend support for paged out grant
	targets V4.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 with this patch when I launch an PVHVM guest on Xen 4.1 I get this
> > in the initial domain and the guest is crashed:
> > 
> > [  261.927218] privcmd_fault: vma=ffff88002a31dce8 7f4edc095000-7f4edc195000, pgoff=c8, uv=00007f4edc15d000
> 
> With this patch? Or with the mmapbatch v2? This is a page fault in a foreign-mapped VMA. Not touched by this grant backend patch we are talking about.
> 
> Does the hypervisor dump anything to its console?
> 
> At which point during xc_hvm_build do you see this? (or elsewhere in the toolstack?)

My apologies. It was Oliver's persistent grant patch that does not like your patch.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 21 20:57:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Sep 2012 20:57:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TFAHB-0005ow-Oz; Fri, 21 Sep 2012 20:56:41 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1TFAH9-0005or-WF
	for xen-devel@lists.xen.org; Fri, 21 Sep 2012 20:56:40 +0000
Received: from [85.158.139.211:19265] by server-16.bemta-5.messagelabs.com id
	3F/85-11718-784DC505; Fri, 21 Sep 2012 20:56:39 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-9.tower-206.messagelabs.com!1348260997!17997507!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzU2MzI0\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19771 invoked from network); 21 Sep 2012 20:56:38 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-9.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 21 Sep 2012 20:56: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 q8LKuSuZ017777
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 21 Sep 2012 20:56:29 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q8LKuSYI010166
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 21 Sep 2012 20:56:28 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
	q8LKuRe0010966; Fri, 21 Sep 2012 15:56:27 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 21 Sep 2012 13:56:27 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 32673402EC; Fri, 21 Sep 2012 16:45:21 -0400 (EDT)
Date: Fri, 21 Sep 2012 16:45:21 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Andres Lagar-Cavilla <andres.lagarcavilla@gmail.com>
Message-ID: <20120921204521.GA30614@phenom.dumpdata.com>
References: <1347632819-13684-1-git-send-email-andres@lagarcavilla.org>
	<1347869865.14977.15.camel@zakaz.uk.xensource.com>
	<5B5132A4-93B2-41D0-B1A6-048810565DB5@gridcentric.ca>
	<20120921185258.GA4931@phenom.dumpdata.com>
	<ACFBD23A-6B32-47F3-B71A-37F4557FDE47@gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <ACFBD23A-6B32-47F3-B71A-37F4557FDE47@gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: Ian Campbell <Ian.Campbell@citrix.com>,
	Andres Lagar-Cavilla <andreslc@gridcentric.ca>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	xen-devel <xen-devel@lists.xen.org>,
	David Vrabel <david.vrabel@citrix.com>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	David Miller <davem@davemloft.net>,
	Andres Lagar-Cavilla <andres@lagarcavilla.org>
Subject: Re: [Xen-devel] [PATCH] Xen backend support for paged out grant
	targets V4.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 with this patch when I launch an PVHVM guest on Xen 4.1 I get this
> > in the initial domain and the guest is crashed:
> > 
> > [  261.927218] privcmd_fault: vma=ffff88002a31dce8 7f4edc095000-7f4edc195000, pgoff=c8, uv=00007f4edc15d000
> 
> With this patch? Or with the mmapbatch v2? This is a page fault in a foreign-mapped VMA. Not touched by this grant backend patch we are talking about.
> 
> Does the hypervisor dump anything to its console?
> 
> At which point during xc_hvm_build do you see this? (or elsewhere in the toolstack?)

My apologies. It was Oliver's persistent grant patch that does not like your patch.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 21 20:58:23 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Sep 2012 20: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 1TFAIW-0005tI-7H; Fri, 21 Sep 2012 20:58:04 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1TFAIV-0005t9-7T
	for xen-devel@lists.xen.org; Fri, 21 Sep 2012 20:58:03 +0000
Received: from [85.158.138.51:18430] by server-16.bemta-3.messagelabs.com id
	17/B4-31776-AD4DC505; Fri, 21 Sep 2012 20:58:02 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1348261076!31605675!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzU2MzI0\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21620 invoked from network); 21 Sep 2012 20:58:02 -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; 21 Sep 2012 20:58:02 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q8LKvrpf019228
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 21 Sep 2012 20:57: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
	q8LKvqKg019716
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 21 Sep 2012 20:57:53 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
	q8LKvqfR011742; Fri, 21 Sep 2012 15:57:52 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 21 Sep 2012 13:57:52 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id A0667402EC; Fri, 21 Sep 2012 16:46:46 -0400 (EDT)
Date: Fri, 21 Sep 2012 16:46:46 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Oliver Chick <oliver.chick@citrix.com>, andres.lagarcavilla@gmail.com
Message-ID: <20120921204646.GB30614@phenom.dumpdata.com>
References: <1348242767-23732-1-git-send-email-oliver.chick@citrix.com>
	<20120921184123.GA27502@phenom.dumpdata.com>
	<20120921185622.GA5042@phenom.dumpdata.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120921185622.GA5042@phenom.dumpdata.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: linux-kernel@vger.kernel.org, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH v2] Persistent grant maps for xen blk drivers
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Sep 21, 2012 at 02:56:22PM -0400, Konrad Rzeszutek Wilk wrote:
> > *: With a PVHVM guest I get
> > 
> > [  261.927218] privcmd_fault: vma=ffff88002a31dce8 7f4edc095000-7f4edc195000, pgoff=c8, uv=00007f4edc15d000
> > 
> > thought if I applied your patch on top of v3.6-rc6 I didn't see the privcmd_fault but
> > I did see the guest crash.
> 
> And that is due to c571898ffc24a1768e1b2dabeac0fc7dd4c14601 which I've reverted in my
> #linux-next branch

Nevermind. Andres' patch by itself (so without yours) works just fine. There is
something your patch and his aren't agreeing on.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 21 20:58:23 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Sep 2012 20: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 1TFAIW-0005tI-7H; Fri, 21 Sep 2012 20:58:04 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1TFAIV-0005t9-7T
	for xen-devel@lists.xen.org; Fri, 21 Sep 2012 20:58:03 +0000
Received: from [85.158.138.51:18430] by server-16.bemta-3.messagelabs.com id
	17/B4-31776-AD4DC505; Fri, 21 Sep 2012 20:58:02 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1348261076!31605675!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzU2MzI0\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21620 invoked from network); 21 Sep 2012 20:58:02 -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; 21 Sep 2012 20:58:02 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q8LKvrpf019228
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 21 Sep 2012 20:57: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
	q8LKvqKg019716
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 21 Sep 2012 20:57:53 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
	q8LKvqfR011742; Fri, 21 Sep 2012 15:57:52 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 21 Sep 2012 13:57:52 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id A0667402EC; Fri, 21 Sep 2012 16:46:46 -0400 (EDT)
Date: Fri, 21 Sep 2012 16:46:46 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Oliver Chick <oliver.chick@citrix.com>, andres.lagarcavilla@gmail.com
Message-ID: <20120921204646.GB30614@phenom.dumpdata.com>
References: <1348242767-23732-1-git-send-email-oliver.chick@citrix.com>
	<20120921184123.GA27502@phenom.dumpdata.com>
	<20120921185622.GA5042@phenom.dumpdata.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120921185622.GA5042@phenom.dumpdata.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: linux-kernel@vger.kernel.org, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH v2] Persistent grant maps for xen blk drivers
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Sep 21, 2012 at 02:56:22PM -0400, Konrad Rzeszutek Wilk wrote:
> > *: With a PVHVM guest I get
> > 
> > [  261.927218] privcmd_fault: vma=ffff88002a31dce8 7f4edc095000-7f4edc195000, pgoff=c8, uv=00007f4edc15d000
> > 
> > thought if I applied your patch on top of v3.6-rc6 I didn't see the privcmd_fault but
> > I did see the guest crash.
> 
> And that is due to c571898ffc24a1768e1b2dabeac0fc7dd4c14601 which I've reverted in my
> #linux-next branch

Nevermind. Andres' patch by itself (so without yours) works just fine. There is
something your patch and his aren't agreeing on.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 21 23:42:17 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Sep 2012 23:42:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TFCqv-0006oK-Fh; Fri, 21 Sep 2012 23:41: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 1TFCqu-0006oF-8C
	for xen-devel@lists.xensource.com; Fri, 21 Sep 2012 23:41:44 +0000
Received: from [85.158.139.83:12109] by server-3.bemta-5.messagelabs.com id
	8A/57-21836-73BFC505; Fri, 21 Sep 2012 23:41:43 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1348270902!31434247!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTA3NTI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13079 invoked from network); 21 Sep 2012 23:41:42 -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;
	21 Sep 2012 23:41:42 -0000
X-IronPort-AV: E=Sophos;i="4.80,465,1344211200"; d="scan'208";a="14701295"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Sep 2012 23: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.279.1; Sat, 22 Sep 2012 00:41: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 1TFCqr-0006bp-AB;
	Fri, 21 Sep 2012 23:41:41 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1TFCqr-0003ZU-8Q;
	Sat, 22 Sep 2012 00:41:41 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-13827-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sat, 22 Sep 2012 00:41:41 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13827: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 13827 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13827/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-multivcpu  5 xen-boot                  fail REGR. vs. 13825
 test-amd64-i386-xl-win-vcpus1  5 xen-boot                 fail REGR. vs. 13825
 test-amd64-i386-qemuu-rhel6hvm-intel  5 xen-boot          fail REGR. vs. 13825
 test-amd64-i386-win-vcpus1    5 xen-boot                  fail REGR. vs. 13825
 test-amd64-i386-xl-win7-amd64  5 xen-boot                 fail REGR. vs. 13825
 test-amd64-amd64-win          5 xen-boot                  fail REGR. vs. 13825
 test-amd64-amd64-xl-winxpsp3  5 xen-boot                  fail REGR. vs. 13825
 test-amd64-i386-pair          8 xen-boot/dst_host         fail REGR. vs. 13825
 test-amd64-i386-pair          7 xen-boot/src_host         fail REGR. vs. 13825

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore            fail   like 13825
 test-amd64-amd64-xl-pcipt-intel  5 xen-boot               fail REGR. vs. 13825
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail like 13823
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail like 13825

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  8f658b463b78
baseline version:
 xen                  d364becfb083

------------------------------------------------------------
People who touched revisions under test:
  Jan Beulich <jbeulich@suse.com>
  Keir Fraser <keir@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-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                         fail    
 test-amd64-i386-xl-multivcpu                                 fail    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-amd64-amd64-xl-sedf                                     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-amd64-amd64-xl-win                                      fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
changeset:   25938:8f658b463b78
tag:         tip
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Sep 21 17:02:46 2012 +0200
    
    x86: enable VIA CPU support
    
    Newer VIA CPUs have both 64-bit and VMX support. Enable them to be
    recognized for these purposes, at once stripping off any 32-bit CPU
    only bits from the respective CPU support file, and adding 64-bit ones
    found in recent Linux.
    
    This particularly implies untying the VMX == Intel assumption in a few
    places.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   25937:32187301ecc5
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Sep 21 15:20:21 2012 +0200
    
    x86: eliminate code affecting only 64-bit-incapable CPUs
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   25936:c8873f13cec3
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Sep 21 14:25:12 2012 +0200
    
    printk: prefer %#x et at over 0x%x
    
    Performance is not an issue with printk(), so let the function do
    minimally more work and instead save a byte per affected format
    specifier.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   25935:1e6e6b49b4ac
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Sep 21 13:47:18 2012 +0200
    
    x86: introduce MWAIT-based, ACPI-less CPU idle driver
    
    This is a port of Linux'es intel-idle driver serving the same purpose.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   25934:8eab91903e71
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Sep 21 13:45:08 2012 +0200
    
    cpuidle: remove unused latency_ticks member
    
    ... and code used only for initializing it.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   25933:d364becfb083
user:        Jan Beulich <jbeulich@suse.com>
date:        Thu Sep 20 13:31:19 2012 +0200
    
    introduce guest_handle_for_field()
    
    This helper turns a field of a GUEST_HANDLE in a GUEST_HANDLE.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    
    
(qemu changes not included)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 21 23:42:17 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Sep 2012 23:42:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TFCqv-0006oK-Fh; Fri, 21 Sep 2012 23:41: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 1TFCqu-0006oF-8C
	for xen-devel@lists.xensource.com; Fri, 21 Sep 2012 23:41:44 +0000
Received: from [85.158.139.83:12109] by server-3.bemta-5.messagelabs.com id
	8A/57-21836-73BFC505; Fri, 21 Sep 2012 23:41:43 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1348270902!31434247!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTA3NTI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13079 invoked from network); 21 Sep 2012 23:41:42 -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;
	21 Sep 2012 23:41:42 -0000
X-IronPort-AV: E=Sophos;i="4.80,465,1344211200"; d="scan'208";a="14701295"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Sep 2012 23: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.279.1; Sat, 22 Sep 2012 00:41: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 1TFCqr-0006bp-AB;
	Fri, 21 Sep 2012 23:41:41 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1TFCqr-0003ZU-8Q;
	Sat, 22 Sep 2012 00:41:41 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-13827-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sat, 22 Sep 2012 00:41:41 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13827: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 13827 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13827/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-multivcpu  5 xen-boot                  fail REGR. vs. 13825
 test-amd64-i386-xl-win-vcpus1  5 xen-boot                 fail REGR. vs. 13825
 test-amd64-i386-qemuu-rhel6hvm-intel  5 xen-boot          fail REGR. vs. 13825
 test-amd64-i386-win-vcpus1    5 xen-boot                  fail REGR. vs. 13825
 test-amd64-i386-xl-win7-amd64  5 xen-boot                 fail REGR. vs. 13825
 test-amd64-amd64-win          5 xen-boot                  fail REGR. vs. 13825
 test-amd64-amd64-xl-winxpsp3  5 xen-boot                  fail REGR. vs. 13825
 test-amd64-i386-pair          8 xen-boot/dst_host         fail REGR. vs. 13825
 test-amd64-i386-pair          7 xen-boot/src_host         fail REGR. vs. 13825

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore            fail   like 13825
 test-amd64-amd64-xl-pcipt-intel  5 xen-boot               fail REGR. vs. 13825
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail like 13823
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail like 13825

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  8f658b463b78
baseline version:
 xen                  d364becfb083

------------------------------------------------------------
People who touched revisions under test:
  Jan Beulich <jbeulich@suse.com>
  Keir Fraser <keir@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-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                         fail    
 test-amd64-i386-xl-multivcpu                                 fail    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-amd64-amd64-xl-sedf                                     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-amd64-amd64-xl-win                                      fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
changeset:   25938:8f658b463b78
tag:         tip
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Sep 21 17:02:46 2012 +0200
    
    x86: enable VIA CPU support
    
    Newer VIA CPUs have both 64-bit and VMX support. Enable them to be
    recognized for these purposes, at once stripping off any 32-bit CPU
    only bits from the respective CPU support file, and adding 64-bit ones
    found in recent Linux.
    
    This particularly implies untying the VMX == Intel assumption in a few
    places.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   25937:32187301ecc5
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Sep 21 15:20:21 2012 +0200
    
    x86: eliminate code affecting only 64-bit-incapable CPUs
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   25936:c8873f13cec3
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Sep 21 14:25:12 2012 +0200
    
    printk: prefer %#x et at over 0x%x
    
    Performance is not an issue with printk(), so let the function do
    minimally more work and instead save a byte per affected format
    specifier.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   25935:1e6e6b49b4ac
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Sep 21 13:47:18 2012 +0200
    
    x86: introduce MWAIT-based, ACPI-less CPU idle driver
    
    This is a port of Linux'es intel-idle driver serving the same purpose.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   25934:8eab91903e71
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Sep 21 13:45:08 2012 +0200
    
    cpuidle: remove unused latency_ticks member
    
    ... and code used only for initializing it.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   25933:d364becfb083
user:        Jan Beulich <jbeulich@suse.com>
date:        Thu Sep 20 13:31:19 2012 +0200
    
    introduce guest_handle_for_field()
    
    This helper turns a field of a GUEST_HANDLE in a GUEST_HANDLE.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    
    
(qemu changes not included)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 21 23:45:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Sep 2012 23: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 1TFCua-0006up-4U; Fri, 21 Sep 2012 23:45:32 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andre.Przywara@amd.com>) id 1TFCuY-0006ub-NX
	for xen-devel@lists.xen.org; Fri, 21 Sep 2012 23:45:30 +0000
X-Env-Sender: Andre.Przywara@amd.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1348271116!4974728!1
X-Originating-IP: [216.32.181.186]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25982 invoked from network); 21 Sep 2012 23:45:18 -0000
Received: from ch1ehsobe006.messaging.microsoft.com (HELO
	ch1outboundpool.messaging.microsoft.com) (216.32.181.186)
	by server-15.tower-27.messagelabs.com with AES128-SHA encrypted SMTP;
	21 Sep 2012 23:45:18 -0000
Received: from mail101-ch1-R.bigfish.com (10.43.68.248) by
	CH1EHSOBE020.bigfish.com (10.43.70.77) with Microsoft SMTP Server id
	14.1.225.23; Fri, 21 Sep 2012 23:45:16 +0000
Received: from mail101-ch1 (localhost [127.0.0.1])	by
	mail101-ch1-R.bigfish.com (Postfix) with ESMTP id 4007D400203;
	Fri, 21 Sep 2012 23:45:16 +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: -2
X-BigFish: VPS-2(z551bizbb2dI98dI9371I1432Id6f1izz1202h1d1ah1d2ahzz8275bhz2dh668h839hd25he5bhf0ah107ah1288h12a5h12a9h12bdh137ah1155h)
Received: from mail101-ch1 (localhost.localdomain [127.0.0.1]) by mail101-ch1
	(MessageSwitch) id 1348271114218099_10221;
	Fri, 21 Sep 2012 23:45:14 +0000 (UTC)
Received: from CH1EHSMHS029.bigfish.com (snatpool1.int.messaging.microsoft.com
	[10.43.68.250])	by mail101-ch1.bigfish.com (Postfix) with ESMTP id
	282B56004D;	Fri, 21 Sep 2012 23:45:14 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	CH1EHSMHS029.bigfish.com (10.43.70.29) with Microsoft SMTP Server id
	14.1.225.23; Fri, 21 Sep 2012 23:45:13 +0000
X-WSS-ID: 0MAQ4NC-01-2VD-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 2F63E10280C5;	Fri, 21 Sep 2012 18:45:11 -0500 (CDT)
Received: from sausexhtp02.amd.com (163.181.3.152) by sausexedgep02.amd.com
	(163.181.36.59) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Fri, 21 Sep 2012 18:45:25 -0500
Received: from storexhtp01.amd.com (172.24.4.3) by sausexhtp02.amd.com
	(163.181.3.152) with Microsoft SMTP Server (TLS) id 8.3.213.0;
	Fri, 21 Sep 2012 18:45:11 -0500
Received: from [10.224.148.41] (10.224.148.41) by storexhtp01.amd.com
	(172.24.4.3) with Microsoft SMTP Server id 8.3.213.0; Fri, 21 Sep 2012
	19:45:11 -0400
Message-ID: <505CFC71.5090702@amd.com>
Date: Sat, 22 Sep 2012 01:46:57 +0200
From: Andre Przywara <andre.przywara@amd.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.26) Gecko/20120131 Lightning/1.0b2 Thunderbird/3.1.18
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk <konrad@kernel.org>
References: <501BC20F.3040205@amd.com>
	<20120803123628.GB10670@andromeda.dapyr.net>
	<20120817142237.GA8467@phenom.dumpdata.com>
	<505CA8AB.6000808@amd.com>
	<20120921174833.GC6821@phenom.dumpdata.com>
In-Reply-To: <20120921174833.GC6821@phenom.dumpdata.com>
X-OriginatorOrg: amd.com
Cc: Konrad Rzeszutek Wilk <konrad@darnok.org>,
	Jeremy Fitzhardinge <jeremy@goop.org>, xen-devel <xen-devel@lists.xen.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] Dom0 crash with old style AMD NUMA detection
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 09/21/2012 07:48 PM, Konrad Rzeszutek Wilk wrote:
>> Acked-by: Andre Przywara<andre.przywara@amd.com>
>>
>> I compiled and boot-tested this on my (single node ;-) test box.
>> First bare-metal, dmesg: No NUMA configuration found
>> Then again, but with numa=off on the cmd-line: NUMA turned off
>> Then under Xen as Dom0 kernel: NUMA turned off
>>
>> So the code behaves under Xen as one would have explicitly specified
>> numa=off, which is what we want.
>
> Right.
>> I couldn't get hold of the test machine (old K8 server) that the bug
>> was once triggered, that's why I'm reluctant to give my Tested-by.
>> Will try this ASAP.
>
> OK, will wait with this - it would be a bit silly if the patch did not
> fix the issue :-)

Thanks for you patience. I tried some machines, it not only affects K8s, 
but also Barcelonas and Magny-Cours.
Boot those with a Xen HV and restrict Dom0's memory to something well 
below the first node's size (say dom0_mem=512M). If the 3.x Dom0 kernel 
has CONFIG_AMD_NUMA compiled in, the box will crash, because the 
hardware's NUMA info read from the northbridge does not fit to Dom0's 
understanding of it's memory.
With your fix the box booted fine, NUMA is turned off and everyone is happy.
Double checked by commenting the numa_off=1 line in your patch: crash 
again. So this line definitely fixes this.

Tested-by: Andre Przywara <andre.przywara@amd.com>

Regards,
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 Fri Sep 21 23:45:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 21 Sep 2012 23: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 1TFCua-0006up-4U; Fri, 21 Sep 2012 23:45:32 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andre.Przywara@amd.com>) id 1TFCuY-0006ub-NX
	for xen-devel@lists.xen.org; Fri, 21 Sep 2012 23:45:30 +0000
X-Env-Sender: Andre.Przywara@amd.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1348271116!4974728!1
X-Originating-IP: [216.32.181.186]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25982 invoked from network); 21 Sep 2012 23:45:18 -0000
Received: from ch1ehsobe006.messaging.microsoft.com (HELO
	ch1outboundpool.messaging.microsoft.com) (216.32.181.186)
	by server-15.tower-27.messagelabs.com with AES128-SHA encrypted SMTP;
	21 Sep 2012 23:45:18 -0000
Received: from mail101-ch1-R.bigfish.com (10.43.68.248) by
	CH1EHSOBE020.bigfish.com (10.43.70.77) with Microsoft SMTP Server id
	14.1.225.23; Fri, 21 Sep 2012 23:45:16 +0000
Received: from mail101-ch1 (localhost [127.0.0.1])	by
	mail101-ch1-R.bigfish.com (Postfix) with ESMTP id 4007D400203;
	Fri, 21 Sep 2012 23:45:16 +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: -2
X-BigFish: VPS-2(z551bizbb2dI98dI9371I1432Id6f1izz1202h1d1ah1d2ahzz8275bhz2dh668h839hd25he5bhf0ah107ah1288h12a5h12a9h12bdh137ah1155h)
Received: from mail101-ch1 (localhost.localdomain [127.0.0.1]) by mail101-ch1
	(MessageSwitch) id 1348271114218099_10221;
	Fri, 21 Sep 2012 23:45:14 +0000 (UTC)
Received: from CH1EHSMHS029.bigfish.com (snatpool1.int.messaging.microsoft.com
	[10.43.68.250])	by mail101-ch1.bigfish.com (Postfix) with ESMTP id
	282B56004D;	Fri, 21 Sep 2012 23:45:14 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	CH1EHSMHS029.bigfish.com (10.43.70.29) with Microsoft SMTP Server id
	14.1.225.23; Fri, 21 Sep 2012 23:45:13 +0000
X-WSS-ID: 0MAQ4NC-01-2VD-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 2F63E10280C5;	Fri, 21 Sep 2012 18:45:11 -0500 (CDT)
Received: from sausexhtp02.amd.com (163.181.3.152) by sausexedgep02.amd.com
	(163.181.36.59) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Fri, 21 Sep 2012 18:45:25 -0500
Received: from storexhtp01.amd.com (172.24.4.3) by sausexhtp02.amd.com
	(163.181.3.152) with Microsoft SMTP Server (TLS) id 8.3.213.0;
	Fri, 21 Sep 2012 18:45:11 -0500
Received: from [10.224.148.41] (10.224.148.41) by storexhtp01.amd.com
	(172.24.4.3) with Microsoft SMTP Server id 8.3.213.0; Fri, 21 Sep 2012
	19:45:11 -0400
Message-ID: <505CFC71.5090702@amd.com>
Date: Sat, 22 Sep 2012 01:46:57 +0200
From: Andre Przywara <andre.przywara@amd.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.26) Gecko/20120131 Lightning/1.0b2 Thunderbird/3.1.18
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk <konrad@kernel.org>
References: <501BC20F.3040205@amd.com>
	<20120803123628.GB10670@andromeda.dapyr.net>
	<20120817142237.GA8467@phenom.dumpdata.com>
	<505CA8AB.6000808@amd.com>
	<20120921174833.GC6821@phenom.dumpdata.com>
In-Reply-To: <20120921174833.GC6821@phenom.dumpdata.com>
X-OriginatorOrg: amd.com
Cc: Konrad Rzeszutek Wilk <konrad@darnok.org>,
	Jeremy Fitzhardinge <jeremy@goop.org>, xen-devel <xen-devel@lists.xen.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] Dom0 crash with old style AMD NUMA detection
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 09/21/2012 07:48 PM, Konrad Rzeszutek Wilk wrote:
>> Acked-by: Andre Przywara<andre.przywara@amd.com>
>>
>> I compiled and boot-tested this on my (single node ;-) test box.
>> First bare-metal, dmesg: No NUMA configuration found
>> Then again, but with numa=off on the cmd-line: NUMA turned off
>> Then under Xen as Dom0 kernel: NUMA turned off
>>
>> So the code behaves under Xen as one would have explicitly specified
>> numa=off, which is what we want.
>
> Right.
>> I couldn't get hold of the test machine (old K8 server) that the bug
>> was once triggered, that's why I'm reluctant to give my Tested-by.
>> Will try this ASAP.
>
> OK, will wait with this - it would be a bit silly if the patch did not
> fix the issue :-)

Thanks for you patience. I tried some machines, it not only affects K8s, 
but also Barcelonas and Magny-Cours.
Boot those with a Xen HV and restrict Dom0's memory to something well 
below the first node's size (say dom0_mem=512M). If the 3.x Dom0 kernel 
has CONFIG_AMD_NUMA compiled in, the box will crash, because the 
hardware's NUMA info read from the northbridge does not fit to Dom0's 
understanding of it's memory.
With your fix the box booted fine, NUMA is turned off and everyone is happy.
Double checked by commenting the numa_off=1 line in your patch: crash 
again. So this line definitely fixes this.

Tested-by: Andre Przywara <andre.przywara@amd.com>

Regards,
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 Sat Sep 22 04:34:34 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 22 Sep 2012 04:34: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 1TFHPj-0004pM-37; Sat, 22 Sep 2012 04:33:59 +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 1TFHPh-0004p8-7S
	for xen-devel@lists.xensource.com; Sat, 22 Sep 2012 04:33:57 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1348288429!10852919!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTA3NTI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16142 invoked from network); 22 Sep 2012 04:33:49 -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 Sep 2012 04:33:49 -0000
X-IronPort-AV: E=Sophos;i="4.80,465,1344211200"; d="scan'208";a="14702686"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Sep 2012 04:33: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.279.1; Sat, 22 Sep 2012 05:33: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 1TFHPY-00089Y-ID;
	Sat, 22 Sep 2012 04:33:48 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1TFHPY-0005ST-GD;
	Sat, 22 Sep 2012 05:33:48 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-13837-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sat, 22 Sep 2012 05:33:48 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13837: regressions - trouble:
	broken/fail/pass
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 13837 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13837/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-multivcpu  5 xen-boot                  fail REGR. vs. 13825
 test-amd64-i386-xl-win-vcpus1  5 xen-boot                 fail REGR. vs. 13825
 test-amd64-i386-qemuu-rhel6hvm-intel  5 xen-boot          fail REGR. vs. 13825
 test-amd64-i386-win-vcpus1    5 xen-boot                  fail REGR. vs. 13825
 test-amd64-i386-xl-win7-amd64  5 xen-boot                 fail REGR. vs. 13825
 test-amd64-amd64-win          5 xen-boot                  fail REGR. vs. 13825
 test-amd64-amd64-xl-winxpsp3  5 xen-boot                  fail REGR. vs. 13825
 test-amd64-i386-pair          8 xen-boot/dst_host         fail REGR. vs. 13825
 test-amd64-i386-pair          7 xen-boot/src_host         fail REGR. vs. 13825

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-win7-amd64 12 guest-localmigrate/x10    fail pass in 13827

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore            fail   like 13825
 test-amd64-amd64-xl-sedf      3 host-install(3)              broken like 13825
 test-amd64-amd64-xl-pcipt-intel  5 xen-boot               fail REGR. vs. 13825
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail like 13823
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail like 13825

Tests which did not succeed, but are not blocking:
 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-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop          fail in 13827 never pass

version targeted for testing:
 xen                  8f658b463b78
baseline version:
 xen                  d364becfb083

------------------------------------------------------------
People who touched revisions under test:
  Jan Beulich <jbeulich@suse.com>
  Keir Fraser <keir@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-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                         fail    
 test-amd64-i386-xl-multivcpu                                 fail    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-amd64-amd64-xl-sedf                                     broken  
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-amd64-amd64-xl-win                                      fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
changeset:   25938:8f658b463b78
tag:         tip
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Sep 21 17:02:46 2012 +0200
    
    x86: enable VIA CPU support
    
    Newer VIA CPUs have both 64-bit and VMX support. Enable them to be
    recognized for these purposes, at once stripping off any 32-bit CPU
    only bits from the respective CPU support file, and adding 64-bit ones
    found in recent Linux.
    
    This particularly implies untying the VMX == Intel assumption in a few
    places.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   25937:32187301ecc5
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Sep 21 15:20:21 2012 +0200
    
    x86: eliminate code affecting only 64-bit-incapable CPUs
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   25936:c8873f13cec3
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Sep 21 14:25:12 2012 +0200
    
    printk: prefer %#x et at over 0x%x
    
    Performance is not an issue with printk(), so let the function do
    minimally more work and instead save a byte per affected format
    specifier.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   25935:1e6e6b49b4ac
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Sep 21 13:47:18 2012 +0200
    
    x86: introduce MWAIT-based, ACPI-less CPU idle driver
    
    This is a port of Linux'es intel-idle driver serving the same purpose.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   25934:8eab91903e71
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Sep 21 13:45:08 2012 +0200
    
    cpuidle: remove unused latency_ticks member
    
    ... and code used only for initializing it.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   25933:d364becfb083
user:        Jan Beulich <jbeulich@suse.com>
date:        Thu Sep 20 13:31:19 2012 +0200
    
    introduce guest_handle_for_field()
    
    This helper turns a field of a GUEST_HANDLE in a GUEST_HANDLE.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    
    
(qemu changes not included)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Sep 22 04:34:34 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 22 Sep 2012 04:34: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 1TFHPj-0004pM-37; Sat, 22 Sep 2012 04:33:59 +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 1TFHPh-0004p8-7S
	for xen-devel@lists.xensource.com; Sat, 22 Sep 2012 04:33:57 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1348288429!10852919!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTA3NTI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16142 invoked from network); 22 Sep 2012 04:33:49 -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 Sep 2012 04:33:49 -0000
X-IronPort-AV: E=Sophos;i="4.80,465,1344211200"; d="scan'208";a="14702686"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Sep 2012 04:33: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.279.1; Sat, 22 Sep 2012 05:33: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 1TFHPY-00089Y-ID;
	Sat, 22 Sep 2012 04:33:48 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1TFHPY-0005ST-GD;
	Sat, 22 Sep 2012 05:33:48 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-13837-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sat, 22 Sep 2012 05:33:48 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13837: regressions - trouble:
	broken/fail/pass
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 13837 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13837/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-multivcpu  5 xen-boot                  fail REGR. vs. 13825
 test-amd64-i386-xl-win-vcpus1  5 xen-boot                 fail REGR. vs. 13825
 test-amd64-i386-qemuu-rhel6hvm-intel  5 xen-boot          fail REGR. vs. 13825
 test-amd64-i386-win-vcpus1    5 xen-boot                  fail REGR. vs. 13825
 test-amd64-i386-xl-win7-amd64  5 xen-boot                 fail REGR. vs. 13825
 test-amd64-amd64-win          5 xen-boot                  fail REGR. vs. 13825
 test-amd64-amd64-xl-winxpsp3  5 xen-boot                  fail REGR. vs. 13825
 test-amd64-i386-pair          8 xen-boot/dst_host         fail REGR. vs. 13825
 test-amd64-i386-pair          7 xen-boot/src_host         fail REGR. vs. 13825

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-win7-amd64 12 guest-localmigrate/x10    fail pass in 13827

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore            fail   like 13825
 test-amd64-amd64-xl-sedf      3 host-install(3)              broken like 13825
 test-amd64-amd64-xl-pcipt-intel  5 xen-boot               fail REGR. vs. 13825
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail like 13823
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail like 13825

Tests which did not succeed, but are not blocking:
 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-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop          fail in 13827 never pass

version targeted for testing:
 xen                  8f658b463b78
baseline version:
 xen                  d364becfb083

------------------------------------------------------------
People who touched revisions under test:
  Jan Beulich <jbeulich@suse.com>
  Keir Fraser <keir@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-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                         fail    
 test-amd64-i386-xl-multivcpu                                 fail    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-amd64-amd64-xl-sedf                                     broken  
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-amd64-amd64-xl-win                                      fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
changeset:   25938:8f658b463b78
tag:         tip
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Sep 21 17:02:46 2012 +0200
    
    x86: enable VIA CPU support
    
    Newer VIA CPUs have both 64-bit and VMX support. Enable them to be
    recognized for these purposes, at once stripping off any 32-bit CPU
    only bits from the respective CPU support file, and adding 64-bit ones
    found in recent Linux.
    
    This particularly implies untying the VMX == Intel assumption in a few
    places.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   25937:32187301ecc5
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Sep 21 15:20:21 2012 +0200
    
    x86: eliminate code affecting only 64-bit-incapable CPUs
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   25936:c8873f13cec3
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Sep 21 14:25:12 2012 +0200
    
    printk: prefer %#x et at over 0x%x
    
    Performance is not an issue with printk(), so let the function do
    minimally more work and instead save a byte per affected format
    specifier.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   25935:1e6e6b49b4ac
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Sep 21 13:47:18 2012 +0200
    
    x86: introduce MWAIT-based, ACPI-less CPU idle driver
    
    This is a port of Linux'es intel-idle driver serving the same purpose.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   25934:8eab91903e71
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Sep 21 13:45:08 2012 +0200
    
    cpuidle: remove unused latency_ticks member
    
    ... and code used only for initializing it.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   25933:d364becfb083
user:        Jan Beulich <jbeulich@suse.com>
date:        Thu Sep 20 13:31:19 2012 +0200
    
    introduce guest_handle_for_field()
    
    This helper turns a field of a GUEST_HANDLE in a GUEST_HANDLE.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    
    
(qemu changes not included)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Sep 22 08:49:20 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 22 Sep 2012 08: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 1TFLOH-00074q-2U; Sat, 22 Sep 2012 08:48:45 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <john.krstev@gmail.com>) id 1TFH5l-0004X3-0k
	for xen-devel@lists.xensource.com; Sat, 22 Sep 2012 04:13:21 +0000
Received: from [85.158.143.99:55067] by server-1.bemta-4.messagelabs.com id
	36/CE-05684-0EA3D505; Sat, 22 Sep 2012 04:13:20 +0000
X-Env-Sender: john.krstev@gmail.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1348287197!23811489!1
X-Originating-IP: [209.85.220.43]
X-SpamReason: No, hits=0.4 required=7.0 tests=MIME_QP_LONG_LINE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17883 invoked from network); 22 Sep 2012 04:13:19 -0000
Received: from mail-pa0-f43.google.com (HELO mail-pa0-f43.google.com)
	(209.85.220.43)
	by server-11.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Sep 2012 04:13:19 -0000
Received: by padfb1 with SMTP id fb1so199904pad.30
	for <xen-devel@lists.xensource.com>;
	Fri, 21 Sep 2012 21:13:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=references:in-reply-to:mime-version:content-transfer-encoding
	:content-type:message-id:cc:x-mailer:from:subject:date:to;
	bh=+ZjI7hrd4xiZWEF63Insc4MJAyZegdU/m90sXic/WgE=;
	b=Qs8d4g+tVLAH/YM0fND52ooaPzm9I9/jXRYcZsZuehe4oUE1LXil+/f+GovcV+kJm4
	aufOALlSiF+SdCZtWg1u/bBoR9QQ4pLsPBCjTSves38mW7gMbWVgZJ9oPcBd/UZkG+FN
	qsrzEZmYihOwwIYrtAVzFfsG9bVkBxYHtBKxidzTn2fGPknFl9D6X0qbr6EJXXg53n/a
	Er+MVM1MUIuekUnFpIaT0ccFlxpgr1qbehFIY/GUnXCUPMTvQo9uy5S6Ibu7d1kzqnfT
	WTSEHFibxGcG/+lP6ZLWxPuJEvph3AB1keIcj0vH+NFMRumUu0bOOIk4HVmnQMjtq/c2
	ZQKA==
Received: by 10.68.129.164 with SMTP id nx4mr20451817pbb.28.1348287196700;
	Fri, 21 Sep 2012 21:13:16 -0700 (PDT)
Received: from [192.168.2.132] (60-240-122-85.static.tpgi.com.au.
	[60.240.122.85])
	by mx.google.com with ESMTPS id l10sm5106839pax.32.2012.09.21.21.13.14
	(version=TLSv1/SSLv3 cipher=OTHER);
	Fri, 21 Sep 2012 21:13:16 -0700 (PDT)
References: <CA+LkAa=RHJCtpncP8AUSeR8Te3ZLMvRctuZqnv_NwUkCQ-im8Q@mail.gmail.com>
	<20120921172901.GA6821@phenom.dumpdata.com>
In-Reply-To: <20120921172901.GA6821@phenom.dumpdata.com>
Mime-Version: 1.0 (1.0)
Message-Id: <0D623B1B-135B-4F48-8E36-7067137713A2@gmail.com>
X-Mailer: iPhone Mail (9B208)
From: John Krstev <john.krstev@gmail.com>
Date: Sat, 22 Sep 2012 14:13:08 +1000
To: Konrad Rzeszutek Wilk <konrad@kernel.org>
X-Mailman-Approved-At: Sat, 22 Sep 2012 08:48:44 +0000
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Xen + DVB = not working. memory allocation 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

Hi Konrad,

It runs fine under baremetal, using the scan utility it finds channels, or using myth tv I can watch digital channels. Under Xen the scan utility gives me 'filter timeout.' This is under dom0 and also domU when passing through via vt-d (pass thru works ok for other devices such as intel on board graphics [sandy bridge]). It appears to lock but then time out on receiving data. 

Sorry I meant 3.6-rc6. I've been trying many kernel versions over last couple of months without any success. 

Do you have any suggestions? FYI haven't tried the debug options.

Regards,

John

On 22/09/2012, at 3:29, Konrad Rzeszutek Wilk <konrad@kernel.org> wrote:

> On Fri, Sep 21, 2012 at 01:02:23PM +1000, John Krstev wrote:
>> Hi Konrad,
> 
> Hey John,
> 
> Please next time also include xen-devel on the To header. I've done that
> for you.
>> 
>> I refer to your patch at:
>> http://lists.xen.org/archives/html/xen-devel/2012-01/msg01927.html
>> which I found reading
>> http://www.gossamer-threads.com/lists/xen/devel/256197
>> 
>> I have a winfast DVT 2000H (cx88) DVB card which is not able to
>> scan/watch digital TV when running under Xen.
> 
> Did you first try running it under baremetal Linux (using a Live CD for
> example?) Did it work there?
> 
> How does it not work? Can you program it? Is this under a guest or the
> main kernel? When it wsa not working, did you try all the debug
> options enable (http://wiki.xen.org/wiki/XenSerialConsole) to
> see if there is anthing being reported?
> 
>> 
>> I've tried installing the above patch to the 3.6-rc6 kernel, but did
>> not seem to help.
>> 
>> Apologies if this has been asked before (I wasn't able to find another
>> patch), but is there a patch to get this (suspected vmalloc_32) fixed
>> and DVB card working?
> 
> Eventually yes.
>> 
>> FYI I'm running 64 bit 3.5-rc6 and xen 4.3-unstable.
> 
> 3.5-rc6 or 3.6-rc6?
> I presume the latter?
>> 
>> Thank you! :)
>> 
>> Regards,
>> 
>> John
>> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Sep 22 08:49:20 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 22 Sep 2012 08: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 1TFLOH-00074q-2U; Sat, 22 Sep 2012 08:48:45 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <john.krstev@gmail.com>) id 1TFH5l-0004X3-0k
	for xen-devel@lists.xensource.com; Sat, 22 Sep 2012 04:13:21 +0000
Received: from [85.158.143.99:55067] by server-1.bemta-4.messagelabs.com id
	36/CE-05684-0EA3D505; Sat, 22 Sep 2012 04:13:20 +0000
X-Env-Sender: john.krstev@gmail.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1348287197!23811489!1
X-Originating-IP: [209.85.220.43]
X-SpamReason: No, hits=0.4 required=7.0 tests=MIME_QP_LONG_LINE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17883 invoked from network); 22 Sep 2012 04:13:19 -0000
Received: from mail-pa0-f43.google.com (HELO mail-pa0-f43.google.com)
	(209.85.220.43)
	by server-11.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Sep 2012 04:13:19 -0000
Received: by padfb1 with SMTP id fb1so199904pad.30
	for <xen-devel@lists.xensource.com>;
	Fri, 21 Sep 2012 21:13:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=references:in-reply-to:mime-version:content-transfer-encoding
	:content-type:message-id:cc:x-mailer:from:subject:date:to;
	bh=+ZjI7hrd4xiZWEF63Insc4MJAyZegdU/m90sXic/WgE=;
	b=Qs8d4g+tVLAH/YM0fND52ooaPzm9I9/jXRYcZsZuehe4oUE1LXil+/f+GovcV+kJm4
	aufOALlSiF+SdCZtWg1u/bBoR9QQ4pLsPBCjTSves38mW7gMbWVgZJ9oPcBd/UZkG+FN
	qsrzEZmYihOwwIYrtAVzFfsG9bVkBxYHtBKxidzTn2fGPknFl9D6X0qbr6EJXXg53n/a
	Er+MVM1MUIuekUnFpIaT0ccFlxpgr1qbehFIY/GUnXCUPMTvQo9uy5S6Ibu7d1kzqnfT
	WTSEHFibxGcG/+lP6ZLWxPuJEvph3AB1keIcj0vH+NFMRumUu0bOOIk4HVmnQMjtq/c2
	ZQKA==
Received: by 10.68.129.164 with SMTP id nx4mr20451817pbb.28.1348287196700;
	Fri, 21 Sep 2012 21:13:16 -0700 (PDT)
Received: from [192.168.2.132] (60-240-122-85.static.tpgi.com.au.
	[60.240.122.85])
	by mx.google.com with ESMTPS id l10sm5106839pax.32.2012.09.21.21.13.14
	(version=TLSv1/SSLv3 cipher=OTHER);
	Fri, 21 Sep 2012 21:13:16 -0700 (PDT)
References: <CA+LkAa=RHJCtpncP8AUSeR8Te3ZLMvRctuZqnv_NwUkCQ-im8Q@mail.gmail.com>
	<20120921172901.GA6821@phenom.dumpdata.com>
In-Reply-To: <20120921172901.GA6821@phenom.dumpdata.com>
Mime-Version: 1.0 (1.0)
Message-Id: <0D623B1B-135B-4F48-8E36-7067137713A2@gmail.com>
X-Mailer: iPhone Mail (9B208)
From: John Krstev <john.krstev@gmail.com>
Date: Sat, 22 Sep 2012 14:13:08 +1000
To: Konrad Rzeszutek Wilk <konrad@kernel.org>
X-Mailman-Approved-At: Sat, 22 Sep 2012 08:48:44 +0000
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Xen + DVB = not working. memory allocation 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

Hi Konrad,

It runs fine under baremetal, using the scan utility it finds channels, or using myth tv I can watch digital channels. Under Xen the scan utility gives me 'filter timeout.' This is under dom0 and also domU when passing through via vt-d (pass thru works ok for other devices such as intel on board graphics [sandy bridge]). It appears to lock but then time out on receiving data. 

Sorry I meant 3.6-rc6. I've been trying many kernel versions over last couple of months without any success. 

Do you have any suggestions? FYI haven't tried the debug options.

Regards,

John

On 22/09/2012, at 3:29, Konrad Rzeszutek Wilk <konrad@kernel.org> wrote:

> On Fri, Sep 21, 2012 at 01:02:23PM +1000, John Krstev wrote:
>> Hi Konrad,
> 
> Hey John,
> 
> Please next time also include xen-devel on the To header. I've done that
> for you.
>> 
>> I refer to your patch at:
>> http://lists.xen.org/archives/html/xen-devel/2012-01/msg01927.html
>> which I found reading
>> http://www.gossamer-threads.com/lists/xen/devel/256197
>> 
>> I have a winfast DVT 2000H (cx88) DVB card which is not able to
>> scan/watch digital TV when running under Xen.
> 
> Did you first try running it under baremetal Linux (using a Live CD for
> example?) Did it work there?
> 
> How does it not work? Can you program it? Is this under a guest or the
> main kernel? When it wsa not working, did you try all the debug
> options enable (http://wiki.xen.org/wiki/XenSerialConsole) to
> see if there is anthing being reported?
> 
>> 
>> I've tried installing the above patch to the 3.6-rc6 kernel, but did
>> not seem to help.
>> 
>> Apologies if this has been asked before (I wasn't able to find another
>> patch), but is there a patch to get this (suspected vmalloc_32) fixed
>> and DVB card working?
> 
> Eventually yes.
>> 
>> FYI I'm running 64 bit 3.5-rc6 and xen 4.3-unstable.
> 
> 3.5-rc6 or 3.6-rc6?
> I presume the latter?
>> 
>> Thank you! :)
>> 
>> Regards,
>> 
>> John
>> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Sep 22 09:44:20 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 22 Sep 2012 09:44:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TFMFW-0007RC-G4; Sat, 22 Sep 2012 09:43:46 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1TFMFU-0007R7-C2
	for xen-devel@lists.xensource.com; Sat, 22 Sep 2012 09:43:44 +0000
Received: from [85.158.139.83:55142] by server-1.bemta-5.messagelabs.com id
	70/45-04809-F488D505; Sat, 22 Sep 2012 09:43:43 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1348307022!31929016!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTA3NTI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15460 invoked from network); 22 Sep 2012 09:43:42 -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 Sep 2012 09:43:42 -0000
X-IronPort-AV: E=Sophos;i="4.80,467,1344211200"; d="scan'208";a="14703749"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Sep 2012 09:43: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.279.1; Sat, 22 Sep 2012 10:43:42 +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 1TFMFR-0002aM-Ay;
	Sat, 22 Sep 2012 09:43:41 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1TFMFR-0002nl-AN;
	Sat, 22 Sep 2012 10:43:41 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-13841-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sat, 22 Sep 2012 10:43:41 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13841: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 13841 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13841/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-multivcpu  5 xen-boot                  fail REGR. vs. 13825
 test-amd64-i386-xl-win-vcpus1  5 xen-boot                 fail REGR. vs. 13825
 test-amd64-i386-qemuu-rhel6hvm-intel  5 xen-boot          fail REGR. vs. 13825
 test-amd64-i386-win-vcpus1    5 xen-boot                  fail REGR. vs. 13825
 test-amd64-i386-xl-win7-amd64  5 xen-boot                 fail REGR. vs. 13825
 test-amd64-amd64-win          5 xen-boot                  fail REGR. vs. 13825
 test-amd64-amd64-xl-winxpsp3  5 xen-boot                  fail REGR. vs. 13825
 test-amd64-i386-pair          8 xen-boot/dst_host         fail REGR. vs. 13825
 test-amd64-i386-pair          7 xen-boot/src_host         fail REGR. vs. 13825

Tests which are failing intermittently (not blocking):
 test-amd64-i386-rhel6hvm-intel  5 xen-boot                  fail pass in 13837
 test-amd64-i386-xl-credit2    5 xen-boot                    fail pass in 13837
 test-amd64-amd64-xl-win7-amd64 12 guest-localmigrate/x10 fail in 13837 pass in 13841

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore            fail   like 13825
 test-amd64-amd64-xl-pcipt-intel  5 xen-boot               fail REGR. vs. 13825
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail like 13823
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail like 13825
 test-amd64-amd64-xl-sedf      3 host-install(3)     broken in 13837 like 13825

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  8f658b463b78
baseline version:
 xen                  d364becfb083

------------------------------------------------------------
People who touched revisions under test:
  Jan Beulich <jbeulich@suse.com>
  Keir Fraser <keir@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-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                                   fail    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 fail    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-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-amd64-amd64-xl-win                                      fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
changeset:   25938:8f658b463b78
tag:         tip
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Sep 21 17:02:46 2012 +0200
    
    x86: enable VIA CPU support
    
    Newer VIA CPUs have both 64-bit and VMX support. Enable them to be
    recognized for these purposes, at once stripping off any 32-bit CPU
    only bits from the respective CPU support file, and adding 64-bit ones
    found in recent Linux.
    
    This particularly implies untying the VMX == Intel assumption in a few
    places.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   25937:32187301ecc5
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Sep 21 15:20:21 2012 +0200
    
    x86: eliminate code affecting only 64-bit-incapable CPUs
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   25936:c8873f13cec3
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Sep 21 14:25:12 2012 +0200
    
    printk: prefer %#x et at over 0x%x
    
    Performance is not an issue with printk(), so let the function do
    minimally more work and instead save a byte per affected format
    specifier.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   25935:1e6e6b49b4ac
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Sep 21 13:47:18 2012 +0200
    
    x86: introduce MWAIT-based, ACPI-less CPU idle driver
    
    This is a port of Linux'es intel-idle driver serving the same purpose.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   25934:8eab91903e71
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Sep 21 13:45:08 2012 +0200
    
    cpuidle: remove unused latency_ticks member
    
    ... and code used only for initializing it.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   25933:d364becfb083
user:        Jan Beulich <jbeulich@suse.com>
date:        Thu Sep 20 13:31:19 2012 +0200
    
    introduce guest_handle_for_field()
    
    This helper turns a field of a GUEST_HANDLE in a GUEST_HANDLE.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    
    
(qemu changes not included)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Sep 22 09:44:20 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 22 Sep 2012 09:44:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TFMFW-0007RC-G4; Sat, 22 Sep 2012 09:43:46 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1TFMFU-0007R7-C2
	for xen-devel@lists.xensource.com; Sat, 22 Sep 2012 09:43:44 +0000
Received: from [85.158.139.83:55142] by server-1.bemta-5.messagelabs.com id
	70/45-04809-F488D505; Sat, 22 Sep 2012 09:43:43 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1348307022!31929016!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTA3NTI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15460 invoked from network); 22 Sep 2012 09:43:42 -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 Sep 2012 09:43:42 -0000
X-IronPort-AV: E=Sophos;i="4.80,467,1344211200"; d="scan'208";a="14703749"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Sep 2012 09:43: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.279.1; Sat, 22 Sep 2012 10:43:42 +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 1TFMFR-0002aM-Ay;
	Sat, 22 Sep 2012 09:43:41 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1TFMFR-0002nl-AN;
	Sat, 22 Sep 2012 10:43:41 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-13841-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sat, 22 Sep 2012 10:43:41 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13841: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 13841 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13841/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-multivcpu  5 xen-boot                  fail REGR. vs. 13825
 test-amd64-i386-xl-win-vcpus1  5 xen-boot                 fail REGR. vs. 13825
 test-amd64-i386-qemuu-rhel6hvm-intel  5 xen-boot          fail REGR. vs. 13825
 test-amd64-i386-win-vcpus1    5 xen-boot                  fail REGR. vs. 13825
 test-amd64-i386-xl-win7-amd64  5 xen-boot                 fail REGR. vs. 13825
 test-amd64-amd64-win          5 xen-boot                  fail REGR. vs. 13825
 test-amd64-amd64-xl-winxpsp3  5 xen-boot                  fail REGR. vs. 13825
 test-amd64-i386-pair          8 xen-boot/dst_host         fail REGR. vs. 13825
 test-amd64-i386-pair          7 xen-boot/src_host         fail REGR. vs. 13825

Tests which are failing intermittently (not blocking):
 test-amd64-i386-rhel6hvm-intel  5 xen-boot                  fail pass in 13837
 test-amd64-i386-xl-credit2    5 xen-boot                    fail pass in 13837
 test-amd64-amd64-xl-win7-amd64 12 guest-localmigrate/x10 fail in 13837 pass in 13841

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore            fail   like 13825
 test-amd64-amd64-xl-pcipt-intel  5 xen-boot               fail REGR. vs. 13825
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail like 13823
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail like 13825
 test-amd64-amd64-xl-sedf      3 host-install(3)     broken in 13837 like 13825

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  8f658b463b78
baseline version:
 xen                  d364becfb083

------------------------------------------------------------
People who touched revisions under test:
  Jan Beulich <jbeulich@suse.com>
  Keir Fraser <keir@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-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                                   fail    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 fail    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-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-amd64-amd64-xl-win                                      fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
changeset:   25938:8f658b463b78
tag:         tip
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Sep 21 17:02:46 2012 +0200
    
    x86: enable VIA CPU support
    
    Newer VIA CPUs have both 64-bit and VMX support. Enable them to be
    recognized for these purposes, at once stripping off any 32-bit CPU
    only bits from the respective CPU support file, and adding 64-bit ones
    found in recent Linux.
    
    This particularly implies untying the VMX == Intel assumption in a few
    places.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   25937:32187301ecc5
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Sep 21 15:20:21 2012 +0200
    
    x86: eliminate code affecting only 64-bit-incapable CPUs
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   25936:c8873f13cec3
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Sep 21 14:25:12 2012 +0200
    
    printk: prefer %#x et at over 0x%x
    
    Performance is not an issue with printk(), so let the function do
    minimally more work and instead save a byte per affected format
    specifier.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   25935:1e6e6b49b4ac
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Sep 21 13:47:18 2012 +0200
    
    x86: introduce MWAIT-based, ACPI-less CPU idle driver
    
    This is a port of Linux'es intel-idle driver serving the same purpose.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   25934:8eab91903e71
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Sep 21 13:45:08 2012 +0200
    
    cpuidle: remove unused latency_ticks member
    
    ... and code used only for initializing it.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   25933:d364becfb083
user:        Jan Beulich <jbeulich@suse.com>
date:        Thu Sep 20 13:31:19 2012 +0200
    
    introduce guest_handle_for_field()
    
    This helper turns a field of a GUEST_HANDLE in a GUEST_HANDLE.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    
    
(qemu changes not included)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Sep 22 11:58:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 22 Sep 2012 11:58:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TFOLc-000858-Vs; Sat, 22 Sep 2012 11:58:12 +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 1TFOLb-000850-3Y
	for xen-devel@lists.xensource.com; Sat, 22 Sep 2012 11:58:11 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1348315084!10013111!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTA4MzA=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19877 invoked from network); 22 Sep 2012 11:58:04 -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 Sep 2012 11:58:04 -0000
X-IronPort-AV: E=Sophos;i="4.80,467,1344211200"; d="scan'208";a="14704156"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Sep 2012 11:58: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.279.1; Sat, 22 Sep 2012 12:58: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 1TFOLT-0004Uc-4m;
	Sat, 22 Sep 2012 11:58:03 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1TFOLT-00056I-0q;
	Sat, 22 Sep 2012 12:58:03 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <E1TFOLT-00056I-0q@woking.cam.xci-test.com>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sat, 22 Sep 2012 12:58:03 +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-i386-xl-multivcpu
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

branch xen-unstable
xen branch xen-unstable
job test-amd64-i386-xl-multivcpu
test xen-boot

Tree: linux git://xenbits.xen.org/linux-pvops.git
Tree: qemu git://xenbits.xen.org/staging/qemu-xen-unstable.git
Tree: qemuu git://xenbits.xen.org/staging/qemu-upstream-unstable.git
Tree: xen http://xenbits.xen.org/hg/staging/xen-unstable.hg

*** Found and reproduced problem changeset ***

  Bug is in tree:  xen http://xenbits.xen.org/hg/staging/xen-unstable.hg
  Bug introduced:  1e6e6b49b4ac
  Bug not present: 8eab91903e71


  changeset:   25935:1e6e6b49b4ac
  user:        Jan Beulich <jbeulich@suse.com>
  date:        Fri Sep 21 13:47:18 2012 +0200
      
      x86: introduce MWAIT-based, ACPI-less CPU idle driver
      
      This is a port of Linux'es intel-idle driver serving the same purpose.
      
      Signed-off-by: Jan Beulich <jbeulich@suse.com>
      Acked-by: Keir Fraser <keir@xen.org>
      
      


For bisection revision-tuple graph see:
   http://www.chiark.greenend.org.uk/~xensrcts/results/bisect.xen-unstable.test-amd64-i386-xl-multivcpu.xen-boot.html
Revision IDs in each graph node refer, respectively, to the Trees above.

----------------------------------------
Searching for failure / basis pass:
 13841 fail [host=earwig] / 13823 [host=lace-bug] 13821 [host=potato-beetle] 13819 [host=gall-mite] 13816 [host=leaf-beetle] 13812 ok.
Failure / basis pass flights: 13841 / 13812
Tree: linux git://xenbits.xen.org/linux-pvops.git
Tree: qemu git://xenbits.xen.org/staging/qemu-xen-unstable.git
Tree: qemuu git://xenbits.xen.org/staging/qemu-upstream-unstable.git
Tree: xen http://xenbits.xen.org/hg/staging/xen-unstable.hg
Latest a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 8f658b463b78
Basis pass a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 7b045d43e59d
Generating revisions with ./adhoc-revtuple-generator  git://xenbits.xen.org/linux-pvops.git#a938a246d34912423c560f475ccf1ce0c71d9d00-a938a246d34912423c560f475ccf1ce0c71d9d00 git://xenbits.xen.org/staging/qemu-xen-unstable.git#bacc0d302445c75f18f4c826750fb5853b60e7ca-bacc0d302445c75f18f4c826750fb5853b60e7ca git://xenbits.xen.org/staging/qemu-upstream-unstable.git#cdf4d2bb4006805f209712fbb8ed1f83127e9984-cdf4d2bb4006805f209712fbb8ed1f83127e9984 http://xenbits.xen.org/hg/staging/xen-unstable.hg#7b045d43e59d-8f658b463b78
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 117 nodes in revision graph
Searching for test results:
 13846 fail a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 1e6e6b49b4ac
 13827 fail a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 8f658b463b78
 13812 pass a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 7b045d43e59d
 13847 pass a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 8eab91903e71
 13816 [host=leaf-beetle]
 13838 pass a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 7b045d43e59d
 13819 [host=gall-mite]
 13839 fail a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 8f658b463b78
 13821 [host=potato-beetle]
 13849 fail a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 1e6e6b49b4ac
 13823 [host=lace-bug]
 13840 pass a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 d364becfb083
 13842 fail a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 1e6e6b49b4ac
 13843 pass a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 8eab91903e71
 13844 fail a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 1e6e6b49b4ac
 13841 fail a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 8f658b463b78
 13845 pass a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 8eab91903e71
Searching for interesting versions
 Result found: flight 13812 (pass), for basis pass
 Result found: flight 13827 (fail), for basis failure
 Repro found: flight 13838 (pass), for basis pass
 Repro found: flight 13839 (fail), for basis failure
 0 revisions at a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 8eab91903e71
No revisions left to test, checking graph state.
 Result found: flight 13843 (pass), for last pass
 Result found: flight 13844 (fail), for first failure
 Repro found: flight 13845 (pass), for last pass
 Repro found: flight 13846 (fail), for first failure
 Repro found: flight 13847 (pass), for last pass
 Repro found: flight 13849 (fail), for first failure

*** Found and reproduced problem changeset ***

  Bug is in tree:  xen http://xenbits.xen.org/hg/staging/xen-unstable.hg
  Bug introduced:  1e6e6b49b4ac
  Bug not present: 8eab91903e71

pulling from ssh://xen@xenbits.xen.org/HG/staging/xen-unstable.hg
searching for changes
no changes found

  changeset:   25935:1e6e6b49b4ac
  user:        Jan Beulich <jbeulich@suse.com>
  date:        Fri Sep 21 13:47:18 2012 +0200
      
      x86: introduce MWAIT-based, ACPI-less CPU idle driver
      
      This is a port of Linux'es intel-idle driver serving the same purpose.
      
      Signed-off-by: Jan Beulich <jbeulich@suse.com>
      Acked-by: Keir Fraser <keir@xen.org>
      
      

Revision graph left in /home/xc_osstest/results/bisect.xen-unstable.test-amd64-i386-xl-multivcpu.xen-boot.{dot,ps,png,html}.
----------------------------------------
13849: tolerable ALL FAIL

flight 13849 xen-unstable real-bisect [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13849/

Failures :-/ but no regressions.

Tests which did not succeed,
including tests which could not be run:
 test-amd64-i386-xl-multivcpu  5 xen-boot                fail baseline untested


jobs:
 test-amd64-i386-xl-multivcpu                                 fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Sep 22 11:58:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 22 Sep 2012 11:58:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TFOLc-000858-Vs; Sat, 22 Sep 2012 11:58:12 +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 1TFOLb-000850-3Y
	for xen-devel@lists.xensource.com; Sat, 22 Sep 2012 11:58:11 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1348315084!10013111!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTA4MzA=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19877 invoked from network); 22 Sep 2012 11:58:04 -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 Sep 2012 11:58:04 -0000
X-IronPort-AV: E=Sophos;i="4.80,467,1344211200"; d="scan'208";a="14704156"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Sep 2012 11:58: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.279.1; Sat, 22 Sep 2012 12:58: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 1TFOLT-0004Uc-4m;
	Sat, 22 Sep 2012 11:58:03 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1TFOLT-00056I-0q;
	Sat, 22 Sep 2012 12:58:03 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <E1TFOLT-00056I-0q@woking.cam.xci-test.com>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sat, 22 Sep 2012 12:58:03 +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-i386-xl-multivcpu
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

branch xen-unstable
xen branch xen-unstable
job test-amd64-i386-xl-multivcpu
test xen-boot

Tree: linux git://xenbits.xen.org/linux-pvops.git
Tree: qemu git://xenbits.xen.org/staging/qemu-xen-unstable.git
Tree: qemuu git://xenbits.xen.org/staging/qemu-upstream-unstable.git
Tree: xen http://xenbits.xen.org/hg/staging/xen-unstable.hg

*** Found and reproduced problem changeset ***

  Bug is in tree:  xen http://xenbits.xen.org/hg/staging/xen-unstable.hg
  Bug introduced:  1e6e6b49b4ac
  Bug not present: 8eab91903e71


  changeset:   25935:1e6e6b49b4ac
  user:        Jan Beulich <jbeulich@suse.com>
  date:        Fri Sep 21 13:47:18 2012 +0200
      
      x86: introduce MWAIT-based, ACPI-less CPU idle driver
      
      This is a port of Linux'es intel-idle driver serving the same purpose.
      
      Signed-off-by: Jan Beulich <jbeulich@suse.com>
      Acked-by: Keir Fraser <keir@xen.org>
      
      


For bisection revision-tuple graph see:
   http://www.chiark.greenend.org.uk/~xensrcts/results/bisect.xen-unstable.test-amd64-i386-xl-multivcpu.xen-boot.html
Revision IDs in each graph node refer, respectively, to the Trees above.

----------------------------------------
Searching for failure / basis pass:
 13841 fail [host=earwig] / 13823 [host=lace-bug] 13821 [host=potato-beetle] 13819 [host=gall-mite] 13816 [host=leaf-beetle] 13812 ok.
Failure / basis pass flights: 13841 / 13812
Tree: linux git://xenbits.xen.org/linux-pvops.git
Tree: qemu git://xenbits.xen.org/staging/qemu-xen-unstable.git
Tree: qemuu git://xenbits.xen.org/staging/qemu-upstream-unstable.git
Tree: xen http://xenbits.xen.org/hg/staging/xen-unstable.hg
Latest a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 8f658b463b78
Basis pass a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 7b045d43e59d
Generating revisions with ./adhoc-revtuple-generator  git://xenbits.xen.org/linux-pvops.git#a938a246d34912423c560f475ccf1ce0c71d9d00-a938a246d34912423c560f475ccf1ce0c71d9d00 git://xenbits.xen.org/staging/qemu-xen-unstable.git#bacc0d302445c75f18f4c826750fb5853b60e7ca-bacc0d302445c75f18f4c826750fb5853b60e7ca git://xenbits.xen.org/staging/qemu-upstream-unstable.git#cdf4d2bb4006805f209712fbb8ed1f83127e9984-cdf4d2bb4006805f209712fbb8ed1f83127e9984 http://xenbits.xen.org/hg/staging/xen-unstable.hg#7b045d43e59d-8f658b463b78
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 117 nodes in revision graph
Searching for test results:
 13846 fail a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 1e6e6b49b4ac
 13827 fail a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 8f658b463b78
 13812 pass a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 7b045d43e59d
 13847 pass a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 8eab91903e71
 13816 [host=leaf-beetle]
 13838 pass a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 7b045d43e59d
 13819 [host=gall-mite]
 13839 fail a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 8f658b463b78
 13821 [host=potato-beetle]
 13849 fail a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 1e6e6b49b4ac
 13823 [host=lace-bug]
 13840 pass a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 d364becfb083
 13842 fail a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 1e6e6b49b4ac
 13843 pass a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 8eab91903e71
 13844 fail a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 1e6e6b49b4ac
 13841 fail a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 8f658b463b78
 13845 pass a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 8eab91903e71
Searching for interesting versions
 Result found: flight 13812 (pass), for basis pass
 Result found: flight 13827 (fail), for basis failure
 Repro found: flight 13838 (pass), for basis pass
 Repro found: flight 13839 (fail), for basis failure
 0 revisions at a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 8eab91903e71
No revisions left to test, checking graph state.
 Result found: flight 13843 (pass), for last pass
 Result found: flight 13844 (fail), for first failure
 Repro found: flight 13845 (pass), for last pass
 Repro found: flight 13846 (fail), for first failure
 Repro found: flight 13847 (pass), for last pass
 Repro found: flight 13849 (fail), for first failure

*** Found and reproduced problem changeset ***

  Bug is in tree:  xen http://xenbits.xen.org/hg/staging/xen-unstable.hg
  Bug introduced:  1e6e6b49b4ac
  Bug not present: 8eab91903e71

pulling from ssh://xen@xenbits.xen.org/HG/staging/xen-unstable.hg
searching for changes
no changes found

  changeset:   25935:1e6e6b49b4ac
  user:        Jan Beulich <jbeulich@suse.com>
  date:        Fri Sep 21 13:47:18 2012 +0200
      
      x86: introduce MWAIT-based, ACPI-less CPU idle driver
      
      This is a port of Linux'es intel-idle driver serving the same purpose.
      
      Signed-off-by: Jan Beulich <jbeulich@suse.com>
      Acked-by: Keir Fraser <keir@xen.org>
      
      

Revision graph left in /home/xc_osstest/results/bisect.xen-unstable.test-amd64-i386-xl-multivcpu.xen-boot.{dot,ps,png,html}.
----------------------------------------
13849: tolerable ALL FAIL

flight 13849 xen-unstable real-bisect [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13849/

Failures :-/ but no regressions.

Tests which did not succeed,
including tests which could not be run:
 test-amd64-i386-xl-multivcpu  5 xen-boot                fail baseline untested


jobs:
 test-amd64-i386-xl-multivcpu                                 fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Sep 22 13:11:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 22 Sep 2012 13: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 1TFPTd-0000GI-KX; Sat, 22 Sep 2012 13:10:33 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <julian.pidancet@gmail.com>) id 1TFPTc-0000GD-6Q
	for xen-devel@lists.xen.org; Sat, 22 Sep 2012 13:10:32 +0000
Received: from [85.158.139.83:59107] by server-13.bemta-5.messagelabs.com id
	61/FB-23645-7C8BD505; Sat, 22 Sep 2012 13:10:31 +0000
X-Env-Sender: julian.pidancet@gmail.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1348319430!27378618!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-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27496 invoked from network); 22 Sep 2012 13:10:30 -0000
Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com)
	(74.125.83.45)
	by server-14.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Sep 2012 13:10:30 -0000
Received: by eeke53 with SMTP id e53so1937949eek.32
	for <xen-devel@lists.xen.org>; Sat, 22 Sep 2012 06:10:30 -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=jO+EsZRYfG39qXXr9N639SrRt3XuWL1V2oq5UlnkV84=;
	b=fe2M1HRQwM6VUfhSFywmvCtFodpj8ctEtMBP+j2n29Njf7NQmPkx/z1+F/JXf0XvB6
	hqhobCLVi4Vaii9CVDYhDZPyK3be1BUfBGBOT6+moLKqYLIP95QtQYIpdUcUcveQP+7b
	P0ivCT6peSRbY8aWWegQDFYXz3qeuziRV0gOew0DzFaYgVwNyJL8AEcNCxFb0hNfpOTf
	PTxBpPSDxvXcDMOY2/9u951ScY0JXJ5MamOM0H0ILWs5aF9IIcm8vQvgJOyrHA85nzm2
	JYnD6jxYqz0/nWN+U8s73vG+Qhd+wPfQXxTl++GJDStnQk6Qurjm/sIvgA0AX5pvcXxl
	HbjQ==
Received: by 10.14.220.8 with SMTP id n8mr8863642eep.19.1348319430425;
	Sat, 22 Sep 2012 06:10:30 -0700 (PDT)
Received: from [192.168.1.110] (188-223-88-44.zone14.bethere.co.uk.
	[188.223.88.44])
	by mx.google.com with ESMTPS id r45sm31377038eem.6.2012.09.22.06.10.28
	(version=SSLv3 cipher=OTHER); Sat, 22 Sep 2012 06:10:29 -0700 (PDT)
Message-ID: <505DC16E.6050303@gmail.com>
Date: Sat, 22 Sep 2012 14:47:26 +0100
From: Julian Pidancet <julian.pidancet@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:10.0.7) Gecko/20120918 Thunderbird/10.0.7
MIME-Version: 1.0
To: Jean Guyader <jean.guyader@citrix.com>
References: <1348141322-28657-1-git-send-email-jean.guyader@citrix.com>
	<1348141322-28657-5-git-send-email-jean.guyader@citrix.com>
In-Reply-To: <1348141322-28657-5-git-send-email-jean.guyader@citrix.com>
Cc: tim@xen.org, JBeulich@suse.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 4/4] 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 09/20/12 12:42, Jean Guyader wrote:
> 
> 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.
> 

Could we rename "viptables" in "v4vtables", or something that doesn't
contain "IP" in the name ? Since IP is a totally unrelated protocol, it
doesn't make sense here.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Sep 22 13:11:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 22 Sep 2012 13: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 1TFPTd-0000GI-KX; Sat, 22 Sep 2012 13:10:33 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <julian.pidancet@gmail.com>) id 1TFPTc-0000GD-6Q
	for xen-devel@lists.xen.org; Sat, 22 Sep 2012 13:10:32 +0000
Received: from [85.158.139.83:59107] by server-13.bemta-5.messagelabs.com id
	61/FB-23645-7C8BD505; Sat, 22 Sep 2012 13:10:31 +0000
X-Env-Sender: julian.pidancet@gmail.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1348319430!27378618!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-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27496 invoked from network); 22 Sep 2012 13:10:30 -0000
Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com)
	(74.125.83.45)
	by server-14.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Sep 2012 13:10:30 -0000
Received: by eeke53 with SMTP id e53so1937949eek.32
	for <xen-devel@lists.xen.org>; Sat, 22 Sep 2012 06:10:30 -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=jO+EsZRYfG39qXXr9N639SrRt3XuWL1V2oq5UlnkV84=;
	b=fe2M1HRQwM6VUfhSFywmvCtFodpj8ctEtMBP+j2n29Njf7NQmPkx/z1+F/JXf0XvB6
	hqhobCLVi4Vaii9CVDYhDZPyK3be1BUfBGBOT6+moLKqYLIP95QtQYIpdUcUcveQP+7b
	P0ivCT6peSRbY8aWWegQDFYXz3qeuziRV0gOew0DzFaYgVwNyJL8AEcNCxFb0hNfpOTf
	PTxBpPSDxvXcDMOY2/9u951ScY0JXJ5MamOM0H0ILWs5aF9IIcm8vQvgJOyrHA85nzm2
	JYnD6jxYqz0/nWN+U8s73vG+Qhd+wPfQXxTl++GJDStnQk6Qurjm/sIvgA0AX5pvcXxl
	HbjQ==
Received: by 10.14.220.8 with SMTP id n8mr8863642eep.19.1348319430425;
	Sat, 22 Sep 2012 06:10:30 -0700 (PDT)
Received: from [192.168.1.110] (188-223-88-44.zone14.bethere.co.uk.
	[188.223.88.44])
	by mx.google.com with ESMTPS id r45sm31377038eem.6.2012.09.22.06.10.28
	(version=SSLv3 cipher=OTHER); Sat, 22 Sep 2012 06:10:29 -0700 (PDT)
Message-ID: <505DC16E.6050303@gmail.com>
Date: Sat, 22 Sep 2012 14:47:26 +0100
From: Julian Pidancet <julian.pidancet@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:10.0.7) Gecko/20120918 Thunderbird/10.0.7
MIME-Version: 1.0
To: Jean Guyader <jean.guyader@citrix.com>
References: <1348141322-28657-1-git-send-email-jean.guyader@citrix.com>
	<1348141322-28657-5-git-send-email-jean.guyader@citrix.com>
In-Reply-To: <1348141322-28657-5-git-send-email-jean.guyader@citrix.com>
Cc: tim@xen.org, JBeulich@suse.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 4/4] 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 09/20/12 12:42, Jean Guyader wrote:
> 
> 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.
> 

Could we rename "viptables" in "v4vtables", or something that doesn't
contain "IP" in the name ? Since IP is a totally unrelated protocol, it
doesn't make sense here.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Sep 22 13:28:48 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 22 Sep 2012 13:28:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TFPkm-0000Qv-Al; Sat, 22 Sep 2012 13:28:16 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ketuzsezr@gmail.com>) id 1TFPkk-0000Qq-Ht
	for xen-devel@lists.xensource.com; Sat, 22 Sep 2012 13:28:14 +0000
Received: from [85.158.139.211:13652] by server-6.bemta-5.messagelabs.com id
	88/75-21336-DECBD505; Sat, 22 Sep 2012 13:28:13 +0000
X-Env-Sender: ketuzsezr@gmail.com
X-Msg-Ref: server-8.tower-206.messagelabs.com!1348320489!19538980!1
X-Originating-IP: [209.85.160.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13991 invoked from network); 22 Sep 2012 13:28:11 -0000
Received: from mail-pb0-f43.google.com (HELO mail-pb0-f43.google.com)
	(209.85.160.43)
	by server-8.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Sep 2012 13:28:11 -0000
Received: by pbbrq2 with SMTP id rq2so12148215pbb.30
	for <xen-devel@lists.xensource.com>;
	Sat, 22 Sep 2012 06:28:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
	bh=RmPTeeXcynXDRrj8cPNOOTUumUj2WN+XqxqqyH6dpz8=;
	b=QvbApQZT+bMWnV+oTM3pj88uHKalLX07UNj4gl6/ceqfWNkzyQQMFPJ0NlArv1wYet
	iOcPi/VKZcYPfl7QfOBmRPWLEAn2Bq6QTf5cRufVG2YMKVNZxwvcF2cNkuqTK4ZAGgYV
	eH8gaZy9fdNXziZxFiqLNeqYUTKWCkSh3w5wjquP/8oqQwFAHILdAHyUla+PFvwqm9Tc
	zp9Rk5dwOSdzhm63KqUXqDDHonPiqKT03BJXqLHhqSmAxDMbc+2ALPoWv5c6/K9niQ9D
	2MDn05vxcpHHOCZ9MTQorjEKlPLt0xlWAWF+Ulrzv32gnkopAOINLRk8E2I7SV67S8sn
	gliw==
MIME-Version: 1.0
Received: by 10.68.200.72 with SMTP id jq8mr14811704pbc.38.1348320489247; Sat,
	22 Sep 2012 06:28:09 -0700 (PDT)
Received: by 10.66.193.9 with HTTP; Sat, 22 Sep 2012 06:28:09 -0700 (PDT)
In-Reply-To: <1347306367-28669-1-git-send-email-konrad.wilk@oracle.com>
References: <1347306367-28669-1-git-send-email-konrad.wilk@oracle.com>
Date: Sat, 22 Sep 2012 09:28:09 -0400
X-Google-Sender-Auth: FOPo6sFOLkjnm_mG4tFtAHE4wvc
Message-ID: <CACJDEmreY+MS8Rz_Y+wk0BdAA0PsOeQ3SAEbysLT+J-PqnKSbw@mail.gmail.com>
From: Konrad Rzeszutek Wilk <konrad@kernel.org>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org,
	stefano.stabellini@eu.citrix.com
Subject: Re: [Xen-devel] [PATCH] Xen-SWIOTLB fixes (v4) for v3.7
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 it to use an io_tlb passed in. Note: I hadn't tested this
> on IA64 and that is something I need to do.

Done. I got my hands on a HP zx6000 and the patch series did not show
any regressions.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Sep 22 13:28:48 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 22 Sep 2012 13:28:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TFPkm-0000Qv-Al; Sat, 22 Sep 2012 13:28:16 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ketuzsezr@gmail.com>) id 1TFPkk-0000Qq-Ht
	for xen-devel@lists.xensource.com; Sat, 22 Sep 2012 13:28:14 +0000
Received: from [85.158.139.211:13652] by server-6.bemta-5.messagelabs.com id
	88/75-21336-DECBD505; Sat, 22 Sep 2012 13:28:13 +0000
X-Env-Sender: ketuzsezr@gmail.com
X-Msg-Ref: server-8.tower-206.messagelabs.com!1348320489!19538980!1
X-Originating-IP: [209.85.160.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13991 invoked from network); 22 Sep 2012 13:28:11 -0000
Received: from mail-pb0-f43.google.com (HELO mail-pb0-f43.google.com)
	(209.85.160.43)
	by server-8.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Sep 2012 13:28:11 -0000
Received: by pbbrq2 with SMTP id rq2so12148215pbb.30
	for <xen-devel@lists.xensource.com>;
	Sat, 22 Sep 2012 06:28:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
	bh=RmPTeeXcynXDRrj8cPNOOTUumUj2WN+XqxqqyH6dpz8=;
	b=QvbApQZT+bMWnV+oTM3pj88uHKalLX07UNj4gl6/ceqfWNkzyQQMFPJ0NlArv1wYet
	iOcPi/VKZcYPfl7QfOBmRPWLEAn2Bq6QTf5cRufVG2YMKVNZxwvcF2cNkuqTK4ZAGgYV
	eH8gaZy9fdNXziZxFiqLNeqYUTKWCkSh3w5wjquP/8oqQwFAHILdAHyUla+PFvwqm9Tc
	zp9Rk5dwOSdzhm63KqUXqDDHonPiqKT03BJXqLHhqSmAxDMbc+2ALPoWv5c6/K9niQ9D
	2MDn05vxcpHHOCZ9MTQorjEKlPLt0xlWAWF+Ulrzv32gnkopAOINLRk8E2I7SV67S8sn
	gliw==
MIME-Version: 1.0
Received: by 10.68.200.72 with SMTP id jq8mr14811704pbc.38.1348320489247; Sat,
	22 Sep 2012 06:28:09 -0700 (PDT)
Received: by 10.66.193.9 with HTTP; Sat, 22 Sep 2012 06:28:09 -0700 (PDT)
In-Reply-To: <1347306367-28669-1-git-send-email-konrad.wilk@oracle.com>
References: <1347306367-28669-1-git-send-email-konrad.wilk@oracle.com>
Date: Sat, 22 Sep 2012 09:28:09 -0400
X-Google-Sender-Auth: FOPo6sFOLkjnm_mG4tFtAHE4wvc
Message-ID: <CACJDEmreY+MS8Rz_Y+wk0BdAA0PsOeQ3SAEbysLT+J-PqnKSbw@mail.gmail.com>
From: Konrad Rzeszutek Wilk <konrad@kernel.org>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org,
	stefano.stabellini@eu.citrix.com
Subject: Re: [Xen-devel] [PATCH] Xen-SWIOTLB fixes (v4) for v3.7
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 it to use an io_tlb passed in. Note: I hadn't tested this
> on IA64 and that is something I need to do.

Done. I got my hands on a HP zx6000 and the patch series did not show
any regressions.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Sep 22 15:19:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 22 Sep 2012 15:19:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TFRTV-0001hG-TI; Sat, 22 Sep 2012 15:18: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 1TFRTV-0001hB-5v
	for xen-devel@lists.xensource.com; Sat, 22 Sep 2012 15:18:33 +0000
Received: from [85.158.143.35:5782] by server-1.bemta-4.messagelabs.com id
	66/F6-05684-8C6DD505; Sat, 22 Sep 2012 15:18:32 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1348327111!13306843!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTA4MzA=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8421 invoked from network); 22 Sep 2012 15:18:31 -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;
	22 Sep 2012 15:18:31 -0000
X-IronPort-AV: E=Sophos;i="4.80,467,1344211200"; d="scan'208";a="14704802"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Sep 2012 15:18:31 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Sat, 22 Sep 2012 16:18: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 1TFRTS-0006AH-Ly;
	Sat, 22 Sep 2012 15:18:30 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1TFRTS-0004Do-Du;
	Sat, 22 Sep 2012 16:18:30 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-13848-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sat, 22 Sep 2012 16:18:30 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13848: regressions - trouble:
	broken/fail/pass
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 13848 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13848/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-multivcpu  5 xen-boot                  fail REGR. vs. 13825
 test-amd64-i386-xl-win-vcpus1  5 xen-boot                 fail REGR. vs. 13825
 test-amd64-i386-qemuu-rhel6hvm-intel  5 xen-boot          fail REGR. vs. 13825
 test-amd64-i386-xl-win7-amd64  5 xen-boot                 fail REGR. vs. 13825
 test-amd64-amd64-win          5 xen-boot                  fail REGR. vs. 13825
 test-amd64-amd64-xl-winxpsp3  5 xen-boot                  fail REGR. vs. 13825
 test-amd64-i386-pair          8 xen-boot/dst_host         fail REGR. vs. 13825
 test-amd64-i386-pair          7 xen-boot/src_host         fail REGR. vs. 13825
 test-amd64-i386-win-vcpus1    5 xen-boot         fail in 13837 REGR. vs. 13825

Tests which are failing intermittently (not blocking):
 test-amd64-i386-rhel6hvm-intel  5 xen-boot                  fail pass in 13837
 test-amd64-amd64-pv           5 xen-boot                    fail pass in 13841
 test-amd64-i386-xl-credit2    3 host-install(3)           broken pass in 13841
 test-amd64-i386-win-vcpus1    3 host-install(3)           broken pass in 13841
 test-amd64-amd64-xl-win7-amd64 12 guest-localmigrate/x10 fail in 13837 pass in 13848
 test-amd64-i386-xl-credit2    5 xen-boot           fail in 13841 pass in 13837

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore            fail   like 13825
 test-amd64-amd64-xl-pcipt-intel  5 xen-boot               fail REGR. vs. 13825
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail like 13823
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail like 13825
 test-amd64-amd64-xl-sedf      3 host-install(3)     broken in 13837 like 13825

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  8f658b463b78
baseline version:
 xen                  d364becfb083

------------------------------------------------------------
People who touched revisions under test:
  Jan Beulich <jbeulich@suse.com>
  Keir Fraser <keir@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-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                                   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                                 fail    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          fail    
 test-amd64-i386-pv                                           pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   broken  
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-amd64-amd64-xl-win                                      fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
changeset:   25938:8f658b463b78
tag:         tip
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Sep 21 17:02:46 2012 +0200
    
    x86: enable VIA CPU support
    
    Newer VIA CPUs have both 64-bit and VMX support. Enable them to be
    recognized for these purposes, at once stripping off any 32-bit CPU
    only bits from the respective CPU support file, and adding 64-bit ones
    found in recent Linux.
    
    This particularly implies untying the VMX == Intel assumption in a few
    places.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   25937:32187301ecc5
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Sep 21 15:20:21 2012 +0200
    
    x86: eliminate code affecting only 64-bit-incapable CPUs
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   25936:c8873f13cec3
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Sep 21 14:25:12 2012 +0200
    
    printk: prefer %#x et at over 0x%x
    
    Performance is not an issue with printk(), so let the function do
    minimally more work and instead save a byte per affected format
    specifier.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   25935:1e6e6b49b4ac
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Sep 21 13:47:18 2012 +0200
    
    x86: introduce MWAIT-based, ACPI-less CPU idle driver
    
    This is a port of Linux'es intel-idle driver serving the same purpose.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   25934:8eab91903e71
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Sep 21 13:45:08 2012 +0200
    
    cpuidle: remove unused latency_ticks member
    
    ... and code used only for initializing it.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   25933:d364becfb083
user:        Jan Beulich <jbeulich@suse.com>
date:        Thu Sep 20 13:31:19 2012 +0200
    
    introduce guest_handle_for_field()
    
    This helper turns a field of a GUEST_HANDLE in a GUEST_HANDLE.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    
    
(qemu changes not included)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Sep 22 15:19:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 22 Sep 2012 15:19:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TFRTV-0001hG-TI; Sat, 22 Sep 2012 15:18: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 1TFRTV-0001hB-5v
	for xen-devel@lists.xensource.com; Sat, 22 Sep 2012 15:18:33 +0000
Received: from [85.158.143.35:5782] by server-1.bemta-4.messagelabs.com id
	66/F6-05684-8C6DD505; Sat, 22 Sep 2012 15:18:32 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1348327111!13306843!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTA4MzA=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8421 invoked from network); 22 Sep 2012 15:18:31 -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;
	22 Sep 2012 15:18:31 -0000
X-IronPort-AV: E=Sophos;i="4.80,467,1344211200"; d="scan'208";a="14704802"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Sep 2012 15:18:31 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Sat, 22 Sep 2012 16:18: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 1TFRTS-0006AH-Ly;
	Sat, 22 Sep 2012 15:18:30 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1TFRTS-0004Do-Du;
	Sat, 22 Sep 2012 16:18:30 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-13848-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sat, 22 Sep 2012 16:18:30 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13848: regressions - trouble:
	broken/fail/pass
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 13848 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13848/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-multivcpu  5 xen-boot                  fail REGR. vs. 13825
 test-amd64-i386-xl-win-vcpus1  5 xen-boot                 fail REGR. vs. 13825
 test-amd64-i386-qemuu-rhel6hvm-intel  5 xen-boot          fail REGR. vs. 13825
 test-amd64-i386-xl-win7-amd64  5 xen-boot                 fail REGR. vs. 13825
 test-amd64-amd64-win          5 xen-boot                  fail REGR. vs. 13825
 test-amd64-amd64-xl-winxpsp3  5 xen-boot                  fail REGR. vs. 13825
 test-amd64-i386-pair          8 xen-boot/dst_host         fail REGR. vs. 13825
 test-amd64-i386-pair          7 xen-boot/src_host         fail REGR. vs. 13825
 test-amd64-i386-win-vcpus1    5 xen-boot         fail in 13837 REGR. vs. 13825

Tests which are failing intermittently (not blocking):
 test-amd64-i386-rhel6hvm-intel  5 xen-boot                  fail pass in 13837
 test-amd64-amd64-pv           5 xen-boot                    fail pass in 13841
 test-amd64-i386-xl-credit2    3 host-install(3)           broken pass in 13841
 test-amd64-i386-win-vcpus1    3 host-install(3)           broken pass in 13841
 test-amd64-amd64-xl-win7-amd64 12 guest-localmigrate/x10 fail in 13837 pass in 13848
 test-amd64-i386-xl-credit2    5 xen-boot           fail in 13841 pass in 13837

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore            fail   like 13825
 test-amd64-amd64-xl-pcipt-intel  5 xen-boot               fail REGR. vs. 13825
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail like 13823
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail like 13825
 test-amd64-amd64-xl-sedf      3 host-install(3)     broken in 13837 like 13825

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  8f658b463b78
baseline version:
 xen                  d364becfb083

------------------------------------------------------------
People who touched revisions under test:
  Jan Beulich <jbeulich@suse.com>
  Keir Fraser <keir@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-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                                   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                                 fail    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          fail    
 test-amd64-i386-pv                                           pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   broken  
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-amd64-amd64-xl-win                                      fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
changeset:   25938:8f658b463b78
tag:         tip
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Sep 21 17:02:46 2012 +0200
    
    x86: enable VIA CPU support
    
    Newer VIA CPUs have both 64-bit and VMX support. Enable them to be
    recognized for these purposes, at once stripping off any 32-bit CPU
    only bits from the respective CPU support file, and adding 64-bit ones
    found in recent Linux.
    
    This particularly implies untying the VMX == Intel assumption in a few
    places.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   25937:32187301ecc5
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Sep 21 15:20:21 2012 +0200
    
    x86: eliminate code affecting only 64-bit-incapable CPUs
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   25936:c8873f13cec3
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Sep 21 14:25:12 2012 +0200
    
    printk: prefer %#x et at over 0x%x
    
    Performance is not an issue with printk(), so let the function do
    minimally more work and instead save a byte per affected format
    specifier.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   25935:1e6e6b49b4ac
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Sep 21 13:47:18 2012 +0200
    
    x86: introduce MWAIT-based, ACPI-less CPU idle driver
    
    This is a port of Linux'es intel-idle driver serving the same purpose.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   25934:8eab91903e71
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Sep 21 13:45:08 2012 +0200
    
    cpuidle: remove unused latency_ticks member
    
    ... and code used only for initializing it.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   25933:d364becfb083
user:        Jan Beulich <jbeulich@suse.com>
date:        Thu Sep 20 13:31:19 2012 +0200
    
    introduce guest_handle_for_field()
    
    This helper turns a field of a GUEST_HANDLE in a GUEST_HANDLE.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    
    
(qemu changes not included)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Sep 22 16:41:02 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 22 Sep 2012 16:41:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TFSks-0002of-St; Sat, 22 Sep 2012 16:40: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 1TFSkr-0002oa-BY
	for xen-devel@lists.xensource.com; Sat, 22 Sep 2012 16:40:33 +0000
Received: from [85.158.137.99:53444] by server-4.bemta-3.messagelabs.com id
	13/66-24831-00AED505; Sat, 22 Sep 2012 16:40:32 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-217.messagelabs.com!1348332031!15569331!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTA4MzA=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27011 invoked from network); 22 Sep 2012 16:40:31 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Sep 2012 16:40:31 -0000
X-IronPort-AV: E=Sophos;i="4.80,467,1344211200"; d="scan'208";a="14705109"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Sep 2012 16:40: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.279.1; Sat, 22 Sep 2012 17:40: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 1TFSkn-0007HJ-R6;
	Sat, 22 Sep 2012 16:40:29 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1TFSkn-0000pY-Qe;
	Sat, 22 Sep 2012 17:40:29 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-13850-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sat, 22 Sep 2012 17:40:29 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13850: trouble: blocked/broken/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 13850 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13850/

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64                   2 host-install(2)         broken REGR. vs. 13825
 build-amd64-oldkern           2 host-install(2)         broken REGR. vs. 13825
 build-amd64-pvops             2 host-install(2)         broken REGR. vs. 13825

Tests which did not succeed, but are not blocking:
 test-amd64-i386-rhel6hvm-amd  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 xen-build-check(1)           blocked n/a
 test-amd64-amd64-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf-pin  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xend-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win           1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf      1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-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-amd64-i386-xl-multivcpu  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-qemuu-rhel6hvm-intel  1 xen-build-check(1)         blocked n/a
 test-amd64-i386-pv            1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-pcipt-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win-vcpus1    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-winxpsp3-vcpus1  1 xen-build-check(1)           blocked n/a
 test-amd64-i386-xl            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-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-win          1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 xen-build-check(1)         blocked n/a
 test-amd64-amd64-xl-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-pair         1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pair          1 xen-build-check(1)           blocked  n/a

version targeted for testing:
 xen                  8f658b463b78
baseline version:
 xen                  d364becfb083

------------------------------------------------------------
People who touched revisions under test:
  Jan Beulich <jbeulich@suse.com>
  Keir Fraser <keir@xen.org>
------------------------------------------------------------

jobs:
 build-amd64                                                  broken  
 build-i386                                                   pass    
 build-amd64-oldkern                                          broken  
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            broken  
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          blocked 
 test-amd64-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-amd64-amd64-xl-sedf-pin                                 blocked 
 test-amd64-amd64-pv                                          blocked 
 test-amd64-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-amd64-amd64-xl-win                                      blocked 
 test-amd64-amd64-xl-qemuu-winxpsp3                           blocked 
 test-amd64-i386-xend-winxpsp3                                blocked 
 test-amd64-amd64-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.

------------------------------------------------------------
changeset:   25938:8f658b463b78
tag:         tip
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Sep 21 17:02:46 2012 +0200
    
    x86: enable VIA CPU support
    
    Newer VIA CPUs have both 64-bit and VMX support. Enable them to be
    recognized for these purposes, at once stripping off any 32-bit CPU
    only bits from the respective CPU support file, and adding 64-bit ones
    found in recent Linux.
    
    This particularly implies untying the VMX == Intel assumption in a few
    places.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   25937:32187301ecc5
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Sep 21 15:20:21 2012 +0200
    
    x86: eliminate code affecting only 64-bit-incapable CPUs
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   25936:c8873f13cec3
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Sep 21 14:25:12 2012 +0200
    
    printk: prefer %#x et at over 0x%x
    
    Performance is not an issue with printk(), so let the function do
    minimally more work and instead save a byte per affected format
    specifier.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   25935:1e6e6b49b4ac
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Sep 21 13:47:18 2012 +0200
    
    x86: introduce MWAIT-based, ACPI-less CPU idle driver
    
    This is a port of Linux'es intel-idle driver serving the same purpose.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   25934:8eab91903e71
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Sep 21 13:45:08 2012 +0200
    
    cpuidle: remove unused latency_ticks member
    
    ... and code used only for initializing it.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   25933:d364becfb083
user:        Jan Beulich <jbeulich@suse.com>
date:        Thu Sep 20 13:31:19 2012 +0200
    
    introduce guest_handle_for_field()
    
    This helper turns a field of a GUEST_HANDLE in a GUEST_HANDLE.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    
    
(qemu changes not included)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Sep 22 16:41:02 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 22 Sep 2012 16:41:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TFSks-0002of-St; Sat, 22 Sep 2012 16:40: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 1TFSkr-0002oa-BY
	for xen-devel@lists.xensource.com; Sat, 22 Sep 2012 16:40:33 +0000
Received: from [85.158.137.99:53444] by server-4.bemta-3.messagelabs.com id
	13/66-24831-00AED505; Sat, 22 Sep 2012 16:40:32 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-217.messagelabs.com!1348332031!15569331!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTA4MzA=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27011 invoked from network); 22 Sep 2012 16:40:31 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Sep 2012 16:40:31 -0000
X-IronPort-AV: E=Sophos;i="4.80,467,1344211200"; d="scan'208";a="14705109"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Sep 2012 16:40: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.279.1; Sat, 22 Sep 2012 17:40: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 1TFSkn-0007HJ-R6;
	Sat, 22 Sep 2012 16:40:29 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1TFSkn-0000pY-Qe;
	Sat, 22 Sep 2012 17:40:29 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-13850-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sat, 22 Sep 2012 17:40:29 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13850: trouble: blocked/broken/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 13850 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13850/

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64                   2 host-install(2)         broken REGR. vs. 13825
 build-amd64-oldkern           2 host-install(2)         broken REGR. vs. 13825
 build-amd64-pvops             2 host-install(2)         broken REGR. vs. 13825

Tests which did not succeed, but are not blocking:
 test-amd64-i386-rhel6hvm-amd  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 xen-build-check(1)           blocked n/a
 test-amd64-amd64-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf-pin  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xend-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win           1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf      1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-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-amd64-i386-xl-multivcpu  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-qemuu-rhel6hvm-intel  1 xen-build-check(1)         blocked n/a
 test-amd64-i386-pv            1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-pcipt-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win-vcpus1    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-winxpsp3-vcpus1  1 xen-build-check(1)           blocked n/a
 test-amd64-i386-xl            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-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-win          1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 xen-build-check(1)         blocked n/a
 test-amd64-amd64-xl-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-pair         1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pair          1 xen-build-check(1)           blocked  n/a

version targeted for testing:
 xen                  8f658b463b78
baseline version:
 xen                  d364becfb083

------------------------------------------------------------
People who touched revisions under test:
  Jan Beulich <jbeulich@suse.com>
  Keir Fraser <keir@xen.org>
------------------------------------------------------------

jobs:
 build-amd64                                                  broken  
 build-i386                                                   pass    
 build-amd64-oldkern                                          broken  
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            broken  
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          blocked 
 test-amd64-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-amd64-amd64-xl-sedf-pin                                 blocked 
 test-amd64-amd64-pv                                          blocked 
 test-amd64-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-amd64-amd64-xl-win                                      blocked 
 test-amd64-amd64-xl-qemuu-winxpsp3                           blocked 
 test-amd64-i386-xend-winxpsp3                                blocked 
 test-amd64-amd64-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.

------------------------------------------------------------
changeset:   25938:8f658b463b78
tag:         tip
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Sep 21 17:02:46 2012 +0200
    
    x86: enable VIA CPU support
    
    Newer VIA CPUs have both 64-bit and VMX support. Enable them to be
    recognized for these purposes, at once stripping off any 32-bit CPU
    only bits from the respective CPU support file, and adding 64-bit ones
    found in recent Linux.
    
    This particularly implies untying the VMX == Intel assumption in a few
    places.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   25937:32187301ecc5
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Sep 21 15:20:21 2012 +0200
    
    x86: eliminate code affecting only 64-bit-incapable CPUs
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   25936:c8873f13cec3
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Sep 21 14:25:12 2012 +0200
    
    printk: prefer %#x et at over 0x%x
    
    Performance is not an issue with printk(), so let the function do
    minimally more work and instead save a byte per affected format
    specifier.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   25935:1e6e6b49b4ac
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Sep 21 13:47:18 2012 +0200
    
    x86: introduce MWAIT-based, ACPI-less CPU idle driver
    
    This is a port of Linux'es intel-idle driver serving the same purpose.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   25934:8eab91903e71
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Sep 21 13:45:08 2012 +0200
    
    cpuidle: remove unused latency_ticks member
    
    ... and code used only for initializing it.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   25933:d364becfb083
user:        Jan Beulich <jbeulich@suse.com>
date:        Thu Sep 20 13:31:19 2012 +0200
    
    introduce guest_handle_for_field()
    
    This helper turns a field of a GUEST_HANDLE in a GUEST_HANDLE.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    
    
(qemu changes not included)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Sep 22 17:12:59 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 22 Sep 2012 17:12:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TFTFg-00038n-Ix; Sat, 22 Sep 2012 17:12:24 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <julien.grall@gmail.com>) id 1TFTFf-00038i-06
	for xen-devel@lists.xen.org; Sat, 22 Sep 2012 17:12:23 +0000
Received: from [85.158.137.99:9391] by server-16.bemta-3.messagelabs.com id
	5B/17-31776-671FD505; Sat, 22 Sep 2012 17:12:22 +0000
X-Env-Sender: julien.grall@gmail.com
X-Msg-Ref: server-14.tower-217.messagelabs.com!1348333940!18701410!1
X-Originating-IP: [209.85.223.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9405 invoked from network); 22 Sep 2012 17:12:21 -0000
Received: from mail-ie0-f173.google.com (HELO mail-ie0-f173.google.com)
	(209.85.223.173)
	by server-14.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Sep 2012 17:12:21 -0000
Received: by iea17 with SMTP id 17so4272602iea.32
	for <xen-devel@lists.xen.org>; Sat, 22 Sep 2012 10:12: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:from:date:message-id:subject:to
	:cc:content-type;
	bh=c0KVa1XLvzlVCuElHKLQaGGSaeGrLat0U5gmE/5yt+w=;
	b=GaUKpv2JVJjwn/HHqmFE5It6Wm9xTvWYHEtOj7Co54ZmRP6NGRibc1Q4pWjnUMEGko
	GIjpmy9NueIK5a6f/KHbPnGfzaFtU/dbOWjnLnXGO7EvLz92O1n4d1b4Og+GeOjpmRdg
	EERn028VwrSxo4Jz4YIPTmSwVL3AfnUaNY3WmkFAfbyJ+7erYhEDcE4zbcigkU20P7eZ
	orj+2gsbkNgkcrVbGQxeGXFu+GPBIrNmuVJrlr5siRX1V2vLL8l4t+9ar4sT9KHUmQ03
	t0iQfzIkAlXh5HJY9HA/+Nru2VJE+7NapDEtHkibqyR72BAz1kcLPU3H9tcLjiyRbEht
	sdhw==
Received: by 10.50.140.74 with SMTP id re10mr1440206igb.52.1348333939615; Sat,
	22 Sep 2012 10:12:19 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.43.1.197 with HTTP; Sat, 22 Sep 2012 10:11:39 -0700 (PDT)
In-Reply-To: <20572.38321.326083.184425@mariner.uk.xensource.com>
References: <1348049147-16752-1-git-send-email-julien.grall@citrix.com>
	<20572.35759.42063.973125@mariner.uk.xensource.com>
	<505C941F.6080903@citrix.com>
	<20572.38321.326083.184425@mariner.uk.xensource.com>
From: Julien Grall <julien.grall@gmail.com>
Date: Sat, 22 Sep 2012 18:11:39 +0100
Message-ID: <CAF3u54ACoD4toNBfTBRyUy90yt=Zn50NjszoRmzSFOObr5dfvA@mail.gmail.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Cc: Julien Grall <julien.grall@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] libxenstore: filter watch events in
 libxenstore when we unwatch
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Sep 21, 2012 at 5:28 PM, Ian Jackson <Ian.Jackson@eu.citrix.com> wrote:
> Julien Grall writes ("Re: [PATCH] libxenstore: filter watch events in libxenstore when we unwatch"):
>> On 09/21/2012 04:45 PM, Ian Jackson wrote:
>> > The num_strings thing is obsolete.  There will always be two strings.
>> > Also xs_count_strings walks the array.
>>
>> >> +  /* Clear the pipe token if there are no more pending watches. */
>> >> +  if (list_empty(&h->watch_list) && (h->watch_pipe[0] != -1)) {
>> >> +          while (read(h->watch_pipe[0], &c, 1) != 1)
>> >> +                  continue;
>> >> +  }
>> >
>> > I'm not convinced this is necessary.  Don't callers already need to
>> > cope with potential spurious signallings of the watch pipe ?
>>
>> I base my code on xs_read_watch. As I understand xs_read_watch, it will
>> wait on a condition until the list is not empty.
>> So if the list is empty and not the pipe, an event can occur and block
>> the application (with xs_read_watch).
>
> xs_read_watch can only be correctly be used if you are determined to
> wait, right there, until a particular watch turns up.
>
> If you are using xs_fileno, you must do as the comment says:
>  * Callers should, after xs_fileno has become readable, repeatedly
>  * call xs_check_watch until it returns NULL and sets errno to EAGAIN.
>  * (If the fd became readable, xs_check_watch is allowed to make it no
>  * longer show up as readable even if future calls to xs_check_watch
>  * will return more watch events.)

The function xs_check_watch was recently introduced in Xen (see your
commit on december 2011).
Most of application, for instance QEMU, still use xs_read_watch.
So if xs_unwatch doesn't empty the pipe, most of this applications
potentially stall indefinitly.

IMHO, this piece of code is really important.

Sincerely yours,

-- 
Grall Julien

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Sep 22 17:12:59 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 22 Sep 2012 17:12:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TFTFg-00038n-Ix; Sat, 22 Sep 2012 17:12:24 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <julien.grall@gmail.com>) id 1TFTFf-00038i-06
	for xen-devel@lists.xen.org; Sat, 22 Sep 2012 17:12:23 +0000
Received: from [85.158.137.99:9391] by server-16.bemta-3.messagelabs.com id
	5B/17-31776-671FD505; Sat, 22 Sep 2012 17:12:22 +0000
X-Env-Sender: julien.grall@gmail.com
X-Msg-Ref: server-14.tower-217.messagelabs.com!1348333940!18701410!1
X-Originating-IP: [209.85.223.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9405 invoked from network); 22 Sep 2012 17:12:21 -0000
Received: from mail-ie0-f173.google.com (HELO mail-ie0-f173.google.com)
	(209.85.223.173)
	by server-14.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Sep 2012 17:12:21 -0000
Received: by iea17 with SMTP id 17so4272602iea.32
	for <xen-devel@lists.xen.org>; Sat, 22 Sep 2012 10:12: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:from:date:message-id:subject:to
	:cc:content-type;
	bh=c0KVa1XLvzlVCuElHKLQaGGSaeGrLat0U5gmE/5yt+w=;
	b=GaUKpv2JVJjwn/HHqmFE5It6Wm9xTvWYHEtOj7Co54ZmRP6NGRibc1Q4pWjnUMEGko
	GIjpmy9NueIK5a6f/KHbPnGfzaFtU/dbOWjnLnXGO7EvLz92O1n4d1b4Og+GeOjpmRdg
	EERn028VwrSxo4Jz4YIPTmSwVL3AfnUaNY3WmkFAfbyJ+7erYhEDcE4zbcigkU20P7eZ
	orj+2gsbkNgkcrVbGQxeGXFu+GPBIrNmuVJrlr5siRX1V2vLL8l4t+9ar4sT9KHUmQ03
	t0iQfzIkAlXh5HJY9HA/+Nru2VJE+7NapDEtHkibqyR72BAz1kcLPU3H9tcLjiyRbEht
	sdhw==
Received: by 10.50.140.74 with SMTP id re10mr1440206igb.52.1348333939615; Sat,
	22 Sep 2012 10:12:19 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.43.1.197 with HTTP; Sat, 22 Sep 2012 10:11:39 -0700 (PDT)
In-Reply-To: <20572.38321.326083.184425@mariner.uk.xensource.com>
References: <1348049147-16752-1-git-send-email-julien.grall@citrix.com>
	<20572.35759.42063.973125@mariner.uk.xensource.com>
	<505C941F.6080903@citrix.com>
	<20572.38321.326083.184425@mariner.uk.xensource.com>
From: Julien Grall <julien.grall@gmail.com>
Date: Sat, 22 Sep 2012 18:11:39 +0100
Message-ID: <CAF3u54ACoD4toNBfTBRyUy90yt=Zn50NjszoRmzSFOObr5dfvA@mail.gmail.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Cc: Julien Grall <julien.grall@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] libxenstore: filter watch events in
 libxenstore when we unwatch
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Sep 21, 2012 at 5:28 PM, Ian Jackson <Ian.Jackson@eu.citrix.com> wrote:
> Julien Grall writes ("Re: [PATCH] libxenstore: filter watch events in libxenstore when we unwatch"):
>> On 09/21/2012 04:45 PM, Ian Jackson wrote:
>> > The num_strings thing is obsolete.  There will always be two strings.
>> > Also xs_count_strings walks the array.
>>
>> >> +  /* Clear the pipe token if there are no more pending watches. */
>> >> +  if (list_empty(&h->watch_list) && (h->watch_pipe[0] != -1)) {
>> >> +          while (read(h->watch_pipe[0], &c, 1) != 1)
>> >> +                  continue;
>> >> +  }
>> >
>> > I'm not convinced this is necessary.  Don't callers already need to
>> > cope with potential spurious signallings of the watch pipe ?
>>
>> I base my code on xs_read_watch. As I understand xs_read_watch, it will
>> wait on a condition until the list is not empty.
>> So if the list is empty and not the pipe, an event can occur and block
>> the application (with xs_read_watch).
>
> xs_read_watch can only be correctly be used if you are determined to
> wait, right there, until a particular watch turns up.
>
> If you are using xs_fileno, you must do as the comment says:
>  * Callers should, after xs_fileno has become readable, repeatedly
>  * call xs_check_watch until it returns NULL and sets errno to EAGAIN.
>  * (If the fd became readable, xs_check_watch is allowed to make it no
>  * longer show up as readable even if future calls to xs_check_watch
>  * will return more watch events.)

The function xs_check_watch was recently introduced in Xen (see your
commit on december 2011).
Most of application, for instance QEMU, still use xs_read_watch.
So if xs_unwatch doesn't empty the pipe, most of this applications
potentially stall indefinitly.

IMHO, this piece of code is really important.

Sincerely yours,

-- 
Grall Julien

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Sep 22 18:16:28 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 22 Sep 2012 18:16:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TFUFB-0003b7-BX; Sat, 22 Sep 2012 18:15:57 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1TFUF9-0003b2-IK
	for xen-devel@lists.xensource.com; Sat, 22 Sep 2012 18:15:55 +0000
Received: from [85.158.139.211:8943] by server-11.bemta-5.messagelabs.com id
	22/FC-24658-A500E505; Sat, 22 Sep 2012 18:15:54 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-206.messagelabs.com!1348337754!19623636!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTA4MzA=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22772 invoked from network); 22 Sep 2012 18:15:54 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Sep 2012 18:15:54 -0000
X-IronPort-AV: E=Sophos;i="4.80,468,1344211200"; d="scan'208";a="14705402"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Sep 2012 18:15:53 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Sat, 22 Sep 2012 19:15: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 1TFUF7-0000Mx-11;
	Sat, 22 Sep 2012 18:15:53 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1TFUF6-0003TZ-Tp;
	Sat, 22 Sep 2012 19:15:52 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-13851-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sat, 22 Sep 2012 19:15:52 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13851: trouble: blocked/broken/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 13851 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13851/

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64                   2 host-install(2)         broken REGR. vs. 13825
 build-amd64-oldkern           2 host-install(2)         broken REGR. vs. 13825
 build-amd64-pvops             2 host-install(2)         broken REGR. vs. 13825

Tests which did not succeed, but are not blocking:
 test-amd64-i386-rhel6hvm-amd  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 xen-build-check(1)           blocked n/a
 test-amd64-amd64-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf-pin  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xend-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win           1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf      1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-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-amd64-i386-xl-multivcpu  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-qemuu-rhel6hvm-intel  1 xen-build-check(1)         blocked n/a
 test-amd64-i386-pv            1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-pcipt-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win-vcpus1    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-winxpsp3-vcpus1  1 xen-build-check(1)           blocked n/a
 test-amd64-i386-xl            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-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-win          1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 xen-build-check(1)         blocked n/a
 test-amd64-amd64-xl-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-pair         1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pair          1 xen-build-check(1)           blocked  n/a

version targeted for testing:
 xen                  8f658b463b78
baseline version:
 xen                  d364becfb083

------------------------------------------------------------
People who touched revisions under test:
  Jan Beulich <jbeulich@suse.com>
  Keir Fraser <keir@xen.org>
------------------------------------------------------------

jobs:
 build-amd64                                                  broken  
 build-i386                                                   pass    
 build-amd64-oldkern                                          broken  
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            broken  
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          blocked 
 test-amd64-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-amd64-amd64-xl-sedf-pin                                 blocked 
 test-amd64-amd64-pv                                          blocked 
 test-amd64-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-amd64-amd64-xl-win                                      blocked 
 test-amd64-amd64-xl-qemuu-winxpsp3                           blocked 
 test-amd64-i386-xend-winxpsp3                                blocked 
 test-amd64-amd64-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.

------------------------------------------------------------
changeset:   25938:8f658b463b78
tag:         tip
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Sep 21 17:02:46 2012 +0200
    
    x86: enable VIA CPU support
    
    Newer VIA CPUs have both 64-bit and VMX support. Enable them to be
    recognized for these purposes, at once stripping off any 32-bit CPU
    only bits from the respective CPU support file, and adding 64-bit ones
    found in recent Linux.
    
    This particularly implies untying the VMX == Intel assumption in a few
    places.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   25937:32187301ecc5
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Sep 21 15:20:21 2012 +0200
    
    x86: eliminate code affecting only 64-bit-incapable CPUs
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   25936:c8873f13cec3
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Sep 21 14:25:12 2012 +0200
    
    printk: prefer %#x et at over 0x%x
    
    Performance is not an issue with printk(), so let the function do
    minimally more work and instead save a byte per affected format
    specifier.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   25935:1e6e6b49b4ac
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Sep 21 13:47:18 2012 +0200
    
    x86: introduce MWAIT-based, ACPI-less CPU idle driver
    
    This is a port of Linux'es intel-idle driver serving the same purpose.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   25934:8eab91903e71
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Sep 21 13:45:08 2012 +0200
    
    cpuidle: remove unused latency_ticks member
    
    ... and code used only for initializing it.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   25933:d364becfb083
user:        Jan Beulich <jbeulich@suse.com>
date:        Thu Sep 20 13:31:19 2012 +0200
    
    introduce guest_handle_for_field()
    
    This helper turns a field of a GUEST_HANDLE in a GUEST_HANDLE.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    
    
(qemu changes not included)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Sep 22 18:16:28 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 22 Sep 2012 18:16:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TFUFB-0003b7-BX; Sat, 22 Sep 2012 18:15:57 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1TFUF9-0003b2-IK
	for xen-devel@lists.xensource.com; Sat, 22 Sep 2012 18:15:55 +0000
Received: from [85.158.139.211:8943] by server-11.bemta-5.messagelabs.com id
	22/FC-24658-A500E505; Sat, 22 Sep 2012 18:15:54 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-206.messagelabs.com!1348337754!19623636!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTA4MzA=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22772 invoked from network); 22 Sep 2012 18:15:54 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Sep 2012 18:15:54 -0000
X-IronPort-AV: E=Sophos;i="4.80,468,1344211200"; d="scan'208";a="14705402"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Sep 2012 18:15:53 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Sat, 22 Sep 2012 19:15: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 1TFUF7-0000Mx-11;
	Sat, 22 Sep 2012 18:15:53 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1TFUF6-0003TZ-Tp;
	Sat, 22 Sep 2012 19:15:52 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-13851-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sat, 22 Sep 2012 19:15:52 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13851: trouble: blocked/broken/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 13851 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13851/

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64                   2 host-install(2)         broken REGR. vs. 13825
 build-amd64-oldkern           2 host-install(2)         broken REGR. vs. 13825
 build-amd64-pvops             2 host-install(2)         broken REGR. vs. 13825

Tests which did not succeed, but are not blocking:
 test-amd64-i386-rhel6hvm-amd  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 xen-build-check(1)           blocked n/a
 test-amd64-amd64-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf-pin  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xend-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win           1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf      1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-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-amd64-i386-xl-multivcpu  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-qemuu-rhel6hvm-intel  1 xen-build-check(1)         blocked n/a
 test-amd64-i386-pv            1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-pcipt-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win-vcpus1    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-winxpsp3-vcpus1  1 xen-build-check(1)           blocked n/a
 test-amd64-i386-xl            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-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-win          1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 xen-build-check(1)         blocked n/a
 test-amd64-amd64-xl-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-pair         1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pair          1 xen-build-check(1)           blocked  n/a

version targeted for testing:
 xen                  8f658b463b78
baseline version:
 xen                  d364becfb083

------------------------------------------------------------
People who touched revisions under test:
  Jan Beulich <jbeulich@suse.com>
  Keir Fraser <keir@xen.org>
------------------------------------------------------------

jobs:
 build-amd64                                                  broken  
 build-i386                                                   pass    
 build-amd64-oldkern                                          broken  
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            broken  
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          blocked 
 test-amd64-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-amd64-amd64-xl-sedf-pin                                 blocked 
 test-amd64-amd64-pv                                          blocked 
 test-amd64-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-amd64-amd64-xl-win                                      blocked 
 test-amd64-amd64-xl-qemuu-winxpsp3                           blocked 
 test-amd64-i386-xend-winxpsp3                                blocked 
 test-amd64-amd64-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.

------------------------------------------------------------
changeset:   25938:8f658b463b78
tag:         tip
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Sep 21 17:02:46 2012 +0200
    
    x86: enable VIA CPU support
    
    Newer VIA CPUs have both 64-bit and VMX support. Enable them to be
    recognized for these purposes, at once stripping off any 32-bit CPU
    only bits from the respective CPU support file, and adding 64-bit ones
    found in recent Linux.
    
    This particularly implies untying the VMX == Intel assumption in a few
    places.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   25937:32187301ecc5
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Sep 21 15:20:21 2012 +0200
    
    x86: eliminate code affecting only 64-bit-incapable CPUs
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   25936:c8873f13cec3
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Sep 21 14:25:12 2012 +0200
    
    printk: prefer %#x et at over 0x%x
    
    Performance is not an issue with printk(), so let the function do
    minimally more work and instead save a byte per affected format
    specifier.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   25935:1e6e6b49b4ac
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Sep 21 13:47:18 2012 +0200
    
    x86: introduce MWAIT-based, ACPI-less CPU idle driver
    
    This is a port of Linux'es intel-idle driver serving the same purpose.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   25934:8eab91903e71
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Sep 21 13:45:08 2012 +0200
    
    cpuidle: remove unused latency_ticks member
    
    ... and code used only for initializing it.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   25933:d364becfb083
user:        Jan Beulich <jbeulich@suse.com>
date:        Thu Sep 20 13:31:19 2012 +0200
    
    introduce guest_handle_for_field()
    
    This helper turns a field of a GUEST_HANDLE in a GUEST_HANDLE.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    
    
(qemu changes not included)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Sep 22 20:17:22 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 22 Sep 2012 20:17:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TFW88-0004eL-BU; Sat, 22 Sep 2012 20:16:48 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1TFW86-0004eD-5j
	for xen-devel@lists.xensource.com; Sat, 22 Sep 2012 20:16:46 +0000
Received: from [85.158.138.51:29231] by server-15.bemta-3.messagelabs.com id
	C7/E0-09665-DAC1E505; Sat, 22 Sep 2012 20:16:45 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1348345003!29805695!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTA4MzA=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27498 invoked from network); 22 Sep 2012 20:16:43 -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;
	22 Sep 2012 20:16:43 -0000
X-IronPort-AV: E=Sophos;i="4.80,468,1344211200"; d="scan'208";a="14705667"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Sep 2012 20:16: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.279.1; Sat, 22 Sep 2012 21:16:42 +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 1TFW82-0001Qj-0U;
	Sat, 22 Sep 2012 20:16:42 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1TFW81-0000pB-VU;
	Sat, 22 Sep 2012 21:16:41 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-13852-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sat, 22 Sep 2012 21:16:41 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13852: trouble: blocked/broken/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 13852 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13852/

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64                   2 host-install(2)         broken REGR. vs. 13825
 build-amd64-oldkern           2 host-install(2)         broken REGR. vs. 13825
 build-amd64-pvops             2 host-install(2)         broken REGR. vs. 13825

Tests which did not succeed, but are not blocking:
 test-amd64-i386-rhel6hvm-amd  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 xen-build-check(1)           blocked n/a
 test-amd64-amd64-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf-pin  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xend-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win           1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf      1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-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-amd64-i386-xl-multivcpu  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-qemuu-rhel6hvm-intel  1 xen-build-check(1)         blocked n/a
 test-amd64-i386-pv            1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-pcipt-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win-vcpus1    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-winxpsp3-vcpus1  1 xen-build-check(1)           blocked n/a
 test-amd64-i386-xl            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-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-win          1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 xen-build-check(1)         blocked n/a
 test-amd64-amd64-xl-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-pair         1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pair          1 xen-build-check(1)           blocked  n/a

version targeted for testing:
 xen                  8f658b463b78
baseline version:
 xen                  d364becfb083

------------------------------------------------------------
People who touched revisions under test:
  Jan Beulich <jbeulich@suse.com>
  Keir Fraser <keir@xen.org>
------------------------------------------------------------

jobs:
 build-amd64                                                  broken  
 build-i386                                                   pass    
 build-amd64-oldkern                                          broken  
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            broken  
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          blocked 
 test-amd64-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-amd64-amd64-xl-sedf-pin                                 blocked 
 test-amd64-amd64-pv                                          blocked 
 test-amd64-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-amd64-amd64-xl-win                                      blocked 
 test-amd64-amd64-xl-qemuu-winxpsp3                           blocked 
 test-amd64-i386-xend-winxpsp3                                blocked 
 test-amd64-amd64-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.

------------------------------------------------------------
changeset:   25938:8f658b463b78
tag:         tip
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Sep 21 17:02:46 2012 +0200
    
    x86: enable VIA CPU support
    
    Newer VIA CPUs have both 64-bit and VMX support. Enable them to be
    recognized for these purposes, at once stripping off any 32-bit CPU
    only bits from the respective CPU support file, and adding 64-bit ones
    found in recent Linux.
    
    This particularly implies untying the VMX == Intel assumption in a few
    places.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   25937:32187301ecc5
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Sep 21 15:20:21 2012 +0200
    
    x86: eliminate code affecting only 64-bit-incapable CPUs
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   25936:c8873f13cec3
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Sep 21 14:25:12 2012 +0200
    
    printk: prefer %#x et at over 0x%x
    
    Performance is not an issue with printk(), so let the function do
    minimally more work and instead save a byte per affected format
    specifier.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   25935:1e6e6b49b4ac
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Sep 21 13:47:18 2012 +0200
    
    x86: introduce MWAIT-based, ACPI-less CPU idle driver
    
    This is a port of Linux'es intel-idle driver serving the same purpose.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   25934:8eab91903e71
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Sep 21 13:45:08 2012 +0200
    
    cpuidle: remove unused latency_ticks member
    
    ... and code used only for initializing it.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   25933:d364becfb083
user:        Jan Beulich <jbeulich@suse.com>
date:        Thu Sep 20 13:31:19 2012 +0200
    
    introduce guest_handle_for_field()
    
    This helper turns a field of a GUEST_HANDLE in a GUEST_HANDLE.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    
    
(qemu changes not included)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Sep 22 20:17:22 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 22 Sep 2012 20:17:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TFW88-0004eL-BU; Sat, 22 Sep 2012 20:16:48 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1TFW86-0004eD-5j
	for xen-devel@lists.xensource.com; Sat, 22 Sep 2012 20:16:46 +0000
Received: from [85.158.138.51:29231] by server-15.bemta-3.messagelabs.com id
	C7/E0-09665-DAC1E505; Sat, 22 Sep 2012 20:16:45 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1348345003!29805695!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTA4MzA=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27498 invoked from network); 22 Sep 2012 20:16:43 -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;
	22 Sep 2012 20:16:43 -0000
X-IronPort-AV: E=Sophos;i="4.80,468,1344211200"; d="scan'208";a="14705667"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Sep 2012 20:16: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.279.1; Sat, 22 Sep 2012 21:16:42 +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 1TFW82-0001Qj-0U;
	Sat, 22 Sep 2012 20:16:42 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1TFW81-0000pB-VU;
	Sat, 22 Sep 2012 21:16:41 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-13852-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sat, 22 Sep 2012 21:16:41 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13852: trouble: blocked/broken/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 13852 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13852/

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64                   2 host-install(2)         broken REGR. vs. 13825
 build-amd64-oldkern           2 host-install(2)         broken REGR. vs. 13825
 build-amd64-pvops             2 host-install(2)         broken REGR. vs. 13825

Tests which did not succeed, but are not blocking:
 test-amd64-i386-rhel6hvm-amd  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 xen-build-check(1)           blocked n/a
 test-amd64-amd64-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf-pin  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xend-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win           1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf      1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-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-amd64-i386-xl-multivcpu  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-qemuu-rhel6hvm-intel  1 xen-build-check(1)         blocked n/a
 test-amd64-i386-pv            1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-pcipt-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win-vcpus1    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-winxpsp3-vcpus1  1 xen-build-check(1)           blocked n/a
 test-amd64-i386-xl            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-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-win          1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 xen-build-check(1)         blocked n/a
 test-amd64-amd64-xl-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-pair         1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pair          1 xen-build-check(1)           blocked  n/a

version targeted for testing:
 xen                  8f658b463b78
baseline version:
 xen                  d364becfb083

------------------------------------------------------------
People who touched revisions under test:
  Jan Beulich <jbeulich@suse.com>
  Keir Fraser <keir@xen.org>
------------------------------------------------------------

jobs:
 build-amd64                                                  broken  
 build-i386                                                   pass    
 build-amd64-oldkern                                          broken  
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            broken  
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          blocked 
 test-amd64-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-amd64-amd64-xl-sedf-pin                                 blocked 
 test-amd64-amd64-pv                                          blocked 
 test-amd64-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-amd64-amd64-xl-win                                      blocked 
 test-amd64-amd64-xl-qemuu-winxpsp3                           blocked 
 test-amd64-i386-xend-winxpsp3                                blocked 
 test-amd64-amd64-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.

------------------------------------------------------------
changeset:   25938:8f658b463b78
tag:         tip
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Sep 21 17:02:46 2012 +0200
    
    x86: enable VIA CPU support
    
    Newer VIA CPUs have both 64-bit and VMX support. Enable them to be
    recognized for these purposes, at once stripping off any 32-bit CPU
    only bits from the respective CPU support file, and adding 64-bit ones
    found in recent Linux.
    
    This particularly implies untying the VMX == Intel assumption in a few
    places.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   25937:32187301ecc5
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Sep 21 15:20:21 2012 +0200
    
    x86: eliminate code affecting only 64-bit-incapable CPUs
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   25936:c8873f13cec3
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Sep 21 14:25:12 2012 +0200
    
    printk: prefer %#x et at over 0x%x
    
    Performance is not an issue with printk(), so let the function do
    minimally more work and instead save a byte per affected format
    specifier.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   25935:1e6e6b49b4ac
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Sep 21 13:47:18 2012 +0200
    
    x86: introduce MWAIT-based, ACPI-less CPU idle driver
    
    This is a port of Linux'es intel-idle driver serving the same purpose.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   25934:8eab91903e71
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Sep 21 13:45:08 2012 +0200
    
    cpuidle: remove unused latency_ticks member
    
    ... and code used only for initializing it.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   25933:d364becfb083
user:        Jan Beulich <jbeulich@suse.com>
date:        Thu Sep 20 13:31:19 2012 +0200
    
    introduce guest_handle_for_field()
    
    This helper turns a field of a GUEST_HANDLE in a GUEST_HANDLE.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    
    
(qemu changes not included)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Sep 22 20:25:34 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 22 Sep 2012 20:25:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TFWG9-0004nO-BR; Sat, 22 Sep 2012 20:25:05 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ikozhukhov@gmail.com>) id 1TFWG6-0004nF-W3
	for xen-devel@lists.xensource.com; Sat, 22 Sep 2012 20:25:03 +0000
Received: from [85.158.139.211:58185] by server-6.bemta-5.messagelabs.com id
	75/61-21336-E9E1E505; Sat, 22 Sep 2012 20:25:02 +0000
X-Env-Sender: ikozhukhov@gmail.com
X-Msg-Ref: server-12.tower-206.messagelabs.com!1348345501!18577329!1
X-Originating-IP: [209.85.217.171]
X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_MESSAGE,
	MIME_QP_LONG_LINE,ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31175 invoked from network); 22 Sep 2012 20:25:01 -0000
Received: from mail-lb0-f171.google.com (HELO mail-lb0-f171.google.com)
	(209.85.217.171)
	by server-12.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Sep 2012 20:25:01 -0000
Received: by lbom4 with SMTP id m4so4045566lbo.30
	for <xen-devel@lists.xensource.com>;
	Sat, 22 Sep 2012 13:25:00 -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
	:mime-version:content-type;
	bh=AzFOVVxJy0OBRk4ibVSo299Q3Wmn+anDesmULelPo1k=;
	b=IaTX81Bp6TBzhPJj2E+95al0chzp05OJhj2/6ifQOCaFfserevPZnZkbVWdfjphraS
	J+rAMQiczOP1YYEDu/knnZ+5GJESiolPMaQ5W0mxf7nRhs6p3cxfk38opSj6pmA9iS6N
	9YCNG1cSUYhmbo64UwIIm13SWRUFc3B1Fwjgc1KpuFUdReZ8//VBKoea2lxW7cJeLzXo
	fc5J3hR2LTj7IsvjHAZn3uS1uYDjyCWilkVlnnJMElwkqXhBcy3TmQ+U3pAIdJLrQpra
	+P8WCgLUxiBkr8z9+ACBst46vSGWmDsGcj9f4+hkL4c8EK0UdxZtbW2imjY/6sPGuoUw
	cg+w==
Received: by 10.112.46.41 with SMTP id s9mr1869043lbm.36.1348345500451;
	Sat, 22 Sep 2012 13:25:00 -0700 (PDT)
Received: from [172.16.90.16] ([91.204.58.44])
	by mx.google.com with ESMTPS id i3sm1708952lbg.10.2012.09.22.13.24.58
	(version=SSLv3 cipher=OTHER); Sat, 22 Sep 2012 13:24:59 -0700 (PDT)
User-Agent: Microsoft-MacOutlook/14.2.4.120824
Date: Sun, 23 Sep 2012 00:24:55 +0400
From: Igor Kozhukhov <ikozhukhov@gmail.com>
To: <xen-devel@lists.xensource.com>
Message-ID: <CC840757.2EB4A%ikozhukhov@gmail.com>
Thread-Topic: xen-4.1.3 panic on solaris kernel dom0
Mime-version: 1.0
Subject: [Xen-devel] xen-4.1.3 panic on solaris kernel 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: multipart/mixed; boundary="===============5164011845898435560=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--===============5164011845898435560==
Content-type: multipart/alternative;
	boundary="B_3431204698_911277"

> This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--B_3431204698_911277
Content-type: text/plain;
	charset="US-ASCII"
Content-transfer-encoding: 7bit

Hello All,

I have panic with xen-4.1.3 - http://pastebin.com/vXv7BYq9

Could you please help me identify problem - why apic_find_irq() possible to
failed ?

I try to port xen-4.1.3 to illumos based platform (www.dilos.org)

I have loaded xen-3.4.4.

For xen-4.1.3 need update headers and additional files on illumos-gate
kernel.

I have made some changes and built debug build for testing.

As you can see on paster xen kernel have been loaded, but I have panic on
loading solaris kernel.

Could you please check logs from xen kernel (on top on paste)  and let me
know if it have issues.

---
Best regards,
Igor Kozhukhov
IRC# igork



--B_3431204698_911277
Content-type: text/html;
	charset="US-ASCII"
Content-transfer-encoding: quoted-printable

<html><head></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: s=
pace; -webkit-line-break: after-white-space; font-size: 14px; font-family: C=
alibri, sans-serif; "><div><div><div style=3D"color: rgb(0, 0, 0); ">Hello All=
,</div><div style=3D"color: rgb(0, 0, 0); "><br></div><div><span class=3D"Apple-=
style-span" style=3D"line-height: 15px; font-family: Menlo; font-size: medium;=
 ">I have panic with xen-4.1.3 -&nbsp;<a href=3D"http://pastebin.com/vXv7BYq9"=
 title=3D"http://pastebin.com/vXv7BYq9" style=3D"word-wrap: break-word; text-ren=
dering: optimizelegibility; ">http://pastebin.com/vXv7BYq9</a></span></div><=
div><div><br></div><font face=3D"Calibri,Verdana,Helvetica,Arial" style=3D"color=
: rgb(0, 0, 0); "><span style=3D"font-size:11pt"><div><font face=3D"Calibri,Verd=
ana,Helvetica,Arial" style=3D"color: rgb(0, 0, 0); "><span style=3D"font-size:11=
pt">Could you please help me identify problem - why&nbsp;apic_find_irq() pos=
sible to failed ?</span></font></div><div><br></div><div>I try to port xen-4=
.1.3 to illumos based platform (www.dilos.org)</div><div><font face=3D"Calibri=
,Verdana,Helvetica,Arial" style=3D"color: rgb(0, 0, 0); "><span style=3D"font-si=
ze:11pt"><br></span></font></div><div><font face=3D"Calibri,Verdana,Helvetica,=
Arial" style=3D"color: rgb(0, 0, 0); "><span style=3D"font-size:11pt">I have loa=
ded xen-3.4.4.</span></font></div><div><font face=3D"Calibri,Verdana,Helvetica=
,Arial" style=3D"color: rgb(0, 0, 0); "><span style=3D"font-size:11pt"><br></spa=
n></font></div><div><font face=3D"Calibri,Verdana,Helvetica,Arial" style=3D"colo=
r: rgb(0, 0, 0); "><span style=3D"font-size:11pt">For xen-4.1.3 need update he=
aders and additional files on illumos-gate kernel.</span></font></div><div><=
font face=3D"Calibri,Verdana,Helvetica,Arial" style=3D"color: rgb(0, 0, 0); "><s=
pan style=3D"font-size:11pt"><br></span></font></div><div><font face=3D"Calibri,=
Verdana,Helvetica,Arial" style=3D"color: rgb(0, 0, 0); "><span style=3D"font-siz=
e:11pt">I have made some changes and built debug build for testing.</span></=
font></div><div><font face=3D"Calibri,Verdana,Helvetica,Arial" style=3D"color: r=
gb(0, 0, 0); "><span style=3D"font-size:11pt"><br></span></font></div><div><fo=
nt face=3D"Calibri,Verdana,Helvetica,Arial" style=3D"color: rgb(0, 0, 0); "><spa=
n style=3D"font-size:11pt">As you can see on paster xen kernel have been loade=
d, but I have panic on loading solaris kernel.</span></font></div><div><font=
 face=3D"Calibri,Verdana,Helvetica,Arial" style=3D"color: rgb(0, 0, 0); "><span =
style=3D"font-size:11pt"><br></span></font></div><div><font face=3D"Calibri,Verd=
ana,Helvetica,Arial" style=3D"color: rgb(0, 0, 0); "><span style=3D"font-size:11=
pt">Could you please check logs from xen kernel (on top on paste) &nbsp;and =
let me know if it have issues.</span></font></div><div><font face=3D"Calibri,V=
erdana,Helvetica,Arial" style=3D"color: rgb(0, 0, 0); "><span style=3D"font-size=
:11pt"><br></span></font></div>---<br>
Best regards,<br>
Igor Kozhukhov<br>IRC# igork<br></span></font></div></div></div></body></ht=
ml>

--B_3431204698_911277--




--===============5164011845898435560==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============5164011845898435560==--




From xen-devel-bounces@lists.xen.org Sat Sep 22 20:25:34 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 22 Sep 2012 20:25:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TFWG9-0004nO-BR; Sat, 22 Sep 2012 20:25:05 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ikozhukhov@gmail.com>) id 1TFWG6-0004nF-W3
	for xen-devel@lists.xensource.com; Sat, 22 Sep 2012 20:25:03 +0000
Received: from [85.158.139.211:58185] by server-6.bemta-5.messagelabs.com id
	75/61-21336-E9E1E505; Sat, 22 Sep 2012 20:25:02 +0000
X-Env-Sender: ikozhukhov@gmail.com
X-Msg-Ref: server-12.tower-206.messagelabs.com!1348345501!18577329!1
X-Originating-IP: [209.85.217.171]
X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_MESSAGE,
	MIME_QP_LONG_LINE,ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31175 invoked from network); 22 Sep 2012 20:25:01 -0000
Received: from mail-lb0-f171.google.com (HELO mail-lb0-f171.google.com)
	(209.85.217.171)
	by server-12.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Sep 2012 20:25:01 -0000
Received: by lbom4 with SMTP id m4so4045566lbo.30
	for <xen-devel@lists.xensource.com>;
	Sat, 22 Sep 2012 13:25:00 -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
	:mime-version:content-type;
	bh=AzFOVVxJy0OBRk4ibVSo299Q3Wmn+anDesmULelPo1k=;
	b=IaTX81Bp6TBzhPJj2E+95al0chzp05OJhj2/6ifQOCaFfserevPZnZkbVWdfjphraS
	J+rAMQiczOP1YYEDu/knnZ+5GJESiolPMaQ5W0mxf7nRhs6p3cxfk38opSj6pmA9iS6N
	9YCNG1cSUYhmbo64UwIIm13SWRUFc3B1Fwjgc1KpuFUdReZ8//VBKoea2lxW7cJeLzXo
	fc5J3hR2LTj7IsvjHAZn3uS1uYDjyCWilkVlnnJMElwkqXhBcy3TmQ+U3pAIdJLrQpra
	+P8WCgLUxiBkr8z9+ACBst46vSGWmDsGcj9f4+hkL4c8EK0UdxZtbW2imjY/6sPGuoUw
	cg+w==
Received: by 10.112.46.41 with SMTP id s9mr1869043lbm.36.1348345500451;
	Sat, 22 Sep 2012 13:25:00 -0700 (PDT)
Received: from [172.16.90.16] ([91.204.58.44])
	by mx.google.com with ESMTPS id i3sm1708952lbg.10.2012.09.22.13.24.58
	(version=SSLv3 cipher=OTHER); Sat, 22 Sep 2012 13:24:59 -0700 (PDT)
User-Agent: Microsoft-MacOutlook/14.2.4.120824
Date: Sun, 23 Sep 2012 00:24:55 +0400
From: Igor Kozhukhov <ikozhukhov@gmail.com>
To: <xen-devel@lists.xensource.com>
Message-ID: <CC840757.2EB4A%ikozhukhov@gmail.com>
Thread-Topic: xen-4.1.3 panic on solaris kernel dom0
Mime-version: 1.0
Subject: [Xen-devel] xen-4.1.3 panic on solaris kernel 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: multipart/mixed; boundary="===============5164011845898435560=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--===============5164011845898435560==
Content-type: multipart/alternative;
	boundary="B_3431204698_911277"

> This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--B_3431204698_911277
Content-type: text/plain;
	charset="US-ASCII"
Content-transfer-encoding: 7bit

Hello All,

I have panic with xen-4.1.3 - http://pastebin.com/vXv7BYq9

Could you please help me identify problem - why apic_find_irq() possible to
failed ?

I try to port xen-4.1.3 to illumos based platform (www.dilos.org)

I have loaded xen-3.4.4.

For xen-4.1.3 need update headers and additional files on illumos-gate
kernel.

I have made some changes and built debug build for testing.

As you can see on paster xen kernel have been loaded, but I have panic on
loading solaris kernel.

Could you please check logs from xen kernel (on top on paste)  and let me
know if it have issues.

---
Best regards,
Igor Kozhukhov
IRC# igork



--B_3431204698_911277
Content-type: text/html;
	charset="US-ASCII"
Content-transfer-encoding: quoted-printable

<html><head></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: s=
pace; -webkit-line-break: after-white-space; font-size: 14px; font-family: C=
alibri, sans-serif; "><div><div><div style=3D"color: rgb(0, 0, 0); ">Hello All=
,</div><div style=3D"color: rgb(0, 0, 0); "><br></div><div><span class=3D"Apple-=
style-span" style=3D"line-height: 15px; font-family: Menlo; font-size: medium;=
 ">I have panic with xen-4.1.3 -&nbsp;<a href=3D"http://pastebin.com/vXv7BYq9"=
 title=3D"http://pastebin.com/vXv7BYq9" style=3D"word-wrap: break-word; text-ren=
dering: optimizelegibility; ">http://pastebin.com/vXv7BYq9</a></span></div><=
div><div><br></div><font face=3D"Calibri,Verdana,Helvetica,Arial" style=3D"color=
: rgb(0, 0, 0); "><span style=3D"font-size:11pt"><div><font face=3D"Calibri,Verd=
ana,Helvetica,Arial" style=3D"color: rgb(0, 0, 0); "><span style=3D"font-size:11=
pt">Could you please help me identify problem - why&nbsp;apic_find_irq() pos=
sible to failed ?</span></font></div><div><br></div><div>I try to port xen-4=
.1.3 to illumos based platform (www.dilos.org)</div><div><font face=3D"Calibri=
,Verdana,Helvetica,Arial" style=3D"color: rgb(0, 0, 0); "><span style=3D"font-si=
ze:11pt"><br></span></font></div><div><font face=3D"Calibri,Verdana,Helvetica,=
Arial" style=3D"color: rgb(0, 0, 0); "><span style=3D"font-size:11pt">I have loa=
ded xen-3.4.4.</span></font></div><div><font face=3D"Calibri,Verdana,Helvetica=
,Arial" style=3D"color: rgb(0, 0, 0); "><span style=3D"font-size:11pt"><br></spa=
n></font></div><div><font face=3D"Calibri,Verdana,Helvetica,Arial" style=3D"colo=
r: rgb(0, 0, 0); "><span style=3D"font-size:11pt">For xen-4.1.3 need update he=
aders and additional files on illumos-gate kernel.</span></font></div><div><=
font face=3D"Calibri,Verdana,Helvetica,Arial" style=3D"color: rgb(0, 0, 0); "><s=
pan style=3D"font-size:11pt"><br></span></font></div><div><font face=3D"Calibri,=
Verdana,Helvetica,Arial" style=3D"color: rgb(0, 0, 0); "><span style=3D"font-siz=
e:11pt">I have made some changes and built debug build for testing.</span></=
font></div><div><font face=3D"Calibri,Verdana,Helvetica,Arial" style=3D"color: r=
gb(0, 0, 0); "><span style=3D"font-size:11pt"><br></span></font></div><div><fo=
nt face=3D"Calibri,Verdana,Helvetica,Arial" style=3D"color: rgb(0, 0, 0); "><spa=
n style=3D"font-size:11pt">As you can see on paster xen kernel have been loade=
d, but I have panic on loading solaris kernel.</span></font></div><div><font=
 face=3D"Calibri,Verdana,Helvetica,Arial" style=3D"color: rgb(0, 0, 0); "><span =
style=3D"font-size:11pt"><br></span></font></div><div><font face=3D"Calibri,Verd=
ana,Helvetica,Arial" style=3D"color: rgb(0, 0, 0); "><span style=3D"font-size:11=
pt">Could you please check logs from xen kernel (on top on paste) &nbsp;and =
let me know if it have issues.</span></font></div><div><font face=3D"Calibri,V=
erdana,Helvetica,Arial" style=3D"color: rgb(0, 0, 0); "><span style=3D"font-size=
:11pt"><br></span></font></div>---<br>
Best regards,<br>
Igor Kozhukhov<br>IRC# igork<br></span></font></div></div></div></body></ht=
ml>

--B_3431204698_911277--




--===============5164011845898435560==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============5164011845898435560==--




From xen-devel-bounces@lists.xen.org Sun Sep 23 02:16:50 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 23 Sep 2012 02: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 1TFbk0-000340-Jw; Sun, 23 Sep 2012 02:16: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 1TFbjz-00033v-2a
	for xen-devel@lists.xensource.com; Sun, 23 Sep 2012 02:16:15 +0000
Received: from [85.158.143.99:46915] by server-1.bemta-4.messagelabs.com id
	62/6C-05684-EE07E505; Sun, 23 Sep 2012 02:16:14 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1348366573!21616524!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTA4MzM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25975 invoked from network); 23 Sep 2012 02:16:13 -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;
	23 Sep 2012 02:16:13 -0000
X-IronPort-AV: E=Sophos;i="4.80,469,1344211200"; d="scan'208";a="14706379"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Sep 2012 02:16: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.279.1; Sun, 23 Sep 2012 03:16: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 1TFbjw-0003i0-D1;
	Sun, 23 Sep 2012 02:16:12 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1TFbjw-0007Cx-BJ;
	Sun, 23 Sep 2012 03:16:12 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-13853-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sun, 23 Sep 2012 03:16:12 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13853: trouble: blocked/broken/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 13853 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13853/

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64                   2 host-install(2)         broken REGR. vs. 13825
 build-amd64-oldkern           2 host-install(2)         broken REGR. vs. 13825
 build-amd64-pvops             2 host-install(2)         broken REGR. vs. 13825

Tests which did not succeed, but are not blocking:
 test-amd64-i386-rhel6hvm-amd  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 xen-build-check(1)           blocked n/a
 test-amd64-amd64-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf-pin  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xend-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win           1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf      1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-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-amd64-i386-xl-multivcpu  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-qemuu-rhel6hvm-intel  1 xen-build-check(1)         blocked n/a
 test-amd64-i386-pv            1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-pcipt-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win-vcpus1    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-winxpsp3-vcpus1  1 xen-build-check(1)           blocked n/a
 test-amd64-i386-xl            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-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-win          1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 xen-build-check(1)         blocked n/a
 test-amd64-amd64-xl-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-pair         1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pair          1 xen-build-check(1)           blocked  n/a

version targeted for testing:
 xen                  8f658b463b78
baseline version:
 xen                  d364becfb083

------------------------------------------------------------
People who touched revisions under test:
  Jan Beulich <jbeulich@suse.com>
  Keir Fraser <keir@xen.org>
------------------------------------------------------------

jobs:
 build-amd64                                                  broken  
 build-i386                                                   pass    
 build-amd64-oldkern                                          broken  
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            broken  
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          blocked 
 test-amd64-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-amd64-amd64-xl-sedf-pin                                 blocked 
 test-amd64-amd64-pv                                          blocked 
 test-amd64-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-amd64-amd64-xl-win                                      blocked 
 test-amd64-amd64-xl-qemuu-winxpsp3                           blocked 
 test-amd64-i386-xend-winxpsp3                                blocked 
 test-amd64-amd64-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.

------------------------------------------------------------
changeset:   25938:8f658b463b78
tag:         tip
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Sep 21 17:02:46 2012 +0200
    
    x86: enable VIA CPU support
    
    Newer VIA CPUs have both 64-bit and VMX support. Enable them to be
    recognized for these purposes, at once stripping off any 32-bit CPU
    only bits from the respective CPU support file, and adding 64-bit ones
    found in recent Linux.
    
    This particularly implies untying the VMX == Intel assumption in a few
    places.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   25937:32187301ecc5
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Sep 21 15:20:21 2012 +0200
    
    x86: eliminate code affecting only 64-bit-incapable CPUs
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   25936:c8873f13cec3
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Sep 21 14:25:12 2012 +0200
    
    printk: prefer %#x et at over 0x%x
    
    Performance is not an issue with printk(), so let the function do
    minimally more work and instead save a byte per affected format
    specifier.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   25935:1e6e6b49b4ac
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Sep 21 13:47:18 2012 +0200
    
    x86: introduce MWAIT-based, ACPI-less CPU idle driver
    
    This is a port of Linux'es intel-idle driver serving the same purpose.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   25934:8eab91903e71
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Sep 21 13:45:08 2012 +0200
    
    cpuidle: remove unused latency_ticks member
    
    ... and code used only for initializing it.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   25933:d364becfb083
user:        Jan Beulich <jbeulich@suse.com>
date:        Thu Sep 20 13:31:19 2012 +0200
    
    introduce guest_handle_for_field()
    
    This helper turns a field of a GUEST_HANDLE in a GUEST_HANDLE.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    
    
(qemu changes not included)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Sep 23 02:16:50 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 23 Sep 2012 02: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 1TFbk0-000340-Jw; Sun, 23 Sep 2012 02:16: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 1TFbjz-00033v-2a
	for xen-devel@lists.xensource.com; Sun, 23 Sep 2012 02:16:15 +0000
Received: from [85.158.143.99:46915] by server-1.bemta-4.messagelabs.com id
	62/6C-05684-EE07E505; Sun, 23 Sep 2012 02:16:14 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1348366573!21616524!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTA4MzM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25975 invoked from network); 23 Sep 2012 02:16:13 -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;
	23 Sep 2012 02:16:13 -0000
X-IronPort-AV: E=Sophos;i="4.80,469,1344211200"; d="scan'208";a="14706379"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Sep 2012 02:16: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.279.1; Sun, 23 Sep 2012 03:16: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 1TFbjw-0003i0-D1;
	Sun, 23 Sep 2012 02:16:12 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1TFbjw-0007Cx-BJ;
	Sun, 23 Sep 2012 03:16:12 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-13853-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sun, 23 Sep 2012 03:16:12 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13853: trouble: blocked/broken/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 13853 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13853/

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64                   2 host-install(2)         broken REGR. vs. 13825
 build-amd64-oldkern           2 host-install(2)         broken REGR. vs. 13825
 build-amd64-pvops             2 host-install(2)         broken REGR. vs. 13825

Tests which did not succeed, but are not blocking:
 test-amd64-i386-rhel6hvm-amd  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 xen-build-check(1)           blocked n/a
 test-amd64-amd64-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf-pin  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xend-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win           1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf      1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-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-amd64-i386-xl-multivcpu  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-qemuu-rhel6hvm-intel  1 xen-build-check(1)         blocked n/a
 test-amd64-i386-pv            1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-pcipt-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win-vcpus1    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-winxpsp3-vcpus1  1 xen-build-check(1)           blocked n/a
 test-amd64-i386-xl            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-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-win          1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 xen-build-check(1)         blocked n/a
 test-amd64-amd64-xl-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-pair         1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pair          1 xen-build-check(1)           blocked  n/a

version targeted for testing:
 xen                  8f658b463b78
baseline version:
 xen                  d364becfb083

------------------------------------------------------------
People who touched revisions under test:
  Jan Beulich <jbeulich@suse.com>
  Keir Fraser <keir@xen.org>
------------------------------------------------------------

jobs:
 build-amd64                                                  broken  
 build-i386                                                   pass    
 build-amd64-oldkern                                          broken  
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            broken  
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          blocked 
 test-amd64-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-amd64-amd64-xl-sedf-pin                                 blocked 
 test-amd64-amd64-pv                                          blocked 
 test-amd64-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-amd64-amd64-xl-win                                      blocked 
 test-amd64-amd64-xl-qemuu-winxpsp3                           blocked 
 test-amd64-i386-xend-winxpsp3                                blocked 
 test-amd64-amd64-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.

------------------------------------------------------------
changeset:   25938:8f658b463b78
tag:         tip
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Sep 21 17:02:46 2012 +0200
    
    x86: enable VIA CPU support
    
    Newer VIA CPUs have both 64-bit and VMX support. Enable them to be
    recognized for these purposes, at once stripping off any 32-bit CPU
    only bits from the respective CPU support file, and adding 64-bit ones
    found in recent Linux.
    
    This particularly implies untying the VMX == Intel assumption in a few
    places.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   25937:32187301ecc5
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Sep 21 15:20:21 2012 +0200
    
    x86: eliminate code affecting only 64-bit-incapable CPUs
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   25936:c8873f13cec3
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Sep 21 14:25:12 2012 +0200
    
    printk: prefer %#x et at over 0x%x
    
    Performance is not an issue with printk(), so let the function do
    minimally more work and instead save a byte per affected format
    specifier.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   25935:1e6e6b49b4ac
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Sep 21 13:47:18 2012 +0200
    
    x86: introduce MWAIT-based, ACPI-less CPU idle driver
    
    This is a port of Linux'es intel-idle driver serving the same purpose.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   25934:8eab91903e71
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Sep 21 13:45:08 2012 +0200
    
    cpuidle: remove unused latency_ticks member
    
    ... and code used only for initializing it.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   25933:d364becfb083
user:        Jan Beulich <jbeulich@suse.com>
date:        Thu Sep 20 13:31:19 2012 +0200
    
    introduce guest_handle_for_field()
    
    This helper turns a field of a GUEST_HANDLE in a GUEST_HANDLE.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    
    
(qemu changes not included)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Sep 23 12:17:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 23 Sep 2012 12:17:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TFl7E-0006Yu-NN; Sun, 23 Sep 2012 12:16:52 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1TFl7E-0006Yp-0c
	for xen-devel@lists.xensource.com; Sun, 23 Sep 2012 12:16:52 +0000
Received: from [85.158.139.211:60095] by server-9.bemta-5.messagelabs.com id
	B5/A8-20529-3BDFE505; Sun, 23 Sep 2012 12:16:51 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-206.messagelabs.com!1348402610!19674044!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTA4MzM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3307 invoked from network); 23 Sep 2012 12:16:50 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Sep 2012 12:16:50 -0000
X-IronPort-AV: E=Sophos;i="4.80,469,1344211200"; d="scan'208";a="14709718"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Sep 2012 12:16: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.279.1; Sun, 23 Sep 2012 13:16:49 +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 1TFl7B-0006zq-9h;
	Sun, 23 Sep 2012 12:16:49 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1TFl7B-0004Nh-7B;
	Sun, 23 Sep 2012 13:16:49 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-13854-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sun, 23 Sep 2012 13:16:49 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13854: trouble: blocked/broken/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 13854 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13854/

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64                   2 host-install(2)         broken REGR. vs. 13825
 build-amd64-oldkern           2 host-install(2)         broken REGR. vs. 13825
 build-amd64-pvops             2 host-install(2)         broken REGR. vs. 13825

Tests which did not succeed, but are not blocking:
 test-amd64-i386-rhel6hvm-amd  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 xen-build-check(1)           blocked n/a
 test-amd64-amd64-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf-pin  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xend-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win           1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf      1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-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-amd64-i386-xl-multivcpu  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-qemuu-rhel6hvm-intel  1 xen-build-check(1)         blocked n/a
 test-amd64-i386-pv            1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-pcipt-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win-vcpus1    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-winxpsp3-vcpus1  1 xen-build-check(1)           blocked n/a
 test-amd64-i386-xl            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-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-win          1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 xen-build-check(1)         blocked n/a
 test-amd64-amd64-xl-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-pair         1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pair          1 xen-build-check(1)           blocked  n/a

version targeted for testing:
 xen                  8f658b463b78
baseline version:
 xen                  d364becfb083

------------------------------------------------------------
People who touched revisions under test:
  Jan Beulich <jbeulich@suse.com>
  Keir Fraser <keir@xen.org>
------------------------------------------------------------

jobs:
 build-amd64                                                  broken  
 build-i386                                                   pass    
 build-amd64-oldkern                                          broken  
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            broken  
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          blocked 
 test-amd64-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-amd64-amd64-xl-sedf-pin                                 blocked 
 test-amd64-amd64-pv                                          blocked 
 test-amd64-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-amd64-amd64-xl-win                                      blocked 
 test-amd64-amd64-xl-qemuu-winxpsp3                           blocked 
 test-amd64-i386-xend-winxpsp3                                blocked 
 test-amd64-amd64-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.

------------------------------------------------------------
changeset:   25938:8f658b463b78
tag:         tip
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Sep 21 17:02:46 2012 +0200
    
    x86: enable VIA CPU support
    
    Newer VIA CPUs have both 64-bit and VMX support. Enable them to be
    recognized for these purposes, at once stripping off any 32-bit CPU
    only bits from the respective CPU support file, and adding 64-bit ones
    found in recent Linux.
    
    This particularly implies untying the VMX == Intel assumption in a few
    places.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   25937:32187301ecc5
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Sep 21 15:20:21 2012 +0200
    
    x86: eliminate code affecting only 64-bit-incapable CPUs
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   25936:c8873f13cec3
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Sep 21 14:25:12 2012 +0200
    
    printk: prefer %#x et at over 0x%x
    
    Performance is not an issue with printk(), so let the function do
    minimally more work and instead save a byte per affected format
    specifier.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   25935:1e6e6b49b4ac
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Sep 21 13:47:18 2012 +0200
    
    x86: introduce MWAIT-based, ACPI-less CPU idle driver
    
    This is a port of Linux'es intel-idle driver serving the same purpose.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   25934:8eab91903e71
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Sep 21 13:45:08 2012 +0200
    
    cpuidle: remove unused latency_ticks member
    
    ... and code used only for initializing it.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   25933:d364becfb083
user:        Jan Beulich <jbeulich@suse.com>
date:        Thu Sep 20 13:31:19 2012 +0200
    
    introduce guest_handle_for_field()
    
    This helper turns a field of a GUEST_HANDLE in a GUEST_HANDLE.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    
    
(qemu changes not included)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Sep 23 12:17:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 23 Sep 2012 12:17:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TFl7E-0006Yu-NN; Sun, 23 Sep 2012 12:16:52 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1TFl7E-0006Yp-0c
	for xen-devel@lists.xensource.com; Sun, 23 Sep 2012 12:16:52 +0000
Received: from [85.158.139.211:60095] by server-9.bemta-5.messagelabs.com id
	B5/A8-20529-3BDFE505; Sun, 23 Sep 2012 12:16:51 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-206.messagelabs.com!1348402610!19674044!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTA4MzM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3307 invoked from network); 23 Sep 2012 12:16:50 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Sep 2012 12:16:50 -0000
X-IronPort-AV: E=Sophos;i="4.80,469,1344211200"; d="scan'208";a="14709718"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Sep 2012 12:16: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.279.1; Sun, 23 Sep 2012 13:16:49 +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 1TFl7B-0006zq-9h;
	Sun, 23 Sep 2012 12:16:49 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1TFl7B-0004Nh-7B;
	Sun, 23 Sep 2012 13:16:49 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-13854-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sun, 23 Sep 2012 13:16:49 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13854: trouble: blocked/broken/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 13854 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13854/

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64                   2 host-install(2)         broken REGR. vs. 13825
 build-amd64-oldkern           2 host-install(2)         broken REGR. vs. 13825
 build-amd64-pvops             2 host-install(2)         broken REGR. vs. 13825

Tests which did not succeed, but are not blocking:
 test-amd64-i386-rhel6hvm-amd  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 xen-build-check(1)           blocked n/a
 test-amd64-amd64-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf-pin  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xend-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win           1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf      1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-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-amd64-i386-xl-multivcpu  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-qemuu-rhel6hvm-intel  1 xen-build-check(1)         blocked n/a
 test-amd64-i386-pv            1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-pcipt-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win-vcpus1    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-winxpsp3-vcpus1  1 xen-build-check(1)           blocked n/a
 test-amd64-i386-xl            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-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-win          1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 xen-build-check(1)         blocked n/a
 test-amd64-amd64-xl-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-pair         1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pair          1 xen-build-check(1)           blocked  n/a

version targeted for testing:
 xen                  8f658b463b78
baseline version:
 xen                  d364becfb083

------------------------------------------------------------
People who touched revisions under test:
  Jan Beulich <jbeulich@suse.com>
  Keir Fraser <keir@xen.org>
------------------------------------------------------------

jobs:
 build-amd64                                                  broken  
 build-i386                                                   pass    
 build-amd64-oldkern                                          broken  
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            broken  
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          blocked 
 test-amd64-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-amd64-amd64-xl-sedf-pin                                 blocked 
 test-amd64-amd64-pv                                          blocked 
 test-amd64-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-amd64-amd64-xl-win                                      blocked 
 test-amd64-amd64-xl-qemuu-winxpsp3                           blocked 
 test-amd64-i386-xend-winxpsp3                                blocked 
 test-amd64-amd64-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.

------------------------------------------------------------
changeset:   25938:8f658b463b78
tag:         tip
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Sep 21 17:02:46 2012 +0200
    
    x86: enable VIA CPU support
    
    Newer VIA CPUs have both 64-bit and VMX support. Enable them to be
    recognized for these purposes, at once stripping off any 32-bit CPU
    only bits from the respective CPU support file, and adding 64-bit ones
    found in recent Linux.
    
    This particularly implies untying the VMX == Intel assumption in a few
    places.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   25937:32187301ecc5
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Sep 21 15:20:21 2012 +0200
    
    x86: eliminate code affecting only 64-bit-incapable CPUs
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   25936:c8873f13cec3
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Sep 21 14:25:12 2012 +0200
    
    printk: prefer %#x et at over 0x%x
    
    Performance is not an issue with printk(), so let the function do
    minimally more work and instead save a byte per affected format
    specifier.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   25935:1e6e6b49b4ac
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Sep 21 13:47:18 2012 +0200
    
    x86: introduce MWAIT-based, ACPI-less CPU idle driver
    
    This is a port of Linux'es intel-idle driver serving the same purpose.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   25934:8eab91903e71
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Sep 21 13:45:08 2012 +0200
    
    cpuidle: remove unused latency_ticks member
    
    ... and code used only for initializing it.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   25933:d364becfb083
user:        Jan Beulich <jbeulich@suse.com>
date:        Thu Sep 20 13:31:19 2012 +0200
    
    introduce guest_handle_for_field()
    
    This helper turns a field of a GUEST_HANDLE in a GUEST_HANDLE.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    
    
(qemu changes not included)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Sep 23 15:12:17 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 23 Sep 2012 15: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 1TFnqQ-0007k7-VF; Sun, 23 Sep 2012 15:11:42 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wdauchy@gmail.com>) id 1TFnqO-0007k2-JQ
	for xen-devel@lists.xensource.com; Sun, 23 Sep 2012 15:11:41 +0000
Received: from [85.158.143.99:59502] by server-1.bemta-4.messagelabs.com id
	A2/9F-05684-BA62F505; Sun, 23 Sep 2012 15:11:39 +0000
X-Env-Sender: wdauchy@gmail.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1348413094!26152540!1
X-Originating-IP: [209.85.160.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-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1168 invoked from network); 23 Sep 2012 15:11:36 -0000
Received: from mail-pb0-f43.google.com (HELO mail-pb0-f43.google.com)
	(209.85.160.43)
	by server-4.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Sep 2012 15:11:36 -0000
Received: by pbbrq2 with SMTP id rq2so13729817pbb.30
	for <xen-devel@lists.xensource.com>;
	Sun, 23 Sep 2012 08:11:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to
	:cc:content-type:content-transfer-encoding;
	bh=56VQBKH4qFV7NEVSJRn+UdL9jb40RLi2Jcl76mMTc4s=;
	b=rVtNZDKDlLQIjqHURIrQZtZqBGWZmjVzmSGfCxgH2it35IMesnTUQ58QQU5ku+UQ0m
	FYKcuuh/m6RIBOS4TuURAAGwN1HV1mzkDgTwSeiBXnXtObVqSM6Y1qFMORdppMmfRXB2
	nB3qqYfMPTePtdCIeKk61mBPI8hQk3NxsZ0brADXrh/WjddfDHZY9Z02jBdSeSfOu+PZ
	rQnol9LdnT/Rp+h+elES/yR0mzeD2h1DEM7jWHJO/GE497tof/3PQfionuhA0uSI+HcU
	kqlbs2XrgQmVjuWluFqxM16tAPuMQXfMTYqxMcTfE7vWIBG3Tzj5LxhA9kytyiHe7YR1
	Bqcg==
Received: by 10.66.74.100 with SMTP id s4mr26469097pav.27.1348413093666; Sun,
	23 Sep 2012 08:11:33 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.68.135.42 with HTTP; Sun, 23 Sep 2012 08:11:13 -0700 (PDT)
In-Reply-To: <20120920212823.GE27312@konrad-lan.dumpdata.com>
References: <CAJ75kXZm-BqWdL2O41XkSE1VCdd4ruW=+CqDmR1b3=701RnXmw@mail.gmail.com>
	<20120918133650.GC12053@phenom.dumpdata.com>
	<CAJ75kXZEaCj4Jqs_qm46d7U-s1C2hkAONs8c5Audrw2c3X=nBA@mail.gmail.com>
	<20120920134851.GB1998@localhost.localdomain>
	<CAJ75kXZ0depUJF_h0yok-r4aL0TBGnqTpW_PKT4Q7P1_6R4X2A@mail.gmail.com>
	<20120920162337.GB8912@reaktio.net>
	<CAJ75kXaXbitBvosYp8Sv_548XbvdxU=M_NSSHTb_5d56=-n4nA@mail.gmail.com>
	<20120920163525.GC8912@reaktio.net>
	<CAJ75kXZnb82GnssNWxyGMHjTYiRQCRsNdPeYdEb-tsvkshpfEg@mail.gmail.com>
	<20120920212823.GE27312@konrad-lan.dumpdata.com>
From: William Dauchy <wdauchy@gmail.com>
Date: Sun, 23 Sep 2012 17:11:13 +0200
Message-ID: <CAJ75kXZjuUgQfc=8tz2F_UEwnQWRD7AhyMOM1L+DSMFzoss9Dw@mail.gmail.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] Error getting mfn
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Sep 20, 2012 at 11:28 PM, Konrad Rzeszutek Wilk
<konrad.wilk@oracle.com> wrote:
> Ah. OK. so lets deal with one issue at hand. The CONFIG_NUMA - you said
> you applied I posted for it some time ago? Is it this one?
> http://lkml.indiana.edu/hypermail/linux/kernel/1205.3/03619.html

yes; and applied on my tests.

> For the non-NUMA case - can you try to compile a kernel without
> NUMA enabled and also include 'earlyprintk=xen' on your Linux command
> line? That should give me a good approximation of what/where
> it is being hit.

Here is the log without NUMA enabled.

(XEN) Xen version 4.1.3 (package@) (gcc version 4.4.5 (Debian 4.4.5-8)
) Mon Sep 17 15:01:52 UTC 2012
(XEN) Latest ChangeSet: Thu Aug 09 16:47:30 2012 +0100 23334:ce7195d2b80e
(XEN) Console output is synchronous.
(XEN) Bootloader: COM32 Multiboot loader v0.2
(XEN) Command line: console=com2 debug sync_console dom0_max_vcpus=1
dom0_mem=1024M,max:1024M loglvl=all guest_loglvl=all
(XEN) Video information:
(XEN)  VGA is text mode 80x25, font 8x16
(XEN)  VBE/DDC methods: none; EDID transfer time: 1 seconds
(XEN)  EDID info not retrieved because no DDC retrieval method detected
(XEN) Disc information:
(XEN)  Found 0 MBR signatures
(XEN)  Found 0 EDD information structures
(XEN) Xen-e820 RAM map:
(XEN)  0000000000000000 - 000000000009b400 (usable)
(XEN)  000000000009b400 - 00000000000a0000 (reserved)
(XEN)  00000000000e0000 - 0000000000100000 (reserved)
(XEN)  0000000000100000 - 00000000bf730000 (usable)
(XEN)  00000000bf730000 - 00000000bf73e000 (ACPI data)
(XEN)  00000000bf73e000 - 00000000bf7a0000 (ACPI NVS)
(XEN)  00000000bf7a0000 - 00000000bf7b0000 (reserved)
(XEN)  00000000bf7bc000 - 00000000c0000000 (reserved)
(XEN)  00000000e0000000 - 00000000f0000000 (reserved)
(XEN)  00000000fee00000 - 00000000fee01000 (reserved)
(XEN)  00000000ffa00000 - 0000000100000000 (reserved)
(XEN)  0000000100000000 - 0000000c40000000 (usable)
(XEN) ACPI: RSDP 000FA6F0, 0024 (r2 ACPIAM)
(XEN) ACPI: XSDT BF730100, 006C (r1 122311 XSDT1136 20111223 MSFT       97)
(XEN) ACPI: FACP BF730290, 00F4 (r4 122311 FACP1136 20111223 MSFT       97)
(XEN) ACPI: DSDT BF730540, 48F7 (r2  5442B 5442B166      166 INTL 20051117)
(XEN) ACPI: FACS BF73E000, 0040
(XEN) ACPI: APIC BF730390, 011E (r2 122311 APIC1136 20111223 MSFT       97)
(XEN) ACPI: SPCR BF7304B0, 0050 (r1 122311 SPCR1136 20111223 MSFT       97)
(XEN) ACPI: MCFG BF730500, 003C (r1 122311 OEMMCFG  20111223 MSFT       97)
(XEN) ACPI: OEMB BF73E040, 0082 (r1 122311 OEMB1136 20111223 MSFT       97)
(XEN) ACPI: SRAT BF73A540, 0250 (r2 122311 OEMSRAT         1 INTL        1)
(XEN) ACPI: HPET BF73A790, 0038 (r1 122311 OEMHPET  20111223 MSFT       97)
(XEN) ACPI: DMAR BF73E0D0, 00D8 (r1    AMI  OEMDMAR        1 MSFT       97)
(XEN) ACPI: SSDT BF7439A0, 0363 (r1 DpgPmm    CpuPm       12 INTL 20051117)
(XEN) System RAM: 49142MB (50322220kB)
(XEN) SRAT: PXM 0 -> APIC 0 -> Node 0
(XEN) SRAT: PXM 0 -> APIC 2 -> Node 0
(XEN) SRAT: PXM 0 -> APIC 4 -> Node 0
(XEN) SRAT: PXM 0 -> APIC 16 -> Node 0
(XEN) SRAT: PXM 0 -> APIC 18 -> Node 0
(XEN) SRAT: PXM 0 -> APIC 20 -> Node 0
(XEN) SRAT: PXM 0 -> APIC 1 -> Node 0
(XEN) SRAT: PXM 0 -> APIC 3 -> Node 0
(XEN) SRAT: PXM 0 -> APIC 5 -> Node 0
(XEN) SRAT: PXM 0 -> APIC 17 -> Node 0
(XEN) SRAT: PXM 0 -> APIC 19 -> Node 0
(XEN) SRAT: PXM 0 -> APIC 21 -> Node 0
(XEN) SRAT: PXM 1 -> APIC 32 -> Node 1
(XEN) SRAT: PXM 1 -> APIC 34 -> Node 1
(XEN) SRAT: PXM 1 -> APIC 36 -> Node 1
(XEN) SRAT: PXM 1 -> APIC 48 -> Node 1
(XEN) SRAT: PXM 1 -> APIC 50 -> Node 1
(XEN) SRAT: PXM 1 -> APIC 52 -> Node 1
(XEN) SRAT: PXM 1 -> APIC 33 -> Node 1
(XEN) SRAT: PXM 1 -> APIC 35 -> Node 1
(XEN) SRAT: PXM 1 -> APIC 37 -> Node 1
(XEN) SRAT: PXM 1 -> APIC 49 -> Node 1
(XEN) SRAT: PXM 1 -> APIC 51 -> Node 1
(XEN) SRAT: PXM 1 -> APIC 53 -> Node 1
(XEN) SRAT: Node 0 PXM 0 0-a0000
(XEN) SRAT: Node 0 PXM 0 100000-c0000000
(XEN) SRAT: Node 0 PXM 0 100000000-640000000
(XEN) SRAT: Node 1 PXM 1 640000000-c40000000
(XEN) NUMA: Allocated memnodemap from c3f7c5000 - c3f7d2000
(XEN) NUMA: Using 8 for the hash shift.
(XEN) Domain heap initialised DMA width 32 bits
(XEN) found SMP MP-table at 000ff780
(XEN) DMI present.
(XEN) Using APIC driver default
(XEN) ACPI: PM-Timer IO Port: 0x808
(XEN) ACPI: ACPI SLEEP INFO: pm1x_cnt[804,0], pm1x_evt[800,0]
(XEN) ACPI:                  wakeup_vec[bf73e00c], vec_size[20]
(XEN) ACPI: Local APIC address 0xfee00000
(XEN) ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled)
(XEN) Processor #0 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x02] lapic_id[0x02] enabled)
(XEN) Processor #2 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x03] lapic_id[0x04] enabled)
(XEN) Processor #4 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x04] lapic_id[0x10] enabled)
(XEN) Processor #16 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x05] lapic_id[0x12] enabled)
(XEN) Processor #18 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x06] lapic_id[0x14] enabled)
(XEN) Processor #20 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x07] lapic_id[0x20] enabled)
(XEN) Processor #32 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x08] lapic_id[0x22] enabled)
(XEN) Processor #34 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x09] lapic_id[0x24] enabled)
(XEN) Processor #36 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x0a] lapic_id[0x30] enabled)
(XEN) Processor #48 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x0b] lapic_id[0x32] enabled)
(XEN) Processor #50 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x0c] lapic_id[0x34] enabled)
(XEN) Processor #52 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x0d] lapic_id[0x01] enabled)
(XEN) Processor #1 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x0e] lapic_id[0x03] enabled)
(XEN) Processor #3 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x0f] lapic_id[0x05] enabled)
(XEN) Processor #5 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x10] lapic_id[0x11] enabled)
(XEN) Processor #17 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x11] lapic_id[0x13] enabled)
(XEN) Processor #19 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x12] lapic_id[0x15] enabled)
(XEN) Processor #21 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x13] lapic_id[0x21] enabled)
(XEN) Processor #33 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x14] lapic_id[0x23] enabled)
(XEN) Processor #35 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x15] lapic_id[0x25] enabled)
(XEN) Processor #37 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x16] lapic_id[0x31] enabled)
(XEN) Processor #49 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x17] lapic_id[0x33] enabled)
(XEN) Processor #51 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x18] lapic_id[0x35] enabled)
(XEN) Processor #53 6:12 APIC version 21
(XEN) ACPI: LAPIC_NMI (acpi_id[0xff] dfl dfl lint[0x1])
(XEN) Overriding APIC driver with bigsmp
(XEN) ACPI: IOAPIC (id[0x06] address[0xfec00000] gsi_base[0])
(XEN) IOAPIC[0]: apic_id 6, version 32, address 0xfec00000, GSI 0-23
(XEN) ACPI: IOAPIC (id[0x07] address[0xfec8a000] gsi_base[24])
(XEN) IOAPIC[1]: apic_id 7, version 32, address 0xfec8a000, GSI 24-47
(XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
(XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
(XEN) ACPI: IRQ0 used by override.
(XEN) ACPI: IRQ2 used by override.
(XEN) ACPI: IRQ9 used by override.
(XEN) Enabling APIC mode:  Phys.  Using 2 I/O APICs
(XEN) ACPI: HPET id: 0x8086a301 base: 0xfed00000
(XEN) PCI: MCFG configuration 0: base e0000000 segment 0 buses 0 - 255
(XEN) PCI: MCFG area at e0000000 reserved in E820
(XEN) Table is not found!
(XEN) Using ACPI (MADT) for SMP configuration information
(XEN) IRQ limits: 48 GSI, 4576 MSI/MSI-X
(XEN) Using scheduler: SMP Credit Scheduler (credit)
(XEN) Detected 2266.815 MHz processor.
(XEN) Initing memory sharing.
(XEN) mce_intel.c:1162: MCA Capability: BCAST 1 SER 0 CMCI 1 firstbank
0 extended MCE MSR 0
(XEN) Intel machine check reporting enabled
(XEN) Intel VT-d supported page sizes: 4kB.
(XEN) Intel VT-d Snoop Control enabled.
(XEN) Intel VT-d Dom0 DMA Passthrough not enabled.
(XEN) Intel VT-d Queued Invalidation enabled.
(XEN) Intel VT-d Interrupt Remapping not enabled.
(XEN) Intel VT-d Shared EPT tables not enabled.
(XEN) I/O virtualisation enabled
(XEN)  - Dom0 mode: Relaxed
(XEN) Enabled directed EOI with ioapic_ack_old on!
(XEN) ENABLING IO-APIC IRQs
(XEN)  -> Using old ACK method
(XEN) ..TIMER: vector=0xF0 apic1=0 pin1=2 apic2=-1 pin2=-1
(XEN) Platform timer is 14.318MHz HPET
(XEN) Defaulting to alternative key handling; send 'A' to switch to normal mode.
(XEN) Allocated console ring of 256 KiB.
(XEN) VMX: Supported advanced features:
(XEN)  - APIC MMIO access virtualisation
(XEN)  - APIC TPR shadow
(XEN)  - Extended Page Tables (EPT)
(XEN)  - Virtual-Processor Identifiers (VPID)
(XEN)  - Virtual NMI
(XEN)  - MSR direct-access bitmap
(XEN)  - Unrestricted Guest
(XEN) HVM: ASIDs enabled.
(XEN) HVM: VMX enabled
(XEN) HVM: Hardware Assisted Paging (HAP) detected
(XEN) HVM: HAP page sizes: 4kB, 2MB, 1GB
(XEN) Brought up 24 CPUs
(XEN) ACPI sleep modes: S3
(XEN) mcheck_poll: Machine check polling timer started.
(XEN) *** LOADING DOMAIN 0 ***
(XEN)  Xen  kernel: 64-bit, lsb, compat32
(XEN)  Dom0 kernel: 32-bit, PAE, lsb, paddr 0x1000000 -> 0x17ce000
(XEN) PHYSICAL MEMORY ARRANGEMENT:
(XEN)  Dom0 alloc.:   0000000c20000000->0000000c22000000 (253212 pages
to be allocated)
(XEN)  Init. ramdisk: 0000000c3fd1c000->0000000c3ffff200
(XEN) VIRTUAL MEMORY ARRANGEMENT:
(XEN)  Loaded kernel: 00000000c1000000->00000000c17ce000
(XEN)  Init. ramdisk: 00000000c17ce000->00000000c1ab1200
(XEN)  Phys-Mach map: 00000000c1ab2000->00000000c1bb2000
(XEN)  Start info:    00000000c1bb2000->00000000c1bb24b4
(XEN)  Page tables:   00000000c1bb3000->00000000c1bc9000
(XEN)  Boot stack:    00000000c1bc9000->00000000c1bca000
(XEN)  TOTAL:         00000000c0000000->00000000c2000000
(XEN)  ENTRY ADDRESS: 00000000c14eb000
(XEN) Dom0 has maximum 1 VCPUs
(XEN) Scrubbing Free RAM:
..........................................................................................................................................................................................................................................................................................................................................................................................................................................................................................done.
(XEN) Xen trace buffers: disabled
(XEN) Std. Loglevel: All
(XEN) Guest Loglevel: All
(XEN) **********************************************
(XEN) ******* WARNING: CONSOLE OUTPUT IS SYNCHRONOUS
(XEN) ******* This option is intended to aid debugging of Xen by ensuring
(XEN) ******* that all output is synchronously delivered on the serial line.
(XEN) ******* However it can introduce SIGNIFICANT latencies and affect
(XEN) ******* timekeeping. It is NOT recommended for production use!
(XEN) **********************************************
(XEN) 3... 2... 1...
(XEN) *** Serial input -> DOM0 (type 'CTRL-a' three times to switch
input to Xen)
(XEN) Freed 212kB init memory.
mapping kernel into physical memory
Xen: setup ISA identity maps
about to get started...
Reserving virtual address space above 0xfcc00000
Linux version 3.4.11 (gcc version 4.4.5 (Debian 4.4.5-8) ) #18 SMP Sun
Sep 23 14:32:16 UTC 2012
KERNEL supported cpus:
  Intel GenuineIntel
Freeing  9b-100 pfn range: 101 pages freed
1-1 mapping on 9b->100
1-1 mapping on bf730->100000
Released 101 pages of unused memory
Set 264501 page(s) to 1-1 mapping
BIOS-provided physical RAM map:
 Xen: 0000000000000000 - 000000000009b000 (usable)
 Xen: 000000000009b400 - 0000000000100000 (reserved)
 Xen: 0000000000100000 - 0000000040065000 (usable)
 Xen: 0000000040065000 - 00000000bf730000 (unusable)
 Xen: 00000000bf730000 - 00000000bf73e000 (ACPI data)
 Xen: 00000000bf73e000 - 00000000bf7a0000 (ACPI NVS)
 Xen: 00000000bf7a0000 - 00000000bf7b0000 (reserved)
 Xen: 00000000bf7bc000 - 00000000c0000000 (reserved)
 Xen: 00000000e0000000 - 00000000f0000000 (reserved)
 Xen: 00000000fec00000 - 00000000fec01000 (reserved)
 Xen: 00000000fec8a000 - 00000000fec8b000 (reserved)
 Xen: 00000000fee00000 - 00000000fee01000 (reserved)
 Xen: 00000000ffa00000 - 0000000100000000 (reserved)
 Xen: 0000000100000000 - 0000000c40000000 (unusable)
bootconsole [xenboot0] enabled
NX (Execute Disable) protection: active
DMI present.
DMI: Dell       C6100           /0D61XP, BIOS 1.66 12/23/2011
e820 update range: 0000000000000000 - 0000000000010000 (usable) ==> (reserved)
e820 remove range: 00000000000a0000 - 0000000000100000 (usable)
last_pfn = 0x40065 max_arch_pfn = 0x1000000
initial memory mapped : 0 - 027ff000
Base memory trampoline at [c009a000] 9a000 size 4096
init_memory_mapping: 0000000000000000-00000000345fe000
 0000000000 - 00345fe000 page 4k
kernel direct mapping tables up to 345fe000 @ 2658000-27ff000
(XEN) mm.c:908:d0 Error getting mfn 2009b (pfn 5555555555555555) from
L1 entry 000000002009b023 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 000000002009b023
(XEN) mm.c:908:d0 Error getting mfn 2009c (pfn 5555555555555555) from
L1 entry 000000002009c023 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 000000002009c023
(XEN) mm.c:908:d0 Error getting mfn 2009d (pfn 5555555555555555) from
L1 entry 000000002009d023 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 000000002009d023
(XEN) mm.c:908:d0 Error getting mfn 2009e (pfn 5555555555555555) from
L1 entry 000000002009e023 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 000000002009e023
(XEN) mm.c:908:d0 Error getting mfn 2009f (pfn 5555555555555555) from
L1 entry 000000002009f023 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 000000002009f023
xen: setting RW the range 27e9000 - 27ff000
RAMDISK: 017ce000 - 01ab2000
ACPI: RSDP 000fa6f0 00024 (v02 ACPIAM)
ACPI: XSDT bf730100 0006C (v01 122311 XSDT1136 20111223 MSFT 00000097)
ACPI: FACP bf730290 000F4 (v04 122311 FACP1136 20111223 MSFT 00000097)
ACPI: DSDT bf730540 048F7 (v02  5442B 5442B166 00000166 INTL 20051117)
ACPI: FACS bf73e000 00040
ACPI: APIC bf730390 0011E (v02 122311 APIC1136 20111223 MSFT 00000097)
ACPI: SPCR bf7304b0 00050 (v01 122311 SPCR1136 20111223 MSFT 00000097)
ACPI: MCFG bf730500 0003C (v01 122311 OEMMCFG  20111223 MSFT 00000097)
ACPI: OEMB bf73e040 00082 (v01 122311 OEMB1136 20111223 MSFT 00000097)
ACPI: SRAT bf73a540 00250 (v02 122311 OEMSRAT  00000001 INTL 00000001)
ACPI: HPET bf73a790 00038 (v01 122311 OEMHPET  20111223 MSFT 00000097)
ACPI: XMAR bf73e0d0 000D8 (v01    AMI  OEMDMAR 00000001 MSFT 00000097)
ACPI: SSDT bf7439a0 00363 (v01 DpgPmm    CpuPm 00000012 INTL 20051117)
ACPI: Local APIC address 0xfee00000
186MB HIGHMEM available.
837MB LOWMEM available.
  mapped low ram: 0 - 345fe000
  low ram: 0 - 345fe000
Zone PFN ranges:
  DMA      0x00000010 -> 0x00001000
  Normal   0x00001000 -> 0x000345fe
  HighMem  0x000345fe -> 0x00040065
Movable zone start PFN for each node
Early memory PFN ranges
    0: 0x00000010 -> 0x0000009b
    0: 0x00000100 -> 0x00040065
On node 0 totalpages: 262128
  DMA zone: 32 pages used for memmap
  DMA zone: 0 pages reserved
  DMA zone: 3947 pages, LIFO batch:0
  Normal zone: 1644 pages used for memmap
  Normal zone: 208786 pages, LIFO batch:31
  HighMem zone: 373 pages used for memmap
  HighMem zone: 47346 pages, LIFO batch:15
Using APIC driver default
ACPI: PM-Timer IO Port: 0x808
ACPI: Local APIC address 0xfee00000
ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled)
ACPI: LAPIC (acpi_id[0x02] lapic_id[0x02] enabled)
ACPI: LAPIC (acpi_id[0x03] lapic_id[0x04] enabled)
ACPI: LAPIC (acpi_id[0x04] lapic_id[0x10] enabled)
ACPI: LAPIC (acpi_id[0x05] lapic_id[0x12] enabled)
ACPI: LAPIC (acpi_id[0x06] lapic_id[0x14] enabled)
ACPI: LAPIC (acpi_id[0x07] lapic_id[0x20] enabled)
ACPI: LAPIC (acpi_id[0x08] lapic_id[0x22] enabled)
ACPI: LAPIC (acpi_id[0x09] lapic_id[0x24] enabled)
ACPI: LAPIC (acpi_id[0x0a] lapic_id[0x30] enabled)
ACPI: LAPIC (acpi_id[0x0b] lapic_id[0x32] enabled)
ACPI: LAPIC (acpi_id[0x0c] lapic_id[0x34] enabled)
ACPI: LAPIC (acpi_id[0x0d] lapic_id[0x01] enabled)
ACPI: LAPIC (acpi_id[0x0e] lapic_id[0x03] enabled)
ACPI: LAPIC (acpi_id[0x0f] lapic_id[0x05] enabled)
ACPI: LAPIC (acpi_id[0x10] lapic_id[0x11] enabled)
ACPI: LAPIC (acpi_id[0x11] lapic_id[0x13] enabled)
ACPI: LAPIC (acpi_id[0x12] lapic_id[0x15] enabled)
ACPI: LAPIC (acpi_id[0x13] lapic_id[0x21] enabled)
ACPI: LAPIC (acpi_id[0x14] lapic_id[0x23] enabled)
ACPI: LAPIC (acpi_id[0x15] lapic_id[0x25] enabled)
ACPI: LAPIC (acpi_id[0x16] lapic_id[0x31] enabled)
ACPI: LAPIC (acpi_id[0x17] lapic_id[0x33] enabled)
ACPI: LAPIC (acpi_id[0x18] lapic_id[0x35] enabled)
ACPI: LAPIC_NMI (acpi_id[0xff] dfl dfl lint[0x1])
ACPI: IOAPIC (id[0x06] address[0xfec00000] gsi_base[0])
IOAPIC[0]: apic_id 6, version 253, address 0xfec00000, GSI 0-253
ACPI: IOAPIC (id[0x07] address[0xfec8a000] gsi_base[24])
IOAPIC[1]: apic_id 7, version 253, address 0xfec8a000, GSI 24-277
ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
ACPI: IRQ0 used by override.
ACPI: IRQ2 used by override.
ACPI: IRQ9 used by override.
Using ACPI (MADT) for SMP configuration information
ACPI: HPET id: 0x8086a301 base: 0xfed00000
SMP: Allowing 24 CPUs, 0 hotplug CPUs
nr_irqs_gsi: 294
Allocating PCI resources starting at c0000000 (gap: c0000000:20000000)
Booting paravirtualized kernel on Xen
Xen version: 4.1.3 (preserve-AD)
setup_percpu: NR_CPUS:32 nr_cpumask_bits:32 nr_cpu_ids:24 nr_node_ids:1
PERCPU: Embedded 12 pages/cpu @f38b6000 s27072 r0 d22080 u49152
pcpu-alloc: s27072 r0 d22080 u49152 alloc=12*4096
pcpu-alloc: [0] 00 [0] 01 [0] 02 [0] 03 [0] 04 [0] 05 [0] 06 [0] 07
pcpu-alloc: [0] 08 [0] 09 [0] 10 [0] 11 [0] 12 [0] 13 [0] 14 [0] 15
pcpu-alloc: [0] 16 [0] 17 [0] 18 [0] 19 [0] 20 [0] 21 [0] 22 [0] 23
Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 260079
Kernel command line: root=/dev/nfs loglvl=all verbose=y console=hvc0
debug loglevel=8 earlyprintk=xen
PID hash table entries: 4096 (order: 2, 16384 bytes)
Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
Initializing CPU#0
Placing 64MB software IO TLB between ef7f2000 - f37f2000
software IO TLB at phys 0x2f7f2000 - 0x337f2000
Initializing HighMem for node 0 (000345fe:00040065)
Memory: 956424k/1048980k available (3623k kernel code, 91684k
reserved, 1410k data, 344k init, 190472k highmem)
virtual kernel memory layout:
    fixmap  : 0xfc936000 - 0xfcbff000   (2852 kB)
    pkmap   : 0xfc600000 - 0xfc800000   (2048 kB)
    vmalloc : 0xf4dfe000 - 0xfc5fe000   ( 120 MB)
    lowmem  : 0xc0000000 - 0xf45fe000   ( 837 MB)
      .init : 0xc14eb000 - 0xc1541000   ( 344 kB)
      .data : 0xc1389c49 - 0xc14ea840   (1410 kB)
      .text : 0xc1000000 - 0xc1389c49   (3623 kB)
Hierarchical RCU implementation.
	Additional per-CPU info printed with stalls.
NR_IRQS:2304 nr_irqs:256 16
CPU 0 irqstacks, hard=ef008000 soft=ef00a000
xen: sci override: global_irq=9 trigger=0 polarity=0
xen: registering gsi 9 triggering 0 polarity 0
xen: --> pirq=9 -> irq=9 (gsi=9)
xen: acpi sci 9
xen: --> pirq=1 -> irq=1 (gsi=1)
xen: --> pirq=2 -> irq=2 (gsi=2)
xen: --> pirq=3 -> irq=3 (gsi=3)
xen: --> pirq=4 -> irq=4 (gsi=4)
xen: --> pirq=5 -> irq=5 (gsi=5)
xen: --> pirq=6 -> irq=6 (gsi=6)
xen: --> pirq=7 -> irq=7 (gsi=7)
xen: --> pirq=8 -> irq=8 (gsi=8)
xen: --> pirq=10 -> irq=10 (gsi=10)
xen: --> pirq=11 -> irq=11 (gsi=11)
xen: --> pirq=12 -> irq=12 (gsi=12)
xen: --> pirq=13 -> irq=13 (gsi=13)
xen: --> pirq=14 -> irq=14 (gsi=14)
xen: --> pirq=15 -> irq=15 (gsi=15)
Console: colour VGA+ 80x25
console [hvc0] enabled, bootconsole disabled
console [hvc0] enabled, bootconsole disabled
Xen: using vcpuop timer interface
installing Xen timer for CPU 0
Detected 2266.814 MHz processor.
Calibrating delay loop (skipped), value calculated using timer
frequency.. 4533.62 BogoMIPS (lpj=9067256)
pid_max: default: 32768 minimum: 301
Mount-cache hash table entries: 512
CPU: Physical Processor ID: 0
CPU: Processor Core ID: 0
ENERGY_PERF_BIAS: Set to 'normal', was 'performance'
ENERGY_PERF_BIAS: View and update with x86_energy_perf_policy(8)
SMP alternatives: switching to UP code
Freeing SMP alternatives: 20k freed
ACPI: Core revision 20120320
Performance Events: unsupported p6 CPU model 44 no PMU driver,
software events only.
Brought up 1 CPUs
Grant tables using version 2 layout.
Grant table initialized
NET: Registered protocol family 16
ACPI: bus type pci registered
dca service started, version 1.12.1
PCI: MMCONFIG for domain 0000 [bus 00-ff] at [mem
0xe0000000-0xefffffff] (base 0xe0000000)
PCI: MMCONFIG at [mem 0xe0000000-0xefffffff] reserved in E820
PCI: Using MMCONFIG for extended config space
PCI: Using configuration type 1 for base access
bio: create slab <bio-0> at 0
ACPI: Added _OSI(Module Device)
ACPI: Added _OSI(Processor Device)
ACPI: Added _OSI(3.0 _SCP Extensions)
ACPI: Added _OSI(Processor Aggregator Device)
ACPI: EC: Look up EC in DSDT
\_SB_:_OSC invalid UUID
_OSC request data:1 6
ACPI: Executed 2 blocks of module-level executable AML code
ACPI: SSDT bf73e1b0 0414C (v01 DpgPmm  P001Ist 00000011 INTL 20051117)
ACPI: Dynamic OEM Table Load:
ACPI: SSDT   (null) 0414C (v01 DpgPmm  P001Ist 00000011 INTL 20051117)
ACPI: SSDT bf742300 00C88 (v01  PmRef  P001Cst 00003001 INTL 20051117)
ACPI: Dynamic OEM Table Load:
ACPI: SSDT   (null) 00C88 (v01  PmRef  P001Cst 00003001 INTL 20051117)
ACPI: SSDT bf742f90 00A0A (v01  PmRef  Cpu0Tst 00003000 INTL 20051117)
ACPI: Dynamic OEM Table Load:
ACPI: SSDT   (null) 00A0A (v01  PmRef  Cpu0Tst 00003000 INTL 20051117)
ACPI: Interpreter enabled
ACPI: (supports S0 S5)
ACPI: Using IOAPIC for interrupt routing
PCI: Using host bridge windows from ACPI; if necessary, use
"pci=nocrs" and report a bug
ACPI: PCI Root Bridge [PCI0] (domain 0000 [bus 00-ff])
pci_root PNP0A08:00: host bridge window [io  0x0000-0x03af]
pci_root PNP0A08:00: host bridge window [io  0x03e0-0x0cf7]
pci_root PNP0A08:00: host bridge window [io  0x03b0-0x03bb]
pci_root PNP0A08:00: host bridge window [io  0x03c0-0x03df]
pci_root PNP0A08:00: host bridge window [io  0x0d00-0xffff]
pci_root PNP0A08:00: host bridge window [mem 0x000a0000-0x000bffff]
pci_root PNP0A08:00: host bridge window [mem 0x000d0000-0x000dffff]
pci_root PNP0A08:00: host bridge window [mem 0xc0000000-0xdfffffff]
pci_root PNP0A08:00: host bridge window [mem 0xf0000000-0xfed8ffff]
PCI host bridge to bus 0000:00
pci_bus 0000:00: root bus resource [io  0x0000-0x03af]
pci_bus 0000:00: root bus resource [io  0x03e0-0x0cf7]
pci_bus 0000:00: root bus resource [io  0x03b0-0x03bb]
pci_bus 0000:00: root bus resource [io  0x03c0-0x03df]
pci_bus 0000:00: root bus resource [io  0x0d00-0xffff]
pci_bus 0000:00: root bus resource [mem 0x000a0000-0x000bffff]
pci_bus 0000:00: root bus resource [mem 0x000d0000-0x000dffff]
pci_bus 0000:00: root bus resource [mem 0xc0000000-0xdfffffff]
pci_bus 0000:00: root bus resource [mem 0xf0000000-0xfed8ffff]
pci 0000:00:00.0: [8086:3406] type 00 class 0x060000
pci 0000:00:00.0: PME# supported from D0 D3hot D3cold
pci 0000:00:01.0: [8086:3408] type 01 class 0x060400
pci 0000:00:01.0: PME# supported from D0 D3hot D3cold
pci 0000:00:03.0: [8086:340a] type 01 class 0x060400
pci 0000:00:03.0: PME# supported from D0 D3hot D3cold
pci 0000:00:05.0: [8086:340c] type 01 class 0x060400
pci 0000:00:05.0: PME# supported from D0 D3hot D3cold
pci 0000:00:07.0: [8086:340e] type 01 class 0x060400
pci 0000:00:07.0: PME# supported from D0 D3hot D3cold
pci 0000:00:13.0: [8086:342d] type 00 class 0x080020
pci 0000:00:13.0: reg 10: [mem 0xfec8a000-0xfec8afff]
pci 0000:00:13.0: PME# supported from D0 D3hot D3cold
pci 0000:00:14.0: [8086:342e] type 00 class 0x080000
pci 0000:00:14.1: [8086:3422] type 00 class 0x080000
pci 0000:00:14.2: [8086:3423] type 00 class 0x080000
pci 0000:00:14.3: [8086:3438] type 00 class 0x080000
pci 0000:00:16.0: [8086:3430] type 00 class 0x088000
pci 0000:00:16.0: reg 10: [mem 0xfbef8000-0xfbefbfff 64bit]
pci 0000:00:16.1: [8086:3431] type 00 class 0x088000
pci 0000:00:16.1: reg 10: [mem 0xfbef4000-0xfbef7fff 64bit]
pci 0000:00:16.2: [8086:3432] type 00 class 0x088000
pci 0000:00:16.2: reg 10: [mem 0xfbef0000-0xfbef3fff 64bit]
pci 0000:00:16.3: [8086:3433] type 00 class 0x088000
pci 0000:00:16.3: reg 10: [mem 0xfbeec000-0xfbeeffff 64bit]
pci 0000:00:16.4: [8086:3429] type 00 class 0x088000
pci 0000:00:16.4: reg 10: [mem 0xfbee8000-0xfbeebfff 64bit]
pci 0000:00:16.5: [8086:342a] type 00 class 0x088000
pci 0000:00:16.5: reg 10: [mem 0xfbee4000-0xfbee7fff 64bit]
pci 0000:00:16.6: [8086:342b] type 00 class 0x088000
pci 0000:00:16.6: reg 10: [mem 0xfbee0000-0xfbee3fff 64bit]
pci 0000:00:16.7: [8086:342c] type 00 class 0x088000
pci 0000:00:16.7: reg 10: [mem 0xfbedc000-0xfbedffff 64bit]
pci 0000:00:1d.0: [8086:3a34] type 00 class 0x0c0300
pci 0000:00:1d.0: reg 20: [io  0xbc00-0xbc1f]
pci 0000:00:1d.1: [8086:3a35] type 00 class 0x0c0300
pci 0000:00:1d.1: reg 20: [io  0xb880-0xb89f]
pci 0000:00:1d.2: [8086:3a36] type 00 class 0x0c0300
pci 0000:00:1d.2: reg 20: [io  0xb800-0xb81f]
pci 0000:00:1d.7: [8086:3a3a] type 00 class 0x0c0320
pci 0000:00:1d.7: reg 10: [mem 0xfbeda000-0xfbeda3ff]
pci 0000:00:1d.7: PME# supported from D0 D3hot D3cold
pci 0000:00:1e.0: [8086:244e] type 01 class 0x060401
pci 0000:00:1f.0: [8086:3a16] type 00 class 0x060100
pci 0000:00:1f.0: ICH7 LPC Generic IO decode 2 PIO at 0ca0 (mask 000f)
pci 0000:00:1f.2: [8086:3a22] type 00 class 0x010601
pci 0000:00:1f.2: reg 10: [io  0xac00-0xac07]
pci 0000:00:1f.2: reg 14: [io  0xb480-0xb483]
pci 0000:00:1f.2: reg 18: [io  0xb400-0xb407]
pci 0000:00:1f.2: reg 1c: [io  0xb080-0xb083]
pci 0000:00:1f.2: reg 20: [io  0xb000-0xb01f]
pci 0000:00:1f.2: reg 24: [mem 0xfbed8000-0xfbed87ff]
pci 0000:00:1f.2: PME# supported from D3hot
pci 0000:00:1f.3: [8086:3a30] type 00 class 0x0c0500
pci 0000:00:1f.3: reg 10: [mem 0xfbed6000-0xfbed60ff 64bit]
pci 0000:00:1f.3: reg 20: [io  0x0400-0x041f]
pci 0000:01:00.0: [8086:10c9] type 00 class 0x020000
pci 0000:01:00.0: reg 10: [mem 0xfbce0000-0xfbcfffff]
pci 0000:01:00.0: reg 14: [mem 0xfbcc0000-0xfbcdffff]
pci 0000:01:00.0: reg 18: [io  0xcc00-0xcc1f]
pci 0000:01:00.0: reg 1c: [mem 0xfbc9c000-0xfbc9ffff]
pci 0000:01:00.0: reg 30: [mem 0xfbca0000-0xfbcbffff pref]
pci 0000:01:00.0: PME# supported from D0 D3hot D3cold
pci 0000:01:00.1: [8086:10c9] type 00 class 0x020000
pci 0000:01:00.1: reg 10: [mem 0xfbc20000-0xfbc3ffff]
pci 0000:01:00.1: reg 14: [mem 0xfbc00000-0xfbc1ffff]
pci 0000:01:00.1: reg 18: [io  0xc880-0xc89f]
pci 0000:01:00.1: reg 1c: [mem 0xfbbdc000-0xfbbdffff]
pci 0000:01:00.1: reg 30: [mem 0xfbbe0000-0xfbbfffff pref]
pci 0000:01:00.1: PME# supported from D0 D3hot D3cold
pci 0000:00:01.0: PCI bridge to [bus 01-02]
pci 0000:00:01.0:   bridge window [io  0xc000-0xcfff]
pci 0000:00:01.0:   bridge window [mem 0xfbb00000-0xfbcfffff]
pci 0000:03:00.0: [8086:10fb] type 00 class 0x020000
pci 0000:03:00.0: reg 10: [mem 0xfbdc0000-0xfbdfffff 64bit]
pci 0000:03:00.0: reg 18: [io  0xdc00-0xdc1f]
pci 0000:03:00.0: reg 20: [mem 0xfbd9c000-0xfbd9ffff 64bit]
pci 0000:03:00.0: reg 30: [mem 0xfbda0000-0xfbdbffff pref]
pci 0000:03:00.0: PME# supported from D0 D3hot
pci 0000:03:00.1: [8086:10fb] type 00 class 0x020000
pci 0000:03:00.1: reg 10: [mem 0xfbd40000-0xfbd7ffff 64bit]
pci 0000:03:00.1: reg 18: [io  0xd880-0xd89f]
pci 0000:03:00.1: reg 20: [mem 0xfbd1c000-0xfbd1ffff 64bit]
pci 0000:03:00.1: reg 30: [mem 0xfbd20000-0xfbd3ffff pref]
pci 0000:03:00.1: PME# supported from D0 D3hot
pci 0000:00:03.0: PCI bridge to [bus 03-04]
pci 0000:00:03.0:   bridge window [io  0xd000-0xdfff]
pci 0000:00:03.0:   bridge window [mem 0xfbd00000-0xfbdfffff]
pci 0000:00:03.0:   bridge window [mem 0xf9c00000-0xf9ffffff 64bit pref]
pci 0000:00:05.0: PCI bridge to [bus 05-05]
pci 0000:00:07.0: PCI bridge to [bus 06-06]
pci 0000:07:04.0: [1a03:2000] type 00 class 0x030000
pci 0000:07:04.0: reg 10: [mem 0xfb000000-0xfb7fffff]
pci 0000:07:04.0: reg 14: [mem 0xfafe0000-0xfaffffff]
pci 0000:07:04.0: reg 18: [io  0xec00-0xec7f]
pci 0000:07:04.0: supports D1 D2
pci 0000:07:04.0: PME# supported from D0 D1 D2 D3hot D3cold
pci 0000:00:1e.0: PCI bridge to [bus 07-07] (subtractive decode)
pci 0000:00:1e.0:   bridge window [io  0xe000-0xefff]
pci 0000:00:1e.0:   bridge window [mem 0xfaf00000-0xfb7fffff]
pci 0000:00:1e.0:   bridge window [io  0x0000-0x03af] (subtractive decode)
pci 0000:00:1e.0:   bridge window [io  0x03e0-0x0cf7] (subtractive decode)
pci 0000:00:1e.0:   bridge window [io  0x03b0-0x03bb] (subtractive decode)
pci 0000:00:1e.0:   bridge window [io  0x03c0-0x03df] (subtractive decode)
pci 0000:00:1e.0:   bridge window [io  0x0d00-0xffff] (subtractive decode)
pci 0000:00:1e.0:   bridge window [mem 0x000a0000-0x000bffff]
(subtractive decode)
pci 0000:00:1e.0:   bridge window [mem 0x000d0000-0x000dffff]
(subtractive decode)
pci 0000:00:1e.0:   bridge window [mem 0xc0000000-0xdfffffff]
(subtractive decode)
pci 0000:00:1e.0:   bridge window [mem 0xf0000000-0xfed8ffff]
(subtractive decode)
pci_bus 0000:00: on NUMA node 0
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT]
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.NPE7._PRT]
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.P0P1._PRT]
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.NPE1._PRT]
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.NPE5._PRT]
 pci0000:00: Unable to request _OSC control (_OSC support mask: 0x19)
(XEN) PCI add device 00:00.0
(XEN) PCI add device 00:01.0
(XEN) PCI add device 00:03.0
(XEN) PCI add device 00:05.0
(XEN) PCI add device 00:07.0
(XEN) PCI add device 00:13.0
(XEN) PCI add device 00:14.0
(XEN) PCI add device 00:14.1
(XEN) PCI add device 00:14.2
(XEN) PCI add device 00:14.3
(XEN) PCI add device 00:16.0
(XEN) PCI add device 00:16.1
(XEN) PCI add device 00:16.2
(XEN) PCI add device 00:16.3
(XEN) PCI add device 00:16.4
(XEN) PCI add device 00:16.5
(XEN) PCI add device 00:16.6
(XEN) PCI add device 00:16.7
(XEN) PCI add device 00:1d.0
(XEN) PCI add device 00:1d.1
(XEN) PCI add device 00:1d.2
(XEN) PCI add device 00:1d.7
(XEN) PCI add device 00:1e.0
(XEN) PCI add device 00:1f.0
(XEN) PCI add device 00:1f.2
(XEN) PCI add device 00:1f.3
(XEN) PCI add device 01:00.0
(XEN) PCI add device 01:00.1
(XEN) PCI add device 03:00.0
(XEN) PCI add device 03:00.1
(XEN) PCI add device 07:04.0
ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 6 7 *10 11 12 14 15)
ACPI: PCI Interrupt Link [LNKB] (IRQs *5)
ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 6 7 10 11 12 14 *15)
ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 6 7 10 *11 12 14 15)
ACPI: PCI Interrupt Link [LNKE] (IRQs 3 4 6 7 10 11 12 14 15) *0, disabled.
ACPI: PCI Interrupt Link [LNKF] (IRQs 3 4 6 7 10 11 12 14 15) *0, disabled.
ACPI: PCI Interrupt Link [LNKG] (IRQs 3 4 6 7 10 11 12 14 15) *0, disabled.
ACPI: PCI Interrupt Link [LNKH] (IRQs 3 4 6 7 10 11 12 *14 15)
xen/balloon: Initialising balloon driver.
xen-balloon: Initialising balloon driver.
xen/balloon: Xen selfballooning driver disabled for domain0.
vgaarb: device added: PCI:0000:07:04.0,decodes=io+mem,owns=io+mem,locks=none
vgaarb: loaded
vgaarb: bridge control possible 0000:07:04.0
PCI: Using ACPI for IRQ routing
PCI: Discovered peer bus fe
PCI: root bus fe: using default resources
PCI host bridge to bus 0000:fe
pci_bus 0000:fe: root bus resource [io  0x0000-0xffff]
pci_bus 0000:fe: root bus resource [mem 0x00000000-0xffffffffff]
pci 0000:fe:00.0: [8086:2c70] type 00 class 0x060000
pci 0000:fe:00.1: [8086:2d81] type 00 class 0x060000
pci 0000:fe:02.0: [8086:2d90] type 00 class 0x060000
pci 0000:fe:02.1: [8086:2d91] type 00 class 0x060000
pci 0000:fe:02.2: [8086:2d92] type 00 class 0x060000
pci 0000:fe:02.3: [8086:2d93] type 00 class 0x060000
pci 0000:fe:02.4: [8086:2d94] type 00 class 0x060000
pci 0000:fe:02.5: [8086:2d95] type 00 class 0x060000
pci 0000:fe:03.0: [8086:2d98] type 00 class 0x060000
pci 0000:fe:03.1: [8086:2d99] type 00 class 0x060000
pci 0000:fe:03.2: [8086:2d9a] type 00 class 0x060000
pci 0000:fe:03.4: [8086:2d9c] type 00 class 0x060000
pci 0000:fe:04.0: [8086:2da0] type 00 class 0x060000
pci 0000:fe:04.1: [8086:2da1] type 00 class 0x060000
pci 0000:fe:04.2: [8086:2da2] type 00 class 0x060000
pci 0000:fe:04.3: [8086:2da3] type 00 class 0x060000
pci 0000:fe:05.0: [8086:2da8] type 00 class 0x060000
pci 0000:fe:05.1: [8086:2da9] type 00 class 0x060000
pci 0000:fe:05.2: [8086:2daa] type 00 class 0x060000
pci 0000:fe:05.3: [8086:2dab] type 00 class 0x060000
pci 0000:fe:06.0: [8086:2db0] type 00 class 0x060000
pci 0000:fe:06.1: [8086:2db1] type 00 class 0x060000
pci 0000:fe:06.2: [8086:2db2] type 00 class 0x060000
pci 0000:fe:06.3: [8086:2db3] type 00 class 0x060000
(XEN) PCI add device fe:00.0
(XEN) PCI add device fe:00.1
(XEN) PCI add device fe:02.0
(XEN) PCI add device fe:02.1
(XEN) PCI add device fe:02.2
(XEN) PCI add device fe:02.3
(XEN) PCI add device fe:02.4
(XEN) PCI add device fe:02.5
(XEN) PCI add device fe:03.0
(XEN) PCI add device fe:03.1
(XEN) PCI add device fe:03.2
(XEN) PCI add device fe:03.4
(XEN) PCI add device fe:04.0
(XEN) PCI add device fe:04.1
(XEN) PCI add device fe:04.2
(XEN) PCI add device fe:04.3
(XEN) PCI add device fe:05.0
(XEN) PCI add device fe:05.1
(XEN) PCI add device fe:05.2
(XEN) PCI add device fe:05.3
(XEN) PCI add device fe:06.0
(XEN) PCI add device fe:06.1
(XEN) PCI add device fe:06.2
(XEN) PCI add device fe:06.3
PCI: Discovered peer bus ff

PCI: root bus ff: using default resources

PCI host bridge to bus 0000:ff

pci_bus 0000:ff: root bus resource [io  0x0000-0xffff]

pci_bus 0000:ff: root bus resource [mem 0x00000000-0xffffffffff]

pci 0000:ff:00.0: [8086:2c70] type 00 class 0x060000

pci 0000:ff:00.1: [8086:2d81] type 00 class 0x060000

pci 0000:ff:02.0: [8086:2d90] type 00 class 0x060000

pci 0000:ff:02.1: [8086:2d91] type 00 class 0x060000

pci 0000:ff:02.2: [8086:2d92] type 00 class 0x060000

pci 0000:ff:02.3: [8086:2d93] type 00 class 0x060000

pci 0000:ff:02.4: [8086:2d94] type 00 class 0x060000

pci 0000:ff:02.5: [8086:2d95] type 00 class 0x060000

pci 0000:ff:03.0: [8086:2d98] type 00 class 0x060000

pci 0000:ff:03.1: [8086:2d99] type 00 class 0x060000

pci 0000:ff:03.2: [8086:2d9a] type 00 class 0x060000

pci 0000:ff:03.4: [8086:2d9c] type 00 class 0x060000

pci 0000:ff:04.0: [8086:2da0] type 00 class 0x060000

pci 0000:ff:04.1: [8086:2da1] type 00 class 0x060000

pci 0000:ff:04.2: [8086:2da2] type 00 class 0x060000

pci 0000:ff:04.3: [8086:2da3] type 00 class 0x060000

pci 0000:ff:05.0: [8086:2da8] type 00 class 0x060000

pci 0000:ff:05.1: [8086:2da9] type 00 class 0x060000

pci 0000:ff:05.2: [8086:2daa] type 00 class 0x060000

pci 0000:ff:05.3: [8086:2dab] type 00 class 0x060000

pci 0000:ff:06.0: [8086:2db0] type 00 class 0x060000

pci 0000:ff:06.1: [8086:2db1] type 00 class 0x060000

pci 0000:ff:06.2: [8086:2db2] type 00 class 0x060000

pci 0000:ff:06.3: [8086:2db3] type 00 class 0x060000

(XEN) PCI add device ff:00.0
(XEN) PCI add device ff:00.1
(XEN) PCI add device ff:02.0
(XEN) PCI add device ff:02.1
(XEN) PCI add device ff:02.2
(XEN) PCI add device ff:02.3
(XEN) PCI add device ff:02.4
(XEN) PCI add device ff:02.5
(XEN) PCI add device ff:03.0
(XEN) PCI add device ff:03.1
(XEN) PCI add device ff:03.2
(XEN) PCI add device ff:03.4
(XEN) PCI add device ff:04.0
(XEN) PCI add device ff:04.1
(XEN) PCI add device ff:04.2
(XEN) PCI add device ff:04.3
(XEN) PCI add device ff:05.0
(XEN) PCI add device ff:05.1
(XEN) PCI add device ff:05.2
(XEN) PCI add device ff:05.3
(XEN) PCI add device ff:06.0
(XEN) PCI add device ff:06.1
(XEN) PCI add device ff:06.2
(XEN) PCI add device ff:06.3
PCI: pci_cache_line_size set to 64 bytes

reserve RAM buffer: 000000000009b000 - 000000000009ffff

reserve RAM buffer: 0000000040065000 - 0000000043ffffff

Switching to clocksource xen

pnp: PnP ACPI init

ACPI: bus type pnp registered

pnp 00:00: [bus 00-ff]

pnp 00:00: [io  0x0cf8-0x0cff]

pnp 00:00: [io  0x0000-0x03af window]

pnp 00:00: [io  0x03e0-0x0cf7 window]

pnp 00:00: [io  0x03b0-0x03bb window]

pnp 00:00: [io  0x03c0-0x03df window]

pnp 00:00: [io  0x0d00-0xffff window]

pnp 00:00: [mem 0x000a0000-0x000bffff window]

pnp 00:00: [mem 0x000d0000-0x000dffff window]

pnp 00:00: [mem 0xc0000000-0xdfffffff window]

pnp 00:00: [mem 0xf0000000-0xfed8ffff window]

pnp 00:00: Plug and Play ACPI device, IDs PNP0a08 PNP0a03 (active)

pnp 00:01: [mem 0xfbf00000-0xfbffffff]

pnp 00:01: [mem 0xfc000000-0xfcffffff]

pnp 00:01: [mem 0xfd000000-0xfdffffff]

pnp 00:01: [mem 0xfe000000-0xfebfffff]

pnp 00:01: [mem 0xfec8a000-0xfec8afff]

pnp 00:01: [mem 0xfed10000-0xfed10fff]

system 00:01: [mem 0xfbf00000-0xfbffffff] has been reserved

system 00:01: [mem 0xfc000000-0xfcffffff] has been reserved

system 00:01: [mem 0xfd000000-0xfdffffff] has been reserved

system 00:01: [mem 0xfe000000-0xfebfffff] has been reserved

system 00:01: [mem 0xfec8a000-0xfec8afff] could not be reserved

system 00:01: [mem 0xfed10000-0xfed10fff] has been reserved

system 00:01: Plug and Play ACPI device, IDs PNP0c01 (active)

pnp 00:02: [dma 4]

pnp 00:02: [io  0x0000-0x000f]

pnp 00:02: [io  0x0081-0x0083]

pnp 00:02: [io  0x0087]

pnp 00:02: [io  0x0089-0x008b]

pnp 00:02: [io  0x008f]

pnp 00:02: [io  0x00c0-0x00df]

pnp 00:02: Plug and Play ACPI device, IDs PNP0200 (active)

pnp 00:03: [io  0x0070-0x0071]
xen: registering gsi 8 triggering 1 polarity 0
pnp 00:03: [irq 8]
pnp 00:03: Plug and Play ACPI device, IDs PNP0b00 (active)
pnp 00:04: [io  0x0061]
pnp 00:04: Plug and Play ACPI device, IDs PNP0800 (active)
pnp 00:05: [io  0x00f0-0x00ff]
xen: registering gsi 13 triggering 1 polarity 0
pnp 00:05: [irq 13]
pnp 00:05: Plug and Play ACPI device, IDs PNP0c04 (active)
pnp 00:06: [io  0x0010-0x001f]
pnp 00:06: [io  0x0022-0x003f]
pnp 00:06: [io  0x0044-0x005f]
pnp 00:06: [io  0x0062-0x0063]
pnp 00:06: [io  0x0065-0x006f]
pnp 00:06: [io  0x0072-0x007f]
pnp 00:06: [io  0x0080]
pnp 00:06: [io  0x0084-0x0086]
pnp 00:06: [io  0x0088]
pnp 00:06: [io  0x008c-0x008e]
pnp 00:06: [io  0x0090-0x009f]
pnp 00:06: [io  0x00a2-0x00bf]
pnp 00:06: [io  0x00e0-0x00ef]
pnp 00:06: [io  0x04d0-0x04d1]
pnp 00:06: [io  0x0800-0x087f]
pnp 00:06: [io  0x0000-0xffffffffffffffff disabled]
pnp 00:06: [io  0x0500-0x057f]
pnp 00:06: [io  0x0000-0xffffffffffffffff disabled]
pnp 00:06: [mem 0xfed1c000-0xfed1ffff]
pnp 00:06: [mem 0xfed20000-0xfed3ffff]
pnp 00:06: [mem 0xfed40000-0xfed8ffff]
system 00:06: [io  0x04d0-0x04d1] has been reserved
system 00:06: [io  0x0800-0x087f] has been reserved
system 00:06: [io  0x0500-0x057f] has been reserved
system 00:06: [mem 0xfed1c000-0xfed1ffff] has been reserved
system 00:06: [mem 0xfed20000-0xfed3ffff] has been reserved
system 00:06: [mem 0xfed40000-0xfed8ffff] has been reserved
system 00:06: Plug and Play ACPI device, IDs PNP0c02 (active)
pnp 00:07: [io  0x0ca2]
pnp 00:07: [io  0x0ca3]
pnp 00:07: Plug and Play ACPI device, IDs IPI0001 (active)
pnp 00:08: [mem 0xfed00000-0xfed003ff]
pnp 00:08: Plug and Play ACPI device, IDs PNP0103 (active)
pnp 00:09: [io  0x0060]
pnp 00:09: [io  0x0064]
pnp 00:09: [mem 0xfec00000-0xfec00fff]
pnp 00:09: [mem 0xfee00000-0xfee00fff]
system 00:09: [mem 0xfec00000-0xfec00fff] could not be reserved
system 00:09: [mem 0xfee00000-0xfee00fff] has been reserved
system 00:09: Plug and Play ACPI device, IDs PNP0c02 (active)
pnp 00:0a: [mem 0xe0000000-0xefffffff]
system 00:0a: [mem 0xe0000000-0xefffffff] has been reserved
system 00:0a: Plug and Play ACPI device, IDs PNP0c02 (active)
pnp 00:0b: [mem 0x00000000-0x0009ffff]
pnp 00:0b: [mem 0x000c0000-0x000cffff]
pnp 00:0b: [mem 0x000e0000-0x000fffff]
pnp 00:0b: [mem 0x00100000-0xbfffffff]
pnp 00:0b: [mem 0xfed90000-0xffffffff]
system 00:0b: [mem 0x00000000-0x0009ffff] could not be reserved
system 00:0b: [mem 0x000c0000-0x000cffff] could not be reserved
system 00:0b: [mem 0x000e0000-0x000fffff] could not be reserved
system 00:0b: [mem 0x00100000-0xbfffffff] could not be reserved
system 00:0b: [mem 0xfed90000-0xffffffff] could not be reserved
system 00:0b: Plug and Play ACPI device, IDs PNP0c01 (active)
pnp: PnP ACPI: found 12 devices
ACPI: ACPI bus type pnp unregistered
PM-Timer failed consistency check  (0x0xffffff) - aborting.
pci 0000:00:01.0: PCI bridge to [bus 01-02]
pci 0000:00:01.0:   bridge window [io  0xc000-0xcfff]
pci 0000:00:01.0:   bridge window [mem 0xfbb00000-0xfbcfffff]
pci 0000:00:03.0: PCI bridge to [bus 03-04]
pci 0000:00:03.0:   bridge window [io  0xd000-0xdfff]
pci 0000:00:03.0:   bridge window [mem 0xfbd00000-0xfbdfffff]
pci 0000:00:03.0:   bridge window [mem 0xf9c00000-0xf9ffffff 64bit pref]
pci 0000:00:05.0: PCI bridge to [bus 05-05]
pci 0000:00:07.0: PCI bridge to [bus 06-06]
pci 0000:00:1e.0: PCI bridge to [bus 07-07]
pci 0000:00:1e.0:   bridge window [io  0xe000-0xefff]
pci 0000:00:1e.0:   bridge window [mem 0xfaf00000-0xfb7fffff]
pci 0000:00:1e.0: setting latency timer to 64
pci_bus 0000:00: resource 4 [io  0x0000-0x03af]
pci_bus 0000:00: resource 5 [io  0x03e0-0x0cf7]
pci_bus 0000:00: resource 6 [io  0x03b0-0x03bb]
pci_bus 0000:00: resource 7 [io  0x03c0-0x03df]
pci_bus 0000:00: resource 8 [io  0x0d00-0xffff]
pci_bus 0000:00: resource 9 [mem 0x000a0000-0x000bffff]
pci_bus 0000:00: resource 10 [mem 0x000d0000-0x000dffff]
pci_bus 0000:00: resource 11 [mem 0xc0000000-0xdfffffff]
pci_bus 0000:00: resource 12 [mem 0xf0000000-0xfed8ffff]
pci_bus 0000:01: resource 0 [io  0xc000-0xcfff]
pci_bus 0000:01: resource 1 [mem 0xfbb00000-0xfbcfffff]
pci_bus 0000:03: resource 0 [io  0xd000-0xdfff]
pci_bus 0000:03: resource 1 [mem 0xfbd00000-0xfbdfffff]
pci_bus 0000:03: resource 2 [mem 0xf9c00000-0xf9ffffff 64bit pref]
pci_bus 0000:07: resource 0 [io  0xe000-0xefff]
pci_bus 0000:07: resource 1 [mem 0xfaf00000-0xfb7fffff]
pci_bus 0000:07: resource 4 [io  0x0000-0x03af]
pci_bus 0000:07: resource 5 [io  0x03e0-0x0cf7]
pci_bus 0000:07: resource 6 [io  0x03b0-0x03bb]
pci_bus 0000:07: resource 7 [io  0x03c0-0x03df]
pci_bus 0000:07: resource 8 [io  0x0d00-0xffff]
pci_bus 0000:07: resource 9 [mem 0x000a0000-0x000bffff]
pci_bus 0000:07: resource 10 [mem 0x000d0000-0x000dffff]
pci_bus 0000:07: resource 11 [mem 0xc0000000-0xdfffffff]
pci_bus 0000:07: resource 12 [mem 0xf0000000-0xfed8ffff]
pci_bus 0000:fe: resource 4 [io  0x0000-0xffff]
pci_bus 0000:fe: resource 5 [mem 0x00000000-0xffffffffff]
pci_bus 0000:ff: resource 4 [io  0x0000-0xffff]
pci_bus 0000:ff: resource 5 [mem 0x00000000-0xffffffffff]
NET: Registered protocol family 2
IP route cache hash table entries: 32768 (order: 5, 131072 bytes)
TCP established hash table entries: 131072 (order: 8, 1048576 bytes)
TCP bind hash table entries: 65536 (order: 7, 524288 bytes)
TCP: Hash tables configured (established 131072 bind 65536)
TCP: reno registered
UDP hash table entries: 512 (order: 2, 16384 bytes)
UDP-Lite hash table entries: 512 (order: 2, 16384 bytes)
NET: Registered protocol family 1
RPC: Registered named UNIX socket transport module.
RPC: Registered udp transport module.
RPC: Registered tcp transport module.
RPC: Registered tcp NFSv4.1 backchannel transport module.
xen: registering gsi 23 triggering 0 polarity 1
xen: --> pirq=23 -> irq=23 (gsi=23)
xen: registering gsi 19 triggering 0 polarity 1
xen: --> pirq=19 -> irq=19 (gsi=19)
xen: registering gsi 18 triggering 0 polarity 1
xen: --> pirq=18 -> irq=18 (gsi=18)
xen: registering gsi 23 triggering 0 polarity 1
Already setup the GSI :23
pci 0000:07:04.0: Boot video device
PCI: CLS 256 bytes, default 64
Trying to unpack rootfs image as initramfs...
Freeing initrd memory: 2960k freed
microcode: CPU0 sig=0x206c2, pf=0x1, revision=0x14
microcode: Microcode Update Driver: v2.00
<tigran@aivazian.fsnet.co.uk>, Peter Oruba
highmem bounce pool size: 64 pages
NFS: Registering the id_resolver key type
msgmni has been set to 1501
Block layer SCSI generic (bsg) driver version 0.4 loaded (major 253)
io scheduler noop registered (default)
io scheduler deadline registered
io scheduler cfq registered
ioapic: probe of 0000:00:13.0 failed with error -22
ioatdma: Intel(R) QuickData Technology Driver 4.00
xen: registering gsi 43 triggering 0 polarity 1
xen: --> pirq=43 -> irq=43 (gsi=43)
(XEN) ../physdev.c:171: dom0: wrong map_pirq type 3
xen: registering gsi 44 triggering 0 polarity 1
xen: --> pirq=44 -> irq=44 (gsi=44)
xen: registering gsi 45 triggering 0 polarity 1
xen: --> pirq=45 -> irq=45 (gsi=45)
xen: registering gsi 46 triggering 0 polarity 1
xen: --> pirq=46 -> irq=46 (gsi=46)
xen: registering gsi 43 triggering 0 polarity 1
Already setup the GSI :43
xen: registering gsi 44 triggering 0 polarity 1
Already setup the GSI :44
xen: registering gsi 45 triggering 0 polarity 1
Already setup the GSI :45
xen: registering gsi 46 triggering 0 polarity 1
Already setup the GSI :46
Event-channel device installed.
xen-pciback: backend is vpci
Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled
serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
brd: module loaded
loop: module loaded
igb: Intel(R) Gigabit Ethernet Network Driver - version 3.2.10-k
igb: Copyright (c) 2007-2012 Intel Corporation.
xen: registering gsi 17 triggering 0 polarity 1
xen: --> pirq=17 -> irq=17 (gsi=17)
igb 0000:01:00.0: Intel(R) Gigabit Ethernet Network Connection
igb 0000:01:00.0: eth0: (PCIe:2.5Gb/s:Width x4) 00:26:6c:ff:b3:8c
igb 0000:01:00.0: eth0: PBA No: 82576B-001
igb 0000:01:00.0: Using MSI-X interrupts. 1 rx queue(s), 1 tx queue(s)
xen: registering gsi 16 triggering 0 polarity 1
xen: --> pirq=16 -> irq=16 (gsi=16)
igb 0000:01:00.1: Intel(R) Gigabit Ethernet Network Connection
igb 0000:01:00.1: eth1: (PCIe:2.5Gb/s:Width x4) 00:26:6c:ff:b3:8d
igb 0000:01:00.1: eth1: PBA No: 82576B-001
igb 0000:01:00.1: Using MSI-X interrupts. 1 rx queue(s), 1 tx queue(s)
ixgbe: Intel(R) 10 Gigabit PCI Express Network Driver - version 3.8.21-k
ixgbe: Copyright (c) 1999-2012 Intel Corporation.
xen: registering gsi 24 triggering 0 polarity 1
xen: --> pirq=24 -> irq=24 (gsi=24)
ixgbe 0000:03:00.0: Multiqueue Disabled: Rx Queue count = 1, Tx Queue count = 1
ixgbe 0000:03:00.0: (PCI Express:5.0GT/s:Width x8) 00:8c:fa:01:84:6a
ixgbe 0000:03:00.0: MAC: 2, PHY: 1, PBA No: FFFFFF-0FF
ixgbe 0000:03:00.0: Intel(R) 10 Gigabit Network Connection
xen: registering gsi 34 triggering 0 polarity 1
xen: --> pirq=34 -> irq=34 (gsi=34)
ixgbe 0000:03:00.1: Multiqueue Disabled: Rx Queue count = 1, Tx Queue count = 1
ixgbe 0000:03:00.1: (PCI Express:5.0GT/s:Width x8) 00:8c:fa:01:84:6b
ixgbe 0000:03:00.1: MAC: 2, PHY: 1, PBA No: FFFFFF-0FF
ixgbe 0000:03:00.1: Intel(R) 10 Gigabit Network Connection
md: raid0 personality registered for level 0
md: raid1 personality registered for level 1
device-mapper: ioctl: 4.22.0-ioctl (2011-10-19) initialised: dm-devel@redhat.com
dcdbas dcdbas: Dell Systems Management Base Driver (version 5.6.0-3.2)
ip_tables: (C) 2000-2006 Netfilter Core Team
TCP: cubic registered
NET: Registered protocol family 10
NET: Registered protocol family 17
8021q: 802.1Q VLAN Support v1.8
Using IPI No-Shortcut mode
console [netcon0] enabled
netconsole: network logging started
drivers/rtc/hctosys.c: unable to open rtc device (rtc0)
BIOS EDD facility v0.16 2004-Jun-25, 0 devices found
EDD information not available.
ADDRCONF(NETDEV_UP): eth0: link is not ready
8021q: adding VLAN 0 to HW filter on device eth0
igb: eth0 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX
ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
Sending DHCP requests .., OK
Freeing unused kernel memory: 344k freed
Using fallback suid method
Using fallback suid method
INIT: version 2.88 booting
Using makefile-style concurrent boot in runlevel S.
.udev/ already exists on the static /dev! ...  [33m(warning). [39;49m
Starting the hotplug events dispatcher: udevd.
Synthesizing the initial hotplug events...done.
Waiting for /dev to be fully populated...input: Power Button as
/devices/LNXSYSTM:00/device:00/PNP0C0C:00/input/input0
ACPI: Power Button [PWRB]
input: Power Button as /devices/LNXSYSTM:00/LNXPWRBN:00/input/input1
ACPI: Power Button [PWRF]
rtc_cmos 00:03: RTC can wake from S4
rtc_cmos 00:03: rtc core: registered rtc_cmos as rtc0
rtc0: alarms up to one month, y3k, 114 bytes nvram
udev[1176]: renamed network interface eth1 to eth4
udevd-work[1175]: error changing net interface name eth0 to eth5:
Device or resource busy
udev[1177]: renamed network interface eth2 to eth6
udev[1178]: renamed network interface eth3 to eth7
done.
Setting preliminary keymap...done.
Activating swap...done.
Cleaning up ifupdown....
Setting up networking....
Loading kernel modules...udevd-work[1168]: kernel-provided name
'interfaces' and NAME= 'etherd/interfaces' disagree, please use
SYMLINK+= or change the kernel to provide the proper name
udevd-work[1166]: kernel-provided name 'err' and NAME= 'etherd/err'
disagree, please use SYMLINK+= or change the kernel to provide the
proper name
udevd-work[1167]: kernel-provided name 'discover' and NAME=
'etherd/discover' disagree, please use SYMLINK+= or change the kernel
to provide the proper name
udevd-work[1170]: kernel-provided name 'flush' and NAME=
'etherd/flush' disagree, please use SYMLINK+= or change the kernel to
provide the proper name
udevd-work[1169]: kernel-provided name 'revalidate' and NAME=
'etherd/revalidate' disagree, please use SYMLINK+= or change the
kernel to provide the proper name
Mounting local filesystems...done.
Activating swapfile swap...done.
Cleaning up temporary files....
Mounted debugfs on /sys/kernel/debug.
Cleaning up temporary files....
Setting console screen modes and fonts.
cannot (un)set powersave mode
 [9;30] [14;30]Setting up console font and keymap...done.
.
Mounting network filesystems:.
 [31mfailed. [39;49m
rm: cannot remove `/var/lib/urandom/random-seed': Read-only file system
startpar: service(s) returned failure: udev-mtab ...  [31mfailed! [39;49m
INIT: Entering runlevel: 2
Using makefile-style concurrent boot in runlevel 2.
Debugfs is already mounted on /sys/kernel/debug; nothing to do.
Starting enhanced syslogd: rsyslogd.
Starting ACPI services....
Starting periodic command scheduler: cron.
Starting OpenBSD Secure Shell server: sshd.
Starting xenstored...Could not open tracefile: No such file or directory
Setting domain 0 name...
Starting xenconsoled...



-- 
William

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Sep 23 15:12:17 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 23 Sep 2012 15: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 1TFnqQ-0007k7-VF; Sun, 23 Sep 2012 15:11:42 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wdauchy@gmail.com>) id 1TFnqO-0007k2-JQ
	for xen-devel@lists.xensource.com; Sun, 23 Sep 2012 15:11:41 +0000
Received: from [85.158.143.99:59502] by server-1.bemta-4.messagelabs.com id
	A2/9F-05684-BA62F505; Sun, 23 Sep 2012 15:11:39 +0000
X-Env-Sender: wdauchy@gmail.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1348413094!26152540!1
X-Originating-IP: [209.85.160.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-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1168 invoked from network); 23 Sep 2012 15:11:36 -0000
Received: from mail-pb0-f43.google.com (HELO mail-pb0-f43.google.com)
	(209.85.160.43)
	by server-4.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Sep 2012 15:11:36 -0000
Received: by pbbrq2 with SMTP id rq2so13729817pbb.30
	for <xen-devel@lists.xensource.com>;
	Sun, 23 Sep 2012 08:11:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to
	:cc:content-type:content-transfer-encoding;
	bh=56VQBKH4qFV7NEVSJRn+UdL9jb40RLi2Jcl76mMTc4s=;
	b=rVtNZDKDlLQIjqHURIrQZtZqBGWZmjVzmSGfCxgH2it35IMesnTUQ58QQU5ku+UQ0m
	FYKcuuh/m6RIBOS4TuURAAGwN1HV1mzkDgTwSeiBXnXtObVqSM6Y1qFMORdppMmfRXB2
	nB3qqYfMPTePtdCIeKk61mBPI8hQk3NxsZ0brADXrh/WjddfDHZY9Z02jBdSeSfOu+PZ
	rQnol9LdnT/Rp+h+elES/yR0mzeD2h1DEM7jWHJO/GE497tof/3PQfionuhA0uSI+HcU
	kqlbs2XrgQmVjuWluFqxM16tAPuMQXfMTYqxMcTfE7vWIBG3Tzj5LxhA9kytyiHe7YR1
	Bqcg==
Received: by 10.66.74.100 with SMTP id s4mr26469097pav.27.1348413093666; Sun,
	23 Sep 2012 08:11:33 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.68.135.42 with HTTP; Sun, 23 Sep 2012 08:11:13 -0700 (PDT)
In-Reply-To: <20120920212823.GE27312@konrad-lan.dumpdata.com>
References: <CAJ75kXZm-BqWdL2O41XkSE1VCdd4ruW=+CqDmR1b3=701RnXmw@mail.gmail.com>
	<20120918133650.GC12053@phenom.dumpdata.com>
	<CAJ75kXZEaCj4Jqs_qm46d7U-s1C2hkAONs8c5Audrw2c3X=nBA@mail.gmail.com>
	<20120920134851.GB1998@localhost.localdomain>
	<CAJ75kXZ0depUJF_h0yok-r4aL0TBGnqTpW_PKT4Q7P1_6R4X2A@mail.gmail.com>
	<20120920162337.GB8912@reaktio.net>
	<CAJ75kXaXbitBvosYp8Sv_548XbvdxU=M_NSSHTb_5d56=-n4nA@mail.gmail.com>
	<20120920163525.GC8912@reaktio.net>
	<CAJ75kXZnb82GnssNWxyGMHjTYiRQCRsNdPeYdEb-tsvkshpfEg@mail.gmail.com>
	<20120920212823.GE27312@konrad-lan.dumpdata.com>
From: William Dauchy <wdauchy@gmail.com>
Date: Sun, 23 Sep 2012 17:11:13 +0200
Message-ID: <CAJ75kXZjuUgQfc=8tz2F_UEwnQWRD7AhyMOM1L+DSMFzoss9Dw@mail.gmail.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] Error getting mfn
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Sep 20, 2012 at 11:28 PM, Konrad Rzeszutek Wilk
<konrad.wilk@oracle.com> wrote:
> Ah. OK. so lets deal with one issue at hand. The CONFIG_NUMA - you said
> you applied I posted for it some time ago? Is it this one?
> http://lkml.indiana.edu/hypermail/linux/kernel/1205.3/03619.html

yes; and applied on my tests.

> For the non-NUMA case - can you try to compile a kernel without
> NUMA enabled and also include 'earlyprintk=xen' on your Linux command
> line? That should give me a good approximation of what/where
> it is being hit.

Here is the log without NUMA enabled.

(XEN) Xen version 4.1.3 (package@) (gcc version 4.4.5 (Debian 4.4.5-8)
) Mon Sep 17 15:01:52 UTC 2012
(XEN) Latest ChangeSet: Thu Aug 09 16:47:30 2012 +0100 23334:ce7195d2b80e
(XEN) Console output is synchronous.
(XEN) Bootloader: COM32 Multiboot loader v0.2
(XEN) Command line: console=com2 debug sync_console dom0_max_vcpus=1
dom0_mem=1024M,max:1024M loglvl=all guest_loglvl=all
(XEN) Video information:
(XEN)  VGA is text mode 80x25, font 8x16
(XEN)  VBE/DDC methods: none; EDID transfer time: 1 seconds
(XEN)  EDID info not retrieved because no DDC retrieval method detected
(XEN) Disc information:
(XEN)  Found 0 MBR signatures
(XEN)  Found 0 EDD information structures
(XEN) Xen-e820 RAM map:
(XEN)  0000000000000000 - 000000000009b400 (usable)
(XEN)  000000000009b400 - 00000000000a0000 (reserved)
(XEN)  00000000000e0000 - 0000000000100000 (reserved)
(XEN)  0000000000100000 - 00000000bf730000 (usable)
(XEN)  00000000bf730000 - 00000000bf73e000 (ACPI data)
(XEN)  00000000bf73e000 - 00000000bf7a0000 (ACPI NVS)
(XEN)  00000000bf7a0000 - 00000000bf7b0000 (reserved)
(XEN)  00000000bf7bc000 - 00000000c0000000 (reserved)
(XEN)  00000000e0000000 - 00000000f0000000 (reserved)
(XEN)  00000000fee00000 - 00000000fee01000 (reserved)
(XEN)  00000000ffa00000 - 0000000100000000 (reserved)
(XEN)  0000000100000000 - 0000000c40000000 (usable)
(XEN) ACPI: RSDP 000FA6F0, 0024 (r2 ACPIAM)
(XEN) ACPI: XSDT BF730100, 006C (r1 122311 XSDT1136 20111223 MSFT       97)
(XEN) ACPI: FACP BF730290, 00F4 (r4 122311 FACP1136 20111223 MSFT       97)
(XEN) ACPI: DSDT BF730540, 48F7 (r2  5442B 5442B166      166 INTL 20051117)
(XEN) ACPI: FACS BF73E000, 0040
(XEN) ACPI: APIC BF730390, 011E (r2 122311 APIC1136 20111223 MSFT       97)
(XEN) ACPI: SPCR BF7304B0, 0050 (r1 122311 SPCR1136 20111223 MSFT       97)
(XEN) ACPI: MCFG BF730500, 003C (r1 122311 OEMMCFG  20111223 MSFT       97)
(XEN) ACPI: OEMB BF73E040, 0082 (r1 122311 OEMB1136 20111223 MSFT       97)
(XEN) ACPI: SRAT BF73A540, 0250 (r2 122311 OEMSRAT         1 INTL        1)
(XEN) ACPI: HPET BF73A790, 0038 (r1 122311 OEMHPET  20111223 MSFT       97)
(XEN) ACPI: DMAR BF73E0D0, 00D8 (r1    AMI  OEMDMAR        1 MSFT       97)
(XEN) ACPI: SSDT BF7439A0, 0363 (r1 DpgPmm    CpuPm       12 INTL 20051117)
(XEN) System RAM: 49142MB (50322220kB)
(XEN) SRAT: PXM 0 -> APIC 0 -> Node 0
(XEN) SRAT: PXM 0 -> APIC 2 -> Node 0
(XEN) SRAT: PXM 0 -> APIC 4 -> Node 0
(XEN) SRAT: PXM 0 -> APIC 16 -> Node 0
(XEN) SRAT: PXM 0 -> APIC 18 -> Node 0
(XEN) SRAT: PXM 0 -> APIC 20 -> Node 0
(XEN) SRAT: PXM 0 -> APIC 1 -> Node 0
(XEN) SRAT: PXM 0 -> APIC 3 -> Node 0
(XEN) SRAT: PXM 0 -> APIC 5 -> Node 0
(XEN) SRAT: PXM 0 -> APIC 17 -> Node 0
(XEN) SRAT: PXM 0 -> APIC 19 -> Node 0
(XEN) SRAT: PXM 0 -> APIC 21 -> Node 0
(XEN) SRAT: PXM 1 -> APIC 32 -> Node 1
(XEN) SRAT: PXM 1 -> APIC 34 -> Node 1
(XEN) SRAT: PXM 1 -> APIC 36 -> Node 1
(XEN) SRAT: PXM 1 -> APIC 48 -> Node 1
(XEN) SRAT: PXM 1 -> APIC 50 -> Node 1
(XEN) SRAT: PXM 1 -> APIC 52 -> Node 1
(XEN) SRAT: PXM 1 -> APIC 33 -> Node 1
(XEN) SRAT: PXM 1 -> APIC 35 -> Node 1
(XEN) SRAT: PXM 1 -> APIC 37 -> Node 1
(XEN) SRAT: PXM 1 -> APIC 49 -> Node 1
(XEN) SRAT: PXM 1 -> APIC 51 -> Node 1
(XEN) SRAT: PXM 1 -> APIC 53 -> Node 1
(XEN) SRAT: Node 0 PXM 0 0-a0000
(XEN) SRAT: Node 0 PXM 0 100000-c0000000
(XEN) SRAT: Node 0 PXM 0 100000000-640000000
(XEN) SRAT: Node 1 PXM 1 640000000-c40000000
(XEN) NUMA: Allocated memnodemap from c3f7c5000 - c3f7d2000
(XEN) NUMA: Using 8 for the hash shift.
(XEN) Domain heap initialised DMA width 32 bits
(XEN) found SMP MP-table at 000ff780
(XEN) DMI present.
(XEN) Using APIC driver default
(XEN) ACPI: PM-Timer IO Port: 0x808
(XEN) ACPI: ACPI SLEEP INFO: pm1x_cnt[804,0], pm1x_evt[800,0]
(XEN) ACPI:                  wakeup_vec[bf73e00c], vec_size[20]
(XEN) ACPI: Local APIC address 0xfee00000
(XEN) ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled)
(XEN) Processor #0 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x02] lapic_id[0x02] enabled)
(XEN) Processor #2 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x03] lapic_id[0x04] enabled)
(XEN) Processor #4 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x04] lapic_id[0x10] enabled)
(XEN) Processor #16 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x05] lapic_id[0x12] enabled)
(XEN) Processor #18 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x06] lapic_id[0x14] enabled)
(XEN) Processor #20 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x07] lapic_id[0x20] enabled)
(XEN) Processor #32 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x08] lapic_id[0x22] enabled)
(XEN) Processor #34 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x09] lapic_id[0x24] enabled)
(XEN) Processor #36 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x0a] lapic_id[0x30] enabled)
(XEN) Processor #48 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x0b] lapic_id[0x32] enabled)
(XEN) Processor #50 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x0c] lapic_id[0x34] enabled)
(XEN) Processor #52 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x0d] lapic_id[0x01] enabled)
(XEN) Processor #1 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x0e] lapic_id[0x03] enabled)
(XEN) Processor #3 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x0f] lapic_id[0x05] enabled)
(XEN) Processor #5 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x10] lapic_id[0x11] enabled)
(XEN) Processor #17 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x11] lapic_id[0x13] enabled)
(XEN) Processor #19 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x12] lapic_id[0x15] enabled)
(XEN) Processor #21 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x13] lapic_id[0x21] enabled)
(XEN) Processor #33 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x14] lapic_id[0x23] enabled)
(XEN) Processor #35 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x15] lapic_id[0x25] enabled)
(XEN) Processor #37 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x16] lapic_id[0x31] enabled)
(XEN) Processor #49 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x17] lapic_id[0x33] enabled)
(XEN) Processor #51 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x18] lapic_id[0x35] enabled)
(XEN) Processor #53 6:12 APIC version 21
(XEN) ACPI: LAPIC_NMI (acpi_id[0xff] dfl dfl lint[0x1])
(XEN) Overriding APIC driver with bigsmp
(XEN) ACPI: IOAPIC (id[0x06] address[0xfec00000] gsi_base[0])
(XEN) IOAPIC[0]: apic_id 6, version 32, address 0xfec00000, GSI 0-23
(XEN) ACPI: IOAPIC (id[0x07] address[0xfec8a000] gsi_base[24])
(XEN) IOAPIC[1]: apic_id 7, version 32, address 0xfec8a000, GSI 24-47
(XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
(XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
(XEN) ACPI: IRQ0 used by override.
(XEN) ACPI: IRQ2 used by override.
(XEN) ACPI: IRQ9 used by override.
(XEN) Enabling APIC mode:  Phys.  Using 2 I/O APICs
(XEN) ACPI: HPET id: 0x8086a301 base: 0xfed00000
(XEN) PCI: MCFG configuration 0: base e0000000 segment 0 buses 0 - 255
(XEN) PCI: MCFG area at e0000000 reserved in E820
(XEN) Table is not found!
(XEN) Using ACPI (MADT) for SMP configuration information
(XEN) IRQ limits: 48 GSI, 4576 MSI/MSI-X
(XEN) Using scheduler: SMP Credit Scheduler (credit)
(XEN) Detected 2266.815 MHz processor.
(XEN) Initing memory sharing.
(XEN) mce_intel.c:1162: MCA Capability: BCAST 1 SER 0 CMCI 1 firstbank
0 extended MCE MSR 0
(XEN) Intel machine check reporting enabled
(XEN) Intel VT-d supported page sizes: 4kB.
(XEN) Intel VT-d Snoop Control enabled.
(XEN) Intel VT-d Dom0 DMA Passthrough not enabled.
(XEN) Intel VT-d Queued Invalidation enabled.
(XEN) Intel VT-d Interrupt Remapping not enabled.
(XEN) Intel VT-d Shared EPT tables not enabled.
(XEN) I/O virtualisation enabled
(XEN)  - Dom0 mode: Relaxed
(XEN) Enabled directed EOI with ioapic_ack_old on!
(XEN) ENABLING IO-APIC IRQs
(XEN)  -> Using old ACK method
(XEN) ..TIMER: vector=0xF0 apic1=0 pin1=2 apic2=-1 pin2=-1
(XEN) Platform timer is 14.318MHz HPET
(XEN) Defaulting to alternative key handling; send 'A' to switch to normal mode.
(XEN) Allocated console ring of 256 KiB.
(XEN) VMX: Supported advanced features:
(XEN)  - APIC MMIO access virtualisation
(XEN)  - APIC TPR shadow
(XEN)  - Extended Page Tables (EPT)
(XEN)  - Virtual-Processor Identifiers (VPID)
(XEN)  - Virtual NMI
(XEN)  - MSR direct-access bitmap
(XEN)  - Unrestricted Guest
(XEN) HVM: ASIDs enabled.
(XEN) HVM: VMX enabled
(XEN) HVM: Hardware Assisted Paging (HAP) detected
(XEN) HVM: HAP page sizes: 4kB, 2MB, 1GB
(XEN) Brought up 24 CPUs
(XEN) ACPI sleep modes: S3
(XEN) mcheck_poll: Machine check polling timer started.
(XEN) *** LOADING DOMAIN 0 ***
(XEN)  Xen  kernel: 64-bit, lsb, compat32
(XEN)  Dom0 kernel: 32-bit, PAE, lsb, paddr 0x1000000 -> 0x17ce000
(XEN) PHYSICAL MEMORY ARRANGEMENT:
(XEN)  Dom0 alloc.:   0000000c20000000->0000000c22000000 (253212 pages
to be allocated)
(XEN)  Init. ramdisk: 0000000c3fd1c000->0000000c3ffff200
(XEN) VIRTUAL MEMORY ARRANGEMENT:
(XEN)  Loaded kernel: 00000000c1000000->00000000c17ce000
(XEN)  Init. ramdisk: 00000000c17ce000->00000000c1ab1200
(XEN)  Phys-Mach map: 00000000c1ab2000->00000000c1bb2000
(XEN)  Start info:    00000000c1bb2000->00000000c1bb24b4
(XEN)  Page tables:   00000000c1bb3000->00000000c1bc9000
(XEN)  Boot stack:    00000000c1bc9000->00000000c1bca000
(XEN)  TOTAL:         00000000c0000000->00000000c2000000
(XEN)  ENTRY ADDRESS: 00000000c14eb000
(XEN) Dom0 has maximum 1 VCPUs
(XEN) Scrubbing Free RAM:
..........................................................................................................................................................................................................................................................................................................................................................................................................................................................................................done.
(XEN) Xen trace buffers: disabled
(XEN) Std. Loglevel: All
(XEN) Guest Loglevel: All
(XEN) **********************************************
(XEN) ******* WARNING: CONSOLE OUTPUT IS SYNCHRONOUS
(XEN) ******* This option is intended to aid debugging of Xen by ensuring
(XEN) ******* that all output is synchronously delivered on the serial line.
(XEN) ******* However it can introduce SIGNIFICANT latencies and affect
(XEN) ******* timekeeping. It is NOT recommended for production use!
(XEN) **********************************************
(XEN) 3... 2... 1...
(XEN) *** Serial input -> DOM0 (type 'CTRL-a' three times to switch
input to Xen)
(XEN) Freed 212kB init memory.
mapping kernel into physical memory
Xen: setup ISA identity maps
about to get started...
Reserving virtual address space above 0xfcc00000
Linux version 3.4.11 (gcc version 4.4.5 (Debian 4.4.5-8) ) #18 SMP Sun
Sep 23 14:32:16 UTC 2012
KERNEL supported cpus:
  Intel GenuineIntel
Freeing  9b-100 pfn range: 101 pages freed
1-1 mapping on 9b->100
1-1 mapping on bf730->100000
Released 101 pages of unused memory
Set 264501 page(s) to 1-1 mapping
BIOS-provided physical RAM map:
 Xen: 0000000000000000 - 000000000009b000 (usable)
 Xen: 000000000009b400 - 0000000000100000 (reserved)
 Xen: 0000000000100000 - 0000000040065000 (usable)
 Xen: 0000000040065000 - 00000000bf730000 (unusable)
 Xen: 00000000bf730000 - 00000000bf73e000 (ACPI data)
 Xen: 00000000bf73e000 - 00000000bf7a0000 (ACPI NVS)
 Xen: 00000000bf7a0000 - 00000000bf7b0000 (reserved)
 Xen: 00000000bf7bc000 - 00000000c0000000 (reserved)
 Xen: 00000000e0000000 - 00000000f0000000 (reserved)
 Xen: 00000000fec00000 - 00000000fec01000 (reserved)
 Xen: 00000000fec8a000 - 00000000fec8b000 (reserved)
 Xen: 00000000fee00000 - 00000000fee01000 (reserved)
 Xen: 00000000ffa00000 - 0000000100000000 (reserved)
 Xen: 0000000100000000 - 0000000c40000000 (unusable)
bootconsole [xenboot0] enabled
NX (Execute Disable) protection: active
DMI present.
DMI: Dell       C6100           /0D61XP, BIOS 1.66 12/23/2011
e820 update range: 0000000000000000 - 0000000000010000 (usable) ==> (reserved)
e820 remove range: 00000000000a0000 - 0000000000100000 (usable)
last_pfn = 0x40065 max_arch_pfn = 0x1000000
initial memory mapped : 0 - 027ff000
Base memory trampoline at [c009a000] 9a000 size 4096
init_memory_mapping: 0000000000000000-00000000345fe000
 0000000000 - 00345fe000 page 4k
kernel direct mapping tables up to 345fe000 @ 2658000-27ff000
(XEN) mm.c:908:d0 Error getting mfn 2009b (pfn 5555555555555555) from
L1 entry 000000002009b023 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 000000002009b023
(XEN) mm.c:908:d0 Error getting mfn 2009c (pfn 5555555555555555) from
L1 entry 000000002009c023 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 000000002009c023
(XEN) mm.c:908:d0 Error getting mfn 2009d (pfn 5555555555555555) from
L1 entry 000000002009d023 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 000000002009d023
(XEN) mm.c:908:d0 Error getting mfn 2009e (pfn 5555555555555555) from
L1 entry 000000002009e023 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 000000002009e023
(XEN) mm.c:908:d0 Error getting mfn 2009f (pfn 5555555555555555) from
L1 entry 000000002009f023 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 000000002009f023
xen: setting RW the range 27e9000 - 27ff000
RAMDISK: 017ce000 - 01ab2000
ACPI: RSDP 000fa6f0 00024 (v02 ACPIAM)
ACPI: XSDT bf730100 0006C (v01 122311 XSDT1136 20111223 MSFT 00000097)
ACPI: FACP bf730290 000F4 (v04 122311 FACP1136 20111223 MSFT 00000097)
ACPI: DSDT bf730540 048F7 (v02  5442B 5442B166 00000166 INTL 20051117)
ACPI: FACS bf73e000 00040
ACPI: APIC bf730390 0011E (v02 122311 APIC1136 20111223 MSFT 00000097)
ACPI: SPCR bf7304b0 00050 (v01 122311 SPCR1136 20111223 MSFT 00000097)
ACPI: MCFG bf730500 0003C (v01 122311 OEMMCFG  20111223 MSFT 00000097)
ACPI: OEMB bf73e040 00082 (v01 122311 OEMB1136 20111223 MSFT 00000097)
ACPI: SRAT bf73a540 00250 (v02 122311 OEMSRAT  00000001 INTL 00000001)
ACPI: HPET bf73a790 00038 (v01 122311 OEMHPET  20111223 MSFT 00000097)
ACPI: XMAR bf73e0d0 000D8 (v01    AMI  OEMDMAR 00000001 MSFT 00000097)
ACPI: SSDT bf7439a0 00363 (v01 DpgPmm    CpuPm 00000012 INTL 20051117)
ACPI: Local APIC address 0xfee00000
186MB HIGHMEM available.
837MB LOWMEM available.
  mapped low ram: 0 - 345fe000
  low ram: 0 - 345fe000
Zone PFN ranges:
  DMA      0x00000010 -> 0x00001000
  Normal   0x00001000 -> 0x000345fe
  HighMem  0x000345fe -> 0x00040065
Movable zone start PFN for each node
Early memory PFN ranges
    0: 0x00000010 -> 0x0000009b
    0: 0x00000100 -> 0x00040065
On node 0 totalpages: 262128
  DMA zone: 32 pages used for memmap
  DMA zone: 0 pages reserved
  DMA zone: 3947 pages, LIFO batch:0
  Normal zone: 1644 pages used for memmap
  Normal zone: 208786 pages, LIFO batch:31
  HighMem zone: 373 pages used for memmap
  HighMem zone: 47346 pages, LIFO batch:15
Using APIC driver default
ACPI: PM-Timer IO Port: 0x808
ACPI: Local APIC address 0xfee00000
ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled)
ACPI: LAPIC (acpi_id[0x02] lapic_id[0x02] enabled)
ACPI: LAPIC (acpi_id[0x03] lapic_id[0x04] enabled)
ACPI: LAPIC (acpi_id[0x04] lapic_id[0x10] enabled)
ACPI: LAPIC (acpi_id[0x05] lapic_id[0x12] enabled)
ACPI: LAPIC (acpi_id[0x06] lapic_id[0x14] enabled)
ACPI: LAPIC (acpi_id[0x07] lapic_id[0x20] enabled)
ACPI: LAPIC (acpi_id[0x08] lapic_id[0x22] enabled)
ACPI: LAPIC (acpi_id[0x09] lapic_id[0x24] enabled)
ACPI: LAPIC (acpi_id[0x0a] lapic_id[0x30] enabled)
ACPI: LAPIC (acpi_id[0x0b] lapic_id[0x32] enabled)
ACPI: LAPIC (acpi_id[0x0c] lapic_id[0x34] enabled)
ACPI: LAPIC (acpi_id[0x0d] lapic_id[0x01] enabled)
ACPI: LAPIC (acpi_id[0x0e] lapic_id[0x03] enabled)
ACPI: LAPIC (acpi_id[0x0f] lapic_id[0x05] enabled)
ACPI: LAPIC (acpi_id[0x10] lapic_id[0x11] enabled)
ACPI: LAPIC (acpi_id[0x11] lapic_id[0x13] enabled)
ACPI: LAPIC (acpi_id[0x12] lapic_id[0x15] enabled)
ACPI: LAPIC (acpi_id[0x13] lapic_id[0x21] enabled)
ACPI: LAPIC (acpi_id[0x14] lapic_id[0x23] enabled)
ACPI: LAPIC (acpi_id[0x15] lapic_id[0x25] enabled)
ACPI: LAPIC (acpi_id[0x16] lapic_id[0x31] enabled)
ACPI: LAPIC (acpi_id[0x17] lapic_id[0x33] enabled)
ACPI: LAPIC (acpi_id[0x18] lapic_id[0x35] enabled)
ACPI: LAPIC_NMI (acpi_id[0xff] dfl dfl lint[0x1])
ACPI: IOAPIC (id[0x06] address[0xfec00000] gsi_base[0])
IOAPIC[0]: apic_id 6, version 253, address 0xfec00000, GSI 0-253
ACPI: IOAPIC (id[0x07] address[0xfec8a000] gsi_base[24])
IOAPIC[1]: apic_id 7, version 253, address 0xfec8a000, GSI 24-277
ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
ACPI: IRQ0 used by override.
ACPI: IRQ2 used by override.
ACPI: IRQ9 used by override.
Using ACPI (MADT) for SMP configuration information
ACPI: HPET id: 0x8086a301 base: 0xfed00000
SMP: Allowing 24 CPUs, 0 hotplug CPUs
nr_irqs_gsi: 294
Allocating PCI resources starting at c0000000 (gap: c0000000:20000000)
Booting paravirtualized kernel on Xen
Xen version: 4.1.3 (preserve-AD)
setup_percpu: NR_CPUS:32 nr_cpumask_bits:32 nr_cpu_ids:24 nr_node_ids:1
PERCPU: Embedded 12 pages/cpu @f38b6000 s27072 r0 d22080 u49152
pcpu-alloc: s27072 r0 d22080 u49152 alloc=12*4096
pcpu-alloc: [0] 00 [0] 01 [0] 02 [0] 03 [0] 04 [0] 05 [0] 06 [0] 07
pcpu-alloc: [0] 08 [0] 09 [0] 10 [0] 11 [0] 12 [0] 13 [0] 14 [0] 15
pcpu-alloc: [0] 16 [0] 17 [0] 18 [0] 19 [0] 20 [0] 21 [0] 22 [0] 23
Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 260079
Kernel command line: root=/dev/nfs loglvl=all verbose=y console=hvc0
debug loglevel=8 earlyprintk=xen
PID hash table entries: 4096 (order: 2, 16384 bytes)
Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
Initializing CPU#0
Placing 64MB software IO TLB between ef7f2000 - f37f2000
software IO TLB at phys 0x2f7f2000 - 0x337f2000
Initializing HighMem for node 0 (000345fe:00040065)
Memory: 956424k/1048980k available (3623k kernel code, 91684k
reserved, 1410k data, 344k init, 190472k highmem)
virtual kernel memory layout:
    fixmap  : 0xfc936000 - 0xfcbff000   (2852 kB)
    pkmap   : 0xfc600000 - 0xfc800000   (2048 kB)
    vmalloc : 0xf4dfe000 - 0xfc5fe000   ( 120 MB)
    lowmem  : 0xc0000000 - 0xf45fe000   ( 837 MB)
      .init : 0xc14eb000 - 0xc1541000   ( 344 kB)
      .data : 0xc1389c49 - 0xc14ea840   (1410 kB)
      .text : 0xc1000000 - 0xc1389c49   (3623 kB)
Hierarchical RCU implementation.
	Additional per-CPU info printed with stalls.
NR_IRQS:2304 nr_irqs:256 16
CPU 0 irqstacks, hard=ef008000 soft=ef00a000
xen: sci override: global_irq=9 trigger=0 polarity=0
xen: registering gsi 9 triggering 0 polarity 0
xen: --> pirq=9 -> irq=9 (gsi=9)
xen: acpi sci 9
xen: --> pirq=1 -> irq=1 (gsi=1)
xen: --> pirq=2 -> irq=2 (gsi=2)
xen: --> pirq=3 -> irq=3 (gsi=3)
xen: --> pirq=4 -> irq=4 (gsi=4)
xen: --> pirq=5 -> irq=5 (gsi=5)
xen: --> pirq=6 -> irq=6 (gsi=6)
xen: --> pirq=7 -> irq=7 (gsi=7)
xen: --> pirq=8 -> irq=8 (gsi=8)
xen: --> pirq=10 -> irq=10 (gsi=10)
xen: --> pirq=11 -> irq=11 (gsi=11)
xen: --> pirq=12 -> irq=12 (gsi=12)
xen: --> pirq=13 -> irq=13 (gsi=13)
xen: --> pirq=14 -> irq=14 (gsi=14)
xen: --> pirq=15 -> irq=15 (gsi=15)
Console: colour VGA+ 80x25
console [hvc0] enabled, bootconsole disabled
console [hvc0] enabled, bootconsole disabled
Xen: using vcpuop timer interface
installing Xen timer for CPU 0
Detected 2266.814 MHz processor.
Calibrating delay loop (skipped), value calculated using timer
frequency.. 4533.62 BogoMIPS (lpj=9067256)
pid_max: default: 32768 minimum: 301
Mount-cache hash table entries: 512
CPU: Physical Processor ID: 0
CPU: Processor Core ID: 0
ENERGY_PERF_BIAS: Set to 'normal', was 'performance'
ENERGY_PERF_BIAS: View and update with x86_energy_perf_policy(8)
SMP alternatives: switching to UP code
Freeing SMP alternatives: 20k freed
ACPI: Core revision 20120320
Performance Events: unsupported p6 CPU model 44 no PMU driver,
software events only.
Brought up 1 CPUs
Grant tables using version 2 layout.
Grant table initialized
NET: Registered protocol family 16
ACPI: bus type pci registered
dca service started, version 1.12.1
PCI: MMCONFIG for domain 0000 [bus 00-ff] at [mem
0xe0000000-0xefffffff] (base 0xe0000000)
PCI: MMCONFIG at [mem 0xe0000000-0xefffffff] reserved in E820
PCI: Using MMCONFIG for extended config space
PCI: Using configuration type 1 for base access
bio: create slab <bio-0> at 0
ACPI: Added _OSI(Module Device)
ACPI: Added _OSI(Processor Device)
ACPI: Added _OSI(3.0 _SCP Extensions)
ACPI: Added _OSI(Processor Aggregator Device)
ACPI: EC: Look up EC in DSDT
\_SB_:_OSC invalid UUID
_OSC request data:1 6
ACPI: Executed 2 blocks of module-level executable AML code
ACPI: SSDT bf73e1b0 0414C (v01 DpgPmm  P001Ist 00000011 INTL 20051117)
ACPI: Dynamic OEM Table Load:
ACPI: SSDT   (null) 0414C (v01 DpgPmm  P001Ist 00000011 INTL 20051117)
ACPI: SSDT bf742300 00C88 (v01  PmRef  P001Cst 00003001 INTL 20051117)
ACPI: Dynamic OEM Table Load:
ACPI: SSDT   (null) 00C88 (v01  PmRef  P001Cst 00003001 INTL 20051117)
ACPI: SSDT bf742f90 00A0A (v01  PmRef  Cpu0Tst 00003000 INTL 20051117)
ACPI: Dynamic OEM Table Load:
ACPI: SSDT   (null) 00A0A (v01  PmRef  Cpu0Tst 00003000 INTL 20051117)
ACPI: Interpreter enabled
ACPI: (supports S0 S5)
ACPI: Using IOAPIC for interrupt routing
PCI: Using host bridge windows from ACPI; if necessary, use
"pci=nocrs" and report a bug
ACPI: PCI Root Bridge [PCI0] (domain 0000 [bus 00-ff])
pci_root PNP0A08:00: host bridge window [io  0x0000-0x03af]
pci_root PNP0A08:00: host bridge window [io  0x03e0-0x0cf7]
pci_root PNP0A08:00: host bridge window [io  0x03b0-0x03bb]
pci_root PNP0A08:00: host bridge window [io  0x03c0-0x03df]
pci_root PNP0A08:00: host bridge window [io  0x0d00-0xffff]
pci_root PNP0A08:00: host bridge window [mem 0x000a0000-0x000bffff]
pci_root PNP0A08:00: host bridge window [mem 0x000d0000-0x000dffff]
pci_root PNP0A08:00: host bridge window [mem 0xc0000000-0xdfffffff]
pci_root PNP0A08:00: host bridge window [mem 0xf0000000-0xfed8ffff]
PCI host bridge to bus 0000:00
pci_bus 0000:00: root bus resource [io  0x0000-0x03af]
pci_bus 0000:00: root bus resource [io  0x03e0-0x0cf7]
pci_bus 0000:00: root bus resource [io  0x03b0-0x03bb]
pci_bus 0000:00: root bus resource [io  0x03c0-0x03df]
pci_bus 0000:00: root bus resource [io  0x0d00-0xffff]
pci_bus 0000:00: root bus resource [mem 0x000a0000-0x000bffff]
pci_bus 0000:00: root bus resource [mem 0x000d0000-0x000dffff]
pci_bus 0000:00: root bus resource [mem 0xc0000000-0xdfffffff]
pci_bus 0000:00: root bus resource [mem 0xf0000000-0xfed8ffff]
pci 0000:00:00.0: [8086:3406] type 00 class 0x060000
pci 0000:00:00.0: PME# supported from D0 D3hot D3cold
pci 0000:00:01.0: [8086:3408] type 01 class 0x060400
pci 0000:00:01.0: PME# supported from D0 D3hot D3cold
pci 0000:00:03.0: [8086:340a] type 01 class 0x060400
pci 0000:00:03.0: PME# supported from D0 D3hot D3cold
pci 0000:00:05.0: [8086:340c] type 01 class 0x060400
pci 0000:00:05.0: PME# supported from D0 D3hot D3cold
pci 0000:00:07.0: [8086:340e] type 01 class 0x060400
pci 0000:00:07.0: PME# supported from D0 D3hot D3cold
pci 0000:00:13.0: [8086:342d] type 00 class 0x080020
pci 0000:00:13.0: reg 10: [mem 0xfec8a000-0xfec8afff]
pci 0000:00:13.0: PME# supported from D0 D3hot D3cold
pci 0000:00:14.0: [8086:342e] type 00 class 0x080000
pci 0000:00:14.1: [8086:3422] type 00 class 0x080000
pci 0000:00:14.2: [8086:3423] type 00 class 0x080000
pci 0000:00:14.3: [8086:3438] type 00 class 0x080000
pci 0000:00:16.0: [8086:3430] type 00 class 0x088000
pci 0000:00:16.0: reg 10: [mem 0xfbef8000-0xfbefbfff 64bit]
pci 0000:00:16.1: [8086:3431] type 00 class 0x088000
pci 0000:00:16.1: reg 10: [mem 0xfbef4000-0xfbef7fff 64bit]
pci 0000:00:16.2: [8086:3432] type 00 class 0x088000
pci 0000:00:16.2: reg 10: [mem 0xfbef0000-0xfbef3fff 64bit]
pci 0000:00:16.3: [8086:3433] type 00 class 0x088000
pci 0000:00:16.3: reg 10: [mem 0xfbeec000-0xfbeeffff 64bit]
pci 0000:00:16.4: [8086:3429] type 00 class 0x088000
pci 0000:00:16.4: reg 10: [mem 0xfbee8000-0xfbeebfff 64bit]
pci 0000:00:16.5: [8086:342a] type 00 class 0x088000
pci 0000:00:16.5: reg 10: [mem 0xfbee4000-0xfbee7fff 64bit]
pci 0000:00:16.6: [8086:342b] type 00 class 0x088000
pci 0000:00:16.6: reg 10: [mem 0xfbee0000-0xfbee3fff 64bit]
pci 0000:00:16.7: [8086:342c] type 00 class 0x088000
pci 0000:00:16.7: reg 10: [mem 0xfbedc000-0xfbedffff 64bit]
pci 0000:00:1d.0: [8086:3a34] type 00 class 0x0c0300
pci 0000:00:1d.0: reg 20: [io  0xbc00-0xbc1f]
pci 0000:00:1d.1: [8086:3a35] type 00 class 0x0c0300
pci 0000:00:1d.1: reg 20: [io  0xb880-0xb89f]
pci 0000:00:1d.2: [8086:3a36] type 00 class 0x0c0300
pci 0000:00:1d.2: reg 20: [io  0xb800-0xb81f]
pci 0000:00:1d.7: [8086:3a3a] type 00 class 0x0c0320
pci 0000:00:1d.7: reg 10: [mem 0xfbeda000-0xfbeda3ff]
pci 0000:00:1d.7: PME# supported from D0 D3hot D3cold
pci 0000:00:1e.0: [8086:244e] type 01 class 0x060401
pci 0000:00:1f.0: [8086:3a16] type 00 class 0x060100
pci 0000:00:1f.0: ICH7 LPC Generic IO decode 2 PIO at 0ca0 (mask 000f)
pci 0000:00:1f.2: [8086:3a22] type 00 class 0x010601
pci 0000:00:1f.2: reg 10: [io  0xac00-0xac07]
pci 0000:00:1f.2: reg 14: [io  0xb480-0xb483]
pci 0000:00:1f.2: reg 18: [io  0xb400-0xb407]
pci 0000:00:1f.2: reg 1c: [io  0xb080-0xb083]
pci 0000:00:1f.2: reg 20: [io  0xb000-0xb01f]
pci 0000:00:1f.2: reg 24: [mem 0xfbed8000-0xfbed87ff]
pci 0000:00:1f.2: PME# supported from D3hot
pci 0000:00:1f.3: [8086:3a30] type 00 class 0x0c0500
pci 0000:00:1f.3: reg 10: [mem 0xfbed6000-0xfbed60ff 64bit]
pci 0000:00:1f.3: reg 20: [io  0x0400-0x041f]
pci 0000:01:00.0: [8086:10c9] type 00 class 0x020000
pci 0000:01:00.0: reg 10: [mem 0xfbce0000-0xfbcfffff]
pci 0000:01:00.0: reg 14: [mem 0xfbcc0000-0xfbcdffff]
pci 0000:01:00.0: reg 18: [io  0xcc00-0xcc1f]
pci 0000:01:00.0: reg 1c: [mem 0xfbc9c000-0xfbc9ffff]
pci 0000:01:00.0: reg 30: [mem 0xfbca0000-0xfbcbffff pref]
pci 0000:01:00.0: PME# supported from D0 D3hot D3cold
pci 0000:01:00.1: [8086:10c9] type 00 class 0x020000
pci 0000:01:00.1: reg 10: [mem 0xfbc20000-0xfbc3ffff]
pci 0000:01:00.1: reg 14: [mem 0xfbc00000-0xfbc1ffff]
pci 0000:01:00.1: reg 18: [io  0xc880-0xc89f]
pci 0000:01:00.1: reg 1c: [mem 0xfbbdc000-0xfbbdffff]
pci 0000:01:00.1: reg 30: [mem 0xfbbe0000-0xfbbfffff pref]
pci 0000:01:00.1: PME# supported from D0 D3hot D3cold
pci 0000:00:01.0: PCI bridge to [bus 01-02]
pci 0000:00:01.0:   bridge window [io  0xc000-0xcfff]
pci 0000:00:01.0:   bridge window [mem 0xfbb00000-0xfbcfffff]
pci 0000:03:00.0: [8086:10fb] type 00 class 0x020000
pci 0000:03:00.0: reg 10: [mem 0xfbdc0000-0xfbdfffff 64bit]
pci 0000:03:00.0: reg 18: [io  0xdc00-0xdc1f]
pci 0000:03:00.0: reg 20: [mem 0xfbd9c000-0xfbd9ffff 64bit]
pci 0000:03:00.0: reg 30: [mem 0xfbda0000-0xfbdbffff pref]
pci 0000:03:00.0: PME# supported from D0 D3hot
pci 0000:03:00.1: [8086:10fb] type 00 class 0x020000
pci 0000:03:00.1: reg 10: [mem 0xfbd40000-0xfbd7ffff 64bit]
pci 0000:03:00.1: reg 18: [io  0xd880-0xd89f]
pci 0000:03:00.1: reg 20: [mem 0xfbd1c000-0xfbd1ffff 64bit]
pci 0000:03:00.1: reg 30: [mem 0xfbd20000-0xfbd3ffff pref]
pci 0000:03:00.1: PME# supported from D0 D3hot
pci 0000:00:03.0: PCI bridge to [bus 03-04]
pci 0000:00:03.0:   bridge window [io  0xd000-0xdfff]
pci 0000:00:03.0:   bridge window [mem 0xfbd00000-0xfbdfffff]
pci 0000:00:03.0:   bridge window [mem 0xf9c00000-0xf9ffffff 64bit pref]
pci 0000:00:05.0: PCI bridge to [bus 05-05]
pci 0000:00:07.0: PCI bridge to [bus 06-06]
pci 0000:07:04.0: [1a03:2000] type 00 class 0x030000
pci 0000:07:04.0: reg 10: [mem 0xfb000000-0xfb7fffff]
pci 0000:07:04.0: reg 14: [mem 0xfafe0000-0xfaffffff]
pci 0000:07:04.0: reg 18: [io  0xec00-0xec7f]
pci 0000:07:04.0: supports D1 D2
pci 0000:07:04.0: PME# supported from D0 D1 D2 D3hot D3cold
pci 0000:00:1e.0: PCI bridge to [bus 07-07] (subtractive decode)
pci 0000:00:1e.0:   bridge window [io  0xe000-0xefff]
pci 0000:00:1e.0:   bridge window [mem 0xfaf00000-0xfb7fffff]
pci 0000:00:1e.0:   bridge window [io  0x0000-0x03af] (subtractive decode)
pci 0000:00:1e.0:   bridge window [io  0x03e0-0x0cf7] (subtractive decode)
pci 0000:00:1e.0:   bridge window [io  0x03b0-0x03bb] (subtractive decode)
pci 0000:00:1e.0:   bridge window [io  0x03c0-0x03df] (subtractive decode)
pci 0000:00:1e.0:   bridge window [io  0x0d00-0xffff] (subtractive decode)
pci 0000:00:1e.0:   bridge window [mem 0x000a0000-0x000bffff]
(subtractive decode)
pci 0000:00:1e.0:   bridge window [mem 0x000d0000-0x000dffff]
(subtractive decode)
pci 0000:00:1e.0:   bridge window [mem 0xc0000000-0xdfffffff]
(subtractive decode)
pci 0000:00:1e.0:   bridge window [mem 0xf0000000-0xfed8ffff]
(subtractive decode)
pci_bus 0000:00: on NUMA node 0
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT]
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.NPE7._PRT]
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.P0P1._PRT]
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.NPE1._PRT]
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.NPE5._PRT]
 pci0000:00: Unable to request _OSC control (_OSC support mask: 0x19)
(XEN) PCI add device 00:00.0
(XEN) PCI add device 00:01.0
(XEN) PCI add device 00:03.0
(XEN) PCI add device 00:05.0
(XEN) PCI add device 00:07.0
(XEN) PCI add device 00:13.0
(XEN) PCI add device 00:14.0
(XEN) PCI add device 00:14.1
(XEN) PCI add device 00:14.2
(XEN) PCI add device 00:14.3
(XEN) PCI add device 00:16.0
(XEN) PCI add device 00:16.1
(XEN) PCI add device 00:16.2
(XEN) PCI add device 00:16.3
(XEN) PCI add device 00:16.4
(XEN) PCI add device 00:16.5
(XEN) PCI add device 00:16.6
(XEN) PCI add device 00:16.7
(XEN) PCI add device 00:1d.0
(XEN) PCI add device 00:1d.1
(XEN) PCI add device 00:1d.2
(XEN) PCI add device 00:1d.7
(XEN) PCI add device 00:1e.0
(XEN) PCI add device 00:1f.0
(XEN) PCI add device 00:1f.2
(XEN) PCI add device 00:1f.3
(XEN) PCI add device 01:00.0
(XEN) PCI add device 01:00.1
(XEN) PCI add device 03:00.0
(XEN) PCI add device 03:00.1
(XEN) PCI add device 07:04.0
ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 6 7 *10 11 12 14 15)
ACPI: PCI Interrupt Link [LNKB] (IRQs *5)
ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 6 7 10 11 12 14 *15)
ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 6 7 10 *11 12 14 15)
ACPI: PCI Interrupt Link [LNKE] (IRQs 3 4 6 7 10 11 12 14 15) *0, disabled.
ACPI: PCI Interrupt Link [LNKF] (IRQs 3 4 6 7 10 11 12 14 15) *0, disabled.
ACPI: PCI Interrupt Link [LNKG] (IRQs 3 4 6 7 10 11 12 14 15) *0, disabled.
ACPI: PCI Interrupt Link [LNKH] (IRQs 3 4 6 7 10 11 12 *14 15)
xen/balloon: Initialising balloon driver.
xen-balloon: Initialising balloon driver.
xen/balloon: Xen selfballooning driver disabled for domain0.
vgaarb: device added: PCI:0000:07:04.0,decodes=io+mem,owns=io+mem,locks=none
vgaarb: loaded
vgaarb: bridge control possible 0000:07:04.0
PCI: Using ACPI for IRQ routing
PCI: Discovered peer bus fe
PCI: root bus fe: using default resources
PCI host bridge to bus 0000:fe
pci_bus 0000:fe: root bus resource [io  0x0000-0xffff]
pci_bus 0000:fe: root bus resource [mem 0x00000000-0xffffffffff]
pci 0000:fe:00.0: [8086:2c70] type 00 class 0x060000
pci 0000:fe:00.1: [8086:2d81] type 00 class 0x060000
pci 0000:fe:02.0: [8086:2d90] type 00 class 0x060000
pci 0000:fe:02.1: [8086:2d91] type 00 class 0x060000
pci 0000:fe:02.2: [8086:2d92] type 00 class 0x060000
pci 0000:fe:02.3: [8086:2d93] type 00 class 0x060000
pci 0000:fe:02.4: [8086:2d94] type 00 class 0x060000
pci 0000:fe:02.5: [8086:2d95] type 00 class 0x060000
pci 0000:fe:03.0: [8086:2d98] type 00 class 0x060000
pci 0000:fe:03.1: [8086:2d99] type 00 class 0x060000
pci 0000:fe:03.2: [8086:2d9a] type 00 class 0x060000
pci 0000:fe:03.4: [8086:2d9c] type 00 class 0x060000
pci 0000:fe:04.0: [8086:2da0] type 00 class 0x060000
pci 0000:fe:04.1: [8086:2da1] type 00 class 0x060000
pci 0000:fe:04.2: [8086:2da2] type 00 class 0x060000
pci 0000:fe:04.3: [8086:2da3] type 00 class 0x060000
pci 0000:fe:05.0: [8086:2da8] type 00 class 0x060000
pci 0000:fe:05.1: [8086:2da9] type 00 class 0x060000
pci 0000:fe:05.2: [8086:2daa] type 00 class 0x060000
pci 0000:fe:05.3: [8086:2dab] type 00 class 0x060000
pci 0000:fe:06.0: [8086:2db0] type 00 class 0x060000
pci 0000:fe:06.1: [8086:2db1] type 00 class 0x060000
pci 0000:fe:06.2: [8086:2db2] type 00 class 0x060000
pci 0000:fe:06.3: [8086:2db3] type 00 class 0x060000
(XEN) PCI add device fe:00.0
(XEN) PCI add device fe:00.1
(XEN) PCI add device fe:02.0
(XEN) PCI add device fe:02.1
(XEN) PCI add device fe:02.2
(XEN) PCI add device fe:02.3
(XEN) PCI add device fe:02.4
(XEN) PCI add device fe:02.5
(XEN) PCI add device fe:03.0
(XEN) PCI add device fe:03.1
(XEN) PCI add device fe:03.2
(XEN) PCI add device fe:03.4
(XEN) PCI add device fe:04.0
(XEN) PCI add device fe:04.1
(XEN) PCI add device fe:04.2
(XEN) PCI add device fe:04.3
(XEN) PCI add device fe:05.0
(XEN) PCI add device fe:05.1
(XEN) PCI add device fe:05.2
(XEN) PCI add device fe:05.3
(XEN) PCI add device fe:06.0
(XEN) PCI add device fe:06.1
(XEN) PCI add device fe:06.2
(XEN) PCI add device fe:06.3
PCI: Discovered peer bus ff

PCI: root bus ff: using default resources

PCI host bridge to bus 0000:ff

pci_bus 0000:ff: root bus resource [io  0x0000-0xffff]

pci_bus 0000:ff: root bus resource [mem 0x00000000-0xffffffffff]

pci 0000:ff:00.0: [8086:2c70] type 00 class 0x060000

pci 0000:ff:00.1: [8086:2d81] type 00 class 0x060000

pci 0000:ff:02.0: [8086:2d90] type 00 class 0x060000

pci 0000:ff:02.1: [8086:2d91] type 00 class 0x060000

pci 0000:ff:02.2: [8086:2d92] type 00 class 0x060000

pci 0000:ff:02.3: [8086:2d93] type 00 class 0x060000

pci 0000:ff:02.4: [8086:2d94] type 00 class 0x060000

pci 0000:ff:02.5: [8086:2d95] type 00 class 0x060000

pci 0000:ff:03.0: [8086:2d98] type 00 class 0x060000

pci 0000:ff:03.1: [8086:2d99] type 00 class 0x060000

pci 0000:ff:03.2: [8086:2d9a] type 00 class 0x060000

pci 0000:ff:03.4: [8086:2d9c] type 00 class 0x060000

pci 0000:ff:04.0: [8086:2da0] type 00 class 0x060000

pci 0000:ff:04.1: [8086:2da1] type 00 class 0x060000

pci 0000:ff:04.2: [8086:2da2] type 00 class 0x060000

pci 0000:ff:04.3: [8086:2da3] type 00 class 0x060000

pci 0000:ff:05.0: [8086:2da8] type 00 class 0x060000

pci 0000:ff:05.1: [8086:2da9] type 00 class 0x060000

pci 0000:ff:05.2: [8086:2daa] type 00 class 0x060000

pci 0000:ff:05.3: [8086:2dab] type 00 class 0x060000

pci 0000:ff:06.0: [8086:2db0] type 00 class 0x060000

pci 0000:ff:06.1: [8086:2db1] type 00 class 0x060000

pci 0000:ff:06.2: [8086:2db2] type 00 class 0x060000

pci 0000:ff:06.3: [8086:2db3] type 00 class 0x060000

(XEN) PCI add device ff:00.0
(XEN) PCI add device ff:00.1
(XEN) PCI add device ff:02.0
(XEN) PCI add device ff:02.1
(XEN) PCI add device ff:02.2
(XEN) PCI add device ff:02.3
(XEN) PCI add device ff:02.4
(XEN) PCI add device ff:02.5
(XEN) PCI add device ff:03.0
(XEN) PCI add device ff:03.1
(XEN) PCI add device ff:03.2
(XEN) PCI add device ff:03.4
(XEN) PCI add device ff:04.0
(XEN) PCI add device ff:04.1
(XEN) PCI add device ff:04.2
(XEN) PCI add device ff:04.3
(XEN) PCI add device ff:05.0
(XEN) PCI add device ff:05.1
(XEN) PCI add device ff:05.2
(XEN) PCI add device ff:05.3
(XEN) PCI add device ff:06.0
(XEN) PCI add device ff:06.1
(XEN) PCI add device ff:06.2
(XEN) PCI add device ff:06.3
PCI: pci_cache_line_size set to 64 bytes

reserve RAM buffer: 000000000009b000 - 000000000009ffff

reserve RAM buffer: 0000000040065000 - 0000000043ffffff

Switching to clocksource xen

pnp: PnP ACPI init

ACPI: bus type pnp registered

pnp 00:00: [bus 00-ff]

pnp 00:00: [io  0x0cf8-0x0cff]

pnp 00:00: [io  0x0000-0x03af window]

pnp 00:00: [io  0x03e0-0x0cf7 window]

pnp 00:00: [io  0x03b0-0x03bb window]

pnp 00:00: [io  0x03c0-0x03df window]

pnp 00:00: [io  0x0d00-0xffff window]

pnp 00:00: [mem 0x000a0000-0x000bffff window]

pnp 00:00: [mem 0x000d0000-0x000dffff window]

pnp 00:00: [mem 0xc0000000-0xdfffffff window]

pnp 00:00: [mem 0xf0000000-0xfed8ffff window]

pnp 00:00: Plug and Play ACPI device, IDs PNP0a08 PNP0a03 (active)

pnp 00:01: [mem 0xfbf00000-0xfbffffff]

pnp 00:01: [mem 0xfc000000-0xfcffffff]

pnp 00:01: [mem 0xfd000000-0xfdffffff]

pnp 00:01: [mem 0xfe000000-0xfebfffff]

pnp 00:01: [mem 0xfec8a000-0xfec8afff]

pnp 00:01: [mem 0xfed10000-0xfed10fff]

system 00:01: [mem 0xfbf00000-0xfbffffff] has been reserved

system 00:01: [mem 0xfc000000-0xfcffffff] has been reserved

system 00:01: [mem 0xfd000000-0xfdffffff] has been reserved

system 00:01: [mem 0xfe000000-0xfebfffff] has been reserved

system 00:01: [mem 0xfec8a000-0xfec8afff] could not be reserved

system 00:01: [mem 0xfed10000-0xfed10fff] has been reserved

system 00:01: Plug and Play ACPI device, IDs PNP0c01 (active)

pnp 00:02: [dma 4]

pnp 00:02: [io  0x0000-0x000f]

pnp 00:02: [io  0x0081-0x0083]

pnp 00:02: [io  0x0087]

pnp 00:02: [io  0x0089-0x008b]

pnp 00:02: [io  0x008f]

pnp 00:02: [io  0x00c0-0x00df]

pnp 00:02: Plug and Play ACPI device, IDs PNP0200 (active)

pnp 00:03: [io  0x0070-0x0071]
xen: registering gsi 8 triggering 1 polarity 0
pnp 00:03: [irq 8]
pnp 00:03: Plug and Play ACPI device, IDs PNP0b00 (active)
pnp 00:04: [io  0x0061]
pnp 00:04: Plug and Play ACPI device, IDs PNP0800 (active)
pnp 00:05: [io  0x00f0-0x00ff]
xen: registering gsi 13 triggering 1 polarity 0
pnp 00:05: [irq 13]
pnp 00:05: Plug and Play ACPI device, IDs PNP0c04 (active)
pnp 00:06: [io  0x0010-0x001f]
pnp 00:06: [io  0x0022-0x003f]
pnp 00:06: [io  0x0044-0x005f]
pnp 00:06: [io  0x0062-0x0063]
pnp 00:06: [io  0x0065-0x006f]
pnp 00:06: [io  0x0072-0x007f]
pnp 00:06: [io  0x0080]
pnp 00:06: [io  0x0084-0x0086]
pnp 00:06: [io  0x0088]
pnp 00:06: [io  0x008c-0x008e]
pnp 00:06: [io  0x0090-0x009f]
pnp 00:06: [io  0x00a2-0x00bf]
pnp 00:06: [io  0x00e0-0x00ef]
pnp 00:06: [io  0x04d0-0x04d1]
pnp 00:06: [io  0x0800-0x087f]
pnp 00:06: [io  0x0000-0xffffffffffffffff disabled]
pnp 00:06: [io  0x0500-0x057f]
pnp 00:06: [io  0x0000-0xffffffffffffffff disabled]
pnp 00:06: [mem 0xfed1c000-0xfed1ffff]
pnp 00:06: [mem 0xfed20000-0xfed3ffff]
pnp 00:06: [mem 0xfed40000-0xfed8ffff]
system 00:06: [io  0x04d0-0x04d1] has been reserved
system 00:06: [io  0x0800-0x087f] has been reserved
system 00:06: [io  0x0500-0x057f] has been reserved
system 00:06: [mem 0xfed1c000-0xfed1ffff] has been reserved
system 00:06: [mem 0xfed20000-0xfed3ffff] has been reserved
system 00:06: [mem 0xfed40000-0xfed8ffff] has been reserved
system 00:06: Plug and Play ACPI device, IDs PNP0c02 (active)
pnp 00:07: [io  0x0ca2]
pnp 00:07: [io  0x0ca3]
pnp 00:07: Plug and Play ACPI device, IDs IPI0001 (active)
pnp 00:08: [mem 0xfed00000-0xfed003ff]
pnp 00:08: Plug and Play ACPI device, IDs PNP0103 (active)
pnp 00:09: [io  0x0060]
pnp 00:09: [io  0x0064]
pnp 00:09: [mem 0xfec00000-0xfec00fff]
pnp 00:09: [mem 0xfee00000-0xfee00fff]
system 00:09: [mem 0xfec00000-0xfec00fff] could not be reserved
system 00:09: [mem 0xfee00000-0xfee00fff] has been reserved
system 00:09: Plug and Play ACPI device, IDs PNP0c02 (active)
pnp 00:0a: [mem 0xe0000000-0xefffffff]
system 00:0a: [mem 0xe0000000-0xefffffff] has been reserved
system 00:0a: Plug and Play ACPI device, IDs PNP0c02 (active)
pnp 00:0b: [mem 0x00000000-0x0009ffff]
pnp 00:0b: [mem 0x000c0000-0x000cffff]
pnp 00:0b: [mem 0x000e0000-0x000fffff]
pnp 00:0b: [mem 0x00100000-0xbfffffff]
pnp 00:0b: [mem 0xfed90000-0xffffffff]
system 00:0b: [mem 0x00000000-0x0009ffff] could not be reserved
system 00:0b: [mem 0x000c0000-0x000cffff] could not be reserved
system 00:0b: [mem 0x000e0000-0x000fffff] could not be reserved
system 00:0b: [mem 0x00100000-0xbfffffff] could not be reserved
system 00:0b: [mem 0xfed90000-0xffffffff] could not be reserved
system 00:0b: Plug and Play ACPI device, IDs PNP0c01 (active)
pnp: PnP ACPI: found 12 devices
ACPI: ACPI bus type pnp unregistered
PM-Timer failed consistency check  (0x0xffffff) - aborting.
pci 0000:00:01.0: PCI bridge to [bus 01-02]
pci 0000:00:01.0:   bridge window [io  0xc000-0xcfff]
pci 0000:00:01.0:   bridge window [mem 0xfbb00000-0xfbcfffff]
pci 0000:00:03.0: PCI bridge to [bus 03-04]
pci 0000:00:03.0:   bridge window [io  0xd000-0xdfff]
pci 0000:00:03.0:   bridge window [mem 0xfbd00000-0xfbdfffff]
pci 0000:00:03.0:   bridge window [mem 0xf9c00000-0xf9ffffff 64bit pref]
pci 0000:00:05.0: PCI bridge to [bus 05-05]
pci 0000:00:07.0: PCI bridge to [bus 06-06]
pci 0000:00:1e.0: PCI bridge to [bus 07-07]
pci 0000:00:1e.0:   bridge window [io  0xe000-0xefff]
pci 0000:00:1e.0:   bridge window [mem 0xfaf00000-0xfb7fffff]
pci 0000:00:1e.0: setting latency timer to 64
pci_bus 0000:00: resource 4 [io  0x0000-0x03af]
pci_bus 0000:00: resource 5 [io  0x03e0-0x0cf7]
pci_bus 0000:00: resource 6 [io  0x03b0-0x03bb]
pci_bus 0000:00: resource 7 [io  0x03c0-0x03df]
pci_bus 0000:00: resource 8 [io  0x0d00-0xffff]
pci_bus 0000:00: resource 9 [mem 0x000a0000-0x000bffff]
pci_bus 0000:00: resource 10 [mem 0x000d0000-0x000dffff]
pci_bus 0000:00: resource 11 [mem 0xc0000000-0xdfffffff]
pci_bus 0000:00: resource 12 [mem 0xf0000000-0xfed8ffff]
pci_bus 0000:01: resource 0 [io  0xc000-0xcfff]
pci_bus 0000:01: resource 1 [mem 0xfbb00000-0xfbcfffff]
pci_bus 0000:03: resource 0 [io  0xd000-0xdfff]
pci_bus 0000:03: resource 1 [mem 0xfbd00000-0xfbdfffff]
pci_bus 0000:03: resource 2 [mem 0xf9c00000-0xf9ffffff 64bit pref]
pci_bus 0000:07: resource 0 [io  0xe000-0xefff]
pci_bus 0000:07: resource 1 [mem 0xfaf00000-0xfb7fffff]
pci_bus 0000:07: resource 4 [io  0x0000-0x03af]
pci_bus 0000:07: resource 5 [io  0x03e0-0x0cf7]
pci_bus 0000:07: resource 6 [io  0x03b0-0x03bb]
pci_bus 0000:07: resource 7 [io  0x03c0-0x03df]
pci_bus 0000:07: resource 8 [io  0x0d00-0xffff]
pci_bus 0000:07: resource 9 [mem 0x000a0000-0x000bffff]
pci_bus 0000:07: resource 10 [mem 0x000d0000-0x000dffff]
pci_bus 0000:07: resource 11 [mem 0xc0000000-0xdfffffff]
pci_bus 0000:07: resource 12 [mem 0xf0000000-0xfed8ffff]
pci_bus 0000:fe: resource 4 [io  0x0000-0xffff]
pci_bus 0000:fe: resource 5 [mem 0x00000000-0xffffffffff]
pci_bus 0000:ff: resource 4 [io  0x0000-0xffff]
pci_bus 0000:ff: resource 5 [mem 0x00000000-0xffffffffff]
NET: Registered protocol family 2
IP route cache hash table entries: 32768 (order: 5, 131072 bytes)
TCP established hash table entries: 131072 (order: 8, 1048576 bytes)
TCP bind hash table entries: 65536 (order: 7, 524288 bytes)
TCP: Hash tables configured (established 131072 bind 65536)
TCP: reno registered
UDP hash table entries: 512 (order: 2, 16384 bytes)
UDP-Lite hash table entries: 512 (order: 2, 16384 bytes)
NET: Registered protocol family 1
RPC: Registered named UNIX socket transport module.
RPC: Registered udp transport module.
RPC: Registered tcp transport module.
RPC: Registered tcp NFSv4.1 backchannel transport module.
xen: registering gsi 23 triggering 0 polarity 1
xen: --> pirq=23 -> irq=23 (gsi=23)
xen: registering gsi 19 triggering 0 polarity 1
xen: --> pirq=19 -> irq=19 (gsi=19)
xen: registering gsi 18 triggering 0 polarity 1
xen: --> pirq=18 -> irq=18 (gsi=18)
xen: registering gsi 23 triggering 0 polarity 1
Already setup the GSI :23
pci 0000:07:04.0: Boot video device
PCI: CLS 256 bytes, default 64
Trying to unpack rootfs image as initramfs...
Freeing initrd memory: 2960k freed
microcode: CPU0 sig=0x206c2, pf=0x1, revision=0x14
microcode: Microcode Update Driver: v2.00
<tigran@aivazian.fsnet.co.uk>, Peter Oruba
highmem bounce pool size: 64 pages
NFS: Registering the id_resolver key type
msgmni has been set to 1501
Block layer SCSI generic (bsg) driver version 0.4 loaded (major 253)
io scheduler noop registered (default)
io scheduler deadline registered
io scheduler cfq registered
ioapic: probe of 0000:00:13.0 failed with error -22
ioatdma: Intel(R) QuickData Technology Driver 4.00
xen: registering gsi 43 triggering 0 polarity 1
xen: --> pirq=43 -> irq=43 (gsi=43)
(XEN) ../physdev.c:171: dom0: wrong map_pirq type 3
xen: registering gsi 44 triggering 0 polarity 1
xen: --> pirq=44 -> irq=44 (gsi=44)
xen: registering gsi 45 triggering 0 polarity 1
xen: --> pirq=45 -> irq=45 (gsi=45)
xen: registering gsi 46 triggering 0 polarity 1
xen: --> pirq=46 -> irq=46 (gsi=46)
xen: registering gsi 43 triggering 0 polarity 1
Already setup the GSI :43
xen: registering gsi 44 triggering 0 polarity 1
Already setup the GSI :44
xen: registering gsi 45 triggering 0 polarity 1
Already setup the GSI :45
xen: registering gsi 46 triggering 0 polarity 1
Already setup the GSI :46
Event-channel device installed.
xen-pciback: backend is vpci
Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled
serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
brd: module loaded
loop: module loaded
igb: Intel(R) Gigabit Ethernet Network Driver - version 3.2.10-k
igb: Copyright (c) 2007-2012 Intel Corporation.
xen: registering gsi 17 triggering 0 polarity 1
xen: --> pirq=17 -> irq=17 (gsi=17)
igb 0000:01:00.0: Intel(R) Gigabit Ethernet Network Connection
igb 0000:01:00.0: eth0: (PCIe:2.5Gb/s:Width x4) 00:26:6c:ff:b3:8c
igb 0000:01:00.0: eth0: PBA No: 82576B-001
igb 0000:01:00.0: Using MSI-X interrupts. 1 rx queue(s), 1 tx queue(s)
xen: registering gsi 16 triggering 0 polarity 1
xen: --> pirq=16 -> irq=16 (gsi=16)
igb 0000:01:00.1: Intel(R) Gigabit Ethernet Network Connection
igb 0000:01:00.1: eth1: (PCIe:2.5Gb/s:Width x4) 00:26:6c:ff:b3:8d
igb 0000:01:00.1: eth1: PBA No: 82576B-001
igb 0000:01:00.1: Using MSI-X interrupts. 1 rx queue(s), 1 tx queue(s)
ixgbe: Intel(R) 10 Gigabit PCI Express Network Driver - version 3.8.21-k
ixgbe: Copyright (c) 1999-2012 Intel Corporation.
xen: registering gsi 24 triggering 0 polarity 1
xen: --> pirq=24 -> irq=24 (gsi=24)
ixgbe 0000:03:00.0: Multiqueue Disabled: Rx Queue count = 1, Tx Queue count = 1
ixgbe 0000:03:00.0: (PCI Express:5.0GT/s:Width x8) 00:8c:fa:01:84:6a
ixgbe 0000:03:00.0: MAC: 2, PHY: 1, PBA No: FFFFFF-0FF
ixgbe 0000:03:00.0: Intel(R) 10 Gigabit Network Connection
xen: registering gsi 34 triggering 0 polarity 1
xen: --> pirq=34 -> irq=34 (gsi=34)
ixgbe 0000:03:00.1: Multiqueue Disabled: Rx Queue count = 1, Tx Queue count = 1
ixgbe 0000:03:00.1: (PCI Express:5.0GT/s:Width x8) 00:8c:fa:01:84:6b
ixgbe 0000:03:00.1: MAC: 2, PHY: 1, PBA No: FFFFFF-0FF
ixgbe 0000:03:00.1: Intel(R) 10 Gigabit Network Connection
md: raid0 personality registered for level 0
md: raid1 personality registered for level 1
device-mapper: ioctl: 4.22.0-ioctl (2011-10-19) initialised: dm-devel@redhat.com
dcdbas dcdbas: Dell Systems Management Base Driver (version 5.6.0-3.2)
ip_tables: (C) 2000-2006 Netfilter Core Team
TCP: cubic registered
NET: Registered protocol family 10
NET: Registered protocol family 17
8021q: 802.1Q VLAN Support v1.8
Using IPI No-Shortcut mode
console [netcon0] enabled
netconsole: network logging started
drivers/rtc/hctosys.c: unable to open rtc device (rtc0)
BIOS EDD facility v0.16 2004-Jun-25, 0 devices found
EDD information not available.
ADDRCONF(NETDEV_UP): eth0: link is not ready
8021q: adding VLAN 0 to HW filter on device eth0
igb: eth0 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX
ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
Sending DHCP requests .., OK
Freeing unused kernel memory: 344k freed
Using fallback suid method
Using fallback suid method
INIT: version 2.88 booting
Using makefile-style concurrent boot in runlevel S.
.udev/ already exists on the static /dev! ...  [33m(warning). [39;49m
Starting the hotplug events dispatcher: udevd.
Synthesizing the initial hotplug events...done.
Waiting for /dev to be fully populated...input: Power Button as
/devices/LNXSYSTM:00/device:00/PNP0C0C:00/input/input0
ACPI: Power Button [PWRB]
input: Power Button as /devices/LNXSYSTM:00/LNXPWRBN:00/input/input1
ACPI: Power Button [PWRF]
rtc_cmos 00:03: RTC can wake from S4
rtc_cmos 00:03: rtc core: registered rtc_cmos as rtc0
rtc0: alarms up to one month, y3k, 114 bytes nvram
udev[1176]: renamed network interface eth1 to eth4
udevd-work[1175]: error changing net interface name eth0 to eth5:
Device or resource busy
udev[1177]: renamed network interface eth2 to eth6
udev[1178]: renamed network interface eth3 to eth7
done.
Setting preliminary keymap...done.
Activating swap...done.
Cleaning up ifupdown....
Setting up networking....
Loading kernel modules...udevd-work[1168]: kernel-provided name
'interfaces' and NAME= 'etherd/interfaces' disagree, please use
SYMLINK+= or change the kernel to provide the proper name
udevd-work[1166]: kernel-provided name 'err' and NAME= 'etherd/err'
disagree, please use SYMLINK+= or change the kernel to provide the
proper name
udevd-work[1167]: kernel-provided name 'discover' and NAME=
'etherd/discover' disagree, please use SYMLINK+= or change the kernel
to provide the proper name
udevd-work[1170]: kernel-provided name 'flush' and NAME=
'etherd/flush' disagree, please use SYMLINK+= or change the kernel to
provide the proper name
udevd-work[1169]: kernel-provided name 'revalidate' and NAME=
'etherd/revalidate' disagree, please use SYMLINK+= or change the
kernel to provide the proper name
Mounting local filesystems...done.
Activating swapfile swap...done.
Cleaning up temporary files....
Mounted debugfs on /sys/kernel/debug.
Cleaning up temporary files....
Setting console screen modes and fonts.
cannot (un)set powersave mode
 [9;30] [14;30]Setting up console font and keymap...done.
.
Mounting network filesystems:.
 [31mfailed. [39;49m
rm: cannot remove `/var/lib/urandom/random-seed': Read-only file system
startpar: service(s) returned failure: udev-mtab ...  [31mfailed! [39;49m
INIT: Entering runlevel: 2
Using makefile-style concurrent boot in runlevel 2.
Debugfs is already mounted on /sys/kernel/debug; nothing to do.
Starting enhanced syslogd: rsyslogd.
Starting ACPI services....
Starting periodic command scheduler: cron.
Starting OpenBSD Secure Shell server: sshd.
Starting xenstored...Could not open tracefile: No such file or directory
Setting domain 0 name...
Starting xenconsoled...



-- 
William

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Sep 23 15:17:01 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 23 Sep 2012 15:17:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TFnv3-0007u2-Qn; Sun, 23 Sep 2012 15:16:29 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1TFnv2-0007tx-QD
	for xen-devel@lists.xensource.com; Sun, 23 Sep 2012 15:16:29 +0000
Received: from [85.158.139.211:63630] by server-9.bemta-5.messagelabs.com id
	75/09-20529-CC72F505; Sun, 23 Sep 2012 15:16:28 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-206.messagelabs.com!1348413387!19638499!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTA4MzU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1913 invoked from network); 23 Sep 2012 15:16:27 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Sep 2012 15:16:27 -0000
X-IronPort-AV: E=Sophos;i="4.80,470,1344211200"; d="scan'208";a="14710652"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Sep 2012 15:16: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.279.1; Sun, 23 Sep 2012 16:16:26 +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 1TFnv0-00084C-M5;
	Sun, 23 Sep 2012 15:16:26 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1TFnv0-0003Rn-DR;
	Sun, 23 Sep 2012 16:16:26 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-13855-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sun, 23 Sep 2012 16:16:26 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13855: trouble: blocked/broken/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 13855 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13855/

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64                   2 host-install(2)         broken REGR. vs. 13825
 build-amd64-oldkern           2 host-install(2)         broken REGR. vs. 13825
 build-amd64-pvops             2 host-install(2)         broken REGR. vs. 13825

Tests which did not succeed, but are not blocking:
 test-amd64-i386-rhel6hvm-amd  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 xen-build-check(1)           blocked n/a
 test-amd64-amd64-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf-pin  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xend-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win           1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf      1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-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-amd64-i386-xl-multivcpu  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-qemuu-rhel6hvm-intel  1 xen-build-check(1)         blocked n/a
 test-amd64-i386-pv            1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-pcipt-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win-vcpus1    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-winxpsp3-vcpus1  1 xen-build-check(1)           blocked n/a
 test-amd64-i386-xl            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-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-win          1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 xen-build-check(1)         blocked n/a
 test-amd64-amd64-xl-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-pair         1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pair          1 xen-build-check(1)           blocked  n/a

version targeted for testing:
 xen                  8f658b463b78
baseline version:
 xen                  d364becfb083

------------------------------------------------------------
People who touched revisions under test:
  Jan Beulich <jbeulich@suse.com>
  Keir Fraser <keir@xen.org>
------------------------------------------------------------

jobs:
 build-amd64                                                  broken  
 build-i386                                                   pass    
 build-amd64-oldkern                                          broken  
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            broken  
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          blocked 
 test-amd64-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-amd64-amd64-xl-sedf-pin                                 blocked 
 test-amd64-amd64-pv                                          blocked 
 test-amd64-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-amd64-amd64-xl-win                                      blocked 
 test-amd64-amd64-xl-qemuu-winxpsp3                           blocked 
 test-amd64-i386-xend-winxpsp3                                blocked 
 test-amd64-amd64-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.

------------------------------------------------------------
changeset:   25938:8f658b463b78
tag:         tip
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Sep 21 17:02:46 2012 +0200
    
    x86: enable VIA CPU support
    
    Newer VIA CPUs have both 64-bit and VMX support. Enable them to be
    recognized for these purposes, at once stripping off any 32-bit CPU
    only bits from the respective CPU support file, and adding 64-bit ones
    found in recent Linux.
    
    This particularly implies untying the VMX == Intel assumption in a few
    places.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   25937:32187301ecc5
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Sep 21 15:20:21 2012 +0200
    
    x86: eliminate code affecting only 64-bit-incapable CPUs
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   25936:c8873f13cec3
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Sep 21 14:25:12 2012 +0200
    
    printk: prefer %#x et at over 0x%x
    
    Performance is not an issue with printk(), so let the function do
    minimally more work and instead save a byte per affected format
    specifier.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   25935:1e6e6b49b4ac
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Sep 21 13:47:18 2012 +0200
    
    x86: introduce MWAIT-based, ACPI-less CPU idle driver
    
    This is a port of Linux'es intel-idle driver serving the same purpose.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   25934:8eab91903e71
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Sep 21 13:45:08 2012 +0200
    
    cpuidle: remove unused latency_ticks member
    
    ... and code used only for initializing it.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   25933:d364becfb083
user:        Jan Beulich <jbeulich@suse.com>
date:        Thu Sep 20 13:31:19 2012 +0200
    
    introduce guest_handle_for_field()
    
    This helper turns a field of a GUEST_HANDLE in a GUEST_HANDLE.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    
    
(qemu changes not included)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Sep 23 15:17:01 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 23 Sep 2012 15:17:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TFnv3-0007u2-Qn; Sun, 23 Sep 2012 15:16:29 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1TFnv2-0007tx-QD
	for xen-devel@lists.xensource.com; Sun, 23 Sep 2012 15:16:29 +0000
Received: from [85.158.139.211:63630] by server-9.bemta-5.messagelabs.com id
	75/09-20529-CC72F505; Sun, 23 Sep 2012 15:16:28 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-206.messagelabs.com!1348413387!19638499!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTA4MzU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1913 invoked from network); 23 Sep 2012 15:16:27 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Sep 2012 15:16:27 -0000
X-IronPort-AV: E=Sophos;i="4.80,470,1344211200"; d="scan'208";a="14710652"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Sep 2012 15:16: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.279.1; Sun, 23 Sep 2012 16:16:26 +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 1TFnv0-00084C-M5;
	Sun, 23 Sep 2012 15:16:26 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1TFnv0-0003Rn-DR;
	Sun, 23 Sep 2012 16:16:26 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-13855-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sun, 23 Sep 2012 16:16:26 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13855: trouble: blocked/broken/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 13855 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13855/

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64                   2 host-install(2)         broken REGR. vs. 13825
 build-amd64-oldkern           2 host-install(2)         broken REGR. vs. 13825
 build-amd64-pvops             2 host-install(2)         broken REGR. vs. 13825

Tests which did not succeed, but are not blocking:
 test-amd64-i386-rhel6hvm-amd  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 xen-build-check(1)           blocked n/a
 test-amd64-amd64-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf-pin  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xend-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win           1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf      1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-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-amd64-i386-xl-multivcpu  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-qemuu-rhel6hvm-intel  1 xen-build-check(1)         blocked n/a
 test-amd64-i386-pv            1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-pcipt-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win-vcpus1    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-winxpsp3-vcpus1  1 xen-build-check(1)           blocked n/a
 test-amd64-i386-xl            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-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-win          1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 xen-build-check(1)         blocked n/a
 test-amd64-amd64-xl-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-pair         1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pair          1 xen-build-check(1)           blocked  n/a

version targeted for testing:
 xen                  8f658b463b78
baseline version:
 xen                  d364becfb083

------------------------------------------------------------
People who touched revisions under test:
  Jan Beulich <jbeulich@suse.com>
  Keir Fraser <keir@xen.org>
------------------------------------------------------------

jobs:
 build-amd64                                                  broken  
 build-i386                                                   pass    
 build-amd64-oldkern                                          broken  
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            broken  
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          blocked 
 test-amd64-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-amd64-amd64-xl-sedf-pin                                 blocked 
 test-amd64-amd64-pv                                          blocked 
 test-amd64-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-amd64-amd64-xl-win                                      blocked 
 test-amd64-amd64-xl-qemuu-winxpsp3                           blocked 
 test-amd64-i386-xend-winxpsp3                                blocked 
 test-amd64-amd64-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.

------------------------------------------------------------
changeset:   25938:8f658b463b78
tag:         tip
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Sep 21 17:02:46 2012 +0200
    
    x86: enable VIA CPU support
    
    Newer VIA CPUs have both 64-bit and VMX support. Enable them to be
    recognized for these purposes, at once stripping off any 32-bit CPU
    only bits from the respective CPU support file, and adding 64-bit ones
    found in recent Linux.
    
    This particularly implies untying the VMX == Intel assumption in a few
    places.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   25937:32187301ecc5
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Sep 21 15:20:21 2012 +0200
    
    x86: eliminate code affecting only 64-bit-incapable CPUs
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   25936:c8873f13cec3
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Sep 21 14:25:12 2012 +0200
    
    printk: prefer %#x et at over 0x%x
    
    Performance is not an issue with printk(), so let the function do
    minimally more work and instead save a byte per affected format
    specifier.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   25935:1e6e6b49b4ac
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Sep 21 13:47:18 2012 +0200
    
    x86: introduce MWAIT-based, ACPI-less CPU idle driver
    
    This is a port of Linux'es intel-idle driver serving the same purpose.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   25934:8eab91903e71
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Sep 21 13:45:08 2012 +0200
    
    cpuidle: remove unused latency_ticks member
    
    ... and code used only for initializing it.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   25933:d364becfb083
user:        Jan Beulich <jbeulich@suse.com>
date:        Thu Sep 20 13:31:19 2012 +0200
    
    introduce guest_handle_for_field()
    
    This helper turns a field of a GUEST_HANDLE in a GUEST_HANDLE.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    
    
(qemu changes not included)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Sep 23 18:17:30 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 23 Sep 2012 18:17:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TFqjc-0000mH-LU; Sun, 23 Sep 2012 18:16: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 1TFqja-0000mC-Ao
	for xen-devel@lists.xensource.com; Sun, 23 Sep 2012 18:16:50 +0000
Received: from [85.158.143.99:24604] by server-1.bemta-4.messagelabs.com id
	E7/9A-05684-1125F505; Sun, 23 Sep 2012 18:16:49 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1348424208!31438742!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTA4MzU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24700 invoked from network); 23 Sep 2012 18:16:48 -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;
	23 Sep 2012 18:16:48 -0000
X-IronPort-AV: E=Sophos;i="4.80,471,1344211200"; d="scan'208";a="14711138"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Sep 2012 18:16: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.279.1; Sun, 23 Sep 2012 19:16: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 1TFqjW-0000rG-OT;
	Sun, 23 Sep 2012 18:16:46 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1TFqjW-0002q1-Kh;
	Sun, 23 Sep 2012 19:16:46 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-13856-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sun, 23 Sep 2012 19:16:46 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13856: trouble: blocked/broken/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 13856 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13856/

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64                   2 host-install(2)         broken REGR. vs. 13825
 build-amd64-oldkern           2 host-install(2)         broken REGR. vs. 13825
 build-amd64-pvops             2 host-install(2)         broken REGR. vs. 13825

Tests which did not succeed, but are not blocking:
 test-amd64-i386-rhel6hvm-amd  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 xen-build-check(1)           blocked n/a
 test-amd64-amd64-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf-pin  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xend-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win           1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf      1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-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-amd64-i386-xl-multivcpu  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-qemuu-rhel6hvm-intel  1 xen-build-check(1)         blocked n/a
 test-amd64-i386-pv            1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-pcipt-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win-vcpus1    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-winxpsp3-vcpus1  1 xen-build-check(1)           blocked n/a
 test-amd64-i386-xl            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-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-win          1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 xen-build-check(1)         blocked n/a
 test-amd64-amd64-xl-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-pair         1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pair          1 xen-build-check(1)           blocked  n/a

version targeted for testing:
 xen                  8f658b463b78
baseline version:
 xen                  d364becfb083

------------------------------------------------------------
People who touched revisions under test:
  Jan Beulich <jbeulich@suse.com>
  Keir Fraser <keir@xen.org>
------------------------------------------------------------

jobs:
 build-amd64                                                  broken  
 build-i386                                                   pass    
 build-amd64-oldkern                                          broken  
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            broken  
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          blocked 
 test-amd64-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-amd64-amd64-xl-sedf-pin                                 blocked 
 test-amd64-amd64-pv                                          blocked 
 test-amd64-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-amd64-amd64-xl-win                                      blocked 
 test-amd64-amd64-xl-qemuu-winxpsp3                           blocked 
 test-amd64-i386-xend-winxpsp3                                blocked 
 test-amd64-amd64-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.

------------------------------------------------------------
changeset:   25938:8f658b463b78
tag:         tip
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Sep 21 17:02:46 2012 +0200
    
    x86: enable VIA CPU support
    
    Newer VIA CPUs have both 64-bit and VMX support. Enable them to be
    recognized for these purposes, at once stripping off any 32-bit CPU
    only bits from the respective CPU support file, and adding 64-bit ones
    found in recent Linux.
    
    This particularly implies untying the VMX == Intel assumption in a few
    places.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   25937:32187301ecc5
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Sep 21 15:20:21 2012 +0200
    
    x86: eliminate code affecting only 64-bit-incapable CPUs
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   25936:c8873f13cec3
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Sep 21 14:25:12 2012 +0200
    
    printk: prefer %#x et at over 0x%x
    
    Performance is not an issue with printk(), so let the function do
    minimally more work and instead save a byte per affected format
    specifier.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   25935:1e6e6b49b4ac
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Sep 21 13:47:18 2012 +0200
    
    x86: introduce MWAIT-based, ACPI-less CPU idle driver
    
    This is a port of Linux'es intel-idle driver serving the same purpose.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   25934:8eab91903e71
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Sep 21 13:45:08 2012 +0200
    
    cpuidle: remove unused latency_ticks member
    
    ... and code used only for initializing it.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   25933:d364becfb083
user:        Jan Beulich <jbeulich@suse.com>
date:        Thu Sep 20 13:31:19 2012 +0200
    
    introduce guest_handle_for_field()
    
    This helper turns a field of a GUEST_HANDLE in a GUEST_HANDLE.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    
    
(qemu changes not included)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Sep 23 18:17:30 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 23 Sep 2012 18:17:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TFqjc-0000mH-LU; Sun, 23 Sep 2012 18:16: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 1TFqja-0000mC-Ao
	for xen-devel@lists.xensource.com; Sun, 23 Sep 2012 18:16:50 +0000
Received: from [85.158.143.99:24604] by server-1.bemta-4.messagelabs.com id
	E7/9A-05684-1125F505; Sun, 23 Sep 2012 18:16:49 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1348424208!31438742!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTA4MzU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24700 invoked from network); 23 Sep 2012 18:16:48 -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;
	23 Sep 2012 18:16:48 -0000
X-IronPort-AV: E=Sophos;i="4.80,471,1344211200"; d="scan'208";a="14711138"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Sep 2012 18:16: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.279.1; Sun, 23 Sep 2012 19:16: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 1TFqjW-0000rG-OT;
	Sun, 23 Sep 2012 18:16:46 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1TFqjW-0002q1-Kh;
	Sun, 23 Sep 2012 19:16:46 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-13856-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sun, 23 Sep 2012 19:16:46 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13856: trouble: blocked/broken/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 13856 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13856/

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64                   2 host-install(2)         broken REGR. vs. 13825
 build-amd64-oldkern           2 host-install(2)         broken REGR. vs. 13825
 build-amd64-pvops             2 host-install(2)         broken REGR. vs. 13825

Tests which did not succeed, but are not blocking:
 test-amd64-i386-rhel6hvm-amd  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 xen-build-check(1)           blocked n/a
 test-amd64-amd64-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf-pin  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xend-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win           1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf      1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-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-amd64-i386-xl-multivcpu  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-qemuu-rhel6hvm-intel  1 xen-build-check(1)         blocked n/a
 test-amd64-i386-pv            1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-pcipt-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win-vcpus1    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-winxpsp3-vcpus1  1 xen-build-check(1)           blocked n/a
 test-amd64-i386-xl            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-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-win          1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 xen-build-check(1)         blocked n/a
 test-amd64-amd64-xl-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-pair         1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pair          1 xen-build-check(1)           blocked  n/a

version targeted for testing:
 xen                  8f658b463b78
baseline version:
 xen                  d364becfb083

------------------------------------------------------------
People who touched revisions under test:
  Jan Beulich <jbeulich@suse.com>
  Keir Fraser <keir@xen.org>
------------------------------------------------------------

jobs:
 build-amd64                                                  broken  
 build-i386                                                   pass    
 build-amd64-oldkern                                          broken  
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            broken  
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          blocked 
 test-amd64-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-amd64-amd64-xl-sedf-pin                                 blocked 
 test-amd64-amd64-pv                                          blocked 
 test-amd64-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-amd64-amd64-xl-win                                      blocked 
 test-amd64-amd64-xl-qemuu-winxpsp3                           blocked 
 test-amd64-i386-xend-winxpsp3                                blocked 
 test-amd64-amd64-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.

------------------------------------------------------------
changeset:   25938:8f658b463b78
tag:         tip
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Sep 21 17:02:46 2012 +0200
    
    x86: enable VIA CPU support
    
    Newer VIA CPUs have both 64-bit and VMX support. Enable them to be
    recognized for these purposes, at once stripping off any 32-bit CPU
    only bits from the respective CPU support file, and adding 64-bit ones
    found in recent Linux.
    
    This particularly implies untying the VMX == Intel assumption in a few
    places.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   25937:32187301ecc5
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Sep 21 15:20:21 2012 +0200
    
    x86: eliminate code affecting only 64-bit-incapable CPUs
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   25936:c8873f13cec3
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Sep 21 14:25:12 2012 +0200
    
    printk: prefer %#x et at over 0x%x
    
    Performance is not an issue with printk(), so let the function do
    minimally more work and instead save a byte per affected format
    specifier.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   25935:1e6e6b49b4ac
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Sep 21 13:47:18 2012 +0200
    
    x86: introduce MWAIT-based, ACPI-less CPU idle driver
    
    This is a port of Linux'es intel-idle driver serving the same purpose.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   25934:8eab91903e71
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Sep 21 13:45:08 2012 +0200
    
    cpuidle: remove unused latency_ticks member
    
    ... and code used only for initializing it.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   25933:d364becfb083
user:        Jan Beulich <jbeulich@suse.com>
date:        Thu Sep 20 13:31:19 2012 +0200
    
    introduce guest_handle_for_field()
    
    This helper turns a field of a GUEST_HANDLE in a GUEST_HANDLE.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    
    
(qemu changes not included)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Sep 23 20:16:31 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 23 Sep 2012 20:16:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TFsas-0001Pf-VB; Sun, 23 Sep 2012 20:15:58 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1TFsaq-0001PZ-SV
	for xen-devel@lists.xensource.com; Sun, 23 Sep 2012 20:15:57 +0000
Received: from [85.158.137.99:35057] by server-1.bemta-3.messagelabs.com id
	6A/F1-05884-BFD6F505; Sun, 23 Sep 2012 20:15:55 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-217.messagelabs.com!1348431354!18811733!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTA4MzU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10027 invoked from network); 23 Sep 2012 20:15:55 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Sep 2012 20:15:55 -0000
X-IronPort-AV: E=Sophos;i="4.80,471,1344211200"; d="scan'208";a="14711395"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Sep 2012 20:15: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.279.1; Sun, 23 Sep 2012 21:15: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 1TFsao-0001hT-2h;
	Sun, 23 Sep 2012 20:15:54 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1TFsao-0008PS-29;
	Sun, 23 Sep 2012 21:15:54 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-13857-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sun, 23 Sep 2012 21:15:54 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13857: trouble: blocked/broken/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 13857 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13857/

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64                   2 host-install(2)         broken REGR. vs. 13825
 build-amd64-oldkern           2 host-install(2)         broken REGR. vs. 13825
 build-amd64-pvops             2 host-install(2)         broken REGR. vs. 13825

Tests which did not succeed, but are not blocking:
 test-amd64-i386-rhel6hvm-amd  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 xen-build-check(1)           blocked n/a
 test-amd64-amd64-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf-pin  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xend-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win           1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf      1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-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-amd64-i386-xl-multivcpu  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-qemuu-rhel6hvm-intel  1 xen-build-check(1)         blocked n/a
 test-amd64-i386-pv            1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-pcipt-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win-vcpus1    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-winxpsp3-vcpus1  1 xen-build-check(1)           blocked n/a
 test-amd64-i386-xl            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-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-win          1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 xen-build-check(1)         blocked n/a
 test-amd64-amd64-xl-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-pair         1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pair          1 xen-build-check(1)           blocked  n/a

version targeted for testing:
 xen                  8f658b463b78
baseline version:
 xen                  d364becfb083

------------------------------------------------------------
People who touched revisions under test:
  Jan Beulich <jbeulich@suse.com>
  Keir Fraser <keir@xen.org>
------------------------------------------------------------

jobs:
 build-amd64                                                  broken  
 build-i386                                                   pass    
 build-amd64-oldkern                                          broken  
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            broken  
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          blocked 
 test-amd64-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-amd64-amd64-xl-sedf-pin                                 blocked 
 test-amd64-amd64-pv                                          blocked 
 test-amd64-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-amd64-amd64-xl-win                                      blocked 
 test-amd64-amd64-xl-qemuu-winxpsp3                           blocked 
 test-amd64-i386-xend-winxpsp3                                blocked 
 test-amd64-amd64-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.

------------------------------------------------------------
changeset:   25938:8f658b463b78
tag:         tip
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Sep 21 17:02:46 2012 +0200
    
    x86: enable VIA CPU support
    
    Newer VIA CPUs have both 64-bit and VMX support. Enable them to be
    recognized for these purposes, at once stripping off any 32-bit CPU
    only bits from the respective CPU support file, and adding 64-bit ones
    found in recent Linux.
    
    This particularly implies untying the VMX == Intel assumption in a few
    places.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   25937:32187301ecc5
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Sep 21 15:20:21 2012 +0200
    
    x86: eliminate code affecting only 64-bit-incapable CPUs
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   25936:c8873f13cec3
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Sep 21 14:25:12 2012 +0200
    
    printk: prefer %#x et at over 0x%x
    
    Performance is not an issue with printk(), so let the function do
    minimally more work and instead save a byte per affected format
    specifier.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   25935:1e6e6b49b4ac
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Sep 21 13:47:18 2012 +0200
    
    x86: introduce MWAIT-based, ACPI-less CPU idle driver
    
    This is a port of Linux'es intel-idle driver serving the same purpose.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   25934:8eab91903e71
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Sep 21 13:45:08 2012 +0200
    
    cpuidle: remove unused latency_ticks member
    
    ... and code used only for initializing it.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   25933:d364becfb083
user:        Jan Beulich <jbeulich@suse.com>
date:        Thu Sep 20 13:31:19 2012 +0200
    
    introduce guest_handle_for_field()
    
    This helper turns a field of a GUEST_HANDLE in a GUEST_HANDLE.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    
    
(qemu changes not included)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Sep 23 20:16:31 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 23 Sep 2012 20:16:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TFsas-0001Pf-VB; Sun, 23 Sep 2012 20:15:58 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1TFsaq-0001PZ-SV
	for xen-devel@lists.xensource.com; Sun, 23 Sep 2012 20:15:57 +0000
Received: from [85.158.137.99:35057] by server-1.bemta-3.messagelabs.com id
	6A/F1-05884-BFD6F505; Sun, 23 Sep 2012 20:15:55 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-217.messagelabs.com!1348431354!18811733!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTA4MzU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10027 invoked from network); 23 Sep 2012 20:15:55 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Sep 2012 20:15:55 -0000
X-IronPort-AV: E=Sophos;i="4.80,471,1344211200"; d="scan'208";a="14711395"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Sep 2012 20:15: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.279.1; Sun, 23 Sep 2012 21:15: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 1TFsao-0001hT-2h;
	Sun, 23 Sep 2012 20:15:54 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1TFsao-0008PS-29;
	Sun, 23 Sep 2012 21:15:54 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-13857-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sun, 23 Sep 2012 21:15:54 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13857: trouble: blocked/broken/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 13857 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13857/

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64                   2 host-install(2)         broken REGR. vs. 13825
 build-amd64-oldkern           2 host-install(2)         broken REGR. vs. 13825
 build-amd64-pvops             2 host-install(2)         broken REGR. vs. 13825

Tests which did not succeed, but are not blocking:
 test-amd64-i386-rhel6hvm-amd  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 xen-build-check(1)           blocked n/a
 test-amd64-amd64-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf-pin  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xend-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win           1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf      1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-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-amd64-i386-xl-multivcpu  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-qemuu-rhel6hvm-intel  1 xen-build-check(1)         blocked n/a
 test-amd64-i386-pv            1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-pcipt-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win-vcpus1    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-winxpsp3-vcpus1  1 xen-build-check(1)           blocked n/a
 test-amd64-i386-xl            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-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-win          1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 xen-build-check(1)         blocked n/a
 test-amd64-amd64-xl-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-pair         1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pair          1 xen-build-check(1)           blocked  n/a

version targeted for testing:
 xen                  8f658b463b78
baseline version:
 xen                  d364becfb083

------------------------------------------------------------
People who touched revisions under test:
  Jan Beulich <jbeulich@suse.com>
  Keir Fraser <keir@xen.org>
------------------------------------------------------------

jobs:
 build-amd64                                                  broken  
 build-i386                                                   pass    
 build-amd64-oldkern                                          broken  
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            broken  
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          blocked 
 test-amd64-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-amd64-amd64-xl-sedf-pin                                 blocked 
 test-amd64-amd64-pv                                          blocked 
 test-amd64-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-amd64-amd64-xl-win                                      blocked 
 test-amd64-amd64-xl-qemuu-winxpsp3                           blocked 
 test-amd64-i386-xend-winxpsp3                                blocked 
 test-amd64-amd64-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.

------------------------------------------------------------
changeset:   25938:8f658b463b78
tag:         tip
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Sep 21 17:02:46 2012 +0200
    
    x86: enable VIA CPU support
    
    Newer VIA CPUs have both 64-bit and VMX support. Enable them to be
    recognized for these purposes, at once stripping off any 32-bit CPU
    only bits from the respective CPU support file, and adding 64-bit ones
    found in recent Linux.
    
    This particularly implies untying the VMX == Intel assumption in a few
    places.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   25937:32187301ecc5
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Sep 21 15:20:21 2012 +0200
    
    x86: eliminate code affecting only 64-bit-incapable CPUs
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   25936:c8873f13cec3
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Sep 21 14:25:12 2012 +0200
    
    printk: prefer %#x et at over 0x%x
    
    Performance is not an issue with printk(), so let the function do
    minimally more work and instead save a byte per affected format
    specifier.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   25935:1e6e6b49b4ac
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Sep 21 13:47:18 2012 +0200
    
    x86: introduce MWAIT-based, ACPI-less CPU idle driver
    
    This is a port of Linux'es intel-idle driver serving the same purpose.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   25934:8eab91903e71
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Sep 21 13:45:08 2012 +0200
    
    cpuidle: remove unused latency_ticks member
    
    ... and code used only for initializing it.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   25933:d364becfb083
user:        Jan Beulich <jbeulich@suse.com>
date:        Thu Sep 20 13:31:19 2012 +0200
    
    introduce guest_handle_for_field()
    
    This helper turns a field of a GUEST_HANDLE in a GUEST_HANDLE.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    
    
(qemu changes not included)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 24 00:46:49 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Sep 2012 00:46: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 1TFwoS-0003ly-MO; Mon, 24 Sep 2012 00:46:16 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <singapore.mr.teo.en.ming@gmail.com>)
	id 1TFwoQ-0003lp-K7
	for xen-devel@lists.xen.org; Mon, 24 Sep 2012 00:46:14 +0000
Received: from [85.158.143.99:18885] by server-1.bemta-4.messagelabs.com id
	A1/16-05684-55DAF505; Mon, 24 Sep 2012 00:46:13 +0000
X-Env-Sender: singapore.mr.teo.en.ming@gmail.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1348447570!31132103!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-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13177 invoked from network); 24 Sep 2012 00:46:12 -0000
Received: from mail-pb0-f45.google.com (HELO mail-pb0-f45.google.com)
	(209.85.160.45)
	by server-5.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Sep 2012 00:46:12 -0000
Received: by pbbrp2 with SMTP id rp2so212129pbb.32
	for <multiple recipients>; Sun, 23 Sep 2012 17:46:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=message-id:disposition-notification-to:date:from:user-agent
	:mime-version:to:cc:subject:content-type;
	bh=lDa7xU0tYQvz8mVL8LJtMHJUs0aI9It4xoMFwFlJBLo=;
	b=zGP8pqqzT4KWLWC8TiFyOuXzgfQVg6rIo44XqU+QJBK6G81EttXEMDRJ9Bo1hPgYMJ
	c3drj/yG3QE2UkNbXh+zbCTkQ2QxH88peZxsCsZ9kUBkUqNxk8QXcG8Y9UvShJ2Xywjv
	zrOiKp0u2mIi9XgE2o9YRnFCJnzbIXT1flZElrIm3sCcv+p7AW0ZCFdNKOBSO4y9lJw6
	CHMZQlHriwl3XJ7ZuqeHLjxjrlMrZD32lfGOddRVzzE0IqLVDImKz8uqYmyLIlslhDJj
	bgL0lfeNQ8L03JPZdjv49QMziAR+ddab6TSS/ed6xRNXwx7cbo7/MEVzW1WjwqY3kNxS
	QQ8g==
Received: by 10.66.87.105 with SMTP id w9mr3338017paz.5.1348447569994;
	Sun, 23 Sep 2012 17:46:09 -0700 (PDT)
Received: from [192.168.1.2] (cm141.gamma206.maxonline.com.sg.
	[202.156.206.141])
	by mx.google.com with ESMTPS id h10sm4630762pav.28.2012.09.23.17.46.07
	(version=SSLv3 cipher=OTHER); Sun, 23 Sep 2012 17:46:09 -0700 (PDT)
Message-ID: <505FAD4D.7080003@gmail.com>
Date: Mon, 24 Sep 2012 08:46:05 +0800
From: "Teo En Ming (Zhang Enming)" <singapore.mr.teo.en.ming@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
MIME-Version: 1.0
To: "xen-users@lists.xen.org" <xen-users@lists.xen.org>, 
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Content-Type: multipart/mixed; boundary="------------020100030600030809050601"
Cc: "Teo En Ming \(Zhang Enming\)" <singapore.mr.teo.en.ming@gmail.com>,
	Frank Lyon <franklyon@gmail.com>
Subject: [Xen-devel] Is it possible to passthrough 2 GPUs to a single 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

This is a multi-part message in MIME format.
--------------020100030600030809050601
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Hi,

I tried working on Frank Lyon's server. With 2 GPUs (NVIDIA Quadro 6000) 
plugged in, Windows 7 and Windows 8 HVM guests are unable to start. 
Windows 7 and WIndows 8 HVM guests only manage to start properly when 
the 2nd GPU is unplugged out of the server. Is this right? This doesn't 
make sense.

Attached are Frank Lyon's xen configuration files.

Please advise. Thank you very much.

-- 
Yours sincerely,

Mr. Teo En Ming (Zhang Enming)
Singapore


--------------020100030600030809050601
Content-Type: text/plain;
 name="40_custom"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename="40_custom"

#!/bin/sh
exec tail -n +3 $0
# This file provides an easy way to add custom menu entries.  Simply type the
# menu entries you want to add after this comment.  Be careful not to change
# the 'exec tail' line above.
menuentry 'Ubuntu 12.04 amd64 Release with Xen 4.3-unstable and Linux Kernel 3.5.4-xen-frank.lyon-sgp' --class gnu-linux --class gnu --class os {
recordfail
insmod part_msdos
insmod ext2
search --no-floppy --fs-uuid --set=root d5ec6b7f-e1db-4b46-b050-d0bd46403f59
set root='(hd0,msdos1)'
search --no-floppy --fs-uuid --set=root d5ec6b7f-e1db-4b46-b050-d0bd46403f59
multiboot /xen.gz
module /vmlinuz-3.5.4-xen-frank.lyon-sgp placeholder root=/dev/mapper/snow-root dom0_mem=1024 console=tty quiet splash vt.handoff=7 nomodeset
module /initrd.img-3.5.4-xen-frank.lyon-sgp
}

--------------020100030600030809050601
Content-Type: text/plain;
 name="grub"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename="grub"

# If you change this file, run 'update-grub' afterwards to update
# /boot/grub/grub.cfg.
# For full documentation of the options in this file, see:
#   info -f grub -n 'Simple configuration'

GRUB_DEFAULT=0
#GRUB_HIDDEN_TIMEOUT=0
GRUB_HIDDEN_TIMEOUT_QUIET=true
GRUB_TIMEOUT=50
GRUB_DISTRIBUTOR=`lsb_release -i -s 2> /dev/null || echo Debian`
GRUB_CMDLINE_LINUX_DEFAULT=""
GRUB_CMDLINE_LINUX="nomodeset"

# Uncomment to enable BadRAM filtering, modify to suit your needs
# This works with Linux (no patch required) and with any kernel that obtains
# the memory map information from GRUB (GNU Mach, kernel of FreeBSD ...)
#GRUB_BADRAM="0x01234567,0xfefefefe,0x89abcdef,0xefefefef"

# Uncomment to disable graphical terminal (grub-pc only)
#GRUB_TERMINAL=console

# The resolution used on graphical terminal
# note that you can use only modes which your graphic card supports via VBE
# you can see them in real GRUB with the command `vbeinfo'
#GRUB_GFXMODE=640x480

# Uncomment if you don't want GRUB to pass "root=UUID=xxx" parameter to Linux
#GRUB_DISABLE_LINUX_UUID=true

# Uncomment to disable generation of recovery mode menu entries
#GRUB_DISABLE_RECOVERY="true"

# Uncomment to get a beep at grub start
#GRUB_INIT_TUNE="480 440 1"

--------------020100030600030809050601
Content-Type: text/plain;
 name="rc.local"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename="rc.local"

#!/bin/sh -e
#
# rc.local
#
# This script is executed at the end of each multiuser runlevel.
# Make sure that the script will "exit 0" on success or any other
# value on error.
#
# In order to enable or disable this script just change the execution
# bits.
#
# By default this script does nothing.

sudo ifconfig eth0 up
sudo route add default gw 192.168.25.1
sudo echo "nameserver 192.168.50.15" >> /etc/resolv.conf
sudo echo "nameserver 192.168.50.30" >> /etc/resolv.conf
exit 0

--------------020100030600030809050601
Content-Type: text/plain;
 name="start-windows"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename="start-windows"

#!/bin/sh
set -x
#
#Loads pci-stub kernel module
sudo modprobe pci-stub
#
#Passthrough NVIDIA Quadro 6000
# 
echo "Passthrough NVIDIA Quadro 6000 VGA card."
sudo chmod o+w /sys/bus/pci/drivers/pci-stub/new_id
sudo chmod o+w /sys/bus/pci/devices/0000:0d:00.0/driver/unbind
sudo chmod o+w /sys/bus/pci/drivers/pci-stub/bind
echo "10de 06d8" > /sys/bus/pci/drivers/pci-stub/new_id
echo "0000:0d:00.0" > /sys/bus/pci/devices/0000:0d:00.0/driver/unbind
echo "0000:0d:00.0" > /sys/bus/pci/drivers/pci-stub/bind
#
#Passthrough NVIDIA HD Audio Controller
# 
echo "Passthrough NVIDIA HD Audio Controller."
sudo chmod o+w /sys/bus/pci/drivers/pci-stub/new_id
sudo chmod o+w /sys/bus/pci/devices/0000:0d:00.1/driver/unbind
sudo chmod o+w /sys/bus/pci/drivers/pci-stub/bind
echo "10de 0be5" > /sys/bus/pci/drivers/pci-stub/new_id
echo "0000:0d:00.1" > /sys/bus/pci/devices/0000:0d:00.1/driver/unbind
echo "0000:0d:00.1" > /sys/bus/pci/drivers/pci-stub/bind
#
#Passthrough 2nd NVIDIA Quadro 6000
#
#echo "Passthrough 2nd NVIDIA Quadro 6000 VGA card."
#sudo chmod o+w /sys/bus/pci/drivers/pci-stub/new_id
#sudo chmod o+w /sys/bus/pci/devices/0000:1b:00.0/driver/unbind
#sudo chmod o+w /sys/bus/pci/drivers/pci-stub/bind
#echo "10de 06d8" > /sys/bus/pci/drivers/pci-stub/new_id
#echo "0000:1b:00.0" > /sys/bus/pci/devices/0000:1b:00.0/driver/unbind
#echo "0000:1b:00.0" > /sys/bus/pci/drivers/pci-stub/bind
#
#Passthrough 2nd NVIDIA HD Audio Controller
#
#echo "Passthrough 2nd NVIDIA HD Audio Controller."
#sudo chmod o+w /sys/bus/pci/drivers/pci-stub/new_id
#sudo chmod o+w /sys/bus/pci/devices/0000:1b:00.1/driver/unbind
#sudo chmod o+w /sys/bus/pci/drivers/pci-stub/bind
#echo "10de 0be5" > /sys/bus/pci/drivers/pci-stub/new_id
#echo "0000:1b:00.1" > /sys/bus/pci/devices/0000:1b:00.1/driver/unbind
#echo "0000:1b:00.1" > /sys/bus/pci/drivers/pci-stub/bind

#
#Wait for 10 seconds
#
sleep 10
#
#Start Windows HVM domU with VGA Passthrough
#
sudo xl create /etc/xen/Windows7
#sudo xl create /etc/xen/Windows8

--------------020100030600030809050601
Content-Type: text/plain;
 name="Windows7"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename="Windows7"

# XL domain configuration file for Windows 8 Consumer Preview 64-bit English HVM domU
# Please refer to "man xl.cfg" for further explanations.
# See also docs/misc/xl-network-configuration.markdown and
# docs/misc/xl-disk-configuration.txt
# Written by Teo En Ming (Zhang Enming)
# Email: teo.en.ming@gmail.com
# Mobile Phone: +65-8369-2618
# Country: Singapore
# Date: 18 Mar 2012 Sun
name="Windows8"
# Product Key: WJBRX-2N7B2-CCBF6-VPP97-R88XV
builder="hvm"
vcpus=2
memory=2048
on_poweroff="destroy"
on_reboot="restart"
on_crash="destroy"
disk=[ 'format=raw, vdev=hda, access=rw, target=/etc/xen/images/windows7.img', 'format=raw, vdev=hdc, access=ro, devtype=cdrom, target=/home/flyon/windows7.iso' ]
vif=[ 'bridge=eth0,type=ioemu,model=e1000' ]
#boot=[c|d|n]
# Selects the emulated virtual device to boot from. Options are hard disk (c), cd-rom (d) or network/PXE (n).
# Multiple options can be given and will be attempted in the order they are given. e.g. to boot from cd-rom
# but fallback to the hard disk you can give dc. The default is cd.
boot="dc"
acpi=1
#xen_platform_pci=1
#viridian=1
#stdvga=1

vnc=1
vnclisten="192.168.25.50"
vncdisplay=0
vncunused=1
vncpasswd=""
sdl=0
usb=1
# Passthrough the USB Keyboard
usbdevice = "host:04f2:0110"
# Passthrough the USB Optical Mouse
usbdevice = "host:046d:c03d"
# Enable Xen VGA Passthrough
gfx_passthru=1
# VGA Passthrough NVIDIA Quadro 6000 and PCI Passthrough NVIDIA HD Audio Controller, then 2nd NVIDIA Quadro 6000 and 2nd NVIDIA HD Audio Controller
#pci = [ '0d:00.0','0d:00.1','1b:00.0','1b:00.1' ]
pci = [ '0d:00.0','0d:00.1' ]

# PCI Passthrough Intel HD Audio Controller.
#pci = [ '00:1b.0' ]
# PCI Passthrough all the USB Controllers.
# pci = [ '00:1a.0','00:1a.1','00:1a.2','00:1a.7','00:1d.0','00:1d.1','00:1d.2','00:1d.7' ]


--------------020100030600030809050601
Content-Type: text/plain;
 name="Windows8"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename="Windows8"

# XL domain configuration file for Windows 8 Consumer Preview 64-bit English HVM domU
# Please refer to "man xl.cfg" for further explanations.
# See also docs/misc/xl-network-configuration.markdown and
# docs/misc/xl-disk-configuration.txt
# Written by Teo En Ming (Zhang Enming)
# Email: teo.en.ming@gmail.com
# Mobile Phone: +65-8369-2618
# Country: Singapore
# Date: 18 Mar 2012 Sun
name="Windows8"
# Product Key: WJBRX-2N7B2-CCBF6-VPP97-R88XV
builder="hvm"
vcpus=2
memory=2048
on_poweroff="destroy"
on_reboot="restart"
on_crash="destroy"
disk=[ 'format=raw, vdev=hda, access=rw, target=/etc/xen/images/windows8.img', 'format=raw, vdev=hdc, access=ro, devtype=cdrom, target=/home/flyon/windows8.iso' ]
vif=[ 'bridge=eth0,type=ioemu,model=e1000' ]
#boot=[c|d|n]
# Selects the emulated virtual device to boot from. Options are hard disk (c), cd-rom (d) or network/PXE (n).
# Multiple options can be given and will be attempted in the order they are given. e.g. to boot from cd-rom
# but fallback to the hard disk you can give dc. The default is cd.
boot="dc"
acpi=1
#xen_platform_pci=1
#viridian=1
#stdvga=1

vnc=1
vnclisten="192.168.25.50"
vncdisplay=0
vncunused=1
vncpasswd=""
sdl=0
usb=1
# Passthrough the USB Keyboard
usbdevice = "host:04f2:0110"
# Passthrough the USB Optical Mouse
usbdevice = "host:046d:c03d"
# Enable Xen VGA Passthrough
gfx_passthru=1
# VGA Passthrough NVIDIA Quadro 6000 and PCI Passthrough NVIDIA HD Audio Controller, then 2nd NVIDIA Quadro 6000 and 2nd NVIDIA HD Audio Controller
#pci = [ '0d:00.0','0d:00.1','1b:00.0','1b:00.1' ]
pci = [ '0d:00.0','0d:00.1' ]

# PCI Passthrough Intel HD Audio Controller.
#pci = [ '00:1b.0' ]
# PCI Passthrough all the USB Controllers.
# pci = [ '00:1a.0','00:1a.1','00:1a.2','00:1a.7','00:1d.0','00:1d.1','00:1d.2','00:1d.7' ]


--------------020100030600030809050601
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--------------020100030600030809050601--


From xen-devel-bounces@lists.xen.org Mon Sep 24 00:46:49 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Sep 2012 00:46: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 1TFwoS-0003ly-MO; Mon, 24 Sep 2012 00:46:16 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <singapore.mr.teo.en.ming@gmail.com>)
	id 1TFwoQ-0003lp-K7
	for xen-devel@lists.xen.org; Mon, 24 Sep 2012 00:46:14 +0000
Received: from [85.158.143.99:18885] by server-1.bemta-4.messagelabs.com id
	A1/16-05684-55DAF505; Mon, 24 Sep 2012 00:46:13 +0000
X-Env-Sender: singapore.mr.teo.en.ming@gmail.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1348447570!31132103!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-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13177 invoked from network); 24 Sep 2012 00:46:12 -0000
Received: from mail-pb0-f45.google.com (HELO mail-pb0-f45.google.com)
	(209.85.160.45)
	by server-5.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Sep 2012 00:46:12 -0000
Received: by pbbrp2 with SMTP id rp2so212129pbb.32
	for <multiple recipients>; Sun, 23 Sep 2012 17:46:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=message-id:disposition-notification-to:date:from:user-agent
	:mime-version:to:cc:subject:content-type;
	bh=lDa7xU0tYQvz8mVL8LJtMHJUs0aI9It4xoMFwFlJBLo=;
	b=zGP8pqqzT4KWLWC8TiFyOuXzgfQVg6rIo44XqU+QJBK6G81EttXEMDRJ9Bo1hPgYMJ
	c3drj/yG3QE2UkNbXh+zbCTkQ2QxH88peZxsCsZ9kUBkUqNxk8QXcG8Y9UvShJ2Xywjv
	zrOiKp0u2mIi9XgE2o9YRnFCJnzbIXT1flZElrIm3sCcv+p7AW0ZCFdNKOBSO4y9lJw6
	CHMZQlHriwl3XJ7ZuqeHLjxjrlMrZD32lfGOddRVzzE0IqLVDImKz8uqYmyLIlslhDJj
	bgL0lfeNQ8L03JPZdjv49QMziAR+ddab6TSS/ed6xRNXwx7cbo7/MEVzW1WjwqY3kNxS
	QQ8g==
Received: by 10.66.87.105 with SMTP id w9mr3338017paz.5.1348447569994;
	Sun, 23 Sep 2012 17:46:09 -0700 (PDT)
Received: from [192.168.1.2] (cm141.gamma206.maxonline.com.sg.
	[202.156.206.141])
	by mx.google.com with ESMTPS id h10sm4630762pav.28.2012.09.23.17.46.07
	(version=SSLv3 cipher=OTHER); Sun, 23 Sep 2012 17:46:09 -0700 (PDT)
Message-ID: <505FAD4D.7080003@gmail.com>
Date: Mon, 24 Sep 2012 08:46:05 +0800
From: "Teo En Ming (Zhang Enming)" <singapore.mr.teo.en.ming@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
MIME-Version: 1.0
To: "xen-users@lists.xen.org" <xen-users@lists.xen.org>, 
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Content-Type: multipart/mixed; boundary="------------020100030600030809050601"
Cc: "Teo En Ming \(Zhang Enming\)" <singapore.mr.teo.en.ming@gmail.com>,
	Frank Lyon <franklyon@gmail.com>
Subject: [Xen-devel] Is it possible to passthrough 2 GPUs to a single 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

This is a multi-part message in MIME format.
--------------020100030600030809050601
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Hi,

I tried working on Frank Lyon's server. With 2 GPUs (NVIDIA Quadro 6000) 
plugged in, Windows 7 and Windows 8 HVM guests are unable to start. 
Windows 7 and WIndows 8 HVM guests only manage to start properly when 
the 2nd GPU is unplugged out of the server. Is this right? This doesn't 
make sense.

Attached are Frank Lyon's xen configuration files.

Please advise. Thank you very much.

-- 
Yours sincerely,

Mr. Teo En Ming (Zhang Enming)
Singapore


--------------020100030600030809050601
Content-Type: text/plain;
 name="40_custom"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename="40_custom"

#!/bin/sh
exec tail -n +3 $0
# This file provides an easy way to add custom menu entries.  Simply type the
# menu entries you want to add after this comment.  Be careful not to change
# the 'exec tail' line above.
menuentry 'Ubuntu 12.04 amd64 Release with Xen 4.3-unstable and Linux Kernel 3.5.4-xen-frank.lyon-sgp' --class gnu-linux --class gnu --class os {
recordfail
insmod part_msdos
insmod ext2
search --no-floppy --fs-uuid --set=root d5ec6b7f-e1db-4b46-b050-d0bd46403f59
set root='(hd0,msdos1)'
search --no-floppy --fs-uuid --set=root d5ec6b7f-e1db-4b46-b050-d0bd46403f59
multiboot /xen.gz
module /vmlinuz-3.5.4-xen-frank.lyon-sgp placeholder root=/dev/mapper/snow-root dom0_mem=1024 console=tty quiet splash vt.handoff=7 nomodeset
module /initrd.img-3.5.4-xen-frank.lyon-sgp
}

--------------020100030600030809050601
Content-Type: text/plain;
 name="grub"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename="grub"

# If you change this file, run 'update-grub' afterwards to update
# /boot/grub/grub.cfg.
# For full documentation of the options in this file, see:
#   info -f grub -n 'Simple configuration'

GRUB_DEFAULT=0
#GRUB_HIDDEN_TIMEOUT=0
GRUB_HIDDEN_TIMEOUT_QUIET=true
GRUB_TIMEOUT=50
GRUB_DISTRIBUTOR=`lsb_release -i -s 2> /dev/null || echo Debian`
GRUB_CMDLINE_LINUX_DEFAULT=""
GRUB_CMDLINE_LINUX="nomodeset"

# Uncomment to enable BadRAM filtering, modify to suit your needs
# This works with Linux (no patch required) and with any kernel that obtains
# the memory map information from GRUB (GNU Mach, kernel of FreeBSD ...)
#GRUB_BADRAM="0x01234567,0xfefefefe,0x89abcdef,0xefefefef"

# Uncomment to disable graphical terminal (grub-pc only)
#GRUB_TERMINAL=console

# The resolution used on graphical terminal
# note that you can use only modes which your graphic card supports via VBE
# you can see them in real GRUB with the command `vbeinfo'
#GRUB_GFXMODE=640x480

# Uncomment if you don't want GRUB to pass "root=UUID=xxx" parameter to Linux
#GRUB_DISABLE_LINUX_UUID=true

# Uncomment to disable generation of recovery mode menu entries
#GRUB_DISABLE_RECOVERY="true"

# Uncomment to get a beep at grub start
#GRUB_INIT_TUNE="480 440 1"

--------------020100030600030809050601
Content-Type: text/plain;
 name="rc.local"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename="rc.local"

#!/bin/sh -e
#
# rc.local
#
# This script is executed at the end of each multiuser runlevel.
# Make sure that the script will "exit 0" on success or any other
# value on error.
#
# In order to enable or disable this script just change the execution
# bits.
#
# By default this script does nothing.

sudo ifconfig eth0 up
sudo route add default gw 192.168.25.1
sudo echo "nameserver 192.168.50.15" >> /etc/resolv.conf
sudo echo "nameserver 192.168.50.30" >> /etc/resolv.conf
exit 0

--------------020100030600030809050601
Content-Type: text/plain;
 name="start-windows"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename="start-windows"

#!/bin/sh
set -x
#
#Loads pci-stub kernel module
sudo modprobe pci-stub
#
#Passthrough NVIDIA Quadro 6000
# 
echo "Passthrough NVIDIA Quadro 6000 VGA card."
sudo chmod o+w /sys/bus/pci/drivers/pci-stub/new_id
sudo chmod o+w /sys/bus/pci/devices/0000:0d:00.0/driver/unbind
sudo chmod o+w /sys/bus/pci/drivers/pci-stub/bind
echo "10de 06d8" > /sys/bus/pci/drivers/pci-stub/new_id
echo "0000:0d:00.0" > /sys/bus/pci/devices/0000:0d:00.0/driver/unbind
echo "0000:0d:00.0" > /sys/bus/pci/drivers/pci-stub/bind
#
#Passthrough NVIDIA HD Audio Controller
# 
echo "Passthrough NVIDIA HD Audio Controller."
sudo chmod o+w /sys/bus/pci/drivers/pci-stub/new_id
sudo chmod o+w /sys/bus/pci/devices/0000:0d:00.1/driver/unbind
sudo chmod o+w /sys/bus/pci/drivers/pci-stub/bind
echo "10de 0be5" > /sys/bus/pci/drivers/pci-stub/new_id
echo "0000:0d:00.1" > /sys/bus/pci/devices/0000:0d:00.1/driver/unbind
echo "0000:0d:00.1" > /sys/bus/pci/drivers/pci-stub/bind
#
#Passthrough 2nd NVIDIA Quadro 6000
#
#echo "Passthrough 2nd NVIDIA Quadro 6000 VGA card."
#sudo chmod o+w /sys/bus/pci/drivers/pci-stub/new_id
#sudo chmod o+w /sys/bus/pci/devices/0000:1b:00.0/driver/unbind
#sudo chmod o+w /sys/bus/pci/drivers/pci-stub/bind
#echo "10de 06d8" > /sys/bus/pci/drivers/pci-stub/new_id
#echo "0000:1b:00.0" > /sys/bus/pci/devices/0000:1b:00.0/driver/unbind
#echo "0000:1b:00.0" > /sys/bus/pci/drivers/pci-stub/bind
#
#Passthrough 2nd NVIDIA HD Audio Controller
#
#echo "Passthrough 2nd NVIDIA HD Audio Controller."
#sudo chmod o+w /sys/bus/pci/drivers/pci-stub/new_id
#sudo chmod o+w /sys/bus/pci/devices/0000:1b:00.1/driver/unbind
#sudo chmod o+w /sys/bus/pci/drivers/pci-stub/bind
#echo "10de 0be5" > /sys/bus/pci/drivers/pci-stub/new_id
#echo "0000:1b:00.1" > /sys/bus/pci/devices/0000:1b:00.1/driver/unbind
#echo "0000:1b:00.1" > /sys/bus/pci/drivers/pci-stub/bind

#
#Wait for 10 seconds
#
sleep 10
#
#Start Windows HVM domU with VGA Passthrough
#
sudo xl create /etc/xen/Windows7
#sudo xl create /etc/xen/Windows8

--------------020100030600030809050601
Content-Type: text/plain;
 name="Windows7"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename="Windows7"

# XL domain configuration file for Windows 8 Consumer Preview 64-bit English HVM domU
# Please refer to "man xl.cfg" for further explanations.
# See also docs/misc/xl-network-configuration.markdown and
# docs/misc/xl-disk-configuration.txt
# Written by Teo En Ming (Zhang Enming)
# Email: teo.en.ming@gmail.com
# Mobile Phone: +65-8369-2618
# Country: Singapore
# Date: 18 Mar 2012 Sun
name="Windows8"
# Product Key: WJBRX-2N7B2-CCBF6-VPP97-R88XV
builder="hvm"
vcpus=2
memory=2048
on_poweroff="destroy"
on_reboot="restart"
on_crash="destroy"
disk=[ 'format=raw, vdev=hda, access=rw, target=/etc/xen/images/windows7.img', 'format=raw, vdev=hdc, access=ro, devtype=cdrom, target=/home/flyon/windows7.iso' ]
vif=[ 'bridge=eth0,type=ioemu,model=e1000' ]
#boot=[c|d|n]
# Selects the emulated virtual device to boot from. Options are hard disk (c), cd-rom (d) or network/PXE (n).
# Multiple options can be given and will be attempted in the order they are given. e.g. to boot from cd-rom
# but fallback to the hard disk you can give dc. The default is cd.
boot="dc"
acpi=1
#xen_platform_pci=1
#viridian=1
#stdvga=1

vnc=1
vnclisten="192.168.25.50"
vncdisplay=0
vncunused=1
vncpasswd=""
sdl=0
usb=1
# Passthrough the USB Keyboard
usbdevice = "host:04f2:0110"
# Passthrough the USB Optical Mouse
usbdevice = "host:046d:c03d"
# Enable Xen VGA Passthrough
gfx_passthru=1
# VGA Passthrough NVIDIA Quadro 6000 and PCI Passthrough NVIDIA HD Audio Controller, then 2nd NVIDIA Quadro 6000 and 2nd NVIDIA HD Audio Controller
#pci = [ '0d:00.0','0d:00.1','1b:00.0','1b:00.1' ]
pci = [ '0d:00.0','0d:00.1' ]

# PCI Passthrough Intel HD Audio Controller.
#pci = [ '00:1b.0' ]
# PCI Passthrough all the USB Controllers.
# pci = [ '00:1a.0','00:1a.1','00:1a.2','00:1a.7','00:1d.0','00:1d.1','00:1d.2','00:1d.7' ]


--------------020100030600030809050601
Content-Type: text/plain;
 name="Windows8"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename="Windows8"

# XL domain configuration file for Windows 8 Consumer Preview 64-bit English HVM domU
# Please refer to "man xl.cfg" for further explanations.
# See also docs/misc/xl-network-configuration.markdown and
# docs/misc/xl-disk-configuration.txt
# Written by Teo En Ming (Zhang Enming)
# Email: teo.en.ming@gmail.com
# Mobile Phone: +65-8369-2618
# Country: Singapore
# Date: 18 Mar 2012 Sun
name="Windows8"
# Product Key: WJBRX-2N7B2-CCBF6-VPP97-R88XV
builder="hvm"
vcpus=2
memory=2048
on_poweroff="destroy"
on_reboot="restart"
on_crash="destroy"
disk=[ 'format=raw, vdev=hda, access=rw, target=/etc/xen/images/windows8.img', 'format=raw, vdev=hdc, access=ro, devtype=cdrom, target=/home/flyon/windows8.iso' ]
vif=[ 'bridge=eth0,type=ioemu,model=e1000' ]
#boot=[c|d|n]
# Selects the emulated virtual device to boot from. Options are hard disk (c), cd-rom (d) or network/PXE (n).
# Multiple options can be given and will be attempted in the order they are given. e.g. to boot from cd-rom
# but fallback to the hard disk you can give dc. The default is cd.
boot="dc"
acpi=1
#xen_platform_pci=1
#viridian=1
#stdvga=1

vnc=1
vnclisten="192.168.25.50"
vncdisplay=0
vncunused=1
vncpasswd=""
sdl=0
usb=1
# Passthrough the USB Keyboard
usbdevice = "host:04f2:0110"
# Passthrough the USB Optical Mouse
usbdevice = "host:046d:c03d"
# Enable Xen VGA Passthrough
gfx_passthru=1
# VGA Passthrough NVIDIA Quadro 6000 and PCI Passthrough NVIDIA HD Audio Controller, then 2nd NVIDIA Quadro 6000 and 2nd NVIDIA HD Audio Controller
#pci = [ '0d:00.0','0d:00.1','1b:00.0','1b:00.1' ]
pci = [ '0d:00.0','0d:00.1' ]

# PCI Passthrough Intel HD Audio Controller.
#pci = [ '00:1b.0' ]
# PCI Passthrough all the USB Controllers.
# pci = [ '00:1a.0','00:1a.1','00:1a.2','00:1a.7','00:1d.0','00:1d.1','00:1d.2','00:1d.7' ]


--------------020100030600030809050601
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--------------020100030600030809050601--


From xen-devel-bounces@lists.xen.org Mon Sep 24 00:50:42 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Sep 2012 00:50:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TFwsG-000432-5l; Mon, 24 Sep 2012 00:50:12 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <singapore.mr.teo.en.ming@gmail.com>)
	id 1TFwsE-00042m-OE
	for xen-devel@lists.xen.org; Mon, 24 Sep 2012 00:50:10 +0000
Received: from [85.158.137.99:11037] by server-14.bemta-3.messagelabs.com id
	CE/B8-21431-14EAF505; Mon, 24 Sep 2012 00:50:09 +0000
X-Env-Sender: singapore.mr.teo.en.ming@gmail.com
X-Msg-Ref: server-16.tower-217.messagelabs.com!1348447806!18817323!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-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22296 invoked from network); 24 Sep 2012 00:50:08 -0000
Received: from mail-pb0-f45.google.com (HELO mail-pb0-f45.google.com)
	(209.85.160.45)
	by server-16.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Sep 2012 00:50:08 -0000
Received: by pbbrp2 with SMTP id rp2so215787pbb.32
	for <multiple recipients>; Sun, 23 Sep 2012 17:50:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=message-id:disposition-notification-to:date:from:user-agent
	:mime-version:to:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=xnZdvFW4bOHRYUPjCUeddA7ukaQDpy0bamG1qwooBtw=;
	b=PKg7Z9Ay4NhAF/018wwcGe927hs2FMMz9+sZdBOOuUJVDkCYTw512Ph/Ha4SXbAyQR
	3WEcyINMVyPp9m7kqR/24FaOgcJXwsy7NnLSKynWh2hfAVFaDmdIx/Dzx3jEvlES0JlA
	AEP9W2ycy+jImkr9uAnhXPCuA4S0nuqWRAx0ONjc04EMdYXBqwSgQrBDLcm0C6uNkQar
	SgptVMwyZyv46IFwzix57Igr3E1MMshyvtnx6u4BsPx3AXd8D2BSOqrbiLrCEws/rm2p
	S4lF5UCi4xLOZofKViDyqSF0B2oYF5/DCLEGOPC1XskPBAuTmNXmyIhiOKWiBVjphgn0
	JHyw==
Received: by 10.68.201.104 with SMTP id jz8mr32806234pbc.141.1348447806323;
	Sun, 23 Sep 2012 17:50:06 -0700 (PDT)
Received: from [192.168.1.2] (cm141.gamma206.maxonline.com.sg.
	[202.156.206.141])
	by mx.google.com with ESMTPS id nz6sm895271pbb.50.2012.09.23.17.50.04
	(version=SSLv3 cipher=OTHER); Sun, 23 Sep 2012 17:50:05 -0700 (PDT)
Message-ID: <505FAE3A.5030109@gmail.com>
Date: Mon, 24 Sep 2012 08:50:02 +0800
From: "Teo En Ming (Zhang Enming)" <singapore.mr.teo.en.ming@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
MIME-Version: 1.0
To: "xen-users@lists.xen.org" <xen-users@lists.xen.org>, 
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	"Teo En Ming (Zhang Enming)" <singapore.mr.teo.en.ming@gmail.com>, 
	Frank Lyon <franklyon@gmail.com>
References: <5059F632.3050808@gmail.com>
In-Reply-To: <5059F632.3050808@gmail.com>
Subject: Re: [Xen-devel] VGA Passthrough with Xen 4.3-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 20/09/2012 00:43, Teo En Ming (Zhang Enming) wrote:
> Dear All,
>
> I have tried to apply VGA passthrough patches hosted at Jean David 
> Techer's website to Xen 4.3-unstable. However, I cannot get VGA 
> passthrough to work with Xen 4.3-unstable. Are the VGA passthrough 
> patches hosted at David Techer's website incompatible with Xen 
> 4.3-unstable?
>
> This is David Techer's website: 
> http://www.davidgis.fr/blog/index.php?2011/12/07/860-xen-42unstable-patches-for-vga-pass-through
>
> I have also provided error logs in this email for troubleshooting 
> purposes.
>
> Please advise. Thank you very much.
>
Hi Guys,

I have found out that VGA Passthrough doesn't work with Xen 
4.3-unstable. But VGA Passthrough worked with Xen 4.2-unstable changeset 
25099.

-- 
Yours sincerely,

Mr. Teo En Ming (Zhang Enming)
Singapore


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 24 00:50:42 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Sep 2012 00:50:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TFwsG-000432-5l; Mon, 24 Sep 2012 00:50:12 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <singapore.mr.teo.en.ming@gmail.com>)
	id 1TFwsE-00042m-OE
	for xen-devel@lists.xen.org; Mon, 24 Sep 2012 00:50:10 +0000
Received: from [85.158.137.99:11037] by server-14.bemta-3.messagelabs.com id
	CE/B8-21431-14EAF505; Mon, 24 Sep 2012 00:50:09 +0000
X-Env-Sender: singapore.mr.teo.en.ming@gmail.com
X-Msg-Ref: server-16.tower-217.messagelabs.com!1348447806!18817323!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-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22296 invoked from network); 24 Sep 2012 00:50:08 -0000
Received: from mail-pb0-f45.google.com (HELO mail-pb0-f45.google.com)
	(209.85.160.45)
	by server-16.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Sep 2012 00:50:08 -0000
Received: by pbbrp2 with SMTP id rp2so215787pbb.32
	for <multiple recipients>; Sun, 23 Sep 2012 17:50:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=message-id:disposition-notification-to:date:from:user-agent
	:mime-version:to:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=xnZdvFW4bOHRYUPjCUeddA7ukaQDpy0bamG1qwooBtw=;
	b=PKg7Z9Ay4NhAF/018wwcGe927hs2FMMz9+sZdBOOuUJVDkCYTw512Ph/Ha4SXbAyQR
	3WEcyINMVyPp9m7kqR/24FaOgcJXwsy7NnLSKynWh2hfAVFaDmdIx/Dzx3jEvlES0JlA
	AEP9W2ycy+jImkr9uAnhXPCuA4S0nuqWRAx0ONjc04EMdYXBqwSgQrBDLcm0C6uNkQar
	SgptVMwyZyv46IFwzix57Igr3E1MMshyvtnx6u4BsPx3AXd8D2BSOqrbiLrCEws/rm2p
	S4lF5UCi4xLOZofKViDyqSF0B2oYF5/DCLEGOPC1XskPBAuTmNXmyIhiOKWiBVjphgn0
	JHyw==
Received: by 10.68.201.104 with SMTP id jz8mr32806234pbc.141.1348447806323;
	Sun, 23 Sep 2012 17:50:06 -0700 (PDT)
Received: from [192.168.1.2] (cm141.gamma206.maxonline.com.sg.
	[202.156.206.141])
	by mx.google.com with ESMTPS id nz6sm895271pbb.50.2012.09.23.17.50.04
	(version=SSLv3 cipher=OTHER); Sun, 23 Sep 2012 17:50:05 -0700 (PDT)
Message-ID: <505FAE3A.5030109@gmail.com>
Date: Mon, 24 Sep 2012 08:50:02 +0800
From: "Teo En Ming (Zhang Enming)" <singapore.mr.teo.en.ming@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
MIME-Version: 1.0
To: "xen-users@lists.xen.org" <xen-users@lists.xen.org>, 
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	"Teo En Ming (Zhang Enming)" <singapore.mr.teo.en.ming@gmail.com>, 
	Frank Lyon <franklyon@gmail.com>
References: <5059F632.3050808@gmail.com>
In-Reply-To: <5059F632.3050808@gmail.com>
Subject: Re: [Xen-devel] VGA Passthrough with Xen 4.3-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 20/09/2012 00:43, Teo En Ming (Zhang Enming) wrote:
> Dear All,
>
> I have tried to apply VGA passthrough patches hosted at Jean David 
> Techer's website to Xen 4.3-unstable. However, I cannot get VGA 
> passthrough to work with Xen 4.3-unstable. Are the VGA passthrough 
> patches hosted at David Techer's website incompatible with Xen 
> 4.3-unstable?
>
> This is David Techer's website: 
> http://www.davidgis.fr/blog/index.php?2011/12/07/860-xen-42unstable-patches-for-vga-pass-through
>
> I have also provided error logs in this email for troubleshooting 
> purposes.
>
> Please advise. Thank you very much.
>
Hi Guys,

I have found out that VGA Passthrough doesn't work with Xen 
4.3-unstable. But VGA Passthrough worked with Xen 4.2-unstable changeset 
25099.

-- 
Yours sincerely,

Mr. Teo En Ming (Zhang Enming)
Singapore


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 24 02:18:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Sep 2012 02:18:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TFyET-0000yB-BN; Mon, 24 Sep 2012 02:17: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 1TFyER-0000y6-Sw
	for xen-devel@lists.xensource.com; Mon, 24 Sep 2012 02:17:12 +0000
Received: from [85.158.139.83:5878] by server-8.bemta-5.messagelabs.com id
	C4/E3-03759-7A2CF505; Mon, 24 Sep 2012 02:17:11 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1348453029!31437444!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTA4NDA=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5896 invoked from network); 24 Sep 2012 02:17:10 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Sep 2012 02:17:10 -0000
X-IronPort-AV: E=Sophos;i="4.80,471,1344211200"; d="scan'208";a="14712273"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Sep 2012 02:17: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.279.1; Mon, 24 Sep 2012 03:17: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 1TFyEO-0003wB-FC;
	Mon, 24 Sep 2012 02:17:08 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1TFyEO-0000Gb-EI;
	Mon, 24 Sep 2012 03:17:08 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-13858-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Mon, 24 Sep 2012 03:17:08 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13858: trouble: blocked/broken/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 13858 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13858/

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64                   2 host-install(2)         broken REGR. vs. 13825
 build-amd64-oldkern           2 host-install(2)         broken REGR. vs. 13825
 build-amd64-pvops             2 host-install(2)         broken REGR. vs. 13825

Tests which did not succeed, but are not blocking:
 test-amd64-i386-rhel6hvm-amd  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 xen-build-check(1)           blocked n/a
 test-amd64-amd64-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf-pin  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xend-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win           1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf      1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-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-amd64-i386-xl-multivcpu  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-qemuu-rhel6hvm-intel  1 xen-build-check(1)         blocked n/a
 test-amd64-i386-pv            1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-pcipt-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win-vcpus1    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-winxpsp3-vcpus1  1 xen-build-check(1)           blocked n/a
 test-amd64-i386-xl            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-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-win          1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 xen-build-check(1)         blocked n/a
 test-amd64-amd64-xl-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-pair         1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pair          1 xen-build-check(1)           blocked  n/a

version targeted for testing:
 xen                  8f658b463b78
baseline version:
 xen                  d364becfb083

------------------------------------------------------------
People who touched revisions under test:
  Jan Beulich <jbeulich@suse.com>
  Keir Fraser <keir@xen.org>
------------------------------------------------------------

jobs:
 build-amd64                                                  broken  
 build-i386                                                   pass    
 build-amd64-oldkern                                          broken  
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            broken  
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          blocked 
 test-amd64-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-amd64-amd64-xl-sedf-pin                                 blocked 
 test-amd64-amd64-pv                                          blocked 
 test-amd64-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-amd64-amd64-xl-win                                      blocked 
 test-amd64-amd64-xl-qemuu-winxpsp3                           blocked 
 test-amd64-i386-xend-winxpsp3                                blocked 
 test-amd64-amd64-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.

------------------------------------------------------------
changeset:   25938:8f658b463b78
tag:         tip
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Sep 21 17:02:46 2012 +0200
    
    x86: enable VIA CPU support
    
    Newer VIA CPUs have both 64-bit and VMX support. Enable them to be
    recognized for these purposes, at once stripping off any 32-bit CPU
    only bits from the respective CPU support file, and adding 64-bit ones
    found in recent Linux.
    
    This particularly implies untying the VMX == Intel assumption in a few
    places.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   25937:32187301ecc5
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Sep 21 15:20:21 2012 +0200
    
    x86: eliminate code affecting only 64-bit-incapable CPUs
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   25936:c8873f13cec3
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Sep 21 14:25:12 2012 +0200
    
    printk: prefer %#x et at over 0x%x
    
    Performance is not an issue with printk(), so let the function do
    minimally more work and instead save a byte per affected format
    specifier.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   25935:1e6e6b49b4ac
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Sep 21 13:47:18 2012 +0200
    
    x86: introduce MWAIT-based, ACPI-less CPU idle driver
    
    This is a port of Linux'es intel-idle driver serving the same purpose.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   25934:8eab91903e71
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Sep 21 13:45:08 2012 +0200
    
    cpuidle: remove unused latency_ticks member
    
    ... and code used only for initializing it.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   25933:d364becfb083
user:        Jan Beulich <jbeulich@suse.com>
date:        Thu Sep 20 13:31:19 2012 +0200
    
    introduce guest_handle_for_field()
    
    This helper turns a field of a GUEST_HANDLE in a GUEST_HANDLE.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    
    
(qemu changes not included)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 24 02:18:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Sep 2012 02:18:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TFyET-0000yB-BN; Mon, 24 Sep 2012 02:17: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 1TFyER-0000y6-Sw
	for xen-devel@lists.xensource.com; Mon, 24 Sep 2012 02:17:12 +0000
Received: from [85.158.139.83:5878] by server-8.bemta-5.messagelabs.com id
	C4/E3-03759-7A2CF505; Mon, 24 Sep 2012 02:17:11 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1348453029!31437444!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTA4NDA=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5896 invoked from network); 24 Sep 2012 02:17:10 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Sep 2012 02:17:10 -0000
X-IronPort-AV: E=Sophos;i="4.80,471,1344211200"; d="scan'208";a="14712273"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Sep 2012 02:17: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.279.1; Mon, 24 Sep 2012 03:17: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 1TFyEO-0003wB-FC;
	Mon, 24 Sep 2012 02:17:08 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1TFyEO-0000Gb-EI;
	Mon, 24 Sep 2012 03:17:08 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-13858-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Mon, 24 Sep 2012 03:17:08 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13858: trouble: blocked/broken/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 13858 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13858/

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64                   2 host-install(2)         broken REGR. vs. 13825
 build-amd64-oldkern           2 host-install(2)         broken REGR. vs. 13825
 build-amd64-pvops             2 host-install(2)         broken REGR. vs. 13825

Tests which did not succeed, but are not blocking:
 test-amd64-i386-rhel6hvm-amd  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 xen-build-check(1)           blocked n/a
 test-amd64-amd64-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf-pin  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xend-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win           1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf      1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-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-amd64-i386-xl-multivcpu  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-qemuu-rhel6hvm-intel  1 xen-build-check(1)         blocked n/a
 test-amd64-i386-pv            1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-pcipt-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win-vcpus1    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-winxpsp3-vcpus1  1 xen-build-check(1)           blocked n/a
 test-amd64-i386-xl            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-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-win          1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 xen-build-check(1)         blocked n/a
 test-amd64-amd64-xl-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-pair         1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pair          1 xen-build-check(1)           blocked  n/a

version targeted for testing:
 xen                  8f658b463b78
baseline version:
 xen                  d364becfb083

------------------------------------------------------------
People who touched revisions under test:
  Jan Beulich <jbeulich@suse.com>
  Keir Fraser <keir@xen.org>
------------------------------------------------------------

jobs:
 build-amd64                                                  broken  
 build-i386                                                   pass    
 build-amd64-oldkern                                          broken  
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            broken  
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          blocked 
 test-amd64-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-amd64-amd64-xl-sedf-pin                                 blocked 
 test-amd64-amd64-pv                                          blocked 
 test-amd64-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-amd64-amd64-xl-win                                      blocked 
 test-amd64-amd64-xl-qemuu-winxpsp3                           blocked 
 test-amd64-i386-xend-winxpsp3                                blocked 
 test-amd64-amd64-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.

------------------------------------------------------------
changeset:   25938:8f658b463b78
tag:         tip
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Sep 21 17:02:46 2012 +0200
    
    x86: enable VIA CPU support
    
    Newer VIA CPUs have both 64-bit and VMX support. Enable them to be
    recognized for these purposes, at once stripping off any 32-bit CPU
    only bits from the respective CPU support file, and adding 64-bit ones
    found in recent Linux.
    
    This particularly implies untying the VMX == Intel assumption in a few
    places.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   25937:32187301ecc5
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Sep 21 15:20:21 2012 +0200
    
    x86: eliminate code affecting only 64-bit-incapable CPUs
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   25936:c8873f13cec3
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Sep 21 14:25:12 2012 +0200
    
    printk: prefer %#x et at over 0x%x
    
    Performance is not an issue with printk(), so let the function do
    minimally more work and instead save a byte per affected format
    specifier.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   25935:1e6e6b49b4ac
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Sep 21 13:47:18 2012 +0200
    
    x86: introduce MWAIT-based, ACPI-less CPU idle driver
    
    This is a port of Linux'es intel-idle driver serving the same purpose.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   25934:8eab91903e71
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Sep 21 13:45:08 2012 +0200
    
    cpuidle: remove unused latency_ticks member
    
    ... and code used only for initializing it.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   25933:d364becfb083
user:        Jan Beulich <jbeulich@suse.com>
date:        Thu Sep 20 13:31:19 2012 +0200
    
    introduce guest_handle_for_field()
    
    This helper turns a field of a GUEST_HANDLE in a GUEST_HANDLE.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    
    
(qemu changes not included)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 24 06:18:17 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Sep 2012 06:18:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TG1zG-0005Mf-FC; Mon, 24 Sep 2012 06:17:46 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <gabrielx.wu@intel.com>) id 1TG1zE-0005MX-Fa
	for xen-devel@lists.xen.org; Mon, 24 Sep 2012 06:17:44 +0000
X-Env-Sender: gabrielx.wu@intel.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1348467457!2800526!1
X-Originating-IP: [192.55.52.88]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjg4ID0+IDMyMjY5OQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 862 invoked from network); 24 Sep 2012 06:17:38 -0000
Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88)
	by server-11.tower-27.messagelabs.com with SMTP;
	24 Sep 2012 06:17:38 -0000
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
	by fmsmga101.fm.intel.com with ESMTP; 23 Sep 2012 23:17:36 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.80,474,1344236400"; d="scan'208";a="225628704"
Received: from fmsmsx104.amr.corp.intel.com ([10.19.9.35])
	by fmsmga001.fm.intel.com with ESMTP; 23 Sep 2012 23:17:36 -0700
Received: from fmsmsx151.amr.corp.intel.com (10.19.17.220) by
	FMSMSX104.amr.corp.intel.com (10.19.9.35) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Sun, 23 Sep 2012 23:17:35 -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; Sun, 23 Sep 2012 23:17:35 -0700
Received: from shsmsx102.ccr.corp.intel.com ([169.254.2.92]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.175]) with mapi id
	14.01.0355.002; Mon, 24 Sep 2012 14:17:33 +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:25929 & Dom0:3.5.4
Thread-Index: AQHNmhxIBEDgQH27cUqEM6LPCh2j3Q==
Date: Mon, 24 Sep 2012 06:17:33 +0000
Message-ID: <E4558C0C96688748837EB1B05BEED75A0FD73A8A@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,
	RongrongX" <rongrongx.liu@intel.com>, "Liu,
	SongtaoX" <songtaox.liu@intel.com>, "Zhou, Chao" <chao.zhou@intel.com>
Subject: [Xen-devel] VMX status report. Xen:25929 & Dom0:3.5.4
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi all,

This is the test report of xen-unstable tree, no issue found and two issues fixed.

Version Info:
=================================================================
xen-changeset:   25929:fee83ac77d8c
Dom0:          linux.git  3.5.4
=================================================================

New issue(0)
==============

Fixed issues(2)
==============
1. RHEL6.2/6.1 guest runs quite slow
  http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1811
2. XenU PV guest with VIF network cannot boot up with Linux3.6 dom0
  http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1832

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. after detaching a VF from a guest, shutdown the guest is very slow
  http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1812
6. Poor performance when do guest save/restore and migration with linux 3.1 dom0
  http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1784
7. vcpu-set doesn't take effect on guest
  http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1822
8.Fail to probe NIC driver in domu
  http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1824
9. Dom0 cannot be shutdown before PCI device detachment from guest
  http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1826


Best Regards,
Ronghui Wu(Gabriel)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 24 06:18:17 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Sep 2012 06:18:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TG1zG-0005Mf-FC; Mon, 24 Sep 2012 06:17:46 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <gabrielx.wu@intel.com>) id 1TG1zE-0005MX-Fa
	for xen-devel@lists.xen.org; Mon, 24 Sep 2012 06:17:44 +0000
X-Env-Sender: gabrielx.wu@intel.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1348467457!2800526!1
X-Originating-IP: [192.55.52.88]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjg4ID0+IDMyMjY5OQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 862 invoked from network); 24 Sep 2012 06:17:38 -0000
Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88)
	by server-11.tower-27.messagelabs.com with SMTP;
	24 Sep 2012 06:17:38 -0000
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
	by fmsmga101.fm.intel.com with ESMTP; 23 Sep 2012 23:17:36 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.80,474,1344236400"; d="scan'208";a="225628704"
Received: from fmsmsx104.amr.corp.intel.com ([10.19.9.35])
	by fmsmga001.fm.intel.com with ESMTP; 23 Sep 2012 23:17:36 -0700
Received: from fmsmsx151.amr.corp.intel.com (10.19.17.220) by
	FMSMSX104.amr.corp.intel.com (10.19.9.35) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Sun, 23 Sep 2012 23:17:35 -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; Sun, 23 Sep 2012 23:17:35 -0700
Received: from shsmsx102.ccr.corp.intel.com ([169.254.2.92]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.175]) with mapi id
	14.01.0355.002; Mon, 24 Sep 2012 14:17:33 +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:25929 & Dom0:3.5.4
Thread-Index: AQHNmhxIBEDgQH27cUqEM6LPCh2j3Q==
Date: Mon, 24 Sep 2012 06:17:33 +0000
Message-ID: <E4558C0C96688748837EB1B05BEED75A0FD73A8A@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,
	RongrongX" <rongrongx.liu@intel.com>, "Liu,
	SongtaoX" <songtaox.liu@intel.com>, "Zhou, Chao" <chao.zhou@intel.com>
Subject: [Xen-devel] VMX status report. Xen:25929 & Dom0:3.5.4
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi all,

This is the test report of xen-unstable tree, no issue found and two issues fixed.

Version Info:
=================================================================
xen-changeset:   25929:fee83ac77d8c
Dom0:          linux.git  3.5.4
=================================================================

New issue(0)
==============

Fixed issues(2)
==============
1. RHEL6.2/6.1 guest runs quite slow
  http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1811
2. XenU PV guest with VIF network cannot boot up with Linux3.6 dom0
  http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1832

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. after detaching a VF from a guest, shutdown the guest is very slow
  http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1812
6. Poor performance when do guest save/restore and migration with linux 3.1 dom0
  http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1784
7. vcpu-set doesn't take effect on guest
  http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1822
8.Fail to probe NIC driver in domu
  http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1824
9. Dom0 cannot be shutdown before PCI device detachment from guest
  http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1826


Best Regards,
Ronghui Wu(Gabriel)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 24 07:55:41 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Sep 2012 07:55:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TG3VX-0006T7-Fl; Mon, 24 Sep 2012 07:55:11 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <techno.geek.0x01@gmail.com>) id 1TFylB-0001Jz-Eu
	for xen-devel@lists.xen.org; Mon, 24 Sep 2012 02:51:01 +0000
Received: from [85.158.139.83:40731] by server-11.bemta-5.messagelabs.com id
	6F/B2-24658-49ACF505; Mon, 24 Sep 2012 02:51:00 +0000
X-Env-Sender: techno.geek.0x01@gmail.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1348455060!24559789!1
X-Originating-IP: [74.125.82.51]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3371 invoked from network); 24 Sep 2012 02:51:00 -0000
Received: from mail-wg0-f51.google.com (HELO mail-wg0-f51.google.com)
	(74.125.82.51)
	by server-11.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Sep 2012 02:51:00 -0000
Received: by wgbed3 with SMTP id ed3so3326564wgb.32
	for <xen-devel@lists.xen.org>; Sun, 23 Sep 2012 19:51:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=9R8OXE8iSOhRlrG1SPb7XdmzDSM2HawOGkgFU8Zpj48=;
	b=nlD00m/Cd1ywv0O55VaUR2/y5x1P+Te9NbvSXN0Ov6yUmlKgDy0Af9WTYAaZ/G1Pw2
	Oq9mJ65K7TyFx1MxFbfXwx1rcTxvlbe2tiYNnstcSqy8Rm+Hsedic/GW7zKrsOpVWJfm
	F6eX+2G2GFcy6VN42faATu0yn7Zf4VD/xOFDI58AgpG3naQ1V8F+/rZdlwbEwYg4PX4I
	kiCEX1b07ZDe4PPXOdWV9bI1ogeFMduuMK2X7rOCMx56D8y0Ao3gDwuw3mBMsFBwUiyD
	9US1w8uCfURoscwox1N7DXWRVgyV0e49ePeQ1D2EBVydMNfzTErfgeAQJNLeMc9I92au
	CeDQ==
MIME-Version: 1.0
Received: by 10.180.100.133 with SMTP id ey5mr11151820wib.4.1348455059879;
	Sun, 23 Sep 2012 19:50:59 -0700 (PDT)
Received: by 10.216.162.131 with HTTP; Sun, 23 Sep 2012 19:50:59 -0700 (PDT)
In-Reply-To: <505C87EB020000780009D02F@nat28.tlf.novell.com>
References: <CALHMb0dTaR0NCQ1XdfrZ00NXGe0DpKXMNAG0vvZrpNMkLxti6A@mail.gmail.com>
	<505C87EB020000780009D02F@nat28.tlf.novell.com>
Date: Mon, 24 Sep 2012 10:50:59 +0800
Message-ID: <CALHMb0fMfNz6b3heCHWhOMcH5RqkpkyFwPqup6k4Eeh64yfrdg@mail.gmail.com>
From: Yaogun Wen <techno.geek.0x01@gmail.com>
To: Ian Campbell <Ian.Campbell@citrix.com>, Jan Beulich <JBeulich@suse.com>
X-Mailman-Approved-At: Mon, 24 Sep 2012 07:55:10 +0000
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] The use of evtchn_upcall_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 2012/9/21 at pm 9:24 Ian Campbell wrote:
> It is read from assembly code (entry.S) accessed via
> VCPUINFO_upcall_mask which is defined using the asm-offsets.c mechanism.
>
> local_event_delivery_is_enabled seems to be redundant these days.
Thank you for your guidance. :)
But I still have some questions, please keep reading.

On 2012/9/21 at pm 9:29 Jan Beulich wrote:
> Setting an event channel pending isn't tied to the channel being
> unmasked - in particular, for polled event channels, one would
> keep them masked permanently, yet still expect events to be
> signaled. The mask really controls whether an upcall is actually
> permitted (just like EFLAGS.IF controls whether interrupts can
> be injected).
This explanation helps me to understand the meaning of VCPUINFO_upcall_mask.
I don't know x86 assembly language, but according to your explanation,
it seems that guest which only have masked channel will still receive
the events.
But from the comment of vcpu_info struct, it says "The mask
(evtchn_upcall_mask) is read before making an event upcall to the
guest".
So, which one is correct?


-- 
Best regards,

Yao-Jing Wen

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 24 07:55:41 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Sep 2012 07:55:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TG3VX-0006T7-Fl; Mon, 24 Sep 2012 07:55:11 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <techno.geek.0x01@gmail.com>) id 1TFylB-0001Jz-Eu
	for xen-devel@lists.xen.org; Mon, 24 Sep 2012 02:51:01 +0000
Received: from [85.158.139.83:40731] by server-11.bemta-5.messagelabs.com id
	6F/B2-24658-49ACF505; Mon, 24 Sep 2012 02:51:00 +0000
X-Env-Sender: techno.geek.0x01@gmail.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1348455060!24559789!1
X-Originating-IP: [74.125.82.51]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3371 invoked from network); 24 Sep 2012 02:51:00 -0000
Received: from mail-wg0-f51.google.com (HELO mail-wg0-f51.google.com)
	(74.125.82.51)
	by server-11.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Sep 2012 02:51:00 -0000
Received: by wgbed3 with SMTP id ed3so3326564wgb.32
	for <xen-devel@lists.xen.org>; Sun, 23 Sep 2012 19:51:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=9R8OXE8iSOhRlrG1SPb7XdmzDSM2HawOGkgFU8Zpj48=;
	b=nlD00m/Cd1ywv0O55VaUR2/y5x1P+Te9NbvSXN0Ov6yUmlKgDy0Af9WTYAaZ/G1Pw2
	Oq9mJ65K7TyFx1MxFbfXwx1rcTxvlbe2tiYNnstcSqy8Rm+Hsedic/GW7zKrsOpVWJfm
	F6eX+2G2GFcy6VN42faATu0yn7Zf4VD/xOFDI58AgpG3naQ1V8F+/rZdlwbEwYg4PX4I
	kiCEX1b07ZDe4PPXOdWV9bI1ogeFMduuMK2X7rOCMx56D8y0Ao3gDwuw3mBMsFBwUiyD
	9US1w8uCfURoscwox1N7DXWRVgyV0e49ePeQ1D2EBVydMNfzTErfgeAQJNLeMc9I92au
	CeDQ==
MIME-Version: 1.0
Received: by 10.180.100.133 with SMTP id ey5mr11151820wib.4.1348455059879;
	Sun, 23 Sep 2012 19:50:59 -0700 (PDT)
Received: by 10.216.162.131 with HTTP; Sun, 23 Sep 2012 19:50:59 -0700 (PDT)
In-Reply-To: <505C87EB020000780009D02F@nat28.tlf.novell.com>
References: <CALHMb0dTaR0NCQ1XdfrZ00NXGe0DpKXMNAG0vvZrpNMkLxti6A@mail.gmail.com>
	<505C87EB020000780009D02F@nat28.tlf.novell.com>
Date: Mon, 24 Sep 2012 10:50:59 +0800
Message-ID: <CALHMb0fMfNz6b3heCHWhOMcH5RqkpkyFwPqup6k4Eeh64yfrdg@mail.gmail.com>
From: Yaogun Wen <techno.geek.0x01@gmail.com>
To: Ian Campbell <Ian.Campbell@citrix.com>, Jan Beulich <JBeulich@suse.com>
X-Mailman-Approved-At: Mon, 24 Sep 2012 07:55:10 +0000
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] The use of evtchn_upcall_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 2012/9/21 at pm 9:24 Ian Campbell wrote:
> It is read from assembly code (entry.S) accessed via
> VCPUINFO_upcall_mask which is defined using the asm-offsets.c mechanism.
>
> local_event_delivery_is_enabled seems to be redundant these days.
Thank you for your guidance. :)
But I still have some questions, please keep reading.

On 2012/9/21 at pm 9:29 Jan Beulich wrote:
> Setting an event channel pending isn't tied to the channel being
> unmasked - in particular, for polled event channels, one would
> keep them masked permanently, yet still expect events to be
> signaled. The mask really controls whether an upcall is actually
> permitted (just like EFLAGS.IF controls whether interrupts can
> be injected).
This explanation helps me to understand the meaning of VCPUINFO_upcall_mask.
I don't know x86 assembly language, but according to your explanation,
it seems that guest which only have masked channel will still receive
the events.
But from the comment of vcpu_info struct, it says "The mask
(evtchn_upcall_mask) is read before making an event upcall to the
guest".
So, which one is correct?


-- 
Best regards,

Yao-Jing Wen

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 24 08:07:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Sep 2012 08: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 1TG3hR-0007AS-BK; Mon, 24 Sep 2012 08:07:29 +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 1TG3hQ-0007A6-MY
	for xen-devel@lists.xen.org; Mon, 24 Sep 2012 08:07:28 +0000
Received: from [85.158.143.99:60970] by server-3.bemta-4.messagelabs.com id
	E0/17-10986-FB410605; Mon, 24 Sep 2012 08:07:27 +0000
X-Env-Sender: lars.kurth.xen@gmail.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1348474046!23368681!1
X-Originating-IP: [209.85.217.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-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5160 invoked from network); 24 Sep 2012 08:07:26 -0000
Received: from mail-lb0-f173.google.com (HELO mail-lb0-f173.google.com)
	(209.85.217.173)
	by server-12.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Sep 2012 08:07:26 -0000
Received: by lbbgm13 with SMTP id gm13so7838046lbb.32
	for <multiple recipients>; Mon, 24 Sep 2012 01:07: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:content-type;
	bh=VQM2rVud5klBfZBJsYP4BZ05g1BoP8iFuZY4r7QOYIY=;
	b=gYnaJjsP+4u7B2DkjMucZjh96UMsiaqNVhgAcf/Fq1I3raUMz9qpkDylqAXNut51Qe
	4eIomwWYOAESOgG0E1h+E27W4wXp4AhOX8TwGbG3YcXijTsJMVLPBc8HrVFSyxJqPeVy
	uqcAi0V7BSP3EKK8/PRjBtxkKYk9LjczmWiUhK5wVMaTuq5kefsOkGCU6VtiZDahZZg7
	XmQ5MZu7i6R/toiLcQUa4jIKpZBIAwnTM+deNCFTTkak898O69KnYQCHs3ByrORMN5YN
	3T8IdlWNnz6faDLPYnUTaPC4zUtGF/rjgpxcOkRCOoCnmqgtKKgEZTlKUrOKDZGxpjP6
	prRw==
MIME-Version: 1.0
Received: by 10.112.26.135 with SMTP id l7mr567705lbg.84.1348474045943; Mon,
	24 Sep 2012 01:07:25 -0700 (PDT)
Received: by 10.112.120.138 with HTTP; Mon, 24 Sep 2012 01:07:25 -0700 (PDT)
Date: Mon, 24 Sep 2012 09:07:25 +0100
Message-ID: <CAOqnZH4DZTH2oWHRhKE4oiGGJmRMBWwJJXx+1+HvvOeKBtfhbw@mail.gmail.com>
From: Lars Kurth <lars.kurth.xen@gmail.com>
To: xen-devel@lists.xen.org, xen-users@lists.xen.org, xen-api@lists.xen.org, 
	xen-arm@lists.xen.org
Subject: [Xen-devel] [Reminder] Xen Document Day on IRC freenode #xendocs
	today
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============7547515804736137385=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============7547515804736137385==
Content-Type: multipart/alternative; boundary=bcaec554d4247f4f0204ca6e143b

--bcaec554d4247f4f0204ca6e143b
Content-Type: text/plain; charset=ISO-8859-1

Good Morning,
we have another document day today! More information about docs day at
http://wiki.xen.org/wiki/Xen_Document_Days
The TODO list is at http://wiki.xen.org/wiki/Xen_Document_Days/TODO
Regards
Lars

--bcaec554d4247f4f0204ca6e143b
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Good Morning,<br>we have another document day today! More information about=
 docs day at <a href=3D"http://wiki.xen.org/wiki/Xen_Document_Days">http://=
wiki.xen.org/wiki/Xen_Document_Days</a><br>The TODO list is at <a href=3D"h=
ttp://wiki.xen.org/wiki/Xen_Document_Days/TODO">http://wiki.xen.org/wiki/Xe=
n_Document_Days/TODO</a><br>
Regards<br>Lars<br>

--bcaec554d4247f4f0204ca6e143b--


--===============7547515804736137385==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============7547515804736137385==--


From xen-devel-bounces@lists.xen.org Mon Sep 24 08:07:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Sep 2012 08: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 1TG3hR-0007AS-BK; Mon, 24 Sep 2012 08:07:29 +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 1TG3hQ-0007A6-MY
	for xen-devel@lists.xen.org; Mon, 24 Sep 2012 08:07:28 +0000
Received: from [85.158.143.99:60970] by server-3.bemta-4.messagelabs.com id
	E0/17-10986-FB410605; Mon, 24 Sep 2012 08:07:27 +0000
X-Env-Sender: lars.kurth.xen@gmail.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1348474046!23368681!1
X-Originating-IP: [209.85.217.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-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5160 invoked from network); 24 Sep 2012 08:07:26 -0000
Received: from mail-lb0-f173.google.com (HELO mail-lb0-f173.google.com)
	(209.85.217.173)
	by server-12.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Sep 2012 08:07:26 -0000
Received: by lbbgm13 with SMTP id gm13so7838046lbb.32
	for <multiple recipients>; Mon, 24 Sep 2012 01:07: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:content-type;
	bh=VQM2rVud5klBfZBJsYP4BZ05g1BoP8iFuZY4r7QOYIY=;
	b=gYnaJjsP+4u7B2DkjMucZjh96UMsiaqNVhgAcf/Fq1I3raUMz9qpkDylqAXNut51Qe
	4eIomwWYOAESOgG0E1h+E27W4wXp4AhOX8TwGbG3YcXijTsJMVLPBc8HrVFSyxJqPeVy
	uqcAi0V7BSP3EKK8/PRjBtxkKYk9LjczmWiUhK5wVMaTuq5kefsOkGCU6VtiZDahZZg7
	XmQ5MZu7i6R/toiLcQUa4jIKpZBIAwnTM+deNCFTTkak898O69KnYQCHs3ByrORMN5YN
	3T8IdlWNnz6faDLPYnUTaPC4zUtGF/rjgpxcOkRCOoCnmqgtKKgEZTlKUrOKDZGxpjP6
	prRw==
MIME-Version: 1.0
Received: by 10.112.26.135 with SMTP id l7mr567705lbg.84.1348474045943; Mon,
	24 Sep 2012 01:07:25 -0700 (PDT)
Received: by 10.112.120.138 with HTTP; Mon, 24 Sep 2012 01:07:25 -0700 (PDT)
Date: Mon, 24 Sep 2012 09:07:25 +0100
Message-ID: <CAOqnZH4DZTH2oWHRhKE4oiGGJmRMBWwJJXx+1+HvvOeKBtfhbw@mail.gmail.com>
From: Lars Kurth <lars.kurth.xen@gmail.com>
To: xen-devel@lists.xen.org, xen-users@lists.xen.org, xen-api@lists.xen.org, 
	xen-arm@lists.xen.org
Subject: [Xen-devel] [Reminder] Xen Document Day on IRC freenode #xendocs
	today
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============7547515804736137385=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============7547515804736137385==
Content-Type: multipart/alternative; boundary=bcaec554d4247f4f0204ca6e143b

--bcaec554d4247f4f0204ca6e143b
Content-Type: text/plain; charset=ISO-8859-1

Good Morning,
we have another document day today! More information about docs day at
http://wiki.xen.org/wiki/Xen_Document_Days
The TODO list is at http://wiki.xen.org/wiki/Xen_Document_Days/TODO
Regards
Lars

--bcaec554d4247f4f0204ca6e143b
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Good Morning,<br>we have another document day today! More information about=
 docs day at <a href=3D"http://wiki.xen.org/wiki/Xen_Document_Days">http://=
wiki.xen.org/wiki/Xen_Document_Days</a><br>The TODO list is at <a href=3D"h=
ttp://wiki.xen.org/wiki/Xen_Document_Days/TODO">http://wiki.xen.org/wiki/Xe=
n_Document_Days/TODO</a><br>
Regards<br>Lars<br>

--bcaec554d4247f4f0204ca6e143b--


--===============7547515804736137385==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============7547515804736137385==--


From xen-devel-bounces@lists.xen.org Mon Sep 24 08:32:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Sep 2012 08:32:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TG450-0007jB-5K; Mon, 24 Sep 2012 08:31:50 +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 1TG44y-0007j2-TF
	for xen-devel@lists.xensource.com; Mon, 24 Sep 2012 08:31:49 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1348475492!10155675!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTA4NDA=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21597 invoked from network); 24 Sep 2012 08:31:34 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Sep 2012 08:31:34 -0000
X-IronPort-AV: E=Sophos;i="4.80,474,1344211200"; d="scan'208";a="14715819"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Sep 2012 08:31: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.279.1;
	Mon, 24 Sep 2012 09:31:32 +0100
Message-ID: <1348475490.3452.36.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: xen.org <ian.jackson@eu.citrix.com>, Jan Beulich <JBeulich@suse.com>
Date: Mon, 24 Sep 2012 09:31:30 +0100
In-Reply-To: <osstest-13858-mainreport@xen.org>
References: <osstest-13858-mainreport@xen.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [xen-unstable test] 13858: trouble:
 blocked/broken/pass
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2012-09-24 at 03:17 +0100, xen.org wrote:
> flight 13858 xen-unstable real [real]
> http://www.chiark.greenend.org.uk/~xensrcts/logs/13858/
> 
> Failures and problems with tests :-(
> 
> Tests which did not succeed and are blocking,
> including tests which could not be run:
>  build-amd64                   2 host-install(2)         broken REGR. vs. 13825

Jan, I guess this is most likely down to 25935:1e6e6b49b4ac "x86:
introduce MWAIT-based, ACPI-less CPU idle driver"?

Sep 24 01:35:46.025150 (XEN) ----[ Xen-4.3-unstable  x86_64  debug=y  Not tainted ]----
Sep 24 01:35:46.033069 (XEN) CPU:    1
Sep 24 01:35:46.033107 (XEN) RIP:    e008:[<0000000000000000>] ???
Sep 24 01:35:46.033155 (XEN) RFLAGS: 0000000000010046   CONTEXT: hypervisor
Sep 24 01:35:46.045069 (XEN) rax: 0000000000000008   rbx: 0000000000000001   rcx: 0000000000000003
Sep 24 01:35:46.053054 (XEN) rdx: 0000003db54eb700   rsi: 7fffffffffffffff   rdi: 0000000000000001
Sep 24 01:35:46.053115 (XEN) rbp: ffff8302357e7ee0   rsp: ffff8302357e7e58   r8:  0000000000000000
Sep 24 01:35:46.065475 (XEN) r9:  000000000000003e   r10: ffff8302357e7f18   r11: ffff8302357e7f18
Sep 24 01:35:46.073056 (XEN) r12: ffff8302357ee340   r13: ffff82c480263980   r14: ffff8302357ee3d0
Sep 24 01:35:46.073118 (XEN) r15: 0000000000000001   cr0: 000000008005003b   cr4: 00000000000026f0
Sep 24 01:35:46.085106 (XEN) cr3: 00000000bf473000   cr2: 0000000000000000
Sep 24 01:35:46.085158 (XEN) ds: 0000   es: 0000   fs: 0000   gs: 0000   ss: 0000   cs: e008
Sep 24 01:35:46.093483 (XEN) Xen stack trace from rsp=ffff8302357e7e58:
Sep 24 01:35:46.093535 (XEN)    ffff82c4801a3d05 ffff8302357eca70 0000000800000020 ffff82c4802ead60
Sep 24 01:35:46.105490 (XEN)    0000000000000001 ffff8302357e7ea0 ffff82c48016bf07 0000000000000000
Sep 24 01:35:46.113067 (XEN)    0000000000000000 ffff8302357e7ee0 fffff830fffff830 0000000000000046
Sep 24 01:35:46.121329 (XEN)    ffff8302357e7f18 ffff82c480263980 ffff8302357e7f18 0000000000000000
Sep 24 01:35:46.121391 (XEN)    0000000000000000 ffff8302357e7f10 ffff82c48015c2be 8302357dc0000fff
Sep 24 01:35:46.133072 (XEN)    0000000000000001 0000000000000001 0000000000000000 ffff8302357e7ee0
Sep 24 01:35:46.141265 (XEN)    0000000000000000 0000000000000000 0000000000000000 0000000000000000
Sep 24 01:35:46.141324 (XEN)    0000000000000000 0000000000000000 0000000000000000 0000000000000000
Sep 24 01:35:46.153074 (XEN)    0000000000000000 0000000000000000 0000000000000000 0000000000000000
Sep 24 01:35:46.161216 (XEN)    0000000000000000 0000000000000000 0000000000000000 0000000000000000
Sep 24 01:35:46.161276 (XEN)    0000000000000000 0000000000000000 0000000000000000 0000000000000000
Sep 24 01:35:46.173076 (XEN)    0000000000000000 0000000000000000 0000000000000000 0000000000000000
Sep 24 01:35:46.181134 (XEN)    0000000000000000 0000000000000001 ffff8300bf2fe000 0000003db54eb700
Sep 24 01:35:46.181195 (XEN)    0000000000000000
Sep 24 01:35:46.193060 (XEN) Xen call trace:
Sep 24 01:35:46.193101 (XEN)    [<0000000000000000>] ???
Sep 24 01:35:46.193181 (XEN)    [<ffff82c48015c2be>] idle_loop+0x6c/0x7a
Sep 24 01:35:46.193233 (XEN)    
Sep 24 01:35:46.201065 (XEN) Pagetable walk from 0000000000000000:
Sep 24 01:35:46.201114 (XEN)  L4[0x000] = 000000023b201063 ffffffffffffffff
Sep 24 01:35:46.201165 (XEN)  L3[0x000] = 000000023b200063 ffffffffffffffff
Sep 24 01:35:46.213078 (XEN)  L2[0x000] = 00000002357ff063 ffffffffffffffff 
Sep 24 01:35:46.213130 (XEN)  L1[0x000] = 0000000000000000 ffffffffffffffff
Sep 24 01:35:46.217068 (XEN) 
Sep 24 01:35:46.217102 (XEN) ****************************************
Sep 24 01:35:46.225485 (XEN) Panic on CPU 1:
Sep 24 01:35:46.225526 (XEN) FATAL PAGE FAULT
Sep 24 01:35:46.229059 (XEN) [error_code=0010]
Sep 24 01:35:46.233466 (XEN) Faulting linear address: 0000000000000000
Sep 24 01:35:46.237480 (XEN) ****************************************


>  build-amd64-oldkern           2 host-install(2)         broken REGR. vs. 13825
>  build-amd64-pvops             2 host-install(2)         broken REGR. vs. 13825
> 
> Tests which did not succeed, but are not blocking:
>  test-amd64-i386-rhel6hvm-amd  1 xen-build-check(1)           blocked  n/a
>  test-amd64-i386-qemuu-rhel6hvm-amd  1 xen-build-check(1)           blocked n/a
>  test-amd64-amd64-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
>  test-amd64-amd64-xl-sedf-pin  1 xen-build-check(1)           blocked  n/a
>  test-amd64-i386-rhel6hvm-intel  1 xen-build-check(1)           blocked  n/a
>  test-amd64-i386-xend-winxpsp3  1 xen-build-check(1)           blocked  n/a
>  test-amd64-i386-win           1 xen-build-check(1)           blocked  n/a
>  test-amd64-amd64-xl-sedf      1 xen-build-check(1)           blocked  n/a
>  test-amd64-amd64-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-amd64-i386-xl-multivcpu  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-qemuu-rhel6hvm-intel  1 xen-build-check(1)         blocked n/a
>  test-amd64-i386-pv            1 xen-build-check(1)           blocked  n/a
>  test-amd64-amd64-xl-pcipt-intel  1 xen-build-check(1)           blocked  n/a
>  test-amd64-i386-win-vcpus1    1 xen-build-check(1)           blocked  n/a
>  test-amd64-i386-xl-winxpsp3-vcpus1  1 xen-build-check(1)           blocked n/a
>  test-amd64-i386-xl            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-win7-amd64  1 xen-build-check(1)           blocked  n/a
>  test-amd64-amd64-win          1 xen-build-check(1)           blocked  n/a
>  test-amd64-amd64-xl-qemuu-win7-amd64  1 xen-build-check(1)         blocked n/a
>  test-amd64-amd64-xl-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-pair         1 xen-build-check(1)           blocked  n/a
>  test-amd64-i386-pair          1 xen-build-check(1)           blocked  n/a
> 
> version targeted for testing:
>  xen                  8f658b463b78
> baseline version:
>  xen                  d364becfb083
> 
> ------------------------------------------------------------
> People who touched revisions under test:
>   Jan Beulich <jbeulich@suse.com>
>   Keir Fraser <keir@xen.org>
> ------------------------------------------------------------
> 
> jobs:
>  build-amd64                                                  broken  
>  build-i386                                                   pass    
>  build-amd64-oldkern                                          broken  
>  build-i386-oldkern                                           pass    
>  build-amd64-pvops                                            broken  
>  build-i386-pvops                                             pass    
>  test-amd64-amd64-xl                                          blocked 
>  test-amd64-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-amd64-amd64-xl-sedf-pin                                 blocked 
>  test-amd64-amd64-pv                                          blocked 
>  test-amd64-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-amd64-amd64-xl-win                                      blocked 
>  test-amd64-amd64-xl-qemuu-winxpsp3                           blocked 
>  test-amd64-i386-xend-winxpsp3                                blocked 
>  test-amd64-amd64-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.
> 
> ------------------------------------------------------------
> changeset:   25938:8f658b463b78
> tag:         tip
> user:        Jan Beulich <jbeulich@suse.com>
> date:        Fri Sep 21 17:02:46 2012 +0200
>     
>     x86: enable VIA CPU support
>     
>     Newer VIA CPUs have both 64-bit and VMX support. Enable them to be
>     recognized for these purposes, at once stripping off any 32-bit CPU
>     only bits from the respective CPU support file, and adding 64-bit ones
>     found in recent Linux.
>     
>     This particularly implies untying the VMX == Intel assumption in a few
>     places.
>     
>     Signed-off-by: Jan Beulich <jbeulich@suse.com>
>     Acked-by: Keir Fraser <keir@xen.org>
>     
>     
> changeset:   25937:32187301ecc5
> user:        Jan Beulich <jbeulich@suse.com>
> date:        Fri Sep 21 15:20:21 2012 +0200
>     
>     x86: eliminate code affecting only 64-bit-incapable CPUs
>     
>     Signed-off-by: Jan Beulich <jbeulich@suse.com>
>     Acked-by: Keir Fraser <keir@xen.org>
>     
>     
> changeset:   25936:c8873f13cec3
> user:        Jan Beulich <jbeulich@suse.com>
> date:        Fri Sep 21 14:25:12 2012 +0200
>     
>     printk: prefer %#x et at over 0x%x
>     
>     Performance is not an issue with printk(), so let the function do
>     minimally more work and instead save a byte per affected format
>     specifier.
>     
>     Signed-off-by: Jan Beulich <jbeulich@suse.com>
>     Acked-by: Keir Fraser <keir@xen.org>
>     
>     
> changeset:   25935:1e6e6b49b4ac
> user:        Jan Beulich <jbeulich@suse.com>
> date:        Fri Sep 21 13:47:18 2012 +0200
>     
>     x86: introduce MWAIT-based, ACPI-less CPU idle driver
>     
>     This is a port of Linux'es intel-idle driver serving the same purpose.
>     
>     Signed-off-by: Jan Beulich <jbeulich@suse.com>
>     Acked-by: Keir Fraser <keir@xen.org>
>     
>     
> changeset:   25934:8eab91903e71
> user:        Jan Beulich <jbeulich@suse.com>
> date:        Fri Sep 21 13:45:08 2012 +0200
>     
>     cpuidle: remove unused latency_ticks member
>     
>     ... and code used only for initializing it.
>     
>     Signed-off-by: Jan Beulich <jbeulich@suse.com>
>     Acked-by: Keir Fraser <keir@xen.org>
>     
>     
> changeset:   25933:d364becfb083
> user:        Jan Beulich <jbeulich@suse.com>
> date:        Thu Sep 20 13:31:19 2012 +0200
>     
>     introduce guest_handle_for_field()
>     
>     This helper turns a field of a GUEST_HANDLE in a GUEST_HANDLE.
>     
>     Signed-off-by: Jan Beulich <jbeulich@suse.com>
>     
>     
> (qemu changes not included)
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 24 08:32:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Sep 2012 08:32:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TG450-0007jB-5K; Mon, 24 Sep 2012 08:31:50 +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 1TG44y-0007j2-TF
	for xen-devel@lists.xensource.com; Mon, 24 Sep 2012 08:31:49 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1348475492!10155675!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTA4NDA=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21597 invoked from network); 24 Sep 2012 08:31:34 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Sep 2012 08:31:34 -0000
X-IronPort-AV: E=Sophos;i="4.80,474,1344211200"; d="scan'208";a="14715819"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Sep 2012 08:31: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.279.1;
	Mon, 24 Sep 2012 09:31:32 +0100
Message-ID: <1348475490.3452.36.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: xen.org <ian.jackson@eu.citrix.com>, Jan Beulich <JBeulich@suse.com>
Date: Mon, 24 Sep 2012 09:31:30 +0100
In-Reply-To: <osstest-13858-mainreport@xen.org>
References: <osstest-13858-mainreport@xen.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [xen-unstable test] 13858: trouble:
 blocked/broken/pass
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2012-09-24 at 03:17 +0100, xen.org wrote:
> flight 13858 xen-unstable real [real]
> http://www.chiark.greenend.org.uk/~xensrcts/logs/13858/
> 
> Failures and problems with tests :-(
> 
> Tests which did not succeed and are blocking,
> including tests which could not be run:
>  build-amd64                   2 host-install(2)         broken REGR. vs. 13825

Jan, I guess this is most likely down to 25935:1e6e6b49b4ac "x86:
introduce MWAIT-based, ACPI-less CPU idle driver"?

Sep 24 01:35:46.025150 (XEN) ----[ Xen-4.3-unstable  x86_64  debug=y  Not tainted ]----
Sep 24 01:35:46.033069 (XEN) CPU:    1
Sep 24 01:35:46.033107 (XEN) RIP:    e008:[<0000000000000000>] ???
Sep 24 01:35:46.033155 (XEN) RFLAGS: 0000000000010046   CONTEXT: hypervisor
Sep 24 01:35:46.045069 (XEN) rax: 0000000000000008   rbx: 0000000000000001   rcx: 0000000000000003
Sep 24 01:35:46.053054 (XEN) rdx: 0000003db54eb700   rsi: 7fffffffffffffff   rdi: 0000000000000001
Sep 24 01:35:46.053115 (XEN) rbp: ffff8302357e7ee0   rsp: ffff8302357e7e58   r8:  0000000000000000
Sep 24 01:35:46.065475 (XEN) r9:  000000000000003e   r10: ffff8302357e7f18   r11: ffff8302357e7f18
Sep 24 01:35:46.073056 (XEN) r12: ffff8302357ee340   r13: ffff82c480263980   r14: ffff8302357ee3d0
Sep 24 01:35:46.073118 (XEN) r15: 0000000000000001   cr0: 000000008005003b   cr4: 00000000000026f0
Sep 24 01:35:46.085106 (XEN) cr3: 00000000bf473000   cr2: 0000000000000000
Sep 24 01:35:46.085158 (XEN) ds: 0000   es: 0000   fs: 0000   gs: 0000   ss: 0000   cs: e008
Sep 24 01:35:46.093483 (XEN) Xen stack trace from rsp=ffff8302357e7e58:
Sep 24 01:35:46.093535 (XEN)    ffff82c4801a3d05 ffff8302357eca70 0000000800000020 ffff82c4802ead60
Sep 24 01:35:46.105490 (XEN)    0000000000000001 ffff8302357e7ea0 ffff82c48016bf07 0000000000000000
Sep 24 01:35:46.113067 (XEN)    0000000000000000 ffff8302357e7ee0 fffff830fffff830 0000000000000046
Sep 24 01:35:46.121329 (XEN)    ffff8302357e7f18 ffff82c480263980 ffff8302357e7f18 0000000000000000
Sep 24 01:35:46.121391 (XEN)    0000000000000000 ffff8302357e7f10 ffff82c48015c2be 8302357dc0000fff
Sep 24 01:35:46.133072 (XEN)    0000000000000001 0000000000000001 0000000000000000 ffff8302357e7ee0
Sep 24 01:35:46.141265 (XEN)    0000000000000000 0000000000000000 0000000000000000 0000000000000000
Sep 24 01:35:46.141324 (XEN)    0000000000000000 0000000000000000 0000000000000000 0000000000000000
Sep 24 01:35:46.153074 (XEN)    0000000000000000 0000000000000000 0000000000000000 0000000000000000
Sep 24 01:35:46.161216 (XEN)    0000000000000000 0000000000000000 0000000000000000 0000000000000000
Sep 24 01:35:46.161276 (XEN)    0000000000000000 0000000000000000 0000000000000000 0000000000000000
Sep 24 01:35:46.173076 (XEN)    0000000000000000 0000000000000000 0000000000000000 0000000000000000
Sep 24 01:35:46.181134 (XEN)    0000000000000000 0000000000000001 ffff8300bf2fe000 0000003db54eb700
Sep 24 01:35:46.181195 (XEN)    0000000000000000
Sep 24 01:35:46.193060 (XEN) Xen call trace:
Sep 24 01:35:46.193101 (XEN)    [<0000000000000000>] ???
Sep 24 01:35:46.193181 (XEN)    [<ffff82c48015c2be>] idle_loop+0x6c/0x7a
Sep 24 01:35:46.193233 (XEN)    
Sep 24 01:35:46.201065 (XEN) Pagetable walk from 0000000000000000:
Sep 24 01:35:46.201114 (XEN)  L4[0x000] = 000000023b201063 ffffffffffffffff
Sep 24 01:35:46.201165 (XEN)  L3[0x000] = 000000023b200063 ffffffffffffffff
Sep 24 01:35:46.213078 (XEN)  L2[0x000] = 00000002357ff063 ffffffffffffffff 
Sep 24 01:35:46.213130 (XEN)  L1[0x000] = 0000000000000000 ffffffffffffffff
Sep 24 01:35:46.217068 (XEN) 
Sep 24 01:35:46.217102 (XEN) ****************************************
Sep 24 01:35:46.225485 (XEN) Panic on CPU 1:
Sep 24 01:35:46.225526 (XEN) FATAL PAGE FAULT
Sep 24 01:35:46.229059 (XEN) [error_code=0010]
Sep 24 01:35:46.233466 (XEN) Faulting linear address: 0000000000000000
Sep 24 01:35:46.237480 (XEN) ****************************************


>  build-amd64-oldkern           2 host-install(2)         broken REGR. vs. 13825
>  build-amd64-pvops             2 host-install(2)         broken REGR. vs. 13825
> 
> Tests which did not succeed, but are not blocking:
>  test-amd64-i386-rhel6hvm-amd  1 xen-build-check(1)           blocked  n/a
>  test-amd64-i386-qemuu-rhel6hvm-amd  1 xen-build-check(1)           blocked n/a
>  test-amd64-amd64-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
>  test-amd64-amd64-xl-sedf-pin  1 xen-build-check(1)           blocked  n/a
>  test-amd64-i386-rhel6hvm-intel  1 xen-build-check(1)           blocked  n/a
>  test-amd64-i386-xend-winxpsp3  1 xen-build-check(1)           blocked  n/a
>  test-amd64-i386-win           1 xen-build-check(1)           blocked  n/a
>  test-amd64-amd64-xl-sedf      1 xen-build-check(1)           blocked  n/a
>  test-amd64-amd64-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-amd64-i386-xl-multivcpu  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-qemuu-rhel6hvm-intel  1 xen-build-check(1)         blocked n/a
>  test-amd64-i386-pv            1 xen-build-check(1)           blocked  n/a
>  test-amd64-amd64-xl-pcipt-intel  1 xen-build-check(1)           blocked  n/a
>  test-amd64-i386-win-vcpus1    1 xen-build-check(1)           blocked  n/a
>  test-amd64-i386-xl-winxpsp3-vcpus1  1 xen-build-check(1)           blocked n/a
>  test-amd64-i386-xl            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-win7-amd64  1 xen-build-check(1)           blocked  n/a
>  test-amd64-amd64-win          1 xen-build-check(1)           blocked  n/a
>  test-amd64-amd64-xl-qemuu-win7-amd64  1 xen-build-check(1)         blocked n/a
>  test-amd64-amd64-xl-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-pair         1 xen-build-check(1)           blocked  n/a
>  test-amd64-i386-pair          1 xen-build-check(1)           blocked  n/a
> 
> version targeted for testing:
>  xen                  8f658b463b78
> baseline version:
>  xen                  d364becfb083
> 
> ------------------------------------------------------------
> People who touched revisions under test:
>   Jan Beulich <jbeulich@suse.com>
>   Keir Fraser <keir@xen.org>
> ------------------------------------------------------------
> 
> jobs:
>  build-amd64                                                  broken  
>  build-i386                                                   pass    
>  build-amd64-oldkern                                          broken  
>  build-i386-oldkern                                           pass    
>  build-amd64-pvops                                            broken  
>  build-i386-pvops                                             pass    
>  test-amd64-amd64-xl                                          blocked 
>  test-amd64-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-amd64-amd64-xl-sedf-pin                                 blocked 
>  test-amd64-amd64-pv                                          blocked 
>  test-amd64-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-amd64-amd64-xl-win                                      blocked 
>  test-amd64-amd64-xl-qemuu-winxpsp3                           blocked 
>  test-amd64-i386-xend-winxpsp3                                blocked 
>  test-amd64-amd64-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.
> 
> ------------------------------------------------------------
> changeset:   25938:8f658b463b78
> tag:         tip
> user:        Jan Beulich <jbeulich@suse.com>
> date:        Fri Sep 21 17:02:46 2012 +0200
>     
>     x86: enable VIA CPU support
>     
>     Newer VIA CPUs have both 64-bit and VMX support. Enable them to be
>     recognized for these purposes, at once stripping off any 32-bit CPU
>     only bits from the respective CPU support file, and adding 64-bit ones
>     found in recent Linux.
>     
>     This particularly implies untying the VMX == Intel assumption in a few
>     places.
>     
>     Signed-off-by: Jan Beulich <jbeulich@suse.com>
>     Acked-by: Keir Fraser <keir@xen.org>
>     
>     
> changeset:   25937:32187301ecc5
> user:        Jan Beulich <jbeulich@suse.com>
> date:        Fri Sep 21 15:20:21 2012 +0200
>     
>     x86: eliminate code affecting only 64-bit-incapable CPUs
>     
>     Signed-off-by: Jan Beulich <jbeulich@suse.com>
>     Acked-by: Keir Fraser <keir@xen.org>
>     
>     
> changeset:   25936:c8873f13cec3
> user:        Jan Beulich <jbeulich@suse.com>
> date:        Fri Sep 21 14:25:12 2012 +0200
>     
>     printk: prefer %#x et at over 0x%x
>     
>     Performance is not an issue with printk(), so let the function do
>     minimally more work and instead save a byte per affected format
>     specifier.
>     
>     Signed-off-by: Jan Beulich <jbeulich@suse.com>
>     Acked-by: Keir Fraser <keir@xen.org>
>     
>     
> changeset:   25935:1e6e6b49b4ac
> user:        Jan Beulich <jbeulich@suse.com>
> date:        Fri Sep 21 13:47:18 2012 +0200
>     
>     x86: introduce MWAIT-based, ACPI-less CPU idle driver
>     
>     This is a port of Linux'es intel-idle driver serving the same purpose.
>     
>     Signed-off-by: Jan Beulich <jbeulich@suse.com>
>     Acked-by: Keir Fraser <keir@xen.org>
>     
>     
> changeset:   25934:8eab91903e71
> user:        Jan Beulich <jbeulich@suse.com>
> date:        Fri Sep 21 13:45:08 2012 +0200
>     
>     cpuidle: remove unused latency_ticks member
>     
>     ... and code used only for initializing it.
>     
>     Signed-off-by: Jan Beulich <jbeulich@suse.com>
>     Acked-by: Keir Fraser <keir@xen.org>
>     
>     
> changeset:   25933:d364becfb083
> user:        Jan Beulich <jbeulich@suse.com>
> date:        Thu Sep 20 13:31:19 2012 +0200
>     
>     introduce guest_handle_for_field()
>     
>     This helper turns a field of a GUEST_HANDLE in a GUEST_HANDLE.
>     
>     Signed-off-by: Jan Beulich <jbeulich@suse.com>
>     
>     
> (qemu changes not included)
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 24 08:39:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Sep 2012 08: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 1TG4Bk-0008B2-8t; Mon, 24 Sep 2012 08:38:48 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <linux@eikelenboom.it>) id 1TG4Bg-0008Aa-Tv
	for xen-devel@lists.xensource.com; Mon, 24 Sep 2012 08:38:47 +0000
Received: from [85.158.138.51:33415] by server-9.bemta-3.messagelabs.com id
	F5/E2-15390-41C10605; Mon, 24 Sep 2012 08:38:44 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-14.tower-174.messagelabs.com!1348475917!25377149!1
X-Originating-IP: [188.40.164.121]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15970 invoked from network); 24 Sep 2012 08:38:37 -0000
Received: from static.121.164.40.188.clients.your-server.de (HELO
	smtp.eikelenboom.it) (188.40.164.121)
	by server-14.tower-174.messagelabs.com with AES256-SHA encrypted SMTP;
	24 Sep 2012 08:38:37 -0000
Received: from 132-64-ftth.onsneteindhoven.nl ([88.159.64.132]:50420
	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 1TG4CI-0002ri-2W; Mon, 24 Sep 2012 10:39:22 +0200
Date: Mon, 24 Sep 2012 10:38:35 +0200
From: Sander Eikelenboom <linux@eikelenboom.it>
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <74647167.20120924103835@eikelenboom.it>
To: Wei Wang <wei.wang2@amd.com>
In-Reply-To: <5049B650.4080101@amd.com>
References: <504764E2.4000809@amd.com>
	<326589347.20120906005936@eikelenboom.it>
	<5048A603.3070207@amd.com>
	<483486315.20120906155001@eikelenboom.it>
	<5048BB29.4040900@amd.com>
	<488803362.20120907093241@eikelenboom.it>
	<5049B650.4080101@amd.com>
MIME-Version: 1.0
Content-Type: multipart/mixed;
 boundary="----------0E41640F726FFA493"
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH] amd iommu: Dump flags of IO page faults
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

------------0E41640F726FFA493
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit


Friday, September 7, 2012, 10:54:40 AM, you wrote:

> On 09/07/2012 09:32 AM, Sander Eikelenboom wrote:
>>
>> Thursday, September 6, 2012, 5:03:05 PM, you wrote:
>>
>>> On 09/06/2012 03:50 PM, Sander Eikelenboom wrote:
>>>>
>>>> Thursday, September 6, 2012, 3:32:51 PM, you wrote:
>>>>
>>>>> On 09/06/2012 12:59 AM, Sander Eikelenboom wrote:
>>>>>>
>>>>>> Wednesday, September 5, 2012, 4:42:42 PM, you wrote:
>>>>>>
>>>>>>> Hi Jan,
>>>>>>> Attached patch dumps io page fault flags. The flags show the reason of
>>>>>>> the fault and tell us if this is an unmapped interrupt fault or a DMA fault.
>>>>>>
>>>>>>> Thanks,
>>>>>>> Wei
>>>>>>
>>>>>>> signed-off-by: Wei Wang<wei.wang2@amd.com>
>>>>>>
>>>>>>
>>>>>> I have applied the patch and the flags seem to differ between the faults:
>>>>>>
>>>>>> AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0a06, fault address = 0xc2c2c2c0, flags = 0x000
>>>>>> (XEN) [2012-09-05 20:54:16] AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0a06, fault address = 0xc2c2c2c0, flags = 0x000
>>>>>> (XEN) [2012-09-05 20:54:16] AMD-Vi: IO_PAGE_FAULT: domain = 14, device id = 0x0700, fault address = 0xa8d339e0, flags = 0x020
>>>>>> (XEN) [2012-09-05 20:54:16] AMD-Vi: IO_PAGE_FAULT: domain = 14, device id = 0x0700, fault address = 0xa8d33a40, flags = 0x020
>>>>
>>>>> OK, so they are not interrupt requests. I guess further information from
>>>>> your system would be helpful to debug this issue:
>>>>> 1) xl info
>>>>> 2) xl list
>>>>> 3) lscpi -vvv (NOTE: not in dom0 but in your guest)
>>>>> 4) cat /proc/iomem (in both dom0 and your hvm guest)
>>>>
>>>> dom14 is not a HVM guest,it's a PV guest.
>>
>>> Ah, I see. PV guest is quite different than hvm, it does use p2m tables
>>> as io page tables. So no-sharept option does not work in this case. PV
>>> guests always use separated io page tables. There might be some
>>> incorrect mappings on the page tables. I will check this on my side.
>>
>> I have reverted the machine to xen-4.1.4-pre (changeset 23353) and kept everything else the same.
>> I haven't seen any IO PAGE FAULTS after that.
>>
>> I did spot some differences in the output from lspci between xen 4.1 and 4.2, related to MSI enabled or not for the IOMMU device.
>> Have attached the xl/xm dmesg and lspci from booting with both versions.
>>
>> lspci:
>>
>> 00:00.2 Generic system peripheral [0806]: ATI Technologies Inc RD990 I/O Memory Management Unit (IOMMU) [1002:5a23]
>>          Subsystem: ATI Technologies Inc RD990 I/O Memory Management Unit (IOMMU) [1002:5a23]
>>          Control: I/O- Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
>>          Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast>TAbort-<TAbort-<MAbort->SERR-<PERR- INTx-
>>          Latency: 0
>>          Interrupt: pin A routed to IRQ 10
>>          Capabilities: [40] Secure device<?>
>> 4.1:    Capabilities: [54] MSI: Enable- Count=1/1 Maskable- 64bit+

> Eh... That is interesting. So which dom0 are you using?  There is a c/s 
> in 4.2 to prevent recent dom0 to disable iommu interrupt (changeset 
> 25492:61844569a432) Otherwise, iommu cannot send any events including IO 
> PAGE faults. You could try to revert dom0 to an old version like 2.6 
> pv_ops to see if you really have no io page faults on 4.1

Ok i finally got the time to do some more testing, tested 4.2 around that changeset, and made a copy of the guest using HVM instead of PV.

The results:
- On xen-4.1.* and a 3.6-rc6 kernel (dom0 and domU):  the video device passed through works fine, both in a HVM as a PV guest, i don't see IO page faults getting reported.
- On xen-4.2 changeset <  25492 and a 3.6-rc6 kernel (dom0 and domU):  the video device passed through works fine, both in a HVM as a PV guest, i don't see IO page faults getting reported.
- On xen-4.2 changeset >  25492 and a 3.6-rc6 kernel (dom0 and domU): the video device passed through works fine for a short while (around 5 to 10 minutes) in a PV guest, after that IO page faults get reported and the video freezes, i don't see any errors in the guest though.
- On xen-unstable tip and a 3.6-rc6 kernel (dom0 and domU):
                                                      PV:  the video device passed through works fine for a short while (around 5 to 10 minutes), after that IO page faults get reported and the video freezes, i don't see any errors in the guest though.
                                                      HVM: the video device passed through doesn't work from the start:
                                                                     - The device is there according to lspci
                                                                     - The video application start fine, but delivers a green image, so the device is not working properly. I don't see IO page faults though.

Attached are (all with xen-unstable tip and the guest as HVM (domain 15):
- xl dmesg
- Patch which adds some more info, but all values reported seem to be zero (see xl dmesg)
- lspci dom0
- lspci HVM guest




>> 4.2:    Capabilities: [54] MSI: Enable+ Count=1/1 Maskable- 64bit+
>>                  Address: 00000000fee0100c  Data: 4128
>>          Capabilities: [64] HyperTransport: MSI Mapping Enable+ Fixed+
>>
>> Although it seems enabled, shouldn't the IRQ number used be much higher than 10 for MSI interrupts ?

> The IRQ number is fine. MSI vector is stored at  Data: 4128

>>
>> There is another difference in the bridge device that's in front of the  0a:00.6 device that faults before the kernel is even booted.
>>
>> 00:03.0 PCI bridge [0604]: ATI Technologies Inc RD890 PCI to PCI bridge (PCI express gpp port C) [1002:5a17] (prog-if 00 [Normal decode])
>>          Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx+
>> 4.1:    Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast>TAbort-<TAbort-<MAbort->SERR-<PERR- INTx-
>> 4.2:    Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast>TAbort-<TAbort+<MAbort->SERR-<PERR- INTx-
>>          Latency: 0, Cache Line Size: 64 bytes
>>          Bus: primary=00, secondary=0a, subordinate=0a, sec-latency=0
>>          I/O behind bridge: 0000f000-00000fff
>>          Memory behind bridge: f9f00000-f9ffffff
>>          Prefetchable memory behind bridge: 00000000fff00000-00000000000fffff
>> 4.1:    Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast>TAbort-<TAbort-<MAbort-<SERR-<PERR-
>> 4.2:    Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast>TAbort+<TAbort-<MAbort-<SERR-<PERR-
>>          BridgeCtl: Parity+ SERR+ NoISA+ VGA- MAbort->Reset- FastB2B-
>>                  PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
>>          Capabilities: [50] Power Management version 3
>>                  Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
>>                  Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
>>          Capabilities: [58] Express (v2) Root Port (Slot+), MSI 00
>>                  DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s<64ns, L1<1us
>>                          ExtTag+ RBE+ FLReset-
>>                  DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
>>                          RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+
>>                          MaxPayload 128 bytes, MaxReadReq 128 bytes
>>                  DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr- TransPend-
>>                  LnkCap: Port #1, Speed 5GT/s, Width x8, ASPM L0s L1, Latency L0<1us, L1<8us
>>                          ClockPM- Surprise- LLActRep+ BwNot+
>>                  LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommClk-
>>                          ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
>>                  LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive+ BWMgmt+ ABWMgmt-
>>                  SltCap: AttnBtn- PwrCtrl- MRL- AttnInd- PwrInd- HotPlug- Surprise-
>>                          Slot #3, PowerLimit 10.000W; Interlock- NoCompl+
>>                  SltCtl: Enable: AttnBtn- PwrFlt- MRL- PresDet- CmdCplt- HPIrq- LinkChg-
>>                          Control: AttnInd Unknown, PwrInd Unknown, Power- Interlock-
>>                  SltSta: Status: AttnBtn- PowerFlt- MRL- CmdCplt- PresDet+ Interlock-
>>                          Changed: MRL- PresDet+ LinkState+

> The probably because of the IO_PAGE_FAULT.

> Thanks,
> Wei

>> serveerstertje:~# lspci -t
>> -[0000:00]-+-00.0
>>             +-00.2
>>             +-02.0-[0b]----00.0
>>             +-03.0-[0a]--+-00.0
>>             |            +-00.1
>>             |            +-00.2
>>             |            +-00.3
>>             |            +-00.4
>>             |            +-00.5
>>             |            +-00.6
>>             |            \-00.7
>>             +-05.0-[09]----00.0
>>             +-06.0-[08]----00.0
>>             +-0a.0-[07]----00.0
>>             +-0b.0-[06]--+-00.0
>>             |            \-00.1
>>             +-0c.0-[05]----00.0
>>             +-0d.0-[04]--+-00.0
>>             |            +-00.1
>>             |            +-00.2
>>             |            +-00.3
>>             |            +-00.4
>>             |            +-00.5
>>             |            +-00.6
>>             |            \-00.7
>>             +-11.0
>>             +-12.0
>>             +-12.2
>>             +-13.0
>>             +-13.2
>>             +-14.0
>>             +-14.3
>>             +-14.4-[03]----06.0
>>             +-14.5
>>             +-15.0-[02]--
>>             +-16.0
>>             +-16.2
>>             +-18.0
>>             +-18.1
>>             +-18.2
>>             +-18.3
>>             \-18.4
>>
>>
>>
>>
>>
>>> Thanks,
>>> Wei
>>
>>>> I will try to make a complete package, and try with one pv domain only where the devices are being passed through just to simplify the setup.
>>>>
>>>>
>>>>> * I would also like to know the symptoms of device 0x0700 when IO_PF
>>>>> happened. Did it stop working?
>>>>
>>>> Yes it stops working, the video capture just freezes, but the driver doesn't bail out.
>>>> For the USB controller (0x0a06) it starts to give errors for usbdev_open in the guest.
>>>>
>>>>> (BTW: I copied a few options from your boot cmd line and it worked with
>>>>> my RD890 system
>>>>
>>>>> dom0_mem=1024M,max:1024M loglvl=all loglvl_guest=all console_timestamps
>>>>> cpuidle cpufreq=xen noreboot debug lapic=debug apic_verbosity=debug
>>>>> apic=debug iommu=on,verbose,debug,no-sharept
>>>>
>>>>> * so, what OEM board you have?)
>>>>
>>>> MSI 890FXA-GD70
>>>>
>>>>> Also from your log, these lines looks very strange:
>>>>
>>>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>>>>> read-only memory page. gfn=0xd5, mfn=0xa4a11
>>>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>>>>> read-only memory page. gfn=0xd7, mfn=0xa4a0f
>>>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>>>>> read-only memory page. gfn=0xd9, mfn=0xa4a0d
>>>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>>>>> read-only memory page. gfn=0xdb, mfn=0xa4a0b
>>>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>>>>> read-only memory page. gfn=0xdd, mfn=0xa4a09
>>>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>>>>> read-only memory page. gfn=0xdf, mfn=0xa4a07
>>>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>>>>> read-only memory page. gfn=0xe1, mfn=0xa4a05
>>>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>>>>> read-only memory page. gfn=0xe3, mfn=0xa4a03
>>>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>>>>> read-only memory page. gfn=0xe5, mfn=0xa4a01
>>>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>>>>> read-only memory page. gfn=0xe7, mfn=0xa463f
>>>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>>>>> read-only memory page. gfn=0xe9, mfn=0xa463d
>>>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>>>>> read-only memory page. gfn=0xeb, mfn=0xa463b
>>>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>>>>> read-only memory page. gfn=0xed, mfn=0xa4639
>>>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>>>>> read-only memory page. gfn=0xef, mfn=0xa4637
>>>>> (XEN) [2012-09-04 16:13:56] AMD-Vi: IO_PAGE_FAULT: domain = 0, device id
>>>>> = 0x0a06, fault address = 0xc2c2c2c0
>>>>> (XEN) [2012-09-04 16:13:56] AMD-Vi: IO_PAGE_FAULT: domain = 14, device
>>>>> id = 0x0700, fault address = 0xa90f8300
>>>>> (XEN) [2012-09-04 16:13:56] AMD-Vi: IO_PAGE_FAULT: domain = 14, device
>>>>> id = 0x0700, fault address = 0xa90f8340
>>>>> (XEN) [2012-09-04 16:13:56] AMD-Vi: IO_PAGE_FAULT: domain = 14, device
>>>>> id = 0x0700, fault address = 0xa90f8380
>>>>> (XEN) [2012-09-04 16:13:56] AMD-Vi: IO_PAGE_FAULT: domain = 14, device
>>>>> id = 0x0700, fault address = 0xa90f83c0
>>>>
>>>>> * they are just followed by the IO PAGE fault. Do you know where are
>>>>> they from? Your video card driver maybe?
>>>>
>>>>    From a HVM domain with a old (3.0.3) kernel, but the faults also occur without this domain being started.
>>>>
>>>>
>>>>> Thanks,
>>>>> Wei
>>>>
>>>>
>>>>>> Complete xl dmesg and lspci -vvvknn attached.
>>>>>>
>>>>>> Thx
>>>>>>
>>>>>> --
>>>>>> Sander
>>>>
>>>>
>>>>
>>>>
>>>>
>>
>>



------------0E41640F726FFA493
Content-Type: text/plain;
 name="lspci-dom0.txt"
Content-transfer-encoding: base64
Content-Disposition: attachment;
 filename="lspci-dom0.txt"

MDA6MDAuMCBIb3N0IGJyaWRnZSBbMDYwMF06IEFUSSBUZWNobm9sb2dpZXMgSW5jIFJEODkw
IE5vcnRoYnJpZGdlIG9ubHkgc2luZ2xlIHNsb3QgUENJLWUgR0ZYIEh5ZHJhIHBhcnQgWzEw
MDI6NWExMV0gKHJldiAwMikNCglTdWJzeXN0ZW06IEFUSSBUZWNobm9sb2dpZXMgSW5jIFJE
ODkwIE5vcnRoYnJpZGdlIG9ubHkgc2luZ2xlIHNsb3QgUENJLWUgR0ZYIEh5ZHJhIHBhcnQg
WzEwMDI6NWExMV0NCglDb250cm9sOiBJL08tIE1lbSsgQnVzTWFzdGVyLSBTcGVjQ3ljbGUt
IE1lbVdJTlYtIFZHQVNub29wLSBQYXJFcnItIFN0ZXBwaW5nLSBTRVJSLSBGYXN0QjJCLSBE
aXNJTlR4LQ0KCVN0YXR1czogQ2FwKyA2Nk1Iei0gVURGLSBGYXN0QjJCLSBQYXJFcnItIERF
VlNFTD1mYXN0ID5UQWJvcnQtIDxUQWJvcnQtIDxNQWJvcnQrID5TRVJSLSA8UEVSUi0gSU5U
eC0NCglDYXBhYmlsaXRpZXM6IFtmMF0gSHlwZXJUcmFuc3BvcnQ6IE1TSSBNYXBwaW5nIEVu
YWJsZSsgRml4ZWQrDQoJQ2FwYWJpbGl0aWVzOiBbYzRdIEh5cGVyVHJhbnNwb3J0OiBTbGF2
ZSBvciBQcmltYXJ5IEludGVyZmFjZQ0KCQlDb21tYW5kOiBCYXNlVW5pdElEPTAgVW5pdENu
dD0yMCBNYXN0SG9zdC0gRGVmRGlyLSBEVUwtDQoJCUxpbmsgQ29udHJvbCAwOiBDRmxFLSBD
U1QtIENGRS0gPExrRmFpbC0gSW5pdCsgRU9DLSBUWE8tIDxDUkNFcnI9MCBJc29jRW4tIExT
RW4tIEV4dENUTC0gNjRiLQ0KCQlMaW5rIENvbmZpZyAwOiBNTFdJPTE2Yml0IER3RmNJbi0g
TUxXTz0xNmJpdCBEd0ZjT3V0LSBMV0k9MTZiaXQgRHdGY0luRW4tIExXTz0xNmJpdCBEd0Zj
T3V0RW4tDQoJCUxpbmsgQ29udHJvbCAxOiBDRmxFLSBDU1QtIENGRS0gPExrRmFpbCsgSW5p
dC0gRU9DKyBUWE8rIDxDUkNFcnI9MCBJc29jRW4tIExTRW4tIEV4dENUTC0gNjRiLQ0KCQlM
aW5rIENvbmZpZyAxOiBNTFdJPThiaXQgRHdGY0luLSBNTFdPPThiaXQgRHdGY091dC0gTFdJ
PThiaXQgRHdGY0luRW4tIExXTz04Yml0IER3RmNPdXRFbi0NCgkJUmV2aXNpb24gSUQ6IDMu
MDANCgkJTGluayBGcmVxdWVuY3kgMDogW2JdDQoJCUxpbmsgRXJyb3IgMDogPFByb3QtIDxP
dmZsLSA8RU9DLSBDVExUbS0NCgkJTGluayBGcmVxdWVuY3kgQ2FwYWJpbGl0eSAwOiAyMDBN
SHorIDMwME1Iei0gNDAwTUh6KyA1MDBNSHotIDYwME1IeisgODAwTUh6KyAxLjBHSHorIDEu
MkdIeisgMS40R0h6LSAxLjZHSHotIFZlbmQtDQoJCUZlYXR1cmUgQ2FwYWJpbGl0eTogSXNv
Y0ZDKyBMRFRTVE9QKyBDUkNUTS0gRUNUTFQtIDY0YkErIFVJRFJELQ0KCQlMaW5rIEZyZXF1
ZW5jeSAxOiAyMDBNSHoNCgkJTGluayBFcnJvciAxOiA8UHJvdC0gPE92ZmwtIDxFT0MtIENU
TFRtLQ0KCQlMaW5rIEZyZXF1ZW5jeSBDYXBhYmlsaXR5IDE6IDIwME1Iei0gMzAwTUh6LSA0
MDBNSHotIDUwME1Iei0gNjAwTUh6LSA4MDBNSHotIDEuMEdIei0gMS4yR0h6LSAxLjRHSHot
IDEuNkdIei0gVmVuZC0NCgkJRXJyb3IgSGFuZGxpbmc6IFBGbEUtIE9GbEUtIFBGRS0gT0ZF
LSBFT0NGRS0gUkZFLSBDUkNGRS0gU0VSUkZFLSBDRi0gUkUtIFBORkUtIE9ORkUtIEVPQ05G
RS0gUk5GRS0gQ1JDTkZFLSBTRVJSTkZFLQ0KCQlQcmVmZXRjaGFibGUgbWVtb3J5IGJlaGlu
ZCBicmlkZ2UgVXBwZXI6IDAwLTAwDQoJCUJ1cyBOdW1iZXI6IDAwDQoJQ2FwYWJpbGl0aWVz
OiBbNDBdIEh5cGVyVHJhbnNwb3J0OiBSZXRyeSBNb2RlDQoJQ2FwYWJpbGl0aWVzOiBbNTRd
IEh5cGVyVHJhbnNwb3J0OiBVbml0SUQgQ2x1bXBpbmcNCglDYXBhYmlsaXRpZXM6IFs5Y10g
SHlwZXJUcmFuc3BvcnQ6ICMxYQ0KCUNhcGFiaWxpdGllczogWzcwXSBNU0k6IEVuYWJsZS0g
Q291bnQ9MS80IE1hc2thYmxlLSA2NGJpdC0NCgkJQWRkcmVzczogMDAwMDAwMDAgIERhdGE6
IDAwMDANCg0KMDA6MDAuMiBHZW5lcmljIHN5c3RlbSBwZXJpcGhlcmFsIFswODA2XTogQVRJ
IFRlY2hub2xvZ2llcyBJbmMgUkQ5OTAgSS9PIE1lbW9yeSBNYW5hZ2VtZW50IFVuaXQgKElP
TU1VKSBbMTAwMjo1YTIzXQ0KCVN1YnN5c3RlbTogQVRJIFRlY2hub2xvZ2llcyBJbmMgUkQ5
OTAgSS9PIE1lbW9yeSBNYW5hZ2VtZW50IFVuaXQgKElPTU1VKSBbMTAwMjo1YTIzXQ0KCUNv
bnRyb2w6IEkvTy0gTWVtLSBCdXNNYXN0ZXIrIFNwZWNDeWNsZS0gTWVtV0lOVi0gVkdBU25v
b3AtIFBhckVyci0gU3RlcHBpbmctIFNFUlItIEZhc3RCMkItIERpc0lOVHgtDQoJU3RhdHVz
OiBDYXArIDY2TUh6LSBVREYtIEZhc3RCMkItIFBhckVyci0gREVWU0VMPWZhc3QgPlRBYm9y
dC0gPFRBYm9ydC0gPE1BYm9ydC0gPlNFUlItIDxQRVJSLSBJTlR4LQ0KCUxhdGVuY3k6IDAN
CglJbnRlcnJ1cHQ6IHBpbiBBIHJvdXRlZCB0byBJUlEgMTANCglDYXBhYmlsaXRpZXM6IFs0
MF0gU2VjdXJlIGRldmljZSA8Pz4NCglDYXBhYmlsaXRpZXM6IFs1NF0gTVNJOiBFbmFibGUr
IENvdW50PTEvMSBNYXNrYWJsZS0gNjRiaXQrDQoJCUFkZHJlc3M6IDAwMDAwMDAwZmVlMDEw
MGMgIERhdGE6IDQxMjgNCglDYXBhYmlsaXRpZXM6IFs2NF0gSHlwZXJUcmFuc3BvcnQ6IE1T
SSBNYXBwaW5nIEVuYWJsZSsgRml4ZWQrDQoNCjAwOjAyLjAgUENJIGJyaWRnZSBbMDYwNF06
IEFUSSBUZWNobm9sb2dpZXMgSW5jIFJEODkwIFBDSSB0byBQQ0kgYnJpZGdlIChQQ0kgZXhw
cmVzcyBncHAgcG9ydCBCKSBbMTAwMjo1YTE2XSAocHJvZy1pZiAwMCBbTm9ybWFsIGRlY29k
ZV0pDQoJQ29udHJvbDogSS9PKyBNZW0rIEJ1c01hc3RlcisgU3BlY0N5Y2xlLSBNZW1XSU5W
LSBWR0FTbm9vcC0gUGFyRXJyLSBTdGVwcGluZy0gU0VSUisgRmFzdEIyQi0gRGlzSU5UeCsN
CglTdGF0dXM6IENhcCsgNjZNSHotIFVERi0gRmFzdEIyQi0gUGFyRXJyLSBERVZTRUw9ZmFz
dCA+VEFib3J0LSA8VEFib3J0LSA8TUFib3J0LSA+U0VSUi0gPFBFUlItIElOVHgtDQoJTGF0
ZW5jeTogMCwgQ2FjaGUgTGluZSBTaXplOiA2NCBieXRlcw0KCUJ1czogcHJpbWFyeT0wMCwg
c2Vjb25kYXJ5PTBhLCBzdWJvcmRpbmF0ZT0wYSwgc2VjLWxhdGVuY3k9MA0KCUkvTyBiZWhp
bmQgYnJpZGdlOiAwMDAwZTAwMC0wMDAwZWZmZg0KCU1lbW9yeSBiZWhpbmQgYnJpZGdlOiBm
YTAwMDAwMC1mZTlmZmZmZg0KCVByZWZldGNoYWJsZSBtZW1vcnkgYmVoaW5kIGJyaWRnZTog
MDAwMDAwMDBkMDAwMDAwMC0wMDAwMDAwMGRmZmZmZmZmDQoJU2Vjb25kYXJ5IHN0YXR1czog
NjZNSHotIEZhc3RCMkItIFBhckVyci0gREVWU0VMPWZhc3QgPlRBYm9ydC0gPFRBYm9ydC0g
PE1BYm9ydC0gPFNFUlItIDxQRVJSLQ0KCUJyaWRnZUN0bDogUGFyaXR5KyBTRVJSKyBOb0lT
QS0gVkdBKyBNQWJvcnQtID5SZXNldC0gRmFzdEIyQi0NCgkJUHJpRGlzY1Rtci0gU2VjRGlz
Y1Rtci0gRGlzY1RtclN0YXQtIERpc2NUbXJTRVJSRW4tDQoJQ2FwYWJpbGl0aWVzOiBbNTBd
IFBvd2VyIE1hbmFnZW1lbnQgdmVyc2lvbiAzDQoJCUZsYWdzOiBQTUVDbGstIERTSS0gRDEt
IEQyLSBBdXhDdXJyZW50PTBtQSBQTUUoRDArLEQxLSxEMi0sRDNob3QrLEQzY29sZCspDQoJ
CVN0YXR1czogRDAgTm9Tb2Z0UnN0LSBQTUUtRW5hYmxlLSBEU2VsPTAgRFNjYWxlPTAgUE1F
LQ0KCUNhcGFiaWxpdGllczogWzU4XSBFeHByZXNzICh2MikgUm9vdCBQb3J0IChTbG90Kyks
IE1TSSAwMA0KCQlEZXZDYXA6CU1heFBheWxvYWQgMTI4IGJ5dGVzLCBQaGFudEZ1bmMgMCwg
TGF0ZW5jeSBMMHMgPDY0bnMsIEwxIDwxdXMNCgkJCUV4dFRhZysgUkJFKyBGTFJlc2V0LQ0K
CQlEZXZDdGw6CVJlcG9ydCBlcnJvcnM6IENvcnJlY3RhYmxlLSBOb24tRmF0YWwtIEZhdGFs
LSBVbnN1cHBvcnRlZC0NCgkJCVJseGRPcmQrIEV4dFRhZy0gUGhhbnRGdW5jLSBBdXhQd3It
IE5vU25vb3ArDQoJCQlNYXhQYXlsb2FkIDEyOCBieXRlcywgTWF4UmVhZFJlcSAxMjggYnl0
ZXMNCgkJRGV2U3RhOglDb3JyRXJyLSBVbmNvcnJFcnItIEZhdGFsRXJyLSBVbnN1cHBSZXEt
IEF1eFB3ci0gVHJhbnNQZW5kLQ0KCQlMbmtDYXA6CVBvcnQgIzAsIFNwZWVkIDVHVC9zLCBX
aWR0aCB4OCwgQVNQTSBMMHMgTDEsIExhdGVuY3kgTDAgPDF1cywgTDEgPDh1cw0KCQkJQ2xv
Y2tQTS0gU3VycHJpc2UtIExMQWN0UmVwKyBCd05vdCsNCgkJTG5rQ3RsOglBU1BNIERpc2Fi
bGVkOyBSQ0IgNjQgYnl0ZXMgRGlzYWJsZWQtIFJldHJhaW4tIENvbW1DbGsrDQoJCQlFeHRT
eW5jaC0gQ2xvY2tQTS0gQXV0V2lkRGlzLSBCV0ludC0gQXV0QldJbnQtDQoJCUxua1N0YToJ
U3BlZWQgMi41R1QvcywgV2lkdGggeDgsIFRyRXJyLSBUcmFpbi0gU2xvdENsaysgRExBY3Rp
dmUrIEJXTWdtdCsgQUJXTWdtdC0NCgkJU2x0Q2FwOglBdHRuQnRuLSBQd3JDdHJsLSBNUkwt
IEF0dG5JbmQtIFB3ckluZC0gSG90UGx1Zy0gU3VycHJpc2UtDQoJCQlTbG90ICMxLCBQb3dl
ckxpbWl0IDI1LjAwMFc7IEludGVybG9jay0gTm9Db21wbCsNCgkJU2x0Q3RsOglFbmFibGU6
IEF0dG5CdG4tIFB3ckZsdC0gTVJMLSBQcmVzRGV0LSBDbWRDcGx0LSBIUElycS0gTGlua0No
Zy0NCgkJCUNvbnRyb2w6IEF0dG5JbmQgVW5rbm93biwgUHdySW5kIFVua25vd24sIFBvd2Vy
LSBJbnRlcmxvY2stDQoJCVNsdFN0YToJU3RhdHVzOiBBdHRuQnRuLSBQb3dlckZsdC0gTVJM
LSBDbWRDcGx0LSBQcmVzRGV0KyBJbnRlcmxvY2stDQoJCQlDaGFuZ2VkOiBNUkwtIFByZXNE
ZXQrIExpbmtTdGF0ZSsNCgkJUm9vdEN0bDogRXJyQ29ycmVjdGFibGUtIEVyck5vbi1GYXRh
bC0gRXJyRmF0YWwtIFBNRUludEVuYS0gQ1JTVmlzaWJsZS0NCgkJUm9vdENhcDogQ1JTVmlz
aWJsZS0NCgkJUm9vdFN0YTogUE1FIFJlcUlEIDAwMDAsIFBNRVN0YXR1cy0gUE1FUGVuZGlu
Zy0NCgkJRGV2Q2FwMjogQ29tcGxldGlvbiBUaW1lb3V0OiBSYW5nZSBBQkNELCBUaW1lb3V0
RGlzKyBBUklGd2QrDQoJCURldkN0bDI6IENvbXBsZXRpb24gVGltZW91dDogNjVtcyB0byAy
MTBtcywgVGltZW91dERpcy0gQVJJRndkLQ0KCQlMbmtDdGwyOiBUYXJnZXQgTGluayBTcGVl
ZDogNUdUL3MsIEVudGVyQ29tcGxpYW5jZS0gU3BlZWREaXMtLCBTZWxlY3RhYmxlIERlLWVt
cGhhc2lzOiAtMy41ZEINCgkJCSBUcmFuc21pdCBNYXJnaW46IE5vcm1hbCBPcGVyYXRpbmcg
UmFuZ2UsIEVudGVyTW9kaWZpZWRDb21wbGlhbmNlLSBDb21wbGlhbmNlU09TLQ0KCQkJIENv
bXBsaWFuY2UgRGUtZW1waGFzaXM6IC02ZEINCgkJTG5rU3RhMjogQ3VycmVudCBEZS1lbXBo
YXNpcyBMZXZlbDogLTMuNWRCDQoJQ2FwYWJpbGl0aWVzOiBbYTBdIE1TSTogRW5hYmxlKyBD
b3VudD0xLzEgTWFza2FibGUtIDY0Yml0LQ0KCQlBZGRyZXNzOiBmZWUzZjAwYyAgRGF0YTog
NDE1MQ0KCUNhcGFiaWxpdGllczogW2IwXSBTdWJzeXN0ZW06IEFUSSBUZWNobm9sb2dpZXMg
SW5jIERldmljZSBbMTAwMjo1YTExXQ0KCUNhcGFiaWxpdGllczogW2I4XSBIeXBlclRyYW5z
cG9ydDogTVNJIE1hcHBpbmcgRW5hYmxlKyBGaXhlZCsNCglDYXBhYmlsaXRpZXM6IFsxMDAg
djFdIFZlbmRvciBTcGVjaWZpYyBJbmZvcm1hdGlvbjogSUQ9MDAwMSBSZXY9MSBMZW49MDEw
IDw/Pg0KCUNhcGFiaWxpdGllczogWzE5MCB2MV0gQWNjZXNzIENvbnRyb2wgU2VydmljZXMN
CgkJQUNTQ2FwOglTcmNWYWxpZCsgVHJhbnNCbGsrIFJlcVJlZGlyKyBDbXBsdFJlZGlyKyBV
cHN0cmVhbUZ3ZCsgRWdyZXNzQ3RybC0gRGlyZWN0VHJhbnMrDQoJCUFDU0N0bDoJU3JjVmFs
aWQrIFRyYW5zQmxrLSBSZXFSZWRpcisgQ21wbHRSZWRpcisgVXBzdHJlYW1Gd2QrIEVncmVz
c0N0cmwtIERpcmVjdFRyYW5zLQ0KCUtlcm5lbCBkcml2ZXIgaW4gdXNlOiBwY2llcG9ydA0K
DQowMDowMy4wIFBDSSBicmlkZ2UgWzA2MDRdOiBBVEkgVGVjaG5vbG9naWVzIEluYyBSRDg5
MCBQQ0kgdG8gUENJIGJyaWRnZSAoUENJIGV4cHJlc3MgZ3BwIHBvcnQgQykgWzEwMDI6NWEx
N10gKHByb2ctaWYgMDAgW05vcm1hbCBkZWNvZGVdKQ0KCUNvbnRyb2w6IEkvTy0gTWVtKyBC
dXNNYXN0ZXIrIFNwZWNDeWNsZS0gTWVtV0lOVi0gVkdBU25vb3AtIFBhckVyci0gU3RlcHBp
bmctIFNFUlIrIEZhc3RCMkItIERpc0lOVHgrDQoJU3RhdHVzOiBDYXArIDY2TUh6LSBVREYt
IEZhc3RCMkItIFBhckVyci0gREVWU0VMPWZhc3QgPlRBYm9ydC0gPFRBYm9ydC0gPE1BYm9y
dC0gPlNFUlItIDxQRVJSLSBJTlR4LQ0KCUxhdGVuY3k6IDAsIENhY2hlIExpbmUgU2l6ZTog
NjQgYnl0ZXMNCglCdXM6IHByaW1hcnk9MDAsIHNlY29uZGFyeT0wOSwgc3Vib3JkaW5hdGU9
MDksIHNlYy1sYXRlbmN5PTANCglJL08gYmVoaW5kIGJyaWRnZTogMDAwMGYwMDAtMDAwMDBm
ZmYNCglNZW1vcnkgYmVoaW5kIGJyaWRnZTogZjlmMDAwMDAtZjlmZmZmZmYNCglQcmVmZXRj
aGFibGUgbWVtb3J5IGJlaGluZCBicmlkZ2U6IDAwMDAwMDAwZmZmMDAwMDAtMDAwMDAwMDAw
MDBmZmZmZg0KCVNlY29uZGFyeSBzdGF0dXM6IDY2TUh6LSBGYXN0QjJCLSBQYXJFcnItIERF
VlNFTD1mYXN0ID5UQWJvcnQtIDxUQWJvcnQtIDxNQWJvcnQtIDxTRVJSLSA8UEVSUi0NCglC
cmlkZ2VDdGw6IFBhcml0eSsgU0VSUisgTm9JU0ErIFZHQS0gTUFib3J0LSA+UmVzZXQtIEZh
c3RCMkItDQoJCVByaURpc2NUbXItIFNlY0Rpc2NUbXItIERpc2NUbXJTdGF0LSBEaXNjVG1y
U0VSUkVuLQ0KCUNhcGFiaWxpdGllczogWzUwXSBQb3dlciBNYW5hZ2VtZW50IHZlcnNpb24g
Mw0KCQlGbGFnczogUE1FQ2xrLSBEU0ktIEQxLSBEMi0gQXV4Q3VycmVudD0wbUEgUE1FKEQw
KyxEMS0sRDItLEQzaG90KyxEM2NvbGQrKQ0KCQlTdGF0dXM6IEQwIE5vU29mdFJzdC0gUE1F
LUVuYWJsZS0gRFNlbD0wIERTY2FsZT0wIFBNRS0NCglDYXBhYmlsaXRpZXM6IFs1OF0gRXhw
cmVzcyAodjIpIFJvb3QgUG9ydCAoU2xvdCspLCBNU0kgMDANCgkJRGV2Q2FwOglNYXhQYXls
b2FkIDEyOCBieXRlcywgUGhhbnRGdW5jIDAsIExhdGVuY3kgTDBzIDw2NG5zLCBMMSA8MXVz
DQoJCQlFeHRUYWcrIFJCRSsgRkxSZXNldC0NCgkJRGV2Q3RsOglSZXBvcnQgZXJyb3JzOiBD
b3JyZWN0YWJsZS0gTm9uLUZhdGFsLSBGYXRhbC0gVW5zdXBwb3J0ZWQtDQoJCQlSbHhkT3Jk
KyBFeHRUYWctIFBoYW50RnVuYy0gQXV4UHdyLSBOb1Nub29wKw0KCQkJTWF4UGF5bG9hZCAx
MjggYnl0ZXMsIE1heFJlYWRSZXEgMTI4IGJ5dGVzDQoJCURldlN0YToJQ29yckVyci0gVW5j
b3JyRXJyLSBGYXRhbEVyci0gVW5zdXBwUmVxLSBBdXhQd3ItIFRyYW5zUGVuZC0NCgkJTG5r
Q2FwOglQb3J0ICMxLCBTcGVlZCA1R1QvcywgV2lkdGggeDgsIEFTUE0gTDBzIEwxLCBMYXRl
bmN5IEwwIDwxdXMsIEwxIDw4dXMNCgkJCUNsb2NrUE0tIFN1cnByaXNlLSBMTEFjdFJlcCsg
QndOb3QrDQoJCUxua0N0bDoJQVNQTSBEaXNhYmxlZDsgUkNCIDY0IGJ5dGVzIERpc2FibGVk
LSBSZXRyYWluLSBDb21tQ2xrLQ0KCQkJRXh0U3luY2gtIENsb2NrUE0tIEF1dFdpZERpcy0g
QldJbnQtIEF1dEJXSW50LQ0KCQlMbmtTdGE6CVNwZWVkIDIuNUdUL3MsIFdpZHRoIHgxLCBU
ckVyci0gVHJhaW4tIFNsb3RDbGsrIERMQWN0aXZlKyBCV01nbXQrIEFCV01nbXQtDQoJCVNs
dENhcDoJQXR0bkJ0bi0gUHdyQ3RybC0gTVJMLSBBdHRuSW5kLSBQd3JJbmQtIEhvdFBsdWct
IFN1cnByaXNlLQ0KCQkJU2xvdCAjMywgUG93ZXJMaW1pdCAxMS4wMDBXOyBJbnRlcmxvY2st
IE5vQ29tcGwrDQoJCVNsdEN0bDoJRW5hYmxlOiBBdHRuQnRuLSBQd3JGbHQtIE1STC0gUHJl
c0RldC0gQ21kQ3BsdC0gSFBJcnEtIExpbmtDaGctDQoJCQlDb250cm9sOiBBdHRuSW5kIFVu
a25vd24sIFB3ckluZCBVbmtub3duLCBQb3dlci0gSW50ZXJsb2NrLQ0KCQlTbHRTdGE6CVN0
YXR1czogQXR0bkJ0bi0gUG93ZXJGbHQtIE1STC0gQ21kQ3BsdC0gUHJlc0RldCsgSW50ZXJs
b2NrLQ0KCQkJQ2hhbmdlZDogTVJMLSBQcmVzRGV0KyBMaW5rU3RhdGUrDQoJCVJvb3RDdGw6
IEVyckNvcnJlY3RhYmxlLSBFcnJOb24tRmF0YWwtIEVyckZhdGFsLSBQTUVJbnRFbmEtIENS
U1Zpc2libGUtDQoJCVJvb3RDYXA6IENSU1Zpc2libGUtDQoJCVJvb3RTdGE6IFBNRSBSZXFJ
RCAwMDAwLCBQTUVTdGF0dXMtIFBNRVBlbmRpbmctDQoJCURldkNhcDI6IENvbXBsZXRpb24g
VGltZW91dDogUmFuZ2UgQUJDRCwgVGltZW91dERpcysgQVJJRndkKw0KCQlEZXZDdGwyOiBD
b21wbGV0aW9uIFRpbWVvdXQ6IDY1bXMgdG8gMjEwbXMsIFRpbWVvdXREaXMtIEFSSUZ3ZC0N
CgkJTG5rQ3RsMjogVGFyZ2V0IExpbmsgU3BlZWQ6IDVHVC9zLCBFbnRlckNvbXBsaWFuY2Ut
IFNwZWVkRGlzLSwgU2VsZWN0YWJsZSBEZS1lbXBoYXNpczogLTMuNWRCDQoJCQkgVHJhbnNt
aXQgTWFyZ2luOiBOb3JtYWwgT3BlcmF0aW5nIFJhbmdlLCBFbnRlck1vZGlmaWVkQ29tcGxp
YW5jZS0gQ29tcGxpYW5jZVNPUy0NCgkJCSBDb21wbGlhbmNlIERlLWVtcGhhc2lzOiAtNmRC
DQoJCUxua1N0YTI6IEN1cnJlbnQgRGUtZW1waGFzaXMgTGV2ZWw6IC0zLjVkQg0KCUNhcGFi
aWxpdGllczogW2EwXSBNU0k6IEVuYWJsZSsgQ291bnQ9MS8xIE1hc2thYmxlLSA2NGJpdC0N
CgkJQWRkcmVzczogZmVlM2YwMGMgIERhdGE6IDQxNTkNCglDYXBhYmlsaXRpZXM6IFtiMF0g
U3Vic3lzdGVtOiBBVEkgVGVjaG5vbG9naWVzIEluYyBEZXZpY2UgWzEwMDI6NWExMV0NCglD
YXBhYmlsaXRpZXM6IFtiOF0gSHlwZXJUcmFuc3BvcnQ6IE1TSSBNYXBwaW5nIEVuYWJsZSsg
Rml4ZWQrDQoJQ2FwYWJpbGl0aWVzOiBbMTAwIHYxXSBWZW5kb3IgU3BlY2lmaWMgSW5mb3Jt
YXRpb246IElEPTAwMDEgUmV2PTEgTGVuPTAxMCA8Pz4NCglDYXBhYmlsaXRpZXM6IFsxOTAg
djFdIEFjY2VzcyBDb250cm9sIFNlcnZpY2VzDQoJCUFDU0NhcDoJU3JjVmFsaWQrIFRyYW5z
QmxrKyBSZXFSZWRpcisgQ21wbHRSZWRpcisgVXBzdHJlYW1Gd2QrIEVncmVzc0N0cmwtIERp
cmVjdFRyYW5zKw0KCQlBQ1NDdGw6CVNyY1ZhbGlkKyBUcmFuc0Jsay0gUmVxUmVkaXIrIENt
cGx0UmVkaXIrIFVwc3RyZWFtRndkKyBFZ3Jlc3NDdHJsLSBEaXJlY3RUcmFucy0NCglLZXJu
ZWwgZHJpdmVyIGluIHVzZTogcGNpZXBvcnQNCg0KMDA6MDUuMCBQQ0kgYnJpZGdlIFswNjA0
XTogQVRJIFRlY2hub2xvZ2llcyBJbmMgUkQ4OTAgUENJIHRvIFBDSSBicmlkZ2UgKFBDSSBl
eHByZXNzIGdwcCBwb3J0IEUpIFsxMDAyOjVhMTldIChwcm9nLWlmIDAwIFtOb3JtYWwgZGVj
b2RlXSkNCglDb250cm9sOiBJL08rIE1lbSsgQnVzTWFzdGVyKyBTcGVjQ3ljbGUtIE1lbVdJ
TlYtIFZHQVNub29wLSBQYXJFcnItIFN0ZXBwaW5nLSBTRVJSKyBGYXN0QjJCLSBEaXNJTlR4
Kw0KCVN0YXR1czogQ2FwKyA2Nk1Iei0gVURGLSBGYXN0QjJCLSBQYXJFcnItIERFVlNFTD1m
YXN0ID5UQWJvcnQtIDxUQWJvcnQtIDxNQWJvcnQtID5TRVJSLSA8UEVSUi0gSU5UeC0NCglM
YXRlbmN5OiAwLCBDYWNoZSBMaW5lIFNpemU6IDY0IGJ5dGVzDQoJQnVzOiBwcmltYXJ5PTAw
LCBzZWNvbmRhcnk9MDgsIHN1Ym9yZGluYXRlPTA4LCBzZWMtbGF0ZW5jeT0wDQoJSS9PIGJl
aGluZCBicmlkZ2U6IDAwMDBkMDAwLTAwMDBkZmZmDQoJTWVtb3J5IGJlaGluZCBicmlkZ2U6
IGY5ZTAwMDAwLWY5ZWZmZmZmDQoJUHJlZmV0Y2hhYmxlIG1lbW9yeSBiZWhpbmQgYnJpZGdl
OiAwMDAwMDAwMGNmZjAwMDAwLTAwMDAwMDAwY2ZmZmZmZmYNCglTZWNvbmRhcnkgc3RhdHVz
OiA2Nk1Iei0gRmFzdEIyQi0gUGFyRXJyLSBERVZTRUw9ZmFzdCA+VEFib3J0LSA8VEFib3J0
LSA8TUFib3J0LSA8U0VSUi0gPFBFUlItDQoJQnJpZGdlQ3RsOiBQYXJpdHkrIFNFUlIrIE5v
SVNBKyBWR0EtIE1BYm9ydC0gPlJlc2V0LSBGYXN0QjJCLQ0KCQlQcmlEaXNjVG1yLSBTZWNE
aXNjVG1yLSBEaXNjVG1yU3RhdC0gRGlzY1RtclNFUlJFbi0NCglDYXBhYmlsaXRpZXM6IFs1
MF0gUG93ZXIgTWFuYWdlbWVudCB2ZXJzaW9uIDMNCgkJRmxhZ3M6IFBNRUNsay0gRFNJLSBE
MS0gRDItIEF1eEN1cnJlbnQ9MG1BIFBNRShEMCssRDEtLEQyLSxEM2hvdCssRDNjb2xkKykN
CgkJU3RhdHVzOiBEMCBOb1NvZnRSc3QtIFBNRS1FbmFibGUtIERTZWw9MCBEU2NhbGU9MCBQ
TUUtDQoJQ2FwYWJpbGl0aWVzOiBbNThdIEV4cHJlc3MgKHYyKSBSb290IFBvcnQgKFNsb3Qr
KSwgTVNJIDAwDQoJCURldkNhcDoJTWF4UGF5bG9hZCAxMjggYnl0ZXMsIFBoYW50RnVuYyAw
LCBMYXRlbmN5IEwwcyA8NjRucywgTDEgPDF1cw0KCQkJRXh0VGFnKyBSQkUrIEZMUmVzZXQt
DQoJCURldkN0bDoJUmVwb3J0IGVycm9yczogQ29ycmVjdGFibGUtIE5vbi1GYXRhbC0gRmF0
YWwtIFVuc3VwcG9ydGVkLQ0KCQkJUmx4ZE9yZCsgRXh0VGFnLSBQaGFudEZ1bmMtIEF1eFB3
ci0gTm9Tbm9vcCsNCgkJCU1heFBheWxvYWQgMTI4IGJ5dGVzLCBNYXhSZWFkUmVxIDEyOCBi
eXRlcw0KCQlEZXZTdGE6CUNvcnJFcnItIFVuY29yckVyci0gRmF0YWxFcnItIFVuc3VwcFJl
cS0gQXV4UHdyLSBUcmFuc1BlbmQtDQoJCUxua0NhcDoJUG9ydCAjMSwgU3BlZWQgNUdUL3Ms
IFdpZHRoIHgxLCBBU1BNIEwwcyBMMSwgTGF0ZW5jeSBMMCA8MXVzLCBMMSA8OHVzDQoJCQlD
bG9ja1BNLSBTdXJwcmlzZS0gTExBY3RSZXArIEJ3Tm90Kw0KCQlMbmtDdGw6CUFTUE0gRGlz
YWJsZWQ7IFJDQiA2NCBieXRlcyBEaXNhYmxlZC0gUmV0cmFpbi0gQ29tbUNsaysNCgkJCUV4
dFN5bmNoLSBDbG9ja1BNLSBBdXRXaWREaXMtIEJXSW50LSBBdXRCV0ludC0NCgkJTG5rU3Rh
OglTcGVlZCAyLjVHVC9zLCBXaWR0aCB4MSwgVHJFcnItIFRyYWluLSBTbG90Q2xrKyBETEFj
dGl2ZSsgQldNZ210KyBBQldNZ210LQ0KCQlTbHRDYXA6CUF0dG5CdG4tIFB3ckN0cmwtIE1S
TC0gQXR0bkluZC0gUHdySW5kLSBIb3RQbHVnLSBTdXJwcmlzZS0NCgkJCVNsb3QgIzUsIFBv
d2VyTGltaXQgNzUuMDAwVzsgSW50ZXJsb2NrLSBOb0NvbXBsKw0KCQlTbHRDdGw6CUVuYWJs
ZTogQXR0bkJ0bi0gUHdyRmx0LSBNUkwtIFByZXNEZXQtIENtZENwbHQtIEhQSXJxLSBMaW5r
Q2hnLQ0KCQkJQ29udHJvbDogQXR0bkluZCBVbmtub3duLCBQd3JJbmQgVW5rbm93biwgUG93
ZXItIEludGVybG9jay0NCgkJU2x0U3RhOglTdGF0dXM6IEF0dG5CdG4tIFBvd2VyRmx0LSBN
UkwtIENtZENwbHQtIFByZXNEZXQrIEludGVybG9jay0NCgkJCUNoYW5nZWQ6IE1STC0gUHJl
c0RldCsgTGlua1N0YXRlKw0KCQlSb290Q3RsOiBFcnJDb3JyZWN0YWJsZS0gRXJyTm9uLUZh
dGFsLSBFcnJGYXRhbC0gUE1FSW50RW5hLSBDUlNWaXNpYmxlLQ0KCQlSb290Q2FwOiBDUlNW
aXNpYmxlLQ0KCQlSb290U3RhOiBQTUUgUmVxSUQgMDAwMCwgUE1FU3RhdHVzLSBQTUVQZW5k
aW5nLQ0KCQlEZXZDYXAyOiBDb21wbGV0aW9uIFRpbWVvdXQ6IFJhbmdlIEFCQ0QsIFRpbWVv
dXREaXMrIEFSSUZ3ZCsNCgkJRGV2Q3RsMjogQ29tcGxldGlvbiBUaW1lb3V0OiA2NW1zIHRv
IDIxMG1zLCBUaW1lb3V0RGlzLSBBUklGd2QtDQoJCUxua0N0bDI6IFRhcmdldCBMaW5rIFNw
ZWVkOiA1R1QvcywgRW50ZXJDb21wbGlhbmNlLSBTcGVlZERpcy0sIFNlbGVjdGFibGUgRGUt
ZW1waGFzaXM6IC0zLjVkQg0KCQkJIFRyYW5zbWl0IE1hcmdpbjogTm9ybWFsIE9wZXJhdGlu
ZyBSYW5nZSwgRW50ZXJNb2RpZmllZENvbXBsaWFuY2UtIENvbXBsaWFuY2VTT1MtDQoJCQkg
Q29tcGxpYW5jZSBEZS1lbXBoYXNpczogLTZkQg0KCQlMbmtTdGEyOiBDdXJyZW50IERlLWVt
cGhhc2lzIExldmVsOiAtMy41ZEINCglDYXBhYmlsaXRpZXM6IFthMF0gTVNJOiBFbmFibGUr
IENvdW50PTEvMSBNYXNrYWJsZS0gNjRiaXQtDQoJCUFkZHJlc3M6IGZlZTNmMDBjICBEYXRh
OiA0MTYxDQoJQ2FwYWJpbGl0aWVzOiBbYjBdIFN1YnN5c3RlbTogQVRJIFRlY2hub2xvZ2ll
cyBJbmMgRGV2aWNlIFsxMDAyOjVhMTFdDQoJQ2FwYWJpbGl0aWVzOiBbYjhdIEh5cGVyVHJh
bnNwb3J0OiBNU0kgTWFwcGluZyBFbmFibGUrIEZpeGVkKw0KCUNhcGFiaWxpdGllczogWzEw
MCB2MV0gVmVuZG9yIFNwZWNpZmljIEluZm9ybWF0aW9uOiBJRD0wMDAxIFJldj0xIExlbj0w
MTAgPD8+DQoJQ2FwYWJpbGl0aWVzOiBbMTkwIHYxXSBBY2Nlc3MgQ29udHJvbCBTZXJ2aWNl
cw0KCQlBQ1NDYXA6CVNyY1ZhbGlkKyBUcmFuc0JsaysgUmVxUmVkaXIrIENtcGx0UmVkaXIr
IFVwc3RyZWFtRndkKyBFZ3Jlc3NDdHJsLSBEaXJlY3RUcmFucysNCgkJQUNTQ3RsOglTcmNW
YWxpZCsgVHJhbnNCbGstIFJlcVJlZGlyKyBDbXBsdFJlZGlyKyBVcHN0cmVhbUZ3ZCsgRWdy
ZXNzQ3RybC0gRGlyZWN0VHJhbnMtDQoJS2VybmVsIGRyaXZlciBpbiB1c2U6IHBjaWVwb3J0
DQoNCjAwOjA2LjAgUENJIGJyaWRnZSBbMDYwNF06IEFUSSBUZWNobm9sb2dpZXMgSW5jIFJE
ODkwIFBDSSB0byBQQ0kgYnJpZGdlIChQQ0kgZXhwcmVzcyBncHAgcG9ydCBGKSBbMTAwMjo1
YTFhXSAocHJvZy1pZiAwMCBbTm9ybWFsIGRlY29kZV0pDQoJQ29udHJvbDogSS9PKyBNZW0r
IEJ1c01hc3RlcisgU3BlY0N5Y2xlLSBNZW1XSU5WLSBWR0FTbm9vcC0gUGFyRXJyLSBTdGVw
cGluZy0gU0VSUisgRmFzdEIyQi0gRGlzSU5UeCsNCglTdGF0dXM6IENhcCsgNjZNSHotIFVE
Ri0gRmFzdEIyQi0gUGFyRXJyLSBERVZTRUw9ZmFzdCA+VEFib3J0LSA8VEFib3J0LSA8TUFi
b3J0LSA+U0VSUi0gPFBFUlItIElOVHgtDQoJTGF0ZW5jeTogMCwgQ2FjaGUgTGluZSBTaXpl
OiA2NCBieXRlcw0KCUJ1czogcHJpbWFyeT0wMCwgc2Vjb25kYXJ5PTA3LCBzdWJvcmRpbmF0
ZT0wNywgc2VjLWxhdGVuY3k9MA0KCUkvTyBiZWhpbmQgYnJpZGdlOiAwMDAwYzAwMC0wMDAw
Y2ZmZg0KCU1lbW9yeSBiZWhpbmQgYnJpZGdlOiBmOWQwMDAwMC1mOWRmZmZmZg0KCVByZWZl
dGNoYWJsZSBtZW1vcnkgYmVoaW5kIGJyaWRnZTogMDAwMDAwMDBjZmUwMDAwMC0wMDAwMDAw
MGNmZWZmZmZmDQoJU2Vjb25kYXJ5IHN0YXR1czogNjZNSHotIEZhc3RCMkItIFBhckVyci0g
REVWU0VMPWZhc3QgPlRBYm9ydC0gPFRBYm9ydC0gPE1BYm9ydC0gPFNFUlItIDxQRVJSLQ0K
CUJyaWRnZUN0bDogUGFyaXR5KyBTRVJSKyBOb0lTQSsgVkdBLSBNQWJvcnQtID5SZXNldC0g
RmFzdEIyQi0NCgkJUHJpRGlzY1Rtci0gU2VjRGlzY1Rtci0gRGlzY1RtclN0YXQtIERpc2NU
bXJTRVJSRW4tDQoJQ2FwYWJpbGl0aWVzOiBbNTBdIFBvd2VyIE1hbmFnZW1lbnQgdmVyc2lv
biAzDQoJCUZsYWdzOiBQTUVDbGstIERTSS0gRDEtIEQyLSBBdXhDdXJyZW50PTBtQSBQTUUo
RDArLEQxLSxEMi0sRDNob3QrLEQzY29sZCspDQoJCVN0YXR1czogRDAgTm9Tb2Z0UnN0LSBQ
TUUtRW5hYmxlLSBEU2VsPTAgRFNjYWxlPTAgUE1FLQ0KCUNhcGFiaWxpdGllczogWzU4XSBF
eHByZXNzICh2MikgUm9vdCBQb3J0IChTbG90KyksIE1TSSAwMA0KCQlEZXZDYXA6CU1heFBh
eWxvYWQgMTI4IGJ5dGVzLCBQaGFudEZ1bmMgMCwgTGF0ZW5jeSBMMHMgPDY0bnMsIEwxIDwx
dXMNCgkJCUV4dFRhZysgUkJFKyBGTFJlc2V0LQ0KCQlEZXZDdGw6CVJlcG9ydCBlcnJvcnM6
IENvcnJlY3RhYmxlLSBOb24tRmF0YWwtIEZhdGFsLSBVbnN1cHBvcnRlZC0NCgkJCVJseGRP
cmQrIEV4dFRhZy0gUGhhbnRGdW5jLSBBdXhQd3ItIE5vU25vb3ArDQoJCQlNYXhQYXlsb2Fk
IDEyOCBieXRlcywgTWF4UmVhZFJlcSAxMjggYnl0ZXMNCgkJRGV2U3RhOglDb3JyRXJyLSBV
bmNvcnJFcnItIEZhdGFsRXJyLSBVbnN1cHBSZXEtIEF1eFB3ci0gVHJhbnNQZW5kLQ0KCQlM
bmtDYXA6CVBvcnQgIzIsIFNwZWVkIDVHVC9zLCBXaWR0aCB4MSwgQVNQTSBMMHMgTDEsIExh
dGVuY3kgTDAgPDF1cywgTDEgPDh1cw0KCQkJQ2xvY2tQTS0gU3VycHJpc2UtIExMQWN0UmVw
KyBCd05vdCsNCgkJTG5rQ3RsOglBU1BNIERpc2FibGVkOyBSQ0IgNjQgYnl0ZXMgRGlzYWJs
ZWQtIFJldHJhaW4tIENvbW1DbGsrDQoJCQlFeHRTeW5jaC0gQ2xvY2tQTS0gQXV0V2lkRGlz
LSBCV0ludC0gQXV0QldJbnQtDQoJCUxua1N0YToJU3BlZWQgMi41R1QvcywgV2lkdGggeDEs
IFRyRXJyLSBUcmFpbi0gU2xvdENsaysgRExBY3RpdmUrIEJXTWdtdCsgQUJXTWdtdC0NCgkJ
U2x0Q2FwOglBdHRuQnRuLSBQd3JDdHJsLSBNUkwtIEF0dG5JbmQtIFB3ckluZC0gSG90UGx1
Zy0gU3VycHJpc2UtDQoJCQlTbG90ICM2LCBQb3dlckxpbWl0IDc1LjAwMFc7IEludGVybG9j
ay0gTm9Db21wbCsNCgkJU2x0Q3RsOglFbmFibGU6IEF0dG5CdG4tIFB3ckZsdC0gTVJMLSBQ
cmVzRGV0LSBDbWRDcGx0LSBIUElycS0gTGlua0NoZy0NCgkJCUNvbnRyb2w6IEF0dG5JbmQg
VW5rbm93biwgUHdySW5kIFVua25vd24sIFBvd2VyLSBJbnRlcmxvY2stDQoJCVNsdFN0YToJ
U3RhdHVzOiBBdHRuQnRuLSBQb3dlckZsdC0gTVJMLSBDbWRDcGx0LSBQcmVzRGV0KyBJbnRl
cmxvY2stDQoJCQlDaGFuZ2VkOiBNUkwtIFByZXNEZXQrIExpbmtTdGF0ZSsNCgkJUm9vdEN0
bDogRXJyQ29ycmVjdGFibGUtIEVyck5vbi1GYXRhbC0gRXJyRmF0YWwtIFBNRUludEVuYS0g
Q1JTVmlzaWJsZS0NCgkJUm9vdENhcDogQ1JTVmlzaWJsZS0NCgkJUm9vdFN0YTogUE1FIFJl
cUlEIDAwMDAsIFBNRVN0YXR1cy0gUE1FUGVuZGluZy0NCgkJRGV2Q2FwMjogQ29tcGxldGlv
biBUaW1lb3V0OiBSYW5nZSBBQkNELCBUaW1lb3V0RGlzKyBBUklGd2QrDQoJCURldkN0bDI6
IENvbXBsZXRpb24gVGltZW91dDogNjVtcyB0byAyMTBtcywgVGltZW91dERpcy0gQVJJRndk
LQ0KCQlMbmtDdGwyOiBUYXJnZXQgTGluayBTcGVlZDogNUdUL3MsIEVudGVyQ29tcGxpYW5j
ZS0gU3BlZWREaXMtLCBTZWxlY3RhYmxlIERlLWVtcGhhc2lzOiAtMy41ZEINCgkJCSBUcmFu
c21pdCBNYXJnaW46IE5vcm1hbCBPcGVyYXRpbmcgUmFuZ2UsIEVudGVyTW9kaWZpZWRDb21w
bGlhbmNlLSBDb21wbGlhbmNlU09TLQ0KCQkJIENvbXBsaWFuY2UgRGUtZW1waGFzaXM6IC02
ZEINCgkJTG5rU3RhMjogQ3VycmVudCBEZS1lbXBoYXNpcyBMZXZlbDogLTMuNWRCDQoJQ2Fw
YWJpbGl0aWVzOiBbYTBdIE1TSTogRW5hYmxlKyBDb3VudD0xLzEgTWFza2FibGUtIDY0Yml0
LQ0KCQlBZGRyZXNzOiBmZWUzZjAwYyAgRGF0YTogNDE2OQ0KCUNhcGFiaWxpdGllczogW2Iw
XSBTdWJzeXN0ZW06IEFUSSBUZWNobm9sb2dpZXMgSW5jIERldmljZSBbMTAwMjo1YTExXQ0K
CUNhcGFiaWxpdGllczogW2I4XSBIeXBlclRyYW5zcG9ydDogTVNJIE1hcHBpbmcgRW5hYmxl
KyBGaXhlZCsNCglDYXBhYmlsaXRpZXM6IFsxMDAgdjFdIFZlbmRvciBTcGVjaWZpYyBJbmZv
cm1hdGlvbjogSUQ9MDAwMSBSZXY9MSBMZW49MDEwIDw/Pg0KCUNhcGFiaWxpdGllczogWzE5
MCB2MV0gQWNjZXNzIENvbnRyb2wgU2VydmljZXMNCgkJQUNTQ2FwOglTcmNWYWxpZCsgVHJh
bnNCbGsrIFJlcVJlZGlyKyBDbXBsdFJlZGlyKyBVcHN0cmVhbUZ3ZCsgRWdyZXNzQ3RybC0g
RGlyZWN0VHJhbnMrDQoJCUFDU0N0bDoJU3JjVmFsaWQrIFRyYW5zQmxrLSBSZXFSZWRpcisg
Q21wbHRSZWRpcisgVXBzdHJlYW1Gd2QrIEVncmVzc0N0cmwtIERpcmVjdFRyYW5zLQ0KCUtl
cm5lbCBkcml2ZXIgaW4gdXNlOiBwY2llcG9ydA0KDQowMDowYS4wIFBDSSBicmlkZ2UgWzA2
MDRdOiBBVEkgVGVjaG5vbG9naWVzIEluYyBSRDg5MCBQQ0kgdG8gUENJIGJyaWRnZSAoZXh0
ZXJuYWwgZ2Z4MSBwb3J0IEEpIFsxMDAyOjVhMWRdIChwcm9nLWlmIDAwIFtOb3JtYWwgZGVj
b2RlXSkNCglDb250cm9sOiBJL08tIE1lbSsgQnVzTWFzdGVyKyBTcGVjQ3ljbGUtIE1lbVdJ
TlYtIFZHQVNub29wLSBQYXJFcnItIFN0ZXBwaW5nLSBTRVJSKyBGYXN0QjJCLSBEaXNJTlR4
Kw0KCVN0YXR1czogQ2FwKyA2Nk1Iei0gVURGLSBGYXN0QjJCLSBQYXJFcnItIERFVlNFTD1m
YXN0ID5UQWJvcnQtIDxUQWJvcnQtIDxNQWJvcnQtID5TRVJSLSA8UEVSUi0gSU5UeC0NCglM
YXRlbmN5OiAwLCBDYWNoZSBMaW5lIFNpemU6IDY0IGJ5dGVzDQoJQnVzOiBwcmltYXJ5PTAw
LCBzZWNvbmRhcnk9MDYsIHN1Ym9yZGluYXRlPTA2LCBzZWMtbGF0ZW5jeT0wDQoJSS9PIGJl
aGluZCBicmlkZ2U6IDAwMDBmMDAwLTAwMDAwZmZmDQoJTWVtb3J5IGJlaGluZCBicmlkZ2U6
IGY5YTAwMDAwLWY5YmZmZmZmDQoJUHJlZmV0Y2hhYmxlIG1lbW9yeSBiZWhpbmQgYnJpZGdl
OiAwMDAwMDAwMGZmZjAwMDAwLTAwMDAwMDAwMDAwZmZmZmYNCglTZWNvbmRhcnkgc3RhdHVz
OiA2Nk1Iei0gRmFzdEIyQi0gUGFyRXJyLSBERVZTRUw9ZmFzdCA+VEFib3J0LSA8VEFib3J0
LSA8TUFib3J0KyA8U0VSUi0gPFBFUlItDQoJQnJpZGdlQ3RsOiBQYXJpdHkrIFNFUlIrIE5v
SVNBKyBWR0EtIE1BYm9ydC0gPlJlc2V0LSBGYXN0QjJCLQ0KCQlQcmlEaXNjVG1yLSBTZWNE
aXNjVG1yLSBEaXNjVG1yU3RhdC0gRGlzY1RtclNFUlJFbi0NCglDYXBhYmlsaXRpZXM6IFs1
MF0gUG93ZXIgTWFuYWdlbWVudCB2ZXJzaW9uIDMNCgkJRmxhZ3M6IFBNRUNsay0gRFNJLSBE
MS0gRDItIEF1eEN1cnJlbnQ9MG1BIFBNRShEMCssRDEtLEQyLSxEM2hvdCssRDNjb2xkKykN
CgkJU3RhdHVzOiBEMCBOb1NvZnRSc3QtIFBNRS1FbmFibGUtIERTZWw9MCBEU2NhbGU9MCBQ
TUUtDQoJQ2FwYWJpbGl0aWVzOiBbNThdIEV4cHJlc3MgKHYyKSBSb290IFBvcnQgKFNsb3Qr
KSwgTVNJIDAwDQoJCURldkNhcDoJTWF4UGF5bG9hZCAxMjggYnl0ZXMsIFBoYW50RnVuYyAw
LCBMYXRlbmN5IEwwcyA8NjRucywgTDEgPDF1cw0KCQkJRXh0VGFnKyBSQkUrIEZMUmVzZXQt
DQoJCURldkN0bDoJUmVwb3J0IGVycm9yczogQ29ycmVjdGFibGUtIE5vbi1GYXRhbC0gRmF0
YWwtIFVuc3VwcG9ydGVkLQ0KCQkJUmx4ZE9yZCsgRXh0VGFnLSBQaGFudEZ1bmMtIEF1eFB3
ci0gTm9Tbm9vcCsNCgkJCU1heFBheWxvYWQgMTI4IGJ5dGVzLCBNYXhSZWFkUmVxIDEyOCBi
eXRlcw0KCQlEZXZTdGE6CUNvcnJFcnItIFVuY29yckVyci0gRmF0YWxFcnItIFVuc3VwcFJl
cS0gQXV4UHdyLSBUcmFuc1BlbmQtDQoJCUxua0NhcDoJUG9ydCAjNSwgU3BlZWQgMi41R1Qv
cywgV2lkdGggeDEsIEFTUE0gTDBzIEwxLCBMYXRlbmN5IEwwIDwxdXMsIEwxIDw4dXMNCgkJ
CUNsb2NrUE0tIFN1cnByaXNlLSBMTEFjdFJlcCsgQndOb3QrDQoJCUxua0N0bDoJQVNQTSBE
aXNhYmxlZDsgUkNCIDY0IGJ5dGVzIERpc2FibGVkLSBSZXRyYWluLSBDb21tQ2xrLQ0KCQkJ
RXh0U3luY2gtIENsb2NrUE0tIEF1dFdpZERpcy0gQldJbnQtIEF1dEJXSW50LQ0KCQlMbmtT
dGE6CVNwZWVkIDIuNUdUL3MsIFdpZHRoIHgxLCBUckVyci0gVHJhaW4tIFNsb3RDbGsrIERM
QWN0aXZlKyBCV01nbXQrIEFCV01nbXQtDQoJCVNsdENhcDoJQXR0bkJ0bi0gUHdyQ3RybC0g
TVJMLSBBdHRuSW5kLSBQd3JJbmQtIEhvdFBsdWctIFN1cnByaXNlLQ0KCQkJU2xvdCAjMiwg
UG93ZXJMaW1pdCA3NS4wMDBXOyBJbnRlcmxvY2stIE5vQ29tcGwrDQoJCVNsdEN0bDoJRW5h
YmxlOiBBdHRuQnRuLSBQd3JGbHQtIE1STC0gUHJlc0RldC0gQ21kQ3BsdC0gSFBJcnEtIExp
bmtDaGctDQoJCQlDb250cm9sOiBBdHRuSW5kIFVua25vd24sIFB3ckluZCBVbmtub3duLCBQ
b3dlci0gSW50ZXJsb2NrLQ0KCQlTbHRTdGE6CVN0YXR1czogQXR0bkJ0bi0gUG93ZXJGbHQt
IE1STC0gQ21kQ3BsdC0gUHJlc0RldCsgSW50ZXJsb2NrLQ0KCQkJQ2hhbmdlZDogTVJMLSBQ
cmVzRGV0KyBMaW5rU3RhdGUrDQoJCVJvb3RDdGw6IEVyckNvcnJlY3RhYmxlLSBFcnJOb24t
RmF0YWwtIEVyckZhdGFsLSBQTUVJbnRFbmEtIENSU1Zpc2libGUtDQoJCVJvb3RDYXA6IENS
U1Zpc2libGUtDQoJCVJvb3RTdGE6IFBNRSBSZXFJRCAwMDAwLCBQTUVTdGF0dXMtIFBNRVBl
bmRpbmctDQoJCURldkNhcDI6IENvbXBsZXRpb24gVGltZW91dDogUmFuZ2UgQUJDRCwgVGlt
ZW91dERpcysgQVJJRndkKw0KCQlEZXZDdGwyOiBDb21wbGV0aW9uIFRpbWVvdXQ6IDY1bXMg
dG8gMjEwbXMsIFRpbWVvdXREaXMtIEFSSUZ3ZC0NCgkJTG5rQ3RsMjogVGFyZ2V0IExpbmsg
U3BlZWQ6IDIuNUdUL3MsIEVudGVyQ29tcGxpYW5jZS0gU3BlZWREaXMtLCBTZWxlY3RhYmxl
IERlLWVtcGhhc2lzOiAtNmRCDQoJCQkgVHJhbnNtaXQgTWFyZ2luOiBOb3JtYWwgT3BlcmF0
aW5nIFJhbmdlLCBFbnRlck1vZGlmaWVkQ29tcGxpYW5jZS0gQ29tcGxpYW5jZVNPUy0NCgkJ
CSBDb21wbGlhbmNlIERlLWVtcGhhc2lzOiAtNmRCDQoJCUxua1N0YTI6IEN1cnJlbnQgRGUt
ZW1waGFzaXMgTGV2ZWw6IC02ZEINCglDYXBhYmlsaXRpZXM6IFthMF0gTVNJOiBFbmFibGUr
IENvdW50PTEvMSBNYXNrYWJsZS0gNjRiaXQtDQoJCUFkZHJlc3M6IGZlZTNmMDBjICBEYXRh
OiA0MTcxDQoJQ2FwYWJpbGl0aWVzOiBbYjBdIFN1YnN5c3RlbTogQVRJIFRlY2hub2xvZ2ll
cyBJbmMgRGV2aWNlIFsxMDAyOjVhMTFdDQoJQ2FwYWJpbGl0aWVzOiBbYjhdIEh5cGVyVHJh
bnNwb3J0OiBNU0kgTWFwcGluZyBFbmFibGUrIEZpeGVkKw0KCUNhcGFiaWxpdGllczogWzEw
MCB2MV0gVmVuZG9yIFNwZWNpZmljIEluZm9ybWF0aW9uOiBJRD0wMDAxIFJldj0xIExlbj0w
MTAgPD8+DQoJQ2FwYWJpbGl0aWVzOiBbMTkwIHYxXSBBY2Nlc3MgQ29udHJvbCBTZXJ2aWNl
cw0KCQlBQ1NDYXA6CVNyY1ZhbGlkKyBUcmFuc0JsaysgUmVxUmVkaXIrIENtcGx0UmVkaXIr
IFVwc3RyZWFtRndkKyBFZ3Jlc3NDdHJsLSBEaXJlY3RUcmFucysNCgkJQUNTQ3RsOglTcmNW
YWxpZCsgVHJhbnNCbGstIFJlcVJlZGlyKyBDbXBsdFJlZGlyKyBVcHN0cmVhbUZ3ZCsgRWdy
ZXNzQ3RybC0gRGlyZWN0VHJhbnMtDQoJS2VybmVsIGRyaXZlciBpbiB1c2U6IHBjaWVwb3J0
DQoNCjAwOjBiLjAgUENJIGJyaWRnZSBbMDYwNF06IEFUSSBUZWNobm9sb2dpZXMgSW5jIFJE
ODkwIFBDSSB0byBQQ0kgYnJpZGdlIChOQi1TQiBsaW5rKSBbMTAwMjo1YTFmXSAocHJvZy1p
ZiAwMCBbTm9ybWFsIGRlY29kZV0pDQoJQ29udHJvbDogSS9PKyBNZW0rIEJ1c01hc3Rlcisg
U3BlY0N5Y2xlLSBNZW1XSU5WLSBWR0FTbm9vcC0gUGFyRXJyLSBTdGVwcGluZy0gU0VSUisg
RmFzdEIyQi0gRGlzSU5UeCsNCglTdGF0dXM6IENhcCsgNjZNSHotIFVERi0gRmFzdEIyQi0g
UGFyRXJyLSBERVZTRUw9ZmFzdCA+VEFib3J0LSA8VEFib3J0LSA8TUFib3J0LSA+U0VSUi0g
PFBFUlItIElOVHgtDQoJTGF0ZW5jeTogMCwgQ2FjaGUgTGluZSBTaXplOiA2NCBieXRlcw0K
CUJ1czogcHJpbWFyeT0wMCwgc2Vjb25kYXJ5PTA1LCBzdWJvcmRpbmF0ZT0wNSwgc2VjLWxh
dGVuY3k9MA0KCUkvTyBiZWhpbmQgYnJpZGdlOiAwMDAwYjAwMC0wMDAwYmZmZg0KCU1lbW9y
eSBiZWhpbmQgYnJpZGdlOiBmOTkwMDAwMC1mOTlmZmZmZg0KCVByZWZldGNoYWJsZSBtZW1v
cnkgYmVoaW5kIGJyaWRnZTogMDAwMDAwMDBiMDAwMDAwMC0wMDAwMDAwMGJmZmZmZmZmDQoJ
U2Vjb25kYXJ5IHN0YXR1czogNjZNSHotIEZhc3RCMkItIFBhckVyci0gREVWU0VMPWZhc3Qg
PlRBYm9ydC0gPFRBYm9ydC0gPE1BYm9ydC0gPFNFUlItIDxQRVJSLQ0KCUJyaWRnZUN0bDog
UGFyaXR5KyBTRVJSKyBOb0lTQSsgVkdBLSBNQWJvcnQtID5SZXNldC0gRmFzdEIyQi0NCgkJ
UHJpRGlzY1Rtci0gU2VjRGlzY1Rtci0gRGlzY1RtclN0YXQtIERpc2NUbXJTRVJSRW4tDQoJ
Q2FwYWJpbGl0aWVzOiBbNTBdIFBvd2VyIE1hbmFnZW1lbnQgdmVyc2lvbiAzDQoJCUZsYWdz
OiBQTUVDbGstIERTSS0gRDEtIEQyLSBBdXhDdXJyZW50PTBtQSBQTUUoRDArLEQxLSxEMi0s
RDNob3QrLEQzY29sZCspDQoJCVN0YXR1czogRDAgTm9Tb2Z0UnN0LSBQTUUtRW5hYmxlLSBE
U2VsPTAgRFNjYWxlPTAgUE1FLQ0KCUNhcGFiaWxpdGllczogWzU4XSBFeHByZXNzICh2Mikg
Um9vdCBQb3J0IChTbG90KyksIE1TSSAwMA0KCQlEZXZDYXA6CU1heFBheWxvYWQgMTI4IGJ5
dGVzLCBQaGFudEZ1bmMgMCwgTGF0ZW5jeSBMMHMgPDY0bnMsIEwxIDwxdXMNCgkJCUV4dFRh
ZysgUkJFKyBGTFJlc2V0LQ0KCQlEZXZDdGw6CVJlcG9ydCBlcnJvcnM6IENvcnJlY3RhYmxl
LSBOb24tRmF0YWwtIEZhdGFsLSBVbnN1cHBvcnRlZC0NCgkJCVJseGRPcmQrIEV4dFRhZy0g
UGhhbnRGdW5jLSBBdXhQd3ItIE5vU25vb3ArDQoJCQlNYXhQYXlsb2FkIDEyOCBieXRlcywg
TWF4UmVhZFJlcSAxMjggYnl0ZXMNCgkJRGV2U3RhOglDb3JyRXJyLSBVbmNvcnJFcnItIEZh
dGFsRXJyLSBVbnN1cHBSZXEtIEF1eFB3ci0gVHJhbnNQZW5kLQ0KCQlMbmtDYXA6CVBvcnQg
IzAsIFNwZWVkIDVHVC9zLCBXaWR0aCB4MTYsIEFTUE0gTDBzIEwxLCBMYXRlbmN5IEwwIDwx
dXMsIEwxIDw4dXMNCgkJCUNsb2NrUE0tIFN1cnByaXNlLSBMTEFjdFJlcCsgQndOb3QrDQoJ
CUxua0N0bDoJQVNQTSBEaXNhYmxlZDsgUkNCIDY0IGJ5dGVzIERpc2FibGVkLSBSZXRyYWlu
LSBDb21tQ2xrKw0KCQkJRXh0U3luY2gtIENsb2NrUE0tIEF1dFdpZERpcy0gQldJbnQtIEF1
dEJXSW50LQ0KCQlMbmtTdGE6CVNwZWVkIDIuNUdUL3MsIFdpZHRoIHgxNiwgVHJFcnItIFRy
YWluLSBTbG90Q2xrKyBETEFjdGl2ZSsgQldNZ210KyBBQldNZ210LQ0KCQlTbHRDYXA6CUF0
dG5CdG4tIFB3ckN0cmwtIE1STC0gQXR0bkluZC0gUHdySW5kLSBIb3RQbHVnLSBTdXJwcmlz
ZS0NCgkJCVNsb3QgIzUsIFBvd2VyTGltaXQgNzUuMDAwVzsgSW50ZXJsb2NrLSBOb0NvbXBs
Kw0KCQlTbHRDdGw6CUVuYWJsZTogQXR0bkJ0bi0gUHdyRmx0LSBNUkwtIFByZXNEZXQtIENt
ZENwbHQtIEhQSXJxLSBMaW5rQ2hnLQ0KCQkJQ29udHJvbDogQXR0bkluZCBVbmtub3duLCBQ
d3JJbmQgVW5rbm93biwgUG93ZXItIEludGVybG9jay0NCgkJU2x0U3RhOglTdGF0dXM6IEF0
dG5CdG4tIFBvd2VyRmx0LSBNUkwtIENtZENwbHQtIFByZXNEZXQrIEludGVybG9jay0NCgkJ
CUNoYW5nZWQ6IE1STC0gUHJlc0RldCsgTGlua1N0YXRlKw0KCQlSb290Q3RsOiBFcnJDb3Jy
ZWN0YWJsZS0gRXJyTm9uLUZhdGFsLSBFcnJGYXRhbC0gUE1FSW50RW5hLSBDUlNWaXNpYmxl
LQ0KCQlSb290Q2FwOiBDUlNWaXNpYmxlLQ0KCQlSb290U3RhOiBQTUUgUmVxSUQgMDAwMCwg
UE1FU3RhdHVzLSBQTUVQZW5kaW5nLQ0KCQlEZXZDYXAyOiBDb21wbGV0aW9uIFRpbWVvdXQ6
IFJhbmdlIEFCQ0QsIFRpbWVvdXREaXMrIEFSSUZ3ZCsNCgkJRGV2Q3RsMjogQ29tcGxldGlv
biBUaW1lb3V0OiA2NW1zIHRvIDIxMG1zLCBUaW1lb3V0RGlzLSBBUklGd2QtDQoJCUxua0N0
bDI6IFRhcmdldCBMaW5rIFNwZWVkOiA1R1QvcywgRW50ZXJDb21wbGlhbmNlLSBTcGVlZERp
cy0sIFNlbGVjdGFibGUgRGUtZW1waGFzaXM6IC0zLjVkQg0KCQkJIFRyYW5zbWl0IE1hcmdp
bjogTm9ybWFsIE9wZXJhdGluZyBSYW5nZSwgRW50ZXJNb2RpZmllZENvbXBsaWFuY2UtIENv
bXBsaWFuY2VTT1MtDQoJCQkgQ29tcGxpYW5jZSBEZS1lbXBoYXNpczogLTZkQg0KCQlMbmtT
dGEyOiBDdXJyZW50IERlLWVtcGhhc2lzIExldmVsOiAtMy41ZEINCglDYXBhYmlsaXRpZXM6
IFthMF0gTVNJOiBFbmFibGUrIENvdW50PTEvMSBNYXNrYWJsZS0gNjRiaXQtDQoJCUFkZHJl
c3M6IGZlZTNmMDBjICBEYXRhOiA0MTc5DQoJQ2FwYWJpbGl0aWVzOiBbYjBdIFN1YnN5c3Rl
bTogQVRJIFRlY2hub2xvZ2llcyBJbmMgRGV2aWNlIFsxMDAyOjVhMTFdDQoJQ2FwYWJpbGl0
aWVzOiBbYjhdIEh5cGVyVHJhbnNwb3J0OiBNU0kgTWFwcGluZyBFbmFibGUrIEZpeGVkKw0K
CUNhcGFiaWxpdGllczogWzEwMCB2MV0gVmVuZG9yIFNwZWNpZmljIEluZm9ybWF0aW9uOiBJ
RD0wMDAxIFJldj0xIExlbj0wMTAgPD8+DQoJQ2FwYWJpbGl0aWVzOiBbMTkwIHYxXSBBY2Nl
c3MgQ29udHJvbCBTZXJ2aWNlcw0KCQlBQ1NDYXA6CVNyY1ZhbGlkKyBUcmFuc0JsaysgUmVx
UmVkaXIrIENtcGx0UmVkaXIrIFVwc3RyZWFtRndkKyBFZ3Jlc3NDdHJsLSBEaXJlY3RUcmFu
cysNCgkJQUNTQ3RsOglTcmNWYWxpZCsgVHJhbnNCbGstIFJlcVJlZGlyKyBDbXBsdFJlZGly
KyBVcHN0cmVhbUZ3ZCsgRWdyZXNzQ3RybC0gRGlyZWN0VHJhbnMtDQoJS2VybmVsIGRyaXZl
ciBpbiB1c2U6IHBjaWVwb3J0DQoNCjAwOjBkLjAgUENJIGJyaWRnZSBbMDYwNF06IEFUSSBU
ZWNobm9sb2dpZXMgSW5jIFJEODkwIFBDSSB0byBQQ0kgYnJpZGdlIChleHRlcm5hbCBnZngx
IHBvcnQgQikgWzEwMDI6NWExZV0gKHByb2ctaWYgMDAgW05vcm1hbCBkZWNvZGVdKQ0KCUNv
bnRyb2w6IEkvTy0gTWVtKyBCdXNNYXN0ZXIrIFNwZWNDeWNsZS0gTWVtV0lOVi0gVkdBU25v
b3AtIFBhckVyci0gU3RlcHBpbmctIFNFUlIrIEZhc3RCMkItIERpc0lOVHgrDQoJU3RhdHVz
OiBDYXArIDY2TUh6LSBVREYtIEZhc3RCMkItIFBhckVyci0gREVWU0VMPWZhc3QgPlRBYm9y
dC0gPFRBYm9ydC0gPE1BYm9ydC0gPlNFUlItIDxQRVJSLSBJTlR4LQ0KCUxhdGVuY3k6IDAs
IENhY2hlIExpbmUgU2l6ZTogNjQgYnl0ZXMNCglCdXM6IHByaW1hcnk9MDAsIHNlY29uZGFy
eT0wNCwgc3Vib3JkaW5hdGU9MDQsIHNlYy1sYXRlbmN5PTANCglJL08gYmVoaW5kIGJyaWRn
ZTogMDAwMGYwMDAtMDAwMDBmZmYNCglNZW1vcnkgYmVoaW5kIGJyaWRnZTogZjk4MDAwMDAt
Zjk4ZmZmZmYNCglQcmVmZXRjaGFibGUgbWVtb3J5IGJlaGluZCBicmlkZ2U6IDAwMDAwMDAw
ZmZmMDAwMDAtMDAwMDAwMDAwMDBmZmZmZg0KCVNlY29uZGFyeSBzdGF0dXM6IDY2TUh6LSBG
YXN0QjJCLSBQYXJFcnItIERFVlNFTD1mYXN0ID5UQWJvcnQtIDxUQWJvcnQtIDxNQWJvcnQt
IDxTRVJSLSA8UEVSUi0NCglCcmlkZ2VDdGw6IFBhcml0eSsgU0VSUisgTm9JU0ErIFZHQS0g
TUFib3J0LSA+UmVzZXQtIEZhc3RCMkItDQoJCVByaURpc2NUbXItIFNlY0Rpc2NUbXItIERp
c2NUbXJTdGF0LSBEaXNjVG1yU0VSUkVuLQ0KCUNhcGFiaWxpdGllczogWzUwXSBQb3dlciBN
YW5hZ2VtZW50IHZlcnNpb24gMw0KCQlGbGFnczogUE1FQ2xrLSBEU0ktIEQxLSBEMi0gQXV4
Q3VycmVudD0wbUEgUE1FKEQwKyxEMS0sRDItLEQzaG90KyxEM2NvbGQrKQ0KCQlTdGF0dXM6
IEQwIE5vU29mdFJzdC0gUE1FLUVuYWJsZS0gRFNlbD0wIERTY2FsZT0wIFBNRS0NCglDYXBh
YmlsaXRpZXM6IFs1OF0gRXhwcmVzcyAodjIpIFJvb3QgUG9ydCAoU2xvdCspLCBNU0kgMDAN
CgkJRGV2Q2FwOglNYXhQYXlsb2FkIDEyOCBieXRlcywgUGhhbnRGdW5jIDAsIExhdGVuY3kg
TDBzIDw2NG5zLCBMMSA8MXVzDQoJCQlFeHRUYWcrIFJCRSsgRkxSZXNldC0NCgkJRGV2Q3Rs
OglSZXBvcnQgZXJyb3JzOiBDb3JyZWN0YWJsZS0gTm9uLUZhdGFsLSBGYXRhbC0gVW5zdXBw
b3J0ZWQtDQoJCQlSbHhkT3JkKyBFeHRUYWctIFBoYW50RnVuYy0gQXV4UHdyLSBOb1Nub29w
Kw0KCQkJTWF4UGF5bG9hZCAxMjggYnl0ZXMsIE1heFJlYWRSZXEgMTI4IGJ5dGVzDQoJCURl
dlN0YToJQ29yckVyci0gVW5jb3JyRXJyLSBGYXRhbEVyci0gVW5zdXBwUmVxLSBBdXhQd3It
IFRyYW5zUGVuZC0NCgkJTG5rQ2FwOglQb3J0ICMwLCBTcGVlZCA1R1QvcywgV2lkdGggeDQs
IEFTUE0gTDBzIEwxLCBMYXRlbmN5IEwwIDwxdXMsIEwxIDw4dXMNCgkJCUNsb2NrUE0tIFN1
cnByaXNlLSBMTEFjdFJlcCsgQndOb3QrDQoJCUxua0N0bDoJQVNQTSBEaXNhYmxlZDsgUkNC
IDY0IGJ5dGVzIERpc2FibGVkLSBSZXRyYWluLSBDb21tQ2xrLQ0KCQkJRXh0U3luY2gtIENs
b2NrUE0tIEF1dFdpZERpcy0gQldJbnQtIEF1dEJXSW50LQ0KCQlMbmtTdGE6CVNwZWVkIDIu
NUdUL3MsIFdpZHRoIHgxLCBUckVyci0gVHJhaW4tIFNsb3RDbGsrIERMQWN0aXZlKyBCV01n
bXQrIEFCV01nbXQtDQoJCVNsdENhcDoJQXR0bkJ0bi0gUHdyQ3RybC0gTVJMLSBBdHRuSW5k
LSBQd3JJbmQtIEhvdFBsdWctIFN1cnByaXNlLQ0KCQkJU2xvdCAjNCwgUG93ZXJMaW1pdCA3
NS4wMDBXOyBJbnRlcmxvY2stIE5vQ29tcGwrDQoJCVNsdEN0bDoJRW5hYmxlOiBBdHRuQnRu
LSBQd3JGbHQtIE1STC0gUHJlc0RldC0gQ21kQ3BsdC0gSFBJcnEtIExpbmtDaGctDQoJCQlD
b250cm9sOiBBdHRuSW5kIFVua25vd24sIFB3ckluZCBVbmtub3duLCBQb3dlci0gSW50ZXJs
b2NrLQ0KCQlTbHRTdGE6CVN0YXR1czogQXR0bkJ0bi0gUG93ZXJGbHQtIE1STC0gQ21kQ3Bs
dC0gUHJlc0RldCsgSW50ZXJsb2NrLQ0KCQkJQ2hhbmdlZDogTVJMLSBQcmVzRGV0KyBMaW5r
U3RhdGUrDQoJCVJvb3RDdGw6IEVyckNvcnJlY3RhYmxlLSBFcnJOb24tRmF0YWwtIEVyckZh
dGFsLSBQTUVJbnRFbmEtIENSU1Zpc2libGUtDQoJCVJvb3RDYXA6IENSU1Zpc2libGUtDQoJ
CVJvb3RTdGE6IFBNRSBSZXFJRCAwMDAwLCBQTUVTdGF0dXMtIFBNRVBlbmRpbmctDQoJCURl
dkNhcDI6IENvbXBsZXRpb24gVGltZW91dDogUmFuZ2UgQUJDRCwgVGltZW91dERpcysgQVJJ
RndkKw0KCQlEZXZDdGwyOiBDb21wbGV0aW9uIFRpbWVvdXQ6IDY1bXMgdG8gMjEwbXMsIFRp
bWVvdXREaXMtIEFSSUZ3ZC0NCgkJTG5rQ3RsMjogVGFyZ2V0IExpbmsgU3BlZWQ6IDVHVC9z
LCBFbnRlckNvbXBsaWFuY2UtIFNwZWVkRGlzLSwgU2VsZWN0YWJsZSBEZS1lbXBoYXNpczog
LTMuNWRCDQoJCQkgVHJhbnNtaXQgTWFyZ2luOiBOb3JtYWwgT3BlcmF0aW5nIFJhbmdlLCBF
bnRlck1vZGlmaWVkQ29tcGxpYW5jZS0gQ29tcGxpYW5jZVNPUy0NCgkJCSBDb21wbGlhbmNl
IERlLWVtcGhhc2lzOiAtNmRCDQoJCUxua1N0YTI6IEN1cnJlbnQgRGUtZW1waGFzaXMgTGV2
ZWw6IC0zLjVkQg0KCUNhcGFiaWxpdGllczogW2EwXSBNU0k6IEVuYWJsZSsgQ291bnQ9MS8x
IE1hc2thYmxlLSA2NGJpdC0NCgkJQWRkcmVzczogZmVlM2YwMGMgIERhdGE6IDQxODENCglD
YXBhYmlsaXRpZXM6IFtiMF0gU3Vic3lzdGVtOiBBVEkgVGVjaG5vbG9naWVzIEluYyBEZXZp
Y2UgWzEwMDI6NWExMV0NCglDYXBhYmlsaXRpZXM6IFtiOF0gSHlwZXJUcmFuc3BvcnQ6IE1T
SSBNYXBwaW5nIEVuYWJsZSsgRml4ZWQrDQoJQ2FwYWJpbGl0aWVzOiBbMTAwIHYxXSBWZW5k
b3IgU3BlY2lmaWMgSW5mb3JtYXRpb246IElEPTAwMDEgUmV2PTEgTGVuPTAxMCA8Pz4NCglD
YXBhYmlsaXRpZXM6IFsxOTAgdjFdIEFjY2VzcyBDb250cm9sIFNlcnZpY2VzDQoJCUFDU0Nh
cDoJU3JjVmFsaWQrIFRyYW5zQmxrKyBSZXFSZWRpcisgQ21wbHRSZWRpcisgVXBzdHJlYW1G
d2QrIEVncmVzc0N0cmwtIERpcmVjdFRyYW5zKw0KCQlBQ1NDdGw6CVNyY1ZhbGlkKyBUcmFu
c0Jsay0gUmVxUmVkaXIrIENtcGx0UmVkaXIrIFVwc3RyZWFtRndkKyBFZ3Jlc3NDdHJsLSBE
aXJlY3RUcmFucy0NCglLZXJuZWwgZHJpdmVyIGluIHVzZTogcGNpZXBvcnQNCg0KMDA6MTEu
MCBTQVRBIGNvbnRyb2xsZXIgWzAxMDZdOiBBVEkgVGVjaG5vbG9naWVzIEluYyBTQjd4MC9T
Qjh4MC9TQjl4MCBTQVRBIENvbnRyb2xsZXIgW0lERSBtb2RlXSBbMTAwMjo0MzkwXSAocmV2
IDQwKSAocHJvZy1pZiAwMSBbQUhDSSAxLjBdKQ0KCVN1YnN5c3RlbTogTWljcm8tU3RhciBJ
bnRlcm5hdGlvbmFsIENvLiwgTHRkLiBEZXZpY2UgWzE0NjI6NzY0MF0NCglDb250cm9sOiBJ
L08rIE1lbSsgQnVzTWFzdGVyKyBTcGVjQ3ljbGUtIE1lbVdJTlYtIFZHQVNub29wLSBQYXJF
cnItIFN0ZXBwaW5nLSBTRVJSKyBGYXN0QjJCLSBEaXNJTlR4Kw0KCVN0YXR1czogQ2FwKyA2
Nk1IeisgVURGLSBGYXN0QjJCLSBQYXJFcnItIERFVlNFTD1tZWRpdW0gPlRBYm9ydC0gPFRB
Ym9ydC0gPE1BYm9ydC0gPlNFUlItIDxQRVJSLSBJTlR4LQ0KCUxhdGVuY3k6IDY0LCBDYWNo
ZSBMaW5lIFNpemU6IDY0IGJ5dGVzDQoJSW50ZXJydXB0OiBwaW4gQSByb3V0ZWQgdG8gSVJR
IDExOQ0KCVJlZ2lvbiAwOiBJL08gcG9ydHMgYXQgNzAwMCBbc2l6ZT04XQ0KCVJlZ2lvbiAx
OiBJL08gcG9ydHMgYXQgNjAwMCBbc2l6ZT00XQ0KCVJlZ2lvbiAyOiBJL08gcG9ydHMgYXQg
NTAwMCBbc2l6ZT04XQ0KCVJlZ2lvbiAzOiBJL08gcG9ydHMgYXQgMzAwMCBbc2l6ZT00XQ0K
CVJlZ2lvbiA0OiBJL08gcG9ydHMgYXQgMjAwMCBbc2l6ZT0xNl0NCglSZWdpb24gNTogTWVt
b3J5IGF0IGY5NmZmMDAwICgzMi1iaXQsIG5vbi1wcmVmZXRjaGFibGUpIFtzaXplPTFLXQ0K
CUNhcGFiaWxpdGllczogWzUwXSBNU0k6IEVuYWJsZSsgQ291bnQ9MS80IE1hc2thYmxlLSA2
NGJpdCsNCgkJQWRkcmVzczogMDAwMDAwMDBmZWUwMTAwYyAgRGF0YTogNDFhOQ0KCUNhcGFi
aWxpdGllczogWzcwXSBTQVRBIEhCQSB2MS4wIEluQ2ZnU3BhY2UNCglDYXBhYmlsaXRpZXM6
IFthNF0gUENJIEFkdmFuY2VkIEZlYXR1cmVzDQoJCUFGQ2FwOiBUUCsgRkxSKw0KCQlBRkN0
cmw6IEZMUi0NCgkJQUZTdGF0dXM6IFRQLQ0KCUtlcm5lbCBkcml2ZXIgaW4gdXNlOiBhaGNp
DQoNCjAwOjEyLjAgVVNCIGNvbnRyb2xsZXIgWzBjMDNdOiBBVEkgVGVjaG5vbG9naWVzIElu
YyBTQjd4MC9TQjh4MC9TQjl4MCBVU0IgT0hDSTAgQ29udHJvbGxlciBbMTAwMjo0Mzk3XSAo
cHJvZy1pZiAxMCBbT0hDSV0pDQoJU3Vic3lzdGVtOiBNaWNyby1TdGFyIEludGVybmF0aW9u
YWwgQ28uLCBMdGQuIERldmljZSBbMTQ2Mjo3NjQwXQ0KCUNvbnRyb2w6IEkvTysgTWVtKyBC
dXNNYXN0ZXIrIFNwZWNDeWNsZS0gTWVtV0lOVisgVkdBU25vb3AtIFBhckVyci0gU3RlcHBp
bmctIFNFUlIrIEZhc3RCMkItIERpc0lOVHgtDQoJU3RhdHVzOiBDYXAtIDY2TUh6KyBVREYt
IEZhc3RCMkIrIFBhckVyci0gREVWU0VMPW1lZGl1bSA+VEFib3J0LSA8VEFib3J0LSA8TUFi
b3J0LSA+U0VSUi0gPFBFUlItIElOVHgtDQoJTGF0ZW5jeTogNjQsIENhY2hlIExpbmUgU2l6
ZTogNjQgYnl0ZXMNCglJbnRlcnJ1cHQ6IHBpbiBBIHJvdXRlZCB0byBJUlEgMTgNCglSZWdp
b24gMDogTWVtb3J5IGF0IGY5NmY3MDAwICgzMi1iaXQsIG5vbi1wcmVmZXRjaGFibGUpIFtz
aXplPTRLXQ0KCUtlcm5lbCBkcml2ZXIgaW4gdXNlOiBvaGNpX2hjZA0KDQowMDoxMi4yIFVT
QiBjb250cm9sbGVyIFswYzAzXTogQVRJIFRlY2hub2xvZ2llcyBJbmMgU0I3eDAvU0I4eDAv
U0I5eDAgVVNCIEVIQ0kgQ29udHJvbGxlciBbMTAwMjo0Mzk2XSAocHJvZy1pZiAyMCBbRUhD
SV0pDQoJU3Vic3lzdGVtOiBNaWNyby1TdGFyIEludGVybmF0aW9uYWwgQ28uLCBMdGQuIERl
dmljZSBbMTQ2Mjo3NjQwXQ0KCUNvbnRyb2w6IEkvTy0gTWVtKyBCdXNNYXN0ZXIrIFNwZWND
eWNsZS0gTWVtV0lOVisgVkdBU25vb3AtIFBhckVyci0gU3RlcHBpbmctIFNFUlIrIEZhc3RC
MkItIERpc0lOVHgtDQoJU3RhdHVzOiBDYXArIDY2TUh6KyBVREYtIEZhc3RCMkIrIFBhckVy
ci0gREVWU0VMPW1lZGl1bSA+VEFib3J0LSA8VEFib3J0LSA8TUFib3J0LSA+U0VSUi0gPFBF
UlItIElOVHgtDQoJTGF0ZW5jeTogNjQsIENhY2hlIExpbmUgU2l6ZTogNjQgYnl0ZXMNCglJ
bnRlcnJ1cHQ6IHBpbiBCIHJvdXRlZCB0byBJUlEgMTcNCglSZWdpb24gMDogTWVtb3J5IGF0
IGY5NmZmNDAwICgzMi1iaXQsIG5vbi1wcmVmZXRjaGFibGUpIFtzaXplPTI1Nl0NCglDYXBh
YmlsaXRpZXM6IFtjMF0gUG93ZXIgTWFuYWdlbWVudCB2ZXJzaW9uIDINCgkJRmxhZ3M6IFBN
RUNsay0gRFNJLSBEMSsgRDIrIEF1eEN1cnJlbnQ9MG1BIFBNRShEMCssRDErLEQyKyxEM2hv
dCssRDNjb2xkLSkNCgkJU3RhdHVzOiBEMCBOb1NvZnRSc3QtIFBNRS1FbmFibGUtIERTZWw9
MCBEU2NhbGU9MCBQTUUtDQoJCUJyaWRnZTogUE0tIEIzKw0KCUNhcGFiaWxpdGllczogW2U0
XSBEZWJ1ZyBwb3J0OiBCQVI9MSBvZmZzZXQ9MDBlMA0KCUtlcm5lbCBkcml2ZXIgaW4gdXNl
OiBlaGNpX2hjZA0KDQowMDoxMy4wIFVTQiBjb250cm9sbGVyIFswYzAzXTogQVRJIFRlY2hu
b2xvZ2llcyBJbmMgU0I3eDAvU0I4eDAvU0I5eDAgVVNCIE9IQ0kwIENvbnRyb2xsZXIgWzEw
MDI6NDM5N10gKHByb2ctaWYgMTAgW09IQ0ldKQ0KCVN1YnN5c3RlbTogTWljcm8tU3RhciBJ
bnRlcm5hdGlvbmFsIENvLiwgTHRkLiBEZXZpY2UgWzE0NjI6NzY0MF0NCglDb250cm9sOiBJ
L08rIE1lbSsgQnVzTWFzdGVyKyBTcGVjQ3ljbGUtIE1lbVdJTlYrIFZHQVNub29wLSBQYXJF
cnItIFN0ZXBwaW5nLSBTRVJSKyBGYXN0QjJCLSBEaXNJTlR4LQ0KCVN0YXR1czogQ2FwLSA2
Nk1IeisgVURGLSBGYXN0QjJCKyBQYXJFcnItIERFVlNFTD1tZWRpdW0gPlRBYm9ydC0gPFRB
Ym9ydC0gPE1BYm9ydC0gPlNFUlItIDxQRVJSLSBJTlR4LQ0KCUxhdGVuY3k6IDY0LCBDYWNo
ZSBMaW5lIFNpemU6IDY0IGJ5dGVzDQoJSW50ZXJydXB0OiBwaW4gQSByb3V0ZWQgdG8gSVJR
IDE4DQoJUmVnaW9uIDA6IE1lbW9yeSBhdCBmOTZmYzAwMCAoMzItYml0LCBub24tcHJlZmV0
Y2hhYmxlKSBbc2l6ZT00S10NCglLZXJuZWwgZHJpdmVyIGluIHVzZTogb2hjaV9oY2QNCg0K
MDA6MTMuMiBVU0IgY29udHJvbGxlciBbMGMwM106IEFUSSBUZWNobm9sb2dpZXMgSW5jIFNC
N3gwL1NCOHgwL1NCOXgwIFVTQiBFSENJIENvbnRyb2xsZXIgWzEwMDI6NDM5Nl0gKHByb2ct
aWYgMjAgW0VIQ0ldKQ0KCVN1YnN5c3RlbTogTWljcm8tU3RhciBJbnRlcm5hdGlvbmFsIENv
LiwgTHRkLiBEZXZpY2UgWzE0NjI6NzY0MF0NCglDb250cm9sOiBJL08tIE1lbSsgQnVzTWFz
dGVyKyBTcGVjQ3ljbGUtIE1lbVdJTlYrIFZHQVNub29wLSBQYXJFcnItIFN0ZXBwaW5nLSBT
RVJSKyBGYXN0QjJCLSBEaXNJTlR4LQ0KCVN0YXR1czogQ2FwKyA2Nk1IeisgVURGLSBGYXN0
QjJCKyBQYXJFcnItIERFVlNFTD1tZWRpdW0gPlRBYm9ydC0gPFRBYm9ydC0gPE1BYm9ydC0g
PlNFUlItIDxQRVJSLSBJTlR4LQ0KCUxhdGVuY3k6IDY0LCBDYWNoZSBMaW5lIFNpemU6IDY0
IGJ5dGVzDQoJSW50ZXJydXB0OiBwaW4gQiByb3V0ZWQgdG8gSVJRIDE3DQoJUmVnaW9uIDA6
IE1lbW9yeSBhdCBmOTZmZjgwMCAoMzItYml0LCBub24tcHJlZmV0Y2hhYmxlKSBbc2l6ZT0y
NTZdDQoJQ2FwYWJpbGl0aWVzOiBbYzBdIFBvd2VyIE1hbmFnZW1lbnQgdmVyc2lvbiAyDQoJ
CUZsYWdzOiBQTUVDbGstIERTSS0gRDErIEQyKyBBdXhDdXJyZW50PTBtQSBQTUUoRDArLEQx
KyxEMissRDNob3QrLEQzY29sZC0pDQoJCVN0YXR1czogRDAgTm9Tb2Z0UnN0LSBQTUUtRW5h
YmxlLSBEU2VsPTAgRFNjYWxlPTAgUE1FLQ0KCQlCcmlkZ2U6IFBNLSBCMysNCglDYXBhYmls
aXRpZXM6IFtlNF0gRGVidWcgcG9ydDogQkFSPTEgb2Zmc2V0PTAwZTANCglLZXJuZWwgZHJp
dmVyIGluIHVzZTogZWhjaV9oY2QNCg0KMDA6MTQuMCBTTUJ1cyBbMGMwNV06IEFUSSBUZWNo
bm9sb2dpZXMgSW5jIFNCeDAwIFNNQnVzIENvbnRyb2xsZXIgWzEwMDI6NDM4NV0gKHJldiA0
MSkNCglDb250cm9sOiBJL08rIE1lbSsgQnVzTWFzdGVyLSBTcGVjQ3ljbGUtIE1lbVdJTlYt
IFZHQVNub29wLSBQYXJFcnItIFN0ZXBwaW5nLSBTRVJSLSBGYXN0QjJCLSBEaXNJTlR4Kw0K
CVN0YXR1czogQ2FwLSA2Nk1IeisgVURGLSBGYXN0QjJCLSBQYXJFcnItIERFVlNFTD1tZWRp
dW0gPlRBYm9ydC0gPFRBYm9ydC0gPE1BYm9ydC0gPlNFUlItIDxQRVJSLSBJTlR4LQ0KDQow
MDoxNC4xIElERSBpbnRlcmZhY2UgWzAxMDFdOiBBVEkgVGVjaG5vbG9naWVzIEluYyBTQjd4
MC9TQjh4MC9TQjl4MCBJREUgQ29udHJvbGxlciBbMTAwMjo0MzljXSAocmV2IDQwKSAocHJv
Zy1pZiA4YSBbTWFzdGVyIFNlY1AgUHJpUF0pDQoJU3Vic3lzdGVtOiBNaWNyby1TdGFyIElu
dGVybmF0aW9uYWwgQ28uLCBMdGQuIERldmljZSBbMTQ2Mjo3NjQwXQ0KCUNvbnRyb2w6IEkv
TysgTWVtLSBCdXNNYXN0ZXIrIFNwZWNDeWNsZS0gTWVtV0lOVi0gVkdBU25vb3AtIFBhckVy
ci0gU3RlcHBpbmctIFNFUlItIEZhc3RCMkItIERpc0lOVHgtDQoJU3RhdHVzOiBDYXAtIDY2
TUh6KyBVREYtIEZhc3RCMkItIFBhckVyci0gREVWU0VMPW1lZGl1bSA+VEFib3J0LSA8VEFi
b3J0LSA8TUFib3J0LSA+U0VSUi0gPFBFUlItIElOVHgtDQoJTGF0ZW5jeTogMA0KCUludGVy
cnVwdDogcGluIEIgcm91dGVkIHRvIElSUSAwDQoJUmVnaW9uIDA6IEkvTyBwb3J0cyBhdCAw
MWYwIFtzaXplPThdDQoJUmVnaW9uIDE6IEkvTyBwb3J0cyBhdCAwM2Y0IFtzaXplPTFdDQoJ
UmVnaW9uIDI6IEkvTyBwb3J0cyBhdCAwMTcwIFtzaXplPThdDQoJUmVnaW9uIDM6IEkvTyBw
b3J0cyBhdCAwMzc0IFtzaXplPTFdDQoJUmVnaW9uIDQ6IEkvTyBwb3J0cyBhdCBmZjAwIFtz
aXplPTE2XQ0KDQowMDoxNC4yIEF1ZGlvIGRldmljZSBbMDQwM106IEFUSSBUZWNobm9sb2dp
ZXMgSW5jIFNCeDAwIEF6YWxpYSAoSW50ZWwgSERBKSBbMTAwMjo0MzgzXSAocmV2IDQwKQ0K
CVN1YnN5c3RlbTogTWljcm8tU3RhciBJbnRlcm5hdGlvbmFsIENvLiwgTHRkLiBEZXZpY2Ug
WzE0NjI6NzY0MF0NCglDb250cm9sOiBJL08tIE1lbSsgQnVzTWFzdGVyKyBTcGVjQ3ljbGUt
IE1lbVdJTlYtIFZHQVNub29wLSBQYXJFcnItIFN0ZXBwaW5nLSBTRVJSLSBGYXN0QjJCLSBE
aXNJTlR4LQ0KCVN0YXR1czogQ2FwKyA2Nk1Iei0gVURGLSBGYXN0QjJCLSBQYXJFcnItIERF
VlNFTD1zbG93ID5UQWJvcnQtIDxUQWJvcnQtIDxNQWJvcnQtID5TRVJSLSA8UEVSUi0gSU5U
eC0NCglMYXRlbmN5OiA2NCwgQ2FjaGUgTGluZSBTaXplOiA2NCBieXRlcw0KCUludGVycnVw
dDogcGluIEEgcm91dGVkIHRvIElSUSAxNg0KCVJlZ2lvbiAwOiBNZW1vcnkgYXQgZjk2Zjgw
MDAgKDY0LWJpdCwgbm9uLXByZWZldGNoYWJsZSkgW3NpemU9MTZLXQ0KCUNhcGFiaWxpdGll
czogWzUwXSBQb3dlciBNYW5hZ2VtZW50IHZlcnNpb24gMg0KCQlGbGFnczogUE1FQ2xrLSBE
U0ktIEQxLSBEMi0gQXV4Q3VycmVudD01NW1BIFBNRShEMCssRDEtLEQyLSxEM2hvdCssRDNj
b2xkKykNCgkJU3RhdHVzOiBEMCBOb1NvZnRSc3QtIFBNRS1FbmFibGUtIERTZWw9MCBEU2Nh
bGU9MCBQTUUtDQoJS2VybmVsIGRyaXZlciBpbiB1c2U6IHNuZF9oZGFfaW50ZWwNCg0KMDA6
MTQuMyBJU0EgYnJpZGdlIFswNjAxXTogQVRJIFRlY2hub2xvZ2llcyBJbmMgU0I3eDAvU0I4
eDAvU0I5eDAgTFBDIGhvc3QgY29udHJvbGxlciBbMTAwMjo0MzlkXSAocmV2IDQwKQ0KCVN1
YnN5c3RlbTogTWljcm8tU3RhciBJbnRlcm5hdGlvbmFsIENvLiwgTHRkLiBEZXZpY2UgWzE0
NjI6NzY0MF0NCglDb250cm9sOiBJL08rIE1lbSsgQnVzTWFzdGVyKyBTcGVjQ3ljbGUrIE1l
bVdJTlYtIFZHQVNub29wLSBQYXJFcnItIFN0ZXBwaW5nLSBTRVJSLSBGYXN0QjJCLSBEaXNJ
TlR4LQ0KCVN0YXR1czogQ2FwLSA2Nk1IeisgVURGLSBGYXN0QjJCLSBQYXJFcnItIERFVlNF
TD1tZWRpdW0gPlRBYm9ydC0gPFRBYm9ydC0gPE1BYm9ydC0gPlNFUlItIDxQRVJSLSBJTlR4
LQ0KCUxhdGVuY3k6IDANCg0KMDA6MTQuNCBQQ0kgYnJpZGdlIFswNjA0XTogQVRJIFRlY2hu
b2xvZ2llcyBJbmMgU0J4MDAgUENJIHRvIFBDSSBCcmlkZ2UgWzEwMDI6NDM4NF0gKHJldiA0
MCkgKHByb2ctaWYgMDAgW05vcm1hbCBkZWNvZGVdKQ0KCUNvbnRyb2w6IEkvTysgTWVtLSBC
dXNNYXN0ZXIrIFNwZWNDeWNsZS0gTWVtV0lOVi0gVkdBU25vb3AtIFBhckVyci0gU3RlcHBp
bmctIFNFUlIrIEZhc3RCMkItIERpc0lOVHgtDQoJU3RhdHVzOiBDYXAtIDY2TUh6KyBVREYt
IEZhc3RCMkIrIFBhckVyci0gREVWU0VMPW1lZGl1bSA+VEFib3J0LSA8VEFib3J0LSA8TUFi
b3J0LSA+U0VSUi0gPFBFUlItIElOVHgtDQoJTGF0ZW5jeTogNjQNCglCdXM6IHByaW1hcnk9
MDAsIHNlY29uZGFyeT0wMywgc3Vib3JkaW5hdGU9MDMsIHNlYy1sYXRlbmN5PTY0DQoJSS9P
IGJlaGluZCBicmlkZ2U6IDAwMDBhMDAwLTAwMDBhZmZmDQoJTWVtb3J5IGJlaGluZCBicmlk
Z2U6IGZmZjAwMDAwLTAwMGZmZmZmDQoJUHJlZmV0Y2hhYmxlIG1lbW9yeSBiZWhpbmQgYnJp
ZGdlOiBmZmYwMDAwMC0wMDBmZmZmZg0KCVNlY29uZGFyeSBzdGF0dXM6IDY2TUh6LSBGYXN0
QjJCKyBQYXJFcnItIERFVlNFTD1tZWRpdW0gPlRBYm9ydC0gPFRBYm9ydC0gPE1BYm9ydCsg
PFNFUlItIDxQRVJSLQ0KCUJyaWRnZUN0bDogUGFyaXR5KyBTRVJSKyBOb0lTQSsgVkdBLSBN
QWJvcnQtID5SZXNldC0gRmFzdEIyQi0NCgkJUHJpRGlzY1Rtci0gU2VjRGlzY1Rtci0gRGlz
Y1RtclN0YXQtIERpc2NUbXJTRVJSRW4tDQoNCjAwOjE0LjUgVVNCIGNvbnRyb2xsZXIgWzBj
MDNdOiBBVEkgVGVjaG5vbG9naWVzIEluYyBTQjd4MC9TQjh4MC9TQjl4MCBVU0IgT0hDSTIg
Q29udHJvbGxlciBbMTAwMjo0Mzk5XSAocHJvZy1pZiAxMCBbT0hDSV0pDQoJU3Vic3lzdGVt
OiBNaWNyby1TdGFyIEludGVybmF0aW9uYWwgQ28uLCBMdGQuIERldmljZSBbMTQ2Mjo3NjQw
XQ0KCUNvbnRyb2w6IEkvTysgTWVtKyBCdXNNYXN0ZXIrIFNwZWNDeWNsZS0gTWVtV0lOVisg
VkdBU25vb3AtIFBhckVyci0gU3RlcHBpbmctIFNFUlIrIEZhc3RCMkItIERpc0lOVHgtDQoJ
U3RhdHVzOiBDYXAtIDY2TUh6KyBVREYtIEZhc3RCMkIrIFBhckVyci0gREVWU0VMPW1lZGl1
bSA+VEFib3J0LSA8VEFib3J0LSA8TUFib3J0LSA+U0VSUi0gPFBFUlItIElOVHgtDQoJTGF0
ZW5jeTogNjQsIENhY2hlIExpbmUgU2l6ZTogNjQgYnl0ZXMNCglJbnRlcnJ1cHQ6IHBpbiBD
IHJvdXRlZCB0byBJUlEgMTgNCglSZWdpb24gMDogTWVtb3J5IGF0IGY5NmZkMDAwICgzMi1i
aXQsIG5vbi1wcmVmZXRjaGFibGUpIFtzaXplPTRLXQ0KCUtlcm5lbCBkcml2ZXIgaW4gdXNl
OiBvaGNpX2hjZA0KDQowMDoxNS4wIFBDSSBicmlkZ2UgWzA2MDRdOiBBVEkgVGVjaG5vbG9n
aWVzIEluYyBTQjcwMC9TQjgwMC9TQjkwMCBQQ0kgdG8gUENJIGJyaWRnZSAoUENJRSBwb3J0
IDApIFsxMDAyOjQzYTBdIChwcm9nLWlmIDAwIFtOb3JtYWwgZGVjb2RlXSkNCglDb250cm9s
OiBJL08tIE1lbS0gQnVzTWFzdGVyKyBTcGVjQ3ljbGUtIE1lbVdJTlYtIFZHQVNub29wLSBQ
YXJFcnItIFN0ZXBwaW5nLSBTRVJSKyBGYXN0QjJCLSBEaXNJTlR4Kw0KCVN0YXR1czogQ2Fw
KyA2Nk1Iei0gVURGLSBGYXN0QjJCLSBQYXJFcnItIERFVlNFTD1mYXN0ID5UQWJvcnQtIDxU
QWJvcnQtIDxNQWJvcnQtID5TRVJSLSA8UEVSUi0gSU5UeC0NCglMYXRlbmN5OiAwLCBDYWNo
ZSBMaW5lIFNpemU6IDY0IGJ5dGVzDQoJQnVzOiBwcmltYXJ5PTAwLCBzZWNvbmRhcnk9MDIs
IHN1Ym9yZGluYXRlPTAyLCBzZWMtbGF0ZW5jeT0wDQoJSS9PIGJlaGluZCBicmlkZ2U6IDAw
MDBmMDAwLTAwMDAwZmZmDQoJTWVtb3J5IGJlaGluZCBicmlkZ2U6IGZmZjAwMDAwLTAwMGZm
ZmZmDQoJUHJlZmV0Y2hhYmxlIG1lbW9yeSBiZWhpbmQgYnJpZGdlOiAwMDAwMDAwMGZmZjAw
MDAwLTAwMDAwMDAwMDAwZmZmZmYNCglTZWNvbmRhcnkgc3RhdHVzOiA2Nk1Iei0gRmFzdEIy
Qi0gUGFyRXJyLSBERVZTRUw9ZmFzdCA+VEFib3J0LSA8VEFib3J0LSA8TUFib3J0LSA8U0VS
Ui0gPFBFUlItDQoJQnJpZGdlQ3RsOiBQYXJpdHkrIFNFUlIrIE5vSVNBKyBWR0EtIE1BYm9y
dC0gPlJlc2V0LSBGYXN0QjJCLQ0KCQlQcmlEaXNjVG1yLSBTZWNEaXNjVG1yLSBEaXNjVG1y
U3RhdC0gRGlzY1RtclNFUlJFbi0NCglDYXBhYmlsaXRpZXM6IFs1MF0gUG93ZXIgTWFuYWdl
bWVudCB2ZXJzaW9uIDMNCgkJRmxhZ3M6IFBNRUNsay0gRFNJLSBEMSsgRDIrIEF1eEN1cnJl
bnQ9MG1BIFBNRShEMC0sRDEtLEQyLSxEM2hvdC0sRDNjb2xkLSkNCgkJU3RhdHVzOiBEMCBO
b1NvZnRSc3QtIFBNRS1FbmFibGUtIERTZWw9MCBEU2NhbGU9MCBQTUUtDQoJQ2FwYWJpbGl0
aWVzOiBbNThdIEV4cHJlc3MgKHYyKSBSb290IFBvcnQgKFNsb3QrKSwgTVNJIDAwDQoJCURl
dkNhcDoJTWF4UGF5bG9hZCAxMjggYnl0ZXMsIFBoYW50RnVuYyAwLCBMYXRlbmN5IEwwcyA8
NjRucywgTDEgPDF1cw0KCQkJRXh0VGFnKyBSQkUrIEZMUmVzZXQtDQoJCURldkN0bDoJUmVw
b3J0IGVycm9yczogQ29ycmVjdGFibGUtIE5vbi1GYXRhbC0gRmF0YWwtIFVuc3VwcG9ydGVk
LQ0KCQkJUmx4ZE9yZCsgRXh0VGFnLSBQaGFudEZ1bmMtIEF1eFB3ci0gTm9Tbm9vcCsNCgkJ
CU1heFBheWxvYWQgMTI4IGJ5dGVzLCBNYXhSZWFkUmVxIDEyOCBieXRlcw0KCQlEZXZTdGE6
CUNvcnJFcnItIFVuY29yckVyci0gRmF0YWxFcnItIFVuc3VwcFJlcS0gQXV4UHdyLSBUcmFu
c1BlbmQtDQoJCUxua0NhcDoJUG9ydCAjMjQ3LCBTcGVlZCAyLjVHVC9zLCBXaWR0aCB4MSwg
QVNQTSBMMHMgTDEsIExhdGVuY3kgTDAgPDY0bnMsIEwxIDwxdXMNCgkJCUNsb2NrUE0tIFN1
cnByaXNlLSBMTEFjdFJlcCsgQndOb3QrDQoJCUxua0N0bDoJQVNQTSBEaXNhYmxlZDsgUkNC
IDY0IGJ5dGVzIERpc2FibGVkLSBSZXRyYWluLSBDb21tQ2xrLQ0KCQkJRXh0U3luY2gtIENs
b2NrUE0tIEF1dFdpZERpcy0gQldJbnQtIEF1dEJXSW50LQ0KCQlMbmtTdGE6CVNwZWVkIHVu
a25vd24sIFdpZHRoIHgxNiwgVHJFcnItIFRyYWluLSBTbG90Q2xrKyBETEFjdGl2ZS0gQldN
Z210LSBBQldNZ210LQ0KCQlTbHRDYXA6CUF0dG5CdG4tIFB3ckN0cmwtIE1STC0gQXR0bklu
ZC0gUHdySW5kLSBIb3RQbHVnLSBTdXJwcmlzZS0NCgkJCVNsb3QgIzMyLCBQb3dlckxpbWl0
IDc1LjAwMFc7IEludGVybG9jay0gTm9Db21wbCsNCgkJU2x0Q3RsOglFbmFibGU6IEF0dG5C
dG4tIFB3ckZsdC0gTVJMLSBQcmVzRGV0LSBDbWRDcGx0LSBIUElycS0gTGlua0NoZy0NCgkJ
CUNvbnRyb2w6IEF0dG5JbmQgVW5rbm93biwgUHdySW5kIFVua25vd24sIFBvd2VyLSBJbnRl
cmxvY2stDQoJCVNsdFN0YToJU3RhdHVzOiBBdHRuQnRuLSBQb3dlckZsdC0gTVJMLSBDbWRD
cGx0LSBQcmVzRGV0LSBJbnRlcmxvY2stDQoJCQlDaGFuZ2VkOiBNUkwtIFByZXNEZXQtIExp
bmtTdGF0ZS0NCgkJUm9vdEN0bDogRXJyQ29ycmVjdGFibGUtIEVyck5vbi1GYXRhbC0gRXJy
RmF0YWwtIFBNRUludEVuYS0gQ1JTVmlzaWJsZS0NCgkJUm9vdENhcDogQ1JTVmlzaWJsZS0N
CgkJUm9vdFN0YTogUE1FIFJlcUlEIDAwMDAsIFBNRVN0YXR1cy0gUE1FUGVuZGluZy0NCgkJ
RGV2Q2FwMjogQ29tcGxldGlvbiBUaW1lb3V0OiBSYW5nZSBBQkNELCBUaW1lb3V0RGlzKyBB
UklGd2QtDQoJCURldkN0bDI6IENvbXBsZXRpb24gVGltZW91dDogNjVtcyB0byAyMTBtcywg
VGltZW91dERpcy0gQVJJRndkLQ0KCQlMbmtDdGwyOiBUYXJnZXQgTGluayBTcGVlZDogMi41
R1QvcywgRW50ZXJDb21wbGlhbmNlLSBTcGVlZERpcy0sIFNlbGVjdGFibGUgRGUtZW1waGFz
aXM6IC0zLjVkQg0KCQkJIFRyYW5zbWl0IE1hcmdpbjogTm9ybWFsIE9wZXJhdGluZyBSYW5n
ZSwgRW50ZXJNb2RpZmllZENvbXBsaWFuY2UtIENvbXBsaWFuY2VTT1MtDQoJCQkgQ29tcGxp
YW5jZSBEZS1lbXBoYXNpczogLTZkQg0KCQlMbmtTdGEyOiBDdXJyZW50IERlLWVtcGhhc2lz
IExldmVsOiAtNmRCDQoJQ2FwYWJpbGl0aWVzOiBbYTBdIE1TSTogRW5hYmxlKyBDb3VudD0x
LzEgTWFza2FibGUtIDY0Yml0Kw0KCQlBZGRyZXNzOiAwMDAwMDAwMGZlZTNmMDBjICBEYXRh
OiA0MTg5DQoJQ2FwYWJpbGl0aWVzOiBbYjBdIFN1YnN5c3RlbTogQVRJIFRlY2hub2xvZ2ll
cyBJbmMgRGV2aWNlIFsxMDAyOjAwMDBdDQoJQ2FwYWJpbGl0aWVzOiBbYjhdIEh5cGVyVHJh
bnNwb3J0OiBNU0kgTWFwcGluZyBFbmFibGUrIEZpeGVkKw0KCUNhcGFiaWxpdGllczogWzEw
MCB2MV0gVmVuZG9yIFNwZWNpZmljIEluZm9ybWF0aW9uOiBJRD0wMDAxIFJldj0xIExlbj0w
MTAgPD8+DQoJS2VybmVsIGRyaXZlciBpbiB1c2U6IHBjaWVwb3J0DQoNCjAwOjE2LjAgVVNC
IGNvbnRyb2xsZXIgWzBjMDNdOiBBVEkgVGVjaG5vbG9naWVzIEluYyBTQjd4MC9TQjh4MC9T
Qjl4MCBVU0IgT0hDSTAgQ29udHJvbGxlciBbMTAwMjo0Mzk3XSAocHJvZy1pZiAxMCBbT0hD
SV0pDQoJU3Vic3lzdGVtOiBNaWNyby1TdGFyIEludGVybmF0aW9uYWwgQ28uLCBMdGQuIERl
dmljZSBbMTQ2Mjo3NjQwXQ0KCUNvbnRyb2w6IEkvTysgTWVtKyBCdXNNYXN0ZXIrIFNwZWND
eWNsZS0gTWVtV0lOVisgVkdBU25vb3AtIFBhckVyci0gU3RlcHBpbmctIFNFUlIrIEZhc3RC
MkItIERpc0lOVHgtDQoJU3RhdHVzOiBDYXAtIDY2TUh6KyBVREYtIEZhc3RCMkIrIFBhckVy
ci0gREVWU0VMPW1lZGl1bSA+VEFib3J0LSA8VEFib3J0LSA8TUFib3J0LSA+U0VSUi0gPFBF
UlItIElOVHgtDQoJTGF0ZW5jeTogNjQsIENhY2hlIExpbmUgU2l6ZTogNjQgYnl0ZXMNCglJ
bnRlcnJ1cHQ6IHBpbiBBIHJvdXRlZCB0byBJUlEgMTgNCglSZWdpb24gMDogTWVtb3J5IGF0
IGY5NmZlMDAwICgzMi1iaXQsIG5vbi1wcmVmZXRjaGFibGUpIFtzaXplPTRLXQ0KCUtlcm5l
bCBkcml2ZXIgaW4gdXNlOiBvaGNpX2hjZA0KDQowMDoxNi4yIFVTQiBjb250cm9sbGVyIFsw
YzAzXTogQVRJIFRlY2hub2xvZ2llcyBJbmMgU0I3eDAvU0I4eDAvU0I5eDAgVVNCIEVIQ0kg
Q29udHJvbGxlciBbMTAwMjo0Mzk2XSAocHJvZy1pZiAyMCBbRUhDSV0pDQoJU3Vic3lzdGVt
OiBNaWNyby1TdGFyIEludGVybmF0aW9uYWwgQ28uLCBMdGQuIERldmljZSBbMTQ2Mjo3NjQw
XQ0KCUNvbnRyb2w6IEkvTy0gTWVtKyBCdXNNYXN0ZXIrIFNwZWNDeWNsZS0gTWVtV0lOVisg
VkdBU25vb3AtIFBhckVyci0gU3RlcHBpbmctIFNFUlIrIEZhc3RCMkItIERpc0lOVHgtDQoJ
U3RhdHVzOiBDYXArIDY2TUh6KyBVREYtIEZhc3RCMkIrIFBhckVyci0gREVWU0VMPW1lZGl1
bSA+VEFib3J0LSA8VEFib3J0LSA8TUFib3J0LSA+U0VSUi0gPFBFUlItIElOVHgtDQoJTGF0
ZW5jeTogNjQsIENhY2hlIExpbmUgU2l6ZTogNjQgYnl0ZXMNCglJbnRlcnJ1cHQ6IHBpbiBC
IHJvdXRlZCB0byBJUlEgMTcNCglSZWdpb24gMDogTWVtb3J5IGF0IGY5NmZmYzAwICgzMi1i
aXQsIG5vbi1wcmVmZXRjaGFibGUpIFtzaXplPTI1Nl0NCglDYXBhYmlsaXRpZXM6IFtjMF0g
UG93ZXIgTWFuYWdlbWVudCB2ZXJzaW9uIDINCgkJRmxhZ3M6IFBNRUNsay0gRFNJLSBEMSsg
RDIrIEF1eEN1cnJlbnQ9MG1BIFBNRShEMCssRDErLEQyKyxEM2hvdCssRDNjb2xkLSkNCgkJ
U3RhdHVzOiBEMCBOb1NvZnRSc3QtIFBNRS1FbmFibGUtIERTZWw9MCBEU2NhbGU9MCBQTUUt
DQoJCUJyaWRnZTogUE0tIEIzKw0KCUNhcGFiaWxpdGllczogW2U0XSBEZWJ1ZyBwb3J0OiBC
QVI9MSBvZmZzZXQ9MDBlMA0KCUtlcm5lbCBkcml2ZXIgaW4gdXNlOiBlaGNpX2hjZA0KDQow
MDoxOC4wIEhvc3QgYnJpZGdlIFswNjAwXTogQWR2YW5jZWQgTWljcm8gRGV2aWNlcyBbQU1E
XSBGYW1pbHkgMTBoIFByb2Nlc3NvciBIeXBlclRyYW5zcG9ydCBDb25maWd1cmF0aW9uIFsx
MDIyOjEyMDBdDQoJQ29udHJvbDogSS9PLSBNZW0tIEJ1c01hc3Rlci0gU3BlY0N5Y2xlLSBN
ZW1XSU5WLSBWR0FTbm9vcC0gUGFyRXJyLSBTdGVwcGluZy0gU0VSUi0gRmFzdEIyQi0gRGlz
SU5UeC0NCglTdGF0dXM6IENhcCsgNjZNSHotIFVERi0gRmFzdEIyQi0gUGFyRXJyLSBERVZT
RUw9ZmFzdCA+VEFib3J0LSA8VEFib3J0LSA8TUFib3J0LSA+U0VSUi0gPFBFUlItIElOVHgt
DQoJQ2FwYWJpbGl0aWVzOiBbODBdIEh5cGVyVHJhbnNwb3J0OiBIb3N0IG9yIFNlY29uZGFy
eSBJbnRlcmZhY2UNCgkJQ29tbWFuZDogV2FybVJzdCsgRGJsRW5kLSBEZXZOdW09MCBDaGFp
blNpZGUtIEhvc3RIaWRlKyBTbGF2ZS0gPEVPQ0Vyci0gRFVMLQ0KCQlMaW5rIENvbnRyb2w6
IENGbEUtIENTVC0gQ0ZFLSA8TGtGYWlsLSBJbml0KyBFT0MtIFRYTy0gPENSQ0Vycj0wIElz
b2NFbi0gTFNFbisgRXh0Q1RMLSA2NGItDQoJCUxpbmsgQ29uZmlnOiBNTFdJPTE2Yml0IER3
RmNJbi0gTUxXTz0xNmJpdCBEd0ZjT3V0LSBMV0k9MTZiaXQgRHdGY0luRW4tIExXTz0xNmJp
dCBEd0ZjT3V0RW4tDQoJCVJldmlzaW9uIElEOiAzLjAwDQoJCUxpbmsgRnJlcXVlbmN5OiBb
Yl0NCgkJTGluayBFcnJvcjogPFByb3QtIDxPdmZsLSA8RU9DLSBDVExUbS0NCgkJTGluayBG
cmVxdWVuY3kgQ2FwYWJpbGl0eTogMjAwTUh6KyAzMDBNSHotIDQwME1IeisgNTAwTUh6LSA2
MDBNSHorIDgwME1IeisgMS4wR0h6KyAxLjJHSHorIDEuNEdIei0gMS42R0h6LSBWZW5kLQ0K
CQlGZWF0dXJlIENhcGFiaWxpdHk6IElzb2NGQysgTERUU1RPUCsgQ1JDVE0tIEVDVExULSA2
NGJBKyBVSURSRC0gRXh0UlMtIFVDbmZFLQ0KDQowMDoxOC4xIEhvc3QgYnJpZGdlIFswNjAw
XTogQWR2YW5jZWQgTWljcm8gRGV2aWNlcyBbQU1EXSBGYW1pbHkgMTBoIFByb2Nlc3NvciBB
ZGRyZXNzIE1hcCBbMTAyMjoxMjAxXQ0KCUNvbnRyb2w6IEkvTy0gTWVtLSBCdXNNYXN0ZXIt
IFNwZWNDeWNsZS0gTWVtV0lOVi0gVkdBU25vb3AtIFBhckVyci0gU3RlcHBpbmctIFNFUlIt
IEZhc3RCMkItIERpc0lOVHgtDQoJU3RhdHVzOiBDYXAtIDY2TUh6LSBVREYtIEZhc3RCMkIt
IFBhckVyci0gREVWU0VMPWZhc3QgPlRBYm9ydC0gPFRBYm9ydC0gPE1BYm9ydC0gPlNFUlIt
IDxQRVJSLSBJTlR4LQ0KDQowMDoxOC4yIEhvc3QgYnJpZGdlIFswNjAwXTogQWR2YW5jZWQg
TWljcm8gRGV2aWNlcyBbQU1EXSBGYW1pbHkgMTBoIFByb2Nlc3NvciBEUkFNIENvbnRyb2xs
ZXIgWzEwMjI6MTIwMl0NCglDb250cm9sOiBJL08tIE1lbS0gQnVzTWFzdGVyLSBTcGVjQ3lj
bGUtIE1lbVdJTlYtIFZHQVNub29wLSBQYXJFcnItIFN0ZXBwaW5nLSBTRVJSLSBGYXN0QjJC
LSBEaXNJTlR4LQ0KCVN0YXR1czogQ2FwLSA2Nk1Iei0gVURGLSBGYXN0QjJCLSBQYXJFcnIt
IERFVlNFTD1mYXN0ID5UQWJvcnQtIDxUQWJvcnQtIDxNQWJvcnQtID5TRVJSLSA8UEVSUi0g
SU5UeC0NCg0KMDA6MTguMyBIb3N0IGJyaWRnZSBbMDYwMF06IEFkdmFuY2VkIE1pY3JvIERl
dmljZXMgW0FNRF0gRmFtaWx5IDEwaCBQcm9jZXNzb3IgTWlzY2VsbGFuZW91cyBDb250cm9s
IFsxMDIyOjEyMDNdDQoJQ29udHJvbDogSS9PLSBNZW0tIEJ1c01hc3Rlci0gU3BlY0N5Y2xl
LSBNZW1XSU5WLSBWR0FTbm9vcC0gUGFyRXJyLSBTdGVwcGluZy0gU0VSUi0gRmFzdEIyQi0g
RGlzSU5UeC0NCglTdGF0dXM6IENhcCsgNjZNSHotIFVERi0gRmFzdEIyQi0gUGFyRXJyLSBE
RVZTRUw9ZmFzdCA+VEFib3J0LSA8VEFib3J0LSA8TUFib3J0LSA+U0VSUi0gPFBFUlItIElO
VHgtDQoJQ2FwYWJpbGl0aWVzOiBbZjBdIFNlY3VyZSBkZXZpY2UgPD8+DQoJS2VybmVsIGRy
aXZlciBpbiB1c2U6IGsxMHRlbXANCg0KMDA6MTguNCBIb3N0IGJyaWRnZSBbMDYwMF06IEFk
dmFuY2VkIE1pY3JvIERldmljZXMgW0FNRF0gRmFtaWx5IDEwaCBQcm9jZXNzb3IgTGluayBD
b250cm9sIFsxMDIyOjEyMDRdDQoJQ29udHJvbDogSS9PLSBNZW0tIEJ1c01hc3Rlci0gU3Bl
Y0N5Y2xlLSBNZW1XSU5WLSBWR0FTbm9vcC0gUGFyRXJyLSBTdGVwcGluZy0gU0VSUi0gRmFz
dEIyQi0gRGlzSU5UeC0NCglTdGF0dXM6IENhcC0gNjZNSHotIFVERi0gRmFzdEIyQi0gUGFy
RXJyLSBERVZTRUw9ZmFzdCA+VEFib3J0LSA8VEFib3J0LSA8TUFib3J0LSA+U0VSUi0gPFBF
UlItIElOVHgtDQoNCjAzOjA2LjAgTXVsdGltZWRpYSBhdWRpbyBjb250cm9sbGVyIFswNDAx
XTogQy1NZWRpYSBFbGVjdHJvbmljcyBJbmMgQ004NzM4IFsxM2Y2OjAxMTFdIChyZXYgMTAp
DQoJU3Vic3lzdGVtOiBDLU1lZGlhIEVsZWN0cm9uaWNzIEluYyBDTUk4NzM4L0MzRFggUENJ
IEF1ZGlvIERldmljZSBbMTNmNjowMTExXQ0KCUNvbnRyb2w6IEkvTysgTWVtLSBCdXNNYXN0
ZXIrIFNwZWNDeWNsZS0gTWVtV0lOVi0gVkdBU25vb3AtIFBhckVyci0gU3RlcHBpbmctIFNF
UlItIEZhc3RCMkItIERpc0lOVHgtDQoJU3RhdHVzOiBDYXArIDY2TUh6LSBVREYtIEZhc3RC
MkItIFBhckVyci0gREVWU0VMPW1lZGl1bSA+VEFib3J0LSA8VEFib3J0LSA8TUFib3J0LSA+
U0VSUi0gPFBFUlItIElOVHgtDQoJTGF0ZW5jeTogNjQgKDUwMG5zIG1pbiwgNjAwMG5zIG1h
eCkNCglJbnRlcnJ1cHQ6IHBpbiBBIHJvdXRlZCB0byBJUlEgMjINCglSZWdpb24gMDogSS9P
IHBvcnRzIGF0IGE4MDAgW3NpemU9MjU2XQ0KCUNhcGFiaWxpdGllczogW2MwXSBQb3dlciBN
YW5hZ2VtZW50IHZlcnNpb24gMg0KCQlGbGFnczogUE1FQ2xrLSBEU0ktIEQxKyBEMisgQXV4
Q3VycmVudD0wbUEgUE1FKEQwLSxEMS0sRDItLEQzaG90LSxEM2NvbGQtKQ0KCQlTdGF0dXM6
IEQwIE5vU29mdFJzdC0gUE1FLUVuYWJsZS0gRFNlbD0wIERTY2FsZT0wIFBNRS0NCglLZXJu
ZWwgZHJpdmVyIGluIHVzZTogcGNpYmFjaw0KDQowNDowMC4wIFVTQiBjb250cm9sbGVyIFsw
YzAzXTogTmV0TW9zIFRlY2hub2xvZ3kgTUNTOTk5MCBQQ0llIHRvIDTigJBQb3J0IFVTQiAy
LjAgSG9zdCBDb250cm9sbGVyIFs5NzEwOjk5OTBdIChwcm9nLWlmIDEwIFtPSENJXSkNCglT
dWJzeXN0ZW06IERldmljZSBbYTAwMDo0MDAwXQ0KCUNvbnRyb2w6IEkvTy0gTWVtLSBCdXNN
YXN0ZXItIFNwZWNDeWNsZS0gTWVtV0lOVi0gVkdBU25vb3AtIFBhckVyci0gU3RlcHBpbmct
IFNFUlItIEZhc3RCMkItIERpc0lOVHgtDQoJU3RhdHVzOiBDYXArIDY2TUh6LSBVREYtIEZh
c3RCMkItIFBhckVyci0gREVWU0VMPWZhc3QgPlRBYm9ydC0gPFRBYm9ydC0gPE1BYm9ydC0g
PlNFUlItIDxQRVJSLSBJTlR4LQ0KCUludGVycnVwdDogcGluIEEgcm91dGVkIHRvIElSUSA0
MA0KCVJlZ2lvbiAwOiBNZW1vcnkgYXQgZjk4ZjgwMDAgKDMyLWJpdCwgbm9uLXByZWZldGNo
YWJsZSkgW2Rpc2FibGVkXSBbc2l6ZT00S10NCglDYXBhYmlsaXRpZXM6IFs1MF0gTVNJOiBF
bmFibGUtIENvdW50PTEvMSBNYXNrYWJsZS0gNjRiaXQrDQoJCUFkZHJlc3M6IDAwMDAwMDAw
MDAwMDAwMDAgIERhdGE6IDAwMDANCglDYXBhYmlsaXRpZXM6IFs3OF0gUG93ZXIgTWFuYWdl
bWVudCB2ZXJzaW9uIDMNCgkJRmxhZ3M6IFBNRUNsay0gRFNJLSBEMSsgRDIrIEF1eEN1cnJl
bnQ9Mzc1bUEgUE1FKEQwKyxEMSssRDIrLEQzaG90KyxEM2NvbGQtKQ0KCQlTdGF0dXM6IEQw
IE5vU29mdFJzdCsgUE1FLUVuYWJsZS0gRFNlbD0wIERTY2FsZT0wIFBNRS0NCglDYXBhYmls
aXRpZXM6IFs4MF0gRXhwcmVzcyAodjEpIEVuZHBvaW50LCBNU0kgMDANCgkJRGV2Q2FwOglN
YXhQYXlsb2FkIDI1NiBieXRlcywgUGhhbnRGdW5jIDAsIExhdGVuY3kgTDBzIHVubGltaXRl
ZCwgTDEgdW5saW1pdGVkDQoJCQlFeHRUYWctIEF0dG5CdG4tIEF0dG5JbmQtIFB3ckluZC0g
UkJFKyBGTFJlc2V0LQ0KCQlEZXZDdGw6CVJlcG9ydCBlcnJvcnM6IENvcnJlY3RhYmxlLSBO
b24tRmF0YWwtIEZhdGFsLSBVbnN1cHBvcnRlZC0NCgkJCVJseGRPcmQtIEV4dFRhZy0gUGhh
bnRGdW5jLSBBdXhQd3ItIE5vU25vb3ArDQoJCQlNYXhQYXlsb2FkIDEyOCBieXRlcywgTWF4
UmVhZFJlcSA1MTIgYnl0ZXMNCgkJRGV2U3RhOglDb3JyRXJyLSBVbmNvcnJFcnItIEZhdGFs
RXJyLSBVbnN1cHBSZXEtIEF1eFB3ci0gVHJhbnNQZW5kLQ0KCQlMbmtDYXA6CVBvcnQgIzEs
IFNwZWVkIDIuNUdUL3MsIFdpZHRoIHgxLCBBU1BNIHVua25vd24sIExhdGVuY3kgTDAgPDY0
bnMsIEwxIHVubGltaXRlZA0KCQkJQ2xvY2tQTSsgU3VycHJpc2UtIExMQWN0UmVwLSBCd05v
dC0NCgkJTG5rQ3RsOglBU1BNIERpc2FibGVkOyBSQ0IgNjQgYnl0ZXMgRGlzYWJsZWQtIFJl
dHJhaW4tIENvbW1DbGstDQoJCQlFeHRTeW5jaC0gQ2xvY2tQTS0gQXV0V2lkRGlzLSBCV0lu
dC0gQXV0QldJbnQtDQoJCUxua1N0YToJU3BlZWQgMi41R1QvcywgV2lkdGggeDEsIFRyRXJy
LSBUcmFpbi0gU2xvdENsay0gRExBY3RpdmUtIEJXTWdtdC0gQUJXTWdtdC0NCglDYXBhYmls
aXRpZXM6IFsxMDAgdjFdIFZpcnR1YWwgQ2hhbm5lbA0KCQlDYXBzOglMUEVWQz0wIFJlZkNs
az0xMDBucyBQQVRFbnRyeUJpdHM9MQ0KCQlBcmI6CUZpeGVkLSBXUlIzMi0gV1JSNjQtIFdS
UjEyOC0NCgkJQ3RybDoJQXJiU2VsZWN0PUZpeGVkDQoJCVN0YXR1czoJSW5Qcm9ncmVzcy0N
CgkJVkMwOglDYXBzOglQQVRPZmZzZXQ9MDAgTWF4VGltZVNsb3RzPTEgUmVqU25vb3BUcmFu
cy0NCgkJCUFyYjoJRml4ZWQtIFdSUjMyLSBXUlI2NC0gV1JSMTI4LSBUV1JSMTI4LSBXUlIy
NTYtDQoJCQlDdHJsOglFbmFibGUrIElEPTAgQXJiU2VsZWN0PUZpeGVkIFRDL1ZDPWZmDQoJ
CQlTdGF0dXM6CU5lZ29QZW5kaW5nLSBJblByb2dyZXNzLQ0KCUtlcm5lbCBkcml2ZXIgaW4g
dXNlOiBwY2liYWNrDQoNCjA0OjAwLjEgVVNCIGNvbnRyb2xsZXIgWzBjMDNdOiBOZXRNb3Mg
VGVjaG5vbG9neSBNQ1M5OTkwIFBDSWUgdG8gNOKAkFBvcnQgVVNCIDIuMCBIb3N0IENvbnRy
b2xsZXIgWzk3MTA6OTk5MF0gKHByb2ctaWYgMjAgW0VIQ0ldKQ0KCVN1YnN5c3RlbTogRGV2
aWNlIFthMDAwOjQwMDBdDQoJQ29udHJvbDogSS9PLSBNZW0tIEJ1c01hc3Rlci0gU3BlY0N5
Y2xlLSBNZW1XSU5WLSBWR0FTbm9vcC0gUGFyRXJyLSBTdGVwcGluZy0gU0VSUi0gRmFzdEIy
Qi0gRGlzSU5UeC0NCglTdGF0dXM6IENhcCsgNjZNSHotIFVERi0gRmFzdEIyQi0gUGFyRXJy
LSBERVZTRUw9ZmFzdCA+VEFib3J0LSA8VEFib3J0LSA8TUFib3J0LSA+U0VSUi0gPFBFUlIt
IElOVHgtDQoJSW50ZXJydXB0OiBwaW4gQSByb3V0ZWQgdG8gSVJRIDQwDQoJUmVnaW9uIDA6
IE1lbW9yeSBhdCBmOThmOTAwMCAoMzItYml0LCBub24tcHJlZmV0Y2hhYmxlKSBbZGlzYWJs
ZWRdIFtzaXplPTRLXQ0KCUNhcGFiaWxpdGllczogWzUwXSBNU0k6IEVuYWJsZS0gQ291bnQ9
MS8xIE1hc2thYmxlLSA2NGJpdCsNCgkJQWRkcmVzczogMDAwMDAwMDAwMDAwMDAwMCAgRGF0
YTogMDAwMA0KCUNhcGFiaWxpdGllczogWzc4XSBQb3dlciBNYW5hZ2VtZW50IHZlcnNpb24g
Mw0KCQlGbGFnczogUE1FQ2xrLSBEU0ktIEQxKyBEMisgQXV4Q3VycmVudD0zNzVtQSBQTUUo
RDArLEQxKyxEMissRDNob3QrLEQzY29sZC0pDQoJCVN0YXR1czogRDAgTm9Tb2Z0UnN0KyBQ
TUUtRW5hYmxlLSBEU2VsPTAgRFNjYWxlPTAgUE1FLQ0KCUNhcGFiaWxpdGllczogWzgwXSBF
eHByZXNzICh2MSkgRW5kcG9pbnQsIE1TSSAwMA0KCQlEZXZDYXA6CU1heFBheWxvYWQgMjU2
IGJ5dGVzLCBQaGFudEZ1bmMgMCwgTGF0ZW5jeSBMMHMgdW5saW1pdGVkLCBMMSB1bmxpbWl0
ZWQNCgkJCUV4dFRhZy0gQXR0bkJ0bi0gQXR0bkluZC0gUHdySW5kLSBSQkUrIEZMUmVzZXQt
DQoJCURldkN0bDoJUmVwb3J0IGVycm9yczogQ29ycmVjdGFibGUtIE5vbi1GYXRhbC0gRmF0
YWwtIFVuc3VwcG9ydGVkLQ0KCQkJUmx4ZE9yZC0gRXh0VGFnLSBQaGFudEZ1bmMtIEF1eFB3
ci0gTm9Tbm9vcCsNCgkJCU1heFBheWxvYWQgMTI4IGJ5dGVzLCBNYXhSZWFkUmVxIDUxMiBi
eXRlcw0KCQlEZXZTdGE6CUNvcnJFcnItIFVuY29yckVyci0gRmF0YWxFcnItIFVuc3VwcFJl
cS0gQXV4UHdyLSBUcmFuc1BlbmQtDQoJCUxua0NhcDoJUG9ydCAjMSwgU3BlZWQgMi41R1Qv
cywgV2lkdGggeDEsIEFTUE0gdW5rbm93biwgTGF0ZW5jeSBMMCA8NjRucywgTDEgdW5saW1p
dGVkDQoJCQlDbG9ja1BNKyBTdXJwcmlzZS0gTExBY3RSZXAtIEJ3Tm90LQ0KCQlMbmtDdGw6
CUFTUE0gRGlzYWJsZWQ7IFJDQiA2NCBieXRlcyBEaXNhYmxlZC0gUmV0cmFpbi0gQ29tbUNs
ay0NCgkJCUV4dFN5bmNoLSBDbG9ja1BNLSBBdXRXaWREaXMtIEJXSW50LSBBdXRCV0ludC0N
CgkJTG5rU3RhOglTcGVlZCAyLjVHVC9zLCBXaWR0aCB4MSwgVHJFcnItIFRyYWluLSBTbG90
Q2xrLSBETEFjdGl2ZS0gQldNZ210LSBBQldNZ210LQ0KCUtlcm5lbCBkcml2ZXIgaW4gdXNl
OiBwY2liYWNrDQoNCjA0OjAwLjIgVVNCIGNvbnRyb2xsZXIgWzBjMDNdOiBOZXRNb3MgVGVj
aG5vbG9neSBNQ1M5OTkwIFBDSWUgdG8gNOKAkFBvcnQgVVNCIDIuMCBIb3N0IENvbnRyb2xs
ZXIgWzk3MTA6OTk5MF0gKHByb2ctaWYgMTAgW09IQ0ldKQ0KCVN1YnN5c3RlbTogRGV2aWNl
IFthMDAwOjQwMDBdDQoJQ29udHJvbDogSS9PLSBNZW0tIEJ1c01hc3Rlci0gU3BlY0N5Y2xl
LSBNZW1XSU5WLSBWR0FTbm9vcC0gUGFyRXJyLSBTdGVwcGluZy0gU0VSUi0gRmFzdEIyQi0g
RGlzSU5UeC0NCglTdGF0dXM6IENhcCsgNjZNSHotIFVERi0gRmFzdEIyQi0gUGFyRXJyLSBE
RVZTRUw9ZmFzdCA+VEFib3J0LSA8VEFib3J0LSA8TUFib3J0LSA+U0VSUi0gPFBFUlItIElO
VHgtDQoJSW50ZXJydXB0OiBwaW4gQiByb3V0ZWQgdG8gSVJRIDQxDQoJUmVnaW9uIDA6IE1l
bW9yeSBhdCBmOThmYTAwMCAoMzItYml0LCBub24tcHJlZmV0Y2hhYmxlKSBbZGlzYWJsZWRd
IFtzaXplPTRLXQ0KCUNhcGFiaWxpdGllczogWzUwXSBNU0k6IEVuYWJsZS0gQ291bnQ9MS8x
IE1hc2thYmxlLSA2NGJpdCsNCgkJQWRkcmVzczogMDAwMDAwMDAwMDAwMDAwMCAgRGF0YTog
MDAwMA0KCUNhcGFiaWxpdGllczogWzc4XSBQb3dlciBNYW5hZ2VtZW50IHZlcnNpb24gMw0K
CQlGbGFnczogUE1FQ2xrLSBEU0ktIEQxKyBEMisgQXV4Q3VycmVudD0zNzVtQSBQTUUoRDAr
LEQxKyxEMissRDNob3QrLEQzY29sZC0pDQoJCVN0YXR1czogRDAgTm9Tb2Z0UnN0KyBQTUUt
RW5hYmxlLSBEU2VsPTAgRFNjYWxlPTAgUE1FLQ0KCUNhcGFiaWxpdGllczogWzgwXSBFeHBy
ZXNzICh2MSkgRW5kcG9pbnQsIE1TSSAwMA0KCQlEZXZDYXA6CU1heFBheWxvYWQgMjU2IGJ5
dGVzLCBQaGFudEZ1bmMgMCwgTGF0ZW5jeSBMMHMgdW5saW1pdGVkLCBMMSB1bmxpbWl0ZWQN
CgkJCUV4dFRhZy0gQXR0bkJ0bi0gQXR0bkluZC0gUHdySW5kLSBSQkUrIEZMUmVzZXQtDQoJ
CURldkN0bDoJUmVwb3J0IGVycm9yczogQ29ycmVjdGFibGUtIE5vbi1GYXRhbC0gRmF0YWwt
IFVuc3VwcG9ydGVkLQ0KCQkJUmx4ZE9yZC0gRXh0VGFnLSBQaGFudEZ1bmMtIEF1eFB3ci0g
Tm9Tbm9vcCsNCgkJCU1heFBheWxvYWQgMTI4IGJ5dGVzLCBNYXhSZWFkUmVxIDUxMiBieXRl
cw0KCQlEZXZTdGE6CUNvcnJFcnItIFVuY29yckVyci0gRmF0YWxFcnItIFVuc3VwcFJlcS0g
QXV4UHdyLSBUcmFuc1BlbmQtDQoJCUxua0NhcDoJUG9ydCAjMSwgU3BlZWQgMi41R1Qvcywg
V2lkdGggeDEsIEFTUE0gdW5rbm93biwgTGF0ZW5jeSBMMCA8NjRucywgTDEgdW5saW1pdGVk
DQoJCQlDbG9ja1BNKyBTdXJwcmlzZS0gTExBY3RSZXAtIEJ3Tm90LQ0KCQlMbmtDdGw6CUFT
UE0gRGlzYWJsZWQ7IFJDQiA2NCBieXRlcyBEaXNhYmxlZC0gUmV0cmFpbi0gQ29tbUNsay0N
CgkJCUV4dFN5bmNoLSBDbG9ja1BNLSBBdXRXaWREaXMtIEJXSW50LSBBdXRCV0ludC0NCgkJ
TG5rU3RhOglTcGVlZCAyLjVHVC9zLCBXaWR0aCB4MSwgVHJFcnItIFRyYWluLSBTbG90Q2xr
LSBETEFjdGl2ZS0gQldNZ210LSBBQldNZ210LQ0KCUtlcm5lbCBkcml2ZXIgaW4gdXNlOiBw
Y2liYWNrDQoNCjA0OjAwLjMgVVNCIGNvbnRyb2xsZXIgWzBjMDNdOiBOZXRNb3MgVGVjaG5v
bG9neSBNQ1M5OTkwIFBDSWUgdG8gNOKAkFBvcnQgVVNCIDIuMCBIb3N0IENvbnRyb2xsZXIg
Wzk3MTA6OTk5MF0gKHByb2ctaWYgMjAgW0VIQ0ldKQ0KCVN1YnN5c3RlbTogRGV2aWNlIFth
MDAwOjQwMDBdDQoJQ29udHJvbDogSS9PLSBNZW0tIEJ1c01hc3Rlci0gU3BlY0N5Y2xlLSBN
ZW1XSU5WLSBWR0FTbm9vcC0gUGFyRXJyLSBTdGVwcGluZy0gU0VSUi0gRmFzdEIyQi0gRGlz
SU5UeC0NCglTdGF0dXM6IENhcCsgNjZNSHotIFVERi0gRmFzdEIyQi0gUGFyRXJyLSBERVZT
RUw9ZmFzdCA+VEFib3J0LSA8VEFib3J0LSA8TUFib3J0LSA+U0VSUi0gPFBFUlItIElOVHgt
DQoJSW50ZXJydXB0OiBwaW4gQiByb3V0ZWQgdG8gSVJRIDQxDQoJUmVnaW9uIDA6IE1lbW9y
eSBhdCBmOThmYjAwMCAoMzItYml0LCBub24tcHJlZmV0Y2hhYmxlKSBbZGlzYWJsZWRdIFtz
aXplPTRLXQ0KCUNhcGFiaWxpdGllczogWzUwXSBNU0k6IEVuYWJsZS0gQ291bnQ9MS8xIE1h
c2thYmxlLSA2NGJpdCsNCgkJQWRkcmVzczogMDAwMDAwMDAwMDAwMDAwMCAgRGF0YTogMDAw
MA0KCUNhcGFiaWxpdGllczogWzc4XSBQb3dlciBNYW5hZ2VtZW50IHZlcnNpb24gMw0KCQlG
bGFnczogUE1FQ2xrLSBEU0ktIEQxKyBEMisgQXV4Q3VycmVudD0zNzVtQSBQTUUoRDArLEQx
KyxEMissRDNob3QrLEQzY29sZC0pDQoJCVN0YXR1czogRDAgTm9Tb2Z0UnN0KyBQTUUtRW5h
YmxlLSBEU2VsPTAgRFNjYWxlPTAgUE1FLQ0KCUNhcGFiaWxpdGllczogWzgwXSBFeHByZXNz
ICh2MSkgRW5kcG9pbnQsIE1TSSAwMA0KCQlEZXZDYXA6CU1heFBheWxvYWQgMjU2IGJ5dGVz
LCBQaGFudEZ1bmMgMCwgTGF0ZW5jeSBMMHMgdW5saW1pdGVkLCBMMSB1bmxpbWl0ZWQNCgkJ
CUV4dFRhZy0gQXR0bkJ0bi0gQXR0bkluZC0gUHdySW5kLSBSQkUrIEZMUmVzZXQtDQoJCURl
dkN0bDoJUmVwb3J0IGVycm9yczogQ29ycmVjdGFibGUtIE5vbi1GYXRhbC0gRmF0YWwtIFVu
c3VwcG9ydGVkLQ0KCQkJUmx4ZE9yZC0gRXh0VGFnLSBQaGFudEZ1bmMtIEF1eFB3ci0gTm9T
bm9vcCsNCgkJCU1heFBheWxvYWQgMTI4IGJ5dGVzLCBNYXhSZWFkUmVxIDUxMiBieXRlcw0K
CQlEZXZTdGE6CUNvcnJFcnItIFVuY29yckVyci0gRmF0YWxFcnItIFVuc3VwcFJlcS0gQXV4
UHdyLSBUcmFuc1BlbmQtDQoJCUxua0NhcDoJUG9ydCAjMSwgU3BlZWQgMi41R1QvcywgV2lk
dGggeDEsIEFTUE0gdW5rbm93biwgTGF0ZW5jeSBMMCA8NjRucywgTDEgdW5saW1pdGVkDQoJ
CQlDbG9ja1BNKyBTdXJwcmlzZS0gTExBY3RSZXAtIEJ3Tm90LQ0KCQlMbmtDdGw6CUFTUE0g
RGlzYWJsZWQ7IFJDQiA2NCBieXRlcyBEaXNhYmxlZC0gUmV0cmFpbi0gQ29tbUNsay0NCgkJ
CUV4dFN5bmNoLSBDbG9ja1BNLSBBdXRXaWREaXMtIEJXSW50LSBBdXRCV0ludC0NCgkJTG5r
U3RhOglTcGVlZCAyLjVHVC9zLCBXaWR0aCB4MSwgVHJFcnItIFRyYWluLSBTbG90Q2xrLSBE
TEFjdGl2ZS0gQldNZ210LSBBQldNZ210LQ0KCUtlcm5lbCBkcml2ZXIgaW4gdXNlOiBwY2li
YWNrDQoNCjA0OjAwLjQgVVNCIGNvbnRyb2xsZXIgWzBjMDNdOiBOZXRNb3MgVGVjaG5vbG9n
eSBNQ1M5OTkwIFBDSWUgdG8gNOKAkFBvcnQgVVNCIDIuMCBIb3N0IENvbnRyb2xsZXIgWzk3
MTA6OTk5MF0gKHByb2ctaWYgMTAgW09IQ0ldKQ0KCVN1YnN5c3RlbTogRGV2aWNlIFthMDAw
OjQwMDBdDQoJQ29udHJvbDogSS9PLSBNZW0tIEJ1c01hc3Rlci0gU3BlY0N5Y2xlLSBNZW1X
SU5WLSBWR0FTbm9vcC0gUGFyRXJyLSBTdGVwcGluZy0gU0VSUi0gRmFzdEIyQi0gRGlzSU5U
eC0NCglTdGF0dXM6IENhcCsgNjZNSHotIFVERi0gRmFzdEIyQi0gUGFyRXJyLSBERVZTRUw9
ZmFzdCA+VEFib3J0LSA8VEFib3J0LSA8TUFib3J0LSA+U0VSUi0gPFBFUlItIElOVHgtDQoJ
SW50ZXJydXB0OiBwaW4gQyByb3V0ZWQgdG8gSVJRIDQyDQoJUmVnaW9uIDA6IE1lbW9yeSBh
dCBmOThmYzAwMCAoMzItYml0LCBub24tcHJlZmV0Y2hhYmxlKSBbZGlzYWJsZWRdIFtzaXpl
PTRLXQ0KCUNhcGFiaWxpdGllczogWzUwXSBNU0k6IEVuYWJsZS0gQ291bnQ9MS8xIE1hc2th
YmxlLSA2NGJpdCsNCgkJQWRkcmVzczogMDAwMDAwMDAwMDAwMDAwMCAgRGF0YTogMDAwMA0K
CUNhcGFiaWxpdGllczogWzc4XSBQb3dlciBNYW5hZ2VtZW50IHZlcnNpb24gMw0KCQlGbGFn
czogUE1FQ2xrLSBEU0ktIEQxKyBEMisgQXV4Q3VycmVudD0zNzVtQSBQTUUoRDArLEQxKyxE
MissRDNob3QrLEQzY29sZC0pDQoJCVN0YXR1czogRDAgTm9Tb2Z0UnN0KyBQTUUtRW5hYmxl
LSBEU2VsPTAgRFNjYWxlPTAgUE1FLQ0KCUNhcGFiaWxpdGllczogWzgwXSBFeHByZXNzICh2
MSkgRW5kcG9pbnQsIE1TSSAwMA0KCQlEZXZDYXA6CU1heFBheWxvYWQgMjU2IGJ5dGVzLCBQ
aGFudEZ1bmMgMCwgTGF0ZW5jeSBMMHMgdW5saW1pdGVkLCBMMSB1bmxpbWl0ZWQNCgkJCUV4
dFRhZy0gQXR0bkJ0bi0gQXR0bkluZC0gUHdySW5kLSBSQkUrIEZMUmVzZXQtDQoJCURldkN0
bDoJUmVwb3J0IGVycm9yczogQ29ycmVjdGFibGUtIE5vbi1GYXRhbC0gRmF0YWwtIFVuc3Vw
cG9ydGVkLQ0KCQkJUmx4ZE9yZC0gRXh0VGFnLSBQaGFudEZ1bmMtIEF1eFB3ci0gTm9Tbm9v
cCsNCgkJCU1heFBheWxvYWQgMTI4IGJ5dGVzLCBNYXhSZWFkUmVxIDUxMiBieXRlcw0KCQlE
ZXZTdGE6CUNvcnJFcnItIFVuY29yckVyci0gRmF0YWxFcnItIFVuc3VwcFJlcS0gQXV4UHdy
LSBUcmFuc1BlbmQtDQoJCUxua0NhcDoJUG9ydCAjMSwgU3BlZWQgMi41R1QvcywgV2lkdGgg
eDEsIEFTUE0gdW5rbm93biwgTGF0ZW5jeSBMMCA8NjRucywgTDEgdW5saW1pdGVkDQoJCQlD
bG9ja1BNKyBTdXJwcmlzZS0gTExBY3RSZXAtIEJ3Tm90LQ0KCQlMbmtDdGw6CUFTUE0gRGlz
YWJsZWQ7IFJDQiA2NCBieXRlcyBEaXNhYmxlZC0gUmV0cmFpbi0gQ29tbUNsay0NCgkJCUV4
dFN5bmNoLSBDbG9ja1BNLSBBdXRXaWREaXMtIEJXSW50LSBBdXRCV0ludC0NCgkJTG5rU3Rh
OglTcGVlZCAyLjVHVC9zLCBXaWR0aCB4MSwgVHJFcnItIFRyYWluLSBTbG90Q2xrLSBETEFj
dGl2ZS0gQldNZ210LSBBQldNZ210LQ0KCUtlcm5lbCBkcml2ZXIgaW4gdXNlOiBwY2liYWNr
DQoNCjA0OjAwLjUgVVNCIGNvbnRyb2xsZXIgWzBjMDNdOiBOZXRNb3MgVGVjaG5vbG9neSBN
Q1M5OTkwIFBDSWUgdG8gNOKAkFBvcnQgVVNCIDIuMCBIb3N0IENvbnRyb2xsZXIgWzk3MTA6
OTk5MF0gKHByb2ctaWYgMjAgW0VIQ0ldKQ0KCVN1YnN5c3RlbTogRGV2aWNlIFthMDAwOjQw
MDBdDQoJQ29udHJvbDogSS9PLSBNZW0tIEJ1c01hc3Rlci0gU3BlY0N5Y2xlLSBNZW1XSU5W
LSBWR0FTbm9vcC0gUGFyRXJyLSBTdGVwcGluZy0gU0VSUi0gRmFzdEIyQi0gRGlzSU5UeC0N
CglTdGF0dXM6IENhcCsgNjZNSHotIFVERi0gRmFzdEIyQi0gUGFyRXJyLSBERVZTRUw9ZmFz
dCA+VEFib3J0LSA8VEFib3J0LSA8TUFib3J0LSA+U0VSUi0gPFBFUlItIElOVHgtDQoJSW50
ZXJydXB0OiBwaW4gQyByb3V0ZWQgdG8gSVJRIDQyDQoJUmVnaW9uIDA6IE1lbW9yeSBhdCBm
OThmZDAwMCAoMzItYml0LCBub24tcHJlZmV0Y2hhYmxlKSBbZGlzYWJsZWRdIFtzaXplPTRL
XQ0KCUNhcGFiaWxpdGllczogWzUwXSBNU0k6IEVuYWJsZS0gQ291bnQ9MS8xIE1hc2thYmxl
LSA2NGJpdCsNCgkJQWRkcmVzczogMDAwMDAwMDAwMDAwMDAwMCAgRGF0YTogMDAwMA0KCUNh
cGFiaWxpdGllczogWzc4XSBQb3dlciBNYW5hZ2VtZW50IHZlcnNpb24gMw0KCQlGbGFnczog
UE1FQ2xrLSBEU0ktIEQxKyBEMisgQXV4Q3VycmVudD0zNzVtQSBQTUUoRDArLEQxKyxEMiss
RDNob3QrLEQzY29sZC0pDQoJCVN0YXR1czogRDAgTm9Tb2Z0UnN0KyBQTUUtRW5hYmxlLSBE
U2VsPTAgRFNjYWxlPTAgUE1FLQ0KCUNhcGFiaWxpdGllczogWzgwXSBFeHByZXNzICh2MSkg
RW5kcG9pbnQsIE1TSSAwMA0KCQlEZXZDYXA6CU1heFBheWxvYWQgMjU2IGJ5dGVzLCBQaGFu
dEZ1bmMgMCwgTGF0ZW5jeSBMMHMgdW5saW1pdGVkLCBMMSB1bmxpbWl0ZWQNCgkJCUV4dFRh
Zy0gQXR0bkJ0bi0gQXR0bkluZC0gUHdySW5kLSBSQkUrIEZMUmVzZXQtDQoJCURldkN0bDoJ
UmVwb3J0IGVycm9yczogQ29ycmVjdGFibGUtIE5vbi1GYXRhbC0gRmF0YWwtIFVuc3VwcG9y
dGVkLQ0KCQkJUmx4ZE9yZC0gRXh0VGFnLSBQaGFudEZ1bmMtIEF1eFB3ci0gTm9Tbm9vcCsN
CgkJCU1heFBheWxvYWQgMTI4IGJ5dGVzLCBNYXhSZWFkUmVxIDUxMiBieXRlcw0KCQlEZXZT
dGE6CUNvcnJFcnItIFVuY29yckVyci0gRmF0YWxFcnItIFVuc3VwcFJlcS0gQXV4UHdyLSBU
cmFuc1BlbmQtDQoJCUxua0NhcDoJUG9ydCAjMSwgU3BlZWQgMi41R1QvcywgV2lkdGggeDEs
IEFTUE0gdW5rbm93biwgTGF0ZW5jeSBMMCA8NjRucywgTDEgdW5saW1pdGVkDQoJCQlDbG9j
a1BNKyBTdXJwcmlzZS0gTExBY3RSZXAtIEJ3Tm90LQ0KCQlMbmtDdGw6CUFTUE0gRGlzYWJs
ZWQ7IFJDQiA2NCBieXRlcyBEaXNhYmxlZC0gUmV0cmFpbi0gQ29tbUNsay0NCgkJCUV4dFN5
bmNoLSBDbG9ja1BNLSBBdXRXaWREaXMtIEJXSW50LSBBdXRCV0ludC0NCgkJTG5rU3RhOglT
cGVlZCAyLjVHVC9zLCBXaWR0aCB4MSwgVHJFcnItIFRyYWluLSBTbG90Q2xrLSBETEFjdGl2
ZS0gQldNZ210LSBBQldNZ210LQ0KCUtlcm5lbCBkcml2ZXIgaW4gdXNlOiBwY2liYWNrDQoN
CjA0OjAwLjYgVVNCIGNvbnRyb2xsZXIgWzBjMDNdOiBOZXRNb3MgVGVjaG5vbG9neSBNQ1M5
OTkwIFBDSWUgdG8gNOKAkFBvcnQgVVNCIDIuMCBIb3N0IENvbnRyb2xsZXIgWzk3MTA6OTk5
MF0gKHByb2ctaWYgMTAgW09IQ0ldKQ0KCVN1YnN5c3RlbTogRGV2aWNlIFthMDAwOjQwMDBd
DQoJQ29udHJvbDogSS9PLSBNZW0tIEJ1c01hc3Rlci0gU3BlY0N5Y2xlLSBNZW1XSU5WLSBW
R0FTbm9vcC0gUGFyRXJyLSBTdGVwcGluZy0gU0VSUi0gRmFzdEIyQi0gRGlzSU5UeC0NCglT
dGF0dXM6IENhcCsgNjZNSHotIFVERi0gRmFzdEIyQi0gUGFyRXJyLSBERVZTRUw9ZmFzdCA+
VEFib3J0LSA8VEFib3J0LSA8TUFib3J0LSA+U0VSUi0gPFBFUlItIElOVHgtDQoJSW50ZXJy
dXB0OiBwaW4gRCByb3V0ZWQgdG8gSVJRIDQzDQoJUmVnaW9uIDA6IE1lbW9yeSBhdCBmOThm
ZTAwMCAoMzItYml0LCBub24tcHJlZmV0Y2hhYmxlKSBbZGlzYWJsZWRdIFtzaXplPTRLXQ0K
CUNhcGFiaWxpdGllczogWzUwXSBNU0k6IEVuYWJsZS0gQ291bnQ9MS8xIE1hc2thYmxlLSA2
NGJpdCsNCgkJQWRkcmVzczogMDAwMDAwMDAwMDAwMDAwMCAgRGF0YTogMDAwMA0KCUNhcGFi
aWxpdGllczogWzc4XSBQb3dlciBNYW5hZ2VtZW50IHZlcnNpb24gMw0KCQlGbGFnczogUE1F
Q2xrLSBEU0ktIEQxKyBEMisgQXV4Q3VycmVudD0zNzVtQSBQTUUoRDArLEQxKyxEMissRDNo
b3QrLEQzY29sZC0pDQoJCVN0YXR1czogRDAgTm9Tb2Z0UnN0KyBQTUUtRW5hYmxlLSBEU2Vs
PTAgRFNjYWxlPTAgUE1FLQ0KCUNhcGFiaWxpdGllczogWzgwXSBFeHByZXNzICh2MSkgRW5k
cG9pbnQsIE1TSSAwMA0KCQlEZXZDYXA6CU1heFBheWxvYWQgMjU2IGJ5dGVzLCBQaGFudEZ1
bmMgMCwgTGF0ZW5jeSBMMHMgdW5saW1pdGVkLCBMMSB1bmxpbWl0ZWQNCgkJCUV4dFRhZy0g
QXR0bkJ0bi0gQXR0bkluZC0gUHdySW5kLSBSQkUrIEZMUmVzZXQtDQoJCURldkN0bDoJUmVw
b3J0IGVycm9yczogQ29ycmVjdGFibGUtIE5vbi1GYXRhbC0gRmF0YWwtIFVuc3VwcG9ydGVk
LQ0KCQkJUmx4ZE9yZC0gRXh0VGFnLSBQaGFudEZ1bmMtIEF1eFB3ci0gTm9Tbm9vcCsNCgkJ
CU1heFBheWxvYWQgMTI4IGJ5dGVzLCBNYXhSZWFkUmVxIDUxMiBieXRlcw0KCQlEZXZTdGE6
CUNvcnJFcnItIFVuY29yckVyci0gRmF0YWxFcnItIFVuc3VwcFJlcS0gQXV4UHdyLSBUcmFu
c1BlbmQtDQoJCUxua0NhcDoJUG9ydCAjMSwgU3BlZWQgMi41R1QvcywgV2lkdGggeDEsIEFT
UE0gdW5rbm93biwgTGF0ZW5jeSBMMCA8NjRucywgTDEgdW5saW1pdGVkDQoJCQlDbG9ja1BN
KyBTdXJwcmlzZS0gTExBY3RSZXAtIEJ3Tm90LQ0KCQlMbmtDdGw6CUFTUE0gRGlzYWJsZWQ7
IFJDQiA2NCBieXRlcyBEaXNhYmxlZC0gUmV0cmFpbi0gQ29tbUNsay0NCgkJCUV4dFN5bmNo
LSBDbG9ja1BNLSBBdXRXaWREaXMtIEJXSW50LSBBdXRCV0ludC0NCgkJTG5rU3RhOglTcGVl
ZCAyLjVHVC9zLCBXaWR0aCB4MSwgVHJFcnItIFRyYWluLSBTbG90Q2xrLSBETEFjdGl2ZS0g
QldNZ210LSBBQldNZ210LQ0KCUtlcm5lbCBkcml2ZXIgaW4gdXNlOiBwY2liYWNrDQoNCjA0
OjAwLjcgVVNCIGNvbnRyb2xsZXIgWzBjMDNdOiBOZXRNb3MgVGVjaG5vbG9neSBNQ1M5OTkw
IFBDSWUgdG8gNOKAkFBvcnQgVVNCIDIuMCBIb3N0IENvbnRyb2xsZXIgWzk3MTA6OTk5MF0g
KHByb2ctaWYgMjAgW0VIQ0ldKQ0KCVN1YnN5c3RlbTogRGV2aWNlIFthMDAwOjQwMDBdDQoJ
Q29udHJvbDogSS9PLSBNZW0tIEJ1c01hc3Rlci0gU3BlY0N5Y2xlLSBNZW1XSU5WLSBWR0FT
bm9vcC0gUGFyRXJyLSBTdGVwcGluZy0gU0VSUi0gRmFzdEIyQi0gRGlzSU5UeC0NCglTdGF0
dXM6IENhcCsgNjZNSHotIFVERi0gRmFzdEIyQi0gUGFyRXJyLSBERVZTRUw9ZmFzdCA+VEFi
b3J0LSA8VEFib3J0LSA8TUFib3J0LSA+U0VSUi0gPFBFUlItIElOVHgtDQoJSW50ZXJydXB0
OiBwaW4gRCByb3V0ZWQgdG8gSVJRIDQzDQoJUmVnaW9uIDA6IE1lbW9yeSBhdCBmOThmZjAw
MCAoMzItYml0LCBub24tcHJlZmV0Y2hhYmxlKSBbZGlzYWJsZWRdIFtzaXplPTRLXQ0KCUNh
cGFiaWxpdGllczogWzUwXSBNU0k6IEVuYWJsZS0gQ291bnQ9MS8xIE1hc2thYmxlLSA2NGJp
dCsNCgkJQWRkcmVzczogMDAwMDAwMDAwMDAwMDAwMCAgRGF0YTogMDAwMA0KCUNhcGFiaWxp
dGllczogWzc4XSBQb3dlciBNYW5hZ2VtZW50IHZlcnNpb24gMw0KCQlGbGFnczogUE1FQ2xr
LSBEU0ktIEQxKyBEMisgQXV4Q3VycmVudD0zNzVtQSBQTUUoRDArLEQxKyxEMissRDNob3Qr
LEQzY29sZC0pDQoJCVN0YXR1czogRDAgTm9Tb2Z0UnN0KyBQTUUtRW5hYmxlLSBEU2VsPTAg
RFNjYWxlPTAgUE1FLQ0KCUNhcGFiaWxpdGllczogWzgwXSBFeHByZXNzICh2MSkgRW5kcG9p
bnQsIE1TSSAwMA0KCQlEZXZDYXA6CU1heFBheWxvYWQgMjU2IGJ5dGVzLCBQaGFudEZ1bmMg
MCwgTGF0ZW5jeSBMMHMgdW5saW1pdGVkLCBMMSB1bmxpbWl0ZWQNCgkJCUV4dFRhZy0gQXR0
bkJ0bi0gQXR0bkluZC0gUHdySW5kLSBSQkUrIEZMUmVzZXQtDQoJCURldkN0bDoJUmVwb3J0
IGVycm9yczogQ29ycmVjdGFibGUtIE5vbi1GYXRhbC0gRmF0YWwtIFVuc3VwcG9ydGVkLQ0K
CQkJUmx4ZE9yZC0gRXh0VGFnLSBQaGFudEZ1bmMtIEF1eFB3ci0gTm9Tbm9vcCsNCgkJCU1h
eFBheWxvYWQgMTI4IGJ5dGVzLCBNYXhSZWFkUmVxIDUxMiBieXRlcw0KCQlEZXZTdGE6CUNv
cnJFcnItIFVuY29yckVyci0gRmF0YWxFcnItIFVuc3VwcFJlcS0gQXV4UHdyLSBUcmFuc1Bl
bmQtDQoJCUxua0NhcDoJUG9ydCAjMSwgU3BlZWQgMi41R1QvcywgV2lkdGggeDEsIEFTUE0g
dW5rbm93biwgTGF0ZW5jeSBMMCA8NjRucywgTDEgdW5saW1pdGVkDQoJCQlDbG9ja1BNKyBT
dXJwcmlzZS0gTExBY3RSZXAtIEJ3Tm90LQ0KCQlMbmtDdGw6CUFTUE0gRGlzYWJsZWQ7IFJD
QiA2NCBieXRlcyBEaXNhYmxlZC0gUmV0cmFpbi0gQ29tbUNsay0NCgkJCUV4dFN5bmNoLSBD
bG9ja1BNLSBBdXRXaWREaXMtIEJXSW50LSBBdXRCV0ludC0NCgkJTG5rU3RhOglTcGVlZCAy
LjVHVC9zLCBXaWR0aCB4MSwgVHJFcnItIFRyYWluLSBTbG90Q2xrLSBETEFjdGl2ZS0gQldN
Z210LSBBQldNZ210LQ0KCUtlcm5lbCBkcml2ZXIgaW4gdXNlOiBwY2liYWNrDQoNCjA1OjAw
LjAgVkdBIGNvbXBhdGlibGUgY29udHJvbGxlciBbMDMwMF06IEFUSSBUZWNobm9sb2dpZXMg
SW5jIFJWNjIwIExFIFtSYWRlb24gSEQgMzQ1MF0gWzEwMDI6OTVjNV0gKHByb2ctaWYgMDAg
W1ZHQSBjb250cm9sbGVyXSkNCglTdWJzeXN0ZW06IEFTVVNUZUsgQ29tcHV0ZXIgSW5jLiBE
ZXZpY2UgWzEwNDM6MDFkNF0NCglDb250cm9sOiBJL08tIE1lbS0gQnVzTWFzdGVyLSBTcGVj
Q3ljbGUtIE1lbVdJTlYtIFZHQVNub29wLSBQYXJFcnItIFN0ZXBwaW5nLSBTRVJSLSBGYXN0
QjJCLSBEaXNJTlR4LQ0KCVN0YXR1czogQ2FwKyA2Nk1Iei0gVURGLSBGYXN0QjJCLSBQYXJF
cnItIERFVlNFTD1mYXN0ID5UQWJvcnQtIDxUQWJvcnQtIDxNQWJvcnQtID5TRVJSLSA8UEVS
Ui0gSU5UeC0NCglJbnRlcnJ1cHQ6IHBpbiBBIHJvdXRlZCB0byBJUlEgMTANCglSZWdpb24g
MDogTWVtb3J5IGF0IGIwMDAwMDAwICg2NC1iaXQsIHByZWZldGNoYWJsZSkgW2Rpc2FibGVk
XSBbc2l6ZT0yNTZNXQ0KCVJlZ2lvbiAyOiBNZW1vcnkgYXQgZjk5ZTAwMDAgKDY0LWJpdCwg
bm9uLXByZWZldGNoYWJsZSkgW2Rpc2FibGVkXSBbc2l6ZT02NEtdDQoJUmVnaW9uIDQ6IEkv
TyBwb3J0cyBhdCBiMDAwIFtkaXNhYmxlZF0gW3NpemU9MjU2XQ0KCUV4cGFuc2lvbiBST00g
YXQgZjk5YzAwMDAgW2Rpc2FibGVkXSBbc2l6ZT0xMjhLXQ0KCUNhcGFiaWxpdGllczogWzUw
XSBQb3dlciBNYW5hZ2VtZW50IHZlcnNpb24gMw0KCQlGbGFnczogUE1FQ2xrLSBEU0ktIEQx
KyBEMisgQXV4Q3VycmVudD0wbUEgUE1FKEQwLSxEMS0sRDItLEQzaG90LSxEM2NvbGQtKQ0K
CQlTdGF0dXM6IEQwIE5vU29mdFJzdC0gUE1FLUVuYWJsZS0gRFNlbD0wIERTY2FsZT0wIFBN
RS0NCglDYXBhYmlsaXRpZXM6IFs1OF0gRXhwcmVzcyAodjIpIExlZ2FjeSBFbmRwb2ludCwg
TVNJIDAwDQoJCURldkNhcDoJTWF4UGF5bG9hZCAxMjggYnl0ZXMsIFBoYW50RnVuYyAwLCBM
YXRlbmN5IEwwcyA8NHVzLCBMMSB1bmxpbWl0ZWQNCgkJCUV4dFRhZysgQXR0bkJ0bi0gQXR0
bkluZC0gUHdySW5kLSBSQkUrIEZMUmVzZXQtDQoJCURldkN0bDoJUmVwb3J0IGVycm9yczog
Q29ycmVjdGFibGUtIE5vbi1GYXRhbC0gRmF0YWwtIFVuc3VwcG9ydGVkLQ0KCQkJUmx4ZE9y
ZCsgRXh0VGFnLSBQaGFudEZ1bmMtIEF1eFB3ci0gTm9Tbm9vcCsNCgkJCU1heFBheWxvYWQg
MTI4IGJ5dGVzLCBNYXhSZWFkUmVxIDEyOCBieXRlcw0KCQlEZXZTdGE6CUNvcnJFcnItIFVu
Y29yckVyci0gRmF0YWxFcnItIFVuc3VwcFJlcS0gQXV4UHdyLSBUcmFuc1BlbmQtDQoJCUxu
a0NhcDoJUG9ydCAjMCwgU3BlZWQgMi41R1QvcywgV2lkdGggeDE2LCBBU1BNIEwwcyBMMSwg
TGF0ZW5jeSBMMCA8NjRucywgTDEgPDF1cw0KCQkJQ2xvY2tQTS0gU3VycHJpc2UtIExMQWN0
UmVwLSBCd05vdC0NCgkJTG5rQ3RsOglBU1BNIERpc2FibGVkOyBSQ0IgNjQgYnl0ZXMgRGlz
YWJsZWQtIFJldHJhaW4tIENvbW1DbGsrDQoJCQlFeHRTeW5jaC0gQ2xvY2tQTS0gQXV0V2lk
RGlzLSBCV0ludC0gQXV0QldJbnQtDQoJCUxua1N0YToJU3BlZWQgMi41R1QvcywgV2lkdGgg
eDE2LCBUckVyci0gVHJhaW4tIFNsb3RDbGsrIERMQWN0aXZlLSBCV01nbXQtIEFCV01nbXQt
DQoJCURldkNhcDI6IENvbXBsZXRpb24gVGltZW91dDogTm90IFN1cHBvcnRlZCwgVGltZW91
dERpcy0NCgkJRGV2Q3RsMjogQ29tcGxldGlvbiBUaW1lb3V0OiA1MHVzIHRvIDUwbXMsIFRp
bWVvdXREaXMtDQoJCUxua0N0bDI6IFRhcmdldCBMaW5rIFNwZWVkOiAyLjVHVC9zLCBFbnRl
ckNvbXBsaWFuY2UtIFNwZWVkRGlzLSwgU2VsZWN0YWJsZSBEZS1lbXBoYXNpczogLTZkQg0K
CQkJIFRyYW5zbWl0IE1hcmdpbjogTm9ybWFsIE9wZXJhdGluZyBSYW5nZSwgRW50ZXJNb2Rp
ZmllZENvbXBsaWFuY2UtIENvbXBsaWFuY2VTT1MtDQoJCQkgQ29tcGxpYW5jZSBEZS1lbXBo
YXNpczogLTZkQg0KCQlMbmtTdGEyOiBDdXJyZW50IERlLWVtcGhhc2lzIExldmVsOiAtNmRC
DQoJQ2FwYWJpbGl0aWVzOiBbYTBdIE1TSTogRW5hYmxlLSBDb3VudD0xLzEgTWFza2FibGUt
IDY0Yml0Kw0KCQlBZGRyZXNzOiAwMDAwMDAwMDAwMDAwMDAwICBEYXRhOiAwMDAwDQoJQ2Fw
YWJpbGl0aWVzOiBbMTAwIHYxXSBWZW5kb3IgU3BlY2lmaWMgSW5mb3JtYXRpb246IElEPTAw
MDEgUmV2PTEgTGVuPTAxMCA8Pz4NCg0KMDU6MDAuMSBBdWRpbyBkZXZpY2UgWzA0MDNdOiBB
VEkgVGVjaG5vbG9naWVzIEluYyBSVjYyMCBBdWRpbyBkZXZpY2UgW1JhZGVvbiBIRCAzNHh4
IFNlcmllc10gWzEwMDI6YWEyOF0NCglTdWJzeXN0ZW06IEFTVVNUZUsgQ29tcHV0ZXIgSW5j
LiBEZXZpY2UgWzEwNDM6YWEyOF0NCglDb250cm9sOiBJL08rIE1lbSsgQnVzTWFzdGVyKyBT
cGVjQ3ljbGUtIE1lbVdJTlYtIFZHQVNub29wLSBQYXJFcnItIFN0ZXBwaW5nLSBTRVJSKyBG
YXN0QjJCLSBEaXNJTlR4Kw0KCVN0YXR1czogQ2FwKyA2Nk1Iei0gVURGLSBGYXN0QjJCLSBQ
YXJFcnItIERFVlNFTD1mYXN0ID5UQWJvcnQtIDxUQWJvcnQtIDxNQWJvcnQtID5TRVJSLSA8
UEVSUi0gSU5UeC0NCglMYXRlbmN5OiAwLCBDYWNoZSBMaW5lIFNpemU6IDY0IGJ5dGVzDQoJ
SW50ZXJydXB0OiBwaW4gQiByb3V0ZWQgdG8gSVJRIDEyMg0KCVJlZ2lvbiAwOiBNZW1vcnkg
YXQgZjk5ZmMwMDAgKDY0LWJpdCwgbm9uLXByZWZldGNoYWJsZSkgW3NpemU9MTZLXQ0KCUNh
cGFiaWxpdGllczogWzUwXSBQb3dlciBNYW5hZ2VtZW50IHZlcnNpb24gMw0KCQlGbGFnczog
UE1FQ2xrLSBEU0ktIEQxKyBEMisgQXV4Q3VycmVudD0wbUEgUE1FKEQwLSxEMS0sRDItLEQz
aG90LSxEM2NvbGQtKQ0KCQlTdGF0dXM6IEQwIE5vU29mdFJzdC0gUE1FLUVuYWJsZS0gRFNl
bD0wIERTY2FsZT0wIFBNRS0NCglDYXBhYmlsaXRpZXM6IFs1OF0gRXhwcmVzcyAodjIpIExl
Z2FjeSBFbmRwb2ludCwgTVNJIDAwDQoJCURldkNhcDoJTWF4UGF5bG9hZCAxMjggYnl0ZXMs
IFBoYW50RnVuYyAwLCBMYXRlbmN5IEwwcyA8NHVzLCBMMSB1bmxpbWl0ZWQNCgkJCUV4dFRh
ZysgQXR0bkJ0bi0gQXR0bkluZC0gUHdySW5kLSBSQkUrIEZMUmVzZXQtDQoJCURldkN0bDoJ
UmVwb3J0IGVycm9yczogQ29ycmVjdGFibGUtIE5vbi1GYXRhbC0gRmF0YWwtIFVuc3VwcG9y
dGVkLQ0KCQkJUmx4ZE9yZCsgRXh0VGFnLSBQaGFudEZ1bmMtIEF1eFB3ci0gTm9Tbm9vcCsN
CgkJCU1heFBheWxvYWQgMTI4IGJ5dGVzLCBNYXhSZWFkUmVxIDEyOCBieXRlcw0KCQlEZXZT
dGE6CUNvcnJFcnItIFVuY29yckVyci0gRmF0YWxFcnItIFVuc3VwcFJlcS0gQXV4UHdyLSBU
cmFuc1BlbmQtDQoJCUxua0NhcDoJUG9ydCAjMCwgU3BlZWQgMi41R1QvcywgV2lkdGggeDE2
LCBBU1BNIEwwcyBMMSwgTGF0ZW5jeSBMMCA8NjRucywgTDEgPDF1cw0KCQkJQ2xvY2tQTS0g
U3VycHJpc2UtIExMQWN0UmVwLSBCd05vdC0NCgkJTG5rQ3RsOglBU1BNIERpc2FibGVkOyBS
Q0IgNjQgYnl0ZXMgRGlzYWJsZWQtIFJldHJhaW4tIENvbW1DbGsrDQoJCQlFeHRTeW5jaC0g
Q2xvY2tQTS0gQXV0V2lkRGlzLSBCV0ludC0gQXV0QldJbnQtDQoJCUxua1N0YToJU3BlZWQg
Mi41R1QvcywgV2lkdGggeDE2LCBUckVyci0gVHJhaW4tIFNsb3RDbGsrIERMQWN0aXZlLSBC
V01nbXQtIEFCV01nbXQtDQoJCURldkNhcDI6IENvbXBsZXRpb24gVGltZW91dDogTm90IFN1
cHBvcnRlZCwgVGltZW91dERpcy0NCgkJRGV2Q3RsMjogQ29tcGxldGlvbiBUaW1lb3V0OiA1
MHVzIHRvIDUwbXMsIFRpbWVvdXREaXMtDQoJCUxua0N0bDI6IFRhcmdldCBMaW5rIFNwZWVk
OiAyLjVHVC9zLCBFbnRlckNvbXBsaWFuY2UtIFNwZWVkRGlzLSwgU2VsZWN0YWJsZSBEZS1l
bXBoYXNpczogLTZkQg0KCQkJIFRyYW5zbWl0IE1hcmdpbjogTm9ybWFsIE9wZXJhdGluZyBS
YW5nZSwgRW50ZXJNb2RpZmllZENvbXBsaWFuY2UtIENvbXBsaWFuY2VTT1MtDQoJCQkgQ29t
cGxpYW5jZSBEZS1lbXBoYXNpczogLTZkQg0KCQlMbmtTdGEyOiBDdXJyZW50IERlLWVtcGhh
c2lzIExldmVsOiAtNmRCDQoJQ2FwYWJpbGl0aWVzOiBbYTBdIE1TSTogRW5hYmxlKyBDb3Vu
dD0xLzEgTWFza2FibGUtIDY0Yml0Kw0KCQlBZGRyZXNzOiAwMDAwMDAwMGZlZTAxMDBjICBE
YXRhOiA0MWQ5DQoJQ2FwYWJpbGl0aWVzOiBbMTAwIHYxXSBWZW5kb3IgU3BlY2lmaWMgSW5m
b3JtYXRpb246IElEPTAwMDEgUmV2PTEgTGVuPTAxMCA8Pz4NCglLZXJuZWwgZHJpdmVyIGlu
IHVzZTogc25kX2hkYV9pbnRlbA0KDQowNjowMC4wIE11bHRpbWVkaWEgdmlkZW8gY29udHJv
bGxlciBbMDQwMF06IENvbmV4YW50IFN5c3RlbXMsIEluYy4gRGV2aWNlIFsxNGYxOjgyMTBd
DQoJQ29udHJvbDogSS9PLSBNZW0rIEJ1c01hc3RlcisgU3BlY0N5Y2xlLSBNZW1XSU5WLSBW
R0FTbm9vcC0gUGFyRXJyLSBTdGVwcGluZy0gU0VSUi0gRmFzdEIyQi0gRGlzSU5UeC0NCglT
dGF0dXM6IENhcCsgNjZNSHotIFVERi0gRmFzdEIyQi0gUGFyRXJyLSBERVZTRUw9ZmFzdCA+
VEFib3J0LSA8VEFib3J0LSA8TUFib3J0LSA+U0VSUi0gPFBFUlItIElOVHgtDQoJTGF0ZW5j
eTogMA0KCUludGVycnVwdDogcGluIEEgcm91dGVkIHRvIElSUSA0Nw0KCVJlZ2lvbiAwOiBN
ZW1vcnkgYXQgZjlhMDAwMDAgKDY0LWJpdCwgbm9uLXByZWZldGNoYWJsZSkgW3NpemU9Mk1d
DQoJQ2FwYWJpbGl0aWVzOiBbNDBdIEV4cHJlc3MgKHYxKSBFbmRwb2ludCwgTVNJIDAwDQoJ
CURldkNhcDoJTWF4UGF5bG9hZCAxMjggYnl0ZXMsIFBoYW50RnVuYyAwLCBMYXRlbmN5IEww
cyA8NjRucywgTDEgPDF1cw0KCQkJRXh0VGFnLSBBdHRuQnRuLSBBdHRuSW5kLSBQd3JJbmQt
IFJCRSsgRkxSZXNldC0NCgkJRGV2Q3RsOglSZXBvcnQgZXJyb3JzOiBDb3JyZWN0YWJsZS0g
Tm9uLUZhdGFsLSBGYXRhbC0gVW5zdXBwb3J0ZWQtDQoJCQlSbHhkT3JkKyBFeHRUYWctIFBo
YW50RnVuYy0gQXV4UHdyLSBOb1Nub29wKw0KCQkJTWF4UGF5bG9hZCAxMjggYnl0ZXMsIE1h
eFJlYWRSZXEgNTEyIGJ5dGVzDQoJCURldlN0YToJQ29yckVycisgVW5jb3JyRXJyKyBGYXRh
bEVyci0gVW5zdXBwUmVxKyBBdXhQd3ItIFRyYW5zUGVuZC0NCgkJTG5rQ2FwOglQb3J0ICMw
LCBTcGVlZCAyLjVHVC9zLCBXaWR0aCB4MSwgQVNQTSBMMHMgTDEsIExhdGVuY3kgTDAgPDJ1
cywgTDEgPDR1cw0KCQkJQ2xvY2tQTS0gU3VycHJpc2UtIExMQWN0UmVwLSBCd05vdC0NCgkJ
TG5rQ3RsOglBU1BNIERpc2FibGVkOyBSQ0IgNjQgYnl0ZXMgRGlzYWJsZWQtIFJldHJhaW4t
IENvbW1DbGstDQoJCQlFeHRTeW5jaC0gQ2xvY2tQTS0gQXV0V2lkRGlzLSBCV0ludC0gQXV0
QldJbnQtDQoJCUxua1N0YToJU3BlZWQgMi41R1QvcywgV2lkdGggeDEsIFRyRXJyLSBUcmFp
bi0gU2xvdENsay0gRExBY3RpdmUtIEJXTWdtdC0gQUJXTWdtdC0NCglDYXBhYmlsaXRpZXM6
IFs4MF0gUG93ZXIgTWFuYWdlbWVudCB2ZXJzaW9uIDMNCgkJRmxhZ3M6IFBNRUNsay0gRFNJ
KyBEMSsgRDIrIEF1eEN1cnJlbnQ9MG1BIFBNRShEMCssRDErLEQyKyxEM2hvdCssRDNjb2xk
LSkNCgkJU3RhdHVzOiBEMCBOb1NvZnRSc3QrIFBNRS1FbmFibGUtIERTZWw9MCBEU2NhbGU9
MCBQTUUtDQoJQ2FwYWJpbGl0aWVzOiBbOTBdIFZpdGFsIFByb2R1Y3QgRGF0YQ0KCQlVbmtu
b3duIHNtYWxsIHJlc291cmNlIHR5cGUgMDAsIHdpbGwgbm90IGRlY29kZSBtb3JlLg0KCUNh
cGFiaWxpdGllczogW2EwXSBNU0k6IEVuYWJsZS0gQ291bnQ9MS8xIE1hc2thYmxlLSA2NGJp
dCsNCgkJQWRkcmVzczogMDAwMDAwMDAwMDAwMDAwMCAgRGF0YTogMDAwMA0KCUNhcGFiaWxp
dGllczogWzEwMCB2MV0gQWR2YW5jZWQgRXJyb3IgUmVwb3J0aW5nDQoJCVVFU3RhOglETFAt
IFNERVMtIFRMUC0gRkNQLSBDbXBsdFRPLSBDbXBsdEFicnQtIFVueENtcGx0LSBSeE9GLSBN
YWxmVExQLSBFQ1JDLSBVbnN1cFJlcSsgQUNTVmlvbC0NCgkJVUVNc2s6CURMUC0gU0RFUy0g
VExQLSBGQ1AtIENtcGx0VE8tIENtcGx0QWJydC0gVW54Q21wbHQtIFJ4T0YtIE1hbGZUTFAt
IEVDUkMtIFVuc3VwUmVxLSBBQ1NWaW9sLQ0KCQlVRVN2cnQ6CURMUCsgU0RFUy0gVExQLSBG
Q1ArIENtcGx0VE8tIENtcGx0QWJydC0gVW54Q21wbHQtIFJ4T0YrIE1hbGZUTFArIEVDUkMt
IFVuc3VwUmVxLSBBQ1NWaW9sLQ0KCQlDRVN0YToJUnhFcnItIEJhZFRMUC0gQmFkRExMUC0g
Um9sbG92ZXItIFRpbWVvdXQtIE5vbkZhdGFsRXJyKw0KCQlDRU1zazoJUnhFcnItIEJhZFRM
UC0gQmFkRExMUC0gUm9sbG92ZXItIFRpbWVvdXQtIE5vbkZhdGFsRXJyKw0KCQlBRVJDYXA6
CUZpcnN0IEVycm9yIFBvaW50ZXI6IDE0LCBHZW5DYXAtIENHZW5Fbi0gQ2hrQ2FwLSBDaGtF
bi0NCglDYXBhYmlsaXRpZXM6IFsyMDAgdjFdIFZpcnR1YWwgQ2hhbm5lbA0KCQlDYXBzOglM
UEVWQz0xIFJlZkNsaz0xMDBucyBQQVRFbnRyeUJpdHM9MQ0KCQlBcmI6CUZpeGVkKyBXUlIz
MisgV1JSNjQrIFdSUjEyOC0NCgkJQ3RybDoJQXJiU2VsZWN0PVdSUjY0DQoJCVN0YXR1czoJ
SW5Qcm9ncmVzcy0NCgkJUG9ydCBBcmJpdHJhdGlvbiBUYWJsZSBbMjQwXSA8Pz4NCgkJVkMw
OglDYXBzOglQQVRPZmZzZXQ9MDAgTWF4VGltZVNsb3RzPTEgUmVqU25vb3BUcmFucy0NCgkJ
CUFyYjoJRml4ZWQtIFdSUjMyLSBXUlI2NC0gV1JSMTI4LSBUV1JSMTI4LSBXUlIyNTYtDQoJ
CQlDdHJsOglFbmFibGUrIElEPTAgQXJiU2VsZWN0PUZpeGVkIFRDL1ZDPWZmDQoJCQlTdGF0
dXM6CU5lZ29QZW5kaW5nLSBJblByb2dyZXNzLQ0KCQlWQzE6CUNhcHM6CVBBVE9mZnNldD0w
MCBNYXhUaW1lU2xvdHM9MSBSZWpTbm9vcFRyYW5zLQ0KCQkJQXJiOglGaXhlZC0gV1JSMzIt
IFdSUjY0LSBXUlIxMjgtIFRXUlIxMjgtIFdSUjI1Ni0NCgkJCUN0cmw6CUVuYWJsZS0gSUQ9
MSBBcmJTZWxlY3Q9Rml4ZWQgVEMvVkM9MDANCgkJCVN0YXR1czoJTmVnb1BlbmRpbmctIElu
UHJvZ3Jlc3MtDQoJS2VybmVsIGRyaXZlciBpbiB1c2U6IHBjaWJhY2sNCg0KMDc6MDAuMCBF
dGhlcm5ldCBjb250cm9sbGVyIFswMjAwXTogUmVhbHRlayBTZW1pY29uZHVjdG9yIENvLiwg
THRkLiBSVEw4MTExLzgxNjhCIFBDSSBFeHByZXNzIEdpZ2FiaXQgRXRoZXJuZXQgY29udHJv
bGxlciBbMTBlYzo4MTY4XSAocmV2IDAzKQ0KCVN1YnN5c3RlbTogTWljcm8tU3RhciBJbnRl
cm5hdGlvbmFsIENvLiwgTHRkLiBEZXZpY2UgWzE0NjI6NzY0MF0NCglDb250cm9sOiBJL08r
IE1lbSsgQnVzTWFzdGVyKyBTcGVjQ3ljbGUtIE1lbVdJTlYtIFZHQVNub29wLSBQYXJFcnIt
IFN0ZXBwaW5nLSBTRVJSKyBGYXN0QjJCLSBEaXNJTlR4Kw0KCVN0YXR1czogQ2FwKyA2Nk1I
ei0gVURGLSBGYXN0QjJCLSBQYXJFcnItIERFVlNFTD1mYXN0ID5UQWJvcnQtIDxUQWJvcnQt
IDxNQWJvcnQtID5TRVJSLSA8UEVSUi0gSU5UeC0NCglMYXRlbmN5OiAwLCBDYWNoZSBMaW5l
IFNpemU6IDY0IGJ5dGVzDQoJSW50ZXJydXB0OiBwaW4gQSByb3V0ZWQgdG8gSVJRIDEyMQ0K
CVJlZ2lvbiAwOiBJL08gcG9ydHMgYXQgYzgwMCBbc2l6ZT0yNTZdDQoJUmVnaW9uIDI6IE1l
bW9yeSBhdCBjZmVmZjAwMCAoNjQtYml0LCBwcmVmZXRjaGFibGUpIFtzaXplPTRLXQ0KCVJl
Z2lvbiA0OiBNZW1vcnkgYXQgY2ZlZjgwMDAgKDY0LWJpdCwgcHJlZmV0Y2hhYmxlKSBbc2l6
ZT0xNktdDQoJRXhwYW5zaW9uIFJPTSBhdCBmOWRlMDAwMCBbZGlzYWJsZWRdIFtzaXplPTEy
OEtdDQoJQ2FwYWJpbGl0aWVzOiBbNDBdIFBvd2VyIE1hbmFnZW1lbnQgdmVyc2lvbiAzDQoJ
CUZsYWdzOiBQTUVDbGstIERTSS0gRDErIEQyKyBBdXhDdXJyZW50PTM3NW1BIFBNRShEMCss
RDErLEQyKyxEM2hvdCssRDNjb2xkKykNCgkJU3RhdHVzOiBEMCBOb1NvZnRSc3QrIFBNRS1F
bmFibGUtIERTZWw9MCBEU2NhbGU9MCBQTUUtDQoJQ2FwYWJpbGl0aWVzOiBbNTBdIE1TSTog
RW5hYmxlKyBDb3VudD0xLzEgTWFza2FibGUtIDY0Yml0Kw0KCQlBZGRyZXNzOiAwMDAwMDAw
MGZlZTAxMDBjICBEYXRhOiA0MWM5DQoJQ2FwYWJpbGl0aWVzOiBbNzBdIEV4cHJlc3MgKHYy
KSBFbmRwb2ludCwgTVNJIDAxDQoJCURldkNhcDoJTWF4UGF5bG9hZCAyNTYgYnl0ZXMsIFBo
YW50RnVuYyAwLCBMYXRlbmN5IEwwcyA8NTEybnMsIEwxIDw2NHVzDQoJCQlFeHRUYWctIEF0
dG5CdG4tIEF0dG5JbmQtIFB3ckluZC0gUkJFKyBGTFJlc2V0LQ0KCQlEZXZDdGw6CVJlcG9y
dCBlcnJvcnM6IENvcnJlY3RhYmxlLSBOb24tRmF0YWwtIEZhdGFsLSBVbnN1cHBvcnRlZC0N
CgkJCVJseGRPcmQtIEV4dFRhZy0gUGhhbnRGdW5jLSBBdXhQd3ItIE5vU25vb3AtDQoJCQlN
YXhQYXlsb2FkIDEyOCBieXRlcywgTWF4UmVhZFJlcSA1MTIgYnl0ZXMNCgkJRGV2U3RhOglD
b3JyRXJyKyBVbmNvcnJFcnItIEZhdGFsRXJyLSBVbnN1cHBSZXErIEF1eFB3cisgVHJhbnNQ
ZW5kLQ0KCQlMbmtDYXA6CVBvcnQgIzAsIFNwZWVkIDIuNUdUL3MsIFdpZHRoIHgxLCBBU1BN
IEwwcyBMMSwgTGF0ZW5jeSBMMCA8NTEybnMsIEwxIDw2NHVzDQoJCQlDbG9ja1BNKyBTdXJw
cmlzZS0gTExBY3RSZXAtIEJ3Tm90LQ0KCQlMbmtDdGw6CUFTUE0gRGlzYWJsZWQ7IFJDQiA2
NCBieXRlcyBEaXNhYmxlZC0gUmV0cmFpbi0gQ29tbUNsaysNCgkJCUV4dFN5bmNoLSBDbG9j
a1BNLSBBdXRXaWREaXMtIEJXSW50LSBBdXRCV0ludC0NCgkJTG5rU3RhOglTcGVlZCAyLjVH
VC9zLCBXaWR0aCB4MSwgVHJFcnItIFRyYWluLSBTbG90Q2xrKyBETEFjdGl2ZS0gQldNZ210
LSBBQldNZ210LQ0KCQlEZXZDYXAyOiBDb21wbGV0aW9uIFRpbWVvdXQ6IE5vdCBTdXBwb3J0
ZWQsIFRpbWVvdXREaXMrDQoJCURldkN0bDI6IENvbXBsZXRpb24gVGltZW91dDogNTB1cyB0
byA1MG1zLCBUaW1lb3V0RGlzLQ0KCQlMbmtDdGwyOiBUYXJnZXQgTGluayBTcGVlZDogMi41
R1QvcywgRW50ZXJDb21wbGlhbmNlLSBTcGVlZERpcy0sIFNlbGVjdGFibGUgRGUtZW1waGFz
aXM6IC02ZEINCgkJCSBUcmFuc21pdCBNYXJnaW46IE5vcm1hbCBPcGVyYXRpbmcgUmFuZ2Us
IEVudGVyTW9kaWZpZWRDb21wbGlhbmNlLSBDb21wbGlhbmNlU09TLQ0KCQkJIENvbXBsaWFu
Y2UgRGUtZW1waGFzaXM6IC02ZEINCgkJTG5rU3RhMjogQ3VycmVudCBEZS1lbXBoYXNpcyBM
ZXZlbDogLTZkQg0KCUNhcGFiaWxpdGllczogW2FjXSBNU0ktWDogRW5hYmxlLSBDb3VudD00
IE1hc2tlZC0NCgkJVmVjdG9yIHRhYmxlOiBCQVI9NCBvZmZzZXQ9MDAwMDAwMDANCgkJUEJB
OiBCQVI9NCBvZmZzZXQ9MDAwMDA4MDANCglDYXBhYmlsaXRpZXM6IFtjY10gVml0YWwgUHJv
ZHVjdCBEYXRhDQoJCVVua25vd24gc21hbGwgcmVzb3VyY2UgdHlwZSAwMCwgd2lsbCBub3Qg
ZGVjb2RlIG1vcmUuDQoJQ2FwYWJpbGl0aWVzOiBbMTAwIHYxXSBBZHZhbmNlZCBFcnJvciBS
ZXBvcnRpbmcNCgkJVUVTdGE6CURMUC0gU0RFUy0gVExQLSBGQ1AtIENtcGx0VE8tIENtcGx0
QWJydC0gVW54Q21wbHQtIFJ4T0YtIE1hbGZUTFAtIEVDUkMtIFVuc3VwUmVxLSBBQ1NWaW9s
LQ0KCQlVRU1zazoJRExQLSBTREVTLSBUTFAtIEZDUC0gQ21wbHRUTy0gQ21wbHRBYnJ0LSBV
bnhDbXBsdC0gUnhPRi0gTWFsZlRMUC0gRUNSQy0gVW5zdXBSZXEtIEFDU1Zpb2wtDQoJCVVF
U3ZydDoJRExQKyBTREVTKyBUTFAtIEZDUCsgQ21wbHRUTy0gQ21wbHRBYnJ0LSBVbnhDbXBs
dC0gUnhPRisgTWFsZlRMUCsgRUNSQy0gVW5zdXBSZXEtIEFDU1Zpb2wtDQoJCUNFU3RhOglS
eEVyci0gQmFkVExQLSBCYWRETExQLSBSb2xsb3Zlci0gVGltZW91dC0gTm9uRmF0YWxFcnIr
DQoJCUNFTXNrOglSeEVyci0gQmFkVExQLSBCYWRETExQLSBSb2xsb3Zlci0gVGltZW91dC0g
Tm9uRmF0YWxFcnIrDQoJCUFFUkNhcDoJRmlyc3QgRXJyb3IgUG9pbnRlcjogMDAsIEdlbkNh
cCsgQ0dlbkVuLSBDaGtDYXArIENoa0VuLQ0KCUNhcGFiaWxpdGllczogWzE0MCB2MV0gVmly
dHVhbCBDaGFubmVsDQoJCUNhcHM6CUxQRVZDPTAgUmVmQ2xrPTEwMG5zIFBBVEVudHJ5Qml0
cz0xDQoJCUFyYjoJRml4ZWQtIFdSUjMyLSBXUlI2NC0gV1JSMTI4LQ0KCQlDdHJsOglBcmJT
ZWxlY3Q9Rml4ZWQNCgkJU3RhdHVzOglJblByb2dyZXNzLQ0KCQlWQzA6CUNhcHM6CVBBVE9m
ZnNldD0wMCBNYXhUaW1lU2xvdHM9MSBSZWpTbm9vcFRyYW5zLQ0KCQkJQXJiOglGaXhlZC0g
V1JSMzItIFdSUjY0LSBXUlIxMjgtIFRXUlIxMjgtIFdSUjI1Ni0NCgkJCUN0cmw6CUVuYWJs
ZSsgSUQ9MCBBcmJTZWxlY3Q9Rml4ZWQgVEMvVkM9ZmYNCgkJCVN0YXR1czoJTmVnb1BlbmRp
bmctIEluUHJvZ3Jlc3MtDQoJQ2FwYWJpbGl0aWVzOiBbMTYwIHYxXSBEZXZpY2UgU2VyaWFs
IE51bWJlciAwMy0wMC0wMC0wMC02OC00Yy1lMC0wMA0KCUtlcm5lbCBkcml2ZXIgaW4gdXNl
OiByODE2OQ0KDQowODowMC4wIEV0aGVybmV0IGNvbnRyb2xsZXIgWzAyMDBdOiBSZWFsdGVr
IFNlbWljb25kdWN0b3IgQ28uLCBMdGQuIFJUTDgxMTEvODE2OEIgUENJIEV4cHJlc3MgR2ln
YWJpdCBFdGhlcm5ldCBjb250cm9sbGVyIFsxMGVjOjgxNjhdIChyZXYgMDMpDQoJU3Vic3lz
dGVtOiBNaWNyby1TdGFyIEludGVybmF0aW9uYWwgQ28uLCBMdGQuIERldmljZSBbMTQ2Mjo3
NjQwXQ0KCUNvbnRyb2w6IEkvTysgTWVtKyBCdXNNYXN0ZXIrIFNwZWNDeWNsZS0gTWVtV0lO
Vi0gVkdBU25vb3AtIFBhckVyci0gU3RlcHBpbmctIFNFUlIrIEZhc3RCMkItIERpc0lOVHgr
DQoJU3RhdHVzOiBDYXArIDY2TUh6LSBVREYtIEZhc3RCMkItIFBhckVyci0gREVWU0VMPWZh
c3QgPlRBYm9ydC0gPFRBYm9ydC0gPE1BYm9ydC0gPlNFUlItIDxQRVJSLSBJTlR4LQ0KCUxh
dGVuY3k6IDAsIENhY2hlIExpbmUgU2l6ZTogNjQgYnl0ZXMNCglJbnRlcnJ1cHQ6IHBpbiBB
IHJvdXRlZCB0byBJUlEgMTIwDQoJUmVnaW9uIDA6IEkvTyBwb3J0cyBhdCBkODAwIFtzaXpl
PTI1Nl0NCglSZWdpb24gMjogTWVtb3J5IGF0IGNmZmZmMDAwICg2NC1iaXQsIHByZWZldGNo
YWJsZSkgW3NpemU9NEtdDQoJUmVnaW9uIDQ6IE1lbW9yeSBhdCBjZmZmODAwMCAoNjQtYml0
LCBwcmVmZXRjaGFibGUpIFtzaXplPTE2S10NCglFeHBhbnNpb24gUk9NIGF0IGY5ZWUwMDAw
IFtkaXNhYmxlZF0gW3NpemU9MTI4S10NCglDYXBhYmlsaXRpZXM6IFs0MF0gUG93ZXIgTWFu
YWdlbWVudCB2ZXJzaW9uIDMNCgkJRmxhZ3M6IFBNRUNsay0gRFNJLSBEMSsgRDIrIEF1eEN1
cnJlbnQ9Mzc1bUEgUE1FKEQwKyxEMSssRDIrLEQzaG90KyxEM2NvbGQrKQ0KCQlTdGF0dXM6
IEQwIE5vU29mdFJzdCsgUE1FLUVuYWJsZS0gRFNlbD0wIERTY2FsZT0wIFBNRS0NCglDYXBh
YmlsaXRpZXM6IFs1MF0gTVNJOiBFbmFibGUrIENvdW50PTEvMSBNYXNrYWJsZS0gNjRiaXQr
DQoJCUFkZHJlc3M6IDAwMDAwMDAwZmVlMDEwMGMgIERhdGE6IDQxYjkNCglDYXBhYmlsaXRp
ZXM6IFs3MF0gRXhwcmVzcyAodjIpIEVuZHBvaW50LCBNU0kgMDENCgkJRGV2Q2FwOglNYXhQ
YXlsb2FkIDI1NiBieXRlcywgUGhhbnRGdW5jIDAsIExhdGVuY3kgTDBzIDw1MTJucywgTDEg
PDY0dXMNCgkJCUV4dFRhZy0gQXR0bkJ0bi0gQXR0bkluZC0gUHdySW5kLSBSQkUrIEZMUmVz
ZXQtDQoJCURldkN0bDoJUmVwb3J0IGVycm9yczogQ29ycmVjdGFibGUtIE5vbi1GYXRhbC0g
RmF0YWwtIFVuc3VwcG9ydGVkLQ0KCQkJUmx4ZE9yZC0gRXh0VGFnLSBQaGFudEZ1bmMtIEF1
eFB3ci0gTm9Tbm9vcC0NCgkJCU1heFBheWxvYWQgMTI4IGJ5dGVzLCBNYXhSZWFkUmVxIDQw
OTYgYnl0ZXMNCgkJRGV2U3RhOglDb3JyRXJyKyBVbmNvcnJFcnItIEZhdGFsRXJyLSBVbnN1
cHBSZXErIEF1eFB3cisgVHJhbnNQZW5kLQ0KCQlMbmtDYXA6CVBvcnQgIzAsIFNwZWVkIDIu
NUdUL3MsIFdpZHRoIHgxLCBBU1BNIEwwcyBMMSwgTGF0ZW5jeSBMMCA8NTEybnMsIEwxIDw2
NHVzDQoJCQlDbG9ja1BNKyBTdXJwcmlzZS0gTExBY3RSZXAtIEJ3Tm90LQ0KCQlMbmtDdGw6
CUFTUE0gRGlzYWJsZWQ7IFJDQiA2NCBieXRlcyBEaXNhYmxlZC0gUmV0cmFpbi0gQ29tbUNs
aysNCgkJCUV4dFN5bmNoLSBDbG9ja1BNLSBBdXRXaWREaXMtIEJXSW50LSBBdXRCV0ludC0N
CgkJTG5rU3RhOglTcGVlZCAyLjVHVC9zLCBXaWR0aCB4MSwgVHJFcnItIFRyYWluLSBTbG90
Q2xrKyBETEFjdGl2ZS0gQldNZ210LSBBQldNZ210LQ0KCQlEZXZDYXAyOiBDb21wbGV0aW9u
IFRpbWVvdXQ6IE5vdCBTdXBwb3J0ZWQsIFRpbWVvdXREaXMrDQoJCURldkN0bDI6IENvbXBs
ZXRpb24gVGltZW91dDogNTB1cyB0byA1MG1zLCBUaW1lb3V0RGlzLQ0KCQlMbmtDdGwyOiBU
YXJnZXQgTGluayBTcGVlZDogMi41R1QvcywgRW50ZXJDb21wbGlhbmNlLSBTcGVlZERpcy0s
IFNlbGVjdGFibGUgRGUtZW1waGFzaXM6IC02ZEINCgkJCSBUcmFuc21pdCBNYXJnaW46IE5v
cm1hbCBPcGVyYXRpbmcgUmFuZ2UsIEVudGVyTW9kaWZpZWRDb21wbGlhbmNlLSBDb21wbGlh
bmNlU09TLQ0KCQkJIENvbXBsaWFuY2UgRGUtZW1waGFzaXM6IC02ZEINCgkJTG5rU3RhMjog
Q3VycmVudCBEZS1lbXBoYXNpcyBMZXZlbDogLTZkQg0KCUNhcGFiaWxpdGllczogW2FjXSBN
U0ktWDogRW5hYmxlLSBDb3VudD00IE1hc2tlZC0NCgkJVmVjdG9yIHRhYmxlOiBCQVI9NCBv
ZmZzZXQ9MDAwMDAwMDANCgkJUEJBOiBCQVI9NCBvZmZzZXQ9MDAwMDA4MDANCglDYXBhYmls
aXRpZXM6IFtjY10gVml0YWwgUHJvZHVjdCBEYXRhDQoJCVVua25vd24gc21hbGwgcmVzb3Vy
Y2UgdHlwZSAwMCwgd2lsbCBub3QgZGVjb2RlIG1vcmUuDQoJQ2FwYWJpbGl0aWVzOiBbMTAw
IHYxXSBBZHZhbmNlZCBFcnJvciBSZXBvcnRpbmcNCgkJVUVTdGE6CURMUC0gU0RFUy0gVExQ
LSBGQ1AtIENtcGx0VE8tIENtcGx0QWJydC0gVW54Q21wbHQtIFJ4T0YtIE1hbGZUTFAtIEVD
UkMtIFVuc3VwUmVxLSBBQ1NWaW9sLQ0KCQlVRU1zazoJRExQLSBTREVTLSBUTFAtIEZDUC0g
Q21wbHRUTy0gQ21wbHRBYnJ0LSBVbnhDbXBsdC0gUnhPRi0gTWFsZlRMUC0gRUNSQy0gVW5z
dXBSZXEtIEFDU1Zpb2wtDQoJCVVFU3ZydDoJRExQKyBTREVTKyBUTFAtIEZDUCsgQ21wbHRU
Ty0gQ21wbHRBYnJ0LSBVbnhDbXBsdC0gUnhPRisgTWFsZlRMUCsgRUNSQy0gVW5zdXBSZXEt
IEFDU1Zpb2wtDQoJCUNFU3RhOglSeEVyci0gQmFkVExQLSBCYWRETExQLSBSb2xsb3Zlci0g
VGltZW91dC0gTm9uRmF0YWxFcnIrDQoJCUNFTXNrOglSeEVyci0gQmFkVExQLSBCYWRETExQ
LSBSb2xsb3Zlci0gVGltZW91dC0gTm9uRmF0YWxFcnIrDQoJCUFFUkNhcDoJRmlyc3QgRXJy
b3IgUG9pbnRlcjogMDAsIEdlbkNhcCsgQ0dlbkVuLSBDaGtDYXArIENoa0VuLQ0KCUNhcGFi
aWxpdGllczogWzE0MCB2MV0gVmlydHVhbCBDaGFubmVsDQoJCUNhcHM6CUxQRVZDPTAgUmVm
Q2xrPTEwMG5zIFBBVEVudHJ5Qml0cz0xDQoJCUFyYjoJRml4ZWQtIFdSUjMyLSBXUlI2NC0g
V1JSMTI4LQ0KCQlDdHJsOglBcmJTZWxlY3Q9Rml4ZWQNCgkJU3RhdHVzOglJblByb2dyZXNz
LQ0KCQlWQzA6CUNhcHM6CVBBVE9mZnNldD0wMCBNYXhUaW1lU2xvdHM9MSBSZWpTbm9vcFRy
YW5zLQ0KCQkJQXJiOglGaXhlZC0gV1JSMzItIFdSUjY0LSBXUlIxMjgtIFRXUlIxMjgtIFdS
UjI1Ni0NCgkJCUN0cmw6CUVuYWJsZSsgSUQ9MCBBcmJTZWxlY3Q9Rml4ZWQgVEMvVkM9ZmYN
CgkJCVN0YXR1czoJTmVnb1BlbmRpbmctIEluUHJvZ3Jlc3MtDQoJQ2FwYWJpbGl0aWVzOiBb
MTYwIHYxXSBEZXZpY2UgU2VyaWFsIE51bWJlciAwNC0wMC0wMC0wMC02OC00Yy1lMC0wMA0K
CUtlcm5lbCBkcml2ZXIgaW4gdXNlOiByODE2OQ0KDQowOTowMC4wIFVTQiBjb250cm9sbGVy
IFswYzAzXTogTmV0TW9zIFRlY2hub2xvZ3kgTUNTOTk5MCBQQ0llIHRvIDTigJBQb3J0IFVT
QiAyLjAgSG9zdCBDb250cm9sbGVyIFs5NzEwOjk5OTBdIChwcm9nLWlmIDEwIFtPSENJXSkN
CglTdWJzeXN0ZW06IERldmljZSBbYTAwMDo0MDAwXQ0KCUNvbnRyb2w6IEkvTy0gTWVtLSBC
dXNNYXN0ZXItIFNwZWNDeWNsZS0gTWVtV0lOVi0gVkdBU25vb3AtIFBhckVyci0gU3RlcHBp
bmctIFNFUlItIEZhc3RCMkItIERpc0lOVHgtDQoJU3RhdHVzOiBDYXArIDY2TUh6LSBVREYt
IEZhc3RCMkItIFBhckVyci0gREVWU0VMPWZhc3QgPlRBYm9ydC0gPFRBYm9ydC0gPE1BYm9y
dC0gPlNFUlItIDxQRVJSLSBJTlR4LQ0KCUludGVycnVwdDogcGluIEEgcm91dGVkIHRvIElS
USAyOA0KCVJlZ2lvbiAwOiBNZW1vcnkgYXQgZjlmZjgwMDAgKDMyLWJpdCwgbm9uLXByZWZl
dGNoYWJsZSkgW2Rpc2FibGVkXSBbc2l6ZT00S10NCglDYXBhYmlsaXRpZXM6IFs1MF0gTVNJ
OiBFbmFibGUtIENvdW50PTEvMSBNYXNrYWJsZS0gNjRiaXQrDQoJCUFkZHJlc3M6IDAwMDAw
MDAwMDAwMDAwMDAgIERhdGE6IDAwMDANCglDYXBhYmlsaXRpZXM6IFs3OF0gUG93ZXIgTWFu
YWdlbWVudCB2ZXJzaW9uIDMNCgkJRmxhZ3M6IFBNRUNsay0gRFNJLSBEMSsgRDIrIEF1eEN1
cnJlbnQ9Mzc1bUEgUE1FKEQwKyxEMSssRDIrLEQzaG90KyxEM2NvbGQtKQ0KCQlTdGF0dXM6
IEQwIE5vU29mdFJzdCsgUE1FLUVuYWJsZS0gRFNlbD0wIERTY2FsZT0wIFBNRS0NCglDYXBh
YmlsaXRpZXM6IFs4MF0gRXhwcmVzcyAodjEpIEVuZHBvaW50LCBNU0kgMDANCgkJRGV2Q2Fw
OglNYXhQYXlsb2FkIDI1NiBieXRlcywgUGhhbnRGdW5jIDAsIExhdGVuY3kgTDBzIHVubGlt
aXRlZCwgTDEgdW5saW1pdGVkDQoJCQlFeHRUYWctIEF0dG5CdG4tIEF0dG5JbmQtIFB3cklu
ZC0gUkJFKyBGTFJlc2V0LQ0KCQlEZXZDdGw6CVJlcG9ydCBlcnJvcnM6IENvcnJlY3RhYmxl
LSBOb24tRmF0YWwtIEZhdGFsLSBVbnN1cHBvcnRlZC0NCgkJCVJseGRPcmQtIEV4dFRhZy0g
UGhhbnRGdW5jLSBBdXhQd3ItIE5vU25vb3ArDQoJCQlNYXhQYXlsb2FkIDEyOCBieXRlcywg
TWF4UmVhZFJlcSA1MTIgYnl0ZXMNCgkJRGV2U3RhOglDb3JyRXJyLSBVbmNvcnJFcnItIEZh
dGFsRXJyLSBVbnN1cHBSZXEtIEF1eFB3ci0gVHJhbnNQZW5kLQ0KCQlMbmtDYXA6CVBvcnQg
IzEsIFNwZWVkIDIuNUdUL3MsIFdpZHRoIHgxLCBBU1BNIHVua25vd24sIExhdGVuY3kgTDAg
PDY0bnMsIEwxIHVubGltaXRlZA0KCQkJQ2xvY2tQTSsgU3VycHJpc2UtIExMQWN0UmVwLSBC
d05vdC0NCgkJTG5rQ3RsOglBU1BNIERpc2FibGVkOyBSQ0IgNjQgYnl0ZXMgRGlzYWJsZWQt
IFJldHJhaW4tIENvbW1DbGstDQoJCQlFeHRTeW5jaC0gQ2xvY2tQTS0gQXV0V2lkRGlzLSBC
V0ludC0gQXV0QldJbnQtDQoJCUxua1N0YToJU3BlZWQgMi41R1QvcywgV2lkdGggeDEsIFRy
RXJyLSBUcmFpbi0gU2xvdENsay0gRExBY3RpdmUtIEJXTWdtdC0gQUJXTWdtdC0NCglDYXBh
YmlsaXRpZXM6IFsxMDAgdjFdIFZpcnR1YWwgQ2hhbm5lbA0KCQlDYXBzOglMUEVWQz0wIFJl
ZkNsaz0xMDBucyBQQVRFbnRyeUJpdHM9MQ0KCQlBcmI6CUZpeGVkLSBXUlIzMi0gV1JSNjQt
IFdSUjEyOC0NCgkJQ3RybDoJQXJiU2VsZWN0PUZpeGVkDQoJCVN0YXR1czoJSW5Qcm9ncmVz
cy0NCgkJVkMwOglDYXBzOglQQVRPZmZzZXQ9MDAgTWF4VGltZVNsb3RzPTEgUmVqU25vb3BU
cmFucy0NCgkJCUFyYjoJRml4ZWQtIFdSUjMyLSBXUlI2NC0gV1JSMTI4LSBUV1JSMTI4LSBX
UlIyNTYtDQoJCQlDdHJsOglFbmFibGUrIElEPTAgQXJiU2VsZWN0PUZpeGVkIFRDL1ZDPWZm
DQoJCQlTdGF0dXM6CU5lZ29QZW5kaW5nLSBJblByb2dyZXNzLQ0KCUtlcm5lbCBkcml2ZXIg
aW4gdXNlOiBwY2liYWNrDQoNCjA5OjAwLjEgVVNCIGNvbnRyb2xsZXIgWzBjMDNdOiBOZXRN
b3MgVGVjaG5vbG9neSBNQ1M5OTkwIFBDSWUgdG8gNOKAkFBvcnQgVVNCIDIuMCBIb3N0IENv
bnRyb2xsZXIgWzk3MTA6OTk5MF0gKHByb2ctaWYgMjAgW0VIQ0ldKQ0KCVN1YnN5c3RlbTog
RGV2aWNlIFthMDAwOjQwMDBdDQoJQ29udHJvbDogSS9PLSBNZW0tIEJ1c01hc3Rlci0gU3Bl
Y0N5Y2xlLSBNZW1XSU5WLSBWR0FTbm9vcC0gUGFyRXJyLSBTdGVwcGluZy0gU0VSUi0gRmFz
dEIyQi0gRGlzSU5UeC0NCglTdGF0dXM6IENhcCsgNjZNSHotIFVERi0gRmFzdEIyQi0gUGFy
RXJyLSBERVZTRUw9ZmFzdCA+VEFib3J0LSA8VEFib3J0LSA8TUFib3J0LSA+U0VSUi0gPFBF
UlItIElOVHgtDQoJSW50ZXJydXB0OiBwaW4gQSByb3V0ZWQgdG8gSVJRIDI4DQoJUmVnaW9u
IDA6IE1lbW9yeSBhdCBmOWZmOTAwMCAoMzItYml0LCBub24tcHJlZmV0Y2hhYmxlKSBbZGlz
YWJsZWRdIFtzaXplPTRLXQ0KCUNhcGFiaWxpdGllczogWzUwXSBNU0k6IEVuYWJsZS0gQ291
bnQ9MS8xIE1hc2thYmxlLSA2NGJpdCsNCgkJQWRkcmVzczogMDAwMDAwMDAwMDAwMDAwMCAg
RGF0YTogMDAwMA0KCUNhcGFiaWxpdGllczogWzc4XSBQb3dlciBNYW5hZ2VtZW50IHZlcnNp
b24gMw0KCQlGbGFnczogUE1FQ2xrLSBEU0ktIEQxKyBEMisgQXV4Q3VycmVudD0zNzVtQSBQ
TUUoRDArLEQxKyxEMissRDNob3QrLEQzY29sZC0pDQoJCVN0YXR1czogRDAgTm9Tb2Z0UnN0
KyBQTUUtRW5hYmxlLSBEU2VsPTAgRFNjYWxlPTAgUE1FLQ0KCUNhcGFiaWxpdGllczogWzgw
XSBFeHByZXNzICh2MSkgRW5kcG9pbnQsIE1TSSAwMA0KCQlEZXZDYXA6CU1heFBheWxvYWQg
MjU2IGJ5dGVzLCBQaGFudEZ1bmMgMCwgTGF0ZW5jeSBMMHMgdW5saW1pdGVkLCBMMSB1bmxp
bWl0ZWQNCgkJCUV4dFRhZy0gQXR0bkJ0bi0gQXR0bkluZC0gUHdySW5kLSBSQkUrIEZMUmVz
ZXQtDQoJCURldkN0bDoJUmVwb3J0IGVycm9yczogQ29ycmVjdGFibGUtIE5vbi1GYXRhbC0g
RmF0YWwtIFVuc3VwcG9ydGVkLQ0KCQkJUmx4ZE9yZC0gRXh0VGFnLSBQaGFudEZ1bmMtIEF1
eFB3ci0gTm9Tbm9vcCsNCgkJCU1heFBheWxvYWQgMTI4IGJ5dGVzLCBNYXhSZWFkUmVxIDUx
MiBieXRlcw0KCQlEZXZTdGE6CUNvcnJFcnItIFVuY29yckVyci0gRmF0YWxFcnItIFVuc3Vw
cFJlcS0gQXV4UHdyLSBUcmFuc1BlbmQtDQoJCUxua0NhcDoJUG9ydCAjMSwgU3BlZWQgMi41
R1QvcywgV2lkdGggeDEsIEFTUE0gdW5rbm93biwgTGF0ZW5jeSBMMCA8NjRucywgTDEgdW5s
aW1pdGVkDQoJCQlDbG9ja1BNKyBTdXJwcmlzZS0gTExBY3RSZXAtIEJ3Tm90LQ0KCQlMbmtD
dGw6CUFTUE0gRGlzYWJsZWQ7IFJDQiA2NCBieXRlcyBEaXNhYmxlZC0gUmV0cmFpbi0gQ29t
bUNsay0NCgkJCUV4dFN5bmNoLSBDbG9ja1BNLSBBdXRXaWREaXMtIEJXSW50LSBBdXRCV0lu
dC0NCgkJTG5rU3RhOglTcGVlZCAyLjVHVC9zLCBXaWR0aCB4MSwgVHJFcnItIFRyYWluLSBT
bG90Q2xrLSBETEFjdGl2ZS0gQldNZ210LSBBQldNZ210LQ0KCUtlcm5lbCBkcml2ZXIgaW4g
dXNlOiBwY2liYWNrDQoNCjA5OjAwLjIgVVNCIGNvbnRyb2xsZXIgWzBjMDNdOiBOZXRNb3Mg
VGVjaG5vbG9neSBNQ1M5OTkwIFBDSWUgdG8gNOKAkFBvcnQgVVNCIDIuMCBIb3N0IENvbnRy
b2xsZXIgWzk3MTA6OTk5MF0gKHByb2ctaWYgMTAgW09IQ0ldKQ0KCVN1YnN5c3RlbTogRGV2
aWNlIFthMDAwOjQwMDBdDQoJQ29udHJvbDogSS9PLSBNZW0tIEJ1c01hc3Rlci0gU3BlY0N5
Y2xlLSBNZW1XSU5WLSBWR0FTbm9vcC0gUGFyRXJyLSBTdGVwcGluZy0gU0VSUi0gRmFzdEIy
Qi0gRGlzSU5UeC0NCglTdGF0dXM6IENhcCsgNjZNSHotIFVERi0gRmFzdEIyQi0gUGFyRXJy
LSBERVZTRUw9ZmFzdCA+VEFib3J0LSA8VEFib3J0LSA8TUFib3J0LSA+U0VSUi0gPFBFUlIt
IElOVHgtDQoJSW50ZXJydXB0OiBwaW4gQiByb3V0ZWQgdG8gSVJRIDI5DQoJUmVnaW9uIDA6
IE1lbW9yeSBhdCBmOWZmYTAwMCAoMzItYml0LCBub24tcHJlZmV0Y2hhYmxlKSBbZGlzYWJs
ZWRdIFtzaXplPTRLXQ0KCUNhcGFiaWxpdGllczogWzUwXSBNU0k6IEVuYWJsZS0gQ291bnQ9
MS8xIE1hc2thYmxlLSA2NGJpdCsNCgkJQWRkcmVzczogMDAwMDAwMDAwMDAwMDAwMCAgRGF0
YTogMDAwMA0KCUNhcGFiaWxpdGllczogWzc4XSBQb3dlciBNYW5hZ2VtZW50IHZlcnNpb24g
Mw0KCQlGbGFnczogUE1FQ2xrLSBEU0ktIEQxKyBEMisgQXV4Q3VycmVudD0zNzVtQSBQTUUo
RDArLEQxKyxEMissRDNob3QrLEQzY29sZC0pDQoJCVN0YXR1czogRDAgTm9Tb2Z0UnN0KyBQ
TUUtRW5hYmxlLSBEU2VsPTAgRFNjYWxlPTAgUE1FLQ0KCUNhcGFiaWxpdGllczogWzgwXSBF
eHByZXNzICh2MSkgRW5kcG9pbnQsIE1TSSAwMA0KCQlEZXZDYXA6CU1heFBheWxvYWQgMjU2
IGJ5dGVzLCBQaGFudEZ1bmMgMCwgTGF0ZW5jeSBMMHMgdW5saW1pdGVkLCBMMSB1bmxpbWl0
ZWQNCgkJCUV4dFRhZy0gQXR0bkJ0bi0gQXR0bkluZC0gUHdySW5kLSBSQkUrIEZMUmVzZXQt
DQoJCURldkN0bDoJUmVwb3J0IGVycm9yczogQ29ycmVjdGFibGUtIE5vbi1GYXRhbC0gRmF0
YWwtIFVuc3VwcG9ydGVkLQ0KCQkJUmx4ZE9yZC0gRXh0VGFnLSBQaGFudEZ1bmMtIEF1eFB3
ci0gTm9Tbm9vcCsNCgkJCU1heFBheWxvYWQgMTI4IGJ5dGVzLCBNYXhSZWFkUmVxIDUxMiBi
eXRlcw0KCQlEZXZTdGE6CUNvcnJFcnItIFVuY29yckVyci0gRmF0YWxFcnItIFVuc3VwcFJl
cS0gQXV4UHdyLSBUcmFuc1BlbmQtDQoJCUxua0NhcDoJUG9ydCAjMSwgU3BlZWQgMi41R1Qv
cywgV2lkdGggeDEsIEFTUE0gdW5rbm93biwgTGF0ZW5jeSBMMCA8NjRucywgTDEgdW5saW1p
dGVkDQoJCQlDbG9ja1BNKyBTdXJwcmlzZS0gTExBY3RSZXAtIEJ3Tm90LQ0KCQlMbmtDdGw6
CUFTUE0gRGlzYWJsZWQ7IFJDQiA2NCBieXRlcyBEaXNhYmxlZC0gUmV0cmFpbi0gQ29tbUNs
ay0NCgkJCUV4dFN5bmNoLSBDbG9ja1BNLSBBdXRXaWREaXMtIEJXSW50LSBBdXRCV0ludC0N
CgkJTG5rU3RhOglTcGVlZCAyLjVHVC9zLCBXaWR0aCB4MSwgVHJFcnItIFRyYWluLSBTbG90
Q2xrLSBETEFjdGl2ZS0gQldNZ210LSBBQldNZ210LQ0KCUtlcm5lbCBkcml2ZXIgaW4gdXNl
OiBwY2liYWNrDQoNCjA5OjAwLjMgVVNCIGNvbnRyb2xsZXIgWzBjMDNdOiBOZXRNb3MgVGVj
aG5vbG9neSBNQ1M5OTkwIFBDSWUgdG8gNOKAkFBvcnQgVVNCIDIuMCBIb3N0IENvbnRyb2xs
ZXIgWzk3MTA6OTk5MF0gKHByb2ctaWYgMjAgW0VIQ0ldKQ0KCVN1YnN5c3RlbTogRGV2aWNl
IFthMDAwOjQwMDBdDQoJQ29udHJvbDogSS9PLSBNZW0tIEJ1c01hc3Rlci0gU3BlY0N5Y2xl
LSBNZW1XSU5WLSBWR0FTbm9vcC0gUGFyRXJyLSBTdGVwcGluZy0gU0VSUi0gRmFzdEIyQi0g
RGlzSU5UeC0NCglTdGF0dXM6IENhcCsgNjZNSHotIFVERi0gRmFzdEIyQi0gUGFyRXJyLSBE
RVZTRUw9ZmFzdCA+VEFib3J0LSA8VEFib3J0LSA8TUFib3J0LSA+U0VSUi0gPFBFUlItIElO
VHgtDQoJSW50ZXJydXB0OiBwaW4gQiByb3V0ZWQgdG8gSVJRIDI5DQoJUmVnaW9uIDA6IE1l
bW9yeSBhdCBmOWZmYjAwMCAoMzItYml0LCBub24tcHJlZmV0Y2hhYmxlKSBbZGlzYWJsZWRd
IFtzaXplPTRLXQ0KCUNhcGFiaWxpdGllczogWzUwXSBNU0k6IEVuYWJsZS0gQ291bnQ9MS8x
IE1hc2thYmxlLSA2NGJpdCsNCgkJQWRkcmVzczogMDAwMDAwMDAwMDAwMDAwMCAgRGF0YTog
MDAwMA0KCUNhcGFiaWxpdGllczogWzc4XSBQb3dlciBNYW5hZ2VtZW50IHZlcnNpb24gMw0K
CQlGbGFnczogUE1FQ2xrLSBEU0ktIEQxKyBEMisgQXV4Q3VycmVudD0zNzVtQSBQTUUoRDAr
LEQxKyxEMissRDNob3QrLEQzY29sZC0pDQoJCVN0YXR1czogRDAgTm9Tb2Z0UnN0KyBQTUUt
RW5hYmxlLSBEU2VsPTAgRFNjYWxlPTAgUE1FLQ0KCUNhcGFiaWxpdGllczogWzgwXSBFeHBy
ZXNzICh2MSkgRW5kcG9pbnQsIE1TSSAwMA0KCQlEZXZDYXA6CU1heFBheWxvYWQgMjU2IGJ5
dGVzLCBQaGFudEZ1bmMgMCwgTGF0ZW5jeSBMMHMgdW5saW1pdGVkLCBMMSB1bmxpbWl0ZWQN
CgkJCUV4dFRhZy0gQXR0bkJ0bi0gQXR0bkluZC0gUHdySW5kLSBSQkUrIEZMUmVzZXQtDQoJ
CURldkN0bDoJUmVwb3J0IGVycm9yczogQ29ycmVjdGFibGUtIE5vbi1GYXRhbC0gRmF0YWwt
IFVuc3VwcG9ydGVkLQ0KCQkJUmx4ZE9yZC0gRXh0VGFnLSBQaGFudEZ1bmMtIEF1eFB3ci0g
Tm9Tbm9vcCsNCgkJCU1heFBheWxvYWQgMTI4IGJ5dGVzLCBNYXhSZWFkUmVxIDUxMiBieXRl
cw0KCQlEZXZTdGE6CUNvcnJFcnItIFVuY29yckVyci0gRmF0YWxFcnItIFVuc3VwcFJlcS0g
QXV4UHdyLSBUcmFuc1BlbmQtDQoJCUxua0NhcDoJUG9ydCAjMSwgU3BlZWQgMi41R1Qvcywg
V2lkdGggeDEsIEFTUE0gdW5rbm93biwgTGF0ZW5jeSBMMCA8NjRucywgTDEgdW5saW1pdGVk
DQoJCQlDbG9ja1BNKyBTdXJwcmlzZS0gTExBY3RSZXAtIEJ3Tm90LQ0KCQlMbmtDdGw6CUFT
UE0gRGlzYWJsZWQ7IFJDQiA2NCBieXRlcyBEaXNhYmxlZC0gUmV0cmFpbi0gQ29tbUNsay0N
CgkJCUV4dFN5bmNoLSBDbG9ja1BNLSBBdXRXaWREaXMtIEJXSW50LSBBdXRCV0ludC0NCgkJ
TG5rU3RhOglTcGVlZCAyLjVHVC9zLCBXaWR0aCB4MSwgVHJFcnItIFRyYWluLSBTbG90Q2xr
LSBETEFjdGl2ZS0gQldNZ210LSBBQldNZ210LQ0KCUtlcm5lbCBkcml2ZXIgaW4gdXNlOiBw
Y2liYWNrDQoNCjA5OjAwLjQgVVNCIGNvbnRyb2xsZXIgWzBjMDNdOiBOZXRNb3MgVGVjaG5v
bG9neSBNQ1M5OTkwIFBDSWUgdG8gNOKAkFBvcnQgVVNCIDIuMCBIb3N0IENvbnRyb2xsZXIg
Wzk3MTA6OTk5MF0gKHByb2ctaWYgMTAgW09IQ0ldKQ0KCVN1YnN5c3RlbTogRGV2aWNlIFth
MDAwOjQwMDBdDQoJQ29udHJvbDogSS9PLSBNZW0tIEJ1c01hc3Rlci0gU3BlY0N5Y2xlLSBN
ZW1XSU5WLSBWR0FTbm9vcC0gUGFyRXJyLSBTdGVwcGluZy0gU0VSUi0gRmFzdEIyQi0gRGlz
SU5UeC0NCglTdGF0dXM6IENhcCsgNjZNSHotIFVERi0gRmFzdEIyQi0gUGFyRXJyLSBERVZT
RUw9ZmFzdCA+VEFib3J0LSA8VEFib3J0LSA8TUFib3J0LSA+U0VSUi0gPFBFUlItIElOVHgt
DQoJSW50ZXJydXB0OiBwaW4gQyByb3V0ZWQgdG8gSVJRIDMwDQoJUmVnaW9uIDA6IE1lbW9y
eSBhdCBmOWZmYzAwMCAoMzItYml0LCBub24tcHJlZmV0Y2hhYmxlKSBbZGlzYWJsZWRdIFtz
aXplPTRLXQ0KCUNhcGFiaWxpdGllczogWzUwXSBNU0k6IEVuYWJsZS0gQ291bnQ9MS8xIE1h
c2thYmxlLSA2NGJpdCsNCgkJQWRkcmVzczogMDAwMDAwMDAwMDAwMDAwMCAgRGF0YTogMDAw
MA0KCUNhcGFiaWxpdGllczogWzc4XSBQb3dlciBNYW5hZ2VtZW50IHZlcnNpb24gMw0KCQlG
bGFnczogUE1FQ2xrLSBEU0ktIEQxKyBEMisgQXV4Q3VycmVudD0zNzVtQSBQTUUoRDArLEQx
KyxEMissRDNob3QrLEQzY29sZC0pDQoJCVN0YXR1czogRDAgTm9Tb2Z0UnN0KyBQTUUtRW5h
YmxlLSBEU2VsPTAgRFNjYWxlPTAgUE1FLQ0KCUNhcGFiaWxpdGllczogWzgwXSBFeHByZXNz
ICh2MSkgRW5kcG9pbnQsIE1TSSAwMA0KCQlEZXZDYXA6CU1heFBheWxvYWQgMjU2IGJ5dGVz
LCBQaGFudEZ1bmMgMCwgTGF0ZW5jeSBMMHMgdW5saW1pdGVkLCBMMSB1bmxpbWl0ZWQNCgkJ
CUV4dFRhZy0gQXR0bkJ0bi0gQXR0bkluZC0gUHdySW5kLSBSQkUrIEZMUmVzZXQtDQoJCURl
dkN0bDoJUmVwb3J0IGVycm9yczogQ29ycmVjdGFibGUtIE5vbi1GYXRhbC0gRmF0YWwtIFVu
c3VwcG9ydGVkLQ0KCQkJUmx4ZE9yZC0gRXh0VGFnLSBQaGFudEZ1bmMtIEF1eFB3ci0gTm9T
bm9vcCsNCgkJCU1heFBheWxvYWQgMTI4IGJ5dGVzLCBNYXhSZWFkUmVxIDUxMiBieXRlcw0K
CQlEZXZTdGE6CUNvcnJFcnItIFVuY29yckVyci0gRmF0YWxFcnItIFVuc3VwcFJlcS0gQXV4
UHdyLSBUcmFuc1BlbmQtDQoJCUxua0NhcDoJUG9ydCAjMSwgU3BlZWQgMi41R1QvcywgV2lk
dGggeDEsIEFTUE0gdW5rbm93biwgTGF0ZW5jeSBMMCA8NjRucywgTDEgdW5saW1pdGVkDQoJ
CQlDbG9ja1BNKyBTdXJwcmlzZS0gTExBY3RSZXAtIEJ3Tm90LQ0KCQlMbmtDdGw6CUFTUE0g
RGlzYWJsZWQ7IFJDQiA2NCBieXRlcyBEaXNhYmxlZC0gUmV0cmFpbi0gQ29tbUNsay0NCgkJ
CUV4dFN5bmNoLSBDbG9ja1BNLSBBdXRXaWREaXMtIEJXSW50LSBBdXRCV0ludC0NCgkJTG5r
U3RhOglTcGVlZCAyLjVHVC9zLCBXaWR0aCB4MSwgVHJFcnItIFRyYWluLSBTbG90Q2xrLSBE
TEFjdGl2ZS0gQldNZ210LSBBQldNZ210LQ0KCUtlcm5lbCBkcml2ZXIgaW4gdXNlOiBwY2li
YWNrDQoNCjA5OjAwLjUgVVNCIGNvbnRyb2xsZXIgWzBjMDNdOiBOZXRNb3MgVGVjaG5vbG9n
eSBNQ1M5OTkwIFBDSWUgdG8gNOKAkFBvcnQgVVNCIDIuMCBIb3N0IENvbnRyb2xsZXIgWzk3
MTA6OTk5MF0gKHByb2ctaWYgMjAgW0VIQ0ldKQ0KCVN1YnN5c3RlbTogRGV2aWNlIFthMDAw
OjQwMDBdDQoJQ29udHJvbDogSS9PLSBNZW0tIEJ1c01hc3Rlci0gU3BlY0N5Y2xlLSBNZW1X
SU5WLSBWR0FTbm9vcC0gUGFyRXJyLSBTdGVwcGluZy0gU0VSUi0gRmFzdEIyQi0gRGlzSU5U
eC0NCglTdGF0dXM6IENhcCsgNjZNSHotIFVERi0gRmFzdEIyQi0gUGFyRXJyLSBERVZTRUw9
ZmFzdCA+VEFib3J0LSA8VEFib3J0LSA8TUFib3J0LSA+U0VSUi0gPFBFUlItIElOVHgtDQoJ
SW50ZXJydXB0OiBwaW4gQyByb3V0ZWQgdG8gSVJRIDMwDQoJUmVnaW9uIDA6IE1lbW9yeSBh
dCBmOWZmZDAwMCAoMzItYml0LCBub24tcHJlZmV0Y2hhYmxlKSBbZGlzYWJsZWRdIFtzaXpl
PTRLXQ0KCUNhcGFiaWxpdGllczogWzUwXSBNU0k6IEVuYWJsZS0gQ291bnQ9MS8xIE1hc2th
YmxlLSA2NGJpdCsNCgkJQWRkcmVzczogMDAwMDAwMDAwMDAwMDAwMCAgRGF0YTogMDAwMA0K
CUNhcGFiaWxpdGllczogWzc4XSBQb3dlciBNYW5hZ2VtZW50IHZlcnNpb24gMw0KCQlGbGFn
czogUE1FQ2xrLSBEU0ktIEQxKyBEMisgQXV4Q3VycmVudD0zNzVtQSBQTUUoRDArLEQxKyxE
MissRDNob3QrLEQzY29sZC0pDQoJCVN0YXR1czogRDAgTm9Tb2Z0UnN0KyBQTUUtRW5hYmxl
LSBEU2VsPTAgRFNjYWxlPTAgUE1FLQ0KCUNhcGFiaWxpdGllczogWzgwXSBFeHByZXNzICh2
MSkgRW5kcG9pbnQsIE1TSSAwMA0KCQlEZXZDYXA6CU1heFBheWxvYWQgMjU2IGJ5dGVzLCBQ
aGFudEZ1bmMgMCwgTGF0ZW5jeSBMMHMgdW5saW1pdGVkLCBMMSB1bmxpbWl0ZWQNCgkJCUV4
dFRhZy0gQXR0bkJ0bi0gQXR0bkluZC0gUHdySW5kLSBSQkUrIEZMUmVzZXQtDQoJCURldkN0
bDoJUmVwb3J0IGVycm9yczogQ29ycmVjdGFibGUtIE5vbi1GYXRhbC0gRmF0YWwtIFVuc3Vw
cG9ydGVkLQ0KCQkJUmx4ZE9yZC0gRXh0VGFnLSBQaGFudEZ1bmMtIEF1eFB3ci0gTm9Tbm9v
cCsNCgkJCU1heFBheWxvYWQgMTI4IGJ5dGVzLCBNYXhSZWFkUmVxIDUxMiBieXRlcw0KCQlE
ZXZTdGE6CUNvcnJFcnItIFVuY29yckVyci0gRmF0YWxFcnItIFVuc3VwcFJlcS0gQXV4UHdy
LSBUcmFuc1BlbmQtDQoJCUxua0NhcDoJUG9ydCAjMSwgU3BlZWQgMi41R1QvcywgV2lkdGgg
eDEsIEFTUE0gdW5rbm93biwgTGF0ZW5jeSBMMCA8NjRucywgTDEgdW5saW1pdGVkDQoJCQlD
bG9ja1BNKyBTdXJwcmlzZS0gTExBY3RSZXAtIEJ3Tm90LQ0KCQlMbmtDdGw6CUFTUE0gRGlz
YWJsZWQ7IFJDQiA2NCBieXRlcyBEaXNhYmxlZC0gUmV0cmFpbi0gQ29tbUNsay0NCgkJCUV4
dFN5bmNoLSBDbG9ja1BNLSBBdXRXaWREaXMtIEJXSW50LSBBdXRCV0ludC0NCgkJTG5rU3Rh
OglTcGVlZCAyLjVHVC9zLCBXaWR0aCB4MSwgVHJFcnItIFRyYWluLSBTbG90Q2xrLSBETEFj
dGl2ZS0gQldNZ210LSBBQldNZ210LQ0KCUtlcm5lbCBkcml2ZXIgaW4gdXNlOiBwY2liYWNr
DQoNCjA5OjAwLjYgVVNCIGNvbnRyb2xsZXIgWzBjMDNdOiBOZXRNb3MgVGVjaG5vbG9neSBN
Q1M5OTkwIFBDSWUgdG8gNOKAkFBvcnQgVVNCIDIuMCBIb3N0IENvbnRyb2xsZXIgWzk3MTA6
OTk5MF0gKHByb2ctaWYgMTAgW09IQ0ldKQ0KCVN1YnN5c3RlbTogRGV2aWNlIFthMDAwOjQw
MDBdDQoJQ29udHJvbDogSS9PLSBNZW0tIEJ1c01hc3Rlci0gU3BlY0N5Y2xlLSBNZW1XSU5W
LSBWR0FTbm9vcC0gUGFyRXJyLSBTdGVwcGluZy0gU0VSUi0gRmFzdEIyQi0gRGlzSU5UeC0N
CglTdGF0dXM6IENhcCsgNjZNSHotIFVERi0gRmFzdEIyQi0gUGFyRXJyLSBERVZTRUw9ZmFz
dCA+VEFib3J0LSA8VEFib3J0LSA8TUFib3J0LSA+U0VSUi0gPFBFUlItIElOVHgtDQoJSW50
ZXJydXB0OiBwaW4gRCByb3V0ZWQgdG8gSVJRIDMxDQoJUmVnaW9uIDA6IE1lbW9yeSBhdCBm
OWZmZTAwMCAoMzItYml0LCBub24tcHJlZmV0Y2hhYmxlKSBbZGlzYWJsZWRdIFtzaXplPTRL
XQ0KCUNhcGFiaWxpdGllczogWzUwXSBNU0k6IEVuYWJsZS0gQ291bnQ9MS8xIE1hc2thYmxl
LSA2NGJpdCsNCgkJQWRkcmVzczogMDAwMDAwMDAwMDAwMDAwMCAgRGF0YTogMDAwMA0KCUNh
cGFiaWxpdGllczogWzc4XSBQb3dlciBNYW5hZ2VtZW50IHZlcnNpb24gMw0KCQlGbGFnczog
UE1FQ2xrLSBEU0ktIEQxKyBEMisgQXV4Q3VycmVudD0zNzVtQSBQTUUoRDArLEQxKyxEMiss
RDNob3QrLEQzY29sZC0pDQoJCVN0YXR1czogRDAgTm9Tb2Z0UnN0KyBQTUUtRW5hYmxlLSBE
U2VsPTAgRFNjYWxlPTAgUE1FLQ0KCUNhcGFiaWxpdGllczogWzgwXSBFeHByZXNzICh2MSkg
RW5kcG9pbnQsIE1TSSAwMA0KCQlEZXZDYXA6CU1heFBheWxvYWQgMjU2IGJ5dGVzLCBQaGFu
dEZ1bmMgMCwgTGF0ZW5jeSBMMHMgdW5saW1pdGVkLCBMMSB1bmxpbWl0ZWQNCgkJCUV4dFRh
Zy0gQXR0bkJ0bi0gQXR0bkluZC0gUHdySW5kLSBSQkUrIEZMUmVzZXQtDQoJCURldkN0bDoJ
UmVwb3J0IGVycm9yczogQ29ycmVjdGFibGUtIE5vbi1GYXRhbC0gRmF0YWwtIFVuc3VwcG9y
dGVkLQ0KCQkJUmx4ZE9yZC0gRXh0VGFnLSBQaGFudEZ1bmMtIEF1eFB3ci0gTm9Tbm9vcCsN
CgkJCU1heFBheWxvYWQgMTI4IGJ5dGVzLCBNYXhSZWFkUmVxIDUxMiBieXRlcw0KCQlEZXZT
dGE6CUNvcnJFcnItIFVuY29yckVyci0gRmF0YWxFcnItIFVuc3VwcFJlcS0gQXV4UHdyLSBU
cmFuc1BlbmQtDQoJCUxua0NhcDoJUG9ydCAjMSwgU3BlZWQgMi41R1QvcywgV2lkdGggeDEs
IEFTUE0gdW5rbm93biwgTGF0ZW5jeSBMMCA8NjRucywgTDEgdW5saW1pdGVkDQoJCQlDbG9j
a1BNKyBTdXJwcmlzZS0gTExBY3RSZXAtIEJ3Tm90LQ0KCQlMbmtDdGw6CUFTUE0gRGlzYWJs
ZWQ7IFJDQiA2NCBieXRlcyBEaXNhYmxlZC0gUmV0cmFpbi0gQ29tbUNsay0NCgkJCUV4dFN5
bmNoLSBDbG9ja1BNLSBBdXRXaWREaXMtIEJXSW50LSBBdXRCV0ludC0NCgkJTG5rU3RhOglT
cGVlZCAyLjVHVC9zLCBXaWR0aCB4MSwgVHJFcnItIFRyYWluLSBTbG90Q2xrLSBETEFjdGl2
ZS0gQldNZ210LSBBQldNZ210LQ0KCUtlcm5lbCBkcml2ZXIgaW4gdXNlOiBwY2liYWNrDQoN
CjA5OjAwLjcgVVNCIGNvbnRyb2xsZXIgWzBjMDNdOiBOZXRNb3MgVGVjaG5vbG9neSBNQ1M5
OTkwIFBDSWUgdG8gNOKAkFBvcnQgVVNCIDIuMCBIb3N0IENvbnRyb2xsZXIgWzk3MTA6OTk5
MF0gKHByb2ctaWYgMjAgW0VIQ0ldKQ0KCVN1YnN5c3RlbTogRGV2aWNlIFthMDAwOjQwMDBd
DQoJQ29udHJvbDogSS9PLSBNZW0tIEJ1c01hc3Rlci0gU3BlY0N5Y2xlLSBNZW1XSU5WLSBW
R0FTbm9vcC0gUGFyRXJyLSBTdGVwcGluZy0gU0VSUi0gRmFzdEIyQi0gRGlzSU5UeC0NCglT
dGF0dXM6IENhcCsgNjZNSHotIFVERi0gRmFzdEIyQi0gUGFyRXJyLSBERVZTRUw9ZmFzdCA+
VEFib3J0LSA8VEFib3J0LSA8TUFib3J0LSA+U0VSUi0gPFBFUlItIElOVHgtDQoJSW50ZXJy
dXB0OiBwaW4gRCByb3V0ZWQgdG8gSVJRIDMxDQoJUmVnaW9uIDA6IE1lbW9yeSBhdCBmOWZm
ZjAwMCAoMzItYml0LCBub24tcHJlZmV0Y2hhYmxlKSBbZGlzYWJsZWRdIFtzaXplPTRLXQ0K
CUNhcGFiaWxpdGllczogWzUwXSBNU0k6IEVuYWJsZS0gQ291bnQ9MS8xIE1hc2thYmxlLSA2
NGJpdCsNCgkJQWRkcmVzczogMDAwMDAwMDAwMDAwMDAwMCAgRGF0YTogMDAwMA0KCUNhcGFi
aWxpdGllczogWzc4XSBQb3dlciBNYW5hZ2VtZW50IHZlcnNpb24gMw0KCQlGbGFnczogUE1F
Q2xrLSBEU0ktIEQxKyBEMisgQXV4Q3VycmVudD0zNzVtQSBQTUUoRDArLEQxKyxEMissRDNo
b3QrLEQzY29sZC0pDQoJCVN0YXR1czogRDAgTm9Tb2Z0UnN0KyBQTUUtRW5hYmxlLSBEU2Vs
PTAgRFNjYWxlPTAgUE1FLQ0KCUNhcGFiaWxpdGllczogWzgwXSBFeHByZXNzICh2MSkgRW5k
cG9pbnQsIE1TSSAwMA0KCQlEZXZDYXA6CU1heFBheWxvYWQgMjU2IGJ5dGVzLCBQaGFudEZ1
bmMgMCwgTGF0ZW5jeSBMMHMgdW5saW1pdGVkLCBMMSB1bmxpbWl0ZWQNCgkJCUV4dFRhZy0g
QXR0bkJ0bi0gQXR0bkluZC0gUHdySW5kLSBSQkUrIEZMUmVzZXQtDQoJCURldkN0bDoJUmVw
b3J0IGVycm9yczogQ29ycmVjdGFibGUtIE5vbi1GYXRhbC0gRmF0YWwtIFVuc3VwcG9ydGVk
LQ0KCQkJUmx4ZE9yZC0gRXh0VGFnLSBQaGFudEZ1bmMtIEF1eFB3ci0gTm9Tbm9vcCsNCgkJ
CU1heFBheWxvYWQgMTI4IGJ5dGVzLCBNYXhSZWFkUmVxIDUxMiBieXRlcw0KCQlEZXZTdGE6
CUNvcnJFcnItIFVuY29yckVyci0gRmF0YWxFcnItIFVuc3VwcFJlcS0gQXV4UHdyLSBUcmFu
c1BlbmQtDQoJCUxua0NhcDoJUG9ydCAjMSwgU3BlZWQgMi41R1QvcywgV2lkdGggeDEsIEFT
UE0gdW5rbm93biwgTGF0ZW5jeSBMMCA8NjRucywgTDEgdW5saW1pdGVkDQoJCQlDbG9ja1BN
KyBTdXJwcmlzZS0gTExBY3RSZXAtIEJ3Tm90LQ0KCQlMbmtDdGw6CUFTUE0gRGlzYWJsZWQ7
IFJDQiA2NCBieXRlcyBEaXNhYmxlZC0gUmV0cmFpbi0gQ29tbUNsay0NCgkJCUV4dFN5bmNo
LSBDbG9ja1BNLSBBdXRXaWREaXMtIEJXSW50LSBBdXRCV0ludC0NCgkJTG5rU3RhOglTcGVl
ZCAyLjVHVC9zLCBXaWR0aCB4MSwgVHJFcnItIFRyYWluLSBTbG90Q2xrLSBETEFjdGl2ZS0g
QldNZ210LSBBQldNZ210LQ0KCUtlcm5lbCBkcml2ZXIgaW4gdXNlOiBwY2liYWNrDQoNCjBh
OjAwLjAgVkdBIGNvbXBhdGlibGUgY29udHJvbGxlciBbMDMwMF06IG5WaWRpYSBDb3Jwb3Jh
dGlvbiBHOTggW0dlRm9yY2UgODQwMCBHU10gWzEwZGU6MDZlNF0gKHJldiBhMSkgKHByb2ct
aWYgMDAgW1ZHQSBjb250cm9sbGVyXSkNCglTdWJzeXN0ZW06IEFTVVNUZUsgQ29tcHV0ZXIg
SW5jLiBEZXZpY2UgWzEwNDM6ODI2Nl0NCglDb250cm9sOiBJL08rIE1lbSsgQnVzTWFzdGVy
KyBTcGVjQ3ljbGUtIE1lbVdJTlYtIFZHQVNub29wLSBQYXJFcnItIFN0ZXBwaW5nLSBTRVJS
KyBGYXN0QjJCLSBEaXNJTlR4LQ0KCVN0YXR1czogQ2FwKyA2Nk1Iei0gVURGLSBGYXN0QjJC
LSBQYXJFcnItIERFVlNFTD1mYXN0ID5UQWJvcnQtIDxUQWJvcnQtIDxNQWJvcnQtID5TRVJS
LSA8UEVSUi0gSU5UeC0NCglMYXRlbmN5OiAwLCBDYWNoZSBMaW5lIFNpemU6IDY0IGJ5dGVz
DQoJSW50ZXJydXB0OiBwaW4gQSByb3V0ZWQgdG8gSVJRIDEwDQoJUmVnaW9uIDA6IE1lbW9y
eSBhdCBmZDAwMDAwMCAoMzItYml0LCBub24tcHJlZmV0Y2hhYmxlKSBbc2l6ZT0xNk1dDQoJ
UmVnaW9uIDE6IE1lbW9yeSBhdCBkMDAwMDAwMCAoNjQtYml0LCBwcmVmZXRjaGFibGUpIFtz
aXplPTI1Nk1dDQoJUmVnaW9uIDM6IE1lbW9yeSBhdCBmYTAwMDAwMCAoNjQtYml0LCBub24t
cHJlZmV0Y2hhYmxlKSBbc2l6ZT0zMk1dDQoJUmVnaW9uIDU6IEkvTyBwb3J0cyBhdCBlODAw
IFtzaXplPTEyOF0NCglFeHBhbnNpb24gUk9NIGF0IGZlOWUwMDAwIFtkaXNhYmxlZF0gW3Np
emU9MTI4S10NCglDYXBhYmlsaXRpZXM6IFs2MF0gUG93ZXIgTWFuYWdlbWVudCB2ZXJzaW9u
IDMNCgkJRmxhZ3M6IFBNRUNsay0gRFNJLSBEMS0gRDItIEF1eEN1cnJlbnQ9MG1BIFBNRShE
MC0sRDEtLEQyLSxEM2hvdC0sRDNjb2xkLSkNCgkJU3RhdHVzOiBEMCBOb1NvZnRSc3QrIFBN
RS1FbmFibGUtIERTZWw9MCBEU2NhbGU9MCBQTUUtDQoJQ2FwYWJpbGl0aWVzOiBbNjhdIE1T
STogRW5hYmxlLSBDb3VudD0xLzEgTWFza2FibGUtIDY0Yml0Kw0KCQlBZGRyZXNzOiAwMDAw
MDAwMDAwMDAwMDAwICBEYXRhOiAwMDAwDQoJQ2FwYWJpbGl0aWVzOiBbNzhdIEV4cHJlc3Mg
KHYxKSBFbmRwb2ludCwgTVNJIDAwDQoJCURldkNhcDoJTWF4UGF5bG9hZCAxMjggYnl0ZXMs
IFBoYW50RnVuYyAwLCBMYXRlbmN5IEwwcyA8NTEybnMsIEwxIDw0dXMNCgkJCUV4dFRhZysg
QXR0bkJ0bi0gQXR0bkluZC0gUHdySW5kLSBSQkUrIEZMUmVzZXQtDQoJCURldkN0bDoJUmVw
b3J0IGVycm9yczogQ29ycmVjdGFibGUtIE5vbi1GYXRhbC0gRmF0YWwtIFVuc3VwcG9ydGVk
LQ0KCQkJUmx4ZE9yZC0gRXh0VGFnLSBQaGFudEZ1bmMtIEF1eFB3ci0gTm9Tbm9vcCsNCgkJ
CU1heFBheWxvYWQgMTI4IGJ5dGVzLCBNYXhSZWFkUmVxIDUxMiBieXRlcw0KCQlEZXZTdGE6
CUNvcnJFcnItIFVuY29yckVyci0gRmF0YWxFcnItIFVuc3VwcFJlcS0gQXV4UHdyLSBUcmFu
c1BlbmQtDQoJCUxua0NhcDoJUG9ydCAjMCwgU3BlZWQgMi41R1QvcywgV2lkdGggeDE2LCBB
U1BNIEwwcyBMMSwgTGF0ZW5jeSBMMCA8NTEybnMsIEwxIDwxdXMNCgkJCUNsb2NrUE0tIFN1
cnByaXNlLSBMTEFjdFJlcC0gQndOb3QtDQoJCUxua0N0bDoJQVNQTSBEaXNhYmxlZDsgUkNC
IDEyOCBieXRlcyBEaXNhYmxlZC0gUmV0cmFpbi0gQ29tbUNsaysNCgkJCUV4dFN5bmNoLSBD
bG9ja1BNLSBBdXRXaWREaXMtIEJXSW50LSBBdXRCV0ludC0NCgkJTG5rU3RhOglTcGVlZCAy
LjVHVC9zLCBXaWR0aCB4OCwgVHJFcnItIFRyYWluLSBTbG90Q2xrKyBETEFjdGl2ZS0gQldN
Z210LSBBQldNZ210LQ0KCUNhcGFiaWxpdGllczogWzEwMCB2MV0gVmlydHVhbCBDaGFubmVs
DQoJCUNhcHM6CUxQRVZDPTAgUmVmQ2xrPTEwMG5zIFBBVEVudHJ5Qml0cz0xDQoJCUFyYjoJ
Rml4ZWQtIFdSUjMyLSBXUlI2NC0gV1JSMTI4LQ0KCQlDdHJsOglBcmJTZWxlY3Q9Rml4ZWQN
CgkJU3RhdHVzOglJblByb2dyZXNzLQ0KCQlWQzA6CUNhcHM6CVBBVE9mZnNldD0wMCBNYXhU
aW1lU2xvdHM9MSBSZWpTbm9vcFRyYW5zLQ0KCQkJQXJiOglGaXhlZC0gV1JSMzItIFdSUjY0
LSBXUlIxMjgtIFRXUlIxMjgtIFdSUjI1Ni0NCgkJCUN0cmw6CUVuYWJsZSsgSUQ9MCBBcmJT
ZWxlY3Q9Rml4ZWQgVEMvVkM9ZmYNCgkJCVN0YXR1czoJTmVnb1BlbmRpbmctIEluUHJvZ3Jl
c3MtDQoJQ2FwYWJpbGl0aWVzOiBbMTI4IHYxXSBQb3dlciBCdWRnZXRpbmcgPD8+DQoJQ2Fw
YWJpbGl0aWVzOiBbNjAwIHYxXSBWZW5kb3IgU3BlY2lmaWMgSW5mb3JtYXRpb246IElEPTAw
MDEgUmV2PTEgTGVuPTAyNCA8Pz4NCg0K
------------0E41640F726FFA493
Content-Type: text/plain;
 name="lspci-hvm.txt"
Content-transfer-encoding: base64
Content-Disposition: attachment;
 filename="lspci-hvm.txt"

MDA6MDAuMCBIb3N0IGJyaWRnZSBbMDYwMF06IEludGVsIENvcnBvcmF0aW9uIDQ0MEZYIC0g
ODI0NDFGWCBQTUMgW05hdG9tYV0gWzgwODY6MTIzN10gKHJldiAwMikNCglTdWJzeXN0ZW06
IFJlZCBIYXQsIEluYyBRZW11IHZpcnR1YWwgbWFjaGluZSBbMWFmNDoxMTAwXQ0KCVBoeXNp
Y2FsIFNsb3Q6IDANCglDb250cm9sOiBJL08tIE1lbS0gQnVzTWFzdGVyKyBTcGVjQ3ljbGUt
IE1lbVdJTlYtIFZHQVNub29wLSBQYXJFcnItIFN0ZXBwaW5nLSBTRVJSLSBGYXN0QjJCLSBE
aXNJTlR4LQ0KCVN0YXR1czogQ2FwLSA2Nk1Iei0gVURGLSBGYXN0QjJCLSBQYXJFcnItIERF
VlNFTD1mYXN0ID5UQWJvcnQtIDxUQWJvcnQtIDxNQWJvcnQtID5TRVJSLSA8UEVSUi0gSU5U
eC0NCglMYXRlbmN5OiAwDQoNCjAwOjAxLjAgSVNBIGJyaWRnZSBbMDYwMV06IEludGVsIENv
cnBvcmF0aW9uIDgyMzcxU0IgUElJWDMgSVNBIFtOYXRvbWEvVHJpdG9uIElJXSBbODA4Njo3
MDAwXQ0KCVN1YnN5c3RlbTogUmVkIEhhdCwgSW5jIFFlbXUgdmlydHVhbCBtYWNoaW5lIFsx
YWY0OjExMDBdDQoJUGh5c2ljYWwgU2xvdDogMQ0KCUNvbnRyb2w6IEkvTysgTWVtKyBCdXNN
YXN0ZXIrIFNwZWNDeWNsZS0gTWVtV0lOVi0gVkdBU25vb3AtIFBhckVyci0gU3RlcHBpbmct
IFNFUlItIEZhc3RCMkItIERpc0lOVHgtDQoJU3RhdHVzOiBDYXAtIDY2TUh6LSBVREYtIEZh
c3RCMkItIFBhckVyci0gREVWU0VMPW1lZGl1bSA+VEFib3J0LSA8VEFib3J0LSA8TUFib3J0
LSA+U0VSUi0gPFBFUlItIElOVHgtDQoJTGF0ZW5jeTogMA0KDQowMDowMS4xIElERSBpbnRl
cmZhY2UgWzAxMDFdOiBJbnRlbCBDb3Jwb3JhdGlvbiA4MjM3MVNCIFBJSVgzIElERSBbTmF0
b21hL1RyaXRvbiBJSV0gWzgwODY6NzAxMF0gKHByb2ctaWYgODAgW01hc3Rlcl0pDQoJU3Vi
c3lzdGVtOiBYZW5Tb3VyY2UsIEluYy4gRGV2aWNlIFs1ODUzOjAwMDFdDQoJUGh5c2ljYWwg
U2xvdDogMQ0KCUNvbnRyb2w6IEkvTysgTWVtLSBCdXNNYXN0ZXIrIFNwZWNDeWNsZS0gTWVt
V0lOVi0gVkdBU25vb3AtIFBhckVyci0gU3RlcHBpbmctIFNFUlItIEZhc3RCMkItIERpc0lO
VHgtDQoJU3RhdHVzOiBDYXAtIDY2TUh6LSBVREYtIEZhc3RCMkIrIFBhckVyci0gREVWU0VM
PW1lZGl1bSA+VEFib3J0LSA8VEFib3J0LSA8TUFib3J0LSA+U0VSUi0gPFBFUlItIElOVHgt
DQoJTGF0ZW5jeTogMA0KCVJlZ2lvbiAwOiBbdmlydHVhbF0gTWVtb3J5IGF0IDAwMDAwMWYw
ICgzMi1iaXQsIG5vbi1wcmVmZXRjaGFibGUpIFtzaXplPThdDQoJUmVnaW9uIDE6IFt2aXJ0
dWFsXSBNZW1vcnkgYXQgMDAwMDAzZjAgKHR5cGUgMywgbm9uLXByZWZldGNoYWJsZSkgW3Np
emU9MV0NCglSZWdpb24gMjogW3ZpcnR1YWxdIE1lbW9yeSBhdCAwMDAwMDE3MCAoMzItYml0
LCBub24tcHJlZmV0Y2hhYmxlKSBbc2l6ZT04XQ0KCVJlZ2lvbiAzOiBbdmlydHVhbF0gTWVt
b3J5IGF0IDAwMDAwMzcwICh0eXBlIDMsIG5vbi1wcmVmZXRjaGFibGUpIFtzaXplPTFdDQoJ
UmVnaW9uIDQ6IEkvTyBwb3J0cyBhdCBjMTYwIFtzaXplPTE2XQ0KDQowMDowMS4yIFVTQiBj
b250cm9sbGVyIFswYzAzXTogSW50ZWwgQ29ycG9yYXRpb24gODIzNzFTQiBQSUlYMyBVU0Ig
W05hdG9tYS9Ucml0b24gSUldIFs4MDg2OjcwMjBdIChyZXYgMDEpIChwcm9nLWlmIDAwIFtV
SENJXSkNCglTdWJzeXN0ZW06IFJlZCBIYXQsIEluYyBRZW11IHZpcnR1YWwgbWFjaGluZSBb
MWFmNDoxMTAwXQ0KCVBoeXNpY2FsIFNsb3Q6IDENCglDb250cm9sOiBJL08rIE1lbS0gQnVz
TWFzdGVyKyBTcGVjQ3ljbGUtIE1lbVdJTlYtIFZHQVNub29wLSBQYXJFcnItIFN0ZXBwaW5n
LSBTRVJSLSBGYXN0QjJCLSBEaXNJTlR4LQ0KCVN0YXR1czogQ2FwLSA2Nk1Iei0gVURGLSBG
YXN0QjJCLSBQYXJFcnItIERFVlNFTD1mYXN0ID5UQWJvcnQtIDxUQWJvcnQtIDxNQWJvcnQt
ID5TRVJSLSA8UEVSUi0gSU5UeC0NCglMYXRlbmN5OiA2NA0KCUludGVycnVwdDogcGluIEQg
cm91dGVkIHRvIElSUSAyMw0KCVJlZ2lvbiA0OiBJL08gcG9ydHMgYXQgYzE0MCBbc2l6ZT0z
Ml0NCglLZXJuZWwgZHJpdmVyIGluIHVzZTogdWhjaV9oY2QNCg0KMDA6MDEuMyBCcmlkZ2Ug
WzA2ODBdOiBJbnRlbCBDb3Jwb3JhdGlvbiA4MjM3MUFCL0VCL01CIFBJSVg0IEFDUEkgWzgw
ODY6NzExM10gKHJldiAwMSkNCglTdWJzeXN0ZW06IFJlZCBIYXQsIEluYyBRZW11IHZpcnR1
YWwgbWFjaGluZSBbMWFmNDoxMTAwXQ0KCVBoeXNpY2FsIFNsb3Q6IDENCglDb250cm9sOiBJ
L08tIE1lbS0gQnVzTWFzdGVyKyBTcGVjQ3ljbGUtIE1lbVdJTlYtIFZHQVNub29wLSBQYXJF
cnItIFN0ZXBwaW5nLSBTRVJSLSBGYXN0QjJCLSBEaXNJTlR4LQ0KCVN0YXR1czogQ2FwLSA2
Nk1Iei0gVURGLSBGYXN0QjJCLSBQYXJFcnItIERFVlNFTD1mYXN0ID5UQWJvcnQtIDxUQWJv
cnQtIDxNQWJvcnQtID5TRVJSLSA8UEVSUi0gSU5UeC0NCglMYXRlbmN5OiAwDQoJSW50ZXJy
dXB0OiBwaW4gQSByb3V0ZWQgdG8gSVJRIDkNCg0KMDA6MDIuMCBWR0EgY29tcGF0aWJsZSBj
b250cm9sbGVyIFswMzAwXTogQ2lycnVzIExvZ2ljIEdEIDU0NDYgWzEwMTM6MDBiOF0gKHBy
b2ctaWYgMDAgW1ZHQSBjb250cm9sbGVyXSkNCglTdWJzeXN0ZW06IFhlblNvdXJjZSwgSW5j
LiBEZXZpY2UgWzU4NTM6MDAwMV0NCglQaHlzaWNhbCBTbG90OiAyDQoJQ29udHJvbDogSS9P
KyBNZW0rIEJ1c01hc3RlcisgU3BlY0N5Y2xlLSBNZW1XSU5WLSBWR0FTbm9vcC0gUGFyRXJy
LSBTdGVwcGluZy0gU0VSUi0gRmFzdEIyQi0gRGlzSU5UeC0NCglTdGF0dXM6IENhcC0gNjZN
SHotIFVERi0gRmFzdEIyQi0gUGFyRXJyLSBERVZTRUw9ZmFzdCA+VEFib3J0LSA8VEFib3J0
LSA8TUFib3J0LSA+U0VSUi0gPFBFUlItIElOVHgtDQoJTGF0ZW5jeTogMA0KCVJlZ2lvbiAw
OiBNZW1vcnkgYXQgZjAwMDAwMDAgKDMyLWJpdCwgcHJlZmV0Y2hhYmxlKSBbc2l6ZT0zMk1d
DQoJUmVnaW9uIDE6IE1lbW9yeSBhdCBmMzIyMDAwMCAoMzItYml0LCBub24tcHJlZmV0Y2hh
YmxlKSBbc2l6ZT00S10NCglFeHBhbnNpb24gUk9NIGF0IDx1bmFzc2lnbmVkPiBbZGlzYWJs
ZWRdDQoNCjAwOjAzLjAgVW5hc3NpZ25lZCBjbGFzcyBbZmY4MF06IFhlblNvdXJjZSwgSW5j
LiBYZW4gUGxhdGZvcm0gRGV2aWNlIFs1ODUzOjAwMDFdIChyZXYgMDEpDQoJU3Vic3lzdGVt
OiBYZW5Tb3VyY2UsIEluYy4gWGVuIFBsYXRmb3JtIERldmljZSBbNTg1MzowMDAxXQ0KCVBo
eXNpY2FsIFNsb3Q6IDMNCglDb250cm9sOiBJL08rIE1lbSsgQnVzTWFzdGVyKyBTcGVjQ3lj
bGUtIE1lbVdJTlYtIFZHQVNub29wLSBQYXJFcnItIFN0ZXBwaW5nLSBTRVJSLSBGYXN0QjJC
LSBEaXNJTlR4LQ0KCVN0YXR1czogQ2FwLSA2Nk1Iei0gVURGLSBGYXN0QjJCLSBQYXJFcnIt
IERFVlNFTD1mYXN0ID5UQWJvcnQtIDxUQWJvcnQtIDxNQWJvcnQtID5TRVJSLSA8UEVSUi0g
SU5UeC0NCglMYXRlbmN5OiAwDQoJSW50ZXJydXB0OiBwaW4gQSByb3V0ZWQgdG8gSVJRIDI4
DQoJUmVnaW9uIDA6IEkvTyBwb3J0cyBhdCBjMDAwIFtzaXplPTI1Nl0NCglSZWdpb24gMTog
TWVtb3J5IGF0IGYyMDAwMDAwICgzMi1iaXQsIHByZWZldGNoYWJsZSkgW3NpemU9MTZNXQ0K
CUtlcm5lbCBkcml2ZXIgaW4gdXNlOiB4ZW4tcGxhdGZvcm0tcGNpDQoNCjAwOjA1LjAgTXVs
dGltZWRpYSB2aWRlbyBjb250cm9sbGVyIFswNDAwXTogQ29uZXhhbnQgU3lzdGVtcywgSW5j
LiBEZXZpY2UgWzE0ZjE6ODIxMF0NCglQaHlzaWNhbCBTbG90OiA1DQoJQ29udHJvbDogSS9P
LSBNZW0rIEJ1c01hc3RlcisgU3BlY0N5Y2xlLSBNZW1XSU5WLSBWR0FTbm9vcC0gUGFyRXJy
LSBTdGVwcGluZy0gU0VSUi0gRmFzdEIyQi0gRGlzSU5UeC0NCglTdGF0dXM6IENhcCsgNjZN
SHotIFVERi0gRmFzdEIyQi0gUGFyRXJyLSBERVZTRUw9ZmFzdCA+VEFib3J0LSA8VEFib3J0
LSA8TUFib3J0LSA+U0VSUi0gPFBFUlItIElOVHgtDQoJTGF0ZW5jeTogMA0KCUludGVycnVw
dDogcGluIEEgcm91dGVkIHRvIElSUSAzNg0KCVJlZ2lvbiAwOiBNZW1vcnkgYXQgZjMwMDAw
MDAgKDY0LWJpdCwgbm9uLXByZWZldGNoYWJsZSkgW3NpemU9Mk1dDQoJQ2FwYWJpbGl0aWVz
OiBbNDBdIEV4cHJlc3MgKHYxKSBFbmRwb2ludCwgTVNJIDAwDQoJCURldkNhcDoJTWF4UGF5
bG9hZCAxMjggYnl0ZXMsIFBoYW50RnVuYyAwLCBMYXRlbmN5IEwwcyA8NjRucywgTDEgPDF1
cw0KCQkJRXh0VGFnLSBBdHRuQnRuLSBBdHRuSW5kLSBQd3JJbmQtIFJCRSsgRkxSZXNldC0N
CgkJRGV2Q3RsOglSZXBvcnQgZXJyb3JzOiBDb3JyZWN0YWJsZS0gTm9uLUZhdGFsLSBGYXRh
bC0gVW5zdXBwb3J0ZWQtDQoJCQlSbHhkT3JkKyBFeHRUYWctIFBoYW50RnVuYy0gQXV4UHdy
LSBOb1Nub29wKw0KCQkJTWF4UGF5bG9hZCAxMjggYnl0ZXMsIE1heFJlYWRSZXEgNTEyIGJ5
dGVzDQoJCURldlN0YToJQ29yckVycisgVW5jb3JyRXJyKyBGYXRhbEVyci0gVW5zdXBwUmVx
KyBBdXhQd3ItIFRyYW5zUGVuZC0NCgkJTG5rQ2FwOglQb3J0ICMwLCBTcGVlZCAyLjVHVC9z
LCBXaWR0aCB4MSwgQVNQTSBMMHMgTDEsIExhdGVuY3kgTDAgPDJ1cywgTDEgPDR1cw0KCQkJ
Q2xvY2tQTS0gU3VycHJpc2UtIExMQWN0UmVwLSBCd05vdC0NCgkJTG5rQ3RsOglBU1BNIERp
c2FibGVkOyBSQ0IgNjQgYnl0ZXMgRGlzYWJsZWQtIFJldHJhaW4tIENvbW1DbGstDQoJCQlF
eHRTeW5jaC0gQ2xvY2tQTS0gQXV0V2lkRGlzLSBCV0ludC0gQXV0QldJbnQtDQoJCUxua1N0
YToJU3BlZWQgMi41R1QvcywgV2lkdGggeDEsIFRyRXJyLSBUcmFpbi0gU2xvdENsay0gRExB
Y3RpdmUtIEJXTWdtdC0gQUJXTWdtdC0NCglDYXBhYmlsaXRpZXM6IFs4MF0gUG93ZXIgTWFu
YWdlbWVudCB2ZXJzaW9uIDMNCgkJRmxhZ3M6IFBNRUNsay0gRFNJKyBEMSsgRDIrIEF1eEN1
cnJlbnQ9MG1BIFBNRShEMC0sRDEtLEQyLSxEM2hvdC0sRDNjb2xkLSkNCgkJU3RhdHVzOiBE
MCBOb1NvZnRSc3QrIFBNRS1FbmFibGUtIERTZWw9MCBEU2NhbGU9MCBQTUUtDQoJQ2FwYWJp
bGl0aWVzOiBbOTBdIFZpdGFsIFByb2R1Y3QgRGF0YQ0KCQlVbmtub3duIHNtYWxsIHJlc291
cmNlIHR5cGUgMDAsIHdpbGwgbm90IGRlY29kZSBtb3JlLg0KCUNhcGFiaWxpdGllczogW2Ew
XSBNU0k6IEVuYWJsZS0gQ291bnQ9MS8xIE1hc2thYmxlLSA2NGJpdCsNCgkJQWRkcmVzczog
MDAwMDAwMDAwMDAwMDAwMCAgRGF0YTogMDAwMA0KCUNhcGFiaWxpdGllczogWzEwMCB2MF0g
IzE0ZjENCglLZXJuZWwgZHJpdmVyIGluIHVzZTogY3gyNTgyMQ0KDQo=
------------0E41640F726FFA493
Content-Type: application/octet-stream;
 name="patch.diff"
Content-transfer-encoding: base64
Content-Disposition: attachment;
 filename="patch.diff"

ZGlmZiAtciBkMzY0YmVjZmIwODMgeGVuL2RyaXZlcnMvcGFzc3Rocm91Z2gvYW1kL2lvbW11
X21hcC5jCi0tLSBhL3hlbi9kcml2ZXJzL3Bhc3N0aHJvdWdoL2FtZC9pb21tdV9tYXAuYwlU
aHUgU2VwIDIwIDEzOjMxOjE5IDIwMTIgKzAyMDAKKysrIGIveGVuL2RyaXZlcnMvcGFzc3Ro
cm91Z2gvYW1kL2lvbW11X21hcC5jCU1vbiBTZXAgMjQgMTA6MzU6MTUgMjAxMiArMDIwMApA
QCAtNzk1LDcgKzc5NSw4IEBACiAKICAgICAgICAgLyogV2hlbiBzaGFyaW5nIHAybSB3aXRo
IGlvbW11LCBwYWdpbmcgbW9kZSA9IDQgKi8KICAgICAgICAgaGQtPnBhZ2luZ19tb2RlID0g
SU9NTVVfUEFHSU5HX01PREVfTEVWRUxfNDsKLSAgICAgICAgQU1EX0lPTU1VX0RFQlVHKCJT
aGFyZSBwMm0gdGFibGUgd2l0aCBpb21tdTogcDJtIHRhYmxlID0gMHglbHhcbiIsCisgICAg
ICAgIEFNRF9JT01NVV9ERUJVRygiU2hhcmUgcDJtIHRhYmxlIHdpdGggaW9tbXU6IGRvbWFp
bjolZCBwMm0gdGFibGUgPSAweCVseFxuIiwKKyAgICAgICAgICAgICAgICAgICAgICAgIGQt
PmRvbWFpbl9pZCwKICAgICAgICAgICAgICAgICAgICAgICAgIG1mbl94KHBnZF9tZm4pKTsK
ICAgICB9CiB9CmRpZmYgLXIgZDM2NGJlY2ZiMDgzIHhlbi9kcml2ZXJzL3Bhc3N0aHJvdWdo
L2FtZC9wY2lfYW1kX2lvbW11LmMKLS0tIGEveGVuL2RyaXZlcnMvcGFzc3Rocm91Z2gvYW1k
L3BjaV9hbWRfaW9tbXUuYwlUaHUgU2VwIDIwIDEzOjMxOjE5IDIwMTIgKzAyMDAKKysrIGIv
eGVuL2RyaXZlcnMvcGFzc3Rocm91Z2gvYW1kL3BjaV9hbWRfaW9tbXUuYwlNb24gU2VwIDI0
IDEwOjM1OjE1IDIwMTIgKzAyMDAKQEAgLTg3LDEwICs4NywxMSBAQAogewogICAgIHZvaWQg
KmR0ZTsKICAgICB1bnNpZ25lZCBsb25nIGZsYWdzOwotICAgIGludCByZXFfaWQsIHZhbGlk
ID0gMTsKKyAgICBpbnQgcmVxX2lkLCByZXFhX2lkLHZhbGlkID0gMTsKICAgICBpbnQgZHRl
X2kgPSAwOwogICAgIHU4IGJ1cyA9IFBDSV9CVVMoYmRmKTsKICAgICB1OCBkZXZmbiA9IFBD
SV9ERVZGTjIoYmRmKTsKKyAgICBzdHJ1Y3QgaXZyc19tYXBwaW5ncyAqaXZyc19tYXBwaW5n
czsKIAogICAgIHN0cnVjdCBodm1faW9tbXUgKmhkID0gZG9tYWluX2h2bV9pb21tdShkb21h
aW4pOwogCkBAIC0xMjAsMTIgKzEyMSwxOCBAQAogICAgICAgICAgICAgaW9tbXVfZHRlX3Nl
dF9pb3RsYigodTMyICopZHRlLCBkdGVfaSk7CiAKICAgICAgICAgYW1kX2lvbW11X2ZsdXNo
X2RldmljZShpb21tdSwgcmVxX2lkKTsKLQorICAgIGl2cnNfbWFwcGluZ3MgPSBnZXRfaXZy
c19tYXBwaW5ncyhpb21tdS0+c2VnKTsKKyAgICByZXFhX2lkID0gZ2V0X2RtYV9yZXF1ZXN0
b3JfaWQoaW9tbXUtPnNlZywgYmRmKTsKKyAgICAKICAgICAgICAgQU1EX0lPTU1VX0RFQlVH
KCJTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHglMDR4LCAiCiAgICAgICAg
ICAgICAgICAgICAgICAgICAicm9vdCB0YWJsZSA9IDB4JSJQUkl4NjQiLCAiCi0gICAgICAg
ICAgICAgICAgICAgICAgICAiZG9tYWluID0gJWQsIHBhZ2luZyBtb2RlID0gJWRcbiIsIHJl
cV9pZCwKKyAgICAgICAgICAgICAgICAgICAgICAgICJkb21haW4gPSAlZCwgcGFnaW5nIG1v
ZGUgPSAlZCB8ICVseCAlbHggJWx4ICVseFxuIiwgcmVxX2lkLAogICAgICAgICAgICAgICAg
ICAgICAgICAgcGFnZV90b19tYWRkcihoZC0+cm9vdF90YWJsZSksCi0gICAgICAgICAgICAg
ICAgICAgICAgICBoZC0+ZG9tYWluX2lkLCBoZC0+cGFnaW5nX21vZGUpOworICAgICAgICAg
ICAgICAgICAgICAgICAgaGQtPmRvbWFpbl9pZCwgaGQtPnBhZ2luZ19tb2RlLAorICAgIGl2
cnNfbWFwcGluZ3NbcmVxYV9pZF0uYWRkcl9yYW5nZV9zdGFydCwKKyAgICBpdnJzX21hcHBp
bmdzW3JlcWFfaWRdLmFkZHJfcmFuZ2VfbGVuZ3RoLAorICAgIGl2cnNfbWFwcGluZ3NbYmRm
XS5hZGRyX3JhbmdlX3N0YXJ0LAorICAgIGl2cnNfbWFwcGluZ3NbYmRmXS5hZGRyX3Jhbmdl
X2xlbmd0aCk7CiAgICAgfQogCiAgICAgc3Bpbl91bmxvY2tfaXJxcmVzdG9yZSgmaW9tbXUt
PmxvY2ssIGZsYWdzKTsKQEAgLTMzNCw4ICszNDEsMTAgQEAKICAgICBzdHJ1Y3QgcGNpX2Rl
diAqcGRldjsKICAgICBzdHJ1Y3QgYW1kX2lvbW11ICppb21tdTsKICAgICBpbnQgYmRmOwor
ICAgIGludCByZXFfaWQ7CiAgICAgc3RydWN0IGh2bV9pb21tdSAqdCA9IGRvbWFpbl9odm1f
aW9tbXUodGFyZ2V0KTsKLQorICAgIHN0cnVjdCBpdnJzX21hcHBpbmdzICppdnJzX21hcHBp
bmdzOworICAgIAogICAgIEFTU0VSVChzcGluX2lzX2xvY2tlZCgmcGNpZGV2c19sb2NrKSk7
CiAgICAgcGRldiA9IHBjaV9nZXRfcGRldl9ieV9kb21haW4oc291cmNlLCBzZWcsIGJ1cywg
ZGV2Zm4pOwogICAgIGlmICggIXBkZXYgKQpAQCAtMzYzLDEwICszNzIsMTcgQEAKICAgICAg
ICAgYWxsb2NhdGVfZG9tYWluX3Jlc291cmNlcyh0KTsKIAogICAgIGFtZF9pb21tdV9zZXR1
cF9kb21haW5fZGV2aWNlKHRhcmdldCwgaW9tbXUsIGJkZik7Ci0gICAgQU1EX0lPTU1VX0RF
QlVHKCJSZS1hc3NpZ24gJTA0eDolMDJ4OiUwMnguJXUgZnJvbSBkb20lZCB0byBkb20lZFxu
IiwKKyAgICAKKyAgICBpdnJzX21hcHBpbmdzID0gZ2V0X2l2cnNfbWFwcGluZ3Moc2VnKTsK
KyAgICByZXFfaWQgPSBnZXRfZG1hX3JlcXVlc3Rvcl9pZChzZWcsIGJkZik7CisgICAgCisg
ICAgQU1EX0lPTU1VX0RFQlVHKCJSZS1hc3NpZ24gJTA0eDolMDJ4OiUwMnguJXUgZnJvbSBk
b20lZCB0byBkb20lZCAlbHggJWx4ICVseCAlbHhcbiIsCiAgICAgICAgICAgICAgICAgICAg
IHNlZywgYnVzLCBQQ0lfU0xPVChkZXZmbiksIFBDSV9GVU5DKGRldmZuKSwKLSAgICAgICAg
ICAgICAgICAgICAgc291cmNlLT5kb21haW5faWQsIHRhcmdldC0+ZG9tYWluX2lkKTsKLQor
ICAgICAgICAgICAgICAgICAgICBzb3VyY2UtPmRvbWFpbl9pZCwgdGFyZ2V0LT5kb21haW5f
aWQsCisgICAgaXZyc19tYXBwaW5nc1tyZXFfaWRdLmFkZHJfcmFuZ2Vfc3RhcnQsCisgICAg
aXZyc19tYXBwaW5nc1tyZXFfaWRdLmFkZHJfcmFuZ2VfbGVuZ3RoLAorICAgIGl2cnNfbWFw
cGluZ3NbYmRmXS5hZGRyX3JhbmdlX3N0YXJ0LAorICAgIGl2cnNfbWFwcGluZ3NbYmRmXS5h
ZGRyX3JhbmdlX2xlbmd0aCk7CiAgICAgcmV0dXJuIDA7CiB9CiAKQEAgLTM4NSw2ICs0MDEs
MTMgQEAKICAgICAgICAgICAgIGl2cnNfbWFwcGluZ3NbcmVxX2lkXS53cml0ZV9wZXJtaXNz
aW9uLAogICAgICAgICAgICAgaXZyc19tYXBwaW5nc1tyZXFfaWRdLnJlYWRfcGVybWlzc2lv
bik7CiAgICAgfQorICAgICAgICBBTURfSU9NTVVfREVCVUcoImFtZF9pb21tdV9hc3NpZ25f
ZGV2aWNlOiIKKyAgICAgICAgICAgICAgICAgICAgICAgICIgZDolZCAlMDR4OiUwMng6JTAy
eC4ldSAlbHggJWx4XG4iLAorICAgICAgICAgICAgICAgICAgICAgICAgZC0+ZG9tYWluX2lk
LAorICAgICAgICAgICAgICAgICAgICAgICAgc2VnLCBidXMsIFBDSV9TTE9UKGRldmZuKSwK
KyAgICAgICAgICAgICAgICAgICAgICAgIFBDSV9GVU5DKGRldmZuKSwKKyAgICAgICAgICAg
ICAgICAgICAgICAgIGl2cnNfbWFwcGluZ3NbcmVxX2lkXS5hZGRyX3JhbmdlX3N0YXJ0LAor
ICAgICAgICAgICAgICAgICAgICAgICAgaXZyc19tYXBwaW5nc1tyZXFfaWRdLmFkZHJfcmFu
Z2VfbGVuZ3RoKTsKIAogICAgIHJldHVybiByZWFzc2lnbl9kZXZpY2UoZG9tMCwgZCwgc2Vn
LCBidXMsIGRldmZuKTsKIH0K
------------0E41640F726FFA493
Content-Type: text/plain;
 name="xl-dmesg-hvm.txt"
Content-transfer-encoding: base64
Content-Disposition: attachment;
 filename="xl-dmesg-hvm.txt"

IF9fICBfXyAgICAgICAgICAgIF8gIF8gICAgX19fX18gICAgICAgICAgICAgICAgICAgIF8g
ICAgICAgIF8gICAgIF8gICAgICANCiBcIFwvIC9fX18gXyBfXyAgIHwgfHwgfCAgfF9fXyAv
ICAgIF8gICBfIF8gX18gIF9fX3wgfF8gX18gX3wgfF9fIHwgfCBfX18gDQogIFwgIC8vIF8g
XCAnXyBcICB8IHx8IHxfICAgfF8gXCBfX3wgfCB8IHwgJ18gXC8gX198IF9fLyBfYCB8ICdf
IFx8IHwvIF8gXA0KICAvICBcICBfXy8gfCB8IHwgfF9fICAgX3wgX19fKSB8X198IHxffCB8
IHwgfCBcX18gXCB8fCAoX3wgfCB8XykgfCB8ICBfXy8NCiAvXy9cX1xfX198X3wgfF98ICAg
IHxffChfKV9fX18vICAgIFxfXyxffF98IHxffF9fXy9cX19cX18sX3xfLl9fL3xffFxfX198
DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgIA0KKFhFTikgWGVuIHZlcnNpb24gNC4zLXVuc3RhYmxl
IChyb290QGR5bmRucy5vcmcpIChnY2MgKERlYmlhbiA0LjQuNS04KSA0LjQuNSkgU3VuIFNl
cCAyMyAyMDoyNDo0MiBDRVNUIDIwMTINCihYRU4pIExhdGVzdCBDaGFuZ2VTZXQ6IFRodSBT
ZXAgMjAgMTM6MzE6MTkgMjAxMiArMDIwMCAyNTkzMzpkMzY0YmVjZmIwODMNCihYRU4pIEJv
b3Rsb2FkZXI6IEdSVUIgMS45OCsyMDEwMDgwNC0xNCtzcXVlZXplMQ0KKFhFTikgQ29tbWFu
ZCBsaW5lOiBkb20wX21lbT0xMDI0TSxtYXg6MTAyNE0gbG9nbHZsPWFsbCBsb2dsdmxfZ3Vl
c3Q9YWxsIGNvbnNvbGVfdGltZXN0YW1wcyB2Z2E9Z2Z4LTEyODB4MTAyNHgzMiBjcHVpZGxl
IGNwdWZyZXE9eGVuIG5vcmVib290IGRlYnVnIGxhcGljPWRlYnVnIGFwaWNfdmVyYm9zaXR5
PWRlYnVnIGFwaWM9ZGVidWcgaW9tbXU9b24sdmVyYm9zZSxkZWJ1ZyxhbWQtaW9tbXUtZGVi
dWcgY29tMT0zODQwMCw4bjEgY29uc29sZT12Z2EsY29tMQ0KKFhFTikgVmlkZW8gaW5mb3Jt
YXRpb246DQooWEVOKSAgVkdBIGlzIGdyYXBoaWNzIG1vZGUgMTI4MHgxMDI0LCAzMiBicHAN
CihYRU4pICBWQkUvRERDIG1ldGhvZHM6IFYyOyBFRElEIHRyYW5zZmVyIHRpbWU6IDEgc2Vj
b25kcw0KKFhFTikgRGlzYyBpbmZvcm1hdGlvbjoNCihYRU4pICBGb3VuZCAyIE1CUiBzaWdu
YXR1cmVzDQooWEVOKSAgRm91bmQgMiBFREQgaW5mb3JtYXRpb24gc3RydWN0dXJlcw0KKFhF
TikgWGVuLWU4MjAgUkFNIG1hcDoNCihYRU4pICAwMDAwMDAwMDAwMDAwMDAwIC0gMDAwMDAw
MDAwMDA5ZjAwMCAodXNhYmxlKQ0KKFhFTikgIDAwMDAwMDAwMDAwOWYwMDAgLSAwMDAwMDAw
MDAwMGEwMDAwIChyZXNlcnZlZCkNCihYRU4pICAwMDAwMDAwMDAwMGU0MDAwIC0gMDAwMDAw
MDAwMDEwMDAwMCAocmVzZXJ2ZWQpDQooWEVOKSAgMDAwMDAwMDAwMDEwMDAwMCAtIDAwMDAw
MDAwYWZmOTAwMDAgKHVzYWJsZSkNCihYRU4pICAwMDAwMDAwMGFmZjkwMDAwIC0gMDAwMDAw
MDBhZmY5ZTAwMCAoQUNQSSBkYXRhKQ0KKFhFTikgIDAwMDAwMDAwYWZmOWUwMDAgLSAwMDAw
MDAwMGFmZmUwMDAwIChBQ1BJIE5WUykNCihYRU4pICAwMDAwMDAwMGFmZmUwMDAwIC0gMDAw
MDAwMDBiMDAwMDAwMCAocmVzZXJ2ZWQpDQooWEVOKSAgMDAwMDAwMDBmZmUwMDAwMCAtIDAw
MDAwMDAxMDAwMDAwMDAgKHJlc2VydmVkKQ0KKFhFTikgIDAwMDAwMDAxMDAwMDAwMDAgLSAw
MDAwMDAwMjUwMDAwMDAwICh1c2FibGUpDQooWEVOKSBBQ1BJOiBSU0RQIDAwMEZCMTAwLCAw
MDE0IChyMCBBQ1BJQU0pDQooWEVOKSBBQ1BJOiBSU0RUIEFGRjkwMDAwLCAwMDQ4IChyMSBN
U0kgICAgT0VNU0xJQyAgMjAxMDA5MTMgTVNGVCAgICAgICA5NykNCihYRU4pIEFDUEk6IEZB
Q1AgQUZGOTAyMDAsIDAwODQgKHIxIDc2NDBNUyBBNzY0MDEwMCAyMDEwMDkxMyBNU0ZUICAg
ICAgIDk3KQ0KKFhFTikgQUNQSTogRFNEVCBBRkY5MDVFMCwgOTQyNyAocjEgIEE3NjQwIEE3
NjQwMTAwICAgICAgMTAwIElOVEwgMjAwNTExMTcpDQooWEVOKSBBQ1BJOiBGQUNTIEFGRjlF
MDAwLCAwMDQwDQooWEVOKSBBQ1BJOiBBUElDIEFGRjkwMzkwLCAwMDg4IChyMSA3NjQwTVMg
QTc2NDAxMDAgMjAxMDA5MTMgTVNGVCAgICAgICA5NykNCihYRU4pIEFDUEk6IE1DRkcgQUZG
OTA0MjAsIDAwM0MgKHIxIDc2NDBNUyBPRU1NQ0ZHICAyMDEwMDkxMyBNU0ZUICAgICAgIDk3
KQ0KKFhFTikgQUNQSTogU0xJQyBBRkY5MDQ2MCwgMDE3NiAocjEgTVNJICAgIE9FTVNMSUMg
IDIwMTAwOTEzIE1TRlQgICAgICAgOTcpDQooWEVOKSBBQ1BJOiBPRU1CIEFGRjlFMDQwLCAw
MDcyIChyMSA3NjQwTVMgQTc2NDAxMDAgMjAxMDA5MTMgTVNGVCAgICAgICA5NykNCihYRU4p
IEFDUEk6IFNSQVQgQUZGOUE1RTAsIDAxMDggKHIzIEFNRCAgICBGQU1fRl8xMCAgICAgICAg
MiBBTUQgICAgICAgICAxKQ0KKFhFTikgQUNQSTogSFBFVCBBRkY5QTZGMCwgMDAzOCAocjEg
NzY0ME1TIE9FTUhQRVQgIDIwMTAwOTEzIE1TRlQgICAgICAgOTcpDQooWEVOKSBBQ1BJOiBJ
VlJTIEFGRjlBNzMwLCAwMEY4IChyMSAgQU1EICAgICBSRDg5MFMgICAyMDIwMzEgQU1EICAg
ICAgICAgMCkNCihYRU4pIEFDUEk6IFNTRFQgQUZGOUE4MzAsIDBEQTQgKHIxIEEgTSBJICBQ
T1dFUk5PVyAgICAgICAgMSBBTUQgICAgICAgICAxKQ0KKFhFTikgU3lzdGVtIFJBTTogODE5
MU1CICg4Mzg3Nzcya0IpDQooWEVOKSBTUkFUOiBQWE0gMCAtPiBBUElDIDAgLT4gTm9kZSAw
DQooWEVOKSBTUkFUOiBQWE0gMCAtPiBBUElDIDEgLT4gTm9kZSAwDQooWEVOKSBTUkFUOiBQ
WE0gMCAtPiBBUElDIDIgLT4gTm9kZSAwDQooWEVOKSBTUkFUOiBQWE0gMCAtPiBBUElDIDMg
LT4gTm9kZSAwDQooWEVOKSBTUkFUOiBQWE0gMCAtPiBBUElDIDQgLT4gTm9kZSAwDQooWEVO
KSBTUkFUOiBQWE0gMCAtPiBBUElDIDUgLT4gTm9kZSAwDQooWEVOKSBTUkFUOiBOb2RlIDAg
UFhNIDAgMC1hMDAwMA0KKFhFTikgU1JBVDogTm9kZSAwIFBYTSAwIDEwMDAwMC1iMDAwMDAw
MA0KKFhFTikgU1JBVDogTm9kZSAwIFBYTSAwIDEwMDAwMDAwMC0yNTAwMDAwMDANCihYRU4p
IE5VTUE6IEFsbG9jYXRlZCBtZW1ub2RlbWFwIGZyb20gMjRkOWE0MDAwIC0gMjRkOWE3MDAw
DQooWEVOKSBOVU1BOiBVc2luZyA4IGZvciB0aGUgaGFzaCBzaGlmdC4NCihYRU4pIERvbWFp
biBoZWFwIGluaXRpYWxpc2VkDQooWEVOKSB2ZXNhZmI6IGZyYW1lYnVmZmVyIGF0IDB4ZmIw
MDAwMDAsIG1hcHBlZCB0byAweGZmZmY4MmMwMDAwMDAwMDAsIHVzaW5nIDYxNDRrLCB0b3Rh
bCAxNDMzNmsNCihYRU4pIHZlc2FmYjogbW9kZSBpcyAxMjgweDEwMjR4MzIsIGxpbmVsZW5n
dGg9NTEyMCwgZm9udCA4eDE2DQooWEVOKSB2ZXNhZmI6IFRydWVjb2xvcjogc2l6ZT04Ojg6
ODo4LCBzaGlmdD0yNDoxNjo4OjANCihYRU4pIGZvdW5kIFNNUCBNUC10YWJsZSBhdCAwMDBm
Zjc4MA0KKFhFTikgRE1JIHByZXNlbnQuDQooWEVOKSBBUElDIGJvb3Qgc3RhdGUgaXMgJ3hh
cGljJw0KKFhFTikgVXNpbmcgQVBJQyBkcml2ZXIgZGVmYXVsdA0KKFhFTikgQUNQSTogUE0t
VGltZXIgSU8gUG9ydDogMHg4MDgNCihYRU4pIEFDUEk6IEFDUEkgU0xFRVAgSU5GTzogcG0x
eF9jbnRbODA0LDBdLCBwbTF4X2V2dFs4MDAsMF0NCihYRU4pIEFDUEk6ICAgICAgICAgICAg
ICAgICAgd2FrZXVwX3ZlY1thZmY5ZTAwY10sIHZlY19zaXplWzIwXQ0KKFhFTikgQUNQSTog
TG9jYWwgQVBJQyBhZGRyZXNzIDB4ZmVlMDAwMDANCihYRU4pIEFDUEk6IExBUElDIChhY3Bp
X2lkWzB4MDFdIGxhcGljX2lkWzB4MDBdIGVuYWJsZWQpDQooWEVOKSBQcm9jZXNzb3IgIzAg
MDoxMCBBUElDIHZlcnNpb24gMTYNCihYRU4pIEFDUEk6IExBUElDIChhY3BpX2lkWzB4MDJd
IGxhcGljX2lkWzB4MDFdIGVuYWJsZWQpDQooWEVOKSBQcm9jZXNzb3IgIzEgMDoxMCBBUElD
IHZlcnNpb24gMTYNCihYRU4pIEFDUEk6IExBUElDIChhY3BpX2lkWzB4MDNdIGxhcGljX2lk
WzB4MDJdIGVuYWJsZWQpDQooWEVOKSBQcm9jZXNzb3IgIzIgMDoxMCBBUElDIHZlcnNpb24g
MTYNCihYRU4pIEFDUEk6IExBUElDIChhY3BpX2lkWzB4MDRdIGxhcGljX2lkWzB4MDNdIGVu
YWJsZWQpDQooWEVOKSBQcm9jZXNzb3IgIzMgMDoxMCBBUElDIHZlcnNpb24gMTYNCihYRU4p
IEFDUEk6IExBUElDIChhY3BpX2lkWzB4MDVdIGxhcGljX2lkWzB4MDRdIGVuYWJsZWQpDQoo
WEVOKSBQcm9jZXNzb3IgIzQgMDoxMCBBUElDIHZlcnNpb24gMTYNCihYRU4pIEFDUEk6IExB
UElDIChhY3BpX2lkWzB4MDZdIGxhcGljX2lkWzB4MDVdIGVuYWJsZWQpDQooWEVOKSBQcm9j
ZXNzb3IgIzUgMDoxMCBBUElDIHZlcnNpb24gMTYNCihYRU4pIEFDUEk6IElPQVBJQyAoaWRb
MHgwNl0gYWRkcmVzc1sweGZlYzAwMDAwXSBnc2lfYmFzZVswXSkNCihYRU4pIElPQVBJQ1sw
XTogYXBpY19pZCA2LCB2ZXJzaW9uIDMzLCBhZGRyZXNzIDB4ZmVjMDAwMDAsIEdTSSAwLTIz
DQooWEVOKSBBQ1BJOiBJT0FQSUMgKGlkWzB4MDddIGFkZHJlc3NbMHhmZWMyMDAwMF0gZ3Np
X2Jhc2VbMjRdKQ0KKFhFTikgSU9BUElDWzFdOiBhcGljX2lkIDcsIHZlcnNpb24gMzMsIGFk
ZHJlc3MgMHhmZWMyMDAwMCwgR1NJIDI0LTU1DQooWEVOKSBBQ1BJOiBJTlRfU1JDX09WUiAo
YnVzIDAgYnVzX2lycSAwIGdsb2JhbF9pcnEgMiBkZmwgZGZsKQ0KKFhFTikgQUNQSTogSU5U
X1NSQ19PVlIgKGJ1cyAwIGJ1c19pcnEgOSBnbG9iYWxfaXJxIDkgbG93IGxldmVsKQ0KKFhF
TikgQUNQSTogSVJRMCB1c2VkIGJ5IG92ZXJyaWRlLg0KKFhFTikgQUNQSTogSVJRMiB1c2Vk
IGJ5IG92ZXJyaWRlLg0KKFhFTikgQUNQSTogSVJROSB1c2VkIGJ5IG92ZXJyaWRlLg0KKFhF
TikgRW5hYmxpbmcgQVBJQyBtb2RlOiAgRmxhdC4gIFVzaW5nIDIgSS9PIEFQSUNzDQooWEVO
KSBBQ1BJOiBIUEVUIGlkOiAweDgzMDAgYmFzZTogMHhmZWQwMDAwMA0KKFhFTikgVGFibGUg
aXMgbm90IGZvdW5kIQ0KKFhFTikgVXNpbmcgQUNQSSAoTUFEVCkgZm9yIFNNUCBjb25maWd1
cmF0aW9uIGluZm9ybWF0aW9uDQooWEVOKSBTTVA6IEFsbG93aW5nIDYgQ1BVcyAoMCBob3Rw
bHVnIENQVXMpDQooWEVOKSBtYXBwZWQgQVBJQyB0byBmZmZmODJjM2ZmZGZiMDAwIChmZWUw
MDAwMCkNCihYRU4pIG1hcHBlZCBJT0FQSUMgdG8gZmZmZjgyYzNmZmRmYTAwMCAoZmVjMDAw
MDApDQooWEVOKSBtYXBwZWQgSU9BUElDIHRvIGZmZmY4MmMzZmZkZjkwMDAgKGZlYzIwMDAw
KQ0KKFhFTikgSVJRIGxpbWl0czogNTYgR1NJLCAxMTEyIE1TSS9NU0ktWA0KKFhFTikgVXNp
bmcgc2NoZWR1bGVyOiBTTVAgQ3JlZGl0IFNjaGVkdWxlciAoY3JlZGl0KQ0KKFhFTikgRGV0
ZWN0ZWQgMzIwMC4yMDAgTUh6IHByb2Nlc3Nvci4NCihYRU4pIEluaXRpbmcgbWVtb3J5IHNo
YXJpbmcuDQooWEVOKSBBTUQgRmFtMTBoIG1hY2hpbmUgY2hlY2sgcmVwb3J0aW5nIGVuYWJs
ZWQNCihYRU4pIFBDSTogTUNGRyBjb25maWd1cmF0aW9uIDA6IGJhc2UgZTAwMDAwMDAgc2Vn
bWVudCAwMDAwIGJ1c2VzIDAwIC0gZmYNCihYRU4pIFBDSTogTm90IHVzaW5nIE1DRkcgZm9y
IHNlZ21lbnQgMDAwMCBidXMgMDAtZmYNCihYRU4pIEFNRC1WaTogRm91bmQgTVNJIGNhcGFi
aWxpdHkgYmxvY2sgYXQgMHg1NA0KKFhFTikgQU1ELVZpOiBBQ1BJIFRhYmxlOg0KKFhFTikg
QU1ELVZpOiAgU2lnbmF0dXJlIElWUlMNCihYRU4pIEFNRC1WaTogIExlbmd0aCAweGY4DQoo
WEVOKSBBTUQtVmk6ICBSZXZpc2lvbiAweDENCihYRU4pIEFNRC1WaTogIENoZWNrU3VtIDB4
OTgNCihYRU4pIEFNRC1WaTogIE9FTV9JZCBBTUQgIA0KKFhFTikgQU1ELVZpOiAgT0VNX1Rh
YmxlX0lkIFJEODkwUw0KKFhFTikgQU1ELVZpOiAgT0VNX1JldmlzaW9uIDB4MjAyMDMxDQoo
WEVOKSBBTUQtVmk6ICBDcmVhdG9yX0lkIEFNRCANCihYRU4pIEFNRC1WaTogIENyZWF0b3Jf
UmV2aXNpb24gMHgwDQooWEVOKSBBTUQtVmk6IElWUlMgQmxvY2s6DQooWEVOKSBBTUQtVmk6
ICBUeXBlIDB4MTANCihYRU4pIEFNRC1WaTogIEZsYWdzIDB4M2UNCihYRU4pIEFNRC1WaTog
IExlbmd0aCAweGM4DQooWEVOKSBBTUQtVmk6ICBEZXZfSWQgMHgyDQooWEVOKSBBTUQtVmk6
IElWSEQgRGV2aWNlIEVudHJ5Og0KKFhFTikgQU1ELVZpOiAgVHlwZSAweDMNCihYRU4pIEFN
RC1WaTogIERldl9JZCAweDANCihYRU4pIEFNRC1WaTogIEZsYWdzIDB4MA0KKFhFTikgQU1E
LVZpOiAgRGV2X0lkIFJhbmdlOiAweDAgLT4gMHgyDQooWEVOKSBBTUQtVmk6IElWSEQgRGV2
aWNlIEVudHJ5Og0KKFhFTikgQU1ELVZpOiAgVHlwZSAweDINCihYRU4pIEFNRC1WaTogIERl
dl9JZCAweDEwDQooWEVOKSBBTUQtVmk6ICBGbGFncyAweDANCihYRU4pIEFNRC1WaTogSVZI
RCBEZXZpY2UgRW50cnk6DQooWEVOKSBBTUQtVmk6ICBUeXBlIDB4Mg0KKFhFTikgQU1ELVZp
OiAgRGV2X0lkIDB4YTAwDQooWEVOKSBBTUQtVmk6ICBGbGFncyAweDANCihYRU4pIEFNRC1W
aTogSVZIRCBEZXZpY2UgRW50cnk6DQooWEVOKSBBTUQtVmk6ICBUeXBlIDB4Mg0KKFhFTikg
QU1ELVZpOiAgRGV2X0lkIDB4MTgNCihYRU4pIEFNRC1WaTogIEZsYWdzIDB4MA0KKFhFTikg
QU1ELVZpOiBJVkhEIERldmljZSBFbnRyeToNCihYRU4pIEFNRC1WaTogIFR5cGUgMHgzDQoo
WEVOKSBBTUQtVmk6ICBEZXZfSWQgMHg5MDANCihYRU4pIEFNRC1WaTogIEZsYWdzIDB4MA0K
KFhFTikgQU1ELVZpOiAgRGV2X0lkIFJhbmdlOiAweDkwMCAtPiAweDkwNw0KKFhFTikgQU1E
LVZpOiBJVkhEIERldmljZSBFbnRyeToNCihYRU4pIEFNRC1WaTogIFR5cGUgMHgyDQooWEVO
KSBBTUQtVmk6ICBEZXZfSWQgMHgyOA0KKFhFTikgQU1ELVZpOiAgRmxhZ3MgMHgwDQooWEVO
KSBBTUQtVmk6IElWSEQgRGV2aWNlIEVudHJ5Og0KKFhFTikgQU1ELVZpOiAgVHlwZSAweDIN
CihYRU4pIEFNRC1WaTogIERldl9JZCAweDgwMA0KKFhFTikgQU1ELVZpOiAgRmxhZ3MgMHgw
DQooWEVOKSBBTUQtVmk6IElWSEQgRGV2aWNlIEVudHJ5Og0KKFhFTikgQU1ELVZpOiAgVHlw
ZSAweDINCihYRU4pIEFNRC1WaTogIERldl9JZCAweDMwDQooWEVOKSBBTUQtVmk6ICBGbGFn
cyAweDANCihYRU4pIEFNRC1WaTogSVZIRCBEZXZpY2UgRW50cnk6DQooWEVOKSBBTUQtVmk6
ICBUeXBlIDB4Mg0KKFhFTikgQU1ELVZpOiAgRGV2X0lkIDB4NzAwDQooWEVOKSBBTUQtVmk6
ICBGbGFncyAweDANCihYRU4pIEFNRC1WaTogSVZIRCBEZXZpY2UgRW50cnk6DQooWEVOKSBB
TUQtVmk6ICBUeXBlIDB4Mg0KKFhFTikgQU1ELVZpOiAgRGV2X0lkIDB4NTANCihYRU4pIEFN
RC1WaTogIEZsYWdzIDB4MA0KKFhFTikgQU1ELVZpOiBJVkhEIERldmljZSBFbnRyeToNCihY
RU4pIEFNRC1WaTogIFR5cGUgMHgyDQooWEVOKSBBTUQtVmk6ICBEZXZfSWQgMHg2MDANCihY
RU4pIEFNRC1WaTogIEZsYWdzIDB4MA0KKFhFTikgQU1ELVZpOiBJVkhEIERldmljZSBFbnRy
eToNCihYRU4pIEFNRC1WaTogIFR5cGUgMHgyDQooWEVOKSBBTUQtVmk6ICBEZXZfSWQgMHg1
OA0KKFhFTikgQU1ELVZpOiAgRmxhZ3MgMHgwDQooWEVOKSBBTUQtVmk6IElWSEQgRGV2aWNl
IEVudHJ5Og0KKFhFTikgQU1ELVZpOiAgVHlwZSAweDMNCihYRU4pIEFNRC1WaTogIERldl9J
ZCAweDUwMA0KKFhFTikgQU1ELVZpOiAgRmxhZ3MgMHgwDQooWEVOKSBBTUQtVmk6ICBEZXZf
SWQgUmFuZ2U6IDB4NTAwIC0+IDB4NTAxDQooWEVOKSBBTUQtVmk6IElWSEQgRGV2aWNlIEVu
dHJ5Og0KKFhFTikgQU1ELVZpOiAgVHlwZSAweDINCihYRU4pIEFNRC1WaTogIERldl9JZCAw
eDY4DQooWEVOKSBBTUQtVmk6ICBGbGFncyAweDANCihYRU4pIEFNRC1WaTogSVZIRCBEZXZp
Y2UgRW50cnk6DQooWEVOKSBBTUQtVmk6ICBUeXBlIDB4Mw0KKFhFTikgQU1ELVZpOiAgRGV2
X0lkIDB4NDAwDQooWEVOKSBBTUQtVmk6ICBGbGFncyAweDANCihYRU4pIEFNRC1WaTogIERl
dl9JZCBSYW5nZTogMHg0MDAgLT4gMHg0MDcNCihYRU4pIEFNRC1WaTogSVZIRCBEZXZpY2Ug
RW50cnk6DQooWEVOKSBBTUQtVmk6ICBUeXBlIDB4Mg0KKFhFTikgQU1ELVZpOiAgRGV2X0lk
IDB4ODgNCihYRU4pIEFNRC1WaTogIEZsYWdzIDB4MA0KKFhFTikgQU1ELVZpOiBJVkhEIERl
dmljZSBFbnRyeToNCihYRU4pIEFNRC1WaTogIFR5cGUgMHgzDQooWEVOKSBBTUQtVmk6ICBE
ZXZfSWQgMHg5MA0KKFhFTikgQU1ELVZpOiAgRmxhZ3MgMHgwDQooWEVOKSBBTUQtVmk6ICBE
ZXZfSWQgUmFuZ2U6IDB4OTAgLT4gMHg5Mg0KKFhFTikgQU1ELVZpOiBJVkhEIERldmljZSBF
bnRyeToNCihYRU4pIEFNRC1WaTogIFR5cGUgMHgzDQooWEVOKSBBTUQtVmk6ICBEZXZfSWQg
MHg5OA0KKFhFTikgQU1ELVZpOiAgRmxhZ3MgMHgwDQooWEVOKSBBTUQtVmk6ICBEZXZfSWQg
UmFuZ2U6IDB4OTggLT4gMHg5YQ0KKFhFTikgQU1ELVZpOiBJVkhEIERldmljZSBFbnRyeToN
CihYRU4pIEFNRC1WaTogIFR5cGUgMHgyDQooWEVOKSBBTUQtVmk6ICBEZXZfSWQgMHhhMA0K
KFhFTikgQU1ELVZpOiAgRmxhZ3MgMHhkNw0KKFhFTikgQU1ELVZpOiBJVkhEIERldmljZSBF
bnRyeToNCihYRU4pIEFNRC1WaTogIFR5cGUgMHgyDQooWEVOKSBBTUQtVmk6ICBEZXZfSWQg
MHhhMQ0KKFhFTikgQU1ELVZpOiAgRmxhZ3MgMHgwDQooWEVOKSBBTUQtVmk6IElWSEQgRGV2
aWNlIEVudHJ5Og0KKFhFTikgQU1ELVZpOiAgVHlwZSAweDINCihYRU4pIEFNRC1WaTogIERl
dl9JZCAweGEyDQooWEVOKSBBTUQtVmk6ICBGbGFncyAweDANCihYRU4pIEFNRC1WaTogSVZI
RCBEZXZpY2UgRW50cnk6DQooWEVOKSBBTUQtVmk6ICBUeXBlIDB4Mg0KKFhFTikgQU1ELVZp
OiAgRGV2X0lkIDB4YTMNCihYRU4pIEFNRC1WaTogIEZsYWdzIDB4MA0KKFhFTikgQU1ELVZp
OiBJVkhEIERldmljZSBFbnRyeToNCihYRU4pIEFNRC1WaTogIFR5cGUgMHgyDQooWEVOKSBB
TUQtVmk6ICBEZXZfSWQgMHhhNA0KKFhFTikgQU1ELVZpOiAgRmxhZ3MgMHgwDQooWEVOKSBB
TUQtVmk6IElWSEQgRGV2aWNlIEVudHJ5Og0KKFhFTikgQU1ELVZpOiAgVHlwZSAweDANCihY
RU4pIEFNRC1WaTogIERldl9JZCAweDANCihYRU4pIEFNRC1WaTogIEZsYWdzIDB4MA0KKFhF
TikgQU1ELVZpOiBJVkhEIERldmljZSBFbnRyeToNCihYRU4pIEFNRC1WaTogIFR5cGUgMHg0
Mw0KKFhFTikgQU1ELVZpOiAgRGV2X0lkIDB4MzAwDQooWEVOKSBBTUQtVmk6ICBGbGFncyAw
eDANCihYRU4pIEFNRC1WaTogIERldl9JZCBSYW5nZTogMHgzMDAgLT4gMHgzZmYNCihYRU4p
IEFNRC1WaTogIERldl9JZCBBbGlhczogMHhhNA0KKFhFTikgQU1ELVZpOiBJVkhEIERldmlj
ZSBFbnRyeToNCihYRU4pIEFNRC1WaTogIFR5cGUgMHgyDQooWEVOKSBBTUQtVmk6ICBEZXZf
SWQgMHhhNQ0KKFhFTikgQU1ELVZpOiAgRmxhZ3MgMHgwDQooWEVOKSBBTUQtVmk6IElWSEQg
RGV2aWNlIEVudHJ5Og0KKFhFTikgQU1ELVZpOiAgVHlwZSAweDINCihYRU4pIEFNRC1WaTog
IERldl9JZCAweGE4DQooWEVOKSBBTUQtVmk6ICBGbGFncyAweDANCihYRU4pIEFNRC1WaTog
SVZIRCBEZXZpY2UgRW50cnk6DQooWEVOKSBBTUQtVmk6ICBUeXBlIDB4Mg0KKFhFTikgQU1E
LVZpOiAgRGV2X0lkIDB4YTkNCihYRU4pIEFNRC1WaTogIEZsYWdzIDB4MA0KKFhFTikgQU1E
LVZpOiBJVkhEIERldmljZSBFbnRyeToNCihYRU4pIEFNRC1WaTogIFR5cGUgMHgyDQooWEVO
KSBBTUQtVmk6ICBEZXZfSWQgMHgxMDANCihYRU4pIEFNRC1WaTogIEZsYWdzIDB4MA0KKFhF
TikgQU1ELVZpOiBJVkhEIERldmljZSBFbnRyeToNCihYRU4pIEFNRC1WaTogIFR5cGUgMHgz
DQooWEVOKSBBTUQtVmk6ICBEZXZfSWQgMHhiMA0KKFhFTikgQU1ELVZpOiAgRmxhZ3MgMHgw
DQooWEVOKSBBTUQtVmk6ICBEZXZfSWQgUmFuZ2U6IDB4YjAgLT4gMHhiMg0KKFhFTikgQU1E
LVZpOiBJVkhEIERldmljZSBFbnRyeToNCihYRU4pIEFNRC1WaTogIFR5cGUgMHgwDQooWEVO
KSBBTUQtVmk6ICBEZXZfSWQgMHgwDQooWEVOKSBBTUQtVmk6ICBGbGFncyAweDANCihYRU4p
IEFNRC1WaTogSVZIRCBEZXZpY2UgRW50cnk6DQooWEVOKSBBTUQtVmk6ICBUeXBlIDB4NDgN
CihYRU4pIEFNRC1WaTogIERldl9JZCAweDANCihYRU4pIEFNRC1WaTogIEZsYWdzIDB4ZDcN
CihYRU4pIEFNRC1WaTogSVZIRCBEZXZpY2UgRW50cnk6DQooWEVOKSBBTUQtVmk6ICBUeXBl
IDB4NDgNCihYRU4pIEFNRC1WaTogIERldl9JZCAweDANCihYRU4pIEFNRC1WaTogIEZsYWdz
IDB4MA0KKFhFTikgQU1ELVZpOiBJT01NVSAwIEVuYWJsZWQuDQooWEVOKSBBTUQtVmk6IEVu
YWJsaW5nIGdsb2JhbCB2ZWN0b3IgbWFwDQooWEVOKSBJL08gdmlydHVhbGlzYXRpb24gZW5h
YmxlZA0KKFhFTikgIC0gRG9tMCBtb2RlOiBSZWxheGVkDQooWEVOKSBHZXR0aW5nIFZFUlNJ
T046IDgwMDUwMDEwDQooWEVOKSBHZXR0aW5nIFZFUlNJT046IDgwMDUwMDEwDQooWEVOKSBH
ZXR0aW5nIElEOiAwDQooWEVOKSBHZXR0aW5nIExWVDA6IDcwMA0KKFhFTikgR2V0dGluZyBM
VlQxOiA0MDANCihYRU4pIGVuYWJsZWQgRXh0SU5UIG9uIENQVSMwDQooWEVOKSBFU1IgdmFs
dWUgYmVmb3JlIGVuYWJsaW5nIHZlY3RvcjogMHgwMDAwMDAwNCAgYWZ0ZXI6IDB4MDAwMDAw
MDANCihYRU4pIEVOQUJMSU5HIElPLUFQSUMgSVJRcw0KKFhFTikgIC0+IFVzaW5nIG5ldyBB
Q0sgbWV0aG9kDQooWEVOKSBpbml0IElPX0FQSUMgSVJRcw0KKFhFTikgIElPLUFQSUMgKGFw
aWNpZC1waW4pIDYtMCwgNi0xNiwgNi0xNywgNi0xOCwgNi0xOSwgNi0yMCwgNi0yMSwgNi0y
MiwgNi0yMywgNy0wLCA3LTEsIDctMiwgNy0zLCA3LTQsIDctNSwgNy02LCA3LTcsIDctOCwg
Ny05LCA3LTEwLCA3LTExLCA3LTEyLCA3LTEzLCA3LTE0LCA3LTE1LCA3LTE2LCA3LTE3LCA3
LTE4LCA3LTE5LCA3LTIwLCA3LTIxLCA3LTIyLCA3LTIzLCA3LTI0LCA3LTI1LCA3LTI2LCA3
LTI3LCA3LTI4LCA3LTI5LCA3LTMwLCA3LTMxIG5vdCBjb25uZWN0ZWQuDQooWEVOKSAuLlRJ
TUVSOiB2ZWN0b3I9MHhGMCBhcGljMT0wIHBpbjE9MiBhcGljMj0tMSBwaW4yPS0xDQooWEVO
KSBudW1iZXIgb2YgTVAgSVJRIHNvdXJjZXM6IDE1Lg0KKFhFTikgbnVtYmVyIG9mIElPLUFQ
SUMgIzYgcmVnaXN0ZXJzOiAyNC4NCihYRU4pIG51bWJlciBvZiBJTy1BUElDICM3IHJlZ2lz
dGVyczogMzIuDQooWEVOKSB0ZXN0aW5nIHRoZSBJTyBBUElDLi4uLi4uLi4uLi4uLi4uLi4u
Li4uLi4NCihYRU4pIElPIEFQSUMgIzYuLi4uLi4NCihYRU4pIC4uLi4gcmVnaXN0ZXIgIzAw
OiAwNjAwMDAwMA0KKFhFTikgLi4uLi4uLiAgICA6IHBoeXNpY2FsIEFQSUMgaWQ6IDA2DQoo
WEVOKSAuLi4uLi4uICAgIDogRGVsaXZlcnkgVHlwZTogMA0KKFhFTikgLi4uLi4uLiAgICA6
IExUUyAgICAgICAgICA6IDANCihYRU4pIC4uLi4gcmVnaXN0ZXIgIzAxOiAwMDE3ODAyMQ0K
KFhFTikgLi4uLi4uLiAgICAgOiBtYXggcmVkaXJlY3Rpb24gZW50cmllczogMDAxNw0KKFhF
TikgLi4uLi4uLiAgICAgOiBQUlEgaW1wbGVtZW50ZWQ6IDENCihYRU4pIC4uLi4uLi4gICAg
IDogSU8gQVBJQyB2ZXJzaW9uOiAwMDIxDQooWEVOKSAuLi4uIHJlZ2lzdGVyICMwMjogMDYw
MDAwMDANCihYRU4pIC4uLi4uLi4gICAgIDogYXJiaXRyYXRpb246IDA2DQooWEVOKSAuLi4u
IHJlZ2lzdGVyICMwMzogMDcwMDAwMDANCihYRU4pIC4uLi4uLi4gICAgIDogQm9vdCBEVCAg
ICA6IDANCihYRU4pIC4uLi4gSVJRIHJlZGlyZWN0aW9uIHRhYmxlOg0KKFhFTikgIE5SIExv
ZyBQaHkgTWFzayBUcmlnIElSUiBQb2wgU3RhdCBEZXN0IERlbGkgVmVjdDogICANCihYRU4p
ICAwMCAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwDQooWEVO
KSAgMDEgMDAxIDAxICAwICAgIDAgICAgMCAgIDAgICAwICAgIDEgICAgMSAgICAzMA0KKFhF
TikgIDAyIDAwMSAwMSAgMCAgICAwICAgIDAgICAwICAgMCAgICAxICAgIDEgICAgRjANCihY
RU4pICAwMyAwMDEgMDEgIDAgICAgMCAgICAwICAgMCAgIDAgICAgMSAgICAxICAgIDM4DQoo
WEVOKSAgMDQgMDAxIDAxICAwICAgIDAgICAgMCAgIDAgICAwICAgIDEgICAgMSAgICBGMQ0K
KFhFTikgIDA1IDAwMSAwMSAgMCAgICAwICAgIDAgICAwICAgMCAgICAxICAgIDEgICAgNDAN
CihYRU4pICAwNiAwMDEgMDEgIDAgICAgMCAgICAwICAgMCAgIDAgICAgMSAgICAxICAgIDQ4
DQooWEVOKSAgMDcgMDAxIDAxICAwICAgIDAgICAgMCAgIDAgICAwICAgIDEgICAgMSAgICA1
MA0KKFhFTikgIDA4IDAwMSAwMSAgMCAgICAwICAgIDAgICAwICAgMCAgICAxICAgIDEgICAg
NTgNCihYRU4pICAwOSAwMDEgMDEgIDEgICAgMSAgICAwICAgMSAgIDAgICAgMSAgICAxICAg
IDYwDQooWEVOKSAgMGEgMDAxIDAxICAwICAgIDAgICAgMCAgIDAgICAwICAgIDEgICAgMSAg
ICA2OA0KKFhFTikgIDBiIDAwMSAwMSAgMCAgICAwICAgIDAgICAwICAgMCAgICAxICAgIDEg
ICAgNzANCihYRU4pICAwYyAwMDEgMDEgIDAgICAgMCAgICAwICAgMCAgIDAgICAgMSAgICAx
ICAgIDc4DQooWEVOKSAgMGQgMDAxIDAxICAwICAgIDAgICAgMCAgIDAgICAwICAgIDEgICAg
MSAgICA4OA0KKFhFTikgIDBlIDAwMSAwMSAgMCAgICAwICAgIDAgICAwICAgMCAgICAxICAg
IDEgICAgOTANCihYRU4pICAwZiAwMDEgMDEgIDAgICAgMCAgICAwICAgMCAgIDAgICAgMSAg
ICAxICAgIDk4DQooWEVOKSAgMTAgMDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAwICAgIDAg
ICAgMCAgICAwMA0KKFhFTikgIDExIDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAw
ICAgIDAgICAgMDANCihYRU4pICAxMiAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAg
MCAgICAwICAgIDAwDQooWEVOKSAgMTMgMDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAwICAg
IDAgICAgMCAgICAwMA0KKFhFTikgIDE0IDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAg
ICAwICAgIDAgICAgMDANCihYRU4pICAxNSAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAg
ICAgMCAgICAwICAgIDAwDQooWEVOKSAgMTYgMDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAw
ICAgIDAgICAgMCAgICAwMA0KKFhFTikgIDE3IDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAg
MCAgICAwICAgIDAgICAgMDANCihYRU4pIElPIEFQSUMgIzcuLi4uLi4NCihYRU4pIC4uLi4g
cmVnaXN0ZXIgIzAwOiAwNzAwMDAwMA0KKFhFTikgLi4uLi4uLiAgICA6IHBoeXNpY2FsIEFQ
SUMgaWQ6IDA3DQooWEVOKSAuLi4uLi4uICAgIDogRGVsaXZlcnkgVHlwZTogMA0KKFhFTikg
Li4uLi4uLiAgICA6IExUUyAgICAgICAgICA6IDANCihYRU4pIC4uLi4gcmVnaXN0ZXIgIzAx
OiAwMDFGODAyMQ0KKFhFTikgLi4uLi4uLiAgICAgOiBtYXggcmVkaXJlY3Rpb24gZW50cmll
czogMDAxRg0KKFhFTikgLi4uLi4uLiAgICAgOiBQUlEgaW1wbGVtZW50ZWQ6IDENCihYRU4p
IC4uLi4uLi4gICAgIDogSU8gQVBJQyB2ZXJzaW9uOiAwMDIxDQooWEVOKSAuLi4uIHJlZ2lz
dGVyICMwMjogMDAwMDAwMDANCihYRU4pIC4uLi4uLi4gICAgIDogYXJiaXRyYXRpb246IDAw
DQooWEVOKSAuLi4uIElSUSByZWRpcmVjdGlvbiB0YWJsZToNCihYRU4pICBOUiBMb2cgUGh5
IE1hc2sgVHJpZyBJUlIgUG9sIFN0YXQgRGVzdCBEZWxpIFZlY3Q6ICAgDQooWEVOKSAgMDAg
MDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAwICAgIDAgICAgMCAgICAwMA0KKFhFTikgIDAx
IDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDAgICAgMDANCihYRU4pICAw
MiAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwDQooWEVOKSAg
MDMgMDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAwICAgIDAgICAgMCAgICAwMA0KKFhFTikg
IDA0IDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDAgICAgMDANCihYRU4p
ICAwNSAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwDQooWEVO
KSAgMDYgMDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAwICAgIDAgICAgMCAgICAwMA0KKFhF
TikgIDA3IDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDAgICAgMDANCihY
RU4pICAwOCAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwDQoo
WEVOKSAgMDkgMDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAwICAgIDAgICAgMCAgICAwMA0K
KFhFTikgIDBhIDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDAgICAgMDAN
CihYRU4pICAwYiAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAw
DQooWEVOKSAgMGMgMDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAwICAgIDAgICAgMCAgICAw
MA0KKFhFTikgIDBkIDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDAgICAg
MDANCihYRU4pICAwZSAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAg
IDAwDQooWEVOKSAgMGYgMDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAwICAgIDAgICAgMCAg
ICAwMA0KKFhFTikgIDEwIDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDAg
ICAgMDANCihYRU4pICAxMSAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAw
ICAgIDAwDQooWEVOKSAgMTIgMDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAwICAgIDAgICAg
MCAgICAwMA0KKFhFTikgIDEzIDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAg
IDAgICAgMDANCihYRU4pICAxNCAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAg
ICAwICAgIDAwDQooWEVOKSAgMTUgMDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAwICAgIDAg
ICAgMCAgICAwMA0KKFhFTikgIDE2IDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAw
ICAgIDAgICAgMDANCihYRU4pICAxNyAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAg
MCAgICAwICAgIDAwDQooWEVOKSAgMTggMDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAwICAg
IDAgICAgMCAgICAwMA0KKFhFTikgIDE5IDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAg
ICAwICAgIDAgICAgMDANCihYRU4pICAxYSAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAg
ICAgMCAgICAwICAgIDAwDQooWEVOKSAgMWIgMDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAw
ICAgIDAgICAgMCAgICAwMA0KKFhFTikgIDFjIDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAg
MCAgICAwICAgIDAgICAgMDANCihYRU4pICAxZCAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAg
IDAgICAgMCAgICAwICAgIDAwDQooWEVOKSAgMWUgMDAwIDAwICAxICAgIDAgICAgMCAgIDAg
ICAwICAgIDAgICAgMCAgICAwMA0KKFhFTikgIDFmIDAwMCAwMCAgMSAgICAwICAgIDAgICAw
ICAgMCAgICAwICAgIDAgICAgMDANCihYRU4pIFVzaW5nIHZlY3Rvci1iYXNlZCBpbmRleGlu
Zw0KKFhFTikgSVJRIHRvIHBpbiBtYXBwaW5nczoNCihYRU4pIElSUTI0MCAtPiAwOjINCihY
RU4pIElSUTQ4IC0+IDA6MQ0KKFhFTikgSVJRNTYgLT4gMDozDQooWEVOKSBJUlEyNDEgLT4g
MDo0DQooWEVOKSBJUlE2NCAtPiAwOjUNCihYRU4pIElSUTcyIC0+IDA6Ng0KKFhFTikgSVJR
ODAgLT4gMDo3DQooWEVOKSBJUlE4OCAtPiAwOjgNCihYRU4pIElSUTk2IC0+IDA6OQ0KKFhF
TikgSVJRMTA0IC0+IDA6MTANCihYRU4pIElSUTExMiAtPiAwOjExDQooWEVOKSBJUlExMjAg
LT4gMDoxMg0KKFhFTikgSVJRMTM2IC0+IDA6MTMNCihYRU4pIElSUTE0NCAtPiAwOjE0DQoo
WEVOKSBJUlExNTIgLT4gMDoxNQ0KKFhFTikgLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u
Li4uLi4uLi4uIGRvbmUuDQooWEVOKSBVc2luZyBsb2NhbCBBUElDIHRpbWVyIGludGVycnVw
dHMuDQooWEVOKSBjYWxpYnJhdGluZyBBUElDIHRpbWVyIC4uLg0KKFhFTikgLi4uLi4gQ1BV
IGNsb2NrIHNwZWVkIGlzIDMyMDAuMTYwOCBNSHouDQooWEVOKSAuLi4uLiBob3N0IGJ1cyBj
bG9jayBzcGVlZCBpcyAyMDAuMDA5OSBNSHouDQooWEVOKSAuLi4uLiBidXNfc2NhbGUgPSAw
eDAwMDBDQ0Q3DQooWEVOKSBbMjAxMi0wOS0yNCAwNjozOToyOV0gUGxhdGZvcm0gdGltZXIg
aXMgMTQuMzE4TUh6IEhQRVQNCihYRU4pIFsyMDEyLTA5LTI0IDA2OjM5OjI5XSBBbGxvY2F0
ZWQgY29uc29sZSByaW5nIG9mIDY0IEtpQi4NCihYRU4pIFsyMDEyLTA5LTI0IDA2OjM5OjI5
XSBIVk06IEFTSURzIGVuYWJsZWQuDQooWEVOKSBbMjAxMi0wOS0yNCAwNjozOToyOV0gU1ZN
OiBTdXBwb3J0ZWQgYWR2YW5jZWQgZmVhdHVyZXM6DQooWEVOKSBbMjAxMi0wOS0yNCAwNjoz
OToyOV0gIC0gTmVzdGVkIFBhZ2UgVGFibGVzIChOUFQpDQooWEVOKSBbMjAxMi0wOS0yNCAw
NjozOToyOV0gIC0gTGFzdCBCcmFuY2ggUmVjb3JkIChMQlIpIFZpcnR1YWxpc2F0aW9uDQoo
WEVOKSBbMjAxMi0wOS0yNCAwNjozOToyOV0gIC0gTmV4dC1SSVAgU2F2ZWQgb24gI1ZNRVhJ
VA0KKFhFTikgWzIwMTItMDktMjQgMDY6Mzk6MjldICAtIFBhdXNlLUludGVyY2VwdCBGaWx0
ZXINCihYRU4pIFsyMDEyLTA5LTI0IDA2OjM5OjI5XSBIVk06IFNWTSBlbmFibGVkDQooWEVO
KSBbMjAxMi0wOS0yNCAwNjozOToyOV0gSFZNOiBIYXJkd2FyZSBBc3Npc3RlZCBQYWdpbmcg
KEhBUCkgZGV0ZWN0ZWQNCihYRU4pIFsyMDEyLTA5LTI0IDA2OjM5OjI5XSBIVk06IEhBUCBw
YWdlIHNpemVzOiA0a0IsIDJNQiwgMUdCDQooWEVOKSBbMjAxMi0wOS0yNCAwNjozOToyOF0g
bWFza2VkIEV4dElOVCBvbiBDUFUjMQ0KKFhFTikgWzIwMTItMDktMjQgMDY6Mzk6MjldIG1p
Y3JvY29kZTogY29sbGVjdF9jcHVfaW5mbzogcGF0Y2hfaWQ9MHgxMDAwMGJmDQooWEVOKSBb
MjAxMi0wOS0yNCAwNjozOToyOF0gbWFza2VkIEV4dElOVCBvbiBDUFUjMg0KKFhFTikgWzIw
MTItMDktMjQgMDY6Mzk6MjldIG1pY3JvY29kZTogY29sbGVjdF9jcHVfaW5mbzogcGF0Y2hf
aWQ9MHgxMDAwMGJmDQooWEVOKSBbMjAxMi0wOS0yNCAwNjozOToyOF0gbWFza2VkIEV4dElO
VCBvbiBDUFUjMw0KKFhFTikgWzIwMTItMDktMjQgMDY6Mzk6MjldIG1pY3JvY29kZTogY29s
bGVjdF9jcHVfaW5mbzogcGF0Y2hfaWQ9MHgxMDAwMGJmDQooWEVOKSBbMjAxMi0wOS0yNCAw
NjozOToyOF0gbWFza2VkIEV4dElOVCBvbiBDUFUjNA0KKFhFTikgWzIwMTItMDktMjQgMDY6
Mzk6MzBdIG1pY3JvY29kZTogY29sbGVjdF9jcHVfaW5mbzogcGF0Y2hfaWQ9MHgxMDAwMGJm
DQooWEVOKSBbMjAxMi0wOS0yNCAwNjozOToyOF0gbWFza2VkIEV4dElOVCBvbiBDUFUjNQ0K
KFhFTikgWzIwMTItMDktMjQgMDY6Mzk6MzBdIEJyb3VnaHQgdXAgNiBDUFVzDQooWEVOKSBb
MjAxMi0wOS0yNCAwNjozOTozMF0gbWljcm9jb2RlOiBjb2xsZWN0X2NwdV9pbmZvOiBwYXRj
aF9pZD0weDEwMDAwYmYNCihYRU4pIFsyMDEyLTA5LTI0IDA2OjM5OjMwXSBIUEVUJ3MgTVNJ
IG1vZGUgaGFzbid0IGJlZW4gc3VwcG9ydGVkIHdoZW4gSW50ZXJydXB0IFJlbWFwcGluZyBp
cyBlbmFibGVkLg0KKFhFTikgWzIwMTItMDktMjQgMDY6Mzk6MzBdIEFDUEkgc2xlZXAgbW9k
ZXM6IFMzDQooWEVOKSBbMjAxMi0wOS0yNCAwNjozOTozMF0gTUNBOiBVc2UgaHcgdGhyZXNo
b2xkaW5nIHRvIGFkanVzdCBwb2xsaW5nIGZyZXF1ZW5jeQ0KKFhFTikgWzIwMTItMDktMjQg
MDY6Mzk6MzBdIG1jaGVja19wb2xsOiBNYWNoaW5lIGNoZWNrIHBvbGxpbmcgdGltZXIgc3Rh
cnRlZC4NCihYRU4pIFsyMDEyLTA5LTI0IDA2OjM5OjMwXSBYZW5vcHJvZmlsZTogRmFpbGVk
IHRvIHNldHVwIElCUyBMVlQgb2Zmc2V0LCBJQlNDVEwgPSAweGZmZmZmZmZmDQooWEVOKSBb
MjAxMi0wOS0yNCAwNjozOTozMF0gKioqIExPQURJTkcgRE9NQUlOIDAgKioqDQooWEVOKSBb
MjAxMi0wOS0yNCAwNjozOTozMF0gZWxmX3BhcnNlX2JpbmFyeTogcGhkcjogcGFkZHI9MHgx
MDAwMDAwIG1lbXN6PTB4ZDZhMDAwDQooWEVOKSBbMjAxMi0wOS0yNCAwNjozOTozMF0gZWxm
X3BhcnNlX2JpbmFyeTogcGhkcjogcGFkZHI9MHgxZTAwMDAwIG1lbXN6PTB4ZGIwZTgNCihY
RU4pIFsyMDEyLTA5LTI0IDA2OjM5OjMwXSBlbGZfcGFyc2VfYmluYXJ5OiBwaGRyOiBwYWRk
cj0weDFlZGMwMDAgbWVtc3o9MHgxM2NjMA0KKFhFTikgWzIwMTItMDktMjQgMDY6Mzk6MzBd
IGVsZl9wYXJzZV9iaW5hcnk6IHBoZHI6IHBhZGRyPTB4MWVmMDAwMCBtZW1zej0weGRlNTAw
MA0KKFhFTikgWzIwMTItMDktMjQgMDY6Mzk6MzBdIGVsZl9wYXJzZV9iaW5hcnk6IG1lbW9y
eTogMHgxMDAwMDAwIC0+IDB4MmNkNTAwMA0KKFhFTikgWzIwMTItMDktMjQgMDY6Mzk6MzBd
IGVsZl94ZW5fcGFyc2Vfbm90ZTogR1VFU1RfT1MgPSAibGludXgiDQooWEVOKSBbMjAxMi0w
OS0yNCAwNjozOTozMF0gZWxmX3hlbl9wYXJzZV9ub3RlOiBHVUVTVF9WRVJTSU9OID0gIjIu
NiINCihYRU4pIFsyMDEyLTA5LTI0IDA2OjM5OjMwXSBlbGZfeGVuX3BhcnNlX25vdGU6IFhF
Tl9WRVJTSU9OID0gInhlbi0zLjAiDQooWEVOKSBbMjAxMi0wOS0yNCAwNjozOTozMF0gZWxm
X3hlbl9wYXJzZV9ub3RlOiBWSVJUX0JBU0UgPSAweGZmZmZmZmZmODAwMDAwMDANCihYRU4p
IFsyMDEyLTA5LTI0IDA2OjM5OjMwXSBlbGZfeGVuX3BhcnNlX25vdGU6IEVOVFJZID0gMHhm
ZmZmZmZmZjgxZWYwMjEwDQooWEVOKSBbMjAxMi0wOS0yNCAwNjozOTozMF0gZWxmX3hlbl9w
YXJzZV9ub3RlOiBIWVBFUkNBTExfUEFHRSA9IDB4ZmZmZmZmZmY4MTAwMTAwMA0KKFhFTikg
WzIwMTItMDktMjQgMDY6Mzk6MzBdIGVsZl94ZW5fcGFyc2Vfbm90ZTogRkVBVFVSRVMgPSAi
IXdyaXRhYmxlX3BhZ2VfdGFibGVzfHBhZV9wZ2Rpcl9hYm92ZV80Z2IiDQooWEVOKSBbMjAx
Mi0wOS0yNCAwNjozOTozMF0gZWxmX3hlbl9wYXJzZV9ub3RlOiBQQUVfTU9ERSA9ICJ5ZXMi
DQooWEVOKSBbMjAxMi0wOS0yNCAwNjozOTozMF0gZWxmX3hlbl9wYXJzZV9ub3RlOiBMT0FE
RVIgPSAiZ2VuZXJpYyINCihYRU4pIFsyMDEyLTA5LTI0IDA2OjM5OjMwXSBlbGZfeGVuX3Bh
cnNlX25vdGU6IHVua25vd24geGVuIGVsZiBub3RlICgweGQpDQooWEVOKSBbMjAxMi0wOS0y
NCAwNjozOTozMF0gZWxmX3hlbl9wYXJzZV9ub3RlOiBTVVNQRU5EX0NBTkNFTCA9IDB4MQ0K
KFhFTikgWzIwMTItMDktMjQgMDY6Mzk6MzBdIGVsZl94ZW5fcGFyc2Vfbm90ZTogSFZfU1RB
UlRfTE9XID0gMHhmZmZmODAwMDAwMDAwMDAwDQooWEVOKSBbMjAxMi0wOS0yNCAwNjozOToz
MF0gZWxmX3hlbl9wYXJzZV9ub3RlOiBQQUREUl9PRkZTRVQgPSAweDANCihYRU4pIFsyMDEy
LTA5LTI0IDA2OjM5OjMwXSBlbGZfeGVuX2FkZHJfY2FsY19jaGVjazogYWRkcmVzc2VzOg0K
KFhFTikgWzIwMTItMDktMjQgMDY6Mzk6MzBdICAgICB2aXJ0X2Jhc2UgICAgICAgID0gMHhm
ZmZmZmZmZjgwMDAwMDAwDQooWEVOKSBbMjAxMi0wOS0yNCAwNjozOTozMF0gICAgIGVsZl9w
YWRkcl9vZmZzZXQgPSAweDANCihYRU4pIFsyMDEyLTA5LTI0IDA2OjM5OjMwXSAgICAgdmly
dF9vZmZzZXQgICAgICA9IDB4ZmZmZmZmZmY4MDAwMDAwMA0KKFhFTikgWzIwMTItMDktMjQg
MDY6Mzk6MzBdICAgICB2aXJ0X2tzdGFydCAgICAgID0gMHhmZmZmZmZmZjgxMDAwMDAwDQoo
WEVOKSBbMjAxMi0wOS0yNCAwNjozOTozMF0gICAgIHZpcnRfa2VuZCAgICAgICAgPSAweGZm
ZmZmZmZmODJjZDUwMDANCihYRU4pIFsyMDEyLTA5LTI0IDA2OjM5OjMwXSAgICAgdmlydF9l
bnRyeSAgICAgICA9IDB4ZmZmZmZmZmY4MWVmMDIxMA0KKFhFTikgWzIwMTItMDktMjQgMDY6
Mzk6MzBdICAgICBwMm1fYmFzZSAgICAgICAgID0gMHhmZmZmZmZmZmZmZmZmZmZmDQooWEVO
KSBbMjAxMi0wOS0yNCAwNjozOTozMF0gIFhlbiAga2VybmVsOiA2NC1iaXQsIGxzYiwgY29t
cGF0MzINCihYRU4pIFsyMDEyLTA5LTI0IDA2OjM5OjMwXSAgRG9tMCBrZXJuZWw6IDY0LWJp
dCwgUEFFLCBsc2IsIHBhZGRyIDB4MTAwMDAwMCAtPiAweDJjZDUwMDANCihYRU4pIFsyMDEy
LTA5LTI0IDA2OjM5OjMwXSBQSFlTSUNBTCBNRU1PUlkgQVJSQU5HRU1FTlQ6DQooWEVOKSBb
MjAxMi0wOS0yNCAwNjozOTozMF0gIERvbTAgYWxsb2MuOiAgIDAwMDAwMDAyNDAwMDAwMDAt
PjAwMDAwMDAyNDQwMDAwMDAgKDI0MjQyOCBwYWdlcyB0byBiZSBhbGxvY2F0ZWQpDQooWEVO
KSBbMjAxMi0wOS0yNCAwNjozOTozMF0gIEluaXQuIHJhbWRpc2s6IDAwMDAwMDAyNGYyZmMw
MDAtPjAwMDAwMDAyNGZmZmY4MDANCihYRU4pIFsyMDEyLTA5LTI0IDA2OjM5OjMwXSBWSVJU
VUFMIE1FTU9SWSBBUlJBTkdFTUVOVDoNCihYRU4pIFsyMDEyLTA5LTI0IDA2OjM5OjMwXSAg
TG9hZGVkIGtlcm5lbDogZmZmZmZmZmY4MTAwMDAwMC0+ZmZmZmZmZmY4MmNkNTAwMA0KKFhF
TikgWzIwMTItMDktMjQgMDY6Mzk6MzBdICBJbml0LiByYW1kaXNrOiBmZmZmZmZmZjgyY2Q1
MDAwLT5mZmZmZmZmZjgzOWQ4ODAwDQooWEVOKSBbMjAxMi0wOS0yNCAwNjozOTozMF0gIFBo
eXMtTWFjaCBtYXA6IGZmZmZmZmZmODM5ZDkwMDAtPmZmZmZmZmZmODNiZDkwMDANCihYRU4p
IFsyMDEyLTA5LTI0IDA2OjM5OjMwXSAgU3RhcnQgaW5mbzogICAgZmZmZmZmZmY4M2JkOTAw
MC0+ZmZmZmZmZmY4M2JkOTRiNA0KKFhFTikgWzIwMTItMDktMjQgMDY6Mzk6MzBdICBQYWdl
IHRhYmxlczogICBmZmZmZmZmZjgzYmRhMDAwLT5mZmZmZmZmZjgzYmZkMDAwDQooWEVOKSBb
MjAxMi0wOS0yNCAwNjozOTozMF0gIEJvb3Qgc3RhY2s6ICAgIGZmZmZmZmZmODNiZmQwMDAt
PmZmZmZmZmZmODNiZmUwMDANCihYRU4pIFsyMDEyLTA5LTI0IDA2OjM5OjMwXSAgVE9UQUw6
ICAgICAgICAgZmZmZmZmZmY4MDAwMDAwMC0+ZmZmZmZmZmY4NDAwMDAwMA0KKFhFTikgWzIw
MTItMDktMjQgMDY6Mzk6MzBdICBFTlRSWSBBRERSRVNTOiBmZmZmZmZmZjgxZWYwMjEwDQoo
WEVOKSBbMjAxMi0wOS0yNCAwNjozOTozMF0gRG9tMCBoYXMgbWF4aW11bSA2IFZDUFVzDQoo
WEVOKSBbMjAxMi0wOS0yNCAwNjozOTozMF0gZWxmX2xvYWRfYmluYXJ5OiBwaGRyIDAgYXQg
MHhmZmZmZmZmZjgxMDAwMDAwIC0+IDB4ZmZmZmZmZmY4MWQ2YTAwMA0KKFhFTikgWzIwMTIt
MDktMjQgMDY6Mzk6MzBdIGVsZl9sb2FkX2JpbmFyeTogcGhkciAxIGF0IDB4ZmZmZmZmZmY4
MWUwMDAwMCAtPiAweGZmZmZmZmZmODFlZGIwZTgNCihYRU4pIFsyMDEyLTA5LTI0IDA2OjM5
OjMwXSBlbGZfbG9hZF9iaW5hcnk6IHBoZHIgMiBhdCAweGZmZmZmZmZmODFlZGMwMDAgLT4g
MHhmZmZmZmZmZjgxZWVmY2MwDQooWEVOKSBbMjAxMi0wOS0yNCAwNjozOTozMF0gZWxmX2xv
YWRfYmluYXJ5OiBwaGRyIDMgYXQgMHhmZmZmZmZmZjgxZWYwMDAwIC0+IDB4ZmZmZmZmZmY4
MWY4OTAwMA0KKFhFTikgWzIwMTItMDktMjQgMDY6Mzk6MzBdIEFNRC1WaTogU2V0dXAgSS9P
IHBhZ2UgdGFibGU6IGRldmljZSBpZCA9IDB4MDAwMCwgcm9vdCB0YWJsZSA9IDB4MjRkODRk
MDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMgfCAwIDAgMCAwDQooWEVOKSBbMjAx
Mi0wOS0yNCAwNjozOTozMF0gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNl
IGlkID0gMHgwMDAyLCByb290IHRhYmxlID0gMHgyNGQ4NGQwMDAsIGRvbWFpbiA9IDAsIHBh
Z2luZyBtb2RlID0gMyB8IDAgMCAwIDANCihYRU4pIFsyMDEyLTA5LTI0IDA2OjM5OjMwXSBB
TUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweDAwMTAsIHJvb3Qg
dGFibGUgPSAweDI0ZDg0ZDAwMCwgZG9tYWluID0gMCwgcGFnaW5nIG1vZGUgPSAzIHwgMCAw
IDAgMA0KKFhFTikgWzIwMTItMDktMjQgMDY6Mzk6MzBdIEFNRC1WaTogU2V0dXAgSS9PIHBh
Z2UgdGFibGU6IGRldmljZSBpZCA9IDB4MDAxOCwgcm9vdCB0YWJsZSA9IDB4MjRkODRkMDAw
LCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMgfCAwIDAgMCAwDQooWEVOKSBbMjAxMi0w
OS0yNCAwNjozOTozMF0gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlk
ID0gMHgwMDI4LCByb290IHRhYmxlID0gMHgyNGQ4NGQwMDAsIGRvbWFpbiA9IDAsIHBhZ2lu
ZyBtb2RlID0gMyB8IDAgMCAwIDANCihYRU4pIFsyMDEyLTA5LTI0IDA2OjM5OjMwXSBBTUQt
Vmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweDAwMzAsIHJvb3QgdGFi
bGUgPSAweDI0ZDg0ZDAwMCwgZG9tYWluID0gMCwgcGFnaW5nIG1vZGUgPSAzIHwgMCAwIDAg
MA0KKFhFTikgWzIwMTItMDktMjQgMDY6Mzk6MzBdIEFNRC1WaTogU2V0dXAgSS9PIHBhZ2Ug
dGFibGU6IGRldmljZSBpZCA9IDB4MDA1MCwgcm9vdCB0YWJsZSA9IDB4MjRkODRkMDAwLCBk
b21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMgfCAwIDAgMCAwDQooWEVOKSBbMjAxMi0wOS0y
NCAwNjozOTozMF0gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0g
MHgwMDU4LCByb290IHRhYmxlID0gMHgyNGQ4NGQwMDAsIGRvbWFpbiA9IDAsIHBhZ2luZyBt
b2RlID0gMyB8IDAgMCAwIDANCihYRU4pIFsyMDEyLTA5LTI0IDA2OjM5OjMwXSBBTUQtVmk6
IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweDAwNjgsIHJvb3QgdGFibGUg
PSAweDI0ZDg0ZDAwMCwgZG9tYWluID0gMCwgcGFnaW5nIG1vZGUgPSAzIHwgMCAwIDAgMA0K
KFhFTikgWzIwMTItMDktMjQgMDY6Mzk6MzBdIEFNRC1WaTogU2V0dXAgSS9PIHBhZ2UgdGFi
bGU6IGRldmljZSBpZCA9IDB4MDA4OCwgcm9vdCB0YWJsZSA9IDB4MjRkODRkMDAwLCBkb21h
aW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMgfCAwIDAgMCAwDQooWEVOKSBbMjAxMi0wOS0yNCAw
NjozOTozMV0gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHgw
MDkwLCByb290IHRhYmxlID0gMHgyNGQ4NGQwMDAsIGRvbWFpbiA9IDAsIHBhZ2luZyBtb2Rl
ID0gMyB8IDAgMCAwIDANCihYRU4pIFsyMDEyLTA5LTI0IDA2OjM5OjMxXSBBTUQtVmk6IFNl
dHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweDAwOTIsIHJvb3QgdGFibGUgPSAw
eDI0ZDg0ZDAwMCwgZG9tYWluID0gMCwgcGFnaW5nIG1vZGUgPSAzIHwgMCAwIDAgMA0KKFhF
TikgWzIwMTItMDktMjQgMDY6Mzk6MzFdIEFNRC1WaTogU2V0dXAgSS9PIHBhZ2UgdGFibGU6
IGRldmljZSBpZCA9IDB4MDA5OCwgcm9vdCB0YWJsZSA9IDB4MjRkODRkMDAwLCBkb21haW4g
PSAwLCBwYWdpbmcgbW9kZSA9IDMgfCAwIDAgMCAwDQooWEVOKSBbMjAxMi0wOS0yNCAwNjoz
OTozMV0gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHgwMDlh
LCByb290IHRhYmxlID0gMHgyNGQ4NGQwMDAsIGRvbWFpbiA9IDAsIHBhZ2luZyBtb2RlID0g
MyB8IDAgMCAwIDANCihYRU4pIFsyMDEyLTA5LTI0IDA2OjM5OjMxXSBBTUQtVmk6IFNldHVw
IEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweDAwYTAsIHJvb3QgdGFibGUgPSAweDI0
ZDg0ZDAwMCwgZG9tYWluID0gMCwgcGFnaW5nIG1vZGUgPSAzIHwgMCAwIDAgMA0KKFhFTikg
WzIwMTItMDktMjQgMDY6Mzk6MzFdIEFNRC1WaTogU2V0dXAgSS9PIHBhZ2UgdGFibGU6IGRl
dmljZSBpZCA9IDB4MDBhMSwgcm9vdCB0YWJsZSA9IDB4MjRkODRkMDAwLCBkb21haW4gPSAw
LCBwYWdpbmcgbW9kZSA9IDMgfCAwIDAgMCAwDQooWEVOKSBbMjAxMi0wOS0yNCAwNjozOToz
MV0gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHgwMGEyLCBy
b290IHRhYmxlID0gMHgyNGQ4NGQwMDAsIGRvbWFpbiA9IDAsIHBhZ2luZyBtb2RlID0gMyB8
IDAgMCAwIDANCihYRU4pIFsyMDEyLTA5LTI0IDA2OjM5OjMxXSBBTUQtVmk6IFNldHVwIEkv
TyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweDAwYTMsIHJvb3QgdGFibGUgPSAweDI0ZDg0
ZDAwMCwgZG9tYWluID0gMCwgcGFnaW5nIG1vZGUgPSAzIHwgMCAwIDAgMA0KKFhFTikgWzIw
MTItMDktMjQgMDY6Mzk6MzFdIEFNRC1WaTogU2V0dXAgSS9PIHBhZ2UgdGFibGU6IGRldmlj
ZSBpZCA9IDB4MDBhNCwgcm9vdCB0YWJsZSA9IDB4MjRkODRkMDAwLCBkb21haW4gPSAwLCBw
YWdpbmcgbW9kZSA9IDMgfCAwIDAgMCAwDQooWEVOKSBbMjAxMi0wOS0yNCAwNjozOTozMV0g
QU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHgwMGE1LCByb290
IHRhYmxlID0gMHgyNGQ4NGQwMDAsIGRvbWFpbiA9IDAsIHBhZ2luZyBtb2RlID0gMyB8IDAg
MCAwIDANCihYRU4pIFsyMDEyLTA5LTI0IDA2OjM5OjMxXSBBTUQtVmk6IFNldHVwIEkvTyBw
YWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweDAwYTgsIHJvb3QgdGFibGUgPSAweDI0ZDg0ZDAw
MCwgZG9tYWluID0gMCwgcGFnaW5nIG1vZGUgPSAzIHwgMCAwIDAgMA0KKFhFTikgWzIwMTIt
MDktMjQgMDY6Mzk6MzFdIEFNRC1WaTogU2V0dXAgSS9PIHBhZ2UgdGFibGU6IGRldmljZSBp
ZCA9IDB4MDBiMCwgcm9vdCB0YWJsZSA9IDB4MjRkODRkMDAwLCBkb21haW4gPSAwLCBwYWdp
bmcgbW9kZSA9IDMgfCAwIDAgMCAwDQooWEVOKSBbMjAxMi0wOS0yNCAwNjozOTozMV0gQU1E
LVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHgwMGIyLCByb290IHRh
YmxlID0gMHgyNGQ4NGQwMDAsIGRvbWFpbiA9IDAsIHBhZ2luZyBtb2RlID0gMyB8IDAgMCAw
IDANCihYRU4pIFsyMDEyLTA5LTI0IDA2OjM5OjMxXSBBTUQtVmk6IE5vIGlvbW11IGZvciBk
ZXZpY2UgMDAwMDowMDoxOC4wDQooWEVOKSBbMjAxMi0wOS0yNCAwNjozOTozMV0gQU1ELVZp
OiBObyBpb21tdSBmb3IgZGV2aWNlIDAwMDA6MDA6MTguMQ0KKFhFTikgWzIwMTItMDktMjQg
MDY6Mzk6MzFdIEFNRC1WaTogTm8gaW9tbXUgZm9yIGRldmljZSAwMDAwOjAwOjE4LjINCihY
RU4pIFsyMDEyLTA5LTI0IDA2OjM5OjMxXSBBTUQtVmk6IE5vIGlvbW11IGZvciBkZXZpY2Ug
MDAwMDowMDoxOC4zDQooWEVOKSBbMjAxMi0wOS0yNCAwNjozOTozMV0gQU1ELVZpOiBObyBp
b21tdSBmb3IgZGV2aWNlIDAwMDA6MDA6MTguNA0KKFhFTikgWzIwMTItMDktMjQgMDY6Mzk6
MzFdIEFNRC1WaTogU2V0dXAgSS9PIHBhZ2UgdGFibGU6IGRldmljZSBpZCA9IDB4MDQwMCwg
cm9vdCB0YWJsZSA9IDB4MjRkODRkMDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMg
fCAwIDAgMCAwDQooWEVOKSBbMjAxMi0wOS0yNCAwNjozOTozMV0gQU1ELVZpOiBTZXR1cCBJ
L08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHgwNDAxLCByb290IHRhYmxlID0gMHgyNGQ4
NGQwMDAsIGRvbWFpbiA9IDAsIHBhZ2luZyBtb2RlID0gMyB8IDAgMCAwIDANCihYRU4pIFsy
MDEyLTA5LTI0IDA2OjM5OjMxXSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZp
Y2UgaWQgPSAweDA0MDIsIHJvb3QgdGFibGUgPSAweDI0ZDg0ZDAwMCwgZG9tYWluID0gMCwg
cGFnaW5nIG1vZGUgPSAzIHwgMCAwIDAgMA0KKFhFTikgWzIwMTItMDktMjQgMDY6Mzk6MzFd
IEFNRC1WaTogU2V0dXAgSS9PIHBhZ2UgdGFibGU6IGRldmljZSBpZCA9IDB4MDQwMywgcm9v
dCB0YWJsZSA9IDB4MjRkODRkMDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMgfCAw
IDAgMCAwDQooWEVOKSBbMjAxMi0wOS0yNCAwNjozOTozMV0gQU1ELVZpOiBTZXR1cCBJL08g
cGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHgwNDA0LCByb290IHRhYmxlID0gMHgyNGQ4NGQw
MDAsIGRvbWFpbiA9IDAsIHBhZ2luZyBtb2RlID0gMyB8IDAgMCAwIDANCihYRU4pIFsyMDEy
LTA5LTI0IDA2OjM5OjMxXSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2Ug
aWQgPSAweDA0MDUsIHJvb3QgdGFibGUgPSAweDI0ZDg0ZDAwMCwgZG9tYWluID0gMCwgcGFn
aW5nIG1vZGUgPSAzIHwgMCAwIDAgMA0KKFhFTikgWzIwMTItMDktMjQgMDY6Mzk6MzFdIEFN
RC1WaTogU2V0dXAgSS9PIHBhZ2UgdGFibGU6IGRldmljZSBpZCA9IDB4MDQwNiwgcm9vdCB0
YWJsZSA9IDB4MjRkODRkMDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMgfCAwIDAg
MCAwDQooWEVOKSBbMjAxMi0wOS0yNCAwNjozOTozMV0gQU1ELVZpOiBTZXR1cCBJL08gcGFn
ZSB0YWJsZTogZGV2aWNlIGlkID0gMHgwNDA3LCByb290IHRhYmxlID0gMHgyNGQ4NGQwMDAs
IGRvbWFpbiA9IDAsIHBhZ2luZyBtb2RlID0gMyB8IDAgMCAwIDANCihYRU4pIFsyMDEyLTA5
LTI0IDA2OjM5OjMxXSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQg
PSAweDA1MDAsIHJvb3QgdGFibGUgPSAweDI0ZDg0ZDAwMCwgZG9tYWluID0gMCwgcGFnaW5n
IG1vZGUgPSAzIHwgMCAwIDAgMA0KKFhFTikgWzIwMTItMDktMjQgMDY6Mzk6MzFdIEFNRC1W
aTogU2V0dXAgSS9PIHBhZ2UgdGFibGU6IGRldmljZSBpZCA9IDB4MDUwMSwgcm9vdCB0YWJs
ZSA9IDB4MjRkODRkMDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMgfCAwIDAgMCAw
DQooWEVOKSBbMjAxMi0wOS0yNCAwNjozOTozMV0gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0
YWJsZTogZGV2aWNlIGlkID0gMHgwNjAwLCByb290IHRhYmxlID0gMHgyNGQ4NGQwMDAsIGRv
bWFpbiA9IDAsIHBhZ2luZyBtb2RlID0gMyB8IDAgMCAwIDANCihYRU4pIFsyMDEyLTA5LTI0
IDA2OjM5OjMxXSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAw
eDA3MDAsIHJvb3QgdGFibGUgPSAweDI0ZDg0ZDAwMCwgZG9tYWluID0gMCwgcGFnaW5nIG1v
ZGUgPSAzIHwgMCAwIDAgMA0KKFhFTikgWzIwMTItMDktMjQgMDY6Mzk6MzFdIEFNRC1WaTog
U2V0dXAgSS9PIHBhZ2UgdGFibGU6IGRldmljZSBpZCA9IDB4MDgwMCwgcm9vdCB0YWJsZSA9
IDB4MjRkODRkMDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMgfCAwIDAgMCAwDQoo
WEVOKSBbMjAxMi0wOS0yNCAwNjozOTozMV0gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJs
ZTogZGV2aWNlIGlkID0gMHgwOTAwLCByb290IHRhYmxlID0gMHgyNGQ4NGQwMDAsIGRvbWFp
biA9IDAsIHBhZ2luZyBtb2RlID0gMyB8IDAgMCAwIDANCihYRU4pIFsyMDEyLTA5LTI0IDA2
OjM5OjMxXSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweDA5
MDEsIHJvb3QgdGFibGUgPSAweDI0ZDg0ZDAwMCwgZG9tYWluID0gMCwgcGFnaW5nIG1vZGUg
PSAzIHwgMCAwIDAgMA0KKFhFTikgWzIwMTItMDktMjQgMDY6Mzk6MzFdIEFNRC1WaTogU2V0
dXAgSS9PIHBhZ2UgdGFibGU6IGRldmljZSBpZCA9IDB4MDkwMiwgcm9vdCB0YWJsZSA9IDB4
MjRkODRkMDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMgfCAwIDAgMCAwDQooWEVO
KSBbMjAxMi0wOS0yNCAwNjozOTozMV0gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTog
ZGV2aWNlIGlkID0gMHgwOTAzLCByb290IHRhYmxlID0gMHgyNGQ4NGQwMDAsIGRvbWFpbiA9
IDAsIHBhZ2luZyBtb2RlID0gMyB8IDAgMCAwIDANCihYRU4pIFsyMDEyLTA5LTI0IDA2OjM5
OjMxXSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweDA5MDQs
IHJvb3QgdGFibGUgPSAweDI0ZDg0ZDAwMCwgZG9tYWluID0gMCwgcGFnaW5nIG1vZGUgPSAz
IHwgMCAwIDAgMA0KKFhFTikgWzIwMTItMDktMjQgMDY6Mzk6MzFdIEFNRC1WaTogU2V0dXAg
SS9PIHBhZ2UgdGFibGU6IGRldmljZSBpZCA9IDB4MDkwNSwgcm9vdCB0YWJsZSA9IDB4MjRk
ODRkMDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMgfCAwIDAgMCAwDQooWEVOKSBb
MjAxMi0wOS0yNCAwNjozOTozMV0gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2
aWNlIGlkID0gMHgwOTA2LCByb290IHRhYmxlID0gMHgyNGQ4NGQwMDAsIGRvbWFpbiA9IDAs
IHBhZ2luZyBtb2RlID0gMyB8IDAgMCAwIDANCihYRU4pIFsyMDEyLTA5LTI0IDA2OjM5OjMx
XSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweDA5MDcsIHJv
b3QgdGFibGUgPSAweDI0ZDg0ZDAwMCwgZG9tYWluID0gMCwgcGFnaW5nIG1vZGUgPSAzIHwg
MCAwIDAgMA0KKFhFTikgWzIwMTItMDktMjQgMDY6Mzk6MzFdIEFNRC1WaTogU2V0dXAgSS9P
IHBhZ2UgdGFibGU6IGRldmljZSBpZCA9IDB4MGEwMCwgcm9vdCB0YWJsZSA9IDB4MjRkODRk
MDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMgfCAwIDAgMCAwDQooWEVOKSBbMjAx
Mi0wOS0yNCAwNjozOTozMV0gU2NydWJiaW5nIEZyZWUgUkFNOiAuLi4uLi4uLi4uLi4uLi4u
Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u
LmRvbmUuDQooWEVOKSBbMjAxMi0wOS0yNCAwNjozOTozM10gSW5pdGlhbCBsb3cgbWVtb3J5
IHZpcnEgdGhyZXNob2xkIHNldCBhdCAweDQwMDAgcGFnZXMuDQooWEVOKSBbMjAxMi0wOS0y
NCAwNjozOTozM10gU3RkLiBMb2dsZXZlbDogQWxsDQooWEVOKSBbMjAxMi0wOS0yNCAwNjoz
OTozM10gR3Vlc3QgTG9nbGV2ZWw6IEFsbA0KKFhFTikgWzIwMTItMDktMjQgMDY6Mzk6MzNd
IFhlbiBpcyByZWxpbnF1aXNoaW5nIFZHQSBjb25zb2xlLg0KKFhFTikgWzIwMTItMDktMjQg
MDY6Mzk6MzNdICoqKiBTZXJpYWwgaW5wdXQgLT4gRE9NMCAodHlwZSAnQ1RSTC1hJyB0aHJl
ZSB0aW1lcyB0byBzd2l0Y2ggaW5wdXQgdG8gWGVuKQ0KKFhFTikgWzIwMTItMDktMjQgMDY6
Mzk6MzNdIEZyZWVkIDI0NGtCIGluaXQgbWVtb3J5Lg0KKFhFTikgWzIwMTItMDktMjQgMDY6
Mzk6MzNdIElPQVBJQ1swXTogU2V0IFBDSSByb3V0aW5nIGVudHJ5ICg2LTkgLT4gMHg2MCAt
PiBJUlEgOSBNb2RlOjEgQWN0aXZlOjEpDQooWEVOKSBbMjAxMi0wOS0yNCAwNjozOTozM10g
dHJhcHMuYzoyNTA0OmQwIERvbWFpbiBhdHRlbXB0ZWQgV1JNU1IgMDAwMDAwMDBjMDAxMDAw
NCBmcm9tIDB4MDAwMGVmZjBmODczMWYxYyB0byAweDAwMDAwMDAwMDAwMGFiY2QuDQooWEVO
KSBbMjAxMi0wOS0yNCAwNjozOTozM10gUENJIGFkZCBkZXZpY2UgMDAwMDowMDowMC4wDQoo
WEVOKSBbMjAxMi0wOS0yNCAwNjozOTozM10gUENJIGFkZCBkZXZpY2UgMDAwMDowMDowMC4y
DQooWEVOKSBbMjAxMi0wOS0yNCAwNjozOTozM10gUENJIGFkZCBkZXZpY2UgMDAwMDowMDow
Mi4wDQooWEVOKSBbMjAxMi0wOS0yNCAwNjozOTozM10gUENJIGFkZCBkZXZpY2UgMDAwMDow
MDowMy4wDQooWEVOKSBbMjAxMi0wOS0yNCAwNjozOTozM10gUENJIGFkZCBkZXZpY2UgMDAw
MDowMDowNS4wDQooWEVOKSBbMjAxMi0wOS0yNCAwNjozOTozM10gUENJIGFkZCBkZXZpY2Ug
MDAwMDowMDowNi4wDQooWEVOKSBbMjAxMi0wOS0yNCAwNjozOTozM10gUENJIGFkZCBkZXZp
Y2UgMDAwMDowMDowYS4wDQooWEVOKSBbMjAxMi0wOS0yNCAwNjozOTozM10gUENJIGFkZCBk
ZXZpY2UgMDAwMDowMDowYi4wDQooWEVOKSBbMjAxMi0wOS0yNCAwNjozOTozM10gUENJIGFk
ZCBkZXZpY2UgMDAwMDowMDowZC4wDQooWEVOKSBbMjAxMi0wOS0yNCAwNjozOTozM10gUENJ
IGFkZCBkZXZpY2UgMDAwMDowMDoxMS4wDQooWEVOKSBbMjAxMi0wOS0yNCAwNjozOTozM10g
UENJIGFkZCBkZXZpY2UgMDAwMDowMDoxMi4wDQooWEVOKSBbMjAxMi0wOS0yNCAwNjozOToz
M10gUENJIGFkZCBkZXZpY2UgMDAwMDowMDoxMi4yDQooWEVOKSBbMjAxMi0wOS0yNCAwNjoz
OTozM10gUENJIGFkZCBkZXZpY2UgMDAwMDowMDoxMy4wDQooWEVOKSBbMjAxMi0wOS0yNCAw
NjozOTozM10gUENJIGFkZCBkZXZpY2UgMDAwMDowMDoxMy4yDQooWEVOKSBbMjAxMi0wOS0y
NCAwNjozOTozM10gUENJIGFkZCBkZXZpY2UgMDAwMDowMDoxNC4wDQooWEVOKSBbMjAxMi0w
OS0yNCAwNjozOTozM10gUENJIGFkZCBkZXZpY2UgMDAwMDowMDoxNC4xDQooWEVOKSBbMjAx
Mi0wOS0yNCAwNjozOTozM10gUENJIGFkZCBkZXZpY2UgMDAwMDowMDoxNC4yDQooWEVOKSBb
MjAxMi0wOS0yNCAwNjozOTozM10gUENJIGFkZCBkZXZpY2UgMDAwMDowMDoxNC4zDQooWEVO
KSBbMjAxMi0wOS0yNCAwNjozOTozM10gUENJIGFkZCBkZXZpY2UgMDAwMDowMDoxNC40DQoo
WEVOKSBbMjAxMi0wOS0yNCAwNjozOTozM10gUENJIGFkZCBkZXZpY2UgMDAwMDowMDoxNC41
DQooWEVOKSBbMjAxMi0wOS0yNCAwNjozOTozM10gUENJIGFkZCBkZXZpY2UgMDAwMDowMDox
NS4wDQooWEVOKSBbMjAxMi0wOS0yNCAwNjozOTozM10gUENJIGFkZCBkZXZpY2UgMDAwMDow
MDoxNi4wDQooWEVOKSBbMjAxMi0wOS0yNCAwNjozOTozM10gUENJIGFkZCBkZXZpY2UgMDAw
MDowMDoxNi4yDQooWEVOKSBbMjAxMi0wOS0yNCAwNjozOTozM10gUENJIGFkZCBkZXZpY2Ug
MDAwMDowMDoxOC4wDQooWEVOKSBbMjAxMi0wOS0yNCAwNjozOTozM10gUENJIGFkZCBkZXZp
Y2UgMDAwMDowMDoxOC4xDQooWEVOKSBbMjAxMi0wOS0yNCAwNjozOTozM10gUENJIGFkZCBk
ZXZpY2UgMDAwMDowMDoxOC4yDQooWEVOKSBbMjAxMi0wOS0yNCAwNjozOTozM10gUENJIGFk
ZCBkZXZpY2UgMDAwMDowMDoxOC4zDQooWEVOKSBbMjAxMi0wOS0yNCAwNjozOTozM10gUENJ
IGFkZCBkZXZpY2UgMDAwMDowMDoxOC40DQooWEVOKSBbMjAxMi0wOS0yNCAwNjozOTozM10g
UENJIGFkZCBkZXZpY2UgMDAwMDowYTowMC4wDQooWEVOKSBbMjAxMi0wOS0yNCAwNjozOToz
M10gUENJIGFkZCBkZXZpY2UgMDAwMDowOTowMC4wDQooWEVOKSBbMjAxMi0wOS0yNCAwNjoz
OTozM10gUENJIGFkZCBkZXZpY2UgMDAwMDowOTowMC4xDQooWEVOKSBbMjAxMi0wOS0yNCAw
NjozOTozM10gUENJIGFkZCBkZXZpY2UgMDAwMDowOTowMC4yDQooWEVOKSBbMjAxMi0wOS0y
NCAwNjozOTozM10gUENJIGFkZCBkZXZpY2UgMDAwMDowOTowMC4zDQooWEVOKSBbMjAxMi0w
OS0yNCAwNjozOTozM10gUENJIGFkZCBkZXZpY2UgMDAwMDowOTowMC40DQooWEVOKSBbMjAx
Mi0wOS0yNCAwNjozOTozM10gUENJIGFkZCBkZXZpY2UgMDAwMDowOTowMC41DQooWEVOKSBb
MjAxMi0wOS0yNCAwNjozOTozM10gUENJIGFkZCBkZXZpY2UgMDAwMDowOTowMC42DQooWEVO
KSBbMjAxMi0wOS0yNCAwNjozOTozM10gUENJIGFkZCBkZXZpY2UgMDAwMDowOTowMC43DQoo
WEVOKSBbMjAxMi0wOS0yNCAwNjozOTozM10gUENJIGFkZCBkZXZpY2UgMDAwMDowODowMC4w
DQooWEVOKSBbMjAxMi0wOS0yNCAwNjozOTozM10gUENJIGFkZCBkZXZpY2UgMDAwMDowNzow
MC4wDQooWEVOKSBbMjAxMi0wOS0yNCAwNjozOTozM10gUENJIGFkZCBkZXZpY2UgMDAwMDow
NjowMC4wDQooWEVOKSBbMjAxMi0wOS0yNCAwNjozOTozM10gUENJIGFkZCBkZXZpY2UgMDAw
MDowNTowMC4wDQooWEVOKSBbMjAxMi0wOS0yNCAwNjozOTozM10gUENJIGFkZCBkZXZpY2Ug
MDAwMDowNTowMC4xDQooWEVOKSBbMjAxMi0wOS0yNCAwNjozOTozM10gUENJIGFkZCBkZXZp
Y2UgMDAwMDowNDowMC4wDQooWEVOKSBbMjAxMi0wOS0yNCAwNjozOTozM10gUENJIGFkZCBk
ZXZpY2UgMDAwMDowNDowMC4xDQooWEVOKSBbMjAxMi0wOS0yNCAwNjozOTozM10gUENJIGFk
ZCBkZXZpY2UgMDAwMDowNDowMC4yDQooWEVOKSBbMjAxMi0wOS0yNCAwNjozOTozM10gUENJ
IGFkZCBkZXZpY2UgMDAwMDowNDowMC4zDQooWEVOKSBbMjAxMi0wOS0yNCAwNjozOTozM10g
UENJIGFkZCBkZXZpY2UgMDAwMDowNDowMC40DQooWEVOKSBbMjAxMi0wOS0yNCAwNjozOToz
M10gUENJIGFkZCBkZXZpY2UgMDAwMDowNDowMC41DQooWEVOKSBbMjAxMi0wOS0yNCAwNjoz
OTozM10gUENJIGFkZCBkZXZpY2UgMDAwMDowNDowMC42DQooWEVOKSBbMjAxMi0wOS0yNCAw
NjozOTozM10gUENJIGFkZCBkZXZpY2UgMDAwMDowNDowMC43DQooWEVOKSBbMjAxMi0wOS0y
NCAwNjozOTozM10gUENJIGFkZCBkZXZpY2UgMDAwMDowMzowNi4wDQooWEVOKSBbMjAxMi0w
OS0yNCAwNjozOTozM10gSU9BUElDWzBdOiBTZXQgUENJIHJvdXRpbmcgZW50cnkgKDYtOCAt
PiAweDU4IC0+IElSUSA4IE1vZGU6MCBBY3RpdmU6MCkNCihYRU4pIFsyMDEyLTA5LTI0IDA2
OjM5OjMzXSBJT0FQSUNbMF06IFNldCBQQ0kgcm91dGluZyBlbnRyeSAoNi0xMyAtPiAweDg4
IC0+IElSUSAxMyBNb2RlOjAgQWN0aXZlOjApDQooWEVOKSBbMjAxMi0wOS0yNCAwNjozOToz
M10gSU9BUElDWzFdOiBTZXQgUENJIHJvdXRpbmcgZW50cnkgKDctMjggLT4gMHhhMCAtPiBJ
UlEgNTIgTW9kZToxIEFjdGl2ZToxKQ0KKFhFTikgWzIwMTItMDktMjQgMDY6Mzk6MzNdIElP
QVBJQ1sxXTogU2V0IFBDSSByb3V0aW5nIGVudHJ5ICg3LTI5IC0+IDB4YTggLT4gSVJRIDUz
IE1vZGU6MSBBY3RpdmU6MSkNCihYRU4pIFsyMDEyLTA5LTI0IDA2OjM5OjMzXSBJT0FQSUNb
MV06IFNldCBQQ0kgcm91dGluZyBlbnRyeSAoNy0zMCAtPiAweGIwIC0+IElSUSA1NCBNb2Rl
OjEgQWN0aXZlOjEpDQooWEVOKSBbMjAxMi0wOS0yNCAwNjozOTozM10gSU9BUElDWzBdOiBT
ZXQgUENJIHJvdXRpbmcgZW50cnkgKDYtMTYgLT4gMHhiOCAtPiBJUlEgMTYgTW9kZToxIEFj
dGl2ZToxKQ0KKFhFTikgWzIwMTItMDktMjQgMDY6Mzk6MzNdIElPQVBJQ1swXTogU2V0IFBD
SSByb3V0aW5nIGVudHJ5ICg2LTE4IC0+IDB4YzAgLT4gSVJRIDE4IE1vZGU6MSBBY3RpdmU6
MSkNCihYRU4pIFsyMDEyLTA5LTI0IDA2OjM5OjM0XSBJT0FQSUNbMF06IFNldCBQQ0kgcm91
dGluZyBlbnRyeSAoNi0xNyAtPiAweGM4IC0+IElSUSAxNyBNb2RlOjEgQWN0aXZlOjEpDQoo
WEVOKSBbMjAxMi0wOS0yNCAwNjozOTozNF0gSU9BUElDWzFdOiBTZXQgUENJIHJvdXRpbmcg
ZW50cnkgKDctNCAtPiAweGQwIC0+IElSUSAyOCBNb2RlOjEgQWN0aXZlOjEpDQooWEVOKSBb
MjAxMi0wOS0yNCAwNjozOTozNF0gSU9BUElDWzFdOiBTZXQgUENJIHJvdXRpbmcgZW50cnkg
KDctNSAtPiAweGQ4IC0+IElSUSAyOSBNb2RlOjEgQWN0aXZlOjEpDQooWEVOKSBbMjAxMi0w
OS0yNCAwNjozOTozNF0gSU9BUElDWzFdOiBTZXQgUENJIHJvdXRpbmcgZW50cnkgKDctNiAt
PiAweDIxIC0+IElSUSAzMCBNb2RlOjEgQWN0aXZlOjEpDQooWEVOKSBbMjAxMi0wOS0yNCAw
NjozOTozNF0gSU9BUElDWzFdOiBTZXQgUENJIHJvdXRpbmcgZW50cnkgKDctNyAtPiAweDI5
IC0+IElSUSAzMSBNb2RlOjEgQWN0aXZlOjEpDQooWEVOKSBbMjAxMi0wOS0yNCAwNjozOToz
NF0gSU9BUElDWzFdOiBTZXQgUENJIHJvdXRpbmcgZW50cnkgKDctMTYgLT4gMHgzMSAtPiBJ
UlEgNDAgTW9kZToxIEFjdGl2ZToxKQ0KKFhFTikgWzIwMTItMDktMjQgMDY6Mzk6MzRdIElP
QVBJQ1sxXTogU2V0IFBDSSByb3V0aW5nIGVudHJ5ICg3LTE3IC0+IDB4MzkgLT4gSVJRIDQx
IE1vZGU6MSBBY3RpdmU6MSkNCihYRU4pIFsyMDEyLTA5LTI0IDA2OjM5OjM0XSBJT0FQSUNb
MV06IFNldCBQQ0kgcm91dGluZyBlbnRyeSAoNy0xOCAtPiAweDQxIC0+IElSUSA0MiBNb2Rl
OjEgQWN0aXZlOjEpDQooWEVOKSBbMjAxMi0wOS0yNCAwNjozOTozNF0gSU9BUElDWzFdOiBT
ZXQgUENJIHJvdXRpbmcgZW50cnkgKDctMTkgLT4gMHg0OSAtPiBJUlEgNDMgTW9kZToxIEFj
dGl2ZToxKQ0KKFhFTikgWzIwMTItMDktMjQgMDY6Mzk6MzRdIElPQVBJQ1swXTogU2V0IFBD
SSByb3V0aW5nIGVudHJ5ICg2LTIyIC0+IDB4OTEgLT4gSVJRIDIyIE1vZGU6MSBBY3RpdmU6
MSkNCihYRU4pIFsyMDEyLTA5LTI0IDA2OjM5OjM0XSBJT0FQSUNbMV06IFNldCBQQ0kgcm91
dGluZyBlbnRyeSAoNy0yMyAtPiAweDk5IC0+IElSUSA0NyBNb2RlOjEgQWN0aXZlOjEpDQoo
WEVOKSBbMjAxMi0wOS0yNCAwNjozOTozNF0gSU9BUElDWzBdOiBTZXQgUENJIHJvdXRpbmcg
ZW50cnkgKDYtMTkgLT4gMHhhMSAtPiBJUlEgMTkgTW9kZToxIEFjdGl2ZToxKQ0KKFhFTikg
WzIwMTItMDktMjQgMDY6Mzk6MzVdIElPQVBJQ1sxXTogU2V0IFBDSSByb3V0aW5nIGVudHJ5
ICg3LTIyIC0+IDB4YjEgLT4gSVJRIDQ2IE1vZGU6MSBBY3RpdmU6MSkNCihYRU4pIFsyMDEy
LTA5LTI0IDA2OjM5OjM1XSBJT0FQSUNbMV06IFNldCBQQ0kgcm91dGluZyBlbnRyeSAoNy0y
NyAtPiAweGMxIC0+IElSUSA1MSBNb2RlOjEgQWN0aXZlOjEpDQooWEVOKSBbMjAxMi0wOS0y
NCAwNjozOTozNl0gSU9BUElDWzFdOiBTZXQgUENJIHJvdXRpbmcgZW50cnkgKDctOSAtPiAw
eGQxIC0+IElSUSAzMyBNb2RlOjEgQWN0aXZlOjEpDQooWEVOKSBbMjAxMi0wOS0yNCAwNjo0
MDo0Ml0gdHJhcHMuYzoyNTA0OmQxIERvbWFpbiBhdHRlbXB0ZWQgV1JNU1IgMDAwMDAwMDBj
MDAxMDAwNCBmcm9tIDB4MDAwMDAwMDAwN2ZiZmMwMCB0byAweDAwMDAwMDAwMDAwMGFiY2Qu
DQooWEVOKSBbMjAxMi0wOS0yNCAwNjo0MDo0OF0gdHJhcHMuYzoyNTA0OmQyIERvbWFpbiBh
dHRlbXB0ZWQgV1JNU1IgMDAwMDAwMDBjMDAxMDAwNCBmcm9tIDB4MDAwMGY1ZjAyOWRlNjgw
MCB0byAweDAwMDAwMDAwMDAwMGFiY2QuDQooWEVOKSBbMjAxMi0wOS0yNCAwNjo0MDo1NF0g
dHJhcHMuYzoyNTA0OmQzIERvbWFpbiBhdHRlbXB0ZWQgV1JNU1IgMDAwMDAwMDBjMDAxMDAw
NCBmcm9tIDB4MDAwMDgwNzZjMGU5NDA2MyB0byAweDAwMDAwMDAwMDAwMGFiY2QuDQooWEVO
KSBbMjAxMi0wOS0yNCAwNjo0MTowMV0gdHJhcHMuYzoyNTA0OmQ0IERvbWFpbiBhdHRlbXB0
ZWQgV1JNU1IgMDAwMDAwMDBjMDAxMDAwNCBmcm9tIDB4MDAwMDBjYjQ0NmMyYTMwNSB0byAw
eDAwMDAwMDAwMDAwMGFiY2QuDQooWEVOKSBbMjAxMi0wOS0yNCAwNjo0MTowN10gdHJhcHMu
YzoyNTA0OmQ1IERvbWFpbiBhdHRlbXB0ZWQgV1JNU1IgMDAwMDAwMDBjMDAxMDAwNCBmcm9t
IDB4MDAwMDAwMDAwN2ZiZmMwMCB0byAweDAwMDAwMDAwMDAwMGFiY2QuDQooWEVOKSBbMjAx
Mi0wOS0yNCAwNjo0MToxNF0gdHJhcHMuYzoyNTA0OmQ2IERvbWFpbiBhdHRlbXB0ZWQgV1JN
U1IgMDAwMDAwMDBjMDAxMDAwNCBmcm9tIDB4MDAwMGY1ZjAyOWRlNjgwMCB0byAweDAwMDAw
MDAwMDAwMGFiY2QuDQooWEVOKSBbMjAxMi0wOS0yNCAwNjo0MToyMF0gdHJhcHMuYzoyNTA0
OmQ3IERvbWFpbiBhdHRlbXB0ZWQgV1JNU1IgMDAwMDAwMDBjMDAxMDAwNCBmcm9tIDB4MDAw
MDgwNzZjMGU5NDA2MyB0byAweDAwMDAwMDAwMDAwMGFiY2QuDQooWEVOKSBbMjAxMi0wOS0y
NCAwNjo0MToyNV0gdHJhcHMuYzoyNTA0OmQ4IERvbWFpbiBhdHRlbXB0ZWQgV1JNU1IgMDAw
MDAwMDBjMDAxMDAwNCBmcm9tIDB4MDAwMDAwMDAwN2ZiZmMwMCB0byAweDAwMDAwMDAwMDAw
MGFiY2QuDQooWEVOKSBbMjAxMi0wOS0yNCAwNjo0MTozMV0gdHJhcHMuYzoyNTA0OmQ5IERv
bWFpbiBhdHRlbXB0ZWQgV1JNU1IgMDAwMDAwMDBjMDAxMDAwNCBmcm9tIDB4MDAwMDgwNzZj
MGU5NDA2MyB0byAweDAwMDAwMDAwMDAwMGFiY2QuDQooWEVOKSBbMjAxMi0wOS0yNCAwNjo0
MTozOF0gdHJhcHMuYzoyNTA0OmQxMCBEb21haW4gYXR0ZW1wdGVkIFdSTVNSIDAwMDAwMDAw
YzAwMTAwMDQgZnJvbSAweDAwMDAwMDAwMDdmYmZjMDAgdG8gMHgwMDAwMDAwMDAwMDBhYmNk
Lg0KKFhFTikgWzIwMTItMDktMjQgMDY6NDE6NDhdIEFNRC1WaTogYW1kX2lvbW11X2Fzc2ln
bl9kZXZpY2U6IGQ6MTEgMDAwMDowMzowNi4wIDAgMA0KKFhFTikgWzIwMTItMDktMjQgMDY6
NDE6NDhdIEFNRC1WaTogRGlzYWJsZTogZGV2aWNlIGlkID0gMHgwMGE0LCBkb21haW4gPSAw
LCBwYWdpbmcgbW9kZSA9IDMNCihYRU4pIFsyMDEyLTA5LTI0IDA2OjQxOjQ4XSBBTUQtVmk6
IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweDAwYTQsIHJvb3QgdGFibGUg
PSAweDE4ZTBhNTAwMCwgZG9tYWluID0gMTEsIHBhZ2luZyBtb2RlID0gMyB8IDAgMCAwIDAN
CihYRU4pIFsyMDEyLTA5LTI0IDA2OjQxOjQ4XSBBTUQtVmk6IFJlLWFzc2lnbiAwMDAwOjAz
OjA2LjAgZnJvbSBkb20wIHRvIGRvbTExIDAgMCAwIDANCihYRU4pIFsyMDEyLTA5LTI0IDA2
OjQxOjQ5XSB0cmFwcy5jOjI1MDQ6ZDExIERvbWFpbiBhdHRlbXB0ZWQgV1JNU1IgMDAwMDAw
MDBjMDAxMDAwNCBmcm9tIDB4MDAwMDgwNzZjMGU5NDA2MyB0byAweDAwMDAwMDAwMDAwMGFi
Y2QuDQooWEVOKSBbMjAxMi0wOS0yNCAwNjo0MTo1NV0gdHJhcHMuYzoyNTA0OmQxMiBEb21h
aW4gYXR0ZW1wdGVkIFdSTVNSIDAwMDAwMDAwYzAwMTAwMDQgZnJvbSAweDAwMDAwY2I0NDZj
MmEzMDUgdG8gMHgwMDAwMDAwMDAwMDBhYmNkLg0KKFhFTikgWzIwMTItMDktMjQgMDY6NDI6
MDFdIHRyYXBzLmM6MjUwNDpkMTMgRG9tYWluIGF0dGVtcHRlZCBXUk1TUiAwMDAwMDAwMGMw
MDEwMDA0IGZyb20gMHgwMDAwODA3NmMwZTk0MDYzIHRvIDB4MDAwMDAwMDAwMDAwYWJjZC4N
CihYRU4pIFsyMDEyLTA5LTI0IDA2OjQyOjA4XSB0cmFwcy5jOjI1MDQ6ZDE0IERvbWFpbiBh
dHRlbXB0ZWQgV1JNU1IgMDAwMDAwMDBjMDAxMDAwNCBmcm9tIDB4MDAwMDgwNzZjMGU5NDA2
MyB0byAweDAwMDAwMDAwMDAwMGFiY2QuDQooWEVOKSBbMjAxMi0wOS0yNCAwNjo0NDoxNl0g
dHJhcHMuYzozMDYyOiBHUEYgKDAwNjApOiBmZmZmODJjNDgwMTVlNjllIC0+IGZmZmY4MmM0
ODAyMjYyZTMNCihYRU4pIFsyMDEyLTA5LTI0IDA2OjQ4OjEzXSB0cmFwcy5jOjMwNjI6IEdQ
RiAoMDA2MCk6IGZmZmY4MmM0ODAxNWU2OWUgLT4gZmZmZjgyYzQ4MDIyNjJlMw0KKFhFTikg
WzIwMTItMDktMjQgMDY6NDk6MjNdIHRyYXBzLmM6MzA2MjogR1BGICgwMDYwKTogZmZmZjgy
YzQ4MDE1ZTY5ZSAtPiBmZmZmODJjNDgwMjI2MmUzDQooWEVOKSBbMjAxMi0wOS0yNCAwODoy
NToyMV0gQU1ELVZpOiBTaGFyZSBwMm0gdGFibGUgd2l0aCBpb21tdTogZG9tYWluOjE1IHAy
bSB0YWJsZSA9IDB4MWMxZjk0DQooWEVOKSBbMjAxMi0wOS0yNCAwODoyNToyMl0gW1ZULURd
aW8uYzoyODI6IGQxNTogYmluZDogbV9nc2k9MTYgZ19nc2k9MzYgZGV2aWNlPTUgaW50eD0w
DQooWEVOKSBbMjAxMi0wOS0yNCAwODoyNToyMl0gQU1ELVZpOiBhbWRfaW9tbXVfYXNzaWdu
X2RldmljZTogZDoxNSAwMDAwOjA2OjAwLjAgMCAwDQooWEVOKSBbMjAxMi0wOS0yNCAwODoy
NToyMl0gQU1ELVZpOiBEaXNhYmxlOiBkZXZpY2UgaWQgPSAweDA2MDAsIGRvbWFpbiA9IDAs
IHBhZ2luZyBtb2RlID0gMw0KKFhFTikgWzIwMTItMDktMjQgMDg6MjU6MjJdIEFNRC1WaTog
U2V0dXAgSS9PIHBhZ2UgdGFibGU6IGRldmljZSBpZCA9IDB4MDYwMCwgcm9vdCB0YWJsZSA9
IDB4MWMxZjk0MDAwLCBkb21haW4gPSAxNSwgcGFnaW5nIG1vZGUgPSA0IHwgMCAwIDAgMA0K
KFhFTikgWzIwMTItMDktMjQgMDg6MjU6MjJdIEFNRC1WaTogUmUtYXNzaWduIDAwMDA6MDY6
MDAuMCBmcm9tIGRvbTAgdG8gZG9tMTUgMCAwIDAgMA0KKFhFTikgWzIwMTItMDktMjQgMDg6
MjU6MjJdIEhWTTE1OiBIVk0gTG9hZGVyDQooWEVOKSBbMjAxMi0wOS0yNCAwODoyNToyMl0g
SFZNMTU6IERldGVjdGVkIFhlbiB2NC4zLXVuc3RhYmxlDQooWEVOKSBbMjAxMi0wOS0yNCAw
ODoyNToyMl0gSFZNMTU6IFhlbmJ1cyByaW5ncyBAMHhmZWZmYzAwMCwgZXZlbnQgY2hhbm5l
bCA1DQooWEVOKSBbMjAxMi0wOS0yNCAwODoyNToyMl0gSFZNMTU6IFN5c3RlbSByZXF1ZXN0
ZWQgUk9NQklPUw0KKFhFTikgWzIwMTItMDktMjQgMDg6MjU6MjJdIEhWTTE1OiBDUFUgc3Bl
ZWQgaXMgMzIwMCBNSHoNCihYRU4pIFsyMDEyLTA5LTI0IDA4OjI1OjIyXSBpcnEuYzoyNzA6
IERvbTE1IFBDSSBsaW5rIDAgY2hhbmdlZCAwIC0+IDUNCihYRU4pIFsyMDEyLTA5LTI0IDA4
OjI1OjIyXSBIVk0xNTogUENJLUlTQSBsaW5rIDAgcm91dGVkIHRvIElSUTUNCihYRU4pIFsy
MDEyLTA5LTI0IDA4OjI1OjIyXSBpcnEuYzoyNzA6IERvbTE1IFBDSSBsaW5rIDEgY2hhbmdl
ZCAwIC0+IDEwDQooWEVOKSBbMjAxMi0wOS0yNCAwODoyNToyMl0gSFZNMTU6IFBDSS1JU0Eg
bGluayAxIHJvdXRlZCB0byBJUlExMA0KKFhFTikgWzIwMTItMDktMjQgMDg6MjU6MjJdIGly
cS5jOjI3MDogRG9tMTUgUENJIGxpbmsgMiBjaGFuZ2VkIDAgLT4gMTENCihYRU4pIFsyMDEy
LTA5LTI0IDA4OjI1OjIyXSBIVk0xNTogUENJLUlTQSBsaW5rIDIgcm91dGVkIHRvIElSUTEx
DQooWEVOKSBbMjAxMi0wOS0yNCAwODoyNToyMl0gaXJxLmM6MjcwOiBEb20xNSBQQ0kgbGlu
ayAzIGNoYW5nZWQgMCAtPiA1DQooWEVOKSBbMjAxMi0wOS0yNCAwODoyNToyMl0gSFZNMTU6
IFBDSS1JU0EgbGluayAzIHJvdXRlZCB0byBJUlE1DQooWEVOKSBbMjAxMi0wOS0yNCAwODoy
NToyMl0gSFZNMTU6IHBjaSBkZXYgMDE6MiBJTlRELT5JUlE1DQooWEVOKSBbMjAxMi0wOS0y
NCAwODoyNToyMl0gSFZNMTU6IHBjaSBkZXYgMDE6MyBJTlRBLT5JUlExMA0KKFhFTikgWzIw
MTItMDktMjQgMDg6MjU6MjJdIEhWTTE1OiBwY2kgZGV2IDAzOjAgSU5UQS0+SVJRNQ0KKFhF
TikgWzIwMTItMDktMjQgMDg6MjU6MjJdIEhWTTE1OiBwY2kgZGV2IDA0OjAgSU5UQS0+SVJR
NQ0KKFhFTikgWzIwMTItMDktMjQgMDg6MjU6MjJdIEhWTTE1OiBwY2kgZGV2IDA1OjAgSU5U
QS0+SVJRMTANCihYRU4pIFsyMDEyLTA5LTI0IDA4OjI1OjIyXSBIVk0xNTogcGNpIGRldiAw
MjowIGJhciAxMCBzaXplIDAyMDAwMDAwOiBmMDAwMDAwOA0KKFhFTikgWzIwMTItMDktMjQg
MDg6MjU6MjJdIEhWTTE1OiBwY2kgZGV2IDAzOjAgYmFyIDE0IHNpemUgMDEwMDAwMDA6IGYy
MDAwMDA4DQooWEVOKSBbMjAxMi0wOS0yNCAwODoyNToyMl0gSFZNMTU6IHBjaSBkZXYgMDU6
MCBiYXIgMTAgc2l6ZSAwMDIwMDAwMDogZjMwMDAwMDQNCihYRU4pIFsyMDEyLTA5LTI0IDA4
OjI1OjIyXSBtZW1vcnlfbWFwOmFkZDogZG9tMTUgZ2ZuPWYzMDAwIG1mbj1mOWEwMCBucj0y
MDANCihYRU4pIFsyMDEyLTA5LTI0IDA4OjI1OjIyXSBIVk0xNTogcGNpIGRldiAwNDowIGJh
ciAxMCBzaXplIDAwMDIwMDAwOiBmMzIwMDAwMA0KKFhFTikgWzIwMTItMDktMjQgMDg6MjU6
MjJdIEhWTTE1OiBwY2kgZGV2IDAyOjAgYmFyIDE0IHNpemUgMDAwMDEwMDA6IGYzMjIwMDAw
DQooWEVOKSBbMjAxMi0wOS0yNCAwODoyNToyMl0gSFZNMTU6IHBjaSBkZXYgMDM6MCBiYXIg
MTAgc2l6ZSAwMDAwMDEwMDogMDAwMGMwMDENCihYRU4pIFsyMDEyLTA5LTI0IDA4OjI1OjIy
XSBIVk0xNTogcGNpIGRldiAwNDowIGJhciAxNCBzaXplIDAwMDAwMDQwOiAwMDAwYzEwMQ0K
KFhFTikgWzIwMTItMDktMjQgMDg6MjU6MjJdIEhWTTE1OiBwY2kgZGV2IDAxOjIgYmFyIDIw
IHNpemUgMDAwMDAwMjA6IDAwMDBjMTQxDQooWEVOKSBbMjAxMi0wOS0yNCAwODoyNToyMl0g
SFZNMTU6IHBjaSBkZXYgMDE6MSBiYXIgMjAgc2l6ZSAwMDAwMDAxMDogMDAwMGMxNjENCihY
RU4pIFsyMDEyLTA5LTI0IDA4OjI1OjIyXSBIVk0xNTogTXVsdGlwcm9jZXNzb3IgaW5pdGlh
bGlzYXRpb246DQooWEVOKSBbMjAxMi0wOS0yNCAwODoyNToyMl0gSFZNMTU6ICAtIENQVTAg
Li4uIDQ4LWJpdCBwaHlzIC4uLiBmaXhlZCBNVFJScyAuLi4gdmFyIE1UUlJzIFsyLzhdIC4u
LiBkb25lLg0KKFhFTikgWzIwMTItMDktMjQgMDg6MjU6MjJdIEhWTTE1OiAgLSBDUFUxIC4u
LiA0OC1iaXQgcGh5cyAuLi4gZml4ZWQgTVRSUnMgLi4uIHZhciBNVFJScyBbMi84XSAuLi4g
ZG9uZS4NCihYRU4pIFsyMDEyLTA5LTI0IDA4OjI1OjIyXSBIVk0xNTogIC0gQ1BVMiAuLi4g
NDgtYml0IHBoeXMgLi4uIGZpeGVkIE1UUlJzIC4uLiB2YXIgTVRSUnMgWzIvOF0gLi4uIGRv
bmUuDQooWEVOKSBbMjAxMi0wOS0yNCAwODoyNToyMl0gSFZNMTU6IFRlc3RpbmcgSFZNIGVu
dmlyb25tZW50Og0KKFhFTikgWzIwMTItMDktMjQgMDg6MjU6MjJdIEhWTTE1OiAgLSBSRVAg
SU5TQiBhY3Jvc3MgcGFnZSBib3VuZGFyaWVzIC4uLiBwYXNzZWQNCihYRU4pIFsyMDEyLTA5
LTI0IDA4OjI1OjIyXSBIVk0xNTogIC0gR1MgYmFzZSBNU1JzIGFuZCBTV0FQR1MgLi4uIHBh
c3NlZA0KKFhFTikgWzIwMTItMDktMjQgMDg6MjU6MjJdIEhWTTE1OiBQYXNzZWQgMiBvZiAy
IHRlc3RzDQooWEVOKSBbMjAxMi0wOS0yNCAwODoyNToyMl0gSFZNMTU6IFdyaXRpbmcgU01C
SU9TIHRhYmxlcyAuLi4NCihYRU4pIFsyMDEyLTA5LTI0IDA4OjI1OjIyXSBIVk0xNTogTG9h
ZGluZyBST01CSU9TIC4uLg0KKFhFTikgWzIwMTItMDktMjQgMDg6MjU6MjJdIEhWTTE1OiA5
NjYwIGJ5dGVzIG9mIFJPTUJJT1MgaGlnaC1tZW1vcnkgZXh0ZW5zaW9uczoNCihYRU4pIFsy
MDEyLTA5LTI0IDA4OjI1OjIyXSBIVk0xNTogICBSZWxvY2F0aW5nIHRvIDB4ZmMwMDEwMDAt
MHhmYzAwMzViYyAuLi4gZG9uZQ0KKFhFTikgWzIwMTItMDktMjQgMDg6MjU6MjJdIEhWTTE1
OiBDcmVhdGluZyBNUCB0YWJsZXMgLi4uDQooWEVOKSBbMjAxMi0wOS0yNCAwODoyNToyMl0g
SFZNMTU6IExvYWRpbmcgQ2lycnVzIFZHQUJJT1MgLi4uDQooWEVOKSBbMjAxMi0wOS0yNCAw
ODoyNToyMl0gSFZNMTU6IExvYWRpbmcgUENJIE9wdGlvbiBST00gLi4uDQooWEVOKSBbMjAx
Mi0wOS0yNCAwODoyNToyMl0gSFZNMTU6ICAtIE1hbnVmYWN0dXJlcjogaHR0cDovL2lweGUu
b3JnDQooWEVOKSBbMjAxMi0wOS0yNCAwODoyNToyMl0gSFZNMTU6ICAtIFByb2R1Y3QgbmFt
ZTogaVBYRQ0KKFhFTikgWzIwMTItMDktMjQgMDg6MjU6MjJdIEhWTTE1OiBPcHRpb24gUk9N
czoNCihYRU4pIFsyMDEyLTA5LTI0IDA4OjI1OjIyXSBIVk0xNTogIGMwMDAwLWM4ZmZmOiBW
R0EgQklPUw0KKFhFTikgWzIwMTItMDktMjQgMDg6MjU6MjJdIEhWTTE1OiAgYzkwMDAtZDlm
ZmY6IEV0aGVyYm9vdCBST00NCihYRU4pIFsyMDEyLTA5LTI0IDA4OjI1OjIyXSBIVk0xNTog
TG9hZGluZyBBQ1BJIC4uLg0KKFhFTikgWzIwMTItMDktMjQgMDg6MjU6MjJdIEhWTTE1OiB2
bTg2IFRTUyBhdCBmYzAwZjY4MA0KKFhFTikgWzIwMTItMDktMjQgMDg6MjU6MjJdIEhWTTE1
OiBCSU9TIG1hcDoNCihYRU4pIFsyMDEyLTA5LTI0IDA4OjI1OjIyXSBIVk0xNTogIGYwMDAw
LWZmZmZmOiBNYWluIEJJT1MNCihYRU4pIFsyMDEyLTA5LTI0IDA4OjI1OjIyXSBIVk0xNTog
RTgyMCB0YWJsZToNCihYRU4pIFsyMDEyLTA5LTI0IDA4OjI1OjIyXSBIVk0xNTogIFswMF06
IDAwMDAwMDAwOjAwMDAwMDAwIC0gMDAwMDAwMDA6MDAwOWUwMDA6IFJBTQ0KKFhFTikgWzIw
MTItMDktMjQgMDg6MjU6MjJdIEhWTTE1OiAgWzAxXTogMDAwMDAwMDA6MDAwOWUwMDAgLSAw
MDAwMDAwMDowMDBhMDAwMDogUkVTRVJWRUQNCihYRU4pIFsyMDEyLTA5LTI0IDA4OjI1OjIy
XSBIVk0xNTogIEhPTEU6IDAwMDAwMDAwOjAwMGEwMDAwIC0gMDAwMDAwMDA6MDAwZTAwMDAN
CihYRU4pIFsyMDEyLTA5LTI0IDA4OjI1OjIyXSBIVk0xNTogIFswMl06IDAwMDAwMDAwOjAw
MGUwMDAwIC0gMDAwMDAwMDA6MDAxMDAwMDA6IFJFU0VSVkVEDQooWEVOKSBbMjAxMi0wOS0y
NCAwODoyNToyMl0gSFZNMTU6ICBbMDNdOiAwMDAwMDAwMDowMDEwMDAwMCAtIDAwMDAwMDAw
OjNmODAwMDAwOiBSQU0NCihYRU4pIFsyMDEyLTA5LTI0IDA4OjI1OjIyXSBIVk0xNTogIEhP
TEU6IDAwMDAwMDAwOjNmODAwMDAwIC0gMDAwMDAwMDA6ZmMwMDAwMDANCihYRU4pIFsyMDEy
LTA5LTI0IDA4OjI1OjIyXSBIVk0xNTogIFswNF06IDAwMDAwMDAwOmZjMDAwMDAwIC0gMDAw
MDAwMDE6MDAwMDAwMDA6IFJFU0VSVkVEDQooWEVOKSBbMjAxMi0wOS0yNCAwODoyNToyMl0g
SFZNMTU6IEludm9raW5nIFJPTUJJT1MgLi4uDQooWEVOKSBbMjAxMi0wOS0yNCAwODoyNToy
Ml0gSFZNMTU6ICRSZXZpc2lvbjogMS4yMjEgJCAkRGF0ZTogMjAwOC8xMi8wNyAxNzozMjoy
OSAkDQooWEVOKSBbMjAxMi0wOS0yNCAwODoyNToyM10gc3RkdmdhLmM6MTQ3OmQxNSBlbnRl
cmluZyBzdGR2Z2EgYW5kIGNhY2hpbmcgbW9kZXMNCihYRU4pIFsyMDEyLTA5LTI0IDA4OjI1
OjIzXSBIVk0xNTogVkdBQmlvcyAkSWQ6IHZnYWJpb3MuYyx2IDEuNjcgMjAwOC8wMS8yNyAw
OTo0NDoxMiB2cnVwcGVydCBFeHAgJA0KKFhFTikgWzIwMTItMDktMjQgMDg6MjU6MjNdIEhW
TTE1OiBCb2NocyBCSU9TIC0gYnVpbGQ6IDA2LzIzLzk5DQooWEVOKSBbMjAxMi0wOS0yNCAw
ODoyNToyM10gSFZNMTU6ICRSZXZpc2lvbjogMS4yMjEgJCAkRGF0ZTogMjAwOC8xMi8wNyAx
NzozMjoyOSAkDQooWEVOKSBbMjAxMi0wOS0yNCAwODoyNToyM10gSFZNMTU6IE9wdGlvbnM6
IGFwbWJpb3MgcGNpYmlvcyBlbHRvcml0byBQTU0gDQooWEVOKSBbMjAxMi0wOS0yNCAwODoy
NToyM10gSFZNMTU6IA0KKFhFTikgWzIwMTItMDktMjQgMDg6MjU6MjNdIEhWTTE1OiBhdGEw
LTA6IFBDSFM9MTYzODMvMTYvNjMgdHJhbnNsYXRpb249bGJhIExDSFM9MTAyNC8yNTUvNjMN
CihYRU4pIFsyMDEyLTA5LTI0IDA4OjI1OjIzXSBIVk0xNTogYXRhMCBtYXN0ZXI6IFFFTVUg
SEFSRERJU0sgQVRBLTcgSGFyZC1EaXNrICg4MTkyIE1CeXRlcykNCihYRU4pIFsyMDEyLTA5
LTI0IDA4OjI1OjIzXSBIVk0xNTogYXRhMC0xOiBQQ0hTPTEwNDAvMTYvNjMgdHJhbnNsYXRp
b249bGJhIExDSFM9MTAyNC8xNi82Mw0KKFhFTikgWzIwMTItMDktMjQgMDg6MjU6MjNdIEhW
TTE1OiBhdGEwICBzbGF2ZTogUUVNVSBIQVJERElTSyBBVEEtNyBIYXJkLURpc2sgKCA1MTIg
TUJ5dGVzKQ0KKFhFTikgWzIwMTItMDktMjQgMDg6MjU6MjNdIEhWTTE1OiBhdGExLTA6IFBD
SFM9MTYzODMvMTYvNjMgdHJhbnNsYXRpb249bGJhIExDSFM9MTAyNC8yNTUvNjMNCihYRU4p
IFsyMDEyLTA5LTI0IDA4OjI1OjIzXSBIVk0xNTogYXRhMSBtYXN0ZXI6IFFFTVUgSEFSRERJ
U0sgQVRBLTcgSGFyZC1EaXNrICggMzAwIEdCeXRlcykNCihYRU4pIFsyMDEyLTA5LTI0IDA4
OjI1OjI0XSBIVk0xNTogSURFIHRpbWUgb3V0DQooWEVOKSBbMjAxMi0wOS0yNCAwODoyNToy
NF0gSFZNMTU6IA0KKFhFTikgWzIwMTItMDktMjQgMDg6MjU6MjRdIEhWTTE1OiANCihYRU4p
IFsyMDEyLTA5LTI0IDA4OjI1OjI0XSBIVk0xNTogDQooWEVOKSBbMjAxMi0wOS0yNCAwODoy
NToyNF0gSFZNMTU6IFByZXNzIEYxMiBmb3IgYm9vdCBtZW51Lg0KKFhFTikgWzIwMTItMDkt
MjQgMDg6MjU6MjRdIEhWTTE1OiANCihYRU4pIFsyMDEyLTA5LTI0IDA4OjI1OjI0XSBIVk0x
NTogQm9vdGluZyBmcm9tIEhhcmQgRGlzay4uLg0KKFhFTikgWzIwMTItMDktMjQgMDg6MjU6
MjRdIEhWTTE1OiBCb290aW5nIGZyb20gMDAwMDo3YzAwDQooWEVOKSBbMjAxMi0wOS0yNCAw
ODoyNToyNV0gc3RkdmdhLmM6MTUxOmQxNSBsZWF2aW5nIHN0ZHZnYQ0KKFhFTikgWzIwMTIt
MDktMjQgMDg6MjU6MzJdIHN0ZHZnYS5jOjE0NzpkMTUgZW50ZXJpbmcgc3RkdmdhIGFuZCBj
YWNoaW5nIG1vZGVzDQooWEVOKSBbMjAxMi0wOS0yNCAwODoyNTozM10gaXJxLmM6Mzc1OiBE
b20xNSBjYWxsYmFjayB2aWEgY2hhbmdlZCB0byBEaXJlY3QgVmVjdG9yIDB4ZjMNCihYRU4p
IFsyMDEyLTA5LTI0IDA4OjI1OjMzXSBtZW1vcnlfbWFwOnJlbW92ZTogZG9tMTUgZ2ZuPWYz
MDAwIG1mbj1mOWEwMCBucj0yMDANCihYRU4pIFsyMDEyLTA5LTI0IDA4OjI1OjMzXSBtZW1v
cnlfbWFwOmFkZDogZG9tMTUgZ2ZuPWYzMDAwIG1mbj1mOWEwMCBucj0yMDANCihYRU4pIFsy
MDEyLTA5LTI0IDA4OjI1OjMzXSBtZW1vcnlfbWFwOnJlbW92ZTogZG9tMTUgZ2ZuPWYzMDAw
IG1mbj1mOWEwMCBucj0yMDANCihYRU4pIFsyMDEyLTA5LTI0IDA4OjI1OjMzXSBtZW1vcnlf
bWFwOmFkZDogZG9tMTUgZ2ZuPWYzMDAwIG1mbj1mOWEwMCBucj0yMDANCihYRU4pIFsyMDEy
LTA5LTI0IDA4OjI1OjMzXSBtZW1vcnlfbWFwOnJlbW92ZTogZG9tMTUgZ2ZuPWYzMDAwIG1m
bj1mOWEwMCBucj0yMDANCihYRU4pIFsyMDEyLTA5LTI0IDA4OjI1OjMzXSBtZW1vcnlfbWFw
OmFkZDogZG9tMTUgZ2ZuPWYzMDAwIG1mbj1mOWEwMCBucj0yMDANCihYRU4pIFsyMDEyLTA5
LTI0IDA4OjI1OjMzXSBtZW1vcnlfbWFwOnJlbW92ZTogZG9tMTUgZ2ZuPWYzMDAwIG1mbj1m
OWEwMCBucj0yMDANCihYRU4pIFsyMDEyLTA5LTI0IDA4OjI1OjMzXSBtZW1vcnlfbWFwOmFk
ZDogZG9tMTUgZ2ZuPWYzMDAwIG1mbj1mOWEwMCBucj0yMDANCihYRU4pIFsyMDEyLTA5LTI0
IDA4OjI1OjMzXSBtZW1vcnlfbWFwOnJlbW92ZTogZG9tMTUgZ2ZuPWYzMDAwIG1mbj1mOWEw
MCBucj0yMDANCihYRU4pIFsyMDEyLTA5LTI0IDA4OjI1OjMzXSBtZW1vcnlfbWFwOmFkZDog
ZG9tMTUgZ2ZuPWYzMDAwIG1mbj1mOWEwMCBucj0yMDANCihYRU4pIFsyMDEyLTA5LTI0IDA4
OjI1OjMzXSBtZW1vcnlfbWFwOnJlbW92ZTogZG9tMTUgZ2ZuPWYzMDAwIG1mbj1mOWEwMCBu
cj0yMDANCihYRU4pIFsyMDEyLTA5LTI0IDA4OjI1OjMzXSBtZW1vcnlfbWFwOmFkZDogZG9t
MTUgZ2ZuPWYzMDAwIG1mbj1mOWEwMCBucj0yMDANCihYRU4pIFsyMDEyLTA5LTI0IDA4OjI1
OjM0XSBpcnEuYzoyNzA6IERvbTE1IFBDSSBsaW5rIDAgY2hhbmdlZCA1IC0+IDANCihYRU4p
IFsyMDEyLTA5LTI0IDA4OjI1OjM0XSBpcnEuYzoyNzA6IERvbTE1IFBDSSBsaW5rIDEgY2hh
bmdlZCAxMCAtPiAwDQooWEVOKSBbMjAxMi0wOS0yNCAwODoyNTozNF0gaXJxLmM6MjcwOiBE
b20xNSBQQ0kgbGluayAyIGNoYW5nZWQgMTEgLT4gMA0KKFhFTikgWzIwMTItMDktMjQgMDg6
MjU6MzRdIGlycS5jOjI3MDogRG9tMTUgUENJIGxpbmsgMyBjaGFuZ2VkIDUgLT4gMA0K
------------0E41640F726FFA493
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

------------0E41640F726FFA493--



From xen-devel-bounces@lists.xen.org Mon Sep 24 08:39:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Sep 2012 08: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 1TG4Bk-0008B2-8t; Mon, 24 Sep 2012 08:38:48 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <linux@eikelenboom.it>) id 1TG4Bg-0008Aa-Tv
	for xen-devel@lists.xensource.com; Mon, 24 Sep 2012 08:38:47 +0000
Received: from [85.158.138.51:33415] by server-9.bemta-3.messagelabs.com id
	F5/E2-15390-41C10605; Mon, 24 Sep 2012 08:38:44 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-14.tower-174.messagelabs.com!1348475917!25377149!1
X-Originating-IP: [188.40.164.121]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15970 invoked from network); 24 Sep 2012 08:38:37 -0000
Received: from static.121.164.40.188.clients.your-server.de (HELO
	smtp.eikelenboom.it) (188.40.164.121)
	by server-14.tower-174.messagelabs.com with AES256-SHA encrypted SMTP;
	24 Sep 2012 08:38:37 -0000
Received: from 132-64-ftth.onsneteindhoven.nl ([88.159.64.132]:50420
	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 1TG4CI-0002ri-2W; Mon, 24 Sep 2012 10:39:22 +0200
Date: Mon, 24 Sep 2012 10:38:35 +0200
From: Sander Eikelenboom <linux@eikelenboom.it>
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <74647167.20120924103835@eikelenboom.it>
To: Wei Wang <wei.wang2@amd.com>
In-Reply-To: <5049B650.4080101@amd.com>
References: <504764E2.4000809@amd.com>
	<326589347.20120906005936@eikelenboom.it>
	<5048A603.3070207@amd.com>
	<483486315.20120906155001@eikelenboom.it>
	<5048BB29.4040900@amd.com>
	<488803362.20120907093241@eikelenboom.it>
	<5049B650.4080101@amd.com>
MIME-Version: 1.0
Content-Type: multipart/mixed;
 boundary="----------0E41640F726FFA493"
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH] amd iommu: Dump flags of IO page faults
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

------------0E41640F726FFA493
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit


Friday, September 7, 2012, 10:54:40 AM, you wrote:

> On 09/07/2012 09:32 AM, Sander Eikelenboom wrote:
>>
>> Thursday, September 6, 2012, 5:03:05 PM, you wrote:
>>
>>> On 09/06/2012 03:50 PM, Sander Eikelenboom wrote:
>>>>
>>>> Thursday, September 6, 2012, 3:32:51 PM, you wrote:
>>>>
>>>>> On 09/06/2012 12:59 AM, Sander Eikelenboom wrote:
>>>>>>
>>>>>> Wednesday, September 5, 2012, 4:42:42 PM, you wrote:
>>>>>>
>>>>>>> Hi Jan,
>>>>>>> Attached patch dumps io page fault flags. The flags show the reason of
>>>>>>> the fault and tell us if this is an unmapped interrupt fault or a DMA fault.
>>>>>>
>>>>>>> Thanks,
>>>>>>> Wei
>>>>>>
>>>>>>> signed-off-by: Wei Wang<wei.wang2@amd.com>
>>>>>>
>>>>>>
>>>>>> I have applied the patch and the flags seem to differ between the faults:
>>>>>>
>>>>>> AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0a06, fault address = 0xc2c2c2c0, flags = 0x000
>>>>>> (XEN) [2012-09-05 20:54:16] AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0a06, fault address = 0xc2c2c2c0, flags = 0x000
>>>>>> (XEN) [2012-09-05 20:54:16] AMD-Vi: IO_PAGE_FAULT: domain = 14, device id = 0x0700, fault address = 0xa8d339e0, flags = 0x020
>>>>>> (XEN) [2012-09-05 20:54:16] AMD-Vi: IO_PAGE_FAULT: domain = 14, device id = 0x0700, fault address = 0xa8d33a40, flags = 0x020
>>>>
>>>>> OK, so they are not interrupt requests. I guess further information from
>>>>> your system would be helpful to debug this issue:
>>>>> 1) xl info
>>>>> 2) xl list
>>>>> 3) lscpi -vvv (NOTE: not in dom0 but in your guest)
>>>>> 4) cat /proc/iomem (in both dom0 and your hvm guest)
>>>>
>>>> dom14 is not a HVM guest,it's a PV guest.
>>
>>> Ah, I see. PV guest is quite different than hvm, it does use p2m tables
>>> as io page tables. So no-sharept option does not work in this case. PV
>>> guests always use separated io page tables. There might be some
>>> incorrect mappings on the page tables. I will check this on my side.
>>
>> I have reverted the machine to xen-4.1.4-pre (changeset 23353) and kept everything else the same.
>> I haven't seen any IO PAGE FAULTS after that.
>>
>> I did spot some differences in the output from lspci between xen 4.1 and 4.2, related to MSI enabled or not for the IOMMU device.
>> Have attached the xl/xm dmesg and lspci from booting with both versions.
>>
>> lspci:
>>
>> 00:00.2 Generic system peripheral [0806]: ATI Technologies Inc RD990 I/O Memory Management Unit (IOMMU) [1002:5a23]
>>          Subsystem: ATI Technologies Inc RD990 I/O Memory Management Unit (IOMMU) [1002:5a23]
>>          Control: I/O- Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
>>          Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast>TAbort-<TAbort-<MAbort->SERR-<PERR- INTx-
>>          Latency: 0
>>          Interrupt: pin A routed to IRQ 10
>>          Capabilities: [40] Secure device<?>
>> 4.1:    Capabilities: [54] MSI: Enable- Count=1/1 Maskable- 64bit+

> Eh... That is interesting. So which dom0 are you using?  There is a c/s 
> in 4.2 to prevent recent dom0 to disable iommu interrupt (changeset 
> 25492:61844569a432) Otherwise, iommu cannot send any events including IO 
> PAGE faults. You could try to revert dom0 to an old version like 2.6 
> pv_ops to see if you really have no io page faults on 4.1

Ok i finally got the time to do some more testing, tested 4.2 around that changeset, and made a copy of the guest using HVM instead of PV.

The results:
- On xen-4.1.* and a 3.6-rc6 kernel (dom0 and domU):  the video device passed through works fine, both in a HVM as a PV guest, i don't see IO page faults getting reported.
- On xen-4.2 changeset <  25492 and a 3.6-rc6 kernel (dom0 and domU):  the video device passed through works fine, both in a HVM as a PV guest, i don't see IO page faults getting reported.
- On xen-4.2 changeset >  25492 and a 3.6-rc6 kernel (dom0 and domU): the video device passed through works fine for a short while (around 5 to 10 minutes) in a PV guest, after that IO page faults get reported and the video freezes, i don't see any errors in the guest though.
- On xen-unstable tip and a 3.6-rc6 kernel (dom0 and domU):
                                                      PV:  the video device passed through works fine for a short while (around 5 to 10 minutes), after that IO page faults get reported and the video freezes, i don't see any errors in the guest though.
                                                      HVM: the video device passed through doesn't work from the start:
                                                                     - The device is there according to lspci
                                                                     - The video application start fine, but delivers a green image, so the device is not working properly. I don't see IO page faults though.

Attached are (all with xen-unstable tip and the guest as HVM (domain 15):
- xl dmesg
- Patch which adds some more info, but all values reported seem to be zero (see xl dmesg)
- lspci dom0
- lspci HVM guest




>> 4.2:    Capabilities: [54] MSI: Enable+ Count=1/1 Maskable- 64bit+
>>                  Address: 00000000fee0100c  Data: 4128
>>          Capabilities: [64] HyperTransport: MSI Mapping Enable+ Fixed+
>>
>> Although it seems enabled, shouldn't the IRQ number used be much higher than 10 for MSI interrupts ?

> The IRQ number is fine. MSI vector is stored at  Data: 4128

>>
>> There is another difference in the bridge device that's in front of the  0a:00.6 device that faults before the kernel is even booted.
>>
>> 00:03.0 PCI bridge [0604]: ATI Technologies Inc RD890 PCI to PCI bridge (PCI express gpp port C) [1002:5a17] (prog-if 00 [Normal decode])
>>          Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx+
>> 4.1:    Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast>TAbort-<TAbort-<MAbort->SERR-<PERR- INTx-
>> 4.2:    Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast>TAbort-<TAbort+<MAbort->SERR-<PERR- INTx-
>>          Latency: 0, Cache Line Size: 64 bytes
>>          Bus: primary=00, secondary=0a, subordinate=0a, sec-latency=0
>>          I/O behind bridge: 0000f000-00000fff
>>          Memory behind bridge: f9f00000-f9ffffff
>>          Prefetchable memory behind bridge: 00000000fff00000-00000000000fffff
>> 4.1:    Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast>TAbort-<TAbort-<MAbort-<SERR-<PERR-
>> 4.2:    Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast>TAbort+<TAbort-<MAbort-<SERR-<PERR-
>>          BridgeCtl: Parity+ SERR+ NoISA+ VGA- MAbort->Reset- FastB2B-
>>                  PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
>>          Capabilities: [50] Power Management version 3
>>                  Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
>>                  Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
>>          Capabilities: [58] Express (v2) Root Port (Slot+), MSI 00
>>                  DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s<64ns, L1<1us
>>                          ExtTag+ RBE+ FLReset-
>>                  DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
>>                          RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+
>>                          MaxPayload 128 bytes, MaxReadReq 128 bytes
>>                  DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr- TransPend-
>>                  LnkCap: Port #1, Speed 5GT/s, Width x8, ASPM L0s L1, Latency L0<1us, L1<8us
>>                          ClockPM- Surprise- LLActRep+ BwNot+
>>                  LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommClk-
>>                          ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
>>                  LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive+ BWMgmt+ ABWMgmt-
>>                  SltCap: AttnBtn- PwrCtrl- MRL- AttnInd- PwrInd- HotPlug- Surprise-
>>                          Slot #3, PowerLimit 10.000W; Interlock- NoCompl+
>>                  SltCtl: Enable: AttnBtn- PwrFlt- MRL- PresDet- CmdCplt- HPIrq- LinkChg-
>>                          Control: AttnInd Unknown, PwrInd Unknown, Power- Interlock-
>>                  SltSta: Status: AttnBtn- PowerFlt- MRL- CmdCplt- PresDet+ Interlock-
>>                          Changed: MRL- PresDet+ LinkState+

> The probably because of the IO_PAGE_FAULT.

> Thanks,
> Wei

>> serveerstertje:~# lspci -t
>> -[0000:00]-+-00.0
>>             +-00.2
>>             +-02.0-[0b]----00.0
>>             +-03.0-[0a]--+-00.0
>>             |            +-00.1
>>             |            +-00.2
>>             |            +-00.3
>>             |            +-00.4
>>             |            +-00.5
>>             |            +-00.6
>>             |            \-00.7
>>             +-05.0-[09]----00.0
>>             +-06.0-[08]----00.0
>>             +-0a.0-[07]----00.0
>>             +-0b.0-[06]--+-00.0
>>             |            \-00.1
>>             +-0c.0-[05]----00.0
>>             +-0d.0-[04]--+-00.0
>>             |            +-00.1
>>             |            +-00.2
>>             |            +-00.3
>>             |            +-00.4
>>             |            +-00.5
>>             |            +-00.6
>>             |            \-00.7
>>             +-11.0
>>             +-12.0
>>             +-12.2
>>             +-13.0
>>             +-13.2
>>             +-14.0
>>             +-14.3
>>             +-14.4-[03]----06.0
>>             +-14.5
>>             +-15.0-[02]--
>>             +-16.0
>>             +-16.2
>>             +-18.0
>>             +-18.1
>>             +-18.2
>>             +-18.3
>>             \-18.4
>>
>>
>>
>>
>>
>>> Thanks,
>>> Wei
>>
>>>> I will try to make a complete package, and try with one pv domain only where the devices are being passed through just to simplify the setup.
>>>>
>>>>
>>>>> * I would also like to know the symptoms of device 0x0700 when IO_PF
>>>>> happened. Did it stop working?
>>>>
>>>> Yes it stops working, the video capture just freezes, but the driver doesn't bail out.
>>>> For the USB controller (0x0a06) it starts to give errors for usbdev_open in the guest.
>>>>
>>>>> (BTW: I copied a few options from your boot cmd line and it worked with
>>>>> my RD890 system
>>>>
>>>>> dom0_mem=1024M,max:1024M loglvl=all loglvl_guest=all console_timestamps
>>>>> cpuidle cpufreq=xen noreboot debug lapic=debug apic_verbosity=debug
>>>>> apic=debug iommu=on,verbose,debug,no-sharept
>>>>
>>>>> * so, what OEM board you have?)
>>>>
>>>> MSI 890FXA-GD70
>>>>
>>>>> Also from your log, these lines looks very strange:
>>>>
>>>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>>>>> read-only memory page. gfn=0xd5, mfn=0xa4a11
>>>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>>>>> read-only memory page. gfn=0xd7, mfn=0xa4a0f
>>>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>>>>> read-only memory page. gfn=0xd9, mfn=0xa4a0d
>>>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>>>>> read-only memory page. gfn=0xdb, mfn=0xa4a0b
>>>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>>>>> read-only memory page. gfn=0xdd, mfn=0xa4a09
>>>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>>>>> read-only memory page. gfn=0xdf, mfn=0xa4a07
>>>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>>>>> read-only memory page. gfn=0xe1, mfn=0xa4a05
>>>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>>>>> read-only memory page. gfn=0xe3, mfn=0xa4a03
>>>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>>>>> read-only memory page. gfn=0xe5, mfn=0xa4a01
>>>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>>>>> read-only memory page. gfn=0xe7, mfn=0xa463f
>>>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>>>>> read-only memory page. gfn=0xe9, mfn=0xa463d
>>>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>>>>> read-only memory page. gfn=0xeb, mfn=0xa463b
>>>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>>>>> read-only memory page. gfn=0xed, mfn=0xa4639
>>>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>>>>> read-only memory page. gfn=0xef, mfn=0xa4637
>>>>> (XEN) [2012-09-04 16:13:56] AMD-Vi: IO_PAGE_FAULT: domain = 0, device id
>>>>> = 0x0a06, fault address = 0xc2c2c2c0
>>>>> (XEN) [2012-09-04 16:13:56] AMD-Vi: IO_PAGE_FAULT: domain = 14, device
>>>>> id = 0x0700, fault address = 0xa90f8300
>>>>> (XEN) [2012-09-04 16:13:56] AMD-Vi: IO_PAGE_FAULT: domain = 14, device
>>>>> id = 0x0700, fault address = 0xa90f8340
>>>>> (XEN) [2012-09-04 16:13:56] AMD-Vi: IO_PAGE_FAULT: domain = 14, device
>>>>> id = 0x0700, fault address = 0xa90f8380
>>>>> (XEN) [2012-09-04 16:13:56] AMD-Vi: IO_PAGE_FAULT: domain = 14, device
>>>>> id = 0x0700, fault address = 0xa90f83c0
>>>>
>>>>> * they are just followed by the IO PAGE fault. Do you know where are
>>>>> they from? Your video card driver maybe?
>>>>
>>>>    From a HVM domain with a old (3.0.3) kernel, but the faults also occur without this domain being started.
>>>>
>>>>
>>>>> Thanks,
>>>>> Wei
>>>>
>>>>
>>>>>> Complete xl dmesg and lspci -vvvknn attached.
>>>>>>
>>>>>> Thx
>>>>>>
>>>>>> --
>>>>>> Sander
>>>>
>>>>
>>>>
>>>>
>>>>
>>
>>



------------0E41640F726FFA493
Content-Type: text/plain;
 name="lspci-dom0.txt"
Content-transfer-encoding: base64
Content-Disposition: attachment;
 filename="lspci-dom0.txt"

MDA6MDAuMCBIb3N0IGJyaWRnZSBbMDYwMF06IEFUSSBUZWNobm9sb2dpZXMgSW5jIFJEODkw
IE5vcnRoYnJpZGdlIG9ubHkgc2luZ2xlIHNsb3QgUENJLWUgR0ZYIEh5ZHJhIHBhcnQgWzEw
MDI6NWExMV0gKHJldiAwMikNCglTdWJzeXN0ZW06IEFUSSBUZWNobm9sb2dpZXMgSW5jIFJE
ODkwIE5vcnRoYnJpZGdlIG9ubHkgc2luZ2xlIHNsb3QgUENJLWUgR0ZYIEh5ZHJhIHBhcnQg
WzEwMDI6NWExMV0NCglDb250cm9sOiBJL08tIE1lbSsgQnVzTWFzdGVyLSBTcGVjQ3ljbGUt
IE1lbVdJTlYtIFZHQVNub29wLSBQYXJFcnItIFN0ZXBwaW5nLSBTRVJSLSBGYXN0QjJCLSBE
aXNJTlR4LQ0KCVN0YXR1czogQ2FwKyA2Nk1Iei0gVURGLSBGYXN0QjJCLSBQYXJFcnItIERF
VlNFTD1mYXN0ID5UQWJvcnQtIDxUQWJvcnQtIDxNQWJvcnQrID5TRVJSLSA8UEVSUi0gSU5U
eC0NCglDYXBhYmlsaXRpZXM6IFtmMF0gSHlwZXJUcmFuc3BvcnQ6IE1TSSBNYXBwaW5nIEVu
YWJsZSsgRml4ZWQrDQoJQ2FwYWJpbGl0aWVzOiBbYzRdIEh5cGVyVHJhbnNwb3J0OiBTbGF2
ZSBvciBQcmltYXJ5IEludGVyZmFjZQ0KCQlDb21tYW5kOiBCYXNlVW5pdElEPTAgVW5pdENu
dD0yMCBNYXN0SG9zdC0gRGVmRGlyLSBEVUwtDQoJCUxpbmsgQ29udHJvbCAwOiBDRmxFLSBD
U1QtIENGRS0gPExrRmFpbC0gSW5pdCsgRU9DLSBUWE8tIDxDUkNFcnI9MCBJc29jRW4tIExT
RW4tIEV4dENUTC0gNjRiLQ0KCQlMaW5rIENvbmZpZyAwOiBNTFdJPTE2Yml0IER3RmNJbi0g
TUxXTz0xNmJpdCBEd0ZjT3V0LSBMV0k9MTZiaXQgRHdGY0luRW4tIExXTz0xNmJpdCBEd0Zj
T3V0RW4tDQoJCUxpbmsgQ29udHJvbCAxOiBDRmxFLSBDU1QtIENGRS0gPExrRmFpbCsgSW5p
dC0gRU9DKyBUWE8rIDxDUkNFcnI9MCBJc29jRW4tIExTRW4tIEV4dENUTC0gNjRiLQ0KCQlM
aW5rIENvbmZpZyAxOiBNTFdJPThiaXQgRHdGY0luLSBNTFdPPThiaXQgRHdGY091dC0gTFdJ
PThiaXQgRHdGY0luRW4tIExXTz04Yml0IER3RmNPdXRFbi0NCgkJUmV2aXNpb24gSUQ6IDMu
MDANCgkJTGluayBGcmVxdWVuY3kgMDogW2JdDQoJCUxpbmsgRXJyb3IgMDogPFByb3QtIDxP
dmZsLSA8RU9DLSBDVExUbS0NCgkJTGluayBGcmVxdWVuY3kgQ2FwYWJpbGl0eSAwOiAyMDBN
SHorIDMwME1Iei0gNDAwTUh6KyA1MDBNSHotIDYwME1IeisgODAwTUh6KyAxLjBHSHorIDEu
MkdIeisgMS40R0h6LSAxLjZHSHotIFZlbmQtDQoJCUZlYXR1cmUgQ2FwYWJpbGl0eTogSXNv
Y0ZDKyBMRFRTVE9QKyBDUkNUTS0gRUNUTFQtIDY0YkErIFVJRFJELQ0KCQlMaW5rIEZyZXF1
ZW5jeSAxOiAyMDBNSHoNCgkJTGluayBFcnJvciAxOiA8UHJvdC0gPE92ZmwtIDxFT0MtIENU
TFRtLQ0KCQlMaW5rIEZyZXF1ZW5jeSBDYXBhYmlsaXR5IDE6IDIwME1Iei0gMzAwTUh6LSA0
MDBNSHotIDUwME1Iei0gNjAwTUh6LSA4MDBNSHotIDEuMEdIei0gMS4yR0h6LSAxLjRHSHot
IDEuNkdIei0gVmVuZC0NCgkJRXJyb3IgSGFuZGxpbmc6IFBGbEUtIE9GbEUtIFBGRS0gT0ZF
LSBFT0NGRS0gUkZFLSBDUkNGRS0gU0VSUkZFLSBDRi0gUkUtIFBORkUtIE9ORkUtIEVPQ05G
RS0gUk5GRS0gQ1JDTkZFLSBTRVJSTkZFLQ0KCQlQcmVmZXRjaGFibGUgbWVtb3J5IGJlaGlu
ZCBicmlkZ2UgVXBwZXI6IDAwLTAwDQoJCUJ1cyBOdW1iZXI6IDAwDQoJQ2FwYWJpbGl0aWVz
OiBbNDBdIEh5cGVyVHJhbnNwb3J0OiBSZXRyeSBNb2RlDQoJQ2FwYWJpbGl0aWVzOiBbNTRd
IEh5cGVyVHJhbnNwb3J0OiBVbml0SUQgQ2x1bXBpbmcNCglDYXBhYmlsaXRpZXM6IFs5Y10g
SHlwZXJUcmFuc3BvcnQ6ICMxYQ0KCUNhcGFiaWxpdGllczogWzcwXSBNU0k6IEVuYWJsZS0g
Q291bnQ9MS80IE1hc2thYmxlLSA2NGJpdC0NCgkJQWRkcmVzczogMDAwMDAwMDAgIERhdGE6
IDAwMDANCg0KMDA6MDAuMiBHZW5lcmljIHN5c3RlbSBwZXJpcGhlcmFsIFswODA2XTogQVRJ
IFRlY2hub2xvZ2llcyBJbmMgUkQ5OTAgSS9PIE1lbW9yeSBNYW5hZ2VtZW50IFVuaXQgKElP
TU1VKSBbMTAwMjo1YTIzXQ0KCVN1YnN5c3RlbTogQVRJIFRlY2hub2xvZ2llcyBJbmMgUkQ5
OTAgSS9PIE1lbW9yeSBNYW5hZ2VtZW50IFVuaXQgKElPTU1VKSBbMTAwMjo1YTIzXQ0KCUNv
bnRyb2w6IEkvTy0gTWVtLSBCdXNNYXN0ZXIrIFNwZWNDeWNsZS0gTWVtV0lOVi0gVkdBU25v
b3AtIFBhckVyci0gU3RlcHBpbmctIFNFUlItIEZhc3RCMkItIERpc0lOVHgtDQoJU3RhdHVz
OiBDYXArIDY2TUh6LSBVREYtIEZhc3RCMkItIFBhckVyci0gREVWU0VMPWZhc3QgPlRBYm9y
dC0gPFRBYm9ydC0gPE1BYm9ydC0gPlNFUlItIDxQRVJSLSBJTlR4LQ0KCUxhdGVuY3k6IDAN
CglJbnRlcnJ1cHQ6IHBpbiBBIHJvdXRlZCB0byBJUlEgMTANCglDYXBhYmlsaXRpZXM6IFs0
MF0gU2VjdXJlIGRldmljZSA8Pz4NCglDYXBhYmlsaXRpZXM6IFs1NF0gTVNJOiBFbmFibGUr
IENvdW50PTEvMSBNYXNrYWJsZS0gNjRiaXQrDQoJCUFkZHJlc3M6IDAwMDAwMDAwZmVlMDEw
MGMgIERhdGE6IDQxMjgNCglDYXBhYmlsaXRpZXM6IFs2NF0gSHlwZXJUcmFuc3BvcnQ6IE1T
SSBNYXBwaW5nIEVuYWJsZSsgRml4ZWQrDQoNCjAwOjAyLjAgUENJIGJyaWRnZSBbMDYwNF06
IEFUSSBUZWNobm9sb2dpZXMgSW5jIFJEODkwIFBDSSB0byBQQ0kgYnJpZGdlIChQQ0kgZXhw
cmVzcyBncHAgcG9ydCBCKSBbMTAwMjo1YTE2XSAocHJvZy1pZiAwMCBbTm9ybWFsIGRlY29k
ZV0pDQoJQ29udHJvbDogSS9PKyBNZW0rIEJ1c01hc3RlcisgU3BlY0N5Y2xlLSBNZW1XSU5W
LSBWR0FTbm9vcC0gUGFyRXJyLSBTdGVwcGluZy0gU0VSUisgRmFzdEIyQi0gRGlzSU5UeCsN
CglTdGF0dXM6IENhcCsgNjZNSHotIFVERi0gRmFzdEIyQi0gUGFyRXJyLSBERVZTRUw9ZmFz
dCA+VEFib3J0LSA8VEFib3J0LSA8TUFib3J0LSA+U0VSUi0gPFBFUlItIElOVHgtDQoJTGF0
ZW5jeTogMCwgQ2FjaGUgTGluZSBTaXplOiA2NCBieXRlcw0KCUJ1czogcHJpbWFyeT0wMCwg
c2Vjb25kYXJ5PTBhLCBzdWJvcmRpbmF0ZT0wYSwgc2VjLWxhdGVuY3k9MA0KCUkvTyBiZWhp
bmQgYnJpZGdlOiAwMDAwZTAwMC0wMDAwZWZmZg0KCU1lbW9yeSBiZWhpbmQgYnJpZGdlOiBm
YTAwMDAwMC1mZTlmZmZmZg0KCVByZWZldGNoYWJsZSBtZW1vcnkgYmVoaW5kIGJyaWRnZTog
MDAwMDAwMDBkMDAwMDAwMC0wMDAwMDAwMGRmZmZmZmZmDQoJU2Vjb25kYXJ5IHN0YXR1czog
NjZNSHotIEZhc3RCMkItIFBhckVyci0gREVWU0VMPWZhc3QgPlRBYm9ydC0gPFRBYm9ydC0g
PE1BYm9ydC0gPFNFUlItIDxQRVJSLQ0KCUJyaWRnZUN0bDogUGFyaXR5KyBTRVJSKyBOb0lT
QS0gVkdBKyBNQWJvcnQtID5SZXNldC0gRmFzdEIyQi0NCgkJUHJpRGlzY1Rtci0gU2VjRGlz
Y1Rtci0gRGlzY1RtclN0YXQtIERpc2NUbXJTRVJSRW4tDQoJQ2FwYWJpbGl0aWVzOiBbNTBd
IFBvd2VyIE1hbmFnZW1lbnQgdmVyc2lvbiAzDQoJCUZsYWdzOiBQTUVDbGstIERTSS0gRDEt
IEQyLSBBdXhDdXJyZW50PTBtQSBQTUUoRDArLEQxLSxEMi0sRDNob3QrLEQzY29sZCspDQoJ
CVN0YXR1czogRDAgTm9Tb2Z0UnN0LSBQTUUtRW5hYmxlLSBEU2VsPTAgRFNjYWxlPTAgUE1F
LQ0KCUNhcGFiaWxpdGllczogWzU4XSBFeHByZXNzICh2MikgUm9vdCBQb3J0IChTbG90Kyks
IE1TSSAwMA0KCQlEZXZDYXA6CU1heFBheWxvYWQgMTI4IGJ5dGVzLCBQaGFudEZ1bmMgMCwg
TGF0ZW5jeSBMMHMgPDY0bnMsIEwxIDwxdXMNCgkJCUV4dFRhZysgUkJFKyBGTFJlc2V0LQ0K
CQlEZXZDdGw6CVJlcG9ydCBlcnJvcnM6IENvcnJlY3RhYmxlLSBOb24tRmF0YWwtIEZhdGFs
LSBVbnN1cHBvcnRlZC0NCgkJCVJseGRPcmQrIEV4dFRhZy0gUGhhbnRGdW5jLSBBdXhQd3It
IE5vU25vb3ArDQoJCQlNYXhQYXlsb2FkIDEyOCBieXRlcywgTWF4UmVhZFJlcSAxMjggYnl0
ZXMNCgkJRGV2U3RhOglDb3JyRXJyLSBVbmNvcnJFcnItIEZhdGFsRXJyLSBVbnN1cHBSZXEt
IEF1eFB3ci0gVHJhbnNQZW5kLQ0KCQlMbmtDYXA6CVBvcnQgIzAsIFNwZWVkIDVHVC9zLCBX
aWR0aCB4OCwgQVNQTSBMMHMgTDEsIExhdGVuY3kgTDAgPDF1cywgTDEgPDh1cw0KCQkJQ2xv
Y2tQTS0gU3VycHJpc2UtIExMQWN0UmVwKyBCd05vdCsNCgkJTG5rQ3RsOglBU1BNIERpc2Fi
bGVkOyBSQ0IgNjQgYnl0ZXMgRGlzYWJsZWQtIFJldHJhaW4tIENvbW1DbGsrDQoJCQlFeHRT
eW5jaC0gQ2xvY2tQTS0gQXV0V2lkRGlzLSBCV0ludC0gQXV0QldJbnQtDQoJCUxua1N0YToJ
U3BlZWQgMi41R1QvcywgV2lkdGggeDgsIFRyRXJyLSBUcmFpbi0gU2xvdENsaysgRExBY3Rp
dmUrIEJXTWdtdCsgQUJXTWdtdC0NCgkJU2x0Q2FwOglBdHRuQnRuLSBQd3JDdHJsLSBNUkwt
IEF0dG5JbmQtIFB3ckluZC0gSG90UGx1Zy0gU3VycHJpc2UtDQoJCQlTbG90ICMxLCBQb3dl
ckxpbWl0IDI1LjAwMFc7IEludGVybG9jay0gTm9Db21wbCsNCgkJU2x0Q3RsOglFbmFibGU6
IEF0dG5CdG4tIFB3ckZsdC0gTVJMLSBQcmVzRGV0LSBDbWRDcGx0LSBIUElycS0gTGlua0No
Zy0NCgkJCUNvbnRyb2w6IEF0dG5JbmQgVW5rbm93biwgUHdySW5kIFVua25vd24sIFBvd2Vy
LSBJbnRlcmxvY2stDQoJCVNsdFN0YToJU3RhdHVzOiBBdHRuQnRuLSBQb3dlckZsdC0gTVJM
LSBDbWRDcGx0LSBQcmVzRGV0KyBJbnRlcmxvY2stDQoJCQlDaGFuZ2VkOiBNUkwtIFByZXNE
ZXQrIExpbmtTdGF0ZSsNCgkJUm9vdEN0bDogRXJyQ29ycmVjdGFibGUtIEVyck5vbi1GYXRh
bC0gRXJyRmF0YWwtIFBNRUludEVuYS0gQ1JTVmlzaWJsZS0NCgkJUm9vdENhcDogQ1JTVmlz
aWJsZS0NCgkJUm9vdFN0YTogUE1FIFJlcUlEIDAwMDAsIFBNRVN0YXR1cy0gUE1FUGVuZGlu
Zy0NCgkJRGV2Q2FwMjogQ29tcGxldGlvbiBUaW1lb3V0OiBSYW5nZSBBQkNELCBUaW1lb3V0
RGlzKyBBUklGd2QrDQoJCURldkN0bDI6IENvbXBsZXRpb24gVGltZW91dDogNjVtcyB0byAy
MTBtcywgVGltZW91dERpcy0gQVJJRndkLQ0KCQlMbmtDdGwyOiBUYXJnZXQgTGluayBTcGVl
ZDogNUdUL3MsIEVudGVyQ29tcGxpYW5jZS0gU3BlZWREaXMtLCBTZWxlY3RhYmxlIERlLWVt
cGhhc2lzOiAtMy41ZEINCgkJCSBUcmFuc21pdCBNYXJnaW46IE5vcm1hbCBPcGVyYXRpbmcg
UmFuZ2UsIEVudGVyTW9kaWZpZWRDb21wbGlhbmNlLSBDb21wbGlhbmNlU09TLQ0KCQkJIENv
bXBsaWFuY2UgRGUtZW1waGFzaXM6IC02ZEINCgkJTG5rU3RhMjogQ3VycmVudCBEZS1lbXBo
YXNpcyBMZXZlbDogLTMuNWRCDQoJQ2FwYWJpbGl0aWVzOiBbYTBdIE1TSTogRW5hYmxlKyBD
b3VudD0xLzEgTWFza2FibGUtIDY0Yml0LQ0KCQlBZGRyZXNzOiBmZWUzZjAwYyAgRGF0YTog
NDE1MQ0KCUNhcGFiaWxpdGllczogW2IwXSBTdWJzeXN0ZW06IEFUSSBUZWNobm9sb2dpZXMg
SW5jIERldmljZSBbMTAwMjo1YTExXQ0KCUNhcGFiaWxpdGllczogW2I4XSBIeXBlclRyYW5z
cG9ydDogTVNJIE1hcHBpbmcgRW5hYmxlKyBGaXhlZCsNCglDYXBhYmlsaXRpZXM6IFsxMDAg
djFdIFZlbmRvciBTcGVjaWZpYyBJbmZvcm1hdGlvbjogSUQ9MDAwMSBSZXY9MSBMZW49MDEw
IDw/Pg0KCUNhcGFiaWxpdGllczogWzE5MCB2MV0gQWNjZXNzIENvbnRyb2wgU2VydmljZXMN
CgkJQUNTQ2FwOglTcmNWYWxpZCsgVHJhbnNCbGsrIFJlcVJlZGlyKyBDbXBsdFJlZGlyKyBV
cHN0cmVhbUZ3ZCsgRWdyZXNzQ3RybC0gRGlyZWN0VHJhbnMrDQoJCUFDU0N0bDoJU3JjVmFs
aWQrIFRyYW5zQmxrLSBSZXFSZWRpcisgQ21wbHRSZWRpcisgVXBzdHJlYW1Gd2QrIEVncmVz
c0N0cmwtIERpcmVjdFRyYW5zLQ0KCUtlcm5lbCBkcml2ZXIgaW4gdXNlOiBwY2llcG9ydA0K
DQowMDowMy4wIFBDSSBicmlkZ2UgWzA2MDRdOiBBVEkgVGVjaG5vbG9naWVzIEluYyBSRDg5
MCBQQ0kgdG8gUENJIGJyaWRnZSAoUENJIGV4cHJlc3MgZ3BwIHBvcnQgQykgWzEwMDI6NWEx
N10gKHByb2ctaWYgMDAgW05vcm1hbCBkZWNvZGVdKQ0KCUNvbnRyb2w6IEkvTy0gTWVtKyBC
dXNNYXN0ZXIrIFNwZWNDeWNsZS0gTWVtV0lOVi0gVkdBU25vb3AtIFBhckVyci0gU3RlcHBp
bmctIFNFUlIrIEZhc3RCMkItIERpc0lOVHgrDQoJU3RhdHVzOiBDYXArIDY2TUh6LSBVREYt
IEZhc3RCMkItIFBhckVyci0gREVWU0VMPWZhc3QgPlRBYm9ydC0gPFRBYm9ydC0gPE1BYm9y
dC0gPlNFUlItIDxQRVJSLSBJTlR4LQ0KCUxhdGVuY3k6IDAsIENhY2hlIExpbmUgU2l6ZTog
NjQgYnl0ZXMNCglCdXM6IHByaW1hcnk9MDAsIHNlY29uZGFyeT0wOSwgc3Vib3JkaW5hdGU9
MDksIHNlYy1sYXRlbmN5PTANCglJL08gYmVoaW5kIGJyaWRnZTogMDAwMGYwMDAtMDAwMDBm
ZmYNCglNZW1vcnkgYmVoaW5kIGJyaWRnZTogZjlmMDAwMDAtZjlmZmZmZmYNCglQcmVmZXRj
aGFibGUgbWVtb3J5IGJlaGluZCBicmlkZ2U6IDAwMDAwMDAwZmZmMDAwMDAtMDAwMDAwMDAw
MDBmZmZmZg0KCVNlY29uZGFyeSBzdGF0dXM6IDY2TUh6LSBGYXN0QjJCLSBQYXJFcnItIERF
VlNFTD1mYXN0ID5UQWJvcnQtIDxUQWJvcnQtIDxNQWJvcnQtIDxTRVJSLSA8UEVSUi0NCglC
cmlkZ2VDdGw6IFBhcml0eSsgU0VSUisgTm9JU0ErIFZHQS0gTUFib3J0LSA+UmVzZXQtIEZh
c3RCMkItDQoJCVByaURpc2NUbXItIFNlY0Rpc2NUbXItIERpc2NUbXJTdGF0LSBEaXNjVG1y
U0VSUkVuLQ0KCUNhcGFiaWxpdGllczogWzUwXSBQb3dlciBNYW5hZ2VtZW50IHZlcnNpb24g
Mw0KCQlGbGFnczogUE1FQ2xrLSBEU0ktIEQxLSBEMi0gQXV4Q3VycmVudD0wbUEgUE1FKEQw
KyxEMS0sRDItLEQzaG90KyxEM2NvbGQrKQ0KCQlTdGF0dXM6IEQwIE5vU29mdFJzdC0gUE1F
LUVuYWJsZS0gRFNlbD0wIERTY2FsZT0wIFBNRS0NCglDYXBhYmlsaXRpZXM6IFs1OF0gRXhw
cmVzcyAodjIpIFJvb3QgUG9ydCAoU2xvdCspLCBNU0kgMDANCgkJRGV2Q2FwOglNYXhQYXls
b2FkIDEyOCBieXRlcywgUGhhbnRGdW5jIDAsIExhdGVuY3kgTDBzIDw2NG5zLCBMMSA8MXVz
DQoJCQlFeHRUYWcrIFJCRSsgRkxSZXNldC0NCgkJRGV2Q3RsOglSZXBvcnQgZXJyb3JzOiBD
b3JyZWN0YWJsZS0gTm9uLUZhdGFsLSBGYXRhbC0gVW5zdXBwb3J0ZWQtDQoJCQlSbHhkT3Jk
KyBFeHRUYWctIFBoYW50RnVuYy0gQXV4UHdyLSBOb1Nub29wKw0KCQkJTWF4UGF5bG9hZCAx
MjggYnl0ZXMsIE1heFJlYWRSZXEgMTI4IGJ5dGVzDQoJCURldlN0YToJQ29yckVyci0gVW5j
b3JyRXJyLSBGYXRhbEVyci0gVW5zdXBwUmVxLSBBdXhQd3ItIFRyYW5zUGVuZC0NCgkJTG5r
Q2FwOglQb3J0ICMxLCBTcGVlZCA1R1QvcywgV2lkdGggeDgsIEFTUE0gTDBzIEwxLCBMYXRl
bmN5IEwwIDwxdXMsIEwxIDw4dXMNCgkJCUNsb2NrUE0tIFN1cnByaXNlLSBMTEFjdFJlcCsg
QndOb3QrDQoJCUxua0N0bDoJQVNQTSBEaXNhYmxlZDsgUkNCIDY0IGJ5dGVzIERpc2FibGVk
LSBSZXRyYWluLSBDb21tQ2xrLQ0KCQkJRXh0U3luY2gtIENsb2NrUE0tIEF1dFdpZERpcy0g
QldJbnQtIEF1dEJXSW50LQ0KCQlMbmtTdGE6CVNwZWVkIDIuNUdUL3MsIFdpZHRoIHgxLCBU
ckVyci0gVHJhaW4tIFNsb3RDbGsrIERMQWN0aXZlKyBCV01nbXQrIEFCV01nbXQtDQoJCVNs
dENhcDoJQXR0bkJ0bi0gUHdyQ3RybC0gTVJMLSBBdHRuSW5kLSBQd3JJbmQtIEhvdFBsdWct
IFN1cnByaXNlLQ0KCQkJU2xvdCAjMywgUG93ZXJMaW1pdCAxMS4wMDBXOyBJbnRlcmxvY2st
IE5vQ29tcGwrDQoJCVNsdEN0bDoJRW5hYmxlOiBBdHRuQnRuLSBQd3JGbHQtIE1STC0gUHJl
c0RldC0gQ21kQ3BsdC0gSFBJcnEtIExpbmtDaGctDQoJCQlDb250cm9sOiBBdHRuSW5kIFVu
a25vd24sIFB3ckluZCBVbmtub3duLCBQb3dlci0gSW50ZXJsb2NrLQ0KCQlTbHRTdGE6CVN0
YXR1czogQXR0bkJ0bi0gUG93ZXJGbHQtIE1STC0gQ21kQ3BsdC0gUHJlc0RldCsgSW50ZXJs
b2NrLQ0KCQkJQ2hhbmdlZDogTVJMLSBQcmVzRGV0KyBMaW5rU3RhdGUrDQoJCVJvb3RDdGw6
IEVyckNvcnJlY3RhYmxlLSBFcnJOb24tRmF0YWwtIEVyckZhdGFsLSBQTUVJbnRFbmEtIENS
U1Zpc2libGUtDQoJCVJvb3RDYXA6IENSU1Zpc2libGUtDQoJCVJvb3RTdGE6IFBNRSBSZXFJ
RCAwMDAwLCBQTUVTdGF0dXMtIFBNRVBlbmRpbmctDQoJCURldkNhcDI6IENvbXBsZXRpb24g
VGltZW91dDogUmFuZ2UgQUJDRCwgVGltZW91dERpcysgQVJJRndkKw0KCQlEZXZDdGwyOiBD
b21wbGV0aW9uIFRpbWVvdXQ6IDY1bXMgdG8gMjEwbXMsIFRpbWVvdXREaXMtIEFSSUZ3ZC0N
CgkJTG5rQ3RsMjogVGFyZ2V0IExpbmsgU3BlZWQ6IDVHVC9zLCBFbnRlckNvbXBsaWFuY2Ut
IFNwZWVkRGlzLSwgU2VsZWN0YWJsZSBEZS1lbXBoYXNpczogLTMuNWRCDQoJCQkgVHJhbnNt
aXQgTWFyZ2luOiBOb3JtYWwgT3BlcmF0aW5nIFJhbmdlLCBFbnRlck1vZGlmaWVkQ29tcGxp
YW5jZS0gQ29tcGxpYW5jZVNPUy0NCgkJCSBDb21wbGlhbmNlIERlLWVtcGhhc2lzOiAtNmRC
DQoJCUxua1N0YTI6IEN1cnJlbnQgRGUtZW1waGFzaXMgTGV2ZWw6IC0zLjVkQg0KCUNhcGFi
aWxpdGllczogW2EwXSBNU0k6IEVuYWJsZSsgQ291bnQ9MS8xIE1hc2thYmxlLSA2NGJpdC0N
CgkJQWRkcmVzczogZmVlM2YwMGMgIERhdGE6IDQxNTkNCglDYXBhYmlsaXRpZXM6IFtiMF0g
U3Vic3lzdGVtOiBBVEkgVGVjaG5vbG9naWVzIEluYyBEZXZpY2UgWzEwMDI6NWExMV0NCglD
YXBhYmlsaXRpZXM6IFtiOF0gSHlwZXJUcmFuc3BvcnQ6IE1TSSBNYXBwaW5nIEVuYWJsZSsg
Rml4ZWQrDQoJQ2FwYWJpbGl0aWVzOiBbMTAwIHYxXSBWZW5kb3IgU3BlY2lmaWMgSW5mb3Jt
YXRpb246IElEPTAwMDEgUmV2PTEgTGVuPTAxMCA8Pz4NCglDYXBhYmlsaXRpZXM6IFsxOTAg
djFdIEFjY2VzcyBDb250cm9sIFNlcnZpY2VzDQoJCUFDU0NhcDoJU3JjVmFsaWQrIFRyYW5z
QmxrKyBSZXFSZWRpcisgQ21wbHRSZWRpcisgVXBzdHJlYW1Gd2QrIEVncmVzc0N0cmwtIERp
cmVjdFRyYW5zKw0KCQlBQ1NDdGw6CVNyY1ZhbGlkKyBUcmFuc0Jsay0gUmVxUmVkaXIrIENt
cGx0UmVkaXIrIFVwc3RyZWFtRndkKyBFZ3Jlc3NDdHJsLSBEaXJlY3RUcmFucy0NCglLZXJu
ZWwgZHJpdmVyIGluIHVzZTogcGNpZXBvcnQNCg0KMDA6MDUuMCBQQ0kgYnJpZGdlIFswNjA0
XTogQVRJIFRlY2hub2xvZ2llcyBJbmMgUkQ4OTAgUENJIHRvIFBDSSBicmlkZ2UgKFBDSSBl
eHByZXNzIGdwcCBwb3J0IEUpIFsxMDAyOjVhMTldIChwcm9nLWlmIDAwIFtOb3JtYWwgZGVj
b2RlXSkNCglDb250cm9sOiBJL08rIE1lbSsgQnVzTWFzdGVyKyBTcGVjQ3ljbGUtIE1lbVdJ
TlYtIFZHQVNub29wLSBQYXJFcnItIFN0ZXBwaW5nLSBTRVJSKyBGYXN0QjJCLSBEaXNJTlR4
Kw0KCVN0YXR1czogQ2FwKyA2Nk1Iei0gVURGLSBGYXN0QjJCLSBQYXJFcnItIERFVlNFTD1m
YXN0ID5UQWJvcnQtIDxUQWJvcnQtIDxNQWJvcnQtID5TRVJSLSA8UEVSUi0gSU5UeC0NCglM
YXRlbmN5OiAwLCBDYWNoZSBMaW5lIFNpemU6IDY0IGJ5dGVzDQoJQnVzOiBwcmltYXJ5PTAw
LCBzZWNvbmRhcnk9MDgsIHN1Ym9yZGluYXRlPTA4LCBzZWMtbGF0ZW5jeT0wDQoJSS9PIGJl
aGluZCBicmlkZ2U6IDAwMDBkMDAwLTAwMDBkZmZmDQoJTWVtb3J5IGJlaGluZCBicmlkZ2U6
IGY5ZTAwMDAwLWY5ZWZmZmZmDQoJUHJlZmV0Y2hhYmxlIG1lbW9yeSBiZWhpbmQgYnJpZGdl
OiAwMDAwMDAwMGNmZjAwMDAwLTAwMDAwMDAwY2ZmZmZmZmYNCglTZWNvbmRhcnkgc3RhdHVz
OiA2Nk1Iei0gRmFzdEIyQi0gUGFyRXJyLSBERVZTRUw9ZmFzdCA+VEFib3J0LSA8VEFib3J0
LSA8TUFib3J0LSA8U0VSUi0gPFBFUlItDQoJQnJpZGdlQ3RsOiBQYXJpdHkrIFNFUlIrIE5v
SVNBKyBWR0EtIE1BYm9ydC0gPlJlc2V0LSBGYXN0QjJCLQ0KCQlQcmlEaXNjVG1yLSBTZWNE
aXNjVG1yLSBEaXNjVG1yU3RhdC0gRGlzY1RtclNFUlJFbi0NCglDYXBhYmlsaXRpZXM6IFs1
MF0gUG93ZXIgTWFuYWdlbWVudCB2ZXJzaW9uIDMNCgkJRmxhZ3M6IFBNRUNsay0gRFNJLSBE
MS0gRDItIEF1eEN1cnJlbnQ9MG1BIFBNRShEMCssRDEtLEQyLSxEM2hvdCssRDNjb2xkKykN
CgkJU3RhdHVzOiBEMCBOb1NvZnRSc3QtIFBNRS1FbmFibGUtIERTZWw9MCBEU2NhbGU9MCBQ
TUUtDQoJQ2FwYWJpbGl0aWVzOiBbNThdIEV4cHJlc3MgKHYyKSBSb290IFBvcnQgKFNsb3Qr
KSwgTVNJIDAwDQoJCURldkNhcDoJTWF4UGF5bG9hZCAxMjggYnl0ZXMsIFBoYW50RnVuYyAw
LCBMYXRlbmN5IEwwcyA8NjRucywgTDEgPDF1cw0KCQkJRXh0VGFnKyBSQkUrIEZMUmVzZXQt
DQoJCURldkN0bDoJUmVwb3J0IGVycm9yczogQ29ycmVjdGFibGUtIE5vbi1GYXRhbC0gRmF0
YWwtIFVuc3VwcG9ydGVkLQ0KCQkJUmx4ZE9yZCsgRXh0VGFnLSBQaGFudEZ1bmMtIEF1eFB3
ci0gTm9Tbm9vcCsNCgkJCU1heFBheWxvYWQgMTI4IGJ5dGVzLCBNYXhSZWFkUmVxIDEyOCBi
eXRlcw0KCQlEZXZTdGE6CUNvcnJFcnItIFVuY29yckVyci0gRmF0YWxFcnItIFVuc3VwcFJl
cS0gQXV4UHdyLSBUcmFuc1BlbmQtDQoJCUxua0NhcDoJUG9ydCAjMSwgU3BlZWQgNUdUL3Ms
IFdpZHRoIHgxLCBBU1BNIEwwcyBMMSwgTGF0ZW5jeSBMMCA8MXVzLCBMMSA8OHVzDQoJCQlD
bG9ja1BNLSBTdXJwcmlzZS0gTExBY3RSZXArIEJ3Tm90Kw0KCQlMbmtDdGw6CUFTUE0gRGlz
YWJsZWQ7IFJDQiA2NCBieXRlcyBEaXNhYmxlZC0gUmV0cmFpbi0gQ29tbUNsaysNCgkJCUV4
dFN5bmNoLSBDbG9ja1BNLSBBdXRXaWREaXMtIEJXSW50LSBBdXRCV0ludC0NCgkJTG5rU3Rh
OglTcGVlZCAyLjVHVC9zLCBXaWR0aCB4MSwgVHJFcnItIFRyYWluLSBTbG90Q2xrKyBETEFj
dGl2ZSsgQldNZ210KyBBQldNZ210LQ0KCQlTbHRDYXA6CUF0dG5CdG4tIFB3ckN0cmwtIE1S
TC0gQXR0bkluZC0gUHdySW5kLSBIb3RQbHVnLSBTdXJwcmlzZS0NCgkJCVNsb3QgIzUsIFBv
d2VyTGltaXQgNzUuMDAwVzsgSW50ZXJsb2NrLSBOb0NvbXBsKw0KCQlTbHRDdGw6CUVuYWJs
ZTogQXR0bkJ0bi0gUHdyRmx0LSBNUkwtIFByZXNEZXQtIENtZENwbHQtIEhQSXJxLSBMaW5r
Q2hnLQ0KCQkJQ29udHJvbDogQXR0bkluZCBVbmtub3duLCBQd3JJbmQgVW5rbm93biwgUG93
ZXItIEludGVybG9jay0NCgkJU2x0U3RhOglTdGF0dXM6IEF0dG5CdG4tIFBvd2VyRmx0LSBN
UkwtIENtZENwbHQtIFByZXNEZXQrIEludGVybG9jay0NCgkJCUNoYW5nZWQ6IE1STC0gUHJl
c0RldCsgTGlua1N0YXRlKw0KCQlSb290Q3RsOiBFcnJDb3JyZWN0YWJsZS0gRXJyTm9uLUZh
dGFsLSBFcnJGYXRhbC0gUE1FSW50RW5hLSBDUlNWaXNpYmxlLQ0KCQlSb290Q2FwOiBDUlNW
aXNpYmxlLQ0KCQlSb290U3RhOiBQTUUgUmVxSUQgMDAwMCwgUE1FU3RhdHVzLSBQTUVQZW5k
aW5nLQ0KCQlEZXZDYXAyOiBDb21wbGV0aW9uIFRpbWVvdXQ6IFJhbmdlIEFCQ0QsIFRpbWVv
dXREaXMrIEFSSUZ3ZCsNCgkJRGV2Q3RsMjogQ29tcGxldGlvbiBUaW1lb3V0OiA2NW1zIHRv
IDIxMG1zLCBUaW1lb3V0RGlzLSBBUklGd2QtDQoJCUxua0N0bDI6IFRhcmdldCBMaW5rIFNw
ZWVkOiA1R1QvcywgRW50ZXJDb21wbGlhbmNlLSBTcGVlZERpcy0sIFNlbGVjdGFibGUgRGUt
ZW1waGFzaXM6IC0zLjVkQg0KCQkJIFRyYW5zbWl0IE1hcmdpbjogTm9ybWFsIE9wZXJhdGlu
ZyBSYW5nZSwgRW50ZXJNb2RpZmllZENvbXBsaWFuY2UtIENvbXBsaWFuY2VTT1MtDQoJCQkg
Q29tcGxpYW5jZSBEZS1lbXBoYXNpczogLTZkQg0KCQlMbmtTdGEyOiBDdXJyZW50IERlLWVt
cGhhc2lzIExldmVsOiAtMy41ZEINCglDYXBhYmlsaXRpZXM6IFthMF0gTVNJOiBFbmFibGUr
IENvdW50PTEvMSBNYXNrYWJsZS0gNjRiaXQtDQoJCUFkZHJlc3M6IGZlZTNmMDBjICBEYXRh
OiA0MTYxDQoJQ2FwYWJpbGl0aWVzOiBbYjBdIFN1YnN5c3RlbTogQVRJIFRlY2hub2xvZ2ll
cyBJbmMgRGV2aWNlIFsxMDAyOjVhMTFdDQoJQ2FwYWJpbGl0aWVzOiBbYjhdIEh5cGVyVHJh
bnNwb3J0OiBNU0kgTWFwcGluZyBFbmFibGUrIEZpeGVkKw0KCUNhcGFiaWxpdGllczogWzEw
MCB2MV0gVmVuZG9yIFNwZWNpZmljIEluZm9ybWF0aW9uOiBJRD0wMDAxIFJldj0xIExlbj0w
MTAgPD8+DQoJQ2FwYWJpbGl0aWVzOiBbMTkwIHYxXSBBY2Nlc3MgQ29udHJvbCBTZXJ2aWNl
cw0KCQlBQ1NDYXA6CVNyY1ZhbGlkKyBUcmFuc0JsaysgUmVxUmVkaXIrIENtcGx0UmVkaXIr
IFVwc3RyZWFtRndkKyBFZ3Jlc3NDdHJsLSBEaXJlY3RUcmFucysNCgkJQUNTQ3RsOglTcmNW
YWxpZCsgVHJhbnNCbGstIFJlcVJlZGlyKyBDbXBsdFJlZGlyKyBVcHN0cmVhbUZ3ZCsgRWdy
ZXNzQ3RybC0gRGlyZWN0VHJhbnMtDQoJS2VybmVsIGRyaXZlciBpbiB1c2U6IHBjaWVwb3J0
DQoNCjAwOjA2LjAgUENJIGJyaWRnZSBbMDYwNF06IEFUSSBUZWNobm9sb2dpZXMgSW5jIFJE
ODkwIFBDSSB0byBQQ0kgYnJpZGdlIChQQ0kgZXhwcmVzcyBncHAgcG9ydCBGKSBbMTAwMjo1
YTFhXSAocHJvZy1pZiAwMCBbTm9ybWFsIGRlY29kZV0pDQoJQ29udHJvbDogSS9PKyBNZW0r
IEJ1c01hc3RlcisgU3BlY0N5Y2xlLSBNZW1XSU5WLSBWR0FTbm9vcC0gUGFyRXJyLSBTdGVw
cGluZy0gU0VSUisgRmFzdEIyQi0gRGlzSU5UeCsNCglTdGF0dXM6IENhcCsgNjZNSHotIFVE
Ri0gRmFzdEIyQi0gUGFyRXJyLSBERVZTRUw9ZmFzdCA+VEFib3J0LSA8VEFib3J0LSA8TUFi
b3J0LSA+U0VSUi0gPFBFUlItIElOVHgtDQoJTGF0ZW5jeTogMCwgQ2FjaGUgTGluZSBTaXpl
OiA2NCBieXRlcw0KCUJ1czogcHJpbWFyeT0wMCwgc2Vjb25kYXJ5PTA3LCBzdWJvcmRpbmF0
ZT0wNywgc2VjLWxhdGVuY3k9MA0KCUkvTyBiZWhpbmQgYnJpZGdlOiAwMDAwYzAwMC0wMDAw
Y2ZmZg0KCU1lbW9yeSBiZWhpbmQgYnJpZGdlOiBmOWQwMDAwMC1mOWRmZmZmZg0KCVByZWZl
dGNoYWJsZSBtZW1vcnkgYmVoaW5kIGJyaWRnZTogMDAwMDAwMDBjZmUwMDAwMC0wMDAwMDAw
MGNmZWZmZmZmDQoJU2Vjb25kYXJ5IHN0YXR1czogNjZNSHotIEZhc3RCMkItIFBhckVyci0g
REVWU0VMPWZhc3QgPlRBYm9ydC0gPFRBYm9ydC0gPE1BYm9ydC0gPFNFUlItIDxQRVJSLQ0K
CUJyaWRnZUN0bDogUGFyaXR5KyBTRVJSKyBOb0lTQSsgVkdBLSBNQWJvcnQtID5SZXNldC0g
RmFzdEIyQi0NCgkJUHJpRGlzY1Rtci0gU2VjRGlzY1Rtci0gRGlzY1RtclN0YXQtIERpc2NU
bXJTRVJSRW4tDQoJQ2FwYWJpbGl0aWVzOiBbNTBdIFBvd2VyIE1hbmFnZW1lbnQgdmVyc2lv
biAzDQoJCUZsYWdzOiBQTUVDbGstIERTSS0gRDEtIEQyLSBBdXhDdXJyZW50PTBtQSBQTUUo
RDArLEQxLSxEMi0sRDNob3QrLEQzY29sZCspDQoJCVN0YXR1czogRDAgTm9Tb2Z0UnN0LSBQ
TUUtRW5hYmxlLSBEU2VsPTAgRFNjYWxlPTAgUE1FLQ0KCUNhcGFiaWxpdGllczogWzU4XSBF
eHByZXNzICh2MikgUm9vdCBQb3J0IChTbG90KyksIE1TSSAwMA0KCQlEZXZDYXA6CU1heFBh
eWxvYWQgMTI4IGJ5dGVzLCBQaGFudEZ1bmMgMCwgTGF0ZW5jeSBMMHMgPDY0bnMsIEwxIDwx
dXMNCgkJCUV4dFRhZysgUkJFKyBGTFJlc2V0LQ0KCQlEZXZDdGw6CVJlcG9ydCBlcnJvcnM6
IENvcnJlY3RhYmxlLSBOb24tRmF0YWwtIEZhdGFsLSBVbnN1cHBvcnRlZC0NCgkJCVJseGRP
cmQrIEV4dFRhZy0gUGhhbnRGdW5jLSBBdXhQd3ItIE5vU25vb3ArDQoJCQlNYXhQYXlsb2Fk
IDEyOCBieXRlcywgTWF4UmVhZFJlcSAxMjggYnl0ZXMNCgkJRGV2U3RhOglDb3JyRXJyLSBV
bmNvcnJFcnItIEZhdGFsRXJyLSBVbnN1cHBSZXEtIEF1eFB3ci0gVHJhbnNQZW5kLQ0KCQlM
bmtDYXA6CVBvcnQgIzIsIFNwZWVkIDVHVC9zLCBXaWR0aCB4MSwgQVNQTSBMMHMgTDEsIExh
dGVuY3kgTDAgPDF1cywgTDEgPDh1cw0KCQkJQ2xvY2tQTS0gU3VycHJpc2UtIExMQWN0UmVw
KyBCd05vdCsNCgkJTG5rQ3RsOglBU1BNIERpc2FibGVkOyBSQ0IgNjQgYnl0ZXMgRGlzYWJs
ZWQtIFJldHJhaW4tIENvbW1DbGsrDQoJCQlFeHRTeW5jaC0gQ2xvY2tQTS0gQXV0V2lkRGlz
LSBCV0ludC0gQXV0QldJbnQtDQoJCUxua1N0YToJU3BlZWQgMi41R1QvcywgV2lkdGggeDEs
IFRyRXJyLSBUcmFpbi0gU2xvdENsaysgRExBY3RpdmUrIEJXTWdtdCsgQUJXTWdtdC0NCgkJ
U2x0Q2FwOglBdHRuQnRuLSBQd3JDdHJsLSBNUkwtIEF0dG5JbmQtIFB3ckluZC0gSG90UGx1
Zy0gU3VycHJpc2UtDQoJCQlTbG90ICM2LCBQb3dlckxpbWl0IDc1LjAwMFc7IEludGVybG9j
ay0gTm9Db21wbCsNCgkJU2x0Q3RsOglFbmFibGU6IEF0dG5CdG4tIFB3ckZsdC0gTVJMLSBQ
cmVzRGV0LSBDbWRDcGx0LSBIUElycS0gTGlua0NoZy0NCgkJCUNvbnRyb2w6IEF0dG5JbmQg
VW5rbm93biwgUHdySW5kIFVua25vd24sIFBvd2VyLSBJbnRlcmxvY2stDQoJCVNsdFN0YToJ
U3RhdHVzOiBBdHRuQnRuLSBQb3dlckZsdC0gTVJMLSBDbWRDcGx0LSBQcmVzRGV0KyBJbnRl
cmxvY2stDQoJCQlDaGFuZ2VkOiBNUkwtIFByZXNEZXQrIExpbmtTdGF0ZSsNCgkJUm9vdEN0
bDogRXJyQ29ycmVjdGFibGUtIEVyck5vbi1GYXRhbC0gRXJyRmF0YWwtIFBNRUludEVuYS0g
Q1JTVmlzaWJsZS0NCgkJUm9vdENhcDogQ1JTVmlzaWJsZS0NCgkJUm9vdFN0YTogUE1FIFJl
cUlEIDAwMDAsIFBNRVN0YXR1cy0gUE1FUGVuZGluZy0NCgkJRGV2Q2FwMjogQ29tcGxldGlv
biBUaW1lb3V0OiBSYW5nZSBBQkNELCBUaW1lb3V0RGlzKyBBUklGd2QrDQoJCURldkN0bDI6
IENvbXBsZXRpb24gVGltZW91dDogNjVtcyB0byAyMTBtcywgVGltZW91dERpcy0gQVJJRndk
LQ0KCQlMbmtDdGwyOiBUYXJnZXQgTGluayBTcGVlZDogNUdUL3MsIEVudGVyQ29tcGxpYW5j
ZS0gU3BlZWREaXMtLCBTZWxlY3RhYmxlIERlLWVtcGhhc2lzOiAtMy41ZEINCgkJCSBUcmFu
c21pdCBNYXJnaW46IE5vcm1hbCBPcGVyYXRpbmcgUmFuZ2UsIEVudGVyTW9kaWZpZWRDb21w
bGlhbmNlLSBDb21wbGlhbmNlU09TLQ0KCQkJIENvbXBsaWFuY2UgRGUtZW1waGFzaXM6IC02
ZEINCgkJTG5rU3RhMjogQ3VycmVudCBEZS1lbXBoYXNpcyBMZXZlbDogLTMuNWRCDQoJQ2Fw
YWJpbGl0aWVzOiBbYTBdIE1TSTogRW5hYmxlKyBDb3VudD0xLzEgTWFza2FibGUtIDY0Yml0
LQ0KCQlBZGRyZXNzOiBmZWUzZjAwYyAgRGF0YTogNDE2OQ0KCUNhcGFiaWxpdGllczogW2Iw
XSBTdWJzeXN0ZW06IEFUSSBUZWNobm9sb2dpZXMgSW5jIERldmljZSBbMTAwMjo1YTExXQ0K
CUNhcGFiaWxpdGllczogW2I4XSBIeXBlclRyYW5zcG9ydDogTVNJIE1hcHBpbmcgRW5hYmxl
KyBGaXhlZCsNCglDYXBhYmlsaXRpZXM6IFsxMDAgdjFdIFZlbmRvciBTcGVjaWZpYyBJbmZv
cm1hdGlvbjogSUQ9MDAwMSBSZXY9MSBMZW49MDEwIDw/Pg0KCUNhcGFiaWxpdGllczogWzE5
MCB2MV0gQWNjZXNzIENvbnRyb2wgU2VydmljZXMNCgkJQUNTQ2FwOglTcmNWYWxpZCsgVHJh
bnNCbGsrIFJlcVJlZGlyKyBDbXBsdFJlZGlyKyBVcHN0cmVhbUZ3ZCsgRWdyZXNzQ3RybC0g
RGlyZWN0VHJhbnMrDQoJCUFDU0N0bDoJU3JjVmFsaWQrIFRyYW5zQmxrLSBSZXFSZWRpcisg
Q21wbHRSZWRpcisgVXBzdHJlYW1Gd2QrIEVncmVzc0N0cmwtIERpcmVjdFRyYW5zLQ0KCUtl
cm5lbCBkcml2ZXIgaW4gdXNlOiBwY2llcG9ydA0KDQowMDowYS4wIFBDSSBicmlkZ2UgWzA2
MDRdOiBBVEkgVGVjaG5vbG9naWVzIEluYyBSRDg5MCBQQ0kgdG8gUENJIGJyaWRnZSAoZXh0
ZXJuYWwgZ2Z4MSBwb3J0IEEpIFsxMDAyOjVhMWRdIChwcm9nLWlmIDAwIFtOb3JtYWwgZGVj
b2RlXSkNCglDb250cm9sOiBJL08tIE1lbSsgQnVzTWFzdGVyKyBTcGVjQ3ljbGUtIE1lbVdJ
TlYtIFZHQVNub29wLSBQYXJFcnItIFN0ZXBwaW5nLSBTRVJSKyBGYXN0QjJCLSBEaXNJTlR4
Kw0KCVN0YXR1czogQ2FwKyA2Nk1Iei0gVURGLSBGYXN0QjJCLSBQYXJFcnItIERFVlNFTD1m
YXN0ID5UQWJvcnQtIDxUQWJvcnQtIDxNQWJvcnQtID5TRVJSLSA8UEVSUi0gSU5UeC0NCglM
YXRlbmN5OiAwLCBDYWNoZSBMaW5lIFNpemU6IDY0IGJ5dGVzDQoJQnVzOiBwcmltYXJ5PTAw
LCBzZWNvbmRhcnk9MDYsIHN1Ym9yZGluYXRlPTA2LCBzZWMtbGF0ZW5jeT0wDQoJSS9PIGJl
aGluZCBicmlkZ2U6IDAwMDBmMDAwLTAwMDAwZmZmDQoJTWVtb3J5IGJlaGluZCBicmlkZ2U6
IGY5YTAwMDAwLWY5YmZmZmZmDQoJUHJlZmV0Y2hhYmxlIG1lbW9yeSBiZWhpbmQgYnJpZGdl
OiAwMDAwMDAwMGZmZjAwMDAwLTAwMDAwMDAwMDAwZmZmZmYNCglTZWNvbmRhcnkgc3RhdHVz
OiA2Nk1Iei0gRmFzdEIyQi0gUGFyRXJyLSBERVZTRUw9ZmFzdCA+VEFib3J0LSA8VEFib3J0
LSA8TUFib3J0KyA8U0VSUi0gPFBFUlItDQoJQnJpZGdlQ3RsOiBQYXJpdHkrIFNFUlIrIE5v
SVNBKyBWR0EtIE1BYm9ydC0gPlJlc2V0LSBGYXN0QjJCLQ0KCQlQcmlEaXNjVG1yLSBTZWNE
aXNjVG1yLSBEaXNjVG1yU3RhdC0gRGlzY1RtclNFUlJFbi0NCglDYXBhYmlsaXRpZXM6IFs1
MF0gUG93ZXIgTWFuYWdlbWVudCB2ZXJzaW9uIDMNCgkJRmxhZ3M6IFBNRUNsay0gRFNJLSBE
MS0gRDItIEF1eEN1cnJlbnQ9MG1BIFBNRShEMCssRDEtLEQyLSxEM2hvdCssRDNjb2xkKykN
CgkJU3RhdHVzOiBEMCBOb1NvZnRSc3QtIFBNRS1FbmFibGUtIERTZWw9MCBEU2NhbGU9MCBQ
TUUtDQoJQ2FwYWJpbGl0aWVzOiBbNThdIEV4cHJlc3MgKHYyKSBSb290IFBvcnQgKFNsb3Qr
KSwgTVNJIDAwDQoJCURldkNhcDoJTWF4UGF5bG9hZCAxMjggYnl0ZXMsIFBoYW50RnVuYyAw
LCBMYXRlbmN5IEwwcyA8NjRucywgTDEgPDF1cw0KCQkJRXh0VGFnKyBSQkUrIEZMUmVzZXQt
DQoJCURldkN0bDoJUmVwb3J0IGVycm9yczogQ29ycmVjdGFibGUtIE5vbi1GYXRhbC0gRmF0
YWwtIFVuc3VwcG9ydGVkLQ0KCQkJUmx4ZE9yZCsgRXh0VGFnLSBQaGFudEZ1bmMtIEF1eFB3
ci0gTm9Tbm9vcCsNCgkJCU1heFBheWxvYWQgMTI4IGJ5dGVzLCBNYXhSZWFkUmVxIDEyOCBi
eXRlcw0KCQlEZXZTdGE6CUNvcnJFcnItIFVuY29yckVyci0gRmF0YWxFcnItIFVuc3VwcFJl
cS0gQXV4UHdyLSBUcmFuc1BlbmQtDQoJCUxua0NhcDoJUG9ydCAjNSwgU3BlZWQgMi41R1Qv
cywgV2lkdGggeDEsIEFTUE0gTDBzIEwxLCBMYXRlbmN5IEwwIDwxdXMsIEwxIDw4dXMNCgkJ
CUNsb2NrUE0tIFN1cnByaXNlLSBMTEFjdFJlcCsgQndOb3QrDQoJCUxua0N0bDoJQVNQTSBE
aXNhYmxlZDsgUkNCIDY0IGJ5dGVzIERpc2FibGVkLSBSZXRyYWluLSBDb21tQ2xrLQ0KCQkJ
RXh0U3luY2gtIENsb2NrUE0tIEF1dFdpZERpcy0gQldJbnQtIEF1dEJXSW50LQ0KCQlMbmtT
dGE6CVNwZWVkIDIuNUdUL3MsIFdpZHRoIHgxLCBUckVyci0gVHJhaW4tIFNsb3RDbGsrIERM
QWN0aXZlKyBCV01nbXQrIEFCV01nbXQtDQoJCVNsdENhcDoJQXR0bkJ0bi0gUHdyQ3RybC0g
TVJMLSBBdHRuSW5kLSBQd3JJbmQtIEhvdFBsdWctIFN1cnByaXNlLQ0KCQkJU2xvdCAjMiwg
UG93ZXJMaW1pdCA3NS4wMDBXOyBJbnRlcmxvY2stIE5vQ29tcGwrDQoJCVNsdEN0bDoJRW5h
YmxlOiBBdHRuQnRuLSBQd3JGbHQtIE1STC0gUHJlc0RldC0gQ21kQ3BsdC0gSFBJcnEtIExp
bmtDaGctDQoJCQlDb250cm9sOiBBdHRuSW5kIFVua25vd24sIFB3ckluZCBVbmtub3duLCBQ
b3dlci0gSW50ZXJsb2NrLQ0KCQlTbHRTdGE6CVN0YXR1czogQXR0bkJ0bi0gUG93ZXJGbHQt
IE1STC0gQ21kQ3BsdC0gUHJlc0RldCsgSW50ZXJsb2NrLQ0KCQkJQ2hhbmdlZDogTVJMLSBQ
cmVzRGV0KyBMaW5rU3RhdGUrDQoJCVJvb3RDdGw6IEVyckNvcnJlY3RhYmxlLSBFcnJOb24t
RmF0YWwtIEVyckZhdGFsLSBQTUVJbnRFbmEtIENSU1Zpc2libGUtDQoJCVJvb3RDYXA6IENS
U1Zpc2libGUtDQoJCVJvb3RTdGE6IFBNRSBSZXFJRCAwMDAwLCBQTUVTdGF0dXMtIFBNRVBl
bmRpbmctDQoJCURldkNhcDI6IENvbXBsZXRpb24gVGltZW91dDogUmFuZ2UgQUJDRCwgVGlt
ZW91dERpcysgQVJJRndkKw0KCQlEZXZDdGwyOiBDb21wbGV0aW9uIFRpbWVvdXQ6IDY1bXMg
dG8gMjEwbXMsIFRpbWVvdXREaXMtIEFSSUZ3ZC0NCgkJTG5rQ3RsMjogVGFyZ2V0IExpbmsg
U3BlZWQ6IDIuNUdUL3MsIEVudGVyQ29tcGxpYW5jZS0gU3BlZWREaXMtLCBTZWxlY3RhYmxl
IERlLWVtcGhhc2lzOiAtNmRCDQoJCQkgVHJhbnNtaXQgTWFyZ2luOiBOb3JtYWwgT3BlcmF0
aW5nIFJhbmdlLCBFbnRlck1vZGlmaWVkQ29tcGxpYW5jZS0gQ29tcGxpYW5jZVNPUy0NCgkJ
CSBDb21wbGlhbmNlIERlLWVtcGhhc2lzOiAtNmRCDQoJCUxua1N0YTI6IEN1cnJlbnQgRGUt
ZW1waGFzaXMgTGV2ZWw6IC02ZEINCglDYXBhYmlsaXRpZXM6IFthMF0gTVNJOiBFbmFibGUr
IENvdW50PTEvMSBNYXNrYWJsZS0gNjRiaXQtDQoJCUFkZHJlc3M6IGZlZTNmMDBjICBEYXRh
OiA0MTcxDQoJQ2FwYWJpbGl0aWVzOiBbYjBdIFN1YnN5c3RlbTogQVRJIFRlY2hub2xvZ2ll
cyBJbmMgRGV2aWNlIFsxMDAyOjVhMTFdDQoJQ2FwYWJpbGl0aWVzOiBbYjhdIEh5cGVyVHJh
bnNwb3J0OiBNU0kgTWFwcGluZyBFbmFibGUrIEZpeGVkKw0KCUNhcGFiaWxpdGllczogWzEw
MCB2MV0gVmVuZG9yIFNwZWNpZmljIEluZm9ybWF0aW9uOiBJRD0wMDAxIFJldj0xIExlbj0w
MTAgPD8+DQoJQ2FwYWJpbGl0aWVzOiBbMTkwIHYxXSBBY2Nlc3MgQ29udHJvbCBTZXJ2aWNl
cw0KCQlBQ1NDYXA6CVNyY1ZhbGlkKyBUcmFuc0JsaysgUmVxUmVkaXIrIENtcGx0UmVkaXIr
IFVwc3RyZWFtRndkKyBFZ3Jlc3NDdHJsLSBEaXJlY3RUcmFucysNCgkJQUNTQ3RsOglTcmNW
YWxpZCsgVHJhbnNCbGstIFJlcVJlZGlyKyBDbXBsdFJlZGlyKyBVcHN0cmVhbUZ3ZCsgRWdy
ZXNzQ3RybC0gRGlyZWN0VHJhbnMtDQoJS2VybmVsIGRyaXZlciBpbiB1c2U6IHBjaWVwb3J0
DQoNCjAwOjBiLjAgUENJIGJyaWRnZSBbMDYwNF06IEFUSSBUZWNobm9sb2dpZXMgSW5jIFJE
ODkwIFBDSSB0byBQQ0kgYnJpZGdlIChOQi1TQiBsaW5rKSBbMTAwMjo1YTFmXSAocHJvZy1p
ZiAwMCBbTm9ybWFsIGRlY29kZV0pDQoJQ29udHJvbDogSS9PKyBNZW0rIEJ1c01hc3Rlcisg
U3BlY0N5Y2xlLSBNZW1XSU5WLSBWR0FTbm9vcC0gUGFyRXJyLSBTdGVwcGluZy0gU0VSUisg
RmFzdEIyQi0gRGlzSU5UeCsNCglTdGF0dXM6IENhcCsgNjZNSHotIFVERi0gRmFzdEIyQi0g
UGFyRXJyLSBERVZTRUw9ZmFzdCA+VEFib3J0LSA8VEFib3J0LSA8TUFib3J0LSA+U0VSUi0g
PFBFUlItIElOVHgtDQoJTGF0ZW5jeTogMCwgQ2FjaGUgTGluZSBTaXplOiA2NCBieXRlcw0K
CUJ1czogcHJpbWFyeT0wMCwgc2Vjb25kYXJ5PTA1LCBzdWJvcmRpbmF0ZT0wNSwgc2VjLWxh
dGVuY3k9MA0KCUkvTyBiZWhpbmQgYnJpZGdlOiAwMDAwYjAwMC0wMDAwYmZmZg0KCU1lbW9y
eSBiZWhpbmQgYnJpZGdlOiBmOTkwMDAwMC1mOTlmZmZmZg0KCVByZWZldGNoYWJsZSBtZW1v
cnkgYmVoaW5kIGJyaWRnZTogMDAwMDAwMDBiMDAwMDAwMC0wMDAwMDAwMGJmZmZmZmZmDQoJ
U2Vjb25kYXJ5IHN0YXR1czogNjZNSHotIEZhc3RCMkItIFBhckVyci0gREVWU0VMPWZhc3Qg
PlRBYm9ydC0gPFRBYm9ydC0gPE1BYm9ydC0gPFNFUlItIDxQRVJSLQ0KCUJyaWRnZUN0bDog
UGFyaXR5KyBTRVJSKyBOb0lTQSsgVkdBLSBNQWJvcnQtID5SZXNldC0gRmFzdEIyQi0NCgkJ
UHJpRGlzY1Rtci0gU2VjRGlzY1Rtci0gRGlzY1RtclN0YXQtIERpc2NUbXJTRVJSRW4tDQoJ
Q2FwYWJpbGl0aWVzOiBbNTBdIFBvd2VyIE1hbmFnZW1lbnQgdmVyc2lvbiAzDQoJCUZsYWdz
OiBQTUVDbGstIERTSS0gRDEtIEQyLSBBdXhDdXJyZW50PTBtQSBQTUUoRDArLEQxLSxEMi0s
RDNob3QrLEQzY29sZCspDQoJCVN0YXR1czogRDAgTm9Tb2Z0UnN0LSBQTUUtRW5hYmxlLSBE
U2VsPTAgRFNjYWxlPTAgUE1FLQ0KCUNhcGFiaWxpdGllczogWzU4XSBFeHByZXNzICh2Mikg
Um9vdCBQb3J0IChTbG90KyksIE1TSSAwMA0KCQlEZXZDYXA6CU1heFBheWxvYWQgMTI4IGJ5
dGVzLCBQaGFudEZ1bmMgMCwgTGF0ZW5jeSBMMHMgPDY0bnMsIEwxIDwxdXMNCgkJCUV4dFRh
ZysgUkJFKyBGTFJlc2V0LQ0KCQlEZXZDdGw6CVJlcG9ydCBlcnJvcnM6IENvcnJlY3RhYmxl
LSBOb24tRmF0YWwtIEZhdGFsLSBVbnN1cHBvcnRlZC0NCgkJCVJseGRPcmQrIEV4dFRhZy0g
UGhhbnRGdW5jLSBBdXhQd3ItIE5vU25vb3ArDQoJCQlNYXhQYXlsb2FkIDEyOCBieXRlcywg
TWF4UmVhZFJlcSAxMjggYnl0ZXMNCgkJRGV2U3RhOglDb3JyRXJyLSBVbmNvcnJFcnItIEZh
dGFsRXJyLSBVbnN1cHBSZXEtIEF1eFB3ci0gVHJhbnNQZW5kLQ0KCQlMbmtDYXA6CVBvcnQg
IzAsIFNwZWVkIDVHVC9zLCBXaWR0aCB4MTYsIEFTUE0gTDBzIEwxLCBMYXRlbmN5IEwwIDwx
dXMsIEwxIDw4dXMNCgkJCUNsb2NrUE0tIFN1cnByaXNlLSBMTEFjdFJlcCsgQndOb3QrDQoJ
CUxua0N0bDoJQVNQTSBEaXNhYmxlZDsgUkNCIDY0IGJ5dGVzIERpc2FibGVkLSBSZXRyYWlu
LSBDb21tQ2xrKw0KCQkJRXh0U3luY2gtIENsb2NrUE0tIEF1dFdpZERpcy0gQldJbnQtIEF1
dEJXSW50LQ0KCQlMbmtTdGE6CVNwZWVkIDIuNUdUL3MsIFdpZHRoIHgxNiwgVHJFcnItIFRy
YWluLSBTbG90Q2xrKyBETEFjdGl2ZSsgQldNZ210KyBBQldNZ210LQ0KCQlTbHRDYXA6CUF0
dG5CdG4tIFB3ckN0cmwtIE1STC0gQXR0bkluZC0gUHdySW5kLSBIb3RQbHVnLSBTdXJwcmlz
ZS0NCgkJCVNsb3QgIzUsIFBvd2VyTGltaXQgNzUuMDAwVzsgSW50ZXJsb2NrLSBOb0NvbXBs
Kw0KCQlTbHRDdGw6CUVuYWJsZTogQXR0bkJ0bi0gUHdyRmx0LSBNUkwtIFByZXNEZXQtIENt
ZENwbHQtIEhQSXJxLSBMaW5rQ2hnLQ0KCQkJQ29udHJvbDogQXR0bkluZCBVbmtub3duLCBQ
d3JJbmQgVW5rbm93biwgUG93ZXItIEludGVybG9jay0NCgkJU2x0U3RhOglTdGF0dXM6IEF0
dG5CdG4tIFBvd2VyRmx0LSBNUkwtIENtZENwbHQtIFByZXNEZXQrIEludGVybG9jay0NCgkJ
CUNoYW5nZWQ6IE1STC0gUHJlc0RldCsgTGlua1N0YXRlKw0KCQlSb290Q3RsOiBFcnJDb3Jy
ZWN0YWJsZS0gRXJyTm9uLUZhdGFsLSBFcnJGYXRhbC0gUE1FSW50RW5hLSBDUlNWaXNpYmxl
LQ0KCQlSb290Q2FwOiBDUlNWaXNpYmxlLQ0KCQlSb290U3RhOiBQTUUgUmVxSUQgMDAwMCwg
UE1FU3RhdHVzLSBQTUVQZW5kaW5nLQ0KCQlEZXZDYXAyOiBDb21wbGV0aW9uIFRpbWVvdXQ6
IFJhbmdlIEFCQ0QsIFRpbWVvdXREaXMrIEFSSUZ3ZCsNCgkJRGV2Q3RsMjogQ29tcGxldGlv
biBUaW1lb3V0OiA2NW1zIHRvIDIxMG1zLCBUaW1lb3V0RGlzLSBBUklGd2QtDQoJCUxua0N0
bDI6IFRhcmdldCBMaW5rIFNwZWVkOiA1R1QvcywgRW50ZXJDb21wbGlhbmNlLSBTcGVlZERp
cy0sIFNlbGVjdGFibGUgRGUtZW1waGFzaXM6IC0zLjVkQg0KCQkJIFRyYW5zbWl0IE1hcmdp
bjogTm9ybWFsIE9wZXJhdGluZyBSYW5nZSwgRW50ZXJNb2RpZmllZENvbXBsaWFuY2UtIENv
bXBsaWFuY2VTT1MtDQoJCQkgQ29tcGxpYW5jZSBEZS1lbXBoYXNpczogLTZkQg0KCQlMbmtT
dGEyOiBDdXJyZW50IERlLWVtcGhhc2lzIExldmVsOiAtMy41ZEINCglDYXBhYmlsaXRpZXM6
IFthMF0gTVNJOiBFbmFibGUrIENvdW50PTEvMSBNYXNrYWJsZS0gNjRiaXQtDQoJCUFkZHJl
c3M6IGZlZTNmMDBjICBEYXRhOiA0MTc5DQoJQ2FwYWJpbGl0aWVzOiBbYjBdIFN1YnN5c3Rl
bTogQVRJIFRlY2hub2xvZ2llcyBJbmMgRGV2aWNlIFsxMDAyOjVhMTFdDQoJQ2FwYWJpbGl0
aWVzOiBbYjhdIEh5cGVyVHJhbnNwb3J0OiBNU0kgTWFwcGluZyBFbmFibGUrIEZpeGVkKw0K
CUNhcGFiaWxpdGllczogWzEwMCB2MV0gVmVuZG9yIFNwZWNpZmljIEluZm9ybWF0aW9uOiBJ
RD0wMDAxIFJldj0xIExlbj0wMTAgPD8+DQoJQ2FwYWJpbGl0aWVzOiBbMTkwIHYxXSBBY2Nl
c3MgQ29udHJvbCBTZXJ2aWNlcw0KCQlBQ1NDYXA6CVNyY1ZhbGlkKyBUcmFuc0JsaysgUmVx
UmVkaXIrIENtcGx0UmVkaXIrIFVwc3RyZWFtRndkKyBFZ3Jlc3NDdHJsLSBEaXJlY3RUcmFu
cysNCgkJQUNTQ3RsOglTcmNWYWxpZCsgVHJhbnNCbGstIFJlcVJlZGlyKyBDbXBsdFJlZGly
KyBVcHN0cmVhbUZ3ZCsgRWdyZXNzQ3RybC0gRGlyZWN0VHJhbnMtDQoJS2VybmVsIGRyaXZl
ciBpbiB1c2U6IHBjaWVwb3J0DQoNCjAwOjBkLjAgUENJIGJyaWRnZSBbMDYwNF06IEFUSSBU
ZWNobm9sb2dpZXMgSW5jIFJEODkwIFBDSSB0byBQQ0kgYnJpZGdlIChleHRlcm5hbCBnZngx
IHBvcnQgQikgWzEwMDI6NWExZV0gKHByb2ctaWYgMDAgW05vcm1hbCBkZWNvZGVdKQ0KCUNv
bnRyb2w6IEkvTy0gTWVtKyBCdXNNYXN0ZXIrIFNwZWNDeWNsZS0gTWVtV0lOVi0gVkdBU25v
b3AtIFBhckVyci0gU3RlcHBpbmctIFNFUlIrIEZhc3RCMkItIERpc0lOVHgrDQoJU3RhdHVz
OiBDYXArIDY2TUh6LSBVREYtIEZhc3RCMkItIFBhckVyci0gREVWU0VMPWZhc3QgPlRBYm9y
dC0gPFRBYm9ydC0gPE1BYm9ydC0gPlNFUlItIDxQRVJSLSBJTlR4LQ0KCUxhdGVuY3k6IDAs
IENhY2hlIExpbmUgU2l6ZTogNjQgYnl0ZXMNCglCdXM6IHByaW1hcnk9MDAsIHNlY29uZGFy
eT0wNCwgc3Vib3JkaW5hdGU9MDQsIHNlYy1sYXRlbmN5PTANCglJL08gYmVoaW5kIGJyaWRn
ZTogMDAwMGYwMDAtMDAwMDBmZmYNCglNZW1vcnkgYmVoaW5kIGJyaWRnZTogZjk4MDAwMDAt
Zjk4ZmZmZmYNCglQcmVmZXRjaGFibGUgbWVtb3J5IGJlaGluZCBicmlkZ2U6IDAwMDAwMDAw
ZmZmMDAwMDAtMDAwMDAwMDAwMDBmZmZmZg0KCVNlY29uZGFyeSBzdGF0dXM6IDY2TUh6LSBG
YXN0QjJCLSBQYXJFcnItIERFVlNFTD1mYXN0ID5UQWJvcnQtIDxUQWJvcnQtIDxNQWJvcnQt
IDxTRVJSLSA8UEVSUi0NCglCcmlkZ2VDdGw6IFBhcml0eSsgU0VSUisgTm9JU0ErIFZHQS0g
TUFib3J0LSA+UmVzZXQtIEZhc3RCMkItDQoJCVByaURpc2NUbXItIFNlY0Rpc2NUbXItIERp
c2NUbXJTdGF0LSBEaXNjVG1yU0VSUkVuLQ0KCUNhcGFiaWxpdGllczogWzUwXSBQb3dlciBN
YW5hZ2VtZW50IHZlcnNpb24gMw0KCQlGbGFnczogUE1FQ2xrLSBEU0ktIEQxLSBEMi0gQXV4
Q3VycmVudD0wbUEgUE1FKEQwKyxEMS0sRDItLEQzaG90KyxEM2NvbGQrKQ0KCQlTdGF0dXM6
IEQwIE5vU29mdFJzdC0gUE1FLUVuYWJsZS0gRFNlbD0wIERTY2FsZT0wIFBNRS0NCglDYXBh
YmlsaXRpZXM6IFs1OF0gRXhwcmVzcyAodjIpIFJvb3QgUG9ydCAoU2xvdCspLCBNU0kgMDAN
CgkJRGV2Q2FwOglNYXhQYXlsb2FkIDEyOCBieXRlcywgUGhhbnRGdW5jIDAsIExhdGVuY3kg
TDBzIDw2NG5zLCBMMSA8MXVzDQoJCQlFeHRUYWcrIFJCRSsgRkxSZXNldC0NCgkJRGV2Q3Rs
OglSZXBvcnQgZXJyb3JzOiBDb3JyZWN0YWJsZS0gTm9uLUZhdGFsLSBGYXRhbC0gVW5zdXBw
b3J0ZWQtDQoJCQlSbHhkT3JkKyBFeHRUYWctIFBoYW50RnVuYy0gQXV4UHdyLSBOb1Nub29w
Kw0KCQkJTWF4UGF5bG9hZCAxMjggYnl0ZXMsIE1heFJlYWRSZXEgMTI4IGJ5dGVzDQoJCURl
dlN0YToJQ29yckVyci0gVW5jb3JyRXJyLSBGYXRhbEVyci0gVW5zdXBwUmVxLSBBdXhQd3It
IFRyYW5zUGVuZC0NCgkJTG5rQ2FwOglQb3J0ICMwLCBTcGVlZCA1R1QvcywgV2lkdGggeDQs
IEFTUE0gTDBzIEwxLCBMYXRlbmN5IEwwIDwxdXMsIEwxIDw4dXMNCgkJCUNsb2NrUE0tIFN1
cnByaXNlLSBMTEFjdFJlcCsgQndOb3QrDQoJCUxua0N0bDoJQVNQTSBEaXNhYmxlZDsgUkNC
IDY0IGJ5dGVzIERpc2FibGVkLSBSZXRyYWluLSBDb21tQ2xrLQ0KCQkJRXh0U3luY2gtIENs
b2NrUE0tIEF1dFdpZERpcy0gQldJbnQtIEF1dEJXSW50LQ0KCQlMbmtTdGE6CVNwZWVkIDIu
NUdUL3MsIFdpZHRoIHgxLCBUckVyci0gVHJhaW4tIFNsb3RDbGsrIERMQWN0aXZlKyBCV01n
bXQrIEFCV01nbXQtDQoJCVNsdENhcDoJQXR0bkJ0bi0gUHdyQ3RybC0gTVJMLSBBdHRuSW5k
LSBQd3JJbmQtIEhvdFBsdWctIFN1cnByaXNlLQ0KCQkJU2xvdCAjNCwgUG93ZXJMaW1pdCA3
NS4wMDBXOyBJbnRlcmxvY2stIE5vQ29tcGwrDQoJCVNsdEN0bDoJRW5hYmxlOiBBdHRuQnRu
LSBQd3JGbHQtIE1STC0gUHJlc0RldC0gQ21kQ3BsdC0gSFBJcnEtIExpbmtDaGctDQoJCQlD
b250cm9sOiBBdHRuSW5kIFVua25vd24sIFB3ckluZCBVbmtub3duLCBQb3dlci0gSW50ZXJs
b2NrLQ0KCQlTbHRTdGE6CVN0YXR1czogQXR0bkJ0bi0gUG93ZXJGbHQtIE1STC0gQ21kQ3Bs
dC0gUHJlc0RldCsgSW50ZXJsb2NrLQ0KCQkJQ2hhbmdlZDogTVJMLSBQcmVzRGV0KyBMaW5r
U3RhdGUrDQoJCVJvb3RDdGw6IEVyckNvcnJlY3RhYmxlLSBFcnJOb24tRmF0YWwtIEVyckZh
dGFsLSBQTUVJbnRFbmEtIENSU1Zpc2libGUtDQoJCVJvb3RDYXA6IENSU1Zpc2libGUtDQoJ
CVJvb3RTdGE6IFBNRSBSZXFJRCAwMDAwLCBQTUVTdGF0dXMtIFBNRVBlbmRpbmctDQoJCURl
dkNhcDI6IENvbXBsZXRpb24gVGltZW91dDogUmFuZ2UgQUJDRCwgVGltZW91dERpcysgQVJJ
RndkKw0KCQlEZXZDdGwyOiBDb21wbGV0aW9uIFRpbWVvdXQ6IDY1bXMgdG8gMjEwbXMsIFRp
bWVvdXREaXMtIEFSSUZ3ZC0NCgkJTG5rQ3RsMjogVGFyZ2V0IExpbmsgU3BlZWQ6IDVHVC9z
LCBFbnRlckNvbXBsaWFuY2UtIFNwZWVkRGlzLSwgU2VsZWN0YWJsZSBEZS1lbXBoYXNpczog
LTMuNWRCDQoJCQkgVHJhbnNtaXQgTWFyZ2luOiBOb3JtYWwgT3BlcmF0aW5nIFJhbmdlLCBF
bnRlck1vZGlmaWVkQ29tcGxpYW5jZS0gQ29tcGxpYW5jZVNPUy0NCgkJCSBDb21wbGlhbmNl
IERlLWVtcGhhc2lzOiAtNmRCDQoJCUxua1N0YTI6IEN1cnJlbnQgRGUtZW1waGFzaXMgTGV2
ZWw6IC0zLjVkQg0KCUNhcGFiaWxpdGllczogW2EwXSBNU0k6IEVuYWJsZSsgQ291bnQ9MS8x
IE1hc2thYmxlLSA2NGJpdC0NCgkJQWRkcmVzczogZmVlM2YwMGMgIERhdGE6IDQxODENCglD
YXBhYmlsaXRpZXM6IFtiMF0gU3Vic3lzdGVtOiBBVEkgVGVjaG5vbG9naWVzIEluYyBEZXZp
Y2UgWzEwMDI6NWExMV0NCglDYXBhYmlsaXRpZXM6IFtiOF0gSHlwZXJUcmFuc3BvcnQ6IE1T
SSBNYXBwaW5nIEVuYWJsZSsgRml4ZWQrDQoJQ2FwYWJpbGl0aWVzOiBbMTAwIHYxXSBWZW5k
b3IgU3BlY2lmaWMgSW5mb3JtYXRpb246IElEPTAwMDEgUmV2PTEgTGVuPTAxMCA8Pz4NCglD
YXBhYmlsaXRpZXM6IFsxOTAgdjFdIEFjY2VzcyBDb250cm9sIFNlcnZpY2VzDQoJCUFDU0Nh
cDoJU3JjVmFsaWQrIFRyYW5zQmxrKyBSZXFSZWRpcisgQ21wbHRSZWRpcisgVXBzdHJlYW1G
d2QrIEVncmVzc0N0cmwtIERpcmVjdFRyYW5zKw0KCQlBQ1NDdGw6CVNyY1ZhbGlkKyBUcmFu
c0Jsay0gUmVxUmVkaXIrIENtcGx0UmVkaXIrIFVwc3RyZWFtRndkKyBFZ3Jlc3NDdHJsLSBE
aXJlY3RUcmFucy0NCglLZXJuZWwgZHJpdmVyIGluIHVzZTogcGNpZXBvcnQNCg0KMDA6MTEu
MCBTQVRBIGNvbnRyb2xsZXIgWzAxMDZdOiBBVEkgVGVjaG5vbG9naWVzIEluYyBTQjd4MC9T
Qjh4MC9TQjl4MCBTQVRBIENvbnRyb2xsZXIgW0lERSBtb2RlXSBbMTAwMjo0MzkwXSAocmV2
IDQwKSAocHJvZy1pZiAwMSBbQUhDSSAxLjBdKQ0KCVN1YnN5c3RlbTogTWljcm8tU3RhciBJ
bnRlcm5hdGlvbmFsIENvLiwgTHRkLiBEZXZpY2UgWzE0NjI6NzY0MF0NCglDb250cm9sOiBJ
L08rIE1lbSsgQnVzTWFzdGVyKyBTcGVjQ3ljbGUtIE1lbVdJTlYtIFZHQVNub29wLSBQYXJF
cnItIFN0ZXBwaW5nLSBTRVJSKyBGYXN0QjJCLSBEaXNJTlR4Kw0KCVN0YXR1czogQ2FwKyA2
Nk1IeisgVURGLSBGYXN0QjJCLSBQYXJFcnItIERFVlNFTD1tZWRpdW0gPlRBYm9ydC0gPFRB
Ym9ydC0gPE1BYm9ydC0gPlNFUlItIDxQRVJSLSBJTlR4LQ0KCUxhdGVuY3k6IDY0LCBDYWNo
ZSBMaW5lIFNpemU6IDY0IGJ5dGVzDQoJSW50ZXJydXB0OiBwaW4gQSByb3V0ZWQgdG8gSVJR
IDExOQ0KCVJlZ2lvbiAwOiBJL08gcG9ydHMgYXQgNzAwMCBbc2l6ZT04XQ0KCVJlZ2lvbiAx
OiBJL08gcG9ydHMgYXQgNjAwMCBbc2l6ZT00XQ0KCVJlZ2lvbiAyOiBJL08gcG9ydHMgYXQg
NTAwMCBbc2l6ZT04XQ0KCVJlZ2lvbiAzOiBJL08gcG9ydHMgYXQgMzAwMCBbc2l6ZT00XQ0K
CVJlZ2lvbiA0OiBJL08gcG9ydHMgYXQgMjAwMCBbc2l6ZT0xNl0NCglSZWdpb24gNTogTWVt
b3J5IGF0IGY5NmZmMDAwICgzMi1iaXQsIG5vbi1wcmVmZXRjaGFibGUpIFtzaXplPTFLXQ0K
CUNhcGFiaWxpdGllczogWzUwXSBNU0k6IEVuYWJsZSsgQ291bnQ9MS80IE1hc2thYmxlLSA2
NGJpdCsNCgkJQWRkcmVzczogMDAwMDAwMDBmZWUwMTAwYyAgRGF0YTogNDFhOQ0KCUNhcGFi
aWxpdGllczogWzcwXSBTQVRBIEhCQSB2MS4wIEluQ2ZnU3BhY2UNCglDYXBhYmlsaXRpZXM6
IFthNF0gUENJIEFkdmFuY2VkIEZlYXR1cmVzDQoJCUFGQ2FwOiBUUCsgRkxSKw0KCQlBRkN0
cmw6IEZMUi0NCgkJQUZTdGF0dXM6IFRQLQ0KCUtlcm5lbCBkcml2ZXIgaW4gdXNlOiBhaGNp
DQoNCjAwOjEyLjAgVVNCIGNvbnRyb2xsZXIgWzBjMDNdOiBBVEkgVGVjaG5vbG9naWVzIElu
YyBTQjd4MC9TQjh4MC9TQjl4MCBVU0IgT0hDSTAgQ29udHJvbGxlciBbMTAwMjo0Mzk3XSAo
cHJvZy1pZiAxMCBbT0hDSV0pDQoJU3Vic3lzdGVtOiBNaWNyby1TdGFyIEludGVybmF0aW9u
YWwgQ28uLCBMdGQuIERldmljZSBbMTQ2Mjo3NjQwXQ0KCUNvbnRyb2w6IEkvTysgTWVtKyBC
dXNNYXN0ZXIrIFNwZWNDeWNsZS0gTWVtV0lOVisgVkdBU25vb3AtIFBhckVyci0gU3RlcHBp
bmctIFNFUlIrIEZhc3RCMkItIERpc0lOVHgtDQoJU3RhdHVzOiBDYXAtIDY2TUh6KyBVREYt
IEZhc3RCMkIrIFBhckVyci0gREVWU0VMPW1lZGl1bSA+VEFib3J0LSA8VEFib3J0LSA8TUFi
b3J0LSA+U0VSUi0gPFBFUlItIElOVHgtDQoJTGF0ZW5jeTogNjQsIENhY2hlIExpbmUgU2l6
ZTogNjQgYnl0ZXMNCglJbnRlcnJ1cHQ6IHBpbiBBIHJvdXRlZCB0byBJUlEgMTgNCglSZWdp
b24gMDogTWVtb3J5IGF0IGY5NmY3MDAwICgzMi1iaXQsIG5vbi1wcmVmZXRjaGFibGUpIFtz
aXplPTRLXQ0KCUtlcm5lbCBkcml2ZXIgaW4gdXNlOiBvaGNpX2hjZA0KDQowMDoxMi4yIFVT
QiBjb250cm9sbGVyIFswYzAzXTogQVRJIFRlY2hub2xvZ2llcyBJbmMgU0I3eDAvU0I4eDAv
U0I5eDAgVVNCIEVIQ0kgQ29udHJvbGxlciBbMTAwMjo0Mzk2XSAocHJvZy1pZiAyMCBbRUhD
SV0pDQoJU3Vic3lzdGVtOiBNaWNyby1TdGFyIEludGVybmF0aW9uYWwgQ28uLCBMdGQuIERl
dmljZSBbMTQ2Mjo3NjQwXQ0KCUNvbnRyb2w6IEkvTy0gTWVtKyBCdXNNYXN0ZXIrIFNwZWND
eWNsZS0gTWVtV0lOVisgVkdBU25vb3AtIFBhckVyci0gU3RlcHBpbmctIFNFUlIrIEZhc3RC
MkItIERpc0lOVHgtDQoJU3RhdHVzOiBDYXArIDY2TUh6KyBVREYtIEZhc3RCMkIrIFBhckVy
ci0gREVWU0VMPW1lZGl1bSA+VEFib3J0LSA8VEFib3J0LSA8TUFib3J0LSA+U0VSUi0gPFBF
UlItIElOVHgtDQoJTGF0ZW5jeTogNjQsIENhY2hlIExpbmUgU2l6ZTogNjQgYnl0ZXMNCglJ
bnRlcnJ1cHQ6IHBpbiBCIHJvdXRlZCB0byBJUlEgMTcNCglSZWdpb24gMDogTWVtb3J5IGF0
IGY5NmZmNDAwICgzMi1iaXQsIG5vbi1wcmVmZXRjaGFibGUpIFtzaXplPTI1Nl0NCglDYXBh
YmlsaXRpZXM6IFtjMF0gUG93ZXIgTWFuYWdlbWVudCB2ZXJzaW9uIDINCgkJRmxhZ3M6IFBN
RUNsay0gRFNJLSBEMSsgRDIrIEF1eEN1cnJlbnQ9MG1BIFBNRShEMCssRDErLEQyKyxEM2hv
dCssRDNjb2xkLSkNCgkJU3RhdHVzOiBEMCBOb1NvZnRSc3QtIFBNRS1FbmFibGUtIERTZWw9
MCBEU2NhbGU9MCBQTUUtDQoJCUJyaWRnZTogUE0tIEIzKw0KCUNhcGFiaWxpdGllczogW2U0
XSBEZWJ1ZyBwb3J0OiBCQVI9MSBvZmZzZXQ9MDBlMA0KCUtlcm5lbCBkcml2ZXIgaW4gdXNl
OiBlaGNpX2hjZA0KDQowMDoxMy4wIFVTQiBjb250cm9sbGVyIFswYzAzXTogQVRJIFRlY2hu
b2xvZ2llcyBJbmMgU0I3eDAvU0I4eDAvU0I5eDAgVVNCIE9IQ0kwIENvbnRyb2xsZXIgWzEw
MDI6NDM5N10gKHByb2ctaWYgMTAgW09IQ0ldKQ0KCVN1YnN5c3RlbTogTWljcm8tU3RhciBJ
bnRlcm5hdGlvbmFsIENvLiwgTHRkLiBEZXZpY2UgWzE0NjI6NzY0MF0NCglDb250cm9sOiBJ
L08rIE1lbSsgQnVzTWFzdGVyKyBTcGVjQ3ljbGUtIE1lbVdJTlYrIFZHQVNub29wLSBQYXJF
cnItIFN0ZXBwaW5nLSBTRVJSKyBGYXN0QjJCLSBEaXNJTlR4LQ0KCVN0YXR1czogQ2FwLSA2
Nk1IeisgVURGLSBGYXN0QjJCKyBQYXJFcnItIERFVlNFTD1tZWRpdW0gPlRBYm9ydC0gPFRB
Ym9ydC0gPE1BYm9ydC0gPlNFUlItIDxQRVJSLSBJTlR4LQ0KCUxhdGVuY3k6IDY0LCBDYWNo
ZSBMaW5lIFNpemU6IDY0IGJ5dGVzDQoJSW50ZXJydXB0OiBwaW4gQSByb3V0ZWQgdG8gSVJR
IDE4DQoJUmVnaW9uIDA6IE1lbW9yeSBhdCBmOTZmYzAwMCAoMzItYml0LCBub24tcHJlZmV0
Y2hhYmxlKSBbc2l6ZT00S10NCglLZXJuZWwgZHJpdmVyIGluIHVzZTogb2hjaV9oY2QNCg0K
MDA6MTMuMiBVU0IgY29udHJvbGxlciBbMGMwM106IEFUSSBUZWNobm9sb2dpZXMgSW5jIFNC
N3gwL1NCOHgwL1NCOXgwIFVTQiBFSENJIENvbnRyb2xsZXIgWzEwMDI6NDM5Nl0gKHByb2ct
aWYgMjAgW0VIQ0ldKQ0KCVN1YnN5c3RlbTogTWljcm8tU3RhciBJbnRlcm5hdGlvbmFsIENv
LiwgTHRkLiBEZXZpY2UgWzE0NjI6NzY0MF0NCglDb250cm9sOiBJL08tIE1lbSsgQnVzTWFz
dGVyKyBTcGVjQ3ljbGUtIE1lbVdJTlYrIFZHQVNub29wLSBQYXJFcnItIFN0ZXBwaW5nLSBT
RVJSKyBGYXN0QjJCLSBEaXNJTlR4LQ0KCVN0YXR1czogQ2FwKyA2Nk1IeisgVURGLSBGYXN0
QjJCKyBQYXJFcnItIERFVlNFTD1tZWRpdW0gPlRBYm9ydC0gPFRBYm9ydC0gPE1BYm9ydC0g
PlNFUlItIDxQRVJSLSBJTlR4LQ0KCUxhdGVuY3k6IDY0LCBDYWNoZSBMaW5lIFNpemU6IDY0
IGJ5dGVzDQoJSW50ZXJydXB0OiBwaW4gQiByb3V0ZWQgdG8gSVJRIDE3DQoJUmVnaW9uIDA6
IE1lbW9yeSBhdCBmOTZmZjgwMCAoMzItYml0LCBub24tcHJlZmV0Y2hhYmxlKSBbc2l6ZT0y
NTZdDQoJQ2FwYWJpbGl0aWVzOiBbYzBdIFBvd2VyIE1hbmFnZW1lbnQgdmVyc2lvbiAyDQoJ
CUZsYWdzOiBQTUVDbGstIERTSS0gRDErIEQyKyBBdXhDdXJyZW50PTBtQSBQTUUoRDArLEQx
KyxEMissRDNob3QrLEQzY29sZC0pDQoJCVN0YXR1czogRDAgTm9Tb2Z0UnN0LSBQTUUtRW5h
YmxlLSBEU2VsPTAgRFNjYWxlPTAgUE1FLQ0KCQlCcmlkZ2U6IFBNLSBCMysNCglDYXBhYmls
aXRpZXM6IFtlNF0gRGVidWcgcG9ydDogQkFSPTEgb2Zmc2V0PTAwZTANCglLZXJuZWwgZHJp
dmVyIGluIHVzZTogZWhjaV9oY2QNCg0KMDA6MTQuMCBTTUJ1cyBbMGMwNV06IEFUSSBUZWNo
bm9sb2dpZXMgSW5jIFNCeDAwIFNNQnVzIENvbnRyb2xsZXIgWzEwMDI6NDM4NV0gKHJldiA0
MSkNCglDb250cm9sOiBJL08rIE1lbSsgQnVzTWFzdGVyLSBTcGVjQ3ljbGUtIE1lbVdJTlYt
IFZHQVNub29wLSBQYXJFcnItIFN0ZXBwaW5nLSBTRVJSLSBGYXN0QjJCLSBEaXNJTlR4Kw0K
CVN0YXR1czogQ2FwLSA2Nk1IeisgVURGLSBGYXN0QjJCLSBQYXJFcnItIERFVlNFTD1tZWRp
dW0gPlRBYm9ydC0gPFRBYm9ydC0gPE1BYm9ydC0gPlNFUlItIDxQRVJSLSBJTlR4LQ0KDQow
MDoxNC4xIElERSBpbnRlcmZhY2UgWzAxMDFdOiBBVEkgVGVjaG5vbG9naWVzIEluYyBTQjd4
MC9TQjh4MC9TQjl4MCBJREUgQ29udHJvbGxlciBbMTAwMjo0MzljXSAocmV2IDQwKSAocHJv
Zy1pZiA4YSBbTWFzdGVyIFNlY1AgUHJpUF0pDQoJU3Vic3lzdGVtOiBNaWNyby1TdGFyIElu
dGVybmF0aW9uYWwgQ28uLCBMdGQuIERldmljZSBbMTQ2Mjo3NjQwXQ0KCUNvbnRyb2w6IEkv
TysgTWVtLSBCdXNNYXN0ZXIrIFNwZWNDeWNsZS0gTWVtV0lOVi0gVkdBU25vb3AtIFBhckVy
ci0gU3RlcHBpbmctIFNFUlItIEZhc3RCMkItIERpc0lOVHgtDQoJU3RhdHVzOiBDYXAtIDY2
TUh6KyBVREYtIEZhc3RCMkItIFBhckVyci0gREVWU0VMPW1lZGl1bSA+VEFib3J0LSA8VEFi
b3J0LSA8TUFib3J0LSA+U0VSUi0gPFBFUlItIElOVHgtDQoJTGF0ZW5jeTogMA0KCUludGVy
cnVwdDogcGluIEIgcm91dGVkIHRvIElSUSAwDQoJUmVnaW9uIDA6IEkvTyBwb3J0cyBhdCAw
MWYwIFtzaXplPThdDQoJUmVnaW9uIDE6IEkvTyBwb3J0cyBhdCAwM2Y0IFtzaXplPTFdDQoJ
UmVnaW9uIDI6IEkvTyBwb3J0cyBhdCAwMTcwIFtzaXplPThdDQoJUmVnaW9uIDM6IEkvTyBw
b3J0cyBhdCAwMzc0IFtzaXplPTFdDQoJUmVnaW9uIDQ6IEkvTyBwb3J0cyBhdCBmZjAwIFtz
aXplPTE2XQ0KDQowMDoxNC4yIEF1ZGlvIGRldmljZSBbMDQwM106IEFUSSBUZWNobm9sb2dp
ZXMgSW5jIFNCeDAwIEF6YWxpYSAoSW50ZWwgSERBKSBbMTAwMjo0MzgzXSAocmV2IDQwKQ0K
CVN1YnN5c3RlbTogTWljcm8tU3RhciBJbnRlcm5hdGlvbmFsIENvLiwgTHRkLiBEZXZpY2Ug
WzE0NjI6NzY0MF0NCglDb250cm9sOiBJL08tIE1lbSsgQnVzTWFzdGVyKyBTcGVjQ3ljbGUt
IE1lbVdJTlYtIFZHQVNub29wLSBQYXJFcnItIFN0ZXBwaW5nLSBTRVJSLSBGYXN0QjJCLSBE
aXNJTlR4LQ0KCVN0YXR1czogQ2FwKyA2Nk1Iei0gVURGLSBGYXN0QjJCLSBQYXJFcnItIERF
VlNFTD1zbG93ID5UQWJvcnQtIDxUQWJvcnQtIDxNQWJvcnQtID5TRVJSLSA8UEVSUi0gSU5U
eC0NCglMYXRlbmN5OiA2NCwgQ2FjaGUgTGluZSBTaXplOiA2NCBieXRlcw0KCUludGVycnVw
dDogcGluIEEgcm91dGVkIHRvIElSUSAxNg0KCVJlZ2lvbiAwOiBNZW1vcnkgYXQgZjk2Zjgw
MDAgKDY0LWJpdCwgbm9uLXByZWZldGNoYWJsZSkgW3NpemU9MTZLXQ0KCUNhcGFiaWxpdGll
czogWzUwXSBQb3dlciBNYW5hZ2VtZW50IHZlcnNpb24gMg0KCQlGbGFnczogUE1FQ2xrLSBE
U0ktIEQxLSBEMi0gQXV4Q3VycmVudD01NW1BIFBNRShEMCssRDEtLEQyLSxEM2hvdCssRDNj
b2xkKykNCgkJU3RhdHVzOiBEMCBOb1NvZnRSc3QtIFBNRS1FbmFibGUtIERTZWw9MCBEU2Nh
bGU9MCBQTUUtDQoJS2VybmVsIGRyaXZlciBpbiB1c2U6IHNuZF9oZGFfaW50ZWwNCg0KMDA6
MTQuMyBJU0EgYnJpZGdlIFswNjAxXTogQVRJIFRlY2hub2xvZ2llcyBJbmMgU0I3eDAvU0I4
eDAvU0I5eDAgTFBDIGhvc3QgY29udHJvbGxlciBbMTAwMjo0MzlkXSAocmV2IDQwKQ0KCVN1
YnN5c3RlbTogTWljcm8tU3RhciBJbnRlcm5hdGlvbmFsIENvLiwgTHRkLiBEZXZpY2UgWzE0
NjI6NzY0MF0NCglDb250cm9sOiBJL08rIE1lbSsgQnVzTWFzdGVyKyBTcGVjQ3ljbGUrIE1l
bVdJTlYtIFZHQVNub29wLSBQYXJFcnItIFN0ZXBwaW5nLSBTRVJSLSBGYXN0QjJCLSBEaXNJ
TlR4LQ0KCVN0YXR1czogQ2FwLSA2Nk1IeisgVURGLSBGYXN0QjJCLSBQYXJFcnItIERFVlNF
TD1tZWRpdW0gPlRBYm9ydC0gPFRBYm9ydC0gPE1BYm9ydC0gPlNFUlItIDxQRVJSLSBJTlR4
LQ0KCUxhdGVuY3k6IDANCg0KMDA6MTQuNCBQQ0kgYnJpZGdlIFswNjA0XTogQVRJIFRlY2hu
b2xvZ2llcyBJbmMgU0J4MDAgUENJIHRvIFBDSSBCcmlkZ2UgWzEwMDI6NDM4NF0gKHJldiA0
MCkgKHByb2ctaWYgMDAgW05vcm1hbCBkZWNvZGVdKQ0KCUNvbnRyb2w6IEkvTysgTWVtLSBC
dXNNYXN0ZXIrIFNwZWNDeWNsZS0gTWVtV0lOVi0gVkdBU25vb3AtIFBhckVyci0gU3RlcHBp
bmctIFNFUlIrIEZhc3RCMkItIERpc0lOVHgtDQoJU3RhdHVzOiBDYXAtIDY2TUh6KyBVREYt
IEZhc3RCMkIrIFBhckVyci0gREVWU0VMPW1lZGl1bSA+VEFib3J0LSA8VEFib3J0LSA8TUFi
b3J0LSA+U0VSUi0gPFBFUlItIElOVHgtDQoJTGF0ZW5jeTogNjQNCglCdXM6IHByaW1hcnk9
MDAsIHNlY29uZGFyeT0wMywgc3Vib3JkaW5hdGU9MDMsIHNlYy1sYXRlbmN5PTY0DQoJSS9P
IGJlaGluZCBicmlkZ2U6IDAwMDBhMDAwLTAwMDBhZmZmDQoJTWVtb3J5IGJlaGluZCBicmlk
Z2U6IGZmZjAwMDAwLTAwMGZmZmZmDQoJUHJlZmV0Y2hhYmxlIG1lbW9yeSBiZWhpbmQgYnJp
ZGdlOiBmZmYwMDAwMC0wMDBmZmZmZg0KCVNlY29uZGFyeSBzdGF0dXM6IDY2TUh6LSBGYXN0
QjJCKyBQYXJFcnItIERFVlNFTD1tZWRpdW0gPlRBYm9ydC0gPFRBYm9ydC0gPE1BYm9ydCsg
PFNFUlItIDxQRVJSLQ0KCUJyaWRnZUN0bDogUGFyaXR5KyBTRVJSKyBOb0lTQSsgVkdBLSBN
QWJvcnQtID5SZXNldC0gRmFzdEIyQi0NCgkJUHJpRGlzY1Rtci0gU2VjRGlzY1Rtci0gRGlz
Y1RtclN0YXQtIERpc2NUbXJTRVJSRW4tDQoNCjAwOjE0LjUgVVNCIGNvbnRyb2xsZXIgWzBj
MDNdOiBBVEkgVGVjaG5vbG9naWVzIEluYyBTQjd4MC9TQjh4MC9TQjl4MCBVU0IgT0hDSTIg
Q29udHJvbGxlciBbMTAwMjo0Mzk5XSAocHJvZy1pZiAxMCBbT0hDSV0pDQoJU3Vic3lzdGVt
OiBNaWNyby1TdGFyIEludGVybmF0aW9uYWwgQ28uLCBMdGQuIERldmljZSBbMTQ2Mjo3NjQw
XQ0KCUNvbnRyb2w6IEkvTysgTWVtKyBCdXNNYXN0ZXIrIFNwZWNDeWNsZS0gTWVtV0lOVisg
VkdBU25vb3AtIFBhckVyci0gU3RlcHBpbmctIFNFUlIrIEZhc3RCMkItIERpc0lOVHgtDQoJ
U3RhdHVzOiBDYXAtIDY2TUh6KyBVREYtIEZhc3RCMkIrIFBhckVyci0gREVWU0VMPW1lZGl1
bSA+VEFib3J0LSA8VEFib3J0LSA8TUFib3J0LSA+U0VSUi0gPFBFUlItIElOVHgtDQoJTGF0
ZW5jeTogNjQsIENhY2hlIExpbmUgU2l6ZTogNjQgYnl0ZXMNCglJbnRlcnJ1cHQ6IHBpbiBD
IHJvdXRlZCB0byBJUlEgMTgNCglSZWdpb24gMDogTWVtb3J5IGF0IGY5NmZkMDAwICgzMi1i
aXQsIG5vbi1wcmVmZXRjaGFibGUpIFtzaXplPTRLXQ0KCUtlcm5lbCBkcml2ZXIgaW4gdXNl
OiBvaGNpX2hjZA0KDQowMDoxNS4wIFBDSSBicmlkZ2UgWzA2MDRdOiBBVEkgVGVjaG5vbG9n
aWVzIEluYyBTQjcwMC9TQjgwMC9TQjkwMCBQQ0kgdG8gUENJIGJyaWRnZSAoUENJRSBwb3J0
IDApIFsxMDAyOjQzYTBdIChwcm9nLWlmIDAwIFtOb3JtYWwgZGVjb2RlXSkNCglDb250cm9s
OiBJL08tIE1lbS0gQnVzTWFzdGVyKyBTcGVjQ3ljbGUtIE1lbVdJTlYtIFZHQVNub29wLSBQ
YXJFcnItIFN0ZXBwaW5nLSBTRVJSKyBGYXN0QjJCLSBEaXNJTlR4Kw0KCVN0YXR1czogQ2Fw
KyA2Nk1Iei0gVURGLSBGYXN0QjJCLSBQYXJFcnItIERFVlNFTD1mYXN0ID5UQWJvcnQtIDxU
QWJvcnQtIDxNQWJvcnQtID5TRVJSLSA8UEVSUi0gSU5UeC0NCglMYXRlbmN5OiAwLCBDYWNo
ZSBMaW5lIFNpemU6IDY0IGJ5dGVzDQoJQnVzOiBwcmltYXJ5PTAwLCBzZWNvbmRhcnk9MDIs
IHN1Ym9yZGluYXRlPTAyLCBzZWMtbGF0ZW5jeT0wDQoJSS9PIGJlaGluZCBicmlkZ2U6IDAw
MDBmMDAwLTAwMDAwZmZmDQoJTWVtb3J5IGJlaGluZCBicmlkZ2U6IGZmZjAwMDAwLTAwMGZm
ZmZmDQoJUHJlZmV0Y2hhYmxlIG1lbW9yeSBiZWhpbmQgYnJpZGdlOiAwMDAwMDAwMGZmZjAw
MDAwLTAwMDAwMDAwMDAwZmZmZmYNCglTZWNvbmRhcnkgc3RhdHVzOiA2Nk1Iei0gRmFzdEIy
Qi0gUGFyRXJyLSBERVZTRUw9ZmFzdCA+VEFib3J0LSA8VEFib3J0LSA8TUFib3J0LSA8U0VS
Ui0gPFBFUlItDQoJQnJpZGdlQ3RsOiBQYXJpdHkrIFNFUlIrIE5vSVNBKyBWR0EtIE1BYm9y
dC0gPlJlc2V0LSBGYXN0QjJCLQ0KCQlQcmlEaXNjVG1yLSBTZWNEaXNjVG1yLSBEaXNjVG1y
U3RhdC0gRGlzY1RtclNFUlJFbi0NCglDYXBhYmlsaXRpZXM6IFs1MF0gUG93ZXIgTWFuYWdl
bWVudCB2ZXJzaW9uIDMNCgkJRmxhZ3M6IFBNRUNsay0gRFNJLSBEMSsgRDIrIEF1eEN1cnJl
bnQ9MG1BIFBNRShEMC0sRDEtLEQyLSxEM2hvdC0sRDNjb2xkLSkNCgkJU3RhdHVzOiBEMCBO
b1NvZnRSc3QtIFBNRS1FbmFibGUtIERTZWw9MCBEU2NhbGU9MCBQTUUtDQoJQ2FwYWJpbGl0
aWVzOiBbNThdIEV4cHJlc3MgKHYyKSBSb290IFBvcnQgKFNsb3QrKSwgTVNJIDAwDQoJCURl
dkNhcDoJTWF4UGF5bG9hZCAxMjggYnl0ZXMsIFBoYW50RnVuYyAwLCBMYXRlbmN5IEwwcyA8
NjRucywgTDEgPDF1cw0KCQkJRXh0VGFnKyBSQkUrIEZMUmVzZXQtDQoJCURldkN0bDoJUmVw
b3J0IGVycm9yczogQ29ycmVjdGFibGUtIE5vbi1GYXRhbC0gRmF0YWwtIFVuc3VwcG9ydGVk
LQ0KCQkJUmx4ZE9yZCsgRXh0VGFnLSBQaGFudEZ1bmMtIEF1eFB3ci0gTm9Tbm9vcCsNCgkJ
CU1heFBheWxvYWQgMTI4IGJ5dGVzLCBNYXhSZWFkUmVxIDEyOCBieXRlcw0KCQlEZXZTdGE6
CUNvcnJFcnItIFVuY29yckVyci0gRmF0YWxFcnItIFVuc3VwcFJlcS0gQXV4UHdyLSBUcmFu
c1BlbmQtDQoJCUxua0NhcDoJUG9ydCAjMjQ3LCBTcGVlZCAyLjVHVC9zLCBXaWR0aCB4MSwg
QVNQTSBMMHMgTDEsIExhdGVuY3kgTDAgPDY0bnMsIEwxIDwxdXMNCgkJCUNsb2NrUE0tIFN1
cnByaXNlLSBMTEFjdFJlcCsgQndOb3QrDQoJCUxua0N0bDoJQVNQTSBEaXNhYmxlZDsgUkNC
IDY0IGJ5dGVzIERpc2FibGVkLSBSZXRyYWluLSBDb21tQ2xrLQ0KCQkJRXh0U3luY2gtIENs
b2NrUE0tIEF1dFdpZERpcy0gQldJbnQtIEF1dEJXSW50LQ0KCQlMbmtTdGE6CVNwZWVkIHVu
a25vd24sIFdpZHRoIHgxNiwgVHJFcnItIFRyYWluLSBTbG90Q2xrKyBETEFjdGl2ZS0gQldN
Z210LSBBQldNZ210LQ0KCQlTbHRDYXA6CUF0dG5CdG4tIFB3ckN0cmwtIE1STC0gQXR0bklu
ZC0gUHdySW5kLSBIb3RQbHVnLSBTdXJwcmlzZS0NCgkJCVNsb3QgIzMyLCBQb3dlckxpbWl0
IDc1LjAwMFc7IEludGVybG9jay0gTm9Db21wbCsNCgkJU2x0Q3RsOglFbmFibGU6IEF0dG5C
dG4tIFB3ckZsdC0gTVJMLSBQcmVzRGV0LSBDbWRDcGx0LSBIUElycS0gTGlua0NoZy0NCgkJ
CUNvbnRyb2w6IEF0dG5JbmQgVW5rbm93biwgUHdySW5kIFVua25vd24sIFBvd2VyLSBJbnRl
cmxvY2stDQoJCVNsdFN0YToJU3RhdHVzOiBBdHRuQnRuLSBQb3dlckZsdC0gTVJMLSBDbWRD
cGx0LSBQcmVzRGV0LSBJbnRlcmxvY2stDQoJCQlDaGFuZ2VkOiBNUkwtIFByZXNEZXQtIExp
bmtTdGF0ZS0NCgkJUm9vdEN0bDogRXJyQ29ycmVjdGFibGUtIEVyck5vbi1GYXRhbC0gRXJy
RmF0YWwtIFBNRUludEVuYS0gQ1JTVmlzaWJsZS0NCgkJUm9vdENhcDogQ1JTVmlzaWJsZS0N
CgkJUm9vdFN0YTogUE1FIFJlcUlEIDAwMDAsIFBNRVN0YXR1cy0gUE1FUGVuZGluZy0NCgkJ
RGV2Q2FwMjogQ29tcGxldGlvbiBUaW1lb3V0OiBSYW5nZSBBQkNELCBUaW1lb3V0RGlzKyBB
UklGd2QtDQoJCURldkN0bDI6IENvbXBsZXRpb24gVGltZW91dDogNjVtcyB0byAyMTBtcywg
VGltZW91dERpcy0gQVJJRndkLQ0KCQlMbmtDdGwyOiBUYXJnZXQgTGluayBTcGVlZDogMi41
R1QvcywgRW50ZXJDb21wbGlhbmNlLSBTcGVlZERpcy0sIFNlbGVjdGFibGUgRGUtZW1waGFz
aXM6IC0zLjVkQg0KCQkJIFRyYW5zbWl0IE1hcmdpbjogTm9ybWFsIE9wZXJhdGluZyBSYW5n
ZSwgRW50ZXJNb2RpZmllZENvbXBsaWFuY2UtIENvbXBsaWFuY2VTT1MtDQoJCQkgQ29tcGxp
YW5jZSBEZS1lbXBoYXNpczogLTZkQg0KCQlMbmtTdGEyOiBDdXJyZW50IERlLWVtcGhhc2lz
IExldmVsOiAtNmRCDQoJQ2FwYWJpbGl0aWVzOiBbYTBdIE1TSTogRW5hYmxlKyBDb3VudD0x
LzEgTWFza2FibGUtIDY0Yml0Kw0KCQlBZGRyZXNzOiAwMDAwMDAwMGZlZTNmMDBjICBEYXRh
OiA0MTg5DQoJQ2FwYWJpbGl0aWVzOiBbYjBdIFN1YnN5c3RlbTogQVRJIFRlY2hub2xvZ2ll
cyBJbmMgRGV2aWNlIFsxMDAyOjAwMDBdDQoJQ2FwYWJpbGl0aWVzOiBbYjhdIEh5cGVyVHJh
bnNwb3J0OiBNU0kgTWFwcGluZyBFbmFibGUrIEZpeGVkKw0KCUNhcGFiaWxpdGllczogWzEw
MCB2MV0gVmVuZG9yIFNwZWNpZmljIEluZm9ybWF0aW9uOiBJRD0wMDAxIFJldj0xIExlbj0w
MTAgPD8+DQoJS2VybmVsIGRyaXZlciBpbiB1c2U6IHBjaWVwb3J0DQoNCjAwOjE2LjAgVVNC
IGNvbnRyb2xsZXIgWzBjMDNdOiBBVEkgVGVjaG5vbG9naWVzIEluYyBTQjd4MC9TQjh4MC9T
Qjl4MCBVU0IgT0hDSTAgQ29udHJvbGxlciBbMTAwMjo0Mzk3XSAocHJvZy1pZiAxMCBbT0hD
SV0pDQoJU3Vic3lzdGVtOiBNaWNyby1TdGFyIEludGVybmF0aW9uYWwgQ28uLCBMdGQuIERl
dmljZSBbMTQ2Mjo3NjQwXQ0KCUNvbnRyb2w6IEkvTysgTWVtKyBCdXNNYXN0ZXIrIFNwZWND
eWNsZS0gTWVtV0lOVisgVkdBU25vb3AtIFBhckVyci0gU3RlcHBpbmctIFNFUlIrIEZhc3RC
MkItIERpc0lOVHgtDQoJU3RhdHVzOiBDYXAtIDY2TUh6KyBVREYtIEZhc3RCMkIrIFBhckVy
ci0gREVWU0VMPW1lZGl1bSA+VEFib3J0LSA8VEFib3J0LSA8TUFib3J0LSA+U0VSUi0gPFBF
UlItIElOVHgtDQoJTGF0ZW5jeTogNjQsIENhY2hlIExpbmUgU2l6ZTogNjQgYnl0ZXMNCglJ
bnRlcnJ1cHQ6IHBpbiBBIHJvdXRlZCB0byBJUlEgMTgNCglSZWdpb24gMDogTWVtb3J5IGF0
IGY5NmZlMDAwICgzMi1iaXQsIG5vbi1wcmVmZXRjaGFibGUpIFtzaXplPTRLXQ0KCUtlcm5l
bCBkcml2ZXIgaW4gdXNlOiBvaGNpX2hjZA0KDQowMDoxNi4yIFVTQiBjb250cm9sbGVyIFsw
YzAzXTogQVRJIFRlY2hub2xvZ2llcyBJbmMgU0I3eDAvU0I4eDAvU0I5eDAgVVNCIEVIQ0kg
Q29udHJvbGxlciBbMTAwMjo0Mzk2XSAocHJvZy1pZiAyMCBbRUhDSV0pDQoJU3Vic3lzdGVt
OiBNaWNyby1TdGFyIEludGVybmF0aW9uYWwgQ28uLCBMdGQuIERldmljZSBbMTQ2Mjo3NjQw
XQ0KCUNvbnRyb2w6IEkvTy0gTWVtKyBCdXNNYXN0ZXIrIFNwZWNDeWNsZS0gTWVtV0lOVisg
VkdBU25vb3AtIFBhckVyci0gU3RlcHBpbmctIFNFUlIrIEZhc3RCMkItIERpc0lOVHgtDQoJ
U3RhdHVzOiBDYXArIDY2TUh6KyBVREYtIEZhc3RCMkIrIFBhckVyci0gREVWU0VMPW1lZGl1
bSA+VEFib3J0LSA8VEFib3J0LSA8TUFib3J0LSA+U0VSUi0gPFBFUlItIElOVHgtDQoJTGF0
ZW5jeTogNjQsIENhY2hlIExpbmUgU2l6ZTogNjQgYnl0ZXMNCglJbnRlcnJ1cHQ6IHBpbiBC
IHJvdXRlZCB0byBJUlEgMTcNCglSZWdpb24gMDogTWVtb3J5IGF0IGY5NmZmYzAwICgzMi1i
aXQsIG5vbi1wcmVmZXRjaGFibGUpIFtzaXplPTI1Nl0NCglDYXBhYmlsaXRpZXM6IFtjMF0g
UG93ZXIgTWFuYWdlbWVudCB2ZXJzaW9uIDINCgkJRmxhZ3M6IFBNRUNsay0gRFNJLSBEMSsg
RDIrIEF1eEN1cnJlbnQ9MG1BIFBNRShEMCssRDErLEQyKyxEM2hvdCssRDNjb2xkLSkNCgkJ
U3RhdHVzOiBEMCBOb1NvZnRSc3QtIFBNRS1FbmFibGUtIERTZWw9MCBEU2NhbGU9MCBQTUUt
DQoJCUJyaWRnZTogUE0tIEIzKw0KCUNhcGFiaWxpdGllczogW2U0XSBEZWJ1ZyBwb3J0OiBC
QVI9MSBvZmZzZXQ9MDBlMA0KCUtlcm5lbCBkcml2ZXIgaW4gdXNlOiBlaGNpX2hjZA0KDQow
MDoxOC4wIEhvc3QgYnJpZGdlIFswNjAwXTogQWR2YW5jZWQgTWljcm8gRGV2aWNlcyBbQU1E
XSBGYW1pbHkgMTBoIFByb2Nlc3NvciBIeXBlclRyYW5zcG9ydCBDb25maWd1cmF0aW9uIFsx
MDIyOjEyMDBdDQoJQ29udHJvbDogSS9PLSBNZW0tIEJ1c01hc3Rlci0gU3BlY0N5Y2xlLSBN
ZW1XSU5WLSBWR0FTbm9vcC0gUGFyRXJyLSBTdGVwcGluZy0gU0VSUi0gRmFzdEIyQi0gRGlz
SU5UeC0NCglTdGF0dXM6IENhcCsgNjZNSHotIFVERi0gRmFzdEIyQi0gUGFyRXJyLSBERVZT
RUw9ZmFzdCA+VEFib3J0LSA8VEFib3J0LSA8TUFib3J0LSA+U0VSUi0gPFBFUlItIElOVHgt
DQoJQ2FwYWJpbGl0aWVzOiBbODBdIEh5cGVyVHJhbnNwb3J0OiBIb3N0IG9yIFNlY29uZGFy
eSBJbnRlcmZhY2UNCgkJQ29tbWFuZDogV2FybVJzdCsgRGJsRW5kLSBEZXZOdW09MCBDaGFp
blNpZGUtIEhvc3RIaWRlKyBTbGF2ZS0gPEVPQ0Vyci0gRFVMLQ0KCQlMaW5rIENvbnRyb2w6
IENGbEUtIENTVC0gQ0ZFLSA8TGtGYWlsLSBJbml0KyBFT0MtIFRYTy0gPENSQ0Vycj0wIElz
b2NFbi0gTFNFbisgRXh0Q1RMLSA2NGItDQoJCUxpbmsgQ29uZmlnOiBNTFdJPTE2Yml0IER3
RmNJbi0gTUxXTz0xNmJpdCBEd0ZjT3V0LSBMV0k9MTZiaXQgRHdGY0luRW4tIExXTz0xNmJp
dCBEd0ZjT3V0RW4tDQoJCVJldmlzaW9uIElEOiAzLjAwDQoJCUxpbmsgRnJlcXVlbmN5OiBb
Yl0NCgkJTGluayBFcnJvcjogPFByb3QtIDxPdmZsLSA8RU9DLSBDVExUbS0NCgkJTGluayBG
cmVxdWVuY3kgQ2FwYWJpbGl0eTogMjAwTUh6KyAzMDBNSHotIDQwME1IeisgNTAwTUh6LSA2
MDBNSHorIDgwME1IeisgMS4wR0h6KyAxLjJHSHorIDEuNEdIei0gMS42R0h6LSBWZW5kLQ0K
CQlGZWF0dXJlIENhcGFiaWxpdHk6IElzb2NGQysgTERUU1RPUCsgQ1JDVE0tIEVDVExULSA2
NGJBKyBVSURSRC0gRXh0UlMtIFVDbmZFLQ0KDQowMDoxOC4xIEhvc3QgYnJpZGdlIFswNjAw
XTogQWR2YW5jZWQgTWljcm8gRGV2aWNlcyBbQU1EXSBGYW1pbHkgMTBoIFByb2Nlc3NvciBB
ZGRyZXNzIE1hcCBbMTAyMjoxMjAxXQ0KCUNvbnRyb2w6IEkvTy0gTWVtLSBCdXNNYXN0ZXIt
IFNwZWNDeWNsZS0gTWVtV0lOVi0gVkdBU25vb3AtIFBhckVyci0gU3RlcHBpbmctIFNFUlIt
IEZhc3RCMkItIERpc0lOVHgtDQoJU3RhdHVzOiBDYXAtIDY2TUh6LSBVREYtIEZhc3RCMkIt
IFBhckVyci0gREVWU0VMPWZhc3QgPlRBYm9ydC0gPFRBYm9ydC0gPE1BYm9ydC0gPlNFUlIt
IDxQRVJSLSBJTlR4LQ0KDQowMDoxOC4yIEhvc3QgYnJpZGdlIFswNjAwXTogQWR2YW5jZWQg
TWljcm8gRGV2aWNlcyBbQU1EXSBGYW1pbHkgMTBoIFByb2Nlc3NvciBEUkFNIENvbnRyb2xs
ZXIgWzEwMjI6MTIwMl0NCglDb250cm9sOiBJL08tIE1lbS0gQnVzTWFzdGVyLSBTcGVjQ3lj
bGUtIE1lbVdJTlYtIFZHQVNub29wLSBQYXJFcnItIFN0ZXBwaW5nLSBTRVJSLSBGYXN0QjJC
LSBEaXNJTlR4LQ0KCVN0YXR1czogQ2FwLSA2Nk1Iei0gVURGLSBGYXN0QjJCLSBQYXJFcnIt
IERFVlNFTD1mYXN0ID5UQWJvcnQtIDxUQWJvcnQtIDxNQWJvcnQtID5TRVJSLSA8UEVSUi0g
SU5UeC0NCg0KMDA6MTguMyBIb3N0IGJyaWRnZSBbMDYwMF06IEFkdmFuY2VkIE1pY3JvIERl
dmljZXMgW0FNRF0gRmFtaWx5IDEwaCBQcm9jZXNzb3IgTWlzY2VsbGFuZW91cyBDb250cm9s
IFsxMDIyOjEyMDNdDQoJQ29udHJvbDogSS9PLSBNZW0tIEJ1c01hc3Rlci0gU3BlY0N5Y2xl
LSBNZW1XSU5WLSBWR0FTbm9vcC0gUGFyRXJyLSBTdGVwcGluZy0gU0VSUi0gRmFzdEIyQi0g
RGlzSU5UeC0NCglTdGF0dXM6IENhcCsgNjZNSHotIFVERi0gRmFzdEIyQi0gUGFyRXJyLSBE
RVZTRUw9ZmFzdCA+VEFib3J0LSA8VEFib3J0LSA8TUFib3J0LSA+U0VSUi0gPFBFUlItIElO
VHgtDQoJQ2FwYWJpbGl0aWVzOiBbZjBdIFNlY3VyZSBkZXZpY2UgPD8+DQoJS2VybmVsIGRy
aXZlciBpbiB1c2U6IGsxMHRlbXANCg0KMDA6MTguNCBIb3N0IGJyaWRnZSBbMDYwMF06IEFk
dmFuY2VkIE1pY3JvIERldmljZXMgW0FNRF0gRmFtaWx5IDEwaCBQcm9jZXNzb3IgTGluayBD
b250cm9sIFsxMDIyOjEyMDRdDQoJQ29udHJvbDogSS9PLSBNZW0tIEJ1c01hc3Rlci0gU3Bl
Y0N5Y2xlLSBNZW1XSU5WLSBWR0FTbm9vcC0gUGFyRXJyLSBTdGVwcGluZy0gU0VSUi0gRmFz
dEIyQi0gRGlzSU5UeC0NCglTdGF0dXM6IENhcC0gNjZNSHotIFVERi0gRmFzdEIyQi0gUGFy
RXJyLSBERVZTRUw9ZmFzdCA+VEFib3J0LSA8VEFib3J0LSA8TUFib3J0LSA+U0VSUi0gPFBF
UlItIElOVHgtDQoNCjAzOjA2LjAgTXVsdGltZWRpYSBhdWRpbyBjb250cm9sbGVyIFswNDAx
XTogQy1NZWRpYSBFbGVjdHJvbmljcyBJbmMgQ004NzM4IFsxM2Y2OjAxMTFdIChyZXYgMTAp
DQoJU3Vic3lzdGVtOiBDLU1lZGlhIEVsZWN0cm9uaWNzIEluYyBDTUk4NzM4L0MzRFggUENJ
IEF1ZGlvIERldmljZSBbMTNmNjowMTExXQ0KCUNvbnRyb2w6IEkvTysgTWVtLSBCdXNNYXN0
ZXIrIFNwZWNDeWNsZS0gTWVtV0lOVi0gVkdBU25vb3AtIFBhckVyci0gU3RlcHBpbmctIFNF
UlItIEZhc3RCMkItIERpc0lOVHgtDQoJU3RhdHVzOiBDYXArIDY2TUh6LSBVREYtIEZhc3RC
MkItIFBhckVyci0gREVWU0VMPW1lZGl1bSA+VEFib3J0LSA8VEFib3J0LSA8TUFib3J0LSA+
U0VSUi0gPFBFUlItIElOVHgtDQoJTGF0ZW5jeTogNjQgKDUwMG5zIG1pbiwgNjAwMG5zIG1h
eCkNCglJbnRlcnJ1cHQ6IHBpbiBBIHJvdXRlZCB0byBJUlEgMjINCglSZWdpb24gMDogSS9P
IHBvcnRzIGF0IGE4MDAgW3NpemU9MjU2XQ0KCUNhcGFiaWxpdGllczogW2MwXSBQb3dlciBN
YW5hZ2VtZW50IHZlcnNpb24gMg0KCQlGbGFnczogUE1FQ2xrLSBEU0ktIEQxKyBEMisgQXV4
Q3VycmVudD0wbUEgUE1FKEQwLSxEMS0sRDItLEQzaG90LSxEM2NvbGQtKQ0KCQlTdGF0dXM6
IEQwIE5vU29mdFJzdC0gUE1FLUVuYWJsZS0gRFNlbD0wIERTY2FsZT0wIFBNRS0NCglLZXJu
ZWwgZHJpdmVyIGluIHVzZTogcGNpYmFjaw0KDQowNDowMC4wIFVTQiBjb250cm9sbGVyIFsw
YzAzXTogTmV0TW9zIFRlY2hub2xvZ3kgTUNTOTk5MCBQQ0llIHRvIDTigJBQb3J0IFVTQiAy
LjAgSG9zdCBDb250cm9sbGVyIFs5NzEwOjk5OTBdIChwcm9nLWlmIDEwIFtPSENJXSkNCglT
dWJzeXN0ZW06IERldmljZSBbYTAwMDo0MDAwXQ0KCUNvbnRyb2w6IEkvTy0gTWVtLSBCdXNN
YXN0ZXItIFNwZWNDeWNsZS0gTWVtV0lOVi0gVkdBU25vb3AtIFBhckVyci0gU3RlcHBpbmct
IFNFUlItIEZhc3RCMkItIERpc0lOVHgtDQoJU3RhdHVzOiBDYXArIDY2TUh6LSBVREYtIEZh
c3RCMkItIFBhckVyci0gREVWU0VMPWZhc3QgPlRBYm9ydC0gPFRBYm9ydC0gPE1BYm9ydC0g
PlNFUlItIDxQRVJSLSBJTlR4LQ0KCUludGVycnVwdDogcGluIEEgcm91dGVkIHRvIElSUSA0
MA0KCVJlZ2lvbiAwOiBNZW1vcnkgYXQgZjk4ZjgwMDAgKDMyLWJpdCwgbm9uLXByZWZldGNo
YWJsZSkgW2Rpc2FibGVkXSBbc2l6ZT00S10NCglDYXBhYmlsaXRpZXM6IFs1MF0gTVNJOiBF
bmFibGUtIENvdW50PTEvMSBNYXNrYWJsZS0gNjRiaXQrDQoJCUFkZHJlc3M6IDAwMDAwMDAw
MDAwMDAwMDAgIERhdGE6IDAwMDANCglDYXBhYmlsaXRpZXM6IFs3OF0gUG93ZXIgTWFuYWdl
bWVudCB2ZXJzaW9uIDMNCgkJRmxhZ3M6IFBNRUNsay0gRFNJLSBEMSsgRDIrIEF1eEN1cnJl
bnQ9Mzc1bUEgUE1FKEQwKyxEMSssRDIrLEQzaG90KyxEM2NvbGQtKQ0KCQlTdGF0dXM6IEQw
IE5vU29mdFJzdCsgUE1FLUVuYWJsZS0gRFNlbD0wIERTY2FsZT0wIFBNRS0NCglDYXBhYmls
aXRpZXM6IFs4MF0gRXhwcmVzcyAodjEpIEVuZHBvaW50LCBNU0kgMDANCgkJRGV2Q2FwOglN
YXhQYXlsb2FkIDI1NiBieXRlcywgUGhhbnRGdW5jIDAsIExhdGVuY3kgTDBzIHVubGltaXRl
ZCwgTDEgdW5saW1pdGVkDQoJCQlFeHRUYWctIEF0dG5CdG4tIEF0dG5JbmQtIFB3ckluZC0g
UkJFKyBGTFJlc2V0LQ0KCQlEZXZDdGw6CVJlcG9ydCBlcnJvcnM6IENvcnJlY3RhYmxlLSBO
b24tRmF0YWwtIEZhdGFsLSBVbnN1cHBvcnRlZC0NCgkJCVJseGRPcmQtIEV4dFRhZy0gUGhh
bnRGdW5jLSBBdXhQd3ItIE5vU25vb3ArDQoJCQlNYXhQYXlsb2FkIDEyOCBieXRlcywgTWF4
UmVhZFJlcSA1MTIgYnl0ZXMNCgkJRGV2U3RhOglDb3JyRXJyLSBVbmNvcnJFcnItIEZhdGFs
RXJyLSBVbnN1cHBSZXEtIEF1eFB3ci0gVHJhbnNQZW5kLQ0KCQlMbmtDYXA6CVBvcnQgIzEs
IFNwZWVkIDIuNUdUL3MsIFdpZHRoIHgxLCBBU1BNIHVua25vd24sIExhdGVuY3kgTDAgPDY0
bnMsIEwxIHVubGltaXRlZA0KCQkJQ2xvY2tQTSsgU3VycHJpc2UtIExMQWN0UmVwLSBCd05v
dC0NCgkJTG5rQ3RsOglBU1BNIERpc2FibGVkOyBSQ0IgNjQgYnl0ZXMgRGlzYWJsZWQtIFJl
dHJhaW4tIENvbW1DbGstDQoJCQlFeHRTeW5jaC0gQ2xvY2tQTS0gQXV0V2lkRGlzLSBCV0lu
dC0gQXV0QldJbnQtDQoJCUxua1N0YToJU3BlZWQgMi41R1QvcywgV2lkdGggeDEsIFRyRXJy
LSBUcmFpbi0gU2xvdENsay0gRExBY3RpdmUtIEJXTWdtdC0gQUJXTWdtdC0NCglDYXBhYmls
aXRpZXM6IFsxMDAgdjFdIFZpcnR1YWwgQ2hhbm5lbA0KCQlDYXBzOglMUEVWQz0wIFJlZkNs
az0xMDBucyBQQVRFbnRyeUJpdHM9MQ0KCQlBcmI6CUZpeGVkLSBXUlIzMi0gV1JSNjQtIFdS
UjEyOC0NCgkJQ3RybDoJQXJiU2VsZWN0PUZpeGVkDQoJCVN0YXR1czoJSW5Qcm9ncmVzcy0N
CgkJVkMwOglDYXBzOglQQVRPZmZzZXQ9MDAgTWF4VGltZVNsb3RzPTEgUmVqU25vb3BUcmFu
cy0NCgkJCUFyYjoJRml4ZWQtIFdSUjMyLSBXUlI2NC0gV1JSMTI4LSBUV1JSMTI4LSBXUlIy
NTYtDQoJCQlDdHJsOglFbmFibGUrIElEPTAgQXJiU2VsZWN0PUZpeGVkIFRDL1ZDPWZmDQoJ
CQlTdGF0dXM6CU5lZ29QZW5kaW5nLSBJblByb2dyZXNzLQ0KCUtlcm5lbCBkcml2ZXIgaW4g
dXNlOiBwY2liYWNrDQoNCjA0OjAwLjEgVVNCIGNvbnRyb2xsZXIgWzBjMDNdOiBOZXRNb3Mg
VGVjaG5vbG9neSBNQ1M5OTkwIFBDSWUgdG8gNOKAkFBvcnQgVVNCIDIuMCBIb3N0IENvbnRy
b2xsZXIgWzk3MTA6OTk5MF0gKHByb2ctaWYgMjAgW0VIQ0ldKQ0KCVN1YnN5c3RlbTogRGV2
aWNlIFthMDAwOjQwMDBdDQoJQ29udHJvbDogSS9PLSBNZW0tIEJ1c01hc3Rlci0gU3BlY0N5
Y2xlLSBNZW1XSU5WLSBWR0FTbm9vcC0gUGFyRXJyLSBTdGVwcGluZy0gU0VSUi0gRmFzdEIy
Qi0gRGlzSU5UeC0NCglTdGF0dXM6IENhcCsgNjZNSHotIFVERi0gRmFzdEIyQi0gUGFyRXJy
LSBERVZTRUw9ZmFzdCA+VEFib3J0LSA8VEFib3J0LSA8TUFib3J0LSA+U0VSUi0gPFBFUlIt
IElOVHgtDQoJSW50ZXJydXB0OiBwaW4gQSByb3V0ZWQgdG8gSVJRIDQwDQoJUmVnaW9uIDA6
IE1lbW9yeSBhdCBmOThmOTAwMCAoMzItYml0LCBub24tcHJlZmV0Y2hhYmxlKSBbZGlzYWJs
ZWRdIFtzaXplPTRLXQ0KCUNhcGFiaWxpdGllczogWzUwXSBNU0k6IEVuYWJsZS0gQ291bnQ9
MS8xIE1hc2thYmxlLSA2NGJpdCsNCgkJQWRkcmVzczogMDAwMDAwMDAwMDAwMDAwMCAgRGF0
YTogMDAwMA0KCUNhcGFiaWxpdGllczogWzc4XSBQb3dlciBNYW5hZ2VtZW50IHZlcnNpb24g
Mw0KCQlGbGFnczogUE1FQ2xrLSBEU0ktIEQxKyBEMisgQXV4Q3VycmVudD0zNzVtQSBQTUUo
RDArLEQxKyxEMissRDNob3QrLEQzY29sZC0pDQoJCVN0YXR1czogRDAgTm9Tb2Z0UnN0KyBQ
TUUtRW5hYmxlLSBEU2VsPTAgRFNjYWxlPTAgUE1FLQ0KCUNhcGFiaWxpdGllczogWzgwXSBF
eHByZXNzICh2MSkgRW5kcG9pbnQsIE1TSSAwMA0KCQlEZXZDYXA6CU1heFBheWxvYWQgMjU2
IGJ5dGVzLCBQaGFudEZ1bmMgMCwgTGF0ZW5jeSBMMHMgdW5saW1pdGVkLCBMMSB1bmxpbWl0
ZWQNCgkJCUV4dFRhZy0gQXR0bkJ0bi0gQXR0bkluZC0gUHdySW5kLSBSQkUrIEZMUmVzZXQt
DQoJCURldkN0bDoJUmVwb3J0IGVycm9yczogQ29ycmVjdGFibGUtIE5vbi1GYXRhbC0gRmF0
YWwtIFVuc3VwcG9ydGVkLQ0KCQkJUmx4ZE9yZC0gRXh0VGFnLSBQaGFudEZ1bmMtIEF1eFB3
ci0gTm9Tbm9vcCsNCgkJCU1heFBheWxvYWQgMTI4IGJ5dGVzLCBNYXhSZWFkUmVxIDUxMiBi
eXRlcw0KCQlEZXZTdGE6CUNvcnJFcnItIFVuY29yckVyci0gRmF0YWxFcnItIFVuc3VwcFJl
cS0gQXV4UHdyLSBUcmFuc1BlbmQtDQoJCUxua0NhcDoJUG9ydCAjMSwgU3BlZWQgMi41R1Qv
cywgV2lkdGggeDEsIEFTUE0gdW5rbm93biwgTGF0ZW5jeSBMMCA8NjRucywgTDEgdW5saW1p
dGVkDQoJCQlDbG9ja1BNKyBTdXJwcmlzZS0gTExBY3RSZXAtIEJ3Tm90LQ0KCQlMbmtDdGw6
CUFTUE0gRGlzYWJsZWQ7IFJDQiA2NCBieXRlcyBEaXNhYmxlZC0gUmV0cmFpbi0gQ29tbUNs
ay0NCgkJCUV4dFN5bmNoLSBDbG9ja1BNLSBBdXRXaWREaXMtIEJXSW50LSBBdXRCV0ludC0N
CgkJTG5rU3RhOglTcGVlZCAyLjVHVC9zLCBXaWR0aCB4MSwgVHJFcnItIFRyYWluLSBTbG90
Q2xrLSBETEFjdGl2ZS0gQldNZ210LSBBQldNZ210LQ0KCUtlcm5lbCBkcml2ZXIgaW4gdXNl
OiBwY2liYWNrDQoNCjA0OjAwLjIgVVNCIGNvbnRyb2xsZXIgWzBjMDNdOiBOZXRNb3MgVGVj
aG5vbG9neSBNQ1M5OTkwIFBDSWUgdG8gNOKAkFBvcnQgVVNCIDIuMCBIb3N0IENvbnRyb2xs
ZXIgWzk3MTA6OTk5MF0gKHByb2ctaWYgMTAgW09IQ0ldKQ0KCVN1YnN5c3RlbTogRGV2aWNl
IFthMDAwOjQwMDBdDQoJQ29udHJvbDogSS9PLSBNZW0tIEJ1c01hc3Rlci0gU3BlY0N5Y2xl
LSBNZW1XSU5WLSBWR0FTbm9vcC0gUGFyRXJyLSBTdGVwcGluZy0gU0VSUi0gRmFzdEIyQi0g
RGlzSU5UeC0NCglTdGF0dXM6IENhcCsgNjZNSHotIFVERi0gRmFzdEIyQi0gUGFyRXJyLSBE
RVZTRUw9ZmFzdCA+VEFib3J0LSA8VEFib3J0LSA8TUFib3J0LSA+U0VSUi0gPFBFUlItIElO
VHgtDQoJSW50ZXJydXB0OiBwaW4gQiByb3V0ZWQgdG8gSVJRIDQxDQoJUmVnaW9uIDA6IE1l
bW9yeSBhdCBmOThmYTAwMCAoMzItYml0LCBub24tcHJlZmV0Y2hhYmxlKSBbZGlzYWJsZWRd
IFtzaXplPTRLXQ0KCUNhcGFiaWxpdGllczogWzUwXSBNU0k6IEVuYWJsZS0gQ291bnQ9MS8x
IE1hc2thYmxlLSA2NGJpdCsNCgkJQWRkcmVzczogMDAwMDAwMDAwMDAwMDAwMCAgRGF0YTog
MDAwMA0KCUNhcGFiaWxpdGllczogWzc4XSBQb3dlciBNYW5hZ2VtZW50IHZlcnNpb24gMw0K
CQlGbGFnczogUE1FQ2xrLSBEU0ktIEQxKyBEMisgQXV4Q3VycmVudD0zNzVtQSBQTUUoRDAr
LEQxKyxEMissRDNob3QrLEQzY29sZC0pDQoJCVN0YXR1czogRDAgTm9Tb2Z0UnN0KyBQTUUt
RW5hYmxlLSBEU2VsPTAgRFNjYWxlPTAgUE1FLQ0KCUNhcGFiaWxpdGllczogWzgwXSBFeHBy
ZXNzICh2MSkgRW5kcG9pbnQsIE1TSSAwMA0KCQlEZXZDYXA6CU1heFBheWxvYWQgMjU2IGJ5
dGVzLCBQaGFudEZ1bmMgMCwgTGF0ZW5jeSBMMHMgdW5saW1pdGVkLCBMMSB1bmxpbWl0ZWQN
CgkJCUV4dFRhZy0gQXR0bkJ0bi0gQXR0bkluZC0gUHdySW5kLSBSQkUrIEZMUmVzZXQtDQoJ
CURldkN0bDoJUmVwb3J0IGVycm9yczogQ29ycmVjdGFibGUtIE5vbi1GYXRhbC0gRmF0YWwt
IFVuc3VwcG9ydGVkLQ0KCQkJUmx4ZE9yZC0gRXh0VGFnLSBQaGFudEZ1bmMtIEF1eFB3ci0g
Tm9Tbm9vcCsNCgkJCU1heFBheWxvYWQgMTI4IGJ5dGVzLCBNYXhSZWFkUmVxIDUxMiBieXRl
cw0KCQlEZXZTdGE6CUNvcnJFcnItIFVuY29yckVyci0gRmF0YWxFcnItIFVuc3VwcFJlcS0g
QXV4UHdyLSBUcmFuc1BlbmQtDQoJCUxua0NhcDoJUG9ydCAjMSwgU3BlZWQgMi41R1Qvcywg
V2lkdGggeDEsIEFTUE0gdW5rbm93biwgTGF0ZW5jeSBMMCA8NjRucywgTDEgdW5saW1pdGVk
DQoJCQlDbG9ja1BNKyBTdXJwcmlzZS0gTExBY3RSZXAtIEJ3Tm90LQ0KCQlMbmtDdGw6CUFT
UE0gRGlzYWJsZWQ7IFJDQiA2NCBieXRlcyBEaXNhYmxlZC0gUmV0cmFpbi0gQ29tbUNsay0N
CgkJCUV4dFN5bmNoLSBDbG9ja1BNLSBBdXRXaWREaXMtIEJXSW50LSBBdXRCV0ludC0NCgkJ
TG5rU3RhOglTcGVlZCAyLjVHVC9zLCBXaWR0aCB4MSwgVHJFcnItIFRyYWluLSBTbG90Q2xr
LSBETEFjdGl2ZS0gQldNZ210LSBBQldNZ210LQ0KCUtlcm5lbCBkcml2ZXIgaW4gdXNlOiBw
Y2liYWNrDQoNCjA0OjAwLjMgVVNCIGNvbnRyb2xsZXIgWzBjMDNdOiBOZXRNb3MgVGVjaG5v
bG9neSBNQ1M5OTkwIFBDSWUgdG8gNOKAkFBvcnQgVVNCIDIuMCBIb3N0IENvbnRyb2xsZXIg
Wzk3MTA6OTk5MF0gKHByb2ctaWYgMjAgW0VIQ0ldKQ0KCVN1YnN5c3RlbTogRGV2aWNlIFth
MDAwOjQwMDBdDQoJQ29udHJvbDogSS9PLSBNZW0tIEJ1c01hc3Rlci0gU3BlY0N5Y2xlLSBN
ZW1XSU5WLSBWR0FTbm9vcC0gUGFyRXJyLSBTdGVwcGluZy0gU0VSUi0gRmFzdEIyQi0gRGlz
SU5UeC0NCglTdGF0dXM6IENhcCsgNjZNSHotIFVERi0gRmFzdEIyQi0gUGFyRXJyLSBERVZT
RUw9ZmFzdCA+VEFib3J0LSA8VEFib3J0LSA8TUFib3J0LSA+U0VSUi0gPFBFUlItIElOVHgt
DQoJSW50ZXJydXB0OiBwaW4gQiByb3V0ZWQgdG8gSVJRIDQxDQoJUmVnaW9uIDA6IE1lbW9y
eSBhdCBmOThmYjAwMCAoMzItYml0LCBub24tcHJlZmV0Y2hhYmxlKSBbZGlzYWJsZWRdIFtz
aXplPTRLXQ0KCUNhcGFiaWxpdGllczogWzUwXSBNU0k6IEVuYWJsZS0gQ291bnQ9MS8xIE1h
c2thYmxlLSA2NGJpdCsNCgkJQWRkcmVzczogMDAwMDAwMDAwMDAwMDAwMCAgRGF0YTogMDAw
MA0KCUNhcGFiaWxpdGllczogWzc4XSBQb3dlciBNYW5hZ2VtZW50IHZlcnNpb24gMw0KCQlG
bGFnczogUE1FQ2xrLSBEU0ktIEQxKyBEMisgQXV4Q3VycmVudD0zNzVtQSBQTUUoRDArLEQx
KyxEMissRDNob3QrLEQzY29sZC0pDQoJCVN0YXR1czogRDAgTm9Tb2Z0UnN0KyBQTUUtRW5h
YmxlLSBEU2VsPTAgRFNjYWxlPTAgUE1FLQ0KCUNhcGFiaWxpdGllczogWzgwXSBFeHByZXNz
ICh2MSkgRW5kcG9pbnQsIE1TSSAwMA0KCQlEZXZDYXA6CU1heFBheWxvYWQgMjU2IGJ5dGVz
LCBQaGFudEZ1bmMgMCwgTGF0ZW5jeSBMMHMgdW5saW1pdGVkLCBMMSB1bmxpbWl0ZWQNCgkJ
CUV4dFRhZy0gQXR0bkJ0bi0gQXR0bkluZC0gUHdySW5kLSBSQkUrIEZMUmVzZXQtDQoJCURl
dkN0bDoJUmVwb3J0IGVycm9yczogQ29ycmVjdGFibGUtIE5vbi1GYXRhbC0gRmF0YWwtIFVu
c3VwcG9ydGVkLQ0KCQkJUmx4ZE9yZC0gRXh0VGFnLSBQaGFudEZ1bmMtIEF1eFB3ci0gTm9T
bm9vcCsNCgkJCU1heFBheWxvYWQgMTI4IGJ5dGVzLCBNYXhSZWFkUmVxIDUxMiBieXRlcw0K
CQlEZXZTdGE6CUNvcnJFcnItIFVuY29yckVyci0gRmF0YWxFcnItIFVuc3VwcFJlcS0gQXV4
UHdyLSBUcmFuc1BlbmQtDQoJCUxua0NhcDoJUG9ydCAjMSwgU3BlZWQgMi41R1QvcywgV2lk
dGggeDEsIEFTUE0gdW5rbm93biwgTGF0ZW5jeSBMMCA8NjRucywgTDEgdW5saW1pdGVkDQoJ
CQlDbG9ja1BNKyBTdXJwcmlzZS0gTExBY3RSZXAtIEJ3Tm90LQ0KCQlMbmtDdGw6CUFTUE0g
RGlzYWJsZWQ7IFJDQiA2NCBieXRlcyBEaXNhYmxlZC0gUmV0cmFpbi0gQ29tbUNsay0NCgkJ
CUV4dFN5bmNoLSBDbG9ja1BNLSBBdXRXaWREaXMtIEJXSW50LSBBdXRCV0ludC0NCgkJTG5r
U3RhOglTcGVlZCAyLjVHVC9zLCBXaWR0aCB4MSwgVHJFcnItIFRyYWluLSBTbG90Q2xrLSBE
TEFjdGl2ZS0gQldNZ210LSBBQldNZ210LQ0KCUtlcm5lbCBkcml2ZXIgaW4gdXNlOiBwY2li
YWNrDQoNCjA0OjAwLjQgVVNCIGNvbnRyb2xsZXIgWzBjMDNdOiBOZXRNb3MgVGVjaG5vbG9n
eSBNQ1M5OTkwIFBDSWUgdG8gNOKAkFBvcnQgVVNCIDIuMCBIb3N0IENvbnRyb2xsZXIgWzk3
MTA6OTk5MF0gKHByb2ctaWYgMTAgW09IQ0ldKQ0KCVN1YnN5c3RlbTogRGV2aWNlIFthMDAw
OjQwMDBdDQoJQ29udHJvbDogSS9PLSBNZW0tIEJ1c01hc3Rlci0gU3BlY0N5Y2xlLSBNZW1X
SU5WLSBWR0FTbm9vcC0gUGFyRXJyLSBTdGVwcGluZy0gU0VSUi0gRmFzdEIyQi0gRGlzSU5U
eC0NCglTdGF0dXM6IENhcCsgNjZNSHotIFVERi0gRmFzdEIyQi0gUGFyRXJyLSBERVZTRUw9
ZmFzdCA+VEFib3J0LSA8VEFib3J0LSA8TUFib3J0LSA+U0VSUi0gPFBFUlItIElOVHgtDQoJ
SW50ZXJydXB0OiBwaW4gQyByb3V0ZWQgdG8gSVJRIDQyDQoJUmVnaW9uIDA6IE1lbW9yeSBh
dCBmOThmYzAwMCAoMzItYml0LCBub24tcHJlZmV0Y2hhYmxlKSBbZGlzYWJsZWRdIFtzaXpl
PTRLXQ0KCUNhcGFiaWxpdGllczogWzUwXSBNU0k6IEVuYWJsZS0gQ291bnQ9MS8xIE1hc2th
YmxlLSA2NGJpdCsNCgkJQWRkcmVzczogMDAwMDAwMDAwMDAwMDAwMCAgRGF0YTogMDAwMA0K
CUNhcGFiaWxpdGllczogWzc4XSBQb3dlciBNYW5hZ2VtZW50IHZlcnNpb24gMw0KCQlGbGFn
czogUE1FQ2xrLSBEU0ktIEQxKyBEMisgQXV4Q3VycmVudD0zNzVtQSBQTUUoRDArLEQxKyxE
MissRDNob3QrLEQzY29sZC0pDQoJCVN0YXR1czogRDAgTm9Tb2Z0UnN0KyBQTUUtRW5hYmxl
LSBEU2VsPTAgRFNjYWxlPTAgUE1FLQ0KCUNhcGFiaWxpdGllczogWzgwXSBFeHByZXNzICh2
MSkgRW5kcG9pbnQsIE1TSSAwMA0KCQlEZXZDYXA6CU1heFBheWxvYWQgMjU2IGJ5dGVzLCBQ
aGFudEZ1bmMgMCwgTGF0ZW5jeSBMMHMgdW5saW1pdGVkLCBMMSB1bmxpbWl0ZWQNCgkJCUV4
dFRhZy0gQXR0bkJ0bi0gQXR0bkluZC0gUHdySW5kLSBSQkUrIEZMUmVzZXQtDQoJCURldkN0
bDoJUmVwb3J0IGVycm9yczogQ29ycmVjdGFibGUtIE5vbi1GYXRhbC0gRmF0YWwtIFVuc3Vw
cG9ydGVkLQ0KCQkJUmx4ZE9yZC0gRXh0VGFnLSBQaGFudEZ1bmMtIEF1eFB3ci0gTm9Tbm9v
cCsNCgkJCU1heFBheWxvYWQgMTI4IGJ5dGVzLCBNYXhSZWFkUmVxIDUxMiBieXRlcw0KCQlE
ZXZTdGE6CUNvcnJFcnItIFVuY29yckVyci0gRmF0YWxFcnItIFVuc3VwcFJlcS0gQXV4UHdy
LSBUcmFuc1BlbmQtDQoJCUxua0NhcDoJUG9ydCAjMSwgU3BlZWQgMi41R1QvcywgV2lkdGgg
eDEsIEFTUE0gdW5rbm93biwgTGF0ZW5jeSBMMCA8NjRucywgTDEgdW5saW1pdGVkDQoJCQlD
bG9ja1BNKyBTdXJwcmlzZS0gTExBY3RSZXAtIEJ3Tm90LQ0KCQlMbmtDdGw6CUFTUE0gRGlz
YWJsZWQ7IFJDQiA2NCBieXRlcyBEaXNhYmxlZC0gUmV0cmFpbi0gQ29tbUNsay0NCgkJCUV4
dFN5bmNoLSBDbG9ja1BNLSBBdXRXaWREaXMtIEJXSW50LSBBdXRCV0ludC0NCgkJTG5rU3Rh
OglTcGVlZCAyLjVHVC9zLCBXaWR0aCB4MSwgVHJFcnItIFRyYWluLSBTbG90Q2xrLSBETEFj
dGl2ZS0gQldNZ210LSBBQldNZ210LQ0KCUtlcm5lbCBkcml2ZXIgaW4gdXNlOiBwY2liYWNr
DQoNCjA0OjAwLjUgVVNCIGNvbnRyb2xsZXIgWzBjMDNdOiBOZXRNb3MgVGVjaG5vbG9neSBN
Q1M5OTkwIFBDSWUgdG8gNOKAkFBvcnQgVVNCIDIuMCBIb3N0IENvbnRyb2xsZXIgWzk3MTA6
OTk5MF0gKHByb2ctaWYgMjAgW0VIQ0ldKQ0KCVN1YnN5c3RlbTogRGV2aWNlIFthMDAwOjQw
MDBdDQoJQ29udHJvbDogSS9PLSBNZW0tIEJ1c01hc3Rlci0gU3BlY0N5Y2xlLSBNZW1XSU5W
LSBWR0FTbm9vcC0gUGFyRXJyLSBTdGVwcGluZy0gU0VSUi0gRmFzdEIyQi0gRGlzSU5UeC0N
CglTdGF0dXM6IENhcCsgNjZNSHotIFVERi0gRmFzdEIyQi0gUGFyRXJyLSBERVZTRUw9ZmFz
dCA+VEFib3J0LSA8VEFib3J0LSA8TUFib3J0LSA+U0VSUi0gPFBFUlItIElOVHgtDQoJSW50
ZXJydXB0OiBwaW4gQyByb3V0ZWQgdG8gSVJRIDQyDQoJUmVnaW9uIDA6IE1lbW9yeSBhdCBm
OThmZDAwMCAoMzItYml0LCBub24tcHJlZmV0Y2hhYmxlKSBbZGlzYWJsZWRdIFtzaXplPTRL
XQ0KCUNhcGFiaWxpdGllczogWzUwXSBNU0k6IEVuYWJsZS0gQ291bnQ9MS8xIE1hc2thYmxl
LSA2NGJpdCsNCgkJQWRkcmVzczogMDAwMDAwMDAwMDAwMDAwMCAgRGF0YTogMDAwMA0KCUNh
cGFiaWxpdGllczogWzc4XSBQb3dlciBNYW5hZ2VtZW50IHZlcnNpb24gMw0KCQlGbGFnczog
UE1FQ2xrLSBEU0ktIEQxKyBEMisgQXV4Q3VycmVudD0zNzVtQSBQTUUoRDArLEQxKyxEMiss
RDNob3QrLEQzY29sZC0pDQoJCVN0YXR1czogRDAgTm9Tb2Z0UnN0KyBQTUUtRW5hYmxlLSBE
U2VsPTAgRFNjYWxlPTAgUE1FLQ0KCUNhcGFiaWxpdGllczogWzgwXSBFeHByZXNzICh2MSkg
RW5kcG9pbnQsIE1TSSAwMA0KCQlEZXZDYXA6CU1heFBheWxvYWQgMjU2IGJ5dGVzLCBQaGFu
dEZ1bmMgMCwgTGF0ZW5jeSBMMHMgdW5saW1pdGVkLCBMMSB1bmxpbWl0ZWQNCgkJCUV4dFRh
Zy0gQXR0bkJ0bi0gQXR0bkluZC0gUHdySW5kLSBSQkUrIEZMUmVzZXQtDQoJCURldkN0bDoJ
UmVwb3J0IGVycm9yczogQ29ycmVjdGFibGUtIE5vbi1GYXRhbC0gRmF0YWwtIFVuc3VwcG9y
dGVkLQ0KCQkJUmx4ZE9yZC0gRXh0VGFnLSBQaGFudEZ1bmMtIEF1eFB3ci0gTm9Tbm9vcCsN
CgkJCU1heFBheWxvYWQgMTI4IGJ5dGVzLCBNYXhSZWFkUmVxIDUxMiBieXRlcw0KCQlEZXZT
dGE6CUNvcnJFcnItIFVuY29yckVyci0gRmF0YWxFcnItIFVuc3VwcFJlcS0gQXV4UHdyLSBU
cmFuc1BlbmQtDQoJCUxua0NhcDoJUG9ydCAjMSwgU3BlZWQgMi41R1QvcywgV2lkdGggeDEs
IEFTUE0gdW5rbm93biwgTGF0ZW5jeSBMMCA8NjRucywgTDEgdW5saW1pdGVkDQoJCQlDbG9j
a1BNKyBTdXJwcmlzZS0gTExBY3RSZXAtIEJ3Tm90LQ0KCQlMbmtDdGw6CUFTUE0gRGlzYWJs
ZWQ7IFJDQiA2NCBieXRlcyBEaXNhYmxlZC0gUmV0cmFpbi0gQ29tbUNsay0NCgkJCUV4dFN5
bmNoLSBDbG9ja1BNLSBBdXRXaWREaXMtIEJXSW50LSBBdXRCV0ludC0NCgkJTG5rU3RhOglT
cGVlZCAyLjVHVC9zLCBXaWR0aCB4MSwgVHJFcnItIFRyYWluLSBTbG90Q2xrLSBETEFjdGl2
ZS0gQldNZ210LSBBQldNZ210LQ0KCUtlcm5lbCBkcml2ZXIgaW4gdXNlOiBwY2liYWNrDQoN
CjA0OjAwLjYgVVNCIGNvbnRyb2xsZXIgWzBjMDNdOiBOZXRNb3MgVGVjaG5vbG9neSBNQ1M5
OTkwIFBDSWUgdG8gNOKAkFBvcnQgVVNCIDIuMCBIb3N0IENvbnRyb2xsZXIgWzk3MTA6OTk5
MF0gKHByb2ctaWYgMTAgW09IQ0ldKQ0KCVN1YnN5c3RlbTogRGV2aWNlIFthMDAwOjQwMDBd
DQoJQ29udHJvbDogSS9PLSBNZW0tIEJ1c01hc3Rlci0gU3BlY0N5Y2xlLSBNZW1XSU5WLSBW
R0FTbm9vcC0gUGFyRXJyLSBTdGVwcGluZy0gU0VSUi0gRmFzdEIyQi0gRGlzSU5UeC0NCglT
dGF0dXM6IENhcCsgNjZNSHotIFVERi0gRmFzdEIyQi0gUGFyRXJyLSBERVZTRUw9ZmFzdCA+
VEFib3J0LSA8VEFib3J0LSA8TUFib3J0LSA+U0VSUi0gPFBFUlItIElOVHgtDQoJSW50ZXJy
dXB0OiBwaW4gRCByb3V0ZWQgdG8gSVJRIDQzDQoJUmVnaW9uIDA6IE1lbW9yeSBhdCBmOThm
ZTAwMCAoMzItYml0LCBub24tcHJlZmV0Y2hhYmxlKSBbZGlzYWJsZWRdIFtzaXplPTRLXQ0K
CUNhcGFiaWxpdGllczogWzUwXSBNU0k6IEVuYWJsZS0gQ291bnQ9MS8xIE1hc2thYmxlLSA2
NGJpdCsNCgkJQWRkcmVzczogMDAwMDAwMDAwMDAwMDAwMCAgRGF0YTogMDAwMA0KCUNhcGFi
aWxpdGllczogWzc4XSBQb3dlciBNYW5hZ2VtZW50IHZlcnNpb24gMw0KCQlGbGFnczogUE1F
Q2xrLSBEU0ktIEQxKyBEMisgQXV4Q3VycmVudD0zNzVtQSBQTUUoRDArLEQxKyxEMissRDNo
b3QrLEQzY29sZC0pDQoJCVN0YXR1czogRDAgTm9Tb2Z0UnN0KyBQTUUtRW5hYmxlLSBEU2Vs
PTAgRFNjYWxlPTAgUE1FLQ0KCUNhcGFiaWxpdGllczogWzgwXSBFeHByZXNzICh2MSkgRW5k
cG9pbnQsIE1TSSAwMA0KCQlEZXZDYXA6CU1heFBheWxvYWQgMjU2IGJ5dGVzLCBQaGFudEZ1
bmMgMCwgTGF0ZW5jeSBMMHMgdW5saW1pdGVkLCBMMSB1bmxpbWl0ZWQNCgkJCUV4dFRhZy0g
QXR0bkJ0bi0gQXR0bkluZC0gUHdySW5kLSBSQkUrIEZMUmVzZXQtDQoJCURldkN0bDoJUmVw
b3J0IGVycm9yczogQ29ycmVjdGFibGUtIE5vbi1GYXRhbC0gRmF0YWwtIFVuc3VwcG9ydGVk
LQ0KCQkJUmx4ZE9yZC0gRXh0VGFnLSBQaGFudEZ1bmMtIEF1eFB3ci0gTm9Tbm9vcCsNCgkJ
CU1heFBheWxvYWQgMTI4IGJ5dGVzLCBNYXhSZWFkUmVxIDUxMiBieXRlcw0KCQlEZXZTdGE6
CUNvcnJFcnItIFVuY29yckVyci0gRmF0YWxFcnItIFVuc3VwcFJlcS0gQXV4UHdyLSBUcmFu
c1BlbmQtDQoJCUxua0NhcDoJUG9ydCAjMSwgU3BlZWQgMi41R1QvcywgV2lkdGggeDEsIEFT
UE0gdW5rbm93biwgTGF0ZW5jeSBMMCA8NjRucywgTDEgdW5saW1pdGVkDQoJCQlDbG9ja1BN
KyBTdXJwcmlzZS0gTExBY3RSZXAtIEJ3Tm90LQ0KCQlMbmtDdGw6CUFTUE0gRGlzYWJsZWQ7
IFJDQiA2NCBieXRlcyBEaXNhYmxlZC0gUmV0cmFpbi0gQ29tbUNsay0NCgkJCUV4dFN5bmNo
LSBDbG9ja1BNLSBBdXRXaWREaXMtIEJXSW50LSBBdXRCV0ludC0NCgkJTG5rU3RhOglTcGVl
ZCAyLjVHVC9zLCBXaWR0aCB4MSwgVHJFcnItIFRyYWluLSBTbG90Q2xrLSBETEFjdGl2ZS0g
QldNZ210LSBBQldNZ210LQ0KCUtlcm5lbCBkcml2ZXIgaW4gdXNlOiBwY2liYWNrDQoNCjA0
OjAwLjcgVVNCIGNvbnRyb2xsZXIgWzBjMDNdOiBOZXRNb3MgVGVjaG5vbG9neSBNQ1M5OTkw
IFBDSWUgdG8gNOKAkFBvcnQgVVNCIDIuMCBIb3N0IENvbnRyb2xsZXIgWzk3MTA6OTk5MF0g
KHByb2ctaWYgMjAgW0VIQ0ldKQ0KCVN1YnN5c3RlbTogRGV2aWNlIFthMDAwOjQwMDBdDQoJ
Q29udHJvbDogSS9PLSBNZW0tIEJ1c01hc3Rlci0gU3BlY0N5Y2xlLSBNZW1XSU5WLSBWR0FT
bm9vcC0gUGFyRXJyLSBTdGVwcGluZy0gU0VSUi0gRmFzdEIyQi0gRGlzSU5UeC0NCglTdGF0
dXM6IENhcCsgNjZNSHotIFVERi0gRmFzdEIyQi0gUGFyRXJyLSBERVZTRUw9ZmFzdCA+VEFi
b3J0LSA8VEFib3J0LSA8TUFib3J0LSA+U0VSUi0gPFBFUlItIElOVHgtDQoJSW50ZXJydXB0
OiBwaW4gRCByb3V0ZWQgdG8gSVJRIDQzDQoJUmVnaW9uIDA6IE1lbW9yeSBhdCBmOThmZjAw
MCAoMzItYml0LCBub24tcHJlZmV0Y2hhYmxlKSBbZGlzYWJsZWRdIFtzaXplPTRLXQ0KCUNh
cGFiaWxpdGllczogWzUwXSBNU0k6IEVuYWJsZS0gQ291bnQ9MS8xIE1hc2thYmxlLSA2NGJp
dCsNCgkJQWRkcmVzczogMDAwMDAwMDAwMDAwMDAwMCAgRGF0YTogMDAwMA0KCUNhcGFiaWxp
dGllczogWzc4XSBQb3dlciBNYW5hZ2VtZW50IHZlcnNpb24gMw0KCQlGbGFnczogUE1FQ2xr
LSBEU0ktIEQxKyBEMisgQXV4Q3VycmVudD0zNzVtQSBQTUUoRDArLEQxKyxEMissRDNob3Qr
LEQzY29sZC0pDQoJCVN0YXR1czogRDAgTm9Tb2Z0UnN0KyBQTUUtRW5hYmxlLSBEU2VsPTAg
RFNjYWxlPTAgUE1FLQ0KCUNhcGFiaWxpdGllczogWzgwXSBFeHByZXNzICh2MSkgRW5kcG9p
bnQsIE1TSSAwMA0KCQlEZXZDYXA6CU1heFBheWxvYWQgMjU2IGJ5dGVzLCBQaGFudEZ1bmMg
MCwgTGF0ZW5jeSBMMHMgdW5saW1pdGVkLCBMMSB1bmxpbWl0ZWQNCgkJCUV4dFRhZy0gQXR0
bkJ0bi0gQXR0bkluZC0gUHdySW5kLSBSQkUrIEZMUmVzZXQtDQoJCURldkN0bDoJUmVwb3J0
IGVycm9yczogQ29ycmVjdGFibGUtIE5vbi1GYXRhbC0gRmF0YWwtIFVuc3VwcG9ydGVkLQ0K
CQkJUmx4ZE9yZC0gRXh0VGFnLSBQaGFudEZ1bmMtIEF1eFB3ci0gTm9Tbm9vcCsNCgkJCU1h
eFBheWxvYWQgMTI4IGJ5dGVzLCBNYXhSZWFkUmVxIDUxMiBieXRlcw0KCQlEZXZTdGE6CUNv
cnJFcnItIFVuY29yckVyci0gRmF0YWxFcnItIFVuc3VwcFJlcS0gQXV4UHdyLSBUcmFuc1Bl
bmQtDQoJCUxua0NhcDoJUG9ydCAjMSwgU3BlZWQgMi41R1QvcywgV2lkdGggeDEsIEFTUE0g
dW5rbm93biwgTGF0ZW5jeSBMMCA8NjRucywgTDEgdW5saW1pdGVkDQoJCQlDbG9ja1BNKyBT
dXJwcmlzZS0gTExBY3RSZXAtIEJ3Tm90LQ0KCQlMbmtDdGw6CUFTUE0gRGlzYWJsZWQ7IFJD
QiA2NCBieXRlcyBEaXNhYmxlZC0gUmV0cmFpbi0gQ29tbUNsay0NCgkJCUV4dFN5bmNoLSBD
bG9ja1BNLSBBdXRXaWREaXMtIEJXSW50LSBBdXRCV0ludC0NCgkJTG5rU3RhOglTcGVlZCAy
LjVHVC9zLCBXaWR0aCB4MSwgVHJFcnItIFRyYWluLSBTbG90Q2xrLSBETEFjdGl2ZS0gQldN
Z210LSBBQldNZ210LQ0KCUtlcm5lbCBkcml2ZXIgaW4gdXNlOiBwY2liYWNrDQoNCjA1OjAw
LjAgVkdBIGNvbXBhdGlibGUgY29udHJvbGxlciBbMDMwMF06IEFUSSBUZWNobm9sb2dpZXMg
SW5jIFJWNjIwIExFIFtSYWRlb24gSEQgMzQ1MF0gWzEwMDI6OTVjNV0gKHByb2ctaWYgMDAg
W1ZHQSBjb250cm9sbGVyXSkNCglTdWJzeXN0ZW06IEFTVVNUZUsgQ29tcHV0ZXIgSW5jLiBE
ZXZpY2UgWzEwNDM6MDFkNF0NCglDb250cm9sOiBJL08tIE1lbS0gQnVzTWFzdGVyLSBTcGVj
Q3ljbGUtIE1lbVdJTlYtIFZHQVNub29wLSBQYXJFcnItIFN0ZXBwaW5nLSBTRVJSLSBGYXN0
QjJCLSBEaXNJTlR4LQ0KCVN0YXR1czogQ2FwKyA2Nk1Iei0gVURGLSBGYXN0QjJCLSBQYXJF
cnItIERFVlNFTD1mYXN0ID5UQWJvcnQtIDxUQWJvcnQtIDxNQWJvcnQtID5TRVJSLSA8UEVS
Ui0gSU5UeC0NCglJbnRlcnJ1cHQ6IHBpbiBBIHJvdXRlZCB0byBJUlEgMTANCglSZWdpb24g
MDogTWVtb3J5IGF0IGIwMDAwMDAwICg2NC1iaXQsIHByZWZldGNoYWJsZSkgW2Rpc2FibGVk
XSBbc2l6ZT0yNTZNXQ0KCVJlZ2lvbiAyOiBNZW1vcnkgYXQgZjk5ZTAwMDAgKDY0LWJpdCwg
bm9uLXByZWZldGNoYWJsZSkgW2Rpc2FibGVkXSBbc2l6ZT02NEtdDQoJUmVnaW9uIDQ6IEkv
TyBwb3J0cyBhdCBiMDAwIFtkaXNhYmxlZF0gW3NpemU9MjU2XQ0KCUV4cGFuc2lvbiBST00g
YXQgZjk5YzAwMDAgW2Rpc2FibGVkXSBbc2l6ZT0xMjhLXQ0KCUNhcGFiaWxpdGllczogWzUw
XSBQb3dlciBNYW5hZ2VtZW50IHZlcnNpb24gMw0KCQlGbGFnczogUE1FQ2xrLSBEU0ktIEQx
KyBEMisgQXV4Q3VycmVudD0wbUEgUE1FKEQwLSxEMS0sRDItLEQzaG90LSxEM2NvbGQtKQ0K
CQlTdGF0dXM6IEQwIE5vU29mdFJzdC0gUE1FLUVuYWJsZS0gRFNlbD0wIERTY2FsZT0wIFBN
RS0NCglDYXBhYmlsaXRpZXM6IFs1OF0gRXhwcmVzcyAodjIpIExlZ2FjeSBFbmRwb2ludCwg
TVNJIDAwDQoJCURldkNhcDoJTWF4UGF5bG9hZCAxMjggYnl0ZXMsIFBoYW50RnVuYyAwLCBM
YXRlbmN5IEwwcyA8NHVzLCBMMSB1bmxpbWl0ZWQNCgkJCUV4dFRhZysgQXR0bkJ0bi0gQXR0
bkluZC0gUHdySW5kLSBSQkUrIEZMUmVzZXQtDQoJCURldkN0bDoJUmVwb3J0IGVycm9yczog
Q29ycmVjdGFibGUtIE5vbi1GYXRhbC0gRmF0YWwtIFVuc3VwcG9ydGVkLQ0KCQkJUmx4ZE9y
ZCsgRXh0VGFnLSBQaGFudEZ1bmMtIEF1eFB3ci0gTm9Tbm9vcCsNCgkJCU1heFBheWxvYWQg
MTI4IGJ5dGVzLCBNYXhSZWFkUmVxIDEyOCBieXRlcw0KCQlEZXZTdGE6CUNvcnJFcnItIFVu
Y29yckVyci0gRmF0YWxFcnItIFVuc3VwcFJlcS0gQXV4UHdyLSBUcmFuc1BlbmQtDQoJCUxu
a0NhcDoJUG9ydCAjMCwgU3BlZWQgMi41R1QvcywgV2lkdGggeDE2LCBBU1BNIEwwcyBMMSwg
TGF0ZW5jeSBMMCA8NjRucywgTDEgPDF1cw0KCQkJQ2xvY2tQTS0gU3VycHJpc2UtIExMQWN0
UmVwLSBCd05vdC0NCgkJTG5rQ3RsOglBU1BNIERpc2FibGVkOyBSQ0IgNjQgYnl0ZXMgRGlz
YWJsZWQtIFJldHJhaW4tIENvbW1DbGsrDQoJCQlFeHRTeW5jaC0gQ2xvY2tQTS0gQXV0V2lk
RGlzLSBCV0ludC0gQXV0QldJbnQtDQoJCUxua1N0YToJU3BlZWQgMi41R1QvcywgV2lkdGgg
eDE2LCBUckVyci0gVHJhaW4tIFNsb3RDbGsrIERMQWN0aXZlLSBCV01nbXQtIEFCV01nbXQt
DQoJCURldkNhcDI6IENvbXBsZXRpb24gVGltZW91dDogTm90IFN1cHBvcnRlZCwgVGltZW91
dERpcy0NCgkJRGV2Q3RsMjogQ29tcGxldGlvbiBUaW1lb3V0OiA1MHVzIHRvIDUwbXMsIFRp
bWVvdXREaXMtDQoJCUxua0N0bDI6IFRhcmdldCBMaW5rIFNwZWVkOiAyLjVHVC9zLCBFbnRl
ckNvbXBsaWFuY2UtIFNwZWVkRGlzLSwgU2VsZWN0YWJsZSBEZS1lbXBoYXNpczogLTZkQg0K
CQkJIFRyYW5zbWl0IE1hcmdpbjogTm9ybWFsIE9wZXJhdGluZyBSYW5nZSwgRW50ZXJNb2Rp
ZmllZENvbXBsaWFuY2UtIENvbXBsaWFuY2VTT1MtDQoJCQkgQ29tcGxpYW5jZSBEZS1lbXBo
YXNpczogLTZkQg0KCQlMbmtTdGEyOiBDdXJyZW50IERlLWVtcGhhc2lzIExldmVsOiAtNmRC
DQoJQ2FwYWJpbGl0aWVzOiBbYTBdIE1TSTogRW5hYmxlLSBDb3VudD0xLzEgTWFza2FibGUt
IDY0Yml0Kw0KCQlBZGRyZXNzOiAwMDAwMDAwMDAwMDAwMDAwICBEYXRhOiAwMDAwDQoJQ2Fw
YWJpbGl0aWVzOiBbMTAwIHYxXSBWZW5kb3IgU3BlY2lmaWMgSW5mb3JtYXRpb246IElEPTAw
MDEgUmV2PTEgTGVuPTAxMCA8Pz4NCg0KMDU6MDAuMSBBdWRpbyBkZXZpY2UgWzA0MDNdOiBB
VEkgVGVjaG5vbG9naWVzIEluYyBSVjYyMCBBdWRpbyBkZXZpY2UgW1JhZGVvbiBIRCAzNHh4
IFNlcmllc10gWzEwMDI6YWEyOF0NCglTdWJzeXN0ZW06IEFTVVNUZUsgQ29tcHV0ZXIgSW5j
LiBEZXZpY2UgWzEwNDM6YWEyOF0NCglDb250cm9sOiBJL08rIE1lbSsgQnVzTWFzdGVyKyBT
cGVjQ3ljbGUtIE1lbVdJTlYtIFZHQVNub29wLSBQYXJFcnItIFN0ZXBwaW5nLSBTRVJSKyBG
YXN0QjJCLSBEaXNJTlR4Kw0KCVN0YXR1czogQ2FwKyA2Nk1Iei0gVURGLSBGYXN0QjJCLSBQ
YXJFcnItIERFVlNFTD1mYXN0ID5UQWJvcnQtIDxUQWJvcnQtIDxNQWJvcnQtID5TRVJSLSA8
UEVSUi0gSU5UeC0NCglMYXRlbmN5OiAwLCBDYWNoZSBMaW5lIFNpemU6IDY0IGJ5dGVzDQoJ
SW50ZXJydXB0OiBwaW4gQiByb3V0ZWQgdG8gSVJRIDEyMg0KCVJlZ2lvbiAwOiBNZW1vcnkg
YXQgZjk5ZmMwMDAgKDY0LWJpdCwgbm9uLXByZWZldGNoYWJsZSkgW3NpemU9MTZLXQ0KCUNh
cGFiaWxpdGllczogWzUwXSBQb3dlciBNYW5hZ2VtZW50IHZlcnNpb24gMw0KCQlGbGFnczog
UE1FQ2xrLSBEU0ktIEQxKyBEMisgQXV4Q3VycmVudD0wbUEgUE1FKEQwLSxEMS0sRDItLEQz
aG90LSxEM2NvbGQtKQ0KCQlTdGF0dXM6IEQwIE5vU29mdFJzdC0gUE1FLUVuYWJsZS0gRFNl
bD0wIERTY2FsZT0wIFBNRS0NCglDYXBhYmlsaXRpZXM6IFs1OF0gRXhwcmVzcyAodjIpIExl
Z2FjeSBFbmRwb2ludCwgTVNJIDAwDQoJCURldkNhcDoJTWF4UGF5bG9hZCAxMjggYnl0ZXMs
IFBoYW50RnVuYyAwLCBMYXRlbmN5IEwwcyA8NHVzLCBMMSB1bmxpbWl0ZWQNCgkJCUV4dFRh
ZysgQXR0bkJ0bi0gQXR0bkluZC0gUHdySW5kLSBSQkUrIEZMUmVzZXQtDQoJCURldkN0bDoJ
UmVwb3J0IGVycm9yczogQ29ycmVjdGFibGUtIE5vbi1GYXRhbC0gRmF0YWwtIFVuc3VwcG9y
dGVkLQ0KCQkJUmx4ZE9yZCsgRXh0VGFnLSBQaGFudEZ1bmMtIEF1eFB3ci0gTm9Tbm9vcCsN
CgkJCU1heFBheWxvYWQgMTI4IGJ5dGVzLCBNYXhSZWFkUmVxIDEyOCBieXRlcw0KCQlEZXZT
dGE6CUNvcnJFcnItIFVuY29yckVyci0gRmF0YWxFcnItIFVuc3VwcFJlcS0gQXV4UHdyLSBU
cmFuc1BlbmQtDQoJCUxua0NhcDoJUG9ydCAjMCwgU3BlZWQgMi41R1QvcywgV2lkdGggeDE2
LCBBU1BNIEwwcyBMMSwgTGF0ZW5jeSBMMCA8NjRucywgTDEgPDF1cw0KCQkJQ2xvY2tQTS0g
U3VycHJpc2UtIExMQWN0UmVwLSBCd05vdC0NCgkJTG5rQ3RsOglBU1BNIERpc2FibGVkOyBS
Q0IgNjQgYnl0ZXMgRGlzYWJsZWQtIFJldHJhaW4tIENvbW1DbGsrDQoJCQlFeHRTeW5jaC0g
Q2xvY2tQTS0gQXV0V2lkRGlzLSBCV0ludC0gQXV0QldJbnQtDQoJCUxua1N0YToJU3BlZWQg
Mi41R1QvcywgV2lkdGggeDE2LCBUckVyci0gVHJhaW4tIFNsb3RDbGsrIERMQWN0aXZlLSBC
V01nbXQtIEFCV01nbXQtDQoJCURldkNhcDI6IENvbXBsZXRpb24gVGltZW91dDogTm90IFN1
cHBvcnRlZCwgVGltZW91dERpcy0NCgkJRGV2Q3RsMjogQ29tcGxldGlvbiBUaW1lb3V0OiA1
MHVzIHRvIDUwbXMsIFRpbWVvdXREaXMtDQoJCUxua0N0bDI6IFRhcmdldCBMaW5rIFNwZWVk
OiAyLjVHVC9zLCBFbnRlckNvbXBsaWFuY2UtIFNwZWVkRGlzLSwgU2VsZWN0YWJsZSBEZS1l
bXBoYXNpczogLTZkQg0KCQkJIFRyYW5zbWl0IE1hcmdpbjogTm9ybWFsIE9wZXJhdGluZyBS
YW5nZSwgRW50ZXJNb2RpZmllZENvbXBsaWFuY2UtIENvbXBsaWFuY2VTT1MtDQoJCQkgQ29t
cGxpYW5jZSBEZS1lbXBoYXNpczogLTZkQg0KCQlMbmtTdGEyOiBDdXJyZW50IERlLWVtcGhh
c2lzIExldmVsOiAtNmRCDQoJQ2FwYWJpbGl0aWVzOiBbYTBdIE1TSTogRW5hYmxlKyBDb3Vu
dD0xLzEgTWFza2FibGUtIDY0Yml0Kw0KCQlBZGRyZXNzOiAwMDAwMDAwMGZlZTAxMDBjICBE
YXRhOiA0MWQ5DQoJQ2FwYWJpbGl0aWVzOiBbMTAwIHYxXSBWZW5kb3IgU3BlY2lmaWMgSW5m
b3JtYXRpb246IElEPTAwMDEgUmV2PTEgTGVuPTAxMCA8Pz4NCglLZXJuZWwgZHJpdmVyIGlu
IHVzZTogc25kX2hkYV9pbnRlbA0KDQowNjowMC4wIE11bHRpbWVkaWEgdmlkZW8gY29udHJv
bGxlciBbMDQwMF06IENvbmV4YW50IFN5c3RlbXMsIEluYy4gRGV2aWNlIFsxNGYxOjgyMTBd
DQoJQ29udHJvbDogSS9PLSBNZW0rIEJ1c01hc3RlcisgU3BlY0N5Y2xlLSBNZW1XSU5WLSBW
R0FTbm9vcC0gUGFyRXJyLSBTdGVwcGluZy0gU0VSUi0gRmFzdEIyQi0gRGlzSU5UeC0NCglT
dGF0dXM6IENhcCsgNjZNSHotIFVERi0gRmFzdEIyQi0gUGFyRXJyLSBERVZTRUw9ZmFzdCA+
VEFib3J0LSA8VEFib3J0LSA8TUFib3J0LSA+U0VSUi0gPFBFUlItIElOVHgtDQoJTGF0ZW5j
eTogMA0KCUludGVycnVwdDogcGluIEEgcm91dGVkIHRvIElSUSA0Nw0KCVJlZ2lvbiAwOiBN
ZW1vcnkgYXQgZjlhMDAwMDAgKDY0LWJpdCwgbm9uLXByZWZldGNoYWJsZSkgW3NpemU9Mk1d
DQoJQ2FwYWJpbGl0aWVzOiBbNDBdIEV4cHJlc3MgKHYxKSBFbmRwb2ludCwgTVNJIDAwDQoJ
CURldkNhcDoJTWF4UGF5bG9hZCAxMjggYnl0ZXMsIFBoYW50RnVuYyAwLCBMYXRlbmN5IEww
cyA8NjRucywgTDEgPDF1cw0KCQkJRXh0VGFnLSBBdHRuQnRuLSBBdHRuSW5kLSBQd3JJbmQt
IFJCRSsgRkxSZXNldC0NCgkJRGV2Q3RsOglSZXBvcnQgZXJyb3JzOiBDb3JyZWN0YWJsZS0g
Tm9uLUZhdGFsLSBGYXRhbC0gVW5zdXBwb3J0ZWQtDQoJCQlSbHhkT3JkKyBFeHRUYWctIFBo
YW50RnVuYy0gQXV4UHdyLSBOb1Nub29wKw0KCQkJTWF4UGF5bG9hZCAxMjggYnl0ZXMsIE1h
eFJlYWRSZXEgNTEyIGJ5dGVzDQoJCURldlN0YToJQ29yckVycisgVW5jb3JyRXJyKyBGYXRh
bEVyci0gVW5zdXBwUmVxKyBBdXhQd3ItIFRyYW5zUGVuZC0NCgkJTG5rQ2FwOglQb3J0ICMw
LCBTcGVlZCAyLjVHVC9zLCBXaWR0aCB4MSwgQVNQTSBMMHMgTDEsIExhdGVuY3kgTDAgPDJ1
cywgTDEgPDR1cw0KCQkJQ2xvY2tQTS0gU3VycHJpc2UtIExMQWN0UmVwLSBCd05vdC0NCgkJ
TG5rQ3RsOglBU1BNIERpc2FibGVkOyBSQ0IgNjQgYnl0ZXMgRGlzYWJsZWQtIFJldHJhaW4t
IENvbW1DbGstDQoJCQlFeHRTeW5jaC0gQ2xvY2tQTS0gQXV0V2lkRGlzLSBCV0ludC0gQXV0
QldJbnQtDQoJCUxua1N0YToJU3BlZWQgMi41R1QvcywgV2lkdGggeDEsIFRyRXJyLSBUcmFp
bi0gU2xvdENsay0gRExBY3RpdmUtIEJXTWdtdC0gQUJXTWdtdC0NCglDYXBhYmlsaXRpZXM6
IFs4MF0gUG93ZXIgTWFuYWdlbWVudCB2ZXJzaW9uIDMNCgkJRmxhZ3M6IFBNRUNsay0gRFNJ
KyBEMSsgRDIrIEF1eEN1cnJlbnQ9MG1BIFBNRShEMCssRDErLEQyKyxEM2hvdCssRDNjb2xk
LSkNCgkJU3RhdHVzOiBEMCBOb1NvZnRSc3QrIFBNRS1FbmFibGUtIERTZWw9MCBEU2NhbGU9
MCBQTUUtDQoJQ2FwYWJpbGl0aWVzOiBbOTBdIFZpdGFsIFByb2R1Y3QgRGF0YQ0KCQlVbmtu
b3duIHNtYWxsIHJlc291cmNlIHR5cGUgMDAsIHdpbGwgbm90IGRlY29kZSBtb3JlLg0KCUNh
cGFiaWxpdGllczogW2EwXSBNU0k6IEVuYWJsZS0gQ291bnQ9MS8xIE1hc2thYmxlLSA2NGJp
dCsNCgkJQWRkcmVzczogMDAwMDAwMDAwMDAwMDAwMCAgRGF0YTogMDAwMA0KCUNhcGFiaWxp
dGllczogWzEwMCB2MV0gQWR2YW5jZWQgRXJyb3IgUmVwb3J0aW5nDQoJCVVFU3RhOglETFAt
IFNERVMtIFRMUC0gRkNQLSBDbXBsdFRPLSBDbXBsdEFicnQtIFVueENtcGx0LSBSeE9GLSBN
YWxmVExQLSBFQ1JDLSBVbnN1cFJlcSsgQUNTVmlvbC0NCgkJVUVNc2s6CURMUC0gU0RFUy0g
VExQLSBGQ1AtIENtcGx0VE8tIENtcGx0QWJydC0gVW54Q21wbHQtIFJ4T0YtIE1hbGZUTFAt
IEVDUkMtIFVuc3VwUmVxLSBBQ1NWaW9sLQ0KCQlVRVN2cnQ6CURMUCsgU0RFUy0gVExQLSBG
Q1ArIENtcGx0VE8tIENtcGx0QWJydC0gVW54Q21wbHQtIFJ4T0YrIE1hbGZUTFArIEVDUkMt
IFVuc3VwUmVxLSBBQ1NWaW9sLQ0KCQlDRVN0YToJUnhFcnItIEJhZFRMUC0gQmFkRExMUC0g
Um9sbG92ZXItIFRpbWVvdXQtIE5vbkZhdGFsRXJyKw0KCQlDRU1zazoJUnhFcnItIEJhZFRM
UC0gQmFkRExMUC0gUm9sbG92ZXItIFRpbWVvdXQtIE5vbkZhdGFsRXJyKw0KCQlBRVJDYXA6
CUZpcnN0IEVycm9yIFBvaW50ZXI6IDE0LCBHZW5DYXAtIENHZW5Fbi0gQ2hrQ2FwLSBDaGtF
bi0NCglDYXBhYmlsaXRpZXM6IFsyMDAgdjFdIFZpcnR1YWwgQ2hhbm5lbA0KCQlDYXBzOglM
UEVWQz0xIFJlZkNsaz0xMDBucyBQQVRFbnRyeUJpdHM9MQ0KCQlBcmI6CUZpeGVkKyBXUlIz
MisgV1JSNjQrIFdSUjEyOC0NCgkJQ3RybDoJQXJiU2VsZWN0PVdSUjY0DQoJCVN0YXR1czoJ
SW5Qcm9ncmVzcy0NCgkJUG9ydCBBcmJpdHJhdGlvbiBUYWJsZSBbMjQwXSA8Pz4NCgkJVkMw
OglDYXBzOglQQVRPZmZzZXQ9MDAgTWF4VGltZVNsb3RzPTEgUmVqU25vb3BUcmFucy0NCgkJ
CUFyYjoJRml4ZWQtIFdSUjMyLSBXUlI2NC0gV1JSMTI4LSBUV1JSMTI4LSBXUlIyNTYtDQoJ
CQlDdHJsOglFbmFibGUrIElEPTAgQXJiU2VsZWN0PUZpeGVkIFRDL1ZDPWZmDQoJCQlTdGF0
dXM6CU5lZ29QZW5kaW5nLSBJblByb2dyZXNzLQ0KCQlWQzE6CUNhcHM6CVBBVE9mZnNldD0w
MCBNYXhUaW1lU2xvdHM9MSBSZWpTbm9vcFRyYW5zLQ0KCQkJQXJiOglGaXhlZC0gV1JSMzIt
IFdSUjY0LSBXUlIxMjgtIFRXUlIxMjgtIFdSUjI1Ni0NCgkJCUN0cmw6CUVuYWJsZS0gSUQ9
MSBBcmJTZWxlY3Q9Rml4ZWQgVEMvVkM9MDANCgkJCVN0YXR1czoJTmVnb1BlbmRpbmctIElu
UHJvZ3Jlc3MtDQoJS2VybmVsIGRyaXZlciBpbiB1c2U6IHBjaWJhY2sNCg0KMDc6MDAuMCBF
dGhlcm5ldCBjb250cm9sbGVyIFswMjAwXTogUmVhbHRlayBTZW1pY29uZHVjdG9yIENvLiwg
THRkLiBSVEw4MTExLzgxNjhCIFBDSSBFeHByZXNzIEdpZ2FiaXQgRXRoZXJuZXQgY29udHJv
bGxlciBbMTBlYzo4MTY4XSAocmV2IDAzKQ0KCVN1YnN5c3RlbTogTWljcm8tU3RhciBJbnRl
cm5hdGlvbmFsIENvLiwgTHRkLiBEZXZpY2UgWzE0NjI6NzY0MF0NCglDb250cm9sOiBJL08r
IE1lbSsgQnVzTWFzdGVyKyBTcGVjQ3ljbGUtIE1lbVdJTlYtIFZHQVNub29wLSBQYXJFcnIt
IFN0ZXBwaW5nLSBTRVJSKyBGYXN0QjJCLSBEaXNJTlR4Kw0KCVN0YXR1czogQ2FwKyA2Nk1I
ei0gVURGLSBGYXN0QjJCLSBQYXJFcnItIERFVlNFTD1mYXN0ID5UQWJvcnQtIDxUQWJvcnQt
IDxNQWJvcnQtID5TRVJSLSA8UEVSUi0gSU5UeC0NCglMYXRlbmN5OiAwLCBDYWNoZSBMaW5l
IFNpemU6IDY0IGJ5dGVzDQoJSW50ZXJydXB0OiBwaW4gQSByb3V0ZWQgdG8gSVJRIDEyMQ0K
CVJlZ2lvbiAwOiBJL08gcG9ydHMgYXQgYzgwMCBbc2l6ZT0yNTZdDQoJUmVnaW9uIDI6IE1l
bW9yeSBhdCBjZmVmZjAwMCAoNjQtYml0LCBwcmVmZXRjaGFibGUpIFtzaXplPTRLXQ0KCVJl
Z2lvbiA0OiBNZW1vcnkgYXQgY2ZlZjgwMDAgKDY0LWJpdCwgcHJlZmV0Y2hhYmxlKSBbc2l6
ZT0xNktdDQoJRXhwYW5zaW9uIFJPTSBhdCBmOWRlMDAwMCBbZGlzYWJsZWRdIFtzaXplPTEy
OEtdDQoJQ2FwYWJpbGl0aWVzOiBbNDBdIFBvd2VyIE1hbmFnZW1lbnQgdmVyc2lvbiAzDQoJ
CUZsYWdzOiBQTUVDbGstIERTSS0gRDErIEQyKyBBdXhDdXJyZW50PTM3NW1BIFBNRShEMCss
RDErLEQyKyxEM2hvdCssRDNjb2xkKykNCgkJU3RhdHVzOiBEMCBOb1NvZnRSc3QrIFBNRS1F
bmFibGUtIERTZWw9MCBEU2NhbGU9MCBQTUUtDQoJQ2FwYWJpbGl0aWVzOiBbNTBdIE1TSTog
RW5hYmxlKyBDb3VudD0xLzEgTWFza2FibGUtIDY0Yml0Kw0KCQlBZGRyZXNzOiAwMDAwMDAw
MGZlZTAxMDBjICBEYXRhOiA0MWM5DQoJQ2FwYWJpbGl0aWVzOiBbNzBdIEV4cHJlc3MgKHYy
KSBFbmRwb2ludCwgTVNJIDAxDQoJCURldkNhcDoJTWF4UGF5bG9hZCAyNTYgYnl0ZXMsIFBo
YW50RnVuYyAwLCBMYXRlbmN5IEwwcyA8NTEybnMsIEwxIDw2NHVzDQoJCQlFeHRUYWctIEF0
dG5CdG4tIEF0dG5JbmQtIFB3ckluZC0gUkJFKyBGTFJlc2V0LQ0KCQlEZXZDdGw6CVJlcG9y
dCBlcnJvcnM6IENvcnJlY3RhYmxlLSBOb24tRmF0YWwtIEZhdGFsLSBVbnN1cHBvcnRlZC0N
CgkJCVJseGRPcmQtIEV4dFRhZy0gUGhhbnRGdW5jLSBBdXhQd3ItIE5vU25vb3AtDQoJCQlN
YXhQYXlsb2FkIDEyOCBieXRlcywgTWF4UmVhZFJlcSA1MTIgYnl0ZXMNCgkJRGV2U3RhOglD
b3JyRXJyKyBVbmNvcnJFcnItIEZhdGFsRXJyLSBVbnN1cHBSZXErIEF1eFB3cisgVHJhbnNQ
ZW5kLQ0KCQlMbmtDYXA6CVBvcnQgIzAsIFNwZWVkIDIuNUdUL3MsIFdpZHRoIHgxLCBBU1BN
IEwwcyBMMSwgTGF0ZW5jeSBMMCA8NTEybnMsIEwxIDw2NHVzDQoJCQlDbG9ja1BNKyBTdXJw
cmlzZS0gTExBY3RSZXAtIEJ3Tm90LQ0KCQlMbmtDdGw6CUFTUE0gRGlzYWJsZWQ7IFJDQiA2
NCBieXRlcyBEaXNhYmxlZC0gUmV0cmFpbi0gQ29tbUNsaysNCgkJCUV4dFN5bmNoLSBDbG9j
a1BNLSBBdXRXaWREaXMtIEJXSW50LSBBdXRCV0ludC0NCgkJTG5rU3RhOglTcGVlZCAyLjVH
VC9zLCBXaWR0aCB4MSwgVHJFcnItIFRyYWluLSBTbG90Q2xrKyBETEFjdGl2ZS0gQldNZ210
LSBBQldNZ210LQ0KCQlEZXZDYXAyOiBDb21wbGV0aW9uIFRpbWVvdXQ6IE5vdCBTdXBwb3J0
ZWQsIFRpbWVvdXREaXMrDQoJCURldkN0bDI6IENvbXBsZXRpb24gVGltZW91dDogNTB1cyB0
byA1MG1zLCBUaW1lb3V0RGlzLQ0KCQlMbmtDdGwyOiBUYXJnZXQgTGluayBTcGVlZDogMi41
R1QvcywgRW50ZXJDb21wbGlhbmNlLSBTcGVlZERpcy0sIFNlbGVjdGFibGUgRGUtZW1waGFz
aXM6IC02ZEINCgkJCSBUcmFuc21pdCBNYXJnaW46IE5vcm1hbCBPcGVyYXRpbmcgUmFuZ2Us
IEVudGVyTW9kaWZpZWRDb21wbGlhbmNlLSBDb21wbGlhbmNlU09TLQ0KCQkJIENvbXBsaWFu
Y2UgRGUtZW1waGFzaXM6IC02ZEINCgkJTG5rU3RhMjogQ3VycmVudCBEZS1lbXBoYXNpcyBM
ZXZlbDogLTZkQg0KCUNhcGFiaWxpdGllczogW2FjXSBNU0ktWDogRW5hYmxlLSBDb3VudD00
IE1hc2tlZC0NCgkJVmVjdG9yIHRhYmxlOiBCQVI9NCBvZmZzZXQ9MDAwMDAwMDANCgkJUEJB
OiBCQVI9NCBvZmZzZXQ9MDAwMDA4MDANCglDYXBhYmlsaXRpZXM6IFtjY10gVml0YWwgUHJv
ZHVjdCBEYXRhDQoJCVVua25vd24gc21hbGwgcmVzb3VyY2UgdHlwZSAwMCwgd2lsbCBub3Qg
ZGVjb2RlIG1vcmUuDQoJQ2FwYWJpbGl0aWVzOiBbMTAwIHYxXSBBZHZhbmNlZCBFcnJvciBS
ZXBvcnRpbmcNCgkJVUVTdGE6CURMUC0gU0RFUy0gVExQLSBGQ1AtIENtcGx0VE8tIENtcGx0
QWJydC0gVW54Q21wbHQtIFJ4T0YtIE1hbGZUTFAtIEVDUkMtIFVuc3VwUmVxLSBBQ1NWaW9s
LQ0KCQlVRU1zazoJRExQLSBTREVTLSBUTFAtIEZDUC0gQ21wbHRUTy0gQ21wbHRBYnJ0LSBV
bnhDbXBsdC0gUnhPRi0gTWFsZlRMUC0gRUNSQy0gVW5zdXBSZXEtIEFDU1Zpb2wtDQoJCVVF
U3ZydDoJRExQKyBTREVTKyBUTFAtIEZDUCsgQ21wbHRUTy0gQ21wbHRBYnJ0LSBVbnhDbXBs
dC0gUnhPRisgTWFsZlRMUCsgRUNSQy0gVW5zdXBSZXEtIEFDU1Zpb2wtDQoJCUNFU3RhOglS
eEVyci0gQmFkVExQLSBCYWRETExQLSBSb2xsb3Zlci0gVGltZW91dC0gTm9uRmF0YWxFcnIr
DQoJCUNFTXNrOglSeEVyci0gQmFkVExQLSBCYWRETExQLSBSb2xsb3Zlci0gVGltZW91dC0g
Tm9uRmF0YWxFcnIrDQoJCUFFUkNhcDoJRmlyc3QgRXJyb3IgUG9pbnRlcjogMDAsIEdlbkNh
cCsgQ0dlbkVuLSBDaGtDYXArIENoa0VuLQ0KCUNhcGFiaWxpdGllczogWzE0MCB2MV0gVmly
dHVhbCBDaGFubmVsDQoJCUNhcHM6CUxQRVZDPTAgUmVmQ2xrPTEwMG5zIFBBVEVudHJ5Qml0
cz0xDQoJCUFyYjoJRml4ZWQtIFdSUjMyLSBXUlI2NC0gV1JSMTI4LQ0KCQlDdHJsOglBcmJT
ZWxlY3Q9Rml4ZWQNCgkJU3RhdHVzOglJblByb2dyZXNzLQ0KCQlWQzA6CUNhcHM6CVBBVE9m
ZnNldD0wMCBNYXhUaW1lU2xvdHM9MSBSZWpTbm9vcFRyYW5zLQ0KCQkJQXJiOglGaXhlZC0g
V1JSMzItIFdSUjY0LSBXUlIxMjgtIFRXUlIxMjgtIFdSUjI1Ni0NCgkJCUN0cmw6CUVuYWJs
ZSsgSUQ9MCBBcmJTZWxlY3Q9Rml4ZWQgVEMvVkM9ZmYNCgkJCVN0YXR1czoJTmVnb1BlbmRp
bmctIEluUHJvZ3Jlc3MtDQoJQ2FwYWJpbGl0aWVzOiBbMTYwIHYxXSBEZXZpY2UgU2VyaWFs
IE51bWJlciAwMy0wMC0wMC0wMC02OC00Yy1lMC0wMA0KCUtlcm5lbCBkcml2ZXIgaW4gdXNl
OiByODE2OQ0KDQowODowMC4wIEV0aGVybmV0IGNvbnRyb2xsZXIgWzAyMDBdOiBSZWFsdGVr
IFNlbWljb25kdWN0b3IgQ28uLCBMdGQuIFJUTDgxMTEvODE2OEIgUENJIEV4cHJlc3MgR2ln
YWJpdCBFdGhlcm5ldCBjb250cm9sbGVyIFsxMGVjOjgxNjhdIChyZXYgMDMpDQoJU3Vic3lz
dGVtOiBNaWNyby1TdGFyIEludGVybmF0aW9uYWwgQ28uLCBMdGQuIERldmljZSBbMTQ2Mjo3
NjQwXQ0KCUNvbnRyb2w6IEkvTysgTWVtKyBCdXNNYXN0ZXIrIFNwZWNDeWNsZS0gTWVtV0lO
Vi0gVkdBU25vb3AtIFBhckVyci0gU3RlcHBpbmctIFNFUlIrIEZhc3RCMkItIERpc0lOVHgr
DQoJU3RhdHVzOiBDYXArIDY2TUh6LSBVREYtIEZhc3RCMkItIFBhckVyci0gREVWU0VMPWZh
c3QgPlRBYm9ydC0gPFRBYm9ydC0gPE1BYm9ydC0gPlNFUlItIDxQRVJSLSBJTlR4LQ0KCUxh
dGVuY3k6IDAsIENhY2hlIExpbmUgU2l6ZTogNjQgYnl0ZXMNCglJbnRlcnJ1cHQ6IHBpbiBB
IHJvdXRlZCB0byBJUlEgMTIwDQoJUmVnaW9uIDA6IEkvTyBwb3J0cyBhdCBkODAwIFtzaXpl
PTI1Nl0NCglSZWdpb24gMjogTWVtb3J5IGF0IGNmZmZmMDAwICg2NC1iaXQsIHByZWZldGNo
YWJsZSkgW3NpemU9NEtdDQoJUmVnaW9uIDQ6IE1lbW9yeSBhdCBjZmZmODAwMCAoNjQtYml0
LCBwcmVmZXRjaGFibGUpIFtzaXplPTE2S10NCglFeHBhbnNpb24gUk9NIGF0IGY5ZWUwMDAw
IFtkaXNhYmxlZF0gW3NpemU9MTI4S10NCglDYXBhYmlsaXRpZXM6IFs0MF0gUG93ZXIgTWFu
YWdlbWVudCB2ZXJzaW9uIDMNCgkJRmxhZ3M6IFBNRUNsay0gRFNJLSBEMSsgRDIrIEF1eEN1
cnJlbnQ9Mzc1bUEgUE1FKEQwKyxEMSssRDIrLEQzaG90KyxEM2NvbGQrKQ0KCQlTdGF0dXM6
IEQwIE5vU29mdFJzdCsgUE1FLUVuYWJsZS0gRFNlbD0wIERTY2FsZT0wIFBNRS0NCglDYXBh
YmlsaXRpZXM6IFs1MF0gTVNJOiBFbmFibGUrIENvdW50PTEvMSBNYXNrYWJsZS0gNjRiaXQr
DQoJCUFkZHJlc3M6IDAwMDAwMDAwZmVlMDEwMGMgIERhdGE6IDQxYjkNCglDYXBhYmlsaXRp
ZXM6IFs3MF0gRXhwcmVzcyAodjIpIEVuZHBvaW50LCBNU0kgMDENCgkJRGV2Q2FwOglNYXhQ
YXlsb2FkIDI1NiBieXRlcywgUGhhbnRGdW5jIDAsIExhdGVuY3kgTDBzIDw1MTJucywgTDEg
PDY0dXMNCgkJCUV4dFRhZy0gQXR0bkJ0bi0gQXR0bkluZC0gUHdySW5kLSBSQkUrIEZMUmVz
ZXQtDQoJCURldkN0bDoJUmVwb3J0IGVycm9yczogQ29ycmVjdGFibGUtIE5vbi1GYXRhbC0g
RmF0YWwtIFVuc3VwcG9ydGVkLQ0KCQkJUmx4ZE9yZC0gRXh0VGFnLSBQaGFudEZ1bmMtIEF1
eFB3ci0gTm9Tbm9vcC0NCgkJCU1heFBheWxvYWQgMTI4IGJ5dGVzLCBNYXhSZWFkUmVxIDQw
OTYgYnl0ZXMNCgkJRGV2U3RhOglDb3JyRXJyKyBVbmNvcnJFcnItIEZhdGFsRXJyLSBVbnN1
cHBSZXErIEF1eFB3cisgVHJhbnNQZW5kLQ0KCQlMbmtDYXA6CVBvcnQgIzAsIFNwZWVkIDIu
NUdUL3MsIFdpZHRoIHgxLCBBU1BNIEwwcyBMMSwgTGF0ZW5jeSBMMCA8NTEybnMsIEwxIDw2
NHVzDQoJCQlDbG9ja1BNKyBTdXJwcmlzZS0gTExBY3RSZXAtIEJ3Tm90LQ0KCQlMbmtDdGw6
CUFTUE0gRGlzYWJsZWQ7IFJDQiA2NCBieXRlcyBEaXNhYmxlZC0gUmV0cmFpbi0gQ29tbUNs
aysNCgkJCUV4dFN5bmNoLSBDbG9ja1BNLSBBdXRXaWREaXMtIEJXSW50LSBBdXRCV0ludC0N
CgkJTG5rU3RhOglTcGVlZCAyLjVHVC9zLCBXaWR0aCB4MSwgVHJFcnItIFRyYWluLSBTbG90
Q2xrKyBETEFjdGl2ZS0gQldNZ210LSBBQldNZ210LQ0KCQlEZXZDYXAyOiBDb21wbGV0aW9u
IFRpbWVvdXQ6IE5vdCBTdXBwb3J0ZWQsIFRpbWVvdXREaXMrDQoJCURldkN0bDI6IENvbXBs
ZXRpb24gVGltZW91dDogNTB1cyB0byA1MG1zLCBUaW1lb3V0RGlzLQ0KCQlMbmtDdGwyOiBU
YXJnZXQgTGluayBTcGVlZDogMi41R1QvcywgRW50ZXJDb21wbGlhbmNlLSBTcGVlZERpcy0s
IFNlbGVjdGFibGUgRGUtZW1waGFzaXM6IC02ZEINCgkJCSBUcmFuc21pdCBNYXJnaW46IE5v
cm1hbCBPcGVyYXRpbmcgUmFuZ2UsIEVudGVyTW9kaWZpZWRDb21wbGlhbmNlLSBDb21wbGlh
bmNlU09TLQ0KCQkJIENvbXBsaWFuY2UgRGUtZW1waGFzaXM6IC02ZEINCgkJTG5rU3RhMjog
Q3VycmVudCBEZS1lbXBoYXNpcyBMZXZlbDogLTZkQg0KCUNhcGFiaWxpdGllczogW2FjXSBN
U0ktWDogRW5hYmxlLSBDb3VudD00IE1hc2tlZC0NCgkJVmVjdG9yIHRhYmxlOiBCQVI9NCBv
ZmZzZXQ9MDAwMDAwMDANCgkJUEJBOiBCQVI9NCBvZmZzZXQ9MDAwMDA4MDANCglDYXBhYmls
aXRpZXM6IFtjY10gVml0YWwgUHJvZHVjdCBEYXRhDQoJCVVua25vd24gc21hbGwgcmVzb3Vy
Y2UgdHlwZSAwMCwgd2lsbCBub3QgZGVjb2RlIG1vcmUuDQoJQ2FwYWJpbGl0aWVzOiBbMTAw
IHYxXSBBZHZhbmNlZCBFcnJvciBSZXBvcnRpbmcNCgkJVUVTdGE6CURMUC0gU0RFUy0gVExQ
LSBGQ1AtIENtcGx0VE8tIENtcGx0QWJydC0gVW54Q21wbHQtIFJ4T0YtIE1hbGZUTFAtIEVD
UkMtIFVuc3VwUmVxLSBBQ1NWaW9sLQ0KCQlVRU1zazoJRExQLSBTREVTLSBUTFAtIEZDUC0g
Q21wbHRUTy0gQ21wbHRBYnJ0LSBVbnhDbXBsdC0gUnhPRi0gTWFsZlRMUC0gRUNSQy0gVW5z
dXBSZXEtIEFDU1Zpb2wtDQoJCVVFU3ZydDoJRExQKyBTREVTKyBUTFAtIEZDUCsgQ21wbHRU
Ty0gQ21wbHRBYnJ0LSBVbnhDbXBsdC0gUnhPRisgTWFsZlRMUCsgRUNSQy0gVW5zdXBSZXEt
IEFDU1Zpb2wtDQoJCUNFU3RhOglSeEVyci0gQmFkVExQLSBCYWRETExQLSBSb2xsb3Zlci0g
VGltZW91dC0gTm9uRmF0YWxFcnIrDQoJCUNFTXNrOglSeEVyci0gQmFkVExQLSBCYWRETExQ
LSBSb2xsb3Zlci0gVGltZW91dC0gTm9uRmF0YWxFcnIrDQoJCUFFUkNhcDoJRmlyc3QgRXJy
b3IgUG9pbnRlcjogMDAsIEdlbkNhcCsgQ0dlbkVuLSBDaGtDYXArIENoa0VuLQ0KCUNhcGFi
aWxpdGllczogWzE0MCB2MV0gVmlydHVhbCBDaGFubmVsDQoJCUNhcHM6CUxQRVZDPTAgUmVm
Q2xrPTEwMG5zIFBBVEVudHJ5Qml0cz0xDQoJCUFyYjoJRml4ZWQtIFdSUjMyLSBXUlI2NC0g
V1JSMTI4LQ0KCQlDdHJsOglBcmJTZWxlY3Q9Rml4ZWQNCgkJU3RhdHVzOglJblByb2dyZXNz
LQ0KCQlWQzA6CUNhcHM6CVBBVE9mZnNldD0wMCBNYXhUaW1lU2xvdHM9MSBSZWpTbm9vcFRy
YW5zLQ0KCQkJQXJiOglGaXhlZC0gV1JSMzItIFdSUjY0LSBXUlIxMjgtIFRXUlIxMjgtIFdS
UjI1Ni0NCgkJCUN0cmw6CUVuYWJsZSsgSUQ9MCBBcmJTZWxlY3Q9Rml4ZWQgVEMvVkM9ZmYN
CgkJCVN0YXR1czoJTmVnb1BlbmRpbmctIEluUHJvZ3Jlc3MtDQoJQ2FwYWJpbGl0aWVzOiBb
MTYwIHYxXSBEZXZpY2UgU2VyaWFsIE51bWJlciAwNC0wMC0wMC0wMC02OC00Yy1lMC0wMA0K
CUtlcm5lbCBkcml2ZXIgaW4gdXNlOiByODE2OQ0KDQowOTowMC4wIFVTQiBjb250cm9sbGVy
IFswYzAzXTogTmV0TW9zIFRlY2hub2xvZ3kgTUNTOTk5MCBQQ0llIHRvIDTigJBQb3J0IFVT
QiAyLjAgSG9zdCBDb250cm9sbGVyIFs5NzEwOjk5OTBdIChwcm9nLWlmIDEwIFtPSENJXSkN
CglTdWJzeXN0ZW06IERldmljZSBbYTAwMDo0MDAwXQ0KCUNvbnRyb2w6IEkvTy0gTWVtLSBC
dXNNYXN0ZXItIFNwZWNDeWNsZS0gTWVtV0lOVi0gVkdBU25vb3AtIFBhckVyci0gU3RlcHBp
bmctIFNFUlItIEZhc3RCMkItIERpc0lOVHgtDQoJU3RhdHVzOiBDYXArIDY2TUh6LSBVREYt
IEZhc3RCMkItIFBhckVyci0gREVWU0VMPWZhc3QgPlRBYm9ydC0gPFRBYm9ydC0gPE1BYm9y
dC0gPlNFUlItIDxQRVJSLSBJTlR4LQ0KCUludGVycnVwdDogcGluIEEgcm91dGVkIHRvIElS
USAyOA0KCVJlZ2lvbiAwOiBNZW1vcnkgYXQgZjlmZjgwMDAgKDMyLWJpdCwgbm9uLXByZWZl
dGNoYWJsZSkgW2Rpc2FibGVkXSBbc2l6ZT00S10NCglDYXBhYmlsaXRpZXM6IFs1MF0gTVNJ
OiBFbmFibGUtIENvdW50PTEvMSBNYXNrYWJsZS0gNjRiaXQrDQoJCUFkZHJlc3M6IDAwMDAw
MDAwMDAwMDAwMDAgIERhdGE6IDAwMDANCglDYXBhYmlsaXRpZXM6IFs3OF0gUG93ZXIgTWFu
YWdlbWVudCB2ZXJzaW9uIDMNCgkJRmxhZ3M6IFBNRUNsay0gRFNJLSBEMSsgRDIrIEF1eEN1
cnJlbnQ9Mzc1bUEgUE1FKEQwKyxEMSssRDIrLEQzaG90KyxEM2NvbGQtKQ0KCQlTdGF0dXM6
IEQwIE5vU29mdFJzdCsgUE1FLUVuYWJsZS0gRFNlbD0wIERTY2FsZT0wIFBNRS0NCglDYXBh
YmlsaXRpZXM6IFs4MF0gRXhwcmVzcyAodjEpIEVuZHBvaW50LCBNU0kgMDANCgkJRGV2Q2Fw
OglNYXhQYXlsb2FkIDI1NiBieXRlcywgUGhhbnRGdW5jIDAsIExhdGVuY3kgTDBzIHVubGlt
aXRlZCwgTDEgdW5saW1pdGVkDQoJCQlFeHRUYWctIEF0dG5CdG4tIEF0dG5JbmQtIFB3cklu
ZC0gUkJFKyBGTFJlc2V0LQ0KCQlEZXZDdGw6CVJlcG9ydCBlcnJvcnM6IENvcnJlY3RhYmxl
LSBOb24tRmF0YWwtIEZhdGFsLSBVbnN1cHBvcnRlZC0NCgkJCVJseGRPcmQtIEV4dFRhZy0g
UGhhbnRGdW5jLSBBdXhQd3ItIE5vU25vb3ArDQoJCQlNYXhQYXlsb2FkIDEyOCBieXRlcywg
TWF4UmVhZFJlcSA1MTIgYnl0ZXMNCgkJRGV2U3RhOglDb3JyRXJyLSBVbmNvcnJFcnItIEZh
dGFsRXJyLSBVbnN1cHBSZXEtIEF1eFB3ci0gVHJhbnNQZW5kLQ0KCQlMbmtDYXA6CVBvcnQg
IzEsIFNwZWVkIDIuNUdUL3MsIFdpZHRoIHgxLCBBU1BNIHVua25vd24sIExhdGVuY3kgTDAg
PDY0bnMsIEwxIHVubGltaXRlZA0KCQkJQ2xvY2tQTSsgU3VycHJpc2UtIExMQWN0UmVwLSBC
d05vdC0NCgkJTG5rQ3RsOglBU1BNIERpc2FibGVkOyBSQ0IgNjQgYnl0ZXMgRGlzYWJsZWQt
IFJldHJhaW4tIENvbW1DbGstDQoJCQlFeHRTeW5jaC0gQ2xvY2tQTS0gQXV0V2lkRGlzLSBC
V0ludC0gQXV0QldJbnQtDQoJCUxua1N0YToJU3BlZWQgMi41R1QvcywgV2lkdGggeDEsIFRy
RXJyLSBUcmFpbi0gU2xvdENsay0gRExBY3RpdmUtIEJXTWdtdC0gQUJXTWdtdC0NCglDYXBh
YmlsaXRpZXM6IFsxMDAgdjFdIFZpcnR1YWwgQ2hhbm5lbA0KCQlDYXBzOglMUEVWQz0wIFJl
ZkNsaz0xMDBucyBQQVRFbnRyeUJpdHM9MQ0KCQlBcmI6CUZpeGVkLSBXUlIzMi0gV1JSNjQt
IFdSUjEyOC0NCgkJQ3RybDoJQXJiU2VsZWN0PUZpeGVkDQoJCVN0YXR1czoJSW5Qcm9ncmVz
cy0NCgkJVkMwOglDYXBzOglQQVRPZmZzZXQ9MDAgTWF4VGltZVNsb3RzPTEgUmVqU25vb3BU
cmFucy0NCgkJCUFyYjoJRml4ZWQtIFdSUjMyLSBXUlI2NC0gV1JSMTI4LSBUV1JSMTI4LSBX
UlIyNTYtDQoJCQlDdHJsOglFbmFibGUrIElEPTAgQXJiU2VsZWN0PUZpeGVkIFRDL1ZDPWZm
DQoJCQlTdGF0dXM6CU5lZ29QZW5kaW5nLSBJblByb2dyZXNzLQ0KCUtlcm5lbCBkcml2ZXIg
aW4gdXNlOiBwY2liYWNrDQoNCjA5OjAwLjEgVVNCIGNvbnRyb2xsZXIgWzBjMDNdOiBOZXRN
b3MgVGVjaG5vbG9neSBNQ1M5OTkwIFBDSWUgdG8gNOKAkFBvcnQgVVNCIDIuMCBIb3N0IENv
bnRyb2xsZXIgWzk3MTA6OTk5MF0gKHByb2ctaWYgMjAgW0VIQ0ldKQ0KCVN1YnN5c3RlbTog
RGV2aWNlIFthMDAwOjQwMDBdDQoJQ29udHJvbDogSS9PLSBNZW0tIEJ1c01hc3Rlci0gU3Bl
Y0N5Y2xlLSBNZW1XSU5WLSBWR0FTbm9vcC0gUGFyRXJyLSBTdGVwcGluZy0gU0VSUi0gRmFz
dEIyQi0gRGlzSU5UeC0NCglTdGF0dXM6IENhcCsgNjZNSHotIFVERi0gRmFzdEIyQi0gUGFy
RXJyLSBERVZTRUw9ZmFzdCA+VEFib3J0LSA8VEFib3J0LSA8TUFib3J0LSA+U0VSUi0gPFBF
UlItIElOVHgtDQoJSW50ZXJydXB0OiBwaW4gQSByb3V0ZWQgdG8gSVJRIDI4DQoJUmVnaW9u
IDA6IE1lbW9yeSBhdCBmOWZmOTAwMCAoMzItYml0LCBub24tcHJlZmV0Y2hhYmxlKSBbZGlz
YWJsZWRdIFtzaXplPTRLXQ0KCUNhcGFiaWxpdGllczogWzUwXSBNU0k6IEVuYWJsZS0gQ291
bnQ9MS8xIE1hc2thYmxlLSA2NGJpdCsNCgkJQWRkcmVzczogMDAwMDAwMDAwMDAwMDAwMCAg
RGF0YTogMDAwMA0KCUNhcGFiaWxpdGllczogWzc4XSBQb3dlciBNYW5hZ2VtZW50IHZlcnNp
b24gMw0KCQlGbGFnczogUE1FQ2xrLSBEU0ktIEQxKyBEMisgQXV4Q3VycmVudD0zNzVtQSBQ
TUUoRDArLEQxKyxEMissRDNob3QrLEQzY29sZC0pDQoJCVN0YXR1czogRDAgTm9Tb2Z0UnN0
KyBQTUUtRW5hYmxlLSBEU2VsPTAgRFNjYWxlPTAgUE1FLQ0KCUNhcGFiaWxpdGllczogWzgw
XSBFeHByZXNzICh2MSkgRW5kcG9pbnQsIE1TSSAwMA0KCQlEZXZDYXA6CU1heFBheWxvYWQg
MjU2IGJ5dGVzLCBQaGFudEZ1bmMgMCwgTGF0ZW5jeSBMMHMgdW5saW1pdGVkLCBMMSB1bmxp
bWl0ZWQNCgkJCUV4dFRhZy0gQXR0bkJ0bi0gQXR0bkluZC0gUHdySW5kLSBSQkUrIEZMUmVz
ZXQtDQoJCURldkN0bDoJUmVwb3J0IGVycm9yczogQ29ycmVjdGFibGUtIE5vbi1GYXRhbC0g
RmF0YWwtIFVuc3VwcG9ydGVkLQ0KCQkJUmx4ZE9yZC0gRXh0VGFnLSBQaGFudEZ1bmMtIEF1
eFB3ci0gTm9Tbm9vcCsNCgkJCU1heFBheWxvYWQgMTI4IGJ5dGVzLCBNYXhSZWFkUmVxIDUx
MiBieXRlcw0KCQlEZXZTdGE6CUNvcnJFcnItIFVuY29yckVyci0gRmF0YWxFcnItIFVuc3Vw
cFJlcS0gQXV4UHdyLSBUcmFuc1BlbmQtDQoJCUxua0NhcDoJUG9ydCAjMSwgU3BlZWQgMi41
R1QvcywgV2lkdGggeDEsIEFTUE0gdW5rbm93biwgTGF0ZW5jeSBMMCA8NjRucywgTDEgdW5s
aW1pdGVkDQoJCQlDbG9ja1BNKyBTdXJwcmlzZS0gTExBY3RSZXAtIEJ3Tm90LQ0KCQlMbmtD
dGw6CUFTUE0gRGlzYWJsZWQ7IFJDQiA2NCBieXRlcyBEaXNhYmxlZC0gUmV0cmFpbi0gQ29t
bUNsay0NCgkJCUV4dFN5bmNoLSBDbG9ja1BNLSBBdXRXaWREaXMtIEJXSW50LSBBdXRCV0lu
dC0NCgkJTG5rU3RhOglTcGVlZCAyLjVHVC9zLCBXaWR0aCB4MSwgVHJFcnItIFRyYWluLSBT
bG90Q2xrLSBETEFjdGl2ZS0gQldNZ210LSBBQldNZ210LQ0KCUtlcm5lbCBkcml2ZXIgaW4g
dXNlOiBwY2liYWNrDQoNCjA5OjAwLjIgVVNCIGNvbnRyb2xsZXIgWzBjMDNdOiBOZXRNb3Mg
VGVjaG5vbG9neSBNQ1M5OTkwIFBDSWUgdG8gNOKAkFBvcnQgVVNCIDIuMCBIb3N0IENvbnRy
b2xsZXIgWzk3MTA6OTk5MF0gKHByb2ctaWYgMTAgW09IQ0ldKQ0KCVN1YnN5c3RlbTogRGV2
aWNlIFthMDAwOjQwMDBdDQoJQ29udHJvbDogSS9PLSBNZW0tIEJ1c01hc3Rlci0gU3BlY0N5
Y2xlLSBNZW1XSU5WLSBWR0FTbm9vcC0gUGFyRXJyLSBTdGVwcGluZy0gU0VSUi0gRmFzdEIy
Qi0gRGlzSU5UeC0NCglTdGF0dXM6IENhcCsgNjZNSHotIFVERi0gRmFzdEIyQi0gUGFyRXJy
LSBERVZTRUw9ZmFzdCA+VEFib3J0LSA8VEFib3J0LSA8TUFib3J0LSA+U0VSUi0gPFBFUlIt
IElOVHgtDQoJSW50ZXJydXB0OiBwaW4gQiByb3V0ZWQgdG8gSVJRIDI5DQoJUmVnaW9uIDA6
IE1lbW9yeSBhdCBmOWZmYTAwMCAoMzItYml0LCBub24tcHJlZmV0Y2hhYmxlKSBbZGlzYWJs
ZWRdIFtzaXplPTRLXQ0KCUNhcGFiaWxpdGllczogWzUwXSBNU0k6IEVuYWJsZS0gQ291bnQ9
MS8xIE1hc2thYmxlLSA2NGJpdCsNCgkJQWRkcmVzczogMDAwMDAwMDAwMDAwMDAwMCAgRGF0
YTogMDAwMA0KCUNhcGFiaWxpdGllczogWzc4XSBQb3dlciBNYW5hZ2VtZW50IHZlcnNpb24g
Mw0KCQlGbGFnczogUE1FQ2xrLSBEU0ktIEQxKyBEMisgQXV4Q3VycmVudD0zNzVtQSBQTUUo
RDArLEQxKyxEMissRDNob3QrLEQzY29sZC0pDQoJCVN0YXR1czogRDAgTm9Tb2Z0UnN0KyBQ
TUUtRW5hYmxlLSBEU2VsPTAgRFNjYWxlPTAgUE1FLQ0KCUNhcGFiaWxpdGllczogWzgwXSBF
eHByZXNzICh2MSkgRW5kcG9pbnQsIE1TSSAwMA0KCQlEZXZDYXA6CU1heFBheWxvYWQgMjU2
IGJ5dGVzLCBQaGFudEZ1bmMgMCwgTGF0ZW5jeSBMMHMgdW5saW1pdGVkLCBMMSB1bmxpbWl0
ZWQNCgkJCUV4dFRhZy0gQXR0bkJ0bi0gQXR0bkluZC0gUHdySW5kLSBSQkUrIEZMUmVzZXQt
DQoJCURldkN0bDoJUmVwb3J0IGVycm9yczogQ29ycmVjdGFibGUtIE5vbi1GYXRhbC0gRmF0
YWwtIFVuc3VwcG9ydGVkLQ0KCQkJUmx4ZE9yZC0gRXh0VGFnLSBQaGFudEZ1bmMtIEF1eFB3
ci0gTm9Tbm9vcCsNCgkJCU1heFBheWxvYWQgMTI4IGJ5dGVzLCBNYXhSZWFkUmVxIDUxMiBi
eXRlcw0KCQlEZXZTdGE6CUNvcnJFcnItIFVuY29yckVyci0gRmF0YWxFcnItIFVuc3VwcFJl
cS0gQXV4UHdyLSBUcmFuc1BlbmQtDQoJCUxua0NhcDoJUG9ydCAjMSwgU3BlZWQgMi41R1Qv
cywgV2lkdGggeDEsIEFTUE0gdW5rbm93biwgTGF0ZW5jeSBMMCA8NjRucywgTDEgdW5saW1p
dGVkDQoJCQlDbG9ja1BNKyBTdXJwcmlzZS0gTExBY3RSZXAtIEJ3Tm90LQ0KCQlMbmtDdGw6
CUFTUE0gRGlzYWJsZWQ7IFJDQiA2NCBieXRlcyBEaXNhYmxlZC0gUmV0cmFpbi0gQ29tbUNs
ay0NCgkJCUV4dFN5bmNoLSBDbG9ja1BNLSBBdXRXaWREaXMtIEJXSW50LSBBdXRCV0ludC0N
CgkJTG5rU3RhOglTcGVlZCAyLjVHVC9zLCBXaWR0aCB4MSwgVHJFcnItIFRyYWluLSBTbG90
Q2xrLSBETEFjdGl2ZS0gQldNZ210LSBBQldNZ210LQ0KCUtlcm5lbCBkcml2ZXIgaW4gdXNl
OiBwY2liYWNrDQoNCjA5OjAwLjMgVVNCIGNvbnRyb2xsZXIgWzBjMDNdOiBOZXRNb3MgVGVj
aG5vbG9neSBNQ1M5OTkwIFBDSWUgdG8gNOKAkFBvcnQgVVNCIDIuMCBIb3N0IENvbnRyb2xs
ZXIgWzk3MTA6OTk5MF0gKHByb2ctaWYgMjAgW0VIQ0ldKQ0KCVN1YnN5c3RlbTogRGV2aWNl
IFthMDAwOjQwMDBdDQoJQ29udHJvbDogSS9PLSBNZW0tIEJ1c01hc3Rlci0gU3BlY0N5Y2xl
LSBNZW1XSU5WLSBWR0FTbm9vcC0gUGFyRXJyLSBTdGVwcGluZy0gU0VSUi0gRmFzdEIyQi0g
RGlzSU5UeC0NCglTdGF0dXM6IENhcCsgNjZNSHotIFVERi0gRmFzdEIyQi0gUGFyRXJyLSBE
RVZTRUw9ZmFzdCA+VEFib3J0LSA8VEFib3J0LSA8TUFib3J0LSA+U0VSUi0gPFBFUlItIElO
VHgtDQoJSW50ZXJydXB0OiBwaW4gQiByb3V0ZWQgdG8gSVJRIDI5DQoJUmVnaW9uIDA6IE1l
bW9yeSBhdCBmOWZmYjAwMCAoMzItYml0LCBub24tcHJlZmV0Y2hhYmxlKSBbZGlzYWJsZWRd
IFtzaXplPTRLXQ0KCUNhcGFiaWxpdGllczogWzUwXSBNU0k6IEVuYWJsZS0gQ291bnQ9MS8x
IE1hc2thYmxlLSA2NGJpdCsNCgkJQWRkcmVzczogMDAwMDAwMDAwMDAwMDAwMCAgRGF0YTog
MDAwMA0KCUNhcGFiaWxpdGllczogWzc4XSBQb3dlciBNYW5hZ2VtZW50IHZlcnNpb24gMw0K
CQlGbGFnczogUE1FQ2xrLSBEU0ktIEQxKyBEMisgQXV4Q3VycmVudD0zNzVtQSBQTUUoRDAr
LEQxKyxEMissRDNob3QrLEQzY29sZC0pDQoJCVN0YXR1czogRDAgTm9Tb2Z0UnN0KyBQTUUt
RW5hYmxlLSBEU2VsPTAgRFNjYWxlPTAgUE1FLQ0KCUNhcGFiaWxpdGllczogWzgwXSBFeHBy
ZXNzICh2MSkgRW5kcG9pbnQsIE1TSSAwMA0KCQlEZXZDYXA6CU1heFBheWxvYWQgMjU2IGJ5
dGVzLCBQaGFudEZ1bmMgMCwgTGF0ZW5jeSBMMHMgdW5saW1pdGVkLCBMMSB1bmxpbWl0ZWQN
CgkJCUV4dFRhZy0gQXR0bkJ0bi0gQXR0bkluZC0gUHdySW5kLSBSQkUrIEZMUmVzZXQtDQoJ
CURldkN0bDoJUmVwb3J0IGVycm9yczogQ29ycmVjdGFibGUtIE5vbi1GYXRhbC0gRmF0YWwt
IFVuc3VwcG9ydGVkLQ0KCQkJUmx4ZE9yZC0gRXh0VGFnLSBQaGFudEZ1bmMtIEF1eFB3ci0g
Tm9Tbm9vcCsNCgkJCU1heFBheWxvYWQgMTI4IGJ5dGVzLCBNYXhSZWFkUmVxIDUxMiBieXRl
cw0KCQlEZXZTdGE6CUNvcnJFcnItIFVuY29yckVyci0gRmF0YWxFcnItIFVuc3VwcFJlcS0g
QXV4UHdyLSBUcmFuc1BlbmQtDQoJCUxua0NhcDoJUG9ydCAjMSwgU3BlZWQgMi41R1Qvcywg
V2lkdGggeDEsIEFTUE0gdW5rbm93biwgTGF0ZW5jeSBMMCA8NjRucywgTDEgdW5saW1pdGVk
DQoJCQlDbG9ja1BNKyBTdXJwcmlzZS0gTExBY3RSZXAtIEJ3Tm90LQ0KCQlMbmtDdGw6CUFT
UE0gRGlzYWJsZWQ7IFJDQiA2NCBieXRlcyBEaXNhYmxlZC0gUmV0cmFpbi0gQ29tbUNsay0N
CgkJCUV4dFN5bmNoLSBDbG9ja1BNLSBBdXRXaWREaXMtIEJXSW50LSBBdXRCV0ludC0NCgkJ
TG5rU3RhOglTcGVlZCAyLjVHVC9zLCBXaWR0aCB4MSwgVHJFcnItIFRyYWluLSBTbG90Q2xr
LSBETEFjdGl2ZS0gQldNZ210LSBBQldNZ210LQ0KCUtlcm5lbCBkcml2ZXIgaW4gdXNlOiBw
Y2liYWNrDQoNCjA5OjAwLjQgVVNCIGNvbnRyb2xsZXIgWzBjMDNdOiBOZXRNb3MgVGVjaG5v
bG9neSBNQ1M5OTkwIFBDSWUgdG8gNOKAkFBvcnQgVVNCIDIuMCBIb3N0IENvbnRyb2xsZXIg
Wzk3MTA6OTk5MF0gKHByb2ctaWYgMTAgW09IQ0ldKQ0KCVN1YnN5c3RlbTogRGV2aWNlIFth
MDAwOjQwMDBdDQoJQ29udHJvbDogSS9PLSBNZW0tIEJ1c01hc3Rlci0gU3BlY0N5Y2xlLSBN
ZW1XSU5WLSBWR0FTbm9vcC0gUGFyRXJyLSBTdGVwcGluZy0gU0VSUi0gRmFzdEIyQi0gRGlz
SU5UeC0NCglTdGF0dXM6IENhcCsgNjZNSHotIFVERi0gRmFzdEIyQi0gUGFyRXJyLSBERVZT
RUw9ZmFzdCA+VEFib3J0LSA8VEFib3J0LSA8TUFib3J0LSA+U0VSUi0gPFBFUlItIElOVHgt
DQoJSW50ZXJydXB0OiBwaW4gQyByb3V0ZWQgdG8gSVJRIDMwDQoJUmVnaW9uIDA6IE1lbW9y
eSBhdCBmOWZmYzAwMCAoMzItYml0LCBub24tcHJlZmV0Y2hhYmxlKSBbZGlzYWJsZWRdIFtz
aXplPTRLXQ0KCUNhcGFiaWxpdGllczogWzUwXSBNU0k6IEVuYWJsZS0gQ291bnQ9MS8xIE1h
c2thYmxlLSA2NGJpdCsNCgkJQWRkcmVzczogMDAwMDAwMDAwMDAwMDAwMCAgRGF0YTogMDAw
MA0KCUNhcGFiaWxpdGllczogWzc4XSBQb3dlciBNYW5hZ2VtZW50IHZlcnNpb24gMw0KCQlG
bGFnczogUE1FQ2xrLSBEU0ktIEQxKyBEMisgQXV4Q3VycmVudD0zNzVtQSBQTUUoRDArLEQx
KyxEMissRDNob3QrLEQzY29sZC0pDQoJCVN0YXR1czogRDAgTm9Tb2Z0UnN0KyBQTUUtRW5h
YmxlLSBEU2VsPTAgRFNjYWxlPTAgUE1FLQ0KCUNhcGFiaWxpdGllczogWzgwXSBFeHByZXNz
ICh2MSkgRW5kcG9pbnQsIE1TSSAwMA0KCQlEZXZDYXA6CU1heFBheWxvYWQgMjU2IGJ5dGVz
LCBQaGFudEZ1bmMgMCwgTGF0ZW5jeSBMMHMgdW5saW1pdGVkLCBMMSB1bmxpbWl0ZWQNCgkJ
CUV4dFRhZy0gQXR0bkJ0bi0gQXR0bkluZC0gUHdySW5kLSBSQkUrIEZMUmVzZXQtDQoJCURl
dkN0bDoJUmVwb3J0IGVycm9yczogQ29ycmVjdGFibGUtIE5vbi1GYXRhbC0gRmF0YWwtIFVu
c3VwcG9ydGVkLQ0KCQkJUmx4ZE9yZC0gRXh0VGFnLSBQaGFudEZ1bmMtIEF1eFB3ci0gTm9T
bm9vcCsNCgkJCU1heFBheWxvYWQgMTI4IGJ5dGVzLCBNYXhSZWFkUmVxIDUxMiBieXRlcw0K
CQlEZXZTdGE6CUNvcnJFcnItIFVuY29yckVyci0gRmF0YWxFcnItIFVuc3VwcFJlcS0gQXV4
UHdyLSBUcmFuc1BlbmQtDQoJCUxua0NhcDoJUG9ydCAjMSwgU3BlZWQgMi41R1QvcywgV2lk
dGggeDEsIEFTUE0gdW5rbm93biwgTGF0ZW5jeSBMMCA8NjRucywgTDEgdW5saW1pdGVkDQoJ
CQlDbG9ja1BNKyBTdXJwcmlzZS0gTExBY3RSZXAtIEJ3Tm90LQ0KCQlMbmtDdGw6CUFTUE0g
RGlzYWJsZWQ7IFJDQiA2NCBieXRlcyBEaXNhYmxlZC0gUmV0cmFpbi0gQ29tbUNsay0NCgkJ
CUV4dFN5bmNoLSBDbG9ja1BNLSBBdXRXaWREaXMtIEJXSW50LSBBdXRCV0ludC0NCgkJTG5r
U3RhOglTcGVlZCAyLjVHVC9zLCBXaWR0aCB4MSwgVHJFcnItIFRyYWluLSBTbG90Q2xrLSBE
TEFjdGl2ZS0gQldNZ210LSBBQldNZ210LQ0KCUtlcm5lbCBkcml2ZXIgaW4gdXNlOiBwY2li
YWNrDQoNCjA5OjAwLjUgVVNCIGNvbnRyb2xsZXIgWzBjMDNdOiBOZXRNb3MgVGVjaG5vbG9n
eSBNQ1M5OTkwIFBDSWUgdG8gNOKAkFBvcnQgVVNCIDIuMCBIb3N0IENvbnRyb2xsZXIgWzk3
MTA6OTk5MF0gKHByb2ctaWYgMjAgW0VIQ0ldKQ0KCVN1YnN5c3RlbTogRGV2aWNlIFthMDAw
OjQwMDBdDQoJQ29udHJvbDogSS9PLSBNZW0tIEJ1c01hc3Rlci0gU3BlY0N5Y2xlLSBNZW1X
SU5WLSBWR0FTbm9vcC0gUGFyRXJyLSBTdGVwcGluZy0gU0VSUi0gRmFzdEIyQi0gRGlzSU5U
eC0NCglTdGF0dXM6IENhcCsgNjZNSHotIFVERi0gRmFzdEIyQi0gUGFyRXJyLSBERVZTRUw9
ZmFzdCA+VEFib3J0LSA8VEFib3J0LSA8TUFib3J0LSA+U0VSUi0gPFBFUlItIElOVHgtDQoJ
SW50ZXJydXB0OiBwaW4gQyByb3V0ZWQgdG8gSVJRIDMwDQoJUmVnaW9uIDA6IE1lbW9yeSBh
dCBmOWZmZDAwMCAoMzItYml0LCBub24tcHJlZmV0Y2hhYmxlKSBbZGlzYWJsZWRdIFtzaXpl
PTRLXQ0KCUNhcGFiaWxpdGllczogWzUwXSBNU0k6IEVuYWJsZS0gQ291bnQ9MS8xIE1hc2th
YmxlLSA2NGJpdCsNCgkJQWRkcmVzczogMDAwMDAwMDAwMDAwMDAwMCAgRGF0YTogMDAwMA0K
CUNhcGFiaWxpdGllczogWzc4XSBQb3dlciBNYW5hZ2VtZW50IHZlcnNpb24gMw0KCQlGbGFn
czogUE1FQ2xrLSBEU0ktIEQxKyBEMisgQXV4Q3VycmVudD0zNzVtQSBQTUUoRDArLEQxKyxE
MissRDNob3QrLEQzY29sZC0pDQoJCVN0YXR1czogRDAgTm9Tb2Z0UnN0KyBQTUUtRW5hYmxl
LSBEU2VsPTAgRFNjYWxlPTAgUE1FLQ0KCUNhcGFiaWxpdGllczogWzgwXSBFeHByZXNzICh2
MSkgRW5kcG9pbnQsIE1TSSAwMA0KCQlEZXZDYXA6CU1heFBheWxvYWQgMjU2IGJ5dGVzLCBQ
aGFudEZ1bmMgMCwgTGF0ZW5jeSBMMHMgdW5saW1pdGVkLCBMMSB1bmxpbWl0ZWQNCgkJCUV4
dFRhZy0gQXR0bkJ0bi0gQXR0bkluZC0gUHdySW5kLSBSQkUrIEZMUmVzZXQtDQoJCURldkN0
bDoJUmVwb3J0IGVycm9yczogQ29ycmVjdGFibGUtIE5vbi1GYXRhbC0gRmF0YWwtIFVuc3Vw
cG9ydGVkLQ0KCQkJUmx4ZE9yZC0gRXh0VGFnLSBQaGFudEZ1bmMtIEF1eFB3ci0gTm9Tbm9v
cCsNCgkJCU1heFBheWxvYWQgMTI4IGJ5dGVzLCBNYXhSZWFkUmVxIDUxMiBieXRlcw0KCQlE
ZXZTdGE6CUNvcnJFcnItIFVuY29yckVyci0gRmF0YWxFcnItIFVuc3VwcFJlcS0gQXV4UHdy
LSBUcmFuc1BlbmQtDQoJCUxua0NhcDoJUG9ydCAjMSwgU3BlZWQgMi41R1QvcywgV2lkdGgg
eDEsIEFTUE0gdW5rbm93biwgTGF0ZW5jeSBMMCA8NjRucywgTDEgdW5saW1pdGVkDQoJCQlD
bG9ja1BNKyBTdXJwcmlzZS0gTExBY3RSZXAtIEJ3Tm90LQ0KCQlMbmtDdGw6CUFTUE0gRGlz
YWJsZWQ7IFJDQiA2NCBieXRlcyBEaXNhYmxlZC0gUmV0cmFpbi0gQ29tbUNsay0NCgkJCUV4
dFN5bmNoLSBDbG9ja1BNLSBBdXRXaWREaXMtIEJXSW50LSBBdXRCV0ludC0NCgkJTG5rU3Rh
OglTcGVlZCAyLjVHVC9zLCBXaWR0aCB4MSwgVHJFcnItIFRyYWluLSBTbG90Q2xrLSBETEFj
dGl2ZS0gQldNZ210LSBBQldNZ210LQ0KCUtlcm5lbCBkcml2ZXIgaW4gdXNlOiBwY2liYWNr
DQoNCjA5OjAwLjYgVVNCIGNvbnRyb2xsZXIgWzBjMDNdOiBOZXRNb3MgVGVjaG5vbG9neSBN
Q1M5OTkwIFBDSWUgdG8gNOKAkFBvcnQgVVNCIDIuMCBIb3N0IENvbnRyb2xsZXIgWzk3MTA6
OTk5MF0gKHByb2ctaWYgMTAgW09IQ0ldKQ0KCVN1YnN5c3RlbTogRGV2aWNlIFthMDAwOjQw
MDBdDQoJQ29udHJvbDogSS9PLSBNZW0tIEJ1c01hc3Rlci0gU3BlY0N5Y2xlLSBNZW1XSU5W
LSBWR0FTbm9vcC0gUGFyRXJyLSBTdGVwcGluZy0gU0VSUi0gRmFzdEIyQi0gRGlzSU5UeC0N
CglTdGF0dXM6IENhcCsgNjZNSHotIFVERi0gRmFzdEIyQi0gUGFyRXJyLSBERVZTRUw9ZmFz
dCA+VEFib3J0LSA8VEFib3J0LSA8TUFib3J0LSA+U0VSUi0gPFBFUlItIElOVHgtDQoJSW50
ZXJydXB0OiBwaW4gRCByb3V0ZWQgdG8gSVJRIDMxDQoJUmVnaW9uIDA6IE1lbW9yeSBhdCBm
OWZmZTAwMCAoMzItYml0LCBub24tcHJlZmV0Y2hhYmxlKSBbZGlzYWJsZWRdIFtzaXplPTRL
XQ0KCUNhcGFiaWxpdGllczogWzUwXSBNU0k6IEVuYWJsZS0gQ291bnQ9MS8xIE1hc2thYmxl
LSA2NGJpdCsNCgkJQWRkcmVzczogMDAwMDAwMDAwMDAwMDAwMCAgRGF0YTogMDAwMA0KCUNh
cGFiaWxpdGllczogWzc4XSBQb3dlciBNYW5hZ2VtZW50IHZlcnNpb24gMw0KCQlGbGFnczog
UE1FQ2xrLSBEU0ktIEQxKyBEMisgQXV4Q3VycmVudD0zNzVtQSBQTUUoRDArLEQxKyxEMiss
RDNob3QrLEQzY29sZC0pDQoJCVN0YXR1czogRDAgTm9Tb2Z0UnN0KyBQTUUtRW5hYmxlLSBE
U2VsPTAgRFNjYWxlPTAgUE1FLQ0KCUNhcGFiaWxpdGllczogWzgwXSBFeHByZXNzICh2MSkg
RW5kcG9pbnQsIE1TSSAwMA0KCQlEZXZDYXA6CU1heFBheWxvYWQgMjU2IGJ5dGVzLCBQaGFu
dEZ1bmMgMCwgTGF0ZW5jeSBMMHMgdW5saW1pdGVkLCBMMSB1bmxpbWl0ZWQNCgkJCUV4dFRh
Zy0gQXR0bkJ0bi0gQXR0bkluZC0gUHdySW5kLSBSQkUrIEZMUmVzZXQtDQoJCURldkN0bDoJ
UmVwb3J0IGVycm9yczogQ29ycmVjdGFibGUtIE5vbi1GYXRhbC0gRmF0YWwtIFVuc3VwcG9y
dGVkLQ0KCQkJUmx4ZE9yZC0gRXh0VGFnLSBQaGFudEZ1bmMtIEF1eFB3ci0gTm9Tbm9vcCsN
CgkJCU1heFBheWxvYWQgMTI4IGJ5dGVzLCBNYXhSZWFkUmVxIDUxMiBieXRlcw0KCQlEZXZT
dGE6CUNvcnJFcnItIFVuY29yckVyci0gRmF0YWxFcnItIFVuc3VwcFJlcS0gQXV4UHdyLSBU
cmFuc1BlbmQtDQoJCUxua0NhcDoJUG9ydCAjMSwgU3BlZWQgMi41R1QvcywgV2lkdGggeDEs
IEFTUE0gdW5rbm93biwgTGF0ZW5jeSBMMCA8NjRucywgTDEgdW5saW1pdGVkDQoJCQlDbG9j
a1BNKyBTdXJwcmlzZS0gTExBY3RSZXAtIEJ3Tm90LQ0KCQlMbmtDdGw6CUFTUE0gRGlzYWJs
ZWQ7IFJDQiA2NCBieXRlcyBEaXNhYmxlZC0gUmV0cmFpbi0gQ29tbUNsay0NCgkJCUV4dFN5
bmNoLSBDbG9ja1BNLSBBdXRXaWREaXMtIEJXSW50LSBBdXRCV0ludC0NCgkJTG5rU3RhOglT
cGVlZCAyLjVHVC9zLCBXaWR0aCB4MSwgVHJFcnItIFRyYWluLSBTbG90Q2xrLSBETEFjdGl2
ZS0gQldNZ210LSBBQldNZ210LQ0KCUtlcm5lbCBkcml2ZXIgaW4gdXNlOiBwY2liYWNrDQoN
CjA5OjAwLjcgVVNCIGNvbnRyb2xsZXIgWzBjMDNdOiBOZXRNb3MgVGVjaG5vbG9neSBNQ1M5
OTkwIFBDSWUgdG8gNOKAkFBvcnQgVVNCIDIuMCBIb3N0IENvbnRyb2xsZXIgWzk3MTA6OTk5
MF0gKHByb2ctaWYgMjAgW0VIQ0ldKQ0KCVN1YnN5c3RlbTogRGV2aWNlIFthMDAwOjQwMDBd
DQoJQ29udHJvbDogSS9PLSBNZW0tIEJ1c01hc3Rlci0gU3BlY0N5Y2xlLSBNZW1XSU5WLSBW
R0FTbm9vcC0gUGFyRXJyLSBTdGVwcGluZy0gU0VSUi0gRmFzdEIyQi0gRGlzSU5UeC0NCglT
dGF0dXM6IENhcCsgNjZNSHotIFVERi0gRmFzdEIyQi0gUGFyRXJyLSBERVZTRUw9ZmFzdCA+
VEFib3J0LSA8VEFib3J0LSA8TUFib3J0LSA+U0VSUi0gPFBFUlItIElOVHgtDQoJSW50ZXJy
dXB0OiBwaW4gRCByb3V0ZWQgdG8gSVJRIDMxDQoJUmVnaW9uIDA6IE1lbW9yeSBhdCBmOWZm
ZjAwMCAoMzItYml0LCBub24tcHJlZmV0Y2hhYmxlKSBbZGlzYWJsZWRdIFtzaXplPTRLXQ0K
CUNhcGFiaWxpdGllczogWzUwXSBNU0k6IEVuYWJsZS0gQ291bnQ9MS8xIE1hc2thYmxlLSA2
NGJpdCsNCgkJQWRkcmVzczogMDAwMDAwMDAwMDAwMDAwMCAgRGF0YTogMDAwMA0KCUNhcGFi
aWxpdGllczogWzc4XSBQb3dlciBNYW5hZ2VtZW50IHZlcnNpb24gMw0KCQlGbGFnczogUE1F
Q2xrLSBEU0ktIEQxKyBEMisgQXV4Q3VycmVudD0zNzVtQSBQTUUoRDArLEQxKyxEMissRDNo
b3QrLEQzY29sZC0pDQoJCVN0YXR1czogRDAgTm9Tb2Z0UnN0KyBQTUUtRW5hYmxlLSBEU2Vs
PTAgRFNjYWxlPTAgUE1FLQ0KCUNhcGFiaWxpdGllczogWzgwXSBFeHByZXNzICh2MSkgRW5k
cG9pbnQsIE1TSSAwMA0KCQlEZXZDYXA6CU1heFBheWxvYWQgMjU2IGJ5dGVzLCBQaGFudEZ1
bmMgMCwgTGF0ZW5jeSBMMHMgdW5saW1pdGVkLCBMMSB1bmxpbWl0ZWQNCgkJCUV4dFRhZy0g
QXR0bkJ0bi0gQXR0bkluZC0gUHdySW5kLSBSQkUrIEZMUmVzZXQtDQoJCURldkN0bDoJUmVw
b3J0IGVycm9yczogQ29ycmVjdGFibGUtIE5vbi1GYXRhbC0gRmF0YWwtIFVuc3VwcG9ydGVk
LQ0KCQkJUmx4ZE9yZC0gRXh0VGFnLSBQaGFudEZ1bmMtIEF1eFB3ci0gTm9Tbm9vcCsNCgkJ
CU1heFBheWxvYWQgMTI4IGJ5dGVzLCBNYXhSZWFkUmVxIDUxMiBieXRlcw0KCQlEZXZTdGE6
CUNvcnJFcnItIFVuY29yckVyci0gRmF0YWxFcnItIFVuc3VwcFJlcS0gQXV4UHdyLSBUcmFu
c1BlbmQtDQoJCUxua0NhcDoJUG9ydCAjMSwgU3BlZWQgMi41R1QvcywgV2lkdGggeDEsIEFT
UE0gdW5rbm93biwgTGF0ZW5jeSBMMCA8NjRucywgTDEgdW5saW1pdGVkDQoJCQlDbG9ja1BN
KyBTdXJwcmlzZS0gTExBY3RSZXAtIEJ3Tm90LQ0KCQlMbmtDdGw6CUFTUE0gRGlzYWJsZWQ7
IFJDQiA2NCBieXRlcyBEaXNhYmxlZC0gUmV0cmFpbi0gQ29tbUNsay0NCgkJCUV4dFN5bmNo
LSBDbG9ja1BNLSBBdXRXaWREaXMtIEJXSW50LSBBdXRCV0ludC0NCgkJTG5rU3RhOglTcGVl
ZCAyLjVHVC9zLCBXaWR0aCB4MSwgVHJFcnItIFRyYWluLSBTbG90Q2xrLSBETEFjdGl2ZS0g
QldNZ210LSBBQldNZ210LQ0KCUtlcm5lbCBkcml2ZXIgaW4gdXNlOiBwY2liYWNrDQoNCjBh
OjAwLjAgVkdBIGNvbXBhdGlibGUgY29udHJvbGxlciBbMDMwMF06IG5WaWRpYSBDb3Jwb3Jh
dGlvbiBHOTggW0dlRm9yY2UgODQwMCBHU10gWzEwZGU6MDZlNF0gKHJldiBhMSkgKHByb2ct
aWYgMDAgW1ZHQSBjb250cm9sbGVyXSkNCglTdWJzeXN0ZW06IEFTVVNUZUsgQ29tcHV0ZXIg
SW5jLiBEZXZpY2UgWzEwNDM6ODI2Nl0NCglDb250cm9sOiBJL08rIE1lbSsgQnVzTWFzdGVy
KyBTcGVjQ3ljbGUtIE1lbVdJTlYtIFZHQVNub29wLSBQYXJFcnItIFN0ZXBwaW5nLSBTRVJS
KyBGYXN0QjJCLSBEaXNJTlR4LQ0KCVN0YXR1czogQ2FwKyA2Nk1Iei0gVURGLSBGYXN0QjJC
LSBQYXJFcnItIERFVlNFTD1mYXN0ID5UQWJvcnQtIDxUQWJvcnQtIDxNQWJvcnQtID5TRVJS
LSA8UEVSUi0gSU5UeC0NCglMYXRlbmN5OiAwLCBDYWNoZSBMaW5lIFNpemU6IDY0IGJ5dGVz
DQoJSW50ZXJydXB0OiBwaW4gQSByb3V0ZWQgdG8gSVJRIDEwDQoJUmVnaW9uIDA6IE1lbW9y
eSBhdCBmZDAwMDAwMCAoMzItYml0LCBub24tcHJlZmV0Y2hhYmxlKSBbc2l6ZT0xNk1dDQoJ
UmVnaW9uIDE6IE1lbW9yeSBhdCBkMDAwMDAwMCAoNjQtYml0LCBwcmVmZXRjaGFibGUpIFtz
aXplPTI1Nk1dDQoJUmVnaW9uIDM6IE1lbW9yeSBhdCBmYTAwMDAwMCAoNjQtYml0LCBub24t
cHJlZmV0Y2hhYmxlKSBbc2l6ZT0zMk1dDQoJUmVnaW9uIDU6IEkvTyBwb3J0cyBhdCBlODAw
IFtzaXplPTEyOF0NCglFeHBhbnNpb24gUk9NIGF0IGZlOWUwMDAwIFtkaXNhYmxlZF0gW3Np
emU9MTI4S10NCglDYXBhYmlsaXRpZXM6IFs2MF0gUG93ZXIgTWFuYWdlbWVudCB2ZXJzaW9u
IDMNCgkJRmxhZ3M6IFBNRUNsay0gRFNJLSBEMS0gRDItIEF1eEN1cnJlbnQ9MG1BIFBNRShE
MC0sRDEtLEQyLSxEM2hvdC0sRDNjb2xkLSkNCgkJU3RhdHVzOiBEMCBOb1NvZnRSc3QrIFBN
RS1FbmFibGUtIERTZWw9MCBEU2NhbGU9MCBQTUUtDQoJQ2FwYWJpbGl0aWVzOiBbNjhdIE1T
STogRW5hYmxlLSBDb3VudD0xLzEgTWFza2FibGUtIDY0Yml0Kw0KCQlBZGRyZXNzOiAwMDAw
MDAwMDAwMDAwMDAwICBEYXRhOiAwMDAwDQoJQ2FwYWJpbGl0aWVzOiBbNzhdIEV4cHJlc3Mg
KHYxKSBFbmRwb2ludCwgTVNJIDAwDQoJCURldkNhcDoJTWF4UGF5bG9hZCAxMjggYnl0ZXMs
IFBoYW50RnVuYyAwLCBMYXRlbmN5IEwwcyA8NTEybnMsIEwxIDw0dXMNCgkJCUV4dFRhZysg
QXR0bkJ0bi0gQXR0bkluZC0gUHdySW5kLSBSQkUrIEZMUmVzZXQtDQoJCURldkN0bDoJUmVw
b3J0IGVycm9yczogQ29ycmVjdGFibGUtIE5vbi1GYXRhbC0gRmF0YWwtIFVuc3VwcG9ydGVk
LQ0KCQkJUmx4ZE9yZC0gRXh0VGFnLSBQaGFudEZ1bmMtIEF1eFB3ci0gTm9Tbm9vcCsNCgkJ
CU1heFBheWxvYWQgMTI4IGJ5dGVzLCBNYXhSZWFkUmVxIDUxMiBieXRlcw0KCQlEZXZTdGE6
CUNvcnJFcnItIFVuY29yckVyci0gRmF0YWxFcnItIFVuc3VwcFJlcS0gQXV4UHdyLSBUcmFu
c1BlbmQtDQoJCUxua0NhcDoJUG9ydCAjMCwgU3BlZWQgMi41R1QvcywgV2lkdGggeDE2LCBB
U1BNIEwwcyBMMSwgTGF0ZW5jeSBMMCA8NTEybnMsIEwxIDwxdXMNCgkJCUNsb2NrUE0tIFN1
cnByaXNlLSBMTEFjdFJlcC0gQndOb3QtDQoJCUxua0N0bDoJQVNQTSBEaXNhYmxlZDsgUkNC
IDEyOCBieXRlcyBEaXNhYmxlZC0gUmV0cmFpbi0gQ29tbUNsaysNCgkJCUV4dFN5bmNoLSBD
bG9ja1BNLSBBdXRXaWREaXMtIEJXSW50LSBBdXRCV0ludC0NCgkJTG5rU3RhOglTcGVlZCAy
LjVHVC9zLCBXaWR0aCB4OCwgVHJFcnItIFRyYWluLSBTbG90Q2xrKyBETEFjdGl2ZS0gQldN
Z210LSBBQldNZ210LQ0KCUNhcGFiaWxpdGllczogWzEwMCB2MV0gVmlydHVhbCBDaGFubmVs
DQoJCUNhcHM6CUxQRVZDPTAgUmVmQ2xrPTEwMG5zIFBBVEVudHJ5Qml0cz0xDQoJCUFyYjoJ
Rml4ZWQtIFdSUjMyLSBXUlI2NC0gV1JSMTI4LQ0KCQlDdHJsOglBcmJTZWxlY3Q9Rml4ZWQN
CgkJU3RhdHVzOglJblByb2dyZXNzLQ0KCQlWQzA6CUNhcHM6CVBBVE9mZnNldD0wMCBNYXhU
aW1lU2xvdHM9MSBSZWpTbm9vcFRyYW5zLQ0KCQkJQXJiOglGaXhlZC0gV1JSMzItIFdSUjY0
LSBXUlIxMjgtIFRXUlIxMjgtIFdSUjI1Ni0NCgkJCUN0cmw6CUVuYWJsZSsgSUQ9MCBBcmJT
ZWxlY3Q9Rml4ZWQgVEMvVkM9ZmYNCgkJCVN0YXR1czoJTmVnb1BlbmRpbmctIEluUHJvZ3Jl
c3MtDQoJQ2FwYWJpbGl0aWVzOiBbMTI4IHYxXSBQb3dlciBCdWRnZXRpbmcgPD8+DQoJQ2Fw
YWJpbGl0aWVzOiBbNjAwIHYxXSBWZW5kb3IgU3BlY2lmaWMgSW5mb3JtYXRpb246IElEPTAw
MDEgUmV2PTEgTGVuPTAyNCA8Pz4NCg0K
------------0E41640F726FFA493
Content-Type: text/plain;
 name="lspci-hvm.txt"
Content-transfer-encoding: base64
Content-Disposition: attachment;
 filename="lspci-hvm.txt"

MDA6MDAuMCBIb3N0IGJyaWRnZSBbMDYwMF06IEludGVsIENvcnBvcmF0aW9uIDQ0MEZYIC0g
ODI0NDFGWCBQTUMgW05hdG9tYV0gWzgwODY6MTIzN10gKHJldiAwMikNCglTdWJzeXN0ZW06
IFJlZCBIYXQsIEluYyBRZW11IHZpcnR1YWwgbWFjaGluZSBbMWFmNDoxMTAwXQ0KCVBoeXNp
Y2FsIFNsb3Q6IDANCglDb250cm9sOiBJL08tIE1lbS0gQnVzTWFzdGVyKyBTcGVjQ3ljbGUt
IE1lbVdJTlYtIFZHQVNub29wLSBQYXJFcnItIFN0ZXBwaW5nLSBTRVJSLSBGYXN0QjJCLSBE
aXNJTlR4LQ0KCVN0YXR1czogQ2FwLSA2Nk1Iei0gVURGLSBGYXN0QjJCLSBQYXJFcnItIERF
VlNFTD1mYXN0ID5UQWJvcnQtIDxUQWJvcnQtIDxNQWJvcnQtID5TRVJSLSA8UEVSUi0gSU5U
eC0NCglMYXRlbmN5OiAwDQoNCjAwOjAxLjAgSVNBIGJyaWRnZSBbMDYwMV06IEludGVsIENv
cnBvcmF0aW9uIDgyMzcxU0IgUElJWDMgSVNBIFtOYXRvbWEvVHJpdG9uIElJXSBbODA4Njo3
MDAwXQ0KCVN1YnN5c3RlbTogUmVkIEhhdCwgSW5jIFFlbXUgdmlydHVhbCBtYWNoaW5lIFsx
YWY0OjExMDBdDQoJUGh5c2ljYWwgU2xvdDogMQ0KCUNvbnRyb2w6IEkvTysgTWVtKyBCdXNN
YXN0ZXIrIFNwZWNDeWNsZS0gTWVtV0lOVi0gVkdBU25vb3AtIFBhckVyci0gU3RlcHBpbmct
IFNFUlItIEZhc3RCMkItIERpc0lOVHgtDQoJU3RhdHVzOiBDYXAtIDY2TUh6LSBVREYtIEZh
c3RCMkItIFBhckVyci0gREVWU0VMPW1lZGl1bSA+VEFib3J0LSA8VEFib3J0LSA8TUFib3J0
LSA+U0VSUi0gPFBFUlItIElOVHgtDQoJTGF0ZW5jeTogMA0KDQowMDowMS4xIElERSBpbnRl
cmZhY2UgWzAxMDFdOiBJbnRlbCBDb3Jwb3JhdGlvbiA4MjM3MVNCIFBJSVgzIElERSBbTmF0
b21hL1RyaXRvbiBJSV0gWzgwODY6NzAxMF0gKHByb2ctaWYgODAgW01hc3Rlcl0pDQoJU3Vi
c3lzdGVtOiBYZW5Tb3VyY2UsIEluYy4gRGV2aWNlIFs1ODUzOjAwMDFdDQoJUGh5c2ljYWwg
U2xvdDogMQ0KCUNvbnRyb2w6IEkvTysgTWVtLSBCdXNNYXN0ZXIrIFNwZWNDeWNsZS0gTWVt
V0lOVi0gVkdBU25vb3AtIFBhckVyci0gU3RlcHBpbmctIFNFUlItIEZhc3RCMkItIERpc0lO
VHgtDQoJU3RhdHVzOiBDYXAtIDY2TUh6LSBVREYtIEZhc3RCMkIrIFBhckVyci0gREVWU0VM
PW1lZGl1bSA+VEFib3J0LSA8VEFib3J0LSA8TUFib3J0LSA+U0VSUi0gPFBFUlItIElOVHgt
DQoJTGF0ZW5jeTogMA0KCVJlZ2lvbiAwOiBbdmlydHVhbF0gTWVtb3J5IGF0IDAwMDAwMWYw
ICgzMi1iaXQsIG5vbi1wcmVmZXRjaGFibGUpIFtzaXplPThdDQoJUmVnaW9uIDE6IFt2aXJ0
dWFsXSBNZW1vcnkgYXQgMDAwMDAzZjAgKHR5cGUgMywgbm9uLXByZWZldGNoYWJsZSkgW3Np
emU9MV0NCglSZWdpb24gMjogW3ZpcnR1YWxdIE1lbW9yeSBhdCAwMDAwMDE3MCAoMzItYml0
LCBub24tcHJlZmV0Y2hhYmxlKSBbc2l6ZT04XQ0KCVJlZ2lvbiAzOiBbdmlydHVhbF0gTWVt
b3J5IGF0IDAwMDAwMzcwICh0eXBlIDMsIG5vbi1wcmVmZXRjaGFibGUpIFtzaXplPTFdDQoJ
UmVnaW9uIDQ6IEkvTyBwb3J0cyBhdCBjMTYwIFtzaXplPTE2XQ0KDQowMDowMS4yIFVTQiBj
b250cm9sbGVyIFswYzAzXTogSW50ZWwgQ29ycG9yYXRpb24gODIzNzFTQiBQSUlYMyBVU0Ig
W05hdG9tYS9Ucml0b24gSUldIFs4MDg2OjcwMjBdIChyZXYgMDEpIChwcm9nLWlmIDAwIFtV
SENJXSkNCglTdWJzeXN0ZW06IFJlZCBIYXQsIEluYyBRZW11IHZpcnR1YWwgbWFjaGluZSBb
MWFmNDoxMTAwXQ0KCVBoeXNpY2FsIFNsb3Q6IDENCglDb250cm9sOiBJL08rIE1lbS0gQnVz
TWFzdGVyKyBTcGVjQ3ljbGUtIE1lbVdJTlYtIFZHQVNub29wLSBQYXJFcnItIFN0ZXBwaW5n
LSBTRVJSLSBGYXN0QjJCLSBEaXNJTlR4LQ0KCVN0YXR1czogQ2FwLSA2Nk1Iei0gVURGLSBG
YXN0QjJCLSBQYXJFcnItIERFVlNFTD1mYXN0ID5UQWJvcnQtIDxUQWJvcnQtIDxNQWJvcnQt
ID5TRVJSLSA8UEVSUi0gSU5UeC0NCglMYXRlbmN5OiA2NA0KCUludGVycnVwdDogcGluIEQg
cm91dGVkIHRvIElSUSAyMw0KCVJlZ2lvbiA0OiBJL08gcG9ydHMgYXQgYzE0MCBbc2l6ZT0z
Ml0NCglLZXJuZWwgZHJpdmVyIGluIHVzZTogdWhjaV9oY2QNCg0KMDA6MDEuMyBCcmlkZ2Ug
WzA2ODBdOiBJbnRlbCBDb3Jwb3JhdGlvbiA4MjM3MUFCL0VCL01CIFBJSVg0IEFDUEkgWzgw
ODY6NzExM10gKHJldiAwMSkNCglTdWJzeXN0ZW06IFJlZCBIYXQsIEluYyBRZW11IHZpcnR1
YWwgbWFjaGluZSBbMWFmNDoxMTAwXQ0KCVBoeXNpY2FsIFNsb3Q6IDENCglDb250cm9sOiBJ
L08tIE1lbS0gQnVzTWFzdGVyKyBTcGVjQ3ljbGUtIE1lbVdJTlYtIFZHQVNub29wLSBQYXJF
cnItIFN0ZXBwaW5nLSBTRVJSLSBGYXN0QjJCLSBEaXNJTlR4LQ0KCVN0YXR1czogQ2FwLSA2
Nk1Iei0gVURGLSBGYXN0QjJCLSBQYXJFcnItIERFVlNFTD1mYXN0ID5UQWJvcnQtIDxUQWJv
cnQtIDxNQWJvcnQtID5TRVJSLSA8UEVSUi0gSU5UeC0NCglMYXRlbmN5OiAwDQoJSW50ZXJy
dXB0OiBwaW4gQSByb3V0ZWQgdG8gSVJRIDkNCg0KMDA6MDIuMCBWR0EgY29tcGF0aWJsZSBj
b250cm9sbGVyIFswMzAwXTogQ2lycnVzIExvZ2ljIEdEIDU0NDYgWzEwMTM6MDBiOF0gKHBy
b2ctaWYgMDAgW1ZHQSBjb250cm9sbGVyXSkNCglTdWJzeXN0ZW06IFhlblNvdXJjZSwgSW5j
LiBEZXZpY2UgWzU4NTM6MDAwMV0NCglQaHlzaWNhbCBTbG90OiAyDQoJQ29udHJvbDogSS9P
KyBNZW0rIEJ1c01hc3RlcisgU3BlY0N5Y2xlLSBNZW1XSU5WLSBWR0FTbm9vcC0gUGFyRXJy
LSBTdGVwcGluZy0gU0VSUi0gRmFzdEIyQi0gRGlzSU5UeC0NCglTdGF0dXM6IENhcC0gNjZN
SHotIFVERi0gRmFzdEIyQi0gUGFyRXJyLSBERVZTRUw9ZmFzdCA+VEFib3J0LSA8VEFib3J0
LSA8TUFib3J0LSA+U0VSUi0gPFBFUlItIElOVHgtDQoJTGF0ZW5jeTogMA0KCVJlZ2lvbiAw
OiBNZW1vcnkgYXQgZjAwMDAwMDAgKDMyLWJpdCwgcHJlZmV0Y2hhYmxlKSBbc2l6ZT0zMk1d
DQoJUmVnaW9uIDE6IE1lbW9yeSBhdCBmMzIyMDAwMCAoMzItYml0LCBub24tcHJlZmV0Y2hh
YmxlKSBbc2l6ZT00S10NCglFeHBhbnNpb24gUk9NIGF0IDx1bmFzc2lnbmVkPiBbZGlzYWJs
ZWRdDQoNCjAwOjAzLjAgVW5hc3NpZ25lZCBjbGFzcyBbZmY4MF06IFhlblNvdXJjZSwgSW5j
LiBYZW4gUGxhdGZvcm0gRGV2aWNlIFs1ODUzOjAwMDFdIChyZXYgMDEpDQoJU3Vic3lzdGVt
OiBYZW5Tb3VyY2UsIEluYy4gWGVuIFBsYXRmb3JtIERldmljZSBbNTg1MzowMDAxXQ0KCVBo
eXNpY2FsIFNsb3Q6IDMNCglDb250cm9sOiBJL08rIE1lbSsgQnVzTWFzdGVyKyBTcGVjQ3lj
bGUtIE1lbVdJTlYtIFZHQVNub29wLSBQYXJFcnItIFN0ZXBwaW5nLSBTRVJSLSBGYXN0QjJC
LSBEaXNJTlR4LQ0KCVN0YXR1czogQ2FwLSA2Nk1Iei0gVURGLSBGYXN0QjJCLSBQYXJFcnIt
IERFVlNFTD1mYXN0ID5UQWJvcnQtIDxUQWJvcnQtIDxNQWJvcnQtID5TRVJSLSA8UEVSUi0g
SU5UeC0NCglMYXRlbmN5OiAwDQoJSW50ZXJydXB0OiBwaW4gQSByb3V0ZWQgdG8gSVJRIDI4
DQoJUmVnaW9uIDA6IEkvTyBwb3J0cyBhdCBjMDAwIFtzaXplPTI1Nl0NCglSZWdpb24gMTog
TWVtb3J5IGF0IGYyMDAwMDAwICgzMi1iaXQsIHByZWZldGNoYWJsZSkgW3NpemU9MTZNXQ0K
CUtlcm5lbCBkcml2ZXIgaW4gdXNlOiB4ZW4tcGxhdGZvcm0tcGNpDQoNCjAwOjA1LjAgTXVs
dGltZWRpYSB2aWRlbyBjb250cm9sbGVyIFswNDAwXTogQ29uZXhhbnQgU3lzdGVtcywgSW5j
LiBEZXZpY2UgWzE0ZjE6ODIxMF0NCglQaHlzaWNhbCBTbG90OiA1DQoJQ29udHJvbDogSS9P
LSBNZW0rIEJ1c01hc3RlcisgU3BlY0N5Y2xlLSBNZW1XSU5WLSBWR0FTbm9vcC0gUGFyRXJy
LSBTdGVwcGluZy0gU0VSUi0gRmFzdEIyQi0gRGlzSU5UeC0NCglTdGF0dXM6IENhcCsgNjZN
SHotIFVERi0gRmFzdEIyQi0gUGFyRXJyLSBERVZTRUw9ZmFzdCA+VEFib3J0LSA8VEFib3J0
LSA8TUFib3J0LSA+U0VSUi0gPFBFUlItIElOVHgtDQoJTGF0ZW5jeTogMA0KCUludGVycnVw
dDogcGluIEEgcm91dGVkIHRvIElSUSAzNg0KCVJlZ2lvbiAwOiBNZW1vcnkgYXQgZjMwMDAw
MDAgKDY0LWJpdCwgbm9uLXByZWZldGNoYWJsZSkgW3NpemU9Mk1dDQoJQ2FwYWJpbGl0aWVz
OiBbNDBdIEV4cHJlc3MgKHYxKSBFbmRwb2ludCwgTVNJIDAwDQoJCURldkNhcDoJTWF4UGF5
bG9hZCAxMjggYnl0ZXMsIFBoYW50RnVuYyAwLCBMYXRlbmN5IEwwcyA8NjRucywgTDEgPDF1
cw0KCQkJRXh0VGFnLSBBdHRuQnRuLSBBdHRuSW5kLSBQd3JJbmQtIFJCRSsgRkxSZXNldC0N
CgkJRGV2Q3RsOglSZXBvcnQgZXJyb3JzOiBDb3JyZWN0YWJsZS0gTm9uLUZhdGFsLSBGYXRh
bC0gVW5zdXBwb3J0ZWQtDQoJCQlSbHhkT3JkKyBFeHRUYWctIFBoYW50RnVuYy0gQXV4UHdy
LSBOb1Nub29wKw0KCQkJTWF4UGF5bG9hZCAxMjggYnl0ZXMsIE1heFJlYWRSZXEgNTEyIGJ5
dGVzDQoJCURldlN0YToJQ29yckVycisgVW5jb3JyRXJyKyBGYXRhbEVyci0gVW5zdXBwUmVx
KyBBdXhQd3ItIFRyYW5zUGVuZC0NCgkJTG5rQ2FwOglQb3J0ICMwLCBTcGVlZCAyLjVHVC9z
LCBXaWR0aCB4MSwgQVNQTSBMMHMgTDEsIExhdGVuY3kgTDAgPDJ1cywgTDEgPDR1cw0KCQkJ
Q2xvY2tQTS0gU3VycHJpc2UtIExMQWN0UmVwLSBCd05vdC0NCgkJTG5rQ3RsOglBU1BNIERp
c2FibGVkOyBSQ0IgNjQgYnl0ZXMgRGlzYWJsZWQtIFJldHJhaW4tIENvbW1DbGstDQoJCQlF
eHRTeW5jaC0gQ2xvY2tQTS0gQXV0V2lkRGlzLSBCV0ludC0gQXV0QldJbnQtDQoJCUxua1N0
YToJU3BlZWQgMi41R1QvcywgV2lkdGggeDEsIFRyRXJyLSBUcmFpbi0gU2xvdENsay0gRExB
Y3RpdmUtIEJXTWdtdC0gQUJXTWdtdC0NCglDYXBhYmlsaXRpZXM6IFs4MF0gUG93ZXIgTWFu
YWdlbWVudCB2ZXJzaW9uIDMNCgkJRmxhZ3M6IFBNRUNsay0gRFNJKyBEMSsgRDIrIEF1eEN1
cnJlbnQ9MG1BIFBNRShEMC0sRDEtLEQyLSxEM2hvdC0sRDNjb2xkLSkNCgkJU3RhdHVzOiBE
MCBOb1NvZnRSc3QrIFBNRS1FbmFibGUtIERTZWw9MCBEU2NhbGU9MCBQTUUtDQoJQ2FwYWJp
bGl0aWVzOiBbOTBdIFZpdGFsIFByb2R1Y3QgRGF0YQ0KCQlVbmtub3duIHNtYWxsIHJlc291
cmNlIHR5cGUgMDAsIHdpbGwgbm90IGRlY29kZSBtb3JlLg0KCUNhcGFiaWxpdGllczogW2Ew
XSBNU0k6IEVuYWJsZS0gQ291bnQ9MS8xIE1hc2thYmxlLSA2NGJpdCsNCgkJQWRkcmVzczog
MDAwMDAwMDAwMDAwMDAwMCAgRGF0YTogMDAwMA0KCUNhcGFiaWxpdGllczogWzEwMCB2MF0g
IzE0ZjENCglLZXJuZWwgZHJpdmVyIGluIHVzZTogY3gyNTgyMQ0KDQo=
------------0E41640F726FFA493
Content-Type: application/octet-stream;
 name="patch.diff"
Content-transfer-encoding: base64
Content-Disposition: attachment;
 filename="patch.diff"

ZGlmZiAtciBkMzY0YmVjZmIwODMgeGVuL2RyaXZlcnMvcGFzc3Rocm91Z2gvYW1kL2lvbW11
X21hcC5jCi0tLSBhL3hlbi9kcml2ZXJzL3Bhc3N0aHJvdWdoL2FtZC9pb21tdV9tYXAuYwlU
aHUgU2VwIDIwIDEzOjMxOjE5IDIwMTIgKzAyMDAKKysrIGIveGVuL2RyaXZlcnMvcGFzc3Ro
cm91Z2gvYW1kL2lvbW11X21hcC5jCU1vbiBTZXAgMjQgMTA6MzU6MTUgMjAxMiArMDIwMApA
QCAtNzk1LDcgKzc5NSw4IEBACiAKICAgICAgICAgLyogV2hlbiBzaGFyaW5nIHAybSB3aXRo
IGlvbW11LCBwYWdpbmcgbW9kZSA9IDQgKi8KICAgICAgICAgaGQtPnBhZ2luZ19tb2RlID0g
SU9NTVVfUEFHSU5HX01PREVfTEVWRUxfNDsKLSAgICAgICAgQU1EX0lPTU1VX0RFQlVHKCJT
aGFyZSBwMm0gdGFibGUgd2l0aCBpb21tdTogcDJtIHRhYmxlID0gMHglbHhcbiIsCisgICAg
ICAgIEFNRF9JT01NVV9ERUJVRygiU2hhcmUgcDJtIHRhYmxlIHdpdGggaW9tbXU6IGRvbWFp
bjolZCBwMm0gdGFibGUgPSAweCVseFxuIiwKKyAgICAgICAgICAgICAgICAgICAgICAgIGQt
PmRvbWFpbl9pZCwKICAgICAgICAgICAgICAgICAgICAgICAgIG1mbl94KHBnZF9tZm4pKTsK
ICAgICB9CiB9CmRpZmYgLXIgZDM2NGJlY2ZiMDgzIHhlbi9kcml2ZXJzL3Bhc3N0aHJvdWdo
L2FtZC9wY2lfYW1kX2lvbW11LmMKLS0tIGEveGVuL2RyaXZlcnMvcGFzc3Rocm91Z2gvYW1k
L3BjaV9hbWRfaW9tbXUuYwlUaHUgU2VwIDIwIDEzOjMxOjE5IDIwMTIgKzAyMDAKKysrIGIv
eGVuL2RyaXZlcnMvcGFzc3Rocm91Z2gvYW1kL3BjaV9hbWRfaW9tbXUuYwlNb24gU2VwIDI0
IDEwOjM1OjE1IDIwMTIgKzAyMDAKQEAgLTg3LDEwICs4NywxMSBAQAogewogICAgIHZvaWQg
KmR0ZTsKICAgICB1bnNpZ25lZCBsb25nIGZsYWdzOwotICAgIGludCByZXFfaWQsIHZhbGlk
ID0gMTsKKyAgICBpbnQgcmVxX2lkLCByZXFhX2lkLHZhbGlkID0gMTsKICAgICBpbnQgZHRl
X2kgPSAwOwogICAgIHU4IGJ1cyA9IFBDSV9CVVMoYmRmKTsKICAgICB1OCBkZXZmbiA9IFBD
SV9ERVZGTjIoYmRmKTsKKyAgICBzdHJ1Y3QgaXZyc19tYXBwaW5ncyAqaXZyc19tYXBwaW5n
czsKIAogICAgIHN0cnVjdCBodm1faW9tbXUgKmhkID0gZG9tYWluX2h2bV9pb21tdShkb21h
aW4pOwogCkBAIC0xMjAsMTIgKzEyMSwxOCBAQAogICAgICAgICAgICAgaW9tbXVfZHRlX3Nl
dF9pb3RsYigodTMyICopZHRlLCBkdGVfaSk7CiAKICAgICAgICAgYW1kX2lvbW11X2ZsdXNo
X2RldmljZShpb21tdSwgcmVxX2lkKTsKLQorICAgIGl2cnNfbWFwcGluZ3MgPSBnZXRfaXZy
c19tYXBwaW5ncyhpb21tdS0+c2VnKTsKKyAgICByZXFhX2lkID0gZ2V0X2RtYV9yZXF1ZXN0
b3JfaWQoaW9tbXUtPnNlZywgYmRmKTsKKyAgICAKICAgICAgICAgQU1EX0lPTU1VX0RFQlVH
KCJTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHglMDR4LCAiCiAgICAgICAg
ICAgICAgICAgICAgICAgICAicm9vdCB0YWJsZSA9IDB4JSJQUkl4NjQiLCAiCi0gICAgICAg
ICAgICAgICAgICAgICAgICAiZG9tYWluID0gJWQsIHBhZ2luZyBtb2RlID0gJWRcbiIsIHJl
cV9pZCwKKyAgICAgICAgICAgICAgICAgICAgICAgICJkb21haW4gPSAlZCwgcGFnaW5nIG1v
ZGUgPSAlZCB8ICVseCAlbHggJWx4ICVseFxuIiwgcmVxX2lkLAogICAgICAgICAgICAgICAg
ICAgICAgICAgcGFnZV90b19tYWRkcihoZC0+cm9vdF90YWJsZSksCi0gICAgICAgICAgICAg
ICAgICAgICAgICBoZC0+ZG9tYWluX2lkLCBoZC0+cGFnaW5nX21vZGUpOworICAgICAgICAg
ICAgICAgICAgICAgICAgaGQtPmRvbWFpbl9pZCwgaGQtPnBhZ2luZ19tb2RlLAorICAgIGl2
cnNfbWFwcGluZ3NbcmVxYV9pZF0uYWRkcl9yYW5nZV9zdGFydCwKKyAgICBpdnJzX21hcHBp
bmdzW3JlcWFfaWRdLmFkZHJfcmFuZ2VfbGVuZ3RoLAorICAgIGl2cnNfbWFwcGluZ3NbYmRm
XS5hZGRyX3JhbmdlX3N0YXJ0LAorICAgIGl2cnNfbWFwcGluZ3NbYmRmXS5hZGRyX3Jhbmdl
X2xlbmd0aCk7CiAgICAgfQogCiAgICAgc3Bpbl91bmxvY2tfaXJxcmVzdG9yZSgmaW9tbXUt
PmxvY2ssIGZsYWdzKTsKQEAgLTMzNCw4ICszNDEsMTAgQEAKICAgICBzdHJ1Y3QgcGNpX2Rl
diAqcGRldjsKICAgICBzdHJ1Y3QgYW1kX2lvbW11ICppb21tdTsKICAgICBpbnQgYmRmOwor
ICAgIGludCByZXFfaWQ7CiAgICAgc3RydWN0IGh2bV9pb21tdSAqdCA9IGRvbWFpbl9odm1f
aW9tbXUodGFyZ2V0KTsKLQorICAgIHN0cnVjdCBpdnJzX21hcHBpbmdzICppdnJzX21hcHBp
bmdzOworICAgIAogICAgIEFTU0VSVChzcGluX2lzX2xvY2tlZCgmcGNpZGV2c19sb2NrKSk7
CiAgICAgcGRldiA9IHBjaV9nZXRfcGRldl9ieV9kb21haW4oc291cmNlLCBzZWcsIGJ1cywg
ZGV2Zm4pOwogICAgIGlmICggIXBkZXYgKQpAQCAtMzYzLDEwICszNzIsMTcgQEAKICAgICAg
ICAgYWxsb2NhdGVfZG9tYWluX3Jlc291cmNlcyh0KTsKIAogICAgIGFtZF9pb21tdV9zZXR1
cF9kb21haW5fZGV2aWNlKHRhcmdldCwgaW9tbXUsIGJkZik7Ci0gICAgQU1EX0lPTU1VX0RF
QlVHKCJSZS1hc3NpZ24gJTA0eDolMDJ4OiUwMnguJXUgZnJvbSBkb20lZCB0byBkb20lZFxu
IiwKKyAgICAKKyAgICBpdnJzX21hcHBpbmdzID0gZ2V0X2l2cnNfbWFwcGluZ3Moc2VnKTsK
KyAgICByZXFfaWQgPSBnZXRfZG1hX3JlcXVlc3Rvcl9pZChzZWcsIGJkZik7CisgICAgCisg
ICAgQU1EX0lPTU1VX0RFQlVHKCJSZS1hc3NpZ24gJTA0eDolMDJ4OiUwMnguJXUgZnJvbSBk
b20lZCB0byBkb20lZCAlbHggJWx4ICVseCAlbHhcbiIsCiAgICAgICAgICAgICAgICAgICAg
IHNlZywgYnVzLCBQQ0lfU0xPVChkZXZmbiksIFBDSV9GVU5DKGRldmZuKSwKLSAgICAgICAg
ICAgICAgICAgICAgc291cmNlLT5kb21haW5faWQsIHRhcmdldC0+ZG9tYWluX2lkKTsKLQor
ICAgICAgICAgICAgICAgICAgICBzb3VyY2UtPmRvbWFpbl9pZCwgdGFyZ2V0LT5kb21haW5f
aWQsCisgICAgaXZyc19tYXBwaW5nc1tyZXFfaWRdLmFkZHJfcmFuZ2Vfc3RhcnQsCisgICAg
aXZyc19tYXBwaW5nc1tyZXFfaWRdLmFkZHJfcmFuZ2VfbGVuZ3RoLAorICAgIGl2cnNfbWFw
cGluZ3NbYmRmXS5hZGRyX3JhbmdlX3N0YXJ0LAorICAgIGl2cnNfbWFwcGluZ3NbYmRmXS5h
ZGRyX3JhbmdlX2xlbmd0aCk7CiAgICAgcmV0dXJuIDA7CiB9CiAKQEAgLTM4NSw2ICs0MDEs
MTMgQEAKICAgICAgICAgICAgIGl2cnNfbWFwcGluZ3NbcmVxX2lkXS53cml0ZV9wZXJtaXNz
aW9uLAogICAgICAgICAgICAgaXZyc19tYXBwaW5nc1tyZXFfaWRdLnJlYWRfcGVybWlzc2lv
bik7CiAgICAgfQorICAgICAgICBBTURfSU9NTVVfREVCVUcoImFtZF9pb21tdV9hc3NpZ25f
ZGV2aWNlOiIKKyAgICAgICAgICAgICAgICAgICAgICAgICIgZDolZCAlMDR4OiUwMng6JTAy
eC4ldSAlbHggJWx4XG4iLAorICAgICAgICAgICAgICAgICAgICAgICAgZC0+ZG9tYWluX2lk
LAorICAgICAgICAgICAgICAgICAgICAgICAgc2VnLCBidXMsIFBDSV9TTE9UKGRldmZuKSwK
KyAgICAgICAgICAgICAgICAgICAgICAgIFBDSV9GVU5DKGRldmZuKSwKKyAgICAgICAgICAg
ICAgICAgICAgICAgIGl2cnNfbWFwcGluZ3NbcmVxX2lkXS5hZGRyX3JhbmdlX3N0YXJ0LAor
ICAgICAgICAgICAgICAgICAgICAgICAgaXZyc19tYXBwaW5nc1tyZXFfaWRdLmFkZHJfcmFu
Z2VfbGVuZ3RoKTsKIAogICAgIHJldHVybiByZWFzc2lnbl9kZXZpY2UoZG9tMCwgZCwgc2Vn
LCBidXMsIGRldmZuKTsKIH0K
------------0E41640F726FFA493
Content-Type: text/plain;
 name="xl-dmesg-hvm.txt"
Content-transfer-encoding: base64
Content-Disposition: attachment;
 filename="xl-dmesg-hvm.txt"

IF9fICBfXyAgICAgICAgICAgIF8gIF8gICAgX19fX18gICAgICAgICAgICAgICAgICAgIF8g
ICAgICAgIF8gICAgIF8gICAgICANCiBcIFwvIC9fX18gXyBfXyAgIHwgfHwgfCAgfF9fXyAv
ICAgIF8gICBfIF8gX18gIF9fX3wgfF8gX18gX3wgfF9fIHwgfCBfX18gDQogIFwgIC8vIF8g
XCAnXyBcICB8IHx8IHxfICAgfF8gXCBfX3wgfCB8IHwgJ18gXC8gX198IF9fLyBfYCB8ICdf
IFx8IHwvIF8gXA0KICAvICBcICBfXy8gfCB8IHwgfF9fICAgX3wgX19fKSB8X198IHxffCB8
IHwgfCBcX18gXCB8fCAoX3wgfCB8XykgfCB8ICBfXy8NCiAvXy9cX1xfX198X3wgfF98ICAg
IHxffChfKV9fX18vICAgIFxfXyxffF98IHxffF9fXy9cX19cX18sX3xfLl9fL3xffFxfX198
DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgIA0KKFhFTikgWGVuIHZlcnNpb24gNC4zLXVuc3RhYmxl
IChyb290QGR5bmRucy5vcmcpIChnY2MgKERlYmlhbiA0LjQuNS04KSA0LjQuNSkgU3VuIFNl
cCAyMyAyMDoyNDo0MiBDRVNUIDIwMTINCihYRU4pIExhdGVzdCBDaGFuZ2VTZXQ6IFRodSBT
ZXAgMjAgMTM6MzE6MTkgMjAxMiArMDIwMCAyNTkzMzpkMzY0YmVjZmIwODMNCihYRU4pIEJv
b3Rsb2FkZXI6IEdSVUIgMS45OCsyMDEwMDgwNC0xNCtzcXVlZXplMQ0KKFhFTikgQ29tbWFu
ZCBsaW5lOiBkb20wX21lbT0xMDI0TSxtYXg6MTAyNE0gbG9nbHZsPWFsbCBsb2dsdmxfZ3Vl
c3Q9YWxsIGNvbnNvbGVfdGltZXN0YW1wcyB2Z2E9Z2Z4LTEyODB4MTAyNHgzMiBjcHVpZGxl
IGNwdWZyZXE9eGVuIG5vcmVib290IGRlYnVnIGxhcGljPWRlYnVnIGFwaWNfdmVyYm9zaXR5
PWRlYnVnIGFwaWM9ZGVidWcgaW9tbXU9b24sdmVyYm9zZSxkZWJ1ZyxhbWQtaW9tbXUtZGVi
dWcgY29tMT0zODQwMCw4bjEgY29uc29sZT12Z2EsY29tMQ0KKFhFTikgVmlkZW8gaW5mb3Jt
YXRpb246DQooWEVOKSAgVkdBIGlzIGdyYXBoaWNzIG1vZGUgMTI4MHgxMDI0LCAzMiBicHAN
CihYRU4pICBWQkUvRERDIG1ldGhvZHM6IFYyOyBFRElEIHRyYW5zZmVyIHRpbWU6IDEgc2Vj
b25kcw0KKFhFTikgRGlzYyBpbmZvcm1hdGlvbjoNCihYRU4pICBGb3VuZCAyIE1CUiBzaWdu
YXR1cmVzDQooWEVOKSAgRm91bmQgMiBFREQgaW5mb3JtYXRpb24gc3RydWN0dXJlcw0KKFhF
TikgWGVuLWU4MjAgUkFNIG1hcDoNCihYRU4pICAwMDAwMDAwMDAwMDAwMDAwIC0gMDAwMDAw
MDAwMDA5ZjAwMCAodXNhYmxlKQ0KKFhFTikgIDAwMDAwMDAwMDAwOWYwMDAgLSAwMDAwMDAw
MDAwMGEwMDAwIChyZXNlcnZlZCkNCihYRU4pICAwMDAwMDAwMDAwMGU0MDAwIC0gMDAwMDAw
MDAwMDEwMDAwMCAocmVzZXJ2ZWQpDQooWEVOKSAgMDAwMDAwMDAwMDEwMDAwMCAtIDAwMDAw
MDAwYWZmOTAwMDAgKHVzYWJsZSkNCihYRU4pICAwMDAwMDAwMGFmZjkwMDAwIC0gMDAwMDAw
MDBhZmY5ZTAwMCAoQUNQSSBkYXRhKQ0KKFhFTikgIDAwMDAwMDAwYWZmOWUwMDAgLSAwMDAw
MDAwMGFmZmUwMDAwIChBQ1BJIE5WUykNCihYRU4pICAwMDAwMDAwMGFmZmUwMDAwIC0gMDAw
MDAwMDBiMDAwMDAwMCAocmVzZXJ2ZWQpDQooWEVOKSAgMDAwMDAwMDBmZmUwMDAwMCAtIDAw
MDAwMDAxMDAwMDAwMDAgKHJlc2VydmVkKQ0KKFhFTikgIDAwMDAwMDAxMDAwMDAwMDAgLSAw
MDAwMDAwMjUwMDAwMDAwICh1c2FibGUpDQooWEVOKSBBQ1BJOiBSU0RQIDAwMEZCMTAwLCAw
MDE0IChyMCBBQ1BJQU0pDQooWEVOKSBBQ1BJOiBSU0RUIEFGRjkwMDAwLCAwMDQ4IChyMSBN
U0kgICAgT0VNU0xJQyAgMjAxMDA5MTMgTVNGVCAgICAgICA5NykNCihYRU4pIEFDUEk6IEZB
Q1AgQUZGOTAyMDAsIDAwODQgKHIxIDc2NDBNUyBBNzY0MDEwMCAyMDEwMDkxMyBNU0ZUICAg
ICAgIDk3KQ0KKFhFTikgQUNQSTogRFNEVCBBRkY5MDVFMCwgOTQyNyAocjEgIEE3NjQwIEE3
NjQwMTAwICAgICAgMTAwIElOVEwgMjAwNTExMTcpDQooWEVOKSBBQ1BJOiBGQUNTIEFGRjlF
MDAwLCAwMDQwDQooWEVOKSBBQ1BJOiBBUElDIEFGRjkwMzkwLCAwMDg4IChyMSA3NjQwTVMg
QTc2NDAxMDAgMjAxMDA5MTMgTVNGVCAgICAgICA5NykNCihYRU4pIEFDUEk6IE1DRkcgQUZG
OTA0MjAsIDAwM0MgKHIxIDc2NDBNUyBPRU1NQ0ZHICAyMDEwMDkxMyBNU0ZUICAgICAgIDk3
KQ0KKFhFTikgQUNQSTogU0xJQyBBRkY5MDQ2MCwgMDE3NiAocjEgTVNJICAgIE9FTVNMSUMg
IDIwMTAwOTEzIE1TRlQgICAgICAgOTcpDQooWEVOKSBBQ1BJOiBPRU1CIEFGRjlFMDQwLCAw
MDcyIChyMSA3NjQwTVMgQTc2NDAxMDAgMjAxMDA5MTMgTVNGVCAgICAgICA5NykNCihYRU4p
IEFDUEk6IFNSQVQgQUZGOUE1RTAsIDAxMDggKHIzIEFNRCAgICBGQU1fRl8xMCAgICAgICAg
MiBBTUQgICAgICAgICAxKQ0KKFhFTikgQUNQSTogSFBFVCBBRkY5QTZGMCwgMDAzOCAocjEg
NzY0ME1TIE9FTUhQRVQgIDIwMTAwOTEzIE1TRlQgICAgICAgOTcpDQooWEVOKSBBQ1BJOiBJ
VlJTIEFGRjlBNzMwLCAwMEY4IChyMSAgQU1EICAgICBSRDg5MFMgICAyMDIwMzEgQU1EICAg
ICAgICAgMCkNCihYRU4pIEFDUEk6IFNTRFQgQUZGOUE4MzAsIDBEQTQgKHIxIEEgTSBJICBQ
T1dFUk5PVyAgICAgICAgMSBBTUQgICAgICAgICAxKQ0KKFhFTikgU3lzdGVtIFJBTTogODE5
MU1CICg4Mzg3Nzcya0IpDQooWEVOKSBTUkFUOiBQWE0gMCAtPiBBUElDIDAgLT4gTm9kZSAw
DQooWEVOKSBTUkFUOiBQWE0gMCAtPiBBUElDIDEgLT4gTm9kZSAwDQooWEVOKSBTUkFUOiBQ
WE0gMCAtPiBBUElDIDIgLT4gTm9kZSAwDQooWEVOKSBTUkFUOiBQWE0gMCAtPiBBUElDIDMg
LT4gTm9kZSAwDQooWEVOKSBTUkFUOiBQWE0gMCAtPiBBUElDIDQgLT4gTm9kZSAwDQooWEVO
KSBTUkFUOiBQWE0gMCAtPiBBUElDIDUgLT4gTm9kZSAwDQooWEVOKSBTUkFUOiBOb2RlIDAg
UFhNIDAgMC1hMDAwMA0KKFhFTikgU1JBVDogTm9kZSAwIFBYTSAwIDEwMDAwMC1iMDAwMDAw
MA0KKFhFTikgU1JBVDogTm9kZSAwIFBYTSAwIDEwMDAwMDAwMC0yNTAwMDAwMDANCihYRU4p
IE5VTUE6IEFsbG9jYXRlZCBtZW1ub2RlbWFwIGZyb20gMjRkOWE0MDAwIC0gMjRkOWE3MDAw
DQooWEVOKSBOVU1BOiBVc2luZyA4IGZvciB0aGUgaGFzaCBzaGlmdC4NCihYRU4pIERvbWFp
biBoZWFwIGluaXRpYWxpc2VkDQooWEVOKSB2ZXNhZmI6IGZyYW1lYnVmZmVyIGF0IDB4ZmIw
MDAwMDAsIG1hcHBlZCB0byAweGZmZmY4MmMwMDAwMDAwMDAsIHVzaW5nIDYxNDRrLCB0b3Rh
bCAxNDMzNmsNCihYRU4pIHZlc2FmYjogbW9kZSBpcyAxMjgweDEwMjR4MzIsIGxpbmVsZW5n
dGg9NTEyMCwgZm9udCA4eDE2DQooWEVOKSB2ZXNhZmI6IFRydWVjb2xvcjogc2l6ZT04Ojg6
ODo4LCBzaGlmdD0yNDoxNjo4OjANCihYRU4pIGZvdW5kIFNNUCBNUC10YWJsZSBhdCAwMDBm
Zjc4MA0KKFhFTikgRE1JIHByZXNlbnQuDQooWEVOKSBBUElDIGJvb3Qgc3RhdGUgaXMgJ3hh
cGljJw0KKFhFTikgVXNpbmcgQVBJQyBkcml2ZXIgZGVmYXVsdA0KKFhFTikgQUNQSTogUE0t
VGltZXIgSU8gUG9ydDogMHg4MDgNCihYRU4pIEFDUEk6IEFDUEkgU0xFRVAgSU5GTzogcG0x
eF9jbnRbODA0LDBdLCBwbTF4X2V2dFs4MDAsMF0NCihYRU4pIEFDUEk6ICAgICAgICAgICAg
ICAgICAgd2FrZXVwX3ZlY1thZmY5ZTAwY10sIHZlY19zaXplWzIwXQ0KKFhFTikgQUNQSTog
TG9jYWwgQVBJQyBhZGRyZXNzIDB4ZmVlMDAwMDANCihYRU4pIEFDUEk6IExBUElDIChhY3Bp
X2lkWzB4MDFdIGxhcGljX2lkWzB4MDBdIGVuYWJsZWQpDQooWEVOKSBQcm9jZXNzb3IgIzAg
MDoxMCBBUElDIHZlcnNpb24gMTYNCihYRU4pIEFDUEk6IExBUElDIChhY3BpX2lkWzB4MDJd
IGxhcGljX2lkWzB4MDFdIGVuYWJsZWQpDQooWEVOKSBQcm9jZXNzb3IgIzEgMDoxMCBBUElD
IHZlcnNpb24gMTYNCihYRU4pIEFDUEk6IExBUElDIChhY3BpX2lkWzB4MDNdIGxhcGljX2lk
WzB4MDJdIGVuYWJsZWQpDQooWEVOKSBQcm9jZXNzb3IgIzIgMDoxMCBBUElDIHZlcnNpb24g
MTYNCihYRU4pIEFDUEk6IExBUElDIChhY3BpX2lkWzB4MDRdIGxhcGljX2lkWzB4MDNdIGVu
YWJsZWQpDQooWEVOKSBQcm9jZXNzb3IgIzMgMDoxMCBBUElDIHZlcnNpb24gMTYNCihYRU4p
IEFDUEk6IExBUElDIChhY3BpX2lkWzB4MDVdIGxhcGljX2lkWzB4MDRdIGVuYWJsZWQpDQoo
WEVOKSBQcm9jZXNzb3IgIzQgMDoxMCBBUElDIHZlcnNpb24gMTYNCihYRU4pIEFDUEk6IExB
UElDIChhY3BpX2lkWzB4MDZdIGxhcGljX2lkWzB4MDVdIGVuYWJsZWQpDQooWEVOKSBQcm9j
ZXNzb3IgIzUgMDoxMCBBUElDIHZlcnNpb24gMTYNCihYRU4pIEFDUEk6IElPQVBJQyAoaWRb
MHgwNl0gYWRkcmVzc1sweGZlYzAwMDAwXSBnc2lfYmFzZVswXSkNCihYRU4pIElPQVBJQ1sw
XTogYXBpY19pZCA2LCB2ZXJzaW9uIDMzLCBhZGRyZXNzIDB4ZmVjMDAwMDAsIEdTSSAwLTIz
DQooWEVOKSBBQ1BJOiBJT0FQSUMgKGlkWzB4MDddIGFkZHJlc3NbMHhmZWMyMDAwMF0gZ3Np
X2Jhc2VbMjRdKQ0KKFhFTikgSU9BUElDWzFdOiBhcGljX2lkIDcsIHZlcnNpb24gMzMsIGFk
ZHJlc3MgMHhmZWMyMDAwMCwgR1NJIDI0LTU1DQooWEVOKSBBQ1BJOiBJTlRfU1JDX09WUiAo
YnVzIDAgYnVzX2lycSAwIGdsb2JhbF9pcnEgMiBkZmwgZGZsKQ0KKFhFTikgQUNQSTogSU5U
X1NSQ19PVlIgKGJ1cyAwIGJ1c19pcnEgOSBnbG9iYWxfaXJxIDkgbG93IGxldmVsKQ0KKFhF
TikgQUNQSTogSVJRMCB1c2VkIGJ5IG92ZXJyaWRlLg0KKFhFTikgQUNQSTogSVJRMiB1c2Vk
IGJ5IG92ZXJyaWRlLg0KKFhFTikgQUNQSTogSVJROSB1c2VkIGJ5IG92ZXJyaWRlLg0KKFhF
TikgRW5hYmxpbmcgQVBJQyBtb2RlOiAgRmxhdC4gIFVzaW5nIDIgSS9PIEFQSUNzDQooWEVO
KSBBQ1BJOiBIUEVUIGlkOiAweDgzMDAgYmFzZTogMHhmZWQwMDAwMA0KKFhFTikgVGFibGUg
aXMgbm90IGZvdW5kIQ0KKFhFTikgVXNpbmcgQUNQSSAoTUFEVCkgZm9yIFNNUCBjb25maWd1
cmF0aW9uIGluZm9ybWF0aW9uDQooWEVOKSBTTVA6IEFsbG93aW5nIDYgQ1BVcyAoMCBob3Rw
bHVnIENQVXMpDQooWEVOKSBtYXBwZWQgQVBJQyB0byBmZmZmODJjM2ZmZGZiMDAwIChmZWUw
MDAwMCkNCihYRU4pIG1hcHBlZCBJT0FQSUMgdG8gZmZmZjgyYzNmZmRmYTAwMCAoZmVjMDAw
MDApDQooWEVOKSBtYXBwZWQgSU9BUElDIHRvIGZmZmY4MmMzZmZkZjkwMDAgKGZlYzIwMDAw
KQ0KKFhFTikgSVJRIGxpbWl0czogNTYgR1NJLCAxMTEyIE1TSS9NU0ktWA0KKFhFTikgVXNp
bmcgc2NoZWR1bGVyOiBTTVAgQ3JlZGl0IFNjaGVkdWxlciAoY3JlZGl0KQ0KKFhFTikgRGV0
ZWN0ZWQgMzIwMC4yMDAgTUh6IHByb2Nlc3Nvci4NCihYRU4pIEluaXRpbmcgbWVtb3J5IHNo
YXJpbmcuDQooWEVOKSBBTUQgRmFtMTBoIG1hY2hpbmUgY2hlY2sgcmVwb3J0aW5nIGVuYWJs
ZWQNCihYRU4pIFBDSTogTUNGRyBjb25maWd1cmF0aW9uIDA6IGJhc2UgZTAwMDAwMDAgc2Vn
bWVudCAwMDAwIGJ1c2VzIDAwIC0gZmYNCihYRU4pIFBDSTogTm90IHVzaW5nIE1DRkcgZm9y
IHNlZ21lbnQgMDAwMCBidXMgMDAtZmYNCihYRU4pIEFNRC1WaTogRm91bmQgTVNJIGNhcGFi
aWxpdHkgYmxvY2sgYXQgMHg1NA0KKFhFTikgQU1ELVZpOiBBQ1BJIFRhYmxlOg0KKFhFTikg
QU1ELVZpOiAgU2lnbmF0dXJlIElWUlMNCihYRU4pIEFNRC1WaTogIExlbmd0aCAweGY4DQoo
WEVOKSBBTUQtVmk6ICBSZXZpc2lvbiAweDENCihYRU4pIEFNRC1WaTogIENoZWNrU3VtIDB4
OTgNCihYRU4pIEFNRC1WaTogIE9FTV9JZCBBTUQgIA0KKFhFTikgQU1ELVZpOiAgT0VNX1Rh
YmxlX0lkIFJEODkwUw0KKFhFTikgQU1ELVZpOiAgT0VNX1JldmlzaW9uIDB4MjAyMDMxDQoo
WEVOKSBBTUQtVmk6ICBDcmVhdG9yX0lkIEFNRCANCihYRU4pIEFNRC1WaTogIENyZWF0b3Jf
UmV2aXNpb24gMHgwDQooWEVOKSBBTUQtVmk6IElWUlMgQmxvY2s6DQooWEVOKSBBTUQtVmk6
ICBUeXBlIDB4MTANCihYRU4pIEFNRC1WaTogIEZsYWdzIDB4M2UNCihYRU4pIEFNRC1WaTog
IExlbmd0aCAweGM4DQooWEVOKSBBTUQtVmk6ICBEZXZfSWQgMHgyDQooWEVOKSBBTUQtVmk6
IElWSEQgRGV2aWNlIEVudHJ5Og0KKFhFTikgQU1ELVZpOiAgVHlwZSAweDMNCihYRU4pIEFN
RC1WaTogIERldl9JZCAweDANCihYRU4pIEFNRC1WaTogIEZsYWdzIDB4MA0KKFhFTikgQU1E
LVZpOiAgRGV2X0lkIFJhbmdlOiAweDAgLT4gMHgyDQooWEVOKSBBTUQtVmk6IElWSEQgRGV2
aWNlIEVudHJ5Og0KKFhFTikgQU1ELVZpOiAgVHlwZSAweDINCihYRU4pIEFNRC1WaTogIERl
dl9JZCAweDEwDQooWEVOKSBBTUQtVmk6ICBGbGFncyAweDANCihYRU4pIEFNRC1WaTogSVZI
RCBEZXZpY2UgRW50cnk6DQooWEVOKSBBTUQtVmk6ICBUeXBlIDB4Mg0KKFhFTikgQU1ELVZp
OiAgRGV2X0lkIDB4YTAwDQooWEVOKSBBTUQtVmk6ICBGbGFncyAweDANCihYRU4pIEFNRC1W
aTogSVZIRCBEZXZpY2UgRW50cnk6DQooWEVOKSBBTUQtVmk6ICBUeXBlIDB4Mg0KKFhFTikg
QU1ELVZpOiAgRGV2X0lkIDB4MTgNCihYRU4pIEFNRC1WaTogIEZsYWdzIDB4MA0KKFhFTikg
QU1ELVZpOiBJVkhEIERldmljZSBFbnRyeToNCihYRU4pIEFNRC1WaTogIFR5cGUgMHgzDQoo
WEVOKSBBTUQtVmk6ICBEZXZfSWQgMHg5MDANCihYRU4pIEFNRC1WaTogIEZsYWdzIDB4MA0K
KFhFTikgQU1ELVZpOiAgRGV2X0lkIFJhbmdlOiAweDkwMCAtPiAweDkwNw0KKFhFTikgQU1E
LVZpOiBJVkhEIERldmljZSBFbnRyeToNCihYRU4pIEFNRC1WaTogIFR5cGUgMHgyDQooWEVO
KSBBTUQtVmk6ICBEZXZfSWQgMHgyOA0KKFhFTikgQU1ELVZpOiAgRmxhZ3MgMHgwDQooWEVO
KSBBTUQtVmk6IElWSEQgRGV2aWNlIEVudHJ5Og0KKFhFTikgQU1ELVZpOiAgVHlwZSAweDIN
CihYRU4pIEFNRC1WaTogIERldl9JZCAweDgwMA0KKFhFTikgQU1ELVZpOiAgRmxhZ3MgMHgw
DQooWEVOKSBBTUQtVmk6IElWSEQgRGV2aWNlIEVudHJ5Og0KKFhFTikgQU1ELVZpOiAgVHlw
ZSAweDINCihYRU4pIEFNRC1WaTogIERldl9JZCAweDMwDQooWEVOKSBBTUQtVmk6ICBGbGFn
cyAweDANCihYRU4pIEFNRC1WaTogSVZIRCBEZXZpY2UgRW50cnk6DQooWEVOKSBBTUQtVmk6
ICBUeXBlIDB4Mg0KKFhFTikgQU1ELVZpOiAgRGV2X0lkIDB4NzAwDQooWEVOKSBBTUQtVmk6
ICBGbGFncyAweDANCihYRU4pIEFNRC1WaTogSVZIRCBEZXZpY2UgRW50cnk6DQooWEVOKSBB
TUQtVmk6ICBUeXBlIDB4Mg0KKFhFTikgQU1ELVZpOiAgRGV2X0lkIDB4NTANCihYRU4pIEFN
RC1WaTogIEZsYWdzIDB4MA0KKFhFTikgQU1ELVZpOiBJVkhEIERldmljZSBFbnRyeToNCihY
RU4pIEFNRC1WaTogIFR5cGUgMHgyDQooWEVOKSBBTUQtVmk6ICBEZXZfSWQgMHg2MDANCihY
RU4pIEFNRC1WaTogIEZsYWdzIDB4MA0KKFhFTikgQU1ELVZpOiBJVkhEIERldmljZSBFbnRy
eToNCihYRU4pIEFNRC1WaTogIFR5cGUgMHgyDQooWEVOKSBBTUQtVmk6ICBEZXZfSWQgMHg1
OA0KKFhFTikgQU1ELVZpOiAgRmxhZ3MgMHgwDQooWEVOKSBBTUQtVmk6IElWSEQgRGV2aWNl
IEVudHJ5Og0KKFhFTikgQU1ELVZpOiAgVHlwZSAweDMNCihYRU4pIEFNRC1WaTogIERldl9J
ZCAweDUwMA0KKFhFTikgQU1ELVZpOiAgRmxhZ3MgMHgwDQooWEVOKSBBTUQtVmk6ICBEZXZf
SWQgUmFuZ2U6IDB4NTAwIC0+IDB4NTAxDQooWEVOKSBBTUQtVmk6IElWSEQgRGV2aWNlIEVu
dHJ5Og0KKFhFTikgQU1ELVZpOiAgVHlwZSAweDINCihYRU4pIEFNRC1WaTogIERldl9JZCAw
eDY4DQooWEVOKSBBTUQtVmk6ICBGbGFncyAweDANCihYRU4pIEFNRC1WaTogSVZIRCBEZXZp
Y2UgRW50cnk6DQooWEVOKSBBTUQtVmk6ICBUeXBlIDB4Mw0KKFhFTikgQU1ELVZpOiAgRGV2
X0lkIDB4NDAwDQooWEVOKSBBTUQtVmk6ICBGbGFncyAweDANCihYRU4pIEFNRC1WaTogIERl
dl9JZCBSYW5nZTogMHg0MDAgLT4gMHg0MDcNCihYRU4pIEFNRC1WaTogSVZIRCBEZXZpY2Ug
RW50cnk6DQooWEVOKSBBTUQtVmk6ICBUeXBlIDB4Mg0KKFhFTikgQU1ELVZpOiAgRGV2X0lk
IDB4ODgNCihYRU4pIEFNRC1WaTogIEZsYWdzIDB4MA0KKFhFTikgQU1ELVZpOiBJVkhEIERl
dmljZSBFbnRyeToNCihYRU4pIEFNRC1WaTogIFR5cGUgMHgzDQooWEVOKSBBTUQtVmk6ICBE
ZXZfSWQgMHg5MA0KKFhFTikgQU1ELVZpOiAgRmxhZ3MgMHgwDQooWEVOKSBBTUQtVmk6ICBE
ZXZfSWQgUmFuZ2U6IDB4OTAgLT4gMHg5Mg0KKFhFTikgQU1ELVZpOiBJVkhEIERldmljZSBF
bnRyeToNCihYRU4pIEFNRC1WaTogIFR5cGUgMHgzDQooWEVOKSBBTUQtVmk6ICBEZXZfSWQg
MHg5OA0KKFhFTikgQU1ELVZpOiAgRmxhZ3MgMHgwDQooWEVOKSBBTUQtVmk6ICBEZXZfSWQg
UmFuZ2U6IDB4OTggLT4gMHg5YQ0KKFhFTikgQU1ELVZpOiBJVkhEIERldmljZSBFbnRyeToN
CihYRU4pIEFNRC1WaTogIFR5cGUgMHgyDQooWEVOKSBBTUQtVmk6ICBEZXZfSWQgMHhhMA0K
KFhFTikgQU1ELVZpOiAgRmxhZ3MgMHhkNw0KKFhFTikgQU1ELVZpOiBJVkhEIERldmljZSBF
bnRyeToNCihYRU4pIEFNRC1WaTogIFR5cGUgMHgyDQooWEVOKSBBTUQtVmk6ICBEZXZfSWQg
MHhhMQ0KKFhFTikgQU1ELVZpOiAgRmxhZ3MgMHgwDQooWEVOKSBBTUQtVmk6IElWSEQgRGV2
aWNlIEVudHJ5Og0KKFhFTikgQU1ELVZpOiAgVHlwZSAweDINCihYRU4pIEFNRC1WaTogIERl
dl9JZCAweGEyDQooWEVOKSBBTUQtVmk6ICBGbGFncyAweDANCihYRU4pIEFNRC1WaTogSVZI
RCBEZXZpY2UgRW50cnk6DQooWEVOKSBBTUQtVmk6ICBUeXBlIDB4Mg0KKFhFTikgQU1ELVZp
OiAgRGV2X0lkIDB4YTMNCihYRU4pIEFNRC1WaTogIEZsYWdzIDB4MA0KKFhFTikgQU1ELVZp
OiBJVkhEIERldmljZSBFbnRyeToNCihYRU4pIEFNRC1WaTogIFR5cGUgMHgyDQooWEVOKSBB
TUQtVmk6ICBEZXZfSWQgMHhhNA0KKFhFTikgQU1ELVZpOiAgRmxhZ3MgMHgwDQooWEVOKSBB
TUQtVmk6IElWSEQgRGV2aWNlIEVudHJ5Og0KKFhFTikgQU1ELVZpOiAgVHlwZSAweDANCihY
RU4pIEFNRC1WaTogIERldl9JZCAweDANCihYRU4pIEFNRC1WaTogIEZsYWdzIDB4MA0KKFhF
TikgQU1ELVZpOiBJVkhEIERldmljZSBFbnRyeToNCihYRU4pIEFNRC1WaTogIFR5cGUgMHg0
Mw0KKFhFTikgQU1ELVZpOiAgRGV2X0lkIDB4MzAwDQooWEVOKSBBTUQtVmk6ICBGbGFncyAw
eDANCihYRU4pIEFNRC1WaTogIERldl9JZCBSYW5nZTogMHgzMDAgLT4gMHgzZmYNCihYRU4p
IEFNRC1WaTogIERldl9JZCBBbGlhczogMHhhNA0KKFhFTikgQU1ELVZpOiBJVkhEIERldmlj
ZSBFbnRyeToNCihYRU4pIEFNRC1WaTogIFR5cGUgMHgyDQooWEVOKSBBTUQtVmk6ICBEZXZf
SWQgMHhhNQ0KKFhFTikgQU1ELVZpOiAgRmxhZ3MgMHgwDQooWEVOKSBBTUQtVmk6IElWSEQg
RGV2aWNlIEVudHJ5Og0KKFhFTikgQU1ELVZpOiAgVHlwZSAweDINCihYRU4pIEFNRC1WaTog
IERldl9JZCAweGE4DQooWEVOKSBBTUQtVmk6ICBGbGFncyAweDANCihYRU4pIEFNRC1WaTog
SVZIRCBEZXZpY2UgRW50cnk6DQooWEVOKSBBTUQtVmk6ICBUeXBlIDB4Mg0KKFhFTikgQU1E
LVZpOiAgRGV2X0lkIDB4YTkNCihYRU4pIEFNRC1WaTogIEZsYWdzIDB4MA0KKFhFTikgQU1E
LVZpOiBJVkhEIERldmljZSBFbnRyeToNCihYRU4pIEFNRC1WaTogIFR5cGUgMHgyDQooWEVO
KSBBTUQtVmk6ICBEZXZfSWQgMHgxMDANCihYRU4pIEFNRC1WaTogIEZsYWdzIDB4MA0KKFhF
TikgQU1ELVZpOiBJVkhEIERldmljZSBFbnRyeToNCihYRU4pIEFNRC1WaTogIFR5cGUgMHgz
DQooWEVOKSBBTUQtVmk6ICBEZXZfSWQgMHhiMA0KKFhFTikgQU1ELVZpOiAgRmxhZ3MgMHgw
DQooWEVOKSBBTUQtVmk6ICBEZXZfSWQgUmFuZ2U6IDB4YjAgLT4gMHhiMg0KKFhFTikgQU1E
LVZpOiBJVkhEIERldmljZSBFbnRyeToNCihYRU4pIEFNRC1WaTogIFR5cGUgMHgwDQooWEVO
KSBBTUQtVmk6ICBEZXZfSWQgMHgwDQooWEVOKSBBTUQtVmk6ICBGbGFncyAweDANCihYRU4p
IEFNRC1WaTogSVZIRCBEZXZpY2UgRW50cnk6DQooWEVOKSBBTUQtVmk6ICBUeXBlIDB4NDgN
CihYRU4pIEFNRC1WaTogIERldl9JZCAweDANCihYRU4pIEFNRC1WaTogIEZsYWdzIDB4ZDcN
CihYRU4pIEFNRC1WaTogSVZIRCBEZXZpY2UgRW50cnk6DQooWEVOKSBBTUQtVmk6ICBUeXBl
IDB4NDgNCihYRU4pIEFNRC1WaTogIERldl9JZCAweDANCihYRU4pIEFNRC1WaTogIEZsYWdz
IDB4MA0KKFhFTikgQU1ELVZpOiBJT01NVSAwIEVuYWJsZWQuDQooWEVOKSBBTUQtVmk6IEVu
YWJsaW5nIGdsb2JhbCB2ZWN0b3IgbWFwDQooWEVOKSBJL08gdmlydHVhbGlzYXRpb24gZW5h
YmxlZA0KKFhFTikgIC0gRG9tMCBtb2RlOiBSZWxheGVkDQooWEVOKSBHZXR0aW5nIFZFUlNJ
T046IDgwMDUwMDEwDQooWEVOKSBHZXR0aW5nIFZFUlNJT046IDgwMDUwMDEwDQooWEVOKSBH
ZXR0aW5nIElEOiAwDQooWEVOKSBHZXR0aW5nIExWVDA6IDcwMA0KKFhFTikgR2V0dGluZyBM
VlQxOiA0MDANCihYRU4pIGVuYWJsZWQgRXh0SU5UIG9uIENQVSMwDQooWEVOKSBFU1IgdmFs
dWUgYmVmb3JlIGVuYWJsaW5nIHZlY3RvcjogMHgwMDAwMDAwNCAgYWZ0ZXI6IDB4MDAwMDAw
MDANCihYRU4pIEVOQUJMSU5HIElPLUFQSUMgSVJRcw0KKFhFTikgIC0+IFVzaW5nIG5ldyBB
Q0sgbWV0aG9kDQooWEVOKSBpbml0IElPX0FQSUMgSVJRcw0KKFhFTikgIElPLUFQSUMgKGFw
aWNpZC1waW4pIDYtMCwgNi0xNiwgNi0xNywgNi0xOCwgNi0xOSwgNi0yMCwgNi0yMSwgNi0y
MiwgNi0yMywgNy0wLCA3LTEsIDctMiwgNy0zLCA3LTQsIDctNSwgNy02LCA3LTcsIDctOCwg
Ny05LCA3LTEwLCA3LTExLCA3LTEyLCA3LTEzLCA3LTE0LCA3LTE1LCA3LTE2LCA3LTE3LCA3
LTE4LCA3LTE5LCA3LTIwLCA3LTIxLCA3LTIyLCA3LTIzLCA3LTI0LCA3LTI1LCA3LTI2LCA3
LTI3LCA3LTI4LCA3LTI5LCA3LTMwLCA3LTMxIG5vdCBjb25uZWN0ZWQuDQooWEVOKSAuLlRJ
TUVSOiB2ZWN0b3I9MHhGMCBhcGljMT0wIHBpbjE9MiBhcGljMj0tMSBwaW4yPS0xDQooWEVO
KSBudW1iZXIgb2YgTVAgSVJRIHNvdXJjZXM6IDE1Lg0KKFhFTikgbnVtYmVyIG9mIElPLUFQ
SUMgIzYgcmVnaXN0ZXJzOiAyNC4NCihYRU4pIG51bWJlciBvZiBJTy1BUElDICM3IHJlZ2lz
dGVyczogMzIuDQooWEVOKSB0ZXN0aW5nIHRoZSBJTyBBUElDLi4uLi4uLi4uLi4uLi4uLi4u
Li4uLi4NCihYRU4pIElPIEFQSUMgIzYuLi4uLi4NCihYRU4pIC4uLi4gcmVnaXN0ZXIgIzAw
OiAwNjAwMDAwMA0KKFhFTikgLi4uLi4uLiAgICA6IHBoeXNpY2FsIEFQSUMgaWQ6IDA2DQoo
WEVOKSAuLi4uLi4uICAgIDogRGVsaXZlcnkgVHlwZTogMA0KKFhFTikgLi4uLi4uLiAgICA6
IExUUyAgICAgICAgICA6IDANCihYRU4pIC4uLi4gcmVnaXN0ZXIgIzAxOiAwMDE3ODAyMQ0K
KFhFTikgLi4uLi4uLiAgICAgOiBtYXggcmVkaXJlY3Rpb24gZW50cmllczogMDAxNw0KKFhF
TikgLi4uLi4uLiAgICAgOiBQUlEgaW1wbGVtZW50ZWQ6IDENCihYRU4pIC4uLi4uLi4gICAg
IDogSU8gQVBJQyB2ZXJzaW9uOiAwMDIxDQooWEVOKSAuLi4uIHJlZ2lzdGVyICMwMjogMDYw
MDAwMDANCihYRU4pIC4uLi4uLi4gICAgIDogYXJiaXRyYXRpb246IDA2DQooWEVOKSAuLi4u
IHJlZ2lzdGVyICMwMzogMDcwMDAwMDANCihYRU4pIC4uLi4uLi4gICAgIDogQm9vdCBEVCAg
ICA6IDANCihYRU4pIC4uLi4gSVJRIHJlZGlyZWN0aW9uIHRhYmxlOg0KKFhFTikgIE5SIExv
ZyBQaHkgTWFzayBUcmlnIElSUiBQb2wgU3RhdCBEZXN0IERlbGkgVmVjdDogICANCihYRU4p
ICAwMCAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwDQooWEVO
KSAgMDEgMDAxIDAxICAwICAgIDAgICAgMCAgIDAgICAwICAgIDEgICAgMSAgICAzMA0KKFhF
TikgIDAyIDAwMSAwMSAgMCAgICAwICAgIDAgICAwICAgMCAgICAxICAgIDEgICAgRjANCihY
RU4pICAwMyAwMDEgMDEgIDAgICAgMCAgICAwICAgMCAgIDAgICAgMSAgICAxICAgIDM4DQoo
WEVOKSAgMDQgMDAxIDAxICAwICAgIDAgICAgMCAgIDAgICAwICAgIDEgICAgMSAgICBGMQ0K
KFhFTikgIDA1IDAwMSAwMSAgMCAgICAwICAgIDAgICAwICAgMCAgICAxICAgIDEgICAgNDAN
CihYRU4pICAwNiAwMDEgMDEgIDAgICAgMCAgICAwICAgMCAgIDAgICAgMSAgICAxICAgIDQ4
DQooWEVOKSAgMDcgMDAxIDAxICAwICAgIDAgICAgMCAgIDAgICAwICAgIDEgICAgMSAgICA1
MA0KKFhFTikgIDA4IDAwMSAwMSAgMCAgICAwICAgIDAgICAwICAgMCAgICAxICAgIDEgICAg
NTgNCihYRU4pICAwOSAwMDEgMDEgIDEgICAgMSAgICAwICAgMSAgIDAgICAgMSAgICAxICAg
IDYwDQooWEVOKSAgMGEgMDAxIDAxICAwICAgIDAgICAgMCAgIDAgICAwICAgIDEgICAgMSAg
ICA2OA0KKFhFTikgIDBiIDAwMSAwMSAgMCAgICAwICAgIDAgICAwICAgMCAgICAxICAgIDEg
ICAgNzANCihYRU4pICAwYyAwMDEgMDEgIDAgICAgMCAgICAwICAgMCAgIDAgICAgMSAgICAx
ICAgIDc4DQooWEVOKSAgMGQgMDAxIDAxICAwICAgIDAgICAgMCAgIDAgICAwICAgIDEgICAg
MSAgICA4OA0KKFhFTikgIDBlIDAwMSAwMSAgMCAgICAwICAgIDAgICAwICAgMCAgICAxICAg
IDEgICAgOTANCihYRU4pICAwZiAwMDEgMDEgIDAgICAgMCAgICAwICAgMCAgIDAgICAgMSAg
ICAxICAgIDk4DQooWEVOKSAgMTAgMDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAwICAgIDAg
ICAgMCAgICAwMA0KKFhFTikgIDExIDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAw
ICAgIDAgICAgMDANCihYRU4pICAxMiAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAg
MCAgICAwICAgIDAwDQooWEVOKSAgMTMgMDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAwICAg
IDAgICAgMCAgICAwMA0KKFhFTikgIDE0IDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAg
ICAwICAgIDAgICAgMDANCihYRU4pICAxNSAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAg
ICAgMCAgICAwICAgIDAwDQooWEVOKSAgMTYgMDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAw
ICAgIDAgICAgMCAgICAwMA0KKFhFTikgIDE3IDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAg
MCAgICAwICAgIDAgICAgMDANCihYRU4pIElPIEFQSUMgIzcuLi4uLi4NCihYRU4pIC4uLi4g
cmVnaXN0ZXIgIzAwOiAwNzAwMDAwMA0KKFhFTikgLi4uLi4uLiAgICA6IHBoeXNpY2FsIEFQ
SUMgaWQ6IDA3DQooWEVOKSAuLi4uLi4uICAgIDogRGVsaXZlcnkgVHlwZTogMA0KKFhFTikg
Li4uLi4uLiAgICA6IExUUyAgICAgICAgICA6IDANCihYRU4pIC4uLi4gcmVnaXN0ZXIgIzAx
OiAwMDFGODAyMQ0KKFhFTikgLi4uLi4uLiAgICAgOiBtYXggcmVkaXJlY3Rpb24gZW50cmll
czogMDAxRg0KKFhFTikgLi4uLi4uLiAgICAgOiBQUlEgaW1wbGVtZW50ZWQ6IDENCihYRU4p
IC4uLi4uLi4gICAgIDogSU8gQVBJQyB2ZXJzaW9uOiAwMDIxDQooWEVOKSAuLi4uIHJlZ2lz
dGVyICMwMjogMDAwMDAwMDANCihYRU4pIC4uLi4uLi4gICAgIDogYXJiaXRyYXRpb246IDAw
DQooWEVOKSAuLi4uIElSUSByZWRpcmVjdGlvbiB0YWJsZToNCihYRU4pICBOUiBMb2cgUGh5
IE1hc2sgVHJpZyBJUlIgUG9sIFN0YXQgRGVzdCBEZWxpIFZlY3Q6ICAgDQooWEVOKSAgMDAg
MDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAwICAgIDAgICAgMCAgICAwMA0KKFhFTikgIDAx
IDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDAgICAgMDANCihYRU4pICAw
MiAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwDQooWEVOKSAg
MDMgMDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAwICAgIDAgICAgMCAgICAwMA0KKFhFTikg
IDA0IDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDAgICAgMDANCihYRU4p
ICAwNSAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwDQooWEVO
KSAgMDYgMDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAwICAgIDAgICAgMCAgICAwMA0KKFhF
TikgIDA3IDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDAgICAgMDANCihY
RU4pICAwOCAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwDQoo
WEVOKSAgMDkgMDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAwICAgIDAgICAgMCAgICAwMA0K
KFhFTikgIDBhIDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDAgICAgMDAN
CihYRU4pICAwYiAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAw
DQooWEVOKSAgMGMgMDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAwICAgIDAgICAgMCAgICAw
MA0KKFhFTikgIDBkIDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDAgICAg
MDANCihYRU4pICAwZSAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAg
IDAwDQooWEVOKSAgMGYgMDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAwICAgIDAgICAgMCAg
ICAwMA0KKFhFTikgIDEwIDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDAg
ICAgMDANCihYRU4pICAxMSAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAw
ICAgIDAwDQooWEVOKSAgMTIgMDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAwICAgIDAgICAg
MCAgICAwMA0KKFhFTikgIDEzIDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAg
IDAgICAgMDANCihYRU4pICAxNCAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAg
ICAwICAgIDAwDQooWEVOKSAgMTUgMDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAwICAgIDAg
ICAgMCAgICAwMA0KKFhFTikgIDE2IDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAw
ICAgIDAgICAgMDANCihYRU4pICAxNyAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAg
MCAgICAwICAgIDAwDQooWEVOKSAgMTggMDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAwICAg
IDAgICAgMCAgICAwMA0KKFhFTikgIDE5IDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAg
ICAwICAgIDAgICAgMDANCihYRU4pICAxYSAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAg
ICAgMCAgICAwICAgIDAwDQooWEVOKSAgMWIgMDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAw
ICAgIDAgICAgMCAgICAwMA0KKFhFTikgIDFjIDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAg
MCAgICAwICAgIDAgICAgMDANCihYRU4pICAxZCAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAg
IDAgICAgMCAgICAwICAgIDAwDQooWEVOKSAgMWUgMDAwIDAwICAxICAgIDAgICAgMCAgIDAg
ICAwICAgIDAgICAgMCAgICAwMA0KKFhFTikgIDFmIDAwMCAwMCAgMSAgICAwICAgIDAgICAw
ICAgMCAgICAwICAgIDAgICAgMDANCihYRU4pIFVzaW5nIHZlY3Rvci1iYXNlZCBpbmRleGlu
Zw0KKFhFTikgSVJRIHRvIHBpbiBtYXBwaW5nczoNCihYRU4pIElSUTI0MCAtPiAwOjINCihY
RU4pIElSUTQ4IC0+IDA6MQ0KKFhFTikgSVJRNTYgLT4gMDozDQooWEVOKSBJUlEyNDEgLT4g
MDo0DQooWEVOKSBJUlE2NCAtPiAwOjUNCihYRU4pIElSUTcyIC0+IDA6Ng0KKFhFTikgSVJR
ODAgLT4gMDo3DQooWEVOKSBJUlE4OCAtPiAwOjgNCihYRU4pIElSUTk2IC0+IDA6OQ0KKFhF
TikgSVJRMTA0IC0+IDA6MTANCihYRU4pIElSUTExMiAtPiAwOjExDQooWEVOKSBJUlExMjAg
LT4gMDoxMg0KKFhFTikgSVJRMTM2IC0+IDA6MTMNCihYRU4pIElSUTE0NCAtPiAwOjE0DQoo
WEVOKSBJUlExNTIgLT4gMDoxNQ0KKFhFTikgLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u
Li4uLi4uLi4uIGRvbmUuDQooWEVOKSBVc2luZyBsb2NhbCBBUElDIHRpbWVyIGludGVycnVw
dHMuDQooWEVOKSBjYWxpYnJhdGluZyBBUElDIHRpbWVyIC4uLg0KKFhFTikgLi4uLi4gQ1BV
IGNsb2NrIHNwZWVkIGlzIDMyMDAuMTYwOCBNSHouDQooWEVOKSAuLi4uLiBob3N0IGJ1cyBj
bG9jayBzcGVlZCBpcyAyMDAuMDA5OSBNSHouDQooWEVOKSAuLi4uLiBidXNfc2NhbGUgPSAw
eDAwMDBDQ0Q3DQooWEVOKSBbMjAxMi0wOS0yNCAwNjozOToyOV0gUGxhdGZvcm0gdGltZXIg
aXMgMTQuMzE4TUh6IEhQRVQNCihYRU4pIFsyMDEyLTA5LTI0IDA2OjM5OjI5XSBBbGxvY2F0
ZWQgY29uc29sZSByaW5nIG9mIDY0IEtpQi4NCihYRU4pIFsyMDEyLTA5LTI0IDA2OjM5OjI5
XSBIVk06IEFTSURzIGVuYWJsZWQuDQooWEVOKSBbMjAxMi0wOS0yNCAwNjozOToyOV0gU1ZN
OiBTdXBwb3J0ZWQgYWR2YW5jZWQgZmVhdHVyZXM6DQooWEVOKSBbMjAxMi0wOS0yNCAwNjoz
OToyOV0gIC0gTmVzdGVkIFBhZ2UgVGFibGVzIChOUFQpDQooWEVOKSBbMjAxMi0wOS0yNCAw
NjozOToyOV0gIC0gTGFzdCBCcmFuY2ggUmVjb3JkIChMQlIpIFZpcnR1YWxpc2F0aW9uDQoo
WEVOKSBbMjAxMi0wOS0yNCAwNjozOToyOV0gIC0gTmV4dC1SSVAgU2F2ZWQgb24gI1ZNRVhJ
VA0KKFhFTikgWzIwMTItMDktMjQgMDY6Mzk6MjldICAtIFBhdXNlLUludGVyY2VwdCBGaWx0
ZXINCihYRU4pIFsyMDEyLTA5LTI0IDA2OjM5OjI5XSBIVk06IFNWTSBlbmFibGVkDQooWEVO
KSBbMjAxMi0wOS0yNCAwNjozOToyOV0gSFZNOiBIYXJkd2FyZSBBc3Npc3RlZCBQYWdpbmcg
KEhBUCkgZGV0ZWN0ZWQNCihYRU4pIFsyMDEyLTA5LTI0IDA2OjM5OjI5XSBIVk06IEhBUCBw
YWdlIHNpemVzOiA0a0IsIDJNQiwgMUdCDQooWEVOKSBbMjAxMi0wOS0yNCAwNjozOToyOF0g
bWFza2VkIEV4dElOVCBvbiBDUFUjMQ0KKFhFTikgWzIwMTItMDktMjQgMDY6Mzk6MjldIG1p
Y3JvY29kZTogY29sbGVjdF9jcHVfaW5mbzogcGF0Y2hfaWQ9MHgxMDAwMGJmDQooWEVOKSBb
MjAxMi0wOS0yNCAwNjozOToyOF0gbWFza2VkIEV4dElOVCBvbiBDUFUjMg0KKFhFTikgWzIw
MTItMDktMjQgMDY6Mzk6MjldIG1pY3JvY29kZTogY29sbGVjdF9jcHVfaW5mbzogcGF0Y2hf
aWQ9MHgxMDAwMGJmDQooWEVOKSBbMjAxMi0wOS0yNCAwNjozOToyOF0gbWFza2VkIEV4dElO
VCBvbiBDUFUjMw0KKFhFTikgWzIwMTItMDktMjQgMDY6Mzk6MjldIG1pY3JvY29kZTogY29s
bGVjdF9jcHVfaW5mbzogcGF0Y2hfaWQ9MHgxMDAwMGJmDQooWEVOKSBbMjAxMi0wOS0yNCAw
NjozOToyOF0gbWFza2VkIEV4dElOVCBvbiBDUFUjNA0KKFhFTikgWzIwMTItMDktMjQgMDY6
Mzk6MzBdIG1pY3JvY29kZTogY29sbGVjdF9jcHVfaW5mbzogcGF0Y2hfaWQ9MHgxMDAwMGJm
DQooWEVOKSBbMjAxMi0wOS0yNCAwNjozOToyOF0gbWFza2VkIEV4dElOVCBvbiBDUFUjNQ0K
KFhFTikgWzIwMTItMDktMjQgMDY6Mzk6MzBdIEJyb3VnaHQgdXAgNiBDUFVzDQooWEVOKSBb
MjAxMi0wOS0yNCAwNjozOTozMF0gbWljcm9jb2RlOiBjb2xsZWN0X2NwdV9pbmZvOiBwYXRj
aF9pZD0weDEwMDAwYmYNCihYRU4pIFsyMDEyLTA5LTI0IDA2OjM5OjMwXSBIUEVUJ3MgTVNJ
IG1vZGUgaGFzbid0IGJlZW4gc3VwcG9ydGVkIHdoZW4gSW50ZXJydXB0IFJlbWFwcGluZyBp
cyBlbmFibGVkLg0KKFhFTikgWzIwMTItMDktMjQgMDY6Mzk6MzBdIEFDUEkgc2xlZXAgbW9k
ZXM6IFMzDQooWEVOKSBbMjAxMi0wOS0yNCAwNjozOTozMF0gTUNBOiBVc2UgaHcgdGhyZXNo
b2xkaW5nIHRvIGFkanVzdCBwb2xsaW5nIGZyZXF1ZW5jeQ0KKFhFTikgWzIwMTItMDktMjQg
MDY6Mzk6MzBdIG1jaGVja19wb2xsOiBNYWNoaW5lIGNoZWNrIHBvbGxpbmcgdGltZXIgc3Rh
cnRlZC4NCihYRU4pIFsyMDEyLTA5LTI0IDA2OjM5OjMwXSBYZW5vcHJvZmlsZTogRmFpbGVk
IHRvIHNldHVwIElCUyBMVlQgb2Zmc2V0LCBJQlNDVEwgPSAweGZmZmZmZmZmDQooWEVOKSBb
MjAxMi0wOS0yNCAwNjozOTozMF0gKioqIExPQURJTkcgRE9NQUlOIDAgKioqDQooWEVOKSBb
MjAxMi0wOS0yNCAwNjozOTozMF0gZWxmX3BhcnNlX2JpbmFyeTogcGhkcjogcGFkZHI9MHgx
MDAwMDAwIG1lbXN6PTB4ZDZhMDAwDQooWEVOKSBbMjAxMi0wOS0yNCAwNjozOTozMF0gZWxm
X3BhcnNlX2JpbmFyeTogcGhkcjogcGFkZHI9MHgxZTAwMDAwIG1lbXN6PTB4ZGIwZTgNCihY
RU4pIFsyMDEyLTA5LTI0IDA2OjM5OjMwXSBlbGZfcGFyc2VfYmluYXJ5OiBwaGRyOiBwYWRk
cj0weDFlZGMwMDAgbWVtc3o9MHgxM2NjMA0KKFhFTikgWzIwMTItMDktMjQgMDY6Mzk6MzBd
IGVsZl9wYXJzZV9iaW5hcnk6IHBoZHI6IHBhZGRyPTB4MWVmMDAwMCBtZW1zej0weGRlNTAw
MA0KKFhFTikgWzIwMTItMDktMjQgMDY6Mzk6MzBdIGVsZl9wYXJzZV9iaW5hcnk6IG1lbW9y
eTogMHgxMDAwMDAwIC0+IDB4MmNkNTAwMA0KKFhFTikgWzIwMTItMDktMjQgMDY6Mzk6MzBd
IGVsZl94ZW5fcGFyc2Vfbm90ZTogR1VFU1RfT1MgPSAibGludXgiDQooWEVOKSBbMjAxMi0w
OS0yNCAwNjozOTozMF0gZWxmX3hlbl9wYXJzZV9ub3RlOiBHVUVTVF9WRVJTSU9OID0gIjIu
NiINCihYRU4pIFsyMDEyLTA5LTI0IDA2OjM5OjMwXSBlbGZfeGVuX3BhcnNlX25vdGU6IFhF
Tl9WRVJTSU9OID0gInhlbi0zLjAiDQooWEVOKSBbMjAxMi0wOS0yNCAwNjozOTozMF0gZWxm
X3hlbl9wYXJzZV9ub3RlOiBWSVJUX0JBU0UgPSAweGZmZmZmZmZmODAwMDAwMDANCihYRU4p
IFsyMDEyLTA5LTI0IDA2OjM5OjMwXSBlbGZfeGVuX3BhcnNlX25vdGU6IEVOVFJZID0gMHhm
ZmZmZmZmZjgxZWYwMjEwDQooWEVOKSBbMjAxMi0wOS0yNCAwNjozOTozMF0gZWxmX3hlbl9w
YXJzZV9ub3RlOiBIWVBFUkNBTExfUEFHRSA9IDB4ZmZmZmZmZmY4MTAwMTAwMA0KKFhFTikg
WzIwMTItMDktMjQgMDY6Mzk6MzBdIGVsZl94ZW5fcGFyc2Vfbm90ZTogRkVBVFVSRVMgPSAi
IXdyaXRhYmxlX3BhZ2VfdGFibGVzfHBhZV9wZ2Rpcl9hYm92ZV80Z2IiDQooWEVOKSBbMjAx
Mi0wOS0yNCAwNjozOTozMF0gZWxmX3hlbl9wYXJzZV9ub3RlOiBQQUVfTU9ERSA9ICJ5ZXMi
DQooWEVOKSBbMjAxMi0wOS0yNCAwNjozOTozMF0gZWxmX3hlbl9wYXJzZV9ub3RlOiBMT0FE
RVIgPSAiZ2VuZXJpYyINCihYRU4pIFsyMDEyLTA5LTI0IDA2OjM5OjMwXSBlbGZfeGVuX3Bh
cnNlX25vdGU6IHVua25vd24geGVuIGVsZiBub3RlICgweGQpDQooWEVOKSBbMjAxMi0wOS0y
NCAwNjozOTozMF0gZWxmX3hlbl9wYXJzZV9ub3RlOiBTVVNQRU5EX0NBTkNFTCA9IDB4MQ0K
KFhFTikgWzIwMTItMDktMjQgMDY6Mzk6MzBdIGVsZl94ZW5fcGFyc2Vfbm90ZTogSFZfU1RB
UlRfTE9XID0gMHhmZmZmODAwMDAwMDAwMDAwDQooWEVOKSBbMjAxMi0wOS0yNCAwNjozOToz
MF0gZWxmX3hlbl9wYXJzZV9ub3RlOiBQQUREUl9PRkZTRVQgPSAweDANCihYRU4pIFsyMDEy
LTA5LTI0IDA2OjM5OjMwXSBlbGZfeGVuX2FkZHJfY2FsY19jaGVjazogYWRkcmVzc2VzOg0K
KFhFTikgWzIwMTItMDktMjQgMDY6Mzk6MzBdICAgICB2aXJ0X2Jhc2UgICAgICAgID0gMHhm
ZmZmZmZmZjgwMDAwMDAwDQooWEVOKSBbMjAxMi0wOS0yNCAwNjozOTozMF0gICAgIGVsZl9w
YWRkcl9vZmZzZXQgPSAweDANCihYRU4pIFsyMDEyLTA5LTI0IDA2OjM5OjMwXSAgICAgdmly
dF9vZmZzZXQgICAgICA9IDB4ZmZmZmZmZmY4MDAwMDAwMA0KKFhFTikgWzIwMTItMDktMjQg
MDY6Mzk6MzBdICAgICB2aXJ0X2tzdGFydCAgICAgID0gMHhmZmZmZmZmZjgxMDAwMDAwDQoo
WEVOKSBbMjAxMi0wOS0yNCAwNjozOTozMF0gICAgIHZpcnRfa2VuZCAgICAgICAgPSAweGZm
ZmZmZmZmODJjZDUwMDANCihYRU4pIFsyMDEyLTA5LTI0IDA2OjM5OjMwXSAgICAgdmlydF9l
bnRyeSAgICAgICA9IDB4ZmZmZmZmZmY4MWVmMDIxMA0KKFhFTikgWzIwMTItMDktMjQgMDY6
Mzk6MzBdICAgICBwMm1fYmFzZSAgICAgICAgID0gMHhmZmZmZmZmZmZmZmZmZmZmDQooWEVO
KSBbMjAxMi0wOS0yNCAwNjozOTozMF0gIFhlbiAga2VybmVsOiA2NC1iaXQsIGxzYiwgY29t
cGF0MzINCihYRU4pIFsyMDEyLTA5LTI0IDA2OjM5OjMwXSAgRG9tMCBrZXJuZWw6IDY0LWJp
dCwgUEFFLCBsc2IsIHBhZGRyIDB4MTAwMDAwMCAtPiAweDJjZDUwMDANCihYRU4pIFsyMDEy
LTA5LTI0IDA2OjM5OjMwXSBQSFlTSUNBTCBNRU1PUlkgQVJSQU5HRU1FTlQ6DQooWEVOKSBb
MjAxMi0wOS0yNCAwNjozOTozMF0gIERvbTAgYWxsb2MuOiAgIDAwMDAwMDAyNDAwMDAwMDAt
PjAwMDAwMDAyNDQwMDAwMDAgKDI0MjQyOCBwYWdlcyB0byBiZSBhbGxvY2F0ZWQpDQooWEVO
KSBbMjAxMi0wOS0yNCAwNjozOTozMF0gIEluaXQuIHJhbWRpc2s6IDAwMDAwMDAyNGYyZmMw
MDAtPjAwMDAwMDAyNGZmZmY4MDANCihYRU4pIFsyMDEyLTA5LTI0IDA2OjM5OjMwXSBWSVJU
VUFMIE1FTU9SWSBBUlJBTkdFTUVOVDoNCihYRU4pIFsyMDEyLTA5LTI0IDA2OjM5OjMwXSAg
TG9hZGVkIGtlcm5lbDogZmZmZmZmZmY4MTAwMDAwMC0+ZmZmZmZmZmY4MmNkNTAwMA0KKFhF
TikgWzIwMTItMDktMjQgMDY6Mzk6MzBdICBJbml0LiByYW1kaXNrOiBmZmZmZmZmZjgyY2Q1
MDAwLT5mZmZmZmZmZjgzOWQ4ODAwDQooWEVOKSBbMjAxMi0wOS0yNCAwNjozOTozMF0gIFBo
eXMtTWFjaCBtYXA6IGZmZmZmZmZmODM5ZDkwMDAtPmZmZmZmZmZmODNiZDkwMDANCihYRU4p
IFsyMDEyLTA5LTI0IDA2OjM5OjMwXSAgU3RhcnQgaW5mbzogICAgZmZmZmZmZmY4M2JkOTAw
MC0+ZmZmZmZmZmY4M2JkOTRiNA0KKFhFTikgWzIwMTItMDktMjQgMDY6Mzk6MzBdICBQYWdl
IHRhYmxlczogICBmZmZmZmZmZjgzYmRhMDAwLT5mZmZmZmZmZjgzYmZkMDAwDQooWEVOKSBb
MjAxMi0wOS0yNCAwNjozOTozMF0gIEJvb3Qgc3RhY2s6ICAgIGZmZmZmZmZmODNiZmQwMDAt
PmZmZmZmZmZmODNiZmUwMDANCihYRU4pIFsyMDEyLTA5LTI0IDA2OjM5OjMwXSAgVE9UQUw6
ICAgICAgICAgZmZmZmZmZmY4MDAwMDAwMC0+ZmZmZmZmZmY4NDAwMDAwMA0KKFhFTikgWzIw
MTItMDktMjQgMDY6Mzk6MzBdICBFTlRSWSBBRERSRVNTOiBmZmZmZmZmZjgxZWYwMjEwDQoo
WEVOKSBbMjAxMi0wOS0yNCAwNjozOTozMF0gRG9tMCBoYXMgbWF4aW11bSA2IFZDUFVzDQoo
WEVOKSBbMjAxMi0wOS0yNCAwNjozOTozMF0gZWxmX2xvYWRfYmluYXJ5OiBwaGRyIDAgYXQg
MHhmZmZmZmZmZjgxMDAwMDAwIC0+IDB4ZmZmZmZmZmY4MWQ2YTAwMA0KKFhFTikgWzIwMTIt
MDktMjQgMDY6Mzk6MzBdIGVsZl9sb2FkX2JpbmFyeTogcGhkciAxIGF0IDB4ZmZmZmZmZmY4
MWUwMDAwMCAtPiAweGZmZmZmZmZmODFlZGIwZTgNCihYRU4pIFsyMDEyLTA5LTI0IDA2OjM5
OjMwXSBlbGZfbG9hZF9iaW5hcnk6IHBoZHIgMiBhdCAweGZmZmZmZmZmODFlZGMwMDAgLT4g
MHhmZmZmZmZmZjgxZWVmY2MwDQooWEVOKSBbMjAxMi0wOS0yNCAwNjozOTozMF0gZWxmX2xv
YWRfYmluYXJ5OiBwaGRyIDMgYXQgMHhmZmZmZmZmZjgxZWYwMDAwIC0+IDB4ZmZmZmZmZmY4
MWY4OTAwMA0KKFhFTikgWzIwMTItMDktMjQgMDY6Mzk6MzBdIEFNRC1WaTogU2V0dXAgSS9P
IHBhZ2UgdGFibGU6IGRldmljZSBpZCA9IDB4MDAwMCwgcm9vdCB0YWJsZSA9IDB4MjRkODRk
MDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMgfCAwIDAgMCAwDQooWEVOKSBbMjAx
Mi0wOS0yNCAwNjozOTozMF0gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNl
IGlkID0gMHgwMDAyLCByb290IHRhYmxlID0gMHgyNGQ4NGQwMDAsIGRvbWFpbiA9IDAsIHBh
Z2luZyBtb2RlID0gMyB8IDAgMCAwIDANCihYRU4pIFsyMDEyLTA5LTI0IDA2OjM5OjMwXSBB
TUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweDAwMTAsIHJvb3Qg
dGFibGUgPSAweDI0ZDg0ZDAwMCwgZG9tYWluID0gMCwgcGFnaW5nIG1vZGUgPSAzIHwgMCAw
IDAgMA0KKFhFTikgWzIwMTItMDktMjQgMDY6Mzk6MzBdIEFNRC1WaTogU2V0dXAgSS9PIHBh
Z2UgdGFibGU6IGRldmljZSBpZCA9IDB4MDAxOCwgcm9vdCB0YWJsZSA9IDB4MjRkODRkMDAw
LCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMgfCAwIDAgMCAwDQooWEVOKSBbMjAxMi0w
OS0yNCAwNjozOTozMF0gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlk
ID0gMHgwMDI4LCByb290IHRhYmxlID0gMHgyNGQ4NGQwMDAsIGRvbWFpbiA9IDAsIHBhZ2lu
ZyBtb2RlID0gMyB8IDAgMCAwIDANCihYRU4pIFsyMDEyLTA5LTI0IDA2OjM5OjMwXSBBTUQt
Vmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweDAwMzAsIHJvb3QgdGFi
bGUgPSAweDI0ZDg0ZDAwMCwgZG9tYWluID0gMCwgcGFnaW5nIG1vZGUgPSAzIHwgMCAwIDAg
MA0KKFhFTikgWzIwMTItMDktMjQgMDY6Mzk6MzBdIEFNRC1WaTogU2V0dXAgSS9PIHBhZ2Ug
dGFibGU6IGRldmljZSBpZCA9IDB4MDA1MCwgcm9vdCB0YWJsZSA9IDB4MjRkODRkMDAwLCBk
b21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMgfCAwIDAgMCAwDQooWEVOKSBbMjAxMi0wOS0y
NCAwNjozOTozMF0gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0g
MHgwMDU4LCByb290IHRhYmxlID0gMHgyNGQ4NGQwMDAsIGRvbWFpbiA9IDAsIHBhZ2luZyBt
b2RlID0gMyB8IDAgMCAwIDANCihYRU4pIFsyMDEyLTA5LTI0IDA2OjM5OjMwXSBBTUQtVmk6
IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweDAwNjgsIHJvb3QgdGFibGUg
PSAweDI0ZDg0ZDAwMCwgZG9tYWluID0gMCwgcGFnaW5nIG1vZGUgPSAzIHwgMCAwIDAgMA0K
KFhFTikgWzIwMTItMDktMjQgMDY6Mzk6MzBdIEFNRC1WaTogU2V0dXAgSS9PIHBhZ2UgdGFi
bGU6IGRldmljZSBpZCA9IDB4MDA4OCwgcm9vdCB0YWJsZSA9IDB4MjRkODRkMDAwLCBkb21h
aW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMgfCAwIDAgMCAwDQooWEVOKSBbMjAxMi0wOS0yNCAw
NjozOTozMV0gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHgw
MDkwLCByb290IHRhYmxlID0gMHgyNGQ4NGQwMDAsIGRvbWFpbiA9IDAsIHBhZ2luZyBtb2Rl
ID0gMyB8IDAgMCAwIDANCihYRU4pIFsyMDEyLTA5LTI0IDA2OjM5OjMxXSBBTUQtVmk6IFNl
dHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweDAwOTIsIHJvb3QgdGFibGUgPSAw
eDI0ZDg0ZDAwMCwgZG9tYWluID0gMCwgcGFnaW5nIG1vZGUgPSAzIHwgMCAwIDAgMA0KKFhF
TikgWzIwMTItMDktMjQgMDY6Mzk6MzFdIEFNRC1WaTogU2V0dXAgSS9PIHBhZ2UgdGFibGU6
IGRldmljZSBpZCA9IDB4MDA5OCwgcm9vdCB0YWJsZSA9IDB4MjRkODRkMDAwLCBkb21haW4g
PSAwLCBwYWdpbmcgbW9kZSA9IDMgfCAwIDAgMCAwDQooWEVOKSBbMjAxMi0wOS0yNCAwNjoz
OTozMV0gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHgwMDlh
LCByb290IHRhYmxlID0gMHgyNGQ4NGQwMDAsIGRvbWFpbiA9IDAsIHBhZ2luZyBtb2RlID0g
MyB8IDAgMCAwIDANCihYRU4pIFsyMDEyLTA5LTI0IDA2OjM5OjMxXSBBTUQtVmk6IFNldHVw
IEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweDAwYTAsIHJvb3QgdGFibGUgPSAweDI0
ZDg0ZDAwMCwgZG9tYWluID0gMCwgcGFnaW5nIG1vZGUgPSAzIHwgMCAwIDAgMA0KKFhFTikg
WzIwMTItMDktMjQgMDY6Mzk6MzFdIEFNRC1WaTogU2V0dXAgSS9PIHBhZ2UgdGFibGU6IGRl
dmljZSBpZCA9IDB4MDBhMSwgcm9vdCB0YWJsZSA9IDB4MjRkODRkMDAwLCBkb21haW4gPSAw
LCBwYWdpbmcgbW9kZSA9IDMgfCAwIDAgMCAwDQooWEVOKSBbMjAxMi0wOS0yNCAwNjozOToz
MV0gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHgwMGEyLCBy
b290IHRhYmxlID0gMHgyNGQ4NGQwMDAsIGRvbWFpbiA9IDAsIHBhZ2luZyBtb2RlID0gMyB8
IDAgMCAwIDANCihYRU4pIFsyMDEyLTA5LTI0IDA2OjM5OjMxXSBBTUQtVmk6IFNldHVwIEkv
TyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweDAwYTMsIHJvb3QgdGFibGUgPSAweDI0ZDg0
ZDAwMCwgZG9tYWluID0gMCwgcGFnaW5nIG1vZGUgPSAzIHwgMCAwIDAgMA0KKFhFTikgWzIw
MTItMDktMjQgMDY6Mzk6MzFdIEFNRC1WaTogU2V0dXAgSS9PIHBhZ2UgdGFibGU6IGRldmlj
ZSBpZCA9IDB4MDBhNCwgcm9vdCB0YWJsZSA9IDB4MjRkODRkMDAwLCBkb21haW4gPSAwLCBw
YWdpbmcgbW9kZSA9IDMgfCAwIDAgMCAwDQooWEVOKSBbMjAxMi0wOS0yNCAwNjozOTozMV0g
QU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHgwMGE1LCByb290
IHRhYmxlID0gMHgyNGQ4NGQwMDAsIGRvbWFpbiA9IDAsIHBhZ2luZyBtb2RlID0gMyB8IDAg
MCAwIDANCihYRU4pIFsyMDEyLTA5LTI0IDA2OjM5OjMxXSBBTUQtVmk6IFNldHVwIEkvTyBw
YWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweDAwYTgsIHJvb3QgdGFibGUgPSAweDI0ZDg0ZDAw
MCwgZG9tYWluID0gMCwgcGFnaW5nIG1vZGUgPSAzIHwgMCAwIDAgMA0KKFhFTikgWzIwMTIt
MDktMjQgMDY6Mzk6MzFdIEFNRC1WaTogU2V0dXAgSS9PIHBhZ2UgdGFibGU6IGRldmljZSBp
ZCA9IDB4MDBiMCwgcm9vdCB0YWJsZSA9IDB4MjRkODRkMDAwLCBkb21haW4gPSAwLCBwYWdp
bmcgbW9kZSA9IDMgfCAwIDAgMCAwDQooWEVOKSBbMjAxMi0wOS0yNCAwNjozOTozMV0gQU1E
LVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHgwMGIyLCByb290IHRh
YmxlID0gMHgyNGQ4NGQwMDAsIGRvbWFpbiA9IDAsIHBhZ2luZyBtb2RlID0gMyB8IDAgMCAw
IDANCihYRU4pIFsyMDEyLTA5LTI0IDA2OjM5OjMxXSBBTUQtVmk6IE5vIGlvbW11IGZvciBk
ZXZpY2UgMDAwMDowMDoxOC4wDQooWEVOKSBbMjAxMi0wOS0yNCAwNjozOTozMV0gQU1ELVZp
OiBObyBpb21tdSBmb3IgZGV2aWNlIDAwMDA6MDA6MTguMQ0KKFhFTikgWzIwMTItMDktMjQg
MDY6Mzk6MzFdIEFNRC1WaTogTm8gaW9tbXUgZm9yIGRldmljZSAwMDAwOjAwOjE4LjINCihY
RU4pIFsyMDEyLTA5LTI0IDA2OjM5OjMxXSBBTUQtVmk6IE5vIGlvbW11IGZvciBkZXZpY2Ug
MDAwMDowMDoxOC4zDQooWEVOKSBbMjAxMi0wOS0yNCAwNjozOTozMV0gQU1ELVZpOiBObyBp
b21tdSBmb3IgZGV2aWNlIDAwMDA6MDA6MTguNA0KKFhFTikgWzIwMTItMDktMjQgMDY6Mzk6
MzFdIEFNRC1WaTogU2V0dXAgSS9PIHBhZ2UgdGFibGU6IGRldmljZSBpZCA9IDB4MDQwMCwg
cm9vdCB0YWJsZSA9IDB4MjRkODRkMDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMg
fCAwIDAgMCAwDQooWEVOKSBbMjAxMi0wOS0yNCAwNjozOTozMV0gQU1ELVZpOiBTZXR1cCBJ
L08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHgwNDAxLCByb290IHRhYmxlID0gMHgyNGQ4
NGQwMDAsIGRvbWFpbiA9IDAsIHBhZ2luZyBtb2RlID0gMyB8IDAgMCAwIDANCihYRU4pIFsy
MDEyLTA5LTI0IDA2OjM5OjMxXSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZp
Y2UgaWQgPSAweDA0MDIsIHJvb3QgdGFibGUgPSAweDI0ZDg0ZDAwMCwgZG9tYWluID0gMCwg
cGFnaW5nIG1vZGUgPSAzIHwgMCAwIDAgMA0KKFhFTikgWzIwMTItMDktMjQgMDY6Mzk6MzFd
IEFNRC1WaTogU2V0dXAgSS9PIHBhZ2UgdGFibGU6IGRldmljZSBpZCA9IDB4MDQwMywgcm9v
dCB0YWJsZSA9IDB4MjRkODRkMDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMgfCAw
IDAgMCAwDQooWEVOKSBbMjAxMi0wOS0yNCAwNjozOTozMV0gQU1ELVZpOiBTZXR1cCBJL08g
cGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHgwNDA0LCByb290IHRhYmxlID0gMHgyNGQ4NGQw
MDAsIGRvbWFpbiA9IDAsIHBhZ2luZyBtb2RlID0gMyB8IDAgMCAwIDANCihYRU4pIFsyMDEy
LTA5LTI0IDA2OjM5OjMxXSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2Ug
aWQgPSAweDA0MDUsIHJvb3QgdGFibGUgPSAweDI0ZDg0ZDAwMCwgZG9tYWluID0gMCwgcGFn
aW5nIG1vZGUgPSAzIHwgMCAwIDAgMA0KKFhFTikgWzIwMTItMDktMjQgMDY6Mzk6MzFdIEFN
RC1WaTogU2V0dXAgSS9PIHBhZ2UgdGFibGU6IGRldmljZSBpZCA9IDB4MDQwNiwgcm9vdCB0
YWJsZSA9IDB4MjRkODRkMDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMgfCAwIDAg
MCAwDQooWEVOKSBbMjAxMi0wOS0yNCAwNjozOTozMV0gQU1ELVZpOiBTZXR1cCBJL08gcGFn
ZSB0YWJsZTogZGV2aWNlIGlkID0gMHgwNDA3LCByb290IHRhYmxlID0gMHgyNGQ4NGQwMDAs
IGRvbWFpbiA9IDAsIHBhZ2luZyBtb2RlID0gMyB8IDAgMCAwIDANCihYRU4pIFsyMDEyLTA5
LTI0IDA2OjM5OjMxXSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQg
PSAweDA1MDAsIHJvb3QgdGFibGUgPSAweDI0ZDg0ZDAwMCwgZG9tYWluID0gMCwgcGFnaW5n
IG1vZGUgPSAzIHwgMCAwIDAgMA0KKFhFTikgWzIwMTItMDktMjQgMDY6Mzk6MzFdIEFNRC1W
aTogU2V0dXAgSS9PIHBhZ2UgdGFibGU6IGRldmljZSBpZCA9IDB4MDUwMSwgcm9vdCB0YWJs
ZSA9IDB4MjRkODRkMDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMgfCAwIDAgMCAw
DQooWEVOKSBbMjAxMi0wOS0yNCAwNjozOTozMV0gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0
YWJsZTogZGV2aWNlIGlkID0gMHgwNjAwLCByb290IHRhYmxlID0gMHgyNGQ4NGQwMDAsIGRv
bWFpbiA9IDAsIHBhZ2luZyBtb2RlID0gMyB8IDAgMCAwIDANCihYRU4pIFsyMDEyLTA5LTI0
IDA2OjM5OjMxXSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAw
eDA3MDAsIHJvb3QgdGFibGUgPSAweDI0ZDg0ZDAwMCwgZG9tYWluID0gMCwgcGFnaW5nIG1v
ZGUgPSAzIHwgMCAwIDAgMA0KKFhFTikgWzIwMTItMDktMjQgMDY6Mzk6MzFdIEFNRC1WaTog
U2V0dXAgSS9PIHBhZ2UgdGFibGU6IGRldmljZSBpZCA9IDB4MDgwMCwgcm9vdCB0YWJsZSA9
IDB4MjRkODRkMDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMgfCAwIDAgMCAwDQoo
WEVOKSBbMjAxMi0wOS0yNCAwNjozOTozMV0gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJs
ZTogZGV2aWNlIGlkID0gMHgwOTAwLCByb290IHRhYmxlID0gMHgyNGQ4NGQwMDAsIGRvbWFp
biA9IDAsIHBhZ2luZyBtb2RlID0gMyB8IDAgMCAwIDANCihYRU4pIFsyMDEyLTA5LTI0IDA2
OjM5OjMxXSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweDA5
MDEsIHJvb3QgdGFibGUgPSAweDI0ZDg0ZDAwMCwgZG9tYWluID0gMCwgcGFnaW5nIG1vZGUg
PSAzIHwgMCAwIDAgMA0KKFhFTikgWzIwMTItMDktMjQgMDY6Mzk6MzFdIEFNRC1WaTogU2V0
dXAgSS9PIHBhZ2UgdGFibGU6IGRldmljZSBpZCA9IDB4MDkwMiwgcm9vdCB0YWJsZSA9IDB4
MjRkODRkMDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMgfCAwIDAgMCAwDQooWEVO
KSBbMjAxMi0wOS0yNCAwNjozOTozMV0gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTog
ZGV2aWNlIGlkID0gMHgwOTAzLCByb290IHRhYmxlID0gMHgyNGQ4NGQwMDAsIGRvbWFpbiA9
IDAsIHBhZ2luZyBtb2RlID0gMyB8IDAgMCAwIDANCihYRU4pIFsyMDEyLTA5LTI0IDA2OjM5
OjMxXSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweDA5MDQs
IHJvb3QgdGFibGUgPSAweDI0ZDg0ZDAwMCwgZG9tYWluID0gMCwgcGFnaW5nIG1vZGUgPSAz
IHwgMCAwIDAgMA0KKFhFTikgWzIwMTItMDktMjQgMDY6Mzk6MzFdIEFNRC1WaTogU2V0dXAg
SS9PIHBhZ2UgdGFibGU6IGRldmljZSBpZCA9IDB4MDkwNSwgcm9vdCB0YWJsZSA9IDB4MjRk
ODRkMDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMgfCAwIDAgMCAwDQooWEVOKSBb
MjAxMi0wOS0yNCAwNjozOTozMV0gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2
aWNlIGlkID0gMHgwOTA2LCByb290IHRhYmxlID0gMHgyNGQ4NGQwMDAsIGRvbWFpbiA9IDAs
IHBhZ2luZyBtb2RlID0gMyB8IDAgMCAwIDANCihYRU4pIFsyMDEyLTA5LTI0IDA2OjM5OjMx
XSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweDA5MDcsIHJv
b3QgdGFibGUgPSAweDI0ZDg0ZDAwMCwgZG9tYWluID0gMCwgcGFnaW5nIG1vZGUgPSAzIHwg
MCAwIDAgMA0KKFhFTikgWzIwMTItMDktMjQgMDY6Mzk6MzFdIEFNRC1WaTogU2V0dXAgSS9P
IHBhZ2UgdGFibGU6IGRldmljZSBpZCA9IDB4MGEwMCwgcm9vdCB0YWJsZSA9IDB4MjRkODRk
MDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMgfCAwIDAgMCAwDQooWEVOKSBbMjAx
Mi0wOS0yNCAwNjozOTozMV0gU2NydWJiaW5nIEZyZWUgUkFNOiAuLi4uLi4uLi4uLi4uLi4u
Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u
LmRvbmUuDQooWEVOKSBbMjAxMi0wOS0yNCAwNjozOTozM10gSW5pdGlhbCBsb3cgbWVtb3J5
IHZpcnEgdGhyZXNob2xkIHNldCBhdCAweDQwMDAgcGFnZXMuDQooWEVOKSBbMjAxMi0wOS0y
NCAwNjozOTozM10gU3RkLiBMb2dsZXZlbDogQWxsDQooWEVOKSBbMjAxMi0wOS0yNCAwNjoz
OTozM10gR3Vlc3QgTG9nbGV2ZWw6IEFsbA0KKFhFTikgWzIwMTItMDktMjQgMDY6Mzk6MzNd
IFhlbiBpcyByZWxpbnF1aXNoaW5nIFZHQSBjb25zb2xlLg0KKFhFTikgWzIwMTItMDktMjQg
MDY6Mzk6MzNdICoqKiBTZXJpYWwgaW5wdXQgLT4gRE9NMCAodHlwZSAnQ1RSTC1hJyB0aHJl
ZSB0aW1lcyB0byBzd2l0Y2ggaW5wdXQgdG8gWGVuKQ0KKFhFTikgWzIwMTItMDktMjQgMDY6
Mzk6MzNdIEZyZWVkIDI0NGtCIGluaXQgbWVtb3J5Lg0KKFhFTikgWzIwMTItMDktMjQgMDY6
Mzk6MzNdIElPQVBJQ1swXTogU2V0IFBDSSByb3V0aW5nIGVudHJ5ICg2LTkgLT4gMHg2MCAt
PiBJUlEgOSBNb2RlOjEgQWN0aXZlOjEpDQooWEVOKSBbMjAxMi0wOS0yNCAwNjozOTozM10g
dHJhcHMuYzoyNTA0OmQwIERvbWFpbiBhdHRlbXB0ZWQgV1JNU1IgMDAwMDAwMDBjMDAxMDAw
NCBmcm9tIDB4MDAwMGVmZjBmODczMWYxYyB0byAweDAwMDAwMDAwMDAwMGFiY2QuDQooWEVO
KSBbMjAxMi0wOS0yNCAwNjozOTozM10gUENJIGFkZCBkZXZpY2UgMDAwMDowMDowMC4wDQoo
WEVOKSBbMjAxMi0wOS0yNCAwNjozOTozM10gUENJIGFkZCBkZXZpY2UgMDAwMDowMDowMC4y
DQooWEVOKSBbMjAxMi0wOS0yNCAwNjozOTozM10gUENJIGFkZCBkZXZpY2UgMDAwMDowMDow
Mi4wDQooWEVOKSBbMjAxMi0wOS0yNCAwNjozOTozM10gUENJIGFkZCBkZXZpY2UgMDAwMDow
MDowMy4wDQooWEVOKSBbMjAxMi0wOS0yNCAwNjozOTozM10gUENJIGFkZCBkZXZpY2UgMDAw
MDowMDowNS4wDQooWEVOKSBbMjAxMi0wOS0yNCAwNjozOTozM10gUENJIGFkZCBkZXZpY2Ug
MDAwMDowMDowNi4wDQooWEVOKSBbMjAxMi0wOS0yNCAwNjozOTozM10gUENJIGFkZCBkZXZp
Y2UgMDAwMDowMDowYS4wDQooWEVOKSBbMjAxMi0wOS0yNCAwNjozOTozM10gUENJIGFkZCBk
ZXZpY2UgMDAwMDowMDowYi4wDQooWEVOKSBbMjAxMi0wOS0yNCAwNjozOTozM10gUENJIGFk
ZCBkZXZpY2UgMDAwMDowMDowZC4wDQooWEVOKSBbMjAxMi0wOS0yNCAwNjozOTozM10gUENJ
IGFkZCBkZXZpY2UgMDAwMDowMDoxMS4wDQooWEVOKSBbMjAxMi0wOS0yNCAwNjozOTozM10g
UENJIGFkZCBkZXZpY2UgMDAwMDowMDoxMi4wDQooWEVOKSBbMjAxMi0wOS0yNCAwNjozOToz
M10gUENJIGFkZCBkZXZpY2UgMDAwMDowMDoxMi4yDQooWEVOKSBbMjAxMi0wOS0yNCAwNjoz
OTozM10gUENJIGFkZCBkZXZpY2UgMDAwMDowMDoxMy4wDQooWEVOKSBbMjAxMi0wOS0yNCAw
NjozOTozM10gUENJIGFkZCBkZXZpY2UgMDAwMDowMDoxMy4yDQooWEVOKSBbMjAxMi0wOS0y
NCAwNjozOTozM10gUENJIGFkZCBkZXZpY2UgMDAwMDowMDoxNC4wDQooWEVOKSBbMjAxMi0w
OS0yNCAwNjozOTozM10gUENJIGFkZCBkZXZpY2UgMDAwMDowMDoxNC4xDQooWEVOKSBbMjAx
Mi0wOS0yNCAwNjozOTozM10gUENJIGFkZCBkZXZpY2UgMDAwMDowMDoxNC4yDQooWEVOKSBb
MjAxMi0wOS0yNCAwNjozOTozM10gUENJIGFkZCBkZXZpY2UgMDAwMDowMDoxNC4zDQooWEVO
KSBbMjAxMi0wOS0yNCAwNjozOTozM10gUENJIGFkZCBkZXZpY2UgMDAwMDowMDoxNC40DQoo
WEVOKSBbMjAxMi0wOS0yNCAwNjozOTozM10gUENJIGFkZCBkZXZpY2UgMDAwMDowMDoxNC41
DQooWEVOKSBbMjAxMi0wOS0yNCAwNjozOTozM10gUENJIGFkZCBkZXZpY2UgMDAwMDowMDox
NS4wDQooWEVOKSBbMjAxMi0wOS0yNCAwNjozOTozM10gUENJIGFkZCBkZXZpY2UgMDAwMDow
MDoxNi4wDQooWEVOKSBbMjAxMi0wOS0yNCAwNjozOTozM10gUENJIGFkZCBkZXZpY2UgMDAw
MDowMDoxNi4yDQooWEVOKSBbMjAxMi0wOS0yNCAwNjozOTozM10gUENJIGFkZCBkZXZpY2Ug
MDAwMDowMDoxOC4wDQooWEVOKSBbMjAxMi0wOS0yNCAwNjozOTozM10gUENJIGFkZCBkZXZp
Y2UgMDAwMDowMDoxOC4xDQooWEVOKSBbMjAxMi0wOS0yNCAwNjozOTozM10gUENJIGFkZCBk
ZXZpY2UgMDAwMDowMDoxOC4yDQooWEVOKSBbMjAxMi0wOS0yNCAwNjozOTozM10gUENJIGFk
ZCBkZXZpY2UgMDAwMDowMDoxOC4zDQooWEVOKSBbMjAxMi0wOS0yNCAwNjozOTozM10gUENJ
IGFkZCBkZXZpY2UgMDAwMDowMDoxOC40DQooWEVOKSBbMjAxMi0wOS0yNCAwNjozOTozM10g
UENJIGFkZCBkZXZpY2UgMDAwMDowYTowMC4wDQooWEVOKSBbMjAxMi0wOS0yNCAwNjozOToz
M10gUENJIGFkZCBkZXZpY2UgMDAwMDowOTowMC4wDQooWEVOKSBbMjAxMi0wOS0yNCAwNjoz
OTozM10gUENJIGFkZCBkZXZpY2UgMDAwMDowOTowMC4xDQooWEVOKSBbMjAxMi0wOS0yNCAw
NjozOTozM10gUENJIGFkZCBkZXZpY2UgMDAwMDowOTowMC4yDQooWEVOKSBbMjAxMi0wOS0y
NCAwNjozOTozM10gUENJIGFkZCBkZXZpY2UgMDAwMDowOTowMC4zDQooWEVOKSBbMjAxMi0w
OS0yNCAwNjozOTozM10gUENJIGFkZCBkZXZpY2UgMDAwMDowOTowMC40DQooWEVOKSBbMjAx
Mi0wOS0yNCAwNjozOTozM10gUENJIGFkZCBkZXZpY2UgMDAwMDowOTowMC41DQooWEVOKSBb
MjAxMi0wOS0yNCAwNjozOTozM10gUENJIGFkZCBkZXZpY2UgMDAwMDowOTowMC42DQooWEVO
KSBbMjAxMi0wOS0yNCAwNjozOTozM10gUENJIGFkZCBkZXZpY2UgMDAwMDowOTowMC43DQoo
WEVOKSBbMjAxMi0wOS0yNCAwNjozOTozM10gUENJIGFkZCBkZXZpY2UgMDAwMDowODowMC4w
DQooWEVOKSBbMjAxMi0wOS0yNCAwNjozOTozM10gUENJIGFkZCBkZXZpY2UgMDAwMDowNzow
MC4wDQooWEVOKSBbMjAxMi0wOS0yNCAwNjozOTozM10gUENJIGFkZCBkZXZpY2UgMDAwMDow
NjowMC4wDQooWEVOKSBbMjAxMi0wOS0yNCAwNjozOTozM10gUENJIGFkZCBkZXZpY2UgMDAw
MDowNTowMC4wDQooWEVOKSBbMjAxMi0wOS0yNCAwNjozOTozM10gUENJIGFkZCBkZXZpY2Ug
MDAwMDowNTowMC4xDQooWEVOKSBbMjAxMi0wOS0yNCAwNjozOTozM10gUENJIGFkZCBkZXZp
Y2UgMDAwMDowNDowMC4wDQooWEVOKSBbMjAxMi0wOS0yNCAwNjozOTozM10gUENJIGFkZCBk
ZXZpY2UgMDAwMDowNDowMC4xDQooWEVOKSBbMjAxMi0wOS0yNCAwNjozOTozM10gUENJIGFk
ZCBkZXZpY2UgMDAwMDowNDowMC4yDQooWEVOKSBbMjAxMi0wOS0yNCAwNjozOTozM10gUENJ
IGFkZCBkZXZpY2UgMDAwMDowNDowMC4zDQooWEVOKSBbMjAxMi0wOS0yNCAwNjozOTozM10g
UENJIGFkZCBkZXZpY2UgMDAwMDowNDowMC40DQooWEVOKSBbMjAxMi0wOS0yNCAwNjozOToz
M10gUENJIGFkZCBkZXZpY2UgMDAwMDowNDowMC41DQooWEVOKSBbMjAxMi0wOS0yNCAwNjoz
OTozM10gUENJIGFkZCBkZXZpY2UgMDAwMDowNDowMC42DQooWEVOKSBbMjAxMi0wOS0yNCAw
NjozOTozM10gUENJIGFkZCBkZXZpY2UgMDAwMDowNDowMC43DQooWEVOKSBbMjAxMi0wOS0y
NCAwNjozOTozM10gUENJIGFkZCBkZXZpY2UgMDAwMDowMzowNi4wDQooWEVOKSBbMjAxMi0w
OS0yNCAwNjozOTozM10gSU9BUElDWzBdOiBTZXQgUENJIHJvdXRpbmcgZW50cnkgKDYtOCAt
PiAweDU4IC0+IElSUSA4IE1vZGU6MCBBY3RpdmU6MCkNCihYRU4pIFsyMDEyLTA5LTI0IDA2
OjM5OjMzXSBJT0FQSUNbMF06IFNldCBQQ0kgcm91dGluZyBlbnRyeSAoNi0xMyAtPiAweDg4
IC0+IElSUSAxMyBNb2RlOjAgQWN0aXZlOjApDQooWEVOKSBbMjAxMi0wOS0yNCAwNjozOToz
M10gSU9BUElDWzFdOiBTZXQgUENJIHJvdXRpbmcgZW50cnkgKDctMjggLT4gMHhhMCAtPiBJ
UlEgNTIgTW9kZToxIEFjdGl2ZToxKQ0KKFhFTikgWzIwMTItMDktMjQgMDY6Mzk6MzNdIElP
QVBJQ1sxXTogU2V0IFBDSSByb3V0aW5nIGVudHJ5ICg3LTI5IC0+IDB4YTggLT4gSVJRIDUz
IE1vZGU6MSBBY3RpdmU6MSkNCihYRU4pIFsyMDEyLTA5LTI0IDA2OjM5OjMzXSBJT0FQSUNb
MV06IFNldCBQQ0kgcm91dGluZyBlbnRyeSAoNy0zMCAtPiAweGIwIC0+IElSUSA1NCBNb2Rl
OjEgQWN0aXZlOjEpDQooWEVOKSBbMjAxMi0wOS0yNCAwNjozOTozM10gSU9BUElDWzBdOiBT
ZXQgUENJIHJvdXRpbmcgZW50cnkgKDYtMTYgLT4gMHhiOCAtPiBJUlEgMTYgTW9kZToxIEFj
dGl2ZToxKQ0KKFhFTikgWzIwMTItMDktMjQgMDY6Mzk6MzNdIElPQVBJQ1swXTogU2V0IFBD
SSByb3V0aW5nIGVudHJ5ICg2LTE4IC0+IDB4YzAgLT4gSVJRIDE4IE1vZGU6MSBBY3RpdmU6
MSkNCihYRU4pIFsyMDEyLTA5LTI0IDA2OjM5OjM0XSBJT0FQSUNbMF06IFNldCBQQ0kgcm91
dGluZyBlbnRyeSAoNi0xNyAtPiAweGM4IC0+IElSUSAxNyBNb2RlOjEgQWN0aXZlOjEpDQoo
WEVOKSBbMjAxMi0wOS0yNCAwNjozOTozNF0gSU9BUElDWzFdOiBTZXQgUENJIHJvdXRpbmcg
ZW50cnkgKDctNCAtPiAweGQwIC0+IElSUSAyOCBNb2RlOjEgQWN0aXZlOjEpDQooWEVOKSBb
MjAxMi0wOS0yNCAwNjozOTozNF0gSU9BUElDWzFdOiBTZXQgUENJIHJvdXRpbmcgZW50cnkg
KDctNSAtPiAweGQ4IC0+IElSUSAyOSBNb2RlOjEgQWN0aXZlOjEpDQooWEVOKSBbMjAxMi0w
OS0yNCAwNjozOTozNF0gSU9BUElDWzFdOiBTZXQgUENJIHJvdXRpbmcgZW50cnkgKDctNiAt
PiAweDIxIC0+IElSUSAzMCBNb2RlOjEgQWN0aXZlOjEpDQooWEVOKSBbMjAxMi0wOS0yNCAw
NjozOTozNF0gSU9BUElDWzFdOiBTZXQgUENJIHJvdXRpbmcgZW50cnkgKDctNyAtPiAweDI5
IC0+IElSUSAzMSBNb2RlOjEgQWN0aXZlOjEpDQooWEVOKSBbMjAxMi0wOS0yNCAwNjozOToz
NF0gSU9BUElDWzFdOiBTZXQgUENJIHJvdXRpbmcgZW50cnkgKDctMTYgLT4gMHgzMSAtPiBJ
UlEgNDAgTW9kZToxIEFjdGl2ZToxKQ0KKFhFTikgWzIwMTItMDktMjQgMDY6Mzk6MzRdIElP
QVBJQ1sxXTogU2V0IFBDSSByb3V0aW5nIGVudHJ5ICg3LTE3IC0+IDB4MzkgLT4gSVJRIDQx
IE1vZGU6MSBBY3RpdmU6MSkNCihYRU4pIFsyMDEyLTA5LTI0IDA2OjM5OjM0XSBJT0FQSUNb
MV06IFNldCBQQ0kgcm91dGluZyBlbnRyeSAoNy0xOCAtPiAweDQxIC0+IElSUSA0MiBNb2Rl
OjEgQWN0aXZlOjEpDQooWEVOKSBbMjAxMi0wOS0yNCAwNjozOTozNF0gSU9BUElDWzFdOiBT
ZXQgUENJIHJvdXRpbmcgZW50cnkgKDctMTkgLT4gMHg0OSAtPiBJUlEgNDMgTW9kZToxIEFj
dGl2ZToxKQ0KKFhFTikgWzIwMTItMDktMjQgMDY6Mzk6MzRdIElPQVBJQ1swXTogU2V0IFBD
SSByb3V0aW5nIGVudHJ5ICg2LTIyIC0+IDB4OTEgLT4gSVJRIDIyIE1vZGU6MSBBY3RpdmU6
MSkNCihYRU4pIFsyMDEyLTA5LTI0IDA2OjM5OjM0XSBJT0FQSUNbMV06IFNldCBQQ0kgcm91
dGluZyBlbnRyeSAoNy0yMyAtPiAweDk5IC0+IElSUSA0NyBNb2RlOjEgQWN0aXZlOjEpDQoo
WEVOKSBbMjAxMi0wOS0yNCAwNjozOTozNF0gSU9BUElDWzBdOiBTZXQgUENJIHJvdXRpbmcg
ZW50cnkgKDYtMTkgLT4gMHhhMSAtPiBJUlEgMTkgTW9kZToxIEFjdGl2ZToxKQ0KKFhFTikg
WzIwMTItMDktMjQgMDY6Mzk6MzVdIElPQVBJQ1sxXTogU2V0IFBDSSByb3V0aW5nIGVudHJ5
ICg3LTIyIC0+IDB4YjEgLT4gSVJRIDQ2IE1vZGU6MSBBY3RpdmU6MSkNCihYRU4pIFsyMDEy
LTA5LTI0IDA2OjM5OjM1XSBJT0FQSUNbMV06IFNldCBQQ0kgcm91dGluZyBlbnRyeSAoNy0y
NyAtPiAweGMxIC0+IElSUSA1MSBNb2RlOjEgQWN0aXZlOjEpDQooWEVOKSBbMjAxMi0wOS0y
NCAwNjozOTozNl0gSU9BUElDWzFdOiBTZXQgUENJIHJvdXRpbmcgZW50cnkgKDctOSAtPiAw
eGQxIC0+IElSUSAzMyBNb2RlOjEgQWN0aXZlOjEpDQooWEVOKSBbMjAxMi0wOS0yNCAwNjo0
MDo0Ml0gdHJhcHMuYzoyNTA0OmQxIERvbWFpbiBhdHRlbXB0ZWQgV1JNU1IgMDAwMDAwMDBj
MDAxMDAwNCBmcm9tIDB4MDAwMDAwMDAwN2ZiZmMwMCB0byAweDAwMDAwMDAwMDAwMGFiY2Qu
DQooWEVOKSBbMjAxMi0wOS0yNCAwNjo0MDo0OF0gdHJhcHMuYzoyNTA0OmQyIERvbWFpbiBh
dHRlbXB0ZWQgV1JNU1IgMDAwMDAwMDBjMDAxMDAwNCBmcm9tIDB4MDAwMGY1ZjAyOWRlNjgw
MCB0byAweDAwMDAwMDAwMDAwMGFiY2QuDQooWEVOKSBbMjAxMi0wOS0yNCAwNjo0MDo1NF0g
dHJhcHMuYzoyNTA0OmQzIERvbWFpbiBhdHRlbXB0ZWQgV1JNU1IgMDAwMDAwMDBjMDAxMDAw
NCBmcm9tIDB4MDAwMDgwNzZjMGU5NDA2MyB0byAweDAwMDAwMDAwMDAwMGFiY2QuDQooWEVO
KSBbMjAxMi0wOS0yNCAwNjo0MTowMV0gdHJhcHMuYzoyNTA0OmQ0IERvbWFpbiBhdHRlbXB0
ZWQgV1JNU1IgMDAwMDAwMDBjMDAxMDAwNCBmcm9tIDB4MDAwMDBjYjQ0NmMyYTMwNSB0byAw
eDAwMDAwMDAwMDAwMGFiY2QuDQooWEVOKSBbMjAxMi0wOS0yNCAwNjo0MTowN10gdHJhcHMu
YzoyNTA0OmQ1IERvbWFpbiBhdHRlbXB0ZWQgV1JNU1IgMDAwMDAwMDBjMDAxMDAwNCBmcm9t
IDB4MDAwMDAwMDAwN2ZiZmMwMCB0byAweDAwMDAwMDAwMDAwMGFiY2QuDQooWEVOKSBbMjAx
Mi0wOS0yNCAwNjo0MToxNF0gdHJhcHMuYzoyNTA0OmQ2IERvbWFpbiBhdHRlbXB0ZWQgV1JN
U1IgMDAwMDAwMDBjMDAxMDAwNCBmcm9tIDB4MDAwMGY1ZjAyOWRlNjgwMCB0byAweDAwMDAw
MDAwMDAwMGFiY2QuDQooWEVOKSBbMjAxMi0wOS0yNCAwNjo0MToyMF0gdHJhcHMuYzoyNTA0
OmQ3IERvbWFpbiBhdHRlbXB0ZWQgV1JNU1IgMDAwMDAwMDBjMDAxMDAwNCBmcm9tIDB4MDAw
MDgwNzZjMGU5NDA2MyB0byAweDAwMDAwMDAwMDAwMGFiY2QuDQooWEVOKSBbMjAxMi0wOS0y
NCAwNjo0MToyNV0gdHJhcHMuYzoyNTA0OmQ4IERvbWFpbiBhdHRlbXB0ZWQgV1JNU1IgMDAw
MDAwMDBjMDAxMDAwNCBmcm9tIDB4MDAwMDAwMDAwN2ZiZmMwMCB0byAweDAwMDAwMDAwMDAw
MGFiY2QuDQooWEVOKSBbMjAxMi0wOS0yNCAwNjo0MTozMV0gdHJhcHMuYzoyNTA0OmQ5IERv
bWFpbiBhdHRlbXB0ZWQgV1JNU1IgMDAwMDAwMDBjMDAxMDAwNCBmcm9tIDB4MDAwMDgwNzZj
MGU5NDA2MyB0byAweDAwMDAwMDAwMDAwMGFiY2QuDQooWEVOKSBbMjAxMi0wOS0yNCAwNjo0
MTozOF0gdHJhcHMuYzoyNTA0OmQxMCBEb21haW4gYXR0ZW1wdGVkIFdSTVNSIDAwMDAwMDAw
YzAwMTAwMDQgZnJvbSAweDAwMDAwMDAwMDdmYmZjMDAgdG8gMHgwMDAwMDAwMDAwMDBhYmNk
Lg0KKFhFTikgWzIwMTItMDktMjQgMDY6NDE6NDhdIEFNRC1WaTogYW1kX2lvbW11X2Fzc2ln
bl9kZXZpY2U6IGQ6MTEgMDAwMDowMzowNi4wIDAgMA0KKFhFTikgWzIwMTItMDktMjQgMDY6
NDE6NDhdIEFNRC1WaTogRGlzYWJsZTogZGV2aWNlIGlkID0gMHgwMGE0LCBkb21haW4gPSAw
LCBwYWdpbmcgbW9kZSA9IDMNCihYRU4pIFsyMDEyLTA5LTI0IDA2OjQxOjQ4XSBBTUQtVmk6
IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweDAwYTQsIHJvb3QgdGFibGUg
PSAweDE4ZTBhNTAwMCwgZG9tYWluID0gMTEsIHBhZ2luZyBtb2RlID0gMyB8IDAgMCAwIDAN
CihYRU4pIFsyMDEyLTA5LTI0IDA2OjQxOjQ4XSBBTUQtVmk6IFJlLWFzc2lnbiAwMDAwOjAz
OjA2LjAgZnJvbSBkb20wIHRvIGRvbTExIDAgMCAwIDANCihYRU4pIFsyMDEyLTA5LTI0IDA2
OjQxOjQ5XSB0cmFwcy5jOjI1MDQ6ZDExIERvbWFpbiBhdHRlbXB0ZWQgV1JNU1IgMDAwMDAw
MDBjMDAxMDAwNCBmcm9tIDB4MDAwMDgwNzZjMGU5NDA2MyB0byAweDAwMDAwMDAwMDAwMGFi
Y2QuDQooWEVOKSBbMjAxMi0wOS0yNCAwNjo0MTo1NV0gdHJhcHMuYzoyNTA0OmQxMiBEb21h
aW4gYXR0ZW1wdGVkIFdSTVNSIDAwMDAwMDAwYzAwMTAwMDQgZnJvbSAweDAwMDAwY2I0NDZj
MmEzMDUgdG8gMHgwMDAwMDAwMDAwMDBhYmNkLg0KKFhFTikgWzIwMTItMDktMjQgMDY6NDI6
MDFdIHRyYXBzLmM6MjUwNDpkMTMgRG9tYWluIGF0dGVtcHRlZCBXUk1TUiAwMDAwMDAwMGMw
MDEwMDA0IGZyb20gMHgwMDAwODA3NmMwZTk0MDYzIHRvIDB4MDAwMDAwMDAwMDAwYWJjZC4N
CihYRU4pIFsyMDEyLTA5LTI0IDA2OjQyOjA4XSB0cmFwcy5jOjI1MDQ6ZDE0IERvbWFpbiBh
dHRlbXB0ZWQgV1JNU1IgMDAwMDAwMDBjMDAxMDAwNCBmcm9tIDB4MDAwMDgwNzZjMGU5NDA2
MyB0byAweDAwMDAwMDAwMDAwMGFiY2QuDQooWEVOKSBbMjAxMi0wOS0yNCAwNjo0NDoxNl0g
dHJhcHMuYzozMDYyOiBHUEYgKDAwNjApOiBmZmZmODJjNDgwMTVlNjllIC0+IGZmZmY4MmM0
ODAyMjYyZTMNCihYRU4pIFsyMDEyLTA5LTI0IDA2OjQ4OjEzXSB0cmFwcy5jOjMwNjI6IEdQ
RiAoMDA2MCk6IGZmZmY4MmM0ODAxNWU2OWUgLT4gZmZmZjgyYzQ4MDIyNjJlMw0KKFhFTikg
WzIwMTItMDktMjQgMDY6NDk6MjNdIHRyYXBzLmM6MzA2MjogR1BGICgwMDYwKTogZmZmZjgy
YzQ4MDE1ZTY5ZSAtPiBmZmZmODJjNDgwMjI2MmUzDQooWEVOKSBbMjAxMi0wOS0yNCAwODoy
NToyMV0gQU1ELVZpOiBTaGFyZSBwMm0gdGFibGUgd2l0aCBpb21tdTogZG9tYWluOjE1IHAy
bSB0YWJsZSA9IDB4MWMxZjk0DQooWEVOKSBbMjAxMi0wOS0yNCAwODoyNToyMl0gW1ZULURd
aW8uYzoyODI6IGQxNTogYmluZDogbV9nc2k9MTYgZ19nc2k9MzYgZGV2aWNlPTUgaW50eD0w
DQooWEVOKSBbMjAxMi0wOS0yNCAwODoyNToyMl0gQU1ELVZpOiBhbWRfaW9tbXVfYXNzaWdu
X2RldmljZTogZDoxNSAwMDAwOjA2OjAwLjAgMCAwDQooWEVOKSBbMjAxMi0wOS0yNCAwODoy
NToyMl0gQU1ELVZpOiBEaXNhYmxlOiBkZXZpY2UgaWQgPSAweDA2MDAsIGRvbWFpbiA9IDAs
IHBhZ2luZyBtb2RlID0gMw0KKFhFTikgWzIwMTItMDktMjQgMDg6MjU6MjJdIEFNRC1WaTog
U2V0dXAgSS9PIHBhZ2UgdGFibGU6IGRldmljZSBpZCA9IDB4MDYwMCwgcm9vdCB0YWJsZSA9
IDB4MWMxZjk0MDAwLCBkb21haW4gPSAxNSwgcGFnaW5nIG1vZGUgPSA0IHwgMCAwIDAgMA0K
KFhFTikgWzIwMTItMDktMjQgMDg6MjU6MjJdIEFNRC1WaTogUmUtYXNzaWduIDAwMDA6MDY6
MDAuMCBmcm9tIGRvbTAgdG8gZG9tMTUgMCAwIDAgMA0KKFhFTikgWzIwMTItMDktMjQgMDg6
MjU6MjJdIEhWTTE1OiBIVk0gTG9hZGVyDQooWEVOKSBbMjAxMi0wOS0yNCAwODoyNToyMl0g
SFZNMTU6IERldGVjdGVkIFhlbiB2NC4zLXVuc3RhYmxlDQooWEVOKSBbMjAxMi0wOS0yNCAw
ODoyNToyMl0gSFZNMTU6IFhlbmJ1cyByaW5ncyBAMHhmZWZmYzAwMCwgZXZlbnQgY2hhbm5l
bCA1DQooWEVOKSBbMjAxMi0wOS0yNCAwODoyNToyMl0gSFZNMTU6IFN5c3RlbSByZXF1ZXN0
ZWQgUk9NQklPUw0KKFhFTikgWzIwMTItMDktMjQgMDg6MjU6MjJdIEhWTTE1OiBDUFUgc3Bl
ZWQgaXMgMzIwMCBNSHoNCihYRU4pIFsyMDEyLTA5LTI0IDA4OjI1OjIyXSBpcnEuYzoyNzA6
IERvbTE1IFBDSSBsaW5rIDAgY2hhbmdlZCAwIC0+IDUNCihYRU4pIFsyMDEyLTA5LTI0IDA4
OjI1OjIyXSBIVk0xNTogUENJLUlTQSBsaW5rIDAgcm91dGVkIHRvIElSUTUNCihYRU4pIFsy
MDEyLTA5LTI0IDA4OjI1OjIyXSBpcnEuYzoyNzA6IERvbTE1IFBDSSBsaW5rIDEgY2hhbmdl
ZCAwIC0+IDEwDQooWEVOKSBbMjAxMi0wOS0yNCAwODoyNToyMl0gSFZNMTU6IFBDSS1JU0Eg
bGluayAxIHJvdXRlZCB0byBJUlExMA0KKFhFTikgWzIwMTItMDktMjQgMDg6MjU6MjJdIGly
cS5jOjI3MDogRG9tMTUgUENJIGxpbmsgMiBjaGFuZ2VkIDAgLT4gMTENCihYRU4pIFsyMDEy
LTA5LTI0IDA4OjI1OjIyXSBIVk0xNTogUENJLUlTQSBsaW5rIDIgcm91dGVkIHRvIElSUTEx
DQooWEVOKSBbMjAxMi0wOS0yNCAwODoyNToyMl0gaXJxLmM6MjcwOiBEb20xNSBQQ0kgbGlu
ayAzIGNoYW5nZWQgMCAtPiA1DQooWEVOKSBbMjAxMi0wOS0yNCAwODoyNToyMl0gSFZNMTU6
IFBDSS1JU0EgbGluayAzIHJvdXRlZCB0byBJUlE1DQooWEVOKSBbMjAxMi0wOS0yNCAwODoy
NToyMl0gSFZNMTU6IHBjaSBkZXYgMDE6MiBJTlRELT5JUlE1DQooWEVOKSBbMjAxMi0wOS0y
NCAwODoyNToyMl0gSFZNMTU6IHBjaSBkZXYgMDE6MyBJTlRBLT5JUlExMA0KKFhFTikgWzIw
MTItMDktMjQgMDg6MjU6MjJdIEhWTTE1OiBwY2kgZGV2IDAzOjAgSU5UQS0+SVJRNQ0KKFhF
TikgWzIwMTItMDktMjQgMDg6MjU6MjJdIEhWTTE1OiBwY2kgZGV2IDA0OjAgSU5UQS0+SVJR
NQ0KKFhFTikgWzIwMTItMDktMjQgMDg6MjU6MjJdIEhWTTE1OiBwY2kgZGV2IDA1OjAgSU5U
QS0+SVJRMTANCihYRU4pIFsyMDEyLTA5LTI0IDA4OjI1OjIyXSBIVk0xNTogcGNpIGRldiAw
MjowIGJhciAxMCBzaXplIDAyMDAwMDAwOiBmMDAwMDAwOA0KKFhFTikgWzIwMTItMDktMjQg
MDg6MjU6MjJdIEhWTTE1OiBwY2kgZGV2IDAzOjAgYmFyIDE0IHNpemUgMDEwMDAwMDA6IGYy
MDAwMDA4DQooWEVOKSBbMjAxMi0wOS0yNCAwODoyNToyMl0gSFZNMTU6IHBjaSBkZXYgMDU6
MCBiYXIgMTAgc2l6ZSAwMDIwMDAwMDogZjMwMDAwMDQNCihYRU4pIFsyMDEyLTA5LTI0IDA4
OjI1OjIyXSBtZW1vcnlfbWFwOmFkZDogZG9tMTUgZ2ZuPWYzMDAwIG1mbj1mOWEwMCBucj0y
MDANCihYRU4pIFsyMDEyLTA5LTI0IDA4OjI1OjIyXSBIVk0xNTogcGNpIGRldiAwNDowIGJh
ciAxMCBzaXplIDAwMDIwMDAwOiBmMzIwMDAwMA0KKFhFTikgWzIwMTItMDktMjQgMDg6MjU6
MjJdIEhWTTE1OiBwY2kgZGV2IDAyOjAgYmFyIDE0IHNpemUgMDAwMDEwMDA6IGYzMjIwMDAw
DQooWEVOKSBbMjAxMi0wOS0yNCAwODoyNToyMl0gSFZNMTU6IHBjaSBkZXYgMDM6MCBiYXIg
MTAgc2l6ZSAwMDAwMDEwMDogMDAwMGMwMDENCihYRU4pIFsyMDEyLTA5LTI0IDA4OjI1OjIy
XSBIVk0xNTogcGNpIGRldiAwNDowIGJhciAxNCBzaXplIDAwMDAwMDQwOiAwMDAwYzEwMQ0K
KFhFTikgWzIwMTItMDktMjQgMDg6MjU6MjJdIEhWTTE1OiBwY2kgZGV2IDAxOjIgYmFyIDIw
IHNpemUgMDAwMDAwMjA6IDAwMDBjMTQxDQooWEVOKSBbMjAxMi0wOS0yNCAwODoyNToyMl0g
SFZNMTU6IHBjaSBkZXYgMDE6MSBiYXIgMjAgc2l6ZSAwMDAwMDAxMDogMDAwMGMxNjENCihY
RU4pIFsyMDEyLTA5LTI0IDA4OjI1OjIyXSBIVk0xNTogTXVsdGlwcm9jZXNzb3IgaW5pdGlh
bGlzYXRpb246DQooWEVOKSBbMjAxMi0wOS0yNCAwODoyNToyMl0gSFZNMTU6ICAtIENQVTAg
Li4uIDQ4LWJpdCBwaHlzIC4uLiBmaXhlZCBNVFJScyAuLi4gdmFyIE1UUlJzIFsyLzhdIC4u
LiBkb25lLg0KKFhFTikgWzIwMTItMDktMjQgMDg6MjU6MjJdIEhWTTE1OiAgLSBDUFUxIC4u
LiA0OC1iaXQgcGh5cyAuLi4gZml4ZWQgTVRSUnMgLi4uIHZhciBNVFJScyBbMi84XSAuLi4g
ZG9uZS4NCihYRU4pIFsyMDEyLTA5LTI0IDA4OjI1OjIyXSBIVk0xNTogIC0gQ1BVMiAuLi4g
NDgtYml0IHBoeXMgLi4uIGZpeGVkIE1UUlJzIC4uLiB2YXIgTVRSUnMgWzIvOF0gLi4uIGRv
bmUuDQooWEVOKSBbMjAxMi0wOS0yNCAwODoyNToyMl0gSFZNMTU6IFRlc3RpbmcgSFZNIGVu
dmlyb25tZW50Og0KKFhFTikgWzIwMTItMDktMjQgMDg6MjU6MjJdIEhWTTE1OiAgLSBSRVAg
SU5TQiBhY3Jvc3MgcGFnZSBib3VuZGFyaWVzIC4uLiBwYXNzZWQNCihYRU4pIFsyMDEyLTA5
LTI0IDA4OjI1OjIyXSBIVk0xNTogIC0gR1MgYmFzZSBNU1JzIGFuZCBTV0FQR1MgLi4uIHBh
c3NlZA0KKFhFTikgWzIwMTItMDktMjQgMDg6MjU6MjJdIEhWTTE1OiBQYXNzZWQgMiBvZiAy
IHRlc3RzDQooWEVOKSBbMjAxMi0wOS0yNCAwODoyNToyMl0gSFZNMTU6IFdyaXRpbmcgU01C
SU9TIHRhYmxlcyAuLi4NCihYRU4pIFsyMDEyLTA5LTI0IDA4OjI1OjIyXSBIVk0xNTogTG9h
ZGluZyBST01CSU9TIC4uLg0KKFhFTikgWzIwMTItMDktMjQgMDg6MjU6MjJdIEhWTTE1OiA5
NjYwIGJ5dGVzIG9mIFJPTUJJT1MgaGlnaC1tZW1vcnkgZXh0ZW5zaW9uczoNCihYRU4pIFsy
MDEyLTA5LTI0IDA4OjI1OjIyXSBIVk0xNTogICBSZWxvY2F0aW5nIHRvIDB4ZmMwMDEwMDAt
MHhmYzAwMzViYyAuLi4gZG9uZQ0KKFhFTikgWzIwMTItMDktMjQgMDg6MjU6MjJdIEhWTTE1
OiBDcmVhdGluZyBNUCB0YWJsZXMgLi4uDQooWEVOKSBbMjAxMi0wOS0yNCAwODoyNToyMl0g
SFZNMTU6IExvYWRpbmcgQ2lycnVzIFZHQUJJT1MgLi4uDQooWEVOKSBbMjAxMi0wOS0yNCAw
ODoyNToyMl0gSFZNMTU6IExvYWRpbmcgUENJIE9wdGlvbiBST00gLi4uDQooWEVOKSBbMjAx
Mi0wOS0yNCAwODoyNToyMl0gSFZNMTU6ICAtIE1hbnVmYWN0dXJlcjogaHR0cDovL2lweGUu
b3JnDQooWEVOKSBbMjAxMi0wOS0yNCAwODoyNToyMl0gSFZNMTU6ICAtIFByb2R1Y3QgbmFt
ZTogaVBYRQ0KKFhFTikgWzIwMTItMDktMjQgMDg6MjU6MjJdIEhWTTE1OiBPcHRpb24gUk9N
czoNCihYRU4pIFsyMDEyLTA5LTI0IDA4OjI1OjIyXSBIVk0xNTogIGMwMDAwLWM4ZmZmOiBW
R0EgQklPUw0KKFhFTikgWzIwMTItMDktMjQgMDg6MjU6MjJdIEhWTTE1OiAgYzkwMDAtZDlm
ZmY6IEV0aGVyYm9vdCBST00NCihYRU4pIFsyMDEyLTA5LTI0IDA4OjI1OjIyXSBIVk0xNTog
TG9hZGluZyBBQ1BJIC4uLg0KKFhFTikgWzIwMTItMDktMjQgMDg6MjU6MjJdIEhWTTE1OiB2
bTg2IFRTUyBhdCBmYzAwZjY4MA0KKFhFTikgWzIwMTItMDktMjQgMDg6MjU6MjJdIEhWTTE1
OiBCSU9TIG1hcDoNCihYRU4pIFsyMDEyLTA5LTI0IDA4OjI1OjIyXSBIVk0xNTogIGYwMDAw
LWZmZmZmOiBNYWluIEJJT1MNCihYRU4pIFsyMDEyLTA5LTI0IDA4OjI1OjIyXSBIVk0xNTog
RTgyMCB0YWJsZToNCihYRU4pIFsyMDEyLTA5LTI0IDA4OjI1OjIyXSBIVk0xNTogIFswMF06
IDAwMDAwMDAwOjAwMDAwMDAwIC0gMDAwMDAwMDA6MDAwOWUwMDA6IFJBTQ0KKFhFTikgWzIw
MTItMDktMjQgMDg6MjU6MjJdIEhWTTE1OiAgWzAxXTogMDAwMDAwMDA6MDAwOWUwMDAgLSAw
MDAwMDAwMDowMDBhMDAwMDogUkVTRVJWRUQNCihYRU4pIFsyMDEyLTA5LTI0IDA4OjI1OjIy
XSBIVk0xNTogIEhPTEU6IDAwMDAwMDAwOjAwMGEwMDAwIC0gMDAwMDAwMDA6MDAwZTAwMDAN
CihYRU4pIFsyMDEyLTA5LTI0IDA4OjI1OjIyXSBIVk0xNTogIFswMl06IDAwMDAwMDAwOjAw
MGUwMDAwIC0gMDAwMDAwMDA6MDAxMDAwMDA6IFJFU0VSVkVEDQooWEVOKSBbMjAxMi0wOS0y
NCAwODoyNToyMl0gSFZNMTU6ICBbMDNdOiAwMDAwMDAwMDowMDEwMDAwMCAtIDAwMDAwMDAw
OjNmODAwMDAwOiBSQU0NCihYRU4pIFsyMDEyLTA5LTI0IDA4OjI1OjIyXSBIVk0xNTogIEhP
TEU6IDAwMDAwMDAwOjNmODAwMDAwIC0gMDAwMDAwMDA6ZmMwMDAwMDANCihYRU4pIFsyMDEy
LTA5LTI0IDA4OjI1OjIyXSBIVk0xNTogIFswNF06IDAwMDAwMDAwOmZjMDAwMDAwIC0gMDAw
MDAwMDE6MDAwMDAwMDA6IFJFU0VSVkVEDQooWEVOKSBbMjAxMi0wOS0yNCAwODoyNToyMl0g
SFZNMTU6IEludm9raW5nIFJPTUJJT1MgLi4uDQooWEVOKSBbMjAxMi0wOS0yNCAwODoyNToy
Ml0gSFZNMTU6ICRSZXZpc2lvbjogMS4yMjEgJCAkRGF0ZTogMjAwOC8xMi8wNyAxNzozMjoy
OSAkDQooWEVOKSBbMjAxMi0wOS0yNCAwODoyNToyM10gc3RkdmdhLmM6MTQ3OmQxNSBlbnRl
cmluZyBzdGR2Z2EgYW5kIGNhY2hpbmcgbW9kZXMNCihYRU4pIFsyMDEyLTA5LTI0IDA4OjI1
OjIzXSBIVk0xNTogVkdBQmlvcyAkSWQ6IHZnYWJpb3MuYyx2IDEuNjcgMjAwOC8wMS8yNyAw
OTo0NDoxMiB2cnVwcGVydCBFeHAgJA0KKFhFTikgWzIwMTItMDktMjQgMDg6MjU6MjNdIEhW
TTE1OiBCb2NocyBCSU9TIC0gYnVpbGQ6IDA2LzIzLzk5DQooWEVOKSBbMjAxMi0wOS0yNCAw
ODoyNToyM10gSFZNMTU6ICRSZXZpc2lvbjogMS4yMjEgJCAkRGF0ZTogMjAwOC8xMi8wNyAx
NzozMjoyOSAkDQooWEVOKSBbMjAxMi0wOS0yNCAwODoyNToyM10gSFZNMTU6IE9wdGlvbnM6
IGFwbWJpb3MgcGNpYmlvcyBlbHRvcml0byBQTU0gDQooWEVOKSBbMjAxMi0wOS0yNCAwODoy
NToyM10gSFZNMTU6IA0KKFhFTikgWzIwMTItMDktMjQgMDg6MjU6MjNdIEhWTTE1OiBhdGEw
LTA6IFBDSFM9MTYzODMvMTYvNjMgdHJhbnNsYXRpb249bGJhIExDSFM9MTAyNC8yNTUvNjMN
CihYRU4pIFsyMDEyLTA5LTI0IDA4OjI1OjIzXSBIVk0xNTogYXRhMCBtYXN0ZXI6IFFFTVUg
SEFSRERJU0sgQVRBLTcgSGFyZC1EaXNrICg4MTkyIE1CeXRlcykNCihYRU4pIFsyMDEyLTA5
LTI0IDA4OjI1OjIzXSBIVk0xNTogYXRhMC0xOiBQQ0hTPTEwNDAvMTYvNjMgdHJhbnNsYXRp
b249bGJhIExDSFM9MTAyNC8xNi82Mw0KKFhFTikgWzIwMTItMDktMjQgMDg6MjU6MjNdIEhW
TTE1OiBhdGEwICBzbGF2ZTogUUVNVSBIQVJERElTSyBBVEEtNyBIYXJkLURpc2sgKCA1MTIg
TUJ5dGVzKQ0KKFhFTikgWzIwMTItMDktMjQgMDg6MjU6MjNdIEhWTTE1OiBhdGExLTA6IFBD
SFM9MTYzODMvMTYvNjMgdHJhbnNsYXRpb249bGJhIExDSFM9MTAyNC8yNTUvNjMNCihYRU4p
IFsyMDEyLTA5LTI0IDA4OjI1OjIzXSBIVk0xNTogYXRhMSBtYXN0ZXI6IFFFTVUgSEFSRERJ
U0sgQVRBLTcgSGFyZC1EaXNrICggMzAwIEdCeXRlcykNCihYRU4pIFsyMDEyLTA5LTI0IDA4
OjI1OjI0XSBIVk0xNTogSURFIHRpbWUgb3V0DQooWEVOKSBbMjAxMi0wOS0yNCAwODoyNToy
NF0gSFZNMTU6IA0KKFhFTikgWzIwMTItMDktMjQgMDg6MjU6MjRdIEhWTTE1OiANCihYRU4p
IFsyMDEyLTA5LTI0IDA4OjI1OjI0XSBIVk0xNTogDQooWEVOKSBbMjAxMi0wOS0yNCAwODoy
NToyNF0gSFZNMTU6IFByZXNzIEYxMiBmb3IgYm9vdCBtZW51Lg0KKFhFTikgWzIwMTItMDkt
MjQgMDg6MjU6MjRdIEhWTTE1OiANCihYRU4pIFsyMDEyLTA5LTI0IDA4OjI1OjI0XSBIVk0x
NTogQm9vdGluZyBmcm9tIEhhcmQgRGlzay4uLg0KKFhFTikgWzIwMTItMDktMjQgMDg6MjU6
MjRdIEhWTTE1OiBCb290aW5nIGZyb20gMDAwMDo3YzAwDQooWEVOKSBbMjAxMi0wOS0yNCAw
ODoyNToyNV0gc3RkdmdhLmM6MTUxOmQxNSBsZWF2aW5nIHN0ZHZnYQ0KKFhFTikgWzIwMTIt
MDktMjQgMDg6MjU6MzJdIHN0ZHZnYS5jOjE0NzpkMTUgZW50ZXJpbmcgc3RkdmdhIGFuZCBj
YWNoaW5nIG1vZGVzDQooWEVOKSBbMjAxMi0wOS0yNCAwODoyNTozM10gaXJxLmM6Mzc1OiBE
b20xNSBjYWxsYmFjayB2aWEgY2hhbmdlZCB0byBEaXJlY3QgVmVjdG9yIDB4ZjMNCihYRU4p
IFsyMDEyLTA5LTI0IDA4OjI1OjMzXSBtZW1vcnlfbWFwOnJlbW92ZTogZG9tMTUgZ2ZuPWYz
MDAwIG1mbj1mOWEwMCBucj0yMDANCihYRU4pIFsyMDEyLTA5LTI0IDA4OjI1OjMzXSBtZW1v
cnlfbWFwOmFkZDogZG9tMTUgZ2ZuPWYzMDAwIG1mbj1mOWEwMCBucj0yMDANCihYRU4pIFsy
MDEyLTA5LTI0IDA4OjI1OjMzXSBtZW1vcnlfbWFwOnJlbW92ZTogZG9tMTUgZ2ZuPWYzMDAw
IG1mbj1mOWEwMCBucj0yMDANCihYRU4pIFsyMDEyLTA5LTI0IDA4OjI1OjMzXSBtZW1vcnlf
bWFwOmFkZDogZG9tMTUgZ2ZuPWYzMDAwIG1mbj1mOWEwMCBucj0yMDANCihYRU4pIFsyMDEy
LTA5LTI0IDA4OjI1OjMzXSBtZW1vcnlfbWFwOnJlbW92ZTogZG9tMTUgZ2ZuPWYzMDAwIG1m
bj1mOWEwMCBucj0yMDANCihYRU4pIFsyMDEyLTA5LTI0IDA4OjI1OjMzXSBtZW1vcnlfbWFw
OmFkZDogZG9tMTUgZ2ZuPWYzMDAwIG1mbj1mOWEwMCBucj0yMDANCihYRU4pIFsyMDEyLTA5
LTI0IDA4OjI1OjMzXSBtZW1vcnlfbWFwOnJlbW92ZTogZG9tMTUgZ2ZuPWYzMDAwIG1mbj1m
OWEwMCBucj0yMDANCihYRU4pIFsyMDEyLTA5LTI0IDA4OjI1OjMzXSBtZW1vcnlfbWFwOmFk
ZDogZG9tMTUgZ2ZuPWYzMDAwIG1mbj1mOWEwMCBucj0yMDANCihYRU4pIFsyMDEyLTA5LTI0
IDA4OjI1OjMzXSBtZW1vcnlfbWFwOnJlbW92ZTogZG9tMTUgZ2ZuPWYzMDAwIG1mbj1mOWEw
MCBucj0yMDANCihYRU4pIFsyMDEyLTA5LTI0IDA4OjI1OjMzXSBtZW1vcnlfbWFwOmFkZDog
ZG9tMTUgZ2ZuPWYzMDAwIG1mbj1mOWEwMCBucj0yMDANCihYRU4pIFsyMDEyLTA5LTI0IDA4
OjI1OjMzXSBtZW1vcnlfbWFwOnJlbW92ZTogZG9tMTUgZ2ZuPWYzMDAwIG1mbj1mOWEwMCBu
cj0yMDANCihYRU4pIFsyMDEyLTA5LTI0IDA4OjI1OjMzXSBtZW1vcnlfbWFwOmFkZDogZG9t
MTUgZ2ZuPWYzMDAwIG1mbj1mOWEwMCBucj0yMDANCihYRU4pIFsyMDEyLTA5LTI0IDA4OjI1
OjM0XSBpcnEuYzoyNzA6IERvbTE1IFBDSSBsaW5rIDAgY2hhbmdlZCA1IC0+IDANCihYRU4p
IFsyMDEyLTA5LTI0IDA4OjI1OjM0XSBpcnEuYzoyNzA6IERvbTE1IFBDSSBsaW5rIDEgY2hh
bmdlZCAxMCAtPiAwDQooWEVOKSBbMjAxMi0wOS0yNCAwODoyNTozNF0gaXJxLmM6MjcwOiBE
b20xNSBQQ0kgbGluayAyIGNoYW5nZWQgMTEgLT4gMA0KKFhFTikgWzIwMTItMDktMjQgMDg6
MjU6MzRdIGlycS5jOjI3MDogRG9tMTUgUENJIGxpbmsgMyBjaGFuZ2VkIDUgLT4gMA0K
------------0E41640F726FFA493
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

------------0E41640F726FFA493--



From xen-devel-bounces@lists.xen.org Mon Sep 24 08:41:45 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Sep 2012 08:41:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TG4EH-0008UB-6z; Mon, 24 Sep 2012 08:41:25 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1TG4EF-0008Ty-KN
	for xen-devel@lists.xensource.com; Mon, 24 Sep 2012 08:41:23 +0000
Received: from [85.158.139.83:62105] by server-3.bemta-5.messagelabs.com id
	D8/C5-16108-2BC10605; Mon, 24 Sep 2012 08:41:22 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1348476075!32098615!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTA4NDk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29649 invoked from network); 24 Sep 2012 08:41: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;
	24 Sep 2012 08:41:16 -0000
X-IronPort-AV: E=Sophos;i="4.80,474,1344211200"; d="scan'208";a="14716039"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Sep 2012 08:41: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.279.1;
	Mon, 24 Sep 2012 09:41:06 +0100
Message-ID: <1348476065.3452.46.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
Date: Mon, 24 Sep 2012 09:41:05 +0100
In-Reply-To: <505CB69D.6070203@jhuapl.edu>
References: <505CB69D.6070203@jhuapl.edu>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] PATCH [base vtpm and libxl patches 0/6]
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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-09-21 at 19:49 +0100, Matthew Fioravante wrote:
> So it looks like I was basing my patches off of this tree
> git://xenbits.xen.org/xen-unstable.git 
> which is not actually xen-unstable.

Huh, I could have sworn I removed this old/unmaintained mirror out of
the way to somewhere less confusing. I shall really do so this time!

>  I rebased and reworked my patches off of the correct tree
> git://xenbits.xen.org/xen.git 

This is the currently maintained mirror. Note that the canonical source
for xen-unstable is the Mercurial tree at
http://xenbits.xen.org/hg/xen-unstable.hg and that git is just a mirror,
although we will be flipping that relationship around during this
development cycle.

> What follows are the vtpmd, vtpm_manager, and libxl patches. All of
> the mini-os patches apply cleanly to the latest xen so I won't be
> resubmitting those unless you all would want me to.

Thanks,

Today is a docs day[0] but I'll hopefully get to look at these soon.

Ian.
[0] http://lists.xen.org/archives/html/xen-devel/2012-09/msg01857.html


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 24 08:41:45 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Sep 2012 08:41:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TG4EH-0008UB-6z; Mon, 24 Sep 2012 08:41:25 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1TG4EF-0008Ty-KN
	for xen-devel@lists.xensource.com; Mon, 24 Sep 2012 08:41:23 +0000
Received: from [85.158.139.83:62105] by server-3.bemta-5.messagelabs.com id
	D8/C5-16108-2BC10605; Mon, 24 Sep 2012 08:41:22 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1348476075!32098615!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTA4NDk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29649 invoked from network); 24 Sep 2012 08:41: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;
	24 Sep 2012 08:41:16 -0000
X-IronPort-AV: E=Sophos;i="4.80,474,1344211200"; d="scan'208";a="14716039"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Sep 2012 08:41: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.279.1;
	Mon, 24 Sep 2012 09:41:06 +0100
Message-ID: <1348476065.3452.46.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
Date: Mon, 24 Sep 2012 09:41:05 +0100
In-Reply-To: <505CB69D.6070203@jhuapl.edu>
References: <505CB69D.6070203@jhuapl.edu>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] PATCH [base vtpm and libxl patches 0/6]
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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-09-21 at 19:49 +0100, Matthew Fioravante wrote:
> So it looks like I was basing my patches off of this tree
> git://xenbits.xen.org/xen-unstable.git 
> which is not actually xen-unstable.

Huh, I could have sworn I removed this old/unmaintained mirror out of
the way to somewhere less confusing. I shall really do so this time!

>  I rebased and reworked my patches off of the correct tree
> git://xenbits.xen.org/xen.git 

This is the currently maintained mirror. Note that the canonical source
for xen-unstable is the Mercurial tree at
http://xenbits.xen.org/hg/xen-unstable.hg and that git is just a mirror,
although we will be flipping that relationship around during this
development cycle.

> What follows are the vtpmd, vtpm_manager, and libxl patches. All of
> the mini-os patches apply cleanly to the latest xen so I won't be
> resubmitting those unless you all would want me to.

Thanks,

Today is a docs day[0] but I'll hopefully get to look at these soon.

Ian.
[0] http://lists.xen.org/archives/html/xen-devel/2012-09/msg01857.html


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 24 09:33:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Sep 2012 09:33:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TG524-0001Og-Ex; Mon, 24 Sep 2012 09:32: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 1TG523-0001Ob-OL
	for xen-devel@lists.xen.org; Mon, 24 Sep 2012 09:32:51 +0000
Received: from [85.158.143.35:5904] by server-1.bemta-4.messagelabs.com id
	59/5A-05684-3C820605; Mon, 24 Sep 2012 09:32:51 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1348479170!13381590!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30402 invoked from network); 24 Sep 2012 09:32:50 -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;
	24 Sep 2012 09:32:50 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 24 Sep 2012 10:32:49 +0100
Message-Id: <506044DE020000780009D40D@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 24 Sep 2012 10:32:46 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Campbell" <Ian.Campbell@citrix.com>
References: <osstest-13858-mainreport@xen.org>
	<1348475490.3452.36.camel@zakaz.uk.xensource.com>
In-Reply-To: <1348475490.3452.36.camel@zakaz.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "xen.org" <ian.jackson@eu.citrix.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [xen-unstable test] 13858: trouble:
 blocked/broken/pass
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 24.09.12 at 10:31, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> On Mon, 2012-09-24 at 03:17 +0100, xen.org wrote:
>> flight 13858 xen-unstable real [real]
>> http://www.chiark.greenend.org.uk/~xensrcts/logs/13858/ 
>> 
>> Failures and problems with tests :-(
>> 
>> Tests which did not succeed and are blocking,
>> including tests which could not be run:
>>  build-amd64                   2 host-install(2)         broken REGR. vs. 
> 13825
> 
> Jan, I guess this is most likely down to 25935:1e6e6b49b4ac "x86:
> introduce MWAIT-based, ACPI-less CPU idle driver"?

Yes, I would think so too. But rather than reverting it I'd prefer to
understand what's wrong (since I didn't see such problem on any
of my machines here). The stack state suggests that pm_idle is
being left at NULL, and it shouldn't be too difficult to figure out
why this is so. Give me a little time; I'll revert the patch if I can't
figure it reasonably quickly.

Jan

> Sep 24 01:35:46.025150 (XEN) ----[ Xen-4.3-unstable  x86_64  debug=y  Not 
> tainted ]----
> Sep 24 01:35:46.033069 (XEN) CPU:    1
> Sep 24 01:35:46.033107 (XEN) RIP:    e008:[<0000000000000000>] ???
> Sep 24 01:35:46.033155 (XEN) RFLAGS: 0000000000010046   CONTEXT: hypervisor
> Sep 24 01:35:46.045069 (XEN) rax: 0000000000000008   rbx: 0000000000000001   
> rcx: 0000000000000003
> Sep 24 01:35:46.053054 (XEN) rdx: 0000003db54eb700   rsi: 7fffffffffffffff   
> rdi: 0000000000000001
> Sep 24 01:35:46.053115 (XEN) rbp: ffff8302357e7ee0   rsp: ffff8302357e7e58   
> r8:  0000000000000000
> Sep 24 01:35:46.065475 (XEN) r9:  000000000000003e   r10: ffff8302357e7f18   
> r11: ffff8302357e7f18
> Sep 24 01:35:46.073056 (XEN) r12: ffff8302357ee340   r13: ffff82c480263980   
> r14: ffff8302357ee3d0
> Sep 24 01:35:46.073118 (XEN) r15: 0000000000000001   cr0: 000000008005003b   
> cr4: 00000000000026f0
> Sep 24 01:35:46.085106 (XEN) cr3: 00000000bf473000   cr2: 0000000000000000
> Sep 24 01:35:46.085158 (XEN) ds: 0000   es: 0000   fs: 0000   gs: 0000   ss: 
> 0000   cs: e008
> Sep 24 01:35:46.093483 (XEN) Xen stack trace from rsp=ffff8302357e7e58:
> Sep 24 01:35:46.093535 (XEN)    ffff82c4801a3d05 ffff8302357eca70 
> 0000000800000020 ffff82c4802ead60
> Sep 24 01:35:46.105490 (XEN)    0000000000000001 ffff8302357e7ea0 
> ffff82c48016bf07 0000000000000000
> Sep 24 01:35:46.113067 (XEN)    0000000000000000 ffff8302357e7ee0 
> fffff830fffff830 0000000000000046
> Sep 24 01:35:46.121329 (XEN)    ffff8302357e7f18 ffff82c480263980 
> ffff8302357e7f18 0000000000000000
> Sep 24 01:35:46.121391 (XEN)    0000000000000000 ffff8302357e7f10 
> ffff82c48015c2be 8302357dc0000fff
> Sep 24 01:35:46.133072 (XEN)    0000000000000001 0000000000000001 
> 0000000000000000 ffff8302357e7ee0
> Sep 24 01:35:46.141265 (XEN)    0000000000000000 0000000000000000 
> 0000000000000000 0000000000000000
> Sep 24 01:35:46.141324 (XEN)    0000000000000000 0000000000000000 
> 0000000000000000 0000000000000000
> Sep 24 01:35:46.153074 (XEN)    0000000000000000 0000000000000000 
> 0000000000000000 0000000000000000
> Sep 24 01:35:46.161216 (XEN)    0000000000000000 0000000000000000 
> 0000000000000000 0000000000000000
> Sep 24 01:35:46.161276 (XEN)    0000000000000000 0000000000000000 
> 0000000000000000 0000000000000000
> Sep 24 01:35:46.173076 (XEN)    0000000000000000 0000000000000000 
> 0000000000000000 0000000000000000
> Sep 24 01:35:46.181134 (XEN)    0000000000000000 0000000000000001 
> ffff8300bf2fe000 0000003db54eb700
> Sep 24 01:35:46.181195 (XEN)    0000000000000000
> Sep 24 01:35:46.193060 (XEN) Xen call trace:
> Sep 24 01:35:46.193101 (XEN)    [<0000000000000000>] ???
> Sep 24 01:35:46.193181 (XEN)    [<ffff82c48015c2be>] idle_loop+0x6c/0x7a
> Sep 24 01:35:46.193233 (XEN)    
> Sep 24 01:35:46.201065 (XEN) Pagetable walk from 0000000000000000:
> Sep 24 01:35:46.201114 (XEN)  L4[0x000] = 000000023b201063 ffffffffffffffff
> Sep 24 01:35:46.201165 (XEN)  L3[0x000] = 000000023b200063 ffffffffffffffff
> Sep 24 01:35:46.213078 (XEN)  L2[0x000] = 00000002357ff063 ffffffffffffffff 
> Sep 24 01:35:46.213130 (XEN)  L1[0x000] = 0000000000000000 ffffffffffffffff
> Sep 24 01:35:46.217068 (XEN) 
> Sep 24 01:35:46.217102 (XEN) ****************************************
> Sep 24 01:35:46.225485 (XEN) Panic on CPU 1:
> Sep 24 01:35:46.225526 (XEN) FATAL PAGE FAULT
> Sep 24 01:35:46.229059 (XEN) [error_code=0010]
> Sep 24 01:35:46.233466 (XEN) Faulting linear address: 0000000000000000
> Sep 24 01:35:46.237480 (XEN) ****************************************


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 24 09:33:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Sep 2012 09:33:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TG524-0001Og-Ex; Mon, 24 Sep 2012 09:32: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 1TG523-0001Ob-OL
	for xen-devel@lists.xen.org; Mon, 24 Sep 2012 09:32:51 +0000
Received: from [85.158.143.35:5904] by server-1.bemta-4.messagelabs.com id
	59/5A-05684-3C820605; Mon, 24 Sep 2012 09:32:51 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1348479170!13381590!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30402 invoked from network); 24 Sep 2012 09:32:50 -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;
	24 Sep 2012 09:32:50 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 24 Sep 2012 10:32:49 +0100
Message-Id: <506044DE020000780009D40D@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 24 Sep 2012 10:32:46 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Campbell" <Ian.Campbell@citrix.com>
References: <osstest-13858-mainreport@xen.org>
	<1348475490.3452.36.camel@zakaz.uk.xensource.com>
In-Reply-To: <1348475490.3452.36.camel@zakaz.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "xen.org" <ian.jackson@eu.citrix.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [xen-unstable test] 13858: trouble:
 blocked/broken/pass
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 24.09.12 at 10:31, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> On Mon, 2012-09-24 at 03:17 +0100, xen.org wrote:
>> flight 13858 xen-unstable real [real]
>> http://www.chiark.greenend.org.uk/~xensrcts/logs/13858/ 
>> 
>> Failures and problems with tests :-(
>> 
>> Tests which did not succeed and are blocking,
>> including tests which could not be run:
>>  build-amd64                   2 host-install(2)         broken REGR. vs. 
> 13825
> 
> Jan, I guess this is most likely down to 25935:1e6e6b49b4ac "x86:
> introduce MWAIT-based, ACPI-less CPU idle driver"?

Yes, I would think so too. But rather than reverting it I'd prefer to
understand what's wrong (since I didn't see such problem on any
of my machines here). The stack state suggests that pm_idle is
being left at NULL, and it shouldn't be too difficult to figure out
why this is so. Give me a little time; I'll revert the patch if I can't
figure it reasonably quickly.

Jan

> Sep 24 01:35:46.025150 (XEN) ----[ Xen-4.3-unstable  x86_64  debug=y  Not 
> tainted ]----
> Sep 24 01:35:46.033069 (XEN) CPU:    1
> Sep 24 01:35:46.033107 (XEN) RIP:    e008:[<0000000000000000>] ???
> Sep 24 01:35:46.033155 (XEN) RFLAGS: 0000000000010046   CONTEXT: hypervisor
> Sep 24 01:35:46.045069 (XEN) rax: 0000000000000008   rbx: 0000000000000001   
> rcx: 0000000000000003
> Sep 24 01:35:46.053054 (XEN) rdx: 0000003db54eb700   rsi: 7fffffffffffffff   
> rdi: 0000000000000001
> Sep 24 01:35:46.053115 (XEN) rbp: ffff8302357e7ee0   rsp: ffff8302357e7e58   
> r8:  0000000000000000
> Sep 24 01:35:46.065475 (XEN) r9:  000000000000003e   r10: ffff8302357e7f18   
> r11: ffff8302357e7f18
> Sep 24 01:35:46.073056 (XEN) r12: ffff8302357ee340   r13: ffff82c480263980   
> r14: ffff8302357ee3d0
> Sep 24 01:35:46.073118 (XEN) r15: 0000000000000001   cr0: 000000008005003b   
> cr4: 00000000000026f0
> Sep 24 01:35:46.085106 (XEN) cr3: 00000000bf473000   cr2: 0000000000000000
> Sep 24 01:35:46.085158 (XEN) ds: 0000   es: 0000   fs: 0000   gs: 0000   ss: 
> 0000   cs: e008
> Sep 24 01:35:46.093483 (XEN) Xen stack trace from rsp=ffff8302357e7e58:
> Sep 24 01:35:46.093535 (XEN)    ffff82c4801a3d05 ffff8302357eca70 
> 0000000800000020 ffff82c4802ead60
> Sep 24 01:35:46.105490 (XEN)    0000000000000001 ffff8302357e7ea0 
> ffff82c48016bf07 0000000000000000
> Sep 24 01:35:46.113067 (XEN)    0000000000000000 ffff8302357e7ee0 
> fffff830fffff830 0000000000000046
> Sep 24 01:35:46.121329 (XEN)    ffff8302357e7f18 ffff82c480263980 
> ffff8302357e7f18 0000000000000000
> Sep 24 01:35:46.121391 (XEN)    0000000000000000 ffff8302357e7f10 
> ffff82c48015c2be 8302357dc0000fff
> Sep 24 01:35:46.133072 (XEN)    0000000000000001 0000000000000001 
> 0000000000000000 ffff8302357e7ee0
> Sep 24 01:35:46.141265 (XEN)    0000000000000000 0000000000000000 
> 0000000000000000 0000000000000000
> Sep 24 01:35:46.141324 (XEN)    0000000000000000 0000000000000000 
> 0000000000000000 0000000000000000
> Sep 24 01:35:46.153074 (XEN)    0000000000000000 0000000000000000 
> 0000000000000000 0000000000000000
> Sep 24 01:35:46.161216 (XEN)    0000000000000000 0000000000000000 
> 0000000000000000 0000000000000000
> Sep 24 01:35:46.161276 (XEN)    0000000000000000 0000000000000000 
> 0000000000000000 0000000000000000
> Sep 24 01:35:46.173076 (XEN)    0000000000000000 0000000000000000 
> 0000000000000000 0000000000000000
> Sep 24 01:35:46.181134 (XEN)    0000000000000000 0000000000000001 
> ffff8300bf2fe000 0000003db54eb700
> Sep 24 01:35:46.181195 (XEN)    0000000000000000
> Sep 24 01:35:46.193060 (XEN) Xen call trace:
> Sep 24 01:35:46.193101 (XEN)    [<0000000000000000>] ???
> Sep 24 01:35:46.193181 (XEN)    [<ffff82c48015c2be>] idle_loop+0x6c/0x7a
> Sep 24 01:35:46.193233 (XEN)    
> Sep 24 01:35:46.201065 (XEN) Pagetable walk from 0000000000000000:
> Sep 24 01:35:46.201114 (XEN)  L4[0x000] = 000000023b201063 ffffffffffffffff
> Sep 24 01:35:46.201165 (XEN)  L3[0x000] = 000000023b200063 ffffffffffffffff
> Sep 24 01:35:46.213078 (XEN)  L2[0x000] = 00000002357ff063 ffffffffffffffff 
> Sep 24 01:35:46.213130 (XEN)  L1[0x000] = 0000000000000000 ffffffffffffffff
> Sep 24 01:35:46.217068 (XEN) 
> Sep 24 01:35:46.217102 (XEN) ****************************************
> Sep 24 01:35:46.225485 (XEN) Panic on CPU 1:
> Sep 24 01:35:46.225526 (XEN) FATAL PAGE FAULT
> Sep 24 01:35:46.229059 (XEN) [error_code=0010]
> Sep 24 01:35:46.233466 (XEN) Faulting linear address: 0000000000000000
> Sep 24 01:35:46.237480 (XEN) ****************************************


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 24 10:25:02 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Sep 2012 10: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 1TG5qB-00027t-Dl; Mon, 24 Sep 2012 10:24:39 +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 1TG5q9-00027o-Bi
	for xen-devel@lists.xensource.com; Mon, 24 Sep 2012 10:24:37 +0000
Received: from [85.158.138.51:11779] by server-5.bemta-3.messagelabs.com id
	B1/80-13133-4E430605; Mon, 24 Sep 2012 10:24:36 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1348482274!25395896!1
X-Originating-IP: [143.182.124.21]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMjEgPT4gMjA3NjEw\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18476 invoked from network); 24 Sep 2012 10:24:35 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (143.182.124.21)
	by server-14.tower-174.messagelabs.com with SMTP;
	24 Sep 2012 10:24:35 -0000
Received: from azsmga002.ch.intel.com ([10.2.17.35])
	by azsmga101.ch.intel.com with ESMTP; 24 Sep 2012 03:24:34 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.80,474,1344236400"; d="scan'208";a="148341206"
Received: from fmsmsx103.amr.corp.intel.com ([10.19.9.34])
	by AZSMGA002.ch.intel.com with ESMTP; 24 Sep 2012 03:24:33 -0700
Received: from fmsmsx102.amr.corp.intel.com (10.19.9.53) by
	FMSMSX103.amr.corp.intel.com (10.19.9.34) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Mon, 24 Sep 2012 03:24:33 -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; Mon, 24 Sep 2012 03:24:33 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.239]) by
	SHSMSX102.ccr.corp.intel.com ([169.254.2.92]) with mapi id
	14.01.0355.002; Mon, 24 Sep 2012 18:24:31 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: Christoph Egger <Christoph.Egger@amd.com>
Thread-Topic: comments for c/s 25919 Xen mce
Thread-Index: AQHNl8yym0PxwQPZS1qiRYz6p8f4j5eZTODw
Date: Mon, 24 Sep 2012 10:24:30 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC82923353384C1@SHSMSX101.ccr.corp.intel.com>
References: <DE8DF0795D48FD4CA783C40EC8292335332DA5@SHSMSX101.ccr.corp.intel.com>
	<505C1A79.9060100@amd.com>
In-Reply-To: <505C1A79.9060100@amd.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"keir@xen.org" <keir@xen.org>,
	"Ian.Campbell@citrix.com" <Ian.Campbell@citrix.com>,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] comments for c/s 25919 Xen mce
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 wrote:
> On 09/21/12 08:44, Liu, Jinsong wrote:
> 
>> Christoph, Keir, Jan
>> 
>> I have a draft look at c/s 25919. It moves some mce_intel.c logic to
>> mce.c (and remove old mce.c logic). By draft reviewing the patch I
>> think it need more work to do, and currently it in fact would hung
>> at AMD platform (I have no AMD platform to test), i.e,
>> MACHINE_CHECK_SOFTIRQ --> mce_delayed_action() --> mce_action() -->
>> ASSERT(handler_num);     
>> 
>> For AMD mce it may need add (if any misunderstanding please point to
>> me) 1). add default handler which used at softirq context
> 
> 
> This is mcee_softirq().
> 
>> 2). add AMD vmce inject logic
> 
> 
> Yes, patch is sent.
> See http://lists.xen.org/archives/html/xen-devel/2012-09/msg01413.html
> 
>> 3). more test
> 
> 
> There are more patches in my queue.
> 
> Christoph
> 

So, Christoph, considering you have a patches queue and would change more mce/vmce, how about wait a moment and then based your patches on my vmce patches? My vmce patches have been posted for quite some time, and have already been reviewed-rebased-tested several rounds. I think they are basically stable now, currently only need tools maintainers to have review patch4/5 (live migration tools part).

... I know I have no right asking you to do so, but we need cooperate for mce/vmce, and if you agree I would be very much appreciated. As for your mce/vmce patches, I'd like to help test at Intel's platform to make sure it works fine.

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 Sep 24 10:25:02 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Sep 2012 10: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 1TG5qB-00027t-Dl; Mon, 24 Sep 2012 10:24:39 +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 1TG5q9-00027o-Bi
	for xen-devel@lists.xensource.com; Mon, 24 Sep 2012 10:24:37 +0000
Received: from [85.158.138.51:11779] by server-5.bemta-3.messagelabs.com id
	B1/80-13133-4E430605; Mon, 24 Sep 2012 10:24:36 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1348482274!25395896!1
X-Originating-IP: [143.182.124.21]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMjEgPT4gMjA3NjEw\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18476 invoked from network); 24 Sep 2012 10:24:35 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (143.182.124.21)
	by server-14.tower-174.messagelabs.com with SMTP;
	24 Sep 2012 10:24:35 -0000
Received: from azsmga002.ch.intel.com ([10.2.17.35])
	by azsmga101.ch.intel.com with ESMTP; 24 Sep 2012 03:24:34 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.80,474,1344236400"; d="scan'208";a="148341206"
Received: from fmsmsx103.amr.corp.intel.com ([10.19.9.34])
	by AZSMGA002.ch.intel.com with ESMTP; 24 Sep 2012 03:24:33 -0700
Received: from fmsmsx102.amr.corp.intel.com (10.19.9.53) by
	FMSMSX103.amr.corp.intel.com (10.19.9.34) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Mon, 24 Sep 2012 03:24:33 -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; Mon, 24 Sep 2012 03:24:33 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.239]) by
	SHSMSX102.ccr.corp.intel.com ([169.254.2.92]) with mapi id
	14.01.0355.002; Mon, 24 Sep 2012 18:24:31 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: Christoph Egger <Christoph.Egger@amd.com>
Thread-Topic: comments for c/s 25919 Xen mce
Thread-Index: AQHNl8yym0PxwQPZS1qiRYz6p8f4j5eZTODw
Date: Mon, 24 Sep 2012 10:24:30 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC82923353384C1@SHSMSX101.ccr.corp.intel.com>
References: <DE8DF0795D48FD4CA783C40EC8292335332DA5@SHSMSX101.ccr.corp.intel.com>
	<505C1A79.9060100@amd.com>
In-Reply-To: <505C1A79.9060100@amd.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"keir@xen.org" <keir@xen.org>,
	"Ian.Campbell@citrix.com" <Ian.Campbell@citrix.com>,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] comments for c/s 25919 Xen mce
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 wrote:
> On 09/21/12 08:44, Liu, Jinsong wrote:
> 
>> Christoph, Keir, Jan
>> 
>> I have a draft look at c/s 25919. It moves some mce_intel.c logic to
>> mce.c (and remove old mce.c logic). By draft reviewing the patch I
>> think it need more work to do, and currently it in fact would hung
>> at AMD platform (I have no AMD platform to test), i.e,
>> MACHINE_CHECK_SOFTIRQ --> mce_delayed_action() --> mce_action() -->
>> ASSERT(handler_num);     
>> 
>> For AMD mce it may need add (if any misunderstanding please point to
>> me) 1). add default handler which used at softirq context
> 
> 
> This is mcee_softirq().
> 
>> 2). add AMD vmce inject logic
> 
> 
> Yes, patch is sent.
> See http://lists.xen.org/archives/html/xen-devel/2012-09/msg01413.html
> 
>> 3). more test
> 
> 
> There are more patches in my queue.
> 
> Christoph
> 

So, Christoph, considering you have a patches queue and would change more mce/vmce, how about wait a moment and then based your patches on my vmce patches? My vmce patches have been posted for quite some time, and have already been reviewed-rebased-tested several rounds. I think they are basically stable now, currently only need tools maintainers to have review patch4/5 (live migration tools part).

... I know I have no right asking you to do so, but we need cooperate for mce/vmce, and if you agree I would be very much appreciated. As for your mce/vmce patches, I'd like to help test at Intel's platform to make sure it works fine.

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 Sep 24 10:30:49 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Sep 2012 10:30:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TG5vm-0002Gq-Ch; Mon, 24 Sep 2012 10:30: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 1TG5vl-0002Gl-84
	for xen-devel@lists.xensource.com; Mon, 24 Sep 2012 10:30:25 +0000
Received: from [85.158.143.99:61771] by server-1.bemta-4.messagelabs.com id
	89/57-05684-04630605; Mon, 24 Sep 2012 10:30:24 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1348482622!26237921!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTA4NDk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30931 invoked from network); 24 Sep 2012 10:30:23 -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;
	24 Sep 2012 10:30:23 -0000
X-IronPort-AV: E=Sophos;i="4.80,474,1344211200"; d="scan'208";a="14719468"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Sep 2012 10:30: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.279.1; Mon, 24 Sep 2012 11:30: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
	1TG5vh-0008IT-Nr; Mon, 24 Sep 2012 10:30:21 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1TG5vh-0006Ep-HL;
	Mon, 24 Sep 2012 11:30:21 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20576.13885.190051.170343@mariner.uk.xensource.com>
Date: Mon, 24 Sep 2012 11:30:21 +0100
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1348475490.3452.36.camel@zakaz.uk.xensource.com>
References: <osstest-13858-mainreport@xen.org>
	<1348475490.3452.36.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>,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [xen-unstable test] 13858: trouble:
 blocked/broken/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

Ian Campbell writes ("Re: [Xen-devel] [xen-unstable test] 13858: trouble: blocked/broken/pass"):
> On Mon, 2012-09-24 at 03:17 +0100, xen.org wrote:
> > flight 13858 xen-unstable real [real]
> > http://www.chiark.greenend.org.uk/~xensrcts/logs/13858/
> > 
> > Failures and problems with tests :-(
> > 
> > Tests which did not succeed and are blocking,
> > including tests which could not be run:
> >  build-amd64                   2 host-install(2)         broken REGR. vs. 13825
> 
> Jan, I guess this is most likely down to 25935:1e6e6b49b4ac "x86:
> introduce MWAIT-based, ACPI-less CPU idle driver"?

As we've discussed elsewhere, this is appearing in this test due to
the box having forgotten that it is supposed to boot from the network.
This plus the Xen bug you see means it has got stuck in a reboot loop
despite the test system's attempts to reuse the box.

We think the Xen bug showed up in 13848:

http://www.chiark.greenend.org.uk/~xensrcts/logs/13848/test-amd64-i386-xl-win7-amd64/info.html

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 24 10:30:49 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Sep 2012 10:30:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TG5vm-0002Gq-Ch; Mon, 24 Sep 2012 10:30: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 1TG5vl-0002Gl-84
	for xen-devel@lists.xensource.com; Mon, 24 Sep 2012 10:30:25 +0000
Received: from [85.158.143.99:61771] by server-1.bemta-4.messagelabs.com id
	89/57-05684-04630605; Mon, 24 Sep 2012 10:30:24 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1348482622!26237921!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTA4NDk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30931 invoked from network); 24 Sep 2012 10:30:23 -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;
	24 Sep 2012 10:30:23 -0000
X-IronPort-AV: E=Sophos;i="4.80,474,1344211200"; d="scan'208";a="14719468"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Sep 2012 10:30: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.279.1; Mon, 24 Sep 2012 11:30: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
	1TG5vh-0008IT-Nr; Mon, 24 Sep 2012 10:30:21 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1TG5vh-0006Ep-HL;
	Mon, 24 Sep 2012 11:30:21 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20576.13885.190051.170343@mariner.uk.xensource.com>
Date: Mon, 24 Sep 2012 11:30:21 +0100
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1348475490.3452.36.camel@zakaz.uk.xensource.com>
References: <osstest-13858-mainreport@xen.org>
	<1348475490.3452.36.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>,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [xen-unstable test] 13858: trouble:
 blocked/broken/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

Ian Campbell writes ("Re: [Xen-devel] [xen-unstable test] 13858: trouble: blocked/broken/pass"):
> On Mon, 2012-09-24 at 03:17 +0100, xen.org wrote:
> > flight 13858 xen-unstable real [real]
> > http://www.chiark.greenend.org.uk/~xensrcts/logs/13858/
> > 
> > Failures and problems with tests :-(
> > 
> > Tests which did not succeed and are blocking,
> > including tests which could not be run:
> >  build-amd64                   2 host-install(2)         broken REGR. vs. 13825
> 
> Jan, I guess this is most likely down to 25935:1e6e6b49b4ac "x86:
> introduce MWAIT-based, ACPI-less CPU idle driver"?

As we've discussed elsewhere, this is appearing in this test due to
the box having forgotten that it is supposed to boot from the network.
This plus the Xen bug you see means it has got stuck in a reboot loop
despite the test system's attempts to reuse the box.

We think the Xen bug showed up in 13848:

http://www.chiark.greenend.org.uk/~xensrcts/logs/13848/test-amd64-i386-xl-win7-amd64/info.html

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 24 10:47:22 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Sep 2012 10:47: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 1TG6Bp-0002Ud-VC; Mon, 24 Sep 2012 10:47:02 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1TG6Bo-0002UY-DY
	for xen-devel@lists.xensource.com; Mon, 24 Sep 2012 10:47:00 +0000
Received: from [85.158.138.51:37826] by server-12.bemta-3.messagelabs.com id
	3C/86-10384-32A30605; Mon, 24 Sep 2012 10:46:59 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1348483617!23702006!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNzcwMDM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26392 invoked from network); 24 Sep 2012 10:46:59 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-6.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Sep 2012 10:46:59 -0000
X-IronPort-AV: E=Sophos;i="4.80,474,1344211200"; d="scan'208";a="209104560"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Sep 2012 10:46:57 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1;
	Mon, 24 Sep 2012 06:46:56 -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 1TG6Bf-0006cA-Bq;
	Mon, 24 Sep 2012 11:46:51 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: linux-kernel@vger.kernel.org
Date: Mon, 24 Sep 2012 11:46:14 +0100
Message-ID: <1348483574-7901-1-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.9.5
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com, Ian.Campbell@citrix.com, pawel.moll@arm.com,
	konrad.wilk@oracle.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	arnd@arndb.de, linux-arm-kernel@lists.infradead.org
Subject: [Xen-devel] [PATCH v3 1/1] arm: introduce a DTS for Xen
	unprivileged virtual 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

Given that the xenvm machine is based on vexpress but with an extremely
limited selection of peripherals (the guest is supposed to use virtual
devices instead), add "xen,xenvm" to the list of compatible machines in
mach-vexpress.


Changes in v3:

- add comments to mark fields that are likely to be changed by the
hypervisor.


Changes in v2:

- remove include skeleton;
- use #address-cells = <2> and #size-cells = <2>;
- remove the debug bootargs;
- use memory@80000000 instead of memory;
- remove the ranges and interrupt-map from the motherboard node;
- set the machine compatible to "xen,xenvm-4.2", "xen,xenvm";
- rename the dts file to xenvm-4.2.dts;
- add "xen,xenvm" to the list of compatible DT strings to mach-vexpress.


Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Acked-by: Pawel Moll <pawel.moll@arm.com> (v2m changes)
CC: Arnd Bergmann <arnd@arndb.de>
---
 arch/arm/boot/dts/xenvm-4.2.dts      |   68 ++++++++++++++++++++++++++++++++++
 arch/arm/mach-vexpress/Makefile.boot |    3 +-
 arch/arm/mach-vexpress/v2m.c         |    1 +
 3 files changed, 71 insertions(+), 1 deletions(-)
 create mode 100644 arch/arm/boot/dts/xenvm-4.2.dts

diff --git a/arch/arm/boot/dts/xenvm-4.2.dts b/arch/arm/boot/dts/xenvm-4.2.dts
new file mode 100644
index 0000000..ec3f952
--- /dev/null
+++ b/arch/arm/boot/dts/xenvm-4.2.dts
@@ -0,0 +1,68 @@
+/*
+ * Xen Virtual Machine for unprivileged guests
+ *
+ * Based on ARM Ltd. Versatile Express CoreTile Express (single CPU)
+ * Cortex-A15 MPCore (V2P-CA15)
+ *
+ */
+
+/dts-v1/;
+
+/ {
+	model = "XENVM-4.2";
+	compatible = "xen,xenvm-4.2", "xen,xenvm";
+	interrupt-parent = <&gic>;
+	#address-cells = <2>;
+	#size-cells = <2>;
+
+	chosen {
+		/* this field is going to be adjusted by the hypervisor */
+		bootargs = "console=hvc0 root=/dev/xvda";
+	};
+
+	cpus {
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		cpu@0 {
+			device_type = "cpu";
+			compatible = "arm,cortex-a15";
+			reg = <0>;
+		};
+	};
+
+	memory@80000000 {
+		device_type = "memory";
+		/* this field is going to be adjusted by the hypervisor */
+		reg = <0 0x80000000 0 0x08000000>;
+	};
+
+	gic: interrupt-controller@2c001000 {
+		compatible = "arm,cortex-a15-gic", "arm,cortex-a9-gic";
+		#interrupt-cells = <3>;
+		#address-cells = <0>;
+		interrupt-controller;
+		reg = <0 0x2c001000 0 0x1000>,
+		      <0 0x2c002000 0 0x100>;
+	};
+
+	timer {
+		compatible = "arm,armv7-timer";
+		interrupts = <1 13 0xf08>,
+			     <1 14 0xf08>,
+			     <1 11 0xf08>,
+			     <1 10 0xf08>;
+	};
+
+	hypervisor {
+		compatible = "xen,xen-4.2", "xen,xen";
+		/* this field is going to be adjusted by the hypervisor */
+		reg = <0 0xb0000000 0 0x20000>;
+		/* this field is going to be adjusted by the hypervisor */
+		interrupts = <1 15 0xf08>;
+	};
+
+	motherboard {
+		arm,v2m-memory-map = "rs1";
+	};
+};
diff --git a/arch/arm/mach-vexpress/Makefile.boot b/arch/arm/mach-vexpress/Makefile.boot
index 318d308..38dbaac 100644
--- a/arch/arm/mach-vexpress/Makefile.boot
+++ b/arch/arm/mach-vexpress/Makefile.boot
@@ -7,4 +7,5 @@ initrd_phys-y	:= 0x60800000
 dtb-$(CONFIG_ARCH_VEXPRESS_DT)	+= vexpress-v2p-ca5s.dtb \
 				   vexpress-v2p-ca9.dtb \
 				   vexpress-v2p-ca15-tc1.dtb \
-				   vexpress-v2p-ca15_a7.dtb
+				   vexpress-v2p-ca15_a7.dtb \
+				   xenvm-4.2.dtb
diff --git a/arch/arm/mach-vexpress/v2m.c b/arch/arm/mach-vexpress/v2m.c
index 4e567f7..9545b70 100644
--- a/arch/arm/mach-vexpress/v2m.c
+++ b/arch/arm/mach-vexpress/v2m.c
@@ -659,6 +659,7 @@ static void __init v2m_dt_init(void)
 
 const static char *v2m_dt_match[] __initconst = {
 	"arm,vexpress",
+	"xen,xenvm",
 	NULL,
 };
 
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 24 10:47:22 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Sep 2012 10:47: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 1TG6Bp-0002Ud-VC; Mon, 24 Sep 2012 10:47:02 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1TG6Bo-0002UY-DY
	for xen-devel@lists.xensource.com; Mon, 24 Sep 2012 10:47:00 +0000
Received: from [85.158.138.51:37826] by server-12.bemta-3.messagelabs.com id
	3C/86-10384-32A30605; Mon, 24 Sep 2012 10:46:59 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1348483617!23702006!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNzcwMDM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26392 invoked from network); 24 Sep 2012 10:46:59 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-6.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Sep 2012 10:46:59 -0000
X-IronPort-AV: E=Sophos;i="4.80,474,1344211200"; d="scan'208";a="209104560"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Sep 2012 10:46:57 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1;
	Mon, 24 Sep 2012 06:46:56 -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 1TG6Bf-0006cA-Bq;
	Mon, 24 Sep 2012 11:46:51 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: linux-kernel@vger.kernel.org
Date: Mon, 24 Sep 2012 11:46:14 +0100
Message-ID: <1348483574-7901-1-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.9.5
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com, Ian.Campbell@citrix.com, pawel.moll@arm.com,
	konrad.wilk@oracle.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	arnd@arndb.de, linux-arm-kernel@lists.infradead.org
Subject: [Xen-devel] [PATCH v3 1/1] arm: introduce a DTS for Xen
	unprivileged virtual 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

Given that the xenvm machine is based on vexpress but with an extremely
limited selection of peripherals (the guest is supposed to use virtual
devices instead), add "xen,xenvm" to the list of compatible machines in
mach-vexpress.


Changes in v3:

- add comments to mark fields that are likely to be changed by the
hypervisor.


Changes in v2:

- remove include skeleton;
- use #address-cells = <2> and #size-cells = <2>;
- remove the debug bootargs;
- use memory@80000000 instead of memory;
- remove the ranges and interrupt-map from the motherboard node;
- set the machine compatible to "xen,xenvm-4.2", "xen,xenvm";
- rename the dts file to xenvm-4.2.dts;
- add "xen,xenvm" to the list of compatible DT strings to mach-vexpress.


Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Acked-by: Pawel Moll <pawel.moll@arm.com> (v2m changes)
CC: Arnd Bergmann <arnd@arndb.de>
---
 arch/arm/boot/dts/xenvm-4.2.dts      |   68 ++++++++++++++++++++++++++++++++++
 arch/arm/mach-vexpress/Makefile.boot |    3 +-
 arch/arm/mach-vexpress/v2m.c         |    1 +
 3 files changed, 71 insertions(+), 1 deletions(-)
 create mode 100644 arch/arm/boot/dts/xenvm-4.2.dts

diff --git a/arch/arm/boot/dts/xenvm-4.2.dts b/arch/arm/boot/dts/xenvm-4.2.dts
new file mode 100644
index 0000000..ec3f952
--- /dev/null
+++ b/arch/arm/boot/dts/xenvm-4.2.dts
@@ -0,0 +1,68 @@
+/*
+ * Xen Virtual Machine for unprivileged guests
+ *
+ * Based on ARM Ltd. Versatile Express CoreTile Express (single CPU)
+ * Cortex-A15 MPCore (V2P-CA15)
+ *
+ */
+
+/dts-v1/;
+
+/ {
+	model = "XENVM-4.2";
+	compatible = "xen,xenvm-4.2", "xen,xenvm";
+	interrupt-parent = <&gic>;
+	#address-cells = <2>;
+	#size-cells = <2>;
+
+	chosen {
+		/* this field is going to be adjusted by the hypervisor */
+		bootargs = "console=hvc0 root=/dev/xvda";
+	};
+
+	cpus {
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		cpu@0 {
+			device_type = "cpu";
+			compatible = "arm,cortex-a15";
+			reg = <0>;
+		};
+	};
+
+	memory@80000000 {
+		device_type = "memory";
+		/* this field is going to be adjusted by the hypervisor */
+		reg = <0 0x80000000 0 0x08000000>;
+	};
+
+	gic: interrupt-controller@2c001000 {
+		compatible = "arm,cortex-a15-gic", "arm,cortex-a9-gic";
+		#interrupt-cells = <3>;
+		#address-cells = <0>;
+		interrupt-controller;
+		reg = <0 0x2c001000 0 0x1000>,
+		      <0 0x2c002000 0 0x100>;
+	};
+
+	timer {
+		compatible = "arm,armv7-timer";
+		interrupts = <1 13 0xf08>,
+			     <1 14 0xf08>,
+			     <1 11 0xf08>,
+			     <1 10 0xf08>;
+	};
+
+	hypervisor {
+		compatible = "xen,xen-4.2", "xen,xen";
+		/* this field is going to be adjusted by the hypervisor */
+		reg = <0 0xb0000000 0 0x20000>;
+		/* this field is going to be adjusted by the hypervisor */
+		interrupts = <1 15 0xf08>;
+	};
+
+	motherboard {
+		arm,v2m-memory-map = "rs1";
+	};
+};
diff --git a/arch/arm/mach-vexpress/Makefile.boot b/arch/arm/mach-vexpress/Makefile.boot
index 318d308..38dbaac 100644
--- a/arch/arm/mach-vexpress/Makefile.boot
+++ b/arch/arm/mach-vexpress/Makefile.boot
@@ -7,4 +7,5 @@ initrd_phys-y	:= 0x60800000
 dtb-$(CONFIG_ARCH_VEXPRESS_DT)	+= vexpress-v2p-ca5s.dtb \
 				   vexpress-v2p-ca9.dtb \
 				   vexpress-v2p-ca15-tc1.dtb \
-				   vexpress-v2p-ca15_a7.dtb
+				   vexpress-v2p-ca15_a7.dtb \
+				   xenvm-4.2.dtb
diff --git a/arch/arm/mach-vexpress/v2m.c b/arch/arm/mach-vexpress/v2m.c
index 4e567f7..9545b70 100644
--- a/arch/arm/mach-vexpress/v2m.c
+++ b/arch/arm/mach-vexpress/v2m.c
@@ -659,6 +659,7 @@ static void __init v2m_dt_init(void)
 
 const static char *v2m_dt_match[] __initconst = {
 	"arm,vexpress",
+	"xen,xenvm",
 	NULL,
 };
 
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 24 10:49:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Sep 2012 10: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 1TG6DU-0002Zh-9A; Mon, 24 Sep 2012 10:48: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 1TG6DS-0002ZV-P7
	for xen-devel@lists.xen.org; Mon, 24 Sep 2012 10:48:42 +0000
Received: from [85.158.143.99:40835] by server-1.bemta-4.messagelabs.com id
	59/F8-05684-98A30605; Mon, 24 Sep 2012 10:48:41 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1348483721!31191442!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30086 invoked from network); 24 Sep 2012 10:48:41 -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;
	24 Sep 2012 10:48:41 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 24 Sep 2012 11:48:41 +0100
Message-Id: <506056A6020000780009D453@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 24 Sep 2012 11:48:38 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Konrad Rzeszutek Wilk" <konrad@kernel.org>
References: <504F3F8A020000780009A8F9@nat28.tlf.novell.com>
	<20120921163406.GC4780@phenom.dumpdata.com>
In-Reply-To: <20120921163406.GC4780@phenom.dumpdata.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] x86: retrieve keyboard shift status flags
 from BIOS
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 21.09.12 at 18:34, Konrad Rzeszutek Wilk <konrad@kernel.org> wrote:
> And here is a variant for the upstream:
> 
> From 21b4fdf0592156ac3020f5c492139368dcdfcf71 Mon Sep 17 00:00:00 2001
> From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> Date: Fri, 21 Sep 2012 12:30:35 -0400
> Subject: [PATCH] xen/x86: retrieve keyboard shift status flags from
>  hypervisor.
> 
> The xen c/s 25873 allows the hypervisor to retrieve the NUMLOCK flag.
> With this patch, the Linux kernel can get the state according to the
> data in the BIOS.
> 
> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

Acked-by: Jan Beulich <jbeulich@suse.com>

(but also see below)

> --- a/arch/x86/xen/enlighten.c
> +++ b/arch/x86/xen/enlighten.c
> @@ -1441,11 +1441,19 @@ asmlinkage void __init xen_start_kernel(void)
>  		const struct dom0_vga_console_info *info =
>  			(void *)((char *)xen_start_info +
>  				 xen_start_info->console.dom0.info_off);
> +		struct xen_platform_op op = {
> +			.cmd = XENPF_firmware_info,
> +			.interface_version = XENPF_INTERFACE_VERSION,
> +			.u.firmware_info.type = XEN_FW_KBD_SHIFT_FLAGS,
> +		};
>  
>  		xen_init_vga(info, xen_start_info->console.dom0.info_size);
>  		xen_start_info->console.domU.mfn = 0;
>  		xen_start_info->console.domU.evtchn = 0;
>  
> +		if (HYPERVISOR_dom0_op(&op) == 0)
> +			boot_params.kbd_status = op.u.firmware_info.u.kbd_shift_flags;
> +
>  		xen_init_apic();
>  
>  		/* Make sure ACS will be enabled */
> diff --git a/include/xen/interface/platform.h 
> b/include/xen/interface/platform.h
> index 61fa661..81eee3b 100644
> --- a/include/xen/interface/platform.h
> +++ b/include/xen/interface/platform.h
> @@ -112,6 +112,7 @@ DEFINE_GUEST_HANDLE_STRUCT(xenpf_platform_quirk_t);
>  #define XEN_FW_DISK_INFO          1 /* from int 13 AH=08/41/48 */
>  #define XEN_FW_DISK_MBR_SIGNATURE 2 /* from MBR offset 0x1b8 */
>  #define XEN_FW_VBEDDC_INFO        3 /* from int 10 AX=4f15 */
> +#define XEN_FW_KBD_SHIFT_FLAGS    5 /* Int16, Fn02: Get keyboard shift 
> flags. */
>  struct xenpf_firmware_info {
>  	/* IN variables. */
>  	uint32_t type;
> @@ -142,6 +143,8 @@ struct xenpf_firmware_info {
>  			/* must refer to 128-byte buffer */
>  			GUEST_HANDLE(uchar) edid;
>  		} vbeddc_info; /* XEN_FW_VBEDDC_INFO */
> +		uint8_t kbd_shift_flags; /* XEN_FW_KBD_SHIFT_FLAGS */
> +

I'd prefer to not have stray empty line here - if anything, it should
go before the new union member.

Jan

>  	} u;
>  };
>  DEFINE_GUEST_HANDLE_STRUCT(xenpf_firmware_info_t);
> -- 
> 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 Sep 24 10:49:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Sep 2012 10: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 1TG6DU-0002Zh-9A; Mon, 24 Sep 2012 10:48: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 1TG6DS-0002ZV-P7
	for xen-devel@lists.xen.org; Mon, 24 Sep 2012 10:48:42 +0000
Received: from [85.158.143.99:40835] by server-1.bemta-4.messagelabs.com id
	59/F8-05684-98A30605; Mon, 24 Sep 2012 10:48:41 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1348483721!31191442!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30086 invoked from network); 24 Sep 2012 10:48:41 -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;
	24 Sep 2012 10:48:41 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 24 Sep 2012 11:48:41 +0100
Message-Id: <506056A6020000780009D453@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 24 Sep 2012 11:48:38 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Konrad Rzeszutek Wilk" <konrad@kernel.org>
References: <504F3F8A020000780009A8F9@nat28.tlf.novell.com>
	<20120921163406.GC4780@phenom.dumpdata.com>
In-Reply-To: <20120921163406.GC4780@phenom.dumpdata.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] x86: retrieve keyboard shift status flags
 from BIOS
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 21.09.12 at 18:34, Konrad Rzeszutek Wilk <konrad@kernel.org> wrote:
> And here is a variant for the upstream:
> 
> From 21b4fdf0592156ac3020f5c492139368dcdfcf71 Mon Sep 17 00:00:00 2001
> From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> Date: Fri, 21 Sep 2012 12:30:35 -0400
> Subject: [PATCH] xen/x86: retrieve keyboard shift status flags from
>  hypervisor.
> 
> The xen c/s 25873 allows the hypervisor to retrieve the NUMLOCK flag.
> With this patch, the Linux kernel can get the state according to the
> data in the BIOS.
> 
> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

Acked-by: Jan Beulich <jbeulich@suse.com>

(but also see below)

> --- a/arch/x86/xen/enlighten.c
> +++ b/arch/x86/xen/enlighten.c
> @@ -1441,11 +1441,19 @@ asmlinkage void __init xen_start_kernel(void)
>  		const struct dom0_vga_console_info *info =
>  			(void *)((char *)xen_start_info +
>  				 xen_start_info->console.dom0.info_off);
> +		struct xen_platform_op op = {
> +			.cmd = XENPF_firmware_info,
> +			.interface_version = XENPF_INTERFACE_VERSION,
> +			.u.firmware_info.type = XEN_FW_KBD_SHIFT_FLAGS,
> +		};
>  
>  		xen_init_vga(info, xen_start_info->console.dom0.info_size);
>  		xen_start_info->console.domU.mfn = 0;
>  		xen_start_info->console.domU.evtchn = 0;
>  
> +		if (HYPERVISOR_dom0_op(&op) == 0)
> +			boot_params.kbd_status = op.u.firmware_info.u.kbd_shift_flags;
> +
>  		xen_init_apic();
>  
>  		/* Make sure ACS will be enabled */
> diff --git a/include/xen/interface/platform.h 
> b/include/xen/interface/platform.h
> index 61fa661..81eee3b 100644
> --- a/include/xen/interface/platform.h
> +++ b/include/xen/interface/platform.h
> @@ -112,6 +112,7 @@ DEFINE_GUEST_HANDLE_STRUCT(xenpf_platform_quirk_t);
>  #define XEN_FW_DISK_INFO          1 /* from int 13 AH=08/41/48 */
>  #define XEN_FW_DISK_MBR_SIGNATURE 2 /* from MBR offset 0x1b8 */
>  #define XEN_FW_VBEDDC_INFO        3 /* from int 10 AX=4f15 */
> +#define XEN_FW_KBD_SHIFT_FLAGS    5 /* Int16, Fn02: Get keyboard shift 
> flags. */
>  struct xenpf_firmware_info {
>  	/* IN variables. */
>  	uint32_t type;
> @@ -142,6 +143,8 @@ struct xenpf_firmware_info {
>  			/* must refer to 128-byte buffer */
>  			GUEST_HANDLE(uchar) edid;
>  		} vbeddc_info; /* XEN_FW_VBEDDC_INFO */
> +		uint8_t kbd_shift_flags; /* XEN_FW_KBD_SHIFT_FLAGS */
> +

I'd prefer to not have stray empty line here - if anything, it should
go before the new union member.

Jan

>  	} u;
>  };
>  DEFINE_GUEST_HANDLE_STRUCT(xenpf_firmware_info_t);
> -- 
> 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 Sep 24 10:53:18 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Sep 2012 10:53: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 1TG6Hb-0002wh-V7; Mon, 24 Sep 2012 10:52: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 1TG6Ha-0002wX-Fx
	for xen-devel@lists.xen.org; Mon, 24 Sep 2012 10:52:58 +0000
Received: from [85.158.143.99:4954] by server-1.bemta-4.messagelabs.com id
	18/80-05684-98B30605; Mon, 24 Sep 2012 10:52:57 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1348483977!23336557!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10256 invoked from network); 24 Sep 2012 10:52:57 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-2.tower-216.messagelabs.com with SMTP;
	24 Sep 2012 10:52:57 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 24 Sep 2012 11:52:57 +0100
Message-Id: <506057A6020000780009D462@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 24 Sep 2012 11:52:54 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Yaogun Wen" <techno.geek.0x01@gmail.com>
References: <CALHMb0dTaR0NCQ1XdfrZ00NXGe0DpKXMNAG0vvZrpNMkLxti6A@mail.gmail.com>
	<505C87EB020000780009D02F@nat28.tlf.novell.com>
	<CALHMb0fMfNz6b3heCHWhOMcH5RqkpkyFwPqup6k4Eeh64yfrdg@mail.gmail.com>
In-Reply-To: <CALHMb0fMfNz6b3heCHWhOMcH5RqkpkyFwPqup6k4Eeh64yfrdg@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Ian Campbell <Ian.Campbell@citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] The use of evtchn_upcall_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 24.09.12 at 04:50, Yaogun Wen <techno.geek.0x01@gmail.com> wrote:
>> Setting an event channel pending isn't tied to the channel being
>> unmasked - in particular, for polled event channels, one would
>> keep them masked permanently, yet still expect events to be
>> signaled. The mask really controls whether an upcall is actually
>> permitted (just like EFLAGS.IF controls whether interrupts can
>> be injected).
> This explanation helps me to understand the meaning of VCPUINFO_upcall_mask.
> I don't know x86 assembly language, but according to your explanation,
> it seems that guest which only have masked channel will still receive
> the events.
> But from the comment of vcpu_info struct, it says "The mask
> (evtchn_upcall_mask) is read before making an event upcall to the
> guest".
> So, which one is correct?

Both. If I'm understanding correctly, you're mixing up per-channel
masks (evtchn_mask[]) and the global delivery mask
(evtchn_upcall_mask). If that's not the case, I'm afraid I don't
follow what your concern is.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 24 10:53:18 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Sep 2012 10:53: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 1TG6Hb-0002wh-V7; Mon, 24 Sep 2012 10:52: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 1TG6Ha-0002wX-Fx
	for xen-devel@lists.xen.org; Mon, 24 Sep 2012 10:52:58 +0000
Received: from [85.158.143.99:4954] by server-1.bemta-4.messagelabs.com id
	18/80-05684-98B30605; Mon, 24 Sep 2012 10:52:57 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1348483977!23336557!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10256 invoked from network); 24 Sep 2012 10:52:57 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-2.tower-216.messagelabs.com with SMTP;
	24 Sep 2012 10:52:57 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 24 Sep 2012 11:52:57 +0100
Message-Id: <506057A6020000780009D462@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 24 Sep 2012 11:52:54 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Yaogun Wen" <techno.geek.0x01@gmail.com>
References: <CALHMb0dTaR0NCQ1XdfrZ00NXGe0DpKXMNAG0vvZrpNMkLxti6A@mail.gmail.com>
	<505C87EB020000780009D02F@nat28.tlf.novell.com>
	<CALHMb0fMfNz6b3heCHWhOMcH5RqkpkyFwPqup6k4Eeh64yfrdg@mail.gmail.com>
In-Reply-To: <CALHMb0fMfNz6b3heCHWhOMcH5RqkpkyFwPqup6k4Eeh64yfrdg@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Ian Campbell <Ian.Campbell@citrix.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] The use of evtchn_upcall_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 24.09.12 at 04:50, Yaogun Wen <techno.geek.0x01@gmail.com> wrote:
>> Setting an event channel pending isn't tied to the channel being
>> unmasked - in particular, for polled event channels, one would
>> keep them masked permanently, yet still expect events to be
>> signaled. The mask really controls whether an upcall is actually
>> permitted (just like EFLAGS.IF controls whether interrupts can
>> be injected).
> This explanation helps me to understand the meaning of VCPUINFO_upcall_mask.
> I don't know x86 assembly language, but according to your explanation,
> it seems that guest which only have masked channel will still receive
> the events.
> But from the comment of vcpu_info struct, it says "The mask
> (evtchn_upcall_mask) is read before making an event upcall to the
> guest".
> So, which one is correct?

Both. If I'm understanding correctly, you're mixing up per-channel
masks (evtchn_mask[]) and the global delivery mask
(evtchn_upcall_mask). If that's not the case, I'm afraid I don't
follow what your concern is.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 24 11:03:10 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Sep 2012 11: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 1TG6RD-0003IZ-73; Mon, 24 Sep 2012 11:02: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 1TG6RC-0003He-0J
	for xen-devel@lists.xen.org; Mon, 24 Sep 2012 11:02:54 +0000
Received: from [85.158.137.99:34049] by server-10.bemta-3.messagelabs.com id
	75/6D-10411-DDD30605; Mon, 24 Sep 2012 11:02:53 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-16.tower-217.messagelabs.com!1348484571!18882145!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8420 invoked from network); 24 Sep 2012 11:02:51 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-16.tower-217.messagelabs.com with SMTP;
	24 Sep 2012 11:02:51 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 24 Sep 2012 12:02:51 +0100
Message-Id: <506059F9020000780009D46E@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 24 Sep 2012 12:02:49 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__PartAC9D91C9.0__="
Subject: [Xen-devel] [PATCH] x86: fix MWAIT-based idle driver for CPUs
	without ARAT
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<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.

--=__PartAC9D91C9.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

lapic_timer_{on,off} need to get initialized in this case. This in turn
requires getting HPET broadcast setup to be carried out earlier (and
hence preventing double initialization there).

Signed-off-by: Jan Beulich <jbeulich@suse.com>
---
Note that I don't have a respective system available to test these
adjustments (which is also why I didn't notice the omission from the
original patch), so I can only hope that this works and takes care of
the observed boot failure.

--- a/xen/arch/x86/acpi/cpu_idle.c
+++ b/xen/arch/x86/acpi/cpu_idle.c
@@ -74,6 +74,29 @@ static void lapic_timer_nop(void) { }
 void (*__read_mostly lapic_timer_off)(void);
 void (*__read_mostly lapic_timer_on)(void);
=20
+bool_t lapic_timer_init(void)
+{
+    if ( boot_cpu_has(X86_FEATURE_ARAT) )
+    {
+        lapic_timer_off =3D lapic_timer_nop;
+        lapic_timer_on =3D lapic_timer_nop;
+    }
+    else if ( hpet_broadcast_is_available() )
+    {
+        lapic_timer_off =3D hpet_broadcast_enter;
+        lapic_timer_on =3D hpet_broadcast_exit;
+    }
+    else if ( pit_broadcast_is_available() )
+    {
+        lapic_timer_off =3D pit_broadcast_enter;
+        lapic_timer_on =3D pit_broadcast_exit;
+    }
+    else
+        return 0;
+
+    return 1;
+}
+
 static uint64_t (*__read_mostly tick_to_ns)(uint64_t) =3D acpi_pm_tick_to_=
ns;
=20
 void (*__read_mostly pm_idle_save)(void);
@@ -789,25 +812,8 @@ static int check_cx(struct acpi_processo
         if ( local_apic_timer_c2_ok )
             break;
     case ACPI_STATE_C3:
-        if ( boot_cpu_has(X86_FEATURE_ARAT) )
-        {
-            lapic_timer_off =3D lapic_timer_nop;
-            lapic_timer_on =3D lapic_timer_nop;
-        }
-        else if ( hpet_broadcast_is_available() )
-        {
-            lapic_timer_off =3D hpet_broadcast_enter;
-            lapic_timer_on =3D hpet_broadcast_exit;
-        }
-        else if ( pit_broadcast_is_available() )
-        {
-            lapic_timer_off =3D pit_broadcast_enter;
-            lapic_timer_on =3D pit_broadcast_exit;
-        }
-        else
-        {
+        if ( !lapic_timer_init() )
             return -EINVAL;
-        }
=20
         /* All the logic here assumes flags.bm_check is same across all =
CPUs */
         if ( bm_check_flag =3D=3D -1 )
--- a/xen/arch/x86/cpu/mwait-idle.c
+++ b/xen/arch/x86/cpu/mwait-idle.c
@@ -56,6 +56,7 @@
 #include <xen/softirq.h>
 #include <xen/trace.h>
 #include <asm/cpuidle.h>
+#include <asm/hpet.h>
 #include <asm/mwait.h>
 #include <asm/msr.h>
 #include <acpi/cpufreq/cpufreq.h>
@@ -501,6 +502,12 @@ int __init mwait_idle_init(struct notifi
=20
 	err =3D mwait_idle_probe();
 	if (!err) {
+		if (!boot_cpu_has(X86_FEATURE_ARAT))
+			hpet_broadcast_init();
+		if (!lapic_timer_init())
+			err =3D -EINVAL;
+	}
+	if (!err) {
 		nfb->notifier_call =3D mwait_idle_cpu_init;
 		mwait_idle_cpu_init(nfb, CPU_UP_PREPARE, NULL);
=20
--- a/xen/arch/x86/hpet.c
+++ b/xen/arch/x86/hpet.c
@@ -495,7 +495,7 @@ void __init hpet_broadcast_init(void)
     u32 hpet_id, cfg;
     unsigned int i, n;
=20
-    if ( hpet_rate =3D=3D 0 )
+    if ( hpet_rate =3D=3D 0 || hpet_broadcast_is_available() )
         return;
=20
     cfg =3D hpet_read32(HPET_CFG);
--- a/xen/include/asm-x86/cpuidle.h
+++ b/xen/include/asm-x86/cpuidle.h
@@ -10,6 +10,7 @@ extern struct acpi_processor_power *proc
=20
 extern void (*pm_idle_save)(void);
=20
+bool_t lapic_timer_init(void);
 extern void (*lapic_timer_off)(void);
 extern void (*lapic_timer_on)(void);
=20




--=__PartAC9D91C9.0__=
Content-Type: text/plain; name="x86-mwait-idle-lapic-timer-init.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="x86-mwait-idle-lapic-timer-init.patch"

x86: fix MWAIT-based idle driver for CPUs without ARAT=0A=0Alapic_timer_{on=
,off} need to get initialized in this case. This in turn=0Arequires =
getting HPET broadcast setup to be carried out earlier (and=0Ahence =
preventing double initialization there).=0A=0ASigned-off-by: Jan Beulich =
<jbeulich@suse.com>=0A---=0ANote that I don't have a respective system =
available to test these=0Aadjustments (which is also why I didn't notice =
the omission from the=0Aoriginal patch), so I can only hope that this =
works and takes care of=0Athe observed boot failure.=0A=0A--- a/xen/arch/x8=
6/acpi/cpu_idle.c=0A+++ b/xen/arch/x86/acpi/cpu_idle.c=0A@@ -74,6 +74,29 =
@@ static void lapic_timer_nop(void) { }=0A void (*__read_mostly lapic_time=
r_off)(void);=0A void (*__read_mostly lapic_timer_on)(void);=0A =0A+bool_t =
lapic_timer_init(void)=0A+{=0A+    if ( boot_cpu_has(X86_FEATURE_ARAT) =
)=0A+    {=0A+        lapic_timer_off =3D lapic_timer_nop;=0A+        =
lapic_timer_on =3D lapic_timer_nop;=0A+    }=0A+    else if ( hpet_broadcas=
t_is_available() )=0A+    {=0A+        lapic_timer_off =3D hpet_broadcast_e=
nter;=0A+        lapic_timer_on =3D hpet_broadcast_exit;=0A+    }=0A+    =
else if ( pit_broadcast_is_available() )=0A+    {=0A+        lapic_timer_of=
f =3D pit_broadcast_enter;=0A+        lapic_timer_on =3D pit_broadcast_exit=
;=0A+    }=0A+    else=0A+        return 0;=0A+=0A+    return 1;=0A+}=0A+=
=0A static uint64_t (*__read_mostly tick_to_ns)(uint64_t) =3D acpi_pm_tick_=
to_ns;=0A =0A void (*__read_mostly pm_idle_save)(void);=0A@@ -789,25 =
+812,8 @@ static int check_cx(struct acpi_processo=0A         if ( =
local_apic_timer_c2_ok )=0A             break;=0A     case ACPI_STATE_C3:=
=0A-        if ( boot_cpu_has(X86_FEATURE_ARAT) )=0A-        {=0A-         =
   lapic_timer_off =3D lapic_timer_nop;=0A-            lapic_timer_on =3D =
lapic_timer_nop;=0A-        }=0A-        else if ( hpet_broadcast_is_availa=
ble() )=0A-        {=0A-            lapic_timer_off =3D hpet_broadcast_ente=
r;=0A-            lapic_timer_on =3D hpet_broadcast_exit;=0A-        }=0A- =
       else if ( pit_broadcast_is_available() )=0A-        {=0A-           =
 lapic_timer_off =3D pit_broadcast_enter;=0A-            lapic_timer_on =
=3D pit_broadcast_exit;=0A-        }=0A-        else=0A-        {=0A+      =
  if ( !lapic_timer_init() )=0A             return -EINVAL;=0A-        =
}=0A =0A         /* All the logic here assumes flags.bm_check is same =
across all CPUs */=0A         if ( bm_check_flag =3D=3D -1 )=0A--- =
a/xen/arch/x86/cpu/mwait-idle.c=0A+++ b/xen/arch/x86/cpu/mwait-idle.c=0A@@ =
-56,6 +56,7 @@=0A #include <xen/softirq.h>=0A #include <xen/trace.h>=0A =
#include <asm/cpuidle.h>=0A+#include <asm/hpet.h>=0A #include <asm/mwait.h>=
=0A #include <asm/msr.h>=0A #include <acpi/cpufreq/cpufreq.h>=0A@@ -501,6 =
+502,12 @@ int __init mwait_idle_init(struct notifi=0A =0A 	err =3D =
mwait_idle_probe();=0A 	if (!err) {=0A+		if (!boot_cpu_has(X86_FEATU=
RE_ARAT))=0A+			hpet_broadcast_init();=0A+		if =
(!lapic_timer_init())=0A+			err =3D -EINVAL;=0A+	=
}=0A+	if (!err) {=0A 		nfb->notifier_call =3D mwait_idle_cpu_init;=
=0A 		mwait_idle_cpu_init(nfb, CPU_UP_PREPARE, NULL);=0A =0A--- =
a/xen/arch/x86/hpet.c=0A+++ b/xen/arch/x86/hpet.c=0A@@ -495,7 +495,7 @@ =
void __init hpet_broadcast_init(void)=0A     u32 hpet_id, cfg;=0A     =
unsigned int i, n;=0A =0A-    if ( hpet_rate =3D=3D 0 )=0A+    if ( =
hpet_rate =3D=3D 0 || hpet_broadcast_is_available() )=0A         return;=0A=
 =0A     cfg =3D hpet_read32(HPET_CFG);=0A--- a/xen/include/asm-x86/cpuidle=
.h=0A+++ b/xen/include/asm-x86/cpuidle.h=0A@@ -10,6 +10,7 @@ extern struct =
acpi_processor_power *proc=0A =0A extern void (*pm_idle_save)(void);=0A =
=0A+bool_t lapic_timer_init(void);=0A extern void (*lapic_timer_off)(void);=
=0A extern void (*lapic_timer_on)(void);=0A =0A
--=__PartAC9D91C9.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

--=__PartAC9D91C9.0__=--


From xen-devel-bounces@lists.xen.org Mon Sep 24 11:03:10 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Sep 2012 11: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 1TG6RD-0003IZ-73; Mon, 24 Sep 2012 11:02: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 1TG6RC-0003He-0J
	for xen-devel@lists.xen.org; Mon, 24 Sep 2012 11:02:54 +0000
Received: from [85.158.137.99:34049] by server-10.bemta-3.messagelabs.com id
	75/6D-10411-DDD30605; Mon, 24 Sep 2012 11:02:53 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-16.tower-217.messagelabs.com!1348484571!18882145!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8420 invoked from network); 24 Sep 2012 11:02:51 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-16.tower-217.messagelabs.com with SMTP;
	24 Sep 2012 11:02:51 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 24 Sep 2012 12:02:51 +0100
Message-Id: <506059F9020000780009D46E@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 24 Sep 2012 12:02:49 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__PartAC9D91C9.0__="
Subject: [Xen-devel] [PATCH] x86: fix MWAIT-based idle driver for CPUs
	without ARAT
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<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.

--=__PartAC9D91C9.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

lapic_timer_{on,off} need to get initialized in this case. This in turn
requires getting HPET broadcast setup to be carried out earlier (and
hence preventing double initialization there).

Signed-off-by: Jan Beulich <jbeulich@suse.com>
---
Note that I don't have a respective system available to test these
adjustments (which is also why I didn't notice the omission from the
original patch), so I can only hope that this works and takes care of
the observed boot failure.

--- a/xen/arch/x86/acpi/cpu_idle.c
+++ b/xen/arch/x86/acpi/cpu_idle.c
@@ -74,6 +74,29 @@ static void lapic_timer_nop(void) { }
 void (*__read_mostly lapic_timer_off)(void);
 void (*__read_mostly lapic_timer_on)(void);
=20
+bool_t lapic_timer_init(void)
+{
+    if ( boot_cpu_has(X86_FEATURE_ARAT) )
+    {
+        lapic_timer_off =3D lapic_timer_nop;
+        lapic_timer_on =3D lapic_timer_nop;
+    }
+    else if ( hpet_broadcast_is_available() )
+    {
+        lapic_timer_off =3D hpet_broadcast_enter;
+        lapic_timer_on =3D hpet_broadcast_exit;
+    }
+    else if ( pit_broadcast_is_available() )
+    {
+        lapic_timer_off =3D pit_broadcast_enter;
+        lapic_timer_on =3D pit_broadcast_exit;
+    }
+    else
+        return 0;
+
+    return 1;
+}
+
 static uint64_t (*__read_mostly tick_to_ns)(uint64_t) =3D acpi_pm_tick_to_=
ns;
=20
 void (*__read_mostly pm_idle_save)(void);
@@ -789,25 +812,8 @@ static int check_cx(struct acpi_processo
         if ( local_apic_timer_c2_ok )
             break;
     case ACPI_STATE_C3:
-        if ( boot_cpu_has(X86_FEATURE_ARAT) )
-        {
-            lapic_timer_off =3D lapic_timer_nop;
-            lapic_timer_on =3D lapic_timer_nop;
-        }
-        else if ( hpet_broadcast_is_available() )
-        {
-            lapic_timer_off =3D hpet_broadcast_enter;
-            lapic_timer_on =3D hpet_broadcast_exit;
-        }
-        else if ( pit_broadcast_is_available() )
-        {
-            lapic_timer_off =3D pit_broadcast_enter;
-            lapic_timer_on =3D pit_broadcast_exit;
-        }
-        else
-        {
+        if ( !lapic_timer_init() )
             return -EINVAL;
-        }
=20
         /* All the logic here assumes flags.bm_check is same across all =
CPUs */
         if ( bm_check_flag =3D=3D -1 )
--- a/xen/arch/x86/cpu/mwait-idle.c
+++ b/xen/arch/x86/cpu/mwait-idle.c
@@ -56,6 +56,7 @@
 #include <xen/softirq.h>
 #include <xen/trace.h>
 #include <asm/cpuidle.h>
+#include <asm/hpet.h>
 #include <asm/mwait.h>
 #include <asm/msr.h>
 #include <acpi/cpufreq/cpufreq.h>
@@ -501,6 +502,12 @@ int __init mwait_idle_init(struct notifi
=20
 	err =3D mwait_idle_probe();
 	if (!err) {
+		if (!boot_cpu_has(X86_FEATURE_ARAT))
+			hpet_broadcast_init();
+		if (!lapic_timer_init())
+			err =3D -EINVAL;
+	}
+	if (!err) {
 		nfb->notifier_call =3D mwait_idle_cpu_init;
 		mwait_idle_cpu_init(nfb, CPU_UP_PREPARE, NULL);
=20
--- a/xen/arch/x86/hpet.c
+++ b/xen/arch/x86/hpet.c
@@ -495,7 +495,7 @@ void __init hpet_broadcast_init(void)
     u32 hpet_id, cfg;
     unsigned int i, n;
=20
-    if ( hpet_rate =3D=3D 0 )
+    if ( hpet_rate =3D=3D 0 || hpet_broadcast_is_available() )
         return;
=20
     cfg =3D hpet_read32(HPET_CFG);
--- a/xen/include/asm-x86/cpuidle.h
+++ b/xen/include/asm-x86/cpuidle.h
@@ -10,6 +10,7 @@ extern struct acpi_processor_power *proc
=20
 extern void (*pm_idle_save)(void);
=20
+bool_t lapic_timer_init(void);
 extern void (*lapic_timer_off)(void);
 extern void (*lapic_timer_on)(void);
=20




--=__PartAC9D91C9.0__=
Content-Type: text/plain; name="x86-mwait-idle-lapic-timer-init.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="x86-mwait-idle-lapic-timer-init.patch"

x86: fix MWAIT-based idle driver for CPUs without ARAT=0A=0Alapic_timer_{on=
,off} need to get initialized in this case. This in turn=0Arequires =
getting HPET broadcast setup to be carried out earlier (and=0Ahence =
preventing double initialization there).=0A=0ASigned-off-by: Jan Beulich =
<jbeulich@suse.com>=0A---=0ANote that I don't have a respective system =
available to test these=0Aadjustments (which is also why I didn't notice =
the omission from the=0Aoriginal patch), so I can only hope that this =
works and takes care of=0Athe observed boot failure.=0A=0A--- a/xen/arch/x8=
6/acpi/cpu_idle.c=0A+++ b/xen/arch/x86/acpi/cpu_idle.c=0A@@ -74,6 +74,29 =
@@ static void lapic_timer_nop(void) { }=0A void (*__read_mostly lapic_time=
r_off)(void);=0A void (*__read_mostly lapic_timer_on)(void);=0A =0A+bool_t =
lapic_timer_init(void)=0A+{=0A+    if ( boot_cpu_has(X86_FEATURE_ARAT) =
)=0A+    {=0A+        lapic_timer_off =3D lapic_timer_nop;=0A+        =
lapic_timer_on =3D lapic_timer_nop;=0A+    }=0A+    else if ( hpet_broadcas=
t_is_available() )=0A+    {=0A+        lapic_timer_off =3D hpet_broadcast_e=
nter;=0A+        lapic_timer_on =3D hpet_broadcast_exit;=0A+    }=0A+    =
else if ( pit_broadcast_is_available() )=0A+    {=0A+        lapic_timer_of=
f =3D pit_broadcast_enter;=0A+        lapic_timer_on =3D pit_broadcast_exit=
;=0A+    }=0A+    else=0A+        return 0;=0A+=0A+    return 1;=0A+}=0A+=
=0A static uint64_t (*__read_mostly tick_to_ns)(uint64_t) =3D acpi_pm_tick_=
to_ns;=0A =0A void (*__read_mostly pm_idle_save)(void);=0A@@ -789,25 =
+812,8 @@ static int check_cx(struct acpi_processo=0A         if ( =
local_apic_timer_c2_ok )=0A             break;=0A     case ACPI_STATE_C3:=
=0A-        if ( boot_cpu_has(X86_FEATURE_ARAT) )=0A-        {=0A-         =
   lapic_timer_off =3D lapic_timer_nop;=0A-            lapic_timer_on =3D =
lapic_timer_nop;=0A-        }=0A-        else if ( hpet_broadcast_is_availa=
ble() )=0A-        {=0A-            lapic_timer_off =3D hpet_broadcast_ente=
r;=0A-            lapic_timer_on =3D hpet_broadcast_exit;=0A-        }=0A- =
       else if ( pit_broadcast_is_available() )=0A-        {=0A-           =
 lapic_timer_off =3D pit_broadcast_enter;=0A-            lapic_timer_on =
=3D pit_broadcast_exit;=0A-        }=0A-        else=0A-        {=0A+      =
  if ( !lapic_timer_init() )=0A             return -EINVAL;=0A-        =
}=0A =0A         /* All the logic here assumes flags.bm_check is same =
across all CPUs */=0A         if ( bm_check_flag =3D=3D -1 )=0A--- =
a/xen/arch/x86/cpu/mwait-idle.c=0A+++ b/xen/arch/x86/cpu/mwait-idle.c=0A@@ =
-56,6 +56,7 @@=0A #include <xen/softirq.h>=0A #include <xen/trace.h>=0A =
#include <asm/cpuidle.h>=0A+#include <asm/hpet.h>=0A #include <asm/mwait.h>=
=0A #include <asm/msr.h>=0A #include <acpi/cpufreq/cpufreq.h>=0A@@ -501,6 =
+502,12 @@ int __init mwait_idle_init(struct notifi=0A =0A 	err =3D =
mwait_idle_probe();=0A 	if (!err) {=0A+		if (!boot_cpu_has(X86_FEATU=
RE_ARAT))=0A+			hpet_broadcast_init();=0A+		if =
(!lapic_timer_init())=0A+			err =3D -EINVAL;=0A+	=
}=0A+	if (!err) {=0A 		nfb->notifier_call =3D mwait_idle_cpu_init;=
=0A 		mwait_idle_cpu_init(nfb, CPU_UP_PREPARE, NULL);=0A =0A--- =
a/xen/arch/x86/hpet.c=0A+++ b/xen/arch/x86/hpet.c=0A@@ -495,7 +495,7 @@ =
void __init hpet_broadcast_init(void)=0A     u32 hpet_id, cfg;=0A     =
unsigned int i, n;=0A =0A-    if ( hpet_rate =3D=3D 0 )=0A+    if ( =
hpet_rate =3D=3D 0 || hpet_broadcast_is_available() )=0A         return;=0A=
 =0A     cfg =3D hpet_read32(HPET_CFG);=0A--- a/xen/include/asm-x86/cpuidle=
.h=0A+++ b/xen/include/asm-x86/cpuidle.h=0A@@ -10,6 +10,7 @@ extern struct =
acpi_processor_power *proc=0A =0A extern void (*pm_idle_save)(void);=0A =
=0A+bool_t lapic_timer_init(void);=0A extern void (*lapic_timer_off)(void);=
=0A extern void (*lapic_timer_on)(void);=0A =0A
--=__PartAC9D91C9.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

--=__PartAC9D91C9.0__=--


From xen-devel-bounces@lists.xen.org Mon Sep 24 11:11:30 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Sep 2012 11: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 1TG6ZF-0003Uq-6j; Mon, 24 Sep 2012 11:11: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 1TG6ZD-0003Ul-Eh
	for xen-devel@lists.xen.org; Mon, 24 Sep 2012 11:11:11 +0000
Received: from [85.158.143.99:41236] by server-1.bemta-4.messagelabs.com id
	89/51-05684-ECF30605; Mon, 24 Sep 2012 11:11:10 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1348485068!24007914!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTA4NDk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6152 invoked from network); 24 Sep 2012 11:11:08 -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;
	24 Sep 2012 11:11:08 -0000
X-IronPort-AV: E=Sophos;i="4.80,474,1344211200"; d="scan'208";a="14720813"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Sep 2012 11:11: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.279.1; Mon, 24 Sep 2012 12:11: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
	1TG6Z9-0000NV-Jv; Mon, 24 Sep 2012 11:11:07 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1TG6Z9-0006GS-FW;
	Mon, 24 Sep 2012 12:11:07 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20576.16331.346158.567037@mariner.uk.xensource.com>
Date: Mon, 24 Sep 2012 12:11:07 +0100
To: Julien Grall <julien.grall@gmail.com>
In-Reply-To: <CAF3u54ACoD4toNBfTBRyUy90yt=Zn50NjszoRmzSFOObr5dfvA@mail.gmail.com>
References: <1348049147-16752-1-git-send-email-julien.grall@citrix.com>
	<20572.35759.42063.973125@mariner.uk.xensource.com>
	<505C941F.6080903@citrix.com>
	<20572.38321.326083.184425@mariner.uk.xensource.com>
	<CAF3u54ACoD4toNBfTBRyUy90yt=Zn50NjszoRmzSFOObr5dfvA@mail.gmail.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Julien Grall <julien.grall@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] libxenstore: filter watch events in
 libxenstore when we unwatch
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Julien Grall writes ("Re: [Xen-devel] [PATCH] libxenstore: filter watch events in libxenstore when we unwatch"):
> The function xs_check_watch was recently introduced in Xen (see your
> commit on december 2011).

Oh, I'd forgotten that.

> Most of application, for instance QEMU, still use xs_read_watch.
> So if xs_unwatch doesn't empty the pipe, most of this applications
> potentially stall indefinitly.
> 
> IMHO, this piece of code is really important.

In that case, I agree.

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 Sep 24 11:11:30 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Sep 2012 11: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 1TG6ZF-0003Uq-6j; Mon, 24 Sep 2012 11:11: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 1TG6ZD-0003Ul-Eh
	for xen-devel@lists.xen.org; Mon, 24 Sep 2012 11:11:11 +0000
Received: from [85.158.143.99:41236] by server-1.bemta-4.messagelabs.com id
	89/51-05684-ECF30605; Mon, 24 Sep 2012 11:11:10 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1348485068!24007914!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTA4NDk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6152 invoked from network); 24 Sep 2012 11:11:08 -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;
	24 Sep 2012 11:11:08 -0000
X-IronPort-AV: E=Sophos;i="4.80,474,1344211200"; d="scan'208";a="14720813"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Sep 2012 11:11: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.279.1; Mon, 24 Sep 2012 12:11: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
	1TG6Z9-0000NV-Jv; Mon, 24 Sep 2012 11:11:07 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1TG6Z9-0006GS-FW;
	Mon, 24 Sep 2012 12:11:07 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20576.16331.346158.567037@mariner.uk.xensource.com>
Date: Mon, 24 Sep 2012 12:11:07 +0100
To: Julien Grall <julien.grall@gmail.com>
In-Reply-To: <CAF3u54ACoD4toNBfTBRyUy90yt=Zn50NjszoRmzSFOObr5dfvA@mail.gmail.com>
References: <1348049147-16752-1-git-send-email-julien.grall@citrix.com>
	<20572.35759.42063.973125@mariner.uk.xensource.com>
	<505C941F.6080903@citrix.com>
	<20572.38321.326083.184425@mariner.uk.xensource.com>
	<CAF3u54ACoD4toNBfTBRyUy90yt=Zn50NjszoRmzSFOObr5dfvA@mail.gmail.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Julien Grall <julien.grall@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] libxenstore: filter watch events in
 libxenstore when we unwatch
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Julien Grall writes ("Re: [Xen-devel] [PATCH] libxenstore: filter watch events in libxenstore when we unwatch"):
> The function xs_check_watch was recently introduced in Xen (see your
> commit on december 2011).

Oh, I'd forgotten that.

> Most of application, for instance QEMU, still use xs_read_watch.
> So if xs_unwatch doesn't empty the pipe, most of this applications
> potentially stall indefinitly.
> 
> IMHO, this piece of code is really important.

In that case, I agree.

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 Sep 24 11:22:56 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Sep 2012 11: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 1TG6kK-0003em-Ej; Mon, 24 Sep 2012 11:22: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 1TG6kI-0003eh-I1
	for xen-devel@lists.xen.org; Mon, 24 Sep 2012 11:22:38 +0000
Received: from [85.158.137.99:40843] by server-12.bemta-3.messagelabs.com id
	59/A6-10384-D7240605; Mon, 24 Sep 2012 11:22:37 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-8.tower-217.messagelabs.com!1348485756!13529749!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23095 invoked from network); 24 Sep 2012 11:22:36 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-8.tower-217.messagelabs.com with SMTP;
	24 Sep 2012 11:22:36 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 24 Sep 2012 12:22:36 +0100
Message-Id: <50605E9A020000780009D486@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 24 Sep 2012 12:22:34 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ben Guthro" <ben@guthro.net>,"Keir Fraser" <keir@xen.org>
References: <CAOvdn6XKPOMNn6AjuYvZvPXRRJffN3po5GXe1Yh1-m0hisMK_w@mail.gmail.com>
	<CC8273A0.4C9DD%keir@xen.org>
In-Reply-To: <CC8273A0.4C9DD%keir@xen.org>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>, john.baboval@citrix.com,
	Thomas Goetz <thomas.goetz@citrix.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen4.2 S3 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 21.09.12 at 20:42, Keir Fraser <keir@xen.org> wrote:
> On 21/09/2012 19:20, "Ben Guthro" <ben@guthro.net> wrote:
> 
>> 
>> 
>> On Fri, Sep 21, 2012 at 2:47 AM, Jan Beulich <JBeulich@suse.com> wrote:
>>> 
>>> That's because CPU1 is stuck in cpu_init() (in the infinite loop after
>>> printing "CPU#1 already initialized!"), as Keir pointed out yesterday.
>>> 
>> 
>> I've done some more tracing on this, and instrumented cpu_init(), 
> cpu_uninit()
>> - and found something I cannot quite explain.
>> I was most interested in the cpu_initialized mask, set just above these two
>> functions (and only used in those two functions)
>> 
>> I convert  cpu_initialized to a string, using cpumask_scnprintf - and print 
> it
>> out when it is read, or written in these two functions.
>> 
>> When CPU1 is being torn down, the cpumask bit gets cleared for CPU1, and I 
> am
>> able to print this to the console to verify.
>> However, when the machine is returning from S3, and going through cpu_init -
>> the bit is set again.
>> 
>> Could this be an issue of caches not being flushed?
>> 
>> I see that the last thing done before acpi_enter_sleep_state actually
>> writes PM1A_CONTROL / PM1B_CONTROL to enter S3 is a ACPI_FLUSH_CPU_CACHE()
>> 
>> This analysis seems unlikely, at this point...but I'm not sure what to make 
> of
>> the data other than a cache issue.
>> 
>> Am I "barking up the wrong tree" here?
> 
> Perhaps not. Try dumping it immediately before and after the actual S3
> sleep. Since you probably can't print to serial line at that point, you
> could just take a copy of the bitmap and print them both shortly after S3
> resume. Then if it still looks bad, or the problem magically resolves with
> the extra printing, you can suspect cache flush a bit more strongly.
> However, WBINVD (which is what ACPI_FLUSH_CPU_CACHE() is) should be enough.

CPU0 issuing WBINVD might not be enough; other CPUs should
probably also do so unconditionally (currently they do this only
when using one of the advanced halt forms in acpi_dead_idle()).

While one would think that a halted CPU would not only continue
to keep its cache up-to-date, but also eventually write back its
dirty cache lines, I don't think the latter is actually guaranteed,
so if the CPU ends up getting the INIT before the line was written
back, the modification could get lost.

But of course this theory depends on Ben's system actually using
the default halt mechanism rather than one of the advanced ones.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 24 11:22:56 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Sep 2012 11: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 1TG6kK-0003em-Ej; Mon, 24 Sep 2012 11:22: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 1TG6kI-0003eh-I1
	for xen-devel@lists.xen.org; Mon, 24 Sep 2012 11:22:38 +0000
Received: from [85.158.137.99:40843] by server-12.bemta-3.messagelabs.com id
	59/A6-10384-D7240605; Mon, 24 Sep 2012 11:22:37 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-8.tower-217.messagelabs.com!1348485756!13529749!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23095 invoked from network); 24 Sep 2012 11:22:36 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-8.tower-217.messagelabs.com with SMTP;
	24 Sep 2012 11:22:36 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 24 Sep 2012 12:22:36 +0100
Message-Id: <50605E9A020000780009D486@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 24 Sep 2012 12:22:34 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ben Guthro" <ben@guthro.net>,"Keir Fraser" <keir@xen.org>
References: <CAOvdn6XKPOMNn6AjuYvZvPXRRJffN3po5GXe1Yh1-m0hisMK_w@mail.gmail.com>
	<CC8273A0.4C9DD%keir@xen.org>
In-Reply-To: <CC8273A0.4C9DD%keir@xen.org>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>, john.baboval@citrix.com,
	Thomas Goetz <thomas.goetz@citrix.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen4.2 S3 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 21.09.12 at 20:42, Keir Fraser <keir@xen.org> wrote:
> On 21/09/2012 19:20, "Ben Guthro" <ben@guthro.net> wrote:
> 
>> 
>> 
>> On Fri, Sep 21, 2012 at 2:47 AM, Jan Beulich <JBeulich@suse.com> wrote:
>>> 
>>> That's because CPU1 is stuck in cpu_init() (in the infinite loop after
>>> printing "CPU#1 already initialized!"), as Keir pointed out yesterday.
>>> 
>> 
>> I've done some more tracing on this, and instrumented cpu_init(), 
> cpu_uninit()
>> - and found something I cannot quite explain.
>> I was most interested in the cpu_initialized mask, set just above these two
>> functions (and only used in those two functions)
>> 
>> I convert  cpu_initialized to a string, using cpumask_scnprintf - and print 
> it
>> out when it is read, or written in these two functions.
>> 
>> When CPU1 is being torn down, the cpumask bit gets cleared for CPU1, and I 
> am
>> able to print this to the console to verify.
>> However, when the machine is returning from S3, and going through cpu_init -
>> the bit is set again.
>> 
>> Could this be an issue of caches not being flushed?
>> 
>> I see that the last thing done before acpi_enter_sleep_state actually
>> writes PM1A_CONTROL / PM1B_CONTROL to enter S3 is a ACPI_FLUSH_CPU_CACHE()
>> 
>> This analysis seems unlikely, at this point...but I'm not sure what to make 
> of
>> the data other than a cache issue.
>> 
>> Am I "barking up the wrong tree" here?
> 
> Perhaps not. Try dumping it immediately before and after the actual S3
> sleep. Since you probably can't print to serial line at that point, you
> could just take a copy of the bitmap and print them both shortly after S3
> resume. Then if it still looks bad, or the problem magically resolves with
> the extra printing, you can suspect cache flush a bit more strongly.
> However, WBINVD (which is what ACPI_FLUSH_CPU_CACHE() is) should be enough.

CPU0 issuing WBINVD might not be enough; other CPUs should
probably also do so unconditionally (currently they do this only
when using one of the advanced halt forms in acpi_dead_idle()).

While one would think that a halted CPU would not only continue
to keep its cache up-to-date, but also eventually write back its
dirty cache lines, I don't think the latter is actually guaranteed,
so if the CPU ends up getting the INIT before the line was written
back, the modification could get lost.

But of course this theory depends on Ben's system actually using
the default halt mechanism rather than one of the advanced ones.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 24 11:26:21 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Sep 2012 11:26:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TG6ne-0003mX-Mv; Mon, 24 Sep 2012 11:26:06 +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 1TG6nc-0003mF-Vh
	for xen-devel@lists.xen.org; Mon, 24 Sep 2012 11:26:05 +0000
Received: from [85.158.143.99:37946] by server-3.bemta-4.messagelabs.com id
	B4/CF-10986-C4340605; Mon, 24 Sep 2012 11:26:04 +0000
X-Env-Sender: ben.guthro@gmail.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1348485960!21749843!1
X-Originating-IP: [209.85.223.173]
X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_20_30,HTML_MESSAGE,
	RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 858 invoked from network); 24 Sep 2012 11:26:01 -0000
Received: from mail-ie0-f173.google.com (HELO mail-ie0-f173.google.com)
	(209.85.223.173)
	by server-8.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Sep 2012 11:26:01 -0000
Received: by iea17 with SMTP id 17so7484826iea.32
	for <xen-devel@lists.xen.org>; Mon, 24 Sep 2012 04:25: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;
	bh=kDHRxzB0hSBcRyN7+fhfgQJR/LSB/r+7fF+lPOYfyGc=;
	b=tNfMi9pfAfTQc+TUCA+WXJrrcaGEbSabftYMkeCqiGeTp3zj7mOBXjPuHjvRfDyg1c
	NXfv5fIk8Yim2HDlUDBizQo2Bgr9d3CFzEGQ21mWN/eUPfoqqzBE9+NywzNZw+kxq7XL
	LRRGgcSY0s1jsnop93xDeu8LsJ1F/5sHUgJUdTquSHzFfl++rWs+EwzgF1fRWsEAlM5a
	J5CB+g669TMhQW3iymvSABaUX0GsWq0HhPj0pPAecDn2DrwoTd51t9U0i4xpBWZ56COy
	DX6iylyZ3n+gGKKlC0h/QQjd4TRaRNelppq4gq3aW0vIbaylUzDSerWIB9kBFg9rRKgU
	gvew==
MIME-Version: 1.0
Received: by 10.50.236.72 with SMTP id us8mr4831854igc.70.1348485959733; Mon,
	24 Sep 2012 04:25:59 -0700 (PDT)
Received: by 10.64.55.132 with HTTP; Mon, 24 Sep 2012 04:25:59 -0700 (PDT)
In-Reply-To: <50605E9A020000780009D486@nat28.tlf.novell.com>
References: <CAOvdn6XKPOMNn6AjuYvZvPXRRJffN3po5GXe1Yh1-m0hisMK_w@mail.gmail.com>
	<CC8273A0.4C9DD%keir@xen.org>
	<50605E9A020000780009D486@nat28.tlf.novell.com>
Date: Mon, 24 Sep 2012 07:25:59 -0400
X-Google-Sender-Auth: g4yNK9DOOIhZtri56EaYe10W18U
Message-ID: <CAOvdn6XmB6rj3_QVU+59V8p24Y5G47AWxVEM=id02JWXkuhibQ@mail.gmail.com>
From: Ben Guthro <ben@guthro.net>
To: Jan Beulich <JBeulich@suse.com>
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>, Keir Fraser <keir@xen.org>,
	john.baboval@citrix.com, Thomas Goetz <thomas.goetz@citrix.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen4.2 S3 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: multipart/mixed; boundary="===============6081085386524649401=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============6081085386524649401==
Content-Type: multipart/alternative; boundary=14dae9340af39d520f04ca70da8e

--14dae9340af39d520f04ca70da8e
Content-Type: text/plain; charset=ISO-8859-1

It is an older system (Core2) - so it may be using the default mechanism,
but I'd have to go dig up some processor docs to be sure.

I'm still seeing some behavior in my experiments that I can't entirely
explain (yet)
I'll be spending some time today looking into it more closely.


On Mon, Sep 24, 2012 at 7:22 AM, Jan Beulich <JBeulich@suse.com> wrote:

> >>> On 21.09.12 at 20:42, Keir Fraser <keir@xen.org> wrote:
> > On 21/09/2012 19:20, "Ben Guthro" <ben@guthro.net> wrote:
> >
> >>
> >>
> >> On Fri, Sep 21, 2012 at 2:47 AM, Jan Beulich <JBeulich@suse.com> wrote:
> >>>
> >>> That's because CPU1 is stuck in cpu_init() (in the infinite loop after
> >>> printing "CPU#1 already initialized!"), as Keir pointed out yesterday.
> >>>
> >>
> >> I've done some more tracing on this, and instrumented cpu_init(),
> > cpu_uninit()
> >> - and found something I cannot quite explain.
> >> I was most interested in the cpu_initialized mask, set just above these
> two
> >> functions (and only used in those two functions)
> >>
> >> I convert  cpu_initialized to a string, using cpumask_scnprintf - and
> print
> > it
> >> out when it is read, or written in these two functions.
> >>
> >> When CPU1 is being torn down, the cpumask bit gets cleared for CPU1,
> and I
> > am
> >> able to print this to the console to verify.
> >> However, when the machine is returning from S3, and going through
> cpu_init -
> >> the bit is set again.
> >>
> >> Could this be an issue of caches not being flushed?
> >>
> >> I see that the last thing done before acpi_enter_sleep_state actually
> >> writes PM1A_CONTROL / PM1B_CONTROL to enter S3 is a
> ACPI_FLUSH_CPU_CACHE()
> >>
> >> This analysis seems unlikely, at this point...but I'm not sure what to
> make
> > of
> >> the data other than a cache issue.
> >>
> >> Am I "barking up the wrong tree" here?
> >
> > Perhaps not. Try dumping it immediately before and after the actual S3
> > sleep. Since you probably can't print to serial line at that point, you
> > could just take a copy of the bitmap and print them both shortly after S3
> > resume. Then if it still looks bad, or the problem magically resolves
> with
> > the extra printing, you can suspect cache flush a bit more strongly.
> > However, WBINVD (which is what ACPI_FLUSH_CPU_CACHE() is) should be
> enough.
>
> CPU0 issuing WBINVD might not be enough; other CPUs should
> probably also do so unconditionally (currently they do this only
> when using one of the advanced halt forms in acpi_dead_idle()).
>
> While one would think that a halted CPU would not only continue
> to keep its cache up-to-date, but also eventually write back its
> dirty cache lines, I don't think the latter is actually guaranteed,
> so if the CPU ends up getting the INIT before the line was written
> back, the modification could get lost.
>
> But of course this theory depends on Ben's system actually using
> the default halt mechanism rather than one of the advanced ones.
>
> Jan
>
>

--14dae9340af39d520f04ca70da8e
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

It is an older system (Core2) - so it may be using the default mechanism, b=
ut I&#39;d have to go dig up some processor docs to be sure.<div><br></div>=
<div>I&#39;m still seeing some behavior in my experiments that I can&#39;t =
entirely explain (yet)</div>
<div>I&#39;ll be spending some time today looking into it more closely.</di=
v><div><br><br><div class=3D"gmail_quote">On Mon, Sep 24, 2012 at 7:22 AM, =
Jan Beulich <span dir=3D"ltr">&lt;<a href=3D"mailto:JBeulich@suse.com" targ=
et=3D"_blank">JBeulich@suse.com</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div class=3D"HOEnZb"><div class=3D"h5">&gt;=
&gt;&gt; On 21.09.12 at 20:42, Keir Fraser &lt;<a href=3D"mailto:keir@xen.o=
rg">keir@xen.org</a>&gt; wrote:<br>

&gt; On 21/09/2012 19:20, &quot;Ben Guthro&quot; &lt;<a href=3D"mailto:ben@=
guthro.net">ben@guthro.net</a>&gt; wrote:<br>
&gt;<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; On Fri, Sep 21, 2012 at 2:47 AM, Jan Beulich &lt;<a href=3D"mailto=
:JBeulich@suse.com">JBeulich@suse.com</a>&gt; wrote:<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; That&#39;s because CPU1 is stuck in cpu_init() (in the infinit=
e loop after<br>
&gt;&gt;&gt; printing &quot;CPU#1 already initialized!&quot;), as Keir poin=
ted out yesterday.<br>
&gt;&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; I&#39;ve done some more tracing on this, and instrumented cpu_init=
(),<br>
&gt; cpu_uninit()<br>
&gt;&gt; - and found something I cannot quite explain.<br>
&gt;&gt; I was most interested in the cpu_initialized mask, set just above =
these two<br>
&gt;&gt; functions (and only used in those two functions)<br>
&gt;&gt;<br>
&gt;&gt; I convert =A0cpu_initialized to a string, using cpumask_scnprintf =
- and print<br>
&gt; it<br>
&gt;&gt; out when it is read, or written in these two functions.<br>
&gt;&gt;<br>
&gt;&gt; When CPU1 is being torn down, the cpumask bit gets cleared for CPU=
1, and I<br>
&gt; am<br>
&gt;&gt; able to print this to the console to verify.<br>
&gt;&gt; However, when the machine is returning from S3, and going through =
cpu_init -<br>
&gt;&gt; the bit is set again.<br>
&gt;&gt;<br>
&gt;&gt; Could this be an issue of caches not being flushed?<br>
&gt;&gt;<br>
&gt;&gt; I see that the last thing done before acpi_enter_sleep_state actua=
lly<br>
&gt;&gt; writes PM1A_CONTROL / PM1B_CONTROL to enter S3 is a ACPI_FLUSH_CPU=
_CACHE()<br>
&gt;&gt;<br>
&gt;&gt; This analysis seems unlikely, at this point...but I&#39;m not sure=
 what to make<br>
&gt; of<br>
&gt;&gt; the data other than a cache issue.<br>
&gt;&gt;<br>
&gt;&gt; Am I &quot;barking up the wrong tree&quot; here?<br>
&gt;<br>
&gt; Perhaps not. Try dumping it immediately before and after the actual S3=
<br>
&gt; sleep. Since you probably can&#39;t print to serial line at that point=
, you<br>
&gt; could just take a copy of the bitmap and print them both shortly after=
 S3<br>
&gt; resume. Then if it still looks bad, or the problem magically resolves =
with<br>
&gt; the extra printing, you can suspect cache flush a bit more strongly.<b=
r>
&gt; However, WBINVD (which is what ACPI_FLUSH_CPU_CACHE() is) should be en=
ough.<br>
<br>
</div></div>CPU0 issuing WBINVD might not be enough; other CPUs should<br>
probably also do so unconditionally (currently they do this only<br>
when using one of the advanced halt forms in acpi_dead_idle()).<br>
<br>
While one would think that a halted CPU would not only continue<br>
to keep its cache up-to-date, but also eventually write back its<br>
dirty cache lines, I don&#39;t think the latter is actually guaranteed,<br>
so if the CPU ends up getting the INIT before the line was written<br>
back, the modification could get lost.<br>
<br>
But of course this theory depends on Ben&#39;s system actually using<br>
the default halt mechanism rather than one of the advanced ones.<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
Jan<br>
<br>
</font></span></blockquote></div><br></div>

--14dae9340af39d520f04ca70da8e--


--===============6081085386524649401==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============6081085386524649401==--


From xen-devel-bounces@lists.xen.org Mon Sep 24 11:26:21 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Sep 2012 11:26:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TG6ne-0003mX-Mv; Mon, 24 Sep 2012 11:26:06 +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 1TG6nc-0003mF-Vh
	for xen-devel@lists.xen.org; Mon, 24 Sep 2012 11:26:05 +0000
Received: from [85.158.143.99:37946] by server-3.bemta-4.messagelabs.com id
	B4/CF-10986-C4340605; Mon, 24 Sep 2012 11:26:04 +0000
X-Env-Sender: ben.guthro@gmail.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1348485960!21749843!1
X-Originating-IP: [209.85.223.173]
X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_20_30,HTML_MESSAGE,
	RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 858 invoked from network); 24 Sep 2012 11:26:01 -0000
Received: from mail-ie0-f173.google.com (HELO mail-ie0-f173.google.com)
	(209.85.223.173)
	by server-8.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Sep 2012 11:26:01 -0000
Received: by iea17 with SMTP id 17so7484826iea.32
	for <xen-devel@lists.xen.org>; Mon, 24 Sep 2012 04:25: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;
	bh=kDHRxzB0hSBcRyN7+fhfgQJR/LSB/r+7fF+lPOYfyGc=;
	b=tNfMi9pfAfTQc+TUCA+WXJrrcaGEbSabftYMkeCqiGeTp3zj7mOBXjPuHjvRfDyg1c
	NXfv5fIk8Yim2HDlUDBizQo2Bgr9d3CFzEGQ21mWN/eUPfoqqzBE9+NywzNZw+kxq7XL
	LRRGgcSY0s1jsnop93xDeu8LsJ1F/5sHUgJUdTquSHzFfl++rWs+EwzgF1fRWsEAlM5a
	J5CB+g669TMhQW3iymvSABaUX0GsWq0HhPj0pPAecDn2DrwoTd51t9U0i4xpBWZ56COy
	DX6iylyZ3n+gGKKlC0h/QQjd4TRaRNelppq4gq3aW0vIbaylUzDSerWIB9kBFg9rRKgU
	gvew==
MIME-Version: 1.0
Received: by 10.50.236.72 with SMTP id us8mr4831854igc.70.1348485959733; Mon,
	24 Sep 2012 04:25:59 -0700 (PDT)
Received: by 10.64.55.132 with HTTP; Mon, 24 Sep 2012 04:25:59 -0700 (PDT)
In-Reply-To: <50605E9A020000780009D486@nat28.tlf.novell.com>
References: <CAOvdn6XKPOMNn6AjuYvZvPXRRJffN3po5GXe1Yh1-m0hisMK_w@mail.gmail.com>
	<CC8273A0.4C9DD%keir@xen.org>
	<50605E9A020000780009D486@nat28.tlf.novell.com>
Date: Mon, 24 Sep 2012 07:25:59 -0400
X-Google-Sender-Auth: g4yNK9DOOIhZtri56EaYe10W18U
Message-ID: <CAOvdn6XmB6rj3_QVU+59V8p24Y5G47AWxVEM=id02JWXkuhibQ@mail.gmail.com>
From: Ben Guthro <ben@guthro.net>
To: Jan Beulich <JBeulich@suse.com>
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>, Keir Fraser <keir@xen.org>,
	john.baboval@citrix.com, Thomas Goetz <thomas.goetz@citrix.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen4.2 S3 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: multipart/mixed; boundary="===============6081085386524649401=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============6081085386524649401==
Content-Type: multipart/alternative; boundary=14dae9340af39d520f04ca70da8e

--14dae9340af39d520f04ca70da8e
Content-Type: text/plain; charset=ISO-8859-1

It is an older system (Core2) - so it may be using the default mechanism,
but I'd have to go dig up some processor docs to be sure.

I'm still seeing some behavior in my experiments that I can't entirely
explain (yet)
I'll be spending some time today looking into it more closely.


On Mon, Sep 24, 2012 at 7:22 AM, Jan Beulich <JBeulich@suse.com> wrote:

> >>> On 21.09.12 at 20:42, Keir Fraser <keir@xen.org> wrote:
> > On 21/09/2012 19:20, "Ben Guthro" <ben@guthro.net> wrote:
> >
> >>
> >>
> >> On Fri, Sep 21, 2012 at 2:47 AM, Jan Beulich <JBeulich@suse.com> wrote:
> >>>
> >>> That's because CPU1 is stuck in cpu_init() (in the infinite loop after
> >>> printing "CPU#1 already initialized!"), as Keir pointed out yesterday.
> >>>
> >>
> >> I've done some more tracing on this, and instrumented cpu_init(),
> > cpu_uninit()
> >> - and found something I cannot quite explain.
> >> I was most interested in the cpu_initialized mask, set just above these
> two
> >> functions (and only used in those two functions)
> >>
> >> I convert  cpu_initialized to a string, using cpumask_scnprintf - and
> print
> > it
> >> out when it is read, or written in these two functions.
> >>
> >> When CPU1 is being torn down, the cpumask bit gets cleared for CPU1,
> and I
> > am
> >> able to print this to the console to verify.
> >> However, when the machine is returning from S3, and going through
> cpu_init -
> >> the bit is set again.
> >>
> >> Could this be an issue of caches not being flushed?
> >>
> >> I see that the last thing done before acpi_enter_sleep_state actually
> >> writes PM1A_CONTROL / PM1B_CONTROL to enter S3 is a
> ACPI_FLUSH_CPU_CACHE()
> >>
> >> This analysis seems unlikely, at this point...but I'm not sure what to
> make
> > of
> >> the data other than a cache issue.
> >>
> >> Am I "barking up the wrong tree" here?
> >
> > Perhaps not. Try dumping it immediately before and after the actual S3
> > sleep. Since you probably can't print to serial line at that point, you
> > could just take a copy of the bitmap and print them both shortly after S3
> > resume. Then if it still looks bad, or the problem magically resolves
> with
> > the extra printing, you can suspect cache flush a bit more strongly.
> > However, WBINVD (which is what ACPI_FLUSH_CPU_CACHE() is) should be
> enough.
>
> CPU0 issuing WBINVD might not be enough; other CPUs should
> probably also do so unconditionally (currently they do this only
> when using one of the advanced halt forms in acpi_dead_idle()).
>
> While one would think that a halted CPU would not only continue
> to keep its cache up-to-date, but also eventually write back its
> dirty cache lines, I don't think the latter is actually guaranteed,
> so if the CPU ends up getting the INIT before the line was written
> back, the modification could get lost.
>
> But of course this theory depends on Ben's system actually using
> the default halt mechanism rather than one of the advanced ones.
>
> Jan
>
>

--14dae9340af39d520f04ca70da8e
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

It is an older system (Core2) - so it may be using the default mechanism, b=
ut I&#39;d have to go dig up some processor docs to be sure.<div><br></div>=
<div>I&#39;m still seeing some behavior in my experiments that I can&#39;t =
entirely explain (yet)</div>
<div>I&#39;ll be spending some time today looking into it more closely.</di=
v><div><br><br><div class=3D"gmail_quote">On Mon, Sep 24, 2012 at 7:22 AM, =
Jan Beulich <span dir=3D"ltr">&lt;<a href=3D"mailto:JBeulich@suse.com" targ=
et=3D"_blank">JBeulich@suse.com</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div class=3D"HOEnZb"><div class=3D"h5">&gt;=
&gt;&gt; On 21.09.12 at 20:42, Keir Fraser &lt;<a href=3D"mailto:keir@xen.o=
rg">keir@xen.org</a>&gt; wrote:<br>

&gt; On 21/09/2012 19:20, &quot;Ben Guthro&quot; &lt;<a href=3D"mailto:ben@=
guthro.net">ben@guthro.net</a>&gt; wrote:<br>
&gt;<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; On Fri, Sep 21, 2012 at 2:47 AM, Jan Beulich &lt;<a href=3D"mailto=
:JBeulich@suse.com">JBeulich@suse.com</a>&gt; wrote:<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; That&#39;s because CPU1 is stuck in cpu_init() (in the infinit=
e loop after<br>
&gt;&gt;&gt; printing &quot;CPU#1 already initialized!&quot;), as Keir poin=
ted out yesterday.<br>
&gt;&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; I&#39;ve done some more tracing on this, and instrumented cpu_init=
(),<br>
&gt; cpu_uninit()<br>
&gt;&gt; - and found something I cannot quite explain.<br>
&gt;&gt; I was most interested in the cpu_initialized mask, set just above =
these two<br>
&gt;&gt; functions (and only used in those two functions)<br>
&gt;&gt;<br>
&gt;&gt; I convert =A0cpu_initialized to a string, using cpumask_scnprintf =
- and print<br>
&gt; it<br>
&gt;&gt; out when it is read, or written in these two functions.<br>
&gt;&gt;<br>
&gt;&gt; When CPU1 is being torn down, the cpumask bit gets cleared for CPU=
1, and I<br>
&gt; am<br>
&gt;&gt; able to print this to the console to verify.<br>
&gt;&gt; However, when the machine is returning from S3, and going through =
cpu_init -<br>
&gt;&gt; the bit is set again.<br>
&gt;&gt;<br>
&gt;&gt; Could this be an issue of caches not being flushed?<br>
&gt;&gt;<br>
&gt;&gt; I see that the last thing done before acpi_enter_sleep_state actua=
lly<br>
&gt;&gt; writes PM1A_CONTROL / PM1B_CONTROL to enter S3 is a ACPI_FLUSH_CPU=
_CACHE()<br>
&gt;&gt;<br>
&gt;&gt; This analysis seems unlikely, at this point...but I&#39;m not sure=
 what to make<br>
&gt; of<br>
&gt;&gt; the data other than a cache issue.<br>
&gt;&gt;<br>
&gt;&gt; Am I &quot;barking up the wrong tree&quot; here?<br>
&gt;<br>
&gt; Perhaps not. Try dumping it immediately before and after the actual S3=
<br>
&gt; sleep. Since you probably can&#39;t print to serial line at that point=
, you<br>
&gt; could just take a copy of the bitmap and print them both shortly after=
 S3<br>
&gt; resume. Then if it still looks bad, or the problem magically resolves =
with<br>
&gt; the extra printing, you can suspect cache flush a bit more strongly.<b=
r>
&gt; However, WBINVD (which is what ACPI_FLUSH_CPU_CACHE() is) should be en=
ough.<br>
<br>
</div></div>CPU0 issuing WBINVD might not be enough; other CPUs should<br>
probably also do so unconditionally (currently they do this only<br>
when using one of the advanced halt forms in acpi_dead_idle()).<br>
<br>
While one would think that a halted CPU would not only continue<br>
to keep its cache up-to-date, but also eventually write back its<br>
dirty cache lines, I don&#39;t think the latter is actually guaranteed,<br>
so if the CPU ends up getting the INIT before the line was written<br>
back, the modification could get lost.<br>
<br>
But of course this theory depends on Ben&#39;s system actually using<br>
the default halt mechanism rather than one of the advanced ones.<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
Jan<br>
<br>
</font></span></blockquote></div><br></div>

--14dae9340af39d520f04ca70da8e--


--===============6081085386524649401==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============6081085386524649401==--


From xen-devel-bounces@lists.xen.org Mon Sep 24 11:26:21 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Sep 2012 11:26:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TG6na-0003ly-99; Mon, 24 Sep 2012 11:26:02 +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 1TG6nY-0003lr-JG
	for xen-devel@lists.xen.org; Mon, 24 Sep 2012 11:26:00 +0000
Received: from [85.158.138.51:34088] by server-13.bemta-3.messagelabs.com id
	20/14-01606-74340605; Mon, 24 Sep 2012 11:25:59 +0000
X-Env-Sender: lars.kurth.xen@gmail.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1348485959!30056778!1
X-Originating-IP: [209.85.214.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4555 invoked from network); 24 Sep 2012 11:25:59 -0000
Received: from mail-bk0-f45.google.com (HELO mail-bk0-f45.google.com)
	(209.85.214.45)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Sep 2012 11:25:59 -0000
Received: by bkcjg9 with SMTP id jg9so2544290bkc.32
	for <xen-devel@lists.xen.org>; Mon, 24 Sep 2012 04:25: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:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=sCtdjQy6vuXMNbUVDYOizfK3BTrw1vRRKmPQCnoFaBE=;
	b=yxvDeGpVaoUyFTIt5TshirowRAD4KNvx1em7tAB0ChWSiBYjtvVuR+7u32X3Zuiit/
	X9sSfaqMAe2LFupMdNcqzonkUn5hs8Wbf6idvAd9mukAp5K5XLyp+cOqIOWhfuSpfm/p
	LRJLA3f43uMEd6I5UClZ4XnD7rpmzRosI/ygTJA7semZgZf0QX/n2KVEQCKNvqR4hL7N
	2CunhiV3lne7ZVreC2fXZ6JCQXXNCTvpZ+2H6i5kDyzxFM9KNXK1VzT216h4RoEc0If1
	yBM22Cr7/LAk0K1/r1am0pc50oreddNLOmq35IMb0kq0ea2RjaJsBtg3ozhI7qXaR4vP
	e2hw==
Received: by 10.204.130.212 with SMTP id u20mr4274963bks.121.1348485958939;
	Mon, 24 Sep 2012 04:25:58 -0700 (PDT)
Received: from [172.16.26.11] (b0fb5b35.bb.sky.com. [176.251.91.53])
	by mx.google.com with ESMTPS id 25sm10058222bkx.9.2012.09.24.04.25.57
	(version=SSLv3 cipher=OTHER); Mon, 24 Sep 2012 04:25:57 -0700 (PDT)
Message-ID: <50604343.1090506@xen.org>
Date: Mon, 24 Sep 2012 12:25:55 +0100
From: Lars Kurth <lars.kurth@xen.org>
User-Agent: Mozilla/5.0 (Windows NT 6.1;
	rv:15.0) Gecko/20120907 Thunderbird/15.0.1
MIME-Version: 1.0
To: xen-devel@lists.xen.org
References: <20448.49637.38489.246434@mariner.uk.xensource.com>
	<1345718230.12501.79.camel@zakaz.uk.xensource.com>
In-Reply-To: <1345718230.12501.79.camel@zakaz.uk.xensource.com>
Subject: Re: [Xen-devel] Security vulnerability process,
 and CVE-2012-0217 [vote?]
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: lars.kurth@xen.org
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi,

Does anybody have any objections to Ian's changes in this patch series? 
None of these appear significant changes. In line with the decision 
making process, I would be happy to apply. But, I am also happy to run 
this through a vote.

The patch series was
[PATCH 1/6] Clarify what info predisclosure list members may share 
during an embargo
[PATCH 2/6] Clarifications to predisclosure list subscription instructions
[PATCH 3/6] Clarify the scope of the process to just the hypervisor project
[PATCH 4/6] Discuss post-embargo disclosure of potentially controversial 
private decisions
[PATCH 5/6] Patch review, expert advice and targetted fixes
[PATCH 6/6] Declare version 1.3 ... that would have changed to 1.4 as we 
added CentOS to the pre-disclosure list in 1.3

Best Regards
Lars

On 23/08/2012 11:37, Ian Campbell wrote:
> On Tue, 2012-06-19 at 19:16 +0100, Ian Jackson wrote:
> [...]
>> More minor policy questions
>> ---------------------------
> [...]
>> Lacunae in the process
>> ----------------------
> I've prepared a series of patches to the policy[0] which implement most
> (but not all) of what was suggested in these two sections. I think they
> are largely uncontroversial, but please do holler if you disagree or
> want to suggest further improvements..
>
> I'm not at all sure that patches are the best way to present this but there
> we are.
>
> Ian.
>
> [0] http://www.xen.org/projects/security_vulnerability_process.html
>
>
>
>
>
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 24 11:26:21 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Sep 2012 11:26:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TG6na-0003ly-99; Mon, 24 Sep 2012 11:26:02 +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 1TG6nY-0003lr-JG
	for xen-devel@lists.xen.org; Mon, 24 Sep 2012 11:26:00 +0000
Received: from [85.158.138.51:34088] by server-13.bemta-3.messagelabs.com id
	20/14-01606-74340605; Mon, 24 Sep 2012 11:25:59 +0000
X-Env-Sender: lars.kurth.xen@gmail.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1348485959!30056778!1
X-Originating-IP: [209.85.214.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4555 invoked from network); 24 Sep 2012 11:25:59 -0000
Received: from mail-bk0-f45.google.com (HELO mail-bk0-f45.google.com)
	(209.85.214.45)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Sep 2012 11:25:59 -0000
Received: by bkcjg9 with SMTP id jg9so2544290bkc.32
	for <xen-devel@lists.xen.org>; Mon, 24 Sep 2012 04:25: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:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=sCtdjQy6vuXMNbUVDYOizfK3BTrw1vRRKmPQCnoFaBE=;
	b=yxvDeGpVaoUyFTIt5TshirowRAD4KNvx1em7tAB0ChWSiBYjtvVuR+7u32X3Zuiit/
	X9sSfaqMAe2LFupMdNcqzonkUn5hs8Wbf6idvAd9mukAp5K5XLyp+cOqIOWhfuSpfm/p
	LRJLA3f43uMEd6I5UClZ4XnD7rpmzRosI/ygTJA7semZgZf0QX/n2KVEQCKNvqR4hL7N
	2CunhiV3lne7ZVreC2fXZ6JCQXXNCTvpZ+2H6i5kDyzxFM9KNXK1VzT216h4RoEc0If1
	yBM22Cr7/LAk0K1/r1am0pc50oreddNLOmq35IMb0kq0ea2RjaJsBtg3ozhI7qXaR4vP
	e2hw==
Received: by 10.204.130.212 with SMTP id u20mr4274963bks.121.1348485958939;
	Mon, 24 Sep 2012 04:25:58 -0700 (PDT)
Received: from [172.16.26.11] (b0fb5b35.bb.sky.com. [176.251.91.53])
	by mx.google.com with ESMTPS id 25sm10058222bkx.9.2012.09.24.04.25.57
	(version=SSLv3 cipher=OTHER); Mon, 24 Sep 2012 04:25:57 -0700 (PDT)
Message-ID: <50604343.1090506@xen.org>
Date: Mon, 24 Sep 2012 12:25:55 +0100
From: Lars Kurth <lars.kurth@xen.org>
User-Agent: Mozilla/5.0 (Windows NT 6.1;
	rv:15.0) Gecko/20120907 Thunderbird/15.0.1
MIME-Version: 1.0
To: xen-devel@lists.xen.org
References: <20448.49637.38489.246434@mariner.uk.xensource.com>
	<1345718230.12501.79.camel@zakaz.uk.xensource.com>
In-Reply-To: <1345718230.12501.79.camel@zakaz.uk.xensource.com>
Subject: Re: [Xen-devel] Security vulnerability process,
 and CVE-2012-0217 [vote?]
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: lars.kurth@xen.org
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi,

Does anybody have any objections to Ian's changes in this patch series? 
None of these appear significant changes. In line with the decision 
making process, I would be happy to apply. But, I am also happy to run 
this through a vote.

The patch series was
[PATCH 1/6] Clarify what info predisclosure list members may share 
during an embargo
[PATCH 2/6] Clarifications to predisclosure list subscription instructions
[PATCH 3/6] Clarify the scope of the process to just the hypervisor project
[PATCH 4/6] Discuss post-embargo disclosure of potentially controversial 
private decisions
[PATCH 5/6] Patch review, expert advice and targetted fixes
[PATCH 6/6] Declare version 1.3 ... that would have changed to 1.4 as we 
added CentOS to the pre-disclosure list in 1.3

Best Regards
Lars

On 23/08/2012 11:37, Ian Campbell wrote:
> On Tue, 2012-06-19 at 19:16 +0100, Ian Jackson wrote:
> [...]
>> More minor policy questions
>> ---------------------------
> [...]
>> Lacunae in the process
>> ----------------------
> I've prepared a series of patches to the policy[0] which implement most
> (but not all) of what was suggested in these two sections. I think they
> are largely uncontroversial, but please do holler if you disagree or
> want to suggest further improvements..
>
> I'm not at all sure that patches are the best way to present this but there
> we are.
>
> Ian.
>
> [0] http://www.xen.org/projects/security_vulnerability_process.html
>
>
>
>
>
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 24 11:28:32 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Sep 2012 11:28:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TG6po-00040n-Ci; Mon, 24 Sep 2012 11:28:20 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1TG6pn-00040f-B0
	for Xen-devel@lists.xensource.com; Mon, 24 Sep 2012 11:28:19 +0000
Received: from [85.158.143.99:56664] by server-2.bemta-4.messagelabs.com id
	04/71-06610-2D340605; Mon, 24 Sep 2012 11:28:18 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1348486097!26247731!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTA4NDk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1708 invoked from network); 24 Sep 2012 11:28:18 -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;
	24 Sep 2012 11:28:18 -0000
X-IronPort-AV: E=Sophos;i="4.80,474,1344211200"; d="scan'208";a="14721251"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Sep 2012 11:27: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.279.1; Mon, 24 Sep 2012 12:27:49 +0100
Date: Mon, 24 Sep 2012 12:26:57 +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: <20120921121511.30001c08@mantra.us.oracle.com>
Message-ID: <alpine.DEB.2.02.1209241214280.29232@kaball.uk.xensource.com>
References: <20120921121511.30001c08@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>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH v1 1/8]: PVH  basic and hader file changes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 21 Sep 2012, Mukesh Rathor wrote:
> ---
>  arch/x86/include/asm/xen/interface.h |    8 +++++++-
>  arch/x86/include/asm/xen/page.h      |    3 +++
>  arch/x86/xen/irq.c                   |    5 ++++-
>  arch/x86/xen/p2m.c                   |    2 +-
>  drivers/xen/cpu_hotplug.c            |    4 +++-
>  drivers/xen/events.c                 |   12 ++++++++----
>  drivers/xen/xenbus/xenbus_client.c   |    2 +-
>  drivers/xen/xenbus/xenbus_probe.c    |    6 +++++-
>  include/xen/interface/memory.h       |   27 +++++++++++++++++++++++++++
>  include/xen/interface/physdev.h      |   10 ++++++++++
>  10 files changed, 69 insertions(+), 10 deletions(-)
> 
> diff --git a/arch/x86/include/asm/xen/interface.h b/arch/x86/include/asm/xen/interface.h
> index cbf0c9d..1d22131 100644
> --- a/arch/x86/include/asm/xen/interface.h
> +++ b/arch/x86/include/asm/xen/interface.h
> @@ -136,7 +136,13 @@ struct vcpu_guest_context {
>      struct cpu_user_regs user_regs;         /* User-level CPU registers     */
>      struct trap_info trap_ctxt[256];        /* Virtual IDT                  */
>      unsigned long ldt_base, ldt_ents;       /* LDT (linear address, # ents) */
> -    unsigned long gdt_frames[16], gdt_ents; /* GDT (machine frames, # ents) */
> +    union {
> +	struct {
> +		/* PV: GDT (machine frames, # ents).*/
> +		unsigned long gdt_frames[16], gdt_ents;
> +	};
> +	unsigned long gdtaddr, gdtsz;	    /* PVH: GDTR addr and size */
> +    };
>      unsigned long kernel_ss, kernel_sp;     /* Virtual TSS (only SS1/SP1)   */
>      /* NB. User pagetable on x86/64 is placed in ctrlreg[1]. */
>      unsigned long ctrlreg[8];               /* CR0-CR7 (control registers)  */

I think I'll be fully able to understand what these are for only after I
read the Xen side patches...


> diff --git a/arch/x86/include/asm/xen/page.h b/arch/x86/include/asm/xen/page.h
> index 93971e8..d1cfb96 100644
> --- a/arch/x86/include/asm/xen/page.h
> +++ b/arch/x86/include/asm/xen/page.h
> @@ -158,6 +158,9 @@ static inline xpaddr_t machine_to_phys(xmaddr_t machine)
>  static inline unsigned long mfn_to_local_pfn(unsigned long mfn)
>  {
>  	unsigned long pfn = mfn_to_pfn(mfn);
> +
> +	if (xen_feature(XENFEAT_auto_translated_physmap))
> +		return mfn;
>  	if (get_phys_to_machine(pfn) != mfn)
>  		return -1; /* force !pfn_valid() */
>  	return pfn;
> diff --git a/arch/x86/xen/irq.c b/arch/x86/xen/irq.c
> index 1573376..31959a7 100644
> --- a/arch/x86/xen/irq.c
> +++ b/arch/x86/xen/irq.c
> @@ -5,6 +5,7 @@
>  #include <xen/interface/xen.h>
>  #include <xen/interface/sched.h>
>  #include <xen/interface/vcpu.h>
> +#include <xen/features.h>
>  
>  #include <asm/xen/hypercall.h>
>  #include <asm/xen/hypervisor.h>
> @@ -128,6 +129,8 @@ static const struct pv_irq_ops xen_irq_ops __initconst = {
>  
>  void __init xen_init_irq_ops(void)
>  {
> -	pv_irq_ops = xen_irq_ops;
> +	/* For PVH we use default pv_irq_ops settings */
> +	if (!xen_feature(XENFEAT_hvm_callback_vector))
> +		pv_irq_ops = xen_irq_ops;
>  	x86_init.irqs.intr_init = xen_init_IRQ;
>  }
> diff --git a/arch/x86/xen/p2m.c b/arch/x86/xen/p2m.c
> index 64effdc..a954f83 100644
> --- a/arch/x86/xen/p2m.c
> +++ b/arch/x86/xen/p2m.c
> @@ -626,7 +626,7 @@ bool __set_phys_to_machine(unsigned long pfn, unsigned long mfn)
>  {
>  	unsigned topidx, mididx, idx;
>  
> -	if (unlikely(xen_feature(XENFEAT_auto_translated_physmap))) {
> +	if (xen_feature(XENFEAT_auto_translated_physmap)) {
>  		BUG_ON(pfn != mfn && mfn != INVALID_P2M_ENTRY);
>  		return true;
>  	}
> diff --git a/drivers/xen/cpu_hotplug.c b/drivers/xen/cpu_hotplug.c
> index 4dcfced..de6bcf9 100644
> --- a/drivers/xen/cpu_hotplug.c
> +++ b/drivers/xen/cpu_hotplug.c
> @@ -2,6 +2,7 @@
>  
>  #include <xen/xen.h>
>  #include <xen/xenbus.h>
> +#include <xen/features.h>
>  
>  #include <asm/xen/hypervisor.h>
>  #include <asm/cpu.h>
> @@ -100,7 +101,8 @@ static int __init setup_vcpu_hotplug_event(void)
>  	static struct notifier_block xsn_cpu = {
>  		.notifier_call = setup_cpu_watcher };
>  
> -	if (!xen_pv_domain())
> +	/* PVH TBD/FIXME: future work */
> +	if (!xen_pv_domain() || xen_feature(XENFEAT_auto_translated_physmap))
>  		return -ENODEV;

Didn't we say that a PVH domain is actually a pv guest?
In that case shouldn't the test

if (!xen_pv_domain())

be sufficient?


>  	register_xenstore_notifier(&xsn_cpu);
> diff --git a/drivers/xen/events.c b/drivers/xen/events.c
> index 7595581..f656791 100644
> --- a/drivers/xen/events.c
> +++ b/drivers/xen/events.c
> @@ -1755,7 +1755,7 @@ int xen_set_callback_via(uint64_t via)
>  }
>  EXPORT_SYMBOL_GPL(xen_set_callback_via);
>  
> -#ifdef CONFIG_XEN_PVHVM
> +
>  /* Vector callbacks are better than PCI interrupts to receive event
>   * channel notifications because we can receive vector callbacks on any
>   * vcpu and we don't need PCI support or APIC interactions. */
> @@ -1779,9 +1779,6 @@ void xen_callback_vector(void)
>  			alloc_intr_gate(XEN_HVM_EVTCHN_CALLBACK, xen_hvm_callback_vector);
>  	}
>  }
> -#else
> -void xen_callback_vector(void) {}
> -#endif
>  
>  void __init xen_init_IRQ(void)
>  {
> @@ -1814,6 +1811,13 @@ void __init xen_init_IRQ(void)
>  		if (xen_initial_domain())
>  			pci_xen_initial_domain();
>  
> +		if (xen_feature(XENFEAT_hvm_callback_vector)) {
> +			xen_callback_vector();
> +			return;
> +		}
> +
> +		/* PVH: TBD/FIXME: debug and fix eio map to work with pvh */
> +
>  		pirq_eoi_map = (void *)__get_free_page(GFP_KERNEL|__GFP_ZERO);
>  		eoi_gmfn.gmfn = virt_to_mfn(pirq_eoi_map);
>  		rc = HYPERVISOR_physdev_op(PHYSDEVOP_pirq_eoi_gmfn_v2, &eoi_gmfn);
> diff --git a/drivers/xen/xenbus/xenbus_client.c b/drivers/xen/xenbus/xenbus_client.c
> index b3e146e..a81e66b 100644
> --- a/drivers/xen/xenbus/xenbus_client.c
> +++ b/drivers/xen/xenbus/xenbus_client.c
> @@ -743,7 +743,7 @@ static const struct xenbus_ring_ops ring_ops_hvm = {
>  
>  void __init xenbus_ring_ops_init(void)
>  {
> -	if (xen_pv_domain())
> +	if (xen_pv_domain() && !xen_feature(XENFEAT_auto_translated_physmap))
>  		ring_ops = &ring_ops_pv;
>  	else
>  		ring_ops = &ring_ops_hvm;
> diff --git a/drivers/xen/xenbus/xenbus_probe.c b/drivers/xen/xenbus/xenbus_probe.c
> index b793723..481dc72 100644
> --- a/drivers/xen/xenbus/xenbus_probe.c
> +++ b/drivers/xen/xenbus/xenbus_probe.c
> @@ -749,7 +749,11 @@ static int __init xenbus_init(void)
>  			if (err)
>  				goto out_error;
>  		}
> -		xen_store_interface = mfn_to_virt(xen_store_mfn);
> +                if (xen_feature(XENFEAT_auto_translated_physmap))

small code style issue here

> +			/* mfn is actually a pfn */
> +			xen_store_interface = __va(xen_store_mfn<<PAGE_SHIFT);
> +		else
> +			xen_store_interface = mfn_to_virt(xen_store_mfn);
>  	}

I think that mfn_to_virt should work for PVH too: mfn_to_virt is:

(__va(mfn_to_pfn(m) << PAGE_SHIFT))

and mfn_to_pfn just return mfn when XENFEAT_auto_translated_physmap is
set

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 24 11:28:32 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Sep 2012 11:28:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TG6po-00040n-Ci; Mon, 24 Sep 2012 11:28:20 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1TG6pn-00040f-B0
	for Xen-devel@lists.xensource.com; Mon, 24 Sep 2012 11:28:19 +0000
Received: from [85.158.143.99:56664] by server-2.bemta-4.messagelabs.com id
	04/71-06610-2D340605; Mon, 24 Sep 2012 11:28:18 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1348486097!26247731!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTA4NDk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1708 invoked from network); 24 Sep 2012 11:28:18 -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;
	24 Sep 2012 11:28:18 -0000
X-IronPort-AV: E=Sophos;i="4.80,474,1344211200"; d="scan'208";a="14721251"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Sep 2012 11:27: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.279.1; Mon, 24 Sep 2012 12:27:49 +0100
Date: Mon, 24 Sep 2012 12:26:57 +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: <20120921121511.30001c08@mantra.us.oracle.com>
Message-ID: <alpine.DEB.2.02.1209241214280.29232@kaball.uk.xensource.com>
References: <20120921121511.30001c08@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>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH v1 1/8]: PVH  basic and hader file changes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 21 Sep 2012, Mukesh Rathor wrote:
> ---
>  arch/x86/include/asm/xen/interface.h |    8 +++++++-
>  arch/x86/include/asm/xen/page.h      |    3 +++
>  arch/x86/xen/irq.c                   |    5 ++++-
>  arch/x86/xen/p2m.c                   |    2 +-
>  drivers/xen/cpu_hotplug.c            |    4 +++-
>  drivers/xen/events.c                 |   12 ++++++++----
>  drivers/xen/xenbus/xenbus_client.c   |    2 +-
>  drivers/xen/xenbus/xenbus_probe.c    |    6 +++++-
>  include/xen/interface/memory.h       |   27 +++++++++++++++++++++++++++
>  include/xen/interface/physdev.h      |   10 ++++++++++
>  10 files changed, 69 insertions(+), 10 deletions(-)
> 
> diff --git a/arch/x86/include/asm/xen/interface.h b/arch/x86/include/asm/xen/interface.h
> index cbf0c9d..1d22131 100644
> --- a/arch/x86/include/asm/xen/interface.h
> +++ b/arch/x86/include/asm/xen/interface.h
> @@ -136,7 +136,13 @@ struct vcpu_guest_context {
>      struct cpu_user_regs user_regs;         /* User-level CPU registers     */
>      struct trap_info trap_ctxt[256];        /* Virtual IDT                  */
>      unsigned long ldt_base, ldt_ents;       /* LDT (linear address, # ents) */
> -    unsigned long gdt_frames[16], gdt_ents; /* GDT (machine frames, # ents) */
> +    union {
> +	struct {
> +		/* PV: GDT (machine frames, # ents).*/
> +		unsigned long gdt_frames[16], gdt_ents;
> +	};
> +	unsigned long gdtaddr, gdtsz;	    /* PVH: GDTR addr and size */
> +    };
>      unsigned long kernel_ss, kernel_sp;     /* Virtual TSS (only SS1/SP1)   */
>      /* NB. User pagetable on x86/64 is placed in ctrlreg[1]. */
>      unsigned long ctrlreg[8];               /* CR0-CR7 (control registers)  */

I think I'll be fully able to understand what these are for only after I
read the Xen side patches...


> diff --git a/arch/x86/include/asm/xen/page.h b/arch/x86/include/asm/xen/page.h
> index 93971e8..d1cfb96 100644
> --- a/arch/x86/include/asm/xen/page.h
> +++ b/arch/x86/include/asm/xen/page.h
> @@ -158,6 +158,9 @@ static inline xpaddr_t machine_to_phys(xmaddr_t machine)
>  static inline unsigned long mfn_to_local_pfn(unsigned long mfn)
>  {
>  	unsigned long pfn = mfn_to_pfn(mfn);
> +
> +	if (xen_feature(XENFEAT_auto_translated_physmap))
> +		return mfn;
>  	if (get_phys_to_machine(pfn) != mfn)
>  		return -1; /* force !pfn_valid() */
>  	return pfn;
> diff --git a/arch/x86/xen/irq.c b/arch/x86/xen/irq.c
> index 1573376..31959a7 100644
> --- a/arch/x86/xen/irq.c
> +++ b/arch/x86/xen/irq.c
> @@ -5,6 +5,7 @@
>  #include <xen/interface/xen.h>
>  #include <xen/interface/sched.h>
>  #include <xen/interface/vcpu.h>
> +#include <xen/features.h>
>  
>  #include <asm/xen/hypercall.h>
>  #include <asm/xen/hypervisor.h>
> @@ -128,6 +129,8 @@ static const struct pv_irq_ops xen_irq_ops __initconst = {
>  
>  void __init xen_init_irq_ops(void)
>  {
> -	pv_irq_ops = xen_irq_ops;
> +	/* For PVH we use default pv_irq_ops settings */
> +	if (!xen_feature(XENFEAT_hvm_callback_vector))
> +		pv_irq_ops = xen_irq_ops;
>  	x86_init.irqs.intr_init = xen_init_IRQ;
>  }
> diff --git a/arch/x86/xen/p2m.c b/arch/x86/xen/p2m.c
> index 64effdc..a954f83 100644
> --- a/arch/x86/xen/p2m.c
> +++ b/arch/x86/xen/p2m.c
> @@ -626,7 +626,7 @@ bool __set_phys_to_machine(unsigned long pfn, unsigned long mfn)
>  {
>  	unsigned topidx, mididx, idx;
>  
> -	if (unlikely(xen_feature(XENFEAT_auto_translated_physmap))) {
> +	if (xen_feature(XENFEAT_auto_translated_physmap)) {
>  		BUG_ON(pfn != mfn && mfn != INVALID_P2M_ENTRY);
>  		return true;
>  	}
> diff --git a/drivers/xen/cpu_hotplug.c b/drivers/xen/cpu_hotplug.c
> index 4dcfced..de6bcf9 100644
> --- a/drivers/xen/cpu_hotplug.c
> +++ b/drivers/xen/cpu_hotplug.c
> @@ -2,6 +2,7 @@
>  
>  #include <xen/xen.h>
>  #include <xen/xenbus.h>
> +#include <xen/features.h>
>  
>  #include <asm/xen/hypervisor.h>
>  #include <asm/cpu.h>
> @@ -100,7 +101,8 @@ static int __init setup_vcpu_hotplug_event(void)
>  	static struct notifier_block xsn_cpu = {
>  		.notifier_call = setup_cpu_watcher };
>  
> -	if (!xen_pv_domain())
> +	/* PVH TBD/FIXME: future work */
> +	if (!xen_pv_domain() || xen_feature(XENFEAT_auto_translated_physmap))
>  		return -ENODEV;

Didn't we say that a PVH domain is actually a pv guest?
In that case shouldn't the test

if (!xen_pv_domain())

be sufficient?


>  	register_xenstore_notifier(&xsn_cpu);
> diff --git a/drivers/xen/events.c b/drivers/xen/events.c
> index 7595581..f656791 100644
> --- a/drivers/xen/events.c
> +++ b/drivers/xen/events.c
> @@ -1755,7 +1755,7 @@ int xen_set_callback_via(uint64_t via)
>  }
>  EXPORT_SYMBOL_GPL(xen_set_callback_via);
>  
> -#ifdef CONFIG_XEN_PVHVM
> +
>  /* Vector callbacks are better than PCI interrupts to receive event
>   * channel notifications because we can receive vector callbacks on any
>   * vcpu and we don't need PCI support or APIC interactions. */
> @@ -1779,9 +1779,6 @@ void xen_callback_vector(void)
>  			alloc_intr_gate(XEN_HVM_EVTCHN_CALLBACK, xen_hvm_callback_vector);
>  	}
>  }
> -#else
> -void xen_callback_vector(void) {}
> -#endif
>  
>  void __init xen_init_IRQ(void)
>  {
> @@ -1814,6 +1811,13 @@ void __init xen_init_IRQ(void)
>  		if (xen_initial_domain())
>  			pci_xen_initial_domain();
>  
> +		if (xen_feature(XENFEAT_hvm_callback_vector)) {
> +			xen_callback_vector();
> +			return;
> +		}
> +
> +		/* PVH: TBD/FIXME: debug and fix eio map to work with pvh */
> +
>  		pirq_eoi_map = (void *)__get_free_page(GFP_KERNEL|__GFP_ZERO);
>  		eoi_gmfn.gmfn = virt_to_mfn(pirq_eoi_map);
>  		rc = HYPERVISOR_physdev_op(PHYSDEVOP_pirq_eoi_gmfn_v2, &eoi_gmfn);
> diff --git a/drivers/xen/xenbus/xenbus_client.c b/drivers/xen/xenbus/xenbus_client.c
> index b3e146e..a81e66b 100644
> --- a/drivers/xen/xenbus/xenbus_client.c
> +++ b/drivers/xen/xenbus/xenbus_client.c
> @@ -743,7 +743,7 @@ static const struct xenbus_ring_ops ring_ops_hvm = {
>  
>  void __init xenbus_ring_ops_init(void)
>  {
> -	if (xen_pv_domain())
> +	if (xen_pv_domain() && !xen_feature(XENFEAT_auto_translated_physmap))
>  		ring_ops = &ring_ops_pv;
>  	else
>  		ring_ops = &ring_ops_hvm;
> diff --git a/drivers/xen/xenbus/xenbus_probe.c b/drivers/xen/xenbus/xenbus_probe.c
> index b793723..481dc72 100644
> --- a/drivers/xen/xenbus/xenbus_probe.c
> +++ b/drivers/xen/xenbus/xenbus_probe.c
> @@ -749,7 +749,11 @@ static int __init xenbus_init(void)
>  			if (err)
>  				goto out_error;
>  		}
> -		xen_store_interface = mfn_to_virt(xen_store_mfn);
> +                if (xen_feature(XENFEAT_auto_translated_physmap))

small code style issue here

> +			/* mfn is actually a pfn */
> +			xen_store_interface = __va(xen_store_mfn<<PAGE_SHIFT);
> +		else
> +			xen_store_interface = mfn_to_virt(xen_store_mfn);
>  	}

I think that mfn_to_virt should work for PVH too: mfn_to_virt is:

(__va(mfn_to_pfn(m) << PAGE_SHIFT))

and mfn_to_pfn just return mfn when XENFEAT_auto_translated_physmap is
set

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 24 11:29:34 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Sep 2012 11: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 1TG6qp-00047o-R3; Mon, 24 Sep 2012 11:29: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 1TG6qo-00047e-Is
	for Xen-devel@lists.xensource.com; Mon, 24 Sep 2012 11:29:22 +0000
Received: from [85.158.143.35:58313] by server-2.bemta-4.messagelabs.com id
	55/13-06610-11440605; Mon, 24 Sep 2012 11:29:21 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1348486161!18225986!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTA4NDk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18009 invoked from network); 24 Sep 2012 11:29:21 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Sep 2012 11:29:21 -0000
X-IronPort-AV: E=Sophos;i="4.80,474,1344211200"; d="scan'208";a="14721295"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Sep 2012 11:29: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.279.1;
	Mon, 24 Sep 2012 12:29:20 +0100
Message-ID: <1348486159.3452.61.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Date: Mon, 24 Sep 2012 12:29:19 +0100
In-Reply-To: <alpine.DEB.2.02.1209241214280.29232@kaball.uk.xensource.com>
References: <20120921121511.30001c08@mantra.us.oracle.com>
	<alpine.DEB.2.02.1209241214280.29232@kaball.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH v1 1/8]: PVH  basic and hader file changes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2012-09-24 at 12:26 +0100, Stefano Stabellini wrote:
> > diff --git a/arch/x86/include/asm/xen/interface.h b/arch/x86/include/asm/xen/interface.h
> > index cbf0c9d..1d22131 100644
> > --- a/arch/x86/include/asm/xen/interface.h
> > +++ b/arch/x86/include/asm/xen/interface.h
> > @@ -136,7 +136,13 @@ struct vcpu_guest_context {
> >      struct cpu_user_regs user_regs;         /* User-level CPU registers     */
> >      struct trap_info trap_ctxt[256];        /* Virtual IDT                  */
> >      unsigned long ldt_base, ldt_ents;       /* LDT (linear address, # ents) */
> > -    unsigned long gdt_frames[16], gdt_ents; /* GDT (machine frames, # ents) */
> > +    union {
> > +	struct {
> > +		/* PV: GDT (machine frames, # ents).*/
> > +		unsigned long gdt_frames[16], gdt_ents;
> > +	};
> > +	unsigned long gdtaddr, gdtsz;	    /* PVH: GDTR addr and size */
> > +    };
> >      unsigned long kernel_ss, kernel_sp;     /* Virtual TSS (only SS1/SP1)   */
> >      /* NB. User pagetable on x86/64 is placed in ctrlreg[1]. */
> >      unsigned long ctrlreg[8];               /* CR0-CR7 (control registers)  */
> 
> I think I'll be fully able to understand what these are for only after I
> read the Xen side patches...

Also won't this cause gdtaddr and gdtsz to share the same storage, since
they are immediately inside a union -- I suspect that isn't what was
wanted!



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 24 11:29:34 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Sep 2012 11: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 1TG6qp-00047o-R3; Mon, 24 Sep 2012 11:29: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 1TG6qo-00047e-Is
	for Xen-devel@lists.xensource.com; Mon, 24 Sep 2012 11:29:22 +0000
Received: from [85.158.143.35:58313] by server-2.bemta-4.messagelabs.com id
	55/13-06610-11440605; Mon, 24 Sep 2012 11:29:21 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1348486161!18225986!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTA4NDk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18009 invoked from network); 24 Sep 2012 11:29:21 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Sep 2012 11:29:21 -0000
X-IronPort-AV: E=Sophos;i="4.80,474,1344211200"; d="scan'208";a="14721295"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Sep 2012 11:29: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.279.1;
	Mon, 24 Sep 2012 12:29:20 +0100
Message-ID: <1348486159.3452.61.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Date: Mon, 24 Sep 2012 12:29:19 +0100
In-Reply-To: <alpine.DEB.2.02.1209241214280.29232@kaball.uk.xensource.com>
References: <20120921121511.30001c08@mantra.us.oracle.com>
	<alpine.DEB.2.02.1209241214280.29232@kaball.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH v1 1/8]: PVH  basic and hader file changes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2012-09-24 at 12:26 +0100, Stefano Stabellini wrote:
> > diff --git a/arch/x86/include/asm/xen/interface.h b/arch/x86/include/asm/xen/interface.h
> > index cbf0c9d..1d22131 100644
> > --- a/arch/x86/include/asm/xen/interface.h
> > +++ b/arch/x86/include/asm/xen/interface.h
> > @@ -136,7 +136,13 @@ struct vcpu_guest_context {
> >      struct cpu_user_regs user_regs;         /* User-level CPU registers     */
> >      struct trap_info trap_ctxt[256];        /* Virtual IDT                  */
> >      unsigned long ldt_base, ldt_ents;       /* LDT (linear address, # ents) */
> > -    unsigned long gdt_frames[16], gdt_ents; /* GDT (machine frames, # ents) */
> > +    union {
> > +	struct {
> > +		/* PV: GDT (machine frames, # ents).*/
> > +		unsigned long gdt_frames[16], gdt_ents;
> > +	};
> > +	unsigned long gdtaddr, gdtsz;	    /* PVH: GDTR addr and size */
> > +    };
> >      unsigned long kernel_ss, kernel_sp;     /* Virtual TSS (only SS1/SP1)   */
> >      /* NB. User pagetable on x86/64 is placed in ctrlreg[1]. */
> >      unsigned long ctrlreg[8];               /* CR0-CR7 (control registers)  */
> 
> I think I'll be fully able to understand what these are for only after I
> read the Xen side patches...

Also won't this cause gdtaddr and gdtsz to share the same storage, since
they are immediately inside a union -- I suspect that isn't what was
wanted!



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 24 11:35:53 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Sep 2012 11:35:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TG6wu-0004Sb-Ph; Mon, 24 Sep 2012 11:35:40 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1TG6wt-0004SW-Cd
	for xen-devel@lists.xen.org; Mon, 24 Sep 2012 11:35:39 +0000
Received: from [85.158.137.99:5271] by server-16.bemta-3.messagelabs.com id
	AA/C9-31776-A8540605; Mon, 24 Sep 2012 11:35:38 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-217.messagelabs.com!1348486537!16523557!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTA4NDk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17491 invoked from network); 24 Sep 2012 11:35:37 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Sep 2012 11:35:37 -0000
X-IronPort-AV: E=Sophos;i="4.80,474,1344211200"; d="scan'208";a="14721434"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Sep 2012 11:35: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.279.1; Mon, 24 Sep 2012 12:35: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
	1TG6wq-0000XS-I7; Mon, 24 Sep 2012 11:35:36 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1TG6wq-0006Hj-EG;
	Mon, 24 Sep 2012 12:35:36 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20576.17800.334075.677204@mariner.uk.xensource.com>
Date: Mon, 24 Sep 2012 12:35:36 +0100
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1345215949.10161.76.camel@zakaz.uk.xensource.com>
References: <1343657037-28495-1-git-send-email-ian.campbell@citrix.com>
	<1344506462.32142.96.camel@zakaz.uk.xensource.com>
	<20515.49901.369414.638893@mariner.uk.xensource.com>
	<1345215949.10161.76.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] [DOCDAY PATCH] docs: initial documentation for
	xenstore paths
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("Re: [DOCDAY PATCH] docs: initial documentation for xenstore paths"):
> On Thu, 2012-08-09 at 15:02 +0100, Ian Jackson wrote:
> > Ian Campbell writes ("Re: [DOCDAY PATCH] docs: initial documentation for xenstore paths"):
> > ...
> > > > --- a/docs/misc/xenstore-paths.markdown
> > > > +++ b/docs/misc/xenstore-paths.markdown
> > > > @@ -0,0 +1,294 @@
> > ...
> > > > +PATH can contain simple regex constructs following the POSIX regexp
> > > > +syntax described in regexp(7). In addition the following additional
> > > > +wild card names are defined and are evaluated before regexp expansion:
> > 
> > Can we use a restricted perl re syntax ?  That avoids weirdness with
> > the rules for \.
> 
> Is "restricted perl re syntax" a well defined thing (reference?) or do
> you just mean perlre(1)--?

I mean pcre, or perlre(1), probably.

> What's the weirdness with \.?

In Perl syntax, a punctuation character preceded by \ is always a
literal, and all metacharacters are unbackslashed punctuation.

In regexp(7) you need to remember which of ( ) | [ ] . & $ need
\-escaping to be literals and which need \-annotating to be
metacharacters.  (And there are various dialects of this too; for
example Emacs regexps require \ in front of a different subset of the
punctuation.)

I don't particularly care about all the fancy (?:...) etc. extensions,
but being able to write the regexp without referring to the manual, or
experimenting, is very good - particularly in a document which will be
tested at most rather indirectly.

> > > > +The process ID of the device model associated with this domain, if it
> > > > +has one.
> > > > +
> > > > +XXX why is this visible to the guest?
> > 
> > I think some of these things were put here just because there wasn't
> > another place for the toolstack to store things.  See also the
> > arbitrary junk stored by scripts in the device backend directories.
> 
> Should we define a proper home for these? e.g. /$toolstack/$domid?

Yes, we should, but the purpose of the doc is to document what we do
now, not what we will do :-).  I just replied to explain your XXX.

> > Should have a cross-reference to the cpu online/offline protocol,
> > which appears to be in xen/include/public/vcpu.h.  It doesn't seem to
> > be fully documented yet.
> 
> vcpu.h has the hypercalls which are the mechanism by which a guest
> brings a cpu up/down but nothing on the xenstore protocol which might
> cause it to do so.
> 
> I don't think a reference currently exists for that protocol. This
> probably belongs in the same (non-existent) protocol doc as
> ~/control/shutdown in so much as it is a toolstack<->guest kernel
> protocol.

Right.  Well, then a cross-reference to vcpu.h is in order along with
remarks along the lines you quote about the lack of a proper protocol
document.

> > This should have a cross-reference to the documentation defining
> > static-max etc.  I thought we had some in tree but I can't seem to
> > find it.  The best I can find is docs/man/xl.cfg.pod.5.
> 
> I think you might be thinking of tools/libxl/libxl_memory.txt.
> 
> Shall we move that doc to docs/misc?

Good idea.

> Perhaps:
> 
>         every effort to ... reach this target
> 
> ? but I'm not sure that is strictly correct, a guest can use less if it
> wants to. So perhaps
> 
>         every effort to ... not use more than this
>         
> ? seems clumsy though.

:-).  These all seem fine to me.

> > > > +#### ~/device/suspend/event-channel = ""|EVTCHN [w]
> > > > +
> > > > +The domain's suspend event channel. The use of a suspend event channel
> > > > +is optional at the domain's discression. If it is not used then this
> > > > +path will be left blank.
> > 
> > May it be ENOENT ?  Does the toolstack create it as "" then ?
> 
> libxl seems to *mkdir* it:
>     libxl__xs_mkdir(gc, t,
>                     libxl__sprintf(gc, "%s/device/suspend/event-channel", dom_path),
>                     rwperm, ARRAY_SIZE(rwperm));
> 
> which I suppose is the same as writing it as "" (unless there is some
> subtle xenstore semantic difference I'm not thinking of)

As docs/misc/xenstore.txt says:

 If a particular path exists, all of its parents do too.  Every
 existing path maps to a possibly empty value, and may also have zero
 or more immediate children.  There is thus no particular distinction
 between directories and leaf nodes.  However, it is conventional not
 to store nonempty values at nodes which also have children.

The difference between MKDIR and WRITE is simply that if there is an
existing node, WRITE overwrites its value and MKDIR leaves it
unchanged.  See the doc.

> > > > +XXX why is this exposed to the guest?
> > 
> > Is there really only one event channel ?  Ie the same evtchn is used
> > to signal to xenstore that the guest has sent a command, and to signal
> > the guest that xenstore has written the response ?
> 
> Yes, event channels are bidirectional so that's quite common.

Oh, I didn't realise they were bidirectional.

> > Anyway surely this is something the guest needs to know.  Why it's in
> > xenstore is a bit of a mystery since you can't use xenstore without it
> > and it's in the start_info.
> 
> I should have written "why is this exposed to the guest via xenstore?"

Right.  OK.

> > Is this the same value as start_info.store_evtchn ?  Cross reference ?
> 
> I'd be semi inclined to ditch/deprecate it unless we can figure out what
> it is for -- as you say there is something of a chicken and egg problem
> with using it.

I think it's fine to deprecate it.

> > I think it's not specified anywhere.  It's ad-hoc.  The guest
> > shouldn't need to see it but exposing it readonly is probably
> > harmless.  Except perhaps for the vnc password ?
> 
> vnc password appears to go into /vm/$uuid/vncpass (looking at libxl code
> only).

Yuk.  We want to abolish /vm/$uuid/ surely.

> AFAIK it does nothing special with the perms, but /vm/$uuid is not guest
> readable (perms are "n0") so I think that works out ok.
> 
> I wonder if that's part of the point of /vm/$uuid.

Perhaps we should make a new directory for this.  We do seem to have
quite a bit of cruft in our system which attempting to write this
document is revealing.

The right answer is probably to mention it in the doc as "likely to
move".

> > > > +### /vm/$UUID/uuid = UUID []
> > > > +
> > > > +Value is the same UUID as the path.
> > > > +
> > > > +### /vm/$UUID/name = STRING []
> > > > +
> > > > +The domains name.
> > 
> > IMO this should be
> >   (a) in /local/domain/$DOMID
> >   (b) also a copy in /byname/$NAME = $DOMID   for fast lookup
> > but not in 4.2.
> > 
> > Guests shouldn't rely on it.  In fact do guests actually need anything
> > from here ?
> 
> I'd say definitely not, but it has existed with xend for many years so
> I'd be surprised if something hadn't crept in somewhere :-(

Yers.

We should at least say that guests shouldn't use it.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 24 11:35:53 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Sep 2012 11:35:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TG6wu-0004Sb-Ph; Mon, 24 Sep 2012 11:35:40 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1TG6wt-0004SW-Cd
	for xen-devel@lists.xen.org; Mon, 24 Sep 2012 11:35:39 +0000
Received: from [85.158.137.99:5271] by server-16.bemta-3.messagelabs.com id
	AA/C9-31776-A8540605; Mon, 24 Sep 2012 11:35:38 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-217.messagelabs.com!1348486537!16523557!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTA4NDk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17491 invoked from network); 24 Sep 2012 11:35:37 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Sep 2012 11:35:37 -0000
X-IronPort-AV: E=Sophos;i="4.80,474,1344211200"; d="scan'208";a="14721434"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Sep 2012 11:35: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.279.1; Mon, 24 Sep 2012 12:35: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
	1TG6wq-0000XS-I7; Mon, 24 Sep 2012 11:35:36 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1TG6wq-0006Hj-EG;
	Mon, 24 Sep 2012 12:35:36 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20576.17800.334075.677204@mariner.uk.xensource.com>
Date: Mon, 24 Sep 2012 12:35:36 +0100
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1345215949.10161.76.camel@zakaz.uk.xensource.com>
References: <1343657037-28495-1-git-send-email-ian.campbell@citrix.com>
	<1344506462.32142.96.camel@zakaz.uk.xensource.com>
	<20515.49901.369414.638893@mariner.uk.xensource.com>
	<1345215949.10161.76.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] [DOCDAY PATCH] docs: initial documentation for
	xenstore paths
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("Re: [DOCDAY PATCH] docs: initial documentation for xenstore paths"):
> On Thu, 2012-08-09 at 15:02 +0100, Ian Jackson wrote:
> > Ian Campbell writes ("Re: [DOCDAY PATCH] docs: initial documentation for xenstore paths"):
> > ...
> > > > --- a/docs/misc/xenstore-paths.markdown
> > > > +++ b/docs/misc/xenstore-paths.markdown
> > > > @@ -0,0 +1,294 @@
> > ...
> > > > +PATH can contain simple regex constructs following the POSIX regexp
> > > > +syntax described in regexp(7). In addition the following additional
> > > > +wild card names are defined and are evaluated before regexp expansion:
> > 
> > Can we use a restricted perl re syntax ?  That avoids weirdness with
> > the rules for \.
> 
> Is "restricted perl re syntax" a well defined thing (reference?) or do
> you just mean perlre(1)--?

I mean pcre, or perlre(1), probably.

> What's the weirdness with \.?

In Perl syntax, a punctuation character preceded by \ is always a
literal, and all metacharacters are unbackslashed punctuation.

In regexp(7) you need to remember which of ( ) | [ ] . & $ need
\-escaping to be literals and which need \-annotating to be
metacharacters.  (And there are various dialects of this too; for
example Emacs regexps require \ in front of a different subset of the
punctuation.)

I don't particularly care about all the fancy (?:...) etc. extensions,
but being able to write the regexp without referring to the manual, or
experimenting, is very good - particularly in a document which will be
tested at most rather indirectly.

> > > > +The process ID of the device model associated with this domain, if it
> > > > +has one.
> > > > +
> > > > +XXX why is this visible to the guest?
> > 
> > I think some of these things were put here just because there wasn't
> > another place for the toolstack to store things.  See also the
> > arbitrary junk stored by scripts in the device backend directories.
> 
> Should we define a proper home for these? e.g. /$toolstack/$domid?

Yes, we should, but the purpose of the doc is to document what we do
now, not what we will do :-).  I just replied to explain your XXX.

> > Should have a cross-reference to the cpu online/offline protocol,
> > which appears to be in xen/include/public/vcpu.h.  It doesn't seem to
> > be fully documented yet.
> 
> vcpu.h has the hypercalls which are the mechanism by which a guest
> brings a cpu up/down but nothing on the xenstore protocol which might
> cause it to do so.
> 
> I don't think a reference currently exists for that protocol. This
> probably belongs in the same (non-existent) protocol doc as
> ~/control/shutdown in so much as it is a toolstack<->guest kernel
> protocol.

Right.  Well, then a cross-reference to vcpu.h is in order along with
remarks along the lines you quote about the lack of a proper protocol
document.

> > This should have a cross-reference to the documentation defining
> > static-max etc.  I thought we had some in tree but I can't seem to
> > find it.  The best I can find is docs/man/xl.cfg.pod.5.
> 
> I think you might be thinking of tools/libxl/libxl_memory.txt.
> 
> Shall we move that doc to docs/misc?

Good idea.

> Perhaps:
> 
>         every effort to ... reach this target
> 
> ? but I'm not sure that is strictly correct, a guest can use less if it
> wants to. So perhaps
> 
>         every effort to ... not use more than this
>         
> ? seems clumsy though.

:-).  These all seem fine to me.

> > > > +#### ~/device/suspend/event-channel = ""|EVTCHN [w]
> > > > +
> > > > +The domain's suspend event channel. The use of a suspend event channel
> > > > +is optional at the domain's discression. If it is not used then this
> > > > +path will be left blank.
> > 
> > May it be ENOENT ?  Does the toolstack create it as "" then ?
> 
> libxl seems to *mkdir* it:
>     libxl__xs_mkdir(gc, t,
>                     libxl__sprintf(gc, "%s/device/suspend/event-channel", dom_path),
>                     rwperm, ARRAY_SIZE(rwperm));
> 
> which I suppose is the same as writing it as "" (unless there is some
> subtle xenstore semantic difference I'm not thinking of)

As docs/misc/xenstore.txt says:

 If a particular path exists, all of its parents do too.  Every
 existing path maps to a possibly empty value, and may also have zero
 or more immediate children.  There is thus no particular distinction
 between directories and leaf nodes.  However, it is conventional not
 to store nonempty values at nodes which also have children.

The difference between MKDIR and WRITE is simply that if there is an
existing node, WRITE overwrites its value and MKDIR leaves it
unchanged.  See the doc.

> > > > +XXX why is this exposed to the guest?
> > 
> > Is there really only one event channel ?  Ie the same evtchn is used
> > to signal to xenstore that the guest has sent a command, and to signal
> > the guest that xenstore has written the response ?
> 
> Yes, event channels are bidirectional so that's quite common.

Oh, I didn't realise they were bidirectional.

> > Anyway surely this is something the guest needs to know.  Why it's in
> > xenstore is a bit of a mystery since you can't use xenstore without it
> > and it's in the start_info.
> 
> I should have written "why is this exposed to the guest via xenstore?"

Right.  OK.

> > Is this the same value as start_info.store_evtchn ?  Cross reference ?
> 
> I'd be semi inclined to ditch/deprecate it unless we can figure out what
> it is for -- as you say there is something of a chicken and egg problem
> with using it.

I think it's fine to deprecate it.

> > I think it's not specified anywhere.  It's ad-hoc.  The guest
> > shouldn't need to see it but exposing it readonly is probably
> > harmless.  Except perhaps for the vnc password ?
> 
> vnc password appears to go into /vm/$uuid/vncpass (looking at libxl code
> only).

Yuk.  We want to abolish /vm/$uuid/ surely.

> AFAIK it does nothing special with the perms, but /vm/$uuid is not guest
> readable (perms are "n0") so I think that works out ok.
> 
> I wonder if that's part of the point of /vm/$uuid.

Perhaps we should make a new directory for this.  We do seem to have
quite a bit of cruft in our system which attempting to write this
document is revealing.

The right answer is probably to mention it in the doc as "likely to
move".

> > > > +### /vm/$UUID/uuid = UUID []
> > > > +
> > > > +Value is the same UUID as the path.
> > > > +
> > > > +### /vm/$UUID/name = STRING []
> > > > +
> > > > +The domains name.
> > 
> > IMO this should be
> >   (a) in /local/domain/$DOMID
> >   (b) also a copy in /byname/$NAME = $DOMID   for fast lookup
> > but not in 4.2.
> > 
> > Guests shouldn't rely on it.  In fact do guests actually need anything
> > from here ?
> 
> I'd say definitely not, but it has existed with xend for many years so
> I'd be surprised if something hadn't crept in somewhere :-(

Yers.

We should at least say that guests shouldn't use it.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 24 11:36:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Sep 2012 11: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 1TG6xw-0004WF-7d; Mon, 24 Sep 2012 11:36: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 1TG6xu-0004W4-WA
	for xen-devel@lists.xen.org; Mon, 24 Sep 2012 11:36:43 +0000
Received: from [85.158.143.35:38864] by server-2.bemta-4.messagelabs.com id
	D6/2E-06610-AC540605; Mon, 24 Sep 2012 11:36:42 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1348486601!19612217!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6348 invoked from network); 24 Sep 2012 11:36:41 -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;
	24 Sep 2012 11:36:41 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 24 Sep 2012 12:36:41 +0100
Message-Id: <506061E6020000780009D4AB@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 24 Sep 2012 12:36:38 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Oliver Chick" <oliver.chick@citrix.com>
References: <1348242767-23732-1-git-send-email-oliver.chick@citrix.com>
In-Reply-To: <1348242767-23732-1-git-send-email-oliver.chick@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: konrad.wilk@oracle.com, linux-kernel@vger.kernel.org,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH v2] Persistent grant maps for xen blk drivers
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 21.09.12 at 17:52, Oliver Chick <oliver.chick@citrix.com> wrote:
> Changes since v1:
> 
>  * Maximum number of persistent grants per device now 64, rather than
>    256, as this is the actual maxmimum request in a (1 page) ring.

As said previously, I don't see why this needs to have a separate
#define at all - it's simply __RING_SIZE(). No adding this would
also imply that - apart from perhaps documenting the new xenstore
nodes - io/blkif.h would need changing at all (which otherwise would
require a hypervisor side patch to be submitted too).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 24 11:36:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Sep 2012 11: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 1TG6xw-0004WF-7d; Mon, 24 Sep 2012 11:36: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 1TG6xu-0004W4-WA
	for xen-devel@lists.xen.org; Mon, 24 Sep 2012 11:36:43 +0000
Received: from [85.158.143.35:38864] by server-2.bemta-4.messagelabs.com id
	D6/2E-06610-AC540605; Mon, 24 Sep 2012 11:36:42 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1348486601!19612217!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6348 invoked from network); 24 Sep 2012 11:36:41 -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;
	24 Sep 2012 11:36:41 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 24 Sep 2012 12:36:41 +0100
Message-Id: <506061E6020000780009D4AB@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 24 Sep 2012 12:36:38 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Oliver Chick" <oliver.chick@citrix.com>
References: <1348242767-23732-1-git-send-email-oliver.chick@citrix.com>
In-Reply-To: <1348242767-23732-1-git-send-email-oliver.chick@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: konrad.wilk@oracle.com, linux-kernel@vger.kernel.org,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH v2] Persistent grant maps for xen blk drivers
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 21.09.12 at 17:52, Oliver Chick <oliver.chick@citrix.com> wrote:
> Changes since v1:
> 
>  * Maximum number of persistent grants per device now 64, rather than
>    256, as this is the actual maxmimum request in a (1 page) ring.

As said previously, I don't see why this needs to have a separate
#define at all - it's simply __RING_SIZE(). No adding this would
also imply that - apart from perhaps documenting the new xenstore
nodes - io/blkif.h would need changing at all (which otherwise would
require a hypervisor side patch to be submitted too).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 24 11:45:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Sep 2012 11:45:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TG75v-0004lG-5H; Mon, 24 Sep 2012 11:44: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 1TG75s-0004lB-SP
	for xen-devel@lists.xen.org; Mon, 24 Sep 2012 11:44:56 +0000
Received: from [85.158.137.99:51121] by server-14.bemta-3.messagelabs.com id
	B0/88-21431-8B740605; Mon, 24 Sep 2012 11:44:56 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-217.messagelabs.com!1348487095!17696115!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTA4NDk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 644 invoked from network); 24 Sep 2012 11:44:55 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Sep 2012 11:44:55 -0000
X-IronPort-AV: E=Sophos;i="4.80,474,1344211200"; d="scan'208";a="14721671"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Sep 2012 11:44: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.279.1;
	Mon, 24 Sep 2012 12:44:55 +0100
Message-ID: <1348487093.3452.62.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Mon, 24 Sep 2012 12:44:53 +0100
In-Reply-To: <506061E6020000780009D4AB@nat28.tlf.novell.com>
References: <1348242767-23732-1-git-send-email-oliver.chick@citrix.com>
	<506061E6020000780009D4AB@nat28.tlf.novell.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "Oliver Chick \(Intern\)" <oliver.chick@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH v2] Persistent grant maps for xen blk drivers
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2012-09-24 at 12:36 +0100, Jan Beulich wrote:
> >>> On 21.09.12 at 17:52, Oliver Chick <oliver.chick@citrix.com> wrote:
> > Changes since v1:
> > 
> >  * Maximum number of persistent grants per device now 64, rather than
> >    256, as this is the actual maxmimum request in a (1 page) ring.
> 
> As said previously, I don't see why this needs to have a separate
> #define at all - it's simply __RING_SIZE(). No adding this would
> also imply that - apart from perhaps documenting the new xenstore
> nodes - io/blkif.h would need changing at all (which otherwise would
> require a hypervisor side patch to be submitted too).

Whether or not this definition is required in blkif.h we certainly want
a patch to the hypervisor tree to document this new protocol extension.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 24 11:45:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Sep 2012 11:45:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TG75v-0004lG-5H; Mon, 24 Sep 2012 11:44: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 1TG75s-0004lB-SP
	for xen-devel@lists.xen.org; Mon, 24 Sep 2012 11:44:56 +0000
Received: from [85.158.137.99:51121] by server-14.bemta-3.messagelabs.com id
	B0/88-21431-8B740605; Mon, 24 Sep 2012 11:44:56 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-217.messagelabs.com!1348487095!17696115!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTA4NDk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 644 invoked from network); 24 Sep 2012 11:44:55 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Sep 2012 11:44:55 -0000
X-IronPort-AV: E=Sophos;i="4.80,474,1344211200"; d="scan'208";a="14721671"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Sep 2012 11:44: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.279.1;
	Mon, 24 Sep 2012 12:44:55 +0100
Message-ID: <1348487093.3452.62.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Mon, 24 Sep 2012 12:44:53 +0100
In-Reply-To: <506061E6020000780009D4AB@nat28.tlf.novell.com>
References: <1348242767-23732-1-git-send-email-oliver.chick@citrix.com>
	<506061E6020000780009D4AB@nat28.tlf.novell.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "Oliver Chick \(Intern\)" <oliver.chick@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH v2] Persistent grant maps for xen blk drivers
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2012-09-24 at 12:36 +0100, Jan Beulich wrote:
> >>> On 21.09.12 at 17:52, Oliver Chick <oliver.chick@citrix.com> wrote:
> > Changes since v1:
> > 
> >  * Maximum number of persistent grants per device now 64, rather than
> >    256, as this is the actual maxmimum request in a (1 page) ring.
> 
> As said previously, I don't see why this needs to have a separate
> #define at all - it's simply __RING_SIZE(). No adding this would
> also imply that - apart from perhaps documenting the new xenstore
> nodes - io/blkif.h would need changing at all (which otherwise would
> require a hypervisor side patch to be submitted too).

Whether or not this definition is required in blkif.h we certainly want
a patch to the hypervisor tree to document this new protocol extension.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 24 11:45:22 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Sep 2012 11: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 1TG765-0004ly-ID; Mon, 24 Sep 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 <Ian.Campbell@citrix.com>) id 1TG764-0004lk-0Q
	for xen-devel@lists.xen.org; Mon, 24 Sep 2012 11:45:08 +0000
Received: from [85.158.143.35:17066] by server-3.bemta-4.messagelabs.com id
	CE/9D-10986-3C740605; Mon, 24 Sep 2012 11:45:07 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1348487105!13496933!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNzcwMDM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32417 invoked from network); 24 Sep 2012 11:45:06 -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;
	24 Sep 2012 11:45:06 -0000
X-IronPort-AV: E=Sophos;i="4.80,474,1344211200"; d="scan'208";a="209110398"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Sep 2012 11:45:04 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1;
	Mon, 24 Sep 2012 07:45: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 1TG760-0007Yh-3k;
	Mon, 24 Sep 2012 12:45:04 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Mon, 24 Sep 2012 12:45:03 +0100
Message-ID: <1348487103-2113-1-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
MIME-Version: 1.0
Cc: keir@xen.org, Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [DOCDAY PATCH V2] docs: document/mark-up SCHEDOP_*
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 biggest subtlety here is there additional argument when op ==
SCHEDOP_shutdown and reason == SHUTDOWN_suspend and its interpretation by
xc_domain_{save,restore}. Add some clarifying comments to libxc as well.

This patch moves some structs around but there is no functional change
other than improved documentation.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
v2: clarify code motion.
---
 tools/libxc/xc_domain_restore.c |   10 ++++-
 tools/libxc/xc_domain_save.c    |    9 ++++-
 xen/include/public/sched.h      |   84 ++++++++++++++++++++++++++-------------
 3 files changed, 72 insertions(+), 31 deletions(-)

diff --git a/tools/libxc/xc_domain_restore.c b/tools/libxc/xc_domain_restore.c
index 3fe2b12..5541e73 100644
--- a/tools/libxc/xc_domain_restore.c
+++ b/tools/libxc/xc_domain_restore.c
@@ -1895,8 +1895,14 @@ int xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
         if ( i == 0 )
         {
             /*
-             * Uncanonicalise the suspend-record frame number and poke
-             * resume record.
+             * Uncanonicalise the start info frame number and poke in
+             * updated values into the start info itself.
+             *
+             * The start info MFN is the 3rd argument to the
+             * HYPERVISOR_sched_op hypercall when op==SCHEDOP_shutdown
+             * and reason==SHUTDOWN_suspend, it is canonicalised in
+             * xc_domain_save and therefore the PFN is found in the
+             * edx register.
              */
             pfn = GET_FIELD(ctxt, user_regs.edx);
             if ( (pfn >= dinfo->p2m_size) ||
diff --git a/tools/libxc/xc_domain_save.c b/tools/libxc/xc_domain_save.c
index c359649..f161472 100644
--- a/tools/libxc/xc_domain_save.c
+++ b/tools/libxc/xc_domain_save.c
@@ -1867,7 +1867,14 @@ int xc_domain_save(xc_interface *xch, int io_fd, uint32_t dom, uint32_t max_iter
         goto out;
     }
 
-    /* Canonicalise the suspend-record frame number. */
+    /*
+     * Canonicalise the start info frame number.
+     *
+     * The start info MFN is the 3rd argument to the
+     * HYPERVISOR_sched_op hypercall when op==SCHEDOP_shutdown and
+     * reason==SHUTDOWN_suspend and is therefore found in the edx
+     * register.
+     */
     mfn = GET_FIELD(&ctxt, user_regs.edx);
     if ( !MFN_IS_IN_PSEUDOPHYS_MAP(mfn) )
     {
diff --git a/xen/include/public/sched.h b/xen/include/public/sched.h
index 7f87420..db5124a 100644
--- a/xen/include/public/sched.h
+++ b/xen/include/public/sched.h
@@ -1,8 +1,8 @@
 /******************************************************************************
  * sched.h
- * 
+ *
  * Scheduler state interactions
- * 
+ *
  * Permission is hereby granted, free of charge, to any person obtaining a copy
  * of this software and associated documentation files (the "Software"), to
  * deal in the Software without restriction, including without limitation the
@@ -30,20 +30,33 @@
 #include "event_channel.h"
 
 /*
+ * `incontents 150 sched Guest Scheduler Operations
+ *
+ * The SCHEDOP interface provides mechanisms for a guest to interact
+ * with the scheduler, including yield, blocking and shutting itself
+ * down.
+ */
+
+/*
  * The prototype for this hypercall is:
- *  long sched_op(int cmd, void *arg)
+ * ` long HYPERVISOR_sched_op(enum sched_op cmd, void *arg, ...)
+ *
  * @cmd == SCHEDOP_??? (scheduler operation).
  * @arg == Operation-specific extra argument(s), as described below.
- * 
+ * ...  == Additional Operation-specific extra arguments, described below.
+ *
  * Versions of Xen prior to 3.0.2 provided only the following legacy version
  * of this hypercall, supporting only the commands yield, block and shutdown:
  *  long sched_op(int cmd, unsigned long arg)
  * @cmd == SCHEDOP_??? (scheduler operation).
  * @arg == 0               (SCHEDOP_yield and SCHEDOP_block)
  *      == SHUTDOWN_* code (SCHEDOP_shutdown)
- * This legacy version is available to new guests as sched_op_compat().
+ *
+ * This legacy version is available to new guests as:
+ * ` long HYPERVISOR_sched_op_compat(enum sched_op cmd, unsigned long arg)
  */
 
+/* ` enum sched_op { // SCHEDOP_* => struct sched_* */
 /*
  * Voluntarily yield the CPU.
  * @arg == NULL.
@@ -61,59 +74,72 @@
 
 /*
  * Halt execution of this domain (all VCPUs) and notify the system controller.
- * @arg == pointer to sched_shutdown structure.
+ * @arg == pointer to sched_shutdown_t structure.
+ *
+ * If the sched_shutdown_t reason is SHUTDOWN_suspend then this
+ * hypercall takes an additional extra argument which should be the
+ * MFN of the guest's start_info_t.
+ *
+ * In addition, which reason is SHUTDOWN_suspend this hypercall
+ * returns 1 if suspend was cancelled or the domain was merely
+ * checkpointed, and 0 if it is resuming in a new domain.
  */
 #define SCHEDOP_shutdown    2
-struct sched_shutdown {
-    unsigned int reason; /* SHUTDOWN_* */
-};
-typedef struct sched_shutdown sched_shutdown_t;
-DEFINE_XEN_GUEST_HANDLE(sched_shutdown_t);
 
 /*
  * Poll a set of event-channel ports. Return when one or more are pending. An
  * optional timeout may be specified.
- * @arg == pointer to sched_poll structure.
+ * @arg == pointer to sched_poll_t structure.
  */
 #define SCHEDOP_poll        3
-struct sched_poll {
-    XEN_GUEST_HANDLE(evtchn_port_t) ports;
-    unsigned int nr_ports;
-    uint64_t timeout;
-};
-typedef struct sched_poll sched_poll_t;
-DEFINE_XEN_GUEST_HANDLE(sched_poll_t);
 
 /*
  * Declare a shutdown for another domain. The main use of this function is
  * in interpreting shutdown requests and reasons for fully-virtualized
  * domains.  A para-virtualized domain may use SCHEDOP_shutdown directly.
- * @arg == pointer to sched_remote_shutdown structure.
+ * @arg == pointer to sched_remote_shutdown_t structure.
  */
 #define SCHEDOP_remote_shutdown        4
-struct sched_remote_shutdown {
-    domid_t domain_id;         /* Remote domain ID */
-    unsigned int reason;       /* SHUTDOWN_xxx reason */
-};
-typedef struct sched_remote_shutdown sched_remote_shutdown_t;
-DEFINE_XEN_GUEST_HANDLE(sched_remote_shutdown_t);
 
 /*
  * Latch a shutdown code, so that when the domain later shuts down it
  * reports this code to the control tools.
- * @arg == as for SCHEDOP_shutdown.
+ * @arg == sched_shutdown_t, as for SCHEDOP_shutdown.
  */
 #define SCHEDOP_shutdown_code 5
 
 /*
  * Setup, poke and destroy a domain watchdog timer.
- * @arg == pointer to sched_watchdog structure.
+ * @arg == pointer to sched_watchdog_t structure.
  * With id == 0, setup a domain watchdog timer to cause domain shutdown
  *               after timeout, returns watchdog id.
  * With id != 0 and timeout == 0, destroy domain watchdog timer.
  * With id != 0 and timeout != 0, poke watchdog timer and set new timeout.
  */
 #define SCHEDOP_watchdog    6
+/* ` } */
+
+struct sched_shutdown {
+    unsigned int reason; /* SHUTDOWN_* => enum sched_shutdown_reason */
+};
+typedef struct sched_shutdown sched_shutdown_t;
+DEFINE_XEN_GUEST_HANDLE(sched_shutdown_t);
+
+struct sched_poll {
+    XEN_GUEST_HANDLE(evtchn_port_t) ports;
+    unsigned int nr_ports;
+    uint64_t timeout;
+};
+typedef struct sched_poll sched_poll_t;
+DEFINE_XEN_GUEST_HANDLE(sched_poll_t);
+
+struct sched_remote_shutdown {
+    domid_t domain_id;         /* Remote domain ID */
+    unsigned int reason;       /* SHUTDOWN_* => enum sched_shutdown_reason */
+};
+typedef struct sched_remote_shutdown sched_remote_shutdown_t;
+DEFINE_XEN_GUEST_HANDLE(sched_remote_shutdown_t);
+
 struct sched_watchdog {
     uint32_t id;                /* watchdog ID */
     uint32_t timeout;           /* timeout */
@@ -126,11 +152,13 @@ DEFINE_XEN_GUEST_HANDLE(sched_watchdog_t);
  * software to determine the appropriate action. For the most part, Xen does
  * not care about the shutdown code.
  */
+/* ` enum sched_shutdown_reason { */
 #define SHUTDOWN_poweroff   0  /* Domain exited normally. Clean up and kill. */
 #define SHUTDOWN_reboot     1  /* Clean up, kill, and then restart.          */
 #define SHUTDOWN_suspend    2  /* Clean up, save suspend info, kill.         */
 #define SHUTDOWN_crash      3  /* Tell controller we've crashed.             */
 #define SHUTDOWN_watchdog   4  /* Restart because watchdog time expired.     */
+/* ` } */
 
 #endif /* __XEN_PUBLIC_SCHED_H__ */
 
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 24 11:45:22 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Sep 2012 11: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 1TG765-0004ly-ID; Mon, 24 Sep 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 <Ian.Campbell@citrix.com>) id 1TG764-0004lk-0Q
	for xen-devel@lists.xen.org; Mon, 24 Sep 2012 11:45:08 +0000
Received: from [85.158.143.35:17066] by server-3.bemta-4.messagelabs.com id
	CE/9D-10986-3C740605; Mon, 24 Sep 2012 11:45:07 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1348487105!13496933!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNzcwMDM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32417 invoked from network); 24 Sep 2012 11:45:06 -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;
	24 Sep 2012 11:45:06 -0000
X-IronPort-AV: E=Sophos;i="4.80,474,1344211200"; d="scan'208";a="209110398"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Sep 2012 11:45:04 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1;
	Mon, 24 Sep 2012 07:45: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 1TG760-0007Yh-3k;
	Mon, 24 Sep 2012 12:45:04 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Mon, 24 Sep 2012 12:45:03 +0100
Message-ID: <1348487103-2113-1-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
MIME-Version: 1.0
Cc: keir@xen.org, Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [DOCDAY PATCH V2] docs: document/mark-up SCHEDOP_*
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 biggest subtlety here is there additional argument when op ==
SCHEDOP_shutdown and reason == SHUTDOWN_suspend and its interpretation by
xc_domain_{save,restore}. Add some clarifying comments to libxc as well.

This patch moves some structs around but there is no functional change
other than improved documentation.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
v2: clarify code motion.
---
 tools/libxc/xc_domain_restore.c |   10 ++++-
 tools/libxc/xc_domain_save.c    |    9 ++++-
 xen/include/public/sched.h      |   84 ++++++++++++++++++++++++++-------------
 3 files changed, 72 insertions(+), 31 deletions(-)

diff --git a/tools/libxc/xc_domain_restore.c b/tools/libxc/xc_domain_restore.c
index 3fe2b12..5541e73 100644
--- a/tools/libxc/xc_domain_restore.c
+++ b/tools/libxc/xc_domain_restore.c
@@ -1895,8 +1895,14 @@ int xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
         if ( i == 0 )
         {
             /*
-             * Uncanonicalise the suspend-record frame number and poke
-             * resume record.
+             * Uncanonicalise the start info frame number and poke in
+             * updated values into the start info itself.
+             *
+             * The start info MFN is the 3rd argument to the
+             * HYPERVISOR_sched_op hypercall when op==SCHEDOP_shutdown
+             * and reason==SHUTDOWN_suspend, it is canonicalised in
+             * xc_domain_save and therefore the PFN is found in the
+             * edx register.
              */
             pfn = GET_FIELD(ctxt, user_regs.edx);
             if ( (pfn >= dinfo->p2m_size) ||
diff --git a/tools/libxc/xc_domain_save.c b/tools/libxc/xc_domain_save.c
index c359649..f161472 100644
--- a/tools/libxc/xc_domain_save.c
+++ b/tools/libxc/xc_domain_save.c
@@ -1867,7 +1867,14 @@ int xc_domain_save(xc_interface *xch, int io_fd, uint32_t dom, uint32_t max_iter
         goto out;
     }
 
-    /* Canonicalise the suspend-record frame number. */
+    /*
+     * Canonicalise the start info frame number.
+     *
+     * The start info MFN is the 3rd argument to the
+     * HYPERVISOR_sched_op hypercall when op==SCHEDOP_shutdown and
+     * reason==SHUTDOWN_suspend and is therefore found in the edx
+     * register.
+     */
     mfn = GET_FIELD(&ctxt, user_regs.edx);
     if ( !MFN_IS_IN_PSEUDOPHYS_MAP(mfn) )
     {
diff --git a/xen/include/public/sched.h b/xen/include/public/sched.h
index 7f87420..db5124a 100644
--- a/xen/include/public/sched.h
+++ b/xen/include/public/sched.h
@@ -1,8 +1,8 @@
 /******************************************************************************
  * sched.h
- * 
+ *
  * Scheduler state interactions
- * 
+ *
  * Permission is hereby granted, free of charge, to any person obtaining a copy
  * of this software and associated documentation files (the "Software"), to
  * deal in the Software without restriction, including without limitation the
@@ -30,20 +30,33 @@
 #include "event_channel.h"
 
 /*
+ * `incontents 150 sched Guest Scheduler Operations
+ *
+ * The SCHEDOP interface provides mechanisms for a guest to interact
+ * with the scheduler, including yield, blocking and shutting itself
+ * down.
+ */
+
+/*
  * The prototype for this hypercall is:
- *  long sched_op(int cmd, void *arg)
+ * ` long HYPERVISOR_sched_op(enum sched_op cmd, void *arg, ...)
+ *
  * @cmd == SCHEDOP_??? (scheduler operation).
  * @arg == Operation-specific extra argument(s), as described below.
- * 
+ * ...  == Additional Operation-specific extra arguments, described below.
+ *
  * Versions of Xen prior to 3.0.2 provided only the following legacy version
  * of this hypercall, supporting only the commands yield, block and shutdown:
  *  long sched_op(int cmd, unsigned long arg)
  * @cmd == SCHEDOP_??? (scheduler operation).
  * @arg == 0               (SCHEDOP_yield and SCHEDOP_block)
  *      == SHUTDOWN_* code (SCHEDOP_shutdown)
- * This legacy version is available to new guests as sched_op_compat().
+ *
+ * This legacy version is available to new guests as:
+ * ` long HYPERVISOR_sched_op_compat(enum sched_op cmd, unsigned long arg)
  */
 
+/* ` enum sched_op { // SCHEDOP_* => struct sched_* */
 /*
  * Voluntarily yield the CPU.
  * @arg == NULL.
@@ -61,59 +74,72 @@
 
 /*
  * Halt execution of this domain (all VCPUs) and notify the system controller.
- * @arg == pointer to sched_shutdown structure.
+ * @arg == pointer to sched_shutdown_t structure.
+ *
+ * If the sched_shutdown_t reason is SHUTDOWN_suspend then this
+ * hypercall takes an additional extra argument which should be the
+ * MFN of the guest's start_info_t.
+ *
+ * In addition, which reason is SHUTDOWN_suspend this hypercall
+ * returns 1 if suspend was cancelled or the domain was merely
+ * checkpointed, and 0 if it is resuming in a new domain.
  */
 #define SCHEDOP_shutdown    2
-struct sched_shutdown {
-    unsigned int reason; /* SHUTDOWN_* */
-};
-typedef struct sched_shutdown sched_shutdown_t;
-DEFINE_XEN_GUEST_HANDLE(sched_shutdown_t);
 
 /*
  * Poll a set of event-channel ports. Return when one or more are pending. An
  * optional timeout may be specified.
- * @arg == pointer to sched_poll structure.
+ * @arg == pointer to sched_poll_t structure.
  */
 #define SCHEDOP_poll        3
-struct sched_poll {
-    XEN_GUEST_HANDLE(evtchn_port_t) ports;
-    unsigned int nr_ports;
-    uint64_t timeout;
-};
-typedef struct sched_poll sched_poll_t;
-DEFINE_XEN_GUEST_HANDLE(sched_poll_t);
 
 /*
  * Declare a shutdown for another domain. The main use of this function is
  * in interpreting shutdown requests and reasons for fully-virtualized
  * domains.  A para-virtualized domain may use SCHEDOP_shutdown directly.
- * @arg == pointer to sched_remote_shutdown structure.
+ * @arg == pointer to sched_remote_shutdown_t structure.
  */
 #define SCHEDOP_remote_shutdown        4
-struct sched_remote_shutdown {
-    domid_t domain_id;         /* Remote domain ID */
-    unsigned int reason;       /* SHUTDOWN_xxx reason */
-};
-typedef struct sched_remote_shutdown sched_remote_shutdown_t;
-DEFINE_XEN_GUEST_HANDLE(sched_remote_shutdown_t);
 
 /*
  * Latch a shutdown code, so that when the domain later shuts down it
  * reports this code to the control tools.
- * @arg == as for SCHEDOP_shutdown.
+ * @arg == sched_shutdown_t, as for SCHEDOP_shutdown.
  */
 #define SCHEDOP_shutdown_code 5
 
 /*
  * Setup, poke and destroy a domain watchdog timer.
- * @arg == pointer to sched_watchdog structure.
+ * @arg == pointer to sched_watchdog_t structure.
  * With id == 0, setup a domain watchdog timer to cause domain shutdown
  *               after timeout, returns watchdog id.
  * With id != 0 and timeout == 0, destroy domain watchdog timer.
  * With id != 0 and timeout != 0, poke watchdog timer and set new timeout.
  */
 #define SCHEDOP_watchdog    6
+/* ` } */
+
+struct sched_shutdown {
+    unsigned int reason; /* SHUTDOWN_* => enum sched_shutdown_reason */
+};
+typedef struct sched_shutdown sched_shutdown_t;
+DEFINE_XEN_GUEST_HANDLE(sched_shutdown_t);
+
+struct sched_poll {
+    XEN_GUEST_HANDLE(evtchn_port_t) ports;
+    unsigned int nr_ports;
+    uint64_t timeout;
+};
+typedef struct sched_poll sched_poll_t;
+DEFINE_XEN_GUEST_HANDLE(sched_poll_t);
+
+struct sched_remote_shutdown {
+    domid_t domain_id;         /* Remote domain ID */
+    unsigned int reason;       /* SHUTDOWN_* => enum sched_shutdown_reason */
+};
+typedef struct sched_remote_shutdown sched_remote_shutdown_t;
+DEFINE_XEN_GUEST_HANDLE(sched_remote_shutdown_t);
+
 struct sched_watchdog {
     uint32_t id;                /* watchdog ID */
     uint32_t timeout;           /* timeout */
@@ -126,11 +152,13 @@ DEFINE_XEN_GUEST_HANDLE(sched_watchdog_t);
  * software to determine the appropriate action. For the most part, Xen does
  * not care about the shutdown code.
  */
+/* ` enum sched_shutdown_reason { */
 #define SHUTDOWN_poweroff   0  /* Domain exited normally. Clean up and kill. */
 #define SHUTDOWN_reboot     1  /* Clean up, kill, and then restart.          */
 #define SHUTDOWN_suspend    2  /* Clean up, save suspend info, kill.         */
 #define SHUTDOWN_crash      3  /* Tell controller we've crashed.             */
 #define SHUTDOWN_watchdog   4  /* Restart because watchdog time expired.     */
+/* ` } */
 
 #endif /* __XEN_PUBLIC_SCHED_H__ */
 
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 24 11:46:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Sep 2012 11: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 1TG76o-0004sS-5F; Mon, 24 Sep 2012 11:45: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 1TG76m-0004sH-Ub
	for xen-devel@lists.xen.org; Mon, 24 Sep 2012 11:45:53 +0000
Received: from [85.158.143.35:19524] by server-1.bemta-4.messagelabs.com id
	0E/F5-05684-0F740605; Mon, 24 Sep 2012 11:45:52 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1348487150!16112879!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31931 invoked from network); 24 Sep 2012 11:45:50 -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;
	24 Sep 2012 11:45:50 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 24 Sep 2012 12:45:50 +0100
Message-Id: <5060640B020000780009D4D2@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 24 Sep 2012 12:45:47 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ben Guthro" <ben@guthro.net>
References: <CAOvdn6XKPOMNn6AjuYvZvPXRRJffN3po5GXe1Yh1-m0hisMK_w@mail.gmail.com>
	<CC8273A0.4C9DD%keir@xen.org>
	<50605E9A020000780009D486@nat28.tlf.novell.com>
	<CAOvdn6XmB6rj3_QVU+59V8p24Y5G47AWxVEM=id02JWXkuhibQ@mail.gmail.com>
In-Reply-To: <CAOvdn6XmB6rj3_QVU+59V8p24Y5G47AWxVEM=id02JWXkuhibQ@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>, Keir Fraser <keir@xen.org>,
	john.baboval@citrix.com, Thomas Goetz <thomas.goetz@citrix.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen4.2 S3 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 24.09.12 at 13:25, Ben Guthro <ben@guthro.net> wrote:
> It is an older system (Core2) - so it may be using the default mechanism,
> but I'd have to go dig up some processor docs to be sure.

This is not just a matter of what the CPU supports, but also what
info gets passed down from Dom0 - if e.g. your kernel doesn't
have Konrad's P-/C-state patches, then there's no way for Xen to
use any of the advanced methods.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 24 11:46:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Sep 2012 11: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 1TG76o-0004sS-5F; Mon, 24 Sep 2012 11:45: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 1TG76m-0004sH-Ub
	for xen-devel@lists.xen.org; Mon, 24 Sep 2012 11:45:53 +0000
Received: from [85.158.143.35:19524] by server-1.bemta-4.messagelabs.com id
	0E/F5-05684-0F740605; Mon, 24 Sep 2012 11:45:52 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1348487150!16112879!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31931 invoked from network); 24 Sep 2012 11:45:50 -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;
	24 Sep 2012 11:45:50 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 24 Sep 2012 12:45:50 +0100
Message-Id: <5060640B020000780009D4D2@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 24 Sep 2012 12:45:47 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ben Guthro" <ben@guthro.net>
References: <CAOvdn6XKPOMNn6AjuYvZvPXRRJffN3po5GXe1Yh1-m0hisMK_w@mail.gmail.com>
	<CC8273A0.4C9DD%keir@xen.org>
	<50605E9A020000780009D486@nat28.tlf.novell.com>
	<CAOvdn6XmB6rj3_QVU+59V8p24Y5G47AWxVEM=id02JWXkuhibQ@mail.gmail.com>
In-Reply-To: <CAOvdn6XmB6rj3_QVU+59V8p24Y5G47AWxVEM=id02JWXkuhibQ@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>, Keir Fraser <keir@xen.org>,
	john.baboval@citrix.com, Thomas Goetz <thomas.goetz@citrix.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen4.2 S3 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 24.09.12 at 13:25, Ben Guthro <ben@guthro.net> wrote:
> It is an older system (Core2) - so it may be using the default mechanism,
> but I'd have to go dig up some processor docs to be sure.

This is not just a matter of what the CPU supports, but also what
info gets passed down from Dom0 - if e.g. your kernel doesn't
have Konrad's P-/C-state patches, then there's no way for Xen to
use any of the advanced methods.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 24 11:54:25 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Sep 2012 11: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 1TG7Ep-0005Ct-33; Mon, 24 Sep 2012 11:54:11 +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 1TG7En-0005Cl-Ew
	for xen-devel@lists.xen.org; Mon, 24 Sep 2012 11:54:09 +0000
Received: from [85.158.143.35:60900] by server-3.bemta-4.messagelabs.com id
	E2/2C-10986-0E940605; Mon, 24 Sep 2012 11:54:08 +0000
X-Env-Sender: ben.guthro@gmail.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1348487646!13764616!1
X-Originating-IP: [209.85.223.173]
X-SpamReason: No, hits=0.9 required=7.0 tests=HTML_40_50,HTML_MESSAGE,
	RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2628 invoked from network); 24 Sep 2012 11:54:08 -0000
Received: from mail-ie0-f173.google.com (HELO mail-ie0-f173.google.com)
	(209.85.223.173)
	by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Sep 2012 11:54:08 -0000
Received: by iea17 with SMTP id 17so7549988iea.32
	for <xen-devel@lists.xen.org>; Mon, 24 Sep 2012 04:54:06 -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=OJ+Y7wWQhcPNI74sEoCpsQjN661g5+xrRLbd3FKO3Jk=;
	b=zw3KOaLWpYT85G8ynJ3tTSTyaBisn0Ud0pSMbuk3usBqUcymFVlIopnGBW9FJU5wrY
	mb8RiAmufBEF+n7PkKvNCZZNSAbkf+a+XR5BhHoXkroK0j2UXqEvmHrxpGY0qZWod3A/
	U5gwCoKEsRyieIcCSSyUZLuvOxMVc0c+KR0chN98KGBrKFwp96IbgEsn0lGz8qOAmkvt
	UuL5hfHnl871bcDAHdIFAlJx3oK988DkApKHIuPNjO/seEhHlzQo1P3DGzMjGV0dKOJO
	uB14sR7UaDjl3pa+Fu+6VToLKbhKrJBKpwcYy7k9zVpkKO4UaOvzw6EDlZlzS6x6ek6y
	aXLw==
MIME-Version: 1.0
Received: by 10.50.158.226 with SMTP id wx2mr4904892igb.70.1348487646205; Mon,
	24 Sep 2012 04:54:06 -0700 (PDT)
Received: by 10.64.55.132 with HTTP; Mon, 24 Sep 2012 04:54:05 -0700 (PDT)
In-Reply-To: <5060640B020000780009D4D2@nat28.tlf.novell.com>
References: <CAOvdn6XKPOMNn6AjuYvZvPXRRJffN3po5GXe1Yh1-m0hisMK_w@mail.gmail.com>
	<CC8273A0.4C9DD%keir@xen.org>
	<50605E9A020000780009D486@nat28.tlf.novell.com>
	<CAOvdn6XmB6rj3_QVU+59V8p24Y5G47AWxVEM=id02JWXkuhibQ@mail.gmail.com>
	<5060640B020000780009D4D2@nat28.tlf.novell.com>
Date: Mon, 24 Sep 2012 07:54:05 -0400
X-Google-Sender-Auth: Ft6HY0J6UCW66Skeqf_O2uzYgIc
Message-ID: <CAOvdn6XLy8zR2rb2MEyi2aT9LQiFvFLY_H02p181mTsVLVTZkw@mail.gmail.com>
From: Ben Guthro <ben@guthro.net>
To: Jan Beulich <JBeulich@suse.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: Keir Fraser <keir@xen.org>, john.baboval@citrix.com,
	Thomas Goetz <thomas.goetz@citrix.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen4.2 S3 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: multipart/mixed; boundary="===============1606395479224179970=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============1606395479224179970==
Content-Type: multipart/alternative; boundary=14dae9340c8922d62b04ca713f50

--14dae9340c8922d62b04ca713f50
Content-Type: text/plain; charset=ISO-8859-1

I see - Konrad - do you have a changeset I can look for with the features
Jan describes?


On Mon, Sep 24, 2012 at 7:45 AM, Jan Beulich <JBeulich@suse.com> wrote:

> >>> On 24.09.12 at 13:25, Ben Guthro <ben@guthro.net> wrote:
> > It is an older system (Core2) - so it may be using the default mechanism,
> > but I'd have to go dig up some processor docs to be sure.
>
> This is not just a matter of what the CPU supports, but also what
> info gets passed down from Dom0 - if e.g. your kernel doesn't
> have Konrad's P-/C-state patches, then there's no way for Xen to
> use any of the advanced methods.
>
> Jan
>
>

--14dae9340c8922d62b04ca713f50
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div>I see - Konrad - do you have a changeset I can look for with the featu=
res Jan describes?</div><div><br></div><div><br><div class=3D"gmail_quote">=
On Mon, Sep 24, 2012 at 7:45 AM, 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>
<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 24.09.12 a=
t 13:25, Ben Guthro &lt;<a href=3D"mailto:ben@guthro.net">ben@guthro.net</a=
>&gt; wrote:<br>

&gt; It is an older system (Core2) - so it may be using the default mechani=
sm,<br>
&gt; but I&#39;d have to go dig up some processor docs to be sure.<br>
<br>
</div>This is not just a matter of what the CPU supports, but also what<br>
info gets passed down from Dom0 - if e.g. your kernel doesn&#39;t<br>
have Konrad&#39;s P-/C-state patches, then there&#39;s no way for Xen to<br=
>
use any of the advanced methods.<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
Jan<br>
<br>
</font></span></blockquote></div><br></div>

--14dae9340c8922d62b04ca713f50--


--===============1606395479224179970==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============1606395479224179970==--


From xen-devel-bounces@lists.xen.org Mon Sep 24 11:54:25 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Sep 2012 11: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 1TG7Ep-0005Ct-33; Mon, 24 Sep 2012 11:54:11 +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 1TG7En-0005Cl-Ew
	for xen-devel@lists.xen.org; Mon, 24 Sep 2012 11:54:09 +0000
Received: from [85.158.143.35:60900] by server-3.bemta-4.messagelabs.com id
	E2/2C-10986-0E940605; Mon, 24 Sep 2012 11:54:08 +0000
X-Env-Sender: ben.guthro@gmail.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1348487646!13764616!1
X-Originating-IP: [209.85.223.173]
X-SpamReason: No, hits=0.9 required=7.0 tests=HTML_40_50,HTML_MESSAGE,
	RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2628 invoked from network); 24 Sep 2012 11:54:08 -0000
Received: from mail-ie0-f173.google.com (HELO mail-ie0-f173.google.com)
	(209.85.223.173)
	by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Sep 2012 11:54:08 -0000
Received: by iea17 with SMTP id 17so7549988iea.32
	for <xen-devel@lists.xen.org>; Mon, 24 Sep 2012 04:54:06 -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=OJ+Y7wWQhcPNI74sEoCpsQjN661g5+xrRLbd3FKO3Jk=;
	b=zw3KOaLWpYT85G8ynJ3tTSTyaBisn0Ud0pSMbuk3usBqUcymFVlIopnGBW9FJU5wrY
	mb8RiAmufBEF+n7PkKvNCZZNSAbkf+a+XR5BhHoXkroK0j2UXqEvmHrxpGY0qZWod3A/
	U5gwCoKEsRyieIcCSSyUZLuvOxMVc0c+KR0chN98KGBrKFwp96IbgEsn0lGz8qOAmkvt
	UuL5hfHnl871bcDAHdIFAlJx3oK988DkApKHIuPNjO/seEhHlzQo1P3DGzMjGV0dKOJO
	uB14sR7UaDjl3pa+Fu+6VToLKbhKrJBKpwcYy7k9zVpkKO4UaOvzw6EDlZlzS6x6ek6y
	aXLw==
MIME-Version: 1.0
Received: by 10.50.158.226 with SMTP id wx2mr4904892igb.70.1348487646205; Mon,
	24 Sep 2012 04:54:06 -0700 (PDT)
Received: by 10.64.55.132 with HTTP; Mon, 24 Sep 2012 04:54:05 -0700 (PDT)
In-Reply-To: <5060640B020000780009D4D2@nat28.tlf.novell.com>
References: <CAOvdn6XKPOMNn6AjuYvZvPXRRJffN3po5GXe1Yh1-m0hisMK_w@mail.gmail.com>
	<CC8273A0.4C9DD%keir@xen.org>
	<50605E9A020000780009D486@nat28.tlf.novell.com>
	<CAOvdn6XmB6rj3_QVU+59V8p24Y5G47AWxVEM=id02JWXkuhibQ@mail.gmail.com>
	<5060640B020000780009D4D2@nat28.tlf.novell.com>
Date: Mon, 24 Sep 2012 07:54:05 -0400
X-Google-Sender-Auth: Ft6HY0J6UCW66Skeqf_O2uzYgIc
Message-ID: <CAOvdn6XLy8zR2rb2MEyi2aT9LQiFvFLY_H02p181mTsVLVTZkw@mail.gmail.com>
From: Ben Guthro <ben@guthro.net>
To: Jan Beulich <JBeulich@suse.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: Keir Fraser <keir@xen.org>, john.baboval@citrix.com,
	Thomas Goetz <thomas.goetz@citrix.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen4.2 S3 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: multipart/mixed; boundary="===============1606395479224179970=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============1606395479224179970==
Content-Type: multipart/alternative; boundary=14dae9340c8922d62b04ca713f50

--14dae9340c8922d62b04ca713f50
Content-Type: text/plain; charset=ISO-8859-1

I see - Konrad - do you have a changeset I can look for with the features
Jan describes?


On Mon, Sep 24, 2012 at 7:45 AM, Jan Beulich <JBeulich@suse.com> wrote:

> >>> On 24.09.12 at 13:25, Ben Guthro <ben@guthro.net> wrote:
> > It is an older system (Core2) - so it may be using the default mechanism,
> > but I'd have to go dig up some processor docs to be sure.
>
> This is not just a matter of what the CPU supports, but also what
> info gets passed down from Dom0 - if e.g. your kernel doesn't
> have Konrad's P-/C-state patches, then there's no way for Xen to
> use any of the advanced methods.
>
> Jan
>
>

--14dae9340c8922d62b04ca713f50
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div>I see - Konrad - do you have a changeset I can look for with the featu=
res Jan describes?</div><div><br></div><div><br><div class=3D"gmail_quote">=
On Mon, Sep 24, 2012 at 7:45 AM, 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>
<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 24.09.12 a=
t 13:25, Ben Guthro &lt;<a href=3D"mailto:ben@guthro.net">ben@guthro.net</a=
>&gt; wrote:<br>

&gt; It is an older system (Core2) - so it may be using the default mechani=
sm,<br>
&gt; but I&#39;d have to go dig up some processor docs to be sure.<br>
<br>
</div>This is not just a matter of what the CPU supports, but also what<br>
info gets passed down from Dom0 - if e.g. your kernel doesn&#39;t<br>
have Konrad&#39;s P-/C-state patches, then there&#39;s no way for Xen to<br=
>
use any of the advanced methods.<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
Jan<br>
<br>
</font></span></blockquote></div><br></div>

--14dae9340c8922d62b04ca713f50--


--===============1606395479224179970==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============1606395479224179970==--


From xen-devel-bounces@lists.xen.org Mon Sep 24 11:56:45 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Sep 2012 11: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 1TG7H5-0005J4-Kp; Mon, 24 Sep 2012 11:56:31 +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 1TG7H4-0005Ix-2r
	for Xen-devel@lists.xensource.com; Mon, 24 Sep 2012 11:56:30 +0000
Received: from [85.158.139.83:10460] by server-10.bemta-5.messagelabs.com id
	A6/A4-16911-D6A40605; Mon, 24 Sep 2012 11:56:29 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1348487788!24515767!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTA4NDk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3214 invoked from network); 24 Sep 2012 11:56:28 -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;
	24 Sep 2012 11:56:28 -0000
X-IronPort-AV: E=Sophos;i="4.80,474,1344211200"; d="scan'208";a="14721953"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Sep 2012 11: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.279.1; Mon, 24 Sep 2012 12:56:27 +0100
Date: Mon, 24 Sep 2012 12:55:31 +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: <20120921121556.1a0ea8af@mantra.us.oracle.com>
Message-ID: <alpine.DEB.2.02.1209241228460.29232@kaball.uk.xensource.com>
References: <20120921121556.1a0ea8af@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>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH v1 2/8]: PVH mmu 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

There are few code style issues on this patch, I suggest you run it
through scripts/checkpatch.pl, it should be able to catch all these
errors.

On Fri, 21 Sep 2012, Mukesh Rathor wrote:
> ---
>  arch/x86/xen/mmu.c    |  180 +++++++++++++++++++++++++++++++++++++++++++++++--
>  arch/x86/xen/mmu.h    |    2 +
>  include/xen/xen-ops.h |   12 +++-
>  3 files changed, 188 insertions(+), 6 deletions(-)
> 
> diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c
> index b65a761..9b5a5ef 100644
> --- a/arch/x86/xen/mmu.c
> +++ b/arch/x86/xen/mmu.c
> @@ -73,6 +73,7 @@
>  #include <xen/interface/version.h>
>  #include <xen/interface/memory.h>
>  #include <xen/hvc-console.h>
> +#include <xen/balloon.h>
>  
>  #include "multicalls.h"
>  #include "mmu.h"
> @@ -330,6 +331,26 @@ static void xen_set_pte(pte_t *ptep, pte_t pteval)
>  	__xen_set_pte(ptep, pteval);
>  }
>  
> +void xen_set_clr_mmio_pvh_pte(unsigned long pfn, unsigned long mfn, 
> +			      int nr_mfns, int add_mapping)
> +{
> +	struct physdev_map_iomem iomem;
> +
> +	iomem.first_gfn = pfn;
> +	iomem.first_mfn = mfn;
> +	iomem.nr_mfns = nr_mfns;
> +	iomem.add_mapping = add_mapping;
> +
> +	if (HYPERVISOR_physdev_op(PHYSDEVOP_pvh_map_iomem, &iomem))
> +		BUG();
> +}
> +
> +static void xen_dom0pvh_set_pte_at(struct mm_struct *mm, unsigned long addr,
> +		    		   pte_t *ptep, pte_t pteval)
> +{
> +	native_set_pte(ptep, pteval);
> +}

can't you just set set_pte_at to native_set_pte?


>  static void xen_set_pte_at(struct mm_struct *mm, unsigned long addr,
>  		    pte_t *ptep, pte_t pteval)
>  {
> @@ -1197,6 +1218,10 @@ static void xen_post_allocator_init(void);
>  static void __init xen_pagetable_setup_done(pgd_t *base)
>  {
>  	xen_setup_shared_info();
> +
> +	if (xen_feature(XENFEAT_auto_translated_physmap))
> +		return;
> +
>  	xen_post_allocator_init();
>  }

Can we move the if..return at the beginning of xen_post_allocator_init?
It would make it easier to understand what it is for.
Or maybe we could have xen_setup_shared_info take a pgd_t *base
parameter so that you can set pagetable_setup_done to
xen_setup_shared_info directly on pvh.


> @@ -1455,6 +1480,10 @@ static void __init xen_set_pte_init(pte_t *ptep, pte_t pte)
>  static void pin_pagetable_pfn(unsigned cmd, unsigned long pfn)
>  {
>  	struct mmuext_op op;
> +
> +	if (xen_feature(XENFEAT_writable_page_tables))
> +		return;
> +
>  	op.cmd = cmd;
>  	op.arg1.mfn = pfn_to_mfn(pfn);
>  	if (HYPERVISOR_mmuext_op(&op, 1, NULL, DOMID_SELF))

given the very limited set of mmu pvops that we initialize on pvh, I
cannot find who would actually call pin_pagetable_pfn on pvh.


> @@ -1652,6 +1681,10 @@ static void set_page_prot(void *addr, pgprot_t prot)
>  	unsigned long pfn = __pa(addr) >> PAGE_SHIFT;
>  	pte_t pte = pfn_pte(pfn, prot);
>  
> +	/* recall for PVH, page tables are native. */
> +	if (xen_feature(XENFEAT_auto_translated_physmap))
> +		return;
> +
>  	if (HYPERVISOR_update_va_mapping((unsigned long)addr, pte, 0))
>  		BUG();
>  }
> @@ -1729,6 +1762,9 @@ static void convert_pfn_mfn(void *v)
>  	pte_t *pte = v;
>  	int i;
>  
> +	if (xen_feature(XENFEAT_auto_translated_physmap))
> +		return;
> +
>  	/* All levels are converted the same way, so just treat them
>  	   as ptes. */
>  	for (i = 0; i < PTRS_PER_PTE; i++)
> @@ -1745,6 +1781,7 @@ static void convert_pfn_mfn(void *v)
>   * but that's enough to get __va working.  We need to fill in the rest
>   * of the physical mapping once some sort of allocator has been set
>   * up.
> + * NOTE: for PVH, the page tables are native.
>   */
>  pgd_t * __init xen_setup_kernel_pagetable(pgd_t *pgd,
>  					 unsigned long max_pfn)
> @@ -1802,9 +1839,13 @@ pgd_t * __init xen_setup_kernel_pagetable(pgd_t *pgd,
>  	 * structure to attach it to, so make sure we just set kernel
>  	 * pgd.
>  	 */
> -	xen_mc_batch();
> -	__xen_write_cr3(true, __pa(pgd));
> -	xen_mc_issue(PARAVIRT_LAZY_CPU);
> +	if (xen_feature(XENFEAT_writable_page_tables)) {
> +		native_write_cr3(__pa(pgd));
> +	} else {
> +		xen_mc_batch();
> +		__xen_write_cr3(true, __pa(pgd));
> +		xen_mc_issue(PARAVIRT_LAZY_CPU);
> +	}
>  
>  	memblock_reserve(__pa(xen_start_info->pt_base),
>  			 xen_start_info->nr_pt_frames * PAGE_SIZE);
> @@ -2067,9 +2108,21 @@ static const struct pv_mmu_ops xen_mmu_ops __initconst = {
>  
>  void __init xen_init_mmu_ops(void)
>  {
> +	x86_init.paging.pagetable_setup_done = xen_pagetable_setup_done;
> +
> +	if (xen_feature(XENFEAT_auto_translated_physmap)) {
> +		pv_mmu_ops.flush_tlb_others = xen_flush_tlb_others;
> +
> +		/* set_pte* for PCI devices to map iomem. */
> +		if (xen_initial_domain()) {
> +			pv_mmu_ops.set_pte = native_set_pte;
> +			pv_mmu_ops.set_pte_at = xen_dom0pvh_set_pte_at;
> +		}
> +		return;
> +	}
> +
>  	x86_init.mapping.pagetable_reserve = xen_mapping_pagetable_reserve;
>  	x86_init.paging.pagetable_setup_start = xen_pagetable_setup_start;
> -	x86_init.paging.pagetable_setup_done = xen_pagetable_setup_done;
>  	pv_mmu_ops = xen_mmu_ops;
>  
>  	memset(dummy_mapping, 0xff, PAGE_SIZE);

I wonder whether it would make sense to have a xen_pvh_init_mmu_ops,
given that they end up being so different...


> @@ -2305,6 +2358,92 @@ void __init xen_hvm_init_mmu_ops(void)
>  }
>  #endif
>  
> +/* Map foreign gmfn, fgmfn, to local pfn, lpfn. This for the user space 
> + * creating new guest on PVH dom0 and needs to map domU pages. 
> + */
> +static int pvh_add_to_xen_p2m(unsigned long lpfn, unsigned long fgmfn,
> +			      unsigned int domid)
> +{
> +	int rc;
> +	struct xen_add_to_physmap xatp = { .u.foreign_domid = domid };
> +
> +	xatp.gpfn = lpfn;
> +	xatp.idx = fgmfn;
> +	xatp.domid = DOMID_SELF;
> +	xatp.space = XENMAPSPACE_gmfn_foreign;
> +	rc = HYPERVISOR_memory_op(XENMEM_add_to_physmap, &xatp);
> +	if (rc)
> +		pr_warn("d0: Failed to map pfn to mfn rc:%d pfn:%lx mfn:%lx\n", 
> +			rc, lpfn, fgmfn); 
> +	return rc;
> +}
> +
> +int pvh_rem_xen_p2m(unsigned long spfn, int count)
> +{
> +	struct xen_remove_from_physmap xrp;
> +	int i, rc;
> +
> +	for (i=0; i < count; i++) {
> +		xrp.domid = DOMID_SELF;
> +		xrp.gpfn = spfn+i;
> +		rc = HYPERVISOR_memory_op(XENMEM_remove_from_physmap, &xrp);
> +		if (rc) {
> +			pr_warn("Failed to unmap pfn:%lx rc:%d done:%d\n",
> +				spfn+i, rc, i);
> +			return 1;
> +		}
> +	}
> +	return 0;
> +}
> +EXPORT_SYMBOL_GPL(pvh_rem_xen_p2m);
> +
> +struct pvh_remap_data {
> +	unsigned long fgmfn;		/* foreign domain's gmfn */
> +	pgprot_t prot;
> +	domid_t  domid;
> +	struct xen_pvh_pfn_info *pvhinfop;
> +};
> +
> +static int pvh_map_pte_fn(pte_t *ptep, pgtable_t token, unsigned long addr, 
> +			void *data)
> +{
> +	int rc;
> +	struct pvh_remap_data *remapp = data;
> +	struct xen_pvh_pfn_info *pvhp = remapp->pvhinfop;
> +	unsigned long pfn = page_to_pfn(pvhp->pi_paga[pvhp->pi_next_todo++]);
> +	pte_t pteval = pte_mkspecial(pfn_pte(pfn, remapp->prot));
> +
> +	if ((rc=pvh_add_to_xen_p2m(pfn, remapp->fgmfn, remapp->domid)))
> +		return rc;
> +	native_set_pte(ptep, pteval);

Do we actually need the pte to be "special"?
I would think that being in the guest p2m, it is actually quite a normal
page.


> +	return 0;
> +}
> +
> +/* The only caller at moment passes one gmfn at a time.
> + * PVH TBD/FIXME: expand this in future to honor batch requests.
> + */
> +static int pvh_remap_gmfn_range(struct vm_area_struct *vma,
> +				unsigned long addr, unsigned long mfn, int nr,
> +				pgprot_t prot, unsigned domid,
> +				struct xen_pvh_pfn_info *pvhp)
> +{
> +	int err;
> +	struct pvh_remap_data pvhdata;
> +
> +	if (nr > 1)
> +		return -EINVAL;
> +
> +	pvhdata.fgmfn = mfn;
> +	pvhdata.prot = prot;
> +	pvhdata.domid = domid;
> +	pvhdata.pvhinfop = pvhp;
> +	err = apply_to_page_range(vma->vm_mm, addr, nr << PAGE_SHIFT,
> +				  pvh_map_pte_fn, &pvhdata);
> +	flush_tlb_all();

Maybe we can use one of the flush_tlb_range varieties instead of a
flush_tlb_all?


> +	return err;
> +}
> +
>  #define REMAP_BATCH_SIZE 16
>  
>  struct remap_data {
> @@ -2329,7 +2468,9 @@ static int remap_area_mfn_pte_fn(pte_t *ptep, pgtable_t token,
>  int xen_remap_domain_mfn_range(struct vm_area_struct *vma,
>  			       unsigned long addr,
>  			       unsigned long mfn, int nr,
> -			       pgprot_t prot, unsigned domid)
> +			       pgprot_t prot, unsigned domid,
> +			       struct xen_pvh_pfn_info *pvhp)
> +
>  {
>  	struct remap_data rmd;
>  	struct mmu_update mmu_update[REMAP_BATCH_SIZE];
> @@ -2342,6 +2483,12 @@ int xen_remap_domain_mfn_range(struct vm_area_struct *vma,
>  	BUG_ON(!((vma->vm_flags & (VM_PFNMAP | VM_RESERVED | VM_IO)) ==
>  				(VM_PFNMAP | VM_RESERVED | VM_IO)));
>  
> +	if (xen_feature(XENFEAT_auto_translated_physmap)) {
> +		/* We need to update the local page tables and the xen HAP */
> +		return pvh_remap_gmfn_range(vma, addr, mfn, nr, prot, domid,
> +					    pvhp);
> +	}
> +
>  	rmd.mfn = mfn;
>  	rmd.prot = prot;
>  
> @@ -2371,3 +2518,26 @@ out:
>  	return err;
>  }
>  EXPORT_SYMBOL_GPL(xen_remap_domain_mfn_range);
> +
> +/* Returns: Number of pages unmapped */
> +int xen_unmap_domain_mfn_range(struct vm_area_struct *vma,
> +			       struct xen_pvh_pfn_info *pvhp)
> +{
> +	int count = 0;
> +
> +	if (!pvhp || !xen_feature(XENFEAT_auto_translated_physmap))
> +		return 0;
> +
> +	while (pvhp->pi_next_todo--) {
> +		unsigned long pfn;
> +
> +		/* the mmu has already cleaned up the process mmu resources at
> +		 * this point (lookup_address will return NULL). */
> +		pfn = page_to_pfn(pvhp->pi_paga[pvhp->pi_next_todo]);
> +		pvh_rem_xen_p2m(pfn, 1);
> +		count++;
> +	}
> +	flush_tlb_all();
> +	return count;

Who is going to remove the corresponding mapping from the vma?
Also we might be able to replace the flush_tlb_all with a
flush_tlb_range.


> +EXPORT_SYMBOL_GPL(xen_unmap_domain_mfn_range);
> diff --git a/arch/x86/xen/mmu.h b/arch/x86/xen/mmu.h
> index 73809bb..6d0bb56 100644
> --- a/arch/x86/xen/mmu.h
> +++ b/arch/x86/xen/mmu.h
> @@ -23,4 +23,6 @@ unsigned long xen_read_cr2_direct(void);
>  
>  extern void xen_init_mmu_ops(void);
>  extern void xen_hvm_init_mmu_ops(void);
> +extern void xen_set_clr_mmio_pvh_pte(unsigned long pfn, unsigned long mfn,
> +				     int nr_mfns, int add_mapping);
>  #endif	/* _XEN_MMU_H */
> diff --git a/include/xen/xen-ops.h b/include/xen/xen-ops.h
> index 6a198e4..6c5ad83 100644
> --- a/include/xen/xen-ops.h
> +++ b/include/xen/xen-ops.h
> @@ -24,9 +24,19 @@ int xen_create_contiguous_region(unsigned long vstart, unsigned int order,
>  void xen_destroy_contiguous_region(unsigned long vstart, unsigned int order);
>  
>  struct vm_area_struct;
> +struct xen_pvh_pfn_info;
>  int xen_remap_domain_mfn_range(struct vm_area_struct *vma,
>  			       unsigned long addr,
>  			       unsigned long mfn, int nr,
> -			       pgprot_t prot, unsigned domid);
> +			       pgprot_t prot, unsigned domid,
> +			       struct xen_pvh_pfn_info *pvhp);
> +int xen_unmap_domain_mfn_range(struct vm_area_struct *vma,
> +			       struct xen_pvh_pfn_info *pvhp);
> +
> +struct xen_pvh_pfn_info {
> +	struct page **pi_paga;		/* pfn info page array */
> +	int 	      pi_num_pgs;
> +	int 	      pi_next_todo;
> +};
>  
>  #endif /* INCLUDE_XEN_OPS_H */
> -- 
> 1.7.2.3
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 24 11:56:45 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Sep 2012 11: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 1TG7H5-0005J4-Kp; Mon, 24 Sep 2012 11:56:31 +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 1TG7H4-0005Ix-2r
	for Xen-devel@lists.xensource.com; Mon, 24 Sep 2012 11:56:30 +0000
Received: from [85.158.139.83:10460] by server-10.bemta-5.messagelabs.com id
	A6/A4-16911-D6A40605; Mon, 24 Sep 2012 11:56:29 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1348487788!24515767!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTA4NDk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3214 invoked from network); 24 Sep 2012 11:56:28 -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;
	24 Sep 2012 11:56:28 -0000
X-IronPort-AV: E=Sophos;i="4.80,474,1344211200"; d="scan'208";a="14721953"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Sep 2012 11: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.279.1; Mon, 24 Sep 2012 12:56:27 +0100
Date: Mon, 24 Sep 2012 12:55:31 +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: <20120921121556.1a0ea8af@mantra.us.oracle.com>
Message-ID: <alpine.DEB.2.02.1209241228460.29232@kaball.uk.xensource.com>
References: <20120921121556.1a0ea8af@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>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH v1 2/8]: PVH mmu 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

There are few code style issues on this patch, I suggest you run it
through scripts/checkpatch.pl, it should be able to catch all these
errors.

On Fri, 21 Sep 2012, Mukesh Rathor wrote:
> ---
>  arch/x86/xen/mmu.c    |  180 +++++++++++++++++++++++++++++++++++++++++++++++--
>  arch/x86/xen/mmu.h    |    2 +
>  include/xen/xen-ops.h |   12 +++-
>  3 files changed, 188 insertions(+), 6 deletions(-)
> 
> diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c
> index b65a761..9b5a5ef 100644
> --- a/arch/x86/xen/mmu.c
> +++ b/arch/x86/xen/mmu.c
> @@ -73,6 +73,7 @@
>  #include <xen/interface/version.h>
>  #include <xen/interface/memory.h>
>  #include <xen/hvc-console.h>
> +#include <xen/balloon.h>
>  
>  #include "multicalls.h"
>  #include "mmu.h"
> @@ -330,6 +331,26 @@ static void xen_set_pte(pte_t *ptep, pte_t pteval)
>  	__xen_set_pte(ptep, pteval);
>  }
>  
> +void xen_set_clr_mmio_pvh_pte(unsigned long pfn, unsigned long mfn, 
> +			      int nr_mfns, int add_mapping)
> +{
> +	struct physdev_map_iomem iomem;
> +
> +	iomem.first_gfn = pfn;
> +	iomem.first_mfn = mfn;
> +	iomem.nr_mfns = nr_mfns;
> +	iomem.add_mapping = add_mapping;
> +
> +	if (HYPERVISOR_physdev_op(PHYSDEVOP_pvh_map_iomem, &iomem))
> +		BUG();
> +}
> +
> +static void xen_dom0pvh_set_pte_at(struct mm_struct *mm, unsigned long addr,
> +		    		   pte_t *ptep, pte_t pteval)
> +{
> +	native_set_pte(ptep, pteval);
> +}

can't you just set set_pte_at to native_set_pte?


>  static void xen_set_pte_at(struct mm_struct *mm, unsigned long addr,
>  		    pte_t *ptep, pte_t pteval)
>  {
> @@ -1197,6 +1218,10 @@ static void xen_post_allocator_init(void);
>  static void __init xen_pagetable_setup_done(pgd_t *base)
>  {
>  	xen_setup_shared_info();
> +
> +	if (xen_feature(XENFEAT_auto_translated_physmap))
> +		return;
> +
>  	xen_post_allocator_init();
>  }

Can we move the if..return at the beginning of xen_post_allocator_init?
It would make it easier to understand what it is for.
Or maybe we could have xen_setup_shared_info take a pgd_t *base
parameter so that you can set pagetable_setup_done to
xen_setup_shared_info directly on pvh.


> @@ -1455,6 +1480,10 @@ static void __init xen_set_pte_init(pte_t *ptep, pte_t pte)
>  static void pin_pagetable_pfn(unsigned cmd, unsigned long pfn)
>  {
>  	struct mmuext_op op;
> +
> +	if (xen_feature(XENFEAT_writable_page_tables))
> +		return;
> +
>  	op.cmd = cmd;
>  	op.arg1.mfn = pfn_to_mfn(pfn);
>  	if (HYPERVISOR_mmuext_op(&op, 1, NULL, DOMID_SELF))

given the very limited set of mmu pvops that we initialize on pvh, I
cannot find who would actually call pin_pagetable_pfn on pvh.


> @@ -1652,6 +1681,10 @@ static void set_page_prot(void *addr, pgprot_t prot)
>  	unsigned long pfn = __pa(addr) >> PAGE_SHIFT;
>  	pte_t pte = pfn_pte(pfn, prot);
>  
> +	/* recall for PVH, page tables are native. */
> +	if (xen_feature(XENFEAT_auto_translated_physmap))
> +		return;
> +
>  	if (HYPERVISOR_update_va_mapping((unsigned long)addr, pte, 0))
>  		BUG();
>  }
> @@ -1729,6 +1762,9 @@ static void convert_pfn_mfn(void *v)
>  	pte_t *pte = v;
>  	int i;
>  
> +	if (xen_feature(XENFEAT_auto_translated_physmap))
> +		return;
> +
>  	/* All levels are converted the same way, so just treat them
>  	   as ptes. */
>  	for (i = 0; i < PTRS_PER_PTE; i++)
> @@ -1745,6 +1781,7 @@ static void convert_pfn_mfn(void *v)
>   * but that's enough to get __va working.  We need to fill in the rest
>   * of the physical mapping once some sort of allocator has been set
>   * up.
> + * NOTE: for PVH, the page tables are native.
>   */
>  pgd_t * __init xen_setup_kernel_pagetable(pgd_t *pgd,
>  					 unsigned long max_pfn)
> @@ -1802,9 +1839,13 @@ pgd_t * __init xen_setup_kernel_pagetable(pgd_t *pgd,
>  	 * structure to attach it to, so make sure we just set kernel
>  	 * pgd.
>  	 */
> -	xen_mc_batch();
> -	__xen_write_cr3(true, __pa(pgd));
> -	xen_mc_issue(PARAVIRT_LAZY_CPU);
> +	if (xen_feature(XENFEAT_writable_page_tables)) {
> +		native_write_cr3(__pa(pgd));
> +	} else {
> +		xen_mc_batch();
> +		__xen_write_cr3(true, __pa(pgd));
> +		xen_mc_issue(PARAVIRT_LAZY_CPU);
> +	}
>  
>  	memblock_reserve(__pa(xen_start_info->pt_base),
>  			 xen_start_info->nr_pt_frames * PAGE_SIZE);
> @@ -2067,9 +2108,21 @@ static const struct pv_mmu_ops xen_mmu_ops __initconst = {
>  
>  void __init xen_init_mmu_ops(void)
>  {
> +	x86_init.paging.pagetable_setup_done = xen_pagetable_setup_done;
> +
> +	if (xen_feature(XENFEAT_auto_translated_physmap)) {
> +		pv_mmu_ops.flush_tlb_others = xen_flush_tlb_others;
> +
> +		/* set_pte* for PCI devices to map iomem. */
> +		if (xen_initial_domain()) {
> +			pv_mmu_ops.set_pte = native_set_pte;
> +			pv_mmu_ops.set_pte_at = xen_dom0pvh_set_pte_at;
> +		}
> +		return;
> +	}
> +
>  	x86_init.mapping.pagetable_reserve = xen_mapping_pagetable_reserve;
>  	x86_init.paging.pagetable_setup_start = xen_pagetable_setup_start;
> -	x86_init.paging.pagetable_setup_done = xen_pagetable_setup_done;
>  	pv_mmu_ops = xen_mmu_ops;
>  
>  	memset(dummy_mapping, 0xff, PAGE_SIZE);

I wonder whether it would make sense to have a xen_pvh_init_mmu_ops,
given that they end up being so different...


> @@ -2305,6 +2358,92 @@ void __init xen_hvm_init_mmu_ops(void)
>  }
>  #endif
>  
> +/* Map foreign gmfn, fgmfn, to local pfn, lpfn. This for the user space 
> + * creating new guest on PVH dom0 and needs to map domU pages. 
> + */
> +static int pvh_add_to_xen_p2m(unsigned long lpfn, unsigned long fgmfn,
> +			      unsigned int domid)
> +{
> +	int rc;
> +	struct xen_add_to_physmap xatp = { .u.foreign_domid = domid };
> +
> +	xatp.gpfn = lpfn;
> +	xatp.idx = fgmfn;
> +	xatp.domid = DOMID_SELF;
> +	xatp.space = XENMAPSPACE_gmfn_foreign;
> +	rc = HYPERVISOR_memory_op(XENMEM_add_to_physmap, &xatp);
> +	if (rc)
> +		pr_warn("d0: Failed to map pfn to mfn rc:%d pfn:%lx mfn:%lx\n", 
> +			rc, lpfn, fgmfn); 
> +	return rc;
> +}
> +
> +int pvh_rem_xen_p2m(unsigned long spfn, int count)
> +{
> +	struct xen_remove_from_physmap xrp;
> +	int i, rc;
> +
> +	for (i=0; i < count; i++) {
> +		xrp.domid = DOMID_SELF;
> +		xrp.gpfn = spfn+i;
> +		rc = HYPERVISOR_memory_op(XENMEM_remove_from_physmap, &xrp);
> +		if (rc) {
> +			pr_warn("Failed to unmap pfn:%lx rc:%d done:%d\n",
> +				spfn+i, rc, i);
> +			return 1;
> +		}
> +	}
> +	return 0;
> +}
> +EXPORT_SYMBOL_GPL(pvh_rem_xen_p2m);
> +
> +struct pvh_remap_data {
> +	unsigned long fgmfn;		/* foreign domain's gmfn */
> +	pgprot_t prot;
> +	domid_t  domid;
> +	struct xen_pvh_pfn_info *pvhinfop;
> +};
> +
> +static int pvh_map_pte_fn(pte_t *ptep, pgtable_t token, unsigned long addr, 
> +			void *data)
> +{
> +	int rc;
> +	struct pvh_remap_data *remapp = data;
> +	struct xen_pvh_pfn_info *pvhp = remapp->pvhinfop;
> +	unsigned long pfn = page_to_pfn(pvhp->pi_paga[pvhp->pi_next_todo++]);
> +	pte_t pteval = pte_mkspecial(pfn_pte(pfn, remapp->prot));
> +
> +	if ((rc=pvh_add_to_xen_p2m(pfn, remapp->fgmfn, remapp->domid)))
> +		return rc;
> +	native_set_pte(ptep, pteval);

Do we actually need the pte to be "special"?
I would think that being in the guest p2m, it is actually quite a normal
page.


> +	return 0;
> +}
> +
> +/* The only caller at moment passes one gmfn at a time.
> + * PVH TBD/FIXME: expand this in future to honor batch requests.
> + */
> +static int pvh_remap_gmfn_range(struct vm_area_struct *vma,
> +				unsigned long addr, unsigned long mfn, int nr,
> +				pgprot_t prot, unsigned domid,
> +				struct xen_pvh_pfn_info *pvhp)
> +{
> +	int err;
> +	struct pvh_remap_data pvhdata;
> +
> +	if (nr > 1)
> +		return -EINVAL;
> +
> +	pvhdata.fgmfn = mfn;
> +	pvhdata.prot = prot;
> +	pvhdata.domid = domid;
> +	pvhdata.pvhinfop = pvhp;
> +	err = apply_to_page_range(vma->vm_mm, addr, nr << PAGE_SHIFT,
> +				  pvh_map_pte_fn, &pvhdata);
> +	flush_tlb_all();

Maybe we can use one of the flush_tlb_range varieties instead of a
flush_tlb_all?


> +	return err;
> +}
> +
>  #define REMAP_BATCH_SIZE 16
>  
>  struct remap_data {
> @@ -2329,7 +2468,9 @@ static int remap_area_mfn_pte_fn(pte_t *ptep, pgtable_t token,
>  int xen_remap_domain_mfn_range(struct vm_area_struct *vma,
>  			       unsigned long addr,
>  			       unsigned long mfn, int nr,
> -			       pgprot_t prot, unsigned domid)
> +			       pgprot_t prot, unsigned domid,
> +			       struct xen_pvh_pfn_info *pvhp)
> +
>  {
>  	struct remap_data rmd;
>  	struct mmu_update mmu_update[REMAP_BATCH_SIZE];
> @@ -2342,6 +2483,12 @@ int xen_remap_domain_mfn_range(struct vm_area_struct *vma,
>  	BUG_ON(!((vma->vm_flags & (VM_PFNMAP | VM_RESERVED | VM_IO)) ==
>  				(VM_PFNMAP | VM_RESERVED | VM_IO)));
>  
> +	if (xen_feature(XENFEAT_auto_translated_physmap)) {
> +		/* We need to update the local page tables and the xen HAP */
> +		return pvh_remap_gmfn_range(vma, addr, mfn, nr, prot, domid,
> +					    pvhp);
> +	}
> +
>  	rmd.mfn = mfn;
>  	rmd.prot = prot;
>  
> @@ -2371,3 +2518,26 @@ out:
>  	return err;
>  }
>  EXPORT_SYMBOL_GPL(xen_remap_domain_mfn_range);
> +
> +/* Returns: Number of pages unmapped */
> +int xen_unmap_domain_mfn_range(struct vm_area_struct *vma,
> +			       struct xen_pvh_pfn_info *pvhp)
> +{
> +	int count = 0;
> +
> +	if (!pvhp || !xen_feature(XENFEAT_auto_translated_physmap))
> +		return 0;
> +
> +	while (pvhp->pi_next_todo--) {
> +		unsigned long pfn;
> +
> +		/* the mmu has already cleaned up the process mmu resources at
> +		 * this point (lookup_address will return NULL). */
> +		pfn = page_to_pfn(pvhp->pi_paga[pvhp->pi_next_todo]);
> +		pvh_rem_xen_p2m(pfn, 1);
> +		count++;
> +	}
> +	flush_tlb_all();
> +	return count;

Who is going to remove the corresponding mapping from the vma?
Also we might be able to replace the flush_tlb_all with a
flush_tlb_range.


> +EXPORT_SYMBOL_GPL(xen_unmap_domain_mfn_range);
> diff --git a/arch/x86/xen/mmu.h b/arch/x86/xen/mmu.h
> index 73809bb..6d0bb56 100644
> --- a/arch/x86/xen/mmu.h
> +++ b/arch/x86/xen/mmu.h
> @@ -23,4 +23,6 @@ unsigned long xen_read_cr2_direct(void);
>  
>  extern void xen_init_mmu_ops(void);
>  extern void xen_hvm_init_mmu_ops(void);
> +extern void xen_set_clr_mmio_pvh_pte(unsigned long pfn, unsigned long mfn,
> +				     int nr_mfns, int add_mapping);
>  #endif	/* _XEN_MMU_H */
> diff --git a/include/xen/xen-ops.h b/include/xen/xen-ops.h
> index 6a198e4..6c5ad83 100644
> --- a/include/xen/xen-ops.h
> +++ b/include/xen/xen-ops.h
> @@ -24,9 +24,19 @@ int xen_create_contiguous_region(unsigned long vstart, unsigned int order,
>  void xen_destroy_contiguous_region(unsigned long vstart, unsigned int order);
>  
>  struct vm_area_struct;
> +struct xen_pvh_pfn_info;
>  int xen_remap_domain_mfn_range(struct vm_area_struct *vma,
>  			       unsigned long addr,
>  			       unsigned long mfn, int nr,
> -			       pgprot_t prot, unsigned domid);
> +			       pgprot_t prot, unsigned domid,
> +			       struct xen_pvh_pfn_info *pvhp);
> +int xen_unmap_domain_mfn_range(struct vm_area_struct *vma,
> +			       struct xen_pvh_pfn_info *pvhp);
> +
> +struct xen_pvh_pfn_info {
> +	struct page **pi_paga;		/* pfn info page array */
> +	int 	      pi_num_pgs;
> +	int 	      pi_next_todo;
> +};
>  
>  #endif /* INCLUDE_XEN_OPS_H */
> -- 
> 1.7.2.3
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 24 11:56:53 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Sep 2012 11: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 1TG7HG-0005K1-18; Mon, 24 Sep 2012 11:56:42 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <singapore.mr.teo.en.ming@gmail.com>)
	id 1TG7HE-0005Jc-2V
	for xen-devel@lists.xen.org; Mon, 24 Sep 2012 11:56:40 +0000
Received: from [85.158.139.211:64446] by server-11.bemta-5.messagelabs.com id
	73/77-13866-77A40605; Mon, 24 Sep 2012 11:56:39 +0000
X-Env-Sender: singapore.mr.teo.en.ming@gmail.com
X-Msg-Ref: server-4.tower-206.messagelabs.com!1348487794!19744968!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-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23955 invoked from network); 24 Sep 2012 11:56:36 -0000
Received: from mail-pb0-f45.google.com (HELO mail-pb0-f45.google.com)
	(209.85.160.45)
	by server-4.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Sep 2012 11:56:36 -0000
Received: by pbbrp2 with SMTP id rp2so1102708pbb.32
	for <multiple recipients>; Mon, 24 Sep 2012 04:56:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=message-id:disposition-notification-to:date:from:user-agent
	:mime-version:to:subject:content-type;
	bh=bkoSBOfrlNo1V759dGrXRbg9GLiCN/DnnDtbDYQ0DfM=;
	b=VruEDClSgvQxy8BPEA6BGrQDC+z+h/BcNyOdDn5lBFkdBqZrkjyFdltyiIE87VWd6f
	NKKTznGwHeWOM1/D+LlPv+HUMXKzKRsMNSCCC15MxrWhUN4xRfv0lGxhfy5wq3bZgBs6
	kYDxMZ06g3u9kpQqa3Tp5SHSQWvacBmBd9LgVNMrlKBVDwE9QUi3/nLTggGrnnJcp/dI
	yemAsr0OE7L62jaO2cUTo1tpunEpf9z+rs1Evcofp55YjiiuXOX2ajjqhP8GzqXr2cQQ
	3UyPruX1P/Cbsv2G6nVb/ZzPqXedy9zdtSs5ds1SfHz/ro15R7Lh2ZkRO90W75c4oJnf
	1Sbg==
Received: by 10.68.203.230 with SMTP id kt6mr35762427pbc.163.1348487794558;
	Mon, 24 Sep 2012 04:56:34 -0700 (PDT)
Received: from [192.168.1.2] (cm141.gamma206.maxonline.com.sg.
	[202.156.206.141])
	by mx.google.com with ESMTPS id bm8sm8662001pab.3.2012.09.24.04.56.31
	(version=SSLv3 cipher=OTHER); Mon, 24 Sep 2012 04:56:34 -0700 (PDT)
Message-ID: <50604A6E.3040305@gmail.com>
Date: Mon, 24 Sep 2012 19:56:30 +0800
From: "Teo En Ming (Zhang Enming)" <singapore.mr.teo.en.ming@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
MIME-Version: 1.0
To: "xen-users@lists.xen.org" <xen-users@lists.xen.org>, 
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	"Teo En Ming (Zhang Enming)" <singapore.mr.teo.en.ming@gmail.com>, 
	Frank Lyon <franklyon@gmail.com>,
	David TECHER <davidtecher@yahoo.fr>, Casey DeLorme <cdelorme@gmail.com>,
	Tobias Geiger <tobias.geiger@vido.info>
Content-Type: multipart/mixed; boundary="------------020803020300030807030301"
Subject: [Xen-devel] 100% Perfect Success in Xen 4.2-unstable Changeset
 25099 VGA Passthrough with NVIDIA Quadro 6000 (Frank Lyon's Xen VGA
 Passthrough Configuration Files)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a multi-part message in MIME format.
--------------020803020300030807030301
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Dear All,

Frank Lyon (Singapore) engaged me to work on Xen VGA Passthrough for 
him. He started off contemplating VGA Passthrough using Xen Cloud 
Platform (XCP) but he couldn't get VGA Passthrough to work with it. Then 
he engaged a tech guy from a software consultancy firm in Singapore but 
the tech guy he engaged also couldn't get VGA Passthrough to work using 
Xen Cloud Platform. Finally Frank Lyon engaged me to work on Xen VGA 
Passthrough for him. I dropped XCP altogether because I have totally no 
experience with it at all. I finally got 100% perfect success in Xen VGA 
Passthrough with his NVIDIA Quadro 6000.

Here are Frank Lyon's hardware specifications:

Server: HP ProLiant DL370G6
Processors: 2x Intel Xeon CPU X5650 @ 2.67 GHz (2 Processors detected, 
12 total cores detected per processor)
Harddisks: 4X 1TB SAS MDL 6G DP 7.2K Harddisks
Memory: 48GB of memory
Display adapter: NVIDIA Quadro 6000

Here are Frank Lyon's software configuration:

Host Operating System: Ubuntu 12.04 LTS Server CD
HVM domU: Windows 7 64-bit and Windows 8 Pro 64-bit
Xen Hypervisor version: 4.2-unstable Changeset 25099
Linux Dom0 Kernel: 3.5.4 (I compiled it from sources)

Attached in this email are Xen VGA Passthrough configuration files and 
scripts I have configured for Frank Lyon's Xen VGA Passthrough server.

Reference guides/tutorials followed in setting up Frank Lyon's Xen VGA 
Passthrough server (hosted on Xen Wiki):

(1) 
http://wiki.xen.org/wiki/Building_and_Installing_Xen_4.x_and_Linux_Kernel_3.x_on_Ubuntu_and_Debian_Linux

(2) 
http://wiki.xen.org/wiki/Xen_VGA_Passthrough_to_Windows_8_with_Xen_4.2-unstable

The above two are guides/tutorials/HowTo/documentation I have written 
for (1) building and installing Xen 4.x and Linux Kernel 3.x on Ubuntu 
and Debian Linux and (2) Xen VGA Passthrough.

Dear Jean David Techer,

Now I have 100% success in getting Xen VGA Passthrough to work in Frank 
Lyon's Xen VGA Passthrough server, with Xen VGA Passthrough patches 
hosted at your personal website. The display adapter which was 100% 
successfully passed through in Frank Lyon's example is a NVIDIA Quadro 
6000. I still have no idea why I have PARTIAL (less than 100%) success 
with Xen VGA Passthrough with my own NVIDIA Geforce 8400 GS VGA card. As 
I have told you before, there is a yellow exclamation mark with my 
NVIDIA Geforce 8400 GS in Device Manager in Windows XP and Windows 8 HVM 
domUs. I am so totally astonished and elated and happy that I could get 
100% success in Xen VGA Passthrough with Frank Lyon's Xen VGA 
Passthrough server. The Xen VGA Passthrough patches hosted at your 
personal website definitely works. Thumbs up David Techer! There is 
***ABSOLUTELY NO*** yellow exclamation mark with Frank Lyon's NVIDIA 
Quadro 6000 in Device Manager in Windows 7 and Windows 8 HVM domUs. I 
really wondered what's the problem with my case. I could get somebody 
else's Xen VGA Passthrough to work but yet I could not get mine to work 
100%. Perhaps I should get another NVIDIA vga card to try out VGA 
Passthrough.

Dear All,

Although I have 100% success in Xen VGA Passthrough in Frank Lyon's 
case, it was done with Xen 4.2-unstable Changeset 25099. I couldn't get 
Xen VGA Passthrough to work with Xen 4.3-unstable. Perhaps the Xen 
developers could look into this problem?

In addition, I cannot passthrough TWO NVIDIA Quadro 6000 to a single 
Windows 7 or Windows 8 HVM guest. Anybody knows how I could passthrough 
two GPUs to a single HVM? Windows 7 and Windows 8 HVM guests would go 
haywire with the 2nd NVIDIA Quadro 6000 plugged in. The 2nd NVIDIA 
Quadro 6000 needs to be unplugged. Anybody knows why?

Please advise. Thank you very much for your kind attention.

-- 
Yours sincerely,
Mr. Teo En Ming (Zhang Enming)
Singapore

--------------020803020300030807030301
Content-Type: text/plain;
 name="40_custom"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename="40_custom"

#!/bin/sh
exec tail -n +3 $0
# This file provides an easy way to add custom menu entries.  Simply type the
# menu entries you want to add after this comment.  Be careful not to change
# the 'exec tail' line above.
menuentry 'Ubuntu 12.04 amd64 Release with Xen 4.3-unstable and Linux Kernel 3.5.4-xen-frank.lyon-sgp' --class gnu-linux --class gnu --class os {
recordfail
insmod part_msdos
insmod ext2
search --no-floppy --fs-uuid --set=root d5ec6b7f-e1db-4b46-b050-d0bd46403f59
set root='(hd0,msdos1)'
search --no-floppy --fs-uuid --set=root d5ec6b7f-e1db-4b46-b050-d0bd46403f59
multiboot /xen.gz
module /vmlinuz-3.5.4-xen-frank.lyon-sgp placeholder root=/dev/mapper/snow-root dom0_mem=1024 console=tty quiet splash vt.handoff=7 nomodeset
module /initrd.img-3.5.4-xen-frank.lyon-sgp
}

--------------020803020300030807030301
Content-Type: text/plain;
 name="dsdt.asl"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename="dsdt.asl"

/******************************************************************************
 * DSDT for Xen with Qemu device model
 *
 * Copyright (c) 2004, Intel Corporation.
 *
 * This program is free software; you can redistribute it and/or modify it
 * under the terms and conditions of the GNU General Public License,
 * version 2, as published by the Free Software Foundation.
 *
 * This program is distributed in the hope it will be useful, but WITHOUT
 * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
 * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
 * more details.
 *
 * You should have received a copy of the GNU General Public License along with
 * this program; if not, write to the Free Software Foundation, Inc., 59 Temple
 * Place - Suite 330, Boston, MA 02111-1307 USA.
 */

DefinitionBlock ("DSDT.aml", "DSDT", 2, "Xen", "HVM", 0)
{
    Name (\PMBS, 0x0C00)
    Name (\PMLN, 0x08)
    Name (\IOB1, 0x00)
    Name (\IOL1, 0x00)
    Name (\APCB, 0xFEC00000)
    Name (\APCL, 0x00010000)
    Name (\PUID, 0x00)

    /* _S3 and _S4 are in separate SSDTs */
    Name (\_S5, Package (0x04)
    {
        0x00,  /* PM1a_CNT.SLP_TYP */
        0x00,  /* PM1b_CNT.SLP_TYP */
        0x00,  /* reserved */
        0x00   /* reserved */
    })

    Name(PICD, 0)
    Method(_PIC, 1)
    {
        Store(Arg0, PICD) 
    }

    Scope (\_SB)
    {
       /* ACPI_INFO_PHYSICAL_ADDRESS == 0xFC000000 */
       OperationRegion(BIOS, SystemMemory, 0xFC000000, 24)
       Field(BIOS, ByteAcc, NoLock, Preserve) {
           UAR1, 1,
           UAR2, 1,
           LTP1, 1,
           HPET, 1,
           Offset(4),
           PMIN, 32,
           PLEN, 32,
           MSUA, 32, /* MADT checksum address */
           MAPA, 32, /* MADT LAPIC0 address */
           VGIA, 32  /* VM generation id address */
       }

        /* Fix HCT test for 0x400 pci memory:
         * - need to report low 640 MB mem as motherboard resource
         */
       Device(MEM0)
       {
           Name(_HID, EISAID("PNP0C02"))
           Name(_CRS, ResourceTemplate() {
               QWordMemory(
                    ResourceConsumer, PosDecode, MinFixed,
                    MaxFixed, Cacheable, ReadWrite,
                    0x00000000,
                    0x00000000,
                    0x0009ffff,
                    0x00000000,
                    0x000a0000)
           })
       }

       Device (PCI0)
       {
           Name (_HID, EisaId ("PNP0A03"))
           Name (_UID, 0x00)
           Name (_ADR, 0x00)
           Name (_BBN, 0x00)

           /* Make cirrues VGA S3 suspend/resume work in Windows XP/2003 */
           Device (VGA)
           {
               Name (_ADR, 0x00020000)

               Method (_S1D, 0, NotSerialized)
               {
                   Return (0x00)
               }
               Method (_S2D, 0, NotSerialized)
               {
                   Return (0x00)
               }
               Method (_S3D, 0, NotSerialized)
               {
                   Return (0x00)
               }
           }

           Method (_CRS, 0, NotSerialized)
           {
               Name (PRT0, ResourceTemplate ()
               {
                   /* bus number is from 0 - 255*/
                   WordBusNumber(
                        ResourceProducer, MinFixed, MaxFixed, SubDecode,
                        0x0000,
                        0x0000,
                        0x00FF,
                        0x0000,
                        0x0100)
                    IO (Decode16, 0x0CF8, 0x0CF8, 0x01, 0x08)
                    WordIO(
                        ResourceProducer, MinFixed, MaxFixed, PosDecode,
                        EntireRange,
                        0x0000,
                        0x0000,
                        0x0CF7,
                        0x0000,
                        0x0CF8)
                    WordIO(
                        ResourceProducer, MinFixed, MaxFixed, PosDecode,
                        EntireRange,
                        0x0000,
                        0x0D00,
                        0xFFFF,
                        0x0000,
                        0xF300)

                    /* reserve memory for pci devices */
                    DWordMemory(
                        ResourceProducer, PosDecode, MinFixed, MaxFixed,
                        Cacheable, ReadWrite,
                        0x00000000,
                        0x000A0000,
                        0x000BFFFF,
                        0x00000000,
                        0x00020000)

                    /* reserve MMIO BARs of gfx for 1:1 mapping */
                    DWordMemory(
                        ResourceProducer, PosDecode, MinFixed, MaxFixed,
                        Cacheable, ReadWrite,
                        0x00000000,
                        0xF8000000,
                        0xF9FFFFFF,
                        0x00000000,
                        0x02000000)

                    DWordMemory(
                        ResourceProducer, PosDecode, MinFixed, MaxFixed,
                        NonCacheable, ReadWrite,
                        0x00000000,
                        0xD8000000,
                        0xDFFFFFFF,
                        0x00000000,
                        0x08000000)

                    DWordMemory(
                        ResourceProducer, PosDecode, MinFixed, MaxFixed,
                        Cacheable, ReadWrite,
                        0x00000000,
                        0xD4000000,
                        0xD7FFFFFF,
                        0x00000000,
                        0x04000000)

                    DWordMemory(
                        ResourceProducer, PosDecode, MinFixed, MaxFixed,
                        Cacheable, ReadWrite,
                        0x00000000,
                        0xFB000000,
                        0xFB07FFFF,
                        0x00000000,
                        0x00080000,                        
			,, _Y01)
                })

                CreateDWordField(PRT0, \_SB.PCI0._CRS._Y01._MIN, MMIN)
                CreateDWordField(PRT0, \_SB.PCI0._CRS._Y01._MAX, MMAX)
                CreateDWordField(PRT0, \_SB.PCI0._CRS._Y01._LEN, MLEN)

                Store(\_SB.PMIN, MMIN)
                Store(\_SB.PLEN, MLEN)
                Add(MMIN, MLEN, MMAX)
                Subtract(MMAX, One, MMAX)

                Return (PRT0)
            }

            Device(HPET) {
                Name(_HID,  EISAID("PNP0103"))
                Name(_UID, 0)
                Method (_STA, 0, NotSerialized) {
                    If(LEqual(\_SB.HPET, 0)) {
                        Return(0x00)
                    } Else {
                        Return(0x0F)
                    }
                }
                Name(_CRS, ResourceTemplate() {
                    DWordMemory(
                        ResourceConsumer, PosDecode, MinFixed, MaxFixed,
                        NonCacheable, ReadWrite,
                        0x00000000,
                        0xFED00000,
                        0xFED003FF,
                        0x00000000,
                        0x00000400 /* 1K memory: FED00000 - FED003FF */
                    )
                })
            }

            Device (ISA)
            {
                Name (_ADR, 0x00010000) /* device 1, fn 0 */

                OperationRegion(PIRQ, PCI_Config, 0x60, 0x4)
                Scope(\) {
                    Field (\_SB.PCI0.ISA.PIRQ, ByteAcc, NoLock, Preserve) {
                        PIRA, 8,
                        PIRB, 8,
                        PIRC, 8,
                        PIRD, 8
                    }
                }
                Device (SYSR)
                {
                    Name (_HID, EisaId ("PNP0C02"))
                    Name (_UID, 0x01)
                    Name (CRS, ResourceTemplate ()
                    {
                        /* TODO: list hidden resources */
                        IO (Decode16, 0x0010, 0x0010, 0x00, 0x10)
                        IO (Decode16, 0x0022, 0x0022, 0x00, 0x0C)
                        IO (Decode16, 0x0030, 0x0030, 0x00, 0x10)
                        IO (Decode16, 0x0044, 0x0044, 0x00, 0x1C)
                        IO (Decode16, 0x0062, 0x0062, 0x00, 0x02)
                        IO (Decode16, 0x0065, 0x0065, 0x00, 0x0B)
                        IO (Decode16, 0x0072, 0x0072, 0x00, 0x0E)
                        IO (Decode16, 0x0080, 0x0080, 0x00, 0x01)
                        IO (Decode16, 0x0084, 0x0084, 0x00, 0x03)
                        IO (Decode16, 0x0088, 0x0088, 0x00, 0x01)
                        IO (Decode16, 0x008C, 0x008C, 0x00, 0x03)
                        IO (Decode16, 0x0090, 0x0090, 0x00, 0x10)
                        IO (Decode16, 0x00A2, 0x00A2, 0x00, 0x1C)
                        IO (Decode16, 0x00E0, 0x00E0, 0x00, 0x10)
                        IO (Decode16, 0x08A0, 0x08A0, 0x00, 0x04)
                        IO (Decode16, 0x0CC0, 0x0CC0, 0x00, 0x10)
                        IO (Decode16, 0x04D0, 0x04D0, 0x00, 0x02)
                    })
                    Method (_CRS, 0, NotSerialized)
                    {
                        Return (CRS)
                    }
                }

                Device (PIC)
                {
                    Name (_HID, EisaId ("PNP0000"))
                    Name (_CRS, ResourceTemplate ()
                    {
                        IO (Decode16, 0x0020, 0x0020, 0x01, 0x02)
                        IO (Decode16, 0x00A0, 0x00A0, 0x01, 0x02)
                        IRQNoFlags () {2}
                    })
                }

                Device (DMA0)
                {
                    Name (_HID, EisaId ("PNP0200"))
                    Name (_CRS, ResourceTemplate ()
                    {
                        DMA (Compatibility, BusMaster, Transfer8) {4}
                        IO (Decode16, 0x0000, 0x0000, 0x00, 0x10)
                        IO (Decode16, 0x0081, 0x0081, 0x00, 0x03)
                        IO (Decode16, 0x0087, 0x0087, 0x00, 0x01)
                        IO (Decode16, 0x0089, 0x0089, 0x00, 0x03)
                        IO (Decode16, 0x008F, 0x008F, 0x00, 0x01)
                        IO (Decode16, 0x00C0, 0x00C0, 0x00, 0x20)
                        IO (Decode16, 0x0480, 0x0480, 0x00, 0x10)
                    })
                }

                Device (TMR)
                {
                    Name (_HID, EisaId ("PNP0100"))
                    Name (_CRS, ResourceTemplate ()
                    {
                        IO (Decode16, 0x0040, 0x0040, 0x00, 0x04)
                        IRQNoFlags () {0}
                    })
                }

                Device (RTC)
                {
                    Name (_HID, EisaId ("PNP0B00"))
                    Name (_CRS, ResourceTemplate ()
                    {
                        IO (Decode16, 0x0070, 0x0070, 0x00, 0x02)
                        IRQNoFlags () {8}
                    })
                }

                Device (SPKR)
                {
                    Name (_HID, EisaId ("PNP0800"))
                    Name (_CRS, ResourceTemplate ()
                    {
                        IO (Decode16, 0x0061, 0x0061, 0x00, 0x01)
                    })
                }

                Device (PS2M)
                {
                    Name (_HID, EisaId ("PNP0F13"))
                    Name (_CID, 0x130FD041)
                    Method (_STA, 0, NotSerialized)
                    {
                        Return (0x0F)
                    }

                    Name (_CRS, ResourceTemplate ()
                    {
                        IRQNoFlags () {12}
                    })
                }

                Device (PS2K)
                {
                    Name (_HID, EisaId ("PNP0303"))
                    Name (_CID, 0x0B03D041)
                    Method (_STA, 0, NotSerialized)
                    {
                        Return (0x0F)
                    }

                    Name (_CRS, ResourceTemplate ()
                    {
                        IO (Decode16, 0x0060, 0x0060, 0x00, 0x01)
                        IO (Decode16, 0x0064, 0x0064, 0x00, 0x01)
                        IRQNoFlags () {1}
                    })
                }

                Device (FDC0)
                {
                    Name (_HID, EisaId ("PNP0700"))
                    Method (_STA, 0, NotSerialized)
                    {
                          Return (0x0F)
                    }

                    Name (_CRS, ResourceTemplate ()
                    {
                        IO (Decode16, 0x03F0, 0x03F0, 0x01, 0x06)
                        IO (Decode16, 0x03F7, 0x03F7, 0x01, 0x01)
                        IRQNoFlags () {6}
                        DMA (Compatibility, NotBusMaster, Transfer8) {2}
                    })
                }

                Device (UAR1)
                {
                    Name (_HID, EisaId ("PNP0501"))
                    Name (_UID, 0x01)
                    Method (_STA, 0, NotSerialized)
                    {
                        If(LEqual(\_SB.UAR1, 0)) {
                            Return(0x00)
                        } Else {
                            Return(0x0F)
                        }
                    }

                    Name (_CRS, ResourceTemplate()
                    {
                        IO (Decode16, 0x03F8, 0x03F8, 8, 8)
                        IRQNoFlags () {4}
                    })
                }

                Device (UAR2)
                {
                    Name (_HID, EisaId ("PNP0501"))
                    Name (_UID, 0x02)
                    Method (_STA, 0, NotSerialized)
                    {
                        If(LEqual(\_SB.UAR2, 0)) {
                            Return(0x00)
                        } Else {
                            Return(0x0F)
                        }
                    }

                    Name (_CRS, ResourceTemplate()
                    {
                        IO (Decode16, 0x02F8, 0x02F8, 8, 8)
                        IRQNoFlags () {3}
                    })
                }

                Device (LTP1)
                {
                    Name (_HID, EisaId ("PNP0400"))
                    Name (_UID, 0x02)
                    Method (_STA, 0, NotSerialized)
                    {
                        If(LEqual(\_SB.LTP1, 0)) {
                            Return(0x00)
                        } Else {
                            Return(0x0F)
                        }
                    }

                    Name (_CRS, ResourceTemplate()
                    {
                        IO (Decode16, 0x0378, 0x0378, 0x08, 0x08)
                        IRQNoFlags () {7}
                    })
                } 

                Device(VGID) {
                    Name(_HID, EisaID ("XEN0000"))
                    Name(_UID, 0x00)
                    Name(_CID, "VM_Gen_Counter")
                    Name(_DDN, "VM_Gen_Counter")
                    Method(_STA, 0, NotSerialized)
                    {
                        If(LEqual(\_SB.VGIA, 0x00000000)) {
                            Return(0x00)
                        } Else {
                            Return(0x0F)
                        }
                    }
                    Name(PKG, Package ()
                    {
                        0x00000000,
                        0x00000000
                    })
                    Method(ADDR, 0, NotSerialized)
                    {
                        Store(\_SB.VGIA, Index(PKG, 0))
                        Return(PKG)
                    }
                }
            }
        }
    }
}

--------------020803020300030807030301
Content-Type: text/plain;
 name="grub"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename="grub"

# If you change this file, run 'update-grub' afterwards to update
# /boot/grub/grub.cfg.
# For full documentation of the options in this file, see:
#   info -f grub -n 'Simple configuration'

GRUB_DEFAULT=13
#GRUB_HIDDEN_TIMEOUT=0
GRUB_HIDDEN_TIMEOUT_QUIET=true
GRUB_TIMEOUT=50
GRUB_DISTRIBUTOR=`lsb_release -i -s 2> /dev/null || echo Debian`
GRUB_CMDLINE_LINUX_DEFAULT=""
GRUB_CMDLINE_LINUX="nomodeset"

# Uncomment to enable BadRAM filtering, modify to suit your needs
# This works with Linux (no patch required) and with any kernel that obtains
# the memory map information from GRUB (GNU Mach, kernel of FreeBSD ...)
#GRUB_BADRAM="0x01234567,0xfefefefe,0x89abcdef,0xefefefef"

# Uncomment to disable graphical terminal (grub-pc only)
#GRUB_TERMINAL=console

# The resolution used on graphical terminal
# note that you can use only modes which your graphic card supports via VBE
# you can see them in real GRUB with the command `vbeinfo'
#GRUB_GFXMODE=640x480

# Uncomment if you don't want GRUB to pass "root=UUID=xxx" parameter to Linux
#GRUB_DISABLE_LINUX_UUID=true

# Uncomment to disable generation of recovery mode menu entries
#GRUB_DISABLE_RECOVERY="true"

# Uncomment to get a beep at grub start
#GRUB_INIT_TUNE="480 440 1"

--------------020803020300030807030301
Content-Type: text/plain;
 name="rc.local"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename="rc.local"

#!/bin/sh -e
#
# rc.local
#
# This script is executed at the end of each multiuser runlevel.
# Make sure that the script will "exit 0" on success or any other
# value on error.
#
# In order to enable or disable this script just change the execution
# bits.
#
# By default this script does nothing.

sudo ifconfig eth0 up
sudo route add default gw 192.168.25.1
sudo echo "nameserver 192.168.50.15" >> /etc/resolv.conf
sudo echo "nameserver 192.168.50.30" >> /etc/resolv.conf
exit 0

--------------020803020300030807030301
Content-Type: text/plain;
 name="start-windows"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename="start-windows"

#!/bin/sh
set -x
#
#Loads pci-stub kernel module
sudo modprobe pci-stub
#
#Passthrough NVIDIA Quadro 6000
# 
echo "Passthrough NVIDIA Quadro 6000 VGA card."
sudo chmod o+w /sys/bus/pci/drivers/pci-stub/new_id
sudo chmod o+w /sys/bus/pci/devices/0000:0d:00.0/driver/unbind
sudo chmod o+w /sys/bus/pci/drivers/pci-stub/bind
echo "10de 06d8" > /sys/bus/pci/drivers/pci-stub/new_id
echo "0000:0d:00.0" > /sys/bus/pci/devices/0000:0d:00.0/driver/unbind
echo "0000:0d:00.0" > /sys/bus/pci/drivers/pci-stub/bind
#
#Passthrough NVIDIA HD Audio Controller
# 
echo "Passthrough NVIDIA HD Audio Controller."
sudo chmod o+w /sys/bus/pci/drivers/pci-stub/new_id
sudo chmod o+w /sys/bus/pci/devices/0000:0d:00.1/driver/unbind
sudo chmod o+w /sys/bus/pci/drivers/pci-stub/bind
echo "10de 0be5" > /sys/bus/pci/drivers/pci-stub/new_id
echo "0000:0d:00.1" > /sys/bus/pci/devices/0000:0d:00.1/driver/unbind
echo "0000:0d:00.1" > /sys/bus/pci/drivers/pci-stub/bind
#
#Passthrough 2nd NVIDIA Quadro 6000
#
#echo "Passthrough 2nd NVIDIA Quadro 6000 VGA card."
#sudo chmod o+w /sys/bus/pci/drivers/pci-stub/new_id
#sudo chmod o+w /sys/bus/pci/devices/0000:1b:00.0/driver/unbind
#sudo chmod o+w /sys/bus/pci/drivers/pci-stub/bind
#echo "10de 06d8" > /sys/bus/pci/drivers/pci-stub/new_id
#echo "0000:1b:00.0" > /sys/bus/pci/devices/0000:1b:00.0/driver/unbind
#echo "0000:1b:00.0" > /sys/bus/pci/drivers/pci-stub/bind
#
#Passthrough 2nd NVIDIA HD Audio Controller
#
#echo "Passthrough 2nd NVIDIA HD Audio Controller."
#sudo chmod o+w /sys/bus/pci/drivers/pci-stub/new_id
#sudo chmod o+w /sys/bus/pci/devices/0000:1b:00.1/driver/unbind
#sudo chmod o+w /sys/bus/pci/drivers/pci-stub/bind
#echo "10de 0be5" > /sys/bus/pci/drivers/pci-stub/new_id
#echo "0000:1b:00.1" > /sys/bus/pci/devices/0000:1b:00.1/driver/unbind
#echo "0000:1b:00.1" > /sys/bus/pci/drivers/pci-stub/bind
#
#Passthrough USB 1.1 Controller #3
#
echo "Passthrough USB 1.1 Controller #3"
sudo chmod o+w /sys/bus/pci/drivers/pci-stub/new_id
sudo chmod o+w /sys/bus/pci/devices/0000:00:1d.2/driver/unbind
sudo chmod o+w /sys/bus/pci/drivers/pci-stub/bind
echo "8086 3a36" > /sys/bus/pci/drivers/pci-stub/new_id
echo "0000:00:1d.2" > /sys/bus/pci/devices/0000:00:1d.2/driver/unbind
echo "0000:00:1d.2" > /sys/bus/pci/drivers/pci-stub/bind
#
#Passthrough USB 1.1 Controller #4
#
echo "Passthrough USB 1.1 Controller #4"
sudo chmod o+w /sys/bus/pci/drivers/pci-stub/new_id
sudo chmod o+w /sys/bus/pci/devices/0000:00:1d.3/driver/unbind
sudo chmod o+w /sys/bus/pci/drivers/pci-stub/bind
echo "8086 3a39" > /sys/bus/pci/drivers/pci-stub/new_id
echo "0000:00:1d.3" > /sys/bus/pci/devices/0000:00:1d.3/driver/unbind
echo "0000:00:1d.3" > /sys/bus/pci/drivers/pci-stub/bind

#
#Wait for 10 seconds
#
sleep 10
#
#Start Windows HVM domU with VGA Passthrough
#
sudo xl create /etc/xen/Windows7
#sudo xl create /etc/xen/Windows8

--------------020803020300030807030301
Content-Type: text/plain;
 name="Windows7"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename="Windows7"

# XL domain configuration file for Windows 8 Consumer Preview 64-bit English HVM domU
# Please refer to "man xl.cfg" for further explanations.
# See also docs/misc/xl-network-configuration.markdown and
# docs/misc/xl-disk-configuration.txt
# Written by Teo En Ming (Zhang Enming)
# Email: teo.en.ming@gmail.com
# Mobile Phone: +65-8369-2618
# Country: Singapore
# Date: 18 Mar 2012 Sun
name="Windows8"
# Product Key: WJBRX-2N7B2-CCBF6-VPP97-R88XV
builder="hvm"
vcpus=2
memory=2048
on_poweroff="destroy"
on_reboot="restart"
on_crash="destroy"
disk=[ 'format=raw, vdev=hda, access=rw, target=/etc/xen/images/windows7.img', 'format=raw, vdev=hdc, access=ro, devtype=cdrom, target=/home/flyon/windows7.iso' ]
vif=[ 'bridge=eth0,type=ioemu,model=e1000' ]
#boot=[c|d|n]
# Selects the emulated virtual device to boot from. Options are hard disk (c), cd-rom (d) or network/PXE (n).
# Multiple options can be given and will be attempted in the order they are given. e.g. to boot from cd-rom
# but fallback to the hard disk you can give dc. The default is cd.
boot="dc"
acpi=1
#xen_platform_pci=1
#viridian=1
#stdvga=1

vnc=1
vnclisten="192.168.25.50"
vncdisplay=0
vncunused=1
vncpasswd=""
sdl=0
usb=1
# Passthrough the USB Keyboard
usbdevice = "host:04f2:0110"
# Passthrough the USB Optical Mouse
usbdevice = "host:046d:c03d"
# Enable Xen VGA Passthrough
gfx_passthru=1
# VGA Passthrough NVIDIA Quadro 6000 and PCI Passthrough NVIDIA HD Audio Controller, then 2nd NVIDIA Quadro 6000 and 2nd NVIDIA HD Audio Controller
#pci = [ '0d:00.0','0d:00.1','1b:00.0','1b:00.1' ]
# The last 2 entries are USB 1.1 controllers.
pci = [ '0d:00.0','0d:00.1','00:1d.2','00:1d.3' ]

# PCI Passthrough Intel HD Audio Controller.
#pci = [ '00:1b.0' ]
# PCI Passthrough all the USB Controllers.
# pci = [ '00:1a.0','00:1a.1','00:1a.2','00:1a.7','00:1d.0','00:1d.1','00:1d.2','00:1d.7' ]


--------------020803020300030807030301
Content-Type: text/plain;
 name="Windows8"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename="Windows8"

# XL domain configuration file for Windows 8 Consumer Preview 64-bit English HVM domU
# Please refer to "man xl.cfg" for further explanations.
# See also docs/misc/xl-network-configuration.markdown and
# docs/misc/xl-disk-configuration.txt
# Written by Teo En Ming (Zhang Enming)
# Email: teo.en.ming@gmail.com
# Mobile Phone: +65-8369-2618
# Country: Singapore
# Date: 18 Mar 2012 Sun
name="Windows8"
# Product Key: WJBRX-2N7B2-CCBF6-VPP97-R88XV
builder="hvm"
vcpus=2
memory=2048
on_poweroff="destroy"
on_reboot="restart"
on_crash="destroy"
disk=[ 'format=raw, vdev=hda, access=rw, target=/etc/xen/images/windows8.img', 'format=raw, vdev=hdc, access=ro, devtype=cdrom, target=/home/flyon/windows8.iso' ]
vif=[ 'bridge=eth0,type=ioemu,model=e1000' ]
#boot=[c|d|n]
# Selects the emulated virtual device to boot from. Options are hard disk (c), cd-rom (d) or network/PXE (n).
# Multiple options can be given and will be attempted in the order they are given. e.g. to boot from cd-rom
# but fallback to the hard disk you can give dc. The default is cd.
boot="dc"
acpi=1
#xen_platform_pci=1
#viridian=1
#stdvga=1

vnc=1
vnclisten="192.168.25.50"
vncdisplay=0
vncunused=1
vncpasswd=""
sdl=0
usb=1
# Passthrough the USB Keyboard
usbdevice = "host:04f2:0110"
# Passthrough the USB Optical Mouse
usbdevice = "host:046d:c03d"
# Enable Xen VGA Passthrough
gfx_passthru=1
# VGA Passthrough NVIDIA Quadro 6000 and PCI Passthrough NVIDIA HD Audio Controller, then 2nd NVIDIA Quadro 6000 and 2nd NVIDIA HD Audio Controller
#pci = [ '0d:00.0','0d:00.1','1b:00.0','1b:00.1' ]
pci = [ '0d:00.0','0d:00.1' ]

# PCI Passthrough Intel HD Audio Controller.
#pci = [ '00:1b.0' ]
# PCI Passthrough all the USB Controllers.
# pci = [ '00:1a.0','00:1a.1','00:1a.2','00:1a.7','00:1d.0','00:1d.1','00:1d.2','00:1d.7' ]


--------------020803020300030807030301
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--------------020803020300030807030301--


From xen-devel-bounces@lists.xen.org Mon Sep 24 11:56:53 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Sep 2012 11: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 1TG7HG-0005K1-18; Mon, 24 Sep 2012 11:56:42 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <singapore.mr.teo.en.ming@gmail.com>)
	id 1TG7HE-0005Jc-2V
	for xen-devel@lists.xen.org; Mon, 24 Sep 2012 11:56:40 +0000
Received: from [85.158.139.211:64446] by server-11.bemta-5.messagelabs.com id
	73/77-13866-77A40605; Mon, 24 Sep 2012 11:56:39 +0000
X-Env-Sender: singapore.mr.teo.en.ming@gmail.com
X-Msg-Ref: server-4.tower-206.messagelabs.com!1348487794!19744968!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-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23955 invoked from network); 24 Sep 2012 11:56:36 -0000
Received: from mail-pb0-f45.google.com (HELO mail-pb0-f45.google.com)
	(209.85.160.45)
	by server-4.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Sep 2012 11:56:36 -0000
Received: by pbbrp2 with SMTP id rp2so1102708pbb.32
	for <multiple recipients>; Mon, 24 Sep 2012 04:56:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=message-id:disposition-notification-to:date:from:user-agent
	:mime-version:to:subject:content-type;
	bh=bkoSBOfrlNo1V759dGrXRbg9GLiCN/DnnDtbDYQ0DfM=;
	b=VruEDClSgvQxy8BPEA6BGrQDC+z+h/BcNyOdDn5lBFkdBqZrkjyFdltyiIE87VWd6f
	NKKTznGwHeWOM1/D+LlPv+HUMXKzKRsMNSCCC15MxrWhUN4xRfv0lGxhfy5wq3bZgBs6
	kYDxMZ06g3u9kpQqa3Tp5SHSQWvacBmBd9LgVNMrlKBVDwE9QUi3/nLTggGrnnJcp/dI
	yemAsr0OE7L62jaO2cUTo1tpunEpf9z+rs1Evcofp55YjiiuXOX2ajjqhP8GzqXr2cQQ
	3UyPruX1P/Cbsv2G6nVb/ZzPqXedy9zdtSs5ds1SfHz/ro15R7Lh2ZkRO90W75c4oJnf
	1Sbg==
Received: by 10.68.203.230 with SMTP id kt6mr35762427pbc.163.1348487794558;
	Mon, 24 Sep 2012 04:56:34 -0700 (PDT)
Received: from [192.168.1.2] (cm141.gamma206.maxonline.com.sg.
	[202.156.206.141])
	by mx.google.com with ESMTPS id bm8sm8662001pab.3.2012.09.24.04.56.31
	(version=SSLv3 cipher=OTHER); Mon, 24 Sep 2012 04:56:34 -0700 (PDT)
Message-ID: <50604A6E.3040305@gmail.com>
Date: Mon, 24 Sep 2012 19:56:30 +0800
From: "Teo En Ming (Zhang Enming)" <singapore.mr.teo.en.ming@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
MIME-Version: 1.0
To: "xen-users@lists.xen.org" <xen-users@lists.xen.org>, 
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	"Teo En Ming (Zhang Enming)" <singapore.mr.teo.en.ming@gmail.com>, 
	Frank Lyon <franklyon@gmail.com>,
	David TECHER <davidtecher@yahoo.fr>, Casey DeLorme <cdelorme@gmail.com>,
	Tobias Geiger <tobias.geiger@vido.info>
Content-Type: multipart/mixed; boundary="------------020803020300030807030301"
Subject: [Xen-devel] 100% Perfect Success in Xen 4.2-unstable Changeset
 25099 VGA Passthrough with NVIDIA Quadro 6000 (Frank Lyon's Xen VGA
 Passthrough Configuration Files)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a multi-part message in MIME format.
--------------020803020300030807030301
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Dear All,

Frank Lyon (Singapore) engaged me to work on Xen VGA Passthrough for 
him. He started off contemplating VGA Passthrough using Xen Cloud 
Platform (XCP) but he couldn't get VGA Passthrough to work with it. Then 
he engaged a tech guy from a software consultancy firm in Singapore but 
the tech guy he engaged also couldn't get VGA Passthrough to work using 
Xen Cloud Platform. Finally Frank Lyon engaged me to work on Xen VGA 
Passthrough for him. I dropped XCP altogether because I have totally no 
experience with it at all. I finally got 100% perfect success in Xen VGA 
Passthrough with his NVIDIA Quadro 6000.

Here are Frank Lyon's hardware specifications:

Server: HP ProLiant DL370G6
Processors: 2x Intel Xeon CPU X5650 @ 2.67 GHz (2 Processors detected, 
12 total cores detected per processor)
Harddisks: 4X 1TB SAS MDL 6G DP 7.2K Harddisks
Memory: 48GB of memory
Display adapter: NVIDIA Quadro 6000

Here are Frank Lyon's software configuration:

Host Operating System: Ubuntu 12.04 LTS Server CD
HVM domU: Windows 7 64-bit and Windows 8 Pro 64-bit
Xen Hypervisor version: 4.2-unstable Changeset 25099
Linux Dom0 Kernel: 3.5.4 (I compiled it from sources)

Attached in this email are Xen VGA Passthrough configuration files and 
scripts I have configured for Frank Lyon's Xen VGA Passthrough server.

Reference guides/tutorials followed in setting up Frank Lyon's Xen VGA 
Passthrough server (hosted on Xen Wiki):

(1) 
http://wiki.xen.org/wiki/Building_and_Installing_Xen_4.x_and_Linux_Kernel_3.x_on_Ubuntu_and_Debian_Linux

(2) 
http://wiki.xen.org/wiki/Xen_VGA_Passthrough_to_Windows_8_with_Xen_4.2-unstable

The above two are guides/tutorials/HowTo/documentation I have written 
for (1) building and installing Xen 4.x and Linux Kernel 3.x on Ubuntu 
and Debian Linux and (2) Xen VGA Passthrough.

Dear Jean David Techer,

Now I have 100% success in getting Xen VGA Passthrough to work in Frank 
Lyon's Xen VGA Passthrough server, with Xen VGA Passthrough patches 
hosted at your personal website. The display adapter which was 100% 
successfully passed through in Frank Lyon's example is a NVIDIA Quadro 
6000. I still have no idea why I have PARTIAL (less than 100%) success 
with Xen VGA Passthrough with my own NVIDIA Geforce 8400 GS VGA card. As 
I have told you before, there is a yellow exclamation mark with my 
NVIDIA Geforce 8400 GS in Device Manager in Windows XP and Windows 8 HVM 
domUs. I am so totally astonished and elated and happy that I could get 
100% success in Xen VGA Passthrough with Frank Lyon's Xen VGA 
Passthrough server. The Xen VGA Passthrough patches hosted at your 
personal website definitely works. Thumbs up David Techer! There is 
***ABSOLUTELY NO*** yellow exclamation mark with Frank Lyon's NVIDIA 
Quadro 6000 in Device Manager in Windows 7 and Windows 8 HVM domUs. I 
really wondered what's the problem with my case. I could get somebody 
else's Xen VGA Passthrough to work but yet I could not get mine to work 
100%. Perhaps I should get another NVIDIA vga card to try out VGA 
Passthrough.

Dear All,

Although I have 100% success in Xen VGA Passthrough in Frank Lyon's 
case, it was done with Xen 4.2-unstable Changeset 25099. I couldn't get 
Xen VGA Passthrough to work with Xen 4.3-unstable. Perhaps the Xen 
developers could look into this problem?

In addition, I cannot passthrough TWO NVIDIA Quadro 6000 to a single 
Windows 7 or Windows 8 HVM guest. Anybody knows how I could passthrough 
two GPUs to a single HVM? Windows 7 and Windows 8 HVM guests would go 
haywire with the 2nd NVIDIA Quadro 6000 plugged in. The 2nd NVIDIA 
Quadro 6000 needs to be unplugged. Anybody knows why?

Please advise. Thank you very much for your kind attention.

-- 
Yours sincerely,
Mr. Teo En Ming (Zhang Enming)
Singapore

--------------020803020300030807030301
Content-Type: text/plain;
 name="40_custom"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename="40_custom"

#!/bin/sh
exec tail -n +3 $0
# This file provides an easy way to add custom menu entries.  Simply type the
# menu entries you want to add after this comment.  Be careful not to change
# the 'exec tail' line above.
menuentry 'Ubuntu 12.04 amd64 Release with Xen 4.3-unstable and Linux Kernel 3.5.4-xen-frank.lyon-sgp' --class gnu-linux --class gnu --class os {
recordfail
insmod part_msdos
insmod ext2
search --no-floppy --fs-uuid --set=root d5ec6b7f-e1db-4b46-b050-d0bd46403f59
set root='(hd0,msdos1)'
search --no-floppy --fs-uuid --set=root d5ec6b7f-e1db-4b46-b050-d0bd46403f59
multiboot /xen.gz
module /vmlinuz-3.5.4-xen-frank.lyon-sgp placeholder root=/dev/mapper/snow-root dom0_mem=1024 console=tty quiet splash vt.handoff=7 nomodeset
module /initrd.img-3.5.4-xen-frank.lyon-sgp
}

--------------020803020300030807030301
Content-Type: text/plain;
 name="dsdt.asl"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename="dsdt.asl"

/******************************************************************************
 * DSDT for Xen with Qemu device model
 *
 * Copyright (c) 2004, Intel Corporation.
 *
 * This program is free software; you can redistribute it and/or modify it
 * under the terms and conditions of the GNU General Public License,
 * version 2, as published by the Free Software Foundation.
 *
 * This program is distributed in the hope it will be useful, but WITHOUT
 * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
 * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
 * more details.
 *
 * You should have received a copy of the GNU General Public License along with
 * this program; if not, write to the Free Software Foundation, Inc., 59 Temple
 * Place - Suite 330, Boston, MA 02111-1307 USA.
 */

DefinitionBlock ("DSDT.aml", "DSDT", 2, "Xen", "HVM", 0)
{
    Name (\PMBS, 0x0C00)
    Name (\PMLN, 0x08)
    Name (\IOB1, 0x00)
    Name (\IOL1, 0x00)
    Name (\APCB, 0xFEC00000)
    Name (\APCL, 0x00010000)
    Name (\PUID, 0x00)

    /* _S3 and _S4 are in separate SSDTs */
    Name (\_S5, Package (0x04)
    {
        0x00,  /* PM1a_CNT.SLP_TYP */
        0x00,  /* PM1b_CNT.SLP_TYP */
        0x00,  /* reserved */
        0x00   /* reserved */
    })

    Name(PICD, 0)
    Method(_PIC, 1)
    {
        Store(Arg0, PICD) 
    }

    Scope (\_SB)
    {
       /* ACPI_INFO_PHYSICAL_ADDRESS == 0xFC000000 */
       OperationRegion(BIOS, SystemMemory, 0xFC000000, 24)
       Field(BIOS, ByteAcc, NoLock, Preserve) {
           UAR1, 1,
           UAR2, 1,
           LTP1, 1,
           HPET, 1,
           Offset(4),
           PMIN, 32,
           PLEN, 32,
           MSUA, 32, /* MADT checksum address */
           MAPA, 32, /* MADT LAPIC0 address */
           VGIA, 32  /* VM generation id address */
       }

        /* Fix HCT test for 0x400 pci memory:
         * - need to report low 640 MB mem as motherboard resource
         */
       Device(MEM0)
       {
           Name(_HID, EISAID("PNP0C02"))
           Name(_CRS, ResourceTemplate() {
               QWordMemory(
                    ResourceConsumer, PosDecode, MinFixed,
                    MaxFixed, Cacheable, ReadWrite,
                    0x00000000,
                    0x00000000,
                    0x0009ffff,
                    0x00000000,
                    0x000a0000)
           })
       }

       Device (PCI0)
       {
           Name (_HID, EisaId ("PNP0A03"))
           Name (_UID, 0x00)
           Name (_ADR, 0x00)
           Name (_BBN, 0x00)

           /* Make cirrues VGA S3 suspend/resume work in Windows XP/2003 */
           Device (VGA)
           {
               Name (_ADR, 0x00020000)

               Method (_S1D, 0, NotSerialized)
               {
                   Return (0x00)
               }
               Method (_S2D, 0, NotSerialized)
               {
                   Return (0x00)
               }
               Method (_S3D, 0, NotSerialized)
               {
                   Return (0x00)
               }
           }

           Method (_CRS, 0, NotSerialized)
           {
               Name (PRT0, ResourceTemplate ()
               {
                   /* bus number is from 0 - 255*/
                   WordBusNumber(
                        ResourceProducer, MinFixed, MaxFixed, SubDecode,
                        0x0000,
                        0x0000,
                        0x00FF,
                        0x0000,
                        0x0100)
                    IO (Decode16, 0x0CF8, 0x0CF8, 0x01, 0x08)
                    WordIO(
                        ResourceProducer, MinFixed, MaxFixed, PosDecode,
                        EntireRange,
                        0x0000,
                        0x0000,
                        0x0CF7,
                        0x0000,
                        0x0CF8)
                    WordIO(
                        ResourceProducer, MinFixed, MaxFixed, PosDecode,
                        EntireRange,
                        0x0000,
                        0x0D00,
                        0xFFFF,
                        0x0000,
                        0xF300)

                    /* reserve memory for pci devices */
                    DWordMemory(
                        ResourceProducer, PosDecode, MinFixed, MaxFixed,
                        Cacheable, ReadWrite,
                        0x00000000,
                        0x000A0000,
                        0x000BFFFF,
                        0x00000000,
                        0x00020000)

                    /* reserve MMIO BARs of gfx for 1:1 mapping */
                    DWordMemory(
                        ResourceProducer, PosDecode, MinFixed, MaxFixed,
                        Cacheable, ReadWrite,
                        0x00000000,
                        0xF8000000,
                        0xF9FFFFFF,
                        0x00000000,
                        0x02000000)

                    DWordMemory(
                        ResourceProducer, PosDecode, MinFixed, MaxFixed,
                        NonCacheable, ReadWrite,
                        0x00000000,
                        0xD8000000,
                        0xDFFFFFFF,
                        0x00000000,
                        0x08000000)

                    DWordMemory(
                        ResourceProducer, PosDecode, MinFixed, MaxFixed,
                        Cacheable, ReadWrite,
                        0x00000000,
                        0xD4000000,
                        0xD7FFFFFF,
                        0x00000000,
                        0x04000000)

                    DWordMemory(
                        ResourceProducer, PosDecode, MinFixed, MaxFixed,
                        Cacheable, ReadWrite,
                        0x00000000,
                        0xFB000000,
                        0xFB07FFFF,
                        0x00000000,
                        0x00080000,                        
			,, _Y01)
                })

                CreateDWordField(PRT0, \_SB.PCI0._CRS._Y01._MIN, MMIN)
                CreateDWordField(PRT0, \_SB.PCI0._CRS._Y01._MAX, MMAX)
                CreateDWordField(PRT0, \_SB.PCI0._CRS._Y01._LEN, MLEN)

                Store(\_SB.PMIN, MMIN)
                Store(\_SB.PLEN, MLEN)
                Add(MMIN, MLEN, MMAX)
                Subtract(MMAX, One, MMAX)

                Return (PRT0)
            }

            Device(HPET) {
                Name(_HID,  EISAID("PNP0103"))
                Name(_UID, 0)
                Method (_STA, 0, NotSerialized) {
                    If(LEqual(\_SB.HPET, 0)) {
                        Return(0x00)
                    } Else {
                        Return(0x0F)
                    }
                }
                Name(_CRS, ResourceTemplate() {
                    DWordMemory(
                        ResourceConsumer, PosDecode, MinFixed, MaxFixed,
                        NonCacheable, ReadWrite,
                        0x00000000,
                        0xFED00000,
                        0xFED003FF,
                        0x00000000,
                        0x00000400 /* 1K memory: FED00000 - FED003FF */
                    )
                })
            }

            Device (ISA)
            {
                Name (_ADR, 0x00010000) /* device 1, fn 0 */

                OperationRegion(PIRQ, PCI_Config, 0x60, 0x4)
                Scope(\) {
                    Field (\_SB.PCI0.ISA.PIRQ, ByteAcc, NoLock, Preserve) {
                        PIRA, 8,
                        PIRB, 8,
                        PIRC, 8,
                        PIRD, 8
                    }
                }
                Device (SYSR)
                {
                    Name (_HID, EisaId ("PNP0C02"))
                    Name (_UID, 0x01)
                    Name (CRS, ResourceTemplate ()
                    {
                        /* TODO: list hidden resources */
                        IO (Decode16, 0x0010, 0x0010, 0x00, 0x10)
                        IO (Decode16, 0x0022, 0x0022, 0x00, 0x0C)
                        IO (Decode16, 0x0030, 0x0030, 0x00, 0x10)
                        IO (Decode16, 0x0044, 0x0044, 0x00, 0x1C)
                        IO (Decode16, 0x0062, 0x0062, 0x00, 0x02)
                        IO (Decode16, 0x0065, 0x0065, 0x00, 0x0B)
                        IO (Decode16, 0x0072, 0x0072, 0x00, 0x0E)
                        IO (Decode16, 0x0080, 0x0080, 0x00, 0x01)
                        IO (Decode16, 0x0084, 0x0084, 0x00, 0x03)
                        IO (Decode16, 0x0088, 0x0088, 0x00, 0x01)
                        IO (Decode16, 0x008C, 0x008C, 0x00, 0x03)
                        IO (Decode16, 0x0090, 0x0090, 0x00, 0x10)
                        IO (Decode16, 0x00A2, 0x00A2, 0x00, 0x1C)
                        IO (Decode16, 0x00E0, 0x00E0, 0x00, 0x10)
                        IO (Decode16, 0x08A0, 0x08A0, 0x00, 0x04)
                        IO (Decode16, 0x0CC0, 0x0CC0, 0x00, 0x10)
                        IO (Decode16, 0x04D0, 0x04D0, 0x00, 0x02)
                    })
                    Method (_CRS, 0, NotSerialized)
                    {
                        Return (CRS)
                    }
                }

                Device (PIC)
                {
                    Name (_HID, EisaId ("PNP0000"))
                    Name (_CRS, ResourceTemplate ()
                    {
                        IO (Decode16, 0x0020, 0x0020, 0x01, 0x02)
                        IO (Decode16, 0x00A0, 0x00A0, 0x01, 0x02)
                        IRQNoFlags () {2}
                    })
                }

                Device (DMA0)
                {
                    Name (_HID, EisaId ("PNP0200"))
                    Name (_CRS, ResourceTemplate ()
                    {
                        DMA (Compatibility, BusMaster, Transfer8) {4}
                        IO (Decode16, 0x0000, 0x0000, 0x00, 0x10)
                        IO (Decode16, 0x0081, 0x0081, 0x00, 0x03)
                        IO (Decode16, 0x0087, 0x0087, 0x00, 0x01)
                        IO (Decode16, 0x0089, 0x0089, 0x00, 0x03)
                        IO (Decode16, 0x008F, 0x008F, 0x00, 0x01)
                        IO (Decode16, 0x00C0, 0x00C0, 0x00, 0x20)
                        IO (Decode16, 0x0480, 0x0480, 0x00, 0x10)
                    })
                }

                Device (TMR)
                {
                    Name (_HID, EisaId ("PNP0100"))
                    Name (_CRS, ResourceTemplate ()
                    {
                        IO (Decode16, 0x0040, 0x0040, 0x00, 0x04)
                        IRQNoFlags () {0}
                    })
                }

                Device (RTC)
                {
                    Name (_HID, EisaId ("PNP0B00"))
                    Name (_CRS, ResourceTemplate ()
                    {
                        IO (Decode16, 0x0070, 0x0070, 0x00, 0x02)
                        IRQNoFlags () {8}
                    })
                }

                Device (SPKR)
                {
                    Name (_HID, EisaId ("PNP0800"))
                    Name (_CRS, ResourceTemplate ()
                    {
                        IO (Decode16, 0x0061, 0x0061, 0x00, 0x01)
                    })
                }

                Device (PS2M)
                {
                    Name (_HID, EisaId ("PNP0F13"))
                    Name (_CID, 0x130FD041)
                    Method (_STA, 0, NotSerialized)
                    {
                        Return (0x0F)
                    }

                    Name (_CRS, ResourceTemplate ()
                    {
                        IRQNoFlags () {12}
                    })
                }

                Device (PS2K)
                {
                    Name (_HID, EisaId ("PNP0303"))
                    Name (_CID, 0x0B03D041)
                    Method (_STA, 0, NotSerialized)
                    {
                        Return (0x0F)
                    }

                    Name (_CRS, ResourceTemplate ()
                    {
                        IO (Decode16, 0x0060, 0x0060, 0x00, 0x01)
                        IO (Decode16, 0x0064, 0x0064, 0x00, 0x01)
                        IRQNoFlags () {1}
                    })
                }

                Device (FDC0)
                {
                    Name (_HID, EisaId ("PNP0700"))
                    Method (_STA, 0, NotSerialized)
                    {
                          Return (0x0F)
                    }

                    Name (_CRS, ResourceTemplate ()
                    {
                        IO (Decode16, 0x03F0, 0x03F0, 0x01, 0x06)
                        IO (Decode16, 0x03F7, 0x03F7, 0x01, 0x01)
                        IRQNoFlags () {6}
                        DMA (Compatibility, NotBusMaster, Transfer8) {2}
                    })
                }

                Device (UAR1)
                {
                    Name (_HID, EisaId ("PNP0501"))
                    Name (_UID, 0x01)
                    Method (_STA, 0, NotSerialized)
                    {
                        If(LEqual(\_SB.UAR1, 0)) {
                            Return(0x00)
                        } Else {
                            Return(0x0F)
                        }
                    }

                    Name (_CRS, ResourceTemplate()
                    {
                        IO (Decode16, 0x03F8, 0x03F8, 8, 8)
                        IRQNoFlags () {4}
                    })
                }

                Device (UAR2)
                {
                    Name (_HID, EisaId ("PNP0501"))
                    Name (_UID, 0x02)
                    Method (_STA, 0, NotSerialized)
                    {
                        If(LEqual(\_SB.UAR2, 0)) {
                            Return(0x00)
                        } Else {
                            Return(0x0F)
                        }
                    }

                    Name (_CRS, ResourceTemplate()
                    {
                        IO (Decode16, 0x02F8, 0x02F8, 8, 8)
                        IRQNoFlags () {3}
                    })
                }

                Device (LTP1)
                {
                    Name (_HID, EisaId ("PNP0400"))
                    Name (_UID, 0x02)
                    Method (_STA, 0, NotSerialized)
                    {
                        If(LEqual(\_SB.LTP1, 0)) {
                            Return(0x00)
                        } Else {
                            Return(0x0F)
                        }
                    }

                    Name (_CRS, ResourceTemplate()
                    {
                        IO (Decode16, 0x0378, 0x0378, 0x08, 0x08)
                        IRQNoFlags () {7}
                    })
                } 

                Device(VGID) {
                    Name(_HID, EisaID ("XEN0000"))
                    Name(_UID, 0x00)
                    Name(_CID, "VM_Gen_Counter")
                    Name(_DDN, "VM_Gen_Counter")
                    Method(_STA, 0, NotSerialized)
                    {
                        If(LEqual(\_SB.VGIA, 0x00000000)) {
                            Return(0x00)
                        } Else {
                            Return(0x0F)
                        }
                    }
                    Name(PKG, Package ()
                    {
                        0x00000000,
                        0x00000000
                    })
                    Method(ADDR, 0, NotSerialized)
                    {
                        Store(\_SB.VGIA, Index(PKG, 0))
                        Return(PKG)
                    }
                }
            }
        }
    }
}

--------------020803020300030807030301
Content-Type: text/plain;
 name="grub"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename="grub"

# If you change this file, run 'update-grub' afterwards to update
# /boot/grub/grub.cfg.
# For full documentation of the options in this file, see:
#   info -f grub -n 'Simple configuration'

GRUB_DEFAULT=13
#GRUB_HIDDEN_TIMEOUT=0
GRUB_HIDDEN_TIMEOUT_QUIET=true
GRUB_TIMEOUT=50
GRUB_DISTRIBUTOR=`lsb_release -i -s 2> /dev/null || echo Debian`
GRUB_CMDLINE_LINUX_DEFAULT=""
GRUB_CMDLINE_LINUX="nomodeset"

# Uncomment to enable BadRAM filtering, modify to suit your needs
# This works with Linux (no patch required) and with any kernel that obtains
# the memory map information from GRUB (GNU Mach, kernel of FreeBSD ...)
#GRUB_BADRAM="0x01234567,0xfefefefe,0x89abcdef,0xefefefef"

# Uncomment to disable graphical terminal (grub-pc only)
#GRUB_TERMINAL=console

# The resolution used on graphical terminal
# note that you can use only modes which your graphic card supports via VBE
# you can see them in real GRUB with the command `vbeinfo'
#GRUB_GFXMODE=640x480

# Uncomment if you don't want GRUB to pass "root=UUID=xxx" parameter to Linux
#GRUB_DISABLE_LINUX_UUID=true

# Uncomment to disable generation of recovery mode menu entries
#GRUB_DISABLE_RECOVERY="true"

# Uncomment to get a beep at grub start
#GRUB_INIT_TUNE="480 440 1"

--------------020803020300030807030301
Content-Type: text/plain;
 name="rc.local"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename="rc.local"

#!/bin/sh -e
#
# rc.local
#
# This script is executed at the end of each multiuser runlevel.
# Make sure that the script will "exit 0" on success or any other
# value on error.
#
# In order to enable or disable this script just change the execution
# bits.
#
# By default this script does nothing.

sudo ifconfig eth0 up
sudo route add default gw 192.168.25.1
sudo echo "nameserver 192.168.50.15" >> /etc/resolv.conf
sudo echo "nameserver 192.168.50.30" >> /etc/resolv.conf
exit 0

--------------020803020300030807030301
Content-Type: text/plain;
 name="start-windows"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename="start-windows"

#!/bin/sh
set -x
#
#Loads pci-stub kernel module
sudo modprobe pci-stub
#
#Passthrough NVIDIA Quadro 6000
# 
echo "Passthrough NVIDIA Quadro 6000 VGA card."
sudo chmod o+w /sys/bus/pci/drivers/pci-stub/new_id
sudo chmod o+w /sys/bus/pci/devices/0000:0d:00.0/driver/unbind
sudo chmod o+w /sys/bus/pci/drivers/pci-stub/bind
echo "10de 06d8" > /sys/bus/pci/drivers/pci-stub/new_id
echo "0000:0d:00.0" > /sys/bus/pci/devices/0000:0d:00.0/driver/unbind
echo "0000:0d:00.0" > /sys/bus/pci/drivers/pci-stub/bind
#
#Passthrough NVIDIA HD Audio Controller
# 
echo "Passthrough NVIDIA HD Audio Controller."
sudo chmod o+w /sys/bus/pci/drivers/pci-stub/new_id
sudo chmod o+w /sys/bus/pci/devices/0000:0d:00.1/driver/unbind
sudo chmod o+w /sys/bus/pci/drivers/pci-stub/bind
echo "10de 0be5" > /sys/bus/pci/drivers/pci-stub/new_id
echo "0000:0d:00.1" > /sys/bus/pci/devices/0000:0d:00.1/driver/unbind
echo "0000:0d:00.1" > /sys/bus/pci/drivers/pci-stub/bind
#
#Passthrough 2nd NVIDIA Quadro 6000
#
#echo "Passthrough 2nd NVIDIA Quadro 6000 VGA card."
#sudo chmod o+w /sys/bus/pci/drivers/pci-stub/new_id
#sudo chmod o+w /sys/bus/pci/devices/0000:1b:00.0/driver/unbind
#sudo chmod o+w /sys/bus/pci/drivers/pci-stub/bind
#echo "10de 06d8" > /sys/bus/pci/drivers/pci-stub/new_id
#echo "0000:1b:00.0" > /sys/bus/pci/devices/0000:1b:00.0/driver/unbind
#echo "0000:1b:00.0" > /sys/bus/pci/drivers/pci-stub/bind
#
#Passthrough 2nd NVIDIA HD Audio Controller
#
#echo "Passthrough 2nd NVIDIA HD Audio Controller."
#sudo chmod o+w /sys/bus/pci/drivers/pci-stub/new_id
#sudo chmod o+w /sys/bus/pci/devices/0000:1b:00.1/driver/unbind
#sudo chmod o+w /sys/bus/pci/drivers/pci-stub/bind
#echo "10de 0be5" > /sys/bus/pci/drivers/pci-stub/new_id
#echo "0000:1b:00.1" > /sys/bus/pci/devices/0000:1b:00.1/driver/unbind
#echo "0000:1b:00.1" > /sys/bus/pci/drivers/pci-stub/bind
#
#Passthrough USB 1.1 Controller #3
#
echo "Passthrough USB 1.1 Controller #3"
sudo chmod o+w /sys/bus/pci/drivers/pci-stub/new_id
sudo chmod o+w /sys/bus/pci/devices/0000:00:1d.2/driver/unbind
sudo chmod o+w /sys/bus/pci/drivers/pci-stub/bind
echo "8086 3a36" > /sys/bus/pci/drivers/pci-stub/new_id
echo "0000:00:1d.2" > /sys/bus/pci/devices/0000:00:1d.2/driver/unbind
echo "0000:00:1d.2" > /sys/bus/pci/drivers/pci-stub/bind
#
#Passthrough USB 1.1 Controller #4
#
echo "Passthrough USB 1.1 Controller #4"
sudo chmod o+w /sys/bus/pci/drivers/pci-stub/new_id
sudo chmod o+w /sys/bus/pci/devices/0000:00:1d.3/driver/unbind
sudo chmod o+w /sys/bus/pci/drivers/pci-stub/bind
echo "8086 3a39" > /sys/bus/pci/drivers/pci-stub/new_id
echo "0000:00:1d.3" > /sys/bus/pci/devices/0000:00:1d.3/driver/unbind
echo "0000:00:1d.3" > /sys/bus/pci/drivers/pci-stub/bind

#
#Wait for 10 seconds
#
sleep 10
#
#Start Windows HVM domU with VGA Passthrough
#
sudo xl create /etc/xen/Windows7
#sudo xl create /etc/xen/Windows8

--------------020803020300030807030301
Content-Type: text/plain;
 name="Windows7"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename="Windows7"

# XL domain configuration file for Windows 8 Consumer Preview 64-bit English HVM domU
# Please refer to "man xl.cfg" for further explanations.
# See also docs/misc/xl-network-configuration.markdown and
# docs/misc/xl-disk-configuration.txt
# Written by Teo En Ming (Zhang Enming)
# Email: teo.en.ming@gmail.com
# Mobile Phone: +65-8369-2618
# Country: Singapore
# Date: 18 Mar 2012 Sun
name="Windows8"
# Product Key: WJBRX-2N7B2-CCBF6-VPP97-R88XV
builder="hvm"
vcpus=2
memory=2048
on_poweroff="destroy"
on_reboot="restart"
on_crash="destroy"
disk=[ 'format=raw, vdev=hda, access=rw, target=/etc/xen/images/windows7.img', 'format=raw, vdev=hdc, access=ro, devtype=cdrom, target=/home/flyon/windows7.iso' ]
vif=[ 'bridge=eth0,type=ioemu,model=e1000' ]
#boot=[c|d|n]
# Selects the emulated virtual device to boot from. Options are hard disk (c), cd-rom (d) or network/PXE (n).
# Multiple options can be given and will be attempted in the order they are given. e.g. to boot from cd-rom
# but fallback to the hard disk you can give dc. The default is cd.
boot="dc"
acpi=1
#xen_platform_pci=1
#viridian=1
#stdvga=1

vnc=1
vnclisten="192.168.25.50"
vncdisplay=0
vncunused=1
vncpasswd=""
sdl=0
usb=1
# Passthrough the USB Keyboard
usbdevice = "host:04f2:0110"
# Passthrough the USB Optical Mouse
usbdevice = "host:046d:c03d"
# Enable Xen VGA Passthrough
gfx_passthru=1
# VGA Passthrough NVIDIA Quadro 6000 and PCI Passthrough NVIDIA HD Audio Controller, then 2nd NVIDIA Quadro 6000 and 2nd NVIDIA HD Audio Controller
#pci = [ '0d:00.0','0d:00.1','1b:00.0','1b:00.1' ]
# The last 2 entries are USB 1.1 controllers.
pci = [ '0d:00.0','0d:00.1','00:1d.2','00:1d.3' ]

# PCI Passthrough Intel HD Audio Controller.
#pci = [ '00:1b.0' ]
# PCI Passthrough all the USB Controllers.
# pci = [ '00:1a.0','00:1a.1','00:1a.2','00:1a.7','00:1d.0','00:1d.1','00:1d.2','00:1d.7' ]


--------------020803020300030807030301
Content-Type: text/plain;
 name="Windows8"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename="Windows8"

# XL domain configuration file for Windows 8 Consumer Preview 64-bit English HVM domU
# Please refer to "man xl.cfg" for further explanations.
# See also docs/misc/xl-network-configuration.markdown and
# docs/misc/xl-disk-configuration.txt
# Written by Teo En Ming (Zhang Enming)
# Email: teo.en.ming@gmail.com
# Mobile Phone: +65-8369-2618
# Country: Singapore
# Date: 18 Mar 2012 Sun
name="Windows8"
# Product Key: WJBRX-2N7B2-CCBF6-VPP97-R88XV
builder="hvm"
vcpus=2
memory=2048
on_poweroff="destroy"
on_reboot="restart"
on_crash="destroy"
disk=[ 'format=raw, vdev=hda, access=rw, target=/etc/xen/images/windows8.img', 'format=raw, vdev=hdc, access=ro, devtype=cdrom, target=/home/flyon/windows8.iso' ]
vif=[ 'bridge=eth0,type=ioemu,model=e1000' ]
#boot=[c|d|n]
# Selects the emulated virtual device to boot from. Options are hard disk (c), cd-rom (d) or network/PXE (n).
# Multiple options can be given and will be attempted in the order they are given. e.g. to boot from cd-rom
# but fallback to the hard disk you can give dc. The default is cd.
boot="dc"
acpi=1
#xen_platform_pci=1
#viridian=1
#stdvga=1

vnc=1
vnclisten="192.168.25.50"
vncdisplay=0
vncunused=1
vncpasswd=""
sdl=0
usb=1
# Passthrough the USB Keyboard
usbdevice = "host:04f2:0110"
# Passthrough the USB Optical Mouse
usbdevice = "host:046d:c03d"
# Enable Xen VGA Passthrough
gfx_passthru=1
# VGA Passthrough NVIDIA Quadro 6000 and PCI Passthrough NVIDIA HD Audio Controller, then 2nd NVIDIA Quadro 6000 and 2nd NVIDIA HD Audio Controller
#pci = [ '0d:00.0','0d:00.1','1b:00.0','1b:00.1' ]
pci = [ '0d:00.0','0d:00.1' ]

# PCI Passthrough Intel HD Audio Controller.
#pci = [ '00:1b.0' ]
# PCI Passthrough all the USB Controllers.
# pci = [ '00:1a.0','00:1a.1','00:1a.2','00:1a.7','00:1d.0','00:1d.1','00:1d.2','00:1d.7' ]


--------------020803020300030807030301
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--------------020803020300030807030301--


From xen-devel-bounces@lists.xen.org Mon Sep 24 12:05:39 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Sep 2012 12:05:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TG7Pj-00067l-Dz; Mon, 24 Sep 2012 12:05: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 1TG7Ph-00067Z-Dy
	for xen-devel@lists.xen.org; Mon, 24 Sep 2012 12:05:25 +0000
Received: from [85.158.138.51:3445] by server-13.bemta-3.messagelabs.com id
	3D/BC-01606-38C40605; Mon, 24 Sep 2012 12:05:23 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1348488323!31731768!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7478 invoked from network); 24 Sep 2012 12:05:23 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-11.tower-174.messagelabs.com with SMTP;
	24 Sep 2012 12:05:23 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 24 Sep 2012 13:05:23 +0100
Message-Id: <506068A0020000780009D519@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 24 Sep 2012 13:05:20 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ben Guthro" <ben@guthro.net>,
	"Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>
References: <CAOvdn6XKPOMNn6AjuYvZvPXRRJffN3po5GXe1Yh1-m0hisMK_w@mail.gmail.com>
	<CC8273A0.4C9DD%keir@xen.org>
	<50605E9A020000780009D486@nat28.tlf.novell.com>
	<CAOvdn6XmB6rj3_QVU+59V8p24Y5G47AWxVEM=id02JWXkuhibQ@mail.gmail.com>
	<5060640B020000780009D4D2@nat28.tlf.novell.com>
	<CAOvdn6XLy8zR2rb2MEyi2aT9LQiFvFLY_H02p181mTsVLVTZkw@mail.gmail.com>
In-Reply-To: <CAOvdn6XLy8zR2rb2MEyi2aT9LQiFvFLY_H02p181mTsVLVTZkw@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Keir Fraser <keir@xen.org>, john.baboval@citrix.com,
	Thomas Goetz <thomas.goetz@citrix.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen4.2 S3 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 24.09.12 at 13:54, Ben Guthro <ben@guthro.net> wrote:
> I see - Konrad - do you have a changeset I can look for with the features
> Jan describes?

Alternatively you could also stick a wbinvd() in the two possibly
relevant places...

Jan

> On Mon, Sep 24, 2012 at 7:45 AM, Jan Beulich <JBeulich@suse.com> wrote:
> 
>> >>> On 24.09.12 at 13:25, Ben Guthro <ben@guthro.net> wrote:
>> > It is an older system (Core2) - so it may be using the default mechanism,
>> > but I'd have to go dig up some processor docs to be sure.
>>
>> This is not just a matter of what the CPU supports, but also what
>> info gets passed down from Dom0 - if e.g. your kernel doesn't
>> have Konrad's P-/C-state patches, then there's no way for Xen to
>> use any of the advanced methods.
>>
>> Jan
>>
>>




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 24 12:05:39 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Sep 2012 12:05:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TG7Pj-00067l-Dz; Mon, 24 Sep 2012 12:05: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 1TG7Ph-00067Z-Dy
	for xen-devel@lists.xen.org; Mon, 24 Sep 2012 12:05:25 +0000
Received: from [85.158.138.51:3445] by server-13.bemta-3.messagelabs.com id
	3D/BC-01606-38C40605; Mon, 24 Sep 2012 12:05:23 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1348488323!31731768!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7478 invoked from network); 24 Sep 2012 12:05:23 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-11.tower-174.messagelabs.com with SMTP;
	24 Sep 2012 12:05:23 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 24 Sep 2012 13:05:23 +0100
Message-Id: <506068A0020000780009D519@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 24 Sep 2012 13:05:20 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ben Guthro" <ben@guthro.net>,
	"Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>
References: <CAOvdn6XKPOMNn6AjuYvZvPXRRJffN3po5GXe1Yh1-m0hisMK_w@mail.gmail.com>
	<CC8273A0.4C9DD%keir@xen.org>
	<50605E9A020000780009D486@nat28.tlf.novell.com>
	<CAOvdn6XmB6rj3_QVU+59V8p24Y5G47AWxVEM=id02JWXkuhibQ@mail.gmail.com>
	<5060640B020000780009D4D2@nat28.tlf.novell.com>
	<CAOvdn6XLy8zR2rb2MEyi2aT9LQiFvFLY_H02p181mTsVLVTZkw@mail.gmail.com>
In-Reply-To: <CAOvdn6XLy8zR2rb2MEyi2aT9LQiFvFLY_H02p181mTsVLVTZkw@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Keir Fraser <keir@xen.org>, john.baboval@citrix.com,
	Thomas Goetz <thomas.goetz@citrix.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen4.2 S3 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 24.09.12 at 13:54, Ben Guthro <ben@guthro.net> wrote:
> I see - Konrad - do you have a changeset I can look for with the features
> Jan describes?

Alternatively you could also stick a wbinvd() in the two possibly
relevant places...

Jan

> On Mon, Sep 24, 2012 at 7:45 AM, Jan Beulich <JBeulich@suse.com> wrote:
> 
>> >>> On 24.09.12 at 13:25, Ben Guthro <ben@guthro.net> wrote:
>> > It is an older system (Core2) - so it may be using the default mechanism,
>> > but I'd have to go dig up some processor docs to be sure.
>>
>> This is not just a matter of what the CPU supports, but also what
>> info gets passed down from Dom0 - if e.g. your kernel doesn't
>> have Konrad's P-/C-state patches, then there's no way for Xen to
>> use any of the advanced methods.
>>
>> Jan
>>
>>




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 24 12:11:31 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Sep 2012 12:11:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TG7VO-0006Jo-7J; Mon, 24 Sep 2012 12:11:18 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1TG7VM-0006JZ-SD
	for Xen-devel@lists.xensource.com; Mon, 24 Sep 2012 12:11:17 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1348488491!11572617!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTA4NDk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19591 invoked from network); 24 Sep 2012 12:08:12 -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;
	24 Sep 2012 12:08:12 -0000
X-IronPort-AV: E=Sophos;i="4.80,474,1344211200"; d="scan'208";a="14722324"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Sep 2012 12:08: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.279.1; Mon, 24 Sep 2012 13:08:11 +0100
Date: Mon, 24 Sep 2012 13:07: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: <20120921121659.5a723de9@mantra.us.oracle.com>
Message-ID: <alpine.DEB.2.02.1209241257440.29232@kaball.uk.xensource.com>
References: <20120921121659.5a723de9@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>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH v1 3/8]: PVH startup changes (enlighten.c)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 21 Sep 2012, Mukesh Rathor wrote:
> ---
>  arch/x86/xen/enlighten.c |   99 ++++++++++++++++++++++++++++++++++++---------
>  1 files changed, 79 insertions(+), 20 deletions(-)
> 
> diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
> index bf4bda6..98f1798 100644
> --- a/arch/x86/xen/enlighten.c
> +++ b/arch/x86/xen/enlighten.c
> @@ -45,6 +45,7 @@
>  #include <xen/hvm.h>
>  #include <xen/hvc-console.h>
>  #include <xen/acpi.h>
> +#include <xen/features.h>
>  
>  #include <asm/paravirt.h>
>  #include <asm/apic.h>
> @@ -105,6 +106,9 @@ RESERVE_BRK(shared_info_page_brk, PAGE_SIZE);
>  __read_mostly int xen_have_vector_callback;
>  EXPORT_SYMBOL_GPL(xen_have_vector_callback);
>  
> +#define xen_pvh_domain() (xen_pv_domain() && \
> +			  xen_feature(XENFEAT_auto_translated_physmap) && \
> +			  xen_have_vector_callback)
>  /*
>   * Point at some empty memory to start with. We map the real shared_info
>   * page as soon as fixmap is up and running.
> @@ -139,6 +143,8 @@ struct tls_descs {
>   */
>  static DEFINE_PER_CPU(struct tls_descs, shadow_tls_desc);
>  
> +static void __init xen_hvm_init_shared_info(void);
> +
>  static void clamp_max_cpus(void)
>  {
>  #ifdef CONFIG_SMP
> @@ -217,8 +223,9 @@ static void __init xen_banner(void)
>  	struct xen_extraversion extra;
>  	HYPERVISOR_xen_version(XENVER_extraversion, &extra);
>  
> -	printk(KERN_INFO "Booting paravirtualized kernel on %s\n",
> -	       pv_info.name);
> +	printk(KERN_INFO "Booting paravirtualized kernel %son %s\n",
> +		xen_feature(XENFEAT_auto_translated_physmap) ?
> +			"with PVH extensions " : "", pv_info.name);
>  	printk(KERN_INFO "Xen version: %d.%d%s%s\n",
>  	       version >> 16, version & 0xffff, extra.extraversion,
>  	       xen_feature(XENFEAT_mmu_pt_update_preserve_ad) ? " (preserve-AD)" : "");
> @@ -271,12 +278,15 @@ static void xen_cpuid(unsigned int *ax, unsigned int *bx,
>  		break;
>  	}
>  
> -	asm(XEN_EMULATE_PREFIX "cpuid"
> -		: "=a" (*ax),
> -		  "=b" (*bx),
> -		  "=c" (*cx),
> -		  "=d" (*dx)
> -		: "0" (*ax), "2" (*cx));
> +	if (xen_pvh_domain())
> +		native_cpuid(ax, bx, cx, dx);
> +	else
> +		asm(XEN_EMULATE_PREFIX "cpuid"
> +			: "=a" (*ax),
> +			"=b" (*bx),
> +			"=c" (*cx),
> +			"=d" (*dx)
> +			: "0" (*ax), "2" (*cx));

can't we just set the cpuid pvop to native_cpuid?


>  	*bx &= maskebx;
>  	*cx &= maskecx;
> @@ -1034,6 +1044,10 @@ static int xen_write_msr_safe(unsigned int msr, unsigned low, unsigned high)
>  
>  void xen_setup_shared_info(void)
>  {
> +	/* do later in xen_pvh_guest_init() when extend_brk is properly setup*/

Which one is the function that is going to get called later to do the
initialization? It cannot be this one because it would still return
immediately.


> +	if (xen_pvh_domain() && xen_initial_domain())
> +		return;
> +
>  	if (!xen_feature(XENFEAT_auto_translated_physmap)) {
>  		set_fixmap(FIX_PARAVIRT_BOOTMAP,
>  			   xen_start_info->shared_info);
>
> @@ -1044,6 +1058,10 @@ void xen_setup_shared_info(void)
>  		HYPERVISOR_shared_info =
>  			(struct shared_info *)__va(xen_start_info->shared_info);
>  
> +	/* PVH TBD/FIXME: vcpu info placement in phase 2 */
> +	if (xen_pvh_domain())
> +		return;

It seems that if xen_initial_domain we always skip the initialization
while if !xen_initial_domain we only initialize HYPERVISOR_shared_info.
I don't understand why we have this difference.

Also it might be worth refactoring xen_setup_shared_info moving out the
call to xen_setup_vcpu_info_placement and xen_setup_mfn_list_list in
order to avoid all these

if ([!]xen_pvh_domain())
    return;

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 24 12:11:31 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Sep 2012 12:11:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TG7VO-0006Jo-7J; Mon, 24 Sep 2012 12:11:18 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1TG7VM-0006JZ-SD
	for Xen-devel@lists.xensource.com; Mon, 24 Sep 2012 12:11:17 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1348488491!11572617!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTA4NDk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19591 invoked from network); 24 Sep 2012 12:08:12 -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;
	24 Sep 2012 12:08:12 -0000
X-IronPort-AV: E=Sophos;i="4.80,474,1344211200"; d="scan'208";a="14722324"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Sep 2012 12:08: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.279.1; Mon, 24 Sep 2012 13:08:11 +0100
Date: Mon, 24 Sep 2012 13:07: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: <20120921121659.5a723de9@mantra.us.oracle.com>
Message-ID: <alpine.DEB.2.02.1209241257440.29232@kaball.uk.xensource.com>
References: <20120921121659.5a723de9@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>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH v1 3/8]: PVH startup changes (enlighten.c)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 21 Sep 2012, Mukesh Rathor wrote:
> ---
>  arch/x86/xen/enlighten.c |   99 ++++++++++++++++++++++++++++++++++++---------
>  1 files changed, 79 insertions(+), 20 deletions(-)
> 
> diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
> index bf4bda6..98f1798 100644
> --- a/arch/x86/xen/enlighten.c
> +++ b/arch/x86/xen/enlighten.c
> @@ -45,6 +45,7 @@
>  #include <xen/hvm.h>
>  #include <xen/hvc-console.h>
>  #include <xen/acpi.h>
> +#include <xen/features.h>
>  
>  #include <asm/paravirt.h>
>  #include <asm/apic.h>
> @@ -105,6 +106,9 @@ RESERVE_BRK(shared_info_page_brk, PAGE_SIZE);
>  __read_mostly int xen_have_vector_callback;
>  EXPORT_SYMBOL_GPL(xen_have_vector_callback);
>  
> +#define xen_pvh_domain() (xen_pv_domain() && \
> +			  xen_feature(XENFEAT_auto_translated_physmap) && \
> +			  xen_have_vector_callback)
>  /*
>   * Point at some empty memory to start with. We map the real shared_info
>   * page as soon as fixmap is up and running.
> @@ -139,6 +143,8 @@ struct tls_descs {
>   */
>  static DEFINE_PER_CPU(struct tls_descs, shadow_tls_desc);
>  
> +static void __init xen_hvm_init_shared_info(void);
> +
>  static void clamp_max_cpus(void)
>  {
>  #ifdef CONFIG_SMP
> @@ -217,8 +223,9 @@ static void __init xen_banner(void)
>  	struct xen_extraversion extra;
>  	HYPERVISOR_xen_version(XENVER_extraversion, &extra);
>  
> -	printk(KERN_INFO "Booting paravirtualized kernel on %s\n",
> -	       pv_info.name);
> +	printk(KERN_INFO "Booting paravirtualized kernel %son %s\n",
> +		xen_feature(XENFEAT_auto_translated_physmap) ?
> +			"with PVH extensions " : "", pv_info.name);
>  	printk(KERN_INFO "Xen version: %d.%d%s%s\n",
>  	       version >> 16, version & 0xffff, extra.extraversion,
>  	       xen_feature(XENFEAT_mmu_pt_update_preserve_ad) ? " (preserve-AD)" : "");
> @@ -271,12 +278,15 @@ static void xen_cpuid(unsigned int *ax, unsigned int *bx,
>  		break;
>  	}
>  
> -	asm(XEN_EMULATE_PREFIX "cpuid"
> -		: "=a" (*ax),
> -		  "=b" (*bx),
> -		  "=c" (*cx),
> -		  "=d" (*dx)
> -		: "0" (*ax), "2" (*cx));
> +	if (xen_pvh_domain())
> +		native_cpuid(ax, bx, cx, dx);
> +	else
> +		asm(XEN_EMULATE_PREFIX "cpuid"
> +			: "=a" (*ax),
> +			"=b" (*bx),
> +			"=c" (*cx),
> +			"=d" (*dx)
> +			: "0" (*ax), "2" (*cx));

can't we just set the cpuid pvop to native_cpuid?


>  	*bx &= maskebx;
>  	*cx &= maskecx;
> @@ -1034,6 +1044,10 @@ static int xen_write_msr_safe(unsigned int msr, unsigned low, unsigned high)
>  
>  void xen_setup_shared_info(void)
>  {
> +	/* do later in xen_pvh_guest_init() when extend_brk is properly setup*/

Which one is the function that is going to get called later to do the
initialization? It cannot be this one because it would still return
immediately.


> +	if (xen_pvh_domain() && xen_initial_domain())
> +		return;
> +
>  	if (!xen_feature(XENFEAT_auto_translated_physmap)) {
>  		set_fixmap(FIX_PARAVIRT_BOOTMAP,
>  			   xen_start_info->shared_info);
>
> @@ -1044,6 +1058,10 @@ void xen_setup_shared_info(void)
>  		HYPERVISOR_shared_info =
>  			(struct shared_info *)__va(xen_start_info->shared_info);
>  
> +	/* PVH TBD/FIXME: vcpu info placement in phase 2 */
> +	if (xen_pvh_domain())
> +		return;

It seems that if xen_initial_domain we always skip the initialization
while if !xen_initial_domain we only initialize HYPERVISOR_shared_info.
I don't understand why we have this difference.

Also it might be worth refactoring xen_setup_shared_info moving out the
call to xen_setup_vcpu_info_placement and xen_setup_mfn_list_list in
order to avoid all these

if ([!]xen_pvh_domain())
    return;

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 24 12:15:52 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Sep 2012 12: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 1TG7Zc-0006Ts-T9; Mon, 24 Sep 2012 12:15:40 +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 1TG7Zb-0006Tl-De
	for Xen-devel@lists.xensource.com; Mon, 24 Sep 2012 12:15:39 +0000
Received: from [85.158.139.83:55562] by server-14.bemta-5.messagelabs.com id
	5E/8C-05772-AEE40605; Mon, 24 Sep 2012 12:15:38 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1348488937!31845499!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTA4NDk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11211 invoked from network); 24 Sep 2012 12:15: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;
	24 Sep 2012 12:15:37 -0000
X-IronPort-AV: E=Sophos;i="4.80,474,1344211200"; d="scan'208";a="14722528"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Sep 2012 12:15: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.279.1; Mon, 24 Sep 2012 13:15:37 +0100
Date: Mon, 24 Sep 2012 13:14:45 +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: <20120921121752.5fa80b35@mantra.us.oracle.com>
Message-ID: <alpine.DEB.2.02.1209241310380.29232@kaball.uk.xensource.com>
References: <20120921121752.5fa80b35@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>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH v1 4/8]: PVH setup changes...
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 21 Sep 2012, Mukesh Rathor wrote:
> @@ -500,10 +527,9 @@ void __cpuinit xen_enable_syscall(void)
>  #endif /* CONFIG_X86_64 */
>  }
>  
> -void __init xen_arch_setup(void)
> +/* Non auto translated PV domain, ie, it's not PVH. */
> +static __init void inline xen_non_pvh_arch_setup(void)
>  {
> -	xen_panic_handler_init();
> -
>  	HYPERVISOR_vm_assist(VMASST_CMD_enable, VMASST_TYPE_4gb_segments);
>  	HYPERVISOR_vm_assist(VMASST_CMD_enable, VMASST_TYPE_writable_pagetables);
>  
> @@ -517,6 +543,15 @@ void __init xen_arch_setup(void)
>  
>  	xen_enable_sysenter();
>  	xen_enable_syscall();
> +}
> +
> +/* This function not called for HVM domain */
> +void __init xen_arch_setup(void)
> +{
> +	xen_panic_handler_init();
> +
> +	if (!xen_feature(XENFEAT_auto_translated_physmap))
> +		xen_non_pvh_arch_setup();
>  
>  #ifdef CONFIG_ACPI
>  	if (!(xen_start_info->flags & SIF_INITDOMAIN)) {
 
IMHO having a xen_non_pvh_arch_setup function is less intuitive
than just wrapping all that code around an

if (!xen_feature(XENFEAT_auto_translated_physmap)) {


Or at least you could name the function xen_pvmmu_arch_setup.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 24 12:15:52 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Sep 2012 12: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 1TG7Zc-0006Ts-T9; Mon, 24 Sep 2012 12:15:40 +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 1TG7Zb-0006Tl-De
	for Xen-devel@lists.xensource.com; Mon, 24 Sep 2012 12:15:39 +0000
Received: from [85.158.139.83:55562] by server-14.bemta-5.messagelabs.com id
	5E/8C-05772-AEE40605; Mon, 24 Sep 2012 12:15:38 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1348488937!31845499!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTA4NDk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11211 invoked from network); 24 Sep 2012 12:15: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;
	24 Sep 2012 12:15:37 -0000
X-IronPort-AV: E=Sophos;i="4.80,474,1344211200"; d="scan'208";a="14722528"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Sep 2012 12:15: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.279.1; Mon, 24 Sep 2012 13:15:37 +0100
Date: Mon, 24 Sep 2012 13:14:45 +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: <20120921121752.5fa80b35@mantra.us.oracle.com>
Message-ID: <alpine.DEB.2.02.1209241310380.29232@kaball.uk.xensource.com>
References: <20120921121752.5fa80b35@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>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH v1 4/8]: PVH setup changes...
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 21 Sep 2012, Mukesh Rathor wrote:
> @@ -500,10 +527,9 @@ void __cpuinit xen_enable_syscall(void)
>  #endif /* CONFIG_X86_64 */
>  }
>  
> -void __init xen_arch_setup(void)
> +/* Non auto translated PV domain, ie, it's not PVH. */
> +static __init void inline xen_non_pvh_arch_setup(void)
>  {
> -	xen_panic_handler_init();
> -
>  	HYPERVISOR_vm_assist(VMASST_CMD_enable, VMASST_TYPE_4gb_segments);
>  	HYPERVISOR_vm_assist(VMASST_CMD_enable, VMASST_TYPE_writable_pagetables);
>  
> @@ -517,6 +543,15 @@ void __init xen_arch_setup(void)
>  
>  	xen_enable_sysenter();
>  	xen_enable_syscall();
> +}
> +
> +/* This function not called for HVM domain */
> +void __init xen_arch_setup(void)
> +{
> +	xen_panic_handler_init();
> +
> +	if (!xen_feature(XENFEAT_auto_translated_physmap))
> +		xen_non_pvh_arch_setup();
>  
>  #ifdef CONFIG_ACPI
>  	if (!(xen_start_info->flags & SIF_INITDOMAIN)) {
 
IMHO having a xen_non_pvh_arch_setup function is less intuitive
than just wrapping all that code around an

if (!xen_feature(XENFEAT_auto_translated_physmap)) {


Or at least you could name the function xen_pvmmu_arch_setup.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 24 12:17:46 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Sep 2012 12:17:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TG7bT-0006aX-Co; Mon, 24 Sep 2012 12:17: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 1TG7bR-0006aI-8H
	for Xen-devel@lists.xensource.com; Mon, 24 Sep 2012 12:17:33 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1348488992!11573400!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTA4NDk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7130 invoked from network); 24 Sep 2012 12:16:32 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Sep 2012 12:16:32 -0000
X-IronPort-AV: E=Sophos;i="4.80,474,1344211200"; d="scan'208";a="14722562"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Sep 2012 12:16: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.279.1;
	Mon, 24 Sep 2012 13:16:32 +0100
Message-ID: <1348488991.3452.69.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Date: Mon, 24 Sep 2012 13:16:31 +0100
In-Reply-To: <alpine.DEB.2.02.1209241228460.29232@kaball.uk.xensource.com>
References: <20120921121556.1a0ea8af@mantra.us.oracle.com>
	<alpine.DEB.2.02.1209241228460.29232@kaball.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH v1 2/8]: PVH mmu changes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2012-09-24 at 12:55 +0100, Stefano Stabellini wrote:
> There are few code style issues on this patch, I suggest you run it
> through scripts/checkpatch.pl, it should be able to catch all these
> errors.

It would also be nice to starting having some changelogs entries for
these patches for the next posting. There's a lot of complex stuff going
on here.

> > @@ -2371,3 +2518,26 @@ out:
> >  	return err;
> >  }
> >  EXPORT_SYMBOL_GPL(xen_remap_domain_mfn_range);
> > +
> > +/* Returns: Number of pages unmapped */
> > +int xen_unmap_domain_mfn_range(struct vm_area_struct *vma,
> > +			       struct xen_pvh_pfn_info *pvhp)
> > +{
> > +	int count = 0;
> > +
> > +	if (!pvhp || !xen_feature(XENFEAT_auto_translated_physmap))
> > +		return 0;
> > +
> > +	while (pvhp->pi_next_todo--) {
> > +		unsigned long pfn;
> > +
> > +		/* the mmu has already cleaned up the process mmu resources at
> > +		 * this point (lookup_address will return NULL). */
> > +		pfn = page_to_pfn(pvhp->pi_paga[pvhp->pi_next_todo]);
> > +		pvh_rem_xen_p2m(pfn, 1);
> > +		count++;
> > +	}
> > +	flush_tlb_all();
> > +	return count;
> 
> Who is going to remove the corresponding mapping from the vma?
> Also we might be able to replace the flush_tlb_all with a
> flush_tlb_range.

I'm not convinced that a guest level TLB flush is either necessary or
sufficient here. What we are doing is removing entries from the P2M
which means that we need to do the appropriate HAP flush in the
hypervisor, which must necessarily invalidate any stage 1 mappings which
this flush might also touch (i.e. the HAP flush must be a super set of
this flush).

Without the HAP flush in the hypervisor you risk guests being able to
see old p2m mappings via the TLB entries which is a security issue
AFAICT.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 24 12:17:46 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Sep 2012 12:17:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TG7bT-0006aX-Co; Mon, 24 Sep 2012 12:17: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 1TG7bR-0006aI-8H
	for Xen-devel@lists.xensource.com; Mon, 24 Sep 2012 12:17:33 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1348488992!11573400!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTA4NDk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7130 invoked from network); 24 Sep 2012 12:16:32 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Sep 2012 12:16:32 -0000
X-IronPort-AV: E=Sophos;i="4.80,474,1344211200"; d="scan'208";a="14722562"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Sep 2012 12:16: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.279.1;
	Mon, 24 Sep 2012 13:16:32 +0100
Message-ID: <1348488991.3452.69.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Date: Mon, 24 Sep 2012 13:16:31 +0100
In-Reply-To: <alpine.DEB.2.02.1209241228460.29232@kaball.uk.xensource.com>
References: <20120921121556.1a0ea8af@mantra.us.oracle.com>
	<alpine.DEB.2.02.1209241228460.29232@kaball.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH v1 2/8]: PVH mmu changes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2012-09-24 at 12:55 +0100, Stefano Stabellini wrote:
> There are few code style issues on this patch, I suggest you run it
> through scripts/checkpatch.pl, it should be able to catch all these
> errors.

It would also be nice to starting having some changelogs entries for
these patches for the next posting. There's a lot of complex stuff going
on here.

> > @@ -2371,3 +2518,26 @@ out:
> >  	return err;
> >  }
> >  EXPORT_SYMBOL_GPL(xen_remap_domain_mfn_range);
> > +
> > +/* Returns: Number of pages unmapped */
> > +int xen_unmap_domain_mfn_range(struct vm_area_struct *vma,
> > +			       struct xen_pvh_pfn_info *pvhp)
> > +{
> > +	int count = 0;
> > +
> > +	if (!pvhp || !xen_feature(XENFEAT_auto_translated_physmap))
> > +		return 0;
> > +
> > +	while (pvhp->pi_next_todo--) {
> > +		unsigned long pfn;
> > +
> > +		/* the mmu has already cleaned up the process mmu resources at
> > +		 * this point (lookup_address will return NULL). */
> > +		pfn = page_to_pfn(pvhp->pi_paga[pvhp->pi_next_todo]);
> > +		pvh_rem_xen_p2m(pfn, 1);
> > +		count++;
> > +	}
> > +	flush_tlb_all();
> > +	return count;
> 
> Who is going to remove the corresponding mapping from the vma?
> Also we might be able to replace the flush_tlb_all with a
> flush_tlb_range.

I'm not convinced that a guest level TLB flush is either necessary or
sufficient here. What we are doing is removing entries from the P2M
which means that we need to do the appropriate HAP flush in the
hypervisor, which must necessarily invalidate any stage 1 mappings which
this flush might also touch (i.e. the HAP flush must be a super set of
this flush).

Without the HAP flush in the hypervisor you risk guests being able to
see old p2m mappings via the TLB entries which is a security issue
AFAICT.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 24 12:17:50 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Sep 2012 12:17:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TG7bT-0006ae-Oi; Mon, 24 Sep 2012 12:17:35 +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 1TG7bS-0006aS-A1
	for xen-devel@lists.xensource.com; Mon, 24 Sep 2012 12:17:34 +0000
Received: from [85.158.139.211:29184] by server-4.bemta-5.messagelabs.com id
	9D/BF-20767-D5F40605; Mon, 24 Sep 2012 12:17:33 +0000
X-Env-Sender: Christoph.Egger@amd.com
X-Msg-Ref: server-12.tower-206.messagelabs.com!1348489051!18730574!1
X-Originating-IP: [216.32.181.184]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19935 invoked from network); 24 Sep 2012 12:17:32 -0000
Received: from ch1ehsobe004.messaging.microsoft.com (HELO
	ch1outboundpool.messaging.microsoft.com) (216.32.181.184)
	by server-12.tower-206.messagelabs.com with AES128-SHA encrypted SMTP;
	24 Sep 2012 12:17:32 -0000
Received: from mail145-ch1-R.bigfish.com (10.43.68.247) by
	CH1EHSOBE008.bigfish.com (10.43.70.58) with Microsoft SMTP Server id
	14.1.225.23; Mon, 24 Sep 2012 12:17:31 +0000
Received: from mail145-ch1 (localhost [127.0.0.1])	by
	mail145-ch1-R.bigfish.com (Postfix) with ESMTP id 51032420073;
	Mon, 24 Sep 2012 12:17:31 +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: -3
X-BigFish: VPS-3(zzbb2dI98dI1432Izz1202h1d1ah1d2ahzz17326ah8275dhz2dh668h839hd25he5bhf0ah107ah1288h12a5h12a9h12bdh137ah1155h)
Received: from mail145-ch1 (localhost.localdomain [127.0.0.1]) by mail145-ch1
	(MessageSwitch) id 1348489048836827_16244;
	Mon, 24 Sep 2012 12:17:28 +0000 (UTC)
Received: from CH1EHSMHS026.bigfish.com (snatpool1.int.messaging.microsoft.com
	[10.43.68.245])	by mail145-ch1.bigfish.com (Postfix) with ESMTP id
	BFFD6240072;	Mon, 24 Sep 2012 12:17:28 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	CH1EHSMHS026.bigfish.com (10.43.70.26) with Microsoft SMTP Server id
	14.1.225.23; Mon, 24 Sep 2012 12:17:28 +0000
X-WSS-ID: 0MAUST0-01-0ZW-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 2AA601028026;	Mon, 24 Sep 2012 07:17: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;
	Mon, 24 Sep 2012 07:17: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;
	Mon, 24 Sep 2012 07:17:24 -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, 24 Sep 2012
	08:17:23 -0400
Message-ID: <50604F52.9040706@amd.com>
Date: Mon, 24 Sep 2012 14:17:22 +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: <DE8DF0795D48FD4CA783C40EC8292335332DA5@SHSMSX101.ccr.corp.intel.com>
	<505C1A79.9060100@amd.com>
	<DE8DF0795D48FD4CA783C40EC82923353384C1@SHSMSX101.ccr.corp.intel.com>
In-Reply-To: <DE8DF0795D48FD4CA783C40EC82923353384C1@SHSMSX101.ccr.corp.intel.com>
X-OriginatorOrg: amd.com
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"keir@xen.org" <keir@xen.org>,
	"Ian.Campbell@citrix.com" <Ian.Campbell@citrix.com>,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] comments for c/s 25919 Xen mce
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 09/24/12 12:24, Liu, Jinsong wrote:

> Christoph Egger wrote:
>> On 09/21/12 08:44, Liu, Jinsong wrote:
>>
>>> Christoph, Keir, Jan
>>>
>>> I have a draft look at c/s 25919. It moves some mce_intel.c logic to
>>> mce.c (and remove old mce.c logic). By draft reviewing the patch I
>>> think it need more work to do, and currently it in fact would hung
>>> at AMD platform (I have no AMD platform to test), i.e,
>>> MACHINE_CHECK_SOFTIRQ --> mce_delayed_action() --> mce_action() -->
>>> ASSERT(handler_num);     
>>>
>>> For AMD mce it may need add (if any misunderstanding please point to
>>> me) 1). add default handler which used at softirq context
>>
>>
>> This is mcee_softirq().
>>
>>> 2). add AMD vmce inject logic
>>
>>
>> Yes, patch is sent.
>> See http://lists.xen.org/archives/html/xen-devel/2012-09/msg01413.html
>>
>>> 3). more test
>>
>>
>> There are more patches in my queue.
>>
>> Christoph
>>
> 
> So, Christoph, considering you have a patches queue and would

> change more mce/vmce, how about wait a moment and then based your
> patches on my vmce patches? My vmce patches have been posted for
> quite some time, and have already been reviewed-rebased-tested
> several rounds. I think they are basically stable now, currently only
> need tools maintainers to have review patch4/5 (live migration tools
> part).

> 
> ... I know I have no right asking you to do so, but we need cooperate

> for mce/vmce, and if you agree I would be very much appreciated. As
> for your mce/vmce patches, I'd like to help test at Intel's platform
> to make sure it works fine.

I don't mind in which order the patches go upstream -
yours first, mine first or somehow interleaved..

It is just important to me that you take my comments (to patch 2/5)
into account to minimize the required rebase-retest effort.

Christoph

-- 
---to satisfy European Law for business letters:
Advanced Micro Devices GmbH
Einsteinring 24, 85689 Dornach b. Muenchen
Geschaeftsfuehrer: Alberto Bozzo
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 Sep 24 12:17:50 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Sep 2012 12:17:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TG7bT-0006ae-Oi; Mon, 24 Sep 2012 12:17:35 +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 1TG7bS-0006aS-A1
	for xen-devel@lists.xensource.com; Mon, 24 Sep 2012 12:17:34 +0000
Received: from [85.158.139.211:29184] by server-4.bemta-5.messagelabs.com id
	9D/BF-20767-D5F40605; Mon, 24 Sep 2012 12:17:33 +0000
X-Env-Sender: Christoph.Egger@amd.com
X-Msg-Ref: server-12.tower-206.messagelabs.com!1348489051!18730574!1
X-Originating-IP: [216.32.181.184]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19935 invoked from network); 24 Sep 2012 12:17:32 -0000
Received: from ch1ehsobe004.messaging.microsoft.com (HELO
	ch1outboundpool.messaging.microsoft.com) (216.32.181.184)
	by server-12.tower-206.messagelabs.com with AES128-SHA encrypted SMTP;
	24 Sep 2012 12:17:32 -0000
Received: from mail145-ch1-R.bigfish.com (10.43.68.247) by
	CH1EHSOBE008.bigfish.com (10.43.70.58) with Microsoft SMTP Server id
	14.1.225.23; Mon, 24 Sep 2012 12:17:31 +0000
Received: from mail145-ch1 (localhost [127.0.0.1])	by
	mail145-ch1-R.bigfish.com (Postfix) with ESMTP id 51032420073;
	Mon, 24 Sep 2012 12:17:31 +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: -3
X-BigFish: VPS-3(zzbb2dI98dI1432Izz1202h1d1ah1d2ahzz17326ah8275dhz2dh668h839hd25he5bhf0ah107ah1288h12a5h12a9h12bdh137ah1155h)
Received: from mail145-ch1 (localhost.localdomain [127.0.0.1]) by mail145-ch1
	(MessageSwitch) id 1348489048836827_16244;
	Mon, 24 Sep 2012 12:17:28 +0000 (UTC)
Received: from CH1EHSMHS026.bigfish.com (snatpool1.int.messaging.microsoft.com
	[10.43.68.245])	by mail145-ch1.bigfish.com (Postfix) with ESMTP id
	BFFD6240072;	Mon, 24 Sep 2012 12:17:28 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	CH1EHSMHS026.bigfish.com (10.43.70.26) with Microsoft SMTP Server id
	14.1.225.23; Mon, 24 Sep 2012 12:17:28 +0000
X-WSS-ID: 0MAUST0-01-0ZW-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 2AA601028026;	Mon, 24 Sep 2012 07:17: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;
	Mon, 24 Sep 2012 07:17: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;
	Mon, 24 Sep 2012 07:17:24 -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, 24 Sep 2012
	08:17:23 -0400
Message-ID: <50604F52.9040706@amd.com>
Date: Mon, 24 Sep 2012 14:17:22 +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: <DE8DF0795D48FD4CA783C40EC8292335332DA5@SHSMSX101.ccr.corp.intel.com>
	<505C1A79.9060100@amd.com>
	<DE8DF0795D48FD4CA783C40EC82923353384C1@SHSMSX101.ccr.corp.intel.com>
In-Reply-To: <DE8DF0795D48FD4CA783C40EC82923353384C1@SHSMSX101.ccr.corp.intel.com>
X-OriginatorOrg: amd.com
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"keir@xen.org" <keir@xen.org>,
	"Ian.Campbell@citrix.com" <Ian.Campbell@citrix.com>,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] comments for c/s 25919 Xen mce
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 09/24/12 12:24, Liu, Jinsong wrote:

> Christoph Egger wrote:
>> On 09/21/12 08:44, Liu, Jinsong wrote:
>>
>>> Christoph, Keir, Jan
>>>
>>> I have a draft look at c/s 25919. It moves some mce_intel.c logic to
>>> mce.c (and remove old mce.c logic). By draft reviewing the patch I
>>> think it need more work to do, and currently it in fact would hung
>>> at AMD platform (I have no AMD platform to test), i.e,
>>> MACHINE_CHECK_SOFTIRQ --> mce_delayed_action() --> mce_action() -->
>>> ASSERT(handler_num);     
>>>
>>> For AMD mce it may need add (if any misunderstanding please point to
>>> me) 1). add default handler which used at softirq context
>>
>>
>> This is mcee_softirq().
>>
>>> 2). add AMD vmce inject logic
>>
>>
>> Yes, patch is sent.
>> See http://lists.xen.org/archives/html/xen-devel/2012-09/msg01413.html
>>
>>> 3). more test
>>
>>
>> There are more patches in my queue.
>>
>> Christoph
>>
> 
> So, Christoph, considering you have a patches queue and would

> change more mce/vmce, how about wait a moment and then based your
> patches on my vmce patches? My vmce patches have been posted for
> quite some time, and have already been reviewed-rebased-tested
> several rounds. I think they are basically stable now, currently only
> need tools maintainers to have review patch4/5 (live migration tools
> part).

> 
> ... I know I have no right asking you to do so, but we need cooperate

> for mce/vmce, and if you agree I would be very much appreciated. As
> for your mce/vmce patches, I'd like to help test at Intel's platform
> to make sure it works fine.

I don't mind in which order the patches go upstream -
yours first, mine first or somehow interleaved..

It is just important to me that you take my comments (to patch 2/5)
into account to minimize the required rebase-retest effort.

Christoph

-- 
---to satisfy European Law for business letters:
Advanced Micro Devices GmbH
Einsteinring 24, 85689 Dornach b. Muenchen
Geschaeftsfuehrer: Alberto Bozzo
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 Sep 24 12:20:46 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Sep 2012 12: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 1TG7eP-0006qX-DK; Mon, 24 Sep 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 <Stefano.Stabellini@eu.citrix.com>)
	id 1TG7eO-0006qM-77
	for Xen-devel@lists.xensource.com; Mon, 24 Sep 2012 12:20:36 +0000
Received: from [85.158.139.211:45678] by server-16.bemta-5.messagelabs.com id
	F7/D0-05998-31050605; Mon, 24 Sep 2012 12:20:35 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-13.tower-206.messagelabs.com!1348489234!15750439!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTA4NDk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28245 invoked from network); 24 Sep 2012 12:20:35 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Sep 2012 12:20:35 -0000
X-IronPort-AV: E=Sophos;i="4.80,474,1344211200"; d="scan'208";a="14722678"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Sep 2012 12:20: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.279.1; Mon, 24 Sep 2012 13:20:23 +0100
Date: Mon, 24 Sep 2012 13:19:32 +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: <20120921121835.300851d8@mantra.us.oracle.com>
Message-ID: <alpine.DEB.2.02.1209241315360.29232@kaball.uk.xensource.com>
References: <20120921121835.300851d8@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>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH v1 5/8]: PVH smp changes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 21 Sep 2012, Mukesh Rathor wrote:
> ---
>  arch/x86/xen/smp.c |   75 ++++++++++++++++++++++++++++++++++------------------
>  1 files changed, 49 insertions(+), 26 deletions(-)
> 
> diff --git a/arch/x86/xen/smp.c b/arch/x86/xen/smp.c
> index f58dca7..e1e8582 100644
> --- a/arch/x86/xen/smp.c
> +++ b/arch/x86/xen/smp.c
> @@ -68,9 +68,11 @@ static void __cpuinit cpu_bringup(void)
>  	touch_softlockup_watchdog();
>  	preempt_disable();
>  
> -	xen_enable_sysenter();
> -	xen_enable_syscall();
> -
> +	/* PVH runs in ring 0 and allows us to do native syscalls. Yay! */
> +	if (!xen_feature(XENFEAT_supervisor_mode_kernel)) {
> +		xen_enable_sysenter();
> +		xen_enable_syscall();
> +	}
>  	cpu = smp_processor_id();
>  	smp_store_cpu_info(cpu);
>  	cpu_data(cpu).x86_max_cores = 1;
> @@ -230,10 +232,11 @@ static void __init xen_smp_prepare_boot_cpu(void)
>  	BUG_ON(smp_processor_id() != 0);
>  	native_smp_prepare_boot_cpu();
>  
> -	/* We've switched to the "real" per-cpu gdt, so make sure the
> -	   old memory can be recycled */
> -	make_lowmem_page_readwrite(xen_initial_gdt);
> -
> +	if (!xen_feature(XENFEAT_writable_page_tables)) {
> +		/* We've switched to the "real" per-cpu gdt, so make sure the
> +	   	 * old memory can be recycled */
> +		make_lowmem_page_readwrite(xen_initial_gdt);
> +	}

it is worth adding a comment saying that PVH doesn't need this even if
the pagetable are writable in that case


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 24 12:20:46 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Sep 2012 12: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 1TG7eP-0006qX-DK; Mon, 24 Sep 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 <Stefano.Stabellini@eu.citrix.com>)
	id 1TG7eO-0006qM-77
	for Xen-devel@lists.xensource.com; Mon, 24 Sep 2012 12:20:36 +0000
Received: from [85.158.139.211:45678] by server-16.bemta-5.messagelabs.com id
	F7/D0-05998-31050605; Mon, 24 Sep 2012 12:20:35 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-13.tower-206.messagelabs.com!1348489234!15750439!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTA4NDk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28245 invoked from network); 24 Sep 2012 12:20:35 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Sep 2012 12:20:35 -0000
X-IronPort-AV: E=Sophos;i="4.80,474,1344211200"; d="scan'208";a="14722678"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Sep 2012 12:20: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.279.1; Mon, 24 Sep 2012 13:20:23 +0100
Date: Mon, 24 Sep 2012 13:19:32 +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: <20120921121835.300851d8@mantra.us.oracle.com>
Message-ID: <alpine.DEB.2.02.1209241315360.29232@kaball.uk.xensource.com>
References: <20120921121835.300851d8@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>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH v1 5/8]: PVH smp changes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 21 Sep 2012, Mukesh Rathor wrote:
> ---
>  arch/x86/xen/smp.c |   75 ++++++++++++++++++++++++++++++++++------------------
>  1 files changed, 49 insertions(+), 26 deletions(-)
> 
> diff --git a/arch/x86/xen/smp.c b/arch/x86/xen/smp.c
> index f58dca7..e1e8582 100644
> --- a/arch/x86/xen/smp.c
> +++ b/arch/x86/xen/smp.c
> @@ -68,9 +68,11 @@ static void __cpuinit cpu_bringup(void)
>  	touch_softlockup_watchdog();
>  	preempt_disable();
>  
> -	xen_enable_sysenter();
> -	xen_enable_syscall();
> -
> +	/* PVH runs in ring 0 and allows us to do native syscalls. Yay! */
> +	if (!xen_feature(XENFEAT_supervisor_mode_kernel)) {
> +		xen_enable_sysenter();
> +		xen_enable_syscall();
> +	}
>  	cpu = smp_processor_id();
>  	smp_store_cpu_info(cpu);
>  	cpu_data(cpu).x86_max_cores = 1;
> @@ -230,10 +232,11 @@ static void __init xen_smp_prepare_boot_cpu(void)
>  	BUG_ON(smp_processor_id() != 0);
>  	native_smp_prepare_boot_cpu();
>  
> -	/* We've switched to the "real" per-cpu gdt, so make sure the
> -	   old memory can be recycled */
> -	make_lowmem_page_readwrite(xen_initial_gdt);
> -
> +	if (!xen_feature(XENFEAT_writable_page_tables)) {
> +		/* We've switched to the "real" per-cpu gdt, so make sure the
> +	   	 * old memory can be recycled */
> +		make_lowmem_page_readwrite(xen_initial_gdt);
> +	}

it is worth adding a comment saying that PVH doesn't need this even if
the pagetable are writable in that case


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 24 12:22:19 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Sep 2012 12: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 1TG7ft-0006yu-TH; Mon, 24 Sep 2012 12:22:09 +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 1TG7fs-0006yj-Je
	for xen-devel@lists.xen.org; Mon, 24 Sep 2012 12:22:08 +0000
Received: from [85.158.137.99:12091] by server-6.bemta-3.messagelabs.com id
	96/C4-29694-F6050605; Mon, 24 Sep 2012 12:22:07 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-16.tower-217.messagelabs.com!1348489327!18895343!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA1MTM3Njk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28899 invoked from network); 24 Sep 2012 12:22:07 -0000
Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25)
	by server-16.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 24 Sep 2012 12:22:07 -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 6B4E228D8;
	Mon, 24 Sep 2012 15:22:04 +0300 (EEST)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id 2FB8F2005D; Mon, 24 Sep 2012 15:22:04 +0300 (EEST)
Date: Mon, 24 Sep 2012 15:22:04 +0300
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: Ben Guthro <ben@guthro.net>
Message-ID: <20120924122203.GG8912@reaktio.net>
References: <CAOvdn6XKPOMNn6AjuYvZvPXRRJffN3po5GXe1Yh1-m0hisMK_w@mail.gmail.com>
	<CC8273A0.4C9DD%keir@xen.org>
	<50605E9A020000780009D486@nat28.tlf.novell.com>
	<CAOvdn6XmB6rj3_QVU+59V8p24Y5G47AWxVEM=id02JWXkuhibQ@mail.gmail.com>
	<5060640B020000780009D4D2@nat28.tlf.novell.com>
	<CAOvdn6XLy8zR2rb2MEyi2aT9LQiFvFLY_H02p181mTsVLVTZkw@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAOvdn6XLy8zR2rb2MEyi2aT9LQiFvFLY_H02p181mTsVLVTZkw@mail.gmail.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: Keir Fraser <keir@xen.org>, john.baboval@citrix.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	xen-devel <xen-devel@lists.xen.org>, Jan Beulich <JBeulich@suse.com>,
	Thomas Goetz <thomas.goetz@citrix.com>
Subject: Re: [Xen-devel] Xen4.2 S3 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 Mon, Sep 24, 2012 at 07:54:05AM -0400, Ben Guthro wrote:
>    I see - Konrad - do you have a changeset I can look for with the features
>    Jan describes?

xen-acpi-processor driver was merged to upstream Linux kernel v3.4.

-- Pasi

>    On Mon, Sep 24, 2012 at 7:45 AM, Jan Beulich <[1]JBeulich@suse.com> wrote:
> 
>      >>> On 24.09.12 at 13:25, Ben Guthro <[2]ben@guthro.net> wrote:
>      > It is an older system (Core2) - so it may be using the default
>      mechanism,
>      > but I'd have to go dig up some processor docs to be sure.
> 
>      This is not just a matter of what the CPU supports, but also what
>      info gets passed down from Dom0 - if e.g. your kernel doesn't
>      have Konrad's P-/C-state patches, then there's no way for Xen to
>      use any of the advanced methods.
>      Jan
> 
> References
> 
>    Visible links
>    1. mailto:JBeulich@suse.com
>    2. mailto:ben@guthro.net

> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Sep 24 12:22:19 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Sep 2012 12: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 1TG7ft-0006yu-TH; Mon, 24 Sep 2012 12:22:09 +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 1TG7fs-0006yj-Je
	for xen-devel@lists.xen.org; Mon, 24 Sep 2012 12:22:08 +0000
Received: from [85.158.137.99:12091] by server-6.bemta-3.messagelabs.com id
	96/C4-29694-F6050605; Mon, 24 Sep 2012 12:22:07 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-16.tower-217.messagelabs.com!1348489327!18895343!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA1MTM3Njk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28899 invoked from network); 24 Sep 2012 12:22:07 -0000
Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25)
	by server-16.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 24 Sep 2012 12:22:07 -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 6B4E228D8;
	Mon, 24 Sep 2012 15:22:04 +0300 (EEST)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id 2FB8F2005D; Mon, 24 Sep 2012 15:22:04 +0300 (EEST)
Date: Mon, 24 Sep 2012 15:22:04 +0300
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: Ben Guthro <ben@guthro.net>
Message-ID: <20120924122203.GG8912@reaktio.net>
References: <CAOvdn6XKPOMNn6AjuYvZvPXRRJffN3po5GXe1Yh1-m0hisMK_w@mail.gmail.com>
	<CC8273A0.4C9DD%keir@xen.org>
	<50605E9A020000780009D486@nat28.tlf.novell.com>
	<CAOvdn6XmB6rj3_QVU+59V8p24Y5G47AWxVEM=id02JWXkuhibQ@mail.gmail.com>
	<5060640B020000780009D4D2@nat28.tlf.novell.com>
	<CAOvdn6XLy8zR2rb2MEyi2aT9LQiFvFLY_H02p181mTsVLVTZkw@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAOvdn6XLy8zR2rb2MEyi2aT9LQiFvFLY_H02p181mTsVLVTZkw@mail.gmail.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: Keir Fraser <keir@xen.org>, john.baboval@citrix.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	xen-devel <xen-devel@lists.xen.org>, Jan Beulich <JBeulich@suse.com>,
	Thomas Goetz <thomas.goetz@citrix.com>
Subject: Re: [Xen-devel] Xen4.2 S3 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 Mon, Sep 24, 2012 at 07:54:05AM -0400, Ben Guthro wrote:
>    I see - Konrad - do you have a changeset I can look for with the features
>    Jan describes?

xen-acpi-processor driver was merged to upstream Linux kernel v3.4.

-- Pasi

>    On Mon, Sep 24, 2012 at 7:45 AM, Jan Beulich <[1]JBeulich@suse.com> wrote:
> 
>      >>> On 24.09.12 at 13:25, Ben Guthro <[2]ben@guthro.net> wrote:
>      > It is an older system (Core2) - so it may be using the default
>      mechanism,
>      > but I'd have to go dig up some processor docs to be sure.
> 
>      This is not just a matter of what the CPU supports, but also what
>      info gets passed down from Dom0 - if e.g. your kernel doesn't
>      have Konrad's P-/C-state patches, then there's no way for Xen to
>      use any of the advanced methods.
>      Jan
> 
> References
> 
>    Visible links
>    1. mailto:JBeulich@suse.com
>    2. mailto:ben@guthro.net

> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Sep 24 12:22:34 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Sep 2012 12: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 1TG7g9-00071w-FP; Mon, 24 Sep 2012 12:22:25 +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 1TG7g7-00071V-UG
	for xen-devel@lists.xensource.com; Mon, 24 Sep 2012 12:22:24 +0000
Received: from [85.158.139.83:52192] by server-2.bemta-5.messagelabs.com id
	63/0F-28944-F7050605; Mon, 24 Sep 2012 12:22:23 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1348489340!31322231!1
X-Originating-IP: [216.32.180.184]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8875 invoked from network); 24 Sep 2012 12:22:21 -0000
Received: from co1ehsobe001.messaging.microsoft.com (HELO
	co1outboundpool.messaging.microsoft.com) (216.32.180.184)
	by server-13.tower-182.messagelabs.com with AES128-SHA encrypted SMTP;
	24 Sep 2012 12:22:21 -0000
Received: from mail161-co1-R.bigfish.com (10.243.78.254) by
	CO1EHSOBE013.bigfish.com (10.243.66.76) with Microsoft SMTP Server id
	14.1.225.23; Mon, 24 Sep 2012 12:22:19 +0000
Received: from mail161-co1 (localhost [127.0.0.1])	by
	mail161-co1-R.bigfish.com (Postfix) with ESMTP id 45259920078;
	Mon, 24 Sep 2012 12:22:19 +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: -6
X-BigFish: VPS-6(zzbb2dI98dI9371I936eI1432I4015I1447Id6f1izz1202h1d1ah1d2ahzz8275bhz2dh668h839hd25he5bhf0ah107ah1288h12a5h12a9h12bdh137ah1155h)
Received: from mail161-co1 (localhost.localdomain [127.0.0.1]) by mail161-co1
	(MessageSwitch) id 1348489336576521_25003;
	Mon, 24 Sep 2012 12:22:16 +0000 (UTC)
Received: from CO1EHSMHS015.bigfish.com (unknown [10.243.78.239])	by
	mail161-co1.bigfish.com (Postfix) with ESMTP id 8A2851A01FF;
	Mon, 24 Sep 2012 12:22:16 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	CO1EHSMHS015.bigfish.com (10.243.66.25) with Microsoft SMTP Server id
	14.1.225.23; Mon, 24 Sep 2012 12:22:16 +0000
X-WSS-ID: 0MAUT11-02-7Y6-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 27DB4C8017;	Mon, 24 Sep 2012 07:22:12 -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;
	Mon, 24 Sep 2012 07:22:18 -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;
	Mon, 24 Sep 2012 07:22:13 -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, 24 Sep 2012
	08:22: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 0EB6049C1EC; Mon, 24 Sep 2012
	13:22:11 +0100 (BST)
Message-ID: <506050F0.7020703@amd.com>
Date: Mon, 24 Sep 2012 14:24:16 +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: Sander Eikelenboom <linux@eikelenboom.it>
References: <504764E2.4000809@amd.com>
	<326589347.20120906005936@eikelenboom.it>
	<5048A603.3070207@amd.com>
	<483486315.20120906155001@eikelenboom.it>
	<5048BB29.4040900@amd.com>
	<488803362.20120907093241@eikelenboom.it>
	<5049B650.4080101@amd.com> <74647167
In-Reply-To: <74647167.20120924103835@eikelenboom.it>
X-OriginatorOrg: amd.com
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH] amd iommu: Dump flags of IO page faults
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 09/24/2012 10:38 AM, Sander Eikelenboom wrote:
>
> Friday, September 7, 2012, 10:54:40 AM, you wrote:
>
>> On 09/07/2012 09:32 AM, Sander Eikelenboom wrote:
>>>
>>> Thursday, September 6, 2012, 5:03:05 PM, you wrote:
>>>
>>>> On 09/06/2012 03:50 PM, Sander Eikelenboom wrote:
>>>>>
>>>>> Thursday, September 6, 2012, 3:32:51 PM, you wrote:
>>>>>
>>>>>> On 09/06/2012 12:59 AM, Sander Eikelenboom wrote:
>>>>>>>
>>>>>>> Wednesday, September 5, 2012, 4:42:42 PM, you wrote:
>>>>>>>
>>>>>>>> Hi Jan,
>>>>>>>> Attached patch dumps io page fault flags. The flags show the reason of
>>>>>>>> the fault and tell us if this is an unmapped interrupt fault or a DMA fault.
>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Wei
>>>>>>>
>>>>>>>> signed-off-by: Wei Wang<wei.wang2@amd.com>
>>>>>>>
>>>>>>>
>>>>>>> I have applied the patch and the flags seem to differ between the faults:
>>>>>>>
>>>>>>> AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0a06, fault address = 0xc2c2c2c0, flags = 0x000
>>>>>>> (XEN) [2012-09-05 20:54:16] AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0a06, fault address = 0xc2c2c2c0, flags = 0x000
>>>>>>> (XEN) [2012-09-05 20:54:16] AMD-Vi: IO_PAGE_FAULT: domain = 14, device id = 0x0700, fault address = 0xa8d339e0, flags = 0x020
>>>>>>> (XEN) [2012-09-05 20:54:16] AMD-Vi: IO_PAGE_FAULT: domain = 14, device id = 0x0700, fault address = 0xa8d33a40, flags = 0x020
>>>>>
>>>>>> OK, so they are not interrupt requests. I guess further information from
>>>>>> your system would be helpful to debug this issue:
>>>>>> 1) xl info
>>>>>> 2) xl list
>>>>>> 3) lscpi -vvv (NOTE: not in dom0 but in your guest)
>>>>>> 4) cat /proc/iomem (in both dom0 and your hvm guest)
>>>>>
>>>>> dom14 is not a HVM guest,it's a PV guest.
>>>
>>>> Ah, I see. PV guest is quite different than hvm, it does use p2m tables
>>>> as io page tables. So no-sharept option does not work in this case. PV
>>>> guests always use separated io page tables. There might be some
>>>> incorrect mappings on the page tables. I will check this on my side.
>>>
>>> I have reverted the machine to xen-4.1.4-pre (changeset 23353) and kept everything else the same.
>>> I haven't seen any IO PAGE FAULTS after that.
>>>
>>> I did spot some differences in the output from lspci between xen 4.1 and 4.2, related to MSI enabled or not for the IOMMU device.
>>> Have attached the xl/xm dmesg and lspci from booting with both versions.
>>>
>>> lspci:
>>>
>>> 00:00.2 Generic system peripheral [0806]: ATI Technologies Inc RD990 I/O Memory Management Unit (IOMMU) [1002:5a23]
>>>           Subsystem: ATI Technologies Inc RD990 I/O Memory Management Unit (IOMMU) [1002:5a23]
>>>           Control: I/O- Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
>>>           Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast>TAbort-<TAbort-<MAbort->SERR-<PERR- INTx-
>>>           Latency: 0
>>>           Interrupt: pin A routed to IRQ 10
>>>           Capabilities: [40] Secure device<?>
>>> 4.1:    Capabilities: [54] MSI: Enable- Count=1/1 Maskable- 64bit+
>
>> Eh... That is interesting. So which dom0 are you using?  There is a c/s
>> in 4.2 to prevent recent dom0 to disable iommu interrupt (changeset
>> 25492:61844569a432) Otherwise, iommu cannot send any events including IO
>> PAGE faults. You could try to revert dom0 to an old version like 2.6
>> pv_ops to see if you really have no io page faults on 4.1
>
> Ok i finally got the time to do some more testing, tested 4.2 around that changeset, and made a copy of the guest using HVM instead of PV.
>
> The results:
> - On xen-4.1.* and a 3.6-rc6 kernel (dom0 and domU):  the video device passed through works fine, both in a HVM as a PV guest, i don't see IO page faults getting reported.
> - On xen-4.2 changeset<   25492 and a 3.6-rc6 kernel (dom0 and domU):  the video device passed through works fine, both in a HVM as a PV guest, i don't see IO page faults getting reported.
> - On xen-4.2 changeset>   25492 and a 3.6-rc6 kernel (dom0 and domU): the video device passed through works fine for a short while (around 5 to 10 minutes) in a PV guest, after that IO page faults get reported and the video freezes, i don't see any errors in the guest though.
> - On xen-unstable tip and a 3.6-rc6 kernel (dom0 and domU):
>                                                        PV:  the video device passed through works fine for a short while (around 5 to 10 minutes), after that IO page faults get reported and the video freezes, i don't see any errors in the guest though.
>                                                        HVM: the video device passed through doesn't work from the start:
>                                                                       - The device is there according to lspci
>                                                                       - The video application start fine, but delivers a green image, so the device is not working properly. I don't see IO page faults though.
>
> Attached are (all with xen-unstable tip and the guest as HVM (domain 15):
> - xl dmesg
> - Patch which adds some more info, but all values reported seem to be zero (see xl dmesg)
> - lspci dom0
> - lspci HVM guest

HI,
Thanks for the information, very very helpful for debugging. I hope I 
could start to look at this right after sending my next iommu patch 
queue upstream...another question is: Did you see this issue on a single 
pv/hvm guest system or you only saw it on a system with about 16 running 
VMs?

Thanks,
Wei

>
>
>
>>> 4.2:    Capabilities: [54] MSI: Enable+ Count=1/1 Maskable- 64bit+
>>>                   Address: 00000000fee0100c  Data: 4128
>>>           Capabilities: [64] HyperTransport: MSI Mapping Enable+ Fixed+
>>>
>>> Although it seems enabled, shouldn't the IRQ number used be much higher than 10 for MSI interrupts ?
>
>> The IRQ number is fine. MSI vector is stored at  Data: 4128
>
>>>
>>> There is another difference in the bridge device that's in front of the  0a:00.6 device that faults before the kernel is even booted.
>>>
>>> 00:03.0 PCI bridge [0604]: ATI Technologies Inc RD890 PCI to PCI bridge (PCI express gpp port C) [1002:5a17] (prog-if 00 [Normal decode])
>>>           Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx+
>>> 4.1:    Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast>TAbort-<TAbort-<MAbort->SERR-<PERR- INTx-
>>> 4.2:    Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast>TAbort-<TAbort+<MAbort->SERR-<PERR- INTx-
>>>           Latency: 0, Cache Line Size: 64 bytes
>>>           Bus: primary=00, secondary=0a, subordinate=0a, sec-latency=0
>>>           I/O behind bridge: 0000f000-00000fff
>>>           Memory behind bridge: f9f00000-f9ffffff
>>>           Prefetchable memory behind bridge: 00000000fff00000-00000000000fffff
>>> 4.1:    Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast>TAbort-<TAbort-<MAbort-<SERR-<PERR-
>>> 4.2:    Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast>TAbort+<TAbort-<MAbort-<SERR-<PERR-
>>>           BridgeCtl: Parity+ SERR+ NoISA+ VGA- MAbort->Reset- FastB2B-
>>>                   PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
>>>           Capabilities: [50] Power Management version 3
>>>                   Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
>>>                   Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
>>>           Capabilities: [58] Express (v2) Root Port (Slot+), MSI 00
>>>                   DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s<64ns, L1<1us
>>>                           ExtTag+ RBE+ FLReset-
>>>                   DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
>>>                           RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+
>>>                           MaxPayload 128 bytes, MaxReadReq 128 bytes
>>>                   DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr- TransPend-
>>>                   LnkCap: Port #1, Speed 5GT/s, Width x8, ASPM L0s L1, Latency L0<1us, L1<8us
>>>                           ClockPM- Surprise- LLActRep+ BwNot+
>>>                   LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommClk-
>>>                           ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
>>>                   LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive+ BWMgmt+ ABWMgmt-
>>>                   SltCap: AttnBtn- PwrCtrl- MRL- AttnInd- PwrInd- HotPlug- Surprise-
>>>                           Slot #3, PowerLimit 10.000W; Interlock- NoCompl+
>>>                   SltCtl: Enable: AttnBtn- PwrFlt- MRL- PresDet- CmdCplt- HPIrq- LinkChg-
>>>                           Control: AttnInd Unknown, PwrInd Unknown, Power- Interlock-
>>>                   SltSta: Status: AttnBtn- PowerFlt- MRL- CmdCplt- PresDet+ Interlock-
>>>                           Changed: MRL- PresDet+ LinkState+
>
>> The probably because of the IO_PAGE_FAULT.
>
>> Thanks,
>> Wei
>
>>> serveerstertje:~# lspci -t
>>> -[0000:00]-+-00.0
>>>              +-00.2
>>>              +-02.0-[0b]----00.0
>>>              +-03.0-[0a]--+-00.0
>>>              |            +-00.1
>>>              |            +-00.2
>>>              |            +-00.3
>>>              |            +-00.4
>>>              |            +-00.5
>>>              |            +-00.6
>>>              |            \-00.7
>>>              +-05.0-[09]----00.0
>>>              +-06.0-[08]----00.0
>>>              +-0a.0-[07]----00.0
>>>              +-0b.0-[06]--+-00.0
>>>              |            \-00.1
>>>              +-0c.0-[05]----00.0
>>>              +-0d.0-[04]--+-00.0
>>>              |            +-00.1
>>>              |            +-00.2
>>>              |            +-00.3
>>>              |            +-00.4
>>>              |            +-00.5
>>>              |            +-00.6
>>>              |            \-00.7
>>>              +-11.0
>>>              +-12.0
>>>              +-12.2
>>>              +-13.0
>>>              +-13.2
>>>              +-14.0
>>>              +-14.3
>>>              +-14.4-[03]----06.0
>>>              +-14.5
>>>              +-15.0-[02]--
>>>              +-16.0
>>>              +-16.2
>>>              +-18.0
>>>              +-18.1
>>>              +-18.2
>>>              +-18.3
>>>              \-18.4
>>>
>>>
>>>
>>>
>>>
>>>> Thanks,
>>>> Wei
>>>
>>>>> I will try to make a complete package, and try with one pv domain only where the devices are being passed through just to simplify the setup.
>>>>>
>>>>>
>>>>>> * I would also like to know the symptoms of device 0x0700 when IO_PF
>>>>>> happened. Did it stop working?
>>>>>
>>>>> Yes it stops working, the video capture just freezes, but the driver doesn't bail out.
>>>>> For the USB controller (0x0a06) it starts to give errors for usbdev_open in the guest.
>>>>>
>>>>>> (BTW: I copied a few options from your boot cmd line and it worked with
>>>>>> my RD890 system
>>>>>
>>>>>> dom0_mem=1024M,max:1024M loglvl=all loglvl_guest=all console_timestamps
>>>>>> cpuidle cpufreq=xen noreboot debug lapic=debug apic_verbosity=debug
>>>>>> apic=debug iommu=on,verbose,debug,no-sharept
>>>>>
>>>>>> * so, what OEM board you have?)
>>>>>
>>>>> MSI 890FXA-GD70
>>>>>
>>>>>> Also from your log, these lines looks very strange:
>>>>>
>>>>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>>>>>> read-only memory page. gfn=0xd5, mfn=0xa4a11
>>>>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>>>>>> read-only memory page. gfn=0xd7, mfn=0xa4a0f
>>>>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>>>>>> read-only memory page. gfn=0xd9, mfn=0xa4a0d
>>>>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>>>>>> read-only memory page. gfn=0xdb, mfn=0xa4a0b
>>>>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>>>>>> read-only memory page. gfn=0xdd, mfn=0xa4a09
>>>>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>>>>>> read-only memory page. gfn=0xdf, mfn=0xa4a07
>>>>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>>>>>> read-only memory page. gfn=0xe1, mfn=0xa4a05
>>>>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>>>>>> read-only memory page. gfn=0xe3, mfn=0xa4a03
>>>>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>>>>>> read-only memory page. gfn=0xe5, mfn=0xa4a01
>>>>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>>>>>> read-only memory page. gfn=0xe7, mfn=0xa463f
>>>>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>>>>>> read-only memory page. gfn=0xe9, mfn=0xa463d
>>>>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>>>>>> read-only memory page. gfn=0xeb, mfn=0xa463b
>>>>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>>>>>> read-only memory page. gfn=0xed, mfn=0xa4639
>>>>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>>>>>> read-only memory page. gfn=0xef, mfn=0xa4637
>>>>>> (XEN) [2012-09-04 16:13:56] AMD-Vi: IO_PAGE_FAULT: domain = 0, device id
>>>>>> = 0x0a06, fault address = 0xc2c2c2c0
>>>>>> (XEN) [2012-09-04 16:13:56] AMD-Vi: IO_PAGE_FAULT: domain = 14, device
>>>>>> id = 0x0700, fault address = 0xa90f8300
>>>>>> (XEN) [2012-09-04 16:13:56] AMD-Vi: IO_PAGE_FAULT: domain = 14, device
>>>>>> id = 0x0700, fault address = 0xa90f8340
>>>>>> (XEN) [2012-09-04 16:13:56] AMD-Vi: IO_PAGE_FAULT: domain = 14, device
>>>>>> id = 0x0700, fault address = 0xa90f8380
>>>>>> (XEN) [2012-09-04 16:13:56] AMD-Vi: IO_PAGE_FAULT: domain = 14, device
>>>>>> id = 0x0700, fault address = 0xa90f83c0
>>>>>
>>>>>> * they are just followed by the IO PAGE fault. Do you know where are
>>>>>> they from? Your video card driver maybe?
>>>>>
>>>>>      From a HVM domain with a old (3.0.3) kernel, but the faults also occur without this domain being started.
>>>>>
>>>>>
>>>>>> Thanks,
>>>>>> Wei
>>>>>
>>>>>
>>>>>>> Complete xl dmesg and lspci -vvvknn attached.
>>>>>>>
>>>>>>> Thx
>>>>>>>
>>>>>>> --
>>>>>>> Sander
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>
>>>
>
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 24 12:22:34 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Sep 2012 12: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 1TG7g9-00071w-FP; Mon, 24 Sep 2012 12:22:25 +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 1TG7g7-00071V-UG
	for xen-devel@lists.xensource.com; Mon, 24 Sep 2012 12:22:24 +0000
Received: from [85.158.139.83:52192] by server-2.bemta-5.messagelabs.com id
	63/0F-28944-F7050605; Mon, 24 Sep 2012 12:22:23 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1348489340!31322231!1
X-Originating-IP: [216.32.180.184]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8875 invoked from network); 24 Sep 2012 12:22:21 -0000
Received: from co1ehsobe001.messaging.microsoft.com (HELO
	co1outboundpool.messaging.microsoft.com) (216.32.180.184)
	by server-13.tower-182.messagelabs.com with AES128-SHA encrypted SMTP;
	24 Sep 2012 12:22:21 -0000
Received: from mail161-co1-R.bigfish.com (10.243.78.254) by
	CO1EHSOBE013.bigfish.com (10.243.66.76) with Microsoft SMTP Server id
	14.1.225.23; Mon, 24 Sep 2012 12:22:19 +0000
Received: from mail161-co1 (localhost [127.0.0.1])	by
	mail161-co1-R.bigfish.com (Postfix) with ESMTP id 45259920078;
	Mon, 24 Sep 2012 12:22:19 +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: -6
X-BigFish: VPS-6(zzbb2dI98dI9371I936eI1432I4015I1447Id6f1izz1202h1d1ah1d2ahzz8275bhz2dh668h839hd25he5bhf0ah107ah1288h12a5h12a9h12bdh137ah1155h)
Received: from mail161-co1 (localhost.localdomain [127.0.0.1]) by mail161-co1
	(MessageSwitch) id 1348489336576521_25003;
	Mon, 24 Sep 2012 12:22:16 +0000 (UTC)
Received: from CO1EHSMHS015.bigfish.com (unknown [10.243.78.239])	by
	mail161-co1.bigfish.com (Postfix) with ESMTP id 8A2851A01FF;
	Mon, 24 Sep 2012 12:22:16 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	CO1EHSMHS015.bigfish.com (10.243.66.25) with Microsoft SMTP Server id
	14.1.225.23; Mon, 24 Sep 2012 12:22:16 +0000
X-WSS-ID: 0MAUT11-02-7Y6-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 27DB4C8017;	Mon, 24 Sep 2012 07:22:12 -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;
	Mon, 24 Sep 2012 07:22:18 -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;
	Mon, 24 Sep 2012 07:22:13 -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, 24 Sep 2012
	08:22: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 0EB6049C1EC; Mon, 24 Sep 2012
	13:22:11 +0100 (BST)
Message-ID: <506050F0.7020703@amd.com>
Date: Mon, 24 Sep 2012 14:24:16 +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: Sander Eikelenboom <linux@eikelenboom.it>
References: <504764E2.4000809@amd.com>
	<326589347.20120906005936@eikelenboom.it>
	<5048A603.3070207@amd.com>
	<483486315.20120906155001@eikelenboom.it>
	<5048BB29.4040900@amd.com>
	<488803362.20120907093241@eikelenboom.it>
	<5049B650.4080101@amd.com> <74647167
In-Reply-To: <74647167.20120924103835@eikelenboom.it>
X-OriginatorOrg: amd.com
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH] amd iommu: Dump flags of IO page faults
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 09/24/2012 10:38 AM, Sander Eikelenboom wrote:
>
> Friday, September 7, 2012, 10:54:40 AM, you wrote:
>
>> On 09/07/2012 09:32 AM, Sander Eikelenboom wrote:
>>>
>>> Thursday, September 6, 2012, 5:03:05 PM, you wrote:
>>>
>>>> On 09/06/2012 03:50 PM, Sander Eikelenboom wrote:
>>>>>
>>>>> Thursday, September 6, 2012, 3:32:51 PM, you wrote:
>>>>>
>>>>>> On 09/06/2012 12:59 AM, Sander Eikelenboom wrote:
>>>>>>>
>>>>>>> Wednesday, September 5, 2012, 4:42:42 PM, you wrote:
>>>>>>>
>>>>>>>> Hi Jan,
>>>>>>>> Attached patch dumps io page fault flags. The flags show the reason of
>>>>>>>> the fault and tell us if this is an unmapped interrupt fault or a DMA fault.
>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Wei
>>>>>>>
>>>>>>>> signed-off-by: Wei Wang<wei.wang2@amd.com>
>>>>>>>
>>>>>>>
>>>>>>> I have applied the patch and the flags seem to differ between the faults:
>>>>>>>
>>>>>>> AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0a06, fault address = 0xc2c2c2c0, flags = 0x000
>>>>>>> (XEN) [2012-09-05 20:54:16] AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0a06, fault address = 0xc2c2c2c0, flags = 0x000
>>>>>>> (XEN) [2012-09-05 20:54:16] AMD-Vi: IO_PAGE_FAULT: domain = 14, device id = 0x0700, fault address = 0xa8d339e0, flags = 0x020
>>>>>>> (XEN) [2012-09-05 20:54:16] AMD-Vi: IO_PAGE_FAULT: domain = 14, device id = 0x0700, fault address = 0xa8d33a40, flags = 0x020
>>>>>
>>>>>> OK, so they are not interrupt requests. I guess further information from
>>>>>> your system would be helpful to debug this issue:
>>>>>> 1) xl info
>>>>>> 2) xl list
>>>>>> 3) lscpi -vvv (NOTE: not in dom0 but in your guest)
>>>>>> 4) cat /proc/iomem (in both dom0 and your hvm guest)
>>>>>
>>>>> dom14 is not a HVM guest,it's a PV guest.
>>>
>>>> Ah, I see. PV guest is quite different than hvm, it does use p2m tables
>>>> as io page tables. So no-sharept option does not work in this case. PV
>>>> guests always use separated io page tables. There might be some
>>>> incorrect mappings on the page tables. I will check this on my side.
>>>
>>> I have reverted the machine to xen-4.1.4-pre (changeset 23353) and kept everything else the same.
>>> I haven't seen any IO PAGE FAULTS after that.
>>>
>>> I did spot some differences in the output from lspci between xen 4.1 and 4.2, related to MSI enabled or not for the IOMMU device.
>>> Have attached the xl/xm dmesg and lspci from booting with both versions.
>>>
>>> lspci:
>>>
>>> 00:00.2 Generic system peripheral [0806]: ATI Technologies Inc RD990 I/O Memory Management Unit (IOMMU) [1002:5a23]
>>>           Subsystem: ATI Technologies Inc RD990 I/O Memory Management Unit (IOMMU) [1002:5a23]
>>>           Control: I/O- Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
>>>           Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast>TAbort-<TAbort-<MAbort->SERR-<PERR- INTx-
>>>           Latency: 0
>>>           Interrupt: pin A routed to IRQ 10
>>>           Capabilities: [40] Secure device<?>
>>> 4.1:    Capabilities: [54] MSI: Enable- Count=1/1 Maskable- 64bit+
>
>> Eh... That is interesting. So which dom0 are you using?  There is a c/s
>> in 4.2 to prevent recent dom0 to disable iommu interrupt (changeset
>> 25492:61844569a432) Otherwise, iommu cannot send any events including IO
>> PAGE faults. You could try to revert dom0 to an old version like 2.6
>> pv_ops to see if you really have no io page faults on 4.1
>
> Ok i finally got the time to do some more testing, tested 4.2 around that changeset, and made a copy of the guest using HVM instead of PV.
>
> The results:
> - On xen-4.1.* and a 3.6-rc6 kernel (dom0 and domU):  the video device passed through works fine, both in a HVM as a PV guest, i don't see IO page faults getting reported.
> - On xen-4.2 changeset<   25492 and a 3.6-rc6 kernel (dom0 and domU):  the video device passed through works fine, both in a HVM as a PV guest, i don't see IO page faults getting reported.
> - On xen-4.2 changeset>   25492 and a 3.6-rc6 kernel (dom0 and domU): the video device passed through works fine for a short while (around 5 to 10 minutes) in a PV guest, after that IO page faults get reported and the video freezes, i don't see any errors in the guest though.
> - On xen-unstable tip and a 3.6-rc6 kernel (dom0 and domU):
>                                                        PV:  the video device passed through works fine for a short while (around 5 to 10 minutes), after that IO page faults get reported and the video freezes, i don't see any errors in the guest though.
>                                                        HVM: the video device passed through doesn't work from the start:
>                                                                       - The device is there according to lspci
>                                                                       - The video application start fine, but delivers a green image, so the device is not working properly. I don't see IO page faults though.
>
> Attached are (all with xen-unstable tip and the guest as HVM (domain 15):
> - xl dmesg
> - Patch which adds some more info, but all values reported seem to be zero (see xl dmesg)
> - lspci dom0
> - lspci HVM guest

HI,
Thanks for the information, very very helpful for debugging. I hope I 
could start to look at this right after sending my next iommu patch 
queue upstream...another question is: Did you see this issue on a single 
pv/hvm guest system or you only saw it on a system with about 16 running 
VMs?

Thanks,
Wei

>
>
>
>>> 4.2:    Capabilities: [54] MSI: Enable+ Count=1/1 Maskable- 64bit+
>>>                   Address: 00000000fee0100c  Data: 4128
>>>           Capabilities: [64] HyperTransport: MSI Mapping Enable+ Fixed+
>>>
>>> Although it seems enabled, shouldn't the IRQ number used be much higher than 10 for MSI interrupts ?
>
>> The IRQ number is fine. MSI vector is stored at  Data: 4128
>
>>>
>>> There is another difference in the bridge device that's in front of the  0a:00.6 device that faults before the kernel is even booted.
>>>
>>> 00:03.0 PCI bridge [0604]: ATI Technologies Inc RD890 PCI to PCI bridge (PCI express gpp port C) [1002:5a17] (prog-if 00 [Normal decode])
>>>           Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx+
>>> 4.1:    Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast>TAbort-<TAbort-<MAbort->SERR-<PERR- INTx-
>>> 4.2:    Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast>TAbort-<TAbort+<MAbort->SERR-<PERR- INTx-
>>>           Latency: 0, Cache Line Size: 64 bytes
>>>           Bus: primary=00, secondary=0a, subordinate=0a, sec-latency=0
>>>           I/O behind bridge: 0000f000-00000fff
>>>           Memory behind bridge: f9f00000-f9ffffff
>>>           Prefetchable memory behind bridge: 00000000fff00000-00000000000fffff
>>> 4.1:    Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast>TAbort-<TAbort-<MAbort-<SERR-<PERR-
>>> 4.2:    Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast>TAbort+<TAbort-<MAbort-<SERR-<PERR-
>>>           BridgeCtl: Parity+ SERR+ NoISA+ VGA- MAbort->Reset- FastB2B-
>>>                   PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
>>>           Capabilities: [50] Power Management version 3
>>>                   Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
>>>                   Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
>>>           Capabilities: [58] Express (v2) Root Port (Slot+), MSI 00
>>>                   DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s<64ns, L1<1us
>>>                           ExtTag+ RBE+ FLReset-
>>>                   DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
>>>                           RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+
>>>                           MaxPayload 128 bytes, MaxReadReq 128 bytes
>>>                   DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr- TransPend-
>>>                   LnkCap: Port #1, Speed 5GT/s, Width x8, ASPM L0s L1, Latency L0<1us, L1<8us
>>>                           ClockPM- Surprise- LLActRep+ BwNot+
>>>                   LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommClk-
>>>                           ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
>>>                   LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive+ BWMgmt+ ABWMgmt-
>>>                   SltCap: AttnBtn- PwrCtrl- MRL- AttnInd- PwrInd- HotPlug- Surprise-
>>>                           Slot #3, PowerLimit 10.000W; Interlock- NoCompl+
>>>                   SltCtl: Enable: AttnBtn- PwrFlt- MRL- PresDet- CmdCplt- HPIrq- LinkChg-
>>>                           Control: AttnInd Unknown, PwrInd Unknown, Power- Interlock-
>>>                   SltSta: Status: AttnBtn- PowerFlt- MRL- CmdCplt- PresDet+ Interlock-
>>>                           Changed: MRL- PresDet+ LinkState+
>
>> The probably because of the IO_PAGE_FAULT.
>
>> Thanks,
>> Wei
>
>>> serveerstertje:~# lspci -t
>>> -[0000:00]-+-00.0
>>>              +-00.2
>>>              +-02.0-[0b]----00.0
>>>              +-03.0-[0a]--+-00.0
>>>              |            +-00.1
>>>              |            +-00.2
>>>              |            +-00.3
>>>              |            +-00.4
>>>              |            +-00.5
>>>              |            +-00.6
>>>              |            \-00.7
>>>              +-05.0-[09]----00.0
>>>              +-06.0-[08]----00.0
>>>              +-0a.0-[07]----00.0
>>>              +-0b.0-[06]--+-00.0
>>>              |            \-00.1
>>>              +-0c.0-[05]----00.0
>>>              +-0d.0-[04]--+-00.0
>>>              |            +-00.1
>>>              |            +-00.2
>>>              |            +-00.3
>>>              |            +-00.4
>>>              |            +-00.5
>>>              |            +-00.6
>>>              |            \-00.7
>>>              +-11.0
>>>              +-12.0
>>>              +-12.2
>>>              +-13.0
>>>              +-13.2
>>>              +-14.0
>>>              +-14.3
>>>              +-14.4-[03]----06.0
>>>              +-14.5
>>>              +-15.0-[02]--
>>>              +-16.0
>>>              +-16.2
>>>              +-18.0
>>>              +-18.1
>>>              +-18.2
>>>              +-18.3
>>>              \-18.4
>>>
>>>
>>>
>>>
>>>
>>>> Thanks,
>>>> Wei
>>>
>>>>> I will try to make a complete package, and try with one pv domain only where the devices are being passed through just to simplify the setup.
>>>>>
>>>>>
>>>>>> * I would also like to know the symptoms of device 0x0700 when IO_PF
>>>>>> happened. Did it stop working?
>>>>>
>>>>> Yes it stops working, the video capture just freezes, but the driver doesn't bail out.
>>>>> For the USB controller (0x0a06) it starts to give errors for usbdev_open in the guest.
>>>>>
>>>>>> (BTW: I copied a few options from your boot cmd line and it worked with
>>>>>> my RD890 system
>>>>>
>>>>>> dom0_mem=1024M,max:1024M loglvl=all loglvl_guest=all console_timestamps
>>>>>> cpuidle cpufreq=xen noreboot debug lapic=debug apic_verbosity=debug
>>>>>> apic=debug iommu=on,verbose,debug,no-sharept
>>>>>
>>>>>> * so, what OEM board you have?)
>>>>>
>>>>> MSI 890FXA-GD70
>>>>>
>>>>>> Also from your log, these lines looks very strange:
>>>>>
>>>>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>>>>>> read-only memory page. gfn=0xd5, mfn=0xa4a11
>>>>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>>>>>> read-only memory page. gfn=0xd7, mfn=0xa4a0f
>>>>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>>>>>> read-only memory page. gfn=0xd9, mfn=0xa4a0d
>>>>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>>>>>> read-only memory page. gfn=0xdb, mfn=0xa4a0b
>>>>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>>>>>> read-only memory page. gfn=0xdd, mfn=0xa4a09
>>>>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>>>>>> read-only memory page. gfn=0xdf, mfn=0xa4a07
>>>>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>>>>>> read-only memory page. gfn=0xe1, mfn=0xa4a05
>>>>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>>>>>> read-only memory page. gfn=0xe3, mfn=0xa4a03
>>>>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>>>>>> read-only memory page. gfn=0xe5, mfn=0xa4a01
>>>>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>>>>>> read-only memory page. gfn=0xe7, mfn=0xa463f
>>>>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>>>>>> read-only memory page. gfn=0xe9, mfn=0xa463d
>>>>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>>>>>> read-only memory page. gfn=0xeb, mfn=0xa463b
>>>>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>>>>>> read-only memory page. gfn=0xed, mfn=0xa4639
>>>>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>>>>>> read-only memory page. gfn=0xef, mfn=0xa4637
>>>>>> (XEN) [2012-09-04 16:13:56] AMD-Vi: IO_PAGE_FAULT: domain = 0, device id
>>>>>> = 0x0a06, fault address = 0xc2c2c2c0
>>>>>> (XEN) [2012-09-04 16:13:56] AMD-Vi: IO_PAGE_FAULT: domain = 14, device
>>>>>> id = 0x0700, fault address = 0xa90f8300
>>>>>> (XEN) [2012-09-04 16:13:56] AMD-Vi: IO_PAGE_FAULT: domain = 14, device
>>>>>> id = 0x0700, fault address = 0xa90f8340
>>>>>> (XEN) [2012-09-04 16:13:56] AMD-Vi: IO_PAGE_FAULT: domain = 14, device
>>>>>> id = 0x0700, fault address = 0xa90f8380
>>>>>> (XEN) [2012-09-04 16:13:56] AMD-Vi: IO_PAGE_FAULT: domain = 14, device
>>>>>> id = 0x0700, fault address = 0xa90f83c0
>>>>>
>>>>>> * they are just followed by the IO PAGE fault. Do you know where are
>>>>>> they from? Your video card driver maybe?
>>>>>
>>>>>      From a HVM domain with a old (3.0.3) kernel, but the faults also occur without this domain being started.
>>>>>
>>>>>
>>>>>> Thanks,
>>>>>> Wei
>>>>>
>>>>>
>>>>>>> Complete xl dmesg and lspci -vvvknn attached.
>>>>>>>
>>>>>>> Thx
>>>>>>>
>>>>>>> --
>>>>>>> Sander
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>
>>>
>
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 24 12:25:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Sep 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 1TG7iZ-0007I1-1r; Mon, 24 Sep 2012 12:24:55 +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 1TG7iX-0007Hi-1r
	for xen-devel@lists.xen.org; Mon, 24 Sep 2012 12:24:53 +0000
Received: from [85.158.138.51:30235] by server-1.bemta-3.messagelabs.com id
	97/36-05884-41150605; Mon, 24 Sep 2012 12:24:52 +0000
X-Env-Sender: ben.guthro@gmail.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1348489489!31734439!1
X-Originating-IP: [209.85.223.173]
X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE,
	RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24793 invoked from network); 24 Sep 2012 12:24:50 -0000
Received: from mail-ie0-f173.google.com (HELO mail-ie0-f173.google.com)
	(209.85.223.173)
	by server-11.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Sep 2012 12:24:50 -0000
Received: by iea17 with SMTP id 17so7638016iea.32
	for <xen-devel@lists.xen.org>; Mon, 24 Sep 2012 05:24: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=z40qEf84lZUs63dixCFM9rsHukot6b22vcf8tNbureQ=;
	b=jm2OARXJesOa2AOSdhVrrqd+EW8h0RBy/8K1KvYetFj37gza8v2/Fti1s2EdvNGBL1
	UOA3EdpCP/78CVNSu9Rrkdx2NqDkw7bj/Gi+vPtGAUflIuSoV4DIZjYj1y9/tCxsEyIE
	ImKe4Kgk0OuOO+j7SN4V6MHw6C1pnGQY4w0bhQuVv4tiSv4VF+LMjlcAvbfVc/B+MZ9S
	yjWGJzodGSUAo6ZI9w3c4jMik1yvDoLFHfFugiaqPphjEo94fflpTdk+pJ3khQUJvx5W
	wCeGOFKWz9D3XIQBdyOsgUaqi2Vh3WIvX0tfndD7LMI+Y0MNMTl9F7YCz76yYepxm7n3
	xu3A==
MIME-Version: 1.0
Received: by 10.50.158.226 with SMTP id wx2mr4980691igb.70.1348489488899; Mon,
	24 Sep 2012 05:24:48 -0700 (PDT)
Received: by 10.64.55.132 with HTTP; Mon, 24 Sep 2012 05:24:48 -0700 (PDT)
In-Reply-To: <506068A0020000780009D519@nat28.tlf.novell.com>
References: <CAOvdn6XKPOMNn6AjuYvZvPXRRJffN3po5GXe1Yh1-m0hisMK_w@mail.gmail.com>
	<CC8273A0.4C9DD%keir@xen.org>
	<50605E9A020000780009D486@nat28.tlf.novell.com>
	<CAOvdn6XmB6rj3_QVU+59V8p24Y5G47AWxVEM=id02JWXkuhibQ@mail.gmail.com>
	<5060640B020000780009D4D2@nat28.tlf.novell.com>
	<CAOvdn6XLy8zR2rb2MEyi2aT9LQiFvFLY_H02p181mTsVLVTZkw@mail.gmail.com>
	<506068A0020000780009D519@nat28.tlf.novell.com>
Date: Mon, 24 Sep 2012 08:24:48 -0400
X-Google-Sender-Auth: MjJf2z0qjSK6KEhKK9ToyjIj1wE
Message-ID: <CAOvdn6Undn2srfNhW++wLfUNFQ5JnZ3rp5bg7DD_TDPCHqmP_A@mail.gmail.com>
From: Ben Guthro <ben@guthro.net>
To: Jan Beulich <JBeulich@suse.com>
Content-Type: multipart/mixed; boundary=14dae9340c89f81da404ca71acab
Cc: xen-devel <xen-devel@lists.xen.org>, Keir Fraser <keir@xen.org>,
	john.baboval@citrix.com, Thomas Goetz <thomas.goetz@citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] Xen4.2 S3 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>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--14dae9340c89f81da404ca71acab
Content-Type: multipart/alternative; boundary=14dae9340c89f81d9004ca71aca9

--14dae9340c89f81d9004ca71aca9
Content-Type: text/plain; charset=ISO-8859-1

On Mon, Sep 24, 2012 at 8:05 AM, Jan Beulich <JBeulich@suse.com> wrote:

> >>> On 24.09.12 at 13:54, Ben Guthro <ben@guthro.net> wrote:
> > I see - Konrad - do you have a changeset I can look for with the features
> > Jan describes?
>
> Alternatively you could also stick a wbinvd() in the two possibly
> relevant places...
>
>
I tried doing this right before disable_nonboot_cpus() in power.c, to no
effect.

The behavior that I'm currently failing to understand seems to be a
heisenbug, exhibited by the 2 attached patches, which are essentially the
same, with a cpumask_copy in 2 different places.

When I have the debug copy just before do_suspend_lowlevel() -
(debug1.patch) the output changes to what I would expect:

(XEN) XXX: CACHE issue? before=1 after=1
That is, only CPU0 is initialized both before, and after the S3 cycle.

However, when that same copy is moved up to before disable_nonboot_cpus() -
as in debug2.patch - it seems to have an effect on the state afterward. I
would have expected this to be something like

(XEN) XXX: CACHE issue? before=3 after=1
But that is not what is actually printed.

I get
(XEN) XXX: CACHE issue? before=3 after=3
That is, the initialized bit is set for CPU1, when it shouldn't be.


It should be noted that even with the debug in that causes the value to be
what I expect, this does not in itself is not sufficient to get things
working entirely, as I then get stalls in the kernel rcu_sched




> Jan
>
> > On Mon, Sep 24, 2012 at 7:45 AM, Jan Beulich <JBeulich@suse.com> wrote:
> >
> >> >>> On 24.09.12 at 13:25, Ben Guthro <ben@guthro.net> wrote:
> >> > It is an older system (Core2) - so it may be using the default
> mechanism,
> >> > but I'd have to go dig up some processor docs to be sure.
> >>
> >> This is not just a matter of what the CPU supports, but also what
> >> info gets passed down from Dom0 - if e.g. your kernel doesn't
> >> have Konrad's P-/C-state patches, then there's no way for Xen to
> >> use any of the advanced methods.
> >>
> >> Jan
> >>
> >>
>
>
>
>

--14dae9340c89f81d9004ca71aca9
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br><br><div class=3D"gmail_quote">On Mon, Sep 24, 2012 at 8:05 AM, Jan Beu=
lich <span dir=3D"ltr">&lt;<a href=3D"mailto:JBeulich@suse.com" target=3D"_=
blank">JBeulich@suse.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmai=
l_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left=
:1ex">
<div class=3D"im">&gt;&gt;&gt; On 24.09.12 at 13:54, Ben Guthro &lt;<a href=
=3D"mailto:ben@guthro.net">ben@guthro.net</a>&gt; wrote:<br>
&gt; I see - Konrad - do you have a changeset I can look for with the featu=
res<br>
&gt; Jan describes?<br>
<br>
</div>Alternatively you could also stick a wbinvd() in the two possibly<br>
relevant places...<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br></font></span></blockquo=
te><div><br></div><div>I tried doing this right before=A0disable_nonboot_cp=
us() in power.c, to no effect.</div><div><br></div><div>The behavior that I=
&#39;m currently failing to understand seems to be a heisenbug, exhibited b=
y the 2 attached patches, which are essentially the same, with a cpumask_co=
py in 2 different places.</div>
<div><br></div><div>When I have the debug copy just before=A0do_suspend_low=
level() - (debug1.patch) the output changes to what I would expect:</div><d=
iv><br></div><div>(XEN) XXX: CACHE issue? before=3D1 after=3D1</div><div>Th=
at is, only CPU0 is initialized both before, and after the S3 cycle.</div>
<div><br></div><div>However, when that same copy is moved up to before=A0di=
sable_nonboot_cpus() - as in debug2.patch - it seems to have an effect on t=
he state afterward. I would have expected this to be something like=A0</div=
>
<div><br></div><div><div>(XEN) XXX: CACHE issue? before=3D3 after=3D1</div>=
</div><div>But that is not what is actually printed.</div><div><br></div><d=
iv>I get</div><div>(XEN) XXX: CACHE issue? before=3D3 after=3D3</div><div>T=
hat is, the initialized bit is set for CPU1, when it shouldn&#39;t be.</div=
>
<div><br></div><div><br></div><div>It should be noted that even with the de=
bug in that causes the value to be what I expect, this does not in itself i=
s not sufficient to get things working entirely, as I then get stalls in th=
e kernel rcu_sched</div>
<div><br></div><div><br></div><div>=A0</div><blockquote class=3D"gmail_quot=
e" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">=
<span class=3D"HOEnZb"><font color=3D"#888888">
Jan<br>
</font></span><div class=3D"HOEnZb"><div class=3D"h5"><br>
&gt; On Mon, Sep 24, 2012 at 7:45 AM, Jan Beulich &lt;<a href=3D"mailto:JBe=
ulich@suse.com">JBeulich@suse.com</a>&gt; wrote:<br>
&gt;<br>
&gt;&gt; &gt;&gt;&gt; On 24.09.12 at 13:25, Ben Guthro &lt;<a href=3D"mailt=
o:ben@guthro.net">ben@guthro.net</a>&gt; wrote:<br>
&gt;&gt; &gt; It is an older system (Core2) - so it may be using the defaul=
t mechanism,<br>
&gt;&gt; &gt; but I&#39;d have to go dig up some processor docs to be sure.=
<br>
&gt;&gt;<br>
&gt;&gt; This is not just a matter of what the CPU supports, but also what<=
br>
&gt;&gt; info gets passed down from Dom0 - if e.g. your kernel doesn&#39;t<=
br>
&gt;&gt; have Konrad&#39;s P-/C-state patches, then there&#39;s no way for =
Xen to<br>
&gt;&gt; use any of the advanced methods.<br>
&gt;&gt;<br>
&gt;&gt; Jan<br>
&gt;&gt;<br>
&gt;&gt;<br>
<br>
<br>
<br>
</div></div></blockquote></div><br>

--14dae9340c89f81d9004ca71aca9--
--14dae9340c89f81da404ca71acab
Content-Type: application/octet-stream; name="debug1.patch"
Content-Disposition: attachment; filename="debug1.patch"
Content-Transfer-Encoding: base64
X-Attachment-Id: f_h7hjbedd0

ZGlmZiAtLWdpdCBhL3hlbi9hcmNoL3g4Ni9hY3BpL3Bvd2VyLmMgYi94ZW4vYXJjaC94ODYvYWNw
aS9wb3dlci5jCmluZGV4IDllMWY5ODkuLjMzZTQ3ZmYgMTAwNjQ0Ci0tLSBhL3hlbi9hcmNoL3g4
Ni9hY3BpL3Bvd2VyLmMKKysrIGIveGVuL2FyY2gveDg2L2FjcGkvcG93ZXIuYwpAQCAtMTIyLDYg
KzEyMiwxMiBAQCBzdGF0aWMgdm9pZCBhY3BpX3NsZWVwX3ByZXBhcmUodTMyIHN0YXRlKQogCiBz
dGF0aWMgdm9pZCBhY3BpX3NsZWVwX3Bvc3QodTMyIHN0YXRlKSB7fQogCitzdGF0aWMgY3B1bWFz
a190IHRtcF9tYXNrMTsKK3N0YXRpYyBjcHVtYXNrX3QgdG1wX21hc2syOworc3RhdGljIGNoYXIg
dHN0cjFbMTAwXTsKK3N0YXRpYyBjaGFyIHRzdHIyWzEwMF07CitleHRlcm4gY3B1bWFza190IGNw
dV9pbml0aWFsaXplZDsKKwogLyogTWFpbiBpbnRlcmZhY2UgdG8gZG8geGVuIHNwZWNpZmljIHN1
c3BlbmQvcmVzdW1lICovCiBzdGF0aWMgaW50IGVudGVyX3N0YXRlKHUzMiBzdGF0ZSkKIHsKQEAg
LTE0NCw2ICsxNTAsNyBAQCBzdGF0aWMgaW50IGVudGVyX3N0YXRlKHUzMiBzdGF0ZSkKIAogICAg
IGFjcGlfZG1hcl9yZWluc3RhdGUoKTsKIAorICAgIC8vY3B1bWFza19jb3B5KCZ0bXBfbWFzazEs
ICZjcHVfaW5pdGlhbGl6ZWQpOwogICAgIGlmICggKGVycm9yID0gZGlzYWJsZV9ub25ib290X2Nw
dXMoKSkgKQogICAgIHsKICAgICAgICAgc3lzdGVtX3N0YXRlID0gU1lTX1NUQVRFX3Jlc3VtZTsK
QEAgLTE3NCw3ICsxODEsOSBAQCBzdGF0aWMgaW50IGVudGVyX3N0YXRlKHUzMiBzdGF0ZSkKICAg
ICBzd2l0Y2ggKCBzdGF0ZSApCiAgICAgewogICAgIGNhc2UgQUNQSV9TVEFURV9TMzoKKyAgICAg
ICAgY3B1bWFza19jb3B5KCZ0bXBfbWFzazEsICZjcHVfaW5pdGlhbGl6ZWQpOwogICAgICAgICBk
b19zdXNwZW5kX2xvd2xldmVsKCk7CisgICAgICAgIGNwdW1hc2tfY29weSgmdG1wX21hc2syLCAm
Y3B1X2luaXRpYWxpemVkKTsKICAgICAgICAgc3lzdGVtX3Jlc2V0X2NvdW50ZXIrKzsKICAgICAg
ICAgZXJyb3IgPSB0Ym9vdF9zM19yZXN1bWUoKTsKICAgICAgICAgYnJlYWs7CkBAIC0yMDQsNiAr
MjEzLDEwIEBAIHN0YXRpYyBpbnQgZW50ZXJfc3RhdGUodTMyIHN0YXRlKQogICAgIGlmICggKHN0
YXRlID09IEFDUElfU1RBVEVfUzMpICYmIGVycm9yICkKICAgICAgICAgdGJvb3RfczNfZXJyb3Io
ZXJyb3IpOwogCisgICAgY3B1bWFza19zY25wcmludGYodHN0cjEsIHNpemVvZih0c3RyMSksICZ0
bXBfbWFzazEpOworICAgIGNwdW1hc2tfc2NucHJpbnRmKHRzdHIyLCBzaXplb2YodHN0cjIpLCAm
dG1wX21hc2syKTsKKworICAgIHByaW50aygiWFhYOiBDQUNIRSBpc3N1ZT8gYmVmb3JlPSVzIGFm
dGVyPSVzXG4iLCB0c3RyMSwgdHN0cjIpOwogIGRvbmU6CiAgICAgc3Bpbl9kZWJ1Z19lbmFibGUo
KTsKICAgICBsb2NhbF9pcnFfcmVzdG9yZShmbGFncyk7CmRpZmYgLS1naXQgYS94ZW4vYXJjaC94
ODYvY3B1L2NvbW1vbi5jIGIveGVuL2FyY2gveDg2L2NwdS9jb21tb24uYwppbmRleCBkMDY2ZWJi
Li5iMmFhMzBiIDEwMDY0NAotLS0gYS94ZW4vYXJjaC94ODYvY3B1L2NvbW1vbi5jCisrKyBiL3hl
bi9hcmNoL3g4Ni9jcHUvY29tbW9uLmMKQEAgLTU4OCw3ICs1ODgsNyBAQCB2b2lkIF9fY3B1aW5p
dCBwcmludF9jcHVfaW5mbyh1bnNpZ25lZCBpbnQgY3B1KQogCXByaW50aygiIHN0ZXBwaW5nICUw
MnhcbiIsIGMtPng4Nl9tYXNrKTsKIH0KIAotc3RhdGljIGNwdW1hc2tfdCBjcHVfaW5pdGlhbGl6
ZWQ7CitjcHVtYXNrX3QgY3B1X2luaXRpYWxpemVkOwogCiAvKiBUaGlzIGlzIGhhY2t5LiA6KQog
ICogV2UncmUgZW11bGF0aW5nIGZ1dHVyZSBiZWhhdmlvci4K
--14dae9340c89f81da404ca71acab
Content-Type: application/octet-stream; name="debug2.patch"
Content-Disposition: attachment; filename="debug2.patch"
Content-Transfer-Encoding: base64
X-Attachment-Id: f_h7hjbjyv1

ZGlmZiAtLWdpdCBhL3hlbi9hcmNoL3g4Ni9hY3BpL3Bvd2VyLmMgYi94ZW4vYXJjaC94ODYvYWNw
aS9wb3dlci5jCmluZGV4IDllMWY5ODkuLmIwYjg4YzIgMTAwNjQ0Ci0tLSBhL3hlbi9hcmNoL3g4
Ni9hY3BpL3Bvd2VyLmMKKysrIGIveGVuL2FyY2gveDg2L2FjcGkvcG93ZXIuYwpAQCAtMTIyLDYg
KzEyMiwxMiBAQCBzdGF0aWMgdm9pZCBhY3BpX3NsZWVwX3ByZXBhcmUodTMyIHN0YXRlKQogCiBz
dGF0aWMgdm9pZCBhY3BpX3NsZWVwX3Bvc3QodTMyIHN0YXRlKSB7fQogCitzdGF0aWMgY3B1bWFz
a190IHRtcF9tYXNrMTsKK3N0YXRpYyBjcHVtYXNrX3QgdG1wX21hc2syOworc3RhdGljIGNoYXIg
dHN0cjFbMTAwXTsKK3N0YXRpYyBjaGFyIHRzdHIyWzEwMF07CitleHRlcm4gY3B1bWFza190IGNw
dV9pbml0aWFsaXplZDsKKwogLyogTWFpbiBpbnRlcmZhY2UgdG8gZG8geGVuIHNwZWNpZmljIHN1
c3BlbmQvcmVzdW1lICovCiBzdGF0aWMgaW50IGVudGVyX3N0YXRlKHUzMiBzdGF0ZSkKIHsKQEAg
LTE0NCw2ICsxNTAsNyBAQCBzdGF0aWMgaW50IGVudGVyX3N0YXRlKHUzMiBzdGF0ZSkKIAogICAg
IGFjcGlfZG1hcl9yZWluc3RhdGUoKTsKIAorICAgIGNwdW1hc2tfY29weSgmdG1wX21hc2sxLCAm
Y3B1X2luaXRpYWxpemVkKTsKICAgICBpZiAoIChlcnJvciA9IGRpc2FibGVfbm9uYm9vdF9jcHVz
KCkpICkKICAgICB7CiAgICAgICAgIHN5c3RlbV9zdGF0ZSA9IFNZU19TVEFURV9yZXN1bWU7CkBA
IC0xNzQsNyArMTgxLDkgQEAgc3RhdGljIGludCBlbnRlcl9zdGF0ZSh1MzIgc3RhdGUpCiAgICAg
c3dpdGNoICggc3RhdGUgKQogICAgIHsKICAgICBjYXNlIEFDUElfU1RBVEVfUzM6CisgICAgICAg
IC8vY3B1bWFza19jb3B5KCZ0bXBfbWFzazEsICZjcHVfaW5pdGlhbGl6ZWQpOwogICAgICAgICBk
b19zdXNwZW5kX2xvd2xldmVsKCk7CisgICAgICAgIGNwdW1hc2tfY29weSgmdG1wX21hc2syLCAm
Y3B1X2luaXRpYWxpemVkKTsKICAgICAgICAgc3lzdGVtX3Jlc2V0X2NvdW50ZXIrKzsKICAgICAg
ICAgZXJyb3IgPSB0Ym9vdF9zM19yZXN1bWUoKTsKICAgICAgICAgYnJlYWs7CkBAIC0yMDQsNiAr
MjEzLDEwIEBAIHN0YXRpYyBpbnQgZW50ZXJfc3RhdGUodTMyIHN0YXRlKQogICAgIGlmICggKHN0
YXRlID09IEFDUElfU1RBVEVfUzMpICYmIGVycm9yICkKICAgICAgICAgdGJvb3RfczNfZXJyb3Io
ZXJyb3IpOwogCisgICAgY3B1bWFza19zY25wcmludGYodHN0cjEsIHNpemVvZih0c3RyMSksICZ0
bXBfbWFzazEpOworICAgIGNwdW1hc2tfc2NucHJpbnRmKHRzdHIyLCBzaXplb2YodHN0cjIpLCAm
dG1wX21hc2syKTsKKworICAgIHByaW50aygiWFhYOiBDQUNIRSBpc3N1ZT8gYmVmb3JlPSVzIGFm
dGVyPSVzXG4iLCB0c3RyMSwgdHN0cjIpOwogIGRvbmU6CiAgICAgc3Bpbl9kZWJ1Z19lbmFibGUo
KTsKICAgICBsb2NhbF9pcnFfcmVzdG9yZShmbGFncyk7CmRpZmYgLS1naXQgYS94ZW4vYXJjaC94
ODYvY3B1L2NvbW1vbi5jIGIveGVuL2FyY2gveDg2L2NwdS9jb21tb24uYwppbmRleCBkMDY2ZWJi
Li5iMmFhMzBiIDEwMDY0NAotLS0gYS94ZW4vYXJjaC94ODYvY3B1L2NvbW1vbi5jCisrKyBiL3hl
bi9hcmNoL3g4Ni9jcHUvY29tbW9uLmMKQEAgLTU4OCw3ICs1ODgsNyBAQCB2b2lkIF9fY3B1aW5p
dCBwcmludF9jcHVfaW5mbyh1bnNpZ25lZCBpbnQgY3B1KQogCXByaW50aygiIHN0ZXBwaW5nICUw
MnhcbiIsIGMtPng4Nl9tYXNrKTsKIH0KIAotc3RhdGljIGNwdW1hc2tfdCBjcHVfaW5pdGlhbGl6
ZWQ7CitjcHVtYXNrX3QgY3B1X2luaXRpYWxpemVkOwogCiAvKiBUaGlzIGlzIGhhY2t5LiA6KQog
ICogV2UncmUgZW11bGF0aW5nIGZ1dHVyZSBiZWhhdmlvci4K
--14dae9340c89f81da404ca71acab
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--14dae9340c89f81da404ca71acab--


From xen-devel-bounces@lists.xen.org Mon Sep 24 12:25:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Sep 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 1TG7iZ-0007I1-1r; Mon, 24 Sep 2012 12:24:55 +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 1TG7iX-0007Hi-1r
	for xen-devel@lists.xen.org; Mon, 24 Sep 2012 12:24:53 +0000
Received: from [85.158.138.51:30235] by server-1.bemta-3.messagelabs.com id
	97/36-05884-41150605; Mon, 24 Sep 2012 12:24:52 +0000
X-Env-Sender: ben.guthro@gmail.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1348489489!31734439!1
X-Originating-IP: [209.85.223.173]
X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE,
	RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24793 invoked from network); 24 Sep 2012 12:24:50 -0000
Received: from mail-ie0-f173.google.com (HELO mail-ie0-f173.google.com)
	(209.85.223.173)
	by server-11.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Sep 2012 12:24:50 -0000
Received: by iea17 with SMTP id 17so7638016iea.32
	for <xen-devel@lists.xen.org>; Mon, 24 Sep 2012 05:24: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=z40qEf84lZUs63dixCFM9rsHukot6b22vcf8tNbureQ=;
	b=jm2OARXJesOa2AOSdhVrrqd+EW8h0RBy/8K1KvYetFj37gza8v2/Fti1s2EdvNGBL1
	UOA3EdpCP/78CVNSu9Rrkdx2NqDkw7bj/Gi+vPtGAUflIuSoV4DIZjYj1y9/tCxsEyIE
	ImKe4Kgk0OuOO+j7SN4V6MHw6C1pnGQY4w0bhQuVv4tiSv4VF+LMjlcAvbfVc/B+MZ9S
	yjWGJzodGSUAo6ZI9w3c4jMik1yvDoLFHfFugiaqPphjEo94fflpTdk+pJ3khQUJvx5W
	wCeGOFKWz9D3XIQBdyOsgUaqi2Vh3WIvX0tfndD7LMI+Y0MNMTl9F7YCz76yYepxm7n3
	xu3A==
MIME-Version: 1.0
Received: by 10.50.158.226 with SMTP id wx2mr4980691igb.70.1348489488899; Mon,
	24 Sep 2012 05:24:48 -0700 (PDT)
Received: by 10.64.55.132 with HTTP; Mon, 24 Sep 2012 05:24:48 -0700 (PDT)
In-Reply-To: <506068A0020000780009D519@nat28.tlf.novell.com>
References: <CAOvdn6XKPOMNn6AjuYvZvPXRRJffN3po5GXe1Yh1-m0hisMK_w@mail.gmail.com>
	<CC8273A0.4C9DD%keir@xen.org>
	<50605E9A020000780009D486@nat28.tlf.novell.com>
	<CAOvdn6XmB6rj3_QVU+59V8p24Y5G47AWxVEM=id02JWXkuhibQ@mail.gmail.com>
	<5060640B020000780009D4D2@nat28.tlf.novell.com>
	<CAOvdn6XLy8zR2rb2MEyi2aT9LQiFvFLY_H02p181mTsVLVTZkw@mail.gmail.com>
	<506068A0020000780009D519@nat28.tlf.novell.com>
Date: Mon, 24 Sep 2012 08:24:48 -0400
X-Google-Sender-Auth: MjJf2z0qjSK6KEhKK9ToyjIj1wE
Message-ID: <CAOvdn6Undn2srfNhW++wLfUNFQ5JnZ3rp5bg7DD_TDPCHqmP_A@mail.gmail.com>
From: Ben Guthro <ben@guthro.net>
To: Jan Beulich <JBeulich@suse.com>
Content-Type: multipart/mixed; boundary=14dae9340c89f81da404ca71acab
Cc: xen-devel <xen-devel@lists.xen.org>, Keir Fraser <keir@xen.org>,
	john.baboval@citrix.com, Thomas Goetz <thomas.goetz@citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] Xen4.2 S3 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>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--14dae9340c89f81da404ca71acab
Content-Type: multipart/alternative; boundary=14dae9340c89f81d9004ca71aca9

--14dae9340c89f81d9004ca71aca9
Content-Type: text/plain; charset=ISO-8859-1

On Mon, Sep 24, 2012 at 8:05 AM, Jan Beulich <JBeulich@suse.com> wrote:

> >>> On 24.09.12 at 13:54, Ben Guthro <ben@guthro.net> wrote:
> > I see - Konrad - do you have a changeset I can look for with the features
> > Jan describes?
>
> Alternatively you could also stick a wbinvd() in the two possibly
> relevant places...
>
>
I tried doing this right before disable_nonboot_cpus() in power.c, to no
effect.

The behavior that I'm currently failing to understand seems to be a
heisenbug, exhibited by the 2 attached patches, which are essentially the
same, with a cpumask_copy in 2 different places.

When I have the debug copy just before do_suspend_lowlevel() -
(debug1.patch) the output changes to what I would expect:

(XEN) XXX: CACHE issue? before=1 after=1
That is, only CPU0 is initialized both before, and after the S3 cycle.

However, when that same copy is moved up to before disable_nonboot_cpus() -
as in debug2.patch - it seems to have an effect on the state afterward. I
would have expected this to be something like

(XEN) XXX: CACHE issue? before=3 after=1
But that is not what is actually printed.

I get
(XEN) XXX: CACHE issue? before=3 after=3
That is, the initialized bit is set for CPU1, when it shouldn't be.


It should be noted that even with the debug in that causes the value to be
what I expect, this does not in itself is not sufficient to get things
working entirely, as I then get stalls in the kernel rcu_sched




> Jan
>
> > On Mon, Sep 24, 2012 at 7:45 AM, Jan Beulich <JBeulich@suse.com> wrote:
> >
> >> >>> On 24.09.12 at 13:25, Ben Guthro <ben@guthro.net> wrote:
> >> > It is an older system (Core2) - so it may be using the default
> mechanism,
> >> > but I'd have to go dig up some processor docs to be sure.
> >>
> >> This is not just a matter of what the CPU supports, but also what
> >> info gets passed down from Dom0 - if e.g. your kernel doesn't
> >> have Konrad's P-/C-state patches, then there's no way for Xen to
> >> use any of the advanced methods.
> >>
> >> Jan
> >>
> >>
>
>
>
>

--14dae9340c89f81d9004ca71aca9
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br><br><div class=3D"gmail_quote">On Mon, Sep 24, 2012 at 8:05 AM, Jan Beu=
lich <span dir=3D"ltr">&lt;<a href=3D"mailto:JBeulich@suse.com" target=3D"_=
blank">JBeulich@suse.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmai=
l_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left=
:1ex">
<div class=3D"im">&gt;&gt;&gt; On 24.09.12 at 13:54, Ben Guthro &lt;<a href=
=3D"mailto:ben@guthro.net">ben@guthro.net</a>&gt; wrote:<br>
&gt; I see - Konrad - do you have a changeset I can look for with the featu=
res<br>
&gt; Jan describes?<br>
<br>
</div>Alternatively you could also stick a wbinvd() in the two possibly<br>
relevant places...<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br></font></span></blockquo=
te><div><br></div><div>I tried doing this right before=A0disable_nonboot_cp=
us() in power.c, to no effect.</div><div><br></div><div>The behavior that I=
&#39;m currently failing to understand seems to be a heisenbug, exhibited b=
y the 2 attached patches, which are essentially the same, with a cpumask_co=
py in 2 different places.</div>
<div><br></div><div>When I have the debug copy just before=A0do_suspend_low=
level() - (debug1.patch) the output changes to what I would expect:</div><d=
iv><br></div><div>(XEN) XXX: CACHE issue? before=3D1 after=3D1</div><div>Th=
at is, only CPU0 is initialized both before, and after the S3 cycle.</div>
<div><br></div><div>However, when that same copy is moved up to before=A0di=
sable_nonboot_cpus() - as in debug2.patch - it seems to have an effect on t=
he state afterward. I would have expected this to be something like=A0</div=
>
<div><br></div><div><div>(XEN) XXX: CACHE issue? before=3D3 after=3D1</div>=
</div><div>But that is not what is actually printed.</div><div><br></div><d=
iv>I get</div><div>(XEN) XXX: CACHE issue? before=3D3 after=3D3</div><div>T=
hat is, the initialized bit is set for CPU1, when it shouldn&#39;t be.</div=
>
<div><br></div><div><br></div><div>It should be noted that even with the de=
bug in that causes the value to be what I expect, this does not in itself i=
s not sufficient to get things working entirely, as I then get stalls in th=
e kernel rcu_sched</div>
<div><br></div><div><br></div><div>=A0</div><blockquote class=3D"gmail_quot=
e" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">=
<span class=3D"HOEnZb"><font color=3D"#888888">
Jan<br>
</font></span><div class=3D"HOEnZb"><div class=3D"h5"><br>
&gt; On Mon, Sep 24, 2012 at 7:45 AM, Jan Beulich &lt;<a href=3D"mailto:JBe=
ulich@suse.com">JBeulich@suse.com</a>&gt; wrote:<br>
&gt;<br>
&gt;&gt; &gt;&gt;&gt; On 24.09.12 at 13:25, Ben Guthro &lt;<a href=3D"mailt=
o:ben@guthro.net">ben@guthro.net</a>&gt; wrote:<br>
&gt;&gt; &gt; It is an older system (Core2) - so it may be using the defaul=
t mechanism,<br>
&gt;&gt; &gt; but I&#39;d have to go dig up some processor docs to be sure.=
<br>
&gt;&gt;<br>
&gt;&gt; This is not just a matter of what the CPU supports, but also what<=
br>
&gt;&gt; info gets passed down from Dom0 - if e.g. your kernel doesn&#39;t<=
br>
&gt;&gt; have Konrad&#39;s P-/C-state patches, then there&#39;s no way for =
Xen to<br>
&gt;&gt; use any of the advanced methods.<br>
&gt;&gt;<br>
&gt;&gt; Jan<br>
&gt;&gt;<br>
&gt;&gt;<br>
<br>
<br>
<br>
</div></div></blockquote></div><br>

--14dae9340c89f81d9004ca71aca9--
--14dae9340c89f81da404ca71acab
Content-Type: application/octet-stream; name="debug1.patch"
Content-Disposition: attachment; filename="debug1.patch"
Content-Transfer-Encoding: base64
X-Attachment-Id: f_h7hjbedd0

ZGlmZiAtLWdpdCBhL3hlbi9hcmNoL3g4Ni9hY3BpL3Bvd2VyLmMgYi94ZW4vYXJjaC94ODYvYWNw
aS9wb3dlci5jCmluZGV4IDllMWY5ODkuLjMzZTQ3ZmYgMTAwNjQ0Ci0tLSBhL3hlbi9hcmNoL3g4
Ni9hY3BpL3Bvd2VyLmMKKysrIGIveGVuL2FyY2gveDg2L2FjcGkvcG93ZXIuYwpAQCAtMTIyLDYg
KzEyMiwxMiBAQCBzdGF0aWMgdm9pZCBhY3BpX3NsZWVwX3ByZXBhcmUodTMyIHN0YXRlKQogCiBz
dGF0aWMgdm9pZCBhY3BpX3NsZWVwX3Bvc3QodTMyIHN0YXRlKSB7fQogCitzdGF0aWMgY3B1bWFz
a190IHRtcF9tYXNrMTsKK3N0YXRpYyBjcHVtYXNrX3QgdG1wX21hc2syOworc3RhdGljIGNoYXIg
dHN0cjFbMTAwXTsKK3N0YXRpYyBjaGFyIHRzdHIyWzEwMF07CitleHRlcm4gY3B1bWFza190IGNw
dV9pbml0aWFsaXplZDsKKwogLyogTWFpbiBpbnRlcmZhY2UgdG8gZG8geGVuIHNwZWNpZmljIHN1
c3BlbmQvcmVzdW1lICovCiBzdGF0aWMgaW50IGVudGVyX3N0YXRlKHUzMiBzdGF0ZSkKIHsKQEAg
LTE0NCw2ICsxNTAsNyBAQCBzdGF0aWMgaW50IGVudGVyX3N0YXRlKHUzMiBzdGF0ZSkKIAogICAg
IGFjcGlfZG1hcl9yZWluc3RhdGUoKTsKIAorICAgIC8vY3B1bWFza19jb3B5KCZ0bXBfbWFzazEs
ICZjcHVfaW5pdGlhbGl6ZWQpOwogICAgIGlmICggKGVycm9yID0gZGlzYWJsZV9ub25ib290X2Nw
dXMoKSkgKQogICAgIHsKICAgICAgICAgc3lzdGVtX3N0YXRlID0gU1lTX1NUQVRFX3Jlc3VtZTsK
QEAgLTE3NCw3ICsxODEsOSBAQCBzdGF0aWMgaW50IGVudGVyX3N0YXRlKHUzMiBzdGF0ZSkKICAg
ICBzd2l0Y2ggKCBzdGF0ZSApCiAgICAgewogICAgIGNhc2UgQUNQSV9TVEFURV9TMzoKKyAgICAg
ICAgY3B1bWFza19jb3B5KCZ0bXBfbWFzazEsICZjcHVfaW5pdGlhbGl6ZWQpOwogICAgICAgICBk
b19zdXNwZW5kX2xvd2xldmVsKCk7CisgICAgICAgIGNwdW1hc2tfY29weSgmdG1wX21hc2syLCAm
Y3B1X2luaXRpYWxpemVkKTsKICAgICAgICAgc3lzdGVtX3Jlc2V0X2NvdW50ZXIrKzsKICAgICAg
ICAgZXJyb3IgPSB0Ym9vdF9zM19yZXN1bWUoKTsKICAgICAgICAgYnJlYWs7CkBAIC0yMDQsNiAr
MjEzLDEwIEBAIHN0YXRpYyBpbnQgZW50ZXJfc3RhdGUodTMyIHN0YXRlKQogICAgIGlmICggKHN0
YXRlID09IEFDUElfU1RBVEVfUzMpICYmIGVycm9yICkKICAgICAgICAgdGJvb3RfczNfZXJyb3Io
ZXJyb3IpOwogCisgICAgY3B1bWFza19zY25wcmludGYodHN0cjEsIHNpemVvZih0c3RyMSksICZ0
bXBfbWFzazEpOworICAgIGNwdW1hc2tfc2NucHJpbnRmKHRzdHIyLCBzaXplb2YodHN0cjIpLCAm
dG1wX21hc2syKTsKKworICAgIHByaW50aygiWFhYOiBDQUNIRSBpc3N1ZT8gYmVmb3JlPSVzIGFm
dGVyPSVzXG4iLCB0c3RyMSwgdHN0cjIpOwogIGRvbmU6CiAgICAgc3Bpbl9kZWJ1Z19lbmFibGUo
KTsKICAgICBsb2NhbF9pcnFfcmVzdG9yZShmbGFncyk7CmRpZmYgLS1naXQgYS94ZW4vYXJjaC94
ODYvY3B1L2NvbW1vbi5jIGIveGVuL2FyY2gveDg2L2NwdS9jb21tb24uYwppbmRleCBkMDY2ZWJi
Li5iMmFhMzBiIDEwMDY0NAotLS0gYS94ZW4vYXJjaC94ODYvY3B1L2NvbW1vbi5jCisrKyBiL3hl
bi9hcmNoL3g4Ni9jcHUvY29tbW9uLmMKQEAgLTU4OCw3ICs1ODgsNyBAQCB2b2lkIF9fY3B1aW5p
dCBwcmludF9jcHVfaW5mbyh1bnNpZ25lZCBpbnQgY3B1KQogCXByaW50aygiIHN0ZXBwaW5nICUw
MnhcbiIsIGMtPng4Nl9tYXNrKTsKIH0KIAotc3RhdGljIGNwdW1hc2tfdCBjcHVfaW5pdGlhbGl6
ZWQ7CitjcHVtYXNrX3QgY3B1X2luaXRpYWxpemVkOwogCiAvKiBUaGlzIGlzIGhhY2t5LiA6KQog
ICogV2UncmUgZW11bGF0aW5nIGZ1dHVyZSBiZWhhdmlvci4K
--14dae9340c89f81da404ca71acab
Content-Type: application/octet-stream; name="debug2.patch"
Content-Disposition: attachment; filename="debug2.patch"
Content-Transfer-Encoding: base64
X-Attachment-Id: f_h7hjbjyv1

ZGlmZiAtLWdpdCBhL3hlbi9hcmNoL3g4Ni9hY3BpL3Bvd2VyLmMgYi94ZW4vYXJjaC94ODYvYWNw
aS9wb3dlci5jCmluZGV4IDllMWY5ODkuLmIwYjg4YzIgMTAwNjQ0Ci0tLSBhL3hlbi9hcmNoL3g4
Ni9hY3BpL3Bvd2VyLmMKKysrIGIveGVuL2FyY2gveDg2L2FjcGkvcG93ZXIuYwpAQCAtMTIyLDYg
KzEyMiwxMiBAQCBzdGF0aWMgdm9pZCBhY3BpX3NsZWVwX3ByZXBhcmUodTMyIHN0YXRlKQogCiBz
dGF0aWMgdm9pZCBhY3BpX3NsZWVwX3Bvc3QodTMyIHN0YXRlKSB7fQogCitzdGF0aWMgY3B1bWFz
a190IHRtcF9tYXNrMTsKK3N0YXRpYyBjcHVtYXNrX3QgdG1wX21hc2syOworc3RhdGljIGNoYXIg
dHN0cjFbMTAwXTsKK3N0YXRpYyBjaGFyIHRzdHIyWzEwMF07CitleHRlcm4gY3B1bWFza190IGNw
dV9pbml0aWFsaXplZDsKKwogLyogTWFpbiBpbnRlcmZhY2UgdG8gZG8geGVuIHNwZWNpZmljIHN1
c3BlbmQvcmVzdW1lICovCiBzdGF0aWMgaW50IGVudGVyX3N0YXRlKHUzMiBzdGF0ZSkKIHsKQEAg
LTE0NCw2ICsxNTAsNyBAQCBzdGF0aWMgaW50IGVudGVyX3N0YXRlKHUzMiBzdGF0ZSkKIAogICAg
IGFjcGlfZG1hcl9yZWluc3RhdGUoKTsKIAorICAgIGNwdW1hc2tfY29weSgmdG1wX21hc2sxLCAm
Y3B1X2luaXRpYWxpemVkKTsKICAgICBpZiAoIChlcnJvciA9IGRpc2FibGVfbm9uYm9vdF9jcHVz
KCkpICkKICAgICB7CiAgICAgICAgIHN5c3RlbV9zdGF0ZSA9IFNZU19TVEFURV9yZXN1bWU7CkBA
IC0xNzQsNyArMTgxLDkgQEAgc3RhdGljIGludCBlbnRlcl9zdGF0ZSh1MzIgc3RhdGUpCiAgICAg
c3dpdGNoICggc3RhdGUgKQogICAgIHsKICAgICBjYXNlIEFDUElfU1RBVEVfUzM6CisgICAgICAg
IC8vY3B1bWFza19jb3B5KCZ0bXBfbWFzazEsICZjcHVfaW5pdGlhbGl6ZWQpOwogICAgICAgICBk
b19zdXNwZW5kX2xvd2xldmVsKCk7CisgICAgICAgIGNwdW1hc2tfY29weSgmdG1wX21hc2syLCAm
Y3B1X2luaXRpYWxpemVkKTsKICAgICAgICAgc3lzdGVtX3Jlc2V0X2NvdW50ZXIrKzsKICAgICAg
ICAgZXJyb3IgPSB0Ym9vdF9zM19yZXN1bWUoKTsKICAgICAgICAgYnJlYWs7CkBAIC0yMDQsNiAr
MjEzLDEwIEBAIHN0YXRpYyBpbnQgZW50ZXJfc3RhdGUodTMyIHN0YXRlKQogICAgIGlmICggKHN0
YXRlID09IEFDUElfU1RBVEVfUzMpICYmIGVycm9yICkKICAgICAgICAgdGJvb3RfczNfZXJyb3Io
ZXJyb3IpOwogCisgICAgY3B1bWFza19zY25wcmludGYodHN0cjEsIHNpemVvZih0c3RyMSksICZ0
bXBfbWFzazEpOworICAgIGNwdW1hc2tfc2NucHJpbnRmKHRzdHIyLCBzaXplb2YodHN0cjIpLCAm
dG1wX21hc2syKTsKKworICAgIHByaW50aygiWFhYOiBDQUNIRSBpc3N1ZT8gYmVmb3JlPSVzIGFm
dGVyPSVzXG4iLCB0c3RyMSwgdHN0cjIpOwogIGRvbmU6CiAgICAgc3Bpbl9kZWJ1Z19lbmFibGUo
KTsKICAgICBsb2NhbF9pcnFfcmVzdG9yZShmbGFncyk7CmRpZmYgLS1naXQgYS94ZW4vYXJjaC94
ODYvY3B1L2NvbW1vbi5jIGIveGVuL2FyY2gveDg2L2NwdS9jb21tb24uYwppbmRleCBkMDY2ZWJi
Li5iMmFhMzBiIDEwMDY0NAotLS0gYS94ZW4vYXJjaC94ODYvY3B1L2NvbW1vbi5jCisrKyBiL3hl
bi9hcmNoL3g4Ni9jcHUvY29tbW9uLmMKQEAgLTU4OCw3ICs1ODgsNyBAQCB2b2lkIF9fY3B1aW5p
dCBwcmludF9jcHVfaW5mbyh1bnNpZ25lZCBpbnQgY3B1KQogCXByaW50aygiIHN0ZXBwaW5nICUw
MnhcbiIsIGMtPng4Nl9tYXNrKTsKIH0KIAotc3RhdGljIGNwdW1hc2tfdCBjcHVfaW5pdGlhbGl6
ZWQ7CitjcHVtYXNrX3QgY3B1X2luaXRpYWxpemVkOwogCiAvKiBUaGlzIGlzIGhhY2t5LiA6KQog
ICogV2UncmUgZW11bGF0aW5nIGZ1dHVyZSBiZWhhdmlvci4K
--14dae9340c89f81da404ca71acab
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--14dae9340c89f81da404ca71acab--


From xen-devel-bounces@lists.xen.org Mon Sep 24 12:25:21 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Sep 2012 12:25: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 1TG7io-0007L9-MF; Mon, 24 Sep 2012 12:25:10 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1TG7in-0007Kj-21
	for Xen-devel@lists.xensource.com; Mon, 24 Sep 2012 12:25:09 +0000
Received: from [85.158.143.99:9793] by server-3.bemta-4.messagelabs.com id
	53/30-10986-42150605; Mon, 24 Sep 2012 12:25:08 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1348489506!24020189!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTA4NDk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13829 invoked from network); 24 Sep 2012 12:25: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;
	24 Sep 2012 12:25:07 -0000
X-IronPort-AV: E=Sophos;i="4.80,474,1344211200"; d="scan'208";a="14722808"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Sep 2012 12:25: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.279.1; Mon, 24 Sep 2012 13:25:04 +0100
Date: Mon, 24 Sep 2012 13:24:12 +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: <1348488991.3452.69.camel@zakaz.uk.xensource.com>
Message-ID: <alpine.DEB.2.02.1209241321240.29232@kaball.uk.xensource.com>
References: <20120921121556.1a0ea8af@mantra.us.oracle.com>
	<alpine.DEB.2.02.1209241228460.29232@kaball.uk.xensource.com>
	<1348488991.3452.69.camel@zakaz.uk.xensource.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v1 2/8]: PVH mmu changes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 24 Sep 2012, Ian Campbell wrote:
> On Mon, 2012-09-24 at 12:55 +0100, Stefano Stabellini wrote:
> > There are few code style issues on this patch, I suggest you run it
> > through scripts/checkpatch.pl, it should be able to catch all these
> > errors.
> 
> It would also be nice to starting having some changelogs entries for
> these patches for the next posting. There's a lot of complex stuff going
> on here.
> 
> > > @@ -2371,3 +2518,26 @@ out:
> > >  	return err;
> > >  }
> > >  EXPORT_SYMBOL_GPL(xen_remap_domain_mfn_range);
> > > +
> > > +/* Returns: Number of pages unmapped */
> > > +int xen_unmap_domain_mfn_range(struct vm_area_struct *vma,
> > > +			       struct xen_pvh_pfn_info *pvhp)
> > > +{
> > > +	int count = 0;
> > > +
> > > +	if (!pvhp || !xen_feature(XENFEAT_auto_translated_physmap))
> > > +		return 0;
> > > +
> > > +	while (pvhp->pi_next_todo--) {
> > > +		unsigned long pfn;
> > > +
> > > +		/* the mmu has already cleaned up the process mmu resources at
> > > +		 * this point (lookup_address will return NULL). */
> > > +		pfn = page_to_pfn(pvhp->pi_paga[pvhp->pi_next_todo]);
> > > +		pvh_rem_xen_p2m(pfn, 1);
> > > +		count++;
> > > +	}
> > > +	flush_tlb_all();
> > > +	return count;
> > 
> > Who is going to remove the corresponding mapping from the vma?
> > Also we might be able to replace the flush_tlb_all with a
> > flush_tlb_range.
> 
> I'm not convinced that a guest level TLB flush is either necessary or
> sufficient here. What we are doing is removing entries from the P2M
> which means that we need to do the appropriate HAP flush in the
> hypervisor, which must necessarily invalidate any stage 1 mappings which
> this flush might also touch (i.e. the HAP flush must be a super set of
> this flush).
> 
> Without the HAP flush in the hypervisor you risk guests being able to
> see old p2m mappings via the TLB entries which is a security issue
> AFAICT.

Yes, you are right, we need a flush in the hypervisor to flush the EPT.
It could probably live in the implementation of  XENMEM_add_to_physmap.

This one should be just for the vma mappings, so in the case of
xen_unmap_domain_mfn_range is unnecessary (given that it is
not removing the vma mappings).

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 24 12:25:21 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Sep 2012 12:25: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 1TG7io-0007L9-MF; Mon, 24 Sep 2012 12:25:10 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1TG7in-0007Kj-21
	for Xen-devel@lists.xensource.com; Mon, 24 Sep 2012 12:25:09 +0000
Received: from [85.158.143.99:9793] by server-3.bemta-4.messagelabs.com id
	53/30-10986-42150605; Mon, 24 Sep 2012 12:25:08 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1348489506!24020189!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTA4NDk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13829 invoked from network); 24 Sep 2012 12:25: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;
	24 Sep 2012 12:25:07 -0000
X-IronPort-AV: E=Sophos;i="4.80,474,1344211200"; d="scan'208";a="14722808"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Sep 2012 12:25: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.279.1; Mon, 24 Sep 2012 13:25:04 +0100
Date: Mon, 24 Sep 2012 13:24:12 +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: <1348488991.3452.69.camel@zakaz.uk.xensource.com>
Message-ID: <alpine.DEB.2.02.1209241321240.29232@kaball.uk.xensource.com>
References: <20120921121556.1a0ea8af@mantra.us.oracle.com>
	<alpine.DEB.2.02.1209241228460.29232@kaball.uk.xensource.com>
	<1348488991.3452.69.camel@zakaz.uk.xensource.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v1 2/8]: PVH mmu changes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 24 Sep 2012, Ian Campbell wrote:
> On Mon, 2012-09-24 at 12:55 +0100, Stefano Stabellini wrote:
> > There are few code style issues on this patch, I suggest you run it
> > through scripts/checkpatch.pl, it should be able to catch all these
> > errors.
> 
> It would also be nice to starting having some changelogs entries for
> these patches for the next posting. There's a lot of complex stuff going
> on here.
> 
> > > @@ -2371,3 +2518,26 @@ out:
> > >  	return err;
> > >  }
> > >  EXPORT_SYMBOL_GPL(xen_remap_domain_mfn_range);
> > > +
> > > +/* Returns: Number of pages unmapped */
> > > +int xen_unmap_domain_mfn_range(struct vm_area_struct *vma,
> > > +			       struct xen_pvh_pfn_info *pvhp)
> > > +{
> > > +	int count = 0;
> > > +
> > > +	if (!pvhp || !xen_feature(XENFEAT_auto_translated_physmap))
> > > +		return 0;
> > > +
> > > +	while (pvhp->pi_next_todo--) {
> > > +		unsigned long pfn;
> > > +
> > > +		/* the mmu has already cleaned up the process mmu resources at
> > > +		 * this point (lookup_address will return NULL). */
> > > +		pfn = page_to_pfn(pvhp->pi_paga[pvhp->pi_next_todo]);
> > > +		pvh_rem_xen_p2m(pfn, 1);
> > > +		count++;
> > > +	}
> > > +	flush_tlb_all();
> > > +	return count;
> > 
> > Who is going to remove the corresponding mapping from the vma?
> > Also we might be able to replace the flush_tlb_all with a
> > flush_tlb_range.
> 
> I'm not convinced that a guest level TLB flush is either necessary or
> sufficient here. What we are doing is removing entries from the P2M
> which means that we need to do the appropriate HAP flush in the
> hypervisor, which must necessarily invalidate any stage 1 mappings which
> this flush might also touch (i.e. the HAP flush must be a super set of
> this flush).
> 
> Without the HAP flush in the hypervisor you risk guests being able to
> see old p2m mappings via the TLB entries which is a security issue
> AFAICT.

Yes, you are right, we need a flush in the hypervisor to flush the EPT.
It could probably live in the implementation of  XENMEM_add_to_physmap.

This one should be just for the vma mappings, so in the case of
xen_unmap_domain_mfn_range is unnecessary (given that it is
not removing the vma mappings).

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 24 12:27:45 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Sep 2012 12:27: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 1TG7lA-0007ZI-8Q; Mon, 24 Sep 2012 12:27:36 +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 1TG7l9-0007ZB-8N
	for xen-devel@lists.xen.org; Mon, 24 Sep 2012 12:27:35 +0000
Received: from [85.158.137.99:9890] by server-13.bemta-3.messagelabs.com id
	1B/96-01606-6B150605; Mon, 24 Sep 2012 12:27:34 +0000
X-Env-Sender: ben.guthro@gmail.com
X-Msg-Ref: server-5.tower-217.messagelabs.com!1348489651!14154336!1
X-Originating-IP: [209.85.223.173]
X-SpamReason: No, hits=0.9 required=7.0 tests=HTML_40_50,HTML_MESSAGE,
	RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9157 invoked from network); 24 Sep 2012 12:27:33 -0000
Received: from mail-ie0-f173.google.com (HELO mail-ie0-f173.google.com)
	(209.85.223.173)
	by server-5.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Sep 2012 12:27:33 -0000
Received: by iea17 with SMTP id 17so7645230iea.32
	for <xen-devel@lists.xen.org>; Mon, 24 Sep 2012 05:27:31 -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=Gp4/zmVfVzjt2PE6yor+fPJ76NEjdg78P9CWMyKzDY0=;
	b=n2mVyYbCSre3P5EJUpfIlHzdxwwu8WTzlnsWnpTiA1mt/EP8xlINEnBj2IoSaUt5Yf
	4nKz4jC0gOv5Z5Px6lkRKgISlNfUre0Fh/QgL0Rh8SvSvdksWdNo/JgqzGUmdyZT2iUb
	iUdMzSc2zEtdc9bynBbxgs1TrQH7883eXZYOKX9er8oaKVfmXJOboY65WD4dDX7LIinF
	Sw3Hg9n+DFDOz8RtzukukCDtSQgb8zs5ziYUSqsOhSUKk2Ht3Q+CUKA9HlJuTRj8rGIf
	LiOq5UKQaVpPRAQ2qB5ckB1r0DKtpPV4gicTzXZ6M5UIoxk8rxaehL7EP3YoMzZx+Rjl
	FNZg==
MIME-Version: 1.0
Received: by 10.50.197.231 with SMTP id ix7mr5091278igc.54.1348489651149; Mon,
	24 Sep 2012 05:27:31 -0700 (PDT)
Received: by 10.64.55.132 with HTTP; Mon, 24 Sep 2012 05:27:31 -0700 (PDT)
In-Reply-To: <20120924122203.GG8912@reaktio.net>
References: <CAOvdn6XKPOMNn6AjuYvZvPXRRJffN3po5GXe1Yh1-m0hisMK_w@mail.gmail.com>
	<CC8273A0.4C9DD%keir@xen.org>
	<50605E9A020000780009D486@nat28.tlf.novell.com>
	<CAOvdn6XmB6rj3_QVU+59V8p24Y5G47AWxVEM=id02JWXkuhibQ@mail.gmail.com>
	<5060640B020000780009D4D2@nat28.tlf.novell.com>
	<CAOvdn6XLy8zR2rb2MEyi2aT9LQiFvFLY_H02p181mTsVLVTZkw@mail.gmail.com>
	<20120924122203.GG8912@reaktio.net>
Date: Mon, 24 Sep 2012 08:27:31 -0400
X-Google-Sender-Auth: GWvqeBt5rM959fBAaHY0UQzjLbc
Message-ID: <CAOvdn6XV4eoA-FfFns1xhx7HCUqXc7KHxZwyKuT4FHG8s3R5RQ@mail.gmail.com>
From: Ben Guthro <ben@guthro.net>
To: =?ISO-8859-1?Q?Pasi_K=E4rkk=E4inen?= <pasik@iki.fi>
Cc: Keir Fraser <keir@xen.org>, john.baboval@citrix.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	xen-devel <xen-devel@lists.xen.org>, Jan Beulich <JBeulich@suse.com>,
	Thomas Goetz <thomas.goetz@citrix.com>
Subject: Re: [Xen-devel] Xen4.2 S3 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: multipart/mixed; boundary="===============8214591420045908854=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============8214591420045908854==
Content-Type: multipart/alternative; boundary=14dae93404bba3dceb04ca71b6ae

--14dae93404bba3dceb04ca71b6ae
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Mon, Sep 24, 2012 at 8:22 AM, Pasi K=E4rkk=E4inen <pasik@iki.fi> wrote:

> On Mon, Sep 24, 2012 at 07:54:05AM -0400, Ben Guthro wrote:
> >    I see - Konrad - do you have a changeset I can look for with the
> features
> >    Jan describes?
>
> xen-acpi-processor driver was merged to upstream Linux kernel v3.4.
>
>
I see - so the advanced methods are not being used then
This same kernel does work with Xen-4.0.x though. Is there an assumption in
the code that ties Xen-4.2 to a newer kernel?



> -- Pasi
>
> >    On Mon, Sep 24, 2012 at 7:45 AM, Jan Beulich <[1]JBeulich@suse.com>
> wrote:
> >
> >      >>> On 24.09.12 at 13:25, Ben Guthro <[2]ben@guthro.net> wrote:
> >      > It is an older system (Core2) - so it may be using the default
> >      mechanism,
> >      > but I'd have to go dig up some processor docs to be sure.
> >
> >      This is not just a matter of what the CPU supports, but also what
> >      info gets passed down from Dom0 - if e.g. your kernel doesn't
> >      have Konrad's P-/C-state patches, then there's no way for Xen to
> >      use any of the advanced methods.
> >      Jan
> >
> > References
> >
> >    Visible links
> >    1. mailto:JBeulich@suse.com
> >    2. mailto:ben@guthro.net
>
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xen.org
> > http://lists.xen.org/xen-devel
>
>

--14dae93404bba3dceb04ca71b6ae
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div class=3D"gmail_quote">On Mon, Sep 24, 2012 at 8:22 AM, Pasi K=E4rkk=E4=
inen <span dir=3D"ltr">&lt;<a href=3D"mailto:pasik@iki.fi" target=3D"_blank=
">pasik@iki.fi</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class=3D"im">On Mon, Sep 24, 2012 at 07:54:05AM -0400, Ben Guthro wrot=
e:<br>
&gt; =A0 =A0I see - Konrad - do you have a changeset I can look for with th=
e features<br>
&gt; =A0 =A0Jan describes?<br>
<br>
</div>xen-acpi-processor driver was merged to upstream Linux kernel v3.4.<b=
r>
<br></blockquote><div><br></div><div>I see - so the advanced methods are no=
t being used then</div><div>This same kernel does work with Xen-4.0.x thoug=
h. Is there an assumption in the code that ties Xen-4.2 to a newer kernel?<=
/div>
<div><br></div><div>=A0</div><blockquote class=3D"gmail_quote" style=3D"mar=
gin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
-- Pasi<br>
<br>
&gt; =A0 =A0On Mon, Sep 24, 2012 at 7:45 AM, Jan Beulich &lt;[1]<a href=3D"=
mailto:JBeulich@suse.com">JBeulich@suse.com</a>&gt; wrote:<br>
<div class=3D"im">&gt;<br>
&gt; =A0 =A0 =A0&gt;&gt;&gt; On 24.09.12 at 13:25, Ben Guthro &lt;[2]<a hre=
f=3D"mailto:ben@guthro.net">ben@guthro.net</a>&gt; wrote:<br>
&gt; =A0 =A0 =A0&gt; It is an older system (Core2) - so it may be using the=
 default<br>
&gt; =A0 =A0 =A0mechanism,<br>
&gt; =A0 =A0 =A0&gt; but I&#39;d have to go dig up some processor docs to b=
e sure.<br>
&gt;<br>
&gt; =A0 =A0 =A0This is not just a matter of what the CPU supports, but als=
o what<br>
&gt; =A0 =A0 =A0info gets passed down from Dom0 - if e.g. your kernel doesn=
&#39;t<br>
&gt; =A0 =A0 =A0have Konrad&#39;s P-/C-state patches, then there&#39;s no w=
ay for Xen to<br>
&gt; =A0 =A0 =A0use any of the advanced methods.<br>
&gt; =A0 =A0 =A0Jan<br>
&gt;<br>
</div>&gt; References<br>
&gt;<br>
&gt; =A0 =A0Visible links<br>
&gt; =A0 =A01. mailto:<a href=3D"mailto:JBeulich@suse.com">JBeulich@suse.co=
m</a><br>
&gt; =A0 =A02. mailto:<a href=3D"mailto:ben@guthro.net">ben@guthro.net</a><=
br>
<div class=3D"HOEnZb"><div class=3D"h5"><br>
&gt; _______________________________________________<br>
&gt; Xen-devel mailing list<br>
&gt; <a href=3D"mailto:Xen-devel@lists.xen.org">Xen-devel@lists.xen.org</a>=
<br>
&gt; <a href=3D"http://lists.xen.org/xen-devel" target=3D"_blank">http://li=
sts.xen.org/xen-devel</a><br>
<br>
</div></div></blockquote></div><br>

--14dae93404bba3dceb04ca71b6ae--


--===============8214591420045908854==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============8214591420045908854==--


From xen-devel-bounces@lists.xen.org Mon Sep 24 12:27:45 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Sep 2012 12:27: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 1TG7lA-0007ZI-8Q; Mon, 24 Sep 2012 12:27:36 +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 1TG7l9-0007ZB-8N
	for xen-devel@lists.xen.org; Mon, 24 Sep 2012 12:27:35 +0000
Received: from [85.158.137.99:9890] by server-13.bemta-3.messagelabs.com id
	1B/96-01606-6B150605; Mon, 24 Sep 2012 12:27:34 +0000
X-Env-Sender: ben.guthro@gmail.com
X-Msg-Ref: server-5.tower-217.messagelabs.com!1348489651!14154336!1
X-Originating-IP: [209.85.223.173]
X-SpamReason: No, hits=0.9 required=7.0 tests=HTML_40_50,HTML_MESSAGE,
	RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9157 invoked from network); 24 Sep 2012 12:27:33 -0000
Received: from mail-ie0-f173.google.com (HELO mail-ie0-f173.google.com)
	(209.85.223.173)
	by server-5.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Sep 2012 12:27:33 -0000
Received: by iea17 with SMTP id 17so7645230iea.32
	for <xen-devel@lists.xen.org>; Mon, 24 Sep 2012 05:27:31 -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=Gp4/zmVfVzjt2PE6yor+fPJ76NEjdg78P9CWMyKzDY0=;
	b=n2mVyYbCSre3P5EJUpfIlHzdxwwu8WTzlnsWnpTiA1mt/EP8xlINEnBj2IoSaUt5Yf
	4nKz4jC0gOv5Z5Px6lkRKgISlNfUre0Fh/QgL0Rh8SvSvdksWdNo/JgqzGUmdyZT2iUb
	iUdMzSc2zEtdc9bynBbxgs1TrQH7883eXZYOKX9er8oaKVfmXJOboY65WD4dDX7LIinF
	Sw3Hg9n+DFDOz8RtzukukCDtSQgb8zs5ziYUSqsOhSUKk2Ht3Q+CUKA9HlJuTRj8rGIf
	LiOq5UKQaVpPRAQ2qB5ckB1r0DKtpPV4gicTzXZ6M5UIoxk8rxaehL7EP3YoMzZx+Rjl
	FNZg==
MIME-Version: 1.0
Received: by 10.50.197.231 with SMTP id ix7mr5091278igc.54.1348489651149; Mon,
	24 Sep 2012 05:27:31 -0700 (PDT)
Received: by 10.64.55.132 with HTTP; Mon, 24 Sep 2012 05:27:31 -0700 (PDT)
In-Reply-To: <20120924122203.GG8912@reaktio.net>
References: <CAOvdn6XKPOMNn6AjuYvZvPXRRJffN3po5GXe1Yh1-m0hisMK_w@mail.gmail.com>
	<CC8273A0.4C9DD%keir@xen.org>
	<50605E9A020000780009D486@nat28.tlf.novell.com>
	<CAOvdn6XmB6rj3_QVU+59V8p24Y5G47AWxVEM=id02JWXkuhibQ@mail.gmail.com>
	<5060640B020000780009D4D2@nat28.tlf.novell.com>
	<CAOvdn6XLy8zR2rb2MEyi2aT9LQiFvFLY_H02p181mTsVLVTZkw@mail.gmail.com>
	<20120924122203.GG8912@reaktio.net>
Date: Mon, 24 Sep 2012 08:27:31 -0400
X-Google-Sender-Auth: GWvqeBt5rM959fBAaHY0UQzjLbc
Message-ID: <CAOvdn6XV4eoA-FfFns1xhx7HCUqXc7KHxZwyKuT4FHG8s3R5RQ@mail.gmail.com>
From: Ben Guthro <ben@guthro.net>
To: =?ISO-8859-1?Q?Pasi_K=E4rkk=E4inen?= <pasik@iki.fi>
Cc: Keir Fraser <keir@xen.org>, john.baboval@citrix.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	xen-devel <xen-devel@lists.xen.org>, Jan Beulich <JBeulich@suse.com>,
	Thomas Goetz <thomas.goetz@citrix.com>
Subject: Re: [Xen-devel] Xen4.2 S3 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: multipart/mixed; boundary="===============8214591420045908854=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============8214591420045908854==
Content-Type: multipart/alternative; boundary=14dae93404bba3dceb04ca71b6ae

--14dae93404bba3dceb04ca71b6ae
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Mon, Sep 24, 2012 at 8:22 AM, Pasi K=E4rkk=E4inen <pasik@iki.fi> wrote:

> On Mon, Sep 24, 2012 at 07:54:05AM -0400, Ben Guthro wrote:
> >    I see - Konrad - do you have a changeset I can look for with the
> features
> >    Jan describes?
>
> xen-acpi-processor driver was merged to upstream Linux kernel v3.4.
>
>
I see - so the advanced methods are not being used then
This same kernel does work with Xen-4.0.x though. Is there an assumption in
the code that ties Xen-4.2 to a newer kernel?



> -- Pasi
>
> >    On Mon, Sep 24, 2012 at 7:45 AM, Jan Beulich <[1]JBeulich@suse.com>
> wrote:
> >
> >      >>> On 24.09.12 at 13:25, Ben Guthro <[2]ben@guthro.net> wrote:
> >      > It is an older system (Core2) - so it may be using the default
> >      mechanism,
> >      > but I'd have to go dig up some processor docs to be sure.
> >
> >      This is not just a matter of what the CPU supports, but also what
> >      info gets passed down from Dom0 - if e.g. your kernel doesn't
> >      have Konrad's P-/C-state patches, then there's no way for Xen to
> >      use any of the advanced methods.
> >      Jan
> >
> > References
> >
> >    Visible links
> >    1. mailto:JBeulich@suse.com
> >    2. mailto:ben@guthro.net
>
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xen.org
> > http://lists.xen.org/xen-devel
>
>

--14dae93404bba3dceb04ca71b6ae
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div class=3D"gmail_quote">On Mon, Sep 24, 2012 at 8:22 AM, Pasi K=E4rkk=E4=
inen <span dir=3D"ltr">&lt;<a href=3D"mailto:pasik@iki.fi" target=3D"_blank=
">pasik@iki.fi</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class=3D"im">On Mon, Sep 24, 2012 at 07:54:05AM -0400, Ben Guthro wrot=
e:<br>
&gt; =A0 =A0I see - Konrad - do you have a changeset I can look for with th=
e features<br>
&gt; =A0 =A0Jan describes?<br>
<br>
</div>xen-acpi-processor driver was merged to upstream Linux kernel v3.4.<b=
r>
<br></blockquote><div><br></div><div>I see - so the advanced methods are no=
t being used then</div><div>This same kernel does work with Xen-4.0.x thoug=
h. Is there an assumption in the code that ties Xen-4.2 to a newer kernel?<=
/div>
<div><br></div><div>=A0</div><blockquote class=3D"gmail_quote" style=3D"mar=
gin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
-- Pasi<br>
<br>
&gt; =A0 =A0On Mon, Sep 24, 2012 at 7:45 AM, Jan Beulich &lt;[1]<a href=3D"=
mailto:JBeulich@suse.com">JBeulich@suse.com</a>&gt; wrote:<br>
<div class=3D"im">&gt;<br>
&gt; =A0 =A0 =A0&gt;&gt;&gt; On 24.09.12 at 13:25, Ben Guthro &lt;[2]<a hre=
f=3D"mailto:ben@guthro.net">ben@guthro.net</a>&gt; wrote:<br>
&gt; =A0 =A0 =A0&gt; It is an older system (Core2) - so it may be using the=
 default<br>
&gt; =A0 =A0 =A0mechanism,<br>
&gt; =A0 =A0 =A0&gt; but I&#39;d have to go dig up some processor docs to b=
e sure.<br>
&gt;<br>
&gt; =A0 =A0 =A0This is not just a matter of what the CPU supports, but als=
o what<br>
&gt; =A0 =A0 =A0info gets passed down from Dom0 - if e.g. your kernel doesn=
&#39;t<br>
&gt; =A0 =A0 =A0have Konrad&#39;s P-/C-state patches, then there&#39;s no w=
ay for Xen to<br>
&gt; =A0 =A0 =A0use any of the advanced methods.<br>
&gt; =A0 =A0 =A0Jan<br>
&gt;<br>
</div>&gt; References<br>
&gt;<br>
&gt; =A0 =A0Visible links<br>
&gt; =A0 =A01. mailto:<a href=3D"mailto:JBeulich@suse.com">JBeulich@suse.co=
m</a><br>
&gt; =A0 =A02. mailto:<a href=3D"mailto:ben@guthro.net">ben@guthro.net</a><=
br>
<div class=3D"HOEnZb"><div class=3D"h5"><br>
&gt; _______________________________________________<br>
&gt; Xen-devel mailing list<br>
&gt; <a href=3D"mailto:Xen-devel@lists.xen.org">Xen-devel@lists.xen.org</a>=
<br>
&gt; <a href=3D"http://lists.xen.org/xen-devel" target=3D"_blank">http://li=
sts.xen.org/xen-devel</a><br>
<br>
</div></div></blockquote></div><br>

--14dae93404bba3dceb04ca71b6ae--


--===============8214591420045908854==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============8214591420045908854==--


From xen-devel-bounces@lists.xen.org Mon Sep 24 12:28:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Sep 2012 12: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 1TG7lb-0007d2-MD; Mon, 24 Sep 2012 12:28:03 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <linux@eikelenboom.it>) id 1TG7lZ-0007cX-A4
	for xen-devel@lists.xensource.com; Mon, 24 Sep 2012 12:28:02 +0000
Received: from [85.158.137.99:17798] by server-13.bemta-3.messagelabs.com id
	ED/47-01606-0D150605; Mon, 24 Sep 2012 12:28:00 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-16.tower-217.messagelabs.com!1348489679!18896350!1
X-Originating-IP: [188.40.164.121]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16598 invoked from network); 24 Sep 2012 12:27:59 -0000
Received: from static.121.164.40.188.clients.your-server.de (HELO
	smtp.eikelenboom.it) (188.40.164.121)
	by server-16.tower-217.messagelabs.com with AES256-SHA encrypted SMTP;
	24 Sep 2012 12:27:59 -0000
Received: from 132-64-ftth.onsneteindhoven.nl ([88.159.64.132]:53112
	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 1TG7mF-00044G-R4; Mon, 24 Sep 2012 14:28:43 +0200
Date: Mon, 24 Sep 2012 14:27:56 +0200
From: Sander Eikelenboom <linux@eikelenboom.it>
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <1264531695.20120924142756@eikelenboom.it>
To: Wei Wang <wei.wang2@amd.com>
In-Reply-To: <74647167<506050F0.7020703@amd.com>
References: <504764E2.4000809@amd.com>
	<326589347.20120906005936@eikelenboom.it>
	<5048A603.3070207@amd.com>
	<483486315.20120906155001@eikelenboom.it>
	<5048BB29.4040900@amd.com>
	<488803362.20120907093241@eikelenboom.it>
	<5049B650.4080101@amd.com> <74647167 <506050F0.7020703@amd.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH] amd iommu: Dump flags of IO page faults
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


Monday, September 24, 2012, 2:24:16 PM, you wrote:

> On 09/24/2012 10:38 AM, Sander Eikelenboom wrote:
>>
>> Friday, September 7, 2012, 10:54:40 AM, you wrote:
>>
>>> On 09/07/2012 09:32 AM, Sander Eikelenboom wrote:
>>>>
>>>> Thursday, September 6, 2012, 5:03:05 PM, you wrote:
>>>>
>>>>> On 09/06/2012 03:50 PM, Sander Eikelenboom wrote:
>>>>>>
>>>>>> Thursday, September 6, 2012, 3:32:51 PM, you wrote:
>>>>>>
>>>>>>> On 09/06/2012 12:59 AM, Sander Eikelenboom wrote:
>>>>>>>>
>>>>>>>> Wednesday, September 5, 2012, 4:42:42 PM, you wrote:
>>>>>>>>
>>>>>>>>> Hi Jan,
>>>>>>>>> Attached patch dumps io page fault flags. The flags show the reason of
>>>>>>>>> the fault and tell us if this is an unmapped interrupt fault or a DMA fault.
>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> Wei
>>>>>>>>
>>>>>>>>> signed-off-by: Wei Wang<wei.wang2@amd.com>
>>>>>>>>
>>>>>>>>
>>>>>>>> I have applied the patch and the flags seem to differ between the faults:
>>>>>>>>
>>>>>>>> AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0a06, fault address = 0xc2c2c2c0, flags = 0x000
>>>>>>>> (XEN) [2012-09-05 20:54:16] AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0a06, fault address = 0xc2c2c2c0, flags = 0x000
>>>>>>>> (XEN) [2012-09-05 20:54:16] AMD-Vi: IO_PAGE_FAULT: domain = 14, device id = 0x0700, fault address = 0xa8d339e0, flags = 0x020
>>>>>>>> (XEN) [2012-09-05 20:54:16] AMD-Vi: IO_PAGE_FAULT: domain = 14, device id = 0x0700, fault address = 0xa8d33a40, flags = 0x020
>>>>>>
>>>>>>> OK, so they are not interrupt requests. I guess further information from
>>>>>>> your system would be helpful to debug this issue:
>>>>>>> 1) xl info
>>>>>>> 2) xl list
>>>>>>> 3) lscpi -vvv (NOTE: not in dom0 but in your guest)
>>>>>>> 4) cat /proc/iomem (in both dom0 and your hvm guest)
>>>>>>
>>>>>> dom14 is not a HVM guest,it's a PV guest.
>>>>
>>>>> Ah, I see. PV guest is quite different than hvm, it does use p2m tables
>>>>> as io page tables. So no-sharept option does not work in this case. PV
>>>>> guests always use separated io page tables. There might be some
>>>>> incorrect mappings on the page tables. I will check this on my side.
>>>>
>>>> I have reverted the machine to xen-4.1.4-pre (changeset 23353) and kept everything else the same.
>>>> I haven't seen any IO PAGE FAULTS after that.
>>>>
>>>> I did spot some differences in the output from lspci between xen 4.1 and 4.2, related to MSI enabled or not for the IOMMU device.
>>>> Have attached the xl/xm dmesg and lspci from booting with both versions.
>>>>
>>>> lspci:
>>>>
>>>> 00:00.2 Generic system peripheral [0806]: ATI Technologies Inc RD990 I/O Memory Management Unit (IOMMU) [1002:5a23]
>>>>           Subsystem: ATI Technologies Inc RD990 I/O Memory Management Unit (IOMMU) [1002:5a23]
>>>>           Control: I/O- Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
>>>>           Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast>TAbort-<TAbort-<MAbort->SERR-<PERR- INTx-
>>>>           Latency: 0
>>>>           Interrupt: pin A routed to IRQ 10
>>>>           Capabilities: [40] Secure device<?>
>>>> 4.1:    Capabilities: [54] MSI: Enable- Count=1/1 Maskable- 64bit+
>>
>>> Eh... That is interesting. So which dom0 are you using?  There is a c/s
>>> in 4.2 to prevent recent dom0 to disable iommu interrupt (changeset
>>> 25492:61844569a432) Otherwise, iommu cannot send any events including IO
>>> PAGE faults. You could try to revert dom0 to an old version like 2.6
>>> pv_ops to see if you really have no io page faults on 4.1
>>
>> Ok i finally got the time to do some more testing, tested 4.2 around that changeset, and made a copy of the guest using HVM instead of PV.
>>
>> The results:
>> - On xen-4.1.* and a 3.6-rc6 kernel (dom0 and domU):  the video device passed through works fine, both in a HVM as a PV guest, i don't see IO page faults getting reported.
>> - On xen-4.2 changeset<   25492 and a 3.6-rc6 kernel (dom0 and domU):  the video device passed through works fine, both in a HVM as a PV guest, i don't see IO page faults getting reported.
>> - On xen-4.2 changeset>   25492 and a 3.6-rc6 kernel (dom0 and domU): the video device passed through works fine for a short while (around 5 to 10 minutes) in a PV guest, after that IO page faults get reported and the video freezes, i don't see any errors in the guest though.
>> - On xen-unstable tip and a 3.6-rc6 kernel (dom0 and domU):
>>                                                        PV:  the video device passed through works fine for a short while (around 5 to 10 minutes), after that IO page faults get reported and the video freezes, i don't see any errors in the guest though.
>>                                                        HVM: the video device passed through doesn't work from the start:
>>                                                                       - The device is there according to lspci
>>                                                                       - The video application start fine, but delivers a green image, so the device is not working properly. I don't see IO page faults though.
>>
>> Attached are (all with xen-unstable tip and the guest as HVM (domain 15):
>> - xl dmesg
>> - Patch which adds some more info, but all values reported seem to be zero (see xl dmesg)
>> - lspci dom0
>> - lspci HVM guest

> HI,
> Thanks for the information, very very helpful for debugging. I hope I 
> could start to look at this right after sending my next iommu patch 
> queue upstream...another question is: Did you see this issue on a single 
> pv/hvm guest system or you only saw it on a system with about 16 running 
> VMs?

> Thanks,
> Wei

If you need more info, i'm more than happy to run additional debug patches.
Haven't tested it with a single guest, will try right a way

Thanks !

--
Sander


>>
>>
>>
>>>> 4.2:    Capabilities: [54] MSI: Enable+ Count=1/1 Maskable- 64bit+
>>>>                   Address: 00000000fee0100c  Data: 4128
>>>>           Capabilities: [64] HyperTransport: MSI Mapping Enable+ Fixed+
>>>>
>>>> Although it seems enabled, shouldn't the IRQ number used be much higher than 10 for MSI interrupts ?
>>
>>> The IRQ number is fine. MSI vector is stored at  Data: 4128
>>
>>>>
>>>> There is another difference in the bridge device that's in front of the  0a:00.6 device that faults before the kernel is even booted.
>>>>
>>>> 00:03.0 PCI bridge [0604]: ATI Technologies Inc RD890 PCI to PCI bridge (PCI express gpp port C) [1002:5a17] (prog-if 00 [Normal decode])
>>>>           Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx+
>>>> 4.1:    Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast>TAbort-<TAbort-<MAbort->SERR-<PERR- INTx-
>>>> 4.2:    Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast>TAbort-<TAbort+<MAbort->SERR-<PERR- INTx-
>>>>           Latency: 0, Cache Line Size: 64 bytes
>>>>           Bus: primary=00, secondary=0a, subordinate=0a, sec-latency=0
>>>>           I/O behind bridge: 0000f000-00000fff
>>>>           Memory behind bridge: f9f00000-f9ffffff
>>>>           Prefetchable memory behind bridge: 00000000fff00000-00000000000fffff
>>>> 4.1:    Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast>TAbort-<TAbort-<MAbort-<SERR-<PERR-
>>>> 4.2:    Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast>TAbort+<TAbort-<MAbort-<SERR-<PERR-
>>>>           BridgeCtl: Parity+ SERR+ NoISA+ VGA- MAbort->Reset- FastB2B-
>>>>                   PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
>>>>           Capabilities: [50] Power Management version 3
>>>>                   Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
>>>>                   Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
>>>>           Capabilities: [58] Express (v2) Root Port (Slot+), MSI 00
>>>>                   DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s<64ns, L1<1us
>>>>                           ExtTag+ RBE+ FLReset-
>>>>                   DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
>>>>                           RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+
>>>>                           MaxPayload 128 bytes, MaxReadReq 128 bytes
>>>>                   DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr- TransPend-
>>>>                   LnkCap: Port #1, Speed 5GT/s, Width x8, ASPM L0s L1, Latency L0<1us, L1<8us
>>>>                           ClockPM- Surprise- LLActRep+ BwNot+
>>>>                   LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommClk-
>>>>                           ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
>>>>                   LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive+ BWMgmt+ ABWMgmt-
>>>>                   SltCap: AttnBtn- PwrCtrl- MRL- AttnInd- PwrInd- HotPlug- Surprise-
>>>>                           Slot #3, PowerLimit 10.000W; Interlock- NoCompl+
>>>>                   SltCtl: Enable: AttnBtn- PwrFlt- MRL- PresDet- CmdCplt- HPIrq- LinkChg-
>>>>                           Control: AttnInd Unknown, PwrInd Unknown, Power- Interlock-
>>>>                   SltSta: Status: AttnBtn- PowerFlt- MRL- CmdCplt- PresDet+ Interlock-
>>>>                           Changed: MRL- PresDet+ LinkState+
>>
>>> The probably because of the IO_PAGE_FAULT.
>>
>>> Thanks,
>>> Wei
>>
>>>> serveerstertje:~# lspci -t
>>>> -[0000:00]-+-00.0
>>>>              +-00.2
>>>>              +-02.0-[0b]----00.0
>>>>              +-03.0-[0a]--+-00.0
>>>>              |            +-00.1
>>>>              |            +-00.2
>>>>              |            +-00.3
>>>>              |            +-00.4
>>>>              |            +-00.5
>>>>              |            +-00.6
>>>>              |            \-00.7
>>>>              +-05.0-[09]----00.0
>>>>              +-06.0-[08]----00.0
>>>>              +-0a.0-[07]----00.0
>>>>              +-0b.0-[06]--+-00.0
>>>>              |            \-00.1
>>>>              +-0c.0-[05]----00.0
>>>>              +-0d.0-[04]--+-00.0
>>>>              |            +-00.1
>>>>              |            +-00.2
>>>>              |            +-00.3
>>>>              |            +-00.4
>>>>              |            +-00.5
>>>>              |            +-00.6
>>>>              |            \-00.7
>>>>              +-11.0
>>>>              +-12.0
>>>>              +-12.2
>>>>              +-13.0
>>>>              +-13.2
>>>>              +-14.0
>>>>              +-14.3
>>>>              +-14.4-[03]----06.0
>>>>              +-14.5
>>>>              +-15.0-[02]--
>>>>              +-16.0
>>>>              +-16.2
>>>>              +-18.0
>>>>              +-18.1
>>>>              +-18.2
>>>>              +-18.3
>>>>              \-18.4
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>> Thanks,
>>>>> Wei
>>>>
>>>>>> I will try to make a complete package, and try with one pv domain only where the devices are being passed through just to simplify the setup.
>>>>>>
>>>>>>
>>>>>>> * I would also like to know the symptoms of device 0x0700 when IO_PF
>>>>>>> happened. Did it stop working?
>>>>>>
>>>>>> Yes it stops working, the video capture just freezes, but the driver doesn't bail out.
>>>>>> For the USB controller (0x0a06) it starts to give errors for usbdev_open in the guest.
>>>>>>
>>>>>>> (BTW: I copied a few options from your boot cmd line and it worked with
>>>>>>> my RD890 system
>>>>>>
>>>>>>> dom0_mem=1024M,max:1024M loglvl=all loglvl_guest=all console_timestamps
>>>>>>> cpuidle cpufreq=xen noreboot debug lapic=debug apic_verbosity=debug
>>>>>>> apic=debug iommu=on,verbose,debug,no-sharept
>>>>>>
>>>>>>> * so, what OEM board you have?)
>>>>>>
>>>>>> MSI 890FXA-GD70
>>>>>>
>>>>>>> Also from your log, these lines looks very strange:
>>>>>>
>>>>>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>>>>>>> read-only memory page. gfn=0xd5, mfn=0xa4a11
>>>>>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>>>>>>> read-only memory page. gfn=0xd7, mfn=0xa4a0f
>>>>>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>>>>>>> read-only memory page. gfn=0xd9, mfn=0xa4a0d
>>>>>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>>>>>>> read-only memory page. gfn=0xdb, mfn=0xa4a0b
>>>>>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>>>>>>> read-only memory page. gfn=0xdd, mfn=0xa4a09
>>>>>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>>>>>>> read-only memory page. gfn=0xdf, mfn=0xa4a07
>>>>>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>>>>>>> read-only memory page. gfn=0xe1, mfn=0xa4a05
>>>>>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>>>>>>> read-only memory page. gfn=0xe3, mfn=0xa4a03
>>>>>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>>>>>>> read-only memory page. gfn=0xe5, mfn=0xa4a01
>>>>>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>>>>>>> read-only memory page. gfn=0xe7, mfn=0xa463f
>>>>>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>>>>>>> read-only memory page. gfn=0xe9, mfn=0xa463d
>>>>>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>>>>>>> read-only memory page. gfn=0xeb, mfn=0xa463b
>>>>>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>>>>>>> read-only memory page. gfn=0xed, mfn=0xa4639
>>>>>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>>>>>>> read-only memory page. gfn=0xef, mfn=0xa4637
>>>>>>> (XEN) [2012-09-04 16:13:56] AMD-Vi: IO_PAGE_FAULT: domain = 0, device id
>>>>>>> = 0x0a06, fault address = 0xc2c2c2c0
>>>>>>> (XEN) [2012-09-04 16:13:56] AMD-Vi: IO_PAGE_FAULT: domain = 14, device
>>>>>>> id = 0x0700, fault address = 0xa90f8300
>>>>>>> (XEN) [2012-09-04 16:13:56] AMD-Vi: IO_PAGE_FAULT: domain = 14, device
>>>>>>> id = 0x0700, fault address = 0xa90f8340
>>>>>>> (XEN) [2012-09-04 16:13:56] AMD-Vi: IO_PAGE_FAULT: domain = 14, device
>>>>>>> id = 0x0700, fault address = 0xa90f8380
>>>>>>> (XEN) [2012-09-04 16:13:56] AMD-Vi: IO_PAGE_FAULT: domain = 14, device
>>>>>>> id = 0x0700, fault address = 0xa90f83c0
>>>>>>
>>>>>>> * they are just followed by the IO PAGE fault. Do you know where are
>>>>>>> they from? Your video card driver maybe?
>>>>>>
>>>>>>      From a HVM domain with a old (3.0.3) kernel, but the faults also occur without this domain being started.
>>>>>>
>>>>>>
>>>>>>> Thanks,
>>>>>>> Wei
>>>>>>
>>>>>>
>>>>>>>> Complete xl dmesg and lspci -vvvknn attached.
>>>>>>>>
>>>>>>>> Thx
>>>>>>>>
>>>>>>>> --
>>>>>>>> Sander
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>
>>>>
>>
>>





_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 24 12:28:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Sep 2012 12: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 1TG7lb-0007d2-MD; Mon, 24 Sep 2012 12:28:03 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <linux@eikelenboom.it>) id 1TG7lZ-0007cX-A4
	for xen-devel@lists.xensource.com; Mon, 24 Sep 2012 12:28:02 +0000
Received: from [85.158.137.99:17798] by server-13.bemta-3.messagelabs.com id
	ED/47-01606-0D150605; Mon, 24 Sep 2012 12:28:00 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-16.tower-217.messagelabs.com!1348489679!18896350!1
X-Originating-IP: [188.40.164.121]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16598 invoked from network); 24 Sep 2012 12:27:59 -0000
Received: from static.121.164.40.188.clients.your-server.de (HELO
	smtp.eikelenboom.it) (188.40.164.121)
	by server-16.tower-217.messagelabs.com with AES256-SHA encrypted SMTP;
	24 Sep 2012 12:27:59 -0000
Received: from 132-64-ftth.onsneteindhoven.nl ([88.159.64.132]:53112
	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 1TG7mF-00044G-R4; Mon, 24 Sep 2012 14:28:43 +0200
Date: Mon, 24 Sep 2012 14:27:56 +0200
From: Sander Eikelenboom <linux@eikelenboom.it>
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <1264531695.20120924142756@eikelenboom.it>
To: Wei Wang <wei.wang2@amd.com>
In-Reply-To: <74647167<506050F0.7020703@amd.com>
References: <504764E2.4000809@amd.com>
	<326589347.20120906005936@eikelenboom.it>
	<5048A603.3070207@amd.com>
	<483486315.20120906155001@eikelenboom.it>
	<5048BB29.4040900@amd.com>
	<488803362.20120907093241@eikelenboom.it>
	<5049B650.4080101@amd.com> <74647167 <506050F0.7020703@amd.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH] amd iommu: Dump flags of IO page faults
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


Monday, September 24, 2012, 2:24:16 PM, you wrote:

> On 09/24/2012 10:38 AM, Sander Eikelenboom wrote:
>>
>> Friday, September 7, 2012, 10:54:40 AM, you wrote:
>>
>>> On 09/07/2012 09:32 AM, Sander Eikelenboom wrote:
>>>>
>>>> Thursday, September 6, 2012, 5:03:05 PM, you wrote:
>>>>
>>>>> On 09/06/2012 03:50 PM, Sander Eikelenboom wrote:
>>>>>>
>>>>>> Thursday, September 6, 2012, 3:32:51 PM, you wrote:
>>>>>>
>>>>>>> On 09/06/2012 12:59 AM, Sander Eikelenboom wrote:
>>>>>>>>
>>>>>>>> Wednesday, September 5, 2012, 4:42:42 PM, you wrote:
>>>>>>>>
>>>>>>>>> Hi Jan,
>>>>>>>>> Attached patch dumps io page fault flags. The flags show the reason of
>>>>>>>>> the fault and tell us if this is an unmapped interrupt fault or a DMA fault.
>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> Wei
>>>>>>>>
>>>>>>>>> signed-off-by: Wei Wang<wei.wang2@amd.com>
>>>>>>>>
>>>>>>>>
>>>>>>>> I have applied the patch and the flags seem to differ between the faults:
>>>>>>>>
>>>>>>>> AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0a06, fault address = 0xc2c2c2c0, flags = 0x000
>>>>>>>> (XEN) [2012-09-05 20:54:16] AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0a06, fault address = 0xc2c2c2c0, flags = 0x000
>>>>>>>> (XEN) [2012-09-05 20:54:16] AMD-Vi: IO_PAGE_FAULT: domain = 14, device id = 0x0700, fault address = 0xa8d339e0, flags = 0x020
>>>>>>>> (XEN) [2012-09-05 20:54:16] AMD-Vi: IO_PAGE_FAULT: domain = 14, device id = 0x0700, fault address = 0xa8d33a40, flags = 0x020
>>>>>>
>>>>>>> OK, so they are not interrupt requests. I guess further information from
>>>>>>> your system would be helpful to debug this issue:
>>>>>>> 1) xl info
>>>>>>> 2) xl list
>>>>>>> 3) lscpi -vvv (NOTE: not in dom0 but in your guest)
>>>>>>> 4) cat /proc/iomem (in both dom0 and your hvm guest)
>>>>>>
>>>>>> dom14 is not a HVM guest,it's a PV guest.
>>>>
>>>>> Ah, I see. PV guest is quite different than hvm, it does use p2m tables
>>>>> as io page tables. So no-sharept option does not work in this case. PV
>>>>> guests always use separated io page tables. There might be some
>>>>> incorrect mappings on the page tables. I will check this on my side.
>>>>
>>>> I have reverted the machine to xen-4.1.4-pre (changeset 23353) and kept everything else the same.
>>>> I haven't seen any IO PAGE FAULTS after that.
>>>>
>>>> I did spot some differences in the output from lspci between xen 4.1 and 4.2, related to MSI enabled or not for the IOMMU device.
>>>> Have attached the xl/xm dmesg and lspci from booting with both versions.
>>>>
>>>> lspci:
>>>>
>>>> 00:00.2 Generic system peripheral [0806]: ATI Technologies Inc RD990 I/O Memory Management Unit (IOMMU) [1002:5a23]
>>>>           Subsystem: ATI Technologies Inc RD990 I/O Memory Management Unit (IOMMU) [1002:5a23]
>>>>           Control: I/O- Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
>>>>           Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast>TAbort-<TAbort-<MAbort->SERR-<PERR- INTx-
>>>>           Latency: 0
>>>>           Interrupt: pin A routed to IRQ 10
>>>>           Capabilities: [40] Secure device<?>
>>>> 4.1:    Capabilities: [54] MSI: Enable- Count=1/1 Maskable- 64bit+
>>
>>> Eh... That is interesting. So which dom0 are you using?  There is a c/s
>>> in 4.2 to prevent recent dom0 to disable iommu interrupt (changeset
>>> 25492:61844569a432) Otherwise, iommu cannot send any events including IO
>>> PAGE faults. You could try to revert dom0 to an old version like 2.6
>>> pv_ops to see if you really have no io page faults on 4.1
>>
>> Ok i finally got the time to do some more testing, tested 4.2 around that changeset, and made a copy of the guest using HVM instead of PV.
>>
>> The results:
>> - On xen-4.1.* and a 3.6-rc6 kernel (dom0 and domU):  the video device passed through works fine, both in a HVM as a PV guest, i don't see IO page faults getting reported.
>> - On xen-4.2 changeset<   25492 and a 3.6-rc6 kernel (dom0 and domU):  the video device passed through works fine, both in a HVM as a PV guest, i don't see IO page faults getting reported.
>> - On xen-4.2 changeset>   25492 and a 3.6-rc6 kernel (dom0 and domU): the video device passed through works fine for a short while (around 5 to 10 minutes) in a PV guest, after that IO page faults get reported and the video freezes, i don't see any errors in the guest though.
>> - On xen-unstable tip and a 3.6-rc6 kernel (dom0 and domU):
>>                                                        PV:  the video device passed through works fine for a short while (around 5 to 10 minutes), after that IO page faults get reported and the video freezes, i don't see any errors in the guest though.
>>                                                        HVM: the video device passed through doesn't work from the start:
>>                                                                       - The device is there according to lspci
>>                                                                       - The video application start fine, but delivers a green image, so the device is not working properly. I don't see IO page faults though.
>>
>> Attached are (all with xen-unstable tip and the guest as HVM (domain 15):
>> - xl dmesg
>> - Patch which adds some more info, but all values reported seem to be zero (see xl dmesg)
>> - lspci dom0
>> - lspci HVM guest

> HI,
> Thanks for the information, very very helpful for debugging. I hope I 
> could start to look at this right after sending my next iommu patch 
> queue upstream...another question is: Did you see this issue on a single 
> pv/hvm guest system or you only saw it on a system with about 16 running 
> VMs?

> Thanks,
> Wei

If you need more info, i'm more than happy to run additional debug patches.
Haven't tested it with a single guest, will try right a way

Thanks !

--
Sander


>>
>>
>>
>>>> 4.2:    Capabilities: [54] MSI: Enable+ Count=1/1 Maskable- 64bit+
>>>>                   Address: 00000000fee0100c  Data: 4128
>>>>           Capabilities: [64] HyperTransport: MSI Mapping Enable+ Fixed+
>>>>
>>>> Although it seems enabled, shouldn't the IRQ number used be much higher than 10 for MSI interrupts ?
>>
>>> The IRQ number is fine. MSI vector is stored at  Data: 4128
>>
>>>>
>>>> There is another difference in the bridge device that's in front of the  0a:00.6 device that faults before the kernel is even booted.
>>>>
>>>> 00:03.0 PCI bridge [0604]: ATI Technologies Inc RD890 PCI to PCI bridge (PCI express gpp port C) [1002:5a17] (prog-if 00 [Normal decode])
>>>>           Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx+
>>>> 4.1:    Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast>TAbort-<TAbort-<MAbort->SERR-<PERR- INTx-
>>>> 4.2:    Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast>TAbort-<TAbort+<MAbort->SERR-<PERR- INTx-
>>>>           Latency: 0, Cache Line Size: 64 bytes
>>>>           Bus: primary=00, secondary=0a, subordinate=0a, sec-latency=0
>>>>           I/O behind bridge: 0000f000-00000fff
>>>>           Memory behind bridge: f9f00000-f9ffffff
>>>>           Prefetchable memory behind bridge: 00000000fff00000-00000000000fffff
>>>> 4.1:    Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast>TAbort-<TAbort-<MAbort-<SERR-<PERR-
>>>> 4.2:    Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast>TAbort+<TAbort-<MAbort-<SERR-<PERR-
>>>>           BridgeCtl: Parity+ SERR+ NoISA+ VGA- MAbort->Reset- FastB2B-
>>>>                   PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
>>>>           Capabilities: [50] Power Management version 3
>>>>                   Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
>>>>                   Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
>>>>           Capabilities: [58] Express (v2) Root Port (Slot+), MSI 00
>>>>                   DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s<64ns, L1<1us
>>>>                           ExtTag+ RBE+ FLReset-
>>>>                   DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
>>>>                           RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+
>>>>                           MaxPayload 128 bytes, MaxReadReq 128 bytes
>>>>                   DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr- TransPend-
>>>>                   LnkCap: Port #1, Speed 5GT/s, Width x8, ASPM L0s L1, Latency L0<1us, L1<8us
>>>>                           ClockPM- Surprise- LLActRep+ BwNot+
>>>>                   LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommClk-
>>>>                           ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
>>>>                   LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive+ BWMgmt+ ABWMgmt-
>>>>                   SltCap: AttnBtn- PwrCtrl- MRL- AttnInd- PwrInd- HotPlug- Surprise-
>>>>                           Slot #3, PowerLimit 10.000W; Interlock- NoCompl+
>>>>                   SltCtl: Enable: AttnBtn- PwrFlt- MRL- PresDet- CmdCplt- HPIrq- LinkChg-
>>>>                           Control: AttnInd Unknown, PwrInd Unknown, Power- Interlock-
>>>>                   SltSta: Status: AttnBtn- PowerFlt- MRL- CmdCplt- PresDet+ Interlock-
>>>>                           Changed: MRL- PresDet+ LinkState+
>>
>>> The probably because of the IO_PAGE_FAULT.
>>
>>> Thanks,
>>> Wei
>>
>>>> serveerstertje:~# lspci -t
>>>> -[0000:00]-+-00.0
>>>>              +-00.2
>>>>              +-02.0-[0b]----00.0
>>>>              +-03.0-[0a]--+-00.0
>>>>              |            +-00.1
>>>>              |            +-00.2
>>>>              |            +-00.3
>>>>              |            +-00.4
>>>>              |            +-00.5
>>>>              |            +-00.6
>>>>              |            \-00.7
>>>>              +-05.0-[09]----00.0
>>>>              +-06.0-[08]----00.0
>>>>              +-0a.0-[07]----00.0
>>>>              +-0b.0-[06]--+-00.0
>>>>              |            \-00.1
>>>>              +-0c.0-[05]----00.0
>>>>              +-0d.0-[04]--+-00.0
>>>>              |            +-00.1
>>>>              |            +-00.2
>>>>              |            +-00.3
>>>>              |            +-00.4
>>>>              |            +-00.5
>>>>              |            +-00.6
>>>>              |            \-00.7
>>>>              +-11.0
>>>>              +-12.0
>>>>              +-12.2
>>>>              +-13.0
>>>>              +-13.2
>>>>              +-14.0
>>>>              +-14.3
>>>>              +-14.4-[03]----06.0
>>>>              +-14.5
>>>>              +-15.0-[02]--
>>>>              +-16.0
>>>>              +-16.2
>>>>              +-18.0
>>>>              +-18.1
>>>>              +-18.2
>>>>              +-18.3
>>>>              \-18.4
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>> Thanks,
>>>>> Wei
>>>>
>>>>>> I will try to make a complete package, and try with one pv domain only where the devices are being passed through just to simplify the setup.
>>>>>>
>>>>>>
>>>>>>> * I would also like to know the symptoms of device 0x0700 when IO_PF
>>>>>>> happened. Did it stop working?
>>>>>>
>>>>>> Yes it stops working, the video capture just freezes, but the driver doesn't bail out.
>>>>>> For the USB controller (0x0a06) it starts to give errors for usbdev_open in the guest.
>>>>>>
>>>>>>> (BTW: I copied a few options from your boot cmd line and it worked with
>>>>>>> my RD890 system
>>>>>>
>>>>>>> dom0_mem=1024M,max:1024M loglvl=all loglvl_guest=all console_timestamps
>>>>>>> cpuidle cpufreq=xen noreboot debug lapic=debug apic_verbosity=debug
>>>>>>> apic=debug iommu=on,verbose,debug,no-sharept
>>>>>>
>>>>>>> * so, what OEM board you have?)
>>>>>>
>>>>>> MSI 890FXA-GD70
>>>>>>
>>>>>>> Also from your log, these lines looks very strange:
>>>>>>
>>>>>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>>>>>>> read-only memory page. gfn=0xd5, mfn=0xa4a11
>>>>>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>>>>>>> read-only memory page. gfn=0xd7, mfn=0xa4a0f
>>>>>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>>>>>>> read-only memory page. gfn=0xd9, mfn=0xa4a0d
>>>>>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>>>>>>> read-only memory page. gfn=0xdb, mfn=0xa4a0b
>>>>>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>>>>>>> read-only memory page. gfn=0xdd, mfn=0xa4a09
>>>>>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>>>>>>> read-only memory page. gfn=0xdf, mfn=0xa4a07
>>>>>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>>>>>>> read-only memory page. gfn=0xe1, mfn=0xa4a05
>>>>>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>>>>>>> read-only memory page. gfn=0xe3, mfn=0xa4a03
>>>>>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>>>>>>> read-only memory page. gfn=0xe5, mfn=0xa4a01
>>>>>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>>>>>>> read-only memory page. gfn=0xe7, mfn=0xa463f
>>>>>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>>>>>>> read-only memory page. gfn=0xe9, mfn=0xa463d
>>>>>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>>>>>>> read-only memory page. gfn=0xeb, mfn=0xa463b
>>>>>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>>>>>>> read-only memory page. gfn=0xed, mfn=0xa4639
>>>>>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>>>>>>> read-only memory page. gfn=0xef, mfn=0xa4637
>>>>>>> (XEN) [2012-09-04 16:13:56] AMD-Vi: IO_PAGE_FAULT: domain = 0, device id
>>>>>>> = 0x0a06, fault address = 0xc2c2c2c0
>>>>>>> (XEN) [2012-09-04 16:13:56] AMD-Vi: IO_PAGE_FAULT: domain = 14, device
>>>>>>> id = 0x0700, fault address = 0xa90f8300
>>>>>>> (XEN) [2012-09-04 16:13:56] AMD-Vi: IO_PAGE_FAULT: domain = 14, device
>>>>>>> id = 0x0700, fault address = 0xa90f8340
>>>>>>> (XEN) [2012-09-04 16:13:56] AMD-Vi: IO_PAGE_FAULT: domain = 14, device
>>>>>>> id = 0x0700, fault address = 0xa90f8380
>>>>>>> (XEN) [2012-09-04 16:13:56] AMD-Vi: IO_PAGE_FAULT: domain = 14, device
>>>>>>> id = 0x0700, fault address = 0xa90f83c0
>>>>>>
>>>>>>> * they are just followed by the IO PAGE fault. Do you know where are
>>>>>>> they from? Your video card driver maybe?
>>>>>>
>>>>>>      From a HVM domain with a old (3.0.3) kernel, but the faults also occur without this domain being started.
>>>>>>
>>>>>>
>>>>>>> Thanks,
>>>>>>> Wei
>>>>>>
>>>>>>
>>>>>>>> Complete xl dmesg and lspci -vvvknn attached.
>>>>>>>>
>>>>>>>> Thx
>>>>>>>>
>>>>>>>> --
>>>>>>>> Sander
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>
>>>>
>>
>>





_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 24 12:33:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Sep 2012 12:33:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TG7qR-0007un-EG; Mon, 24 Sep 2012 12:33: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 1TG7qP-0007uh-Ss
	for xen-devel@lists.xen.org; Mon, 24 Sep 2012 12:33:02 +0000
Received: from [85.158.143.35:27872] by server-1.bemta-4.messagelabs.com id
	3C/B0-05684-DF250605; Mon, 24 Sep 2012 12:33:01 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1348489980!12815577!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22870 invoked from network); 24 Sep 2012 12:33:00 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-11.tower-21.messagelabs.com with SMTP;
	24 Sep 2012 12:33:00 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 24 Sep 2012 13:33:00 +0100
Message-Id: <50606F18020000780009D57B@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 24 Sep 2012 13:32:56 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ben Guthro" <ben@guthro.net>
References: <CAOvdn6XKPOMNn6AjuYvZvPXRRJffN3po5GXe1Yh1-m0hisMK_w@mail.gmail.com>
	<CC8273A0.4C9DD%keir@xen.org>
	<50605E9A020000780009D486@nat28.tlf.novell.com>
	<CAOvdn6XmB6rj3_QVU+59V8p24Y5G47AWxVEM=id02JWXkuhibQ@mail.gmail.com>
	<5060640B020000780009D4D2@nat28.tlf.novell.com>
	<CAOvdn6XLy8zR2rb2MEyi2aT9LQiFvFLY_H02p181mTsVLVTZkw@mail.gmail.com>
	<506068A0020000780009D519@nat28.tlf.novell.com>
	<CAOvdn6Undn2srfNhW++wLfUNFQ5JnZ3rp5bg7DD_TDPCHqmP_A@mail.gmail.com>
In-Reply-To: <CAOvdn6Undn2srfNhW++wLfUNFQ5JnZ3rp5bg7DD_TDPCHqmP_A@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>, Keir Fraser <keir@xen.org>,
	john.baboval@citrix.com, Thomas Goetz <thomas.goetz@citrix.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen4.2 S3 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 24.09.12 at 14:24, Ben Guthro <ben@guthro.net> wrote:
> On Mon, Sep 24, 2012 at 8:05 AM, Jan Beulich <JBeulich@suse.com> wrote:
>> Alternatively you could also stick a wbinvd() in the two possibly
>> relevant places...
>>
> I tried doing this right before disable_nonboot_cpus() in power.c, to no
> effect.

That's too early - this must be done the last thing before entering
the halt loops (which is why I referred to two places).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 24 12:33:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Sep 2012 12:33:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TG7qR-0007un-EG; Mon, 24 Sep 2012 12:33: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 1TG7qP-0007uh-Ss
	for xen-devel@lists.xen.org; Mon, 24 Sep 2012 12:33:02 +0000
Received: from [85.158.143.35:27872] by server-1.bemta-4.messagelabs.com id
	3C/B0-05684-DF250605; Mon, 24 Sep 2012 12:33:01 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1348489980!12815577!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22870 invoked from network); 24 Sep 2012 12:33:00 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-11.tower-21.messagelabs.com with SMTP;
	24 Sep 2012 12:33:00 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 24 Sep 2012 13:33:00 +0100
Message-Id: <50606F18020000780009D57B@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 24 Sep 2012 13:32:56 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ben Guthro" <ben@guthro.net>
References: <CAOvdn6XKPOMNn6AjuYvZvPXRRJffN3po5GXe1Yh1-m0hisMK_w@mail.gmail.com>
	<CC8273A0.4C9DD%keir@xen.org>
	<50605E9A020000780009D486@nat28.tlf.novell.com>
	<CAOvdn6XmB6rj3_QVU+59V8p24Y5G47AWxVEM=id02JWXkuhibQ@mail.gmail.com>
	<5060640B020000780009D4D2@nat28.tlf.novell.com>
	<CAOvdn6XLy8zR2rb2MEyi2aT9LQiFvFLY_H02p181mTsVLVTZkw@mail.gmail.com>
	<506068A0020000780009D519@nat28.tlf.novell.com>
	<CAOvdn6Undn2srfNhW++wLfUNFQ5JnZ3rp5bg7DD_TDPCHqmP_A@mail.gmail.com>
In-Reply-To: <CAOvdn6Undn2srfNhW++wLfUNFQ5JnZ3rp5bg7DD_TDPCHqmP_A@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>, Keir Fraser <keir@xen.org>,
	john.baboval@citrix.com, Thomas Goetz <thomas.goetz@citrix.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen4.2 S3 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 24.09.12 at 14:24, Ben Guthro <ben@guthro.net> wrote:
> On Mon, Sep 24, 2012 at 8:05 AM, Jan Beulich <JBeulich@suse.com> wrote:
>> Alternatively you could also stick a wbinvd() in the two possibly
>> relevant places...
>>
> I tried doing this right before disable_nonboot_cpus() in power.c, to no
> effect.

That's too early - this must be done the last thing before entering
the halt loops (which is why I referred to two places).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 24 12:37:58 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Sep 2012 12: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 1TG7v1-0008A7-9z; Mon, 24 Sep 2012 12:37:47 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jmarcet@gmail.com>) id 1TG7uz-00089y-Tb
	for xen-devel@lists.xen.org; Mon, 24 Sep 2012 12:37:46 +0000
Received: from [85.158.143.99:46054] by server-2.bemta-4.messagelabs.com id
	1A/ED-06610-91450605; Mon, 24 Sep 2012 12:37:45 +0000
X-Env-Sender: jmarcet@gmail.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1348490263!25420549!1
X-Originating-IP: [209.85.214.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6435 invoked from network); 24 Sep 2012 12:37:44 -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;
	24 Sep 2012 12:37:44 -0000
Received: by obbta14 with SMTP id ta14so6901306obb.32
	for <xen-devel@lists.xen.org>; Mon, 24 Sep 2012 05:37:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to
	:cc:content-type;
	bh=MSMbdzolD2NHCWv2k8a0t9dpk7kvrFiyfBJgsrNTlp8=;
	b=iEeG6t0aW+7QC3RHKy5RvISkH/85gYJAGfcwa36diZAZYAntXqUIEJKwZpO9pYL1jJ
	W3ndJm9wlZ4gLpVptHQBMZWS+a11UDSdLoZ0mnVzjbnHeuxXyY5KNm/MQZjGlWU5do4l
	7l4/s76RZ9nmF1zFkHJGsHt7UByFCbUbSfKQMnhHbmDoaxkSjg/OFAjd9PmcgrAVVnR+
	ofWg+/KG5P5ICs62EubsvG53D0qSJ1uDZmA0KU+1V7YM0Y7qXYkz1CTbDNxpBjZgy5NZ
	vIjb812P7Yx1851+YZY23CHoA2/eQaagmpUbcFs1UvV60n7Z8cANozqb/UTxlzP3mxzk
	ScQg==
Received: by 10.182.172.74 with SMTP id ba10mr9693158obc.83.1348490263240;
	Mon, 24 Sep 2012 05:37:43 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.60.138.225 with HTTP; Mon, 24 Sep 2012 05:37:22 -0700 (PDT)
In-Reply-To: <CAOvdn6XV4eoA-FfFns1xhx7HCUqXc7KHxZwyKuT4FHG8s3R5RQ@mail.gmail.com>
References: <CAOvdn6XKPOMNn6AjuYvZvPXRRJffN3po5GXe1Yh1-m0hisMK_w@mail.gmail.com>
	<CC8273A0.4C9DD%keir@xen.org>
	<50605E9A020000780009D486@nat28.tlf.novell.com>
	<CAOvdn6XmB6rj3_QVU+59V8p24Y5G47AWxVEM=id02JWXkuhibQ@mail.gmail.com>
	<5060640B020000780009D4D2@nat28.tlf.novell.com>
	<CAOvdn6XLy8zR2rb2MEyi2aT9LQiFvFLY_H02p181mTsVLVTZkw@mail.gmail.com>
	<20120924122203.GG8912@reaktio.net>
	<CAOvdn6XV4eoA-FfFns1xhx7HCUqXc7KHxZwyKuT4FHG8s3R5RQ@mail.gmail.com>
From: Javier Marcet <jmarcet@gmail.com>
Date: Mon, 24 Sep 2012 14:37:22 +0200
Message-ID: <CAAnFQG9PLQjdh6Ab6=Y5ZGM1s4nGdLekKU=pcKNMxt4rmt_RKA@mail.gmail.com>
To: Ben Guthro <ben@guthro.net>
Cc: Keir Fraser <keir@xen.org>, john.baboval@citrix.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	xen-devel <xen-devel@lists.xen.org>, Jan Beulich <JBeulich@suse.com>,
	Thomas Goetz <thomas.goetz@citrix.com>
Subject: Re: [Xen-devel] Xen4.2 S3 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 Mon, Sep 24, 2012 at 2:27 PM, Ben Guthro <ben@guthro.net> wrote:

Hi Ben,

>> >    I see - Konrad - do you have a changeset I can look for with the
>> > features
>> >    Jan describes?
>>
>> xen-acpi-processor driver was merged to upstream Linux kernel v3.4.
>>
>
> I see - so the advanced methods are not being used then
> This same kernel does work with Xen-4.0.x though. Is there an assumption in
> the code that ties Xen-4.2 to a newer kernel?

I'm being bitten by this bug with a 3.5 kernel and Xen 4.2


-- 
Javier Marcet <jmarcet@gmail.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 24 12:37:58 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Sep 2012 12: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 1TG7v1-0008A7-9z; Mon, 24 Sep 2012 12:37:47 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jmarcet@gmail.com>) id 1TG7uz-00089y-Tb
	for xen-devel@lists.xen.org; Mon, 24 Sep 2012 12:37:46 +0000
Received: from [85.158.143.99:46054] by server-2.bemta-4.messagelabs.com id
	1A/ED-06610-91450605; Mon, 24 Sep 2012 12:37:45 +0000
X-Env-Sender: jmarcet@gmail.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1348490263!25420549!1
X-Originating-IP: [209.85.214.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6435 invoked from network); 24 Sep 2012 12:37:44 -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;
	24 Sep 2012 12:37:44 -0000
Received: by obbta14 with SMTP id ta14so6901306obb.32
	for <xen-devel@lists.xen.org>; Mon, 24 Sep 2012 05:37:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to
	:cc:content-type;
	bh=MSMbdzolD2NHCWv2k8a0t9dpk7kvrFiyfBJgsrNTlp8=;
	b=iEeG6t0aW+7QC3RHKy5RvISkH/85gYJAGfcwa36diZAZYAntXqUIEJKwZpO9pYL1jJ
	W3ndJm9wlZ4gLpVptHQBMZWS+a11UDSdLoZ0mnVzjbnHeuxXyY5KNm/MQZjGlWU5do4l
	7l4/s76RZ9nmF1zFkHJGsHt7UByFCbUbSfKQMnhHbmDoaxkSjg/OFAjd9PmcgrAVVnR+
	ofWg+/KG5P5ICs62EubsvG53D0qSJ1uDZmA0KU+1V7YM0Y7qXYkz1CTbDNxpBjZgy5NZ
	vIjb812P7Yx1851+YZY23CHoA2/eQaagmpUbcFs1UvV60n7Z8cANozqb/UTxlzP3mxzk
	ScQg==
Received: by 10.182.172.74 with SMTP id ba10mr9693158obc.83.1348490263240;
	Mon, 24 Sep 2012 05:37:43 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.60.138.225 with HTTP; Mon, 24 Sep 2012 05:37:22 -0700 (PDT)
In-Reply-To: <CAOvdn6XV4eoA-FfFns1xhx7HCUqXc7KHxZwyKuT4FHG8s3R5RQ@mail.gmail.com>
References: <CAOvdn6XKPOMNn6AjuYvZvPXRRJffN3po5GXe1Yh1-m0hisMK_w@mail.gmail.com>
	<CC8273A0.4C9DD%keir@xen.org>
	<50605E9A020000780009D486@nat28.tlf.novell.com>
	<CAOvdn6XmB6rj3_QVU+59V8p24Y5G47AWxVEM=id02JWXkuhibQ@mail.gmail.com>
	<5060640B020000780009D4D2@nat28.tlf.novell.com>
	<CAOvdn6XLy8zR2rb2MEyi2aT9LQiFvFLY_H02p181mTsVLVTZkw@mail.gmail.com>
	<20120924122203.GG8912@reaktio.net>
	<CAOvdn6XV4eoA-FfFns1xhx7HCUqXc7KHxZwyKuT4FHG8s3R5RQ@mail.gmail.com>
From: Javier Marcet <jmarcet@gmail.com>
Date: Mon, 24 Sep 2012 14:37:22 +0200
Message-ID: <CAAnFQG9PLQjdh6Ab6=Y5ZGM1s4nGdLekKU=pcKNMxt4rmt_RKA@mail.gmail.com>
To: Ben Guthro <ben@guthro.net>
Cc: Keir Fraser <keir@xen.org>, john.baboval@citrix.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	xen-devel <xen-devel@lists.xen.org>, Jan Beulich <JBeulich@suse.com>,
	Thomas Goetz <thomas.goetz@citrix.com>
Subject: Re: [Xen-devel] Xen4.2 S3 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 Mon, Sep 24, 2012 at 2:27 PM, Ben Guthro <ben@guthro.net> wrote:

Hi Ben,

>> >    I see - Konrad - do you have a changeset I can look for with the
>> > features
>> >    Jan describes?
>>
>> xen-acpi-processor driver was merged to upstream Linux kernel v3.4.
>>
>
> I see - so the advanced methods are not being used then
> This same kernel does work with Xen-4.0.x though. Is there an assumption in
> the code that ties Xen-4.2 to a newer kernel?

I'm being bitten by this bug with a 3.5 kernel and Xen 4.2


-- 
Javier Marcet <jmarcet@gmail.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 24 12:37:59 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Sep 2012 12: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 1TG7v5-0008AX-Mr; Mon, 24 Sep 2012 12:37:51 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1TG7v4-0008AJ-7G
	for xen-devel@lists.xen.org; Mon, 24 Sep 2012 12:37:50 +0000
Received: from [85.158.139.211:58841] by server-9.bemta-5.messagelabs.com id
	AE/A5-14846-D1450605; Mon, 24 Sep 2012 12:37:49 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1348490268!19278571!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13426 invoked from network); 24 Sep 2012 12:37:49 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-7.tower-206.messagelabs.com with SMTP;
	24 Sep 2012 12:37:49 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 24 Sep 2012 13:37:48 +0100
Message-Id: <5060703B020000780009D58E@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 24 Sep 2012 13:37:47 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ben Guthro" <ben@guthro.net>,<pasik@iki.fi>
References: <CAOvdn6XKPOMNn6AjuYvZvPXRRJffN3po5GXe1Yh1-m0hisMK_w@mail.gmail.com>
	<CC8273A0.4C9DD%keir@xen.org>
	<50605E9A020000780009D486@nat28.tlf.novell.com>
	<CAOvdn6XmB6rj3_QVU+59V8p24Y5G47AWxVEM=id02JWXkuhibQ@mail.gmail.com>
	<5060640B020000780009D4D2@nat28.tlf.novell.com>
	<CAOvdn6XLy8zR2rb2MEyi2aT9LQiFvFLY_H02p181mTsVLVTZkw@mail.gmail.com>
	<20120924122203.GG8912@reaktio.net>
	<CAOvdn6XV4eoA-FfFns1xhx7HCUqXc7KHxZwyKuT4FHG8s3R5RQ@mail.gmail.com>
In-Reply-To: <CAOvdn6XV4eoA-FfFns1xhx7HCUqXc7KHxZwyKuT4FHG8s3R5RQ@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>, Keir Fraser <keir@xen.org>,
	john.baboval@citrix.com, Thomas Goetz <thomas.goetz@citrix.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen4.2 S3 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="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Pj4+IE9uIDI0LjA5LjEyIGF0IDE0OjI3LCBCZW4gR3V0aHJvIDxiZW5AZ3V0aHJvLm5ldD4gd3Jv
dGU6Cj4gT24gTW9uLCBTZXAgMjQsIDIwMTIgYXQgODoyMiBBTSwgUGFzaSBLw6Rya2vDpGluZW4g
PHBhc2lrQGlraS5maT4gd3JvdGU6Cj4gCj4+IE9uIE1vbiwgU2VwIDI0LCAyMDEyIGF0IDA3OjU0
OjA1QU0gLTA0MDAsIEJlbiBHdXRocm8gd3JvdGU6Cj4+ID4gICAgSSBzZWUgLSBLb25yYWQgLSBk
byB5b3UgaGF2ZSBhIGNoYW5nZXNldCBJIGNhbiBsb29rIGZvciB3aXRoIHRoZQo+PiBmZWF0dXJl
cwo+PiA+ICAgIEphbiBkZXNjcmliZXM/Cj4+Cj4+IHhlbi1hY3BpLXByb2Nlc3NvciBkcml2ZXIg
d2FzIG1lcmdlZCB0byB1cHN0cmVhbSBMaW51eCBrZXJuZWwgdjMuNC4KPj4KPj4KPiBJIHNlZSAt
IHNvIHRoZSBhZHZhbmNlZCBtZXRob2RzIGFyZSBub3QgYmVpbmcgdXNlZCB0aGVuCj4gVGhpcyBz
YW1lIGtlcm5lbCBkb2VzIHdvcmsgd2l0aCBYZW4tNC4wLnggdGhvdWdoLiBJcyB0aGVyZSBhbiBh
c3N1bXB0aW9uIGluCj4gdGhlIGNvZGUgdGhhdCB0aWVzIFhlbi00LjIgdG8gYSBuZXdlciBrZXJu
ZWw/CgpObywgYnV0IGlmIGUuZy4geW91IG1lcmVseSBsb29rIGF0IHRoZSBkaWZmZXJlbmNlcyBi
ZXR3ZWVuIGJvdGgKY3B1X3VuaW5pdCgpIHZlcnNpb25zLCB5b3UnbGwgYWxyZWFkeSBzZWUgdGhh
dCB0aGVyZSdzIHF1aXRlIGEgYml0Cm1vcmUgd3JpdGluZyBvZiBtZW1vcnkgYmVpbmcgZG9uZSBp
biA0LjAueCB0aGFuIGluIDQuMi4wIG9yCi11bnN0YWJsZSwgd2hpY2ggaW5jcmVhc2VzIHRoZSBj
aGFuY2VzIG9mIGhpZGluZyBhbiBldmVudHVhbApjYWNoZSBmbHVzaGluZyBwcm9ibGVtLgoKSmFu
CgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpYZW4tZGV2
ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW4ub3JnCmh0dHA6Ly9saXN0cy54ZW4u
b3JnL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xen.org Mon Sep 24 12:37:59 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Sep 2012 12: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 1TG7v5-0008AX-Mr; Mon, 24 Sep 2012 12:37:51 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1TG7v4-0008AJ-7G
	for xen-devel@lists.xen.org; Mon, 24 Sep 2012 12:37:50 +0000
Received: from [85.158.139.211:58841] by server-9.bemta-5.messagelabs.com id
	AE/A5-14846-D1450605; Mon, 24 Sep 2012 12:37:49 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1348490268!19278571!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13426 invoked from network); 24 Sep 2012 12:37:49 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-7.tower-206.messagelabs.com with SMTP;
	24 Sep 2012 12:37:49 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 24 Sep 2012 13:37:48 +0100
Message-Id: <5060703B020000780009D58E@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 24 Sep 2012 13:37:47 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ben Guthro" <ben@guthro.net>,<pasik@iki.fi>
References: <CAOvdn6XKPOMNn6AjuYvZvPXRRJffN3po5GXe1Yh1-m0hisMK_w@mail.gmail.com>
	<CC8273A0.4C9DD%keir@xen.org>
	<50605E9A020000780009D486@nat28.tlf.novell.com>
	<CAOvdn6XmB6rj3_QVU+59V8p24Y5G47AWxVEM=id02JWXkuhibQ@mail.gmail.com>
	<5060640B020000780009D4D2@nat28.tlf.novell.com>
	<CAOvdn6XLy8zR2rb2MEyi2aT9LQiFvFLY_H02p181mTsVLVTZkw@mail.gmail.com>
	<20120924122203.GG8912@reaktio.net>
	<CAOvdn6XV4eoA-FfFns1xhx7HCUqXc7KHxZwyKuT4FHG8s3R5RQ@mail.gmail.com>
In-Reply-To: <CAOvdn6XV4eoA-FfFns1xhx7HCUqXc7KHxZwyKuT4FHG8s3R5RQ@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>, Keir Fraser <keir@xen.org>,
	john.baboval@citrix.com, Thomas Goetz <thomas.goetz@citrix.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen4.2 S3 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="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Pj4+IE9uIDI0LjA5LjEyIGF0IDE0OjI3LCBCZW4gR3V0aHJvIDxiZW5AZ3V0aHJvLm5ldD4gd3Jv
dGU6Cj4gT24gTW9uLCBTZXAgMjQsIDIwMTIgYXQgODoyMiBBTSwgUGFzaSBLw6Rya2vDpGluZW4g
PHBhc2lrQGlraS5maT4gd3JvdGU6Cj4gCj4+IE9uIE1vbiwgU2VwIDI0LCAyMDEyIGF0IDA3OjU0
OjA1QU0gLTA0MDAsIEJlbiBHdXRocm8gd3JvdGU6Cj4+ID4gICAgSSBzZWUgLSBLb25yYWQgLSBk
byB5b3UgaGF2ZSBhIGNoYW5nZXNldCBJIGNhbiBsb29rIGZvciB3aXRoIHRoZQo+PiBmZWF0dXJl
cwo+PiA+ICAgIEphbiBkZXNjcmliZXM/Cj4+Cj4+IHhlbi1hY3BpLXByb2Nlc3NvciBkcml2ZXIg
d2FzIG1lcmdlZCB0byB1cHN0cmVhbSBMaW51eCBrZXJuZWwgdjMuNC4KPj4KPj4KPiBJIHNlZSAt
IHNvIHRoZSBhZHZhbmNlZCBtZXRob2RzIGFyZSBub3QgYmVpbmcgdXNlZCB0aGVuCj4gVGhpcyBz
YW1lIGtlcm5lbCBkb2VzIHdvcmsgd2l0aCBYZW4tNC4wLnggdGhvdWdoLiBJcyB0aGVyZSBhbiBh
c3N1bXB0aW9uIGluCj4gdGhlIGNvZGUgdGhhdCB0aWVzIFhlbi00LjIgdG8gYSBuZXdlciBrZXJu
ZWw/CgpObywgYnV0IGlmIGUuZy4geW91IG1lcmVseSBsb29rIGF0IHRoZSBkaWZmZXJlbmNlcyBi
ZXR3ZWVuIGJvdGgKY3B1X3VuaW5pdCgpIHZlcnNpb25zLCB5b3UnbGwgYWxyZWFkeSBzZWUgdGhh
dCB0aGVyZSdzIHF1aXRlIGEgYml0Cm1vcmUgd3JpdGluZyBvZiBtZW1vcnkgYmVpbmcgZG9uZSBp
biA0LjAueCB0aGFuIGluIDQuMi4wIG9yCi11bnN0YWJsZSwgd2hpY2ggaW5jcmVhc2VzIHRoZSBj
aGFuY2VzIG9mIGhpZGluZyBhbiBldmVudHVhbApjYWNoZSBmbHVzaGluZyBwcm9ibGVtLgoKSmFu
CgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpYZW4tZGV2
ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW4ub3JnCmh0dHA6Ly9saXN0cy54ZW4u
b3JnL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xen.org Mon Sep 24 13:13:25 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Sep 2012 13:13:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TG8TA-0000an-C4; Mon, 24 Sep 2012 13:13:04 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <vivagin@yeah.net>) id 1TG8T9-0000ai-8T
	for xen-devel@lists.xensource.com; Mon, 24 Sep 2012 13:13:03 +0000
Received: from [85.158.138.51:31533] by server-15.bemta-3.messagelabs.com id
	AD/5B-09665-E5C50605; Mon, 24 Sep 2012 13:13:02 +0000
X-Env-Sender: vivagin@yeah.net
X-Msg-Ref: server-8.tower-174.messagelabs.com!1348492380!31720678!1
X-Originating-IP: [216.139.236.26]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18473 invoked from network); 24 Sep 2012 13:13:01 -0000
Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26)
	by server-8.tower-174.messagelabs.com with AES256-SHA encrypted SMTP;
	24 Sep 2012 13:13:01 -0000
Received: from [192.168.236.26] (helo=sam.nabble.com)
	by sam.nabble.com with esmtp (Exim 4.72)
	(envelope-from <vivagin@yeah.net>) id 1TG8T5-00028H-0J
	for xen-devel@lists.xensource.com; Mon, 24 Sep 2012 06:12:59 -0700
Date: Mon, 24 Sep 2012 06:12:59 -0700 (PDT)
From: Bruce Granger <vivagin@yeah.net>
To: xen-devel@lists.xensource.com
Message-ID: <1348492379003-5711476.post@n5.nabble.com>
In-Reply-To: <1348197814609-5711421.post@n5.nabble.com>
References: <1348197814609-5711421.post@n5.nabble.com>
MIME-Version: 1.0
Subject: Re: [Xen-devel] How could Xen know a certain GuestOS have already
 shutdown?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

It's my honor to receive your answer! Thanks very much!
I have learned much more under your guidance,but I still have a little
question!
I've traced the VIRQ_DOM_EXC which  send from Xen to Dom0 and picked up by
xenstored which fires the @releaseDomain watch when a GuestOS start to
shutdown.

Here, I still have two questions.
First, I haven't found anything useful in the archives about 'releaseDomain
watch'.What is the called '@releaseDomain' ? what's the use of it?
Second,I think that VIRQ_DOM_EXC is the signal used for communicate between
hypervisor and Dom0. I talked that with my parterner, we think that when
shutdown occurs, GuestOS will first get in touch with hypervisor ,then cause
the communication between Xen and Dom0 by VIRQ_DOM_EXC,is that right? What
we also want to know is when shutdown operation occurs in GuestOS, how
GuestOS communicate with the hypervisor first? Is there any signal or
somehow event delivery?
Could you tell me more about that?

Thanks a lot!



--
View this message in context: http://xen.1045712.n5.nabble.com/Xen-devel-How-could-Xen-know-a-certain-GuestOS-have-already-shutdown-tp5711421p5711476.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 Sep 24 13:13:25 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Sep 2012 13:13:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TG8TA-0000an-C4; Mon, 24 Sep 2012 13:13:04 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <vivagin@yeah.net>) id 1TG8T9-0000ai-8T
	for xen-devel@lists.xensource.com; Mon, 24 Sep 2012 13:13:03 +0000
Received: from [85.158.138.51:31533] by server-15.bemta-3.messagelabs.com id
	AD/5B-09665-E5C50605; Mon, 24 Sep 2012 13:13:02 +0000
X-Env-Sender: vivagin@yeah.net
X-Msg-Ref: server-8.tower-174.messagelabs.com!1348492380!31720678!1
X-Originating-IP: [216.139.236.26]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18473 invoked from network); 24 Sep 2012 13:13:01 -0000
Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26)
	by server-8.tower-174.messagelabs.com with AES256-SHA encrypted SMTP;
	24 Sep 2012 13:13:01 -0000
Received: from [192.168.236.26] (helo=sam.nabble.com)
	by sam.nabble.com with esmtp (Exim 4.72)
	(envelope-from <vivagin@yeah.net>) id 1TG8T5-00028H-0J
	for xen-devel@lists.xensource.com; Mon, 24 Sep 2012 06:12:59 -0700
Date: Mon, 24 Sep 2012 06:12:59 -0700 (PDT)
From: Bruce Granger <vivagin@yeah.net>
To: xen-devel@lists.xensource.com
Message-ID: <1348492379003-5711476.post@n5.nabble.com>
In-Reply-To: <1348197814609-5711421.post@n5.nabble.com>
References: <1348197814609-5711421.post@n5.nabble.com>
MIME-Version: 1.0
Subject: Re: [Xen-devel] How could Xen know a certain GuestOS have already
 shutdown?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

It's my honor to receive your answer! Thanks very much!
I have learned much more under your guidance,but I still have a little
question!
I've traced the VIRQ_DOM_EXC which  send from Xen to Dom0 and picked up by
xenstored which fires the @releaseDomain watch when a GuestOS start to
shutdown.

Here, I still have two questions.
First, I haven't found anything useful in the archives about 'releaseDomain
watch'.What is the called '@releaseDomain' ? what's the use of it?
Second,I think that VIRQ_DOM_EXC is the signal used for communicate between
hypervisor and Dom0. I talked that with my parterner, we think that when
shutdown occurs, GuestOS will first get in touch with hypervisor ,then cause
the communication between Xen and Dom0 by VIRQ_DOM_EXC,is that right? What
we also want to know is when shutdown operation occurs in GuestOS, how
GuestOS communicate with the hypervisor first? Is there any signal or
somehow event delivery?
Could you tell me more about that?

Thanks a lot!



--
View this message in context: http://xen.1045712.n5.nabble.com/Xen-devel-How-could-Xen-know-a-certain-GuestOS-have-already-shutdown-tp5711421p5711476.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 Sep 24 13:28:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Sep 2012 13:28:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TG8hQ-00012g-LT; Mon, 24 Sep 2012 13:27:48 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ketuzsezr@gmail.com>) id 1TG8hP-00012Y-MG
	for xen-devel@lists.xen.org; Mon, 24 Sep 2012 13:27:47 +0000
Received: from [85.158.143.99:61167] by server-3.bemta-4.messagelabs.com id
	6A/F9-10986-3DF50605; Mon, 24 Sep 2012 13:27:47 +0000
X-Env-Sender: ketuzsezr@gmail.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1348493264!30638479!1
X-Originating-IP: [209.85.216.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27413 invoked from network); 24 Sep 2012 13:27:45 -0000
Received: from mail-qa0-f45.google.com (HELO mail-qa0-f45.google.com)
	(209.85.216.45)
	by server-13.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Sep 2012 13:27:45 -0000
Received: by qadc10 with SMTP id c10so3283953qad.11
	for <xen-devel@lists.xen.org>; Mon, 24 Sep 2012 06:27:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:date:from:to:cc:subject:message-id:references:mime-version
	:content-type:content-disposition:in-reply-to:user-agent;
	bh=0XVY2KzLvfbbz7mDQBQ59g+5ooQnzEMHuUarffFXmHk=;
	b=WkkbFLHdCZ8mqcOMIkKT+G8Mui474deYcKjev/Vimv8+7V6iId6I1vFt/tz5rYhrGE
	nTtlWlenfNWFeeEI/+sFLoKLcuoy6pDeYYVQxHbgsf2N8OUuk/3/EYluYwu58CddF9ku
	Gs5Sb7+EwU2lxHgzyRwaAfSu1psPGh8iQC6EdWGynpmE3Bm9AqVlvCqbru6eN689zc6M
	wXXu4qeMWaBdFfdoQMPnPoOHWUuAS6Ibm8+WjIRcJ39uifGVDPIleJJrhlst36MzUsKK
	Uw0TgGN55O99BLioMh7wVtK7A4S5aobVxpGSCwhiclufvl4L8vLmIb6HTfNtYuJdZ4hN
	GIGg==
Received: by 10.224.180.83 with SMTP id bt19mr21395526qab.82.1348493249353;
	Mon, 24 Sep 2012 06:27:29 -0700 (PDT)
Received: from phenom.dumpdata.com
	(50-195-21-189-static.hfc.comcastbusiness.net. [50.195.21.189])
	by mx.google.com with ESMTPS id g18sm23237354qan.1.2012.09.24.06.27.28
	(version=TLSv1/SSLv3 cipher=OTHER);
	Mon, 24 Sep 2012 06:27:28 -0700 (PDT)
Date: Mon, 24 Sep 2012 09:16:14 -0400
From: Konrad Rzeszutek Wilk <konrad@kernel.org>
To: "Wu, GabrielX" <gabrielx.wu@intel.com>
Message-ID: <20120924131613.GA17928@phenom.dumpdata.com>
References: <E4558C0C96688748837EB1B05BEED75A0FD73A8A@SHSMSX102.ccr.corp.intel.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <E4558C0C96688748837EB1B05BEED75A0FD73A8A@SHSMSX102.ccr.corp.intel.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: "Zhou, Chao" <chao.zhou@intel.com>, "Ren, Yongjie" <yongjie.ren@intel.com>,
	"Liu, SongtaoX" <songtaox.liu@intel.com>, "Liu,
	RongrongX" <rongrongx.liu@intel.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] VMX status report. Xen:25929 & Dom0:3.5.4
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Sep 24, 2012 at 06:17:33AM +0000, Wu, GabrielX wrote:
> Hi all,
> 
> This is the test report of xen-unstable tree, no issue found and two issues fixed.

Wohoo! Great!
> 
> Version Info:
> =================================================================
> xen-changeset:   25929:fee83ac77d8c
> Dom0:          linux.git  3.5.4
> =================================================================
> 
> New issue(0)
> ==============
> 
> Fixed issues(2)
> ==============
> 1. RHEL6.2/6.1 guest runs quite slow
>   http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1811
> 2. XenU PV guest with VIF network cannot boot up with Linux3.6 dom0
>   http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1832
> 
> 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. after detaching a VF from a guest, shutdown the guest is very slow
>   http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1812
> 6. Poor performance when do guest save/restore and migration with linux 3.1 dom0
>   http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1784

Added some questions in the bug.
> 7. vcpu-set doesn't take effect on guest
>   http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1822
> 8.Fail to probe NIC driver in domu
>   http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1824
> 9. Dom0 cannot be shutdown before PCI device detachment from guest
>   http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1826

The same - added some questions that I believe I asked on the mailing
list last time.
> 
> 
> Best Regards,
> Ronghui Wu(Gabriel)
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Sep 24 13:28:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Sep 2012 13:28:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TG8hQ-00012g-LT; Mon, 24 Sep 2012 13:27:48 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ketuzsezr@gmail.com>) id 1TG8hP-00012Y-MG
	for xen-devel@lists.xen.org; Mon, 24 Sep 2012 13:27:47 +0000
Received: from [85.158.143.99:61167] by server-3.bemta-4.messagelabs.com id
	6A/F9-10986-3DF50605; Mon, 24 Sep 2012 13:27:47 +0000
X-Env-Sender: ketuzsezr@gmail.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1348493264!30638479!1
X-Originating-IP: [209.85.216.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27413 invoked from network); 24 Sep 2012 13:27:45 -0000
Received: from mail-qa0-f45.google.com (HELO mail-qa0-f45.google.com)
	(209.85.216.45)
	by server-13.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Sep 2012 13:27:45 -0000
Received: by qadc10 with SMTP id c10so3283953qad.11
	for <xen-devel@lists.xen.org>; Mon, 24 Sep 2012 06:27:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:date:from:to:cc:subject:message-id:references:mime-version
	:content-type:content-disposition:in-reply-to:user-agent;
	bh=0XVY2KzLvfbbz7mDQBQ59g+5ooQnzEMHuUarffFXmHk=;
	b=WkkbFLHdCZ8mqcOMIkKT+G8Mui474deYcKjev/Vimv8+7V6iId6I1vFt/tz5rYhrGE
	nTtlWlenfNWFeeEI/+sFLoKLcuoy6pDeYYVQxHbgsf2N8OUuk/3/EYluYwu58CddF9ku
	Gs5Sb7+EwU2lxHgzyRwaAfSu1psPGh8iQC6EdWGynpmE3Bm9AqVlvCqbru6eN689zc6M
	wXXu4qeMWaBdFfdoQMPnPoOHWUuAS6Ibm8+WjIRcJ39uifGVDPIleJJrhlst36MzUsKK
	Uw0TgGN55O99BLioMh7wVtK7A4S5aobVxpGSCwhiclufvl4L8vLmIb6HTfNtYuJdZ4hN
	GIGg==
Received: by 10.224.180.83 with SMTP id bt19mr21395526qab.82.1348493249353;
	Mon, 24 Sep 2012 06:27:29 -0700 (PDT)
Received: from phenom.dumpdata.com
	(50-195-21-189-static.hfc.comcastbusiness.net. [50.195.21.189])
	by mx.google.com with ESMTPS id g18sm23237354qan.1.2012.09.24.06.27.28
	(version=TLSv1/SSLv3 cipher=OTHER);
	Mon, 24 Sep 2012 06:27:28 -0700 (PDT)
Date: Mon, 24 Sep 2012 09:16:14 -0400
From: Konrad Rzeszutek Wilk <konrad@kernel.org>
To: "Wu, GabrielX" <gabrielx.wu@intel.com>
Message-ID: <20120924131613.GA17928@phenom.dumpdata.com>
References: <E4558C0C96688748837EB1B05BEED75A0FD73A8A@SHSMSX102.ccr.corp.intel.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <E4558C0C96688748837EB1B05BEED75A0FD73A8A@SHSMSX102.ccr.corp.intel.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: "Zhou, Chao" <chao.zhou@intel.com>, "Ren, Yongjie" <yongjie.ren@intel.com>,
	"Liu, SongtaoX" <songtaox.liu@intel.com>, "Liu,
	RongrongX" <rongrongx.liu@intel.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] VMX status report. Xen:25929 & Dom0:3.5.4
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Sep 24, 2012 at 06:17:33AM +0000, Wu, GabrielX wrote:
> Hi all,
> 
> This is the test report of xen-unstable tree, no issue found and two issues fixed.

Wohoo! Great!
> 
> Version Info:
> =================================================================
> xen-changeset:   25929:fee83ac77d8c
> Dom0:          linux.git  3.5.4
> =================================================================
> 
> New issue(0)
> ==============
> 
> Fixed issues(2)
> ==============
> 1. RHEL6.2/6.1 guest runs quite slow
>   http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1811
> 2. XenU PV guest with VIF network cannot boot up with Linux3.6 dom0
>   http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1832
> 
> 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. after detaching a VF from a guest, shutdown the guest is very slow
>   http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1812
> 6. Poor performance when do guest save/restore and migration with linux 3.1 dom0
>   http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1784

Added some questions in the bug.
> 7. vcpu-set doesn't take effect on guest
>   http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1822
> 8.Fail to probe NIC driver in domu
>   http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1824
> 9. Dom0 cannot be shutdown before PCI device detachment from guest
>   http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1826

The same - added some questions that I believe I asked on the mailing
list last time.
> 
> 
> Best Regards,
> Ronghui Wu(Gabriel)
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Sep 24 13:36:49 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Sep 2012 13: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 1TG8pl-0001I8-LN; Mon, 24 Sep 2012 13:36:25 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ketuzsezr@gmail.com>) id 1TG8pk-0001I3-K3
	for xen-devel@lists.xen.org; Mon, 24 Sep 2012 13:36:24 +0000
Received: from [85.158.138.51:29971] by server-10.bemta-3.messagelabs.com id
	CB/52-10411-7D160605; Mon, 24 Sep 2012 13:36:23 +0000
X-Env-Sender: ketuzsezr@gmail.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1348493781!31262593!1
X-Originating-IP: [209.85.216.52]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
  RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2878 invoked from network); 24 Sep 2012 13:36:22 -0000
Received: from mail-qa0-f52.google.com (HELO mail-qa0-f52.google.com)
	(209.85.216.52)
	by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Sep 2012 13:36:22 -0000
Received: by qabg24 with SMTP id g24so2547802qab.11
	for <xen-devel@lists.xen.org>; Mon, 24 Sep 2012 06:36:20 -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=dnOK+X/ee9JFbhCFdmMFveJsPw+oHJH9CjKHxKE/fT4=;
	b=CWSVCYrYGzliHpSR37TCsDIZMRH4qge7orWNckM2YxymNDnD8QkB924daWrsX7D3++
	tSa5NnXJIyQcR97RrRD+O/pMCI3nTgqsJCtec6TrT0JETJIOSjoa7RcFOxSm0vUJcfut
	7aYUqGElAWBIpMr+MNqDuhj502AgZIbsMhBVauMwq/nWp+UeGt0YLIutPduokzySRcZP
	VPTQmB14uUv4rsuo2wgR1Xaas/XlCM8nPxfEvS2rEh2fJ1Bz31iGkIhcMT03FL6X8HQK
	MImLwTUMaXcziwvtEnfgxqN2hyRjk+hUjue4Aklnk1pPIXONe2pzYJ+jNI+Vplvy6YCB
	T4UA==
Received: by 10.224.186.203 with SMTP id ct11mr32094479qab.80.1348493780834;
	Mon, 24 Sep 2012 06:36:20 -0700 (PDT)
Received: from phenom.dumpdata.com
	(50-195-21-189-static.hfc.comcastbusiness.net. [50.195.21.189])
	by mx.google.com with ESMTPS id ep8sm25692250qab.22.2012.09.24.06.36.19
	(version=TLSv1/SSLv3 cipher=OTHER);
	Mon, 24 Sep 2012 06:36:20 -0700 (PDT)
Date: Mon, 24 Sep 2012 09:25:04 -0400
From: Konrad Rzeszutek Wilk <konrad@kernel.org>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20120924132504.GB17928@phenom.dumpdata.com>
References: <504F3F8A020000780009A8F9@nat28.tlf.novell.com>
	<20120921163406.GC4780@phenom.dumpdata.com>
	<506056A6020000780009D453@nat28.tlf.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <506056A6020000780009D453@nat28.tlf.novell.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] x86: retrieve keyboard shift status flags
 from BIOS
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> > Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> 
> Acked-by: Jan Beulich <jbeulich@suse.com>
> 
> (but also see below)
.. snip..
> > flags. */
> >  struct xenpf_firmware_info {
> >  	/* IN variables. */
> >  	uint32_t type;
> > @@ -142,6 +143,8 @@ struct xenpf_firmware_info {
> >  			/* must refer to 128-byte buffer */
> >  			GUEST_HANDLE(uchar) edid;
> >  		} vbeddc_info; /* XEN_FW_VBEDDC_INFO */
> > +		uint8_t kbd_shift_flags; /* XEN_FW_KBD_SHIFT_FLAGS */
> > +
> 
> I'd prefer to not have stray empty line here - if anything, it should
> go before the new union member.
> 

Done! Thx for the review.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 24 13:36:49 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Sep 2012 13: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 1TG8pl-0001I8-LN; Mon, 24 Sep 2012 13:36:25 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ketuzsezr@gmail.com>) id 1TG8pk-0001I3-K3
	for xen-devel@lists.xen.org; Mon, 24 Sep 2012 13:36:24 +0000
Received: from [85.158.138.51:29971] by server-10.bemta-3.messagelabs.com id
	CB/52-10411-7D160605; Mon, 24 Sep 2012 13:36:23 +0000
X-Env-Sender: ketuzsezr@gmail.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1348493781!31262593!1
X-Originating-IP: [209.85.216.52]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
  RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2878 invoked from network); 24 Sep 2012 13:36:22 -0000
Received: from mail-qa0-f52.google.com (HELO mail-qa0-f52.google.com)
	(209.85.216.52)
	by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Sep 2012 13:36:22 -0000
Received: by qabg24 with SMTP id g24so2547802qab.11
	for <xen-devel@lists.xen.org>; Mon, 24 Sep 2012 06:36:20 -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=dnOK+X/ee9JFbhCFdmMFveJsPw+oHJH9CjKHxKE/fT4=;
	b=CWSVCYrYGzliHpSR37TCsDIZMRH4qge7orWNckM2YxymNDnD8QkB924daWrsX7D3++
	tSa5NnXJIyQcR97RrRD+O/pMCI3nTgqsJCtec6TrT0JETJIOSjoa7RcFOxSm0vUJcfut
	7aYUqGElAWBIpMr+MNqDuhj502AgZIbsMhBVauMwq/nWp+UeGt0YLIutPduokzySRcZP
	VPTQmB14uUv4rsuo2wgR1Xaas/XlCM8nPxfEvS2rEh2fJ1Bz31iGkIhcMT03FL6X8HQK
	MImLwTUMaXcziwvtEnfgxqN2hyRjk+hUjue4Aklnk1pPIXONe2pzYJ+jNI+Vplvy6YCB
	T4UA==
Received: by 10.224.186.203 with SMTP id ct11mr32094479qab.80.1348493780834;
	Mon, 24 Sep 2012 06:36:20 -0700 (PDT)
Received: from phenom.dumpdata.com
	(50-195-21-189-static.hfc.comcastbusiness.net. [50.195.21.189])
	by mx.google.com with ESMTPS id ep8sm25692250qab.22.2012.09.24.06.36.19
	(version=TLSv1/SSLv3 cipher=OTHER);
	Mon, 24 Sep 2012 06:36:20 -0700 (PDT)
Date: Mon, 24 Sep 2012 09:25:04 -0400
From: Konrad Rzeszutek Wilk <konrad@kernel.org>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20120924132504.GB17928@phenom.dumpdata.com>
References: <504F3F8A020000780009A8F9@nat28.tlf.novell.com>
	<20120921163406.GC4780@phenom.dumpdata.com>
	<506056A6020000780009D453@nat28.tlf.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <506056A6020000780009D453@nat28.tlf.novell.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] x86: retrieve keyboard shift status flags
 from BIOS
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> > Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> 
> Acked-by: Jan Beulich <jbeulich@suse.com>
> 
> (but also see below)
.. snip..
> > flags. */
> >  struct xenpf_firmware_info {
> >  	/* IN variables. */
> >  	uint32_t type;
> > @@ -142,6 +143,8 @@ struct xenpf_firmware_info {
> >  			/* must refer to 128-byte buffer */
> >  			GUEST_HANDLE(uchar) edid;
> >  		} vbeddc_info; /* XEN_FW_VBEDDC_INFO */
> > +		uint8_t kbd_shift_flags; /* XEN_FW_KBD_SHIFT_FLAGS */
> > +
> 
> I'd prefer to not have stray empty line here - if anything, it should
> go before the new union member.
> 

Done! Thx for the review.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 24 13:55:28 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Sep 2012 13:55: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 1TG97s-0001SN-CA; Mon, 24 Sep 2012 13:55:08 +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 1TG97q-0001SI-It
	for xen-devel@lists.xensource.com; Mon, 24 Sep 2012 13:55:06 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1348494898!8862673!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzU5Njc1\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3264 invoked from network); 24 Sep 2012 13:54:59 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-8.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 24 Sep 2012 13:54:59 -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 q8ODsulP026970
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 24 Sep 2012 13:54:57 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q8ODsuBc014465
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 24 Sep 2012 13:54:56 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
	q8ODstqw027783; Mon, 24 Sep 2012 08:54:55 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 24 Sep 2012 06:54:55 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 2B15A4031C; Mon, 24 Sep 2012 09:43:43 -0400 (EDT)
Date: Mon, 24 Sep 2012 09:43:43 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Linus Torvalds <torvalds@linux-foundation.org>,
	linux-kernel@vger.kernel.org
Message-ID: <20120924134343.GA31618@phenom.dumpdata.com>
MIME-Version: 1.0
Content-Disposition: inline
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: xen-devel@lists.xensource.com
Subject: [Xen-devel] [GIT PULL] (xen) stable/for-linus-3.7-rc7-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,

I've one fix for which I got the Tested-by right after I sent you a git pull on
Friday. If you have some extra patches for rc7, please consider pulling it.
If you don't have any - I will just stick this in my for-v3.7.

git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git stable/for-linus-3.6-rc7-tag

It is a bug-fix when we run the initial PV guest on a AMD K8 machine
and have CONFIG_AMD_NUMA enabled and detect the NUMA topology from the Northbridge.

We end up in the situation where the initial domain gets too much information
and gets confused and crashes - the fix is to restrict the domain to get the
information - and we do it by just disabling NUMA on the PV guest (the hypervisor is
still able to do its proper NUMA allocations of guests). It is OK to disable the PV
guest from accessing NUMA data as right now we do not inject any NUMA node information
to the PV guests. When we do get to that point, then this patch will have to be reverted.

Konrad Rzeszutek Wilk (1):
      xen/boot: Disable NUMA for PV guests.

 arch/x86/xen/setup.c |    4 ++++
 1 files changed, 4 insertions(+), 0 deletions(-)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 24 13:55:28 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Sep 2012 13:55: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 1TG97s-0001SN-CA; Mon, 24 Sep 2012 13:55:08 +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 1TG97q-0001SI-It
	for xen-devel@lists.xensource.com; Mon, 24 Sep 2012 13:55:06 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1348494898!8862673!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzU5Njc1\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3264 invoked from network); 24 Sep 2012 13:54:59 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-8.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 24 Sep 2012 13:54:59 -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 q8ODsulP026970
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 24 Sep 2012 13:54:57 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q8ODsuBc014465
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 24 Sep 2012 13:54:56 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
	q8ODstqw027783; Mon, 24 Sep 2012 08:54:55 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 24 Sep 2012 06:54:55 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 2B15A4031C; Mon, 24 Sep 2012 09:43:43 -0400 (EDT)
Date: Mon, 24 Sep 2012 09:43:43 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Linus Torvalds <torvalds@linux-foundation.org>,
	linux-kernel@vger.kernel.org
Message-ID: <20120924134343.GA31618@phenom.dumpdata.com>
MIME-Version: 1.0
Content-Disposition: inline
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: xen-devel@lists.xensource.com
Subject: [Xen-devel] [GIT PULL] (xen) stable/for-linus-3.7-rc7-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,

I've one fix for which I got the Tested-by right after I sent you a git pull on
Friday. If you have some extra patches for rc7, please consider pulling it.
If you don't have any - I will just stick this in my for-v3.7.

git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git stable/for-linus-3.6-rc7-tag

It is a bug-fix when we run the initial PV guest on a AMD K8 machine
and have CONFIG_AMD_NUMA enabled and detect the NUMA topology from the Northbridge.

We end up in the situation where the initial domain gets too much information
and gets confused and crashes - the fix is to restrict the domain to get the
information - and we do it by just disabling NUMA on the PV guest (the hypervisor is
still able to do its proper NUMA allocations of guests). It is OK to disable the PV
guest from accessing NUMA data as right now we do not inject any NUMA node information
to the PV guests. When we do get to that point, then this patch will have to be reverted.

Konrad Rzeszutek Wilk (1):
      xen/boot: Disable NUMA for PV guests.

 arch/x86/xen/setup.c |    4 ++++
 1 files changed, 4 insertions(+), 0 deletions(-)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 24 13:56:17 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Sep 2012 13:56: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 1TG98j-0001VE-Pp; Mon, 24 Sep 2012 13:56: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 1TG98i-0001V6-CB
	for Xen-devel@lists.xensource.com; Mon, 24 Sep 2012 13:56:00 +0000
Received: from [85.158.143.99:55938] by server-2.bemta-4.messagelabs.com id
	2E/94-06610-F6660605; Mon, 24 Sep 2012 13:55:59 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1348494958!23367584!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTA4NDk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7645 invoked from network); 24 Sep 2012 13:55:58 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Sep 2012 13:55:58 -0000
X-IronPort-AV: E=Sophos;i="4.80,476,1344211200"; d="scan'208";a="14725651"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Sep 2012 13:55: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.279.1; Mon, 24 Sep 2012 14:55:58 +0100
Date: Mon, 24 Sep 2012 14:55:06 +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: <20120921121928.1c5765bc@mantra.us.oracle.com>
Message-ID: <alpine.DEB.2.02.1209241423450.29232@kaball.uk.xensource.com>
References: <20120921121928.1c5765bc@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>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH v1 6/8]: PVH ballooning and grant changes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 21 Sep 2012, Mukesh Rathor wrote:
> ---
>  drivers/xen/balloon.c     |   35 ++++++++++++++++++++++++++++-------
>  drivers/xen/gntdev.c      |    3 ++-
>  drivers/xen/grant-table.c |   25 +++++++++++++++++++++----
>  3 files changed, 51 insertions(+), 12 deletions(-)
> 
> diff --git a/drivers/xen/balloon.c b/drivers/xen/balloon.c
> index 31ab82f..85a6917 100644
> --- a/drivers/xen/balloon.c
> +++ b/drivers/xen/balloon.c
> @@ -358,10 +358,21 @@ static enum bp_state increase_reservation(unsigned long nr_pages)
>  		BUG_ON(!xen_feature(XENFEAT_auto_translated_physmap) &&
>  		       phys_to_machine_mapping_valid(pfn));
>  
> -		set_phys_to_machine(pfn, frame_list[i]);
> +		if (xen_pv_domain() && 
> +		    xen_feature(XENFEAT_auto_translated_physmap)) {
> +			/* PVH: we just need to update native page table */
> +			pte_t *ptep;
> +			unsigned int level;
> +			void *addr = __va(pfn << PAGE_SHIFT);
> +			ptep = lookup_address((unsigned long)addr, &level);
> +			set_pte(ptep, pfn_pte(pfn, PAGE_KERNEL));
> +		} else
> +			set_phys_to_machine(pfn, frame_list[i]);



>  		/* Link back into the page tables if not highmem. */
> -		if (xen_pv_domain() && !PageHighMem(page)) {
> +		if (xen_pv_domain() && !PageHighMem(page) && 
> +		    !xen_feature(XENFEAT_auto_translated_physmap)) {
> +
>  			int ret;
>  			ret = HYPERVISOR_update_va_mapping(
>  				(unsigned long)__va(pfn << PAGE_SHIFT),
> @@ -418,12 +429,21 @@ static enum bp_state decrease_reservation(unsigned long nr_pages, gfp_t gfp)
>  		scrub_page(page);
>  
>  		if (xen_pv_domain() && !PageHighMem(page)) {
> -			ret = HYPERVISOR_update_va_mapping(
> -				(unsigned long)__va(pfn << PAGE_SHIFT),
> -				__pte_ma(0), 0);
> -			BUG_ON(ret);
> +			if (xen_feature(XENFEAT_auto_translated_physmap)) {
> +				unsigned int level;
> +				pte_t *ptep;
> +				void *addr = __va(pfn << PAGE_SHIFT);
> +				ptep = lookup_address((unsigned long)addr, 
> +							&level);
> +				set_pte(ptep, __pte(0));
> +
> +			} else {
> +				ret = HYPERVISOR_update_va_mapping(
> +					(unsigned long)__va(pfn << PAGE_SHIFT),
> +					__pte_ma(0), 0);
> +				BUG_ON(ret);
> +			}
>  		}
> -
>  	}
>  
>  	/* Ensure that ballooned highmem pages don't have kmaps. */
> @@ -433,6 +453,7 @@ static enum bp_state decrease_reservation(unsigned long nr_pages, gfp_t gfp)
>  	/* No more mappings: invalidate P2M and add to balloon. */
>  	for (i = 0; i < nr_pages; i++) {
>  		pfn = mfn_to_pfn(frame_list[i]);
> +		/* PVH note: following will noop for auto translated */
>  		__set_phys_to_machine(pfn, INVALID_P2M_ENTRY);
>  		balloon_append(pfn_to_page(pfn));
>  	}

Maybe we need a function "update_mapping" internal to balloon.c that
would be set to HYPERVISOR_update_va_mapping for pv guests, set_pte for
pvh guests and nothing for pv on hvm guests.

Speaking of which, why do pvh guests need a set_pte while pv on hvm
guests don't? I would think that their behaviour should be the same
regarding ballooning.


> diff --git a/drivers/xen/gntdev.c b/drivers/xen/gntdev.c
> index 1ffd03b..35d1e3c 100644
> --- a/drivers/xen/gntdev.c
> +++ b/drivers/xen/gntdev.c
> @@ -802,7 +802,8 @@ static int __init gntdev_init(void)
>  	if (!xen_domain())
>  		return -ENODEV;
>  
> -	use_ptemod = xen_pv_domain();
> +	use_ptemod = xen_pv_domain() && 
> +		     !xen_feature(XENFEAT_auto_translated_physmap);
>  
>  	err = misc_register(&gntdev_miscdev);
>  	if (err != 0) {
> diff --git a/drivers/xen/grant-table.c b/drivers/xen/grant-table.c
> index 0bfc1ef..d831d52 100644
> --- a/drivers/xen/grant-table.c
> +++ b/drivers/xen/grant-table.c
> @@ -974,14 +974,19 @@ static void gnttab_unmap_frames_v2(void)
>  static int gnttab_map(unsigned int start_idx, unsigned int end_idx)
>  {
>  	struct gnttab_setup_table setup;
> -	unsigned long *frames;
> +	unsigned long *frames, start_gpfn;
>  	unsigned int nr_gframes = end_idx + 1;
>  	int rc;
>  
> -	if (xen_hvm_domain()) {
> +	if (xen_hvm_domain() || xen_feature(XENFEAT_auto_translated_physmap)) {
>  		struct xen_add_to_physmap xatp;
>  		unsigned int i = end_idx;
>  		rc = 0;
> +
> +		if (xen_hvm_domain())
> +			start_gpfn = xen_hvm_resume_frames >> PAGE_SHIFT;
> +		else
> +			start_gpfn = virt_to_pfn(gnttab_shared.addr);
>  		/*
>  		 * Loop backwards, so that the first hypercall has the largest
>  		 * index, ensuring that the table will grow only once.
> @@ -990,7 +995,7 @@ static int gnttab_map(unsigned int start_idx, unsigned int end_idx)
>  			xatp.domid = DOMID_SELF;
>  			xatp.idx = i;
>  			xatp.space = XENMAPSPACE_grant_table;
> -			xatp.gpfn = (xen_hvm_resume_frames >> PAGE_SHIFT) + i;
> +			xatp.gpfn = start_gpfn + i;
>  			rc = HYPERVISOR_memory_op(XENMEM_add_to_physmap, &xatp);
>  			if (rc != 0) {
>  				printk(KERN_WARNING
> @@ -1053,7 +1058,7 @@ static void gnttab_request_version(void)
>  	int rc;
>  	struct gnttab_set_version gsv;
>  
> -	if (xen_hvm_domain())
> +	if (xen_hvm_domain() || xen_feature(XENFEAT_auto_translated_physmap))
>  		gsv.version = 1;
>  	else
>  		gsv.version = 2;
> @@ -1081,12 +1086,24 @@ static void gnttab_request_version(void)
>  int gnttab_resume(void)
>  {
>  	unsigned int max_nr_gframes;
> +	char *kmsg="Failed to kmalloc pages for pv in hvm grant frames\n";
>  
>  	gnttab_request_version();
>  	max_nr_gframes = gnttab_max_grant_frames();
>  	if (max_nr_gframes < nr_grant_frames)
>  		return -ENOSYS;
>  
> +	/* PVH note: xen will free existing kmalloc'd mfn in 
> +	 * XENMEM_add_to_physmap */
> +	if (xen_pv_domain() && xen_feature(XENFEAT_auto_translated_physmap) && 
> +	    !gnttab_shared.addr) {
> +		gnttab_shared.addr =
> +			kmalloc(max_nr_gframes * PAGE_SIZE, GFP_KERNEL);
> +		if ( !gnttab_shared.addr ) {
> +			printk(KERN_WARNING "%s", kmsg);
> +			return -ENOMEM;
> +		}
> +	}

the way PVH guests use gnttab_shared.addr is very similar to the way PV
on HVM guests use xen_hvm_resume_frames, except that
xen_hvm_resume_frames is allocated using alloc_xen_mmio instead of
kmalloc.

I wonder if it would produce better code switching PV on HVM guests to
gnttab_shared.addr too (or PVH guests to xen_hvm_resume_frames, but then
xen_hvm_resume_frames would need to be renamed).

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 24 13:56:17 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Sep 2012 13:56: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 1TG98j-0001VE-Pp; Mon, 24 Sep 2012 13:56: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 1TG98i-0001V6-CB
	for Xen-devel@lists.xensource.com; Mon, 24 Sep 2012 13:56:00 +0000
Received: from [85.158.143.99:55938] by server-2.bemta-4.messagelabs.com id
	2E/94-06610-F6660605; Mon, 24 Sep 2012 13:55:59 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1348494958!23367584!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTA4NDk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7645 invoked from network); 24 Sep 2012 13:55:58 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Sep 2012 13:55:58 -0000
X-IronPort-AV: E=Sophos;i="4.80,476,1344211200"; d="scan'208";a="14725651"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Sep 2012 13:55: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.279.1; Mon, 24 Sep 2012 14:55:58 +0100
Date: Mon, 24 Sep 2012 14:55:06 +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: <20120921121928.1c5765bc@mantra.us.oracle.com>
Message-ID: <alpine.DEB.2.02.1209241423450.29232@kaball.uk.xensource.com>
References: <20120921121928.1c5765bc@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>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH v1 6/8]: PVH ballooning and grant changes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 21 Sep 2012, Mukesh Rathor wrote:
> ---
>  drivers/xen/balloon.c     |   35 ++++++++++++++++++++++++++++-------
>  drivers/xen/gntdev.c      |    3 ++-
>  drivers/xen/grant-table.c |   25 +++++++++++++++++++++----
>  3 files changed, 51 insertions(+), 12 deletions(-)
> 
> diff --git a/drivers/xen/balloon.c b/drivers/xen/balloon.c
> index 31ab82f..85a6917 100644
> --- a/drivers/xen/balloon.c
> +++ b/drivers/xen/balloon.c
> @@ -358,10 +358,21 @@ static enum bp_state increase_reservation(unsigned long nr_pages)
>  		BUG_ON(!xen_feature(XENFEAT_auto_translated_physmap) &&
>  		       phys_to_machine_mapping_valid(pfn));
>  
> -		set_phys_to_machine(pfn, frame_list[i]);
> +		if (xen_pv_domain() && 
> +		    xen_feature(XENFEAT_auto_translated_physmap)) {
> +			/* PVH: we just need to update native page table */
> +			pte_t *ptep;
> +			unsigned int level;
> +			void *addr = __va(pfn << PAGE_SHIFT);
> +			ptep = lookup_address((unsigned long)addr, &level);
> +			set_pte(ptep, pfn_pte(pfn, PAGE_KERNEL));
> +		} else
> +			set_phys_to_machine(pfn, frame_list[i]);



>  		/* Link back into the page tables if not highmem. */
> -		if (xen_pv_domain() && !PageHighMem(page)) {
> +		if (xen_pv_domain() && !PageHighMem(page) && 
> +		    !xen_feature(XENFEAT_auto_translated_physmap)) {
> +
>  			int ret;
>  			ret = HYPERVISOR_update_va_mapping(
>  				(unsigned long)__va(pfn << PAGE_SHIFT),
> @@ -418,12 +429,21 @@ static enum bp_state decrease_reservation(unsigned long nr_pages, gfp_t gfp)
>  		scrub_page(page);
>  
>  		if (xen_pv_domain() && !PageHighMem(page)) {
> -			ret = HYPERVISOR_update_va_mapping(
> -				(unsigned long)__va(pfn << PAGE_SHIFT),
> -				__pte_ma(0), 0);
> -			BUG_ON(ret);
> +			if (xen_feature(XENFEAT_auto_translated_physmap)) {
> +				unsigned int level;
> +				pte_t *ptep;
> +				void *addr = __va(pfn << PAGE_SHIFT);
> +				ptep = lookup_address((unsigned long)addr, 
> +							&level);
> +				set_pte(ptep, __pte(0));
> +
> +			} else {
> +				ret = HYPERVISOR_update_va_mapping(
> +					(unsigned long)__va(pfn << PAGE_SHIFT),
> +					__pte_ma(0), 0);
> +				BUG_ON(ret);
> +			}
>  		}
> -
>  	}
>  
>  	/* Ensure that ballooned highmem pages don't have kmaps. */
> @@ -433,6 +453,7 @@ static enum bp_state decrease_reservation(unsigned long nr_pages, gfp_t gfp)
>  	/* No more mappings: invalidate P2M and add to balloon. */
>  	for (i = 0; i < nr_pages; i++) {
>  		pfn = mfn_to_pfn(frame_list[i]);
> +		/* PVH note: following will noop for auto translated */
>  		__set_phys_to_machine(pfn, INVALID_P2M_ENTRY);
>  		balloon_append(pfn_to_page(pfn));
>  	}

Maybe we need a function "update_mapping" internal to balloon.c that
would be set to HYPERVISOR_update_va_mapping for pv guests, set_pte for
pvh guests and nothing for pv on hvm guests.

Speaking of which, why do pvh guests need a set_pte while pv on hvm
guests don't? I would think that their behaviour should be the same
regarding ballooning.


> diff --git a/drivers/xen/gntdev.c b/drivers/xen/gntdev.c
> index 1ffd03b..35d1e3c 100644
> --- a/drivers/xen/gntdev.c
> +++ b/drivers/xen/gntdev.c
> @@ -802,7 +802,8 @@ static int __init gntdev_init(void)
>  	if (!xen_domain())
>  		return -ENODEV;
>  
> -	use_ptemod = xen_pv_domain();
> +	use_ptemod = xen_pv_domain() && 
> +		     !xen_feature(XENFEAT_auto_translated_physmap);
>  
>  	err = misc_register(&gntdev_miscdev);
>  	if (err != 0) {
> diff --git a/drivers/xen/grant-table.c b/drivers/xen/grant-table.c
> index 0bfc1ef..d831d52 100644
> --- a/drivers/xen/grant-table.c
> +++ b/drivers/xen/grant-table.c
> @@ -974,14 +974,19 @@ static void gnttab_unmap_frames_v2(void)
>  static int gnttab_map(unsigned int start_idx, unsigned int end_idx)
>  {
>  	struct gnttab_setup_table setup;
> -	unsigned long *frames;
> +	unsigned long *frames, start_gpfn;
>  	unsigned int nr_gframes = end_idx + 1;
>  	int rc;
>  
> -	if (xen_hvm_domain()) {
> +	if (xen_hvm_domain() || xen_feature(XENFEAT_auto_translated_physmap)) {
>  		struct xen_add_to_physmap xatp;
>  		unsigned int i = end_idx;
>  		rc = 0;
> +
> +		if (xen_hvm_domain())
> +			start_gpfn = xen_hvm_resume_frames >> PAGE_SHIFT;
> +		else
> +			start_gpfn = virt_to_pfn(gnttab_shared.addr);
>  		/*
>  		 * Loop backwards, so that the first hypercall has the largest
>  		 * index, ensuring that the table will grow only once.
> @@ -990,7 +995,7 @@ static int gnttab_map(unsigned int start_idx, unsigned int end_idx)
>  			xatp.domid = DOMID_SELF;
>  			xatp.idx = i;
>  			xatp.space = XENMAPSPACE_grant_table;
> -			xatp.gpfn = (xen_hvm_resume_frames >> PAGE_SHIFT) + i;
> +			xatp.gpfn = start_gpfn + i;
>  			rc = HYPERVISOR_memory_op(XENMEM_add_to_physmap, &xatp);
>  			if (rc != 0) {
>  				printk(KERN_WARNING
> @@ -1053,7 +1058,7 @@ static void gnttab_request_version(void)
>  	int rc;
>  	struct gnttab_set_version gsv;
>  
> -	if (xen_hvm_domain())
> +	if (xen_hvm_domain() || xen_feature(XENFEAT_auto_translated_physmap))
>  		gsv.version = 1;
>  	else
>  		gsv.version = 2;
> @@ -1081,12 +1086,24 @@ static void gnttab_request_version(void)
>  int gnttab_resume(void)
>  {
>  	unsigned int max_nr_gframes;
> +	char *kmsg="Failed to kmalloc pages for pv in hvm grant frames\n";
>  
>  	gnttab_request_version();
>  	max_nr_gframes = gnttab_max_grant_frames();
>  	if (max_nr_gframes < nr_grant_frames)
>  		return -ENOSYS;
>  
> +	/* PVH note: xen will free existing kmalloc'd mfn in 
> +	 * XENMEM_add_to_physmap */
> +	if (xen_pv_domain() && xen_feature(XENFEAT_auto_translated_physmap) && 
> +	    !gnttab_shared.addr) {
> +		gnttab_shared.addr =
> +			kmalloc(max_nr_gframes * PAGE_SIZE, GFP_KERNEL);
> +		if ( !gnttab_shared.addr ) {
> +			printk(KERN_WARNING "%s", kmsg);
> +			return -ENOMEM;
> +		}
> +	}

the way PVH guests use gnttab_shared.addr is very similar to the way PV
on HVM guests use xen_hvm_resume_frames, except that
xen_hvm_resume_frames is allocated using alloc_xen_mmio instead of
kmalloc.

I wonder if it would produce better code switching PV on HVM guests to
gnttab_shared.addr too (or PVH guests to xen_hvm_resume_frames, but then
xen_hvm_resume_frames would need to be renamed).

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 24 13:59:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Sep 2012 13:59:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TG9BO-0001h4-HG; Mon, 24 Sep 2012 13:58:46 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1TG9BN-0001gv-4X
	for xen-devel@lists.xensource.com; Mon, 24 Sep 2012 13:58:45 +0000
Received: from [85.158.143.99:52367] by server-2.bemta-4.messagelabs.com id
	04/09-06610-41760605; Mon, 24 Sep 2012 13:58:44 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1348495122!30644036!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzU5Njc1\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2969 invoked from network); 24 Sep 2012 13:58:43 -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; 24 Sep 2012 13:58:43 -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 q8ODwf60031566
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK)
	for <xen-devel@lists.xensource.com>; Mon, 24 Sep 2012 13:58:42 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
	q8ODweAr004086
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for <xen-devel@lists.xensource.com>; Mon, 24 Sep 2012 13:58:41 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
	q8ODwevL030874
	for <xen-devel@lists.xensource.com>; Mon, 24 Sep 2012 08:58:40 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 24 Sep 2012 06:58:40 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id E62FD4031C; Mon, 24 Sep 2012 09:47:28 -0400 (EDT)
Date: Mon, 24 Sep 2012 09:47:28 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: xen-devel@lists.xensource.com
Message-ID: <20120924134728.GB31618@phenom.dumpdata.com>
MIME-Version: 1.0
Content-Disposition: inline
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Subject: [Xen-devel] Patches for v3.7..
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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,

The merge window in all likehood is going to open next week (Monday, Oct 1st), and these
are the patches I've in my tree ready to go (some of them are actually in tip and
in Jens's tree). If you think I've missed some, please tell me what they are.

Andres Lagar-Cavilla (3):
      xen/privcmd: add PRIVCMD_MMAPBATCH_V2 ioctl
      xen/privcmd: Fix mmap batch ioctl error status copy back.
      xen/gndev: Xen backend support for paged out grant targets V4.

Attilio Rao (5):
      x86: Remove base argument from x86_init.paging.pagetable_setup_start
      x86: Rename pagetable_setup_start() to pagetable_init()
      x86: Move paging_init() call to x86_init.paging.pagetable_init()
      x86: xen: Cleanup and remove x86_init.paging.pagetable_setup_done()
      x86: Document x86_init.paging.pagetable_init()

Dan Carpenter (1):
      xen/privcmd: return -EFAULT on error

Daniel De Graaf (1):
      xen/sysfs: Use XENVER_guest_handle to query UUID

David Vrabel (1):
      xen/mm: return more precise error from xen_remap_domain_range()

Ian Campbell (1):
      xen: resynchronise grant table status codes with upstream

Jan Beulich (2):
      xen-pciback: support wild cards in slot specifications
      xen/vga: add the xen EFI video mode support

Konrad Rzeszutek Wilk (31):
      xen/perf: Define .glob for the different hypercalls.
      xen/blkback: Fix compile warning
      xen/p2m: Fix the comment describing the P2M tree.
      xen/x86: Use memblock_reserve for sensitive areas.
      xen/x86: Workaround 64-bit hypervisor and 32-bit initial domain.
      xen/swiotlb: Simplify the logic.
      xen/swiotlb: With more than 4GB on 64-bit, disable the native SWIOTLB.
      swiotlb: add the late swiotlb initialization function with iotlb memory
      xen/apic/xenbus/swiotlb/pcifront/grant/tmem: Make functions or variables static.
      xen/swiotlb: Remove functions not needed anymore.
      xen/swiotlb: Fix compile warnings when using plain integer instead of NULL pointer.
      Revert "xen/x86: Workaround 64-bit hypervisor and 32-bit initial domain." and "xen/x86: Use memblock_reserve for sensitive areas."
      xen/mmu: The xen_setup_kernel_pagetable doesn't need to return anything.
      xen/mmu: Provide comments describing the _ka and _va aliasing issue
      xen/mmu: use copy_page instead of memcpy.
      xen/mmu: For 64-bit do not call xen_map_identity_early
      xen/mmu: Recycle the Xen provided L4, L3, and L2 pages
      xen/p2m: Add logic to revector a P2M tree to use __va leafs.
      xen/mmu: Copy and revector the P2M tree.
      xen/mmu: Remove from __ka space PMD entries for pagetables.
      xen/mmu: Release just the MFN list, not MFN list and part of pagetables.
      xen/p2m: When revectoring deal with holes in the P2M array.
      xen/mmu: If the revector fails, don't attempt to revector anything else.
      xen/swiotlb: Move the nr_tbl determination in its own function.
      xen/swiotlb: Move the error strings to its own function.
      xen/swiotlb: Use the swiotlb_late_init_with_tbl to init Xen-SWIOTLB late when PV PCI is used.
      xen/swiotlb: For early initialization, return zero on success.
      xen/pcifront: Use Xen-SWIOTLB when initting if required.
      xen/swiotlb: Remove functions not needed anymore.
      xen/swiotlb: Fix compile warnings when using plain integer instead of NULL pointer.
      xen/x86: retrieve keyboard shift status flags from hypervisor.

Oliver Chick (1):
      xen/blkback: Change xen_vbd's flush_support and discard_secure to have type unsigned int, rather than bool

Stefano Stabellini (7):
      xen: update xen_add_to_physmap interface
      xen: missing includes
      xen/events: fix unmask_evtchn for PV on HVM guests
      xen: clear IRQ_NOAUTOEN and IRQ_NOREQUEST
      xen: Introduce xen_pfn_t for pfn and mfn types
      xen: allow privcmd for HVM guests
      xen/arm: compile and run xenbus

Wei Yongjun (1):
      xen/blkback: use kmem_cache_zalloc instead of kmem_cache_alloc/memset


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 24 13:59:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Sep 2012 13:59:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TG9BO-0001h4-HG; Mon, 24 Sep 2012 13:58:46 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1TG9BN-0001gv-4X
	for xen-devel@lists.xensource.com; Mon, 24 Sep 2012 13:58:45 +0000
Received: from [85.158.143.99:52367] by server-2.bemta-4.messagelabs.com id
	04/09-06610-41760605; Mon, 24 Sep 2012 13:58:44 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1348495122!30644036!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzU5Njc1\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2969 invoked from network); 24 Sep 2012 13:58:43 -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; 24 Sep 2012 13:58:43 -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 q8ODwf60031566
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK)
	for <xen-devel@lists.xensource.com>; Mon, 24 Sep 2012 13:58:42 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
	q8ODweAr004086
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for <xen-devel@lists.xensource.com>; Mon, 24 Sep 2012 13:58:41 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
	q8ODwevL030874
	for <xen-devel@lists.xensource.com>; Mon, 24 Sep 2012 08:58:40 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 24 Sep 2012 06:58:40 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id E62FD4031C; Mon, 24 Sep 2012 09:47:28 -0400 (EDT)
Date: Mon, 24 Sep 2012 09:47:28 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: xen-devel@lists.xensource.com
Message-ID: <20120924134728.GB31618@phenom.dumpdata.com>
MIME-Version: 1.0
Content-Disposition: inline
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Subject: [Xen-devel] Patches for v3.7..
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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,

The merge window in all likehood is going to open next week (Monday, Oct 1st), and these
are the patches I've in my tree ready to go (some of them are actually in tip and
in Jens's tree). If you think I've missed some, please tell me what they are.

Andres Lagar-Cavilla (3):
      xen/privcmd: add PRIVCMD_MMAPBATCH_V2 ioctl
      xen/privcmd: Fix mmap batch ioctl error status copy back.
      xen/gndev: Xen backend support for paged out grant targets V4.

Attilio Rao (5):
      x86: Remove base argument from x86_init.paging.pagetable_setup_start
      x86: Rename pagetable_setup_start() to pagetable_init()
      x86: Move paging_init() call to x86_init.paging.pagetable_init()
      x86: xen: Cleanup and remove x86_init.paging.pagetable_setup_done()
      x86: Document x86_init.paging.pagetable_init()

Dan Carpenter (1):
      xen/privcmd: return -EFAULT on error

Daniel De Graaf (1):
      xen/sysfs: Use XENVER_guest_handle to query UUID

David Vrabel (1):
      xen/mm: return more precise error from xen_remap_domain_range()

Ian Campbell (1):
      xen: resynchronise grant table status codes with upstream

Jan Beulich (2):
      xen-pciback: support wild cards in slot specifications
      xen/vga: add the xen EFI video mode support

Konrad Rzeszutek Wilk (31):
      xen/perf: Define .glob for the different hypercalls.
      xen/blkback: Fix compile warning
      xen/p2m: Fix the comment describing the P2M tree.
      xen/x86: Use memblock_reserve for sensitive areas.
      xen/x86: Workaround 64-bit hypervisor and 32-bit initial domain.
      xen/swiotlb: Simplify the logic.
      xen/swiotlb: With more than 4GB on 64-bit, disable the native SWIOTLB.
      swiotlb: add the late swiotlb initialization function with iotlb memory
      xen/apic/xenbus/swiotlb/pcifront/grant/tmem: Make functions or variables static.
      xen/swiotlb: Remove functions not needed anymore.
      xen/swiotlb: Fix compile warnings when using plain integer instead of NULL pointer.
      Revert "xen/x86: Workaround 64-bit hypervisor and 32-bit initial domain." and "xen/x86: Use memblock_reserve for sensitive areas."
      xen/mmu: The xen_setup_kernel_pagetable doesn't need to return anything.
      xen/mmu: Provide comments describing the _ka and _va aliasing issue
      xen/mmu: use copy_page instead of memcpy.
      xen/mmu: For 64-bit do not call xen_map_identity_early
      xen/mmu: Recycle the Xen provided L4, L3, and L2 pages
      xen/p2m: Add logic to revector a P2M tree to use __va leafs.
      xen/mmu: Copy and revector the P2M tree.
      xen/mmu: Remove from __ka space PMD entries for pagetables.
      xen/mmu: Release just the MFN list, not MFN list and part of pagetables.
      xen/p2m: When revectoring deal with holes in the P2M array.
      xen/mmu: If the revector fails, don't attempt to revector anything else.
      xen/swiotlb: Move the nr_tbl determination in its own function.
      xen/swiotlb: Move the error strings to its own function.
      xen/swiotlb: Use the swiotlb_late_init_with_tbl to init Xen-SWIOTLB late when PV PCI is used.
      xen/swiotlb: For early initialization, return zero on success.
      xen/pcifront: Use Xen-SWIOTLB when initting if required.
      xen/swiotlb: Remove functions not needed anymore.
      xen/swiotlb: Fix compile warnings when using plain integer instead of NULL pointer.
      xen/x86: retrieve keyboard shift status flags from hypervisor.

Oliver Chick (1):
      xen/blkback: Change xen_vbd's flush_support and discard_secure to have type unsigned int, rather than bool

Stefano Stabellini (7):
      xen: update xen_add_to_physmap interface
      xen: missing includes
      xen/events: fix unmask_evtchn for PV on HVM guests
      xen: clear IRQ_NOAUTOEN and IRQ_NOREQUEST
      xen: Introduce xen_pfn_t for pfn and mfn types
      xen: allow privcmd for HVM guests
      xen/arm: compile and run xenbus

Wei Yongjun (1):
      xen/blkback: use kmem_cache_zalloc instead of kmem_cache_alloc/memset


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 24 14:02:11 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Sep 2012 14:02:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TG9EW-0001wI-4R; Mon, 24 Sep 2012 14:02:00 +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 1TG9ET-0001vt-W0
	for Xen-devel@lists.xensource.com; Mon, 24 Sep 2012 14:01:58 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1348495310!6072706!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzU5Njc1\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14185 invoked from network); 24 Sep 2012 14:01:51 -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; 24 Sep 2012 14:01: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 q8OE1idE003384
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 24 Sep 2012 14:01:45 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q8OE1h1e004789
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 24 Sep 2012 14:01:44 GMT
Received: from abhmt109.oracle.com (abhmt109.oracle.com [141.146.116.61])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q8OE1hcl003531; Mon, 24 Sep 2012 09:01:43 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 24 Sep 2012 07:01:43 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 5D9E34031C; Mon, 24 Sep 2012 09:50:31 -0400 (EDT)
Date: Mon, 24 Sep 2012 09:50:31 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20120924135031.GD31618@phenom.dumpdata.com>
References: <20120921121556.1a0ea8af@mantra.us.oracle.com>
	<alpine.DEB.2.02.1209241228460.29232@kaball.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <alpine.DEB.2.02.1209241228460.29232@kaball.uk.xensource.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: "Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH v1 2/8]: PVH mmu changes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Sep 24, 2012 at 12:55:31PM +0100, Stefano Stabellini wrote:
> There are few code style issues on this patch, I suggest you run it
> through scripts/checkpatch.pl, it should be able to catch all these
> errors.
> 
> On Fri, 21 Sep 2012, Mukesh Rathor wrote:
> > ---
> >  arch/x86/xen/mmu.c    |  180 +++++++++++++++++++++++++++++++++++++++++++++++--
> >  arch/x86/xen/mmu.h    |    2 +
> >  include/xen/xen-ops.h |   12 +++-
> >  3 files changed, 188 insertions(+), 6 deletions(-)
> > 
> > diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c
> > index b65a761..9b5a5ef 100644
> > --- a/arch/x86/xen/mmu.c
> > +++ b/arch/x86/xen/mmu.c
> > @@ -73,6 +73,7 @@
> >  #include <xen/interface/version.h>
> >  #include <xen/interface/memory.h>
> >  #include <xen/hvc-console.h>
> > +#include <xen/balloon.h>
> >  
> >  #include "multicalls.h"
> >  #include "mmu.h"
> > @@ -330,6 +331,26 @@ static void xen_set_pte(pte_t *ptep, pte_t pteval)
> >  	__xen_set_pte(ptep, pteval);
> >  }
> >  
> > +void xen_set_clr_mmio_pvh_pte(unsigned long pfn, unsigned long mfn, 
> > +			      int nr_mfns, int add_mapping)
> > +{
> > +	struct physdev_map_iomem iomem;
> > +
> > +	iomem.first_gfn = pfn;
> > +	iomem.first_mfn = mfn;
> > +	iomem.nr_mfns = nr_mfns;
> > +	iomem.add_mapping = add_mapping;
> > +
> > +	if (HYPERVISOR_physdev_op(PHYSDEVOP_pvh_map_iomem, &iomem))
> > +		BUG();
> > +}
> > +
> > +static void xen_dom0pvh_set_pte_at(struct mm_struct *mm, unsigned long addr,
> > +		    		   pte_t *ptep, pte_t pteval)
> > +{
> > +	native_set_pte(ptep, pteval);
> > +}
> 
> can't you just set set_pte_at to native_set_pte?
> 
> 
> >  static void xen_set_pte_at(struct mm_struct *mm, unsigned long addr,
> >  		    pte_t *ptep, pte_t pteval)
> >  {
> > @@ -1197,6 +1218,10 @@ static void xen_post_allocator_init(void);
> >  static void __init xen_pagetable_setup_done(pgd_t *base)
> >  {
> >  	xen_setup_shared_info();
> > +
> > +	if (xen_feature(XENFEAT_auto_translated_physmap))
> > +		return;
> > +
> >  	xen_post_allocator_init();
> >  }
> 
> Can we move the if..return at the beginning of xen_post_allocator_init?
> It would make it easier to understand what it is for.
> Or maybe we could have xen_setup_shared_info take a pgd_t *base
> parameter so that you can set pagetable_setup_done to
> xen_setup_shared_info directly on pvh.

It actually ends up nicely aligning with my patches since I end up
using 'if (xen_feature(..)'. But you can't see that since these patches
are not rebased on that - which is OK.

> 
> 
> > @@ -1455,6 +1480,10 @@ static void __init xen_set_pte_init(pte_t *ptep, pte_t pte)
> >  static void pin_pagetable_pfn(unsigned cmd, unsigned long pfn)
> >  {
> >  	struct mmuext_op op;
> > +
> > +	if (xen_feature(XENFEAT_writable_page_tables))
> > +		return;
> > +
> >  	op.cmd = cmd;
> >  	op.arg1.mfn = pfn_to_mfn(pfn);
> >  	if (HYPERVISOR_mmuext_op(&op, 1, NULL, DOMID_SELF))
> 
> given the very limited set of mmu pvops that we initialize on pvh, I
> cannot find who would actually call pin_pagetable_pfn on pvh.
> 
> 
> > @@ -1652,6 +1681,10 @@ static void set_page_prot(void *addr, pgprot_t prot)
> >  	unsigned long pfn = __pa(addr) >> PAGE_SHIFT;
> >  	pte_t pte = pfn_pte(pfn, prot);
> >  
> > +	/* recall for PVH, page tables are native. */
> > +	if (xen_feature(XENFEAT_auto_translated_physmap))
> > +		return;
> > +
> >  	if (HYPERVISOR_update_va_mapping((unsigned long)addr, pte, 0))
> >  		BUG();
> >  }
> > @@ -1729,6 +1762,9 @@ static void convert_pfn_mfn(void *v)
> >  	pte_t *pte = v;
> >  	int i;
> >  
> > +	if (xen_feature(XENFEAT_auto_translated_physmap))
> > +		return;
> > +
> >  	/* All levels are converted the same way, so just treat them
> >  	   as ptes. */
> >  	for (i = 0; i < PTRS_PER_PTE; i++)
> > @@ -1745,6 +1781,7 @@ static void convert_pfn_mfn(void *v)
> >   * but that's enough to get __va working.  We need to fill in the rest
> >   * of the physical mapping once some sort of allocator has been set
> >   * up.
> > + * NOTE: for PVH, the page tables are native.
> >   */
> >  pgd_t * __init xen_setup_kernel_pagetable(pgd_t *pgd,
> >  					 unsigned long max_pfn)
> > @@ -1802,9 +1839,13 @@ pgd_t * __init xen_setup_kernel_pagetable(pgd_t *pgd,
> >  	 * structure to attach it to, so make sure we just set kernel
> >  	 * pgd.
> >  	 */
> > -	xen_mc_batch();
> > -	__xen_write_cr3(true, __pa(pgd));
> > -	xen_mc_issue(PARAVIRT_LAZY_CPU);
> > +	if (xen_feature(XENFEAT_writable_page_tables)) {
> > +		native_write_cr3(__pa(pgd));
> > +	} else {
> > +		xen_mc_batch();
> > +		__xen_write_cr3(true, __pa(pgd));
> > +		xen_mc_issue(PARAVIRT_LAZY_CPU);
> > +	}
> >  
> >  	memblock_reserve(__pa(xen_start_info->pt_base),
> >  			 xen_start_info->nr_pt_frames * PAGE_SIZE);
> > @@ -2067,9 +2108,21 @@ static const struct pv_mmu_ops xen_mmu_ops __initconst = {
> >  
> >  void __init xen_init_mmu_ops(void)
> >  {
> > +	x86_init.paging.pagetable_setup_done = xen_pagetable_setup_done;
> > +
> > +	if (xen_feature(XENFEAT_auto_translated_physmap)) {
> > +		pv_mmu_ops.flush_tlb_others = xen_flush_tlb_others;
> > +
> > +		/* set_pte* for PCI devices to map iomem. */
> > +		if (xen_initial_domain()) {
> > +			pv_mmu_ops.set_pte = native_set_pte;
> > +			pv_mmu_ops.set_pte_at = xen_dom0pvh_set_pte_at;
> > +		}
> > +		return;
> > +	}
> > +
> >  	x86_init.mapping.pagetable_reserve = xen_mapping_pagetable_reserve;
> >  	x86_init.paging.pagetable_setup_start = xen_pagetable_setup_start;
> > -	x86_init.paging.pagetable_setup_done = xen_pagetable_setup_done;
> >  	pv_mmu_ops = xen_mmu_ops;
> >  
> >  	memset(dummy_mapping, 0xff, PAGE_SIZE);
> 
> I wonder whether it would make sense to have a xen_pvh_init_mmu_ops,
> given that they end up being so different...
> 
> 
> > @@ -2305,6 +2358,92 @@ void __init xen_hvm_init_mmu_ops(void)
> >  }
> >  #endif
> >  
> > +/* Map foreign gmfn, fgmfn, to local pfn, lpfn. This for the user space 
> > + * creating new guest on PVH dom0 and needs to map domU pages. 
> > + */
> > +static int pvh_add_to_xen_p2m(unsigned long lpfn, unsigned long fgmfn,
> > +			      unsigned int domid)
> > +{
> > +	int rc;
> > +	struct xen_add_to_physmap xatp = { .u.foreign_domid = domid };
> > +
> > +	xatp.gpfn = lpfn;
> > +	xatp.idx = fgmfn;
> > +	xatp.domid = DOMID_SELF;
> > +	xatp.space = XENMAPSPACE_gmfn_foreign;
> > +	rc = HYPERVISOR_memory_op(XENMEM_add_to_physmap, &xatp);
> > +	if (rc)
> > +		pr_warn("d0: Failed to map pfn to mfn rc:%d pfn:%lx mfn:%lx\n", 
> > +			rc, lpfn, fgmfn); 
> > +	return rc;
> > +}
> > +
> > +int pvh_rem_xen_p2m(unsigned long spfn, int count)
> > +{
> > +	struct xen_remove_from_physmap xrp;
> > +	int i, rc;
> > +
> > +	for (i=0; i < count; i++) {
> > +		xrp.domid = DOMID_SELF;
> > +		xrp.gpfn = spfn+i;
> > +		rc = HYPERVISOR_memory_op(XENMEM_remove_from_physmap, &xrp);
> > +		if (rc) {
> > +			pr_warn("Failed to unmap pfn:%lx rc:%d done:%d\n",
> > +				spfn+i, rc, i);
> > +			return 1;
> > +		}
> > +	}
> > +	return 0;
> > +}
> > +EXPORT_SYMBOL_GPL(pvh_rem_xen_p2m);
> > +
> > +struct pvh_remap_data {
> > +	unsigned long fgmfn;		/* foreign domain's gmfn */
> > +	pgprot_t prot;
> > +	domid_t  domid;
> > +	struct xen_pvh_pfn_info *pvhinfop;
> > +};
> > +
> > +static int pvh_map_pte_fn(pte_t *ptep, pgtable_t token, unsigned long addr, 
> > +			void *data)
> > +{
> > +	int rc;
> > +	struct pvh_remap_data *remapp = data;
> > +	struct xen_pvh_pfn_info *pvhp = remapp->pvhinfop;
> > +	unsigned long pfn = page_to_pfn(pvhp->pi_paga[pvhp->pi_next_todo++]);
> > +	pte_t pteval = pte_mkspecial(pfn_pte(pfn, remapp->prot));
> > +
> > +	if ((rc=pvh_add_to_xen_p2m(pfn, remapp->fgmfn, remapp->domid)))
> > +		return rc;
> > +	native_set_pte(ptep, pteval);
> 
> Do we actually need the pte to be "special"?
> I would think that being in the guest p2m, it is actually quite a normal
> page.
> 
> 
> > +	return 0;
> > +}
> > +
> > +/* The only caller at moment passes one gmfn at a time.
> > + * PVH TBD/FIXME: expand this in future to honor batch requests.
> > + */
> > +static int pvh_remap_gmfn_range(struct vm_area_struct *vma,
> > +				unsigned long addr, unsigned long mfn, int nr,
> > +				pgprot_t prot, unsigned domid,
> > +				struct xen_pvh_pfn_info *pvhp)
> > +{
> > +	int err;
> > +	struct pvh_remap_data pvhdata;
> > +
> > +	if (nr > 1)
> > +		return -EINVAL;
> > +
> > +	pvhdata.fgmfn = mfn;
> > +	pvhdata.prot = prot;
> > +	pvhdata.domid = domid;
> > +	pvhdata.pvhinfop = pvhp;
> > +	err = apply_to_page_range(vma->vm_mm, addr, nr << PAGE_SHIFT,
> > +				  pvh_map_pte_fn, &pvhdata);
> > +	flush_tlb_all();
> 
> Maybe we can use one of the flush_tlb_range varieties instead of a
> flush_tlb_all?
> 
> 
> > +	return err;
> > +}
> > +
> >  #define REMAP_BATCH_SIZE 16
> >  
> >  struct remap_data {
> > @@ -2329,7 +2468,9 @@ static int remap_area_mfn_pte_fn(pte_t *ptep, pgtable_t token,
> >  int xen_remap_domain_mfn_range(struct vm_area_struct *vma,
> >  			       unsigned long addr,
> >  			       unsigned long mfn, int nr,
> > -			       pgprot_t prot, unsigned domid)
> > +			       pgprot_t prot, unsigned domid,
> > +			       struct xen_pvh_pfn_info *pvhp)
> > +
> >  {
> >  	struct remap_data rmd;
> >  	struct mmu_update mmu_update[REMAP_BATCH_SIZE];
> > @@ -2342,6 +2483,12 @@ int xen_remap_domain_mfn_range(struct vm_area_struct *vma,
> >  	BUG_ON(!((vma->vm_flags & (VM_PFNMAP | VM_RESERVED | VM_IO)) ==
> >  				(VM_PFNMAP | VM_RESERVED | VM_IO)));
> >  
> > +	if (xen_feature(XENFEAT_auto_translated_physmap)) {
> > +		/* We need to update the local page tables and the xen HAP */
> > +		return pvh_remap_gmfn_range(vma, addr, mfn, nr, prot, domid,
> > +					    pvhp);
> > +	}
> > +
> >  	rmd.mfn = mfn;
> >  	rmd.prot = prot;
> >  
> > @@ -2371,3 +2518,26 @@ out:
> >  	return err;
> >  }
> >  EXPORT_SYMBOL_GPL(xen_remap_domain_mfn_range);
> > +
> > +/* Returns: Number of pages unmapped */
> > +int xen_unmap_domain_mfn_range(struct vm_area_struct *vma,
> > +			       struct xen_pvh_pfn_info *pvhp)
> > +{
> > +	int count = 0;
> > +
> > +	if (!pvhp || !xen_feature(XENFEAT_auto_translated_physmap))
> > +		return 0;
> > +
> > +	while (pvhp->pi_next_todo--) {
> > +		unsigned long pfn;
> > +
> > +		/* the mmu has already cleaned up the process mmu resources at
> > +		 * this point (lookup_address will return NULL). */
> > +		pfn = page_to_pfn(pvhp->pi_paga[pvhp->pi_next_todo]);
> > +		pvh_rem_xen_p2m(pfn, 1);
> > +		count++;
> > +	}
> > +	flush_tlb_all();
> > +	return count;
> 
> Who is going to remove the corresponding mapping from the vma?
> Also we might be able to replace the flush_tlb_all with a
> flush_tlb_range.
> 
> 
> > +EXPORT_SYMBOL_GPL(xen_unmap_domain_mfn_range);
> > diff --git a/arch/x86/xen/mmu.h b/arch/x86/xen/mmu.h
> > index 73809bb..6d0bb56 100644
> > --- a/arch/x86/xen/mmu.h
> > +++ b/arch/x86/xen/mmu.h
> > @@ -23,4 +23,6 @@ unsigned long xen_read_cr2_direct(void);
> >  
> >  extern void xen_init_mmu_ops(void);
> >  extern void xen_hvm_init_mmu_ops(void);
> > +extern void xen_set_clr_mmio_pvh_pte(unsigned long pfn, unsigned long mfn,
> > +				     int nr_mfns, int add_mapping);
> >  #endif	/* _XEN_MMU_H */
> > diff --git a/include/xen/xen-ops.h b/include/xen/xen-ops.h
> > index 6a198e4..6c5ad83 100644
> > --- a/include/xen/xen-ops.h
> > +++ b/include/xen/xen-ops.h
> > @@ -24,9 +24,19 @@ int xen_create_contiguous_region(unsigned long vstart, unsigned int order,
> >  void xen_destroy_contiguous_region(unsigned long vstart, unsigned int order);
> >  
> >  struct vm_area_struct;
> > +struct xen_pvh_pfn_info;
> >  int xen_remap_domain_mfn_range(struct vm_area_struct *vma,
> >  			       unsigned long addr,
> >  			       unsigned long mfn, int nr,
> > -			       pgprot_t prot, unsigned domid);
> > +			       pgprot_t prot, unsigned domid,
> > +			       struct xen_pvh_pfn_info *pvhp);
> > +int xen_unmap_domain_mfn_range(struct vm_area_struct *vma,
> > +			       struct xen_pvh_pfn_info *pvhp);
> > +
> > +struct xen_pvh_pfn_info {
> > +	struct page **pi_paga;		/* pfn info page array */
> > +	int 	      pi_num_pgs;
> > +	int 	      pi_next_todo;
> > +};
> >  
> >  #endif /* INCLUDE_XEN_OPS_H */
> > -- 
> > 1.7.2.3
> > 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 24 14:02:11 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Sep 2012 14:02:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TG9EW-0001wI-4R; Mon, 24 Sep 2012 14:02:00 +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 1TG9ET-0001vt-W0
	for Xen-devel@lists.xensource.com; Mon, 24 Sep 2012 14:01:58 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1348495310!6072706!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzU5Njc1\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14185 invoked from network); 24 Sep 2012 14:01:51 -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; 24 Sep 2012 14:01: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 q8OE1idE003384
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 24 Sep 2012 14:01:45 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q8OE1h1e004789
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 24 Sep 2012 14:01:44 GMT
Received: from abhmt109.oracle.com (abhmt109.oracle.com [141.146.116.61])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q8OE1hcl003531; Mon, 24 Sep 2012 09:01:43 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 24 Sep 2012 07:01:43 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 5D9E34031C; Mon, 24 Sep 2012 09:50:31 -0400 (EDT)
Date: Mon, 24 Sep 2012 09:50:31 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20120924135031.GD31618@phenom.dumpdata.com>
References: <20120921121556.1a0ea8af@mantra.us.oracle.com>
	<alpine.DEB.2.02.1209241228460.29232@kaball.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <alpine.DEB.2.02.1209241228460.29232@kaball.uk.xensource.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: "Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH v1 2/8]: PVH mmu changes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Sep 24, 2012 at 12:55:31PM +0100, Stefano Stabellini wrote:
> There are few code style issues on this patch, I suggest you run it
> through scripts/checkpatch.pl, it should be able to catch all these
> errors.
> 
> On Fri, 21 Sep 2012, Mukesh Rathor wrote:
> > ---
> >  arch/x86/xen/mmu.c    |  180 +++++++++++++++++++++++++++++++++++++++++++++++--
> >  arch/x86/xen/mmu.h    |    2 +
> >  include/xen/xen-ops.h |   12 +++-
> >  3 files changed, 188 insertions(+), 6 deletions(-)
> > 
> > diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c
> > index b65a761..9b5a5ef 100644
> > --- a/arch/x86/xen/mmu.c
> > +++ b/arch/x86/xen/mmu.c
> > @@ -73,6 +73,7 @@
> >  #include <xen/interface/version.h>
> >  #include <xen/interface/memory.h>
> >  #include <xen/hvc-console.h>
> > +#include <xen/balloon.h>
> >  
> >  #include "multicalls.h"
> >  #include "mmu.h"
> > @@ -330,6 +331,26 @@ static void xen_set_pte(pte_t *ptep, pte_t pteval)
> >  	__xen_set_pte(ptep, pteval);
> >  }
> >  
> > +void xen_set_clr_mmio_pvh_pte(unsigned long pfn, unsigned long mfn, 
> > +			      int nr_mfns, int add_mapping)
> > +{
> > +	struct physdev_map_iomem iomem;
> > +
> > +	iomem.first_gfn = pfn;
> > +	iomem.first_mfn = mfn;
> > +	iomem.nr_mfns = nr_mfns;
> > +	iomem.add_mapping = add_mapping;
> > +
> > +	if (HYPERVISOR_physdev_op(PHYSDEVOP_pvh_map_iomem, &iomem))
> > +		BUG();
> > +}
> > +
> > +static void xen_dom0pvh_set_pte_at(struct mm_struct *mm, unsigned long addr,
> > +		    		   pte_t *ptep, pte_t pteval)
> > +{
> > +	native_set_pte(ptep, pteval);
> > +}
> 
> can't you just set set_pte_at to native_set_pte?
> 
> 
> >  static void xen_set_pte_at(struct mm_struct *mm, unsigned long addr,
> >  		    pte_t *ptep, pte_t pteval)
> >  {
> > @@ -1197,6 +1218,10 @@ static void xen_post_allocator_init(void);
> >  static void __init xen_pagetable_setup_done(pgd_t *base)
> >  {
> >  	xen_setup_shared_info();
> > +
> > +	if (xen_feature(XENFEAT_auto_translated_physmap))
> > +		return;
> > +
> >  	xen_post_allocator_init();
> >  }
> 
> Can we move the if..return at the beginning of xen_post_allocator_init?
> It would make it easier to understand what it is for.
> Or maybe we could have xen_setup_shared_info take a pgd_t *base
> parameter so that you can set pagetable_setup_done to
> xen_setup_shared_info directly on pvh.

It actually ends up nicely aligning with my patches since I end up
using 'if (xen_feature(..)'. But you can't see that since these patches
are not rebased on that - which is OK.

> 
> 
> > @@ -1455,6 +1480,10 @@ static void __init xen_set_pte_init(pte_t *ptep, pte_t pte)
> >  static void pin_pagetable_pfn(unsigned cmd, unsigned long pfn)
> >  {
> >  	struct mmuext_op op;
> > +
> > +	if (xen_feature(XENFEAT_writable_page_tables))
> > +		return;
> > +
> >  	op.cmd = cmd;
> >  	op.arg1.mfn = pfn_to_mfn(pfn);
> >  	if (HYPERVISOR_mmuext_op(&op, 1, NULL, DOMID_SELF))
> 
> given the very limited set of mmu pvops that we initialize on pvh, I
> cannot find who would actually call pin_pagetable_pfn on pvh.
> 
> 
> > @@ -1652,6 +1681,10 @@ static void set_page_prot(void *addr, pgprot_t prot)
> >  	unsigned long pfn = __pa(addr) >> PAGE_SHIFT;
> >  	pte_t pte = pfn_pte(pfn, prot);
> >  
> > +	/* recall for PVH, page tables are native. */
> > +	if (xen_feature(XENFEAT_auto_translated_physmap))
> > +		return;
> > +
> >  	if (HYPERVISOR_update_va_mapping((unsigned long)addr, pte, 0))
> >  		BUG();
> >  }
> > @@ -1729,6 +1762,9 @@ static void convert_pfn_mfn(void *v)
> >  	pte_t *pte = v;
> >  	int i;
> >  
> > +	if (xen_feature(XENFEAT_auto_translated_physmap))
> > +		return;
> > +
> >  	/* All levels are converted the same way, so just treat them
> >  	   as ptes. */
> >  	for (i = 0; i < PTRS_PER_PTE; i++)
> > @@ -1745,6 +1781,7 @@ static void convert_pfn_mfn(void *v)
> >   * but that's enough to get __va working.  We need to fill in the rest
> >   * of the physical mapping once some sort of allocator has been set
> >   * up.
> > + * NOTE: for PVH, the page tables are native.
> >   */
> >  pgd_t * __init xen_setup_kernel_pagetable(pgd_t *pgd,
> >  					 unsigned long max_pfn)
> > @@ -1802,9 +1839,13 @@ pgd_t * __init xen_setup_kernel_pagetable(pgd_t *pgd,
> >  	 * structure to attach it to, so make sure we just set kernel
> >  	 * pgd.
> >  	 */
> > -	xen_mc_batch();
> > -	__xen_write_cr3(true, __pa(pgd));
> > -	xen_mc_issue(PARAVIRT_LAZY_CPU);
> > +	if (xen_feature(XENFEAT_writable_page_tables)) {
> > +		native_write_cr3(__pa(pgd));
> > +	} else {
> > +		xen_mc_batch();
> > +		__xen_write_cr3(true, __pa(pgd));
> > +		xen_mc_issue(PARAVIRT_LAZY_CPU);
> > +	}
> >  
> >  	memblock_reserve(__pa(xen_start_info->pt_base),
> >  			 xen_start_info->nr_pt_frames * PAGE_SIZE);
> > @@ -2067,9 +2108,21 @@ static const struct pv_mmu_ops xen_mmu_ops __initconst = {
> >  
> >  void __init xen_init_mmu_ops(void)
> >  {
> > +	x86_init.paging.pagetable_setup_done = xen_pagetable_setup_done;
> > +
> > +	if (xen_feature(XENFEAT_auto_translated_physmap)) {
> > +		pv_mmu_ops.flush_tlb_others = xen_flush_tlb_others;
> > +
> > +		/* set_pte* for PCI devices to map iomem. */
> > +		if (xen_initial_domain()) {
> > +			pv_mmu_ops.set_pte = native_set_pte;
> > +			pv_mmu_ops.set_pte_at = xen_dom0pvh_set_pte_at;
> > +		}
> > +		return;
> > +	}
> > +
> >  	x86_init.mapping.pagetable_reserve = xen_mapping_pagetable_reserve;
> >  	x86_init.paging.pagetable_setup_start = xen_pagetable_setup_start;
> > -	x86_init.paging.pagetable_setup_done = xen_pagetable_setup_done;
> >  	pv_mmu_ops = xen_mmu_ops;
> >  
> >  	memset(dummy_mapping, 0xff, PAGE_SIZE);
> 
> I wonder whether it would make sense to have a xen_pvh_init_mmu_ops,
> given that they end up being so different...
> 
> 
> > @@ -2305,6 +2358,92 @@ void __init xen_hvm_init_mmu_ops(void)
> >  }
> >  #endif
> >  
> > +/* Map foreign gmfn, fgmfn, to local pfn, lpfn. This for the user space 
> > + * creating new guest on PVH dom0 and needs to map domU pages. 
> > + */
> > +static int pvh_add_to_xen_p2m(unsigned long lpfn, unsigned long fgmfn,
> > +			      unsigned int domid)
> > +{
> > +	int rc;
> > +	struct xen_add_to_physmap xatp = { .u.foreign_domid = domid };
> > +
> > +	xatp.gpfn = lpfn;
> > +	xatp.idx = fgmfn;
> > +	xatp.domid = DOMID_SELF;
> > +	xatp.space = XENMAPSPACE_gmfn_foreign;
> > +	rc = HYPERVISOR_memory_op(XENMEM_add_to_physmap, &xatp);
> > +	if (rc)
> > +		pr_warn("d0: Failed to map pfn to mfn rc:%d pfn:%lx mfn:%lx\n", 
> > +			rc, lpfn, fgmfn); 
> > +	return rc;
> > +}
> > +
> > +int pvh_rem_xen_p2m(unsigned long spfn, int count)
> > +{
> > +	struct xen_remove_from_physmap xrp;
> > +	int i, rc;
> > +
> > +	for (i=0; i < count; i++) {
> > +		xrp.domid = DOMID_SELF;
> > +		xrp.gpfn = spfn+i;
> > +		rc = HYPERVISOR_memory_op(XENMEM_remove_from_physmap, &xrp);
> > +		if (rc) {
> > +			pr_warn("Failed to unmap pfn:%lx rc:%d done:%d\n",
> > +				spfn+i, rc, i);
> > +			return 1;
> > +		}
> > +	}
> > +	return 0;
> > +}
> > +EXPORT_SYMBOL_GPL(pvh_rem_xen_p2m);
> > +
> > +struct pvh_remap_data {
> > +	unsigned long fgmfn;		/* foreign domain's gmfn */
> > +	pgprot_t prot;
> > +	domid_t  domid;
> > +	struct xen_pvh_pfn_info *pvhinfop;
> > +};
> > +
> > +static int pvh_map_pte_fn(pte_t *ptep, pgtable_t token, unsigned long addr, 
> > +			void *data)
> > +{
> > +	int rc;
> > +	struct pvh_remap_data *remapp = data;
> > +	struct xen_pvh_pfn_info *pvhp = remapp->pvhinfop;
> > +	unsigned long pfn = page_to_pfn(pvhp->pi_paga[pvhp->pi_next_todo++]);
> > +	pte_t pteval = pte_mkspecial(pfn_pte(pfn, remapp->prot));
> > +
> > +	if ((rc=pvh_add_to_xen_p2m(pfn, remapp->fgmfn, remapp->domid)))
> > +		return rc;
> > +	native_set_pte(ptep, pteval);
> 
> Do we actually need the pte to be "special"?
> I would think that being in the guest p2m, it is actually quite a normal
> page.
> 
> 
> > +	return 0;
> > +}
> > +
> > +/* The only caller at moment passes one gmfn at a time.
> > + * PVH TBD/FIXME: expand this in future to honor batch requests.
> > + */
> > +static int pvh_remap_gmfn_range(struct vm_area_struct *vma,
> > +				unsigned long addr, unsigned long mfn, int nr,
> > +				pgprot_t prot, unsigned domid,
> > +				struct xen_pvh_pfn_info *pvhp)
> > +{
> > +	int err;
> > +	struct pvh_remap_data pvhdata;
> > +
> > +	if (nr > 1)
> > +		return -EINVAL;
> > +
> > +	pvhdata.fgmfn = mfn;
> > +	pvhdata.prot = prot;
> > +	pvhdata.domid = domid;
> > +	pvhdata.pvhinfop = pvhp;
> > +	err = apply_to_page_range(vma->vm_mm, addr, nr << PAGE_SHIFT,
> > +				  pvh_map_pte_fn, &pvhdata);
> > +	flush_tlb_all();
> 
> Maybe we can use one of the flush_tlb_range varieties instead of a
> flush_tlb_all?
> 
> 
> > +	return err;
> > +}
> > +
> >  #define REMAP_BATCH_SIZE 16
> >  
> >  struct remap_data {
> > @@ -2329,7 +2468,9 @@ static int remap_area_mfn_pte_fn(pte_t *ptep, pgtable_t token,
> >  int xen_remap_domain_mfn_range(struct vm_area_struct *vma,
> >  			       unsigned long addr,
> >  			       unsigned long mfn, int nr,
> > -			       pgprot_t prot, unsigned domid)
> > +			       pgprot_t prot, unsigned domid,
> > +			       struct xen_pvh_pfn_info *pvhp)
> > +
> >  {
> >  	struct remap_data rmd;
> >  	struct mmu_update mmu_update[REMAP_BATCH_SIZE];
> > @@ -2342,6 +2483,12 @@ int xen_remap_domain_mfn_range(struct vm_area_struct *vma,
> >  	BUG_ON(!((vma->vm_flags & (VM_PFNMAP | VM_RESERVED | VM_IO)) ==
> >  				(VM_PFNMAP | VM_RESERVED | VM_IO)));
> >  
> > +	if (xen_feature(XENFEAT_auto_translated_physmap)) {
> > +		/* We need to update the local page tables and the xen HAP */
> > +		return pvh_remap_gmfn_range(vma, addr, mfn, nr, prot, domid,
> > +					    pvhp);
> > +	}
> > +
> >  	rmd.mfn = mfn;
> >  	rmd.prot = prot;
> >  
> > @@ -2371,3 +2518,26 @@ out:
> >  	return err;
> >  }
> >  EXPORT_SYMBOL_GPL(xen_remap_domain_mfn_range);
> > +
> > +/* Returns: Number of pages unmapped */
> > +int xen_unmap_domain_mfn_range(struct vm_area_struct *vma,
> > +			       struct xen_pvh_pfn_info *pvhp)
> > +{
> > +	int count = 0;
> > +
> > +	if (!pvhp || !xen_feature(XENFEAT_auto_translated_physmap))
> > +		return 0;
> > +
> > +	while (pvhp->pi_next_todo--) {
> > +		unsigned long pfn;
> > +
> > +		/* the mmu has already cleaned up the process mmu resources at
> > +		 * this point (lookup_address will return NULL). */
> > +		pfn = page_to_pfn(pvhp->pi_paga[pvhp->pi_next_todo]);
> > +		pvh_rem_xen_p2m(pfn, 1);
> > +		count++;
> > +	}
> > +	flush_tlb_all();
> > +	return count;
> 
> Who is going to remove the corresponding mapping from the vma?
> Also we might be able to replace the flush_tlb_all with a
> flush_tlb_range.
> 
> 
> > +EXPORT_SYMBOL_GPL(xen_unmap_domain_mfn_range);
> > diff --git a/arch/x86/xen/mmu.h b/arch/x86/xen/mmu.h
> > index 73809bb..6d0bb56 100644
> > --- a/arch/x86/xen/mmu.h
> > +++ b/arch/x86/xen/mmu.h
> > @@ -23,4 +23,6 @@ unsigned long xen_read_cr2_direct(void);
> >  
> >  extern void xen_init_mmu_ops(void);
> >  extern void xen_hvm_init_mmu_ops(void);
> > +extern void xen_set_clr_mmio_pvh_pte(unsigned long pfn, unsigned long mfn,
> > +				     int nr_mfns, int add_mapping);
> >  #endif	/* _XEN_MMU_H */
> > diff --git a/include/xen/xen-ops.h b/include/xen/xen-ops.h
> > index 6a198e4..6c5ad83 100644
> > --- a/include/xen/xen-ops.h
> > +++ b/include/xen/xen-ops.h
> > @@ -24,9 +24,19 @@ int xen_create_contiguous_region(unsigned long vstart, unsigned int order,
> >  void xen_destroy_contiguous_region(unsigned long vstart, unsigned int order);
> >  
> >  struct vm_area_struct;
> > +struct xen_pvh_pfn_info;
> >  int xen_remap_domain_mfn_range(struct vm_area_struct *vma,
> >  			       unsigned long addr,
> >  			       unsigned long mfn, int nr,
> > -			       pgprot_t prot, unsigned domid);
> > +			       pgprot_t prot, unsigned domid,
> > +			       struct xen_pvh_pfn_info *pvhp);
> > +int xen_unmap_domain_mfn_range(struct vm_area_struct *vma,
> > +			       struct xen_pvh_pfn_info *pvhp);
> > +
> > +struct xen_pvh_pfn_info {
> > +	struct page **pi_paga;		/* pfn info page array */
> > +	int 	      pi_num_pgs;
> > +	int 	      pi_next_todo;
> > +};
> >  
> >  #endif /* INCLUDE_XEN_OPS_H */
> > -- 
> > 1.7.2.3
> > 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 24 14:04:22 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Sep 2012 14:04: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 1TG9Gb-00023N-LW; Mon, 24 Sep 2012 14:04:09 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1TG9GZ-00023A-Kc
	for xen-devel@lists.xen.org; Mon, 24 Sep 2012 14:04:07 +0000
Received: from [85.158.143.35:41454] by server-2.bemta-4.messagelabs.com id
	61/34-06610-65860605; Mon, 24 Sep 2012 14:04:06 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1348495240!12831964!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDc2OTcxMA==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13849 invoked from network); 24 Sep 2012 14:00:43 -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; 24 Sep 2012 14:00: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 q8OE0A46022683
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 24 Sep 2012 14:00:12 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
	q8OE08ak019895
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 24 Sep 2012 14:00:10 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
	q8OE0206028144; Mon, 24 Sep 2012 09:00:06 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 24 Sep 2012 07:00:02 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 2587C4031C; Mon, 24 Sep 2012 09:48:50 -0400 (EDT)
Date: Mon, 24 Sep 2012 09:48:50 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Andre Przywara <andre.przywara@amd.com>
Message-ID: <20120924134850.GC31618@phenom.dumpdata.com>
References: <501BC20F.3040205@amd.com>
	<20120803123628.GB10670@andromeda.dapyr.net>
	<20120817142237.GA8467@phenom.dumpdata.com>
	<505CA8AB.6000808@amd.com>
	<20120921174833.GC6821@phenom.dumpdata.com>
	<505CFC71.5090702@amd.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <505CFC71.5090702@amd.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: Konrad Rzeszutek Wilk <konrad@kernel.org>,
	Jeremy Fitzhardinge <jeremy@goop.org>, xen-devel <xen-devel@lists.xen.org>,
	Konrad Rzeszutek Wilk <konrad@darnok.org>
Subject: Re: [Xen-devel] Dom0 crash with old style AMD NUMA detection
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, Sep 22, 2012 at 01:46:57AM +0200, Andre Przywara wrote:
> On 09/21/2012 07:48 PM, Konrad Rzeszutek Wilk wrote:
> >>Acked-by: Andre Przywara<andre.przywara@amd.com>
> >>
> >>I compiled and boot-tested this on my (single node ;-) test box.
> >>First bare-metal, dmesg: No NUMA configuration found
> >>Then again, but with numa=off on the cmd-line: NUMA turned off
> >>Then under Xen as Dom0 kernel: NUMA turned off
> >>
> >>So the code behaves under Xen as one would have explicitly specified
> >>numa=off, which is what we want.
> >
> >Right.
> >>I couldn't get hold of the test machine (old K8 server) that the bug
> >>was once triggered, that's why I'm reluctant to give my Tested-by.
> >>Will try this ASAP.
> >
> >OK, will wait with this - it would be a bit silly if the patch did not
> >fix the issue :-)
> 
> Thanks for you patience. I tried some machines, it not only affects
> K8s, but also Barcelonas and Magny-Cours.
> Boot those with a Xen HV and restrict Dom0's memory to something
> well below the first node's size (say dom0_mem=512M). If the 3.x
> Dom0 kernel has CONFIG_AMD_NUMA compiled in, the box will crash,
> because the hardware's NUMA info read from the northbridge does not
> fit to Dom0's understanding of it's memory.
> With your fix the box booted fine, NUMA is turned off and everyone is happy.
> Double checked by commenting the numa_off=1 line in your patch:
> crash again. So this line definitely fixes this.
> 
> Tested-by: Andre Przywara <andre.przywara@amd.com>

OK, send out a git pull for it today. If Linus doesn't take it, I will just have
to do it in v3.7 time-frame and do the stable kernel backport.

Thanks again for testing and reporting this!
> 
> Regards,
> 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 Mon Sep 24 14:04:22 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Sep 2012 14:04: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 1TG9Gb-00023N-LW; Mon, 24 Sep 2012 14:04:09 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1TG9GZ-00023A-Kc
	for xen-devel@lists.xen.org; Mon, 24 Sep 2012 14:04:07 +0000
Received: from [85.158.143.35:41454] by server-2.bemta-4.messagelabs.com id
	61/34-06610-65860605; Mon, 24 Sep 2012 14:04:06 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1348495240!12831964!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDc2OTcxMA==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13849 invoked from network); 24 Sep 2012 14:00:43 -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; 24 Sep 2012 14:00: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 q8OE0A46022683
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 24 Sep 2012 14:00:12 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
	q8OE08ak019895
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 24 Sep 2012 14:00:10 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
	q8OE0206028144; Mon, 24 Sep 2012 09:00:06 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 24 Sep 2012 07:00:02 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 2587C4031C; Mon, 24 Sep 2012 09:48:50 -0400 (EDT)
Date: Mon, 24 Sep 2012 09:48:50 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Andre Przywara <andre.przywara@amd.com>
Message-ID: <20120924134850.GC31618@phenom.dumpdata.com>
References: <501BC20F.3040205@amd.com>
	<20120803123628.GB10670@andromeda.dapyr.net>
	<20120817142237.GA8467@phenom.dumpdata.com>
	<505CA8AB.6000808@amd.com>
	<20120921174833.GC6821@phenom.dumpdata.com>
	<505CFC71.5090702@amd.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <505CFC71.5090702@amd.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: Konrad Rzeszutek Wilk <konrad@kernel.org>,
	Jeremy Fitzhardinge <jeremy@goop.org>, xen-devel <xen-devel@lists.xen.org>,
	Konrad Rzeszutek Wilk <konrad@darnok.org>
Subject: Re: [Xen-devel] Dom0 crash with old style AMD NUMA detection
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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, Sep 22, 2012 at 01:46:57AM +0200, Andre Przywara wrote:
> On 09/21/2012 07:48 PM, Konrad Rzeszutek Wilk wrote:
> >>Acked-by: Andre Przywara<andre.przywara@amd.com>
> >>
> >>I compiled and boot-tested this on my (single node ;-) test box.
> >>First bare-metal, dmesg: No NUMA configuration found
> >>Then again, but with numa=off on the cmd-line: NUMA turned off
> >>Then under Xen as Dom0 kernel: NUMA turned off
> >>
> >>So the code behaves under Xen as one would have explicitly specified
> >>numa=off, which is what we want.
> >
> >Right.
> >>I couldn't get hold of the test machine (old K8 server) that the bug
> >>was once triggered, that's why I'm reluctant to give my Tested-by.
> >>Will try this ASAP.
> >
> >OK, will wait with this - it would be a bit silly if the patch did not
> >fix the issue :-)
> 
> Thanks for you patience. I tried some machines, it not only affects
> K8s, but also Barcelonas and Magny-Cours.
> Boot those with a Xen HV and restrict Dom0's memory to something
> well below the first node's size (say dom0_mem=512M). If the 3.x
> Dom0 kernel has CONFIG_AMD_NUMA compiled in, the box will crash,
> because the hardware's NUMA info read from the northbridge does not
> fit to Dom0's understanding of it's memory.
> With your fix the box booted fine, NUMA is turned off and everyone is happy.
> Double checked by commenting the numa_off=1 line in your patch:
> crash again. So this line definitely fixes this.
> 
> Tested-by: Andre Przywara <andre.przywara@amd.com>

OK, send out a git pull for it today. If Linus doesn't take it, I will just have
to do it in v3.7 time-frame and do the stable kernel backport.

Thanks again for testing and reporting this!
> 
> Regards,
> 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 Mon Sep 24 14:05:28 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Sep 2012 14: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 1TG9Hi-00028N-3c; Mon, 24 Sep 2012 14:05:18 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1TG9Hh-00028D-8d
	for Xen-devel@lists.xensource.com; Mon, 24 Sep 2012 14:05:17 +0000
Received: from [85.158.143.99:8533] by server-1.bemta-4.messagelabs.com id
	E9/2C-05684-C9860605; Mon, 24 Sep 2012 14:05:16 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1348495515!24553478!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTA4NDk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 373 invoked from network); 24 Sep 2012 14:05:15 -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;
	24 Sep 2012 14:05:15 -0000
X-IronPort-AV: E=Sophos;i="4.80,476,1344211200"; d="scan'208";a="14725988"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Sep 2012 14:05: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.279.1; Mon, 24 Sep 2012 15:05:14 +0100
Date: Mon, 24 Sep 2012 15:04:22 +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: <20120921121556.1a0ea8af@mantra.us.oracle.com>
Message-ID: <alpine.DEB.2.02.1209241500270.29232@kaball.uk.xensource.com>
References: <20120921121556.1a0ea8af@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>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH v1 2/8]: PVH mmu changes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 21 Sep 2012, Mukesh Rathor wrote:
> +struct pvh_remap_data {
> +	unsigned long fgmfn;		/* foreign domain's gmfn */
> +	pgprot_t prot;
> +	domid_t  domid;
> +	struct xen_pvh_pfn_info *pvhinfop;
> +};
> +
> +static int pvh_map_pte_fn(pte_t *ptep, pgtable_t token, unsigned long addr, 
> +			void *data)
> +{
> +	int rc;
> +	struct pvh_remap_data *remapp = data;
> +	struct xen_pvh_pfn_info *pvhp = remapp->pvhinfop;
> +	unsigned long pfn = page_to_pfn(pvhp->pi_paga[pvhp->pi_next_todo++]);
> +	pte_t pteval = pte_mkspecial(pfn_pte(pfn, remapp->prot));
> +
> +	if ((rc=pvh_add_to_xen_p2m(pfn, remapp->fgmfn, remapp->domid)))
> +		return rc;
> +	native_set_pte(ptep, pteval);
> +
> +	return 0;
> +}
> +
> +/* The only caller at moment passes one gmfn at a time.
> + * PVH TBD/FIXME: expand this in future to honor batch requests.
> + */
> +static int pvh_remap_gmfn_range(struct vm_area_struct *vma,
> +				unsigned long addr, unsigned long mfn, int nr,
> +				pgprot_t prot, unsigned domid,
> +				struct xen_pvh_pfn_info *pvhp)
> +{
> +	int err;
> +	struct pvh_remap_data pvhdata;
> +
> +	if (nr > 1)
> +		return -EINVAL;
> +
> +	pvhdata.fgmfn = mfn;
> +	pvhdata.prot = prot;
> +	pvhdata.domid = domid;
> +	pvhdata.pvhinfop = pvhp;
> +	err = apply_to_page_range(vma->vm_mm, addr, nr << PAGE_SHIFT,
> +				  pvh_map_pte_fn, &pvhdata);
> +	flush_tlb_all();
> +	return err;
> +}
> +
>  #define REMAP_BATCH_SIZE 16
>  
>  struct remap_data {
> @@ -2329,7 +2468,9 @@ static int remap_area_mfn_pte_fn(pte_t *ptep, pgtable_t token,
>  int xen_remap_domain_mfn_range(struct vm_area_struct *vma,
>  			       unsigned long addr,
>  			       unsigned long mfn, int nr,
> -			       pgprot_t prot, unsigned domid)
> +			       pgprot_t prot, unsigned domid,
> +			       struct xen_pvh_pfn_info *pvhp)
> +

xen_remap_domain_mfn_range is a cross-architecture call (it is available
on ARM as well). We cannot leak architecture specific informations like
xen_pvh_pfn_info in the parameter list.
It seems to be that xen_pvh_pfn_info contains arch-agnostic information:
in that case you just need to rename the struct to something more
generic. Otherwise if it really contains x86 specific info, you can
change it into an opaque pointer.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 24 14:05:28 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Sep 2012 14: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 1TG9Hi-00028N-3c; Mon, 24 Sep 2012 14:05:18 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1TG9Hh-00028D-8d
	for Xen-devel@lists.xensource.com; Mon, 24 Sep 2012 14:05:17 +0000
Received: from [85.158.143.99:8533] by server-1.bemta-4.messagelabs.com id
	E9/2C-05684-C9860605; Mon, 24 Sep 2012 14:05:16 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1348495515!24553478!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTA4NDk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 373 invoked from network); 24 Sep 2012 14:05:15 -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;
	24 Sep 2012 14:05:15 -0000
X-IronPort-AV: E=Sophos;i="4.80,476,1344211200"; d="scan'208";a="14725988"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Sep 2012 14:05: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.279.1; Mon, 24 Sep 2012 15:05:14 +0100
Date: Mon, 24 Sep 2012 15:04:22 +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: <20120921121556.1a0ea8af@mantra.us.oracle.com>
Message-ID: <alpine.DEB.2.02.1209241500270.29232@kaball.uk.xensource.com>
References: <20120921121556.1a0ea8af@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>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH v1 2/8]: PVH mmu changes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 21 Sep 2012, Mukesh Rathor wrote:
> +struct pvh_remap_data {
> +	unsigned long fgmfn;		/* foreign domain's gmfn */
> +	pgprot_t prot;
> +	domid_t  domid;
> +	struct xen_pvh_pfn_info *pvhinfop;
> +};
> +
> +static int pvh_map_pte_fn(pte_t *ptep, pgtable_t token, unsigned long addr, 
> +			void *data)
> +{
> +	int rc;
> +	struct pvh_remap_data *remapp = data;
> +	struct xen_pvh_pfn_info *pvhp = remapp->pvhinfop;
> +	unsigned long pfn = page_to_pfn(pvhp->pi_paga[pvhp->pi_next_todo++]);
> +	pte_t pteval = pte_mkspecial(pfn_pte(pfn, remapp->prot));
> +
> +	if ((rc=pvh_add_to_xen_p2m(pfn, remapp->fgmfn, remapp->domid)))
> +		return rc;
> +	native_set_pte(ptep, pteval);
> +
> +	return 0;
> +}
> +
> +/* The only caller at moment passes one gmfn at a time.
> + * PVH TBD/FIXME: expand this in future to honor batch requests.
> + */
> +static int pvh_remap_gmfn_range(struct vm_area_struct *vma,
> +				unsigned long addr, unsigned long mfn, int nr,
> +				pgprot_t prot, unsigned domid,
> +				struct xen_pvh_pfn_info *pvhp)
> +{
> +	int err;
> +	struct pvh_remap_data pvhdata;
> +
> +	if (nr > 1)
> +		return -EINVAL;
> +
> +	pvhdata.fgmfn = mfn;
> +	pvhdata.prot = prot;
> +	pvhdata.domid = domid;
> +	pvhdata.pvhinfop = pvhp;
> +	err = apply_to_page_range(vma->vm_mm, addr, nr << PAGE_SHIFT,
> +				  pvh_map_pte_fn, &pvhdata);
> +	flush_tlb_all();
> +	return err;
> +}
> +
>  #define REMAP_BATCH_SIZE 16
>  
>  struct remap_data {
> @@ -2329,7 +2468,9 @@ static int remap_area_mfn_pte_fn(pte_t *ptep, pgtable_t token,
>  int xen_remap_domain_mfn_range(struct vm_area_struct *vma,
>  			       unsigned long addr,
>  			       unsigned long mfn, int nr,
> -			       pgprot_t prot, unsigned domid)
> +			       pgprot_t prot, unsigned domid,
> +			       struct xen_pvh_pfn_info *pvhp)
> +

xen_remap_domain_mfn_range is a cross-architecture call (it is available
on ARM as well). We cannot leak architecture specific informations like
xen_pvh_pfn_info in the parameter list.
It seems to be that xen_pvh_pfn_info contains arch-agnostic information:
in that case you just need to rename the struct to something more
generic. Otherwise if it really contains x86 specific info, you can
change it into an opaque pointer.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 24 14:11:01 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Sep 2012 14: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 1TG9N1-0002Te-43; Mon, 24 Sep 2012 14:10: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 1TG9Mz-0002TZ-5y
	for xen-devel@lists.xen.org; Mon, 24 Sep 2012 14:10:45 +0000
Received: from [85.158.143.99:57763] by server-3.bemta-4.messagelabs.com id
	D9/9B-10986-4E960605; Mon, 24 Sep 2012 14:10:44 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1348495842!26275220!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28521 invoked from network); 24 Sep 2012 14:10:43 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-4.tower-216.messagelabs.com with SMTP;
	24 Sep 2012 14:10:43 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 24 Sep 2012 15:10:42 +0100
Message-Id: <506085FF020000780009D5F9@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 24 Sep 2012 15:10:39 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ben Guthro" <ben@guthro.net>
References: <CAOvdn6XKPOMNn6AjuYvZvPXRRJffN3po5GXe1Yh1-m0hisMK_w@mail.gmail.com>
	<CC8273A0.4C9DD%keir@xen.org>
	<50605E9A020000780009D486@nat28.tlf.novell.com>
	<CAOvdn6XmB6rj3_QVU+59V8p24Y5G47AWxVEM=id02JWXkuhibQ@mail.gmail.com>
	<5060640B020000780009D4D2@nat28.tlf.novell.com>
	<CAOvdn6XLy8zR2rb2MEyi2aT9LQiFvFLY_H02p181mTsVLVTZkw@mail.gmail.com>
	<506068A0020000780009D519@nat28.tlf.novell.com>
	<CAOvdn6Undn2srfNhW++wLfUNFQ5JnZ3rp5bg7DD_TDPCHqmP_A@mail.gmail.com>
	<50606F18020000780009D57B@nat28.tlf.novell.com>
	<CAOvdn6UMHmPWqedYE9GQQMDaM4oiHLDSn9ZzSgJjGf89g1DgTw@mail.gmail.com>
	<50607D70020000780009D5C3@nat28.tlf.novell.com>
	<CAOvdn6XL9ebp2oUV0XEXk_WdU3-=YAj+xfz6AMLDBpVThH3Xvw@mail.gmail.com>
In-Reply-To: <CAOvdn6XL9ebp2oUV0XEXk_WdU3-=YAj+xfz6AMLDBpVThH3Xvw@mail.gmail.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] Xen4.2 S3 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 24.09.12 at 15:56, Ben Guthro <ben@guthro.net> wrote:
> On Mon, Sep 24, 2012 at 9:34 AM, Jan Beulich <JBeulich@suse.com> wrote:
>> ...; the interesting ones are
>> - at the end of xen/arch/x86/acpu/cpu_idle.c:acpi_dead_idle()
>> - xen/arch/x86/domain.c:default_dead_idle()
> 
> 
> Thanks! This fixes the issue on this machine!

Hooray!

> Is this a reasonable long-term solution - or are there reasons not to
> call wbinvd() here?

That's a perfectly valid adjustment (see my earlier reply where
I originally suggested it and explained why it may be necessary).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 24 14:11:01 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Sep 2012 14: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 1TG9N1-0002Te-43; Mon, 24 Sep 2012 14:10: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 1TG9Mz-0002TZ-5y
	for xen-devel@lists.xen.org; Mon, 24 Sep 2012 14:10:45 +0000
Received: from [85.158.143.99:57763] by server-3.bemta-4.messagelabs.com id
	D9/9B-10986-4E960605; Mon, 24 Sep 2012 14:10:44 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1348495842!26275220!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28521 invoked from network); 24 Sep 2012 14:10:43 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-4.tower-216.messagelabs.com with SMTP;
	24 Sep 2012 14:10:43 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 24 Sep 2012 15:10:42 +0100
Message-Id: <506085FF020000780009D5F9@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 24 Sep 2012 15:10:39 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ben Guthro" <ben@guthro.net>
References: <CAOvdn6XKPOMNn6AjuYvZvPXRRJffN3po5GXe1Yh1-m0hisMK_w@mail.gmail.com>
	<CC8273A0.4C9DD%keir@xen.org>
	<50605E9A020000780009D486@nat28.tlf.novell.com>
	<CAOvdn6XmB6rj3_QVU+59V8p24Y5G47AWxVEM=id02JWXkuhibQ@mail.gmail.com>
	<5060640B020000780009D4D2@nat28.tlf.novell.com>
	<CAOvdn6XLy8zR2rb2MEyi2aT9LQiFvFLY_H02p181mTsVLVTZkw@mail.gmail.com>
	<506068A0020000780009D519@nat28.tlf.novell.com>
	<CAOvdn6Undn2srfNhW++wLfUNFQ5JnZ3rp5bg7DD_TDPCHqmP_A@mail.gmail.com>
	<50606F18020000780009D57B@nat28.tlf.novell.com>
	<CAOvdn6UMHmPWqedYE9GQQMDaM4oiHLDSn9ZzSgJjGf89g1DgTw@mail.gmail.com>
	<50607D70020000780009D5C3@nat28.tlf.novell.com>
	<CAOvdn6XL9ebp2oUV0XEXk_WdU3-=YAj+xfz6AMLDBpVThH3Xvw@mail.gmail.com>
In-Reply-To: <CAOvdn6XL9ebp2oUV0XEXk_WdU3-=YAj+xfz6AMLDBpVThH3Xvw@mail.gmail.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] Xen4.2 S3 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 24.09.12 at 15:56, Ben Guthro <ben@guthro.net> wrote:
> On Mon, Sep 24, 2012 at 9:34 AM, Jan Beulich <JBeulich@suse.com> wrote:
>> ...; the interesting ones are
>> - at the end of xen/arch/x86/acpu/cpu_idle.c:acpi_dead_idle()
>> - xen/arch/x86/domain.c:default_dead_idle()
> 
> 
> Thanks! This fixes the issue on this machine!

Hooray!

> Is this a reasonable long-term solution - or are there reasons not to
> call wbinvd() here?

That's a perfectly valid adjustment (see my earlier reply where
I originally suggested it and explained why it may be necessary).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 24 14:14:16 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Sep 2012 14:14:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TG9QC-0002aI-Nk; Mon, 24 Sep 2012 14:14:04 +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 1TG9QA-0002Zw-MX
	for Xen-devel@lists.xensource.com; Mon, 24 Sep 2012 14:14:02 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1348496036!6618889!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTA4NDk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4142 invoked from network); 24 Sep 2012 14:13:56 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Sep 2012 14:13:56 -0000
X-IronPort-AV: E=Sophos;i="4.80,476,1344211200"; d="scan'208";a="14726250"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Sep 2012 14:13: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.279.1;
	Mon, 24 Sep 2012 15:13:56 +0100
Message-ID: <1348496035.3452.88.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Date: Mon, 24 Sep 2012 15:13:55 +0100
In-Reply-To: <alpine.DEB.2.02.1209241500270.29232@kaball.uk.xensource.com>
References: <20120921121556.1a0ea8af@mantra.us.oracle.com>
	<alpine.DEB.2.02.1209241500270.29232@kaball.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH v1 2/8]: PVH mmu changes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2012-09-24 at 15:04 +0100, Stefano Stabellini wrote:
> On Fri, 21 Sep 2012, Mukesh Rathor wrote:
> > +struct pvh_remap_data {
> > +	unsigned long fgmfn;		/* foreign domain's gmfn */
> > +	pgprot_t prot;
> > +	domid_t  domid;
> > +	struct xen_pvh_pfn_info *pvhinfop;
> > +};
> > +
> > +static int pvh_map_pte_fn(pte_t *ptep, pgtable_t token, unsigned long addr, 
> > +			void *data)
> > +{
> > +	int rc;
> > +	struct pvh_remap_data *remapp = data;
> > +	struct xen_pvh_pfn_info *pvhp = remapp->pvhinfop;
> > +	unsigned long pfn = page_to_pfn(pvhp->pi_paga[pvhp->pi_next_todo++]);
> > +	pte_t pteval = pte_mkspecial(pfn_pte(pfn, remapp->prot));
> > +
> > +	if ((rc=pvh_add_to_xen_p2m(pfn, remapp->fgmfn, remapp->domid)))
> > +		return rc;
> > +	native_set_pte(ptep, pteval);
> > +
> > +	return 0;
> > +}
> > +
> > +/* The only caller at moment passes one gmfn at a time.
> > + * PVH TBD/FIXME: expand this in future to honor batch requests.
> > + */
> > +static int pvh_remap_gmfn_range(struct vm_area_struct *vma,
> > +				unsigned long addr, unsigned long mfn, int nr,
> > +				pgprot_t prot, unsigned domid,
> > +				struct xen_pvh_pfn_info *pvhp)
> > +{
> > +	int err;
> > +	struct pvh_remap_data pvhdata;
> > +
> > +	if (nr > 1)
> > +		return -EINVAL;
> > +
> > +	pvhdata.fgmfn = mfn;
> > +	pvhdata.prot = prot;
> > +	pvhdata.domid = domid;
> > +	pvhdata.pvhinfop = pvhp;
> > +	err = apply_to_page_range(vma->vm_mm, addr, nr << PAGE_SHIFT,
> > +				  pvh_map_pte_fn, &pvhdata);
> > +	flush_tlb_all();
> > +	return err;
> > +}
> > +
> >  #define REMAP_BATCH_SIZE 16
> >  
> >  struct remap_data {
> > @@ -2329,7 +2468,9 @@ static int remap_area_mfn_pte_fn(pte_t *ptep, pgtable_t token,
> >  int xen_remap_domain_mfn_range(struct vm_area_struct *vma,
> >  			       unsigned long addr,
> >  			       unsigned long mfn, int nr,
> > -			       pgprot_t prot, unsigned domid)
> > +			       pgprot_t prot, unsigned domid,
> > +			       struct xen_pvh_pfn_info *pvhp)
> > +
> 
> xen_remap_domain_mfn_range is a cross-architecture call (it is available
> on ARM as well). We cannot leak architecture specific informations like
> xen_pvh_pfn_info in the parameter list.
> It seems to be that xen_pvh_pfn_info contains arch-agnostic information:
> in that case you just need to rename the struct to something more
> generic. Otherwise if it really contains x86 specific info, you can
> change it into an opaque pointer.

... or explode it into the relevant constituents struct members which
need to be passed over the interface when calling these functions.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 24 14:14:16 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Sep 2012 14:14:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TG9QC-0002aI-Nk; Mon, 24 Sep 2012 14:14:04 +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 1TG9QA-0002Zw-MX
	for Xen-devel@lists.xensource.com; Mon, 24 Sep 2012 14:14:02 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1348496036!6618889!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTA4NDk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4142 invoked from network); 24 Sep 2012 14:13:56 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Sep 2012 14:13:56 -0000
X-IronPort-AV: E=Sophos;i="4.80,476,1344211200"; d="scan'208";a="14726250"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Sep 2012 14:13: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.279.1;
	Mon, 24 Sep 2012 15:13:56 +0100
Message-ID: <1348496035.3452.88.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Date: Mon, 24 Sep 2012 15:13:55 +0100
In-Reply-To: <alpine.DEB.2.02.1209241500270.29232@kaball.uk.xensource.com>
References: <20120921121556.1a0ea8af@mantra.us.oracle.com>
	<alpine.DEB.2.02.1209241500270.29232@kaball.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH v1 2/8]: PVH mmu changes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2012-09-24 at 15:04 +0100, Stefano Stabellini wrote:
> On Fri, 21 Sep 2012, Mukesh Rathor wrote:
> > +struct pvh_remap_data {
> > +	unsigned long fgmfn;		/* foreign domain's gmfn */
> > +	pgprot_t prot;
> > +	domid_t  domid;
> > +	struct xen_pvh_pfn_info *pvhinfop;
> > +};
> > +
> > +static int pvh_map_pte_fn(pte_t *ptep, pgtable_t token, unsigned long addr, 
> > +			void *data)
> > +{
> > +	int rc;
> > +	struct pvh_remap_data *remapp = data;
> > +	struct xen_pvh_pfn_info *pvhp = remapp->pvhinfop;
> > +	unsigned long pfn = page_to_pfn(pvhp->pi_paga[pvhp->pi_next_todo++]);
> > +	pte_t pteval = pte_mkspecial(pfn_pte(pfn, remapp->prot));
> > +
> > +	if ((rc=pvh_add_to_xen_p2m(pfn, remapp->fgmfn, remapp->domid)))
> > +		return rc;
> > +	native_set_pte(ptep, pteval);
> > +
> > +	return 0;
> > +}
> > +
> > +/* The only caller at moment passes one gmfn at a time.
> > + * PVH TBD/FIXME: expand this in future to honor batch requests.
> > + */
> > +static int pvh_remap_gmfn_range(struct vm_area_struct *vma,
> > +				unsigned long addr, unsigned long mfn, int nr,
> > +				pgprot_t prot, unsigned domid,
> > +				struct xen_pvh_pfn_info *pvhp)
> > +{
> > +	int err;
> > +	struct pvh_remap_data pvhdata;
> > +
> > +	if (nr > 1)
> > +		return -EINVAL;
> > +
> > +	pvhdata.fgmfn = mfn;
> > +	pvhdata.prot = prot;
> > +	pvhdata.domid = domid;
> > +	pvhdata.pvhinfop = pvhp;
> > +	err = apply_to_page_range(vma->vm_mm, addr, nr << PAGE_SHIFT,
> > +				  pvh_map_pte_fn, &pvhdata);
> > +	flush_tlb_all();
> > +	return err;
> > +}
> > +
> >  #define REMAP_BATCH_SIZE 16
> >  
> >  struct remap_data {
> > @@ -2329,7 +2468,9 @@ static int remap_area_mfn_pte_fn(pte_t *ptep, pgtable_t token,
> >  int xen_remap_domain_mfn_range(struct vm_area_struct *vma,
> >  			       unsigned long addr,
> >  			       unsigned long mfn, int nr,
> > -			       pgprot_t prot, unsigned domid)
> > +			       pgprot_t prot, unsigned domid,
> > +			       struct xen_pvh_pfn_info *pvhp)
> > +
> 
> xen_remap_domain_mfn_range is a cross-architecture call (it is available
> on ARM as well). We cannot leak architecture specific informations like
> xen_pvh_pfn_info in the parameter list.
> It seems to be that xen_pvh_pfn_info contains arch-agnostic information:
> in that case you just need to rename the struct to something more
> generic. Otherwise if it really contains x86 specific info, you can
> change it into an opaque pointer.

... or explode it into the relevant constituents struct members which
need to be passed over the interface when calling these functions.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 24 14:14:17 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Sep 2012 14: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 1TG9QD-0002aP-46; Mon, 24 Sep 2012 14:14:05 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1TG9QB-0002aA-EZ
	for xen-devel@lists.xen.org; Mon, 24 Sep 2012 14:14:03 +0000
Received: from [85.158.139.211:47210] by server-7.bemta-5.messagelabs.com id
	5C/4D-00431-AAA60605; Mon, 24 Sep 2012 14:14:02 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-4.tower-206.messagelabs.com!1348496040!19766140!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDc2OTcxMA==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31499 invoked from network); 24 Sep 2012 14:14:01 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-4.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 24 Sep 2012 14:14:01 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q8OEDuNc012045
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 24 Sep 2012 14:13: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
	q8OEDtSG004788
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 24 Sep 2012 14:13:56 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
	q8OEDn5j013667; Mon, 24 Sep 2012 09:13:49 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 24 Sep 2012 07:13:49 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 196134031C; Mon, 24 Sep 2012 10:02:37 -0400 (EDT)
Date: Mon, 24 Sep 2012 10:02:37 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Ben Guthro <ben@guthro.net>
Message-ID: <20120924140236.GG31618@phenom.dumpdata.com>
References: <CAOvdn6XKPOMNn6AjuYvZvPXRRJffN3po5GXe1Yh1-m0hisMK_w@mail.gmail.com>
	<CC8273A0.4C9DD%keir@xen.org>
	<50605E9A020000780009D486@nat28.tlf.novell.com>
	<CAOvdn6XmB6rj3_QVU+59V8p24Y5G47AWxVEM=id02JWXkuhibQ@mail.gmail.com>
	<5060640B020000780009D4D2@nat28.tlf.novell.com>
	<CAOvdn6XLy8zR2rb2MEyi2aT9LQiFvFLY_H02p181mTsVLVTZkw@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAOvdn6XLy8zR2rb2MEyi2aT9LQiFvFLY_H02p181mTsVLVTZkw@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: Thomas Goetz <thomas.goetz@citrix.com>, Keir Fraser <keir@xen.org>,
	john.baboval@citrix.com, Jan Beulich <JBeulich@suse.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen4.2 S3 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 Mon, Sep 24, 2012 at 07:54:05AM -0400, Ben Guthro wrote:
> I see - Konrad - do you have a changeset I can look for with the features
> Jan describes?

konrad@phenom:~/work/linux$ git log --oneline drivers/xen/xen-acpi-processor.c
17f9b89 xen/acpi: Fix potential memory leak.
323f90a xen-acpi-processor: Add missing #include <xen/xen.h>
b930fe5 xen/acpi: Workaround broken BIOSes exporting non-existing C-states.
27257fc xen/acpi: Remove the WARN's as they just create noise.
59a5680 xen/acpi-processor: C and P-state driver that uploads said data to hypervisor.


> 
> 
> On Mon, Sep 24, 2012 at 7:45 AM, Jan Beulich <JBeulich@suse.com> wrote:
> 
> > >>> On 24.09.12 at 13:25, Ben Guthro <ben@guthro.net> wrote:
> > > It is an older system (Core2) - so it may be using the default mechanism,
> > > but I'd have to go dig up some processor docs to be sure.
> >
> > This is not just a matter of what the CPU supports, but also what
> > info gets passed down from Dom0 - if e.g. your kernel doesn't
> > have Konrad's P-/C-state patches, then there's no way for Xen to
> > use any of the advanced methods.
> >
> > Jan
> >
> >

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 24 14:14:17 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Sep 2012 14: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 1TG9QD-0002aP-46; Mon, 24 Sep 2012 14:14:05 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1TG9QB-0002aA-EZ
	for xen-devel@lists.xen.org; Mon, 24 Sep 2012 14:14:03 +0000
Received: from [85.158.139.211:47210] by server-7.bemta-5.messagelabs.com id
	5C/4D-00431-AAA60605; Mon, 24 Sep 2012 14:14:02 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-4.tower-206.messagelabs.com!1348496040!19766140!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDc2OTcxMA==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31499 invoked from network); 24 Sep 2012 14:14:01 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-4.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 24 Sep 2012 14:14:01 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q8OEDuNc012045
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 24 Sep 2012 14:13: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
	q8OEDtSG004788
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 24 Sep 2012 14:13:56 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
	q8OEDn5j013667; Mon, 24 Sep 2012 09:13:49 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 24 Sep 2012 07:13:49 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 196134031C; Mon, 24 Sep 2012 10:02:37 -0400 (EDT)
Date: Mon, 24 Sep 2012 10:02:37 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Ben Guthro <ben@guthro.net>
Message-ID: <20120924140236.GG31618@phenom.dumpdata.com>
References: <CAOvdn6XKPOMNn6AjuYvZvPXRRJffN3po5GXe1Yh1-m0hisMK_w@mail.gmail.com>
	<CC8273A0.4C9DD%keir@xen.org>
	<50605E9A020000780009D486@nat28.tlf.novell.com>
	<CAOvdn6XmB6rj3_QVU+59V8p24Y5G47AWxVEM=id02JWXkuhibQ@mail.gmail.com>
	<5060640B020000780009D4D2@nat28.tlf.novell.com>
	<CAOvdn6XLy8zR2rb2MEyi2aT9LQiFvFLY_H02p181mTsVLVTZkw@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAOvdn6XLy8zR2rb2MEyi2aT9LQiFvFLY_H02p181mTsVLVTZkw@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: Thomas Goetz <thomas.goetz@citrix.com>, Keir Fraser <keir@xen.org>,
	john.baboval@citrix.com, Jan Beulich <JBeulich@suse.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen4.2 S3 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 Mon, Sep 24, 2012 at 07:54:05AM -0400, Ben Guthro wrote:
> I see - Konrad - do you have a changeset I can look for with the features
> Jan describes?

konrad@phenom:~/work/linux$ git log --oneline drivers/xen/xen-acpi-processor.c
17f9b89 xen/acpi: Fix potential memory leak.
323f90a xen-acpi-processor: Add missing #include <xen/xen.h>
b930fe5 xen/acpi: Workaround broken BIOSes exporting non-existing C-states.
27257fc xen/acpi: Remove the WARN's as they just create noise.
59a5680 xen/acpi-processor: C and P-state driver that uploads said data to hypervisor.


> 
> 
> On Mon, Sep 24, 2012 at 7:45 AM, Jan Beulich <JBeulich@suse.com> wrote:
> 
> > >>> On 24.09.12 at 13:25, Ben Guthro <ben@guthro.net> wrote:
> > > It is an older system (Core2) - so it may be using the default mechanism,
> > > but I'd have to go dig up some processor docs to be sure.
> >
> > This is not just a matter of what the CPU supports, but also what
> > info gets passed down from Dom0 - if e.g. your kernel doesn't
> > have Konrad's P-/C-state patches, then there's no way for Xen to
> > use any of the advanced methods.
> >
> > Jan
> >
> >

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 24 14:15:09 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Sep 2012 14:15: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 1TG9R4-0002hu-If; Mon, 24 Sep 2012 14:14:58 +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 1TG9R2-0002hW-L4
	for xen-devel@lists.xen.org; Mon, 24 Sep 2012 14:14:56 +0000
Received: from [85.158.137.99:25234] by server-4.bemta-3.messagelabs.com id
	7B/48-24831-FDA60605; Mon, 24 Sep 2012 14:14:55 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-2.tower-217.messagelabs.com!1348496094!18800970!1
X-Originating-IP: [63.239.67.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28334 invoked from network); 24 Sep 2012 14:14:55 -0000
Received: from emvm-gh1-uea09.nsa.gov (HELO nsa.gov) (63.239.67.10)
	by server-2.tower-217.messagelabs.com with SMTP;
	24 Sep 2012 14:14:54 -0000
X-TM-IMSS-Message-ID: <774cd17700173973@nsa.gov>
Received: from tarius.tycho.ncsc.mil ([144.51.3.1]) by nsa.gov
	([63.239.67.10]) with ESMTP (TREND IMSS SMTP Service 7.1) id
	774cd17700173973 ; Mon, 24 Sep 2012 10:16:28 -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 q8OEEkZZ030551; 
	Mon, 24 Sep 2012 10:14:46 -0400
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: JBeulich@suse.com
Date: Mon, 24 Sep 2012 10:14:04 -0400
Message-Id: <1348496044-11719-1-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.11.4
In-Reply-To: <505AD938020000780009C7AB@nat28.tlf.novell.com>
References: <505AD938020000780009C7AB@nat28.tlf.novell.com>
Cc: Tim Deegan <tim@xen.org>, Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	Keir Fraser <keir@xen.org>, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH v3] arch/x86: check remote MMIO remap permissions
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Patch was 19/23 in the XSM IS_PRIV series, but as Jan pointed out, it
can be applied separately from the other patches.

---->8---------------------------------------------------------------

When a domain is mapping pages from a different pg_owner domain, the
iomem_access checks are currently only applied to the pg_owner domain,
potentially allowing a domain with a more restrictive iomem_access
policy to have the pages mapped into its page tables. To catch this,
also check the owner of the page tables. The current domain does not
need to be checked because the ability to manipulate a domain's page
tables implies full access to the target domain, so checking that
domain's permission is sufficient.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Acked-by: Jan Beulich <jbeulich@suse.com>
Cc: Keir Fraser <keir@xen.org>
Cc: Tim Deegan <tim@xen.org>
---
 xen/arch/x86/mm.c | 13 +++++++++++++
 1 file changed, 13 insertions(+)

diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
index a962369..ff64413 100644
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -754,6 +754,19 @@ get_page_from_l1e(
             return -EINVAL;
         }
 
+        if ( pg_owner != l1e_owner &&
+             !iomem_access_permitted(l1e_owner, mfn, mfn) )
+        {
+            if ( mfn != (PADDR_MASK >> PAGE_SHIFT) ) /* INVALID_MFN? */
+            {
+                MEM_LOG("Dom%u attempted to map I/O space %08lx in dom%u to dom%u",
+                        curr->domain->domain_id, mfn, pg_owner->domain_id,
+                        l1e_owner->domain_id);
+                return -EPERM;
+            }
+            return -EINVAL;
+        }
+
         if ( !(l1f & _PAGE_RW) ||
              !rangeset_contains_singleton(mmio_ro_ranges, mfn) )
             return 0;
-- 
1.7.11.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 24 14:15:09 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Sep 2012 14:15: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 1TG9R4-0002hu-If; Mon, 24 Sep 2012 14:14:58 +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 1TG9R2-0002hW-L4
	for xen-devel@lists.xen.org; Mon, 24 Sep 2012 14:14:56 +0000
Received: from [85.158.137.99:25234] by server-4.bemta-3.messagelabs.com id
	7B/48-24831-FDA60605; Mon, 24 Sep 2012 14:14:55 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-2.tower-217.messagelabs.com!1348496094!18800970!1
X-Originating-IP: [63.239.67.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28334 invoked from network); 24 Sep 2012 14:14:55 -0000
Received: from emvm-gh1-uea09.nsa.gov (HELO nsa.gov) (63.239.67.10)
	by server-2.tower-217.messagelabs.com with SMTP;
	24 Sep 2012 14:14:54 -0000
X-TM-IMSS-Message-ID: <774cd17700173973@nsa.gov>
Received: from tarius.tycho.ncsc.mil ([144.51.3.1]) by nsa.gov
	([63.239.67.10]) with ESMTP (TREND IMSS SMTP Service 7.1) id
	774cd17700173973 ; Mon, 24 Sep 2012 10:16:28 -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 q8OEEkZZ030551; 
	Mon, 24 Sep 2012 10:14:46 -0400
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: JBeulich@suse.com
Date: Mon, 24 Sep 2012 10:14:04 -0400
Message-Id: <1348496044-11719-1-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.11.4
In-Reply-To: <505AD938020000780009C7AB@nat28.tlf.novell.com>
References: <505AD938020000780009C7AB@nat28.tlf.novell.com>
Cc: Tim Deegan <tim@xen.org>, Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	Keir Fraser <keir@xen.org>, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH v3] arch/x86: check remote MMIO remap permissions
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Patch was 19/23 in the XSM IS_PRIV series, but as Jan pointed out, it
can be applied separately from the other patches.

---->8---------------------------------------------------------------

When a domain is mapping pages from a different pg_owner domain, the
iomem_access checks are currently only applied to the pg_owner domain,
potentially allowing a domain with a more restrictive iomem_access
policy to have the pages mapped into its page tables. To catch this,
also check the owner of the page tables. The current domain does not
need to be checked because the ability to manipulate a domain's page
tables implies full access to the target domain, so checking that
domain's permission is sufficient.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Acked-by: Jan Beulich <jbeulich@suse.com>
Cc: Keir Fraser <keir@xen.org>
Cc: Tim Deegan <tim@xen.org>
---
 xen/arch/x86/mm.c | 13 +++++++++++++
 1 file changed, 13 insertions(+)

diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
index a962369..ff64413 100644
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -754,6 +754,19 @@ get_page_from_l1e(
             return -EINVAL;
         }
 
+        if ( pg_owner != l1e_owner &&
+             !iomem_access_permitted(l1e_owner, mfn, mfn) )
+        {
+            if ( mfn != (PADDR_MASK >> PAGE_SHIFT) ) /* INVALID_MFN? */
+            {
+                MEM_LOG("Dom%u attempted to map I/O space %08lx in dom%u to dom%u",
+                        curr->domain->domain_id, mfn, pg_owner->domain_id,
+                        l1e_owner->domain_id);
+                return -EPERM;
+            }
+            return -EINVAL;
+        }
+
         if ( !(l1f & _PAGE_RW) ||
              !rangeset_contains_singleton(mmio_ro_ranges, mfn) )
             return 0;
-- 
1.7.11.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 24 14:16:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Sep 2012 14:16:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TG9SJ-0002qe-1o; Mon, 24 Sep 2012 14:16: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 1TG9SH-0002qN-Hp
	for xen-devel@lists.xen.org; Mon, 24 Sep 2012 14:16:13 +0000
Received: from [85.158.139.83:53924] by server-9.bemta-5.messagelabs.com id
	7D/AE-14846-C2B60605; Mon, 24 Sep 2012 14:16:12 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1348496149!29685097!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzU5Njc1\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20811 invoked from network); 24 Sep 2012 14:15:51 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-15.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 24 Sep 2012 14:15:51 -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 q8OEFQiS025181
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 24 Sep 2012 14:15:28 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q8OEFOij017665
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 24 Sep 2012 14:15:26 GMT
Received: from abhmt102.oracle.com (abhmt102.oracle.com [141.146.116.54])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q8OEFO7m012746; Mon, 24 Sep 2012 09:15:24 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 24 Sep 2012 07:15:23 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id D7E494031C; Mon, 24 Sep 2012 10:04:11 -0400 (EDT)
Date: Mon, 24 Sep 2012 10:04:11 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Javier Marcet <jmarcet@gmail.com>
Message-ID: <20120924140411.GH31618@phenom.dumpdata.com>
References: <CAOvdn6XKPOMNn6AjuYvZvPXRRJffN3po5GXe1Yh1-m0hisMK_w@mail.gmail.com>
	<CC8273A0.4C9DD%keir@xen.org>
	<50605E9A020000780009D486@nat28.tlf.novell.com>
	<CAOvdn6XmB6rj3_QVU+59V8p24Y5G47AWxVEM=id02JWXkuhibQ@mail.gmail.com>
	<5060640B020000780009D4D2@nat28.tlf.novell.com>
	<CAOvdn6XLy8zR2rb2MEyi2aT9LQiFvFLY_H02p181mTsVLVTZkw@mail.gmail.com>
	<20120924122203.GG8912@reaktio.net>
	<CAOvdn6XV4eoA-FfFns1xhx7HCUqXc7KHxZwyKuT4FHG8s3R5RQ@mail.gmail.com>
	<CAAnFQG9PLQjdh6Ab6=Y5ZGM1s4nGdLekKU=pcKNMxt4rmt_RKA@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAAnFQG9PLQjdh6Ab6=Y5ZGM1s4nGdLekKU=pcKNMxt4rmt_RKA@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: Keir Fraser <keir@xen.org>, john.baboval@citrix.com,
	xen-devel <xen-devel@lists.xen.org>, Ben Guthro <ben@guthro.net>,
	Jan Beulich <JBeulich@suse.com>, Thomas Goetz <thomas.goetz@citrix.com>
Subject: Re: [Xen-devel] Xen4.2 S3 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 Mon, Sep 24, 2012 at 02:37:22PM +0200, Javier Marcet wrote:
> On Mon, Sep 24, 2012 at 2:27 PM, Ben Guthro <ben@guthro.net> wrote:
> 
> Hi Ben,
> 
> >> >    I see - Konrad - do you have a changeset I can look for with the
> >> > features
> >> >    Jan describes?
> >>
> >> xen-acpi-processor driver was merged to upstream Linux kernel v3.4.
> >>
> >
> > I see - so the advanced methods are not being used then

You mean with the v3.5 kernel? I would think they would be used..

> > This same kernel does work with Xen-4.0.x though. Is there an assumption in
> > the code that ties Xen-4.2 to a newer kernel?
> 
> I'm being bitten by this bug with a 3.5 kernel and Xen 4.2

Huh? How so?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 24 14:16:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Sep 2012 14:16:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TG9SJ-0002qe-1o; Mon, 24 Sep 2012 14:16: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 1TG9SH-0002qN-Hp
	for xen-devel@lists.xen.org; Mon, 24 Sep 2012 14:16:13 +0000
Received: from [85.158.139.83:53924] by server-9.bemta-5.messagelabs.com id
	7D/AE-14846-C2B60605; Mon, 24 Sep 2012 14:16:12 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1348496149!29685097!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzU5Njc1\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20811 invoked from network); 24 Sep 2012 14:15:51 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-15.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 24 Sep 2012 14:15:51 -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 q8OEFQiS025181
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 24 Sep 2012 14:15:28 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q8OEFOij017665
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 24 Sep 2012 14:15:26 GMT
Received: from abhmt102.oracle.com (abhmt102.oracle.com [141.146.116.54])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q8OEFO7m012746; Mon, 24 Sep 2012 09:15:24 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 24 Sep 2012 07:15:23 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id D7E494031C; Mon, 24 Sep 2012 10:04:11 -0400 (EDT)
Date: Mon, 24 Sep 2012 10:04:11 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Javier Marcet <jmarcet@gmail.com>
Message-ID: <20120924140411.GH31618@phenom.dumpdata.com>
References: <CAOvdn6XKPOMNn6AjuYvZvPXRRJffN3po5GXe1Yh1-m0hisMK_w@mail.gmail.com>
	<CC8273A0.4C9DD%keir@xen.org>
	<50605E9A020000780009D486@nat28.tlf.novell.com>
	<CAOvdn6XmB6rj3_QVU+59V8p24Y5G47AWxVEM=id02JWXkuhibQ@mail.gmail.com>
	<5060640B020000780009D4D2@nat28.tlf.novell.com>
	<CAOvdn6XLy8zR2rb2MEyi2aT9LQiFvFLY_H02p181mTsVLVTZkw@mail.gmail.com>
	<20120924122203.GG8912@reaktio.net>
	<CAOvdn6XV4eoA-FfFns1xhx7HCUqXc7KHxZwyKuT4FHG8s3R5RQ@mail.gmail.com>
	<CAAnFQG9PLQjdh6Ab6=Y5ZGM1s4nGdLekKU=pcKNMxt4rmt_RKA@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAAnFQG9PLQjdh6Ab6=Y5ZGM1s4nGdLekKU=pcKNMxt4rmt_RKA@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: Keir Fraser <keir@xen.org>, john.baboval@citrix.com,
	xen-devel <xen-devel@lists.xen.org>, Ben Guthro <ben@guthro.net>,
	Jan Beulich <JBeulich@suse.com>, Thomas Goetz <thomas.goetz@citrix.com>
Subject: Re: [Xen-devel] Xen4.2 S3 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 Mon, Sep 24, 2012 at 02:37:22PM +0200, Javier Marcet wrote:
> On Mon, Sep 24, 2012 at 2:27 PM, Ben Guthro <ben@guthro.net> wrote:
> 
> Hi Ben,
> 
> >> >    I see - Konrad - do you have a changeset I can look for with the
> >> > features
> >> >    Jan describes?
> >>
> >> xen-acpi-processor driver was merged to upstream Linux kernel v3.4.
> >>
> >
> > I see - so the advanced methods are not being used then

You mean with the v3.5 kernel? I would think they would be used..

> > This same kernel does work with Xen-4.0.x though. Is there an assumption in
> > the code that ties Xen-4.2 to a newer kernel?
> 
> I'm being bitten by this bug with a 3.5 kernel and Xen 4.2

Huh? How so?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 24 14:17:19 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Sep 2012 14:17: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 1TG9TC-0002y9-GR; Mon, 24 Sep 2012 14:17:10 +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 1TG9TB-0002xs-A5
	for xen-devel@lists.xen.org; Mon, 24 Sep 2012 14:17:09 +0000
Received: from [85.158.143.35:21594] by server-2.bemta-4.messagelabs.com id
	F0/99-06610-46B60605; Mon, 24 Sep 2012 14:17:08 +0000
X-Env-Sender: ben.guthro@gmail.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1348496212!18255608!1
X-Originating-IP: [209.85.223.173]
X-SpamReason: No, hits=0.9 required=7.0 tests=HTML_40_50,HTML_MESSAGE,
	RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31460 invoked from network); 24 Sep 2012 14:16:59 -0000
Received: from mail-ie0-f173.google.com (HELO mail-ie0-f173.google.com)
	(209.85.223.173)
	by server-13.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Sep 2012 14:16:59 -0000
Received: by iea17 with SMTP id 17so8002901iea.32
	for <xen-devel@lists.xen.org>; Mon, 24 Sep 2012 07:16:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
	bh=sWVzcZzS+PRcmRvZ4NXijPfHZeP8liQGJPtTMt2EbdU=;
	b=PZgPzQj+rFFqCJFcW1hmrGsbAP2+XAwqkwqEGKvLUcsIqPnWxqDyHEas+cKS4PQ6Mv
	LkFf1YCbRABEcai4smimz6UkE8MfXBGBHrOk6FPAl6MCe+Wlt5f0qonqQrfvMqHdGozq
	k8u+3Qbt5yYGCsBmsb0KOpUFidR/NzwF2Rls0FkyiKkQYY/9s66osdMv2ejAhFI7LysP
	BsT67mzn3/xEtuyWHrxKzExH32oR59W75hwPcyGle5alKunUOWlHWpBbqINVlTBWxLhq
	bQgTHuGXhJ2m/lo6z29o5alpZ/NnXLF/MhoKI3paC7Wyu7dNbIGBOKBx4XYlFCuhssvk
	mfUA==
MIME-Version: 1.0
Received: by 10.50.77.138 with SMTP id s10mr5287237igw.70.1348496212302; Mon,
	24 Sep 2012 07:16:52 -0700 (PDT)
Received: by 10.64.55.132 with HTTP; Mon, 24 Sep 2012 07:16:52 -0700 (PDT)
In-Reply-To: <506085FF020000780009D5F9@nat28.tlf.novell.com>
References: <CAOvdn6XKPOMNn6AjuYvZvPXRRJffN3po5GXe1Yh1-m0hisMK_w@mail.gmail.com>
	<CC8273A0.4C9DD%keir@xen.org>
	<50605E9A020000780009D486@nat28.tlf.novell.com>
	<CAOvdn6XmB6rj3_QVU+59V8p24Y5G47AWxVEM=id02JWXkuhibQ@mail.gmail.com>
	<5060640B020000780009D4D2@nat28.tlf.novell.com>
	<CAOvdn6XLy8zR2rb2MEyi2aT9LQiFvFLY_H02p181mTsVLVTZkw@mail.gmail.com>
	<506068A0020000780009D519@nat28.tlf.novell.com>
	<CAOvdn6Undn2srfNhW++wLfUNFQ5JnZ3rp5bg7DD_TDPCHqmP_A@mail.gmail.com>
	<50606F18020000780009D57B@nat28.tlf.novell.com>
	<CAOvdn6UMHmPWqedYE9GQQMDaM4oiHLDSn9ZzSgJjGf89g1DgTw@mail.gmail.com>
	<50607D70020000780009D5C3@nat28.tlf.novell.com>
	<CAOvdn6XL9ebp2oUV0XEXk_WdU3-=YAj+xfz6AMLDBpVThH3Xvw@mail.gmail.com>
	<506085FF020000780009D5F9@nat28.tlf.novell.com>
Date: Mon, 24 Sep 2012 10:16:52 -0400
X-Google-Sender-Auth: MtrQ6TuHDowv_TwDZpO0e7t2dy8
Message-ID: <CAOvdn6XYt9vf_Ct0w71x6PHQzOHCaTX6Bi-HeZszRzxpKcRYRg@mail.gmail.com>
From: Ben Guthro <ben@guthro.net>
To: Jan Beulich <JBeulich@suse.com>
Cc: Keir Fraser <keir@xen.org>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen4.2 S3 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: multipart/mixed; boundary="===============1726315368148292286=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============1726315368148292286==
Content-Type: multipart/alternative; boundary=e89a8f3ba95bb71d5704ca733d98

--e89a8f3ba95bb71d5704ca733d98
Content-Type: text/plain; charset=ISO-8859-1

Would you prefer a separate [PATCH] email for this fix, or will you apply
it as-is?



On Mon, Sep 24, 2012 at 10:10 AM, Jan Beulich <JBeulich@suse.com> wrote:

> >>> On 24.09.12 at 15:56, Ben Guthro <ben@guthro.net> wrote:
> > On Mon, Sep 24, 2012 at 9:34 AM, Jan Beulich <JBeulich@suse.com> wrote:
> >> ...; the interesting ones are
> >> - at the end of xen/arch/x86/acpu/cpu_idle.c:acpi_dead_idle()
> >> - xen/arch/x86/domain.c:default_dead_idle()
> >
> >
> > Thanks! This fixes the issue on this machine!
>
> Hooray!
>
> > Is this a reasonable long-term solution - or are there reasons not to
> > call wbinvd() here?
>
> That's a perfectly valid adjustment (see my earlier reply where
> I originally suggested it and explained why it may be necessary).
>
> Jan
>
>

--e89a8f3ba95bb71d5704ca733d98
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Would you prefer a separate [PATCH] email for this fix, or will you apply i=
t as-is?<div><br></div><div><br><br><div class=3D"gmail_quote">On Mon, Sep =
24, 2012 at 10:10 AM, Jan Beulich <span dir=3D"ltr">&lt;<a href=3D"mailto:J=
Beulich@suse.com" target=3D"_blank">JBeulich@suse.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 24.09.12 a=
t 15:56, Ben Guthro &lt;<a href=3D"mailto:ben@guthro.net">ben@guthro.net</a=
>&gt; wrote:<br>

&gt; On Mon, Sep 24, 2012 at 9:34 AM, Jan Beulich &lt;<a href=3D"mailto:JBe=
ulich@suse.com">JBeulich@suse.com</a>&gt; wrote:<br>
</div>&gt;&gt; ...; the interesting ones are<br>
<div class=3D"im">&gt;&gt; - at the end of xen/arch/x86/acpu/cpu_idle.c:acp=
i_dead_idle()<br>
&gt;&gt; - xen/arch/x86/domain.c:default_dead_idle()<br>
&gt;<br>
&gt;<br>
&gt; Thanks! This fixes the issue on this machine!<br>
<br>
</div>Hooray!<br>
<div class=3D"im"><br>
&gt; Is this a reasonable long-term solution - or are there reasons not to<=
br>
&gt; call wbinvd() here?<br>
<br>
</div>That&#39;s a perfectly valid adjustment (see my earlier reply where<b=
r>
I originally suggested it and explained why it may be necessary).<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
Jan<br>
<br>
</font></span></blockquote></div><br></div>

--e89a8f3ba95bb71d5704ca733d98--


--===============1726315368148292286==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============1726315368148292286==--


From xen-devel-bounces@lists.xen.org Mon Sep 24 14:17:19 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Sep 2012 14:17: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 1TG9TC-0002y9-GR; Mon, 24 Sep 2012 14:17:10 +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 1TG9TB-0002xs-A5
	for xen-devel@lists.xen.org; Mon, 24 Sep 2012 14:17:09 +0000
Received: from [85.158.143.35:21594] by server-2.bemta-4.messagelabs.com id
	F0/99-06610-46B60605; Mon, 24 Sep 2012 14:17:08 +0000
X-Env-Sender: ben.guthro@gmail.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1348496212!18255608!1
X-Originating-IP: [209.85.223.173]
X-SpamReason: No, hits=0.9 required=7.0 tests=HTML_40_50,HTML_MESSAGE,
	RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31460 invoked from network); 24 Sep 2012 14:16:59 -0000
Received: from mail-ie0-f173.google.com (HELO mail-ie0-f173.google.com)
	(209.85.223.173)
	by server-13.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Sep 2012 14:16:59 -0000
Received: by iea17 with SMTP id 17so8002901iea.32
	for <xen-devel@lists.xen.org>; Mon, 24 Sep 2012 07:16:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
	bh=sWVzcZzS+PRcmRvZ4NXijPfHZeP8liQGJPtTMt2EbdU=;
	b=PZgPzQj+rFFqCJFcW1hmrGsbAP2+XAwqkwqEGKvLUcsIqPnWxqDyHEas+cKS4PQ6Mv
	LkFf1YCbRABEcai4smimz6UkE8MfXBGBHrOk6FPAl6MCe+Wlt5f0qonqQrfvMqHdGozq
	k8u+3Qbt5yYGCsBmsb0KOpUFidR/NzwF2Rls0FkyiKkQYY/9s66osdMv2ejAhFI7LysP
	BsT67mzn3/xEtuyWHrxKzExH32oR59W75hwPcyGle5alKunUOWlHWpBbqINVlTBWxLhq
	bQgTHuGXhJ2m/lo6z29o5alpZ/NnXLF/MhoKI3paC7Wyu7dNbIGBOKBx4XYlFCuhssvk
	mfUA==
MIME-Version: 1.0
Received: by 10.50.77.138 with SMTP id s10mr5287237igw.70.1348496212302; Mon,
	24 Sep 2012 07:16:52 -0700 (PDT)
Received: by 10.64.55.132 with HTTP; Mon, 24 Sep 2012 07:16:52 -0700 (PDT)
In-Reply-To: <506085FF020000780009D5F9@nat28.tlf.novell.com>
References: <CAOvdn6XKPOMNn6AjuYvZvPXRRJffN3po5GXe1Yh1-m0hisMK_w@mail.gmail.com>
	<CC8273A0.4C9DD%keir@xen.org>
	<50605E9A020000780009D486@nat28.tlf.novell.com>
	<CAOvdn6XmB6rj3_QVU+59V8p24Y5G47AWxVEM=id02JWXkuhibQ@mail.gmail.com>
	<5060640B020000780009D4D2@nat28.tlf.novell.com>
	<CAOvdn6XLy8zR2rb2MEyi2aT9LQiFvFLY_H02p181mTsVLVTZkw@mail.gmail.com>
	<506068A0020000780009D519@nat28.tlf.novell.com>
	<CAOvdn6Undn2srfNhW++wLfUNFQ5JnZ3rp5bg7DD_TDPCHqmP_A@mail.gmail.com>
	<50606F18020000780009D57B@nat28.tlf.novell.com>
	<CAOvdn6UMHmPWqedYE9GQQMDaM4oiHLDSn9ZzSgJjGf89g1DgTw@mail.gmail.com>
	<50607D70020000780009D5C3@nat28.tlf.novell.com>
	<CAOvdn6XL9ebp2oUV0XEXk_WdU3-=YAj+xfz6AMLDBpVThH3Xvw@mail.gmail.com>
	<506085FF020000780009D5F9@nat28.tlf.novell.com>
Date: Mon, 24 Sep 2012 10:16:52 -0400
X-Google-Sender-Auth: MtrQ6TuHDowv_TwDZpO0e7t2dy8
Message-ID: <CAOvdn6XYt9vf_Ct0w71x6PHQzOHCaTX6Bi-HeZszRzxpKcRYRg@mail.gmail.com>
From: Ben Guthro <ben@guthro.net>
To: Jan Beulich <JBeulich@suse.com>
Cc: Keir Fraser <keir@xen.org>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen4.2 S3 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: multipart/mixed; boundary="===============1726315368148292286=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============1726315368148292286==
Content-Type: multipart/alternative; boundary=e89a8f3ba95bb71d5704ca733d98

--e89a8f3ba95bb71d5704ca733d98
Content-Type: text/plain; charset=ISO-8859-1

Would you prefer a separate [PATCH] email for this fix, or will you apply
it as-is?



On Mon, Sep 24, 2012 at 10:10 AM, Jan Beulich <JBeulich@suse.com> wrote:

> >>> On 24.09.12 at 15:56, Ben Guthro <ben@guthro.net> wrote:
> > On Mon, Sep 24, 2012 at 9:34 AM, Jan Beulich <JBeulich@suse.com> wrote:
> >> ...; the interesting ones are
> >> - at the end of xen/arch/x86/acpu/cpu_idle.c:acpi_dead_idle()
> >> - xen/arch/x86/domain.c:default_dead_idle()
> >
> >
> > Thanks! This fixes the issue on this machine!
>
> Hooray!
>
> > Is this a reasonable long-term solution - or are there reasons not to
> > call wbinvd() here?
>
> That's a perfectly valid adjustment (see my earlier reply where
> I originally suggested it and explained why it may be necessary).
>
> Jan
>
>

--e89a8f3ba95bb71d5704ca733d98
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Would you prefer a separate [PATCH] email for this fix, or will you apply i=
t as-is?<div><br></div><div><br><br><div class=3D"gmail_quote">On Mon, Sep =
24, 2012 at 10:10 AM, Jan Beulich <span dir=3D"ltr">&lt;<a href=3D"mailto:J=
Beulich@suse.com" target=3D"_blank">JBeulich@suse.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 24.09.12 a=
t 15:56, Ben Guthro &lt;<a href=3D"mailto:ben@guthro.net">ben@guthro.net</a=
>&gt; wrote:<br>

&gt; On Mon, Sep 24, 2012 at 9:34 AM, Jan Beulich &lt;<a href=3D"mailto:JBe=
ulich@suse.com">JBeulich@suse.com</a>&gt; wrote:<br>
</div>&gt;&gt; ...; the interesting ones are<br>
<div class=3D"im">&gt;&gt; - at the end of xen/arch/x86/acpu/cpu_idle.c:acp=
i_dead_idle()<br>
&gt;&gt; - xen/arch/x86/domain.c:default_dead_idle()<br>
&gt;<br>
&gt;<br>
&gt; Thanks! This fixes the issue on this machine!<br>
<br>
</div>Hooray!<br>
<div class=3D"im"><br>
&gt; Is this a reasonable long-term solution - or are there reasons not to<=
br>
&gt; call wbinvd() here?<br>
<br>
</div>That&#39;s a perfectly valid adjustment (see my earlier reply where<b=
r>
I originally suggested it and explained why it may be necessary).<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
Jan<br>
<br>
</font></span></blockquote></div><br></div>

--e89a8f3ba95bb71d5704ca733d98--


--===============1726315368148292286==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============1726315368148292286==--


From xen-devel-bounces@lists.xen.org Mon Sep 24 14:25:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Sep 2012 14:25:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TG9b0-0003JI-G4; Mon, 24 Sep 2012 14:25:14 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1TG9az-0003JD-Bh
	for Xen-devel@lists.xensource.com; Mon, 24 Sep 2012 14:25:13 +0000
Received: from [85.158.139.83:10929] by server-14.bemta-5.messagelabs.com id
	1A/CE-05772-84D60605; Mon, 24 Sep 2012 14:25:12 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1348496709!31346631!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTA4NDk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5664 invoked from network); 24 Sep 2012 14:25:11 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Sep 2012 14:25:11 -0000
X-IronPort-AV: E=Sophos;i="4.80,476,1344211200"; d="scan'208";a="14726590"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Sep 2012 14:25:08 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Mon, 24 Sep 2012 15:25:08 +0100
Date: Mon, 24 Sep 2012 15:24:16 +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: <20120921122123.33489ce1@mantra.us.oracle.com>
Message-ID: <alpine.DEB.2.02.1209241504410.29232@kaball.uk.xensource.com>
References: <20120921122123.33489ce1@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>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH v1 7/8]: PVH privcmd changes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 21 Sep 2012, Mukesh Rathor wrote:
> ---
>  drivers/xen/privcmd.c |   77 ++++++++++++++++++++++++++++++++++++++++++++----
>  1 files changed, 70 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/xen/privcmd.c b/drivers/xen/privcmd.c
> index ccee0f1..195d89f 100644
> --- a/drivers/xen/privcmd.c
> +++ b/drivers/xen/privcmd.c
> @@ -33,6 +33,7 @@
>  #include <xen/features.h>
>  #include <xen/page.h>
>  #include <xen/xen-ops.h>
> +#include <xen/balloon.h>
>  
>  #include "privcmd.h"
>  
> @@ -178,7 +179,7 @@ static int mmap_mfn_range(void *data, void *state)
>  					msg->va & PAGE_MASK,
>  					msg->mfn, msg->npages,
>  					vma->vm_page_prot,
> -					st->domain);
> +					st->domain, NULL);
>  	if (rc < 0)
>  		return rc;
>  
> @@ -199,6 +200,10 @@ static long privcmd_ioctl_mmap(void __user *udata)
>  	if (!xen_initial_domain())
>  		return -EPERM;
>  
> +	/* PVH: TBD/FIXME. For now we only support privcmd_ioctl_mmap_batch */
> +	if (xen_pv_domain() && xen_feature(XENFEAT_auto_translated_physmap))
> +		return -ENOSYS;
> +
>  	if (copy_from_user(&mmapcmd, udata, sizeof(mmapcmd)))
>  		return -EFAULT;
>  
> @@ -251,13 +256,18 @@ struct mmap_batch_state {
>  	xen_pfn_t __user *user;
>  };
>  
> +/* PVH dom0 fyi: if domU being created is PV, then mfn is mfn(addr on bus). If 
> + * it's PVH then mfn is pfn (input to HAP). */
>  static int mmap_batch_fn(void *data, void *state)
>  {
>  	xen_pfn_t *mfnp = data;
>  	struct mmap_batch_state *st = state;
> +	struct vm_area_struct *vma = st->vma;
> +	struct xen_pvh_pfn_info *pvhp = vma ? vma->vm_private_data : NULL;
>  
> -	if (xen_remap_domain_mfn_range(st->vma, st->va & PAGE_MASK, *mfnp, 1,
> -				       st->vma->vm_page_prot, st->domain) < 0) {
> +	if (xen_remap_domain_mfn_range(vma, st->va & PAGE_MASK, *mfnp, 1,
> +				       vma->vm_page_prot, st->domain, 
> +				       pvhp) < 0) {
>  		*mfnp |= 0xf0000000U;
>  		st->err++;
>  	}

I don't like that a parameter like "xen_pvh_pfn_info" has been added to
a generic arch-agnostic function like xen_remap_domain_mfn_range.

If you need to pass more parameters to xen_remap_domain_mfn_range, it
should be done in a cross-architecture way. In fact, keep in mind that
privcmd.c compiles on ARM (and IA64?) as well.

I think that in this particular case you are using pvh to actually
specify auto_translate_physmap, am I correct?
Maybe we just need to rename xen_pvh_pfn_info to xen_xlat_pfn_info.


> @@ -274,6 +284,40 @@ static int mmap_return_errors(void *data, void *state)
>  	return put_user(*mfnp, st->user++);
>  }
>  
> +/* Allocate pfns that are then mapped with gmfns from foreign domid. Update
> + * the vma with the page info to use later.
> + * Returns: 0 if success, otherwise -errno
> + */ 
> +static int pvh_privcmd_resv_pfns(struct vm_area_struct *vma, int numpgs)
> +{
> +	int rc;
> +	struct xen_pvh_pfn_info *pvhp;
> +
> +	pvhp = kzalloc(sizeof(struct xen_pvh_pfn_info), GFP_KERNEL);
> +	if (pvhp == NULL)
> +		return -ENOMEM;
> +
> +	pvhp->pi_paga = kcalloc(numpgs, sizeof(pvhp->pi_paga[0]), GFP_KERNEL);
> +	if (pvhp->pi_paga == NULL) {
> +		kfree(pvhp);
> +		return -ENOMEM;
> +	}
> +
> +	rc = alloc_xenballooned_pages(numpgs, pvhp->pi_paga, 0);
> +	if (rc != 0) {
> +		pr_warn("%s Could not alloc %d pfns rc:%d\n", __FUNCTION__, 
> +			numpgs, rc);
> +		kfree(pvhp->pi_paga);
> +		kfree(pvhp);
> +		return -ENOMEM;
> +	}
> +	pvhp->pi_num_pgs = numpgs;
> +	BUG_ON(vma->vm_private_data != (void *)1);

what?

> +	vma->vm_private_data = pvhp;
>
> +	return 0;
> +}
> +
>  static struct vm_operations_struct privcmd_vm_ops;
>  
>  static long privcmd_ioctl_mmap_batch(void __user *udata)
> @@ -315,6 +359,12 @@ static long privcmd_ioctl_mmap_batch(void __user *udata)
>  		goto out;
>  	}
>  
> +	if (xen_pv_domain() && xen_feature(XENFEAT_auto_translated_physmap)) {
> +		if ((ret=pvh_privcmd_resv_pfns(vma, m.num))) {

I would change this into:

    if ((ret = pvh_privcmd_resv_pfns(vma, m.num)) < 0) {

> +			up_write(&mm->mmap_sem);
> +			goto out;
> +		}
> +	}
>  	state.domain = m.dom;
>  	state.vma = vma;
>  	state.va = m.addr;
> @@ -365,6 +415,22 @@ static long privcmd_ioctl(struct file *file,
>  	return ret;
>  }
>  
> +static void privcmd_close(struct vm_area_struct *vma)
> +{
> +	int count;
> +	struct xen_pvh_pfn_info *pvhp = vma ? vma->vm_private_data : NULL;
> +
> +	if (!xen_pv_domain()  || !pvhp ||
> +	    !xen_feature(XENFEAT_auto_translated_physmap))
> +		return;
> +
> +	count = xen_unmap_domain_mfn_range(vma, pvhp);
> +	while (count--)
> +		free_xenballooned_pages(1, &pvhp->pi_paga[count]);
> +	kfree(pvhp->pi_paga);
> +	kfree(pvhp);

So xen_remap_domain_mfn_range adds the mappings to the vma, while
xen_unmap_domain_mfn_range does not remove them. I take that somehow
this is done by the generic Linux code that calls into this function?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 24 14:25:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Sep 2012 14:25:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TG9b0-0003JI-G4; Mon, 24 Sep 2012 14:25:14 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1TG9az-0003JD-Bh
	for Xen-devel@lists.xensource.com; Mon, 24 Sep 2012 14:25:13 +0000
Received: from [85.158.139.83:10929] by server-14.bemta-5.messagelabs.com id
	1A/CE-05772-84D60605; Mon, 24 Sep 2012 14:25:12 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1348496709!31346631!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTA4NDk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5664 invoked from network); 24 Sep 2012 14:25:11 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Sep 2012 14:25:11 -0000
X-IronPort-AV: E=Sophos;i="4.80,476,1344211200"; d="scan'208";a="14726590"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Sep 2012 14:25:08 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Mon, 24 Sep 2012 15:25:08 +0100
Date: Mon, 24 Sep 2012 15:24:16 +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: <20120921122123.33489ce1@mantra.us.oracle.com>
Message-ID: <alpine.DEB.2.02.1209241504410.29232@kaball.uk.xensource.com>
References: <20120921122123.33489ce1@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>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH v1 7/8]: PVH privcmd changes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 21 Sep 2012, Mukesh Rathor wrote:
> ---
>  drivers/xen/privcmd.c |   77 ++++++++++++++++++++++++++++++++++++++++++++----
>  1 files changed, 70 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/xen/privcmd.c b/drivers/xen/privcmd.c
> index ccee0f1..195d89f 100644
> --- a/drivers/xen/privcmd.c
> +++ b/drivers/xen/privcmd.c
> @@ -33,6 +33,7 @@
>  #include <xen/features.h>
>  #include <xen/page.h>
>  #include <xen/xen-ops.h>
> +#include <xen/balloon.h>
>  
>  #include "privcmd.h"
>  
> @@ -178,7 +179,7 @@ static int mmap_mfn_range(void *data, void *state)
>  					msg->va & PAGE_MASK,
>  					msg->mfn, msg->npages,
>  					vma->vm_page_prot,
> -					st->domain);
> +					st->domain, NULL);
>  	if (rc < 0)
>  		return rc;
>  
> @@ -199,6 +200,10 @@ static long privcmd_ioctl_mmap(void __user *udata)
>  	if (!xen_initial_domain())
>  		return -EPERM;
>  
> +	/* PVH: TBD/FIXME. For now we only support privcmd_ioctl_mmap_batch */
> +	if (xen_pv_domain() && xen_feature(XENFEAT_auto_translated_physmap))
> +		return -ENOSYS;
> +
>  	if (copy_from_user(&mmapcmd, udata, sizeof(mmapcmd)))
>  		return -EFAULT;
>  
> @@ -251,13 +256,18 @@ struct mmap_batch_state {
>  	xen_pfn_t __user *user;
>  };
>  
> +/* PVH dom0 fyi: if domU being created is PV, then mfn is mfn(addr on bus). If 
> + * it's PVH then mfn is pfn (input to HAP). */
>  static int mmap_batch_fn(void *data, void *state)
>  {
>  	xen_pfn_t *mfnp = data;
>  	struct mmap_batch_state *st = state;
> +	struct vm_area_struct *vma = st->vma;
> +	struct xen_pvh_pfn_info *pvhp = vma ? vma->vm_private_data : NULL;
>  
> -	if (xen_remap_domain_mfn_range(st->vma, st->va & PAGE_MASK, *mfnp, 1,
> -				       st->vma->vm_page_prot, st->domain) < 0) {
> +	if (xen_remap_domain_mfn_range(vma, st->va & PAGE_MASK, *mfnp, 1,
> +				       vma->vm_page_prot, st->domain, 
> +				       pvhp) < 0) {
>  		*mfnp |= 0xf0000000U;
>  		st->err++;
>  	}

I don't like that a parameter like "xen_pvh_pfn_info" has been added to
a generic arch-agnostic function like xen_remap_domain_mfn_range.

If you need to pass more parameters to xen_remap_domain_mfn_range, it
should be done in a cross-architecture way. In fact, keep in mind that
privcmd.c compiles on ARM (and IA64?) as well.

I think that in this particular case you are using pvh to actually
specify auto_translate_physmap, am I correct?
Maybe we just need to rename xen_pvh_pfn_info to xen_xlat_pfn_info.


> @@ -274,6 +284,40 @@ static int mmap_return_errors(void *data, void *state)
>  	return put_user(*mfnp, st->user++);
>  }
>  
> +/* Allocate pfns that are then mapped with gmfns from foreign domid. Update
> + * the vma with the page info to use later.
> + * Returns: 0 if success, otherwise -errno
> + */ 
> +static int pvh_privcmd_resv_pfns(struct vm_area_struct *vma, int numpgs)
> +{
> +	int rc;
> +	struct xen_pvh_pfn_info *pvhp;
> +
> +	pvhp = kzalloc(sizeof(struct xen_pvh_pfn_info), GFP_KERNEL);
> +	if (pvhp == NULL)
> +		return -ENOMEM;
> +
> +	pvhp->pi_paga = kcalloc(numpgs, sizeof(pvhp->pi_paga[0]), GFP_KERNEL);
> +	if (pvhp->pi_paga == NULL) {
> +		kfree(pvhp);
> +		return -ENOMEM;
> +	}
> +
> +	rc = alloc_xenballooned_pages(numpgs, pvhp->pi_paga, 0);
> +	if (rc != 0) {
> +		pr_warn("%s Could not alloc %d pfns rc:%d\n", __FUNCTION__, 
> +			numpgs, rc);
> +		kfree(pvhp->pi_paga);
> +		kfree(pvhp);
> +		return -ENOMEM;
> +	}
> +	pvhp->pi_num_pgs = numpgs;
> +	BUG_ON(vma->vm_private_data != (void *)1);

what?

> +	vma->vm_private_data = pvhp;
>
> +	return 0;
> +}
> +
>  static struct vm_operations_struct privcmd_vm_ops;
>  
>  static long privcmd_ioctl_mmap_batch(void __user *udata)
> @@ -315,6 +359,12 @@ static long privcmd_ioctl_mmap_batch(void __user *udata)
>  		goto out;
>  	}
>  
> +	if (xen_pv_domain() && xen_feature(XENFEAT_auto_translated_physmap)) {
> +		if ((ret=pvh_privcmd_resv_pfns(vma, m.num))) {

I would change this into:

    if ((ret = pvh_privcmd_resv_pfns(vma, m.num)) < 0) {

> +			up_write(&mm->mmap_sem);
> +			goto out;
> +		}
> +	}
>  	state.domain = m.dom;
>  	state.vma = vma;
>  	state.va = m.addr;
> @@ -365,6 +415,22 @@ static long privcmd_ioctl(struct file *file,
>  	return ret;
>  }
>  
> +static void privcmd_close(struct vm_area_struct *vma)
> +{
> +	int count;
> +	struct xen_pvh_pfn_info *pvhp = vma ? vma->vm_private_data : NULL;
> +
> +	if (!xen_pv_domain()  || !pvhp ||
> +	    !xen_feature(XENFEAT_auto_translated_physmap))
> +		return;
> +
> +	count = xen_unmap_domain_mfn_range(vma, pvhp);
> +	while (count--)
> +		free_xenballooned_pages(1, &pvhp->pi_paga[count]);
> +	kfree(pvhp->pi_paga);
> +	kfree(pvhp);

So xen_remap_domain_mfn_range adds the mappings to the vma, while
xen_unmap_domain_mfn_range does not remove them. I take that somehow
this is done by the generic Linux code that calls into this function?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 24 14:28:56 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Sep 2012 14:28:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TG9eO-0003Sg-8c; Mon, 24 Sep 2012 14:28: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 1TG9eM-0003SY-Kq
	for xen-devel@lists.xen.org; Mon, 24 Sep 2012 14:28:42 +0000
Received: from [85.158.143.99:20747] by server-1.bemta-4.messagelabs.com id
	3A/11-05684-91E60605; Mon, 24 Sep 2012 14:28:41 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1348496917!30971395!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29099 invoked from network); 24 Sep 2012 14:28:37 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-3.tower-216.messagelabs.com with SMTP;
	24 Sep 2012 14:28:37 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 24 Sep 2012 15:28:37 +0100
Message-Id: <50608A32020000780009D639@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 24 Sep 2012 15:28:33 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ben Guthro" <ben@guthro.net>
References: <CAOvdn6XKPOMNn6AjuYvZvPXRRJffN3po5GXe1Yh1-m0hisMK_w@mail.gmail.com>
	<CC8273A0.4C9DD%keir@xen.org>
	<50605E9A020000780009D486@nat28.tlf.novell.com>
	<CAOvdn6XmB6rj3_QVU+59V8p24Y5G47AWxVEM=id02JWXkuhibQ@mail.gmail.com>
	<5060640B020000780009D4D2@nat28.tlf.novell.com>
	<CAOvdn6XLy8zR2rb2MEyi2aT9LQiFvFLY_H02p181mTsVLVTZkw@mail.gmail.com>
	<506068A0020000780009D519@nat28.tlf.novell.com>
	<CAOvdn6Undn2srfNhW++wLfUNFQ5JnZ3rp5bg7DD_TDPCHqmP_A@mail.gmail.com>
	<50606F18020000780009D57B@nat28.tlf.novell.com>
	<CAOvdn6UMHmPWqedYE9GQQMDaM4oiHLDSn9ZzSgJjGf89g1DgTw@mail.gmail.com>
	<50607D70020000780009D5C3@nat28.tlf.novell.com>
	<CAOvdn6XL9ebp2oUV0XEXk_WdU3-=YAj+xfz6AMLDBpVThH3Xvw@mail.gmail.com>
	<506085FF020000780009D5F9@nat28.tlf.novell.com>
	<CAOvdn6XYt9vf_Ct0w71x6PHQzOHCaTX6Bi-HeZszRzxpKcRYRg@mail.gmail.com>
In-Reply-To: <CAOvdn6XYt9vf_Ct0w71x6PHQzOHCaTX6Bi-HeZszRzxpKcRYRg@mail.gmail.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] Xen4.2 S3 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 24.09.12 at 16:16, Ben Guthro <ben@guthro.net> wrote:
> Would you prefer a separate [PATCH] email for this fix, or will you apply
> it as-is?

I'll put something together - the most important thing here obviously
is having a proper description. Plus I'd like to slightly extend this and
have acpi_dead_idle() actually use default_dead_idle(), just to have
things consolidated in one place. I assume I can put your S-o-b on
what you sent...

Jan

> On Mon, Sep 24, 2012 at 10:10 AM, Jan Beulich <JBeulich@suse.com> wrote:
> 
>> >>> On 24.09.12 at 15:56, Ben Guthro <ben@guthro.net> wrote:
>> > On Mon, Sep 24, 2012 at 9:34 AM, Jan Beulich <JBeulich@suse.com> wrote:
>> >> ...; the interesting ones are
>> >> - at the end of xen/arch/x86/acpu/cpu_idle.c:acpi_dead_idle()
>> >> - xen/arch/x86/domain.c:default_dead_idle()
>> >
>> >
>> > Thanks! This fixes the issue on this machine!
>>
>> Hooray!
>>
>> > Is this a reasonable long-term solution - or are there reasons not to
>> > call wbinvd() here?
>>
>> That's a perfectly valid adjustment (see my earlier reply where
>> I originally suggested it and explained why it may be necessary).
>>
>> Jan
>>
>>




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 24 14:28:56 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Sep 2012 14:28:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TG9eO-0003Sg-8c; Mon, 24 Sep 2012 14:28: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 1TG9eM-0003SY-Kq
	for xen-devel@lists.xen.org; Mon, 24 Sep 2012 14:28:42 +0000
Received: from [85.158.143.99:20747] by server-1.bemta-4.messagelabs.com id
	3A/11-05684-91E60605; Mon, 24 Sep 2012 14:28:41 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1348496917!30971395!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29099 invoked from network); 24 Sep 2012 14:28:37 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-3.tower-216.messagelabs.com with SMTP;
	24 Sep 2012 14:28:37 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 24 Sep 2012 15:28:37 +0100
Message-Id: <50608A32020000780009D639@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 24 Sep 2012 15:28:33 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ben Guthro" <ben@guthro.net>
References: <CAOvdn6XKPOMNn6AjuYvZvPXRRJffN3po5GXe1Yh1-m0hisMK_w@mail.gmail.com>
	<CC8273A0.4C9DD%keir@xen.org>
	<50605E9A020000780009D486@nat28.tlf.novell.com>
	<CAOvdn6XmB6rj3_QVU+59V8p24Y5G47AWxVEM=id02JWXkuhibQ@mail.gmail.com>
	<5060640B020000780009D4D2@nat28.tlf.novell.com>
	<CAOvdn6XLy8zR2rb2MEyi2aT9LQiFvFLY_H02p181mTsVLVTZkw@mail.gmail.com>
	<506068A0020000780009D519@nat28.tlf.novell.com>
	<CAOvdn6Undn2srfNhW++wLfUNFQ5JnZ3rp5bg7DD_TDPCHqmP_A@mail.gmail.com>
	<50606F18020000780009D57B@nat28.tlf.novell.com>
	<CAOvdn6UMHmPWqedYE9GQQMDaM4oiHLDSn9ZzSgJjGf89g1DgTw@mail.gmail.com>
	<50607D70020000780009D5C3@nat28.tlf.novell.com>
	<CAOvdn6XL9ebp2oUV0XEXk_WdU3-=YAj+xfz6AMLDBpVThH3Xvw@mail.gmail.com>
	<506085FF020000780009D5F9@nat28.tlf.novell.com>
	<CAOvdn6XYt9vf_Ct0w71x6PHQzOHCaTX6Bi-HeZszRzxpKcRYRg@mail.gmail.com>
In-Reply-To: <CAOvdn6XYt9vf_Ct0w71x6PHQzOHCaTX6Bi-HeZszRzxpKcRYRg@mail.gmail.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] Xen4.2 S3 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 24.09.12 at 16:16, Ben Guthro <ben@guthro.net> wrote:
> Would you prefer a separate [PATCH] email for this fix, or will you apply
> it as-is?

I'll put something together - the most important thing here obviously
is having a proper description. Plus I'd like to slightly extend this and
have acpi_dead_idle() actually use default_dead_idle(), just to have
things consolidated in one place. I assume I can put your S-o-b on
what you sent...

Jan

> On Mon, Sep 24, 2012 at 10:10 AM, Jan Beulich <JBeulich@suse.com> wrote:
> 
>> >>> On 24.09.12 at 15:56, Ben Guthro <ben@guthro.net> wrote:
>> > On Mon, Sep 24, 2012 at 9:34 AM, Jan Beulich <JBeulich@suse.com> wrote:
>> >> ...; the interesting ones are
>> >> - at the end of xen/arch/x86/acpu/cpu_idle.c:acpi_dead_idle()
>> >> - xen/arch/x86/domain.c:default_dead_idle()
>> >
>> >
>> > Thanks! This fixes the issue on this machine!
>>
>> Hooray!
>>
>> > Is this a reasonable long-term solution - or are there reasons not to
>> > call wbinvd() here?
>>
>> That's a perfectly valid adjustment (see my earlier reply where
>> I originally suggested it and explained why it may be necessary).
>>
>> Jan
>>
>>




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 24 14:30:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Sep 2012 14:30:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TG9fa-0003Xp-Ng; Mon, 24 Sep 2012 14:29:58 +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 1TG9fZ-0003XM-Md
	for xen-devel@lists.xensource.com; Mon, 24 Sep 2012 14:29:58 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1348496990!4492513!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTA4NDk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 415 invoked from network); 24 Sep 2012 14:29:51 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Sep 2012 14:29:51 -0000
X-IronPort-AV: E=Sophos;i="4.80,476,1344211200"; d="scan'208";a="14726715"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Sep 2012 14:29: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.279.1; Mon, 24 Sep 2012 15:29: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 1TG9fS-000311-2W;
	Mon, 24 Sep 2012 14:29:50 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1TG9fR-0003qY-R0;
	Mon, 24 Sep 2012 15:29:49 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-13859-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Mon, 24 Sep 2012 15:29:49 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13859: regressions - trouble:
	blocked/broken/fail/pass
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 13859 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13859/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-qemuu-rhel6hvm-intel  5 xen-boot          fail REGR. vs. 13825
 test-amd64-i386-win-vcpus1    5 xen-boot                  fail REGR. vs. 13825
 build-amd64-pvops             2 host-install(2)         broken REGR. vs. 13825
 test-amd64-i386-xl-multivcpu  5 xen-boot         fail in 13837 REGR. vs. 13825
 test-amd64-i386-xl-win-vcpus1  5 xen-boot        fail in 13837 REGR. vs. 13825
 test-amd64-i386-xl-win7-amd64  5 xen-boot        fail in 13837 REGR. vs. 13825
 test-amd64-amd64-win          5 xen-boot         fail in 13837 REGR. vs. 13825
 test-amd64-amd64-xl-winxpsp3  5 xen-boot         fail in 13837 REGR. vs. 13825
 test-amd64-i386-pair         8 xen-boot/dst_host fail in 13837 REGR. vs. 13825
 test-amd64-i386-pair         7 xen-boot/src_host fail in 13837 REGR. vs. 13825

Tests which are failing intermittently (not blocking):
 test-amd64-i386-rhel6hvm-intel  5 xen-boot                  fail pass in 13837
 test-amd64-i386-xl-credit2    5 xen-boot                    fail pass in 13837
 test-amd64-i386-xl-multivcpu  3 host-install(3)           broken pass in 13848
 test-amd64-i386-xl-win-vcpus1  3 host-install(3)          broken pass in 13848
 test-amd64-i386-xl            3 host-install(3)           broken pass in 13848
 test-amd64-i386-xl-win7-amd64  3 host-install(3)          broken pass in 13848
 test-amd64-i386-pair          3 host-install/src_host(3)  broken pass in 13848
 test-amd64-amd64-xl-win7-amd64 12 guest-localmigrate/x10 fail in 13837 pass in 13848
 test-amd64-amd64-pv           5 xen-boot           fail in 13848 pass in 13841
 test-amd64-i386-xl-credit2    3 host-install(3)  broken in 13848 pass in 13859
 test-amd64-i386-win-vcpus1    3 host-install(3)  broken in 13848 pass in 13859

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore     fail in 13837 like 13825
 test-amd64-amd64-xl-sedf      3 host-install(3)     broken in 13837 like 13825
 test-amd64-amd64-xl-pcipt-intel  5 xen-boot      fail in 13837 REGR. vs. 13825
 test-amd64-amd64-xl-qemuu-winxpsp3 9 guest-localmigrate fail in 13837 like 13823
 test-amd64-amd64-xl-qemuu-win7-amd64 9 guest-localmigrate fail in 13837 like 13825

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf-pin  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 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-amd64-pv           1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-pcipt-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  1 xen-build-check(1)           blocked n/a
 test-amd64-amd64-win          1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 xen-build-check(1)         blocked n/a
 test-amd64-amd64-xl-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-pair         1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win      13 guest-stop            fail in 13837 never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop          fail in 13848 never pass

version targeted for testing:
 xen                  8f658b463b78
baseline version:
 xen                  d364becfb083

------------------------------------------------------------
People who touched revisions under test:
  Jan Beulich <jbeulich@suse.com>
  Keir Fraser <keir@xen.org>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            broken  
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          blocked 
 test-amd64-i386-xl                                           broken  
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemuu-win7-amd64                         blocked 
 test-amd64-amd64-xl-win7-amd64                               blocked 
 test-amd64-i386-xl-win7-amd64                                broken  
 test-amd64-i386-xl-credit2                                   fail    
 test-amd64-amd64-xl-pcipt-intel                              blocked 
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 broken  
 test-amd64-amd64-pair                                        blocked 
 test-amd64-i386-pair                                         broken  
 test-amd64-amd64-xl-sedf-pin                                 blocked 
 test-amd64-amd64-pv                                          blocked 
 test-amd64-i386-pv                                           pass    
 test-amd64-amd64-xl-sedf                                     blocked 
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                broken  
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         blocked 
 test-amd64-i386-win                                          fail    
 test-amd64-amd64-xl-win                                      blocked 
 test-amd64-amd64-xl-qemuu-winxpsp3                           blocked 
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-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.

------------------------------------------------------------
changeset:   25938:8f658b463b78
tag:         tip
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Sep 21 17:02:46 2012 +0200
    
    x86: enable VIA CPU support
    
    Newer VIA CPUs have both 64-bit and VMX support. Enable them to be
    recognized for these purposes, at once stripping off any 32-bit CPU
    only bits from the respective CPU support file, and adding 64-bit ones
    found in recent Linux.
    
    This particularly implies untying the VMX == Intel assumption in a few
    places.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   25937:32187301ecc5
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Sep 21 15:20:21 2012 +0200
    
    x86: eliminate code affecting only 64-bit-incapable CPUs
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   25936:c8873f13cec3
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Sep 21 14:25:12 2012 +0200
    
    printk: prefer %#x et at over 0x%x
    
    Performance is not an issue with printk(), so let the function do
    minimally more work and instead save a byte per affected format
    specifier.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   25935:1e6e6b49b4ac
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Sep 21 13:47:18 2012 +0200
    
    x86: introduce MWAIT-based, ACPI-less CPU idle driver
    
    This is a port of Linux'es intel-idle driver serving the same purpose.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   25934:8eab91903e71
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Sep 21 13:45:08 2012 +0200
    
    cpuidle: remove unused latency_ticks member
    
    ... and code used only for initializing it.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   25933:d364becfb083
user:        Jan Beulich <jbeulich@suse.com>
date:        Thu Sep 20 13:31:19 2012 +0200
    
    introduce guest_handle_for_field()
    
    This helper turns a field of a GUEST_HANDLE in a GUEST_HANDLE.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    
    
(qemu changes not included)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 24 14:30:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Sep 2012 14:30:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TG9fa-0003Xp-Ng; Mon, 24 Sep 2012 14:29:58 +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 1TG9fZ-0003XM-Md
	for xen-devel@lists.xensource.com; Mon, 24 Sep 2012 14:29:58 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1348496990!4492513!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTA4NDk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 415 invoked from network); 24 Sep 2012 14:29:51 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Sep 2012 14:29:51 -0000
X-IronPort-AV: E=Sophos;i="4.80,476,1344211200"; d="scan'208";a="14726715"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Sep 2012 14:29: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.279.1; Mon, 24 Sep 2012 15:29: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 1TG9fS-000311-2W;
	Mon, 24 Sep 2012 14:29:50 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1TG9fR-0003qY-R0;
	Mon, 24 Sep 2012 15:29:49 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-13859-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Mon, 24 Sep 2012 15:29:49 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13859: regressions - trouble:
	blocked/broken/fail/pass
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 13859 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13859/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-qemuu-rhel6hvm-intel  5 xen-boot          fail REGR. vs. 13825
 test-amd64-i386-win-vcpus1    5 xen-boot                  fail REGR. vs. 13825
 build-amd64-pvops             2 host-install(2)         broken REGR. vs. 13825
 test-amd64-i386-xl-multivcpu  5 xen-boot         fail in 13837 REGR. vs. 13825
 test-amd64-i386-xl-win-vcpus1  5 xen-boot        fail in 13837 REGR. vs. 13825
 test-amd64-i386-xl-win7-amd64  5 xen-boot        fail in 13837 REGR. vs. 13825
 test-amd64-amd64-win          5 xen-boot         fail in 13837 REGR. vs. 13825
 test-amd64-amd64-xl-winxpsp3  5 xen-boot         fail in 13837 REGR. vs. 13825
 test-amd64-i386-pair         8 xen-boot/dst_host fail in 13837 REGR. vs. 13825
 test-amd64-i386-pair         7 xen-boot/src_host fail in 13837 REGR. vs. 13825

Tests which are failing intermittently (not blocking):
 test-amd64-i386-rhel6hvm-intel  5 xen-boot                  fail pass in 13837
 test-amd64-i386-xl-credit2    5 xen-boot                    fail pass in 13837
 test-amd64-i386-xl-multivcpu  3 host-install(3)           broken pass in 13848
 test-amd64-i386-xl-win-vcpus1  3 host-install(3)          broken pass in 13848
 test-amd64-i386-xl            3 host-install(3)           broken pass in 13848
 test-amd64-i386-xl-win7-amd64  3 host-install(3)          broken pass in 13848
 test-amd64-i386-pair          3 host-install/src_host(3)  broken pass in 13848
 test-amd64-amd64-xl-win7-amd64 12 guest-localmigrate/x10 fail in 13837 pass in 13848
 test-amd64-amd64-pv           5 xen-boot           fail in 13848 pass in 13841
 test-amd64-i386-xl-credit2    3 host-install(3)  broken in 13848 pass in 13859
 test-amd64-i386-win-vcpus1    3 host-install(3)  broken in 13848 pass in 13859

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore     fail in 13837 like 13825
 test-amd64-amd64-xl-sedf      3 host-install(3)     broken in 13837 like 13825
 test-amd64-amd64-xl-pcipt-intel  5 xen-boot      fail in 13837 REGR. vs. 13825
 test-amd64-amd64-xl-qemuu-winxpsp3 9 guest-localmigrate fail in 13837 like 13823
 test-amd64-amd64-xl-qemuu-win7-amd64 9 guest-localmigrate fail in 13837 like 13825

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf-pin  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 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-amd64-pv           1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-pcipt-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  1 xen-build-check(1)           blocked n/a
 test-amd64-amd64-win          1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 xen-build-check(1)         blocked n/a
 test-amd64-amd64-xl-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-pair         1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win      13 guest-stop            fail in 13837 never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop          fail in 13848 never pass

version targeted for testing:
 xen                  8f658b463b78
baseline version:
 xen                  d364becfb083

------------------------------------------------------------
People who touched revisions under test:
  Jan Beulich <jbeulich@suse.com>
  Keir Fraser <keir@xen.org>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            broken  
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          blocked 
 test-amd64-i386-xl                                           broken  
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemuu-win7-amd64                         blocked 
 test-amd64-amd64-xl-win7-amd64                               blocked 
 test-amd64-i386-xl-win7-amd64                                broken  
 test-amd64-i386-xl-credit2                                   fail    
 test-amd64-amd64-xl-pcipt-intel                              blocked 
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 broken  
 test-amd64-amd64-pair                                        blocked 
 test-amd64-i386-pair                                         broken  
 test-amd64-amd64-xl-sedf-pin                                 blocked 
 test-amd64-amd64-pv                                          blocked 
 test-amd64-i386-pv                                           pass    
 test-amd64-amd64-xl-sedf                                     blocked 
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                broken  
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         blocked 
 test-amd64-i386-win                                          fail    
 test-amd64-amd64-xl-win                                      blocked 
 test-amd64-amd64-xl-qemuu-winxpsp3                           blocked 
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-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.

------------------------------------------------------------
changeset:   25938:8f658b463b78
tag:         tip
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Sep 21 17:02:46 2012 +0200
    
    x86: enable VIA CPU support
    
    Newer VIA CPUs have both 64-bit and VMX support. Enable them to be
    recognized for these purposes, at once stripping off any 32-bit CPU
    only bits from the respective CPU support file, and adding 64-bit ones
    found in recent Linux.
    
    This particularly implies untying the VMX == Intel assumption in a few
    places.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   25937:32187301ecc5
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Sep 21 15:20:21 2012 +0200
    
    x86: eliminate code affecting only 64-bit-incapable CPUs
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   25936:c8873f13cec3
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Sep 21 14:25:12 2012 +0200
    
    printk: prefer %#x et at over 0x%x
    
    Performance is not an issue with printk(), so let the function do
    minimally more work and instead save a byte per affected format
    specifier.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   25935:1e6e6b49b4ac
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Sep 21 13:47:18 2012 +0200
    
    x86: introduce MWAIT-based, ACPI-less CPU idle driver
    
    This is a port of Linux'es intel-idle driver serving the same purpose.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   25934:8eab91903e71
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Sep 21 13:45:08 2012 +0200
    
    cpuidle: remove unused latency_ticks member
    
    ... and code used only for initializing it.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   25933:d364becfb083
user:        Jan Beulich <jbeulich@suse.com>
date:        Thu Sep 20 13:31:19 2012 +0200
    
    introduce guest_handle_for_field()
    
    This helper turns a field of a GUEST_HANDLE in a GUEST_HANDLE.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    
    
(qemu changes not included)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 24 14:32:44 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Sep 2012 14:32: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 1TG9i6-0003hT-9T; Mon, 24 Sep 2012 14:32:34 +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 1TG9i4-0003hM-E6
	for xen-devel@lists.xen.org; Mon, 24 Sep 2012 14:32:32 +0000
Received: from [85.158.143.99:57068] by server-2.bemta-4.messagelabs.com id
	DB/64-06610-FFE60605; Mon, 24 Sep 2012 14:32:31 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1348497151!30972131!1
X-Originating-IP: [74.125.83.45]
X-SpamReason: No, hits=1.1 required=7.0 tests=HTML_40_50,HTML_MESSAGE,
	MIME_QP_LONG_LINE,RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12498 invoked from network); 24 Sep 2012 14:32:31 -0000
Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com)
	(74.125.83.45)
	by server-3.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Sep 2012 14:32:31 -0000
Received: by eekb47 with SMTP id b47so552997eek.32
	for <xen-devel@lists.xen.org>; Mon, 24 Sep 2012 07:32:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type;
	bh=6ftvNR9mrjpH5ewgC1t67UZiAlwKi93w5CUV9K4FaWY=;
	b=PWK2AOrtBG0KqThakWmpeLSBlM0zZp4oBdb/HcGtwsCq04A+jStBqFBC89iMIfq3I+
	YwMp544xrJ5jWpl1B/Qr3y8bSzm52nw5f/EgTAN2iwOjG04ZwGMFfwBHBt+HFez0VCLg
	0Sef5bYds3W9PVgxoFrm40eq0GsCzVLD56vRd1AFJr8OUUbcflNKVC/oALfRDSRSsfnW
	xvShghgrDzuKYEEGT8VxHEkuKOru3t5zdP7Sw1pPH1VXPSCjRY6pt6Eh2ozkyJCZaTKk
	QtHe5Yg2EDXW2qQd8HJjEr+YfQoBS25hZyNpf/tKqg/4phe67ryaF9TlgsSn2AM1anfQ
	+q6Q==
Received: by 10.14.180.65 with SMTP id i41mr14963909eem.10.1348497150878;
	Mon, 24 Sep 2012 07:32:30 -0700 (PDT)
Received: from [192.168.1.3] (host86-167-82-156.range86-167.btcentralplus.com.
	[86.167.82.156])
	by mx.google.com with ESMTPS id k41sm46655726eep.13.2012.09.24.07.32.27
	(version=SSLv3 cipher=OTHER); Mon, 24 Sep 2012 07:32:30 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.33.0.120411
Date: Mon, 24 Sep 2012 15:32:13 +0100
From: Keir Fraser <keir@xen.org>
To: Ben Guthro <ben@guthro.net>,
	Jan Beulich <JBeulich@suse.com>
Message-ID: <CC862D7D.4CB36%keir@xen.org>
Thread-Topic: [Xen-devel] Xen4.2 S3 regression?
Thread-Index: Ac2aYWMsrJeQLzhxPEyh9mja2+y0WA==
In-Reply-To: <CAOvdn6XYt9vf_Ct0w71x6PHQzOHCaTX6Bi-HeZszRzxpKcRYRg@mail.gmail.com>
Mime-version: 1.0
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen4.2 S3 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: multipart/mixed; boundary="===============6226973333905118920=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--===============6226973333905118920==
Content-type: multipart/alternative;
	boundary="B_3431345549_42957192"

> This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--B_3431345549_42957192
Content-type: text/plain;
	charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable

I would like to see it myself and Ack it. Although I think I can guess what
it does and I will be happy with it if I=B9m right. :)

 -- Keir

On 24/09/2012 15:16, "Ben Guthro" <ben@guthro.net> wrote:

> Would you prefer a separate [PATCH] email for this fix, or will you apply=
 it
> as-is?
>=20
>=20
>=20
> On Mon, Sep 24, 2012 at 10:10 AM, Jan Beulich <JBeulich@suse.com> wrote:
>>>>> >>> On 24.09.12 at 15:56, Ben Guthro <ben@guthro.net> wrote:
>>> > On Mon, Sep 24, 2012 at 9:34 AM, Jan Beulich <JBeulich@suse.com> wrot=
e:
>>>> >> ...; the interesting ones are
>>>> >> - at the end of xen/arch/x86/acpu/cpu_idle.c:acpi_dead_idle()
>>>> >> - xen/arch/x86/domain.c:default_dead_idle()
>>> >
>>> >
>>> > Thanks! This fixes the issue on this machine!
>>=20
>> Hooray!
>>=20
>>> > Is this a reasonable long-term solution - or are there reasons not to
>>> > call wbinvd() here?
>>=20
>> That's a perfectly valid adjustment (see my earlier reply where
>> I originally suggested it and explained why it may be necessary).
>>=20
>> Jan
>>=20
>=20
>=20


--B_3431345549_42957192
Content-type: text/html;
	charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable

<HTML>
<HEAD>
<TITLE>Re: [Xen-devel] Xen4.2 S3 regression?</TITLE>
</HEAD>
<BODY>
<FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN STYLE=3D'font-size:11pt=
'>I would like to see it myself and Ack it. Although I think I can guess wha=
t it does and I will be happy with it if I&#8217;m right. :)<BR>
<BR>
&nbsp;-- Keir<BR>
<BR>
On 24/09/2012 15:16, &quot;Ben Guthro&quot; &lt;<a href=3D"ben@guthro.net">be=
n@guthro.net</a>&gt; wrote:<BR>
<BR>
</SPAN></FONT><BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><=
SPAN STYLE=3D'font-size:11pt'>Would you prefer a separate [PATCH] email for th=
is fix, or will you apply it as-is?<BR>
<BR>
<BR>
<BR>
On Mon, Sep 24, 2012 at 10:10 AM, Jan Beulich &lt;<a href=3D"JBeulich@suse.co=
m">JBeulich@suse.com</a>&gt; wrote:<BR>
</SPAN></FONT><BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><=
SPAN STYLE=3D'font-size:11pt'>&gt;&gt;&gt; On 24.09.12 at 15:56, Ben Guthro &l=
t;<a href=3D"ben@guthro.net">ben@guthro.net</a>&gt; wrote:<BR>
&gt; On Mon, Sep 24, 2012 at 9:34 AM, Jan Beulich &lt;<a href=3D"JBeulich@sus=
e.com">JBeulich@suse.com</a>&gt; wrote:<BR>
&gt;&gt; ...; the interesting ones are<BR>
&gt;&gt; - at the end of xen/arch/x86/acpu/cpu_idle.c:acpi_dead_idle()<BR>
&gt;&gt; - xen/arch/x86/domain.c:default_dead_idle()<BR>
&gt;<BR>
&gt;<BR>
&gt; Thanks! This fixes the issue on this machine!<BR>
<BR>
Hooray!<BR>
<BR>
&gt; Is this a reasonable long-term solution - or are there reasons not to<=
BR>
&gt; call wbinvd() here?<BR>
<BR>
That's a perfectly valid adjustment (see my earlier reply where<BR>
I originally suggested it and explained why it may be necessary).<BR>
<FONT COLOR=3D"#888888"><BR>
Jan<BR>
<BR>
</FONT></SPAN></FONT></BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, =
Arial"><SPAN STYLE=3D'font-size:11pt'><BR>
<BR>
</SPAN></FONT></BLOCKQUOTE>
</BODY>
</HTML>


--B_3431345549_42957192--




--===============6226973333905118920==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============6226973333905118920==--




From xen-devel-bounces@lists.xen.org Mon Sep 24 14:32:44 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Sep 2012 14:32: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 1TG9i6-0003hT-9T; Mon, 24 Sep 2012 14:32:34 +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 1TG9i4-0003hM-E6
	for xen-devel@lists.xen.org; Mon, 24 Sep 2012 14:32:32 +0000
Received: from [85.158.143.99:57068] by server-2.bemta-4.messagelabs.com id
	DB/64-06610-FFE60605; Mon, 24 Sep 2012 14:32:31 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1348497151!30972131!1
X-Originating-IP: [74.125.83.45]
X-SpamReason: No, hits=1.1 required=7.0 tests=HTML_40_50,HTML_MESSAGE,
	MIME_QP_LONG_LINE,RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12498 invoked from network); 24 Sep 2012 14:32:31 -0000
Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com)
	(74.125.83.45)
	by server-3.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Sep 2012 14:32:31 -0000
Received: by eekb47 with SMTP id b47so552997eek.32
	for <xen-devel@lists.xen.org>; Mon, 24 Sep 2012 07:32:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type;
	bh=6ftvNR9mrjpH5ewgC1t67UZiAlwKi93w5CUV9K4FaWY=;
	b=PWK2AOrtBG0KqThakWmpeLSBlM0zZp4oBdb/HcGtwsCq04A+jStBqFBC89iMIfq3I+
	YwMp544xrJ5jWpl1B/Qr3y8bSzm52nw5f/EgTAN2iwOjG04ZwGMFfwBHBt+HFez0VCLg
	0Sef5bYds3W9PVgxoFrm40eq0GsCzVLD56vRd1AFJr8OUUbcflNKVC/oALfRDSRSsfnW
	xvShghgrDzuKYEEGT8VxHEkuKOru3t5zdP7Sw1pPH1VXPSCjRY6pt6Eh2ozkyJCZaTKk
	QtHe5Yg2EDXW2qQd8HJjEr+YfQoBS25hZyNpf/tKqg/4phe67ryaF9TlgsSn2AM1anfQ
	+q6Q==
Received: by 10.14.180.65 with SMTP id i41mr14963909eem.10.1348497150878;
	Mon, 24 Sep 2012 07:32:30 -0700 (PDT)
Received: from [192.168.1.3] (host86-167-82-156.range86-167.btcentralplus.com.
	[86.167.82.156])
	by mx.google.com with ESMTPS id k41sm46655726eep.13.2012.09.24.07.32.27
	(version=SSLv3 cipher=OTHER); Mon, 24 Sep 2012 07:32:30 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.33.0.120411
Date: Mon, 24 Sep 2012 15:32:13 +0100
From: Keir Fraser <keir@xen.org>
To: Ben Guthro <ben@guthro.net>,
	Jan Beulich <JBeulich@suse.com>
Message-ID: <CC862D7D.4CB36%keir@xen.org>
Thread-Topic: [Xen-devel] Xen4.2 S3 regression?
Thread-Index: Ac2aYWMsrJeQLzhxPEyh9mja2+y0WA==
In-Reply-To: <CAOvdn6XYt9vf_Ct0w71x6PHQzOHCaTX6Bi-HeZszRzxpKcRYRg@mail.gmail.com>
Mime-version: 1.0
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen4.2 S3 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: multipart/mixed; boundary="===============6226973333905118920=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--===============6226973333905118920==
Content-type: multipart/alternative;
	boundary="B_3431345549_42957192"

> This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--B_3431345549_42957192
Content-type: text/plain;
	charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable

I would like to see it myself and Ack it. Although I think I can guess what
it does and I will be happy with it if I=B9m right. :)

 -- Keir

On 24/09/2012 15:16, "Ben Guthro" <ben@guthro.net> wrote:

> Would you prefer a separate [PATCH] email for this fix, or will you apply=
 it
> as-is?
>=20
>=20
>=20
> On Mon, Sep 24, 2012 at 10:10 AM, Jan Beulich <JBeulich@suse.com> wrote:
>>>>> >>> On 24.09.12 at 15:56, Ben Guthro <ben@guthro.net> wrote:
>>> > On Mon, Sep 24, 2012 at 9:34 AM, Jan Beulich <JBeulich@suse.com> wrot=
e:
>>>> >> ...; the interesting ones are
>>>> >> - at the end of xen/arch/x86/acpu/cpu_idle.c:acpi_dead_idle()
>>>> >> - xen/arch/x86/domain.c:default_dead_idle()
>>> >
>>> >
>>> > Thanks! This fixes the issue on this machine!
>>=20
>> Hooray!
>>=20
>>> > Is this a reasonable long-term solution - or are there reasons not to
>>> > call wbinvd() here?
>>=20
>> That's a perfectly valid adjustment (see my earlier reply where
>> I originally suggested it and explained why it may be necessary).
>>=20
>> Jan
>>=20
>=20
>=20


--B_3431345549_42957192
Content-type: text/html;
	charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable

<HTML>
<HEAD>
<TITLE>Re: [Xen-devel] Xen4.2 S3 regression?</TITLE>
</HEAD>
<BODY>
<FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN STYLE=3D'font-size:11pt=
'>I would like to see it myself and Ack it. Although I think I can guess wha=
t it does and I will be happy with it if I&#8217;m right. :)<BR>
<BR>
&nbsp;-- Keir<BR>
<BR>
On 24/09/2012 15:16, &quot;Ben Guthro&quot; &lt;<a href=3D"ben@guthro.net">be=
n@guthro.net</a>&gt; wrote:<BR>
<BR>
</SPAN></FONT><BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><=
SPAN STYLE=3D'font-size:11pt'>Would you prefer a separate [PATCH] email for th=
is fix, or will you apply it as-is?<BR>
<BR>
<BR>
<BR>
On Mon, Sep 24, 2012 at 10:10 AM, Jan Beulich &lt;<a href=3D"JBeulich@suse.co=
m">JBeulich@suse.com</a>&gt; wrote:<BR>
</SPAN></FONT><BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><=
SPAN STYLE=3D'font-size:11pt'>&gt;&gt;&gt; On 24.09.12 at 15:56, Ben Guthro &l=
t;<a href=3D"ben@guthro.net">ben@guthro.net</a>&gt; wrote:<BR>
&gt; On Mon, Sep 24, 2012 at 9:34 AM, Jan Beulich &lt;<a href=3D"JBeulich@sus=
e.com">JBeulich@suse.com</a>&gt; wrote:<BR>
&gt;&gt; ...; the interesting ones are<BR>
&gt;&gt; - at the end of xen/arch/x86/acpu/cpu_idle.c:acpi_dead_idle()<BR>
&gt;&gt; - xen/arch/x86/domain.c:default_dead_idle()<BR>
&gt;<BR>
&gt;<BR>
&gt; Thanks! This fixes the issue on this machine!<BR>
<BR>
Hooray!<BR>
<BR>
&gt; Is this a reasonable long-term solution - or are there reasons not to<=
BR>
&gt; call wbinvd() here?<BR>
<BR>
That's a perfectly valid adjustment (see my earlier reply where<BR>
I originally suggested it and explained why it may be necessary).<BR>
<FONT COLOR=3D"#888888"><BR>
Jan<BR>
<BR>
</FONT></SPAN></FONT></BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, =
Arial"><SPAN STYLE=3D'font-size:11pt'><BR>
<BR>
</SPAN></FONT></BLOCKQUOTE>
</BODY>
</HTML>


--B_3431345549_42957192--




--===============6226973333905118920==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============6226973333905118920==--




From xen-devel-bounces@lists.xen.org Mon Sep 24 14:34:44 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Sep 2012 14:34:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TG9k0-0003pR-R1; Mon, 24 Sep 2012 14:34:32 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andres.lagarcavilla@gmail.com>) id 1TG9jz-0003pJ-3d
	for xen-devel@lists.xen.org; Mon, 24 Sep 2012 14:34:31 +0000
Received: from [85.158.137.99:14584] by server-7.bemta-3.messagelabs.com id
	C1/DB-32000-67F60605; Mon, 24 Sep 2012 14:34:30 +0000
X-Env-Sender: andres.lagarcavilla@gmail.com
X-Msg-Ref: server-12.tower-217.messagelabs.com!1348497267!15793098!1
X-Originating-IP: [209.85.223.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-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20144 invoked from network); 24 Sep 2012 14:34:29 -0000
Received: from mail-ie0-f173.google.com (HELO mail-ie0-f173.google.com)
	(209.85.223.173)
	by server-12.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Sep 2012 14:34:29 -0000
Received: by iea17 with SMTP id 17so8067302iea.32
	for <xen-devel@lists.xen.org>; Mon, 24 Sep 2012 07:34:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=subject:mime-version:content-type:from:in-reply-to:date:cc
	:content-transfer-encoding:message-id:references:to:x-mailer;
	bh=JgE4hp/+gxgyCIXrwy0NbKfRPOvdHJ9zat0k7dO6lBU=;
	b=s9pYCxy4mpbvIBsXCC8zOSxo6zzd9nHx+098HS8gw/V9D/DrYHuljsyqWPRSrC05C2
	01jJidXFDSxYyMKme8c2Ba7rPTMiaiK+ptUz1eMwug8oU7eHfTQq0Bx4IHo3jHT+j9gT
	5w7OmQuvo9ZZoBDw0DRecuyCoXqXSmfrVnULd7OsCSv8ckSGsEkRyU1LwwSjpuVosCFJ
	SOvlOFi596KgWILLffV0P+FXF4LvgKaISwOLAlalpU/TucZ7syGVNRN/VllYTqmI7WcY
	L7/HuxB754PndPSDDxJUdOXgrUuUUi9m0Qh5KUUqB+E4bItofe5wC6ecYsXibh16gXwG
	eFzA==
Received: by 10.50.186.229 with SMTP id fn5mr5415199igc.72.1348497267572;
	Mon, 24 Sep 2012 07:34:27 -0700 (PDT)
Received: from [192.168.7.210] ([206.223.182.18])
	by mx.google.com with ESMTPS id hz10sm5783527igc.12.2012.09.24.07.34.23
	(version=TLSv1/SSLv3 cipher=OTHER);
	Mon, 24 Sep 2012 07:34:26 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1278)
From: Andres Lagar-Cavilla <andres.lagarcavilla@gmail.com>
In-Reply-To: <mailman.13261.1348495517.1399.xen-devel@lists.xen.org>
Date: Mon, 24 Sep 2012 10:34:26 -0400
Message-Id: <4735F5D3-7B4C-448A-9B6A-2103645D1BD7@gmail.com>
References: <mailman.13261.1348495517.1399.xen-devel@lists.xen.org>
To: xen-devel@lists.xen.org
X-Mailer: Apple Mail (2.1278)
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] Patches for v3.7..
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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,
> 
> The merge window in all likehood is going to open next week (Monday, Oct 1st), and these
> are the patches I've in my tree ready to go (some of them are actually in tip and
> in Jens's tree). If you think I've missed some, please tell me what they are.
> 
> Andres Lagar-Cavilla (3):
>      xen/privcmd: add PRIVCMD_MMAPBATCH_V2 ioctl
>      xen/privcmd: Fix mmap batch ioctl error status copy back.
>      xen/gndev: Xen backend support for paged out grant targets V4.
Ack. All dependent patches also included below (Dan C, David, V, Ian C.). So, great stuff afaict.
Thanks
Andres

> 
> Attilio Rao (5):
>      x86: Remove base argument from x86_init.paging.pagetable_setup_start
>      x86: Rename pagetable_setup_start() to pagetable_init()
>      x86: Move paging_init() call to x86_init.paging.pagetable_init()
>      x86: xen: Cleanup and remove x86_init.paging.pagetable_setup_done()
>      x86: Document x86_init.paging.pagetable_init()
> 
> Dan Carpenter (1):
>      xen/privcmd: return -EFAULT on error
> 
> Daniel De Graaf (1):
>      xen/sysfs: Use XENVER_guest_handle to query UUID
> 
> David Vrabel (1):
>      xen/mm: return more precise error from xen_remap_domain_range()
> 
> Ian Campbell (1):
>      xen: resynchronise grant table status codes with upstream
> 
> Jan Beulich (2):
>      xen-pciback: support wild cards in slot specifications
>      xen/vga: add the xen EFI video mode support
> 
> Konrad Rzeszutek Wilk (31):
>      xen/perf: Define .glob for the different hypercalls.
>      xen/blkback: Fix compile warning
>      xen/p2m: Fix the comment describing the P2M tree.
>      xen/x86: Use memblock_reserve for sensitive areas.
>      xen/x86: Workaround 64-bit hypervisor and 32-bit initial domain.
>      xen/swiotlb: Simplify the logic.
>      xen/swiotlb: With more than 4GB on 64-bit, disable the native SWIOTLB.
>      swiotlb: add the late swiotlb initialization function with iotlb memory
>      xen/apic/xenbus/swiotlb/pcifront/grant/tmem: Make functions or variables static.
>      xen/swiotlb: Remove functions not needed anymore.
>      xen/swiotlb: Fix compile warnings when using plain integer instead of NULL pointer.
>      Revert "xen/x86: Workaround 64-bit hypervisor and 32-bit initial domain." and "xen/x86: Use memblock_reserve for sensitive areas."
>      xen/mmu: The xen_setup_kernel_pagetable doesn't need to return anything.
>      xen/mmu: Provide comments describing the _ka and _va aliasing issue
>      xen/mmu: use copy_page instead of memcpy.
>      xen/mmu: For 64-bit do not call xen_map_identity_early
>      xen/mmu: Recycle the Xen provided L4, L3, and L2 pages
>      xen/p2m: Add logic to revector a P2M tree to use __va leafs.
>      xen/mmu: Copy and revector the P2M tree.
>      xen/mmu: Remove from __ka space PMD entries for pagetables.
>      xen/mmu: Release just the MFN list, not MFN list and part of pagetables.
>      xen/p2m: When revectoring deal with holes in the P2M array.
>      xen/mmu: If the revector fails, don't attempt to revector anything else.
>      xen/swiotlb: Move the nr_tbl determination in its own function.
>      xen/swiotlb: Move the error strings to its own function.
>      xen/swiotlb: Use the swiotlb_late_init_with_tbl to init Xen-SWIOTLB late when PV PCI is used.
>      xen/swiotlb: For early initialization, return zero on success.
>      xen/pcifront: Use Xen-SWIOTLB when initting if required.
>      xen/swiotlb: Remove functions not needed anymore.
>      xen/swiotlb: Fix compile warnings when using plain integer instead of NULL pointer.
>      xen/x86: retrieve keyboard shift status flags from hypervisor.
> 
> Oliver Chick (1):
>      xen/blkback: Change xen_vbd's flush_support and discard_secure to have type unsigned int, rather than bool
> 
> Stefano Stabellini (7):
>      xen: update xen_add_to_physmap interface
>      xen: missing includes
>      xen/events: fix unmask_evtchn for PV on HVM guests
>      xen: clear IRQ_NOAUTOEN and IRQ_NOREQUEST
>      xen: Introduce xen_pfn_t for pfn and mfn types
>      xen: allow privcmd for HVM guests
>      xen/arm: compile and run xenbus
> 
> Wei Yongjun (1):
>      xen/blkback: use kmem_cache_zalloc instead of kmem_cache_alloc/memset


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 24 14:34:44 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Sep 2012 14:34:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TG9k0-0003pR-R1; Mon, 24 Sep 2012 14:34:32 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andres.lagarcavilla@gmail.com>) id 1TG9jz-0003pJ-3d
	for xen-devel@lists.xen.org; Mon, 24 Sep 2012 14:34:31 +0000
Received: from [85.158.137.99:14584] by server-7.bemta-3.messagelabs.com id
	C1/DB-32000-67F60605; Mon, 24 Sep 2012 14:34:30 +0000
X-Env-Sender: andres.lagarcavilla@gmail.com
X-Msg-Ref: server-12.tower-217.messagelabs.com!1348497267!15793098!1
X-Originating-IP: [209.85.223.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-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20144 invoked from network); 24 Sep 2012 14:34:29 -0000
Received: from mail-ie0-f173.google.com (HELO mail-ie0-f173.google.com)
	(209.85.223.173)
	by server-12.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Sep 2012 14:34:29 -0000
Received: by iea17 with SMTP id 17so8067302iea.32
	for <xen-devel@lists.xen.org>; Mon, 24 Sep 2012 07:34:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=subject:mime-version:content-type:from:in-reply-to:date:cc
	:content-transfer-encoding:message-id:references:to:x-mailer;
	bh=JgE4hp/+gxgyCIXrwy0NbKfRPOvdHJ9zat0k7dO6lBU=;
	b=s9pYCxy4mpbvIBsXCC8zOSxo6zzd9nHx+098HS8gw/V9D/DrYHuljsyqWPRSrC05C2
	01jJidXFDSxYyMKme8c2Ba7rPTMiaiK+ptUz1eMwug8oU7eHfTQq0Bx4IHo3jHT+j9gT
	5w7OmQuvo9ZZoBDw0DRecuyCoXqXSmfrVnULd7OsCSv8ckSGsEkRyU1LwwSjpuVosCFJ
	SOvlOFi596KgWILLffV0P+FXF4LvgKaISwOLAlalpU/TucZ7syGVNRN/VllYTqmI7WcY
	L7/HuxB754PndPSDDxJUdOXgrUuUUi9m0Qh5KUUqB+E4bItofe5wC6ecYsXibh16gXwG
	eFzA==
Received: by 10.50.186.229 with SMTP id fn5mr5415199igc.72.1348497267572;
	Mon, 24 Sep 2012 07:34:27 -0700 (PDT)
Received: from [192.168.7.210] ([206.223.182.18])
	by mx.google.com with ESMTPS id hz10sm5783527igc.12.2012.09.24.07.34.23
	(version=TLSv1/SSLv3 cipher=OTHER);
	Mon, 24 Sep 2012 07:34:26 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1278)
From: Andres Lagar-Cavilla <andres.lagarcavilla@gmail.com>
In-Reply-To: <mailman.13261.1348495517.1399.xen-devel@lists.xen.org>
Date: Mon, 24 Sep 2012 10:34:26 -0400
Message-Id: <4735F5D3-7B4C-448A-9B6A-2103645D1BD7@gmail.com>
References: <mailman.13261.1348495517.1399.xen-devel@lists.xen.org>
To: xen-devel@lists.xen.org
X-Mailer: Apple Mail (2.1278)
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] Patches for v3.7..
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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,
> 
> The merge window in all likehood is going to open next week (Monday, Oct 1st), and these
> are the patches I've in my tree ready to go (some of them are actually in tip and
> in Jens's tree). If you think I've missed some, please tell me what they are.
> 
> Andres Lagar-Cavilla (3):
>      xen/privcmd: add PRIVCMD_MMAPBATCH_V2 ioctl
>      xen/privcmd: Fix mmap batch ioctl error status copy back.
>      xen/gndev: Xen backend support for paged out grant targets V4.
Ack. All dependent patches also included below (Dan C, David, V, Ian C.). So, great stuff afaict.
Thanks
Andres

> 
> Attilio Rao (5):
>      x86: Remove base argument from x86_init.paging.pagetable_setup_start
>      x86: Rename pagetable_setup_start() to pagetable_init()
>      x86: Move paging_init() call to x86_init.paging.pagetable_init()
>      x86: xen: Cleanup and remove x86_init.paging.pagetable_setup_done()
>      x86: Document x86_init.paging.pagetable_init()
> 
> Dan Carpenter (1):
>      xen/privcmd: return -EFAULT on error
> 
> Daniel De Graaf (1):
>      xen/sysfs: Use XENVER_guest_handle to query UUID
> 
> David Vrabel (1):
>      xen/mm: return more precise error from xen_remap_domain_range()
> 
> Ian Campbell (1):
>      xen: resynchronise grant table status codes with upstream
> 
> Jan Beulich (2):
>      xen-pciback: support wild cards in slot specifications
>      xen/vga: add the xen EFI video mode support
> 
> Konrad Rzeszutek Wilk (31):
>      xen/perf: Define .glob for the different hypercalls.
>      xen/blkback: Fix compile warning
>      xen/p2m: Fix the comment describing the P2M tree.
>      xen/x86: Use memblock_reserve for sensitive areas.
>      xen/x86: Workaround 64-bit hypervisor and 32-bit initial domain.
>      xen/swiotlb: Simplify the logic.
>      xen/swiotlb: With more than 4GB on 64-bit, disable the native SWIOTLB.
>      swiotlb: add the late swiotlb initialization function with iotlb memory
>      xen/apic/xenbus/swiotlb/pcifront/grant/tmem: Make functions or variables static.
>      xen/swiotlb: Remove functions not needed anymore.
>      xen/swiotlb: Fix compile warnings when using plain integer instead of NULL pointer.
>      Revert "xen/x86: Workaround 64-bit hypervisor and 32-bit initial domain." and "xen/x86: Use memblock_reserve for sensitive areas."
>      xen/mmu: The xen_setup_kernel_pagetable doesn't need to return anything.
>      xen/mmu: Provide comments describing the _ka and _va aliasing issue
>      xen/mmu: use copy_page instead of memcpy.
>      xen/mmu: For 64-bit do not call xen_map_identity_early
>      xen/mmu: Recycle the Xen provided L4, L3, and L2 pages
>      xen/p2m: Add logic to revector a P2M tree to use __va leafs.
>      xen/mmu: Copy and revector the P2M tree.
>      xen/mmu: Remove from __ka space PMD entries for pagetables.
>      xen/mmu: Release just the MFN list, not MFN list and part of pagetables.
>      xen/p2m: When revectoring deal with holes in the P2M array.
>      xen/mmu: If the revector fails, don't attempt to revector anything else.
>      xen/swiotlb: Move the nr_tbl determination in its own function.
>      xen/swiotlb: Move the error strings to its own function.
>      xen/swiotlb: Use the swiotlb_late_init_with_tbl to init Xen-SWIOTLB late when PV PCI is used.
>      xen/swiotlb: For early initialization, return zero on success.
>      xen/pcifront: Use Xen-SWIOTLB when initting if required.
>      xen/swiotlb: Remove functions not needed anymore.
>      xen/swiotlb: Fix compile warnings when using plain integer instead of NULL pointer.
>      xen/x86: retrieve keyboard shift status flags from hypervisor.
> 
> Oliver Chick (1):
>      xen/blkback: Change xen_vbd's flush_support and discard_secure to have type unsigned int, rather than bool
> 
> Stefano Stabellini (7):
>      xen: update xen_add_to_physmap interface
>      xen: missing includes
>      xen/events: fix unmask_evtchn for PV on HVM guests
>      xen: clear IRQ_NOAUTOEN and IRQ_NOREQUEST
>      xen: Introduce xen_pfn_t for pfn and mfn types
>      xen: allow privcmd for HVM guests
>      xen/arm: compile and run xenbus
> 
> Wei Yongjun (1):
>      xen/blkback: use kmem_cache_zalloc instead of kmem_cache_alloc/memset


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 24 14:39:01 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Sep 2012 14: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 1TG9oA-00045S-IC; Mon, 24 Sep 2012 14:38:50 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andreslc@gridcentric.ca>) id 1TG9o9-00044r-Mm
	for xen-devel@lists.xen.org; Mon, 24 Sep 2012 14:38:49 +0000
Received: from [85.158.137.99:19261] by server-9.bemta-3.messagelabs.com id
	0B/B3-15390-87070605; Mon, 24 Sep 2012 14:38:48 +0000
X-Env-Sender: andreslc@gridcentric.ca
X-Msg-Ref: server-12.tower-217.messagelabs.com!1348497526!15793852!1
X-Originating-IP: [209.85.223.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32091 invoked from network); 24 Sep 2012 14:38:48 -0000
Received: from mail-ie0-f173.google.com (HELO mail-ie0-f173.google.com)
	(209.85.223.173)
	by server-12.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Sep 2012 14:38:48 -0000
Received: by iea17 with SMTP id 17so8081878iea.32
	for <xen-devel@lists.xen.org>; Mon, 24 Sep 2012 07:38:46 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=subject:mime-version:content-type:from:in-reply-to:date:cc
	:content-transfer-encoding:message-id:references:to:x-mailer
	:x-gm-message-state;
	bh=/fHRabp4wtRffk7RS3uZAqsWUCXb38Clrh1sGO+e/pc=;
	b=ktB5d25ovdJU7tU065xyGPjIDVnFW1SZ3U425qntKAvcNmc+UDoVXyEv9M4J6Pc/Yh
	vr8/MR2CnadpVHT4smu/UXSjOo0ysZ3JLDu8yoC8Lp5OaCs32XUhQovIzxcJzpBabC/3
	lQgrHyzOL46VBhL/dv+weyYR3DOgFKyMj7c76u10HobgLlW5CTfCXpmB41JJgqZ8gG7a
	17XFV313/npTpi7ArzI57CXNOdZG2SD9rbFV7LjmIC+OsZ2Wd5qQ/lYiZGuEZ5W+U5i8
	qewbTMTv3zssDBruSWI8uUnwnBIZpheurXB+lDq6WP0e7o+7XSzyDut13kLvRbfd1ap2
	KbLQ==
Received: by 10.50.170.98 with SMTP id al2mr5437541igc.47.1348497526420;
	Mon, 24 Sep 2012 07:38:46 -0700 (PDT)
Received: from [192.168.7.210] ([206.223.182.18])
	by mx.google.com with ESMTPS id n5sm11045049igw.13.2012.09.24.07.38.45
	(version=TLSv1/SSLv3 cipher=OTHER);
	Mon, 24 Sep 2012 07:38:45 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1278)
From: Andres Lagar-Cavilla <andreslc@gridcentric.ca>
In-Reply-To: <20120921204646.GB30614@phenom.dumpdata.com>
Date: Mon, 24 Sep 2012 10:38:48 -0400
Message-Id: <43E8FEC9-DE7D-4352-87F2-63FB8984D556@gridcentric.ca>
References: <1348242767-23732-1-git-send-email-oliver.chick@citrix.com>
	<20120921184123.GA27502@phenom.dumpdata.com>
	<20120921185622.GA5042@phenom.dumpdata.com>
	<20120921204646.GB30614@phenom.dumpdata.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
X-Mailer: Apple Mail (2.1278)
X-Gm-Message-State: ALoCoQkkiZNW5eUOSpeToA/tPUdnJiqhiaHdUURcMSNX5gbnOw6C0q45Qcy1vZ5rxkPfXcUj4dt1
Cc: Oliver Chick <oliver.chick@citrix.com>, linux-kernel@vger.kernel.org,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH v2] Persistent grant maps for xen blk drivers
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Sep 21, 2012, at 4:46 PM, Konrad Rzeszutek Wilk wrote:

> On Fri, Sep 21, 2012 at 02:56:22PM -0400, Konrad Rzeszutek Wilk wrote:
>>> *: With a PVHVM guest I get
>>> 
>>> [  261.927218] privcmd_fault: vma=ffff88002a31dce8 7f4edc095000-7f4edc195000, pgoff=c8, uv=00007f4edc15d000
>>> 
>>> thought if I applied your patch on top of v3.6-rc6 I didn't see the privcmd_fault but
>>> I did see the guest crash.
>> 
>> And that is due to c571898ffc24a1768e1b2dabeac0fc7dd4c14601 which I've reverted in my
>> #linux-next branch
> 
> Nevermind. Andres' patch by itself (so without yours) works just fine. There is
> something your patch and his aren't agreeing on.

Apart from interacting badly in combination, would either patch in isolation work well?

I can think of only one hunk in my patch disagreeing with blkback stuff:
diff --git a/drivers/xen/grant-table.c b/drivers/xen/grant-table.c
index eea81cf..f5681c8 100644
--- a/drivers/xen/grant-table.c
+++ b/drivers/xen/grant-table.c
@@ -836,6 +883,12 @@ int gnttab_map_refs(struct gnttab_map_grant_ref *map_ops,
 	if (ret)
 		return ret;
 
+	/* Retry eagain maps */
+	for (i = 0; i < count; i++)
+		if (map_ops[i].status == GNTST_eagain)
+			gnttab_retry_eagain_gop(GNTTABOP_map_grant_ref, map_ops + i,
+                                    &map_ops[i].status, __func__);
+
 	if (xen_feature(XENFEAT_auto_translated_physmap))
 		return ret;
 
How would you like to proceed?
Andres

> 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 24 14:39:01 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Sep 2012 14: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 1TG9oA-00045S-IC; Mon, 24 Sep 2012 14:38:50 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andreslc@gridcentric.ca>) id 1TG9o9-00044r-Mm
	for xen-devel@lists.xen.org; Mon, 24 Sep 2012 14:38:49 +0000
Received: from [85.158.137.99:19261] by server-9.bemta-3.messagelabs.com id
	0B/B3-15390-87070605; Mon, 24 Sep 2012 14:38:48 +0000
X-Env-Sender: andreslc@gridcentric.ca
X-Msg-Ref: server-12.tower-217.messagelabs.com!1348497526!15793852!1
X-Originating-IP: [209.85.223.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32091 invoked from network); 24 Sep 2012 14:38:48 -0000
Received: from mail-ie0-f173.google.com (HELO mail-ie0-f173.google.com)
	(209.85.223.173)
	by server-12.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Sep 2012 14:38:48 -0000
Received: by iea17 with SMTP id 17so8081878iea.32
	for <xen-devel@lists.xen.org>; Mon, 24 Sep 2012 07:38:46 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=subject:mime-version:content-type:from:in-reply-to:date:cc
	:content-transfer-encoding:message-id:references:to:x-mailer
	:x-gm-message-state;
	bh=/fHRabp4wtRffk7RS3uZAqsWUCXb38Clrh1sGO+e/pc=;
	b=ktB5d25ovdJU7tU065xyGPjIDVnFW1SZ3U425qntKAvcNmc+UDoVXyEv9M4J6Pc/Yh
	vr8/MR2CnadpVHT4smu/UXSjOo0ysZ3JLDu8yoC8Lp5OaCs32XUhQovIzxcJzpBabC/3
	lQgrHyzOL46VBhL/dv+weyYR3DOgFKyMj7c76u10HobgLlW5CTfCXpmB41JJgqZ8gG7a
	17XFV313/npTpi7ArzI57CXNOdZG2SD9rbFV7LjmIC+OsZ2Wd5qQ/lYiZGuEZ5W+U5i8
	qewbTMTv3zssDBruSWI8uUnwnBIZpheurXB+lDq6WP0e7o+7XSzyDut13kLvRbfd1ap2
	KbLQ==
Received: by 10.50.170.98 with SMTP id al2mr5437541igc.47.1348497526420;
	Mon, 24 Sep 2012 07:38:46 -0700 (PDT)
Received: from [192.168.7.210] ([206.223.182.18])
	by mx.google.com with ESMTPS id n5sm11045049igw.13.2012.09.24.07.38.45
	(version=TLSv1/SSLv3 cipher=OTHER);
	Mon, 24 Sep 2012 07:38:45 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1278)
From: Andres Lagar-Cavilla <andreslc@gridcentric.ca>
In-Reply-To: <20120921204646.GB30614@phenom.dumpdata.com>
Date: Mon, 24 Sep 2012 10:38:48 -0400
Message-Id: <43E8FEC9-DE7D-4352-87F2-63FB8984D556@gridcentric.ca>
References: <1348242767-23732-1-git-send-email-oliver.chick@citrix.com>
	<20120921184123.GA27502@phenom.dumpdata.com>
	<20120921185622.GA5042@phenom.dumpdata.com>
	<20120921204646.GB30614@phenom.dumpdata.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
X-Mailer: Apple Mail (2.1278)
X-Gm-Message-State: ALoCoQkkiZNW5eUOSpeToA/tPUdnJiqhiaHdUURcMSNX5gbnOw6C0q45Qcy1vZ5rxkPfXcUj4dt1
Cc: Oliver Chick <oliver.chick@citrix.com>, linux-kernel@vger.kernel.org,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH v2] Persistent grant maps for xen blk drivers
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Sep 21, 2012, at 4:46 PM, Konrad Rzeszutek Wilk wrote:

> On Fri, Sep 21, 2012 at 02:56:22PM -0400, Konrad Rzeszutek Wilk wrote:
>>> *: With a PVHVM guest I get
>>> 
>>> [  261.927218] privcmd_fault: vma=ffff88002a31dce8 7f4edc095000-7f4edc195000, pgoff=c8, uv=00007f4edc15d000
>>> 
>>> thought if I applied your patch on top of v3.6-rc6 I didn't see the privcmd_fault but
>>> I did see the guest crash.
>> 
>> And that is due to c571898ffc24a1768e1b2dabeac0fc7dd4c14601 which I've reverted in my
>> #linux-next branch
> 
> Nevermind. Andres' patch by itself (so without yours) works just fine. There is
> something your patch and his aren't agreeing on.

Apart from interacting badly in combination, would either patch in isolation work well?

I can think of only one hunk in my patch disagreeing with blkback stuff:
diff --git a/drivers/xen/grant-table.c b/drivers/xen/grant-table.c
index eea81cf..f5681c8 100644
--- a/drivers/xen/grant-table.c
+++ b/drivers/xen/grant-table.c
@@ -836,6 +883,12 @@ int gnttab_map_refs(struct gnttab_map_grant_ref *map_ops,
 	if (ret)
 		return ret;
 
+	/* Retry eagain maps */
+	for (i = 0; i < count; i++)
+		if (map_ops[i].status == GNTST_eagain)
+			gnttab_retry_eagain_gop(GNTTABOP_map_grant_ref, map_ops + i,
+                                    &map_ops[i].status, __func__);
+
 	if (xen_feature(XENFEAT_auto_translated_physmap))
 		return ret;
 
How would you like to proceed?
Andres

> 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 24 14:41:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Sep 2012 14: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 1TG9qr-0004Fd-A3; Mon, 24 Sep 2012 14:41:37 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andreslc@gridcentric.ca>) id 1TG9qq-0004FX-6b
	for xen-devel@lists.xen.org; Mon, 24 Sep 2012 14:41:36 +0000
Received: from [85.158.139.211:10441] by server-13.bemta-5.messagelabs.com id
	1A/2A-16359-F1170605; Mon, 24 Sep 2012 14:41:35 +0000
X-Env-Sender: andreslc@gridcentric.ca
X-Msg-Ref: server-2.tower-206.messagelabs.com!1348497693!19740216!1
X-Originating-IP: [209.85.223.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31738 invoked from network); 24 Sep 2012 14:41:34 -0000
Received: from mail-ie0-f173.google.com (HELO mail-ie0-f173.google.com)
	(209.85.223.173)
	by server-2.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Sep 2012 14:41:34 -0000
Received: by iea17 with SMTP id 17so8091607iea.32
	for <xen-devel@lists.xen.org>; Mon, 24 Sep 2012 07:41:33 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=subject:mime-version:content-type:from:in-reply-to:date:cc
	:content-transfer-encoding:message-id:references:to:x-mailer
	:x-gm-message-state;
	bh=VZRB3MrTbyJOwlGNBrGfHOSJ3vS90M8cx4U8QlE+UbI=;
	b=IhKx5AvZLv8VTRnQzenZEgf5elJMeV0r4YbYhCr/Bw/8f1YU9OLW+x2rvQjHcnhmru
	Qsvjpc6bhJ3C9sm6v9XAkiD2sOBLilMsOQ0RmXYLYQb6Kiz7Xo7wbwHIDmMColn6Pdqg
	E6iq5CgY5W9/UB1lKHalQPIuOpa2WSfDDDzASU8mZkW3cJHXCDabpvdoh5edzO25DwOr
	3ToamMb2E+T2qekzQsBZXuRB16NGNbei3A8gcbmuscAaBV6Vri3n3fu1Y4qgnKU+kH8I
	bYxppI2CET2mTjb+tf24ue/7ZCUORlNpSNfo9NXTkTjeemLR3Hh02/L4vNx3IQh5PLk8
	kOkA==
Received: by 10.43.97.8 with SMTP id ci8mr9809253icc.28.1348497693196;
	Mon, 24 Sep 2012 07:41:33 -0700 (PDT)
Received: from [192.168.7.210] ([206.223.182.18])
	by mx.google.com with ESMTPS id ma9sm1615882igc.17.2012.09.24.07.41.31
	(version=TLSv1/SSLv3 cipher=OTHER);
	Mon, 24 Sep 2012 07:41:31 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1278)
From: Andres Lagar-Cavilla <andreslc@gridcentric.ca>
In-Reply-To: <1348214207.26501.58.camel@zakaz.uk.xensource.com>
Date: Mon, 24 Sep 2012 10:41:32 -0400
Message-Id: <6BC390E8-3E11-4EE9-8CC9-073C25E46FCC@gridcentric.ca>
References: <E269205F-457F-4503-BB86-11C0EFA15CEC@gridcentric.ca>
	<505C2F97020000780009CDC9@nat28.tlf.novell.com>
	<1348214207.26501.58.camel@zakaz.uk.xensource.com>
To: Ian Campbell <ian.campbell@citrix.com>
X-Mailer: Apple Mail (2.1278)
X-Gm-Message-State: ALoCoQlb9AhDtvgrtbn6MNt7RkkijVYh/0U46MUy8HAz6IcmXVJKW5YtLMjUoGMHOgWSL+GS7N9Z
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Backport request: 25914:cd2a831d0a41 to
	xen-4.2-testing.hg
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Sep 21, 2012, at 3:56 AM, Ian Campbell wrote:

> On Fri, 2012-09-21 at 08:12 +0100, Jan Beulich wrote:
>>>>> On 20.09.12 at 17:23, Andres Lagar-Cavilla <andreslc@gridcentric.ca> wrote:
>>> It seems back porting has started. I would have asked for a few others, but 
>>> I've been beaten to the punch!
>> 
>> Do you realize that you Cc-ed the wrong people (neither Keir nor
>> I generally take care of tools issues).
>> 
>> Ian, Ian - can one of you take care of this?
> 
> I think we (Ian J & me) agreed that Ian J is going to continue to look
> after backport requests.

Ok, good to know. Ian J, do you think this is palatable for a back port to 4.2.1?
Thanks
Andres

> 
> Ian.
> 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 24 14:41:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Sep 2012 14: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 1TG9qr-0004Fd-A3; Mon, 24 Sep 2012 14:41:37 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andreslc@gridcentric.ca>) id 1TG9qq-0004FX-6b
	for xen-devel@lists.xen.org; Mon, 24 Sep 2012 14:41:36 +0000
Received: from [85.158.139.211:10441] by server-13.bemta-5.messagelabs.com id
	1A/2A-16359-F1170605; Mon, 24 Sep 2012 14:41:35 +0000
X-Env-Sender: andreslc@gridcentric.ca
X-Msg-Ref: server-2.tower-206.messagelabs.com!1348497693!19740216!1
X-Originating-IP: [209.85.223.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31738 invoked from network); 24 Sep 2012 14:41:34 -0000
Received: from mail-ie0-f173.google.com (HELO mail-ie0-f173.google.com)
	(209.85.223.173)
	by server-2.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Sep 2012 14:41:34 -0000
Received: by iea17 with SMTP id 17so8091607iea.32
	for <xen-devel@lists.xen.org>; Mon, 24 Sep 2012 07:41:33 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=subject:mime-version:content-type:from:in-reply-to:date:cc
	:content-transfer-encoding:message-id:references:to:x-mailer
	:x-gm-message-state;
	bh=VZRB3MrTbyJOwlGNBrGfHOSJ3vS90M8cx4U8QlE+UbI=;
	b=IhKx5AvZLv8VTRnQzenZEgf5elJMeV0r4YbYhCr/Bw/8f1YU9OLW+x2rvQjHcnhmru
	Qsvjpc6bhJ3C9sm6v9XAkiD2sOBLilMsOQ0RmXYLYQb6Kiz7Xo7wbwHIDmMColn6Pdqg
	E6iq5CgY5W9/UB1lKHalQPIuOpa2WSfDDDzASU8mZkW3cJHXCDabpvdoh5edzO25DwOr
	3ToamMb2E+T2qekzQsBZXuRB16NGNbei3A8gcbmuscAaBV6Vri3n3fu1Y4qgnKU+kH8I
	bYxppI2CET2mTjb+tf24ue/7ZCUORlNpSNfo9NXTkTjeemLR3Hh02/L4vNx3IQh5PLk8
	kOkA==
Received: by 10.43.97.8 with SMTP id ci8mr9809253icc.28.1348497693196;
	Mon, 24 Sep 2012 07:41:33 -0700 (PDT)
Received: from [192.168.7.210] ([206.223.182.18])
	by mx.google.com with ESMTPS id ma9sm1615882igc.17.2012.09.24.07.41.31
	(version=TLSv1/SSLv3 cipher=OTHER);
	Mon, 24 Sep 2012 07:41:31 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1278)
From: Andres Lagar-Cavilla <andreslc@gridcentric.ca>
In-Reply-To: <1348214207.26501.58.camel@zakaz.uk.xensource.com>
Date: Mon, 24 Sep 2012 10:41:32 -0400
Message-Id: <6BC390E8-3E11-4EE9-8CC9-073C25E46FCC@gridcentric.ca>
References: <E269205F-457F-4503-BB86-11C0EFA15CEC@gridcentric.ca>
	<505C2F97020000780009CDC9@nat28.tlf.novell.com>
	<1348214207.26501.58.camel@zakaz.uk.xensource.com>
To: Ian Campbell <ian.campbell@citrix.com>
X-Mailer: Apple Mail (2.1278)
X-Gm-Message-State: ALoCoQlb9AhDtvgrtbn6MNt7RkkijVYh/0U46MUy8HAz6IcmXVJKW5YtLMjUoGMHOgWSL+GS7N9Z
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Backport request: 25914:cd2a831d0a41 to
	xen-4.2-testing.hg
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Sep 21, 2012, at 3:56 AM, Ian Campbell wrote:

> On Fri, 2012-09-21 at 08:12 +0100, Jan Beulich wrote:
>>>>> On 20.09.12 at 17:23, Andres Lagar-Cavilla <andreslc@gridcentric.ca> wrote:
>>> It seems back porting has started. I would have asked for a few others, but 
>>> I've been beaten to the punch!
>> 
>> Do you realize that you Cc-ed the wrong people (neither Keir nor
>> I generally take care of tools issues).
>> 
>> Ian, Ian - can one of you take care of this?
> 
> I think we (Ian J & me) agreed that Ian J is going to continue to look
> after backport requests.

Ok, good to know. Ian J, do you think this is palatable for a back port to 4.2.1?
Thanks
Andres

> 
> Ian.
> 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 24 14:55:55 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Sep 2012 14:55:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGA4V-0004Sh-MW; Mon, 24 Sep 2012 14:55:43 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1TGA4U-0004Sc-2U
	for xen-devel@lists.xen.org; Mon, 24 Sep 2012 14:55:42 +0000
Received: from [85.158.139.211:17014] by server-5.bemta-5.messagelabs.com id
	A7/E0-21075-D6470605; Mon, 24 Sep 2012 14:55:41 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-12.tower-206.messagelabs.com!1348498540!18757779!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15988 invoked from network); 24 Sep 2012 14:55:40 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-12.tower-206.messagelabs.com with SMTP;
	24 Sep 2012 14:55:40 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 24 Sep 2012 15:55:39 +0100
Message-Id: <50609089020000780009D65E@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 24 Sep 2012 15:55:37 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: linux-kernel@vger.kernel.org, xen-devel <xen-devel@lists.xen.org>
Subject: [Xen-devel] [PATCH] xen-pciback: properly clean up after calling
 pcistub_device_find()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

As the function calls pcistub_device_get() before returning non-NULL,
its callers need to take care of calling pcistub_device_put() on
(mostly, but not exclusively) error paths.

Otoh, the function already guarantees that the 'dev' member is non-NULL
upon successful return, so callers do not need to check for this a
second time.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

---
 drivers/xen/xen-pciback/pci_stub.c |   46 ++++++++++++++++++-------------------
 1 file changed, 23 insertions(+), 23 deletions(-)

--- 3.6-rc7/drivers/xen/xen-pciback/pci_stub.c
+++ 3.6-rc7-xen-pciback-find-error-paths/drivers/xen/xen-pciback/pci_stub.c
@@ -681,14 +681,14 @@ static pci_ers_result_t xen_pcibk_slot_r
 		dev_err(&dev->dev, DRV_NAME " device is not connected or owned"
 			" by HVM, kill it\n");
 		kill_domain_by_device(psdev);
-		goto release;
+		goto end;
 	}
 
 	if (!test_bit(_XEN_PCIB_AERHANDLER,
 		(unsigned long *)&psdev->pdev->sh_info->flags)) {
 		dev_err(&dev->dev,
 			"guest with no AER driver should have been killed\n");
-		goto release;
+		goto end;
 	}
 	result = common_process(psdev, 1, XEN_PCI_OP_aer_slotreset, result);
 
@@ -698,9 +698,9 @@ static pci_ers_result_t xen_pcibk_slot_r
 			"No AER slot_reset service or disconnected!\n");
 		kill_domain_by_device(psdev);
 	}
-release:
-	pcistub_device_put(psdev);
 end:
+	if (psdev)
+		pcistub_device_put(psdev);
 	up_write(&pcistub_sem);
 	return result;
 
@@ -739,14 +739,14 @@ static pci_ers_result_t xen_pcibk_mmio_e
 		dev_err(&dev->dev, DRV_NAME " device is not connected or owned"
 			" by HVM, kill it\n");
 		kill_domain_by_device(psdev);
-		goto release;
+		goto end;
 	}
 
 	if (!test_bit(_XEN_PCIB_AERHANDLER,
 		(unsigned long *)&psdev->pdev->sh_info->flags)) {
 		dev_err(&dev->dev,
 			"guest with no AER driver should have been killed\n");
-		goto release;
+		goto end;
 	}
 	result = common_process(psdev, 1, XEN_PCI_OP_aer_mmio, result);
 
@@ -756,9 +756,9 @@ static pci_ers_result_t xen_pcibk_mmio_e
 			"No AER mmio_enabled service or disconnected!\n");
 		kill_domain_by_device(psdev);
 	}
-release:
-	pcistub_device_put(psdev);
 end:
+	if (psdev)
+		pcistub_device_put(psdev);
 	up_write(&pcistub_sem);
 	return result;
 }
@@ -797,7 +797,7 @@ static pci_ers_result_t xen_pcibk_error_
 		dev_err(&dev->dev, DRV_NAME " device is not connected or owned"
 			" by HVM, kill it\n");
 		kill_domain_by_device(psdev);
-		goto release;
+		goto end;
 	}
 
 	/*Guest owns the device yet no aer handler regiested, kill guest*/
@@ -805,7 +805,7 @@ static pci_ers_result_t xen_pcibk_error_
 		(unsigned long *)&psdev->pdev->sh_info->flags)) {
 		dev_dbg(&dev->dev, "guest may have no aer driver, kill it\n");
 		kill_domain_by_device(psdev);
-		goto release;
+		goto end;
 	}
 	result = common_process(psdev, error, XEN_PCI_OP_aer_detected, result);
 
@@ -815,9 +815,9 @@ static pci_ers_result_t xen_pcibk_error_
 			"No AER error_detected service or disconnected!\n");
 		kill_domain_by_device(psdev);
 	}
-release:
-	pcistub_device_put(psdev);
 end:
+	if (psdev)
+		pcistub_device_put(psdev);
 	up_write(&pcistub_sem);
 	return result;
 }
@@ -851,7 +851,7 @@ static void xen_pcibk_error_resume(struc
 		dev_err(&dev->dev, DRV_NAME " device is not connected or owned"
 			" by HVM, kill it\n");
 		kill_domain_by_device(psdev);
-		goto release;
+		goto end;
 	}
 
 	if (!test_bit(_XEN_PCIB_AERHANDLER,
@@ -859,13 +859,13 @@ static void xen_pcibk_error_resume(struc
 		dev_err(&dev->dev,
 			"guest with no AER driver should have been killed\n");
 		kill_domain_by_device(psdev);
-		goto release;
+		goto end;
 	}
 	common_process(psdev, 1, XEN_PCI_OP_aer_resume,
 		       PCI_ERS_RESULT_RECOVERED);
-release:
-	pcistub_device_put(psdev);
 end:
+	if (psdev)
+		pcistub_device_put(psdev);
 	up_write(&pcistub_sem);
 	return;
 }
@@ -987,7 +987,7 @@ static int pcistub_reg_add(int domain, i
 	struct config_field *field;
 
 	psdev = pcistub_device_find(domain, bus, slot, func);
-	if (!psdev || !psdev->dev) {
+	if (!psdev) {
 		err = -ENODEV;
 		goto out;
 	}
@@ -1011,6 +1011,8 @@ static int pcistub_reg_add(int domain, i
 	if (err)
 		kfree(field);
 out:
+	if (psdev)
+		pcistub_device_put(psdev);
 	return err;
 }
 
@@ -1115,10 +1117,9 @@ static ssize_t pcistub_irq_handler_switc
 
 	err = str_to_slot(buf, &domain, &bus, &slot, &func);
 	if (err)
-		goto out;
+		return err;
 
 	psdev = pcistub_device_find(domain, bus, slot, func);
-
 	if (!psdev)
 		goto out;
 
@@ -1134,6 +1135,8 @@ static ssize_t pcistub_irq_handler_switc
 	if (dev_data->isr_on)
 		dev_data->ack_intr = 1;
 out:
+	if (psdev)
+		pcistub_device_put(psdev);
 	if (!err)
 		err = count;
 	return err;
@@ -1221,10 +1224,7 @@ static ssize_t permissive_add(struct dev
 		err = -ENODEV;
 		goto out;
 	}
-	if (!psdev->dev) {
-		err = -ENODEV;
-		goto release;
-	}
+
 	dev_data = pci_get_drvdata(psdev->dev);
 	/* the driver data for a device should never be null at this point */
 	if (!dev_data) {



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 24 14:55:55 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Sep 2012 14:55:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGA4V-0004Sh-MW; Mon, 24 Sep 2012 14:55:43 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1TGA4U-0004Sc-2U
	for xen-devel@lists.xen.org; Mon, 24 Sep 2012 14:55:42 +0000
Received: from [85.158.139.211:17014] by server-5.bemta-5.messagelabs.com id
	A7/E0-21075-D6470605; Mon, 24 Sep 2012 14:55:41 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-12.tower-206.messagelabs.com!1348498540!18757779!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15988 invoked from network); 24 Sep 2012 14:55:40 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-12.tower-206.messagelabs.com with SMTP;
	24 Sep 2012 14:55:40 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 24 Sep 2012 15:55:39 +0100
Message-Id: <50609089020000780009D65E@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 24 Sep 2012 15:55:37 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: linux-kernel@vger.kernel.org, xen-devel <xen-devel@lists.xen.org>
Subject: [Xen-devel] [PATCH] xen-pciback: properly clean up after calling
 pcistub_device_find()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

As the function calls pcistub_device_get() before returning non-NULL,
its callers need to take care of calling pcistub_device_put() on
(mostly, but not exclusively) error paths.

Otoh, the function already guarantees that the 'dev' member is non-NULL
upon successful return, so callers do not need to check for this a
second time.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

---
 drivers/xen/xen-pciback/pci_stub.c |   46 ++++++++++++++++++-------------------
 1 file changed, 23 insertions(+), 23 deletions(-)

--- 3.6-rc7/drivers/xen/xen-pciback/pci_stub.c
+++ 3.6-rc7-xen-pciback-find-error-paths/drivers/xen/xen-pciback/pci_stub.c
@@ -681,14 +681,14 @@ static pci_ers_result_t xen_pcibk_slot_r
 		dev_err(&dev->dev, DRV_NAME " device is not connected or owned"
 			" by HVM, kill it\n");
 		kill_domain_by_device(psdev);
-		goto release;
+		goto end;
 	}
 
 	if (!test_bit(_XEN_PCIB_AERHANDLER,
 		(unsigned long *)&psdev->pdev->sh_info->flags)) {
 		dev_err(&dev->dev,
 			"guest with no AER driver should have been killed\n");
-		goto release;
+		goto end;
 	}
 	result = common_process(psdev, 1, XEN_PCI_OP_aer_slotreset, result);
 
@@ -698,9 +698,9 @@ static pci_ers_result_t xen_pcibk_slot_r
 			"No AER slot_reset service or disconnected!\n");
 		kill_domain_by_device(psdev);
 	}
-release:
-	pcistub_device_put(psdev);
 end:
+	if (psdev)
+		pcistub_device_put(psdev);
 	up_write(&pcistub_sem);
 	return result;
 
@@ -739,14 +739,14 @@ static pci_ers_result_t xen_pcibk_mmio_e
 		dev_err(&dev->dev, DRV_NAME " device is not connected or owned"
 			" by HVM, kill it\n");
 		kill_domain_by_device(psdev);
-		goto release;
+		goto end;
 	}
 
 	if (!test_bit(_XEN_PCIB_AERHANDLER,
 		(unsigned long *)&psdev->pdev->sh_info->flags)) {
 		dev_err(&dev->dev,
 			"guest with no AER driver should have been killed\n");
-		goto release;
+		goto end;
 	}
 	result = common_process(psdev, 1, XEN_PCI_OP_aer_mmio, result);
 
@@ -756,9 +756,9 @@ static pci_ers_result_t xen_pcibk_mmio_e
 			"No AER mmio_enabled service or disconnected!\n");
 		kill_domain_by_device(psdev);
 	}
-release:
-	pcistub_device_put(psdev);
 end:
+	if (psdev)
+		pcistub_device_put(psdev);
 	up_write(&pcistub_sem);
 	return result;
 }
@@ -797,7 +797,7 @@ static pci_ers_result_t xen_pcibk_error_
 		dev_err(&dev->dev, DRV_NAME " device is not connected or owned"
 			" by HVM, kill it\n");
 		kill_domain_by_device(psdev);
-		goto release;
+		goto end;
 	}
 
 	/*Guest owns the device yet no aer handler regiested, kill guest*/
@@ -805,7 +805,7 @@ static pci_ers_result_t xen_pcibk_error_
 		(unsigned long *)&psdev->pdev->sh_info->flags)) {
 		dev_dbg(&dev->dev, "guest may have no aer driver, kill it\n");
 		kill_domain_by_device(psdev);
-		goto release;
+		goto end;
 	}
 	result = common_process(psdev, error, XEN_PCI_OP_aer_detected, result);
 
@@ -815,9 +815,9 @@ static pci_ers_result_t xen_pcibk_error_
 			"No AER error_detected service or disconnected!\n");
 		kill_domain_by_device(psdev);
 	}
-release:
-	pcistub_device_put(psdev);
 end:
+	if (psdev)
+		pcistub_device_put(psdev);
 	up_write(&pcistub_sem);
 	return result;
 }
@@ -851,7 +851,7 @@ static void xen_pcibk_error_resume(struc
 		dev_err(&dev->dev, DRV_NAME " device is not connected or owned"
 			" by HVM, kill it\n");
 		kill_domain_by_device(psdev);
-		goto release;
+		goto end;
 	}
 
 	if (!test_bit(_XEN_PCIB_AERHANDLER,
@@ -859,13 +859,13 @@ static void xen_pcibk_error_resume(struc
 		dev_err(&dev->dev,
 			"guest with no AER driver should have been killed\n");
 		kill_domain_by_device(psdev);
-		goto release;
+		goto end;
 	}
 	common_process(psdev, 1, XEN_PCI_OP_aer_resume,
 		       PCI_ERS_RESULT_RECOVERED);
-release:
-	pcistub_device_put(psdev);
 end:
+	if (psdev)
+		pcistub_device_put(psdev);
 	up_write(&pcistub_sem);
 	return;
 }
@@ -987,7 +987,7 @@ static int pcistub_reg_add(int domain, i
 	struct config_field *field;
 
 	psdev = pcistub_device_find(domain, bus, slot, func);
-	if (!psdev || !psdev->dev) {
+	if (!psdev) {
 		err = -ENODEV;
 		goto out;
 	}
@@ -1011,6 +1011,8 @@ static int pcistub_reg_add(int domain, i
 	if (err)
 		kfree(field);
 out:
+	if (psdev)
+		pcistub_device_put(psdev);
 	return err;
 }
 
@@ -1115,10 +1117,9 @@ static ssize_t pcistub_irq_handler_switc
 
 	err = str_to_slot(buf, &domain, &bus, &slot, &func);
 	if (err)
-		goto out;
+		return err;
 
 	psdev = pcistub_device_find(domain, bus, slot, func);
-
 	if (!psdev)
 		goto out;
 
@@ -1134,6 +1135,8 @@ static ssize_t pcistub_irq_handler_switc
 	if (dev_data->isr_on)
 		dev_data->ack_intr = 1;
 out:
+	if (psdev)
+		pcistub_device_put(psdev);
 	if (!err)
 		err = count;
 	return err;
@@ -1221,10 +1224,7 @@ static ssize_t permissive_add(struct dev
 		err = -ENODEV;
 		goto out;
 	}
-	if (!psdev->dev) {
-		err = -ENODEV;
-		goto release;
-	}
+
 	dev_data = pci_get_drvdata(psdev->dev);
 	/* the driver data for a device should never be null at this point */
 	if (!dev_data) {



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 24 15:01:31 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Sep 2012 15:01:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGA9u-0004dY-Fn; Mon, 24 Sep 2012 15:01:18 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <arnd@arndb.de>) id 1TGA9t-0004dO-Lw
	for xen-devel@lists.xensource.com; Mon, 24 Sep 2012 15:01:17 +0000
X-Env-Sender: arnd@arndb.de
X-Msg-Ref: server-6.tower-27.messagelabs.com!1348498870!6627170!1
X-Originating-IP: [212.227.126.171]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiAyMTIuMjI3LjEyNi4xNzEgPT4gNjY2MTA=\n,sa_preprocessor: 
	QmFkIElQOiAyMTIuMjI3LjEyNi4xNzEgPT4gNjY2MTA=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11121 invoked from network); 24 Sep 2012 15:01:10 -0000
Received: from moutng.kundenserver.de (HELO moutng.kundenserver.de)
	(212.227.126.171) by server-6.tower-27.messagelabs.com with SMTP;
	24 Sep 2012 15:01:10 -0000
Received: from klappe2.localnet
	(HSI-KBW-149-172-5-253.hsi13.kabel-badenwuerttemberg.de
	[149.172.5.253])
	by mrelayeu.kundenserver.de (node=mreu2) with ESMTP (Nemesis)
	id 0MdH3n-1SzJzW3zYh-00IL38; Mon, 24 Sep 2012 17:00:58 +0200
From: Arnd Bergmann <arnd@arndb.de>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Mon, 24 Sep 2012 15:00:52 +0000
User-Agent: KMail/1.12.2 (Linux/3.5.0; KDE/4.3.2; x86_64; ; )
References: <1348483574-7901-1-git-send-email-stefano.stabellini@eu.citrix.com>
In-Reply-To: <1348483574-7901-1-git-send-email-stefano.stabellini@eu.citrix.com>
MIME-Version: 1.0
Message-Id: <201209241500.53229.arnd@arndb.de>
X-Provags-ID: V02:K0:KywjuGhwIJhHacMinUJ6ph/V3TXSz5eNVIKWmsvbtM6
	bllL136C0diKbX5YBSTY88cK4nHWGS9+poOlmpV//jfnAVF8Hy
	cNSB9Y0RgLrcbnQaNLnmuXOTthuefuxYBIU8HRW9e/VTAY4wPU
	v0HYiycWfR4QwXlyIkJ7bpBoina/UA46SVvAZy9N8f1qS525X1
	SdU4UrpBcQ+WnP422cJh8K/rVnazYoZ1tYYNUTEuwI29D/1tEX
	4GO/4kHvQOs1wmWGIgv8TQ4tcXr+Th0QqOttxPnkEQ8cnrZFTi
	yq6z6bbrwalgBb+nt21XGfEXqbrEl1jZmlisfOBblHUD5pGqg4
	2TxY4HLWgAs7Ln9HwzEA=
Cc: xen-devel@lists.xensource.com, Ian.Campbell@citrix.com, pawel.moll@arm.com,
	konrad.wilk@oracle.com, linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [Xen-devel] [PATCH v3 1/1] arm: introduce a DTS for Xen
	unprivileged virtual 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 Monday 24 September 2012, Stefano Stabellini wrote:
> Given that the xenvm machine is based on vexpress but with an extremely
> limited selection of peripherals (the guest is supposed to use virtual
> devices instead), add "xen,xenvm" to the list of compatible machines in
> mach-vexpress.
> 
> 
> Changes in v3:
> 
> - add comments to mark fields that are likely to be changed by the
> hypervisor.
> 
> 
> Changes in v2:
> 
> - remove include skeleton;
> - use #address-cells = <2> and #size-cells = <2>;
> - remove the debug bootargs;
> - use memory@80000000 instead of memory;
> - remove the ranges and interrupt-map from the motherboard node;
> - set the machine compatible to "xen,xenvm-4.2", "xen,xenvm";
> - rename the dts file to xenvm-4.2.dts;
> - add "xen,xenvm" to the list of compatible DT strings to mach-vexpress.
> 
> 
> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> Acked-by: Pawel Moll <pawel.moll@arm.com> (v2m changes)
> CC: Arnd Bergmann <arnd@arndb.de>

Acked-by: Arnd Bergmann <arnd@arndb.de>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 24 15:01:31 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Sep 2012 15:01:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGA9u-0004dY-Fn; Mon, 24 Sep 2012 15:01:18 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <arnd@arndb.de>) id 1TGA9t-0004dO-Lw
	for xen-devel@lists.xensource.com; Mon, 24 Sep 2012 15:01:17 +0000
X-Env-Sender: arnd@arndb.de
X-Msg-Ref: server-6.tower-27.messagelabs.com!1348498870!6627170!1
X-Originating-IP: [212.227.126.171]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiAyMTIuMjI3LjEyNi4xNzEgPT4gNjY2MTA=\n,sa_preprocessor: 
	QmFkIElQOiAyMTIuMjI3LjEyNi4xNzEgPT4gNjY2MTA=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11121 invoked from network); 24 Sep 2012 15:01:10 -0000
Received: from moutng.kundenserver.de (HELO moutng.kundenserver.de)
	(212.227.126.171) by server-6.tower-27.messagelabs.com with SMTP;
	24 Sep 2012 15:01:10 -0000
Received: from klappe2.localnet
	(HSI-KBW-149-172-5-253.hsi13.kabel-badenwuerttemberg.de
	[149.172.5.253])
	by mrelayeu.kundenserver.de (node=mreu2) with ESMTP (Nemesis)
	id 0MdH3n-1SzJzW3zYh-00IL38; Mon, 24 Sep 2012 17:00:58 +0200
From: Arnd Bergmann <arnd@arndb.de>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Mon, 24 Sep 2012 15:00:52 +0000
User-Agent: KMail/1.12.2 (Linux/3.5.0; KDE/4.3.2; x86_64; ; )
References: <1348483574-7901-1-git-send-email-stefano.stabellini@eu.citrix.com>
In-Reply-To: <1348483574-7901-1-git-send-email-stefano.stabellini@eu.citrix.com>
MIME-Version: 1.0
Message-Id: <201209241500.53229.arnd@arndb.de>
X-Provags-ID: V02:K0:KywjuGhwIJhHacMinUJ6ph/V3TXSz5eNVIKWmsvbtM6
	bllL136C0diKbX5YBSTY88cK4nHWGS9+poOlmpV//jfnAVF8Hy
	cNSB9Y0RgLrcbnQaNLnmuXOTthuefuxYBIU8HRW9e/VTAY4wPU
	v0HYiycWfR4QwXlyIkJ7bpBoina/UA46SVvAZy9N8f1qS525X1
	SdU4UrpBcQ+WnP422cJh8K/rVnazYoZ1tYYNUTEuwI29D/1tEX
	4GO/4kHvQOs1wmWGIgv8TQ4tcXr+Th0QqOttxPnkEQ8cnrZFTi
	yq6z6bbrwalgBb+nt21XGfEXqbrEl1jZmlisfOBblHUD5pGqg4
	2TxY4HLWgAs7Ln9HwzEA=
Cc: xen-devel@lists.xensource.com, Ian.Campbell@citrix.com, pawel.moll@arm.com,
	konrad.wilk@oracle.com, linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [Xen-devel] [PATCH v3 1/1] arm: introduce a DTS for Xen
	unprivileged virtual 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 Monday 24 September 2012, Stefano Stabellini wrote:
> Given that the xenvm machine is based on vexpress but with an extremely
> limited selection of peripherals (the guest is supposed to use virtual
> devices instead), add "xen,xenvm" to the list of compatible machines in
> mach-vexpress.
> 
> 
> Changes in v3:
> 
> - add comments to mark fields that are likely to be changed by the
> hypervisor.
> 
> 
> Changes in v2:
> 
> - remove include skeleton;
> - use #address-cells = <2> and #size-cells = <2>;
> - remove the debug bootargs;
> - use memory@80000000 instead of memory;
> - remove the ranges and interrupt-map from the motherboard node;
> - set the machine compatible to "xen,xenvm-4.2", "xen,xenvm";
> - rename the dts file to xenvm-4.2.dts;
> - add "xen,xenvm" to the list of compatible DT strings to mach-vexpress.
> 
> 
> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> Acked-by: Pawel Moll <pawel.moll@arm.com> (v2m changes)
> CC: Arnd Bergmann <arnd@arndb.de>

Acked-by: Arnd Bergmann <arnd@arndb.de>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 24 15:07:44 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Sep 2012 15:07:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGAFt-0004os-HF; Mon, 24 Sep 2012 15:07: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 1TGAFr-0004on-Mg
	for xen-devel@lists.xen.org; Mon, 24 Sep 2012 15:07:27 +0000
Received: from [85.158.139.211:20575] by server-3.bemta-5.messagelabs.com id
	61/46-16108-F2770605; Mon, 24 Sep 2012 15:07:27 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-206.messagelabs.com!1348499246!19743966!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTA4NDk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30931 invoked from network); 24 Sep 2012 15:07:26 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Sep 2012 15:07:26 -0000
X-IronPort-AV: E=Sophos;i="4.80,476,1344211200"; d="scan'208";a="14727915"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Sep 2012 15:07: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.279.1;
	Mon, 24 Sep 2012 16:07:25 +0100
Message-ID: <1348499244.3452.92.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Mon, 24 Sep 2012 16:07:24 +0100
In-Reply-To: <20576.17800.334075.677204@mariner.uk.xensource.com>
References: <1343657037-28495-1-git-send-email-ian.campbell@citrix.com>
	<1344506462.32142.96.camel@zakaz.uk.xensource.com>
	<20515.49901.369414.638893@mariner.uk.xensource.com>
	<1345215949.10161.76.camel@zakaz.uk.xensource.com>
	<20576.17800.334075.677204@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [DOCDAY PATCH] docs: initial documentation for
	xenstore paths
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2012-09-24 at 12:35 +0100, Ian Jackson wrote:
> Ian Campbell writes ("Re: [DOCDAY PATCH] docs: initial documentation for xenstore paths"):
> > On Thu, 2012-08-09 at 15:02 +0100, Ian Jackson wrote:
> > > Ian Campbell writes ("Re: [DOCDAY PATCH] docs: initial documentation for xenstore paths"):
> > > ...
> > > > > --- a/docs/misc/xenstore-paths.markdown
> > > > > +++ b/docs/misc/xenstore-paths.markdown
> > > > > @@ -0,0 +1,294 @@
> > > ...
> > > > > +PATH can contain simple regex constructs following the POSIX regexp
> > > > > +syntax described in regexp(7). In addition the following additional
> > > > > +wild card names are defined and are evaluated before regexp expansion:
> > > 
> > > Can we use a restricted perl re syntax ?  That avoids weirdness with
> > > the rules for \.
> > 
> > Is "restricted perl re syntax" a well defined thing (reference?) or do
> > you just mean perlre(1)--?
> 
> I mean pcre, or perlre(1), probably.
> 
> > What's the weirdness with \.?
> 
> In Perl syntax, a punctuation character preceded by \ is always a
> literal, and all metacharacters are unbackslashed punctuation.

Great, I think I can cope with that.

I suspect I've mostly used that syntax already anyhow.

> In regexp(7) you need to remember which of ( ) | [ ] . & $ need
> \-escaping to be literals and which need \-annotating to be
> metacharacters.  (And there are various dialects of this too; for
> example Emacs regexps require \ in front of a different subset of the
> punctuation.)

Yes, I don't think I've ever done a regexp search and replace in emacs
successfully on my first attempt.

> I don't particularly care about all the fancy (?:...) etc. extensions,
> but being able to write the regexp without referring to the manual, or
> experimenting, is very good - particularly in a document which will be
> tested at most rather indirectly.
> 
> > > > > +The process ID of the device model associated with this domain, if it
> > > > > +has one.
> > > > > +
> > > > > +XXX why is this visible to the guest?
> > > 
> > > I think some of these things were put here just because there wasn't
> > > another place for the toolstack to store things.  See also the
> > > arbitrary junk stored by scripts in the device backend directories.
> > 
> > Should we define a proper home for these? e.g. /$toolstack/$domid?
> 
> Yes, we should, but the purpose of the doc is to document what we do
> now, not what we will do :-).  I just replied to explain your XXX.

Thanks. I've tagged this one as INTERNAL.

> > > This should have a cross-reference to the documentation defining
> > > static-max etc.  I thought we had some in tree but I can't seem to
> > > find it.  The best I can find is docs/man/xl.cfg.pod.5.
> > 
> > I think you might be thinking of tools/libxl/libxl_memory.txt.
> > 
> > Shall we move that doc to docs/misc?
> 
> Good idea.

I'll incorporate this move into the next version of the patch.

> > Perhaps:
> > 
> >         every effort to ... reach this target
> > 
> > ? but I'm not sure that is strictly correct, a guest can use less if it
> > wants to. So perhaps
> > 
> >         every effort to ... not use more than this
> >         
> > ? seems clumsy though.
> 
> :-).  These all seem fine to me.

I went with "make every effort to every effort use no more
than this amount of RAM". I don't think there's any point in requiring a
guest to use more RAM than it wants to.

> > > I think it's not specified anywhere.  It's ad-hoc.  The guest
> > > shouldn't need to see it but exposing it readonly is probably
> > > harmless.  Except perhaps for the vnc password ?
> > 
> > vnc password appears to go into /vm/$uuid/vncpass (looking at libxl code
> > only).
> 
> Yuk.  We want to abolish /vm/$uuid/ surely.
> 
> > AFAIK it does nothing special with the perms, but /vm/$uuid is not guest
> > readable (perms are "n0") so I think that works out ok.
> > 
> > I wonder if that's part of the point of /vm/$uuid.
> 
> Perhaps we should make a new directory for this.  We do seem to have
> quite a bit of cruft in our system which attempting to write this
> document is revealing.
> 
> The right answer is probably to mention it in the doc as "likely to
> move".

I've noticed that nothing in here appears to be readable by guests.
Therefore I have marked them all with new tags INTERNAL (guest
should/must not read)  and "n" (guest's can't even read).

Thanks for the review/discussion. V2 of this patch to follow shortly.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 24 15:07:44 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Sep 2012 15:07:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGAFt-0004os-HF; Mon, 24 Sep 2012 15:07: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 1TGAFr-0004on-Mg
	for xen-devel@lists.xen.org; Mon, 24 Sep 2012 15:07:27 +0000
Received: from [85.158.139.211:20575] by server-3.bemta-5.messagelabs.com id
	61/46-16108-F2770605; Mon, 24 Sep 2012 15:07:27 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-206.messagelabs.com!1348499246!19743966!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTA4NDk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30931 invoked from network); 24 Sep 2012 15:07:26 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Sep 2012 15:07:26 -0000
X-IronPort-AV: E=Sophos;i="4.80,476,1344211200"; d="scan'208";a="14727915"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Sep 2012 15:07: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.279.1;
	Mon, 24 Sep 2012 16:07:25 +0100
Message-ID: <1348499244.3452.92.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Mon, 24 Sep 2012 16:07:24 +0100
In-Reply-To: <20576.17800.334075.677204@mariner.uk.xensource.com>
References: <1343657037-28495-1-git-send-email-ian.campbell@citrix.com>
	<1344506462.32142.96.camel@zakaz.uk.xensource.com>
	<20515.49901.369414.638893@mariner.uk.xensource.com>
	<1345215949.10161.76.camel@zakaz.uk.xensource.com>
	<20576.17800.334075.677204@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [DOCDAY PATCH] docs: initial documentation for
	xenstore paths
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2012-09-24 at 12:35 +0100, Ian Jackson wrote:
> Ian Campbell writes ("Re: [DOCDAY PATCH] docs: initial documentation for xenstore paths"):
> > On Thu, 2012-08-09 at 15:02 +0100, Ian Jackson wrote:
> > > Ian Campbell writes ("Re: [DOCDAY PATCH] docs: initial documentation for xenstore paths"):
> > > ...
> > > > > --- a/docs/misc/xenstore-paths.markdown
> > > > > +++ b/docs/misc/xenstore-paths.markdown
> > > > > @@ -0,0 +1,294 @@
> > > ...
> > > > > +PATH can contain simple regex constructs following the POSIX regexp
> > > > > +syntax described in regexp(7). In addition the following additional
> > > > > +wild card names are defined and are evaluated before regexp expansion:
> > > 
> > > Can we use a restricted perl re syntax ?  That avoids weirdness with
> > > the rules for \.
> > 
> > Is "restricted perl re syntax" a well defined thing (reference?) or do
> > you just mean perlre(1)--?
> 
> I mean pcre, or perlre(1), probably.
> 
> > What's the weirdness with \.?
> 
> In Perl syntax, a punctuation character preceded by \ is always a
> literal, and all metacharacters are unbackslashed punctuation.

Great, I think I can cope with that.

I suspect I've mostly used that syntax already anyhow.

> In regexp(7) you need to remember which of ( ) | [ ] . & $ need
> \-escaping to be literals and which need \-annotating to be
> metacharacters.  (And there are various dialects of this too; for
> example Emacs regexps require \ in front of a different subset of the
> punctuation.)

Yes, I don't think I've ever done a regexp search and replace in emacs
successfully on my first attempt.

> I don't particularly care about all the fancy (?:...) etc. extensions,
> but being able to write the regexp without referring to the manual, or
> experimenting, is very good - particularly in a document which will be
> tested at most rather indirectly.
> 
> > > > > +The process ID of the device model associated with this domain, if it
> > > > > +has one.
> > > > > +
> > > > > +XXX why is this visible to the guest?
> > > 
> > > I think some of these things were put here just because there wasn't
> > > another place for the toolstack to store things.  See also the
> > > arbitrary junk stored by scripts in the device backend directories.
> > 
> > Should we define a proper home for these? e.g. /$toolstack/$domid?
> 
> Yes, we should, but the purpose of the doc is to document what we do
> now, not what we will do :-).  I just replied to explain your XXX.

Thanks. I've tagged this one as INTERNAL.

> > > This should have a cross-reference to the documentation defining
> > > static-max etc.  I thought we had some in tree but I can't seem to
> > > find it.  The best I can find is docs/man/xl.cfg.pod.5.
> > 
> > I think you might be thinking of tools/libxl/libxl_memory.txt.
> > 
> > Shall we move that doc to docs/misc?
> 
> Good idea.

I'll incorporate this move into the next version of the patch.

> > Perhaps:
> > 
> >         every effort to ... reach this target
> > 
> > ? but I'm not sure that is strictly correct, a guest can use less if it
> > wants to. So perhaps
> > 
> >         every effort to ... not use more than this
> >         
> > ? seems clumsy though.
> 
> :-).  These all seem fine to me.

I went with "make every effort to every effort use no more
than this amount of RAM". I don't think there's any point in requiring a
guest to use more RAM than it wants to.

> > > I think it's not specified anywhere.  It's ad-hoc.  The guest
> > > shouldn't need to see it but exposing it readonly is probably
> > > harmless.  Except perhaps for the vnc password ?
> > 
> > vnc password appears to go into /vm/$uuid/vncpass (looking at libxl code
> > only).
> 
> Yuk.  We want to abolish /vm/$uuid/ surely.
> 
> > AFAIK it does nothing special with the perms, but /vm/$uuid is not guest
> > readable (perms are "n0") so I think that works out ok.
> > 
> > I wonder if that's part of the point of /vm/$uuid.
> 
> Perhaps we should make a new directory for this.  We do seem to have
> quite a bit of cruft in our system which attempting to write this
> document is revealing.
> 
> The right answer is probably to mention it in the doc as "likely to
> move".

I've noticed that nothing in here appears to be readable by guests.
Therefore I have marked them all with new tags INTERNAL (guest
should/must not read)  and "n" (guest's can't even read).

Thanks for the review/discussion. V2 of this patch to follow shortly.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 24 15:08:50 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Sep 2012 15: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 1TGAGx-0004yU-Vs; Mon, 24 Sep 2012 15:08:35 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jmarcet@gmail.com>) id 1TGAGw-0004yJ-JW
	for xen-devel@lists.xen.org; Mon, 24 Sep 2012 15:08:34 +0000
Received: from [85.158.143.99:32624] by server-2.bemta-4.messagelabs.com id
	F3/C0-06610-17770605; Mon, 24 Sep 2012 15:08:33 +0000
X-Env-Sender: jmarcet@gmail.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1348499311!23380235!1
X-Originating-IP: [209.85.214.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 656 invoked from network); 24 Sep 2012 15:08:33 -0000
Received: from mail-ob0-f173.google.com (HELO mail-ob0-f173.google.com)
	(209.85.214.173)
	by server-2.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Sep 2012 15:08:33 -0000
Received: by obbta14 with SMTP id ta14so7116033obb.32
	for <xen-devel@lists.xen.org>; Mon, 24 Sep 2012 08:08:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to
	:cc:content-type;
	bh=/KoVeV3At1xOYwJKM5/CC27oq3LqW/gPHhnTz7gM+00=;
	b=jFulWNRL6q0Xj8dTLl/3KgI9/erR4RkotSPOxFOqVFa3bCwMwQfoZBQ0vQ9oSDfaya
	ODjv9zPzs1Rx69GcPaKtwjkLOl4LiXvq7s1077tG2kEp8urrDPxBxh5H82wpllxrbxkV
	oR657fkOfy2hzC1UZ2YHPXHsqLh3yYfbUVaXj2fHQ6qG1udx4ll/mabUMHtWGNg8nNK+
	wv+Ll43IlDA7Cr6dstmR23Vyn6ugNg7oBYco3qUS2+mRubKwr67u+qRvoNcjyTaJ9lxU
	oQkkNIEDQBYt89H6UsU9TTqtLx0iRE+yrMrieGMcccwhFGbGV4vvO4rmbtD6kHR9jnKc
	m/wQ==
Received: by 10.60.171.69 with SMTP id as5mr10194892oec.100.1348499311613;
	Mon, 24 Sep 2012 08:08:31 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.60.138.225 with HTTP; Mon, 24 Sep 2012 08:08:10 -0700 (PDT)
In-Reply-To: <20120924140411.GH31618@phenom.dumpdata.com>
References: <CAOvdn6XKPOMNn6AjuYvZvPXRRJffN3po5GXe1Yh1-m0hisMK_w@mail.gmail.com>
	<CC8273A0.4C9DD%keir@xen.org>
	<50605E9A020000780009D486@nat28.tlf.novell.com>
	<CAOvdn6XmB6rj3_QVU+59V8p24Y5G47AWxVEM=id02JWXkuhibQ@mail.gmail.com>
	<5060640B020000780009D4D2@nat28.tlf.novell.com>
	<CAOvdn6XLy8zR2rb2MEyi2aT9LQiFvFLY_H02p181mTsVLVTZkw@mail.gmail.com>
	<20120924122203.GG8912@reaktio.net>
	<CAOvdn6XV4eoA-FfFns1xhx7HCUqXc7KHxZwyKuT4FHG8s3R5RQ@mail.gmail.com>
	<CAAnFQG9PLQjdh6Ab6=Y5ZGM1s4nGdLekKU=pcKNMxt4rmt_RKA@mail.gmail.com>
	<20120924140411.GH31618@phenom.dumpdata.com>
From: Javier Marcet <jmarcet@gmail.com>
Date: Mon, 24 Sep 2012 17:08:10 +0200
Message-ID: <CAAnFQG_so=mj5mfjbTunw4z0LN+mTabp-1zvL7+eRntepADhWA@mail.gmail.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: Keir Fraser <keir@xen.org>, john.baboval@citrix.com,
	xen-devel <xen-devel@lists.xen.org>, Ben Guthro <ben@guthro.net>,
	Jan Beulich <JBeulich@suse.com>, Thomas Goetz <thomas.goetz@citrix.com>
Subject: Re: [Xen-devel] Xen4.2 S3 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 Mon, Sep 24, 2012 at 4:04 PM, Konrad Rzeszutek Wilk
<konrad.wilk@oracle.com> wrote:

>> >> >    I see - Konrad - do you have a changeset I can look for with the
>> >> > features
>> >> >    Jan describes?
>> >>
>> >> xen-acpi-processor driver was merged to upstream Linux kernel v3.4.
>> >>
>> >
>> > I see - so the advanced methods are not being used then
>
> You mean with the v3.5 kernel? I would think they would be used..
>
>> > This same kernel does work with Xen-4.0.x though. Is there an assumption in
>> > the code that ties Xen-4.2 to a newer kernel?
>>
>> I'm being bitten by this bug with a 3.5 kernel and Xen 4.2
>
> Huh? How so?

Hmmm, yes, upon resuming from S3 I have this exact same bug.


-- 
Javier Marcet <jmarcet@gmail.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 24 15:08:50 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Sep 2012 15: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 1TGAGx-0004yU-Vs; Mon, 24 Sep 2012 15:08:35 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jmarcet@gmail.com>) id 1TGAGw-0004yJ-JW
	for xen-devel@lists.xen.org; Mon, 24 Sep 2012 15:08:34 +0000
Received: from [85.158.143.99:32624] by server-2.bemta-4.messagelabs.com id
	F3/C0-06610-17770605; Mon, 24 Sep 2012 15:08:33 +0000
X-Env-Sender: jmarcet@gmail.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1348499311!23380235!1
X-Originating-IP: [209.85.214.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 656 invoked from network); 24 Sep 2012 15:08:33 -0000
Received: from mail-ob0-f173.google.com (HELO mail-ob0-f173.google.com)
	(209.85.214.173)
	by server-2.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Sep 2012 15:08:33 -0000
Received: by obbta14 with SMTP id ta14so7116033obb.32
	for <xen-devel@lists.xen.org>; Mon, 24 Sep 2012 08:08:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to
	:cc:content-type;
	bh=/KoVeV3At1xOYwJKM5/CC27oq3LqW/gPHhnTz7gM+00=;
	b=jFulWNRL6q0Xj8dTLl/3KgI9/erR4RkotSPOxFOqVFa3bCwMwQfoZBQ0vQ9oSDfaya
	ODjv9zPzs1Rx69GcPaKtwjkLOl4LiXvq7s1077tG2kEp8urrDPxBxh5H82wpllxrbxkV
	oR657fkOfy2hzC1UZ2YHPXHsqLh3yYfbUVaXj2fHQ6qG1udx4ll/mabUMHtWGNg8nNK+
	wv+Ll43IlDA7Cr6dstmR23Vyn6ugNg7oBYco3qUS2+mRubKwr67u+qRvoNcjyTaJ9lxU
	oQkkNIEDQBYt89H6UsU9TTqtLx0iRE+yrMrieGMcccwhFGbGV4vvO4rmbtD6kHR9jnKc
	m/wQ==
Received: by 10.60.171.69 with SMTP id as5mr10194892oec.100.1348499311613;
	Mon, 24 Sep 2012 08:08:31 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.60.138.225 with HTTP; Mon, 24 Sep 2012 08:08:10 -0700 (PDT)
In-Reply-To: <20120924140411.GH31618@phenom.dumpdata.com>
References: <CAOvdn6XKPOMNn6AjuYvZvPXRRJffN3po5GXe1Yh1-m0hisMK_w@mail.gmail.com>
	<CC8273A0.4C9DD%keir@xen.org>
	<50605E9A020000780009D486@nat28.tlf.novell.com>
	<CAOvdn6XmB6rj3_QVU+59V8p24Y5G47AWxVEM=id02JWXkuhibQ@mail.gmail.com>
	<5060640B020000780009D4D2@nat28.tlf.novell.com>
	<CAOvdn6XLy8zR2rb2MEyi2aT9LQiFvFLY_H02p181mTsVLVTZkw@mail.gmail.com>
	<20120924122203.GG8912@reaktio.net>
	<CAOvdn6XV4eoA-FfFns1xhx7HCUqXc7KHxZwyKuT4FHG8s3R5RQ@mail.gmail.com>
	<CAAnFQG9PLQjdh6Ab6=Y5ZGM1s4nGdLekKU=pcKNMxt4rmt_RKA@mail.gmail.com>
	<20120924140411.GH31618@phenom.dumpdata.com>
From: Javier Marcet <jmarcet@gmail.com>
Date: Mon, 24 Sep 2012 17:08:10 +0200
Message-ID: <CAAnFQG_so=mj5mfjbTunw4z0LN+mTabp-1zvL7+eRntepADhWA@mail.gmail.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: Keir Fraser <keir@xen.org>, john.baboval@citrix.com,
	xen-devel <xen-devel@lists.xen.org>, Ben Guthro <ben@guthro.net>,
	Jan Beulich <JBeulich@suse.com>, Thomas Goetz <thomas.goetz@citrix.com>
Subject: Re: [Xen-devel] Xen4.2 S3 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 Mon, Sep 24, 2012 at 4:04 PM, Konrad Rzeszutek Wilk
<konrad.wilk@oracle.com> wrote:

>> >> >    I see - Konrad - do you have a changeset I can look for with the
>> >> > features
>> >> >    Jan describes?
>> >>
>> >> xen-acpi-processor driver was merged to upstream Linux kernel v3.4.
>> >>
>> >
>> > I see - so the advanced methods are not being used then
>
> You mean with the v3.5 kernel? I would think they would be used..
>
>> > This same kernel does work with Xen-4.0.x though. Is there an assumption in
>> > the code that ties Xen-4.2 to a newer kernel?
>>
>> I'm being bitten by this bug with a 3.5 kernel and Xen 4.2
>
> Huh? How so?

Hmmm, yes, upon resuming from S3 I have this exact same bug.


-- 
Javier Marcet <jmarcet@gmail.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 24 15:17:38 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Sep 2012 15: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 1TGAPV-0005FQ-1e; Mon, 24 Sep 2012 15:17:25 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1TGAPT-0005FG-Ou
	for Xen-devel@lists.xensource.com; Mon, 24 Sep 2012 15:17:23 +0000
Received: from [85.158.137.99:42089] by server-11.bemta-3.messagelabs.com id
	EF/B9-30250-28970605; Mon, 24 Sep 2012 15:17:22 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-9.tower-217.messagelabs.com!1348499842!15772964!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTA4NDk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3191 invoked from network); 24 Sep 2012 15:17:22 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Sep 2012 15:17:22 -0000
X-IronPort-AV: E=Sophos;i="4.80,476,1344211200"; d="scan'208";a="14728270"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Sep 2012 15:17: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.279.1; Mon, 24 Sep 2012 16:17:22 +0100
Date: Mon, 24 Sep 2012 16:16:29 +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: <20120921121202.3163c379@mantra.us.oracle.com>
Message-ID: <alpine.DEB.2.02.1209241613160.29232@kaball.uk.xensource.com>
References: <20120921121202.3163c379@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>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH v1 0/8]: PVH (PV guest with extensions)u
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 21 Sep 2012, Mukesh Rathor wrote:
> Hi guys,
> 
> Ok, I've made all the changes from prev RFC patch submission. Tested
> all the combinations. The patches are a bit smaller from before, and
> couldn't be separated like before, so I can't state whats different in
> each patch. But, it's not too bad to review now.
> 
> As before, they were built on top of
> fc6bdb59a501740b28ed3b616641a22c8dc5dd31 from the following tree:
>         
> git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git

The patch series is not in a bad state. It is reasonable to aim for a
merge in 3.8.
At least the xen_remap_domain_mfn_range, ballooning and privcmd changes,
which interfaces are going to be shared with Xen on ARM ;-)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 24 15:17:38 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Sep 2012 15: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 1TGAPV-0005FQ-1e; Mon, 24 Sep 2012 15:17:25 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1TGAPT-0005FG-Ou
	for Xen-devel@lists.xensource.com; Mon, 24 Sep 2012 15:17:23 +0000
Received: from [85.158.137.99:42089] by server-11.bemta-3.messagelabs.com id
	EF/B9-30250-28970605; Mon, 24 Sep 2012 15:17:22 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-9.tower-217.messagelabs.com!1348499842!15772964!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTA4NDk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3191 invoked from network); 24 Sep 2012 15:17:22 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Sep 2012 15:17:22 -0000
X-IronPort-AV: E=Sophos;i="4.80,476,1344211200"; d="scan'208";a="14728270"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Sep 2012 15:17: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.279.1; Mon, 24 Sep 2012 16:17:22 +0100
Date: Mon, 24 Sep 2012 16:16:29 +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: <20120921121202.3163c379@mantra.us.oracle.com>
Message-ID: <alpine.DEB.2.02.1209241613160.29232@kaball.uk.xensource.com>
References: <20120921121202.3163c379@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>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH v1 0/8]: PVH (PV guest with extensions)u
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 21 Sep 2012, Mukesh Rathor wrote:
> Hi guys,
> 
> Ok, I've made all the changes from prev RFC patch submission. Tested
> all the combinations. The patches are a bit smaller from before, and
> couldn't be separated like before, so I can't state whats different in
> each patch. But, it's not too bad to review now.
> 
> As before, they were built on top of
> fc6bdb59a501740b28ed3b616641a22c8dc5dd31 from the following tree:
>         
> git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git

The patch series is not in a bad state. It is reasonable to aim for a
merge in 3.8.
At least the xen_remap_domain_mfn_range, ballooning and privcmd changes,
which interfaces are going to be shared with Xen on ARM ;-)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 24 15:17:40 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Sep 2012 15:17:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGAPV-0005FX-Dt; Mon, 24 Sep 2012 15:17:25 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1TGAPU-0005FH-7b
	for xen-devel@lists.xen.org; Mon, 24 Sep 2012 15:17:24 +0000
Received: from [85.158.139.83:47525] by server-10.bemta-5.messagelabs.com id
	2F/6C-16911-38970605; Mon, 24 Sep 2012 15:17:23 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1348499842!31358040!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19053 invoked from network); 24 Sep 2012 15:17:22 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-13.tower-182.messagelabs.com with SMTP;
	24 Sep 2012 15:17:22 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 24 Sep 2012 16:17:22 +0100
Message-Id: <506095A0020000780009D67B@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 24 Sep 2012 16:17:20 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__PartB1808C90.1__="
Cc: Ben Guthro <ben@guthro.net>
Subject: [Xen-devel] [PATCH] x86/S3: add cache flush on secondary CPUs
 before going to sleep
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<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.

--=__PartB1808C90.1__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Secondary CPUs, between doing their final memory writes (particularly
updating cpu_initialized) and getting a subsequent INIT, may not write
back all modified data. The INIT itself then causes those modifications
to be lost, so in the cpu_initialized case the CPU would find itself
already initialized, (intentionally) entering an infinite loop instead
of actually coming online.

Signed-off-by: Ben Guthro <ben@guthro.net>

Make acpi_dead_idle() call default_dead_idle() rather than duplicating
the logic there.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/arch/x86/acpi/cpu_idle.c
+++ b/xen/arch/x86/acpi/cpu_idle.c
@@ -659,8 +659,7 @@ void acpi_dead_idle(void)
     }
=20
 default_halt:
-    for ( ; ; )
-        halt();
+    default_dead_idle();
 }
=20
 int cpuidle_init_cpu(unsigned int cpu)
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -45,6 +45,7 @@
 #include <asm/desc.h>
 #include <asm/i387.h>
 #include <asm/xstate.h>
+#include <asm/cpuidle.h>
 #include <asm/mpspec.h>
 #include <asm/ldt.h>
 #include <asm/fixmap.h>
@@ -64,7 +65,6 @@ DEFINE_PER_CPU(struct vcpu *, curr_vcpu)
 DEFINE_PER_CPU(unsigned long, cr4);
=20
 static void default_idle(void);
-static void default_dead_idle(void);
 void (*pm_idle) (void) __read_mostly =3D default_idle;
 void (*dead_idle) (void) __read_mostly =3D default_dead_idle;
=20
@@ -82,8 +82,9 @@ static void default_idle(void)
         local_irq_enable();
 }
=20
-static void default_dead_idle(void)
+void default_dead_idle(void)
 {
+    wbinvd();
     for ( ; ; )
         halt();
 }
--- a/xen/include/asm-x86/cpuidle.h
+++ b/xen/include/asm-x86/cpuidle.h
@@ -18,6 +18,7 @@ extern uint64_t (*cpuidle_get_tick)(void
=20
 int mwait_idle_init(struct notifier_block *);
 int cpuidle_init_cpu(unsigned int cpu);
+void default_dead_idle(void);
 void acpi_dead_idle(void);
 void trace_exit_reason(u32 *irq_traced);
 void update_idle_stats(struct acpi_processor_power *,




--=__PartB1808C90.1__=
Content-Type: text/plain; name="x86-S3-flush-cache.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="x86-S3-flush-cache.patch"

x86/S3: add cache flush on secondary CPUs before going to sleep=0A=0ASecond=
ary CPUs, between doing their final memory writes (particularly=0Aupdating =
cpu_initialized) and getting a subsequent INIT, may not write=0Aback all =
modified data. The INIT itself then causes those modifications=0Ato be =
lost, so in the cpu_initialized case the CPU would find itself=0Aalready =
initialized, (intentionally) entering an infinite loop instead=0Aof =
actually coming online.=0A=0ASigned-off-by: Ben Guthro <ben@guthro.net>=0A=
=0AMake acpi_dead_idle() call default_dead_idle() rather than duplicating=
=0Athe logic there.=0A=0ASigned-off-by: Jan Beulich <jbeulich@suse.com>=0A=
=0A--- a/xen/arch/x86/acpi/cpu_idle.c=0A+++ b/xen/arch/x86/acpi/cpu_idle.c=
=0A@@ -659,8 +659,7 @@ void acpi_dead_idle(void)=0A     }=0A =0A default_ha=
lt:=0A-    for ( ; ; )=0A-        halt();=0A+    default_dead_idle();=0A =
}=0A =0A int cpuidle_init_cpu(unsigned int cpu)=0A--- a/xen/arch/x86/domain=
.c=0A+++ b/xen/arch/x86/domain.c=0A@@ -45,6 +45,7 @@=0A #include <asm/desc.=
h>=0A #include <asm/i387.h>=0A #include <asm/xstate.h>=0A+#include =
<asm/cpuidle.h>=0A #include <asm/mpspec.h>=0A #include <asm/ldt.h>=0A =
#include <asm/fixmap.h>=0A@@ -64,7 +65,6 @@ DEFINE_PER_CPU(struct vcpu *, =
curr_vcpu)=0A DEFINE_PER_CPU(unsigned long, cr4);=0A =0A static void =
default_idle(void);=0A-static void default_dead_idle(void);=0A void =
(*pm_idle) (void) __read_mostly =3D default_idle;=0A void (*dead_idle) =
(void) __read_mostly =3D default_dead_idle;=0A =0A@@ -82,8 +82,9 @@ static =
void default_idle(void)=0A         local_irq_enable();=0A }=0A =0A-static =
void default_dead_idle(void)=0A+void default_dead_idle(void)=0A {=0A+    =
wbinvd();=0A     for ( ; ; )=0A         halt();=0A }=0A--- a/xen/include/as=
m-x86/cpuidle.h=0A+++ b/xen/include/asm-x86/cpuidle.h=0A@@ -18,6 +18,7 @@ =
extern uint64_t (*cpuidle_get_tick)(void=0A =0A int mwait_idle_init(struct =
notifier_block *);=0A int cpuidle_init_cpu(unsigned int cpu);=0A+void =
default_dead_idle(void);=0A void acpi_dead_idle(void);=0A void trace_exit_r=
eason(u32 *irq_traced);=0A void update_idle_stats(struct acpi_processor_pow=
er *,=0A
--=__PartB1808C90.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

--=__PartB1808C90.1__=--


From xen-devel-bounces@lists.xen.org Mon Sep 24 15:17:40 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Sep 2012 15:17:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGAPV-0005FX-Dt; Mon, 24 Sep 2012 15:17:25 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1TGAPU-0005FH-7b
	for xen-devel@lists.xen.org; Mon, 24 Sep 2012 15:17:24 +0000
Received: from [85.158.139.83:47525] by server-10.bemta-5.messagelabs.com id
	2F/6C-16911-38970605; Mon, 24 Sep 2012 15:17:23 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1348499842!31358040!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19053 invoked from network); 24 Sep 2012 15:17:22 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-13.tower-182.messagelabs.com with SMTP;
	24 Sep 2012 15:17:22 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 24 Sep 2012 16:17:22 +0100
Message-Id: <506095A0020000780009D67B@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 24 Sep 2012 16:17:20 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__PartB1808C90.1__="
Cc: Ben Guthro <ben@guthro.net>
Subject: [Xen-devel] [PATCH] x86/S3: add cache flush on secondary CPUs
 before going to sleep
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<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.

--=__PartB1808C90.1__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Secondary CPUs, between doing their final memory writes (particularly
updating cpu_initialized) and getting a subsequent INIT, may not write
back all modified data. The INIT itself then causes those modifications
to be lost, so in the cpu_initialized case the CPU would find itself
already initialized, (intentionally) entering an infinite loop instead
of actually coming online.

Signed-off-by: Ben Guthro <ben@guthro.net>

Make acpi_dead_idle() call default_dead_idle() rather than duplicating
the logic there.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/arch/x86/acpi/cpu_idle.c
+++ b/xen/arch/x86/acpi/cpu_idle.c
@@ -659,8 +659,7 @@ void acpi_dead_idle(void)
     }
=20
 default_halt:
-    for ( ; ; )
-        halt();
+    default_dead_idle();
 }
=20
 int cpuidle_init_cpu(unsigned int cpu)
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -45,6 +45,7 @@
 #include <asm/desc.h>
 #include <asm/i387.h>
 #include <asm/xstate.h>
+#include <asm/cpuidle.h>
 #include <asm/mpspec.h>
 #include <asm/ldt.h>
 #include <asm/fixmap.h>
@@ -64,7 +65,6 @@ DEFINE_PER_CPU(struct vcpu *, curr_vcpu)
 DEFINE_PER_CPU(unsigned long, cr4);
=20
 static void default_idle(void);
-static void default_dead_idle(void);
 void (*pm_idle) (void) __read_mostly =3D default_idle;
 void (*dead_idle) (void) __read_mostly =3D default_dead_idle;
=20
@@ -82,8 +82,9 @@ static void default_idle(void)
         local_irq_enable();
 }
=20
-static void default_dead_idle(void)
+void default_dead_idle(void)
 {
+    wbinvd();
     for ( ; ; )
         halt();
 }
--- a/xen/include/asm-x86/cpuidle.h
+++ b/xen/include/asm-x86/cpuidle.h
@@ -18,6 +18,7 @@ extern uint64_t (*cpuidle_get_tick)(void
=20
 int mwait_idle_init(struct notifier_block *);
 int cpuidle_init_cpu(unsigned int cpu);
+void default_dead_idle(void);
 void acpi_dead_idle(void);
 void trace_exit_reason(u32 *irq_traced);
 void update_idle_stats(struct acpi_processor_power *,




--=__PartB1808C90.1__=
Content-Type: text/plain; name="x86-S3-flush-cache.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="x86-S3-flush-cache.patch"

x86/S3: add cache flush on secondary CPUs before going to sleep=0A=0ASecond=
ary CPUs, between doing their final memory writes (particularly=0Aupdating =
cpu_initialized) and getting a subsequent INIT, may not write=0Aback all =
modified data. The INIT itself then causes those modifications=0Ato be =
lost, so in the cpu_initialized case the CPU would find itself=0Aalready =
initialized, (intentionally) entering an infinite loop instead=0Aof =
actually coming online.=0A=0ASigned-off-by: Ben Guthro <ben@guthro.net>=0A=
=0AMake acpi_dead_idle() call default_dead_idle() rather than duplicating=
=0Athe logic there.=0A=0ASigned-off-by: Jan Beulich <jbeulich@suse.com>=0A=
=0A--- a/xen/arch/x86/acpi/cpu_idle.c=0A+++ b/xen/arch/x86/acpi/cpu_idle.c=
=0A@@ -659,8 +659,7 @@ void acpi_dead_idle(void)=0A     }=0A =0A default_ha=
lt:=0A-    for ( ; ; )=0A-        halt();=0A+    default_dead_idle();=0A =
}=0A =0A int cpuidle_init_cpu(unsigned int cpu)=0A--- a/xen/arch/x86/domain=
.c=0A+++ b/xen/arch/x86/domain.c=0A@@ -45,6 +45,7 @@=0A #include <asm/desc.=
h>=0A #include <asm/i387.h>=0A #include <asm/xstate.h>=0A+#include =
<asm/cpuidle.h>=0A #include <asm/mpspec.h>=0A #include <asm/ldt.h>=0A =
#include <asm/fixmap.h>=0A@@ -64,7 +65,6 @@ DEFINE_PER_CPU(struct vcpu *, =
curr_vcpu)=0A DEFINE_PER_CPU(unsigned long, cr4);=0A =0A static void =
default_idle(void);=0A-static void default_dead_idle(void);=0A void =
(*pm_idle) (void) __read_mostly =3D default_idle;=0A void (*dead_idle) =
(void) __read_mostly =3D default_dead_idle;=0A =0A@@ -82,8 +82,9 @@ static =
void default_idle(void)=0A         local_irq_enable();=0A }=0A =0A-static =
void default_dead_idle(void)=0A+void default_dead_idle(void)=0A {=0A+    =
wbinvd();=0A     for ( ; ; )=0A         halt();=0A }=0A--- a/xen/include/as=
m-x86/cpuidle.h=0A+++ b/xen/include/asm-x86/cpuidle.h=0A@@ -18,6 +18,7 @@ =
extern uint64_t (*cpuidle_get_tick)(void=0A =0A int mwait_idle_init(struct =
notifier_block *);=0A int cpuidle_init_cpu(unsigned int cpu);=0A+void =
default_dead_idle(void);=0A void acpi_dead_idle(void);=0A void trace_exit_r=
eason(u32 *irq_traced);=0A void update_idle_stats(struct acpi_processor_pow=
er *,=0A
--=__PartB1808C90.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

--=__PartB1808C90.1__=--


From xen-devel-bounces@lists.xen.org Mon Sep 24 15:17:53 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Sep 2012 15:17:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGAPj-0005HS-0N; Mon, 24 Sep 2012 15:17:39 +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 1TGAPg-0005Gf-Rp
	for xen-devel@lists.xen.org; Mon, 24 Sep 2012 15:17:37 +0000
Received: from [85.158.139.211:50245] by server-9.bemta-5.messagelabs.com id
	E2/F0-14846-F8970605; Mon, 24 Sep 2012 15:17:35 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-13.tower-206.messagelabs.com!1348499852!15780200!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDc2OTcxMA==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15568 invoked from network); 24 Sep 2012 15:17:34 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-13.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 24 Sep 2012 15:17:34 -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 q8OFHTrp023357
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 24 Sep 2012 15:17:29 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q8OFHS4P014110
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 24 Sep 2012 15:17:28 GMT
Received: from abhmt107.oracle.com (abhmt107.oracle.com [141.146.116.59])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q8OFHSkN003749; Mon, 24 Sep 2012 10:17:28 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 24 Sep 2012 08:17:28 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 7387C4031C; Mon, 24 Sep 2012 11:06:16 -0400 (EDT)
Date: Mon, 24 Sep 2012 11:06:16 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Andres Lagar-Cavilla <andreslc@gridcentric.ca>
Message-ID: <20120924150616.GA694@phenom.dumpdata.com>
References: <1348242767-23732-1-git-send-email-oliver.chick@citrix.com>
	<20120921184123.GA27502@phenom.dumpdata.com>
	<20120921185622.GA5042@phenom.dumpdata.com>
	<20120921204646.GB30614@phenom.dumpdata.com>
	<43E8FEC9-DE7D-4352-87F2-63FB8984D556@gridcentric.ca>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <43E8FEC9-DE7D-4352-87F2-63FB8984D556@gridcentric.ca>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: Oliver Chick <oliver.chick@citrix.com>, linux-kernel@vger.kernel.org,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH v2] Persistent grant maps for xen blk drivers
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Sep 24, 2012 at 10:38:48AM -0400, Andres Lagar-Cavilla wrote:
> On Sep 21, 2012, at 4:46 PM, Konrad Rzeszutek Wilk wrote:
> 
> > On Fri, Sep 21, 2012 at 02:56:22PM -0400, Konrad Rzeszutek Wilk wrote:
> >>> *: With a PVHVM guest I get
> >>> 
> >>> [  261.927218] privcmd_fault: vma=ffff88002a31dce8 7f4edc095000-7f4edc195000, pgoff=c8, uv=00007f4edc15d000
> >>> 
> >>> thought if I applied your patch on top of v3.6-rc6 I didn't see the privcmd_fault but
> >>> I did see the guest crash.
> >> 
> >> And that is due to c571898ffc24a1768e1b2dabeac0fc7dd4c14601 which I've reverted in my
> >> #linux-next branch
> > 
> > Nevermind. Andres' patch by itself (so without yours) works just fine. There is
> > something your patch and his aren't agreeing on.
> 
> Apart from interacting badly in combination, would either patch in isolation work well?

"work well" is not exactly the right phase I would use.

Your patch by itself (so on top v3.6-rc6) works great.
On top of #linux-next (so v3.6-rc6 + lot of other patches for v3.7) works great.

Oliver's patch for blkback/blkfront on top of v3.6-rc6 falls flat on its face in the guest.
Oliver's patch for blkback/blkfront on top of v3.6-rc6 + lot of other patches for v3.7 - your patch)
falls flat on its face in the guest.

Oliver's patch for blkback/blkfront on top of v3.6-rc6 + lot of other patches for v3.7 + your patch)
falls flat on its face in the backend with the privcmd_fault.

I think I need to figure on what tree does Oliver's patch work properly and
figure out why it dies first in the guest and then find out why in the backend
it dies with your patch.

Your patch is still on the train for v3.7

> 
> I can think of only one hunk in my patch disagreeing with blkback stuff:

I can try it out.. but I am not going to get to it today or in the next
few days.

> diff --git a/drivers/xen/grant-table.c b/drivers/xen/grant-table.c
> index eea81cf..f5681c8 100644
> --- a/drivers/xen/grant-table.c
> +++ b/drivers/xen/grant-table.c
> @@ -836,6 +883,12 @@ int gnttab_map_refs(struct gnttab_map_grant_ref *map_ops,
>  	if (ret)
>  		return ret;
>  
> +	/* Retry eagain maps */
> +	for (i = 0; i < count; i++)
> +		if (map_ops[i].status == GNTST_eagain)
> +			gnttab_retry_eagain_gop(GNTTABOP_map_grant_ref, map_ops + i,
> +                                    &map_ops[i].status, __func__);
> +
>  	if (xen_feature(XENFEAT_auto_translated_physmap))
>  		return ret;
>  
> How would you like to proceed?
> Andres
> 
> > 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 24 15:17:53 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Sep 2012 15:17:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGAPj-0005HS-0N; Mon, 24 Sep 2012 15:17:39 +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 1TGAPg-0005Gf-Rp
	for xen-devel@lists.xen.org; Mon, 24 Sep 2012 15:17:37 +0000
Received: from [85.158.139.211:50245] by server-9.bemta-5.messagelabs.com id
	E2/F0-14846-F8970605; Mon, 24 Sep 2012 15:17:35 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-13.tower-206.messagelabs.com!1348499852!15780200!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDc2OTcxMA==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15568 invoked from network); 24 Sep 2012 15:17:34 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-13.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 24 Sep 2012 15:17:34 -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 q8OFHTrp023357
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 24 Sep 2012 15:17:29 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q8OFHS4P014110
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 24 Sep 2012 15:17:28 GMT
Received: from abhmt107.oracle.com (abhmt107.oracle.com [141.146.116.59])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q8OFHSkN003749; Mon, 24 Sep 2012 10:17:28 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 24 Sep 2012 08:17:28 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 7387C4031C; Mon, 24 Sep 2012 11:06:16 -0400 (EDT)
Date: Mon, 24 Sep 2012 11:06:16 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Andres Lagar-Cavilla <andreslc@gridcentric.ca>
Message-ID: <20120924150616.GA694@phenom.dumpdata.com>
References: <1348242767-23732-1-git-send-email-oliver.chick@citrix.com>
	<20120921184123.GA27502@phenom.dumpdata.com>
	<20120921185622.GA5042@phenom.dumpdata.com>
	<20120921204646.GB30614@phenom.dumpdata.com>
	<43E8FEC9-DE7D-4352-87F2-63FB8984D556@gridcentric.ca>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <43E8FEC9-DE7D-4352-87F2-63FB8984D556@gridcentric.ca>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: Oliver Chick <oliver.chick@citrix.com>, linux-kernel@vger.kernel.org,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH v2] Persistent grant maps for xen blk drivers
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Sep 24, 2012 at 10:38:48AM -0400, Andres Lagar-Cavilla wrote:
> On Sep 21, 2012, at 4:46 PM, Konrad Rzeszutek Wilk wrote:
> 
> > On Fri, Sep 21, 2012 at 02:56:22PM -0400, Konrad Rzeszutek Wilk wrote:
> >>> *: With a PVHVM guest I get
> >>> 
> >>> [  261.927218] privcmd_fault: vma=ffff88002a31dce8 7f4edc095000-7f4edc195000, pgoff=c8, uv=00007f4edc15d000
> >>> 
> >>> thought if I applied your patch on top of v3.6-rc6 I didn't see the privcmd_fault but
> >>> I did see the guest crash.
> >> 
> >> And that is due to c571898ffc24a1768e1b2dabeac0fc7dd4c14601 which I've reverted in my
> >> #linux-next branch
> > 
> > Nevermind. Andres' patch by itself (so without yours) works just fine. There is
> > something your patch and his aren't agreeing on.
> 
> Apart from interacting badly in combination, would either patch in isolation work well?

"work well" is not exactly the right phase I would use.

Your patch by itself (so on top v3.6-rc6) works great.
On top of #linux-next (so v3.6-rc6 + lot of other patches for v3.7) works great.

Oliver's patch for blkback/blkfront on top of v3.6-rc6 falls flat on its face in the guest.
Oliver's patch for blkback/blkfront on top of v3.6-rc6 + lot of other patches for v3.7 - your patch)
falls flat on its face in the guest.

Oliver's patch for blkback/blkfront on top of v3.6-rc6 + lot of other patches for v3.7 + your patch)
falls flat on its face in the backend with the privcmd_fault.

I think I need to figure on what tree does Oliver's patch work properly and
figure out why it dies first in the guest and then find out why in the backend
it dies with your patch.

Your patch is still on the train for v3.7

> 
> I can think of only one hunk in my patch disagreeing with blkback stuff:

I can try it out.. but I am not going to get to it today or in the next
few days.

> diff --git a/drivers/xen/grant-table.c b/drivers/xen/grant-table.c
> index eea81cf..f5681c8 100644
> --- a/drivers/xen/grant-table.c
> +++ b/drivers/xen/grant-table.c
> @@ -836,6 +883,12 @@ int gnttab_map_refs(struct gnttab_map_grant_ref *map_ops,
>  	if (ret)
>  		return ret;
>  
> +	/* Retry eagain maps */
> +	for (i = 0; i < count; i++)
> +		if (map_ops[i].status == GNTST_eagain)
> +			gnttab_retry_eagain_gop(GNTTABOP_map_grant_ref, map_ops + i,
> +                                    &map_ops[i].status, __func__);
> +
>  	if (xen_feature(XENFEAT_auto_translated_physmap))
>  		return ret;
>  
> How would you like to proceed?
> Andres
> 
> > 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 24 15:21:33 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Sep 2012 15: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 1TGATK-0005cb-S1; Mon, 24 Sep 2012 15:21:22 +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 1TGATJ-0005cC-7C
	for xen-devel@lists.xensource.com; Mon, 24 Sep 2012 15:21:21 +0000
Received: from [85.158.138.51:41412] by server-8.bemta-3.messagelabs.com id
	20/BD-24700-F6A70605; Mon, 24 Sep 2012 15:21:19 +0000
X-Env-Sender: lars.kurth.xen@gmail.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1348500079!23700418!1
X-Originating-IP: [209.85.214.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20477 invoked from network); 24 Sep 2012 15:21:19 -0000
Received: from mail-bk0-f43.google.com (HELO mail-bk0-f43.google.com)
	(209.85.214.43)
	by server-3.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Sep 2012 15:21:19 -0000
Received: by bkty15 with SMTP id y15so3405547bkt.30
	for <multiple recipients>; Mon, 24 Sep 2012 08:21:15 -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=oBpqR5TznouQsi+IuG0HgLA6pIjdLhkwaiyQfK0JnsQ=;
	b=Cl2oAVttZwNIo9t2hMMtRTPbAz3CgRq7hLvM7P6U3pEtnpFqaSAOdOzYChylrQVpZS
	VtvqhsSfWDkVSq6Y9VdFnWkeUDA1GAyb7K4PF7aMJFVfOYdi4Drz+NYkYKq3L6E7Ezec
	veB4/WwLHMxF1edyy+KC1IeI2MWq9VD46dsdABXPHoDEBzT9hSyQRMReYDuRXjqiSSO6
	c+NLRH63txk0FEfFwmLvKVC60OSJT035rYoSA6hOw7OowPqvXE1BBeDp6SL6/XPlsvza
	8h7tKfLfRkHTrc9Aj2/e1peq+87i3RQRB+MkfS3ASb5UfsokJLXl5fXMQuV2Y5e1EUN7
	GlaQ==
Received: by 10.204.5.148 with SMTP id 20mr1975413bkv.28.1348500075447;
	Mon, 24 Sep 2012 08:21:15 -0700 (PDT)
Received: from [172.16.26.11] (b0fb5b35.bb.sky.com. [176.251.91.53])
	by mx.google.com with ESMTPS id gy18sm2087911bkc.4.2012.09.24.08.21.14
	(version=SSLv3 cipher=OTHER); Mon, 24 Sep 2012 08:21:14 -0700 (PDT)
Message-ID: <50607A68.2090604@xen.org>
Date: Mon, 24 Sep 2012 16:21:12 +0100
From: Lars Kurth <lars.kurth@xen.org>
User-Agent: Mozilla/5.0 (Windows NT 6.1;
	rv:15.0) Gecko/20120907 Thunderbird/15.0.1
MIME-Version: 1.0
To: Grant McWilliams <grantmasterflash@gmail.com>
References: <CAGnmK4wB3ZJ3Tb9-VFgWCkcZNwibDzRYV8tvb14vLgw1wj2awQ@mail.gmail.com>
In-Reply-To: <CAGnmK4wB3ZJ3Tb9-VFgWCkcZNwibDzRYV8tvb14vLgw1wj2awQ@mail.gmail.com>
Cc: xen-devel@lists.xensource.com, xen-api@lists.xensource.com
Subject: Re: [Xen-devel] Proposal - Add xe manpages to xen-org
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

Grant,

this sounds like a fantastic idea. I will leave this for community 
discussion for now, and follow-up whether we need a formal vote in about 
a week's time. I guess there is also some detail to sort out such as 
repo name, exact location, anything legal (e.g. does the source have GPL 
headers), etc.

Best Regards
Lars

On 24/09/2012 16:06, Grant McWilliams wrote:
> Xen Community,
>
>     I have a team of people frantically creating manpages for the xe 
> command and all of it's 361 subcommands. The initial source 
> documentation is in asciidoc but also saved as Docbook. From docbook 
> we transform to epub, html, manpage and pdf. This is currently being 
> hosted in a subversion server at a Seattle area college and we'd like 
> to move it to the xen-org github so it's public, can be reviewed, 
> commented on and contributed too.
>
> We will also document the additional commands specific to 
> xenserver/xcp (xe-edit-bootloader and others like it as time permits.
>
> For each section of commands we're also writing xcp tools that 
> describe how to script the xe command and use it's various 
> options/parameters. These tools have been a godsend in our own 
> administration so far and should be packages and distributed themselves.
>
> All of our documentation is created with future XSLT transforms being 
> able to include or remove sections with the Administration guide and 
> xe help in mind.
>
> This is an official proposal to add this project to xen-org.
>
>
> Grant McWilliams
> Professor of Computer Science
> Edmonds Community College
>


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 24 15:21:33 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Sep 2012 15: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 1TGATK-0005cb-S1; Mon, 24 Sep 2012 15:21:22 +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 1TGATJ-0005cC-7C
	for xen-devel@lists.xensource.com; Mon, 24 Sep 2012 15:21:21 +0000
Received: from [85.158.138.51:41412] by server-8.bemta-3.messagelabs.com id
	20/BD-24700-F6A70605; Mon, 24 Sep 2012 15:21:19 +0000
X-Env-Sender: lars.kurth.xen@gmail.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1348500079!23700418!1
X-Originating-IP: [209.85.214.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20477 invoked from network); 24 Sep 2012 15:21:19 -0000
Received: from mail-bk0-f43.google.com (HELO mail-bk0-f43.google.com)
	(209.85.214.43)
	by server-3.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Sep 2012 15:21:19 -0000
Received: by bkty15 with SMTP id y15so3405547bkt.30
	for <multiple recipients>; Mon, 24 Sep 2012 08:21:15 -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=oBpqR5TznouQsi+IuG0HgLA6pIjdLhkwaiyQfK0JnsQ=;
	b=Cl2oAVttZwNIo9t2hMMtRTPbAz3CgRq7hLvM7P6U3pEtnpFqaSAOdOzYChylrQVpZS
	VtvqhsSfWDkVSq6Y9VdFnWkeUDA1GAyb7K4PF7aMJFVfOYdi4Drz+NYkYKq3L6E7Ezec
	veB4/WwLHMxF1edyy+KC1IeI2MWq9VD46dsdABXPHoDEBzT9hSyQRMReYDuRXjqiSSO6
	c+NLRH63txk0FEfFwmLvKVC60OSJT035rYoSA6hOw7OowPqvXE1BBeDp6SL6/XPlsvza
	8h7tKfLfRkHTrc9Aj2/e1peq+87i3RQRB+MkfS3ASb5UfsokJLXl5fXMQuV2Y5e1EUN7
	GlaQ==
Received: by 10.204.5.148 with SMTP id 20mr1975413bkv.28.1348500075447;
	Mon, 24 Sep 2012 08:21:15 -0700 (PDT)
Received: from [172.16.26.11] (b0fb5b35.bb.sky.com. [176.251.91.53])
	by mx.google.com with ESMTPS id gy18sm2087911bkc.4.2012.09.24.08.21.14
	(version=SSLv3 cipher=OTHER); Mon, 24 Sep 2012 08:21:14 -0700 (PDT)
Message-ID: <50607A68.2090604@xen.org>
Date: Mon, 24 Sep 2012 16:21:12 +0100
From: Lars Kurth <lars.kurth@xen.org>
User-Agent: Mozilla/5.0 (Windows NT 6.1;
	rv:15.0) Gecko/20120907 Thunderbird/15.0.1
MIME-Version: 1.0
To: Grant McWilliams <grantmasterflash@gmail.com>
References: <CAGnmK4wB3ZJ3Tb9-VFgWCkcZNwibDzRYV8tvb14vLgw1wj2awQ@mail.gmail.com>
In-Reply-To: <CAGnmK4wB3ZJ3Tb9-VFgWCkcZNwibDzRYV8tvb14vLgw1wj2awQ@mail.gmail.com>
Cc: xen-devel@lists.xensource.com, xen-api@lists.xensource.com
Subject: Re: [Xen-devel] Proposal - Add xe manpages to xen-org
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

Grant,

this sounds like a fantastic idea. I will leave this for community 
discussion for now, and follow-up whether we need a formal vote in about 
a week's time. I guess there is also some detail to sort out such as 
repo name, exact location, anything legal (e.g. does the source have GPL 
headers), etc.

Best Regards
Lars

On 24/09/2012 16:06, Grant McWilliams wrote:
> Xen Community,
>
>     I have a team of people frantically creating manpages for the xe 
> command and all of it's 361 subcommands. The initial source 
> documentation is in asciidoc but also saved as Docbook. From docbook 
> we transform to epub, html, manpage and pdf. This is currently being 
> hosted in a subversion server at a Seattle area college and we'd like 
> to move it to the xen-org github so it's public, can be reviewed, 
> commented on and contributed too.
>
> We will also document the additional commands specific to 
> xenserver/xcp (xe-edit-bootloader and others like it as time permits.
>
> For each section of commands we're also writing xcp tools that 
> describe how to script the xe command and use it's various 
> options/parameters. These tools have been a godsend in our own 
> administration so far and should be packages and distributed themselves.
>
> All of our documentation is created with future XSLT transforms being 
> able to include or remove sections with the Administration guide and 
> xe help in mind.
>
> This is an official proposal to add this project to xen-org.
>
>
> Grant McWilliams
> Professor of Computer Science
> Edmonds Community College
>


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 24 15:22:02 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Sep 2012 15: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 1TGATp-0005gK-9Z; Mon, 24 Sep 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 <andreslc@gridcentric.ca>) id 1TGATo-0005g3-7A
	for xen-devel@lists.xen.org; Mon, 24 Sep 2012 15:21:52 +0000
Received: from [85.158.143.35:45493] by server-2.bemta-4.messagelabs.com id
	1F/22-06610-F8A70605; Mon, 24 Sep 2012 15:21:51 +0000
X-Env-Sender: andreslc@gridcentric.ca
X-Msg-Ref: server-5.tower-21.messagelabs.com!1348500109!3915387!1
X-Originating-IP: [209.85.223.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4975 invoked from network); 24 Sep 2012 15:21:50 -0000
Received: from mail-ie0-f173.google.com (HELO mail-ie0-f173.google.com)
	(209.85.223.173)
	by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Sep 2012 15:21:50 -0000
Received: by iea17 with SMTP id 17so8245409iea.32
	for <xen-devel@lists.xen.org>; Mon, 24 Sep 2012 08:21:48 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=subject:mime-version:content-type:from:in-reply-to:date:cc
	:content-transfer-encoding:message-id:references:to:x-mailer
	:x-gm-message-state;
	bh=VmreLFqMyUJY97jKEKA4WVIlGe6w9jAp7zIXXa+nKO8=;
	b=O8XhO1l0/5Q2hVJMn7qCxHz5t9qQ2EkCzWG8xzmEE7RoeTjYVeb6H3PnRGJrZ3AdaO
	Ogrk4ynm6fqCOpP5dYfSK19DbStO+uyb+pWLHZ2TmeC4G28VKt3H/YUCOzP8baJL+IPo
	o54LLB4JU+cjbgas7cH2nVQ1Wp2WHhDeCl0VHbA40IIrHujxDqpunMjleh2r7TlLk9I/
	Zy1NxPqNdT5QtwDk2a7VNWAOXrlbN/eQCcDn6Hgd8IrzMMWzpUJX1ufPgHJrokhJNdUk
	ZciOjAb6bDB2WJ7UB+03/S9zD+2QgRMP6sH7LlYa9Sala4ql8/vrykZ5XJQO2wYbjhNt
	xyww==
Received: by 10.50.149.228 with SMTP id ud4mr5549424igb.16.1348500108775;
	Mon, 24 Sep 2012 08:21:48 -0700 (PDT)
Received: from [192.168.7.210] ([206.223.182.18])
	by mx.google.com with ESMTPS id uj6sm11205691igb.4.2012.09.24.08.21.47
	(version=TLSv1/SSLv3 cipher=OTHER);
	Mon, 24 Sep 2012 08:21:48 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1278)
From: Andres Lagar-Cavilla <andreslc@gridcentric.ca>
In-Reply-To: <20120924150616.GA694@phenom.dumpdata.com>
Date: Mon, 24 Sep 2012 11:21:51 -0400
Message-Id: <D5DA2BFE-803C-4195-808D-F8E4DDA20B17@gridcentric.ca>
References: <1348242767-23732-1-git-send-email-oliver.chick@citrix.com>
	<20120921184123.GA27502@phenom.dumpdata.com>
	<20120921185622.GA5042@phenom.dumpdata.com>
	<20120921204646.GB30614@phenom.dumpdata.com>
	<43E8FEC9-DE7D-4352-87F2-63FB8984D556@gridcentric.ca>
	<20120924150616.GA694@phenom.dumpdata.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
X-Mailer: Apple Mail (2.1278)
X-Gm-Message-State: ALoCoQlN37A/J54Mj0OaMmPlalvE4/HPxplLXH2cHbPtNIIwGUStBiW/If5mQXaFHvAQ4O0KCpNH
Cc: Andres Lagar-Cavilla <andreslc@gridcentric.ca>,
	Oliver Chick <oliver.chick@citrix.com>, linux-kernel@vger.kernel.org,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v2] Persistent grant maps for xen blk drivers
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Sep 24, 2012, at 11:06 AM, Konrad Rzeszutek Wilk wrote:

> On Mon, Sep 24, 2012 at 10:38:48AM -0400, Andres Lagar-Cavilla wrote:
>> On Sep 21, 2012, at 4:46 PM, Konrad Rzeszutek Wilk wrote:
>> 
>>> On Fri, Sep 21, 2012 at 02:56:22PM -0400, Konrad Rzeszutek Wilk wrote:
>>>>> *: With a PVHVM guest I get
>>>>> 
>>>>> [  261.927218] privcmd_fault: vma=ffff88002a31dce8 7f4edc095000-7f4edc195000, pgoff=c8, uv=00007f4edc15d000
>>>>> 
>>>>> thought if I applied your patch on top of v3.6-rc6 I didn't see the privcmd_fault but
>>>>> I did see the guest crash.
>>>> 
>>>> And that is due to c571898ffc24a1768e1b2dabeac0fc7dd4c14601 which I've reverted in my
>>>> #linux-next branch
>>> 
>>> Nevermind. Andres' patch by itself (so without yours) works just fine. There is
>>> something your patch and his aren't agreeing on.
>> 
>> Apart from interacting badly in combination, would either patch in isolation work well?
> 
> "work well" is not exactly the right phase I would use.
> 
> Your patch by itself (so on top v3.6-rc6) works great.
> On top of #linux-next (so v3.6-rc6 + lot of other patches for v3.7) works great.
> 
> Oliver's patch for blkback/blkfront on top of v3.6-rc6 falls flat on its face in the guest.
> Oliver's patch for blkback/blkfront on top of v3.6-rc6 + lot of other patches for v3.7 - your patch)
> falls flat on its face in the guest.
> 
> Oliver's patch for blkback/blkfront on top of v3.6-rc6 + lot of other patches for v3.7 + your patch)
> falls flat on its face in the backend with the privcmd_fault.
> 
> I think I need to figure on what tree does Oliver's patch work properly and
> figure out why it dies first in the guest and then find out why in the backend
> it dies with your patch.
> 
> Your patch is still on the train for v3.7
I saw. Great!

> 
>> 
>> I can think of only one hunk in my patch disagreeing with blkback stuff:
> 
> I can try it out.. but I am not going to get to it today or in the next
> few days.

It would seem from your testing matrix above the issue lies somewhere deeper within the blk* patches. I'll watch from the sidelines, please keep me in the loop.

Thanks,
Andres

> 
>> diff --git a/drivers/xen/grant-table.c b/drivers/xen/grant-table.c
>> index eea81cf..f5681c8 100644
>> --- a/drivers/xen/grant-table.c
>> +++ b/drivers/xen/grant-table.c
>> @@ -836,6 +883,12 @@ int gnttab_map_refs(struct gnttab_map_grant_ref *map_ops,
>> 	if (ret)
>> 		return ret;
>> 
>> +	/* Retry eagain maps */
>> +	for (i = 0; i < count; i++)
>> +		if (map_ops[i].status == GNTST_eagain)
>> +			gnttab_retry_eagain_gop(GNTTABOP_map_grant_ref, map_ops + i,
>> +                                    &map_ops[i].status, __func__);
>> +
>> 	if (xen_feature(XENFEAT_auto_translated_physmap))
>> 		return ret;
>> 
>> How would you like to proceed?
>> Andres
>> 
>>> 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 24 15:22:02 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Sep 2012 15: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 1TGATp-0005gK-9Z; Mon, 24 Sep 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 <andreslc@gridcentric.ca>) id 1TGATo-0005g3-7A
	for xen-devel@lists.xen.org; Mon, 24 Sep 2012 15:21:52 +0000
Received: from [85.158.143.35:45493] by server-2.bemta-4.messagelabs.com id
	1F/22-06610-F8A70605; Mon, 24 Sep 2012 15:21:51 +0000
X-Env-Sender: andreslc@gridcentric.ca
X-Msg-Ref: server-5.tower-21.messagelabs.com!1348500109!3915387!1
X-Originating-IP: [209.85.223.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4975 invoked from network); 24 Sep 2012 15:21:50 -0000
Received: from mail-ie0-f173.google.com (HELO mail-ie0-f173.google.com)
	(209.85.223.173)
	by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Sep 2012 15:21:50 -0000
Received: by iea17 with SMTP id 17so8245409iea.32
	for <xen-devel@lists.xen.org>; Mon, 24 Sep 2012 08:21:48 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=subject:mime-version:content-type:from:in-reply-to:date:cc
	:content-transfer-encoding:message-id:references:to:x-mailer
	:x-gm-message-state;
	bh=VmreLFqMyUJY97jKEKA4WVIlGe6w9jAp7zIXXa+nKO8=;
	b=O8XhO1l0/5Q2hVJMn7qCxHz5t9qQ2EkCzWG8xzmEE7RoeTjYVeb6H3PnRGJrZ3AdaO
	Ogrk4ynm6fqCOpP5dYfSK19DbStO+uyb+pWLHZ2TmeC4G28VKt3H/YUCOzP8baJL+IPo
	o54LLB4JU+cjbgas7cH2nVQ1Wp2WHhDeCl0VHbA40IIrHujxDqpunMjleh2r7TlLk9I/
	Zy1NxPqNdT5QtwDk2a7VNWAOXrlbN/eQCcDn6Hgd8IrzMMWzpUJX1ufPgHJrokhJNdUk
	ZciOjAb6bDB2WJ7UB+03/S9zD+2QgRMP6sH7LlYa9Sala4ql8/vrykZ5XJQO2wYbjhNt
	xyww==
Received: by 10.50.149.228 with SMTP id ud4mr5549424igb.16.1348500108775;
	Mon, 24 Sep 2012 08:21:48 -0700 (PDT)
Received: from [192.168.7.210] ([206.223.182.18])
	by mx.google.com with ESMTPS id uj6sm11205691igb.4.2012.09.24.08.21.47
	(version=TLSv1/SSLv3 cipher=OTHER);
	Mon, 24 Sep 2012 08:21:48 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1278)
From: Andres Lagar-Cavilla <andreslc@gridcentric.ca>
In-Reply-To: <20120924150616.GA694@phenom.dumpdata.com>
Date: Mon, 24 Sep 2012 11:21:51 -0400
Message-Id: <D5DA2BFE-803C-4195-808D-F8E4DDA20B17@gridcentric.ca>
References: <1348242767-23732-1-git-send-email-oliver.chick@citrix.com>
	<20120921184123.GA27502@phenom.dumpdata.com>
	<20120921185622.GA5042@phenom.dumpdata.com>
	<20120921204646.GB30614@phenom.dumpdata.com>
	<43E8FEC9-DE7D-4352-87F2-63FB8984D556@gridcentric.ca>
	<20120924150616.GA694@phenom.dumpdata.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
X-Mailer: Apple Mail (2.1278)
X-Gm-Message-State: ALoCoQlN37A/J54Mj0OaMmPlalvE4/HPxplLXH2cHbPtNIIwGUStBiW/If5mQXaFHvAQ4O0KCpNH
Cc: Andres Lagar-Cavilla <andreslc@gridcentric.ca>,
	Oliver Chick <oliver.chick@citrix.com>, linux-kernel@vger.kernel.org,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v2] Persistent grant maps for xen blk drivers
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Sep 24, 2012, at 11:06 AM, Konrad Rzeszutek Wilk wrote:

> On Mon, Sep 24, 2012 at 10:38:48AM -0400, Andres Lagar-Cavilla wrote:
>> On Sep 21, 2012, at 4:46 PM, Konrad Rzeszutek Wilk wrote:
>> 
>>> On Fri, Sep 21, 2012 at 02:56:22PM -0400, Konrad Rzeszutek Wilk wrote:
>>>>> *: With a PVHVM guest I get
>>>>> 
>>>>> [  261.927218] privcmd_fault: vma=ffff88002a31dce8 7f4edc095000-7f4edc195000, pgoff=c8, uv=00007f4edc15d000
>>>>> 
>>>>> thought if I applied your patch on top of v3.6-rc6 I didn't see the privcmd_fault but
>>>>> I did see the guest crash.
>>>> 
>>>> And that is due to c571898ffc24a1768e1b2dabeac0fc7dd4c14601 which I've reverted in my
>>>> #linux-next branch
>>> 
>>> Nevermind. Andres' patch by itself (so without yours) works just fine. There is
>>> something your patch and his aren't agreeing on.
>> 
>> Apart from interacting badly in combination, would either patch in isolation work well?
> 
> "work well" is not exactly the right phase I would use.
> 
> Your patch by itself (so on top v3.6-rc6) works great.
> On top of #linux-next (so v3.6-rc6 + lot of other patches for v3.7) works great.
> 
> Oliver's patch for blkback/blkfront on top of v3.6-rc6 falls flat on its face in the guest.
> Oliver's patch for blkback/blkfront on top of v3.6-rc6 + lot of other patches for v3.7 - your patch)
> falls flat on its face in the guest.
> 
> Oliver's patch for blkback/blkfront on top of v3.6-rc6 + lot of other patches for v3.7 + your patch)
> falls flat on its face in the backend with the privcmd_fault.
> 
> I think I need to figure on what tree does Oliver's patch work properly and
> figure out why it dies first in the guest and then find out why in the backend
> it dies with your patch.
> 
> Your patch is still on the train for v3.7
I saw. Great!

> 
>> 
>> I can think of only one hunk in my patch disagreeing with blkback stuff:
> 
> I can try it out.. but I am not going to get to it today or in the next
> few days.

It would seem from your testing matrix above the issue lies somewhere deeper within the blk* patches. I'll watch from the sidelines, please keep me in the loop.

Thanks,
Andres

> 
>> diff --git a/drivers/xen/grant-table.c b/drivers/xen/grant-table.c
>> index eea81cf..f5681c8 100644
>> --- a/drivers/xen/grant-table.c
>> +++ b/drivers/xen/grant-table.c
>> @@ -836,6 +883,12 @@ int gnttab_map_refs(struct gnttab_map_grant_ref *map_ops,
>> 	if (ret)
>> 		return ret;
>> 
>> +	/* Retry eagain maps */
>> +	for (i = 0; i < count; i++)
>> +		if (map_ops[i].status == GNTST_eagain)
>> +			gnttab_retry_eagain_gop(GNTTABOP_map_grant_ref, map_ops + i,
>> +                                    &map_ops[i].status, __func__);
>> +
>> 	if (xen_feature(XENFEAT_auto_translated_physmap))
>> 		return ret;
>> 
>> How would you like to proceed?
>> Andres
>> 
>>> 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 24 15:23:38 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Sep 2012 15:23:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGAVM-0005tO-TZ; Mon, 24 Sep 2012 15:23: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 1TGAVL-0005t9-AJ
	for Xen-devel@lists.xensource.com; Mon, 24 Sep 2012 15:23:27 +0000
Received: from [85.158.139.83:29236] by server-11.bemta-5.messagelabs.com id
	64/62-13866-EEA70605; Mon, 24 Sep 2012 15:23:26 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1348500205!24556957!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTA4NDk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10348 invoked from network); 24 Sep 2012 15:23:26 -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;
	24 Sep 2012 15:23:26 -0000
X-IronPort-AV: E=Sophos;i="4.80,476,1344211200"; d="scan'208";a="14728513"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Sep 2012 15:23: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.279.1;
	Mon, 24 Sep 2012 16:23:25 +0100
Message-ID: <1348500204.3452.93.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Date: Mon, 24 Sep 2012 16:23:24 +0100
In-Reply-To: <alpine.DEB.2.02.1209241613160.29232@kaball.uk.xensource.com>
References: <20120921121202.3163c379@mantra.us.oracle.com>
	<alpine.DEB.2.02.1209241613160.29232@kaball.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH v1 0/8]: PVH (PV guest with extensions)u
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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-09-24 at 16:16 +0100, Stefano Stabellini wrote:
> On Fri, 21 Sep 2012, Mukesh Rathor wrote:
> > Hi guys,
> > 
> > Ok, I've made all the changes from prev RFC patch submission. Tested
> > all the combinations. The patches are a bit smaller from before, and
> > couldn't be separated like before, so I can't state whats different in
> > each patch. But, it's not too bad to review now.
> > 
> > As before, they were built on top of
> > fc6bdb59a501740b28ed3b616641a22c8dc5dd31 from the following tree:
> >         
> > git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
> 
> The patch series is not in a bad state. It is reasonable to aim for a
> merge in 3.8.
> At least the xen_remap_domain_mfn_range, ballooning and privcmd changes,
> which interfaces are going to be shared with Xen on ARM ;-)

Indeed, I intend to rebase my ARM patches to use these ASAP, if not this
week then when I get back from my long weekend vacation next week.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 24 15:23:38 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Sep 2012 15:23:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGAVM-0005tO-TZ; Mon, 24 Sep 2012 15:23: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 1TGAVL-0005t9-AJ
	for Xen-devel@lists.xensource.com; Mon, 24 Sep 2012 15:23:27 +0000
Received: from [85.158.139.83:29236] by server-11.bemta-5.messagelabs.com id
	64/62-13866-EEA70605; Mon, 24 Sep 2012 15:23:26 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1348500205!24556957!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTA4NDk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10348 invoked from network); 24 Sep 2012 15:23:26 -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;
	24 Sep 2012 15:23:26 -0000
X-IronPort-AV: E=Sophos;i="4.80,476,1344211200"; d="scan'208";a="14728513"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Sep 2012 15:23: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.279.1;
	Mon, 24 Sep 2012 16:23:25 +0100
Message-ID: <1348500204.3452.93.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Date: Mon, 24 Sep 2012 16:23:24 +0100
In-Reply-To: <alpine.DEB.2.02.1209241613160.29232@kaball.uk.xensource.com>
References: <20120921121202.3163c379@mantra.us.oracle.com>
	<alpine.DEB.2.02.1209241613160.29232@kaball.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH v1 0/8]: PVH (PV guest with extensions)u
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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-09-24 at 16:16 +0100, Stefano Stabellini wrote:
> On Fri, 21 Sep 2012, Mukesh Rathor wrote:
> > Hi guys,
> > 
> > Ok, I've made all the changes from prev RFC patch submission. Tested
> > all the combinations. The patches are a bit smaller from before, and
> > couldn't be separated like before, so I can't state whats different in
> > each patch. But, it's not too bad to review now.
> > 
> > As before, they were built on top of
> > fc6bdb59a501740b28ed3b616641a22c8dc5dd31 from the following tree:
> >         
> > git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
> 
> The patch series is not in a bad state. It is reasonable to aim for a
> merge in 3.8.
> At least the xen_remap_domain_mfn_range, ballooning and privcmd changes,
> which interfaces are going to be shared with Xen on ARM ;-)

Indeed, I intend to rebase my ARM patches to use these ASAP, if not this
week then when I get back from my long weekend vacation next week.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 24 15:24:45 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Sep 2012 15:24:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGAWS-00062X-D5; Mon, 24 Sep 2012 15:24:36 +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 1TGAWQ-00062D-H3
	for xen-devel@lists.xensource.com; Mon, 24 Sep 2012 15:24:34 +0000
Received: from [85.158.139.211:3297] by server-1.bemta-5.messagelabs.com id
	4E/3C-09825-13B70605; Mon, 24 Sep 2012 15:24:33 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-15.tower-206.messagelabs.com!1348500271!19814374!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzA4OTE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10854 invoked from network); 24 Sep 2012 15:24:33 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-15.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Sep 2012 15:24:33 -0000
X-IronPort-AV: E=Sophos;i="4.80,476,1344211200"; d="scan'208";a="38957580"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Sep 2012 15:24:21 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1;
	Mon, 24 Sep 2012 11:24:21 -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 1TGAWC-0002gD-UF;
	Mon, 24 Sep 2012 16:24:20 +0100
MIME-Version: 1.0
X-Mercurial-Node: 7e332fd064fac8d9d1cea904d5236c8d74389194
Message-ID: <7e332fd064fac8d9d1ce.1348499997@elijah>
User-Agent: Mercurial-patchbomb/2.0.2
Date: Mon, 24 Sep 2012 16:19:57 +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] docs: Document scheduler-related Xen
	command-line options
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

# HG changeset patch
# User George Dunlap <george.dunlap@eu.citrix.com>
# Date 1348499935 -3600
# Node ID 7e332fd064fac8d9d1cea904d5236c8d74389194
# Parent  7b045d43e59dcb42340097058502bf456e151180
docs: Document scheduler-related Xen command-line options

Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>

diff --git a/docs/misc/xen-command-line.markdown b/docs/misc/xen-command-line.markdown
--- a/docs/misc/xen-command-line.markdown
+++ b/docs/misc/xen-command-line.markdown
@@ -732,12 +732,34 @@ Choose the default scheduler.
 ### sched\_credit\_tslice\_ms
 > `= <integer>`
 
+Set the timeslice of the credit1 scheduler, in milliseconds.  The
+default is 30ms.  Reasonable values may include 10, 5, or even 1 for
+very latency-sensitive workloads.
+
 ### sched\_ratelimit\_us
 > `= <integer>`
 
+In order to limit the rate of context switching, set the minimum
+amount of time that a vcpu can be scheduled for before preempting it,
+in microseconds.  The default is 1000us (1ms).  Setting this to 0
+disables it altogether.
+
 ### sched\_smt\_power\_savings
 > `= <boolean>`
 
+Normally Xen will try to maximize performance and cache utilization by
+spreading out vcpus across as many different divisions as possible
+(i.e, numa nodes, sockets, cores threads, &c).  This often maximizes
+throughput, but also maximizes energy usage, since it reduces the
+depth to which a processor can sleep.
+
+This option inverts the logic, so that the scheduler in effect tries
+to keep the vcpus on the smallest amount of silicon possible; i.e.,
+first fill up sibling threads, then sibling cores, then sibling
+sockets, &c.  This will reduce performance somewhat, particularly on
+systems with hyperthreading enabled, but should reduce power by
+enabling more sockets and cores to go into deeper sleep states.
+
 ### serial\_tx\_buffer
 > `= <size>`
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 24 15:24:45 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Sep 2012 15:24:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGAWS-00062X-D5; Mon, 24 Sep 2012 15:24:36 +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 1TGAWQ-00062D-H3
	for xen-devel@lists.xensource.com; Mon, 24 Sep 2012 15:24:34 +0000
Received: from [85.158.139.211:3297] by server-1.bemta-5.messagelabs.com id
	4E/3C-09825-13B70605; Mon, 24 Sep 2012 15:24:33 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-15.tower-206.messagelabs.com!1348500271!19814374!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzA4OTE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10854 invoked from network); 24 Sep 2012 15:24:33 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-15.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Sep 2012 15:24:33 -0000
X-IronPort-AV: E=Sophos;i="4.80,476,1344211200"; d="scan'208";a="38957580"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Sep 2012 15:24:21 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1;
	Mon, 24 Sep 2012 11:24:21 -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 1TGAWC-0002gD-UF;
	Mon, 24 Sep 2012 16:24:20 +0100
MIME-Version: 1.0
X-Mercurial-Node: 7e332fd064fac8d9d1cea904d5236c8d74389194
Message-ID: <7e332fd064fac8d9d1ce.1348499997@elijah>
User-Agent: Mercurial-patchbomb/2.0.2
Date: Mon, 24 Sep 2012 16:19:57 +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] docs: Document scheduler-related Xen
	command-line options
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

# HG changeset patch
# User George Dunlap <george.dunlap@eu.citrix.com>
# Date 1348499935 -3600
# Node ID 7e332fd064fac8d9d1cea904d5236c8d74389194
# Parent  7b045d43e59dcb42340097058502bf456e151180
docs: Document scheduler-related Xen command-line options

Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>

diff --git a/docs/misc/xen-command-line.markdown b/docs/misc/xen-command-line.markdown
--- a/docs/misc/xen-command-line.markdown
+++ b/docs/misc/xen-command-line.markdown
@@ -732,12 +732,34 @@ Choose the default scheduler.
 ### sched\_credit\_tslice\_ms
 > `= <integer>`
 
+Set the timeslice of the credit1 scheduler, in milliseconds.  The
+default is 30ms.  Reasonable values may include 10, 5, or even 1 for
+very latency-sensitive workloads.
+
 ### sched\_ratelimit\_us
 > `= <integer>`
 
+In order to limit the rate of context switching, set the minimum
+amount of time that a vcpu can be scheduled for before preempting it,
+in microseconds.  The default is 1000us (1ms).  Setting this to 0
+disables it altogether.
+
 ### sched\_smt\_power\_savings
 > `= <boolean>`
 
+Normally Xen will try to maximize performance and cache utilization by
+spreading out vcpus across as many different divisions as possible
+(i.e, numa nodes, sockets, cores threads, &c).  This often maximizes
+throughput, but also maximizes energy usage, since it reduces the
+depth to which a processor can sleep.
+
+This option inverts the logic, so that the scheduler in effect tries
+to keep the vcpus on the smallest amount of silicon possible; i.e.,
+first fill up sibling threads, then sibling cores, then sibling
+sockets, &c.  This will reduce performance somewhat, particularly on
+systems with hyperthreading enabled, but should reduce power by
+enabling more sockets and cores to go into deeper sleep states.
+
 ### serial\_tx\_buffer
 > `= <size>`
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 24 15:24:58 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Sep 2012 15:24:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGAWe-000651-QA; Mon, 24 Sep 2012 15:24: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 1TGAWe-00064e-2f
	for xen-devel@lists.xensource.com; Mon, 24 Sep 2012 15:24:48 +0000
Received: from [85.158.143.35:4245] by server-1.bemta-4.messagelabs.com id
	CD/45-05684-F3B70605; Mon, 24 Sep 2012 15:24:47 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1348500285!13539364!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNzcwMDM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7310 invoked from network); 24 Sep 2012 15:24:46 -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;
	24 Sep 2012 15:24:46 -0000
X-IronPort-AV: E=Sophos;i="4.80,476,1344211200"; d="scan'208";a="209144624"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Sep 2012 15:24:26 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1;
	Mon, 24 Sep 2012 11:24:26 -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 1TGAWH-0002gy-JL;
	Mon, 24 Sep 2012 16:24:25 +0100
MIME-Version: 1.0
X-Mercurial-Node: e45a63da20e99291fa7e98697a9713aa89b98316
Message-ID: <e45a63da20e99291fa7e.1348500002@elijah>
User-Agent: Mercurial-patchbomb/2.0.2
Date: Mon, 24 Sep 2012 16:20:02 +0100
From: George Dunlap <george.dunlap@eu.citrix.com>
To: xen-devel@lists.xensource.com
Cc: george.dunlap@eu.citrix.com
Subject: [Xen-devel] [PATCH] xen: Remove sched_credit_default_yield 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 George Dunlap <george.dunlap@eu.citrix.com>
# Date 1348499942 -3600
# Node ID e45a63da20e99291fa7e98697a9713aa89b98316
# Parent  7e332fd064fac8d9d1cea904d5236c8d74389194
xen: Remove sched_credit_default_yield option

The sched_credit_default_yield option was added when the behavior of
"SCHEDOP_yield" was changed in 4.1, to allow any users who had
problems to revert to the old behavior.  The new behavior has been in
Xen.org xen since 4.1, and in XenServer even longer, and there is no
evidence of anyone having trouble with it.  Remove the option.

Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>

diff --git a/docs/misc/xen-command-line.markdown b/docs/misc/xen-command-line.markdown
--- a/docs/misc/xen-command-line.markdown
+++ b/docs/misc/xen-command-line.markdown
@@ -726,9 +726,6 @@ Choose the default scheduler.
 ### sched\_credit2\_migrate\_resist
 > `= <integer>`
 
-### sched\_credit\_default\_yield
-> `= <boolean>`
-
 ### sched\_credit\_tslice\_ms
 > `= <integer>`
 
diff --git a/xen/common/sched_credit.c b/xen/common/sched_credit.c
--- a/xen/common/sched_credit.c
+++ b/xen/common/sched_credit.c
@@ -103,8 +103,6 @@
 /*
  * Boot parameters
  */
-static bool_t __read_mostly sched_credit_default_yield;
-boolean_param("sched_credit_default_yield", sched_credit_default_yield);
 static int __read_mostly sched_credit_tslice_ms = CSCHED_DEFAULT_TSLICE_MS;
 integer_param("sched_credit_tslice_ms", sched_credit_tslice_ms);
 
@@ -783,11 +781,8 @@ csched_vcpu_yield(const struct scheduler
 {
     struct csched_vcpu * const sv = CSCHED_VCPU(vc);
 
-    if ( !sched_credit_default_yield )
-    {
-        /* Let the scheduler know that this vcpu is trying to yield */
-        sv->flags |= CSCHED_FLAG_VCPU_YIELD;
-    }
+    /* Let the scheduler know that this vcpu is trying to yield */
+    sv->flags |= CSCHED_FLAG_VCPU_YIELD;
 }
 
 static int

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 24 15:24:58 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Sep 2012 15:24:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGAWe-000651-QA; Mon, 24 Sep 2012 15:24: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 1TGAWe-00064e-2f
	for xen-devel@lists.xensource.com; Mon, 24 Sep 2012 15:24:48 +0000
Received: from [85.158.143.35:4245] by server-1.bemta-4.messagelabs.com id
	CD/45-05684-F3B70605; Mon, 24 Sep 2012 15:24:47 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1348500285!13539364!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNzcwMDM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7310 invoked from network); 24 Sep 2012 15:24:46 -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;
	24 Sep 2012 15:24:46 -0000
X-IronPort-AV: E=Sophos;i="4.80,476,1344211200"; d="scan'208";a="209144624"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Sep 2012 15:24:26 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1;
	Mon, 24 Sep 2012 11:24:26 -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 1TGAWH-0002gy-JL;
	Mon, 24 Sep 2012 16:24:25 +0100
MIME-Version: 1.0
X-Mercurial-Node: e45a63da20e99291fa7e98697a9713aa89b98316
Message-ID: <e45a63da20e99291fa7e.1348500002@elijah>
User-Agent: Mercurial-patchbomb/2.0.2
Date: Mon, 24 Sep 2012 16:20:02 +0100
From: George Dunlap <george.dunlap@eu.citrix.com>
To: xen-devel@lists.xensource.com
Cc: george.dunlap@eu.citrix.com
Subject: [Xen-devel] [PATCH] xen: Remove sched_credit_default_yield 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 George Dunlap <george.dunlap@eu.citrix.com>
# Date 1348499942 -3600
# Node ID e45a63da20e99291fa7e98697a9713aa89b98316
# Parent  7e332fd064fac8d9d1cea904d5236c8d74389194
xen: Remove sched_credit_default_yield option

The sched_credit_default_yield option was added when the behavior of
"SCHEDOP_yield" was changed in 4.1, to allow any users who had
problems to revert to the old behavior.  The new behavior has been in
Xen.org xen since 4.1, and in XenServer even longer, and there is no
evidence of anyone having trouble with it.  Remove the option.

Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>

diff --git a/docs/misc/xen-command-line.markdown b/docs/misc/xen-command-line.markdown
--- a/docs/misc/xen-command-line.markdown
+++ b/docs/misc/xen-command-line.markdown
@@ -726,9 +726,6 @@ Choose the default scheduler.
 ### sched\_credit2\_migrate\_resist
 > `= <integer>`
 
-### sched\_credit\_default\_yield
-> `= <boolean>`
-
 ### sched\_credit\_tslice\_ms
 > `= <integer>`
 
diff --git a/xen/common/sched_credit.c b/xen/common/sched_credit.c
--- a/xen/common/sched_credit.c
+++ b/xen/common/sched_credit.c
@@ -103,8 +103,6 @@
 /*
  * Boot parameters
  */
-static bool_t __read_mostly sched_credit_default_yield;
-boolean_param("sched_credit_default_yield", sched_credit_default_yield);
 static int __read_mostly sched_credit_tslice_ms = CSCHED_DEFAULT_TSLICE_MS;
 integer_param("sched_credit_tslice_ms", sched_credit_tslice_ms);
 
@@ -783,11 +781,8 @@ csched_vcpu_yield(const struct scheduler
 {
     struct csched_vcpu * const sv = CSCHED_VCPU(vc);
 
-    if ( !sched_credit_default_yield )
-    {
-        /* Let the scheduler know that this vcpu is trying to yield */
-        sv->flags |= CSCHED_FLAG_VCPU_YIELD;
-    }
+    /* Let the scheduler know that this vcpu is trying to yield */
+    sv->flags |= CSCHED_FLAG_VCPU_YIELD;
 }
 
 static int

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 24 15:29:55 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Sep 2012 15:29: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 1TGAbP-0006Rf-Ho; Mon, 24 Sep 2012 15:29:43 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <grantmasterflash@gmail.com>) id 1TGAFd-0004nr-4A
	for xen-devel@lists.xensource.com; Mon, 24 Sep 2012 15:07:13 +0000
Received: from [85.158.137.99:55939] by server-6.bemta-3.messagelabs.com id
	B3/D2-29694-F1770605; Mon, 24 Sep 2012 15:07:11 +0000
X-Env-Sender: grantmasterflash@gmail.com
X-Msg-Ref: server-3.tower-217.messagelabs.com!1348499229!13864518!1
X-Originating-IP: [209.85.212.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-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28033 invoked from network); 24 Sep 2012 15:07:11 -0000
Received: from mail-vb0-f43.google.com (HELO mail-vb0-f43.google.com)
	(209.85.212.43)
	by server-3.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Sep 2012 15:07:11 -0000
Received: by vbbfq11 with SMTP id fq11so7695877vbb.30
	for <multiple recipients>; Mon, 24 Sep 2012 08:07:09 -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=dqPbFrJwBtU7dOhX/T8GP+vw2yNR/KVyL+TW8dmIWuY=;
	b=bY+Ova0c0T6HAEVpJ1s4zkNfgWPFfrH+q/cnLAQ3eCSkRCe1QAFLwwfpL/nKNTNvr7
	QTY/yls2z0Cj/VnWbWK4bktnXrTCjFBszvQpHxfZY7XoEWFmmbXwUtK6dInt1anFqlbm
	JNZW9+iOJSQpTtafrlT4RAi8cvbt9GiOFWocf+qm8NgiotZ8kOBvP+r5xC2MTxveRh/L
	8eXAOKzELC5IkY1AYQqNocasp3jDew99a9CGaRw9w0pbeiPG6Z/d3EYgpXQkgDE7myaB
	xe6sJBX1jKlx5FzxJnsJS+a54/SdO8F/2j9WWsR4WGXhpjlXBx1Y6ZgFUlM7AS0vmC/g
	COrw==
Received: by 10.52.175.130 with SMTP id ca2mr6138569vdc.112.1348499229302;
	Mon, 24 Sep 2012 08:07:09 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.58.102.48 with HTTP; Mon, 24 Sep 2012 08:06:29 -0700 (PDT)
From: Grant McWilliams <grantmasterflash@gmail.com>
Date: Mon, 24 Sep 2012 08:06:29 -0700
Message-ID: <CAGnmK4wB3ZJ3Tb9-VFgWCkcZNwibDzRYV8tvb14vLgw1wj2awQ@mail.gmail.com>
To: xen-devel@lists.xensource.com, xen-api@lists.xensource.com, 
	Lars Kurth <lars.kurth@xen.org>
X-Mailman-Approved-At: Mon, 24 Sep 2012 15:29:42 +0000
Subject: [Xen-devel] Proposal - Add xe manpages to xen-org
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============9028064006911643214=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============9028064006911643214==
Content-Type: multipart/alternative; boundary=bcaec5014c1d8adec904ca73f1c9

--bcaec5014c1d8adec904ca73f1c9
Content-Type: text/plain; charset=UTF-8

Xen Community,

    I have a team of people frantically creating manpages for the xe
command and all of it's 361 subcommands. The initial source documentation
is in asciidoc but also saved as Docbook. From docbook we transform to
epub, html, manpage and pdf. This is currently being hosted in a subversion
server at a Seattle area college and we'd like to move it to the xen-org
github so it's public, can be reviewed, commented on and contributed too.

We will also document the additional commands specific to xenserver/xcp
(xe-edit-bootloader and others like it as time permits.

For each section of commands we're also writing xcp tools that describe how
to script the xe command and use it's various options/parameters. These
tools have been a godsend in our own administration so far and should be
packages and distributed themselves.

All of our documentation is created with future XSLT transforms being able
to include or remove sections with the Administration guide and xe help in
mind.

This is an official proposal to add this project to xen-org.


Grant McWilliams
Professor of Computer Science
Edmonds Community College

--bcaec5014c1d8adec904ca73f1c9
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div>Xen Community,</div><div><br></div><div>=C2=A0 =C2=A0 I have a team of=
 people frantically creating manpages for the xe command and all of it&#39;=
s 361 subcommands. The initial source documentation is in asciidoc but also=
 saved as Docbook. From docbook we transform to epub, html, manpage and pdf=
. This is currently being hosted in a subversion server at a Seattle area c=
ollege and we&#39;d like to move it to the xen-org github so it&#39;s publi=
c, can be reviewed, commented on and contributed too.</div>

<div><br></div><div>We will also document the additional commands specific =
to xenserver/xcp (xe-edit-bootloader and others like it as time permits.</d=
iv><div><br></div><div>For each section of commands we&#39;re also writing =
xcp tools that describe how to script the xe command and use it&#39;s vario=
us options/parameters. These tools have been a godsend in our own administr=
ation so far and should be packages and distributed themselves.=C2=A0</div>

<div><br></div><div>All of our documentation is created with future XSLT tr=
ansforms being able to include or remove sections with the Administration g=
uide and xe help in mind.=C2=A0</div><div><br></div><div>This is an officia=
l proposal to add this project to xen-org.</div>

<div><br></div><br clear=3D"all">Grant McWilliams<br>Professor of Computer =
Science<div>Edmonds Community College<br><br>
</div>

--bcaec5014c1d8adec904ca73f1c9--


--===============9028064006911643214==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============9028064006911643214==--


From xen-devel-bounces@lists.xen.org Mon Sep 24 15:29:55 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Sep 2012 15:29: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 1TGAbP-0006Rf-Ho; Mon, 24 Sep 2012 15:29:43 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <grantmasterflash@gmail.com>) id 1TGAFd-0004nr-4A
	for xen-devel@lists.xensource.com; Mon, 24 Sep 2012 15:07:13 +0000
Received: from [85.158.137.99:55939] by server-6.bemta-3.messagelabs.com id
	B3/D2-29694-F1770605; Mon, 24 Sep 2012 15:07:11 +0000
X-Env-Sender: grantmasterflash@gmail.com
X-Msg-Ref: server-3.tower-217.messagelabs.com!1348499229!13864518!1
X-Originating-IP: [209.85.212.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-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28033 invoked from network); 24 Sep 2012 15:07:11 -0000
Received: from mail-vb0-f43.google.com (HELO mail-vb0-f43.google.com)
	(209.85.212.43)
	by server-3.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Sep 2012 15:07:11 -0000
Received: by vbbfq11 with SMTP id fq11so7695877vbb.30
	for <multiple recipients>; Mon, 24 Sep 2012 08:07:09 -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=dqPbFrJwBtU7dOhX/T8GP+vw2yNR/KVyL+TW8dmIWuY=;
	b=bY+Ova0c0T6HAEVpJ1s4zkNfgWPFfrH+q/cnLAQ3eCSkRCe1QAFLwwfpL/nKNTNvr7
	QTY/yls2z0Cj/VnWbWK4bktnXrTCjFBszvQpHxfZY7XoEWFmmbXwUtK6dInt1anFqlbm
	JNZW9+iOJSQpTtafrlT4RAi8cvbt9GiOFWocf+qm8NgiotZ8kOBvP+r5xC2MTxveRh/L
	8eXAOKzELC5IkY1AYQqNocasp3jDew99a9CGaRw9w0pbeiPG6Z/d3EYgpXQkgDE7myaB
	xe6sJBX1jKlx5FzxJnsJS+a54/SdO8F/2j9WWsR4WGXhpjlXBx1Y6ZgFUlM7AS0vmC/g
	COrw==
Received: by 10.52.175.130 with SMTP id ca2mr6138569vdc.112.1348499229302;
	Mon, 24 Sep 2012 08:07:09 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.58.102.48 with HTTP; Mon, 24 Sep 2012 08:06:29 -0700 (PDT)
From: Grant McWilliams <grantmasterflash@gmail.com>
Date: Mon, 24 Sep 2012 08:06:29 -0700
Message-ID: <CAGnmK4wB3ZJ3Tb9-VFgWCkcZNwibDzRYV8tvb14vLgw1wj2awQ@mail.gmail.com>
To: xen-devel@lists.xensource.com, xen-api@lists.xensource.com, 
	Lars Kurth <lars.kurth@xen.org>
X-Mailman-Approved-At: Mon, 24 Sep 2012 15:29:42 +0000
Subject: [Xen-devel] Proposal - Add xe manpages to xen-org
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============9028064006911643214=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============9028064006911643214==
Content-Type: multipart/alternative; boundary=bcaec5014c1d8adec904ca73f1c9

--bcaec5014c1d8adec904ca73f1c9
Content-Type: text/plain; charset=UTF-8

Xen Community,

    I have a team of people frantically creating manpages for the xe
command and all of it's 361 subcommands. The initial source documentation
is in asciidoc but also saved as Docbook. From docbook we transform to
epub, html, manpage and pdf. This is currently being hosted in a subversion
server at a Seattle area college and we'd like to move it to the xen-org
github so it's public, can be reviewed, commented on and contributed too.

We will also document the additional commands specific to xenserver/xcp
(xe-edit-bootloader and others like it as time permits.

For each section of commands we're also writing xcp tools that describe how
to script the xe command and use it's various options/parameters. These
tools have been a godsend in our own administration so far and should be
packages and distributed themselves.

All of our documentation is created with future XSLT transforms being able
to include or remove sections with the Administration guide and xe help in
mind.

This is an official proposal to add this project to xen-org.


Grant McWilliams
Professor of Computer Science
Edmonds Community College

--bcaec5014c1d8adec904ca73f1c9
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div>Xen Community,</div><div><br></div><div>=C2=A0 =C2=A0 I have a team of=
 people frantically creating manpages for the xe command and all of it&#39;=
s 361 subcommands. The initial source documentation is in asciidoc but also=
 saved as Docbook. From docbook we transform to epub, html, manpage and pdf=
. This is currently being hosted in a subversion server at a Seattle area c=
ollege and we&#39;d like to move it to the xen-org github so it&#39;s publi=
c, can be reviewed, commented on and contributed too.</div>

<div><br></div><div>We will also document the additional commands specific =
to xenserver/xcp (xe-edit-bootloader and others like it as time permits.</d=
iv><div><br></div><div>For each section of commands we&#39;re also writing =
xcp tools that describe how to script the xe command and use it&#39;s vario=
us options/parameters. These tools have been a godsend in our own administr=
ation so far and should be packages and distributed themselves.=C2=A0</div>

<div><br></div><div>All of our documentation is created with future XSLT tr=
ansforms being able to include or remove sections with the Administration g=
uide and xe help in mind.=C2=A0</div><div><br></div><div>This is an officia=
l proposal to add this project to xen-org.</div>

<div><br></div><br clear=3D"all">Grant McWilliams<br>Professor of Computer =
Science<div>Edmonds Community College<br><br>
</div>

--bcaec5014c1d8adec904ca73f1c9--


--===============9028064006911643214==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============9028064006911643214==--


From xen-devel-bounces@lists.xen.org Mon Sep 24 15:31:43 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Sep 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 1TGAdA-0006YG-6c; Mon, 24 Sep 2012 15:31:32 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony@overnetdata.com>) id 1TGAd9-0006Y9-LR
	for xen-devel@lists.xen.org; Mon, 24 Sep 2012 15:31:31 +0000
Received: from [85.158.138.51:15632] by server-3.bemta-3.messagelabs.com id
	A0/46-21322-2DC70605; Mon, 24 Sep 2012 15:31:30 +0000
X-Env-Sender: anthony@overnetdata.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1348500689!31281624!1
X-Originating-IP: [81.137.131.225]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19326 invoked from network); 24 Sep 2012 15:31:30 -0000
Received: from host81-137-131-225.in-addr.btopenworld.com (HELO
	zimbra.overnetdata.com) (81.137.131.225)
	by server-4.tower-174.messagelabs.com with SMTP;
	24 Sep 2012 15:31:30 -0000
Received: from localhost (localhost.localdomain [127.0.0.1])
	by zimbra.overnetdata.com (Postfix) with ESMTP id A2DC91617DA
	for <xen-devel@lists.xen.org>; Mon, 24 Sep 2012 16:31:29 +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 5uC+9NoAktvN for <xen-devel@lists.xen.org>;
	Mon, 24 Sep 2012 16:31:29 +0100 (BST)
Received: from [192.168.1.51] (unknown [192.168.1.51])
	by zimbra.overnetdata.com (Postfix) with ESMTPSA id 0811E161793
	for <xen-devel@lists.xen.org>; Mon, 24 Sep 2012 16:31:29 +0100 (BST)
Message-ID: <50607CCF.9050904@overnetdata.com>
Date: Mon, 24 Sep 2012 16:31:27 +0100
From: Anthony Wright <anthony@overnetdata.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:15.0) Gecko/20120907 Thunderbird/15.0.1
MIME-Version: 1.0
To: xen-devel@lists.xen.org
X-Enigmail-Version: 1.4.4
Subject: [Xen-devel] First DomU started goes into a busy loop
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On a  32 bit Xen 4.20 system with a 3.5.4 kernel around 40% of the time
when the system starts up the first DomU to be started goes into a busy
loop (always in state r----- which CPU constantly increasing) with no
console output. If I destroy the DomU and restart it with identical
settings, it starts correctly. I got the same happening with Xen 4.1
with a 3.5.3 kernel, but tried upgrading to see if that fixed it, but it
didn't.

If I connect to the console there's no output, and I can't get find any
useful information in the logs or xl dmesg. The DomU is running a 3.3.2
32 bit linux kernel.

Can you give me any suggestions how I might diagnose what's going on ?

thanks,

Anthony


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 24 15:31:43 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Sep 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 1TGAdA-0006YG-6c; Mon, 24 Sep 2012 15:31:32 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony@overnetdata.com>) id 1TGAd9-0006Y9-LR
	for xen-devel@lists.xen.org; Mon, 24 Sep 2012 15:31:31 +0000
Received: from [85.158.138.51:15632] by server-3.bemta-3.messagelabs.com id
	A0/46-21322-2DC70605; Mon, 24 Sep 2012 15:31:30 +0000
X-Env-Sender: anthony@overnetdata.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1348500689!31281624!1
X-Originating-IP: [81.137.131.225]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19326 invoked from network); 24 Sep 2012 15:31:30 -0000
Received: from host81-137-131-225.in-addr.btopenworld.com (HELO
	zimbra.overnetdata.com) (81.137.131.225)
	by server-4.tower-174.messagelabs.com with SMTP;
	24 Sep 2012 15:31:30 -0000
Received: from localhost (localhost.localdomain [127.0.0.1])
	by zimbra.overnetdata.com (Postfix) with ESMTP id A2DC91617DA
	for <xen-devel@lists.xen.org>; Mon, 24 Sep 2012 16:31:29 +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 5uC+9NoAktvN for <xen-devel@lists.xen.org>;
	Mon, 24 Sep 2012 16:31:29 +0100 (BST)
Received: from [192.168.1.51] (unknown [192.168.1.51])
	by zimbra.overnetdata.com (Postfix) with ESMTPSA id 0811E161793
	for <xen-devel@lists.xen.org>; Mon, 24 Sep 2012 16:31:29 +0100 (BST)
Message-ID: <50607CCF.9050904@overnetdata.com>
Date: Mon, 24 Sep 2012 16:31:27 +0100
From: Anthony Wright <anthony@overnetdata.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:15.0) Gecko/20120907 Thunderbird/15.0.1
MIME-Version: 1.0
To: xen-devel@lists.xen.org
X-Enigmail-Version: 1.4.4
Subject: [Xen-devel] First DomU started goes into a busy loop
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On a  32 bit Xen 4.20 system with a 3.5.4 kernel around 40% of the time
when the system starts up the first DomU to be started goes into a busy
loop (always in state r----- which CPU constantly increasing) with no
console output. If I destroy the DomU and restart it with identical
settings, it starts correctly. I got the same happening with Xen 4.1
with a 3.5.3 kernel, but tried upgrading to see if that fixed it, but it
didn't.

If I connect to the console there's no output, and I can't get find any
useful information in the logs or xl dmesg. The DomU is running a 3.3.2
32 bit linux kernel.

Can you give me any suggestions how I might diagnose what's going on ?

thanks,

Anthony


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 24 15:36:48 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Sep 2012 15:36:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGAi4-0006wn-4O; Mon, 24 Sep 2012 15:36: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 1TGAi2-0006wf-NP
	for xen-devel@lists.xen.org; Mon, 24 Sep 2012 15:36:35 +0000
Received: from [85.158.139.83:14892] by server-6.bemta-5.messagelabs.com id
	45/AC-14717-10E70605; Mon, 24 Sep 2012 15:36:33 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1348500991!32181941!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzA4OTE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7295 invoked from network); 24 Sep 2012 15:36:32 -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;
	24 Sep 2012 15:36:32 -0000
X-IronPort-AV: E=Sophos;i="4.80,476,1344211200"; d="scan'208";a="38959534"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Sep 2012 15:36:30 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1;
	Mon, 24 Sep 2012 11:36:30 -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 1TGAhx-0002sR-Oa;
	Mon, 24 Sep 2012 16:36:29 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Date: Mon, 24 Sep 2012 16:36:29 +0100
Message-ID: <1348500989-18281-1-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
MIME-Version: 1.0
Cc: ian.jackson@citrix.com, Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH] docs: initial documentation for xenstore paths
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is based upon my inspection of a system with a single PV domain
and a single HVM domain running and is therefore very incomplete.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
In v2:

- Fold in HVM patch.
- Address review feedback from Ian Jackson.
  - Moved libxl_memory.txt from tools/libxl to docs/misc. Noone can
    ever find it in its current home and it is easier to refer to
    here (and this patch now does)
  - Mark various paths as INTERNAL or DEPRECATED plus introduce "n"
    (following xs perms notation) to indicate that a path is not guest
    readable.
  - Various clarifications and cross-referencing.
  - Typos
---
 docs/INDEX                        |    1 +
 docs/misc/libxl_memory.txt        |   70 ++++++++
 docs/misc/xenstore-paths.markdown |  353 +++++++++++++++++++++++++++++++++++++
 tools/libxl/libxl_memory.txt      |   70 --------
 4 files changed, 424 insertions(+), 70 deletions(-)
 create mode 100644 docs/misc/libxl_memory.txt
 delete mode 100644 tools/libxl/libxl_memory.txt

diff --git a/docs/INDEX b/docs/INDEX
index 5a0a2c2..f5ccae2 100644
--- a/docs/INDEX
+++ b/docs/INDEX
@@ -12,6 +12,7 @@ misc/kexec_and_kdump		Kexec and Kdump for Xen
 misc/tscmode			TSC Mode HOWTO
 misc/vbd-interface		Xen Guest Disk (VBD) Interface
 misc/xenstore			Xenstore protocol specification
+misc/xenstore-paths		Xenstore path documentation
 misc/xl-disk-configuration	XL Disk Configuration
 misc/xl-network-configuration	XL Network Configuration
 misc/distro_mapping		Distro Directory Layouts
diff --git a/docs/misc/libxl_memory.txt b/docs/misc/libxl_memory.txt
new file mode 100644
index 0000000..253476d
--- /dev/null
+++ b/docs/misc/libxl_memory.txt
@@ -0,0 +1,70 @@
+/* === Domain memory breakdown: HVM guests ==================================
+                           
+             +  +----------+                                     +            
+             |  | shadow   |                                     |            
+             |  +----------+                                     |            
+    overhead |  | extra    |                                     |            
+             |  | external |                                     |            
+             |  +----------+                          +          |            
+             |  | extra    |                          |          |            
+             |  | internal |                          |          |            
+             +  +----------+                +         |          | footprint  
+             |  | video    |                |         |          |            
+             |  +----------+  +    +        |         | xen      |            
+             |  |          |  |    |        | actual  | maximum  |            
+             |  |          |  |    |        | target  |          |            
+             |  | guest    |  |    | build  |         |          |            
+             |  |          |  |    | start  |         |          |            
+      static |  |          |  |    |        |         |          |            
+     maximum |  +----------+  |    +        +         +          +            
+             |  |          |  |                                               
+             |  |          |  |                                               
+             |  | balloon  |  | build                                         
+             |  |          |  | maximum                                       
+             |  |          |  |                                               
+             +  +----------+  +                                               
+                
+                
+    extra internal = LIBXL_MAXMEM_CONSTANT
+    extra external = LIBXL_HVM_EXTRA_MEMORY
+    shadow = libxl_domain_build_info.shadow_memkb
+    static maximum = libxl_domain_build_info.max_memkb
+    video = libxl_domain_build_info.video_memkb
+    build start = libxl_domain_build_info.target_memkb
+    libxl_domain_setmaxmem -> xen maximum
+    libxl_set_memory_target -> actual target
+                
+                
+ === Domain memory breakdown: PV guests ==================================
+                
+                
+             +  +----------+                                     +            
+    overhead |  | extra    |                                     |            
+             |  | external |                                     |            
+             |  +----------+                          +          |            
+             |  | extra    |                          |          |            
+             |  | internal |                          |          |            
+             +  +----------+  +    +        +         |          | footprint  
+             |  |          |  |    |        |         | xen      |            
+             |  |          |  |    |        | actual  | maximum  | 
+             |  | guest    |  |    | build  | target  |          |            
+             |  |          |  |    | start  |         |          |            
+      static |  |          |  |    |        |         |          |            
+     maximum |  +----------+  |    +        +         +          +            
+             |  |          |  |                                               
+             |  |          |  |                                               
+             |  | balloon  |  | build                                         
+             |  |          |  | maximum                                       
+             |  |          |  |                                               
+             +  +----------+  +                                               
+                
+
+    extra internal = LIBXL_MAXMEM_CONSTANT
+    extra external = LIBXL_PV_EXTRA_MEMORY
+    static maximum = libxl_domain_build_info.max_memkb
+    build start = libxl_domain_build_info.target_memkb
+    libxl_domain_setmaxmem -> xen maximum
+    libxl_set_memory_target -> actual target
+
+
+ ========================================================================= */
diff --git a/docs/misc/xenstore-paths.markdown b/docs/misc/xenstore-paths.markdown
index e69de29..09e551b 100644
--- a/docs/misc/xenstore-paths.markdown
+++ b/docs/misc/xenstore-paths.markdown
@@ -0,0 +1,353 @@
+# XenStore Paths
+
+This document attempts to defines all the paths which are in common
+use by either guests, front-/back-end drivers, toolstacks etc.
+
+The XenStore wire protocol itself is described in
+[xenstore.txt](xenstore.txt).
+
+## Notation
+
+This document is intended to be partially machine readable, such that
+test system etc can use it to validate whether the xenstore paths used
+by a test are allowable etc.
+
+Therefore the following notation conventions apply:
+
+A xenstore path is generically defined as:
+
+        PATH = VALUES [TAGS]
+
+        PATH/* [TAGS]
+
+The first syntax defines a simple path with a single value. The second
+syntax defines an aggregated set of paths which are usually described
+externally to this document. The text will give a pointer to the
+appropriate external documentation.
+
+PATH can contain simple regex constructs following the Perl compatible
+regexp syntax described in pcre(3) or perlre(1). In addition the
+following additional wild card names are defined and are evaluated
+before regexp expansion:
+
+* ~ -- expands to an arbitrary a domain's home path (described below).
+  Only valid at the begining of a path.
+* $DEVID -- a per-device type device identifier. Typically an integer.
+* $DOMID -- a domain identifier, an integer. Typically this refers to
+  the "other" domain. i.e. ~ refers to the domain providing a service
+  while $DOMID is the consumer of that service.
+* $UUID -- a UUID in the form xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
+
+VALUES are strings and can take the following forms:
+
+* PATH -- a XenStore path.
+* STRING -- an arbitrary string.
+* INTEGER -- An integer, in decimal representation unless otherwise
+  noted.
+ * MEMKB -- the decimal representation of a number of kilobytes.
+ * EVTCHN -- the decimal representation of an event channel.
+ * GNTREF -- the decimal representation of a grant reference.
+* "a literal string" -- literal strings are contained within quotes.
+* (VALUE | VALUE | ... ) -- a set of alternatives. Alternatives are
+  separated by a "|" and all the alternatives are enclosed in "(" and
+  ")".
+
+Additional TAGS may follow as a comma separated set of the following
+tags enclosed in square brackets.
+
+* w -- Path is writable by the containing domain, that is the domain
+  whose home path ~ this key is under or which /vm/$UUID refers to. By
+  default paths under both of these locations are read only for the
+  domain.
+* n -- Path is neither readable nor writeable for guest domains.
+* HVM -- Path is valid for HVM domains only
+* PV --  Path is valid for PV domains only
+* BACKEND -- Path is valid for a backend domain (AKA driver domain)
+* INTERNAL -- Although a path is visible to the domain its use is
+  reserved for the virtual firmware or Xen platform code. Guest
+  Operating Systems must not read this key or otherwise rely on its
+  presence or contents.
+* DEPRECATED -- This path is deprecated and may be removed in its
+  current form in the future. Guests should not add new dependencies
+  on such paths.
+
+Owning domain means the domain whose home path this tag is found
+under.
+
+Lack of either a __HVM__ or __PV__ tag indicates that the path is
+valid for either type of domain (including PVonHVM and similar mixed
+domain types).
+
+## Domain Home Path
+
+Every domain has a home path within the xenstore hierarchy. This is
+the path where the majority of the domain-visible information about
+each domain is stored.
+
+This path is:
+
+      /local/domain/$DOMID
+
+All non-absolute paths are relative to this path.
+
+Although this path could be considered a "Home Directory" for the
+domain it would not usually be writable by the domain. The tools will
+create writable subdirectories as necessary.
+
+## Per Domain Paths
+
+## General Paths
+
+#### ~/vm = PATH []
+
+A pointer back to the domain's /vm/$UUID path (described below).
+
+#### ~/name = STRING []
+
+The guests name.
+
+#### ~/domid = INTEGER   []
+
+The domain's own ID.
+
+#### ~/image/device-model-pid = INTEGER   [INTERNAL]
+
+The process ID of the device model associated with this domain, if it
+has one.
+
+#### ~/cpu/[0-9]+/availability = ("online"|"offline") [PV]
+
+One node for each virtual CPU up to the guest's configured
+maximum. Valid values are "online" and "offline". The guest is expected to react to changes in this path by bringing the appropriate VCPU on or offline using the VCPUOP interface described in [xen/include/public/vcpu.h][VCPU]
+
+This protocol is not currently well documented.
+
+#### ~/memory/static-max = MEMKB []
+
+Specifies a static maximum amount memory which this domain should
+expect to be given. In the absence of in-guest memory hotplug support
+this set on domain boot and is usually the maximum amount of RAM which
+a guest can make use of. See [docs/misc/libxl_memory.txt][LIBXLMEM]
+for a description of how memory is accounted for in toolstacks using
+the libxl library.
+
+#### ~/memory/target = MEMKB []
+
+The current balloon target for the domain. The balloon driver within
+the guest is expected to make every effort to every effort use no more
+than this amount of RAM.
+
+#### ~/memory/videoram = MEMKB [HVM,INTERNAL]
+
+The size of the video RAM this domain is configured with.
+
+#### ~/device/suspend/event-channel = ""|EVTCHN [w]
+
+The domain's suspend event channel. The use of a suspend event channel
+is optional at the domain's discretion. The toolstack will create this
+path with an empty value which the guest may choose to overwrite.
+
+#### ~/hvmloader/generation-id-address = ADDRESS [r,HVM,INTERNAL]
+
+The hexadecimal representation of the address of the domain's
+"generation id".
+
+#### ~/hvmloader/bios = ("rombios"|"seabios"|"OVMF") [HVM,INTERNAL]
+
+The BIOS used by this domain.
+
+#### ~/platform/* [HVM,INTERNAL]
+
+Various platform properties.
+
+* acpi -- is ACPI enabled for this domain
+* acpi_s3 -- is ACPI S3 support enabled for this domain
+* acpi_s4 -- is ACPI S4 support enabled for this domain
+
+### Frontend device paths
+
+Paravirtual device frontends are generally specified by their own
+directory within the XenStore hierarchy. Usually this is under
+~/device/$TYPE/$DEVID although there are exceptions, e.g. ~/console
+for the first PV console.
+
+#### ~/device/vbd/$DEVID/* []
+
+A virtual block device frontend. Described by
+[xen/include/public/io/blkif.h][BLKIF]
+
+#### ~/device/vfb/$DEVID/* []
+
+A virtual framebuffer frontend. Described by
+[xen/include/public/io/fbif.h][FBIF]
+
+#### ~/device/vkbd/$DEVID/* []
+
+A virtual keyboard device frontend. Described by
+[xen/include/public/io/kbdif.h][KBDIF]
+
+#### ~/device/vif/$DEVID/* []
+
+A virtual network device frontend. Described by
+[xen/include/public/io/netif.h][NETIF]
+
+#### ~/console/* []
+
+The primary PV console device. Described in [console.txt](console.txt)
+
+#### ~/device/console/$DEVID/* []
+
+A secondary PV console device. Described in [console.txt](console.txt)
+
+#### ~/device/serial/$DEVID/* [HVM]
+
+An emulated serial device. Described in [console.txt](console.txt)
+
+#### ~/store/port = EVTCHN [DEPRECATED]
+
+The event channel used by the domain's connection to XenStore.
+
+This path is deprecated since the same information is provided via the
+[start_info][SI] for PV guests and as an [HVM param][HVMPARAMS] for
+HVM guests. There is an obvious chicken and egg problem with
+extracting this value from xenstore in order to setup the xenstore
+communication ring.
+
+#### ~/store/ring-ref = GNTREF [DEPRECATED]
+
+The grant reference of the domain's XenStore ring.
+
+As with ~/store/port this path is deprecated.
+
+### Backend Device Paths
+
+Paravirtual device backends are generally specified by their own
+directory within the XenStore hierarchy. Usually this is under
+~/backend/$TYPE/$DOMID/$DEVID.
+
+#### ~/backend/vbd/$DOMID/$DEVID/* []
+
+A virtual block device backend. Described by
+[xen/include/public/io/blkif.h][BLKIF]
+
+Uses the in-kernel blkback driver.
+
+#### ~/backend/qdisk/$DOMID/$DEVID/* []
+
+A virtual block device backend. Described by
+[xen/include/public/io/blkif.h][BLKIF]
+
+Uses the qemu based disk backend.
+
+#### ~/backend/tap/$DOMID/$DEVID/* []
+
+A virtual block device backend. Described by
+[xen/include/public/io/blkif.h][BLKIF]
+
+Uses the in-kernel blktap (v1) disk backend (deprecated).
+
+#### ~/backend/vfb/$DOMID/$DEVID/* []
+
+A virtual framebuffer backend. Described by
+[xen/include/public/io/fbif.h][FBIF]
+
+#### ~/backend/vkbd/$DOMID/$DEVID/* []
+
+A virtual keyboard device backend. Described by
+[xen/include/public/io/kbdif.h][KBDIF]
+
+#### ~/backend/vif/$DOMID/$DEVID/* []
+
+A virtual network device backend. Described by
+[xen/include/public/io/netif.h][NETIF]
+
+#### ~/backend/console/$DOMID/$DEVID/* []
+
+A PV console backend. Described in [console.txt](console.txt)
+
+#### ~/device-model/$DOMID/* [INTERNAL]
+
+Information relating to device models running in the domain. $DOMID is
+the target domain of the device model.
+
+#### ~/libxl/disable_udev = ("1"|"0") []
+
+Indicates whether device hotplug scripts in this domain should be run
+by udev ("0") or will be run by the toolstack directly ("1").
+
+### Platform Feature and Control Paths
+
+#### ~/control/shutdown = (""|COMMAND) [w]
+
+This is the PV shutdown control node. A toolstack can write various
+commands here to cause various guest shutdown, reboot or suspend
+activities. The guest acknowledges a request by writing the empty
+string back to the command node.
+
+The precise protocol is not yet documented.
+
+#### ~/control/platform-feature-multiprocessor-suspend = (0|1) []
+
+Indicates to the guest that this platform supports the multiprocessor
+suspend feature.
+
+#### ~/control/platform-feature-xs\_reset\_watches = (0|1) []
+
+Indicates to the guest that this platform supports the
+XS_RESET_WATCHES xenstore message. See
+[xen/include/public/io/xs\_wire.h][XSWIRE] for the XenStore wire
+protocol definition.
+
+### Domain Controlled Paths
+
+#### ~/data/* [w]
+
+A domain writable path. Available for arbitrary domain use.
+
+## Virtual Machine Paths
+
+The /vm/$UUID namespace is used by toolstacks to store various
+information relating to the domain which is not intended to be guest
+visible (hence they are all tagged [n,INTERNAL]).
+
+Several of the keys here are not well defined and/or not well located
+and are liable to be replaced with more fully defined paths in the
+future.
+
+### /vm/$UUID/uuid = UUID [n,INTERNAL]
+
+Value is the same UUID as the path.
+
+### /vm/$UUID/name = STRING [n,INTERNAL]
+
+The domain's name.
+
+### /vm/$UUID/image/* [n,INTERNAL]
+
+Various information relating to the domain builder used for this guest.
+
+### /vm/$UUID/start_time = INTEGER "." INTEGER [n,INTERNAL]
+
+The time which the guest was started in SECONDS.MICROSECONDS format
+
+### /vm/$UUID/rtc/timeoffset = ""|INTEGER [n,HVM,INTERNAL]
+
+The guest's virtual time offset from UTC in seconds.
+
+## Platform-Level paths
+
+### libxl Specific Paths
+
+#### /libxl/$DOMID/dm-version ("qemu\_xen"|"qemu\_xen\_traditional") = [n,INTERNAL]
+
+The device model version for a domain.
+
+[BLKIF]: http://xenbits.xen.org/docs/unstable/hypercall/include,public,io,blkif.h.html
+[FBIF]: http://xenbits.xen.org/docs/unstable/hypercall/include,public,io,fbif.h.html
+[HVMPARAMS]: http://xenbits.xen.org/docs/unstable/hypercall/include,public,hvm,params.h.html
+[KBDIF]: http://xenbits.xen.org/docs/unstable/hypercall/include,public,io,kbdif.h.html
+[LIBXLMEM]: http://xenbits.xen.org/docs/unstable/misc/libxl_memory.txt
+[NETIF]: http://xenbits.xen.org/docs/unstable/hypercall/include,public,io,netif.h.html
+[SI]: http://xenbits.xen.org/docs/unstable/hypercall/include,public,xen.h.html#Struct_start_info
+[VCPU]: http://xenbits.xen.org/docs/unstable/hypercall/include,public,vcpu.h.html
+[XSWIRE]: http://xenbits.xen.org/docs/unstable/hypercall/include,public,io,xs_wire.h.html
diff --git a/tools/libxl/libxl_memory.txt b/tools/libxl/libxl_memory.txt
deleted file mode 100644
index 253476d..0000000
--- a/tools/libxl/libxl_memory.txt
+++ /dev/null
@@ -1,70 +0,0 @@
-/* === Domain memory breakdown: HVM guests ==================================
-                           
-             +  +----------+                                     +            
-             |  | shadow   |                                     |            
-             |  +----------+                                     |            
-    overhead |  | extra    |                                     |            
-             |  | external |                                     |            
-             |  +----------+                          +          |            
-             |  | extra    |                          |          |            
-             |  | internal |                          |          |            
-             +  +----------+                +         |          | footprint  
-             |  | video    |                |         |          |            
-             |  +----------+  +    +        |         | xen      |            
-             |  |          |  |    |        | actual  | maximum  |            
-             |  |          |  |    |        | target  |          |            
-             |  | guest    |  |    | build  |         |          |            
-             |  |          |  |    | start  |         |          |            
-      static |  |          |  |    |        |         |          |            
-     maximum |  +----------+  |    +        +         +          +            
-             |  |          |  |                                               
-             |  |          |  |                                               
-             |  | balloon  |  | build                                         
-             |  |          |  | maximum                                       
-             |  |          |  |                                               
-             +  +----------+  +                                               
-                
-                
-    extra internal = LIBXL_MAXMEM_CONSTANT
-    extra external = LIBXL_HVM_EXTRA_MEMORY
-    shadow = libxl_domain_build_info.shadow_memkb
-    static maximum = libxl_domain_build_info.max_memkb
-    video = libxl_domain_build_info.video_memkb
-    build start = libxl_domain_build_info.target_memkb
-    libxl_domain_setmaxmem -> xen maximum
-    libxl_set_memory_target -> actual target
-                
-                
- === Domain memory breakdown: PV guests ==================================
-                
-                
-             +  +----------+                                     +            
-    overhead |  | extra    |                                     |            
-             |  | external |                                     |            
-             |  +----------+                          +          |            
-             |  | extra    |                          |          |            
-             |  | internal |                          |          |            
-             +  +----------+  +    +        +         |          | footprint  
-             |  |          |  |    |        |         | xen      |            
-             |  |          |  |    |        | actual  | maximum  | 
-             |  | guest    |  |    | build  | target  |          |            
-             |  |          |  |    | start  |         |          |            
-      static |  |          |  |    |        |         |          |            
-     maximum |  +----------+  |    +        +         +          +            
-             |  |          |  |                                               
-             |  |          |  |                                               
-             |  | balloon  |  | build                                         
-             |  |          |  | maximum                                       
-             |  |          |  |                                               
-             +  +----------+  +                                               
-                
-
-    extra internal = LIBXL_MAXMEM_CONSTANT
-    extra external = LIBXL_PV_EXTRA_MEMORY
-    static maximum = libxl_domain_build_info.max_memkb
-    build start = libxl_domain_build_info.target_memkb
-    libxl_domain_setmaxmem -> xen maximum
-    libxl_set_memory_target -> actual target
-
-
- ========================================================================= */
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 24 15:36:48 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Sep 2012 15:36:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGAi4-0006wn-4O; Mon, 24 Sep 2012 15:36: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 1TGAi2-0006wf-NP
	for xen-devel@lists.xen.org; Mon, 24 Sep 2012 15:36:35 +0000
Received: from [85.158.139.83:14892] by server-6.bemta-5.messagelabs.com id
	45/AC-14717-10E70605; Mon, 24 Sep 2012 15:36:33 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1348500991!32181941!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzA4OTE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7295 invoked from network); 24 Sep 2012 15:36:32 -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;
	24 Sep 2012 15:36:32 -0000
X-IronPort-AV: E=Sophos;i="4.80,476,1344211200"; d="scan'208";a="38959534"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Sep 2012 15:36:30 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1;
	Mon, 24 Sep 2012 11:36:30 -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 1TGAhx-0002sR-Oa;
	Mon, 24 Sep 2012 16:36:29 +0100
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xen.org
Date: Mon, 24 Sep 2012 16:36:29 +0100
Message-ID: <1348500989-18281-1-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
MIME-Version: 1.0
Cc: ian.jackson@citrix.com, Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH] docs: initial documentation for xenstore paths
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is based upon my inspection of a system with a single PV domain
and a single HVM domain running and is therefore very incomplete.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
In v2:

- Fold in HVM patch.
- Address review feedback from Ian Jackson.
  - Moved libxl_memory.txt from tools/libxl to docs/misc. Noone can
    ever find it in its current home and it is easier to refer to
    here (and this patch now does)
  - Mark various paths as INTERNAL or DEPRECATED plus introduce "n"
    (following xs perms notation) to indicate that a path is not guest
    readable.
  - Various clarifications and cross-referencing.
  - Typos
---
 docs/INDEX                        |    1 +
 docs/misc/libxl_memory.txt        |   70 ++++++++
 docs/misc/xenstore-paths.markdown |  353 +++++++++++++++++++++++++++++++++++++
 tools/libxl/libxl_memory.txt      |   70 --------
 4 files changed, 424 insertions(+), 70 deletions(-)
 create mode 100644 docs/misc/libxl_memory.txt
 delete mode 100644 tools/libxl/libxl_memory.txt

diff --git a/docs/INDEX b/docs/INDEX
index 5a0a2c2..f5ccae2 100644
--- a/docs/INDEX
+++ b/docs/INDEX
@@ -12,6 +12,7 @@ misc/kexec_and_kdump		Kexec and Kdump for Xen
 misc/tscmode			TSC Mode HOWTO
 misc/vbd-interface		Xen Guest Disk (VBD) Interface
 misc/xenstore			Xenstore protocol specification
+misc/xenstore-paths		Xenstore path documentation
 misc/xl-disk-configuration	XL Disk Configuration
 misc/xl-network-configuration	XL Network Configuration
 misc/distro_mapping		Distro Directory Layouts
diff --git a/docs/misc/libxl_memory.txt b/docs/misc/libxl_memory.txt
new file mode 100644
index 0000000..253476d
--- /dev/null
+++ b/docs/misc/libxl_memory.txt
@@ -0,0 +1,70 @@
+/* === Domain memory breakdown: HVM guests ==================================
+                           
+             +  +----------+                                     +            
+             |  | shadow   |                                     |            
+             |  +----------+                                     |            
+    overhead |  | extra    |                                     |            
+             |  | external |                                     |            
+             |  +----------+                          +          |            
+             |  | extra    |                          |          |            
+             |  | internal |                          |          |            
+             +  +----------+                +         |          | footprint  
+             |  | video    |                |         |          |            
+             |  +----------+  +    +        |         | xen      |            
+             |  |          |  |    |        | actual  | maximum  |            
+             |  |          |  |    |        | target  |          |            
+             |  | guest    |  |    | build  |         |          |            
+             |  |          |  |    | start  |         |          |            
+      static |  |          |  |    |        |         |          |            
+     maximum |  +----------+  |    +        +         +          +            
+             |  |          |  |                                               
+             |  |          |  |                                               
+             |  | balloon  |  | build                                         
+             |  |          |  | maximum                                       
+             |  |          |  |                                               
+             +  +----------+  +                                               
+                
+                
+    extra internal = LIBXL_MAXMEM_CONSTANT
+    extra external = LIBXL_HVM_EXTRA_MEMORY
+    shadow = libxl_domain_build_info.shadow_memkb
+    static maximum = libxl_domain_build_info.max_memkb
+    video = libxl_domain_build_info.video_memkb
+    build start = libxl_domain_build_info.target_memkb
+    libxl_domain_setmaxmem -> xen maximum
+    libxl_set_memory_target -> actual target
+                
+                
+ === Domain memory breakdown: PV guests ==================================
+                
+                
+             +  +----------+                                     +            
+    overhead |  | extra    |                                     |            
+             |  | external |                                     |            
+             |  +----------+                          +          |            
+             |  | extra    |                          |          |            
+             |  | internal |                          |          |            
+             +  +----------+  +    +        +         |          | footprint  
+             |  |          |  |    |        |         | xen      |            
+             |  |          |  |    |        | actual  | maximum  | 
+             |  | guest    |  |    | build  | target  |          |            
+             |  |          |  |    | start  |         |          |            
+      static |  |          |  |    |        |         |          |            
+     maximum |  +----------+  |    +        +         +          +            
+             |  |          |  |                                               
+             |  |          |  |                                               
+             |  | balloon  |  | build                                         
+             |  |          |  | maximum                                       
+             |  |          |  |                                               
+             +  +----------+  +                                               
+                
+
+    extra internal = LIBXL_MAXMEM_CONSTANT
+    extra external = LIBXL_PV_EXTRA_MEMORY
+    static maximum = libxl_domain_build_info.max_memkb
+    build start = libxl_domain_build_info.target_memkb
+    libxl_domain_setmaxmem -> xen maximum
+    libxl_set_memory_target -> actual target
+
+
+ ========================================================================= */
diff --git a/docs/misc/xenstore-paths.markdown b/docs/misc/xenstore-paths.markdown
index e69de29..09e551b 100644
--- a/docs/misc/xenstore-paths.markdown
+++ b/docs/misc/xenstore-paths.markdown
@@ -0,0 +1,353 @@
+# XenStore Paths
+
+This document attempts to defines all the paths which are in common
+use by either guests, front-/back-end drivers, toolstacks etc.
+
+The XenStore wire protocol itself is described in
+[xenstore.txt](xenstore.txt).
+
+## Notation
+
+This document is intended to be partially machine readable, such that
+test system etc can use it to validate whether the xenstore paths used
+by a test are allowable etc.
+
+Therefore the following notation conventions apply:
+
+A xenstore path is generically defined as:
+
+        PATH = VALUES [TAGS]
+
+        PATH/* [TAGS]
+
+The first syntax defines a simple path with a single value. The second
+syntax defines an aggregated set of paths which are usually described
+externally to this document. The text will give a pointer to the
+appropriate external documentation.
+
+PATH can contain simple regex constructs following the Perl compatible
+regexp syntax described in pcre(3) or perlre(1). In addition the
+following additional wild card names are defined and are evaluated
+before regexp expansion:
+
+* ~ -- expands to an arbitrary a domain's home path (described below).
+  Only valid at the begining of a path.
+* $DEVID -- a per-device type device identifier. Typically an integer.
+* $DOMID -- a domain identifier, an integer. Typically this refers to
+  the "other" domain. i.e. ~ refers to the domain providing a service
+  while $DOMID is the consumer of that service.
+* $UUID -- a UUID in the form xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
+
+VALUES are strings and can take the following forms:
+
+* PATH -- a XenStore path.
+* STRING -- an arbitrary string.
+* INTEGER -- An integer, in decimal representation unless otherwise
+  noted.
+ * MEMKB -- the decimal representation of a number of kilobytes.
+ * EVTCHN -- the decimal representation of an event channel.
+ * GNTREF -- the decimal representation of a grant reference.
+* "a literal string" -- literal strings are contained within quotes.
+* (VALUE | VALUE | ... ) -- a set of alternatives. Alternatives are
+  separated by a "|" and all the alternatives are enclosed in "(" and
+  ")".
+
+Additional TAGS may follow as a comma separated set of the following
+tags enclosed in square brackets.
+
+* w -- Path is writable by the containing domain, that is the domain
+  whose home path ~ this key is under or which /vm/$UUID refers to. By
+  default paths under both of these locations are read only for the
+  domain.
+* n -- Path is neither readable nor writeable for guest domains.
+* HVM -- Path is valid for HVM domains only
+* PV --  Path is valid for PV domains only
+* BACKEND -- Path is valid for a backend domain (AKA driver domain)
+* INTERNAL -- Although a path is visible to the domain its use is
+  reserved for the virtual firmware or Xen platform code. Guest
+  Operating Systems must not read this key or otherwise rely on its
+  presence or contents.
+* DEPRECATED -- This path is deprecated and may be removed in its
+  current form in the future. Guests should not add new dependencies
+  on such paths.
+
+Owning domain means the domain whose home path this tag is found
+under.
+
+Lack of either a __HVM__ or __PV__ tag indicates that the path is
+valid for either type of domain (including PVonHVM and similar mixed
+domain types).
+
+## Domain Home Path
+
+Every domain has a home path within the xenstore hierarchy. This is
+the path where the majority of the domain-visible information about
+each domain is stored.
+
+This path is:
+
+      /local/domain/$DOMID
+
+All non-absolute paths are relative to this path.
+
+Although this path could be considered a "Home Directory" for the
+domain it would not usually be writable by the domain. The tools will
+create writable subdirectories as necessary.
+
+## Per Domain Paths
+
+## General Paths
+
+#### ~/vm = PATH []
+
+A pointer back to the domain's /vm/$UUID path (described below).
+
+#### ~/name = STRING []
+
+The guests name.
+
+#### ~/domid = INTEGER   []
+
+The domain's own ID.
+
+#### ~/image/device-model-pid = INTEGER   [INTERNAL]
+
+The process ID of the device model associated with this domain, if it
+has one.
+
+#### ~/cpu/[0-9]+/availability = ("online"|"offline") [PV]
+
+One node for each virtual CPU up to the guest's configured
+maximum. Valid values are "online" and "offline". The guest is expected to react to changes in this path by bringing the appropriate VCPU on or offline using the VCPUOP interface described in [xen/include/public/vcpu.h][VCPU]
+
+This protocol is not currently well documented.
+
+#### ~/memory/static-max = MEMKB []
+
+Specifies a static maximum amount memory which this domain should
+expect to be given. In the absence of in-guest memory hotplug support
+this set on domain boot and is usually the maximum amount of RAM which
+a guest can make use of. See [docs/misc/libxl_memory.txt][LIBXLMEM]
+for a description of how memory is accounted for in toolstacks using
+the libxl library.
+
+#### ~/memory/target = MEMKB []
+
+The current balloon target for the domain. The balloon driver within
+the guest is expected to make every effort to every effort use no more
+than this amount of RAM.
+
+#### ~/memory/videoram = MEMKB [HVM,INTERNAL]
+
+The size of the video RAM this domain is configured with.
+
+#### ~/device/suspend/event-channel = ""|EVTCHN [w]
+
+The domain's suspend event channel. The use of a suspend event channel
+is optional at the domain's discretion. The toolstack will create this
+path with an empty value which the guest may choose to overwrite.
+
+#### ~/hvmloader/generation-id-address = ADDRESS [r,HVM,INTERNAL]
+
+The hexadecimal representation of the address of the domain's
+"generation id".
+
+#### ~/hvmloader/bios = ("rombios"|"seabios"|"OVMF") [HVM,INTERNAL]
+
+The BIOS used by this domain.
+
+#### ~/platform/* [HVM,INTERNAL]
+
+Various platform properties.
+
+* acpi -- is ACPI enabled for this domain
+* acpi_s3 -- is ACPI S3 support enabled for this domain
+* acpi_s4 -- is ACPI S4 support enabled for this domain
+
+### Frontend device paths
+
+Paravirtual device frontends are generally specified by their own
+directory within the XenStore hierarchy. Usually this is under
+~/device/$TYPE/$DEVID although there are exceptions, e.g. ~/console
+for the first PV console.
+
+#### ~/device/vbd/$DEVID/* []
+
+A virtual block device frontend. Described by
+[xen/include/public/io/blkif.h][BLKIF]
+
+#### ~/device/vfb/$DEVID/* []
+
+A virtual framebuffer frontend. Described by
+[xen/include/public/io/fbif.h][FBIF]
+
+#### ~/device/vkbd/$DEVID/* []
+
+A virtual keyboard device frontend. Described by
+[xen/include/public/io/kbdif.h][KBDIF]
+
+#### ~/device/vif/$DEVID/* []
+
+A virtual network device frontend. Described by
+[xen/include/public/io/netif.h][NETIF]
+
+#### ~/console/* []
+
+The primary PV console device. Described in [console.txt](console.txt)
+
+#### ~/device/console/$DEVID/* []
+
+A secondary PV console device. Described in [console.txt](console.txt)
+
+#### ~/device/serial/$DEVID/* [HVM]
+
+An emulated serial device. Described in [console.txt](console.txt)
+
+#### ~/store/port = EVTCHN [DEPRECATED]
+
+The event channel used by the domain's connection to XenStore.
+
+This path is deprecated since the same information is provided via the
+[start_info][SI] for PV guests and as an [HVM param][HVMPARAMS] for
+HVM guests. There is an obvious chicken and egg problem with
+extracting this value from xenstore in order to setup the xenstore
+communication ring.
+
+#### ~/store/ring-ref = GNTREF [DEPRECATED]
+
+The grant reference of the domain's XenStore ring.
+
+As with ~/store/port this path is deprecated.
+
+### Backend Device Paths
+
+Paravirtual device backends are generally specified by their own
+directory within the XenStore hierarchy. Usually this is under
+~/backend/$TYPE/$DOMID/$DEVID.
+
+#### ~/backend/vbd/$DOMID/$DEVID/* []
+
+A virtual block device backend. Described by
+[xen/include/public/io/blkif.h][BLKIF]
+
+Uses the in-kernel blkback driver.
+
+#### ~/backend/qdisk/$DOMID/$DEVID/* []
+
+A virtual block device backend. Described by
+[xen/include/public/io/blkif.h][BLKIF]
+
+Uses the qemu based disk backend.
+
+#### ~/backend/tap/$DOMID/$DEVID/* []
+
+A virtual block device backend. Described by
+[xen/include/public/io/blkif.h][BLKIF]
+
+Uses the in-kernel blktap (v1) disk backend (deprecated).
+
+#### ~/backend/vfb/$DOMID/$DEVID/* []
+
+A virtual framebuffer backend. Described by
+[xen/include/public/io/fbif.h][FBIF]
+
+#### ~/backend/vkbd/$DOMID/$DEVID/* []
+
+A virtual keyboard device backend. Described by
+[xen/include/public/io/kbdif.h][KBDIF]
+
+#### ~/backend/vif/$DOMID/$DEVID/* []
+
+A virtual network device backend. Described by
+[xen/include/public/io/netif.h][NETIF]
+
+#### ~/backend/console/$DOMID/$DEVID/* []
+
+A PV console backend. Described in [console.txt](console.txt)
+
+#### ~/device-model/$DOMID/* [INTERNAL]
+
+Information relating to device models running in the domain. $DOMID is
+the target domain of the device model.
+
+#### ~/libxl/disable_udev = ("1"|"0") []
+
+Indicates whether device hotplug scripts in this domain should be run
+by udev ("0") or will be run by the toolstack directly ("1").
+
+### Platform Feature and Control Paths
+
+#### ~/control/shutdown = (""|COMMAND) [w]
+
+This is the PV shutdown control node. A toolstack can write various
+commands here to cause various guest shutdown, reboot or suspend
+activities. The guest acknowledges a request by writing the empty
+string back to the command node.
+
+The precise protocol is not yet documented.
+
+#### ~/control/platform-feature-multiprocessor-suspend = (0|1) []
+
+Indicates to the guest that this platform supports the multiprocessor
+suspend feature.
+
+#### ~/control/platform-feature-xs\_reset\_watches = (0|1) []
+
+Indicates to the guest that this platform supports the
+XS_RESET_WATCHES xenstore message. See
+[xen/include/public/io/xs\_wire.h][XSWIRE] for the XenStore wire
+protocol definition.
+
+### Domain Controlled Paths
+
+#### ~/data/* [w]
+
+A domain writable path. Available for arbitrary domain use.
+
+## Virtual Machine Paths
+
+The /vm/$UUID namespace is used by toolstacks to store various
+information relating to the domain which is not intended to be guest
+visible (hence they are all tagged [n,INTERNAL]).
+
+Several of the keys here are not well defined and/or not well located
+and are liable to be replaced with more fully defined paths in the
+future.
+
+### /vm/$UUID/uuid = UUID [n,INTERNAL]
+
+Value is the same UUID as the path.
+
+### /vm/$UUID/name = STRING [n,INTERNAL]
+
+The domain's name.
+
+### /vm/$UUID/image/* [n,INTERNAL]
+
+Various information relating to the domain builder used for this guest.
+
+### /vm/$UUID/start_time = INTEGER "." INTEGER [n,INTERNAL]
+
+The time which the guest was started in SECONDS.MICROSECONDS format
+
+### /vm/$UUID/rtc/timeoffset = ""|INTEGER [n,HVM,INTERNAL]
+
+The guest's virtual time offset from UTC in seconds.
+
+## Platform-Level paths
+
+### libxl Specific Paths
+
+#### /libxl/$DOMID/dm-version ("qemu\_xen"|"qemu\_xen\_traditional") = [n,INTERNAL]
+
+The device model version for a domain.
+
+[BLKIF]: http://xenbits.xen.org/docs/unstable/hypercall/include,public,io,blkif.h.html
+[FBIF]: http://xenbits.xen.org/docs/unstable/hypercall/include,public,io,fbif.h.html
+[HVMPARAMS]: http://xenbits.xen.org/docs/unstable/hypercall/include,public,hvm,params.h.html
+[KBDIF]: http://xenbits.xen.org/docs/unstable/hypercall/include,public,io,kbdif.h.html
+[LIBXLMEM]: http://xenbits.xen.org/docs/unstable/misc/libxl_memory.txt
+[NETIF]: http://xenbits.xen.org/docs/unstable/hypercall/include,public,io,netif.h.html
+[SI]: http://xenbits.xen.org/docs/unstable/hypercall/include,public,xen.h.html#Struct_start_info
+[VCPU]: http://xenbits.xen.org/docs/unstable/hypercall/include,public,vcpu.h.html
+[XSWIRE]: http://xenbits.xen.org/docs/unstable/hypercall/include,public,io,xs_wire.h.html
diff --git a/tools/libxl/libxl_memory.txt b/tools/libxl/libxl_memory.txt
deleted file mode 100644
index 253476d..0000000
--- a/tools/libxl/libxl_memory.txt
+++ /dev/null
@@ -1,70 +0,0 @@
-/* === Domain memory breakdown: HVM guests ==================================
-                           
-             +  +----------+                                     +            
-             |  | shadow   |                                     |            
-             |  +----------+                                     |            
-    overhead |  | extra    |                                     |            
-             |  | external |                                     |            
-             |  +----------+                          +          |            
-             |  | extra    |                          |          |            
-             |  | internal |                          |          |            
-             +  +----------+                +         |          | footprint  
-             |  | video    |                |         |          |            
-             |  +----------+  +    +        |         | xen      |            
-             |  |          |  |    |        | actual  | maximum  |            
-             |  |          |  |    |        | target  |          |            
-             |  | guest    |  |    | build  |         |          |            
-             |  |          |  |    | start  |         |          |            
-      static |  |          |  |    |        |         |          |            
-     maximum |  +----------+  |    +        +         +          +            
-             |  |          |  |                                               
-             |  |          |  |                                               
-             |  | balloon  |  | build                                         
-             |  |          |  | maximum                                       
-             |  |          |  |                                               
-             +  +----------+  +                                               
-                
-                
-    extra internal = LIBXL_MAXMEM_CONSTANT
-    extra external = LIBXL_HVM_EXTRA_MEMORY
-    shadow = libxl_domain_build_info.shadow_memkb
-    static maximum = libxl_domain_build_info.max_memkb
-    video = libxl_domain_build_info.video_memkb
-    build start = libxl_domain_build_info.target_memkb
-    libxl_domain_setmaxmem -> xen maximum
-    libxl_set_memory_target -> actual target
-                
-                
- === Domain memory breakdown: PV guests ==================================
-                
-                
-             +  +----------+                                     +            
-    overhead |  | extra    |                                     |            
-             |  | external |                                     |            
-             |  +----------+                          +          |            
-             |  | extra    |                          |          |            
-             |  | internal |                          |          |            
-             +  +----------+  +    +        +         |          | footprint  
-             |  |          |  |    |        |         | xen      |            
-             |  |          |  |    |        | actual  | maximum  | 
-             |  | guest    |  |    | build  | target  |          |            
-             |  |          |  |    | start  |         |          |            
-      static |  |          |  |    |        |         |          |            
-     maximum |  +----------+  |    +        +         +          +            
-             |  |          |  |                                               
-             |  |          |  |                                               
-             |  | balloon  |  | build                                         
-             |  |          |  | maximum                                       
-             |  |          |  |                                               
-             +  +----------+  +                                               
-                
-
-    extra internal = LIBXL_MAXMEM_CONSTANT
-    extra external = LIBXL_PV_EXTRA_MEMORY
-    static maximum = libxl_domain_build_info.max_memkb
-    build start = libxl_domain_build_info.target_memkb
-    libxl_domain_setmaxmem -> xen maximum
-    libxl_set_memory_target -> actual target
-
-
- ========================================================================= */
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 24 15:41:28 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Sep 2012 15:41:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGAmX-00076n-VZ; Mon, 24 Sep 2012 15:41:13 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1TGAmW-00076i-Fe
	for Xen-devel@lists.xensource.com; Mon, 24 Sep 2012 15:41:12 +0000
Received: from [85.158.139.211:40175] by server-10.bemta-5.messagelabs.com id
	44/D2-16911-71F70605; Mon, 24 Sep 2012 15:41:11 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-6.tower-206.messagelabs.com!1348501269!19772279!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzU5Njc1\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27105 invoked from network); 24 Sep 2012 15:41:11 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-6.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 24 Sep 2012 15:41:11 -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 q8OFf4As002156
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 24 Sep 2012 15:41:05 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
	q8OFf316005747
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 24 Sep 2012 15:41:04 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
	q8OFf3xN023519; Mon, 24 Sep 2012 10:41:03 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 24 Sep 2012 08:41:03 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 8721B4031C; Mon, 24 Sep 2012 11:29:51 -0400 (EDT)
Date: Mon, 24 Sep 2012 11:29:51 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20120924152951.GA1458@phenom.dumpdata.com>
References: <20120921121202.3163c379@mantra.us.oracle.com>
	<alpine.DEB.2.02.1209241613160.29232@kaball.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <alpine.DEB.2.02.1209241613160.29232@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] [PATCH v1 0/8]: PVH (PV guest with extensions)u
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Sep 24, 2012 at 04:16:29PM +0100, Stefano Stabellini wrote:
> On Fri, 21 Sep 2012, Mukesh Rathor wrote:
> > Hi guys,
> > 
> > Ok, I've made all the changes from prev RFC patch submission. Tested
> > all the combinations. The patches are a bit smaller from before, and
> > couldn't be separated like before, so I can't state whats different in
> > each patch. But, it's not too bad to review now.
> > 
> > As before, they were built on top of
> > fc6bdb59a501740b28ed3b616641a22c8dc5dd31 from the following tree:
> >         
> > git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git

I took them for a spin over the weekend and stuck them on top of my
#linux-next - 

git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git linux-next-pvh

which worked well as PV guest (dom0, domU, etc). It didn't do too well
as PVHVM guest, but that might be just that some of the 'if (xen..)'
are properly not set or I mismerged badly. The later is probably likely as
I did screw it up at least twice (as you can see from my log).

Hm, let me give them also a whirl on top of fc6bdb59a501740b28ed3b616641a22c8dc5dd31

> 
> The patch series is not in a bad state. It is reasonable to aim for a
> merge in 3.8.
> At least the xen_remap_domain_mfn_range, ballooning and privcmd changes,
> which interfaces are going to be shared with Xen on ARM ;-)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 24 15:41:28 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Sep 2012 15:41:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGAmX-00076n-VZ; Mon, 24 Sep 2012 15:41:13 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1TGAmW-00076i-Fe
	for Xen-devel@lists.xensource.com; Mon, 24 Sep 2012 15:41:12 +0000
Received: from [85.158.139.211:40175] by server-10.bemta-5.messagelabs.com id
	44/D2-16911-71F70605; Mon, 24 Sep 2012 15:41:11 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-6.tower-206.messagelabs.com!1348501269!19772279!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzU5Njc1\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27105 invoked from network); 24 Sep 2012 15:41:11 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-6.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 24 Sep 2012 15:41:11 -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 q8OFf4As002156
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 24 Sep 2012 15:41:05 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
	q8OFf316005747
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 24 Sep 2012 15:41:04 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
	q8OFf3xN023519; Mon, 24 Sep 2012 10:41:03 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 24 Sep 2012 08:41:03 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 8721B4031C; Mon, 24 Sep 2012 11:29:51 -0400 (EDT)
Date: Mon, 24 Sep 2012 11:29:51 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20120924152951.GA1458@phenom.dumpdata.com>
References: <20120921121202.3163c379@mantra.us.oracle.com>
	<alpine.DEB.2.02.1209241613160.29232@kaball.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <alpine.DEB.2.02.1209241613160.29232@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] [PATCH v1 0/8]: PVH (PV guest with extensions)u
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Sep 24, 2012 at 04:16:29PM +0100, Stefano Stabellini wrote:
> On Fri, 21 Sep 2012, Mukesh Rathor wrote:
> > Hi guys,
> > 
> > Ok, I've made all the changes from prev RFC patch submission. Tested
> > all the combinations. The patches are a bit smaller from before, and
> > couldn't be separated like before, so I can't state whats different in
> > each patch. But, it's not too bad to review now.
> > 
> > As before, they were built on top of
> > fc6bdb59a501740b28ed3b616641a22c8dc5dd31 from the following tree:
> >         
> > git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git

I took them for a spin over the weekend and stuck them on top of my
#linux-next - 

git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git linux-next-pvh

which worked well as PV guest (dom0, domU, etc). It didn't do too well
as PVHVM guest, but that might be just that some of the 'if (xen..)'
are properly not set or I mismerged badly. The later is probably likely as
I did screw it up at least twice (as you can see from my log).

Hm, let me give them also a whirl on top of fc6bdb59a501740b28ed3b616641a22c8dc5dd31

> 
> The patch series is not in a bad state. It is reasonable to aim for a
> merge in 3.8.
> At least the xen_remap_domain_mfn_range, ballooning and privcmd changes,
> which interfaces are going to be shared with Xen on ARM ;-)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 24 15:52:07 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Sep 2012 15:52:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGAwp-0007Kk-BX; Mon, 24 Sep 2012 15:51: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 1TGAwo-0007Kf-4Y
	for xen-devel@lists.xen.org; Mon, 24 Sep 2012 15:51:50 +0000
Received: from [85.158.143.99:46499] by server-3.bemta-4.messagelabs.com id
	39/5F-10986-59180605; Mon, 24 Sep 2012 15:51:49 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1348501908!25154784!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25421 invoked from network); 24 Sep 2012 15:51:49 -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;
	24 Sep 2012 15:51:49 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 24 Sep 2012 16:51:50 +0100
Message-Id: <50609DB1020000780009D690@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 24 Sep 2012 16:51:45 +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 0/3] linux-2.6.18/pciback: misc adjustments
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

1: support wild cards in slot specifications
2: properly clean up after calling pcistub_device_find()
3: improve input validation

Signed-off-by: Jan Beulich <jbeulich@suse.com>


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 24 15:52:07 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Sep 2012 15:52:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGAwp-0007Kk-BX; Mon, 24 Sep 2012 15:51: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 1TGAwo-0007Kf-4Y
	for xen-devel@lists.xen.org; Mon, 24 Sep 2012 15:51:50 +0000
Received: from [85.158.143.99:46499] by server-3.bemta-4.messagelabs.com id
	39/5F-10986-59180605; Mon, 24 Sep 2012 15:51:49 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1348501908!25154784!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25421 invoked from network); 24 Sep 2012 15:51:49 -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;
	24 Sep 2012 15:51:49 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 24 Sep 2012 16:51:50 +0100
Message-Id: <50609DB1020000780009D690@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 24 Sep 2012 16:51:45 +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 0/3] linux-2.6.18/pciback: misc adjustments
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

1: support wild cards in slot specifications
2: properly clean up after calling pcistub_device_find()
3: improve input validation

Signed-off-by: Jan Beulich <jbeulich@suse.com>


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 24 15:54:25 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Sep 2012 15: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 1TGAz7-0007Qn-Sy; Mon, 24 Sep 2012 15:54: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 1TGAz6-0007Qi-2F
	for xen-devel@lists.xen.org; Mon, 24 Sep 2012 15:54:12 +0000
Received: from [85.158.143.99:54536] by server-3.bemta-4.messagelabs.com id
	2A/72-10986-32280605; Mon, 24 Sep 2012 15:54:11 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1348502050!30663172!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30040 invoked from network); 24 Sep 2012 15:54:10 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-13.tower-216.messagelabs.com with SMTP;
	24 Sep 2012 15:54:10 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 24 Sep 2012 16:54:12 +0100
Message-Id: <50609E3E020000780009D699@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 24 Sep 2012 16:54:06 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__PartD4E5E90E.0__="
Subject: [Xen-devel] [PATCH 1/3] linux-2.6.18/pciback: support wild cards in
 slot specifications
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<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.

--=__PartD4E5E90E.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Particularly for hiding sets of SR-IOV devices, specifying them all
individually is rather cumbersome. Therefore, allow function and slot
numbers to be replaced by a wildcard character ('*').

Unfortunately this gets complicated by the in-kernel sscanf()
implementation not being really standard conformant - matching of
plain text tails cannot be checked by the caller (a patch to overcome
this will be sent shortly, and a follow-up patch for simplifying the
code is planned to be sent when that fixed went upstream).

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/drivers/xen/pciback/pci_stub.c
+++ b/drivers/xen/pciback/pci_stub.c
@@ -861,17 +861,41 @@ static inline int str_to_slot(const char
 			      int *slot, int *func)
 {
 	int err;
+	char wc =3D '*';
=20
 	err =3D sscanf(buf, " %x:%x:%x.%x", domain, bus, slot, func);
-	if (err =3D=3D 4)
+	switch (err) {
+	case 3:
+		*func =3D -1;
+		err =3D sscanf(buf, " %x:%x:%x.%c", domain, bus, slot, =
&wc);
+		break;
+	case 2:
+		*slot =3D *func =3D -1;
+		err =3D sscanf(buf, " %x:%x:*.%c", domain, bus, &wc);
+		if (err >=3D 2)
+			++err;
+		break;
+	}
+	if (err =3D=3D 4 && wc =3D=3D '*')
 		return 0;
 	else if (err < 0)
 		return -EINVAL;
=20
 	/* try again without domain */
 	*domain =3D 0;
+	wc =3D '*';
 	err =3D sscanf(buf, " %x:%x.%x", bus, slot, func);
-	if (err =3D=3D 3)
+	switch (err) {
+	case 2:
+		*func =3D -1;
+		err =3D sscanf(buf, " %x:%x.%c", bus, slot, &wc);
+		break;
+	case 1:
+		*slot =3D *func =3D -1;
+		err =3D sscanf(buf, " %x:*.%c", bus, &wc) + 1;
+		break;
+	}
+	if (err =3D=3D 3 && wc =3D=3D '*')
 		return 0;
=20
 	return -EINVAL;
@@ -894,6 +918,19 @@ static int pcistub_device_id_add(int dom
 {
 	struct pcistub_device_id *pci_dev_id;
 	unsigned long flags;
+	int rc =3D 0;
+
+	if (slot < 0) {
+		for (slot =3D 0; !rc && slot < 32; ++slot)
+			rc =3D pcistub_device_id_add(domain, bus, slot, =
func);
+		return rc;
+	}
+
+	if (func < 0) {
+		for (func =3D 0; !rc && func < 8; ++func)
+			rc =3D pcistub_device_id_add(domain, bus, slot, =
func);
+		return rc;
+	}
=20
 	pci_dev_id =3D kmalloc(sizeof(*pci_dev_id), GFP_KERNEL);
 	if (!pci_dev_id)
@@ -916,15 +953,15 @@ static int pcistub_device_id_add(int dom
 static int pcistub_device_id_remove(int domain, int bus, int slot, int =
func)
 {
 	struct pcistub_device_id *pci_dev_id, *t;
-	int devfn =3D PCI_DEVFN(slot, func);
 	int err =3D -ENOENT;
 	unsigned long flags;
=20
 	spin_lock_irqsave(&device_ids_lock, flags);
 	list_for_each_entry_safe(pci_dev_id, t, &pcistub_device_ids, =
slot_list) {
=20
-		if (pci_dev_id->domain =3D=3D domain
-		    && pci_dev_id->bus =3D=3D bus && pci_dev_id->devfn =
=3D=3D devfn) {
+		if (pci_dev_id->domain =3D=3D domain && pci_dev_id->bus =
=3D=3D bus
+		    && (slot < 0 || PCI_SLOT(pci_dev_id->devfn) =3D=3D =
slot)
+		    && (func < 0 || PCI_FUNC(pci_dev_id->devfn) =3D=3D =
func)) {
 			/* Don't break; here because it's possible the =
same
 			 * slot could be in the list more than once
 			 */
@@ -1117,6 +1154,10 @@ static ssize_t permissive_add(struct dev
 	err =3D str_to_slot(buf, &domain, &bus, &slot, &func);
 	if (err)
 		goto out;
+	if (slot < 0 || func < 0) {
+		err =3D -EINVAL;
+		goto out;
+	}
 	psdev =3D pcistub_device_find(domain, bus, slot, func);
 	if (!psdev) {
 		err =3D -ENODEV;
@@ -1211,17 +1252,51 @@ static int __init pcistub_init(void)
=20
 	if (pci_devs_to_hide && *pci_devs_to_hide) {
 		do {
+			char wc =3D '*';
+
 			parsed =3D 0;
=20
 			err =3D sscanf(pci_devs_to_hide + pos,
 				     " (%x:%x:%x.%x) %n",
 				     &domain, &bus, &slot, &func, =
&parsed);
-			if (err !=3D 4) {
+			switch (err) {
+			case 3:
+				func =3D -1;
+				err =3D sscanf(pci_devs_to_hide + pos,
+					     " (%x:%x:%x.%c) %n",
+					     &domain, &bus, &slot, &wc,
+					     &parsed);
+				break;
+			case 2:
+				slot =3D func =3D -1;
+				err =3D sscanf(pci_devs_to_hide + pos,
+					     " (%x:%x:*.%c) %n",
+					     &domain, &bus, &wc, &parsed) =
+ 1;
+				break;
+			}
+
+			if (err !=3D 4 || wc !=3D '*') {
 				domain =3D 0;
+				wc =3D '*';
 				err =3D sscanf(pci_devs_to_hide + pos,
 					     " (%x:%x.%x) %n",
 					     &bus, &slot, &func, &parsed);
-				if (err !=3D 3)
+				switch (err) {
+				case 2:
+					func =3D -1;
+					err =3D sscanf(pci_devs_to_hide + =
pos,
+						     " (%x:%x.%c) %n",
+						     &bus, &slot, &wc,
+						     &parsed);
+					break;
+				case 1:
+					slot =3D func =3D -1;
+					err =3D sscanf(pci_devs_to_hide + =
pos,
+						     " (%x:*.%c) %n",
+						     &bus, &wc, &parsed) + =
1;
+					break;
+				}
+				if (err !=3D 3 || wc !=3D '*')
 					goto parse_error;
 			}
=20



--=__PartD4E5E90E.0__=
Content-Type: text/plain; name="xen-pciback-wildcard.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="xen-pciback-wildcard.patch"

pciback: support wild cards in slot specifications=0A=0AParticularly for =
hiding sets of SR-IOV devices, specifying them all=0Aindividually is =
rather cumbersome. Therefore, allow function and slot=0Anumbers to be =
replaced by a wildcard character ('*').=0A=0AUnfortunately this gets =
complicated by the in-kernel sscanf()=0Aimplementation not being really =
standard conformant - matching of=0Aplain text tails cannot be checked by =
the caller (a patch to overcome=0Athis will be sent shortly, and a =
follow-up patch for simplifying the=0Acode is planned to be sent when that =
fixed went upstream).=0A=0ASigned-off-by: Jan Beulich <jbeulich@suse.com>=
=0A=0A--- a/drivers/xen/pciback/pci_stub.c=0A+++ b/drivers/xen/pciback/pci_=
stub.c=0A@@ -861,17 +861,41 @@ static inline int str_to_slot(const char=0A =
			      int *slot, int *func)=0A {=0A 	int =
err;=0A+	char wc =3D '*';=0A =0A 	err =3D sscanf(buf, " =
%x:%x:%x.%x", domain, bus, slot, func);=0A-	if (err =3D=3D 4)=0A+	=
switch (err) {=0A+	case 3:=0A+		*func =3D -1;=0A+		=
err =3D sscanf(buf, " %x:%x:%x.%c", domain, bus, slot, &wc);=0A+		=
break;=0A+	case 2:=0A+		*slot =3D *func =3D -1;=0A+		=
err =3D sscanf(buf, " %x:%x:*.%c", domain, bus, &wc);=0A+		if =
(err >=3D 2)=0A+			++err;=0A+		break;=0A+	=
}=0A+	if (err =3D=3D 4 && wc =3D=3D '*')=0A 		return 0;=0A 	=
else if (err < 0)=0A 		return -EINVAL;=0A =0A 	/* try again =
without domain */=0A 	*domain =3D 0;=0A+	wc =3D '*';=0A 	err =3D =
sscanf(buf, " %x:%x.%x", bus, slot, func);=0A-	if (err =3D=3D 3)=0A+	=
switch (err) {=0A+	case 2:=0A+		*func =3D -1;=0A+		=
err =3D sscanf(buf, " %x:%x.%c", bus, slot, &wc);=0A+		break;=0A+	=
case 1:=0A+		*slot =3D *func =3D -1;=0A+		err =3D =
sscanf(buf, " %x:*.%c", bus, &wc) + 1;=0A+		break;=0A+	=
}=0A+	if (err =3D=3D 3 && wc =3D=3D '*')=0A 		return 0;=0A =0A 	=
return -EINVAL;=0A@@ -894,6 +918,19 @@ static int pcistub_device_id_add(int=
 dom=0A {=0A 	struct pcistub_device_id *pci_dev_id;=0A 	unsigned =
long flags;=0A+	int rc =3D 0;=0A+=0A+	if (slot < 0) {=0A+		=
for (slot =3D 0; !rc && slot < 32; ++slot)=0A+			rc =3D =
pcistub_device_id_add(domain, bus, slot, func);=0A+		return =
rc;=0A+	}=0A+=0A+	if (func < 0) {=0A+		for (func =3D 0; =
!rc && func < 8; ++func)=0A+			rc =3D pcistub_device_id_ad=
d(domain, bus, slot, func);=0A+		return rc;=0A+	}=0A =0A 	=
pci_dev_id =3D kmalloc(sizeof(*pci_dev_id), GFP_KERNEL);=0A 	if =
(!pci_dev_id)=0A@@ -916,15 +953,15 @@ static int pcistub_device_id_add(int =
dom=0A static int pcistub_device_id_remove(int domain, int bus, int slot, =
int func)=0A {=0A 	struct pcistub_device_id *pci_dev_id, *t;=0A-	=
int devfn =3D PCI_DEVFN(slot, func);=0A 	int err =3D -ENOENT;=0A 	=
unsigned long flags;=0A =0A 	spin_lock_irqsave(&device_ids_lock, =
flags);=0A 	list_for_each_entry_safe(pci_dev_id, t, &pcistub_device_ids=
, slot_list) {=0A =0A-		if (pci_dev_id->domain =3D=3D domain=0A-	=
	    && pci_dev_id->bus =3D=3D bus && pci_dev_id->devfn =3D=3D =
devfn) {=0A+		if (pci_dev_id->domain =3D=3D domain && pci_dev_id-=
>bus =3D=3D bus=0A+		    && (slot < 0 || PCI_SLOT(pci_dev_id->de=
vfn) =3D=3D slot)=0A+		    && (func < 0 || PCI_FUNC(pci_dev_id->de=
vfn) =3D=3D func)) {=0A 			/* Don't break; here =
because it's possible the same=0A 			 * slot could be =
in the list more than once=0A 			 */=0A@@ -1117,6 +1154,10 =
@@ static ssize_t permissive_add(struct dev=0A 	err =3D str_to_slot(buf, =
&domain, &bus, &slot, &func);=0A 	if (err)=0A 		goto =
out;=0A+	if (slot < 0 || func < 0) {=0A+		err =3D -EINVAL;=0A=
+		goto out;=0A+	}=0A 	psdev =3D pcistub_device_find(domai=
n, bus, slot, func);=0A 	if (!psdev) {=0A 		err =3D =
-ENODEV;=0A@@ -1211,17 +1252,51 @@ static int __init pcistub_init(void)=0A =
=0A 	if (pci_devs_to_hide && *pci_devs_to_hide) {=0A 		do =
{=0A+			char wc =3D '*';=0A+=0A 			=
parsed =3D 0;=0A =0A 			err =3D sscanf(pci_devs_to_hide + =
pos,=0A 				     " (%x:%x:%x.%x) %n",=0A 		=
		     &domain, &bus, &slot, &func, &parsed);=0A-			=
if (err !=3D 4) {=0A+			switch (err) {=0A+			=
case 3:=0A+				func =3D -1;=0A+			=
	err =3D sscanf(pci_devs_to_hide + pos,=0A+				=
	     " (%x:%x:%x.%c) %n",=0A+					   =
  &domain, &bus, &slot, &wc,=0A+					   =
  &parsed);=0A+				break;=0A+			=
case 2:=0A+				slot =3D func =3D -1;=0A+		=
		err =3D sscanf(pci_devs_to_hide + pos,=0A+			=
		     " (%x:%x:*.%c) %n",=0A+					=
     &domain, &bus, &wc, &parsed) + 1;=0A+				=
break;=0A+			}=0A+=0A+			if (err =
!=3D 4 || wc !=3D '*') {=0A 				domain =3D 0;=0A+	=
			wc =3D '*';=0A 				err =3D =
sscanf(pci_devs_to_hide + pos,=0A 					   =
  " (%x:%x.%x) %n",=0A 					     &bus, &slot, =
&func, &parsed);=0A-				if (err !=3D 3)=0A+		=
		switch (err) {=0A+				case =
2:=0A+					func =3D -1;=0A+			=
		err =3D sscanf(pci_devs_to_hide + pos,=0A+			=
			     " (%x:%x.%c) %n",=0A+				=
		     &bus, &slot, &wc,=0A+					=
	     &parsed);=0A+					break;=0A+	=
			case 1:=0A+					=
slot =3D func =3D -1;=0A+					err =3D =
sscanf(pci_devs_to_hide + pos,=0A+						=
     " (%x:*.%c) %n",=0A+						   =
  &bus, &wc, &parsed) + 1;=0A+					break;=0A+	=
			}=0A+				if (err !=3D 3 || =
wc !=3D '*')=0A 					goto parse_error;=
=0A 			}=0A =0A
--=__PartD4E5E90E.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

--=__PartD4E5E90E.0__=--


From xen-devel-bounces@lists.xen.org Mon Sep 24 15:54:25 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Sep 2012 15: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 1TGAz7-0007Qn-Sy; Mon, 24 Sep 2012 15:54: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 1TGAz6-0007Qi-2F
	for xen-devel@lists.xen.org; Mon, 24 Sep 2012 15:54:12 +0000
Received: from [85.158.143.99:54536] by server-3.bemta-4.messagelabs.com id
	2A/72-10986-32280605; Mon, 24 Sep 2012 15:54:11 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1348502050!30663172!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30040 invoked from network); 24 Sep 2012 15:54:10 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-13.tower-216.messagelabs.com with SMTP;
	24 Sep 2012 15:54:10 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 24 Sep 2012 16:54:12 +0100
Message-Id: <50609E3E020000780009D699@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 24 Sep 2012 16:54:06 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__PartD4E5E90E.0__="
Subject: [Xen-devel] [PATCH 1/3] linux-2.6.18/pciback: support wild cards in
 slot specifications
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<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.

--=__PartD4E5E90E.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Particularly for hiding sets of SR-IOV devices, specifying them all
individually is rather cumbersome. Therefore, allow function and slot
numbers to be replaced by a wildcard character ('*').

Unfortunately this gets complicated by the in-kernel sscanf()
implementation not being really standard conformant - matching of
plain text tails cannot be checked by the caller (a patch to overcome
this will be sent shortly, and a follow-up patch for simplifying the
code is planned to be sent when that fixed went upstream).

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/drivers/xen/pciback/pci_stub.c
+++ b/drivers/xen/pciback/pci_stub.c
@@ -861,17 +861,41 @@ static inline int str_to_slot(const char
 			      int *slot, int *func)
 {
 	int err;
+	char wc =3D '*';
=20
 	err =3D sscanf(buf, " %x:%x:%x.%x", domain, bus, slot, func);
-	if (err =3D=3D 4)
+	switch (err) {
+	case 3:
+		*func =3D -1;
+		err =3D sscanf(buf, " %x:%x:%x.%c", domain, bus, slot, =
&wc);
+		break;
+	case 2:
+		*slot =3D *func =3D -1;
+		err =3D sscanf(buf, " %x:%x:*.%c", domain, bus, &wc);
+		if (err >=3D 2)
+			++err;
+		break;
+	}
+	if (err =3D=3D 4 && wc =3D=3D '*')
 		return 0;
 	else if (err < 0)
 		return -EINVAL;
=20
 	/* try again without domain */
 	*domain =3D 0;
+	wc =3D '*';
 	err =3D sscanf(buf, " %x:%x.%x", bus, slot, func);
-	if (err =3D=3D 3)
+	switch (err) {
+	case 2:
+		*func =3D -1;
+		err =3D sscanf(buf, " %x:%x.%c", bus, slot, &wc);
+		break;
+	case 1:
+		*slot =3D *func =3D -1;
+		err =3D sscanf(buf, " %x:*.%c", bus, &wc) + 1;
+		break;
+	}
+	if (err =3D=3D 3 && wc =3D=3D '*')
 		return 0;
=20
 	return -EINVAL;
@@ -894,6 +918,19 @@ static int pcistub_device_id_add(int dom
 {
 	struct pcistub_device_id *pci_dev_id;
 	unsigned long flags;
+	int rc =3D 0;
+
+	if (slot < 0) {
+		for (slot =3D 0; !rc && slot < 32; ++slot)
+			rc =3D pcistub_device_id_add(domain, bus, slot, =
func);
+		return rc;
+	}
+
+	if (func < 0) {
+		for (func =3D 0; !rc && func < 8; ++func)
+			rc =3D pcistub_device_id_add(domain, bus, slot, =
func);
+		return rc;
+	}
=20
 	pci_dev_id =3D kmalloc(sizeof(*pci_dev_id), GFP_KERNEL);
 	if (!pci_dev_id)
@@ -916,15 +953,15 @@ static int pcistub_device_id_add(int dom
 static int pcistub_device_id_remove(int domain, int bus, int slot, int =
func)
 {
 	struct pcistub_device_id *pci_dev_id, *t;
-	int devfn =3D PCI_DEVFN(slot, func);
 	int err =3D -ENOENT;
 	unsigned long flags;
=20
 	spin_lock_irqsave(&device_ids_lock, flags);
 	list_for_each_entry_safe(pci_dev_id, t, &pcistub_device_ids, =
slot_list) {
=20
-		if (pci_dev_id->domain =3D=3D domain
-		    && pci_dev_id->bus =3D=3D bus && pci_dev_id->devfn =
=3D=3D devfn) {
+		if (pci_dev_id->domain =3D=3D domain && pci_dev_id->bus =
=3D=3D bus
+		    && (slot < 0 || PCI_SLOT(pci_dev_id->devfn) =3D=3D =
slot)
+		    && (func < 0 || PCI_FUNC(pci_dev_id->devfn) =3D=3D =
func)) {
 			/* Don't break; here because it's possible the =
same
 			 * slot could be in the list more than once
 			 */
@@ -1117,6 +1154,10 @@ static ssize_t permissive_add(struct dev
 	err =3D str_to_slot(buf, &domain, &bus, &slot, &func);
 	if (err)
 		goto out;
+	if (slot < 0 || func < 0) {
+		err =3D -EINVAL;
+		goto out;
+	}
 	psdev =3D pcistub_device_find(domain, bus, slot, func);
 	if (!psdev) {
 		err =3D -ENODEV;
@@ -1211,17 +1252,51 @@ static int __init pcistub_init(void)
=20
 	if (pci_devs_to_hide && *pci_devs_to_hide) {
 		do {
+			char wc =3D '*';
+
 			parsed =3D 0;
=20
 			err =3D sscanf(pci_devs_to_hide + pos,
 				     " (%x:%x:%x.%x) %n",
 				     &domain, &bus, &slot, &func, =
&parsed);
-			if (err !=3D 4) {
+			switch (err) {
+			case 3:
+				func =3D -1;
+				err =3D sscanf(pci_devs_to_hide + pos,
+					     " (%x:%x:%x.%c) %n",
+					     &domain, &bus, &slot, &wc,
+					     &parsed);
+				break;
+			case 2:
+				slot =3D func =3D -1;
+				err =3D sscanf(pci_devs_to_hide + pos,
+					     " (%x:%x:*.%c) %n",
+					     &domain, &bus, &wc, &parsed) =
+ 1;
+				break;
+			}
+
+			if (err !=3D 4 || wc !=3D '*') {
 				domain =3D 0;
+				wc =3D '*';
 				err =3D sscanf(pci_devs_to_hide + pos,
 					     " (%x:%x.%x) %n",
 					     &bus, &slot, &func, &parsed);
-				if (err !=3D 3)
+				switch (err) {
+				case 2:
+					func =3D -1;
+					err =3D sscanf(pci_devs_to_hide + =
pos,
+						     " (%x:%x.%c) %n",
+						     &bus, &slot, &wc,
+						     &parsed);
+					break;
+				case 1:
+					slot =3D func =3D -1;
+					err =3D sscanf(pci_devs_to_hide + =
pos,
+						     " (%x:*.%c) %n",
+						     &bus, &wc, &parsed) + =
1;
+					break;
+				}
+				if (err !=3D 3 || wc !=3D '*')
 					goto parse_error;
 			}
=20



--=__PartD4E5E90E.0__=
Content-Type: text/plain; name="xen-pciback-wildcard.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="xen-pciback-wildcard.patch"

pciback: support wild cards in slot specifications=0A=0AParticularly for =
hiding sets of SR-IOV devices, specifying them all=0Aindividually is =
rather cumbersome. Therefore, allow function and slot=0Anumbers to be =
replaced by a wildcard character ('*').=0A=0AUnfortunately this gets =
complicated by the in-kernel sscanf()=0Aimplementation not being really =
standard conformant - matching of=0Aplain text tails cannot be checked by =
the caller (a patch to overcome=0Athis will be sent shortly, and a =
follow-up patch for simplifying the=0Acode is planned to be sent when that =
fixed went upstream).=0A=0ASigned-off-by: Jan Beulich <jbeulich@suse.com>=
=0A=0A--- a/drivers/xen/pciback/pci_stub.c=0A+++ b/drivers/xen/pciback/pci_=
stub.c=0A@@ -861,17 +861,41 @@ static inline int str_to_slot(const char=0A =
			      int *slot, int *func)=0A {=0A 	int =
err;=0A+	char wc =3D '*';=0A =0A 	err =3D sscanf(buf, " =
%x:%x:%x.%x", domain, bus, slot, func);=0A-	if (err =3D=3D 4)=0A+	=
switch (err) {=0A+	case 3:=0A+		*func =3D -1;=0A+		=
err =3D sscanf(buf, " %x:%x:%x.%c", domain, bus, slot, &wc);=0A+		=
break;=0A+	case 2:=0A+		*slot =3D *func =3D -1;=0A+		=
err =3D sscanf(buf, " %x:%x:*.%c", domain, bus, &wc);=0A+		if =
(err >=3D 2)=0A+			++err;=0A+		break;=0A+	=
}=0A+	if (err =3D=3D 4 && wc =3D=3D '*')=0A 		return 0;=0A 	=
else if (err < 0)=0A 		return -EINVAL;=0A =0A 	/* try again =
without domain */=0A 	*domain =3D 0;=0A+	wc =3D '*';=0A 	err =3D =
sscanf(buf, " %x:%x.%x", bus, slot, func);=0A-	if (err =3D=3D 3)=0A+	=
switch (err) {=0A+	case 2:=0A+		*func =3D -1;=0A+		=
err =3D sscanf(buf, " %x:%x.%c", bus, slot, &wc);=0A+		break;=0A+	=
case 1:=0A+		*slot =3D *func =3D -1;=0A+		err =3D =
sscanf(buf, " %x:*.%c", bus, &wc) + 1;=0A+		break;=0A+	=
}=0A+	if (err =3D=3D 3 && wc =3D=3D '*')=0A 		return 0;=0A =0A 	=
return -EINVAL;=0A@@ -894,6 +918,19 @@ static int pcistub_device_id_add(int=
 dom=0A {=0A 	struct pcistub_device_id *pci_dev_id;=0A 	unsigned =
long flags;=0A+	int rc =3D 0;=0A+=0A+	if (slot < 0) {=0A+		=
for (slot =3D 0; !rc && slot < 32; ++slot)=0A+			rc =3D =
pcistub_device_id_add(domain, bus, slot, func);=0A+		return =
rc;=0A+	}=0A+=0A+	if (func < 0) {=0A+		for (func =3D 0; =
!rc && func < 8; ++func)=0A+			rc =3D pcistub_device_id_ad=
d(domain, bus, slot, func);=0A+		return rc;=0A+	}=0A =0A 	=
pci_dev_id =3D kmalloc(sizeof(*pci_dev_id), GFP_KERNEL);=0A 	if =
(!pci_dev_id)=0A@@ -916,15 +953,15 @@ static int pcistub_device_id_add(int =
dom=0A static int pcistub_device_id_remove(int domain, int bus, int slot, =
int func)=0A {=0A 	struct pcistub_device_id *pci_dev_id, *t;=0A-	=
int devfn =3D PCI_DEVFN(slot, func);=0A 	int err =3D -ENOENT;=0A 	=
unsigned long flags;=0A =0A 	spin_lock_irqsave(&device_ids_lock, =
flags);=0A 	list_for_each_entry_safe(pci_dev_id, t, &pcistub_device_ids=
, slot_list) {=0A =0A-		if (pci_dev_id->domain =3D=3D domain=0A-	=
	    && pci_dev_id->bus =3D=3D bus && pci_dev_id->devfn =3D=3D =
devfn) {=0A+		if (pci_dev_id->domain =3D=3D domain && pci_dev_id-=
>bus =3D=3D bus=0A+		    && (slot < 0 || PCI_SLOT(pci_dev_id->de=
vfn) =3D=3D slot)=0A+		    && (func < 0 || PCI_FUNC(pci_dev_id->de=
vfn) =3D=3D func)) {=0A 			/* Don't break; here =
because it's possible the same=0A 			 * slot could be =
in the list more than once=0A 			 */=0A@@ -1117,6 +1154,10 =
@@ static ssize_t permissive_add(struct dev=0A 	err =3D str_to_slot(buf, =
&domain, &bus, &slot, &func);=0A 	if (err)=0A 		goto =
out;=0A+	if (slot < 0 || func < 0) {=0A+		err =3D -EINVAL;=0A=
+		goto out;=0A+	}=0A 	psdev =3D pcistub_device_find(domai=
n, bus, slot, func);=0A 	if (!psdev) {=0A 		err =3D =
-ENODEV;=0A@@ -1211,17 +1252,51 @@ static int __init pcistub_init(void)=0A =
=0A 	if (pci_devs_to_hide && *pci_devs_to_hide) {=0A 		do =
{=0A+			char wc =3D '*';=0A+=0A 			=
parsed =3D 0;=0A =0A 			err =3D sscanf(pci_devs_to_hide + =
pos,=0A 				     " (%x:%x:%x.%x) %n",=0A 		=
		     &domain, &bus, &slot, &func, &parsed);=0A-			=
if (err !=3D 4) {=0A+			switch (err) {=0A+			=
case 3:=0A+				func =3D -1;=0A+			=
	err =3D sscanf(pci_devs_to_hide + pos,=0A+				=
	     " (%x:%x:%x.%c) %n",=0A+					   =
  &domain, &bus, &slot, &wc,=0A+					   =
  &parsed);=0A+				break;=0A+			=
case 2:=0A+				slot =3D func =3D -1;=0A+		=
		err =3D sscanf(pci_devs_to_hide + pos,=0A+			=
		     " (%x:%x:*.%c) %n",=0A+					=
     &domain, &bus, &wc, &parsed) + 1;=0A+				=
break;=0A+			}=0A+=0A+			if (err =
!=3D 4 || wc !=3D '*') {=0A 				domain =3D 0;=0A+	=
			wc =3D '*';=0A 				err =3D =
sscanf(pci_devs_to_hide + pos,=0A 					   =
  " (%x:%x.%x) %n",=0A 					     &bus, &slot, =
&func, &parsed);=0A-				if (err !=3D 3)=0A+		=
		switch (err) {=0A+				case =
2:=0A+					func =3D -1;=0A+			=
		err =3D sscanf(pci_devs_to_hide + pos,=0A+			=
			     " (%x:%x.%c) %n",=0A+				=
		     &bus, &slot, &wc,=0A+					=
	     &parsed);=0A+					break;=0A+	=
			case 1:=0A+					=
slot =3D func =3D -1;=0A+					err =3D =
sscanf(pci_devs_to_hide + pos,=0A+						=
     " (%x:*.%c) %n",=0A+						   =
  &bus, &wc, &parsed) + 1;=0A+					break;=0A+	=
			}=0A+				if (err !=3D 3 || =
wc !=3D '*')=0A 					goto parse_error;=
=0A 			}=0A =0A
--=__PartD4E5E90E.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

--=__PartD4E5E90E.0__=--


From xen-devel-bounces@lists.xen.org Mon Sep 24 15:54:50 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Sep 2012 15:54:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGAzb-0007TT-AH; Mon, 24 Sep 2012 15:54: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 1TGAzZ-0007TD-Up
	for xen-devel@lists.xen.org; Mon, 24 Sep 2012 15:54:42 +0000
Received: from [85.158.143.99:57842] by server-3.bemta-4.messagelabs.com id
	28/73-10986-14280605; Mon, 24 Sep 2012 15:54:41 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1348502080!31241028!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7922 invoked from network); 24 Sep 2012 15:54:40 -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;
	24 Sep 2012 15:54:40 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 24 Sep 2012 16:54:42 +0100
Message-Id: <50609E5C020000780009D69D@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 24 Sep 2012 16:54: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="=__PartF6C7CB2C.0__="
Subject: [Xen-devel] [PATCH 2/3] linux-2.6.18/pciback: properly clean up
 after calling pcistub_device_find()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<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.

--=__PartF6C7CB2C.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

As the function calls pcistub_device_get() before returning non-NULL,
its callers need to take care of calling pcistub_device_put() on
(mostly, but not exclusively) error paths.

Otoh, the function already guarantees that the 'dev' member is non-NULL
upon successful return, so callers do not need to check for this a
second time.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/drivers/xen/pciback/pci_stub.c
+++ b/drivers/xen/pciback/pci_stub.c
@@ -642,14 +642,14 @@ static pci_ers_result_t pciback_slot_res
 		dev_err(&dev->dev, "pciback device is not connected or =
owned"
 			" by HVM, kill it\n");
 		kill_domain_by_device(psdev);
-		goto release;
+		goto end;
 	}
=20
 	if ( !test_bit(_XEN_PCIB_AERHANDLER,=20
 		(unsigned long *)&psdev->pdev->sh_info->flags) ) {
 		dev_err(&dev->dev,=20
 			"guest with no AER driver should have been =
killed\n");
-		goto release;
+		goto end;
 	}
 	result =3D common_process(psdev, 1, XEN_PCI_OP_aer_slotreset, =
result);
=20
@@ -659,9 +659,9 @@ static pci_ers_result_t pciback_slot_res
 			"No AER slot_reset service or disconnected!\n");
 		kill_domain_by_device(psdev);
 	}
-release:
-	pcistub_device_put(psdev);
 end:
+	if (psdev)
+		pcistub_device_put(psdev);
 	up_write(&pcistub_sem);
 	return result;
=20
@@ -702,14 +702,14 @@ static pci_ers_result_t pciback_mmio_ena
 		dev_err(&dev->dev, "pciback device is not connected or =
owned"
 			" by HVM, kill it\n");
 		kill_domain_by_device(psdev);
-		goto release;
+		goto end;
 	}
=20
 	if ( !test_bit(_XEN_PCIB_AERHANDLER,=20
 		(unsigned long *)&psdev->pdev->sh_info->flags) ) {
 		dev_err(&dev->dev,=20
 			"guest with no AER driver should have been =
killed\n");
-		goto release;
+		goto end;
 	}
 	result =3D common_process(psdev, 1, XEN_PCI_OP_aer_mmio, result);
=20
@@ -719,9 +719,9 @@ static pci_ers_result_t pciback_mmio_ena
 			"No AER mmio_enabled service or disconnected!\n");
 		kill_domain_by_device(psdev);
 	}
-release:
-	pcistub_device_put(psdev);
 end:
+	if (psdev)
+		pcistub_device_put(psdev);
 	up_write(&pcistub_sem);
 	return result;
 }
@@ -762,7 +762,7 @@ static pci_ers_result_t pciback_error_de
 		dev_err(&dev->dev, "pciback device is not connected or =
owned"
 			" by HVM, kill it\n");
 		kill_domain_by_device(psdev);
-		goto release;
+		goto end;
 	}
=20
 	/*Guest owns the device yet no aer handler regiested, kill guest*/
@@ -770,7 +770,7 @@ static pci_ers_result_t pciback_error_de
 		(unsigned long *)&psdev->pdev->sh_info->flags) ) {
 		dev_dbg(&dev->dev, "guest may have no aer driver, kill =
it\n");
 		kill_domain_by_device(psdev);
-		goto release;
+		goto end;
 	}
 	result =3D common_process(psdev, error, XEN_PCI_OP_aer_detected, =
result);
=20
@@ -780,9 +780,9 @@ static pci_ers_result_t pciback_error_de
 			"No AER error_detected service or disconnected!\n")=
;
 		kill_domain_by_device(psdev);
 	}
-release:
-	pcistub_device_put(psdev);
 end:
+	if (psdev)
+		pcistub_device_put(psdev);
 	up_write(&pcistub_sem);
 	return result;
 }
@@ -818,7 +818,7 @@ static void pciback_error_resume(struct=20
 		dev_err(&dev->dev, "pciback device is not connected or =
owned"
 			" by HVM, kill it\n");
 		kill_domain_by_device(psdev);
-		goto release;
+		goto end;
 	}
=20
 	if ( !test_bit(_XEN_PCIB_AERHANDLER,=20
@@ -826,12 +826,12 @@ static void pciback_error_resume(struct=20
 		dev_err(&dev->dev,=20
 			"guest with no AER driver should have been =
killed\n");
 		kill_domain_by_device(psdev);
-		goto release;
+		goto end;
 	}
 	common_process(psdev, 1, XEN_PCI_OP_aer_resume, PCI_ERS_RESULT_RECO=
VERED);
-release:
-	pcistub_device_put(psdev);
 end:
+	if (psdev)
+		pcistub_device_put(psdev);
 	up_write(&pcistub_sem);
 	return;
 }
@@ -988,7 +988,7 @@ static int pcistub_reg_add(int domain, i
 	struct config_field *field;
=20
 	psdev =3D pcistub_device_find(domain, bus, slot, func);
-	if (!psdev || !psdev->dev) {
+	if (!psdev) {
 		err =3D -ENODEV;
 		goto out;
 	}
@@ -1012,6 +1012,8 @@ static int pcistub_reg_add(int domain, i
 	if (err)
 		kfree(field);
       out:
+	if (psdev)
+		pcistub_device_put(psdev);
 	return err;
 }
=20
@@ -1163,10 +1165,7 @@ static ssize_t permissive_add(struct dev
 		err =3D -ENODEV;
 		goto out;
 	}
-	if (!psdev->dev) {
-		err =3D -ENODEV;
-		goto release;
-	}
+
 	dev_data =3D pci_get_drvdata(psdev->dev);
 	/* the driver data for a device should never be null at this point =
*/
 	if (!dev_data) {
@@ -1219,14 +1218,18 @@ DRIVER_ATTR(permissive, S_IRUSR | S_IWUS
 int pciback_get_owner(struct pci_dev *dev)
 {
 	struct pcistub_device *psdev;
+	int rc;
=20
 	psdev =3D pcistub_device_find(pci_domain_nr(dev->bus), dev->bus->nu=
mber,
 			PCI_SLOT(dev->devfn), PCI_FUNC(dev->devfn));
=20
-	if (!psdev || !psdev->pdev)
-		return -1;
+	if (!psdev)
+		return -ESRCH;
+
+	rc =3D psdev->pdev ? psdev->pdev->xdev->otherend_id : -EINVAL;
=20
-	return psdev->pdev->xdev->otherend_id;
+	pcistub_device_put(psdev);
+	return rc;
 }
 #endif
=20



--=__PartF6C7CB2C.0__=
Content-Type: text/plain; name="xen-pciback-find-error-paths.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="xen-pciback-find-error-paths.patch"

pciback: properly clean up after calling pcistub_device_find()=0A=0AAs the =
function calls pcistub_device_get() before returning non-NULL,=0Aits =
callers need to take care of calling pcistub_device_put() on=0A(mostly, =
but not exclusively) error paths.=0A=0AOtoh, the function already =
guarantees that the 'dev' member is non-NULL=0Aupon successful return, so =
callers do not need to check for this a=0Asecond time.=0A=0ASigned-off-by: =
Jan Beulich <jbeulich@suse.com>=0A=0A--- a/drivers/xen/pciback/pci_stub.c=
=0A+++ b/drivers/xen/pciback/pci_stub.c=0A@@ -642,14 +642,14 @@ static =
pci_ers_result_t pciback_slot_res=0A 		dev_err(&dev->dev, =
"pciback device is not connected or owned"=0A 			" by HVM, =
kill it\n");=0A 		kill_domain_by_device(psdev);=0A-		=
goto release;=0A+		goto end;=0A 	}=0A =0A 	if ( =
!test_bit(_XEN_PCIB_AERHANDLER, =0A 		(unsigned long *)&psdev->pd=
ev->sh_info->flags) ) {=0A 		dev_err(&dev->dev, =0A 			=
"guest with no AER driver should have been killed\n");=0A-		=
goto release;=0A+		goto end;=0A 	}=0A 	result =3D =
common_process(psdev, 1, XEN_PCI_OP_aer_slotreset, result);=0A =0A@@ =
-659,9 +659,9 @@ static pci_ers_result_t pciback_slot_res=0A 			=
"No AER slot_reset service or disconnected!\n");=0A 		kill_domain=
_by_device(psdev);=0A 	}=0A-release:=0A-	pcistub_device_put(psdev);=
=0A end:=0A+	if (psdev)=0A+		pcistub_device_put(psdev);=0A 	=
up_write(&pcistub_sem);=0A 	return result;=0A =0A@@ -702,14 +702,14 @@ =
static pci_ers_result_t pciback_mmio_ena=0A 		dev_err(&dev->dev, =
"pciback device is not connected or owned"=0A 			" by HVM, =
kill it\n");=0A 		kill_domain_by_device(psdev);=0A-		=
goto release;=0A+		goto end;=0A 	}=0A =0A 	if ( =
!test_bit(_XEN_PCIB_AERHANDLER, =0A 		(unsigned long *)&psdev->pd=
ev->sh_info->flags) ) {=0A 		dev_err(&dev->dev, =0A 			=
"guest with no AER driver should have been killed\n");=0A-		=
goto release;=0A+		goto end;=0A 	}=0A 	result =3D =
common_process(psdev, 1, XEN_PCI_OP_aer_mmio, result);=0A =0A@@ -719,9 =
+719,9 @@ static pci_ers_result_t pciback_mmio_ena=0A 			=
"No AER mmio_enabled service or disconnected!\n");=0A 		kill_domain=
_by_device(psdev);=0A 	}=0A-release:=0A-	pcistub_device_put(psdev);=
=0A end:=0A+	if (psdev)=0A+		pcistub_device_put(psdev);=0A 	=
up_write(&pcistub_sem);=0A 	return result;=0A }=0A@@ -762,7 +762,7 @@ =
static pci_ers_result_t pciback_error_de=0A 		dev_err(&dev->dev, =
"pciback device is not connected or owned"=0A 			" by HVM, =
kill it\n");=0A 		kill_domain_by_device(psdev);=0A-		=
goto release;=0A+		goto end;=0A 	}=0A =0A 	/*Guest =
owns the device yet no aer handler regiested, kill guest*/=0A@@ -770,7 =
+770,7 @@ static pci_ers_result_t pciback_error_de=0A 		(unsigned =
long *)&psdev->pdev->sh_info->flags) ) {=0A 		dev_dbg(&dev->dev, =
"guest may have no aer driver, kill it\n");=0A 		kill_domain_by_devi=
ce(psdev);=0A-		goto release;=0A+		goto end;=0A 	=
}=0A 	result =3D common_process(psdev, error, XEN_PCI_OP_aer_detected, =
result);=0A =0A@@ -780,9 +780,9 @@ static pci_ers_result_t pciback_error_de=
=0A 			"No AER error_detected service or disconnected!\n")=
;=0A 		kill_domain_by_device(psdev);=0A 	}=0A-release:=0A-	=
pcistub_device_put(psdev);=0A end:=0A+	if (psdev)=0A+		pcistub_dev=
ice_put(psdev);=0A 	up_write(&pcistub_sem);=0A 	return result;=0A =
}=0A@@ -818,7 +818,7 @@ static void pciback_error_resume(struct =0A 		=
dev_err(&dev->dev, "pciback device is not connected or owned"=0A 		=
	" by HVM, kill it\n");=0A 		kill_domain_by_device(psdev=
);=0A-		goto release;=0A+		goto end;=0A 	}=0A =0A 	=
if ( !test_bit(_XEN_PCIB_AERHANDLER, =0A@@ -826,12 +826,12 @@ static void =
pciback_error_resume(struct =0A 		dev_err(&dev->dev, =0A 		=
	"guest with no AER driver should have been killed\n");=0A 		=
kill_domain_by_device(psdev);=0A-		goto release;=0A+		=
goto end;=0A 	}=0A 	common_process(psdev, 1, XEN_PCI_OP_aer_resume, =
PCI_ERS_RESULT_RECOVERED);=0A-release:=0A-	pcistub_device_put(psdev);=
=0A end:=0A+	if (psdev)=0A+		pcistub_device_put(psdev);=0A 	=
up_write(&pcistub_sem);=0A 	return;=0A }=0A@@ -988,7 +988,7 @@ static =
int pcistub_reg_add(int domain, i=0A 	struct config_field *field;=0A =0A =
	psdev =3D pcistub_device_find(domain, bus, slot, func);=0A-	if =
(!psdev || !psdev->dev) {=0A+	if (!psdev) {=0A 		err =3D =
-ENODEV;=0A 		goto out;=0A 	}=0A@@ -1012,6 +1012,8 @@ static =
int pcistub_reg_add(int domain, i=0A 	if (err)=0A 		kfree(field=
);=0A       out:=0A+	if (psdev)=0A+		pcistub_device_put(psdev);=
=0A 	return err;=0A }=0A =0A@@ -1163,10 +1165,7 @@ static ssize_t =
permissive_add(struct dev=0A 		err =3D -ENODEV;=0A 		=
goto out;=0A 	}=0A-	if (!psdev->dev) {=0A-		err =3D -ENODEV;=0A=
-		goto release;=0A-	}=0A+=0A 	dev_data =3D =
pci_get_drvdata(psdev->dev);=0A 	/* the driver data for a device =
should never be null at this point */=0A 	if (!dev_data) {=0A@@ =
-1219,14 +1218,18 @@ DRIVER_ATTR(permissive, S_IRUSR | S_IWUS=0A int =
pciback_get_owner(struct pci_dev *dev)=0A {=0A 	struct pcistub_device =
*psdev;=0A+	int rc;=0A =0A 	psdev =3D pcistub_device_find(pci_domain_nr=
(dev->bus), dev->bus->number,=0A 			PCI_SLOT(dev->devfn=
), PCI_FUNC(dev->devfn));=0A =0A-	if (!psdev || !psdev->pdev)=0A-		=
return -1;=0A+	if (!psdev)=0A+		return -ESRCH;=0A+=0A+	rc =3D =
psdev->pdev ? psdev->pdev->xdev->otherend_id : -EINVAL;=0A =0A-	return =
psdev->pdev->xdev->otherend_id;=0A+	pcistub_device_put(psdev);=0A+	=
return rc;=0A }=0A #endif=0A =0A
--=__PartF6C7CB2C.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

--=__PartF6C7CB2C.0__=--


From xen-devel-bounces@lists.xen.org Mon Sep 24 15:54:50 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Sep 2012 15:54:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGAzb-0007TT-AH; Mon, 24 Sep 2012 15:54: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 1TGAzZ-0007TD-Up
	for xen-devel@lists.xen.org; Mon, 24 Sep 2012 15:54:42 +0000
Received: from [85.158.143.99:57842] by server-3.bemta-4.messagelabs.com id
	28/73-10986-14280605; Mon, 24 Sep 2012 15:54:41 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1348502080!31241028!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7922 invoked from network); 24 Sep 2012 15:54:40 -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;
	24 Sep 2012 15:54:40 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 24 Sep 2012 16:54:42 +0100
Message-Id: <50609E5C020000780009D69D@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 24 Sep 2012 16:54: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="=__PartF6C7CB2C.0__="
Subject: [Xen-devel] [PATCH 2/3] linux-2.6.18/pciback: properly clean up
 after calling pcistub_device_find()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<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.

--=__PartF6C7CB2C.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

As the function calls pcistub_device_get() before returning non-NULL,
its callers need to take care of calling pcistub_device_put() on
(mostly, but not exclusively) error paths.

Otoh, the function already guarantees that the 'dev' member is non-NULL
upon successful return, so callers do not need to check for this a
second time.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/drivers/xen/pciback/pci_stub.c
+++ b/drivers/xen/pciback/pci_stub.c
@@ -642,14 +642,14 @@ static pci_ers_result_t pciback_slot_res
 		dev_err(&dev->dev, "pciback device is not connected or =
owned"
 			" by HVM, kill it\n");
 		kill_domain_by_device(psdev);
-		goto release;
+		goto end;
 	}
=20
 	if ( !test_bit(_XEN_PCIB_AERHANDLER,=20
 		(unsigned long *)&psdev->pdev->sh_info->flags) ) {
 		dev_err(&dev->dev,=20
 			"guest with no AER driver should have been =
killed\n");
-		goto release;
+		goto end;
 	}
 	result =3D common_process(psdev, 1, XEN_PCI_OP_aer_slotreset, =
result);
=20
@@ -659,9 +659,9 @@ static pci_ers_result_t pciback_slot_res
 			"No AER slot_reset service or disconnected!\n");
 		kill_domain_by_device(psdev);
 	}
-release:
-	pcistub_device_put(psdev);
 end:
+	if (psdev)
+		pcistub_device_put(psdev);
 	up_write(&pcistub_sem);
 	return result;
=20
@@ -702,14 +702,14 @@ static pci_ers_result_t pciback_mmio_ena
 		dev_err(&dev->dev, "pciback device is not connected or =
owned"
 			" by HVM, kill it\n");
 		kill_domain_by_device(psdev);
-		goto release;
+		goto end;
 	}
=20
 	if ( !test_bit(_XEN_PCIB_AERHANDLER,=20
 		(unsigned long *)&psdev->pdev->sh_info->flags) ) {
 		dev_err(&dev->dev,=20
 			"guest with no AER driver should have been =
killed\n");
-		goto release;
+		goto end;
 	}
 	result =3D common_process(psdev, 1, XEN_PCI_OP_aer_mmio, result);
=20
@@ -719,9 +719,9 @@ static pci_ers_result_t pciback_mmio_ena
 			"No AER mmio_enabled service or disconnected!\n");
 		kill_domain_by_device(psdev);
 	}
-release:
-	pcistub_device_put(psdev);
 end:
+	if (psdev)
+		pcistub_device_put(psdev);
 	up_write(&pcistub_sem);
 	return result;
 }
@@ -762,7 +762,7 @@ static pci_ers_result_t pciback_error_de
 		dev_err(&dev->dev, "pciback device is not connected or =
owned"
 			" by HVM, kill it\n");
 		kill_domain_by_device(psdev);
-		goto release;
+		goto end;
 	}
=20
 	/*Guest owns the device yet no aer handler regiested, kill guest*/
@@ -770,7 +770,7 @@ static pci_ers_result_t pciback_error_de
 		(unsigned long *)&psdev->pdev->sh_info->flags) ) {
 		dev_dbg(&dev->dev, "guest may have no aer driver, kill =
it\n");
 		kill_domain_by_device(psdev);
-		goto release;
+		goto end;
 	}
 	result =3D common_process(psdev, error, XEN_PCI_OP_aer_detected, =
result);
=20
@@ -780,9 +780,9 @@ static pci_ers_result_t pciback_error_de
 			"No AER error_detected service or disconnected!\n")=
;
 		kill_domain_by_device(psdev);
 	}
-release:
-	pcistub_device_put(psdev);
 end:
+	if (psdev)
+		pcistub_device_put(psdev);
 	up_write(&pcistub_sem);
 	return result;
 }
@@ -818,7 +818,7 @@ static void pciback_error_resume(struct=20
 		dev_err(&dev->dev, "pciback device is not connected or =
owned"
 			" by HVM, kill it\n");
 		kill_domain_by_device(psdev);
-		goto release;
+		goto end;
 	}
=20
 	if ( !test_bit(_XEN_PCIB_AERHANDLER,=20
@@ -826,12 +826,12 @@ static void pciback_error_resume(struct=20
 		dev_err(&dev->dev,=20
 			"guest with no AER driver should have been =
killed\n");
 		kill_domain_by_device(psdev);
-		goto release;
+		goto end;
 	}
 	common_process(psdev, 1, XEN_PCI_OP_aer_resume, PCI_ERS_RESULT_RECO=
VERED);
-release:
-	pcistub_device_put(psdev);
 end:
+	if (psdev)
+		pcistub_device_put(psdev);
 	up_write(&pcistub_sem);
 	return;
 }
@@ -988,7 +988,7 @@ static int pcistub_reg_add(int domain, i
 	struct config_field *field;
=20
 	psdev =3D pcistub_device_find(domain, bus, slot, func);
-	if (!psdev || !psdev->dev) {
+	if (!psdev) {
 		err =3D -ENODEV;
 		goto out;
 	}
@@ -1012,6 +1012,8 @@ static int pcistub_reg_add(int domain, i
 	if (err)
 		kfree(field);
       out:
+	if (psdev)
+		pcistub_device_put(psdev);
 	return err;
 }
=20
@@ -1163,10 +1165,7 @@ static ssize_t permissive_add(struct dev
 		err =3D -ENODEV;
 		goto out;
 	}
-	if (!psdev->dev) {
-		err =3D -ENODEV;
-		goto release;
-	}
+
 	dev_data =3D pci_get_drvdata(psdev->dev);
 	/* the driver data for a device should never be null at this point =
*/
 	if (!dev_data) {
@@ -1219,14 +1218,18 @@ DRIVER_ATTR(permissive, S_IRUSR | S_IWUS
 int pciback_get_owner(struct pci_dev *dev)
 {
 	struct pcistub_device *psdev;
+	int rc;
=20
 	psdev =3D pcistub_device_find(pci_domain_nr(dev->bus), dev->bus->nu=
mber,
 			PCI_SLOT(dev->devfn), PCI_FUNC(dev->devfn));
=20
-	if (!psdev || !psdev->pdev)
-		return -1;
+	if (!psdev)
+		return -ESRCH;
+
+	rc =3D psdev->pdev ? psdev->pdev->xdev->otherend_id : -EINVAL;
=20
-	return psdev->pdev->xdev->otherend_id;
+	pcistub_device_put(psdev);
+	return rc;
 }
 #endif
=20



--=__PartF6C7CB2C.0__=
Content-Type: text/plain; name="xen-pciback-find-error-paths.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="xen-pciback-find-error-paths.patch"

pciback: properly clean up after calling pcistub_device_find()=0A=0AAs the =
function calls pcistub_device_get() before returning non-NULL,=0Aits =
callers need to take care of calling pcistub_device_put() on=0A(mostly, =
but not exclusively) error paths.=0A=0AOtoh, the function already =
guarantees that the 'dev' member is non-NULL=0Aupon successful return, so =
callers do not need to check for this a=0Asecond time.=0A=0ASigned-off-by: =
Jan Beulich <jbeulich@suse.com>=0A=0A--- a/drivers/xen/pciback/pci_stub.c=
=0A+++ b/drivers/xen/pciback/pci_stub.c=0A@@ -642,14 +642,14 @@ static =
pci_ers_result_t pciback_slot_res=0A 		dev_err(&dev->dev, =
"pciback device is not connected or owned"=0A 			" by HVM, =
kill it\n");=0A 		kill_domain_by_device(psdev);=0A-		=
goto release;=0A+		goto end;=0A 	}=0A =0A 	if ( =
!test_bit(_XEN_PCIB_AERHANDLER, =0A 		(unsigned long *)&psdev->pd=
ev->sh_info->flags) ) {=0A 		dev_err(&dev->dev, =0A 			=
"guest with no AER driver should have been killed\n");=0A-		=
goto release;=0A+		goto end;=0A 	}=0A 	result =3D =
common_process(psdev, 1, XEN_PCI_OP_aer_slotreset, result);=0A =0A@@ =
-659,9 +659,9 @@ static pci_ers_result_t pciback_slot_res=0A 			=
"No AER slot_reset service or disconnected!\n");=0A 		kill_domain=
_by_device(psdev);=0A 	}=0A-release:=0A-	pcistub_device_put(psdev);=
=0A end:=0A+	if (psdev)=0A+		pcistub_device_put(psdev);=0A 	=
up_write(&pcistub_sem);=0A 	return result;=0A =0A@@ -702,14 +702,14 @@ =
static pci_ers_result_t pciback_mmio_ena=0A 		dev_err(&dev->dev, =
"pciback device is not connected or owned"=0A 			" by HVM, =
kill it\n");=0A 		kill_domain_by_device(psdev);=0A-		=
goto release;=0A+		goto end;=0A 	}=0A =0A 	if ( =
!test_bit(_XEN_PCIB_AERHANDLER, =0A 		(unsigned long *)&psdev->pd=
ev->sh_info->flags) ) {=0A 		dev_err(&dev->dev, =0A 			=
"guest with no AER driver should have been killed\n");=0A-		=
goto release;=0A+		goto end;=0A 	}=0A 	result =3D =
common_process(psdev, 1, XEN_PCI_OP_aer_mmio, result);=0A =0A@@ -719,9 =
+719,9 @@ static pci_ers_result_t pciback_mmio_ena=0A 			=
"No AER mmio_enabled service or disconnected!\n");=0A 		kill_domain=
_by_device(psdev);=0A 	}=0A-release:=0A-	pcistub_device_put(psdev);=
=0A end:=0A+	if (psdev)=0A+		pcistub_device_put(psdev);=0A 	=
up_write(&pcistub_sem);=0A 	return result;=0A }=0A@@ -762,7 +762,7 @@ =
static pci_ers_result_t pciback_error_de=0A 		dev_err(&dev->dev, =
"pciback device is not connected or owned"=0A 			" by HVM, =
kill it\n");=0A 		kill_domain_by_device(psdev);=0A-		=
goto release;=0A+		goto end;=0A 	}=0A =0A 	/*Guest =
owns the device yet no aer handler regiested, kill guest*/=0A@@ -770,7 =
+770,7 @@ static pci_ers_result_t pciback_error_de=0A 		(unsigned =
long *)&psdev->pdev->sh_info->flags) ) {=0A 		dev_dbg(&dev->dev, =
"guest may have no aer driver, kill it\n");=0A 		kill_domain_by_devi=
ce(psdev);=0A-		goto release;=0A+		goto end;=0A 	=
}=0A 	result =3D common_process(psdev, error, XEN_PCI_OP_aer_detected, =
result);=0A =0A@@ -780,9 +780,9 @@ static pci_ers_result_t pciback_error_de=
=0A 			"No AER error_detected service or disconnected!\n")=
;=0A 		kill_domain_by_device(psdev);=0A 	}=0A-release:=0A-	=
pcistub_device_put(psdev);=0A end:=0A+	if (psdev)=0A+		pcistub_dev=
ice_put(psdev);=0A 	up_write(&pcistub_sem);=0A 	return result;=0A =
}=0A@@ -818,7 +818,7 @@ static void pciback_error_resume(struct =0A 		=
dev_err(&dev->dev, "pciback device is not connected or owned"=0A 		=
	" by HVM, kill it\n");=0A 		kill_domain_by_device(psdev=
);=0A-		goto release;=0A+		goto end;=0A 	}=0A =0A 	=
if ( !test_bit(_XEN_PCIB_AERHANDLER, =0A@@ -826,12 +826,12 @@ static void =
pciback_error_resume(struct =0A 		dev_err(&dev->dev, =0A 		=
	"guest with no AER driver should have been killed\n");=0A 		=
kill_domain_by_device(psdev);=0A-		goto release;=0A+		=
goto end;=0A 	}=0A 	common_process(psdev, 1, XEN_PCI_OP_aer_resume, =
PCI_ERS_RESULT_RECOVERED);=0A-release:=0A-	pcistub_device_put(psdev);=
=0A end:=0A+	if (psdev)=0A+		pcistub_device_put(psdev);=0A 	=
up_write(&pcistub_sem);=0A 	return;=0A }=0A@@ -988,7 +988,7 @@ static =
int pcistub_reg_add(int domain, i=0A 	struct config_field *field;=0A =0A =
	psdev =3D pcistub_device_find(domain, bus, slot, func);=0A-	if =
(!psdev || !psdev->dev) {=0A+	if (!psdev) {=0A 		err =3D =
-ENODEV;=0A 		goto out;=0A 	}=0A@@ -1012,6 +1012,8 @@ static =
int pcistub_reg_add(int domain, i=0A 	if (err)=0A 		kfree(field=
);=0A       out:=0A+	if (psdev)=0A+		pcistub_device_put(psdev);=
=0A 	return err;=0A }=0A =0A@@ -1163,10 +1165,7 @@ static ssize_t =
permissive_add(struct dev=0A 		err =3D -ENODEV;=0A 		=
goto out;=0A 	}=0A-	if (!psdev->dev) {=0A-		err =3D -ENODEV;=0A=
-		goto release;=0A-	}=0A+=0A 	dev_data =3D =
pci_get_drvdata(psdev->dev);=0A 	/* the driver data for a device =
should never be null at this point */=0A 	if (!dev_data) {=0A@@ =
-1219,14 +1218,18 @@ DRIVER_ATTR(permissive, S_IRUSR | S_IWUS=0A int =
pciback_get_owner(struct pci_dev *dev)=0A {=0A 	struct pcistub_device =
*psdev;=0A+	int rc;=0A =0A 	psdev =3D pcistub_device_find(pci_domain_nr=
(dev->bus), dev->bus->number,=0A 			PCI_SLOT(dev->devfn=
), PCI_FUNC(dev->devfn));=0A =0A-	if (!psdev || !psdev->pdev)=0A-		=
return -1;=0A+	if (!psdev)=0A+		return -ESRCH;=0A+=0A+	rc =3D =
psdev->pdev ? psdev->pdev->xdev->otherend_id : -EINVAL;=0A =0A-	return =
psdev->pdev->xdev->otherend_id;=0A+	pcistub_device_put(psdev);=0A+	=
return rc;=0A }=0A #endif=0A =0A
--=__PartF6C7CB2C.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

--=__PartF6C7CB2C.0__=--


From xen-devel-bounces@lists.xen.org Mon Sep 24 15:55:31 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Sep 2012 15:55: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 1TGB0B-0007Yk-Ow; Mon, 24 Sep 2012 15:55: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 1TGB0A-0007YX-Tm
	for xen-devel@lists.xen.org; Mon, 24 Sep 2012 15:55:19 +0000
Received: from [85.158.143.99:50774] by server-2.bemta-4.messagelabs.com id
	2C/4F-06610-66280605; Mon, 24 Sep 2012 15:55:18 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1348502112!31610590!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13551 invoked from network); 24 Sep 2012 15:55:16 -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;
	24 Sep 2012 15:55:16 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 24 Sep 2012 16:55:14 +0100
Message-Id: <50609E7D020000780009D6A1@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 24 Sep 2012 16:55:09 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part97A6AA4D.0__="
Subject: [Xen-devel] [PATCH 3/3] linux-2.6.18/pciback: improve input
	validation
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<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.

--=__Part97A6AA4D.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Reject - where this is not already being done elsewhere - out of range
values originating from user mode. This goes as far as reasonably
possible considering the non-conformance of the in-kernel sscanf().

At the same time, relax quirk parsing so that 0x prefixes get tolerated
without unnecessarily limiting the range of values (in some cases using
the prefix would make parsing outright fail no matter what value was
intended to be specified) for the (future) case where the in-kernel
sscanf() properly honors field width specifications even for integer
conversions.

Plus, to match parsing of standalone PCI device specifications, allow a
second form of input not having a domain specified (implying domain 0).

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/drivers/xen/pciback/pci_stub.c
+++ b/drivers/xen/pciback/pci_stub.c
@@ -121,7 +121,8 @@ static struct pcistub_device *pcistub_de
 		if (psdev->dev !=3D NULL
 		    && domain =3D=3D pci_domain_nr(psdev->dev->bus)
 		    && bus =3D=3D psdev->dev->bus->number
-		    && PCI_DEVFN(slot, func) =3D=3D psdev->dev->devfn) {
+		    && slot =3D=3D PCI_SLOT(psdev->dev->devfn)
+		    && func =3D=3D PCI_FUNC(psdev->dev->devfn)) {
 			pcistub_device_get(psdev);
 			goto out;
 		}
@@ -170,7 +171,8 @@ struct pci_dev *pcistub_get_pci_dev_by_s
 		if (psdev->dev !=3D NULL
 		    && domain =3D=3D pci_domain_nr(psdev->dev->bus)
 		    && bus =3D=3D psdev->dev->bus->number
-		    && PCI_DEVFN(slot, func) =3D=3D psdev->dev->devfn) {
+		    && slot =3D=3D PCI_SLOT(psdev->dev->devfn)
+		    && func =3D=3D PCI_FUNC(psdev->dev->devfn)) {
 			found_dev =3D pcistub_device_get_pci_dev(pdev, =
psdev);
 			break;
 		}
@@ -906,11 +908,18 @@ static inline int str_to_quirk(const cha
 {
 	int err;
=20
-	err =3D
-	    sscanf(buf, " %04x:%02x:%02x.%1x-%08x:%1x:%08x", domain, bus, =
slot,
-		   func, reg, size, mask);
+	err =3D sscanf(buf, " %x:%x:%x.%x-%x:%x:%x", domain, bus, slot, =
func,
+		     reg, size, mask);
 	if (err =3D=3D 7)
 		return 0;
+
+	/* try again without domain */
+	*domain =3D 0;
+	err =3D sscanf(buf, " %x:%x.%x-%x:%x:%x", bus, slot, func, reg, =
size,
+		     mask);
+	if (err =3D=3D 6)
+		return 0;
+
 	return -EINVAL;
 }
=20
@@ -918,7 +927,7 @@ static int pcistub_device_id_add(int dom
 {
 	struct pcistub_device_id *pci_dev_id;
 	unsigned long flags;
-	int rc =3D 0;
+	int rc =3D 0, devfn =3D PCI_DEVFN(slot, func);
=20
 	if (slot < 0) {
 		for (slot =3D 0; !rc && slot < 32; ++slot)
@@ -932,13 +941,23 @@ static int pcistub_device_id_add(int dom
 		return rc;
 	}
=20
+#ifdef CONFIG_PCI_DOMAINS
+	if (domain < 0 || domain > 0xffff
+#else
+	if (domain
+#endif
+	    || bus < 0 || bus > 0xff
+	    || PCI_SLOT(devfn) !=3D slot
+	    || PCI_FUNC(devfn) !=3D func)
+		return -EINVAL;
+
 	pci_dev_id =3D kmalloc(sizeof(*pci_dev_id), GFP_KERNEL);
 	if (!pci_dev_id)
 		return -ENOMEM;
=20
 	pci_dev_id->domain =3D domain;
 	pci_dev_id->bus =3D bus;
-	pci_dev_id->devfn =3D PCI_DEVFN(slot, func);
+	pci_dev_id->devfn =3D devfn;
=20
 	pr_debug("pciback: wants to seize %04x:%02x:%02x.%01x\n",
 		 domain, bus, slot, func);
@@ -979,14 +998,18 @@ static int pcistub_device_id_remove(int=20
 	return err;
 }
=20
-static int pcistub_reg_add(int domain, int bus, int slot, int func, int =
reg,
-			   int size, int mask)
+static int pcistub_reg_add(int domain, int bus, int slot, int func,
+			   unsigned int reg, unsigned int size,
+			   unsigned int mask)
 {
 	int err =3D 0;
 	struct pcistub_device *psdev;
 	struct pci_dev *dev;
 	struct config_field *field;
=20
+	if (reg > 0xfff || (size < 4 && (mask >> (size * 8))))
+		return -EINVAL;
+
 	psdev =3D pcistub_device_find(domain, bus, slot, func);
 	if (!psdev) {
 		err =3D -ENODEV;
@@ -1153,13 +1176,11 @@ static ssize_t permissive_add(struct dev
 	int err;
 	struct pcistub_device *psdev;
 	struct pciback_dev_data *dev_data;
+
 	err =3D str_to_slot(buf, &domain, &bus, &slot, &func);
 	if (err)
 		goto out;
-	if (slot < 0 || func < 0) {
-		err =3D -EINVAL;
-		goto out;
-	}
+
 	psdev =3D pcistub_device_find(domain, bus, slot, func);
 	if (!psdev) {
 		err =3D -ENODEV;



--=__Part97A6AA4D.0__=
Content-Type: text/plain; name="xen-pciback-strict.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="xen-pciback-strict.patch"

pciback: improve input validation=0A=0AReject - where this is not already =
being done elsewhere - out of range=0Avalues originating from user mode. =
This goes as far as reasonably=0Apossible considering the non-conformance =
of the in-kernel sscanf().=0A=0AAt the same time, relax quirk parsing so =
that 0x prefixes get tolerated=0Awithout unnecessarily limiting the range =
of values (in some cases using=0Athe prefix would make parsing outright =
fail no matter what value was=0Aintended to be specified) for the (future) =
case where the in-kernel=0Asscanf() properly honors field width specificati=
ons even for integer=0Aconversions.=0A=0APlus, to match parsing of =
standalone PCI device specifications, allow a=0Asecond form of input not =
having a domain specified (implying domain 0).=0A=0ASigned-off-by: Jan =
Beulich <jbeulich@suse.com>=0A=0A--- a/drivers/xen/pciback/pci_stub.c=0A+++=
 b/drivers/xen/pciback/pci_stub.c=0A@@ -121,7 +121,8 @@ static struct =
pcistub_device *pcistub_de=0A 		if (psdev->dev !=3D NULL=0A 		=
    && domain =3D=3D pci_domain_nr(psdev->dev->bus)=0A 		    && bus =
=3D=3D psdev->dev->bus->number=0A-		    && PCI_DEVFN(slot, =
func) =3D=3D psdev->dev->devfn) {=0A+		    && slot =3D=3D =
PCI_SLOT(psdev->dev->devfn)=0A+		    && func =3D=3D PCI_FUNC(psdev->=
dev->devfn)) {=0A 			pcistub_device_get(psdev);=0A 		=
	goto out;=0A 		}=0A@@ -170,7 +171,8 @@ struct pci_dev =
*pcistub_get_pci_dev_by_s=0A 		if (psdev->dev !=3D NULL=0A 		=
    && domain =3D=3D pci_domain_nr(psdev->dev->bus)=0A 		    && bus =
=3D=3D psdev->dev->bus->number=0A-		    && PCI_DEVFN(slot, =
func) =3D=3D psdev->dev->devfn) {=0A+		    && slot =3D=3D =
PCI_SLOT(psdev->dev->devfn)=0A+		    && func =3D=3D PCI_FUNC(psdev->=
dev->devfn)) {=0A 			found_dev =3D pcistub_device_get_pc=
i_dev(pdev, psdev);=0A 			break;=0A 		}=0A@@ =
-906,11 +908,18 @@ static inline int str_to_quirk(const cha=0A {=0A 	=
int err;=0A =0A-	err =3D=0A-	    sscanf(buf, " %04x:%02x:%02x.%1=
x-%08x:%1x:%08x", domain, bus, slot,=0A-		   func, reg, =
size, mask);=0A+	err =3D sscanf(buf, " %x:%x:%x.%x-%x:%x:%x", =
domain, bus, slot, func,=0A+		     reg, size, mask);=0A 	if =
(err =3D=3D 7)=0A 		return 0;=0A+=0A+	/* try again =
without domain */=0A+	*domain =3D 0;=0A+	err =3D sscanf(buf, " =
%x:%x.%x-%x:%x:%x", bus, slot, func, reg, size,=0A+		     =
mask);=0A+	if (err =3D=3D 6)=0A+		return 0;=0A+=0A 	=
return -EINVAL;=0A }=0A =0A@@ -918,7 +927,7 @@ static int pcistub_device_id=
_add(int dom=0A {=0A 	struct pcistub_device_id *pci_dev_id;=0A 	=
unsigned long flags;=0A-	int rc =3D 0;=0A+	int rc =3D 0, =
devfn =3D PCI_DEVFN(slot, func);=0A =0A 	if (slot < 0) {=0A 		=
for (slot =3D 0; !rc && slot < 32; ++slot)=0A@@ -932,13 +941,23 @@ static =
int pcistub_device_id_add(int dom=0A 		return rc;=0A 	}=0A =
=0A+#ifdef CONFIG_PCI_DOMAINS=0A+	if (domain < 0 || domain > =
0xffff=0A+#else=0A+	if (domain=0A+#endif=0A+	    || bus < 0 || =
bus > 0xff=0A+	    || PCI_SLOT(devfn) !=3D slot=0A+	    || PCI_FUNC(dev=
fn) !=3D func)=0A+		return -EINVAL;=0A+=0A 	pci_dev_id =3D =
kmalloc(sizeof(*pci_dev_id), GFP_KERNEL);=0A 	if (!pci_dev_id)=0A 		=
return -ENOMEM;=0A =0A 	pci_dev_id->domain =3D domain;=0A 	pci_dev_id-=
>bus =3D bus;=0A-	pci_dev_id->devfn =3D PCI_DEVFN(slot, func);=0A+	=
pci_dev_id->devfn =3D devfn;=0A =0A 	pr_debug("pciback: wants to seize =
%04x:%02x:%02x.%01x\n",=0A 		 domain, bus, slot, func);=0A@@ =
-979,14 +998,18 @@ static int pcistub_device_id_remove(int =0A 	return =
err;=0A }=0A =0A-static int pcistub_reg_add(int domain, int bus, int slot, =
int func, int reg,=0A-			   int size, int mask)=0A+static =
int pcistub_reg_add(int domain, int bus, int slot, int func,=0A+		=
	   unsigned int reg, unsigned int size,=0A+			   =
unsigned int mask)=0A {=0A 	int err =3D 0;=0A 	struct pcistub_devi=
ce *psdev;=0A 	struct pci_dev *dev;=0A 	struct config_field =
*field;=0A =0A+	if (reg > 0xfff || (size < 4 && (mask >> (size * 8))))=0A+	=
	return -EINVAL;=0A+=0A 	psdev =3D pcistub_device_find(domain, bus, =
slot, func);=0A 	if (!psdev) {=0A 		err =3D -ENODEV;=0A=
@@ -1153,13 +1176,11 @@ static ssize_t permissive_add(struct dev=0A 	=
int err;=0A 	struct pcistub_device *psdev;=0A 	struct pciback_dev_=
data *dev_data;=0A+=0A 	err =3D str_to_slot(buf, &domain, &bus, &slot, =
&func);=0A 	if (err)=0A 		goto out;=0A-	if (slot < 0 || =
func < 0) {=0A-		err =3D -EINVAL;=0A-		goto out;=0A-	=
}=0A+=0A 	psdev =3D pcistub_device_find(domain, bus, slot, func);=0A =
	if (!psdev) {=0A 		err =3D -ENODEV;=0A
--=__Part97A6AA4D.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

--=__Part97A6AA4D.0__=--


From xen-devel-bounces@lists.xen.org Mon Sep 24 15:55:31 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Sep 2012 15:55: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 1TGB0B-0007Yk-Ow; Mon, 24 Sep 2012 15:55: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 1TGB0A-0007YX-Tm
	for xen-devel@lists.xen.org; Mon, 24 Sep 2012 15:55:19 +0000
Received: from [85.158.143.99:50774] by server-2.bemta-4.messagelabs.com id
	2C/4F-06610-66280605; Mon, 24 Sep 2012 15:55:18 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1348502112!31610590!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13551 invoked from network); 24 Sep 2012 15:55:16 -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;
	24 Sep 2012 15:55:16 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 24 Sep 2012 16:55:14 +0100
Message-Id: <50609E7D020000780009D6A1@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 24 Sep 2012 16:55:09 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part97A6AA4D.0__="
Subject: [Xen-devel] [PATCH 3/3] linux-2.6.18/pciback: improve input
	validation
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<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.

--=__Part97A6AA4D.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Reject - where this is not already being done elsewhere - out of range
values originating from user mode. This goes as far as reasonably
possible considering the non-conformance of the in-kernel sscanf().

At the same time, relax quirk parsing so that 0x prefixes get tolerated
without unnecessarily limiting the range of values (in some cases using
the prefix would make parsing outright fail no matter what value was
intended to be specified) for the (future) case where the in-kernel
sscanf() properly honors field width specifications even for integer
conversions.

Plus, to match parsing of standalone PCI device specifications, allow a
second form of input not having a domain specified (implying domain 0).

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/drivers/xen/pciback/pci_stub.c
+++ b/drivers/xen/pciback/pci_stub.c
@@ -121,7 +121,8 @@ static struct pcistub_device *pcistub_de
 		if (psdev->dev !=3D NULL
 		    && domain =3D=3D pci_domain_nr(psdev->dev->bus)
 		    && bus =3D=3D psdev->dev->bus->number
-		    && PCI_DEVFN(slot, func) =3D=3D psdev->dev->devfn) {
+		    && slot =3D=3D PCI_SLOT(psdev->dev->devfn)
+		    && func =3D=3D PCI_FUNC(psdev->dev->devfn)) {
 			pcistub_device_get(psdev);
 			goto out;
 		}
@@ -170,7 +171,8 @@ struct pci_dev *pcistub_get_pci_dev_by_s
 		if (psdev->dev !=3D NULL
 		    && domain =3D=3D pci_domain_nr(psdev->dev->bus)
 		    && bus =3D=3D psdev->dev->bus->number
-		    && PCI_DEVFN(slot, func) =3D=3D psdev->dev->devfn) {
+		    && slot =3D=3D PCI_SLOT(psdev->dev->devfn)
+		    && func =3D=3D PCI_FUNC(psdev->dev->devfn)) {
 			found_dev =3D pcistub_device_get_pci_dev(pdev, =
psdev);
 			break;
 		}
@@ -906,11 +908,18 @@ static inline int str_to_quirk(const cha
 {
 	int err;
=20
-	err =3D
-	    sscanf(buf, " %04x:%02x:%02x.%1x-%08x:%1x:%08x", domain, bus, =
slot,
-		   func, reg, size, mask);
+	err =3D sscanf(buf, " %x:%x:%x.%x-%x:%x:%x", domain, bus, slot, =
func,
+		     reg, size, mask);
 	if (err =3D=3D 7)
 		return 0;
+
+	/* try again without domain */
+	*domain =3D 0;
+	err =3D sscanf(buf, " %x:%x.%x-%x:%x:%x", bus, slot, func, reg, =
size,
+		     mask);
+	if (err =3D=3D 6)
+		return 0;
+
 	return -EINVAL;
 }
=20
@@ -918,7 +927,7 @@ static int pcistub_device_id_add(int dom
 {
 	struct pcistub_device_id *pci_dev_id;
 	unsigned long flags;
-	int rc =3D 0;
+	int rc =3D 0, devfn =3D PCI_DEVFN(slot, func);
=20
 	if (slot < 0) {
 		for (slot =3D 0; !rc && slot < 32; ++slot)
@@ -932,13 +941,23 @@ static int pcistub_device_id_add(int dom
 		return rc;
 	}
=20
+#ifdef CONFIG_PCI_DOMAINS
+	if (domain < 0 || domain > 0xffff
+#else
+	if (domain
+#endif
+	    || bus < 0 || bus > 0xff
+	    || PCI_SLOT(devfn) !=3D slot
+	    || PCI_FUNC(devfn) !=3D func)
+		return -EINVAL;
+
 	pci_dev_id =3D kmalloc(sizeof(*pci_dev_id), GFP_KERNEL);
 	if (!pci_dev_id)
 		return -ENOMEM;
=20
 	pci_dev_id->domain =3D domain;
 	pci_dev_id->bus =3D bus;
-	pci_dev_id->devfn =3D PCI_DEVFN(slot, func);
+	pci_dev_id->devfn =3D devfn;
=20
 	pr_debug("pciback: wants to seize %04x:%02x:%02x.%01x\n",
 		 domain, bus, slot, func);
@@ -979,14 +998,18 @@ static int pcistub_device_id_remove(int=20
 	return err;
 }
=20
-static int pcistub_reg_add(int domain, int bus, int slot, int func, int =
reg,
-			   int size, int mask)
+static int pcistub_reg_add(int domain, int bus, int slot, int func,
+			   unsigned int reg, unsigned int size,
+			   unsigned int mask)
 {
 	int err =3D 0;
 	struct pcistub_device *psdev;
 	struct pci_dev *dev;
 	struct config_field *field;
=20
+	if (reg > 0xfff || (size < 4 && (mask >> (size * 8))))
+		return -EINVAL;
+
 	psdev =3D pcistub_device_find(domain, bus, slot, func);
 	if (!psdev) {
 		err =3D -ENODEV;
@@ -1153,13 +1176,11 @@ static ssize_t permissive_add(struct dev
 	int err;
 	struct pcistub_device *psdev;
 	struct pciback_dev_data *dev_data;
+
 	err =3D str_to_slot(buf, &domain, &bus, &slot, &func);
 	if (err)
 		goto out;
-	if (slot < 0 || func < 0) {
-		err =3D -EINVAL;
-		goto out;
-	}
+
 	psdev =3D pcistub_device_find(domain, bus, slot, func);
 	if (!psdev) {
 		err =3D -ENODEV;



--=__Part97A6AA4D.0__=
Content-Type: text/plain; name="xen-pciback-strict.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="xen-pciback-strict.patch"

pciback: improve input validation=0A=0AReject - where this is not already =
being done elsewhere - out of range=0Avalues originating from user mode. =
This goes as far as reasonably=0Apossible considering the non-conformance =
of the in-kernel sscanf().=0A=0AAt the same time, relax quirk parsing so =
that 0x prefixes get tolerated=0Awithout unnecessarily limiting the range =
of values (in some cases using=0Athe prefix would make parsing outright =
fail no matter what value was=0Aintended to be specified) for the (future) =
case where the in-kernel=0Asscanf() properly honors field width specificati=
ons even for integer=0Aconversions.=0A=0APlus, to match parsing of =
standalone PCI device specifications, allow a=0Asecond form of input not =
having a domain specified (implying domain 0).=0A=0ASigned-off-by: Jan =
Beulich <jbeulich@suse.com>=0A=0A--- a/drivers/xen/pciback/pci_stub.c=0A+++=
 b/drivers/xen/pciback/pci_stub.c=0A@@ -121,7 +121,8 @@ static struct =
pcistub_device *pcistub_de=0A 		if (psdev->dev !=3D NULL=0A 		=
    && domain =3D=3D pci_domain_nr(psdev->dev->bus)=0A 		    && bus =
=3D=3D psdev->dev->bus->number=0A-		    && PCI_DEVFN(slot, =
func) =3D=3D psdev->dev->devfn) {=0A+		    && slot =3D=3D =
PCI_SLOT(psdev->dev->devfn)=0A+		    && func =3D=3D PCI_FUNC(psdev->=
dev->devfn)) {=0A 			pcistub_device_get(psdev);=0A 		=
	goto out;=0A 		}=0A@@ -170,7 +171,8 @@ struct pci_dev =
*pcistub_get_pci_dev_by_s=0A 		if (psdev->dev !=3D NULL=0A 		=
    && domain =3D=3D pci_domain_nr(psdev->dev->bus)=0A 		    && bus =
=3D=3D psdev->dev->bus->number=0A-		    && PCI_DEVFN(slot, =
func) =3D=3D psdev->dev->devfn) {=0A+		    && slot =3D=3D =
PCI_SLOT(psdev->dev->devfn)=0A+		    && func =3D=3D PCI_FUNC(psdev->=
dev->devfn)) {=0A 			found_dev =3D pcistub_device_get_pc=
i_dev(pdev, psdev);=0A 			break;=0A 		}=0A@@ =
-906,11 +908,18 @@ static inline int str_to_quirk(const cha=0A {=0A 	=
int err;=0A =0A-	err =3D=0A-	    sscanf(buf, " %04x:%02x:%02x.%1=
x-%08x:%1x:%08x", domain, bus, slot,=0A-		   func, reg, =
size, mask);=0A+	err =3D sscanf(buf, " %x:%x:%x.%x-%x:%x:%x", =
domain, bus, slot, func,=0A+		     reg, size, mask);=0A 	if =
(err =3D=3D 7)=0A 		return 0;=0A+=0A+	/* try again =
without domain */=0A+	*domain =3D 0;=0A+	err =3D sscanf(buf, " =
%x:%x.%x-%x:%x:%x", bus, slot, func, reg, size,=0A+		     =
mask);=0A+	if (err =3D=3D 6)=0A+		return 0;=0A+=0A 	=
return -EINVAL;=0A }=0A =0A@@ -918,7 +927,7 @@ static int pcistub_device_id=
_add(int dom=0A {=0A 	struct pcistub_device_id *pci_dev_id;=0A 	=
unsigned long flags;=0A-	int rc =3D 0;=0A+	int rc =3D 0, =
devfn =3D PCI_DEVFN(slot, func);=0A =0A 	if (slot < 0) {=0A 		=
for (slot =3D 0; !rc && slot < 32; ++slot)=0A@@ -932,13 +941,23 @@ static =
int pcistub_device_id_add(int dom=0A 		return rc;=0A 	}=0A =
=0A+#ifdef CONFIG_PCI_DOMAINS=0A+	if (domain < 0 || domain > =
0xffff=0A+#else=0A+	if (domain=0A+#endif=0A+	    || bus < 0 || =
bus > 0xff=0A+	    || PCI_SLOT(devfn) !=3D slot=0A+	    || PCI_FUNC(dev=
fn) !=3D func)=0A+		return -EINVAL;=0A+=0A 	pci_dev_id =3D =
kmalloc(sizeof(*pci_dev_id), GFP_KERNEL);=0A 	if (!pci_dev_id)=0A 		=
return -ENOMEM;=0A =0A 	pci_dev_id->domain =3D domain;=0A 	pci_dev_id-=
>bus =3D bus;=0A-	pci_dev_id->devfn =3D PCI_DEVFN(slot, func);=0A+	=
pci_dev_id->devfn =3D devfn;=0A =0A 	pr_debug("pciback: wants to seize =
%04x:%02x:%02x.%01x\n",=0A 		 domain, bus, slot, func);=0A@@ =
-979,14 +998,18 @@ static int pcistub_device_id_remove(int =0A 	return =
err;=0A }=0A =0A-static int pcistub_reg_add(int domain, int bus, int slot, =
int func, int reg,=0A-			   int size, int mask)=0A+static =
int pcistub_reg_add(int domain, int bus, int slot, int func,=0A+		=
	   unsigned int reg, unsigned int size,=0A+			   =
unsigned int mask)=0A {=0A 	int err =3D 0;=0A 	struct pcistub_devi=
ce *psdev;=0A 	struct pci_dev *dev;=0A 	struct config_field =
*field;=0A =0A+	if (reg > 0xfff || (size < 4 && (mask >> (size * 8))))=0A+	=
	return -EINVAL;=0A+=0A 	psdev =3D pcistub_device_find(domain, bus, =
slot, func);=0A 	if (!psdev) {=0A 		err =3D -ENODEV;=0A=
@@ -1153,13 +1176,11 @@ static ssize_t permissive_add(struct dev=0A 	=
int err;=0A 	struct pcistub_device *psdev;=0A 	struct pciback_dev_=
data *dev_data;=0A+=0A 	err =3D str_to_slot(buf, &domain, &bus, &slot, =
&func);=0A 	if (err)=0A 		goto out;=0A-	if (slot < 0 || =
func < 0) {=0A-		err =3D -EINVAL;=0A-		goto out;=0A-	=
}=0A+=0A 	psdev =3D pcistub_device_find(domain, bus, slot, func);=0A =
	if (!psdev) {=0A 		err =3D -ENODEV;=0A
--=__Part97A6AA4D.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

--=__Part97A6AA4D.0__=--


From xen-devel-bounces@lists.xen.org Mon Sep 24 16:18:22 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Sep 2012 16:18: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 1TGBMB-0008Ub-5c; Mon, 24 Sep 2012 16:18:03 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1TGBMA-0008UW-1L
	for Xen-devel@lists.xensource.com; Mon, 24 Sep 2012 16:18:02 +0000
Received: from [85.158.143.35:42971] by server-3.bemta-4.messagelabs.com id
	ED/B3-10986-9B780605; Mon, 24 Sep 2012 16:18:01 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1348503479!19665850!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzU5Njc1\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18692 invoked from network); 24 Sep 2012 16:18:00 -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; 24 Sep 2012 16:18:00 -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 q8OGHr9U015493
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 24 Sep 2012 16:17:54 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
	q8OGHrca026644
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 24 Sep 2012 16:17:53 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
	q8OGHqLQ021400; Mon, 24 Sep 2012 11:17:53 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 24 Sep 2012 09:17:52 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id E19A44031C; Mon, 24 Sep 2012 12:06:40 -0400 (EDT)
Date: Mon, 24 Sep 2012 12:06:40 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20120924160640.GA21156@phenom.dumpdata.com>
References: <20120921121202.3163c379@mantra.us.oracle.com>
	<alpine.DEB.2.02.1209241613160.29232@kaball.uk.xensource.com>
	<20120924152951.GA1458@phenom.dumpdata.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120924152951.GA1458@phenom.dumpdata.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] [PATCH v1 0/8]: PVH (PV guest with extensions)u
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Sep 24, 2012 at 11:29:51AM -0400, Konrad Rzeszutek Wilk wrote:
> On Mon, Sep 24, 2012 at 04:16:29PM +0100, Stefano Stabellini wrote:
> > On Fri, 21 Sep 2012, Mukesh Rathor wrote:
> > > Hi guys,
> > > 
> > > Ok, I've made all the changes from prev RFC patch submission. Tested
> > > all the combinations. The patches are a bit smaller from before, and
> > > couldn't be separated like before, so I can't state whats different in
> > > each patch. But, it's not too bad to review now.
> > > 
> > > As before, they were built on top of
> > > fc6bdb59a501740b28ed3b616641a22c8dc5dd31 from the following tree:
> > >         
> > > git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
> 
> I took them for a spin over the weekend and stuck them on top of my
> #linux-next - 
> 
> git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git linux-next-pvh
> 
> which worked well as PV guest (dom0, domU, etc). It didn't do too well
> as PVHVM guest, but that might be just that some of the 'if (xen..)'
> are properly not set or I mismerged badly. The later is probably likely as
> I did screw it up at least twice (as you can see from my log).
> 
> Hm, let me give them also a whirl on top of fc6bdb59a501740b28ed3b616641a22c8dc5dd31

And with 3683243b2c551e58082b179fd153c7d43ddc503b applied on top of it
I boots just fine. So I had to mess up the merge somehow.

> 
> > 
> > The patch series is not in a bad state. It is reasonable to aim for a
> > merge in 3.8.
> > At least the xen_remap_domain_mfn_range, ballooning and privcmd changes,
> > which interfaces are going to be shared with Xen on ARM ;-)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 24 16:18:22 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Sep 2012 16:18: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 1TGBMB-0008Ub-5c; Mon, 24 Sep 2012 16:18:03 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1TGBMA-0008UW-1L
	for Xen-devel@lists.xensource.com; Mon, 24 Sep 2012 16:18:02 +0000
Received: from [85.158.143.35:42971] by server-3.bemta-4.messagelabs.com id
	ED/B3-10986-9B780605; Mon, 24 Sep 2012 16:18:01 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1348503479!19665850!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzU5Njc1\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18692 invoked from network); 24 Sep 2012 16:18:00 -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; 24 Sep 2012 16:18:00 -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 q8OGHr9U015493
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 24 Sep 2012 16:17:54 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
	q8OGHrca026644
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 24 Sep 2012 16:17:53 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
	q8OGHqLQ021400; Mon, 24 Sep 2012 11:17:53 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 24 Sep 2012 09:17:52 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id E19A44031C; Mon, 24 Sep 2012 12:06:40 -0400 (EDT)
Date: Mon, 24 Sep 2012 12:06:40 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20120924160640.GA21156@phenom.dumpdata.com>
References: <20120921121202.3163c379@mantra.us.oracle.com>
	<alpine.DEB.2.02.1209241613160.29232@kaball.uk.xensource.com>
	<20120924152951.GA1458@phenom.dumpdata.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120924152951.GA1458@phenom.dumpdata.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] [PATCH v1 0/8]: PVH (PV guest with extensions)u
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Sep 24, 2012 at 11:29:51AM -0400, Konrad Rzeszutek Wilk wrote:
> On Mon, Sep 24, 2012 at 04:16:29PM +0100, Stefano Stabellini wrote:
> > On Fri, 21 Sep 2012, Mukesh Rathor wrote:
> > > Hi guys,
> > > 
> > > Ok, I've made all the changes from prev RFC patch submission. Tested
> > > all the combinations. The patches are a bit smaller from before, and
> > > couldn't be separated like before, so I can't state whats different in
> > > each patch. But, it's not too bad to review now.
> > > 
> > > As before, they were built on top of
> > > fc6bdb59a501740b28ed3b616641a22c8dc5dd31 from the following tree:
> > >         
> > > git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
> 
> I took them for a spin over the weekend and stuck them on top of my
> #linux-next - 
> 
> git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git linux-next-pvh
> 
> which worked well as PV guest (dom0, domU, etc). It didn't do too well
> as PVHVM guest, but that might be just that some of the 'if (xen..)'
> are properly not set or I mismerged badly. The later is probably likely as
> I did screw it up at least twice (as you can see from my log).
> 
> Hm, let me give them also a whirl on top of fc6bdb59a501740b28ed3b616641a22c8dc5dd31

And with 3683243b2c551e58082b179fd153c7d43ddc503b applied on top of it
I boots just fine. So I had to mess up the merge somehow.

> 
> > 
> > The patch series is not in a bad state. It is reasonable to aim for a
> > merge in 3.8.
> > At least the xen_remap_domain_mfn_range, ballooning and privcmd changes,
> > which interfaces are going to be shared with Xen on ARM ;-)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 24 16:35:37 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Sep 2012 16:35:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGBcr-0000Ms-Rz; Mon, 24 Sep 2012 16:35:17 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1TGBcp-0000Mn-WC
	for xen-devel@lists.xen.org; Mon, 24 Sep 2012 16:35:16 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1348504509!11090790!1
X-Originating-IP: [209.85.215.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-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8067 invoked from network); 24 Sep 2012 16:35:09 -0000
Received: from mail-ey0-f173.google.com (HELO mail-ey0-f173.google.com)
	(209.85.215.173)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Sep 2012 16:35:09 -0000
Received: by eaac13 with SMTP id c13so1993973eaa.32
	for <xen-devel@lists.xen.org>; Mon, 24 Sep 2012 09:35:09 -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=IdLBh9Fa62vo9fNMn75+dwQMYI3m4lNHabMfuu+purA=;
	b=AWy6f4PpjM867mV3T11x+gxV10QF5RANKzvAlG37DCLfxQlLALkBptlmaeNzcwGvAr
	T2bqM61MSBjKK09b+v5ZIn+wyWnYBg1HRJQSp+4UAwyfsRDsu0hDx82xkQQqsvfMjkj8
	aEAfNfLZ+1mAmKbJ7WGs4t97xtRetSvpE9kGABL12gPMZ7tHH+6okCG1aAFzesxo67iB
	IROkGegvOY5N22YsrPPsQV7dAKByyYs95/d32qZt1/Z6kcub8C8gtSEtnRJhfmnANzst
	gqbG1vtpYXvcA4EtSkvG+CovszcepwThndmQ4490ZelKUKcLDzIXoM2Sf//qzEkjRR8n
	o+bA==
Received: by 10.14.213.137 with SMTP id a9mr15333609eep.38.1348504509082;
	Mon, 24 Sep 2012 09:35:09 -0700 (PDT)
Received: from [192.168.1.69] (host86-167-82-156.range86-167.btcentralplus.com.
	[86.167.82.156])
	by mx.google.com with ESMTPS id e42sm47527559eem.8.2012.09.24.09.35.07
	(version=SSLv3 cipher=OTHER); Mon, 24 Sep 2012 09:35:08 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Mon, 24 Sep 2012 17:35:05 +0100
From: Keir Fraser <keir.xen@gmail.com>
To: Jan Beulich <JBeulich@suse.com>,
	xen-devel <xen-devel@lists.xen.org>
Message-ID: <CC864A49.3FCF9%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [PATCH] x86/S3: add cache flush on secondary CPUs
	before going to sleep
Thread-Index: Ac2aco06lEiU7cDabkixK/9EkxaCVQ==
In-Reply-To: <506095A0020000780009D67B@nat28.tlf.novell.com>
Mime-version: 1.0
Cc: Ben Guthro <ben@guthro.net>
Subject: Re: [Xen-devel] [PATCH] x86/S3: add cache flush on secondary CPUs
 before going to sleep
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/09/2012 16:17, "Jan Beulich" <JBeulich@suse.com> wrote:

> Secondary CPUs, between doing their final memory writes (particularly
> updating cpu_initialized) and getting a subsequent INIT, may not write
> back all modified data. The INIT itself then causes those modifications
> to be lost, so in the cpu_initialized case the CPU would find itself
> already initialized, (intentionally) entering an infinite loop instead
> of actually coming online.
> 
> Signed-off-by: Ben Guthro <ben@guthro.net>
> 
> Make acpi_dead_idle() call default_dead_idle() rather than duplicating
> the logic there.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Add a comment in default_dead_idle() that the wbinvd is needed in case the
cpu is offline for s3 suspend. That may not otherwise be obvious! And it's a
different reason -- or at least there are other reasons why -- wbinvd is
needed in acpi_dead_idle().

Apart from that:

Acked-by: Keir Fraser <keir@xen.org>

> --- a/xen/arch/x86/acpi/cpu_idle.c
> +++ b/xen/arch/x86/acpi/cpu_idle.c
> @@ -659,8 +659,7 @@ void acpi_dead_idle(void)
>      }
>  
>  default_halt:
> -    for ( ; ; )
> -        halt();
> +    default_dead_idle();
>  }
>  
>  int cpuidle_init_cpu(unsigned int cpu)
> --- a/xen/arch/x86/domain.c
> +++ b/xen/arch/x86/domain.c
> @@ -45,6 +45,7 @@
>  #include <asm/desc.h>
>  #include <asm/i387.h>
>  #include <asm/xstate.h>
> +#include <asm/cpuidle.h>
>  #include <asm/mpspec.h>
>  #include <asm/ldt.h>
>  #include <asm/fixmap.h>
> @@ -64,7 +65,6 @@ DEFINE_PER_CPU(struct vcpu *, curr_vcpu)
>  DEFINE_PER_CPU(unsigned long, cr4);
>  
>  static void default_idle(void);
> -static void default_dead_idle(void);
>  void (*pm_idle) (void) __read_mostly = default_idle;
>  void (*dead_idle) (void) __read_mostly = default_dead_idle;
>  
> @@ -82,8 +82,9 @@ static void default_idle(void)
>          local_irq_enable();
>  }
>  
> -static void default_dead_idle(void)
> +void default_dead_idle(void)
>  {
> +    wbinvd();
>      for ( ; ; )
>          halt();
>  }
> --- a/xen/include/asm-x86/cpuidle.h
> +++ b/xen/include/asm-x86/cpuidle.h
> @@ -18,6 +18,7 @@ extern uint64_t (*cpuidle_get_tick)(void
>  
>  int mwait_idle_init(struct notifier_block *);
>  int cpuidle_init_cpu(unsigned int cpu);
> +void default_dead_idle(void);
>  void acpi_dead_idle(void);
>  void trace_exit_reason(u32 *irq_traced);
>  void update_idle_stats(struct acpi_processor_power *,
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Sep 24 16:35:37 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Sep 2012 16:35:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGBcr-0000Ms-Rz; Mon, 24 Sep 2012 16:35:17 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1TGBcp-0000Mn-WC
	for xen-devel@lists.xen.org; Mon, 24 Sep 2012 16:35:16 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1348504509!11090790!1
X-Originating-IP: [209.85.215.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-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8067 invoked from network); 24 Sep 2012 16:35:09 -0000
Received: from mail-ey0-f173.google.com (HELO mail-ey0-f173.google.com)
	(209.85.215.173)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Sep 2012 16:35:09 -0000
Received: by eaac13 with SMTP id c13so1993973eaa.32
	for <xen-devel@lists.xen.org>; Mon, 24 Sep 2012 09:35:09 -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=IdLBh9Fa62vo9fNMn75+dwQMYI3m4lNHabMfuu+purA=;
	b=AWy6f4PpjM867mV3T11x+gxV10QF5RANKzvAlG37DCLfxQlLALkBptlmaeNzcwGvAr
	T2bqM61MSBjKK09b+v5ZIn+wyWnYBg1HRJQSp+4UAwyfsRDsu0hDx82xkQQqsvfMjkj8
	aEAfNfLZ+1mAmKbJ7WGs4t97xtRetSvpE9kGABL12gPMZ7tHH+6okCG1aAFzesxo67iB
	IROkGegvOY5N22YsrPPsQV7dAKByyYs95/d32qZt1/Z6kcub8C8gtSEtnRJhfmnANzst
	gqbG1vtpYXvcA4EtSkvG+CovszcepwThndmQ4490ZelKUKcLDzIXoM2Sf//qzEkjRR8n
	o+bA==
Received: by 10.14.213.137 with SMTP id a9mr15333609eep.38.1348504509082;
	Mon, 24 Sep 2012 09:35:09 -0700 (PDT)
Received: from [192.168.1.69] (host86-167-82-156.range86-167.btcentralplus.com.
	[86.167.82.156])
	by mx.google.com with ESMTPS id e42sm47527559eem.8.2012.09.24.09.35.07
	(version=SSLv3 cipher=OTHER); Mon, 24 Sep 2012 09:35:08 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Mon, 24 Sep 2012 17:35:05 +0100
From: Keir Fraser <keir.xen@gmail.com>
To: Jan Beulich <JBeulich@suse.com>,
	xen-devel <xen-devel@lists.xen.org>
Message-ID: <CC864A49.3FCF9%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [PATCH] x86/S3: add cache flush on secondary CPUs
	before going to sleep
Thread-Index: Ac2aco06lEiU7cDabkixK/9EkxaCVQ==
In-Reply-To: <506095A0020000780009D67B@nat28.tlf.novell.com>
Mime-version: 1.0
Cc: Ben Guthro <ben@guthro.net>
Subject: Re: [Xen-devel] [PATCH] x86/S3: add cache flush on secondary CPUs
 before going to sleep
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/09/2012 16:17, "Jan Beulich" <JBeulich@suse.com> wrote:

> Secondary CPUs, between doing their final memory writes (particularly
> updating cpu_initialized) and getting a subsequent INIT, may not write
> back all modified data. The INIT itself then causes those modifications
> to be lost, so in the cpu_initialized case the CPU would find itself
> already initialized, (intentionally) entering an infinite loop instead
> of actually coming online.
> 
> Signed-off-by: Ben Guthro <ben@guthro.net>
> 
> Make acpi_dead_idle() call default_dead_idle() rather than duplicating
> the logic there.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Add a comment in default_dead_idle() that the wbinvd is needed in case the
cpu is offline for s3 suspend. That may not otherwise be obvious! And it's a
different reason -- or at least there are other reasons why -- wbinvd is
needed in acpi_dead_idle().

Apart from that:

Acked-by: Keir Fraser <keir@xen.org>

> --- a/xen/arch/x86/acpi/cpu_idle.c
> +++ b/xen/arch/x86/acpi/cpu_idle.c
> @@ -659,8 +659,7 @@ void acpi_dead_idle(void)
>      }
>  
>  default_halt:
> -    for ( ; ; )
> -        halt();
> +    default_dead_idle();
>  }
>  
>  int cpuidle_init_cpu(unsigned int cpu)
> --- a/xen/arch/x86/domain.c
> +++ b/xen/arch/x86/domain.c
> @@ -45,6 +45,7 @@
>  #include <asm/desc.h>
>  #include <asm/i387.h>
>  #include <asm/xstate.h>
> +#include <asm/cpuidle.h>
>  #include <asm/mpspec.h>
>  #include <asm/ldt.h>
>  #include <asm/fixmap.h>
> @@ -64,7 +65,6 @@ DEFINE_PER_CPU(struct vcpu *, curr_vcpu)
>  DEFINE_PER_CPU(unsigned long, cr4);
>  
>  static void default_idle(void);
> -static void default_dead_idle(void);
>  void (*pm_idle) (void) __read_mostly = default_idle;
>  void (*dead_idle) (void) __read_mostly = default_dead_idle;
>  
> @@ -82,8 +82,9 @@ static void default_idle(void)
>          local_irq_enable();
>  }
>  
> -static void default_dead_idle(void)
> +void default_dead_idle(void)
>  {
> +    wbinvd();
>      for ( ; ; )
>          halt();
>  }
> --- a/xen/include/asm-x86/cpuidle.h
> +++ b/xen/include/asm-x86/cpuidle.h
> @@ -18,6 +18,7 @@ extern uint64_t (*cpuidle_get_tick)(void
>  
>  int mwait_idle_init(struct notifier_block *);
>  int cpuidle_init_cpu(unsigned int cpu);
> +void default_dead_idle(void);
>  void acpi_dead_idle(void);
>  void trace_exit_reason(u32 *irq_traced);
>  void update_idle_stats(struct acpi_processor_power *,
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Sep 24 16:46:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Sep 2012 16: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 1TGBn2-0000aQ-4t; Mon, 24 Sep 2012 16:45:48 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1TGBn0-0000aJ-Gr
	for xen-devel@lists.xen.org; Mon, 24 Sep 2012 16:45:46 +0000
Received: from [85.158.137.99:33925] by server-10.bemta-3.messagelabs.com id
	CD/34-10411-93E80605; Mon, 24 Sep 2012 16:45:45 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-217.messagelabs.com!1348505145!18962166!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTA4NDk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32290 invoked from network); 24 Sep 2012 16:45:45 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Sep 2012 16:45:45 -0000
X-IronPort-AV: E=Sophos;i="4.80,476,1344211200"; d="scan'208";a="14730601"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Sep 2012 16:45: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.279.1; Mon, 24 Sep 2012 17:45: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
	1TGBma-0004WC-3n; Mon, 24 Sep 2012 16:45:20 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1TGBmZ-0006Wr-Vb;
	Mon, 24 Sep 2012 17:45:19 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20576.36383.707502.561841@mariner.uk.xensource.com>
Date: Mon, 24 Sep 2012 17:45:19 +0100
To: Ian Campbell <ian.campbell@citrix.com>
In-Reply-To: <1348500989-18281-1-git-send-email-ian.campbell@citrix.com>
References: <1348500989-18281-1-git-send-email-ian.campbell@citrix.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] docs: initial documentation for xenstore
	paths
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("[PATCH] docs: initial documentation for xenstore paths"):
> This is based upon my inspection of a system with a single PV domain
> and a single HVM domain running and is therefore very incomplete.

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 24 16:46:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Sep 2012 16: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 1TGBn2-0000aQ-4t; Mon, 24 Sep 2012 16:45:48 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1TGBn0-0000aJ-Gr
	for xen-devel@lists.xen.org; Mon, 24 Sep 2012 16:45:46 +0000
Received: from [85.158.137.99:33925] by server-10.bemta-3.messagelabs.com id
	CD/34-10411-93E80605; Mon, 24 Sep 2012 16:45:45 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-217.messagelabs.com!1348505145!18962166!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTA4NDk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32290 invoked from network); 24 Sep 2012 16:45:45 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Sep 2012 16:45:45 -0000
X-IronPort-AV: E=Sophos;i="4.80,476,1344211200"; d="scan'208";a="14730601"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Sep 2012 16:45: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.279.1; Mon, 24 Sep 2012 17:45: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
	1TGBma-0004WC-3n; Mon, 24 Sep 2012 16:45:20 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1TGBmZ-0006Wr-Vb;
	Mon, 24 Sep 2012 17:45:19 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20576.36383.707502.561841@mariner.uk.xensource.com>
Date: Mon, 24 Sep 2012 17:45:19 +0100
To: Ian Campbell <ian.campbell@citrix.com>
In-Reply-To: <1348500989-18281-1-git-send-email-ian.campbell@citrix.com>
References: <1348500989-18281-1-git-send-email-ian.campbell@citrix.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] docs: initial documentation for xenstore
	paths
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("[PATCH] docs: initial documentation for xenstore paths"):
> This is based upon my inspection of a system with a single PV domain
> and a single HVM domain running and is therefore very incomplete.

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 24 16:49:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Sep 2012 16:49:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGBpw-0000mT-E4; Mon, 24 Sep 2012 16:48: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 1TGBpu-0000mF-EW
	for xen-devel@lists.xen.org; Mon, 24 Sep 2012 16:48:46 +0000
Received: from [85.158.139.211:40118] by server-16.bemta-5.messagelabs.com id
	7D/A8-05998-DEE80605; Mon, 24 Sep 2012 16:48:45 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-206.messagelabs.com!1348505324!15791353!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTA4NDk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32727 invoked from network); 24 Sep 2012 16:48:45 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Sep 2012 16:48:45 -0000
X-IronPort-AV: E=Sophos;i="4.80,476,1344211200"; d="scan'208";a="14730657"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Sep 2012 16:48:44 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Mon, 24 Sep 2012 17:48: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
	1TGBpr-0004X5-TB	for xen-devel@lists.xen.org;
	Mon, 24 Sep 2012 16:48:43 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1TGBpr-0006X9-Pl	for
	xen-devel@lists.xen.org; Mon, 24 Sep 2012 17:48:43 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20576.36587.698928.396214@mariner.uk.xensource.com>
Date: Mon, 24 Sep 2012 17:48:43 +0100
To: xen-devel@lists.xen.org
X-Mailer: VM 7.19 under Emacs 21.4.1
Subject: [Xen-devel] [PATCH] docs: network diagrams for the wiki
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

After informal discussion, I think this is the best (although not
ideal) way to handle these.  I have arranged for
  http://xenbits.xen.org/docs/unstable-staging/
to exist.

After this patch is pushed to xen-unstable staging, it will be
necessary to update the docs generator to run "make -C docs figs" and
install the result.  Another alternative would be for "make -C docs
html" to produce these and put them somewhere.

I intend also to produce a version for the NAT case and perhaps the
isolated guests case.

Ian.

From: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [PATCH] docs: network diagrams for the wiki

We provide two new diagrams
  docs/figs/network-{bridge,basic}.fig
which are converted to pngs by the Makefiles and intended for
consumption by http://wiki.xen.org/wiki/Xen_Networking.

This is perhaps not the ideal location for this source code but we
don't have a better one.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>

---
 .gitignore                   |    1 +
 .hgignore                    |    1 +
 docs/Makefile                |    7 ++-
 docs/figs/network-basic.fig  |   73 ++++++++++++++++++++++++
 docs/figs/network-bridge.fig |  125 ++++++++++++++++++++++++++++++++++++++++++
 5 files changed, 206 insertions(+), 1 deletions(-)

diff --git a/.gitignore b/.gitignore
index 776e4b2..022a7e8 100644
--- a/.gitignore
+++ b/.gitignore
@@ -392,3 +392,4 @@ tools/xenstore/xenstore-watch
 
 docs/txt/misc/*.txt
 docs/txt/man/*.txt
+docs/figs/*.png
diff --git a/.hgignore b/.hgignore
index 141809e..5095722 100644
--- a/.hgignore
+++ b/.hgignore
@@ -45,6 +45,7 @@
 ^docs/interface/interface\.css$
 ^docs/interface/interface\.html$
 ^docs/interface/labels\.pl$
+^docs/figs/.*\.png
 ^docs/man1/
 ^docs/man5/
 ^docs/pdf/.*$
diff --git a/docs/Makefile b/docs/Makefile
index 007a5a9..8806990 100644
--- a/docs/Makefile
+++ b/docs/Makefile
@@ -25,7 +25,7 @@ DOC_TXT         := $(patsubst %.txt,txt/%.txt,$(wildcard misc/*.txt)) \
 all: build
 
 .PHONY: build
-build: html txt man-pages
+build: html txt man-pages figs
 	@if which $(DOT) 1>/dev/null 2>/dev/null ; then              \
 	$(MAKE) -C xen-api build ; else                              \
         echo "Graphviz (dot) not installed; skipping xen-api." ; fi
@@ -40,6 +40,10 @@ html: $(DOC_HTML) html/index.html
 .PHONY: txt
 txt: $(DOC_TXT)
 
+.PHONY: figs
+figs:
+	$(MAKE) -C figs
+
 .PHONY: python-dev-docs
 python-dev-docs:
 	@mkdir -v -p api/tools/python
@@ -68,6 +72,7 @@ man5/%.5: man/%.pod.5 Makefile
 .PHONY: clean
 clean:
 	$(MAKE) -C xen-api clean
+	$(MAKE) -C figs clean
 	rm -rf .word_count *.aux *.dvi *.bbl *.blg *.glo *.idx *~ 
 	rm -rf *.ilg *.log *.ind *.toc *.bak core
 	rm -rf html txt
diff --git a/docs/figs/network-basic.fig b/docs/figs/network-basic.fig
new file mode 100644
index 0000000..b343def
--- /dev/null
+++ b/docs/figs/network-basic.fig
@@ -0,0 +1,73 @@
+#FIG 3.2  Produced by xfig version 3.2.5b
+Landscape
+Center
+Metric
+A4      
+100.00
+Single
+-2
+1200 2
+0 32 #c0c0c0
+6 4275 5160 6105 6315
+2 2 0 2 0 11 50 -1 28 0.000 0 0 7 0 0 5
+	 6090 5175 4290 5175 4290 6075 6090 6075 6090 5175
+2 2 0 2 0 11 50 -1 28 0.000 0 0 7 0 0 5
+	 4965 6075 5865 6075 5865 6300 4965 6300 4965 6075
+2 1 0 2 0 11 50 -1 28 0.000 0 0 7 0 0 4
+	 6090 5400 5865 5400 5865 5625 6090 5625
+-6
+6 7170 5145 9000 6300
+2 2 0 2 0 11 50 -1 28 0.000 0 0 7 0 0 5
+	 7185 5160 8985 5160 8985 6060 7185 6060 7185 5160
+2 2 0 2 0 11 50 -1 28 0.000 0 0 7 0 0 5
+	 8310 6060 7410 6060 7410 6285 8310 6285 8310 6060
+2 1 0 2 0 11 50 -1 28 0.000 0 0 7 0 0 4
+	 7185 5385 7410 5385 7410 5610 7185 5610
+-6
+6 900 4050 9225 4950
+4 0 0 50 -1 0 16 0.0000 4 195 1335 1170 4860 of the world\001
+4 0 0 50 -1 0 16 0.0000 4 240 1815 1080 4590 interface, to rest\001
+4 0 0 50 -1 0 16 0.0000 4 255 1890 990 4320 Physical network\001
+4 0 0 50 -1 0 16 0.0000 4 255 1485 4050 4860 guest's traffic\001
+4 0 0 50 -1 0 16 0.0000 4 195 1305 4050 4590 backend for\001
+4 0 0 50 -1 0 16 0.0000 4 195 1905 3960 4320 Virtual interface:\001
+4 0 0 50 -1 0 16 0.0000 4 195 1290 7515 4860 Xen drivers\001
+4 0 0 50 -1 0 16 0.0000 4 255 1290 7425 4590 provided by\001
+4 0 0 50 -1 0 16 0.0000 4 195 1905 7155 4320 Virtual interface:\001
+-6
+2 2 0 2 0 29 50 -1 20 0.000 0 0 7 0 0 5
+	 660 5160 2460 5160 2460 6060 660 6060 660 5160
+2 2 0 2 0 29 50 -1 20 0.000 0 0 7 0 0 5
+	 1785 6060 885 6060 885 6285 1785 6285 1785 6060
+2 1 0 2 0 29 50 -1 20 0.000 0 0 7 0 0 4
+	 660 5385 885 5385 900 5625 675 5625
+2 1 0 2 0 29 50 -1 -1 0.000 0 0 7 0 0 3
+	 675 6300 675 4950 450 4950
+2 1 0 3 1 29 50 -1 -1 0.000 0 0 7 0 0 2
+	 6075 5490 7200 5490
+2 1 0 3 4 29 50 -1 -1 0.000 0 0 -1 0 0 2
+	 675 5490 0 5490
+2 1 0 3 4 29 50 -1 -1 0.000 0 0 -1 0 0 2
+	 0 2475 0 6525
+2 2 0 1 0 32 100 -1 20 0.000 0 0 7 0 0 5
+	 675 2250 9675 2250 9675 6750 675 6750 675 2250
+2 2 0 1 0 7 70 -1 20 0.000 0 0 7 0 0 5
+	 6300 2925 900 2925 900 6525 6300 6525 6300 2925
+2 2 0 1 0 7 70 -1 20 0.000 0 0 7 0 0 5
+	 6975 6525 9450 6525 9450 2925 6975 2925 6975 6525
+2 2 0 1 7 7 125 -1 20 0.000 0 0 -1 0 0 5
+	 -225 2025 9900 2025 9900 6975 -225 6975 -225 2025
+4 0 0 50 -1 18 20 0.0000 4 240 735 1170 5490 ethN\001
+4 0 0 50 -1 18 20 0.0000 4 240 945 4500 5490 vifA.B\001
+4 0 0 50 -1 16 20 0.0000 4 315 1410 4500 5850 e.g. vif4.0\001
+4 0 0 50 -1 16 20 0.0000 4 315 1260 1125 5850 e.g. eth0\001
+4 0 0 50 -1 0 16 1.5708 4 255 1395 225 5400 physical link\001
+4 0 0 50 -1 18 20 0.0000 4 240 735 7875 5490 ethB\001
+4 0 0 50 -1 16 20 0.0000 4 315 1260 7650 5850 e.g. eth0\001
+4 0 0 50 -1 0 20 0.0000 4 300 1995 1530 3870 typically dom0\001
+4 0 0 50 -1 0 20 0.0000 4 285 3330 990 3420 Backend (driver) domain\001
+4 0 0 50 -1 0 20 0.0000 4 300 1785 7155 3420 guest domain\001
+4 0 0 50 -1 0 20 0.0000 4 300 1410 7155 3810 domU e.g.\001
+4 0 0 50 -1 16 20 0.0000 4 240 810 8550 3825 dom4\001
+4 0 0 50 -1 0 20 0.0000 4 300 1320 900 2700 Computer\001
+4 0 0 50 -1 0 16 1.5708 4 195 1350 6750 6210 virtual   link\001
diff --git a/docs/figs/network-bridge.fig b/docs/figs/network-bridge.fig
new file mode 100644
index 0000000..63c6ac4
--- /dev/null
+++ b/docs/figs/network-bridge.fig
@@ -0,0 +1,125 @@
+#FIG 3.2  Produced by xfig version 3.2.5b
+Landscape
+Center
+Metric
+A4      
+100.00
+Single
+-2
+1200 2
+0 32 #ffc3ff
+0 33 #c0c0c0
+6 -225 3825 2475 8325
+2 2 0 2 0 29 50 -1 20 0.000 0 0 7 0 0 5
+	 660 6735 2460 6735 2460 7635 660 7635 660 6735
+2 2 0 2 0 29 50 -1 20 0.000 0 0 7 0 0 5
+	 1785 7635 885 7635 885 7860 1785 7860 1785 7635
+2 1 0 2 0 29 50 -1 20 0.000 0 0 7 0 0 4
+	 660 6960 885 6960 900 7200 675 7200
+2 1 0 2 0 29 50 -1 -1 0.000 0 0 7 0 0 3
+	 675 7875 675 6525 450 6525
+2 1 0 3 4 29 50 -1 -1 0.000 0 0 -1 0 0 2
+	 675 7065 0 7065
+2 1 0 3 4 29 50 -1 -1 0.000 0 0 -1 0 0 2
+	 0 4050 0 8100
+4 0 0 50 -1 18 20 0.0000 4 240 675 1170 7065 eth0\001
+-6
+6 1936 4020 3149 5850
+2 2 0 2 0 32 50 -1 19 0.000 0 0 7 0 0 5
+	 1951 5835 1951 4035 2898 4035 2898 5835 1951 5835
+2 2 0 2 0 32 50 -1 19 0.000 0 0 7 0 0 5
+	 2898 4710 2898 5610 3134 5610 3134 4710 2898 4710
+2 1 0 2 0 32 50 -1 19 0.000 0 0 7 0 0 4
+	 2187 5835 2187 5610 2424 5610 2424 5835
+-6
+6 4275 5160 6105 6315
+2 2 0 2 0 11 50 -1 28 0.000 0 0 7 0 0 5
+	 6090 5175 4290 5175 4290 6075 6090 6075 6090 5175
+2 2 0 2 0 11 50 -1 28 0.000 0 0 7 0 0 5
+	 4965 6075 5865 6075 5865 6300 4965 6300 4965 6075
+2 1 0 2 0 11 50 -1 28 0.000 0 0 7 0 0 4
+	 6090 5400 5865 5400 5865 5625 6090 5625
+-6
+6 7170 5145 9000 6300
+2 2 0 2 0 11 50 -1 28 0.000 0 0 7 0 0 5
+	 7185 5160 8985 5160 8985 6060 7185 6060 7185 5160
+2 2 0 2 0 11 50 -1 28 0.000 0 0 7 0 0 5
+	 8310 6060 7410 6060 7410 6285 8310 6285 8310 6060
+2 1 0 2 0 11 50 -1 28 0.000 0 0 7 0 0 4
+	 7185 5385 7410 5385 7410 5610 7185 5610
+-6
+6 4275 7815 6105 8970
+2 2 0 2 0 11 50 -1 28 0.000 0 0 7 0 0 5
+	 6090 7830 4290 7830 4290 8730 6090 8730 6090 7830
+2 2 0 2 0 11 50 -1 28 0.000 0 0 7 0 0 5
+	 4965 8730 5865 8730 5865 8955 4965 8955 4965 8730
+2 1 0 2 0 11 50 -1 28 0.000 0 0 7 0 0 4
+	 6090 8055 5865 8055 5865 8280 6090 8280
+-6
+6 7170 7800 9000 8955
+2 2 0 2 0 11 50 -1 28 0.000 0 0 7 0 0 5
+	 7185 7815 8985 7815 8985 8715 7185 8715 7185 7815
+2 2 0 2 0 11 50 -1 28 0.000 0 0 7 0 0 5
+	 8310 8715 7410 8715 7410 8940 8310 8940 8310 8715
+2 1 0 2 0 11 50 -1 28 0.000 0 0 7 0 0 4
+	 7185 8040 7410 8040 7410 8265 7185 8265
+-6
+6 6975 6750 9450 9225
+6 6975 6750 9450 9225
+2 2 0 1 0 7 70 -1 20 0.000 0 0 7 0 0 5
+	 6975 9225 9450 9225 9450 6750 6975 6750 6975 9225
+4 0 0 50 -1 0 20 0.0000 4 270 705 7200 7200 guest\001
+4 0 0 50 -1 16 20 0.0000 4 240 810 8100 7200 dom7\001
+4 0 0 50 -1 16 20 0.0000 4 225 2070 7200 7650 198.51.100.32\001
+-6
+-6
+2 1 0 3 1 29 50 -1 -1 0.000 0 0 -1 0 0 2
+	 4275 5625 3375 5625
+2 1 0 3 1 29 50 -1 -1 0.000 0 0 -1 0 0 2
+	 4275 8325 3375 8325
+2 1 0 3 1 29 50 -1 -1 0.000 0 0 -1 0 0 2
+	 3375 7200 2475 7200
+2 1 0 3 1 29 50 -1 -1 0.000 0 0 -1 0 0 2
+	 3375 9000 3375 5220
+2 1 0 3 1 29 50 -1 -1 0.000 0 0 -1 0 0 3
+	 2250 5850 2250 6300 3375 6300
+2 2 0 1 0 7 70 -1 20 0.000 0 0 7 0 0 5
+	 6300 2925 900 2925 900 9450 6300 9450 6300 2925
+2 2 0 1 0 33 100 -1 20 0.000 0 0 7 0 0 5
+	 675 2250 9675 2250 9675 9675 675 9675 675 2250
+2 2 0 1 7 7 125 -1 20 0.000 0 0 7 0 0 5
+	 -225 9900 9900 9900 9900 2025 -225 2025 -225 9900
+2 1 0 3 1 29 50 -1 -1 0.000 0 0 7 0 0 2
+	 6075 5490 7200 5490
+2 2 0 1 0 7 70 -1 20 0.000 0 0 7 0 0 5
+	 6975 6525 9450 6525 9450 2925 6975 2925 6975 6525
+2 1 0 3 1 29 50 -1 -1 0.000 0 0 7 0 0 2
+	 6075 8145 7200 8145
+2 2 0 1 0 7 70 -1 20 0.000 0 0 7 0 0 5
+	 6975 6525 9450 6525 9450 5580 6975 5580 6975 6525
+2 2 0 1 0 29 50 -1 -1 0.000 0 0 -1 0 0 5
+	 1395 4230 5670 4230 5670 9180 1395 9180 1395 4230
+4 0 0 50 -1 0 16 1.5708 4 255 1395 225 5400 physical link\001
+4 0 0 50 -1 0 20 0.0000 4 300 1320 900 2700 Computer\001
+4 0 0 50 -1 0 20 0.0000 4 285 3330 990 3420 Backend (driver) domain\001
+4 0 0 50 -1 0 16 1.5708 4 195 1515 3690 7560 virtual switch\001
+4 0 0 50 -1 16 20 0.0000 4 225 1890 1440 3960 198.51.100.1\001
+4 0 0 50 -1 18 20 1.5708 4 240 1095 2250 5400 xenbr0\001
+4 0 0 50 -1 0 16 1.5708 4 255 1185 2520 5490 O/S bridge\001
+4 0 0 50 -1 0 16 1.5708 4 195 990 2790 5310 interface\001
+4 0 0 50 -1 0 20 0.0000 4 300 840 4680 4590 bridge\001
+4 0 0 50 -1 0 20 0.0000 4 225 1185 3330 4590 Software\001
+4 0 0 50 -1 0 20 0.0000 4 300 1785 7155 3420 guest domain\001
+4 0 0 50 -1 0 20 0.0000 4 300 1410 7155 3810 domU e.g.\001
+4 0 0 50 -1 16 20 0.0000 4 240 810 8550 3825 dom4\001
+4 0 0 50 -1 18 20 0.0000 4 240 825 4500 5490 vif4.0\001
+4 0 0 50 -1 18 20 0.0000 4 240 675 7875 5490 eth0\001
+4 0 0 50 -1 16 20 0.0000 4 225 2070 7200 4950 198.51.100.27\001
+4 0 0 50 -1 0 16 0.0000 4 255 1080 4500 5850 (netback)\001
+4 0 0 50 -1 0 16 0.0000 4 255 1140 7560 5850 (netfront)\001
+4 0 0 50 -1 0 16 1.5708 4 195 1350 6750 6210 virtual   link\001
+4 0 0 50 -1 0 16 0.0000 4 255 1080 4500 8505 (netback)\001
+4 0 0 50 -1 0 16 0.0000 4 255 1140 7560 8505 (netfront)\001
+4 0 0 50 -1 0 16 1.5708 4 195 1350 6750 8865 virtual   link\001
+4 0 0 50 -1 18 20 0.0000 4 240 825 4500 8190 vif7.0\001
+4 0 0 50 -1 18 20 0.0000 4 240 675 7830 8190 eth0\001
-- 
tg: (0730dd5..) t/xen/docs.wiki-figs (depends on: base)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 24 16:49:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Sep 2012 16:49:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGBpw-0000mT-E4; Mon, 24 Sep 2012 16:48: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 1TGBpu-0000mF-EW
	for xen-devel@lists.xen.org; Mon, 24 Sep 2012 16:48:46 +0000
Received: from [85.158.139.211:40118] by server-16.bemta-5.messagelabs.com id
	7D/A8-05998-DEE80605; Mon, 24 Sep 2012 16:48:45 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-206.messagelabs.com!1348505324!15791353!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTA4NDk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32727 invoked from network); 24 Sep 2012 16:48:45 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Sep 2012 16:48:45 -0000
X-IronPort-AV: E=Sophos;i="4.80,476,1344211200"; d="scan'208";a="14730657"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Sep 2012 16:48:44 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Mon, 24 Sep 2012 17:48: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
	1TGBpr-0004X5-TB	for xen-devel@lists.xen.org;
	Mon, 24 Sep 2012 16:48:43 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1TGBpr-0006X9-Pl	for
	xen-devel@lists.xen.org; Mon, 24 Sep 2012 17:48:43 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20576.36587.698928.396214@mariner.uk.xensource.com>
Date: Mon, 24 Sep 2012 17:48:43 +0100
To: xen-devel@lists.xen.org
X-Mailer: VM 7.19 under Emacs 21.4.1
Subject: [Xen-devel] [PATCH] docs: network diagrams for the wiki
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

After informal discussion, I think this is the best (although not
ideal) way to handle these.  I have arranged for
  http://xenbits.xen.org/docs/unstable-staging/
to exist.

After this patch is pushed to xen-unstable staging, it will be
necessary to update the docs generator to run "make -C docs figs" and
install the result.  Another alternative would be for "make -C docs
html" to produce these and put them somewhere.

I intend also to produce a version for the NAT case and perhaps the
isolated guests case.

Ian.

From: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [PATCH] docs: network diagrams for the wiki

We provide two new diagrams
  docs/figs/network-{bridge,basic}.fig
which are converted to pngs by the Makefiles and intended for
consumption by http://wiki.xen.org/wiki/Xen_Networking.

This is perhaps not the ideal location for this source code but we
don't have a better one.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>

---
 .gitignore                   |    1 +
 .hgignore                    |    1 +
 docs/Makefile                |    7 ++-
 docs/figs/network-basic.fig  |   73 ++++++++++++++++++++++++
 docs/figs/network-bridge.fig |  125 ++++++++++++++++++++++++++++++++++++++++++
 5 files changed, 206 insertions(+), 1 deletions(-)

diff --git a/.gitignore b/.gitignore
index 776e4b2..022a7e8 100644
--- a/.gitignore
+++ b/.gitignore
@@ -392,3 +392,4 @@ tools/xenstore/xenstore-watch
 
 docs/txt/misc/*.txt
 docs/txt/man/*.txt
+docs/figs/*.png
diff --git a/.hgignore b/.hgignore
index 141809e..5095722 100644
--- a/.hgignore
+++ b/.hgignore
@@ -45,6 +45,7 @@
 ^docs/interface/interface\.css$
 ^docs/interface/interface\.html$
 ^docs/interface/labels\.pl$
+^docs/figs/.*\.png
 ^docs/man1/
 ^docs/man5/
 ^docs/pdf/.*$
diff --git a/docs/Makefile b/docs/Makefile
index 007a5a9..8806990 100644
--- a/docs/Makefile
+++ b/docs/Makefile
@@ -25,7 +25,7 @@ DOC_TXT         := $(patsubst %.txt,txt/%.txt,$(wildcard misc/*.txt)) \
 all: build
 
 .PHONY: build
-build: html txt man-pages
+build: html txt man-pages figs
 	@if which $(DOT) 1>/dev/null 2>/dev/null ; then              \
 	$(MAKE) -C xen-api build ; else                              \
         echo "Graphviz (dot) not installed; skipping xen-api." ; fi
@@ -40,6 +40,10 @@ html: $(DOC_HTML) html/index.html
 .PHONY: txt
 txt: $(DOC_TXT)
 
+.PHONY: figs
+figs:
+	$(MAKE) -C figs
+
 .PHONY: python-dev-docs
 python-dev-docs:
 	@mkdir -v -p api/tools/python
@@ -68,6 +72,7 @@ man5/%.5: man/%.pod.5 Makefile
 .PHONY: clean
 clean:
 	$(MAKE) -C xen-api clean
+	$(MAKE) -C figs clean
 	rm -rf .word_count *.aux *.dvi *.bbl *.blg *.glo *.idx *~ 
 	rm -rf *.ilg *.log *.ind *.toc *.bak core
 	rm -rf html txt
diff --git a/docs/figs/network-basic.fig b/docs/figs/network-basic.fig
new file mode 100644
index 0000000..b343def
--- /dev/null
+++ b/docs/figs/network-basic.fig
@@ -0,0 +1,73 @@
+#FIG 3.2  Produced by xfig version 3.2.5b
+Landscape
+Center
+Metric
+A4      
+100.00
+Single
+-2
+1200 2
+0 32 #c0c0c0
+6 4275 5160 6105 6315
+2 2 0 2 0 11 50 -1 28 0.000 0 0 7 0 0 5
+	 6090 5175 4290 5175 4290 6075 6090 6075 6090 5175
+2 2 0 2 0 11 50 -1 28 0.000 0 0 7 0 0 5
+	 4965 6075 5865 6075 5865 6300 4965 6300 4965 6075
+2 1 0 2 0 11 50 -1 28 0.000 0 0 7 0 0 4
+	 6090 5400 5865 5400 5865 5625 6090 5625
+-6
+6 7170 5145 9000 6300
+2 2 0 2 0 11 50 -1 28 0.000 0 0 7 0 0 5
+	 7185 5160 8985 5160 8985 6060 7185 6060 7185 5160
+2 2 0 2 0 11 50 -1 28 0.000 0 0 7 0 0 5
+	 8310 6060 7410 6060 7410 6285 8310 6285 8310 6060
+2 1 0 2 0 11 50 -1 28 0.000 0 0 7 0 0 4
+	 7185 5385 7410 5385 7410 5610 7185 5610
+-6
+6 900 4050 9225 4950
+4 0 0 50 -1 0 16 0.0000 4 195 1335 1170 4860 of the world\001
+4 0 0 50 -1 0 16 0.0000 4 240 1815 1080 4590 interface, to rest\001
+4 0 0 50 -1 0 16 0.0000 4 255 1890 990 4320 Physical network\001
+4 0 0 50 -1 0 16 0.0000 4 255 1485 4050 4860 guest's traffic\001
+4 0 0 50 -1 0 16 0.0000 4 195 1305 4050 4590 backend for\001
+4 0 0 50 -1 0 16 0.0000 4 195 1905 3960 4320 Virtual interface:\001
+4 0 0 50 -1 0 16 0.0000 4 195 1290 7515 4860 Xen drivers\001
+4 0 0 50 -1 0 16 0.0000 4 255 1290 7425 4590 provided by\001
+4 0 0 50 -1 0 16 0.0000 4 195 1905 7155 4320 Virtual interface:\001
+-6
+2 2 0 2 0 29 50 -1 20 0.000 0 0 7 0 0 5
+	 660 5160 2460 5160 2460 6060 660 6060 660 5160
+2 2 0 2 0 29 50 -1 20 0.000 0 0 7 0 0 5
+	 1785 6060 885 6060 885 6285 1785 6285 1785 6060
+2 1 0 2 0 29 50 -1 20 0.000 0 0 7 0 0 4
+	 660 5385 885 5385 900 5625 675 5625
+2 1 0 2 0 29 50 -1 -1 0.000 0 0 7 0 0 3
+	 675 6300 675 4950 450 4950
+2 1 0 3 1 29 50 -1 -1 0.000 0 0 7 0 0 2
+	 6075 5490 7200 5490
+2 1 0 3 4 29 50 -1 -1 0.000 0 0 -1 0 0 2
+	 675 5490 0 5490
+2 1 0 3 4 29 50 -1 -1 0.000 0 0 -1 0 0 2
+	 0 2475 0 6525
+2 2 0 1 0 32 100 -1 20 0.000 0 0 7 0 0 5
+	 675 2250 9675 2250 9675 6750 675 6750 675 2250
+2 2 0 1 0 7 70 -1 20 0.000 0 0 7 0 0 5
+	 6300 2925 900 2925 900 6525 6300 6525 6300 2925
+2 2 0 1 0 7 70 -1 20 0.000 0 0 7 0 0 5
+	 6975 6525 9450 6525 9450 2925 6975 2925 6975 6525
+2 2 0 1 7 7 125 -1 20 0.000 0 0 -1 0 0 5
+	 -225 2025 9900 2025 9900 6975 -225 6975 -225 2025
+4 0 0 50 -1 18 20 0.0000 4 240 735 1170 5490 ethN\001
+4 0 0 50 -1 18 20 0.0000 4 240 945 4500 5490 vifA.B\001
+4 0 0 50 -1 16 20 0.0000 4 315 1410 4500 5850 e.g. vif4.0\001
+4 0 0 50 -1 16 20 0.0000 4 315 1260 1125 5850 e.g. eth0\001
+4 0 0 50 -1 0 16 1.5708 4 255 1395 225 5400 physical link\001
+4 0 0 50 -1 18 20 0.0000 4 240 735 7875 5490 ethB\001
+4 0 0 50 -1 16 20 0.0000 4 315 1260 7650 5850 e.g. eth0\001
+4 0 0 50 -1 0 20 0.0000 4 300 1995 1530 3870 typically dom0\001
+4 0 0 50 -1 0 20 0.0000 4 285 3330 990 3420 Backend (driver) domain\001
+4 0 0 50 -1 0 20 0.0000 4 300 1785 7155 3420 guest domain\001
+4 0 0 50 -1 0 20 0.0000 4 300 1410 7155 3810 domU e.g.\001
+4 0 0 50 -1 16 20 0.0000 4 240 810 8550 3825 dom4\001
+4 0 0 50 -1 0 20 0.0000 4 300 1320 900 2700 Computer\001
+4 0 0 50 -1 0 16 1.5708 4 195 1350 6750 6210 virtual   link\001
diff --git a/docs/figs/network-bridge.fig b/docs/figs/network-bridge.fig
new file mode 100644
index 0000000..63c6ac4
--- /dev/null
+++ b/docs/figs/network-bridge.fig
@@ -0,0 +1,125 @@
+#FIG 3.2  Produced by xfig version 3.2.5b
+Landscape
+Center
+Metric
+A4      
+100.00
+Single
+-2
+1200 2
+0 32 #ffc3ff
+0 33 #c0c0c0
+6 -225 3825 2475 8325
+2 2 0 2 0 29 50 -1 20 0.000 0 0 7 0 0 5
+	 660 6735 2460 6735 2460 7635 660 7635 660 6735
+2 2 0 2 0 29 50 -1 20 0.000 0 0 7 0 0 5
+	 1785 7635 885 7635 885 7860 1785 7860 1785 7635
+2 1 0 2 0 29 50 -1 20 0.000 0 0 7 0 0 4
+	 660 6960 885 6960 900 7200 675 7200
+2 1 0 2 0 29 50 -1 -1 0.000 0 0 7 0 0 3
+	 675 7875 675 6525 450 6525
+2 1 0 3 4 29 50 -1 -1 0.000 0 0 -1 0 0 2
+	 675 7065 0 7065
+2 1 0 3 4 29 50 -1 -1 0.000 0 0 -1 0 0 2
+	 0 4050 0 8100
+4 0 0 50 -1 18 20 0.0000 4 240 675 1170 7065 eth0\001
+-6
+6 1936 4020 3149 5850
+2 2 0 2 0 32 50 -1 19 0.000 0 0 7 0 0 5
+	 1951 5835 1951 4035 2898 4035 2898 5835 1951 5835
+2 2 0 2 0 32 50 -1 19 0.000 0 0 7 0 0 5
+	 2898 4710 2898 5610 3134 5610 3134 4710 2898 4710
+2 1 0 2 0 32 50 -1 19 0.000 0 0 7 0 0 4
+	 2187 5835 2187 5610 2424 5610 2424 5835
+-6
+6 4275 5160 6105 6315
+2 2 0 2 0 11 50 -1 28 0.000 0 0 7 0 0 5
+	 6090 5175 4290 5175 4290 6075 6090 6075 6090 5175
+2 2 0 2 0 11 50 -1 28 0.000 0 0 7 0 0 5
+	 4965 6075 5865 6075 5865 6300 4965 6300 4965 6075
+2 1 0 2 0 11 50 -1 28 0.000 0 0 7 0 0 4
+	 6090 5400 5865 5400 5865 5625 6090 5625
+-6
+6 7170 5145 9000 6300
+2 2 0 2 0 11 50 -1 28 0.000 0 0 7 0 0 5
+	 7185 5160 8985 5160 8985 6060 7185 6060 7185 5160
+2 2 0 2 0 11 50 -1 28 0.000 0 0 7 0 0 5
+	 8310 6060 7410 6060 7410 6285 8310 6285 8310 6060
+2 1 0 2 0 11 50 -1 28 0.000 0 0 7 0 0 4
+	 7185 5385 7410 5385 7410 5610 7185 5610
+-6
+6 4275 7815 6105 8970
+2 2 0 2 0 11 50 -1 28 0.000 0 0 7 0 0 5
+	 6090 7830 4290 7830 4290 8730 6090 8730 6090 7830
+2 2 0 2 0 11 50 -1 28 0.000 0 0 7 0 0 5
+	 4965 8730 5865 8730 5865 8955 4965 8955 4965 8730
+2 1 0 2 0 11 50 -1 28 0.000 0 0 7 0 0 4
+	 6090 8055 5865 8055 5865 8280 6090 8280
+-6
+6 7170 7800 9000 8955
+2 2 0 2 0 11 50 -1 28 0.000 0 0 7 0 0 5
+	 7185 7815 8985 7815 8985 8715 7185 8715 7185 7815
+2 2 0 2 0 11 50 -1 28 0.000 0 0 7 0 0 5
+	 8310 8715 7410 8715 7410 8940 8310 8940 8310 8715
+2 1 0 2 0 11 50 -1 28 0.000 0 0 7 0 0 4
+	 7185 8040 7410 8040 7410 8265 7185 8265
+-6
+6 6975 6750 9450 9225
+6 6975 6750 9450 9225
+2 2 0 1 0 7 70 -1 20 0.000 0 0 7 0 0 5
+	 6975 9225 9450 9225 9450 6750 6975 6750 6975 9225
+4 0 0 50 -1 0 20 0.0000 4 270 705 7200 7200 guest\001
+4 0 0 50 -1 16 20 0.0000 4 240 810 8100 7200 dom7\001
+4 0 0 50 -1 16 20 0.0000 4 225 2070 7200 7650 198.51.100.32\001
+-6
+-6
+2 1 0 3 1 29 50 -1 -1 0.000 0 0 -1 0 0 2
+	 4275 5625 3375 5625
+2 1 0 3 1 29 50 -1 -1 0.000 0 0 -1 0 0 2
+	 4275 8325 3375 8325
+2 1 0 3 1 29 50 -1 -1 0.000 0 0 -1 0 0 2
+	 3375 7200 2475 7200
+2 1 0 3 1 29 50 -1 -1 0.000 0 0 -1 0 0 2
+	 3375 9000 3375 5220
+2 1 0 3 1 29 50 -1 -1 0.000 0 0 -1 0 0 3
+	 2250 5850 2250 6300 3375 6300
+2 2 0 1 0 7 70 -1 20 0.000 0 0 7 0 0 5
+	 6300 2925 900 2925 900 9450 6300 9450 6300 2925
+2 2 0 1 0 33 100 -1 20 0.000 0 0 7 0 0 5
+	 675 2250 9675 2250 9675 9675 675 9675 675 2250
+2 2 0 1 7 7 125 -1 20 0.000 0 0 7 0 0 5
+	 -225 9900 9900 9900 9900 2025 -225 2025 -225 9900
+2 1 0 3 1 29 50 -1 -1 0.000 0 0 7 0 0 2
+	 6075 5490 7200 5490
+2 2 0 1 0 7 70 -1 20 0.000 0 0 7 0 0 5
+	 6975 6525 9450 6525 9450 2925 6975 2925 6975 6525
+2 1 0 3 1 29 50 -1 -1 0.000 0 0 7 0 0 2
+	 6075 8145 7200 8145
+2 2 0 1 0 7 70 -1 20 0.000 0 0 7 0 0 5
+	 6975 6525 9450 6525 9450 5580 6975 5580 6975 6525
+2 2 0 1 0 29 50 -1 -1 0.000 0 0 -1 0 0 5
+	 1395 4230 5670 4230 5670 9180 1395 9180 1395 4230
+4 0 0 50 -1 0 16 1.5708 4 255 1395 225 5400 physical link\001
+4 0 0 50 -1 0 20 0.0000 4 300 1320 900 2700 Computer\001
+4 0 0 50 -1 0 20 0.0000 4 285 3330 990 3420 Backend (driver) domain\001
+4 0 0 50 -1 0 16 1.5708 4 195 1515 3690 7560 virtual switch\001
+4 0 0 50 -1 16 20 0.0000 4 225 1890 1440 3960 198.51.100.1\001
+4 0 0 50 -1 18 20 1.5708 4 240 1095 2250 5400 xenbr0\001
+4 0 0 50 -1 0 16 1.5708 4 255 1185 2520 5490 O/S bridge\001
+4 0 0 50 -1 0 16 1.5708 4 195 990 2790 5310 interface\001
+4 0 0 50 -1 0 20 0.0000 4 300 840 4680 4590 bridge\001
+4 0 0 50 -1 0 20 0.0000 4 225 1185 3330 4590 Software\001
+4 0 0 50 -1 0 20 0.0000 4 300 1785 7155 3420 guest domain\001
+4 0 0 50 -1 0 20 0.0000 4 300 1410 7155 3810 domU e.g.\001
+4 0 0 50 -1 16 20 0.0000 4 240 810 8550 3825 dom4\001
+4 0 0 50 -1 18 20 0.0000 4 240 825 4500 5490 vif4.0\001
+4 0 0 50 -1 18 20 0.0000 4 240 675 7875 5490 eth0\001
+4 0 0 50 -1 16 20 0.0000 4 225 2070 7200 4950 198.51.100.27\001
+4 0 0 50 -1 0 16 0.0000 4 255 1080 4500 5850 (netback)\001
+4 0 0 50 -1 0 16 0.0000 4 255 1140 7560 5850 (netfront)\001
+4 0 0 50 -1 0 16 1.5708 4 195 1350 6750 6210 virtual   link\001
+4 0 0 50 -1 0 16 0.0000 4 255 1080 4500 8505 (netback)\001
+4 0 0 50 -1 0 16 0.0000 4 255 1140 7560 8505 (netfront)\001
+4 0 0 50 -1 0 16 1.5708 4 195 1350 6750 8865 virtual   link\001
+4 0 0 50 -1 18 20 0.0000 4 240 825 4500 8190 vif7.0\001
+4 0 0 50 -1 18 20 0.0000 4 240 675 7830 8190 eth0\001
-- 
tg: (0730dd5..) t/xen/docs.wiki-figs (depends on: base)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 24 17:09:44 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Sep 2012 17: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 1TGC9v-0001Lz-A7; Mon, 24 Sep 2012 17:09:27 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <vivagin@yeah.net>) id 1TGC9u-0001Lr-JK
	for xen-devel@lists.xensource.com; Mon, 24 Sep 2012 17:09:26 +0000
Received: from [85.158.139.211:25010] by server-13.bemta-5.messagelabs.com id
	AA/CA-16359-5C390605; Mon, 24 Sep 2012 17:09:25 +0000
X-Env-Sender: vivagin@yeah.net
X-Msg-Ref: server-10.tower-206.messagelabs.com!1348506564!19748488!1
X-Originating-IP: [216.139.236.26]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 955 invoked from network); 24 Sep 2012 17:09:25 -0000
Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26)
	by server-10.tower-206.messagelabs.com with AES256-SHA encrypted SMTP;
	24 Sep 2012 17:09:25 -0000
Received: from [192.168.236.26] (helo=sam.nabble.com)
	by sam.nabble.com with esmtp (Exim 4.72)
	(envelope-from <vivagin@yeah.net>) id 1TGC9r-00064J-Ln
	for xen-devel@lists.xensource.com; Mon, 24 Sep 2012 10:09:23 -0700
Date: Mon, 24 Sep 2012 10:09:23 -0700 (PDT)
From: Bruce Granger <vivagin@yeah.net>
To: xen-devel@lists.xensource.com
Message-ID: <1348506563655-5711480.post@n5.nabble.com>
MIME-Version: 1.0
Subject: Re: [Xen-devel] How could Xen know a certain GuestOS have already
 shutdown?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

SGkgZXZlcnlvbmUhIFRoaXMgaXMgcHJvYmFibHkgYSBmYW1pbGlhciBwcm9ibGVtLAogYnV0IEkg
aGF2ZW4ndCBmb3VuZCBhbnl0aGluZyBpbiB0aGUgYXJjaGl2ZXMgb3IgZnJvbSBnb29nbGUgeWV0
LiAKSSBhbHNvIHRhbGtlZCB3aXRoIG15IHBhcnRlcm5lcnMgYnV0IHdlIGhhdmVuJ3QgZ290IGEg
c3VyZSBjb25jbHVzaW9uLgpSZWNlbnRseSBJ4oCZbSBjYXJpbmcgYWJvdXQgYSBxdWVzdGlvbiBh
Ym91dCBzaHV0ZG93biBvcGVyYXRpb246IFdoZW4gd2UKc2h1dGRvd24gYSBHdWVzdE9TIGJ5IGdp
dmluZyB0aGUgY29tbWFuZCBpbiBpdHMgdGVybWluYWwsIGhvdyBjYW4gaHlwZXJ2aXNvcgpnZXQg
dG8ga25vdyB0aGF0IHRoaXMgR3Vlc3RPUyBpcyBhYm91dCB0byBzaHV0ZG93biBhbmQgSG93IGNh
biBoeXBlcnZpc29yCmtub3cgdGhhdCBHdWVzdE9TIGhhcyBhbHJlYWR5IGRvbmUgdGhlIHdvcmsg
b2Ygc2h1dGRvd24/IAogCkkndmUgdHJhY2VkIHRoZSBWSVJRX0RPTV9FWEMgd2hpY2ggc2VuZCBm
cm9tIFhlbiB0byBEb20wIGFuZCBwaWNrZWQgdXAgYnkKeGVuc3RvcmVkIHdoaWNoIGZpcmVzIHRo
ZSBAcmVsZWFzZURvbWFpbiB3YXRjaCB3aGVuIGEgR3Vlc3RPUyBzdGFydCB0bwpzaHV0ZG93bi4g
CgpIZXJlLCBJIHN0aWxsIGhhdmUgdHdvIHF1ZXN0aW9ucy4gCkZpcnN0LCBJIGhhdmVuJ3QgZm91
bmQgYW55dGhpbmcgdXNlZnVsIGluIHRoZSBhcmNoaXZlcyBhYm91dCAncmVsZWFzZURvbWFpbgp3
YXRjaCcuV2hhdCBpcyB0aGUgY2FsbGVkICdAcmVsZWFzZURvbWFpbicgPyB3aGF0J3MgdGhlIHVz
ZSBvZiBpdD8gCgpTZWNvbmQsSSB0aGluayB0aGF0IFZJUlFfRE9NX0VYQyBpcyB0aGUgc2lnbmFs
IHVzZWQgZm9yIGNvbW11bmljYXRlIGJldHdlZW4KaHlwZXJ2aXNvciBhbmQgRG9tMC4gSSB0YWxr
ZWQgdGhhdCB3aXRoIG15IHBhcnRlcm5lciwgd2UgdGhpbmsgdGhhdCB3aGVuCnNodXRkb3duIG9j
Y3VycywgR3Vlc3RPUyB3aWxsIGZpcnN0IGdldCBpbiB0b3VjaCB3aXRoIGh5cGVydmlzb3IgLHRo
ZW4gY2F1c2UKdGhlIGNvbW11bmljYXRpb24gYmV0d2VlbiBYZW4gYW5kIERvbTAgYnkgVklSUV9E
T01fRVhDLGlzIHRoYXQgcmlnaHQ/IFdoYXQKd2UgYWxzbyB3YW50IHRvIGtub3cgaXMgd2hlbiBz
aHV0ZG93biBvcGVyYXRpb24gb2NjdXJzIGluIEd1ZXN0T1MsIGhvdwpHdWVzdE9TIGNvbW11bmlj
YXRlIHdpdGggdGhlIGh5cGVydmlzb3IgZmlyc3Q/IElzIHRoZXJlIGFueSBzaWduYWwgb3IKc29t
ZWhvdyBldmVudCBkZWxpdmVyeT8gCkNvdWxkIGFueW9uZSB0ZWxsIG1lIG1vcmUgYWJvdXQgdGhh
dD8gCgpJdCdzIG15IGhvbm9yIHRvIGdldCBhbGwgeW91ciBzdXBwb3J0ISBUaGFua3MgdmVyeSBt
dWNoIQoKCgotLQpWaWV3IHRoaXMgbWVzc2FnZSBpbiBjb250ZXh0OiBodHRwOi8veGVuLjEwNDU3
MTIubjUubmFiYmxlLmNvbS9SZS1YZW4tZGV2ZWwtSG93LWNvdWxkLVhlbi1rbm93LWEtY2VydGFp
bi1HdWVzdE9TLWhhdmUtYWxyZWFkeS1zaHV0ZG93bi10cDU3MTE0ODAuaHRtbApTZW50IGZyb20g
dGhlIFhlbiAtIERldiBtYWlsaW5nIGxpc3QgYXJjaGl2ZSBhdCBOYWJibGUuY29tLgoKX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxp
bmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwOi8vbGlzdHMueGVuLm9yZy94ZW4t
ZGV2ZWwK

From xen-devel-bounces@lists.xen.org Mon Sep 24 17:09:44 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Sep 2012 17: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 1TGC9v-0001Lz-A7; Mon, 24 Sep 2012 17:09:27 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <vivagin@yeah.net>) id 1TGC9u-0001Lr-JK
	for xen-devel@lists.xensource.com; Mon, 24 Sep 2012 17:09:26 +0000
Received: from [85.158.139.211:25010] by server-13.bemta-5.messagelabs.com id
	AA/CA-16359-5C390605; Mon, 24 Sep 2012 17:09:25 +0000
X-Env-Sender: vivagin@yeah.net
X-Msg-Ref: server-10.tower-206.messagelabs.com!1348506564!19748488!1
X-Originating-IP: [216.139.236.26]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 955 invoked from network); 24 Sep 2012 17:09:25 -0000
Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26)
	by server-10.tower-206.messagelabs.com with AES256-SHA encrypted SMTP;
	24 Sep 2012 17:09:25 -0000
Received: from [192.168.236.26] (helo=sam.nabble.com)
	by sam.nabble.com with esmtp (Exim 4.72)
	(envelope-from <vivagin@yeah.net>) id 1TGC9r-00064J-Ln
	for xen-devel@lists.xensource.com; Mon, 24 Sep 2012 10:09:23 -0700
Date: Mon, 24 Sep 2012 10:09:23 -0700 (PDT)
From: Bruce Granger <vivagin@yeah.net>
To: xen-devel@lists.xensource.com
Message-ID: <1348506563655-5711480.post@n5.nabble.com>
MIME-Version: 1.0
Subject: Re: [Xen-devel] How could Xen know a certain GuestOS have already
 shutdown?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

SGkgZXZlcnlvbmUhIFRoaXMgaXMgcHJvYmFibHkgYSBmYW1pbGlhciBwcm9ibGVtLAogYnV0IEkg
aGF2ZW4ndCBmb3VuZCBhbnl0aGluZyBpbiB0aGUgYXJjaGl2ZXMgb3IgZnJvbSBnb29nbGUgeWV0
LiAKSSBhbHNvIHRhbGtlZCB3aXRoIG15IHBhcnRlcm5lcnMgYnV0IHdlIGhhdmVuJ3QgZ290IGEg
c3VyZSBjb25jbHVzaW9uLgpSZWNlbnRseSBJ4oCZbSBjYXJpbmcgYWJvdXQgYSBxdWVzdGlvbiBh
Ym91dCBzaHV0ZG93biBvcGVyYXRpb246IFdoZW4gd2UKc2h1dGRvd24gYSBHdWVzdE9TIGJ5IGdp
dmluZyB0aGUgY29tbWFuZCBpbiBpdHMgdGVybWluYWwsIGhvdyBjYW4gaHlwZXJ2aXNvcgpnZXQg
dG8ga25vdyB0aGF0IHRoaXMgR3Vlc3RPUyBpcyBhYm91dCB0byBzaHV0ZG93biBhbmQgSG93IGNh
biBoeXBlcnZpc29yCmtub3cgdGhhdCBHdWVzdE9TIGhhcyBhbHJlYWR5IGRvbmUgdGhlIHdvcmsg
b2Ygc2h1dGRvd24/IAogCkkndmUgdHJhY2VkIHRoZSBWSVJRX0RPTV9FWEMgd2hpY2ggc2VuZCBm
cm9tIFhlbiB0byBEb20wIGFuZCBwaWNrZWQgdXAgYnkKeGVuc3RvcmVkIHdoaWNoIGZpcmVzIHRo
ZSBAcmVsZWFzZURvbWFpbiB3YXRjaCB3aGVuIGEgR3Vlc3RPUyBzdGFydCB0bwpzaHV0ZG93bi4g
CgpIZXJlLCBJIHN0aWxsIGhhdmUgdHdvIHF1ZXN0aW9ucy4gCkZpcnN0LCBJIGhhdmVuJ3QgZm91
bmQgYW55dGhpbmcgdXNlZnVsIGluIHRoZSBhcmNoaXZlcyBhYm91dCAncmVsZWFzZURvbWFpbgp3
YXRjaCcuV2hhdCBpcyB0aGUgY2FsbGVkICdAcmVsZWFzZURvbWFpbicgPyB3aGF0J3MgdGhlIHVz
ZSBvZiBpdD8gCgpTZWNvbmQsSSB0aGluayB0aGF0IFZJUlFfRE9NX0VYQyBpcyB0aGUgc2lnbmFs
IHVzZWQgZm9yIGNvbW11bmljYXRlIGJldHdlZW4KaHlwZXJ2aXNvciBhbmQgRG9tMC4gSSB0YWxr
ZWQgdGhhdCB3aXRoIG15IHBhcnRlcm5lciwgd2UgdGhpbmsgdGhhdCB3aGVuCnNodXRkb3duIG9j
Y3VycywgR3Vlc3RPUyB3aWxsIGZpcnN0IGdldCBpbiB0b3VjaCB3aXRoIGh5cGVydmlzb3IgLHRo
ZW4gY2F1c2UKdGhlIGNvbW11bmljYXRpb24gYmV0d2VlbiBYZW4gYW5kIERvbTAgYnkgVklSUV9E
T01fRVhDLGlzIHRoYXQgcmlnaHQ/IFdoYXQKd2UgYWxzbyB3YW50IHRvIGtub3cgaXMgd2hlbiBz
aHV0ZG93biBvcGVyYXRpb24gb2NjdXJzIGluIEd1ZXN0T1MsIGhvdwpHdWVzdE9TIGNvbW11bmlj
YXRlIHdpdGggdGhlIGh5cGVydmlzb3IgZmlyc3Q/IElzIHRoZXJlIGFueSBzaWduYWwgb3IKc29t
ZWhvdyBldmVudCBkZWxpdmVyeT8gCkNvdWxkIGFueW9uZSB0ZWxsIG1lIG1vcmUgYWJvdXQgdGhh
dD8gCgpJdCdzIG15IGhvbm9yIHRvIGdldCBhbGwgeW91ciBzdXBwb3J0ISBUaGFua3MgdmVyeSBt
dWNoIQoKCgotLQpWaWV3IHRoaXMgbWVzc2FnZSBpbiBjb250ZXh0OiBodHRwOi8veGVuLjEwNDU3
MTIubjUubmFiYmxlLmNvbS9SZS1YZW4tZGV2ZWwtSG93LWNvdWxkLVhlbi1rbm93LWEtY2VydGFp
bi1HdWVzdE9TLWhhdmUtYWxyZWFkeS1zaHV0ZG93bi10cDU3MTE0ODAuaHRtbApTZW50IGZyb20g
dGhlIFhlbiAtIERldiBtYWlsaW5nIGxpc3QgYXJjaGl2ZSBhdCBOYWJibGUuY29tLgoKX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxp
bmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwOi8vbGlzdHMueGVuLm9yZy94ZW4t
ZGV2ZWwK

From xen-devel-bounces@lists.xen.org Mon Sep 24 17:18:39 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Sep 2012 17:18:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGCIW-0001X9-Ev; Mon, 24 Sep 2012 17:18:20 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1TGCIU-0001X4-M2
	for xen-devel@lists.xen.org; Mon, 24 Sep 2012 17:18:18 +0000
Received: from [85.158.139.211:33682] by server-9.bemta-5.messagelabs.com id
	B0/4E-14846-9D590605; Mon, 24 Sep 2012 17:18:17 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-10.tower-206.messagelabs.com!1348507092!19749697!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNzcwMDM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30577 invoked from network); 24 Sep 2012 17:18:17 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-10.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Sep 2012 17:18:17 -0000
X-IronPort-AV: E=Sophos;i="4.80,476,1344211200"; d="scan'208";a="209163133"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Sep 2012 17:18:12 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1;
	Mon, 24 Sep 2012 13:18:12 -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 1TGCIN-0004T1-PY	for
	xen-devel@lists.xen.org; Mon, 24 Sep 2012 18:18:11 +0100
Message-ID: <506095D3.8090907@citrix.com>
Date: Mon, 24 Sep 2012 18:18:11 +0100
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120912 Thunderbird/15.0.1
MIME-Version: 1.0
To: xen-devel@lists.xen.org
References: <50607CCF.9050904@overnetdata.com>
In-Reply-To: <50607CCF.9050904@overnetdata.com>
X-Enigmail-Version: 1.4.4
Subject: Re: [Xen-devel] First DomU started goes into a busy loop
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


On 24/09/12 16:31, Anthony Wright wrote:
> On a  32 bit Xen 4.20 system with a 3.5.4 kernel around 40% of the time

I assume you mean 4.2.0?

> when the system starts up the first DomU to be started goes into a busy
> loop (always in state r----- which CPU constantly increasing) with no
> console output. If I destroy the DomU and restart it with identical
> settings, it starts correctly. I got the same happening with Xen 4.1
> with a 3.5.3 kernel, but tried upgrading to see if that fixed it, but it
> didn't.
>
> If I connect to the console there's no output, and I can't get find any
> useful information in the logs or xl dmesg. The DomU is running a 3.3.2
> 32 bit linux kernel.
>
> Can you give me any suggestions how I might diagnose what's going on ?

32bit builds of Xen have been removed from 4.3.  As far as I am aware,
there has been no serious effort to maintain them.  I highly suggest
using a 64bit Xen.

~Andrew

>
> thanks,
>
> Anthony
>
>
> _______________________________________________
> 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 Mon Sep 24 17:18:39 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Sep 2012 17:18:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGCIW-0001X9-Ev; Mon, 24 Sep 2012 17:18:20 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1TGCIU-0001X4-M2
	for xen-devel@lists.xen.org; Mon, 24 Sep 2012 17:18:18 +0000
Received: from [85.158.139.211:33682] by server-9.bemta-5.messagelabs.com id
	B0/4E-14846-9D590605; Mon, 24 Sep 2012 17:18:17 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-10.tower-206.messagelabs.com!1348507092!19749697!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNzcwMDM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30577 invoked from network); 24 Sep 2012 17:18:17 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-10.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Sep 2012 17:18:17 -0000
X-IronPort-AV: E=Sophos;i="4.80,476,1344211200"; d="scan'208";a="209163133"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Sep 2012 17:18:12 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1;
	Mon, 24 Sep 2012 13:18:12 -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 1TGCIN-0004T1-PY	for
	xen-devel@lists.xen.org; Mon, 24 Sep 2012 18:18:11 +0100
Message-ID: <506095D3.8090907@citrix.com>
Date: Mon, 24 Sep 2012 18:18:11 +0100
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120912 Thunderbird/15.0.1
MIME-Version: 1.0
To: xen-devel@lists.xen.org
References: <50607CCF.9050904@overnetdata.com>
In-Reply-To: <50607CCF.9050904@overnetdata.com>
X-Enigmail-Version: 1.4.4
Subject: Re: [Xen-devel] First DomU started goes into a busy loop
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


On 24/09/12 16:31, Anthony Wright wrote:
> On a  32 bit Xen 4.20 system with a 3.5.4 kernel around 40% of the time

I assume you mean 4.2.0?

> when the system starts up the first DomU to be started goes into a busy
> loop (always in state r----- which CPU constantly increasing) with no
> console output. If I destroy the DomU and restart it with identical
> settings, it starts correctly. I got the same happening with Xen 4.1
> with a 3.5.3 kernel, but tried upgrading to see if that fixed it, but it
> didn't.
>
> If I connect to the console there's no output, and I can't get find any
> useful information in the logs or xl dmesg. The DomU is running a 3.3.2
> 32 bit linux kernel.
>
> Can you give me any suggestions how I might diagnose what's going on ?

32bit builds of Xen have been removed from 4.3.  As far as I am aware,
there has been no serious effort to maintain them.  I highly suggest
using a 64bit Xen.

~Andrew

>
> thanks,
>
> Anthony
>
>
> _______________________________________________
> 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 Mon Sep 24 18:17:50 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Sep 2012 18:17:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGDDe-00024v-35; Mon, 24 Sep 2012 18:17: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 1TGDDb-00024q-Vm
	for xen-devel@lists.xensource.com; Mon, 24 Sep 2012 18:17:20 +0000
Received: from [85.158.139.211:45111] by server-7.bemta-5.messagelabs.com id
	EC/CD-00431-FA3A0605; Mon, 24 Sep 2012 18:17:19 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-206.messagelabs.com!1348510638!15801580!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTA4NDk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4734 invoked from network); 24 Sep 2012 18:17:18 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Sep 2012 18:17:18 -0000
X-IronPort-AV: E=Sophos;i="4.80,477,1344211200"; d="scan'208";a="14732062"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Sep 2012 18:17: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.279.1; Mon, 24 Sep 2012 19:17: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 1TGDDa-0005hP-1K;
	Mon, 24 Sep 2012 18:17:18 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1TGDDZ-0006eX-Ky;
	Mon, 24 Sep 2012 19:17:17 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-13860-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Mon, 24 Sep 2012 19:17:17 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13860: regressions - trouble:
	blocked/broken/fail/pass
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 13860 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13860/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-win-vcpus1    5 xen-boot                  fail REGR. vs. 13825
 build-amd64-pvops             2 host-install(2)         broken REGR. vs. 13825
 test-amd64-i386-xl-multivcpu  5 xen-boot         fail in 13837 REGR. vs. 13825
 test-amd64-i386-xl-win-vcpus1  5 xen-boot        fail in 13837 REGR. vs. 13825
 test-amd64-i386-qemuu-rhel6hvm-intel  5 xen-boot fail in 13837 REGR. vs. 13825
 test-amd64-i386-xl-win7-amd64  5 xen-boot        fail in 13837 REGR. vs. 13825
 test-amd64-amd64-win          5 xen-boot         fail in 13837 REGR. vs. 13825
 test-amd64-amd64-xl-winxpsp3  5 xen-boot         fail in 13837 REGR. vs. 13825
 test-amd64-i386-pair         8 xen-boot/dst_host fail in 13837 REGR. vs. 13825
 test-amd64-i386-pair         7 xen-boot/src_host fail in 13837 REGR. vs. 13825

Tests which are failing intermittently (not blocking):
 test-amd64-i386-rhel6hvm-intel  5 xen-boot                  fail pass in 13837
 test-amd64-i386-xl-credit2    5 xen-boot                    fail pass in 13837
 test-amd64-i386-xl-multivcpu  3 host-install(3)           broken pass in 13848
 test-amd64-i386-xl-win-vcpus1  3 host-install(3)          broken pass in 13848
 test-amd64-i386-qemuu-rhel6hvm-intel  3 host-install(3)   broken pass in 13859
 test-amd64-i386-pv            3 host-install(3)           broken pass in 13859
 test-amd64-i386-xl            3 host-install(3)           broken pass in 13848
 test-amd64-i386-xl-win7-amd64  3 host-install(3)          broken pass in 13848
 test-amd64-i386-pair          3 host-install/src_host(3)  broken pass in 13848
 test-amd64-amd64-xl-win7-amd64 12 guest-localmigrate/x10 fail in 13837 pass in 13848
 test-amd64-amd64-pv           5 xen-boot           fail in 13848 pass in 13841
 test-amd64-i386-xl-credit2    3 host-install(3)  broken in 13848 pass in 13860
 test-amd64-i386-win-vcpus1    3 host-install(3)  broken in 13848 pass in 13860

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore     fail in 13837 like 13825
 test-amd64-amd64-xl-sedf      3 host-install(3)     broken in 13837 like 13825
 test-amd64-amd64-xl-pcipt-intel  5 xen-boot      fail in 13837 REGR. vs. 13825
 test-amd64-amd64-xl-qemuu-winxpsp3 9 guest-localmigrate fail in 13837 like 13823
 test-amd64-amd64-xl-qemuu-win7-amd64 9 guest-localmigrate fail in 13837 like 13825

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf-pin  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 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-amd64-pv           1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-pcipt-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  1 xen-build-check(1)           blocked n/a
 test-amd64-amd64-win          1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 xen-build-check(1)         blocked n/a
 test-amd64-amd64-xl-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-pair         1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win      13 guest-stop            fail in 13837 never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop          fail in 13848 never pass

version targeted for testing:
 xen                  8f658b463b78
baseline version:
 xen                  d364becfb083

------------------------------------------------------------
People who touched revisions under test:
  Jan Beulich <jbeulich@suse.com>
  Keir Fraser <keir@xen.org>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            broken  
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          blocked 
 test-amd64-i386-xl                                           broken  
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemuu-win7-amd64                         blocked 
 test-amd64-amd64-xl-win7-amd64                               blocked 
 test-amd64-i386-xl-win7-amd64                                broken  
 test-amd64-i386-xl-credit2                                   fail    
 test-amd64-amd64-xl-pcipt-intel                              blocked 
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         broken  
 test-amd64-i386-xl-multivcpu                                 broken  
 test-amd64-amd64-pair                                        blocked 
 test-amd64-i386-pair                                         broken  
 test-amd64-amd64-xl-sedf-pin                                 blocked 
 test-amd64-amd64-pv                                          blocked 
 test-amd64-i386-pv                                           broken  
 test-amd64-amd64-xl-sedf                                     blocked 
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                broken  
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         blocked 
 test-amd64-i386-win                                          fail    
 test-amd64-amd64-xl-win                                      blocked 
 test-amd64-amd64-xl-qemuu-winxpsp3                           blocked 
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-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.

------------------------------------------------------------
changeset:   25938:8f658b463b78
tag:         tip
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Sep 21 17:02:46 2012 +0200
    
    x86: enable VIA CPU support
    
    Newer VIA CPUs have both 64-bit and VMX support. Enable them to be
    recognized for these purposes, at once stripping off any 32-bit CPU
    only bits from the respective CPU support file, and adding 64-bit ones
    found in recent Linux.
    
    This particularly implies untying the VMX == Intel assumption in a few
    places.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   25937:32187301ecc5
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Sep 21 15:20:21 2012 +0200
    
    x86: eliminate code affecting only 64-bit-incapable CPUs
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   25936:c8873f13cec3
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Sep 21 14:25:12 2012 +0200
    
    printk: prefer %#x et at over 0x%x
    
    Performance is not an issue with printk(), so let the function do
    minimally more work and instead save a byte per affected format
    specifier.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   25935:1e6e6b49b4ac
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Sep 21 13:47:18 2012 +0200
    
    x86: introduce MWAIT-based, ACPI-less CPU idle driver
    
    This is a port of Linux'es intel-idle driver serving the same purpose.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   25934:8eab91903e71
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Sep 21 13:45:08 2012 +0200
    
    cpuidle: remove unused latency_ticks member
    
    ... and code used only for initializing it.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   25933:d364becfb083
user:        Jan Beulich <jbeulich@suse.com>
date:        Thu Sep 20 13:31:19 2012 +0200
    
    introduce guest_handle_for_field()
    
    This helper turns a field of a GUEST_HANDLE in a GUEST_HANDLE.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    
    
(qemu changes not included)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 24 18:17:50 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Sep 2012 18:17:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGDDe-00024v-35; Mon, 24 Sep 2012 18:17: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 1TGDDb-00024q-Vm
	for xen-devel@lists.xensource.com; Mon, 24 Sep 2012 18:17:20 +0000
Received: from [85.158.139.211:45111] by server-7.bemta-5.messagelabs.com id
	EC/CD-00431-FA3A0605; Mon, 24 Sep 2012 18:17:19 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-206.messagelabs.com!1348510638!15801580!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTA4NDk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4734 invoked from network); 24 Sep 2012 18:17:18 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Sep 2012 18:17:18 -0000
X-IronPort-AV: E=Sophos;i="4.80,477,1344211200"; d="scan'208";a="14732062"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Sep 2012 18:17: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.279.1; Mon, 24 Sep 2012 19:17: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 1TGDDa-0005hP-1K;
	Mon, 24 Sep 2012 18:17:18 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1TGDDZ-0006eX-Ky;
	Mon, 24 Sep 2012 19:17:17 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-13860-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Mon, 24 Sep 2012 19:17:17 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13860: regressions - trouble:
	blocked/broken/fail/pass
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 13860 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13860/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-win-vcpus1    5 xen-boot                  fail REGR. vs. 13825
 build-amd64-pvops             2 host-install(2)         broken REGR. vs. 13825
 test-amd64-i386-xl-multivcpu  5 xen-boot         fail in 13837 REGR. vs. 13825
 test-amd64-i386-xl-win-vcpus1  5 xen-boot        fail in 13837 REGR. vs. 13825
 test-amd64-i386-qemuu-rhel6hvm-intel  5 xen-boot fail in 13837 REGR. vs. 13825
 test-amd64-i386-xl-win7-amd64  5 xen-boot        fail in 13837 REGR. vs. 13825
 test-amd64-amd64-win          5 xen-boot         fail in 13837 REGR. vs. 13825
 test-amd64-amd64-xl-winxpsp3  5 xen-boot         fail in 13837 REGR. vs. 13825
 test-amd64-i386-pair         8 xen-boot/dst_host fail in 13837 REGR. vs. 13825
 test-amd64-i386-pair         7 xen-boot/src_host fail in 13837 REGR. vs. 13825

Tests which are failing intermittently (not blocking):
 test-amd64-i386-rhel6hvm-intel  5 xen-boot                  fail pass in 13837
 test-amd64-i386-xl-credit2    5 xen-boot                    fail pass in 13837
 test-amd64-i386-xl-multivcpu  3 host-install(3)           broken pass in 13848
 test-amd64-i386-xl-win-vcpus1  3 host-install(3)          broken pass in 13848
 test-amd64-i386-qemuu-rhel6hvm-intel  3 host-install(3)   broken pass in 13859
 test-amd64-i386-pv            3 host-install(3)           broken pass in 13859
 test-amd64-i386-xl            3 host-install(3)           broken pass in 13848
 test-amd64-i386-xl-win7-amd64  3 host-install(3)          broken pass in 13848
 test-amd64-i386-pair          3 host-install/src_host(3)  broken pass in 13848
 test-amd64-amd64-xl-win7-amd64 12 guest-localmigrate/x10 fail in 13837 pass in 13848
 test-amd64-amd64-pv           5 xen-boot           fail in 13848 pass in 13841
 test-amd64-i386-xl-credit2    3 host-install(3)  broken in 13848 pass in 13860
 test-amd64-i386-win-vcpus1    3 host-install(3)  broken in 13848 pass in 13860

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore     fail in 13837 like 13825
 test-amd64-amd64-xl-sedf      3 host-install(3)     broken in 13837 like 13825
 test-amd64-amd64-xl-pcipt-intel  5 xen-boot      fail in 13837 REGR. vs. 13825
 test-amd64-amd64-xl-qemuu-winxpsp3 9 guest-localmigrate fail in 13837 like 13823
 test-amd64-amd64-xl-qemuu-win7-amd64 9 guest-localmigrate fail in 13837 like 13825

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf-pin  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 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-amd64-pv           1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-pcipt-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  1 xen-build-check(1)           blocked n/a
 test-amd64-amd64-win          1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 xen-build-check(1)         blocked n/a
 test-amd64-amd64-xl-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-pair         1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win      13 guest-stop            fail in 13837 never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop          fail in 13848 never pass

version targeted for testing:
 xen                  8f658b463b78
baseline version:
 xen                  d364becfb083

------------------------------------------------------------
People who touched revisions under test:
  Jan Beulich <jbeulich@suse.com>
  Keir Fraser <keir@xen.org>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            broken  
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          blocked 
 test-amd64-i386-xl                                           broken  
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemuu-win7-amd64                         blocked 
 test-amd64-amd64-xl-win7-amd64                               blocked 
 test-amd64-i386-xl-win7-amd64                                broken  
 test-amd64-i386-xl-credit2                                   fail    
 test-amd64-amd64-xl-pcipt-intel                              blocked 
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         broken  
 test-amd64-i386-xl-multivcpu                                 broken  
 test-amd64-amd64-pair                                        blocked 
 test-amd64-i386-pair                                         broken  
 test-amd64-amd64-xl-sedf-pin                                 blocked 
 test-amd64-amd64-pv                                          blocked 
 test-amd64-i386-pv                                           broken  
 test-amd64-amd64-xl-sedf                                     blocked 
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                broken  
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         blocked 
 test-amd64-i386-win                                          fail    
 test-amd64-amd64-xl-win                                      blocked 
 test-amd64-amd64-xl-qemuu-winxpsp3                           blocked 
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-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.

------------------------------------------------------------
changeset:   25938:8f658b463b78
tag:         tip
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Sep 21 17:02:46 2012 +0200
    
    x86: enable VIA CPU support
    
    Newer VIA CPUs have both 64-bit and VMX support. Enable them to be
    recognized for these purposes, at once stripping off any 32-bit CPU
    only bits from the respective CPU support file, and adding 64-bit ones
    found in recent Linux.
    
    This particularly implies untying the VMX == Intel assumption in a few
    places.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   25937:32187301ecc5
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Sep 21 15:20:21 2012 +0200
    
    x86: eliminate code affecting only 64-bit-incapable CPUs
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   25936:c8873f13cec3
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Sep 21 14:25:12 2012 +0200
    
    printk: prefer %#x et at over 0x%x
    
    Performance is not an issue with printk(), so let the function do
    minimally more work and instead save a byte per affected format
    specifier.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   25935:1e6e6b49b4ac
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Sep 21 13:47:18 2012 +0200
    
    x86: introduce MWAIT-based, ACPI-less CPU idle driver
    
    This is a port of Linux'es intel-idle driver serving the same purpose.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   25934:8eab91903e71
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Sep 21 13:45:08 2012 +0200
    
    cpuidle: remove unused latency_ticks member
    
    ... and code used only for initializing it.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   25933:d364becfb083
user:        Jan Beulich <jbeulich@suse.com>
date:        Thu Sep 20 13:31:19 2012 +0200
    
    introduce guest_handle_for_field()
    
    This helper turns a field of a GUEST_HANDLE in a GUEST_HANDLE.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    
    
(qemu changes not included)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 24 18:20:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Sep 2012 18: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 1TGDFn-0002A8-P6; Mon, 24 Sep 2012 18:19:35 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mukesh.rathor@oracle.com>) id 1TGDFm-00029e-SZ
	for Xen-devel@lists.xensource.com; Mon, 24 Sep 2012 18:19:35 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1348510767!4521134!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzU5Njc1\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14033 invoked from network); 24 Sep 2012 18:19:28 -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; 24 Sep 2012 18:19:28 -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 q8OIJLdJ006302
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 24 Sep 2012 18:19:22 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
	q8OIJKka001066
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 24 Sep 2012 18:19:21 GMT
Received: from abhmt107.oracle.com (abhmt107.oracle.com [141.146.116.59])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q8OIJKbv017329; Mon, 24 Sep 2012 13:19:20 -0500
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 24 Sep 2012 11:19:20 -0700
Date: Mon, 24 Sep 2012 11:19:19 -0700
From: Mukesh Rathor <mukesh.rathor@oracle.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20120924111919.79160756@mantra.us.oracle.com>
In-Reply-To: <alpine.DEB.2.02.1209241214280.29232@kaball.uk.xensource.com>
References: <20120921121511.30001c08@mantra.us.oracle.com>
	<alpine.DEB.2.02.1209241214280.29232@kaball.uk.xensource.com>
Organization: Oracle Corporation
X-Mailer: Claws Mail 3.7.6 (GTK+ 2.18.9; x86_64-redhat-linux-gnu)
Mime-Version: 1.0
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: "Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH v1 1/8]: PVH  basic and hader file changes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 24 Sep 2012 12:26:57 +0100
Stefano Stabellini <stefano.stabellini@eu.citrix.com> wrote:

> On Fri, 21 Sep 2012, Mukesh Rathor wrote:
> > ---
> >  arch/x86/include/asm/xen/interface.h |    8 +++++++-
> >  arch/x86/include/asm/xen/page.h      |    3 +++
> >  arch/x86/xen/irq.c                   |    5 ++++-
> >  arch/x86/xen/p2m.c                   |    2 +-
> >  drivers/xen/cpu_hotplug.c            |    4 +++-
> >  drivers/xen/events.c                 |   12 ++++++++----
> >  drivers/xen/xenbus/xenbus_client.c   |    2 +-
> >  drivers/xen/xenbus/xenbus_probe.c    |    6 +++++-
> >  include/xen/interface/memory.h       |   27
> > +++++++++++++++++++++++++++ include/xen/interface/physdev.h
> > |   10 ++++++++++ 10 files changed, 69 insertions(+), 10
> > deletions(-)
> > 
> > diff --git a/arch/x86/include/asm/xen/interface.h
> > b/arch/x86/include/asm/xen/interface.h index cbf0c9d..1d22131 100644
> > --- a/arch/x86/include/asm/xen/interface.h
> > +++ b/arch/x86/include/asm/xen/interface.h
> > @@ -136,7 +136,13 @@ struct vcpu_guest_context {
> >      struct cpu_user_regs user_regs;         /* User-level CPU
> > registers     */ struct trap_info trap_ctxt[256];        /* Virtual
> > IDT                  */ unsigned long ldt_base, ldt_ents;       /*
> > LDT (linear address, # ents) */
> > -    unsigned long gdt_frames[16], gdt_ents; /* GDT (machine
> > frames, # ents) */
> > +    union {
> > +	struct {
> > +		/* PV: GDT (machine frames, # ents).*/
> > +		unsigned long gdt_frames[16], gdt_ents;
> > +	};
> > +	unsigned long gdtaddr, gdtsz;	    /* PVH: GDTR addr
> > and size */
> > +    };
> >      unsigned long kernel_ss, kernel_sp;     /* Virtual TSS (only
> > SS1/SP1)   */ /* NB. User pagetable on x86/64 is placed in
> > ctrlreg[1]. */ unsigned long ctrlreg[8];               /* CR0-CR7
> > (control registers)  */
> 
> I think I'll be fully able to understand what these are for only
> after I read the Xen side patches...

When we are bringup up smp vcpu, we just need to send down gdtaddr and
gdt size for vcpu context. You had suggested doing it during the
code review, remember :). I had originally in xen. Anyways, earlier
I was just using gdt_frames[0] for addr and gdt_ents for size. But Ian
suggested I change it to union.

> 
> 
> >  #include <xen/xenbus.h>
> > +#include <xen/features.h>
> >  
> >  #include <asm/xen/hypervisor.h>
> >  #include <asm/cpu.h>
> > @@ -100,7 +101,8 @@ static int __init setup_vcpu_hotplug_event(void)
> >  	static struct notifier_block xsn_cpu = {
> >  		.notifier_call = setup_cpu_watcher };
> >  
> > -	if (!xen_pv_domain())
> > +	/* PVH TBD/FIXME: future work */
> > +	if (!xen_pv_domain() ||
> > xen_feature(XENFEAT_auto_translated_physmap)) return -ENODEV;
> 
> Didn't we say that a PVH domain is actually a pv guest?
> In that case shouldn't the test
> 
> if (!xen_pv_domain())
> 
> be sufficient?

No, for HVM and PVH, we want to return -ENODEV.


> 
> >  	register_xenstore_notifier(&xsn_cpu);
> > diff --git a/drivers/xen/events.c b/drivers/xen/events.c
> > index 7595581..f656791 100644
> > --- a/drivers/xen/events.c
> > +++ b/drivers/xen/events.c
> > @@ -1755,7 +1755,7 @@ int xen_set_callback_via(uint64_t via)
> >  }
> >  EXPORT_SYMBOL_GPL(xen_set_callback_via);
> >  
> > -#ifdef CONFIG_XEN_PVHVM
> > +
> >  /* Vector callbacks are better than PCI interrupts to receive event
> >   * channel notifications because we can receive vector callbacks
> > on any
> >   * vcpu and we don't need PCI support or APIC interactions. */
> > @@ -1779,9 +1779,6 @@ void xen_callback_vector(void)
> >  			alloc_intr_gate(XEN_HVM_EVTCHN_CALLBACK,
> > xen_hvm_callback_vector); }
> >  }
> > -#else
> > -void xen_callback_vector(void) {}
> > -#endif
> >  
> >  void __init xen_init_IRQ(void)
> >  {
> > @@ -1814,6 +1811,13 @@ void __init xen_init_IRQ(void)
> >  		if (xen_initial_domain())
> >  			pci_xen_initial_domain();
> >  
> > +		if (xen_feature(XENFEAT_hvm_callback_vector)) {
> > +			xen_callback_vector();
> > +			return;
> > +		}
> > +
> > +		/* PVH: TBD/FIXME: debug and fix eio map to work
> > with pvh */ +
> >  		pirq_eoi_map = (void
> > __va(xen_store_mfn<<PAGE_SHIFT);
> > +		else
> > +			xen_store_interface =
> > mfn_to_virt(xen_store_mfn); }
> 
> I think that mfn_to_virt should work for PVH too: mfn_to_virt is:
> 
> (__va(mfn_to_pfn(m) << PAGE_SHIFT))
> 
> and mfn_to_pfn just return mfn when XENFEAT_auto_translated_physmap is
> set

You are right. Testing it out.





_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 24 18:20:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Sep 2012 18: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 1TGDFn-0002A8-P6; Mon, 24 Sep 2012 18:19:35 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mukesh.rathor@oracle.com>) id 1TGDFm-00029e-SZ
	for Xen-devel@lists.xensource.com; Mon, 24 Sep 2012 18:19:35 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1348510767!4521134!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzU5Njc1\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14033 invoked from network); 24 Sep 2012 18:19:28 -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; 24 Sep 2012 18:19:28 -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 q8OIJLdJ006302
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 24 Sep 2012 18:19:22 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
	q8OIJKka001066
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 24 Sep 2012 18:19:21 GMT
Received: from abhmt107.oracle.com (abhmt107.oracle.com [141.146.116.59])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q8OIJKbv017329; Mon, 24 Sep 2012 13:19:20 -0500
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 24 Sep 2012 11:19:20 -0700
Date: Mon, 24 Sep 2012 11:19:19 -0700
From: Mukesh Rathor <mukesh.rathor@oracle.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20120924111919.79160756@mantra.us.oracle.com>
In-Reply-To: <alpine.DEB.2.02.1209241214280.29232@kaball.uk.xensource.com>
References: <20120921121511.30001c08@mantra.us.oracle.com>
	<alpine.DEB.2.02.1209241214280.29232@kaball.uk.xensource.com>
Organization: Oracle Corporation
X-Mailer: Claws Mail 3.7.6 (GTK+ 2.18.9; x86_64-redhat-linux-gnu)
Mime-Version: 1.0
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: "Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH v1 1/8]: PVH  basic and hader file changes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 24 Sep 2012 12:26:57 +0100
Stefano Stabellini <stefano.stabellini@eu.citrix.com> wrote:

> On Fri, 21 Sep 2012, Mukesh Rathor wrote:
> > ---
> >  arch/x86/include/asm/xen/interface.h |    8 +++++++-
> >  arch/x86/include/asm/xen/page.h      |    3 +++
> >  arch/x86/xen/irq.c                   |    5 ++++-
> >  arch/x86/xen/p2m.c                   |    2 +-
> >  drivers/xen/cpu_hotplug.c            |    4 +++-
> >  drivers/xen/events.c                 |   12 ++++++++----
> >  drivers/xen/xenbus/xenbus_client.c   |    2 +-
> >  drivers/xen/xenbus/xenbus_probe.c    |    6 +++++-
> >  include/xen/interface/memory.h       |   27
> > +++++++++++++++++++++++++++ include/xen/interface/physdev.h
> > |   10 ++++++++++ 10 files changed, 69 insertions(+), 10
> > deletions(-)
> > 
> > diff --git a/arch/x86/include/asm/xen/interface.h
> > b/arch/x86/include/asm/xen/interface.h index cbf0c9d..1d22131 100644
> > --- a/arch/x86/include/asm/xen/interface.h
> > +++ b/arch/x86/include/asm/xen/interface.h
> > @@ -136,7 +136,13 @@ struct vcpu_guest_context {
> >      struct cpu_user_regs user_regs;         /* User-level CPU
> > registers     */ struct trap_info trap_ctxt[256];        /* Virtual
> > IDT                  */ unsigned long ldt_base, ldt_ents;       /*
> > LDT (linear address, # ents) */
> > -    unsigned long gdt_frames[16], gdt_ents; /* GDT (machine
> > frames, # ents) */
> > +    union {
> > +	struct {
> > +		/* PV: GDT (machine frames, # ents).*/
> > +		unsigned long gdt_frames[16], gdt_ents;
> > +	};
> > +	unsigned long gdtaddr, gdtsz;	    /* PVH: GDTR addr
> > and size */
> > +    };
> >      unsigned long kernel_ss, kernel_sp;     /* Virtual TSS (only
> > SS1/SP1)   */ /* NB. User pagetable on x86/64 is placed in
> > ctrlreg[1]. */ unsigned long ctrlreg[8];               /* CR0-CR7
> > (control registers)  */
> 
> I think I'll be fully able to understand what these are for only
> after I read the Xen side patches...

When we are bringup up smp vcpu, we just need to send down gdtaddr and
gdt size for vcpu context. You had suggested doing it during the
code review, remember :). I had originally in xen. Anyways, earlier
I was just using gdt_frames[0] for addr and gdt_ents for size. But Ian
suggested I change it to union.

> 
> 
> >  #include <xen/xenbus.h>
> > +#include <xen/features.h>
> >  
> >  #include <asm/xen/hypervisor.h>
> >  #include <asm/cpu.h>
> > @@ -100,7 +101,8 @@ static int __init setup_vcpu_hotplug_event(void)
> >  	static struct notifier_block xsn_cpu = {
> >  		.notifier_call = setup_cpu_watcher };
> >  
> > -	if (!xen_pv_domain())
> > +	/* PVH TBD/FIXME: future work */
> > +	if (!xen_pv_domain() ||
> > xen_feature(XENFEAT_auto_translated_physmap)) return -ENODEV;
> 
> Didn't we say that a PVH domain is actually a pv guest?
> In that case shouldn't the test
> 
> if (!xen_pv_domain())
> 
> be sufficient?

No, for HVM and PVH, we want to return -ENODEV.


> 
> >  	register_xenstore_notifier(&xsn_cpu);
> > diff --git a/drivers/xen/events.c b/drivers/xen/events.c
> > index 7595581..f656791 100644
> > --- a/drivers/xen/events.c
> > +++ b/drivers/xen/events.c
> > @@ -1755,7 +1755,7 @@ int xen_set_callback_via(uint64_t via)
> >  }
> >  EXPORT_SYMBOL_GPL(xen_set_callback_via);
> >  
> > -#ifdef CONFIG_XEN_PVHVM
> > +
> >  /* Vector callbacks are better than PCI interrupts to receive event
> >   * channel notifications because we can receive vector callbacks
> > on any
> >   * vcpu and we don't need PCI support or APIC interactions. */
> > @@ -1779,9 +1779,6 @@ void xen_callback_vector(void)
> >  			alloc_intr_gate(XEN_HVM_EVTCHN_CALLBACK,
> > xen_hvm_callback_vector); }
> >  }
> > -#else
> > -void xen_callback_vector(void) {}
> > -#endif
> >  
> >  void __init xen_init_IRQ(void)
> >  {
> > @@ -1814,6 +1811,13 @@ void __init xen_init_IRQ(void)
> >  		if (xen_initial_domain())
> >  			pci_xen_initial_domain();
> >  
> > +		if (xen_feature(XENFEAT_hvm_callback_vector)) {
> > +			xen_callback_vector();
> > +			return;
> > +		}
> > +
> > +		/* PVH: TBD/FIXME: debug and fix eio map to work
> > with pvh */ +
> >  		pirq_eoi_map = (void
> > __va(xen_store_mfn<<PAGE_SHIFT);
> > +		else
> > +			xen_store_interface =
> > mfn_to_virt(xen_store_mfn); }
> 
> I think that mfn_to_virt should work for PVH too: mfn_to_virt is:
> 
> (__va(mfn_to_pfn(m) << PAGE_SHIFT))
> 
> and mfn_to_pfn just return mfn when XENFEAT_auto_translated_physmap is
> set

You are right. Testing it out.





_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 24 19:02:55 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Sep 2012 19:02:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGDvB-0002aX-Ev; Mon, 24 Sep 2012 19:02:21 +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 1TGDvA-0002aS-8A
	for xen-devel@lists.xen.org; Mon, 24 Sep 2012 19:02:20 +0000
Received: from [85.158.139.211:10017] by server-8.bemta-5.messagelabs.com id
	4F/B4-18073-B3EA0605; Mon, 24 Sep 2012 19:02:19 +0000
X-Env-Sender: ben.guthro@gmail.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1348513337!19330852!1
X-Originating-IP: [209.85.220.173]
X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_20_30,HTML_MESSAGE,
	RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32693 invoked from network); 24 Sep 2012 19:02:18 -0000
Received: from mail-vc0-f173.google.com (HELO mail-vc0-f173.google.com)
	(209.85.220.173)
	by server-7.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Sep 2012 19:02:18 -0000
Received: by vcbfl15 with SMTP id fl15so8102027vcb.32
	for <xen-devel@lists.xen.org>; Mon, 24 Sep 2012 12:02: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;
	bh=ZMTNJzQ47ox6HBbbEvsMsz6bsCgpCBRSysblNxi9/MQ=;
	b=oYaDgZ7yMKgGYzhhzVx9Q4aOnR3gEFbTX57ErHusDq77S74yQ3jTZ0VTgOHkERtG/E
	4QigoUah7yPqYJCvio6uyDZSbeSM4a8Wx7X54KKySb+GXkfM0Om0K0E45q+ZM+XTDQgw
	GFrDy38BzRoCKgAfknyBY4AbGGKmnlFjyv2DCI2feW0hdfoUI7bdjVSdHf1iIxBPHX80
	lTmSbfKlXDnQvwBSOoE7zhUOrPZPmdof2C4TIH5nuAzvWufaXBC5zXmXV++vd/JQqzwp
	rOPjBx13nJ+A8ual5bcaEMK+Q6+mLTZj62yiNZhlGYt5qnACqu8/usXzcsn1lNnPNlZq
	bKpw==
MIME-Version: 1.0
Received: by 10.52.150.84 with SMTP id ug20mr1842669vdb.16.1348513336764; Mon,
	24 Sep 2012 12:02:16 -0700 (PDT)
Received: by 10.58.137.169 with HTTP; Mon, 24 Sep 2012 12:02:16 -0700 (PDT)
In-Reply-To: <50608A32020000780009D639@nat28.tlf.novell.com>
References: <CAOvdn6XKPOMNn6AjuYvZvPXRRJffN3po5GXe1Yh1-m0hisMK_w@mail.gmail.com>
	<CC8273A0.4C9DD%keir@xen.org>
	<50605E9A020000780009D486@nat28.tlf.novell.com>
	<CAOvdn6XmB6rj3_QVU+59V8p24Y5G47AWxVEM=id02JWXkuhibQ@mail.gmail.com>
	<5060640B020000780009D4D2@nat28.tlf.novell.com>
	<CAOvdn6XLy8zR2rb2MEyi2aT9LQiFvFLY_H02p181mTsVLVTZkw@mail.gmail.com>
	<506068A0020000780009D519@nat28.tlf.novell.com>
	<CAOvdn6Undn2srfNhW++wLfUNFQ5JnZ3rp5bg7DD_TDPCHqmP_A@mail.gmail.com>
	<50606F18020000780009D57B@nat28.tlf.novell.com>
	<CAOvdn6UMHmPWqedYE9GQQMDaM4oiHLDSn9ZzSgJjGf89g1DgTw@mail.gmail.com>
	<50607D70020000780009D5C3@nat28.tlf.novell.com>
	<CAOvdn6XL9ebp2oUV0XEXk_WdU3-=YAj+xfz6AMLDBpVThH3Xvw@mail.gmail.com>
	<506085FF020000780009D5F9@nat28.tlf.novell.com>
	<CAOvdn6XYt9vf_Ct0w71x6PHQzOHCaTX6Bi-HeZszRzxpKcRYRg@mail.gmail.com>
	<50608A32020000780009D639@nat28.tlf.novell.com>
Date: Mon, 24 Sep 2012 15:02:16 -0400
X-Google-Sender-Auth: j_ERci-tLfAT2BH1QnHeMXt0REQ
Message-ID: <CAOvdn6UCF2A3yP1cqWn=dxwr0ayRbr+rg+xj8META9Dm0+CoNw@mail.gmail.com>
From: Ben Guthro <ben@guthro.net>
To: Jan Beulich <JBeulich@suse.com>
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen4.2 S3 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: multipart/mixed; boundary="===============2074279029152564170=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============2074279029152564170==
Content-Type: multipart/alternative; boundary=bcaec51b9c7369a8e504ca773ac7

--bcaec51b9c7369a8e504ca773ac7
Content-Type: text/plain; charset=ISO-8859-1

Well...knock one bug down - and another crops up.

It appears that dom0_vcpu_pin is incompatible with S3.
I'll start digging into why, but if you have any thoughts from the stack
below, I'd welcome any pointers.

/btg


(XEN) Preparing system for ACPI S3 state.
(XEN) Disabling non-boot CPUs ...
(XEN) Entering ACPI S3 state.
(XEN) mce_intel.c:1239: MCA Capability: BCAST 1 SER 0 CMCI 0 firstbank 1
extended MCE MSR 0
(XEN) CMCI: CPU0 has no CMCI support
(XEN) CPU0: Thermal monitoring enabled (TM2)
(XEN) Finishing wakeup from ACPI S3 state.
(XEN) Enabling non-boot CPUs  ...
(XEN) Booting processor 1/1 eip 8a000
(XEN) Initializing CPU#1
(XEN) CPU: L1 I cache: 32K, L1 D cache: 32K
(XEN) CPU: L2 cache: 3072K
(XEN) CPU: Physical Processor ID: 0
(XEN) CPU: Processor Core ID: 1
(XEN) CMCI: CPU1 has no CMCI support
(XEN) CPU1: Thermal monitoring enabled (TM2)
(XEN) CPU1: Intel(R) Core(TM)2 Duo CPU     P8400  @ 2.26GHz stepping 06
(XEN) microcode: CPU1 updated from revision 0x60c to 0x60f, date =
2010-09-29
[   60.100054] ACPI: Low-level resume complete
[   60.100054] PM: Restoring platform NVS memory
[   60.100054] Enabling non-boot CPUs ...
[   60.100054] installing Xen timer for CPU 1
[   60.100054] cpu 1 spinlock event irq 279
(XEN) ----[ Xen-4.2.1-pre  x86_64  debug=n  Tainted:    C ]----
(XEN) CPU:    1
(XEN) RIP:    e008:[<ffff82c480121562>] vcpu_migrate+0x172/0x360
(XEN) RFLAGS: 0000000000010096   CONTEXT: hypervisor
(XEN) rax: 00007d3b7fd17180   rbx: ffff82c4802e8ee0   rcx: ffff82c4802e8ee0
(XEN) rdx: ffff83013a3c5068   rsi: 0000000000000004   rdi: ffff8301300b7d68
(XEN) rbp: 0000000000000001   rsp: ffff8301300b7e28   r8:  0000000000000000
(XEN) r9:  000000000000003e   r10: 000000000000003e   r11: 0000000000000246
(XEN) r12: ffff83013a3c5068   r13: ffff83013a3c5068   r14: ffff82c4802d3140
(XEN) r15: 0000000000000001   cr0: 000000008005003b   cr4: 00000000000026f0
(XEN) cr3: 0000000131a05000   cr2: 0000000000000060
(XEN) ds: 002b   es: 002b   fs: 0000   gs: 0000   ss: e010   cs: e008
(XEN) Xen stack trace from rsp=ffff8301300b7e28:
(XEN)    ffff82c4802d3140 ffff83013a3c5068 0000000000000246 0000000000000004
(XEN)    ffff8300bd2fe000 ffff82c4802e8ee0 00000004012d3140 ffff82c4802e8ee0
(XEN)    ffff88003fc8e820 ffff8300bd2fe000 ffff8301355d8000 0000000000000000
(XEN)    0000000000000000 0000000000000000 ffff88003fc8e820 ffff82c480105a50
(XEN)    0000000000000000 ffff82c4801805ec 0000060f00000000 ffff82c480184f16
(XEN)    0000000000000032 78a20f6e65780b0f ffff88003976fdc8 ffff8300bd2fe000
(XEN)    ffff88003976fe50 ffff8300bd2fe000 ffff88003976fda0 0000000000000001
(XEN)    0000000000000000 ffff82c480214288 ffff88003fc8e820 0000000000000000
(XEN)    0000000000000000 0000000000000001 ffff88003976fda0 ffff88003fc8bdc0
(XEN)    0000000000000246 ffff88003976fe60 00000000ffffffff 0000000000000000
(XEN)    0000000000000018 ffffffff8100130a 0000000000000000 0000000000000001
(XEN)    0000000000000007 0000010000000000 ffffffff8100130a 000000000000e033
(XEN)    0000000000000246 ffff88003976fd88 000000000000e02b d43d5f3fedaef5e7
(XEN)    d3b2ddaeed5038ff 270adb813ad76c9b ddfd6ff5f85e6775 b5881cbf00000001
(XEN)    ffff8300bd2fe000 0000003cba0dc180 0a109ac649c118a1
(XEN) Xen call trace:
(XEN)    [<ffff82c480121562>] vcpu_migrate+0x172/0x360
(XEN)    [<ffff82c480105a50>] do_vcpu_op+0x1e0/0x4a0
(XEN)    [<ffff82c4801805ec>] do_invalid_op+0x19c/0x3f0
(XEN)    [<ffff82c480184f16>] copy_from_user+0x26/0x90
(XEN)    [<ffff82c480214288>] syscall_enter+0x88/0x8d
(XEN)
(XEN) Pagetable walk from 0000000000000060:
(XEN)  L4[0x000] = 0000000000000000 ffffffffffffffff
(XEN)
(XEN) ****************************************
(XEN) Panic on CPU 1:
(XEN) FATAL PAGE FAULT
(XEN) [error_code=0000]
(XEN) Faulting linear address: 0000000000000060
(XEN) ****************************************
(XEN)
(XEN) Reboot in five seconds...


On Mon, Sep 24, 2012 at 10:28 AM, Jan Beulich <JBeulich@suse.com> wrote:

> >>> On 24.09.12 at 16:16, Ben Guthro <ben@guthro.net> wrote:
> > Would you prefer a separate [PATCH] email for this fix, or will you apply
> > it as-is?
>
> I'll put something together - the most important thing here obviously
> is having a proper description. Plus I'd like to slightly extend this and
> have acpi_dead_idle() actually use default_dead_idle(), just to have
> things consolidated in one place. I assume I can put your S-o-b on
> what you sent...
>
> Jan
>
> > On Mon, Sep 24, 2012 at 10:10 AM, Jan Beulich <JBeulich@suse.com> wrote:
> >
> >> >>> On 24.09.12 at 15:56, Ben Guthro <ben@guthro.net> wrote:
> >> > On Mon, Sep 24, 2012 at 9:34 AM, Jan Beulich <JBeulich@suse.com>
> wrote:
> >> >> ...; the interesting ones are
> >> >> - at the end of xen/arch/x86/acpu/cpu_idle.c:acpi_dead_idle()
> >> >> - xen/arch/x86/domain.c:default_dead_idle()
> >> >
> >> >
> >> > Thanks! This fixes the issue on this machine!
> >>
> >> Hooray!
> >>
> >> > Is this a reasonable long-term solution - or are there reasons not to
> >> > call wbinvd() here?
> >>
> >> That's a perfectly valid adjustment (see my earlier reply where
> >> I originally suggested it and explained why it may be necessary).
> >>
> >> Jan
> >>
> >>
>
>
>
>

--bcaec51b9c7369a8e504ca773ac7
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Well...knock one bug down - and another crops up.<div><br></div><div>It app=
ears that dom0_vcpu_pin is incompatible with S3.</div><div>I&#39;ll start d=
igging into why, but if you have any thoughts from the stack below, I&#39;d=
 welcome any pointers.</div>
<div><br></div><div>/btg</div><div><br></div><div><br></div><div><div>(XEN)=
 Preparing system for ACPI S3 state.</div><div>(XEN) Disabling non-boot CPU=
s ...</div><div>(XEN) Entering ACPI S3 state.</div><div>(XEN) mce_intel.c:1=
239: MCA Capability: BCAST 1 SER 0 CMCI 0 firstbank 1 extended MCE MSR 0</d=
iv>
<div>(XEN) CMCI: CPU0 has no CMCI support</div><div>(XEN) CPU0: Thermal mon=
itoring enabled (TM2)</div><div>(XEN) Finishing wakeup from ACPI S3 state.<=
/div><div>(XEN) Enabling non-boot CPUs =A0...</div><div>(XEN) Booting proce=
ssor 1/1 eip 8a000</div>
<div>(XEN) Initializing CPU#1</div><div>(XEN) CPU: L1 I cache: 32K, L1 D ca=
che: 32K</div><div>(XEN) CPU: L2 cache: 3072K</div><div>(XEN) CPU: Physical=
 Processor ID: 0</div><div>(XEN) CPU: Processor Core ID: 1</div><div>(XEN) =
CMCI: CPU1 has no CMCI support</div>
<div>(XEN) CPU1: Thermal monitoring enabled (TM2)</div><div>(XEN) CPU1: Int=
el(R) Core(TM)2 Duo CPU =A0 =A0 P8400 =A0@ 2.26GHz stepping 06</div><div>(X=
EN) microcode: CPU1 updated from revision 0x60c to 0x60f, date =3D 2010-09-=
29=A0</div>
<div>[ =A0 60.100054] ACPI: Low-level resume complete</div><div>[ =A0 60.10=
0054] PM: Restoring platform NVS memory</div><div>[ =A0 60.100054] Enabling=
 non-boot CPUs ...</div><div>[ =A0 60.100054] installing Xen timer for CPU =
1</div>
<div>[ =A0 60.100054] cpu 1 spinlock event irq 279</div><div>(XEN) ----[ Xe=
n-4.2.1-pre =A0x86_64 =A0debug=3Dn =A0Tainted: =A0 =A0C ]----</div><div>(XE=
N) CPU: =A0 =A01</div><div>(XEN) RIP: =A0 =A0e008:[&lt;ffff82c480121562&gt;=
] vcpu_migrate+0x172/0x360</div>
<div>(XEN) RFLAGS: 0000000000010096 =A0 CONTEXT: hypervisor</div><div>(XEN)=
 rax: 00007d3b7fd17180 =A0 rbx: ffff82c4802e8ee0 =A0 rcx: ffff82c4802e8ee0<=
/div><div>(XEN) rdx: ffff83013a3c5068 =A0 rsi: 0000000000000004 =A0 rdi: ff=
ff8301300b7d68</div>
<div>(XEN) rbp: 0000000000000001 =A0 rsp: ffff8301300b7e28 =A0 r8: =A000000=
00000000000</div><div>(XEN) r9: =A0000000000000003e =A0 r10: 00000000000000=
3e =A0 r11: 0000000000000246</div><div>(XEN) r12: ffff83013a3c5068 =A0 r13:=
 ffff83013a3c5068 =A0 r14: ffff82c4802d3140</div>
<div>(XEN) r15: 0000000000000001 =A0 cr0: 000000008005003b =A0 cr4: 0000000=
0000026f0</div><div>(XEN) cr3: 0000000131a05000 =A0 cr2: 0000000000000060</=
div><div>(XEN) ds: 002b =A0 es: 002b =A0 fs: 0000 =A0 gs: 0000 =A0 ss: e010=
 =A0 cs: e008</div>
<div>(XEN) Xen stack trace from rsp=3Dffff8301300b7e28:</div><div>(XEN) =A0=
 =A0ffff82c4802d3140 ffff83013a3c5068 0000000000000246 0000000000000004</di=
v><div>(XEN) =A0 =A0ffff8300bd2fe000 ffff82c4802e8ee0 00000004012d3140 ffff=
82c4802e8ee0</div>
<div>(XEN) =A0 =A0ffff88003fc8e820 ffff8300bd2fe000 ffff8301355d8000 000000=
0000000000</div><div>(XEN) =A0 =A00000000000000000 0000000000000000 ffff880=
03fc8e820 ffff82c480105a50</div><div>(XEN) =A0 =A00000000000000000 ffff82c4=
801805ec 0000060f00000000 ffff82c480184f16</div>
<div>(XEN) =A0 =A00000000000000032 78a20f6e65780b0f ffff88003976fdc8 ffff83=
00bd2fe000</div><div>(XEN) =A0 =A0ffff88003976fe50 ffff8300bd2fe000 ffff880=
03976fda0 0000000000000001</div><div>(XEN) =A0 =A00000000000000000 ffff82c4=
80214288 ffff88003fc8e820 0000000000000000</div>
<div>(XEN) =A0 =A00000000000000000 0000000000000001 ffff88003976fda0 ffff88=
003fc8bdc0</div><div>(XEN) =A0 =A00000000000000246 ffff88003976fe60 0000000=
0ffffffff 0000000000000000</div><div>(XEN) =A0 =A00000000000000018 ffffffff=
8100130a 0000000000000000 0000000000000001</div>
<div>(XEN) =A0 =A00000000000000007 0000010000000000 ffffffff8100130a 000000=
000000e033</div><div>(XEN) =A0 =A00000000000000246 ffff88003976fd88 0000000=
00000e02b d43d5f3fedaef5e7</div><div>(XEN) =A0 =A0d3b2ddaeed5038ff 270adb81=
3ad76c9b ddfd6ff5f85e6775 b5881cbf00000001</div>
<div>(XEN) =A0 =A0ffff8300bd2fe000 0000003cba0dc180 0a109ac649c118a1</div><=
div>(XEN) Xen call trace:</div><div>(XEN) =A0 =A0[&lt;ffff82c480121562&gt;]=
 vcpu_migrate+0x172/0x360</div><div>(XEN) =A0 =A0[&lt;ffff82c480105a50&gt;]=
 do_vcpu_op+0x1e0/0x4a0</div>
<div>(XEN) =A0 =A0[&lt;ffff82c4801805ec&gt;] do_invalid_op+0x19c/0x3f0</div=
><div>(XEN) =A0 =A0[&lt;ffff82c480184f16&gt;] copy_from_user+0x26/0x90</div=
><div>(XEN) =A0 =A0[&lt;ffff82c480214288&gt;] syscall_enter+0x88/0x8d</div>=
<div>(XEN) =A0 =A0</div>
<div>(XEN) Pagetable walk from 0000000000000060:</div><div>(XEN) =A0L4[0x00=
0] =3D 0000000000000000 ffffffffffffffff</div><div>(XEN)=A0</div><div>(XEN)=
 ****************************************</div><div>(XEN) Panic on CPU 1:</=
div>
<div>(XEN) FATAL PAGE FAULT</div><div>(XEN) [error_code=3D0000]</div><div>(=
XEN) Faulting linear address: 0000000000000060</div><div>(XEN) ************=
****************************</div><div>(XEN)=A0</div><div>(XEN) Reboot in f=
ive seconds...</div>
<div><br></div><br><div class=3D"gmail_quote">On Mon, Sep 24, 2012 at 10:28=
 AM, 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><blockquote c=
lass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;=
padding-left:1ex">
<div class=3D"im">&gt;&gt;&gt; On 24.09.12 at 16:16, Ben Guthro &lt;<a href=
=3D"mailto:ben@guthro.net">ben@guthro.net</a>&gt; wrote:<br>
&gt; Would you prefer a separate [PATCH] email for this fix, or will you ap=
ply<br>
&gt; it as-is?<br>
<br>
</div>I&#39;ll put something together - the most important thing here obvio=
usly<br>
is having a proper description. Plus I&#39;d like to slightly extend this a=
nd<br>
have acpi_dead_idle() actually use default_dead_idle(), just to have<br>
things consolidated in one place. I assume I can put your S-o-b on<br>
what you sent...<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
Jan<br>
</font></span><div class=3D"HOEnZb"><div class=3D"h5"><br>
&gt; On Mon, Sep 24, 2012 at 10:10 AM, Jan Beulich &lt;<a href=3D"mailto:JB=
eulich@suse.com">JBeulich@suse.com</a>&gt; wrote:<br>
&gt;<br>
&gt;&gt; &gt;&gt;&gt; On 24.09.12 at 15:56, Ben Guthro &lt;<a href=3D"mailt=
o:ben@guthro.net">ben@guthro.net</a>&gt; wrote:<br>
&gt;&gt; &gt; On Mon, Sep 24, 2012 at 9:34 AM, Jan Beulich &lt;<a href=3D"m=
ailto:JBeulich@suse.com">JBeulich@suse.com</a>&gt; wrote:<br>
&gt;&gt; &gt;&gt; ...; the interesting ones are<br>
&gt;&gt; &gt;&gt; - at the end of xen/arch/x86/acpu/cpu_idle.c:acpi_dead_id=
le()<br>
&gt;&gt; &gt;&gt; - xen/arch/x86/domain.c:default_dead_idle()<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; Thanks! This fixes the issue on this machine!<br>
&gt;&gt;<br>
&gt;&gt; Hooray!<br>
&gt;&gt;<br>
&gt;&gt; &gt; Is this a reasonable long-term solution - or are there reason=
s not to<br>
&gt;&gt; &gt; call wbinvd() here?<br>
&gt;&gt;<br>
&gt;&gt; That&#39;s a perfectly valid adjustment (see my earlier reply wher=
e<br>
&gt;&gt; I originally suggested it and explained why it may be necessary).<=
br>
&gt;&gt;<br>
&gt;&gt; Jan<br>
&gt;&gt;<br>
&gt;&gt;<br>
<br>
<br>
<br>
</div></div></blockquote></div><br></div>

--bcaec51b9c7369a8e504ca773ac7--


--===============2074279029152564170==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============2074279029152564170==--


From xen-devel-bounces@lists.xen.org Mon Sep 24 19:02:55 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Sep 2012 19:02:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGDvB-0002aX-Ev; Mon, 24 Sep 2012 19:02:21 +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 1TGDvA-0002aS-8A
	for xen-devel@lists.xen.org; Mon, 24 Sep 2012 19:02:20 +0000
Received: from [85.158.139.211:10017] by server-8.bemta-5.messagelabs.com id
	4F/B4-18073-B3EA0605; Mon, 24 Sep 2012 19:02:19 +0000
X-Env-Sender: ben.guthro@gmail.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1348513337!19330852!1
X-Originating-IP: [209.85.220.173]
X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_20_30,HTML_MESSAGE,
	RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32693 invoked from network); 24 Sep 2012 19:02:18 -0000
Received: from mail-vc0-f173.google.com (HELO mail-vc0-f173.google.com)
	(209.85.220.173)
	by server-7.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Sep 2012 19:02:18 -0000
Received: by vcbfl15 with SMTP id fl15so8102027vcb.32
	for <xen-devel@lists.xen.org>; Mon, 24 Sep 2012 12:02: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;
	bh=ZMTNJzQ47ox6HBbbEvsMsz6bsCgpCBRSysblNxi9/MQ=;
	b=oYaDgZ7yMKgGYzhhzVx9Q4aOnR3gEFbTX57ErHusDq77S74yQ3jTZ0VTgOHkERtG/E
	4QigoUah7yPqYJCvio6uyDZSbeSM4a8Wx7X54KKySb+GXkfM0Om0K0E45q+ZM+XTDQgw
	GFrDy38BzRoCKgAfknyBY4AbGGKmnlFjyv2DCI2feW0hdfoUI7bdjVSdHf1iIxBPHX80
	lTmSbfKlXDnQvwBSOoE7zhUOrPZPmdof2C4TIH5nuAzvWufaXBC5zXmXV++vd/JQqzwp
	rOPjBx13nJ+A8ual5bcaEMK+Q6+mLTZj62yiNZhlGYt5qnACqu8/usXzcsn1lNnPNlZq
	bKpw==
MIME-Version: 1.0
Received: by 10.52.150.84 with SMTP id ug20mr1842669vdb.16.1348513336764; Mon,
	24 Sep 2012 12:02:16 -0700 (PDT)
Received: by 10.58.137.169 with HTTP; Mon, 24 Sep 2012 12:02:16 -0700 (PDT)
In-Reply-To: <50608A32020000780009D639@nat28.tlf.novell.com>
References: <CAOvdn6XKPOMNn6AjuYvZvPXRRJffN3po5GXe1Yh1-m0hisMK_w@mail.gmail.com>
	<CC8273A0.4C9DD%keir@xen.org>
	<50605E9A020000780009D486@nat28.tlf.novell.com>
	<CAOvdn6XmB6rj3_QVU+59V8p24Y5G47AWxVEM=id02JWXkuhibQ@mail.gmail.com>
	<5060640B020000780009D4D2@nat28.tlf.novell.com>
	<CAOvdn6XLy8zR2rb2MEyi2aT9LQiFvFLY_H02p181mTsVLVTZkw@mail.gmail.com>
	<506068A0020000780009D519@nat28.tlf.novell.com>
	<CAOvdn6Undn2srfNhW++wLfUNFQ5JnZ3rp5bg7DD_TDPCHqmP_A@mail.gmail.com>
	<50606F18020000780009D57B@nat28.tlf.novell.com>
	<CAOvdn6UMHmPWqedYE9GQQMDaM4oiHLDSn9ZzSgJjGf89g1DgTw@mail.gmail.com>
	<50607D70020000780009D5C3@nat28.tlf.novell.com>
	<CAOvdn6XL9ebp2oUV0XEXk_WdU3-=YAj+xfz6AMLDBpVThH3Xvw@mail.gmail.com>
	<506085FF020000780009D5F9@nat28.tlf.novell.com>
	<CAOvdn6XYt9vf_Ct0w71x6PHQzOHCaTX6Bi-HeZszRzxpKcRYRg@mail.gmail.com>
	<50608A32020000780009D639@nat28.tlf.novell.com>
Date: Mon, 24 Sep 2012 15:02:16 -0400
X-Google-Sender-Auth: j_ERci-tLfAT2BH1QnHeMXt0REQ
Message-ID: <CAOvdn6UCF2A3yP1cqWn=dxwr0ayRbr+rg+xj8META9Dm0+CoNw@mail.gmail.com>
From: Ben Guthro <ben@guthro.net>
To: Jan Beulich <JBeulich@suse.com>
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen4.2 S3 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: multipart/mixed; boundary="===============2074279029152564170=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============2074279029152564170==
Content-Type: multipart/alternative; boundary=bcaec51b9c7369a8e504ca773ac7

--bcaec51b9c7369a8e504ca773ac7
Content-Type: text/plain; charset=ISO-8859-1

Well...knock one bug down - and another crops up.

It appears that dom0_vcpu_pin is incompatible with S3.
I'll start digging into why, but if you have any thoughts from the stack
below, I'd welcome any pointers.

/btg


(XEN) Preparing system for ACPI S3 state.
(XEN) Disabling non-boot CPUs ...
(XEN) Entering ACPI S3 state.
(XEN) mce_intel.c:1239: MCA Capability: BCAST 1 SER 0 CMCI 0 firstbank 1
extended MCE MSR 0
(XEN) CMCI: CPU0 has no CMCI support
(XEN) CPU0: Thermal monitoring enabled (TM2)
(XEN) Finishing wakeup from ACPI S3 state.
(XEN) Enabling non-boot CPUs  ...
(XEN) Booting processor 1/1 eip 8a000
(XEN) Initializing CPU#1
(XEN) CPU: L1 I cache: 32K, L1 D cache: 32K
(XEN) CPU: L2 cache: 3072K
(XEN) CPU: Physical Processor ID: 0
(XEN) CPU: Processor Core ID: 1
(XEN) CMCI: CPU1 has no CMCI support
(XEN) CPU1: Thermal monitoring enabled (TM2)
(XEN) CPU1: Intel(R) Core(TM)2 Duo CPU     P8400  @ 2.26GHz stepping 06
(XEN) microcode: CPU1 updated from revision 0x60c to 0x60f, date =
2010-09-29
[   60.100054] ACPI: Low-level resume complete
[   60.100054] PM: Restoring platform NVS memory
[   60.100054] Enabling non-boot CPUs ...
[   60.100054] installing Xen timer for CPU 1
[   60.100054] cpu 1 spinlock event irq 279
(XEN) ----[ Xen-4.2.1-pre  x86_64  debug=n  Tainted:    C ]----
(XEN) CPU:    1
(XEN) RIP:    e008:[<ffff82c480121562>] vcpu_migrate+0x172/0x360
(XEN) RFLAGS: 0000000000010096   CONTEXT: hypervisor
(XEN) rax: 00007d3b7fd17180   rbx: ffff82c4802e8ee0   rcx: ffff82c4802e8ee0
(XEN) rdx: ffff83013a3c5068   rsi: 0000000000000004   rdi: ffff8301300b7d68
(XEN) rbp: 0000000000000001   rsp: ffff8301300b7e28   r8:  0000000000000000
(XEN) r9:  000000000000003e   r10: 000000000000003e   r11: 0000000000000246
(XEN) r12: ffff83013a3c5068   r13: ffff83013a3c5068   r14: ffff82c4802d3140
(XEN) r15: 0000000000000001   cr0: 000000008005003b   cr4: 00000000000026f0
(XEN) cr3: 0000000131a05000   cr2: 0000000000000060
(XEN) ds: 002b   es: 002b   fs: 0000   gs: 0000   ss: e010   cs: e008
(XEN) Xen stack trace from rsp=ffff8301300b7e28:
(XEN)    ffff82c4802d3140 ffff83013a3c5068 0000000000000246 0000000000000004
(XEN)    ffff8300bd2fe000 ffff82c4802e8ee0 00000004012d3140 ffff82c4802e8ee0
(XEN)    ffff88003fc8e820 ffff8300bd2fe000 ffff8301355d8000 0000000000000000
(XEN)    0000000000000000 0000000000000000 ffff88003fc8e820 ffff82c480105a50
(XEN)    0000000000000000 ffff82c4801805ec 0000060f00000000 ffff82c480184f16
(XEN)    0000000000000032 78a20f6e65780b0f ffff88003976fdc8 ffff8300bd2fe000
(XEN)    ffff88003976fe50 ffff8300bd2fe000 ffff88003976fda0 0000000000000001
(XEN)    0000000000000000 ffff82c480214288 ffff88003fc8e820 0000000000000000
(XEN)    0000000000000000 0000000000000001 ffff88003976fda0 ffff88003fc8bdc0
(XEN)    0000000000000246 ffff88003976fe60 00000000ffffffff 0000000000000000
(XEN)    0000000000000018 ffffffff8100130a 0000000000000000 0000000000000001
(XEN)    0000000000000007 0000010000000000 ffffffff8100130a 000000000000e033
(XEN)    0000000000000246 ffff88003976fd88 000000000000e02b d43d5f3fedaef5e7
(XEN)    d3b2ddaeed5038ff 270adb813ad76c9b ddfd6ff5f85e6775 b5881cbf00000001
(XEN)    ffff8300bd2fe000 0000003cba0dc180 0a109ac649c118a1
(XEN) Xen call trace:
(XEN)    [<ffff82c480121562>] vcpu_migrate+0x172/0x360
(XEN)    [<ffff82c480105a50>] do_vcpu_op+0x1e0/0x4a0
(XEN)    [<ffff82c4801805ec>] do_invalid_op+0x19c/0x3f0
(XEN)    [<ffff82c480184f16>] copy_from_user+0x26/0x90
(XEN)    [<ffff82c480214288>] syscall_enter+0x88/0x8d
(XEN)
(XEN) Pagetable walk from 0000000000000060:
(XEN)  L4[0x000] = 0000000000000000 ffffffffffffffff
(XEN)
(XEN) ****************************************
(XEN) Panic on CPU 1:
(XEN) FATAL PAGE FAULT
(XEN) [error_code=0000]
(XEN) Faulting linear address: 0000000000000060
(XEN) ****************************************
(XEN)
(XEN) Reboot in five seconds...


On Mon, Sep 24, 2012 at 10:28 AM, Jan Beulich <JBeulich@suse.com> wrote:

> >>> On 24.09.12 at 16:16, Ben Guthro <ben@guthro.net> wrote:
> > Would you prefer a separate [PATCH] email for this fix, or will you apply
> > it as-is?
>
> I'll put something together - the most important thing here obviously
> is having a proper description. Plus I'd like to slightly extend this and
> have acpi_dead_idle() actually use default_dead_idle(), just to have
> things consolidated in one place. I assume I can put your S-o-b on
> what you sent...
>
> Jan
>
> > On Mon, Sep 24, 2012 at 10:10 AM, Jan Beulich <JBeulich@suse.com> wrote:
> >
> >> >>> On 24.09.12 at 15:56, Ben Guthro <ben@guthro.net> wrote:
> >> > On Mon, Sep 24, 2012 at 9:34 AM, Jan Beulich <JBeulich@suse.com>
> wrote:
> >> >> ...; the interesting ones are
> >> >> - at the end of xen/arch/x86/acpu/cpu_idle.c:acpi_dead_idle()
> >> >> - xen/arch/x86/domain.c:default_dead_idle()
> >> >
> >> >
> >> > Thanks! This fixes the issue on this machine!
> >>
> >> Hooray!
> >>
> >> > Is this a reasonable long-term solution - or are there reasons not to
> >> > call wbinvd() here?
> >>
> >> That's a perfectly valid adjustment (see my earlier reply where
> >> I originally suggested it and explained why it may be necessary).
> >>
> >> Jan
> >>
> >>
>
>
>
>

--bcaec51b9c7369a8e504ca773ac7
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Well...knock one bug down - and another crops up.<div><br></div><div>It app=
ears that dom0_vcpu_pin is incompatible with S3.</div><div>I&#39;ll start d=
igging into why, but if you have any thoughts from the stack below, I&#39;d=
 welcome any pointers.</div>
<div><br></div><div>/btg</div><div><br></div><div><br></div><div><div>(XEN)=
 Preparing system for ACPI S3 state.</div><div>(XEN) Disabling non-boot CPU=
s ...</div><div>(XEN) Entering ACPI S3 state.</div><div>(XEN) mce_intel.c:1=
239: MCA Capability: BCAST 1 SER 0 CMCI 0 firstbank 1 extended MCE MSR 0</d=
iv>
<div>(XEN) CMCI: CPU0 has no CMCI support</div><div>(XEN) CPU0: Thermal mon=
itoring enabled (TM2)</div><div>(XEN) Finishing wakeup from ACPI S3 state.<=
/div><div>(XEN) Enabling non-boot CPUs =A0...</div><div>(XEN) Booting proce=
ssor 1/1 eip 8a000</div>
<div>(XEN) Initializing CPU#1</div><div>(XEN) CPU: L1 I cache: 32K, L1 D ca=
che: 32K</div><div>(XEN) CPU: L2 cache: 3072K</div><div>(XEN) CPU: Physical=
 Processor ID: 0</div><div>(XEN) CPU: Processor Core ID: 1</div><div>(XEN) =
CMCI: CPU1 has no CMCI support</div>
<div>(XEN) CPU1: Thermal monitoring enabled (TM2)</div><div>(XEN) CPU1: Int=
el(R) Core(TM)2 Duo CPU =A0 =A0 P8400 =A0@ 2.26GHz stepping 06</div><div>(X=
EN) microcode: CPU1 updated from revision 0x60c to 0x60f, date =3D 2010-09-=
29=A0</div>
<div>[ =A0 60.100054] ACPI: Low-level resume complete</div><div>[ =A0 60.10=
0054] PM: Restoring platform NVS memory</div><div>[ =A0 60.100054] Enabling=
 non-boot CPUs ...</div><div>[ =A0 60.100054] installing Xen timer for CPU =
1</div>
<div>[ =A0 60.100054] cpu 1 spinlock event irq 279</div><div>(XEN) ----[ Xe=
n-4.2.1-pre =A0x86_64 =A0debug=3Dn =A0Tainted: =A0 =A0C ]----</div><div>(XE=
N) CPU: =A0 =A01</div><div>(XEN) RIP: =A0 =A0e008:[&lt;ffff82c480121562&gt;=
] vcpu_migrate+0x172/0x360</div>
<div>(XEN) RFLAGS: 0000000000010096 =A0 CONTEXT: hypervisor</div><div>(XEN)=
 rax: 00007d3b7fd17180 =A0 rbx: ffff82c4802e8ee0 =A0 rcx: ffff82c4802e8ee0<=
/div><div>(XEN) rdx: ffff83013a3c5068 =A0 rsi: 0000000000000004 =A0 rdi: ff=
ff8301300b7d68</div>
<div>(XEN) rbp: 0000000000000001 =A0 rsp: ffff8301300b7e28 =A0 r8: =A000000=
00000000000</div><div>(XEN) r9: =A0000000000000003e =A0 r10: 00000000000000=
3e =A0 r11: 0000000000000246</div><div>(XEN) r12: ffff83013a3c5068 =A0 r13:=
 ffff83013a3c5068 =A0 r14: ffff82c4802d3140</div>
<div>(XEN) r15: 0000000000000001 =A0 cr0: 000000008005003b =A0 cr4: 0000000=
0000026f0</div><div>(XEN) cr3: 0000000131a05000 =A0 cr2: 0000000000000060</=
div><div>(XEN) ds: 002b =A0 es: 002b =A0 fs: 0000 =A0 gs: 0000 =A0 ss: e010=
 =A0 cs: e008</div>
<div>(XEN) Xen stack trace from rsp=3Dffff8301300b7e28:</div><div>(XEN) =A0=
 =A0ffff82c4802d3140 ffff83013a3c5068 0000000000000246 0000000000000004</di=
v><div>(XEN) =A0 =A0ffff8300bd2fe000 ffff82c4802e8ee0 00000004012d3140 ffff=
82c4802e8ee0</div>
<div>(XEN) =A0 =A0ffff88003fc8e820 ffff8300bd2fe000 ffff8301355d8000 000000=
0000000000</div><div>(XEN) =A0 =A00000000000000000 0000000000000000 ffff880=
03fc8e820 ffff82c480105a50</div><div>(XEN) =A0 =A00000000000000000 ffff82c4=
801805ec 0000060f00000000 ffff82c480184f16</div>
<div>(XEN) =A0 =A00000000000000032 78a20f6e65780b0f ffff88003976fdc8 ffff83=
00bd2fe000</div><div>(XEN) =A0 =A0ffff88003976fe50 ffff8300bd2fe000 ffff880=
03976fda0 0000000000000001</div><div>(XEN) =A0 =A00000000000000000 ffff82c4=
80214288 ffff88003fc8e820 0000000000000000</div>
<div>(XEN) =A0 =A00000000000000000 0000000000000001 ffff88003976fda0 ffff88=
003fc8bdc0</div><div>(XEN) =A0 =A00000000000000246 ffff88003976fe60 0000000=
0ffffffff 0000000000000000</div><div>(XEN) =A0 =A00000000000000018 ffffffff=
8100130a 0000000000000000 0000000000000001</div>
<div>(XEN) =A0 =A00000000000000007 0000010000000000 ffffffff8100130a 000000=
000000e033</div><div>(XEN) =A0 =A00000000000000246 ffff88003976fd88 0000000=
00000e02b d43d5f3fedaef5e7</div><div>(XEN) =A0 =A0d3b2ddaeed5038ff 270adb81=
3ad76c9b ddfd6ff5f85e6775 b5881cbf00000001</div>
<div>(XEN) =A0 =A0ffff8300bd2fe000 0000003cba0dc180 0a109ac649c118a1</div><=
div>(XEN) Xen call trace:</div><div>(XEN) =A0 =A0[&lt;ffff82c480121562&gt;]=
 vcpu_migrate+0x172/0x360</div><div>(XEN) =A0 =A0[&lt;ffff82c480105a50&gt;]=
 do_vcpu_op+0x1e0/0x4a0</div>
<div>(XEN) =A0 =A0[&lt;ffff82c4801805ec&gt;] do_invalid_op+0x19c/0x3f0</div=
><div>(XEN) =A0 =A0[&lt;ffff82c480184f16&gt;] copy_from_user+0x26/0x90</div=
><div>(XEN) =A0 =A0[&lt;ffff82c480214288&gt;] syscall_enter+0x88/0x8d</div>=
<div>(XEN) =A0 =A0</div>
<div>(XEN) Pagetable walk from 0000000000000060:</div><div>(XEN) =A0L4[0x00=
0] =3D 0000000000000000 ffffffffffffffff</div><div>(XEN)=A0</div><div>(XEN)=
 ****************************************</div><div>(XEN) Panic on CPU 1:</=
div>
<div>(XEN) FATAL PAGE FAULT</div><div>(XEN) [error_code=3D0000]</div><div>(=
XEN) Faulting linear address: 0000000000000060</div><div>(XEN) ************=
****************************</div><div>(XEN)=A0</div><div>(XEN) Reboot in f=
ive seconds...</div>
<div><br></div><br><div class=3D"gmail_quote">On Mon, Sep 24, 2012 at 10:28=
 AM, 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><blockquote c=
lass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;=
padding-left:1ex">
<div class=3D"im">&gt;&gt;&gt; On 24.09.12 at 16:16, Ben Guthro &lt;<a href=
=3D"mailto:ben@guthro.net">ben@guthro.net</a>&gt; wrote:<br>
&gt; Would you prefer a separate [PATCH] email for this fix, or will you ap=
ply<br>
&gt; it as-is?<br>
<br>
</div>I&#39;ll put something together - the most important thing here obvio=
usly<br>
is having a proper description. Plus I&#39;d like to slightly extend this a=
nd<br>
have acpi_dead_idle() actually use default_dead_idle(), just to have<br>
things consolidated in one place. I assume I can put your S-o-b on<br>
what you sent...<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
Jan<br>
</font></span><div class=3D"HOEnZb"><div class=3D"h5"><br>
&gt; On Mon, Sep 24, 2012 at 10:10 AM, Jan Beulich &lt;<a href=3D"mailto:JB=
eulich@suse.com">JBeulich@suse.com</a>&gt; wrote:<br>
&gt;<br>
&gt;&gt; &gt;&gt;&gt; On 24.09.12 at 15:56, Ben Guthro &lt;<a href=3D"mailt=
o:ben@guthro.net">ben@guthro.net</a>&gt; wrote:<br>
&gt;&gt; &gt; On Mon, Sep 24, 2012 at 9:34 AM, Jan Beulich &lt;<a href=3D"m=
ailto:JBeulich@suse.com">JBeulich@suse.com</a>&gt; wrote:<br>
&gt;&gt; &gt;&gt; ...; the interesting ones are<br>
&gt;&gt; &gt;&gt; - at the end of xen/arch/x86/acpu/cpu_idle.c:acpi_dead_id=
le()<br>
&gt;&gt; &gt;&gt; - xen/arch/x86/domain.c:default_dead_idle()<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; Thanks! This fixes the issue on this machine!<br>
&gt;&gt;<br>
&gt;&gt; Hooray!<br>
&gt;&gt;<br>
&gt;&gt; &gt; Is this a reasonable long-term solution - or are there reason=
s not to<br>
&gt;&gt; &gt; call wbinvd() here?<br>
&gt;&gt;<br>
&gt;&gt; That&#39;s a perfectly valid adjustment (see my earlier reply wher=
e<br>
&gt;&gt; I originally suggested it and explained why it may be necessary).<=
br>
&gt;&gt;<br>
&gt;&gt; Jan<br>
&gt;&gt;<br>
&gt;&gt;<br>
<br>
<br>
<br>
</div></div></blockquote></div><br></div>

--bcaec51b9c7369a8e504ca773ac7--


--===============2074279029152564170==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============2074279029152564170==--


From xen-devel-bounces@lists.xen.org Mon Sep 24 20:31:00 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Sep 2012 20:31:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGFIT-0003XK-05; Mon, 24 Sep 2012 20:30:29 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1TGFIR-0003XF-MZ
	for xen-devel@lists.xen.org; Mon, 24 Sep 2012 20:30:28 +0000
Received: from [85.158.138.51:30575] by server-2.bemta-3.messagelabs.com id
	4B/20-04862-2E2C0605; Mon, 24 Sep 2012 20:30:26 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1348518624!31781723!1
X-Originating-IP: [74.125.82.173]
X-SpamReason: No, hits=1.4 required=7.0 tests=HTML_20_30,HTML_MESSAGE,
	MIME_QP_LONG_LINE,ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6188 invoked from network); 24 Sep 2012 20:30:25 -0000
Received: from mail-we0-f173.google.com (HELO mail-we0-f173.google.com)
	(74.125.82.173)
	by server-11.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Sep 2012 20:30:25 -0000
Received: by weyt11 with SMTP id t11so4152815wey.32
	for <xen-devel@lists.xen.org>; Mon, 24 Sep 2012 13:30:24 -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;
	bh=E0LEjfJE3UMyf6sk1jLINrdc/Z8rvXfWm2WZu9T2CI8=;
	b=mgQggR0MvliAQI7sTEzO7TzmPCmrOrEGFYqTPi+WVbgrfyBrjwB2cw65uzAZSgSMXL
	eJS3xMtm0GHXK5K/sEcwcexhkoVXAhl41RcjJVGUcy9y9N06o3F1oBpaOYPkkpHLgSD9
	914Ho+NlCFYmDbD3X4Y7vdSHVDHAjzViU6XgOxrSJCZp44/0jEORjjeEWP0NGsCZx7I2
	Cz/3u5eDyMp2uH+IXwkkJtaJ5i6WTqxl7LgGA6OymUCFfFosGEEi6uUVp1O8B5uq35lj
	Hpof4orQ7wwiM2BCg49Vf8Aew51d1YlK+E9h3hZdxI75GPdPTRBTX9OctcyAt2kRhwGn
	xnwQ==
Received: by 10.180.106.9 with SMTP id gq9mr15762080wib.12.1348518624428;
	Mon, 24 Sep 2012 13:30:24 -0700 (PDT)
Received: from [192.168.1.69] (host86-167-82-156.range86-167.btcentralplus.com.
	[86.167.82.156])
	by mx.google.com with ESMTPS id fr4sm18670638wib.8.2012.09.24.13.30.20
	(version=SSLv3 cipher=OTHER); Mon, 24 Sep 2012 13:30:23 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Mon, 24 Sep 2012 21:30:16 +0100
From: Keir Fraser <keir.xen@gmail.com>
To: Ben Guthro <ben@guthro.net>,
	Jan Beulich <JBeulich@suse.com>
Message-ID: <CC868168.3FD29%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] Xen4.2 S3 regression?
Thread-Index: Ac2ak2gKf4S9Pr2u6USzTFHACYTP5g==
In-Reply-To: <CAOvdn6UCF2A3yP1cqWn=dxwr0ayRbr+rg+xj8META9Dm0+CoNw@mail.gmail.com>
Mime-version: 1.0
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen4.2 S3 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: multipart/mixed; boundary="===============6826780111348703616=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--===============6826780111348703616==
Content-type: multipart/alternative;
	boundary="B_3431367022_80686359"

> This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--B_3431367022_80686359
Content-type: text/plain;
	charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable

Do a debug build so the backtrace can be trusted. It=B9s a NULL pointer
dereference so shouldn=B9t be too tricky to make some headway on this one.
Easier than the previous bug. :)

 -- Keir

On 24/09/2012 20:02, "Ben Guthro" <ben@guthro.net> wrote:

> Well...knock one bug down - and another crops up.
>=20
> It appears that dom0_vcpu_pin is incompatible with S3.
> I'll start digging into why, but if you have any thoughts from the stack
> below, I'd welcome any pointers.
>=20
> /btg
>=20
>=20
> (XEN) Preparing system for ACPI S3 state.
> (XEN) Disabling non-boot CPUs ...
> (XEN) Entering ACPI S3 state.
> (XEN) mce_intel.c:1239: MCA Capability: BCAST 1 SER 0 CMCI 0 firstbank 1
> extended MCE MSR 0
> (XEN) CMCI: CPU0 has no CMCI support
> (XEN) CPU0: Thermal monitoring enabled (TM2)
> (XEN) Finishing wakeup from ACPI S3 state.
> (XEN) Enabling non-boot CPUs =A0...
> (XEN) Booting processor 1/1 eip 8a000
> (XEN) Initializing CPU#1
> (XEN) CPU: L1 I cache: 32K, L1 D cache: 32K
> (XEN) CPU: L2 cache: 3072K
> (XEN) CPU: Physical Processor ID: 0
> (XEN) CPU: Processor Core ID: 1
> (XEN) CMCI: CPU1 has no CMCI support
> (XEN) CPU1: Thermal monitoring enabled (TM2)
> (XEN) CPU1: Intel(R) Core(TM)2 Duo CPU =A0 =A0 P8400 =A0@ 2.26GHz stepping 06
> (XEN) microcode: CPU1 updated from revision 0x60c to 0x60f, date =3D 2010-0=
9-29=A0
> [ =A0 60.100054] ACPI: Low-level resume complete
> [ =A0 60.100054] PM: Restoring platform NVS memory
> [ =A0 60.100054] Enabling non-boot CPUs ...
> [ =A0 60.100054] installing Xen timer for CPU 1
> [ =A0 60.100054] cpu 1 spinlock event irq 279
> (XEN) ----[ Xen-4.2.1-pre =A0x86_64 =A0debug=3Dn =A0Tainted: =A0 =A0C ]----
> (XEN) CPU: =A0 =A01
> (XEN) RIP: =A0 =A0e008:[<ffff82c480121562>] vcpu_migrate+0x172/0x360
> (XEN) RFLAGS: 0000000000010096 =A0 CONTEXT: hypervisor
> (XEN) rax: 00007d3b7fd17180 =A0 rbx: ffff82c4802e8ee0 =A0 rcx: ffff82c4802e8e=
e0
> (XEN) rdx: ffff83013a3c5068 =A0 rsi: 0000000000000004 =A0 rdi: ffff8301300b7d=
68
> (XEN) rbp: 0000000000000001 =A0 rsp: ffff8301300b7e28 =A0 r8: =A000000000000000=
00
> (XEN) r9: =A0000000000000003e =A0 r10: 000000000000003e =A0 r11: 00000000000002=
46
> (XEN) r12: ffff83013a3c5068 =A0 r13: ffff83013a3c5068 =A0 r14: ffff82c4802d31=
40
> (XEN) r15: 0000000000000001 =A0 cr0: 000000008005003b =A0 cr4: 00000000000026=
f0
> (XEN) cr3: 0000000131a05000 =A0 cr2: 0000000000000060
> (XEN) ds: 002b =A0 es: 002b =A0 fs: 0000 =A0 gs: 0000 =A0 ss: e010 =A0 cs: e008
> (XEN) Xen stack trace from rsp=3Dffff8301300b7e28:
> (XEN) =A0 =A0ffff82c4802d3140 ffff83013a3c5068 0000000000000246 0000000000000=
004
> (XEN) =A0 =A0ffff8300bd2fe000 ffff82c4802e8ee0 00000004012d3140 ffff82c4802e8=
ee0
> (XEN) =A0 =A0ffff88003fc8e820 ffff8300bd2fe000 ffff8301355d8000 0000000000000=
000
> (XEN) =A0 =A00000000000000000 0000000000000000 ffff88003fc8e820 ffff82c480105=
a50
> (XEN) =A0 =A00000000000000000 ffff82c4801805ec 0000060f00000000 ffff82c480184=
f16
> (XEN) =A0 =A00000000000000032 78a20f6e65780b0f ffff88003976fdc8 ffff8300bd2fe=
000
> (XEN) =A0 =A0ffff88003976fe50 ffff8300bd2fe000 ffff88003976fda0 0000000000000=
001
> (XEN) =A0 =A00000000000000000 ffff82c480214288 ffff88003fc8e820 0000000000000=
000
> (XEN) =A0 =A00000000000000000 0000000000000001 ffff88003976fda0 ffff88003fc8b=
dc0
> (XEN) =A0 =A00000000000000246 ffff88003976fe60 00000000ffffffff 0000000000000=
000
> (XEN) =A0 =A00000000000000018 ffffffff8100130a 0000000000000000 0000000000000=
001
> (XEN) =A0 =A00000000000000007 0000010000000000 ffffffff8100130a 000000000000e=
033
> (XEN) =A0 =A00000000000000246 ffff88003976fd88 000000000000e02b d43d5f3fedaef=
5e7
> (XEN) =A0 =A0d3b2ddaeed5038ff 270adb813ad76c9b ddfd6ff5f85e6775 b5881cbf00000=
001
> (XEN) =A0 =A0ffff8300bd2fe000 0000003cba0dc180 0a109ac649c118a1
> (XEN) Xen call trace:
> (XEN) =A0 =A0[<ffff82c480121562>] vcpu_migrate+0x172/0x360
> (XEN) =A0 =A0[<ffff82c480105a50>] do_vcpu_op+0x1e0/0x4a0
> (XEN) =A0 =A0[<ffff82c4801805ec>] do_invalid_op+0x19c/0x3f0
> (XEN) =A0 =A0[<ffff82c480184f16>] copy_from_user+0x26/0x90
> (XEN) =A0 =A0[<ffff82c480214288>] syscall_enter+0x88/0x8d
> (XEN) =A0 =A0
> (XEN) Pagetable walk from 0000000000000060:
> (XEN) =A0L4[0x000] =3D 0000000000000000 ffffffffffffffff
> (XEN)=A0
> (XEN) ****************************************
> (XEN) Panic on CPU 1:
> (XEN) FATAL PAGE FAULT
> (XEN) [error_code=3D0000]
> (XEN) Faulting linear address: 0000000000000060
> (XEN) ****************************************
> (XEN)=A0
> (XEN) Reboot in five seconds...
>=20
>=20
> On Mon, Sep 24, 2012 at 10:28 AM, Jan Beulich <JBeulich@suse.com> wrote:
>>>>> >>> On 24.09.12 at 16:16, Ben Guthro <ben@guthro.net> wrote:
>>> > Would you prefer a separate [PATCH] email for this fix, or will you a=
pply
>>> > it as-is?
>>=20
>> I'll put something together - the most important thing here obviously
>> is having a proper description. Plus I'd like to slightly extend this an=
d
>> have acpi_dead_idle() actually use default_dead_idle(), just to have
>> things consolidated in one place. I assume I can put your S-o-b on
>> what you sent...
>>=20
>> Jan
>>=20
>>> > On Mon, Sep 24, 2012 at 10:10 AM, Jan Beulich <JBeulich@suse.com> wro=
te:
>>> >
>>>>>>> >> >>> On 24.09.12 at 15:56, Ben Guthro <ben@guthro.net> wrote:
>>>>> >> > On Mon, Sep 24, 2012 at 9:34 AM, Jan Beulich <JBeulich@suse.com>
>>>>> wrote:
>>>>>> >> >> ...; the interesting ones are
>>>>>> >> >> - at the end of xen/arch/x86/acpu/cpu_idle.c:acpi_dead_idle()
>>>>>> >> >> - xen/arch/x86/domain.c:default_dead_idle()
>>>>> >> >
>>>>> >> >
>>>>> >> > Thanks! This fixes the issue on this machine!
>>>> >>
>>>> >> Hooray!
>>>> >>
>>>>> >> > Is this a reasonable long-term solution - or are there reasons n=
ot to
>>>>> >> > call wbinvd() here?
>>>> >>
>>>> >> That's a perfectly valid adjustment (see my earlier reply where
>>>> >> I originally suggested it and explained why it may be necessary).
>>>> >>
>>>> >> Jan
>>>> >>
>>>> >>
>>=20
>>=20
>>=20
>=20
>=20
>=20
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel


--B_3431367022_80686359
Content-type: text/html;
	charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable

<HTML>
<HEAD>
<TITLE>Re: [Xen-devel] Xen4.2 S3 regression?</TITLE>
</HEAD>
<BODY>
<FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN STYLE=3D'font-size:11pt=
'>Do a debug build so the backtrace can be trusted. It&#8217;s a NULL pointe=
r dereference so shouldn&#8217;t be too tricky to make some headway on this =
one. Easier than the previous bug. :)<BR>
<BR>
&nbsp;-- Keir<BR>
<BR>
On 24/09/2012 20:02, &quot;Ben Guthro&quot; &lt;<a href=3D"ben@guthro.net">be=
n@guthro.net</a>&gt; wrote:<BR>
<BR>
</SPAN></FONT><BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><=
SPAN STYLE=3D'font-size:11pt'>Well...knock one bug down - and another crops up=
.<BR>
<BR>
It appears that dom0_vcpu_pin is incompatible with S3.<BR>
I'll start digging into why, but if you have any thoughts from the stack be=
low, I'd welcome any pointers.<BR>
<BR>
/btg<BR>
<BR>
<BR>
(XEN) Preparing system for ACPI S3 state.<BR>
(XEN) Disabling non-boot CPUs ...<BR>
(XEN) Entering ACPI S3 state.<BR>
(XEN) mce_intel.c:1239: MCA Capability: BCAST 1 SER 0 CMCI 0 firstbank 1 ex=
tended MCE MSR 0<BR>
(XEN) CMCI: CPU0 has no CMCI support<BR>
(XEN) CPU0: Thermal monitoring enabled (TM2)<BR>
(XEN) Finishing wakeup from ACPI S3 state.<BR>
(XEN) Enabling non-boot CPUs =A0...<BR>
(XEN) Booting processor 1/1 eip 8a000<BR>
(XEN) Initializing CPU#1<BR>
(XEN) CPU: L1 I cache: 32K, L1 D cache: 32K<BR>
(XEN) CPU: L2 cache: 3072K<BR>
(XEN) CPU: Physical Processor ID: 0<BR>
(XEN) CPU: Processor Core ID: 1<BR>
(XEN) CMCI: CPU1 has no CMCI support<BR>
(XEN) CPU1: Thermal monitoring enabled (TM2)<BR>
(XEN) CPU1: Intel(R) Core(TM)2 Duo CPU =A0 =A0 P8400 =A0@ 2.26GHz stepping 06<BR>
(XEN) microcode: CPU1 updated from revision 0x60c to 0x60f, date =3D 2010-09-=
29=A0<BR>
[ =A0 60.100054] ACPI: Low-level resume complete<BR>
[ =A0 60.100054] PM: Restoring platform NVS memory<BR>
[ =A0 60.100054] Enabling non-boot CPUs ...<BR>
[ =A0 60.100054] installing Xen timer for CPU 1<BR>
[ =A0 60.100054] cpu 1 spinlock event irq 279<BR>
(XEN) ----[ Xen-4.2.1-pre =A0x86_64 =A0debug=3Dn =A0Tainted: =A0 =A0C ]----<BR>
(XEN) CPU: =A0 =A01<BR>
(XEN) RIP: =A0 =A0e008:[&lt;ffff82c480121562&gt;] vcpu_migrate+0x172/0x360<BR>
(XEN) RFLAGS: 0000000000010096 =A0 CONTEXT: hypervisor<BR>
(XEN) rax: 00007d3b7fd17180 =A0 rbx: ffff82c4802e8ee0 =A0 rcx: ffff82c4802e8ee0=
<BR>
(XEN) rdx: ffff83013a3c5068 =A0 rsi: 0000000000000004 =A0 rdi: ffff8301300b7d68=
<BR>
(XEN) rbp: 0000000000000001 =A0 rsp: ffff8301300b7e28 =A0 r8: =A00000000000000000=
<BR>
(XEN) r9: =A0000000000000003e =A0 r10: 000000000000003e =A0 r11: 0000000000000246=
<BR>
(XEN) r12: ffff83013a3c5068 =A0 r13: ffff83013a3c5068 =A0 r14: ffff82c4802d3140=
<BR>
(XEN) r15: 0000000000000001 =A0 cr0: 000000008005003b =A0 cr4: 00000000000026f0=
<BR>
(XEN) cr3: 0000000131a05000 =A0 cr2: 0000000000000060<BR>
(XEN) ds: 002b =A0 es: 002b =A0 fs: 0000 =A0 gs: 0000 =A0 ss: e010 =A0 cs: e008<BR>
(XEN) Xen stack trace from rsp=3Dffff8301300b7e28:<BR>
(XEN) =A0 =A0ffff82c4802d3140 ffff83013a3c5068 0000000000000246 000000000000000=
4<BR>
(XEN) =A0 =A0ffff8300bd2fe000 ffff82c4802e8ee0 00000004012d3140 ffff82c4802e8ee=
0<BR>
(XEN) =A0 =A0ffff88003fc8e820 ffff8300bd2fe000 ffff8301355d8000 000000000000000=
0<BR>
(XEN) =A0 =A00000000000000000 0000000000000000 ffff88003fc8e820 ffff82c480105a5=
0<BR>
(XEN) =A0 =A00000000000000000 ffff82c4801805ec 0000060f00000000 ffff82c480184f1=
6<BR>
(XEN) =A0 =A00000000000000032 78a20f6e65780b0f ffff88003976fdc8 ffff8300bd2fe00=
0<BR>
(XEN) =A0 =A0ffff88003976fe50 ffff8300bd2fe000 ffff88003976fda0 000000000000000=
1<BR>
(XEN) =A0 =A00000000000000000 ffff82c480214288 ffff88003fc8e820 000000000000000=
0<BR>
(XEN) =A0 =A00000000000000000 0000000000000001 ffff88003976fda0 ffff88003fc8bdc=
0<BR>
(XEN) =A0 =A00000000000000246 ffff88003976fe60 00000000ffffffff 000000000000000=
0<BR>
(XEN) =A0 =A00000000000000018 ffffffff8100130a 0000000000000000 000000000000000=
1<BR>
(XEN) =A0 =A00000000000000007 0000010000000000 ffffffff8100130a 000000000000e03=
3<BR>
(XEN) =A0 =A00000000000000246 ffff88003976fd88 000000000000e02b d43d5f3fedaef5e=
7<BR>
(XEN) =A0 =A0d3b2ddaeed5038ff 270adb813ad76c9b ddfd6ff5f85e6775 b5881cbf0000000=
1<BR>
(XEN) =A0 =A0ffff8300bd2fe000 0000003cba0dc180 0a109ac649c118a1<BR>
(XEN) Xen call trace:<BR>
(XEN) =A0 =A0[&lt;ffff82c480121562&gt;] vcpu_migrate+0x172/0x360<BR>
(XEN) =A0 =A0[&lt;ffff82c480105a50&gt;] do_vcpu_op+0x1e0/0x4a0<BR>
(XEN) =A0 =A0[&lt;ffff82c4801805ec&gt;] do_invalid_op+0x19c/0x3f0<BR>
(XEN) =A0 =A0[&lt;ffff82c480184f16&gt;] copy_from_user+0x26/0x90<BR>
(XEN) =A0 =A0[&lt;ffff82c480214288&gt;] syscall_enter+0x88/0x8d<BR>
(XEN) =A0 =A0<BR>
(XEN) Pagetable walk from 0000000000000060:<BR>
(XEN) =A0L4[0x000] =3D 0000000000000000 ffffffffffffffff<BR>
(XEN)=A0<BR>
(XEN) ****************************************<BR>
(XEN) Panic on CPU 1:<BR>
(XEN) FATAL PAGE FAULT<BR>
(XEN) [error_code=3D0000]<BR>
(XEN) Faulting linear address: 0000000000000060<BR>
(XEN) ****************************************<BR>
(XEN)=A0<BR>
(XEN) Reboot in five seconds...<BR>
<BR>
<BR>
On Mon, Sep 24, 2012 at 10:28 AM, Jan Beulich &lt;<a href=3D"JBeulich@suse.co=
m">JBeulich@suse.com</a>&gt; wrote:<BR>
</SPAN></FONT><BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><=
SPAN STYLE=3D'font-size:11pt'>&gt;&gt;&gt; On 24.09.12 at 16:16, Ben Guthro &l=
t;<a href=3D"ben@guthro.net">ben@guthro.net</a>&gt; wrote:<BR>
&gt; Would you prefer a separate [PATCH] email for this fix, or will you ap=
ply<BR>
&gt; it as-is?<BR>
<BR>
I'll put something together - the most important thing here obviously<BR>
is having a proper description. Plus I'd like to slightly extend this and<B=
R>
have acpi_dead_idle() actually use default_dead_idle(), just to have<BR>
things consolidated in one place. I assume I can put your S-o-b on<BR>
what you sent...<BR>
<FONT COLOR=3D"#888888"><BR>
Jan<BR>
</FONT><BR>
&gt; On Mon, Sep 24, 2012 at 10:10 AM, Jan Beulich &lt;<a href=3D"JBeulich@su=
se.com">JBeulich@suse.com</a>&gt; wrote:<BR>
&gt;<BR>
&gt;&gt; &gt;&gt;&gt; On 24.09.12 at 15:56, Ben Guthro &lt;<a href=3D"ben@gut=
hro.net">ben@guthro.net</a>&gt; wrote:<BR>
&gt;&gt; &gt; On Mon, Sep 24, 2012 at 9:34 AM, Jan Beulich &lt;<a href=3D"JBe=
ulich@suse.com">JBeulich@suse.com</a>&gt; wrote:<BR>
&gt;&gt; &gt;&gt; ...; the interesting ones are<BR>
&gt;&gt; &gt;&gt; - at the end of xen/arch/x86/acpu/cpu_idle.c:acpi_dead_id=
le()<BR>
&gt;&gt; &gt;&gt; - xen/arch/x86/domain.c:default_dead_idle()<BR>
&gt;&gt; &gt;<BR>
&gt;&gt; &gt;<BR>
&gt;&gt; &gt; Thanks! This fixes the issue on this machine!<BR>
&gt;&gt;<BR>
&gt;&gt; Hooray!<BR>
&gt;&gt;<BR>
&gt;&gt; &gt; Is this a reasonable long-term solution - or are there reason=
s not to<BR>
&gt;&gt; &gt; call wbinvd() here?<BR>
&gt;&gt;<BR>
&gt;&gt; That's a perfectly valid adjustment (see my earlier reply where<BR=
>
&gt;&gt; I originally suggested it and explained why it may be necessary).<=
BR>
&gt;&gt;<BR>
&gt;&gt; Jan<BR>
&gt;&gt;<BR>
&gt;&gt;<BR>
<BR>
<BR>
<BR>
</SPAN></FONT></BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial">=
<SPAN STYLE=3D'font-size:11pt'><BR>
<BR>
<HR ALIGN=3DCENTER SIZE=3D"3" WIDTH=3D"95%"></SPAN></FONT><FONT SIZE=3D"2"><FONT FA=
CE=3D"Consolas, Courier New, Courier"><SPAN STYLE=3D'font-size:10pt'>___________=
____________________________________<BR>
Xen-devel mailing list<BR>
<a href=3D"Xen-devel@lists.xen.org">Xen-devel@lists.xen.org</a><BR>
<a href=3D"http://lists.xen.org/xen-devel">http://lists.xen.org/xen-devel</a>=
<BR>
</SPAN></FONT></FONT></BLOCKQUOTE>
</BODY>
</HTML>


--B_3431367022_80686359--




--===============6826780111348703616==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============6826780111348703616==--




From xen-devel-bounces@lists.xen.org Mon Sep 24 20:31:00 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Sep 2012 20:31:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGFIT-0003XK-05; Mon, 24 Sep 2012 20:30:29 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1TGFIR-0003XF-MZ
	for xen-devel@lists.xen.org; Mon, 24 Sep 2012 20:30:28 +0000
Received: from [85.158.138.51:30575] by server-2.bemta-3.messagelabs.com id
	4B/20-04862-2E2C0605; Mon, 24 Sep 2012 20:30:26 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1348518624!31781723!1
X-Originating-IP: [74.125.82.173]
X-SpamReason: No, hits=1.4 required=7.0 tests=HTML_20_30,HTML_MESSAGE,
	MIME_QP_LONG_LINE,ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6188 invoked from network); 24 Sep 2012 20:30:25 -0000
Received: from mail-we0-f173.google.com (HELO mail-we0-f173.google.com)
	(74.125.82.173)
	by server-11.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Sep 2012 20:30:25 -0000
Received: by weyt11 with SMTP id t11so4152815wey.32
	for <xen-devel@lists.xen.org>; Mon, 24 Sep 2012 13:30:24 -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;
	bh=E0LEjfJE3UMyf6sk1jLINrdc/Z8rvXfWm2WZu9T2CI8=;
	b=mgQggR0MvliAQI7sTEzO7TzmPCmrOrEGFYqTPi+WVbgrfyBrjwB2cw65uzAZSgSMXL
	eJS3xMtm0GHXK5K/sEcwcexhkoVXAhl41RcjJVGUcy9y9N06o3F1oBpaOYPkkpHLgSD9
	914Ho+NlCFYmDbD3X4Y7vdSHVDHAjzViU6XgOxrSJCZp44/0jEORjjeEWP0NGsCZx7I2
	Cz/3u5eDyMp2uH+IXwkkJtaJ5i6WTqxl7LgGA6OymUCFfFosGEEi6uUVp1O8B5uq35lj
	Hpof4orQ7wwiM2BCg49Vf8Aew51d1YlK+E9h3hZdxI75GPdPTRBTX9OctcyAt2kRhwGn
	xnwQ==
Received: by 10.180.106.9 with SMTP id gq9mr15762080wib.12.1348518624428;
	Mon, 24 Sep 2012 13:30:24 -0700 (PDT)
Received: from [192.168.1.69] (host86-167-82-156.range86-167.btcentralplus.com.
	[86.167.82.156])
	by mx.google.com with ESMTPS id fr4sm18670638wib.8.2012.09.24.13.30.20
	(version=SSLv3 cipher=OTHER); Mon, 24 Sep 2012 13:30:23 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Mon, 24 Sep 2012 21:30:16 +0100
From: Keir Fraser <keir.xen@gmail.com>
To: Ben Guthro <ben@guthro.net>,
	Jan Beulich <JBeulich@suse.com>
Message-ID: <CC868168.3FD29%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] Xen4.2 S3 regression?
Thread-Index: Ac2ak2gKf4S9Pr2u6USzTFHACYTP5g==
In-Reply-To: <CAOvdn6UCF2A3yP1cqWn=dxwr0ayRbr+rg+xj8META9Dm0+CoNw@mail.gmail.com>
Mime-version: 1.0
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen4.2 S3 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: multipart/mixed; boundary="===============6826780111348703616=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--===============6826780111348703616==
Content-type: multipart/alternative;
	boundary="B_3431367022_80686359"

> This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--B_3431367022_80686359
Content-type: text/plain;
	charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable

Do a debug build so the backtrace can be trusted. It=B9s a NULL pointer
dereference so shouldn=B9t be too tricky to make some headway on this one.
Easier than the previous bug. :)

 -- Keir

On 24/09/2012 20:02, "Ben Guthro" <ben@guthro.net> wrote:

> Well...knock one bug down - and another crops up.
>=20
> It appears that dom0_vcpu_pin is incompatible with S3.
> I'll start digging into why, but if you have any thoughts from the stack
> below, I'd welcome any pointers.
>=20
> /btg
>=20
>=20
> (XEN) Preparing system for ACPI S3 state.
> (XEN) Disabling non-boot CPUs ...
> (XEN) Entering ACPI S3 state.
> (XEN) mce_intel.c:1239: MCA Capability: BCAST 1 SER 0 CMCI 0 firstbank 1
> extended MCE MSR 0
> (XEN) CMCI: CPU0 has no CMCI support
> (XEN) CPU0: Thermal monitoring enabled (TM2)
> (XEN) Finishing wakeup from ACPI S3 state.
> (XEN) Enabling non-boot CPUs =A0...
> (XEN) Booting processor 1/1 eip 8a000
> (XEN) Initializing CPU#1
> (XEN) CPU: L1 I cache: 32K, L1 D cache: 32K
> (XEN) CPU: L2 cache: 3072K
> (XEN) CPU: Physical Processor ID: 0
> (XEN) CPU: Processor Core ID: 1
> (XEN) CMCI: CPU1 has no CMCI support
> (XEN) CPU1: Thermal monitoring enabled (TM2)
> (XEN) CPU1: Intel(R) Core(TM)2 Duo CPU =A0 =A0 P8400 =A0@ 2.26GHz stepping 06
> (XEN) microcode: CPU1 updated from revision 0x60c to 0x60f, date =3D 2010-0=
9-29=A0
> [ =A0 60.100054] ACPI: Low-level resume complete
> [ =A0 60.100054] PM: Restoring platform NVS memory
> [ =A0 60.100054] Enabling non-boot CPUs ...
> [ =A0 60.100054] installing Xen timer for CPU 1
> [ =A0 60.100054] cpu 1 spinlock event irq 279
> (XEN) ----[ Xen-4.2.1-pre =A0x86_64 =A0debug=3Dn =A0Tainted: =A0 =A0C ]----
> (XEN) CPU: =A0 =A01
> (XEN) RIP: =A0 =A0e008:[<ffff82c480121562>] vcpu_migrate+0x172/0x360
> (XEN) RFLAGS: 0000000000010096 =A0 CONTEXT: hypervisor
> (XEN) rax: 00007d3b7fd17180 =A0 rbx: ffff82c4802e8ee0 =A0 rcx: ffff82c4802e8e=
e0
> (XEN) rdx: ffff83013a3c5068 =A0 rsi: 0000000000000004 =A0 rdi: ffff8301300b7d=
68
> (XEN) rbp: 0000000000000001 =A0 rsp: ffff8301300b7e28 =A0 r8: =A000000000000000=
00
> (XEN) r9: =A0000000000000003e =A0 r10: 000000000000003e =A0 r11: 00000000000002=
46
> (XEN) r12: ffff83013a3c5068 =A0 r13: ffff83013a3c5068 =A0 r14: ffff82c4802d31=
40
> (XEN) r15: 0000000000000001 =A0 cr0: 000000008005003b =A0 cr4: 00000000000026=
f0
> (XEN) cr3: 0000000131a05000 =A0 cr2: 0000000000000060
> (XEN) ds: 002b =A0 es: 002b =A0 fs: 0000 =A0 gs: 0000 =A0 ss: e010 =A0 cs: e008
> (XEN) Xen stack trace from rsp=3Dffff8301300b7e28:
> (XEN) =A0 =A0ffff82c4802d3140 ffff83013a3c5068 0000000000000246 0000000000000=
004
> (XEN) =A0 =A0ffff8300bd2fe000 ffff82c4802e8ee0 00000004012d3140 ffff82c4802e8=
ee0
> (XEN) =A0 =A0ffff88003fc8e820 ffff8300bd2fe000 ffff8301355d8000 0000000000000=
000
> (XEN) =A0 =A00000000000000000 0000000000000000 ffff88003fc8e820 ffff82c480105=
a50
> (XEN) =A0 =A00000000000000000 ffff82c4801805ec 0000060f00000000 ffff82c480184=
f16
> (XEN) =A0 =A00000000000000032 78a20f6e65780b0f ffff88003976fdc8 ffff8300bd2fe=
000
> (XEN) =A0 =A0ffff88003976fe50 ffff8300bd2fe000 ffff88003976fda0 0000000000000=
001
> (XEN) =A0 =A00000000000000000 ffff82c480214288 ffff88003fc8e820 0000000000000=
000
> (XEN) =A0 =A00000000000000000 0000000000000001 ffff88003976fda0 ffff88003fc8b=
dc0
> (XEN) =A0 =A00000000000000246 ffff88003976fe60 00000000ffffffff 0000000000000=
000
> (XEN) =A0 =A00000000000000018 ffffffff8100130a 0000000000000000 0000000000000=
001
> (XEN) =A0 =A00000000000000007 0000010000000000 ffffffff8100130a 000000000000e=
033
> (XEN) =A0 =A00000000000000246 ffff88003976fd88 000000000000e02b d43d5f3fedaef=
5e7
> (XEN) =A0 =A0d3b2ddaeed5038ff 270adb813ad76c9b ddfd6ff5f85e6775 b5881cbf00000=
001
> (XEN) =A0 =A0ffff8300bd2fe000 0000003cba0dc180 0a109ac649c118a1
> (XEN) Xen call trace:
> (XEN) =A0 =A0[<ffff82c480121562>] vcpu_migrate+0x172/0x360
> (XEN) =A0 =A0[<ffff82c480105a50>] do_vcpu_op+0x1e0/0x4a0
> (XEN) =A0 =A0[<ffff82c4801805ec>] do_invalid_op+0x19c/0x3f0
> (XEN) =A0 =A0[<ffff82c480184f16>] copy_from_user+0x26/0x90
> (XEN) =A0 =A0[<ffff82c480214288>] syscall_enter+0x88/0x8d
> (XEN) =A0 =A0
> (XEN) Pagetable walk from 0000000000000060:
> (XEN) =A0L4[0x000] =3D 0000000000000000 ffffffffffffffff
> (XEN)=A0
> (XEN) ****************************************
> (XEN) Panic on CPU 1:
> (XEN) FATAL PAGE FAULT
> (XEN) [error_code=3D0000]
> (XEN) Faulting linear address: 0000000000000060
> (XEN) ****************************************
> (XEN)=A0
> (XEN) Reboot in five seconds...
>=20
>=20
> On Mon, Sep 24, 2012 at 10:28 AM, Jan Beulich <JBeulich@suse.com> wrote:
>>>>> >>> On 24.09.12 at 16:16, Ben Guthro <ben@guthro.net> wrote:
>>> > Would you prefer a separate [PATCH] email for this fix, or will you a=
pply
>>> > it as-is?
>>=20
>> I'll put something together - the most important thing here obviously
>> is having a proper description. Plus I'd like to slightly extend this an=
d
>> have acpi_dead_idle() actually use default_dead_idle(), just to have
>> things consolidated in one place. I assume I can put your S-o-b on
>> what you sent...
>>=20
>> Jan
>>=20
>>> > On Mon, Sep 24, 2012 at 10:10 AM, Jan Beulich <JBeulich@suse.com> wro=
te:
>>> >
>>>>>>> >> >>> On 24.09.12 at 15:56, Ben Guthro <ben@guthro.net> wrote:
>>>>> >> > On Mon, Sep 24, 2012 at 9:34 AM, Jan Beulich <JBeulich@suse.com>
>>>>> wrote:
>>>>>> >> >> ...; the interesting ones are
>>>>>> >> >> - at the end of xen/arch/x86/acpu/cpu_idle.c:acpi_dead_idle()
>>>>>> >> >> - xen/arch/x86/domain.c:default_dead_idle()
>>>>> >> >
>>>>> >> >
>>>>> >> > Thanks! This fixes the issue on this machine!
>>>> >>
>>>> >> Hooray!
>>>> >>
>>>>> >> > Is this a reasonable long-term solution - or are there reasons n=
ot to
>>>>> >> > call wbinvd() here?
>>>> >>
>>>> >> That's a perfectly valid adjustment (see my earlier reply where
>>>> >> I originally suggested it and explained why it may be necessary).
>>>> >>
>>>> >> Jan
>>>> >>
>>>> >>
>>=20
>>=20
>>=20
>=20
>=20
>=20
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel


--B_3431367022_80686359
Content-type: text/html;
	charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable

<HTML>
<HEAD>
<TITLE>Re: [Xen-devel] Xen4.2 S3 regression?</TITLE>
</HEAD>
<BODY>
<FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN STYLE=3D'font-size:11pt=
'>Do a debug build so the backtrace can be trusted. It&#8217;s a NULL pointe=
r dereference so shouldn&#8217;t be too tricky to make some headway on this =
one. Easier than the previous bug. :)<BR>
<BR>
&nbsp;-- Keir<BR>
<BR>
On 24/09/2012 20:02, &quot;Ben Guthro&quot; &lt;<a href=3D"ben@guthro.net">be=
n@guthro.net</a>&gt; wrote:<BR>
<BR>
</SPAN></FONT><BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><=
SPAN STYLE=3D'font-size:11pt'>Well...knock one bug down - and another crops up=
.<BR>
<BR>
It appears that dom0_vcpu_pin is incompatible with S3.<BR>
I'll start digging into why, but if you have any thoughts from the stack be=
low, I'd welcome any pointers.<BR>
<BR>
/btg<BR>
<BR>
<BR>
(XEN) Preparing system for ACPI S3 state.<BR>
(XEN) Disabling non-boot CPUs ...<BR>
(XEN) Entering ACPI S3 state.<BR>
(XEN) mce_intel.c:1239: MCA Capability: BCAST 1 SER 0 CMCI 0 firstbank 1 ex=
tended MCE MSR 0<BR>
(XEN) CMCI: CPU0 has no CMCI support<BR>
(XEN) CPU0: Thermal monitoring enabled (TM2)<BR>
(XEN) Finishing wakeup from ACPI S3 state.<BR>
(XEN) Enabling non-boot CPUs =A0...<BR>
(XEN) Booting processor 1/1 eip 8a000<BR>
(XEN) Initializing CPU#1<BR>
(XEN) CPU: L1 I cache: 32K, L1 D cache: 32K<BR>
(XEN) CPU: L2 cache: 3072K<BR>
(XEN) CPU: Physical Processor ID: 0<BR>
(XEN) CPU: Processor Core ID: 1<BR>
(XEN) CMCI: CPU1 has no CMCI support<BR>
(XEN) CPU1: Thermal monitoring enabled (TM2)<BR>
(XEN) CPU1: Intel(R) Core(TM)2 Duo CPU =A0 =A0 P8400 =A0@ 2.26GHz stepping 06<BR>
(XEN) microcode: CPU1 updated from revision 0x60c to 0x60f, date =3D 2010-09-=
29=A0<BR>
[ =A0 60.100054] ACPI: Low-level resume complete<BR>
[ =A0 60.100054] PM: Restoring platform NVS memory<BR>
[ =A0 60.100054] Enabling non-boot CPUs ...<BR>
[ =A0 60.100054] installing Xen timer for CPU 1<BR>
[ =A0 60.100054] cpu 1 spinlock event irq 279<BR>
(XEN) ----[ Xen-4.2.1-pre =A0x86_64 =A0debug=3Dn =A0Tainted: =A0 =A0C ]----<BR>
(XEN) CPU: =A0 =A01<BR>
(XEN) RIP: =A0 =A0e008:[&lt;ffff82c480121562&gt;] vcpu_migrate+0x172/0x360<BR>
(XEN) RFLAGS: 0000000000010096 =A0 CONTEXT: hypervisor<BR>
(XEN) rax: 00007d3b7fd17180 =A0 rbx: ffff82c4802e8ee0 =A0 rcx: ffff82c4802e8ee0=
<BR>
(XEN) rdx: ffff83013a3c5068 =A0 rsi: 0000000000000004 =A0 rdi: ffff8301300b7d68=
<BR>
(XEN) rbp: 0000000000000001 =A0 rsp: ffff8301300b7e28 =A0 r8: =A00000000000000000=
<BR>
(XEN) r9: =A0000000000000003e =A0 r10: 000000000000003e =A0 r11: 0000000000000246=
<BR>
(XEN) r12: ffff83013a3c5068 =A0 r13: ffff83013a3c5068 =A0 r14: ffff82c4802d3140=
<BR>
(XEN) r15: 0000000000000001 =A0 cr0: 000000008005003b =A0 cr4: 00000000000026f0=
<BR>
(XEN) cr3: 0000000131a05000 =A0 cr2: 0000000000000060<BR>
(XEN) ds: 002b =A0 es: 002b =A0 fs: 0000 =A0 gs: 0000 =A0 ss: e010 =A0 cs: e008<BR>
(XEN) Xen stack trace from rsp=3Dffff8301300b7e28:<BR>
(XEN) =A0 =A0ffff82c4802d3140 ffff83013a3c5068 0000000000000246 000000000000000=
4<BR>
(XEN) =A0 =A0ffff8300bd2fe000 ffff82c4802e8ee0 00000004012d3140 ffff82c4802e8ee=
0<BR>
(XEN) =A0 =A0ffff88003fc8e820 ffff8300bd2fe000 ffff8301355d8000 000000000000000=
0<BR>
(XEN) =A0 =A00000000000000000 0000000000000000 ffff88003fc8e820 ffff82c480105a5=
0<BR>
(XEN) =A0 =A00000000000000000 ffff82c4801805ec 0000060f00000000 ffff82c480184f1=
6<BR>
(XEN) =A0 =A00000000000000032 78a20f6e65780b0f ffff88003976fdc8 ffff8300bd2fe00=
0<BR>
(XEN) =A0 =A0ffff88003976fe50 ffff8300bd2fe000 ffff88003976fda0 000000000000000=
1<BR>
(XEN) =A0 =A00000000000000000 ffff82c480214288 ffff88003fc8e820 000000000000000=
0<BR>
(XEN) =A0 =A00000000000000000 0000000000000001 ffff88003976fda0 ffff88003fc8bdc=
0<BR>
(XEN) =A0 =A00000000000000246 ffff88003976fe60 00000000ffffffff 000000000000000=
0<BR>
(XEN) =A0 =A00000000000000018 ffffffff8100130a 0000000000000000 000000000000000=
1<BR>
(XEN) =A0 =A00000000000000007 0000010000000000 ffffffff8100130a 000000000000e03=
3<BR>
(XEN) =A0 =A00000000000000246 ffff88003976fd88 000000000000e02b d43d5f3fedaef5e=
7<BR>
(XEN) =A0 =A0d3b2ddaeed5038ff 270adb813ad76c9b ddfd6ff5f85e6775 b5881cbf0000000=
1<BR>
(XEN) =A0 =A0ffff8300bd2fe000 0000003cba0dc180 0a109ac649c118a1<BR>
(XEN) Xen call trace:<BR>
(XEN) =A0 =A0[&lt;ffff82c480121562&gt;] vcpu_migrate+0x172/0x360<BR>
(XEN) =A0 =A0[&lt;ffff82c480105a50&gt;] do_vcpu_op+0x1e0/0x4a0<BR>
(XEN) =A0 =A0[&lt;ffff82c4801805ec&gt;] do_invalid_op+0x19c/0x3f0<BR>
(XEN) =A0 =A0[&lt;ffff82c480184f16&gt;] copy_from_user+0x26/0x90<BR>
(XEN) =A0 =A0[&lt;ffff82c480214288&gt;] syscall_enter+0x88/0x8d<BR>
(XEN) =A0 =A0<BR>
(XEN) Pagetable walk from 0000000000000060:<BR>
(XEN) =A0L4[0x000] =3D 0000000000000000 ffffffffffffffff<BR>
(XEN)=A0<BR>
(XEN) ****************************************<BR>
(XEN) Panic on CPU 1:<BR>
(XEN) FATAL PAGE FAULT<BR>
(XEN) [error_code=3D0000]<BR>
(XEN) Faulting linear address: 0000000000000060<BR>
(XEN) ****************************************<BR>
(XEN)=A0<BR>
(XEN) Reboot in five seconds...<BR>
<BR>
<BR>
On Mon, Sep 24, 2012 at 10:28 AM, Jan Beulich &lt;<a href=3D"JBeulich@suse.co=
m">JBeulich@suse.com</a>&gt; wrote:<BR>
</SPAN></FONT><BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><=
SPAN STYLE=3D'font-size:11pt'>&gt;&gt;&gt; On 24.09.12 at 16:16, Ben Guthro &l=
t;<a href=3D"ben@guthro.net">ben@guthro.net</a>&gt; wrote:<BR>
&gt; Would you prefer a separate [PATCH] email for this fix, or will you ap=
ply<BR>
&gt; it as-is?<BR>
<BR>
I'll put something together - the most important thing here obviously<BR>
is having a proper description. Plus I'd like to slightly extend this and<B=
R>
have acpi_dead_idle() actually use default_dead_idle(), just to have<BR>
things consolidated in one place. I assume I can put your S-o-b on<BR>
what you sent...<BR>
<FONT COLOR=3D"#888888"><BR>
Jan<BR>
</FONT><BR>
&gt; On Mon, Sep 24, 2012 at 10:10 AM, Jan Beulich &lt;<a href=3D"JBeulich@su=
se.com">JBeulich@suse.com</a>&gt; wrote:<BR>
&gt;<BR>
&gt;&gt; &gt;&gt;&gt; On 24.09.12 at 15:56, Ben Guthro &lt;<a href=3D"ben@gut=
hro.net">ben@guthro.net</a>&gt; wrote:<BR>
&gt;&gt; &gt; On Mon, Sep 24, 2012 at 9:34 AM, Jan Beulich &lt;<a href=3D"JBe=
ulich@suse.com">JBeulich@suse.com</a>&gt; wrote:<BR>
&gt;&gt; &gt;&gt; ...; the interesting ones are<BR>
&gt;&gt; &gt;&gt; - at the end of xen/arch/x86/acpu/cpu_idle.c:acpi_dead_id=
le()<BR>
&gt;&gt; &gt;&gt; - xen/arch/x86/domain.c:default_dead_idle()<BR>
&gt;&gt; &gt;<BR>
&gt;&gt; &gt;<BR>
&gt;&gt; &gt; Thanks! This fixes the issue on this machine!<BR>
&gt;&gt;<BR>
&gt;&gt; Hooray!<BR>
&gt;&gt;<BR>
&gt;&gt; &gt; Is this a reasonable long-term solution - or are there reason=
s not to<BR>
&gt;&gt; &gt; call wbinvd() here?<BR>
&gt;&gt;<BR>
&gt;&gt; That's a perfectly valid adjustment (see my earlier reply where<BR=
>
&gt;&gt; I originally suggested it and explained why it may be necessary).<=
BR>
&gt;&gt;<BR>
&gt;&gt; Jan<BR>
&gt;&gt;<BR>
&gt;&gt;<BR>
<BR>
<BR>
<BR>
</SPAN></FONT></BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial">=
<SPAN STYLE=3D'font-size:11pt'><BR>
<BR>
<HR ALIGN=3DCENTER SIZE=3D"3" WIDTH=3D"95%"></SPAN></FONT><FONT SIZE=3D"2"><FONT FA=
CE=3D"Consolas, Courier New, Courier"><SPAN STYLE=3D'font-size:10pt'>___________=
____________________________________<BR>
Xen-devel mailing list<BR>
<a href=3D"Xen-devel@lists.xen.org">Xen-devel@lists.xen.org</a><BR>
<a href=3D"http://lists.xen.org/xen-devel">http://lists.xen.org/xen-devel</a>=
<BR>
</SPAN></FONT></FONT></BLOCKQUOTE>
</BODY>
</HTML>


--B_3431367022_80686359--




--===============6826780111348703616==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============6826780111348703616==--




From xen-devel-bounces@lists.xen.org Mon Sep 24 20:47:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Sep 2012 20: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 1TGFYR-0003l8-Ji; Mon, 24 Sep 2012 20:46:59 +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 1TGFYP-0003kp-Sm
	for xen-devel@lists.xen.org; Mon, 24 Sep 2012 20:46:58 +0000
Received: from [85.158.143.35:7370] by server-2.bemta-4.messagelabs.com id
	A0/C3-06610-1C6C0605; Mon, 24 Sep 2012 20:46:57 +0000
X-Env-Sender: ben.guthro@gmail.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1348519614!8694391!1
X-Originating-IP: [209.85.212.45]
X-SpamReason: No, hits=2.0 required=7.0 tests=HTML_20_30,HTML_MESSAGE,
	RCVD_BY_IP,USERPASS
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2732 invoked from network); 24 Sep 2012 20:46:55 -0000
Received: from mail-vb0-f45.google.com (HELO mail-vb0-f45.google.com)
	(209.85.212.45)
	by server-2.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Sep 2012 20:46:55 -0000
Received: by vbip1 with SMTP id p1so7963066vbi.32
	for <xen-devel@lists.xen.org>; Mon, 24 Sep 2012 13:46: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;
	bh=reh+U9HPW8lmwhxuZ5fZ7svj8TKegB7c1pJWgnVMOig=;
	b=bMTvj2KJlOUMDZJJlnhvfZ0PDnAd5umgvbRUtitkZcJHuhm05KwC7pP38wltiOfxlo
	p/ZeL1z5eZsogUMtB6oDJyKPNATCUDpS75e+SU0OX9aCQk++WSMYWkQaoCvnCMkv5Hoy
	+l8tdhNfHKqist01vYZQIwQCYOHAG/jGZ8jafyMVc23LBJj8qHT42321XDCgeTmf/AYr
	D36ECiuVOjQmlCKNtv0HZYGZliAyMQIK9Yx+7xNrOUWseuhOjeh1nn4YtKkR5yO1uid9
	7CijcW0ZiSUL/TAVne9rP+ydtm0xEklM4fYVMkJubSVCVlS9aN+dwOpfKbRENwZm3s8q
	U4KQ==
MIME-Version: 1.0
Received: by 10.52.150.84 with SMTP id ug20mr1971411vdb.16.1348519614274; Mon,
	24 Sep 2012 13:46:54 -0700 (PDT)
Received: by 10.58.137.169 with HTTP; Mon, 24 Sep 2012 13:46:54 -0700 (PDT)
In-Reply-To: <CC868168.3FD29%keir.xen@gmail.com>
References: <CAOvdn6UCF2A3yP1cqWn=dxwr0ayRbr+rg+xj8META9Dm0+CoNw@mail.gmail.com>
	<CC868168.3FD29%keir.xen@gmail.com>
Date: Mon, 24 Sep 2012 16:46:54 -0400
X-Google-Sender-Auth: dpJ8zH5Ye1s6sFrfaA5LDeNXBEo
Message-ID: <CAOvdn6U-JyLvt96gkLkqzi088tU9_ktv4D+fkJac_BKVe05Y-w@mail.gmail.com>
From: Ben Guthro <ben@guthro.net>
To: Keir Fraser <keir.xen@gmail.com>
Cc: Jan Beulich <JBeulich@suse.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen4.2 S3 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: multipart/mixed; boundary="===============7576102220054106408=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============7576102220054106408==
Content-Type: multipart/alternative; boundary=bcaec51b9c7394dc4604ca78b0e1

--bcaec51b9c7394dc4604ca78b0e1
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

I've managed to determine that _csched_cpu_pick is, for reasons not yet
clear, picking a cpu id outside of the range of cpus that are valid for
this system
(in this case cpu id 4, on a 2 core machine)



On Mon, Sep 24, 2012 at 4:30 PM, Keir Fraser <keir.xen@gmail.com> wrote:

>  Do a debug build so the backtrace can be trusted. It=92s a NULL pointer
> dereference so shouldn=92t be too tricky to make some headway on this one=
.
> Easier than the previous bug. :)
>
>  -- Keir
>
>
> On 24/09/2012 20:02, "Ben Guthro" <ben@guthro.net> wrote:
>
> Well...knock one bug down - and another crops up.
>
> It appears that dom0_vcpu_pin is incompatible with S3.
> I'll start digging into why, but if you have any thoughts from the stack
> below, I'd welcome any pointers.
>
> /btg
>
>
> (XEN) Preparing system for ACPI S3 state.
> (XEN) Disabling non-boot CPUs ...
> (XEN) Entering ACPI S3 state.
> (XEN) mce_intel.c:1239: MCA Capability: BCAST 1 SER 0 CMCI 0 firstbank 1
> extended MCE MSR 0
> (XEN) CMCI: CPU0 has no CMCI support
> (XEN) CPU0: Thermal monitoring enabled (TM2)
> (XEN) Finishing wakeup from ACPI S3 state.
> (XEN) Enabling non-boot CPUs  ...
> (XEN) Booting processor 1/1 eip 8a000
> (XEN) Initializing CPU#1
> (XEN) CPU: L1 I cache: 32K, L1 D cache: 32K
> (XEN) CPU: L2 cache: 3072K
> (XEN) CPU: Physical Processor ID: 0
> (XEN) CPU: Processor Core ID: 1
> (XEN) CMCI: CPU1 has no CMCI support
> (XEN) CPU1: Thermal monitoring enabled (TM2)
> (XEN) CPU1: Intel(R) Core(TM)2 Duo CPU     P8400  @ 2.26GHz stepping 06
> (XEN) microcode: CPU1 updated from revision 0x60c to 0x60f, date =3D
> 2010-09-29
> [   60.100054] ACPI: Low-level resume complete
> [   60.100054] PM: Restoring platform NVS memory
> [   60.100054] Enabling non-boot CPUs ...
> [   60.100054] installing Xen timer for CPU 1
> [   60.100054] cpu 1 spinlock event irq 279
> (XEN) ----[ Xen-4.2.1-pre  x86_64  debug=3Dn  Tainted:    C ]----
> (XEN) CPU:    1
> (XEN) RIP:    e008:[<ffff82c480121562>] vcpu_migrate+0x172/0x360
> (XEN) RFLAGS: 0000000000010096   CONTEXT: hypervisor
> (XEN) rax: 00007d3b7fd17180   rbx: ffff82c4802e8ee0   rcx: ffff82c4802e8e=
e0
> (XEN) rdx: ffff83013a3c5068   rsi: 0000000000000004   rdi: ffff8301300b7d=
68
> (XEN) rbp: 0000000000000001   rsp: ffff8301300b7e28   r8:  00000000000000=
00
> (XEN) r9:  000000000000003e   r10: 000000000000003e   r11: 00000000000002=
46
> (XEN) r12: ffff83013a3c5068   r13: ffff83013a3c5068   r14: ffff82c4802d31=
40
> (XEN) r15: 0000000000000001   cr0: 000000008005003b   cr4: 00000000000026=
f0
> (XEN) cr3: 0000000131a05000   cr2: 0000000000000060
> (XEN) ds: 002b   es: 002b   fs: 0000   gs: 0000   ss: e010   cs: e008
> (XEN) Xen stack trace from rsp=3Dffff8301300b7e28:
> (XEN)    ffff82c4802d3140 ffff83013a3c5068 0000000000000246
> 0000000000000004
> (XEN)    ffff8300bd2fe000 ffff82c4802e8ee0 00000004012d3140
> ffff82c4802e8ee0
> (XEN)    ffff88003fc8e820 ffff8300bd2fe000 ffff8301355d8000
> 0000000000000000
> (XEN)    0000000000000000 0000000000000000 ffff88003fc8e820
> ffff82c480105a50
> (XEN)    0000000000000000 ffff82c4801805ec 0000060f00000000
> ffff82c480184f16
> (XEN)    0000000000000032 78a20f6e65780b0f ffff88003976fdc8
> ffff8300bd2fe000
> (XEN)    ffff88003976fe50 ffff8300bd2fe000 ffff88003976fda0
> 0000000000000001
> (XEN)    0000000000000000 ffff82c480214288 ffff88003fc8e820
> 0000000000000000
> (XEN)    0000000000000000 0000000000000001 ffff88003976fda0
> ffff88003fc8bdc0
> (XEN)    0000000000000246 ffff88003976fe60 00000000ffffffff
> 0000000000000000
> (XEN)    0000000000000018 ffffffff8100130a 0000000000000000
> 0000000000000001
> (XEN)    0000000000000007 0000010000000000 ffffffff8100130a
> 000000000000e033
> (XEN)    0000000000000246 ffff88003976fd88 000000000000e02b
> d43d5f3fedaef5e7
> (XEN)    d3b2ddaeed5038ff 270adb813ad76c9b ddfd6ff5f85e6775
> b5881cbf00000001
> (XEN)    ffff8300bd2fe000 0000003cba0dc180 0a109ac649c118a1
> (XEN) Xen call trace:
> (XEN)    [<ffff82c480121562>] vcpu_migrate+0x172/0x360
> (XEN)    [<ffff82c480105a50>] do_vcpu_op+0x1e0/0x4a0
> (XEN)    [<ffff82c4801805ec>] do_invalid_op+0x19c/0x3f0
> (XEN)    [<ffff82c480184f16>] copy_from_user+0x26/0x90
> (XEN)    [<ffff82c480214288>] syscall_enter+0x88/0x8d
> (XEN)
> (XEN) Pagetable walk from 0000000000000060:
> (XEN)  L4[0x000] =3D 0000000000000000 ffffffffffffffff
> (XEN)
> (XEN) ****************************************
> (XEN) Panic on CPU 1:
> (XEN) FATAL PAGE FAULT
> (XEN) [error_code=3D0000]
> (XEN) Faulting linear address: 0000000000000060
> (XEN) ****************************************
> (XEN)
> (XEN) Reboot in five seconds...
>
>
> On Mon, Sep 24, 2012 at 10:28 AM, Jan Beulich <JBeulich@suse.com> wrote:
>
> >>> On 24.09.12 at 16:16, Ben Guthro <ben@guthro.net> wrote:
> > Would you prefer a separate [PATCH] email for this fix, or will you app=
ly
> > it as-is?
>
> I'll put something together - the most important thing here obviously
> is having a proper description. Plus I'd like to slightly extend this and
> have acpi_dead_idle() actually use default_dead_idle(), just to have
> things consolidated in one place. I assume I can put your S-o-b on
> what you sent...
>
> Jan
>
> > On Mon, Sep 24, 2012 at 10:10 AM, Jan Beulich <JBeulich@suse.com> wrote=
:
> >
> >> >>> On 24.09.12 at 15:56, Ben Guthro <ben@guthro.net> wrote:
> >> > On Mon, Sep 24, 2012 at 9:34 AM, Jan Beulich <JBeulich@suse.com>
> wrote:
> >> >> ...; the interesting ones are
> >> >> - at the end of xen/arch/x86/acpu/cpu_idle.c:acpi_dead_idle()
> >> >> - xen/arch/x86/domain.c:default_dead_idle()
> >> >
> >> >
> >> > Thanks! This fixes the issue on this machine!
> >>
> >> Hooray!
> >>
> >> > Is this a reasonable long-term solution - or are there reasons not t=
o
> >> > call wbinvd() here?
> >>
> >> That's a perfectly valid adjustment (see my earlier reply where
> >> I originally suggested it and explained why it may be necessary).
> >>
> >> Jan
> >>
> >>
>
>
>
>
>
> ------------------------------
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
>
>

--bcaec51b9c7394dc4604ca78b0e1
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

I&#39;ve managed to determine that _csched_cpu_pick=A0is, for reasons not y=
et clear, picking a cpu id outside of the range of cpus that are valid for =
this system<div>(in this case cpu id 4, on a 2 core machine)</div><div><br>
</div><div><br><br><div class=3D"gmail_quote">On Mon, Sep 24, 2012 at 4:30 =
PM, Keir Fraser <span dir=3D"ltr">&lt;<a href=3D"mailto:keir.xen@gmail.com"=
 target=3D"_blank">keir.xen@gmail.com</a>&gt;</span> wrote:<br><blockquote =
class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid=
;padding-left:1ex">




<div>
<font face=3D"Calibri, Verdana, Helvetica, Arial"><span style=3D"font-size:=
11pt">Do a debug build so the backtrace can be trusted. It=92s a NULL point=
er dereference so shouldn=92t be too tricky to make some headway on this on=
e. Easier than the previous bug. :)<span class=3D"HOEnZb"><font color=3D"#8=
88888"><br>

<br>
=A0-- Keir</font></span><div><div class=3D"h5"><br>
<br>
On 24/09/2012 20:02, &quot;Ben Guthro&quot; &lt;<a href=3D"http://ben@guthr=
o.net" target=3D"_blank">ben@guthro.net</a>&gt; wrote:<br>
<br>
</div></div></span></font><blockquote><div><div class=3D"h5"><font face=3D"=
Calibri, Verdana, Helvetica, Arial"><span style=3D"font-size:11pt">Well...k=
nock one bug down - and another crops up.<br>
<br>
It appears that dom0_vcpu_pin is incompatible with S3.<br>
I&#39;ll start digging into why, but if you have any thoughts from the stac=
k below, I&#39;d welcome any pointers.<br>
<br>
/btg<br>
<br>
<br>
(XEN) Preparing system for ACPI S3 state.<br>
(XEN) Disabling non-boot CPUs ...<br>
(XEN) Entering ACPI S3 state.<br>
(XEN) mce_intel.c:1239: MCA Capability: BCAST 1 SER 0 CMCI 0 firstbank 1 ex=
tended MCE MSR 0<br>
(XEN) CMCI: CPU0 has no CMCI support<br>
(XEN) CPU0: Thermal monitoring enabled (TM2)<br>
(XEN) Finishing wakeup from ACPI S3 state.<br>
(XEN) Enabling non-boot CPUs =A0...<br>
(XEN) Booting processor 1/1 eip 8a000<br>
(XEN) Initializing CPU#1<br>
(XEN) CPU: L1 I cache: 32K, L1 D cache: 32K<br>
(XEN) CPU: L2 cache: 3072K<br>
(XEN) CPU: Physical Processor ID: 0<br>
(XEN) CPU: Processor Core ID: 1<br>
(XEN) CMCI: CPU1 has no CMCI support<br>
(XEN) CPU1: Thermal monitoring enabled (TM2)<br>
(XEN) CPU1: Intel(R) Core(TM)2 Duo CPU =A0 =A0 P8400 =A0@ 2.26GHz stepping =
06<br>
(XEN) microcode: CPU1 updated from revision 0x60c to 0x60f, date =3D 2010-0=
9-29=A0<br>
[ =A0 60.100054] ACPI: Low-level resume complete<br>
[ =A0 60.100054] PM: Restoring platform NVS memory<br>
[ =A0 60.100054] Enabling non-boot CPUs ...<br>
[ =A0 60.100054] installing Xen timer for CPU 1<br>
[ =A0 60.100054] cpu 1 spinlock event irq 279<br>
(XEN) ----[ Xen-4.2.1-pre =A0x86_64 =A0debug=3Dn =A0Tainted: =A0 =A0C ]----=
<br>
(XEN) CPU: =A0 =A01<br>
(XEN) RIP: =A0 =A0e008:[&lt;ffff82c480121562&gt;] vcpu_migrate+0x172/0x360<=
br>
(XEN) RFLAGS: 0000000000010096 =A0 CONTEXT: hypervisor<br>
(XEN) rax: 00007d3b7fd17180 =A0 rbx: ffff82c4802e8ee0 =A0 rcx: ffff82c4802e=
8ee0<br>
(XEN) rdx: ffff83013a3c5068 =A0 rsi: 0000000000000004 =A0 rdi: ffff8301300b=
7d68<br>
(XEN) rbp: 0000000000000001 =A0 rsp: ffff8301300b7e28 =A0 r8: =A00000000000=
000000<br>
(XEN) r9: =A0000000000000003e =A0 r10: 000000000000003e =A0 r11: 0000000000=
000246<br>
(XEN) r12: ffff83013a3c5068 =A0 r13: ffff83013a3c5068 =A0 r14: ffff82c4802d=
3140<br>
(XEN) r15: 0000000000000001 =A0 cr0: 000000008005003b =A0 cr4: 000000000000=
26f0<br>
(XEN) cr3: 0000000131a05000 =A0 cr2: 0000000000000060<br>
(XEN) ds: 002b =A0 es: 002b =A0 fs: 0000 =A0 gs: 0000 =A0 ss: e010 =A0 cs: =
e008<br>
(XEN) Xen stack trace from rsp=3Dffff8301300b7e28:<br>
(XEN) =A0 =A0ffff82c4802d3140 ffff83013a3c5068 0000000000000246 00000000000=
00004<br>
(XEN) =A0 =A0ffff8300bd2fe000 ffff82c4802e8ee0 00000004012d3140 ffff82c4802=
e8ee0<br>
(XEN) =A0 =A0ffff88003fc8e820 ffff8300bd2fe000 ffff8301355d8000 00000000000=
00000<br>
(XEN) =A0 =A00000000000000000 0000000000000000 ffff88003fc8e820 ffff82c4801=
05a50<br>
(XEN) =A0 =A00000000000000000 ffff82c4801805ec 0000060f00000000 ffff82c4801=
84f16<br>
(XEN) =A0 =A00000000000000032 78a20f6e65780b0f ffff88003976fdc8 ffff8300bd2=
fe000<br>
(XEN) =A0 =A0ffff88003976fe50 ffff8300bd2fe000 ffff88003976fda0 00000000000=
00001<br>
(XEN) =A0 =A00000000000000000 ffff82c480214288 ffff88003fc8e820 00000000000=
00000<br>
(XEN) =A0 =A00000000000000000 0000000000000001 ffff88003976fda0 ffff88003fc=
8bdc0<br>
(XEN) =A0 =A00000000000000246 ffff88003976fe60 00000000ffffffff 00000000000=
00000<br>
(XEN) =A0 =A00000000000000018 ffffffff8100130a 0000000000000000 00000000000=
00001<br>
(XEN) =A0 =A00000000000000007 0000010000000000 ffffffff8100130a 00000000000=
0e033<br>
(XEN) =A0 =A00000000000000246 ffff88003976fd88 000000000000e02b d43d5f3feda=
ef5e7<br>
(XEN) =A0 =A0d3b2ddaeed5038ff 270adb813ad76c9b ddfd6ff5f85e6775 b5881cbf000=
00001<br>
(XEN) =A0 =A0ffff8300bd2fe000 0000003cba0dc180 0a109ac649c118a1<br>
(XEN) Xen call trace:<br>
(XEN) =A0 =A0[&lt;ffff82c480121562&gt;] vcpu_migrate+0x172/0x360<br>
(XEN) =A0 =A0[&lt;ffff82c480105a50&gt;] do_vcpu_op+0x1e0/0x4a0<br>
(XEN) =A0 =A0[&lt;ffff82c4801805ec&gt;] do_invalid_op+0x19c/0x3f0<br>
(XEN) =A0 =A0[&lt;ffff82c480184f16&gt;] copy_from_user+0x26/0x90<br>
(XEN) =A0 =A0[&lt;ffff82c480214288&gt;] syscall_enter+0x88/0x8d<br>
(XEN) =A0 =A0<br>
(XEN) Pagetable walk from 0000000000000060:<br>
(XEN) =A0L4[0x000] =3D 0000000000000000 ffffffffffffffff<br>
(XEN)=A0<br>
(XEN) ****************************************<br>
(XEN) Panic on CPU 1:<br>
(XEN) FATAL PAGE FAULT<br>
(XEN) [error_code=3D0000]<br>
(XEN) Faulting linear address: 0000000000000060<br>
(XEN) ****************************************<br>
(XEN)=A0<br>
(XEN) Reboot in five seconds...<br>
<br>
<br>
On Mon, Sep 24, 2012 at 10:28 AM, Jan Beulich &lt;<a href=3D"http://JBeulic=
h@suse.com" target=3D"_blank">JBeulich@suse.com</a>&gt; wrote:<br>
</span></font><blockquote><font face=3D"Calibri, Verdana, Helvetica, Arial"=
><span style=3D"font-size:11pt">&gt;&gt;&gt; On 24.09.12 at 16:16, Ben Guth=
ro &lt;<a href=3D"http://ben@guthro.net" target=3D"_blank">ben@guthro.net</=
a>&gt; wrote:<br>

&gt; Would you prefer a separate [PATCH] email for this fix, or will you ap=
ply<br>
&gt; it as-is?<br>
<br>
I&#39;ll put something together - the most important thing here obviously<b=
r>
is having a proper description. Plus I&#39;d like to slightly extend this a=
nd<br>
have acpi_dead_idle() actually use default_dead_idle(), just to have<br>
things consolidated in one place. I assume I can put your S-o-b on<br>
what you sent...<br>
<font color=3D"#888888"><br>
Jan<br>
</font><br>
&gt; On Mon, Sep 24, 2012 at 10:10 AM, Jan Beulich &lt;<a href=3D"http://JB=
eulich@suse.com" target=3D"_blank">JBeulich@suse.com</a>&gt; wrote:<br>
&gt;<br>
&gt;&gt; &gt;&gt;&gt; On 24.09.12 at 15:56, Ben Guthro &lt;<a href=3D"http:=
//ben@guthro.net" target=3D"_blank">ben@guthro.net</a>&gt; wrote:<br>
&gt;&gt; &gt; On Mon, Sep 24, 2012 at 9:34 AM, Jan Beulich &lt;<a href=3D"h=
ttp://JBeulich@suse.com" target=3D"_blank">JBeulich@suse.com</a>&gt; wrote:=
<br>
&gt;&gt; &gt;&gt; ...; the interesting ones are<br>
&gt;&gt; &gt;&gt; - at the end of xen/arch/x86/acpu/cpu_idle.c:acpi_dead_id=
le()<br>
&gt;&gt; &gt;&gt; - xen/arch/x86/domain.c:default_dead_idle()<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; Thanks! This fixes the issue on this machine!<br>
&gt;&gt;<br>
&gt;&gt; Hooray!<br>
&gt;&gt;<br>
&gt;&gt; &gt; Is this a reasonable long-term solution - or are there reason=
s not to<br>
&gt;&gt; &gt; call wbinvd() here?<br>
&gt;&gt;<br>
&gt;&gt; That&#39;s a perfectly valid adjustment (see my earlier reply wher=
e<br>
&gt;&gt; I originally suggested it and explained why it may be necessary).<=
br>
&gt;&gt;<br>
&gt;&gt; Jan<br>
&gt;&gt;<br>
&gt;&gt;<br>
<br>
<br>
<br>
</span></font></blockquote></div></div><font face=3D"Calibri, Verdana, Helv=
etica, Arial"><span style=3D"font-size:11pt"><br>
<br>
<hr align=3D"CENTER" size=3D"3" width=3D"95%"></span></font><div class=3D"i=
m"><font><font face=3D"Consolas, Courier New, Courier"><span style=3D"font-=
size:10pt">_______________________________________________<br>
Xen-devel mailing list<br>
<a href=3D"http://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>
</span></font></font></div></blockquote>
</div>


</blockquote></div><br></div>

--bcaec51b9c7394dc4604ca78b0e1--


--===============7576102220054106408==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============7576102220054106408==--


From xen-devel-bounces@lists.xen.org Mon Sep 24 20:47:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Sep 2012 20: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 1TGFYR-0003l8-Ji; Mon, 24 Sep 2012 20:46:59 +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 1TGFYP-0003kp-Sm
	for xen-devel@lists.xen.org; Mon, 24 Sep 2012 20:46:58 +0000
Received: from [85.158.143.35:7370] by server-2.bemta-4.messagelabs.com id
	A0/C3-06610-1C6C0605; Mon, 24 Sep 2012 20:46:57 +0000
X-Env-Sender: ben.guthro@gmail.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1348519614!8694391!1
X-Originating-IP: [209.85.212.45]
X-SpamReason: No, hits=2.0 required=7.0 tests=HTML_20_30,HTML_MESSAGE,
	RCVD_BY_IP,USERPASS
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2732 invoked from network); 24 Sep 2012 20:46:55 -0000
Received: from mail-vb0-f45.google.com (HELO mail-vb0-f45.google.com)
	(209.85.212.45)
	by server-2.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Sep 2012 20:46:55 -0000
Received: by vbip1 with SMTP id p1so7963066vbi.32
	for <xen-devel@lists.xen.org>; Mon, 24 Sep 2012 13:46: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;
	bh=reh+U9HPW8lmwhxuZ5fZ7svj8TKegB7c1pJWgnVMOig=;
	b=bMTvj2KJlOUMDZJJlnhvfZ0PDnAd5umgvbRUtitkZcJHuhm05KwC7pP38wltiOfxlo
	p/ZeL1z5eZsogUMtB6oDJyKPNATCUDpS75e+SU0OX9aCQk++WSMYWkQaoCvnCMkv5Hoy
	+l8tdhNfHKqist01vYZQIwQCYOHAG/jGZ8jafyMVc23LBJj8qHT42321XDCgeTmf/AYr
	D36ECiuVOjQmlCKNtv0HZYGZliAyMQIK9Yx+7xNrOUWseuhOjeh1nn4YtKkR5yO1uid9
	7CijcW0ZiSUL/TAVne9rP+ydtm0xEklM4fYVMkJubSVCVlS9aN+dwOpfKbRENwZm3s8q
	U4KQ==
MIME-Version: 1.0
Received: by 10.52.150.84 with SMTP id ug20mr1971411vdb.16.1348519614274; Mon,
	24 Sep 2012 13:46:54 -0700 (PDT)
Received: by 10.58.137.169 with HTTP; Mon, 24 Sep 2012 13:46:54 -0700 (PDT)
In-Reply-To: <CC868168.3FD29%keir.xen@gmail.com>
References: <CAOvdn6UCF2A3yP1cqWn=dxwr0ayRbr+rg+xj8META9Dm0+CoNw@mail.gmail.com>
	<CC868168.3FD29%keir.xen@gmail.com>
Date: Mon, 24 Sep 2012 16:46:54 -0400
X-Google-Sender-Auth: dpJ8zH5Ye1s6sFrfaA5LDeNXBEo
Message-ID: <CAOvdn6U-JyLvt96gkLkqzi088tU9_ktv4D+fkJac_BKVe05Y-w@mail.gmail.com>
From: Ben Guthro <ben@guthro.net>
To: Keir Fraser <keir.xen@gmail.com>
Cc: Jan Beulich <JBeulich@suse.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen4.2 S3 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: multipart/mixed; boundary="===============7576102220054106408=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============7576102220054106408==
Content-Type: multipart/alternative; boundary=bcaec51b9c7394dc4604ca78b0e1

--bcaec51b9c7394dc4604ca78b0e1
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

I've managed to determine that _csched_cpu_pick is, for reasons not yet
clear, picking a cpu id outside of the range of cpus that are valid for
this system
(in this case cpu id 4, on a 2 core machine)



On Mon, Sep 24, 2012 at 4:30 PM, Keir Fraser <keir.xen@gmail.com> wrote:

>  Do a debug build so the backtrace can be trusted. It=92s a NULL pointer
> dereference so shouldn=92t be too tricky to make some headway on this one=
.
> Easier than the previous bug. :)
>
>  -- Keir
>
>
> On 24/09/2012 20:02, "Ben Guthro" <ben@guthro.net> wrote:
>
> Well...knock one bug down - and another crops up.
>
> It appears that dom0_vcpu_pin is incompatible with S3.
> I'll start digging into why, but if you have any thoughts from the stack
> below, I'd welcome any pointers.
>
> /btg
>
>
> (XEN) Preparing system for ACPI S3 state.
> (XEN) Disabling non-boot CPUs ...
> (XEN) Entering ACPI S3 state.
> (XEN) mce_intel.c:1239: MCA Capability: BCAST 1 SER 0 CMCI 0 firstbank 1
> extended MCE MSR 0
> (XEN) CMCI: CPU0 has no CMCI support
> (XEN) CPU0: Thermal monitoring enabled (TM2)
> (XEN) Finishing wakeup from ACPI S3 state.
> (XEN) Enabling non-boot CPUs  ...
> (XEN) Booting processor 1/1 eip 8a000
> (XEN) Initializing CPU#1
> (XEN) CPU: L1 I cache: 32K, L1 D cache: 32K
> (XEN) CPU: L2 cache: 3072K
> (XEN) CPU: Physical Processor ID: 0
> (XEN) CPU: Processor Core ID: 1
> (XEN) CMCI: CPU1 has no CMCI support
> (XEN) CPU1: Thermal monitoring enabled (TM2)
> (XEN) CPU1: Intel(R) Core(TM)2 Duo CPU     P8400  @ 2.26GHz stepping 06
> (XEN) microcode: CPU1 updated from revision 0x60c to 0x60f, date =3D
> 2010-09-29
> [   60.100054] ACPI: Low-level resume complete
> [   60.100054] PM: Restoring platform NVS memory
> [   60.100054] Enabling non-boot CPUs ...
> [   60.100054] installing Xen timer for CPU 1
> [   60.100054] cpu 1 spinlock event irq 279
> (XEN) ----[ Xen-4.2.1-pre  x86_64  debug=3Dn  Tainted:    C ]----
> (XEN) CPU:    1
> (XEN) RIP:    e008:[<ffff82c480121562>] vcpu_migrate+0x172/0x360
> (XEN) RFLAGS: 0000000000010096   CONTEXT: hypervisor
> (XEN) rax: 00007d3b7fd17180   rbx: ffff82c4802e8ee0   rcx: ffff82c4802e8e=
e0
> (XEN) rdx: ffff83013a3c5068   rsi: 0000000000000004   rdi: ffff8301300b7d=
68
> (XEN) rbp: 0000000000000001   rsp: ffff8301300b7e28   r8:  00000000000000=
00
> (XEN) r9:  000000000000003e   r10: 000000000000003e   r11: 00000000000002=
46
> (XEN) r12: ffff83013a3c5068   r13: ffff83013a3c5068   r14: ffff82c4802d31=
40
> (XEN) r15: 0000000000000001   cr0: 000000008005003b   cr4: 00000000000026=
f0
> (XEN) cr3: 0000000131a05000   cr2: 0000000000000060
> (XEN) ds: 002b   es: 002b   fs: 0000   gs: 0000   ss: e010   cs: e008
> (XEN) Xen stack trace from rsp=3Dffff8301300b7e28:
> (XEN)    ffff82c4802d3140 ffff83013a3c5068 0000000000000246
> 0000000000000004
> (XEN)    ffff8300bd2fe000 ffff82c4802e8ee0 00000004012d3140
> ffff82c4802e8ee0
> (XEN)    ffff88003fc8e820 ffff8300bd2fe000 ffff8301355d8000
> 0000000000000000
> (XEN)    0000000000000000 0000000000000000 ffff88003fc8e820
> ffff82c480105a50
> (XEN)    0000000000000000 ffff82c4801805ec 0000060f00000000
> ffff82c480184f16
> (XEN)    0000000000000032 78a20f6e65780b0f ffff88003976fdc8
> ffff8300bd2fe000
> (XEN)    ffff88003976fe50 ffff8300bd2fe000 ffff88003976fda0
> 0000000000000001
> (XEN)    0000000000000000 ffff82c480214288 ffff88003fc8e820
> 0000000000000000
> (XEN)    0000000000000000 0000000000000001 ffff88003976fda0
> ffff88003fc8bdc0
> (XEN)    0000000000000246 ffff88003976fe60 00000000ffffffff
> 0000000000000000
> (XEN)    0000000000000018 ffffffff8100130a 0000000000000000
> 0000000000000001
> (XEN)    0000000000000007 0000010000000000 ffffffff8100130a
> 000000000000e033
> (XEN)    0000000000000246 ffff88003976fd88 000000000000e02b
> d43d5f3fedaef5e7
> (XEN)    d3b2ddaeed5038ff 270adb813ad76c9b ddfd6ff5f85e6775
> b5881cbf00000001
> (XEN)    ffff8300bd2fe000 0000003cba0dc180 0a109ac649c118a1
> (XEN) Xen call trace:
> (XEN)    [<ffff82c480121562>] vcpu_migrate+0x172/0x360
> (XEN)    [<ffff82c480105a50>] do_vcpu_op+0x1e0/0x4a0
> (XEN)    [<ffff82c4801805ec>] do_invalid_op+0x19c/0x3f0
> (XEN)    [<ffff82c480184f16>] copy_from_user+0x26/0x90
> (XEN)    [<ffff82c480214288>] syscall_enter+0x88/0x8d
> (XEN)
> (XEN) Pagetable walk from 0000000000000060:
> (XEN)  L4[0x000] =3D 0000000000000000 ffffffffffffffff
> (XEN)
> (XEN) ****************************************
> (XEN) Panic on CPU 1:
> (XEN) FATAL PAGE FAULT
> (XEN) [error_code=3D0000]
> (XEN) Faulting linear address: 0000000000000060
> (XEN) ****************************************
> (XEN)
> (XEN) Reboot in five seconds...
>
>
> On Mon, Sep 24, 2012 at 10:28 AM, Jan Beulich <JBeulich@suse.com> wrote:
>
> >>> On 24.09.12 at 16:16, Ben Guthro <ben@guthro.net> wrote:
> > Would you prefer a separate [PATCH] email for this fix, or will you app=
ly
> > it as-is?
>
> I'll put something together - the most important thing here obviously
> is having a proper description. Plus I'd like to slightly extend this and
> have acpi_dead_idle() actually use default_dead_idle(), just to have
> things consolidated in one place. I assume I can put your S-o-b on
> what you sent...
>
> Jan
>
> > On Mon, Sep 24, 2012 at 10:10 AM, Jan Beulich <JBeulich@suse.com> wrote=
:
> >
> >> >>> On 24.09.12 at 15:56, Ben Guthro <ben@guthro.net> wrote:
> >> > On Mon, Sep 24, 2012 at 9:34 AM, Jan Beulich <JBeulich@suse.com>
> wrote:
> >> >> ...; the interesting ones are
> >> >> - at the end of xen/arch/x86/acpu/cpu_idle.c:acpi_dead_idle()
> >> >> - xen/arch/x86/domain.c:default_dead_idle()
> >> >
> >> >
> >> > Thanks! This fixes the issue on this machine!
> >>
> >> Hooray!
> >>
> >> > Is this a reasonable long-term solution - or are there reasons not t=
o
> >> > call wbinvd() here?
> >>
> >> That's a perfectly valid adjustment (see my earlier reply where
> >> I originally suggested it and explained why it may be necessary).
> >>
> >> Jan
> >>
> >>
>
>
>
>
>
> ------------------------------
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
>
>

--bcaec51b9c7394dc4604ca78b0e1
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

I&#39;ve managed to determine that _csched_cpu_pick=A0is, for reasons not y=
et clear, picking a cpu id outside of the range of cpus that are valid for =
this system<div>(in this case cpu id 4, on a 2 core machine)</div><div><br>
</div><div><br><br><div class=3D"gmail_quote">On Mon, Sep 24, 2012 at 4:30 =
PM, Keir Fraser <span dir=3D"ltr">&lt;<a href=3D"mailto:keir.xen@gmail.com"=
 target=3D"_blank">keir.xen@gmail.com</a>&gt;</span> wrote:<br><blockquote =
class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid=
;padding-left:1ex">




<div>
<font face=3D"Calibri, Verdana, Helvetica, Arial"><span style=3D"font-size:=
11pt">Do a debug build so the backtrace can be trusted. It=92s a NULL point=
er dereference so shouldn=92t be too tricky to make some headway on this on=
e. Easier than the previous bug. :)<span class=3D"HOEnZb"><font color=3D"#8=
88888"><br>

<br>
=A0-- Keir</font></span><div><div class=3D"h5"><br>
<br>
On 24/09/2012 20:02, &quot;Ben Guthro&quot; &lt;<a href=3D"http://ben@guthr=
o.net" target=3D"_blank">ben@guthro.net</a>&gt; wrote:<br>
<br>
</div></div></span></font><blockquote><div><div class=3D"h5"><font face=3D"=
Calibri, Verdana, Helvetica, Arial"><span style=3D"font-size:11pt">Well...k=
nock one bug down - and another crops up.<br>
<br>
It appears that dom0_vcpu_pin is incompatible with S3.<br>
I&#39;ll start digging into why, but if you have any thoughts from the stac=
k below, I&#39;d welcome any pointers.<br>
<br>
/btg<br>
<br>
<br>
(XEN) Preparing system for ACPI S3 state.<br>
(XEN) Disabling non-boot CPUs ...<br>
(XEN) Entering ACPI S3 state.<br>
(XEN) mce_intel.c:1239: MCA Capability: BCAST 1 SER 0 CMCI 0 firstbank 1 ex=
tended MCE MSR 0<br>
(XEN) CMCI: CPU0 has no CMCI support<br>
(XEN) CPU0: Thermal monitoring enabled (TM2)<br>
(XEN) Finishing wakeup from ACPI S3 state.<br>
(XEN) Enabling non-boot CPUs =A0...<br>
(XEN) Booting processor 1/1 eip 8a000<br>
(XEN) Initializing CPU#1<br>
(XEN) CPU: L1 I cache: 32K, L1 D cache: 32K<br>
(XEN) CPU: L2 cache: 3072K<br>
(XEN) CPU: Physical Processor ID: 0<br>
(XEN) CPU: Processor Core ID: 1<br>
(XEN) CMCI: CPU1 has no CMCI support<br>
(XEN) CPU1: Thermal monitoring enabled (TM2)<br>
(XEN) CPU1: Intel(R) Core(TM)2 Duo CPU =A0 =A0 P8400 =A0@ 2.26GHz stepping =
06<br>
(XEN) microcode: CPU1 updated from revision 0x60c to 0x60f, date =3D 2010-0=
9-29=A0<br>
[ =A0 60.100054] ACPI: Low-level resume complete<br>
[ =A0 60.100054] PM: Restoring platform NVS memory<br>
[ =A0 60.100054] Enabling non-boot CPUs ...<br>
[ =A0 60.100054] installing Xen timer for CPU 1<br>
[ =A0 60.100054] cpu 1 spinlock event irq 279<br>
(XEN) ----[ Xen-4.2.1-pre =A0x86_64 =A0debug=3Dn =A0Tainted: =A0 =A0C ]----=
<br>
(XEN) CPU: =A0 =A01<br>
(XEN) RIP: =A0 =A0e008:[&lt;ffff82c480121562&gt;] vcpu_migrate+0x172/0x360<=
br>
(XEN) RFLAGS: 0000000000010096 =A0 CONTEXT: hypervisor<br>
(XEN) rax: 00007d3b7fd17180 =A0 rbx: ffff82c4802e8ee0 =A0 rcx: ffff82c4802e=
8ee0<br>
(XEN) rdx: ffff83013a3c5068 =A0 rsi: 0000000000000004 =A0 rdi: ffff8301300b=
7d68<br>
(XEN) rbp: 0000000000000001 =A0 rsp: ffff8301300b7e28 =A0 r8: =A00000000000=
000000<br>
(XEN) r9: =A0000000000000003e =A0 r10: 000000000000003e =A0 r11: 0000000000=
000246<br>
(XEN) r12: ffff83013a3c5068 =A0 r13: ffff83013a3c5068 =A0 r14: ffff82c4802d=
3140<br>
(XEN) r15: 0000000000000001 =A0 cr0: 000000008005003b =A0 cr4: 000000000000=
26f0<br>
(XEN) cr3: 0000000131a05000 =A0 cr2: 0000000000000060<br>
(XEN) ds: 002b =A0 es: 002b =A0 fs: 0000 =A0 gs: 0000 =A0 ss: e010 =A0 cs: =
e008<br>
(XEN) Xen stack trace from rsp=3Dffff8301300b7e28:<br>
(XEN) =A0 =A0ffff82c4802d3140 ffff83013a3c5068 0000000000000246 00000000000=
00004<br>
(XEN) =A0 =A0ffff8300bd2fe000 ffff82c4802e8ee0 00000004012d3140 ffff82c4802=
e8ee0<br>
(XEN) =A0 =A0ffff88003fc8e820 ffff8300bd2fe000 ffff8301355d8000 00000000000=
00000<br>
(XEN) =A0 =A00000000000000000 0000000000000000 ffff88003fc8e820 ffff82c4801=
05a50<br>
(XEN) =A0 =A00000000000000000 ffff82c4801805ec 0000060f00000000 ffff82c4801=
84f16<br>
(XEN) =A0 =A00000000000000032 78a20f6e65780b0f ffff88003976fdc8 ffff8300bd2=
fe000<br>
(XEN) =A0 =A0ffff88003976fe50 ffff8300bd2fe000 ffff88003976fda0 00000000000=
00001<br>
(XEN) =A0 =A00000000000000000 ffff82c480214288 ffff88003fc8e820 00000000000=
00000<br>
(XEN) =A0 =A00000000000000000 0000000000000001 ffff88003976fda0 ffff88003fc=
8bdc0<br>
(XEN) =A0 =A00000000000000246 ffff88003976fe60 00000000ffffffff 00000000000=
00000<br>
(XEN) =A0 =A00000000000000018 ffffffff8100130a 0000000000000000 00000000000=
00001<br>
(XEN) =A0 =A00000000000000007 0000010000000000 ffffffff8100130a 00000000000=
0e033<br>
(XEN) =A0 =A00000000000000246 ffff88003976fd88 000000000000e02b d43d5f3feda=
ef5e7<br>
(XEN) =A0 =A0d3b2ddaeed5038ff 270adb813ad76c9b ddfd6ff5f85e6775 b5881cbf000=
00001<br>
(XEN) =A0 =A0ffff8300bd2fe000 0000003cba0dc180 0a109ac649c118a1<br>
(XEN) Xen call trace:<br>
(XEN) =A0 =A0[&lt;ffff82c480121562&gt;] vcpu_migrate+0x172/0x360<br>
(XEN) =A0 =A0[&lt;ffff82c480105a50&gt;] do_vcpu_op+0x1e0/0x4a0<br>
(XEN) =A0 =A0[&lt;ffff82c4801805ec&gt;] do_invalid_op+0x19c/0x3f0<br>
(XEN) =A0 =A0[&lt;ffff82c480184f16&gt;] copy_from_user+0x26/0x90<br>
(XEN) =A0 =A0[&lt;ffff82c480214288&gt;] syscall_enter+0x88/0x8d<br>
(XEN) =A0 =A0<br>
(XEN) Pagetable walk from 0000000000000060:<br>
(XEN) =A0L4[0x000] =3D 0000000000000000 ffffffffffffffff<br>
(XEN)=A0<br>
(XEN) ****************************************<br>
(XEN) Panic on CPU 1:<br>
(XEN) FATAL PAGE FAULT<br>
(XEN) [error_code=3D0000]<br>
(XEN) Faulting linear address: 0000000000000060<br>
(XEN) ****************************************<br>
(XEN)=A0<br>
(XEN) Reboot in five seconds...<br>
<br>
<br>
On Mon, Sep 24, 2012 at 10:28 AM, Jan Beulich &lt;<a href=3D"http://JBeulic=
h@suse.com" target=3D"_blank">JBeulich@suse.com</a>&gt; wrote:<br>
</span></font><blockquote><font face=3D"Calibri, Verdana, Helvetica, Arial"=
><span style=3D"font-size:11pt">&gt;&gt;&gt; On 24.09.12 at 16:16, Ben Guth=
ro &lt;<a href=3D"http://ben@guthro.net" target=3D"_blank">ben@guthro.net</=
a>&gt; wrote:<br>

&gt; Would you prefer a separate [PATCH] email for this fix, or will you ap=
ply<br>
&gt; it as-is?<br>
<br>
I&#39;ll put something together - the most important thing here obviously<b=
r>
is having a proper description. Plus I&#39;d like to slightly extend this a=
nd<br>
have acpi_dead_idle() actually use default_dead_idle(), just to have<br>
things consolidated in one place. I assume I can put your S-o-b on<br>
what you sent...<br>
<font color=3D"#888888"><br>
Jan<br>
</font><br>
&gt; On Mon, Sep 24, 2012 at 10:10 AM, Jan Beulich &lt;<a href=3D"http://JB=
eulich@suse.com" target=3D"_blank">JBeulich@suse.com</a>&gt; wrote:<br>
&gt;<br>
&gt;&gt; &gt;&gt;&gt; On 24.09.12 at 15:56, Ben Guthro &lt;<a href=3D"http:=
//ben@guthro.net" target=3D"_blank">ben@guthro.net</a>&gt; wrote:<br>
&gt;&gt; &gt; On Mon, Sep 24, 2012 at 9:34 AM, Jan Beulich &lt;<a href=3D"h=
ttp://JBeulich@suse.com" target=3D"_blank">JBeulich@suse.com</a>&gt; wrote:=
<br>
&gt;&gt; &gt;&gt; ...; the interesting ones are<br>
&gt;&gt; &gt;&gt; - at the end of xen/arch/x86/acpu/cpu_idle.c:acpi_dead_id=
le()<br>
&gt;&gt; &gt;&gt; - xen/arch/x86/domain.c:default_dead_idle()<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; Thanks! This fixes the issue on this machine!<br>
&gt;&gt;<br>
&gt;&gt; Hooray!<br>
&gt;&gt;<br>
&gt;&gt; &gt; Is this a reasonable long-term solution - or are there reason=
s not to<br>
&gt;&gt; &gt; call wbinvd() here?<br>
&gt;&gt;<br>
&gt;&gt; That&#39;s a perfectly valid adjustment (see my earlier reply wher=
e<br>
&gt;&gt; I originally suggested it and explained why it may be necessary).<=
br>
&gt;&gt;<br>
&gt;&gt; Jan<br>
&gt;&gt;<br>
&gt;&gt;<br>
<br>
<br>
<br>
</span></font></blockquote></div></div><font face=3D"Calibri, Verdana, Helv=
etica, Arial"><span style=3D"font-size:11pt"><br>
<br>
<hr align=3D"CENTER" size=3D"3" width=3D"95%"></span></font><div class=3D"i=
m"><font><font face=3D"Consolas, Courier New, Courier"><span style=3D"font-=
size:10pt">_______________________________________________<br>
Xen-devel mailing list<br>
<a href=3D"http://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>
</span></font></font></div></blockquote>
</div>


</blockquote></div><br></div>

--bcaec51b9c7394dc4604ca78b0e1--


--===============7576102220054106408==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============7576102220054106408==--


From xen-devel-bounces@lists.xen.org Mon Sep 24 21:09:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Sep 2012 21: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 1TGFtO-00040p-NX; Mon, 24 Sep 2012 21:08:38 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <linux@eikelenboom.it>) id 1TGFtN-00040k-HA
	for xen-devel@lists.xensource.com; Mon, 24 Sep 2012 21:08:37 +0000
Received: from [85.158.143.35:53385] by server-1.bemta-4.messagelabs.com id
	9B/22-05684-4DBC0605; Mon, 24 Sep 2012 21:08:36 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-9.tower-21.messagelabs.com!1348520914!4943254!1
X-Originating-IP: [188.40.164.121]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19952 invoked from network); 24 Sep 2012 21:08:34 -0000
Received: from static.121.164.40.188.clients.your-server.de (HELO
	smtp.eikelenboom.it) (188.40.164.121)
	by server-9.tower-21.messagelabs.com with AES256-SHA encrypted SMTP;
	24 Sep 2012 21:08:34 -0000
Received: from 132-64-ftth.onsneteindhoven.nl ([88.159.64.132]:63424
	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 1TGFu4-0006nn-ED; Mon, 24 Sep 2012 23:09:20 +0200
Date: Mon, 24 Sep 2012 23:08:32 +0200
From: Sander Eikelenboom <linux@eikelenboom.it>
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <305203045.20120924230832@eikelenboom.it>
To: Wei Wang <wei.wang2@amd.com>
In-Reply-To: <74647167<506050F0.7020703@amd.com>
References: <504764E2.4000809@amd.com>
	<326589347.20120906005936@eikelenboom.it>
	<5048A603.3070207@amd.com>
	<483486315.20120906155001@eikelenboom.it>
	<5048BB29.4040900@amd.com>
	<488803362.20120907093241@eikelenboom.it>
	<5049B650.4080101@amd.com> <74647167 <506050F0.7020703@amd.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH] amd iommu: Dump flags of IO page faults
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


Monday, September 24, 2012, 2:24:16 PM, you wrote:

> On 09/24/2012 10:38 AM, Sander Eikelenboom wrote:
>>
>> Friday, September 7, 2012, 10:54:40 AM, you wrote:
>>
>>> On 09/07/2012 09:32 AM, Sander Eikelenboom wrote:
>>>>
>>>> Thursday, September 6, 2012, 5:03:05 PM, you wrote:
>>>>
>>>>> On 09/06/2012 03:50 PM, Sander Eikelenboom wrote:
>>>>>>
>>>>>> Thursday, September 6, 2012, 3:32:51 PM, you wrote:
>>>>>>
>>>>>>> On 09/06/2012 12:59 AM, Sander Eikelenboom wrote:
>>>>>>>>
>>>>>>>> Wednesday, September 5, 2012, 4:42:42 PM, you wrote:
>>>>>>>>
>>>>>>>>> Hi Jan,
>>>>>>>>> Attached patch dumps io page fault flags. The flags show the reason of
>>>>>>>>> the fault and tell us if this is an unmapped interrupt fault or a DMA fault.
>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> Wei
>>>>>>>>
>>>>>>>>> signed-off-by: Wei Wang<wei.wang2@amd.com>
>>>>>>>>
>>>>>>>>
>>>>>>>> I have applied the patch and the flags seem to differ between the faults:
>>>>>>>>
>>>>>>>> AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0a06, fault address = 0xc2c2c2c0, flags = 0x000
>>>>>>>> (XEN) [2012-09-05 20:54:16] AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0a06, fault address = 0xc2c2c2c0, flags = 0x000
>>>>>>>> (XEN) [2012-09-05 20:54:16] AMD-Vi: IO_PAGE_FAULT: domain = 14, device id = 0x0700, fault address = 0xa8d339e0, flags = 0x020
>>>>>>>> (XEN) [2012-09-05 20:54:16] AMD-Vi: IO_PAGE_FAULT: domain = 14, device id = 0x0700, fault address = 0xa8d33a40, flags = 0x020
>>>>>>
>>>>>>> OK, so they are not interrupt requests. I guess further information from
>>>>>>> your system would be helpful to debug this issue:
>>>>>>> 1) xl info
>>>>>>> 2) xl list
>>>>>>> 3) lscpi -vvv (NOTE: not in dom0 but in your guest)
>>>>>>> 4) cat /proc/iomem (in both dom0 and your hvm guest)
>>>>>>
>>>>>> dom14 is not a HVM guest,it's a PV guest.
>>>>
>>>>> Ah, I see. PV guest is quite different than hvm, it does use p2m tables
>>>>> as io page tables. So no-sharept option does not work in this case. PV
>>>>> guests always use separated io page tables. There might be some
>>>>> incorrect mappings on the page tables. I will check this on my side.
>>>>
>>>> I have reverted the machine to xen-4.1.4-pre (changeset 23353) and kept everything else the same.
>>>> I haven't seen any IO PAGE FAULTS after that.
>>>>
>>>> I did spot some differences in the output from lspci between xen 4.1 and 4.2, related to MSI enabled or not for the IOMMU device.
>>>> Have attached the xl/xm dmesg and lspci from booting with both versions.
>>>>
>>>> lspci:
>>>>
>>>> 00:00.2 Generic system peripheral [0806]: ATI Technologies Inc RD990 I/O Memory Management Unit (IOMMU) [1002:5a23]
>>>>           Subsystem: ATI Technologies Inc RD990 I/O Memory Management Unit (IOMMU) [1002:5a23]
>>>>           Control: I/O- Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
>>>>           Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast>TAbort-<TAbort-<MAbort->SERR-<PERR- INTx-
>>>>           Latency: 0
>>>>           Interrupt: pin A routed to IRQ 10
>>>>           Capabilities: [40] Secure device<?>
>>>> 4.1:    Capabilities: [54] MSI: Enable- Count=1/1 Maskable- 64bit+
>>
>>> Eh... That is interesting. So which dom0 are you using?  There is a c/s
>>> in 4.2 to prevent recent dom0 to disable iommu interrupt (changeset
>>> 25492:61844569a432) Otherwise, iommu cannot send any events including IO
>>> PAGE faults. You could try to revert dom0 to an old version like 2.6
>>> pv_ops to see if you really have no io page faults on 4.1
>>
>> Ok i finally got the time to do some more testing, tested 4.2 around that changeset, and made a copy of the guest using HVM instead of PV.
>>
>> The results:
>> - On xen-4.1.* and a 3.6-rc6 kernel (dom0 and domU):  the video device passed through works fine, both in a HVM as a PV guest, i don't see IO page faults getting reported.
>> - On xen-4.2 changeset<   25492 and a 3.6-rc6 kernel (dom0 and domU):  the video device passed through works fine, both in a HVM as a PV guest, i don't see IO page faults getting reported.
>> - On xen-4.2 changeset>   25492 and a 3.6-rc6 kernel (dom0 and domU): the video device passed through works fine for a short while (around 5 to 10 minutes) in a PV guest, after that IO page faults get reported and the video freezes, i don't see any errors in the guest though.
>> - On xen-unstable tip and a 3.6-rc6 kernel (dom0 and domU):
>>                                                        PV:  the video device passed through works fine for a short while (around 5 to 10 minutes), after that IO page faults get reported and the video freezes, i don't see any errors in the guest though.
>>                                                        HVM: the video device passed through doesn't work from the start:
>>                                                                       - The device is there according to lspci
>>                                                                       - The video application start fine, but delivers a green image, so the device is not working properly. I don't see IO page faults though.
>>
>> Attached are (all with xen-unstable tip and the guest as HVM (domain 15):
>> - xl dmesg
>> - Patch which adds some more info, but all values reported seem to be zero (see xl dmesg)
>> - lspci dom0
>> - lspci HVM guest

> HI,
> Thanks for the information, very very helpful for debugging. I hope I 
> could start to look at this right after sending my next iommu patch 
> queue upstream...another question is: Did you see this issue on a single 
> pv/hvm guest system or you only saw it on a system with about 16 running 
> VMs?

The issue of the hvm not giving a video image also happens when it's the first and only guest running after a cold boot.

> Thanks,
> Wei

>>
>>
>>
>>>> 4.2:    Capabilities: [54] MSI: Enable+ Count=1/1 Maskable- 64bit+
>>>>                   Address: 00000000fee0100c  Data: 4128
>>>>           Capabilities: [64] HyperTransport: MSI Mapping Enable+ Fixed+
>>>>
>>>> Although it seems enabled, shouldn't the IRQ number used be much higher than 10 for MSI interrupts ?
>>
>>> The IRQ number is fine. MSI vector is stored at  Data: 4128
>>
>>>>
>>>> There is another difference in the bridge device that's in front of the  0a:00.6 device that faults before the kernel is even booted.
>>>>
>>>> 00:03.0 PCI bridge [0604]: ATI Technologies Inc RD890 PCI to PCI bridge (PCI express gpp port C) [1002:5a17] (prog-if 00 [Normal decode])
>>>>           Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx+
>>>> 4.1:    Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast>TAbort-<TAbort-<MAbort->SERR-<PERR- INTx-
>>>> 4.2:    Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast>TAbort-<TAbort+<MAbort->SERR-<PERR- INTx-
>>>>           Latency: 0, Cache Line Size: 64 bytes
>>>>           Bus: primary=00, secondary=0a, subordinate=0a, sec-latency=0
>>>>           I/O behind bridge: 0000f000-00000fff
>>>>           Memory behind bridge: f9f00000-f9ffffff
>>>>           Prefetchable memory behind bridge: 00000000fff00000-00000000000fffff
>>>> 4.1:    Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast>TAbort-<TAbort-<MAbort-<SERR-<PERR-
>>>> 4.2:    Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast>TAbort+<TAbort-<MAbort-<SERR-<PERR-
>>>>           BridgeCtl: Parity+ SERR+ NoISA+ VGA- MAbort->Reset- FastB2B-
>>>>                   PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
>>>>           Capabilities: [50] Power Management version 3
>>>>                   Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
>>>>                   Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
>>>>           Capabilities: [58] Express (v2) Root Port (Slot+), MSI 00
>>>>                   DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s<64ns, L1<1us
>>>>                           ExtTag+ RBE+ FLReset-
>>>>                   DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
>>>>                           RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+
>>>>                           MaxPayload 128 bytes, MaxReadReq 128 bytes
>>>>                   DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr- TransPend-
>>>>                   LnkCap: Port #1, Speed 5GT/s, Width x8, ASPM L0s L1, Latency L0<1us, L1<8us
>>>>                           ClockPM- Surprise- LLActRep+ BwNot+
>>>>                   LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommClk-
>>>>                           ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
>>>>                   LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive+ BWMgmt+ ABWMgmt-
>>>>                   SltCap: AttnBtn- PwrCtrl- MRL- AttnInd- PwrInd- HotPlug- Surprise-
>>>>                           Slot #3, PowerLimit 10.000W; Interlock- NoCompl+
>>>>                   SltCtl: Enable: AttnBtn- PwrFlt- MRL- PresDet- CmdCplt- HPIrq- LinkChg-
>>>>                           Control: AttnInd Unknown, PwrInd Unknown, Power- Interlock-
>>>>                   SltSta: Status: AttnBtn- PowerFlt- MRL- CmdCplt- PresDet+ Interlock-
>>>>                           Changed: MRL- PresDet+ LinkState+
>>
>>> The probably because of the IO_PAGE_FAULT.
>>
>>> Thanks,
>>> Wei
>>
>>>> serveerstertje:~# lspci -t
>>>> -[0000:00]-+-00.0
>>>>              +-00.2
>>>>              +-02.0-[0b]----00.0
>>>>              +-03.0-[0a]--+-00.0
>>>>              |            +-00.1
>>>>              |            +-00.2
>>>>              |            +-00.3
>>>>              |            +-00.4
>>>>              |            +-00.5
>>>>              |            +-00.6
>>>>              |            \-00.7
>>>>              +-05.0-[09]----00.0
>>>>              +-06.0-[08]----00.0
>>>>              +-0a.0-[07]----00.0
>>>>              +-0b.0-[06]--+-00.0
>>>>              |            \-00.1
>>>>              +-0c.0-[05]----00.0
>>>>              +-0d.0-[04]--+-00.0
>>>>              |            +-00.1
>>>>              |            +-00.2
>>>>              |            +-00.3
>>>>              |            +-00.4
>>>>              |            +-00.5
>>>>              |            +-00.6
>>>>              |            \-00.7
>>>>              +-11.0
>>>>              +-12.0
>>>>              +-12.2
>>>>              +-13.0
>>>>              +-13.2
>>>>              +-14.0
>>>>              +-14.3
>>>>              +-14.4-[03]----06.0
>>>>              +-14.5
>>>>              +-15.0-[02]--
>>>>              +-16.0
>>>>              +-16.2
>>>>              +-18.0
>>>>              +-18.1
>>>>              +-18.2
>>>>              +-18.3
>>>>              \-18.4
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>> Thanks,
>>>>> Wei
>>>>
>>>>>> I will try to make a complete package, and try with one pv domain only where the devices are being passed through just to simplify the setup.
>>>>>>
>>>>>>
>>>>>>> * I would also like to know the symptoms of device 0x0700 when IO_PF
>>>>>>> happened. Did it stop working?
>>>>>>
>>>>>> Yes it stops working, the video capture just freezes, but the driver doesn't bail out.
>>>>>> For the USB controller (0x0a06) it starts to give errors for usbdev_open in the guest.
>>>>>>
>>>>>>> (BTW: I copied a few options from your boot cmd line and it worked with
>>>>>>> my RD890 system
>>>>>>
>>>>>>> dom0_mem=1024M,max:1024M loglvl=all loglvl_guest=all console_timestamps
>>>>>>> cpuidle cpufreq=xen noreboot debug lapic=debug apic_verbosity=debug
>>>>>>> apic=debug iommu=on,verbose,debug,no-sharept
>>>>>>
>>>>>>> * so, what OEM board you have?)
>>>>>>
>>>>>> MSI 890FXA-GD70
>>>>>>
>>>>>>> Also from your log, these lines looks very strange:
>>>>>>
>>>>>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>>>>>>> read-only memory page. gfn=0xd5, mfn=0xa4a11
>>>>>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>>>>>>> read-only memory page. gfn=0xd7, mfn=0xa4a0f
>>>>>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>>>>>>> read-only memory page. gfn=0xd9, mfn=0xa4a0d
>>>>>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>>>>>>> read-only memory page. gfn=0xdb, mfn=0xa4a0b
>>>>>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>>>>>>> read-only memory page. gfn=0xdd, mfn=0xa4a09
>>>>>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>>>>>>> read-only memory page. gfn=0xdf, mfn=0xa4a07
>>>>>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>>>>>>> read-only memory page. gfn=0xe1, mfn=0xa4a05
>>>>>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>>>>>>> read-only memory page. gfn=0xe3, mfn=0xa4a03
>>>>>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>>>>>>> read-only memory page. gfn=0xe5, mfn=0xa4a01
>>>>>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>>>>>>> read-only memory page. gfn=0xe7, mfn=0xa463f
>>>>>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>>>>>>> read-only memory page. gfn=0xe9, mfn=0xa463d
>>>>>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>>>>>>> read-only memory page. gfn=0xeb, mfn=0xa463b
>>>>>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>>>>>>> read-only memory page. gfn=0xed, mfn=0xa4639
>>>>>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>>>>>>> read-only memory page. gfn=0xef, mfn=0xa4637
>>>>>>> (XEN) [2012-09-04 16:13:56] AMD-Vi: IO_PAGE_FAULT: domain = 0, device id
>>>>>>> = 0x0a06, fault address = 0xc2c2c2c0
>>>>>>> (XEN) [2012-09-04 16:13:56] AMD-Vi: IO_PAGE_FAULT: domain = 14, device
>>>>>>> id = 0x0700, fault address = 0xa90f8300
>>>>>>> (XEN) [2012-09-04 16:13:56] AMD-Vi: IO_PAGE_FAULT: domain = 14, device
>>>>>>> id = 0x0700, fault address = 0xa90f8340
>>>>>>> (XEN) [2012-09-04 16:13:56] AMD-Vi: IO_PAGE_FAULT: domain = 14, device
>>>>>>> id = 0x0700, fault address = 0xa90f8380
>>>>>>> (XEN) [2012-09-04 16:13:56] AMD-Vi: IO_PAGE_FAULT: domain = 14, device
>>>>>>> id = 0x0700, fault address = 0xa90f83c0
>>>>>>
>>>>>>> * they are just followed by the IO PAGE fault. Do you know where are
>>>>>>> they from? Your video card driver maybe?
>>>>>>
>>>>>>      From a HVM domain with a old (3.0.3) kernel, but the faults also occur without this domain being started.
>>>>>>
>>>>>>
>>>>>>> Thanks,
>>>>>>> Wei
>>>>>>
>>>>>>
>>>>>>>> Complete xl dmesg and lspci -vvvknn attached.
>>>>>>>>
>>>>>>>> Thx
>>>>>>>>
>>>>>>>> --
>>>>>>>> Sander
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>
>>>>
>>
>>





_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 24 21:09:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Sep 2012 21: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 1TGFtO-00040p-NX; Mon, 24 Sep 2012 21:08:38 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <linux@eikelenboom.it>) id 1TGFtN-00040k-HA
	for xen-devel@lists.xensource.com; Mon, 24 Sep 2012 21:08:37 +0000
Received: from [85.158.143.35:53385] by server-1.bemta-4.messagelabs.com id
	9B/22-05684-4DBC0605; Mon, 24 Sep 2012 21:08:36 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-9.tower-21.messagelabs.com!1348520914!4943254!1
X-Originating-IP: [188.40.164.121]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19952 invoked from network); 24 Sep 2012 21:08:34 -0000
Received: from static.121.164.40.188.clients.your-server.de (HELO
	smtp.eikelenboom.it) (188.40.164.121)
	by server-9.tower-21.messagelabs.com with AES256-SHA encrypted SMTP;
	24 Sep 2012 21:08:34 -0000
Received: from 132-64-ftth.onsneteindhoven.nl ([88.159.64.132]:63424
	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 1TGFu4-0006nn-ED; Mon, 24 Sep 2012 23:09:20 +0200
Date: Mon, 24 Sep 2012 23:08:32 +0200
From: Sander Eikelenboom <linux@eikelenboom.it>
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <305203045.20120924230832@eikelenboom.it>
To: Wei Wang <wei.wang2@amd.com>
In-Reply-To: <74647167<506050F0.7020703@amd.com>
References: <504764E2.4000809@amd.com>
	<326589347.20120906005936@eikelenboom.it>
	<5048A603.3070207@amd.com>
	<483486315.20120906155001@eikelenboom.it>
	<5048BB29.4040900@amd.com>
	<488803362.20120907093241@eikelenboom.it>
	<5049B650.4080101@amd.com> <74647167 <506050F0.7020703@amd.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH] amd iommu: Dump flags of IO page faults
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


Monday, September 24, 2012, 2:24:16 PM, you wrote:

> On 09/24/2012 10:38 AM, Sander Eikelenboom wrote:
>>
>> Friday, September 7, 2012, 10:54:40 AM, you wrote:
>>
>>> On 09/07/2012 09:32 AM, Sander Eikelenboom wrote:
>>>>
>>>> Thursday, September 6, 2012, 5:03:05 PM, you wrote:
>>>>
>>>>> On 09/06/2012 03:50 PM, Sander Eikelenboom wrote:
>>>>>>
>>>>>> Thursday, September 6, 2012, 3:32:51 PM, you wrote:
>>>>>>
>>>>>>> On 09/06/2012 12:59 AM, Sander Eikelenboom wrote:
>>>>>>>>
>>>>>>>> Wednesday, September 5, 2012, 4:42:42 PM, you wrote:
>>>>>>>>
>>>>>>>>> Hi Jan,
>>>>>>>>> Attached patch dumps io page fault flags. The flags show the reason of
>>>>>>>>> the fault and tell us if this is an unmapped interrupt fault or a DMA fault.
>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> Wei
>>>>>>>>
>>>>>>>>> signed-off-by: Wei Wang<wei.wang2@amd.com>
>>>>>>>>
>>>>>>>>
>>>>>>>> I have applied the patch and the flags seem to differ between the faults:
>>>>>>>>
>>>>>>>> AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0a06, fault address = 0xc2c2c2c0, flags = 0x000
>>>>>>>> (XEN) [2012-09-05 20:54:16] AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x0a06, fault address = 0xc2c2c2c0, flags = 0x000
>>>>>>>> (XEN) [2012-09-05 20:54:16] AMD-Vi: IO_PAGE_FAULT: domain = 14, device id = 0x0700, fault address = 0xa8d339e0, flags = 0x020
>>>>>>>> (XEN) [2012-09-05 20:54:16] AMD-Vi: IO_PAGE_FAULT: domain = 14, device id = 0x0700, fault address = 0xa8d33a40, flags = 0x020
>>>>>>
>>>>>>> OK, so they are not interrupt requests. I guess further information from
>>>>>>> your system would be helpful to debug this issue:
>>>>>>> 1) xl info
>>>>>>> 2) xl list
>>>>>>> 3) lscpi -vvv (NOTE: not in dom0 but in your guest)
>>>>>>> 4) cat /proc/iomem (in both dom0 and your hvm guest)
>>>>>>
>>>>>> dom14 is not a HVM guest,it's a PV guest.
>>>>
>>>>> Ah, I see. PV guest is quite different than hvm, it does use p2m tables
>>>>> as io page tables. So no-sharept option does not work in this case. PV
>>>>> guests always use separated io page tables. There might be some
>>>>> incorrect mappings on the page tables. I will check this on my side.
>>>>
>>>> I have reverted the machine to xen-4.1.4-pre (changeset 23353) and kept everything else the same.
>>>> I haven't seen any IO PAGE FAULTS after that.
>>>>
>>>> I did spot some differences in the output from lspci between xen 4.1 and 4.2, related to MSI enabled or not for the IOMMU device.
>>>> Have attached the xl/xm dmesg and lspci from booting with both versions.
>>>>
>>>> lspci:
>>>>
>>>> 00:00.2 Generic system peripheral [0806]: ATI Technologies Inc RD990 I/O Memory Management Unit (IOMMU) [1002:5a23]
>>>>           Subsystem: ATI Technologies Inc RD990 I/O Memory Management Unit (IOMMU) [1002:5a23]
>>>>           Control: I/O- Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
>>>>           Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast>TAbort-<TAbort-<MAbort->SERR-<PERR- INTx-
>>>>           Latency: 0
>>>>           Interrupt: pin A routed to IRQ 10
>>>>           Capabilities: [40] Secure device<?>
>>>> 4.1:    Capabilities: [54] MSI: Enable- Count=1/1 Maskable- 64bit+
>>
>>> Eh... That is interesting. So which dom0 are you using?  There is a c/s
>>> in 4.2 to prevent recent dom0 to disable iommu interrupt (changeset
>>> 25492:61844569a432) Otherwise, iommu cannot send any events including IO
>>> PAGE faults. You could try to revert dom0 to an old version like 2.6
>>> pv_ops to see if you really have no io page faults on 4.1
>>
>> Ok i finally got the time to do some more testing, tested 4.2 around that changeset, and made a copy of the guest using HVM instead of PV.
>>
>> The results:
>> - On xen-4.1.* and a 3.6-rc6 kernel (dom0 and domU):  the video device passed through works fine, both in a HVM as a PV guest, i don't see IO page faults getting reported.
>> - On xen-4.2 changeset<   25492 and a 3.6-rc6 kernel (dom0 and domU):  the video device passed through works fine, both in a HVM as a PV guest, i don't see IO page faults getting reported.
>> - On xen-4.2 changeset>   25492 and a 3.6-rc6 kernel (dom0 and domU): the video device passed through works fine for a short while (around 5 to 10 minutes) in a PV guest, after that IO page faults get reported and the video freezes, i don't see any errors in the guest though.
>> - On xen-unstable tip and a 3.6-rc6 kernel (dom0 and domU):
>>                                                        PV:  the video device passed through works fine for a short while (around 5 to 10 minutes), after that IO page faults get reported and the video freezes, i don't see any errors in the guest though.
>>                                                        HVM: the video device passed through doesn't work from the start:
>>                                                                       - The device is there according to lspci
>>                                                                       - The video application start fine, but delivers a green image, so the device is not working properly. I don't see IO page faults though.
>>
>> Attached are (all with xen-unstable tip and the guest as HVM (domain 15):
>> - xl dmesg
>> - Patch which adds some more info, but all values reported seem to be zero (see xl dmesg)
>> - lspci dom0
>> - lspci HVM guest

> HI,
> Thanks for the information, very very helpful for debugging. I hope I 
> could start to look at this right after sending my next iommu patch 
> queue upstream...another question is: Did you see this issue on a single 
> pv/hvm guest system or you only saw it on a system with about 16 running 
> VMs?

The issue of the hvm not giving a video image also happens when it's the first and only guest running after a cold boot.

> Thanks,
> Wei

>>
>>
>>
>>>> 4.2:    Capabilities: [54] MSI: Enable+ Count=1/1 Maskable- 64bit+
>>>>                   Address: 00000000fee0100c  Data: 4128
>>>>           Capabilities: [64] HyperTransport: MSI Mapping Enable+ Fixed+
>>>>
>>>> Although it seems enabled, shouldn't the IRQ number used be much higher than 10 for MSI interrupts ?
>>
>>> The IRQ number is fine. MSI vector is stored at  Data: 4128
>>
>>>>
>>>> There is another difference in the bridge device that's in front of the  0a:00.6 device that faults before the kernel is even booted.
>>>>
>>>> 00:03.0 PCI bridge [0604]: ATI Technologies Inc RD890 PCI to PCI bridge (PCI express gpp port C) [1002:5a17] (prog-if 00 [Normal decode])
>>>>           Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx+
>>>> 4.1:    Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast>TAbort-<TAbort-<MAbort->SERR-<PERR- INTx-
>>>> 4.2:    Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast>TAbort-<TAbort+<MAbort->SERR-<PERR- INTx-
>>>>           Latency: 0, Cache Line Size: 64 bytes
>>>>           Bus: primary=00, secondary=0a, subordinate=0a, sec-latency=0
>>>>           I/O behind bridge: 0000f000-00000fff
>>>>           Memory behind bridge: f9f00000-f9ffffff
>>>>           Prefetchable memory behind bridge: 00000000fff00000-00000000000fffff
>>>> 4.1:    Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast>TAbort-<TAbort-<MAbort-<SERR-<PERR-
>>>> 4.2:    Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast>TAbort+<TAbort-<MAbort-<SERR-<PERR-
>>>>           BridgeCtl: Parity+ SERR+ NoISA+ VGA- MAbort->Reset- FastB2B-
>>>>                   PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
>>>>           Capabilities: [50] Power Management version 3
>>>>                   Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
>>>>                   Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
>>>>           Capabilities: [58] Express (v2) Root Port (Slot+), MSI 00
>>>>                   DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s<64ns, L1<1us
>>>>                           ExtTag+ RBE+ FLReset-
>>>>                   DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
>>>>                           RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+
>>>>                           MaxPayload 128 bytes, MaxReadReq 128 bytes
>>>>                   DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr- TransPend-
>>>>                   LnkCap: Port #1, Speed 5GT/s, Width x8, ASPM L0s L1, Latency L0<1us, L1<8us
>>>>                           ClockPM- Surprise- LLActRep+ BwNot+
>>>>                   LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommClk-
>>>>                           ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
>>>>                   LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive+ BWMgmt+ ABWMgmt-
>>>>                   SltCap: AttnBtn- PwrCtrl- MRL- AttnInd- PwrInd- HotPlug- Surprise-
>>>>                           Slot #3, PowerLimit 10.000W; Interlock- NoCompl+
>>>>                   SltCtl: Enable: AttnBtn- PwrFlt- MRL- PresDet- CmdCplt- HPIrq- LinkChg-
>>>>                           Control: AttnInd Unknown, PwrInd Unknown, Power- Interlock-
>>>>                   SltSta: Status: AttnBtn- PowerFlt- MRL- CmdCplt- PresDet+ Interlock-
>>>>                           Changed: MRL- PresDet+ LinkState+
>>
>>> The probably because of the IO_PAGE_FAULT.
>>
>>> Thanks,
>>> Wei
>>
>>>> serveerstertje:~# lspci -t
>>>> -[0000:00]-+-00.0
>>>>              +-00.2
>>>>              +-02.0-[0b]----00.0
>>>>              +-03.0-[0a]--+-00.0
>>>>              |            +-00.1
>>>>              |            +-00.2
>>>>              |            +-00.3
>>>>              |            +-00.4
>>>>              |            +-00.5
>>>>              |            +-00.6
>>>>              |            \-00.7
>>>>              +-05.0-[09]----00.0
>>>>              +-06.0-[08]----00.0
>>>>              +-0a.0-[07]----00.0
>>>>              +-0b.0-[06]--+-00.0
>>>>              |            \-00.1
>>>>              +-0c.0-[05]----00.0
>>>>              +-0d.0-[04]--+-00.0
>>>>              |            +-00.1
>>>>              |            +-00.2
>>>>              |            +-00.3
>>>>              |            +-00.4
>>>>              |            +-00.5
>>>>              |            +-00.6
>>>>              |            \-00.7
>>>>              +-11.0
>>>>              +-12.0
>>>>              +-12.2
>>>>              +-13.0
>>>>              +-13.2
>>>>              +-14.0
>>>>              +-14.3
>>>>              +-14.4-[03]----06.0
>>>>              +-14.5
>>>>              +-15.0-[02]--
>>>>              +-16.0
>>>>              +-16.2
>>>>              +-18.0
>>>>              +-18.1
>>>>              +-18.2
>>>>              +-18.3
>>>>              \-18.4
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>> Thanks,
>>>>> Wei
>>>>
>>>>>> I will try to make a complete package, and try with one pv domain only where the devices are being passed through just to simplify the setup.
>>>>>>
>>>>>>
>>>>>>> * I would also like to know the symptoms of device 0x0700 when IO_PF
>>>>>>> happened. Did it stop working?
>>>>>>
>>>>>> Yes it stops working, the video capture just freezes, but the driver doesn't bail out.
>>>>>> For the USB controller (0x0a06) it starts to give errors for usbdev_open in the guest.
>>>>>>
>>>>>>> (BTW: I copied a few options from your boot cmd line and it worked with
>>>>>>> my RD890 system
>>>>>>
>>>>>>> dom0_mem=1024M,max:1024M loglvl=all loglvl_guest=all console_timestamps
>>>>>>> cpuidle cpufreq=xen noreboot debug lapic=debug apic_verbosity=debug
>>>>>>> apic=debug iommu=on,verbose,debug,no-sharept
>>>>>>
>>>>>>> * so, what OEM board you have?)
>>>>>>
>>>>>> MSI 890FXA-GD70
>>>>>>
>>>>>>> Also from your log, these lines looks very strange:
>>>>>>
>>>>>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>>>>>>> read-only memory page. gfn=0xd5, mfn=0xa4a11
>>>>>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>>>>>>> read-only memory page. gfn=0xd7, mfn=0xa4a0f
>>>>>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>>>>>>> read-only memory page. gfn=0xd9, mfn=0xa4a0d
>>>>>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>>>>>>> read-only memory page. gfn=0xdb, mfn=0xa4a0b
>>>>>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>>>>>>> read-only memory page. gfn=0xdd, mfn=0xa4a09
>>>>>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>>>>>>> read-only memory page. gfn=0xdf, mfn=0xa4a07
>>>>>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>>>>>>> read-only memory page. gfn=0xe1, mfn=0xa4a05
>>>>>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>>>>>>> read-only memory page. gfn=0xe3, mfn=0xa4a03
>>>>>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>>>>>>> read-only memory page. gfn=0xe5, mfn=0xa4a01
>>>>>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>>>>>>> read-only memory page. gfn=0xe7, mfn=0xa463f
>>>>>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>>>>>>> read-only memory page. gfn=0xe9, mfn=0xa463d
>>>>>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>>>>>>> read-only memory page. gfn=0xeb, mfn=0xa463b
>>>>>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>>>>>>> read-only memory page. gfn=0xed, mfn=0xa4639
>>>>>>> (XEN) [2012-09-04 15:54:35] hvm.c:2435:d15 guest attempted write to
>>>>>>> read-only memory page. gfn=0xef, mfn=0xa4637
>>>>>>> (XEN) [2012-09-04 16:13:56] AMD-Vi: IO_PAGE_FAULT: domain = 0, device id
>>>>>>> = 0x0a06, fault address = 0xc2c2c2c0
>>>>>>> (XEN) [2012-09-04 16:13:56] AMD-Vi: IO_PAGE_FAULT: domain = 14, device
>>>>>>> id = 0x0700, fault address = 0xa90f8300
>>>>>>> (XEN) [2012-09-04 16:13:56] AMD-Vi: IO_PAGE_FAULT: domain = 14, device
>>>>>>> id = 0x0700, fault address = 0xa90f8340
>>>>>>> (XEN) [2012-09-04 16:13:56] AMD-Vi: IO_PAGE_FAULT: domain = 14, device
>>>>>>> id = 0x0700, fault address = 0xa90f8380
>>>>>>> (XEN) [2012-09-04 16:13:56] AMD-Vi: IO_PAGE_FAULT: domain = 14, device
>>>>>>> id = 0x0700, fault address = 0xa90f83c0
>>>>>>
>>>>>>> * they are just followed by the IO PAGE fault. Do you know where are
>>>>>>> they from? Your video card driver maybe?
>>>>>>
>>>>>>      From a HVM domain with a old (3.0.3) kernel, but the faults also occur without this domain being started.
>>>>>>
>>>>>>
>>>>>>> Thanks,
>>>>>>> Wei
>>>>>>
>>>>>>
>>>>>>>> Complete xl dmesg and lspci -vvvknn attached.
>>>>>>>>
>>>>>>>> Thx
>>>>>>>>
>>>>>>>> --
>>>>>>>> Sander
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>
>>>>
>>
>>





_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 24 21:13:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Sep 2012 21:13:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGFxS-00048j-D4; Mon, 24 Sep 2012 21:12:50 +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 1TGFxQ-00048M-4r
	for xen-devel@lists.xen.org; Mon, 24 Sep 2012 21:12:48 +0000
Received: from [85.158.138.51:63160] by server-13.bemta-3.messagelabs.com id
	29/2C-01606-FCCC0605; Mon, 24 Sep 2012 21:12:47 +0000
X-Env-Sender: ben.guthro@gmail.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1348521164!23721263!1
X-Originating-IP: [209.85.212.45]
X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_30_40,HTML_MESSAGE,
	RCVD_BY_IP,USERPASS
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27603 invoked from network); 24 Sep 2012 21:12:45 -0000
Received: from mail-vb0-f45.google.com (HELO mail-vb0-f45.google.com)
	(209.85.212.45)
	by server-3.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Sep 2012 21:12:45 -0000
Received: by vbip1 with SMTP id p1so7994660vbi.32
	for <xen-devel@lists.xen.org>; Mon, 24 Sep 2012 14:12:44 -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=uLGv29Lo7vBk2woHt0u8mCsCumkUBCw+AeOWN3NAxg0=;
	b=OnSXH+JF7YRNStb7FHkgf6jw/bSuyI/8shk+SWi1dcs732w4t7NQUcB7XowErokT7Y
	UXapPeA31aWQWwr/WJKYe+QyfTdwXaaQ/C4vIoUjlNc2eRDKhsio8DL8+dVuSy0nA9QY
	5Kzcx0Z/fQrFcIpvlSuvb9qp7CpqXp+un6N5NZXsgu5tTqT25df1qllybCGi+SMY3kqq
	EmmqEB+jkLWFkMCer4gct906ZQWWfyTjv+uDMbCAyHg28WADMk919zyB8H4yxCWgfbtg
	jc4Cbgy3nCURm8oJuXxKSD8ftb+ObBXqiXbhL664r/pt0InOmgQYkfpJrmkTKwJpQsYY
	Jj7Q==
MIME-Version: 1.0
Received: by 10.220.106.143 with SMTP id x15mr8108058vco.33.1348521163944;
	Mon, 24 Sep 2012 14:12:43 -0700 (PDT)
Received: by 10.58.137.169 with HTTP; Mon, 24 Sep 2012 14:12:43 -0700 (PDT)
In-Reply-To: <CAOvdn6U-JyLvt96gkLkqzi088tU9_ktv4D+fkJac_BKVe05Y-w@mail.gmail.com>
References: <CAOvdn6UCF2A3yP1cqWn=dxwr0ayRbr+rg+xj8META9Dm0+CoNw@mail.gmail.com>
	<CC868168.3FD29%keir.xen@gmail.com>
	<CAOvdn6U-JyLvt96gkLkqzi088tU9_ktv4D+fkJac_BKVe05Y-w@mail.gmail.com>
Date: Mon, 24 Sep 2012 17:12:43 -0400
X-Google-Sender-Auth: fFeAQLK1JAe-ym1cmwg01CLi9GQ
Message-ID: <CAOvdn6V+s3AbRzsu8VArbmrZou=im9SqvPf-9Wpif_BrNMv=yg@mail.gmail.com>
From: Ben Guthro <ben@guthro.net>
To: Keir Fraser <keir.xen@gmail.com>
Content-Type: multipart/mixed; boundary=f46d0432b1c2f2f16a04ca790c2b
Cc: Jan Beulich <JBeulich@suse.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen4.2 S3 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>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--f46d0432b1c2f2f16a04ca790c2b
Content-Type: multipart/alternative; boundary=f46d0432b1c2f2f16604ca790c29

--f46d0432b1c2f2f16604ca790c29
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

Here's my "Big hammer" debugging patch.

If I force the cpu to be scheduled on CPU0 when the appropriate cpu is not
online, I can resume properly.

Clearly this is not the proper solution, and I'm sure the fix is subtle.
I'm not seeing it right now though. Perhaps tomorrow morning.
If you have any ideas, I'm happy to run tests then.

/btg

On Mon, Sep 24, 2012 at 4:46 PM, Ben Guthro <ben@guthro.net> wrote:

> I've managed to determine that _csched_cpu_pick is, for reasons not yet
> clear, picking a cpu id outside of the range of cpus that are valid for
> this system
> (in this case cpu id 4, on a 2 core machine)
>
>
>
> On Mon, Sep 24, 2012 at 4:30 PM, Keir Fraser <keir.xen@gmail.com> wrote:
>
>>  Do a debug build so the backtrace can be trusted. It=92s a NULL pointer
>> dereference so shouldn=92t be too tricky to make some headway on this on=
e.
>> Easier than the previous bug. :)
>>
>>  -- Keir
>>
>>
>> On 24/09/2012 20:02, "Ben Guthro" <ben@guthro.net> wrote:
>>
>> Well...knock one bug down - and another crops up.
>>
>> It appears that dom0_vcpu_pin is incompatible with S3.
>> I'll start digging into why, but if you have any thoughts from the stack
>> below, I'd welcome any pointers.
>>
>> /btg
>>
>>
>> (XEN) Preparing system for ACPI S3 state.
>> (XEN) Disabling non-boot CPUs ...
>> (XEN) Entering ACPI S3 state.
>> (XEN) mce_intel.c:1239: MCA Capability: BCAST 1 SER 0 CMCI 0 firstbank 1
>> extended MCE MSR 0
>> (XEN) CMCI: CPU0 has no CMCI support
>> (XEN) CPU0: Thermal monitoring enabled (TM2)
>> (XEN) Finishing wakeup from ACPI S3 state.
>> (XEN) Enabling non-boot CPUs  ...
>> (XEN) Booting processor 1/1 eip 8a000
>> (XEN) Initializing CPU#1
>> (XEN) CPU: L1 I cache: 32K, L1 D cache: 32K
>> (XEN) CPU: L2 cache: 3072K
>> (XEN) CPU: Physical Processor ID: 0
>> (XEN) CPU: Processor Core ID: 1
>> (XEN) CMCI: CPU1 has no CMCI support
>> (XEN) CPU1: Thermal monitoring enabled (TM2)
>> (XEN) CPU1: Intel(R) Core(TM)2 Duo CPU     P8400  @ 2.26GHz stepping 06
>> (XEN) microcode: CPU1 updated from revision 0x60c to 0x60f, date =3D
>> 2010-09-29
>> [   60.100054] ACPI: Low-level resume complete
>> [   60.100054] PM: Restoring platform NVS memory
>> [   60.100054] Enabling non-boot CPUs ...
>> [   60.100054] installing Xen timer for CPU 1
>> [   60.100054] cpu 1 spinlock event irq 279
>> (XEN) ----[ Xen-4.2.1-pre  x86_64  debug=3Dn  Tainted:    C ]----
>> (XEN) CPU:    1
>> (XEN) RIP:    e008:[<ffff82c480121562>] vcpu_migrate+0x172/0x360
>> (XEN) RFLAGS: 0000000000010096   CONTEXT: hypervisor
>> (XEN) rax: 00007d3b7fd17180   rbx: ffff82c4802e8ee0   rcx:
>> ffff82c4802e8ee0
>> (XEN) rdx: ffff83013a3c5068   rsi: 0000000000000004   rdi:
>> ffff8301300b7d68
>> (XEN) rbp: 0000000000000001   rsp: ffff8301300b7e28   r8:
>>  0000000000000000
>> (XEN) r9:  000000000000003e   r10: 000000000000003e   r11:
>> 0000000000000246
>> (XEN) r12: ffff83013a3c5068   r13: ffff83013a3c5068   r14:
>> ffff82c4802d3140
>> (XEN) r15: 0000000000000001   cr0: 000000008005003b   cr4:
>> 00000000000026f0
>> (XEN) cr3: 0000000131a05000   cr2: 0000000000000060
>> (XEN) ds: 002b   es: 002b   fs: 0000   gs: 0000   ss: e010   cs: e008
>> (XEN) Xen stack trace from rsp=3Dffff8301300b7e28:
>> (XEN)    ffff82c4802d3140 ffff83013a3c5068 0000000000000246
>> 0000000000000004
>> (XEN)    ffff8300bd2fe000 ffff82c4802e8ee0 00000004012d3140
>> ffff82c4802e8ee0
>> (XEN)    ffff88003fc8e820 ffff8300bd2fe000 ffff8301355d8000
>> 0000000000000000
>> (XEN)    0000000000000000 0000000000000000 ffff88003fc8e820
>> ffff82c480105a50
>> (XEN)    0000000000000000 ffff82c4801805ec 0000060f00000000
>> ffff82c480184f16
>> (XEN)    0000000000000032 78a20f6e65780b0f ffff88003976fdc8
>> ffff8300bd2fe000
>> (XEN)    ffff88003976fe50 ffff8300bd2fe000 ffff88003976fda0
>> 0000000000000001
>> (XEN)    0000000000000000 ffff82c480214288 ffff88003fc8e820
>> 0000000000000000
>> (XEN)    0000000000000000 0000000000000001 ffff88003976fda0
>> ffff88003fc8bdc0
>> (XEN)    0000000000000246 ffff88003976fe60 00000000ffffffff
>> 0000000000000000
>> (XEN)    0000000000000018 ffffffff8100130a 0000000000000000
>> 0000000000000001
>> (XEN)    0000000000000007 0000010000000000 ffffffff8100130a
>> 000000000000e033
>> (XEN)    0000000000000246 ffff88003976fd88 000000000000e02b
>> d43d5f3fedaef5e7
>> (XEN)    d3b2ddaeed5038ff 270adb813ad76c9b ddfd6ff5f85e6775
>> b5881cbf00000001
>> (XEN)    ffff8300bd2fe000 0000003cba0dc180 0a109ac649c118a1
>> (XEN) Xen call trace:
>> (XEN)    [<ffff82c480121562>] vcpu_migrate+0x172/0x360
>> (XEN)    [<ffff82c480105a50>] do_vcpu_op+0x1e0/0x4a0
>> (XEN)    [<ffff82c4801805ec>] do_invalid_op+0x19c/0x3f0
>> (XEN)    [<ffff82c480184f16>] copy_from_user+0x26/0x90
>> (XEN)    [<ffff82c480214288>] syscall_enter+0x88/0x8d
>> (XEN)
>> (XEN) Pagetable walk from 0000000000000060:
>> (XEN)  L4[0x000] =3D 0000000000000000 ffffffffffffffff
>> (XEN)
>> (XEN) ****************************************
>> (XEN) Panic on CPU 1:
>> (XEN) FATAL PAGE FAULT
>> (XEN) [error_code=3D0000]
>> (XEN) Faulting linear address: 0000000000000060
>> (XEN) ****************************************
>> (XEN)
>> (XEN) Reboot in five seconds...
>>
>>
>> On Mon, Sep 24, 2012 at 10:28 AM, Jan Beulich <JBeulich@suse.com> wrote:
>>
>> >>> On 24.09.12 at 16:16, Ben Guthro <ben@guthro.net> wrote:
>> > Would you prefer a separate [PATCH] email for this fix, or will you
>> apply
>> > it as-is?
>>
>> I'll put something together - the most important thing here obviously
>> is having a proper description. Plus I'd like to slightly extend this an=
d
>> have acpi_dead_idle() actually use default_dead_idle(), just to have
>> things consolidated in one place. I assume I can put your S-o-b on
>> what you sent...
>>
>> Jan
>>
>> > On Mon, Sep 24, 2012 at 10:10 AM, Jan Beulich <JBeulich@suse.com>
>> wrote:
>> >
>> >> >>> On 24.09.12 at 15:56, Ben Guthro <ben@guthro.net> wrote:
>> >> > On Mon, Sep 24, 2012 at 9:34 AM, Jan Beulich <JBeulich@suse.com>
>> wrote:
>> >> >> ...; the interesting ones are
>> >> >> - at the end of xen/arch/x86/acpu/cpu_idle.c:acpi_dead_idle()
>> >> >> - xen/arch/x86/domain.c:default_dead_idle()
>> >> >
>> >> >
>> >> > Thanks! This fixes the issue on this machine!
>> >>
>> >> Hooray!
>> >>
>> >> > Is this a reasonable long-term solution - or are there reasons not =
to
>> >> > call wbinvd() here?
>> >>
>> >> That's a perfectly valid adjustment (see my earlier reply where
>> >> I originally suggested it and explained why it may be necessary).
>> >>
>> >> Jan
>> >>
>> >>
>>
>>
>>
>>
>>
>> ------------------------------
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xen.org
>> http://lists.xen.org/xen-devel
>>
>>
>

--f46d0432b1c2f2f16604ca790c29
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

Here&#39;s my &quot;Big hammer&quot; debugging patch.<div><br></div><div>If=
 I force the cpu to be scheduled on CPU0 when the appropriate cpu is not on=
line, I can resume properly.</div><div><br></div><div>Clearly this is not t=
he proper solution, and I&#39;m sure the fix is subtle. I&#39;m not seeing =
it right now though. Perhaps tomorrow morning.</div>
<div>If you have any ideas, I&#39;m happy to run tests then.</div><div><br>=
</div><div>/btg<br><br><div class=3D"gmail_quote">On Mon, Sep 24, 2012 at 4=
:46 PM, Ben Guthro <span dir=3D"ltr">&lt;<a href=3D"mailto:ben@guthro.net" =
target=3D"_blank">ben@guthro.net</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">I&#39;ve managed to determine that _csched_c=
pu_pick=A0is, for reasons not yet clear, picking a cpu id outside of the ra=
nge of cpus that are valid for this system<div>
(in this case cpu id 4, on a 2 core machine)</div><div class=3D"HOEnZb"><di=
v class=3D"h5"><div><br>
</div><div><br><br><div class=3D"gmail_quote">On Mon, Sep 24, 2012 at 4:30 =
PM, Keir Fraser <span dir=3D"ltr">&lt;<a href=3D"mailto:keir.xen@gmail.com"=
 target=3D"_blank">keir.xen@gmail.com</a>&gt;</span> wrote:<br><blockquote =
class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid=
;padding-left:1ex">





<div>
<font face=3D"Calibri, Verdana, Helvetica, Arial"><span style=3D"font-size:=
11pt">Do a debug build so the backtrace can be trusted. It=92s a NULL point=
er dereference so shouldn=92t be too tricky to make some headway on this on=
e. Easier than the previous bug. :)<span><font color=3D"#888888"><br>


<br>
=A0-- Keir</font></span><div><div><br>
<br>
On 24/09/2012 20:02, &quot;Ben Guthro&quot; &lt;<a href=3D"http://ben@guthr=
o.net" target=3D"_blank">ben@guthro.net</a>&gt; wrote:<br>
<br>
</div></div></span></font><blockquote><div><div><font face=3D"Calibri, Verd=
ana, Helvetica, Arial"><span style=3D"font-size:11pt">Well...knock one bug =
down - and another crops up.<br>
<br>
It appears that dom0_vcpu_pin is incompatible with S3.<br>
I&#39;ll start digging into why, but if you have any thoughts from the stac=
k below, I&#39;d welcome any pointers.<br>
<br>
/btg<br>
<br>
<br>
(XEN) Preparing system for ACPI S3 state.<br>
(XEN) Disabling non-boot CPUs ...<br>
(XEN) Entering ACPI S3 state.<br>
(XEN) mce_intel.c:1239: MCA Capability: BCAST 1 SER 0 CMCI 0 firstbank 1 ex=
tended MCE MSR 0<br>
(XEN) CMCI: CPU0 has no CMCI support<br>
(XEN) CPU0: Thermal monitoring enabled (TM2)<br>
(XEN) Finishing wakeup from ACPI S3 state.<br>
(XEN) Enabling non-boot CPUs =A0...<br>
(XEN) Booting processor 1/1 eip 8a000<br>
(XEN) Initializing CPU#1<br>
(XEN) CPU: L1 I cache: 32K, L1 D cache: 32K<br>
(XEN) CPU: L2 cache: 3072K<br>
(XEN) CPU: Physical Processor ID: 0<br>
(XEN) CPU: Processor Core ID: 1<br>
(XEN) CMCI: CPU1 has no CMCI support<br>
(XEN) CPU1: Thermal monitoring enabled (TM2)<br>
(XEN) CPU1: Intel(R) Core(TM)2 Duo CPU =A0 =A0 P8400 =A0@ 2.26GHz stepping =
06<br>
(XEN) microcode: CPU1 updated from revision 0x60c to 0x60f, date =3D 2010-0=
9-29=A0<br>
[ =A0 60.100054] ACPI: Low-level resume complete<br>
[ =A0 60.100054] PM: Restoring platform NVS memory<br>
[ =A0 60.100054] Enabling non-boot CPUs ...<br>
[ =A0 60.100054] installing Xen timer for CPU 1<br>
[ =A0 60.100054] cpu 1 spinlock event irq 279<br>
(XEN) ----[ Xen-4.2.1-pre =A0x86_64 =A0debug=3Dn =A0Tainted: =A0 =A0C ]----=
<br>
(XEN) CPU: =A0 =A01<br>
(XEN) RIP: =A0 =A0e008:[&lt;ffff82c480121562&gt;] vcpu_migrate+0x172/0x360<=
br>
(XEN) RFLAGS: 0000000000010096 =A0 CONTEXT: hypervisor<br>
(XEN) rax: 00007d3b7fd17180 =A0 rbx: ffff82c4802e8ee0 =A0 rcx: ffff82c4802e=
8ee0<br>
(XEN) rdx: ffff83013a3c5068 =A0 rsi: 0000000000000004 =A0 rdi: ffff8301300b=
7d68<br>
(XEN) rbp: 0000000000000001 =A0 rsp: ffff8301300b7e28 =A0 r8: =A00000000000=
000000<br>
(XEN) r9: =A0000000000000003e =A0 r10: 000000000000003e =A0 r11: 0000000000=
000246<br>
(XEN) r12: ffff83013a3c5068 =A0 r13: ffff83013a3c5068 =A0 r14: ffff82c4802d=
3140<br>
(XEN) r15: 0000000000000001 =A0 cr0: 000000008005003b =A0 cr4: 000000000000=
26f0<br>
(XEN) cr3: 0000000131a05000 =A0 cr2: 0000000000000060<br>
(XEN) ds: 002b =A0 es: 002b =A0 fs: 0000 =A0 gs: 0000 =A0 ss: e010 =A0 cs: =
e008<br>
(XEN) Xen stack trace from rsp=3Dffff8301300b7e28:<br>
(XEN) =A0 =A0ffff82c4802d3140 ffff83013a3c5068 0000000000000246 00000000000=
00004<br>
(XEN) =A0 =A0ffff8300bd2fe000 ffff82c4802e8ee0 00000004012d3140 ffff82c4802=
e8ee0<br>
(XEN) =A0 =A0ffff88003fc8e820 ffff8300bd2fe000 ffff8301355d8000 00000000000=
00000<br>
(XEN) =A0 =A00000000000000000 0000000000000000 ffff88003fc8e820 ffff82c4801=
05a50<br>
(XEN) =A0 =A00000000000000000 ffff82c4801805ec 0000060f00000000 ffff82c4801=
84f16<br>
(XEN) =A0 =A00000000000000032 78a20f6e65780b0f ffff88003976fdc8 ffff8300bd2=
fe000<br>
(XEN) =A0 =A0ffff88003976fe50 ffff8300bd2fe000 ffff88003976fda0 00000000000=
00001<br>
(XEN) =A0 =A00000000000000000 ffff82c480214288 ffff88003fc8e820 00000000000=
00000<br>
(XEN) =A0 =A00000000000000000 0000000000000001 ffff88003976fda0 ffff88003fc=
8bdc0<br>
(XEN) =A0 =A00000000000000246 ffff88003976fe60 00000000ffffffff 00000000000=
00000<br>
(XEN) =A0 =A00000000000000018 ffffffff8100130a 0000000000000000 00000000000=
00001<br>
(XEN) =A0 =A00000000000000007 0000010000000000 ffffffff8100130a 00000000000=
0e033<br>
(XEN) =A0 =A00000000000000246 ffff88003976fd88 000000000000e02b d43d5f3feda=
ef5e7<br>
(XEN) =A0 =A0d3b2ddaeed5038ff 270adb813ad76c9b ddfd6ff5f85e6775 b5881cbf000=
00001<br>
(XEN) =A0 =A0ffff8300bd2fe000 0000003cba0dc180 0a109ac649c118a1<br>
(XEN) Xen call trace:<br>
(XEN) =A0 =A0[&lt;ffff82c480121562&gt;] vcpu_migrate+0x172/0x360<br>
(XEN) =A0 =A0[&lt;ffff82c480105a50&gt;] do_vcpu_op+0x1e0/0x4a0<br>
(XEN) =A0 =A0[&lt;ffff82c4801805ec&gt;] do_invalid_op+0x19c/0x3f0<br>
(XEN) =A0 =A0[&lt;ffff82c480184f16&gt;] copy_from_user+0x26/0x90<br>
(XEN) =A0 =A0[&lt;ffff82c480214288&gt;] syscall_enter+0x88/0x8d<br>
(XEN) =A0 =A0<br>
(XEN) Pagetable walk from 0000000000000060:<br>
(XEN) =A0L4[0x000] =3D 0000000000000000 ffffffffffffffff<br>
(XEN)=A0<br>
(XEN) ****************************************<br>
(XEN) Panic on CPU 1:<br>
(XEN) FATAL PAGE FAULT<br>
(XEN) [error_code=3D0000]<br>
(XEN) Faulting linear address: 0000000000000060<br>
(XEN) ****************************************<br>
(XEN)=A0<br>
(XEN) Reboot in five seconds...<br>
<br>
<br>
On Mon, Sep 24, 2012 at 10:28 AM, Jan Beulich &lt;<a href=3D"http://JBeulic=
h@suse.com" target=3D"_blank">JBeulich@suse.com</a>&gt; wrote:<br>
</span></font><blockquote><font face=3D"Calibri, Verdana, Helvetica, Arial"=
><span style=3D"font-size:11pt">&gt;&gt;&gt; On 24.09.12 at 16:16, Ben Guth=
ro &lt;<a href=3D"http://ben@guthro.net" target=3D"_blank">ben@guthro.net</=
a>&gt; wrote:<br>


&gt; Would you prefer a separate [PATCH] email for this fix, or will you ap=
ply<br>
&gt; it as-is?<br>
<br>
I&#39;ll put something together - the most important thing here obviously<b=
r>
is having a proper description. Plus I&#39;d like to slightly extend this a=
nd<br>
have acpi_dead_idle() actually use default_dead_idle(), just to have<br>
things consolidated in one place. I assume I can put your S-o-b on<br>
what you sent...<br>
<font color=3D"#888888"><br>
Jan<br>
</font><br>
&gt; On Mon, Sep 24, 2012 at 10:10 AM, Jan Beulich &lt;<a href=3D"http://JB=
eulich@suse.com" target=3D"_blank">JBeulich@suse.com</a>&gt; wrote:<br>
&gt;<br>
&gt;&gt; &gt;&gt;&gt; On 24.09.12 at 15:56, Ben Guthro &lt;<a href=3D"http:=
//ben@guthro.net" target=3D"_blank">ben@guthro.net</a>&gt; wrote:<br>
&gt;&gt; &gt; On Mon, Sep 24, 2012 at 9:34 AM, Jan Beulich &lt;<a href=3D"h=
ttp://JBeulich@suse.com" target=3D"_blank">JBeulich@suse.com</a>&gt; wrote:=
<br>
&gt;&gt; &gt;&gt; ...; the interesting ones are<br>
&gt;&gt; &gt;&gt; - at the end of xen/arch/x86/acpu/cpu_idle.c:acpi_dead_id=
le()<br>
&gt;&gt; &gt;&gt; - xen/arch/x86/domain.c:default_dead_idle()<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; Thanks! This fixes the issue on this machine!<br>
&gt;&gt;<br>
&gt;&gt; Hooray!<br>
&gt;&gt;<br>
&gt;&gt; &gt; Is this a reasonable long-term solution - or are there reason=
s not to<br>
&gt;&gt; &gt; call wbinvd() here?<br>
&gt;&gt;<br>
&gt;&gt; That&#39;s a perfectly valid adjustment (see my earlier reply wher=
e<br>
&gt;&gt; I originally suggested it and explained why it may be necessary).<=
br>
&gt;&gt;<br>
&gt;&gt; Jan<br>
&gt;&gt;<br>
&gt;&gt;<br>
<br>
<br>
<br>
</span></font></blockquote></div></div><font face=3D"Calibri, Verdana, Helv=
etica, Arial"><span style=3D"font-size:11pt"><br>
<br>
<hr align=3D"CENTER" size=3D"3" width=3D"95%"></span></font><div><font><fon=
t face=3D"Consolas, Courier New, Courier"><span style=3D"font-size:10pt">__=
_____________________________________________<br>
Xen-devel mailing list<br>
<a href=3D"http://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>
</span></font></font></div></blockquote>
</div>


</blockquote></div><br></div>
</div></div></blockquote></div><br></div>

--f46d0432b1c2f2f16604ca790c29--
--f46d0432b1c2f2f16a04ca790c2b
Content-Type: application/octet-stream; name="debug1.patch"
Content-Disposition: attachment; filename="debug1.patch"
Content-Transfer-Encoding: base64
X-Attachment-Id: f_h7i2jrbx0

ZGlmZiAtLWdpdCBhL3hlbi9jb21tb24vc2NoZWRfY3JlZGl0LmMgYi94ZW4vY29tbW9uL3NjaGVk
X2NyZWRpdC5jCmluZGV4IGE5ODAyYTEuLmUwN2IxMjMgMTAwNjQ0Ci0tLSBhL3hlbi9jb21tb24v
c2NoZWRfY3JlZGl0LmMKKysrIGIveGVuL2NvbW1vbi9zY2hlZF9jcmVkaXQuYwpAQCAtMjMsNiAr
MjMsOCBAQAogI2luY2x1ZGUgPHhlbi9lcnJuby5oPgogI2luY2x1ZGUgPHhlbi9rZXloYW5kbGVy
Lmg+CiAKK3N0YXRpYyB2b2lkIGNzY2hlZF9kdW1wKGNvbnN0IHN0cnVjdCBzY2hlZHVsZXIgKm9w
cyk7CisKIC8qCiAgKiBDU0NIRURfU1RBVFMKICAqCkBAIC00NTYsNiArNDU4LDkgQEAgX19jc2No
ZWRfdmNwdV9pc19taWdyYXRlYWJsZShzdHJ1Y3QgdmNwdSAqdmMsIGludCBkZXN0X2NwdSkKICAg
ICAgICAgICAgY3B1bWFza190ZXN0X2NwdShkZXN0X2NwdSwgdmMtPmNwdV9hZmZpbml0eSk7CiB9
CiAKK3N0YXRpYyBjaGFyIHRzdHIxWzEwMF07CitzdGF0aWMgY2hhciB0c3RyMlsxMDBdOworCiBz
dGF0aWMgaW50CiBfY3NjaGVkX2NwdV9waWNrKGNvbnN0IHN0cnVjdCBzY2hlZHVsZXIgKm9wcywg
c3RydWN0IHZjcHUgKnZjLCBib29sX3QgY29tbWl0KQogewpAQCAtNDczLDcgKzQ3OCw4IEBAIF9j
c2NoZWRfY3B1X3BpY2soY29uc3Qgc3RydWN0IHNjaGVkdWxlciAqb3BzLCBzdHJ1Y3QgdmNwdSAq
dmMsIGJvb2xfdCBjb21taXQpCiAgICAgY3B1bWFza19hbmQoJmNwdXMsIG9ubGluZSwgdmMtPmNw
dV9hZmZpbml0eSk7CiAgICAgY3B1ID0gY3B1bWFza190ZXN0X2NwdSh2Yy0+cHJvY2Vzc29yLCAm
Y3B1cykKICAgICAgICAgICAgID8gdmMtPnByb2Nlc3NvcgotICAgICAgICAgICAgOiBjcHVtYXNr
X2N5Y2xlKHZjLT5wcm9jZXNzb3IsICZjcHVzKTsKKyAgICAgICAgICAgIDogMDsKKy8vICAgICAg
ICAgICAgOiBjcHVtYXNrX2N5Y2xlKHZjLT5wcm9jZXNzb3IsICZjcHVzKTsKICAgICBBU1NFUlQo
ICFjcHVtYXNrX2VtcHR5KCZjcHVzKSAmJiBjcHVtYXNrX3Rlc3RfY3B1KGNwdSwgJmNwdXMpICk7
CiAKICAgICAvKgpAQCAtNTQyLDYgKzU0OCwxNCBAQCBfY3NjaGVkX2NwdV9waWNrKGNvbnN0IHN0
cnVjdCBzY2hlZHVsZXIgKm9wcywgc3RydWN0IHZjcHUgKnZjLCBib29sX3QgY29tbWl0KQogICAg
IGlmICggY29tbWl0ICYmIHNwYyApCiAgICAgICAgc3BjLT5pZGxlX2JpYXMgPSBjcHU7CiAKKwor
ICAgIGlmIChjcHUgPiAxKSB7CisJICAgIGNzY2hlZF9kdW1wKG9wcyk7CisJICAgIGNwdW1hc2tf
c2NucHJpbnRmKHRzdHIxLCBzaXplb2YodHN0cjEpLCBvbmxpbmUpOworCSAgICBjcHVtYXNrX3Nj
bnByaW50Zih0c3RyMiwgc2l6ZW9mKHRzdHIyKSwgdmMtPmNwdV9hZmZpbml0eSk7CisKKwkgICAg
cHJpbnRrKCJNQVNLUzogb25saW5lPSVzIGFmZmluaXR5PSVzXG4iLCB0c3RyMSwgdHN0cjIpOwor
ICAgIH0KICAgICByZXR1cm4gY3B1OwogfQogCmRpZmYgLS1naXQgYS94ZW4vY29tbW9uL3NjaGVk
dWxlLmMgYi94ZW4vY29tbW9uL3NjaGVkdWxlLmMKaW5kZXggMTMxNzhlMC4uMWRhYjZkMyAxMDA2
NDQKLS0tIGEveGVuL2NvbW1vbi9zY2hlZHVsZS5jCisrKyBiL3hlbi9jb21tb24vc2NoZWR1bGUu
YwpAQCAtNDQ1LDYgKzQ0NSw3IEBAIHN0YXRpYyB2b2lkIHZjcHVfbWlncmF0ZShzdHJ1Y3QgdmNw
dSAqdikKIAogICAgICAgICAgICAgLyogU2VsZWN0IGEgbmV3IENQVS4gKi8KICAgICAgICAgICAg
IG5ld19jcHUgPSBTQ0hFRF9PUChWQ1BVMk9QKHYpLCBwaWNrX2NwdSwgdik7CisgICAgICAgICAg
ICBwcmludGsoIiVzOiVkICglcykgbmV3X2NwdT0lZCBvbmxpbmU9JWRcbiIsIF9fRklMRV9fLCBf
X0xJTkVfXywgX19mdW5jX18sIG5ld19jcHUsIG51bV9vbmxpbmVfY3B1cygpKTsKICAgICAgICAg
ICAgIGlmICggKG5ld19sb2NrID09IHBlcl9jcHUoc2NoZWR1bGVfZGF0YSwgbmV3X2NwdSkuc2No
ZWR1bGVfbG9jaykgJiYKICAgICAgICAgICAgICAgICAgY3B1bWFza190ZXN0X2NwdShuZXdfY3B1
LCB2LT5kb21haW4tPmNwdXBvb2wtPmNwdV92YWxpZCkgKQogICAgICAgICAgICAgICAgIGJyZWFr
Owo=
--f46d0432b1c2f2f16a04ca790c2b
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--f46d0432b1c2f2f16a04ca790c2b--


From xen-devel-bounces@lists.xen.org Mon Sep 24 21:13:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Sep 2012 21:13:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGFxS-00048j-D4; Mon, 24 Sep 2012 21:12:50 +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 1TGFxQ-00048M-4r
	for xen-devel@lists.xen.org; Mon, 24 Sep 2012 21:12:48 +0000
Received: from [85.158.138.51:63160] by server-13.bemta-3.messagelabs.com id
	29/2C-01606-FCCC0605; Mon, 24 Sep 2012 21:12:47 +0000
X-Env-Sender: ben.guthro@gmail.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1348521164!23721263!1
X-Originating-IP: [209.85.212.45]
X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_30_40,HTML_MESSAGE,
	RCVD_BY_IP,USERPASS
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27603 invoked from network); 24 Sep 2012 21:12:45 -0000
Received: from mail-vb0-f45.google.com (HELO mail-vb0-f45.google.com)
	(209.85.212.45)
	by server-3.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Sep 2012 21:12:45 -0000
Received: by vbip1 with SMTP id p1so7994660vbi.32
	for <xen-devel@lists.xen.org>; Mon, 24 Sep 2012 14:12:44 -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=uLGv29Lo7vBk2woHt0u8mCsCumkUBCw+AeOWN3NAxg0=;
	b=OnSXH+JF7YRNStb7FHkgf6jw/bSuyI/8shk+SWi1dcs732w4t7NQUcB7XowErokT7Y
	UXapPeA31aWQWwr/WJKYe+QyfTdwXaaQ/C4vIoUjlNc2eRDKhsio8DL8+dVuSy0nA9QY
	5Kzcx0Z/fQrFcIpvlSuvb9qp7CpqXp+un6N5NZXsgu5tTqT25df1qllybCGi+SMY3kqq
	EmmqEB+jkLWFkMCer4gct906ZQWWfyTjv+uDMbCAyHg28WADMk919zyB8H4yxCWgfbtg
	jc4Cbgy3nCURm8oJuXxKSD8ftb+ObBXqiXbhL664r/pt0InOmgQYkfpJrmkTKwJpQsYY
	Jj7Q==
MIME-Version: 1.0
Received: by 10.220.106.143 with SMTP id x15mr8108058vco.33.1348521163944;
	Mon, 24 Sep 2012 14:12:43 -0700 (PDT)
Received: by 10.58.137.169 with HTTP; Mon, 24 Sep 2012 14:12:43 -0700 (PDT)
In-Reply-To: <CAOvdn6U-JyLvt96gkLkqzi088tU9_ktv4D+fkJac_BKVe05Y-w@mail.gmail.com>
References: <CAOvdn6UCF2A3yP1cqWn=dxwr0ayRbr+rg+xj8META9Dm0+CoNw@mail.gmail.com>
	<CC868168.3FD29%keir.xen@gmail.com>
	<CAOvdn6U-JyLvt96gkLkqzi088tU9_ktv4D+fkJac_BKVe05Y-w@mail.gmail.com>
Date: Mon, 24 Sep 2012 17:12:43 -0400
X-Google-Sender-Auth: fFeAQLK1JAe-ym1cmwg01CLi9GQ
Message-ID: <CAOvdn6V+s3AbRzsu8VArbmrZou=im9SqvPf-9Wpif_BrNMv=yg@mail.gmail.com>
From: Ben Guthro <ben@guthro.net>
To: Keir Fraser <keir.xen@gmail.com>
Content-Type: multipart/mixed; boundary=f46d0432b1c2f2f16a04ca790c2b
Cc: Jan Beulich <JBeulich@suse.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen4.2 S3 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>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--f46d0432b1c2f2f16a04ca790c2b
Content-Type: multipart/alternative; boundary=f46d0432b1c2f2f16604ca790c29

--f46d0432b1c2f2f16604ca790c29
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

Here's my "Big hammer" debugging patch.

If I force the cpu to be scheduled on CPU0 when the appropriate cpu is not
online, I can resume properly.

Clearly this is not the proper solution, and I'm sure the fix is subtle.
I'm not seeing it right now though. Perhaps tomorrow morning.
If you have any ideas, I'm happy to run tests then.

/btg

On Mon, Sep 24, 2012 at 4:46 PM, Ben Guthro <ben@guthro.net> wrote:

> I've managed to determine that _csched_cpu_pick is, for reasons not yet
> clear, picking a cpu id outside of the range of cpus that are valid for
> this system
> (in this case cpu id 4, on a 2 core machine)
>
>
>
> On Mon, Sep 24, 2012 at 4:30 PM, Keir Fraser <keir.xen@gmail.com> wrote:
>
>>  Do a debug build so the backtrace can be trusted. It=92s a NULL pointer
>> dereference so shouldn=92t be too tricky to make some headway on this on=
e.
>> Easier than the previous bug. :)
>>
>>  -- Keir
>>
>>
>> On 24/09/2012 20:02, "Ben Guthro" <ben@guthro.net> wrote:
>>
>> Well...knock one bug down - and another crops up.
>>
>> It appears that dom0_vcpu_pin is incompatible with S3.
>> I'll start digging into why, but if you have any thoughts from the stack
>> below, I'd welcome any pointers.
>>
>> /btg
>>
>>
>> (XEN) Preparing system for ACPI S3 state.
>> (XEN) Disabling non-boot CPUs ...
>> (XEN) Entering ACPI S3 state.
>> (XEN) mce_intel.c:1239: MCA Capability: BCAST 1 SER 0 CMCI 0 firstbank 1
>> extended MCE MSR 0
>> (XEN) CMCI: CPU0 has no CMCI support
>> (XEN) CPU0: Thermal monitoring enabled (TM2)
>> (XEN) Finishing wakeup from ACPI S3 state.
>> (XEN) Enabling non-boot CPUs  ...
>> (XEN) Booting processor 1/1 eip 8a000
>> (XEN) Initializing CPU#1
>> (XEN) CPU: L1 I cache: 32K, L1 D cache: 32K
>> (XEN) CPU: L2 cache: 3072K
>> (XEN) CPU: Physical Processor ID: 0
>> (XEN) CPU: Processor Core ID: 1
>> (XEN) CMCI: CPU1 has no CMCI support
>> (XEN) CPU1: Thermal monitoring enabled (TM2)
>> (XEN) CPU1: Intel(R) Core(TM)2 Duo CPU     P8400  @ 2.26GHz stepping 06
>> (XEN) microcode: CPU1 updated from revision 0x60c to 0x60f, date =3D
>> 2010-09-29
>> [   60.100054] ACPI: Low-level resume complete
>> [   60.100054] PM: Restoring platform NVS memory
>> [   60.100054] Enabling non-boot CPUs ...
>> [   60.100054] installing Xen timer for CPU 1
>> [   60.100054] cpu 1 spinlock event irq 279
>> (XEN) ----[ Xen-4.2.1-pre  x86_64  debug=3Dn  Tainted:    C ]----
>> (XEN) CPU:    1
>> (XEN) RIP:    e008:[<ffff82c480121562>] vcpu_migrate+0x172/0x360
>> (XEN) RFLAGS: 0000000000010096   CONTEXT: hypervisor
>> (XEN) rax: 00007d3b7fd17180   rbx: ffff82c4802e8ee0   rcx:
>> ffff82c4802e8ee0
>> (XEN) rdx: ffff83013a3c5068   rsi: 0000000000000004   rdi:
>> ffff8301300b7d68
>> (XEN) rbp: 0000000000000001   rsp: ffff8301300b7e28   r8:
>>  0000000000000000
>> (XEN) r9:  000000000000003e   r10: 000000000000003e   r11:
>> 0000000000000246
>> (XEN) r12: ffff83013a3c5068   r13: ffff83013a3c5068   r14:
>> ffff82c4802d3140
>> (XEN) r15: 0000000000000001   cr0: 000000008005003b   cr4:
>> 00000000000026f0
>> (XEN) cr3: 0000000131a05000   cr2: 0000000000000060
>> (XEN) ds: 002b   es: 002b   fs: 0000   gs: 0000   ss: e010   cs: e008
>> (XEN) Xen stack trace from rsp=3Dffff8301300b7e28:
>> (XEN)    ffff82c4802d3140 ffff83013a3c5068 0000000000000246
>> 0000000000000004
>> (XEN)    ffff8300bd2fe000 ffff82c4802e8ee0 00000004012d3140
>> ffff82c4802e8ee0
>> (XEN)    ffff88003fc8e820 ffff8300bd2fe000 ffff8301355d8000
>> 0000000000000000
>> (XEN)    0000000000000000 0000000000000000 ffff88003fc8e820
>> ffff82c480105a50
>> (XEN)    0000000000000000 ffff82c4801805ec 0000060f00000000
>> ffff82c480184f16
>> (XEN)    0000000000000032 78a20f6e65780b0f ffff88003976fdc8
>> ffff8300bd2fe000
>> (XEN)    ffff88003976fe50 ffff8300bd2fe000 ffff88003976fda0
>> 0000000000000001
>> (XEN)    0000000000000000 ffff82c480214288 ffff88003fc8e820
>> 0000000000000000
>> (XEN)    0000000000000000 0000000000000001 ffff88003976fda0
>> ffff88003fc8bdc0
>> (XEN)    0000000000000246 ffff88003976fe60 00000000ffffffff
>> 0000000000000000
>> (XEN)    0000000000000018 ffffffff8100130a 0000000000000000
>> 0000000000000001
>> (XEN)    0000000000000007 0000010000000000 ffffffff8100130a
>> 000000000000e033
>> (XEN)    0000000000000246 ffff88003976fd88 000000000000e02b
>> d43d5f3fedaef5e7
>> (XEN)    d3b2ddaeed5038ff 270adb813ad76c9b ddfd6ff5f85e6775
>> b5881cbf00000001
>> (XEN)    ffff8300bd2fe000 0000003cba0dc180 0a109ac649c118a1
>> (XEN) Xen call trace:
>> (XEN)    [<ffff82c480121562>] vcpu_migrate+0x172/0x360
>> (XEN)    [<ffff82c480105a50>] do_vcpu_op+0x1e0/0x4a0
>> (XEN)    [<ffff82c4801805ec>] do_invalid_op+0x19c/0x3f0
>> (XEN)    [<ffff82c480184f16>] copy_from_user+0x26/0x90
>> (XEN)    [<ffff82c480214288>] syscall_enter+0x88/0x8d
>> (XEN)
>> (XEN) Pagetable walk from 0000000000000060:
>> (XEN)  L4[0x000] =3D 0000000000000000 ffffffffffffffff
>> (XEN)
>> (XEN) ****************************************
>> (XEN) Panic on CPU 1:
>> (XEN) FATAL PAGE FAULT
>> (XEN) [error_code=3D0000]
>> (XEN) Faulting linear address: 0000000000000060
>> (XEN) ****************************************
>> (XEN)
>> (XEN) Reboot in five seconds...
>>
>>
>> On Mon, Sep 24, 2012 at 10:28 AM, Jan Beulich <JBeulich@suse.com> wrote:
>>
>> >>> On 24.09.12 at 16:16, Ben Guthro <ben@guthro.net> wrote:
>> > Would you prefer a separate [PATCH] email for this fix, or will you
>> apply
>> > it as-is?
>>
>> I'll put something together - the most important thing here obviously
>> is having a proper description. Plus I'd like to slightly extend this an=
d
>> have acpi_dead_idle() actually use default_dead_idle(), just to have
>> things consolidated in one place. I assume I can put your S-o-b on
>> what you sent...
>>
>> Jan
>>
>> > On Mon, Sep 24, 2012 at 10:10 AM, Jan Beulich <JBeulich@suse.com>
>> wrote:
>> >
>> >> >>> On 24.09.12 at 15:56, Ben Guthro <ben@guthro.net> wrote:
>> >> > On Mon, Sep 24, 2012 at 9:34 AM, Jan Beulich <JBeulich@suse.com>
>> wrote:
>> >> >> ...; the interesting ones are
>> >> >> - at the end of xen/arch/x86/acpu/cpu_idle.c:acpi_dead_idle()
>> >> >> - xen/arch/x86/domain.c:default_dead_idle()
>> >> >
>> >> >
>> >> > Thanks! This fixes the issue on this machine!
>> >>
>> >> Hooray!
>> >>
>> >> > Is this a reasonable long-term solution - or are there reasons not =
to
>> >> > call wbinvd() here?
>> >>
>> >> That's a perfectly valid adjustment (see my earlier reply where
>> >> I originally suggested it and explained why it may be necessary).
>> >>
>> >> Jan
>> >>
>> >>
>>
>>
>>
>>
>>
>> ------------------------------
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xen.org
>> http://lists.xen.org/xen-devel
>>
>>
>

--f46d0432b1c2f2f16604ca790c29
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

Here&#39;s my &quot;Big hammer&quot; debugging patch.<div><br></div><div>If=
 I force the cpu to be scheduled on CPU0 when the appropriate cpu is not on=
line, I can resume properly.</div><div><br></div><div>Clearly this is not t=
he proper solution, and I&#39;m sure the fix is subtle. I&#39;m not seeing =
it right now though. Perhaps tomorrow morning.</div>
<div>If you have any ideas, I&#39;m happy to run tests then.</div><div><br>=
</div><div>/btg<br><br><div class=3D"gmail_quote">On Mon, Sep 24, 2012 at 4=
:46 PM, Ben Guthro <span dir=3D"ltr">&lt;<a href=3D"mailto:ben@guthro.net" =
target=3D"_blank">ben@guthro.net</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">I&#39;ve managed to determine that _csched_c=
pu_pick=A0is, for reasons not yet clear, picking a cpu id outside of the ra=
nge of cpus that are valid for this system<div>
(in this case cpu id 4, on a 2 core machine)</div><div class=3D"HOEnZb"><di=
v class=3D"h5"><div><br>
</div><div><br><br><div class=3D"gmail_quote">On Mon, Sep 24, 2012 at 4:30 =
PM, Keir Fraser <span dir=3D"ltr">&lt;<a href=3D"mailto:keir.xen@gmail.com"=
 target=3D"_blank">keir.xen@gmail.com</a>&gt;</span> wrote:<br><blockquote =
class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid=
;padding-left:1ex">





<div>
<font face=3D"Calibri, Verdana, Helvetica, Arial"><span style=3D"font-size:=
11pt">Do a debug build so the backtrace can be trusted. It=92s a NULL point=
er dereference so shouldn=92t be too tricky to make some headway on this on=
e. Easier than the previous bug. :)<span><font color=3D"#888888"><br>


<br>
=A0-- Keir</font></span><div><div><br>
<br>
On 24/09/2012 20:02, &quot;Ben Guthro&quot; &lt;<a href=3D"http://ben@guthr=
o.net" target=3D"_blank">ben@guthro.net</a>&gt; wrote:<br>
<br>
</div></div></span></font><blockquote><div><div><font face=3D"Calibri, Verd=
ana, Helvetica, Arial"><span style=3D"font-size:11pt">Well...knock one bug =
down - and another crops up.<br>
<br>
It appears that dom0_vcpu_pin is incompatible with S3.<br>
I&#39;ll start digging into why, but if you have any thoughts from the stac=
k below, I&#39;d welcome any pointers.<br>
<br>
/btg<br>
<br>
<br>
(XEN) Preparing system for ACPI S3 state.<br>
(XEN) Disabling non-boot CPUs ...<br>
(XEN) Entering ACPI S3 state.<br>
(XEN) mce_intel.c:1239: MCA Capability: BCAST 1 SER 0 CMCI 0 firstbank 1 ex=
tended MCE MSR 0<br>
(XEN) CMCI: CPU0 has no CMCI support<br>
(XEN) CPU0: Thermal monitoring enabled (TM2)<br>
(XEN) Finishing wakeup from ACPI S3 state.<br>
(XEN) Enabling non-boot CPUs =A0...<br>
(XEN) Booting processor 1/1 eip 8a000<br>
(XEN) Initializing CPU#1<br>
(XEN) CPU: L1 I cache: 32K, L1 D cache: 32K<br>
(XEN) CPU: L2 cache: 3072K<br>
(XEN) CPU: Physical Processor ID: 0<br>
(XEN) CPU: Processor Core ID: 1<br>
(XEN) CMCI: CPU1 has no CMCI support<br>
(XEN) CPU1: Thermal monitoring enabled (TM2)<br>
(XEN) CPU1: Intel(R) Core(TM)2 Duo CPU =A0 =A0 P8400 =A0@ 2.26GHz stepping =
06<br>
(XEN) microcode: CPU1 updated from revision 0x60c to 0x60f, date =3D 2010-0=
9-29=A0<br>
[ =A0 60.100054] ACPI: Low-level resume complete<br>
[ =A0 60.100054] PM: Restoring platform NVS memory<br>
[ =A0 60.100054] Enabling non-boot CPUs ...<br>
[ =A0 60.100054] installing Xen timer for CPU 1<br>
[ =A0 60.100054] cpu 1 spinlock event irq 279<br>
(XEN) ----[ Xen-4.2.1-pre =A0x86_64 =A0debug=3Dn =A0Tainted: =A0 =A0C ]----=
<br>
(XEN) CPU: =A0 =A01<br>
(XEN) RIP: =A0 =A0e008:[&lt;ffff82c480121562&gt;] vcpu_migrate+0x172/0x360<=
br>
(XEN) RFLAGS: 0000000000010096 =A0 CONTEXT: hypervisor<br>
(XEN) rax: 00007d3b7fd17180 =A0 rbx: ffff82c4802e8ee0 =A0 rcx: ffff82c4802e=
8ee0<br>
(XEN) rdx: ffff83013a3c5068 =A0 rsi: 0000000000000004 =A0 rdi: ffff8301300b=
7d68<br>
(XEN) rbp: 0000000000000001 =A0 rsp: ffff8301300b7e28 =A0 r8: =A00000000000=
000000<br>
(XEN) r9: =A0000000000000003e =A0 r10: 000000000000003e =A0 r11: 0000000000=
000246<br>
(XEN) r12: ffff83013a3c5068 =A0 r13: ffff83013a3c5068 =A0 r14: ffff82c4802d=
3140<br>
(XEN) r15: 0000000000000001 =A0 cr0: 000000008005003b =A0 cr4: 000000000000=
26f0<br>
(XEN) cr3: 0000000131a05000 =A0 cr2: 0000000000000060<br>
(XEN) ds: 002b =A0 es: 002b =A0 fs: 0000 =A0 gs: 0000 =A0 ss: e010 =A0 cs: =
e008<br>
(XEN) Xen stack trace from rsp=3Dffff8301300b7e28:<br>
(XEN) =A0 =A0ffff82c4802d3140 ffff83013a3c5068 0000000000000246 00000000000=
00004<br>
(XEN) =A0 =A0ffff8300bd2fe000 ffff82c4802e8ee0 00000004012d3140 ffff82c4802=
e8ee0<br>
(XEN) =A0 =A0ffff88003fc8e820 ffff8300bd2fe000 ffff8301355d8000 00000000000=
00000<br>
(XEN) =A0 =A00000000000000000 0000000000000000 ffff88003fc8e820 ffff82c4801=
05a50<br>
(XEN) =A0 =A00000000000000000 ffff82c4801805ec 0000060f00000000 ffff82c4801=
84f16<br>
(XEN) =A0 =A00000000000000032 78a20f6e65780b0f ffff88003976fdc8 ffff8300bd2=
fe000<br>
(XEN) =A0 =A0ffff88003976fe50 ffff8300bd2fe000 ffff88003976fda0 00000000000=
00001<br>
(XEN) =A0 =A00000000000000000 ffff82c480214288 ffff88003fc8e820 00000000000=
00000<br>
(XEN) =A0 =A00000000000000000 0000000000000001 ffff88003976fda0 ffff88003fc=
8bdc0<br>
(XEN) =A0 =A00000000000000246 ffff88003976fe60 00000000ffffffff 00000000000=
00000<br>
(XEN) =A0 =A00000000000000018 ffffffff8100130a 0000000000000000 00000000000=
00001<br>
(XEN) =A0 =A00000000000000007 0000010000000000 ffffffff8100130a 00000000000=
0e033<br>
(XEN) =A0 =A00000000000000246 ffff88003976fd88 000000000000e02b d43d5f3feda=
ef5e7<br>
(XEN) =A0 =A0d3b2ddaeed5038ff 270adb813ad76c9b ddfd6ff5f85e6775 b5881cbf000=
00001<br>
(XEN) =A0 =A0ffff8300bd2fe000 0000003cba0dc180 0a109ac649c118a1<br>
(XEN) Xen call trace:<br>
(XEN) =A0 =A0[&lt;ffff82c480121562&gt;] vcpu_migrate+0x172/0x360<br>
(XEN) =A0 =A0[&lt;ffff82c480105a50&gt;] do_vcpu_op+0x1e0/0x4a0<br>
(XEN) =A0 =A0[&lt;ffff82c4801805ec&gt;] do_invalid_op+0x19c/0x3f0<br>
(XEN) =A0 =A0[&lt;ffff82c480184f16&gt;] copy_from_user+0x26/0x90<br>
(XEN) =A0 =A0[&lt;ffff82c480214288&gt;] syscall_enter+0x88/0x8d<br>
(XEN) =A0 =A0<br>
(XEN) Pagetable walk from 0000000000000060:<br>
(XEN) =A0L4[0x000] =3D 0000000000000000 ffffffffffffffff<br>
(XEN)=A0<br>
(XEN) ****************************************<br>
(XEN) Panic on CPU 1:<br>
(XEN) FATAL PAGE FAULT<br>
(XEN) [error_code=3D0000]<br>
(XEN) Faulting linear address: 0000000000000060<br>
(XEN) ****************************************<br>
(XEN)=A0<br>
(XEN) Reboot in five seconds...<br>
<br>
<br>
On Mon, Sep 24, 2012 at 10:28 AM, Jan Beulich &lt;<a href=3D"http://JBeulic=
h@suse.com" target=3D"_blank">JBeulich@suse.com</a>&gt; wrote:<br>
</span></font><blockquote><font face=3D"Calibri, Verdana, Helvetica, Arial"=
><span style=3D"font-size:11pt">&gt;&gt;&gt; On 24.09.12 at 16:16, Ben Guth=
ro &lt;<a href=3D"http://ben@guthro.net" target=3D"_blank">ben@guthro.net</=
a>&gt; wrote:<br>


&gt; Would you prefer a separate [PATCH] email for this fix, or will you ap=
ply<br>
&gt; it as-is?<br>
<br>
I&#39;ll put something together - the most important thing here obviously<b=
r>
is having a proper description. Plus I&#39;d like to slightly extend this a=
nd<br>
have acpi_dead_idle() actually use default_dead_idle(), just to have<br>
things consolidated in one place. I assume I can put your S-o-b on<br>
what you sent...<br>
<font color=3D"#888888"><br>
Jan<br>
</font><br>
&gt; On Mon, Sep 24, 2012 at 10:10 AM, Jan Beulich &lt;<a href=3D"http://JB=
eulich@suse.com" target=3D"_blank">JBeulich@suse.com</a>&gt; wrote:<br>
&gt;<br>
&gt;&gt; &gt;&gt;&gt; On 24.09.12 at 15:56, Ben Guthro &lt;<a href=3D"http:=
//ben@guthro.net" target=3D"_blank">ben@guthro.net</a>&gt; wrote:<br>
&gt;&gt; &gt; On Mon, Sep 24, 2012 at 9:34 AM, Jan Beulich &lt;<a href=3D"h=
ttp://JBeulich@suse.com" target=3D"_blank">JBeulich@suse.com</a>&gt; wrote:=
<br>
&gt;&gt; &gt;&gt; ...; the interesting ones are<br>
&gt;&gt; &gt;&gt; - at the end of xen/arch/x86/acpu/cpu_idle.c:acpi_dead_id=
le()<br>
&gt;&gt; &gt;&gt; - xen/arch/x86/domain.c:default_dead_idle()<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; Thanks! This fixes the issue on this machine!<br>
&gt;&gt;<br>
&gt;&gt; Hooray!<br>
&gt;&gt;<br>
&gt;&gt; &gt; Is this a reasonable long-term solution - or are there reason=
s not to<br>
&gt;&gt; &gt; call wbinvd() here?<br>
&gt;&gt;<br>
&gt;&gt; That&#39;s a perfectly valid adjustment (see my earlier reply wher=
e<br>
&gt;&gt; I originally suggested it and explained why it may be necessary).<=
br>
&gt;&gt;<br>
&gt;&gt; Jan<br>
&gt;&gt;<br>
&gt;&gt;<br>
<br>
<br>
<br>
</span></font></blockquote></div></div><font face=3D"Calibri, Verdana, Helv=
etica, Arial"><span style=3D"font-size:11pt"><br>
<br>
<hr align=3D"CENTER" size=3D"3" width=3D"95%"></span></font><div><font><fon=
t face=3D"Consolas, Courier New, Courier"><span style=3D"font-size:10pt">__=
_____________________________________________<br>
Xen-devel mailing list<br>
<a href=3D"http://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>
</span></font></font></div></blockquote>
</div>


</blockquote></div><br></div>
</div></div></blockquote></div><br></div>

--f46d0432b1c2f2f16604ca790c29--
--f46d0432b1c2f2f16a04ca790c2b
Content-Type: application/octet-stream; name="debug1.patch"
Content-Disposition: attachment; filename="debug1.patch"
Content-Transfer-Encoding: base64
X-Attachment-Id: f_h7i2jrbx0

ZGlmZiAtLWdpdCBhL3hlbi9jb21tb24vc2NoZWRfY3JlZGl0LmMgYi94ZW4vY29tbW9uL3NjaGVk
X2NyZWRpdC5jCmluZGV4IGE5ODAyYTEuLmUwN2IxMjMgMTAwNjQ0Ci0tLSBhL3hlbi9jb21tb24v
c2NoZWRfY3JlZGl0LmMKKysrIGIveGVuL2NvbW1vbi9zY2hlZF9jcmVkaXQuYwpAQCAtMjMsNiAr
MjMsOCBAQAogI2luY2x1ZGUgPHhlbi9lcnJuby5oPgogI2luY2x1ZGUgPHhlbi9rZXloYW5kbGVy
Lmg+CiAKK3N0YXRpYyB2b2lkIGNzY2hlZF9kdW1wKGNvbnN0IHN0cnVjdCBzY2hlZHVsZXIgKm9w
cyk7CisKIC8qCiAgKiBDU0NIRURfU1RBVFMKICAqCkBAIC00NTYsNiArNDU4LDkgQEAgX19jc2No
ZWRfdmNwdV9pc19taWdyYXRlYWJsZShzdHJ1Y3QgdmNwdSAqdmMsIGludCBkZXN0X2NwdSkKICAg
ICAgICAgICAgY3B1bWFza190ZXN0X2NwdShkZXN0X2NwdSwgdmMtPmNwdV9hZmZpbml0eSk7CiB9
CiAKK3N0YXRpYyBjaGFyIHRzdHIxWzEwMF07CitzdGF0aWMgY2hhciB0c3RyMlsxMDBdOworCiBz
dGF0aWMgaW50CiBfY3NjaGVkX2NwdV9waWNrKGNvbnN0IHN0cnVjdCBzY2hlZHVsZXIgKm9wcywg
c3RydWN0IHZjcHUgKnZjLCBib29sX3QgY29tbWl0KQogewpAQCAtNDczLDcgKzQ3OCw4IEBAIF9j
c2NoZWRfY3B1X3BpY2soY29uc3Qgc3RydWN0IHNjaGVkdWxlciAqb3BzLCBzdHJ1Y3QgdmNwdSAq
dmMsIGJvb2xfdCBjb21taXQpCiAgICAgY3B1bWFza19hbmQoJmNwdXMsIG9ubGluZSwgdmMtPmNw
dV9hZmZpbml0eSk7CiAgICAgY3B1ID0gY3B1bWFza190ZXN0X2NwdSh2Yy0+cHJvY2Vzc29yLCAm
Y3B1cykKICAgICAgICAgICAgID8gdmMtPnByb2Nlc3NvcgotICAgICAgICAgICAgOiBjcHVtYXNr
X2N5Y2xlKHZjLT5wcm9jZXNzb3IsICZjcHVzKTsKKyAgICAgICAgICAgIDogMDsKKy8vICAgICAg
ICAgICAgOiBjcHVtYXNrX2N5Y2xlKHZjLT5wcm9jZXNzb3IsICZjcHVzKTsKICAgICBBU1NFUlQo
ICFjcHVtYXNrX2VtcHR5KCZjcHVzKSAmJiBjcHVtYXNrX3Rlc3RfY3B1KGNwdSwgJmNwdXMpICk7
CiAKICAgICAvKgpAQCAtNTQyLDYgKzU0OCwxNCBAQCBfY3NjaGVkX2NwdV9waWNrKGNvbnN0IHN0
cnVjdCBzY2hlZHVsZXIgKm9wcywgc3RydWN0IHZjcHUgKnZjLCBib29sX3QgY29tbWl0KQogICAg
IGlmICggY29tbWl0ICYmIHNwYyApCiAgICAgICAgc3BjLT5pZGxlX2JpYXMgPSBjcHU7CiAKKwor
ICAgIGlmIChjcHUgPiAxKSB7CisJICAgIGNzY2hlZF9kdW1wKG9wcyk7CisJICAgIGNwdW1hc2tf
c2NucHJpbnRmKHRzdHIxLCBzaXplb2YodHN0cjEpLCBvbmxpbmUpOworCSAgICBjcHVtYXNrX3Nj
bnByaW50Zih0c3RyMiwgc2l6ZW9mKHRzdHIyKSwgdmMtPmNwdV9hZmZpbml0eSk7CisKKwkgICAg
cHJpbnRrKCJNQVNLUzogb25saW5lPSVzIGFmZmluaXR5PSVzXG4iLCB0c3RyMSwgdHN0cjIpOwor
ICAgIH0KICAgICByZXR1cm4gY3B1OwogfQogCmRpZmYgLS1naXQgYS94ZW4vY29tbW9uL3NjaGVk
dWxlLmMgYi94ZW4vY29tbW9uL3NjaGVkdWxlLmMKaW5kZXggMTMxNzhlMC4uMWRhYjZkMyAxMDA2
NDQKLS0tIGEveGVuL2NvbW1vbi9zY2hlZHVsZS5jCisrKyBiL3hlbi9jb21tb24vc2NoZWR1bGUu
YwpAQCAtNDQ1LDYgKzQ0NSw3IEBAIHN0YXRpYyB2b2lkIHZjcHVfbWlncmF0ZShzdHJ1Y3QgdmNw
dSAqdikKIAogICAgICAgICAgICAgLyogU2VsZWN0IGEgbmV3IENQVS4gKi8KICAgICAgICAgICAg
IG5ld19jcHUgPSBTQ0hFRF9PUChWQ1BVMk9QKHYpLCBwaWNrX2NwdSwgdik7CisgICAgICAgICAg
ICBwcmludGsoIiVzOiVkICglcykgbmV3X2NwdT0lZCBvbmxpbmU9JWRcbiIsIF9fRklMRV9fLCBf
X0xJTkVfXywgX19mdW5jX18sIG5ld19jcHUsIG51bV9vbmxpbmVfY3B1cygpKTsKICAgICAgICAg
ICAgIGlmICggKG5ld19sb2NrID09IHBlcl9jcHUoc2NoZWR1bGVfZGF0YSwgbmV3X2NwdSkuc2No
ZWR1bGVfbG9jaykgJiYKICAgICAgICAgICAgICAgICAgY3B1bWFza190ZXN0X2NwdShuZXdfY3B1
LCB2LT5kb21haW4tPmNwdXBvb2wtPmNwdV92YWxpZCkgKQogICAgICAgICAgICAgICAgIGJyZWFr
Owo=
--f46d0432b1c2f2f16a04ca790c2b
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--f46d0432b1c2f2f16a04ca790c2b--


From xen-devel-bounces@lists.xen.org Mon Sep 24 21:37:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Sep 2012 21:37:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGGKe-0004Qj-LY; Mon, 24 Sep 2012 21:36:48 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jmarcet@gmail.com>) id 1TGGKd-0004Qb-9h
	for xen-devel@lists.xen.org; Mon, 24 Sep 2012 21:36:47 +0000
Received: from [85.158.139.83:26507] by server-4.bemta-5.messagelabs.com id
	FC/27-20767-E62D0605; Mon, 24 Sep 2012 21:36:46 +0000
X-Env-Sender: jmarcet@gmail.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1348522604!24720797!1
X-Originating-IP: [209.85.214.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-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30176 invoked from network); 24 Sep 2012 21:36:45 -0000
Received: from mail-ob0-f173.google.com (HELO mail-ob0-f173.google.com)
	(209.85.214.173)
	by server-11.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Sep 2012 21:36:45 -0000
Received: by obbta14 with SMTP id ta14so7660103obb.32
	for <xen-devel@lists.xen.org>; Mon, 24 Sep 2012 14:36:44 -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=6pNtcorNaxK6zxLB/ZZNcLfJ1TBgnYntIT4GxZ3s200=;
	b=fem7AADEkeS27qwh+AbxAI9cRooxQWw2MOMVGxKKwOcjB+xWChmWk1/2KFFq6rktgF
	wQbwPkldFBXlHFBbQERPdrFMVWbfQlJw466/oBuku/z9d/FL04W3Uqx0GN7ZQpDy7n4W
	kYoBC2ArLLSe5QMSE9iF9q3A5sKpJlFa3P3xO2welYhZhhlAw2eAK7jmQukaD67OQ9tP
	xBC1ZrlFegaXWPBt9tTmDr1FGXLEsNa8nfijT0zyjYrvUsdLfcOZJrapehNE+vFTztJM
	eNsrLDCRD80xBIDflXS3I7MgbpAW1uLrVkHvAl+kwGWVy4jw8E56w15HhaQfpfxlVV2e
	F7PQ==
Received: by 10.182.174.68 with SMTP id bq4mr10929191obc.53.1348522604006;
	Mon, 24 Sep 2012 14:36:44 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.60.138.225 with HTTP; Mon, 24 Sep 2012 14:36:23 -0700 (PDT)
In-Reply-To: <20120924140411.GH31618@phenom.dumpdata.com>
References: <CAOvdn6XKPOMNn6AjuYvZvPXRRJffN3po5GXe1Yh1-m0hisMK_w@mail.gmail.com>
	<CC8273A0.4C9DD%keir@xen.org>
	<50605E9A020000780009D486@nat28.tlf.novell.com>
	<CAOvdn6XmB6rj3_QVU+59V8p24Y5G47AWxVEM=id02JWXkuhibQ@mail.gmail.com>
	<5060640B020000780009D4D2@nat28.tlf.novell.com>
	<CAOvdn6XLy8zR2rb2MEyi2aT9LQiFvFLY_H02p181mTsVLVTZkw@mail.gmail.com>
	<20120924122203.GG8912@reaktio.net>
	<CAOvdn6XV4eoA-FfFns1xhx7HCUqXc7KHxZwyKuT4FHG8s3R5RQ@mail.gmail.com>
	<CAAnFQG9PLQjdh6Ab6=Y5ZGM1s4nGdLekKU=pcKNMxt4rmt_RKA@mail.gmail.com>
	<20120924140411.GH31618@phenom.dumpdata.com>
From: Javier Marcet <jmarcet@gmail.com>
Date: Mon, 24 Sep 2012 23:36:23 +0200
Message-ID: <CAAnFQG-tjv5UyF6j-TNHNgme2c4vA0Zxy8AdCiJEVsf2Z0quNA@mail.gmail.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: Keir Fraser <keir@xen.org>, john.baboval@citrix.com,
	xen-devel <xen-devel@lists.xen.org>, Ben Guthro <ben@guthro.net>,
	Jan Beulich <JBeulich@suse.com>, Thomas Goetz <thomas.goetz@citrix.com>
Subject: Re: [Xen-devel] Xen4.2 S3 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 Mon, Sep 24, 2012 at 4:04 PM, Konrad Rzeszutek Wilk
<konrad.wilk@oracle.com> wrote:

>> >> xen-acpi-processor driver was merged to upstream Linux kernel v3.4.
>> >>
>> >
>> > I see - so the advanced methods are not being used then
>
> You mean with the v3.5 kernel? I would think they would be used..
>
>> > This same kernel does work with Xen-4.0.x though. Is there an assumption in
>> > the code that ties Xen-4.2 to a newer kernel?
>>
>> I'm being bitten by this bug with a 3.5 kernel and Xen 4.2
>
> Huh? How so?

I've tried adding a wbinvd() call before the halts in
xen/arch/x86/domain.c:default_idle and I could do full suspend and
resume cycle once, but a reboot later I couldn't resume anymore. Here
is the trace I get:

[  142.322778] ACPI: Preparing to enter system sleep state S3
[  142.723286] PM: Saving platform NVS memory
[  142.736453] Disabling non-boot CPUs ...
[  142.851387] ------------[ cut here ]------------
[  142.851397] WARNING: at
/home/storage/src/ubuntu-precise/kernel/rcutree.c:1550
rcu_do_batch.isra.41+0x5f/0x213()
[  142.851401] Hardware name: To Be Filled By O.E.M.
[  142.851404] Modules linked in: blktap(O) ip6table_filter ip6_tables
ipt_MASQUERADE iptable_nat nf_nat nf_conntrack_ipv4 nf_defrag_ipv4
xt_state nf_conntrack ipt_REJECT xt_CHECKSUM iptable_mangle xt_tcpudp
iptable_filter ip_tables x_tables [last unloaded: cx25840]
[  142.851466] Pid: 32, comm: migration/7 Tainted: G           O
3.5.0-14-i7 #18~precise1
[  142.851469] Call Trace:
[  142.851473]  <IRQ>  [<ffffffff8106a9bd>] warn_slowpath_common+0x7e/0x96
[  142.851488]  [<ffffffff8106a9ea>] warn_slowpath_null+0x15/0x17
[  142.851496]  [<ffffffff810c6e87>] rcu_do_batch.isra.41+0x5f/0x213
[  142.851504]  [<ffffffff810c687f>] ?
check_for_new_grace_period.isra.35+0x38/0x44
[  142.851512]  [<ffffffff810c7101>] __rcu_process_callbacks+0xc6/0xee
[  142.851520]  [<ffffffff810c7149>] rcu_process_callbacks+0x20/0x3e
[  142.851527]  [<ffffffff81070c27>] __do_softirq+0x87/0x113
[  142.851536]  [<ffffffff812e7b22>] ? __xen_evtchn_do_upcall+0x1a0/0x1dd
[  142.851546]  [<ffffffff8162f05c>] call_softirq+0x1c/0x30
[  142.851557]  [<ffffffff810343a3>] do_softirq+0x41/0x7e
[  142.851566]  [<ffffffff81070e66>] irq_exit+0x3f/0x9a
[  142.851573]  [<ffffffff812e95c9>] xen_evtchn_do_upcall+0x2c/0x39
[  142.851580]  [<ffffffff8162f0ae>] xen_do_hypervisor_callback+0x1e/0x30
[  142.851588]  <EOI>  [<ffffffff8100122a>] ? hypercall_page+0x22a/0x1000
[  142.851601]  [<ffffffff8100122a>] ? hypercall_page+0x22a/0x1000
[  142.851609]  [<ffffffff8102eee9>] ? xen_force_evtchn_callback+0xd/0xf
[  142.851618]  [<ffffffff8102f552>] ? check_events+0x12/0x20
[  142.851627]  [<ffffffff8102f53f>] ? xen_restore_fl_direct_reloc+0x4/0x4
[  142.851635]  [<ffffffff810b6ff4>] ? arch_local_irq_restore+0xb/0xd
[  142.851644]  [<ffffffff810b73f4>] ? stop_machine_cpu_stop+0xc1/0xd3
[  142.851652]  [<ffffffff810b7333>] ? queue_stop_cpus_work+0xb5/0xb5
[  142.851660]  [<ffffffff810b7152>] ? cpu_stopper_thread+0xf7/0x187
[  142.851667]  [<ffffffff8108a927>] ? finish_task_switch+0x82/0xc1
[  142.851676]  [<ffffffff8162c50b>] ? __schedule+0x428/0x454
[  142.851685]  [<ffffffff8162cff0>] ? _raw_spin_unlock_irqrestore+0x15/0x18
[  142.851693]  [<ffffffff810b705b>] ? cpu_stop_signal_done+0x30/0x30
[  142.851701]  [<ffffffff81082627>] ? kthread+0x86/0x8e
[  142.851710]  [<ffffffff8162ef64>] ? kernel_thread_helper+0x4/0x10
[  142.851718]  [<ffffffff8162d338>] ? retint_restore_args+0x5/0x6
[  142.851726]  [<ffffffff8162ef60>] ? gs_change+0x13/0x13
[  142.851736] ---[ end trace 3722a99bcc5ae37a ]---
[  144.257229] ACPI: Low-level resume complete
[  144.257322] PM: Restoring platform NVS memory


-- 
Javier Marcet <jmarcet@gmail.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 24 21:37:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Sep 2012 21:37:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGGKe-0004Qj-LY; Mon, 24 Sep 2012 21:36:48 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jmarcet@gmail.com>) id 1TGGKd-0004Qb-9h
	for xen-devel@lists.xen.org; Mon, 24 Sep 2012 21:36:47 +0000
Received: from [85.158.139.83:26507] by server-4.bemta-5.messagelabs.com id
	FC/27-20767-E62D0605; Mon, 24 Sep 2012 21:36:46 +0000
X-Env-Sender: jmarcet@gmail.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1348522604!24720797!1
X-Originating-IP: [209.85.214.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-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30176 invoked from network); 24 Sep 2012 21:36:45 -0000
Received: from mail-ob0-f173.google.com (HELO mail-ob0-f173.google.com)
	(209.85.214.173)
	by server-11.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Sep 2012 21:36:45 -0000
Received: by obbta14 with SMTP id ta14so7660103obb.32
	for <xen-devel@lists.xen.org>; Mon, 24 Sep 2012 14:36:44 -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=6pNtcorNaxK6zxLB/ZZNcLfJ1TBgnYntIT4GxZ3s200=;
	b=fem7AADEkeS27qwh+AbxAI9cRooxQWw2MOMVGxKKwOcjB+xWChmWk1/2KFFq6rktgF
	wQbwPkldFBXlHFBbQERPdrFMVWbfQlJw466/oBuku/z9d/FL04W3Uqx0GN7ZQpDy7n4W
	kYoBC2ArLLSe5QMSE9iF9q3A5sKpJlFa3P3xO2welYhZhhlAw2eAK7jmQukaD67OQ9tP
	xBC1ZrlFegaXWPBt9tTmDr1FGXLEsNa8nfijT0zyjYrvUsdLfcOZJrapehNE+vFTztJM
	eNsrLDCRD80xBIDflXS3I7MgbpAW1uLrVkHvAl+kwGWVy4jw8E56w15HhaQfpfxlVV2e
	F7PQ==
Received: by 10.182.174.68 with SMTP id bq4mr10929191obc.53.1348522604006;
	Mon, 24 Sep 2012 14:36:44 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.60.138.225 with HTTP; Mon, 24 Sep 2012 14:36:23 -0700 (PDT)
In-Reply-To: <20120924140411.GH31618@phenom.dumpdata.com>
References: <CAOvdn6XKPOMNn6AjuYvZvPXRRJffN3po5GXe1Yh1-m0hisMK_w@mail.gmail.com>
	<CC8273A0.4C9DD%keir@xen.org>
	<50605E9A020000780009D486@nat28.tlf.novell.com>
	<CAOvdn6XmB6rj3_QVU+59V8p24Y5G47AWxVEM=id02JWXkuhibQ@mail.gmail.com>
	<5060640B020000780009D4D2@nat28.tlf.novell.com>
	<CAOvdn6XLy8zR2rb2MEyi2aT9LQiFvFLY_H02p181mTsVLVTZkw@mail.gmail.com>
	<20120924122203.GG8912@reaktio.net>
	<CAOvdn6XV4eoA-FfFns1xhx7HCUqXc7KHxZwyKuT4FHG8s3R5RQ@mail.gmail.com>
	<CAAnFQG9PLQjdh6Ab6=Y5ZGM1s4nGdLekKU=pcKNMxt4rmt_RKA@mail.gmail.com>
	<20120924140411.GH31618@phenom.dumpdata.com>
From: Javier Marcet <jmarcet@gmail.com>
Date: Mon, 24 Sep 2012 23:36:23 +0200
Message-ID: <CAAnFQG-tjv5UyF6j-TNHNgme2c4vA0Zxy8AdCiJEVsf2Z0quNA@mail.gmail.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: Keir Fraser <keir@xen.org>, john.baboval@citrix.com,
	xen-devel <xen-devel@lists.xen.org>, Ben Guthro <ben@guthro.net>,
	Jan Beulich <JBeulich@suse.com>, Thomas Goetz <thomas.goetz@citrix.com>
Subject: Re: [Xen-devel] Xen4.2 S3 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 Mon, Sep 24, 2012 at 4:04 PM, Konrad Rzeszutek Wilk
<konrad.wilk@oracle.com> wrote:

>> >> xen-acpi-processor driver was merged to upstream Linux kernel v3.4.
>> >>
>> >
>> > I see - so the advanced methods are not being used then
>
> You mean with the v3.5 kernel? I would think they would be used..
>
>> > This same kernel does work with Xen-4.0.x though. Is there an assumption in
>> > the code that ties Xen-4.2 to a newer kernel?
>>
>> I'm being bitten by this bug with a 3.5 kernel and Xen 4.2
>
> Huh? How so?

I've tried adding a wbinvd() call before the halts in
xen/arch/x86/domain.c:default_idle and I could do full suspend and
resume cycle once, but a reboot later I couldn't resume anymore. Here
is the trace I get:

[  142.322778] ACPI: Preparing to enter system sleep state S3
[  142.723286] PM: Saving platform NVS memory
[  142.736453] Disabling non-boot CPUs ...
[  142.851387] ------------[ cut here ]------------
[  142.851397] WARNING: at
/home/storage/src/ubuntu-precise/kernel/rcutree.c:1550
rcu_do_batch.isra.41+0x5f/0x213()
[  142.851401] Hardware name: To Be Filled By O.E.M.
[  142.851404] Modules linked in: blktap(O) ip6table_filter ip6_tables
ipt_MASQUERADE iptable_nat nf_nat nf_conntrack_ipv4 nf_defrag_ipv4
xt_state nf_conntrack ipt_REJECT xt_CHECKSUM iptable_mangle xt_tcpudp
iptable_filter ip_tables x_tables [last unloaded: cx25840]
[  142.851466] Pid: 32, comm: migration/7 Tainted: G           O
3.5.0-14-i7 #18~precise1
[  142.851469] Call Trace:
[  142.851473]  <IRQ>  [<ffffffff8106a9bd>] warn_slowpath_common+0x7e/0x96
[  142.851488]  [<ffffffff8106a9ea>] warn_slowpath_null+0x15/0x17
[  142.851496]  [<ffffffff810c6e87>] rcu_do_batch.isra.41+0x5f/0x213
[  142.851504]  [<ffffffff810c687f>] ?
check_for_new_grace_period.isra.35+0x38/0x44
[  142.851512]  [<ffffffff810c7101>] __rcu_process_callbacks+0xc6/0xee
[  142.851520]  [<ffffffff810c7149>] rcu_process_callbacks+0x20/0x3e
[  142.851527]  [<ffffffff81070c27>] __do_softirq+0x87/0x113
[  142.851536]  [<ffffffff812e7b22>] ? __xen_evtchn_do_upcall+0x1a0/0x1dd
[  142.851546]  [<ffffffff8162f05c>] call_softirq+0x1c/0x30
[  142.851557]  [<ffffffff810343a3>] do_softirq+0x41/0x7e
[  142.851566]  [<ffffffff81070e66>] irq_exit+0x3f/0x9a
[  142.851573]  [<ffffffff812e95c9>] xen_evtchn_do_upcall+0x2c/0x39
[  142.851580]  [<ffffffff8162f0ae>] xen_do_hypervisor_callback+0x1e/0x30
[  142.851588]  <EOI>  [<ffffffff8100122a>] ? hypercall_page+0x22a/0x1000
[  142.851601]  [<ffffffff8100122a>] ? hypercall_page+0x22a/0x1000
[  142.851609]  [<ffffffff8102eee9>] ? xen_force_evtchn_callback+0xd/0xf
[  142.851618]  [<ffffffff8102f552>] ? check_events+0x12/0x20
[  142.851627]  [<ffffffff8102f53f>] ? xen_restore_fl_direct_reloc+0x4/0x4
[  142.851635]  [<ffffffff810b6ff4>] ? arch_local_irq_restore+0xb/0xd
[  142.851644]  [<ffffffff810b73f4>] ? stop_machine_cpu_stop+0xc1/0xd3
[  142.851652]  [<ffffffff810b7333>] ? queue_stop_cpus_work+0xb5/0xb5
[  142.851660]  [<ffffffff810b7152>] ? cpu_stopper_thread+0xf7/0x187
[  142.851667]  [<ffffffff8108a927>] ? finish_task_switch+0x82/0xc1
[  142.851676]  [<ffffffff8162c50b>] ? __schedule+0x428/0x454
[  142.851685]  [<ffffffff8162cff0>] ? _raw_spin_unlock_irqrestore+0x15/0x18
[  142.851693]  [<ffffffff810b705b>] ? cpu_stop_signal_done+0x30/0x30
[  142.851701]  [<ffffffff81082627>] ? kthread+0x86/0x8e
[  142.851710]  [<ffffffff8162ef64>] ? kernel_thread_helper+0x4/0x10
[  142.851718]  [<ffffffff8162d338>] ? retint_restore_args+0x5/0x6
[  142.851726]  [<ffffffff8162ef60>] ? gs_change+0x13/0x13
[  142.851736] ---[ end trace 3722a99bcc5ae37a ]---
[  144.257229] ACPI: Low-level resume complete
[  144.257322] PM: Restoring platform NVS memory


-- 
Javier Marcet <jmarcet@gmail.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 24 21:58:35 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Sep 2012 21:58:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGGfN-0004fF-O2; Mon, 24 Sep 2012 21:58:13 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1TGGfL-0004f7-NI
	for xen-devel@lists.xensource.com; Mon, 24 Sep 2012 21:58:12 +0000
Received: from [85.158.137.99:4592] by server-8.bemta-3.messagelabs.com id
	AB/A1-24700-277D0605; Mon, 24 Sep 2012 21:58:10 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-217.messagelabs.com!1348523890!14210498!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTA4NDk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4532 invoked from network); 24 Sep 2012 21:58:10 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Sep 2012 21:58:10 -0000
X-IronPort-AV: E=Sophos;i="4.80,477,1344211200"; d="scan'208";a="14734465"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Sep 2012 21:58: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.279.1; Mon, 24 Sep 2012 22:58: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 1TGGfJ-0008EU-1W;
	Mon, 24 Sep 2012 21:58:09 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1TGGfI-000369-Sc;
	Mon, 24 Sep 2012 22:58:08 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-13861-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Mon, 24 Sep 2012 22:58:08 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13861: regressions - trouble:
	blocked/broken/fail/pass
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 13861 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13861/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-win-vcpus1    5 xen-boot                  fail REGR. vs. 13825
 build-amd64-pvops             2 host-install(2)         broken REGR. vs. 13825
 test-amd64-i386-xl-multivcpu  5 xen-boot         fail in 13837 REGR. vs. 13825
 test-amd64-i386-xl-win-vcpus1  5 xen-boot        fail in 13837 REGR. vs. 13825
 test-amd64-i386-qemuu-rhel6hvm-intel  5 xen-boot fail in 13837 REGR. vs. 13825
 test-amd64-i386-xl-win7-amd64  5 xen-boot        fail in 13837 REGR. vs. 13825
 test-amd64-amd64-win          5 xen-boot         fail in 13837 REGR. vs. 13825
 test-amd64-amd64-xl-winxpsp3  5 xen-boot         fail in 13837 REGR. vs. 13825
 test-amd64-i386-pair         8 xen-boot/dst_host fail in 13837 REGR. vs. 13825
 test-amd64-i386-pair         7 xen-boot/src_host fail in 13837 REGR. vs. 13825

Tests which are failing intermittently (not blocking):
 test-amd64-i386-rhel6hvm-intel  5 xen-boot                  fail pass in 13837
 test-amd64-i386-xl-credit2    5 xen-boot                    fail pass in 13837
 test-amd64-i386-xl-multivcpu  3 host-install(3)           broken pass in 13848
 test-amd64-i386-xl-win-vcpus1  3 host-install(3)          broken pass in 13848
 test-amd64-i386-qemuu-rhel6hvm-intel  3 host-install(3)   broken pass in 13859
 test-amd64-i386-pv            3 host-install(3)           broken pass in 13859
 test-amd64-i386-xl            3 host-install(3)           broken pass in 13848
 test-amd64-i386-xl-win7-amd64  3 host-install(3)          broken pass in 13848
 test-amd64-i386-pair          3 host-install/src_host(3)  broken pass in 13848
 test-amd64-amd64-xl-win7-amd64 12 guest-localmigrate/x10 fail in 13837 pass in 13848
 test-amd64-amd64-pv           5 xen-boot           fail in 13848 pass in 13841
 test-amd64-i386-xl-credit2    3 host-install(3)  broken in 13848 pass in 13861
 test-amd64-i386-win-vcpus1    3 host-install(3)  broken in 13848 pass in 13861

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore     fail in 13837 like 13825
 test-amd64-amd64-xl-sedf      3 host-install(3)     broken in 13837 like 13825
 test-amd64-amd64-xl-pcipt-intel  5 xen-boot      fail in 13837 REGR. vs. 13825
 test-amd64-amd64-xl-qemuu-winxpsp3 9 guest-localmigrate fail in 13837 like 13823
 test-amd64-amd64-xl-qemuu-win7-amd64 9 guest-localmigrate fail in 13837 like 13825

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf-pin  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 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-amd64-pv           1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-pcipt-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  1 xen-build-check(1)           blocked n/a
 test-amd64-amd64-win          1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 xen-build-check(1)         blocked n/a
 test-amd64-amd64-xl-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-pair         1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win      13 guest-stop            fail in 13837 never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop          fail in 13848 never pass

version targeted for testing:
 xen                  8f658b463b78
baseline version:
 xen                  d364becfb083

------------------------------------------------------------
People who touched revisions under test:
  Jan Beulich <jbeulich@suse.com>
  Keir Fraser <keir@xen.org>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            broken  
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          blocked 
 test-amd64-i386-xl                                           broken  
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemuu-win7-amd64                         blocked 
 test-amd64-amd64-xl-win7-amd64                               blocked 
 test-amd64-i386-xl-win7-amd64                                broken  
 test-amd64-i386-xl-credit2                                   fail    
 test-amd64-amd64-xl-pcipt-intel                              blocked 
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         broken  
 test-amd64-i386-xl-multivcpu                                 broken  
 test-amd64-amd64-pair                                        blocked 
 test-amd64-i386-pair                                         broken  
 test-amd64-amd64-xl-sedf-pin                                 blocked 
 test-amd64-amd64-pv                                          blocked 
 test-amd64-i386-pv                                           broken  
 test-amd64-amd64-xl-sedf                                     blocked 
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                broken  
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         blocked 
 test-amd64-i386-win                                          fail    
 test-amd64-amd64-xl-win                                      blocked 
 test-amd64-amd64-xl-qemuu-winxpsp3                           blocked 
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-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.

------------------------------------------------------------
changeset:   25938:8f658b463b78
tag:         tip
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Sep 21 17:02:46 2012 +0200
    
    x86: enable VIA CPU support
    
    Newer VIA CPUs have both 64-bit and VMX support. Enable them to be
    recognized for these purposes, at once stripping off any 32-bit CPU
    only bits from the respective CPU support file, and adding 64-bit ones
    found in recent Linux.
    
    This particularly implies untying the VMX == Intel assumption in a few
    places.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   25937:32187301ecc5
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Sep 21 15:20:21 2012 +0200
    
    x86: eliminate code affecting only 64-bit-incapable CPUs
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   25936:c8873f13cec3
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Sep 21 14:25:12 2012 +0200
    
    printk: prefer %#x et at over 0x%x
    
    Performance is not an issue with printk(), so let the function do
    minimally more work and instead save a byte per affected format
    specifier.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   25935:1e6e6b49b4ac
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Sep 21 13:47:18 2012 +0200
    
    x86: introduce MWAIT-based, ACPI-less CPU idle driver
    
    This is a port of Linux'es intel-idle driver serving the same purpose.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   25934:8eab91903e71
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Sep 21 13:45:08 2012 +0200
    
    cpuidle: remove unused latency_ticks member
    
    ... and code used only for initializing it.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   25933:d364becfb083
user:        Jan Beulich <jbeulich@suse.com>
date:        Thu Sep 20 13:31:19 2012 +0200
    
    introduce guest_handle_for_field()
    
    This helper turns a field of a GUEST_HANDLE in a GUEST_HANDLE.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    
    
(qemu changes not included)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 24 21:58:35 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Sep 2012 21:58:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGGfN-0004fF-O2; Mon, 24 Sep 2012 21:58:13 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1TGGfL-0004f7-NI
	for xen-devel@lists.xensource.com; Mon, 24 Sep 2012 21:58:12 +0000
Received: from [85.158.137.99:4592] by server-8.bemta-3.messagelabs.com id
	AB/A1-24700-277D0605; Mon, 24 Sep 2012 21:58:10 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-217.messagelabs.com!1348523890!14210498!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTA4NDk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4532 invoked from network); 24 Sep 2012 21:58:10 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Sep 2012 21:58:10 -0000
X-IronPort-AV: E=Sophos;i="4.80,477,1344211200"; d="scan'208";a="14734465"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Sep 2012 21:58: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.279.1; Mon, 24 Sep 2012 22:58: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 1TGGfJ-0008EU-1W;
	Mon, 24 Sep 2012 21:58:09 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1TGGfI-000369-Sc;
	Mon, 24 Sep 2012 22:58:08 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-13861-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Mon, 24 Sep 2012 22:58:08 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13861: regressions - trouble:
	blocked/broken/fail/pass
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 13861 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13861/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-win-vcpus1    5 xen-boot                  fail REGR. vs. 13825
 build-amd64-pvops             2 host-install(2)         broken REGR. vs. 13825
 test-amd64-i386-xl-multivcpu  5 xen-boot         fail in 13837 REGR. vs. 13825
 test-amd64-i386-xl-win-vcpus1  5 xen-boot        fail in 13837 REGR. vs. 13825
 test-amd64-i386-qemuu-rhel6hvm-intel  5 xen-boot fail in 13837 REGR. vs. 13825
 test-amd64-i386-xl-win7-amd64  5 xen-boot        fail in 13837 REGR. vs. 13825
 test-amd64-amd64-win          5 xen-boot         fail in 13837 REGR. vs. 13825
 test-amd64-amd64-xl-winxpsp3  5 xen-boot         fail in 13837 REGR. vs. 13825
 test-amd64-i386-pair         8 xen-boot/dst_host fail in 13837 REGR. vs. 13825
 test-amd64-i386-pair         7 xen-boot/src_host fail in 13837 REGR. vs. 13825

Tests which are failing intermittently (not blocking):
 test-amd64-i386-rhel6hvm-intel  5 xen-boot                  fail pass in 13837
 test-amd64-i386-xl-credit2    5 xen-boot                    fail pass in 13837
 test-amd64-i386-xl-multivcpu  3 host-install(3)           broken pass in 13848
 test-amd64-i386-xl-win-vcpus1  3 host-install(3)          broken pass in 13848
 test-amd64-i386-qemuu-rhel6hvm-intel  3 host-install(3)   broken pass in 13859
 test-amd64-i386-pv            3 host-install(3)           broken pass in 13859
 test-amd64-i386-xl            3 host-install(3)           broken pass in 13848
 test-amd64-i386-xl-win7-amd64  3 host-install(3)          broken pass in 13848
 test-amd64-i386-pair          3 host-install/src_host(3)  broken pass in 13848
 test-amd64-amd64-xl-win7-amd64 12 guest-localmigrate/x10 fail in 13837 pass in 13848
 test-amd64-amd64-pv           5 xen-boot           fail in 13848 pass in 13841
 test-amd64-i386-xl-credit2    3 host-install(3)  broken in 13848 pass in 13861
 test-amd64-i386-win-vcpus1    3 host-install(3)  broken in 13848 pass in 13861

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore     fail in 13837 like 13825
 test-amd64-amd64-xl-sedf      3 host-install(3)     broken in 13837 like 13825
 test-amd64-amd64-xl-pcipt-intel  5 xen-boot      fail in 13837 REGR. vs. 13825
 test-amd64-amd64-xl-qemuu-winxpsp3 9 guest-localmigrate fail in 13837 like 13823
 test-amd64-amd64-xl-qemuu-win7-amd64 9 guest-localmigrate fail in 13837 like 13825

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf-pin  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 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-amd64-pv           1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-pcipt-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  1 xen-build-check(1)           blocked n/a
 test-amd64-amd64-win          1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 xen-build-check(1)         blocked n/a
 test-amd64-amd64-xl-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-pair         1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win      13 guest-stop            fail in 13837 never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop          fail in 13848 never pass

version targeted for testing:
 xen                  8f658b463b78
baseline version:
 xen                  d364becfb083

------------------------------------------------------------
People who touched revisions under test:
  Jan Beulich <jbeulich@suse.com>
  Keir Fraser <keir@xen.org>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            broken  
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          blocked 
 test-amd64-i386-xl                                           broken  
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemuu-win7-amd64                         blocked 
 test-amd64-amd64-xl-win7-amd64                               blocked 
 test-amd64-i386-xl-win7-amd64                                broken  
 test-amd64-i386-xl-credit2                                   fail    
 test-amd64-amd64-xl-pcipt-intel                              blocked 
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         broken  
 test-amd64-i386-xl-multivcpu                                 broken  
 test-amd64-amd64-pair                                        blocked 
 test-amd64-i386-pair                                         broken  
 test-amd64-amd64-xl-sedf-pin                                 blocked 
 test-amd64-amd64-pv                                          blocked 
 test-amd64-i386-pv                                           broken  
 test-amd64-amd64-xl-sedf                                     blocked 
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                broken  
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         blocked 
 test-amd64-i386-win                                          fail    
 test-amd64-amd64-xl-win                                      blocked 
 test-amd64-amd64-xl-qemuu-winxpsp3                           blocked 
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-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.

------------------------------------------------------------
changeset:   25938:8f658b463b78
tag:         tip
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Sep 21 17:02:46 2012 +0200
    
    x86: enable VIA CPU support
    
    Newer VIA CPUs have both 64-bit and VMX support. Enable them to be
    recognized for these purposes, at once stripping off any 32-bit CPU
    only bits from the respective CPU support file, and adding 64-bit ones
    found in recent Linux.
    
    This particularly implies untying the VMX == Intel assumption in a few
    places.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   25937:32187301ecc5
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Sep 21 15:20:21 2012 +0200
    
    x86: eliminate code affecting only 64-bit-incapable CPUs
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   25936:c8873f13cec3
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Sep 21 14:25:12 2012 +0200
    
    printk: prefer %#x et at over 0x%x
    
    Performance is not an issue with printk(), so let the function do
    minimally more work and instead save a byte per affected format
    specifier.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   25935:1e6e6b49b4ac
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Sep 21 13:47:18 2012 +0200
    
    x86: introduce MWAIT-based, ACPI-less CPU idle driver
    
    This is a port of Linux'es intel-idle driver serving the same purpose.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   25934:8eab91903e71
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Sep 21 13:45:08 2012 +0200
    
    cpuidle: remove unused latency_ticks member
    
    ... and code used only for initializing it.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   25933:d364becfb083
user:        Jan Beulich <jbeulich@suse.com>
date:        Thu Sep 20 13:31:19 2012 +0200
    
    introduce guest_handle_for_field()
    
    This helper turns a field of a GUEST_HANDLE in a GUEST_HANDLE.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    
    
(qemu changes not included)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 24 22:44:18 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Sep 2012 22: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 1TGHNX-00052D-Ej; Mon, 24 Sep 2012 22:43:51 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mukesh.rathor@oracle.com>) id 1TGHNV-000528-St
	for Xen-devel@lists.xensource.com; Mon, 24 Sep 2012 22:43:50 +0000
Received: from [85.158.138.51:47683] by server-14.bemta-3.messagelabs.com id
	A5/CA-21431-522E0605; Mon, 24 Sep 2012 22:43:49 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1348526626!30122946!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDc2OTcxMA==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32088 invoked from network); 24 Sep 2012 22:43:48 -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; 24 Sep 2012 22:43:48 -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 q8OMhcfC030417
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 24 Sep 2012 22:43:39 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
	q8OMhbIl028830
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 24 Sep 2012 22:43:38 GMT
Received: from abhmt117.oracle.com (abhmt117.oracle.com [141.146.116.69])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q8OMha90015094; Mon, 24 Sep 2012 17:43:36 -0500
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 24 Sep 2012 15:43:36 -0700
Date: Mon, 24 Sep 2012 15:43:35 -0700
From: Mukesh Rathor <mukesh.rathor@oracle.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20120924154335.097d3fb9@mantra.us.oracle.com>
In-Reply-To: <alpine.DEB.2.02.1209241257440.29232@kaball.uk.xensource.com>
References: <20120921121659.5a723de9@mantra.us.oracle.com>
	<alpine.DEB.2.02.1209241257440.29232@kaball.uk.xensource.com>
Organization: Oracle Corporation
X-Mailer: Claws Mail 3.7.6 (GTK+ 2.18.9; x86_64-redhat-linux-gnu)
Mime-Version: 1.0
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: "Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH v1 3/8]: PVH startup changes (enlighten.c)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 24 Sep 2012 13:07:19 +0100
Stefano Stabellini <stefano.stabellini@eu.citrix.com> wrote:

> On Fri, 21 Sep 2012, Mukesh Rathor wrote:
> > ---
> >  arch/x86/xen/enlighten.c |   99
> > ++++++++++++++++++++++++++++++++++++--------- 1 files changed, 79
> > insertions(+), 20 deletions(-)
> > 
> > +			"with PVH extensions " : "", pv_info.name);
> >  	printk(KERN_INFO "Xen version: %d.%d%s%s\n",
> >  	       version >> 16, version & 0xffff, extra.extraversion,
> >  	       xen_feature(XENFEAT_mmu_pt_update_preserve_ad) ?
> > " (preserve-AD)" : ""); @@ -271,12 +278,15 @@ static void
> > xen_cpuid(unsigned int *ax, unsigned int *bx, break;
> >  	}
> >  
> > -	asm(XEN_EMULATE_PREFIX "cpuid"
> > -		: "=a" (*ax),
> > -		  "=b" (*bx),
> > -		  "=c" (*cx),
> > -		  "=d" (*dx)
> > -		: "0" (*ax), "2" (*cx));
> > +	if (xen_pvh_domain())
> > +		native_cpuid(ax, bx, cx, dx);
> > +	else
> > +		asm(XEN_EMULATE_PREFIX "cpuid"
> > +			: "=a" (*ax),
> > +			"=b" (*bx),
> > +			"=c" (*cx),
> > +			"=d" (*dx)
> > +			: "0" (*ax), "2" (*cx));
> 
> can't we just set the cpuid pvop to native_cpuid?

We had talked about this a bit at code review. There is some massaging
before and after that goes on, and so we thought we should just leave 
it like that.

> 
> >  	*bx &= maskebx;
> >  	*cx &= maskecx;
> > @@ -1034,6 +1044,10 @@ static int xen_write_msr_safe(unsigned int
> > msr, unsigned low, unsigned high) 
> >  void xen_setup_shared_info(void)
> >  {
> > +	/* do later in xen_pvh_guest_init() when extend_brk is
> > properly setup*/
> 
> Which one is the function that is going to get called later to do the
> initialization? It cannot be this one because it would still return
> immediately.

xen_pvh_guest_init() just like the comment says :).


> 
> > +	if (xen_pvh_domain() && xen_initial_domain())
> > +		return;
> > +
> >  	if (!xen_feature(XENFEAT_auto_translated_physmap)) {
> >  		set_fixmap(FIX_PARAVIRT_BOOTMAP,
> >  			   xen_start_info->shared_info);
> >
> > @@ -1044,6 +1058,10 @@ void xen_setup_shared_info(void)
> >  		HYPERVISOR_shared_info =
> >  			(struct shared_info
> > *)__va(xen_start_info->shared_info); 
> > +	/* PVH TBD/FIXME: vcpu info placement in phase 2 */
> > +	if (xen_pvh_domain())
> > +		return;
> 
> It seems that if xen_initial_domain we always skip the initialization
> while if !xen_initial_domain we only initialize
> HYPERVISOR_shared_info. I don't understand why we have this
> difference.

The comment in xen_pvh_guest_init() explains it. For domU the library
maps the pfn at shared_info, ie, shared_info is pfn. For dom0, it's the
mfn. Dom0 then allocates a pfn via extend_brk, and maps the mfn to it. This
happens in the commond hvm code, xen_hvm_init_shared_info().


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 24 22:44:18 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Sep 2012 22: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 1TGHNX-00052D-Ej; Mon, 24 Sep 2012 22:43:51 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mukesh.rathor@oracle.com>) id 1TGHNV-000528-St
	for Xen-devel@lists.xensource.com; Mon, 24 Sep 2012 22:43:50 +0000
Received: from [85.158.138.51:47683] by server-14.bemta-3.messagelabs.com id
	A5/CA-21431-522E0605; Mon, 24 Sep 2012 22:43:49 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1348526626!30122946!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDc2OTcxMA==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32088 invoked from network); 24 Sep 2012 22:43:48 -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; 24 Sep 2012 22:43:48 -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 q8OMhcfC030417
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 24 Sep 2012 22:43:39 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
	q8OMhbIl028830
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 24 Sep 2012 22:43:38 GMT
Received: from abhmt117.oracle.com (abhmt117.oracle.com [141.146.116.69])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q8OMha90015094; Mon, 24 Sep 2012 17:43:36 -0500
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 24 Sep 2012 15:43:36 -0700
Date: Mon, 24 Sep 2012 15:43:35 -0700
From: Mukesh Rathor <mukesh.rathor@oracle.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20120924154335.097d3fb9@mantra.us.oracle.com>
In-Reply-To: <alpine.DEB.2.02.1209241257440.29232@kaball.uk.xensource.com>
References: <20120921121659.5a723de9@mantra.us.oracle.com>
	<alpine.DEB.2.02.1209241257440.29232@kaball.uk.xensource.com>
Organization: Oracle Corporation
X-Mailer: Claws Mail 3.7.6 (GTK+ 2.18.9; x86_64-redhat-linux-gnu)
Mime-Version: 1.0
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: "Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH v1 3/8]: PVH startup changes (enlighten.c)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 24 Sep 2012 13:07:19 +0100
Stefano Stabellini <stefano.stabellini@eu.citrix.com> wrote:

> On Fri, 21 Sep 2012, Mukesh Rathor wrote:
> > ---
> >  arch/x86/xen/enlighten.c |   99
> > ++++++++++++++++++++++++++++++++++++--------- 1 files changed, 79
> > insertions(+), 20 deletions(-)
> > 
> > +			"with PVH extensions " : "", pv_info.name);
> >  	printk(KERN_INFO "Xen version: %d.%d%s%s\n",
> >  	       version >> 16, version & 0xffff, extra.extraversion,
> >  	       xen_feature(XENFEAT_mmu_pt_update_preserve_ad) ?
> > " (preserve-AD)" : ""); @@ -271,12 +278,15 @@ static void
> > xen_cpuid(unsigned int *ax, unsigned int *bx, break;
> >  	}
> >  
> > -	asm(XEN_EMULATE_PREFIX "cpuid"
> > -		: "=a" (*ax),
> > -		  "=b" (*bx),
> > -		  "=c" (*cx),
> > -		  "=d" (*dx)
> > -		: "0" (*ax), "2" (*cx));
> > +	if (xen_pvh_domain())
> > +		native_cpuid(ax, bx, cx, dx);
> > +	else
> > +		asm(XEN_EMULATE_PREFIX "cpuid"
> > +			: "=a" (*ax),
> > +			"=b" (*bx),
> > +			"=c" (*cx),
> > +			"=d" (*dx)
> > +			: "0" (*ax), "2" (*cx));
> 
> can't we just set the cpuid pvop to native_cpuid?

We had talked about this a bit at code review. There is some massaging
before and after that goes on, and so we thought we should just leave 
it like that.

> 
> >  	*bx &= maskebx;
> >  	*cx &= maskecx;
> > @@ -1034,6 +1044,10 @@ static int xen_write_msr_safe(unsigned int
> > msr, unsigned low, unsigned high) 
> >  void xen_setup_shared_info(void)
> >  {
> > +	/* do later in xen_pvh_guest_init() when extend_brk is
> > properly setup*/
> 
> Which one is the function that is going to get called later to do the
> initialization? It cannot be this one because it would still return
> immediately.

xen_pvh_guest_init() just like the comment says :).


> 
> > +	if (xen_pvh_domain() && xen_initial_domain())
> > +		return;
> > +
> >  	if (!xen_feature(XENFEAT_auto_translated_physmap)) {
> >  		set_fixmap(FIX_PARAVIRT_BOOTMAP,
> >  			   xen_start_info->shared_info);
> >
> > @@ -1044,6 +1058,10 @@ void xen_setup_shared_info(void)
> >  		HYPERVISOR_shared_info =
> >  			(struct shared_info
> > *)__va(xen_start_info->shared_info); 
> > +	/* PVH TBD/FIXME: vcpu info placement in phase 2 */
> > +	if (xen_pvh_domain())
> > +		return;
> 
> It seems that if xen_initial_domain we always skip the initialization
> while if !xen_initial_domain we only initialize
> HYPERVISOR_shared_info. I don't understand why we have this
> difference.

The comment in xen_pvh_guest_init() explains it. For domU the library
maps the pfn at shared_info, ie, shared_info is pfn. For dom0, it's the
mfn. Dom0 then allocates a pfn via extend_brk, and maps the mfn to it. This
happens in the commond hvm code, xen_hvm_init_shared_info().


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 24 22:49:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Sep 2012 22:49:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGHSL-0005A2-5e; Mon, 24 Sep 2012 22:48:49 +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 1TGHSJ-00059x-Tw
	for Xen-devel@lists.xensource.com; Mon, 24 Sep 2012 22:48:48 +0000
Received: from [85.158.143.35:2389] by server-2.bemta-4.messagelabs.com id
	DC/90-06610-F43E0605; Mon, 24 Sep 2012 22:48:47 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1348526920!16151053!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDc3MTA1OQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5691 invoked from network); 24 Sep 2012 22:48:41 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-14.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 24 Sep 2012 22:48:41 -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 q8OMmbhF001603
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 24 Sep 2012 22:48:37 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q8OMmax3022401
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 24 Sep 2012 22:48:37 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
	q8OMmaIG016765; Mon, 24 Sep 2012 17:48:36 -0500
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 24 Sep 2012 15:48:36 -0700
Date: Mon, 24 Sep 2012 15:48:34 -0700
From: Mukesh Rathor <mukesh.rathor@oracle.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20120924154834.434dce06@mantra.us.oracle.com>
In-Reply-To: <alpine.DEB.2.02.1209241310380.29232@kaball.uk.xensource.com>
References: <20120921121752.5fa80b35@mantra.us.oracle.com>
	<alpine.DEB.2.02.1209241310380.29232@kaball.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: acsinet21.oracle.com [141.146.126.237]
Cc: "Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH v1 4/8]: PVH setup changes...
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 24 Sep 2012 13:14:45 +0100
Stefano Stabellini <stefano.stabellini@eu.citrix.com> wrote:

> On Fri, 21 Sep 2012, Mukesh Rathor wrote:
> > @@ -500,10 +527,9 @@ void __cpuinit xen_enable_syscall(void)
> >  #endif /* CONFIG_X86_64 */
> >  }
> >  
> > -void __init xen_arch_setup(void)
> > +/* Non auto translated PV domain, ie, it's not PVH. */
> > +static __init void inline xen_non_pvh_arch_setup(void)
> >  {
> > -	xen_panic_handler_init();
> > -
> >  	HYPERVISOR_vm_assist(VMASST_CMD_enable,
> > VMASST_TYPE_4gb_segments); HYPERVISOR_vm_assist(VMASST_CMD_enable,
> > VMASST_TYPE_writable_pagetables); 
> > @@ -517,6 +543,15 @@ void __init xen_arch_setup(void)
> >  
> >  	xen_enable_sysenter();
> >  	xen_enable_syscall();
> > +}
> > +
> > +/* This function not called for HVM domain */
> > +void __init xen_arch_setup(void)
> > +{
> > +	xen_panic_handler_init();
> > +
> > +	if (!xen_feature(XENFEAT_auto_translated_physmap))
> > +		xen_non_pvh_arch_setup();
> >  
> >  #ifdef CONFIG_ACPI
> >  	if (!(xen_start_info->flags & SIF_INITDOMAIN)) {
>  
> IMHO having a xen_non_pvh_arch_setup function is less intuitive
> than just wrapping all that code around an
> 
> if (!xen_feature(XENFEAT_auto_translated_physmap)) {
> 
Too much indentation.

> Or at least you could name the function xen_pvmmu_arch_setup.

ok, fine, i'll rename it again.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Mon Sep 24 22:49:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 24 Sep 2012 22:49:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGHSL-0005A2-5e; Mon, 24 Sep 2012 22:48:49 +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 1TGHSJ-00059x-Tw
	for Xen-devel@lists.xensource.com; Mon, 24 Sep 2012 22:48:48 +0000
Received: from [85.158.143.35:2389] by server-2.bemta-4.messagelabs.com id
	DC/90-06610-F43E0605; Mon, 24 Sep 2012 22:48:47 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1348526920!16151053!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDc3MTA1OQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5691 invoked from network); 24 Sep 2012 22:48:41 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-14.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 24 Sep 2012 22:48:41 -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 q8OMmbhF001603
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 24 Sep 2012 22:48:37 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q8OMmax3022401
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 24 Sep 2012 22:48:37 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
	q8OMmaIG016765; Mon, 24 Sep 2012 17:48:36 -0500
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 24 Sep 2012 15:48:36 -0700
Date: Mon, 24 Sep 2012 15:48:34 -0700
From: Mukesh Rathor <mukesh.rathor@oracle.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20120924154834.434dce06@mantra.us.oracle.com>
In-Reply-To: <alpine.DEB.2.02.1209241310380.29232@kaball.uk.xensource.com>
References: <20120921121752.5fa80b35@mantra.us.oracle.com>
	<alpine.DEB.2.02.1209241310380.29232@kaball.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: acsinet21.oracle.com [141.146.126.237]
Cc: "Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH v1 4/8]: PVH setup changes...
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 24 Sep 2012 13:14:45 +0100
Stefano Stabellini <stefano.stabellini@eu.citrix.com> wrote:

> On Fri, 21 Sep 2012, Mukesh Rathor wrote:
> > @@ -500,10 +527,9 @@ void __cpuinit xen_enable_syscall(void)
> >  #endif /* CONFIG_X86_64 */
> >  }
> >  
> > -void __init xen_arch_setup(void)
> > +/* Non auto translated PV domain, ie, it's not PVH. */
> > +static __init void inline xen_non_pvh_arch_setup(void)
> >  {
> > -	xen_panic_handler_init();
> > -
> >  	HYPERVISOR_vm_assist(VMASST_CMD_enable,
> > VMASST_TYPE_4gb_segments); HYPERVISOR_vm_assist(VMASST_CMD_enable,
> > VMASST_TYPE_writable_pagetables); 
> > @@ -517,6 +543,15 @@ void __init xen_arch_setup(void)
> >  
> >  	xen_enable_sysenter();
> >  	xen_enable_syscall();
> > +}
> > +
> > +/* This function not called for HVM domain */
> > +void __init xen_arch_setup(void)
> > +{
> > +	xen_panic_handler_init();
> > +
> > +	if (!xen_feature(XENFEAT_auto_translated_physmap))
> > +		xen_non_pvh_arch_setup();
> >  
> >  #ifdef CONFIG_ACPI
> >  	if (!(xen_start_info->flags & SIF_INITDOMAIN)) {
>  
> IMHO having a xen_non_pvh_arch_setup function is less intuitive
> than just wrapping all that code around an
> 
> if (!xen_feature(XENFEAT_auto_translated_physmap)) {
> 
Too much indentation.

> Or at least you could name the function xen_pvmmu_arch_setup.

ok, fine, i'll rename it again.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 25 00:50:58 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 00: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 1TGJLx-0006Ca-8A; Tue, 25 Sep 2012 00:50:21 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <john.krstev@gmail.com>) id 1TGJLv-0006CU-8B
	for xen-devel@lists.xensource.com; Tue, 25 Sep 2012 00:50:19 +0000
Received: from [85.158.139.83:20514] by server-5.bemta-5.messagelabs.com id
	3B/C5-21075-ACFF0605; Tue, 25 Sep 2012 00:50:18 +0000
X-Env-Sender: john.krstev@gmail.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1348534215!24732694!1
X-Originating-IP: [209.85.160.43]
X-SpamReason: No, hits=0.4 required=7.0 tests=MIME_QP_LONG_LINE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28674 invoked from network); 25 Sep 2012 00:50:17 -0000
Received: from mail-pb0-f43.google.com (HELO mail-pb0-f43.google.com)
	(209.85.160.43)
	by server-11.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Sep 2012 00:50:17 -0000
Received: by pbbjt11 with SMTP id jt11so2081391pbb.30
	for <xen-devel@lists.xensource.com>;
	Mon, 24 Sep 2012 17:50:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=references:in-reply-to:mime-version:content-transfer-encoding
	:content-type:message-id:cc:x-mailer:from:subject:date:to;
	bh=fNBEQGsC+qWTI6yugv1UZSQNdSS/fU1lAmSbi6768dg=;
	b=dgMBLSDItJKsZ/St+9kxj5Csro2Jix51PgkWw+803NnoGG6IzX1t9MwHZhmJk2w/Cp
	QBHPQeenpTr4waQcGUBMMr64QCpNTZw35xqhrtYfs2FUVVH1Tuo15Ldr5IQIO2RdL/y0
	rXqte13o4qVjWuQe/g8Mjlsui3VBHGKDtdRnW3ln2sSybMrJRLYpTmiW7SpR1HW94emi
	TRi8KDdiYbe2J6FFvzwCFEWn/XUGbK/dKQmsHc+E/tW9BI66yDZ9lqChOn/Ijbf2YMis
	A7E4muGlijTJdg5/1Wy687SFvMgEPHgWzbZ8vCRQzv5/bMqCo7m7vazFCCFsH4BVlduf
	1MDg==
Received: by 10.68.203.195 with SMTP id ks3mr41100420pbc.79.1348534214973;
	Mon, 24 Sep 2012 17:50:14 -0700 (PDT)
Received: from [10.241.26.79] ([110.145.56.221])
	by mx.google.com with ESMTPS id pa6sm10390038pbc.71.2012.09.24.17.49.56
	(version=TLSv1/SSLv3 cipher=OTHER);
	Mon, 24 Sep 2012 17:50:14 -0700 (PDT)
References: <CA+LkAa=RHJCtpncP8AUSeR8Te3ZLMvRctuZqnv_NwUkCQ-im8Q@mail.gmail.com>
	<20120921172901.GA6821@phenom.dumpdata.com>
In-Reply-To: <20120921172901.GA6821@phenom.dumpdata.com>
Mime-Version: 1.0 (1.0)
Message-Id: <099949C5-C4C0-4D57-A778-849C94781372@gmail.com>
X-Mailer: iPhone Mail (9B208)
From: John Krstev <john.krstev@gmail.com>
Date: Tue, 25 Sep 2012 10:49:38 +1000
To: Konrad Rzeszutek Wilk <konrad@kernel.org>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Xen + DVB = not working. memory allocation issue?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hello Konrad,

Do you have any patches I can try? FYI I've tried booting dom0 with mem=3G and various other options, still does not work. As I mentioned it runs fine on bare metal. 

Last time it did work with xen was Jeremy's kernel + xen 4.0, also kernel 3.0.8 with xen 4.0.4 i believe (cannot reproduce success).

Thank you again for your input. 

Regards,

John



On 22/09/2012, at 3:29, Konrad Rzeszutek Wilk <konrad@kernel.org> wrote:

> On Fri, Sep 21, 2012 at 01:02:23PM +1000, John Krstev wrote:
>> Hi Konrad,
> 
> Hey John,
> 
> Please next time also include xen-devel on the To header. I've done that
> for you.
>> 
>> I refer to your patch at:
>> http://lists.xen.org/archives/html/xen-devel/2012-01/msg01927.html
>> which I found reading
>> http://www.gossamer-threads.com/lists/xen/devel/256197
>> 
>> I have a winfast DVT 2000H (cx88) DVB card which is not able to
>> scan/watch digital TV when running under Xen.
> 
> Did you first try running it under baremetal Linux (using a Live CD for
> example?) Did it work there?
> 
> How does it not work? Can you program it? Is this under a guest or the
> main kernel? When it wsa not working, did you try all the debug
> options enable (http://wiki.xen.org/wiki/XenSerialConsole) to
> see if there is anthing being reported?
> 
>> 
>> I've tried installing the above patch to the 3.6-rc6 kernel, but did
>> not seem to help.
>> 
>> Apologies if this has been asked before (I wasn't able to find another
>> patch), but is there a patch to get this (suspected vmalloc_32) fixed
>> and DVB card working?
> 
> Eventually yes.
>> 
>> FYI I'm running 64 bit 3.5-rc6 and xen 4.3-unstable.
> 
> 3.5-rc6 or 3.6-rc6?
> I presume the latter?
>> 
>> Thank you! :)
>> 
>> Regards,
>> 
>> John
>> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 25 00:50:58 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 00: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 1TGJLx-0006Ca-8A; Tue, 25 Sep 2012 00:50:21 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <john.krstev@gmail.com>) id 1TGJLv-0006CU-8B
	for xen-devel@lists.xensource.com; Tue, 25 Sep 2012 00:50:19 +0000
Received: from [85.158.139.83:20514] by server-5.bemta-5.messagelabs.com id
	3B/C5-21075-ACFF0605; Tue, 25 Sep 2012 00:50:18 +0000
X-Env-Sender: john.krstev@gmail.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1348534215!24732694!1
X-Originating-IP: [209.85.160.43]
X-SpamReason: No, hits=0.4 required=7.0 tests=MIME_QP_LONG_LINE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28674 invoked from network); 25 Sep 2012 00:50:17 -0000
Received: from mail-pb0-f43.google.com (HELO mail-pb0-f43.google.com)
	(209.85.160.43)
	by server-11.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Sep 2012 00:50:17 -0000
Received: by pbbjt11 with SMTP id jt11so2081391pbb.30
	for <xen-devel@lists.xensource.com>;
	Mon, 24 Sep 2012 17:50:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=references:in-reply-to:mime-version:content-transfer-encoding
	:content-type:message-id:cc:x-mailer:from:subject:date:to;
	bh=fNBEQGsC+qWTI6yugv1UZSQNdSS/fU1lAmSbi6768dg=;
	b=dgMBLSDItJKsZ/St+9kxj5Csro2Jix51PgkWw+803NnoGG6IzX1t9MwHZhmJk2w/Cp
	QBHPQeenpTr4waQcGUBMMr64QCpNTZw35xqhrtYfs2FUVVH1Tuo15Ldr5IQIO2RdL/y0
	rXqte13o4qVjWuQe/g8Mjlsui3VBHGKDtdRnW3ln2sSybMrJRLYpTmiW7SpR1HW94emi
	TRi8KDdiYbe2J6FFvzwCFEWn/XUGbK/dKQmsHc+E/tW9BI66yDZ9lqChOn/Ijbf2YMis
	A7E4muGlijTJdg5/1Wy687SFvMgEPHgWzbZ8vCRQzv5/bMqCo7m7vazFCCFsH4BVlduf
	1MDg==
Received: by 10.68.203.195 with SMTP id ks3mr41100420pbc.79.1348534214973;
	Mon, 24 Sep 2012 17:50:14 -0700 (PDT)
Received: from [10.241.26.79] ([110.145.56.221])
	by mx.google.com with ESMTPS id pa6sm10390038pbc.71.2012.09.24.17.49.56
	(version=TLSv1/SSLv3 cipher=OTHER);
	Mon, 24 Sep 2012 17:50:14 -0700 (PDT)
References: <CA+LkAa=RHJCtpncP8AUSeR8Te3ZLMvRctuZqnv_NwUkCQ-im8Q@mail.gmail.com>
	<20120921172901.GA6821@phenom.dumpdata.com>
In-Reply-To: <20120921172901.GA6821@phenom.dumpdata.com>
Mime-Version: 1.0 (1.0)
Message-Id: <099949C5-C4C0-4D57-A778-849C94781372@gmail.com>
X-Mailer: iPhone Mail (9B208)
From: John Krstev <john.krstev@gmail.com>
Date: Tue, 25 Sep 2012 10:49:38 +1000
To: Konrad Rzeszutek Wilk <konrad@kernel.org>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Xen + DVB = not working. memory allocation issue?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hello Konrad,

Do you have any patches I can try? FYI I've tried booting dom0 with mem=3G and various other options, still does not work. As I mentioned it runs fine on bare metal. 

Last time it did work with xen was Jeremy's kernel + xen 4.0, also kernel 3.0.8 with xen 4.0.4 i believe (cannot reproduce success).

Thank you again for your input. 

Regards,

John



On 22/09/2012, at 3:29, Konrad Rzeszutek Wilk <konrad@kernel.org> wrote:

> On Fri, Sep 21, 2012 at 01:02:23PM +1000, John Krstev wrote:
>> Hi Konrad,
> 
> Hey John,
> 
> Please next time also include xen-devel on the To header. I've done that
> for you.
>> 
>> I refer to your patch at:
>> http://lists.xen.org/archives/html/xen-devel/2012-01/msg01927.html
>> which I found reading
>> http://www.gossamer-threads.com/lists/xen/devel/256197
>> 
>> I have a winfast DVT 2000H (cx88) DVB card which is not able to
>> scan/watch digital TV when running under Xen.
> 
> Did you first try running it under baremetal Linux (using a Live CD for
> example?) Did it work there?
> 
> How does it not work? Can you program it? Is this under a guest or the
> main kernel? When it wsa not working, did you try all the debug
> options enable (http://wiki.xen.org/wiki/XenSerialConsole) to
> see if there is anthing being reported?
> 
>> 
>> I've tried installing the above patch to the 3.6-rc6 kernel, but did
>> not seem to help.
>> 
>> Apologies if this has been asked before (I wasn't able to find another
>> patch), but is there a patch to get this (suspected vmalloc_32) fixed
>> and DVB card working?
> 
> Eventually yes.
>> 
>> FYI I'm running 64 bit 3.5-rc6 and xen 4.3-unstable.
> 
> 3.5-rc6 or 3.6-rc6?
> I presume the latter?
>> 
>> Thank you! :)
>> 
>> Regards,
>> 
>> John
>> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 25 01:38:54 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 01:38: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 1TGK6T-0001wH-BT; Tue, 25 Sep 2012 01:38: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 1TGK6R-0001wC-Bb
	for xen-devel@lists.xensource.com; Tue, 25 Sep 2012 01:38:23 +0000
Received: from [85.158.143.99:33153] by server-2.bemta-4.messagelabs.com id
	19/44-06610-E0B01605; Tue, 25 Sep 2012 01:38:22 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1348537101!30708447!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTA5ODg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6310 invoked from network); 25 Sep 2012 01:38:22 -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;
	25 Sep 2012 01:38:22 -0000
X-IronPort-AV: E=Sophos;i="4.80,478,1344211200"; d="scan'208";a="14736312"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Sep 2012 01:38: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.279.1; Tue, 25 Sep 2012 02:38: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 1TGK6P-000146-2j;
	Tue, 25 Sep 2012 01:38:21 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1TGK6O-0007xW-EV;
	Tue, 25 Sep 2012 02:38:20 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-13862-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Tue, 25 Sep 2012 02:38:20 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13862: regressions - trouble:
	blocked/broken/fail/pass
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 13862 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13862/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-win-vcpus1    5 xen-boot                  fail REGR. vs. 13825
 build-amd64-pvops             2 host-install(2)         broken REGR. vs. 13825
 test-amd64-i386-xl-multivcpu  5 xen-boot         fail in 13837 REGR. vs. 13825
 test-amd64-i386-xl-win-vcpus1  5 xen-boot        fail in 13837 REGR. vs. 13825
 test-amd64-i386-qemuu-rhel6hvm-intel  5 xen-boot fail in 13837 REGR. vs. 13825
 test-amd64-i386-xl-win7-amd64  5 xen-boot        fail in 13837 REGR. vs. 13825
 test-amd64-amd64-win          5 xen-boot         fail in 13837 REGR. vs. 13825
 test-amd64-amd64-xl-winxpsp3  5 xen-boot         fail in 13837 REGR. vs. 13825
 test-amd64-i386-pair         8 xen-boot/dst_host fail in 13837 REGR. vs. 13825
 test-amd64-i386-pair         7 xen-boot/src_host fail in 13837 REGR. vs. 13825

Tests which are failing intermittently (not blocking):
 test-amd64-i386-rhel6hvm-intel  5 xen-boot                  fail pass in 13837
 test-amd64-i386-xl-credit2    5 xen-boot                    fail pass in 13837
 test-amd64-i386-xl-multivcpu  3 host-install(3)           broken pass in 13848
 test-amd64-i386-xl-win-vcpus1  3 host-install(3)          broken pass in 13848
 test-amd64-i386-qemuu-rhel6hvm-intel  3 host-install(3)   broken pass in 13859
 test-amd64-i386-pv            3 host-install(3)           broken pass in 13859
 test-amd64-i386-xl            3 host-install(3)           broken pass in 13848
 test-amd64-i386-xl-win7-amd64  3 host-install(3)          broken pass in 13848
 test-amd64-i386-pair          3 host-install/src_host(3)  broken pass in 13848
 test-amd64-amd64-xl-win7-amd64 12 guest-localmigrate/x10 fail in 13837 pass in 13848
 test-amd64-amd64-pv           5 xen-boot           fail in 13848 pass in 13841
 test-amd64-i386-xl-credit2    3 host-install(3)  broken in 13848 pass in 13862
 test-amd64-i386-win-vcpus1    3 host-install(3)  broken in 13848 pass in 13862

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore     fail in 13837 like 13825
 test-amd64-amd64-xl-sedf      3 host-install(3)     broken in 13837 like 13825
 test-amd64-amd64-xl-pcipt-intel  5 xen-boot      fail in 13837 REGR. vs. 13825
 test-amd64-amd64-xl-qemuu-winxpsp3 9 guest-localmigrate fail in 13837 like 13823
 test-amd64-amd64-xl-qemuu-win7-amd64 9 guest-localmigrate fail in 13837 like 13825

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf-pin  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 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-amd64-pv           1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-pcipt-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  1 xen-build-check(1)           blocked n/a
 test-amd64-amd64-win          1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 xen-build-check(1)         blocked n/a
 test-amd64-amd64-xl-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-pair         1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win      13 guest-stop            fail in 13837 never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop          fail in 13848 never pass

version targeted for testing:
 xen                  8f658b463b78
baseline version:
 xen                  d364becfb083

------------------------------------------------------------
People who touched revisions under test:
  Jan Beulich <jbeulich@suse.com>
  Keir Fraser <keir@xen.org>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            broken  
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          blocked 
 test-amd64-i386-xl                                           broken  
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemuu-win7-amd64                         blocked 
 test-amd64-amd64-xl-win7-amd64                               blocked 
 test-amd64-i386-xl-win7-amd64                                broken  
 test-amd64-i386-xl-credit2                                   fail    
 test-amd64-amd64-xl-pcipt-intel                              blocked 
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         broken  
 test-amd64-i386-xl-multivcpu                                 broken  
 test-amd64-amd64-pair                                        blocked 
 test-amd64-i386-pair                                         broken  
 test-amd64-amd64-xl-sedf-pin                                 blocked 
 test-amd64-amd64-pv                                          blocked 
 test-amd64-i386-pv                                           broken  
 test-amd64-amd64-xl-sedf                                     blocked 
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                broken  
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         blocked 
 test-amd64-i386-win                                          fail    
 test-amd64-amd64-xl-win                                      blocked 
 test-amd64-amd64-xl-qemuu-winxpsp3                           blocked 
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-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.

------------------------------------------------------------
changeset:   25938:8f658b463b78
tag:         tip
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Sep 21 17:02:46 2012 +0200
    
    x86: enable VIA CPU support
    
    Newer VIA CPUs have both 64-bit and VMX support. Enable them to be
    recognized for these purposes, at once stripping off any 32-bit CPU
    only bits from the respective CPU support file, and adding 64-bit ones
    found in recent Linux.
    
    This particularly implies untying the VMX == Intel assumption in a few
    places.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   25937:32187301ecc5
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Sep 21 15:20:21 2012 +0200
    
    x86: eliminate code affecting only 64-bit-incapable CPUs
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   25936:c8873f13cec3
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Sep 21 14:25:12 2012 +0200
    
    printk: prefer %#x et at over 0x%x
    
    Performance is not an issue with printk(), so let the function do
    minimally more work and instead save a byte per affected format
    specifier.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   25935:1e6e6b49b4ac
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Sep 21 13:47:18 2012 +0200
    
    x86: introduce MWAIT-based, ACPI-less CPU idle driver
    
    This is a port of Linux'es intel-idle driver serving the same purpose.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   25934:8eab91903e71
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Sep 21 13:45:08 2012 +0200
    
    cpuidle: remove unused latency_ticks member
    
    ... and code used only for initializing it.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   25933:d364becfb083
user:        Jan Beulich <jbeulich@suse.com>
date:        Thu Sep 20 13:31:19 2012 +0200
    
    introduce guest_handle_for_field()
    
    This helper turns a field of a GUEST_HANDLE in a GUEST_HANDLE.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    
    
(qemu changes not included)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 25 01:38:54 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 01:38: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 1TGK6T-0001wH-BT; Tue, 25 Sep 2012 01:38: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 1TGK6R-0001wC-Bb
	for xen-devel@lists.xensource.com; Tue, 25 Sep 2012 01:38:23 +0000
Received: from [85.158.143.99:33153] by server-2.bemta-4.messagelabs.com id
	19/44-06610-E0B01605; Tue, 25 Sep 2012 01:38:22 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1348537101!30708447!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTA5ODg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6310 invoked from network); 25 Sep 2012 01:38:22 -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;
	25 Sep 2012 01:38:22 -0000
X-IronPort-AV: E=Sophos;i="4.80,478,1344211200"; d="scan'208";a="14736312"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Sep 2012 01:38: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.279.1; Tue, 25 Sep 2012 02:38: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 1TGK6P-000146-2j;
	Tue, 25 Sep 2012 01:38:21 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1TGK6O-0007xW-EV;
	Tue, 25 Sep 2012 02:38:20 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-13862-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Tue, 25 Sep 2012 02:38:20 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13862: regressions - trouble:
	blocked/broken/fail/pass
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 13862 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13862/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-win-vcpus1    5 xen-boot                  fail REGR. vs. 13825
 build-amd64-pvops             2 host-install(2)         broken REGR. vs. 13825
 test-amd64-i386-xl-multivcpu  5 xen-boot         fail in 13837 REGR. vs. 13825
 test-amd64-i386-xl-win-vcpus1  5 xen-boot        fail in 13837 REGR. vs. 13825
 test-amd64-i386-qemuu-rhel6hvm-intel  5 xen-boot fail in 13837 REGR. vs. 13825
 test-amd64-i386-xl-win7-amd64  5 xen-boot        fail in 13837 REGR. vs. 13825
 test-amd64-amd64-win          5 xen-boot         fail in 13837 REGR. vs. 13825
 test-amd64-amd64-xl-winxpsp3  5 xen-boot         fail in 13837 REGR. vs. 13825
 test-amd64-i386-pair         8 xen-boot/dst_host fail in 13837 REGR. vs. 13825
 test-amd64-i386-pair         7 xen-boot/src_host fail in 13837 REGR. vs. 13825

Tests which are failing intermittently (not blocking):
 test-amd64-i386-rhel6hvm-intel  5 xen-boot                  fail pass in 13837
 test-amd64-i386-xl-credit2    5 xen-boot                    fail pass in 13837
 test-amd64-i386-xl-multivcpu  3 host-install(3)           broken pass in 13848
 test-amd64-i386-xl-win-vcpus1  3 host-install(3)          broken pass in 13848
 test-amd64-i386-qemuu-rhel6hvm-intel  3 host-install(3)   broken pass in 13859
 test-amd64-i386-pv            3 host-install(3)           broken pass in 13859
 test-amd64-i386-xl            3 host-install(3)           broken pass in 13848
 test-amd64-i386-xl-win7-amd64  3 host-install(3)          broken pass in 13848
 test-amd64-i386-pair          3 host-install/src_host(3)  broken pass in 13848
 test-amd64-amd64-xl-win7-amd64 12 guest-localmigrate/x10 fail in 13837 pass in 13848
 test-amd64-amd64-pv           5 xen-boot           fail in 13848 pass in 13841
 test-amd64-i386-xl-credit2    3 host-install(3)  broken in 13848 pass in 13862
 test-amd64-i386-win-vcpus1    3 host-install(3)  broken in 13848 pass in 13862

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore     fail in 13837 like 13825
 test-amd64-amd64-xl-sedf      3 host-install(3)     broken in 13837 like 13825
 test-amd64-amd64-xl-pcipt-intel  5 xen-boot      fail in 13837 REGR. vs. 13825
 test-amd64-amd64-xl-qemuu-winxpsp3 9 guest-localmigrate fail in 13837 like 13823
 test-amd64-amd64-xl-qemuu-win7-amd64 9 guest-localmigrate fail in 13837 like 13825

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf-pin  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 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-amd64-pv           1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-pcipt-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  1 xen-build-check(1)           blocked n/a
 test-amd64-amd64-win          1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 xen-build-check(1)         blocked n/a
 test-amd64-amd64-xl-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-pair         1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win      13 guest-stop            fail in 13837 never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop          fail in 13848 never pass

version targeted for testing:
 xen                  8f658b463b78
baseline version:
 xen                  d364becfb083

------------------------------------------------------------
People who touched revisions under test:
  Jan Beulich <jbeulich@suse.com>
  Keir Fraser <keir@xen.org>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            broken  
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          blocked 
 test-amd64-i386-xl                                           broken  
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemuu-win7-amd64                         blocked 
 test-amd64-amd64-xl-win7-amd64                               blocked 
 test-amd64-i386-xl-win7-amd64                                broken  
 test-amd64-i386-xl-credit2                                   fail    
 test-amd64-amd64-xl-pcipt-intel                              blocked 
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         broken  
 test-amd64-i386-xl-multivcpu                                 broken  
 test-amd64-amd64-pair                                        blocked 
 test-amd64-i386-pair                                         broken  
 test-amd64-amd64-xl-sedf-pin                                 blocked 
 test-amd64-amd64-pv                                          blocked 
 test-amd64-i386-pv                                           broken  
 test-amd64-amd64-xl-sedf                                     blocked 
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                broken  
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         blocked 
 test-amd64-i386-win                                          fail    
 test-amd64-amd64-xl-win                                      blocked 
 test-amd64-amd64-xl-qemuu-winxpsp3                           blocked 
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-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.

------------------------------------------------------------
changeset:   25938:8f658b463b78
tag:         tip
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Sep 21 17:02:46 2012 +0200
    
    x86: enable VIA CPU support
    
    Newer VIA CPUs have both 64-bit and VMX support. Enable them to be
    recognized for these purposes, at once stripping off any 32-bit CPU
    only bits from the respective CPU support file, and adding 64-bit ones
    found in recent Linux.
    
    This particularly implies untying the VMX == Intel assumption in a few
    places.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   25937:32187301ecc5
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Sep 21 15:20:21 2012 +0200
    
    x86: eliminate code affecting only 64-bit-incapable CPUs
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   25936:c8873f13cec3
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Sep 21 14:25:12 2012 +0200
    
    printk: prefer %#x et at over 0x%x
    
    Performance is not an issue with printk(), so let the function do
    minimally more work and instead save a byte per affected format
    specifier.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   25935:1e6e6b49b4ac
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Sep 21 13:47:18 2012 +0200
    
    x86: introduce MWAIT-based, ACPI-less CPU idle driver
    
    This is a port of Linux'es intel-idle driver serving the same purpose.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   25934:8eab91903e71
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Sep 21 13:45:08 2012 +0200
    
    cpuidle: remove unused latency_ticks member
    
    ... and code used only for initializing it.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   25933:d364becfb083
user:        Jan Beulich <jbeulich@suse.com>
date:        Thu Sep 20 13:31:19 2012 +0200
    
    introduce guest_handle_for_field()
    
    This helper turns a field of a GUEST_HANDLE in a GUEST_HANDLE.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    
    
(qemu changes not included)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 25 03:17:37 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 03: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 1TGLdz-0002lF-W8; Tue, 25 Sep 2012 03:17:08 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <qianhu2011@gmail.com>) id 1TGLdy-0002lA-W8
	for xen-devel@lists.xen.org; Tue, 25 Sep 2012 03:17:07 +0000
Received: from [85.158.139.83:60567] by server-7.bemta-5.messagelabs.com id
	D7/15-00431-23221605; Tue, 25 Sep 2012 03:17:06 +0000
X-Env-Sender: qianhu2011@gmail.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1348543024!29115728!1
X-Originating-IP: [209.85.212.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9402 invoked from network); 25 Sep 2012 03:17:05 -0000
Received: from mail-vb0-f45.google.com (HELO mail-vb0-f45.google.com)
	(209.85.212.45)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Sep 2012 03:17:05 -0000
Received: by vbip1 with SMTP id p1so8303672vbi.32
	for <xen-devel@lists.xen.org>; Mon, 24 Sep 2012 20:17:04 -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=R9mg3eoNB4Em1BCghVQTAH7eDKmmpxkdfhBaQ7iEol4=;
	b=mEfe5RuIfMi/uBZyK/y6IB2uz0rYHFMnrrY/AhNLAMNyYYdl1ZU4j80n87VTWF73uh
	gOBAjf23SWPZwxb2DOPWVPgphdQ7JDCqXXtTtAKU+RZ4ulvAepkpfwpSbNj4BI3Fc2y1
	oQkPdAzocFq4z0dlDAaWfXWVvc7lP6Bq9SIUcJTyy7i75qQXqvGKQJZ4jmAFcwVyhS6k
	x2KauoL1fSyl/pOsO/odpzqFrs5km8yF5bT9oYs44gqqaXJNVCr9NxBK2ybO2gA73+rm
	T+WtRIFg6M66EDeuaUjubCZMgYN07B+R1x8yols7mrVE0cCOl3href2eRaP+3fZa/tyC
	IeMw==
MIME-Version: 1.0
Received: by 10.58.23.100 with SMTP id l4mr8725443vef.46.1348543023959; Mon,
	24 Sep 2012 20:17:03 -0700 (PDT)
Received: by 10.58.249.236 with HTTP; Mon, 24 Sep 2012 20:17:03 -0700 (PDT)
Date: Tue, 25 Sep 2012 11:17:03 +0800
Message-ID: <CALCpXpCvGkjZyG-NOY+fZY0q0f_DxuwPNEnxwKXVhjOe=gcHSQ@mail.gmail.com>
From: Qian Hu <qianhu2011@gmail.com>
To: xen-devel@lists.xen.org
Subject: [Xen-devel] usbpassthrough of xen-4.1.2 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: multipart/mixed; boundary="===============8234836942949505454=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============8234836942949505454==
Content-Type: multipart/alternative; boundary=047d7b339d9de8505a04ca7e23ba

--047d7b339d9de8505a04ca7e23ba
Content-Type: text/plain; charset=ISO-8859-1

Hi, everyone! The same question with updated message.

I am working on the USB passthrough of Xen-4.1.2. My host OS  is Fedora 14
and the guest OS is win7.

According to the wiki page(http://wiki.xen.org/wiki/Xen_USB_Passthrough),

xen supports passthrough of usb device from dom0 to guests. I have tried
the Xen HVM guest qemu-dm usb1.1 emulation,

by specifying "usb = 1" and "usbdevice = host:xxxx:yyyy". I have also tried
the command usb_add host:xxxx:yyyy.

But, the mouse could work, the keyboard didn't, and the usb storage
device(usb 2.0) appeared in the device manager.

While the driver is OK, it couldn't start. I can only find the message
 "The device cannot start(code 10)".

I doubt there may be something wrong with the guest OS driver, which is not
said to be needed.

I am confused and don't know how to resolve it.  Could anyone help me?

Great thanks!

huqian

--047d7b339d9de8505a04ca7e23ba
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<span style=3D"color:rgb(34,34,34);font-size:14px;font-family:arial,sans-se=
rif">Hi, everyone! The same question with updated message.</span><div style=
=3D"color:rgb(34,34,34);font-size:14px;font-family:arial,sans-serif">
<br></div><div style=3D"color:rgb(34,34,34);font-size:14px;font-family:aria=
l,sans-serif">I am working on the USB passthrough of=A0Xen-4.1.2. My host O=
S =A0is Fedora 14 and the guest OS is win7.</div>
<div style=3D"color:rgb(34,34,34);font-size:14px;font-family:arial,sans-ser=
if"><br></div><div style=3D"color:rgb(34,34,34);font-size:14px;font-family:=
arial,sans-serif">
According to the wiki page(<a href=3D"http://wiki.xen.org/wiki/Xen_USB_Pass=
through" style=3D"color:rgb(17,85,204)" target=3D"_blank">http://wiki.xen.o=
rg/wiki/Xen_USB_Passthrough</a>),=A0</div><div style=3D"color:rgb(34,34,34)=
;font-size:14px;font-family:arial,sans-serif">


<br></div><div style=3D"color:rgb(34,34,34);font-size:14px;font-family:aria=
l,sans-serif">xen supports passthrough of usb device from dom0 to guests. I=
 have tried the Xen HVM guest qemu-dm usb1.1 emulation,</div>
<div style=3D"color:rgb(34,34,34);font-size:14px;font-family:arial,sans-ser=
if"><br></div><div style=3D"color:rgb(34,34,34);font-size:14px;font-family:=
arial,sans-serif">
by specifying &quot;usb =3D 1&quot; and &quot;usbdevice =3D host:xxxx:yyyy&=
quot;. I have also tried the command=A0<span style=3D"background-color:rgb(=
249,249,249);line-height:1.3em">usb_add host:xxxx:yyyy.</span></div><div st=
yle=3D"color:rgb(34,34,34);font-size:14px;font-family:arial,sans-serif">

<br></div><div style=3D"color:rgb(34,34,34);font-size:14px;font-family:aria=
l,sans-serif">But, the mouse could work, the keyboard didn&#39;t, and the u=
sb storage device(usb 2.0)<span style=3D"background-color:rgb(255,255,255)"=
>=A0appeared in the device manager.</span></div>
<div style=3D"color:rgb(34,34,34);font-size:14px;font-family:arial,sans-ser=
if"><span style=3D"background-color:rgb(255,255,255)"><br></span></div><div=
 style=3D"color:rgb(34,34,34);font-size:14px;font-family:arial,sans-serif">=
<span style=3D"background-color:rgb(255,255,255)">While the driver is OK, i=
t couldn&#39;t start.=A0</span><span style=3D"background-color:rgb(255,255,=
255)">I can only find the message =A0&quot;The device cannot start(code 10)=
&quot;.</span></div>
<div style=3D"color:rgb(34,34,34);font-size:14px;font-family:arial,sans-ser=
if"><span style=3D"background-color:rgb(255,255,255)"><br></span></div><div=
 style=3D"color:rgb(34,34,34);font-size:14px;font-family:arial,sans-serif">=
<span style=3D"background-color:rgb(255,255,255)">I doubt there may be some=
thing wrong with the guest OS driver, which is not said to be needed.</span=
></div>
<div style=3D"color:rgb(34,34,34);font-size:14px;font-family:arial,sans-ser=
if"><br></div><div style=3D"color:rgb(34,34,34);font-size:14px;font-family:=
arial,sans-serif">

I am confused and don&#39;t know how to resolve it. =A0Could anyone help me=
?</div><div style=3D"color:rgb(34,34,34);font-size:14px;font-family:arial,s=
ans-serif"><br></div><div style=3D"color:rgb(34,34,34);font-size:14px;font-=
family:arial,sans-serif">


Great thanks!</div><div style=3D"color:rgb(34,34,34);font-size:14px;font-fa=
mily:arial,sans-serif"><br></div><div style=3D"color:rgb(34,34,34);font-siz=
e:14px;font-family:arial,sans-serif">huqian</div>

--047d7b339d9de8505a04ca7e23ba--


--===============8234836942949505454==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============8234836942949505454==--


From xen-devel-bounces@lists.xen.org Tue Sep 25 03:17:37 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 03: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 1TGLdz-0002lF-W8; Tue, 25 Sep 2012 03:17:08 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <qianhu2011@gmail.com>) id 1TGLdy-0002lA-W8
	for xen-devel@lists.xen.org; Tue, 25 Sep 2012 03:17:07 +0000
Received: from [85.158.139.83:60567] by server-7.bemta-5.messagelabs.com id
	D7/15-00431-23221605; Tue, 25 Sep 2012 03:17:06 +0000
X-Env-Sender: qianhu2011@gmail.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1348543024!29115728!1
X-Originating-IP: [209.85.212.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9402 invoked from network); 25 Sep 2012 03:17:05 -0000
Received: from mail-vb0-f45.google.com (HELO mail-vb0-f45.google.com)
	(209.85.212.45)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Sep 2012 03:17:05 -0000
Received: by vbip1 with SMTP id p1so8303672vbi.32
	for <xen-devel@lists.xen.org>; Mon, 24 Sep 2012 20:17:04 -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=R9mg3eoNB4Em1BCghVQTAH7eDKmmpxkdfhBaQ7iEol4=;
	b=mEfe5RuIfMi/uBZyK/y6IB2uz0rYHFMnrrY/AhNLAMNyYYdl1ZU4j80n87VTWF73uh
	gOBAjf23SWPZwxb2DOPWVPgphdQ7JDCqXXtTtAKU+RZ4ulvAepkpfwpSbNj4BI3Fc2y1
	oQkPdAzocFq4z0dlDAaWfXWVvc7lP6Bq9SIUcJTyy7i75qQXqvGKQJZ4jmAFcwVyhS6k
	x2KauoL1fSyl/pOsO/odpzqFrs5km8yF5bT9oYs44gqqaXJNVCr9NxBK2ybO2gA73+rm
	T+WtRIFg6M66EDeuaUjubCZMgYN07B+R1x8yols7mrVE0cCOl3href2eRaP+3fZa/tyC
	IeMw==
MIME-Version: 1.0
Received: by 10.58.23.100 with SMTP id l4mr8725443vef.46.1348543023959; Mon,
	24 Sep 2012 20:17:03 -0700 (PDT)
Received: by 10.58.249.236 with HTTP; Mon, 24 Sep 2012 20:17:03 -0700 (PDT)
Date: Tue, 25 Sep 2012 11:17:03 +0800
Message-ID: <CALCpXpCvGkjZyG-NOY+fZY0q0f_DxuwPNEnxwKXVhjOe=gcHSQ@mail.gmail.com>
From: Qian Hu <qianhu2011@gmail.com>
To: xen-devel@lists.xen.org
Subject: [Xen-devel] usbpassthrough of xen-4.1.2 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: multipart/mixed; boundary="===============8234836942949505454=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============8234836942949505454==
Content-Type: multipart/alternative; boundary=047d7b339d9de8505a04ca7e23ba

--047d7b339d9de8505a04ca7e23ba
Content-Type: text/plain; charset=ISO-8859-1

Hi, everyone! The same question with updated message.

I am working on the USB passthrough of Xen-4.1.2. My host OS  is Fedora 14
and the guest OS is win7.

According to the wiki page(http://wiki.xen.org/wiki/Xen_USB_Passthrough),

xen supports passthrough of usb device from dom0 to guests. I have tried
the Xen HVM guest qemu-dm usb1.1 emulation,

by specifying "usb = 1" and "usbdevice = host:xxxx:yyyy". I have also tried
the command usb_add host:xxxx:yyyy.

But, the mouse could work, the keyboard didn't, and the usb storage
device(usb 2.0) appeared in the device manager.

While the driver is OK, it couldn't start. I can only find the message
 "The device cannot start(code 10)".

I doubt there may be something wrong with the guest OS driver, which is not
said to be needed.

I am confused and don't know how to resolve it.  Could anyone help me?

Great thanks!

huqian

--047d7b339d9de8505a04ca7e23ba
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<span style=3D"color:rgb(34,34,34);font-size:14px;font-family:arial,sans-se=
rif">Hi, everyone! The same question with updated message.</span><div style=
=3D"color:rgb(34,34,34);font-size:14px;font-family:arial,sans-serif">
<br></div><div style=3D"color:rgb(34,34,34);font-size:14px;font-family:aria=
l,sans-serif">I am working on the USB passthrough of=A0Xen-4.1.2. My host O=
S =A0is Fedora 14 and the guest OS is win7.</div>
<div style=3D"color:rgb(34,34,34);font-size:14px;font-family:arial,sans-ser=
if"><br></div><div style=3D"color:rgb(34,34,34);font-size:14px;font-family:=
arial,sans-serif">
According to the wiki page(<a href=3D"http://wiki.xen.org/wiki/Xen_USB_Pass=
through" style=3D"color:rgb(17,85,204)" target=3D"_blank">http://wiki.xen.o=
rg/wiki/Xen_USB_Passthrough</a>),=A0</div><div style=3D"color:rgb(34,34,34)=
;font-size:14px;font-family:arial,sans-serif">


<br></div><div style=3D"color:rgb(34,34,34);font-size:14px;font-family:aria=
l,sans-serif">xen supports passthrough of usb device from dom0 to guests. I=
 have tried the Xen HVM guest qemu-dm usb1.1 emulation,</div>
<div style=3D"color:rgb(34,34,34);font-size:14px;font-family:arial,sans-ser=
if"><br></div><div style=3D"color:rgb(34,34,34);font-size:14px;font-family:=
arial,sans-serif">
by specifying &quot;usb =3D 1&quot; and &quot;usbdevice =3D host:xxxx:yyyy&=
quot;. I have also tried the command=A0<span style=3D"background-color:rgb(=
249,249,249);line-height:1.3em">usb_add host:xxxx:yyyy.</span></div><div st=
yle=3D"color:rgb(34,34,34);font-size:14px;font-family:arial,sans-serif">

<br></div><div style=3D"color:rgb(34,34,34);font-size:14px;font-family:aria=
l,sans-serif">But, the mouse could work, the keyboard didn&#39;t, and the u=
sb storage device(usb 2.0)<span style=3D"background-color:rgb(255,255,255)"=
>=A0appeared in the device manager.</span></div>
<div style=3D"color:rgb(34,34,34);font-size:14px;font-family:arial,sans-ser=
if"><span style=3D"background-color:rgb(255,255,255)"><br></span></div><div=
 style=3D"color:rgb(34,34,34);font-size:14px;font-family:arial,sans-serif">=
<span style=3D"background-color:rgb(255,255,255)">While the driver is OK, i=
t couldn&#39;t start.=A0</span><span style=3D"background-color:rgb(255,255,=
255)">I can only find the message =A0&quot;The device cannot start(code 10)=
&quot;.</span></div>
<div style=3D"color:rgb(34,34,34);font-size:14px;font-family:arial,sans-ser=
if"><span style=3D"background-color:rgb(255,255,255)"><br></span></div><div=
 style=3D"color:rgb(34,34,34);font-size:14px;font-family:arial,sans-serif">=
<span style=3D"background-color:rgb(255,255,255)">I doubt there may be some=
thing wrong with the guest OS driver, which is not said to be needed.</span=
></div>
<div style=3D"color:rgb(34,34,34);font-size:14px;font-family:arial,sans-ser=
if"><br></div><div style=3D"color:rgb(34,34,34);font-size:14px;font-family:=
arial,sans-serif">

I am confused and don&#39;t know how to resolve it. =A0Could anyone help me=
?</div><div style=3D"color:rgb(34,34,34);font-size:14px;font-family:arial,s=
ans-serif"><br></div><div style=3D"color:rgb(34,34,34);font-size:14px;font-=
family:arial,sans-serif">


Great thanks!</div><div style=3D"color:rgb(34,34,34);font-size:14px;font-fa=
mily:arial,sans-serif"><br></div><div style=3D"color:rgb(34,34,34);font-siz=
e:14px;font-family:arial,sans-serif">huqian</div>

--047d7b339d9de8505a04ca7e23ba--


--===============8234836942949505454==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============8234836942949505454==--


From xen-devel-bounces@lists.xen.org Tue Sep 25 03:35:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 03:35:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGLvh-0002zl-0o; Tue, 25 Sep 2012 03:35:25 +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 1TGLvg-0002zg-4n
	for xen-devel@lists.xen.org; Tue, 25 Sep 2012 03:35:24 +0000
Received: from [85.158.137.99:54430] by server-1.bemta-3.messagelabs.com id
	7F/80-05884-B7621605; Tue, 25 Sep 2012 03:35:23 +0000
X-Env-Sender: xudong.hao@intel.com
X-Msg-Ref: server-13.tower-217.messagelabs.com!1348544121!18995446!1
X-Originating-IP: [134.134.136.20]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjAgPT4gMzAyOTg2\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27796 invoked from network); 25 Sep 2012 03:35:22 -0000
Received: from mga02.intel.com (HELO mga02.intel.com) (134.134.136.20)
	by server-13.tower-217.messagelabs.com with SMTP;
	25 Sep 2012 03:35:22 -0000
Received: from orsmga001.jf.intel.com ([10.7.209.18])
	by orsmga101.jf.intel.com with ESMTP; 24 Sep 2012 20:35:15 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.80,478,1344236400"; d="scan'208";a="197250370"
Received: from xhao-dev.sh.intel.com (HELO localhost.localdomain)
	([10.239.48.48])
	by orsmga001.jf.intel.com with ESMTP; 24 Sep 2012 20:35:13 -0700
From: Xudong Hao <xudong.hao@intel.com>
To: stefano.stabellini@eu.citrix.com
Date: Tue, 25 Sep 2012 11:38:46 +0800
Message-Id: <1348544326-31334-1-git-send-email-xudong.hao@intel.com>
X-Mailer: git-send-email 1.5.5
Cc: Xudong Hao <xudong.hao@intel.com>, qemu-devel@nongnu.org,
	Xiantao Zhang <xiantao.zhang@intel.com>, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH v2] qemu/xen: Add 64 bits big bar support on qemu
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Changes from v1:
- Rebase to qemu upstream from qemu-xen

Currently it is assumed PCI device BAR access < 4G memory. If there is such a
device whose BAR size is larger than 4G, it must access > 4G memory address.
This patch enable the 64bits big BAR support on qemu.

Signed-off-by: Xudong Hao <xudong.hao@intel.com>
Signed-off-by: Xiantao Zhang <xiantao.zhang@intel.com>
---
 hw/xen_pt.c             |   16 ++++++++--------
 hw/xen_pt_config_init.c |   42 +++++++++++++++++++++++++++++-------------

diff --git a/hw/xen_pt.c b/hw/xen_pt.c
index 307119a..2a8bcf3 100644
--- a/hw/xen_pt.c
+++ b/hw/xen_pt.c
@@ -403,21 +403,21 @@ static int xen_pt_register_regions(XenPCIPassthroughState *s)
 
         s->bases[i].access.u = r->base_addr;
 
-        if (r->type & XEN_HOST_PCI_REGION_TYPE_IO) {
+        if (r->type & XEN_HOST_PCI_REGION_TYPE_IO)
             type = PCI_BASE_ADDRESS_SPACE_IO;
-        } else {
+        else if (r->type & XEN_HOST_PCI_REGION_TYPE_MEM_64)
+            type = PCI_BASE_ADDRESS_MEM_TYPE_64;
+        else if (r->type & XEN_HOST_PCI_REGION_TYPE_PREFETCH)
+            type |= PCI_BASE_ADDRESS_MEM_PREFETCH;
+        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",
+        XEN_PT_LOG(&s->dev, "IO region %i registered (size=0x%lx"PRIx64
+                   " base_addr=0x%lx"PRIx64" type: %#x)\n",
                    i, r->size, r->base_addr, type);
     }
 
diff --git a/hw/xen_pt_config_init.c b/hw/xen_pt_config_init.c
index e524a40..5e7ca22 100644
--- a/hw/xen_pt_config_init.c
+++ b/hw/xen_pt_config_init.c
@@ -342,6 +342,7 @@ static int xen_pt_cmd_reg_write(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
 #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 uint64_t xen_pt_get_bar_size(PCIIORegion *r);
 static XenPTBarFlag xen_pt_bar_reg_parse(XenPCIPassthroughState *s,
                                          XenPTRegInfo *reg)
 {
@@ -366,7 +367,7 @@ static XenPTBarFlag xen_pt_bar_reg_parse(XenPCIPassthroughState *s,
 
     /* check unused BAR */
     r = &d->io_regions[index];
-    if (r->size == 0) {
+    if (!xen_pt_get_bar_size(r)) {
         return XEN_PT_BAR_FLAG_UNUSED;
     }
 
@@ -383,6 +384,24 @@ static XenPTBarFlag xen_pt_bar_reg_parse(XenPCIPassthroughState *s,
     }
 }
 
+static bool is_64bit_bar(PCIIORegion *r)
+{
+    return !!(r->type & PCI_BASE_ADDRESS_MEM_TYPE_64);
+}
+
+static uint64_t xen_pt_get_bar_size(PCIIORegion *r)
+{
+    if (is_64bit_bar(r))
+    {
+        uint64_t size64;
+        size64 = (r + 1)->size; 
+        size64 <<= 32; 
+        size64 += r->size;
+        return size64; 
+    }
+    return r->size; 
+}
+
 static inline uint32_t base_address_with_flags(XenHostPCIIORegion *hr)
 {
     if (hr->type & XEN_HOST_PCI_REGION_TYPE_IO) {
@@ -481,7 +500,10 @@ static int xen_pt_bar_reg_write(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
     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);
+        if (!r_size)
+            bar_ro_mask = XEN_PT_BAR_ALLF;
+        else
+            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;
@@ -489,7 +511,10 @@ static int xen_pt_bar_reg_write(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
         break;
     case XEN_PT_BAR_FLAG_UPPER:
         bar_emu_mask = XEN_PT_BAR_ALLF;
-        bar_ro_mask = 0;    /* all upper 32bit are R/W */
+        if (!r_size)
+            bar_ro_mask = 0;
+        else
+            bar_ro_mask = r_size - 1;
         break;
     default:
         break;
@@ -501,22 +526,13 @@ static int xen_pt_bar_reg_write(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
 
     /* check whether we need to update the virtual region address or not */
     switch (s->bases[index].bar_flag) {
+    case XEN_PT_BAR_FLAG_UPPER:
     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;
     }
-- 
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 Sep 25 03:35:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 03:35:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGLvh-0002zl-0o; Tue, 25 Sep 2012 03:35:25 +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 1TGLvg-0002zg-4n
	for xen-devel@lists.xen.org; Tue, 25 Sep 2012 03:35:24 +0000
Received: from [85.158.137.99:54430] by server-1.bemta-3.messagelabs.com id
	7F/80-05884-B7621605; Tue, 25 Sep 2012 03:35:23 +0000
X-Env-Sender: xudong.hao@intel.com
X-Msg-Ref: server-13.tower-217.messagelabs.com!1348544121!18995446!1
X-Originating-IP: [134.134.136.20]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjAgPT4gMzAyOTg2\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27796 invoked from network); 25 Sep 2012 03:35:22 -0000
Received: from mga02.intel.com (HELO mga02.intel.com) (134.134.136.20)
	by server-13.tower-217.messagelabs.com with SMTP;
	25 Sep 2012 03:35:22 -0000
Received: from orsmga001.jf.intel.com ([10.7.209.18])
	by orsmga101.jf.intel.com with ESMTP; 24 Sep 2012 20:35:15 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.80,478,1344236400"; d="scan'208";a="197250370"
Received: from xhao-dev.sh.intel.com (HELO localhost.localdomain)
	([10.239.48.48])
	by orsmga001.jf.intel.com with ESMTP; 24 Sep 2012 20:35:13 -0700
From: Xudong Hao <xudong.hao@intel.com>
To: stefano.stabellini@eu.citrix.com
Date: Tue, 25 Sep 2012 11:38:46 +0800
Message-Id: <1348544326-31334-1-git-send-email-xudong.hao@intel.com>
X-Mailer: git-send-email 1.5.5
Cc: Xudong Hao <xudong.hao@intel.com>, qemu-devel@nongnu.org,
	Xiantao Zhang <xiantao.zhang@intel.com>, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH v2] qemu/xen: Add 64 bits big bar support on qemu
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Changes from v1:
- Rebase to qemu upstream from qemu-xen

Currently it is assumed PCI device BAR access < 4G memory. If there is such a
device whose BAR size is larger than 4G, it must access > 4G memory address.
This patch enable the 64bits big BAR support on qemu.

Signed-off-by: Xudong Hao <xudong.hao@intel.com>
Signed-off-by: Xiantao Zhang <xiantao.zhang@intel.com>
---
 hw/xen_pt.c             |   16 ++++++++--------
 hw/xen_pt_config_init.c |   42 +++++++++++++++++++++++++++++-------------

diff --git a/hw/xen_pt.c b/hw/xen_pt.c
index 307119a..2a8bcf3 100644
--- a/hw/xen_pt.c
+++ b/hw/xen_pt.c
@@ -403,21 +403,21 @@ static int xen_pt_register_regions(XenPCIPassthroughState *s)
 
         s->bases[i].access.u = r->base_addr;
 
-        if (r->type & XEN_HOST_PCI_REGION_TYPE_IO) {
+        if (r->type & XEN_HOST_PCI_REGION_TYPE_IO)
             type = PCI_BASE_ADDRESS_SPACE_IO;
-        } else {
+        else if (r->type & XEN_HOST_PCI_REGION_TYPE_MEM_64)
+            type = PCI_BASE_ADDRESS_MEM_TYPE_64;
+        else if (r->type & XEN_HOST_PCI_REGION_TYPE_PREFETCH)
+            type |= PCI_BASE_ADDRESS_MEM_PREFETCH;
+        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",
+        XEN_PT_LOG(&s->dev, "IO region %i registered (size=0x%lx"PRIx64
+                   " base_addr=0x%lx"PRIx64" type: %#x)\n",
                    i, r->size, r->base_addr, type);
     }
 
diff --git a/hw/xen_pt_config_init.c b/hw/xen_pt_config_init.c
index e524a40..5e7ca22 100644
--- a/hw/xen_pt_config_init.c
+++ b/hw/xen_pt_config_init.c
@@ -342,6 +342,7 @@ static int xen_pt_cmd_reg_write(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
 #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 uint64_t xen_pt_get_bar_size(PCIIORegion *r);
 static XenPTBarFlag xen_pt_bar_reg_parse(XenPCIPassthroughState *s,
                                          XenPTRegInfo *reg)
 {
@@ -366,7 +367,7 @@ static XenPTBarFlag xen_pt_bar_reg_parse(XenPCIPassthroughState *s,
 
     /* check unused BAR */
     r = &d->io_regions[index];
-    if (r->size == 0) {
+    if (!xen_pt_get_bar_size(r)) {
         return XEN_PT_BAR_FLAG_UNUSED;
     }
 
@@ -383,6 +384,24 @@ static XenPTBarFlag xen_pt_bar_reg_parse(XenPCIPassthroughState *s,
     }
 }
 
+static bool is_64bit_bar(PCIIORegion *r)
+{
+    return !!(r->type & PCI_BASE_ADDRESS_MEM_TYPE_64);
+}
+
+static uint64_t xen_pt_get_bar_size(PCIIORegion *r)
+{
+    if (is_64bit_bar(r))
+    {
+        uint64_t size64;
+        size64 = (r + 1)->size; 
+        size64 <<= 32; 
+        size64 += r->size;
+        return size64; 
+    }
+    return r->size; 
+}
+
 static inline uint32_t base_address_with_flags(XenHostPCIIORegion *hr)
 {
     if (hr->type & XEN_HOST_PCI_REGION_TYPE_IO) {
@@ -481,7 +500,10 @@ static int xen_pt_bar_reg_write(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
     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);
+        if (!r_size)
+            bar_ro_mask = XEN_PT_BAR_ALLF;
+        else
+            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;
@@ -489,7 +511,10 @@ static int xen_pt_bar_reg_write(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
         break;
     case XEN_PT_BAR_FLAG_UPPER:
         bar_emu_mask = XEN_PT_BAR_ALLF;
-        bar_ro_mask = 0;    /* all upper 32bit are R/W */
+        if (!r_size)
+            bar_ro_mask = 0;
+        else
+            bar_ro_mask = r_size - 1;
         break;
     default:
         break;
@@ -501,22 +526,13 @@ static int xen_pt_bar_reg_write(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
 
     /* check whether we need to update the virtual region address or not */
     switch (s->bases[index].bar_flag) {
+    case XEN_PT_BAR_FLAG_UPPER:
     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;
     }
-- 
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 Sep 25 04:57:38 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 04:57:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGNCn-0003Pi-GL; Tue, 25 Sep 2012 04:57:09 +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 1TGNCl-0003Pd-Tc
	for xen-devel@lists.xensource.com; Tue, 25 Sep 2012 04:57:08 +0000
Received: from [85.158.137.99:34617] by server-12.bemta-3.messagelabs.com id
	5E/49-10384-2A931605; Tue, 25 Sep 2012 04:57:06 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-2.tower-217.messagelabs.com!1348549025!18861603!1
X-Originating-IP: [192.55.52.93]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjkzID0+IDM0NjIyMQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29299 invoked from network); 25 Sep 2012 04:57:06 -0000
Received: from mga11.intel.com (HELO mga11.intel.com) (192.55.52.93)
	by server-2.tower-217.messagelabs.com with SMTP;
	25 Sep 2012 04:57:06 -0000
Received: from fmsmga002.fm.intel.com ([10.253.24.26])
	by fmsmga102.fm.intel.com with ESMTP; 24 Sep 2012 21:57:05 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.80,478,1344236400"; d="scan'208";a="226279629"
Received: from fmsmsx103.amr.corp.intel.com ([10.19.9.34])
	by fmsmga002.fm.intel.com with ESMTP; 24 Sep 2012 21:57:04 -0700
Received: from FMSMSX110.amr.corp.intel.com (10.19.9.29) by
	FMSMSX103.amr.corp.intel.com (10.19.9.34) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Mon, 24 Sep 2012 21:57:02 -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, 24 Sep 2012 21:57:02 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.239]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.175]) with mapi id
	14.01.0355.002; Tue, 25 Sep 2012 12:57:01 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: Christoph Egger <Christoph.Egger@amd.com>
Thread-Topic: comments for c/s 25919 Xen mce
Thread-Index: AQHNmk6Mm0PxwQPZS1qiRYz6p8f4j5eafxSQ
Date: Tue, 25 Sep 2012 04:57:00 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC8292335339530@SHSMSX101.ccr.corp.intel.com>
References: <DE8DF0795D48FD4CA783C40EC8292335332DA5@SHSMSX101.ccr.corp.intel.com>
	<505C1A79.9060100@amd.com>
	<DE8DF0795D48FD4CA783C40EC82923353384C1@SHSMSX101.ccr.corp.intel.com>
	<50604F52.9040706@amd.com>
In-Reply-To: <50604F52.9040706@amd.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"keir@xen.org" <keir@xen.org>,
	"Ian.Campbell@citrix.com" <Ian.Campbell@citrix.com>,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] comments for c/s 25919 Xen mce
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 wrote:
> On 09/24/12 12:24, Liu, Jinsong wrote:
> 
>> Christoph Egger wrote:
>>> On 09/21/12 08:44, Liu, Jinsong wrote:
>>> 
>>>> Christoph, Keir, Jan
>>>> 
>>>> I have a draft look at c/s 25919. It moves some mce_intel.c logic
>>>> to mce.c (and remove old mce.c logic). By draft reviewing the
>>>> patch I think it need more work to do, and currently it in fact
>>>> would hung at AMD platform (I have no AMD platform to test), i.e,
>>>> MACHINE_CHECK_SOFTIRQ --> mce_delayed_action() --> mce_action()
>>>> --> ASSERT(handler_num); 
>>>> 
>>>> For AMD mce it may need add (if any misunderstanding please point
>>>> to me) 1). add default handler which used at softirq context
>>> 
>>> 
>>> This is mcee_softirq().
>>> 
>>>> 2). add AMD vmce inject logic
>>> 
>>> 
>>> Yes, patch is sent.
>>> See
>>> http://lists.xen.org/archives/html/xen-devel/2012-09/msg01413.html 
>>> 
>>>> 3). more test
>>> 
>>> 
>>> There are more patches in my queue.
>>> 
>>> Christoph
>>> 
>> 
>> So, Christoph, considering you have a patches queue and would
> 
>> change more mce/vmce, how about wait a moment and then based your
>> patches on my vmce patches? My vmce patches have been posted for
>> quite some time, and have already been reviewed-rebased-tested
>> several rounds. I think they are basically stable now, currently only
>> need tools maintainers to have review patch4/5 (live migration tools
>> part).
> 
>> 
>> ... I know I have no right asking you to do so, but we need cooperate
> 
>> for mce/vmce, and if you agree I would be very much appreciated. As
>> for your mce/vmce patches, I'd like to help test at Intel's platform
>> to make sure it works fine.
> 
> I don't mind in which order the patches go upstream -
> yours first, mine first or somehow interleaved..
> 
> It is just important to me that you take my comments (to patch 2/5)
> into account to minimize the required rebase-retest effort.
> 
> Christoph

Thanks Christoph! I have add a patch injecting vmce for AMD per your comments, will sent out later.

Best Regards,
Jinsong
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 25 04:57:38 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 04:57:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGNCn-0003Pi-GL; Tue, 25 Sep 2012 04:57:09 +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 1TGNCl-0003Pd-Tc
	for xen-devel@lists.xensource.com; Tue, 25 Sep 2012 04:57:08 +0000
Received: from [85.158.137.99:34617] by server-12.bemta-3.messagelabs.com id
	5E/49-10384-2A931605; Tue, 25 Sep 2012 04:57:06 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-2.tower-217.messagelabs.com!1348549025!18861603!1
X-Originating-IP: [192.55.52.93]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjkzID0+IDM0NjIyMQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29299 invoked from network); 25 Sep 2012 04:57:06 -0000
Received: from mga11.intel.com (HELO mga11.intel.com) (192.55.52.93)
	by server-2.tower-217.messagelabs.com with SMTP;
	25 Sep 2012 04:57:06 -0000
Received: from fmsmga002.fm.intel.com ([10.253.24.26])
	by fmsmga102.fm.intel.com with ESMTP; 24 Sep 2012 21:57:05 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.80,478,1344236400"; d="scan'208";a="226279629"
Received: from fmsmsx103.amr.corp.intel.com ([10.19.9.34])
	by fmsmga002.fm.intel.com with ESMTP; 24 Sep 2012 21:57:04 -0700
Received: from FMSMSX110.amr.corp.intel.com (10.19.9.29) by
	FMSMSX103.amr.corp.intel.com (10.19.9.34) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Mon, 24 Sep 2012 21:57:02 -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, 24 Sep 2012 21:57:02 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.239]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.175]) with mapi id
	14.01.0355.002; Tue, 25 Sep 2012 12:57:01 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: Christoph Egger <Christoph.Egger@amd.com>
Thread-Topic: comments for c/s 25919 Xen mce
Thread-Index: AQHNmk6Mm0PxwQPZS1qiRYz6p8f4j5eafxSQ
Date: Tue, 25 Sep 2012 04:57:00 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC8292335339530@SHSMSX101.ccr.corp.intel.com>
References: <DE8DF0795D48FD4CA783C40EC8292335332DA5@SHSMSX101.ccr.corp.intel.com>
	<505C1A79.9060100@amd.com>
	<DE8DF0795D48FD4CA783C40EC82923353384C1@SHSMSX101.ccr.corp.intel.com>
	<50604F52.9040706@amd.com>
In-Reply-To: <50604F52.9040706@amd.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"keir@xen.org" <keir@xen.org>,
	"Ian.Campbell@citrix.com" <Ian.Campbell@citrix.com>,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] comments for c/s 25919 Xen mce
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 wrote:
> On 09/24/12 12:24, Liu, Jinsong wrote:
> 
>> Christoph Egger wrote:
>>> On 09/21/12 08:44, Liu, Jinsong wrote:
>>> 
>>>> Christoph, Keir, Jan
>>>> 
>>>> I have a draft look at c/s 25919. It moves some mce_intel.c logic
>>>> to mce.c (and remove old mce.c logic). By draft reviewing the
>>>> patch I think it need more work to do, and currently it in fact
>>>> would hung at AMD platform (I have no AMD platform to test), i.e,
>>>> MACHINE_CHECK_SOFTIRQ --> mce_delayed_action() --> mce_action()
>>>> --> ASSERT(handler_num); 
>>>> 
>>>> For AMD mce it may need add (if any misunderstanding please point
>>>> to me) 1). add default handler which used at softirq context
>>> 
>>> 
>>> This is mcee_softirq().
>>> 
>>>> 2). add AMD vmce inject logic
>>> 
>>> 
>>> Yes, patch is sent.
>>> See
>>> http://lists.xen.org/archives/html/xen-devel/2012-09/msg01413.html 
>>> 
>>>> 3). more test
>>> 
>>> 
>>> There are more patches in my queue.
>>> 
>>> Christoph
>>> 
>> 
>> So, Christoph, considering you have a patches queue and would
> 
>> change more mce/vmce, how about wait a moment and then based your
>> patches on my vmce patches? My vmce patches have been posted for
>> quite some time, and have already been reviewed-rebased-tested
>> several rounds. I think they are basically stable now, currently only
>> need tools maintainers to have review patch4/5 (live migration tools
>> part).
> 
>> 
>> ... I know I have no right asking you to do so, but we need cooperate
> 
>> for mce/vmce, and if you agree I would be very much appreciated. As
>> for your mce/vmce patches, I'd like to help test at Intel's platform
>> to make sure it works fine.
> 
> I don't mind in which order the patches go upstream -
> yours first, mine first or somehow interleaved..
> 
> It is just important to me that you take my comments (to patch 2/5)
> into account to minimize the required rebase-retest effort.
> 
> Christoph

Thanks Christoph! I have add a patch injecting vmce for AMD per your comments, will sent out later.

Best Regards,
Jinsong
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 25 05:00:54 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 05:00:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGNFy-0003jH-8y; Tue, 25 Sep 2012 05:00: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 1TGNFx-0003jA-1D
	for xen-devel@lists.xensource.com; Tue, 25 Sep 2012 05:00:25 +0000
Received: from [85.158.143.35:4917] by server-3.bemta-4.messagelabs.com id
	95/28-10986-86A31605; Tue, 25 Sep 2012 05:00:24 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1348549219!3980675!1
X-Originating-IP: [134.134.136.20]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjAgPT4gMzAyOTg2\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27121 invoked from network); 25 Sep 2012 05:00:21 -0000
Received: from mga02.intel.com (HELO mga02.intel.com) (134.134.136.20)
	by server-5.tower-21.messagelabs.com with SMTP;
	25 Sep 2012 05:00:21 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga101.jf.intel.com with ESMTP; 24 Sep 2012 22:00:15 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.80,478,1344236400"; d="scan'208";a="212417159"
Received: from fmsmsx108.amr.corp.intel.com ([10.19.9.228])
	by orsmga002.jf.intel.com with ESMTP; 24 Sep 2012 22:00:15 -0700
Received: from fmsmsx151.amr.corp.intel.com (10.19.17.220) by
	FMSMSX108.amr.corp.intel.com (10.19.9.228) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Mon, 24 Sep 2012 22:00:14 -0700
Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by
	FMSMSX151.amr.corp.intel.com (10.19.17.220) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Mon, 24 Sep 2012 22:00:14 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.239]) by
	SHSMSX102.ccr.corp.intel.com ([169.254.2.92]) with mapi id
	14.01.0355.002; Tue, 25 Sep 2012 13:00:12 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: Jan Beulich <JBeulich@suse.com>, Christoph Egger
	<Christoph.Egger@amd.com>, "xen-devel@lists.xensource.com"
	<xen-devel@lists.xensource.com>
Thread-Topic: [PATCH 6] X86/MCE: update vMCE injection for AMD
Thread-Index: Ac2a2qSXbAubMQI3SAyq+zkwzNAc0g==
Date: Tue, 25 Sep 2012 05:00:11 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC8292335339547@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_DE8DF0795D48FD4CA783C40EC8292335339547SHSMSX101ccrcorpi_"
MIME-Version: 1.0
Cc: "keir@xen.org" <keir@xen.org>,
	"Ian.Campbell@citrix.com" <Ian.Campbell@citrix.com>
Subject: [Xen-devel] [PATCH 6] X86/MCE: update vMCE injection for AMD
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--_002_DE8DF0795D48FD4CA783C40EC8292335339547SHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

X86/MCE: update vMCE injection for AMD

For Intel MCE, it broadcasts vMCE to all vcpus. For AMD MCE, it injects
vMCE only to vcpu0. This patch update inject_vmce for AMD.

Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>
Suggested_by: Christoph Egger <Christoph.Egger@amd.com>

diff -r a6d12a1bc758 xen/arch/x86/cpu/mcheck/mce.h
--- a/xen/arch/x86/cpu/mcheck/mce.h	Thu Sep 20 00:03:25 2012 +0800
+++ b/xen/arch/x86/cpu/mcheck/mce.h	Tue Sep 25 19:52:20 2012 +0800
@@ -168,7 +168,7 @@
=20
 int fill_vmsr_data(struct mcinfo_bank *mc_bank, struct domain *d,
     uint64_t gstatus);
-int inject_vmce(struct domain *d);
+int inject_vmce(struct domain *d, bool_t vmce_broadcast);
=20
 static inline int mce_vendor_bank_msr(const struct vcpu *v, uint32_t msr)
 {
diff -r a6d12a1bc758 xen/arch/x86/cpu/mcheck/mce_intel.c
--- a/xen/arch/x86/cpu/mcheck/mce_intel.c	Thu Sep 20 00:03:25 2012 +0800
+++ b/xen/arch/x86/cpu/mcheck/mce_intel.c	Tue Sep 25 19:52:20 2012 +0800
@@ -365,7 +365,7 @@
                 }
=20
                 /* We will inject vMCE to DOMU*/
-                if ( inject_vmce(d) < 0 )
+                if ( inject_vmce(d, 1) < 0 )
                 {
                     mce_printk(MCE_QUIET, "inject vMCE to DOM%d"
                       " failed\n", d->domain_id);
diff -r a6d12a1bc758 xen/arch/x86/cpu/mcheck/vmce.c
--- a/xen/arch/x86/cpu/mcheck/vmce.c	Thu Sep 20 00:03:25 2012 +0800
+++ b/xen/arch/x86/cpu/mcheck/vmce.c	Tue Sep 25 19:52:20 2012 +0800
@@ -344,11 +344,14 @@
 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)
+/*=20
+ * for Intel MCE, broadcast vMCE to all vcpus
+ * for AMD MCE, only inject vMCE to vcpu0
+ */
+int inject_vmce(struct domain *d, bool_t vmce_broadcast)
 {
     struct vcpu *v;
=20
-    /* inject vMCE to all vcpus */
     for_each_vcpu(d, v)
     {
         if ( !test_and_set_bool(v->mce_pending) &&
@@ -365,6 +368,9 @@
                        d->domain_id, v->vcpu_id);
             return -1;
         }
+
+        if ( !vmce_broadcast )
+            break;
     }
=20
     return 0;=

--_002_DE8DF0795D48FD4CA783C40EC8292335339547SHSMSX101ccrcorpi_
Content-Type: application/octet-stream; name="6_vmce_inject_for_AMD.patch"
Content-Description: 6_vmce_inject_for_AMD.patch
Content-Disposition: attachment; filename="6_vmce_inject_for_AMD.patch";
	size=2135; creation-date="Tue, 25 Sep 2012 04:04:02 GMT";
	modification-date="Tue, 25 Sep 2012 12:44:34 GMT"
Content-Transfer-Encoding: base64

WDg2L01DRTogdXBkYXRlIHZNQ0UgaW5qZWN0aW9uIGZvciBBTUQKCkZvciBJbnRlbCBNQ0UsIGl0
IGJyb2FkY2FzdHMgdk1DRSB0byBhbGwgdmNwdXMuIEZvciBBTUQgTUNFLCBpdCBpbmplY3RzCnZN
Q0Ugb25seSB0byB2Y3B1MC4gVGhpcyBwYXRjaCB1cGRhdGUgaW5qZWN0X3ZtY2UgZm9yIEFNRC4K
ClNpZ25lZC1vZmYtYnk6IExpdSwgSmluc29uZyA8amluc29uZy5saXVAaW50ZWwuY29tPgpTdWdn
ZXN0ZWRfYnk6IENocmlzdG9waCBFZ2dlciA8Q2hyaXN0b3BoLkVnZ2VyQGFtZC5jb20+CgpkaWZm
IC1yIGE2ZDEyYTFiYzc1OCB4ZW4vYXJjaC94ODYvY3B1L21jaGVjay9tY2UuaAotLS0gYS94ZW4v
YXJjaC94ODYvY3B1L21jaGVjay9tY2UuaAlUaHUgU2VwIDIwIDAwOjAzOjI1IDIwMTIgKzA4MDAK
KysrIGIveGVuL2FyY2gveDg2L2NwdS9tY2hlY2svbWNlLmgJVHVlIFNlcCAyNSAxOTo1MjoyMCAy
MDEyICswODAwCkBAIC0xNjgsNyArMTY4LDcgQEAKIAogaW50IGZpbGxfdm1zcl9kYXRhKHN0cnVj
dCBtY2luZm9fYmFuayAqbWNfYmFuaywgc3RydWN0IGRvbWFpbiAqZCwKICAgICB1aW50NjRfdCBn
c3RhdHVzKTsKLWludCBpbmplY3Rfdm1jZShzdHJ1Y3QgZG9tYWluICpkKTsKK2ludCBpbmplY3Rf
dm1jZShzdHJ1Y3QgZG9tYWluICpkLCBib29sX3Qgdm1jZV9icm9hZGNhc3QpOwogCiBzdGF0aWMg
aW5saW5lIGludCBtY2VfdmVuZG9yX2JhbmtfbXNyKGNvbnN0IHN0cnVjdCB2Y3B1ICp2LCB1aW50
MzJfdCBtc3IpCiB7CmRpZmYgLXIgYTZkMTJhMWJjNzU4IHhlbi9hcmNoL3g4Ni9jcHUvbWNoZWNr
L21jZV9pbnRlbC5jCi0tLSBhL3hlbi9hcmNoL3g4Ni9jcHUvbWNoZWNrL21jZV9pbnRlbC5jCVRo
dSBTZXAgMjAgMDA6MDM6MjUgMjAxMiArMDgwMAorKysgYi94ZW4vYXJjaC94ODYvY3B1L21jaGVj
ay9tY2VfaW50ZWwuYwlUdWUgU2VwIDI1IDE5OjUyOjIwIDIwMTIgKzA4MDAKQEAgLTM2NSw3ICsz
NjUsNyBAQAogICAgICAgICAgICAgICAgIH0KIAogICAgICAgICAgICAgICAgIC8qIFdlIHdpbGwg
aW5qZWN0IHZNQ0UgdG8gRE9NVSovCi0gICAgICAgICAgICAgICAgaWYgKCBpbmplY3Rfdm1jZShk
KSA8IDAgKQorICAgICAgICAgICAgICAgIGlmICggaW5qZWN0X3ZtY2UoZCwgMSkgPCAwICkKICAg
ICAgICAgICAgICAgICB7CiAgICAgICAgICAgICAgICAgICAgIG1jZV9wcmludGsoTUNFX1FVSUVU
LCAiaW5qZWN0IHZNQ0UgdG8gRE9NJWQiCiAgICAgICAgICAgICAgICAgICAgICAgIiBmYWlsZWRc
biIsIGQtPmRvbWFpbl9pZCk7CmRpZmYgLXIgYTZkMTJhMWJjNzU4IHhlbi9hcmNoL3g4Ni9jcHUv
bWNoZWNrL3ZtY2UuYwotLS0gYS94ZW4vYXJjaC94ODYvY3B1L21jaGVjay92bWNlLmMJVGh1IFNl
cCAyMCAwMDowMzoyNSAyMDEyICswODAwCisrKyBiL3hlbi9hcmNoL3g4Ni9jcHUvbWNoZWNrL3Zt
Y2UuYwlUdWUgU2VwIDI1IDE5OjUyOjIwIDIwMTIgKzA4MDAKQEAgLTM0NCwxMSArMzQ0LDE0IEBA
CiBIVk1fUkVHSVNURVJfU0FWRV9SRVNUT1JFKFZNQ0VfVkNQVSwgdm1jZV9zYXZlX3ZjcHVfY3R4
dCwKICAgICAgICAgICAgICAgICAgICAgICAgICAgdm1jZV9sb2FkX3ZjcHVfY3R4dCwgMSwgSFZN
U1JfUEVSX1ZDUFUpOwogCi1pbnQgaW5qZWN0X3ZtY2Uoc3RydWN0IGRvbWFpbiAqZCkKKy8qIAor
ICogZm9yIEludGVsIE1DRSwgYnJvYWRjYXN0IHZNQ0UgdG8gYWxsIHZjcHVzCisgKiBmb3IgQU1E
IE1DRSwgb25seSBpbmplY3Qgdk1DRSB0byB2Y3B1MAorICovCitpbnQgaW5qZWN0X3ZtY2Uoc3Ry
dWN0IGRvbWFpbiAqZCwgYm9vbF90IHZtY2VfYnJvYWRjYXN0KQogewogICAgIHN0cnVjdCB2Y3B1
ICp2OwogCi0gICAgLyogaW5qZWN0IHZNQ0UgdG8gYWxsIHZjcHVzICovCiAgICAgZm9yX2VhY2hf
dmNwdShkLCB2KQogICAgIHsKICAgICAgICAgaWYgKCAhdGVzdF9hbmRfc2V0X2Jvb2wodi0+bWNl
X3BlbmRpbmcpICYmCkBAIC0zNjUsNiArMzY4LDkgQEAKICAgICAgICAgICAgICAgICAgICAgICAg
ZC0+ZG9tYWluX2lkLCB2LT52Y3B1X2lkKTsKICAgICAgICAgICAgIHJldHVybiAtMTsKICAgICAg
ICAgfQorCisgICAgICAgIGlmICggIXZtY2VfYnJvYWRjYXN0ICkKKyAgICAgICAgICAgIGJyZWFr
OwogICAgIH0KIAogICAgIHJldHVybiAwOwo=

--_002_DE8DF0795D48FD4CA783C40EC8292335339547SHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 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_DE8DF0795D48FD4CA783C40EC8292335339547SHSMSX101ccrcorpi_--


From xen-devel-bounces@lists.xen.org Tue Sep 25 05:00:54 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 05:00:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGNFy-0003jH-8y; Tue, 25 Sep 2012 05:00: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 1TGNFx-0003jA-1D
	for xen-devel@lists.xensource.com; Tue, 25 Sep 2012 05:00:25 +0000
Received: from [85.158.143.35:4917] by server-3.bemta-4.messagelabs.com id
	95/28-10986-86A31605; Tue, 25 Sep 2012 05:00:24 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1348549219!3980675!1
X-Originating-IP: [134.134.136.20]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjAgPT4gMzAyOTg2\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27121 invoked from network); 25 Sep 2012 05:00:21 -0000
Received: from mga02.intel.com (HELO mga02.intel.com) (134.134.136.20)
	by server-5.tower-21.messagelabs.com with SMTP;
	25 Sep 2012 05:00:21 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga101.jf.intel.com with ESMTP; 24 Sep 2012 22:00:15 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.80,478,1344236400"; d="scan'208";a="212417159"
Received: from fmsmsx108.amr.corp.intel.com ([10.19.9.228])
	by orsmga002.jf.intel.com with ESMTP; 24 Sep 2012 22:00:15 -0700
Received: from fmsmsx151.amr.corp.intel.com (10.19.17.220) by
	FMSMSX108.amr.corp.intel.com (10.19.9.228) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Mon, 24 Sep 2012 22:00:14 -0700
Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by
	FMSMSX151.amr.corp.intel.com (10.19.17.220) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Mon, 24 Sep 2012 22:00:14 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.239]) by
	SHSMSX102.ccr.corp.intel.com ([169.254.2.92]) with mapi id
	14.01.0355.002; Tue, 25 Sep 2012 13:00:12 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: Jan Beulich <JBeulich@suse.com>, Christoph Egger
	<Christoph.Egger@amd.com>, "xen-devel@lists.xensource.com"
	<xen-devel@lists.xensource.com>
Thread-Topic: [PATCH 6] X86/MCE: update vMCE injection for AMD
Thread-Index: Ac2a2qSXbAubMQI3SAyq+zkwzNAc0g==
Date: Tue, 25 Sep 2012 05:00:11 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC8292335339547@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_DE8DF0795D48FD4CA783C40EC8292335339547SHSMSX101ccrcorpi_"
MIME-Version: 1.0
Cc: "keir@xen.org" <keir@xen.org>,
	"Ian.Campbell@citrix.com" <Ian.Campbell@citrix.com>
Subject: [Xen-devel] [PATCH 6] X86/MCE: update vMCE injection for AMD
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--_002_DE8DF0795D48FD4CA783C40EC8292335339547SHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

X86/MCE: update vMCE injection for AMD

For Intel MCE, it broadcasts vMCE to all vcpus. For AMD MCE, it injects
vMCE only to vcpu0. This patch update inject_vmce for AMD.

Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>
Suggested_by: Christoph Egger <Christoph.Egger@amd.com>

diff -r a6d12a1bc758 xen/arch/x86/cpu/mcheck/mce.h
--- a/xen/arch/x86/cpu/mcheck/mce.h	Thu Sep 20 00:03:25 2012 +0800
+++ b/xen/arch/x86/cpu/mcheck/mce.h	Tue Sep 25 19:52:20 2012 +0800
@@ -168,7 +168,7 @@
=20
 int fill_vmsr_data(struct mcinfo_bank *mc_bank, struct domain *d,
     uint64_t gstatus);
-int inject_vmce(struct domain *d);
+int inject_vmce(struct domain *d, bool_t vmce_broadcast);
=20
 static inline int mce_vendor_bank_msr(const struct vcpu *v, uint32_t msr)
 {
diff -r a6d12a1bc758 xen/arch/x86/cpu/mcheck/mce_intel.c
--- a/xen/arch/x86/cpu/mcheck/mce_intel.c	Thu Sep 20 00:03:25 2012 +0800
+++ b/xen/arch/x86/cpu/mcheck/mce_intel.c	Tue Sep 25 19:52:20 2012 +0800
@@ -365,7 +365,7 @@
                 }
=20
                 /* We will inject vMCE to DOMU*/
-                if ( inject_vmce(d) < 0 )
+                if ( inject_vmce(d, 1) < 0 )
                 {
                     mce_printk(MCE_QUIET, "inject vMCE to DOM%d"
                       " failed\n", d->domain_id);
diff -r a6d12a1bc758 xen/arch/x86/cpu/mcheck/vmce.c
--- a/xen/arch/x86/cpu/mcheck/vmce.c	Thu Sep 20 00:03:25 2012 +0800
+++ b/xen/arch/x86/cpu/mcheck/vmce.c	Tue Sep 25 19:52:20 2012 +0800
@@ -344,11 +344,14 @@
 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)
+/*=20
+ * for Intel MCE, broadcast vMCE to all vcpus
+ * for AMD MCE, only inject vMCE to vcpu0
+ */
+int inject_vmce(struct domain *d, bool_t vmce_broadcast)
 {
     struct vcpu *v;
=20
-    /* inject vMCE to all vcpus */
     for_each_vcpu(d, v)
     {
         if ( !test_and_set_bool(v->mce_pending) &&
@@ -365,6 +368,9 @@
                        d->domain_id, v->vcpu_id);
             return -1;
         }
+
+        if ( !vmce_broadcast )
+            break;
     }
=20
     return 0;=

--_002_DE8DF0795D48FD4CA783C40EC8292335339547SHSMSX101ccrcorpi_
Content-Type: application/octet-stream; name="6_vmce_inject_for_AMD.patch"
Content-Description: 6_vmce_inject_for_AMD.patch
Content-Disposition: attachment; filename="6_vmce_inject_for_AMD.patch";
	size=2135; creation-date="Tue, 25 Sep 2012 04:04:02 GMT";
	modification-date="Tue, 25 Sep 2012 12:44:34 GMT"
Content-Transfer-Encoding: base64

WDg2L01DRTogdXBkYXRlIHZNQ0UgaW5qZWN0aW9uIGZvciBBTUQKCkZvciBJbnRlbCBNQ0UsIGl0
IGJyb2FkY2FzdHMgdk1DRSB0byBhbGwgdmNwdXMuIEZvciBBTUQgTUNFLCBpdCBpbmplY3RzCnZN
Q0Ugb25seSB0byB2Y3B1MC4gVGhpcyBwYXRjaCB1cGRhdGUgaW5qZWN0X3ZtY2UgZm9yIEFNRC4K
ClNpZ25lZC1vZmYtYnk6IExpdSwgSmluc29uZyA8amluc29uZy5saXVAaW50ZWwuY29tPgpTdWdn
ZXN0ZWRfYnk6IENocmlzdG9waCBFZ2dlciA8Q2hyaXN0b3BoLkVnZ2VyQGFtZC5jb20+CgpkaWZm
IC1yIGE2ZDEyYTFiYzc1OCB4ZW4vYXJjaC94ODYvY3B1L21jaGVjay9tY2UuaAotLS0gYS94ZW4v
YXJjaC94ODYvY3B1L21jaGVjay9tY2UuaAlUaHUgU2VwIDIwIDAwOjAzOjI1IDIwMTIgKzA4MDAK
KysrIGIveGVuL2FyY2gveDg2L2NwdS9tY2hlY2svbWNlLmgJVHVlIFNlcCAyNSAxOTo1MjoyMCAy
MDEyICswODAwCkBAIC0xNjgsNyArMTY4LDcgQEAKIAogaW50IGZpbGxfdm1zcl9kYXRhKHN0cnVj
dCBtY2luZm9fYmFuayAqbWNfYmFuaywgc3RydWN0IGRvbWFpbiAqZCwKICAgICB1aW50NjRfdCBn
c3RhdHVzKTsKLWludCBpbmplY3Rfdm1jZShzdHJ1Y3QgZG9tYWluICpkKTsKK2ludCBpbmplY3Rf
dm1jZShzdHJ1Y3QgZG9tYWluICpkLCBib29sX3Qgdm1jZV9icm9hZGNhc3QpOwogCiBzdGF0aWMg
aW5saW5lIGludCBtY2VfdmVuZG9yX2JhbmtfbXNyKGNvbnN0IHN0cnVjdCB2Y3B1ICp2LCB1aW50
MzJfdCBtc3IpCiB7CmRpZmYgLXIgYTZkMTJhMWJjNzU4IHhlbi9hcmNoL3g4Ni9jcHUvbWNoZWNr
L21jZV9pbnRlbC5jCi0tLSBhL3hlbi9hcmNoL3g4Ni9jcHUvbWNoZWNrL21jZV9pbnRlbC5jCVRo
dSBTZXAgMjAgMDA6MDM6MjUgMjAxMiArMDgwMAorKysgYi94ZW4vYXJjaC94ODYvY3B1L21jaGVj
ay9tY2VfaW50ZWwuYwlUdWUgU2VwIDI1IDE5OjUyOjIwIDIwMTIgKzA4MDAKQEAgLTM2NSw3ICsz
NjUsNyBAQAogICAgICAgICAgICAgICAgIH0KIAogICAgICAgICAgICAgICAgIC8qIFdlIHdpbGwg
aW5qZWN0IHZNQ0UgdG8gRE9NVSovCi0gICAgICAgICAgICAgICAgaWYgKCBpbmplY3Rfdm1jZShk
KSA8IDAgKQorICAgICAgICAgICAgICAgIGlmICggaW5qZWN0X3ZtY2UoZCwgMSkgPCAwICkKICAg
ICAgICAgICAgICAgICB7CiAgICAgICAgICAgICAgICAgICAgIG1jZV9wcmludGsoTUNFX1FVSUVU
LCAiaW5qZWN0IHZNQ0UgdG8gRE9NJWQiCiAgICAgICAgICAgICAgICAgICAgICAgIiBmYWlsZWRc
biIsIGQtPmRvbWFpbl9pZCk7CmRpZmYgLXIgYTZkMTJhMWJjNzU4IHhlbi9hcmNoL3g4Ni9jcHUv
bWNoZWNrL3ZtY2UuYwotLS0gYS94ZW4vYXJjaC94ODYvY3B1L21jaGVjay92bWNlLmMJVGh1IFNl
cCAyMCAwMDowMzoyNSAyMDEyICswODAwCisrKyBiL3hlbi9hcmNoL3g4Ni9jcHUvbWNoZWNrL3Zt
Y2UuYwlUdWUgU2VwIDI1IDE5OjUyOjIwIDIwMTIgKzA4MDAKQEAgLTM0NCwxMSArMzQ0LDE0IEBA
CiBIVk1fUkVHSVNURVJfU0FWRV9SRVNUT1JFKFZNQ0VfVkNQVSwgdm1jZV9zYXZlX3ZjcHVfY3R4
dCwKICAgICAgICAgICAgICAgICAgICAgICAgICAgdm1jZV9sb2FkX3ZjcHVfY3R4dCwgMSwgSFZN
U1JfUEVSX1ZDUFUpOwogCi1pbnQgaW5qZWN0X3ZtY2Uoc3RydWN0IGRvbWFpbiAqZCkKKy8qIAor
ICogZm9yIEludGVsIE1DRSwgYnJvYWRjYXN0IHZNQ0UgdG8gYWxsIHZjcHVzCisgKiBmb3IgQU1E
IE1DRSwgb25seSBpbmplY3Qgdk1DRSB0byB2Y3B1MAorICovCitpbnQgaW5qZWN0X3ZtY2Uoc3Ry
dWN0IGRvbWFpbiAqZCwgYm9vbF90IHZtY2VfYnJvYWRjYXN0KQogewogICAgIHN0cnVjdCB2Y3B1
ICp2OwogCi0gICAgLyogaW5qZWN0IHZNQ0UgdG8gYWxsIHZjcHVzICovCiAgICAgZm9yX2VhY2hf
dmNwdShkLCB2KQogICAgIHsKICAgICAgICAgaWYgKCAhdGVzdF9hbmRfc2V0X2Jvb2wodi0+bWNl
X3BlbmRpbmcpICYmCkBAIC0zNjUsNiArMzY4LDkgQEAKICAgICAgICAgICAgICAgICAgICAgICAg
ZC0+ZG9tYWluX2lkLCB2LT52Y3B1X2lkKTsKICAgICAgICAgICAgIHJldHVybiAtMTsKICAgICAg
ICAgfQorCisgICAgICAgIGlmICggIXZtY2VfYnJvYWRjYXN0ICkKKyAgICAgICAgICAgIGJyZWFr
OwogICAgIH0KIAogICAgIHJldHVybiAwOwo=

--_002_DE8DF0795D48FD4CA783C40EC8292335339547SHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 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_DE8DF0795D48FD4CA783C40EC8292335339547SHSMSX101ccrcorpi_--


From xen-devel-bounces@lists.xen.org Tue Sep 25 05:21:01 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 05:21:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGNZQ-0003z5-47; Tue, 25 Sep 2012 05:20:32 +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 1TGNZO-0003z0-Nt
	for xen-devel@lists.xensource.com; Tue, 25 Sep 2012 05:20:31 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1348550423!6691200!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTA5ODg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22922 invoked from network); 25 Sep 2012 05:20:23 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Sep 2012 05:20:23 -0000
X-IronPort-AV: E=Sophos;i="4.80,479,1344211200"; d="scan'208";a="14737724"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Sep 2012 05:20: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.279.1; Tue, 25 Sep 2012 06:20:23 +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 1TGNZG-0002G9-Ta;
	Tue, 25 Sep 2012 05:20:22 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1TGNZG-0002as-HA;
	Tue, 25 Sep 2012 06:20:22 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-13863-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Tue, 25 Sep 2012 06:20:22 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13863: regressions - trouble:
	blocked/broken/fail/pass
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 13863 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13863/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-win-vcpus1    5 xen-boot                  fail REGR. vs. 13825
 build-amd64-pvops             2 host-install(2)         broken REGR. vs. 13825
 test-amd64-i386-xl-multivcpu  5 xen-boot         fail in 13837 REGR. vs. 13825
 test-amd64-i386-xl-win-vcpus1  5 xen-boot        fail in 13837 REGR. vs. 13825
 test-amd64-i386-qemuu-rhel6hvm-intel  5 xen-boot fail in 13837 REGR. vs. 13825
 test-amd64-i386-xl-win7-amd64  5 xen-boot        fail in 13837 REGR. vs. 13825
 test-amd64-amd64-win          5 xen-boot         fail in 13837 REGR. vs. 13825
 test-amd64-amd64-xl-winxpsp3  5 xen-boot         fail in 13837 REGR. vs. 13825
 test-amd64-i386-pair         8 xen-boot/dst_host fail in 13837 REGR. vs. 13825
 test-amd64-i386-pair         7 xen-boot/src_host fail in 13837 REGR. vs. 13825

Tests which are failing intermittently (not blocking):
 test-amd64-i386-rhel6hvm-intel  5 xen-boot                  fail pass in 13837
 test-amd64-i386-xl-credit2    5 xen-boot                    fail pass in 13837
 test-amd64-i386-xl-multivcpu  3 host-install(3)           broken pass in 13848
 test-amd64-i386-xl-win-vcpus1  3 host-install(3)          broken pass in 13848
 test-amd64-i386-qemuu-rhel6hvm-intel  3 host-install(3)   broken pass in 13859
 test-amd64-i386-pv            3 host-install(3)           broken pass in 13859
 test-amd64-i386-xl            3 host-install(3)           broken pass in 13848
 test-amd64-i386-xl-win7-amd64  3 host-install(3)          broken pass in 13848
 test-amd64-i386-pair          3 host-install/src_host(3)  broken pass in 13848
 test-amd64-amd64-xl-win7-amd64 12 guest-localmigrate/x10 fail in 13837 pass in 13848
 test-amd64-amd64-pv           5 xen-boot           fail in 13848 pass in 13841
 test-amd64-i386-xl-credit2    3 host-install(3)  broken in 13848 pass in 13863
 test-amd64-i386-win-vcpus1    3 host-install(3)  broken in 13848 pass in 13863

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore     fail in 13837 like 13825
 test-amd64-amd64-xl-sedf      3 host-install(3)     broken in 13837 like 13825
 test-amd64-amd64-xl-pcipt-intel  5 xen-boot      fail in 13837 REGR. vs. 13825
 test-amd64-amd64-xl-qemuu-winxpsp3 9 guest-localmigrate fail in 13837 like 13823
 test-amd64-amd64-xl-qemuu-win7-amd64 9 guest-localmigrate fail in 13837 like 13825

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf-pin  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 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-amd64-pv           1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-pcipt-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  1 xen-build-check(1)           blocked n/a
 test-amd64-amd64-win          1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 xen-build-check(1)         blocked n/a
 test-amd64-amd64-xl-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-pair         1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win      13 guest-stop            fail in 13837 never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop          fail in 13848 never pass

version targeted for testing:
 xen                  8f658b463b78
baseline version:
 xen                  d364becfb083

------------------------------------------------------------
People who touched revisions under test:
  Jan Beulich <jbeulich@suse.com>
  Keir Fraser <keir@xen.org>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            broken  
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          blocked 
 test-amd64-i386-xl                                           broken  
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemuu-win7-amd64                         blocked 
 test-amd64-amd64-xl-win7-amd64                               blocked 
 test-amd64-i386-xl-win7-amd64                                broken  
 test-amd64-i386-xl-credit2                                   fail    
 test-amd64-amd64-xl-pcipt-intel                              blocked 
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         broken  
 test-amd64-i386-xl-multivcpu                                 broken  
 test-amd64-amd64-pair                                        blocked 
 test-amd64-i386-pair                                         broken  
 test-amd64-amd64-xl-sedf-pin                                 blocked 
 test-amd64-amd64-pv                                          blocked 
 test-amd64-i386-pv                                           broken  
 test-amd64-amd64-xl-sedf                                     blocked 
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                broken  
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         blocked 
 test-amd64-i386-win                                          fail    
 test-amd64-amd64-xl-win                                      blocked 
 test-amd64-amd64-xl-qemuu-winxpsp3                           blocked 
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-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.

------------------------------------------------------------
changeset:   25938:8f658b463b78
tag:         tip
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Sep 21 17:02:46 2012 +0200
    
    x86: enable VIA CPU support
    
    Newer VIA CPUs have both 64-bit and VMX support. Enable them to be
    recognized for these purposes, at once stripping off any 32-bit CPU
    only bits from the respective CPU support file, and adding 64-bit ones
    found in recent Linux.
    
    This particularly implies untying the VMX == Intel assumption in a few
    places.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   25937:32187301ecc5
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Sep 21 15:20:21 2012 +0200
    
    x86: eliminate code affecting only 64-bit-incapable CPUs
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   25936:c8873f13cec3
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Sep 21 14:25:12 2012 +0200
    
    printk: prefer %#x et at over 0x%x
    
    Performance is not an issue with printk(), so let the function do
    minimally more work and instead save a byte per affected format
    specifier.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   25935:1e6e6b49b4ac
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Sep 21 13:47:18 2012 +0200
    
    x86: introduce MWAIT-based, ACPI-less CPU idle driver
    
    This is a port of Linux'es intel-idle driver serving the same purpose.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   25934:8eab91903e71
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Sep 21 13:45:08 2012 +0200
    
    cpuidle: remove unused latency_ticks member
    
    ... and code used only for initializing it.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   25933:d364becfb083
user:        Jan Beulich <jbeulich@suse.com>
date:        Thu Sep 20 13:31:19 2012 +0200
    
    introduce guest_handle_for_field()
    
    This helper turns a field of a GUEST_HANDLE in a GUEST_HANDLE.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    
    
(qemu changes not included)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 25 05:21:01 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 05:21:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGNZQ-0003z5-47; Tue, 25 Sep 2012 05:20:32 +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 1TGNZO-0003z0-Nt
	for xen-devel@lists.xensource.com; Tue, 25 Sep 2012 05:20:31 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1348550423!6691200!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTA5ODg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22922 invoked from network); 25 Sep 2012 05:20:23 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Sep 2012 05:20:23 -0000
X-IronPort-AV: E=Sophos;i="4.80,479,1344211200"; d="scan'208";a="14737724"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Sep 2012 05:20: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.279.1; Tue, 25 Sep 2012 06:20:23 +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 1TGNZG-0002G9-Ta;
	Tue, 25 Sep 2012 05:20:22 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1TGNZG-0002as-HA;
	Tue, 25 Sep 2012 06:20:22 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-13863-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Tue, 25 Sep 2012 06:20:22 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13863: regressions - trouble:
	blocked/broken/fail/pass
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 13863 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13863/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-win-vcpus1    5 xen-boot                  fail REGR. vs. 13825
 build-amd64-pvops             2 host-install(2)         broken REGR. vs. 13825
 test-amd64-i386-xl-multivcpu  5 xen-boot         fail in 13837 REGR. vs. 13825
 test-amd64-i386-xl-win-vcpus1  5 xen-boot        fail in 13837 REGR. vs. 13825
 test-amd64-i386-qemuu-rhel6hvm-intel  5 xen-boot fail in 13837 REGR. vs. 13825
 test-amd64-i386-xl-win7-amd64  5 xen-boot        fail in 13837 REGR. vs. 13825
 test-amd64-amd64-win          5 xen-boot         fail in 13837 REGR. vs. 13825
 test-amd64-amd64-xl-winxpsp3  5 xen-boot         fail in 13837 REGR. vs. 13825
 test-amd64-i386-pair         8 xen-boot/dst_host fail in 13837 REGR. vs. 13825
 test-amd64-i386-pair         7 xen-boot/src_host fail in 13837 REGR. vs. 13825

Tests which are failing intermittently (not blocking):
 test-amd64-i386-rhel6hvm-intel  5 xen-boot                  fail pass in 13837
 test-amd64-i386-xl-credit2    5 xen-boot                    fail pass in 13837
 test-amd64-i386-xl-multivcpu  3 host-install(3)           broken pass in 13848
 test-amd64-i386-xl-win-vcpus1  3 host-install(3)          broken pass in 13848
 test-amd64-i386-qemuu-rhel6hvm-intel  3 host-install(3)   broken pass in 13859
 test-amd64-i386-pv            3 host-install(3)           broken pass in 13859
 test-amd64-i386-xl            3 host-install(3)           broken pass in 13848
 test-amd64-i386-xl-win7-amd64  3 host-install(3)          broken pass in 13848
 test-amd64-i386-pair          3 host-install/src_host(3)  broken pass in 13848
 test-amd64-amd64-xl-win7-amd64 12 guest-localmigrate/x10 fail in 13837 pass in 13848
 test-amd64-amd64-pv           5 xen-boot           fail in 13848 pass in 13841
 test-amd64-i386-xl-credit2    3 host-install(3)  broken in 13848 pass in 13863
 test-amd64-i386-win-vcpus1    3 host-install(3)  broken in 13848 pass in 13863

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore     fail in 13837 like 13825
 test-amd64-amd64-xl-sedf      3 host-install(3)     broken in 13837 like 13825
 test-amd64-amd64-xl-pcipt-intel  5 xen-boot      fail in 13837 REGR. vs. 13825
 test-amd64-amd64-xl-qemuu-winxpsp3 9 guest-localmigrate fail in 13837 like 13823
 test-amd64-amd64-xl-qemuu-win7-amd64 9 guest-localmigrate fail in 13837 like 13825

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf-pin  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 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-amd64-pv           1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-pcipt-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  1 xen-build-check(1)           blocked n/a
 test-amd64-amd64-win          1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 xen-build-check(1)         blocked n/a
 test-amd64-amd64-xl-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-pair         1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win      13 guest-stop            fail in 13837 never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop          fail in 13848 never pass

version targeted for testing:
 xen                  8f658b463b78
baseline version:
 xen                  d364becfb083

------------------------------------------------------------
People who touched revisions under test:
  Jan Beulich <jbeulich@suse.com>
  Keir Fraser <keir@xen.org>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            broken  
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          blocked 
 test-amd64-i386-xl                                           broken  
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemuu-win7-amd64                         blocked 
 test-amd64-amd64-xl-win7-amd64                               blocked 
 test-amd64-i386-xl-win7-amd64                                broken  
 test-amd64-i386-xl-credit2                                   fail    
 test-amd64-amd64-xl-pcipt-intel                              blocked 
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         broken  
 test-amd64-i386-xl-multivcpu                                 broken  
 test-amd64-amd64-pair                                        blocked 
 test-amd64-i386-pair                                         broken  
 test-amd64-amd64-xl-sedf-pin                                 blocked 
 test-amd64-amd64-pv                                          blocked 
 test-amd64-i386-pv                                           broken  
 test-amd64-amd64-xl-sedf                                     blocked 
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                broken  
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         blocked 
 test-amd64-i386-win                                          fail    
 test-amd64-amd64-xl-win                                      blocked 
 test-amd64-amd64-xl-qemuu-winxpsp3                           blocked 
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-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.

------------------------------------------------------------
changeset:   25938:8f658b463b78
tag:         tip
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Sep 21 17:02:46 2012 +0200
    
    x86: enable VIA CPU support
    
    Newer VIA CPUs have both 64-bit and VMX support. Enable them to be
    recognized for these purposes, at once stripping off any 32-bit CPU
    only bits from the respective CPU support file, and adding 64-bit ones
    found in recent Linux.
    
    This particularly implies untying the VMX == Intel assumption in a few
    places.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   25937:32187301ecc5
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Sep 21 15:20:21 2012 +0200
    
    x86: eliminate code affecting only 64-bit-incapable CPUs
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   25936:c8873f13cec3
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Sep 21 14:25:12 2012 +0200
    
    printk: prefer %#x et at over 0x%x
    
    Performance is not an issue with printk(), so let the function do
    minimally more work and instead save a byte per affected format
    specifier.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   25935:1e6e6b49b4ac
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Sep 21 13:47:18 2012 +0200
    
    x86: introduce MWAIT-based, ACPI-less CPU idle driver
    
    This is a port of Linux'es intel-idle driver serving the same purpose.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   25934:8eab91903e71
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Sep 21 13:45:08 2012 +0200
    
    cpuidle: remove unused latency_ticks member
    
    ... and code used only for initializing it.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   25933:d364becfb083
user:        Jan Beulich <jbeulich@suse.com>
date:        Thu Sep 20 13:31:19 2012 +0200
    
    introduce guest_handle_for_field()
    
    This helper turns a field of a GUEST_HANDLE in a GUEST_HANDLE.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    
    
(qemu changes not included)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 25 05:42:28 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 05: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 1TGNuK-0004CK-2B; Tue, 25 Sep 2012 05:42:08 +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 1TGNuH-0004CF-To
	for xen-devel@lists.xen.org; Tue, 25 Sep 2012 05:42:06 +0000
Received: from [85.158.138.51:48445] by server-1.bemta-3.messagelabs.com id
	92/64-05884-D2441605; Tue, 25 Sep 2012 05:42:05 +0000
X-Env-Sender: yongjie.ren@intel.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1348551723!24230602!1
X-Originating-IP: [134.134.136.20]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjAgPT4gMzAyOTg2\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29373 invoked from network); 25 Sep 2012 05:42:04 -0000
Received: from mga02.intel.com (HELO mga02.intel.com) (134.134.136.20)
	by server-10.tower-174.messagelabs.com with SMTP;
	25 Sep 2012 05:42:04 -0000
Received: from orsmga001.jf.intel.com ([10.7.209.18])
	by orsmga101.jf.intel.com with ESMTP; 24 Sep 2012 22:42:03 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.80,479,1344236400"; d="scan'208";a="197282457"
Received: from fmsmsx107.amr.corp.intel.com ([10.19.9.54])
	by orsmga001.jf.intel.com with ESMTP; 24 Sep 2012 22:42:02 -0700
Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by
	FMSMSX107.amr.corp.intel.com (10.19.9.54) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Mon, 24 Sep 2012 22:42:01 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.239]) by
	SHSMSX102.ccr.corp.intel.com ([169.254.2.92]) with mapi id
	14.01.0355.002; Tue, 25 Sep 2012 13:42:00 +0800
From: "Ren, Yongjie" <yongjie.ren@intel.com>
To: Konrad Rzeszutek Wilk <konrad@kernel.org>, "Wu, GabrielX"
	<gabrielx.wu@intel.com>
Thread-Topic: [Xen-devel] VMX status report. Xen:25929 & Dom0:3.5.4
Thread-Index: AQHNmlhmskCmkJslRU6fxBjxl6ntCpeaiC5g
Date: Tue, 25 Sep 2012 05:41:59 +0000
Message-ID: <1B4B44D9196EFF41AE41FDA404FC0A101AD233@SHSMSX101.ccr.corp.intel.com>
References: <E4558C0C96688748837EB1B05BEED75A0FD73A8A@SHSMSX102.ccr.corp.intel.com>
	<20120924131613.GA17928@phenom.dumpdata.com>
In-Reply-To: <20120924131613.GA17928@phenom.dumpdata.com>
Accept-Language: zh-CN, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: "Liu, RongrongX" <rongrongx.liu@intel.com>, "Liu,
	SongtaoX" <songtaox.liu@intel.com>, "Zhou, Chao" <chao.zhou@intel.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] VMX status report. Xen:25929 & Dom0:3.5.4
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> -----Original Message-----
> From: Konrad Rzeszutek [mailto:ketuzsezr@gmail.com] On Behalf Of
> Konrad Rzeszutek Wilk
> Sent: Monday, September 24, 2012 9:16 PM
> To: Wu, GabrielX
> Cc: xen-devel@lists.xen.org; Ren, Yongjie; Liu, RongrongX; Liu, SongtaoX;
> Zhou, Chao
> Subject: Re: [Xen-devel] VMX status report. Xen:25929 & Dom0:3.5.4
> 
> > 6. Poor performance when do guest save/restore and migration with
> linux 3.1 dom0
> >   http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1784
> 
> Added some questions in the bug.


Output of "perf stat xl migrate 1 localhost" for localhost migration.

      87086.962947 task-clock                #    0.964 CPUs utilized
           132,882 context-switches          #    0.002 M/sec 
            10,252 CPU-migrations            #    0.000 M/sec 
            18,159 page-faults               #    0.000 M/sec 
     <not counted> cycles                  
     <not counted> stalled-cycles-frontend 
     <not counted> stalled-cycles-backend  
     <not counted> instructions            
     <not counted> branches                
     <not counted> branch-misses           

      90.299519242 seconds time elapsed

BTW, do you know why the last 6 counter didn't have data?
Only met this issue when running 'perf stat' command in Dom0.

The following is the output of "perf record -e cpu-clock xl migrate 1 localhost" command.

[ perf record: Woken up 10 times to write data ]
[ perf record: Captured and wrote 3.321 MB perf.data (~145093 samples) ]
# Events: 86K cpu-clock
#
# Overhead          Command          Shared Object                            Symbol
# ........  ...............  .....................  ................................
#
    32.08%  libxl-save-help  [kernel.kallsyms]      [k] hypercall_page
    27.42%              ssh  libcrypto.so.1.0.0     [.] 0x7a6ba         
    14.73%  libxl-save-help  [kernel.kallsyms]      [k] smp_call_function_many
     4.51%              ssh  libcrypto.so.1.0.0     [.] md5_block_asm_data_order
     4.19%              ssh  ssh                    [.] 0x28af6         
     1.83%              ssh  [kernel.kallsyms]      [k] hypercall_page
     1.44%              ssh  libcrypto.so.1.0.0     [.] AES_encrypt
     1.32%  libxl-save-help  [kernel.kallsyms]      [k] find_next_bit
     0.81%  libxl-save-help  [kernel.kallsyms]      [k] xen_send_IPI_one
     0.78%  libxl-save-help  [kernel.kallsyms]      [k] pvclock_clocksource_read
     0.71%  libxl-save-help  [kernel.kallsyms]      [k] unmap_single_vma
     0.66%              ssh  [kernel.kallsyms]      [k] copy_user_generic_string
     0.51%  libxl-save-help  [kernel.kallsyms]      [k] xen_vcpu_stolen
     (didn't include other more lines.)
Also, added update in the bugzilla.


> > 7. vcpu-set doesn't take effect on guest
> >   http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1822
> > 8.Fail to probe NIC driver in domu
> >   http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1824
> > 9. Dom0 cannot be shutdown before PCI device detachment from guest
> >   http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1826
> 
> The same - added some questions that I believe I asked on the mailing
> list last time.
my fault. I'll reply to the email thread you asked me the question.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 25 05:42:28 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 05: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 1TGNuK-0004CK-2B; Tue, 25 Sep 2012 05:42:08 +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 1TGNuH-0004CF-To
	for xen-devel@lists.xen.org; Tue, 25 Sep 2012 05:42:06 +0000
Received: from [85.158.138.51:48445] by server-1.bemta-3.messagelabs.com id
	92/64-05884-D2441605; Tue, 25 Sep 2012 05:42:05 +0000
X-Env-Sender: yongjie.ren@intel.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1348551723!24230602!1
X-Originating-IP: [134.134.136.20]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjAgPT4gMzAyOTg2\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29373 invoked from network); 25 Sep 2012 05:42:04 -0000
Received: from mga02.intel.com (HELO mga02.intel.com) (134.134.136.20)
	by server-10.tower-174.messagelabs.com with SMTP;
	25 Sep 2012 05:42:04 -0000
Received: from orsmga001.jf.intel.com ([10.7.209.18])
	by orsmga101.jf.intel.com with ESMTP; 24 Sep 2012 22:42:03 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.80,479,1344236400"; d="scan'208";a="197282457"
Received: from fmsmsx107.amr.corp.intel.com ([10.19.9.54])
	by orsmga001.jf.intel.com with ESMTP; 24 Sep 2012 22:42:02 -0700
Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by
	FMSMSX107.amr.corp.intel.com (10.19.9.54) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Mon, 24 Sep 2012 22:42:01 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.239]) by
	SHSMSX102.ccr.corp.intel.com ([169.254.2.92]) with mapi id
	14.01.0355.002; Tue, 25 Sep 2012 13:42:00 +0800
From: "Ren, Yongjie" <yongjie.ren@intel.com>
To: Konrad Rzeszutek Wilk <konrad@kernel.org>, "Wu, GabrielX"
	<gabrielx.wu@intel.com>
Thread-Topic: [Xen-devel] VMX status report. Xen:25929 & Dom0:3.5.4
Thread-Index: AQHNmlhmskCmkJslRU6fxBjxl6ntCpeaiC5g
Date: Tue, 25 Sep 2012 05:41:59 +0000
Message-ID: <1B4B44D9196EFF41AE41FDA404FC0A101AD233@SHSMSX101.ccr.corp.intel.com>
References: <E4558C0C96688748837EB1B05BEED75A0FD73A8A@SHSMSX102.ccr.corp.intel.com>
	<20120924131613.GA17928@phenom.dumpdata.com>
In-Reply-To: <20120924131613.GA17928@phenom.dumpdata.com>
Accept-Language: zh-CN, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: "Liu, RongrongX" <rongrongx.liu@intel.com>, "Liu,
	SongtaoX" <songtaox.liu@intel.com>, "Zhou, Chao" <chao.zhou@intel.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] VMX status report. Xen:25929 & Dom0:3.5.4
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> -----Original Message-----
> From: Konrad Rzeszutek [mailto:ketuzsezr@gmail.com] On Behalf Of
> Konrad Rzeszutek Wilk
> Sent: Monday, September 24, 2012 9:16 PM
> To: Wu, GabrielX
> Cc: xen-devel@lists.xen.org; Ren, Yongjie; Liu, RongrongX; Liu, SongtaoX;
> Zhou, Chao
> Subject: Re: [Xen-devel] VMX status report. Xen:25929 & Dom0:3.5.4
> 
> > 6. Poor performance when do guest save/restore and migration with
> linux 3.1 dom0
> >   http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1784
> 
> Added some questions in the bug.


Output of "perf stat xl migrate 1 localhost" for localhost migration.

      87086.962947 task-clock                #    0.964 CPUs utilized
           132,882 context-switches          #    0.002 M/sec 
            10,252 CPU-migrations            #    0.000 M/sec 
            18,159 page-faults               #    0.000 M/sec 
     <not counted> cycles                  
     <not counted> stalled-cycles-frontend 
     <not counted> stalled-cycles-backend  
     <not counted> instructions            
     <not counted> branches                
     <not counted> branch-misses           

      90.299519242 seconds time elapsed

BTW, do you know why the last 6 counter didn't have data?
Only met this issue when running 'perf stat' command in Dom0.

The following is the output of "perf record -e cpu-clock xl migrate 1 localhost" command.

[ perf record: Woken up 10 times to write data ]
[ perf record: Captured and wrote 3.321 MB perf.data (~145093 samples) ]
# Events: 86K cpu-clock
#
# Overhead          Command          Shared Object                            Symbol
# ........  ...............  .....................  ................................
#
    32.08%  libxl-save-help  [kernel.kallsyms]      [k] hypercall_page
    27.42%              ssh  libcrypto.so.1.0.0     [.] 0x7a6ba         
    14.73%  libxl-save-help  [kernel.kallsyms]      [k] smp_call_function_many
     4.51%              ssh  libcrypto.so.1.0.0     [.] md5_block_asm_data_order
     4.19%              ssh  ssh                    [.] 0x28af6         
     1.83%              ssh  [kernel.kallsyms]      [k] hypercall_page
     1.44%              ssh  libcrypto.so.1.0.0     [.] AES_encrypt
     1.32%  libxl-save-help  [kernel.kallsyms]      [k] find_next_bit
     0.81%  libxl-save-help  [kernel.kallsyms]      [k] xen_send_IPI_one
     0.78%  libxl-save-help  [kernel.kallsyms]      [k] pvclock_clocksource_read
     0.71%  libxl-save-help  [kernel.kallsyms]      [k] unmap_single_vma
     0.66%              ssh  [kernel.kallsyms]      [k] copy_user_generic_string
     0.51%  libxl-save-help  [kernel.kallsyms]      [k] xen_vcpu_stolen
     (didn't include other more lines.)
Also, added update in the bugzilla.


> > 7. vcpu-set doesn't take effect on guest
> >   http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1822
> > 8.Fail to probe NIC driver in domu
> >   http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1824
> > 9. Dom0 cannot be shutdown before PCI device detachment from guest
> >   http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1826
> 
> The same - added some questions that I believe I asked on the mailing
> list last time.
my fault. I'll reply to the email thread you asked me the question.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 25 05:58:22 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 05:58:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGO9e-0004MG-Iv; Tue, 25 Sep 2012 05:57:58 +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 1TGO9c-0004MB-JP
	for xen-devel@lists.xen.org; Tue, 25 Sep 2012 05:57:57 +0000
Received: from [85.158.137.99:13971] by server-15.bemta-3.messagelabs.com id
	F2/8D-09665-3E741605; Tue, 25 Sep 2012 05:57:55 +0000
X-Env-Sender: yongjie.ren@intel.com
X-Msg-Ref: server-7.tower-217.messagelabs.com!1348552673!14192274!1
X-Originating-IP: [143.182.124.37]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMzcgPT4gMjA4MTcy\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25029 invoked from network); 25 Sep 2012 05:57:54 -0000
Received: from mga14.intel.com (HELO mga14.intel.com) (143.182.124.37)
	by server-7.tower-217.messagelabs.com with SMTP;
	25 Sep 2012 05:57:54 -0000
Received: from azsmga001.ch.intel.com ([10.2.17.19])
	by azsmga102.ch.intel.com with ESMTP; 24 Sep 2012 22:57:52 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.80,479,1344236400"; d="scan'208";a="196691854"
Received: from fmsmsx105.amr.corp.intel.com ([10.19.9.36])
	by azsmga001.ch.intel.com with ESMTP; 24 Sep 2012 22:57:51 -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; Mon, 24 Sep 2012 22:57:51 -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, 24 Sep 2012 22:57:50 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.239]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.175]) with mapi id
	14.01.0355.002; Tue, 25 Sep 2012 13:57:49 +0800
From: "Ren, Yongjie" <yongjie.ren@intel.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Thread-Topic: [Xen-devel] Xen4.2-rc3 test result
Thread-Index: Ac2HShtAedsoaH/XR0eHCAg2EulTuAAEEXiAASd316D//8o/AP/+bs1AgANRQ4D/47bpsA==
Date: Tue, 25 Sep 2012 05:57:48 +0000
Message-ID: <1B4B44D9196EFF41AE41FDA404FC0A101AD25E@SHSMSX101.ccr.corp.intel.com>
References: <1B4B44D9196EFF41AE41FDA404FC0A1018AF31@SHSMSX101.ccr.corp.intel.com>
	<20120831172410.GA19756@localhost.localdomain>
	<1B4B44D9196EFF41AE41FDA404FC0A10190E9D@SHSMSX101.ccr.corp.intel.com>
	<20120906111158.GF3668@phenom.dumpdata.com>
	<1B4B44D9196EFF41AE41FDA404FC0A10194823@SHSMSX101.ccr.corp.intel.com>
	<20120907135539.GI2870@phenom.dumpdata.com>
In-Reply-To: <20120907135539.GI2870@phenom.dumpdata.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: Konrad Rzeszutek Wilk <konrad@kernel.org>, 'Keir Fraser' <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] Xen4.2-rc3 test result
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> -----Original Message-----
> From: Konrad Rzeszutek Wilk [mailto:konrad.wilk@oracle.com]
> Sent: Friday, September 07, 2012 9:56 PM
> To: Ren, Yongjie
> Cc: Konrad Rzeszutek Wilk; 'xen-devel'; 'Keir Fraser'; 'Ian Campbell'; 'Jan
> Beulich'
> Subject: Re: [Xen-devel] Xen4.2-rc3 test result
> 
> On Fri, Sep 07, 2012 at 08:01:37AM +0000, Ren, Yongjie wrote:
> > > -----Original Message-----
> > > From: Konrad Rzeszutek Wilk [mailto:konrad.wilk@oracle.com]
> > > Sent: Thursday, September 06, 2012 7:12 PM
> > > To: Ren, Yongjie
> > > Cc: Konrad Rzeszutek Wilk; 'xen-devel'; 'Keir Fraser'; 'Ian Campbell';
> 'Jan
> > > Beulich'
> > > Subject: Re: [Xen-devel] Xen4.2-rc3 test result
> > >
> > > On Thu, Sep 06, 2012 at 08:18:16AM +0000, Ren, Yongjie wrote:
> > > > > -----Original Message-----
> > > > > From: Konrad Rzeszutek [mailto:ketuzsezr@gmail.com] On Behalf
> Of
> > > > > Konrad Rzeszutek Wilk
> > > > > Sent: Saturday, September 01, 2012 1:24 AM
> > > > > To: Ren, Yongjie
> > > > > Cc: 'xen-devel'; 'Keir Fraser'; 'Ian Campbell'; 'Jan Beulich'; 'Konrad
> > > > > Rzeszutek Wilk'
> > > > > Subject: Re: [Xen-devel] Xen4.2-rc3 test result
> > > >
> > > > > > 5. Dom0 cannot be shutdown before PCI detachment from guest
> and
> > > > > when pci assignment conflicts
> > > > > >   http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1826
> > > > >
> > > > > Um, so you are assigning the same VF to two guests. I am surprised
> > > that
> > > > > the tools even allowed you to do that. Was 'xm' allowing you to do
> > > that?
> > > > >
> > > > No, 'xl' doesn't allow me to do that. We can't assignment a device to
> > > different guests.
> > > > Sorry, the description of this bug is not accurate. I changed its title to
> > > "Dom0 cannot be shut down before PCI device detachment from a
> guest".
> > > > If a guest (with a PCI device assigned) is running, Dom0 will panic
> when
> > > shutting down.
> > >
> > > And does it panic if you use the 'irqpoll' option it asks for?
> > >
> > Adding 'irqpoll' makes no change.
> >
> > It should be a regression for Xen from 4.1 to 4.2.
> > I didn't meet this issue with 4.1 Xen and 3.5.3 Dom0.
> 
> Aaah. That was not clear from the bugzilla.
> 
> >
> > > Xen-pciback has no involvment as:
> > >
> > >
> > > [  283.747488] xenbus_dev_shutdown: backend/pci/1/0: Initialised !=
> > > Connected, skipping
> > >
> > > and the guest still keeps on getting interrupts.
> > >
> > > What is the stack at the hang?
> > >
> > [  283.747488] xenbus_dev_shutdown: backend/pci/1/0: Initialised !=
> Connected,
> > skipping
> > [  283.747505] xenbus_dev_shutdown: backend/vkbd/2/0: Initialising !=
> > Connected, skipping
> > [  283.747515] xenbus_dev_shutdown: backend/console/2/0:
> Initialising !=
> > Connected, skipping
> > [  380.236571] irq 16: nobody cared (try booting with the "irqpoll"
> option)
> > [  380.236588] Pid: 0, comm: swapper/0 Not tainted 3.4.4 #1
> > [  380.236596] Call Trace:
> > [  380.236601]  <IRQ>  [<ffffffff8110b538>]
> __report_bad_irq+0x38/0xd0
> > [  380.236626]  [<ffffffff8110b72c>] note_interrupt+0x15c/0x210
> > [  380.236637]  [<ffffffff81108ffa>]
> handle_irq_event_percpu+0xca/0x230
> > [  380.236648]  [<ffffffff811091b6>] handle_irq_event+0x56/0x90
> > [  380.236658]  [<ffffffff8110bde3>] handle_fasteoi_irq+0x63/0x120
> > [  380.236671]  [<ffffffff8131c8f1>]
> __xen_evtchn_do_upcall+0x1b1/0x280
> > [  380.236703]  [<ffffffff8131d51a>] xen_evtchn_do_upcall+0x2a/0x40
> > [  380.236716]  [<ffffffff816bc36e>]
> xen_do_hypervisor_callback+0x1e/0x30
> > [  380.236723]  <EOI>  [<ffffffff810013aa>] ?
> hypercall_page+0x3aa/0x1000
> > [  380.236742]  [<ffffffff810013aa>] ? hypercall_page+0x3aa/0x1000
> > [  380.236754]  [<ffffffff810538d0>] ? xen_safe_halt+0x10/0x20
> > [  380.236768]  [<ffffffff81067c9a>] ? default_idle+0x6a/0x1d0
> > [  380.236778]  [<ffffffff81067256>] ? cpu_idle+0x96/0xf0
> > [  380.236789]  [<ffffffff81689a18>] ? rest_init+0x68/0x70
> > [  380.236800]  [<ffffffff81ca9e33>] ? start_kernel+0x407/0x414
> > [  380.236810]  [<ffffffff81ca984a>] ? kernel_init+0x1e1/0x1e1
> > [  380.236821]  [<ffffffff81ca9346>] ?
> x86_64_start_reservations+0x131/0x136
> > [  380.236833]  [<ffffffff81cade7a>] ? xen_start_kernel+0x621/0x628
> > [  380.236841] handlers:
> > [  380.236850] [<ffffffff81428d80>] usb_hcd_irq
> > [  380.236860] Disabling IRQ #16
> 
> That is not the hang stack. That is the kernel telling you that something
> has gone astray with an interrupt. But its unclear what happend _after_
> that.
> 
> It might be that the system called the proper shutdown hypercall and its
> waiting for the hypervisor to do its stuff. Can you try using the 'q' to get
> a stack dump of the dom0 and see where its spinning/sitting please?
> 
(XEN) 'q' pressed -> dumping domain info (now=0x43F:E9B06F08)
(XEN) General information for domain 0:
(XEN)     refcnt=3 dying=0 pause_count=0
(XEN)     nr_pages=1048576 xenheap_pages=6 shared_pages=0 paged_pages=0 dirty_cpus={1-24,26-30} max_pages=4294967295
(XEN)     handle=00000000-0000-0000-0000-000000000000 vm_assist=0000000d
(XEN) Rangesets belonging to domain 0:
(XEN)     I/O Ports  { 0-1f, 22-3f, 44-60, 62-9f, a2-3f7, 400-407, 40c-cfb, d00-ffff }
(XEN)     Interrupts { 0-315, 317-327 }
(XEN)     I/O Memory { 0-febff, fec01-fec3e, fec40-fec7e, fec80-fedff, fee01-ffffffffffffffff }
(XEN) Memory pages belonging to domain 0:
(XEN)     DomPage list too long to display
(XEN)     XenPage 000000000043c8ad: caf=c000000000000002, taf=7400000000000002
(XEN)     XenPage 000000000043c8ac: caf=c000000000000001, taf=7400000000000001
(XEN)     XenPage 000000000043c8ab: caf=c000000000000001, taf=7400000000000001
(XEN)     XenPage 000000000043c8aa: caf=c000000000000001, taf=7400000000000001
(XEN)     XenPage 00000000000bb48e: caf=c000000000000002, taf=7400000000000002
(XEN)     XenPage 0000000000418d84: caf=c000000000000002, taf=7400000000000002
(XEN) VCPU information and callbacks for domain 0:
(XEN)     VCPU0: CPU14 [has=F] poll=0 upcall_pend = 00, upcall_mask = 00 dirty_cpus={14} cpu_affinity={0-127}
(XEN)     pause_count=0 pause_flags=1
(XEN)     No periodic timer
(XEN)     VCPU1: CPU18 [has=F] poll=0 upcall_pend = 00, upcall_mask = 00 dirty_cpus={18} cpu_affinity={0-127}
(XEN)     pause_count=0 pause_flags=1
(XEN)     No periodic timer
(XEN)     VCPU2: CPU15 [has=F] poll=0 upcall_pend = 00, upcall_mask = 00 dirty_cpus={15} cpu_affinity={0-127}
(XEN)     pause_count=0 pause_flags=1
(XEN)     No periodic timer
(XEN)     VCPU3: CPU24 [has=F] poll=0 upcall_pend = 00, upcall_mask = 00 dirty_cpus={24} cpu_affinity={0-127}
(XEN)     pause_count=0 pause_flags=1
(XEN)     No periodic timer
(XEN)     VCPU4: CPU27 [has=F] poll=0 upcall_pend = 00, upcall_mask = 00 dirty_cpus={27} cpu_affinity={0-127}
(XEN)     pause_count=0 pause_flags=1
(XEN)     No periodic timer
(XEN)     VCPU5: CPU30 [has=F] poll=0 upcall_pend = 00, upcall_mask = 00 dirty_cpus={30} cpu_affinity={0-127}
(XEN)     pause_count=0 pause_flags=1
(XEN)     No periodic timer
(XEN)     VCPU6: CPU24 [has=F] poll=0 upcall_pend = 00, upcall_mask = 00 dirty_cpus={} cpu_affinity={0-127}
(XEN)     pause_count=0 pause_flags=1
(XEN)     No periodic timer
(XEN)     VCPU7: CPU11 [has=F] poll=0 upcall_pend = 00, upcall_mask = 00 dirty_cpus={11} cpu_affinity={0-127}
(XEN)     pause_count=0 pause_flags=1
(XEN)     No periodic timer
(XEN)     VCPU8: CPU19 [has=F] poll=0 upcall_pend = 00, upcall_mask = 00 dirty_cpus={19} cpu_affinity={0-127}
(XEN)     pause_count=0 pause_flags=1
(XEN)     No periodic timer
(XEN)     VCPU9: CPU23 [has=F] poll=0 upcall_pend = 00, upcall_mask = 00 dirty_cpus={} cpu_affinity={0-127}
(XEN)     pause_count=0 pause_flags=1
(XEN)     No periodic timer
(XEN)     VCPU10: CPU28 [has=F] poll=0 upcall_pend = 00, upcall_mask = 00 dirty_cpus={28} cpu_affinity={0-127}
(XEN)     pause_count=0 pause_flags=1
(XEN)     No periodic timer
(XEN)     VCPU11: CPU29 [has=F] poll=0 upcall_pend = 00, upcall_mask = 00 dirty_cpus={29} cpu_affinity={0-127}
(XEN)     pause_count=0 pause_flags=1
(XEN)     No periodic timer
(XEN)     VCPU12: CPU10 [has=F] poll=0 upcall_pend = 00, upcall_mask = 00 dirty_cpus={10} cpu_affinity={0-127}
(XEN)     pause_count=0 pause_flags=1
(XEN)     No periodic timer
(XEN)     VCPU13: CPU17 [has=F] poll=0 upcall_pend = 00, upcall_mask = 00 dirty_cpus={17} cpu_affinity={0-127}
(XEN)     pause_count=0 pause_flags=1
(XEN)     No periodic timer
(XEN)     VCPU14: CPU8 [has=F] poll=0 upcall_pend = 00, upcall_mask = 00 dirty_cpus={8} cpu_affinity={0-127}
(XEN)     pause_count=0 pause_flags=1
(XEN)     No periodic timer
(XEN)     VCPU15: CPU22 [has=F] poll=0 upcall_pend = 00, upcall_mask = 00 dirty_cpus={22} cpu_affinity={0-127}
(XEN)     pause_count=0 pause_flags=1
(XEN)     No periodic timer
(XEN)     VCPU16: CPU7 [has=F] poll=0 upcall_pend = 00, upcall_mask = 00 dirty_cpus={7} cpu_affinity={0-127}
(XEN)     pause_count=0 pause_flags=1
(XEN)     No periodic timer
(XEN)     VCPU17: CPU16 [has=F] poll=0 upcall_pend = 00, upcall_mask = 00 dirty_cpus={16} cpu_affinity={0-127}
(XEN)     pause_count=0 pause_flags=1
(XEN)     No periodic timer
(XEN)     VCPU18: CPU26 [has=F] poll=0 upcall_pend = 00, upcall_mask = 00 dirty_cpus={26} cpu_affinity={0-127}
(XEN)     pause_count=0 pause_flags=1
(XEN)     No periodic timer
(XEN)     VCPU19: CPU13 [has=F] poll=0 upcall_pend = 00, upcall_mask = 00 dirty_cpus={13} cpu_affinity={0-127}
(XEN)     pause_count=0 pause_flags=1
(XEN)     No periodic timer
(XEN)     VCPU20: CPU3 [has=F] poll=0 upcall_pend = 00, upcall_mask = 00 dirty_cpus={3} cpu_affinity={0-127}
(XEN)     pause_count=0 pause_flags=1
(XEN)     No periodic timer
(XEN)     VCPU21: CPU12 [has=F] poll=0 upcall_pend = 00, upcall_mask = 00 dirty_cpus={12} cpu_affinity={0-127}
(XEN)     pause_count=0 pause_flags=1
(XEN)     No periodic timer
(XEN)     VCPU22: CPU0 [has=F] poll=0 upcall_pend = 00, upcall_mask = 00 dirty_cpus={} cpu_affinity={0-127}
(XEN)     pause_count=0 pause_flags=1
(XEN)     No periodic timer
(XEN)     VCPU23: CPU23 [has=F] poll=0 upcall_pend = 00, upcall_mask = 00 dirty_cpus={23} cpu_affinity={0-127}
(XEN)     pause_count=0 pause_flags=1
(XEN)     No periodic timer
(XEN)     VCPU24: CPU20 [has=F] poll=0 upcall_pend = 00, upcall_mask = 00 dirty_cpus={20} cpu_affinity={0-127}
(XEN)     pause_count=0 pause_flags=1
(XEN)     No periodic timer
(XEN)     VCPU25: CPU2 [has=F] poll=0 upcall_pend = 00, upcall_mask = 00 dirty_cpus={2} cpu_affinity={0-127}
(XEN)     pause_count=0 pause_flags=1
(XEN)     No periodic timer
(XEN)     VCPU26: CPU1 [has=F] poll=0 upcall_pend = 00, upcall_mask = 00 dirty_cpus={1} cpu_affinity={0-127}
(XEN)     pause_count=0 pause_flags=1
(XEN)     No periodic timer
(XEN)     VCPU27: CPU9 [has=F] poll=0 upcall_pend = 00, upcall_mask = 00 dirty_cpus={9} cpu_affinity={0-127}
(XEN)     pause_count=0 pause_flags=1
(XEN)     No periodic timer
(XEN)     VCPU28: CPU5 [has=F] poll=0 upcall_pend = 00, upcall_mask = 00 dirty_cpus={5} cpu_affinity={0-127}
(XEN)     pause_count=0 pause_flags=1
(XEN)     No periodic timer
(XEN)     VCPU29: CPU4 [has=F] poll=0 upcall_pend = 00, upcall_mask = 00 dirty_cpus={4} cpu_affinity={0-127}
(XEN)     pause_count=0 pause_flags=1
(XEN)     No periodic timer
(XEN)     VCPU30: CPU21 [has=F] poll=0 upcall_pend = 00, upcall_mask = 00 dirty_cpus={21} cpu_affinity={0-127}
(XEN)     pause_count=0 pause_flags=1
(XEN)     No periodic timer
(XEN)     VCPU31: CPU6 [has=F] poll=0 upcall_pend = 00, upcall_mask = 00 dirty_cpus={6} cpu_affinity={0-127}
(XEN)     pause_count=0 pause_flags=1
(XEN)     No periodic timer
(XEN) General information for domain 1:
(XEN)     refcnt=3 dying=0 pause_count=0
(XEN)     nr_pages=1047549 xenheap_pages=6 shared_pages=0 paged_pages=0 dirty_cpus={} max_pages=1048832
(XEN)     handle=dd1ee134-05ef-4a65-a2fe-163bce610687 vm_assist=00000000
(XEN)     paging assistance: hap refcounts translate external 
(XEN) Rangesets belonging to domain 1:
(XEN)     I/O Ports  { }
(XEN)     Interrupts { 101-103 }
(XEN)     I/O Memory { ebb41-ebb43, ebb60-ebb63 }
(XEN) Memory pages belonging to domain 1:
(XEN)     DomPage list too long to display
(XEN)     PoD entries=0 cachesize=0
(XEN)     XenPage 000000000044000e: caf=c000000000000001, taf=7400000000000001
(XEN)     XenPage 000000000044000d: caf=c000000000000001, taf=7400000000000001
(XEN)     XenPage 000000000044000c: caf=c000000000000001, taf=7400000000000001
(XEN)     XenPage 00000000004a04f7: caf=c000000000000001, taf=7400000000000001
(XEN)     XenPage 00000000000bd4f8: caf=c000000000000001, taf=7400000000000001
(XEN)     XenPage 00000000004a0400: caf=c000000000000001, taf=7400000000000001
(XEN) VCPU information and callbacks for domain 1:
(XEN)     VCPU0: CPU1 [has=F] poll=0 upcall_pend = 01, upcall_mask = 00 dirty_cpus={} cpu_affinity={0-15}
(XEN)     pause_count=0 pause_flags=4
(XEN)     paging assistance: hap, 4 levels
(XEN)     No periodic timer
(XEN)     VCPU1: CPU10 [has=F] poll=0 upcall_pend = 00, upcall_mask = 00 dirty_cpus={} cpu_affinity={0-15}
(XEN)     pause_count=0 pause_flags=2
(XEN)     paging assistance: hap, 1 levels
(XEN)     No periodic timer
(XEN)     VCPU2: CPU11 [has=F] poll=0 upcall_pend = 00, upcall_mask = 00 dirty_cpus={} cpu_affinity={0-15}
(XEN)     pause_count=0 pause_flags=2
(XEN)     paging assistance: hap, 1 levels
(XEN)     No periodic timer
(XEN)     VCPU3: CPU12 [has=F] poll=0 upcall_pend = 00, upcall_mask = 00 dirty_cpus={} cpu_affinity={0-15}
(XEN)     pause_count=0 pause_flags=2
(XEN)     paging assistance: hap, 1 levels
(XEN)     No periodic timer
(XEN)     VCPU4: CPU13 [has=F] poll=0 upcall_pend = 00, upcall_mask = 00 dirty_cpus={} cpu_affinity={0-15}
(XEN)     pause_count=0 pause_flags=2
(XEN)     paging assistance: hap, 1 levels
(XEN)     No periodic timer
(XEN)     VCPU5: CPU14 [has=F] poll=0 upcall_pend = 00, upcall_mask = 00 dirty_cpus={} cpu_affinity={0-15}
(XEN)     pause_count=0 pause_flags=2
(XEN)     paging assistance: hap, 1 levels
(XEN)     No periodic timer
(XEN)     VCPU6: CPU15 [has=F] poll=0 upcall_pend = 00, upcall_mask = 00 dirty_cpus={} cpu_affinity={0-15}
(XEN)     pause_count=0 pause_flags=2
(XEN)     paging assistance: hap, 1 levels
(XEN)     No periodic timer
(XEN)     VCPU7: CPU0 [has=F] poll=0 upcall_pend = 00, upcall_mask = 00 dirty_cpus={} cpu_affinity={0-15}
(XEN)     pause_count=0 pause_flags=2
(XEN)     paging assistance: hap, 1 levels
(XEN)     No periodic timer
(XEN)     VCPU8: CPU0 [has=F] poll=0 upcall_pend = 00, upcall_mask = 00 dirty_cpus={} cpu_affinity={0-15}
(XEN)     pause_count=0 pause_flags=2
(XEN)     paging assistance: hap, 1 levels
(XEN)     No periodic timer
(XEN)     VCPU9: CPU0 [has=F] poll=0 upcall_pend = 00, upcall_mask = 00 dirty_cpus={} cpu_affinity={0-15}
(XEN)     pause_count=0 pause_flags=2
(XEN)     paging assistance: hap, 1 levels
(XEN)     No periodic timer
(XEN)     VCPU10: CPU0 [has=F] poll=0 upcall_pend = 00, upcall_mask = 00 dirty_cpus={} cpu_affinity={0-15}
(XEN)     pause_count=0 pause_flags=2
(XEN)     paging assistance: hap, 1 levels
(XEN)     No periodic timer
(XEN)     VCPU11: CPU0 [has=F] poll=0 upcall_pend = 00, upcall_mask = 00 dirty_cpus={} cpu_affinity={0-15}
(XEN)     pause_count=0 pause_flags=2
(XEN)     paging assistance: hap, 1 levels
(XEN)     No periodic timer
(XEN)     VCPU12: CPU0 [has=F] poll=0 upcall_pend = 00, upcall_mask = 00 dirty_cpus={} cpu_affinity={0-15}
(XEN)     pause_count=0 pause_flags=2
(XEN)     paging assistance: hap, 1 levels
(XEN)     No periodic timer
(XEN)     VCPU13: CPU0 [has=F] poll=0 upcall_pend = 00, upcall_mask = 00 dirty_cpus={} cpu_affinity={0-15}
(XEN)     pause_count=0 pause_flags=2
(XEN)     paging assistance: hap, 1 levels
(XEN)     No periodic timer
(XEN)     VCPU14: CPU0 [has=F] poll=0 upcall_pend = 00, upcall_mask = 00 dirty_cpus={} cpu_affinity={0-15}
(XEN)     pause_count=0 pause_flags=2
(XEN)     paging assistance: hap, 1 levels
(XEN)     No periodic timer
(XEN)     VCPU15: CPU0 [has=F] poll=0 upcall_pend = 00, upcall_mask = 00 dirty_cpus={} cpu_affinity={0-15}
(XEN)     pause_count=0 pause_flags=2
(XEN)     paging assistance: hap, 1 levels
(XEN)     No periodic timer
(XEN) General information for domain 2:
(XEN)     refcnt=3 dying=0 pause_count=0
(XEN)     nr_pages=523261 xenheap_pages=6 shared_pages=0 paged_pages=0 dirty_cpus={31} max_pages=524544
(XEN)     handle=b10a1595-a5b0-46e2-a67a-3c77c4755761 vm_assist=00000000
(XEN)     paging assistance: hap refcounts translate external 
(XEN) Rangesets belonging to domain 2:
(XEN)     I/O Ports  { }
(XEN)     Interrupts { }
(XEN)     I/O Memory { }
(XEN) Memory pages belonging to domain 2:
(XEN)     DomPage list too long to display
(XEN)     PoD entries=0 cachesize=0
(XEN)     XenPage 00000000004b44f3: caf=c000000000000001, taf=7400000000000001
(XEN)     XenPage 00000000004b44f2: caf=c000000000000001, taf=7400000000000001
(XEN)     XenPage 00000000004b44f1: caf=c000000000000001, taf=7400000000000001
(XEN)     XenPage 00000000004b44f0: caf=c000000000000001, taf=7400000000000001
(XEN)     XenPage 00000000000bb08f: caf=c000000000000001, taf=7400000000000001
(XEN)     XenPage 00000000004b27a7: caf=c000000000000001, taf=7400000000000001
(XEN) VCPU information and callbacks for domain 2:
(XEN)     VCPU0: CPU31 [has=T] poll=0 upcall_pend = 00, upcall_mask = 00 dirty_cpus={31} cpu_affinity={16-31}
(XEN)     pause_count=0 pause_flags=0
(XEN)     paging assistance: hap, 4 levels
(XEN)     No periodic timer
(XEN)     VCPU1: CPU16 [has=F] poll=0 upcall_pend = 00, upcall_mask = 00 dirty_cpus={} cpu_affinity={16-31}
(XEN)     pause_count=0 pause_flags=4
(XEN)     paging assistance: hap, 4 levels
(XEN)     No periodic timer
(XEN)     VCPU2: CPU18 [has=F] poll=0 upcall_pend = 00, upcall_mask = 00 dirty_cpus={} cpu_affinity={16-31}
(XEN)     pause_count=0 pause_flags=2
(XEN)     paging assistance: hap, 1 levels
(XEN)     No periodic timer
(XEN)     VCPU3: CPU19 [has=F] poll=0 upcall_pend = 00, upcall_mask = 00 dirty_cpus={} cpu_affinity={16-31}
(XEN)     pause_count=0 pause_flags=2
(XEN)     paging assistance: hap, 1 levels
(XEN)     No periodic timer
(XEN)     VCPU4: CPU18 [has=F] poll=0 upcall_pend = 00, upcall_mask = 00 dirty_cpus={} cpu_affinity={16-31}
(XEN)     pause_count=0 pause_flags=2
(XEN)     paging assistance: hap, 1 levels
(XEN)     No periodic timer
(XEN)     VCPU5: CPU19 [has=F] poll=0 upcall_pend = 00, upcall_mask = 00 dirty_cpus={} cpu_affinity={16-31}
(XEN)     pause_count=0 pause_flags=2
(XEN)     paging assistance: hap, 1 levels
(XEN)     No periodic timer
(XEN)     VCPU6: CPU18 [has=F] poll=0 upcall_pend = 00, upcall_mask = 00 dirty_cpus={} cpu_affinity={16-31}
(XEN)     pause_count=0 pause_flags=2
(XEN)     paging assistance: hap, 1 levels
(XEN)     No periodic timer
(XEN)     VCPU7: CPU19 [has=F] poll=0 upcall_pend = 00, upcall_mask = 00 dirty_cpus={} cpu_affinity={16-31}
(XEN)     pause_count=0 pause_flags=2
(XEN)     paging assistance: hap, 1 levels
(XEN)     No periodic timer
(XEN)     VCPU8: CPU18 [has=F] poll=0 upcall_pend = 00, upcall_mask = 00 dirty_cpus={} cpu_affinity={16-31}
(XEN)     pause_count=0 pause_flags=2
(XEN)     paging assistance: hap, 1 levels
(XEN)     No periodic timer
(XEN)     VCPU9: CPU16 [has=F] poll=0 upcall_pend = 00, upcall_mask = 00 dirty_cpus={} cpu_affinity={16-31}
(XEN)     pause_count=0 pause_flags=2
(XEN)     paging assistance: hap, 1 levels
(XEN)     No periodic timer
(XEN)     VCPU10: CPU17 [has=F] poll=0 upcall_pend = 00, upcall_mask = 00 dirty_cpus={} cpu_affinity={16-31}
(XEN)     pause_count=0 pause_flags=2
(XEN)     paging assistance: hap, 1 levels
(XEN)     No periodic timer
(XEN)     VCPU11: CPU18 [has=F] poll=0 upcall_pend = 00, upcall_mask = 00 dirty_cpus={} cpu_affinity={16-31}
(XEN)     pause_count=0 pause_flags=2
(XEN)     paging assistance: hap, 1 levels
(XEN)     No periodic timer
(XEN)     VCPU12: CPU19 [has=F] poll=0 upcall_pend = 00, upcall_mask = 00 dirty_cpus={} cpu_affinity={16-31}
(XEN)     pause_count=0 pause_flags=2
(XEN)     paging assistance: hap, 1 levels
(XEN)     No periodic timer
(XEN)     VCPU13: CPU20 [has=F] poll=0 upcall_pend = 00, upcall_mask = 00 dirty_cpus={} cpu_affinity={16-31}
(XEN)     pause_count=0 pause_flags=2
(XEN)     paging assistance: hap, 1 levels
(XEN)     No periodic timer
(XEN)     VCPU14: CPU21 [has=F] poll=0 upcall_pend = 00, upcall_mask = 00 dirty_cpus={} cpu_affinity={16-31}
(XEN)     pause_count=0 pause_flags=2
(XEN)     paging assistance: hap, 1 levels
(XEN)     No periodic timer
(XEN)     VCPU15: CPU22 [has=F] poll=0 upcall_pend = 00, upcall_mask = 00 dirty_cpus={} cpu_affinity={16-31}
(XEN)     pause_count=0 pause_flags=2
(XEN)     paging assistance: hap, 1 levels
(XEN)     No periodic timer
(XEN) Notifying guest 0:0 (virq 1, port 5, stat 0/0/0)
(XEN) Notifying guest 0:1 (virq 1, port 12, stat 0/0/0)
[ 4672.954495] (XEN) Notifying guest 0:2 (virq 1, port 19, stat 0/0/0)

vcpu 0
  (XEN) Notifying guest 0:3 (virq 1, port 26, stat 0/0/0)
0: masked=0 pend(XEN) Notifying guest 0:4 (virq 1, port 33, stat 0/0/0)
ing=0 event_sel (XEN) Notifying guest 0:5 (virq 1, port 40, stat 0/0/0)
0000000000000000(XEN) Notifying guest 0:6 (virq 1, port 47, stat 0/0/0)

  (XEN) Notifying guest 0:7 (virq 1, port 54, stat 0/0/0)
1: masked=1 pend(XEN) Notifying guest 0:8 (virq 1, port 61, stat 0/0/0)
ing=0 event_sel (XEN) Notifying guest 0:9 (virq 1, port 68, stat 0/0/0)
0000000000000000(XEN) Notifying guest 0:10 (virq 1, port 75, stat 0/0/0)

  (XEN) Notifying guest 0:11 (virq 1, port 82, stat 0/0/0)
2: masked=1 pend(XEN) Notifying guest 0:12 (virq 1, port 89, stat 0/0/0)
ing=0 event_sel (XEN) Notifying guest 0:13 (virq 1, port 96, stat 0/0/0)
0000000000000000(XEN) Notifying guest 0:14 (virq 1, port 103, stat 0/0/0)

  (XEN) Notifying guest 0:15 (virq 1, port 110, stat 0/0/0)
3: masked=1 pend(XEN) Notifying guest 0:16 (virq 1, port 117, stat 0/0/0)
ing=0 event_sel (XEN) Notifying guest 0:17 (virq 1, port 124, stat 0/0/0)
0000000000000000(XEN) Notifying guest 0:18 (virq 1, port 131, stat 0/0/0)

  (XEN) Notifying guest 0:19 (virq 1, port 138, stat 0/0/0)
4: masked=1 pend(XEN) Notifying guest 0:20 (virq 1, port 145, stat 0/0/0)
ing=0 event_sel (XEN) Notifying guest 0:21 (virq 1, port 152, stat 0/0/0)
0000000000000000(XEN) Notifying guest 0:22 (virq 1, port 159, stat 0/0/0)

  (XEN) Notifying guest 0:23 (virq 1, port 166, stat 0/0/0)
5: masked=1 pend(XEN) Notifying guest 0:24 (virq 1, port 173, stat 0/0/0)
ing=0 event_sel (XEN) Notifying guest 0:25 (virq 1, port 180, stat 0/0/0)
0000000000000000(XEN) Notifying guest 0:26 (virq 1, port 187, stat 0/0/0)

  (XEN) Notifying guest 0:27 (virq 1, port 194, stat 0/0/0)
6: masked=1 pend(XEN) Notifying guest 0:28 (virq 1, port 201, stat 0/0/0)
ing=0 event_sel (XEN) Notifying guest 0:29 (virq 1, port 208, stat 0/0/0)
0000000000000000(XEN) Notifying guest 0:30 (virq 1, port 215, stat 0/0/0)

  (XEN) Notifying guest 0:31 (virq 1, port 222, stat 0/0/0)
7: masked=1 pend(XEN) Notifying guest 1:0 (virq 1, port 0, stat 0/-1/-1)
ing=0 event_sel (XEN) Notifying guest 1:1 (virq 1, port 0, stat 0/-1/0)
0000000000000000(XEN) Notifying guest 1:2 (virq 1, port 0, stat 0/-1/0)

  (XEN) Notifying guest 1:3 (virq 1, port 0, stat 0/-1/0)
8: masked=1 pend(XEN) Notifying guest 1:4 (virq 1, port 0, stat 0/-1/0)
ing=0 event_sel (XEN) Notifying guest 1:5 (virq 1, port 0, stat 0/-1/0)
0000000000000000(XEN) Notifying guest 1:6 (virq 1, port 0, stat 0/-1/0)

  (XEN) Notifying guest 1:7 (virq 1, port 0, stat 0/-1/0)
9: masked=1 pend(XEN) Notifying guest 1:8 (virq 1, port 0, stat 0/-1/0)
ing=1 event_sel (XEN) Notifying guest 1:9 (virq 1, port 0, stat 0/-1/0)
0000000000000002(XEN) Notifying guest 1:10 (virq 1, port 0, stat 0/-1/0)

  (XEN) Notifying guest 1:11 (virq 1, port 0, stat 0/-1/0)
10: masked=1 pen(XEN) Notifying guest 1:12 (virq 1, port 0, stat 0/-1/0)
ding=0 event_sel(XEN) Notifying guest 1:13 (virq 1, port 0, stat 0/-1/0)
 000000000000000(XEN) Notifying guest 1:14 (virq 1, port 0, stat 0/-1/0)
0
  (XEN) Notifying guest 1:15 (virq 1, port 0, stat 0/-1/0)
11: masked=1 pen(XEN) Notifying guest 2:0 (virq 1, port 0, stat 0/-1/0)
ding=0 event_sel(XEN) Notifying guest 2:1 (virq 1, port 0, stat 0/-1/0)
 000000000000000(XEN) Notifying guest 2:2 (virq 1, port 0, stat 0/-1/0)
0
  (XEN) Notifying guest 2:3 (virq 1, port 0, stat 0/-1/0)
12: masked=1 pen(XEN) Notifying guest 2:4 (virq 1, port 0, stat 0/-1/0)
ding=0 event_sel(XEN) Notifying guest 2:5 (virq 1, port 0, stat 0/-1/0)
 000000000000000(XEN) Notifying guest 2:6 (virq 1, port 0, stat 0/-1/0)
0
  (XEN) Notifying guest 2:7 (virq 1, port 0, stat 0/-1/0)
13: masked=1 pen(XEN) Notifying guest 2:8 (virq 1, port 0, stat 0/-1/0)
ding=0 event_sel(XEN) Notifying guest 2:9 (virq 1, port 0, stat 0/-1/0)
 000000000000000(XEN) Notifying guest 2:10 (virq 1, port 0, stat 0/-1/0)
0
  (XEN) Notifying guest 2:11 (virq 1, port 0, stat 0/-1/0)
14: masked=1 pen(XEN) Notifying guest 2:12 (virq 1, port 0, stat 0/-1/0)
ding=0 event_sel(XEN) Notifying guest 2:13 (virq 1, port 0, stat 0/-1/0)
 000000000000000(XEN) Notifying guest 2:14 (virq 1, port 0, stat 0/-1/0)
0
  (XEN) Notifying guest 2:15 (virq 1, port 0, stat 0/-1/0)
15: masked=1 pen(XEN) Shared frames 0 -- Saved frames 0
ding=(XEN) *** Serial input -> DOM0 (type 'CTRL-a' three times to switch input to Xen)


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 25 05:58:22 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 05:58:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGO9e-0004MG-Iv; Tue, 25 Sep 2012 05:57:58 +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 1TGO9c-0004MB-JP
	for xen-devel@lists.xen.org; Tue, 25 Sep 2012 05:57:57 +0000
Received: from [85.158.137.99:13971] by server-15.bemta-3.messagelabs.com id
	F2/8D-09665-3E741605; Tue, 25 Sep 2012 05:57:55 +0000
X-Env-Sender: yongjie.ren@intel.com
X-Msg-Ref: server-7.tower-217.messagelabs.com!1348552673!14192274!1
X-Originating-IP: [143.182.124.37]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMzcgPT4gMjA4MTcy\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25029 invoked from network); 25 Sep 2012 05:57:54 -0000
Received: from mga14.intel.com (HELO mga14.intel.com) (143.182.124.37)
	by server-7.tower-217.messagelabs.com with SMTP;
	25 Sep 2012 05:57:54 -0000
Received: from azsmga001.ch.intel.com ([10.2.17.19])
	by azsmga102.ch.intel.com with ESMTP; 24 Sep 2012 22:57:52 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.80,479,1344236400"; d="scan'208";a="196691854"
Received: from fmsmsx105.amr.corp.intel.com ([10.19.9.36])
	by azsmga001.ch.intel.com with ESMTP; 24 Sep 2012 22:57:51 -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; Mon, 24 Sep 2012 22:57:51 -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, 24 Sep 2012 22:57:50 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.239]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.175]) with mapi id
	14.01.0355.002; Tue, 25 Sep 2012 13:57:49 +0800
From: "Ren, Yongjie" <yongjie.ren@intel.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Thread-Topic: [Xen-devel] Xen4.2-rc3 test result
Thread-Index: Ac2HShtAedsoaH/XR0eHCAg2EulTuAAEEXiAASd316D//8o/AP/+bs1AgANRQ4D/47bpsA==
Date: Tue, 25 Sep 2012 05:57:48 +0000
Message-ID: <1B4B44D9196EFF41AE41FDA404FC0A101AD25E@SHSMSX101.ccr.corp.intel.com>
References: <1B4B44D9196EFF41AE41FDA404FC0A1018AF31@SHSMSX101.ccr.corp.intel.com>
	<20120831172410.GA19756@localhost.localdomain>
	<1B4B44D9196EFF41AE41FDA404FC0A10190E9D@SHSMSX101.ccr.corp.intel.com>
	<20120906111158.GF3668@phenom.dumpdata.com>
	<1B4B44D9196EFF41AE41FDA404FC0A10194823@SHSMSX101.ccr.corp.intel.com>
	<20120907135539.GI2870@phenom.dumpdata.com>
In-Reply-To: <20120907135539.GI2870@phenom.dumpdata.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: Konrad Rzeszutek Wilk <konrad@kernel.org>, 'Keir Fraser' <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] Xen4.2-rc3 test result
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> -----Original Message-----
> From: Konrad Rzeszutek Wilk [mailto:konrad.wilk@oracle.com]
> Sent: Friday, September 07, 2012 9:56 PM
> To: Ren, Yongjie
> Cc: Konrad Rzeszutek Wilk; 'xen-devel'; 'Keir Fraser'; 'Ian Campbell'; 'Jan
> Beulich'
> Subject: Re: [Xen-devel] Xen4.2-rc3 test result
> 
> On Fri, Sep 07, 2012 at 08:01:37AM +0000, Ren, Yongjie wrote:
> > > -----Original Message-----
> > > From: Konrad Rzeszutek Wilk [mailto:konrad.wilk@oracle.com]
> > > Sent: Thursday, September 06, 2012 7:12 PM
> > > To: Ren, Yongjie
> > > Cc: Konrad Rzeszutek Wilk; 'xen-devel'; 'Keir Fraser'; 'Ian Campbell';
> 'Jan
> > > Beulich'
> > > Subject: Re: [Xen-devel] Xen4.2-rc3 test result
> > >
> > > On Thu, Sep 06, 2012 at 08:18:16AM +0000, Ren, Yongjie wrote:
> > > > > -----Original Message-----
> > > > > From: Konrad Rzeszutek [mailto:ketuzsezr@gmail.com] On Behalf
> Of
> > > > > Konrad Rzeszutek Wilk
> > > > > Sent: Saturday, September 01, 2012 1:24 AM
> > > > > To: Ren, Yongjie
> > > > > Cc: 'xen-devel'; 'Keir Fraser'; 'Ian Campbell'; 'Jan Beulich'; 'Konrad
> > > > > Rzeszutek Wilk'
> > > > > Subject: Re: [Xen-devel] Xen4.2-rc3 test result
> > > >
> > > > > > 5. Dom0 cannot be shutdown before PCI detachment from guest
> and
> > > > > when pci assignment conflicts
> > > > > >   http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1826
> > > > >
> > > > > Um, so you are assigning the same VF to two guests. I am surprised
> > > that
> > > > > the tools even allowed you to do that. Was 'xm' allowing you to do
> > > that?
> > > > >
> > > > No, 'xl' doesn't allow me to do that. We can't assignment a device to
> > > different guests.
> > > > Sorry, the description of this bug is not accurate. I changed its title to
> > > "Dom0 cannot be shut down before PCI device detachment from a
> guest".
> > > > If a guest (with a PCI device assigned) is running, Dom0 will panic
> when
> > > shutting down.
> > >
> > > And does it panic if you use the 'irqpoll' option it asks for?
> > >
> > Adding 'irqpoll' makes no change.
> >
> > It should be a regression for Xen from 4.1 to 4.2.
> > I didn't meet this issue with 4.1 Xen and 3.5.3 Dom0.
> 
> Aaah. That was not clear from the bugzilla.
> 
> >
> > > Xen-pciback has no involvment as:
> > >
> > >
> > > [  283.747488] xenbus_dev_shutdown: backend/pci/1/0: Initialised !=
> > > Connected, skipping
> > >
> > > and the guest still keeps on getting interrupts.
> > >
> > > What is the stack at the hang?
> > >
> > [  283.747488] xenbus_dev_shutdown: backend/pci/1/0: Initialised !=
> Connected,
> > skipping
> > [  283.747505] xenbus_dev_shutdown: backend/vkbd/2/0: Initialising !=
> > Connected, skipping
> > [  283.747515] xenbus_dev_shutdown: backend/console/2/0:
> Initialising !=
> > Connected, skipping
> > [  380.236571] irq 16: nobody cared (try booting with the "irqpoll"
> option)
> > [  380.236588] Pid: 0, comm: swapper/0 Not tainted 3.4.4 #1
> > [  380.236596] Call Trace:
> > [  380.236601]  <IRQ>  [<ffffffff8110b538>]
> __report_bad_irq+0x38/0xd0
> > [  380.236626]  [<ffffffff8110b72c>] note_interrupt+0x15c/0x210
> > [  380.236637]  [<ffffffff81108ffa>]
> handle_irq_event_percpu+0xca/0x230
> > [  380.236648]  [<ffffffff811091b6>] handle_irq_event+0x56/0x90
> > [  380.236658]  [<ffffffff8110bde3>] handle_fasteoi_irq+0x63/0x120
> > [  380.236671]  [<ffffffff8131c8f1>]
> __xen_evtchn_do_upcall+0x1b1/0x280
> > [  380.236703]  [<ffffffff8131d51a>] xen_evtchn_do_upcall+0x2a/0x40
> > [  380.236716]  [<ffffffff816bc36e>]
> xen_do_hypervisor_callback+0x1e/0x30
> > [  380.236723]  <EOI>  [<ffffffff810013aa>] ?
> hypercall_page+0x3aa/0x1000
> > [  380.236742]  [<ffffffff810013aa>] ? hypercall_page+0x3aa/0x1000
> > [  380.236754]  [<ffffffff810538d0>] ? xen_safe_halt+0x10/0x20
> > [  380.236768]  [<ffffffff81067c9a>] ? default_idle+0x6a/0x1d0
> > [  380.236778]  [<ffffffff81067256>] ? cpu_idle+0x96/0xf0
> > [  380.236789]  [<ffffffff81689a18>] ? rest_init+0x68/0x70
> > [  380.236800]  [<ffffffff81ca9e33>] ? start_kernel+0x407/0x414
> > [  380.236810]  [<ffffffff81ca984a>] ? kernel_init+0x1e1/0x1e1
> > [  380.236821]  [<ffffffff81ca9346>] ?
> x86_64_start_reservations+0x131/0x136
> > [  380.236833]  [<ffffffff81cade7a>] ? xen_start_kernel+0x621/0x628
> > [  380.236841] handlers:
> > [  380.236850] [<ffffffff81428d80>] usb_hcd_irq
> > [  380.236860] Disabling IRQ #16
> 
> That is not the hang stack. That is the kernel telling you that something
> has gone astray with an interrupt. But its unclear what happend _after_
> that.
> 
> It might be that the system called the proper shutdown hypercall and its
> waiting for the hypervisor to do its stuff. Can you try using the 'q' to get
> a stack dump of the dom0 and see where its spinning/sitting please?
> 
(XEN) 'q' pressed -> dumping domain info (now=0x43F:E9B06F08)
(XEN) General information for domain 0:
(XEN)     refcnt=3 dying=0 pause_count=0
(XEN)     nr_pages=1048576 xenheap_pages=6 shared_pages=0 paged_pages=0 dirty_cpus={1-24,26-30} max_pages=4294967295
(XEN)     handle=00000000-0000-0000-0000-000000000000 vm_assist=0000000d
(XEN) Rangesets belonging to domain 0:
(XEN)     I/O Ports  { 0-1f, 22-3f, 44-60, 62-9f, a2-3f7, 400-407, 40c-cfb, d00-ffff }
(XEN)     Interrupts { 0-315, 317-327 }
(XEN)     I/O Memory { 0-febff, fec01-fec3e, fec40-fec7e, fec80-fedff, fee01-ffffffffffffffff }
(XEN) Memory pages belonging to domain 0:
(XEN)     DomPage list too long to display
(XEN)     XenPage 000000000043c8ad: caf=c000000000000002, taf=7400000000000002
(XEN)     XenPage 000000000043c8ac: caf=c000000000000001, taf=7400000000000001
(XEN)     XenPage 000000000043c8ab: caf=c000000000000001, taf=7400000000000001
(XEN)     XenPage 000000000043c8aa: caf=c000000000000001, taf=7400000000000001
(XEN)     XenPage 00000000000bb48e: caf=c000000000000002, taf=7400000000000002
(XEN)     XenPage 0000000000418d84: caf=c000000000000002, taf=7400000000000002
(XEN) VCPU information and callbacks for domain 0:
(XEN)     VCPU0: CPU14 [has=F] poll=0 upcall_pend = 00, upcall_mask = 00 dirty_cpus={14} cpu_affinity={0-127}
(XEN)     pause_count=0 pause_flags=1
(XEN)     No periodic timer
(XEN)     VCPU1: CPU18 [has=F] poll=0 upcall_pend = 00, upcall_mask = 00 dirty_cpus={18} cpu_affinity={0-127}
(XEN)     pause_count=0 pause_flags=1
(XEN)     No periodic timer
(XEN)     VCPU2: CPU15 [has=F] poll=0 upcall_pend = 00, upcall_mask = 00 dirty_cpus={15} cpu_affinity={0-127}
(XEN)     pause_count=0 pause_flags=1
(XEN)     No periodic timer
(XEN)     VCPU3: CPU24 [has=F] poll=0 upcall_pend = 00, upcall_mask = 00 dirty_cpus={24} cpu_affinity={0-127}
(XEN)     pause_count=0 pause_flags=1
(XEN)     No periodic timer
(XEN)     VCPU4: CPU27 [has=F] poll=0 upcall_pend = 00, upcall_mask = 00 dirty_cpus={27} cpu_affinity={0-127}
(XEN)     pause_count=0 pause_flags=1
(XEN)     No periodic timer
(XEN)     VCPU5: CPU30 [has=F] poll=0 upcall_pend = 00, upcall_mask = 00 dirty_cpus={30} cpu_affinity={0-127}
(XEN)     pause_count=0 pause_flags=1
(XEN)     No periodic timer
(XEN)     VCPU6: CPU24 [has=F] poll=0 upcall_pend = 00, upcall_mask = 00 dirty_cpus={} cpu_affinity={0-127}
(XEN)     pause_count=0 pause_flags=1
(XEN)     No periodic timer
(XEN)     VCPU7: CPU11 [has=F] poll=0 upcall_pend = 00, upcall_mask = 00 dirty_cpus={11} cpu_affinity={0-127}
(XEN)     pause_count=0 pause_flags=1
(XEN)     No periodic timer
(XEN)     VCPU8: CPU19 [has=F] poll=0 upcall_pend = 00, upcall_mask = 00 dirty_cpus={19} cpu_affinity={0-127}
(XEN)     pause_count=0 pause_flags=1
(XEN)     No periodic timer
(XEN)     VCPU9: CPU23 [has=F] poll=0 upcall_pend = 00, upcall_mask = 00 dirty_cpus={} cpu_affinity={0-127}
(XEN)     pause_count=0 pause_flags=1
(XEN)     No periodic timer
(XEN)     VCPU10: CPU28 [has=F] poll=0 upcall_pend = 00, upcall_mask = 00 dirty_cpus={28} cpu_affinity={0-127}
(XEN)     pause_count=0 pause_flags=1
(XEN)     No periodic timer
(XEN)     VCPU11: CPU29 [has=F] poll=0 upcall_pend = 00, upcall_mask = 00 dirty_cpus={29} cpu_affinity={0-127}
(XEN)     pause_count=0 pause_flags=1
(XEN)     No periodic timer
(XEN)     VCPU12: CPU10 [has=F] poll=0 upcall_pend = 00, upcall_mask = 00 dirty_cpus={10} cpu_affinity={0-127}
(XEN)     pause_count=0 pause_flags=1
(XEN)     No periodic timer
(XEN)     VCPU13: CPU17 [has=F] poll=0 upcall_pend = 00, upcall_mask = 00 dirty_cpus={17} cpu_affinity={0-127}
(XEN)     pause_count=0 pause_flags=1
(XEN)     No periodic timer
(XEN)     VCPU14: CPU8 [has=F] poll=0 upcall_pend = 00, upcall_mask = 00 dirty_cpus={8} cpu_affinity={0-127}
(XEN)     pause_count=0 pause_flags=1
(XEN)     No periodic timer
(XEN)     VCPU15: CPU22 [has=F] poll=0 upcall_pend = 00, upcall_mask = 00 dirty_cpus={22} cpu_affinity={0-127}
(XEN)     pause_count=0 pause_flags=1
(XEN)     No periodic timer
(XEN)     VCPU16: CPU7 [has=F] poll=0 upcall_pend = 00, upcall_mask = 00 dirty_cpus={7} cpu_affinity={0-127}
(XEN)     pause_count=0 pause_flags=1
(XEN)     No periodic timer
(XEN)     VCPU17: CPU16 [has=F] poll=0 upcall_pend = 00, upcall_mask = 00 dirty_cpus={16} cpu_affinity={0-127}
(XEN)     pause_count=0 pause_flags=1
(XEN)     No periodic timer
(XEN)     VCPU18: CPU26 [has=F] poll=0 upcall_pend = 00, upcall_mask = 00 dirty_cpus={26} cpu_affinity={0-127}
(XEN)     pause_count=0 pause_flags=1
(XEN)     No periodic timer
(XEN)     VCPU19: CPU13 [has=F] poll=0 upcall_pend = 00, upcall_mask = 00 dirty_cpus={13} cpu_affinity={0-127}
(XEN)     pause_count=0 pause_flags=1
(XEN)     No periodic timer
(XEN)     VCPU20: CPU3 [has=F] poll=0 upcall_pend = 00, upcall_mask = 00 dirty_cpus={3} cpu_affinity={0-127}
(XEN)     pause_count=0 pause_flags=1
(XEN)     No periodic timer
(XEN)     VCPU21: CPU12 [has=F] poll=0 upcall_pend = 00, upcall_mask = 00 dirty_cpus={12} cpu_affinity={0-127}
(XEN)     pause_count=0 pause_flags=1
(XEN)     No periodic timer
(XEN)     VCPU22: CPU0 [has=F] poll=0 upcall_pend = 00, upcall_mask = 00 dirty_cpus={} cpu_affinity={0-127}
(XEN)     pause_count=0 pause_flags=1
(XEN)     No periodic timer
(XEN)     VCPU23: CPU23 [has=F] poll=0 upcall_pend = 00, upcall_mask = 00 dirty_cpus={23} cpu_affinity={0-127}
(XEN)     pause_count=0 pause_flags=1
(XEN)     No periodic timer
(XEN)     VCPU24: CPU20 [has=F] poll=0 upcall_pend = 00, upcall_mask = 00 dirty_cpus={20} cpu_affinity={0-127}
(XEN)     pause_count=0 pause_flags=1
(XEN)     No periodic timer
(XEN)     VCPU25: CPU2 [has=F] poll=0 upcall_pend = 00, upcall_mask = 00 dirty_cpus={2} cpu_affinity={0-127}
(XEN)     pause_count=0 pause_flags=1
(XEN)     No periodic timer
(XEN)     VCPU26: CPU1 [has=F] poll=0 upcall_pend = 00, upcall_mask = 00 dirty_cpus={1} cpu_affinity={0-127}
(XEN)     pause_count=0 pause_flags=1
(XEN)     No periodic timer
(XEN)     VCPU27: CPU9 [has=F] poll=0 upcall_pend = 00, upcall_mask = 00 dirty_cpus={9} cpu_affinity={0-127}
(XEN)     pause_count=0 pause_flags=1
(XEN)     No periodic timer
(XEN)     VCPU28: CPU5 [has=F] poll=0 upcall_pend = 00, upcall_mask = 00 dirty_cpus={5} cpu_affinity={0-127}
(XEN)     pause_count=0 pause_flags=1
(XEN)     No periodic timer
(XEN)     VCPU29: CPU4 [has=F] poll=0 upcall_pend = 00, upcall_mask = 00 dirty_cpus={4} cpu_affinity={0-127}
(XEN)     pause_count=0 pause_flags=1
(XEN)     No periodic timer
(XEN)     VCPU30: CPU21 [has=F] poll=0 upcall_pend = 00, upcall_mask = 00 dirty_cpus={21} cpu_affinity={0-127}
(XEN)     pause_count=0 pause_flags=1
(XEN)     No periodic timer
(XEN)     VCPU31: CPU6 [has=F] poll=0 upcall_pend = 00, upcall_mask = 00 dirty_cpus={6} cpu_affinity={0-127}
(XEN)     pause_count=0 pause_flags=1
(XEN)     No periodic timer
(XEN) General information for domain 1:
(XEN)     refcnt=3 dying=0 pause_count=0
(XEN)     nr_pages=1047549 xenheap_pages=6 shared_pages=0 paged_pages=0 dirty_cpus={} max_pages=1048832
(XEN)     handle=dd1ee134-05ef-4a65-a2fe-163bce610687 vm_assist=00000000
(XEN)     paging assistance: hap refcounts translate external 
(XEN) Rangesets belonging to domain 1:
(XEN)     I/O Ports  { }
(XEN)     Interrupts { 101-103 }
(XEN)     I/O Memory { ebb41-ebb43, ebb60-ebb63 }
(XEN) Memory pages belonging to domain 1:
(XEN)     DomPage list too long to display
(XEN)     PoD entries=0 cachesize=0
(XEN)     XenPage 000000000044000e: caf=c000000000000001, taf=7400000000000001
(XEN)     XenPage 000000000044000d: caf=c000000000000001, taf=7400000000000001
(XEN)     XenPage 000000000044000c: caf=c000000000000001, taf=7400000000000001
(XEN)     XenPage 00000000004a04f7: caf=c000000000000001, taf=7400000000000001
(XEN)     XenPage 00000000000bd4f8: caf=c000000000000001, taf=7400000000000001
(XEN)     XenPage 00000000004a0400: caf=c000000000000001, taf=7400000000000001
(XEN) VCPU information and callbacks for domain 1:
(XEN)     VCPU0: CPU1 [has=F] poll=0 upcall_pend = 01, upcall_mask = 00 dirty_cpus={} cpu_affinity={0-15}
(XEN)     pause_count=0 pause_flags=4
(XEN)     paging assistance: hap, 4 levels
(XEN)     No periodic timer
(XEN)     VCPU1: CPU10 [has=F] poll=0 upcall_pend = 00, upcall_mask = 00 dirty_cpus={} cpu_affinity={0-15}
(XEN)     pause_count=0 pause_flags=2
(XEN)     paging assistance: hap, 1 levels
(XEN)     No periodic timer
(XEN)     VCPU2: CPU11 [has=F] poll=0 upcall_pend = 00, upcall_mask = 00 dirty_cpus={} cpu_affinity={0-15}
(XEN)     pause_count=0 pause_flags=2
(XEN)     paging assistance: hap, 1 levels
(XEN)     No periodic timer
(XEN)     VCPU3: CPU12 [has=F] poll=0 upcall_pend = 00, upcall_mask = 00 dirty_cpus={} cpu_affinity={0-15}
(XEN)     pause_count=0 pause_flags=2
(XEN)     paging assistance: hap, 1 levels
(XEN)     No periodic timer
(XEN)     VCPU4: CPU13 [has=F] poll=0 upcall_pend = 00, upcall_mask = 00 dirty_cpus={} cpu_affinity={0-15}
(XEN)     pause_count=0 pause_flags=2
(XEN)     paging assistance: hap, 1 levels
(XEN)     No periodic timer
(XEN)     VCPU5: CPU14 [has=F] poll=0 upcall_pend = 00, upcall_mask = 00 dirty_cpus={} cpu_affinity={0-15}
(XEN)     pause_count=0 pause_flags=2
(XEN)     paging assistance: hap, 1 levels
(XEN)     No periodic timer
(XEN)     VCPU6: CPU15 [has=F] poll=0 upcall_pend = 00, upcall_mask = 00 dirty_cpus={} cpu_affinity={0-15}
(XEN)     pause_count=0 pause_flags=2
(XEN)     paging assistance: hap, 1 levels
(XEN)     No periodic timer
(XEN)     VCPU7: CPU0 [has=F] poll=0 upcall_pend = 00, upcall_mask = 00 dirty_cpus={} cpu_affinity={0-15}
(XEN)     pause_count=0 pause_flags=2
(XEN)     paging assistance: hap, 1 levels
(XEN)     No periodic timer
(XEN)     VCPU8: CPU0 [has=F] poll=0 upcall_pend = 00, upcall_mask = 00 dirty_cpus={} cpu_affinity={0-15}
(XEN)     pause_count=0 pause_flags=2
(XEN)     paging assistance: hap, 1 levels
(XEN)     No periodic timer
(XEN)     VCPU9: CPU0 [has=F] poll=0 upcall_pend = 00, upcall_mask = 00 dirty_cpus={} cpu_affinity={0-15}
(XEN)     pause_count=0 pause_flags=2
(XEN)     paging assistance: hap, 1 levels
(XEN)     No periodic timer
(XEN)     VCPU10: CPU0 [has=F] poll=0 upcall_pend = 00, upcall_mask = 00 dirty_cpus={} cpu_affinity={0-15}
(XEN)     pause_count=0 pause_flags=2
(XEN)     paging assistance: hap, 1 levels
(XEN)     No periodic timer
(XEN)     VCPU11: CPU0 [has=F] poll=0 upcall_pend = 00, upcall_mask = 00 dirty_cpus={} cpu_affinity={0-15}
(XEN)     pause_count=0 pause_flags=2
(XEN)     paging assistance: hap, 1 levels
(XEN)     No periodic timer
(XEN)     VCPU12: CPU0 [has=F] poll=0 upcall_pend = 00, upcall_mask = 00 dirty_cpus={} cpu_affinity={0-15}
(XEN)     pause_count=0 pause_flags=2
(XEN)     paging assistance: hap, 1 levels
(XEN)     No periodic timer
(XEN)     VCPU13: CPU0 [has=F] poll=0 upcall_pend = 00, upcall_mask = 00 dirty_cpus={} cpu_affinity={0-15}
(XEN)     pause_count=0 pause_flags=2
(XEN)     paging assistance: hap, 1 levels
(XEN)     No periodic timer
(XEN)     VCPU14: CPU0 [has=F] poll=0 upcall_pend = 00, upcall_mask = 00 dirty_cpus={} cpu_affinity={0-15}
(XEN)     pause_count=0 pause_flags=2
(XEN)     paging assistance: hap, 1 levels
(XEN)     No periodic timer
(XEN)     VCPU15: CPU0 [has=F] poll=0 upcall_pend = 00, upcall_mask = 00 dirty_cpus={} cpu_affinity={0-15}
(XEN)     pause_count=0 pause_flags=2
(XEN)     paging assistance: hap, 1 levels
(XEN)     No periodic timer
(XEN) General information for domain 2:
(XEN)     refcnt=3 dying=0 pause_count=0
(XEN)     nr_pages=523261 xenheap_pages=6 shared_pages=0 paged_pages=0 dirty_cpus={31} max_pages=524544
(XEN)     handle=b10a1595-a5b0-46e2-a67a-3c77c4755761 vm_assist=00000000
(XEN)     paging assistance: hap refcounts translate external 
(XEN) Rangesets belonging to domain 2:
(XEN)     I/O Ports  { }
(XEN)     Interrupts { }
(XEN)     I/O Memory { }
(XEN) Memory pages belonging to domain 2:
(XEN)     DomPage list too long to display
(XEN)     PoD entries=0 cachesize=0
(XEN)     XenPage 00000000004b44f3: caf=c000000000000001, taf=7400000000000001
(XEN)     XenPage 00000000004b44f2: caf=c000000000000001, taf=7400000000000001
(XEN)     XenPage 00000000004b44f1: caf=c000000000000001, taf=7400000000000001
(XEN)     XenPage 00000000004b44f0: caf=c000000000000001, taf=7400000000000001
(XEN)     XenPage 00000000000bb08f: caf=c000000000000001, taf=7400000000000001
(XEN)     XenPage 00000000004b27a7: caf=c000000000000001, taf=7400000000000001
(XEN) VCPU information and callbacks for domain 2:
(XEN)     VCPU0: CPU31 [has=T] poll=0 upcall_pend = 00, upcall_mask = 00 dirty_cpus={31} cpu_affinity={16-31}
(XEN)     pause_count=0 pause_flags=0
(XEN)     paging assistance: hap, 4 levels
(XEN)     No periodic timer
(XEN)     VCPU1: CPU16 [has=F] poll=0 upcall_pend = 00, upcall_mask = 00 dirty_cpus={} cpu_affinity={16-31}
(XEN)     pause_count=0 pause_flags=4
(XEN)     paging assistance: hap, 4 levels
(XEN)     No periodic timer
(XEN)     VCPU2: CPU18 [has=F] poll=0 upcall_pend = 00, upcall_mask = 00 dirty_cpus={} cpu_affinity={16-31}
(XEN)     pause_count=0 pause_flags=2
(XEN)     paging assistance: hap, 1 levels
(XEN)     No periodic timer
(XEN)     VCPU3: CPU19 [has=F] poll=0 upcall_pend = 00, upcall_mask = 00 dirty_cpus={} cpu_affinity={16-31}
(XEN)     pause_count=0 pause_flags=2
(XEN)     paging assistance: hap, 1 levels
(XEN)     No periodic timer
(XEN)     VCPU4: CPU18 [has=F] poll=0 upcall_pend = 00, upcall_mask = 00 dirty_cpus={} cpu_affinity={16-31}
(XEN)     pause_count=0 pause_flags=2
(XEN)     paging assistance: hap, 1 levels
(XEN)     No periodic timer
(XEN)     VCPU5: CPU19 [has=F] poll=0 upcall_pend = 00, upcall_mask = 00 dirty_cpus={} cpu_affinity={16-31}
(XEN)     pause_count=0 pause_flags=2
(XEN)     paging assistance: hap, 1 levels
(XEN)     No periodic timer
(XEN)     VCPU6: CPU18 [has=F] poll=0 upcall_pend = 00, upcall_mask = 00 dirty_cpus={} cpu_affinity={16-31}
(XEN)     pause_count=0 pause_flags=2
(XEN)     paging assistance: hap, 1 levels
(XEN)     No periodic timer
(XEN)     VCPU7: CPU19 [has=F] poll=0 upcall_pend = 00, upcall_mask = 00 dirty_cpus={} cpu_affinity={16-31}
(XEN)     pause_count=0 pause_flags=2
(XEN)     paging assistance: hap, 1 levels
(XEN)     No periodic timer
(XEN)     VCPU8: CPU18 [has=F] poll=0 upcall_pend = 00, upcall_mask = 00 dirty_cpus={} cpu_affinity={16-31}
(XEN)     pause_count=0 pause_flags=2
(XEN)     paging assistance: hap, 1 levels
(XEN)     No periodic timer
(XEN)     VCPU9: CPU16 [has=F] poll=0 upcall_pend = 00, upcall_mask = 00 dirty_cpus={} cpu_affinity={16-31}
(XEN)     pause_count=0 pause_flags=2
(XEN)     paging assistance: hap, 1 levels
(XEN)     No periodic timer
(XEN)     VCPU10: CPU17 [has=F] poll=0 upcall_pend = 00, upcall_mask = 00 dirty_cpus={} cpu_affinity={16-31}
(XEN)     pause_count=0 pause_flags=2
(XEN)     paging assistance: hap, 1 levels
(XEN)     No periodic timer
(XEN)     VCPU11: CPU18 [has=F] poll=0 upcall_pend = 00, upcall_mask = 00 dirty_cpus={} cpu_affinity={16-31}
(XEN)     pause_count=0 pause_flags=2
(XEN)     paging assistance: hap, 1 levels
(XEN)     No periodic timer
(XEN)     VCPU12: CPU19 [has=F] poll=0 upcall_pend = 00, upcall_mask = 00 dirty_cpus={} cpu_affinity={16-31}
(XEN)     pause_count=0 pause_flags=2
(XEN)     paging assistance: hap, 1 levels
(XEN)     No periodic timer
(XEN)     VCPU13: CPU20 [has=F] poll=0 upcall_pend = 00, upcall_mask = 00 dirty_cpus={} cpu_affinity={16-31}
(XEN)     pause_count=0 pause_flags=2
(XEN)     paging assistance: hap, 1 levels
(XEN)     No periodic timer
(XEN)     VCPU14: CPU21 [has=F] poll=0 upcall_pend = 00, upcall_mask = 00 dirty_cpus={} cpu_affinity={16-31}
(XEN)     pause_count=0 pause_flags=2
(XEN)     paging assistance: hap, 1 levels
(XEN)     No periodic timer
(XEN)     VCPU15: CPU22 [has=F] poll=0 upcall_pend = 00, upcall_mask = 00 dirty_cpus={} cpu_affinity={16-31}
(XEN)     pause_count=0 pause_flags=2
(XEN)     paging assistance: hap, 1 levels
(XEN)     No periodic timer
(XEN) Notifying guest 0:0 (virq 1, port 5, stat 0/0/0)
(XEN) Notifying guest 0:1 (virq 1, port 12, stat 0/0/0)
[ 4672.954495] (XEN) Notifying guest 0:2 (virq 1, port 19, stat 0/0/0)

vcpu 0
  (XEN) Notifying guest 0:3 (virq 1, port 26, stat 0/0/0)
0: masked=0 pend(XEN) Notifying guest 0:4 (virq 1, port 33, stat 0/0/0)
ing=0 event_sel (XEN) Notifying guest 0:5 (virq 1, port 40, stat 0/0/0)
0000000000000000(XEN) Notifying guest 0:6 (virq 1, port 47, stat 0/0/0)

  (XEN) Notifying guest 0:7 (virq 1, port 54, stat 0/0/0)
1: masked=1 pend(XEN) Notifying guest 0:8 (virq 1, port 61, stat 0/0/0)
ing=0 event_sel (XEN) Notifying guest 0:9 (virq 1, port 68, stat 0/0/0)
0000000000000000(XEN) Notifying guest 0:10 (virq 1, port 75, stat 0/0/0)

  (XEN) Notifying guest 0:11 (virq 1, port 82, stat 0/0/0)
2: masked=1 pend(XEN) Notifying guest 0:12 (virq 1, port 89, stat 0/0/0)
ing=0 event_sel (XEN) Notifying guest 0:13 (virq 1, port 96, stat 0/0/0)
0000000000000000(XEN) Notifying guest 0:14 (virq 1, port 103, stat 0/0/0)

  (XEN) Notifying guest 0:15 (virq 1, port 110, stat 0/0/0)
3: masked=1 pend(XEN) Notifying guest 0:16 (virq 1, port 117, stat 0/0/0)
ing=0 event_sel (XEN) Notifying guest 0:17 (virq 1, port 124, stat 0/0/0)
0000000000000000(XEN) Notifying guest 0:18 (virq 1, port 131, stat 0/0/0)

  (XEN) Notifying guest 0:19 (virq 1, port 138, stat 0/0/0)
4: masked=1 pend(XEN) Notifying guest 0:20 (virq 1, port 145, stat 0/0/0)
ing=0 event_sel (XEN) Notifying guest 0:21 (virq 1, port 152, stat 0/0/0)
0000000000000000(XEN) Notifying guest 0:22 (virq 1, port 159, stat 0/0/0)

  (XEN) Notifying guest 0:23 (virq 1, port 166, stat 0/0/0)
5: masked=1 pend(XEN) Notifying guest 0:24 (virq 1, port 173, stat 0/0/0)
ing=0 event_sel (XEN) Notifying guest 0:25 (virq 1, port 180, stat 0/0/0)
0000000000000000(XEN) Notifying guest 0:26 (virq 1, port 187, stat 0/0/0)

  (XEN) Notifying guest 0:27 (virq 1, port 194, stat 0/0/0)
6: masked=1 pend(XEN) Notifying guest 0:28 (virq 1, port 201, stat 0/0/0)
ing=0 event_sel (XEN) Notifying guest 0:29 (virq 1, port 208, stat 0/0/0)
0000000000000000(XEN) Notifying guest 0:30 (virq 1, port 215, stat 0/0/0)

  (XEN) Notifying guest 0:31 (virq 1, port 222, stat 0/0/0)
7: masked=1 pend(XEN) Notifying guest 1:0 (virq 1, port 0, stat 0/-1/-1)
ing=0 event_sel (XEN) Notifying guest 1:1 (virq 1, port 0, stat 0/-1/0)
0000000000000000(XEN) Notifying guest 1:2 (virq 1, port 0, stat 0/-1/0)

  (XEN) Notifying guest 1:3 (virq 1, port 0, stat 0/-1/0)
8: masked=1 pend(XEN) Notifying guest 1:4 (virq 1, port 0, stat 0/-1/0)
ing=0 event_sel (XEN) Notifying guest 1:5 (virq 1, port 0, stat 0/-1/0)
0000000000000000(XEN) Notifying guest 1:6 (virq 1, port 0, stat 0/-1/0)

  (XEN) Notifying guest 1:7 (virq 1, port 0, stat 0/-1/0)
9: masked=1 pend(XEN) Notifying guest 1:8 (virq 1, port 0, stat 0/-1/0)
ing=1 event_sel (XEN) Notifying guest 1:9 (virq 1, port 0, stat 0/-1/0)
0000000000000002(XEN) Notifying guest 1:10 (virq 1, port 0, stat 0/-1/0)

  (XEN) Notifying guest 1:11 (virq 1, port 0, stat 0/-1/0)
10: masked=1 pen(XEN) Notifying guest 1:12 (virq 1, port 0, stat 0/-1/0)
ding=0 event_sel(XEN) Notifying guest 1:13 (virq 1, port 0, stat 0/-1/0)
 000000000000000(XEN) Notifying guest 1:14 (virq 1, port 0, stat 0/-1/0)
0
  (XEN) Notifying guest 1:15 (virq 1, port 0, stat 0/-1/0)
11: masked=1 pen(XEN) Notifying guest 2:0 (virq 1, port 0, stat 0/-1/0)
ding=0 event_sel(XEN) Notifying guest 2:1 (virq 1, port 0, stat 0/-1/0)
 000000000000000(XEN) Notifying guest 2:2 (virq 1, port 0, stat 0/-1/0)
0
  (XEN) Notifying guest 2:3 (virq 1, port 0, stat 0/-1/0)
12: masked=1 pen(XEN) Notifying guest 2:4 (virq 1, port 0, stat 0/-1/0)
ding=0 event_sel(XEN) Notifying guest 2:5 (virq 1, port 0, stat 0/-1/0)
 000000000000000(XEN) Notifying guest 2:6 (virq 1, port 0, stat 0/-1/0)
0
  (XEN) Notifying guest 2:7 (virq 1, port 0, stat 0/-1/0)
13: masked=1 pen(XEN) Notifying guest 2:8 (virq 1, port 0, stat 0/-1/0)
ding=0 event_sel(XEN) Notifying guest 2:9 (virq 1, port 0, stat 0/-1/0)
 000000000000000(XEN) Notifying guest 2:10 (virq 1, port 0, stat 0/-1/0)
0
  (XEN) Notifying guest 2:11 (virq 1, port 0, stat 0/-1/0)
14: masked=1 pen(XEN) Notifying guest 2:12 (virq 1, port 0, stat 0/-1/0)
ding=0 event_sel(XEN) Notifying guest 2:13 (virq 1, port 0, stat 0/-1/0)
 000000000000000(XEN) Notifying guest 2:14 (virq 1, port 0, stat 0/-1/0)
0
  (XEN) Notifying guest 2:15 (virq 1, port 0, stat 0/-1/0)
15: masked=1 pen(XEN) Shared frames 0 -- Saved frames 0
ding=(XEN) *** Serial input -> DOM0 (type 'CTRL-a' three times to switch input to Xen)


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 25 06:12:11 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 06:12:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGON5-0004e0-66; Tue, 25 Sep 2012 06:11:51 +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 1TGON3-0004dv-Sa
	for xen-devel@lists.xen.org; Tue, 25 Sep 2012 06:11:49 +0000
Received: from [85.158.143.99:31270] by server-1.bemta-4.messagelabs.com id
	A1/6B-05684-52B41605; Tue, 25 Sep 2012 06:11:49 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-13.tower-216.messagelabs.com!1348553507!30724679!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA1MTI5Mzc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15840 invoked from network); 25 Sep 2012 06:11:48 -0000
Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25)
	by server-13.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 25 Sep 2012 06:11:48 -0000
X-Originating-Ip: [194.89.68.22]
Received: from ydin.reaktio.net (reaktio.net [194.89.68.22])
	by smtp.tele.fi (Postfix) with ESMTP id 79B852F69;
	Tue, 25 Sep 2012 09:11:47 +0300 (EEST)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id 38B0420061; Tue, 25 Sep 2012 09:11:47 +0300 (EEST)
Date: Tue, 25 Sep 2012 09:11:47 +0300
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: Qian Hu <qianhu2011@gmail.com>
Message-ID: <20120925061147.GK8912@reaktio.net>
References: <CALCpXpCvGkjZyG-NOY+fZY0q0f_DxuwPNEnxwKXVhjOe=gcHSQ@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CALCpXpCvGkjZyG-NOY+fZY0q0f_DxuwPNEnxwKXVhjOe=gcHSQ@mail.gmail.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] usbpassthrough of xen-4.1.2 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, Sep 25, 2012 at 11:17:03AM +0800, Qian Hu wrote:
>    Hi, everyone! The same question with updated message.
>    I am working on the USB passthrough of Xen-4.1.2. My host OS  is Fedora 14
>    and the guest OS is win7.
>    According to the wiki
>    page([1]http://wiki.xen.org/wiki/Xen_USB_Passthrough),
>    xen supports passthrough of usb device from dom0 to guests. I have tried
>    the Xen HVM guest qemu-dm usb1.1 emulation,
>    by specifying "usb = 1" and "usbdevice = host:xxxx:yyyy". I have also
>    tried the command usb_add host:xxxx:yyyy.
>    But, the mouse could work, the keyboard didn't, and the usb storage
>    device(usb 2.0) appeared in the device manager.
>    While the driver is OK, it couldn't start. I can only find the message
>     "The device cannot start(code 10)".
>    I doubt there may be something wrong with the guest OS driver, which is
>    not said to be needed.
>    I am confused and don't know how to resolve it.  Could anyone help me?
>

It might be a bug in the USB emulation code in the old qemu-dm traditional.

Any errors in:
- "dmesg" output? 
- /var/log/xen/qemu-dm* (for the windows vm).
- "xm dmesg" output ? 


-- Pasi


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 25 06:12:11 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 06:12:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGON5-0004e0-66; Tue, 25 Sep 2012 06:11:51 +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 1TGON3-0004dv-Sa
	for xen-devel@lists.xen.org; Tue, 25 Sep 2012 06:11:49 +0000
Received: from [85.158.143.99:31270] by server-1.bemta-4.messagelabs.com id
	A1/6B-05684-52B41605; Tue, 25 Sep 2012 06:11:49 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-13.tower-216.messagelabs.com!1348553507!30724679!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA1MTI5Mzc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15840 invoked from network); 25 Sep 2012 06:11:48 -0000
Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25)
	by server-13.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 25 Sep 2012 06:11:48 -0000
X-Originating-Ip: [194.89.68.22]
Received: from ydin.reaktio.net (reaktio.net [194.89.68.22])
	by smtp.tele.fi (Postfix) with ESMTP id 79B852F69;
	Tue, 25 Sep 2012 09:11:47 +0300 (EEST)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id 38B0420061; Tue, 25 Sep 2012 09:11:47 +0300 (EEST)
Date: Tue, 25 Sep 2012 09:11:47 +0300
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: Qian Hu <qianhu2011@gmail.com>
Message-ID: <20120925061147.GK8912@reaktio.net>
References: <CALCpXpCvGkjZyG-NOY+fZY0q0f_DxuwPNEnxwKXVhjOe=gcHSQ@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CALCpXpCvGkjZyG-NOY+fZY0q0f_DxuwPNEnxwKXVhjOe=gcHSQ@mail.gmail.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] usbpassthrough of xen-4.1.2 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, Sep 25, 2012 at 11:17:03AM +0800, Qian Hu wrote:
>    Hi, everyone! The same question with updated message.
>    I am working on the USB passthrough of Xen-4.1.2. My host OS  is Fedora 14
>    and the guest OS is win7.
>    According to the wiki
>    page([1]http://wiki.xen.org/wiki/Xen_USB_Passthrough),
>    xen supports passthrough of usb device from dom0 to guests. I have tried
>    the Xen HVM guest qemu-dm usb1.1 emulation,
>    by specifying "usb = 1" and "usbdevice = host:xxxx:yyyy". I have also
>    tried the command usb_add host:xxxx:yyyy.
>    But, the mouse could work, the keyboard didn't, and the usb storage
>    device(usb 2.0) appeared in the device manager.
>    While the driver is OK, it couldn't start. I can only find the message
>     "The device cannot start(code 10)".
>    I doubt there may be something wrong with the guest OS driver, which is
>    not said to be needed.
>    I am confused and don't know how to resolve it.  Could anyone help me?
>

It might be a bug in the USB emulation code in the old qemu-dm traditional.

Any errors in:
- "dmesg" output? 
- /var/log/xen/qemu-dm* (for the windows vm).
- "xm dmesg" output ? 


-- Pasi


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 25 07:00:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 07:00: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 1TGP7T-0004vB-6Y; Tue, 25 Sep 2012 06:59:47 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1TGP7R-0004v6-U8
	for xen-devel@lists.xen.org; Tue, 25 Sep 2012 06:59:46 +0000
Received: from [85.158.139.211:52420] by server-5.bemta-5.messagelabs.com id
	41/37-21075-06651605; Tue, 25 Sep 2012 06:59:44 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-16.tower-206.messagelabs.com!1348556384!19870745!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32615 invoked from network); 25 Sep 2012 06:59:44 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-16.tower-206.messagelabs.com with SMTP;
	25 Sep 2012 06:59:44 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 25 Sep 2012 07:59:43 +0100
Message-Id: <50617297020000780009D8AA@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 25 Sep 2012 08:00:07 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Keir Fraser" <keir.xen@gmail.com>,"Ben Guthro" <ben@guthro.net>
References: <CAOvdn6UCF2A3yP1cqWn=dxwr0ayRbr+rg+xj8META9Dm0+CoNw@mail.gmail.com>
	<CC868168.3FD29%keir.xen@gmail.com>
	<CAOvdn6U-JyLvt96gkLkqzi088tU9_ktv4D+fkJac_BKVe05Y-w@mail.gmail.com>
	<CAOvdn6V+s3AbRzsu8VArbmrZou=im9SqvPf-9Wpif_BrNMv=yg@mail.gmail.com>
In-Reply-To: <CAOvdn6V+s3AbRzsu8VArbmrZou=im9SqvPf-9Wpif_BrNMv=yg@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen4.2 S3 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 24.09.12 at 23:12, Ben Guthro <ben@guthro.net> wrote:
> Here's my "Big hammer" debugging patch.
> 
> If I force the cpu to be scheduled on CPU0 when the appropriate cpu is not
> online, I can resume properly.
> 
> Clearly this is not the proper solution, and I'm sure the fix is subtle.
> I'm not seeing it right now though. Perhaps tomorrow morning.
> If you have any ideas, I'm happy to run tests then.

I can't see how the printk() you add in the patch would ever get
reached with the other adjustment you do there. A debug build,
as Keir suggested, would not only get the stack trace right, but
would also result in the ASSERT() right after your first modification
to _csched_cpu_pick() to actually do something (and likely trigger).

Anyway, this might be connected to cpu_disable_scheduler() not
having a counterpart to restore the affinity it broke for pinned
domains (for non-pinned ones I believe this behavior is intentional,
albeit not ideal).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 25 07:00:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 07:00: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 1TGP7T-0004vB-6Y; Tue, 25 Sep 2012 06:59:47 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1TGP7R-0004v6-U8
	for xen-devel@lists.xen.org; Tue, 25 Sep 2012 06:59:46 +0000
Received: from [85.158.139.211:52420] by server-5.bemta-5.messagelabs.com id
	41/37-21075-06651605; Tue, 25 Sep 2012 06:59:44 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-16.tower-206.messagelabs.com!1348556384!19870745!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32615 invoked from network); 25 Sep 2012 06:59:44 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-16.tower-206.messagelabs.com with SMTP;
	25 Sep 2012 06:59:44 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 25 Sep 2012 07:59:43 +0100
Message-Id: <50617297020000780009D8AA@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 25 Sep 2012 08:00:07 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Keir Fraser" <keir.xen@gmail.com>,"Ben Guthro" <ben@guthro.net>
References: <CAOvdn6UCF2A3yP1cqWn=dxwr0ayRbr+rg+xj8META9Dm0+CoNw@mail.gmail.com>
	<CC868168.3FD29%keir.xen@gmail.com>
	<CAOvdn6U-JyLvt96gkLkqzi088tU9_ktv4D+fkJac_BKVe05Y-w@mail.gmail.com>
	<CAOvdn6V+s3AbRzsu8VArbmrZou=im9SqvPf-9Wpif_BrNMv=yg@mail.gmail.com>
In-Reply-To: <CAOvdn6V+s3AbRzsu8VArbmrZou=im9SqvPf-9Wpif_BrNMv=yg@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen4.2 S3 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 24.09.12 at 23:12, Ben Guthro <ben@guthro.net> wrote:
> Here's my "Big hammer" debugging patch.
> 
> If I force the cpu to be scheduled on CPU0 when the appropriate cpu is not
> online, I can resume properly.
> 
> Clearly this is not the proper solution, and I'm sure the fix is subtle.
> I'm not seeing it right now though. Perhaps tomorrow morning.
> If you have any ideas, I'm happy to run tests then.

I can't see how the printk() you add in the patch would ever get
reached with the other adjustment you do there. A debug build,
as Keir suggested, would not only get the stack trace right, but
would also result in the ASSERT() right after your first modification
to _csched_cpu_pick() to actually do something (and likely trigger).

Anyway, this might be connected to cpu_disable_scheduler() not
having a counterpart to restore the affinity it broke for pinned
domains (for non-pinned ones I believe this behavior is intentional,
albeit not ideal).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 25 07:10:30 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 07:10:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGPHT-0005IS-3j; Tue, 25 Sep 2012 07:10:07 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andi.reinbrech@darwinistic.com>) id 1TGPHR-0005IN-Ls
	for xen-devel@lists.xen.org; Tue, 25 Sep 2012 07:10:05 +0000
Received: from [85.158.143.99:6656] by server-2.bemta-4.messagelabs.com id
	7C/52-06610-DC851605; Tue, 25 Sep 2012 07:10:05 +0000
X-Env-Sender: andi.reinbrech@darwinistic.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1348557003!30731450!1
X-Originating-IP: [65.254.45.238]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15093 invoked from network); 25 Sep 2012 07:10:04 -0000
Received: from www.darwinistic.com (HELO brain.darwinistic.com) (65.254.45.238)
	by server-13.tower-216.messagelabs.com with SMTP;
	25 Sep 2012 07:10:04 -0000
Received: from [192.168.0.95] (dsl-242-157-22.telkomadsl.co.za [41.242.157.22])
	by brain.darwinistic.com (Postfix) with ESMTP id 93B2C135A3E7
	for <xen-devel@lists.xen.org>; Tue, 25 Sep 2012 09:10:02 +0200 (SAST)
Message-ID: <506158C5.6000302@darwinistic.com>
Date: Tue, 25 Sep 2012 09:09:57 +0200
From: Andi Reinbrech <andi.reinbrech@darwinistic.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:15.0) Gecko/20120907 Thunderbird/15.0.1
MIME-Version: 1.0
To: xen-devel@lists.xen.org
Subject: [Xen-devel] 4.2 kernel 3.5 USB PCI Passthrough
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi Xenners,

I have been using 4.2 for a very long time now, and recently (since 
upgrading to rc2), I've had some strange issues cropping up:

None of my disk images boot with xl create;  I have moved the important 
ones to LVM disks, since phy: boots fine.  I have hacked some of the xen 
code to make this work (but forgot which hack got it working, it has to 
do with the caching modes in the file open calls - I will double check 
and get back to the list).  My qemu disks are always reported as 
0mb-sized volumes in the BIOS screen when this bug manifests itself.  
Neither raw nor qcow2 images work.

When I upgraded to kernel 3.5, my USB PCI passthrough stopped working.  
The secondary VGA passthrough still works fine, just the USB host 
controller that is passed through gets claimed by xen, but the guest 
cannot load drivers for the controller.  I.e. the guest (Windoze 7) sees 
it in device manager, but the device fails to activate.

Last night I upgraded to the latest 3.5.4 in the fc17 repo, and the USB 
issue was still there.  The weird thing though, is that it seems that my 
raw images magically started booting.  I still need to investigate this, 
in more detail to make sure I'm not mixing up versions and get 
conclusive results.

Apologies, this post is not too detailed and contains too many "maybes", 
but I though there may be a simple answer that someone else had stumbled 
across the same issues recently.

I will compile rc3 later on and run decent comparisons on both kernels, 
as well as raw and LVM machines.

Kind regards,
Andi

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 25 07:10:30 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 07:10:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGPHT-0005IS-3j; Tue, 25 Sep 2012 07:10:07 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andi.reinbrech@darwinistic.com>) id 1TGPHR-0005IN-Ls
	for xen-devel@lists.xen.org; Tue, 25 Sep 2012 07:10:05 +0000
Received: from [85.158.143.99:6656] by server-2.bemta-4.messagelabs.com id
	7C/52-06610-DC851605; Tue, 25 Sep 2012 07:10:05 +0000
X-Env-Sender: andi.reinbrech@darwinistic.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1348557003!30731450!1
X-Originating-IP: [65.254.45.238]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15093 invoked from network); 25 Sep 2012 07:10:04 -0000
Received: from www.darwinistic.com (HELO brain.darwinistic.com) (65.254.45.238)
	by server-13.tower-216.messagelabs.com with SMTP;
	25 Sep 2012 07:10:04 -0000
Received: from [192.168.0.95] (dsl-242-157-22.telkomadsl.co.za [41.242.157.22])
	by brain.darwinistic.com (Postfix) with ESMTP id 93B2C135A3E7
	for <xen-devel@lists.xen.org>; Tue, 25 Sep 2012 09:10:02 +0200 (SAST)
Message-ID: <506158C5.6000302@darwinistic.com>
Date: Tue, 25 Sep 2012 09:09:57 +0200
From: Andi Reinbrech <andi.reinbrech@darwinistic.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:15.0) Gecko/20120907 Thunderbird/15.0.1
MIME-Version: 1.0
To: xen-devel@lists.xen.org
Subject: [Xen-devel] 4.2 kernel 3.5 USB PCI Passthrough
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi Xenners,

I have been using 4.2 for a very long time now, and recently (since 
upgrading to rc2), I've had some strange issues cropping up:

None of my disk images boot with xl create;  I have moved the important 
ones to LVM disks, since phy: boots fine.  I have hacked some of the xen 
code to make this work (but forgot which hack got it working, it has to 
do with the caching modes in the file open calls - I will double check 
and get back to the list).  My qemu disks are always reported as 
0mb-sized volumes in the BIOS screen when this bug manifests itself.  
Neither raw nor qcow2 images work.

When I upgraded to kernel 3.5, my USB PCI passthrough stopped working.  
The secondary VGA passthrough still works fine, just the USB host 
controller that is passed through gets claimed by xen, but the guest 
cannot load drivers for the controller.  I.e. the guest (Windoze 7) sees 
it in device manager, but the device fails to activate.

Last night I upgraded to the latest 3.5.4 in the fc17 repo, and the USB 
issue was still there.  The weird thing though, is that it seems that my 
raw images magically started booting.  I still need to investigate this, 
in more detail to make sure I'm not mixing up versions and get 
conclusive results.

Apologies, this post is not too detailed and contains too many "maybes", 
but I though there may be a simple answer that someone else had stumbled 
across the same issues recently.

I will compile rc3 later on and run decent comparisons on both kernels, 
as well as raw and LVM machines.

Kind regards,
Andi

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 25 07:59:40 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 07:59:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGQ2z-0005Ya-36; Tue, 25 Sep 2012 07:59:13 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72) id 1TGLqI-0002vH-K6
	for xen-devel@lists.xen.org; Tue, 25 Sep 2012 03:29:50 +0000
Received: from [85.158.143.35:12905] by server-3.bemta-4.messagelabs.com id
	0E/3E-10986-D2521605; Tue, 25 Sep 2012 03:29:49 +0000
X-Msg-Ref: server-2.tower-21.messagelabs.com!1348543788!8718747!1
X-Originating-IP: [143.182.124.21]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMjEgPT4gMjA4MDE1\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30139 invoked from network); 25 Sep 2012 03:29:48 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (143.182.124.21)
	by server-2.tower-21.messagelabs.com with SMTP;
	25 Sep 2012 03:29:48 -0000
Received: from azsmga001.ch.intel.com ([10.2.17.19])
	by azsmga101.ch.intel.com with ESMTP; 24 Sep 2012 20:29:46 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.80,478,1344236400"; d="scan'208";a="196655038"
Received: from xhao-dev.sh.intel.com (HELO localhost.localdomain)
	([10.239.48.48])
	by azsmga001.ch.intel.com with ESMTP; 24 Sep 2012 20:29:45 -0700
From: 
To: ian.jackson@eu.citrix.com
Date: Tue, 25 Sep 2012 11:33:18 +0800
Message-Id: <1348543998-31304-1-git-send-email-xudong.hao@intel.com>
X-Mailer: git-send-email 1.5.5
X-Mailman-Approved-At: Tue, 25 Sep 2012 07:59:11 +0000
Cc: ian.campbell@citrix.com, stefano.stabellini@eu.citrix.com,
	Xudong Hao <xudong.hao@intel.com>, xen-devel@lists.xen.org,
	jbeulich@suse.com, Xiantao Zhang <xiantao.zhang@intel.com>
Subject: [Xen-devel] [PATCH v2] xen/tools: Add 64 bits big bar 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

Currently it is assumed PCI device BAR access < 4G memory. If there is such a
device whose BAR size is larger than 4G, it must access > 4G memory address.
This patch enable the 64bits big BAR support on hvmloader.

Changes from v1:
1) Set Dynamic MMIO high memory address instead of a fixed number 640G
2) Mask bar_sz earlier to avoid older code changes
3) Add bar size barrier to judge high memory resource
4) Clean up bar64_relocate code

Signed-off-by: Xiantao Zhang <xiantao.zhang@intel.com>
Signed-off-by: Xudong Hao <xudong.hao@intel.com>

diff -r dc56a9defa30 tools/firmware/hvmloader/cacheattr.c
--- a/tools/firmware/hvmloader/cacheattr.c	Tue Aug 14 10:28:14 2012 +0200
+++ b/tools/firmware/hvmloader/cacheattr.c	Wed Sep 12 14:50:55 2012 +0800
@@ -40,17 +40,10 @@
 #define MSR_PAT              0x0277
 #define MSR_MTRRdefType      0x02ff
 
-void cacheattr_init(void)
+unsigned int cpu_phys_addr(void)
 {
     uint32_t eax, ebx, ecx, edx;
-    uint64_t mtrr_cap, mtrr_def, content, addr_mask;
-    unsigned int i, nr_var_ranges, phys_bits = 36;
-
-    /* Does the CPU support architectural MTRRs? */
-    cpuid(0x00000001, &eax, &ebx, &ecx, &edx);
-    if ( !(edx & (1u << 12)) )
-         return;
-
+    unsigned int phys_bits = 36;
     /* Find the physical address size for this CPU. */
     cpuid(0x80000000, &eax, &ebx, &ecx, &edx);
     if ( eax >= 0x80000008 )
@@ -59,6 +52,22 @@
         phys_bits = (uint8_t)eax;
     }
 
+    return phys_bits;
+}
+
+void cacheattr_init(void)
+{
+    uint32_t eax, ebx, ecx, edx;
+    uint64_t mtrr_cap, mtrr_def, content, addr_mask;
+    unsigned int i, nr_var_ranges, phys_bits;
+
+    /* Does the CPU support architectural MTRRs? */
+    cpuid(0x00000001, &eax, &ebx, &ecx, &edx);
+    if ( !(edx & (1u << 12)) )
+         return;
+
+    phys_bits = cpu_phys_addr();
+
     printf("%u-bit phys ... ", phys_bits);
 
     addr_mask = ((1ull << phys_bits) - 1) & ~((1ull << 12) - 1);
diff -r dc56a9defa30 tools/firmware/hvmloader/config.h
--- a/tools/firmware/hvmloader/config.h	Tue Aug 14 10:28:14 2012 +0200
+++ b/tools/firmware/hvmloader/config.h	Wed Sep 12 14:50:55 2012 +0800
@@ -53,6 +53,8 @@
 /* MMIO hole: Hardcoded defaults, which can be dynamically expanded. */
 #define PCI_MEM_START       0xf0000000
 #define PCI_MEM_END         0xfc000000
+#define PCI_MIN_BIG_BAR_SIZE          0x20000000
+
 extern unsigned long pci_mem_start, pci_mem_end;
 
 
diff -r dc56a9defa30 tools/firmware/hvmloader/pci.c
--- a/tools/firmware/hvmloader/pci.c	Tue Aug 14 10:28:14 2012 +0200
+++ b/tools/firmware/hvmloader/pci.c	Wed Sep 12 14:50:55 2012 +0800
@@ -36,19 +36,25 @@
 
 void pci_setup(void)
 {
-    uint32_t base, devfn, bar_reg, bar_data, bar_sz, cmd, mmio_total = 0;
+    uint8_t is_64bar, using_64bar, bar64_relocate = 0;
+    uint32_t devfn, bar_reg, cmd, bar_data, bar_data_upper;
+    uint64_t base, bar_sz, bar_sz_upper, mmio_total = 0;
     uint32_t vga_devfn = 256;
     uint16_t class, vendor_id, device_id;
     unsigned int bar, pin, link, isa_irq;
+    int64_t mmio_left;
 
     /* Resources assignable to PCI devices via BARs. */
     struct resource {
-        uint32_t base, max;
-    } *resource, mem_resource, io_resource;
+        uint64_t base, max;
+    } *resource, mem_resource, high_mem_resource, io_resource;
 
     /* Create a list of device BARs in descending order of size. */
     struct bars {
-        uint32_t devfn, bar_reg, bar_sz;
+        uint32_t is_64bar;
+        uint32_t devfn;
+        uint32_t bar_reg;
+        uint64_t bar_sz;
     } *bars = (struct bars *)scratch_start;
     unsigned int i, nr_bars = 0;
 
@@ -133,22 +139,34 @@
         /* Map the I/O memory and port resources. */
         for ( bar = 0; bar < 7; bar++ )
         {
+            bar_sz_upper = 0;
             bar_reg = PCI_BASE_ADDRESS_0 + 4*bar;
             if ( bar == 6 )
                 bar_reg = PCI_ROM_ADDRESS;
 
             bar_data = pci_readl(devfn, bar_reg);
+            is_64bar = !!((bar_data & (PCI_BASE_ADDRESS_SPACE |
+                         PCI_BASE_ADDRESS_MEM_TYPE_MASK)) ==
+                         (PCI_BASE_ADDRESS_SPACE_MEMORY |
+                         PCI_BASE_ADDRESS_MEM_TYPE_64));
             pci_writel(devfn, bar_reg, ~0);
             bar_sz = pci_readl(devfn, bar_reg);
             pci_writel(devfn, bar_reg, bar_data);
-            if ( bar_sz == 0 )
-                continue;
 
             bar_sz &= (((bar_data & PCI_BASE_ADDRESS_SPACE) ==
                         PCI_BASE_ADDRESS_SPACE_MEMORY) ?
                        PCI_BASE_ADDRESS_MEM_MASK :
                        (PCI_BASE_ADDRESS_IO_MASK & 0xffff));
+            if (is_64bar) {
+                bar_data_upper = pci_readl(devfn, bar_reg + 4);
+                pci_writel(devfn, bar_reg + 4, ~0);
+                bar_sz_upper = pci_readl(devfn, bar_reg + 4);
+                pci_writel(devfn, bar_reg + 4, bar_data_upper);
+                bar_sz = (bar_sz_upper << 32) | bar_sz;
+            }
             bar_sz &= ~(bar_sz - 1);
+            if ( bar_sz == 0 )
+                continue;
 
             for ( i = 0; i < nr_bars; i++ )
                 if ( bars[i].bar_sz < bar_sz )
@@ -157,6 +175,7 @@
             if ( i != nr_bars )
                 memmove(&bars[i+1], &bars[i], (nr_bars-i) * sizeof(*bars));
 
+            bars[i].is_64bar = is_64bar;
             bars[i].devfn   = devfn;
             bars[i].bar_reg = bar_reg;
             bars[i].bar_sz  = bar_sz;
@@ -167,11 +186,8 @@
 
             nr_bars++;
 
-            /* Skip the upper-half of the address for a 64-bit BAR. */
-            if ( (bar_data & (PCI_BASE_ADDRESS_SPACE |
-                              PCI_BASE_ADDRESS_MEM_TYPE_MASK)) == 
-                 (PCI_BASE_ADDRESS_SPACE_MEMORY | 
-                  PCI_BASE_ADDRESS_MEM_TYPE_64) )
+            /*The upper half is already calculated, skip it! */
+            if (is_64bar)
                 bar++;
         }
 
@@ -197,6 +213,9 @@
             ((pci_mem_start << 1) != 0) )
         pci_mem_start <<= 1;
 
+    if ( (pci_mem_start << 1) != 0 )
+        bar64_relocate = 1;
+
     /* Relocate RAM that overlaps PCI space (in 64k-page chunks). */
     while ( (pci_mem_start >> PAGE_SHIFT) < hvm_info->low_mem_pgend )
     {
@@ -218,11 +237,15 @@
         hvm_info->high_mem_pgend += nr_pages;
     }
 
+    high_mem_resource.base = ((uint64_t)hvm_info->high_mem_pgend) << PAGE_SHIFT; 
+    high_mem_resource.max = 1ull << cpu_phys_addr();
     mem_resource.base = pci_mem_start;
     mem_resource.max = pci_mem_end;
     io_resource.base = 0xc000;
     io_resource.max = 0x10000;
 
+    mmio_left = pci_mem_end - pci_mem_start;
+
     /* Assign iomem and ioport resources in descending order of size. */
     for ( i = 0; i < nr_bars; i++ )
     {
@@ -230,13 +253,29 @@
         bar_reg = bars[i].bar_reg;
         bar_sz  = bars[i].bar_sz;
 
+        using_64bar = bars[i].is_64bar && bar64_relocate && (mmio_left < bar_sz);
         bar_data = pci_readl(devfn, bar_reg);
 
         if ( (bar_data & PCI_BASE_ADDRESS_SPACE) ==
              PCI_BASE_ADDRESS_SPACE_MEMORY )
         {
-            resource = &mem_resource;
-            bar_data &= ~PCI_BASE_ADDRESS_MEM_MASK;
+            /* Mapping high memory if PCI deivce is 64 bits bar and the bar size
+               is larger than 512M */
+            if (using_64bar && (bar_sz > PCI_MIN_BIG_BAR_SIZE)) {
+                if ( high_mem_resource.base & (bar_sz - 1) )
+                    high_mem_resource.base = high_mem_resource.base - 
+                        (high_mem_resource.base & (bar_sz - 1)) + bar_sz;
+                else
+                    high_mem_resource.base = high_mem_resource.base - 
+                        (high_mem_resource.base & (bar_sz - 1));
+                resource = &high_mem_resource;
+                bar_data &= ~PCI_BASE_ADDRESS_MEM_MASK;
+            } 
+            else {
+                resource = &mem_resource;
+                bar_data &= ~PCI_BASE_ADDRESS_MEM_MASK;
+            }
+            mmio_left -= bar_sz;
         }
         else
         {
@@ -244,13 +283,14 @@
             bar_data &= ~PCI_BASE_ADDRESS_IO_MASK;
         }
 
-        base = (resource->base + bar_sz - 1) & ~(bar_sz - 1);
-        bar_data |= base;
+        base = (resource->base  + bar_sz - 1) & ~(uint64_t)(bar_sz - 1);
+        bar_data |= (uint32_t)base;
+        bar_data_upper = (uint32_t)(base >> 32);
         base += bar_sz;
 
         if ( (base < resource->base) || (base > resource->max) )
         {
-            printf("pci dev %02x:%x bar %02x size %08x: no space for "
+            printf("pci dev %02x:%x bar %02x size %llx: no space for "
                    "resource!\n", devfn>>3, devfn&7, bar_reg, bar_sz);
             continue;
         }
@@ -258,8 +298,8 @@
         resource->base = base;
 
         pci_writel(devfn, bar_reg, bar_data);
-        printf("pci dev %02x:%x bar %02x size %08x: %08x\n",
-               devfn>>3, devfn&7, bar_reg, bar_sz, bar_data);
+        if (using_64bar)
+            pci_writel(devfn, bar_reg + 4, bar_data_upper);
 
         /* Now enable the memory or I/O mapping. */
         cmd = pci_readw(devfn, PCI_COMMAND);
diff -r dc56a9defa30 tools/firmware/hvmloader/util.h
--- a/tools/firmware/hvmloader/util.h	Tue Aug 14 10:28:14 2012 +0200
+++ b/tools/firmware/hvmloader/util.h	Wed Sep 12 14:50:55 2012 +0800
@@ -215,6 +215,7 @@
 uint32_t rombios_highbios_setup(void);
 
 /* Miscellaneous. */
+unsigned int cpu_phys_addr(void);
 void cacheattr_init(void);
 unsigned long create_mp_tables(void *table);
 void hvm_write_smbios_tables(

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 25 07:59:40 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 07:59:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGQ2z-0005Ya-36; Tue, 25 Sep 2012 07:59:13 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72) id 1TGLqI-0002vH-K6
	for xen-devel@lists.xen.org; Tue, 25 Sep 2012 03:29:50 +0000
Received: from [85.158.143.35:12905] by server-3.bemta-4.messagelabs.com id
	0E/3E-10986-D2521605; Tue, 25 Sep 2012 03:29:49 +0000
X-Msg-Ref: server-2.tower-21.messagelabs.com!1348543788!8718747!1
X-Originating-IP: [143.182.124.21]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMjEgPT4gMjA4MDE1\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30139 invoked from network); 25 Sep 2012 03:29:48 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (143.182.124.21)
	by server-2.tower-21.messagelabs.com with SMTP;
	25 Sep 2012 03:29:48 -0000
Received: from azsmga001.ch.intel.com ([10.2.17.19])
	by azsmga101.ch.intel.com with ESMTP; 24 Sep 2012 20:29:46 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.80,478,1344236400"; d="scan'208";a="196655038"
Received: from xhao-dev.sh.intel.com (HELO localhost.localdomain)
	([10.239.48.48])
	by azsmga001.ch.intel.com with ESMTP; 24 Sep 2012 20:29:45 -0700
From: 
To: ian.jackson@eu.citrix.com
Date: Tue, 25 Sep 2012 11:33:18 +0800
Message-Id: <1348543998-31304-1-git-send-email-xudong.hao@intel.com>
X-Mailer: git-send-email 1.5.5
X-Mailman-Approved-At: Tue, 25 Sep 2012 07:59:11 +0000
Cc: ian.campbell@citrix.com, stefano.stabellini@eu.citrix.com,
	Xudong Hao <xudong.hao@intel.com>, xen-devel@lists.xen.org,
	jbeulich@suse.com, Xiantao Zhang <xiantao.zhang@intel.com>
Subject: [Xen-devel] [PATCH v2] xen/tools: Add 64 bits big bar 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

Currently it is assumed PCI device BAR access < 4G memory. If there is such a
device whose BAR size is larger than 4G, it must access > 4G memory address.
This patch enable the 64bits big BAR support on hvmloader.

Changes from v1:
1) Set Dynamic MMIO high memory address instead of a fixed number 640G
2) Mask bar_sz earlier to avoid older code changes
3) Add bar size barrier to judge high memory resource
4) Clean up bar64_relocate code

Signed-off-by: Xiantao Zhang <xiantao.zhang@intel.com>
Signed-off-by: Xudong Hao <xudong.hao@intel.com>

diff -r dc56a9defa30 tools/firmware/hvmloader/cacheattr.c
--- a/tools/firmware/hvmloader/cacheattr.c	Tue Aug 14 10:28:14 2012 +0200
+++ b/tools/firmware/hvmloader/cacheattr.c	Wed Sep 12 14:50:55 2012 +0800
@@ -40,17 +40,10 @@
 #define MSR_PAT              0x0277
 #define MSR_MTRRdefType      0x02ff
 
-void cacheattr_init(void)
+unsigned int cpu_phys_addr(void)
 {
     uint32_t eax, ebx, ecx, edx;
-    uint64_t mtrr_cap, mtrr_def, content, addr_mask;
-    unsigned int i, nr_var_ranges, phys_bits = 36;
-
-    /* Does the CPU support architectural MTRRs? */
-    cpuid(0x00000001, &eax, &ebx, &ecx, &edx);
-    if ( !(edx & (1u << 12)) )
-         return;
-
+    unsigned int phys_bits = 36;
     /* Find the physical address size for this CPU. */
     cpuid(0x80000000, &eax, &ebx, &ecx, &edx);
     if ( eax >= 0x80000008 )
@@ -59,6 +52,22 @@
         phys_bits = (uint8_t)eax;
     }
 
+    return phys_bits;
+}
+
+void cacheattr_init(void)
+{
+    uint32_t eax, ebx, ecx, edx;
+    uint64_t mtrr_cap, mtrr_def, content, addr_mask;
+    unsigned int i, nr_var_ranges, phys_bits;
+
+    /* Does the CPU support architectural MTRRs? */
+    cpuid(0x00000001, &eax, &ebx, &ecx, &edx);
+    if ( !(edx & (1u << 12)) )
+         return;
+
+    phys_bits = cpu_phys_addr();
+
     printf("%u-bit phys ... ", phys_bits);
 
     addr_mask = ((1ull << phys_bits) - 1) & ~((1ull << 12) - 1);
diff -r dc56a9defa30 tools/firmware/hvmloader/config.h
--- a/tools/firmware/hvmloader/config.h	Tue Aug 14 10:28:14 2012 +0200
+++ b/tools/firmware/hvmloader/config.h	Wed Sep 12 14:50:55 2012 +0800
@@ -53,6 +53,8 @@
 /* MMIO hole: Hardcoded defaults, which can be dynamically expanded. */
 #define PCI_MEM_START       0xf0000000
 #define PCI_MEM_END         0xfc000000
+#define PCI_MIN_BIG_BAR_SIZE          0x20000000
+
 extern unsigned long pci_mem_start, pci_mem_end;
 
 
diff -r dc56a9defa30 tools/firmware/hvmloader/pci.c
--- a/tools/firmware/hvmloader/pci.c	Tue Aug 14 10:28:14 2012 +0200
+++ b/tools/firmware/hvmloader/pci.c	Wed Sep 12 14:50:55 2012 +0800
@@ -36,19 +36,25 @@
 
 void pci_setup(void)
 {
-    uint32_t base, devfn, bar_reg, bar_data, bar_sz, cmd, mmio_total = 0;
+    uint8_t is_64bar, using_64bar, bar64_relocate = 0;
+    uint32_t devfn, bar_reg, cmd, bar_data, bar_data_upper;
+    uint64_t base, bar_sz, bar_sz_upper, mmio_total = 0;
     uint32_t vga_devfn = 256;
     uint16_t class, vendor_id, device_id;
     unsigned int bar, pin, link, isa_irq;
+    int64_t mmio_left;
 
     /* Resources assignable to PCI devices via BARs. */
     struct resource {
-        uint32_t base, max;
-    } *resource, mem_resource, io_resource;
+        uint64_t base, max;
+    } *resource, mem_resource, high_mem_resource, io_resource;
 
     /* Create a list of device BARs in descending order of size. */
     struct bars {
-        uint32_t devfn, bar_reg, bar_sz;
+        uint32_t is_64bar;
+        uint32_t devfn;
+        uint32_t bar_reg;
+        uint64_t bar_sz;
     } *bars = (struct bars *)scratch_start;
     unsigned int i, nr_bars = 0;
 
@@ -133,22 +139,34 @@
         /* Map the I/O memory and port resources. */
         for ( bar = 0; bar < 7; bar++ )
         {
+            bar_sz_upper = 0;
             bar_reg = PCI_BASE_ADDRESS_0 + 4*bar;
             if ( bar == 6 )
                 bar_reg = PCI_ROM_ADDRESS;
 
             bar_data = pci_readl(devfn, bar_reg);
+            is_64bar = !!((bar_data & (PCI_BASE_ADDRESS_SPACE |
+                         PCI_BASE_ADDRESS_MEM_TYPE_MASK)) ==
+                         (PCI_BASE_ADDRESS_SPACE_MEMORY |
+                         PCI_BASE_ADDRESS_MEM_TYPE_64));
             pci_writel(devfn, bar_reg, ~0);
             bar_sz = pci_readl(devfn, bar_reg);
             pci_writel(devfn, bar_reg, bar_data);
-            if ( bar_sz == 0 )
-                continue;
 
             bar_sz &= (((bar_data & PCI_BASE_ADDRESS_SPACE) ==
                         PCI_BASE_ADDRESS_SPACE_MEMORY) ?
                        PCI_BASE_ADDRESS_MEM_MASK :
                        (PCI_BASE_ADDRESS_IO_MASK & 0xffff));
+            if (is_64bar) {
+                bar_data_upper = pci_readl(devfn, bar_reg + 4);
+                pci_writel(devfn, bar_reg + 4, ~0);
+                bar_sz_upper = pci_readl(devfn, bar_reg + 4);
+                pci_writel(devfn, bar_reg + 4, bar_data_upper);
+                bar_sz = (bar_sz_upper << 32) | bar_sz;
+            }
             bar_sz &= ~(bar_sz - 1);
+            if ( bar_sz == 0 )
+                continue;
 
             for ( i = 0; i < nr_bars; i++ )
                 if ( bars[i].bar_sz < bar_sz )
@@ -157,6 +175,7 @@
             if ( i != nr_bars )
                 memmove(&bars[i+1], &bars[i], (nr_bars-i) * sizeof(*bars));
 
+            bars[i].is_64bar = is_64bar;
             bars[i].devfn   = devfn;
             bars[i].bar_reg = bar_reg;
             bars[i].bar_sz  = bar_sz;
@@ -167,11 +186,8 @@
 
             nr_bars++;
 
-            /* Skip the upper-half of the address for a 64-bit BAR. */
-            if ( (bar_data & (PCI_BASE_ADDRESS_SPACE |
-                              PCI_BASE_ADDRESS_MEM_TYPE_MASK)) == 
-                 (PCI_BASE_ADDRESS_SPACE_MEMORY | 
-                  PCI_BASE_ADDRESS_MEM_TYPE_64) )
+            /*The upper half is already calculated, skip it! */
+            if (is_64bar)
                 bar++;
         }
 
@@ -197,6 +213,9 @@
             ((pci_mem_start << 1) != 0) )
         pci_mem_start <<= 1;
 
+    if ( (pci_mem_start << 1) != 0 )
+        bar64_relocate = 1;
+
     /* Relocate RAM that overlaps PCI space (in 64k-page chunks). */
     while ( (pci_mem_start >> PAGE_SHIFT) < hvm_info->low_mem_pgend )
     {
@@ -218,11 +237,15 @@
         hvm_info->high_mem_pgend += nr_pages;
     }
 
+    high_mem_resource.base = ((uint64_t)hvm_info->high_mem_pgend) << PAGE_SHIFT; 
+    high_mem_resource.max = 1ull << cpu_phys_addr();
     mem_resource.base = pci_mem_start;
     mem_resource.max = pci_mem_end;
     io_resource.base = 0xc000;
     io_resource.max = 0x10000;
 
+    mmio_left = pci_mem_end - pci_mem_start;
+
     /* Assign iomem and ioport resources in descending order of size. */
     for ( i = 0; i < nr_bars; i++ )
     {
@@ -230,13 +253,29 @@
         bar_reg = bars[i].bar_reg;
         bar_sz  = bars[i].bar_sz;
 
+        using_64bar = bars[i].is_64bar && bar64_relocate && (mmio_left < bar_sz);
         bar_data = pci_readl(devfn, bar_reg);
 
         if ( (bar_data & PCI_BASE_ADDRESS_SPACE) ==
              PCI_BASE_ADDRESS_SPACE_MEMORY )
         {
-            resource = &mem_resource;
-            bar_data &= ~PCI_BASE_ADDRESS_MEM_MASK;
+            /* Mapping high memory if PCI deivce is 64 bits bar and the bar size
+               is larger than 512M */
+            if (using_64bar && (bar_sz > PCI_MIN_BIG_BAR_SIZE)) {
+                if ( high_mem_resource.base & (bar_sz - 1) )
+                    high_mem_resource.base = high_mem_resource.base - 
+                        (high_mem_resource.base & (bar_sz - 1)) + bar_sz;
+                else
+                    high_mem_resource.base = high_mem_resource.base - 
+                        (high_mem_resource.base & (bar_sz - 1));
+                resource = &high_mem_resource;
+                bar_data &= ~PCI_BASE_ADDRESS_MEM_MASK;
+            } 
+            else {
+                resource = &mem_resource;
+                bar_data &= ~PCI_BASE_ADDRESS_MEM_MASK;
+            }
+            mmio_left -= bar_sz;
         }
         else
         {
@@ -244,13 +283,14 @@
             bar_data &= ~PCI_BASE_ADDRESS_IO_MASK;
         }
 
-        base = (resource->base + bar_sz - 1) & ~(bar_sz - 1);
-        bar_data |= base;
+        base = (resource->base  + bar_sz - 1) & ~(uint64_t)(bar_sz - 1);
+        bar_data |= (uint32_t)base;
+        bar_data_upper = (uint32_t)(base >> 32);
         base += bar_sz;
 
         if ( (base < resource->base) || (base > resource->max) )
         {
-            printf("pci dev %02x:%x bar %02x size %08x: no space for "
+            printf("pci dev %02x:%x bar %02x size %llx: no space for "
                    "resource!\n", devfn>>3, devfn&7, bar_reg, bar_sz);
             continue;
         }
@@ -258,8 +298,8 @@
         resource->base = base;
 
         pci_writel(devfn, bar_reg, bar_data);
-        printf("pci dev %02x:%x bar %02x size %08x: %08x\n",
-               devfn>>3, devfn&7, bar_reg, bar_sz, bar_data);
+        if (using_64bar)
+            pci_writel(devfn, bar_reg + 4, bar_data_upper);
 
         /* Now enable the memory or I/O mapping. */
         cmd = pci_readw(devfn, PCI_COMMAND);
diff -r dc56a9defa30 tools/firmware/hvmloader/util.h
--- a/tools/firmware/hvmloader/util.h	Tue Aug 14 10:28:14 2012 +0200
+++ b/tools/firmware/hvmloader/util.h	Wed Sep 12 14:50:55 2012 +0800
@@ -215,6 +215,7 @@
 uint32_t rombios_highbios_setup(void);
 
 /* Miscellaneous. */
+unsigned int cpu_phys_addr(void);
 void cacheattr_init(void);
 unsigned long create_mp_tables(void *table);
 void hvm_write_smbios_tables(

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 25 08:02:29 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 08:02:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGQ5j-000653-O3; Tue, 25 Sep 2012 08:02:03 +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 1TGQ5h-00064x-OW
	for xen-devel@lists.xen.org; Tue, 25 Sep 2012 08:02:02 +0000
Received: from [85.158.138.51:20226] by server-6.bemta-3.messagelabs.com id
	4E/28-29694-8F461605; Tue, 25 Sep 2012 08:02:00 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-3.tower-174.messagelabs.com!1348560119!23769499!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA1MTI5Mzc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12287 invoked from network); 25 Sep 2012 08:02:00 -0000
Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25)
	by server-3.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 25 Sep 2012 08:02:00 -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 479AA18F6;
	Tue, 25 Sep 2012 11:01:58 +0300 (EEST)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id 3B86E20061; Tue, 25 Sep 2012 11:01:58 +0300 (EEST)
Date: Tue, 25 Sep 2012 11:01:57 +0300
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: Andi Reinbrech <andi.reinbrech@darwinistic.com>
Message-ID: <20120925080157.GL8912@reaktio.net>
References: <506158C5.6000302@darwinistic.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <506158C5.6000302@darwinistic.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] 4.2 kernel 3.5 USB PCI Passthrough
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Sep 25, 2012 at 09:09:57AM +0200, Andi Reinbrech wrote:
> Hi Xenners,
> 
> I have been using 4.2 for a very long time now, and recently (since
> upgrading to rc2), I've had some strange issues cropping up:
> 
> None of my disk images boot with xl create;  I have moved the
> important ones to LVM disks, since phy: boots fine.  I have hacked
> some of the xen code to make this work (but forgot which hack got it
> working, it has to do with the caching modes in the file open calls
> - I will double check and get back to the list).  My qemu disks are
> always reported as 0mb-sized volumes in the BIOS screen when this
> bug manifests itself.  Neither raw nor qcow2 images work.
>

I think there was fixes/changes to Xen qemu-dm caching modes
during the late 4.2-rc's. 
 
> When I upgraded to kernel 3.5, my USB PCI passthrough stopped
> working.  The secondary VGA passthrough still works fine, just the
> USB host controller that is passed through gets claimed by xen, but
> the guest cannot load drivers for the controller.  I.e. the guest
> (Windoze 7) sees it in device manager, but the device fails to
> activate.
> 

Any errors in dom0 dmesg or in xen dmesg? 

> Last night I upgraded to the latest 3.5.4 in the fc17 repo, and the
> USB issue was still there.  The weird thing though, is that it seems
> that my raw images magically started booting.  I still need to
> investigate this, in more detail to make sure I'm not mixing up
> versions and get conclusive results.
> 

Did you upgrade Xen to 4.2.0 final at the same time? 

> Apologies, this post is not too detailed and contains too many
> "maybes", but I though there may be a simple answer that someone
> else had stumbled across the same issues recently.
> 
> I will compile rc3 later on and run decent comparisons on both
> kernels, as well as raw and LVM machines.
> 

You probably should post a different thread for each problem..

-- Pasi


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 25 08:02:29 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 08:02:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGQ5j-000653-O3; Tue, 25 Sep 2012 08:02:03 +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 1TGQ5h-00064x-OW
	for xen-devel@lists.xen.org; Tue, 25 Sep 2012 08:02:02 +0000
Received: from [85.158.138.51:20226] by server-6.bemta-3.messagelabs.com id
	4E/28-29694-8F461605; Tue, 25 Sep 2012 08:02:00 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-3.tower-174.messagelabs.com!1348560119!23769499!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA1MTI5Mzc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12287 invoked from network); 25 Sep 2012 08:02:00 -0000
Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25)
	by server-3.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 25 Sep 2012 08:02:00 -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 479AA18F6;
	Tue, 25 Sep 2012 11:01:58 +0300 (EEST)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id 3B86E20061; Tue, 25 Sep 2012 11:01:58 +0300 (EEST)
Date: Tue, 25 Sep 2012 11:01:57 +0300
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: Andi Reinbrech <andi.reinbrech@darwinistic.com>
Message-ID: <20120925080157.GL8912@reaktio.net>
References: <506158C5.6000302@darwinistic.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <506158C5.6000302@darwinistic.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] 4.2 kernel 3.5 USB PCI Passthrough
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Sep 25, 2012 at 09:09:57AM +0200, Andi Reinbrech wrote:
> Hi Xenners,
> 
> I have been using 4.2 for a very long time now, and recently (since
> upgrading to rc2), I've had some strange issues cropping up:
> 
> None of my disk images boot with xl create;  I have moved the
> important ones to LVM disks, since phy: boots fine.  I have hacked
> some of the xen code to make this work (but forgot which hack got it
> working, it has to do with the caching modes in the file open calls
> - I will double check and get back to the list).  My qemu disks are
> always reported as 0mb-sized volumes in the BIOS screen when this
> bug manifests itself.  Neither raw nor qcow2 images work.
>

I think there was fixes/changes to Xen qemu-dm caching modes
during the late 4.2-rc's. 
 
> When I upgraded to kernel 3.5, my USB PCI passthrough stopped
> working.  The secondary VGA passthrough still works fine, just the
> USB host controller that is passed through gets claimed by xen, but
> the guest cannot load drivers for the controller.  I.e. the guest
> (Windoze 7) sees it in device manager, but the device fails to
> activate.
> 

Any errors in dom0 dmesg or in xen dmesg? 

> Last night I upgraded to the latest 3.5.4 in the fc17 repo, and the
> USB issue was still there.  The weird thing though, is that it seems
> that my raw images magically started booting.  I still need to
> investigate this, in more detail to make sure I'm not mixing up
> versions and get conclusive results.
> 

Did you upgrade Xen to 4.2.0 final at the same time? 

> Apologies, this post is not too detailed and contains too many
> "maybes", but I though there may be a simple answer that someone
> else had stumbled across the same issues recently.
> 
> I will compile rc3 later on and run decent comparisons on both
> kernels, as well as raw and LVM machines.
> 

You probably should post a different thread for each problem..

-- Pasi


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 25 08:21:37 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 08: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 1TGQOG-0006Lo-Fk; Tue, 25 Sep 2012 08:21: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 1TGQOE-0006Lg-9p
	for xen-devel@lists.xen.org; Tue, 25 Sep 2012 08:21:10 +0000
Received: from [85.158.138.51:26544] by server-9.bemta-3.messagelabs.com id
	33/15-15390-57961605; Tue, 25 Sep 2012 08:21:09 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1348561268!13176100!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTA5ODg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8271 invoked from network); 25 Sep 2012 08:21:09 -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;
	25 Sep 2012 08:21:09 -0000
X-IronPort-AV: E=Sophos;i="4.80,479,1344211200"; d="scan'208";a="14741037"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Sep 2012 08:20: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.279.1;
	Tue, 25 Sep 2012 09:20:56 +0100
Message-ID: <1348561254.3452.103.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Date: Tue, 25 Sep 2012 09:20:54 +0100
In-Reply-To: <506095D3.8090907@citrix.com>
References: <50607CCF.9050904@overnetdata.com> <506095D3.8090907@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Anthony Wright <anthony@overnetdata.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] First DomU started goes into a busy loop
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

(putting Anthony back on the CC)

On Mon, 2012-09-24 at 18:18 +0100, Andrew Cooper wrote:
> 32bit builds of Xen have been removed from 4.3.  As far as I am aware,
> there has been no serious effort to maintain them.  I highly suggest
> using a 64bit Xen.

Anthony's references to 32-bit all seem to be in the context of the
Linux kernel.

Just to be clear we have removed support for the 32-bit hypervisor only.
We have not and will not be removing support for 32-bit (PAE) PV
domains, running as either guest or dom0 on a 64-bit hypervisor. 32-bit
HVM guests, with or without PAE enabled, also remain fully supported.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 25 08:21:37 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 08: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 1TGQOG-0006Lo-Fk; Tue, 25 Sep 2012 08:21: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 1TGQOE-0006Lg-9p
	for xen-devel@lists.xen.org; Tue, 25 Sep 2012 08:21:10 +0000
Received: from [85.158.138.51:26544] by server-9.bemta-3.messagelabs.com id
	33/15-15390-57961605; Tue, 25 Sep 2012 08:21:09 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1348561268!13176100!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTA5ODg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8271 invoked from network); 25 Sep 2012 08:21:09 -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;
	25 Sep 2012 08:21:09 -0000
X-IronPort-AV: E=Sophos;i="4.80,479,1344211200"; d="scan'208";a="14741037"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Sep 2012 08:20: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.279.1;
	Tue, 25 Sep 2012 09:20:56 +0100
Message-ID: <1348561254.3452.103.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Date: Tue, 25 Sep 2012 09:20:54 +0100
In-Reply-To: <506095D3.8090907@citrix.com>
References: <50607CCF.9050904@overnetdata.com> <506095D3.8090907@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Anthony Wright <anthony@overnetdata.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] First DomU started goes into a busy loop
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

(putting Anthony back on the CC)

On Mon, 2012-09-24 at 18:18 +0100, Andrew Cooper wrote:
> 32bit builds of Xen have been removed from 4.3.  As far as I am aware,
> there has been no serious effort to maintain them.  I highly suggest
> using a 64bit Xen.

Anthony's references to 32-bit all seem to be in the context of the
Linux kernel.

Just to be clear we have removed support for the 32-bit hypervisor only.
We have not and will not be removing support for 32-bit (PAE) PV
domains, running as either guest or dom0 on a 64-bit hypervisor. 32-bit
HVM guests, with or without PAE enabled, also remain fully supported.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 25 08:23:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 08:23:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGQPq-0006QW-43; Tue, 25 Sep 2012 08:22:50 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1TGQPo-0006QI-Tq
	for xen-devel@lists.xensource.com; Tue, 25 Sep 2012 08:22:49 +0000
Received: from [85.158.143.35:44694] by server-2.bemta-4.messagelabs.com id
	93/72-06610-7D961605; Tue, 25 Sep 2012 08:22:47 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1348561356!12621010!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTA5ODg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15916 invoked from network); 25 Sep 2012 08:22:36 -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;
	25 Sep 2012 08:22:36 -0000
X-IronPort-AV: E=Sophos;i="4.80,479,1344211200"; d="scan'208";a="14741094"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Sep 2012 08:22:36 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Tue, 25 Sep 2012 09:22:36 +0100
Message-ID: <1348561354.3452.105.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "lars.kurth@xen.org" <lars.kurth@xen.org>
Date: Tue, 25 Sep 2012 09:22:34 +0100
In-Reply-To: <50607A68.2090604@xen.org>
References: <CAGnmK4wB3ZJ3Tb9-VFgWCkcZNwibDzRYV8tvb14vLgw1wj2awQ@mail.gmail.com>
	<50607A68.2090604@xen.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Grant McWilliams <grantmasterflash@gmail.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"xen-api@lists.xensource.com" <xen-api@lists.xensource.com>
Subject: Re: [Xen-devel] Proposal - Add xe manpages to xen-org
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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-09-24 at 16:21 +0100, Lars Kurth wrote:
> On 24/09/2012 16:06, Grant McWilliams wrote:
> > Xen Community,
> >
> >     I have a team of people frantically creating manpages for the xe 
> > command and all of it's 361 subcommands. The initial source 
> > documentation is in asciidoc but also saved as Docbook. From docbook 
> > we transform to epub, html, manpage and pdf. This is currently being 
> > hosted in a subversion server at a Seattle area college and we'd like 
> > to move it to the xen-org github so it's public, can be reviewed, 
> > commented on and contributed too.

IME the best way to ensure that documentation remains current as the
code base changes is to check it in next to the code in the same repo.

This requires a little bit of discipline from the maintainers, to
remember to request appropriate docs updates when code patches require
them, but has been pretty effective e.g. for the xen-unstable code base.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 25 08:23:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 08:23:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGQPq-0006QW-43; Tue, 25 Sep 2012 08:22:50 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1TGQPo-0006QI-Tq
	for xen-devel@lists.xensource.com; Tue, 25 Sep 2012 08:22:49 +0000
Received: from [85.158.143.35:44694] by server-2.bemta-4.messagelabs.com id
	93/72-06610-7D961605; Tue, 25 Sep 2012 08:22:47 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1348561356!12621010!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTA5ODg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15916 invoked from network); 25 Sep 2012 08:22:36 -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;
	25 Sep 2012 08:22:36 -0000
X-IronPort-AV: E=Sophos;i="4.80,479,1344211200"; d="scan'208";a="14741094"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Sep 2012 08:22:36 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Tue, 25 Sep 2012 09:22:36 +0100
Message-ID: <1348561354.3452.105.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "lars.kurth@xen.org" <lars.kurth@xen.org>
Date: Tue, 25 Sep 2012 09:22:34 +0100
In-Reply-To: <50607A68.2090604@xen.org>
References: <CAGnmK4wB3ZJ3Tb9-VFgWCkcZNwibDzRYV8tvb14vLgw1wj2awQ@mail.gmail.com>
	<50607A68.2090604@xen.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Grant McWilliams <grantmasterflash@gmail.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"xen-api@lists.xensource.com" <xen-api@lists.xensource.com>
Subject: Re: [Xen-devel] Proposal - Add xe manpages to xen-org
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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-09-24 at 16:21 +0100, Lars Kurth wrote:
> On 24/09/2012 16:06, Grant McWilliams wrote:
> > Xen Community,
> >
> >     I have a team of people frantically creating manpages for the xe 
> > command and all of it's 361 subcommands. The initial source 
> > documentation is in asciidoc but also saved as Docbook. From docbook 
> > we transform to epub, html, manpage and pdf. This is currently being 
> > hosted in a subversion server at a Seattle area college and we'd like 
> > to move it to the xen-org github so it's public, can be reviewed, 
> > commented on and contributed too.

IME the best way to ensure that documentation remains current as the
code base changes is to check it in next to the code in the same repo.

This requires a little bit of discipline from the maintainers, to
remember to request appropriate docs updates when code patches require
them, but has been pretty effective e.g. for the xen-unstable code base.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 25 08:23:53 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 08:23: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 1TGQQa-0006WD-MY; Tue, 25 Sep 2012 08:23: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 1TGQQZ-0006Vp-G2
	for xen-devel@lists.xensource.com; Tue, 25 Sep 2012 08:23:35 +0000
Received: from [85.158.143.35:24503] by server-2.bemta-4.messagelabs.com id
	B7/04-06610-60A61605; Tue, 25 Sep 2012 08:23:34 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1348561329!19748840!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTA5ODg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9385 invoked from network); 25 Sep 2012 08:22:09 -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;
	25 Sep 2012 08:22:09 -0000
X-IronPort-AV: E=Sophos;i="4.80,479,1344211200"; d="scan'208";a="14741080"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Sep 2012 08:22: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.279.1;
	Tue, 25 Sep 2012 09:22:08 +0100
Message-ID: <1348561327.3452.104.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Bruce Granger <vivagin@yeah.net>
Date: Tue, 25 Sep 2012 09:22:07 +0100
In-Reply-To: <1348506563655-5711480.post@n5.nabble.com>
References: <1348506563655-5711480.post@n5.nabble.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] How could Xen know a certain GuestOS have already
 shutdown?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gTW9uLCAyMDEyLTA5LTI0IGF0IDE4OjA5ICswMTAwLCBCcnVjZSBHcmFuZ2VyIHdyb3RlOgo+
IEhpIGV2ZXJ5b25lISBUaGlzIGlzIHByb2JhYmx5IGEgZmFtaWxpYXIgcHJvYmxlbSwKPiAgYnV0
IEkgaGF2ZW4ndCBmb3VuZCBhbnl0aGluZyBpbiB0aGUgYXJjaGl2ZXMgb3IgZnJvbSBnb29nbGUg
eWV0LiAKPiBJIGFsc28gdGFsa2VkIHdpdGggbXkgcGFydGVybmVycyBidXQgd2UgaGF2ZW4ndCBn
b3QgYSBzdXJlIGNvbmNsdXNpb24uCj4gUmVjZW50bHkgSeKAmW0gY2FyaW5nIGFib3V0IGEgcXVl
c3Rpb24gYWJvdXQgc2h1dGRvd24gb3BlcmF0aW9uOiBXaGVuIHdlCj4gc2h1dGRvd24gYSBHdWVz
dE9TIGJ5IGdpdmluZyB0aGUgY29tbWFuZCBpbiBpdHMgdGVybWluYWwsIGhvdyBjYW4gaHlwZXJ2
aXNvcgo+IGdldCB0byBrbm93IHRoYXQgdGhpcyBHdWVzdE9TIGlzIGFib3V0IHRvIHNodXRkb3du
IGFuZCBIb3cgY2FuIGh5cGVydmlzb3IKPiBrbm93IHRoYXQgR3Vlc3RPUyBoYXMgYWxyZWFkeSBk
b25lIHRoZSB3b3JrIG9mIHNodXRkb3duPyAKPiAgCj4gSSd2ZSB0cmFjZWQgdGhlIFZJUlFfRE9N
X0VYQyB3aGljaCBzZW5kIGZyb20gWGVuIHRvIERvbTAgYW5kIHBpY2tlZCB1cCBieQo+IHhlbnN0
b3JlZCB3aGljaCBmaXJlcyB0aGUgQHJlbGVhc2VEb21haW4gd2F0Y2ggd2hlbiBhIEd1ZXN0T1Mg
c3RhcnQgdG8KPiBzaHV0ZG93bi4gCj4gCj4gSGVyZSwgSSBzdGlsbCBoYXZlIHR3byBxdWVzdGlv
bnMuIAo+IEZpcnN0LCBJIGhhdmVuJ3QgZm91bmQgYW55dGhpbmcgdXNlZnVsIGluIHRoZSBhcmNo
aXZlcyBhYm91dCAncmVsZWFzZURvbWFpbgo+IHdhdGNoJy5XaGF0IGlzIHRoZSBjYWxsZWQgJ0By
ZWxlYXNlRG9tYWluJyA/IHdoYXQncyB0aGUgdXNlIG9mIGl0PyAKCkhhdmUgeW91IGdyZXBwZWQg
aW4gdGhlIGFjdHVhbCBjb2RlPwoKPiBTZWNvbmQsSSB0aGluayB0aGF0IFZJUlFfRE9NX0VYQyBp
cyB0aGUgc2lnbmFsIHVzZWQgZm9yIGNvbW11bmljYXRlIGJldHdlZW4KPiBoeXBlcnZpc29yIGFu
ZCBEb20wLiBJIHRhbGtlZCB0aGF0IHdpdGggbXkgcGFydGVybmVyLCB3ZSB0aGluayB0aGF0IHdo
ZW4KPiBzaHV0ZG93biBvY2N1cnMsIEd1ZXN0T1Mgd2lsbCBmaXJzdCBnZXQgaW4gdG91Y2ggd2l0
aCBoeXBlcnZpc29yICx0aGVuIGNhdXNlCj4gdGhlIGNvbW11bmljYXRpb24gYmV0d2VlbiBYZW4g
YW5kIERvbTAgYnkgVklSUV9ET01fRVhDLGlzIHRoYXQgcmlnaHQ/IFdoYXQKPiB3ZSBhbHNvIHdh
bnQgdG8ga25vdyBpcyB3aGVuIHNodXRkb3duIG9wZXJhdGlvbiBvY2N1cnMgaW4gR3Vlc3RPUywg
aG93Cj4gR3Vlc3RPUyBjb21tdW5pY2F0ZSB3aXRoIHRoZSBoeXBlcnZpc29yIGZpcnN0PyBJcyB0
aGVyZSBhbnkgc2lnbmFsIG9yCj4gc29tZWhvdyBldmVudCBkZWxpdmVyeT8gCgpJIGNvdmVyZWQg
dGhpcyBpbiBteSByZXBseSB0byB5b3Ugb24gRnJpZGF5IFNlZSBNZXNzYWdlLUlEOgo8MTM0ODIx
NDg3OS4yNjUwMS42OC5jYW1lbEB6YWthei51ay54ZW5zb3VyY2UuY29tPgoKSWFuLgoKCl9fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fClhlbi1kZXZlbCBtYWls
aW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbi5vcmcKaHR0cDovL2xpc3RzLnhlbi5vcmcveGVu
LWRldmVsCg==

From xen-devel-bounces@lists.xen.org Tue Sep 25 08:23:53 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 08:23: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 1TGQQa-0006WD-MY; Tue, 25 Sep 2012 08:23: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 1TGQQZ-0006Vp-G2
	for xen-devel@lists.xensource.com; Tue, 25 Sep 2012 08:23:35 +0000
Received: from [85.158.143.35:24503] by server-2.bemta-4.messagelabs.com id
	B7/04-06610-60A61605; Tue, 25 Sep 2012 08:23:34 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1348561329!19748840!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTA5ODg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9385 invoked from network); 25 Sep 2012 08:22:09 -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;
	25 Sep 2012 08:22:09 -0000
X-IronPort-AV: E=Sophos;i="4.80,479,1344211200"; d="scan'208";a="14741080"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Sep 2012 08:22: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.279.1;
	Tue, 25 Sep 2012 09:22:08 +0100
Message-ID: <1348561327.3452.104.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Bruce Granger <vivagin@yeah.net>
Date: Tue, 25 Sep 2012 09:22:07 +0100
In-Reply-To: <1348506563655-5711480.post@n5.nabble.com>
References: <1348506563655-5711480.post@n5.nabble.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] How could Xen know a certain GuestOS have already
 shutdown?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gTW9uLCAyMDEyLTA5LTI0IGF0IDE4OjA5ICswMTAwLCBCcnVjZSBHcmFuZ2VyIHdyb3RlOgo+
IEhpIGV2ZXJ5b25lISBUaGlzIGlzIHByb2JhYmx5IGEgZmFtaWxpYXIgcHJvYmxlbSwKPiAgYnV0
IEkgaGF2ZW4ndCBmb3VuZCBhbnl0aGluZyBpbiB0aGUgYXJjaGl2ZXMgb3IgZnJvbSBnb29nbGUg
eWV0LiAKPiBJIGFsc28gdGFsa2VkIHdpdGggbXkgcGFydGVybmVycyBidXQgd2UgaGF2ZW4ndCBn
b3QgYSBzdXJlIGNvbmNsdXNpb24uCj4gUmVjZW50bHkgSeKAmW0gY2FyaW5nIGFib3V0IGEgcXVl
c3Rpb24gYWJvdXQgc2h1dGRvd24gb3BlcmF0aW9uOiBXaGVuIHdlCj4gc2h1dGRvd24gYSBHdWVz
dE9TIGJ5IGdpdmluZyB0aGUgY29tbWFuZCBpbiBpdHMgdGVybWluYWwsIGhvdyBjYW4gaHlwZXJ2
aXNvcgo+IGdldCB0byBrbm93IHRoYXQgdGhpcyBHdWVzdE9TIGlzIGFib3V0IHRvIHNodXRkb3du
IGFuZCBIb3cgY2FuIGh5cGVydmlzb3IKPiBrbm93IHRoYXQgR3Vlc3RPUyBoYXMgYWxyZWFkeSBk
b25lIHRoZSB3b3JrIG9mIHNodXRkb3duPyAKPiAgCj4gSSd2ZSB0cmFjZWQgdGhlIFZJUlFfRE9N
X0VYQyB3aGljaCBzZW5kIGZyb20gWGVuIHRvIERvbTAgYW5kIHBpY2tlZCB1cCBieQo+IHhlbnN0
b3JlZCB3aGljaCBmaXJlcyB0aGUgQHJlbGVhc2VEb21haW4gd2F0Y2ggd2hlbiBhIEd1ZXN0T1Mg
c3RhcnQgdG8KPiBzaHV0ZG93bi4gCj4gCj4gSGVyZSwgSSBzdGlsbCBoYXZlIHR3byBxdWVzdGlv
bnMuIAo+IEZpcnN0LCBJIGhhdmVuJ3QgZm91bmQgYW55dGhpbmcgdXNlZnVsIGluIHRoZSBhcmNo
aXZlcyBhYm91dCAncmVsZWFzZURvbWFpbgo+IHdhdGNoJy5XaGF0IGlzIHRoZSBjYWxsZWQgJ0By
ZWxlYXNlRG9tYWluJyA/IHdoYXQncyB0aGUgdXNlIG9mIGl0PyAKCkhhdmUgeW91IGdyZXBwZWQg
aW4gdGhlIGFjdHVhbCBjb2RlPwoKPiBTZWNvbmQsSSB0aGluayB0aGF0IFZJUlFfRE9NX0VYQyBp
cyB0aGUgc2lnbmFsIHVzZWQgZm9yIGNvbW11bmljYXRlIGJldHdlZW4KPiBoeXBlcnZpc29yIGFu
ZCBEb20wLiBJIHRhbGtlZCB0aGF0IHdpdGggbXkgcGFydGVybmVyLCB3ZSB0aGluayB0aGF0IHdo
ZW4KPiBzaHV0ZG93biBvY2N1cnMsIEd1ZXN0T1Mgd2lsbCBmaXJzdCBnZXQgaW4gdG91Y2ggd2l0
aCBoeXBlcnZpc29yICx0aGVuIGNhdXNlCj4gdGhlIGNvbW11bmljYXRpb24gYmV0d2VlbiBYZW4g
YW5kIERvbTAgYnkgVklSUV9ET01fRVhDLGlzIHRoYXQgcmlnaHQ/IFdoYXQKPiB3ZSBhbHNvIHdh
bnQgdG8ga25vdyBpcyB3aGVuIHNodXRkb3duIG9wZXJhdGlvbiBvY2N1cnMgaW4gR3Vlc3RPUywg
aG93Cj4gR3Vlc3RPUyBjb21tdW5pY2F0ZSB3aXRoIHRoZSBoeXBlcnZpc29yIGZpcnN0PyBJcyB0
aGVyZSBhbnkgc2lnbmFsIG9yCj4gc29tZWhvdyBldmVudCBkZWxpdmVyeT8gCgpJIGNvdmVyZWQg
dGhpcyBpbiBteSByZXBseSB0byB5b3Ugb24gRnJpZGF5IFNlZSBNZXNzYWdlLUlEOgo8MTM0ODIx
NDg3OS4yNjUwMS42OC5jYW1lbEB6YWthei51ay54ZW5zb3VyY2UuY29tPgoKSWFuLgoKCl9fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fClhlbi1kZXZlbCBtYWls
aW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbi5vcmcKaHR0cDovL2xpc3RzLnhlbi5vcmcveGVu
LWRldmVsCg==

From xen-devel-bounces@lists.xen.org Tue Sep 25 08:32:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 08:32:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGQYc-0006sF-L9; Tue, 25 Sep 2012 08:31: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 1TGQYb-0006sA-2o
	for xen-devel@lists.xen.org; Tue, 25 Sep 2012 08:31:53 +0000
Received: from [85.158.143.35:16783] by server-1.bemta-4.messagelabs.com id
	5D/87-05684-8FB61605; Tue, 25 Sep 2012 08:31:52 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1348561911!13898711!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTA5ODg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12250 invoked from network); 25 Sep 2012 08:31:51 -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 Sep 2012 08:31:51 -0000
X-IronPort-AV: E=Sophos;i="4.80,479,1344211200"; d="scan'208";a="14741393"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Sep 2012 08:31: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.279.1;
	Tue, 25 Sep 2012 09:31:51 +0100
Message-ID: <1348561909.3452.108.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Tue, 25 Sep 2012 09:31:49 +0100
In-Reply-To: <1348543998-31304-1-git-send-email-xudong.hao@intel.com>
References: <1348543998-31304-1-git-send-email-xudong.hao@intel.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Xudong Hao <xudong.hao@intel.com>, Xiantao Zhang <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] xen/tools: Add 64 bits big bar 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-09-25 at 04:33 +0100, an unknown sender wrote:
> Currently it is assumed PCI device BAR access < 4G memory. If there is such a
> device whose BAR size is larger than 4G, it must access > 4G memory address.
> This patch enable the 64bits big BAR support on hvmloader.

Does this work in both qemu-xen-traditional/ROMBIOS and qemu-xen/SeaBIOS
configurations? Or does the BIOS not care about this stuff?

Ian

> 
> Changes from v1:
> 1) Set Dynamic MMIO high memory address instead of a fixed number 640G
> 2) Mask bar_sz earlier to avoid older code changes
> 3) Add bar size barrier to judge high memory resource
> 4) Clean up bar64_relocate code
> 
> Signed-off-by: Xiantao Zhang <xiantao.zhang@intel.com>
> Signed-off-by: Xudong Hao <xudong.hao@intel.com>
> 
> diff -r dc56a9defa30 tools/firmware/hvmloader/cacheattr.c
> --- a/tools/firmware/hvmloader/cacheattr.c	Tue Aug 14 10:28:14 2012 +0200
> +++ b/tools/firmware/hvmloader/cacheattr.c	Wed Sep 12 14:50:55 2012 +0800
> @@ -40,17 +40,10 @@
>  #define MSR_PAT              0x0277
>  #define MSR_MTRRdefType      0x02ff
>  
> -void cacheattr_init(void)
> +unsigned int cpu_phys_addr(void)
>  {
>      uint32_t eax, ebx, ecx, edx;
> -    uint64_t mtrr_cap, mtrr_def, content, addr_mask;
> -    unsigned int i, nr_var_ranges, phys_bits = 36;
> -
> -    /* Does the CPU support architectural MTRRs? */
> -    cpuid(0x00000001, &eax, &ebx, &ecx, &edx);
> -    if ( !(edx & (1u << 12)) )
> -         return;
> -
> +    unsigned int phys_bits = 36;
>      /* Find the physical address size for this CPU. */
>      cpuid(0x80000000, &eax, &ebx, &ecx, &edx);
>      if ( eax >= 0x80000008 )
> @@ -59,6 +52,22 @@
>          phys_bits = (uint8_t)eax;
>      }
>  
> +    return phys_bits;
> +}
> +
> +void cacheattr_init(void)
> +{
> +    uint32_t eax, ebx, ecx, edx;
> +    uint64_t mtrr_cap, mtrr_def, content, addr_mask;
> +    unsigned int i, nr_var_ranges, phys_bits;
> +
> +    /* Does the CPU support architectural MTRRs? */
> +    cpuid(0x00000001, &eax, &ebx, &ecx, &edx);
> +    if ( !(edx & (1u << 12)) )
> +         return;
> +
> +    phys_bits = cpu_phys_addr();
> +
>      printf("%u-bit phys ... ", phys_bits);
>  
>      addr_mask = ((1ull << phys_bits) - 1) & ~((1ull << 12) - 1);
> diff -r dc56a9defa30 tools/firmware/hvmloader/config.h
> --- a/tools/firmware/hvmloader/config.h	Tue Aug 14 10:28:14 2012 +0200
> +++ b/tools/firmware/hvmloader/config.h	Wed Sep 12 14:50:55 2012 +0800
> @@ -53,6 +53,8 @@
>  /* MMIO hole: Hardcoded defaults, which can be dynamically expanded. */
>  #define PCI_MEM_START       0xf0000000
>  #define PCI_MEM_END         0xfc000000
> +#define PCI_MIN_BIG_BAR_SIZE          0x20000000
> +
>  extern unsigned long pci_mem_start, pci_mem_end;
>  
> 
> diff -r dc56a9defa30 tools/firmware/hvmloader/pci.c
> --- a/tools/firmware/hvmloader/pci.c	Tue Aug 14 10:28:14 2012 +0200
> +++ b/tools/firmware/hvmloader/pci.c	Wed Sep 12 14:50:55 2012 +0800
> @@ -36,19 +36,25 @@
>  
>  void pci_setup(void)
>  {
> -    uint32_t base, devfn, bar_reg, bar_data, bar_sz, cmd, mmio_total = 0;
> +    uint8_t is_64bar, using_64bar, bar64_relocate = 0;
> +    uint32_t devfn, bar_reg, cmd, bar_data, bar_data_upper;
> +    uint64_t base, bar_sz, bar_sz_upper, mmio_total = 0;
>      uint32_t vga_devfn = 256;
>      uint16_t class, vendor_id, device_id;
>      unsigned int bar, pin, link, isa_irq;
> +    int64_t mmio_left;
>  
>      /* Resources assignable to PCI devices via BARs. */
>      struct resource {
> -        uint32_t base, max;
> -    } *resource, mem_resource, io_resource;
> +        uint64_t base, max;
> +    } *resource, mem_resource, high_mem_resource, io_resource;
>  
>      /* Create a list of device BARs in descending order of size. */
>      struct bars {
> -        uint32_t devfn, bar_reg, bar_sz;
> +        uint32_t is_64bar;
> +        uint32_t devfn;
> +        uint32_t bar_reg;
> +        uint64_t bar_sz;
>      } *bars = (struct bars *)scratch_start;
>      unsigned int i, nr_bars = 0;
>  
> @@ -133,22 +139,34 @@
>          /* Map the I/O memory and port resources. */
>          for ( bar = 0; bar < 7; bar++ )
>          {
> +            bar_sz_upper = 0;
>              bar_reg = PCI_BASE_ADDRESS_0 + 4*bar;
>              if ( bar == 6 )
>                  bar_reg = PCI_ROM_ADDRESS;
>  
>              bar_data = pci_readl(devfn, bar_reg);
> +            is_64bar = !!((bar_data & (PCI_BASE_ADDRESS_SPACE |
> +                         PCI_BASE_ADDRESS_MEM_TYPE_MASK)) ==
> +                         (PCI_BASE_ADDRESS_SPACE_MEMORY |
> +                         PCI_BASE_ADDRESS_MEM_TYPE_64));
>              pci_writel(devfn, bar_reg, ~0);
>              bar_sz = pci_readl(devfn, bar_reg);
>              pci_writel(devfn, bar_reg, bar_data);
> -            if ( bar_sz == 0 )
> -                continue;
>  
>              bar_sz &= (((bar_data & PCI_BASE_ADDRESS_SPACE) ==
>                          PCI_BASE_ADDRESS_SPACE_MEMORY) ?
>                         PCI_BASE_ADDRESS_MEM_MASK :
>                         (PCI_BASE_ADDRESS_IO_MASK & 0xffff));
> +            if (is_64bar) {
> +                bar_data_upper = pci_readl(devfn, bar_reg + 4);
> +                pci_writel(devfn, bar_reg + 4, ~0);
> +                bar_sz_upper = pci_readl(devfn, bar_reg + 4);
> +                pci_writel(devfn, bar_reg + 4, bar_data_upper);
> +                bar_sz = (bar_sz_upper << 32) | bar_sz;
> +            }
>              bar_sz &= ~(bar_sz - 1);
> +            if ( bar_sz == 0 )
> +                continue;
>  
>              for ( i = 0; i < nr_bars; i++ )
>                  if ( bars[i].bar_sz < bar_sz )
> @@ -157,6 +175,7 @@
>              if ( i != nr_bars )
>                  memmove(&bars[i+1], &bars[i], (nr_bars-i) * sizeof(*bars));
>  
> +            bars[i].is_64bar = is_64bar;
>              bars[i].devfn   = devfn;
>              bars[i].bar_reg = bar_reg;
>              bars[i].bar_sz  = bar_sz;
> @@ -167,11 +186,8 @@
>  
>              nr_bars++;
>  
> -            /* Skip the upper-half of the address for a 64-bit BAR. */
> -            if ( (bar_data & (PCI_BASE_ADDRESS_SPACE |
> -                              PCI_BASE_ADDRESS_MEM_TYPE_MASK)) == 
> -                 (PCI_BASE_ADDRESS_SPACE_MEMORY | 
> -                  PCI_BASE_ADDRESS_MEM_TYPE_64) )
> +            /*The upper half is already calculated, skip it! */
> +            if (is_64bar)
>                  bar++;
>          }
>  
> @@ -197,6 +213,9 @@
>              ((pci_mem_start << 1) != 0) )
>          pci_mem_start <<= 1;
>  
> +    if ( (pci_mem_start << 1) != 0 )
> +        bar64_relocate = 1;
> +
>      /* Relocate RAM that overlaps PCI space (in 64k-page chunks). */
>      while ( (pci_mem_start >> PAGE_SHIFT) < hvm_info->low_mem_pgend )
>      {
> @@ -218,11 +237,15 @@
>          hvm_info->high_mem_pgend += nr_pages;
>      }
>  
> +    high_mem_resource.base = ((uint64_t)hvm_info->high_mem_pgend) << PAGE_SHIFT; 
> +    high_mem_resource.max = 1ull << cpu_phys_addr();
>      mem_resource.base = pci_mem_start;
>      mem_resource.max = pci_mem_end;
>      io_resource.base = 0xc000;
>      io_resource.max = 0x10000;
>  
> +    mmio_left = pci_mem_end - pci_mem_start;
> +
>      /* Assign iomem and ioport resources in descending order of size. */
>      for ( i = 0; i < nr_bars; i++ )
>      {
> @@ -230,13 +253,29 @@
>          bar_reg = bars[i].bar_reg;
>          bar_sz  = bars[i].bar_sz;
>  
> +        using_64bar = bars[i].is_64bar && bar64_relocate && (mmio_left < bar_sz);
>          bar_data = pci_readl(devfn, bar_reg);
>  
>          if ( (bar_data & PCI_BASE_ADDRESS_SPACE) ==
>               PCI_BASE_ADDRESS_SPACE_MEMORY )
>          {
> -            resource = &mem_resource;
> -            bar_data &= ~PCI_BASE_ADDRESS_MEM_MASK;
> +            /* Mapping high memory if PCI deivce is 64 bits bar and the bar size
> +               is larger than 512M */
> +            if (using_64bar && (bar_sz > PCI_MIN_BIG_BAR_SIZE)) {
> +                if ( high_mem_resource.base & (bar_sz - 1) )
> +                    high_mem_resource.base = high_mem_resource.base - 
> +                        (high_mem_resource.base & (bar_sz - 1)) + bar_sz;
> +                else
> +                    high_mem_resource.base = high_mem_resource.base - 
> +                        (high_mem_resource.base & (bar_sz - 1));
> +                resource = &high_mem_resource;
> +                bar_data &= ~PCI_BASE_ADDRESS_MEM_MASK;
> +            } 
> +            else {
> +                resource = &mem_resource;
> +                bar_data &= ~PCI_BASE_ADDRESS_MEM_MASK;
> +            }
> +            mmio_left -= bar_sz;
>          }
>          else
>          {
> @@ -244,13 +283,14 @@
>              bar_data &= ~PCI_BASE_ADDRESS_IO_MASK;
>          }
>  
> -        base = (resource->base + bar_sz - 1) & ~(bar_sz - 1);
> -        bar_data |= base;
> +        base = (resource->base  + bar_sz - 1) & ~(uint64_t)(bar_sz - 1);
> +        bar_data |= (uint32_t)base;
> +        bar_data_upper = (uint32_t)(base >> 32);
>          base += bar_sz;
>  
>          if ( (base < resource->base) || (base > resource->max) )
>          {
> -            printf("pci dev %02x:%x bar %02x size %08x: no space for "
> +            printf("pci dev %02x:%x bar %02x size %llx: no space for "
>                     "resource!\n", devfn>>3, devfn&7, bar_reg, bar_sz);
>              continue;
>          }
> @@ -258,8 +298,8 @@
>          resource->base = base;
>  
>          pci_writel(devfn, bar_reg, bar_data);
> -        printf("pci dev %02x:%x bar %02x size %08x: %08x\n",
> -               devfn>>3, devfn&7, bar_reg, bar_sz, bar_data);
> +        if (using_64bar)
> +            pci_writel(devfn, bar_reg + 4, bar_data_upper);
>  
>          /* Now enable the memory or I/O mapping. */
>          cmd = pci_readw(devfn, PCI_COMMAND);
> diff -r dc56a9defa30 tools/firmware/hvmloader/util.h
> --- a/tools/firmware/hvmloader/util.h	Tue Aug 14 10:28:14 2012 +0200
> +++ b/tools/firmware/hvmloader/util.h	Wed Sep 12 14:50:55 2012 +0800
> @@ -215,6 +215,7 @@
>  uint32_t rombios_highbios_setup(void);
>  
>  /* Miscellaneous. */
> +unsigned int cpu_phys_addr(void);
>  void cacheattr_init(void);
>  unsigned long create_mp_tables(void *table);
>  void hvm_write_smbios_tables(



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 25 08:32:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 08:32:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGQYc-0006sF-L9; Tue, 25 Sep 2012 08:31: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 1TGQYb-0006sA-2o
	for xen-devel@lists.xen.org; Tue, 25 Sep 2012 08:31:53 +0000
Received: from [85.158.143.35:16783] by server-1.bemta-4.messagelabs.com id
	5D/87-05684-8FB61605; Tue, 25 Sep 2012 08:31:52 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1348561911!13898711!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTA5ODg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12250 invoked from network); 25 Sep 2012 08:31:51 -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 Sep 2012 08:31:51 -0000
X-IronPort-AV: E=Sophos;i="4.80,479,1344211200"; d="scan'208";a="14741393"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Sep 2012 08:31: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.279.1;
	Tue, 25 Sep 2012 09:31:51 +0100
Message-ID: <1348561909.3452.108.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Tue, 25 Sep 2012 09:31:49 +0100
In-Reply-To: <1348543998-31304-1-git-send-email-xudong.hao@intel.com>
References: <1348543998-31304-1-git-send-email-xudong.hao@intel.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Xudong Hao <xudong.hao@intel.com>, Xiantao Zhang <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] xen/tools: Add 64 bits big bar 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-09-25 at 04:33 +0100, an unknown sender wrote:
> Currently it is assumed PCI device BAR access < 4G memory. If there is such a
> device whose BAR size is larger than 4G, it must access > 4G memory address.
> This patch enable the 64bits big BAR support on hvmloader.

Does this work in both qemu-xen-traditional/ROMBIOS and qemu-xen/SeaBIOS
configurations? Or does the BIOS not care about this stuff?

Ian

> 
> Changes from v1:
> 1) Set Dynamic MMIO high memory address instead of a fixed number 640G
> 2) Mask bar_sz earlier to avoid older code changes
> 3) Add bar size barrier to judge high memory resource
> 4) Clean up bar64_relocate code
> 
> Signed-off-by: Xiantao Zhang <xiantao.zhang@intel.com>
> Signed-off-by: Xudong Hao <xudong.hao@intel.com>
> 
> diff -r dc56a9defa30 tools/firmware/hvmloader/cacheattr.c
> --- a/tools/firmware/hvmloader/cacheattr.c	Tue Aug 14 10:28:14 2012 +0200
> +++ b/tools/firmware/hvmloader/cacheattr.c	Wed Sep 12 14:50:55 2012 +0800
> @@ -40,17 +40,10 @@
>  #define MSR_PAT              0x0277
>  #define MSR_MTRRdefType      0x02ff
>  
> -void cacheattr_init(void)
> +unsigned int cpu_phys_addr(void)
>  {
>      uint32_t eax, ebx, ecx, edx;
> -    uint64_t mtrr_cap, mtrr_def, content, addr_mask;
> -    unsigned int i, nr_var_ranges, phys_bits = 36;
> -
> -    /* Does the CPU support architectural MTRRs? */
> -    cpuid(0x00000001, &eax, &ebx, &ecx, &edx);
> -    if ( !(edx & (1u << 12)) )
> -         return;
> -
> +    unsigned int phys_bits = 36;
>      /* Find the physical address size for this CPU. */
>      cpuid(0x80000000, &eax, &ebx, &ecx, &edx);
>      if ( eax >= 0x80000008 )
> @@ -59,6 +52,22 @@
>          phys_bits = (uint8_t)eax;
>      }
>  
> +    return phys_bits;
> +}
> +
> +void cacheattr_init(void)
> +{
> +    uint32_t eax, ebx, ecx, edx;
> +    uint64_t mtrr_cap, mtrr_def, content, addr_mask;
> +    unsigned int i, nr_var_ranges, phys_bits;
> +
> +    /* Does the CPU support architectural MTRRs? */
> +    cpuid(0x00000001, &eax, &ebx, &ecx, &edx);
> +    if ( !(edx & (1u << 12)) )
> +         return;
> +
> +    phys_bits = cpu_phys_addr();
> +
>      printf("%u-bit phys ... ", phys_bits);
>  
>      addr_mask = ((1ull << phys_bits) - 1) & ~((1ull << 12) - 1);
> diff -r dc56a9defa30 tools/firmware/hvmloader/config.h
> --- a/tools/firmware/hvmloader/config.h	Tue Aug 14 10:28:14 2012 +0200
> +++ b/tools/firmware/hvmloader/config.h	Wed Sep 12 14:50:55 2012 +0800
> @@ -53,6 +53,8 @@
>  /* MMIO hole: Hardcoded defaults, which can be dynamically expanded. */
>  #define PCI_MEM_START       0xf0000000
>  #define PCI_MEM_END         0xfc000000
> +#define PCI_MIN_BIG_BAR_SIZE          0x20000000
> +
>  extern unsigned long pci_mem_start, pci_mem_end;
>  
> 
> diff -r dc56a9defa30 tools/firmware/hvmloader/pci.c
> --- a/tools/firmware/hvmloader/pci.c	Tue Aug 14 10:28:14 2012 +0200
> +++ b/tools/firmware/hvmloader/pci.c	Wed Sep 12 14:50:55 2012 +0800
> @@ -36,19 +36,25 @@
>  
>  void pci_setup(void)
>  {
> -    uint32_t base, devfn, bar_reg, bar_data, bar_sz, cmd, mmio_total = 0;
> +    uint8_t is_64bar, using_64bar, bar64_relocate = 0;
> +    uint32_t devfn, bar_reg, cmd, bar_data, bar_data_upper;
> +    uint64_t base, bar_sz, bar_sz_upper, mmio_total = 0;
>      uint32_t vga_devfn = 256;
>      uint16_t class, vendor_id, device_id;
>      unsigned int bar, pin, link, isa_irq;
> +    int64_t mmio_left;
>  
>      /* Resources assignable to PCI devices via BARs. */
>      struct resource {
> -        uint32_t base, max;
> -    } *resource, mem_resource, io_resource;
> +        uint64_t base, max;
> +    } *resource, mem_resource, high_mem_resource, io_resource;
>  
>      /* Create a list of device BARs in descending order of size. */
>      struct bars {
> -        uint32_t devfn, bar_reg, bar_sz;
> +        uint32_t is_64bar;
> +        uint32_t devfn;
> +        uint32_t bar_reg;
> +        uint64_t bar_sz;
>      } *bars = (struct bars *)scratch_start;
>      unsigned int i, nr_bars = 0;
>  
> @@ -133,22 +139,34 @@
>          /* Map the I/O memory and port resources. */
>          for ( bar = 0; bar < 7; bar++ )
>          {
> +            bar_sz_upper = 0;
>              bar_reg = PCI_BASE_ADDRESS_0 + 4*bar;
>              if ( bar == 6 )
>                  bar_reg = PCI_ROM_ADDRESS;
>  
>              bar_data = pci_readl(devfn, bar_reg);
> +            is_64bar = !!((bar_data & (PCI_BASE_ADDRESS_SPACE |
> +                         PCI_BASE_ADDRESS_MEM_TYPE_MASK)) ==
> +                         (PCI_BASE_ADDRESS_SPACE_MEMORY |
> +                         PCI_BASE_ADDRESS_MEM_TYPE_64));
>              pci_writel(devfn, bar_reg, ~0);
>              bar_sz = pci_readl(devfn, bar_reg);
>              pci_writel(devfn, bar_reg, bar_data);
> -            if ( bar_sz == 0 )
> -                continue;
>  
>              bar_sz &= (((bar_data & PCI_BASE_ADDRESS_SPACE) ==
>                          PCI_BASE_ADDRESS_SPACE_MEMORY) ?
>                         PCI_BASE_ADDRESS_MEM_MASK :
>                         (PCI_BASE_ADDRESS_IO_MASK & 0xffff));
> +            if (is_64bar) {
> +                bar_data_upper = pci_readl(devfn, bar_reg + 4);
> +                pci_writel(devfn, bar_reg + 4, ~0);
> +                bar_sz_upper = pci_readl(devfn, bar_reg + 4);
> +                pci_writel(devfn, bar_reg + 4, bar_data_upper);
> +                bar_sz = (bar_sz_upper << 32) | bar_sz;
> +            }
>              bar_sz &= ~(bar_sz - 1);
> +            if ( bar_sz == 0 )
> +                continue;
>  
>              for ( i = 0; i < nr_bars; i++ )
>                  if ( bars[i].bar_sz < bar_sz )
> @@ -157,6 +175,7 @@
>              if ( i != nr_bars )
>                  memmove(&bars[i+1], &bars[i], (nr_bars-i) * sizeof(*bars));
>  
> +            bars[i].is_64bar = is_64bar;
>              bars[i].devfn   = devfn;
>              bars[i].bar_reg = bar_reg;
>              bars[i].bar_sz  = bar_sz;
> @@ -167,11 +186,8 @@
>  
>              nr_bars++;
>  
> -            /* Skip the upper-half of the address for a 64-bit BAR. */
> -            if ( (bar_data & (PCI_BASE_ADDRESS_SPACE |
> -                              PCI_BASE_ADDRESS_MEM_TYPE_MASK)) == 
> -                 (PCI_BASE_ADDRESS_SPACE_MEMORY | 
> -                  PCI_BASE_ADDRESS_MEM_TYPE_64) )
> +            /*The upper half is already calculated, skip it! */
> +            if (is_64bar)
>                  bar++;
>          }
>  
> @@ -197,6 +213,9 @@
>              ((pci_mem_start << 1) != 0) )
>          pci_mem_start <<= 1;
>  
> +    if ( (pci_mem_start << 1) != 0 )
> +        bar64_relocate = 1;
> +
>      /* Relocate RAM that overlaps PCI space (in 64k-page chunks). */
>      while ( (pci_mem_start >> PAGE_SHIFT) < hvm_info->low_mem_pgend )
>      {
> @@ -218,11 +237,15 @@
>          hvm_info->high_mem_pgend += nr_pages;
>      }
>  
> +    high_mem_resource.base = ((uint64_t)hvm_info->high_mem_pgend) << PAGE_SHIFT; 
> +    high_mem_resource.max = 1ull << cpu_phys_addr();
>      mem_resource.base = pci_mem_start;
>      mem_resource.max = pci_mem_end;
>      io_resource.base = 0xc000;
>      io_resource.max = 0x10000;
>  
> +    mmio_left = pci_mem_end - pci_mem_start;
> +
>      /* Assign iomem and ioport resources in descending order of size. */
>      for ( i = 0; i < nr_bars; i++ )
>      {
> @@ -230,13 +253,29 @@
>          bar_reg = bars[i].bar_reg;
>          bar_sz  = bars[i].bar_sz;
>  
> +        using_64bar = bars[i].is_64bar && bar64_relocate && (mmio_left < bar_sz);
>          bar_data = pci_readl(devfn, bar_reg);
>  
>          if ( (bar_data & PCI_BASE_ADDRESS_SPACE) ==
>               PCI_BASE_ADDRESS_SPACE_MEMORY )
>          {
> -            resource = &mem_resource;
> -            bar_data &= ~PCI_BASE_ADDRESS_MEM_MASK;
> +            /* Mapping high memory if PCI deivce is 64 bits bar and the bar size
> +               is larger than 512M */
> +            if (using_64bar && (bar_sz > PCI_MIN_BIG_BAR_SIZE)) {
> +                if ( high_mem_resource.base & (bar_sz - 1) )
> +                    high_mem_resource.base = high_mem_resource.base - 
> +                        (high_mem_resource.base & (bar_sz - 1)) + bar_sz;
> +                else
> +                    high_mem_resource.base = high_mem_resource.base - 
> +                        (high_mem_resource.base & (bar_sz - 1));
> +                resource = &high_mem_resource;
> +                bar_data &= ~PCI_BASE_ADDRESS_MEM_MASK;
> +            } 
> +            else {
> +                resource = &mem_resource;
> +                bar_data &= ~PCI_BASE_ADDRESS_MEM_MASK;
> +            }
> +            mmio_left -= bar_sz;
>          }
>          else
>          {
> @@ -244,13 +283,14 @@
>              bar_data &= ~PCI_BASE_ADDRESS_IO_MASK;
>          }
>  
> -        base = (resource->base + bar_sz - 1) & ~(bar_sz - 1);
> -        bar_data |= base;
> +        base = (resource->base  + bar_sz - 1) & ~(uint64_t)(bar_sz - 1);
> +        bar_data |= (uint32_t)base;
> +        bar_data_upper = (uint32_t)(base >> 32);
>          base += bar_sz;
>  
>          if ( (base < resource->base) || (base > resource->max) )
>          {
> -            printf("pci dev %02x:%x bar %02x size %08x: no space for "
> +            printf("pci dev %02x:%x bar %02x size %llx: no space for "
>                     "resource!\n", devfn>>3, devfn&7, bar_reg, bar_sz);
>              continue;
>          }
> @@ -258,8 +298,8 @@
>          resource->base = base;
>  
>          pci_writel(devfn, bar_reg, bar_data);
> -        printf("pci dev %02x:%x bar %02x size %08x: %08x\n",
> -               devfn>>3, devfn&7, bar_reg, bar_sz, bar_data);
> +        if (using_64bar)
> +            pci_writel(devfn, bar_reg + 4, bar_data_upper);
>  
>          /* Now enable the memory or I/O mapping. */
>          cmd = pci_readw(devfn, PCI_COMMAND);
> diff -r dc56a9defa30 tools/firmware/hvmloader/util.h
> --- a/tools/firmware/hvmloader/util.h	Tue Aug 14 10:28:14 2012 +0200
> +++ b/tools/firmware/hvmloader/util.h	Wed Sep 12 14:50:55 2012 +0800
> @@ -215,6 +215,7 @@
>  uint32_t rombios_highbios_setup(void);
>  
>  /* Miscellaneous. */
> +unsigned int cpu_phys_addr(void);
>  void cacheattr_init(void);
>  unsigned long create_mp_tables(void *table);
>  void hvm_write_smbios_tables(



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 25 08:39:39 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 08:39:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGQfr-000741-It; Tue, 25 Sep 2012 08:39:23 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1TGQfq-00073w-LA
	for xen-devel@lists.xen.org; Tue, 25 Sep 2012 08:39:22 +0000
Received: from [85.158.137.99:12872] by server-13.bemta-3.messagelabs.com id
	FD/0E-01606-9BD61605; Tue, 25 Sep 2012 08:39:21 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-217.messagelabs.com!1348562361!17811904!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTA5ODg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16568 invoked from network); 25 Sep 2012 08:39:21 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Sep 2012 08:39:21 -0000
X-IronPort-AV: E=Sophos;i="4.80,479,1344211200"; d="scan'208";a="14741694"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Sep 2012 08:39: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.279.1;
	Tue, 25 Sep 2012 09:39:21 +0100
Message-ID: <1348562359.3452.112.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Anthony PERARD <anthony.perard@citrix.com>
Date: Tue, 25 Sep 2012 09:39:19 +0100
In-Reply-To: <1347906148-9606-2-git-send-email-anthony.perard@citrix.com>
References: <1347906148-9606-1-git-send-email-anthony.perard@citrix.com>
	<1347906148-9606-2-git-send-email-anthony.perard@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Xen Devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH V2 1/9] libxl_json: Use libxl alloc function
	with 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 Mon, 2012-09-17 at 19:22 +0100, Anthony PERARD wrote:
> This patch makes use of the libxl allocation API and removes the check for
> allocation failure.
> 
> Also we don't use GC with a json_object because this structure use flexarray
> and the latter does not use the gc.

It's not an uncommon pattern in libxl for the content of the flexarray
to be gc'd but the actual array itself to be explicitly freed, often
implicitly via flexarray_contents(), if that's what you want.

If we wanted I don't think there's any reason we couldn't make the
flexarray take a gc and use it, that would probably make things simpler
here and elsewhere and reduce the manual memory management (unless you
actually want/need that for some other reason).

> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
> ---
>  tools/libxl/libxl_json.c | 37 +++++++++++--------------------------
>  1 file changed, 11 insertions(+), 26 deletions(-)
> 
> diff --git a/tools/libxl/libxl_json.c b/tools/libxl/libxl_json.c
> index caa8312..9c3dca2 100644
> --- a/tools/libxl/libxl_json.c
> +++ b/tools/libxl/libxl_json.c
> @@ -210,12 +210,7 @@ static libxl__json_object *json_object_alloc(libxl__gc *gc,
>  {
>      libxl__json_object *obj;
>  
> -    obj = calloc(1, sizeof (libxl__json_object));
> -    if (obj == NULL) {
> -        LIBXL__LOG_ERRNO(libxl__gc_owner(gc), LIBXL__LOG_ERROR,
> -                         "Failed to allocate a libxl__json_object");
> -        return NULL;
> -    }
> +    obj = libxl__zalloc(NOGC, sizeof(*obj));

So you now ignore the gc passed in, which in any case you have now
caused to always be NOGC? Seems a bit round-about to me, why not use the
gc parameter here?

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 25 08:39:39 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 08:39:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGQfr-000741-It; Tue, 25 Sep 2012 08:39:23 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1TGQfq-00073w-LA
	for xen-devel@lists.xen.org; Tue, 25 Sep 2012 08:39:22 +0000
Received: from [85.158.137.99:12872] by server-13.bemta-3.messagelabs.com id
	FD/0E-01606-9BD61605; Tue, 25 Sep 2012 08:39:21 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-217.messagelabs.com!1348562361!17811904!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTA5ODg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16568 invoked from network); 25 Sep 2012 08:39:21 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Sep 2012 08:39:21 -0000
X-IronPort-AV: E=Sophos;i="4.80,479,1344211200"; d="scan'208";a="14741694"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Sep 2012 08:39: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.279.1;
	Tue, 25 Sep 2012 09:39:21 +0100
Message-ID: <1348562359.3452.112.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Anthony PERARD <anthony.perard@citrix.com>
Date: Tue, 25 Sep 2012 09:39:19 +0100
In-Reply-To: <1347906148-9606-2-git-send-email-anthony.perard@citrix.com>
References: <1347906148-9606-1-git-send-email-anthony.perard@citrix.com>
	<1347906148-9606-2-git-send-email-anthony.perard@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Xen Devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH V2 1/9] libxl_json: Use libxl alloc function
	with 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 Mon, 2012-09-17 at 19:22 +0100, Anthony PERARD wrote:
> This patch makes use of the libxl allocation API and removes the check for
> allocation failure.
> 
> Also we don't use GC with a json_object because this structure use flexarray
> and the latter does not use the gc.

It's not an uncommon pattern in libxl for the content of the flexarray
to be gc'd but the actual array itself to be explicitly freed, often
implicitly via flexarray_contents(), if that's what you want.

If we wanted I don't think there's any reason we couldn't make the
flexarray take a gc and use it, that would probably make things simpler
here and elsewhere and reduce the manual memory management (unless you
actually want/need that for some other reason).

> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
> ---
>  tools/libxl/libxl_json.c | 37 +++++++++++--------------------------
>  1 file changed, 11 insertions(+), 26 deletions(-)
> 
> diff --git a/tools/libxl/libxl_json.c b/tools/libxl/libxl_json.c
> index caa8312..9c3dca2 100644
> --- a/tools/libxl/libxl_json.c
> +++ b/tools/libxl/libxl_json.c
> @@ -210,12 +210,7 @@ static libxl__json_object *json_object_alloc(libxl__gc *gc,
>  {
>      libxl__json_object *obj;
>  
> -    obj = calloc(1, sizeof (libxl__json_object));
> -    if (obj == NULL) {
> -        LIBXL__LOG_ERRNO(libxl__gc_owner(gc), LIBXL__LOG_ERROR,
> -                         "Failed to allocate a libxl__json_object");
> -        return NULL;
> -    }
> +    obj = libxl__zalloc(NOGC, sizeof(*obj));

So you now ignore the gc passed in, which in any case you have now
caused to always be NOGC? Seems a bit round-about to me, why not use the
gc parameter here?

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 25 08:40:36 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 08:40:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGQgm-00077X-1E; Tue, 25 Sep 2012 08:40: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 1TGQgk-00077I-G1
	for xen-devel@lists.xen.org; Tue, 25 Sep 2012 08:40:18 +0000
Received: from [85.158.137.99:35597] by server-2.bemta-3.messagelabs.com id
	8F/08-04862-1FD61605; Tue, 25 Sep 2012 08:40:17 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-217.messagelabs.com!1348562416!19014112!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTA5ODg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30530 invoked from network); 25 Sep 2012 08:40:17 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Sep 2012 08:40:17 -0000
X-IronPort-AV: E=Sophos;i="4.80,479,1344211200"; d="scan'208";a="14741723"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Sep 2012 08: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.279.1;
	Tue, 25 Sep 2012 09:40:16 +0100
Message-ID: <1348562415.3452.113.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Anthony PERARD <anthony.perard@citrix.com>
Date: Tue, 25 Sep 2012 09:40:15 +0100
In-Reply-To: <1347906148-9606-3-git-send-email-anthony.perard@citrix.com>
References: <1347906148-9606-1-git-send-email-anthony.perard@citrix.com>
	<1347906148-9606-3-git-send-email-anthony.perard@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Xen Devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH V2 2/9] libxl_json: Export json_object
	related function.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2012-09-17 at 19:22 +0100, Anthony PERARD wrote:
> Export libxl__json_object_alloc and libxl__json_object_append_to to use them in
> a later patch.
> 
> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>

Acked-by: Ian Campbell <ian.campbell@citrix.com>

> ---
>  tools/libxl/libxl_internal.h |  8 ++++++++
>  tools/libxl/libxl_json.c     | 34 +++++++++++++++++-----------------
>  2 files changed, 25 insertions(+), 17 deletions(-)
> 
> diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
> index b6f54ba..3c2dcaa 100644
> --- a/tools/libxl/libxl_internal.h
> +++ b/tools/libxl/libxl_internal.h
> @@ -1511,6 +1511,14 @@ static inline long long libxl__json_object_get_integer(const libxl__json_object
>          return -1;
>  }
>  
> +/* Objects allocated using this function must be free with
> + * libxl__json_object_free.
> + */
> +_hidden libxl__json_object *libxl__json_object_alloc(libxl__gc *gc,
> +                                                     libxl__json_node_type type);
> +_hidden int libxl__json_object_append_to(libxl__gc *gc,
> +                                         libxl__json_object *obj,
> +                                         libxl__json_object *dst);
>  _hidden libxl__json_object *libxl__json_array_get(const libxl__json_object *o,
>                                                    int i);
>  _hidden
> diff --git a/tools/libxl/libxl_json.c b/tools/libxl/libxl_json.c
> index 9c3dca2..0539865 100644
> --- a/tools/libxl/libxl_json.c
> +++ b/tools/libxl/libxl_json.c
> @@ -205,7 +205,7 @@ yajl_gen_status libxl__string_gen_json(yajl_gen hand,
>   * libxl__json_object helper functions
>   */
>  
> -static libxl__json_object *json_object_alloc(libxl__gc *gc,
> +libxl__json_object *libxl__json_object_alloc(libxl__gc *gc,
>                                               libxl__json_node_type type)
>  {
>      libxl__json_object *obj;
> @@ -231,7 +231,7 @@ static libxl__json_object *json_object_alloc(libxl__gc *gc,
>      return obj;
>  }
>  
> -static int json_object_append_to(libxl__gc *gc,
> +int libxl__json_object_append_to(libxl__gc *gc,
>                                   libxl__json_object *obj,
>                                   libxl__json_object *dst)
>  {
> @@ -388,9 +388,9 @@ static int json_callback_null(void *opaque)
>  
>      DEBUG_GEN(ctx, null);
>  
> -    obj = json_object_alloc(ctx->gc, JSON_NULL);
> +    obj = libxl__json_object_alloc(ctx->gc, JSON_NULL);
>  
> -    if (json_object_append_to(ctx->gc, obj, ctx->current) == -1) {
> +    if (libxl__json_object_append_to(ctx->gc, obj, ctx->current) == -1) {
>          libxl__json_object_free(ctx->gc, obj);
>          return 0;
>      }
> @@ -405,10 +405,10 @@ static int json_callback_boolean(void *opaque, int boolean)
>  
>      DEBUG_GEN_VALUE(ctx, bool, boolean);
>  
> -    obj = json_object_alloc(ctx->gc,
> -                            boolean ? JSON_TRUE : JSON_FALSE);
> +    obj = libxl__json_object_alloc(ctx->gc,
> +                                   boolean ? JSON_TRUE : JSON_FALSE);
>  
> -    if (json_object_append_to(ctx->gc, obj, ctx->current) == -1) {
> +    if (libxl__json_object_append_to(ctx->gc, obj, ctx->current) == -1) {
>          libxl__json_object_free(ctx->gc, obj);
>          return 0;
>      }
> @@ -441,7 +441,7 @@ static int json_callback_number(void *opaque, const char *s, libxl_yajl_length l
>              goto error;
>          }
>  
> -        obj = json_object_alloc(ctx->gc, JSON_DOUBLE);
> +        obj = libxl__json_object_alloc(ctx->gc, JSON_DOUBLE);
>          obj->u.d = d;
>      } else {
>          long long i = strtoll(s, NULL, 10);
> @@ -450,14 +450,14 @@ static int json_callback_number(void *opaque, const char *s, libxl_yajl_length l
>              goto error;
>          }
>  
> -        obj = json_object_alloc(ctx->gc, JSON_INTEGER);
> +        obj = libxl__json_object_alloc(ctx->gc, JSON_INTEGER);
>          obj->u.i = i;
>      }
>      goto out;
>  
>  error:
>      /* If the conversion fail, we just store the original string. */
> -    obj = json_object_alloc(ctx->gc, JSON_NUMBER);
> +    obj = libxl__json_object_alloc(ctx->gc, JSON_NUMBER);
>  
>      t = malloc(len + 1);
>      if (t == NULL) {
> @@ -471,7 +471,7 @@ error:
>      obj->u.string = t;
>  
>  out:
> -    if (json_object_append_to(ctx->gc, obj, ctx->current) == -1) {
> +    if (libxl__json_object_append_to(ctx->gc, obj, ctx->current) == -1) {
>          libxl__json_object_free(ctx->gc, obj);
>          return 0;
>      }
> @@ -498,10 +498,10 @@ static int json_callback_string(void *opaque, const unsigned char *str,
>      strncpy(t, (const char *) str, len);
>      t[len] = 0;
>  
> -    obj = json_object_alloc(ctx->gc, JSON_STRING);
> +    obj = libxl__json_object_alloc(ctx->gc, JSON_STRING);
>      obj->u.string = t;
>  
> -    if (json_object_append_to(ctx->gc, obj, ctx->current) == -1) {
> +    if (libxl__json_object_append_to(ctx->gc, obj, ctx->current) == -1) {
>          libxl__json_object_free(ctx->gc, obj);
>          return 0;
>      }
> @@ -560,10 +560,10 @@ static int json_callback_start_map(void *opaque)
>  
>      DEBUG_GEN(ctx, map_open);
>  
> -    obj = json_object_alloc(ctx->gc, JSON_MAP);
> +    obj = libxl__json_object_alloc(ctx->gc, JSON_MAP);
>  
>      if (ctx->current) {
> -        if (json_object_append_to(ctx->gc, obj, ctx->current) == -1) {
> +        if (libxl__json_object_append_to(ctx->gc, obj, ctx->current) == -1) {
>              libxl__json_object_free(ctx->gc, obj);
>              return 0;
>          }
> @@ -601,10 +601,10 @@ static int json_callback_start_array(void *opaque)
>  
>      DEBUG_GEN(ctx, array_open);
>  
> -    obj = json_object_alloc(ctx->gc, JSON_ARRAY);
> +    obj = libxl__json_object_alloc(ctx->gc, JSON_ARRAY);
>  
>      if (ctx->current) {
> -        if (json_object_append_to(ctx->gc, obj, ctx->current) == -1) {
> +        if (libxl__json_object_append_to(ctx->gc, obj, ctx->current) == -1) {
>              libxl__json_object_free(ctx->gc, obj);
>              return 0;
>          }



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 25 08:40:36 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 08:40:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGQgm-00077X-1E; Tue, 25 Sep 2012 08:40: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 1TGQgk-00077I-G1
	for xen-devel@lists.xen.org; Tue, 25 Sep 2012 08:40:18 +0000
Received: from [85.158.137.99:35597] by server-2.bemta-3.messagelabs.com id
	8F/08-04862-1FD61605; Tue, 25 Sep 2012 08:40:17 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-217.messagelabs.com!1348562416!19014112!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTA5ODg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30530 invoked from network); 25 Sep 2012 08:40:17 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Sep 2012 08:40:17 -0000
X-IronPort-AV: E=Sophos;i="4.80,479,1344211200"; d="scan'208";a="14741723"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Sep 2012 08: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.279.1;
	Tue, 25 Sep 2012 09:40:16 +0100
Message-ID: <1348562415.3452.113.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Anthony PERARD <anthony.perard@citrix.com>
Date: Tue, 25 Sep 2012 09:40:15 +0100
In-Reply-To: <1347906148-9606-3-git-send-email-anthony.perard@citrix.com>
References: <1347906148-9606-1-git-send-email-anthony.perard@citrix.com>
	<1347906148-9606-3-git-send-email-anthony.perard@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Xen Devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH V2 2/9] libxl_json: Export json_object
	related function.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2012-09-17 at 19:22 +0100, Anthony PERARD wrote:
> Export libxl__json_object_alloc and libxl__json_object_append_to to use them in
> a later patch.
> 
> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>

Acked-by: Ian Campbell <ian.campbell@citrix.com>

> ---
>  tools/libxl/libxl_internal.h |  8 ++++++++
>  tools/libxl/libxl_json.c     | 34 +++++++++++++++++-----------------
>  2 files changed, 25 insertions(+), 17 deletions(-)
> 
> diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
> index b6f54ba..3c2dcaa 100644
> --- a/tools/libxl/libxl_internal.h
> +++ b/tools/libxl/libxl_internal.h
> @@ -1511,6 +1511,14 @@ static inline long long libxl__json_object_get_integer(const libxl__json_object
>          return -1;
>  }
>  
> +/* Objects allocated using this function must be free with
> + * libxl__json_object_free.
> + */
> +_hidden libxl__json_object *libxl__json_object_alloc(libxl__gc *gc,
> +                                                     libxl__json_node_type type);
> +_hidden int libxl__json_object_append_to(libxl__gc *gc,
> +                                         libxl__json_object *obj,
> +                                         libxl__json_object *dst);
>  _hidden libxl__json_object *libxl__json_array_get(const libxl__json_object *o,
>                                                    int i);
>  _hidden
> diff --git a/tools/libxl/libxl_json.c b/tools/libxl/libxl_json.c
> index 9c3dca2..0539865 100644
> --- a/tools/libxl/libxl_json.c
> +++ b/tools/libxl/libxl_json.c
> @@ -205,7 +205,7 @@ yajl_gen_status libxl__string_gen_json(yajl_gen hand,
>   * libxl__json_object helper functions
>   */
>  
> -static libxl__json_object *json_object_alloc(libxl__gc *gc,
> +libxl__json_object *libxl__json_object_alloc(libxl__gc *gc,
>                                               libxl__json_node_type type)
>  {
>      libxl__json_object *obj;
> @@ -231,7 +231,7 @@ static libxl__json_object *json_object_alloc(libxl__gc *gc,
>      return obj;
>  }
>  
> -static int json_object_append_to(libxl__gc *gc,
> +int libxl__json_object_append_to(libxl__gc *gc,
>                                   libxl__json_object *obj,
>                                   libxl__json_object *dst)
>  {
> @@ -388,9 +388,9 @@ static int json_callback_null(void *opaque)
>  
>      DEBUG_GEN(ctx, null);
>  
> -    obj = json_object_alloc(ctx->gc, JSON_NULL);
> +    obj = libxl__json_object_alloc(ctx->gc, JSON_NULL);
>  
> -    if (json_object_append_to(ctx->gc, obj, ctx->current) == -1) {
> +    if (libxl__json_object_append_to(ctx->gc, obj, ctx->current) == -1) {
>          libxl__json_object_free(ctx->gc, obj);
>          return 0;
>      }
> @@ -405,10 +405,10 @@ static int json_callback_boolean(void *opaque, int boolean)
>  
>      DEBUG_GEN_VALUE(ctx, bool, boolean);
>  
> -    obj = json_object_alloc(ctx->gc,
> -                            boolean ? JSON_TRUE : JSON_FALSE);
> +    obj = libxl__json_object_alloc(ctx->gc,
> +                                   boolean ? JSON_TRUE : JSON_FALSE);
>  
> -    if (json_object_append_to(ctx->gc, obj, ctx->current) == -1) {
> +    if (libxl__json_object_append_to(ctx->gc, obj, ctx->current) == -1) {
>          libxl__json_object_free(ctx->gc, obj);
>          return 0;
>      }
> @@ -441,7 +441,7 @@ static int json_callback_number(void *opaque, const char *s, libxl_yajl_length l
>              goto error;
>          }
>  
> -        obj = json_object_alloc(ctx->gc, JSON_DOUBLE);
> +        obj = libxl__json_object_alloc(ctx->gc, JSON_DOUBLE);
>          obj->u.d = d;
>      } else {
>          long long i = strtoll(s, NULL, 10);
> @@ -450,14 +450,14 @@ static int json_callback_number(void *opaque, const char *s, libxl_yajl_length l
>              goto error;
>          }
>  
> -        obj = json_object_alloc(ctx->gc, JSON_INTEGER);
> +        obj = libxl__json_object_alloc(ctx->gc, JSON_INTEGER);
>          obj->u.i = i;
>      }
>      goto out;
>  
>  error:
>      /* If the conversion fail, we just store the original string. */
> -    obj = json_object_alloc(ctx->gc, JSON_NUMBER);
> +    obj = libxl__json_object_alloc(ctx->gc, JSON_NUMBER);
>  
>      t = malloc(len + 1);
>      if (t == NULL) {
> @@ -471,7 +471,7 @@ error:
>      obj->u.string = t;
>  
>  out:
> -    if (json_object_append_to(ctx->gc, obj, ctx->current) == -1) {
> +    if (libxl__json_object_append_to(ctx->gc, obj, ctx->current) == -1) {
>          libxl__json_object_free(ctx->gc, obj);
>          return 0;
>      }
> @@ -498,10 +498,10 @@ static int json_callback_string(void *opaque, const unsigned char *str,
>      strncpy(t, (const char *) str, len);
>      t[len] = 0;
>  
> -    obj = json_object_alloc(ctx->gc, JSON_STRING);
> +    obj = libxl__json_object_alloc(ctx->gc, JSON_STRING);
>      obj->u.string = t;
>  
> -    if (json_object_append_to(ctx->gc, obj, ctx->current) == -1) {
> +    if (libxl__json_object_append_to(ctx->gc, obj, ctx->current) == -1) {
>          libxl__json_object_free(ctx->gc, obj);
>          return 0;
>      }
> @@ -560,10 +560,10 @@ static int json_callback_start_map(void *opaque)
>  
>      DEBUG_GEN(ctx, map_open);
>  
> -    obj = json_object_alloc(ctx->gc, JSON_MAP);
> +    obj = libxl__json_object_alloc(ctx->gc, JSON_MAP);
>  
>      if (ctx->current) {
> -        if (json_object_append_to(ctx->gc, obj, ctx->current) == -1) {
> +        if (libxl__json_object_append_to(ctx->gc, obj, ctx->current) == -1) {
>              libxl__json_object_free(ctx->gc, obj);
>              return 0;
>          }
> @@ -601,10 +601,10 @@ static int json_callback_start_array(void *opaque)
>  
>      DEBUG_GEN(ctx, array_open);
>  
> -    obj = json_object_alloc(ctx->gc, JSON_ARRAY);
> +    obj = libxl__json_object_alloc(ctx->gc, JSON_ARRAY);
>  
>      if (ctx->current) {
> -        if (json_object_append_to(ctx->gc, obj, ctx->current) == -1) {
> +        if (libxl__json_object_append_to(ctx->gc, obj, ctx->current) == -1) {
>              libxl__json_object_free(ctx->gc, obj);
>              return 0;
>          }



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 25 08:40:51 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 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 1TGQh5-00079Z-Ey; Tue, 25 Sep 2012 08:40:39 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wdauchy@gmail.com>) id 1TGQh3-00078W-90
	for xen-devel@lists.xensource.com; Tue, 25 Sep 2012 08:40:37 +0000
X-Env-Sender: wdauchy@gmail.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1348562421!10860842!1
X-Originating-IP: [209.85.220.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23403 invoked from network); 25 Sep 2012 08:40:23 -0000
Received: from mail-pa0-f43.google.com (HELO mail-pa0-f43.google.com)
	(209.85.220.43)
	by server-16.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Sep 2012 08:40:23 -0000
Received: by padfb1 with SMTP id fb1so2053923pad.30
	for <xen-devel@lists.xensource.com>;
	Tue, 25 Sep 2012 01:40: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;
	bh=U3GSWpNBKQHujICtOIZYQ5NVqy8hrj9UemsLEe2IKm8=;
	b=bW3yz9Gl752lygoLJ6d11tDijHmJENxK8k7fs8W321SEOiu583nlP75SQfwECEN2LQ
	CRoSMh5gW4xE407WEp8DwCUscNgOsiQ/gGmghe2wvL2hZl2KkhwzEczBbQLQfDs7UJOT
	3BtnqKdNBEUAXfr3nZcG6pQNJwiWB/4dSiVChutx9FqjfVx5AFiH0VSy4TrUfq6serTi
	AGUCgOM/wwkHxwG58wTxzAHvTemLdFEMwIRLnmLrltGSytKKrD66uK7X19QN5IwZUJ/4
	TU0hYKGATvAbuRgIf4Sx9yVf86dZbilY62CG0L/JqheFUnMCw2J4tTaNlOsSZBuI+LGh
	mG3g==
Received: by 10.68.230.234 with SMTP id tb10mr3892541pbc.71.1348562421272;
	Tue, 25 Sep 2012 01:40:21 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.68.135.42 with HTTP; Tue, 25 Sep 2012 01:40:00 -0700 (PDT)
In-Reply-To: <CAJ75kXZjuUgQfc=8tz2F_UEwnQWRD7AhyMOM1L+DSMFzoss9Dw@mail.gmail.com>
References: <CAJ75kXZm-BqWdL2O41XkSE1VCdd4ruW=+CqDmR1b3=701RnXmw@mail.gmail.com>
	<20120918133650.GC12053@phenom.dumpdata.com>
	<CAJ75kXZEaCj4Jqs_qm46d7U-s1C2hkAONs8c5Audrw2c3X=nBA@mail.gmail.com>
	<20120920134851.GB1998@localhost.localdomain>
	<CAJ75kXZ0depUJF_h0yok-r4aL0TBGnqTpW_PKT4Q7P1_6R4X2A@mail.gmail.com>
	<20120920162337.GB8912@reaktio.net>
	<CAJ75kXaXbitBvosYp8Sv_548XbvdxU=M_NSSHTb_5d56=-n4nA@mail.gmail.com>
	<20120920163525.GC8912@reaktio.net>
	<CAJ75kXZnb82GnssNWxyGMHjTYiRQCRsNdPeYdEb-tsvkshpfEg@mail.gmail.com>
	<20120920212823.GE27312@konrad-lan.dumpdata.com>
	<CAJ75kXZjuUgQfc=8tz2F_UEwnQWRD7AhyMOM1L+DSMFzoss9Dw@mail.gmail.com>
From: William Dauchy <wdauchy@gmail.com>
Date: Tue, 25 Sep 2012 10:40:00 +0200
Message-ID: <CAJ75kXbaj0vHeNDfu5hwEp8jL9zJOwpryYEY0UesvEJd388HJQ@mail.gmail.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] Error getting mfn
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hello Konrad,

Just wondering if you forgot about this thread.

-- 
William

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 25 08:40:51 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 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 1TGQh5-00079Z-Ey; Tue, 25 Sep 2012 08:40:39 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wdauchy@gmail.com>) id 1TGQh3-00078W-90
	for xen-devel@lists.xensource.com; Tue, 25 Sep 2012 08:40:37 +0000
X-Env-Sender: wdauchy@gmail.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1348562421!10860842!1
X-Originating-IP: [209.85.220.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23403 invoked from network); 25 Sep 2012 08:40:23 -0000
Received: from mail-pa0-f43.google.com (HELO mail-pa0-f43.google.com)
	(209.85.220.43)
	by server-16.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Sep 2012 08:40:23 -0000
Received: by padfb1 with SMTP id fb1so2053923pad.30
	for <xen-devel@lists.xensource.com>;
	Tue, 25 Sep 2012 01:40: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;
	bh=U3GSWpNBKQHujICtOIZYQ5NVqy8hrj9UemsLEe2IKm8=;
	b=bW3yz9Gl752lygoLJ6d11tDijHmJENxK8k7fs8W321SEOiu583nlP75SQfwECEN2LQ
	CRoSMh5gW4xE407WEp8DwCUscNgOsiQ/gGmghe2wvL2hZl2KkhwzEczBbQLQfDs7UJOT
	3BtnqKdNBEUAXfr3nZcG6pQNJwiWB/4dSiVChutx9FqjfVx5AFiH0VSy4TrUfq6serTi
	AGUCgOM/wwkHxwG58wTxzAHvTemLdFEMwIRLnmLrltGSytKKrD66uK7X19QN5IwZUJ/4
	TU0hYKGATvAbuRgIf4Sx9yVf86dZbilY62CG0L/JqheFUnMCw2J4tTaNlOsSZBuI+LGh
	mG3g==
Received: by 10.68.230.234 with SMTP id tb10mr3892541pbc.71.1348562421272;
	Tue, 25 Sep 2012 01:40:21 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.68.135.42 with HTTP; Tue, 25 Sep 2012 01:40:00 -0700 (PDT)
In-Reply-To: <CAJ75kXZjuUgQfc=8tz2F_UEwnQWRD7AhyMOM1L+DSMFzoss9Dw@mail.gmail.com>
References: <CAJ75kXZm-BqWdL2O41XkSE1VCdd4ruW=+CqDmR1b3=701RnXmw@mail.gmail.com>
	<20120918133650.GC12053@phenom.dumpdata.com>
	<CAJ75kXZEaCj4Jqs_qm46d7U-s1C2hkAONs8c5Audrw2c3X=nBA@mail.gmail.com>
	<20120920134851.GB1998@localhost.localdomain>
	<CAJ75kXZ0depUJF_h0yok-r4aL0TBGnqTpW_PKT4Q7P1_6R4X2A@mail.gmail.com>
	<20120920162337.GB8912@reaktio.net>
	<CAJ75kXaXbitBvosYp8Sv_548XbvdxU=M_NSSHTb_5d56=-n4nA@mail.gmail.com>
	<20120920163525.GC8912@reaktio.net>
	<CAJ75kXZnb82GnssNWxyGMHjTYiRQCRsNdPeYdEb-tsvkshpfEg@mail.gmail.com>
	<20120920212823.GE27312@konrad-lan.dumpdata.com>
	<CAJ75kXZjuUgQfc=8tz2F_UEwnQWRD7AhyMOM1L+DSMFzoss9Dw@mail.gmail.com>
From: William Dauchy <wdauchy@gmail.com>
Date: Tue, 25 Sep 2012 10:40:00 +0200
Message-ID: <CAJ75kXbaj0vHeNDfu5hwEp8jL9zJOwpryYEY0UesvEJd388HJQ@mail.gmail.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] Error getting mfn
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hello Konrad,

Just wondering if you forgot about this thread.

-- 
William

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 25 08:44:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 08: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 1TGQkX-0007RA-8f; Tue, 25 Sep 2012 08:44: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 1TGQkW-0007R4-58
	for xen-devel@lists.xensource.com; Tue, 25 Sep 2012 08:44:12 +0000
Received: from [85.158.143.99:61135] by server-3.bemta-4.messagelabs.com id
	B0/25-10986-BDE61605; Tue, 25 Sep 2012 08:44:11 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1348562650!22050422!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTA5ODg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5785 invoked from network); 25 Sep 2012 08:44:11 -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;
	25 Sep 2012 08:44:11 -0000
X-IronPort-AV: E=Sophos;i="4.80,479,1344211200"; d="scan'208";a="14741844"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Sep 2012 08:44: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.279.1; Tue, 25 Sep 2012 09:44: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
	1TGQkU-0003sw-Dc; Tue, 25 Sep 2012 08:44:10 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1TGQkU-000751-9M;
	Tue, 25 Sep 2012 09:44:10 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20577.28378.178321.883970@mariner.uk.xensource.com>
Date: Tue, 25 Sep 2012 09:44:10 +0100
To: Jan Beulich <JBeulich@suse.com>
In-Reply-To: <osstest-13861-mainreport@xen.org>
References: <osstest-13861-mainreport@xen.org>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [xen-unstable test] 13861: regressions - trouble:
 blocked/broken/fail/pass
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

xen.org writes ("[xen-unstable test] 13861: regressions - trouble: blocked/broken/fail/pass"):
>  build-amd64-pvops             2 host-install(2)     broken REGR. vs. 13825

This is another machine having forgotten that it was supposed to boot
from the network.  It's itch-mite, the twin of the other test box
gall-mite which had this problem yesterday.

That two identical machines have had this happen within days suggests
that somehow something done to them recently has corrupted their
CMOS, rather than it being a random event.

Jan, do you think it at all plausible that the cpuidle-related Xen bug
is somehow responsible ?  TBH it doesn't seem all that likely because
I've checked gall-mite and the CMOS is still fine, even though the
machine has experienced several of these crashes.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 25 08:44:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 08: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 1TGQkX-0007RA-8f; Tue, 25 Sep 2012 08:44: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 1TGQkW-0007R4-58
	for xen-devel@lists.xensource.com; Tue, 25 Sep 2012 08:44:12 +0000
Received: from [85.158.143.99:61135] by server-3.bemta-4.messagelabs.com id
	B0/25-10986-BDE61605; Tue, 25 Sep 2012 08:44:11 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1348562650!22050422!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTA5ODg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5785 invoked from network); 25 Sep 2012 08:44:11 -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;
	25 Sep 2012 08:44:11 -0000
X-IronPort-AV: E=Sophos;i="4.80,479,1344211200"; d="scan'208";a="14741844"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Sep 2012 08:44: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.279.1; Tue, 25 Sep 2012 09:44: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
	1TGQkU-0003sw-Dc; Tue, 25 Sep 2012 08:44:10 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1TGQkU-000751-9M;
	Tue, 25 Sep 2012 09:44:10 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20577.28378.178321.883970@mariner.uk.xensource.com>
Date: Tue, 25 Sep 2012 09:44:10 +0100
To: Jan Beulich <JBeulich@suse.com>
In-Reply-To: <osstest-13861-mainreport@xen.org>
References: <osstest-13861-mainreport@xen.org>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [xen-unstable test] 13861: regressions - trouble:
 blocked/broken/fail/pass
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

xen.org writes ("[xen-unstable test] 13861: regressions - trouble: blocked/broken/fail/pass"):
>  build-amd64-pvops             2 host-install(2)     broken REGR. vs. 13825

This is another machine having forgotten that it was supposed to boot
from the network.  It's itch-mite, the twin of the other test box
gall-mite which had this problem yesterday.

That two identical machines have had this happen within days suggests
that somehow something done to them recently has corrupted their
CMOS, rather than it being a random event.

Jan, do you think it at all plausible that the cpuidle-related Xen bug
is somehow responsible ?  TBH it doesn't seem all that likely because
I've checked gall-mite and the CMOS is still fine, even though the
machine has experienced several of these crashes.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 25 08:44:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 08:44: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 1TGQl6-0007VA-MK; Tue, 25 Sep 2012 08:44: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 1TGQl5-0007Uw-EN
	for xen-devel@lists.xen.org; Tue, 25 Sep 2012 08:44:47 +0000
Received: from [85.158.143.99:65300] by server-3.bemta-4.messagelabs.com id
	2E/26-10986-EFE61605; Tue, 25 Sep 2012 08:44:46 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1348562686!30747092!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTA5ODg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15727 invoked from network); 25 Sep 2012 08:44:46 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Sep 2012 08:44:46 -0000
X-IronPort-AV: E=Sophos;i="4.80,479,1344211200"; d="scan'208";a="14741863"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Sep 2012 08:44: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.279.1;
	Tue, 25 Sep 2012 09:44:46 +0100
Message-ID: <1348562684.3452.116.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Anthony PERARD <anthony.perard@citrix.com>
Date: Tue, 25 Sep 2012 09:44:44 +0100
In-Reply-To: <1347906148-9606-4-git-send-email-anthony.perard@citrix.com>
References: <1347906148-9606-1-git-send-email-anthony.perard@citrix.com>
	<1347906148-9606-4-git-send-email-anthony.perard@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Xen Devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH V2 3/9] libxl_json: Introduce
 libxl__json_object_to_yajl_gen.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2012-09-17 at 19:22 +0100, Anthony PERARD wrote:
> This function converts a libxl__json_object to yajl by calling every yajl_gen_*
> function on a preallocated yajl_gen hand.
> 
> This helps to integrate a json_object into an already existing yajl_gen tree.
> 
> This function is used in a later patch.
> 
> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
> ---
>  tools/libxl/libxl_internal.h |  3 +++
>  tools/libxl/libxl_json.c     | 63 ++++++++++++++++++++++++++++++++++++++++++++
>  2 files changed, 66 insertions(+)
> 
> diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
> index 3c2dcaa..9c1482d 100644
> --- a/tools/libxl/libxl_internal.h
> +++ b/tools/libxl/libxl_internal.h
> [...]

> +    }
> +    case JSON_ERROR:

I can't see this being used anywhere, could it just be removed from the
enum?

> +    case JSON_ANY:

Is JSON_ANY sort of like a JSON "void *"? Is it ever valid to be passed
one here, IOW does this represent a coding error (==abort()) or a run
time one (== log something)?

> +    default:

If you skip this default case then some compilers will warn (a runtime
error) if we forget to add a new JSON_FOO here.

> +        return -1;
> +    }
> +}
> +
>  
>  /*
>   * JSON callbacks



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 25 08:44:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 08:44: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 1TGQl6-0007VA-MK; Tue, 25 Sep 2012 08:44: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 1TGQl5-0007Uw-EN
	for xen-devel@lists.xen.org; Tue, 25 Sep 2012 08:44:47 +0000
Received: from [85.158.143.99:65300] by server-3.bemta-4.messagelabs.com id
	2E/26-10986-EFE61605; Tue, 25 Sep 2012 08:44:46 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1348562686!30747092!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTA5ODg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15727 invoked from network); 25 Sep 2012 08:44:46 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Sep 2012 08:44:46 -0000
X-IronPort-AV: E=Sophos;i="4.80,479,1344211200"; d="scan'208";a="14741863"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Sep 2012 08:44: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.279.1;
	Tue, 25 Sep 2012 09:44:46 +0100
Message-ID: <1348562684.3452.116.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Anthony PERARD <anthony.perard@citrix.com>
Date: Tue, 25 Sep 2012 09:44:44 +0100
In-Reply-To: <1347906148-9606-4-git-send-email-anthony.perard@citrix.com>
References: <1347906148-9606-1-git-send-email-anthony.perard@citrix.com>
	<1347906148-9606-4-git-send-email-anthony.perard@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Xen Devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH V2 3/9] libxl_json: Introduce
 libxl__json_object_to_yajl_gen.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2012-09-17 at 19:22 +0100, Anthony PERARD wrote:
> This function converts a libxl__json_object to yajl by calling every yajl_gen_*
> function on a preallocated yajl_gen hand.
> 
> This helps to integrate a json_object into an already existing yajl_gen tree.
> 
> This function is used in a later patch.
> 
> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
> ---
>  tools/libxl/libxl_internal.h |  3 +++
>  tools/libxl/libxl_json.c     | 63 ++++++++++++++++++++++++++++++++++++++++++++
>  2 files changed, 66 insertions(+)
> 
> diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
> index 3c2dcaa..9c1482d 100644
> --- a/tools/libxl/libxl_internal.h
> +++ b/tools/libxl/libxl_internal.h
> [...]

> +    }
> +    case JSON_ERROR:

I can't see this being used anywhere, could it just be removed from the
enum?

> +    case JSON_ANY:

Is JSON_ANY sort of like a JSON "void *"? Is it ever valid to be passed
one here, IOW does this represent a coding error (==abort()) or a run
time one (== log something)?

> +    default:

If you skip this default case then some compilers will warn (a runtime
error) if we forget to add a new JSON_FOO here.

> +        return -1;
> +    }
> +}
> +
>  
>  /*
>   * JSON callbacks



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 25 08:51:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 08: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 1TGQr4-0007mp-Gg; Tue, 25 Sep 2012 08:50:58 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1TGQr2-0007mi-RN
	for xen-devel@lists.xen.org; Tue, 25 Sep 2012 08:50:57 +0000
Received: from [85.158.137.99:15123] by server-5.bemta-3.messagelabs.com id
	F0/94-13133-F6071605; Tue, 25 Sep 2012 08:50:55 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-217.messagelabs.com!1348563054!17814108!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=UPPERCASE_25_50
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5869 invoked from network); 25 Sep 2012 08:50:54 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-11.tower-217.messagelabs.com with SMTP;
	25 Sep 2012 08:50:54 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 25 Sep 2012 09:50:54 +0100
Message-Id: <50618CA4020000780009D8F2@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 25 Sep 2012 09:51:16 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__PartBD8C8194.0__="
Subject: [Xen-devel] [PATCH] linux-2.6.18: add backward-compatibility
 configure options
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
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.

--=__PartBD8C8194.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/drivers/xen/Kconfig
+++ b/drivers/xen/Kconfig
@@ -324,6 +324,24 @@ choice
 	config XEN_COMPAT_030100_AND_LATER
 		bool "3.1.0 and later"
=20
+	config XEN_COMPAT_030200_AND_LATER
+		bool "3.2.0 and later"
+
+	config XEN_COMPAT_030300_AND_LATER
+		bool "3.3.0 and later"
+
+	config XEN_COMPAT_030400_AND_LATER
+		bool "3.4.0 and later"
+
+	config XEN_COMPAT_040000_AND_LATER
+		bool "4.0.0 and later"
+
+	config XEN_COMPAT_040100_AND_LATER
+		bool "4.1.0 and later"
+
+	config XEN_COMPAT_040200_AND_LATER
+		bool "4.2.0 and later"
+
 	config XEN_COMPAT_LATEST_ONLY
 		bool "no compatibility code"
=20
@@ -332,6 +350,12 @@ endchoice
 config XEN_COMPAT
 	hex
 	default 0xffffff if XEN_COMPAT_LATEST_ONLY
+	default 0x040200 if XEN_COMPAT_040200_AND_LATER
+	default 0x040100 if XEN_COMPAT_040100_AND_LATER
+	default 0x040000 if XEN_COMPAT_040000_AND_LATER
+	default 0x030400 if XEN_COMPAT_030400_AND_LATER
+	default 0x030300 if XEN_COMPAT_030300_AND_LATER
+	default 0x030200 if XEN_COMPAT_030200_AND_LATER
 	default 0x030100 if XEN_COMPAT_030100_AND_LATER
 	default 0x030004 if XEN_COMPAT_030004_AND_LATER
 	default 0x030002 if XEN_COMPAT_030002_AND_LATER




--=__PartBD8C8194.0__=
Content-Type: text/plain; name="xen-kconfig-compat.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="xen-kconfig-compat.patch"

add backward-compatibility configure options=0A=0ASigned-off-by: Jan =
Beulich <jbeulich@suse.com>=0A=0A--- a/drivers/xen/Kconfig=0A+++ b/drivers/=
xen/Kconfig=0A@@ -324,6 +324,24 @@ choice=0A 	config XEN_COMPAT_030100_AN=
D_LATER=0A 		bool "3.1.0 and later"=0A =0A+	config XEN_COMPAT_0=
30200_AND_LATER=0A+		bool "3.2.0 and later"=0A+=0A+	config =
XEN_COMPAT_030300_AND_LATER=0A+		bool "3.3.0 and later"=0A+=0A+	=
config XEN_COMPAT_030400_AND_LATER=0A+		bool "3.4.0 and later"=0A+=
=0A+	config XEN_COMPAT_040000_AND_LATER=0A+		bool "4.0.0 and =
later"=0A+=0A+	config XEN_COMPAT_040100_AND_LATER=0A+		bool =
"4.1.0 and later"=0A+=0A+	config XEN_COMPAT_040200_AND_LATER=0A+		=
bool "4.2.0 and later"=0A+=0A 	config XEN_COMPAT_LATEST_ONLY=0A 		=
bool "no compatibility code"=0A =0A@@ -332,6 +350,12 @@ endchoice=0A =
config XEN_COMPAT=0A 	hex=0A 	default 0xffffff if XEN_COMPAT_LATEST_ONLY=
=0A+	default 0x040200 if XEN_COMPAT_040200_AND_LATER=0A+	default =
0x040100 if XEN_COMPAT_040100_AND_LATER=0A+	default 0x040000 if =
XEN_COMPAT_040000_AND_LATER=0A+	default 0x030400 if XEN_COMPAT_030400_AND_L=
ATER=0A+	default 0x030300 if XEN_COMPAT_030300_AND_LATER=0A+	=
default 0x030200 if XEN_COMPAT_030200_AND_LATER=0A 	default 0x030100 =
if XEN_COMPAT_030100_AND_LATER=0A 	default 0x030004 if XEN_COMPAT_0300=
04_AND_LATER=0A 	default 0x030002 if XEN_COMPAT_030002_AND_LATER=0A
--=__PartBD8C8194.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

--=__PartBD8C8194.0__=--


From xen-devel-bounces@lists.xen.org Tue Sep 25 08:51:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 08: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 1TGQr4-0007mp-Gg; Tue, 25 Sep 2012 08:50:58 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1TGQr2-0007mi-RN
	for xen-devel@lists.xen.org; Tue, 25 Sep 2012 08:50:57 +0000
Received: from [85.158.137.99:15123] by server-5.bemta-3.messagelabs.com id
	F0/94-13133-F6071605; Tue, 25 Sep 2012 08:50:55 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-217.messagelabs.com!1348563054!17814108!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=UPPERCASE_25_50
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5869 invoked from network); 25 Sep 2012 08:50:54 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-11.tower-217.messagelabs.com with SMTP;
	25 Sep 2012 08:50:54 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 25 Sep 2012 09:50:54 +0100
Message-Id: <50618CA4020000780009D8F2@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 25 Sep 2012 09:51:16 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__PartBD8C8194.0__="
Subject: [Xen-devel] [PATCH] linux-2.6.18: add backward-compatibility
 configure options
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
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.

--=__PartBD8C8194.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/drivers/xen/Kconfig
+++ b/drivers/xen/Kconfig
@@ -324,6 +324,24 @@ choice
 	config XEN_COMPAT_030100_AND_LATER
 		bool "3.1.0 and later"
=20
+	config XEN_COMPAT_030200_AND_LATER
+		bool "3.2.0 and later"
+
+	config XEN_COMPAT_030300_AND_LATER
+		bool "3.3.0 and later"
+
+	config XEN_COMPAT_030400_AND_LATER
+		bool "3.4.0 and later"
+
+	config XEN_COMPAT_040000_AND_LATER
+		bool "4.0.0 and later"
+
+	config XEN_COMPAT_040100_AND_LATER
+		bool "4.1.0 and later"
+
+	config XEN_COMPAT_040200_AND_LATER
+		bool "4.2.0 and later"
+
 	config XEN_COMPAT_LATEST_ONLY
 		bool "no compatibility code"
=20
@@ -332,6 +350,12 @@ endchoice
 config XEN_COMPAT
 	hex
 	default 0xffffff if XEN_COMPAT_LATEST_ONLY
+	default 0x040200 if XEN_COMPAT_040200_AND_LATER
+	default 0x040100 if XEN_COMPAT_040100_AND_LATER
+	default 0x040000 if XEN_COMPAT_040000_AND_LATER
+	default 0x030400 if XEN_COMPAT_030400_AND_LATER
+	default 0x030300 if XEN_COMPAT_030300_AND_LATER
+	default 0x030200 if XEN_COMPAT_030200_AND_LATER
 	default 0x030100 if XEN_COMPAT_030100_AND_LATER
 	default 0x030004 if XEN_COMPAT_030004_AND_LATER
 	default 0x030002 if XEN_COMPAT_030002_AND_LATER




--=__PartBD8C8194.0__=
Content-Type: text/plain; name="xen-kconfig-compat.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="xen-kconfig-compat.patch"

add backward-compatibility configure options=0A=0ASigned-off-by: Jan =
Beulich <jbeulich@suse.com>=0A=0A--- a/drivers/xen/Kconfig=0A+++ b/drivers/=
xen/Kconfig=0A@@ -324,6 +324,24 @@ choice=0A 	config XEN_COMPAT_030100_AN=
D_LATER=0A 		bool "3.1.0 and later"=0A =0A+	config XEN_COMPAT_0=
30200_AND_LATER=0A+		bool "3.2.0 and later"=0A+=0A+	config =
XEN_COMPAT_030300_AND_LATER=0A+		bool "3.3.0 and later"=0A+=0A+	=
config XEN_COMPAT_030400_AND_LATER=0A+		bool "3.4.0 and later"=0A+=
=0A+	config XEN_COMPAT_040000_AND_LATER=0A+		bool "4.0.0 and =
later"=0A+=0A+	config XEN_COMPAT_040100_AND_LATER=0A+		bool =
"4.1.0 and later"=0A+=0A+	config XEN_COMPAT_040200_AND_LATER=0A+		=
bool "4.2.0 and later"=0A+=0A 	config XEN_COMPAT_LATEST_ONLY=0A 		=
bool "no compatibility code"=0A =0A@@ -332,6 +350,12 @@ endchoice=0A =
config XEN_COMPAT=0A 	hex=0A 	default 0xffffff if XEN_COMPAT_LATEST_ONLY=
=0A+	default 0x040200 if XEN_COMPAT_040200_AND_LATER=0A+	default =
0x040100 if XEN_COMPAT_040100_AND_LATER=0A+	default 0x040000 if =
XEN_COMPAT_040000_AND_LATER=0A+	default 0x030400 if XEN_COMPAT_030400_AND_L=
ATER=0A+	default 0x030300 if XEN_COMPAT_030300_AND_LATER=0A+	=
default 0x030200 if XEN_COMPAT_030200_AND_LATER=0A 	default 0x030100 =
if XEN_COMPAT_030100_AND_LATER=0A 	default 0x030004 if XEN_COMPAT_0300=
04_AND_LATER=0A 	default 0x030002 if XEN_COMPAT_030002_AND_LATER=0A
--=__PartBD8C8194.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

--=__PartBD8C8194.0__=--


From xen-devel-bounces@lists.xen.org Tue Sep 25 08:54:06 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 08: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 1TGQtw-0007tP-3z; Tue, 25 Sep 2012 08:53: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 1TGQtu-0007tJ-R3
	for xen-devel@lists.xen.org; Tue, 25 Sep 2012 08:53:55 +0000
Received: from [85.158.137.99:2313] by server-14.bemta-3.messagelabs.com id
	DE/23-21431-22171605; Tue, 25 Sep 2012 08:53:54 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-7.tower-217.messagelabs.com!1348563232!14218622!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30210 invoked from network); 25 Sep 2012 08:53:53 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-7.tower-217.messagelabs.com with SMTP;
	25 Sep 2012 08:53:53 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 25 Sep 2012 09:53:52 +0100
Message-Id: <50618D58020000780009D8F7@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 25 Sep 2012 09:54:16 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part00313C28.0__="
Subject: [Xen-devel] [PATCH] linux-2.6.18/PCI: suppress bogus warning on old
 hypervisors
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<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.

--=__Part00313C28.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

pci_bus_remove_wrapper() warned even for the -ENOSYS case. By detecting
the missing support early (in pci_bus_probe_wrapper()) we can avoid
this by removing the hooks altogether in this case.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/drivers/xen/core/pci.c
+++ b/drivers/xen/core/pci.c
@@ -45,8 +45,21 @@ static int pci_bus_probe_wrapper(struct=20
 		r =3D HYPERVISOR_physdev_op(PHYSDEVOP_manage_pci_add,
 					  &manage_pci);
 	}
-	if (r && r !=3D -ENOSYS)
+
+	switch (r) {
+	case 0:
+		break;
+#if CONFIG_XEN_COMPAT < 0x030300
+	case -ENOSYS:
+		if (!manage_pci_ext.is_virtfn && !manage_pci_ext.is_extfn) =
{
+			pci_bus_type.probe =3D pci_bus_probe;
+			pci_bus_type.remove =3D pci_bus_remove;
+		}
+		break;
+#endif
+	default:
 		return r;
+	}
=20
 	r =3D pci_bus_probe(dev);
 	return r;




--=__Part00313C28.0__=
Content-Type: text/plain; name="xen-pci-bus-remove-warning.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="xen-pci-bus-remove-warning.patch"

PCI: suppress bogus warning on old hypervisors=0A=0Apci_bus_remove_wrapper(=
) warned even for the -ENOSYS case. By detecting=0Athe missing support =
early (in pci_bus_probe_wrapper()) we can avoid=0Athis by removing the =
hooks altogether in this case.=0A=0ASigned-off-by: Jan Beulich <jbeulich@su=
se.com>=0A=0A--- a/drivers/xen/core/pci.c=0A+++ b/drivers/xen/core/pci.c=0A=
@@ -45,8 +45,21 @@ static int pci_bus_probe_wrapper(struct =0A 		r =
=3D HYPERVISOR_physdev_op(PHYSDEVOP_manage_pci_add,=0A 				=
	  &manage_pci);=0A 	}=0A-	if (r && r !=3D -ENOSYS)=0A+=0A+	=
switch (r) {=0A+	case 0:=0A+		break;=0A+#if CONFIG_XEN_CO=
MPAT < 0x030300=0A+	case -ENOSYS:=0A+		if (!manage_pci_ext=
.is_virtfn && !manage_pci_ext.is_extfn) {=0A+			pci_bus_typ=
e.probe =3D pci_bus_probe;=0A+			pci_bus_type.remove =3D =
pci_bus_remove;=0A+		}=0A+		break;=0A+#endif=0A+	=
default:=0A 		return r;=0A+	}=0A =0A 	r =3D pci_bus_probe=
(dev);=0A 	return r;=0A
--=__Part00313C28.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

--=__Part00313C28.0__=--


From xen-devel-bounces@lists.xen.org Tue Sep 25 08:54:06 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 08: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 1TGQtw-0007tP-3z; Tue, 25 Sep 2012 08:53: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 1TGQtu-0007tJ-R3
	for xen-devel@lists.xen.org; Tue, 25 Sep 2012 08:53:55 +0000
Received: from [85.158.137.99:2313] by server-14.bemta-3.messagelabs.com id
	DE/23-21431-22171605; Tue, 25 Sep 2012 08:53:54 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-7.tower-217.messagelabs.com!1348563232!14218622!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30210 invoked from network); 25 Sep 2012 08:53:53 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-7.tower-217.messagelabs.com with SMTP;
	25 Sep 2012 08:53:53 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 25 Sep 2012 09:53:52 +0100
Message-Id: <50618D58020000780009D8F7@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 25 Sep 2012 09:54:16 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part00313C28.0__="
Subject: [Xen-devel] [PATCH] linux-2.6.18/PCI: suppress bogus warning on old
 hypervisors
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<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.

--=__Part00313C28.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

pci_bus_remove_wrapper() warned even for the -ENOSYS case. By detecting
the missing support early (in pci_bus_probe_wrapper()) we can avoid
this by removing the hooks altogether in this case.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/drivers/xen/core/pci.c
+++ b/drivers/xen/core/pci.c
@@ -45,8 +45,21 @@ static int pci_bus_probe_wrapper(struct=20
 		r =3D HYPERVISOR_physdev_op(PHYSDEVOP_manage_pci_add,
 					  &manage_pci);
 	}
-	if (r && r !=3D -ENOSYS)
+
+	switch (r) {
+	case 0:
+		break;
+#if CONFIG_XEN_COMPAT < 0x030300
+	case -ENOSYS:
+		if (!manage_pci_ext.is_virtfn && !manage_pci_ext.is_extfn) =
{
+			pci_bus_type.probe =3D pci_bus_probe;
+			pci_bus_type.remove =3D pci_bus_remove;
+		}
+		break;
+#endif
+	default:
 		return r;
+	}
=20
 	r =3D pci_bus_probe(dev);
 	return r;




--=__Part00313C28.0__=
Content-Type: text/plain; name="xen-pci-bus-remove-warning.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="xen-pci-bus-remove-warning.patch"

PCI: suppress bogus warning on old hypervisors=0A=0Apci_bus_remove_wrapper(=
) warned even for the -ENOSYS case. By detecting=0Athe missing support =
early (in pci_bus_probe_wrapper()) we can avoid=0Athis by removing the =
hooks altogether in this case.=0A=0ASigned-off-by: Jan Beulich <jbeulich@su=
se.com>=0A=0A--- a/drivers/xen/core/pci.c=0A+++ b/drivers/xen/core/pci.c=0A=
@@ -45,8 +45,21 @@ static int pci_bus_probe_wrapper(struct =0A 		r =
=3D HYPERVISOR_physdev_op(PHYSDEVOP_manage_pci_add,=0A 				=
	  &manage_pci);=0A 	}=0A-	if (r && r !=3D -ENOSYS)=0A+=0A+	=
switch (r) {=0A+	case 0:=0A+		break;=0A+#if CONFIG_XEN_CO=
MPAT < 0x030300=0A+	case -ENOSYS:=0A+		if (!manage_pci_ext=
.is_virtfn && !manage_pci_ext.is_extfn) {=0A+			pci_bus_typ=
e.probe =3D pci_bus_probe;=0A+			pci_bus_type.remove =3D =
pci_bus_remove;=0A+		}=0A+		break;=0A+#endif=0A+	=
default:=0A 		return r;=0A+	}=0A =0A 	r =3D pci_bus_probe=
(dev);=0A 	return r;=0A
--=__Part00313C28.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

--=__Part00313C28.0__=--


From xen-devel-bounces@lists.xen.org Tue Sep 25 08:54:50 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 08:54:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGQue-0007xu-IK; Tue, 25 Sep 2012 08:54: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 1TGQud-0007xe-32
	for xen-devel@lists.xen.org; Tue, 25 Sep 2012 08:54:39 +0000
Received: from [85.158.143.35:23816] by server-1.bemta-4.messagelabs.com id
	6A/90-05684-E4171605; Tue, 25 Sep 2012 08:54:38 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1348563269!16203339!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTA5ODg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6880 invoked from network); 25 Sep 2012 08:54:30 -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;
	25 Sep 2012 08:54:30 -0000
X-IronPort-AV: E=Sophos;i="4.80,481,1344211200"; d="scan'208";a="14742357"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Sep 2012 08:54: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.279.1;
	Tue, 25 Sep 2012 09:54:15 +0100
Message-ID: <1348563254.3452.120.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Anthony PERARD <anthony.perard@citrix.com>
Date: Tue, 25 Sep 2012 09:54:14 +0100
In-Reply-To: <1347906148-9606-5-git-send-email-anthony.perard@citrix.com>
References: <1347906148-9606-1-git-send-email-anthony.perard@citrix.com>
	<1347906148-9606-5-git-send-email-anthony.perard@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Xen Devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH V2 4/9] libxl_qmp: Introduces helpers to
 create an argument list.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2012-09-17 at 19:22 +0100, Anthony PERARD wrote:
> Those functions will be used to create a "list" of parameters that contain more
> than just strings. This list is converted by qmp_send to a string to be sent to
> QEMU.
> 
> Those functions will be used in the next two patches, so right now there are
> not compiled.
> 
> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
> ---
>  tools/libxl/libxl_qmp.c | 53 +++++++++++++++++++++++++++++++++++++++++++++++++
>  1 file changed, 53 insertions(+)
> 
> diff --git a/tools/libxl/libxl_qmp.c b/tools/libxl/libxl_qmp.c
> index 07a8bd5..1dd5c6c 100644
> --- a/tools/libxl/libxl_qmp.c
> +++ b/tools/libxl/libxl_qmp.c
> @@ -623,6 +623,59 @@ static void qmp_free_handler(libxl__qmp_handler *qmp)
>      free(qmp);
>  }
>  
> +#if 0
> +/*
> + * QMP Parameters Helpers
> + * Those functions does not use the gc, because of the internal usage of
> + * flexarray that does not support it.
> + * The allocated *param need to be free with libxl__json_object_free(gc, param)
> + */
> +static void qmp_parameters_common_add(libxl__gc *gc,
> +                                      libxl__json_object **param,
> +                                      const char *name,
> +                                      libxl__json_object *obj)
> +{
> +    libxl__json_map_node *arg = NULL;
> +
> +    if (!*param) {
> +        *param = libxl__json_object_alloc(NOGC, JSON_MAP);
> +    }
> +
> +    arg = libxl__zalloc(NOGC, sizeof(*arg));
> +
> +    arg->map_key = libxl__strdup(NOGC, name);
> +    arg->obj = obj;
> +
> +    flexarray_append((*param)->u.map, arg);
> +}
> +
> +static void qmp_parameters_add_string(libxl__gc *gc,
> +                                      libxl__json_object **param,
> +                                      const char *name, const char *argument)
> +{
> +    libxl__json_object *obj;
> +
> +    obj = libxl__json_object_alloc(NOGC, JSON_STRING);
> +    obj->u.string = libxl__strdup(NOGC, argument);
> +
> +    qmp_parameters_common_add(gc, param, name, obj);
> +}
> +
> +static void qmp_parameters_add_bool(libxl__gc *gc,
> +                                    libxl__json_object **param,
> +                                    const char *name, bool b)
> +{
> +    libxl__json_object *obj;
> +
> +    obj = libxl__json_object_alloc(NOGC, JSON_TRUE);

This is pre-existing, but treating JSON_TRUE and JSON_FALSE as distinct
node types and not specific values of the (currently non-existent)
JSON_BOOL type is a bit odd.

I noticed it because you don't use the b param here... 

> +    qmp_parameters_common_add(gc, param, name, obj);
> +}
> +
> +#define QMP_PARAMETERS_SPRINTF(gc, args, name, format, ...) \
> +    qmp_parameters_add_string(gc, args, name, \
> +                              libxl__sprintf(gc, format, __VA_ARGS__))

I think it would be valid, and in keeping with the similar GC_SPRINTFOO
macros, to make gc and perhaps args required in the calling environment
rather than passing them, if you wanted to.

> +#endif
> +
>  /*
>   * API
>   */



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 25 08:54:50 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 08:54:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGQue-0007xu-IK; Tue, 25 Sep 2012 08:54: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 1TGQud-0007xe-32
	for xen-devel@lists.xen.org; Tue, 25 Sep 2012 08:54:39 +0000
Received: from [85.158.143.35:23816] by server-1.bemta-4.messagelabs.com id
	6A/90-05684-E4171605; Tue, 25 Sep 2012 08:54:38 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1348563269!16203339!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTA5ODg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6880 invoked from network); 25 Sep 2012 08:54:30 -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;
	25 Sep 2012 08:54:30 -0000
X-IronPort-AV: E=Sophos;i="4.80,481,1344211200"; d="scan'208";a="14742357"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Sep 2012 08:54: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.279.1;
	Tue, 25 Sep 2012 09:54:15 +0100
Message-ID: <1348563254.3452.120.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Anthony PERARD <anthony.perard@citrix.com>
Date: Tue, 25 Sep 2012 09:54:14 +0100
In-Reply-To: <1347906148-9606-5-git-send-email-anthony.perard@citrix.com>
References: <1347906148-9606-1-git-send-email-anthony.perard@citrix.com>
	<1347906148-9606-5-git-send-email-anthony.perard@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Xen Devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH V2 4/9] libxl_qmp: Introduces helpers to
 create an argument list.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2012-09-17 at 19:22 +0100, Anthony PERARD wrote:
> Those functions will be used to create a "list" of parameters that contain more
> than just strings. This list is converted by qmp_send to a string to be sent to
> QEMU.
> 
> Those functions will be used in the next two patches, so right now there are
> not compiled.
> 
> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
> ---
>  tools/libxl/libxl_qmp.c | 53 +++++++++++++++++++++++++++++++++++++++++++++++++
>  1 file changed, 53 insertions(+)
> 
> diff --git a/tools/libxl/libxl_qmp.c b/tools/libxl/libxl_qmp.c
> index 07a8bd5..1dd5c6c 100644
> --- a/tools/libxl/libxl_qmp.c
> +++ b/tools/libxl/libxl_qmp.c
> @@ -623,6 +623,59 @@ static void qmp_free_handler(libxl__qmp_handler *qmp)
>      free(qmp);
>  }
>  
> +#if 0
> +/*
> + * QMP Parameters Helpers
> + * Those functions does not use the gc, because of the internal usage of
> + * flexarray that does not support it.
> + * The allocated *param need to be free with libxl__json_object_free(gc, param)
> + */
> +static void qmp_parameters_common_add(libxl__gc *gc,
> +                                      libxl__json_object **param,
> +                                      const char *name,
> +                                      libxl__json_object *obj)
> +{
> +    libxl__json_map_node *arg = NULL;
> +
> +    if (!*param) {
> +        *param = libxl__json_object_alloc(NOGC, JSON_MAP);
> +    }
> +
> +    arg = libxl__zalloc(NOGC, sizeof(*arg));
> +
> +    arg->map_key = libxl__strdup(NOGC, name);
> +    arg->obj = obj;
> +
> +    flexarray_append((*param)->u.map, arg);
> +}
> +
> +static void qmp_parameters_add_string(libxl__gc *gc,
> +                                      libxl__json_object **param,
> +                                      const char *name, const char *argument)
> +{
> +    libxl__json_object *obj;
> +
> +    obj = libxl__json_object_alloc(NOGC, JSON_STRING);
> +    obj->u.string = libxl__strdup(NOGC, argument);
> +
> +    qmp_parameters_common_add(gc, param, name, obj);
> +}
> +
> +static void qmp_parameters_add_bool(libxl__gc *gc,
> +                                    libxl__json_object **param,
> +                                    const char *name, bool b)
> +{
> +    libxl__json_object *obj;
> +
> +    obj = libxl__json_object_alloc(NOGC, JSON_TRUE);

This is pre-existing, but treating JSON_TRUE and JSON_FALSE as distinct
node types and not specific values of the (currently non-existent)
JSON_BOOL type is a bit odd.

I noticed it because you don't use the b param here... 

> +    qmp_parameters_common_add(gc, param, name, obj);
> +}
> +
> +#define QMP_PARAMETERS_SPRINTF(gc, args, name, format, ...) \
> +    qmp_parameters_add_string(gc, args, name, \
> +                              libxl__sprintf(gc, format, __VA_ARGS__))

I think it would be valid, and in keeping with the similar GC_SPRINTFOO
macros, to make gc and perhaps args required in the calling environment
rather than passing them, if you wanted to.

> +#endif
> +
>  /*
>   * API
>   */



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 25 08:57:06 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 08:57:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGQwq-00088P-3a; Tue, 25 Sep 2012 08:56: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 1TGQwo-00088E-9p
	for xen-devel@lists.xen.org; Tue, 25 Sep 2012 08:56:54 +0000
Received: from [85.158.138.51:49325] by server-2.bemta-3.messagelabs.com id
	3C/73-04862-5D171605; Tue, 25 Sep 2012 08:56:53 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1348563412!31823955!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTA5ODg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7577 invoked from network); 25 Sep 2012 08:56:52 -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;
	25 Sep 2012 08:56:52 -0000
X-IronPort-AV: E=Sophos;i="4.80,481,1344211200"; d="scan'208";a="14742434"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Sep 2012 08:56: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.279.1;
	Tue, 25 Sep 2012 09:56:52 +0100
Message-ID: <1348563410.3452.121.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Anthony PERARD <anthony.perard@citrix.com>
Date: Tue, 25 Sep 2012 09:56:50 +0100
In-Reply-To: <1347906148-9606-6-git-send-email-anthony.perard@citrix.com>
References: <1347906148-9606-1-git-send-email-anthony.perard@citrix.com>
	<1347906148-9606-6-git-send-email-anthony.perard@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Xen Devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH V2 5/9] libxl_qmp: Use qmp_parameters_*
 functions for param list of a QMP command.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2012-09-17 at 19:22 +0100, Anthony PERARD wrote:
> Signed-off-by: Anthony PERARD <anthony.perard@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 Sep 25 08:57:06 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 08:57:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGQwq-00088P-3a; Tue, 25 Sep 2012 08:56: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 1TGQwo-00088E-9p
	for xen-devel@lists.xen.org; Tue, 25 Sep 2012 08:56:54 +0000
Received: from [85.158.138.51:49325] by server-2.bemta-3.messagelabs.com id
	3C/73-04862-5D171605; Tue, 25 Sep 2012 08:56:53 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1348563412!31823955!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTA5ODg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7577 invoked from network); 25 Sep 2012 08:56:52 -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;
	25 Sep 2012 08:56:52 -0000
X-IronPort-AV: E=Sophos;i="4.80,481,1344211200"; d="scan'208";a="14742434"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Sep 2012 08:56: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.279.1;
	Tue, 25 Sep 2012 09:56:52 +0100
Message-ID: <1348563410.3452.121.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Anthony PERARD <anthony.perard@citrix.com>
Date: Tue, 25 Sep 2012 09:56:50 +0100
In-Reply-To: <1347906148-9606-6-git-send-email-anthony.perard@citrix.com>
References: <1347906148-9606-1-git-send-email-anthony.perard@citrix.com>
	<1347906148-9606-6-git-send-email-anthony.perard@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Xen Devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH V2 5/9] libxl_qmp: Use qmp_parameters_*
 functions for param list of a QMP command.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2012-09-17 at 19:22 +0100, Anthony PERARD wrote:
> Signed-off-by: Anthony PERARD <anthony.perard@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 Sep 25 08:57:59 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 08:57:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGQxj-0008DZ-Hj; Tue, 25 Sep 2012 08:57: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 1TGQxi-0008DN-Gv
	for xen-devel@lists.xen.org; Tue, 25 Sep 2012 08:57:50 +0000
Received: from [85.158.139.83:2603] by server-3.bemta-5.messagelabs.com id
	00/1B-16108-D0271605; Tue, 25 Sep 2012 08:57:49 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1348563468!28113303!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTA5ODg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32293 invoked from network); 25 Sep 2012 08:57:49 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Sep 2012 08:57:49 -0000
X-IronPort-AV: E=Sophos;i="4.80,481,1344211200"; d="scan'208";a="14742472"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Sep 2012 08:57: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.279.1;
	Tue, 25 Sep 2012 09:57:48 +0100
Message-ID: <1348563466.3452.122.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Anthony PERARD <anthony.perard@citrix.com>
Date: Tue, 25 Sep 2012 09:57:46 +0100
In-Reply-To: <1347906148-9606-7-git-send-email-anthony.perard@citrix.com>
References: <1347906148-9606-1-git-send-email-anthony.perard@citrix.com>
	<1347906148-9606-7-git-send-email-anthony.perard@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Xen Devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH V2 6/9] libxl_qmp: Simplify run of single
	QMP commands.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2012-09-17 at 19:22 +0100, Anthony PERARD wrote:
> This new function connects to QEMU, sends the command and disconnects.
> 
> Signed-off-by: Anthony PERARD <anthony.perard@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 Sep 25 08:57:59 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 08:57:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGQxj-0008DZ-Hj; Tue, 25 Sep 2012 08:57: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 1TGQxi-0008DN-Gv
	for xen-devel@lists.xen.org; Tue, 25 Sep 2012 08:57:50 +0000
Received: from [85.158.139.83:2603] by server-3.bemta-5.messagelabs.com id
	00/1B-16108-D0271605; Tue, 25 Sep 2012 08:57:49 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1348563468!28113303!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTA5ODg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32293 invoked from network); 25 Sep 2012 08:57:49 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Sep 2012 08:57:49 -0000
X-IronPort-AV: E=Sophos;i="4.80,481,1344211200"; d="scan'208";a="14742472"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Sep 2012 08:57: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.279.1;
	Tue, 25 Sep 2012 09:57:48 +0100
Message-ID: <1348563466.3452.122.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Anthony PERARD <anthony.perard@citrix.com>
Date: Tue, 25 Sep 2012 09:57:46 +0100
In-Reply-To: <1347906148-9606-7-git-send-email-anthony.perard@citrix.com>
References: <1347906148-9606-1-git-send-email-anthony.perard@citrix.com>
	<1347906148-9606-7-git-send-email-anthony.perard@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Xen Devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH V2 6/9] libxl_qmp: Simplify run of single
	QMP commands.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2012-09-17 at 19:22 +0100, Anthony PERARD wrote:
> This new function connects to QEMU, sends the command and disconnects.
> 
> Signed-off-by: Anthony PERARD <anthony.perard@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 Sep 25 09:01:22 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 09:01:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGR0w-0008Tu-Bu; Tue, 25 Sep 2012 09:01: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 1TGR0u-0008Tj-EH
	for xen-devel@lists.xen.org; Tue, 25 Sep 2012 09:01:08 +0000
Received: from [85.158.137.99:14780] by server-10.bemta-3.messagelabs.com id
	18/87-10411-3D271605; Tue, 25 Sep 2012 09:01:07 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-16.tower-217.messagelabs.com!1348563666!19009545!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29782 invoked from network); 25 Sep 2012 09:01:06 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-16.tower-217.messagelabs.com with SMTP;
	25 Sep 2012 09:01:06 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 25 Sep 2012 10:01:06 +0100
Message-Id: <50618F09020000780009D900@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 25 Sep 2012 10:01:29 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__PartD2E3EEF9.0__="
Subject: [Xen-devel] [PATCH] linux-2.6.18: IRQ/evtchn: adjust affinity
	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.

--=__PartD2E3EEF9.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Virtually forever, Xen code diverged from native in the way affinities
of IRQs got managed: Native, even if restricting handling of an IRQ to
a single CPU e.g. because of APIC ID constraints, it would still keep
the affinity set to all permitted CPUs. Xen instead restricted the
affinity along with the handling. Retain that behavior only for per-CPU
IRQs (and for other dynamic ones on their initial setup, albeit perhaps
event that is still too strict), but make physical ones (and dynamic
ones if their affinity gets adjusted an the fly) match native behavior.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/drivers/xen/core/evtchn.c
+++ b/drivers/xen/core/evtchn.c
@@ -137,21 +137,28 @@ static inline unsigned long active_evtch
 		~sh->evtchn_mask[idx]);
 }
=20
-static void bind_evtchn_to_cpu(unsigned int chn, unsigned int cpu)
+static void _bind_evtchn_to_cpu(unsigned int chn, unsigned int cpu, int =
irq,
+				cpumask_t cpumask)
 {
 	shared_info_t *s =3D HYPERVISOR_shared_info;
-	int irq =3D evtchn_to_irq[chn];
=20
 	BUG_ON(!test_bit(chn, s->evtchn_mask));
=20
-	if (irq !=3D -1)
-		set_native_irq_info(irq, cpumask_of_cpu(cpu));
+	if (irq >=3D 0) {
+		BUG_ON(!cpu_isset(cpu, cpumask));
+		set_native_irq_info(irq, cpumask);
+	}
=20
 	clear_bit(chn, (unsigned long *)cpu_evtchn_mask[cpu_evtchn[chn]]);
 	set_bit(chn, (unsigned long *)cpu_evtchn_mask[cpu]);
 	cpu_evtchn[chn] =3D cpu;
 }
=20
+static void bind_evtchn_to_cpu(unsigned int chn, unsigned int cpu)
+{
+	_bind_evtchn_to_cpu(chn, cpu, evtchn_to_irq[chn], cpumask_of_cpu(cp=
u));
+}
+
 static void init_evtchn_cpu_bindings(void)
 {
 	int i;
@@ -180,6 +187,11 @@ static inline unsigned long active_evtch
 	return (sh->evtchn_pending[idx] & ~sh->evtchn_mask[idx]);
 }
=20
+static void _bind_evtchn_to_cpu(unsigned int chn, unsigned int cpu, int =
irq,
+				cpumask_t cpumask)
+{
+}
+
 static void bind_evtchn_to_cpu(unsigned int chn, unsigned int cpu)
 {
 }
@@ -663,30 +675,32 @@ void unbind_from_irqhandler(unsigned int
 EXPORT_SYMBOL_GPL(unbind_from_irqhandler);
=20
 #ifdef CONFIG_SMP
-void rebind_evtchn_to_cpu(int port, unsigned int cpu)
+static void _rebind_evtchn_to_cpu(int port, unsigned int cpu, int irq,
+				  cpumask_t dest)
 {
 	struct evtchn_bind_vcpu ebv =3D { .port =3D port, .vcpu =3D cpu };
 	int masked;
=20
 	masked =3D test_and_set_evtchn_mask(port);
 	if (HYPERVISOR_event_channel_op(EVTCHNOP_bind_vcpu, &ebv) =3D=3D =
0)
-		bind_evtchn_to_cpu(port, cpu);
+		_bind_evtchn_to_cpu(port, cpu, irq, dest);
 	if (!masked)
 		unmask_evtchn(port);
 }
=20
-static void rebind_irq_to_cpu(unsigned int irq, unsigned int tcpu)
+void rebind_evtchn_to_cpu(int port, unsigned int cpu)
 {
-	int evtchn =3D evtchn_from_irq(irq);
-
-	if (VALID_EVTCHN(evtchn))
-		rebind_evtchn_to_cpu(evtchn, tcpu);
+	_rebind_evtchn_to_cpu(port, cpu, evtchn_to_irq[port],
+			      cpumask_of_cpu(cpu));
 }
=20
 static void set_affinity_irq(unsigned int irq, cpumask_t dest)
 {
+	int evtchn =3D evtchn_from_irq(irq);
 	unsigned tcpu =3D first_cpu(dest);
-	rebind_irq_to_cpu(irq, tcpu);
+
+	if (VALID_EVTCHN(evtchn))
+		_rebind_evtchn_to_cpu(evtchn, tcpu, irq, dest);
 }
 #endif
=20
@@ -854,7 +868,7 @@ static unsigned int startup_pirq(unsigne
 	pirq_query_unmask(irq);
=20
 	evtchn_to_irq[evtchn] =3D irq;
-	bind_evtchn_to_cpu(evtchn, 0);
+	_bind_evtchn_to_cpu(evtchn, 0, irq, cpu_possible_map);
 	irq_info[irq] =3D mk_irq_info(IRQT_PIRQ, bind_pirq.pirq, evtchn);
=20
  out:
@@ -1019,7 +1033,7 @@ static void restore_cpu_virqs(unsigned i
 		/* Record the new mapping. */
 		evtchn_to_irq[evtchn] =3D irq;
 		irq_info[irq] =3D mk_irq_info(IRQT_VIRQ, virq, evtchn);
-		bind_evtchn_to_cpu(evtchn, cpu);
+		_bind_evtchn_to_cpu(evtchn, cpu, -1, CPU_MASK_NONE);
=20
 		/* Ready for use. */
 		unmask_evtchn(evtchn);
@@ -1047,7 +1061,7 @@ static void restore_cpu_ipis(unsigned in
 		/* Record the new mapping. */
 		evtchn_to_irq[evtchn] =3D irq;
 		irq_info[irq] =3D mk_irq_info(IRQT_IPI, ipi, evtchn);
-		bind_evtchn_to_cpu(evtchn, cpu);
+		_bind_evtchn_to_cpu(evtchn, cpu, -1, CPU_MASK_NONE);
=20
 		/* Ready for use. */
 		unmask_evtchn(evtchn);



--=__PartD2E3EEF9.0__=
Content-Type: text/plain; name="xen-irq-affinity.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="xen-irq-affinity.patch"

IRQ/evtchn: adjust affinity handling=0A=0AVirtually forever, Xen code =
diverged from native in the way affinities=0Aof IRQs got managed: Native, =
even if restricting handling of an IRQ to=0Aa single CPU e.g. because of =
APIC ID constraints, it would still keep=0Athe affinity set to all =
permitted CPUs. Xen instead restricted the=0Aaffinity along with the =
handling. Retain that behavior only for per-CPU=0AIRQs (and for other =
dynamic ones on their initial setup, albeit perhaps=0Aevent that is still =
too strict), but make physical ones (and dynamic=0Aones if their affinity =
gets adjusted an the fly) match native behavior.=0A=0ASigned-off-by: Jan =
Beulich <jbeulich@suse.com>=0A=0A--- a/drivers/xen/core/evtchn.c=0A+++ =
b/drivers/xen/core/evtchn.c=0A@@ -137,21 +137,28 @@ static inline unsigned =
long active_evtch=0A 		~sh->evtchn_mask[idx]);=0A }=0A =0A-static =
void bind_evtchn_to_cpu(unsigned int chn, unsigned int cpu)=0A+static void =
_bind_evtchn_to_cpu(unsigned int chn, unsigned int cpu, int irq,=0A+		=
		cpumask_t cpumask)=0A {=0A 	shared_info_t *s =3D =
HYPERVISOR_shared_info;=0A-	int irq =3D evtchn_to_irq[chn];=0A =0A 	=
BUG_ON(!test_bit(chn, s->evtchn_mask));=0A =0A-	if (irq !=3D -1)=0A-		=
set_native_irq_info(irq, cpumask_of_cpu(cpu));=0A+	if (irq >=3D 0) =
{=0A+		BUG_ON(!cpu_isset(cpu, cpumask));=0A+		set_native_=
irq_info(irq, cpumask);=0A+	}=0A =0A 	clear_bit(chn, (unsigned =
long *)cpu_evtchn_mask[cpu_evtchn[chn]]);=0A 	set_bit(chn, (unsigned =
long *)cpu_evtchn_mask[cpu]);=0A 	cpu_evtchn[chn] =3D cpu;=0A }=0A =
=0A+static void bind_evtchn_to_cpu(unsigned int chn, unsigned int =
cpu)=0A+{=0A+	_bind_evtchn_to_cpu(chn, cpu, evtchn_to_irq[chn], =
cpumask_of_cpu(cpu));=0A+}=0A+=0A static void init_evtchn_cpu_bindings(void=
)=0A {=0A 	int i;=0A@@ -180,6 +187,11 @@ static inline unsigned long =
active_evtch=0A 	return (sh->evtchn_pending[idx] & ~sh->evtchn_mask[=
idx]);=0A }=0A =0A+static void _bind_evtchn_to_cpu(unsigned int chn, =
unsigned int cpu, int irq,=0A+				cpumask_t =
cpumask)=0A+{=0A+}=0A+=0A static void bind_evtchn_to_cpu(unsigned int chn, =
unsigned int cpu)=0A {=0A }=0A@@ -663,30 +675,32 @@ void unbind_from_irqhan=
dler(unsigned int=0A EXPORT_SYMBOL_GPL(unbind_from_irqhandler);=0A =0A =
#ifdef CONFIG_SMP=0A-void rebind_evtchn_to_cpu(int port, unsigned int =
cpu)=0A+static void _rebind_evtchn_to_cpu(int port, unsigned int cpu, int =
irq,=0A+				  cpumask_t dest)=0A {=0A 	=
struct evtchn_bind_vcpu ebv =3D { .port =3D port, .vcpu =3D cpu };=0A 	=
int masked;=0A =0A 	masked =3D test_and_set_evtchn_mask(port);=0A 	if =
(HYPERVISOR_event_channel_op(EVTCHNOP_bind_vcpu, &ebv) =3D=3D 0)=0A-		=
bind_evtchn_to_cpu(port, cpu);=0A+		_bind_evtchn_to_cpu(port, =
cpu, irq, dest);=0A 	if (!masked)=0A 		unmask_evtchn(port)=
;=0A }=0A =0A-static void rebind_irq_to_cpu(unsigned int irq, unsigned int =
tcpu)=0A+void rebind_evtchn_to_cpu(int port, unsigned int cpu)=0A {=0A-	=
int evtchn =3D evtchn_from_irq(irq);=0A-=0A-	if (VALID_EVTCHN(evtchn))=
=0A-		rebind_evtchn_to_cpu(evtchn, tcpu);=0A+	_rebind_evtchn_to_c=
pu(port, cpu, evtchn_to_irq[port],=0A+			      cpumask_of_cp=
u(cpu));=0A }=0A =0A static void set_affinity_irq(unsigned int irq, =
cpumask_t dest)=0A {=0A+	int evtchn =3D evtchn_from_irq(irq);=0A 	=
unsigned tcpu =3D first_cpu(dest);=0A-	rebind_irq_to_cpu(irq, tcpu);=0A+=
=0A+	if (VALID_EVTCHN(evtchn))=0A+		_rebind_evtchn_to_cpu(evtch=
n, tcpu, irq, dest);=0A }=0A #endif=0A =0A@@ -854,7 +868,7 @@ static =
unsigned int startup_pirq(unsigne=0A 	pirq_query_unmask(irq);=0A =0A 	=
evtchn_to_irq[evtchn] =3D irq;=0A-	bind_evtchn_to_cpu(evtchn, 0);=0A+	=
_bind_evtchn_to_cpu(evtchn, 0, irq, cpu_possible_map);=0A 	irq_info[ir=
q] =3D mk_irq_info(IRQT_PIRQ, bind_pirq.pirq, evtchn);=0A =0A  out:=0A@@ =
-1019,7 +1033,7 @@ static void restore_cpu_virqs(unsigned i=0A 		/* =
Record the new mapping. */=0A 		evtchn_to_irq[evtchn] =3D irq;=0A 	=
	irq_info[irq] =3D mk_irq_info(IRQT_VIRQ, virq, evtchn);=0A-		=
bind_evtchn_to_cpu(evtchn, cpu);=0A+		_bind_evtchn_to_cpu(evtchn,=
 cpu, -1, CPU_MASK_NONE);=0A =0A 		/* Ready for use. */=0A 	=
	unmask_evtchn(evtchn);=0A@@ -1047,7 +1061,7 @@ static void =
restore_cpu_ipis(unsigned in=0A 		/* Record the new mapping. =
*/=0A 		evtchn_to_irq[evtchn] =3D irq;=0A 		irq_info[ir=
q] =3D mk_irq_info(IRQT_IPI, ipi, evtchn);=0A-		bind_evtchn_to_cpu(=
evtchn, cpu);=0A+		_bind_evtchn_to_cpu(evtchn, cpu, -1, =
CPU_MASK_NONE);=0A =0A 		/* Ready for use. */=0A 		=
unmask_evtchn(evtchn);=0A
--=__PartD2E3EEF9.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

--=__PartD2E3EEF9.0__=--


From xen-devel-bounces@lists.xen.org Tue Sep 25 09:01:22 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 09:01:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGR0w-0008Tu-Bu; Tue, 25 Sep 2012 09:01: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 1TGR0u-0008Tj-EH
	for xen-devel@lists.xen.org; Tue, 25 Sep 2012 09:01:08 +0000
Received: from [85.158.137.99:14780] by server-10.bemta-3.messagelabs.com id
	18/87-10411-3D271605; Tue, 25 Sep 2012 09:01:07 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-16.tower-217.messagelabs.com!1348563666!19009545!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29782 invoked from network); 25 Sep 2012 09:01:06 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-16.tower-217.messagelabs.com with SMTP;
	25 Sep 2012 09:01:06 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 25 Sep 2012 10:01:06 +0100
Message-Id: <50618F09020000780009D900@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 25 Sep 2012 10:01:29 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__PartD2E3EEF9.0__="
Subject: [Xen-devel] [PATCH] linux-2.6.18: IRQ/evtchn: adjust affinity
	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.

--=__PartD2E3EEF9.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Virtually forever, Xen code diverged from native in the way affinities
of IRQs got managed: Native, even if restricting handling of an IRQ to
a single CPU e.g. because of APIC ID constraints, it would still keep
the affinity set to all permitted CPUs. Xen instead restricted the
affinity along with the handling. Retain that behavior only for per-CPU
IRQs (and for other dynamic ones on their initial setup, albeit perhaps
event that is still too strict), but make physical ones (and dynamic
ones if their affinity gets adjusted an the fly) match native behavior.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/drivers/xen/core/evtchn.c
+++ b/drivers/xen/core/evtchn.c
@@ -137,21 +137,28 @@ static inline unsigned long active_evtch
 		~sh->evtchn_mask[idx]);
 }
=20
-static void bind_evtchn_to_cpu(unsigned int chn, unsigned int cpu)
+static void _bind_evtchn_to_cpu(unsigned int chn, unsigned int cpu, int =
irq,
+				cpumask_t cpumask)
 {
 	shared_info_t *s =3D HYPERVISOR_shared_info;
-	int irq =3D evtchn_to_irq[chn];
=20
 	BUG_ON(!test_bit(chn, s->evtchn_mask));
=20
-	if (irq !=3D -1)
-		set_native_irq_info(irq, cpumask_of_cpu(cpu));
+	if (irq >=3D 0) {
+		BUG_ON(!cpu_isset(cpu, cpumask));
+		set_native_irq_info(irq, cpumask);
+	}
=20
 	clear_bit(chn, (unsigned long *)cpu_evtchn_mask[cpu_evtchn[chn]]);
 	set_bit(chn, (unsigned long *)cpu_evtchn_mask[cpu]);
 	cpu_evtchn[chn] =3D cpu;
 }
=20
+static void bind_evtchn_to_cpu(unsigned int chn, unsigned int cpu)
+{
+	_bind_evtchn_to_cpu(chn, cpu, evtchn_to_irq[chn], cpumask_of_cpu(cp=
u));
+}
+
 static void init_evtchn_cpu_bindings(void)
 {
 	int i;
@@ -180,6 +187,11 @@ static inline unsigned long active_evtch
 	return (sh->evtchn_pending[idx] & ~sh->evtchn_mask[idx]);
 }
=20
+static void _bind_evtchn_to_cpu(unsigned int chn, unsigned int cpu, int =
irq,
+				cpumask_t cpumask)
+{
+}
+
 static void bind_evtchn_to_cpu(unsigned int chn, unsigned int cpu)
 {
 }
@@ -663,30 +675,32 @@ void unbind_from_irqhandler(unsigned int
 EXPORT_SYMBOL_GPL(unbind_from_irqhandler);
=20
 #ifdef CONFIG_SMP
-void rebind_evtchn_to_cpu(int port, unsigned int cpu)
+static void _rebind_evtchn_to_cpu(int port, unsigned int cpu, int irq,
+				  cpumask_t dest)
 {
 	struct evtchn_bind_vcpu ebv =3D { .port =3D port, .vcpu =3D cpu };
 	int masked;
=20
 	masked =3D test_and_set_evtchn_mask(port);
 	if (HYPERVISOR_event_channel_op(EVTCHNOP_bind_vcpu, &ebv) =3D=3D =
0)
-		bind_evtchn_to_cpu(port, cpu);
+		_bind_evtchn_to_cpu(port, cpu, irq, dest);
 	if (!masked)
 		unmask_evtchn(port);
 }
=20
-static void rebind_irq_to_cpu(unsigned int irq, unsigned int tcpu)
+void rebind_evtchn_to_cpu(int port, unsigned int cpu)
 {
-	int evtchn =3D evtchn_from_irq(irq);
-
-	if (VALID_EVTCHN(evtchn))
-		rebind_evtchn_to_cpu(evtchn, tcpu);
+	_rebind_evtchn_to_cpu(port, cpu, evtchn_to_irq[port],
+			      cpumask_of_cpu(cpu));
 }
=20
 static void set_affinity_irq(unsigned int irq, cpumask_t dest)
 {
+	int evtchn =3D evtchn_from_irq(irq);
 	unsigned tcpu =3D first_cpu(dest);
-	rebind_irq_to_cpu(irq, tcpu);
+
+	if (VALID_EVTCHN(evtchn))
+		_rebind_evtchn_to_cpu(evtchn, tcpu, irq, dest);
 }
 #endif
=20
@@ -854,7 +868,7 @@ static unsigned int startup_pirq(unsigne
 	pirq_query_unmask(irq);
=20
 	evtchn_to_irq[evtchn] =3D irq;
-	bind_evtchn_to_cpu(evtchn, 0);
+	_bind_evtchn_to_cpu(evtchn, 0, irq, cpu_possible_map);
 	irq_info[irq] =3D mk_irq_info(IRQT_PIRQ, bind_pirq.pirq, evtchn);
=20
  out:
@@ -1019,7 +1033,7 @@ static void restore_cpu_virqs(unsigned i
 		/* Record the new mapping. */
 		evtchn_to_irq[evtchn] =3D irq;
 		irq_info[irq] =3D mk_irq_info(IRQT_VIRQ, virq, evtchn);
-		bind_evtchn_to_cpu(evtchn, cpu);
+		_bind_evtchn_to_cpu(evtchn, cpu, -1, CPU_MASK_NONE);
=20
 		/* Ready for use. */
 		unmask_evtchn(evtchn);
@@ -1047,7 +1061,7 @@ static void restore_cpu_ipis(unsigned in
 		/* Record the new mapping. */
 		evtchn_to_irq[evtchn] =3D irq;
 		irq_info[irq] =3D mk_irq_info(IRQT_IPI, ipi, evtchn);
-		bind_evtchn_to_cpu(evtchn, cpu);
+		_bind_evtchn_to_cpu(evtchn, cpu, -1, CPU_MASK_NONE);
=20
 		/* Ready for use. */
 		unmask_evtchn(evtchn);



--=__PartD2E3EEF9.0__=
Content-Type: text/plain; name="xen-irq-affinity.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="xen-irq-affinity.patch"

IRQ/evtchn: adjust affinity handling=0A=0AVirtually forever, Xen code =
diverged from native in the way affinities=0Aof IRQs got managed: Native, =
even if restricting handling of an IRQ to=0Aa single CPU e.g. because of =
APIC ID constraints, it would still keep=0Athe affinity set to all =
permitted CPUs. Xen instead restricted the=0Aaffinity along with the =
handling. Retain that behavior only for per-CPU=0AIRQs (and for other =
dynamic ones on their initial setup, albeit perhaps=0Aevent that is still =
too strict), but make physical ones (and dynamic=0Aones if their affinity =
gets adjusted an the fly) match native behavior.=0A=0ASigned-off-by: Jan =
Beulich <jbeulich@suse.com>=0A=0A--- a/drivers/xen/core/evtchn.c=0A+++ =
b/drivers/xen/core/evtchn.c=0A@@ -137,21 +137,28 @@ static inline unsigned =
long active_evtch=0A 		~sh->evtchn_mask[idx]);=0A }=0A =0A-static =
void bind_evtchn_to_cpu(unsigned int chn, unsigned int cpu)=0A+static void =
_bind_evtchn_to_cpu(unsigned int chn, unsigned int cpu, int irq,=0A+		=
		cpumask_t cpumask)=0A {=0A 	shared_info_t *s =3D =
HYPERVISOR_shared_info;=0A-	int irq =3D evtchn_to_irq[chn];=0A =0A 	=
BUG_ON(!test_bit(chn, s->evtchn_mask));=0A =0A-	if (irq !=3D -1)=0A-		=
set_native_irq_info(irq, cpumask_of_cpu(cpu));=0A+	if (irq >=3D 0) =
{=0A+		BUG_ON(!cpu_isset(cpu, cpumask));=0A+		set_native_=
irq_info(irq, cpumask);=0A+	}=0A =0A 	clear_bit(chn, (unsigned =
long *)cpu_evtchn_mask[cpu_evtchn[chn]]);=0A 	set_bit(chn, (unsigned =
long *)cpu_evtchn_mask[cpu]);=0A 	cpu_evtchn[chn] =3D cpu;=0A }=0A =
=0A+static void bind_evtchn_to_cpu(unsigned int chn, unsigned int =
cpu)=0A+{=0A+	_bind_evtchn_to_cpu(chn, cpu, evtchn_to_irq[chn], =
cpumask_of_cpu(cpu));=0A+}=0A+=0A static void init_evtchn_cpu_bindings(void=
)=0A {=0A 	int i;=0A@@ -180,6 +187,11 @@ static inline unsigned long =
active_evtch=0A 	return (sh->evtchn_pending[idx] & ~sh->evtchn_mask[=
idx]);=0A }=0A =0A+static void _bind_evtchn_to_cpu(unsigned int chn, =
unsigned int cpu, int irq,=0A+				cpumask_t =
cpumask)=0A+{=0A+}=0A+=0A static void bind_evtchn_to_cpu(unsigned int chn, =
unsigned int cpu)=0A {=0A }=0A@@ -663,30 +675,32 @@ void unbind_from_irqhan=
dler(unsigned int=0A EXPORT_SYMBOL_GPL(unbind_from_irqhandler);=0A =0A =
#ifdef CONFIG_SMP=0A-void rebind_evtchn_to_cpu(int port, unsigned int =
cpu)=0A+static void _rebind_evtchn_to_cpu(int port, unsigned int cpu, int =
irq,=0A+				  cpumask_t dest)=0A {=0A 	=
struct evtchn_bind_vcpu ebv =3D { .port =3D port, .vcpu =3D cpu };=0A 	=
int masked;=0A =0A 	masked =3D test_and_set_evtchn_mask(port);=0A 	if =
(HYPERVISOR_event_channel_op(EVTCHNOP_bind_vcpu, &ebv) =3D=3D 0)=0A-		=
bind_evtchn_to_cpu(port, cpu);=0A+		_bind_evtchn_to_cpu(port, =
cpu, irq, dest);=0A 	if (!masked)=0A 		unmask_evtchn(port)=
;=0A }=0A =0A-static void rebind_irq_to_cpu(unsigned int irq, unsigned int =
tcpu)=0A+void rebind_evtchn_to_cpu(int port, unsigned int cpu)=0A {=0A-	=
int evtchn =3D evtchn_from_irq(irq);=0A-=0A-	if (VALID_EVTCHN(evtchn))=
=0A-		rebind_evtchn_to_cpu(evtchn, tcpu);=0A+	_rebind_evtchn_to_c=
pu(port, cpu, evtchn_to_irq[port],=0A+			      cpumask_of_cp=
u(cpu));=0A }=0A =0A static void set_affinity_irq(unsigned int irq, =
cpumask_t dest)=0A {=0A+	int evtchn =3D evtchn_from_irq(irq);=0A 	=
unsigned tcpu =3D first_cpu(dest);=0A-	rebind_irq_to_cpu(irq, tcpu);=0A+=
=0A+	if (VALID_EVTCHN(evtchn))=0A+		_rebind_evtchn_to_cpu(evtch=
n, tcpu, irq, dest);=0A }=0A #endif=0A =0A@@ -854,7 +868,7 @@ static =
unsigned int startup_pirq(unsigne=0A 	pirq_query_unmask(irq);=0A =0A 	=
evtchn_to_irq[evtchn] =3D irq;=0A-	bind_evtchn_to_cpu(evtchn, 0);=0A+	=
_bind_evtchn_to_cpu(evtchn, 0, irq, cpu_possible_map);=0A 	irq_info[ir=
q] =3D mk_irq_info(IRQT_PIRQ, bind_pirq.pirq, evtchn);=0A =0A  out:=0A@@ =
-1019,7 +1033,7 @@ static void restore_cpu_virqs(unsigned i=0A 		/* =
Record the new mapping. */=0A 		evtchn_to_irq[evtchn] =3D irq;=0A 	=
	irq_info[irq] =3D mk_irq_info(IRQT_VIRQ, virq, evtchn);=0A-		=
bind_evtchn_to_cpu(evtchn, cpu);=0A+		_bind_evtchn_to_cpu(evtchn,=
 cpu, -1, CPU_MASK_NONE);=0A =0A 		/* Ready for use. */=0A 	=
	unmask_evtchn(evtchn);=0A@@ -1047,7 +1061,7 @@ static void =
restore_cpu_ipis(unsigned in=0A 		/* Record the new mapping. =
*/=0A 		evtchn_to_irq[evtchn] =3D irq;=0A 		irq_info[ir=
q] =3D mk_irq_info(IRQT_IPI, ipi, evtchn);=0A-		bind_evtchn_to_cpu(=
evtchn, cpu);=0A+		_bind_evtchn_to_cpu(evtchn, cpu, -1, =
CPU_MASK_NONE);=0A =0A 		/* Ready for use. */=0A 		=
unmask_evtchn(evtchn);=0A
--=__PartD2E3EEF9.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

--=__PartD2E3EEF9.0__=--


From xen-devel-bounces@lists.xen.org Tue Sep 25 09:02:07 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 09:02:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGR1f-00007F-Vu; Tue, 25 Sep 2012 09:01:55 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <qianhu2011@gmail.com>) id 1TGR1f-000070-21
	for xen-devel@lists.xen.org; Tue, 25 Sep 2012 09:01:55 +0000
Received: from [85.158.139.83:9240] by server-6.bemta-5.messagelabs.com id
	5B/C8-14717-20371605; Tue, 25 Sep 2012 09:01:54 +0000
X-Env-Sender: qianhu2011@gmail.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1348563712!27721601!1
X-Originating-IP: [209.85.212.45]
X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_20_30,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7549 invoked from network); 25 Sep 2012 09:01:53 -0000
Received: from mail-vb0-f45.google.com (HELO mail-vb0-f45.google.com)
	(209.85.212.45)
	by server-14.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Sep 2012 09:01:53 -0000
Received: by vbip1 with SMTP id p1so8582329vbi.32
	for <xen-devel@lists.xen.org>; Tue, 25 Sep 2012 02:01:51 -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=n9euFsOuNU81RvmRje9S9m632p8I8i0GffJhd2mr7sg=;
	b=YLQhqoBxOCY6G44PA48b+xaNP4IM4VL5V6KqNMxrriCVUuxDvv2ZGIkneGdSeaLZ7w
	mJYdQT+78jxJs0DLVp9Ct5XXnEBoxJVJT30C/AMLcbEZJy6BR3vuIZ9AUmHyVr3n214H
	RBEsx7LALmx6oO1B3AlprMIZliGebkx6Pe8wB4TCwExKO487CnJZjjGGS5haV6+00J6B
	2Pb++AEaXgUuMP2rK3SqJd0TGpgLHSdHS2s/8OEHQrTomdpYptDwU1iig17ffPyPVXKb
	MjupvkdCPtqQsO4LZVPXqCWGJEQ2Drj+Tb8b8fESL8GhijXd130JmpGm56og5MZVfivc
	pT9Q==
MIME-Version: 1.0
Received: by 10.220.142.16 with SMTP id o16mr8853447vcu.3.1348563711732; Tue,
	25 Sep 2012 02:01:51 -0700 (PDT)
Received: by 10.58.249.236 with HTTP; Tue, 25 Sep 2012 02:01:51 -0700 (PDT)
In-Reply-To: <20120925061147.GK8912@reaktio.net>
References: <CALCpXpCvGkjZyG-NOY+fZY0q0f_DxuwPNEnxwKXVhjOe=gcHSQ@mail.gmail.com>
	<20120925061147.GK8912@reaktio.net>
Date: Tue, 25 Sep 2012 17:01:51 +0800
Message-ID: <CALCpXpCuim55JLLmRgDn+DHGrwx8MFwWjbRKo2Ro5qeJZQEb3g@mail.gmail.com>
From: Qian Hu <qianhu2011@gmail.com>
To: =?ISO-8859-1?Q?Pasi_K=E4rkk=E4inen?= <pasik@iki.fi>
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] usbpassthrough of xen-4.1.2 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: multipart/mixed; boundary="===============4628033854194380622=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============4628033854194380622==
Content-Type: multipart/alternative; boundary=f46d043be0b6feadd004ca82f45a

--f46d043be0b6feadd004ca82f45a
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

I haven't found any  obvious error infomation in the log or command output.
Below is some output message of dmesg,
which I think may be useful. The sentence "usb-storage: waiting for device
to settle before scanning" has repeated for
many times. Does it mean the missing of usb device?

[15171.175847] usb-storage: device found at 3
[15171.175851] usb-storage: waiting for device to settle before scanning
[15171.964100] usb 1-1.1: reset high speed USB device using ehci_hcd and
address 3
[15172.049744] scsi11 : SCSI emulation for USB Mass Storage devices
[15172.051087] usb-storage: device found at 3
[15172.051090] usb-storage: waiting for device to settle before scanning
[15172.190280] usb 1-1.1: reset high speed USB device using ehci_hcd and
address 3
[15172.276400] scsi12 : SCSI emulation for USB Mass Storage devices
[15172.277531] usb-storage: device found at 3
[15172.277537] usb-storage: waiting for device to settle before scanning
[15795.726914] frontend_changed: backend/vbd/2/768: prepare for reconnect
[15796.521940] eth0: port 3(vif2.0) entering disabled state
[15796.524501] eth0: port 3(vif2.0) entering disabled state
[15909.382494] device tap3.0 entered promiscuous mode
[15909.382661] eth0: port 2(tap3.0) entering forwarding state
[15909.496010] eth0: port 2(tap3.0) entering disabled state
[15909.503155] eth0: port 2(tap3.0) entering forwarding state
[15909.542545] device vif3.0 entered promiscuous mode
[15909.548416] eth0: port 3(vif3.0) entering forwarding state
[15919.952172] tap3.0: no IPv6 routers present
[15920.213066] vif3.0: no IPv6 routers present
[15921.487767] eth0: port 2(tap3.0) entering disabled state
[15921.495423] eth0: port 2(tap3.0) entering disabled state
[15922.021211] blkback: ring-ref 16383, event-channel 7, protocol 1
(unspecified, assuming native)
[15927.292273] usb 1-1.1: reset high speed USB device using ehci_hcd and
address 3
[15927.377807] scsi13 : SCSI emulation for USB Mass Storage devices
[15927.378509] usb-storage: device found at 3
[15927.378512] usb-storage: waiting for device to settle before scanning
[15928.354314] usb 1-1.1: reset high speed USB device using ehci_hcd and
address 3
[15928.440038] scsi14 : SCSI emulation for USB Mass Storage devices
[15928.441362] usb-storage: device found at 3
[15928.441366] usb-storage: waiting for device to settle before scanning
[15928.581347] usb 1-1.1: reset high speed USB device using ehci_hcd and
address 3
[15928.667401] scsi15 : SCSI emulation for USB Mass Storage devices
[15928.667840] usb-storage: device found at 3
[15928.667845] usb-storage: waiting for device to settle before scanning
[18491.761185] r8169: peth0: link down
[18491.769600] eth0: port 1(peth0) entering disabled state
[18499.958694] r8169: peth0: link up
[18499.960123] eth0: port 1(peth0) entering forwarding state


2012/9/25 Pasi K=E4rkk=E4inen <pasik@iki.fi>

> On Tue, Sep 25, 2012 at 11:17:03AM +0800, Qian Hu wrote:
> >    Hi, everyone! The same question with updated message.
> >    I am working on the USB passthrough of Xen-4.1.2. My host OS  is
> Fedora 14
> >    and the guest OS is win7.
> >    According to the wiki
> >    page([1]http://wiki.xen.org/wiki/Xen_USB_Passthrough),
> >    xen supports passthrough of usb device from dom0 to guests. I have
> tried
> >    the Xen HVM guest qemu-dm usb1.1 emulation,
> >    by specifying "usb =3D 1" and "usbdevice =3D host:xxxx:yyyy". I have=
 also
> >    tried the command usb_add host:xxxx:yyyy.
> >    But, the mouse could work, the keyboard didn't, and the usb storage
> >    device(usb 2.0) appeared in the device manager.
> >    While the driver is OK, it couldn't start. I can only find the messa=
ge
> >     "The device cannot start(code 10)".
> >    I doubt there may be something wrong with the guest OS driver, which
> is
> >    not said to be needed.
> >    I am confused and don't know how to resolve it.  Could anyone help m=
e?
> >
>
> It might be a bug in the USB emulation code in the old qemu-dm traditiona=
l.
>
> Any errors in:
> - "dmesg" output?
> - /var/log/xen/qemu-dm* (for the windows vm).
> - "xm dmesg" output ?
>
>
> -- Pasi
>
>

--f46d043be0b6feadd004ca82f45a
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

I haven&#39;t found any =A0obvious error infomation in the log or command o=
utput. Below is some output message of dmesg,=A0<div>which I think may be u=
seful. The sentence &quot;usb-storage: waiting for device to settle before =
scanning&quot; has repeated for</div>
<div>many times. Does it mean the missing of usb device?</div><div><br></di=
v><div><div>[15171.175847] usb-storage: device found at 3</div><div>[15171.=
175851] usb-storage: waiting for device to settle before scanning</div>
<div>[15171.964100] usb 1-1.1: reset high speed USB device using ehci_hcd a=
nd address 3</div><div>[15172.049744] scsi11 : SCSI emulation for USB Mass =
Storage devices</div><div>[15172.051087] usb-storage: device found at 3</di=
v>
<div>[15172.051090] usb-storage: waiting for device to settle before scanni=
ng</div><div>[15172.190280] usb 1-1.1: reset high speed USB device using eh=
ci_hcd and address 3</div><div>[15172.276400] scsi12 : SCSI emulation for U=
SB Mass Storage devices</div>
<div>[15172.277531] usb-storage: device found at 3</div><div>[15172.277537]=
 usb-storage: waiting for device to settle before scanning</div><div>[15795=
.726914] frontend_changed: backend/vbd/2/768: prepare for reconnect</div>
<div>[15796.521940] eth0: port 3(vif2.0) entering disabled state</div><div>=
[15796.524501] eth0: port 3(vif2.0) entering disabled state</div><div>[1590=
9.382494] device tap3.0 entered promiscuous mode</div><div>[15909.382661] e=
th0: port 2(tap3.0) entering forwarding state</div>
<div>[15909.496010] eth0: port 2(tap3.0) entering disabled state</div><div>=
[15909.503155] eth0: port 2(tap3.0) entering forwarding state</div><div>[15=
909.542545] device vif3.0 entered promiscuous mode</div><div>[15909.548416]=
 eth0: port 3(vif3.0) entering forwarding state</div>
<div>[15919.952172] tap3.0: no IPv6 routers present</div><div>[15920.213066=
] vif3.0: no IPv6 routers present</div><div>[15921.487767] eth0: port 2(tap=
3.0) entering disabled state</div><div>[15921.495423] eth0: port 2(tap3.0) =
entering disabled state</div>
<div>[15922.021211] blkback: ring-ref 16383, event-channel 7, protocol 1 (u=
nspecified, assuming native)</div><div>[15927.292273] usb 1-1.1: reset high=
 speed USB device using ehci_hcd and address 3</div><div>[15927.377807] scs=
i13 : SCSI emulation for USB Mass Storage devices</div>
<div>[15927.378509] usb-storage: device found at 3</div><div>[15927.378512]=
 usb-storage: waiting for device to settle before scanning</div><div>[15928=
.354314] usb 1-1.1: reset high speed USB device using ehci_hcd and address =
3</div>
<div>[15928.440038] scsi14 : SCSI emulation for USB Mass Storage devices</d=
iv><div>[15928.441362] usb-storage: device found at 3</div><div>[15928.4413=
66] usb-storage: waiting for device to settle before scanning</div><div>
[15928.581347] usb 1-1.1: reset high speed USB device using ehci_hcd and ad=
dress 3</div><div>[15928.667401] scsi15 : SCSI emulation for USB Mass Stora=
ge devices</div><div>[15928.667840] usb-storage: device found at 3</div>
<div>[15928.667845] usb-storage: waiting for device to settle before scanni=
ng</div><div>[18491.761185] r8169: peth0: link down</div><div>[18491.769600=
] eth0: port 1(peth0) entering disabled state</div><div>[18499.958694] r816=
9: peth0: link up</div>
<div>[18499.960123] eth0: port 1(peth0) entering forwarding state</div><div=
><br><br><div class=3D"gmail_quote">2012/9/25 Pasi K=E4rkk=E4inen <span dir=
=3D"ltr">&lt;<a href=3D"mailto:pasik@iki.fi" target=3D"_blank">pasik@iki.fi=
</a>&gt;</span><br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div class=3D"im">On Tue, Sep 25, 2012 at 11=
:17:03AM +0800, Qian Hu wrote:<br>
&gt; =A0 =A0Hi, everyone! The same question with updated message.<br>
&gt; =A0 =A0I am working on the USB passthrough of Xen-4.1.2. My host OS =
=A0is Fedora 14<br>
&gt; =A0 =A0and the guest OS is win7.<br>
&gt; =A0 =A0According to the wiki<br>
</div>&gt; =A0 =A0page([1]<a href=3D"http://wiki.xen.org/wiki/Xen_USB_Passt=
hrough" target=3D"_blank">http://wiki.xen.org/wiki/Xen_USB_Passthrough</a>)=
,<br>
<div class=3D"im">&gt; =A0 =A0xen supports passthrough of usb device from d=
om0 to guests. I have tried<br>
&gt; =A0 =A0the Xen HVM guest qemu-dm usb1.1 emulation,<br>
&gt; =A0 =A0by specifying &quot;usb =3D 1&quot; and &quot;usbdevice =3D hos=
t:xxxx:yyyy&quot;. I have also<br>
&gt; =A0 =A0tried the command usb_add host:xxxx:yyyy.<br>
&gt; =A0 =A0But, the mouse could work, the keyboard didn&#39;t, and the usb=
 storage<br>
&gt; =A0 =A0device(usb 2.0) appeared in the device manager.<br>
&gt; =A0 =A0While the driver is OK, it couldn&#39;t start. I can only find =
the message<br>
&gt; =A0 =A0 &quot;The device cannot start(code 10)&quot;.<br>
&gt; =A0 =A0I doubt there may be something wrong with the guest OS driver, =
which is<br>
&gt; =A0 =A0not said to be needed.<br>
&gt; =A0 =A0I am confused and don&#39;t know how to resolve it. =A0Could an=
yone help me?<br>
&gt;<br>
<br>
</div>It might be a bug in the USB emulation code in the old qemu-dm tradit=
ional.<br>
<br>
Any errors in:<br>
- &quot;dmesg&quot; output?<br>
- /var/log/xen/qemu-dm* (for the windows vm).<br>
- &quot;xm dmesg&quot; output ?<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
<br>
-- Pasi<br>
<br>
</font></span></blockquote></div><br></div></div>

--f46d043be0b6feadd004ca82f45a--


--===============4628033854194380622==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============4628033854194380622==--


From xen-devel-bounces@lists.xen.org Tue Sep 25 09:02:07 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 09:02:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGR1f-00007F-Vu; Tue, 25 Sep 2012 09:01:55 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <qianhu2011@gmail.com>) id 1TGR1f-000070-21
	for xen-devel@lists.xen.org; Tue, 25 Sep 2012 09:01:55 +0000
Received: from [85.158.139.83:9240] by server-6.bemta-5.messagelabs.com id
	5B/C8-14717-20371605; Tue, 25 Sep 2012 09:01:54 +0000
X-Env-Sender: qianhu2011@gmail.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1348563712!27721601!1
X-Originating-IP: [209.85.212.45]
X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_20_30,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7549 invoked from network); 25 Sep 2012 09:01:53 -0000
Received: from mail-vb0-f45.google.com (HELO mail-vb0-f45.google.com)
	(209.85.212.45)
	by server-14.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Sep 2012 09:01:53 -0000
Received: by vbip1 with SMTP id p1so8582329vbi.32
	for <xen-devel@lists.xen.org>; Tue, 25 Sep 2012 02:01:51 -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=n9euFsOuNU81RvmRje9S9m632p8I8i0GffJhd2mr7sg=;
	b=YLQhqoBxOCY6G44PA48b+xaNP4IM4VL5V6KqNMxrriCVUuxDvv2ZGIkneGdSeaLZ7w
	mJYdQT+78jxJs0DLVp9Ct5XXnEBoxJVJT30C/AMLcbEZJy6BR3vuIZ9AUmHyVr3n214H
	RBEsx7LALmx6oO1B3AlprMIZliGebkx6Pe8wB4TCwExKO487CnJZjjGGS5haV6+00J6B
	2Pb++AEaXgUuMP2rK3SqJd0TGpgLHSdHS2s/8OEHQrTomdpYptDwU1iig17ffPyPVXKb
	MjupvkdCPtqQsO4LZVPXqCWGJEQ2Drj+Tb8b8fESL8GhijXd130JmpGm56og5MZVfivc
	pT9Q==
MIME-Version: 1.0
Received: by 10.220.142.16 with SMTP id o16mr8853447vcu.3.1348563711732; Tue,
	25 Sep 2012 02:01:51 -0700 (PDT)
Received: by 10.58.249.236 with HTTP; Tue, 25 Sep 2012 02:01:51 -0700 (PDT)
In-Reply-To: <20120925061147.GK8912@reaktio.net>
References: <CALCpXpCvGkjZyG-NOY+fZY0q0f_DxuwPNEnxwKXVhjOe=gcHSQ@mail.gmail.com>
	<20120925061147.GK8912@reaktio.net>
Date: Tue, 25 Sep 2012 17:01:51 +0800
Message-ID: <CALCpXpCuim55JLLmRgDn+DHGrwx8MFwWjbRKo2Ro5qeJZQEb3g@mail.gmail.com>
From: Qian Hu <qianhu2011@gmail.com>
To: =?ISO-8859-1?Q?Pasi_K=E4rkk=E4inen?= <pasik@iki.fi>
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] usbpassthrough of xen-4.1.2 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: multipart/mixed; boundary="===============4628033854194380622=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============4628033854194380622==
Content-Type: multipart/alternative; boundary=f46d043be0b6feadd004ca82f45a

--f46d043be0b6feadd004ca82f45a
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

I haven't found any  obvious error infomation in the log or command output.
Below is some output message of dmesg,
which I think may be useful. The sentence "usb-storage: waiting for device
to settle before scanning" has repeated for
many times. Does it mean the missing of usb device?

[15171.175847] usb-storage: device found at 3
[15171.175851] usb-storage: waiting for device to settle before scanning
[15171.964100] usb 1-1.1: reset high speed USB device using ehci_hcd and
address 3
[15172.049744] scsi11 : SCSI emulation for USB Mass Storage devices
[15172.051087] usb-storage: device found at 3
[15172.051090] usb-storage: waiting for device to settle before scanning
[15172.190280] usb 1-1.1: reset high speed USB device using ehci_hcd and
address 3
[15172.276400] scsi12 : SCSI emulation for USB Mass Storage devices
[15172.277531] usb-storage: device found at 3
[15172.277537] usb-storage: waiting for device to settle before scanning
[15795.726914] frontend_changed: backend/vbd/2/768: prepare for reconnect
[15796.521940] eth0: port 3(vif2.0) entering disabled state
[15796.524501] eth0: port 3(vif2.0) entering disabled state
[15909.382494] device tap3.0 entered promiscuous mode
[15909.382661] eth0: port 2(tap3.0) entering forwarding state
[15909.496010] eth0: port 2(tap3.0) entering disabled state
[15909.503155] eth0: port 2(tap3.0) entering forwarding state
[15909.542545] device vif3.0 entered promiscuous mode
[15909.548416] eth0: port 3(vif3.0) entering forwarding state
[15919.952172] tap3.0: no IPv6 routers present
[15920.213066] vif3.0: no IPv6 routers present
[15921.487767] eth0: port 2(tap3.0) entering disabled state
[15921.495423] eth0: port 2(tap3.0) entering disabled state
[15922.021211] blkback: ring-ref 16383, event-channel 7, protocol 1
(unspecified, assuming native)
[15927.292273] usb 1-1.1: reset high speed USB device using ehci_hcd and
address 3
[15927.377807] scsi13 : SCSI emulation for USB Mass Storage devices
[15927.378509] usb-storage: device found at 3
[15927.378512] usb-storage: waiting for device to settle before scanning
[15928.354314] usb 1-1.1: reset high speed USB device using ehci_hcd and
address 3
[15928.440038] scsi14 : SCSI emulation for USB Mass Storage devices
[15928.441362] usb-storage: device found at 3
[15928.441366] usb-storage: waiting for device to settle before scanning
[15928.581347] usb 1-1.1: reset high speed USB device using ehci_hcd and
address 3
[15928.667401] scsi15 : SCSI emulation for USB Mass Storage devices
[15928.667840] usb-storage: device found at 3
[15928.667845] usb-storage: waiting for device to settle before scanning
[18491.761185] r8169: peth0: link down
[18491.769600] eth0: port 1(peth0) entering disabled state
[18499.958694] r8169: peth0: link up
[18499.960123] eth0: port 1(peth0) entering forwarding state


2012/9/25 Pasi K=E4rkk=E4inen <pasik@iki.fi>

> On Tue, Sep 25, 2012 at 11:17:03AM +0800, Qian Hu wrote:
> >    Hi, everyone! The same question with updated message.
> >    I am working on the USB passthrough of Xen-4.1.2. My host OS  is
> Fedora 14
> >    and the guest OS is win7.
> >    According to the wiki
> >    page([1]http://wiki.xen.org/wiki/Xen_USB_Passthrough),
> >    xen supports passthrough of usb device from dom0 to guests. I have
> tried
> >    the Xen HVM guest qemu-dm usb1.1 emulation,
> >    by specifying "usb =3D 1" and "usbdevice =3D host:xxxx:yyyy". I have=
 also
> >    tried the command usb_add host:xxxx:yyyy.
> >    But, the mouse could work, the keyboard didn't, and the usb storage
> >    device(usb 2.0) appeared in the device manager.
> >    While the driver is OK, it couldn't start. I can only find the messa=
ge
> >     "The device cannot start(code 10)".
> >    I doubt there may be something wrong with the guest OS driver, which
> is
> >    not said to be needed.
> >    I am confused and don't know how to resolve it.  Could anyone help m=
e?
> >
>
> It might be a bug in the USB emulation code in the old qemu-dm traditiona=
l.
>
> Any errors in:
> - "dmesg" output?
> - /var/log/xen/qemu-dm* (for the windows vm).
> - "xm dmesg" output ?
>
>
> -- Pasi
>
>

--f46d043be0b6feadd004ca82f45a
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

I haven&#39;t found any =A0obvious error infomation in the log or command o=
utput. Below is some output message of dmesg,=A0<div>which I think may be u=
seful. The sentence &quot;usb-storage: waiting for device to settle before =
scanning&quot; has repeated for</div>
<div>many times. Does it mean the missing of usb device?</div><div><br></di=
v><div><div>[15171.175847] usb-storage: device found at 3</div><div>[15171.=
175851] usb-storage: waiting for device to settle before scanning</div>
<div>[15171.964100] usb 1-1.1: reset high speed USB device using ehci_hcd a=
nd address 3</div><div>[15172.049744] scsi11 : SCSI emulation for USB Mass =
Storage devices</div><div>[15172.051087] usb-storage: device found at 3</di=
v>
<div>[15172.051090] usb-storage: waiting for device to settle before scanni=
ng</div><div>[15172.190280] usb 1-1.1: reset high speed USB device using eh=
ci_hcd and address 3</div><div>[15172.276400] scsi12 : SCSI emulation for U=
SB Mass Storage devices</div>
<div>[15172.277531] usb-storage: device found at 3</div><div>[15172.277537]=
 usb-storage: waiting for device to settle before scanning</div><div>[15795=
.726914] frontend_changed: backend/vbd/2/768: prepare for reconnect</div>
<div>[15796.521940] eth0: port 3(vif2.0) entering disabled state</div><div>=
[15796.524501] eth0: port 3(vif2.0) entering disabled state</div><div>[1590=
9.382494] device tap3.0 entered promiscuous mode</div><div>[15909.382661] e=
th0: port 2(tap3.0) entering forwarding state</div>
<div>[15909.496010] eth0: port 2(tap3.0) entering disabled state</div><div>=
[15909.503155] eth0: port 2(tap3.0) entering forwarding state</div><div>[15=
909.542545] device vif3.0 entered promiscuous mode</div><div>[15909.548416]=
 eth0: port 3(vif3.0) entering forwarding state</div>
<div>[15919.952172] tap3.0: no IPv6 routers present</div><div>[15920.213066=
] vif3.0: no IPv6 routers present</div><div>[15921.487767] eth0: port 2(tap=
3.0) entering disabled state</div><div>[15921.495423] eth0: port 2(tap3.0) =
entering disabled state</div>
<div>[15922.021211] blkback: ring-ref 16383, event-channel 7, protocol 1 (u=
nspecified, assuming native)</div><div>[15927.292273] usb 1-1.1: reset high=
 speed USB device using ehci_hcd and address 3</div><div>[15927.377807] scs=
i13 : SCSI emulation for USB Mass Storage devices</div>
<div>[15927.378509] usb-storage: device found at 3</div><div>[15927.378512]=
 usb-storage: waiting for device to settle before scanning</div><div>[15928=
.354314] usb 1-1.1: reset high speed USB device using ehci_hcd and address =
3</div>
<div>[15928.440038] scsi14 : SCSI emulation for USB Mass Storage devices</d=
iv><div>[15928.441362] usb-storage: device found at 3</div><div>[15928.4413=
66] usb-storage: waiting for device to settle before scanning</div><div>
[15928.581347] usb 1-1.1: reset high speed USB device using ehci_hcd and ad=
dress 3</div><div>[15928.667401] scsi15 : SCSI emulation for USB Mass Stora=
ge devices</div><div>[15928.667840] usb-storage: device found at 3</div>
<div>[15928.667845] usb-storage: waiting for device to settle before scanni=
ng</div><div>[18491.761185] r8169: peth0: link down</div><div>[18491.769600=
] eth0: port 1(peth0) entering disabled state</div><div>[18499.958694] r816=
9: peth0: link up</div>
<div>[18499.960123] eth0: port 1(peth0) entering forwarding state</div><div=
><br><br><div class=3D"gmail_quote">2012/9/25 Pasi K=E4rkk=E4inen <span dir=
=3D"ltr">&lt;<a href=3D"mailto:pasik@iki.fi" target=3D"_blank">pasik@iki.fi=
</a>&gt;</span><br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div class=3D"im">On Tue, Sep 25, 2012 at 11=
:17:03AM +0800, Qian Hu wrote:<br>
&gt; =A0 =A0Hi, everyone! The same question with updated message.<br>
&gt; =A0 =A0I am working on the USB passthrough of Xen-4.1.2. My host OS =
=A0is Fedora 14<br>
&gt; =A0 =A0and the guest OS is win7.<br>
&gt; =A0 =A0According to the wiki<br>
</div>&gt; =A0 =A0page([1]<a href=3D"http://wiki.xen.org/wiki/Xen_USB_Passt=
hrough" target=3D"_blank">http://wiki.xen.org/wiki/Xen_USB_Passthrough</a>)=
,<br>
<div class=3D"im">&gt; =A0 =A0xen supports passthrough of usb device from d=
om0 to guests. I have tried<br>
&gt; =A0 =A0the Xen HVM guest qemu-dm usb1.1 emulation,<br>
&gt; =A0 =A0by specifying &quot;usb =3D 1&quot; and &quot;usbdevice =3D hos=
t:xxxx:yyyy&quot;. I have also<br>
&gt; =A0 =A0tried the command usb_add host:xxxx:yyyy.<br>
&gt; =A0 =A0But, the mouse could work, the keyboard didn&#39;t, and the usb=
 storage<br>
&gt; =A0 =A0device(usb 2.0) appeared in the device manager.<br>
&gt; =A0 =A0While the driver is OK, it couldn&#39;t start. I can only find =
the message<br>
&gt; =A0 =A0 &quot;The device cannot start(code 10)&quot;.<br>
&gt; =A0 =A0I doubt there may be something wrong with the guest OS driver, =
which is<br>
&gt; =A0 =A0not said to be needed.<br>
&gt; =A0 =A0I am confused and don&#39;t know how to resolve it. =A0Could an=
yone help me?<br>
&gt;<br>
<br>
</div>It might be a bug in the USB emulation code in the old qemu-dm tradit=
ional.<br>
<br>
Any errors in:<br>
- &quot;dmesg&quot; output?<br>
- /var/log/xen/qemu-dm* (for the windows vm).<br>
- &quot;xm dmesg&quot; output ?<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
<br>
-- Pasi<br>
<br>
</font></span></blockquote></div><br></div></div>

--f46d043be0b6feadd004ca82f45a--


--===============4628033854194380622==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============4628033854194380622==--


From xen-devel-bounces@lists.xen.org Tue Sep 25 09:06:28 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 09: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 1TGR5v-0000RG-MQ; Tue, 25 Sep 2012 09:06:19 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Christoph.Egger@amd.com>) id 1TGR5u-0000R9-1Y
	for xen-devel@lists.xensource.com; Tue, 25 Sep 2012 09:06:18 +0000
Received: from [85.158.139.83:52070] by server-14.bemta-5.messagelabs.com id
	7B/C0-05772-90471605; Tue, 25 Sep 2012 09:06:17 +0000
X-Env-Sender: Christoph.Egger@amd.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1348563974!28115324!1
X-Originating-IP: [216.32.180.184]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14121 invoked from network); 25 Sep 2012 09:06:16 -0000
Received: from co1ehsobe001.messaging.microsoft.com (HELO
	co1outboundpool.messaging.microsoft.com) (216.32.180.184)
	by server-6.tower-182.messagelabs.com with AES128-SHA encrypted SMTP;
	25 Sep 2012 09:06:16 -0000
Received: from mail126-co1-R.bigfish.com (10.243.78.239) by
	CO1EHSOBE012.bigfish.com (10.243.66.75) with Microsoft SMTP Server id
	14.1.225.23; Tue, 25 Sep 2012 09:06:13 +0000
Received: from mail126-co1 (localhost [127.0.0.1])	by
	mail126-co1-R.bigfish.com (Postfix) with ESMTP id E5FEBB40199;
	Tue, 25 Sep 2012 09:06:13 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:163.181.249.109; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp02.amd.com; RD:none; EFVD:NLI
X-SpamScore: -2
X-BigFish: VPS-2(zzbb2dI98dI1432Id6f1izz1202h1d1ah1d2ahzz8275bhz2dh668h839hd25he5bhf0ah107ah1288h12a5h12a9h12bdh137ah13b6h1155h)
Received: from mail126-co1 (localhost.localdomain [127.0.0.1]) by mail126-co1
	(MessageSwitch) id 1348563971267772_9005;
	Tue, 25 Sep 2012 09:06:11 +0000 (UTC)
Received: from CO1EHSMHS018.bigfish.com (unknown [10.243.78.254])	by
	mail126-co1.bigfish.com (Postfix) with ESMTP id 3442B980065;
	Tue, 25 Sep 2012 09:06:11 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	CO1EHSMHS018.bigfish.com (10.243.66.28) with Microsoft SMTP Server id
	14.1.225.23; Tue, 25 Sep 2012 09:06:09 +0000
X-WSS-ID: 0MAWEM6-02-3OC-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 2668CC8009;	Tue, 25 Sep 2012 04:06:06 -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;
	Tue, 25 Sep 2012 04:06:15 -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;
	Tue, 25 Sep 2012 04:06:06 -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; Tue, 25 Sep 2012
	05:06:05 -0400
Message-ID: <506173FB.8070603@amd.com>
Date: Tue, 25 Sep 2012 11:06:03 +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: <DE8DF0795D48FD4CA783C40EC8292335339547@SHSMSX101.ccr.corp.intel.com>
In-Reply-To: <DE8DF0795D48FD4CA783C40EC8292335339547@SHSMSX101.ccr.corp.intel.com>
X-OriginatorOrg: amd.com
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"keir@xen.org" <keir@xen.org>,
	"Ian.Campbell@citrix.com" <Ian.Campbell@citrix.com>,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH 6] X86/MCE: update vMCE injection for AMD
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 09/25/12 07:00, Liu, Jinsong wrote:

> X86/MCE: update vMCE injection for AMD
> 
> For Intel MCE, it broadcasts vMCE to all vcpus. For AMD MCE, it injects
> vMCE only to vcpu0. This patch update inject_vmce for AMD.
> 
> Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>
> Suggested_by: Christoph Egger <Christoph.Egger@amd.com>


Acked-by: Christoph Egger <Christoph.Egger@amd.com>

> 
> diff -r a6d12a1bc758 xen/arch/x86/cpu/mcheck/mce.h
> --- a/xen/arch/x86/cpu/mcheck/mce.h	Thu Sep 20 00:03:25 2012 +0800
> +++ b/xen/arch/x86/cpu/mcheck/mce.h	Tue Sep 25 19:52:20 2012 +0800
> @@ -168,7 +168,7 @@
>  
>  int fill_vmsr_data(struct mcinfo_bank *mc_bank, struct domain *d,
>      uint64_t gstatus);
> -int inject_vmce(struct domain *d);
> +int inject_vmce(struct domain *d, bool_t vmce_broadcast);
>  
>  static inline int mce_vendor_bank_msr(const struct vcpu *v, uint32_t msr)
>  {
> diff -r a6d12a1bc758 xen/arch/x86/cpu/mcheck/mce_intel.c
> --- a/xen/arch/x86/cpu/mcheck/mce_intel.c	Thu Sep 20 00:03:25 2012 +0800
> +++ b/xen/arch/x86/cpu/mcheck/mce_intel.c	Tue Sep 25 19:52:20 2012 +0800
> @@ -365,7 +365,7 @@
>                  }
>  
>                  /* We will inject vMCE to DOMU*/
> -                if ( inject_vmce(d) < 0 )
> +                if ( inject_vmce(d, 1) < 0 )
>                  {
>                      mce_printk(MCE_QUIET, "inject vMCE to DOM%d"
>                        " failed\n", d->domain_id);
> diff -r a6d12a1bc758 xen/arch/x86/cpu/mcheck/vmce.c
> --- a/xen/arch/x86/cpu/mcheck/vmce.c	Thu Sep 20 00:03:25 2012 +0800
> +++ b/xen/arch/x86/cpu/mcheck/vmce.c	Tue Sep 25 19:52:20 2012 +0800
> @@ -344,11 +344,14 @@
>  HVM_REGISTER_SAVE_RESTORE(VMCE_VCPU, vmce_save_vcpu_ctxt,
>                            vmce_load_vcpu_ctxt, 1, HVMSR_PER_VCPU);
>  
> -int inject_vmce(struct domain *d)
> +/* 
> + * for Intel MCE, broadcast vMCE to all vcpus
> + * for AMD MCE, only inject vMCE to vcpu0
> + */
> +int inject_vmce(struct domain *d, bool_t vmce_broadcast)
>  {
>      struct vcpu *v;
>  
> -    /* inject vMCE to all vcpus */
>      for_each_vcpu(d, v)
>      {
>          if ( !test_and_set_bool(v->mce_pending) &&
> @@ -365,6 +368,9 @@
>                         d->domain_id, v->vcpu_id);
>              return -1;
>          }
> +
> +        if ( !vmce_broadcast )
> +            break;
>      }
>  
>      return 0;



-- 
---to satisfy European Law for business letters:
Advanced Micro Devices GmbH
Einsteinring 24, 85689 Dornach b. Muenchen
Geschaeftsfuehrer: Alberto Bozzo
Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen
Registergericht Muenchen, HRB Nr. 43632


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 25 09:06:28 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 09: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 1TGR5v-0000RG-MQ; Tue, 25 Sep 2012 09:06:19 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Christoph.Egger@amd.com>) id 1TGR5u-0000R9-1Y
	for xen-devel@lists.xensource.com; Tue, 25 Sep 2012 09:06:18 +0000
Received: from [85.158.139.83:52070] by server-14.bemta-5.messagelabs.com id
	7B/C0-05772-90471605; Tue, 25 Sep 2012 09:06:17 +0000
X-Env-Sender: Christoph.Egger@amd.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1348563974!28115324!1
X-Originating-IP: [216.32.180.184]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14121 invoked from network); 25 Sep 2012 09:06:16 -0000
Received: from co1ehsobe001.messaging.microsoft.com (HELO
	co1outboundpool.messaging.microsoft.com) (216.32.180.184)
	by server-6.tower-182.messagelabs.com with AES128-SHA encrypted SMTP;
	25 Sep 2012 09:06:16 -0000
Received: from mail126-co1-R.bigfish.com (10.243.78.239) by
	CO1EHSOBE012.bigfish.com (10.243.66.75) with Microsoft SMTP Server id
	14.1.225.23; Tue, 25 Sep 2012 09:06:13 +0000
Received: from mail126-co1 (localhost [127.0.0.1])	by
	mail126-co1-R.bigfish.com (Postfix) with ESMTP id E5FEBB40199;
	Tue, 25 Sep 2012 09:06:13 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:163.181.249.109; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp02.amd.com; RD:none; EFVD:NLI
X-SpamScore: -2
X-BigFish: VPS-2(zzbb2dI98dI1432Id6f1izz1202h1d1ah1d2ahzz8275bhz2dh668h839hd25he5bhf0ah107ah1288h12a5h12a9h12bdh137ah13b6h1155h)
Received: from mail126-co1 (localhost.localdomain [127.0.0.1]) by mail126-co1
	(MessageSwitch) id 1348563971267772_9005;
	Tue, 25 Sep 2012 09:06:11 +0000 (UTC)
Received: from CO1EHSMHS018.bigfish.com (unknown [10.243.78.254])	by
	mail126-co1.bigfish.com (Postfix) with ESMTP id 3442B980065;
	Tue, 25 Sep 2012 09:06:11 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	CO1EHSMHS018.bigfish.com (10.243.66.28) with Microsoft SMTP Server id
	14.1.225.23; Tue, 25 Sep 2012 09:06:09 +0000
X-WSS-ID: 0MAWEM6-02-3OC-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 2668CC8009;	Tue, 25 Sep 2012 04:06:06 -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;
	Tue, 25 Sep 2012 04:06:15 -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;
	Tue, 25 Sep 2012 04:06:06 -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; Tue, 25 Sep 2012
	05:06:05 -0400
Message-ID: <506173FB.8070603@amd.com>
Date: Tue, 25 Sep 2012 11:06:03 +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: <DE8DF0795D48FD4CA783C40EC8292335339547@SHSMSX101.ccr.corp.intel.com>
In-Reply-To: <DE8DF0795D48FD4CA783C40EC8292335339547@SHSMSX101.ccr.corp.intel.com>
X-OriginatorOrg: amd.com
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"keir@xen.org" <keir@xen.org>,
	"Ian.Campbell@citrix.com" <Ian.Campbell@citrix.com>,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH 6] X86/MCE: update vMCE injection for AMD
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 09/25/12 07:00, Liu, Jinsong wrote:

> X86/MCE: update vMCE injection for AMD
> 
> For Intel MCE, it broadcasts vMCE to all vcpus. For AMD MCE, it injects
> vMCE only to vcpu0. This patch update inject_vmce for AMD.
> 
> Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>
> Suggested_by: Christoph Egger <Christoph.Egger@amd.com>


Acked-by: Christoph Egger <Christoph.Egger@amd.com>

> 
> diff -r a6d12a1bc758 xen/arch/x86/cpu/mcheck/mce.h
> --- a/xen/arch/x86/cpu/mcheck/mce.h	Thu Sep 20 00:03:25 2012 +0800
> +++ b/xen/arch/x86/cpu/mcheck/mce.h	Tue Sep 25 19:52:20 2012 +0800
> @@ -168,7 +168,7 @@
>  
>  int fill_vmsr_data(struct mcinfo_bank *mc_bank, struct domain *d,
>      uint64_t gstatus);
> -int inject_vmce(struct domain *d);
> +int inject_vmce(struct domain *d, bool_t vmce_broadcast);
>  
>  static inline int mce_vendor_bank_msr(const struct vcpu *v, uint32_t msr)
>  {
> diff -r a6d12a1bc758 xen/arch/x86/cpu/mcheck/mce_intel.c
> --- a/xen/arch/x86/cpu/mcheck/mce_intel.c	Thu Sep 20 00:03:25 2012 +0800
> +++ b/xen/arch/x86/cpu/mcheck/mce_intel.c	Tue Sep 25 19:52:20 2012 +0800
> @@ -365,7 +365,7 @@
>                  }
>  
>                  /* We will inject vMCE to DOMU*/
> -                if ( inject_vmce(d) < 0 )
> +                if ( inject_vmce(d, 1) < 0 )
>                  {
>                      mce_printk(MCE_QUIET, "inject vMCE to DOM%d"
>                        " failed\n", d->domain_id);
> diff -r a6d12a1bc758 xen/arch/x86/cpu/mcheck/vmce.c
> --- a/xen/arch/x86/cpu/mcheck/vmce.c	Thu Sep 20 00:03:25 2012 +0800
> +++ b/xen/arch/x86/cpu/mcheck/vmce.c	Tue Sep 25 19:52:20 2012 +0800
> @@ -344,11 +344,14 @@
>  HVM_REGISTER_SAVE_RESTORE(VMCE_VCPU, vmce_save_vcpu_ctxt,
>                            vmce_load_vcpu_ctxt, 1, HVMSR_PER_VCPU);
>  
> -int inject_vmce(struct domain *d)
> +/* 
> + * for Intel MCE, broadcast vMCE to all vcpus
> + * for AMD MCE, only inject vMCE to vcpu0
> + */
> +int inject_vmce(struct domain *d, bool_t vmce_broadcast)
>  {
>      struct vcpu *v;
>  
> -    /* inject vMCE to all vcpus */
>      for_each_vcpu(d, v)
>      {
>          if ( !test_and_set_bool(v->mce_pending) &&
> @@ -365,6 +368,9 @@
>                         d->domain_id, v->vcpu_id);
>              return -1;
>          }
> +
> +        if ( !vmce_broadcast )
> +            break;
>      }
>  
>      return 0;



-- 
---to satisfy European Law for business letters:
Advanced Micro Devices GmbH
Einsteinring 24, 85689 Dornach b. Muenchen
Geschaeftsfuehrer: Alberto Bozzo
Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen
Registergericht Muenchen, HRB Nr. 43632


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 25 09:06:34 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 09:06:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGR62-0000Ru-2V; Tue, 25 Sep 2012 09:06:26 +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 1TGR60-0000RF-9e
	for xen-devel@lists.xensource.com; Tue, 25 Sep 2012 09:06:24 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1348563885!12251040!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22648 invoked from network); 25 Sep 2012 09:04:45 -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;
	25 Sep 2012 09:04:45 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 25 Sep 2012 10:04:44 +0100
Message-Id: <50618FE4020000780009D91D@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 25 Sep 2012 10:05:08 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Jackson" <Ian.Jackson@eu.citrix.com>
References: <osstest-13861-mainreport@xen.org>
	<20577.28378.178321.883970@mariner.uk.xensource.com>
In-Reply-To: <20577.28378.178321.883970@mariner.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [xen-unstable test] 13861: regressions - trouble:
 blocked/broken/fail/pass
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 25.09.12 at 10:44, Ian Jackson <Ian.Jackson@eu.citrix.com> wrote:
> xen.org writes ("[xen-unstable test] 13861: regressions - trouble: 
> blocked/broken/fail/pass"):
>>  build-amd64-pvops             2 host-install(2)     broken REGR. vs. 13825
> 
> This is another machine having forgotten that it was supposed to boot
> from the network.  It's itch-mite, the twin of the other test box
> gall-mite which had this problem yesterday.
> 
> That two identical machines have had this happen within days suggests
> that somehow something done to them recently has corrupted their
> CMOS, rather than it being a random event.
> 
> Jan, do you think it at all plausible that the cpuidle-related Xen bug
> is somehow responsible ?  TBH it doesn't seem all that likely because
> I've checked gall-mite and the CMOS is still fine, even though the
> machine has experienced several of these crashes.

No, I don't see how this ought to be connected. Given previous
occasions, is it perhaps that early Xen crashes (maybe in
connection with the way Xen reboots the system afterwards)
cause this independent of the reason for the crash? Or is there
any sort of boot cycle detection active on those systems?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 25 09:06:34 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 09:06:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGR62-0000Ru-2V; Tue, 25 Sep 2012 09:06:26 +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 1TGR60-0000RF-9e
	for xen-devel@lists.xensource.com; Tue, 25 Sep 2012 09:06:24 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1348563885!12251040!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22648 invoked from network); 25 Sep 2012 09:04:45 -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;
	25 Sep 2012 09:04:45 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 25 Sep 2012 10:04:44 +0100
Message-Id: <50618FE4020000780009D91D@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 25 Sep 2012 10:05:08 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Jackson" <Ian.Jackson@eu.citrix.com>
References: <osstest-13861-mainreport@xen.org>
	<20577.28378.178321.883970@mariner.uk.xensource.com>
In-Reply-To: <20577.28378.178321.883970@mariner.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [xen-unstable test] 13861: regressions - trouble:
 blocked/broken/fail/pass
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 25.09.12 at 10:44, Ian Jackson <Ian.Jackson@eu.citrix.com> wrote:
> xen.org writes ("[xen-unstable test] 13861: regressions - trouble: 
> blocked/broken/fail/pass"):
>>  build-amd64-pvops             2 host-install(2)     broken REGR. vs. 13825
> 
> This is another machine having forgotten that it was supposed to boot
> from the network.  It's itch-mite, the twin of the other test box
> gall-mite which had this problem yesterday.
> 
> That two identical machines have had this happen within days suggests
> that somehow something done to them recently has corrupted their
> CMOS, rather than it being a random event.
> 
> Jan, do you think it at all plausible that the cpuidle-related Xen bug
> is somehow responsible ?  TBH it doesn't seem all that likely because
> I've checked gall-mite and the CMOS is still fine, even though the
> machine has experienced several of these crashes.

No, I don't see how this ought to be connected. Given previous
occasions, is it perhaps that early Xen crashes (maybe in
connection with the way Xen reboots the system afterwards)
cause this independent of the reason for the crash? Or is there
any sort of boot cycle detection active on those systems?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 25 09:07:18 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 09: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 1TGR6k-0000ZW-G1; Tue, 25 Sep 2012 09:07:10 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1TGR6j-0000ZI-EM
	for xen-devel@lists.xen.org; Tue, 25 Sep 2012 09:07:09 +0000
Received: from [85.158.139.211:8794] by server-2.bemta-5.messagelabs.com id
	F3/8E-28944-C3471605; Tue, 25 Sep 2012 09:07:08 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-206.messagelabs.com!1348564027!18854518!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTEwNzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9629 invoked from network); 25 Sep 2012 09:07:08 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Sep 2012 09:07:08 -0000
X-IronPort-AV: E=Sophos;i="4.80,481,1344211200"; d="scan'208";a="14742822"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Sep 2012 09:06: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.279.1;
	Tue, 25 Sep 2012 10:06:13 +0100
Message-ID: <1348563972.3452.126.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Anthony PERARD <anthony.perard@citrix.com>
Date: Tue, 25 Sep 2012 10:06:12 +0100
In-Reply-To: <1347906148-9606-5-git-send-email-anthony.perard@citrix.com>
References: <1347906148-9606-1-git-send-email-anthony.perard@citrix.com>
	<1347906148-9606-5-git-send-email-anthony.perard@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Xen Devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH V2 4/9] libxl_qmp: Introduces helpers to
 create an argument list.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2012-09-17 at 19:22 +0100, Anthony PERARD wrote:
> Those functions will be used to create a "list" of parameters that contain more
> than just strings. This list is converted by qmp_send to a string to be sent to
> QEMU.
> 
> Those functions will be used in the next two patches, so right now there are
> not compiled.
> 
> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
> ---
>  tools/libxl/libxl_qmp.c | 53 +++++++++++++++++++++++++++++++++++++++++++++++++
>  1 file changed, 53 insertions(+)
> 
> diff --git a/tools/libxl/libxl_qmp.c b/tools/libxl/libxl_qmp.c
> index 07a8bd5..1dd5c6c 100644
> --- a/tools/libxl/libxl_qmp.c
> +++ b/tools/libxl/libxl_qmp.c
> @@ -623,6 +623,59 @@ static void qmp_free_handler(libxl__qmp_handler *qmp)
>      free(qmp);
>  }
>  
> +#if 0
> +/*
> + * QMP Parameters Helpers
> + * Those functions does not use the gc, because of the internal usage of
> + * flexarray that does not support it.
> + * The allocated *param need to be free with libxl__json_object_free(gc, param)
> + */
> +static void qmp_parameters_common_add(libxl__gc *gc,
> +                                      libxl__json_object **param,
> +                                      const char *name,
> +                                      libxl__json_object *obj)
> +{
> +    libxl__json_map_node *arg = NULL;
> +
> +    if (!*param) {
> +        *param = libxl__json_object_alloc(NOGC, JSON_MAP);
> +    }

Having now read the callers in later patches this looks a bit odd to me
since they do

	args = NULL

	qmp_param.._add_foo(gc, args,...)

	qmp_run_thing

	libxl__json_object_free(...args...)

which is unbalanced WRT allocation and free and I can easily imagine
people forgetting the free.

If you can't arrange for these object's to be gc'd then I think having
an explicit alloc in the caller would be less liable to surprise people.

#define qmp_args_alloc(gc) libxl__json_object_alloc(NOGC, JSON_MAP)
#define qmp_args_free(..) libxl__json_object_free(...args...)

would work nicely IMHO.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 25 09:07:18 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 09: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 1TGR6k-0000ZW-G1; Tue, 25 Sep 2012 09:07:10 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1TGR6j-0000ZI-EM
	for xen-devel@lists.xen.org; Tue, 25 Sep 2012 09:07:09 +0000
Received: from [85.158.139.211:8794] by server-2.bemta-5.messagelabs.com id
	F3/8E-28944-C3471605; Tue, 25 Sep 2012 09:07:08 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-206.messagelabs.com!1348564027!18854518!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTEwNzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9629 invoked from network); 25 Sep 2012 09:07:08 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Sep 2012 09:07:08 -0000
X-IronPort-AV: E=Sophos;i="4.80,481,1344211200"; d="scan'208";a="14742822"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Sep 2012 09:06: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.279.1;
	Tue, 25 Sep 2012 10:06:13 +0100
Message-ID: <1348563972.3452.126.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Anthony PERARD <anthony.perard@citrix.com>
Date: Tue, 25 Sep 2012 10:06:12 +0100
In-Reply-To: <1347906148-9606-5-git-send-email-anthony.perard@citrix.com>
References: <1347906148-9606-1-git-send-email-anthony.perard@citrix.com>
	<1347906148-9606-5-git-send-email-anthony.perard@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Xen Devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH V2 4/9] libxl_qmp: Introduces helpers to
 create an argument list.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2012-09-17 at 19:22 +0100, Anthony PERARD wrote:
> Those functions will be used to create a "list" of parameters that contain more
> than just strings. This list is converted by qmp_send to a string to be sent to
> QEMU.
> 
> Those functions will be used in the next two patches, so right now there are
> not compiled.
> 
> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
> ---
>  tools/libxl/libxl_qmp.c | 53 +++++++++++++++++++++++++++++++++++++++++++++++++
>  1 file changed, 53 insertions(+)
> 
> diff --git a/tools/libxl/libxl_qmp.c b/tools/libxl/libxl_qmp.c
> index 07a8bd5..1dd5c6c 100644
> --- a/tools/libxl/libxl_qmp.c
> +++ b/tools/libxl/libxl_qmp.c
> @@ -623,6 +623,59 @@ static void qmp_free_handler(libxl__qmp_handler *qmp)
>      free(qmp);
>  }
>  
> +#if 0
> +/*
> + * QMP Parameters Helpers
> + * Those functions does not use the gc, because of the internal usage of
> + * flexarray that does not support it.
> + * The allocated *param need to be free with libxl__json_object_free(gc, param)
> + */
> +static void qmp_parameters_common_add(libxl__gc *gc,
> +                                      libxl__json_object **param,
> +                                      const char *name,
> +                                      libxl__json_object *obj)
> +{
> +    libxl__json_map_node *arg = NULL;
> +
> +    if (!*param) {
> +        *param = libxl__json_object_alloc(NOGC, JSON_MAP);
> +    }

Having now read the callers in later patches this looks a bit odd to me
since they do

	args = NULL

	qmp_param.._add_foo(gc, args,...)

	qmp_run_thing

	libxl__json_object_free(...args...)

which is unbalanced WRT allocation and free and I can easily imagine
people forgetting the free.

If you can't arrange for these object's to be gc'd then I think having
an explicit alloc in the caller would be less liable to surprise people.

#define qmp_args_alloc(gc) libxl__json_object_alloc(NOGC, JSON_MAP)
#define qmp_args_free(..) libxl__json_object_free(...args...)

would work nicely IMHO.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 25 09:07:31 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 09: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 1TGR6x-0000cX-T5; Tue, 25 Sep 2012 09:07:23 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1TGR6w-0000c6-8l
	for xen-devel@lists.xen.org; Tue, 25 Sep 2012 09:07:22 +0000
Received: from [85.158.143.35:47601] by server-2.bemta-4.messagelabs.com id
	C3/86-06610-94471605; Tue, 25 Sep 2012 09:07:21 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1348564041!5006852!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTEwNzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9491 invoked from network); 25 Sep 2012 09:07:21 -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;
	25 Sep 2012 09:07:21 -0000
X-IronPort-AV: E=Sophos;i="4.80,481,1344211200"; d="scan'208";a="14742841"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Sep 2012 09:06: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.279.1;
	Tue, 25 Sep 2012 10:06:43 +0100
Message-ID: <1348564001.3452.127.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Anthony PERARD <anthony.perard@citrix.com>
Date: Tue, 25 Sep 2012 10:06:41 +0100
In-Reply-To: <1347906148-9606-8-git-send-email-anthony.perard@citrix.com>
References: <1347906148-9606-1-git-send-email-anthony.perard@citrix.com>
	<1347906148-9606-8-git-send-email-anthony.perard@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Xen Devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH V2 7/9] libxl_qmp: Introduce
 libxl__qmp_set_global_dirty_log.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2012-09-17 at 19:22 +0100, Anthony PERARD wrote:
> This function will enable or disable the global dirty log on QEMU, used during
> a migration.
> 
> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>

Acked-by: Ian Campbell <ian.campbell@citrix.com>

> ---
>  tools/libxl/libxl_internal.h |  2 ++
>  tools/libxl/libxl_qmp.c      | 16 ++++++++++++++--
>  2 files changed, 16 insertions(+), 2 deletions(-)
> 
> diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
> index 9c1482d..acdeeb2 100644
> --- a/tools/libxl/libxl_internal.h
> +++ b/tools/libxl/libxl_internal.h
> @@ -1399,6 +1399,8 @@ _hidden int libxl__qmp_stop(libxl__gc *gc, int domid);
>  _hidden int libxl__qmp_resume(libxl__gc *gc, int domid);
>  /* Save current QEMU state into fd. */
>  _hidden int libxl__qmp_save(libxl__gc *gc, int domid, const char *filename);
> +/* Set dirty bitmap logging status */
> +_hidden int libxl__qmp_set_global_dirty_log(libxl__gc *gc, int domid, bool enable);
>  /* close and free the QMP handler */
>  _hidden void libxl__qmp_close(libxl__qmp_handler *qmp);
>  /* remove the socket file, if the file has already been removed,
> diff --git a/tools/libxl/libxl_qmp.c b/tools/libxl/libxl_qmp.c
> index aac06c2..befa11b 100644
> --- a/tools/libxl/libxl_qmp.c
> +++ b/tools/libxl/libxl_qmp.c
> @@ -660,7 +660,6 @@ static void qmp_parameters_add_string(libxl__gc *gc,
>      qmp_parameters_common_add(gc, param, name, obj);
>  }
>  
> -#if 0
>  static void qmp_parameters_add_bool(libxl__gc *gc,
>                                      libxl__json_object **param,
>                                      const char *name, bool b)
> @@ -670,7 +669,6 @@ static void qmp_parameters_add_bool(libxl__gc *gc,
>      obj = libxl__json_object_alloc(NOGC, JSON_TRUE);
>      qmp_parameters_common_add(gc, param, name, obj);
>  }
> -#endif
>  
>  #define QMP_PARAMETERS_SPRINTF(gc, args, name, format, ...) \
>      qmp_parameters_add_string(gc, args, name, \
> @@ -919,6 +917,20 @@ int libxl__qmp_resume(libxl__gc *gc, int domid)
>      return qmp_run_command(gc, domid, "cont", NULL, NULL, NULL);
>  }
>  
> +int libxl__qmp_set_global_dirty_log(libxl__gc *gc, int domid, bool enable)
> +{
> +    libxl__json_object *args = NULL;
> +    int rc = 0;
> +
> +    qmp_parameters_add_bool(gc, &args, "enable", enable);
> +
> +    rc = qmp_run_command(gc, domid, "xen-set-global-dirty-log", args,
> +                         NULL, NULL);
> +    libxl__json_object_free(gc, args);
> +
> +    return rc;
> +}
> +
>  int libxl__qmp_initializations(libxl__gc *gc, uint32_t domid,
>                                 const libxl_domain_config *guest_config)
>  {



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 25 09:07:31 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 09: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 1TGR6x-0000cX-T5; Tue, 25 Sep 2012 09:07:23 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1TGR6w-0000c6-8l
	for xen-devel@lists.xen.org; Tue, 25 Sep 2012 09:07:22 +0000
Received: from [85.158.143.35:47601] by server-2.bemta-4.messagelabs.com id
	C3/86-06610-94471605; Tue, 25 Sep 2012 09:07:21 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1348564041!5006852!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTEwNzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9491 invoked from network); 25 Sep 2012 09:07:21 -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;
	25 Sep 2012 09:07:21 -0000
X-IronPort-AV: E=Sophos;i="4.80,481,1344211200"; d="scan'208";a="14742841"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Sep 2012 09:06: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.279.1;
	Tue, 25 Sep 2012 10:06:43 +0100
Message-ID: <1348564001.3452.127.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Anthony PERARD <anthony.perard@citrix.com>
Date: Tue, 25 Sep 2012 10:06:41 +0100
In-Reply-To: <1347906148-9606-8-git-send-email-anthony.perard@citrix.com>
References: <1347906148-9606-1-git-send-email-anthony.perard@citrix.com>
	<1347906148-9606-8-git-send-email-anthony.perard@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Xen Devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH V2 7/9] libxl_qmp: Introduce
 libxl__qmp_set_global_dirty_log.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2012-09-17 at 19:22 +0100, Anthony PERARD wrote:
> This function will enable or disable the global dirty log on QEMU, used during
> a migration.
> 
> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>

Acked-by: Ian Campbell <ian.campbell@citrix.com>

> ---
>  tools/libxl/libxl_internal.h |  2 ++
>  tools/libxl/libxl_qmp.c      | 16 ++++++++++++++--
>  2 files changed, 16 insertions(+), 2 deletions(-)
> 
> diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
> index 9c1482d..acdeeb2 100644
> --- a/tools/libxl/libxl_internal.h
> +++ b/tools/libxl/libxl_internal.h
> @@ -1399,6 +1399,8 @@ _hidden int libxl__qmp_stop(libxl__gc *gc, int domid);
>  _hidden int libxl__qmp_resume(libxl__gc *gc, int domid);
>  /* Save current QEMU state into fd. */
>  _hidden int libxl__qmp_save(libxl__gc *gc, int domid, const char *filename);
> +/* Set dirty bitmap logging status */
> +_hidden int libxl__qmp_set_global_dirty_log(libxl__gc *gc, int domid, bool enable);
>  /* close and free the QMP handler */
>  _hidden void libxl__qmp_close(libxl__qmp_handler *qmp);
>  /* remove the socket file, if the file has already been removed,
> diff --git a/tools/libxl/libxl_qmp.c b/tools/libxl/libxl_qmp.c
> index aac06c2..befa11b 100644
> --- a/tools/libxl/libxl_qmp.c
> +++ b/tools/libxl/libxl_qmp.c
> @@ -660,7 +660,6 @@ static void qmp_parameters_add_string(libxl__gc *gc,
>      qmp_parameters_common_add(gc, param, name, obj);
>  }
>  
> -#if 0
>  static void qmp_parameters_add_bool(libxl__gc *gc,
>                                      libxl__json_object **param,
>                                      const char *name, bool b)
> @@ -670,7 +669,6 @@ static void qmp_parameters_add_bool(libxl__gc *gc,
>      obj = libxl__json_object_alloc(NOGC, JSON_TRUE);
>      qmp_parameters_common_add(gc, param, name, obj);
>  }
> -#endif
>  
>  #define QMP_PARAMETERS_SPRINTF(gc, args, name, format, ...) \
>      qmp_parameters_add_string(gc, args, name, \
> @@ -919,6 +917,20 @@ int libxl__qmp_resume(libxl__gc *gc, int domid)
>      return qmp_run_command(gc, domid, "cont", NULL, NULL, NULL);
>  }
>  
> +int libxl__qmp_set_global_dirty_log(libxl__gc *gc, int domid, bool enable)
> +{
> +    libxl__json_object *args = NULL;
> +    int rc = 0;
> +
> +    qmp_parameters_add_bool(gc, &args, "enable", enable);
> +
> +    rc = qmp_run_command(gc, domid, "xen-set-global-dirty-log", args,
> +                         NULL, NULL);
> +    libxl__json_object_free(gc, args);
> +
> +    return rc;
> +}
> +
>  int libxl__qmp_initializations(libxl__gc *gc, uint32_t domid,
>                                 const libxl_domain_config *guest_config)
>  {



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 25 09:10:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 09:10:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGR9Z-0000wh-Kt; Tue, 25 Sep 2012 09:10: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 1TGR9X-0000wC-Ns
	for xen-devel@lists.xen.org; Tue, 25 Sep 2012 09:10:03 +0000
Received: from [85.158.143.99:34794] by server-1.bemta-4.messagelabs.com id
	F3/00-05684-BE471605; Tue, 25 Sep 2012 09:10:03 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1348564202!24659430!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTA5ODg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13405 invoked from network); 25 Sep 2012 09:10:02 -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;
	25 Sep 2012 09:10:02 -0000
X-IronPort-AV: E=Sophos;i="4.80,481,1344211200"; d="scan'208";a="14742958"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Sep 2012 09:10: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.279.1;
	Tue, 25 Sep 2012 10:10:02 +0100
Message-ID: <1348564200.3452.128.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Anthony Perard <anthony.perard@citrix.com>
Date: Tue, 25 Sep 2012 10:10:00 +0100
In-Reply-To: <1348564001.3452.127.camel@zakaz.uk.xensource.com>
References: <1347906148-9606-1-git-send-email-anthony.perard@citrix.com>
	<1347906148-9606-8-git-send-email-anthony.perard@citrix.com>
	<1348564001.3452.127.camel@zakaz.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Xen Devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH V2 7/9] libxl_qmp: Introduce
 libxl__qmp_set_global_dirty_log.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-09-25 at 10:06 +0100, Ian Campbell wrote:
> > +    rc = qmp_run_command(gc, domid, "xen-set-global-dirty-log", args,
> > +                         NULL, NULL);

For got to ask: Is this new function upstream and in our branch already?

I suppose there is no ordering constraint since we fail now, and if we
take this patch we'll just fail more explicitly with an ENOSYS type
error unless/until the qemu half is in place.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 25 09:10:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 09:10:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGR9Z-0000wh-Kt; Tue, 25 Sep 2012 09:10: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 1TGR9X-0000wC-Ns
	for xen-devel@lists.xen.org; Tue, 25 Sep 2012 09:10:03 +0000
Received: from [85.158.143.99:34794] by server-1.bemta-4.messagelabs.com id
	F3/00-05684-BE471605; Tue, 25 Sep 2012 09:10:03 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1348564202!24659430!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTA5ODg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13405 invoked from network); 25 Sep 2012 09:10:02 -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;
	25 Sep 2012 09:10:02 -0000
X-IronPort-AV: E=Sophos;i="4.80,481,1344211200"; d="scan'208";a="14742958"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Sep 2012 09:10: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.279.1;
	Tue, 25 Sep 2012 10:10:02 +0100
Message-ID: <1348564200.3452.128.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Anthony Perard <anthony.perard@citrix.com>
Date: Tue, 25 Sep 2012 10:10:00 +0100
In-Reply-To: <1348564001.3452.127.camel@zakaz.uk.xensource.com>
References: <1347906148-9606-1-git-send-email-anthony.perard@citrix.com>
	<1347906148-9606-8-git-send-email-anthony.perard@citrix.com>
	<1348564001.3452.127.camel@zakaz.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Xen Devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH V2 7/9] libxl_qmp: Introduce
 libxl__qmp_set_global_dirty_log.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-09-25 at 10:06 +0100, Ian Campbell wrote:
> > +    rc = qmp_run_command(gc, domid, "xen-set-global-dirty-log", args,
> > +                         NULL, NULL);

For got to ask: Is this new function upstream and in our branch already?

I suppose there is no ordering constraint since we fail now, and if we
take this patch we'll just fail more explicitly with an ENOSYS type
error unless/until the qemu half is in place.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 25 09:15:16 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 09:15:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGREP-0001Be-D7; Tue, 25 Sep 2012 09:15:05 +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 1TGREO-0001BY-Gr
	for xen-devel@lists.xen.org; Tue, 25 Sep 2012 09:15:04 +0000
Received: from [85.158.143.35:4418] by server-2.bemta-4.messagelabs.com id
	77/56-06610-71671605; Tue, 25 Sep 2012 09:15:03 +0000
X-Env-Sender: xudong.hao@intel.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1348564501!12631624!1
X-Originating-IP: [192.55.52.93]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjkzID0+IDM0NjU0Mw==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20476 invoked from network); 25 Sep 2012 09:15:02 -0000
Received: from mga11.intel.com (HELO mga11.intel.com) (192.55.52.93)
	by server-8.tower-21.messagelabs.com with SMTP;
	25 Sep 2012 09:15:02 -0000
Received: from fmsmga002.fm.intel.com ([10.253.24.26])
	by fmsmga102.fm.intel.com with ESMTP; 25 Sep 2012 02:15:01 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.80,481,1344236400"; d="scan'208";a="226379679"
Received: from fmsmsx104.amr.corp.intel.com ([10.19.9.35])
	by fmsmga002.fm.intel.com with ESMTP; 25 Sep 2012 02:15:00 -0700
Received: from fmsmsx151.amr.corp.intel.com (10.19.17.220) by
	FMSMSX104.amr.corp.intel.com (10.19.9.35) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Tue, 25 Sep 2012 02:15:00 -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; Tue, 25 Sep 2012 02:14:59 -0700
Received: from shsmsx102.ccr.corp.intel.com ([169.254.2.92]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.175]) with mapi id
	14.01.0355.002; Tue, 25 Sep 2012 17:14:58 +0800
From: "Hao, Xudong" <xudong.hao@intel.com>
To: Ian Campbell <Ian.Campbell@citrix.com>, Ian Jackson
	<Ian.Jackson@eu.citrix.com>
Thread-Topic: [PATCH v2] xen/tools: Add 64 bits big bar support
Thread-Index: AQHNms4J6w8sNO8+FEeWdkWyUHsLXpeaNLGAgACRnvA=
Date: Tue, 25 Sep 2012 09:14:57 +0000
Message-ID: <403610A45A2B5242BD291EDAE8B37D300FEC69A5@SHSMSX102.ccr.corp.intel.com>
References: <1348543998-31304-1-git-send-email-xudong.hao@intel.com>
	<1348561909.3452.108.camel@zakaz.uk.xensource.com>
In-Reply-To: <1348561909.3452.108.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: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>, "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] xen/tools: Add 64 bits big bar support
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


> -----Original Message-----
> From: Ian Campbell [mailto:Ian.Campbell@citrix.com]
> Sent: Tuesday, September 25, 2012 4:32 PM
> To: Ian Jackson
> Cc: xen-devel@lists.xen.org; Stefano Stabellini; jbeulich@suse.com; Zhang,
> Xiantao; Hao, Xudong
> Subject: Re: [PATCH v2] xen/tools: Add 64 bits big bar support
> 
> On Tue, 2012-09-25 at 04:33 +0100, an unknown sender wrote:
> > Currently it is assumed PCI device BAR access < 4G memory. If there is such a
> > device whose BAR size is larger than 4G, it must access > 4G memory
> address.
> > This patch enable the 64bits big BAR support on hvmloader.
> 
> Does this work in both qemu-xen-traditional/ROMBIOS and qemu-xen/SeaBIOS
> configurations? Or does the BIOS not care about this stuff?
> 
It's tested pass on both qemu-xen-traditional/ROMBIOS and qemu/SeaBIOS.

-Xudong

> Ian
> 
> >
> > Changes from v1:
> > 1) Set Dynamic MMIO high memory address instead of a fixed number 640G
> > 2) Mask bar_sz earlier to avoid older code changes
> > 3) Add bar size barrier to judge high memory resource
> > 4) Clean up bar64_relocate code
> >
> > Signed-off-by: Xiantao Zhang <xiantao.zhang@intel.com>
> > Signed-off-by: Xudong Hao <xudong.hao@intel.com>
> >
> > diff -r dc56a9defa30 tools/firmware/hvmloader/cacheattr.c
> > --- a/tools/firmware/hvmloader/cacheattr.c	Tue Aug 14 10:28:14 2012
> +0200
> > +++ b/tools/firmware/hvmloader/cacheattr.c	Wed Sep 12 14:50:55 2012
> +0800
> > @@ -40,17 +40,10 @@
> >  #define MSR_PAT              0x0277
> >  #define MSR_MTRRdefType      0x02ff
> >
> > -void cacheattr_init(void)
> > +unsigned int cpu_phys_addr(void)
> >  {
> >      uint32_t eax, ebx, ecx, edx;
> > -    uint64_t mtrr_cap, mtrr_def, content, addr_mask;
> > -    unsigned int i, nr_var_ranges, phys_bits = 36;
> > -
> > -    /* Does the CPU support architectural MTRRs? */
> > -    cpuid(0x00000001, &eax, &ebx, &ecx, &edx);
> > -    if ( !(edx & (1u << 12)) )
> > -         return;
> > -
> > +    unsigned int phys_bits = 36;
> >      /* Find the physical address size for this CPU. */
> >      cpuid(0x80000000, &eax, &ebx, &ecx, &edx);
> >      if ( eax >= 0x80000008 )
> > @@ -59,6 +52,22 @@
> >          phys_bits = (uint8_t)eax;
> >      }
> >
> > +    return phys_bits;
> > +}
> > +
> > +void cacheattr_init(void)
> > +{
> > +    uint32_t eax, ebx, ecx, edx;
> > +    uint64_t mtrr_cap, mtrr_def, content, addr_mask;
> > +    unsigned int i, nr_var_ranges, phys_bits;
> > +
> > +    /* Does the CPU support architectural MTRRs? */
> > +    cpuid(0x00000001, &eax, &ebx, &ecx, &edx);
> > +    if ( !(edx & (1u << 12)) )
> > +         return;
> > +
> > +    phys_bits = cpu_phys_addr();
> > +
> >      printf("%u-bit phys ... ", phys_bits);
> >
> >      addr_mask = ((1ull << phys_bits) - 1) & ~((1ull << 12) - 1);
> > diff -r dc56a9defa30 tools/firmware/hvmloader/config.h
> > --- a/tools/firmware/hvmloader/config.h	Tue Aug 14 10:28:14 2012 +0200
> > +++ b/tools/firmware/hvmloader/config.h	Wed Sep 12 14:50:55 2012 +0800
> > @@ -53,6 +53,8 @@
> >  /* MMIO hole: Hardcoded defaults, which can be dynamically expanded. */
> >  #define PCI_MEM_START       0xf0000000
> >  #define PCI_MEM_END         0xfc000000
> > +#define PCI_MIN_BIG_BAR_SIZE          0x20000000
> > +
> >  extern unsigned long pci_mem_start, pci_mem_end;
> >
> >
> > diff -r dc56a9defa30 tools/firmware/hvmloader/pci.c
> > --- a/tools/firmware/hvmloader/pci.c	Tue Aug 14 10:28:14 2012 +0200
> > +++ b/tools/firmware/hvmloader/pci.c	Wed Sep 12 14:50:55 2012 +0800
> > @@ -36,19 +36,25 @@
> >
> >  void pci_setup(void)
> >  {
> > -    uint32_t base, devfn, bar_reg, bar_data, bar_sz, cmd, mmio_total = 0;
> > +    uint8_t is_64bar, using_64bar, bar64_relocate = 0;
> > +    uint32_t devfn, bar_reg, cmd, bar_data, bar_data_upper;
> > +    uint64_t base, bar_sz, bar_sz_upper, mmio_total = 0;
> >      uint32_t vga_devfn = 256;
> >      uint16_t class, vendor_id, device_id;
> >      unsigned int bar, pin, link, isa_irq;
> > +    int64_t mmio_left;
> >
> >      /* Resources assignable to PCI devices via BARs. */
> >      struct resource {
> > -        uint32_t base, max;
> > -    } *resource, mem_resource, io_resource;
> > +        uint64_t base, max;
> > +    } *resource, mem_resource, high_mem_resource, io_resource;
> >
> >      /* Create a list of device BARs in descending order of size. */
> >      struct bars {
> > -        uint32_t devfn, bar_reg, bar_sz;
> > +        uint32_t is_64bar;
> > +        uint32_t devfn;
> > +        uint32_t bar_reg;
> > +        uint64_t bar_sz;
> >      } *bars = (struct bars *)scratch_start;
> >      unsigned int i, nr_bars = 0;
> >
> > @@ -133,22 +139,34 @@
> >          /* Map the I/O memory and port resources. */
> >          for ( bar = 0; bar < 7; bar++ )
> >          {
> > +            bar_sz_upper = 0;
> >              bar_reg = PCI_BASE_ADDRESS_0 + 4*bar;
> >              if ( bar == 6 )
> >                  bar_reg = PCI_ROM_ADDRESS;
> >
> >              bar_data = pci_readl(devfn, bar_reg);
> > +            is_64bar = !!((bar_data & (PCI_BASE_ADDRESS_SPACE |
> > +                         PCI_BASE_ADDRESS_MEM_TYPE_MASK)) ==
> > +                         (PCI_BASE_ADDRESS_SPACE_MEMORY |
> > +                         PCI_BASE_ADDRESS_MEM_TYPE_64));
> >              pci_writel(devfn, bar_reg, ~0);
> >              bar_sz = pci_readl(devfn, bar_reg);
> >              pci_writel(devfn, bar_reg, bar_data);
> > -            if ( bar_sz == 0 )
> > -                continue;
> >
> >              bar_sz &= (((bar_data & PCI_BASE_ADDRESS_SPACE) ==
> >                          PCI_BASE_ADDRESS_SPACE_MEMORY) ?
> >                         PCI_BASE_ADDRESS_MEM_MASK :
> >                         (PCI_BASE_ADDRESS_IO_MASK & 0xffff));
> > +            if (is_64bar) {
> > +                bar_data_upper = pci_readl(devfn, bar_reg + 4);
> > +                pci_writel(devfn, bar_reg + 4, ~0);
> > +                bar_sz_upper = pci_readl(devfn, bar_reg + 4);
> > +                pci_writel(devfn, bar_reg + 4, bar_data_upper);
> > +                bar_sz = (bar_sz_upper << 32) | bar_sz;
> > +            }
> >              bar_sz &= ~(bar_sz - 1);
> > +            if ( bar_sz == 0 )
> > +                continue;
> >
> >              for ( i = 0; i < nr_bars; i++ )
> >                  if ( bars[i].bar_sz < bar_sz )
> > @@ -157,6 +175,7 @@
> >              if ( i != nr_bars )
> >                  memmove(&bars[i+1], &bars[i], (nr_bars-i) *
> sizeof(*bars));
> >
> > +            bars[i].is_64bar = is_64bar;
> >              bars[i].devfn   = devfn;
> >              bars[i].bar_reg = bar_reg;
> >              bars[i].bar_sz  = bar_sz;
> > @@ -167,11 +186,8 @@
> >
> >              nr_bars++;
> >
> > -            /* Skip the upper-half of the address for a 64-bit BAR. */
> > -            if ( (bar_data & (PCI_BASE_ADDRESS_SPACE |
> > -
> PCI_BASE_ADDRESS_MEM_TYPE_MASK)) ==
> > -                 (PCI_BASE_ADDRESS_SPACE_MEMORY |
> > -                  PCI_BASE_ADDRESS_MEM_TYPE_64) )
> > +            /*The upper half is already calculated, skip it! */
> > +            if (is_64bar)
> >                  bar++;
> >          }
> >
> > @@ -197,6 +213,9 @@
> >              ((pci_mem_start << 1) != 0) )
> >          pci_mem_start <<= 1;
> >
> > +    if ( (pci_mem_start << 1) != 0 )
> > +        bar64_relocate = 1;
> > +
> >      /* Relocate RAM that overlaps PCI space (in 64k-page chunks). */
> >      while ( (pci_mem_start >> PAGE_SHIFT) <
> hvm_info->low_mem_pgend )
> >      {
> > @@ -218,11 +237,15 @@
> >          hvm_info->high_mem_pgend += nr_pages;
> >      }
> >
> > +    high_mem_resource.base = ((uint64_t)hvm_info->high_mem_pgend)
> << PAGE_SHIFT;
> > +    high_mem_resource.max = 1ull << cpu_phys_addr();
> >      mem_resource.base = pci_mem_start;
> >      mem_resource.max = pci_mem_end;
> >      io_resource.base = 0xc000;
> >      io_resource.max = 0x10000;
> >
> > +    mmio_left = pci_mem_end - pci_mem_start;
> > +
> >      /* Assign iomem and ioport resources in descending order of size. */
> >      for ( i = 0; i < nr_bars; i++ )
> >      {
> > @@ -230,13 +253,29 @@
> >          bar_reg = bars[i].bar_reg;
> >          bar_sz  = bars[i].bar_sz;
> >
> > +        using_64bar = bars[i].is_64bar && bar64_relocate && (mmio_left
> < bar_sz);
> >          bar_data = pci_readl(devfn, bar_reg);
> >
> >          if ( (bar_data & PCI_BASE_ADDRESS_SPACE) ==
> >               PCI_BASE_ADDRESS_SPACE_MEMORY )
> >          {
> > -            resource = &mem_resource;
> > -            bar_data &= ~PCI_BASE_ADDRESS_MEM_MASK;
> > +            /* Mapping high memory if PCI deivce is 64 bits bar and the
> bar size
> > +               is larger than 512M */
> > +            if (using_64bar && (bar_sz > PCI_MIN_BIG_BAR_SIZE)) {
> > +                if ( high_mem_resource.base & (bar_sz - 1) )
> > +                    high_mem_resource.base =
> high_mem_resource.base -
> > +                        (high_mem_resource.base & (bar_sz - 1)) +
> bar_sz;
> > +                else
> > +                    high_mem_resource.base =
> high_mem_resource.base -
> > +                        (high_mem_resource.base & (bar_sz - 1));
> > +                resource = &high_mem_resource;
> > +                bar_data &= ~PCI_BASE_ADDRESS_MEM_MASK;
> > +            }
> > +            else {
> > +                resource = &mem_resource;
> > +                bar_data &= ~PCI_BASE_ADDRESS_MEM_MASK;
> > +            }
> > +            mmio_left -= bar_sz;
> >          }
> >          else
> >          {
> > @@ -244,13 +283,14 @@
> >              bar_data &= ~PCI_BASE_ADDRESS_IO_MASK;
> >          }
> >
> > -        base = (resource->base + bar_sz - 1) & ~(bar_sz - 1);
> > -        bar_data |= base;
> > +        base = (resource->base  + bar_sz - 1) & ~(uint64_t)(bar_sz - 1);
> > +        bar_data |= (uint32_t)base;
> > +        bar_data_upper = (uint32_t)(base >> 32);
> >          base += bar_sz;
> >
> >          if ( (base < resource->base) || (base > resource->max) )
> >          {
> > -            printf("pci dev %02x:%x bar %02x size %08x: no space for "
> > +            printf("pci dev %02x:%x bar %02x size %llx: no space for "
> >                     "resource!\n", devfn>>3, devfn&7, bar_reg,
> bar_sz);
> >              continue;
> >          }
> > @@ -258,8 +298,8 @@
> >          resource->base = base;
> >
> >          pci_writel(devfn, bar_reg, bar_data);
> > -        printf("pci dev %02x:%x bar %02x size %08x: %08x\n",
> > -               devfn>>3, devfn&7, bar_reg, bar_sz, bar_data);
> > +        if (using_64bar)
> > +            pci_writel(devfn, bar_reg + 4, bar_data_upper);
> >
> >          /* Now enable the memory or I/O mapping. */
> >          cmd = pci_readw(devfn, PCI_COMMAND);
> > diff -r dc56a9defa30 tools/firmware/hvmloader/util.h
> > --- a/tools/firmware/hvmloader/util.h	Tue Aug 14 10:28:14 2012 +0200
> > +++ b/tools/firmware/hvmloader/util.h	Wed Sep 12 14:50:55 2012 +0800
> > @@ -215,6 +215,7 @@
> >  uint32_t rombios_highbios_setup(void);
> >
> >  /* Miscellaneous. */
> > +unsigned int cpu_phys_addr(void);
> >  void cacheattr_init(void);
> >  unsigned long create_mp_tables(void *table);
> >  void hvm_write_smbios_tables(
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 25 09:15:16 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 09:15:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGREP-0001Be-D7; Tue, 25 Sep 2012 09:15:05 +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 1TGREO-0001BY-Gr
	for xen-devel@lists.xen.org; Tue, 25 Sep 2012 09:15:04 +0000
Received: from [85.158.143.35:4418] by server-2.bemta-4.messagelabs.com id
	77/56-06610-71671605; Tue, 25 Sep 2012 09:15:03 +0000
X-Env-Sender: xudong.hao@intel.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1348564501!12631624!1
X-Originating-IP: [192.55.52.93]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjkzID0+IDM0NjU0Mw==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20476 invoked from network); 25 Sep 2012 09:15:02 -0000
Received: from mga11.intel.com (HELO mga11.intel.com) (192.55.52.93)
	by server-8.tower-21.messagelabs.com with SMTP;
	25 Sep 2012 09:15:02 -0000
Received: from fmsmga002.fm.intel.com ([10.253.24.26])
	by fmsmga102.fm.intel.com with ESMTP; 25 Sep 2012 02:15:01 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.80,481,1344236400"; d="scan'208";a="226379679"
Received: from fmsmsx104.amr.corp.intel.com ([10.19.9.35])
	by fmsmga002.fm.intel.com with ESMTP; 25 Sep 2012 02:15:00 -0700
Received: from fmsmsx151.amr.corp.intel.com (10.19.17.220) by
	FMSMSX104.amr.corp.intel.com (10.19.9.35) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Tue, 25 Sep 2012 02:15:00 -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; Tue, 25 Sep 2012 02:14:59 -0700
Received: from shsmsx102.ccr.corp.intel.com ([169.254.2.92]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.175]) with mapi id
	14.01.0355.002; Tue, 25 Sep 2012 17:14:58 +0800
From: "Hao, Xudong" <xudong.hao@intel.com>
To: Ian Campbell <Ian.Campbell@citrix.com>, Ian Jackson
	<Ian.Jackson@eu.citrix.com>
Thread-Topic: [PATCH v2] xen/tools: Add 64 bits big bar support
Thread-Index: AQHNms4J6w8sNO8+FEeWdkWyUHsLXpeaNLGAgACRnvA=
Date: Tue, 25 Sep 2012 09:14:57 +0000
Message-ID: <403610A45A2B5242BD291EDAE8B37D300FEC69A5@SHSMSX102.ccr.corp.intel.com>
References: <1348543998-31304-1-git-send-email-xudong.hao@intel.com>
	<1348561909.3452.108.camel@zakaz.uk.xensource.com>
In-Reply-To: <1348561909.3452.108.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: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>, "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] xen/tools: Add 64 bits big bar support
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


> -----Original Message-----
> From: Ian Campbell [mailto:Ian.Campbell@citrix.com]
> Sent: Tuesday, September 25, 2012 4:32 PM
> To: Ian Jackson
> Cc: xen-devel@lists.xen.org; Stefano Stabellini; jbeulich@suse.com; Zhang,
> Xiantao; Hao, Xudong
> Subject: Re: [PATCH v2] xen/tools: Add 64 bits big bar support
> 
> On Tue, 2012-09-25 at 04:33 +0100, an unknown sender wrote:
> > Currently it is assumed PCI device BAR access < 4G memory. If there is such a
> > device whose BAR size is larger than 4G, it must access > 4G memory
> address.
> > This patch enable the 64bits big BAR support on hvmloader.
> 
> Does this work in both qemu-xen-traditional/ROMBIOS and qemu-xen/SeaBIOS
> configurations? Or does the BIOS not care about this stuff?
> 
It's tested pass on both qemu-xen-traditional/ROMBIOS and qemu/SeaBIOS.

-Xudong

> Ian
> 
> >
> > Changes from v1:
> > 1) Set Dynamic MMIO high memory address instead of a fixed number 640G
> > 2) Mask bar_sz earlier to avoid older code changes
> > 3) Add bar size barrier to judge high memory resource
> > 4) Clean up bar64_relocate code
> >
> > Signed-off-by: Xiantao Zhang <xiantao.zhang@intel.com>
> > Signed-off-by: Xudong Hao <xudong.hao@intel.com>
> >
> > diff -r dc56a9defa30 tools/firmware/hvmloader/cacheattr.c
> > --- a/tools/firmware/hvmloader/cacheattr.c	Tue Aug 14 10:28:14 2012
> +0200
> > +++ b/tools/firmware/hvmloader/cacheattr.c	Wed Sep 12 14:50:55 2012
> +0800
> > @@ -40,17 +40,10 @@
> >  #define MSR_PAT              0x0277
> >  #define MSR_MTRRdefType      0x02ff
> >
> > -void cacheattr_init(void)
> > +unsigned int cpu_phys_addr(void)
> >  {
> >      uint32_t eax, ebx, ecx, edx;
> > -    uint64_t mtrr_cap, mtrr_def, content, addr_mask;
> > -    unsigned int i, nr_var_ranges, phys_bits = 36;
> > -
> > -    /* Does the CPU support architectural MTRRs? */
> > -    cpuid(0x00000001, &eax, &ebx, &ecx, &edx);
> > -    if ( !(edx & (1u << 12)) )
> > -         return;
> > -
> > +    unsigned int phys_bits = 36;
> >      /* Find the physical address size for this CPU. */
> >      cpuid(0x80000000, &eax, &ebx, &ecx, &edx);
> >      if ( eax >= 0x80000008 )
> > @@ -59,6 +52,22 @@
> >          phys_bits = (uint8_t)eax;
> >      }
> >
> > +    return phys_bits;
> > +}
> > +
> > +void cacheattr_init(void)
> > +{
> > +    uint32_t eax, ebx, ecx, edx;
> > +    uint64_t mtrr_cap, mtrr_def, content, addr_mask;
> > +    unsigned int i, nr_var_ranges, phys_bits;
> > +
> > +    /* Does the CPU support architectural MTRRs? */
> > +    cpuid(0x00000001, &eax, &ebx, &ecx, &edx);
> > +    if ( !(edx & (1u << 12)) )
> > +         return;
> > +
> > +    phys_bits = cpu_phys_addr();
> > +
> >      printf("%u-bit phys ... ", phys_bits);
> >
> >      addr_mask = ((1ull << phys_bits) - 1) & ~((1ull << 12) - 1);
> > diff -r dc56a9defa30 tools/firmware/hvmloader/config.h
> > --- a/tools/firmware/hvmloader/config.h	Tue Aug 14 10:28:14 2012 +0200
> > +++ b/tools/firmware/hvmloader/config.h	Wed Sep 12 14:50:55 2012 +0800
> > @@ -53,6 +53,8 @@
> >  /* MMIO hole: Hardcoded defaults, which can be dynamically expanded. */
> >  #define PCI_MEM_START       0xf0000000
> >  #define PCI_MEM_END         0xfc000000
> > +#define PCI_MIN_BIG_BAR_SIZE          0x20000000
> > +
> >  extern unsigned long pci_mem_start, pci_mem_end;
> >
> >
> > diff -r dc56a9defa30 tools/firmware/hvmloader/pci.c
> > --- a/tools/firmware/hvmloader/pci.c	Tue Aug 14 10:28:14 2012 +0200
> > +++ b/tools/firmware/hvmloader/pci.c	Wed Sep 12 14:50:55 2012 +0800
> > @@ -36,19 +36,25 @@
> >
> >  void pci_setup(void)
> >  {
> > -    uint32_t base, devfn, bar_reg, bar_data, bar_sz, cmd, mmio_total = 0;
> > +    uint8_t is_64bar, using_64bar, bar64_relocate = 0;
> > +    uint32_t devfn, bar_reg, cmd, bar_data, bar_data_upper;
> > +    uint64_t base, bar_sz, bar_sz_upper, mmio_total = 0;
> >      uint32_t vga_devfn = 256;
> >      uint16_t class, vendor_id, device_id;
> >      unsigned int bar, pin, link, isa_irq;
> > +    int64_t mmio_left;
> >
> >      /* Resources assignable to PCI devices via BARs. */
> >      struct resource {
> > -        uint32_t base, max;
> > -    } *resource, mem_resource, io_resource;
> > +        uint64_t base, max;
> > +    } *resource, mem_resource, high_mem_resource, io_resource;
> >
> >      /* Create a list of device BARs in descending order of size. */
> >      struct bars {
> > -        uint32_t devfn, bar_reg, bar_sz;
> > +        uint32_t is_64bar;
> > +        uint32_t devfn;
> > +        uint32_t bar_reg;
> > +        uint64_t bar_sz;
> >      } *bars = (struct bars *)scratch_start;
> >      unsigned int i, nr_bars = 0;
> >
> > @@ -133,22 +139,34 @@
> >          /* Map the I/O memory and port resources. */
> >          for ( bar = 0; bar < 7; bar++ )
> >          {
> > +            bar_sz_upper = 0;
> >              bar_reg = PCI_BASE_ADDRESS_0 + 4*bar;
> >              if ( bar == 6 )
> >                  bar_reg = PCI_ROM_ADDRESS;
> >
> >              bar_data = pci_readl(devfn, bar_reg);
> > +            is_64bar = !!((bar_data & (PCI_BASE_ADDRESS_SPACE |
> > +                         PCI_BASE_ADDRESS_MEM_TYPE_MASK)) ==
> > +                         (PCI_BASE_ADDRESS_SPACE_MEMORY |
> > +                         PCI_BASE_ADDRESS_MEM_TYPE_64));
> >              pci_writel(devfn, bar_reg, ~0);
> >              bar_sz = pci_readl(devfn, bar_reg);
> >              pci_writel(devfn, bar_reg, bar_data);
> > -            if ( bar_sz == 0 )
> > -                continue;
> >
> >              bar_sz &= (((bar_data & PCI_BASE_ADDRESS_SPACE) ==
> >                          PCI_BASE_ADDRESS_SPACE_MEMORY) ?
> >                         PCI_BASE_ADDRESS_MEM_MASK :
> >                         (PCI_BASE_ADDRESS_IO_MASK & 0xffff));
> > +            if (is_64bar) {
> > +                bar_data_upper = pci_readl(devfn, bar_reg + 4);
> > +                pci_writel(devfn, bar_reg + 4, ~0);
> > +                bar_sz_upper = pci_readl(devfn, bar_reg + 4);
> > +                pci_writel(devfn, bar_reg + 4, bar_data_upper);
> > +                bar_sz = (bar_sz_upper << 32) | bar_sz;
> > +            }
> >              bar_sz &= ~(bar_sz - 1);
> > +            if ( bar_sz == 0 )
> > +                continue;
> >
> >              for ( i = 0; i < nr_bars; i++ )
> >                  if ( bars[i].bar_sz < bar_sz )
> > @@ -157,6 +175,7 @@
> >              if ( i != nr_bars )
> >                  memmove(&bars[i+1], &bars[i], (nr_bars-i) *
> sizeof(*bars));
> >
> > +            bars[i].is_64bar = is_64bar;
> >              bars[i].devfn   = devfn;
> >              bars[i].bar_reg = bar_reg;
> >              bars[i].bar_sz  = bar_sz;
> > @@ -167,11 +186,8 @@
> >
> >              nr_bars++;
> >
> > -            /* Skip the upper-half of the address for a 64-bit BAR. */
> > -            if ( (bar_data & (PCI_BASE_ADDRESS_SPACE |
> > -
> PCI_BASE_ADDRESS_MEM_TYPE_MASK)) ==
> > -                 (PCI_BASE_ADDRESS_SPACE_MEMORY |
> > -                  PCI_BASE_ADDRESS_MEM_TYPE_64) )
> > +            /*The upper half is already calculated, skip it! */
> > +            if (is_64bar)
> >                  bar++;
> >          }
> >
> > @@ -197,6 +213,9 @@
> >              ((pci_mem_start << 1) != 0) )
> >          pci_mem_start <<= 1;
> >
> > +    if ( (pci_mem_start << 1) != 0 )
> > +        bar64_relocate = 1;
> > +
> >      /* Relocate RAM that overlaps PCI space (in 64k-page chunks). */
> >      while ( (pci_mem_start >> PAGE_SHIFT) <
> hvm_info->low_mem_pgend )
> >      {
> > @@ -218,11 +237,15 @@
> >          hvm_info->high_mem_pgend += nr_pages;
> >      }
> >
> > +    high_mem_resource.base = ((uint64_t)hvm_info->high_mem_pgend)
> << PAGE_SHIFT;
> > +    high_mem_resource.max = 1ull << cpu_phys_addr();
> >      mem_resource.base = pci_mem_start;
> >      mem_resource.max = pci_mem_end;
> >      io_resource.base = 0xc000;
> >      io_resource.max = 0x10000;
> >
> > +    mmio_left = pci_mem_end - pci_mem_start;
> > +
> >      /* Assign iomem and ioport resources in descending order of size. */
> >      for ( i = 0; i < nr_bars; i++ )
> >      {
> > @@ -230,13 +253,29 @@
> >          bar_reg = bars[i].bar_reg;
> >          bar_sz  = bars[i].bar_sz;
> >
> > +        using_64bar = bars[i].is_64bar && bar64_relocate && (mmio_left
> < bar_sz);
> >          bar_data = pci_readl(devfn, bar_reg);
> >
> >          if ( (bar_data & PCI_BASE_ADDRESS_SPACE) ==
> >               PCI_BASE_ADDRESS_SPACE_MEMORY )
> >          {
> > -            resource = &mem_resource;
> > -            bar_data &= ~PCI_BASE_ADDRESS_MEM_MASK;
> > +            /* Mapping high memory if PCI deivce is 64 bits bar and the
> bar size
> > +               is larger than 512M */
> > +            if (using_64bar && (bar_sz > PCI_MIN_BIG_BAR_SIZE)) {
> > +                if ( high_mem_resource.base & (bar_sz - 1) )
> > +                    high_mem_resource.base =
> high_mem_resource.base -
> > +                        (high_mem_resource.base & (bar_sz - 1)) +
> bar_sz;
> > +                else
> > +                    high_mem_resource.base =
> high_mem_resource.base -
> > +                        (high_mem_resource.base & (bar_sz - 1));
> > +                resource = &high_mem_resource;
> > +                bar_data &= ~PCI_BASE_ADDRESS_MEM_MASK;
> > +            }
> > +            else {
> > +                resource = &mem_resource;
> > +                bar_data &= ~PCI_BASE_ADDRESS_MEM_MASK;
> > +            }
> > +            mmio_left -= bar_sz;
> >          }
> >          else
> >          {
> > @@ -244,13 +283,14 @@
> >              bar_data &= ~PCI_BASE_ADDRESS_IO_MASK;
> >          }
> >
> > -        base = (resource->base + bar_sz - 1) & ~(bar_sz - 1);
> > -        bar_data |= base;
> > +        base = (resource->base  + bar_sz - 1) & ~(uint64_t)(bar_sz - 1);
> > +        bar_data |= (uint32_t)base;
> > +        bar_data_upper = (uint32_t)(base >> 32);
> >          base += bar_sz;
> >
> >          if ( (base < resource->base) || (base > resource->max) )
> >          {
> > -            printf("pci dev %02x:%x bar %02x size %08x: no space for "
> > +            printf("pci dev %02x:%x bar %02x size %llx: no space for "
> >                     "resource!\n", devfn>>3, devfn&7, bar_reg,
> bar_sz);
> >              continue;
> >          }
> > @@ -258,8 +298,8 @@
> >          resource->base = base;
> >
> >          pci_writel(devfn, bar_reg, bar_data);
> > -        printf("pci dev %02x:%x bar %02x size %08x: %08x\n",
> > -               devfn>>3, devfn&7, bar_reg, bar_sz, bar_data);
> > +        if (using_64bar)
> > +            pci_writel(devfn, bar_reg + 4, bar_data_upper);
> >
> >          /* Now enable the memory or I/O mapping. */
> >          cmd = pci_readw(devfn, PCI_COMMAND);
> > diff -r dc56a9defa30 tools/firmware/hvmloader/util.h
> > --- a/tools/firmware/hvmloader/util.h	Tue Aug 14 10:28:14 2012 +0200
> > +++ b/tools/firmware/hvmloader/util.h	Wed Sep 12 14:50:55 2012 +0800
> > @@ -215,6 +215,7 @@
> >  uint32_t rombios_highbios_setup(void);
> >
> >  /* Miscellaneous. */
> > +unsigned int cpu_phys_addr(void);
> >  void cacheattr_init(void);
> >  unsigned long create_mp_tables(void *table);
> >  void hvm_write_smbios_tables(
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 25 09:17:37 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 09: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 1TGRGh-0001IM-Ut; Tue, 25 Sep 2012 09:17: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 1TGRGg-0001IH-JN
	for xen-devel@lists.xensource.com; Tue, 25 Sep 2012 09:17:26 +0000
Received: from [85.158.143.99:51138] by server-3.bemta-4.messagelabs.com id
	B4/B9-10986-5A671605; Tue, 25 Sep 2012 09:17:25 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1348564645!24144671!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTA5ODg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28714 invoked from network); 25 Sep 2012 09:17:25 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Sep 2012 09:17:25 -0000
X-IronPort-AV: E=Sophos;i="4.80,481,1344211200"; d="scan'208";a="14743170"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Sep 2012 09:16: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.279.1; Tue, 25 Sep 2012 10:16: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
	1TGRFz-0004Fu-CJ; Tue, 25 Sep 2012 09:16:43 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1TGRFz-00077M-9G;
	Tue, 25 Sep 2012 10:16:43 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20577.30331.182069.50222@mariner.uk.xensource.com>
Date: Tue, 25 Sep 2012 10:16:43 +0100
To: Jan Beulich <JBeulich@suse.com>
In-Reply-To: <50618FE4020000780009D91D@nat28.tlf.novell.com>
References: <osstest-13861-mainreport@xen.org>
	<20577.28378.178321.883970@mariner.uk.xensource.com>
	<50618FE4020000780009D91D@nat28.tlf.novell.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [xen-unstable test] 13861: regressions - trouble:
 blocked/broken/fail/pass
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Jan Beulich writes ("Re: [xen-unstable test] 13861: regressions - trouble: blocked/broken/fail/pass"):
 On 25.09.12 at 10:44, Ian Jackson <Ian.Jackson@eu.citrix.com> wrote:
> > Jan, do you think it at all plausible that the cpuidle-related Xen bug
> > is somehow responsible ?  TBH it doesn't seem all that likely because
> > I've checked gall-mite and the CMOS is still fine, even though the
> > machine has experienced several of these crashes.
> 
> No, I don't see how this ought to be connected.

Thanks for the reply.

> Given previous occasions, is it perhaps that early Xen crashes
> (maybe in connection with the way Xen reboots the system afterwards)
> cause this independent of the reason for the crash? Or is there any
> sort of boot cycle detection active on those systems?

These are interesting theories.  If there is any sort of boot cycle
detection I don't think it's not configurable in the CMOS, as I went
through all of that when I set the machines up.

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 Sep 25 09:17:37 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 09: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 1TGRGh-0001IM-Ut; Tue, 25 Sep 2012 09:17: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 1TGRGg-0001IH-JN
	for xen-devel@lists.xensource.com; Tue, 25 Sep 2012 09:17:26 +0000
Received: from [85.158.143.99:51138] by server-3.bemta-4.messagelabs.com id
	B4/B9-10986-5A671605; Tue, 25 Sep 2012 09:17:25 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1348564645!24144671!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTA5ODg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28714 invoked from network); 25 Sep 2012 09:17:25 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Sep 2012 09:17:25 -0000
X-IronPort-AV: E=Sophos;i="4.80,481,1344211200"; d="scan'208";a="14743170"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Sep 2012 09:16: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.279.1; Tue, 25 Sep 2012 10:16: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
	1TGRFz-0004Fu-CJ; Tue, 25 Sep 2012 09:16:43 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1TGRFz-00077M-9G;
	Tue, 25 Sep 2012 10:16:43 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20577.30331.182069.50222@mariner.uk.xensource.com>
Date: Tue, 25 Sep 2012 10:16:43 +0100
To: Jan Beulich <JBeulich@suse.com>
In-Reply-To: <50618FE4020000780009D91D@nat28.tlf.novell.com>
References: <osstest-13861-mainreport@xen.org>
	<20577.28378.178321.883970@mariner.uk.xensource.com>
	<50618FE4020000780009D91D@nat28.tlf.novell.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [xen-unstable test] 13861: regressions - trouble:
 blocked/broken/fail/pass
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Jan Beulich writes ("Re: [xen-unstable test] 13861: regressions - trouble: blocked/broken/fail/pass"):
 On 25.09.12 at 10:44, Ian Jackson <Ian.Jackson@eu.citrix.com> wrote:
> > Jan, do you think it at all plausible that the cpuidle-related Xen bug
> > is somehow responsible ?  TBH it doesn't seem all that likely because
> > I've checked gall-mite and the CMOS is still fine, even though the
> > machine has experienced several of these crashes.
> 
> No, I don't see how this ought to be connected.

Thanks for the reply.

> Given previous occasions, is it perhaps that early Xen crashes
> (maybe in connection with the way Xen reboots the system afterwards)
> cause this independent of the reason for the crash? Or is there any
> sort of boot cycle detection active on those systems?

These are interesting theories.  If there is any sort of boot cycle
detection I don't think it's not configurable in the CMOS, as I went
through all of that when I set the machines up.

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 Sep 25 09:22:42 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 09: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 1TGRLb-0001U3-MM; Tue, 25 Sep 2012 09:22: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 1TGRLZ-0001Tw-U7
	for xen-devel@lists.xen.org; Tue, 25 Sep 2012 09:22:30 +0000
Received: from [85.158.139.211:46631] by server-14.bemta-5.messagelabs.com id
	2E/9E-05772-4D771605; Tue, 25 Sep 2012 09:22:28 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-206.messagelabs.com!1348564947!19865541!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTEwNzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 683 invoked from network); 25 Sep 2012 09:22:28 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Sep 2012 09:22:28 -0000
X-IronPort-AV: E=Sophos;i="4.80,481,1344211200"; d="scan'208";a="14743341"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Sep 2012 09:22:15 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Tue, 25 Sep 2012 10:22:15 +0100
Message-ID: <1348564934.3452.135.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Anthony PERARD <anthony.perard@citrix.com>
Date: Tue, 25 Sep 2012 10:22:14 +0100
In-Reply-To: <1347906148-9606-9-git-send-email-anthony.perard@citrix.com>
References: <1347906148-9606-1-git-send-email-anthony.perard@citrix.com>
	<1347906148-9606-9-git-send-email-anthony.perard@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Xen Devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH V2 8/9] libxl_dom: Call the right switch
 logdirty for the right DM.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2012-09-17 at 19:22 +0100, Anthony PERARD wrote:
> This patch dispatch the switch logdirty call depending on which device model
> version is running.
> 
> The call to qemu-xen is synchrone, not like the one to qemu-xen-traditional.

                          synchronous

IIRC there was talk of making the qmp calls asynchronous in the future,
since they might potentially be long running?

I also have some concerns about the existing use of the 3rd parameter to
switch_logdirty_done. In the prototype it takes an "int ok" but in the
definition takes a "int broke", which seems to be inverted. This value
is passed as the return_value argument to
libxl__xc_domain_saverestore_async_callback_done. The current callers
pass 0 (success) or -1 (error) and you follow that precedent, so you
patch is fine IMHO. But I wonder if there isn't scope for some cleanup
here somewhere.

However I don't think any of that should block this patch so:

Acked-by: Ian Campbell <ian.campbell@citrix.com>

IanJ, while I was looking I noticed that remus_checkpoint_dm_saved calls
libxl__xc_domain_saverestore_async_callback_done directly instead of via
switch_logdirty_done like everyone else. Since the s_l_d cancels timers
and stuff too I wonder if this is a bug?

Ian.

> 
> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
> ---
>  tools/libxl/libxl_dom.c | 45 ++++++++++++++++++++++++++++++++++++++++++---
>  1 file changed, 42 insertions(+), 3 deletions(-)
> 
> diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
> index e1de832..95da18e 100644
> --- a/tools/libxl/libxl_dom.c
> +++ b/tools/libxl/libxl_dom.c
> @@ -685,10 +685,10 @@ static void logdirty_init(libxl__logdirty_switch *lds)
>      libxl__ev_time_init(&lds->timeout);
>  }
>  
> -void libxl__domain_suspend_common_switch_qemu_logdirty
> -                               (int domid, unsigned enable, void *user)
> +static void domain_suspend_switch_qemu_xen_traditional_logdirty
> +                               (int domid, unsigned enable,
> +                                libxl__save_helper_state *shs)
>  {
> -    libxl__save_helper_state *shs = user;
>      libxl__egc *egc = shs->egc;
>      libxl__domain_suspend_state *dss = CONTAINER_OF(shs, *dss, shs);
>      libxl__logdirty_switch *lds = &dss->logdirty;
> @@ -756,6 +756,45 @@ void libxl__domain_suspend_common_switch_qemu_logdirty
>      switch_logdirty_done(egc,dss,-1);
>  }
>  
> +static void domain_suspend_switch_qemu_xen_logdirty
> +                               (int domid, unsigned enable,
> +                                libxl__save_helper_state *shs)
> +{
> +    libxl__egc *egc = shs->egc;
> +    libxl__domain_suspend_state *dss = CONTAINER_OF(shs, *dss, shs);
> +    STATE_AO_GC(dss->ao);
> +    int rc;
> +
> +    rc = libxl__qmp_set_global_dirty_log(gc, domid, enable);
> +    if (!rc) {
> +        libxl__xc_domain_saverestore_async_callback_done(egc, shs, 0);
> +    } else {
> +        LOG(ERROR,"logdirty switch failed (rc=%d), aborting suspend",rc);
> +        libxl__xc_domain_saverestore_async_callback_done(egc, shs, -1);
> +    }
> +}
> +
> +void libxl__domain_suspend_common_switch_qemu_logdirty
> +                               (int domid, unsigned enable, void *user)
> +{
> +    libxl__save_helper_state *shs = user;
> +    libxl__egc *egc = shs->egc;
> +    libxl__domain_suspend_state *dss = CONTAINER_OF(shs, *dss, shs);
> +    STATE_AO_GC(dss->ao);
> +
> +    switch (libxl__device_model_version_running(gc, domid)) {
> +    case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL:
> +        domain_suspend_switch_qemu_xen_traditional_logdirty(domid, enable, shs);
> +        break;
> +    case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN:
> +        domain_suspend_switch_qemu_xen_logdirty(domid, enable, shs);
> +        break;
> +    default:
> +        LOG(ERROR,"logdirty switch failed"
> +            ", no valid device model version found, aborting suspend");
> +        libxl__xc_domain_saverestore_async_callback_done(egc, shs, -1);
> +    }
> +}
>  static void switch_logdirty_timeout(libxl__egc *egc, libxl__ev_time *ev,
>                                      const struct timeval *requested_abs)
>  {



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 25 09:22:42 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 09: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 1TGRLb-0001U3-MM; Tue, 25 Sep 2012 09:22: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 1TGRLZ-0001Tw-U7
	for xen-devel@lists.xen.org; Tue, 25 Sep 2012 09:22:30 +0000
Received: from [85.158.139.211:46631] by server-14.bemta-5.messagelabs.com id
	2E/9E-05772-4D771605; Tue, 25 Sep 2012 09:22:28 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-206.messagelabs.com!1348564947!19865541!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTEwNzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 683 invoked from network); 25 Sep 2012 09:22:28 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Sep 2012 09:22:28 -0000
X-IronPort-AV: E=Sophos;i="4.80,481,1344211200"; d="scan'208";a="14743341"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Sep 2012 09:22:15 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Tue, 25 Sep 2012 10:22:15 +0100
Message-ID: <1348564934.3452.135.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Anthony PERARD <anthony.perard@citrix.com>
Date: Tue, 25 Sep 2012 10:22:14 +0100
In-Reply-To: <1347906148-9606-9-git-send-email-anthony.perard@citrix.com>
References: <1347906148-9606-1-git-send-email-anthony.perard@citrix.com>
	<1347906148-9606-9-git-send-email-anthony.perard@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Xen Devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH V2 8/9] libxl_dom: Call the right switch
 logdirty for the right DM.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2012-09-17 at 19:22 +0100, Anthony PERARD wrote:
> This patch dispatch the switch logdirty call depending on which device model
> version is running.
> 
> The call to qemu-xen is synchrone, not like the one to qemu-xen-traditional.

                          synchronous

IIRC there was talk of making the qmp calls asynchronous in the future,
since they might potentially be long running?

I also have some concerns about the existing use of the 3rd parameter to
switch_logdirty_done. In the prototype it takes an "int ok" but in the
definition takes a "int broke", which seems to be inverted. This value
is passed as the return_value argument to
libxl__xc_domain_saverestore_async_callback_done. The current callers
pass 0 (success) or -1 (error) and you follow that precedent, so you
patch is fine IMHO. But I wonder if there isn't scope for some cleanup
here somewhere.

However I don't think any of that should block this patch so:

Acked-by: Ian Campbell <ian.campbell@citrix.com>

IanJ, while I was looking I noticed that remus_checkpoint_dm_saved calls
libxl__xc_domain_saverestore_async_callback_done directly instead of via
switch_logdirty_done like everyone else. Since the s_l_d cancels timers
and stuff too I wonder if this is a bug?

Ian.

> 
> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
> ---
>  tools/libxl/libxl_dom.c | 45 ++++++++++++++++++++++++++++++++++++++++++---
>  1 file changed, 42 insertions(+), 3 deletions(-)
> 
> diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
> index e1de832..95da18e 100644
> --- a/tools/libxl/libxl_dom.c
> +++ b/tools/libxl/libxl_dom.c
> @@ -685,10 +685,10 @@ static void logdirty_init(libxl__logdirty_switch *lds)
>      libxl__ev_time_init(&lds->timeout);
>  }
>  
> -void libxl__domain_suspend_common_switch_qemu_logdirty
> -                               (int domid, unsigned enable, void *user)
> +static void domain_suspend_switch_qemu_xen_traditional_logdirty
> +                               (int domid, unsigned enable,
> +                                libxl__save_helper_state *shs)
>  {
> -    libxl__save_helper_state *shs = user;
>      libxl__egc *egc = shs->egc;
>      libxl__domain_suspend_state *dss = CONTAINER_OF(shs, *dss, shs);
>      libxl__logdirty_switch *lds = &dss->logdirty;
> @@ -756,6 +756,45 @@ void libxl__domain_suspend_common_switch_qemu_logdirty
>      switch_logdirty_done(egc,dss,-1);
>  }
>  
> +static void domain_suspend_switch_qemu_xen_logdirty
> +                               (int domid, unsigned enable,
> +                                libxl__save_helper_state *shs)
> +{
> +    libxl__egc *egc = shs->egc;
> +    libxl__domain_suspend_state *dss = CONTAINER_OF(shs, *dss, shs);
> +    STATE_AO_GC(dss->ao);
> +    int rc;
> +
> +    rc = libxl__qmp_set_global_dirty_log(gc, domid, enable);
> +    if (!rc) {
> +        libxl__xc_domain_saverestore_async_callback_done(egc, shs, 0);
> +    } else {
> +        LOG(ERROR,"logdirty switch failed (rc=%d), aborting suspend",rc);
> +        libxl__xc_domain_saverestore_async_callback_done(egc, shs, -1);
> +    }
> +}
> +
> +void libxl__domain_suspend_common_switch_qemu_logdirty
> +                               (int domid, unsigned enable, void *user)
> +{
> +    libxl__save_helper_state *shs = user;
> +    libxl__egc *egc = shs->egc;
> +    libxl__domain_suspend_state *dss = CONTAINER_OF(shs, *dss, shs);
> +    STATE_AO_GC(dss->ao);
> +
> +    switch (libxl__device_model_version_running(gc, domid)) {
> +    case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL:
> +        domain_suspend_switch_qemu_xen_traditional_logdirty(domid, enable, shs);
> +        break;
> +    case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN:
> +        domain_suspend_switch_qemu_xen_logdirty(domid, enable, shs);
> +        break;
> +    default:
> +        LOG(ERROR,"logdirty switch failed"
> +            ", no valid device model version found, aborting suspend");
> +        libxl__xc_domain_saverestore_async_callback_done(egc, shs, -1);
> +    }
> +}
>  static void switch_logdirty_timeout(libxl__egc *egc, libxl__ev_time *ev,
>                                      const struct timeval *requested_abs)
>  {



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 25 09:23:58 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 09:23:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGRMq-0001a0-9z; Tue, 25 Sep 2012 09:23:48 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1TGRMo-0001Zo-Ts
	for xen-devel@lists.xen.org; Tue, 25 Sep 2012 09:23:47 +0000
Received: from [85.158.139.211:56975] by server-7.bemta-5.messagelabs.com id
	7F/0A-00431-22871605; Tue, 25 Sep 2012 09:23:46 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-206.messagelabs.com!1348565025!19803971!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTEwNzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18594 invoked from network); 25 Sep 2012 09:23:45 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Sep 2012 09:23:45 -0000
X-IronPort-AV: E=Sophos;i="4.80,481,1344211200"; d="scan'208";a="14743391"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Sep 2012 09:23: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.279.1;
	Tue, 25 Sep 2012 10:23:45 +0100
Message-ID: <1348565023.3452.136.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Anthony PERARD <anthony.perard@citrix.com>
Date: Tue, 25 Sep 2012 10:23:43 +0100
In-Reply-To: <1347906148-9606-10-git-send-email-anthony.perard@citrix.com>
References: <1347906148-9606-1-git-send-email-anthony.perard@citrix.com>
	<1347906148-9606-10-git-send-email-anthony.perard@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Xen Devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH V2 9/9] libxl: Allow migration with qemu-xen.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2012-09-17 at 19:22 +0100, Anthony PERARD wrote:
> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>

As far as I'm concerned you can just remove the entire check now, its
only purpose was to catch this case.

Ian.

> ---
>  tools/libxl/libxl.c | 4 ----
>  1 file changed, 4 deletions(-)
> 
> diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
> index 0857c48..f08adf3 100644
> --- a/tools/libxl/libxl.c
> +++ b/tools/libxl/libxl.c
> @@ -770,10 +770,6 @@ int libxl_domain_suspend(libxl_ctx *ctx, uint32_t domid, int fd, int flags,
>      if (type == LIBXL_DOMAIN_TYPE_HVM && flags & LIBXL_SUSPEND_LIVE) {
>          switch (libxl__device_model_version_running(gc, domid)) {
>          case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN:
> -            LOG(ERROR,
> -                "cannot live migrate HVM domains with qemu-xen device-model");
> -            rc = ERROR_FAIL;
> -            goto out_err;
>          case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL:
>              /* No problem */
>              break;



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 25 09:23:58 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 09:23:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGRMq-0001a0-9z; Tue, 25 Sep 2012 09:23:48 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1TGRMo-0001Zo-Ts
	for xen-devel@lists.xen.org; Tue, 25 Sep 2012 09:23:47 +0000
Received: from [85.158.139.211:56975] by server-7.bemta-5.messagelabs.com id
	7F/0A-00431-22871605; Tue, 25 Sep 2012 09:23:46 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-206.messagelabs.com!1348565025!19803971!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTEwNzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18594 invoked from network); 25 Sep 2012 09:23:45 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Sep 2012 09:23:45 -0000
X-IronPort-AV: E=Sophos;i="4.80,481,1344211200"; d="scan'208";a="14743391"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Sep 2012 09:23: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.279.1;
	Tue, 25 Sep 2012 10:23:45 +0100
Message-ID: <1348565023.3452.136.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Anthony PERARD <anthony.perard@citrix.com>
Date: Tue, 25 Sep 2012 10:23:43 +0100
In-Reply-To: <1347906148-9606-10-git-send-email-anthony.perard@citrix.com>
References: <1347906148-9606-1-git-send-email-anthony.perard@citrix.com>
	<1347906148-9606-10-git-send-email-anthony.perard@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Xen Devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH V2 9/9] libxl: Allow migration with qemu-xen.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2012-09-17 at 19:22 +0100, Anthony PERARD wrote:
> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>

As far as I'm concerned you can just remove the entire check now, its
only purpose was to catch this case.

Ian.

> ---
>  tools/libxl/libxl.c | 4 ----
>  1 file changed, 4 deletions(-)
> 
> diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
> index 0857c48..f08adf3 100644
> --- a/tools/libxl/libxl.c
> +++ b/tools/libxl/libxl.c
> @@ -770,10 +770,6 @@ int libxl_domain_suspend(libxl_ctx *ctx, uint32_t domid, int fd, int flags,
>      if (type == LIBXL_DOMAIN_TYPE_HVM && flags & LIBXL_SUSPEND_LIVE) {
>          switch (libxl__device_model_version_running(gc, domid)) {
>          case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN:
> -            LOG(ERROR,
> -                "cannot live migrate HVM domains with qemu-xen device-model");
> -            rc = ERROR_FAIL;
> -            goto out_err;
>          case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL:
>              /* No problem */
>              break;



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 25 09:26:00 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 09:26: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 1TGROo-0001ib-Qo; Tue, 25 Sep 2012 09:25: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 1TGROm-0001iO-UT
	for xen-devel@lists.xen.org; Tue, 25 Sep 2012 09:25:49 +0000
Received: from [85.158.139.211:7931] by server-12.bemta-5.messagelabs.com id
	24/F7-20729-C9871605; Tue, 25 Sep 2012 09:25:48 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-206.messagelabs.com!1348565147!18348441!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTEwNzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21915 invoked from network); 25 Sep 2012 09:25:47 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Sep 2012 09:25:47 -0000
X-IronPort-AV: E=Sophos;i="4.80,481,1344211200"; d="scan'208";a="14743474"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Sep 2012 09:25: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.279.1;
	Tue, 25 Sep 2012 10:25:47 +0100
Message-ID: <1348565145.3452.138.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "Hao, Xudong" <xudong.hao@intel.com>
Date: Tue, 25 Sep 2012 10:25:45 +0100
In-Reply-To: <403610A45A2B5242BD291EDAE8B37D300FEC69A5@SHSMSX102.ccr.corp.intel.com>
References: <1348543998-31304-1-git-send-email-xudong.hao@intel.com>
	<1348561909.3452.108.camel@zakaz.uk.xensource.com>
	<403610A45A2B5242BD291EDAE8B37D300FEC69A5@SHSMSX102.ccr.corp.intel.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Keir Fraser <keir@xen.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.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] xen/tools: Add 64 bits big bar 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-09-25 at 10:14 +0100, Hao, Xudong wrote:
> > -----Original Message-----
> > From: Ian Campbell [mailto:Ian.Campbell@citrix.com]
> > Sent: Tuesday, September 25, 2012 4:32 PM
> > To: Ian Jackson
> > Cc: xen-devel@lists.xen.org; Stefano Stabellini; jbeulich@suse.com; Zhang,
> > Xiantao; Hao, Xudong
> > Subject: Re: [PATCH v2] xen/tools: Add 64 bits big bar support
> > 
> > On Tue, 2012-09-25 at 04:33 +0100, an unknown sender wrote:
> > > Currently it is assumed PCI device BAR access < 4G memory. If there is such a
> > > device whose BAR size is larger than 4G, it must access > 4G memory
> > address.
> > > This patch enable the 64bits big BAR support on hvmloader.
> > 
> > Does this work in both qemu-xen-traditional/ROMBIOS and qemu-xen/SeaBIOS
> > configurations? Or does the BIOS not care about this stuff?
> > 
> It's tested pass on both qemu-xen-traditional/ROMBIOS and qemu/SeaBIOS.

Sweet, thanks!

Adding Keir to the CC. He still watches over hvmloader IIRC.

> 
> -Xudong
> 
> > Ian
> > 
> > >
> > > Changes from v1:
> > > 1) Set Dynamic MMIO high memory address instead of a fixed number 640G
> > > 2) Mask bar_sz earlier to avoid older code changes
> > > 3) Add bar size barrier to judge high memory resource
> > > 4) Clean up bar64_relocate code
> > >
> > > Signed-off-by: Xiantao Zhang <xiantao.zhang@intel.com>
> > > Signed-off-by: Xudong Hao <xudong.hao@intel.com>
> > >
> > > diff -r dc56a9defa30 tools/firmware/hvmloader/cacheattr.c
> > > --- a/tools/firmware/hvmloader/cacheattr.c	Tue Aug 14 10:28:14 2012
> > +0200
> > > +++ b/tools/firmware/hvmloader/cacheattr.c	Wed Sep 12 14:50:55 2012
> > +0800
> > > @@ -40,17 +40,10 @@
> > >  #define MSR_PAT              0x0277
> > >  #define MSR_MTRRdefType      0x02ff
> > >
> > > -void cacheattr_init(void)
> > > +unsigned int cpu_phys_addr(void)
> > >  {
> > >      uint32_t eax, ebx, ecx, edx;
> > > -    uint64_t mtrr_cap, mtrr_def, content, addr_mask;
> > > -    unsigned int i, nr_var_ranges, phys_bits = 36;
> > > -
> > > -    /* Does the CPU support architectural MTRRs? */
> > > -    cpuid(0x00000001, &eax, &ebx, &ecx, &edx);
> > > -    if ( !(edx & (1u << 12)) )
> > > -         return;
> > > -
> > > +    unsigned int phys_bits = 36;
> > >      /* Find the physical address size for this CPU. */
> > >      cpuid(0x80000000, &eax, &ebx, &ecx, &edx);
> > >      if ( eax >= 0x80000008 )
> > > @@ -59,6 +52,22 @@
> > >          phys_bits = (uint8_t)eax;
> > >      }
> > >
> > > +    return phys_bits;
> > > +}
> > > +
> > > +void cacheattr_init(void)
> > > +{
> > > +    uint32_t eax, ebx, ecx, edx;
> > > +    uint64_t mtrr_cap, mtrr_def, content, addr_mask;
> > > +    unsigned int i, nr_var_ranges, phys_bits;
> > > +
> > > +    /* Does the CPU support architectural MTRRs? */
> > > +    cpuid(0x00000001, &eax, &ebx, &ecx, &edx);
> > > +    if ( !(edx & (1u << 12)) )
> > > +         return;
> > > +
> > > +    phys_bits = cpu_phys_addr();
> > > +
> > >      printf("%u-bit phys ... ", phys_bits);
> > >
> > >      addr_mask = ((1ull << phys_bits) - 1) & ~((1ull << 12) - 1);
> > > diff -r dc56a9defa30 tools/firmware/hvmloader/config.h
> > > --- a/tools/firmware/hvmloader/config.h	Tue Aug 14 10:28:14 2012 +0200
> > > +++ b/tools/firmware/hvmloader/config.h	Wed Sep 12 14:50:55 2012 +0800
> > > @@ -53,6 +53,8 @@
> > >  /* MMIO hole: Hardcoded defaults, which can be dynamically expanded. */
> > >  #define PCI_MEM_START       0xf0000000
> > >  #define PCI_MEM_END         0xfc000000
> > > +#define PCI_MIN_BIG_BAR_SIZE          0x20000000
> > > +
> > >  extern unsigned long pci_mem_start, pci_mem_end;
> > >
> > >
> > > diff -r dc56a9defa30 tools/firmware/hvmloader/pci.c
> > > --- a/tools/firmware/hvmloader/pci.c	Tue Aug 14 10:28:14 2012 +0200
> > > +++ b/tools/firmware/hvmloader/pci.c	Wed Sep 12 14:50:55 2012 +0800
> > > @@ -36,19 +36,25 @@
> > >
> > >  void pci_setup(void)
> > >  {
> > > -    uint32_t base, devfn, bar_reg, bar_data, bar_sz, cmd, mmio_total = 0;
> > > +    uint8_t is_64bar, using_64bar, bar64_relocate = 0;
> > > +    uint32_t devfn, bar_reg, cmd, bar_data, bar_data_upper;
> > > +    uint64_t base, bar_sz, bar_sz_upper, mmio_total = 0;
> > >      uint32_t vga_devfn = 256;
> > >      uint16_t class, vendor_id, device_id;
> > >      unsigned int bar, pin, link, isa_irq;
> > > +    int64_t mmio_left;
> > >
> > >      /* Resources assignable to PCI devices via BARs. */
> > >      struct resource {
> > > -        uint32_t base, max;
> > > -    } *resource, mem_resource, io_resource;
> > > +        uint64_t base, max;
> > > +    } *resource, mem_resource, high_mem_resource, io_resource;
> > >
> > >      /* Create a list of device BARs in descending order of size. */
> > >      struct bars {
> > > -        uint32_t devfn, bar_reg, bar_sz;
> > > +        uint32_t is_64bar;
> > > +        uint32_t devfn;
> > > +        uint32_t bar_reg;
> > > +        uint64_t bar_sz;
> > >      } *bars = (struct bars *)scratch_start;
> > >      unsigned int i, nr_bars = 0;
> > >
> > > @@ -133,22 +139,34 @@
> > >          /* Map the I/O memory and port resources. */
> > >          for ( bar = 0; bar < 7; bar++ )
> > >          {
> > > +            bar_sz_upper = 0;
> > >              bar_reg = PCI_BASE_ADDRESS_0 + 4*bar;
> > >              if ( bar == 6 )
> > >                  bar_reg = PCI_ROM_ADDRESS;
> > >
> > >              bar_data = pci_readl(devfn, bar_reg);
> > > +            is_64bar = !!((bar_data & (PCI_BASE_ADDRESS_SPACE |
> > > +                         PCI_BASE_ADDRESS_MEM_TYPE_MASK)) ==
> > > +                         (PCI_BASE_ADDRESS_SPACE_MEMORY |
> > > +                         PCI_BASE_ADDRESS_MEM_TYPE_64));
> > >              pci_writel(devfn, bar_reg, ~0);
> > >              bar_sz = pci_readl(devfn, bar_reg);
> > >              pci_writel(devfn, bar_reg, bar_data);
> > > -            if ( bar_sz == 0 )
> > > -                continue;
> > >
> > >              bar_sz &= (((bar_data & PCI_BASE_ADDRESS_SPACE) ==
> > >                          PCI_BASE_ADDRESS_SPACE_MEMORY) ?
> > >                         PCI_BASE_ADDRESS_MEM_MASK :
> > >                         (PCI_BASE_ADDRESS_IO_MASK & 0xffff));
> > > +            if (is_64bar) {
> > > +                bar_data_upper = pci_readl(devfn, bar_reg + 4);
> > > +                pci_writel(devfn, bar_reg + 4, ~0);
> > > +                bar_sz_upper = pci_readl(devfn, bar_reg + 4);
> > > +                pci_writel(devfn, bar_reg + 4, bar_data_upper);
> > > +                bar_sz = (bar_sz_upper << 32) | bar_sz;
> > > +            }
> > >              bar_sz &= ~(bar_sz - 1);
> > > +            if ( bar_sz == 0 )
> > > +                continue;
> > >
> > >              for ( i = 0; i < nr_bars; i++ )
> > >                  if ( bars[i].bar_sz < bar_sz )
> > > @@ -157,6 +175,7 @@
> > >              if ( i != nr_bars )
> > >                  memmove(&bars[i+1], &bars[i], (nr_bars-i) *
> > sizeof(*bars));
> > >
> > > +            bars[i].is_64bar = is_64bar;
> > >              bars[i].devfn   = devfn;
> > >              bars[i].bar_reg = bar_reg;
> > >              bars[i].bar_sz  = bar_sz;
> > > @@ -167,11 +186,8 @@
> > >
> > >              nr_bars++;
> > >
> > > -            /* Skip the upper-half of the address for a 64-bit BAR. */
> > > -            if ( (bar_data & (PCI_BASE_ADDRESS_SPACE |
> > > -
> > PCI_BASE_ADDRESS_MEM_TYPE_MASK)) ==
> > > -                 (PCI_BASE_ADDRESS_SPACE_MEMORY |
> > > -                  PCI_BASE_ADDRESS_MEM_TYPE_64) )
> > > +            /*The upper half is already calculated, skip it! */
> > > +            if (is_64bar)
> > >                  bar++;
> > >          }
> > >
> > > @@ -197,6 +213,9 @@
> > >              ((pci_mem_start << 1) != 0) )
> > >          pci_mem_start <<= 1;
> > >
> > > +    if ( (pci_mem_start << 1) != 0 )
> > > +        bar64_relocate = 1;
> > > +
> > >      /* Relocate RAM that overlaps PCI space (in 64k-page chunks). */
> > >      while ( (pci_mem_start >> PAGE_SHIFT) <
> > hvm_info->low_mem_pgend )
> > >      {
> > > @@ -218,11 +237,15 @@
> > >          hvm_info->high_mem_pgend += nr_pages;
> > >      }
> > >
> > > +    high_mem_resource.base = ((uint64_t)hvm_info->high_mem_pgend)
> > << PAGE_SHIFT;
> > > +    high_mem_resource.max = 1ull << cpu_phys_addr();
> > >      mem_resource.base = pci_mem_start;
> > >      mem_resource.max = pci_mem_end;
> > >      io_resource.base = 0xc000;
> > >      io_resource.max = 0x10000;
> > >
> > > +    mmio_left = pci_mem_end - pci_mem_start;
> > > +
> > >      /* Assign iomem and ioport resources in descending order of size. */
> > >      for ( i = 0; i < nr_bars; i++ )
> > >      {
> > > @@ -230,13 +253,29 @@
> > >          bar_reg = bars[i].bar_reg;
> > >          bar_sz  = bars[i].bar_sz;
> > >
> > > +        using_64bar = bars[i].is_64bar && bar64_relocate && (mmio_left
> > < bar_sz);
> > >          bar_data = pci_readl(devfn, bar_reg);
> > >
> > >          if ( (bar_data & PCI_BASE_ADDRESS_SPACE) ==
> > >               PCI_BASE_ADDRESS_SPACE_MEMORY )
> > >          {
> > > -            resource = &mem_resource;
> > > -            bar_data &= ~PCI_BASE_ADDRESS_MEM_MASK;
> > > +            /* Mapping high memory if PCI deivce is 64 bits bar and the
> > bar size
> > > +               is larger than 512M */
> > > +            if (using_64bar && (bar_sz > PCI_MIN_BIG_BAR_SIZE)) {
> > > +                if ( high_mem_resource.base & (bar_sz - 1) )
> > > +                    high_mem_resource.base =
> > high_mem_resource.base -
> > > +                        (high_mem_resource.base & (bar_sz - 1)) +
> > bar_sz;
> > > +                else
> > > +                    high_mem_resource.base =
> > high_mem_resource.base -
> > > +                        (high_mem_resource.base & (bar_sz - 1));
> > > +                resource = &high_mem_resource;
> > > +                bar_data &= ~PCI_BASE_ADDRESS_MEM_MASK;
> > > +            }
> > > +            else {
> > > +                resource = &mem_resource;
> > > +                bar_data &= ~PCI_BASE_ADDRESS_MEM_MASK;
> > > +            }
> > > +            mmio_left -= bar_sz;
> > >          }
> > >          else
> > >          {
> > > @@ -244,13 +283,14 @@
> > >              bar_data &= ~PCI_BASE_ADDRESS_IO_MASK;
> > >          }
> > >
> > > -        base = (resource->base + bar_sz - 1) & ~(bar_sz - 1);
> > > -        bar_data |= base;
> > > +        base = (resource->base  + bar_sz - 1) & ~(uint64_t)(bar_sz - 1);
> > > +        bar_data |= (uint32_t)base;
> > > +        bar_data_upper = (uint32_t)(base >> 32);
> > >          base += bar_sz;
> > >
> > >          if ( (base < resource->base) || (base > resource->max) )
> > >          {
> > > -            printf("pci dev %02x:%x bar %02x size %08x: no space for "
> > > +            printf("pci dev %02x:%x bar %02x size %llx: no space for "
> > >                     "resource!\n", devfn>>3, devfn&7, bar_reg,
> > bar_sz);
> > >              continue;
> > >          }
> > > @@ -258,8 +298,8 @@
> > >          resource->base = base;
> > >
> > >          pci_writel(devfn, bar_reg, bar_data);
> > > -        printf("pci dev %02x:%x bar %02x size %08x: %08x\n",
> > > -               devfn>>3, devfn&7, bar_reg, bar_sz, bar_data);
> > > +        if (using_64bar)
> > > +            pci_writel(devfn, bar_reg + 4, bar_data_upper);
> > >
> > >          /* Now enable the memory or I/O mapping. */
> > >          cmd = pci_readw(devfn, PCI_COMMAND);
> > > diff -r dc56a9defa30 tools/firmware/hvmloader/util.h
> > > --- a/tools/firmware/hvmloader/util.h	Tue Aug 14 10:28:14 2012 +0200
> > > +++ b/tools/firmware/hvmloader/util.h	Wed Sep 12 14:50:55 2012 +0800
> > > @@ -215,6 +215,7 @@
> > >  uint32_t rombios_highbios_setup(void);
> > >
> > >  /* Miscellaneous. */
> > > +unsigned int cpu_phys_addr(void);
> > >  void cacheattr_init(void);
> > >  unsigned long create_mp_tables(void *table);
> > >  void hvm_write_smbios_tables(
> > 
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 25 09:26:00 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 09:26: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 1TGROo-0001ib-Qo; Tue, 25 Sep 2012 09:25: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 1TGROm-0001iO-UT
	for xen-devel@lists.xen.org; Tue, 25 Sep 2012 09:25:49 +0000
Received: from [85.158.139.211:7931] by server-12.bemta-5.messagelabs.com id
	24/F7-20729-C9871605; Tue, 25 Sep 2012 09:25:48 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-206.messagelabs.com!1348565147!18348441!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTEwNzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21915 invoked from network); 25 Sep 2012 09:25:47 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Sep 2012 09:25:47 -0000
X-IronPort-AV: E=Sophos;i="4.80,481,1344211200"; d="scan'208";a="14743474"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Sep 2012 09:25: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.279.1;
	Tue, 25 Sep 2012 10:25:47 +0100
Message-ID: <1348565145.3452.138.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "Hao, Xudong" <xudong.hao@intel.com>
Date: Tue, 25 Sep 2012 10:25:45 +0100
In-Reply-To: <403610A45A2B5242BD291EDAE8B37D300FEC69A5@SHSMSX102.ccr.corp.intel.com>
References: <1348543998-31304-1-git-send-email-xudong.hao@intel.com>
	<1348561909.3452.108.camel@zakaz.uk.xensource.com>
	<403610A45A2B5242BD291EDAE8B37D300FEC69A5@SHSMSX102.ccr.corp.intel.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Keir Fraser <keir@xen.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.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] xen/tools: Add 64 bits big bar 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-09-25 at 10:14 +0100, Hao, Xudong wrote:
> > -----Original Message-----
> > From: Ian Campbell [mailto:Ian.Campbell@citrix.com]
> > Sent: Tuesday, September 25, 2012 4:32 PM
> > To: Ian Jackson
> > Cc: xen-devel@lists.xen.org; Stefano Stabellini; jbeulich@suse.com; Zhang,
> > Xiantao; Hao, Xudong
> > Subject: Re: [PATCH v2] xen/tools: Add 64 bits big bar support
> > 
> > On Tue, 2012-09-25 at 04:33 +0100, an unknown sender wrote:
> > > Currently it is assumed PCI device BAR access < 4G memory. If there is such a
> > > device whose BAR size is larger than 4G, it must access > 4G memory
> > address.
> > > This patch enable the 64bits big BAR support on hvmloader.
> > 
> > Does this work in both qemu-xen-traditional/ROMBIOS and qemu-xen/SeaBIOS
> > configurations? Or does the BIOS not care about this stuff?
> > 
> It's tested pass on both qemu-xen-traditional/ROMBIOS and qemu/SeaBIOS.

Sweet, thanks!

Adding Keir to the CC. He still watches over hvmloader IIRC.

> 
> -Xudong
> 
> > Ian
> > 
> > >
> > > Changes from v1:
> > > 1) Set Dynamic MMIO high memory address instead of a fixed number 640G
> > > 2) Mask bar_sz earlier to avoid older code changes
> > > 3) Add bar size barrier to judge high memory resource
> > > 4) Clean up bar64_relocate code
> > >
> > > Signed-off-by: Xiantao Zhang <xiantao.zhang@intel.com>
> > > Signed-off-by: Xudong Hao <xudong.hao@intel.com>
> > >
> > > diff -r dc56a9defa30 tools/firmware/hvmloader/cacheattr.c
> > > --- a/tools/firmware/hvmloader/cacheattr.c	Tue Aug 14 10:28:14 2012
> > +0200
> > > +++ b/tools/firmware/hvmloader/cacheattr.c	Wed Sep 12 14:50:55 2012
> > +0800
> > > @@ -40,17 +40,10 @@
> > >  #define MSR_PAT              0x0277
> > >  #define MSR_MTRRdefType      0x02ff
> > >
> > > -void cacheattr_init(void)
> > > +unsigned int cpu_phys_addr(void)
> > >  {
> > >      uint32_t eax, ebx, ecx, edx;
> > > -    uint64_t mtrr_cap, mtrr_def, content, addr_mask;
> > > -    unsigned int i, nr_var_ranges, phys_bits = 36;
> > > -
> > > -    /* Does the CPU support architectural MTRRs? */
> > > -    cpuid(0x00000001, &eax, &ebx, &ecx, &edx);
> > > -    if ( !(edx & (1u << 12)) )
> > > -         return;
> > > -
> > > +    unsigned int phys_bits = 36;
> > >      /* Find the physical address size for this CPU. */
> > >      cpuid(0x80000000, &eax, &ebx, &ecx, &edx);
> > >      if ( eax >= 0x80000008 )
> > > @@ -59,6 +52,22 @@
> > >          phys_bits = (uint8_t)eax;
> > >      }
> > >
> > > +    return phys_bits;
> > > +}
> > > +
> > > +void cacheattr_init(void)
> > > +{
> > > +    uint32_t eax, ebx, ecx, edx;
> > > +    uint64_t mtrr_cap, mtrr_def, content, addr_mask;
> > > +    unsigned int i, nr_var_ranges, phys_bits;
> > > +
> > > +    /* Does the CPU support architectural MTRRs? */
> > > +    cpuid(0x00000001, &eax, &ebx, &ecx, &edx);
> > > +    if ( !(edx & (1u << 12)) )
> > > +         return;
> > > +
> > > +    phys_bits = cpu_phys_addr();
> > > +
> > >      printf("%u-bit phys ... ", phys_bits);
> > >
> > >      addr_mask = ((1ull << phys_bits) - 1) & ~((1ull << 12) - 1);
> > > diff -r dc56a9defa30 tools/firmware/hvmloader/config.h
> > > --- a/tools/firmware/hvmloader/config.h	Tue Aug 14 10:28:14 2012 +0200
> > > +++ b/tools/firmware/hvmloader/config.h	Wed Sep 12 14:50:55 2012 +0800
> > > @@ -53,6 +53,8 @@
> > >  /* MMIO hole: Hardcoded defaults, which can be dynamically expanded. */
> > >  #define PCI_MEM_START       0xf0000000
> > >  #define PCI_MEM_END         0xfc000000
> > > +#define PCI_MIN_BIG_BAR_SIZE          0x20000000
> > > +
> > >  extern unsigned long pci_mem_start, pci_mem_end;
> > >
> > >
> > > diff -r dc56a9defa30 tools/firmware/hvmloader/pci.c
> > > --- a/tools/firmware/hvmloader/pci.c	Tue Aug 14 10:28:14 2012 +0200
> > > +++ b/tools/firmware/hvmloader/pci.c	Wed Sep 12 14:50:55 2012 +0800
> > > @@ -36,19 +36,25 @@
> > >
> > >  void pci_setup(void)
> > >  {
> > > -    uint32_t base, devfn, bar_reg, bar_data, bar_sz, cmd, mmio_total = 0;
> > > +    uint8_t is_64bar, using_64bar, bar64_relocate = 0;
> > > +    uint32_t devfn, bar_reg, cmd, bar_data, bar_data_upper;
> > > +    uint64_t base, bar_sz, bar_sz_upper, mmio_total = 0;
> > >      uint32_t vga_devfn = 256;
> > >      uint16_t class, vendor_id, device_id;
> > >      unsigned int bar, pin, link, isa_irq;
> > > +    int64_t mmio_left;
> > >
> > >      /* Resources assignable to PCI devices via BARs. */
> > >      struct resource {
> > > -        uint32_t base, max;
> > > -    } *resource, mem_resource, io_resource;
> > > +        uint64_t base, max;
> > > +    } *resource, mem_resource, high_mem_resource, io_resource;
> > >
> > >      /* Create a list of device BARs in descending order of size. */
> > >      struct bars {
> > > -        uint32_t devfn, bar_reg, bar_sz;
> > > +        uint32_t is_64bar;
> > > +        uint32_t devfn;
> > > +        uint32_t bar_reg;
> > > +        uint64_t bar_sz;
> > >      } *bars = (struct bars *)scratch_start;
> > >      unsigned int i, nr_bars = 0;
> > >
> > > @@ -133,22 +139,34 @@
> > >          /* Map the I/O memory and port resources. */
> > >          for ( bar = 0; bar < 7; bar++ )
> > >          {
> > > +            bar_sz_upper = 0;
> > >              bar_reg = PCI_BASE_ADDRESS_0 + 4*bar;
> > >              if ( bar == 6 )
> > >                  bar_reg = PCI_ROM_ADDRESS;
> > >
> > >              bar_data = pci_readl(devfn, bar_reg);
> > > +            is_64bar = !!((bar_data & (PCI_BASE_ADDRESS_SPACE |
> > > +                         PCI_BASE_ADDRESS_MEM_TYPE_MASK)) ==
> > > +                         (PCI_BASE_ADDRESS_SPACE_MEMORY |
> > > +                         PCI_BASE_ADDRESS_MEM_TYPE_64));
> > >              pci_writel(devfn, bar_reg, ~0);
> > >              bar_sz = pci_readl(devfn, bar_reg);
> > >              pci_writel(devfn, bar_reg, bar_data);
> > > -            if ( bar_sz == 0 )
> > > -                continue;
> > >
> > >              bar_sz &= (((bar_data & PCI_BASE_ADDRESS_SPACE) ==
> > >                          PCI_BASE_ADDRESS_SPACE_MEMORY) ?
> > >                         PCI_BASE_ADDRESS_MEM_MASK :
> > >                         (PCI_BASE_ADDRESS_IO_MASK & 0xffff));
> > > +            if (is_64bar) {
> > > +                bar_data_upper = pci_readl(devfn, bar_reg + 4);
> > > +                pci_writel(devfn, bar_reg + 4, ~0);
> > > +                bar_sz_upper = pci_readl(devfn, bar_reg + 4);
> > > +                pci_writel(devfn, bar_reg + 4, bar_data_upper);
> > > +                bar_sz = (bar_sz_upper << 32) | bar_sz;
> > > +            }
> > >              bar_sz &= ~(bar_sz - 1);
> > > +            if ( bar_sz == 0 )
> > > +                continue;
> > >
> > >              for ( i = 0; i < nr_bars; i++ )
> > >                  if ( bars[i].bar_sz < bar_sz )
> > > @@ -157,6 +175,7 @@
> > >              if ( i != nr_bars )
> > >                  memmove(&bars[i+1], &bars[i], (nr_bars-i) *
> > sizeof(*bars));
> > >
> > > +            bars[i].is_64bar = is_64bar;
> > >              bars[i].devfn   = devfn;
> > >              bars[i].bar_reg = bar_reg;
> > >              bars[i].bar_sz  = bar_sz;
> > > @@ -167,11 +186,8 @@
> > >
> > >              nr_bars++;
> > >
> > > -            /* Skip the upper-half of the address for a 64-bit BAR. */
> > > -            if ( (bar_data & (PCI_BASE_ADDRESS_SPACE |
> > > -
> > PCI_BASE_ADDRESS_MEM_TYPE_MASK)) ==
> > > -                 (PCI_BASE_ADDRESS_SPACE_MEMORY |
> > > -                  PCI_BASE_ADDRESS_MEM_TYPE_64) )
> > > +            /*The upper half is already calculated, skip it! */
> > > +            if (is_64bar)
> > >                  bar++;
> > >          }
> > >
> > > @@ -197,6 +213,9 @@
> > >              ((pci_mem_start << 1) != 0) )
> > >          pci_mem_start <<= 1;
> > >
> > > +    if ( (pci_mem_start << 1) != 0 )
> > > +        bar64_relocate = 1;
> > > +
> > >      /* Relocate RAM that overlaps PCI space (in 64k-page chunks). */
> > >      while ( (pci_mem_start >> PAGE_SHIFT) <
> > hvm_info->low_mem_pgend )
> > >      {
> > > @@ -218,11 +237,15 @@
> > >          hvm_info->high_mem_pgend += nr_pages;
> > >      }
> > >
> > > +    high_mem_resource.base = ((uint64_t)hvm_info->high_mem_pgend)
> > << PAGE_SHIFT;
> > > +    high_mem_resource.max = 1ull << cpu_phys_addr();
> > >      mem_resource.base = pci_mem_start;
> > >      mem_resource.max = pci_mem_end;
> > >      io_resource.base = 0xc000;
> > >      io_resource.max = 0x10000;
> > >
> > > +    mmio_left = pci_mem_end - pci_mem_start;
> > > +
> > >      /* Assign iomem and ioport resources in descending order of size. */
> > >      for ( i = 0; i < nr_bars; i++ )
> > >      {
> > > @@ -230,13 +253,29 @@
> > >          bar_reg = bars[i].bar_reg;
> > >          bar_sz  = bars[i].bar_sz;
> > >
> > > +        using_64bar = bars[i].is_64bar && bar64_relocate && (mmio_left
> > < bar_sz);
> > >          bar_data = pci_readl(devfn, bar_reg);
> > >
> > >          if ( (bar_data & PCI_BASE_ADDRESS_SPACE) ==
> > >               PCI_BASE_ADDRESS_SPACE_MEMORY )
> > >          {
> > > -            resource = &mem_resource;
> > > -            bar_data &= ~PCI_BASE_ADDRESS_MEM_MASK;
> > > +            /* Mapping high memory if PCI deivce is 64 bits bar and the
> > bar size
> > > +               is larger than 512M */
> > > +            if (using_64bar && (bar_sz > PCI_MIN_BIG_BAR_SIZE)) {
> > > +                if ( high_mem_resource.base & (bar_sz - 1) )
> > > +                    high_mem_resource.base =
> > high_mem_resource.base -
> > > +                        (high_mem_resource.base & (bar_sz - 1)) +
> > bar_sz;
> > > +                else
> > > +                    high_mem_resource.base =
> > high_mem_resource.base -
> > > +                        (high_mem_resource.base & (bar_sz - 1));
> > > +                resource = &high_mem_resource;
> > > +                bar_data &= ~PCI_BASE_ADDRESS_MEM_MASK;
> > > +            }
> > > +            else {
> > > +                resource = &mem_resource;
> > > +                bar_data &= ~PCI_BASE_ADDRESS_MEM_MASK;
> > > +            }
> > > +            mmio_left -= bar_sz;
> > >          }
> > >          else
> > >          {
> > > @@ -244,13 +283,14 @@
> > >              bar_data &= ~PCI_BASE_ADDRESS_IO_MASK;
> > >          }
> > >
> > > -        base = (resource->base + bar_sz - 1) & ~(bar_sz - 1);
> > > -        bar_data |= base;
> > > +        base = (resource->base  + bar_sz - 1) & ~(uint64_t)(bar_sz - 1);
> > > +        bar_data |= (uint32_t)base;
> > > +        bar_data_upper = (uint32_t)(base >> 32);
> > >          base += bar_sz;
> > >
> > >          if ( (base < resource->base) || (base > resource->max) )
> > >          {
> > > -            printf("pci dev %02x:%x bar %02x size %08x: no space for "
> > > +            printf("pci dev %02x:%x bar %02x size %llx: no space for "
> > >                     "resource!\n", devfn>>3, devfn&7, bar_reg,
> > bar_sz);
> > >              continue;
> > >          }
> > > @@ -258,8 +298,8 @@
> > >          resource->base = base;
> > >
> > >          pci_writel(devfn, bar_reg, bar_data);
> > > -        printf("pci dev %02x:%x bar %02x size %08x: %08x\n",
> > > -               devfn>>3, devfn&7, bar_reg, bar_sz, bar_data);
> > > +        if (using_64bar)
> > > +            pci_writel(devfn, bar_reg + 4, bar_data_upper);
> > >
> > >          /* Now enable the memory or I/O mapping. */
> > >          cmd = pci_readw(devfn, PCI_COMMAND);
> > > diff -r dc56a9defa30 tools/firmware/hvmloader/util.h
> > > --- a/tools/firmware/hvmloader/util.h	Tue Aug 14 10:28:14 2012 +0200
> > > +++ b/tools/firmware/hvmloader/util.h	Wed Sep 12 14:50:55 2012 +0800
> > > @@ -215,6 +215,7 @@
> > >  uint32_t rombios_highbios_setup(void);
> > >
> > >  /* Miscellaneous. */
> > > +unsigned int cpu_phys_addr(void);
> > >  void cacheattr_init(void);
> > >  unsigned long create_mp_tables(void *table);
> > >  void hvm_write_smbios_tables(
> > 
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 25 09:27:45 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 09:27: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 1TGRQU-0001q3-BD; Tue, 25 Sep 2012 09:27:34 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1TGRQT-0001ps-2R
	for xen-devel@lists.xensource.com; Tue, 25 Sep 2012 09:27:33 +0000
Received: from [85.158.138.51:16717] by server-7.bemta-3.messagelabs.com id
	F9/69-32000-30971605; Tue, 25 Sep 2012 09:27:31 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1348565248!30080823!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTEwNzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3617 invoked from network); 25 Sep 2012 09:27:31 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Sep 2012 09:27:31 -0000
X-IronPort-AV: E=Sophos;i="4.80,481,1344211200"; d="scan'208";a="14743527"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Sep 2012 09:27: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.279.1;
	Tue, 25 Sep 2012 10:27:25 +0100
Message-ID: <1348565244.3452.139.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Date: Tue, 25 Sep 2012 10:27:24 +0100
In-Reply-To: <1345642066.12501.6.camel@zakaz.uk.xensource.com>
References: <alpine.DEB.2.02.1208141559360.21096@kaball.uk.xensource.com>
	<alpine.DEB.2.02.1208221213070.15568@kaball.uk.xensource.com>
	<1345642066.12501.6.camel@zakaz.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] libxl/qemu-xen: use cache=writeback for IDE
 and cache=none for SCSI
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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-08-22 at 14:27 +0100, Ian Campbell wrote:
> On Wed, 2012-08-22 at 12:13 +0100, Stefano Stabellini wrote:
> > On Tue, 14 Aug 2012, Stefano Stabellini wrote:
> > > Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> > 
> > ping

pong?

> 
> Is this an appropriate change during rcs, is it critical for 4.2 or
> should it wait for 4.3?
> 
> I think the changelog here is rather lacking, which makes it hard for me
> to decide what to do. e.g. the usual stuff: Why are you making this
> change? What is the impact? etc
> 
> What is the default for all these cases?
> 
> > > diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
> > > index 0c0084f..1c94e80 100644
> > > --- a/tools/libxl/libxl_dm.c
> > > +++ b/tools/libxl/libxl_dm.c
> > > @@ -549,10 +549,10 @@ static char ** libxl__build_device_model_args_new(libxl__gc *gc,
> > >              if (disks[i].is_cdrom) {
> > >                  if (disks[i].format == LIBXL_DISK_FORMAT_EMPTY)
> > >                      drive = libxl__sprintf
> > > -                        (gc, "if=ide,index=%d,media=cdrom", disk);
> > > +                        (gc, "if=ide,index=%d,media=cdrom,cache=writeback", disk);
> 
> Why does the cacheability matter for an empty device?
> 
> > >                  else
> > >                      drive = libxl__sprintf
> > > -                        (gc, "file=%s,if=ide,index=%d,media=cdrom,format=%s",
> > > +                        (gc, "file=%s,if=ide,index=%d,media=cdrom,format=%s,cache=writeback",
> 
> Does writeback mean anything for a r/o device?
> 
> > >                           disks[i].pdev_path, disk, format);
> > >              } else {
> > >                  if (disks[i].format == LIBXL_DISK_FORMAT_EMPTY) {
> > > @@ -575,11 +575,11 @@ static char ** libxl__build_device_model_args_new(libxl__gc *gc,
> > >                   */
> > >                  if (strncmp(disks[i].vdev, "sd", 2) == 0)
> > >                      drive = libxl__sprintf
> > > -                        (gc, "file=%s,if=scsi,bus=0,unit=%d,format=%s",
> > > +                        (gc, "file=%s,if=scsi,bus=0,unit=%d,format=%s,cache=none",
> > >                           disks[i].pdev_path, disk, format);
> > >                  else if (disk < 4)
> > >                      drive = libxl__sprintf
> > > -                        (gc, "file=%s,if=ide,index=%d,media=disk,format=%s",
> > > +                        (gc, "file=%s,if=ide,index=%d,media=disk,format=%s,cache=writeback",
> 
> Why is an SCSI disk treated differently to an IDE one wrt caching?
> 
> Ian.
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 25 09:27:45 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 09:27: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 1TGRQU-0001q3-BD; Tue, 25 Sep 2012 09:27:34 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1TGRQT-0001ps-2R
	for xen-devel@lists.xensource.com; Tue, 25 Sep 2012 09:27:33 +0000
Received: from [85.158.138.51:16717] by server-7.bemta-3.messagelabs.com id
	F9/69-32000-30971605; Tue, 25 Sep 2012 09:27:31 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1348565248!30080823!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTEwNzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3617 invoked from network); 25 Sep 2012 09:27:31 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Sep 2012 09:27:31 -0000
X-IronPort-AV: E=Sophos;i="4.80,481,1344211200"; d="scan'208";a="14743527"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Sep 2012 09:27: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.279.1;
	Tue, 25 Sep 2012 10:27:25 +0100
Message-ID: <1348565244.3452.139.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Date: Tue, 25 Sep 2012 10:27:24 +0100
In-Reply-To: <1345642066.12501.6.camel@zakaz.uk.xensource.com>
References: <alpine.DEB.2.02.1208141559360.21096@kaball.uk.xensource.com>
	<alpine.DEB.2.02.1208221213070.15568@kaball.uk.xensource.com>
	<1345642066.12501.6.camel@zakaz.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] libxl/qemu-xen: use cache=writeback for IDE
 and cache=none for SCSI
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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-08-22 at 14:27 +0100, Ian Campbell wrote:
> On Wed, 2012-08-22 at 12:13 +0100, Stefano Stabellini wrote:
> > On Tue, 14 Aug 2012, Stefano Stabellini wrote:
> > > Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> > 
> > ping

pong?

> 
> Is this an appropriate change during rcs, is it critical for 4.2 or
> should it wait for 4.3?
> 
> I think the changelog here is rather lacking, which makes it hard for me
> to decide what to do. e.g. the usual stuff: Why are you making this
> change? What is the impact? etc
> 
> What is the default for all these cases?
> 
> > > diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
> > > index 0c0084f..1c94e80 100644
> > > --- a/tools/libxl/libxl_dm.c
> > > +++ b/tools/libxl/libxl_dm.c
> > > @@ -549,10 +549,10 @@ static char ** libxl__build_device_model_args_new(libxl__gc *gc,
> > >              if (disks[i].is_cdrom) {
> > >                  if (disks[i].format == LIBXL_DISK_FORMAT_EMPTY)
> > >                      drive = libxl__sprintf
> > > -                        (gc, "if=ide,index=%d,media=cdrom", disk);
> > > +                        (gc, "if=ide,index=%d,media=cdrom,cache=writeback", disk);
> 
> Why does the cacheability matter for an empty device?
> 
> > >                  else
> > >                      drive = libxl__sprintf
> > > -                        (gc, "file=%s,if=ide,index=%d,media=cdrom,format=%s",
> > > +                        (gc, "file=%s,if=ide,index=%d,media=cdrom,format=%s,cache=writeback",
> 
> Does writeback mean anything for a r/o device?
> 
> > >                           disks[i].pdev_path, disk, format);
> > >              } else {
> > >                  if (disks[i].format == LIBXL_DISK_FORMAT_EMPTY) {
> > > @@ -575,11 +575,11 @@ static char ** libxl__build_device_model_args_new(libxl__gc *gc,
> > >                   */
> > >                  if (strncmp(disks[i].vdev, "sd", 2) == 0)
> > >                      drive = libxl__sprintf
> > > -                        (gc, "file=%s,if=scsi,bus=0,unit=%d,format=%s",
> > > +                        (gc, "file=%s,if=scsi,bus=0,unit=%d,format=%s,cache=none",
> > >                           disks[i].pdev_path, disk, format);
> > >                  else if (disk < 4)
> > >                      drive = libxl__sprintf
> > > -                        (gc, "file=%s,if=ide,index=%d,media=disk,format=%s",
> > > +                        (gc, "file=%s,if=ide,index=%d,media=disk,format=%s,cache=writeback",
> 
> Why is an SCSI disk treated differently to an IDE one wrt caching?
> 
> Ian.
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 25 09:36:16 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 09:36:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGRYj-0002BD-E3; Tue, 25 Sep 2012 09:36:05 +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 1TGRYh-0002Aw-N6
	for xen-devel@lists.xensource.com; Tue, 25 Sep 2012 09:36:03 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1348565714!10317124!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTEwNzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27916 invoked from network); 25 Sep 2012 09:35:14 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Sep 2012 09:35:14 -0000
X-IronPort-AV: E=Sophos;i="4.80,481,1344211200"; d="scan'208";a="14743831"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Sep 2012 09:35: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.279.1;
	Tue, 25 Sep 2012 10:35:14 +0100
Message-ID: <1348565712.3452.141.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Sander Eikelenboom <linux@eikelenboom.it>
Date: Tue, 25 Sep 2012 10:35:12 +0100
In-Reply-To: <patchbomb.1346960486@xentest.example.org>
References: <patchbomb.1346960486@xentest.example.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 0 of 3] xl and hotplug: Introduce and use
 shutdown and reboot xm compatibility options
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-09-06 at 20:41 +0100, Sander Eikelenboom wrote:
> The /etc/init.d/xendomains script makes use of options for the
> shutdown command defined in xendomains-sysconfig/default.
> These options were not implemented in xl, this patch series implements
> the options and by using the short variant makes it compatible with
> both xm and xl.
> 
> Signed-off-by: Sander Eikelenboom <linux@eikelenboom.it>

Hi Sander,

Are you still looking into the review feedback on these patches?

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 25 09:36:16 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 09:36:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGRYj-0002BD-E3; Tue, 25 Sep 2012 09:36:05 +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 1TGRYh-0002Aw-N6
	for xen-devel@lists.xensource.com; Tue, 25 Sep 2012 09:36:03 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1348565714!10317124!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTEwNzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27916 invoked from network); 25 Sep 2012 09:35:14 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Sep 2012 09:35:14 -0000
X-IronPort-AV: E=Sophos;i="4.80,481,1344211200"; d="scan'208";a="14743831"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Sep 2012 09:35: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.279.1;
	Tue, 25 Sep 2012 10:35:14 +0100
Message-ID: <1348565712.3452.141.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Sander Eikelenboom <linux@eikelenboom.it>
Date: Tue, 25 Sep 2012 10:35:12 +0100
In-Reply-To: <patchbomb.1346960486@xentest.example.org>
References: <patchbomb.1346960486@xentest.example.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 0 of 3] xl and hotplug: Introduce and use
 shutdown and reboot xm compatibility options
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, 2012-09-06 at 20:41 +0100, Sander Eikelenboom wrote:
> The /etc/init.d/xendomains script makes use of options for the
> shutdown command defined in xendomains-sysconfig/default.
> These options were not implemented in xl, this patch series implements
> the options and by using the short variant makes it compatible with
> both xm and xl.
> 
> Signed-off-by: Sander Eikelenboom <linux@eikelenboom.it>

Hi Sander,

Are you still looking into the review feedback on these patches?

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 25 09:41:18 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 09: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 1TGRdY-0002Ll-5l; Tue, 25 Sep 2012 09:41:04 +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 1TGRdW-0002Ld-MC
	for xen-devel@lists.xen.org; Tue, 25 Sep 2012 09:41:02 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1348566054!4595901!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTEwNzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11104 invoked from network); 25 Sep 2012 09:40:54 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Sep 2012 09:40:54 -0000
X-IronPort-AV: E=Sophos;i="4.80,481,1344211200"; d="scan'208";a="14743992"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Sep 2012 09:40:53 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Tue, 25 Sep 2012 10:40:54 +0100
Message-ID: <1348566052.3452.145.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, 25 Sep 2012 10:40:52 +0100
In-Reply-To: <ba1c6e807c8b1684a83e.1347871431@cosworth.uk.xensource.com>
References: <ba1c6e807c8b1684a83e.1347871431@cosworth.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>, "Keir \(Xen.org\)" <keir@xen.org>
Subject: Re: [Xen-devel] [PATCH] tools: bump SONAMEs for changes during 4.2
 development cycle
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ping?

On Mon, 2012-09-17 at 09:43 +0100, Ian Campbell wrote:
> # HG changeset patch
> # User Ian Campbell <ian.campbell@citrix.com>
> # Date 1347871358 -3600
> # Node ID ba1c6e807c8b1684a83e3692abcc5d42587f16f7
> # Parent  a649d26baee12239a12f5fba7e7746dc4b7d7c89
> tools: bump SONAMEs for changes during 4.2 development cycle.
> 
> We mostly did this as we went along, only a couple of minor number
> bumps were missed http://marc.info/?l=xen-devel&m=134366054929255&w=2:
>  - Bumped libxl from 1.0.0 -> 1.0.1
>  - Bumped libxenstore from 3.0.1 -> 3.0.2
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> ---
> This should be considered for 4.2.1.
> 
> diff -r a649d26baee1 -r ba1c6e807c8b tools/libxl/Makefile
> --- a/tools/libxl/Makefile	Mon Sep 17 09:29:33 2012 +0100
> +++ b/tools/libxl/Makefile	Mon Sep 17 09:42:38 2012 +0100
> @@ -9,7 +9,7 @@ MAJOR = 2.0
>  MINOR = 0
>  
>  XLUMAJOR = 1.0
> -XLUMINOR = 0
> +XLUMINOR = 1
>  
>  CFLAGS += -Werror -Wno-format-zero-length -Wmissing-declarations \
>  	-Wno-declaration-after-statement -Wformat-nonliteral
> diff -r a649d26baee1 -r ba1c6e807c8b tools/xenstore/Makefile
> --- a/tools/xenstore/Makefile	Mon Sep 17 09:29:33 2012 +0100
> +++ b/tools/xenstore/Makefile	Mon Sep 17 09:42:38 2012 +0100
> @@ -2,7 +2,7 @@ XEN_ROOT=$(CURDIR)/../..
>  include $(XEN_ROOT)/tools/Rules.mk
>  
>  MAJOR = 3.0
> -MINOR = 1
> +MINOR = 2
>  
>  CFLAGS += -Werror
>  CFLAGS += -I.
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Sep 25 09:41:18 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 09: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 1TGRdY-0002Ll-5l; Tue, 25 Sep 2012 09:41:04 +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 1TGRdW-0002Ld-MC
	for xen-devel@lists.xen.org; Tue, 25 Sep 2012 09:41:02 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1348566054!4595901!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTEwNzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11104 invoked from network); 25 Sep 2012 09:40:54 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Sep 2012 09:40:54 -0000
X-IronPort-AV: E=Sophos;i="4.80,481,1344211200"; d="scan'208";a="14743992"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Sep 2012 09:40:53 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Tue, 25 Sep 2012 10:40:54 +0100
Message-ID: <1348566052.3452.145.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, 25 Sep 2012 10:40:52 +0100
In-Reply-To: <ba1c6e807c8b1684a83e.1347871431@cosworth.uk.xensource.com>
References: <ba1c6e807c8b1684a83e.1347871431@cosworth.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>, "Keir \(Xen.org\)" <keir@xen.org>
Subject: Re: [Xen-devel] [PATCH] tools: bump SONAMEs for changes during 4.2
 development cycle
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ping?

On Mon, 2012-09-17 at 09:43 +0100, Ian Campbell wrote:
> # HG changeset patch
> # User Ian Campbell <ian.campbell@citrix.com>
> # Date 1347871358 -3600
> # Node ID ba1c6e807c8b1684a83e3692abcc5d42587f16f7
> # Parent  a649d26baee12239a12f5fba7e7746dc4b7d7c89
> tools: bump SONAMEs for changes during 4.2 development cycle.
> 
> We mostly did this as we went along, only a couple of minor number
> bumps were missed http://marc.info/?l=xen-devel&m=134366054929255&w=2:
>  - Bumped libxl from 1.0.0 -> 1.0.1
>  - Bumped libxenstore from 3.0.1 -> 3.0.2
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> ---
> This should be considered for 4.2.1.
> 
> diff -r a649d26baee1 -r ba1c6e807c8b tools/libxl/Makefile
> --- a/tools/libxl/Makefile	Mon Sep 17 09:29:33 2012 +0100
> +++ b/tools/libxl/Makefile	Mon Sep 17 09:42:38 2012 +0100
> @@ -9,7 +9,7 @@ MAJOR = 2.0
>  MINOR = 0
>  
>  XLUMAJOR = 1.0
> -XLUMINOR = 0
> +XLUMINOR = 1
>  
>  CFLAGS += -Werror -Wno-format-zero-length -Wmissing-declarations \
>  	-Wno-declaration-after-statement -Wformat-nonliteral
> diff -r a649d26baee1 -r ba1c6e807c8b tools/xenstore/Makefile
> --- a/tools/xenstore/Makefile	Mon Sep 17 09:29:33 2012 +0100
> +++ b/tools/xenstore/Makefile	Mon Sep 17 09:42:38 2012 +0100
> @@ -2,7 +2,7 @@ XEN_ROOT=$(CURDIR)/../..
>  include $(XEN_ROOT)/tools/Rules.mk
>  
>  MAJOR = 3.0
> -MINOR = 1
> +MINOR = 2
>  
>  CFLAGS += -Werror
>  CFLAGS += -I.
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Sep 25 09:54:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 09:54:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGRq0-0002YS-OV; Tue, 25 Sep 2012 09:53: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 1TGRpz-0002YN-KV
	for xen-devel@lists.xensource.com; Tue, 25 Sep 2012 09:53:55 +0000
Received: from [85.158.143.99:26399] by server-2.bemta-4.messagelabs.com id
	EC/D3-06610-33F71605; Tue, 25 Sep 2012 09:53:55 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1348566834!25550648!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTEwNzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21425 invoked from network); 25 Sep 2012 09:53:54 -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;
	25 Sep 2012 09:53:54 -0000
X-IronPort-AV: E=Sophos;i="4.80,481,1344211200"; d="scan'208";a="14744460"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Sep 2012 09:53: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.279.1;
	Tue, 25 Sep 2012 10:53:44 +0100
Message-ID: <1348566822.3452.151.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
Date: Tue, 25 Sep 2012 10:53:42 +0100
In-Reply-To: <5058B07C.1070404@jhuapl.edu>
References: <50576368.3070007@jhuapl.edu>
	<1347953926.25803.89.camel@dagon.hellion.org.uk>
	<5058B07C.1070404@jhuapl.edu>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] Upgrade vtpmd to berlios version 0.7.4
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

I just realised while looking at your reposting of this that I never
replied here, sorry.

On Tue, 2012-09-18 at 18:33 +0100, Matthew Fioravante wrote:


> > Perhaps we should consider making this stuff an external dependency
> > rather than importing it into our code base? This could be done either
> > as a simple dependency (i.e. require vtpm to be installed before
> > building) or as a repo cloned during build (like how we handle qemu and
> > seabios etc).
> > 
> This might be workable. The vtpm system has 2 mini-so stubdoms and 3
> mini-os tpm drivers. Does mini-os/stubdom have a nice way of building
> stuff out of tree? It doesn't appear so at the moment.

No I don't think it does :-(

>  The whole stubdom setup is basically one large monolithic makefile.
> vtpm domains also require building openssl, polarssl, and libgmp in
> the stubdom cross root.
> 
> Should the tpm drivers should be included in mini-os for potential use
> by other projects or also kept in their own separate tree? They are
> GPL drivers so maybe out of tree makes more sense.
> 
> vtpmd and vtpm_managerdom (deprecated, the old way of running vtpms as
> processes in dom0, instead of separate domains) could easily be moved
> out of tree. They are just binaries installed on the system.

Right, this was the main bit I was thinking of.

I think what I didn't appreciate is that the stub domains also build
this vtm stuff as well as the drivers, is that right? If we need the
source for stubdoms we might as well have it for vtpmd

Architectural question: Am I right that vtpmd is a host wide daemon for
mediating access to the real TPM while vtpm_managerdom (or one of the
stubdom types?) are responsible for the tpm emulation for a single
domain -- they communicate with vtpmd to get stuff done?

Is there also a stubdom which can take on the vtpmd role?

Removing vtpm_managerdom sounds like a win to me, assuming it is
acceptable to require the use of stubdoms for vtpm functionality. Is it?

> vtpm support for xm/xl probably has to stay in xen. Unless someone
> plans on making a plugin architecture for xl. There are also the
> hotplug scripts, but those go away with xl.
> 
> > > The first patch I'd like to submit upgrades vtpmd to version 0.7.4
> > > 
> > > This patch does the following:
> > > -add checks to configure to check for cmake (required by berlios 0.7.4)
> > Is the model with cmake that it is required on all the end systems
> > building the project (like make), or is it only needed on the project
> > maintainer's system (like autoconf/make)?
> Its the equivalent of running a configure script, so its needed on end
> systems.

That's a shame, but unavoidable I suppose.. 

>  Also you have to download and patch the tpm emulator before running
> cmake, so if we did want to avoid its usage on end systems we would
> have to ship the entire source code of the patched emulator.
> > 
> > > -removes all of the 0.5.1 patches
> > > -adds a single patch for 0.7.4
> > > -cleans up the makefile, should work for parallel make (avoiding
> > > version.h discussion from august 2012)
> > > -builds vtpmd to use berlios 0.7.4
> > > -Remoed the tpm_emualtor build option. berlios itself provides a kernel
> > > module if you want to use it in dom0 to emulate the physical tpm.
> > Is there going to be an associated documentation update/refresh?
> Right now I don't have a formal doc but I want to write one. I'm
> looking into getting some time to do 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 Tue Sep 25 09:54:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 09:54:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGRq0-0002YS-OV; Tue, 25 Sep 2012 09:53: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 1TGRpz-0002YN-KV
	for xen-devel@lists.xensource.com; Tue, 25 Sep 2012 09:53:55 +0000
Received: from [85.158.143.99:26399] by server-2.bemta-4.messagelabs.com id
	EC/D3-06610-33F71605; Tue, 25 Sep 2012 09:53:55 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1348566834!25550648!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTEwNzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21425 invoked from network); 25 Sep 2012 09:53:54 -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;
	25 Sep 2012 09:53:54 -0000
X-IronPort-AV: E=Sophos;i="4.80,481,1344211200"; d="scan'208";a="14744460"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Sep 2012 09:53: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.279.1;
	Tue, 25 Sep 2012 10:53:44 +0100
Message-ID: <1348566822.3452.151.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
Date: Tue, 25 Sep 2012 10:53:42 +0100
In-Reply-To: <5058B07C.1070404@jhuapl.edu>
References: <50576368.3070007@jhuapl.edu>
	<1347953926.25803.89.camel@dagon.hellion.org.uk>
	<5058B07C.1070404@jhuapl.edu>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] Upgrade vtpmd to berlios version 0.7.4
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

I just realised while looking at your reposting of this that I never
replied here, sorry.

On Tue, 2012-09-18 at 18:33 +0100, Matthew Fioravante wrote:


> > Perhaps we should consider making this stuff an external dependency
> > rather than importing it into our code base? This could be done either
> > as a simple dependency (i.e. require vtpm to be installed before
> > building) or as a repo cloned during build (like how we handle qemu and
> > seabios etc).
> > 
> This might be workable. The vtpm system has 2 mini-so stubdoms and 3
> mini-os tpm drivers. Does mini-os/stubdom have a nice way of building
> stuff out of tree? It doesn't appear so at the moment.

No I don't think it does :-(

>  The whole stubdom setup is basically one large monolithic makefile.
> vtpm domains also require building openssl, polarssl, and libgmp in
> the stubdom cross root.
> 
> Should the tpm drivers should be included in mini-os for potential use
> by other projects or also kept in their own separate tree? They are
> GPL drivers so maybe out of tree makes more sense.
> 
> vtpmd and vtpm_managerdom (deprecated, the old way of running vtpms as
> processes in dom0, instead of separate domains) could easily be moved
> out of tree. They are just binaries installed on the system.

Right, this was the main bit I was thinking of.

I think what I didn't appreciate is that the stub domains also build
this vtm stuff as well as the drivers, is that right? If we need the
source for stubdoms we might as well have it for vtpmd

Architectural question: Am I right that vtpmd is a host wide daemon for
mediating access to the real TPM while vtpm_managerdom (or one of the
stubdom types?) are responsible for the tpm emulation for a single
domain -- they communicate with vtpmd to get stuff done?

Is there also a stubdom which can take on the vtpmd role?

Removing vtpm_managerdom sounds like a win to me, assuming it is
acceptable to require the use of stubdoms for vtpm functionality. Is it?

> vtpm support for xm/xl probably has to stay in xen. Unless someone
> plans on making a plugin architecture for xl. There are also the
> hotplug scripts, but those go away with xl.
> 
> > > The first patch I'd like to submit upgrades vtpmd to version 0.7.4
> > > 
> > > This patch does the following:
> > > -add checks to configure to check for cmake (required by berlios 0.7.4)
> > Is the model with cmake that it is required on all the end systems
> > building the project (like make), or is it only needed on the project
> > maintainer's system (like autoconf/make)?
> Its the equivalent of running a configure script, so its needed on end
> systems.

That's a shame, but unavoidable I suppose.. 

>  Also you have to download and patch the tpm emulator before running
> cmake, so if we did want to avoid its usage on end systems we would
> have to ship the entire source code of the patched emulator.
> > 
> > > -removes all of the 0.5.1 patches
> > > -adds a single patch for 0.7.4
> > > -cleans up the makefile, should work for parallel make (avoiding
> > > version.h discussion from august 2012)
> > > -builds vtpmd to use berlios 0.7.4
> > > -Remoed the tpm_emualtor build option. berlios itself provides a kernel
> > > module if you want to use it in dom0 to emulate the physical tpm.
> > Is there going to be an associated documentation update/refresh?
> Right now I don't have a formal doc but I want to write one. I'm
> looking into getting some time to do 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 Tue Sep 25 10:04:29 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 10: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 1TGRzv-0002uZ-Jc; Tue, 25 Sep 2012 10:04: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 1TGRzt-0002u8-RR
	for Xen-devel@lists.xensource.com; Tue, 25 Sep 2012 10:04:10 +0000
Received: from [85.158.143.35:13440] by server-2.bemta-4.messagelabs.com id
	6C/79-06610-99181605; Tue, 25 Sep 2012 10:04:09 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1348567446!13650659!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTEwNzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25938 invoked from network); 25 Sep 2012 10:04:07 -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;
	25 Sep 2012 10:04:07 -0000
X-IronPort-AV: E=Sophos;i="4.80,481,1344211200"; d="scan'208";a="14744858"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Sep 2012 10:04:06 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Tue, 25 Sep 2012 11:04:06 +0100
Date: Tue, 25 Sep 2012 11:03:13 +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: <20120924154335.097d3fb9@mantra.us.oracle.com>
Message-ID: <alpine.DEB.2.02.1209251054140.29232@kaball.uk.xensource.com>
References: <20120921121659.5a723de9@mantra.us.oracle.com>
	<alpine.DEB.2.02.1209241257440.29232@kaball.uk.xensource.com>
	<20120924154335.097d3fb9@mantra.us.oracle.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: Ian Campbell <Ian.Campbell@citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v1 3/8]: PVH startup changes (enlighten.c)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 24 Sep 2012, Mukesh Rathor wrote:
> On Mon, 24 Sep 2012 13:07:19 +0100
> Stefano Stabellini <stefano.stabellini@eu.citrix.com> wrote:
> 
> > On Fri, 21 Sep 2012, Mukesh Rathor wrote:
> > > ---
> > >  arch/x86/xen/enlighten.c |   99
> > > ++++++++++++++++++++++++++++++++++++--------- 1 files changed, 79
> > > insertions(+), 20 deletions(-)
> > > 
> > > +			"with PVH extensions " : "", pv_info.name);
> > >  	printk(KERN_INFO "Xen version: %d.%d%s%s\n",
> > >  	       version >> 16, version & 0xffff, extra.extraversion,
> > >  	       xen_feature(XENFEAT_mmu_pt_update_preserve_ad) ?
> > > " (preserve-AD)" : ""); @@ -271,12 +278,15 @@ static void
> > > xen_cpuid(unsigned int *ax, unsigned int *bx, break;
> > >  	}
> > >  
> > > -	asm(XEN_EMULATE_PREFIX "cpuid"
> > > -		: "=a" (*ax),
> > > -		  "=b" (*bx),
> > > -		  "=c" (*cx),
> > > -		  "=d" (*dx)
> > > -		: "0" (*ax), "2" (*cx));
> > > +	if (xen_pvh_domain())
> > > +		native_cpuid(ax, bx, cx, dx);
> > > +	else
> > > +		asm(XEN_EMULATE_PREFIX "cpuid"
> > > +			: "=a" (*ax),
> > > +			"=b" (*bx),
> > > +			"=c" (*cx),
> > > +			"=d" (*dx)
> > > +			: "0" (*ax), "2" (*cx));
> > 
> > can't we just set the cpuid pvop to native_cpuid?
> 
> We had talked about this a bit at code review. There is some massaging
> before and after that goes on, and so we thought we should just leave 
> it like that.

Ah I see, are you talking about all the masks, correct?

 
> > > +	if (xen_pvh_domain() && xen_initial_domain())
> > > +		return;
> > > +
> > >  	if (!xen_feature(XENFEAT_auto_translated_physmap)) {
> > >  		set_fixmap(FIX_PARAVIRT_BOOTMAP,
> > >  			   xen_start_info->shared_info);
> > >
> > > @@ -1044,6 +1058,10 @@ void xen_setup_shared_info(void)
> > >  		HYPERVISOR_shared_info =
> > >  			(struct shared_info
> > > *)__va(xen_start_info->shared_info); 
> > > +	/* PVH TBD/FIXME: vcpu info placement in phase 2 */
> > > +	if (xen_pvh_domain())
> > > +		return;
> > 
> > It seems that if xen_initial_domain we always skip the initialization
> > while if !xen_initial_domain we only initialize
> > HYPERVISOR_shared_info. I don't understand why we have this
> > difference.
> 
> The comment in xen_pvh_guest_init() explains it. For domU the library
> maps the pfn at shared_info, ie, shared_info is pfn. For dom0, it's the
> mfn. Dom0 then allocates a pfn via extend_brk, and maps the mfn to it. This
> happens in the commond hvm code, xen_hvm_init_shared_info().

This difference is really subtle, it would be nice to get rid of it.
Could Xen allocate a pfn for dom0?
Otherwise could we have the tools allocate an mfn instead of a pfn?
In fact looking at xc_dom_x86.c, alloc_magic_pages is explicitly having
a different behavior for xc_dom_feature_translated guests and allocates
pfn instead of an mfn. Maybe we could get rid of that special case: less
code in libxc, a common way of allocating the shared_info page for domU
and dom0 => win.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 25 10:04:29 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 10: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 1TGRzv-0002uZ-Jc; Tue, 25 Sep 2012 10:04: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 1TGRzt-0002u8-RR
	for Xen-devel@lists.xensource.com; Tue, 25 Sep 2012 10:04:10 +0000
Received: from [85.158.143.35:13440] by server-2.bemta-4.messagelabs.com id
	6C/79-06610-99181605; Tue, 25 Sep 2012 10:04:09 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1348567446!13650659!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTEwNzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25938 invoked from network); 25 Sep 2012 10:04:07 -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;
	25 Sep 2012 10:04:07 -0000
X-IronPort-AV: E=Sophos;i="4.80,481,1344211200"; d="scan'208";a="14744858"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Sep 2012 10:04:06 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Tue, 25 Sep 2012 11:04:06 +0100
Date: Tue, 25 Sep 2012 11:03:13 +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: <20120924154335.097d3fb9@mantra.us.oracle.com>
Message-ID: <alpine.DEB.2.02.1209251054140.29232@kaball.uk.xensource.com>
References: <20120921121659.5a723de9@mantra.us.oracle.com>
	<alpine.DEB.2.02.1209241257440.29232@kaball.uk.xensource.com>
	<20120924154335.097d3fb9@mantra.us.oracle.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: Ian Campbell <Ian.Campbell@citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v1 3/8]: PVH startup changes (enlighten.c)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 24 Sep 2012, Mukesh Rathor wrote:
> On Mon, 24 Sep 2012 13:07:19 +0100
> Stefano Stabellini <stefano.stabellini@eu.citrix.com> wrote:
> 
> > On Fri, 21 Sep 2012, Mukesh Rathor wrote:
> > > ---
> > >  arch/x86/xen/enlighten.c |   99
> > > ++++++++++++++++++++++++++++++++++++--------- 1 files changed, 79
> > > insertions(+), 20 deletions(-)
> > > 
> > > +			"with PVH extensions " : "", pv_info.name);
> > >  	printk(KERN_INFO "Xen version: %d.%d%s%s\n",
> > >  	       version >> 16, version & 0xffff, extra.extraversion,
> > >  	       xen_feature(XENFEAT_mmu_pt_update_preserve_ad) ?
> > > " (preserve-AD)" : ""); @@ -271,12 +278,15 @@ static void
> > > xen_cpuid(unsigned int *ax, unsigned int *bx, break;
> > >  	}
> > >  
> > > -	asm(XEN_EMULATE_PREFIX "cpuid"
> > > -		: "=a" (*ax),
> > > -		  "=b" (*bx),
> > > -		  "=c" (*cx),
> > > -		  "=d" (*dx)
> > > -		: "0" (*ax), "2" (*cx));
> > > +	if (xen_pvh_domain())
> > > +		native_cpuid(ax, bx, cx, dx);
> > > +	else
> > > +		asm(XEN_EMULATE_PREFIX "cpuid"
> > > +			: "=a" (*ax),
> > > +			"=b" (*bx),
> > > +			"=c" (*cx),
> > > +			"=d" (*dx)
> > > +			: "0" (*ax), "2" (*cx));
> > 
> > can't we just set the cpuid pvop to native_cpuid?
> 
> We had talked about this a bit at code review. There is some massaging
> before and after that goes on, and so we thought we should just leave 
> it like that.

Ah I see, are you talking about all the masks, correct?

 
> > > +	if (xen_pvh_domain() && xen_initial_domain())
> > > +		return;
> > > +
> > >  	if (!xen_feature(XENFEAT_auto_translated_physmap)) {
> > >  		set_fixmap(FIX_PARAVIRT_BOOTMAP,
> > >  			   xen_start_info->shared_info);
> > >
> > > @@ -1044,6 +1058,10 @@ void xen_setup_shared_info(void)
> > >  		HYPERVISOR_shared_info =
> > >  			(struct shared_info
> > > *)__va(xen_start_info->shared_info); 
> > > +	/* PVH TBD/FIXME: vcpu info placement in phase 2 */
> > > +	if (xen_pvh_domain())
> > > +		return;
> > 
> > It seems that if xen_initial_domain we always skip the initialization
> > while if !xen_initial_domain we only initialize
> > HYPERVISOR_shared_info. I don't understand why we have this
> > difference.
> 
> The comment in xen_pvh_guest_init() explains it. For domU the library
> maps the pfn at shared_info, ie, shared_info is pfn. For dom0, it's the
> mfn. Dom0 then allocates a pfn via extend_brk, and maps the mfn to it. This
> happens in the commond hvm code, xen_hvm_init_shared_info().

This difference is really subtle, it would be nice to get rid of it.
Could Xen allocate a pfn for dom0?
Otherwise could we have the tools allocate an mfn instead of a pfn?
In fact looking at xc_dom_x86.c, alloc_magic_pages is explicitly having
a different behavior for xc_dom_feature_translated guests and allocates
pfn instead of an mfn. Maybe we could get rid of that special case: less
code in libxc, a common way of allocating the shared_info page for domU
and dom0 => win.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 25 10:06:58 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 10: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 1TGS2M-00031z-4g; Tue, 25 Sep 2012 10:06: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 1TGS2K-00031s-SG
	for xen-devel@lists.xen.org; Tue, 25 Sep 2012 10:06:40 +0000
Received: from [85.158.143.99:7496] by server-3.bemta-4.messagelabs.com id
	AC/E1-10986-03281605; Tue, 25 Sep 2012 10:06:40 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1348567599!24153439!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTEwNzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27771 invoked from network); 25 Sep 2012 10:06:39 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Sep 2012 10:06:39 -0000
X-IronPort-AV: E=Sophos;i="4.80,481,1344211200"; d="scan'208";a="14744956"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Sep 2012 10:06: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.279.1; Tue, 25 Sep 2012 11:06: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
	1TGS2J-0004pT-Ac; Tue, 25 Sep 2012 10:06:39 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1TGS2J-0006Is-0r;
	Tue, 25 Sep 2012 11:06:39 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20577.33326.654049.560825@mariner.uk.xensource.com>
Date: Tue, 25 Sep 2012 11:06:38 +0100
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1348566052.3452.145.camel@zakaz.uk.xensource.com>
References: <ba1c6e807c8b1684a83e.1347871431@cosworth.uk.xensource.com>
	<1348566052.3452.145.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>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] tools: bump SONAMEs for changes during 4.2
 development cycle
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("Re: [Xen-devel] [PATCH] tools: bump SONAMEs for changes during 4.2 development cycle"):
> Ping?
> 
> On Mon, 2012-09-17 at 09:43 +0100, Ian Campbell wrote:
> > tools: bump SONAMEs for changes during 4.2 development cycle.

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

Also 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 Sep 25 10:06:58 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 10: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 1TGS2M-00031z-4g; Tue, 25 Sep 2012 10:06: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 1TGS2K-00031s-SG
	for xen-devel@lists.xen.org; Tue, 25 Sep 2012 10:06:40 +0000
Received: from [85.158.143.99:7496] by server-3.bemta-4.messagelabs.com id
	AC/E1-10986-03281605; Tue, 25 Sep 2012 10:06:40 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1348567599!24153439!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTEwNzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27771 invoked from network); 25 Sep 2012 10:06:39 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Sep 2012 10:06:39 -0000
X-IronPort-AV: E=Sophos;i="4.80,481,1344211200"; d="scan'208";a="14744956"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Sep 2012 10:06: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.279.1; Tue, 25 Sep 2012 11:06: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
	1TGS2J-0004pT-Ac; Tue, 25 Sep 2012 10:06:39 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1TGS2J-0006Is-0r;
	Tue, 25 Sep 2012 11:06:39 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20577.33326.654049.560825@mariner.uk.xensource.com>
Date: Tue, 25 Sep 2012 11:06:38 +0100
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1348566052.3452.145.camel@zakaz.uk.xensource.com>
References: <ba1c6e807c8b1684a83e.1347871431@cosworth.uk.xensource.com>
	<1348566052.3452.145.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>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] tools: bump SONAMEs for changes during 4.2
 development cycle
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("Re: [Xen-devel] [PATCH] tools: bump SONAMEs for changes during 4.2 development cycle"):
> Ping?
> 
> On Mon, 2012-09-17 at 09:43 +0100, Ian Campbell wrote:
> > tools: bump SONAMEs for changes during 4.2 development cycle.

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

Also 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 Sep 25 10:09:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 10:09:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGS4Z-00039Q-M8; Tue, 25 Sep 2012 10:08: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 1TGS4Y-00039L-9l
	for xen-devel@lists.xensource.com; Tue, 25 Sep 2012 10:08:58 +0000
Received: from [85.158.138.51:6836] by server-16.bemta-3.messagelabs.com id
	4C/B2-31776-9B281605; Tue, 25 Sep 2012 10:08:57 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1348567736!31959315!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTEwNzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22675 invoked from network); 25 Sep 2012 10:08: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;
	25 Sep 2012 10:08:57 -0000
X-IronPort-AV: E=Sophos;i="4.80,481,1344211200"; d="scan'208";a="14745037"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Sep 2012 10:08: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.279.1;
	Tue, 25 Sep 2012 11:08:56 +0100
Message-ID: <1348567735.3452.156.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
Date: Tue, 25 Sep 2012 11:08:55 +0100
In-Reply-To: <505CB793.1010405@jhuapl.edu>
References: <505CB793.1010405@jhuapl.edu>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] PATCH [base vtpm and libxl patches 1/6] Upgrade
 vtpmd from 0.5.1 to 0.7.4
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-09-21 at 19:53 +0100, Matthew Fioravante wrote:
> Update vtpmd from 0.5.1 to 0.7.4. Also adds checks for cmake
> and gmp to the configure script if vtpm is enabled.

This patch looks whitespace damaged again I'm afraid.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 25 10:09:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 10:09:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGS4Z-00039Q-M8; Tue, 25 Sep 2012 10:08: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 1TGS4Y-00039L-9l
	for xen-devel@lists.xensource.com; Tue, 25 Sep 2012 10:08:58 +0000
Received: from [85.158.138.51:6836] by server-16.bemta-3.messagelabs.com id
	4C/B2-31776-9B281605; Tue, 25 Sep 2012 10:08:57 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1348567736!31959315!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTEwNzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22675 invoked from network); 25 Sep 2012 10:08: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;
	25 Sep 2012 10:08:57 -0000
X-IronPort-AV: E=Sophos;i="4.80,481,1344211200"; d="scan'208";a="14745037"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Sep 2012 10:08: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.279.1;
	Tue, 25 Sep 2012 11:08:56 +0100
Message-ID: <1348567735.3452.156.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
Date: Tue, 25 Sep 2012 11:08:55 +0100
In-Reply-To: <505CB793.1010405@jhuapl.edu>
References: <505CB793.1010405@jhuapl.edu>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] PATCH [base vtpm and libxl patches 1/6] Upgrade
 vtpmd from 0.5.1 to 0.7.4
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-09-21 at 19:53 +0100, Matthew Fioravante wrote:
> Update vtpmd from 0.5.1 to 0.7.4. Also adds checks for cmake
> and gmp to the configure script if vtpm is enabled.

This patch looks whitespace damaged again I'm afraid.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 25 10:09:17 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 10: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 1TGS4h-0003AP-F2; Tue, 25 Sep 2012 10:09: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 1TGS4f-0003A7-Rx
	for xen-devel@lists.xen.org; Tue, 25 Sep 2012 10:09:06 +0000
Received: from [85.158.143.35:41660] by server-2.bemta-4.messagelabs.com id
	FC/A2-06610-1C281605; Tue, 25 Sep 2012 10:09:05 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1348567741!5313744!2
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTEwNzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9605 invoked from network); 25 Sep 2012 10:09:04 -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;
	25 Sep 2012 10:09:04 -0000
X-IronPort-AV: E=Sophos;i="4.80,481,1344211200"; d="scan'208";a="14745043"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Sep 2012 10:09: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.279.1;
	Tue, 25 Sep 2012 11:09:04 +0100
Message-ID: <1348567743.3452.158.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Olaf Hering <olaf@aepfle.de>
Date: Tue, 25 Sep 2012 11:09:03 +0100
In-Reply-To: <8a2eef481d3ab3ca5692.1346945346@probook.site>
References: <8a2eef481d3ab3ca5692.1346945346@probook.site>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] pygrub: always append --args
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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-09-06 at 16:29 +0100, Olaf Hering wrote:
> # HG changeset patch
> # User Olaf Hering <olaf@aepfle.de>
> # Date 1346945306 -7200
> # Node ID 8a2eef481d3ab3ca5692dd0083c95cf314fe1da3
> # Parent  19d367bf07b7687b831c212a57a70e73ea14d3b7
> pygrub: always append --args
> 
> If a bootloader entry in menu.lst has no additional kernel command line
> options listed and the domU.cfg has 'bootargs="--args=something"' the
> additional arguments from the config file are not passed to the kernel.
> The reason for that incorrect behaviour is that run_grub appends arg
> only if the parsed config file has arguments listed.
> 
> Fix this by appending args from image section and the config file separatly.
> To avoid adding to a NoneType initialize grubcfg['args'] to an empty string.
> This does not change behaviour but simplifies the code which appends the
> string.
> 
> Signed-off-by: Olaf Hering <olaf@aepfle.de>
> 
> diff -r 19d367bf07b7 -r 8a2eef481d3a tools/pygrub/src/pygrub
> --- a/tools/pygrub/src/pygrub
> +++ b/tools/pygrub/src/pygrub
> @@ -615,13 +615,15 @@ def run_grub(file, entry, fs, arg):
>      except IndexError:
>          img = g.cf.images[0]
>  
> -    grubcfg = { "kernel": None, "ramdisk": None, "args": None }
> +    grubcfg = { "kernel": None, "ramdisk": None, "args": "" }
>  
>      grubcfg["kernel"] = img.kernel[1]
>      if img.initrd:
>          grubcfg["ramdisk"] = img.initrd[1]
>      if img.args:
> -        grubcfg["args"] = img.args + " " + arg
> +        grubcfg["args"] += img.args
> +    if arg:
> +        grubcfg["args"] += " " + args

I don't imagine any kernel would care about the potential leading space
here so:

Acked-by: Ian Campbell <ian.campbell@citrix.com>

and applied, thanks.

>  
>      return grubcfg
>  
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Sep 25 10:09:17 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 10: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 1TGS4h-0003AP-F2; Tue, 25 Sep 2012 10:09: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 1TGS4f-0003A7-Rx
	for xen-devel@lists.xen.org; Tue, 25 Sep 2012 10:09:06 +0000
Received: from [85.158.143.35:41660] by server-2.bemta-4.messagelabs.com id
	FC/A2-06610-1C281605; Tue, 25 Sep 2012 10:09:05 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1348567741!5313744!2
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTEwNzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9605 invoked from network); 25 Sep 2012 10:09:04 -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;
	25 Sep 2012 10:09:04 -0000
X-IronPort-AV: E=Sophos;i="4.80,481,1344211200"; d="scan'208";a="14745043"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Sep 2012 10:09: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.279.1;
	Tue, 25 Sep 2012 11:09:04 +0100
Message-ID: <1348567743.3452.158.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Olaf Hering <olaf@aepfle.de>
Date: Tue, 25 Sep 2012 11:09:03 +0100
In-Reply-To: <8a2eef481d3ab3ca5692.1346945346@probook.site>
References: <8a2eef481d3ab3ca5692.1346945346@probook.site>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] pygrub: always append --args
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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-09-06 at 16:29 +0100, Olaf Hering wrote:
> # HG changeset patch
> # User Olaf Hering <olaf@aepfle.de>
> # Date 1346945306 -7200
> # Node ID 8a2eef481d3ab3ca5692dd0083c95cf314fe1da3
> # Parent  19d367bf07b7687b831c212a57a70e73ea14d3b7
> pygrub: always append --args
> 
> If a bootloader entry in menu.lst has no additional kernel command line
> options listed and the domU.cfg has 'bootargs="--args=something"' the
> additional arguments from the config file are not passed to the kernel.
> The reason for that incorrect behaviour is that run_grub appends arg
> only if the parsed config file has arguments listed.
> 
> Fix this by appending args from image section and the config file separatly.
> To avoid adding to a NoneType initialize grubcfg['args'] to an empty string.
> This does not change behaviour but simplifies the code which appends the
> string.
> 
> Signed-off-by: Olaf Hering <olaf@aepfle.de>
> 
> diff -r 19d367bf07b7 -r 8a2eef481d3a tools/pygrub/src/pygrub
> --- a/tools/pygrub/src/pygrub
> +++ b/tools/pygrub/src/pygrub
> @@ -615,13 +615,15 @@ def run_grub(file, entry, fs, arg):
>      except IndexError:
>          img = g.cf.images[0]
>  
> -    grubcfg = { "kernel": None, "ramdisk": None, "args": None }
> +    grubcfg = { "kernel": None, "ramdisk": None, "args": "" }
>  
>      grubcfg["kernel"] = img.kernel[1]
>      if img.initrd:
>          grubcfg["ramdisk"] = img.initrd[1]
>      if img.args:
> -        grubcfg["args"] = img.args + " " + arg
> +        grubcfg["args"] += img.args
> +    if arg:
> +        grubcfg["args"] += " " + args

I don't imagine any kernel would care about the potential leading space
here so:

Acked-by: Ian Campbell <ian.campbell@citrix.com>

and applied, thanks.

>  
>      return grubcfg
>  
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Sep 25 10:09:18 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 10:09:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGS4f-00039z-2B; Tue, 25 Sep 2012 10:09: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 1TGS4d-00039i-8j
	for xen-devel@lists.xen.org; Tue, 25 Sep 2012 10:09:03 +0000
Received: from [85.158.143.35:41514] by server-1.bemta-4.messagelabs.com id
	84/96-05684-EB281605; Tue, 25 Sep 2012 10:09:02 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1348567741!5313744!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTEwNzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9355 invoked from network); 25 Sep 2012 10:09:01 -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;
	25 Sep 2012 10:09:01 -0000
X-IronPort-AV: E=Sophos;i="4.80,481,1344211200"; d="scan'208";a="14745040"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Sep 2012 10:09: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.279.1;
	Tue, 25 Sep 2012 11:09:01 +0100
Message-ID: <1348567739.3452.157.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Bastian Blank <waldi@debian.org>
Date: Tue, 25 Sep 2012 11:08:59 +0100
In-Reply-To: <20120916153649.GC22987@wavehammer.waldi.eu.org>
References: <20120916145830.GB22987@wavehammer.waldi.eu.org>
	<20120916153649.GC22987@wavehammer.waldi.eu.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Saving domain in xl does not have proper cleanup
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Sun, 2012-09-16 at 16:36 +0100, Bastian Blank wrote:
> On Sun, Sep 16, 2012 at 04:58:30PM +0200, Bastian Blank wrote:
> > Saving a domain without enough available space with xl in 4.2-rc5 fails
> > to cleanup completely. The domain informations remains in Xenstore,
> > the domain itself seems to remain in a suspended state and there is not
> > xl process for it anymore.
> 
> This patch fixes this bug. It resumes the domain in case of errors in
> the save process.

Thanks, I wrote the following commit message for you and committed.
Please supply one yourself in the future.

    xl: resume the domain on suspend failure
    
    The MUST macro calls exit(3) on failure but we need to cleanup and
    resume.
    
    Signed-off-by: Bastian Blank <waldi@debian.org>
    Acked-by: Ian Campbell <ian.campbell@citrix.com>


> 
> Bastian
> 
> Signed-off-by: Bastian Blank <waldi@debian.org>
> 
> diff -r 4027d31caeb0 tools/libxl/xl_cmdimpl.c
> --- a/tools/libxl/xl_cmdimpl.c	Thu Sep 13 12:21:09 2012 +0100
> +++ b/tools/libxl/xl_cmdimpl.c	Sun Sep 16 17:33:25 2012 +0200
> @@ -2990,15 +2990,18 @@
>  
>      save_domain_core_writeconfig(fd, filename, config_data, config_len);
>  
> -    MUST(libxl_domain_suspend(ctx, domid, fd, 0, NULL));
> +    int rc = libxl_domain_suspend(ctx, domid, fd, 0, NULL);
>      close(fd);
>  
> -    if (checkpoint)
> +    if (rc < 0)
> +        fprintf(stderr, "Failed to save domain, resuming domain\n");
> +
> +    if (checkpoint || rc < 0)
>          libxl_domain_resume(ctx, domid, 1, 0);
>      else
>          libxl_domain_destroy(ctx, domid, 0);
>  
> -    exit(0);
> +    exit(rc < 0 ? 1 : 0);
>  }
>  
>  static pid_t create_migration_child(const char *rune, int *send_fd,



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 25 10:09:18 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 10:09:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGS4f-00039z-2B; Tue, 25 Sep 2012 10:09: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 1TGS4d-00039i-8j
	for xen-devel@lists.xen.org; Tue, 25 Sep 2012 10:09:03 +0000
Received: from [85.158.143.35:41514] by server-1.bemta-4.messagelabs.com id
	84/96-05684-EB281605; Tue, 25 Sep 2012 10:09:02 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1348567741!5313744!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTEwNzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9355 invoked from network); 25 Sep 2012 10:09:01 -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;
	25 Sep 2012 10:09:01 -0000
X-IronPort-AV: E=Sophos;i="4.80,481,1344211200"; d="scan'208";a="14745040"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Sep 2012 10:09: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.279.1;
	Tue, 25 Sep 2012 11:09:01 +0100
Message-ID: <1348567739.3452.157.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Bastian Blank <waldi@debian.org>
Date: Tue, 25 Sep 2012 11:08:59 +0100
In-Reply-To: <20120916153649.GC22987@wavehammer.waldi.eu.org>
References: <20120916145830.GB22987@wavehammer.waldi.eu.org>
	<20120916153649.GC22987@wavehammer.waldi.eu.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Saving domain in xl does not have proper cleanup
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Sun, 2012-09-16 at 16:36 +0100, Bastian Blank wrote:
> On Sun, Sep 16, 2012 at 04:58:30PM +0200, Bastian Blank wrote:
> > Saving a domain without enough available space with xl in 4.2-rc5 fails
> > to cleanup completely. The domain informations remains in Xenstore,
> > the domain itself seems to remain in a suspended state and there is not
> > xl process for it anymore.
> 
> This patch fixes this bug. It resumes the domain in case of errors in
> the save process.

Thanks, I wrote the following commit message for you and committed.
Please supply one yourself in the future.

    xl: resume the domain on suspend failure
    
    The MUST macro calls exit(3) on failure but we need to cleanup and
    resume.
    
    Signed-off-by: Bastian Blank <waldi@debian.org>
    Acked-by: Ian Campbell <ian.campbell@citrix.com>


> 
> Bastian
> 
> Signed-off-by: Bastian Blank <waldi@debian.org>
> 
> diff -r 4027d31caeb0 tools/libxl/xl_cmdimpl.c
> --- a/tools/libxl/xl_cmdimpl.c	Thu Sep 13 12:21:09 2012 +0100
> +++ b/tools/libxl/xl_cmdimpl.c	Sun Sep 16 17:33:25 2012 +0200
> @@ -2990,15 +2990,18 @@
>  
>      save_domain_core_writeconfig(fd, filename, config_data, config_len);
>  
> -    MUST(libxl_domain_suspend(ctx, domid, fd, 0, NULL));
> +    int rc = libxl_domain_suspend(ctx, domid, fd, 0, NULL);
>      close(fd);
>  
> -    if (checkpoint)
> +    if (rc < 0)
> +        fprintf(stderr, "Failed to save domain, resuming domain\n");
> +
> +    if (checkpoint || rc < 0)
>          libxl_domain_resume(ctx, domid, 1, 0);
>      else
>          libxl_domain_destroy(ctx, domid, 0);
>  
> -    exit(0);
> +    exit(rc < 0 ? 1 : 0);
>  }
>  
>  static pid_t create_migration_child(const char *rune, int *send_fd,



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 25 10:16:39 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 10:16:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGSBn-0003d1-E8; Tue, 25 Sep 2012 10:16: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 1TGSBm-0003cv-Tj
	for xen-devel@lists.xensource.com; Tue, 25 Sep 2012 10:16:27 +0000
Received: from [85.158.137.99:5508] by server-10.bemta-3.messagelabs.com id
	97/9F-10411-A7481605; Tue, 25 Sep 2012 10:16:26 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-3.tower-217.messagelabs.com!1348568185!13962095!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTEwNzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27562 invoked from network); 25 Sep 2012 10:16:25 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Sep 2012 10:16:25 -0000
X-IronPort-AV: E=Sophos;i="4.80,481,1344211200"; d="scan'208";a="14745284"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Sep 2012 10:16: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.279.1; Tue, 25 Sep 2012 11:16:25 +0100
Date: Tue, 25 Sep 2012 11:15:42 +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: <1345642066.12501.6.camel@zakaz.uk.xensource.com>
Message-ID: <alpine.DEB.2.02.1208221458020.15568@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1208141559360.21096@kaball.uk.xensource.com>
	<alpine.DEB.2.02.1208221213070.15568@kaball.uk.xensource.com>
	<1345642066.12501.6.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>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] libxl/qemu-xen: use cache=writeback for IDE
 and cache=none for SCSI
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 this email in my draft mailbox, I must have forgotten to send it.

On Wed, 22 Aug 2012, Ian Campbell wrote:
> On Wed, 2012-08-22 at 12:13 +0100, Stefano Stabellini wrote:
> > On Tue, 14 Aug 2012, Stefano Stabellini wrote:
> > > Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> > 
> > ping
> 
> Is this an appropriate change during rcs, is it critical for 4.2 or
> should it wait for 4.3?

It should go in one of the 4.2.x releases.


> I think the changelog here is rather lacking, which makes it hard for me
> to decide what to do. e.g. the usual stuff: Why are you making this
> change? What is the impact? etc

This patch makes QEMU upstream behave like QEMU traditional, that
changed behavior at the same time this patch was sent
(effd5676225761abdab90becac519716515c3be4).


> What is the default for all these cases?

The default is writethrough, that is very slow.


> > > diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
> > > index 0c0084f..1c94e80 100644
> > > --- a/tools/libxl/libxl_dm.c
> > > +++ b/tools/libxl/libxl_dm.c
> > > @@ -549,10 +549,10 @@ static char ** libxl__build_device_model_args_new(libxl__gc *gc,
> > >              if (disks[i].is_cdrom) {
> > >                  if (disks[i].format == LIBXL_DISK_FORMAT_EMPTY)
> > >                      drive = libxl__sprintf
> > > -                        (gc, "if=ide,index=%d,media=cdrom", disk);
> > > +                        (gc, "if=ide,index=%d,media=cdrom,cache=writeback", disk);
> 
> Why does the cacheability matter for an empty device?

It doesn't but the default would stay the same when a cdrom is inserted
(it is a property of the drive).


> > >                  else
> > >                      drive = libxl__sprintf
> > > -                        (gc, "file=%s,if=ide,index=%d,media=cdrom,format=%s",
> > > +                        (gc, "file=%s,if=ide,index=%d,media=cdrom,format=%s,cache=writeback",
> 
> Does writeback mean anything for a r/o device?

I doesn't. Do you want me to resend without this hunk?


> > >                           disks[i].pdev_path, disk, format);
> > >              } else {
> > >                  if (disks[i].format == LIBXL_DISK_FORMAT_EMPTY) {
> > > @@ -575,11 +575,11 @@ static char ** libxl__build_device_model_args_new(libxl__gc *gc,
> > >                   */
> > >                  if (strncmp(disks[i].vdev, "sd", 2) == 0)
> > >                      drive = libxl__sprintf
> > > -                        (gc, "file=%s,if=scsi,bus=0,unit=%d,format=%s",
> > > +                        (gc, "file=%s,if=scsi,bus=0,unit=%d,format=%s,cache=none",
> > >                           disks[i].pdev_path, disk, format);
> > >                  else if (disk < 4)
> > >                      drive = libxl__sprintf
> > > -                        (gc, "file=%s,if=ide,index=%d,media=disk,format=%s",
> > > +                        (gc, "file=%s,if=ide,index=%d,media=disk,format=%s,cache=writeback",
> 
> Why is an SCSI disk treated differently to an IDE one wrt caching?
> 

We chose writeback for IDE because IDE has an explicit flush command
that the guest is going to issue when it wants the data to reach the disk.
At that point we can do a datasync on the filesystem.
I don't know enough about SCSI to be sure that is the case there as
well, so I wanted to stay on the safe side and chose cache=none instead
(that means O_DIRECT).

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 25 10:16:39 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 10:16:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGSBn-0003d1-E8; Tue, 25 Sep 2012 10:16: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 1TGSBm-0003cv-Tj
	for xen-devel@lists.xensource.com; Tue, 25 Sep 2012 10:16:27 +0000
Received: from [85.158.137.99:5508] by server-10.bemta-3.messagelabs.com id
	97/9F-10411-A7481605; Tue, 25 Sep 2012 10:16:26 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-3.tower-217.messagelabs.com!1348568185!13962095!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTEwNzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27562 invoked from network); 25 Sep 2012 10:16:25 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Sep 2012 10:16:25 -0000
X-IronPort-AV: E=Sophos;i="4.80,481,1344211200"; d="scan'208";a="14745284"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Sep 2012 10:16: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.279.1; Tue, 25 Sep 2012 11:16:25 +0100
Date: Tue, 25 Sep 2012 11:15:42 +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: <1345642066.12501.6.camel@zakaz.uk.xensource.com>
Message-ID: <alpine.DEB.2.02.1208221458020.15568@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1208141559360.21096@kaball.uk.xensource.com>
	<alpine.DEB.2.02.1208221213070.15568@kaball.uk.xensource.com>
	<1345642066.12501.6.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>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] libxl/qemu-xen: use cache=writeback for IDE
 and cache=none for SCSI
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 this email in my draft mailbox, I must have forgotten to send it.

On Wed, 22 Aug 2012, Ian Campbell wrote:
> On Wed, 2012-08-22 at 12:13 +0100, Stefano Stabellini wrote:
> > On Tue, 14 Aug 2012, Stefano Stabellini wrote:
> > > Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> > 
> > ping
> 
> Is this an appropriate change during rcs, is it critical for 4.2 or
> should it wait for 4.3?

It should go in one of the 4.2.x releases.


> I think the changelog here is rather lacking, which makes it hard for me
> to decide what to do. e.g. the usual stuff: Why are you making this
> change? What is the impact? etc

This patch makes QEMU upstream behave like QEMU traditional, that
changed behavior at the same time this patch was sent
(effd5676225761abdab90becac519716515c3be4).


> What is the default for all these cases?

The default is writethrough, that is very slow.


> > > diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
> > > index 0c0084f..1c94e80 100644
> > > --- a/tools/libxl/libxl_dm.c
> > > +++ b/tools/libxl/libxl_dm.c
> > > @@ -549,10 +549,10 @@ static char ** libxl__build_device_model_args_new(libxl__gc *gc,
> > >              if (disks[i].is_cdrom) {
> > >                  if (disks[i].format == LIBXL_DISK_FORMAT_EMPTY)
> > >                      drive = libxl__sprintf
> > > -                        (gc, "if=ide,index=%d,media=cdrom", disk);
> > > +                        (gc, "if=ide,index=%d,media=cdrom,cache=writeback", disk);
> 
> Why does the cacheability matter for an empty device?

It doesn't but the default would stay the same when a cdrom is inserted
(it is a property of the drive).


> > >                  else
> > >                      drive = libxl__sprintf
> > > -                        (gc, "file=%s,if=ide,index=%d,media=cdrom,format=%s",
> > > +                        (gc, "file=%s,if=ide,index=%d,media=cdrom,format=%s,cache=writeback",
> 
> Does writeback mean anything for a r/o device?

I doesn't. Do you want me to resend without this hunk?


> > >                           disks[i].pdev_path, disk, format);
> > >              } else {
> > >                  if (disks[i].format == LIBXL_DISK_FORMAT_EMPTY) {
> > > @@ -575,11 +575,11 @@ static char ** libxl__build_device_model_args_new(libxl__gc *gc,
> > >                   */
> > >                  if (strncmp(disks[i].vdev, "sd", 2) == 0)
> > >                      drive = libxl__sprintf
> > > -                        (gc, "file=%s,if=scsi,bus=0,unit=%d,format=%s",
> > > +                        (gc, "file=%s,if=scsi,bus=0,unit=%d,format=%s,cache=none",
> > >                           disks[i].pdev_path, disk, format);
> > >                  else if (disk < 4)
> > >                      drive = libxl__sprintf
> > > -                        (gc, "file=%s,if=ide,index=%d,media=disk,format=%s",
> > > +                        (gc, "file=%s,if=ide,index=%d,media=disk,format=%s,cache=writeback",
> 
> Why is an SCSI disk treated differently to an IDE one wrt caching?
> 

We chose writeback for IDE because IDE has an explicit flush command
that the guest is going to issue when it wants the data to reach the disk.
At that point we can do a datasync on the filesystem.
I don't know enough about SCSI to be sure that is the case there as
well, so I wanted to stay on the safe side and chose cache=none instead
(that means O_DIRECT).

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 25 10:23:00 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 10: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 1TGSHw-0003sJ-Rz; Tue, 25 Sep 2012 10:22:48 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1TGSHv-0003sC-7f
	for xen-devel@lists.xensource.com; Tue, 25 Sep 2012 10:22:47 +0000
Received: from [85.158.139.211:43141] by server-4.bemta-5.messagelabs.com id
	EF/0B-20767-6F581605; Tue, 25 Sep 2012 10:22:46 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-206.messagelabs.com!1348568564!18358421!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTEwNzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16282 invoked from network); 25 Sep 2012 10:22:45 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Sep 2012 10:22:45 -0000
X-IronPort-AV: E=Sophos;i="4.80,481,1344211200"; d="scan'208";a="14745503"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Sep 2012 10:22: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.279.1;
	Tue, 25 Sep 2012 11:22:44 +0100
Message-ID: <1348568562.3452.169.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
Date: Tue, 25 Sep 2012 11:22:42 +0100
In-Reply-To: <505CB887.4090905@jhuapl.edu>
References: <505CB887.4090905@jhuapl.edu>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] PATCH [base vtpm and libxl patches 2/6] Bug fixes
 and breakout of vtpm_manager functionality
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 afraid this patch is also whitespace damaged and can't be applied.

If you use git send-email or the hg email extension then this should
avoid this sort of corruption.

Otherwise see
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=Documentation/email-clients.txt;hb=HEAD for some hints on configuring your email client.

On Fri, 2012-09-21 at 19:57 +0100, Matthew Fioravante wrote:
> Fix numerous memory leaks, IO deadlocks, and other bugs that make
> vtpm_manager barely usable. Also breakout the vtpm_manager compilation
> into separate libraries to facilitate reusing parts of it in mini-os
> domains. Finally, add new programs for communicating with the manager
> correctly to avoid IO deadlock errors.
> 
> Signed off by Matthew Fioravante matthew.fioravante@jhuapl.edu
> 
> ---
> Changed since previous:
> * rebased off of latest xen-unstable
> 
> diff --git a/tools/vtpm_manager/Makefile b/tools/vtpm_manager/Makefile
> --- a/tools/vtpm_manager/Makefile
> +++ b/tools/vtpm_manager/Makefile

I think you could/should add yourself to the MAINTAINERS file for
tools/vtpm and vtpm_manager. If you are OK with that please send a patch
to do so.


> @@ -1,9 +1,9 @@
> -XEN_ROOT = $(CURDIR)/../..
> +XEN_ROOT = $(realpath ../..)

$(CURDIR)/../.. is idiom used almost everywhere in our build system.

What was the issue you were trying to address here?

Outside of the Makefiles and licenses I didn't really review this patch
in much detail, since I'm not really familiar with this code base. I
suspect no one other than you really is really qualified) so I think it
might as well just go on in (once the whitespace damage gets fixed). I'd
give it a little more time on list to see if anyone has any other
opinions.

One other barrier to review is that this is a single huge patch which
fixes multiple issues. In general we would prefer more fine grained
series where each patch fixes a single issue. 

> diff --git a/tools/vtpm_manager/tcs/tpmddl.c
> b/tools/vtpm_manager/tcs/tpmddl.c
> --- /dev/null
> +++ b/tools/vtpm_manager/tcs/tpmddl.c
> @@ -0,0 +1,167 @@
> +/*
> + * Copyright (c) 2010-2012 United States Government, as represented by
> + * the Secretary of Defense.  All rights reserved.

What license covers this code?

Other files in the same directory seem to use a 3 clause BSD.

Same question applies to all the other places with only this header.

> + *
> + * THIS SOFTWARE AND ITS DOCUMENTATION ARE PROVIDED AS IS AND WITHOUT
> + * ANY EXPRESS OR IMPLIED WARRANTIES WHATSOEVER. ALL WARRANTIES
> + * INCLUDING, BUT NOT LIMITED TO, PERFORMANCE, MERCHANTABILITY, FITNESS
> + * FOR A PARTICULAR  PURPOSE, AND NONINFRINGEMENT ARE HEREBY
> + * DISCLAIMED. USERS ASSUME THE ENTIRE RISK AND LIABILITY OF USING THE
> + * SOFTWARE.
> + */
[...]
> +diff --git a/tools/vtpm_manager/util/hashtable_itr.c
> b/tools/vtpm_manager/util/hashtable_itr.c
> --- a/tools/vtpm_manager/util/hashtable_itr.c
> +++ b/tools/vtpm_manager/util/hashtable_itr.c
> @@ -32,11 +32,6 @@
>   * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
>  */
>  
> -/*
> - * There are duplicates of this code in:
> - *  - tools/blktap2/drivers/hashtable_itr.c
> - */

The purpose of this message is to remind people who fix one version that
there are other copies which need fixing too. And perhaps to eventually
motivate someone into reducing the duplication.

Please leave them in place.

> -
>  #include "hashtable.h"
>  #include "hashtable_private.h"
>  #include "hashtable_itr.h"
> diff --git a/tools/vtpm_manager/util/hashtable_itr.h
> b/tools/vtpm_manager/util/hashtable_itr.h
> --- a/tools/vtpm_manager/util/hashtable_itr.h
> +++ b/tools/vtpm_manager/util/hashtable_itr.h
> @@ -32,11 +32,6 @@
>   * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
>  */
>  
> -/*
> - * There are duplicates of this code in:
> - *  - tools/blktap2/drivers/hashtable_itr.h
> - */

Please leave this....

> diff --git a/tools/vtpm_manager/util/hashtable_private.h
> b/tools/vtpm_manager/util/hashtable_private.h
> --- a/tools/vtpm_manager/util/hashtable_private.h
> +++ b/tools/vtpm_manager/util/hashtable_private.h
> @@ -32,12 +32,6 @@
>   * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
>  */
>  
> -/*
> - * There are duplicates of this code in:
> - *  - tools/xenstore/hashtable_private.h
> - *  - tools/blktap2/drivers/hashtable_private.h
> - */

... and this (and any other similar things you've removed which I didn't
notice)


Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 25 10:23:00 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 10: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 1TGSHw-0003sJ-Rz; Tue, 25 Sep 2012 10:22:48 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1TGSHv-0003sC-7f
	for xen-devel@lists.xensource.com; Tue, 25 Sep 2012 10:22:47 +0000
Received: from [85.158.139.211:43141] by server-4.bemta-5.messagelabs.com id
	EF/0B-20767-6F581605; Tue, 25 Sep 2012 10:22:46 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-206.messagelabs.com!1348568564!18358421!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTEwNzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16282 invoked from network); 25 Sep 2012 10:22:45 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Sep 2012 10:22:45 -0000
X-IronPort-AV: E=Sophos;i="4.80,481,1344211200"; d="scan'208";a="14745503"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Sep 2012 10:22: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.279.1;
	Tue, 25 Sep 2012 11:22:44 +0100
Message-ID: <1348568562.3452.169.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
Date: Tue, 25 Sep 2012 11:22:42 +0100
In-Reply-To: <505CB887.4090905@jhuapl.edu>
References: <505CB887.4090905@jhuapl.edu>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] PATCH [base vtpm and libxl patches 2/6] Bug fixes
 and breakout of vtpm_manager functionality
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 afraid this patch is also whitespace damaged and can't be applied.

If you use git send-email or the hg email extension then this should
avoid this sort of corruption.

Otherwise see
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=Documentation/email-clients.txt;hb=HEAD for some hints on configuring your email client.

On Fri, 2012-09-21 at 19:57 +0100, Matthew Fioravante wrote:
> Fix numerous memory leaks, IO deadlocks, and other bugs that make
> vtpm_manager barely usable. Also breakout the vtpm_manager compilation
> into separate libraries to facilitate reusing parts of it in mini-os
> domains. Finally, add new programs for communicating with the manager
> correctly to avoid IO deadlock errors.
> 
> Signed off by Matthew Fioravante matthew.fioravante@jhuapl.edu
> 
> ---
> Changed since previous:
> * rebased off of latest xen-unstable
> 
> diff --git a/tools/vtpm_manager/Makefile b/tools/vtpm_manager/Makefile
> --- a/tools/vtpm_manager/Makefile
> +++ b/tools/vtpm_manager/Makefile

I think you could/should add yourself to the MAINTAINERS file for
tools/vtpm and vtpm_manager. If you are OK with that please send a patch
to do so.


> @@ -1,9 +1,9 @@
> -XEN_ROOT = $(CURDIR)/../..
> +XEN_ROOT = $(realpath ../..)

$(CURDIR)/../.. is idiom used almost everywhere in our build system.

What was the issue you were trying to address here?

Outside of the Makefiles and licenses I didn't really review this patch
in much detail, since I'm not really familiar with this code base. I
suspect no one other than you really is really qualified) so I think it
might as well just go on in (once the whitespace damage gets fixed). I'd
give it a little more time on list to see if anyone has any other
opinions.

One other barrier to review is that this is a single huge patch which
fixes multiple issues. In general we would prefer more fine grained
series where each patch fixes a single issue. 

> diff --git a/tools/vtpm_manager/tcs/tpmddl.c
> b/tools/vtpm_manager/tcs/tpmddl.c
> --- /dev/null
> +++ b/tools/vtpm_manager/tcs/tpmddl.c
> @@ -0,0 +1,167 @@
> +/*
> + * Copyright (c) 2010-2012 United States Government, as represented by
> + * the Secretary of Defense.  All rights reserved.

What license covers this code?

Other files in the same directory seem to use a 3 clause BSD.

Same question applies to all the other places with only this header.

> + *
> + * THIS SOFTWARE AND ITS DOCUMENTATION ARE PROVIDED AS IS AND WITHOUT
> + * ANY EXPRESS OR IMPLIED WARRANTIES WHATSOEVER. ALL WARRANTIES
> + * INCLUDING, BUT NOT LIMITED TO, PERFORMANCE, MERCHANTABILITY, FITNESS
> + * FOR A PARTICULAR  PURPOSE, AND NONINFRINGEMENT ARE HEREBY
> + * DISCLAIMED. USERS ASSUME THE ENTIRE RISK AND LIABILITY OF USING THE
> + * SOFTWARE.
> + */
[...]
> +diff --git a/tools/vtpm_manager/util/hashtable_itr.c
> b/tools/vtpm_manager/util/hashtable_itr.c
> --- a/tools/vtpm_manager/util/hashtable_itr.c
> +++ b/tools/vtpm_manager/util/hashtable_itr.c
> @@ -32,11 +32,6 @@
>   * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
>  */
>  
> -/*
> - * There are duplicates of this code in:
> - *  - tools/blktap2/drivers/hashtable_itr.c
> - */

The purpose of this message is to remind people who fix one version that
there are other copies which need fixing too. And perhaps to eventually
motivate someone into reducing the duplication.

Please leave them in place.

> -
>  #include "hashtable.h"
>  #include "hashtable_private.h"
>  #include "hashtable_itr.h"
> diff --git a/tools/vtpm_manager/util/hashtable_itr.h
> b/tools/vtpm_manager/util/hashtable_itr.h
> --- a/tools/vtpm_manager/util/hashtable_itr.h
> +++ b/tools/vtpm_manager/util/hashtable_itr.h
> @@ -32,11 +32,6 @@
>   * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
>  */
>  
> -/*
> - * There are duplicates of this code in:
> - *  - tools/blktap2/drivers/hashtable_itr.h
> - */

Please leave this....

> diff --git a/tools/vtpm_manager/util/hashtable_private.h
> b/tools/vtpm_manager/util/hashtable_private.h
> --- a/tools/vtpm_manager/util/hashtable_private.h
> +++ b/tools/vtpm_manager/util/hashtable_private.h
> @@ -32,12 +32,6 @@
>   * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
>  */
>  
> -/*
> - * There are duplicates of this code in:
> - *  - tools/xenstore/hashtable_private.h
> - *  - tools/blktap2/drivers/hashtable_private.h
> - */

... and this (and any other similar things you've removed which I didn't
notice)


Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 25 10:27:27 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 10:27: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 1TGSMC-00040F-Hs; Tue, 25 Sep 2012 10: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 1TGSMA-000406-9X
	for xen-devel@lists.xensource.com; Tue, 25 Sep 2012 10:27:10 +0000
Received: from [85.158.138.51:24941] by server-11.bemta-3.messagelabs.com id
	51/7C-30250-DF681605; Tue, 25 Sep 2012 10:27:09 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1348568826!31835847!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTEwNzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3923 invoked from network); 25 Sep 2012 10:27:07 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Sep 2012 10:27:07 -0000
X-IronPort-AV: E=Sophos;i="4.80,481,1344211200"; d="scan'208";a="14745613"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Sep 2012 10:27: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.279.1;
	Tue, 25 Sep 2012 11:27:06 +0100
Message-ID: <1348568824.3452.173.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
Date: Tue, 25 Sep 2012 11:27:04 +0100
In-Reply-To: <505CB918.3030108@jhuapl.edu>
References: <505CB918.3030108@jhuapl.edu>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] PATCH [base vtpm and libxl patches 3/6] Fix bugs in
 vtpm 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

On Fri, 2012-09-21 at 19:59 +0100, Matthew Fioravante wrote:
> This patch fixes IO deadlocks in the vtpm hotplug scripts.
> 
> Signed off by: Matthew Fioravante matthew.fioravante@jhuapl.edu
> 
> ---
> Changed since previous:
> * rebased off of latest xen stable
> * replaced instances of gawk with awk
> 
> diff --git a/tools/hotplug/Linux/vtpm b/tools/hotplug/Linux/vtpm
> --- a/tools/hotplug/Linux/vtpm
> +++ b/tools/hotplug/Linux/vtpm
> @@ -1,22 +1,18 @@
>  #!/bin/bash
>  
> +export PATH=$PATH:/usr/sbin:/sbin

I think this script already indirectly sources xen-hotplug-common.sh
which sets up the path. Likewise the other place you made 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 Tue Sep 25 10:27:27 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 10:27: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 1TGSMC-00040F-Hs; Tue, 25 Sep 2012 10: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 1TGSMA-000406-9X
	for xen-devel@lists.xensource.com; Tue, 25 Sep 2012 10:27:10 +0000
Received: from [85.158.138.51:24941] by server-11.bemta-3.messagelabs.com id
	51/7C-30250-DF681605; Tue, 25 Sep 2012 10:27:09 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1348568826!31835847!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTEwNzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3923 invoked from network); 25 Sep 2012 10:27:07 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Sep 2012 10:27:07 -0000
X-IronPort-AV: E=Sophos;i="4.80,481,1344211200"; d="scan'208";a="14745613"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Sep 2012 10:27: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.279.1;
	Tue, 25 Sep 2012 11:27:06 +0100
Message-ID: <1348568824.3452.173.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
Date: Tue, 25 Sep 2012 11:27:04 +0100
In-Reply-To: <505CB918.3030108@jhuapl.edu>
References: <505CB918.3030108@jhuapl.edu>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] PATCH [base vtpm and libxl patches 3/6] Fix bugs in
 vtpm 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

On Fri, 2012-09-21 at 19:59 +0100, Matthew Fioravante wrote:
> This patch fixes IO deadlocks in the vtpm hotplug scripts.
> 
> Signed off by: Matthew Fioravante matthew.fioravante@jhuapl.edu
> 
> ---
> Changed since previous:
> * rebased off of latest xen stable
> * replaced instances of gawk with awk
> 
> diff --git a/tools/hotplug/Linux/vtpm b/tools/hotplug/Linux/vtpm
> --- a/tools/hotplug/Linux/vtpm
> +++ b/tools/hotplug/Linux/vtpm
> @@ -1,22 +1,18 @@
>  #!/bin/bash
>  
> +export PATH=$PATH:/usr/sbin:/sbin

I think this script already indirectly sources xen-hotplug-common.sh
which sets up the path. Likewise the other place you made 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 Tue Sep 25 10:30:41 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 10:30: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 1TGSPP-00047z-5O; Tue, 25 Sep 2012 10:30: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 1TGSPN-00047r-SX
	for xen-devel@lists.xen.org; Tue, 25 Sep 2012 10:30:29 +0000
Received: from [85.158.143.35:34373] by server-2.bemta-4.messagelabs.com id
	AC/67-06610-5C781605; Tue, 25 Sep 2012 10:30:29 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1348569002!5022705!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32191 invoked from network); 25 Sep 2012 10:30:07 -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;
	25 Sep 2012 10:30:07 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 25 Sep 2012 11:30:02 +0100
Message-Id: <5061A3E1020000780009DA02@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 25 Sep 2012 11:30:25 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: <xen-devel@lists.xen.org>, "Dan Magenheimer" <dan.magenheimer@oracle.com>
References: <cc71cf29-4505-4acf-ac37-5190ce30451b@default>
In-Reply-To: <cc71cf29-4505-4acf-ac37-5190ce30451b@default>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Zhenzhong Duan <zhenzhong.duan@oracle.com>, tim@xen.org,
	IanJackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>,
	Konrad Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] tmem/XSA-15 backport?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 19.09.12 at 17:48, Dan Magenheimer <dan.magenheimer@oracle.com> wrote:
> Once zduan's tmem restore fix is applied, all known
> tmem security issues have been resolved and tested
> and tmem is fully functional again in xen-unstable,
> including save/restore.
> 
> I'd like to recommend that all tmem patches be backported
> to 4.1-stable and 4.2-stable prior to the next
> point release and preferably asap.

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 Sep 25 10:30:41 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 10:30: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 1TGSPP-00047z-5O; Tue, 25 Sep 2012 10:30: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 1TGSPN-00047r-SX
	for xen-devel@lists.xen.org; Tue, 25 Sep 2012 10:30:29 +0000
Received: from [85.158.143.35:34373] by server-2.bemta-4.messagelabs.com id
	AC/67-06610-5C781605; Tue, 25 Sep 2012 10:30:29 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1348569002!5022705!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32191 invoked from network); 25 Sep 2012 10:30:07 -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;
	25 Sep 2012 10:30:07 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 25 Sep 2012 11:30:02 +0100
Message-Id: <5061A3E1020000780009DA02@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 25 Sep 2012 11:30:25 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: <xen-devel@lists.xen.org>, "Dan Magenheimer" <dan.magenheimer@oracle.com>
References: <cc71cf29-4505-4acf-ac37-5190ce30451b@default>
In-Reply-To: <cc71cf29-4505-4acf-ac37-5190ce30451b@default>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Zhenzhong Duan <zhenzhong.duan@oracle.com>, tim@xen.org,
	IanJackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>,
	Konrad Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] tmem/XSA-15 backport?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 19.09.12 at 17:48, Dan Magenheimer <dan.magenheimer@oracle.com> wrote:
> Once zduan's tmem restore fix is applied, all known
> tmem security issues have been resolved and tested
> and tmem is fully functional again in xen-unstable,
> including save/restore.
> 
> I'd like to recommend that all tmem patches be backported
> to 4.1-stable and 4.2-stable prior to the next
> point release and preferably asap.

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 Sep 25 10:31:18 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 10:31:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGSQ0-0004B1-It; Tue, 25 Sep 2012 10:31:08 +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 1TGSPz-0004Aa-0I
	for xen-devel@lists.xensource.com; Tue, 25 Sep 2012 10:31:07 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1348569056!7106341!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTEwNzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31708 invoked from network); 25 Sep 2012 10:30:56 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Sep 2012 10:30:56 -0000
X-IronPort-AV: E=Sophos;i="4.80,481,1344211200"; d="scan'208";a="14745745"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Sep 2012 10:30:46 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Tue, 25 Sep 2012 11:30:46 +0100
Message-ID: <1348569044.3452.176.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
Date: Tue, 25 Sep 2012 11:30:44 +0100
In-Reply-To: <505CBA02.5040308@jhuapl.edu>
References: <505CBA02.5040308@jhuapl.edu>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] PATCH [base vtpm and libxl patches 4/6] add iomem
 support to 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

On Fri, 2012-09-21 at 20:03 +0100, Matthew Fioravante wrote:

> +        if ( ret<0 ){

Tiny coding style nit, this should be
	if (ret < 0) { 
> +            LOGE(ERROR,
> +                 "failed give dom%d access to iomem range
> %"PRIx64"-%"PRIx64,
> +                 domid, io->start, io->start + io->number - 1);
> +            ret = ERROR_FAIL;
> +        }
> +    }
> +
> +
> +
>      for (i = 0; i < d_config->num_nics; i++) {
>          /* We have to init the nic here, because we still haven't
>           * called libxl_device_nic_add at this point, but qemu needs
> @@ -1005,6 +1005,30 @@ static void parse_config_data(const char
> *config_source,
>          }
>      }
>  
> +    if (!xlu_cfg_get_list(config, "iomem", &iomem, &num_iomem, 0)) {
> +        b_info->num_iomem = num_iomem;
> +        b_info->iomem = calloc(num_iomem, sizeof(*b_info->iomem));
> +        if (b_info->iomem == NULL) {
> +            fprintf(stderr, "unable to allocate memory for iomem\n");
> +            exit(-1);
> +        }
> +        for (i = 0; i < num_iomem; i++) {
> +            buf = xlu_cfg_get_listitem (iomem, i);
> +            if (!buf) {
> +                fprintf(stderr,
> +                        "xl: Unable to get element %d in iomem list\n", i);
> +                exit(1);
> +            }
> +            if(sscanf(buf, "%" SCNx64",%" SCNu64,
> &b_info->iomem[i].start, &b_info->iomem[i].number) != 2) {

This should be relatively simply to parse with strtoul (see the ioports
case) which would allow people to select hex or decimal in their
configuration files.

Ian


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 25 10:31:18 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 10:31:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGSQ0-0004B1-It; Tue, 25 Sep 2012 10:31:08 +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 1TGSPz-0004Aa-0I
	for xen-devel@lists.xensource.com; Tue, 25 Sep 2012 10:31:07 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1348569056!7106341!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTEwNzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31708 invoked from network); 25 Sep 2012 10:30:56 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Sep 2012 10:30:56 -0000
X-IronPort-AV: E=Sophos;i="4.80,481,1344211200"; d="scan'208";a="14745745"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Sep 2012 10:30:46 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Tue, 25 Sep 2012 11:30:46 +0100
Message-ID: <1348569044.3452.176.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
Date: Tue, 25 Sep 2012 11:30:44 +0100
In-Reply-To: <505CBA02.5040308@jhuapl.edu>
References: <505CBA02.5040308@jhuapl.edu>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] PATCH [base vtpm and libxl patches 4/6] add iomem
 support to 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

On Fri, 2012-09-21 at 20:03 +0100, Matthew Fioravante wrote:

> +        if ( ret<0 ){

Tiny coding style nit, this should be
	if (ret < 0) { 
> +            LOGE(ERROR,
> +                 "failed give dom%d access to iomem range
> %"PRIx64"-%"PRIx64,
> +                 domid, io->start, io->start + io->number - 1);
> +            ret = ERROR_FAIL;
> +        }
> +    }
> +
> +
> +
>      for (i = 0; i < d_config->num_nics; i++) {
>          /* We have to init the nic here, because we still haven't
>           * called libxl_device_nic_add at this point, but qemu needs
> @@ -1005,6 +1005,30 @@ static void parse_config_data(const char
> *config_source,
>          }
>      }
>  
> +    if (!xlu_cfg_get_list(config, "iomem", &iomem, &num_iomem, 0)) {
> +        b_info->num_iomem = num_iomem;
> +        b_info->iomem = calloc(num_iomem, sizeof(*b_info->iomem));
> +        if (b_info->iomem == NULL) {
> +            fprintf(stderr, "unable to allocate memory for iomem\n");
> +            exit(-1);
> +        }
> +        for (i = 0; i < num_iomem; i++) {
> +            buf = xlu_cfg_get_listitem (iomem, i);
> +            if (!buf) {
> +                fprintf(stderr,
> +                        "xl: Unable to get element %d in iomem list\n", i);
> +                exit(1);
> +            }
> +            if(sscanf(buf, "%" SCNx64",%" SCNu64,
> &b_info->iomem[i].start, &b_info->iomem[i].number) != 2) {

This should be relatively simply to parse with strtoul (see the ioports
case) which would allow people to select hex or decimal in their
configuration files.

Ian


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 25 10:37:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 10:37:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGSVU-0004Zw-SG; Tue, 25 Sep 2012 10:36:48 +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 1TGSVS-0004Zo-Uk
	for xen-devel@lists.xensource.com; Tue, 25 Sep 2012 10:36:47 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1348569399!2989144!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTEwNzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11457 invoked from network); 25 Sep 2012 10:36:39 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Sep 2012 10:36:39 -0000
X-IronPort-AV: E=Sophos;i="4.80,481,1344211200"; d="scan'208";a="14745916"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Sep 2012 10:36: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.279.1;
	Tue, 25 Sep 2012 11:36:39 +0100
Message-ID: <1348569397.3452.180.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
Date: Tue, 25 Sep 2012 11:36:37 +0100
In-Reply-To: <505CBDFD.5070408@jhuapl.edu>
References: <505CBDFD.5070408@jhuapl.edu>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH xm/xl enhancements for vptm 5/6] make devid
	a libxl 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-09-21 at 20:20 +0100, Matthew Fioravante wrote:
> This fixes a bug in libxl where device ids are not initialized properly.
> The devid field for each device is set to be an integer type which are
> always initialized to 0.
> 
> This makes the xl DEV-attach commands always fail to add more than one
> device, because each time the device id is initialized to 0, when it
> should be initialized to -1, which in the code will trigger a search for
> free id.

Which of the DEV-attach commands can be used to add more than one
device?

Where is the code to do the search? I had a look in the disk and network
cases and couldn't find it.

> diff --git a/tools/ocaml/libs/xs/xs.mli b/tools/ocaml/libs/xs/xs.mli
> --- a/tools/ocaml/libs/xs/xs.mli
> +++ b/tools/ocaml/libs/xs/xs.mli
> @@ -27,6 +27,7 @@ exception Failed_to_connect
>  type perms = Xsraw.perms
>  
>  type domid = int
> +type devid = int

I can see why these were needed in the xl modules, but I don't see how
this type can be required in the xenstore ones.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 25 10:37:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 10:37:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGSVU-0004Zw-SG; Tue, 25 Sep 2012 10:36:48 +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 1TGSVS-0004Zo-Uk
	for xen-devel@lists.xensource.com; Tue, 25 Sep 2012 10:36:47 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1348569399!2989144!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTEwNzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11457 invoked from network); 25 Sep 2012 10:36:39 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Sep 2012 10:36:39 -0000
X-IronPort-AV: E=Sophos;i="4.80,481,1344211200"; d="scan'208";a="14745916"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Sep 2012 10:36: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.279.1;
	Tue, 25 Sep 2012 11:36:39 +0100
Message-ID: <1348569397.3452.180.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
Date: Tue, 25 Sep 2012 11:36:37 +0100
In-Reply-To: <505CBDFD.5070408@jhuapl.edu>
References: <505CBDFD.5070408@jhuapl.edu>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH xm/xl enhancements for vptm 5/6] make devid
	a libxl 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-09-21 at 20:20 +0100, Matthew Fioravante wrote:
> This fixes a bug in libxl where device ids are not initialized properly.
> The devid field for each device is set to be an integer type which are
> always initialized to 0.
> 
> This makes the xl DEV-attach commands always fail to add more than one
> device, because each time the device id is initialized to 0, when it
> should be initialized to -1, which in the code will trigger a search for
> free id.

Which of the DEV-attach commands can be used to add more than one
device?

Where is the code to do the search? I had a look in the disk and network
cases and couldn't find it.

> diff --git a/tools/ocaml/libs/xs/xs.mli b/tools/ocaml/libs/xs/xs.mli
> --- a/tools/ocaml/libs/xs/xs.mli
> +++ b/tools/ocaml/libs/xs/xs.mli
> @@ -27,6 +27,7 @@ exception Failed_to_connect
>  type perms = Xsraw.perms
>  
>  type domid = int
> +type devid = int

I can see why these were needed in the xl modules, but I don't see how
this type can be required in the xenstore ones.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 25 10:48:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 10:48:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGSgt-0004ks-4M; Tue, 25 Sep 2012 10:48:35 +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 1TGSgs-0004kn-00
	for xen-devel@lists.xensource.com; Tue, 25 Sep 2012 10:48:34 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1348570107!8582293!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20934 invoked from network); 25 Sep 2012 10:48:27 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-9.tower-27.messagelabs.com with SMTP;
	25 Sep 2012 10:48:27 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 25 Sep 2012 11:48:27 +0100
Message-Id: <5061A833020000780009DA1A@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 25 Sep 2012 11:48:51 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Christoph Egger" <Christoph.Egger@amd.com>,
	"Jinsong Liu" <jinsong.liu@intel.com>
References: <DE8DF0795D48FD4CA783C40EC8292335339547@SHSMSX101.ccr.corp.intel.com>
	<506173FB.8070603@amd.com>
In-Reply-To: <506173FB.8070603@amd.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"keir@xen.org" <keir@xen.org>,
	"Ian.Campbell@citrix.com" <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH 6] X86/MCE: update vMCE injection for AMD
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 25.09.12 at 11:06, Christoph Egger <Christoph.Egger@amd.com> wrote:
> On 09/25/12 07:00, Liu, Jinsong wrote:
> 
>> X86/MCE: update vMCE injection for AMD
>> 
>> For Intel MCE, it broadcasts vMCE to all vcpus. For AMD MCE, it injects
>> vMCE only to vcpu0. This patch update inject_vmce for AMD.
>> 
>> Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>
>> Suggested_by: Christoph Egger <Christoph.Egger@amd.com>
> 
> 
> Acked-by: Christoph Egger <Christoph.Egger@amd.com>

Are you sure (see below)?

>> diff -r a6d12a1bc758 xen/arch/x86/cpu/mcheck/mce.h
>> --- a/xen/arch/x86/cpu/mcheck/mce.h	Thu Sep 20 00:03:25 2012 +0800
>> +++ b/xen/arch/x86/cpu/mcheck/mce.h	Tue Sep 25 19:52:20 2012 +0800
>> @@ -168,7 +168,7 @@
>>  
>>  int fill_vmsr_data(struct mcinfo_bank *mc_bank, struct domain *d,
>>      uint64_t gstatus);
>> -int inject_vmce(struct domain *d);
>> +int inject_vmce(struct domain *d, bool_t vmce_broadcast);
>>  
>>  static inline int mce_vendor_bank_msr(const struct vcpu *v, uint32_t msr)
>>  {
>> diff -r a6d12a1bc758 xen/arch/x86/cpu/mcheck/mce_intel.c
>> --- a/xen/arch/x86/cpu/mcheck/mce_intel.c	Thu Sep 20 00:03:25 2012 +0800
>> +++ b/xen/arch/x86/cpu/mcheck/mce_intel.c	Tue Sep 25 19:52:20 2012 +0800
>> @@ -365,7 +365,7 @@
>>                  }
>>  
>>                  /* We will inject vMCE to DOMU*/
>> -                if ( inject_vmce(d) < 0 )
>> +                if ( inject_vmce(d, 1) < 0 )
>>                  {
>>                      mce_printk(MCE_QUIET, "inject vMCE to DOM%d"
>>                        " failed\n", d->domain_id);
>> diff -r a6d12a1bc758 xen/arch/x86/cpu/mcheck/vmce.c
>> --- a/xen/arch/x86/cpu/mcheck/vmce.c	Thu Sep 20 00:03:25 2012 +0800
>> +++ b/xen/arch/x86/cpu/mcheck/vmce.c	Tue Sep 25 19:52:20 2012 +0800
>> @@ -344,11 +344,14 @@
>>  HVM_REGISTER_SAVE_RESTORE(VMCE_VCPU, vmce_save_vcpu_ctxt,
>>                            vmce_load_vcpu_ctxt, 1, HVMSR_PER_VCPU);
>>  
>> -int inject_vmce(struct domain *d)
>> +/* 
>> + * for Intel MCE, broadcast vMCE to all vcpus
>> + * for AMD MCE, only inject vMCE to vcpu0
>> + */
>> +int inject_vmce(struct domain *d, bool_t vmce_broadcast)
>>  {
>>      struct vcpu *v;
>>  
>> -    /* inject vMCE to all vcpus */
>>      for_each_vcpu(d, v)
>>      {
>>          if ( !test_and_set_bool(v->mce_pending) &&
>> @@ -365,6 +368,9 @@
>>                         d->domain_id, v->vcpu_id);
>>              return -1;
>>          }
>> +
>> +        if ( !vmce_broadcast )
>> +            break;

That'll allow (non-broadcast) injection to vCPU 0 only - is that
really the right thing to do? I.e. shouldn't the caller rather be
given flexibility to specify which vCPU this is to go to (with a
negative value meaning broadcast)?

And I'm intending to fold this into patch 2 anyway before
committing.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 25 10:48:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 10:48:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGSgt-0004ks-4M; Tue, 25 Sep 2012 10:48:35 +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 1TGSgs-0004kn-00
	for xen-devel@lists.xensource.com; Tue, 25 Sep 2012 10:48:34 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1348570107!8582293!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20934 invoked from network); 25 Sep 2012 10:48:27 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-9.tower-27.messagelabs.com with SMTP;
	25 Sep 2012 10:48:27 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 25 Sep 2012 11:48:27 +0100
Message-Id: <5061A833020000780009DA1A@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 25 Sep 2012 11:48:51 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Christoph Egger" <Christoph.Egger@amd.com>,
	"Jinsong Liu" <jinsong.liu@intel.com>
References: <DE8DF0795D48FD4CA783C40EC8292335339547@SHSMSX101.ccr.corp.intel.com>
	<506173FB.8070603@amd.com>
In-Reply-To: <506173FB.8070603@amd.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"keir@xen.org" <keir@xen.org>,
	"Ian.Campbell@citrix.com" <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH 6] X86/MCE: update vMCE injection for AMD
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 25.09.12 at 11:06, Christoph Egger <Christoph.Egger@amd.com> wrote:
> On 09/25/12 07:00, Liu, Jinsong wrote:
> 
>> X86/MCE: update vMCE injection for AMD
>> 
>> For Intel MCE, it broadcasts vMCE to all vcpus. For AMD MCE, it injects
>> vMCE only to vcpu0. This patch update inject_vmce for AMD.
>> 
>> Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>
>> Suggested_by: Christoph Egger <Christoph.Egger@amd.com>
> 
> 
> Acked-by: Christoph Egger <Christoph.Egger@amd.com>

Are you sure (see below)?

>> diff -r a6d12a1bc758 xen/arch/x86/cpu/mcheck/mce.h
>> --- a/xen/arch/x86/cpu/mcheck/mce.h	Thu Sep 20 00:03:25 2012 +0800
>> +++ b/xen/arch/x86/cpu/mcheck/mce.h	Tue Sep 25 19:52:20 2012 +0800
>> @@ -168,7 +168,7 @@
>>  
>>  int fill_vmsr_data(struct mcinfo_bank *mc_bank, struct domain *d,
>>      uint64_t gstatus);
>> -int inject_vmce(struct domain *d);
>> +int inject_vmce(struct domain *d, bool_t vmce_broadcast);
>>  
>>  static inline int mce_vendor_bank_msr(const struct vcpu *v, uint32_t msr)
>>  {
>> diff -r a6d12a1bc758 xen/arch/x86/cpu/mcheck/mce_intel.c
>> --- a/xen/arch/x86/cpu/mcheck/mce_intel.c	Thu Sep 20 00:03:25 2012 +0800
>> +++ b/xen/arch/x86/cpu/mcheck/mce_intel.c	Tue Sep 25 19:52:20 2012 +0800
>> @@ -365,7 +365,7 @@
>>                  }
>>  
>>                  /* We will inject vMCE to DOMU*/
>> -                if ( inject_vmce(d) < 0 )
>> +                if ( inject_vmce(d, 1) < 0 )
>>                  {
>>                      mce_printk(MCE_QUIET, "inject vMCE to DOM%d"
>>                        " failed\n", d->domain_id);
>> diff -r a6d12a1bc758 xen/arch/x86/cpu/mcheck/vmce.c
>> --- a/xen/arch/x86/cpu/mcheck/vmce.c	Thu Sep 20 00:03:25 2012 +0800
>> +++ b/xen/arch/x86/cpu/mcheck/vmce.c	Tue Sep 25 19:52:20 2012 +0800
>> @@ -344,11 +344,14 @@
>>  HVM_REGISTER_SAVE_RESTORE(VMCE_VCPU, vmce_save_vcpu_ctxt,
>>                            vmce_load_vcpu_ctxt, 1, HVMSR_PER_VCPU);
>>  
>> -int inject_vmce(struct domain *d)
>> +/* 
>> + * for Intel MCE, broadcast vMCE to all vcpus
>> + * for AMD MCE, only inject vMCE to vcpu0
>> + */
>> +int inject_vmce(struct domain *d, bool_t vmce_broadcast)
>>  {
>>      struct vcpu *v;
>>  
>> -    /* inject vMCE to all vcpus */
>>      for_each_vcpu(d, v)
>>      {
>>          if ( !test_and_set_bool(v->mce_pending) &&
>> @@ -365,6 +368,9 @@
>>                         d->domain_id, v->vcpu_id);
>>              return -1;
>>          }
>> +
>> +        if ( !vmce_broadcast )
>> +            break;

That'll allow (non-broadcast) injection to vCPU 0 only - is that
really the right thing to do? I.e. shouldn't the caller rather be
given flexibility to specify which vCPU this is to go to (with a
negative value meaning broadcast)?

And I'm intending to fold this into patch 2 anyway before
committing.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 25 10:50:25 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 10:50:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGSiT-0004qY-K1; Tue, 25 Sep 2012 10:50:13 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1TGSiR-0004qR-Q7
	for xen-devel@lists.xensource.com; Tue, 25 Sep 2012 10:50:12 +0000
Received: from [85.158.143.35:3157] by server-2.bemta-4.messagelabs.com id
	F9/F8-06610-36C81605; Tue, 25 Sep 2012 10:50:11 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1348570205!19776608!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTEwNzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11516 invoked from network); 25 Sep 2012 10:50:09 -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;
	25 Sep 2012 10:50:09 -0000
X-IronPort-AV: E=Sophos;i="4.80,481,1344211200"; d="scan'208";a="14746271"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Sep 2012 10:49: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.279.1;
	Tue, 25 Sep 2012 11:49:22 +0100
Message-ID: <1348570160.3452.191.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
Date: Tue, 25 Sep 2012 11:49:20 +0100
In-Reply-To: <505CBEB4.8060105@jhuapl.edu>
References: <505CBEB4.8060105@jhuapl.edu>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH xm/xl enhancements for vptm 6/6] add vtpm
 support to 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

On Fri, 2012-09-21 at 20:23 +0100, Matthew Fioravante wrote:
> Add support for vtpm=["VTPM_SPEC",...] to domain config files. Also add
> commands vtpm-attach, vtpm-list, and vtpm-detach.
> 
> Signed off by Matthew Fioravante matthew.fioravante@jhuapl.edu
> 
> ---
> Changes since previous:
> * Rebased to latest xen
> * Updated xl.cfg and xl manpages
> 
> 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
> @@ -298,6 +298,35 @@ 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>.
>  
> +=item B<vtpm=[ "VTPM_SPEC_STRING", "VTPM_SPEC_STRING", ...]>
> +
> +Specifies the virtual trusted platform module to be

can there be more than one?

> +provided to the guest. Please see F<docs/misc/vtpm.txt>
> +for more details.
> +
> +Each B<VTPM_SPEC_STRING> is a comma-separated list of C<KEY=VALUE>
> +settings, from the following list:
> +
> +=over 4
> +
> +=item C<backend=DOMAIN>
> +
> +Specify the backend domain name of id. This value must be
> +set if you are using the vtpm domain model. If this domain
> +is a guest, the backend should be set to the vtpm domain name.
> +If this domain is a vtpm, the backend should be set to the
> +vtpm manager domain name. The default value is domain 0,
> +which should be used if you are running the vtpm process model.

I had a look in docs/misc/vtpm.txt but didn't see anything which
explained "vtpm process model" vs "vtpm manager domain" vs "vtpm
domain". I suppose that's part of the future doc work you were talking
about ;-)

> +
> +=item C<uuid=UUID>
> +
> +Specify the uuid of this vtpm device. The uuid is used to uniquely
> +identify the vtpm device. You can create one using the uuidgen
> +program on unix systems. If left unspecified, a new uuid
> +will be randomly generated everytime the domain boots.

                                   ^missing space here
> +
> +=back
> +
>  =item B<vfb=[ "VFB_SPEC_STRING", "VFB_SPEC_STRING", ...]>
>  
>  Specifies the paravirtual framebuffer devices which should be supplied
> [..]
> diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
> --- a/tools/libxl/libxl.c
> +++ b/tools/libxl/libxl.c
[...]
> +static void domcreate_attach_vtpms(libxl__egc *egc, libxl__multidev
> *multidev, int ret) {
> +   libxl__domain_create_state *dcs = CONTAINER_OF(multidev, *dcs,
> multidev);
> +   STATE_AO_GC(dcs->ao);
> +   int domid = dcs->guest_domid;
> +
> +   libxl_domain_config* const d_config = dcs->guest_config;
> +
> +   if(ret) {
> +      LOG(ERROR, "unable to add nic devices");
> +      goto error_out;
> +   }
> +
> +    /* Plug nic interfaces */

You mean vtpms here.

> +int main_vtpmdetach(int argc, char **argv)
> +{
> +    uint32_t domid;
> +    int opt, rc=0;
> +    libxl_device_vtpm vtpm;
> +    libxl_uuid uuid;
> +
> +    if ((opt = def_getopt(argc, argv, "", "vtpm-detach", 2)) != -1)
> +        return opt;
> +
> +    domid = find_domain(argv[optind]);
> +
> +    if ( libxl_uuid_from_string(&uuid, argv[optind+1])) {

Why does vtpm use/need UUID's for identification rather than just a
domid+devid like other device types?

Is the UUID used for something more than identification?

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 25 10:50:25 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 10:50:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGSiT-0004qY-K1; Tue, 25 Sep 2012 10:50:13 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1TGSiR-0004qR-Q7
	for xen-devel@lists.xensource.com; Tue, 25 Sep 2012 10:50:12 +0000
Received: from [85.158.143.35:3157] by server-2.bemta-4.messagelabs.com id
	F9/F8-06610-36C81605; Tue, 25 Sep 2012 10:50:11 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1348570205!19776608!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTEwNzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11516 invoked from network); 25 Sep 2012 10:50:09 -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;
	25 Sep 2012 10:50:09 -0000
X-IronPort-AV: E=Sophos;i="4.80,481,1344211200"; d="scan'208";a="14746271"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Sep 2012 10:49: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.279.1;
	Tue, 25 Sep 2012 11:49:22 +0100
Message-ID: <1348570160.3452.191.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
Date: Tue, 25 Sep 2012 11:49:20 +0100
In-Reply-To: <505CBEB4.8060105@jhuapl.edu>
References: <505CBEB4.8060105@jhuapl.edu>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH xm/xl enhancements for vptm 6/6] add vtpm
 support to 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

On Fri, 2012-09-21 at 20:23 +0100, Matthew Fioravante wrote:
> Add support for vtpm=["VTPM_SPEC",...] to domain config files. Also add
> commands vtpm-attach, vtpm-list, and vtpm-detach.
> 
> Signed off by Matthew Fioravante matthew.fioravante@jhuapl.edu
> 
> ---
> Changes since previous:
> * Rebased to latest xen
> * Updated xl.cfg and xl manpages
> 
> 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
> @@ -298,6 +298,35 @@ 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>.
>  
> +=item B<vtpm=[ "VTPM_SPEC_STRING", "VTPM_SPEC_STRING", ...]>
> +
> +Specifies the virtual trusted platform module to be

can there be more than one?

> +provided to the guest. Please see F<docs/misc/vtpm.txt>
> +for more details.
> +
> +Each B<VTPM_SPEC_STRING> is a comma-separated list of C<KEY=VALUE>
> +settings, from the following list:
> +
> +=over 4
> +
> +=item C<backend=DOMAIN>
> +
> +Specify the backend domain name of id. This value must be
> +set if you are using the vtpm domain model. If this domain
> +is a guest, the backend should be set to the vtpm domain name.
> +If this domain is a vtpm, the backend should be set to the
> +vtpm manager domain name. The default value is domain 0,
> +which should be used if you are running the vtpm process model.

I had a look in docs/misc/vtpm.txt but didn't see anything which
explained "vtpm process model" vs "vtpm manager domain" vs "vtpm
domain". I suppose that's part of the future doc work you were talking
about ;-)

> +
> +=item C<uuid=UUID>
> +
> +Specify the uuid of this vtpm device. The uuid is used to uniquely
> +identify the vtpm device. You can create one using the uuidgen
> +program on unix systems. If left unspecified, a new uuid
> +will be randomly generated everytime the domain boots.

                                   ^missing space here
> +
> +=back
> +
>  =item B<vfb=[ "VFB_SPEC_STRING", "VFB_SPEC_STRING", ...]>
>  
>  Specifies the paravirtual framebuffer devices which should be supplied
> [..]
> diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
> --- a/tools/libxl/libxl.c
> +++ b/tools/libxl/libxl.c
[...]
> +static void domcreate_attach_vtpms(libxl__egc *egc, libxl__multidev
> *multidev, int ret) {
> +   libxl__domain_create_state *dcs = CONTAINER_OF(multidev, *dcs,
> multidev);
> +   STATE_AO_GC(dcs->ao);
> +   int domid = dcs->guest_domid;
> +
> +   libxl_domain_config* const d_config = dcs->guest_config;
> +
> +   if(ret) {
> +      LOG(ERROR, "unable to add nic devices");
> +      goto error_out;
> +   }
> +
> +    /* Plug nic interfaces */

You mean vtpms here.

> +int main_vtpmdetach(int argc, char **argv)
> +{
> +    uint32_t domid;
> +    int opt, rc=0;
> +    libxl_device_vtpm vtpm;
> +    libxl_uuid uuid;
> +
> +    if ((opt = def_getopt(argc, argv, "", "vtpm-detach", 2)) != -1)
> +        return opt;
> +
> +    domid = find_domain(argv[optind]);
> +
> +    if ( libxl_uuid_from_string(&uuid, argv[optind+1])) {

Why does vtpm use/need UUID's for identification rather than just a
domid+devid like other device types?

Is the UUID used for something more than identification?

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 25 10:51:19 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 10: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 1TGSjM-0004w5-5v; Tue, 25 Sep 2012 10:51:08 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1TGSjK-0004vt-VS
	for xen-devel@lists.xensource.com; Tue, 25 Sep 2012 10:51:07 +0000
Received: from [85.158.143.99:51747] by server-3.bemta-4.messagelabs.com id
	94/30-10986-A9C81605; Tue, 25 Sep 2012 10:51:06 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1348570265!24677572!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTEwNzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16231 invoked from network); 25 Sep 2012 10:51:05 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Sep 2012 10:51:05 -0000
X-IronPort-AV: E=Sophos;i="4.80,481,1344211200"; d="scan'208";a="14746335"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Sep 2012 10:51: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.279.1;
	Tue, 25 Sep 2012 11:51:05 +0100
Message-ID: <1348570263.3452.192.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
Date: Tue, 25 Sep 2012 11:51:03 +0100
In-Reply-To: <505CBF82.3070101@jhuapl.edu>
References: <5058B8DB.5040109@jhuapl.edu>
	<1348057160.14977.98.camel@zakaz.uk.xensource.com>
	<505CBF82.3070101@jhuapl.edu>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH xm/xl enhancements for vptm 1/6] xl make
 devid a libxl 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-09-21 at 20:26 +0100, Matthew Fioravante wrote:
> The whole purpose of this patch is initialize device ids to -1 instead
> of zero and the only way I could come up to do that cleanly within
> libxl's type system was to create a new type. 

I think that's the right thing to do.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 25 10:51:19 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 10: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 1TGSjM-0004w5-5v; Tue, 25 Sep 2012 10:51:08 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1TGSjK-0004vt-VS
	for xen-devel@lists.xensource.com; Tue, 25 Sep 2012 10:51:07 +0000
Received: from [85.158.143.99:51747] by server-3.bemta-4.messagelabs.com id
	94/30-10986-A9C81605; Tue, 25 Sep 2012 10:51:06 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1348570265!24677572!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTEwNzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16231 invoked from network); 25 Sep 2012 10:51:05 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Sep 2012 10:51:05 -0000
X-IronPort-AV: E=Sophos;i="4.80,481,1344211200"; d="scan'208";a="14746335"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Sep 2012 10:51: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.279.1;
	Tue, 25 Sep 2012 11:51:05 +0100
Message-ID: <1348570263.3452.192.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
Date: Tue, 25 Sep 2012 11:51:03 +0100
In-Reply-To: <505CBF82.3070101@jhuapl.edu>
References: <5058B8DB.5040109@jhuapl.edu>
	<1348057160.14977.98.camel@zakaz.uk.xensource.com>
	<505CBF82.3070101@jhuapl.edu>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH xm/xl enhancements for vptm 1/6] xl make
 devid a libxl 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-09-21 at 20:26 +0100, Matthew Fioravante wrote:
> The whole purpose of this patch is initialize device ids to -1 instead
> of zero and the only way I could come up to do that cleanly within
> libxl's type system was to create a new type. 

I think that's the right thing to do.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 25 10:53:24 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 10:53:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGSlN-00057P-Na; Tue, 25 Sep 2012 10:53: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 1TGSlM-00057I-Lp
	for xen-devel@lists.xen.org; Tue, 25 Sep 2012 10:53:12 +0000
Received: from [85.158.139.211:42565] by server-16.bemta-5.messagelabs.com id
	AA/C8-05998-71D81605; Tue, 25 Sep 2012 10:53:11 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-9.tower-206.messagelabs.com!1348570391!18363197!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTEwNzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24470 invoked from network); 25 Sep 2012 10:53:11 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Sep 2012 10:53:11 -0000
X-IronPort-AV: E=Sophos;i="4.80,481,1344211200"; d="scan'208";a="14746391"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Sep 2012 10:53:10 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Tue, 25 Sep 2012 11:53:10 +0100
Date: Tue, 25 Sep 2012 11:52:17 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Xudong Hao <xudong.hao@intel.com>
In-Reply-To: <1348544326-31334-1-git-send-email-xudong.hao@intel.com>
Message-ID: <alpine.DEB.2.02.1209251134460.29232@kaball.uk.xensource.com>
References: <1348544326-31334-1-git-send-email-xudong.hao@intel.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>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	Xiantao Zhang <xiantao.zhang@intel.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v2] qemu/xen: Add 64 bits big bar support on
	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, 25 Sep 2012, Xudong Hao wrote:
> Changes from v1:
> - Rebase to qemu upstream from qemu-xen

Thanks. Please run scripts/checkpatch.pl on this patch, you'll find
some cody style issues that need to be fixed.


> Currently it is assumed PCI device BAR access < 4G memory. If there is such a
> device whose BAR size is larger than 4G, it must access > 4G memory address.
> This patch enable the 64bits big BAR support on qemu.
> 
> Signed-off-by: Xudong Hao <xudong.hao@intel.com>
> Signed-off-by: Xiantao Zhang <xiantao.zhang@intel.com>
> ---
>  hw/xen_pt.c             |   16 ++++++++--------
>  hw/xen_pt_config_init.c |   42 +++++++++++++++++++++++++++++-------------
> 
> diff --git a/hw/xen_pt.c b/hw/xen_pt.c
> index 307119a..2a8bcf3 100644
> --- a/hw/xen_pt.c
> +++ b/hw/xen_pt.c
> @@ -403,21 +403,21 @@ static int xen_pt_register_regions(XenPCIPassthroughState *s)
>  
>          s->bases[i].access.u = r->base_addr;
>  
> -        if (r->type & XEN_HOST_PCI_REGION_TYPE_IO) {
> +        if (r->type & XEN_HOST_PCI_REGION_TYPE_IO)
>              type = PCI_BASE_ADDRESS_SPACE_IO;
> -        } else {
> +        else if (r->type & XEN_HOST_PCI_REGION_TYPE_MEM_64)
> +            type = PCI_BASE_ADDRESS_MEM_TYPE_64;
> +        else if (r->type & XEN_HOST_PCI_REGION_TYPE_PREFETCH)
> +            type |= PCI_BASE_ADDRESS_MEM_PREFETCH;
> +        else
>              type = PCI_BASE_ADDRESS_SPACE_MEMORY;
> -            if (r->type & XEN_HOST_PCI_REGION_TYPE_PREFETCH) {
> -                type |= PCI_BASE_ADDRESS_MEM_PREFETCH;
> -            }
> -        }

Aside from the cody style issue here, this changes the behavior for type
PCI_BASE_ADDRESS_SPACE_MEMORY. Before we could have:

type = PCI_BASE_ADDRESS_SPACE_MEMORY|PCI_BASE_ADDRESS_MEM_PREFETCH;

now we cannot anymore.


>          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",
> +        XEN_PT_LOG(&s->dev, "IO region %i registered (size=0x%lx"PRIx64
> +                   " base_addr=0x%lx"PRIx64" type: %#x)\n",
>                     i, r->size, r->base_addr, type);
>      }
>  
> diff --git a/hw/xen_pt_config_init.c b/hw/xen_pt_config_init.c
> index e524a40..5e7ca22 100644
> --- a/hw/xen_pt_config_init.c
> +++ b/hw/xen_pt_config_init.c
> @@ -342,6 +342,7 @@ static int xen_pt_cmd_reg_write(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
>  #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 uint64_t xen_pt_get_bar_size(PCIIORegion *r);

there is just one user of xen_pt_get_bar_size, maybe you can just
move the implementation here


>  static XenPTBarFlag xen_pt_bar_reg_parse(XenPCIPassthroughState *s,
>                                           XenPTRegInfo *reg)
>  {
> @@ -366,7 +367,7 @@ static XenPTBarFlag xen_pt_bar_reg_parse(XenPCIPassthroughState *s,
>  
>      /* check unused BAR */
>      r = &d->io_regions[index];
> -    if (r->size == 0) {
> +    if (!xen_pt_get_bar_size(r)) {
>          return XEN_PT_BAR_FLAG_UNUSED;
>      }
>  
> @@ -383,6 +384,24 @@ static XenPTBarFlag xen_pt_bar_reg_parse(XenPCIPassthroughState *s,
>      }
>  }
>  
> +static bool is_64bit_bar(PCIIORegion *r)
> +{
> +    return !!(r->type & PCI_BASE_ADDRESS_MEM_TYPE_64);
> +}
> +
> +static uint64_t xen_pt_get_bar_size(PCIIORegion *r)
> +{
> +    if (is_64bit_bar(r))
> +    {
> +        uint64_t size64;
> +        size64 = (r + 1)->size; 
> +        size64 <<= 32; 
> +        size64 += r->size;
> +        return size64; 
> +    }
> +    return r->size; 
> +}
> +
>  static inline uint32_t base_address_with_flags(XenHostPCIIORegion *hr)
>  {
>      if (hr->type & XEN_HOST_PCI_REGION_TYPE_IO) {
> @@ -481,7 +500,10 @@ static int xen_pt_bar_reg_write(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
>      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);
> +        if (!r_size)
> +            bar_ro_mask = XEN_PT_BAR_ALLF;
> +        else
> +            bar_ro_mask = XEN_PT_BAR_MEM_RO_MASK | (r_size - 1);
>          break;

Is this an actual mistake everywhere?
There is at least another instance of

bar_ro_mask = something | (r_size - 1);

under the XEN_PT_BAR_FLAG_IO case.
Or is it only a problem with 64 bit bars? If so, could you please
explain why?


>      case XEN_PT_BAR_FLAG_IO:
>          bar_emu_mask = XEN_PT_BAR_IO_EMU_MASK;
> @@ -489,7 +511,10 @@ static int xen_pt_bar_reg_write(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
>          break;
>      case XEN_PT_BAR_FLAG_UPPER:
>          bar_emu_mask = XEN_PT_BAR_ALLF;
> -        bar_ro_mask = 0;    /* all upper 32bit are R/W */
> +        if (!r_size)
> +            bar_ro_mask = 0;
> +        else
> +            bar_ro_mask = r_size - 1;
>          break;

bar_ro_mask = r_size ? r_size - 1 : 0;


>      default:
>          break;
> @@ -501,22 +526,13 @@ static int xen_pt_bar_reg_write(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
>  
>      /* check whether we need to update the virtual region address or not */
>      switch (s->bases[index].bar_flag) {
> +    case XEN_PT_BAR_FLAG_UPPER:
>      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;
>      }
> -- 
> 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 Sep 25 10:53:24 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 10:53:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGSlN-00057P-Na; Tue, 25 Sep 2012 10:53: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 1TGSlM-00057I-Lp
	for xen-devel@lists.xen.org; Tue, 25 Sep 2012 10:53:12 +0000
Received: from [85.158.139.211:42565] by server-16.bemta-5.messagelabs.com id
	AA/C8-05998-71D81605; Tue, 25 Sep 2012 10:53:11 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-9.tower-206.messagelabs.com!1348570391!18363197!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTEwNzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24470 invoked from network); 25 Sep 2012 10:53:11 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Sep 2012 10:53:11 -0000
X-IronPort-AV: E=Sophos;i="4.80,481,1344211200"; d="scan'208";a="14746391"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Sep 2012 10:53:10 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Tue, 25 Sep 2012 11:53:10 +0100
Date: Tue, 25 Sep 2012 11:52:17 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Xudong Hao <xudong.hao@intel.com>
In-Reply-To: <1348544326-31334-1-git-send-email-xudong.hao@intel.com>
Message-ID: <alpine.DEB.2.02.1209251134460.29232@kaball.uk.xensource.com>
References: <1348544326-31334-1-git-send-email-xudong.hao@intel.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>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	Xiantao Zhang <xiantao.zhang@intel.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v2] qemu/xen: Add 64 bits big bar support on
	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, 25 Sep 2012, Xudong Hao wrote:
> Changes from v1:
> - Rebase to qemu upstream from qemu-xen

Thanks. Please run scripts/checkpatch.pl on this patch, you'll find
some cody style issues that need to be fixed.


> Currently it is assumed PCI device BAR access < 4G memory. If there is such a
> device whose BAR size is larger than 4G, it must access > 4G memory address.
> This patch enable the 64bits big BAR support on qemu.
> 
> Signed-off-by: Xudong Hao <xudong.hao@intel.com>
> Signed-off-by: Xiantao Zhang <xiantao.zhang@intel.com>
> ---
>  hw/xen_pt.c             |   16 ++++++++--------
>  hw/xen_pt_config_init.c |   42 +++++++++++++++++++++++++++++-------------
> 
> diff --git a/hw/xen_pt.c b/hw/xen_pt.c
> index 307119a..2a8bcf3 100644
> --- a/hw/xen_pt.c
> +++ b/hw/xen_pt.c
> @@ -403,21 +403,21 @@ static int xen_pt_register_regions(XenPCIPassthroughState *s)
>  
>          s->bases[i].access.u = r->base_addr;
>  
> -        if (r->type & XEN_HOST_PCI_REGION_TYPE_IO) {
> +        if (r->type & XEN_HOST_PCI_REGION_TYPE_IO)
>              type = PCI_BASE_ADDRESS_SPACE_IO;
> -        } else {
> +        else if (r->type & XEN_HOST_PCI_REGION_TYPE_MEM_64)
> +            type = PCI_BASE_ADDRESS_MEM_TYPE_64;
> +        else if (r->type & XEN_HOST_PCI_REGION_TYPE_PREFETCH)
> +            type |= PCI_BASE_ADDRESS_MEM_PREFETCH;
> +        else
>              type = PCI_BASE_ADDRESS_SPACE_MEMORY;
> -            if (r->type & XEN_HOST_PCI_REGION_TYPE_PREFETCH) {
> -                type |= PCI_BASE_ADDRESS_MEM_PREFETCH;
> -            }
> -        }

Aside from the cody style issue here, this changes the behavior for type
PCI_BASE_ADDRESS_SPACE_MEMORY. Before we could have:

type = PCI_BASE_ADDRESS_SPACE_MEMORY|PCI_BASE_ADDRESS_MEM_PREFETCH;

now we cannot anymore.


>          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",
> +        XEN_PT_LOG(&s->dev, "IO region %i registered (size=0x%lx"PRIx64
> +                   " base_addr=0x%lx"PRIx64" type: %#x)\n",
>                     i, r->size, r->base_addr, type);
>      }
>  
> diff --git a/hw/xen_pt_config_init.c b/hw/xen_pt_config_init.c
> index e524a40..5e7ca22 100644
> --- a/hw/xen_pt_config_init.c
> +++ b/hw/xen_pt_config_init.c
> @@ -342,6 +342,7 @@ static int xen_pt_cmd_reg_write(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
>  #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 uint64_t xen_pt_get_bar_size(PCIIORegion *r);

there is just one user of xen_pt_get_bar_size, maybe you can just
move the implementation here


>  static XenPTBarFlag xen_pt_bar_reg_parse(XenPCIPassthroughState *s,
>                                           XenPTRegInfo *reg)
>  {
> @@ -366,7 +367,7 @@ static XenPTBarFlag xen_pt_bar_reg_parse(XenPCIPassthroughState *s,
>  
>      /* check unused BAR */
>      r = &d->io_regions[index];
> -    if (r->size == 0) {
> +    if (!xen_pt_get_bar_size(r)) {
>          return XEN_PT_BAR_FLAG_UNUSED;
>      }
>  
> @@ -383,6 +384,24 @@ static XenPTBarFlag xen_pt_bar_reg_parse(XenPCIPassthroughState *s,
>      }
>  }
>  
> +static bool is_64bit_bar(PCIIORegion *r)
> +{
> +    return !!(r->type & PCI_BASE_ADDRESS_MEM_TYPE_64);
> +}
> +
> +static uint64_t xen_pt_get_bar_size(PCIIORegion *r)
> +{
> +    if (is_64bit_bar(r))
> +    {
> +        uint64_t size64;
> +        size64 = (r + 1)->size; 
> +        size64 <<= 32; 
> +        size64 += r->size;
> +        return size64; 
> +    }
> +    return r->size; 
> +}
> +
>  static inline uint32_t base_address_with_flags(XenHostPCIIORegion *hr)
>  {
>      if (hr->type & XEN_HOST_PCI_REGION_TYPE_IO) {
> @@ -481,7 +500,10 @@ static int xen_pt_bar_reg_write(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
>      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);
> +        if (!r_size)
> +            bar_ro_mask = XEN_PT_BAR_ALLF;
> +        else
> +            bar_ro_mask = XEN_PT_BAR_MEM_RO_MASK | (r_size - 1);
>          break;

Is this an actual mistake everywhere?
There is at least another instance of

bar_ro_mask = something | (r_size - 1);

under the XEN_PT_BAR_FLAG_IO case.
Or is it only a problem with 64 bit bars? If so, could you please
explain why?


>      case XEN_PT_BAR_FLAG_IO:
>          bar_emu_mask = XEN_PT_BAR_IO_EMU_MASK;
> @@ -489,7 +511,10 @@ static int xen_pt_bar_reg_write(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
>          break;
>      case XEN_PT_BAR_FLAG_UPPER:
>          bar_emu_mask = XEN_PT_BAR_ALLF;
> -        bar_ro_mask = 0;    /* all upper 32bit are R/W */
> +        if (!r_size)
> +            bar_ro_mask = 0;
> +        else
> +            bar_ro_mask = r_size - 1;
>          break;

bar_ro_mask = r_size ? r_size - 1 : 0;


>      default:
>          break;
> @@ -501,22 +526,13 @@ static int xen_pt_bar_reg_write(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
>  
>      /* check whether we need to update the virtual region address or not */
>      switch (s->bases[index].bar_flag) {
> +    case XEN_PT_BAR_FLAG_UPPER:
>      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;
>      }
> -- 
> 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 Sep 25 10:57:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 10:57:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGSp3-0005L6-KK; Tue, 25 Sep 2012 10:57:01 +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 1TGSp2-0005Kd-9S
	for xen-devel@lists.xen.org; Tue, 25 Sep 2012 10:57:00 +0000
Received: from [85.158.139.83:2485] by server-6.bemta-5.messagelabs.com id
	09/52-14717-AFD81605; Tue, 25 Sep 2012 10:56:58 +0000
X-Env-Sender: lars.kurth.xen@gmail.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1348570618!29182936!1
X-Originating-IP: [74.125.83.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14736 invoked from network); 25 Sep 2012 10:56:58 -0000
Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com)
	(74.125.83.45)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Sep 2012 10:56:58 -0000
Received: by eekb47 with SMTP id b47so1052260eek.32
	for <multiple recipients>; Tue, 25 Sep 2012 03:56:58 -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=Wpz1YTr79D0LTsK1sZB7lYaA1bWrLPrWrV8yAE991CU=;
	b=vseRFu1uSNOtf9x7j1adCKIILF8TDj4B58JR2XbiBpL+gXwR4kkbcCOXrIMjMjkU8i
	3G5E0xNAcfWV3SLIWjEYHXhujJBQ4zeyZc7bxOYqT15cQMya+EU3o2eeu45Q3pgWLPuc
	U8QCfcsFtk8MbMtDJpymH2dKTpmx2b9hU9dedD/6MS0CIjvNkfECmeBJV6AFRya9ZcbY
	ytD8XyWDcNyFoefc/xwr2FeTHTAyPi7wb8HbvHN/n89vDblS2fiOXDIRU2Qpzj5qT4ls
	bpHkzKFv7pw9H2C3aavkT0XCIikeDm55r2ZeKvXSCn3PoZge8cgQaBBD1Gul1hDRJ7Wf
	55LQ==
Received: by 10.14.173.9 with SMTP id u9mr18719241eel.8.1348570618190;
	Tue, 25 Sep 2012 03:56:58 -0700 (PDT)
Received: from [172.16.26.11] (b0fb5b35.bb.sky.com. [176.251.91.53])
	by mx.google.com with ESMTPS id x13sm11540384bkv.16.2012.09.25.03.56.57
	(version=SSLv3 cipher=OTHER); Tue, 25 Sep 2012 03:56:57 -0700 (PDT)
Message-ID: <50618DF5.5070400@xen.org>
Date: Tue, 25 Sep 2012 11:56:53 +0100
From: Lars Kurth <lars.kurth@xen.org>
User-Agent: Mozilla/5.0 (Windows NT 6.1;
	rv:15.0) Gecko/20120907 Thunderbird/15.0.1
MIME-Version: 1.0
To: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>, 
	xen-users@lists.xen.org, "xen-api@lists.xen.org" <xen-api@lists.xen.org>,
	xen-arm@lists.xen.org
Subject: [Xen-devel] Xen Document Day - Thank You!
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,

thank you for contributing to the Xen Document Day yesterday. I ran some 
stats, but may have missed some activities.

Wiki Changes:
1) 27039 words were changed on the Wiki for the document day
2) Contributors: Anthony, Dunlapg, GrantMcWilliams, Ijc, Lars.kurth, 
Lisa.Nguyen, Matthew.Spah, OliverChick, StefanoStabellini

Proposals:
1) A proposal by GrantMcWilliams to contribute xe man pages to the XCP 
codeline in xen.org (see 
http://lists.xen.org/archives/html/xen-api/2012-09/msg00053.html)
2) Additional requests for XL documentation by Matthias Blankenhaus for 
subsequent document days. I will add this proposal the Document Day TODO 
list. Matthias also volunteered to take ownership, but will need help.

Other changes:
1) Capability to build diagrams from source as part of the xen-unstable 
docs build
2) Diagrams being created and included into the wiki
3) A number of content patches to docs in the codeline (did not count 
lines of code) on XenStore, Scheduler, Schedop* and Xen ARM DT bindings

Thank you again for helping improve Xen Documentation.

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 Tue Sep 25 10:57:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 10:57:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGSp3-0005L6-KK; Tue, 25 Sep 2012 10:57:01 +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 1TGSp2-0005Kd-9S
	for xen-devel@lists.xen.org; Tue, 25 Sep 2012 10:57:00 +0000
Received: from [85.158.139.83:2485] by server-6.bemta-5.messagelabs.com id
	09/52-14717-AFD81605; Tue, 25 Sep 2012 10:56:58 +0000
X-Env-Sender: lars.kurth.xen@gmail.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1348570618!29182936!1
X-Originating-IP: [74.125.83.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14736 invoked from network); 25 Sep 2012 10:56:58 -0000
Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com)
	(74.125.83.45)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Sep 2012 10:56:58 -0000
Received: by eekb47 with SMTP id b47so1052260eek.32
	for <multiple recipients>; Tue, 25 Sep 2012 03:56:58 -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=Wpz1YTr79D0LTsK1sZB7lYaA1bWrLPrWrV8yAE991CU=;
	b=vseRFu1uSNOtf9x7j1adCKIILF8TDj4B58JR2XbiBpL+gXwR4kkbcCOXrIMjMjkU8i
	3G5E0xNAcfWV3SLIWjEYHXhujJBQ4zeyZc7bxOYqT15cQMya+EU3o2eeu45Q3pgWLPuc
	U8QCfcsFtk8MbMtDJpymH2dKTpmx2b9hU9dedD/6MS0CIjvNkfECmeBJV6AFRya9ZcbY
	ytD8XyWDcNyFoefc/xwr2FeTHTAyPi7wb8HbvHN/n89vDblS2fiOXDIRU2Qpzj5qT4ls
	bpHkzKFv7pw9H2C3aavkT0XCIikeDm55r2ZeKvXSCn3PoZge8cgQaBBD1Gul1hDRJ7Wf
	55LQ==
Received: by 10.14.173.9 with SMTP id u9mr18719241eel.8.1348570618190;
	Tue, 25 Sep 2012 03:56:58 -0700 (PDT)
Received: from [172.16.26.11] (b0fb5b35.bb.sky.com. [176.251.91.53])
	by mx.google.com with ESMTPS id x13sm11540384bkv.16.2012.09.25.03.56.57
	(version=SSLv3 cipher=OTHER); Tue, 25 Sep 2012 03:56:57 -0700 (PDT)
Message-ID: <50618DF5.5070400@xen.org>
Date: Tue, 25 Sep 2012 11:56:53 +0100
From: Lars Kurth <lars.kurth@xen.org>
User-Agent: Mozilla/5.0 (Windows NT 6.1;
	rv:15.0) Gecko/20120907 Thunderbird/15.0.1
MIME-Version: 1.0
To: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>, 
	xen-users@lists.xen.org, "xen-api@lists.xen.org" <xen-api@lists.xen.org>,
	xen-arm@lists.xen.org
Subject: [Xen-devel] Xen Document Day - Thank You!
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,

thank you for contributing to the Xen Document Day yesterday. I ran some 
stats, but may have missed some activities.

Wiki Changes:
1) 27039 words were changed on the Wiki for the document day
2) Contributors: Anthony, Dunlapg, GrantMcWilliams, Ijc, Lars.kurth, 
Lisa.Nguyen, Matthew.Spah, OliverChick, StefanoStabellini

Proposals:
1) A proposal by GrantMcWilliams to contribute xe man pages to the XCP 
codeline in xen.org (see 
http://lists.xen.org/archives/html/xen-api/2012-09/msg00053.html)
2) Additional requests for XL documentation by Matthias Blankenhaus for 
subsequent document days. I will add this proposal the Document Day TODO 
list. Matthias also volunteered to take ownership, but will need help.

Other changes:
1) Capability to build diagrams from source as part of the xen-unstable 
docs build
2) Diagrams being created and included into the wiki
3) A number of content patches to docs in the codeline (did not count 
lines of code) on XenStore, Scheduler, Schedop* and Xen ARM DT bindings

Thank you again for helping improve Xen Documentation.

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 Tue Sep 25 11:01:34 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 11:01:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGStH-0005nY-9o; Tue, 25 Sep 2012 11:01:23 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1TGStF-0005nO-7r
	for xen-devel@lists.xensource.com; Tue, 25 Sep 2012 11:01:21 +0000
Received: from [85.158.139.83:5461] by server-9.bemta-5.messagelabs.com id
	5B/F7-14846-00F81605; Tue, 25 Sep 2012 11:01:20 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1348570879!27748368!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTEwNzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23974 invoked from network); 25 Sep 2012 11:01:19 -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;
	25 Sep 2012 11:01:19 -0000
X-IronPort-AV: E=Sophos;i="4.80,481,1344211200"; d="scan'208";a="14746619"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Sep 2012 11:00: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.279.1;
	Tue, 25 Sep 2012 12:00:55 +0100
Message-ID: <1348570853.3452.198.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Tue, 25 Sep 2012 12:00:53 +0100
In-Reply-To: <alpine.DEB.2.02.1208221458020.15568@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1208141559360.21096@kaball.uk.xensource.com>
	<alpine.DEB.2.02.1208221213070.15568@kaball.uk.xensource.com>
	<1345642066.12501.6.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.02.1208221458020.15568@kaball.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] libxl/qemu-xen: use cache=writeback for IDE
 and cache=none for SCSI
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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-09-25 at 11:15 +0100, Stefano Stabellini wrote:
> I found this email in my draft mailbox, I must have forgotten to send it.
> 
> On Wed, 22 Aug 2012, Ian Campbell wrote:
> > On Wed, 2012-08-22 at 12:13 +0100, Stefano Stabellini wrote:
> > > On Tue, 14 Aug 2012, Stefano Stabellini wrote:
> > > > Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> > > 
> > > ping
> > 
> > Is this an appropriate change during rcs, is it critical for 4.2 or
> > should it wait for 4.3?
> 
> It should go in one of the 4.2.x releases.
> 
> 
> > I think the changelog here is rather lacking, which makes it hard for me
> > to decide what to do. e.g. the usual stuff: Why are you making this
> > change? What is the impact? etc
> 
> This patch makes QEMU upstream behave like QEMU traditional, that
> changed behavior at the same time this patch was sent
> (effd5676225761abdab90becac519716515c3be4).

Thanks, please can duplicate most of that commit message here as well
please, in particular the reference the ML thread. A reference to the
trad commit ID might be useful too.

> > What is the default for all these cases?
> 
> The default is writethrough, that is very slow.

Say "change caching mode from writethrough to writeback" in the commit
message? Mention that this is a performance issue.

> 
> > > > diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
> > > > index 0c0084f..1c94e80 100644
> > > > --- a/tools/libxl/libxl_dm.c
> > > > +++ b/tools/libxl/libxl_dm.c
> > > > @@ -549,10 +549,10 @@ static char ** libxl__build_device_model_args_new(libxl__gc *gc,
> > > >              if (disks[i].is_cdrom) {
> > > >                  if (disks[i].format == LIBXL_DISK_FORMAT_EMPTY)
> > > >                      drive = libxl__sprintf
> > > > -                        (gc, "if=ide,index=%d,media=cdrom", disk);
> > > > +                        (gc, "if=ide,index=%d,media=cdrom,cache=writeback", disk);
> > 
> > Why does the cacheability matter for an empty device?
> 
> It doesn't but the default would stay the same when a cdrom is inserted
> (it is a property of the drive).

OK.

> > > >                  else
> > > >                      drive = libxl__sprintf
> > > > -                        (gc, "file=%s,if=ide,index=%d,media=cdrom,format=%s",
> > > > +                        (gc, "file=%s,if=ide,index=%d,media=cdrom,format=%s,cache=writeback",
> > 
> > Does writeback mean anything for a r/o device?
> 
> I doesn't. Do you want me to resend without this hunk?

Up to you. I guess it is at least consistent with the other devices. (it
feels like this same line is repeated a lot, but lets not tackle that
here)

> > > >                           disks[i].pdev_path, disk, format);
> > > >              } else {
> > > >                  if (disks[i].format == LIBXL_DISK_FORMAT_EMPTY) {
> > > > @@ -575,11 +575,11 @@ static char ** libxl__build_device_model_args_new(libxl__gc *gc,
> > > >                   */
> > > >                  if (strncmp(disks[i].vdev, "sd", 2) == 0)
> > > >                      drive = libxl__sprintf
> > > > -                        (gc, "file=%s,if=scsi,bus=0,unit=%d,format=%s",
> > > > +                        (gc, "file=%s,if=scsi,bus=0,unit=%d,format=%s,cache=none",
> > > >                           disks[i].pdev_path, disk, format);
> > > >                  else if (disk < 4)
> > > >                      drive = libxl__sprintf
> > > > -                        (gc, "file=%s,if=ide,index=%d,media=disk,format=%s",
> > > > +                        (gc, "file=%s,if=ide,index=%d,media=disk,format=%s,cache=writeback",
> > 
> > Why is an SCSI disk treated differently to an IDE one wrt caching?
> > 
> 
> We chose writeback for IDE because IDE has an explicit flush command
> that the guest is going to issue when it wants the data to reach the disk.
> At that point we can do a datasync on the filesystem.
> I don't know enough about SCSI to be sure that is the case there as
> well, so I wanted to stay on the safe side and chose cache=none instead
> (that means O_DIRECT).

I'm pretty sure SCSI must have an explicit flush command as well
although it might be nice if someone could confirm. And also check that
qemu actually flushes...

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 25 11:01:34 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 11:01:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGStH-0005nY-9o; Tue, 25 Sep 2012 11:01:23 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1TGStF-0005nO-7r
	for xen-devel@lists.xensource.com; Tue, 25 Sep 2012 11:01:21 +0000
Received: from [85.158.139.83:5461] by server-9.bemta-5.messagelabs.com id
	5B/F7-14846-00F81605; Tue, 25 Sep 2012 11:01:20 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1348570879!27748368!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTEwNzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23974 invoked from network); 25 Sep 2012 11:01:19 -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;
	25 Sep 2012 11:01:19 -0000
X-IronPort-AV: E=Sophos;i="4.80,481,1344211200"; d="scan'208";a="14746619"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Sep 2012 11:00: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.279.1;
	Tue, 25 Sep 2012 12:00:55 +0100
Message-ID: <1348570853.3452.198.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Tue, 25 Sep 2012 12:00:53 +0100
In-Reply-To: <alpine.DEB.2.02.1208221458020.15568@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1208141559360.21096@kaball.uk.xensource.com>
	<alpine.DEB.2.02.1208221213070.15568@kaball.uk.xensource.com>
	<1345642066.12501.6.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.02.1208221458020.15568@kaball.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] libxl/qemu-xen: use cache=writeback for IDE
 and cache=none for SCSI
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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-09-25 at 11:15 +0100, Stefano Stabellini wrote:
> I found this email in my draft mailbox, I must have forgotten to send it.
> 
> On Wed, 22 Aug 2012, Ian Campbell wrote:
> > On Wed, 2012-08-22 at 12:13 +0100, Stefano Stabellini wrote:
> > > On Tue, 14 Aug 2012, Stefano Stabellini wrote:
> > > > Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> > > 
> > > ping
> > 
> > Is this an appropriate change during rcs, is it critical for 4.2 or
> > should it wait for 4.3?
> 
> It should go in one of the 4.2.x releases.
> 
> 
> > I think the changelog here is rather lacking, which makes it hard for me
> > to decide what to do. e.g. the usual stuff: Why are you making this
> > change? What is the impact? etc
> 
> This patch makes QEMU upstream behave like QEMU traditional, that
> changed behavior at the same time this patch was sent
> (effd5676225761abdab90becac519716515c3be4).

Thanks, please can duplicate most of that commit message here as well
please, in particular the reference the ML thread. A reference to the
trad commit ID might be useful too.

> > What is the default for all these cases?
> 
> The default is writethrough, that is very slow.

Say "change caching mode from writethrough to writeback" in the commit
message? Mention that this is a performance issue.

> 
> > > > diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
> > > > index 0c0084f..1c94e80 100644
> > > > --- a/tools/libxl/libxl_dm.c
> > > > +++ b/tools/libxl/libxl_dm.c
> > > > @@ -549,10 +549,10 @@ static char ** libxl__build_device_model_args_new(libxl__gc *gc,
> > > >              if (disks[i].is_cdrom) {
> > > >                  if (disks[i].format == LIBXL_DISK_FORMAT_EMPTY)
> > > >                      drive = libxl__sprintf
> > > > -                        (gc, "if=ide,index=%d,media=cdrom", disk);
> > > > +                        (gc, "if=ide,index=%d,media=cdrom,cache=writeback", disk);
> > 
> > Why does the cacheability matter for an empty device?
> 
> It doesn't but the default would stay the same when a cdrom is inserted
> (it is a property of the drive).

OK.

> > > >                  else
> > > >                      drive = libxl__sprintf
> > > > -                        (gc, "file=%s,if=ide,index=%d,media=cdrom,format=%s",
> > > > +                        (gc, "file=%s,if=ide,index=%d,media=cdrom,format=%s,cache=writeback",
> > 
> > Does writeback mean anything for a r/o device?
> 
> I doesn't. Do you want me to resend without this hunk?

Up to you. I guess it is at least consistent with the other devices. (it
feels like this same line is repeated a lot, but lets not tackle that
here)

> > > >                           disks[i].pdev_path, disk, format);
> > > >              } else {
> > > >                  if (disks[i].format == LIBXL_DISK_FORMAT_EMPTY) {
> > > > @@ -575,11 +575,11 @@ static char ** libxl__build_device_model_args_new(libxl__gc *gc,
> > > >                   */
> > > >                  if (strncmp(disks[i].vdev, "sd", 2) == 0)
> > > >                      drive = libxl__sprintf
> > > > -                        (gc, "file=%s,if=scsi,bus=0,unit=%d,format=%s",
> > > > +                        (gc, "file=%s,if=scsi,bus=0,unit=%d,format=%s,cache=none",
> > > >                           disks[i].pdev_path, disk, format);
> > > >                  else if (disk < 4)
> > > >                      drive = libxl__sprintf
> > > > -                        (gc, "file=%s,if=ide,index=%d,media=disk,format=%s",
> > > > +                        (gc, "file=%s,if=ide,index=%d,media=disk,format=%s,cache=writeback",
> > 
> > Why is an SCSI disk treated differently to an IDE one wrt caching?
> > 
> 
> We chose writeback for IDE because IDE has an explicit flush command
> that the guest is going to issue when it wants the data to reach the disk.
> At that point we can do a datasync on the filesystem.
> I don't know enough about SCSI to be sure that is the case there as
> well, so I wanted to stay on the safe side and chose cache=none instead
> (that means O_DIRECT).

I'm pretty sure SCSI must have an explicit flush command as well
although it might be nice if someone could confirm. And also check that
qemu actually flushes...

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 25 11:35:39 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 11:35:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGTQ3-0006LB-5k; Tue, 25 Sep 2012 11:35:15 +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 1TGTQ1-0006Ks-Tm
	for xen-devel@lists.xen.org; Tue, 25 Sep 2012 11:35:14 +0000
Received: from [85.158.137.99:31263] by server-14.bemta-3.messagelabs.com id
	9E/26-21431-1F691605; Tue, 25 Sep 2012 11:35:13 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-16.tower-217.messagelabs.com!1348572911!19038354!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA1MTM1OTg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21365 invoked from network); 25 Sep 2012 11:35:12 -0000
Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25)
	by server-16.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 25 Sep 2012 11:35: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 C5AC1181C;
	Tue, 25 Sep 2012 14:35:10 +0300 (EEST)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id 3152C20061; Tue, 25 Sep 2012 14:35:10 +0300 (EEST)
Date: Tue, 25 Sep 2012 14:35:10 +0300
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120925113510.GM8912@reaktio.net>
References: <201208281225.q7SCP1WO017490@wind.enjellic.com>
	<1346226868.4847.21.camel@dagon.hellion.org.uk>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1346226868.4847.21.camel@dagon.hellion.org.uk>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: "greg@enjellic.com" <greg@enjellic.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] XEN 4.1.3 blktap2 patches.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Aug 29, 2012 at 08:54:28AM +0100, Ian Campbell wrote:
> On Tue, 2012-08-28 at 13:25 +0100, Dr. Greg Wettstein wrote:
> > Good morning, hope the day is going well for everyone.
> > 
> > The patches to fix the blktap2 issues which result in orphaned
> > tapdisk2 processes and the transitory deadlock on guest shutdown
> > didn't make it into the 4.1.3 release.  Updated patches to address
> > these problems are available at the following location:
> > 
> > 	ftp://ftp.enjellic.com/pub/xen/xen-4.1.3.blktap1.patch
> > 	ftp://ftp.enjellic.com/pub/xen/xen-4.1.3.blktap2.patch
> > 
> > The patches are designed to be applied in order and have been verified
> > to work against the 4.1.3 release.
> 
> Please can you post these patches as emails with a changelog and a
> signed-off-by. You should also CC Ian Jackson since he is the one who
> does the tools backports.
>

Hello again,

Dr. Greg: Can you please re-post the patches as emails with Signed-off-by lines included,
as suggested below in Ian's reply.. ? 

http://wiki.xen.org/wiki/Submitting_Xen_Patches

Thanks!

-- Pasi
 
> The changelog should be clear about the backport status. IIRC one of
> these is a backport from unstable (so the changelog should say of which
> commit and preserve the original S-o-b) and the other is a
> reimplementation since too much has changed in unstable so there is no
> plausible backport (and the changelog should mention this).
> 
> Ideally these mails would be threaded with subjects "[PATCH 1/2] ..."
> and "[PATCH 2/2] ..." so that it is obvious that there is a sequence to
> them. A tool such as hg email will do this for you.
> http://wiki.xen.org/wiki/Submitting_Xen_Patches has some hints on how to
> use it.
> 
> If nothing has changed since the previous posting it may be sufficient
> to reply to that previous postings with a "ping" message and CC Ian
> there.
> 
> Ian.
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 25 11:35:39 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 11:35:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGTQ3-0006LB-5k; Tue, 25 Sep 2012 11:35:15 +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 1TGTQ1-0006Ks-Tm
	for xen-devel@lists.xen.org; Tue, 25 Sep 2012 11:35:14 +0000
Received: from [85.158.137.99:31263] by server-14.bemta-3.messagelabs.com id
	9E/26-21431-1F691605; Tue, 25 Sep 2012 11:35:13 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-16.tower-217.messagelabs.com!1348572911!19038354!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA1MTM1OTg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21365 invoked from network); 25 Sep 2012 11:35:12 -0000
Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25)
	by server-16.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 25 Sep 2012 11:35: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 C5AC1181C;
	Tue, 25 Sep 2012 14:35:10 +0300 (EEST)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id 3152C20061; Tue, 25 Sep 2012 14:35:10 +0300 (EEST)
Date: Tue, 25 Sep 2012 14:35:10 +0300
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120925113510.GM8912@reaktio.net>
References: <201208281225.q7SCP1WO017490@wind.enjellic.com>
	<1346226868.4847.21.camel@dagon.hellion.org.uk>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1346226868.4847.21.camel@dagon.hellion.org.uk>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: "greg@enjellic.com" <greg@enjellic.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] XEN 4.1.3 blktap2 patches.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Aug 29, 2012 at 08:54:28AM +0100, Ian Campbell wrote:
> On Tue, 2012-08-28 at 13:25 +0100, Dr. Greg Wettstein wrote:
> > Good morning, hope the day is going well for everyone.
> > 
> > The patches to fix the blktap2 issues which result in orphaned
> > tapdisk2 processes and the transitory deadlock on guest shutdown
> > didn't make it into the 4.1.3 release.  Updated patches to address
> > these problems are available at the following location:
> > 
> > 	ftp://ftp.enjellic.com/pub/xen/xen-4.1.3.blktap1.patch
> > 	ftp://ftp.enjellic.com/pub/xen/xen-4.1.3.blktap2.patch
> > 
> > The patches are designed to be applied in order and have been verified
> > to work against the 4.1.3 release.
> 
> Please can you post these patches as emails with a changelog and a
> signed-off-by. You should also CC Ian Jackson since he is the one who
> does the tools backports.
>

Hello again,

Dr. Greg: Can you please re-post the patches as emails with Signed-off-by lines included,
as suggested below in Ian's reply.. ? 

http://wiki.xen.org/wiki/Submitting_Xen_Patches

Thanks!

-- Pasi
 
> The changelog should be clear about the backport status. IIRC one of
> these is a backport from unstable (so the changelog should say of which
> commit and preserve the original S-o-b) and the other is a
> reimplementation since too much has changed in unstable so there is no
> plausible backport (and the changelog should mention this).
> 
> Ideally these mails would be threaded with subjects "[PATCH 1/2] ..."
> and "[PATCH 2/2] ..." so that it is obvious that there is a sequence to
> them. A tool such as hg email will do this for you.
> http://wiki.xen.org/wiki/Submitting_Xen_Patches has some hints on how to
> use it.
> 
> If nothing has changed since the previous posting it may be sufficient
> to reply to that previous postings with a "ping" message and CC Ian
> there.
> 
> Ian.
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 25 11:54:46 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 11:54:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGTic-0006a2-Uj; Tue, 25 Sep 2012 11:54:26 +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 1TGTib-0006Zx-1c
	for xen-devel@lists.xensource.com; Tue, 25 Sep 2012 11:54:25 +0000
Received: from [85.158.139.211:48222] by server-12.bemta-5.messagelabs.com id
	E1/D7-20729-07B91605; Tue, 25 Sep 2012 11:54:24 +0000
X-Env-Sender: Christoph.Egger@amd.com
X-Msg-Ref: server-12.tower-206.messagelabs.com!1348574062!18881554!1
X-Originating-IP: [65.55.88.11]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11164 invoked from network); 25 Sep 2012 11:54:23 -0000
Received: from tx2ehsobe001.messaging.microsoft.com (HELO
	tx2outboundpool.messaging.microsoft.com) (65.55.88.11)
	by server-12.tower-206.messagelabs.com with AES128-SHA encrypted SMTP;
	25 Sep 2012 11:54:23 -0000
Received: from mail181-tx2-R.bigfish.com (10.9.14.252) by
	TX2EHSOBE009.bigfish.com (10.9.40.29) with Microsoft SMTP Server id
	14.1.225.23; Tue, 25 Sep 2012 11:54:21 +0000
Received: from mail181-tx2 (localhost [127.0.0.1])	by
	mail181-tx2-R.bigfish.com (Postfix) with ESMTP id B3F461A00D9;
	Tue, 25 Sep 2012 11:54:21 +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: -2
X-BigFish: VPS-2(zzbb2dI98dI1432Id6f1izz1202h1d1ah1d2ahzz8275bhz2dh668h839hd25he5bhf0ah107ah1288h12a5h12a9h12bdh137ah13b6h1155h)
Received: from mail181-tx2 (localhost.localdomain [127.0.0.1]) by mail181-tx2
	(MessageSwitch) id 1348574059786506_22711;
	Tue, 25 Sep 2012 11:54:19 +0000 (UTC)
Received: from TX2EHSMHS007.bigfish.com (unknown [10.9.14.241])	by
	mail181-tx2.bigfish.com (Postfix) with ESMTP id BBFA0420048;
	Tue, 25 Sep 2012 11:54:19 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	TX2EHSMHS007.bigfish.com (10.9.99.107) with Microsoft SMTP Server id
	14.1.225.23; Tue, 25 Sep 2012 11:54:14 +0000
X-WSS-ID: 0MAWMEC-01-BP3-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 2C2941028038;	Tue, 25 Sep 2012 06:54:12 -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;
	Tue, 25 Sep 2012 06:54:21 -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;
	Tue, 25 Sep 2012 06:54:12 -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; Tue, 25 Sep 2012
	07:54:11 -0400
Message-ID: <50619B61.2030609@amd.com>
Date: Tue, 25 Sep 2012 13:54:09 +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: Jan Beulich <JBeulich@suse.com>
References: <DE8DF0795D48FD4CA783C40EC8292335339547@SHSMSX101.ccr.corp.intel.com>
	<506173FB.8070603@amd.com>
	<5061A833020000780009DA1A@nat28.tlf.novell.com>
In-Reply-To: <5061A833020000780009DA1A@nat28.tlf.novell.com>
X-OriginatorOrg: amd.com
Cc: Jinsong Liu <jinsong.liu@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"keir@xen.org" <keir@xen.org>,
	"Ian.Campbell@citrix.com" <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH 6] X86/MCE: update vMCE injection for AMD
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 09/25/12 12:48, Jan Beulich wrote:

>>>> On 25.09.12 at 11:06, Christoph Egger <Christoph.Egger@amd.com> wrote:
>> On 09/25/12 07:00, Liu, Jinsong wrote:
>>
>>> X86/MCE: update vMCE injection for AMD
>>>
>>> For Intel MCE, it broadcasts vMCE to all vcpus. For AMD MCE, it injects
>>> vMCE only to vcpu0. This patch update inject_vmce for AMD.
>>>
>>> Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>
>>> Suggested_by: Christoph Egger <Christoph.Egger@amd.com>
>>
>>
>> Acked-by: Christoph Egger <Christoph.Egger@amd.com>
> 
> Are you sure (see below)?

Yes, see below.

>>> diff -r a6d12a1bc758 xen/arch/x86/cpu/mcheck/mce.h
>>> --- a/xen/arch/x86/cpu/mcheck/mce.h	Thu Sep 20 00:03:25 2012 +0800
>>> +++ b/xen/arch/x86/cpu/mcheck/mce.h	Tue Sep 25 19:52:20 2012 +0800
>>> @@ -168,7 +168,7 @@
>>>  
>>>  int fill_vmsr_data(struct mcinfo_bank *mc_bank, struct domain *d,
>>>      uint64_t gstatus);
>>> -int inject_vmce(struct domain *d);
>>> +int inject_vmce(struct domain *d, bool_t vmce_broadcast);
>>>  
>>>  static inline int mce_vendor_bank_msr(const struct vcpu *v, uint32_t msr)
>>>  {
>>> diff -r a6d12a1bc758 xen/arch/x86/cpu/mcheck/mce_intel.c
>>> --- a/xen/arch/x86/cpu/mcheck/mce_intel.c	Thu Sep 20 00:03:25 2012 +0800
>>> +++ b/xen/arch/x86/cpu/mcheck/mce_intel.c	Tue Sep 25 19:52:20 2012 +0800
>>> @@ -365,7 +365,7 @@
>>>                  }
>>>  
>>>                  /* We will inject vMCE to DOMU*/
>>> -                if ( inject_vmce(d) < 0 )
>>> +                if ( inject_vmce(d, 1) < 0 )
>>>                  {
>>>                      mce_printk(MCE_QUIET, "inject vMCE to DOM%d"
>>>                        " failed\n", d->domain_id);
>>> diff -r a6d12a1bc758 xen/arch/x86/cpu/mcheck/vmce.c
>>> --- a/xen/arch/x86/cpu/mcheck/vmce.c	Thu Sep 20 00:03:25 2012 +0800
>>> +++ b/xen/arch/x86/cpu/mcheck/vmce.c	Tue Sep 25 19:52:20 2012 +0800
>>> @@ -344,11 +344,14 @@
>>>  HVM_REGISTER_SAVE_RESTORE(VMCE_VCPU, vmce_save_vcpu_ctxt,
>>>                            vmce_load_vcpu_ctxt, 1, HVMSR_PER_VCPU);
>>>  
>>> -int inject_vmce(struct domain *d)
>>> +/* 
>>> + * for Intel MCE, broadcast vMCE to all vcpus
>>> + * for AMD MCE, only inject vMCE to vcpu0
>>> + */
>>> +int inject_vmce(struct domain *d, bool_t vmce_broadcast)
>>>  {
>>>      struct vcpu *v;
>>>  
>>> -    /* inject vMCE to all vcpus */
>>>      for_each_vcpu(d, v)
>>>      {
>>>          if ( !test_and_set_bool(v->mce_pending) &&
>>> @@ -365,6 +368,9 @@
>>>                         d->domain_id, v->vcpu_id);
>>>              return -1;
>>>          }
>>> +
>>> +        if ( !vmce_broadcast )
>>> +            break;
> 
> That'll allow (non-broadcast) injection to vCPU 0 only - is that
> really the right thing to do?


On AMD side memory errors are found by the northbridge and the first
cpu-core reports this. As long as we do not have NUMA support for the
guest this is fine.

> I.e. shouldn't the caller rather be given flexibility to specify
> which vCPU this is to go to (with a negative value meaning broadcast)?

This is a good idea. Go for it.


> And I'm intending to fold this into patch 2 anyway before
> committing.


Yes, please.

Christoph

-- 
---to satisfy European Law for business letters:
Advanced Micro Devices GmbH
Einsteinring 24, 85689 Dornach b. Muenchen
Geschaeftsfuehrer: Alberto Bozzo
Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen
Registergericht Muenchen, HRB Nr. 43632


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 25 11:54:46 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 11:54:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGTic-0006a2-Uj; Tue, 25 Sep 2012 11:54:26 +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 1TGTib-0006Zx-1c
	for xen-devel@lists.xensource.com; Tue, 25 Sep 2012 11:54:25 +0000
Received: from [85.158.139.211:48222] by server-12.bemta-5.messagelabs.com id
	E1/D7-20729-07B91605; Tue, 25 Sep 2012 11:54:24 +0000
X-Env-Sender: Christoph.Egger@amd.com
X-Msg-Ref: server-12.tower-206.messagelabs.com!1348574062!18881554!1
X-Originating-IP: [65.55.88.11]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11164 invoked from network); 25 Sep 2012 11:54:23 -0000
Received: from tx2ehsobe001.messaging.microsoft.com (HELO
	tx2outboundpool.messaging.microsoft.com) (65.55.88.11)
	by server-12.tower-206.messagelabs.com with AES128-SHA encrypted SMTP;
	25 Sep 2012 11:54:23 -0000
Received: from mail181-tx2-R.bigfish.com (10.9.14.252) by
	TX2EHSOBE009.bigfish.com (10.9.40.29) with Microsoft SMTP Server id
	14.1.225.23; Tue, 25 Sep 2012 11:54:21 +0000
Received: from mail181-tx2 (localhost [127.0.0.1])	by
	mail181-tx2-R.bigfish.com (Postfix) with ESMTP id B3F461A00D9;
	Tue, 25 Sep 2012 11:54:21 +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: -2
X-BigFish: VPS-2(zzbb2dI98dI1432Id6f1izz1202h1d1ah1d2ahzz8275bhz2dh668h839hd25he5bhf0ah107ah1288h12a5h12a9h12bdh137ah13b6h1155h)
Received: from mail181-tx2 (localhost.localdomain [127.0.0.1]) by mail181-tx2
	(MessageSwitch) id 1348574059786506_22711;
	Tue, 25 Sep 2012 11:54:19 +0000 (UTC)
Received: from TX2EHSMHS007.bigfish.com (unknown [10.9.14.241])	by
	mail181-tx2.bigfish.com (Postfix) with ESMTP id BBFA0420048;
	Tue, 25 Sep 2012 11:54:19 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	TX2EHSMHS007.bigfish.com (10.9.99.107) with Microsoft SMTP Server id
	14.1.225.23; Tue, 25 Sep 2012 11:54:14 +0000
X-WSS-ID: 0MAWMEC-01-BP3-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 2C2941028038;	Tue, 25 Sep 2012 06:54:12 -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;
	Tue, 25 Sep 2012 06:54:21 -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;
	Tue, 25 Sep 2012 06:54:12 -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; Tue, 25 Sep 2012
	07:54:11 -0400
Message-ID: <50619B61.2030609@amd.com>
Date: Tue, 25 Sep 2012 13:54:09 +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: Jan Beulich <JBeulich@suse.com>
References: <DE8DF0795D48FD4CA783C40EC8292335339547@SHSMSX101.ccr.corp.intel.com>
	<506173FB.8070603@amd.com>
	<5061A833020000780009DA1A@nat28.tlf.novell.com>
In-Reply-To: <5061A833020000780009DA1A@nat28.tlf.novell.com>
X-OriginatorOrg: amd.com
Cc: Jinsong Liu <jinsong.liu@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"keir@xen.org" <keir@xen.org>,
	"Ian.Campbell@citrix.com" <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH 6] X86/MCE: update vMCE injection for AMD
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 09/25/12 12:48, Jan Beulich wrote:

>>>> On 25.09.12 at 11:06, Christoph Egger <Christoph.Egger@amd.com> wrote:
>> On 09/25/12 07:00, Liu, Jinsong wrote:
>>
>>> X86/MCE: update vMCE injection for AMD
>>>
>>> For Intel MCE, it broadcasts vMCE to all vcpus. For AMD MCE, it injects
>>> vMCE only to vcpu0. This patch update inject_vmce for AMD.
>>>
>>> Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>
>>> Suggested_by: Christoph Egger <Christoph.Egger@amd.com>
>>
>>
>> Acked-by: Christoph Egger <Christoph.Egger@amd.com>
> 
> Are you sure (see below)?

Yes, see below.

>>> diff -r a6d12a1bc758 xen/arch/x86/cpu/mcheck/mce.h
>>> --- a/xen/arch/x86/cpu/mcheck/mce.h	Thu Sep 20 00:03:25 2012 +0800
>>> +++ b/xen/arch/x86/cpu/mcheck/mce.h	Tue Sep 25 19:52:20 2012 +0800
>>> @@ -168,7 +168,7 @@
>>>  
>>>  int fill_vmsr_data(struct mcinfo_bank *mc_bank, struct domain *d,
>>>      uint64_t gstatus);
>>> -int inject_vmce(struct domain *d);
>>> +int inject_vmce(struct domain *d, bool_t vmce_broadcast);
>>>  
>>>  static inline int mce_vendor_bank_msr(const struct vcpu *v, uint32_t msr)
>>>  {
>>> diff -r a6d12a1bc758 xen/arch/x86/cpu/mcheck/mce_intel.c
>>> --- a/xen/arch/x86/cpu/mcheck/mce_intel.c	Thu Sep 20 00:03:25 2012 +0800
>>> +++ b/xen/arch/x86/cpu/mcheck/mce_intel.c	Tue Sep 25 19:52:20 2012 +0800
>>> @@ -365,7 +365,7 @@
>>>                  }
>>>  
>>>                  /* We will inject vMCE to DOMU*/
>>> -                if ( inject_vmce(d) < 0 )
>>> +                if ( inject_vmce(d, 1) < 0 )
>>>                  {
>>>                      mce_printk(MCE_QUIET, "inject vMCE to DOM%d"
>>>                        " failed\n", d->domain_id);
>>> diff -r a6d12a1bc758 xen/arch/x86/cpu/mcheck/vmce.c
>>> --- a/xen/arch/x86/cpu/mcheck/vmce.c	Thu Sep 20 00:03:25 2012 +0800
>>> +++ b/xen/arch/x86/cpu/mcheck/vmce.c	Tue Sep 25 19:52:20 2012 +0800
>>> @@ -344,11 +344,14 @@
>>>  HVM_REGISTER_SAVE_RESTORE(VMCE_VCPU, vmce_save_vcpu_ctxt,
>>>                            vmce_load_vcpu_ctxt, 1, HVMSR_PER_VCPU);
>>>  
>>> -int inject_vmce(struct domain *d)
>>> +/* 
>>> + * for Intel MCE, broadcast vMCE to all vcpus
>>> + * for AMD MCE, only inject vMCE to vcpu0
>>> + */
>>> +int inject_vmce(struct domain *d, bool_t vmce_broadcast)
>>>  {
>>>      struct vcpu *v;
>>>  
>>> -    /* inject vMCE to all vcpus */
>>>      for_each_vcpu(d, v)
>>>      {
>>>          if ( !test_and_set_bool(v->mce_pending) &&
>>> @@ -365,6 +368,9 @@
>>>                         d->domain_id, v->vcpu_id);
>>>              return -1;
>>>          }
>>> +
>>> +        if ( !vmce_broadcast )
>>> +            break;
> 
> That'll allow (non-broadcast) injection to vCPU 0 only - is that
> really the right thing to do?


On AMD side memory errors are found by the northbridge and the first
cpu-core reports this. As long as we do not have NUMA support for the
guest this is fine.

> I.e. shouldn't the caller rather be given flexibility to specify
> which vCPU this is to go to (with a negative value meaning broadcast)?

This is a good idea. Go for it.


> And I'm intending to fold this into patch 2 anyway before
> committing.


Yes, please.

Christoph

-- 
---to satisfy European Law for business letters:
Advanced Micro Devices GmbH
Einsteinring 24, 85689 Dornach b. Muenchen
Geschaeftsfuehrer: Alberto Bozzo
Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen
Registergericht Muenchen, HRB Nr. 43632


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 25 11:58:06 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 11: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 1TGTls-0006iC-Mj; Tue, 25 Sep 2012 11:57:48 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ben.guthro@gmail.com>) id 1TGTlq-0006hq-Mt
	for xen-devel@lists.xen.org; Tue, 25 Sep 2012 11:57:47 +0000
X-Env-Sender: ben.guthro@gmail.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1348574180!8591913!1
X-Originating-IP: [209.85.223.173]
X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_20_30,HTML_MESSAGE,
	RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8211 invoked from network); 25 Sep 2012 11:56:34 -0000
Received: from mail-ie0-f173.google.com (HELO mail-ie0-f173.google.com)
	(209.85.223.173)
	by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Sep 2012 11:56:34 -0000
Received: by iea17 with SMTP id 17so11160445iea.32
	for <xen-devel@lists.xen.org>; Tue, 25 Sep 2012 04:56: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=kVhMotb0VApXqKTbgeaFsvfdcKTsVZZDdvVQovLWEws=;
	b=OhxY+Y7UjfNF4sSDh9pCTGhuHnK5CSqKyZIfr4yb4fhbTmIO3sjPEWWFLOmlXHRe1q
	DncrIFMOklslizuLi5UcJ5AbJmOMnzO2lRMzMQMrTUxqfhDWqTArPJihnyUvh/WQiFbG
	qSvmk3XEj8C8/B1PcD7MOmwC1zu/NRQWdA6MJINWdxMGTZUkHGLfay4f4hlsBnCrd4d+
	Q7apzH++BNuhBG5jmBOQRMaVNxXc0CGXqa4uLcw4J0VBtYkzUyV+E7eo80r8TGy/XEj7
	Ril6B+oTXSAYX5WpLTyqerMU2xwd+ICFGGKhUuwPPm6mxaUE37i9KtGXahZ9Ln8h6KTj
	ErVQ==
MIME-Version: 1.0
Received: by 10.50.190.230 with SMTP id gt6mr7878096igc.49.1348574180289; Tue,
	25 Sep 2012 04:56:20 -0700 (PDT)
Received: by 10.64.55.132 with HTTP; Tue, 25 Sep 2012 04:56:20 -0700 (PDT)
In-Reply-To: <50617297020000780009D8AA@nat28.tlf.novell.com>
References: <CAOvdn6UCF2A3yP1cqWn=dxwr0ayRbr+rg+xj8META9Dm0+CoNw@mail.gmail.com>
	<CC868168.3FD29%keir.xen@gmail.com>
	<CAOvdn6U-JyLvt96gkLkqzi088tU9_ktv4D+fkJac_BKVe05Y-w@mail.gmail.com>
	<CAOvdn6V+s3AbRzsu8VArbmrZou=im9SqvPf-9Wpif_BrNMv=yg@mail.gmail.com>
	<50617297020000780009D8AA@nat28.tlf.novell.com>
Date: Tue, 25 Sep 2012 07:56:20 -0400
X-Google-Sender-Auth: XutSemJddYXZUuh0y-NphFf_Hww
Message-ID: <CAOvdn6Vsnbcd7m8mh3tSgn3KaEoeiOyVD1mr3uQ3bN=rF=pDUQ@mail.gmail.com>
From: Ben Guthro <ben@guthro.net>
To: Jan Beulich <JBeulich@suse.com>
Cc: Keir Fraser <keir.xen@gmail.com>, John Baboval <john.baboval@citrix.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen4.2 S3 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: multipart/mixed; boundary="===============8137127006307440570=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============8137127006307440570==
Content-Type: multipart/alternative; boundary=14dae93406bbf82bf504ca8564c6

--14dae93406bbf82bf504ca8564c6
Content-Type: text/plain; charset=ISO-8859-1

On Tue, Sep 25, 2012 at 3:00 AM, Jan Beulich <JBeulich@suse.com> wrote:

> >>> On 24.09.12 at 23:12, Ben Guthro <ben@guthro.net> wrote:
> > Here's my "Big hammer" debugging patch.
> >
> > If I force the cpu to be scheduled on CPU0 when the appropriate cpu is
> not
> > online, I can resume properly.
> >
> > Clearly this is not the proper solution, and I'm sure the fix is subtle.
> > I'm not seeing it right now though. Perhaps tomorrow morning.
> > If you have any ideas, I'm happy to run tests then.
>
> I can't see how the printk() you add in the patch would ever get
> reached with the other adjustment you do there.


Apologies. I failed to separate prior debugging in this patch from the "big
hammer" fix


> A debug build,
> as Keir suggested, would not only get the stack trace right, but
> would also result in the ASSERT() right after your first modification
> to _csched_cpu_pick() to actually do something (and likely trigger).
>

Indeed. I was using non-debug builds for 2 reasons that, in hindsight may
not be the best of reasons.
1. It was the default
2. Mukesh's kdb debugger requires debug to be off, which I was making use
of previously, and had not disabled.

The stack from a debug build can be found below.
It did, indeed trigger the ASSERT, as you predicted.


(XEN) Finishing wakeup from ACPI S3 state.
(XEN) Enabling non-boot CPUs  ...
(XEN) Booting processor 1/1 eip 8a000
(XEN) Initializing CPU#1
(XEN) CPU: L1 I cache: 32K, L1 D cache: 32K
(XEN) CPU: L2 cache: 3072K
(XEN) CPU: Physical Processor ID: 0
(XEN) CPU: Processor Core ID: 1
(XEN) CMCI: CPU1 has no CMCI support
(XEN) CPU1: Thermal monitoring enabled (TM2)
(XEN) CPU1: Intel(R) Core(TM)2 Duo CPU     P8400  @ 2.26GHz stepping 06
(XEN) microcode: CPU1 updated from revision 0x60c to 0x60f, date =
2010-09-29
[   82.310025] ACPI: Low-level resume complete
[   82.310025] PM: Restoring platform NVS memory
[   82.310025] Enabling non-boot CPUs ...
[   82.310025] installing Xen timer for CPU 1
[   82.310025] cpu 1 spinlock event irq 279
(XEN) Assertion '!cpumask_empty(&cpus) && cpumask_test_cpu(cpu, &cpus)'
failed at sched_credit.c:477
(XEN) ----[ Xen-4.2.1-pre  x86_64  debug=y  Tainted:    C ]----
(XEN) CPU:    1
(XEN) RIP:    e008:[<ffff82c48011a35a>] _csched_cpu_pick+0x135/0x552
(XEN) RFLAGS: 0000000000010002   CONTEXT: hypervisor
(XEN) rax: 0000000000000001   rbx: 0000000000000004   rcx: 0000000000000004
(XEN) rdx: 000000000000000f   rsi: 0000000000000004   rdi: 0000000000000000
(XEN) rbp: ffff8301355d7dd8   rsp: ffff8301355d7d08   r8:  0000000000000000
(XEN) r9:  000000000000003e   r10: ffff82c480231700   r11: 0000000000000246
(XEN) r12: ffff82c480261b20   r13: 0000000000000001   r14: ffff82c480301a60
(XEN) r15: ffff83013a542068   cr0: 000000008005003b   cr4: 00000000000026f0
(XEN) cr3: 0000000131a05000   cr2: 0000000000000000
(XEN) ds: 002b   es: 002b   fs: 0000   gs: 0000   ss: e010   cs: e008
(XEN) Xen stack trace from rsp=ffff8301355d7d08:
(XEN)    0100000131a05000 ffff8301355d7d40 0000000000000082 0000000000000002
(XEN)    ffff8300bd503000 0000000000000001 0000000000000297 ffff8301355d7d58
(XEN)    ffff82c480125499 ffff830138216000 ffff8301355d7d98 5400000000000002
(XEN)    0000000000000286 ffff8301355d7d88 ffff82c480125499 ffff830138216000
(XEN)    0000000000000000 0000000000000000 0000000000000000 0000000000000000
(XEN)    ffff830134ca6a50 ffff83013a542068 ffff83013a542068 0000000000000001
(XEN)    ffff82c480301a60 ffff83013a542068 ffff8301355d7de8 ffff82c48011a785
(XEN)    ffff8301355d7e58 ffff82c480123519 ffff82c480301a60 ffff82c480301a60
(XEN)    ffff82c480301a60 ffff8300bd503000 0000000000503060 0000000000000246
(XEN)    ffff82c480127c31 ffff8300bd503000 ffff82c480301a60 ffff82c4802ebd40
(XEN)    ffff83013a542068 ffff88003fc8e820 ffff8301355d7e88 ffff82c4801237d3
(XEN)    fffffffffffffffe ffff8301355ca000 ffff8300bd503000 0000000000000000
(XEN)    ffff8301355d7ef8 ffff82c480106335 ffff8301355d7f18 ffffffff810030e1
(XEN)    ffff8300bd503000 0000000000000000 ffff8301355d7f08 ffff82c480185390
(XEN)    ffffffff81aafd32 ffff8300bd503000 0000000000000001 0000000000000000
(XEN)    0000000000000000 ffff88003fc8e820 00007cfecaa280c7 ffff82c480227348
(XEN)    ffffffff8100130a 0000000000000018 ffff88003fc8e820 0000000000000000
(XEN)    0000000000000000 0000000000000001 ffff88003976fda0 ffff88003fc8bdc0
(XEN)    0000000000000246 ffff88003976fe60 00000000ffffffff 0000000000000000
(XEN)    0000000000000018 ffffffff8100130a 0000000000000000 0000000000000001
(XEN) Xen call trace:
(XEN)    [<ffff82c48011a35a>] _csched_cpu_pick+0x135/0x552
(XEN)    [<ffff82c48011a785>] csched_cpu_pick+0xe/0x10
(XEN)    [<ffff82c480123519>] vcpu_migrate+0x19f/0x346
(XEN)    [<ffff82c4801237d3>] vcpu_force_reschedule+0xa4/0xb6
(XEN)    [<ffff82c480106335>] do_vcpu_op+0x2c9/0x452
(XEN)    [<ffff82c480227348>] syscall_enter+0xc8/0x122
(XEN)
(XEN)
(XEN) ****************************************
(XEN) Panic on CPU 1:
(XEN) Assertion '!cpumask_empty(&cpus) && cpumask_test_cpu(cpu, &cpus)'
failed at sched_credit.c:477
(XEN) ****************************************
(XEN)
(XEN) Reboot in five seconds...


> Anyway, this might be connected to cpu_disable_scheduler() not
> having a counterpart to restore the affinity it broke for pinned
> domains (for non-pinned ones I believe this behavior is intentional,
> albeit not ideal).
>
> Jan
>
>

--14dae93406bbf82bf504ca8564c6
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br><div class=3D"gmail_quote">On Tue, Sep 25, 2012 at 3:00 AM, Jan Beulich=
 <span dir=3D"ltr">&lt;<a href=3D"mailto:JBeulich@suse.com" target=3D"_blan=
k">JBeulich@suse.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_qu=
ote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex=
">
<div class=3D"im">&gt;&gt;&gt; On 24.09.12 at 23:12, Ben Guthro &lt;<a href=
=3D"mailto:ben@guthro.net">ben@guthro.net</a>&gt; wrote:<br>
&gt; Here&#39;s my &quot;Big hammer&quot; debugging patch.<br>
&gt;<br>
&gt; If I force the cpu to be scheduled on CPU0 when the appropriate cpu is=
 not<br>
&gt; online, I can resume properly.<br>
&gt;<br>
&gt; Clearly this is not the proper solution, and I&#39;m sure the fix is s=
ubtle.<br>
&gt; I&#39;m not seeing it right now though. Perhaps tomorrow morning.<br>
&gt; If you have any ideas, I&#39;m happy to run tests then.<br>
<br>
</div>I can&#39;t see how the printk() you add in the patch would ever get<=
br>
reached with the other adjustment you do there. </blockquote><div><br></div=
><div>Apologies. I failed to separate prior debugging in this patch from th=
e &quot;big hammer&quot; fix</div><div>=A0</div><blockquote class=3D"gmail_=
quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1=
ex">
A debug build,<br>
as Keir suggested, would not only get the stack trace right, but<br>
would also result in the ASSERT() right after your first modification<br>
to _csched_cpu_pick() to actually do something (and likely trigger).<br></b=
lockquote><div><br></div><div>Indeed. I was using non-debug builds for 2 re=
asons that, in hindsight may not be the best of reasons.</div><div>1. It wa=
s the default</div>
<div>2. Mukesh&#39;s kdb debugger requires debug to be off, which I was mak=
ing use of previously, and had not disabled.</div><div>=A0</div><div>The st=
ack from a debug build can be found below.</div><div>It did, indeed trigger=
 the ASSERT, as you predicted.</div>
<div><br></div><div><br></div><div><div>(XEN) Finishing wakeup from ACPI S3=
 state.</div><div>(XEN) Enabling non-boot CPUs =A0...</div><div>(XEN) Booti=
ng processor 1/1 eip 8a000</div><div>(XEN) Initializing CPU#1</div><div>(XE=
N) CPU: L1 I cache: 32K, L1 D cache: 32K</div>
<div>(XEN) CPU: L2 cache: 3072K</div><div>(XEN) CPU: Physical Processor ID:=
 0</div><div>(XEN) CPU: Processor Core ID: 1</div><div>(XEN) CMCI: CPU1 has=
 no CMCI support</div><div>(XEN) CPU1: Thermal monitoring enabled (TM2)</di=
v>
<div>(XEN) CPU1: Intel(R) Core(TM)2 Duo CPU =A0 =A0 P8400 =A0@ 2.26GHz step=
ping 06</div><div>(XEN) microcode: CPU1 updated from revision 0x60c to 0x60=
f, date =3D 2010-09-29=A0</div><div>[ =A0 82.310025] ACPI: Low-level resume=
 complete</div>
<div>[ =A0 82.310025] PM: Restoring platform NVS memory</div><div>[ =A0 82.=
310025] Enabling non-boot CPUs ...</div><div>[ =A0 82.310025] installing Xe=
n timer for CPU 1</div><div>[ =A0 82.310025] cpu 1 spinlock event irq 279</=
div>
<div>(XEN) Assertion &#39;!cpumask_empty(&amp;cpus) &amp;&amp; cpumask_test=
_cpu(cpu, &amp;cpus)&#39; failed at sched_credit.c:477</div><div>(XEN) ----=
[ Xen-4.2.1-pre =A0x86_64 =A0debug=3Dy =A0Tainted: =A0 =A0C ]----</div><div=
>(XEN) CPU: =A0 =A01</div>
<div>(XEN) RIP: =A0 =A0e008:[&lt;ffff82c48011a35a&gt;] _csched_cpu_pick+0x1=
35/0x552</div><div>(XEN) RFLAGS: 0000000000010002 =A0 CONTEXT: hypervisor</=
div><div>(XEN) rax: 0000000000000001 =A0 rbx: 0000000000000004 =A0 rcx: 000=
0000000000004</div>
<div>(XEN) rdx: 000000000000000f =A0 rsi: 0000000000000004 =A0 rdi: 0000000=
000000000</div><div>(XEN) rbp: ffff8301355d7dd8 =A0 rsp: ffff8301355d7d08 =
=A0 r8: =A00000000000000000</div><div>(XEN) r9: =A0000000000000003e =A0 r10=
: ffff82c480231700 =A0 r11: 0000000000000246</div>
<div>(XEN) r12: ffff82c480261b20 =A0 r13: 0000000000000001 =A0 r14: ffff82c=
480301a60</div><div>(XEN) r15: ffff83013a542068 =A0 cr0: 000000008005003b =
=A0 cr4: 00000000000026f0</div><div>(XEN) cr3: 0000000131a05000 =A0 cr2: 00=
00000000000000</div>
<div>(XEN) ds: 002b =A0 es: 002b =A0 fs: 0000 =A0 gs: 0000 =A0 ss: e010 =A0=
 cs: e008</div><div>(XEN) Xen stack trace from rsp=3Dffff8301355d7d08:</div=
><div>(XEN) =A0 =A00100000131a05000 ffff8301355d7d40 0000000000000082 00000=
00000000002</div>
<div>(XEN) =A0 =A0ffff8300bd503000 0000000000000001 0000000000000297 ffff83=
01355d7d58</div><div>(XEN) =A0 =A0ffff82c480125499 ffff830138216000 ffff830=
1355d7d98 5400000000000002</div><div>(XEN) =A0 =A00000000000000286 ffff8301=
355d7d88 ffff82c480125499 ffff830138216000</div>
<div>(XEN) =A0 =A00000000000000000 0000000000000000 0000000000000000 000000=
0000000000</div><div>(XEN) =A0 =A0ffff830134ca6a50 ffff83013a542068 ffff830=
13a542068 0000000000000001</div><div>(XEN) =A0 =A0ffff82c480301a60 ffff8301=
3a542068 ffff8301355d7de8 ffff82c48011a785</div>
<div>(XEN) =A0 =A0ffff8301355d7e58 ffff82c480123519 ffff82c480301a60 ffff82=
c480301a60</div><div>(XEN) =A0 =A0ffff82c480301a60 ffff8300bd503000 0000000=
000503060 0000000000000246</div><div>(XEN) =A0 =A0ffff82c480127c31 ffff8300=
bd503000 ffff82c480301a60 ffff82c4802ebd40</div>
<div>(XEN) =A0 =A0ffff83013a542068 ffff88003fc8e820 ffff8301355d7e88 ffff82=
c4801237d3</div><div>(XEN) =A0 =A0fffffffffffffffe ffff8301355ca000 ffff830=
0bd503000 0000000000000000</div><div>(XEN) =A0 =A0ffff8301355d7ef8 ffff82c4=
80106335 ffff8301355d7f18 ffffffff810030e1</div>
<div>(XEN) =A0 =A0ffff8300bd503000 0000000000000000 ffff8301355d7f08 ffff82=
c480185390</div><div>(XEN) =A0 =A0ffffffff81aafd32 ffff8300bd503000 0000000=
000000001 0000000000000000</div><div>(XEN) =A0 =A00000000000000000 ffff8800=
3fc8e820 00007cfecaa280c7 ffff82c480227348</div>
<div>(XEN) =A0 =A0ffffffff8100130a 0000000000000018 ffff88003fc8e820 000000=
0000000000</div><div>(XEN) =A0 =A00000000000000000 0000000000000001 ffff880=
03976fda0 ffff88003fc8bdc0</div><div>(XEN) =A0 =A00000000000000246 ffff8800=
3976fe60 00000000ffffffff 0000000000000000</div>
<div>(XEN) =A0 =A00000000000000018 ffffffff8100130a 0000000000000000 000000=
0000000001</div><div>(XEN) Xen call trace:</div><div>(XEN) =A0 =A0[&lt;ffff=
82c48011a35a&gt;] _csched_cpu_pick+0x135/0x552</div><div>(XEN) =A0 =A0[&lt;=
ffff82c48011a785&gt;] csched_cpu_pick+0xe/0x10</div>
<div>(XEN) =A0 =A0[&lt;ffff82c480123519&gt;] vcpu_migrate+0x19f/0x346</div>=
<div>(XEN) =A0 =A0[&lt;ffff82c4801237d3&gt;] vcpu_force_reschedule+0xa4/0xb=
6</div><div>(XEN) =A0 =A0[&lt;ffff82c480106335&gt;] do_vcpu_op+0x2c9/0x452<=
/div><div>
(XEN) =A0 =A0[&lt;ffff82c480227348&gt;] syscall_enter+0xc8/0x122</div><div>=
(XEN) =A0 =A0</div><div>(XEN)=A0</div><div>(XEN) **************************=
**************</div><div>(XEN) Panic on CPU 1:</div><div>(XEN) Assertion &#=
39;!cpumask_empty(&amp;cpus) &amp;&amp; cpumask_test_cpu(cpu, &amp;cpus)&#3=
9; failed at sched_credit.c:477</div>
<div>(XEN) ****************************************</div><div>(XEN)=A0</div=
><div>(XEN) Reboot in five seconds...</div></div><div><br></div><blockquote=
 class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc soli=
d;padding-left:1ex">
<br>
Anyway, this might be connected to cpu_disable_scheduler() not<br>
having a counterpart to restore the affinity it broke for pinned<br>
domains (for non-pinned ones I believe this behavior is intentional,<br>
albeit not ideal).<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
Jan<br>
<br>
</font></span></blockquote></div><br>

--14dae93406bbf82bf504ca8564c6--


--===============8137127006307440570==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============8137127006307440570==--


From xen-devel-bounces@lists.xen.org Tue Sep 25 11:58:06 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 11: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 1TGTls-0006iC-Mj; Tue, 25 Sep 2012 11:57:48 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ben.guthro@gmail.com>) id 1TGTlq-0006hq-Mt
	for xen-devel@lists.xen.org; Tue, 25 Sep 2012 11:57:47 +0000
X-Env-Sender: ben.guthro@gmail.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1348574180!8591913!1
X-Originating-IP: [209.85.223.173]
X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_20_30,HTML_MESSAGE,
	RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8211 invoked from network); 25 Sep 2012 11:56:34 -0000
Received: from mail-ie0-f173.google.com (HELO mail-ie0-f173.google.com)
	(209.85.223.173)
	by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Sep 2012 11:56:34 -0000
Received: by iea17 with SMTP id 17so11160445iea.32
	for <xen-devel@lists.xen.org>; Tue, 25 Sep 2012 04:56: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=kVhMotb0VApXqKTbgeaFsvfdcKTsVZZDdvVQovLWEws=;
	b=OhxY+Y7UjfNF4sSDh9pCTGhuHnK5CSqKyZIfr4yb4fhbTmIO3sjPEWWFLOmlXHRe1q
	DncrIFMOklslizuLi5UcJ5AbJmOMnzO2lRMzMQMrTUxqfhDWqTArPJihnyUvh/WQiFbG
	qSvmk3XEj8C8/B1PcD7MOmwC1zu/NRQWdA6MJINWdxMGTZUkHGLfay4f4hlsBnCrd4d+
	Q7apzH++BNuhBG5jmBOQRMaVNxXc0CGXqa4uLcw4J0VBtYkzUyV+E7eo80r8TGy/XEj7
	Ril6B+oTXSAYX5WpLTyqerMU2xwd+ICFGGKhUuwPPm6mxaUE37i9KtGXahZ9Ln8h6KTj
	ErVQ==
MIME-Version: 1.0
Received: by 10.50.190.230 with SMTP id gt6mr7878096igc.49.1348574180289; Tue,
	25 Sep 2012 04:56:20 -0700 (PDT)
Received: by 10.64.55.132 with HTTP; Tue, 25 Sep 2012 04:56:20 -0700 (PDT)
In-Reply-To: <50617297020000780009D8AA@nat28.tlf.novell.com>
References: <CAOvdn6UCF2A3yP1cqWn=dxwr0ayRbr+rg+xj8META9Dm0+CoNw@mail.gmail.com>
	<CC868168.3FD29%keir.xen@gmail.com>
	<CAOvdn6U-JyLvt96gkLkqzi088tU9_ktv4D+fkJac_BKVe05Y-w@mail.gmail.com>
	<CAOvdn6V+s3AbRzsu8VArbmrZou=im9SqvPf-9Wpif_BrNMv=yg@mail.gmail.com>
	<50617297020000780009D8AA@nat28.tlf.novell.com>
Date: Tue, 25 Sep 2012 07:56:20 -0400
X-Google-Sender-Auth: XutSemJddYXZUuh0y-NphFf_Hww
Message-ID: <CAOvdn6Vsnbcd7m8mh3tSgn3KaEoeiOyVD1mr3uQ3bN=rF=pDUQ@mail.gmail.com>
From: Ben Guthro <ben@guthro.net>
To: Jan Beulich <JBeulich@suse.com>
Cc: Keir Fraser <keir.xen@gmail.com>, John Baboval <john.baboval@citrix.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen4.2 S3 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: multipart/mixed; boundary="===============8137127006307440570=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============8137127006307440570==
Content-Type: multipart/alternative; boundary=14dae93406bbf82bf504ca8564c6

--14dae93406bbf82bf504ca8564c6
Content-Type: text/plain; charset=ISO-8859-1

On Tue, Sep 25, 2012 at 3:00 AM, Jan Beulich <JBeulich@suse.com> wrote:

> >>> On 24.09.12 at 23:12, Ben Guthro <ben@guthro.net> wrote:
> > Here's my "Big hammer" debugging patch.
> >
> > If I force the cpu to be scheduled on CPU0 when the appropriate cpu is
> not
> > online, I can resume properly.
> >
> > Clearly this is not the proper solution, and I'm sure the fix is subtle.
> > I'm not seeing it right now though. Perhaps tomorrow morning.
> > If you have any ideas, I'm happy to run tests then.
>
> I can't see how the printk() you add in the patch would ever get
> reached with the other adjustment you do there.


Apologies. I failed to separate prior debugging in this patch from the "big
hammer" fix


> A debug build,
> as Keir suggested, would not only get the stack trace right, but
> would also result in the ASSERT() right after your first modification
> to _csched_cpu_pick() to actually do something (and likely trigger).
>

Indeed. I was using non-debug builds for 2 reasons that, in hindsight may
not be the best of reasons.
1. It was the default
2. Mukesh's kdb debugger requires debug to be off, which I was making use
of previously, and had not disabled.

The stack from a debug build can be found below.
It did, indeed trigger the ASSERT, as you predicted.


(XEN) Finishing wakeup from ACPI S3 state.
(XEN) Enabling non-boot CPUs  ...
(XEN) Booting processor 1/1 eip 8a000
(XEN) Initializing CPU#1
(XEN) CPU: L1 I cache: 32K, L1 D cache: 32K
(XEN) CPU: L2 cache: 3072K
(XEN) CPU: Physical Processor ID: 0
(XEN) CPU: Processor Core ID: 1
(XEN) CMCI: CPU1 has no CMCI support
(XEN) CPU1: Thermal monitoring enabled (TM2)
(XEN) CPU1: Intel(R) Core(TM)2 Duo CPU     P8400  @ 2.26GHz stepping 06
(XEN) microcode: CPU1 updated from revision 0x60c to 0x60f, date =
2010-09-29
[   82.310025] ACPI: Low-level resume complete
[   82.310025] PM: Restoring platform NVS memory
[   82.310025] Enabling non-boot CPUs ...
[   82.310025] installing Xen timer for CPU 1
[   82.310025] cpu 1 spinlock event irq 279
(XEN) Assertion '!cpumask_empty(&cpus) && cpumask_test_cpu(cpu, &cpus)'
failed at sched_credit.c:477
(XEN) ----[ Xen-4.2.1-pre  x86_64  debug=y  Tainted:    C ]----
(XEN) CPU:    1
(XEN) RIP:    e008:[<ffff82c48011a35a>] _csched_cpu_pick+0x135/0x552
(XEN) RFLAGS: 0000000000010002   CONTEXT: hypervisor
(XEN) rax: 0000000000000001   rbx: 0000000000000004   rcx: 0000000000000004
(XEN) rdx: 000000000000000f   rsi: 0000000000000004   rdi: 0000000000000000
(XEN) rbp: ffff8301355d7dd8   rsp: ffff8301355d7d08   r8:  0000000000000000
(XEN) r9:  000000000000003e   r10: ffff82c480231700   r11: 0000000000000246
(XEN) r12: ffff82c480261b20   r13: 0000000000000001   r14: ffff82c480301a60
(XEN) r15: ffff83013a542068   cr0: 000000008005003b   cr4: 00000000000026f0
(XEN) cr3: 0000000131a05000   cr2: 0000000000000000
(XEN) ds: 002b   es: 002b   fs: 0000   gs: 0000   ss: e010   cs: e008
(XEN) Xen stack trace from rsp=ffff8301355d7d08:
(XEN)    0100000131a05000 ffff8301355d7d40 0000000000000082 0000000000000002
(XEN)    ffff8300bd503000 0000000000000001 0000000000000297 ffff8301355d7d58
(XEN)    ffff82c480125499 ffff830138216000 ffff8301355d7d98 5400000000000002
(XEN)    0000000000000286 ffff8301355d7d88 ffff82c480125499 ffff830138216000
(XEN)    0000000000000000 0000000000000000 0000000000000000 0000000000000000
(XEN)    ffff830134ca6a50 ffff83013a542068 ffff83013a542068 0000000000000001
(XEN)    ffff82c480301a60 ffff83013a542068 ffff8301355d7de8 ffff82c48011a785
(XEN)    ffff8301355d7e58 ffff82c480123519 ffff82c480301a60 ffff82c480301a60
(XEN)    ffff82c480301a60 ffff8300bd503000 0000000000503060 0000000000000246
(XEN)    ffff82c480127c31 ffff8300bd503000 ffff82c480301a60 ffff82c4802ebd40
(XEN)    ffff83013a542068 ffff88003fc8e820 ffff8301355d7e88 ffff82c4801237d3
(XEN)    fffffffffffffffe ffff8301355ca000 ffff8300bd503000 0000000000000000
(XEN)    ffff8301355d7ef8 ffff82c480106335 ffff8301355d7f18 ffffffff810030e1
(XEN)    ffff8300bd503000 0000000000000000 ffff8301355d7f08 ffff82c480185390
(XEN)    ffffffff81aafd32 ffff8300bd503000 0000000000000001 0000000000000000
(XEN)    0000000000000000 ffff88003fc8e820 00007cfecaa280c7 ffff82c480227348
(XEN)    ffffffff8100130a 0000000000000018 ffff88003fc8e820 0000000000000000
(XEN)    0000000000000000 0000000000000001 ffff88003976fda0 ffff88003fc8bdc0
(XEN)    0000000000000246 ffff88003976fe60 00000000ffffffff 0000000000000000
(XEN)    0000000000000018 ffffffff8100130a 0000000000000000 0000000000000001
(XEN) Xen call trace:
(XEN)    [<ffff82c48011a35a>] _csched_cpu_pick+0x135/0x552
(XEN)    [<ffff82c48011a785>] csched_cpu_pick+0xe/0x10
(XEN)    [<ffff82c480123519>] vcpu_migrate+0x19f/0x346
(XEN)    [<ffff82c4801237d3>] vcpu_force_reschedule+0xa4/0xb6
(XEN)    [<ffff82c480106335>] do_vcpu_op+0x2c9/0x452
(XEN)    [<ffff82c480227348>] syscall_enter+0xc8/0x122
(XEN)
(XEN)
(XEN) ****************************************
(XEN) Panic on CPU 1:
(XEN) Assertion '!cpumask_empty(&cpus) && cpumask_test_cpu(cpu, &cpus)'
failed at sched_credit.c:477
(XEN) ****************************************
(XEN)
(XEN) Reboot in five seconds...


> Anyway, this might be connected to cpu_disable_scheduler() not
> having a counterpart to restore the affinity it broke for pinned
> domains (for non-pinned ones I believe this behavior is intentional,
> albeit not ideal).
>
> Jan
>
>

--14dae93406bbf82bf504ca8564c6
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br><div class=3D"gmail_quote">On Tue, Sep 25, 2012 at 3:00 AM, Jan Beulich=
 <span dir=3D"ltr">&lt;<a href=3D"mailto:JBeulich@suse.com" target=3D"_blan=
k">JBeulich@suse.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_qu=
ote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex=
">
<div class=3D"im">&gt;&gt;&gt; On 24.09.12 at 23:12, Ben Guthro &lt;<a href=
=3D"mailto:ben@guthro.net">ben@guthro.net</a>&gt; wrote:<br>
&gt; Here&#39;s my &quot;Big hammer&quot; debugging patch.<br>
&gt;<br>
&gt; If I force the cpu to be scheduled on CPU0 when the appropriate cpu is=
 not<br>
&gt; online, I can resume properly.<br>
&gt;<br>
&gt; Clearly this is not the proper solution, and I&#39;m sure the fix is s=
ubtle.<br>
&gt; I&#39;m not seeing it right now though. Perhaps tomorrow morning.<br>
&gt; If you have any ideas, I&#39;m happy to run tests then.<br>
<br>
</div>I can&#39;t see how the printk() you add in the patch would ever get<=
br>
reached with the other adjustment you do there. </blockquote><div><br></div=
><div>Apologies. I failed to separate prior debugging in this patch from th=
e &quot;big hammer&quot; fix</div><div>=A0</div><blockquote class=3D"gmail_=
quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1=
ex">
A debug build,<br>
as Keir suggested, would not only get the stack trace right, but<br>
would also result in the ASSERT() right after your first modification<br>
to _csched_cpu_pick() to actually do something (and likely trigger).<br></b=
lockquote><div><br></div><div>Indeed. I was using non-debug builds for 2 re=
asons that, in hindsight may not be the best of reasons.</div><div>1. It wa=
s the default</div>
<div>2. Mukesh&#39;s kdb debugger requires debug to be off, which I was mak=
ing use of previously, and had not disabled.</div><div>=A0</div><div>The st=
ack from a debug build can be found below.</div><div>It did, indeed trigger=
 the ASSERT, as you predicted.</div>
<div><br></div><div><br></div><div><div>(XEN) Finishing wakeup from ACPI S3=
 state.</div><div>(XEN) Enabling non-boot CPUs =A0...</div><div>(XEN) Booti=
ng processor 1/1 eip 8a000</div><div>(XEN) Initializing CPU#1</div><div>(XE=
N) CPU: L1 I cache: 32K, L1 D cache: 32K</div>
<div>(XEN) CPU: L2 cache: 3072K</div><div>(XEN) CPU: Physical Processor ID:=
 0</div><div>(XEN) CPU: Processor Core ID: 1</div><div>(XEN) CMCI: CPU1 has=
 no CMCI support</div><div>(XEN) CPU1: Thermal monitoring enabled (TM2)</di=
v>
<div>(XEN) CPU1: Intel(R) Core(TM)2 Duo CPU =A0 =A0 P8400 =A0@ 2.26GHz step=
ping 06</div><div>(XEN) microcode: CPU1 updated from revision 0x60c to 0x60=
f, date =3D 2010-09-29=A0</div><div>[ =A0 82.310025] ACPI: Low-level resume=
 complete</div>
<div>[ =A0 82.310025] PM: Restoring platform NVS memory</div><div>[ =A0 82.=
310025] Enabling non-boot CPUs ...</div><div>[ =A0 82.310025] installing Xe=
n timer for CPU 1</div><div>[ =A0 82.310025] cpu 1 spinlock event irq 279</=
div>
<div>(XEN) Assertion &#39;!cpumask_empty(&amp;cpus) &amp;&amp; cpumask_test=
_cpu(cpu, &amp;cpus)&#39; failed at sched_credit.c:477</div><div>(XEN) ----=
[ Xen-4.2.1-pre =A0x86_64 =A0debug=3Dy =A0Tainted: =A0 =A0C ]----</div><div=
>(XEN) CPU: =A0 =A01</div>
<div>(XEN) RIP: =A0 =A0e008:[&lt;ffff82c48011a35a&gt;] _csched_cpu_pick+0x1=
35/0x552</div><div>(XEN) RFLAGS: 0000000000010002 =A0 CONTEXT: hypervisor</=
div><div>(XEN) rax: 0000000000000001 =A0 rbx: 0000000000000004 =A0 rcx: 000=
0000000000004</div>
<div>(XEN) rdx: 000000000000000f =A0 rsi: 0000000000000004 =A0 rdi: 0000000=
000000000</div><div>(XEN) rbp: ffff8301355d7dd8 =A0 rsp: ffff8301355d7d08 =
=A0 r8: =A00000000000000000</div><div>(XEN) r9: =A0000000000000003e =A0 r10=
: ffff82c480231700 =A0 r11: 0000000000000246</div>
<div>(XEN) r12: ffff82c480261b20 =A0 r13: 0000000000000001 =A0 r14: ffff82c=
480301a60</div><div>(XEN) r15: ffff83013a542068 =A0 cr0: 000000008005003b =
=A0 cr4: 00000000000026f0</div><div>(XEN) cr3: 0000000131a05000 =A0 cr2: 00=
00000000000000</div>
<div>(XEN) ds: 002b =A0 es: 002b =A0 fs: 0000 =A0 gs: 0000 =A0 ss: e010 =A0=
 cs: e008</div><div>(XEN) Xen stack trace from rsp=3Dffff8301355d7d08:</div=
><div>(XEN) =A0 =A00100000131a05000 ffff8301355d7d40 0000000000000082 00000=
00000000002</div>
<div>(XEN) =A0 =A0ffff8300bd503000 0000000000000001 0000000000000297 ffff83=
01355d7d58</div><div>(XEN) =A0 =A0ffff82c480125499 ffff830138216000 ffff830=
1355d7d98 5400000000000002</div><div>(XEN) =A0 =A00000000000000286 ffff8301=
355d7d88 ffff82c480125499 ffff830138216000</div>
<div>(XEN) =A0 =A00000000000000000 0000000000000000 0000000000000000 000000=
0000000000</div><div>(XEN) =A0 =A0ffff830134ca6a50 ffff83013a542068 ffff830=
13a542068 0000000000000001</div><div>(XEN) =A0 =A0ffff82c480301a60 ffff8301=
3a542068 ffff8301355d7de8 ffff82c48011a785</div>
<div>(XEN) =A0 =A0ffff8301355d7e58 ffff82c480123519 ffff82c480301a60 ffff82=
c480301a60</div><div>(XEN) =A0 =A0ffff82c480301a60 ffff8300bd503000 0000000=
000503060 0000000000000246</div><div>(XEN) =A0 =A0ffff82c480127c31 ffff8300=
bd503000 ffff82c480301a60 ffff82c4802ebd40</div>
<div>(XEN) =A0 =A0ffff83013a542068 ffff88003fc8e820 ffff8301355d7e88 ffff82=
c4801237d3</div><div>(XEN) =A0 =A0fffffffffffffffe ffff8301355ca000 ffff830=
0bd503000 0000000000000000</div><div>(XEN) =A0 =A0ffff8301355d7ef8 ffff82c4=
80106335 ffff8301355d7f18 ffffffff810030e1</div>
<div>(XEN) =A0 =A0ffff8300bd503000 0000000000000000 ffff8301355d7f08 ffff82=
c480185390</div><div>(XEN) =A0 =A0ffffffff81aafd32 ffff8300bd503000 0000000=
000000001 0000000000000000</div><div>(XEN) =A0 =A00000000000000000 ffff8800=
3fc8e820 00007cfecaa280c7 ffff82c480227348</div>
<div>(XEN) =A0 =A0ffffffff8100130a 0000000000000018 ffff88003fc8e820 000000=
0000000000</div><div>(XEN) =A0 =A00000000000000000 0000000000000001 ffff880=
03976fda0 ffff88003fc8bdc0</div><div>(XEN) =A0 =A00000000000000246 ffff8800=
3976fe60 00000000ffffffff 0000000000000000</div>
<div>(XEN) =A0 =A00000000000000018 ffffffff8100130a 0000000000000000 000000=
0000000001</div><div>(XEN) Xen call trace:</div><div>(XEN) =A0 =A0[&lt;ffff=
82c48011a35a&gt;] _csched_cpu_pick+0x135/0x552</div><div>(XEN) =A0 =A0[&lt;=
ffff82c48011a785&gt;] csched_cpu_pick+0xe/0x10</div>
<div>(XEN) =A0 =A0[&lt;ffff82c480123519&gt;] vcpu_migrate+0x19f/0x346</div>=
<div>(XEN) =A0 =A0[&lt;ffff82c4801237d3&gt;] vcpu_force_reschedule+0xa4/0xb=
6</div><div>(XEN) =A0 =A0[&lt;ffff82c480106335&gt;] do_vcpu_op+0x2c9/0x452<=
/div><div>
(XEN) =A0 =A0[&lt;ffff82c480227348&gt;] syscall_enter+0xc8/0x122</div><div>=
(XEN) =A0 =A0</div><div>(XEN)=A0</div><div>(XEN) **************************=
**************</div><div>(XEN) Panic on CPU 1:</div><div>(XEN) Assertion &#=
39;!cpumask_empty(&amp;cpus) &amp;&amp; cpumask_test_cpu(cpu, &amp;cpus)&#3=
9; failed at sched_credit.c:477</div>
<div>(XEN) ****************************************</div><div>(XEN)=A0</div=
><div>(XEN) Reboot in five seconds...</div></div><div><br></div><blockquote=
 class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc soli=
d;padding-left:1ex">
<br>
Anyway, this might be connected to cpu_disable_scheduler() not<br>
having a counterpart to restore the affinity it broke for pinned<br>
domains (for non-pinned ones I believe this behavior is intentional,<br>
albeit not ideal).<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
Jan<br>
<br>
</font></span></blockquote></div><br>

--14dae93406bbf82bf504ca8564c6--


--===============8137127006307440570==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============8137127006307440570==--


From xen-devel-bounces@lists.xen.org Tue Sep 25 12:40:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 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 1TGUR7-0007ch-Sz; Tue, 25 Sep 2012 12:40:25 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1TGUR6-0007cc-5y
	for xen-devel@lists.xen.org; Tue, 25 Sep 2012 12:40:24 +0000
Received: from [85.158.139.211:14107] by server-12.bemta-5.messagelabs.com id
	EB/83-20729-736A1605; Tue, 25 Sep 2012 12:40:23 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-206.messagelabs.com!1348576822!19906697!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTEwNzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30120 invoked from network); 25 Sep 2012 12:40:22 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Sep 2012 12:40:22 -0000
X-IronPort-AV: E=Sophos;i="4.80,481,1344211200"; d="scan'208";a="14749767"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Sep 2012 12:40: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.279.1;
	Tue, 25 Sep 2012 13:40:20 +0100
Message-ID: <1348576819.3452.199.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Tue, 25 Sep 2012 13:40:19 +0100
In-Reply-To: <20577.33326.654049.560825@mariner.uk.xensource.com>
References: <ba1c6e807c8b1684a83e.1347871431@cosworth.uk.xensource.com>
	<1348566052.3452.145.camel@zakaz.uk.xensource.com>
	<20577.33326.654049.560825@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-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] tools: bump SONAMEs for changes during 4.2
 development cycle
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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-09-25 at 11:06 +0100, Ian Jackson wrote:
> Ian Campbell writes ("Re: [Xen-devel] [PATCH] tools: bump SONAMEs for changes during 4.2 development cycle"):
> > Ping?
> > 
> > On Mon, 2012-09-17 at 09:43 +0100, Ian Campbell wrote:
> > > tools: bump SONAMEs for changes during 4.2 development cycle.
> 
> Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

Thanks, applied.

> Also for 4.2.

I assume you'll do that once it passes through a test?



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 25 12:40:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 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 1TGUR7-0007ch-Sz; Tue, 25 Sep 2012 12:40:25 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1TGUR6-0007cc-5y
	for xen-devel@lists.xen.org; Tue, 25 Sep 2012 12:40:24 +0000
Received: from [85.158.139.211:14107] by server-12.bemta-5.messagelabs.com id
	EB/83-20729-736A1605; Tue, 25 Sep 2012 12:40:23 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-206.messagelabs.com!1348576822!19906697!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTEwNzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30120 invoked from network); 25 Sep 2012 12:40:22 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Sep 2012 12:40:22 -0000
X-IronPort-AV: E=Sophos;i="4.80,481,1344211200"; d="scan'208";a="14749767"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Sep 2012 12:40: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.279.1;
	Tue, 25 Sep 2012 13:40:20 +0100
Message-ID: <1348576819.3452.199.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Tue, 25 Sep 2012 13:40:19 +0100
In-Reply-To: <20577.33326.654049.560825@mariner.uk.xensource.com>
References: <ba1c6e807c8b1684a83e.1347871431@cosworth.uk.xensource.com>
	<1348566052.3452.145.camel@zakaz.uk.xensource.com>
	<20577.33326.654049.560825@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-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] tools: bump SONAMEs for changes during 4.2
 development cycle
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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-09-25 at 11:06 +0100, Ian Jackson wrote:
> Ian Campbell writes ("Re: [Xen-devel] [PATCH] tools: bump SONAMEs for changes during 4.2 development cycle"):
> > Ping?
> > 
> > On Mon, 2012-09-17 at 09:43 +0100, Ian Campbell wrote:
> > > tools: bump SONAMEs for changes during 4.2 development cycle.
> 
> Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

Thanks, applied.

> Also for 4.2.

I assume you'll do that once it passes through a test?



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 25 13:19:41 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 13:19:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGV2d-0007w8-2i; Tue, 25 Sep 2012 13:19: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 1TGV2b-0007w3-I8
	for xen-devel@lists.xen.org; Tue, 25 Sep 2012 13:19:09 +0000
Received: from [85.158.137.99:64454] by server-6.bemta-3.messagelabs.com id
	EB/1D-29694-B4FA1605; Tue, 25 Sep 2012 13:19:07 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-217.messagelabs.com!1348579146!14264467!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTEwNzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2558 invoked from network); 25 Sep 2012 13:19:06 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Sep 2012 13:19:06 -0000
X-IronPort-AV: E=Sophos;i="4.80,483,1344211200"; d="scan'208";a="14751090"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Sep 2012 13:19: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.279.1;
	Tue, 25 Sep 2012 14:19:05 +0100
Message-ID: <1348579144.11229.6.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Tue, 25 Sep 2012 14:19:04 +0100
In-Reply-To: <20576.36587.698928.396214@mariner.uk.xensource.com>
References: <20576.36587.698928.396214@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] docs: network diagrams for the wiki
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2012-09-24 at 17:48 +0100, Ian Jackson wrote:
> @@ -40,6 +40,10 @@ html: $(DOC_HTML) html/index.html
>  .PHONY: txt
>  txt: $(DOC_TXT)
> 
> +.PHONY: figs
> +figs:
> +       $(MAKE) -C figs

I think you've forgotten to "git add docs/figs/Makefile" ?

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 25 13:19:41 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 13:19:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGV2d-0007w8-2i; Tue, 25 Sep 2012 13:19: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 1TGV2b-0007w3-I8
	for xen-devel@lists.xen.org; Tue, 25 Sep 2012 13:19:09 +0000
Received: from [85.158.137.99:64454] by server-6.bemta-3.messagelabs.com id
	EB/1D-29694-B4FA1605; Tue, 25 Sep 2012 13:19:07 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-217.messagelabs.com!1348579146!14264467!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTEwNzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2558 invoked from network); 25 Sep 2012 13:19:06 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Sep 2012 13:19:06 -0000
X-IronPort-AV: E=Sophos;i="4.80,483,1344211200"; d="scan'208";a="14751090"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Sep 2012 13:19: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.279.1;
	Tue, 25 Sep 2012 14:19:05 +0100
Message-ID: <1348579144.11229.6.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Tue, 25 Sep 2012 14:19:04 +0100
In-Reply-To: <20576.36587.698928.396214@mariner.uk.xensource.com>
References: <20576.36587.698928.396214@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] docs: network diagrams for the wiki
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2012-09-24 at 17:48 +0100, Ian Jackson wrote:
> @@ -40,6 +40,10 @@ html: $(DOC_HTML) html/index.html
>  .PHONY: txt
>  txt: $(DOC_TXT)
> 
> +.PHONY: figs
> +figs:
> +       $(MAKE) -C figs

I think you've forgotten to "git add docs/figs/Makefile" ?

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 25 13:19:58 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 13: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 1TGV35-0007xM-Fg; Tue, 25 Sep 2012 13:19:39 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1TGV33-0007xF-On
	for xen-devel@lists.xen.org; Tue, 25 Sep 2012 13:19:37 +0000
Received: from [85.158.139.211:5812] by server-14.bemta-5.messagelabs.com id
	91/BA-05772-86FA1605; Tue, 25 Sep 2012 13:19:36 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-206.messagelabs.com!1348579176!18894902!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTEwNzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19478 invoked from network); 25 Sep 2012 13:19:36 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Sep 2012 13:19:36 -0000
X-IronPort-AV: E=Sophos;i="4.80,483,1344211200"; d="scan'208";a="14751103"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Sep 2012 13: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.279.1;
	Tue, 25 Sep 2012 14:19:35 +0100
Message-ID: <1348579174.11229.7.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Tue, 25 Sep 2012 14:19:34 +0100
In-Reply-To: <20576.36587.698928.396214@mariner.uk.xensource.com>
References: <20576.36587.698928.396214@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] docs: network diagrams for the wiki
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2012-09-24 at 17:48 +0100, Ian Jackson wrote:
> We provide two new diagrams
>   docs/figs/network-{bridge,basic}.fig
> which are converted to pngs by the Makefiles and intended for
> consumption by http://wiki.xen.org/wiki/Xen_Networking.

I opened these in xfig and they look good. Thanks,
Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 25 13:19:58 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 13: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 1TGV35-0007xM-Fg; Tue, 25 Sep 2012 13:19:39 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1TGV33-0007xF-On
	for xen-devel@lists.xen.org; Tue, 25 Sep 2012 13:19:37 +0000
Received: from [85.158.139.211:5812] by server-14.bemta-5.messagelabs.com id
	91/BA-05772-86FA1605; Tue, 25 Sep 2012 13:19:36 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-206.messagelabs.com!1348579176!18894902!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTEwNzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19478 invoked from network); 25 Sep 2012 13:19:36 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Sep 2012 13:19:36 -0000
X-IronPort-AV: E=Sophos;i="4.80,483,1344211200"; d="scan'208";a="14751103"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Sep 2012 13: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.279.1;
	Tue, 25 Sep 2012 14:19:35 +0100
Message-ID: <1348579174.11229.7.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Tue, 25 Sep 2012 14:19:34 +0100
In-Reply-To: <20576.36587.698928.396214@mariner.uk.xensource.com>
References: <20576.36587.698928.396214@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] docs: network diagrams for the wiki
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2012-09-24 at 17:48 +0100, Ian Jackson wrote:
> We provide two new diagrams
>   docs/figs/network-{bridge,basic}.fig
> which are converted to pngs by the Makefiles and intended for
> consumption by http://wiki.xen.org/wiki/Xen_Networking.

I opened these in xfig and they look good. Thanks,
Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 25 13:31:42 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 13:31:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGVEM-0008EG-Lo; Tue, 25 Sep 2012 13:31:18 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1TGVEK-0008EB-S2
	for xen-devel@lists.xen.org; Tue, 25 Sep 2012 13:31:17 +0000
Received: from [85.158.143.99:51253] by server-3.bemta-4.messagelabs.com id
	B3/A7-10986-422B1605; Tue, 25 Sep 2012 13:31:16 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1348579875!24702492!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25482 invoked from network); 25 Sep 2012 13:31:15 -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;
	25 Sep 2012 13:31:15 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 25 Sep 2012 14:31:14 +0100
Message-Id: <5061CE58020000780009DAC1@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 25 Sep 2012 14:31:36 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Christoph Egger" <Christoph.Egger@amd.com>
References: <50584D0A.9060108@amd.com>
In-Reply-To: <50584D0A.9060108@amd.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Jinsong Liu <jinsong.liu@intel.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] vMCE: Add AMD 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 18.09.12 at 12:29, Christoph Egger <Christoph.Egger@amd.com> wrote:
> Add vMCE support to AMD.
> Add vmce namespace to Intel specific vMCE MSR functions.
> Move vMCE prototypes from mce.h to vmce.h
> 
> Signed-off-by: Christoph Egger <Christoph.Egger@amd.com>

I put the patch almost as-is (i.e. modified only where necessary to
apply on top of Jinsong's), but ...

>+int vmce_amd_wrmsr(struct vcpu *v, uint32_t msr, uint64_t val)
>+{
>+        int ret = 0;
>+
>+        switch (msr) {
>+        case MSR_F10_MC4_MISC1:
>+        case MSR_F10_MC4_MISC2:
>+        case MSR_F10_MC4_MISC3:
>+                break;
>+        default:
>+                mce_printk(MCE_QUIET, "Guest writes unhandled MSR 0x%x\n", msr);
>+                ret = 1;
>+                break;
>+        }
>+
>+        return ret;
>+}
>+
>+int vmce_amd_rdmsr(const struct vcpu *v, uint32_t msr, uint64_t *val)
>+{
>+        int ret = 0;
>+
>+        switch (msr) {
>+        case MSR_F10_MC4_MISC1:
>+        case MSR_F10_MC4_MISC2:
>+        case MSR_F10_MC4_MISC3:
>+                break;
>+        default:
>+                mce_printk(MCE_QUIET, "Guest reads unhandled MSR 0x%x\n", msr);
>+                ret = 1;
>+                break;
>+        }
>+
>+        return ret;
>+}

... the return values here were inverted afaict (fixed), and the
functions in this shape are just pointless (i.e. I assume you will
make them actually do something in a subsequent patch) - I
took the liberty to remove the bogus printk()-s as minimal action.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 25 13:31:42 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 13:31:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGVEM-0008EG-Lo; Tue, 25 Sep 2012 13:31:18 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1TGVEK-0008EB-S2
	for xen-devel@lists.xen.org; Tue, 25 Sep 2012 13:31:17 +0000
Received: from [85.158.143.99:51253] by server-3.bemta-4.messagelabs.com id
	B3/A7-10986-422B1605; Tue, 25 Sep 2012 13:31:16 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1348579875!24702492!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25482 invoked from network); 25 Sep 2012 13:31:15 -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;
	25 Sep 2012 13:31:15 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 25 Sep 2012 14:31:14 +0100
Message-Id: <5061CE58020000780009DAC1@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 25 Sep 2012 14:31:36 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Christoph Egger" <Christoph.Egger@amd.com>
References: <50584D0A.9060108@amd.com>
In-Reply-To: <50584D0A.9060108@amd.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Jinsong Liu <jinsong.liu@intel.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] vMCE: Add AMD 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 18.09.12 at 12:29, Christoph Egger <Christoph.Egger@amd.com> wrote:
> Add vMCE support to AMD.
> Add vmce namespace to Intel specific vMCE MSR functions.
> Move vMCE prototypes from mce.h to vmce.h
> 
> Signed-off-by: Christoph Egger <Christoph.Egger@amd.com>

I put the patch almost as-is (i.e. modified only where necessary to
apply on top of Jinsong's), but ...

>+int vmce_amd_wrmsr(struct vcpu *v, uint32_t msr, uint64_t val)
>+{
>+        int ret = 0;
>+
>+        switch (msr) {
>+        case MSR_F10_MC4_MISC1:
>+        case MSR_F10_MC4_MISC2:
>+        case MSR_F10_MC4_MISC3:
>+                break;
>+        default:
>+                mce_printk(MCE_QUIET, "Guest writes unhandled MSR 0x%x\n", msr);
>+                ret = 1;
>+                break;
>+        }
>+
>+        return ret;
>+}
>+
>+int vmce_amd_rdmsr(const struct vcpu *v, uint32_t msr, uint64_t *val)
>+{
>+        int ret = 0;
>+
>+        switch (msr) {
>+        case MSR_F10_MC4_MISC1:
>+        case MSR_F10_MC4_MISC2:
>+        case MSR_F10_MC4_MISC3:
>+                break;
>+        default:
>+                mce_printk(MCE_QUIET, "Guest reads unhandled MSR 0x%x\n", msr);
>+                ret = 1;
>+                break;
>+        }
>+
>+        return ret;
>+}

... the return values here were inverted afaict (fixed), and the
functions in this shape are just pointless (i.e. I assume you will
make them actually do something in a subsequent patch) - I
took the liberty to remove the bogus printk()-s as minimal action.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 25 13:34:02 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 13:34:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGVGi-0008P4-7a; Tue, 25 Sep 2012 13:33:44 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ketuzsezr@gmail.com>) id 1TGVGg-0008Oy-Sl
	for Xen-devel@lists.xensource.com; Tue, 25 Sep 2012 13:33:43 +0000
Received: from [85.158.139.211:28563] by server-13.bemta-5.messagelabs.com id
	01/32-16359-6B2B1605; Tue, 25 Sep 2012 13:33:42 +0000
X-Env-Sender: ketuzsezr@gmail.com
X-Msg-Ref: server-8.tower-206.messagelabs.com!1348580020!19882113!1
X-Originating-IP: [209.85.216.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18575 invoked from network); 25 Sep 2012 13:33:41 -0000
Received: from mail-qc0-f171.google.com (HELO mail-qc0-f171.google.com)
	(209.85.216.171)
	by server-8.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Sep 2012 13:33:41 -0000
Received: by qcad1 with SMTP id d1so2253111qca.30
	for <Xen-devel@lists.xensource.com>;
	Tue, 25 Sep 2012 06:33:40 -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=efbf1+Mj0O5/HX4SJgSFRPTs5PooVSVbz0fjAIa/SM0=;
	b=pPCmDgBGbZHD0N4SpRc6ASwHaoD44MHTaTSpa2lTdjJx/u7D0oXwwgiwH+fzzzmiWH
	GPB102yPVLQKM6u1wJhe+c2VLjcLgMgPjLjjCDajhUJk2EHoePIrrxszl5veARaV2DGZ
	S6V6TQ4qA49NMrYR4zTUh1ED+ycxVhcRtATHH3rulFiO6dV8vMOjqCcUDRq5MAShVSxy
	L4CwT8oujVq+X5WXpr4pJzKaFkECrbiporG9WrV8Vp2rNVrS6GowamM/cMFaH+hvASvT
	s4eJPRKQ5YV1enhwULsNPWVBWil+fchhsasHxdBRYyXdA8uLydsmA4Lmz7+g3XpcOFWy
	2KUA==
Received: by 10.229.135.67 with SMTP id m3mr11167034qct.26.1348580019903;
	Tue, 25 Sep 2012 06:33:39 -0700 (PDT)
Received: from phenom.dumpdata.com
	(50-195-21-189-static.hfc.comcastbusiness.net. [50.195.21.189])
	by mx.google.com with ESMTPS id m4sm804705qak.6.2012.09.25.06.33.38
	(version=TLSv1/SSLv3 cipher=OTHER);
	Tue, 25 Sep 2012 06:33:39 -0700 (PDT)
Date: Tue, 25 Sep 2012 09:22:24 -0400
From: Konrad Rzeszutek Wilk <konrad@kernel.org>
To: Mukesh Rathor <mukesh.rathor@oracle.com>
Message-ID: <20120925132214.GA20515@phenom.dumpdata.com>
References: <20120921121752.5fa80b35@mantra.us.oracle.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120921121752.5fa80b35@mantra.us.oracle.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
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>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH v1 4/8]: PVH setup changes...
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Sep 21, 2012 at 12:17:52PM -0700, Mukesh Rathor wrote:
> 
> ---
>  arch/x86/xen/setup.c |   51 ++++++++++++++++++++++++++++++++++++++++++-------
>  1 files changed, 43 insertions(+), 8 deletions(-)
> 
> diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c
> index ead8557..fba442e 100644
> --- a/arch/x86/xen/setup.c
> +++ b/arch/x86/xen/setup.c
> @@ -26,6 +26,7 @@
>  #include <xen/interface/memory.h>
>  #include <xen/interface/physdev.h>
>  #include <xen/features.h>
> +#include "mmu.h"
>  #include "xen-ops.h"
>  #include "vdso.h"
>  
> @@ -222,6 +223,26 @@ static void __init xen_set_identity_and_release_chunk(
>  	*identity += set_phys_range_identity(start_pfn, end_pfn);
>  }
>  
> +/* For PVH, the pfns [0..MAX] are mapped to mfn's in the EPT/NPT. The mfns
> + * are released as part of this 1:1 mapping hypercall back to the dom heap. We
> + * don't use the xen_do_chunk() PV does above because when P2M/EPT/NPT is 
> + * updated, the mfns are already lost as part of the p2m update.
> + * Also, we map the entire IO space, ie, beyond max_pfn_mapped.
> + */
> +static void __init xen_pvh_identity_map_chunk(unsigned long start_pfn,
> +		unsigned long end_pfn, unsigned long *released, 
> +		unsigned long *identity)
> +{
> +	unsigned long pfn;
> +	int numpfns=1, add_mapping=1;
> +
> +	for (pfn = start_pfn; pfn < end_pfn; pfn++)
> +		xen_set_clr_mmio_pvh_pte(pfn, pfn, numpfns, add_mapping);
> +
> +	*released += end_pfn - start_pfn;

So this will feed in the populate method that will try to populate back
the amount that were released (xen_populate_chunk). Is that OK? You
mention that we do not want to call 'xen_do_chunk()' but the
'xen_populate_chunk' would do that for XENMEM_populate_physmap call.

The modifcation of *released also ends up modifying the "xen_released_pages"
value which is a global value that the balloon driver ends up using so
we have to be carefull?

Perhaps we should just do this (on top of this patch) for right now:

diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c
index 8971a26..3d33ac6 100644
--- a/arch/x86/xen/setup.c
+++ b/arch/x86/xen/setup.c
@@ -103,6 +103,15 @@ static unsigned long __init xen_do_chunk(unsigned long start,
 	unsigned long pfn;
 	int ret;
 
+	if (xen_feature(XENFEAT_auto_translated_physmap)) {
+		/* The xen_set_clr_mmio_pvh_pte did the job for us. */
+		if (release)
+			return end - start;
+		/* And we do not populate back here.. Meaning that the
+ 		 * later balloon driver can do it based on xen_released_pages.
+ 		 * This will be fixed in the future. */
+		return 0;
+	}
 	for (pfn = start; pfn < end; pfn++) {
 		unsigned long frame;
 		unsigned long mfn = pfn_to_mfn(pfn);


> +	*identity += end_pfn - start_pfn;
> +}
> +
>  static unsigned long __init xen_set_identity_and_release(
>  	const struct e820entry *list, size_t map_size, unsigned long nr_pages)
>  {
> @@ -230,6 +251,7 @@ static unsigned long __init xen_set_identity_and_release(
>  	unsigned long identity = 0;
>  	const struct e820entry *entry;
>  	int i;
> +	int xlated_phys = xen_feature(XENFEAT_auto_translated_physmap);
>  
>  	/*
>  	 * Combine non-RAM regions and gaps until a RAM region (or the
> @@ -251,11 +273,16 @@ static unsigned long __init xen_set_identity_and_release(
>  			if (entry->type == E820_RAM)
>  				end_pfn = PFN_UP(entry->addr);
>  
> -			if (start_pfn < end_pfn)
> -				xen_set_identity_and_release_chunk(
> -					start_pfn, end_pfn, nr_pages,
> -					&released, &identity);
> -
> +			if (start_pfn < end_pfn) {
> +				if (xlated_phys) {
> +					xen_pvh_identity_map_chunk(start_pfn, 
> +						end_pfn, &released, &identity);
> +				} else {
> +					xen_set_identity_and_release_chunk(
> +						start_pfn, end_pfn, nr_pages,
> +						&released, &identity);

Might as well just move this in the xen_set_identity_and_release_chunk
function. Meaning, leave this function along and just modify
xen_set_identity_and_release_chunk to do the modifications, like this:


diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c
index 8971a26..3db3f46 100644
--- a/arch/x86/xen/setup.c
+++ b/arch/x86/xen/setup.c
@@ -103,6 +103,15 @@ static unsigned long __init xen_do_chunk(unsigned long start,
 	unsigned long pfn;
 	int ret;
 
+	if (xen_feature(XENFEAT_auto_translated_physmap)) {
+		/* The xen_set_clr_mmio_pvh_pte did the job for us. */
+		if (release)
+			return end - start;
+		/* And we do not populate back here.. Meaning that the
+ 		 * later balloon driver can do it based on xen_released_pages.
+ 		 * This will be fixed in the future. */
+		return 0;
+	}
 	for (pfn = start; pfn < end; pfn++) {
 		unsigned long frame;
 		unsigned long mfn = pfn_to_mfn(pfn);
@@ -218,11 +227,15 @@ static void __init xen_set_identity_and_release_chunk(
 	 * If the PFNs are currently mapped, the VA mapping also needs
 	 * to be updated to be 1:1.
 	 */
-	for (pfn = start_pfn; pfn <= max_pfn_mapped && pfn < end_pfn; pfn++)
-		(void)HYPERVISOR_update_va_mapping(
-			(unsigned long)__va(pfn << PAGE_SHIFT),
-			mfn_pte(pfn, PAGE_KERNEL_IO), 0);
-
+	for (pfn = start_pfn; pfn <= max_pfn_mapped && pfn < end_pfn; pfn++) {
+		if (xen_feature(XENFEAT_auto_translated_physmap)) {
+			xen_set_clr_mmio_pvh_pte(pfn, pfn, 1, 1);
+		} else {
+			(void)HYPERVISOR_update_va_mapping(
+				(unsigned long)__va(pfn << PAGE_SHIFT),
+				mfn_pte(pfn, PAGE_KERNEL_IO), 0);
+		}
+	}
 	if (start_pfn < nr_pages)
 		*released += xen_release_chunk(
 			start_pfn, min(end_pfn, nr_pages));
> +				}
> +			}
>  			start = end;
>  		}
>  	}
> @@ -500,10 +527,9 @@ void __cpuinit xen_enable_syscall(void)
>  #endif /* CONFIG_X86_64 */
>  }
>  
> -void __init xen_arch_setup(void)
> +/* Non auto translated PV domain, ie, it's not PVH. */
> +static __init void inline xen_non_pvh_arch_setup(void)
>  {
> -	xen_panic_handler_init();
> -
>  	HYPERVISOR_vm_assist(VMASST_CMD_enable, VMASST_TYPE_4gb_segments);
>  	HYPERVISOR_vm_assist(VMASST_CMD_enable, VMASST_TYPE_writable_pagetables);
>  
> @@ -517,6 +543,15 @@ void __init xen_arch_setup(void)
>  
>  	xen_enable_sysenter();
>  	xen_enable_syscall();
> +}
> +
> +/* This function not called for HVM domain */
> +void __init xen_arch_setup(void)
> +{
> +	xen_panic_handler_init();
> +
> +	if (!xen_feature(XENFEAT_auto_translated_physmap))
> +		xen_non_pvh_arch_setup();
>  

I am not sure what the syscall functions have to do with parsing of the
E820.

You should split this patch in two - one that deals with the E820
parsing and another that deails with the setup of syscalls.

>  #ifdef CONFIG_ACPI
>  	if (!(xen_start_info->flags & SIF_INITDOMAIN)) {
> -- 
> 1.7.2.3
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 25 13:34:02 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 13:34:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGVGi-0008P4-7a; Tue, 25 Sep 2012 13:33:44 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ketuzsezr@gmail.com>) id 1TGVGg-0008Oy-Sl
	for Xen-devel@lists.xensource.com; Tue, 25 Sep 2012 13:33:43 +0000
Received: from [85.158.139.211:28563] by server-13.bemta-5.messagelabs.com id
	01/32-16359-6B2B1605; Tue, 25 Sep 2012 13:33:42 +0000
X-Env-Sender: ketuzsezr@gmail.com
X-Msg-Ref: server-8.tower-206.messagelabs.com!1348580020!19882113!1
X-Originating-IP: [209.85.216.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18575 invoked from network); 25 Sep 2012 13:33:41 -0000
Received: from mail-qc0-f171.google.com (HELO mail-qc0-f171.google.com)
	(209.85.216.171)
	by server-8.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Sep 2012 13:33:41 -0000
Received: by qcad1 with SMTP id d1so2253111qca.30
	for <Xen-devel@lists.xensource.com>;
	Tue, 25 Sep 2012 06:33:40 -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=efbf1+Mj0O5/HX4SJgSFRPTs5PooVSVbz0fjAIa/SM0=;
	b=pPCmDgBGbZHD0N4SpRc6ASwHaoD44MHTaTSpa2lTdjJx/u7D0oXwwgiwH+fzzzmiWH
	GPB102yPVLQKM6u1wJhe+c2VLjcLgMgPjLjjCDajhUJk2EHoePIrrxszl5veARaV2DGZ
	S6V6TQ4qA49NMrYR4zTUh1ED+ycxVhcRtATHH3rulFiO6dV8vMOjqCcUDRq5MAShVSxy
	L4CwT8oujVq+X5WXpr4pJzKaFkECrbiporG9WrV8Vp2rNVrS6GowamM/cMFaH+hvASvT
	s4eJPRKQ5YV1enhwULsNPWVBWil+fchhsasHxdBRYyXdA8uLydsmA4Lmz7+g3XpcOFWy
	2KUA==
Received: by 10.229.135.67 with SMTP id m3mr11167034qct.26.1348580019903;
	Tue, 25 Sep 2012 06:33:39 -0700 (PDT)
Received: from phenom.dumpdata.com
	(50-195-21-189-static.hfc.comcastbusiness.net. [50.195.21.189])
	by mx.google.com with ESMTPS id m4sm804705qak.6.2012.09.25.06.33.38
	(version=TLSv1/SSLv3 cipher=OTHER);
	Tue, 25 Sep 2012 06:33:39 -0700 (PDT)
Date: Tue, 25 Sep 2012 09:22:24 -0400
From: Konrad Rzeszutek Wilk <konrad@kernel.org>
To: Mukesh Rathor <mukesh.rathor@oracle.com>
Message-ID: <20120925132214.GA20515@phenom.dumpdata.com>
References: <20120921121752.5fa80b35@mantra.us.oracle.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120921121752.5fa80b35@mantra.us.oracle.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
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>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH v1 4/8]: PVH setup changes...
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Sep 21, 2012 at 12:17:52PM -0700, Mukesh Rathor wrote:
> 
> ---
>  arch/x86/xen/setup.c |   51 ++++++++++++++++++++++++++++++++++++++++++-------
>  1 files changed, 43 insertions(+), 8 deletions(-)
> 
> diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c
> index ead8557..fba442e 100644
> --- a/arch/x86/xen/setup.c
> +++ b/arch/x86/xen/setup.c
> @@ -26,6 +26,7 @@
>  #include <xen/interface/memory.h>
>  #include <xen/interface/physdev.h>
>  #include <xen/features.h>
> +#include "mmu.h"
>  #include "xen-ops.h"
>  #include "vdso.h"
>  
> @@ -222,6 +223,26 @@ static void __init xen_set_identity_and_release_chunk(
>  	*identity += set_phys_range_identity(start_pfn, end_pfn);
>  }
>  
> +/* For PVH, the pfns [0..MAX] are mapped to mfn's in the EPT/NPT. The mfns
> + * are released as part of this 1:1 mapping hypercall back to the dom heap. We
> + * don't use the xen_do_chunk() PV does above because when P2M/EPT/NPT is 
> + * updated, the mfns are already lost as part of the p2m update.
> + * Also, we map the entire IO space, ie, beyond max_pfn_mapped.
> + */
> +static void __init xen_pvh_identity_map_chunk(unsigned long start_pfn,
> +		unsigned long end_pfn, unsigned long *released, 
> +		unsigned long *identity)
> +{
> +	unsigned long pfn;
> +	int numpfns=1, add_mapping=1;
> +
> +	for (pfn = start_pfn; pfn < end_pfn; pfn++)
> +		xen_set_clr_mmio_pvh_pte(pfn, pfn, numpfns, add_mapping);
> +
> +	*released += end_pfn - start_pfn;

So this will feed in the populate method that will try to populate back
the amount that were released (xen_populate_chunk). Is that OK? You
mention that we do not want to call 'xen_do_chunk()' but the
'xen_populate_chunk' would do that for XENMEM_populate_physmap call.

The modifcation of *released also ends up modifying the "xen_released_pages"
value which is a global value that the balloon driver ends up using so
we have to be carefull?

Perhaps we should just do this (on top of this patch) for right now:

diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c
index 8971a26..3d33ac6 100644
--- a/arch/x86/xen/setup.c
+++ b/arch/x86/xen/setup.c
@@ -103,6 +103,15 @@ static unsigned long __init xen_do_chunk(unsigned long start,
 	unsigned long pfn;
 	int ret;
 
+	if (xen_feature(XENFEAT_auto_translated_physmap)) {
+		/* The xen_set_clr_mmio_pvh_pte did the job for us. */
+		if (release)
+			return end - start;
+		/* And we do not populate back here.. Meaning that the
+ 		 * later balloon driver can do it based on xen_released_pages.
+ 		 * This will be fixed in the future. */
+		return 0;
+	}
 	for (pfn = start; pfn < end; pfn++) {
 		unsigned long frame;
 		unsigned long mfn = pfn_to_mfn(pfn);


> +	*identity += end_pfn - start_pfn;
> +}
> +
>  static unsigned long __init xen_set_identity_and_release(
>  	const struct e820entry *list, size_t map_size, unsigned long nr_pages)
>  {
> @@ -230,6 +251,7 @@ static unsigned long __init xen_set_identity_and_release(
>  	unsigned long identity = 0;
>  	const struct e820entry *entry;
>  	int i;
> +	int xlated_phys = xen_feature(XENFEAT_auto_translated_physmap);
>  
>  	/*
>  	 * Combine non-RAM regions and gaps until a RAM region (or the
> @@ -251,11 +273,16 @@ static unsigned long __init xen_set_identity_and_release(
>  			if (entry->type == E820_RAM)
>  				end_pfn = PFN_UP(entry->addr);
>  
> -			if (start_pfn < end_pfn)
> -				xen_set_identity_and_release_chunk(
> -					start_pfn, end_pfn, nr_pages,
> -					&released, &identity);
> -
> +			if (start_pfn < end_pfn) {
> +				if (xlated_phys) {
> +					xen_pvh_identity_map_chunk(start_pfn, 
> +						end_pfn, &released, &identity);
> +				} else {
> +					xen_set_identity_and_release_chunk(
> +						start_pfn, end_pfn, nr_pages,
> +						&released, &identity);

Might as well just move this in the xen_set_identity_and_release_chunk
function. Meaning, leave this function along and just modify
xen_set_identity_and_release_chunk to do the modifications, like this:


diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c
index 8971a26..3db3f46 100644
--- a/arch/x86/xen/setup.c
+++ b/arch/x86/xen/setup.c
@@ -103,6 +103,15 @@ static unsigned long __init xen_do_chunk(unsigned long start,
 	unsigned long pfn;
 	int ret;
 
+	if (xen_feature(XENFEAT_auto_translated_physmap)) {
+		/* The xen_set_clr_mmio_pvh_pte did the job for us. */
+		if (release)
+			return end - start;
+		/* And we do not populate back here.. Meaning that the
+ 		 * later balloon driver can do it based on xen_released_pages.
+ 		 * This will be fixed in the future. */
+		return 0;
+	}
 	for (pfn = start; pfn < end; pfn++) {
 		unsigned long frame;
 		unsigned long mfn = pfn_to_mfn(pfn);
@@ -218,11 +227,15 @@ static void __init xen_set_identity_and_release_chunk(
 	 * If the PFNs are currently mapped, the VA mapping also needs
 	 * to be updated to be 1:1.
 	 */
-	for (pfn = start_pfn; pfn <= max_pfn_mapped && pfn < end_pfn; pfn++)
-		(void)HYPERVISOR_update_va_mapping(
-			(unsigned long)__va(pfn << PAGE_SHIFT),
-			mfn_pte(pfn, PAGE_KERNEL_IO), 0);
-
+	for (pfn = start_pfn; pfn <= max_pfn_mapped && pfn < end_pfn; pfn++) {
+		if (xen_feature(XENFEAT_auto_translated_physmap)) {
+			xen_set_clr_mmio_pvh_pte(pfn, pfn, 1, 1);
+		} else {
+			(void)HYPERVISOR_update_va_mapping(
+				(unsigned long)__va(pfn << PAGE_SHIFT),
+				mfn_pte(pfn, PAGE_KERNEL_IO), 0);
+		}
+	}
 	if (start_pfn < nr_pages)
 		*released += xen_release_chunk(
 			start_pfn, min(end_pfn, nr_pages));
> +				}
> +			}
>  			start = end;
>  		}
>  	}
> @@ -500,10 +527,9 @@ void __cpuinit xen_enable_syscall(void)
>  #endif /* CONFIG_X86_64 */
>  }
>  
> -void __init xen_arch_setup(void)
> +/* Non auto translated PV domain, ie, it's not PVH. */
> +static __init void inline xen_non_pvh_arch_setup(void)
>  {
> -	xen_panic_handler_init();
> -
>  	HYPERVISOR_vm_assist(VMASST_CMD_enable, VMASST_TYPE_4gb_segments);
>  	HYPERVISOR_vm_assist(VMASST_CMD_enable, VMASST_TYPE_writable_pagetables);
>  
> @@ -517,6 +543,15 @@ void __init xen_arch_setup(void)
>  
>  	xen_enable_sysenter();
>  	xen_enable_syscall();
> +}
> +
> +/* This function not called for HVM domain */
> +void __init xen_arch_setup(void)
> +{
> +	xen_panic_handler_init();
> +
> +	if (!xen_feature(XENFEAT_auto_translated_physmap))
> +		xen_non_pvh_arch_setup();
>  

I am not sure what the syscall functions have to do with parsing of the
E820.

You should split this patch in two - one that deals with the E820
parsing and another that deails with the setup of syscalls.

>  #ifdef CONFIG_ACPI
>  	if (!(xen_start_info->flags & SIF_INITDOMAIN)) {
> -- 
> 1.7.2.3
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 25 13:40:32 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 13: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 1TGVMu-00009z-5u; Tue, 25 Sep 2012 13:40: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 1TGVMt-00009u-ID
	for Xen-devel@lists.xensource.com; Tue, 25 Sep 2012 13:40:07 +0000
Received: from [85.158.137.99:19305] by server-11.bemta-3.messagelabs.com id
	EC/15-30250-634B1605; Tue, 25 Sep 2012 13:40:06 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-217.messagelabs.com!1348580405!16692050!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTEwNzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30540 invoked from network); 25 Sep 2012 13:40:06 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Sep 2012 13:40:06 -0000
X-IronPort-AV: E=Sophos;i="4.80,483,1344211200"; d="scan'208";a="14751762"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Sep 2012 13: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.279.1;
	Tue, 25 Sep 2012 14:39:42 +0100
Message-ID: <1348580381.11229.11.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Mukesh Rathor <mukesh.rathor@oracle.com>
Date: Tue, 25 Sep 2012 14:39:41 +0100
In-Reply-To: <20120921121928.1c5765bc@mantra.us.oracle.com>
References: <20120921121928.1c5765bc@mantra.us.oracle.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-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] [PATCH v1 6/8]: PVH ballooning and grant changes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-09-21 at 20:19 +0100, Mukesh Rathor wrote:
> ---
>  drivers/xen/balloon.c     |   35 ++++++++++++++++++++++++++++-------
>  drivers/xen/gntdev.c      |    3 ++-
>  drivers/xen/grant-table.c |   25 +++++++++++++++++++++----
>  3 files changed, 51 insertions(+), 12 deletions(-)
> 
> diff --git a/drivers/xen/balloon.c b/drivers/xen/balloon.c
> index 31ab82f..85a6917 100644
> --- a/drivers/xen/balloon.c
> +++ b/drivers/xen/balloon.c
> @@ -358,10 +358,21 @@ static enum bp_state increase_reservation(unsigned long nr_pages)
>  		BUG_ON(!xen_feature(XENFEAT_auto_translated_physmap) &&
>  		       phys_to_machine_mapping_valid(pfn));
>  
> -		set_phys_to_machine(pfn, frame_list[i]);
> +		if (xen_pv_domain() && 
> +		    xen_feature(XENFEAT_auto_translated_physmap)) {
> +			/* PVH: we just need to update native page table */

Do you not need a PageHighMem check here somewhere? (although this is
moot if you follow the suggestion below)

> +			pte_t *ptep;
> +			unsigned int level;
> +			void *addr = __va(pfn << PAGE_SHIFT);
> +			ptep = lookup_address((unsigned long)addr, &level);
> +			set_pte(ptep, pfn_pte(pfn, PAGE_KERNEL));
> +		} else
> +			set_phys_to_machine(pfn, frame_list[i]);
>  
>  		/* Link back into the page tables if not highmem. */
> -		if (xen_pv_domain() && !PageHighMem(page)) {
> +		if (xen_pv_domain() && !PageHighMem(page) && 
> +		    !xen_feature(XENFEAT_auto_translated_physmap)) {

I think it would be more logical to put the PVH PT update here next to
the PV PT update and gate the set_phys_to_machine above on !a_t_pm, like
how you've done it in the decrease case.

(or perhaps per your comment below set_phys_to_machine isa NOP also on
PVH?)

> +
>  			int ret;
>  			ret = HYPERVISOR_update_va_mapping(
>  				(unsigned long)__va(pfn << PAGE_SHIFT),
> @@ -418,12 +429,21 @@ static enum bp_state decrease_reservation(unsigned long nr_pages, gfp_t gfp)
>  		scrub_page(page);
>  
>  		if (xen_pv_domain() && !PageHighMem(page)) {
> -			ret = HYPERVISOR_update_va_mapping(
> -				(unsigned long)__va(pfn << PAGE_SHIFT),
> -				__pte_ma(0), 0);
> -			BUG_ON(ret);
> +			if (xen_feature(XENFEAT_auto_translated_physmap)) {
> +				unsigned int level;
> +				pte_t *ptep;
> +				void *addr = __va(pfn << PAGE_SHIFT);
> +				ptep = lookup_address((unsigned long)addr, 
> +							&level);
> +				set_pte(ptep, __pte(0));
> +
> +			} else {
> +				ret = HYPERVISOR_update_va_mapping(
> +					(unsigned long)__va(pfn << PAGE_SHIFT),
> +					__pte_ma(0), 0);
> +				BUG_ON(ret);
> +			}
>  		}
> -
>  	}
>  
>  	/* Ensure that ballooned highmem pages don't have kmaps. */
> @@ -433,6 +453,7 @@ static enum bp_state decrease_reservation(unsigned long nr_pages, gfp_t gfp)
>  	/* No more mappings: invalidate P2M and add to balloon. */
>  	for (i = 0; i < nr_pages; i++) {
>  		pfn = mfn_to_pfn(frame_list[i]);
> +		/* PVH note: following will noop for auto translated */
>  		__set_phys_to_machine(pfn, INVALID_P2M_ENTRY);
>  		balloon_append(pfn_to_page(pfn));
>  	}
> diff --git a/drivers/xen/gntdev.c b/drivers/xen/gntdev.c
> index 1ffd03b..35d1e3c 100644
> --- a/drivers/xen/gntdev.c
> +++ b/drivers/xen/gntdev.c
> @@ -802,7 +802,8 @@ static int __init gntdev_init(void)
>  	if (!xen_domain())
>  		return -ENODEV;
>  
> -	use_ptemod = xen_pv_domain();
> +	use_ptemod = xen_pv_domain() && 
> +		     !xen_feature(XENFEAT_auto_translated_physmap);

I keep wondering if
#define XENFEAT(x) xen_feature(XENFEAT_#x)
might not be useful to keep some of these long lines under control.

Probably not, since the bulk is the "x" bit...

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 25 13:40:32 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 13: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 1TGVMu-00009z-5u; Tue, 25 Sep 2012 13:40: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 1TGVMt-00009u-ID
	for Xen-devel@lists.xensource.com; Tue, 25 Sep 2012 13:40:07 +0000
Received: from [85.158.137.99:19305] by server-11.bemta-3.messagelabs.com id
	EC/15-30250-634B1605; Tue, 25 Sep 2012 13:40:06 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-217.messagelabs.com!1348580405!16692050!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTEwNzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30540 invoked from network); 25 Sep 2012 13:40:06 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Sep 2012 13:40:06 -0000
X-IronPort-AV: E=Sophos;i="4.80,483,1344211200"; d="scan'208";a="14751762"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Sep 2012 13: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.279.1;
	Tue, 25 Sep 2012 14:39:42 +0100
Message-ID: <1348580381.11229.11.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Mukesh Rathor <mukesh.rathor@oracle.com>
Date: Tue, 25 Sep 2012 14:39:41 +0100
In-Reply-To: <20120921121928.1c5765bc@mantra.us.oracle.com>
References: <20120921121928.1c5765bc@mantra.us.oracle.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-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] [PATCH v1 6/8]: PVH ballooning and grant changes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-09-21 at 20:19 +0100, Mukesh Rathor wrote:
> ---
>  drivers/xen/balloon.c     |   35 ++++++++++++++++++++++++++++-------
>  drivers/xen/gntdev.c      |    3 ++-
>  drivers/xen/grant-table.c |   25 +++++++++++++++++++++----
>  3 files changed, 51 insertions(+), 12 deletions(-)
> 
> diff --git a/drivers/xen/balloon.c b/drivers/xen/balloon.c
> index 31ab82f..85a6917 100644
> --- a/drivers/xen/balloon.c
> +++ b/drivers/xen/balloon.c
> @@ -358,10 +358,21 @@ static enum bp_state increase_reservation(unsigned long nr_pages)
>  		BUG_ON(!xen_feature(XENFEAT_auto_translated_physmap) &&
>  		       phys_to_machine_mapping_valid(pfn));
>  
> -		set_phys_to_machine(pfn, frame_list[i]);
> +		if (xen_pv_domain() && 
> +		    xen_feature(XENFEAT_auto_translated_physmap)) {
> +			/* PVH: we just need to update native page table */

Do you not need a PageHighMem check here somewhere? (although this is
moot if you follow the suggestion below)

> +			pte_t *ptep;
> +			unsigned int level;
> +			void *addr = __va(pfn << PAGE_SHIFT);
> +			ptep = lookup_address((unsigned long)addr, &level);
> +			set_pte(ptep, pfn_pte(pfn, PAGE_KERNEL));
> +		} else
> +			set_phys_to_machine(pfn, frame_list[i]);
>  
>  		/* Link back into the page tables if not highmem. */
> -		if (xen_pv_domain() && !PageHighMem(page)) {
> +		if (xen_pv_domain() && !PageHighMem(page) && 
> +		    !xen_feature(XENFEAT_auto_translated_physmap)) {

I think it would be more logical to put the PVH PT update here next to
the PV PT update and gate the set_phys_to_machine above on !a_t_pm, like
how you've done it in the decrease case.

(or perhaps per your comment below set_phys_to_machine isa NOP also on
PVH?)

> +
>  			int ret;
>  			ret = HYPERVISOR_update_va_mapping(
>  				(unsigned long)__va(pfn << PAGE_SHIFT),
> @@ -418,12 +429,21 @@ static enum bp_state decrease_reservation(unsigned long nr_pages, gfp_t gfp)
>  		scrub_page(page);
>  
>  		if (xen_pv_domain() && !PageHighMem(page)) {
> -			ret = HYPERVISOR_update_va_mapping(
> -				(unsigned long)__va(pfn << PAGE_SHIFT),
> -				__pte_ma(0), 0);
> -			BUG_ON(ret);
> +			if (xen_feature(XENFEAT_auto_translated_physmap)) {
> +				unsigned int level;
> +				pte_t *ptep;
> +				void *addr = __va(pfn << PAGE_SHIFT);
> +				ptep = lookup_address((unsigned long)addr, 
> +							&level);
> +				set_pte(ptep, __pte(0));
> +
> +			} else {
> +				ret = HYPERVISOR_update_va_mapping(
> +					(unsigned long)__va(pfn << PAGE_SHIFT),
> +					__pte_ma(0), 0);
> +				BUG_ON(ret);
> +			}
>  		}
> -
>  	}
>  
>  	/* Ensure that ballooned highmem pages don't have kmaps. */
> @@ -433,6 +453,7 @@ static enum bp_state decrease_reservation(unsigned long nr_pages, gfp_t gfp)
>  	/* No more mappings: invalidate P2M and add to balloon. */
>  	for (i = 0; i < nr_pages; i++) {
>  		pfn = mfn_to_pfn(frame_list[i]);
> +		/* PVH note: following will noop for auto translated */
>  		__set_phys_to_machine(pfn, INVALID_P2M_ENTRY);
>  		balloon_append(pfn_to_page(pfn));
>  	}
> diff --git a/drivers/xen/gntdev.c b/drivers/xen/gntdev.c
> index 1ffd03b..35d1e3c 100644
> --- a/drivers/xen/gntdev.c
> +++ b/drivers/xen/gntdev.c
> @@ -802,7 +802,8 @@ static int __init gntdev_init(void)
>  	if (!xen_domain())
>  		return -ENODEV;
>  
> -	use_ptemod = xen_pv_domain();
> +	use_ptemod = xen_pv_domain() && 
> +		     !xen_feature(XENFEAT_auto_translated_physmap);

I keep wondering if
#define XENFEAT(x) xen_feature(XENFEAT_#x)
might not be useful to keep some of these long lines under control.

Probably not, since the bulk is the "x" bit...

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 25 13:45:16 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 13: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 1TGVRe-0000Pk-IK; Tue, 25 Sep 2012 13:45:02 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1TGVRc-0000Pd-QC
	for Xen-devel@lists.xensource.com; Tue, 25 Sep 2012 13:45:01 +0000
Received: from [85.158.138.51:38721] by server-12.bemta-3.messagelabs.com id
	47/12-10384-C55B1605; Tue, 25 Sep 2012 13:45:00 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1348580699!31407653!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTEwNzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9132 invoked from network); 25 Sep 2012 13:44:59 -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;
	25 Sep 2012 13:44:59 -0000
X-IronPort-AV: E=Sophos;i="4.80,483,1344211200"; d="scan'208";a="14751924"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Sep 2012 13: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.279.1;
	Tue, 25 Sep 2012 14:44:27 +0100
Message-ID: <1348580666.11229.15.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Date: Tue, 25 Sep 2012 14:44:26 +0100
In-Reply-To: <alpine.DEB.2.02.1209241504410.29232@kaball.uk.xensource.com>
References: <20120921122123.33489ce1@mantra.us.oracle.com>
	<alpine.DEB.2.02.1209241504410.29232@kaball.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH v1 7/8]: PVH privcmd changes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2012-09-24 at 15:24 +0100, Stefano Stabellini wrote:
> On Fri, 21 Sep 2012, Mukesh Rathor wrote:
> > ---
> >  drivers/xen/privcmd.c |   77 ++++++++++++++++++++++++++++++++++++++++++++----
> >  1 files changed, 70 insertions(+), 7 deletions(-)
> > 
> > diff --git a/drivers/xen/privcmd.c b/drivers/xen/privcmd.c
> > index ccee0f1..195d89f 100644
> > --- a/drivers/xen/privcmd.c
> > +++ b/drivers/xen/privcmd.c
> > @@ -33,6 +33,7 @@
> >  #include <xen/features.h>
> >  #include <xen/page.h>
> >  #include <xen/xen-ops.h>
> > +#include <xen/balloon.h>
> >  
> >  #include "privcmd.h"
> >  
> > @@ -178,7 +179,7 @@ static int mmap_mfn_range(void *data, void *state)
> >  					msg->va & PAGE_MASK,
> >  					msg->mfn, msg->npages,
> >  					vma->vm_page_prot,
> > -					st->domain);
> > +					st->domain, NULL);
> >  	if (rc < 0)
> >  		return rc;
> >  
> > @@ -199,6 +200,10 @@ static long privcmd_ioctl_mmap(void __user *udata)
> >  	if (!xen_initial_domain())
> >  		return -EPERM;
> >  
> > +	/* PVH: TBD/FIXME. For now we only support privcmd_ioctl_mmap_batch */
> > +	if (xen_pv_domain() && xen_feature(XENFEAT_auto_translated_physmap))
> > +		return -ENOSYS;
> > +
> >  	if (copy_from_user(&mmapcmd, udata, sizeof(mmapcmd)))
> >  		return -EFAULT;
> >  
> > @@ -251,13 +256,18 @@ struct mmap_batch_state {
> >  	xen_pfn_t __user *user;
> >  };
> >  
> > +/* PVH dom0 fyi: if domU being created is PV, then mfn is mfn(addr on bus). If 
> > + * it's PVH then mfn is pfn (input to HAP). */
> >  static int mmap_batch_fn(void *data, void *state)
> >  {
> >  	xen_pfn_t *mfnp = data;
> >  	struct mmap_batch_state *st = state;
> > +	struct vm_area_struct *vma = st->vma;
> > +	struct xen_pvh_pfn_info *pvhp = vma ? vma->vm_private_data : NULL;
> >  
> > -	if (xen_remap_domain_mfn_range(st->vma, st->va & PAGE_MASK, *mfnp, 1,
> > -				       st->vma->vm_page_prot, st->domain) < 0) {
> > +	if (xen_remap_domain_mfn_range(vma, st->va & PAGE_MASK, *mfnp, 1,
> > +				       vma->vm_page_prot, st->domain, 
> > +				       pvhp) < 0) {
> >  		*mfnp |= 0xf0000000U;
> >  		st->err++;
> >  	}
> 
> I don't like that a parameter like "xen_pvh_pfn_info" has been added to
> a generic arch-agnostic function like xen_remap_domain_mfn_range.

This might have been my suggestion but actually I was thinking more
along the lines of what you suggest :

> If you need to pass more parameters to xen_remap_domain_mfn_range, it
> should be done in a cross-architecture way. In fact, keep in mind that
> privcmd.c compiles on ARM (and IA64?) as well.
> 
> I think that in this particular case you are using pvh to actually
> specify auto_translate_physmap, am I correct?
> Maybe we just need to rename xen_pvh_pfn_info to xen_xlat_pfn_info.

Or perhaps passing pvhp->pages as the new argument.

> > @@ -315,6 +359,12 @@ static long privcmd_ioctl_mmap_batch(void __user *udata)
> >  		goto out;
> >  	}
> >  
> > +	if (xen_pv_domain() && xen_feature(XENFEAT_auto_translated_physmap)) {
> > +		if ((ret=pvh_privcmd_resv_pfns(vma, m.num))) {
> 
> I would change this into:
> 
>     if ((ret = pvh_privcmd_resv_pfns(vma, m.num)) < 0) {

I thought assignment in if statements was frowned upon by CodingStyle,
although having looked the only bit which backs that up is "Kernel
coding style is super simple.  Avoid tricky expressions." which isn't
exactly explicit.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 25 13:45:16 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 13: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 1TGVRe-0000Pk-IK; Tue, 25 Sep 2012 13:45:02 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1TGVRc-0000Pd-QC
	for Xen-devel@lists.xensource.com; Tue, 25 Sep 2012 13:45:01 +0000
Received: from [85.158.138.51:38721] by server-12.bemta-3.messagelabs.com id
	47/12-10384-C55B1605; Tue, 25 Sep 2012 13:45:00 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1348580699!31407653!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTEwNzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9132 invoked from network); 25 Sep 2012 13:44:59 -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;
	25 Sep 2012 13:44:59 -0000
X-IronPort-AV: E=Sophos;i="4.80,483,1344211200"; d="scan'208";a="14751924"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Sep 2012 13: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.279.1;
	Tue, 25 Sep 2012 14:44:27 +0100
Message-ID: <1348580666.11229.15.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Date: Tue, 25 Sep 2012 14:44:26 +0100
In-Reply-To: <alpine.DEB.2.02.1209241504410.29232@kaball.uk.xensource.com>
References: <20120921122123.33489ce1@mantra.us.oracle.com>
	<alpine.DEB.2.02.1209241504410.29232@kaball.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH v1 7/8]: PVH privcmd changes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2012-09-24 at 15:24 +0100, Stefano Stabellini wrote:
> On Fri, 21 Sep 2012, Mukesh Rathor wrote:
> > ---
> >  drivers/xen/privcmd.c |   77 ++++++++++++++++++++++++++++++++++++++++++++----
> >  1 files changed, 70 insertions(+), 7 deletions(-)
> > 
> > diff --git a/drivers/xen/privcmd.c b/drivers/xen/privcmd.c
> > index ccee0f1..195d89f 100644
> > --- a/drivers/xen/privcmd.c
> > +++ b/drivers/xen/privcmd.c
> > @@ -33,6 +33,7 @@
> >  #include <xen/features.h>
> >  #include <xen/page.h>
> >  #include <xen/xen-ops.h>
> > +#include <xen/balloon.h>
> >  
> >  #include "privcmd.h"
> >  
> > @@ -178,7 +179,7 @@ static int mmap_mfn_range(void *data, void *state)
> >  					msg->va & PAGE_MASK,
> >  					msg->mfn, msg->npages,
> >  					vma->vm_page_prot,
> > -					st->domain);
> > +					st->domain, NULL);
> >  	if (rc < 0)
> >  		return rc;
> >  
> > @@ -199,6 +200,10 @@ static long privcmd_ioctl_mmap(void __user *udata)
> >  	if (!xen_initial_domain())
> >  		return -EPERM;
> >  
> > +	/* PVH: TBD/FIXME. For now we only support privcmd_ioctl_mmap_batch */
> > +	if (xen_pv_domain() && xen_feature(XENFEAT_auto_translated_physmap))
> > +		return -ENOSYS;
> > +
> >  	if (copy_from_user(&mmapcmd, udata, sizeof(mmapcmd)))
> >  		return -EFAULT;
> >  
> > @@ -251,13 +256,18 @@ struct mmap_batch_state {
> >  	xen_pfn_t __user *user;
> >  };
> >  
> > +/* PVH dom0 fyi: if domU being created is PV, then mfn is mfn(addr on bus). If 
> > + * it's PVH then mfn is pfn (input to HAP). */
> >  static int mmap_batch_fn(void *data, void *state)
> >  {
> >  	xen_pfn_t *mfnp = data;
> >  	struct mmap_batch_state *st = state;
> > +	struct vm_area_struct *vma = st->vma;
> > +	struct xen_pvh_pfn_info *pvhp = vma ? vma->vm_private_data : NULL;
> >  
> > -	if (xen_remap_domain_mfn_range(st->vma, st->va & PAGE_MASK, *mfnp, 1,
> > -				       st->vma->vm_page_prot, st->domain) < 0) {
> > +	if (xen_remap_domain_mfn_range(vma, st->va & PAGE_MASK, *mfnp, 1,
> > +				       vma->vm_page_prot, st->domain, 
> > +				       pvhp) < 0) {
> >  		*mfnp |= 0xf0000000U;
> >  		st->err++;
> >  	}
> 
> I don't like that a parameter like "xen_pvh_pfn_info" has been added to
> a generic arch-agnostic function like xen_remap_domain_mfn_range.

This might have been my suggestion but actually I was thinking more
along the lines of what you suggest :

> If you need to pass more parameters to xen_remap_domain_mfn_range, it
> should be done in a cross-architecture way. In fact, keep in mind that
> privcmd.c compiles on ARM (and IA64?) as well.
> 
> I think that in this particular case you are using pvh to actually
> specify auto_translate_physmap, am I correct?
> Maybe we just need to rename xen_pvh_pfn_info to xen_xlat_pfn_info.

Or perhaps passing pvhp->pages as the new argument.

> > @@ -315,6 +359,12 @@ static long privcmd_ioctl_mmap_batch(void __user *udata)
> >  		goto out;
> >  	}
> >  
> > +	if (xen_pv_domain() && xen_feature(XENFEAT_auto_translated_physmap)) {
> > +		if ((ret=pvh_privcmd_resv_pfns(vma, m.num))) {
> 
> I would change this into:
> 
>     if ((ret = pvh_privcmd_resv_pfns(vma, m.num)) < 0) {

I thought assignment in if statements was frowned upon by CodingStyle,
although having looked the only bit which backs that up is "Kernel
coding style is super simple.  Avoid tricky expressions." which isn't
exactly explicit.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 25 13:46:37 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 13:46:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGVSx-0000ZO-6f; Tue, 25 Sep 2012 13:46:23 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1TGVSw-0000ZE-H2
	for Xen-devel@lists.xensource.com; Tue, 25 Sep 2012 13:46:22 +0000
Received: from [85.158.139.211:17291] by server-7.bemta-5.messagelabs.com id
	96/1F-00431-DA5B1605; Tue, 25 Sep 2012 13:46:21 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-206.messagelabs.com!1348580779!19917932!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTEwNzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32006 invoked from network); 25 Sep 2012 13:46:20 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Sep 2012 13:46:20 -0000
X-IronPort-AV: E=Sophos;i="4.80,483,1344211200"; d="scan'208";a="14751974"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Sep 2012 13:46:19 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Tue, 25 Sep 2012 14:46:19 +0100
Message-ID: <1348580778.11229.17.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Mukesh Rathor <mukesh.rathor@oracle.com>
Date: Tue, 25 Sep 2012 14:46:18 +0100
In-Reply-To: <20120921122123.33489ce1@mantra.us.oracle.com>
References: <20120921122123.33489ce1@mantra.us.oracle.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-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] [PATCH v1 7/8]: PVH privcmd 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

> 		pr_warn("%s Could not alloc %d pfns rc:%d\n", __FUNCTION__, 
> +			numpgs, rc);

IIRC __FUNCTION__ is a deprecated gcc'ism replaced by C99's __func__.

checkpatch.pl warns about this.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 25 13:46:37 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 13:46:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGVSx-0000ZO-6f; Tue, 25 Sep 2012 13:46:23 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1TGVSw-0000ZE-H2
	for Xen-devel@lists.xensource.com; Tue, 25 Sep 2012 13:46:22 +0000
Received: from [85.158.139.211:17291] by server-7.bemta-5.messagelabs.com id
	96/1F-00431-DA5B1605; Tue, 25 Sep 2012 13:46:21 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-206.messagelabs.com!1348580779!19917932!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTEwNzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32006 invoked from network); 25 Sep 2012 13:46:20 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Sep 2012 13:46:20 -0000
X-IronPort-AV: E=Sophos;i="4.80,483,1344211200"; d="scan'208";a="14751974"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Sep 2012 13:46:19 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Tue, 25 Sep 2012 14:46:19 +0100
Message-ID: <1348580778.11229.17.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Mukesh Rathor <mukesh.rathor@oracle.com>
Date: Tue, 25 Sep 2012 14:46:18 +0100
In-Reply-To: <20120921122123.33489ce1@mantra.us.oracle.com>
References: <20120921122123.33489ce1@mantra.us.oracle.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-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] [PATCH v1 7/8]: PVH privcmd 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

> 		pr_warn("%s Could not alloc %d pfns rc:%d\n", __FUNCTION__, 
> +			numpgs, rc);

IIRC __FUNCTION__ is a deprecated gcc'ism replaced by C99's __func__.

checkpatch.pl warns about this.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 25 13:47:28 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 13:47:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGVTn-0000fr-LV; Tue, 25 Sep 2012 13:47: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 1TGVTm-0000fP-2o
	for Xen-devel@lists.xensource.com; Tue, 25 Sep 2012 13:47:14 +0000
Received: from [85.158.139.83:44057] by server-10.bemta-5.messagelabs.com id
	A5/59-16911-1E5B1605; Tue, 25 Sep 2012 13:47:13 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1348580830!31390516!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTEwNzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24535 invoked from network); 25 Sep 2012 13:47:12 -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;
	25 Sep 2012 13:47:12 -0000
X-IronPort-AV: E=Sophos;i="4.80,483,1344211200"; d="scan'208";a="14751993"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Sep 2012 13:47:10 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Tue, 25 Sep 2012 14:47:08 +0100
Message-ID: <1348580827.11229.18.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Mukesh Rathor <mukesh.rathor@oracle.com>
Date: Tue, 25 Sep 2012 14:47:07 +0100
In-Reply-To: <20120921121202.3163c379@mantra.us.oracle.com>
References: <20120921121202.3163c379@mantra.us.oracle.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-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] [PATCH v1 0/8]: PVH (PV guest with extensions)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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-09-21 at 20:12 +0100, Mukesh Rathor wrote:
> Hi guys,
> 
> Ok, I've made all the changes from prev RFC patch submission. Tested
> all the combinations. The patches are a bit smaller from before, and
> couldn't be separated like before, so I can't state whats different in
> each patch. But, it's not too bad to review now.

FYI I've actually read through all of them, I just didn't have much to
say because Stefano already said most of what I would have said.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 25 13:47:28 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 13:47:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGVTn-0000fr-LV; Tue, 25 Sep 2012 13:47: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 1TGVTm-0000fP-2o
	for Xen-devel@lists.xensource.com; Tue, 25 Sep 2012 13:47:14 +0000
Received: from [85.158.139.83:44057] by server-10.bemta-5.messagelabs.com id
	A5/59-16911-1E5B1605; Tue, 25 Sep 2012 13:47:13 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1348580830!31390516!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTEwNzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24535 invoked from network); 25 Sep 2012 13:47:12 -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;
	25 Sep 2012 13:47:12 -0000
X-IronPort-AV: E=Sophos;i="4.80,483,1344211200"; d="scan'208";a="14751993"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Sep 2012 13:47:10 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Tue, 25 Sep 2012 14:47:08 +0100
Message-ID: <1348580827.11229.18.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Mukesh Rathor <mukesh.rathor@oracle.com>
Date: Tue, 25 Sep 2012 14:47:07 +0100
In-Reply-To: <20120921121202.3163c379@mantra.us.oracle.com>
References: <20120921121202.3163c379@mantra.us.oracle.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-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] [PATCH v1 0/8]: PVH (PV guest with extensions)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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-09-21 at 20:12 +0100, Mukesh Rathor wrote:
> Hi guys,
> 
> Ok, I've made all the changes from prev RFC patch submission. Tested
> all the combinations. The patches are a bit smaller from before, and
> couldn't be separated like before, so I can't state whats different in
> each patch. But, it's not too bad to review now.

FYI I've actually read through all of them, I just didn't have much to
say because Stefano already said most of what I would have said.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 25 13:55:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 13: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 1TGVbF-0001Fe-SP; Tue, 25 Sep 2012 13:54:57 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony.perard@citrix.com>) id 1TGVbE-0001FP-48
	for xen-devel@lists.xen.org; Tue, 25 Sep 2012 13:54:56 +0000
Received: from [85.158.137.99:35205] by server-2.bemta-3.messagelabs.com id
	3D/56-04862-FA7B1605; Tue, 25 Sep 2012 13:54:55 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-5.tower-217.messagelabs.com!1348581293!14319060!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzEyNDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8829 invoked from network); 25 Sep 2012 13:54:54 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-5.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Sep 2012 13:54:54 -0000
X-IronPort-AV: E=Sophos;i="4.80,483,1344211200"; d="scan'208";a="39086541"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Sep 2012 13:54:53 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Tue, 25 Sep 2012 09:54:52 -0400
Received: from [10.80.3.61]	by ukmail1.uk.xensource.com with esmtp (Exim 4.69)
	(envelope-from <anthony.perard@citrix.com>)	id 1TGVbA-0006Pq-8g;
	Tue, 25 Sep 2012 14:54:52 +0100
Message-ID: <5061B7AC.508@citrix.com>
Date: Tue, 25 Sep 2012 14:54:52 +0100
From: Anthony PERARD <anthony.perard@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120910 Thunderbird/15.0.1
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <1347906148-9606-1-git-send-email-anthony.perard@citrix.com>
	<1347906148-9606-2-git-send-email-anthony.perard@citrix.com>
	<1348562359.3452.112.camel@zakaz.uk.xensource.com>
In-Reply-To: <1348562359.3452.112.camel@zakaz.uk.xensource.com>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Xen Devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH V2 1/9] libxl_json: Use libxl alloc function
	with 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 09/25/2012 09:39 AM, Ian Campbell wrote:
> On Mon, 2012-09-17 at 19:22 +0100, Anthony PERARD wrote:
>> This patch makes use of the libxl allocation API and removes the check for
>> allocation failure.
>>
>> Also we don't use GC with a json_object because this structure use flexarray
>> and the latter does not use the gc.
> 
> It's not an uncommon pattern in libxl for the content of the flexarray
> to be gc'd but the actual array itself to be explicitly freed, often
> implicitly via flexarray_contents(), if that's what you want.

Trying to use flexarray_contents() in the context of json_object would
mean that I need to know when the array is filled with every things
needed. This seams a bit complicated.

> If we wanted I don't think there's any reason we couldn't make the
> flexarray take a gc and use it, that would probably make things simpler
> here and elsewhere and reduce the manual memory management (unless you
> actually want/need that for some other reason).

Having flexarray using gc seams a better idea. I will work on that as I
don't think I need to keep those object around and using NOGC was only
because of flexarray.

>> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
>> ---
>>  tools/libxl/libxl_json.c | 37 +++++++++++--------------------------
>>  1 file changed, 11 insertions(+), 26 deletions(-)
>>
>> diff --git a/tools/libxl/libxl_json.c b/tools/libxl/libxl_json.c
>> index caa8312..9c3dca2 100644
>> --- a/tools/libxl/libxl_json.c
>> +++ b/tools/libxl/libxl_json.c
>> @@ -210,12 +210,7 @@ static libxl__json_object *json_object_alloc(libxl__gc *gc,
>>  {
>>      libxl__json_object *obj;
>>  
>> -    obj = calloc(1, sizeof (libxl__json_object));
>> -    if (obj == NULL) {
>> -        LIBXL__LOG_ERRNO(libxl__gc_owner(gc), LIBXL__LOG_ERROR,
>> -                         "Failed to allocate a libxl__json_object");
>> -        return NULL;
>> -    }
>> +    obj = libxl__zalloc(NOGC, sizeof(*obj));
> 
> So you now ignore the gc passed in, which in any case you have now
> caused to always be NOGC? Seems a bit round-about to me, why not use the
> gc parameter here?

Yes, I suppose is not necessary to use NOGC here, and leave the choice
to the caller. I just wanted to be explicit.

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 Tue Sep 25 13:55:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 13: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 1TGVbF-0001Fe-SP; Tue, 25 Sep 2012 13:54:57 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony.perard@citrix.com>) id 1TGVbE-0001FP-48
	for xen-devel@lists.xen.org; Tue, 25 Sep 2012 13:54:56 +0000
Received: from [85.158.137.99:35205] by server-2.bemta-3.messagelabs.com id
	3D/56-04862-FA7B1605; Tue, 25 Sep 2012 13:54:55 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-5.tower-217.messagelabs.com!1348581293!14319060!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzEyNDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8829 invoked from network); 25 Sep 2012 13:54:54 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-5.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Sep 2012 13:54:54 -0000
X-IronPort-AV: E=Sophos;i="4.80,483,1344211200"; d="scan'208";a="39086541"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Sep 2012 13:54:53 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Tue, 25 Sep 2012 09:54:52 -0400
Received: from [10.80.3.61]	by ukmail1.uk.xensource.com with esmtp (Exim 4.69)
	(envelope-from <anthony.perard@citrix.com>)	id 1TGVbA-0006Pq-8g;
	Tue, 25 Sep 2012 14:54:52 +0100
Message-ID: <5061B7AC.508@citrix.com>
Date: Tue, 25 Sep 2012 14:54:52 +0100
From: Anthony PERARD <anthony.perard@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120910 Thunderbird/15.0.1
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <1347906148-9606-1-git-send-email-anthony.perard@citrix.com>
	<1347906148-9606-2-git-send-email-anthony.perard@citrix.com>
	<1348562359.3452.112.camel@zakaz.uk.xensource.com>
In-Reply-To: <1348562359.3452.112.camel@zakaz.uk.xensource.com>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Xen Devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH V2 1/9] libxl_json: Use libxl alloc function
	with 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 09/25/2012 09:39 AM, Ian Campbell wrote:
> On Mon, 2012-09-17 at 19:22 +0100, Anthony PERARD wrote:
>> This patch makes use of the libxl allocation API and removes the check for
>> allocation failure.
>>
>> Also we don't use GC with a json_object because this structure use flexarray
>> and the latter does not use the gc.
> 
> It's not an uncommon pattern in libxl for the content of the flexarray
> to be gc'd but the actual array itself to be explicitly freed, often
> implicitly via flexarray_contents(), if that's what you want.

Trying to use flexarray_contents() in the context of json_object would
mean that I need to know when the array is filled with every things
needed. This seams a bit complicated.

> If we wanted I don't think there's any reason we couldn't make the
> flexarray take a gc and use it, that would probably make things simpler
> here and elsewhere and reduce the manual memory management (unless you
> actually want/need that for some other reason).

Having flexarray using gc seams a better idea. I will work on that as I
don't think I need to keep those object around and using NOGC was only
because of flexarray.

>> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
>> ---
>>  tools/libxl/libxl_json.c | 37 +++++++++++--------------------------
>>  1 file changed, 11 insertions(+), 26 deletions(-)
>>
>> diff --git a/tools/libxl/libxl_json.c b/tools/libxl/libxl_json.c
>> index caa8312..9c3dca2 100644
>> --- a/tools/libxl/libxl_json.c
>> +++ b/tools/libxl/libxl_json.c
>> @@ -210,12 +210,7 @@ static libxl__json_object *json_object_alloc(libxl__gc *gc,
>>  {
>>      libxl__json_object *obj;
>>  
>> -    obj = calloc(1, sizeof (libxl__json_object));
>> -    if (obj == NULL) {
>> -        LIBXL__LOG_ERRNO(libxl__gc_owner(gc), LIBXL__LOG_ERROR,
>> -                         "Failed to allocate a libxl__json_object");
>> -        return NULL;
>> -    }
>> +    obj = libxl__zalloc(NOGC, sizeof(*obj));
> 
> So you now ignore the gc passed in, which in any case you have now
> caused to always be NOGC? Seems a bit round-about to me, why not use the
> gc parameter here?

Yes, I suppose is not necessary to use NOGC here, and leave the choice
to the caller. I just wanted to be explicit.

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 Tue Sep 25 13:55:30 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 13:55: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 1TGVbZ-0001JC-AN; Tue, 25 Sep 2012 13:55: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 1TGVbX-0001IX-8e
	for Xen-devel@lists.xensource.com; Tue, 25 Sep 2012 13:55:15 +0000
Received: from [85.158.143.99:62832] by server-3.bemta-4.messagelabs.com id
	0E/02-10986-2C7B1605; Tue, 25 Sep 2012 13:55:14 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1348581306!23523929!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTEwNzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8370 invoked from network); 25 Sep 2012 13:55:13 -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;
	25 Sep 2012 13:55:13 -0000
X-IronPort-AV: E=Sophos;i="4.80,483,1344211200"; d="scan'208";a="14752201"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Sep 2012 13:54:25 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Tue, 25 Sep 2012 14:54:25 +0100
Message-ID: <1348581263.11229.21.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Mukesh Rathor <mukesh.rathor@oracle.com>
Date: Tue, 25 Sep 2012 14:54:23 +0100
In-Reply-To: <20120921121202.3163c379@mantra.us.oracle.com>
References: <20120921121202.3163c379@mantra.us.oracle.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-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] [PATCH v1 0/8]: PVH (PV guest with extensions)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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-09-21 at 20:12 +0100, Mukesh Rathor wrote:
> Hi guys,
> 
> Ok, I've made all the changes from prev RFC patch submission.

Did I miss the patch with the changes to arch/x86/xen/xen-head.S which
declare the features which are used here as supported by the kernel
image?

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 25 13:55:30 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 13:55: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 1TGVbZ-0001JC-AN; Tue, 25 Sep 2012 13:55: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 1TGVbX-0001IX-8e
	for Xen-devel@lists.xensource.com; Tue, 25 Sep 2012 13:55:15 +0000
Received: from [85.158.143.99:62832] by server-3.bemta-4.messagelabs.com id
	0E/02-10986-2C7B1605; Tue, 25 Sep 2012 13:55:14 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1348581306!23523929!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTEwNzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8370 invoked from network); 25 Sep 2012 13:55:13 -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;
	25 Sep 2012 13:55:13 -0000
X-IronPort-AV: E=Sophos;i="4.80,483,1344211200"; d="scan'208";a="14752201"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Sep 2012 13:54:25 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Tue, 25 Sep 2012 14:54:25 +0100
Message-ID: <1348581263.11229.21.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Mukesh Rathor <mukesh.rathor@oracle.com>
Date: Tue, 25 Sep 2012 14:54:23 +0100
In-Reply-To: <20120921121202.3163c379@mantra.us.oracle.com>
References: <20120921121202.3163c379@mantra.us.oracle.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-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] [PATCH v1 0/8]: PVH (PV guest with extensions)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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-09-21 at 20:12 +0100, Mukesh Rathor wrote:
> Hi guys,
> 
> Ok, I've made all the changes from prev RFC patch submission.

Did I miss the patch with the changes to arch/x86/xen/xen-head.S which
declare the features which are used here as supported by the kernel
image?

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 25 14:11:02 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 14:11: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 1TGVqZ-0002Ap-Qy; Tue, 25 Sep 2012 14:10:47 +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 1TGVqY-0002Ak-4N
	for xen-devel@lists.xen.org; Tue, 25 Sep 2012 14:10:46 +0000
Received: from [85.158.137.99:4096] by server-7.bemta-3.messagelabs.com id
	F8/72-32000-56BB1605; Tue, 25 Sep 2012 14:10:45 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-5.tower-217.messagelabs.com!1348582244!14321592!1
X-Originating-IP: [74.125.83.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31535 invoked from network); 25 Sep 2012 14:10:44 -0000
Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com)
	(74.125.83.45)
	by server-5.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Sep 2012 14:10:44 -0000
Received: by eekb47 with SMTP id b47so1252687eek.32
	for <xen-devel@lists.xen.org>; Tue, 25 Sep 2012 07:10:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:user-agent:date:subject:from:to:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=DOZ4/FzUOw0mmuEwMBC1YTABA+Xivu2YZ9PsMObdwWI=;
	b=d9E7NsFa2EhMYX/F4wKf9cNz/tBEUnMEqPizwyaAu9ogKZxNFyo5EC87jC2LCQPNQC
	agl59qnwSKXtwGYb3tjf0HpQRaW0fS7+r9CAWMDweUlcLyXUBnS6assG5FU374F+kSXV
	h6XzhObVrI5eto9lBEo5WqDS6fNtIAU1h3yUihQmR/rHvdHBYpUMN89qjti7Y+Etnsyq
	oBPkUklPUO9z+kBndiXmvt1oG4FMSew0xfGd2ykdJIeGxu4X1VJZT+XHrFcqZk9mWkgQ
	nVrdTl+f1W/s5hG5nKaY9UYLSRtWGEXqxUDMDmuzmUuLHlP6f7FM4Ycf9r8m8xkK/vwe
	aCtw==
Received: by 10.14.220.8 with SMTP id n8mr19739839eep.19.1348582244128;
	Tue, 25 Sep 2012 07:10:44 -0700 (PDT)
Received: from [192.168.1.3] (host86-167-82-156.range86-167.btcentralplus.com.
	[86.167.82.156])
	by mx.google.com with ESMTPS id 46sm1161544eef.17.2012.09.25.07.10.39
	(version=SSLv3 cipher=OTHER); Tue, 25 Sep 2012 07:10:42 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.33.0.120411
Date: Tue, 25 Sep 2012 15:10:34 +0100
From: Keir Fraser <keir@xen.org>
To: Jan Beulich <JBeulich@suse.com>,
	xen-devel <xen-devel@lists.xen.org>
Message-ID: <CC8779EA.4CD5F%keir@xen.org>
Thread-Topic: [Xen-devel] [PATCH] x86: fix MWAIT-based idle driver for CPUs
	without ARAT
Thread-Index: Ac2bJ4dS/LgQTIeZjU+KK3L3Ugao+A==
In-Reply-To: <506059F9020000780009D46E@nat28.tlf.novell.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] [PATCH] x86: fix MWAIT-based idle driver for CPUs
 without ARAT
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/09/2012 12:02, "Jan Beulich" <JBeulich@suse.com> wrote:

> lapic_timer_{on,off} need to get initialized in this case. This in turn
> requires getting HPET broadcast setup to be carried out earlier (and
> hence preventing double initialization there).
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Acked-by: Keir Fraser <keir@xen.org>

> ---
> Note that I don't have a respective system available to test these
> adjustments (which is also why I didn't notice the omission from the
> original patch), so I can only hope that this works and takes care of
> the observed boot failure.
> 
> --- a/xen/arch/x86/acpi/cpu_idle.c
> +++ b/xen/arch/x86/acpi/cpu_idle.c
> @@ -74,6 +74,29 @@ static void lapic_timer_nop(void) { }
>  void (*__read_mostly lapic_timer_off)(void);
>  void (*__read_mostly lapic_timer_on)(void);
>  
> +bool_t lapic_timer_init(void)
> +{
> +    if ( boot_cpu_has(X86_FEATURE_ARAT) )
> +    {
> +        lapic_timer_off = lapic_timer_nop;
> +        lapic_timer_on = lapic_timer_nop;
> +    }
> +    else if ( hpet_broadcast_is_available() )
> +    {
> +        lapic_timer_off = hpet_broadcast_enter;
> +        lapic_timer_on = hpet_broadcast_exit;
> +    }
> +    else if ( pit_broadcast_is_available() )
> +    {
> +        lapic_timer_off = pit_broadcast_enter;
> +        lapic_timer_on = pit_broadcast_exit;
> +    }
> +    else
> +        return 0;
> +
> +    return 1;
> +}
> +
>  static uint64_t (*__read_mostly tick_to_ns)(uint64_t) = acpi_pm_tick_to_ns;
>  
>  void (*__read_mostly pm_idle_save)(void);
> @@ -789,25 +812,8 @@ static int check_cx(struct acpi_processo
>          if ( local_apic_timer_c2_ok )
>              break;
>      case ACPI_STATE_C3:
> -        if ( boot_cpu_has(X86_FEATURE_ARAT) )
> -        {
> -            lapic_timer_off = lapic_timer_nop;
> -            lapic_timer_on = lapic_timer_nop;
> -        }
> -        else if ( hpet_broadcast_is_available() )
> -        {
> -            lapic_timer_off = hpet_broadcast_enter;
> -            lapic_timer_on = hpet_broadcast_exit;
> -        }
> -        else if ( pit_broadcast_is_available() )
> -        {
> -            lapic_timer_off = pit_broadcast_enter;
> -            lapic_timer_on = pit_broadcast_exit;
> -        }
> -        else
> -        {
> +        if ( !lapic_timer_init() )
>              return -EINVAL;
> -        }
>  
>          /* All the logic here assumes flags.bm_check is same across all CPUs
> */
>          if ( bm_check_flag == -1 )
> --- a/xen/arch/x86/cpu/mwait-idle.c
> +++ b/xen/arch/x86/cpu/mwait-idle.c
> @@ -56,6 +56,7 @@
>  #include <xen/softirq.h>
>  #include <xen/trace.h>
>  #include <asm/cpuidle.h>
> +#include <asm/hpet.h>
>  #include <asm/mwait.h>
>  #include <asm/msr.h>
>  #include <acpi/cpufreq/cpufreq.h>
> @@ -501,6 +502,12 @@ int __init mwait_idle_init(struct notifi
>  
> err = mwait_idle_probe();
> if (!err) {
> +  if (!boot_cpu_has(X86_FEATURE_ARAT))
> +   hpet_broadcast_init();
> +  if (!lapic_timer_init())
> +   err = -EINVAL;
> + }
> + if (!err) {
> nfb->notifier_call = mwait_idle_cpu_init;
> mwait_idle_cpu_init(nfb, CPU_UP_PREPARE, NULL);
>  
> --- a/xen/arch/x86/hpet.c
> +++ b/xen/arch/x86/hpet.c
> @@ -495,7 +495,7 @@ void __init hpet_broadcast_init(void)
>      u32 hpet_id, cfg;
>      unsigned int i, n;
>  
> -    if ( hpet_rate == 0 )
> +    if ( hpet_rate == 0 || hpet_broadcast_is_available() )
>          return;
>  
>      cfg = hpet_read32(HPET_CFG);
> --- a/xen/include/asm-x86/cpuidle.h
> +++ b/xen/include/asm-x86/cpuidle.h
> @@ -10,6 +10,7 @@ extern struct acpi_processor_power *proc
>  
>  extern void (*pm_idle_save)(void);
>  
> +bool_t lapic_timer_init(void);
>  extern void (*lapic_timer_off)(void);
>  extern void (*lapic_timer_on)(void);
>  
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 25 14:11:02 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 14:11: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 1TGVqZ-0002Ap-Qy; Tue, 25 Sep 2012 14:10:47 +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 1TGVqY-0002Ak-4N
	for xen-devel@lists.xen.org; Tue, 25 Sep 2012 14:10:46 +0000
Received: from [85.158.137.99:4096] by server-7.bemta-3.messagelabs.com id
	F8/72-32000-56BB1605; Tue, 25 Sep 2012 14:10:45 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-5.tower-217.messagelabs.com!1348582244!14321592!1
X-Originating-IP: [74.125.83.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31535 invoked from network); 25 Sep 2012 14:10:44 -0000
Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com)
	(74.125.83.45)
	by server-5.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Sep 2012 14:10:44 -0000
Received: by eekb47 with SMTP id b47so1252687eek.32
	for <xen-devel@lists.xen.org>; Tue, 25 Sep 2012 07:10:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:user-agent:date:subject:from:to:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=DOZ4/FzUOw0mmuEwMBC1YTABA+Xivu2YZ9PsMObdwWI=;
	b=d9E7NsFa2EhMYX/F4wKf9cNz/tBEUnMEqPizwyaAu9ogKZxNFyo5EC87jC2LCQPNQC
	agl59qnwSKXtwGYb3tjf0HpQRaW0fS7+r9CAWMDweUlcLyXUBnS6assG5FU374F+kSXV
	h6XzhObVrI5eto9lBEo5WqDS6fNtIAU1h3yUihQmR/rHvdHBYpUMN89qjti7Y+Etnsyq
	oBPkUklPUO9z+kBndiXmvt1oG4FMSew0xfGd2ykdJIeGxu4X1VJZT+XHrFcqZk9mWkgQ
	nVrdTl+f1W/s5hG5nKaY9UYLSRtWGEXqxUDMDmuzmUuLHlP6f7FM4Ycf9r8m8xkK/vwe
	aCtw==
Received: by 10.14.220.8 with SMTP id n8mr19739839eep.19.1348582244128;
	Tue, 25 Sep 2012 07:10:44 -0700 (PDT)
Received: from [192.168.1.3] (host86-167-82-156.range86-167.btcentralplus.com.
	[86.167.82.156])
	by mx.google.com with ESMTPS id 46sm1161544eef.17.2012.09.25.07.10.39
	(version=SSLv3 cipher=OTHER); Tue, 25 Sep 2012 07:10:42 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.33.0.120411
Date: Tue, 25 Sep 2012 15:10:34 +0100
From: Keir Fraser <keir@xen.org>
To: Jan Beulich <JBeulich@suse.com>,
	xen-devel <xen-devel@lists.xen.org>
Message-ID: <CC8779EA.4CD5F%keir@xen.org>
Thread-Topic: [Xen-devel] [PATCH] x86: fix MWAIT-based idle driver for CPUs
	without ARAT
Thread-Index: Ac2bJ4dS/LgQTIeZjU+KK3L3Ugao+A==
In-Reply-To: <506059F9020000780009D46E@nat28.tlf.novell.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] [PATCH] x86: fix MWAIT-based idle driver for CPUs
 without ARAT
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/09/2012 12:02, "Jan Beulich" <JBeulich@suse.com> wrote:

> lapic_timer_{on,off} need to get initialized in this case. This in turn
> requires getting HPET broadcast setup to be carried out earlier (and
> hence preventing double initialization there).
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Acked-by: Keir Fraser <keir@xen.org>

> ---
> Note that I don't have a respective system available to test these
> adjustments (which is also why I didn't notice the omission from the
> original patch), so I can only hope that this works and takes care of
> the observed boot failure.
> 
> --- a/xen/arch/x86/acpi/cpu_idle.c
> +++ b/xen/arch/x86/acpi/cpu_idle.c
> @@ -74,6 +74,29 @@ static void lapic_timer_nop(void) { }
>  void (*__read_mostly lapic_timer_off)(void);
>  void (*__read_mostly lapic_timer_on)(void);
>  
> +bool_t lapic_timer_init(void)
> +{
> +    if ( boot_cpu_has(X86_FEATURE_ARAT) )
> +    {
> +        lapic_timer_off = lapic_timer_nop;
> +        lapic_timer_on = lapic_timer_nop;
> +    }
> +    else if ( hpet_broadcast_is_available() )
> +    {
> +        lapic_timer_off = hpet_broadcast_enter;
> +        lapic_timer_on = hpet_broadcast_exit;
> +    }
> +    else if ( pit_broadcast_is_available() )
> +    {
> +        lapic_timer_off = pit_broadcast_enter;
> +        lapic_timer_on = pit_broadcast_exit;
> +    }
> +    else
> +        return 0;
> +
> +    return 1;
> +}
> +
>  static uint64_t (*__read_mostly tick_to_ns)(uint64_t) = acpi_pm_tick_to_ns;
>  
>  void (*__read_mostly pm_idle_save)(void);
> @@ -789,25 +812,8 @@ static int check_cx(struct acpi_processo
>          if ( local_apic_timer_c2_ok )
>              break;
>      case ACPI_STATE_C3:
> -        if ( boot_cpu_has(X86_FEATURE_ARAT) )
> -        {
> -            lapic_timer_off = lapic_timer_nop;
> -            lapic_timer_on = lapic_timer_nop;
> -        }
> -        else if ( hpet_broadcast_is_available() )
> -        {
> -            lapic_timer_off = hpet_broadcast_enter;
> -            lapic_timer_on = hpet_broadcast_exit;
> -        }
> -        else if ( pit_broadcast_is_available() )
> -        {
> -            lapic_timer_off = pit_broadcast_enter;
> -            lapic_timer_on = pit_broadcast_exit;
> -        }
> -        else
> -        {
> +        if ( !lapic_timer_init() )
>              return -EINVAL;
> -        }
>  
>          /* All the logic here assumes flags.bm_check is same across all CPUs
> */
>          if ( bm_check_flag == -1 )
> --- a/xen/arch/x86/cpu/mwait-idle.c
> +++ b/xen/arch/x86/cpu/mwait-idle.c
> @@ -56,6 +56,7 @@
>  #include <xen/softirq.h>
>  #include <xen/trace.h>
>  #include <asm/cpuidle.h>
> +#include <asm/hpet.h>
>  #include <asm/mwait.h>
>  #include <asm/msr.h>
>  #include <acpi/cpufreq/cpufreq.h>
> @@ -501,6 +502,12 @@ int __init mwait_idle_init(struct notifi
>  
> err = mwait_idle_probe();
> if (!err) {
> +  if (!boot_cpu_has(X86_FEATURE_ARAT))
> +   hpet_broadcast_init();
> +  if (!lapic_timer_init())
> +   err = -EINVAL;
> + }
> + if (!err) {
> nfb->notifier_call = mwait_idle_cpu_init;
> mwait_idle_cpu_init(nfb, CPU_UP_PREPARE, NULL);
>  
> --- a/xen/arch/x86/hpet.c
> +++ b/xen/arch/x86/hpet.c
> @@ -495,7 +495,7 @@ void __init hpet_broadcast_init(void)
>      u32 hpet_id, cfg;
>      unsigned int i, n;
>  
> -    if ( hpet_rate == 0 )
> +    if ( hpet_rate == 0 || hpet_broadcast_is_available() )
>          return;
>  
>      cfg = hpet_read32(HPET_CFG);
> --- a/xen/include/asm-x86/cpuidle.h
> +++ b/xen/include/asm-x86/cpuidle.h
> @@ -10,6 +10,7 @@ extern struct acpi_processor_power *proc
>  
>  extern void (*pm_idle_save)(void);
>  
> +bool_t lapic_timer_init(void);
>  extern void (*lapic_timer_off)(void);
>  extern void (*lapic_timer_on)(void);
>  
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 25 14:13:32 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 14:13:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGVt3-0002G0-CO; Tue, 25 Sep 2012 14:13:21 +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 1TGVt1-0002Fu-EI
	for xen-devel@lists.xen.org; Tue, 25 Sep 2012 14:13:19 +0000
Received: from [85.158.138.51:2367] by server-3.bemta-3.messagelabs.com id
	31/46-21322-EFBB1605; Tue, 25 Sep 2012 14:13:18 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1348582397!24311992!1
X-Originating-IP: [74.125.83.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16067 invoked from network); 25 Sep 2012 14:13:18 -0000
Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com)
	(74.125.83.45)
	by server-10.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Sep 2012 14:13:18 -0000
Received: by eekb47 with SMTP id b47so1255496eek.32
	for <xen-devel@lists.xen.org>; Tue, 25 Sep 2012 07:13: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=VjBn3P903N1bzFuVro+YDCP3LdZGg+H3EGfhgeGpAXE=;
	b=kMq+gBhWV7/J1TKW/kFIgwUKftNSBorwcNie2BgjmZhWEdwMqDonDjzIXJVn9iARqp
	UWBx6+dH6d8LvvYKQyqDWYo1hy9FkDcZc2kbkONxqia2KUzquJX+c5UgJWzeY9wdnibc
	BRHvmDAyAy8w6eFq10huBZCvg2tbjH2l1I4rchMi8iUXCYaxt4ZG74hDQqPVhBwiQ6a5
	6WE65eUXspzJARrQK/CcYHDO/t7XGuB5uTQqYd1GUVKd23puXwh6NEbrQ9VNGJQvKKpZ
	xNzHUnjNdECu84NqAbdPqYCYffVL6Neey3vRMD/+ovAlqUQhffCypVSJx4A0yrWbDxy7
	Cr8Q==
Received: by 10.14.215.193 with SMTP id e41mr20368819eep.44.1348582397773;
	Tue, 25 Sep 2012 07:13:17 -0700 (PDT)
Received: from [192.168.1.3] (host86-167-82-156.range86-167.btcentralplus.com.
	[86.167.82.156])
	by mx.google.com with ESMTPS id u8sm1226751eel.11.2012.09.25.07.13.15
	(version=SSLv3 cipher=OTHER); Tue, 25 Sep 2012 07:13:16 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.33.0.120411
Date: Tue, 25 Sep 2012 15:13:12 +0100
From: Keir Fraser <keir@xen.org>
To: <xen-devel@lists.xen.org>
Message-ID: <CC877A88.4CD63%keir@xen.org>
Thread-Topic: [Xen-devel] [PATCH v2] xen/tools: Add 64 bits big bar support
Thread-Index: Ac2bJ+V/s57Tgddz6Ei2iezKPDKJGA==
In-Reply-To: <1348543998-31304-1-git-send-email-xudong.hao@intel.com>
Mime-version: 1.0
Cc: Xiantao Zhang <xiantao.zhang@intel.com>, Xudong Hao <xudong.hao@intel.com>,
	ian.campbell@citrix.com, jbeulich@suse.com,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v2] xen/tools: Add 64 bits big bar 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 25/09/2012 04:33, "" <> wrote:

> Currently it is assumed PCI device BAR access < 4G memory. If there is such a
> device whose BAR size is larger than 4G, it must access > 4G memory address.
> This patch enable the 64bits big BAR support on hvmloader.
> 
> Changes from v1:
> 1) Set Dynamic MMIO high memory address instead of a fixed number 640G
> 2) Mask bar_sz earlier to avoid older code changes
> 3) Add bar size barrier to judge high memory resource
> 4) Clean up bar64_relocate code
> 
> Signed-off-by: Xiantao Zhang <xiantao.zhang@intel.com>
> Signed-off-by: Xudong Hao <xudong.hao@intel.com>

...

> @@ -258,8 +298,8 @@
>          resource->base = base;
>  
>          pci_writel(devfn, bar_reg, bar_data);
> -        printf("pci dev %02x:%x bar %02x size %08x: %08x\n",
> -               devfn>>3, devfn&7, bar_reg, bar_sz, bar_data);
> +        if (using_64bar)
> +            pci_writel(devfn, bar_reg + 4, bar_data_upper);

Why is the printf removed?

 -- Keir


>          /* Now enable the memory or I/O mapping. */
>          cmd = pci_readw(devfn, PCI_COMMAND);
> diff -r dc56a9defa30 tools/firmware/hvmloader/util.h
> --- a/tools/firmware/hvmloader/util.h Tue Aug 14 10:28:14 2012 +0200
> +++ b/tools/firmware/hvmloader/util.h Wed Sep 12 14:50:55 2012 +0800
> @@ -215,6 +215,7 @@
>  uint32_t rombios_highbios_setup(void);
>  
>  /* Miscellaneous. */
> +unsigned int cpu_phys_addr(void);
>  void cacheattr_init(void);
>  unsigned long create_mp_tables(void *table);
>  void hvm_write_smbios_tables(
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Sep 25 14:13:32 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 14:13:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGVt3-0002G0-CO; Tue, 25 Sep 2012 14:13:21 +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 1TGVt1-0002Fu-EI
	for xen-devel@lists.xen.org; Tue, 25 Sep 2012 14:13:19 +0000
Received: from [85.158.138.51:2367] by server-3.bemta-3.messagelabs.com id
	31/46-21322-EFBB1605; Tue, 25 Sep 2012 14:13:18 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1348582397!24311992!1
X-Originating-IP: [74.125.83.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16067 invoked from network); 25 Sep 2012 14:13:18 -0000
Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com)
	(74.125.83.45)
	by server-10.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Sep 2012 14:13:18 -0000
Received: by eekb47 with SMTP id b47so1255496eek.32
	for <xen-devel@lists.xen.org>; Tue, 25 Sep 2012 07:13: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=VjBn3P903N1bzFuVro+YDCP3LdZGg+H3EGfhgeGpAXE=;
	b=kMq+gBhWV7/J1TKW/kFIgwUKftNSBorwcNie2BgjmZhWEdwMqDonDjzIXJVn9iARqp
	UWBx6+dH6d8LvvYKQyqDWYo1hy9FkDcZc2kbkONxqia2KUzquJX+c5UgJWzeY9wdnibc
	BRHvmDAyAy8w6eFq10huBZCvg2tbjH2l1I4rchMi8iUXCYaxt4ZG74hDQqPVhBwiQ6a5
	6WE65eUXspzJARrQK/CcYHDO/t7XGuB5uTQqYd1GUVKd23puXwh6NEbrQ9VNGJQvKKpZ
	xNzHUnjNdECu84NqAbdPqYCYffVL6Neey3vRMD/+ovAlqUQhffCypVSJx4A0yrWbDxy7
	Cr8Q==
Received: by 10.14.215.193 with SMTP id e41mr20368819eep.44.1348582397773;
	Tue, 25 Sep 2012 07:13:17 -0700 (PDT)
Received: from [192.168.1.3] (host86-167-82-156.range86-167.btcentralplus.com.
	[86.167.82.156])
	by mx.google.com with ESMTPS id u8sm1226751eel.11.2012.09.25.07.13.15
	(version=SSLv3 cipher=OTHER); Tue, 25 Sep 2012 07:13:16 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.33.0.120411
Date: Tue, 25 Sep 2012 15:13:12 +0100
From: Keir Fraser <keir@xen.org>
To: <xen-devel@lists.xen.org>
Message-ID: <CC877A88.4CD63%keir@xen.org>
Thread-Topic: [Xen-devel] [PATCH v2] xen/tools: Add 64 bits big bar support
Thread-Index: Ac2bJ+V/s57Tgddz6Ei2iezKPDKJGA==
In-Reply-To: <1348543998-31304-1-git-send-email-xudong.hao@intel.com>
Mime-version: 1.0
Cc: Xiantao Zhang <xiantao.zhang@intel.com>, Xudong Hao <xudong.hao@intel.com>,
	ian.campbell@citrix.com, jbeulich@suse.com,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v2] xen/tools: Add 64 bits big bar 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 25/09/2012 04:33, "" <> wrote:

> Currently it is assumed PCI device BAR access < 4G memory. If there is such a
> device whose BAR size is larger than 4G, it must access > 4G memory address.
> This patch enable the 64bits big BAR support on hvmloader.
> 
> Changes from v1:
> 1) Set Dynamic MMIO high memory address instead of a fixed number 640G
> 2) Mask bar_sz earlier to avoid older code changes
> 3) Add bar size barrier to judge high memory resource
> 4) Clean up bar64_relocate code
> 
> Signed-off-by: Xiantao Zhang <xiantao.zhang@intel.com>
> Signed-off-by: Xudong Hao <xudong.hao@intel.com>

...

> @@ -258,8 +298,8 @@
>          resource->base = base;
>  
>          pci_writel(devfn, bar_reg, bar_data);
> -        printf("pci dev %02x:%x bar %02x size %08x: %08x\n",
> -               devfn>>3, devfn&7, bar_reg, bar_sz, bar_data);
> +        if (using_64bar)
> +            pci_writel(devfn, bar_reg + 4, bar_data_upper);

Why is the printf removed?

 -- Keir


>          /* Now enable the memory or I/O mapping. */
>          cmd = pci_readw(devfn, PCI_COMMAND);
> diff -r dc56a9defa30 tools/firmware/hvmloader/util.h
> --- a/tools/firmware/hvmloader/util.h Tue Aug 14 10:28:14 2012 +0200
> +++ b/tools/firmware/hvmloader/util.h Wed Sep 12 14:50:55 2012 +0800
> @@ -215,6 +215,7 @@
>  uint32_t rombios_highbios_setup(void);
>  
>  /* Miscellaneous. */
> +unsigned int cpu_phys_addr(void);
>  void cacheattr_init(void);
>  unsigned long create_mp_tables(void *table);
>  void hvm_write_smbios_tables(
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Sep 25 14:15:52 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 14: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 1TGVvK-0002OS-Tv; Tue, 25 Sep 2012 14:15:42 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ketuzsezr@gmail.com>) id 1TGVvJ-0002OJ-7p
	for xen-devel@lists.xen.org; Tue, 25 Sep 2012 14:15:41 +0000
Received: from [85.158.139.83:7683] by server-3.bemta-5.messagelabs.com id
	D2/47-16108-C8CB1605; Tue, 25 Sep 2012 14:15:40 +0000
X-Env-Sender: ketuzsezr@gmail.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1348582538!31885549!1
X-Originating-IP: [209.85.216.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10312 invoked from network); 25 Sep 2012 14:15:39 -0000
Received: from mail-qa0-f45.google.com (HELO mail-qa0-f45.google.com)
	(209.85.216.45)
	by server-12.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Sep 2012 14:15:39 -0000
Received: by qaas11 with SMTP id s11so417700qaa.11
	for <xen-devel@lists.xen.org>; Tue, 25 Sep 2012 07:15: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=imqKqNqX3NUFxqWw9QD3B6qgM3zWevBzHh9Kfz8E2FI=;
	b=vKNzqLnHPYl0hgeh6H32HkAu8lZkibJJn8JaAEtgKwsEpIi6aNzNwCP8nB4wsFyny+
	CewABqRqovynr5S9zTIMepGn2Sl9tx4U28D+obt+5h2tVeORZaQJ/NS+1Gx4x+UpvRoJ
	lG1BheyTA0JVukVWNoqMw+hfkxWg8rlf3feojESi/J9es8MVT3qPcGHo4n4RHuLAv8lY
	knXwPe09XYx5i+Q9Xf4UcAgs+63hijf5eeb4yp6BMG7lO5O7CzV70hf6JRgrVcwlUc8w
	pRFOtlkR6e+cjcuPCvMz96v1E28azWnYBN5XirG/Fm96FhnYXgoTvIxyMWW/Amqk049G
	CbfA==
Received: by 10.224.185.148 with SMTP id co20mr40328857qab.4.1348582538296;
	Tue, 25 Sep 2012 07:15:38 -0700 (PDT)
Received: from phenom.dumpdata.com
	(50-195-21-189-static.hfc.comcastbusiness.net. [50.195.21.189])
	by mx.google.com with ESMTPS id dp3sm903879qab.21.2012.09.25.07.15.37
	(version=TLSv1/SSLv3 cipher=OTHER);
	Tue, 25 Sep 2012 07:15:37 -0700 (PDT)
Date: Tue, 25 Sep 2012 10:04:22 -0400
From: Konrad Rzeszutek Wilk <konrad@kernel.org>
To: Qian Hu <qianhu2011@gmail.com>
Message-ID: <20120925140421.GA16478@phenom.dumpdata.com>
References: <CALCpXpCvGkjZyG-NOY+fZY0q0f_DxuwPNEnxwKXVhjOe=gcHSQ@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CALCpXpCvGkjZyG-NOY+fZY0q0f_DxuwPNEnxwKXVhjOe=gcHSQ@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] usbpassthrough of xen-4.1.2 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, Sep 25, 2012 at 11:17:03AM +0800, Qian Hu wrote:
> Hi, everyone! The same question with updated message.
> 
> I am working on the USB passthrough of Xen-4.1.2. My host OS  is Fedora 14
> and the guest OS is win7.
> 
> According to the wiki page(http://wiki.xen.org/wiki/Xen_USB_Passthrough),
> 
> xen supports passthrough of usb device from dom0 to guests. I have tried
> the Xen HVM guest qemu-dm usb1.1 emulation,
> 
> by specifying "usb = 1" and "usbdevice = host:xxxx:yyyy". I have also tried
> the command usb_add host:xxxx:yyyy.

Do you also re-assign the device from the Linux kernel? Like this:

(the C408 0040 is my mouse).

 cd /sys/bus/usb/drivers/usbhid
 for a in `ls -1 | grep :`
 do
   for DEV in C408 0040
   do
        grep $DEV $a/modalias
        if [ $? -eq 0 ]; then
                echo "Unbinding $a for $DEV"
                echo $a > unbind
        fi
   done
 done

This is what the config file looks for me:
builder='hvm'
memory = 2048
name = "Windows7"
vcpus=3
disk = [ 'phy:/dev/vg_guest/Win7_Home,hda,w']
vnc=1
videoram=8
vnclisten="0.0.0.0"
vncpasswd=''
stdvga=0
serial='pty'
tsc_mode=0
usb=1
usb_add="host:045e:0040"
usbdevice='tablet'
xen_platform_pci=1
# Remember QEMU_AUDIO_DRV=pa
soundhw='es1370'
pci=['01:00.0','01:00.1','02:00.0']

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 25 14:15:52 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 14: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 1TGVvK-0002OS-Tv; Tue, 25 Sep 2012 14:15:42 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ketuzsezr@gmail.com>) id 1TGVvJ-0002OJ-7p
	for xen-devel@lists.xen.org; Tue, 25 Sep 2012 14:15:41 +0000
Received: from [85.158.139.83:7683] by server-3.bemta-5.messagelabs.com id
	D2/47-16108-C8CB1605; Tue, 25 Sep 2012 14:15:40 +0000
X-Env-Sender: ketuzsezr@gmail.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1348582538!31885549!1
X-Originating-IP: [209.85.216.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10312 invoked from network); 25 Sep 2012 14:15:39 -0000
Received: from mail-qa0-f45.google.com (HELO mail-qa0-f45.google.com)
	(209.85.216.45)
	by server-12.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Sep 2012 14:15:39 -0000
Received: by qaas11 with SMTP id s11so417700qaa.11
	for <xen-devel@lists.xen.org>; Tue, 25 Sep 2012 07:15: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=imqKqNqX3NUFxqWw9QD3B6qgM3zWevBzHh9Kfz8E2FI=;
	b=vKNzqLnHPYl0hgeh6H32HkAu8lZkibJJn8JaAEtgKwsEpIi6aNzNwCP8nB4wsFyny+
	CewABqRqovynr5S9zTIMepGn2Sl9tx4U28D+obt+5h2tVeORZaQJ/NS+1Gx4x+UpvRoJ
	lG1BheyTA0JVukVWNoqMw+hfkxWg8rlf3feojESi/J9es8MVT3qPcGHo4n4RHuLAv8lY
	knXwPe09XYx5i+Q9Xf4UcAgs+63hijf5eeb4yp6BMG7lO5O7CzV70hf6JRgrVcwlUc8w
	pRFOtlkR6e+cjcuPCvMz96v1E28azWnYBN5XirG/Fm96FhnYXgoTvIxyMWW/Amqk049G
	CbfA==
Received: by 10.224.185.148 with SMTP id co20mr40328857qab.4.1348582538296;
	Tue, 25 Sep 2012 07:15:38 -0700 (PDT)
Received: from phenom.dumpdata.com
	(50-195-21-189-static.hfc.comcastbusiness.net. [50.195.21.189])
	by mx.google.com with ESMTPS id dp3sm903879qab.21.2012.09.25.07.15.37
	(version=TLSv1/SSLv3 cipher=OTHER);
	Tue, 25 Sep 2012 07:15:37 -0700 (PDT)
Date: Tue, 25 Sep 2012 10:04:22 -0400
From: Konrad Rzeszutek Wilk <konrad@kernel.org>
To: Qian Hu <qianhu2011@gmail.com>
Message-ID: <20120925140421.GA16478@phenom.dumpdata.com>
References: <CALCpXpCvGkjZyG-NOY+fZY0q0f_DxuwPNEnxwKXVhjOe=gcHSQ@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CALCpXpCvGkjZyG-NOY+fZY0q0f_DxuwPNEnxwKXVhjOe=gcHSQ@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] usbpassthrough of xen-4.1.2 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, Sep 25, 2012 at 11:17:03AM +0800, Qian Hu wrote:
> Hi, everyone! The same question with updated message.
> 
> I am working on the USB passthrough of Xen-4.1.2. My host OS  is Fedora 14
> and the guest OS is win7.
> 
> According to the wiki page(http://wiki.xen.org/wiki/Xen_USB_Passthrough),
> 
> xen supports passthrough of usb device from dom0 to guests. I have tried
> the Xen HVM guest qemu-dm usb1.1 emulation,
> 
> by specifying "usb = 1" and "usbdevice = host:xxxx:yyyy". I have also tried
> the command usb_add host:xxxx:yyyy.

Do you also re-assign the device from the Linux kernel? Like this:

(the C408 0040 is my mouse).

 cd /sys/bus/usb/drivers/usbhid
 for a in `ls -1 | grep :`
 do
   for DEV in C408 0040
   do
        grep $DEV $a/modalias
        if [ $? -eq 0 ]; then
                echo "Unbinding $a for $DEV"
                echo $a > unbind
        fi
   done
 done

This is what the config file looks for me:
builder='hvm'
memory = 2048
name = "Windows7"
vcpus=3
disk = [ 'phy:/dev/vg_guest/Win7_Home,hda,w']
vnc=1
videoram=8
vnclisten="0.0.0.0"
vncpasswd=''
stdvga=0
serial='pty'
tsc_mode=0
usb=1
usb_add="host:045e:0040"
usbdevice='tablet'
xen_platform_pci=1
# Remember QEMU_AUDIO_DRV=pa
soundhw='es1370'
pci=['01:00.0','01:00.1','02:00.0']

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 25 14:17:45 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 14: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 1TGVx7-0002W4-F8; Tue, 25 Sep 2012 14:17:33 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ketuzsezr@gmail.com>) id 1TGVx6-0002Vv-4U
	for xen-devel@lists.xen.org; Tue, 25 Sep 2012 14:17:32 +0000
Received: from [85.158.137.99:50453] by server-4.bemta-3.messagelabs.com id
	2E/7E-24831-BFCB1605; Tue, 25 Sep 2012 14:17:31 +0000
X-Env-Sender: ketuzsezr@gmail.com
X-Msg-Ref: server-9.tower-217.messagelabs.com!1348582649!15910219!1
X-Originating-IP: [209.85.216.52]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
  RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27736 invoked from network); 25 Sep 2012 14:17:30 -0000
Received: from mail-qa0-f52.google.com (HELO mail-qa0-f52.google.com)
	(209.85.216.52)
	by server-9.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Sep 2012 14:17:30 -0000
Received: by qabg24 with SMTP id g24so122758qab.11
	for <xen-devel@lists.xen.org>; Tue, 25 Sep 2012 07:17:28 -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=oM0DmWRoc9SVSMWt+XaKYMaO8i1wawcbnLDF/xnvDGg=;
	b=ike+gpEBypB0pzXoAWfw+8kpTNrPivlHnoZQGw0EckHEbsYY7eumfUcc2XPfsL34D9
	pfz+xHMw6r9rXUuz3l+pVcgkcusGVtXXrOHyp2Z3Q3PfGy/8YO8DXnt7jUBNH2EXXbME
	pX6euCap2zTYzRFK/PzVSoPhsCNe2GZUu8VTc+apmMlNYbXIQIPC29n1HxLxhqcXWbAH
	bizUl9wZTMqnTz7WAAf8Vdc/8ZDWSCgv0G3YIxlXZsTgnM8QF3etKL4cOWcxQ9wS9ijA
	hJbWNSFRJ1a9qarCZwPD62vwGeX+t01UgWpfPo5t71AZHkoxPfM0CgYO4sY4KDAPD/Fa
	kBZw==
Received: by 10.224.31.201 with SMTP id z9mr39846209qac.94.1348582648759;
	Tue, 25 Sep 2012 07:17:28 -0700 (PDT)
Received: from phenom.dumpdata.com
	(50-195-21-189-static.hfc.comcastbusiness.net. [50.195.21.189])
	by mx.google.com with ESMTPS id dp3sm908881qab.21.2012.09.25.07.17.27
	(version=TLSv1/SSLv3 cipher=OTHER);
	Tue, 25 Sep 2012 07:17:28 -0700 (PDT)
Date: Tue, 25 Sep 2012 10:06:12 -0400
From: Konrad Rzeszutek Wilk <konrad@kernel.org>
To: Javier Marcet <jmarcet@gmail.com>
Message-ID: <20120925140611.GB16478@phenom.dumpdata.com>
References: <CC8273A0.4C9DD%keir@xen.org>
	<50605E9A020000780009D486@nat28.tlf.novell.com>
	<CAOvdn6XmB6rj3_QVU+59V8p24Y5G47AWxVEM=id02JWXkuhibQ@mail.gmail.com>
	<5060640B020000780009D4D2@nat28.tlf.novell.com>
	<CAOvdn6XLy8zR2rb2MEyi2aT9LQiFvFLY_H02p181mTsVLVTZkw@mail.gmail.com>
	<20120924122203.GG8912@reaktio.net>
	<CAOvdn6XV4eoA-FfFns1xhx7HCUqXc7KHxZwyKuT4FHG8s3R5RQ@mail.gmail.com>
	<CAAnFQG9PLQjdh6Ab6=Y5ZGM1s4nGdLekKU=pcKNMxt4rmt_RKA@mail.gmail.com>
	<20120924140411.GH31618@phenom.dumpdata.com>
	<CAAnFQG-tjv5UyF6j-TNHNgme2c4vA0Zxy8AdCiJEVsf2Z0quNA@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAAnFQG-tjv5UyF6j-TNHNgme2c4vA0Zxy8AdCiJEVsf2Z0quNA@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: Keir Fraser <keir@xen.org>, john.baboval@citrix.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	xen-devel <xen-devel@lists.xen.org>, Ben Guthro <ben@guthro.net>,
	Jan Beulich <JBeulich@suse.com>, Thomas Goetz <thomas.goetz@citrix.com>
Subject: Re: [Xen-devel] Xen4.2 S3 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 Mon, Sep 24, 2012 at 11:36:23PM +0200, Javier Marcet wrote:
> On Mon, Sep 24, 2012 at 4:04 PM, Konrad Rzeszutek Wilk
> <konrad.wilk@oracle.com> wrote:
> 
> >> >> xen-acpi-processor driver was merged to upstream Linux kernel v3.4.
> >> >>
> >> >
> >> > I see - so the advanced methods are not being used then
> >
> > You mean with the v3.5 kernel? I would think they would be used..
> >
> >> > This same kernel does work with Xen-4.0.x though. Is there an assumption in
> >> > the code that ties Xen-4.2 to a newer kernel?
> >>
> >> I'm being bitten by this bug with a 3.5 kernel and Xen 4.2
> >
> > Huh? How so?
> 
> I've tried adding a wbinvd() call before the halts in
> xen/arch/x86/domain.c:default_idle and I could do full suspend and
> resume cycle once, but a reboot later I couldn't resume anymore. Here

Did you use the patch that Jan posted?
> is the trace I get:

That is a different issue. That is the kernel, while the outstanding
issue in regards to suspend/resume is in the hypervisor.
> 
> [  142.322778] ACPI: Preparing to enter system sleep state S3
> [  142.723286] PM: Saving platform NVS memory
> [  142.736453] Disabling non-boot CPUs ...
> [  142.851387] ------------[ cut here ]------------
> [  142.851397] WARNING: at
> /home/storage/src/ubuntu-precise/kernel/rcutree.c:1550
> rcu_do_batch.isra.41+0x5f/0x213()


which ought to be fixed, but lets concentrate on one thing at a time.
If you use the patch that Jan posted, does it work? And I presume
you also have the two out-of-tree patches to make resume work in the
dom0?

> [  142.851401] Hardware name: To Be Filled By O.E.M.
> [  142.851404] Modules linked in: blktap(O) ip6table_filter ip6_tables
> ipt_MASQUERADE iptable_nat nf_nat nf_conntrack_ipv4 nf_defrag_ipv4
> xt_state nf_conntrack ipt_REJECT xt_CHECKSUM iptable_mangle xt_tcpudp
> iptable_filter ip_tables x_tables [last unloaded: cx25840]
> [  142.851466] Pid: 32, comm: migration/7 Tainted: G           O
> 3.5.0-14-i7 #18~precise1
> [  142.851469] Call Trace:
> [  142.851473]  <IRQ>  [<ffffffff8106a9bd>] warn_slowpath_common+0x7e/0x96
> [  142.851488]  [<ffffffff8106a9ea>] warn_slowpath_null+0x15/0x17
> [  142.851496]  [<ffffffff810c6e87>] rcu_do_batch.isra.41+0x5f/0x213
> [  142.851504]  [<ffffffff810c687f>] ?
> check_for_new_grace_period.isra.35+0x38/0x44
> [  142.851512]  [<ffffffff810c7101>] __rcu_process_callbacks+0xc6/0xee
> [  142.851520]  [<ffffffff810c7149>] rcu_process_callbacks+0x20/0x3e
> [  142.851527]  [<ffffffff81070c27>] __do_softirq+0x87/0x113
> [  142.851536]  [<ffffffff812e7b22>] ? __xen_evtchn_do_upcall+0x1a0/0x1dd
> [  142.851546]  [<ffffffff8162f05c>] call_softirq+0x1c/0x30
> [  142.851557]  [<ffffffff810343a3>] do_softirq+0x41/0x7e
> [  142.851566]  [<ffffffff81070e66>] irq_exit+0x3f/0x9a
> [  142.851573]  [<ffffffff812e95c9>] xen_evtchn_do_upcall+0x2c/0x39
> [  142.851580]  [<ffffffff8162f0ae>] xen_do_hypervisor_callback+0x1e/0x30
> [  142.851588]  <EOI>  [<ffffffff8100122a>] ? hypercall_page+0x22a/0x1000
> [  142.851601]  [<ffffffff8100122a>] ? hypercall_page+0x22a/0x1000
> [  142.851609]  [<ffffffff8102eee9>] ? xen_force_evtchn_callback+0xd/0xf
> [  142.851618]  [<ffffffff8102f552>] ? check_events+0x12/0x20
> [  142.851627]  [<ffffffff8102f53f>] ? xen_restore_fl_direct_reloc+0x4/0x4
> [  142.851635]  [<ffffffff810b6ff4>] ? arch_local_irq_restore+0xb/0xd
> [  142.851644]  [<ffffffff810b73f4>] ? stop_machine_cpu_stop+0xc1/0xd3
> [  142.851652]  [<ffffffff810b7333>] ? queue_stop_cpus_work+0xb5/0xb5
> [  142.851660]  [<ffffffff810b7152>] ? cpu_stopper_thread+0xf7/0x187
> [  142.851667]  [<ffffffff8108a927>] ? finish_task_switch+0x82/0xc1
> [  142.851676]  [<ffffffff8162c50b>] ? __schedule+0x428/0x454
> [  142.851685]  [<ffffffff8162cff0>] ? _raw_spin_unlock_irqrestore+0x15/0x18
> [  142.851693]  [<ffffffff810b705b>] ? cpu_stop_signal_done+0x30/0x30
> [  142.851701]  [<ffffffff81082627>] ? kthread+0x86/0x8e
> [  142.851710]  [<ffffffff8162ef64>] ? kernel_thread_helper+0x4/0x10
> [  142.851718]  [<ffffffff8162d338>] ? retint_restore_args+0x5/0x6
> [  142.851726]  [<ffffffff8162ef60>] ? gs_change+0x13/0x13
> [  142.851736] ---[ end trace 3722a99bcc5ae37a ]---
> [  144.257229] ACPI: Low-level resume complete
> [  144.257322] PM: Restoring platform NVS memory
> 
> 
> -- 
> Javier Marcet <jmarcet@gmail.com>
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 25 14:17:45 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 14: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 1TGVx7-0002W4-F8; Tue, 25 Sep 2012 14:17:33 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ketuzsezr@gmail.com>) id 1TGVx6-0002Vv-4U
	for xen-devel@lists.xen.org; Tue, 25 Sep 2012 14:17:32 +0000
Received: from [85.158.137.99:50453] by server-4.bemta-3.messagelabs.com id
	2E/7E-24831-BFCB1605; Tue, 25 Sep 2012 14:17:31 +0000
X-Env-Sender: ketuzsezr@gmail.com
X-Msg-Ref: server-9.tower-217.messagelabs.com!1348582649!15910219!1
X-Originating-IP: [209.85.216.52]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
  RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27736 invoked from network); 25 Sep 2012 14:17:30 -0000
Received: from mail-qa0-f52.google.com (HELO mail-qa0-f52.google.com)
	(209.85.216.52)
	by server-9.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Sep 2012 14:17:30 -0000
Received: by qabg24 with SMTP id g24so122758qab.11
	for <xen-devel@lists.xen.org>; Tue, 25 Sep 2012 07:17:28 -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=oM0DmWRoc9SVSMWt+XaKYMaO8i1wawcbnLDF/xnvDGg=;
	b=ike+gpEBypB0pzXoAWfw+8kpTNrPivlHnoZQGw0EckHEbsYY7eumfUcc2XPfsL34D9
	pfz+xHMw6r9rXUuz3l+pVcgkcusGVtXXrOHyp2Z3Q3PfGy/8YO8DXnt7jUBNH2EXXbME
	pX6euCap2zTYzRFK/PzVSoPhsCNe2GZUu8VTc+apmMlNYbXIQIPC29n1HxLxhqcXWbAH
	bizUl9wZTMqnTz7WAAf8Vdc/8ZDWSCgv0G3YIxlXZsTgnM8QF3etKL4cOWcxQ9wS9ijA
	hJbWNSFRJ1a9qarCZwPD62vwGeX+t01UgWpfPo5t71AZHkoxPfM0CgYO4sY4KDAPD/Fa
	kBZw==
Received: by 10.224.31.201 with SMTP id z9mr39846209qac.94.1348582648759;
	Tue, 25 Sep 2012 07:17:28 -0700 (PDT)
Received: from phenom.dumpdata.com
	(50-195-21-189-static.hfc.comcastbusiness.net. [50.195.21.189])
	by mx.google.com with ESMTPS id dp3sm908881qab.21.2012.09.25.07.17.27
	(version=TLSv1/SSLv3 cipher=OTHER);
	Tue, 25 Sep 2012 07:17:28 -0700 (PDT)
Date: Tue, 25 Sep 2012 10:06:12 -0400
From: Konrad Rzeszutek Wilk <konrad@kernel.org>
To: Javier Marcet <jmarcet@gmail.com>
Message-ID: <20120925140611.GB16478@phenom.dumpdata.com>
References: <CC8273A0.4C9DD%keir@xen.org>
	<50605E9A020000780009D486@nat28.tlf.novell.com>
	<CAOvdn6XmB6rj3_QVU+59V8p24Y5G47AWxVEM=id02JWXkuhibQ@mail.gmail.com>
	<5060640B020000780009D4D2@nat28.tlf.novell.com>
	<CAOvdn6XLy8zR2rb2MEyi2aT9LQiFvFLY_H02p181mTsVLVTZkw@mail.gmail.com>
	<20120924122203.GG8912@reaktio.net>
	<CAOvdn6XV4eoA-FfFns1xhx7HCUqXc7KHxZwyKuT4FHG8s3R5RQ@mail.gmail.com>
	<CAAnFQG9PLQjdh6Ab6=Y5ZGM1s4nGdLekKU=pcKNMxt4rmt_RKA@mail.gmail.com>
	<20120924140411.GH31618@phenom.dumpdata.com>
	<CAAnFQG-tjv5UyF6j-TNHNgme2c4vA0Zxy8AdCiJEVsf2Z0quNA@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAAnFQG-tjv5UyF6j-TNHNgme2c4vA0Zxy8AdCiJEVsf2Z0quNA@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: Keir Fraser <keir@xen.org>, john.baboval@citrix.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	xen-devel <xen-devel@lists.xen.org>, Ben Guthro <ben@guthro.net>,
	Jan Beulich <JBeulich@suse.com>, Thomas Goetz <thomas.goetz@citrix.com>
Subject: Re: [Xen-devel] Xen4.2 S3 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 Mon, Sep 24, 2012 at 11:36:23PM +0200, Javier Marcet wrote:
> On Mon, Sep 24, 2012 at 4:04 PM, Konrad Rzeszutek Wilk
> <konrad.wilk@oracle.com> wrote:
> 
> >> >> xen-acpi-processor driver was merged to upstream Linux kernel v3.4.
> >> >>
> >> >
> >> > I see - so the advanced methods are not being used then
> >
> > You mean with the v3.5 kernel? I would think they would be used..
> >
> >> > This same kernel does work with Xen-4.0.x though. Is there an assumption in
> >> > the code that ties Xen-4.2 to a newer kernel?
> >>
> >> I'm being bitten by this bug with a 3.5 kernel and Xen 4.2
> >
> > Huh? How so?
> 
> I've tried adding a wbinvd() call before the halts in
> xen/arch/x86/domain.c:default_idle and I could do full suspend and
> resume cycle once, but a reboot later I couldn't resume anymore. Here

Did you use the patch that Jan posted?
> is the trace I get:

That is a different issue. That is the kernel, while the outstanding
issue in regards to suspend/resume is in the hypervisor.
> 
> [  142.322778] ACPI: Preparing to enter system sleep state S3
> [  142.723286] PM: Saving platform NVS memory
> [  142.736453] Disabling non-boot CPUs ...
> [  142.851387] ------------[ cut here ]------------
> [  142.851397] WARNING: at
> /home/storage/src/ubuntu-precise/kernel/rcutree.c:1550
> rcu_do_batch.isra.41+0x5f/0x213()


which ought to be fixed, but lets concentrate on one thing at a time.
If you use the patch that Jan posted, does it work? And I presume
you also have the two out-of-tree patches to make resume work in the
dom0?

> [  142.851401] Hardware name: To Be Filled By O.E.M.
> [  142.851404] Modules linked in: blktap(O) ip6table_filter ip6_tables
> ipt_MASQUERADE iptable_nat nf_nat nf_conntrack_ipv4 nf_defrag_ipv4
> xt_state nf_conntrack ipt_REJECT xt_CHECKSUM iptable_mangle xt_tcpudp
> iptable_filter ip_tables x_tables [last unloaded: cx25840]
> [  142.851466] Pid: 32, comm: migration/7 Tainted: G           O
> 3.5.0-14-i7 #18~precise1
> [  142.851469] Call Trace:
> [  142.851473]  <IRQ>  [<ffffffff8106a9bd>] warn_slowpath_common+0x7e/0x96
> [  142.851488]  [<ffffffff8106a9ea>] warn_slowpath_null+0x15/0x17
> [  142.851496]  [<ffffffff810c6e87>] rcu_do_batch.isra.41+0x5f/0x213
> [  142.851504]  [<ffffffff810c687f>] ?
> check_for_new_grace_period.isra.35+0x38/0x44
> [  142.851512]  [<ffffffff810c7101>] __rcu_process_callbacks+0xc6/0xee
> [  142.851520]  [<ffffffff810c7149>] rcu_process_callbacks+0x20/0x3e
> [  142.851527]  [<ffffffff81070c27>] __do_softirq+0x87/0x113
> [  142.851536]  [<ffffffff812e7b22>] ? __xen_evtchn_do_upcall+0x1a0/0x1dd
> [  142.851546]  [<ffffffff8162f05c>] call_softirq+0x1c/0x30
> [  142.851557]  [<ffffffff810343a3>] do_softirq+0x41/0x7e
> [  142.851566]  [<ffffffff81070e66>] irq_exit+0x3f/0x9a
> [  142.851573]  [<ffffffff812e95c9>] xen_evtchn_do_upcall+0x2c/0x39
> [  142.851580]  [<ffffffff8162f0ae>] xen_do_hypervisor_callback+0x1e/0x30
> [  142.851588]  <EOI>  [<ffffffff8100122a>] ? hypercall_page+0x22a/0x1000
> [  142.851601]  [<ffffffff8100122a>] ? hypercall_page+0x22a/0x1000
> [  142.851609]  [<ffffffff8102eee9>] ? xen_force_evtchn_callback+0xd/0xf
> [  142.851618]  [<ffffffff8102f552>] ? check_events+0x12/0x20
> [  142.851627]  [<ffffffff8102f53f>] ? xen_restore_fl_direct_reloc+0x4/0x4
> [  142.851635]  [<ffffffff810b6ff4>] ? arch_local_irq_restore+0xb/0xd
> [  142.851644]  [<ffffffff810b73f4>] ? stop_machine_cpu_stop+0xc1/0xd3
> [  142.851652]  [<ffffffff810b7333>] ? queue_stop_cpus_work+0xb5/0xb5
> [  142.851660]  [<ffffffff810b7152>] ? cpu_stopper_thread+0xf7/0x187
> [  142.851667]  [<ffffffff8108a927>] ? finish_task_switch+0x82/0xc1
> [  142.851676]  [<ffffffff8162c50b>] ? __schedule+0x428/0x454
> [  142.851685]  [<ffffffff8162cff0>] ? _raw_spin_unlock_irqrestore+0x15/0x18
> [  142.851693]  [<ffffffff810b705b>] ? cpu_stop_signal_done+0x30/0x30
> [  142.851701]  [<ffffffff81082627>] ? kthread+0x86/0x8e
> [  142.851710]  [<ffffffff8162ef64>] ? kernel_thread_helper+0x4/0x10
> [  142.851718]  [<ffffffff8162d338>] ? retint_restore_args+0x5/0x6
> [  142.851726]  [<ffffffff8162ef60>] ? gs_change+0x13/0x13
> [  142.851736] ---[ end trace 3722a99bcc5ae37a ]---
> [  144.257229] ACPI: Low-level resume complete
> [  144.257322] PM: Restoring platform NVS memory
> 
> 
> -- 
> Javier Marcet <jmarcet@gmail.com>
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 25 14:19:37 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 14:19:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGVyy-0002gB-4V; Tue, 25 Sep 2012 14:19:28 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anil@recoil.org>) id 1TGVyw-0002fr-8y
	for xen-devel@lists.xensource.com; Tue, 25 Sep 2012 14:19:26 +0000
Received: from [85.158.143.35:51280] by server-3.bemta-4.messagelabs.com id
	9F/1E-10986-D6DB1605; Tue, 25 Sep 2012 14:19:25 +0000
X-Env-Sender: anil@recoil.org
X-Msg-Ref: server-6.tower-21.messagelabs.com!1348582764!19813855!1
X-Originating-IP: [89.16.177.154]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20022 invoked from network); 25 Sep 2012 14:19:25 -0000
Received: from recoil.dh.bytemark.co.uk (HELO dark.recoil.org) (89.16.177.154)
	by server-6.tower-21.messagelabs.com with SMTP;
	25 Sep 2012 14:19:25 -0000
Received: (qmail 8432 invoked by uid 634); 25 Sep 2012 14:19:24 -0000
Received: from 217.sub-70-192-129.myvzw.com (HELO [192.168.1.16])
	(70.192.129.217)
	(smtp-auth username remote@recoil.org, mechanism cram-md5)
	by dark.recoil.org (qpsmtpd/0.84) with ESMTPA;
	Tue, 25 Sep 2012 15:19:24 +0100
Mime-Version: 1.0 (Mac OS X Mail 6.1 \(1498\))
From: Anil Madhavapeddy <anil@recoil.org>
In-Reply-To: <1348561354.3452.105.camel@zakaz.uk.xensource.com>
Date: Tue, 25 Sep 2012 10:19:22 -0400
Message-Id: <2D15A521-63E8-4CE7-8D42-62A67FBD75B2@recoil.org>
References: <CAGnmK4wB3ZJ3Tb9-VFgWCkcZNwibDzRYV8tvb14vLgw1wj2awQ@mail.gmail.com>
	<50607A68.2090604@xen.org>
	<1348561354.3452.105.camel@zakaz.uk.xensource.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
X-Mailer: Apple Mail (2.1498)
X-Virus-Checked: Checked by ClamAV on dark.recoil.org
Cc: "lars.kurth@xen.org" <lars.kurth@xen.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"xen-api@lists.xensource.com" <xen-api@lists.xensource.com>
Subject: Re: [Xen-devel] [Xen-API]  Proposal - Add xe manpages to xen-org
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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 Sep 2012, at 04:22, Ian Campbell <Ian.Campbell@citrix.com> wrote:

> On Mon, 2012-09-24 at 16:21 +0100, Lars Kurth wrote:
>> On 24/09/2012 16:06, Grant McWilliams wrote:
>>> Xen Community,
>>> 
>>>    I have a team of people frantically creating manpages for the xe 
>>> command and all of it's 361 subcommands. The initial source 
>>> documentation is in asciidoc but also saved as Docbook. From docbook 
>>> we transform to epub, html, manpage and pdf. This is currently being 
>>> hosted in a subversion server at a Seattle area college and we'd like 
>>> to move it to the xen-org github so it's public, can be reviewed, 
>>> commented on and contributed too.
> 
> IME the best way to ensure that documentation remains current as the
> code base changes is to check it in next to the code in the same repo.
> 
> This requires a little bit of discipline from the maintainers, to
> remember to request appropriate docs updates when code patches require
> them, but has been pretty effective e.g. for the xen-unstable code base.

While xe man-pages are sorely needed, wouldn't it be better to autogenerate
it from the existing xe/xapi help by converting it to groff/asciidoc?
Manually keeping the zillion commands in sync will be quite the ongoing 
effort.

-anil


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 25 14:19:37 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 14:19:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGVyy-0002gB-4V; Tue, 25 Sep 2012 14:19:28 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anil@recoil.org>) id 1TGVyw-0002fr-8y
	for xen-devel@lists.xensource.com; Tue, 25 Sep 2012 14:19:26 +0000
Received: from [85.158.143.35:51280] by server-3.bemta-4.messagelabs.com id
	9F/1E-10986-D6DB1605; Tue, 25 Sep 2012 14:19:25 +0000
X-Env-Sender: anil@recoil.org
X-Msg-Ref: server-6.tower-21.messagelabs.com!1348582764!19813855!1
X-Originating-IP: [89.16.177.154]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20022 invoked from network); 25 Sep 2012 14:19:25 -0000
Received: from recoil.dh.bytemark.co.uk (HELO dark.recoil.org) (89.16.177.154)
	by server-6.tower-21.messagelabs.com with SMTP;
	25 Sep 2012 14:19:25 -0000
Received: (qmail 8432 invoked by uid 634); 25 Sep 2012 14:19:24 -0000
Received: from 217.sub-70-192-129.myvzw.com (HELO [192.168.1.16])
	(70.192.129.217)
	(smtp-auth username remote@recoil.org, mechanism cram-md5)
	by dark.recoil.org (qpsmtpd/0.84) with ESMTPA;
	Tue, 25 Sep 2012 15:19:24 +0100
Mime-Version: 1.0 (Mac OS X Mail 6.1 \(1498\))
From: Anil Madhavapeddy <anil@recoil.org>
In-Reply-To: <1348561354.3452.105.camel@zakaz.uk.xensource.com>
Date: Tue, 25 Sep 2012 10:19:22 -0400
Message-Id: <2D15A521-63E8-4CE7-8D42-62A67FBD75B2@recoil.org>
References: <CAGnmK4wB3ZJ3Tb9-VFgWCkcZNwibDzRYV8tvb14vLgw1wj2awQ@mail.gmail.com>
	<50607A68.2090604@xen.org>
	<1348561354.3452.105.camel@zakaz.uk.xensource.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
X-Mailer: Apple Mail (2.1498)
X-Virus-Checked: Checked by ClamAV on dark.recoil.org
Cc: "lars.kurth@xen.org" <lars.kurth@xen.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"xen-api@lists.xensource.com" <xen-api@lists.xensource.com>
Subject: Re: [Xen-devel] [Xen-API]  Proposal - Add xe manpages to xen-org
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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 Sep 2012, at 04:22, Ian Campbell <Ian.Campbell@citrix.com> wrote:

> On Mon, 2012-09-24 at 16:21 +0100, Lars Kurth wrote:
>> On 24/09/2012 16:06, Grant McWilliams wrote:
>>> Xen Community,
>>> 
>>>    I have a team of people frantically creating manpages for the xe 
>>> command and all of it's 361 subcommands. The initial source 
>>> documentation is in asciidoc but also saved as Docbook. From docbook 
>>> we transform to epub, html, manpage and pdf. This is currently being 
>>> hosted in a subversion server at a Seattle area college and we'd like 
>>> to move it to the xen-org github so it's public, can be reviewed, 
>>> commented on and contributed too.
> 
> IME the best way to ensure that documentation remains current as the
> code base changes is to check it in next to the code in the same repo.
> 
> This requires a little bit of discipline from the maintainers, to
> remember to request appropriate docs updates when code patches require
> them, but has been pretty effective e.g. for the xen-unstable code base.

While xe man-pages are sorely needed, wouldn't it be better to autogenerate
it from the existing xe/xapi help by converting it to groff/asciidoc?
Manually keeping the zillion commands in sync will be quite the ongoing 
effort.

-anil


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 25 14:20:09 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 14: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 1TGVzO-0002k1-Md; Tue, 25 Sep 2012 14:19:54 +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 1TGVzO-0002jq-4m
	for xen-devel@lists.xen.org; Tue, 25 Sep 2012 14:19:54 +0000
Received: from [85.158.139.211:58677] by server-3.bemta-5.messagelabs.com id
	40/EE-16108-98DB1605; Tue, 25 Sep 2012 14:19:53 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-10.tower-206.messagelabs.com!1348582791!19878436!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNzczMzU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29845 invoked from network); 25 Sep 2012 14:19:52 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-10.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Sep 2012 14:19:52 -0000
X-IronPort-AV: E=Sophos;i="4.80,483,1344211200"; d="scan'208";a="209274083"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Sep 2012 14:19:13 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Tue, 25 Sep 2012 10:18: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 1TGVyQ-0006nf-IG;
	Tue, 25 Sep 2012 15:18:54 +0100
Message-ID: <5061BD4E.6000905@citrix.com>
Date: Tue, 25 Sep 2012 15:18:54 +0100
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120912 Thunderbird/15.0.1
MIME-Version: 1.0
To: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
X-Enigmail-Version: 1.4.4
Content-Type: multipart/mixed; boundary="------------040108090504000407090903"
Cc: Keir Fraser <keir@xen.org>, Jan Beulich <jbeulich@suse.com>
Subject: [Xen-devel] RFC: EFER in crash notes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--------------040108090504000407090903
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit

While this patch is very simple, and I hope without any objection, it is
RFC for the reason that our crash ABI is private.

The comments for XEN_ELFNOTE_CRASH_REGS does state that it is
architecture specific, and makes no indication about the size or
contents of the crash note.  However, any code trying to use one of
these types of notes has to make an assumption that it if the note desc
length is 4*8 bytes long, it is representing CR{0,2-4}.

I guess my question boils down to whether it is acceptable to change a
private ABI which is not really so private, or whether we should make a
formal public ABI for all of the inards of the crash notes and use that.

I have some upcoming plans to put quite a lot more information into this
(or an equivalent) structure for extra analysis of the environment at
the point of a crash, so perhaps putting in the proper work to make a
public ABI would be the best course of action.

-- 
Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
T: +44 (0)1223 225 900, http://www.citrix.com


--------------040108090504000407090903
Content-Type: text/x-patch; name="kexec-efer-in-crash-notes.patch"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="kexec-efer-in-crash-notes.patch"

# HG changeset patch
# Parent d364becfb0835f69e85d273fe2b29035c2d975df

diff -r d364becfb083 xen/include/asm-x86/elf.h
--- a/xen/include/asm-x86/elf.h
+++ b/xen/include/asm-x86/elf.h
@@ -3,6 +3,7 @@
 
 typedef struct {
     unsigned long cr0, cr2, cr3, cr4;
+    unsigned long efer;
 } crash_xen_core_t;
 
 #include <asm/x86_64/elf.h>
diff -r d364becfb083 xen/include/asm-x86/x86_64/elf.h
--- a/xen/include/asm-x86/x86_64/elf.h
+++ b/xen/include/asm-x86/x86_64/elf.h
@@ -1,6 +1,8 @@
 #ifndef __X86_64_ELF_H__
 #define __X86_64_ELF_H__
 
+#include <asm/msr.h>
+
 typedef struct {
     unsigned long r15;
     unsigned long r14;
@@ -75,6 +77,8 @@ static inline void elf_core_save_regs(EL
 
     asm volatile("mov %%cr4, %0" : "=r" (tmp) : );
     xen_core_regs->cr4 = tmp;
+
+    rdmsrl(MSR_EFER, xen_core_regs->efer);
 }
 
 #endif /* __X86_64_ELF_H__ */

--------------040108090504000407090903
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--------------040108090504000407090903--


From xen-devel-bounces@lists.xen.org Tue Sep 25 14:20:09 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 14: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 1TGVzO-0002k1-Md; Tue, 25 Sep 2012 14:19:54 +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 1TGVzO-0002jq-4m
	for xen-devel@lists.xen.org; Tue, 25 Sep 2012 14:19:54 +0000
Received: from [85.158.139.211:58677] by server-3.bemta-5.messagelabs.com id
	40/EE-16108-98DB1605; Tue, 25 Sep 2012 14:19:53 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-10.tower-206.messagelabs.com!1348582791!19878436!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNzczMzU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29845 invoked from network); 25 Sep 2012 14:19:52 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-10.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Sep 2012 14:19:52 -0000
X-IronPort-AV: E=Sophos;i="4.80,483,1344211200"; d="scan'208";a="209274083"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Sep 2012 14:19:13 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Tue, 25 Sep 2012 10:18: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 1TGVyQ-0006nf-IG;
	Tue, 25 Sep 2012 15:18:54 +0100
Message-ID: <5061BD4E.6000905@citrix.com>
Date: Tue, 25 Sep 2012 15:18:54 +0100
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120912 Thunderbird/15.0.1
MIME-Version: 1.0
To: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
X-Enigmail-Version: 1.4.4
Content-Type: multipart/mixed; boundary="------------040108090504000407090903"
Cc: Keir Fraser <keir@xen.org>, Jan Beulich <jbeulich@suse.com>
Subject: [Xen-devel] RFC: EFER in crash notes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--------------040108090504000407090903
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit

While this patch is very simple, and I hope without any objection, it is
RFC for the reason that our crash ABI is private.

The comments for XEN_ELFNOTE_CRASH_REGS does state that it is
architecture specific, and makes no indication about the size or
contents of the crash note.  However, any code trying to use one of
these types of notes has to make an assumption that it if the note desc
length is 4*8 bytes long, it is representing CR{0,2-4}.

I guess my question boils down to whether it is acceptable to change a
private ABI which is not really so private, or whether we should make a
formal public ABI for all of the inards of the crash notes and use that.

I have some upcoming plans to put quite a lot more information into this
(or an equivalent) structure for extra analysis of the environment at
the point of a crash, so perhaps putting in the proper work to make a
public ABI would be the best course of action.

-- 
Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
T: +44 (0)1223 225 900, http://www.citrix.com


--------------040108090504000407090903
Content-Type: text/x-patch; name="kexec-efer-in-crash-notes.patch"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="kexec-efer-in-crash-notes.patch"

# HG changeset patch
# Parent d364becfb0835f69e85d273fe2b29035c2d975df

diff -r d364becfb083 xen/include/asm-x86/elf.h
--- a/xen/include/asm-x86/elf.h
+++ b/xen/include/asm-x86/elf.h
@@ -3,6 +3,7 @@
 
 typedef struct {
     unsigned long cr0, cr2, cr3, cr4;
+    unsigned long efer;
 } crash_xen_core_t;
 
 #include <asm/x86_64/elf.h>
diff -r d364becfb083 xen/include/asm-x86/x86_64/elf.h
--- a/xen/include/asm-x86/x86_64/elf.h
+++ b/xen/include/asm-x86/x86_64/elf.h
@@ -1,6 +1,8 @@
 #ifndef __X86_64_ELF_H__
 #define __X86_64_ELF_H__
 
+#include <asm/msr.h>
+
 typedef struct {
     unsigned long r15;
     unsigned long r14;
@@ -75,6 +77,8 @@ static inline void elf_core_save_regs(EL
 
     asm volatile("mov %%cr4, %0" : "=r" (tmp) : );
     xen_core_regs->cr4 = tmp;
+
+    rdmsrl(MSR_EFER, xen_core_regs->efer);
 }
 
 #endif /* __X86_64_ELF_H__ */

--------------040108090504000407090903
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--------------040108090504000407090903--


From xen-devel-bounces@lists.xen.org Tue Sep 25 14:21:21 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 14:21:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGW0c-0002vl-5f; Tue, 25 Sep 2012 14:21:10 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony.perard@citrix.com>) id 1TGW0b-0002v4-AN
	for xen-devel@lists.xen.org; Tue, 25 Sep 2012 14:21:09 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1348582861!3022811!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzEyNDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10847 invoked from network); 25 Sep 2012 14:21:02 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Sep 2012 14:21:02 -0000
X-IronPort-AV: E=Sophos;i="4.80,483,1344211200"; d="scan'208";a="39091708"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Sep 2012 14:20:51 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Tue, 25 Sep 2012 10:20:30 -0400
Received: from [10.80.3.61]	by ukmail1.uk.xensource.com with esmtp (Exim 4.69)
	(envelope-from <anthony.perard@citrix.com>)	id 1TGVzy-0006pV-Po;
	Tue, 25 Sep 2012 15:20:30 +0100
Message-ID: <5061BDAE.5030700@citrix.com>
Date: Tue, 25 Sep 2012 15:20:30 +0100
From: Anthony PERARD <anthony.perard@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120910 Thunderbird/15.0.1
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <1347906148-9606-1-git-send-email-anthony.perard@citrix.com>
	<1347906148-9606-4-git-send-email-anthony.perard@citrix.com>
	<1348562684.3452.116.camel@zakaz.uk.xensource.com>
In-Reply-To: <1348562684.3452.116.camel@zakaz.uk.xensource.com>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Xen Devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH V2 3/9] libxl_json: Introduce
	libxl__json_object_to_yajl_gen.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 09/25/2012 09:44 AM, Ian Campbell wrote:
> On Mon, 2012-09-17 at 19:22 +0100, Anthony PERARD wrote:
>> This function converts a libxl__json_object to yajl by calling every yajl_gen_*
>> function on a preallocated yajl_gen hand.
>>
>> This helps to integrate a json_object into an already existing yajl_gen tree.
>>
>> This function is used in a later patch.
>>
>> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
>> ---
>>  tools/libxl/libxl_internal.h |  3 +++
>>  tools/libxl/libxl_json.c     | 63 ++++++++++++++++++++++++++++++++++++++++++++
>>  2 files changed, 66 insertions(+)
>>
>> diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
>> index 3c2dcaa..9c1482d 100644
>> --- a/tools/libxl/libxl_internal.h
>> +++ b/tools/libxl/libxl_internal.h
>> [...]
> 
>> +    }
>> +    case JSON_ERROR:
> 
> I can't see this being used anywhere, could it just be removed from the
> enum?

Yes.

>> +    case JSON_ANY:
> 
> Is JSON_ANY sort of like a JSON "void *"? Is it ever valid to be passed
> one here, IOW does this represent a coding error (==abort()) or a run
> time one (== log something)?

This value is only used as parameter of one function,
libxl__json_map_get, that return an object from the json_object tree
with the expected type. But sometime we don't expect any type so
JSON_ANY is used and allow "map_get" to return any type of object.

So JSON_ANY is not valid here and would probably be a coding error.

>> +    default:
> 
> If you skip this default case then some compilers will warn (a runtime
> error) if we forget to add a new JSON_FOO here.

I tried to remove the default, but then gcc believe that the function
would not return in some cases. But I did not add a return because it
felt weird to add a useless/never_executed return/abort.

But it seams better to remove the default case, so I will.

>> +        return -1;
>> +    }
>> +}

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 Tue Sep 25 14:21:21 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 14:21:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGW0c-0002vl-5f; Tue, 25 Sep 2012 14:21:10 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony.perard@citrix.com>) id 1TGW0b-0002v4-AN
	for xen-devel@lists.xen.org; Tue, 25 Sep 2012 14:21:09 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1348582861!3022811!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzEyNDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10847 invoked from network); 25 Sep 2012 14:21:02 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Sep 2012 14:21:02 -0000
X-IronPort-AV: E=Sophos;i="4.80,483,1344211200"; d="scan'208";a="39091708"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Sep 2012 14:20:51 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Tue, 25 Sep 2012 10:20:30 -0400
Received: from [10.80.3.61]	by ukmail1.uk.xensource.com with esmtp (Exim 4.69)
	(envelope-from <anthony.perard@citrix.com>)	id 1TGVzy-0006pV-Po;
	Tue, 25 Sep 2012 15:20:30 +0100
Message-ID: <5061BDAE.5030700@citrix.com>
Date: Tue, 25 Sep 2012 15:20:30 +0100
From: Anthony PERARD <anthony.perard@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120910 Thunderbird/15.0.1
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <1347906148-9606-1-git-send-email-anthony.perard@citrix.com>
	<1347906148-9606-4-git-send-email-anthony.perard@citrix.com>
	<1348562684.3452.116.camel@zakaz.uk.xensource.com>
In-Reply-To: <1348562684.3452.116.camel@zakaz.uk.xensource.com>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Xen Devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH V2 3/9] libxl_json: Introduce
	libxl__json_object_to_yajl_gen.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 09/25/2012 09:44 AM, Ian Campbell wrote:
> On Mon, 2012-09-17 at 19:22 +0100, Anthony PERARD wrote:
>> This function converts a libxl__json_object to yajl by calling every yajl_gen_*
>> function on a preallocated yajl_gen hand.
>>
>> This helps to integrate a json_object into an already existing yajl_gen tree.
>>
>> This function is used in a later patch.
>>
>> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
>> ---
>>  tools/libxl/libxl_internal.h |  3 +++
>>  tools/libxl/libxl_json.c     | 63 ++++++++++++++++++++++++++++++++++++++++++++
>>  2 files changed, 66 insertions(+)
>>
>> diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
>> index 3c2dcaa..9c1482d 100644
>> --- a/tools/libxl/libxl_internal.h
>> +++ b/tools/libxl/libxl_internal.h
>> [...]
> 
>> +    }
>> +    case JSON_ERROR:
> 
> I can't see this being used anywhere, could it just be removed from the
> enum?

Yes.

>> +    case JSON_ANY:
> 
> Is JSON_ANY sort of like a JSON "void *"? Is it ever valid to be passed
> one here, IOW does this represent a coding error (==abort()) or a run
> time one (== log something)?

This value is only used as parameter of one function,
libxl__json_map_get, that return an object from the json_object tree
with the expected type. But sometime we don't expect any type so
JSON_ANY is used and allow "map_get" to return any type of object.

So JSON_ANY is not valid here and would probably be a coding error.

>> +    default:
> 
> If you skip this default case then some compilers will warn (a runtime
> error) if we forget to add a new JSON_FOO here.

I tried to remove the default, but then gcc believe that the function
would not return in some cases. But I did not add a return because it
felt weird to add a useless/never_executed return/abort.

But it seams better to remove the default case, so I will.

>> +        return -1;
>> +    }
>> +}

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 Tue Sep 25 14:21:44 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 14: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 1TGW10-0002zg-Jf; Tue, 25 Sep 2012 14:21:34 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ketuzsezr@gmail.com>) id 1TGW0y-0002zC-K7
	for xen-devel@lists.xensource.com; Tue, 25 Sep 2012 14:21:32 +0000
Received: from [85.158.139.211:31027] by server-15.bemta-5.messagelabs.com id
	02/26-19430-BEDB1605; Tue, 25 Sep 2012 14:21:31 +0000
X-Env-Sender: ketuzsezr@gmail.com
X-Msg-Ref: server-5.tower-206.messagelabs.com!1348582890!19861398!1
X-Originating-IP: [209.85.216.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21272 invoked from network); 25 Sep 2012 14:21:31 -0000
Received: from mail-qc0-f171.google.com (HELO mail-qc0-f171.google.com)
	(209.85.216.171)
	by server-5.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Sep 2012 14:21:31 -0000
Received: by qcad1 with SMTP id d1so2304385qca.30
	for <xen-devel@lists.xensource.com>;
	Tue, 25 Sep 2012 07:21:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:date:from:to:cc:subject:message-id:references:mime-version
	:content-type:content-disposition:in-reply-to:user-agent;
	bh=BylhrOIPcYWLNlH42kNcHmGPMYCcai0L4omKzpM6QQE=;
	b=klHyP/OsX4ZtN04RNmYyVZdSY9xFppGrRrVMsdy/8VkAHt5B3Q6kRpPAgdMtGxYZh9
	/5X7jEr0UXb9xUD+kUUUQquwANf/HFhG2c7PKthkQm1Vo6fKUy3Rl6blC+vCD7VqeHzh
	QaRWaM5DuqlZObyAPDwewInP2sO9sm0F2qFXDlayQZKxrIuUcAlu2DLd2VOQ5NLqumwr
	lr7VN2ugqtC0tD1Mq24QZDg4MTgh6p9QbaT3hNkdRbf6v+pYVRmeOu1frcDiBoxTsEz8
	sGpKmGxLB2l6kbtWYuoJCeGD1MqUKbArpnHtJbbt+pZ+eGUWyHhre91fHFlmE6ptw4sJ
	dh0Q==
Received: by 10.224.199.132 with SMTP id es4mr40029280qab.43.1348582889801;
	Tue, 25 Sep 2012 07:21:29 -0700 (PDT)
Received: from phenom.dumpdata.com
	(50-195-21-189-static.hfc.comcastbusiness.net. [50.195.21.189])
	by mx.google.com with ESMTPS id l3sm921971qan.19.2012.09.25.07.21.28
	(version=TLSv1/SSLv3 cipher=OTHER);
	Tue, 25 Sep 2012 07:21:29 -0700 (PDT)
Date: Tue, 25 Sep 2012 10:10:13 -0400
From: Konrad Rzeszutek Wilk <konrad@kernel.org>
To: John Krstev <john.krstev@gmail.com>
Message-ID: <20120925141013.GC16478@phenom.dumpdata.com>
References: <CA+LkAa=RHJCtpncP8AUSeR8Te3ZLMvRctuZqnv_NwUkCQ-im8Q@mail.gmail.com>
	<20120921172901.GA6821@phenom.dumpdata.com>
	<099949C5-C4C0-4D57-A778-849C94781372@gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <099949C5-C4C0-4D57-A778-849C94781372@gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Xen + DVB = not working. memory allocation 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 Tue, Sep 25, 2012 at 10:49:38AM +1000, John Krstev wrote:
> Hello Konrad,

Hey John,

Please do not top-post.
> 
> Do you have any patches I can try? FYI I've tried booting dom0 with mem=3G and various other options, still does not work. As I mentioned it runs fine on bare metal. 

So try also limiting how much memory the hypervisor has to eliminate
this being a 4GB issue. Meaning on the _hypervisor_ line add 'mem=4G'.

The next step is to actually figure out if where in the driver (cx88)
fails. And I need to know whether you are running this in a domain or
in the initial domain? If you crank up all the debug options do you
get anything saying what the problem is? How do you 'capture' the
video output? If you do it manually (cat /dev/video0 > /tmp/file.mpg)
does the file increase? Is it full of garbage ?

Does the channel selection work? Can you select the proper channel?

> 
> Last time it did work with xen was Jeremy's kernel + xen 4.0, also kernel 3.0.8 with xen 4.0.4 i believe (cannot reproduce success).
> 
> Thank you again for your input. 
> 
> Regards,
> 
> John
> 
> 
> 
> On 22/09/2012, at 3:29, Konrad Rzeszutek Wilk <konrad@kernel.org> wrote:
> 
> > On Fri, Sep 21, 2012 at 01:02:23PM +1000, John Krstev wrote:
> >> Hi Konrad,
> > 
> > Hey John,
> > 
> > Please next time also include xen-devel on the To header. I've done that
> > for you.
> >> 
> >> I refer to your patch at:
> >> http://lists.xen.org/archives/html/xen-devel/2012-01/msg01927.html
> >> which I found reading
> >> http://www.gossamer-threads.com/lists/xen/devel/256197
> >> 
> >> I have a winfast DVT 2000H (cx88) DVB card which is not able to
> >> scan/watch digital TV when running under Xen.
> > 
> > Did you first try running it under baremetal Linux (using a Live CD for
> > example?) Did it work there?
> > 
> > How does it not work? Can you program it? Is this under a guest or the
> > main kernel? When it wsa not working, did you try all the debug
> > options enable (http://wiki.xen.org/wiki/XenSerialConsole) to
> > see if there is anthing being reported?
> > 
> >> 
> >> I've tried installing the above patch to the 3.6-rc6 kernel, but did
> >> not seem to help.
> >> 
> >> Apologies if this has been asked before (I wasn't able to find another
> >> patch), but is there a patch to get this (suspected vmalloc_32) fixed
> >> and DVB card working?
> > 
> > Eventually yes.
> >> 
> >> FYI I'm running 64 bit 3.5-rc6 and xen 4.3-unstable.
> > 
> > 3.5-rc6 or 3.6-rc6?
> > I presume the latter?
> >> 
> >> Thank you! :)
> >> 
> >> Regards,
> >> 
> >> John
> >> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Sep 25 14:21:44 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 14: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 1TGW10-0002zg-Jf; Tue, 25 Sep 2012 14:21:34 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ketuzsezr@gmail.com>) id 1TGW0y-0002zC-K7
	for xen-devel@lists.xensource.com; Tue, 25 Sep 2012 14:21:32 +0000
Received: from [85.158.139.211:31027] by server-15.bemta-5.messagelabs.com id
	02/26-19430-BEDB1605; Tue, 25 Sep 2012 14:21:31 +0000
X-Env-Sender: ketuzsezr@gmail.com
X-Msg-Ref: server-5.tower-206.messagelabs.com!1348582890!19861398!1
X-Originating-IP: [209.85.216.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21272 invoked from network); 25 Sep 2012 14:21:31 -0000
Received: from mail-qc0-f171.google.com (HELO mail-qc0-f171.google.com)
	(209.85.216.171)
	by server-5.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Sep 2012 14:21:31 -0000
Received: by qcad1 with SMTP id d1so2304385qca.30
	for <xen-devel@lists.xensource.com>;
	Tue, 25 Sep 2012 07:21:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:date:from:to:cc:subject:message-id:references:mime-version
	:content-type:content-disposition:in-reply-to:user-agent;
	bh=BylhrOIPcYWLNlH42kNcHmGPMYCcai0L4omKzpM6QQE=;
	b=klHyP/OsX4ZtN04RNmYyVZdSY9xFppGrRrVMsdy/8VkAHt5B3Q6kRpPAgdMtGxYZh9
	/5X7jEr0UXb9xUD+kUUUQquwANf/HFhG2c7PKthkQm1Vo6fKUy3Rl6blC+vCD7VqeHzh
	QaRWaM5DuqlZObyAPDwewInP2sO9sm0F2qFXDlayQZKxrIuUcAlu2DLd2VOQ5NLqumwr
	lr7VN2ugqtC0tD1Mq24QZDg4MTgh6p9QbaT3hNkdRbf6v+pYVRmeOu1frcDiBoxTsEz8
	sGpKmGxLB2l6kbtWYuoJCeGD1MqUKbArpnHtJbbt+pZ+eGUWyHhre91fHFlmE6ptw4sJ
	dh0Q==
Received: by 10.224.199.132 with SMTP id es4mr40029280qab.43.1348582889801;
	Tue, 25 Sep 2012 07:21:29 -0700 (PDT)
Received: from phenom.dumpdata.com
	(50-195-21-189-static.hfc.comcastbusiness.net. [50.195.21.189])
	by mx.google.com with ESMTPS id l3sm921971qan.19.2012.09.25.07.21.28
	(version=TLSv1/SSLv3 cipher=OTHER);
	Tue, 25 Sep 2012 07:21:29 -0700 (PDT)
Date: Tue, 25 Sep 2012 10:10:13 -0400
From: Konrad Rzeszutek Wilk <konrad@kernel.org>
To: John Krstev <john.krstev@gmail.com>
Message-ID: <20120925141013.GC16478@phenom.dumpdata.com>
References: <CA+LkAa=RHJCtpncP8AUSeR8Te3ZLMvRctuZqnv_NwUkCQ-im8Q@mail.gmail.com>
	<20120921172901.GA6821@phenom.dumpdata.com>
	<099949C5-C4C0-4D57-A778-849C94781372@gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <099949C5-C4C0-4D57-A778-849C94781372@gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Xen + DVB = not working. memory allocation 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 Tue, Sep 25, 2012 at 10:49:38AM +1000, John Krstev wrote:
> Hello Konrad,

Hey John,

Please do not top-post.
> 
> Do you have any patches I can try? FYI I've tried booting dom0 with mem=3G and various other options, still does not work. As I mentioned it runs fine on bare metal. 

So try also limiting how much memory the hypervisor has to eliminate
this being a 4GB issue. Meaning on the _hypervisor_ line add 'mem=4G'.

The next step is to actually figure out if where in the driver (cx88)
fails. And I need to know whether you are running this in a domain or
in the initial domain? If you crank up all the debug options do you
get anything saying what the problem is? How do you 'capture' the
video output? If you do it manually (cat /dev/video0 > /tmp/file.mpg)
does the file increase? Is it full of garbage ?

Does the channel selection work? Can you select the proper channel?

> 
> Last time it did work with xen was Jeremy's kernel + xen 4.0, also kernel 3.0.8 with xen 4.0.4 i believe (cannot reproduce success).
> 
> Thank you again for your input. 
> 
> Regards,
> 
> John
> 
> 
> 
> On 22/09/2012, at 3:29, Konrad Rzeszutek Wilk <konrad@kernel.org> wrote:
> 
> > On Fri, Sep 21, 2012 at 01:02:23PM +1000, John Krstev wrote:
> >> Hi Konrad,
> > 
> > Hey John,
> > 
> > Please next time also include xen-devel on the To header. I've done that
> > for you.
> >> 
> >> I refer to your patch at:
> >> http://lists.xen.org/archives/html/xen-devel/2012-01/msg01927.html
> >> which I found reading
> >> http://www.gossamer-threads.com/lists/xen/devel/256197
> >> 
> >> I have a winfast DVT 2000H (cx88) DVB card which is not able to
> >> scan/watch digital TV when running under Xen.
> > 
> > Did you first try running it under baremetal Linux (using a Live CD for
> > example?) Did it work there?
> > 
> > How does it not work? Can you program it? Is this under a guest or the
> > main kernel? When it wsa not working, did you try all the debug
> > options enable (http://wiki.xen.org/wiki/XenSerialConsole) to
> > see if there is anthing being reported?
> > 
> >> 
> >> I've tried installing the above patch to the 3.6-rc6 kernel, but did
> >> not seem to help.
> >> 
> >> Apologies if this has been asked before (I wasn't able to find another
> >> patch), but is there a patch to get this (suspected vmalloc_32) fixed
> >> and DVB card working?
> > 
> > Eventually yes.
> >> 
> >> FYI I'm running 64 bit 3.5-rc6 and xen 4.3-unstable.
> > 
> > 3.5-rc6 or 3.6-rc6?
> > I presume the latter?
> >> 
> >> Thank you! :)
> >> 
> >> Regards,
> >> 
> >> John
> >> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Sep 25 14:22:45 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 14: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 1TGW21-0003AR-2q; Tue, 25 Sep 2012 14:22:37 +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 1TGW1z-0003A2-8Y
	for xen-devel@lists.xen.org; Tue, 25 Sep 2012 14:22:35 +0000
Received: from [85.158.139.211:34553] by server-1.bemta-5.messagelabs.com id
	EB/D1-09825-A2EB1605; Tue, 25 Sep 2012 14:22:34 +0000
X-Env-Sender: ben.guthro@gmail.com
X-Msg-Ref: server-11.tower-206.messagelabs.com!1348582951!19914923!1
X-Originating-IP: [209.85.223.173]
X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE,
	RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12557 invoked from network); 25 Sep 2012 14:22:32 -0000
Received: from mail-ie0-f173.google.com (HELO mail-ie0-f173.google.com)
	(209.85.223.173)
	by server-11.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Sep 2012 14:22:32 -0000
Received: by iea17 with SMTP id 17so11654336iea.32
	for <xen-devel@lists.xen.org>; Tue, 25 Sep 2012 07:22:31 -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=MZTxvWXDQYY1otGNK6slzfLY9pcykq/0tMF29kVcJSc=;
	b=m1K+fX+l8u3bB8bjMBvm7sYS8kiiz9onJW7xR3BJdxje19VM8nP9uHszulMTCxqIdU
	5qEFz60p8On14GbZi+pMdpo1UOwwaLFXHokVunsu3f41JRZW/f7cYptjfvEFxBbYe+mP
	LAK0zxmnlg4m53ChJ8y6gdo5nSXREw/UimvpPeZWC1QzjTqbpY7M7RxQ9C+okgyABFPx
	BSoekCHKeax88/nbpL+ddbNJMXwSSUdCkw2PjcvKgAAb9cfGSlPLZTCue+AeIhyNeypi
	WbUy4Izm4VEOnbwXD1I3MRyVqYa4OgpcYRPDDW2RR+j02UAWWW85t0S+0jjyQI1LeXgH
	2ITA==
MIME-Version: 1.0
Received: by 10.50.190.230 with SMTP id gt6mr8273571igc.49.1348582951031; Tue,
	25 Sep 2012 07:22:31 -0700 (PDT)
Received: by 10.64.55.132 with HTTP; Tue, 25 Sep 2012 07:22:30 -0700 (PDT)
In-Reply-To: <CAOvdn6Vsnbcd7m8mh3tSgn3KaEoeiOyVD1mr3uQ3bN=rF=pDUQ@mail.gmail.com>
References: <CAOvdn6UCF2A3yP1cqWn=dxwr0ayRbr+rg+xj8META9Dm0+CoNw@mail.gmail.com>
	<CC868168.3FD29%keir.xen@gmail.com>
	<CAOvdn6U-JyLvt96gkLkqzi088tU9_ktv4D+fkJac_BKVe05Y-w@mail.gmail.com>
	<CAOvdn6V+s3AbRzsu8VArbmrZou=im9SqvPf-9Wpif_BrNMv=yg@mail.gmail.com>
	<50617297020000780009D8AA@nat28.tlf.novell.com>
	<CAOvdn6Vsnbcd7m8mh3tSgn3KaEoeiOyVD1mr3uQ3bN=rF=pDUQ@mail.gmail.com>
Date: Tue, 25 Sep 2012 10:22:30 -0400
X-Google-Sender-Auth: e_sg0XZ0mJrfhwyqD8sz8pequXA
Message-ID: <CAOvdn6X6_NwfTNTgwNG7CQOqu2oDb6o6r1Zf+5y0cwZGLKToxA@mail.gmail.com>
From: Ben Guthro <ben@guthro.net>
To: Jan Beulich <JBeulich@suse.com>
Cc: Keir Fraser <keir.xen@gmail.com>, John Baboval <john.baboval@citrix.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen4.2 S3 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: multipart/mixed; boundary="===============1146436197524404307=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============1146436197524404307==
Content-Type: multipart/alternative; boundary=14dae93406bbbf14f804ca876f6d

--14dae93406bbbf14f804ca876f6d
Content-Type: text/plain; charset=ISO-8859-1

I went back to an old patch that had, since it was in this same function
that you made reference to:
http://markmail.org/message/qpnmiqzt5bngeejk

I noticed that I was not seeing the "Breaking vcpu affinity" printk - so I
tried to get that

The change proposed in that thread seems to work around this pinning
problem.
However, I'm not sure that it is the "right thing" to be doing.

Do you have any thoughts on this?


On Tue, Sep 25, 2012 at 7:56 AM, Ben Guthro <ben@guthro.net> wrote:

>
> On Tue, Sep 25, 2012 at 3:00 AM, Jan Beulich <JBeulich@suse.com> wrote:
>
>> >>> On 24.09.12 at 23:12, Ben Guthro <ben@guthro.net> wrote:
>> > Here's my "Big hammer" debugging patch.
>> >
>> > If I force the cpu to be scheduled on CPU0 when the appropriate cpu is
>> not
>> > online, I can resume properly.
>> >
>> > Clearly this is not the proper solution, and I'm sure the fix is subtle.
>> > I'm not seeing it right now though. Perhaps tomorrow morning.
>> > If you have any ideas, I'm happy to run tests then.
>>
>> I can't see how the printk() you add in the patch would ever get
>> reached with the other adjustment you do there.
>
>
> Apologies. I failed to separate prior debugging in this patch from the
> "big hammer" fix
>
>
>> A debug build,
>> as Keir suggested, would not only get the stack trace right, but
>> would also result in the ASSERT() right after your first modification
>> to _csched_cpu_pick() to actually do something (and likely trigger).
>>
>
> Indeed. I was using non-debug builds for 2 reasons that, in hindsight may
> not be the best of reasons.
> 1. It was the default
> 2. Mukesh's kdb debugger requires debug to be off, which I was making use
> of previously, and had not disabled.
>
> The stack from a debug build can be found below.
> It did, indeed trigger the ASSERT, as you predicted.
>
>
> (XEN) Finishing wakeup from ACPI S3 state.
> (XEN) Enabling non-boot CPUs  ...
> (XEN) Booting processor 1/1 eip 8a000
> (XEN) Initializing CPU#1
> (XEN) CPU: L1 I cache: 32K, L1 D cache: 32K
> (XEN) CPU: L2 cache: 3072K
> (XEN) CPU: Physical Processor ID: 0
> (XEN) CPU: Processor Core ID: 1
> (XEN) CMCI: CPU1 has no CMCI support
> (XEN) CPU1: Thermal monitoring enabled (TM2)
> (XEN) CPU1: Intel(R) Core(TM)2 Duo CPU     P8400  @ 2.26GHz stepping 06
> (XEN) microcode: CPU1 updated from revision 0x60c to 0x60f, date =
> 2010-09-29
> [   82.310025] ACPI: Low-level resume complete
> [   82.310025] PM: Restoring platform NVS memory
> [   82.310025] Enabling non-boot CPUs ...
> [   82.310025] installing Xen timer for CPU 1
> [   82.310025] cpu 1 spinlock event irq 279
> (XEN) Assertion '!cpumask_empty(&cpus) && cpumask_test_cpu(cpu, &cpus)'
> failed at sched_credit.c:477
> (XEN) ----[ Xen-4.2.1-pre  x86_64  debug=y  Tainted:    C ]----
> (XEN) CPU:    1
> (XEN) RIP:    e008:[<ffff82c48011a35a>] _csched_cpu_pick+0x135/0x552
> (XEN) RFLAGS: 0000000000010002   CONTEXT: hypervisor
> (XEN) rax: 0000000000000001   rbx: 0000000000000004   rcx: 0000000000000004
> (XEN) rdx: 000000000000000f   rsi: 0000000000000004   rdi: 0000000000000000
> (XEN) rbp: ffff8301355d7dd8   rsp: ffff8301355d7d08   r8:  0000000000000000
> (XEN) r9:  000000000000003e   r10: ffff82c480231700   r11: 0000000000000246
> (XEN) r12: ffff82c480261b20   r13: 0000000000000001   r14: ffff82c480301a60
> (XEN) r15: ffff83013a542068   cr0: 000000008005003b   cr4: 00000000000026f0
> (XEN) cr3: 0000000131a05000   cr2: 0000000000000000
> (XEN) ds: 002b   es: 002b   fs: 0000   gs: 0000   ss: e010   cs: e008
> (XEN) Xen stack trace from rsp=ffff8301355d7d08:
> (XEN)    0100000131a05000 ffff8301355d7d40 0000000000000082
> 0000000000000002
> (XEN)    ffff8300bd503000 0000000000000001 0000000000000297
> ffff8301355d7d58
> (XEN)    ffff82c480125499 ffff830138216000 ffff8301355d7d98
> 5400000000000002
> (XEN)    0000000000000286 ffff8301355d7d88 ffff82c480125499
> ffff830138216000
> (XEN)    0000000000000000 0000000000000000 0000000000000000
> 0000000000000000
> (XEN)    ffff830134ca6a50 ffff83013a542068 ffff83013a542068
> 0000000000000001
> (XEN)    ffff82c480301a60 ffff83013a542068 ffff8301355d7de8
> ffff82c48011a785
> (XEN)    ffff8301355d7e58 ffff82c480123519 ffff82c480301a60
> ffff82c480301a60
> (XEN)    ffff82c480301a60 ffff8300bd503000 0000000000503060
> 0000000000000246
> (XEN)    ffff82c480127c31 ffff8300bd503000 ffff82c480301a60
> ffff82c4802ebd40
> (XEN)    ffff83013a542068 ffff88003fc8e820 ffff8301355d7e88
> ffff82c4801237d3
> (XEN)    fffffffffffffffe ffff8301355ca000 ffff8300bd503000
> 0000000000000000
> (XEN)    ffff8301355d7ef8 ffff82c480106335 ffff8301355d7f18
> ffffffff810030e1
> (XEN)    ffff8300bd503000 0000000000000000 ffff8301355d7f08
> ffff82c480185390
> (XEN)    ffffffff81aafd32 ffff8300bd503000 0000000000000001
> 0000000000000000
> (XEN)    0000000000000000 ffff88003fc8e820 00007cfecaa280c7
> ffff82c480227348
> (XEN)    ffffffff8100130a 0000000000000018 ffff88003fc8e820
> 0000000000000000
> (XEN)    0000000000000000 0000000000000001 ffff88003976fda0
> ffff88003fc8bdc0
> (XEN)    0000000000000246 ffff88003976fe60 00000000ffffffff
> 0000000000000000
> (XEN)    0000000000000018 ffffffff8100130a 0000000000000000
> 0000000000000001
> (XEN) Xen call trace:
> (XEN)    [<ffff82c48011a35a>] _csched_cpu_pick+0x135/0x552
> (XEN)    [<ffff82c48011a785>] csched_cpu_pick+0xe/0x10
> (XEN)    [<ffff82c480123519>] vcpu_migrate+0x19f/0x346
> (XEN)    [<ffff82c4801237d3>] vcpu_force_reschedule+0xa4/0xb6
> (XEN)    [<ffff82c480106335>] do_vcpu_op+0x2c9/0x452
> (XEN)    [<ffff82c480227348>] syscall_enter+0xc8/0x122
> (XEN)
> (XEN)
> (XEN) ****************************************
> (XEN) Panic on CPU 1:
> (XEN) Assertion '!cpumask_empty(&cpus) && cpumask_test_cpu(cpu, &cpus)'
> failed at sched_credit.c:477
> (XEN) ****************************************
> (XEN)
> (XEN) Reboot in five seconds...
>
>
>> Anyway, this might be connected to cpu_disable_scheduler() not
>> having a counterpart to restore the affinity it broke for pinned
>> domains (for non-pinned ones I believe this behavior is intentional,
>> albeit not ideal).
>>
>> Jan
>>
>>
>

--14dae93406bbbf14f804ca876f6d
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div>I went back to an old patch that had, since it was in this same functi=
on that you made reference to:</div><a href=3D"http://markmail.org/message/=
qpnmiqzt5bngeejk">http://markmail.org/message/qpnmiqzt5bngeejk</a><div><br>
</div><div>I noticed that I was not seeing the &quot;Breaking vcpu affinity=
&quot; printk - so I tried to get that=A0</div><div><br></div><div>The chan=
ge proposed in that thread seems to work around this pinning problem.</div>
<div>However, I&#39;m not sure that it is the &quot;right thing&quot; to be=
 doing.</div><div><br></div><div>Do you have any thoughts on this?</div><di=
v><br><br><div class=3D"gmail_quote">On Tue, Sep 25, 2012 at 7:56 AM, Ben G=
uthro <span dir=3D"ltr">&lt;<a href=3D"mailto:ben@guthro.net" target=3D"_bl=
ank">ben@guthro.net</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"><br><div class=3D"gmail_quote"><div class=3D=
"im">On Tue, Sep 25, 2012 at 3:00 AM, Jan Beulich <span dir=3D"ltr">&lt;<a =
href=3D"mailto:JBeulich@suse.com" target=3D"_blank">JBeulich@suse.com</a>&g=
t;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
<div>&gt;&gt;&gt; On 24.09.12 at 23:12, Ben Guthro &lt;<a href=3D"mailto:be=
n@guthro.net" target=3D"_blank">ben@guthro.net</a>&gt; wrote:<br>
&gt; Here&#39;s my &quot;Big hammer&quot; debugging patch.<br>
&gt;<br>
&gt; If I force the cpu to be scheduled on CPU0 when the appropriate cpu is=
 not<br>
&gt; online, I can resume properly.<br>
&gt;<br>
&gt; Clearly this is not the proper solution, and I&#39;m sure the fix is s=
ubtle.<br>
&gt; I&#39;m not seeing it right now though. Perhaps tomorrow morning.<br>
&gt; If you have any ideas, I&#39;m happy to run tests then.<br>
<br>
</div>I can&#39;t see how the printk() you add in the patch would ever get<=
br>
reached with the other adjustment you do there. </blockquote><div><br></div=
></div><div>Apologies. I failed to separate prior debugging in this patch f=
rom the &quot;big hammer&quot; fix</div><div class=3D"im"><div>=A0</div><bl=
ockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #=
ccc solid;padding-left:1ex">

A debug build,<br>
as Keir suggested, would not only get the stack trace right, but<br>
would also result in the ASSERT() right after your first modification<br>
to _csched_cpu_pick() to actually do something (and likely trigger).<br></b=
lockquote><div><br></div></div><div>Indeed. I was using non-debug builds fo=
r 2 reasons that, in hindsight may not be the best of reasons.</div><div>
1. It was the default</div>
<div>2. Mukesh&#39;s kdb debugger requires debug to be off, which I was mak=
ing use of previously, and had not disabled.</div><div>=A0</div><div>The st=
ack from a debug build can be found below.</div><div>It did, indeed trigger=
 the ASSERT, as you predicted.</div>

<div><br></div><div><br></div><div><div class=3D"im"><div>(XEN) Finishing w=
akeup from ACPI S3 state.</div><div>(XEN) Enabling non-boot CPUs =A0...</di=
v><div>(XEN) Booting processor 1/1 eip 8a000</div><div>(XEN) Initializing C=
PU#1</div>
<div>(XEN) CPU: L1 I cache: 32K, L1 D cache: 32K</div>
<div>(XEN) CPU: L2 cache: 3072K</div><div>(XEN) CPU: Physical Processor ID:=
 0</div><div>(XEN) CPU: Processor Core ID: 1</div><div>(XEN) CMCI: CPU1 has=
 no CMCI support</div><div>(XEN) CPU1: Thermal monitoring enabled (TM2)</di=
v>

<div>(XEN) CPU1: Intel(R) Core(TM)2 Duo CPU =A0 =A0 P8400 =A0@ 2.26GHz step=
ping 06</div><div>(XEN) microcode: CPU1 updated from revision 0x60c to 0x60=
f, date =3D 2010-09-29=A0</div></div><div>[ =A0 82.310025] ACPI: Low-level =
resume complete</div>

<div>[ =A0 82.310025] PM: Restoring platform NVS memory</div><div>[ =A0 82.=
310025] Enabling non-boot CPUs ...</div><div>[ =A0 82.310025] installing Xe=
n timer for CPU 1</div><div>[ =A0 82.310025] cpu 1 spinlock event irq 279</=
div>

<div>(XEN) Assertion &#39;!cpumask_empty(&amp;cpus) &amp;&amp; cpumask_test=
_cpu(cpu, &amp;cpus)&#39; failed at sched_credit.c:477</div><div>(XEN) ----=
[ Xen-4.2.1-pre =A0x86_64 =A0debug=3Dy =A0Tainted: =A0 =A0C ]----</div><div=
>(XEN) CPU: =A0 =A01</div>

<div>(XEN) RIP: =A0 =A0e008:[&lt;ffff82c48011a35a&gt;] _csched_cpu_pick+0x1=
35/0x552</div><div>(XEN) RFLAGS: 0000000000010002 =A0 CONTEXT: hypervisor</=
div><div>(XEN) rax: 0000000000000001 =A0 rbx: 0000000000000004 =A0 rcx: 000=
0000000000004</div>

<div>(XEN) rdx: 000000000000000f =A0 rsi: 0000000000000004 =A0 rdi: 0000000=
000000000</div><div>(XEN) rbp: ffff8301355d7dd8 =A0 rsp: ffff8301355d7d08 =
=A0 r8: =A00000000000000000</div><div>(XEN) r9: =A0000000000000003e =A0 r10=
: ffff82c480231700 =A0 r11: 0000000000000246</div>

<div>(XEN) r12: ffff82c480261b20 =A0 r13: 0000000000000001 =A0 r14: ffff82c=
480301a60</div><div>(XEN) r15: ffff83013a542068 =A0 cr0: 000000008005003b =
=A0 cr4: 00000000000026f0</div><div>(XEN) cr3: 0000000131a05000 =A0 cr2: 00=
00000000000000</div>
<div class=3D"im">
<div>(XEN) ds: 002b =A0 es: 002b =A0 fs: 0000 =A0 gs: 0000 =A0 ss: e010 =A0=
 cs: e008</div></div><div>(XEN) Xen stack trace from rsp=3Dffff8301355d7d08=
:</div><div>(XEN) =A0 =A00100000131a05000 ffff8301355d7d40 0000000000000082=
 0000000000000002</div>

<div>(XEN) =A0 =A0ffff8300bd503000 0000000000000001 0000000000000297 ffff83=
01355d7d58</div><div>(XEN) =A0 =A0ffff82c480125499 ffff830138216000 ffff830=
1355d7d98 5400000000000002</div><div>(XEN) =A0 =A00000000000000286 ffff8301=
355d7d88 ffff82c480125499 ffff830138216000</div>

<div>(XEN) =A0 =A00000000000000000 0000000000000000 0000000000000000 000000=
0000000000</div><div>(XEN) =A0 =A0ffff830134ca6a50 ffff83013a542068 ffff830=
13a542068 0000000000000001</div><div>(XEN) =A0 =A0ffff82c480301a60 ffff8301=
3a542068 ffff8301355d7de8 ffff82c48011a785</div>

<div>(XEN) =A0 =A0ffff8301355d7e58 ffff82c480123519 ffff82c480301a60 ffff82=
c480301a60</div><div>(XEN) =A0 =A0ffff82c480301a60 ffff8300bd503000 0000000=
000503060 0000000000000246</div><div>(XEN) =A0 =A0ffff82c480127c31 ffff8300=
bd503000 ffff82c480301a60 ffff82c4802ebd40</div>

<div>(XEN) =A0 =A0ffff83013a542068 ffff88003fc8e820 ffff8301355d7e88 ffff82=
c4801237d3</div><div>(XEN) =A0 =A0fffffffffffffffe ffff8301355ca000 ffff830=
0bd503000 0000000000000000</div><div>(XEN) =A0 =A0ffff8301355d7ef8 ffff82c4=
80106335 ffff8301355d7f18 ffffffff810030e1</div>

<div>(XEN) =A0 =A0ffff8300bd503000 0000000000000000 ffff8301355d7f08 ffff82=
c480185390</div><div>(XEN) =A0 =A0ffffffff81aafd32 ffff8300bd503000 0000000=
000000001 0000000000000000</div><div>(XEN) =A0 =A00000000000000000 ffff8800=
3fc8e820 00007cfecaa280c7 ffff82c480227348</div>

<div>(XEN) =A0 =A0ffffffff8100130a 0000000000000018 ffff88003fc8e820 000000=
0000000000</div><div class=3D"im"><div>(XEN) =A0 =A00000000000000000 000000=
0000000001 ffff88003976fda0 ffff88003fc8bdc0</div><div>(XEN) =A0 =A00000000=
000000246 ffff88003976fe60 00000000ffffffff 0000000000000000</div>

<div>(XEN) =A0 =A00000000000000018 ffffffff8100130a 0000000000000000 000000=
0000000001</div></div><div>(XEN) Xen call trace:</div><div>(XEN) =A0 =A0[&l=
t;ffff82c48011a35a&gt;] _csched_cpu_pick+0x135/0x552</div><div>(XEN) =A0 =
=A0[&lt;ffff82c48011a785&gt;] csched_cpu_pick+0xe/0x10</div>

<div>(XEN) =A0 =A0[&lt;ffff82c480123519&gt;] vcpu_migrate+0x19f/0x346</div>=
<div>(XEN) =A0 =A0[&lt;ffff82c4801237d3&gt;] vcpu_force_reschedule+0xa4/0xb=
6</div><div>(XEN) =A0 =A0[&lt;ffff82c480106335&gt;] do_vcpu_op+0x2c9/0x452<=
/div><div>

(XEN) =A0 =A0[&lt;ffff82c480227348&gt;] syscall_enter+0xc8/0x122</div><div>=
(XEN) =A0 =A0</div><div class=3D"im"><div>(XEN)=A0</div><div>(XEN) ********=
********************************</div><div>(XEN) Panic on CPU 1:</div></div=
><div>(XEN) Assertion &#39;!cpumask_empty(&amp;cpus) &amp;&amp; cpumask_tes=
t_cpu(cpu, &amp;cpus)&#39; failed at sched_credit.c:477</div>
<div class=3D"im">
<div>(XEN) ****************************************</div><div>(XEN)=A0</div=
><div>(XEN) Reboot in five seconds...</div></div></div><div><br></div><bloc=
kquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #cc=
c solid;padding-left:1ex">

<br><div class=3D"im">
Anyway, this might be connected to cpu_disable_scheduler() not<br>
having a counterpart to restore the affinity it broke for pinned<br>
domains (for non-pinned ones I believe this behavior is intentional,<br>
albeit not ideal).<br>
<span><font color=3D"#888888"><br>
Jan<br>
<br>
</font></span></div></blockquote></div><br>
</blockquote></div><br></div>

--14dae93406bbbf14f804ca876f6d--


--===============1146436197524404307==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============1146436197524404307==--


From xen-devel-bounces@lists.xen.org Tue Sep 25 14:22:45 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 14: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 1TGW21-0003AR-2q; Tue, 25 Sep 2012 14:22:37 +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 1TGW1z-0003A2-8Y
	for xen-devel@lists.xen.org; Tue, 25 Sep 2012 14:22:35 +0000
Received: from [85.158.139.211:34553] by server-1.bemta-5.messagelabs.com id
	EB/D1-09825-A2EB1605; Tue, 25 Sep 2012 14:22:34 +0000
X-Env-Sender: ben.guthro@gmail.com
X-Msg-Ref: server-11.tower-206.messagelabs.com!1348582951!19914923!1
X-Originating-IP: [209.85.223.173]
X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE,
	RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12557 invoked from network); 25 Sep 2012 14:22:32 -0000
Received: from mail-ie0-f173.google.com (HELO mail-ie0-f173.google.com)
	(209.85.223.173)
	by server-11.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Sep 2012 14:22:32 -0000
Received: by iea17 with SMTP id 17so11654336iea.32
	for <xen-devel@lists.xen.org>; Tue, 25 Sep 2012 07:22:31 -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=MZTxvWXDQYY1otGNK6slzfLY9pcykq/0tMF29kVcJSc=;
	b=m1K+fX+l8u3bB8bjMBvm7sYS8kiiz9onJW7xR3BJdxje19VM8nP9uHszulMTCxqIdU
	5qEFz60p8On14GbZi+pMdpo1UOwwaLFXHokVunsu3f41JRZW/f7cYptjfvEFxBbYe+mP
	LAK0zxmnlg4m53ChJ8y6gdo5nSXREw/UimvpPeZWC1QzjTqbpY7M7RxQ9C+okgyABFPx
	BSoekCHKeax88/nbpL+ddbNJMXwSSUdCkw2PjcvKgAAb9cfGSlPLZTCue+AeIhyNeypi
	WbUy4Izm4VEOnbwXD1I3MRyVqYa4OgpcYRPDDW2RR+j02UAWWW85t0S+0jjyQI1LeXgH
	2ITA==
MIME-Version: 1.0
Received: by 10.50.190.230 with SMTP id gt6mr8273571igc.49.1348582951031; Tue,
	25 Sep 2012 07:22:31 -0700 (PDT)
Received: by 10.64.55.132 with HTTP; Tue, 25 Sep 2012 07:22:30 -0700 (PDT)
In-Reply-To: <CAOvdn6Vsnbcd7m8mh3tSgn3KaEoeiOyVD1mr3uQ3bN=rF=pDUQ@mail.gmail.com>
References: <CAOvdn6UCF2A3yP1cqWn=dxwr0ayRbr+rg+xj8META9Dm0+CoNw@mail.gmail.com>
	<CC868168.3FD29%keir.xen@gmail.com>
	<CAOvdn6U-JyLvt96gkLkqzi088tU9_ktv4D+fkJac_BKVe05Y-w@mail.gmail.com>
	<CAOvdn6V+s3AbRzsu8VArbmrZou=im9SqvPf-9Wpif_BrNMv=yg@mail.gmail.com>
	<50617297020000780009D8AA@nat28.tlf.novell.com>
	<CAOvdn6Vsnbcd7m8mh3tSgn3KaEoeiOyVD1mr3uQ3bN=rF=pDUQ@mail.gmail.com>
Date: Tue, 25 Sep 2012 10:22:30 -0400
X-Google-Sender-Auth: e_sg0XZ0mJrfhwyqD8sz8pequXA
Message-ID: <CAOvdn6X6_NwfTNTgwNG7CQOqu2oDb6o6r1Zf+5y0cwZGLKToxA@mail.gmail.com>
From: Ben Guthro <ben@guthro.net>
To: Jan Beulich <JBeulich@suse.com>
Cc: Keir Fraser <keir.xen@gmail.com>, John Baboval <john.baboval@citrix.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen4.2 S3 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: multipart/mixed; boundary="===============1146436197524404307=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============1146436197524404307==
Content-Type: multipart/alternative; boundary=14dae93406bbbf14f804ca876f6d

--14dae93406bbbf14f804ca876f6d
Content-Type: text/plain; charset=ISO-8859-1

I went back to an old patch that had, since it was in this same function
that you made reference to:
http://markmail.org/message/qpnmiqzt5bngeejk

I noticed that I was not seeing the "Breaking vcpu affinity" printk - so I
tried to get that

The change proposed in that thread seems to work around this pinning
problem.
However, I'm not sure that it is the "right thing" to be doing.

Do you have any thoughts on this?


On Tue, Sep 25, 2012 at 7:56 AM, Ben Guthro <ben@guthro.net> wrote:

>
> On Tue, Sep 25, 2012 at 3:00 AM, Jan Beulich <JBeulich@suse.com> wrote:
>
>> >>> On 24.09.12 at 23:12, Ben Guthro <ben@guthro.net> wrote:
>> > Here's my "Big hammer" debugging patch.
>> >
>> > If I force the cpu to be scheduled on CPU0 when the appropriate cpu is
>> not
>> > online, I can resume properly.
>> >
>> > Clearly this is not the proper solution, and I'm sure the fix is subtle.
>> > I'm not seeing it right now though. Perhaps tomorrow morning.
>> > If you have any ideas, I'm happy to run tests then.
>>
>> I can't see how the printk() you add in the patch would ever get
>> reached with the other adjustment you do there.
>
>
> Apologies. I failed to separate prior debugging in this patch from the
> "big hammer" fix
>
>
>> A debug build,
>> as Keir suggested, would not only get the stack trace right, but
>> would also result in the ASSERT() right after your first modification
>> to _csched_cpu_pick() to actually do something (and likely trigger).
>>
>
> Indeed. I was using non-debug builds for 2 reasons that, in hindsight may
> not be the best of reasons.
> 1. It was the default
> 2. Mukesh's kdb debugger requires debug to be off, which I was making use
> of previously, and had not disabled.
>
> The stack from a debug build can be found below.
> It did, indeed trigger the ASSERT, as you predicted.
>
>
> (XEN) Finishing wakeup from ACPI S3 state.
> (XEN) Enabling non-boot CPUs  ...
> (XEN) Booting processor 1/1 eip 8a000
> (XEN) Initializing CPU#1
> (XEN) CPU: L1 I cache: 32K, L1 D cache: 32K
> (XEN) CPU: L2 cache: 3072K
> (XEN) CPU: Physical Processor ID: 0
> (XEN) CPU: Processor Core ID: 1
> (XEN) CMCI: CPU1 has no CMCI support
> (XEN) CPU1: Thermal monitoring enabled (TM2)
> (XEN) CPU1: Intel(R) Core(TM)2 Duo CPU     P8400  @ 2.26GHz stepping 06
> (XEN) microcode: CPU1 updated from revision 0x60c to 0x60f, date =
> 2010-09-29
> [   82.310025] ACPI: Low-level resume complete
> [   82.310025] PM: Restoring platform NVS memory
> [   82.310025] Enabling non-boot CPUs ...
> [   82.310025] installing Xen timer for CPU 1
> [   82.310025] cpu 1 spinlock event irq 279
> (XEN) Assertion '!cpumask_empty(&cpus) && cpumask_test_cpu(cpu, &cpus)'
> failed at sched_credit.c:477
> (XEN) ----[ Xen-4.2.1-pre  x86_64  debug=y  Tainted:    C ]----
> (XEN) CPU:    1
> (XEN) RIP:    e008:[<ffff82c48011a35a>] _csched_cpu_pick+0x135/0x552
> (XEN) RFLAGS: 0000000000010002   CONTEXT: hypervisor
> (XEN) rax: 0000000000000001   rbx: 0000000000000004   rcx: 0000000000000004
> (XEN) rdx: 000000000000000f   rsi: 0000000000000004   rdi: 0000000000000000
> (XEN) rbp: ffff8301355d7dd8   rsp: ffff8301355d7d08   r8:  0000000000000000
> (XEN) r9:  000000000000003e   r10: ffff82c480231700   r11: 0000000000000246
> (XEN) r12: ffff82c480261b20   r13: 0000000000000001   r14: ffff82c480301a60
> (XEN) r15: ffff83013a542068   cr0: 000000008005003b   cr4: 00000000000026f0
> (XEN) cr3: 0000000131a05000   cr2: 0000000000000000
> (XEN) ds: 002b   es: 002b   fs: 0000   gs: 0000   ss: e010   cs: e008
> (XEN) Xen stack trace from rsp=ffff8301355d7d08:
> (XEN)    0100000131a05000 ffff8301355d7d40 0000000000000082
> 0000000000000002
> (XEN)    ffff8300bd503000 0000000000000001 0000000000000297
> ffff8301355d7d58
> (XEN)    ffff82c480125499 ffff830138216000 ffff8301355d7d98
> 5400000000000002
> (XEN)    0000000000000286 ffff8301355d7d88 ffff82c480125499
> ffff830138216000
> (XEN)    0000000000000000 0000000000000000 0000000000000000
> 0000000000000000
> (XEN)    ffff830134ca6a50 ffff83013a542068 ffff83013a542068
> 0000000000000001
> (XEN)    ffff82c480301a60 ffff83013a542068 ffff8301355d7de8
> ffff82c48011a785
> (XEN)    ffff8301355d7e58 ffff82c480123519 ffff82c480301a60
> ffff82c480301a60
> (XEN)    ffff82c480301a60 ffff8300bd503000 0000000000503060
> 0000000000000246
> (XEN)    ffff82c480127c31 ffff8300bd503000 ffff82c480301a60
> ffff82c4802ebd40
> (XEN)    ffff83013a542068 ffff88003fc8e820 ffff8301355d7e88
> ffff82c4801237d3
> (XEN)    fffffffffffffffe ffff8301355ca000 ffff8300bd503000
> 0000000000000000
> (XEN)    ffff8301355d7ef8 ffff82c480106335 ffff8301355d7f18
> ffffffff810030e1
> (XEN)    ffff8300bd503000 0000000000000000 ffff8301355d7f08
> ffff82c480185390
> (XEN)    ffffffff81aafd32 ffff8300bd503000 0000000000000001
> 0000000000000000
> (XEN)    0000000000000000 ffff88003fc8e820 00007cfecaa280c7
> ffff82c480227348
> (XEN)    ffffffff8100130a 0000000000000018 ffff88003fc8e820
> 0000000000000000
> (XEN)    0000000000000000 0000000000000001 ffff88003976fda0
> ffff88003fc8bdc0
> (XEN)    0000000000000246 ffff88003976fe60 00000000ffffffff
> 0000000000000000
> (XEN)    0000000000000018 ffffffff8100130a 0000000000000000
> 0000000000000001
> (XEN) Xen call trace:
> (XEN)    [<ffff82c48011a35a>] _csched_cpu_pick+0x135/0x552
> (XEN)    [<ffff82c48011a785>] csched_cpu_pick+0xe/0x10
> (XEN)    [<ffff82c480123519>] vcpu_migrate+0x19f/0x346
> (XEN)    [<ffff82c4801237d3>] vcpu_force_reschedule+0xa4/0xb6
> (XEN)    [<ffff82c480106335>] do_vcpu_op+0x2c9/0x452
> (XEN)    [<ffff82c480227348>] syscall_enter+0xc8/0x122
> (XEN)
> (XEN)
> (XEN) ****************************************
> (XEN) Panic on CPU 1:
> (XEN) Assertion '!cpumask_empty(&cpus) && cpumask_test_cpu(cpu, &cpus)'
> failed at sched_credit.c:477
> (XEN) ****************************************
> (XEN)
> (XEN) Reboot in five seconds...
>
>
>> Anyway, this might be connected to cpu_disable_scheduler() not
>> having a counterpart to restore the affinity it broke for pinned
>> domains (for non-pinned ones I believe this behavior is intentional,
>> albeit not ideal).
>>
>> Jan
>>
>>
>

--14dae93406bbbf14f804ca876f6d
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div>I went back to an old patch that had, since it was in this same functi=
on that you made reference to:</div><a href=3D"http://markmail.org/message/=
qpnmiqzt5bngeejk">http://markmail.org/message/qpnmiqzt5bngeejk</a><div><br>
</div><div>I noticed that I was not seeing the &quot;Breaking vcpu affinity=
&quot; printk - so I tried to get that=A0</div><div><br></div><div>The chan=
ge proposed in that thread seems to work around this pinning problem.</div>
<div>However, I&#39;m not sure that it is the &quot;right thing&quot; to be=
 doing.</div><div><br></div><div>Do you have any thoughts on this?</div><di=
v><br><br><div class=3D"gmail_quote">On Tue, Sep 25, 2012 at 7:56 AM, Ben G=
uthro <span dir=3D"ltr">&lt;<a href=3D"mailto:ben@guthro.net" target=3D"_bl=
ank">ben@guthro.net</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"><br><div class=3D"gmail_quote"><div class=3D=
"im">On Tue, Sep 25, 2012 at 3:00 AM, Jan Beulich <span dir=3D"ltr">&lt;<a =
href=3D"mailto:JBeulich@suse.com" target=3D"_blank">JBeulich@suse.com</a>&g=
t;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
<div>&gt;&gt;&gt; On 24.09.12 at 23:12, Ben Guthro &lt;<a href=3D"mailto:be=
n@guthro.net" target=3D"_blank">ben@guthro.net</a>&gt; wrote:<br>
&gt; Here&#39;s my &quot;Big hammer&quot; debugging patch.<br>
&gt;<br>
&gt; If I force the cpu to be scheduled on CPU0 when the appropriate cpu is=
 not<br>
&gt; online, I can resume properly.<br>
&gt;<br>
&gt; Clearly this is not the proper solution, and I&#39;m sure the fix is s=
ubtle.<br>
&gt; I&#39;m not seeing it right now though. Perhaps tomorrow morning.<br>
&gt; If you have any ideas, I&#39;m happy to run tests then.<br>
<br>
</div>I can&#39;t see how the printk() you add in the patch would ever get<=
br>
reached with the other adjustment you do there. </blockquote><div><br></div=
></div><div>Apologies. I failed to separate prior debugging in this patch f=
rom the &quot;big hammer&quot; fix</div><div class=3D"im"><div>=A0</div><bl=
ockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #=
ccc solid;padding-left:1ex">

A debug build,<br>
as Keir suggested, would not only get the stack trace right, but<br>
would also result in the ASSERT() right after your first modification<br>
to _csched_cpu_pick() to actually do something (and likely trigger).<br></b=
lockquote><div><br></div></div><div>Indeed. I was using non-debug builds fo=
r 2 reasons that, in hindsight may not be the best of reasons.</div><div>
1. It was the default</div>
<div>2. Mukesh&#39;s kdb debugger requires debug to be off, which I was mak=
ing use of previously, and had not disabled.</div><div>=A0</div><div>The st=
ack from a debug build can be found below.</div><div>It did, indeed trigger=
 the ASSERT, as you predicted.</div>

<div><br></div><div><br></div><div><div class=3D"im"><div>(XEN) Finishing w=
akeup from ACPI S3 state.</div><div>(XEN) Enabling non-boot CPUs =A0...</di=
v><div>(XEN) Booting processor 1/1 eip 8a000</div><div>(XEN) Initializing C=
PU#1</div>
<div>(XEN) CPU: L1 I cache: 32K, L1 D cache: 32K</div>
<div>(XEN) CPU: L2 cache: 3072K</div><div>(XEN) CPU: Physical Processor ID:=
 0</div><div>(XEN) CPU: Processor Core ID: 1</div><div>(XEN) CMCI: CPU1 has=
 no CMCI support</div><div>(XEN) CPU1: Thermal monitoring enabled (TM2)</di=
v>

<div>(XEN) CPU1: Intel(R) Core(TM)2 Duo CPU =A0 =A0 P8400 =A0@ 2.26GHz step=
ping 06</div><div>(XEN) microcode: CPU1 updated from revision 0x60c to 0x60=
f, date =3D 2010-09-29=A0</div></div><div>[ =A0 82.310025] ACPI: Low-level =
resume complete</div>

<div>[ =A0 82.310025] PM: Restoring platform NVS memory</div><div>[ =A0 82.=
310025] Enabling non-boot CPUs ...</div><div>[ =A0 82.310025] installing Xe=
n timer for CPU 1</div><div>[ =A0 82.310025] cpu 1 spinlock event irq 279</=
div>

<div>(XEN) Assertion &#39;!cpumask_empty(&amp;cpus) &amp;&amp; cpumask_test=
_cpu(cpu, &amp;cpus)&#39; failed at sched_credit.c:477</div><div>(XEN) ----=
[ Xen-4.2.1-pre =A0x86_64 =A0debug=3Dy =A0Tainted: =A0 =A0C ]----</div><div=
>(XEN) CPU: =A0 =A01</div>

<div>(XEN) RIP: =A0 =A0e008:[&lt;ffff82c48011a35a&gt;] _csched_cpu_pick+0x1=
35/0x552</div><div>(XEN) RFLAGS: 0000000000010002 =A0 CONTEXT: hypervisor</=
div><div>(XEN) rax: 0000000000000001 =A0 rbx: 0000000000000004 =A0 rcx: 000=
0000000000004</div>

<div>(XEN) rdx: 000000000000000f =A0 rsi: 0000000000000004 =A0 rdi: 0000000=
000000000</div><div>(XEN) rbp: ffff8301355d7dd8 =A0 rsp: ffff8301355d7d08 =
=A0 r8: =A00000000000000000</div><div>(XEN) r9: =A0000000000000003e =A0 r10=
: ffff82c480231700 =A0 r11: 0000000000000246</div>

<div>(XEN) r12: ffff82c480261b20 =A0 r13: 0000000000000001 =A0 r14: ffff82c=
480301a60</div><div>(XEN) r15: ffff83013a542068 =A0 cr0: 000000008005003b =
=A0 cr4: 00000000000026f0</div><div>(XEN) cr3: 0000000131a05000 =A0 cr2: 00=
00000000000000</div>
<div class=3D"im">
<div>(XEN) ds: 002b =A0 es: 002b =A0 fs: 0000 =A0 gs: 0000 =A0 ss: e010 =A0=
 cs: e008</div></div><div>(XEN) Xen stack trace from rsp=3Dffff8301355d7d08=
:</div><div>(XEN) =A0 =A00100000131a05000 ffff8301355d7d40 0000000000000082=
 0000000000000002</div>

<div>(XEN) =A0 =A0ffff8300bd503000 0000000000000001 0000000000000297 ffff83=
01355d7d58</div><div>(XEN) =A0 =A0ffff82c480125499 ffff830138216000 ffff830=
1355d7d98 5400000000000002</div><div>(XEN) =A0 =A00000000000000286 ffff8301=
355d7d88 ffff82c480125499 ffff830138216000</div>

<div>(XEN) =A0 =A00000000000000000 0000000000000000 0000000000000000 000000=
0000000000</div><div>(XEN) =A0 =A0ffff830134ca6a50 ffff83013a542068 ffff830=
13a542068 0000000000000001</div><div>(XEN) =A0 =A0ffff82c480301a60 ffff8301=
3a542068 ffff8301355d7de8 ffff82c48011a785</div>

<div>(XEN) =A0 =A0ffff8301355d7e58 ffff82c480123519 ffff82c480301a60 ffff82=
c480301a60</div><div>(XEN) =A0 =A0ffff82c480301a60 ffff8300bd503000 0000000=
000503060 0000000000000246</div><div>(XEN) =A0 =A0ffff82c480127c31 ffff8300=
bd503000 ffff82c480301a60 ffff82c4802ebd40</div>

<div>(XEN) =A0 =A0ffff83013a542068 ffff88003fc8e820 ffff8301355d7e88 ffff82=
c4801237d3</div><div>(XEN) =A0 =A0fffffffffffffffe ffff8301355ca000 ffff830=
0bd503000 0000000000000000</div><div>(XEN) =A0 =A0ffff8301355d7ef8 ffff82c4=
80106335 ffff8301355d7f18 ffffffff810030e1</div>

<div>(XEN) =A0 =A0ffff8300bd503000 0000000000000000 ffff8301355d7f08 ffff82=
c480185390</div><div>(XEN) =A0 =A0ffffffff81aafd32 ffff8300bd503000 0000000=
000000001 0000000000000000</div><div>(XEN) =A0 =A00000000000000000 ffff8800=
3fc8e820 00007cfecaa280c7 ffff82c480227348</div>

<div>(XEN) =A0 =A0ffffffff8100130a 0000000000000018 ffff88003fc8e820 000000=
0000000000</div><div class=3D"im"><div>(XEN) =A0 =A00000000000000000 000000=
0000000001 ffff88003976fda0 ffff88003fc8bdc0</div><div>(XEN) =A0 =A00000000=
000000246 ffff88003976fe60 00000000ffffffff 0000000000000000</div>

<div>(XEN) =A0 =A00000000000000018 ffffffff8100130a 0000000000000000 000000=
0000000001</div></div><div>(XEN) Xen call trace:</div><div>(XEN) =A0 =A0[&l=
t;ffff82c48011a35a&gt;] _csched_cpu_pick+0x135/0x552</div><div>(XEN) =A0 =
=A0[&lt;ffff82c48011a785&gt;] csched_cpu_pick+0xe/0x10</div>

<div>(XEN) =A0 =A0[&lt;ffff82c480123519&gt;] vcpu_migrate+0x19f/0x346</div>=
<div>(XEN) =A0 =A0[&lt;ffff82c4801237d3&gt;] vcpu_force_reschedule+0xa4/0xb=
6</div><div>(XEN) =A0 =A0[&lt;ffff82c480106335&gt;] do_vcpu_op+0x2c9/0x452<=
/div><div>

(XEN) =A0 =A0[&lt;ffff82c480227348&gt;] syscall_enter+0xc8/0x122</div><div>=
(XEN) =A0 =A0</div><div class=3D"im"><div>(XEN)=A0</div><div>(XEN) ********=
********************************</div><div>(XEN) Panic on CPU 1:</div></div=
><div>(XEN) Assertion &#39;!cpumask_empty(&amp;cpus) &amp;&amp; cpumask_tes=
t_cpu(cpu, &amp;cpus)&#39; failed at sched_credit.c:477</div>
<div class=3D"im">
<div>(XEN) ****************************************</div><div>(XEN)=A0</div=
><div>(XEN) Reboot in five seconds...</div></div></div><div><br></div><bloc=
kquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #cc=
c solid;padding-left:1ex">

<br><div class=3D"im">
Anyway, this might be connected to cpu_disable_scheduler() not<br>
having a counterpart to restore the affinity it broke for pinned<br>
domains (for non-pinned ones I believe this behavior is intentional,<br>
albeit not ideal).<br>
<span><font color=3D"#888888"><br>
Jan<br>
<br>
</font></span></div></blockquote></div><br>
</blockquote></div><br></div>

--14dae93406bbbf14f804ca876f6d--


--===============1146436197524404307==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============1146436197524404307==--


From xen-devel-bounces@lists.xen.org Tue Sep 25 14:29:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 14:29:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGW8F-0003Xj-42; Tue, 25 Sep 2012 14:29: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 1TGW8D-0003Xe-KD
	for xen-devel@lists.xen.org; Tue, 25 Sep 2012 14:29:01 +0000
Received: from [85.158.143.35:58515] by server-3.bemta-4.messagelabs.com id
	86/5E-10986-CAFB1605; Tue, 25 Sep 2012 14:29:00 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1348583340!16263792!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTEwNzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7524 invoked from network); 25 Sep 2012 14:29:00 -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;
	25 Sep 2012 14:29:00 -0000
X-IronPort-AV: E=Sophos;i="4.80,483,1344211200"; d="scan'208";a="14753269"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Sep 2012 14:29:00 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Tue, 25 Sep 2012 15:29:00 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1TGW8C-0007f6-1G; Tue, 25 Sep 2012 14:29:00 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1TGW8B-0006Zi-RX;
	Tue, 25 Sep 2012 15:28:59 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20577.49067.710246.317319@mariner.uk.xensource.com>
Date: Tue, 25 Sep 2012 15:28:59 +0100
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1348576819.3452.199.camel@zakaz.uk.xensource.com>
References: <ba1c6e807c8b1684a83e.1347871431@cosworth.uk.xensource.com>
	<1348566052.3452.145.camel@zakaz.uk.xensource.com>
	<20577.33326.654049.560825@mariner.uk.xensource.com>
	<1348576819.3452.199.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>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] tools: bump SONAMEs for changes during 4.2
 development cycle
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("Re: [Xen-devel] [PATCH] tools: bump SONAMEs for changes during 4.2 development cycle"):
> On Tue, 2012-09-25 at 11:06 +0100, Ian Jackson wrote:
> > Also for 4.2.
> 
> I assume you'll do that once it passes through a test?

Yes.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 25 14:29:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 14:29:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGW8F-0003Xj-42; Tue, 25 Sep 2012 14:29: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 1TGW8D-0003Xe-KD
	for xen-devel@lists.xen.org; Tue, 25 Sep 2012 14:29:01 +0000
Received: from [85.158.143.35:58515] by server-3.bemta-4.messagelabs.com id
	86/5E-10986-CAFB1605; Tue, 25 Sep 2012 14:29:00 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1348583340!16263792!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTEwNzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7524 invoked from network); 25 Sep 2012 14:29:00 -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;
	25 Sep 2012 14:29:00 -0000
X-IronPort-AV: E=Sophos;i="4.80,483,1344211200"; d="scan'208";a="14753269"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Sep 2012 14:29:00 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Tue, 25 Sep 2012 15:29:00 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1TGW8C-0007f6-1G; Tue, 25 Sep 2012 14:29:00 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1TGW8B-0006Zi-RX;
	Tue, 25 Sep 2012 15:28:59 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20577.49067.710246.317319@mariner.uk.xensource.com>
Date: Tue, 25 Sep 2012 15:28:59 +0100
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1348576819.3452.199.camel@zakaz.uk.xensource.com>
References: <ba1c6e807c8b1684a83e.1347871431@cosworth.uk.xensource.com>
	<1348566052.3452.145.camel@zakaz.uk.xensource.com>
	<20577.33326.654049.560825@mariner.uk.xensource.com>
	<1348576819.3452.199.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>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] tools: bump SONAMEs for changes during 4.2
 development cycle
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("Re: [Xen-devel] [PATCH] tools: bump SONAMEs for changes during 4.2 development cycle"):
> On Tue, 2012-09-25 at 11:06 +0100, Ian Jackson wrote:
> > Also for 4.2.
> 
> I assume you'll do that once it passes through a test?

Yes.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 25 14:31:09 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 14: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 1TGWA7-0003dG-QE; Tue, 25 Sep 2012 14:30: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 1TGWA6-0003cz-Cv
	for xen-devel@lists.xensource.com; Tue, 25 Sep 2012 14:30:58 +0000
Received: from [85.158.137.99:15803] by server-10.bemta-3.messagelabs.com id
	4F/EA-10411-120C1605; Tue, 25 Sep 2012 14:30:57 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-217.messagelabs.com!1348583454!14324953!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTEwNzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9515 invoked from network); 25 Sep 2012 14:30:55 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Sep 2012 14:30:55 -0000
X-IronPort-AV: E=Sophos;i="4.80,483,1344211200"; d="scan'208";a="14753307"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Sep 2012 14:30: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.279.1;
	Tue, 25 Sep 2012 15:30:40 +0100
Message-ID: <1348583438.11229.23.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Anil Madhavapeddy <anil@recoil.org>
Date: Tue, 25 Sep 2012 15:30:38 +0100
In-Reply-To: <2D15A521-63E8-4CE7-8D42-62A67FBD75B2@recoil.org>
References: <CAGnmK4wB3ZJ3Tb9-VFgWCkcZNwibDzRYV8tvb14vLgw1wj2awQ@mail.gmail.com>
	<50607A68.2090604@xen.org>
	<1348561354.3452.105.camel@zakaz.uk.xensource.com>
	<2D15A521-63E8-4CE7-8D42-62A67FBD75B2@recoil.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "lars.kurth@xen.org" <lars.kurth@xen.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"xen-api@lists.xensource.com" <xen-api@lists.xensource.com>
Subject: Re: [Xen-devel] [Xen-API]  Proposal - Add xe manpages to xen-org
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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-09-25 at 15:19 +0100, Anil Madhavapeddy wrote:
> On 25 Sep 2012, at 04:22, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> 
> > On Mon, 2012-09-24 at 16:21 +0100, Lars Kurth wrote:
> >> On 24/09/2012 16:06, Grant McWilliams wrote:
> >>> Xen Community,
> >>> 
> >>>    I have a team of people frantically creating manpages for the xe 
> >>> command and all of it's 361 subcommands. The initial source 
> >>> documentation is in asciidoc but also saved as Docbook. From docbook 
> >>> we transform to epub, html, manpage and pdf. This is currently being 
> >>> hosted in a subversion server at a Seattle area college and we'd like 
> >>> to move it to the xen-org github so it's public, can be reviewed, 
> >>> commented on and contributed too.
> > 
> > IME the best way to ensure that documentation remains current as the
> > code base changes is to check it in next to the code in the same repo.
> > 
> > This requires a little bit of discipline from the maintainers, to
> > remember to request appropriate docs updates when code patches require
> > them, but has been pretty effective e.g. for the xen-unstable code base.
> 
> While xe man-pages are sorely needed, wouldn't it be better to autogenerate
> it from the existing xe/xapi help by converting it to groff/asciidoc?

According to the original mail it is in asciidoc already, so maybe this
is already the case?

I agree that actually in the source is even better than next to the
source, if it's an option...

> Manually keeping the zillion commands in sync will be quite the ongoing 
> effort.

Someone still needs to write/update the text regardless of where it
lives, but that's as much a code review thing as anything else.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 25 14:31:09 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 14: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 1TGWA7-0003dG-QE; Tue, 25 Sep 2012 14:30: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 1TGWA6-0003cz-Cv
	for xen-devel@lists.xensource.com; Tue, 25 Sep 2012 14:30:58 +0000
Received: from [85.158.137.99:15803] by server-10.bemta-3.messagelabs.com id
	4F/EA-10411-120C1605; Tue, 25 Sep 2012 14:30:57 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-217.messagelabs.com!1348583454!14324953!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTEwNzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9515 invoked from network); 25 Sep 2012 14:30:55 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Sep 2012 14:30:55 -0000
X-IronPort-AV: E=Sophos;i="4.80,483,1344211200"; d="scan'208";a="14753307"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Sep 2012 14:30: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.279.1;
	Tue, 25 Sep 2012 15:30:40 +0100
Message-ID: <1348583438.11229.23.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Anil Madhavapeddy <anil@recoil.org>
Date: Tue, 25 Sep 2012 15:30:38 +0100
In-Reply-To: <2D15A521-63E8-4CE7-8D42-62A67FBD75B2@recoil.org>
References: <CAGnmK4wB3ZJ3Tb9-VFgWCkcZNwibDzRYV8tvb14vLgw1wj2awQ@mail.gmail.com>
	<50607A68.2090604@xen.org>
	<1348561354.3452.105.camel@zakaz.uk.xensource.com>
	<2D15A521-63E8-4CE7-8D42-62A67FBD75B2@recoil.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "lars.kurth@xen.org" <lars.kurth@xen.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"xen-api@lists.xensource.com" <xen-api@lists.xensource.com>
Subject: Re: [Xen-devel] [Xen-API]  Proposal - Add xe manpages to xen-org
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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-09-25 at 15:19 +0100, Anil Madhavapeddy wrote:
> On 25 Sep 2012, at 04:22, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> 
> > On Mon, 2012-09-24 at 16:21 +0100, Lars Kurth wrote:
> >> On 24/09/2012 16:06, Grant McWilliams wrote:
> >>> Xen Community,
> >>> 
> >>>    I have a team of people frantically creating manpages for the xe 
> >>> command and all of it's 361 subcommands. The initial source 
> >>> documentation is in asciidoc but also saved as Docbook. From docbook 
> >>> we transform to epub, html, manpage and pdf. This is currently being 
> >>> hosted in a subversion server at a Seattle area college and we'd like 
> >>> to move it to the xen-org github so it's public, can be reviewed, 
> >>> commented on and contributed too.
> > 
> > IME the best way to ensure that documentation remains current as the
> > code base changes is to check it in next to the code in the same repo.
> > 
> > This requires a little bit of discipline from the maintainers, to
> > remember to request appropriate docs updates when code patches require
> > them, but has been pretty effective e.g. for the xen-unstable code base.
> 
> While xe man-pages are sorely needed, wouldn't it be better to autogenerate
> it from the existing xe/xapi help by converting it to groff/asciidoc?

According to the original mail it is in asciidoc already, so maybe this
is already the case?

I agree that actually in the source is even better than next to the
source, if it's an option...

> Manually keeping the zillion commands in sync will be quite the ongoing 
> effort.

Someone still needs to write/update the text regardless of where it
lives, but that's as much a code review thing as anything else.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 25 14:32:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 14:32:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGWBB-0003kr-8f; Tue, 25 Sep 2012 14:32: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 1TGWBA-0003kf-1e
	for xen-devel@lists.xen.org; Tue, 25 Sep 2012 14:32:04 +0000
Received: from [85.158.139.211:42585] by server-9.bemta-5.messagelabs.com id
	FC/70-14846-360C1605; Tue, 25 Sep 2012 14:32:03 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-206.messagelabs.com!1348583522!19942857!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTEwNzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8700 invoked from network); 25 Sep 2012 14:32:02 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Sep 2012 14:32:02 -0000
X-IronPort-AV: E=Sophos;i="4.80,483,1344211200"; d="scan'208";a="14753340"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Sep 2012 14:32: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.279.1;
	Tue, 25 Sep 2012 15:32:02 +0100
Message-ID: <1348583521.11229.24.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Anthony PERARD <anthony.perard@citrix.com>
Date: Tue, 25 Sep 2012 15:32:01 +0100
In-Reply-To: <5061BDAE.5030700@citrix.com>
References: <1347906148-9606-1-git-send-email-anthony.perard@citrix.com>
	<1347906148-9606-4-git-send-email-anthony.perard@citrix.com>
	<1348562684.3452.116.camel@zakaz.uk.xensource.com>
	<5061BDAE.5030700@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Xen Devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH V2 3/9] libxl_json: Introduce
 libxl__json_object_to_yajl_gen.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-09-25 at 15:20 +0100, Anthony PERARD wrote:
> >> +    case JSON_ANY:
> > 
> > Is JSON_ANY sort of like a JSON "void *"? Is it ever valid to be passed
> > one here, IOW does this represent a coding error (==abort()) or a run
> > time one (== log something)?
> 
> This value is only used as parameter of one function,
> libxl__json_map_get, that return an object from the json_object tree
> with the expected type. But sometime we don't expect any type so
> JSON_ANY is used and allow "map_get" to return any type of object.
> 
> So JSON_ANY is not valid here and would probably be a coding error.

Lets abort() then.

> 
> >> +    default:
> > 
> > If you skip this default case then some compilers will warn (a runtime
> > error) if we forget to add a new JSON_FOO here.
> 
> I tried to remove the default, but then gcc believe that the function
> would not return in some cases.

Gah! 

>  But I did not add a return because it
> felt weird to add a useless/never_executed return/abort.
> 
> But it seams better to remove the default case, so I will.
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 25 14:32:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 14:32:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGWBB-0003kr-8f; Tue, 25 Sep 2012 14:32: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 1TGWBA-0003kf-1e
	for xen-devel@lists.xen.org; Tue, 25 Sep 2012 14:32:04 +0000
Received: from [85.158.139.211:42585] by server-9.bemta-5.messagelabs.com id
	FC/70-14846-360C1605; Tue, 25 Sep 2012 14:32:03 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-206.messagelabs.com!1348583522!19942857!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTEwNzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8700 invoked from network); 25 Sep 2012 14:32:02 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Sep 2012 14:32:02 -0000
X-IronPort-AV: E=Sophos;i="4.80,483,1344211200"; d="scan'208";a="14753340"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Sep 2012 14:32: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.279.1;
	Tue, 25 Sep 2012 15:32:02 +0100
Message-ID: <1348583521.11229.24.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Anthony PERARD <anthony.perard@citrix.com>
Date: Tue, 25 Sep 2012 15:32:01 +0100
In-Reply-To: <5061BDAE.5030700@citrix.com>
References: <1347906148-9606-1-git-send-email-anthony.perard@citrix.com>
	<1347906148-9606-4-git-send-email-anthony.perard@citrix.com>
	<1348562684.3452.116.camel@zakaz.uk.xensource.com>
	<5061BDAE.5030700@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Xen Devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH V2 3/9] libxl_json: Introduce
 libxl__json_object_to_yajl_gen.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-09-25 at 15:20 +0100, Anthony PERARD wrote:
> >> +    case JSON_ANY:
> > 
> > Is JSON_ANY sort of like a JSON "void *"? Is it ever valid to be passed
> > one here, IOW does this represent a coding error (==abort()) or a run
> > time one (== log something)?
> 
> This value is only used as parameter of one function,
> libxl__json_map_get, that return an object from the json_object tree
> with the expected type. But sometime we don't expect any type so
> JSON_ANY is used and allow "map_get" to return any type of object.
> 
> So JSON_ANY is not valid here and would probably be a coding error.

Lets abort() then.

> 
> >> +    default:
> > 
> > If you skip this default case then some compilers will warn (a runtime
> > error) if we forget to add a new JSON_FOO here.
> 
> I tried to remove the default, but then gcc believe that the function
> would not return in some cases.

Gah! 

>  But I did not add a return because it
> felt weird to add a useless/never_executed return/abort.
> 
> But it seams better to remove the default case, so I will.
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 25 14:33:59 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 14:33:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGWCt-000445-5e; Tue, 25 Sep 2012 14:33: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 1TGWCr-00043e-L7
	for xen-devel@lists.xen.org; Tue, 25 Sep 2012 14:33:49 +0000
Received: from [85.158.143.99:63266] by server-3.bemta-4.messagelabs.com id
	48/66-10986-CC0C1605; Tue, 25 Sep 2012 14:33:48 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1348583627!23530109!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTEwNzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9245 invoked from network); 25 Sep 2012 14:33:47 -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;
	25 Sep 2012 14:33:47 -0000
X-IronPort-AV: E=Sophos;i="4.80,483,1344211200"; d="scan'208";a="14753389"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Sep 2012 14:33: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.279.1; Tue, 25 Sep 2012 15:33: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
	1TGWCp-0007pl-6e; Tue, 25 Sep 2012 14:33:47 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1TGWCp-0006aN-35;
	Tue, 25 Sep 2012 15:33:47 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20577.49354.986341.321870@mariner.uk.xensource.com>
Date: Tue, 25 Sep 2012 15:33:46 +0100
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1348579144.11229.6.camel@zakaz.uk.xensource.com>
References: <20576.36587.698928.396214@mariner.uk.xensource.com>
	<1348579144.11229.6.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] docs: network diagrams for the wiki
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("Re: [Xen-devel] [PATCH] docs: network diagrams for the wiki"):
> I think you've forgotten to "git add docs/figs/Makefile" ?

Oops.

From: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [PATCH v2] docs: network diagrams for the wiki

We provide two new diagrams
  docs/figs/network-{bridge,basic}.fig
which are converted to pngs by the Makefiles and intended for
consumption by http://wiki.xen.org/wiki/Xen_Networking.

This is perhaps not the ideal location for this source code but we
don't have a better one.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
v2: add missing docs/figs/Makefile

---
 .gitignore                   |    1 +
 .hgignore                    |    1 +
 docs/Makefile                |    7 ++-
 docs/figs/Makefile           |   15 +++++
 docs/figs/network-basic.fig  |   73 ++++++++++++++++++++++++
 docs/figs/network-bridge.fig |  125 ++++++++++++++++++++++++++++++++++++++++++
 6 files changed, 221 insertions(+), 1 deletions(-)

diff --git a/.gitignore b/.gitignore
index 776e4b2..022a7e8 100644
--- a/.gitignore
+++ b/.gitignore
@@ -392,3 +392,4 @@ tools/xenstore/xenstore-watch
 
 docs/txt/misc/*.txt
 docs/txt/man/*.txt
+docs/figs/*.png
diff --git a/.hgignore b/.hgignore
index 141809e..5095722 100644
--- a/.hgignore
+++ b/.hgignore
@@ -45,6 +45,7 @@
 ^docs/interface/interface\.css$
 ^docs/interface/interface\.html$
 ^docs/interface/labels\.pl$
+^docs/figs/.*\.png
 ^docs/man1/
 ^docs/man5/
 ^docs/pdf/.*$
diff --git a/docs/Makefile b/docs/Makefile
index 007a5a9..8806990 100644
--- a/docs/Makefile
+++ b/docs/Makefile
@@ -25,7 +25,7 @@ DOC_TXT         := $(patsubst %.txt,txt/%.txt,$(wildcard misc/*.txt)) \
 all: build
 
 .PHONY: build
-build: html txt man-pages
+build: html txt man-pages figs
 	@if which $(DOT) 1>/dev/null 2>/dev/null ; then              \
 	$(MAKE) -C xen-api build ; else                              \
         echo "Graphviz (dot) not installed; skipping xen-api." ; fi
@@ -40,6 +40,10 @@ html: $(DOC_HTML) html/index.html
 .PHONY: txt
 txt: $(DOC_TXT)
 
+.PHONY: figs
+figs:
+	$(MAKE) -C figs
+
 .PHONY: python-dev-docs
 python-dev-docs:
 	@mkdir -v -p api/tools/python
@@ -68,6 +72,7 @@ man5/%.5: man/%.pod.5 Makefile
 .PHONY: clean
 clean:
 	$(MAKE) -C xen-api clean
+	$(MAKE) -C figs clean
 	rm -rf .word_count *.aux *.dvi *.bbl *.blg *.glo *.idx *~ 
 	rm -rf *.ilg *.log *.ind *.toc *.bak core
 	rm -rf html txt
diff --git a/docs/figs/Makefile b/docs/figs/Makefile
new file mode 100644
index 0000000..5ecdae3
--- /dev/null
+++ b/docs/figs/Makefile
@@ -0,0 +1,15 @@
+
+XEN_ROOT=$(CURDIR)/../..
+include $(XEN_ROOT)/Config.mk
+include $(XEN_ROOT)/docs/Docs.mk
+
+TARGETS= network-bridge.png network-basic.png
+
+all: $(TARGETS)
+
+%.png:	%.fig
+	$(FIG2DEV) -L png $< >$@.tmp
+	mv -f $@.tmp $@
+
+clean:
+	rm -f *~ *.png
diff --git a/docs/figs/network-basic.fig b/docs/figs/network-basic.fig
new file mode 100644
index 0000000..b343def
--- /dev/null
+++ b/docs/figs/network-basic.fig
@@ -0,0 +1,73 @@
+#FIG 3.2  Produced by xfig version 3.2.5b
+Landscape
+Center
+Metric
+A4      
+100.00
+Single
+-2
+1200 2
+0 32 #c0c0c0
+6 4275 5160 6105 6315
+2 2 0 2 0 11 50 -1 28 0.000 0 0 7 0 0 5
+	 6090 5175 4290 5175 4290 6075 6090 6075 6090 5175
+2 2 0 2 0 11 50 -1 28 0.000 0 0 7 0 0 5
+	 4965 6075 5865 6075 5865 6300 4965 6300 4965 6075
+2 1 0 2 0 11 50 -1 28 0.000 0 0 7 0 0 4
+	 6090 5400 5865 5400 5865 5625 6090 5625
+-6
+6 7170 5145 9000 6300
+2 2 0 2 0 11 50 -1 28 0.000 0 0 7 0 0 5
+	 7185 5160 8985 5160 8985 6060 7185 6060 7185 5160
+2 2 0 2 0 11 50 -1 28 0.000 0 0 7 0 0 5
+	 8310 6060 7410 6060 7410 6285 8310 6285 8310 6060
+2 1 0 2 0 11 50 -1 28 0.000 0 0 7 0 0 4
+	 7185 5385 7410 5385 7410 5610 7185 5610
+-6
+6 900 4050 9225 4950
+4 0 0 50 -1 0 16 0.0000 4 195 1335 1170 4860 of the world\001
+4 0 0 50 -1 0 16 0.0000 4 240 1815 1080 4590 interface, to rest\001
+4 0 0 50 -1 0 16 0.0000 4 255 1890 990 4320 Physical network\001
+4 0 0 50 -1 0 16 0.0000 4 255 1485 4050 4860 guest's traffic\001
+4 0 0 50 -1 0 16 0.0000 4 195 1305 4050 4590 backend for\001
+4 0 0 50 -1 0 16 0.0000 4 195 1905 3960 4320 Virtual interface:\001
+4 0 0 50 -1 0 16 0.0000 4 195 1290 7515 4860 Xen drivers\001
+4 0 0 50 -1 0 16 0.0000 4 255 1290 7425 4590 provided by\001
+4 0 0 50 -1 0 16 0.0000 4 195 1905 7155 4320 Virtual interface:\001
+-6
+2 2 0 2 0 29 50 -1 20 0.000 0 0 7 0 0 5
+	 660 5160 2460 5160 2460 6060 660 6060 660 5160
+2 2 0 2 0 29 50 -1 20 0.000 0 0 7 0 0 5
+	 1785 6060 885 6060 885 6285 1785 6285 1785 6060
+2 1 0 2 0 29 50 -1 20 0.000 0 0 7 0 0 4
+	 660 5385 885 5385 900 5625 675 5625
+2 1 0 2 0 29 50 -1 -1 0.000 0 0 7 0 0 3
+	 675 6300 675 4950 450 4950
+2 1 0 3 1 29 50 -1 -1 0.000 0 0 7 0 0 2
+	 6075 5490 7200 5490
+2 1 0 3 4 29 50 -1 -1 0.000 0 0 -1 0 0 2
+	 675 5490 0 5490
+2 1 0 3 4 29 50 -1 -1 0.000 0 0 -1 0 0 2
+	 0 2475 0 6525
+2 2 0 1 0 32 100 -1 20 0.000 0 0 7 0 0 5
+	 675 2250 9675 2250 9675 6750 675 6750 675 2250
+2 2 0 1 0 7 70 -1 20 0.000 0 0 7 0 0 5
+	 6300 2925 900 2925 900 6525 6300 6525 6300 2925
+2 2 0 1 0 7 70 -1 20 0.000 0 0 7 0 0 5
+	 6975 6525 9450 6525 9450 2925 6975 2925 6975 6525
+2 2 0 1 7 7 125 -1 20 0.000 0 0 -1 0 0 5
+	 -225 2025 9900 2025 9900 6975 -225 6975 -225 2025
+4 0 0 50 -1 18 20 0.0000 4 240 735 1170 5490 ethN\001
+4 0 0 50 -1 18 20 0.0000 4 240 945 4500 5490 vifA.B\001
+4 0 0 50 -1 16 20 0.0000 4 315 1410 4500 5850 e.g. vif4.0\001
+4 0 0 50 -1 16 20 0.0000 4 315 1260 1125 5850 e.g. eth0\001
+4 0 0 50 -1 0 16 1.5708 4 255 1395 225 5400 physical link\001
+4 0 0 50 -1 18 20 0.0000 4 240 735 7875 5490 ethB\001
+4 0 0 50 -1 16 20 0.0000 4 315 1260 7650 5850 e.g. eth0\001
+4 0 0 50 -1 0 20 0.0000 4 300 1995 1530 3870 typically dom0\001
+4 0 0 50 -1 0 20 0.0000 4 285 3330 990 3420 Backend (driver) domain\001
+4 0 0 50 -1 0 20 0.0000 4 300 1785 7155 3420 guest domain\001
+4 0 0 50 -1 0 20 0.0000 4 300 1410 7155 3810 domU e.g.\001
+4 0 0 50 -1 16 20 0.0000 4 240 810 8550 3825 dom4\001
+4 0 0 50 -1 0 20 0.0000 4 300 1320 900 2700 Computer\001
+4 0 0 50 -1 0 16 1.5708 4 195 1350 6750 6210 virtual   link\001
diff --git a/docs/figs/network-bridge.fig b/docs/figs/network-bridge.fig
new file mode 100644
index 0000000..63c6ac4
--- /dev/null
+++ b/docs/figs/network-bridge.fig
@@ -0,0 +1,125 @@
+#FIG 3.2  Produced by xfig version 3.2.5b
+Landscape
+Center
+Metric
+A4      
+100.00
+Single
+-2
+1200 2
+0 32 #ffc3ff
+0 33 #c0c0c0
+6 -225 3825 2475 8325
+2 2 0 2 0 29 50 -1 20 0.000 0 0 7 0 0 5
+	 660 6735 2460 6735 2460 7635 660 7635 660 6735
+2 2 0 2 0 29 50 -1 20 0.000 0 0 7 0 0 5
+	 1785 7635 885 7635 885 7860 1785 7860 1785 7635
+2 1 0 2 0 29 50 -1 20 0.000 0 0 7 0 0 4
+	 660 6960 885 6960 900 7200 675 7200
+2 1 0 2 0 29 50 -1 -1 0.000 0 0 7 0 0 3
+	 675 7875 675 6525 450 6525
+2 1 0 3 4 29 50 -1 -1 0.000 0 0 -1 0 0 2
+	 675 7065 0 7065
+2 1 0 3 4 29 50 -1 -1 0.000 0 0 -1 0 0 2
+	 0 4050 0 8100
+4 0 0 50 -1 18 20 0.0000 4 240 675 1170 7065 eth0\001
+-6
+6 1936 4020 3149 5850
+2 2 0 2 0 32 50 -1 19 0.000 0 0 7 0 0 5
+	 1951 5835 1951 4035 2898 4035 2898 5835 1951 5835
+2 2 0 2 0 32 50 -1 19 0.000 0 0 7 0 0 5
+	 2898 4710 2898 5610 3134 5610 3134 4710 2898 4710
+2 1 0 2 0 32 50 -1 19 0.000 0 0 7 0 0 4
+	 2187 5835 2187 5610 2424 5610 2424 5835
+-6
+6 4275 5160 6105 6315
+2 2 0 2 0 11 50 -1 28 0.000 0 0 7 0 0 5
+	 6090 5175 4290 5175 4290 6075 6090 6075 6090 5175
+2 2 0 2 0 11 50 -1 28 0.000 0 0 7 0 0 5
+	 4965 6075 5865 6075 5865 6300 4965 6300 4965 6075
+2 1 0 2 0 11 50 -1 28 0.000 0 0 7 0 0 4
+	 6090 5400 5865 5400 5865 5625 6090 5625
+-6
+6 7170 5145 9000 6300
+2 2 0 2 0 11 50 -1 28 0.000 0 0 7 0 0 5
+	 7185 5160 8985 5160 8985 6060 7185 6060 7185 5160
+2 2 0 2 0 11 50 -1 28 0.000 0 0 7 0 0 5
+	 8310 6060 7410 6060 7410 6285 8310 6285 8310 6060
+2 1 0 2 0 11 50 -1 28 0.000 0 0 7 0 0 4
+	 7185 5385 7410 5385 7410 5610 7185 5610
+-6
+6 4275 7815 6105 8970
+2 2 0 2 0 11 50 -1 28 0.000 0 0 7 0 0 5
+	 6090 7830 4290 7830 4290 8730 6090 8730 6090 7830
+2 2 0 2 0 11 50 -1 28 0.000 0 0 7 0 0 5
+	 4965 8730 5865 8730 5865 8955 4965 8955 4965 8730
+2 1 0 2 0 11 50 -1 28 0.000 0 0 7 0 0 4
+	 6090 8055 5865 8055 5865 8280 6090 8280
+-6
+6 7170 7800 9000 8955
+2 2 0 2 0 11 50 -1 28 0.000 0 0 7 0 0 5
+	 7185 7815 8985 7815 8985 8715 7185 8715 7185 7815
+2 2 0 2 0 11 50 -1 28 0.000 0 0 7 0 0 5
+	 8310 8715 7410 8715 7410 8940 8310 8940 8310 8715
+2 1 0 2 0 11 50 -1 28 0.000 0 0 7 0 0 4
+	 7185 8040 7410 8040 7410 8265 7185 8265
+-6
+6 6975 6750 9450 9225
+6 6975 6750 9450 9225
+2 2 0 1 0 7 70 -1 20 0.000 0 0 7 0 0 5
+	 6975 9225 9450 9225 9450 6750 6975 6750 6975 9225
+4 0 0 50 -1 0 20 0.0000 4 270 705 7200 7200 guest\001
+4 0 0 50 -1 16 20 0.0000 4 240 810 8100 7200 dom7\001
+4 0 0 50 -1 16 20 0.0000 4 225 2070 7200 7650 198.51.100.32\001
+-6
+-6
+2 1 0 3 1 29 50 -1 -1 0.000 0 0 -1 0 0 2
+	 4275 5625 3375 5625
+2 1 0 3 1 29 50 -1 -1 0.000 0 0 -1 0 0 2
+	 4275 8325 3375 8325
+2 1 0 3 1 29 50 -1 -1 0.000 0 0 -1 0 0 2
+	 3375 7200 2475 7200
+2 1 0 3 1 29 50 -1 -1 0.000 0 0 -1 0 0 2
+	 3375 9000 3375 5220
+2 1 0 3 1 29 50 -1 -1 0.000 0 0 -1 0 0 3
+	 2250 5850 2250 6300 3375 6300
+2 2 0 1 0 7 70 -1 20 0.000 0 0 7 0 0 5
+	 6300 2925 900 2925 900 9450 6300 9450 6300 2925
+2 2 0 1 0 33 100 -1 20 0.000 0 0 7 0 0 5
+	 675 2250 9675 2250 9675 9675 675 9675 675 2250
+2 2 0 1 7 7 125 -1 20 0.000 0 0 7 0 0 5
+	 -225 9900 9900 9900 9900 2025 -225 2025 -225 9900
+2 1 0 3 1 29 50 -1 -1 0.000 0 0 7 0 0 2
+	 6075 5490 7200 5490
+2 2 0 1 0 7 70 -1 20 0.000 0 0 7 0 0 5
+	 6975 6525 9450 6525 9450 2925 6975 2925 6975 6525
+2 1 0 3 1 29 50 -1 -1 0.000 0 0 7 0 0 2
+	 6075 8145 7200 8145
+2 2 0 1 0 7 70 -1 20 0.000 0 0 7 0 0 5
+	 6975 6525 9450 6525 9450 5580 6975 5580 6975 6525
+2 2 0 1 0 29 50 -1 -1 0.000 0 0 -1 0 0 5
+	 1395 4230 5670 4230 5670 9180 1395 9180 1395 4230
+4 0 0 50 -1 0 16 1.5708 4 255 1395 225 5400 physical link\001
+4 0 0 50 -1 0 20 0.0000 4 300 1320 900 2700 Computer\001
+4 0 0 50 -1 0 20 0.0000 4 285 3330 990 3420 Backend (driver) domain\001
+4 0 0 50 -1 0 16 1.5708 4 195 1515 3690 7560 virtual switch\001
+4 0 0 50 -1 16 20 0.0000 4 225 1890 1440 3960 198.51.100.1\001
+4 0 0 50 -1 18 20 1.5708 4 240 1095 2250 5400 xenbr0\001
+4 0 0 50 -1 0 16 1.5708 4 255 1185 2520 5490 O/S bridge\001
+4 0 0 50 -1 0 16 1.5708 4 195 990 2790 5310 interface\001
+4 0 0 50 -1 0 20 0.0000 4 300 840 4680 4590 bridge\001
+4 0 0 50 -1 0 20 0.0000 4 225 1185 3330 4590 Software\001
+4 0 0 50 -1 0 20 0.0000 4 300 1785 7155 3420 guest domain\001
+4 0 0 50 -1 0 20 0.0000 4 300 1410 7155 3810 domU e.g.\001
+4 0 0 50 -1 16 20 0.0000 4 240 810 8550 3825 dom4\001
+4 0 0 50 -1 18 20 0.0000 4 240 825 4500 5490 vif4.0\001
+4 0 0 50 -1 18 20 0.0000 4 240 675 7875 5490 eth0\001
+4 0 0 50 -1 16 20 0.0000 4 225 2070 7200 4950 198.51.100.27\001
+4 0 0 50 -1 0 16 0.0000 4 255 1080 4500 5850 (netback)\001
+4 0 0 50 -1 0 16 0.0000 4 255 1140 7560 5850 (netfront)\001
+4 0 0 50 -1 0 16 1.5708 4 195 1350 6750 6210 virtual   link\001
+4 0 0 50 -1 0 16 0.0000 4 255 1080 4500 8505 (netback)\001
+4 0 0 50 -1 0 16 0.0000 4 255 1140 7560 8505 (netfront)\001
+4 0 0 50 -1 0 16 1.5708 4 195 1350 6750 8865 virtual   link\001
+4 0 0 50 -1 18 20 0.0000 4 240 825 4500 8190 vif7.0\001
+4 0 0 50 -1 18 20 0.0000 4 240 675 7830 8190 eth0\001
-- 
tg: (0730dd5..) t/xen/docs.wiki-figs (depends on: base)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 25 14:33:59 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 14:33:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGWCt-000445-5e; Tue, 25 Sep 2012 14:33: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 1TGWCr-00043e-L7
	for xen-devel@lists.xen.org; Tue, 25 Sep 2012 14:33:49 +0000
Received: from [85.158.143.99:63266] by server-3.bemta-4.messagelabs.com id
	48/66-10986-CC0C1605; Tue, 25 Sep 2012 14:33:48 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1348583627!23530109!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTEwNzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9245 invoked from network); 25 Sep 2012 14:33:47 -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;
	25 Sep 2012 14:33:47 -0000
X-IronPort-AV: E=Sophos;i="4.80,483,1344211200"; d="scan'208";a="14753389"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Sep 2012 14:33: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.279.1; Tue, 25 Sep 2012 15:33: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
	1TGWCp-0007pl-6e; Tue, 25 Sep 2012 14:33:47 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1TGWCp-0006aN-35;
	Tue, 25 Sep 2012 15:33:47 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20577.49354.986341.321870@mariner.uk.xensource.com>
Date: Tue, 25 Sep 2012 15:33:46 +0100
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1348579144.11229.6.camel@zakaz.uk.xensource.com>
References: <20576.36587.698928.396214@mariner.uk.xensource.com>
	<1348579144.11229.6.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] docs: network diagrams for the wiki
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("Re: [Xen-devel] [PATCH] docs: network diagrams for the wiki"):
> I think you've forgotten to "git add docs/figs/Makefile" ?

Oops.

From: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [PATCH v2] docs: network diagrams for the wiki

We provide two new diagrams
  docs/figs/network-{bridge,basic}.fig
which are converted to pngs by the Makefiles and intended for
consumption by http://wiki.xen.org/wiki/Xen_Networking.

This is perhaps not the ideal location for this source code but we
don't have a better one.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
v2: add missing docs/figs/Makefile

---
 .gitignore                   |    1 +
 .hgignore                    |    1 +
 docs/Makefile                |    7 ++-
 docs/figs/Makefile           |   15 +++++
 docs/figs/network-basic.fig  |   73 ++++++++++++++++++++++++
 docs/figs/network-bridge.fig |  125 ++++++++++++++++++++++++++++++++++++++++++
 6 files changed, 221 insertions(+), 1 deletions(-)

diff --git a/.gitignore b/.gitignore
index 776e4b2..022a7e8 100644
--- a/.gitignore
+++ b/.gitignore
@@ -392,3 +392,4 @@ tools/xenstore/xenstore-watch
 
 docs/txt/misc/*.txt
 docs/txt/man/*.txt
+docs/figs/*.png
diff --git a/.hgignore b/.hgignore
index 141809e..5095722 100644
--- a/.hgignore
+++ b/.hgignore
@@ -45,6 +45,7 @@
 ^docs/interface/interface\.css$
 ^docs/interface/interface\.html$
 ^docs/interface/labels\.pl$
+^docs/figs/.*\.png
 ^docs/man1/
 ^docs/man5/
 ^docs/pdf/.*$
diff --git a/docs/Makefile b/docs/Makefile
index 007a5a9..8806990 100644
--- a/docs/Makefile
+++ b/docs/Makefile
@@ -25,7 +25,7 @@ DOC_TXT         := $(patsubst %.txt,txt/%.txt,$(wildcard misc/*.txt)) \
 all: build
 
 .PHONY: build
-build: html txt man-pages
+build: html txt man-pages figs
 	@if which $(DOT) 1>/dev/null 2>/dev/null ; then              \
 	$(MAKE) -C xen-api build ; else                              \
         echo "Graphviz (dot) not installed; skipping xen-api." ; fi
@@ -40,6 +40,10 @@ html: $(DOC_HTML) html/index.html
 .PHONY: txt
 txt: $(DOC_TXT)
 
+.PHONY: figs
+figs:
+	$(MAKE) -C figs
+
 .PHONY: python-dev-docs
 python-dev-docs:
 	@mkdir -v -p api/tools/python
@@ -68,6 +72,7 @@ man5/%.5: man/%.pod.5 Makefile
 .PHONY: clean
 clean:
 	$(MAKE) -C xen-api clean
+	$(MAKE) -C figs clean
 	rm -rf .word_count *.aux *.dvi *.bbl *.blg *.glo *.idx *~ 
 	rm -rf *.ilg *.log *.ind *.toc *.bak core
 	rm -rf html txt
diff --git a/docs/figs/Makefile b/docs/figs/Makefile
new file mode 100644
index 0000000..5ecdae3
--- /dev/null
+++ b/docs/figs/Makefile
@@ -0,0 +1,15 @@
+
+XEN_ROOT=$(CURDIR)/../..
+include $(XEN_ROOT)/Config.mk
+include $(XEN_ROOT)/docs/Docs.mk
+
+TARGETS= network-bridge.png network-basic.png
+
+all: $(TARGETS)
+
+%.png:	%.fig
+	$(FIG2DEV) -L png $< >$@.tmp
+	mv -f $@.tmp $@
+
+clean:
+	rm -f *~ *.png
diff --git a/docs/figs/network-basic.fig b/docs/figs/network-basic.fig
new file mode 100644
index 0000000..b343def
--- /dev/null
+++ b/docs/figs/network-basic.fig
@@ -0,0 +1,73 @@
+#FIG 3.2  Produced by xfig version 3.2.5b
+Landscape
+Center
+Metric
+A4      
+100.00
+Single
+-2
+1200 2
+0 32 #c0c0c0
+6 4275 5160 6105 6315
+2 2 0 2 0 11 50 -1 28 0.000 0 0 7 0 0 5
+	 6090 5175 4290 5175 4290 6075 6090 6075 6090 5175
+2 2 0 2 0 11 50 -1 28 0.000 0 0 7 0 0 5
+	 4965 6075 5865 6075 5865 6300 4965 6300 4965 6075
+2 1 0 2 0 11 50 -1 28 0.000 0 0 7 0 0 4
+	 6090 5400 5865 5400 5865 5625 6090 5625
+-6
+6 7170 5145 9000 6300
+2 2 0 2 0 11 50 -1 28 0.000 0 0 7 0 0 5
+	 7185 5160 8985 5160 8985 6060 7185 6060 7185 5160
+2 2 0 2 0 11 50 -1 28 0.000 0 0 7 0 0 5
+	 8310 6060 7410 6060 7410 6285 8310 6285 8310 6060
+2 1 0 2 0 11 50 -1 28 0.000 0 0 7 0 0 4
+	 7185 5385 7410 5385 7410 5610 7185 5610
+-6
+6 900 4050 9225 4950
+4 0 0 50 -1 0 16 0.0000 4 195 1335 1170 4860 of the world\001
+4 0 0 50 -1 0 16 0.0000 4 240 1815 1080 4590 interface, to rest\001
+4 0 0 50 -1 0 16 0.0000 4 255 1890 990 4320 Physical network\001
+4 0 0 50 -1 0 16 0.0000 4 255 1485 4050 4860 guest's traffic\001
+4 0 0 50 -1 0 16 0.0000 4 195 1305 4050 4590 backend for\001
+4 0 0 50 -1 0 16 0.0000 4 195 1905 3960 4320 Virtual interface:\001
+4 0 0 50 -1 0 16 0.0000 4 195 1290 7515 4860 Xen drivers\001
+4 0 0 50 -1 0 16 0.0000 4 255 1290 7425 4590 provided by\001
+4 0 0 50 -1 0 16 0.0000 4 195 1905 7155 4320 Virtual interface:\001
+-6
+2 2 0 2 0 29 50 -1 20 0.000 0 0 7 0 0 5
+	 660 5160 2460 5160 2460 6060 660 6060 660 5160
+2 2 0 2 0 29 50 -1 20 0.000 0 0 7 0 0 5
+	 1785 6060 885 6060 885 6285 1785 6285 1785 6060
+2 1 0 2 0 29 50 -1 20 0.000 0 0 7 0 0 4
+	 660 5385 885 5385 900 5625 675 5625
+2 1 0 2 0 29 50 -1 -1 0.000 0 0 7 0 0 3
+	 675 6300 675 4950 450 4950
+2 1 0 3 1 29 50 -1 -1 0.000 0 0 7 0 0 2
+	 6075 5490 7200 5490
+2 1 0 3 4 29 50 -1 -1 0.000 0 0 -1 0 0 2
+	 675 5490 0 5490
+2 1 0 3 4 29 50 -1 -1 0.000 0 0 -1 0 0 2
+	 0 2475 0 6525
+2 2 0 1 0 32 100 -1 20 0.000 0 0 7 0 0 5
+	 675 2250 9675 2250 9675 6750 675 6750 675 2250
+2 2 0 1 0 7 70 -1 20 0.000 0 0 7 0 0 5
+	 6300 2925 900 2925 900 6525 6300 6525 6300 2925
+2 2 0 1 0 7 70 -1 20 0.000 0 0 7 0 0 5
+	 6975 6525 9450 6525 9450 2925 6975 2925 6975 6525
+2 2 0 1 7 7 125 -1 20 0.000 0 0 -1 0 0 5
+	 -225 2025 9900 2025 9900 6975 -225 6975 -225 2025
+4 0 0 50 -1 18 20 0.0000 4 240 735 1170 5490 ethN\001
+4 0 0 50 -1 18 20 0.0000 4 240 945 4500 5490 vifA.B\001
+4 0 0 50 -1 16 20 0.0000 4 315 1410 4500 5850 e.g. vif4.0\001
+4 0 0 50 -1 16 20 0.0000 4 315 1260 1125 5850 e.g. eth0\001
+4 0 0 50 -1 0 16 1.5708 4 255 1395 225 5400 physical link\001
+4 0 0 50 -1 18 20 0.0000 4 240 735 7875 5490 ethB\001
+4 0 0 50 -1 16 20 0.0000 4 315 1260 7650 5850 e.g. eth0\001
+4 0 0 50 -1 0 20 0.0000 4 300 1995 1530 3870 typically dom0\001
+4 0 0 50 -1 0 20 0.0000 4 285 3330 990 3420 Backend (driver) domain\001
+4 0 0 50 -1 0 20 0.0000 4 300 1785 7155 3420 guest domain\001
+4 0 0 50 -1 0 20 0.0000 4 300 1410 7155 3810 domU e.g.\001
+4 0 0 50 -1 16 20 0.0000 4 240 810 8550 3825 dom4\001
+4 0 0 50 -1 0 20 0.0000 4 300 1320 900 2700 Computer\001
+4 0 0 50 -1 0 16 1.5708 4 195 1350 6750 6210 virtual   link\001
diff --git a/docs/figs/network-bridge.fig b/docs/figs/network-bridge.fig
new file mode 100644
index 0000000..63c6ac4
--- /dev/null
+++ b/docs/figs/network-bridge.fig
@@ -0,0 +1,125 @@
+#FIG 3.2  Produced by xfig version 3.2.5b
+Landscape
+Center
+Metric
+A4      
+100.00
+Single
+-2
+1200 2
+0 32 #ffc3ff
+0 33 #c0c0c0
+6 -225 3825 2475 8325
+2 2 0 2 0 29 50 -1 20 0.000 0 0 7 0 0 5
+	 660 6735 2460 6735 2460 7635 660 7635 660 6735
+2 2 0 2 0 29 50 -1 20 0.000 0 0 7 0 0 5
+	 1785 7635 885 7635 885 7860 1785 7860 1785 7635
+2 1 0 2 0 29 50 -1 20 0.000 0 0 7 0 0 4
+	 660 6960 885 6960 900 7200 675 7200
+2 1 0 2 0 29 50 -1 -1 0.000 0 0 7 0 0 3
+	 675 7875 675 6525 450 6525
+2 1 0 3 4 29 50 -1 -1 0.000 0 0 -1 0 0 2
+	 675 7065 0 7065
+2 1 0 3 4 29 50 -1 -1 0.000 0 0 -1 0 0 2
+	 0 4050 0 8100
+4 0 0 50 -1 18 20 0.0000 4 240 675 1170 7065 eth0\001
+-6
+6 1936 4020 3149 5850
+2 2 0 2 0 32 50 -1 19 0.000 0 0 7 0 0 5
+	 1951 5835 1951 4035 2898 4035 2898 5835 1951 5835
+2 2 0 2 0 32 50 -1 19 0.000 0 0 7 0 0 5
+	 2898 4710 2898 5610 3134 5610 3134 4710 2898 4710
+2 1 0 2 0 32 50 -1 19 0.000 0 0 7 0 0 4
+	 2187 5835 2187 5610 2424 5610 2424 5835
+-6
+6 4275 5160 6105 6315
+2 2 0 2 0 11 50 -1 28 0.000 0 0 7 0 0 5
+	 6090 5175 4290 5175 4290 6075 6090 6075 6090 5175
+2 2 0 2 0 11 50 -1 28 0.000 0 0 7 0 0 5
+	 4965 6075 5865 6075 5865 6300 4965 6300 4965 6075
+2 1 0 2 0 11 50 -1 28 0.000 0 0 7 0 0 4
+	 6090 5400 5865 5400 5865 5625 6090 5625
+-6
+6 7170 5145 9000 6300
+2 2 0 2 0 11 50 -1 28 0.000 0 0 7 0 0 5
+	 7185 5160 8985 5160 8985 6060 7185 6060 7185 5160
+2 2 0 2 0 11 50 -1 28 0.000 0 0 7 0 0 5
+	 8310 6060 7410 6060 7410 6285 8310 6285 8310 6060
+2 1 0 2 0 11 50 -1 28 0.000 0 0 7 0 0 4
+	 7185 5385 7410 5385 7410 5610 7185 5610
+-6
+6 4275 7815 6105 8970
+2 2 0 2 0 11 50 -1 28 0.000 0 0 7 0 0 5
+	 6090 7830 4290 7830 4290 8730 6090 8730 6090 7830
+2 2 0 2 0 11 50 -1 28 0.000 0 0 7 0 0 5
+	 4965 8730 5865 8730 5865 8955 4965 8955 4965 8730
+2 1 0 2 0 11 50 -1 28 0.000 0 0 7 0 0 4
+	 6090 8055 5865 8055 5865 8280 6090 8280
+-6
+6 7170 7800 9000 8955
+2 2 0 2 0 11 50 -1 28 0.000 0 0 7 0 0 5
+	 7185 7815 8985 7815 8985 8715 7185 8715 7185 7815
+2 2 0 2 0 11 50 -1 28 0.000 0 0 7 0 0 5
+	 8310 8715 7410 8715 7410 8940 8310 8940 8310 8715
+2 1 0 2 0 11 50 -1 28 0.000 0 0 7 0 0 4
+	 7185 8040 7410 8040 7410 8265 7185 8265
+-6
+6 6975 6750 9450 9225
+6 6975 6750 9450 9225
+2 2 0 1 0 7 70 -1 20 0.000 0 0 7 0 0 5
+	 6975 9225 9450 9225 9450 6750 6975 6750 6975 9225
+4 0 0 50 -1 0 20 0.0000 4 270 705 7200 7200 guest\001
+4 0 0 50 -1 16 20 0.0000 4 240 810 8100 7200 dom7\001
+4 0 0 50 -1 16 20 0.0000 4 225 2070 7200 7650 198.51.100.32\001
+-6
+-6
+2 1 0 3 1 29 50 -1 -1 0.000 0 0 -1 0 0 2
+	 4275 5625 3375 5625
+2 1 0 3 1 29 50 -1 -1 0.000 0 0 -1 0 0 2
+	 4275 8325 3375 8325
+2 1 0 3 1 29 50 -1 -1 0.000 0 0 -1 0 0 2
+	 3375 7200 2475 7200
+2 1 0 3 1 29 50 -1 -1 0.000 0 0 -1 0 0 2
+	 3375 9000 3375 5220
+2 1 0 3 1 29 50 -1 -1 0.000 0 0 -1 0 0 3
+	 2250 5850 2250 6300 3375 6300
+2 2 0 1 0 7 70 -1 20 0.000 0 0 7 0 0 5
+	 6300 2925 900 2925 900 9450 6300 9450 6300 2925
+2 2 0 1 0 33 100 -1 20 0.000 0 0 7 0 0 5
+	 675 2250 9675 2250 9675 9675 675 9675 675 2250
+2 2 0 1 7 7 125 -1 20 0.000 0 0 7 0 0 5
+	 -225 9900 9900 9900 9900 2025 -225 2025 -225 9900
+2 1 0 3 1 29 50 -1 -1 0.000 0 0 7 0 0 2
+	 6075 5490 7200 5490
+2 2 0 1 0 7 70 -1 20 0.000 0 0 7 0 0 5
+	 6975 6525 9450 6525 9450 2925 6975 2925 6975 6525
+2 1 0 3 1 29 50 -1 -1 0.000 0 0 7 0 0 2
+	 6075 8145 7200 8145
+2 2 0 1 0 7 70 -1 20 0.000 0 0 7 0 0 5
+	 6975 6525 9450 6525 9450 5580 6975 5580 6975 6525
+2 2 0 1 0 29 50 -1 -1 0.000 0 0 -1 0 0 5
+	 1395 4230 5670 4230 5670 9180 1395 9180 1395 4230
+4 0 0 50 -1 0 16 1.5708 4 255 1395 225 5400 physical link\001
+4 0 0 50 -1 0 20 0.0000 4 300 1320 900 2700 Computer\001
+4 0 0 50 -1 0 20 0.0000 4 285 3330 990 3420 Backend (driver) domain\001
+4 0 0 50 -1 0 16 1.5708 4 195 1515 3690 7560 virtual switch\001
+4 0 0 50 -1 16 20 0.0000 4 225 1890 1440 3960 198.51.100.1\001
+4 0 0 50 -1 18 20 1.5708 4 240 1095 2250 5400 xenbr0\001
+4 0 0 50 -1 0 16 1.5708 4 255 1185 2520 5490 O/S bridge\001
+4 0 0 50 -1 0 16 1.5708 4 195 990 2790 5310 interface\001
+4 0 0 50 -1 0 20 0.0000 4 300 840 4680 4590 bridge\001
+4 0 0 50 -1 0 20 0.0000 4 225 1185 3330 4590 Software\001
+4 0 0 50 -1 0 20 0.0000 4 300 1785 7155 3420 guest domain\001
+4 0 0 50 -1 0 20 0.0000 4 300 1410 7155 3810 domU e.g.\001
+4 0 0 50 -1 16 20 0.0000 4 240 810 8550 3825 dom4\001
+4 0 0 50 -1 18 20 0.0000 4 240 825 4500 5490 vif4.0\001
+4 0 0 50 -1 18 20 0.0000 4 240 675 7875 5490 eth0\001
+4 0 0 50 -1 16 20 0.0000 4 225 2070 7200 4950 198.51.100.27\001
+4 0 0 50 -1 0 16 0.0000 4 255 1080 4500 5850 (netback)\001
+4 0 0 50 -1 0 16 0.0000 4 255 1140 7560 5850 (netfront)\001
+4 0 0 50 -1 0 16 1.5708 4 195 1350 6750 6210 virtual   link\001
+4 0 0 50 -1 0 16 0.0000 4 255 1080 4500 8505 (netback)\001
+4 0 0 50 -1 0 16 0.0000 4 255 1140 7560 8505 (netfront)\001
+4 0 0 50 -1 0 16 1.5708 4 195 1350 6750 8865 virtual   link\001
+4 0 0 50 -1 18 20 0.0000 4 240 825 4500 8190 vif7.0\001
+4 0 0 50 -1 18 20 0.0000 4 240 675 7830 8190 eth0\001
-- 
tg: (0730dd5..) t/xen/docs.wiki-figs (depends on: base)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 25 14:34:00 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 14: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 1TGWCs-00043w-Pf; Tue, 25 Sep 2012 14:33: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 1TGWCr-00043e-89
	for xen-devel@lists.xen.org; Tue, 25 Sep 2012 14:33:49 +0000
Received: from [85.158.143.99:17897] by server-3.bemta-4.messagelabs.com id
	67/66-10986-CC0C1605; Tue, 25 Sep 2012 14:33:48 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1348583627!23530109!2
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTEwNzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9302 invoked from network); 25 Sep 2012 14:33:48 -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;
	25 Sep 2012 14:33:48 -0000
X-IronPort-AV: E=Sophos;i="4.80,483,1344211200"; d="scan'208";a="14753390"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Sep 2012 14:33: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.279.1;
	Tue, 25 Sep 2012 15:33:47 +0100
Message-ID: <1348583626.11229.26.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Date: Tue, 25 Sep 2012 15:33:46 +0100
In-Reply-To: <5061BD4E.6000905@citrix.com>
References: <5061BD4E.6000905@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-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] RFC: EFER in crash notes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-09-25 at 15:18 +0100, Andrew Cooper wrote:
> While this patch is very simple, and I hope without any objection, it is
> RFC for the reason that our crash ABI is private.
> 
> The comments for XEN_ELFNOTE_CRASH_REGS does state that it is
> architecture specific, and makes no indication about the size or
> contents of the crash note.  However, any code trying to use one of
> these types of notes has to make an assumption that it if the note desc
> length is 4*8 bytes long, it is representing CR{0,2-4}.
> 
> I guess my question boils down to whether it is acceptable to change a
> private ABI which is not really so private, or whether we should make a
> formal public ABI for all of the inards of the crash notes and use that.

Is it really private? (or even "not so private"), don't external tools
like crash support it?

I suppose the size field in the notes is a sort of rudimentary version
field. Remember you can always add a new note type though.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 25 14:34:00 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 14: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 1TGWCs-00043w-Pf; Tue, 25 Sep 2012 14:33: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 1TGWCr-00043e-89
	for xen-devel@lists.xen.org; Tue, 25 Sep 2012 14:33:49 +0000
Received: from [85.158.143.99:17897] by server-3.bemta-4.messagelabs.com id
	67/66-10986-CC0C1605; Tue, 25 Sep 2012 14:33:48 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1348583627!23530109!2
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTEwNzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9302 invoked from network); 25 Sep 2012 14:33:48 -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;
	25 Sep 2012 14:33:48 -0000
X-IronPort-AV: E=Sophos;i="4.80,483,1344211200"; d="scan'208";a="14753390"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Sep 2012 14:33: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.279.1;
	Tue, 25 Sep 2012 15:33:47 +0100
Message-ID: <1348583626.11229.26.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Date: Tue, 25 Sep 2012 15:33:46 +0100
In-Reply-To: <5061BD4E.6000905@citrix.com>
References: <5061BD4E.6000905@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-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] RFC: EFER in crash notes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-09-25 at 15:18 +0100, Andrew Cooper wrote:
> While this patch is very simple, and I hope without any objection, it is
> RFC for the reason that our crash ABI is private.
> 
> The comments for XEN_ELFNOTE_CRASH_REGS does state that it is
> architecture specific, and makes no indication about the size or
> contents of the crash note.  However, any code trying to use one of
> these types of notes has to make an assumption that it if the note desc
> length is 4*8 bytes long, it is representing CR{0,2-4}.
> 
> I guess my question boils down to whether it is acceptable to change a
> private ABI which is not really so private, or whether we should make a
> formal public ABI for all of the inards of the crash notes and use that.

Is it really private? (or even "not so private"), don't external tools
like crash support it?

I suppose the size field in the notes is a sort of rudimentary version
field. Remember you can always add a new note type though.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 25 14:36:54 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 14:36: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 1TGWFb-0004Lv-Og; Tue, 25 Sep 2012 14:36: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 1TGWFZ-0004Lg-Lm
	for xen-devel@lists.xen.org; Tue, 25 Sep 2012 14:36:38 +0000
Received: from [85.158.143.35:34558] by server-3.bemta-4.messagelabs.com id
	74/F9-10986-471C1605; Tue, 25 Sep 2012 14:36:36 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1348583796!16264861!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTEwNzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4513 invoked from network); 25 Sep 2012 14:36:36 -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;
	25 Sep 2012 14:36:36 -0000
X-IronPort-AV: E=Sophos;i="4.80,483,1344211200"; d="scan'208";a="14753500"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Sep 2012 14:36: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.279.1;
	Tue, 25 Sep 2012 15:36:35 +0100
Message-ID: <1348583794.11229.28.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Tue, 25 Sep 2012 15:36:34 +0100
In-Reply-To: <20577.49354.986341.321870@mariner.uk.xensource.com>
References: <20576.36587.698928.396214@mariner.uk.xensource.com>
	<1348579144.11229.6.camel@zakaz.uk.xensource.com>
	<20577.49354.986341.321870@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] docs: network diagrams for the wiki
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-09-25 at 15:33 +0100, Ian Jackson wrote:
> Ian Campbell writes ("Re: [Xen-devel] [PATCH] docs: network diagrams for the wiki"):
> > I think you've forgotten to "git add docs/figs/Makefile" ?
> 
> Oops.
> 
> From: Ian Jackson <ian.jackson@eu.citrix.com>
> Subject: [PATCH v2] docs: network diagrams for the wiki
> 
> We provide two new diagrams
>   docs/figs/network-{bridge,basic}.fig
> which are converted to pngs by the Makefiles and intended for
> consumption by http://wiki.xen.org/wiki/Xen_Networking.
> 
> This is perhaps not the ideal location for this source code but we
> don't have a better one.
> 
> Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>

I'm not totally convinced by this as a home for things referenced from
the wiki like this but lets try it:

Acked-by: Ian Campbell <ian.campbell@citrix.com>

> ---
> v2: add missing docs/figs/Makefile
> 
> ---
>  .gitignore                   |    1 +
>  .hgignore                    |    1 +
>  docs/Makefile                |    7 ++-
>  docs/figs/Makefile           |   15 +++++
>  docs/figs/network-basic.fig  |   73 ++++++++++++++++++++++++
>  docs/figs/network-bridge.fig |  125 ++++++++++++++++++++++++++++++++++++++++++
>  6 files changed, 221 insertions(+), 1 deletions(-)
> 
> diff --git a/.gitignore b/.gitignore
> index 776e4b2..022a7e8 100644
> --- a/.gitignore
> +++ b/.gitignore
> @@ -392,3 +392,4 @@ tools/xenstore/xenstore-watch
>  
>  docs/txt/misc/*.txt
>  docs/txt/man/*.txt
> +docs/figs/*.png
> diff --git a/.hgignore b/.hgignore
> index 141809e..5095722 100644
> --- a/.hgignore
> +++ b/.hgignore
> @@ -45,6 +45,7 @@
>  ^docs/interface/interface\.css$
>  ^docs/interface/interface\.html$
>  ^docs/interface/labels\.pl$
> +^docs/figs/.*\.png
>  ^docs/man1/
>  ^docs/man5/
>  ^docs/pdf/.*$
> diff --git a/docs/Makefile b/docs/Makefile
> index 007a5a9..8806990 100644
> --- a/docs/Makefile
> +++ b/docs/Makefile
> @@ -25,7 +25,7 @@ DOC_TXT         := $(patsubst %.txt,txt/%.txt,$(wildcard misc/*.txt)) \
>  all: build
>  
>  .PHONY: build
> -build: html txt man-pages
> +build: html txt man-pages figs
>  	@if which $(DOT) 1>/dev/null 2>/dev/null ; then              \
>  	$(MAKE) -C xen-api build ; else                              \
>          echo "Graphviz (dot) not installed; skipping xen-api." ; fi
> @@ -40,6 +40,10 @@ html: $(DOC_HTML) html/index.html
>  .PHONY: txt
>  txt: $(DOC_TXT)
>  
> +.PHONY: figs
> +figs:
> +	$(MAKE) -C figs
> +
>  .PHONY: python-dev-docs
>  python-dev-docs:
>  	@mkdir -v -p api/tools/python
> @@ -68,6 +72,7 @@ man5/%.5: man/%.pod.5 Makefile
>  .PHONY: clean
>  clean:
>  	$(MAKE) -C xen-api clean
> +	$(MAKE) -C figs clean
>  	rm -rf .word_count *.aux *.dvi *.bbl *.blg *.glo *.idx *~ 
>  	rm -rf *.ilg *.log *.ind *.toc *.bak core
>  	rm -rf html txt
> diff --git a/docs/figs/Makefile b/docs/figs/Makefile
> new file mode 100644
> index 0000000..5ecdae3
> --- /dev/null
> +++ b/docs/figs/Makefile
> @@ -0,0 +1,15 @@
> +
> +XEN_ROOT=$(CURDIR)/../..
> +include $(XEN_ROOT)/Config.mk
> +include $(XEN_ROOT)/docs/Docs.mk
> +
> +TARGETS= network-bridge.png network-basic.png
> +
> +all: $(TARGETS)
> +
> +%.png:	%.fig
> +	$(FIG2DEV) -L png $< >$@.tmp
> +	mv -f $@.tmp $@
> +
> +clean:
> +	rm -f *~ *.png
> diff --git a/docs/figs/network-basic.fig b/docs/figs/network-basic.fig
> new file mode 100644
> index 0000000..b343def
> --- /dev/null
> +++ b/docs/figs/network-basic.fig
> @@ -0,0 +1,73 @@
> +#FIG 3.2  Produced by xfig version 3.2.5b
> +Landscape
> +Center
> +Metric
> +A4      
> +100.00
> +Single
> +-2
> +1200 2
> +0 32 #c0c0c0
> +6 4275 5160 6105 6315
> +2 2 0 2 0 11 50 -1 28 0.000 0 0 7 0 0 5
> +	 6090 5175 4290 5175 4290 6075 6090 6075 6090 5175
> +2 2 0 2 0 11 50 -1 28 0.000 0 0 7 0 0 5
> +	 4965 6075 5865 6075 5865 6300 4965 6300 4965 6075
> +2 1 0 2 0 11 50 -1 28 0.000 0 0 7 0 0 4
> +	 6090 5400 5865 5400 5865 5625 6090 5625
> +-6
> +6 7170 5145 9000 6300
> +2 2 0 2 0 11 50 -1 28 0.000 0 0 7 0 0 5
> +	 7185 5160 8985 5160 8985 6060 7185 6060 7185 5160
> +2 2 0 2 0 11 50 -1 28 0.000 0 0 7 0 0 5
> +	 8310 6060 7410 6060 7410 6285 8310 6285 8310 6060
> +2 1 0 2 0 11 50 -1 28 0.000 0 0 7 0 0 4
> +	 7185 5385 7410 5385 7410 5610 7185 5610
> +-6
> +6 900 4050 9225 4950
> +4 0 0 50 -1 0 16 0.0000 4 195 1335 1170 4860 of the world\001
> +4 0 0 50 -1 0 16 0.0000 4 240 1815 1080 4590 interface, to rest\001
> +4 0 0 50 -1 0 16 0.0000 4 255 1890 990 4320 Physical network\001
> +4 0 0 50 -1 0 16 0.0000 4 255 1485 4050 4860 guest's traffic\001
> +4 0 0 50 -1 0 16 0.0000 4 195 1305 4050 4590 backend for\001
> +4 0 0 50 -1 0 16 0.0000 4 195 1905 3960 4320 Virtual interface:\001
> +4 0 0 50 -1 0 16 0.0000 4 195 1290 7515 4860 Xen drivers\001
> +4 0 0 50 -1 0 16 0.0000 4 255 1290 7425 4590 provided by\001
> +4 0 0 50 -1 0 16 0.0000 4 195 1905 7155 4320 Virtual interface:\001
> +-6
> +2 2 0 2 0 29 50 -1 20 0.000 0 0 7 0 0 5
> +	 660 5160 2460 5160 2460 6060 660 6060 660 5160
> +2 2 0 2 0 29 50 -1 20 0.000 0 0 7 0 0 5
> +	 1785 6060 885 6060 885 6285 1785 6285 1785 6060
> +2 1 0 2 0 29 50 -1 20 0.000 0 0 7 0 0 4
> +	 660 5385 885 5385 900 5625 675 5625
> +2 1 0 2 0 29 50 -1 -1 0.000 0 0 7 0 0 3
> +	 675 6300 675 4950 450 4950
> +2 1 0 3 1 29 50 -1 -1 0.000 0 0 7 0 0 2
> +	 6075 5490 7200 5490
> +2 1 0 3 4 29 50 -1 -1 0.000 0 0 -1 0 0 2
> +	 675 5490 0 5490
> +2 1 0 3 4 29 50 -1 -1 0.000 0 0 -1 0 0 2
> +	 0 2475 0 6525
> +2 2 0 1 0 32 100 -1 20 0.000 0 0 7 0 0 5
> +	 675 2250 9675 2250 9675 6750 675 6750 675 2250
> +2 2 0 1 0 7 70 -1 20 0.000 0 0 7 0 0 5
> +	 6300 2925 900 2925 900 6525 6300 6525 6300 2925
> +2 2 0 1 0 7 70 -1 20 0.000 0 0 7 0 0 5
> +	 6975 6525 9450 6525 9450 2925 6975 2925 6975 6525
> +2 2 0 1 7 7 125 -1 20 0.000 0 0 -1 0 0 5
> +	 -225 2025 9900 2025 9900 6975 -225 6975 -225 2025
> +4 0 0 50 -1 18 20 0.0000 4 240 735 1170 5490 ethN\001
> +4 0 0 50 -1 18 20 0.0000 4 240 945 4500 5490 vifA.B\001
> +4 0 0 50 -1 16 20 0.0000 4 315 1410 4500 5850 e.g. vif4.0\001
> +4 0 0 50 -1 16 20 0.0000 4 315 1260 1125 5850 e.g. eth0\001
> +4 0 0 50 -1 0 16 1.5708 4 255 1395 225 5400 physical link\001
> +4 0 0 50 -1 18 20 0.0000 4 240 735 7875 5490 ethB\001
> +4 0 0 50 -1 16 20 0.0000 4 315 1260 7650 5850 e.g. eth0\001
> +4 0 0 50 -1 0 20 0.0000 4 300 1995 1530 3870 typically dom0\001
> +4 0 0 50 -1 0 20 0.0000 4 285 3330 990 3420 Backend (driver) domain\001
> +4 0 0 50 -1 0 20 0.0000 4 300 1785 7155 3420 guest domain\001
> +4 0 0 50 -1 0 20 0.0000 4 300 1410 7155 3810 domU e.g.\001
> +4 0 0 50 -1 16 20 0.0000 4 240 810 8550 3825 dom4\001
> +4 0 0 50 -1 0 20 0.0000 4 300 1320 900 2700 Computer\001
> +4 0 0 50 -1 0 16 1.5708 4 195 1350 6750 6210 virtual   link\001
> diff --git a/docs/figs/network-bridge.fig b/docs/figs/network-bridge.fig
> new file mode 100644
> index 0000000..63c6ac4
> --- /dev/null
> +++ b/docs/figs/network-bridge.fig
> @@ -0,0 +1,125 @@
> +#FIG 3.2  Produced by xfig version 3.2.5b
> +Landscape
> +Center
> +Metric
> +A4      
> +100.00
> +Single
> +-2
> +1200 2
> +0 32 #ffc3ff
> +0 33 #c0c0c0
> +6 -225 3825 2475 8325
> +2 2 0 2 0 29 50 -1 20 0.000 0 0 7 0 0 5
> +	 660 6735 2460 6735 2460 7635 660 7635 660 6735
> +2 2 0 2 0 29 50 -1 20 0.000 0 0 7 0 0 5
> +	 1785 7635 885 7635 885 7860 1785 7860 1785 7635
> +2 1 0 2 0 29 50 -1 20 0.000 0 0 7 0 0 4
> +	 660 6960 885 6960 900 7200 675 7200
> +2 1 0 2 0 29 50 -1 -1 0.000 0 0 7 0 0 3
> +	 675 7875 675 6525 450 6525
> +2 1 0 3 4 29 50 -1 -1 0.000 0 0 -1 0 0 2
> +	 675 7065 0 7065
> +2 1 0 3 4 29 50 -1 -1 0.000 0 0 -1 0 0 2
> +	 0 4050 0 8100
> +4 0 0 50 -1 18 20 0.0000 4 240 675 1170 7065 eth0\001
> +-6
> +6 1936 4020 3149 5850
> +2 2 0 2 0 32 50 -1 19 0.000 0 0 7 0 0 5
> +	 1951 5835 1951 4035 2898 4035 2898 5835 1951 5835
> +2 2 0 2 0 32 50 -1 19 0.000 0 0 7 0 0 5
> +	 2898 4710 2898 5610 3134 5610 3134 4710 2898 4710
> +2 1 0 2 0 32 50 -1 19 0.000 0 0 7 0 0 4
> +	 2187 5835 2187 5610 2424 5610 2424 5835
> +-6
> +6 4275 5160 6105 6315
> +2 2 0 2 0 11 50 -1 28 0.000 0 0 7 0 0 5
> +	 6090 5175 4290 5175 4290 6075 6090 6075 6090 5175
> +2 2 0 2 0 11 50 -1 28 0.000 0 0 7 0 0 5
> +	 4965 6075 5865 6075 5865 6300 4965 6300 4965 6075
> +2 1 0 2 0 11 50 -1 28 0.000 0 0 7 0 0 4
> +	 6090 5400 5865 5400 5865 5625 6090 5625
> +-6
> +6 7170 5145 9000 6300
> +2 2 0 2 0 11 50 -1 28 0.000 0 0 7 0 0 5
> +	 7185 5160 8985 5160 8985 6060 7185 6060 7185 5160
> +2 2 0 2 0 11 50 -1 28 0.000 0 0 7 0 0 5
> +	 8310 6060 7410 6060 7410 6285 8310 6285 8310 6060
> +2 1 0 2 0 11 50 -1 28 0.000 0 0 7 0 0 4
> +	 7185 5385 7410 5385 7410 5610 7185 5610
> +-6
> +6 4275 7815 6105 8970
> +2 2 0 2 0 11 50 -1 28 0.000 0 0 7 0 0 5
> +	 6090 7830 4290 7830 4290 8730 6090 8730 6090 7830
> +2 2 0 2 0 11 50 -1 28 0.000 0 0 7 0 0 5
> +	 4965 8730 5865 8730 5865 8955 4965 8955 4965 8730
> +2 1 0 2 0 11 50 -1 28 0.000 0 0 7 0 0 4
> +	 6090 8055 5865 8055 5865 8280 6090 8280
> +-6
> +6 7170 7800 9000 8955
> +2 2 0 2 0 11 50 -1 28 0.000 0 0 7 0 0 5
> +	 7185 7815 8985 7815 8985 8715 7185 8715 7185 7815
> +2 2 0 2 0 11 50 -1 28 0.000 0 0 7 0 0 5
> +	 8310 8715 7410 8715 7410 8940 8310 8940 8310 8715
> +2 1 0 2 0 11 50 -1 28 0.000 0 0 7 0 0 4
> +	 7185 8040 7410 8040 7410 8265 7185 8265
> +-6
> +6 6975 6750 9450 9225
> +6 6975 6750 9450 9225
> +2 2 0 1 0 7 70 -1 20 0.000 0 0 7 0 0 5
> +	 6975 9225 9450 9225 9450 6750 6975 6750 6975 9225
> +4 0 0 50 -1 0 20 0.0000 4 270 705 7200 7200 guest\001
> +4 0 0 50 -1 16 20 0.0000 4 240 810 8100 7200 dom7\001
> +4 0 0 50 -1 16 20 0.0000 4 225 2070 7200 7650 198.51.100.32\001
> +-6
> +-6
> +2 1 0 3 1 29 50 -1 -1 0.000 0 0 -1 0 0 2
> +	 4275 5625 3375 5625
> +2 1 0 3 1 29 50 -1 -1 0.000 0 0 -1 0 0 2
> +	 4275 8325 3375 8325
> +2 1 0 3 1 29 50 -1 -1 0.000 0 0 -1 0 0 2
> +	 3375 7200 2475 7200
> +2 1 0 3 1 29 50 -1 -1 0.000 0 0 -1 0 0 2
> +	 3375 9000 3375 5220
> +2 1 0 3 1 29 50 -1 -1 0.000 0 0 -1 0 0 3
> +	 2250 5850 2250 6300 3375 6300
> +2 2 0 1 0 7 70 -1 20 0.000 0 0 7 0 0 5
> +	 6300 2925 900 2925 900 9450 6300 9450 6300 2925
> +2 2 0 1 0 33 100 -1 20 0.000 0 0 7 0 0 5
> +	 675 2250 9675 2250 9675 9675 675 9675 675 2250
> +2 2 0 1 7 7 125 -1 20 0.000 0 0 7 0 0 5
> +	 -225 9900 9900 9900 9900 2025 -225 2025 -225 9900
> +2 1 0 3 1 29 50 -1 -1 0.000 0 0 7 0 0 2
> +	 6075 5490 7200 5490
> +2 2 0 1 0 7 70 -1 20 0.000 0 0 7 0 0 5
> +	 6975 6525 9450 6525 9450 2925 6975 2925 6975 6525
> +2 1 0 3 1 29 50 -1 -1 0.000 0 0 7 0 0 2
> +	 6075 8145 7200 8145
> +2 2 0 1 0 7 70 -1 20 0.000 0 0 7 0 0 5
> +	 6975 6525 9450 6525 9450 5580 6975 5580 6975 6525
> +2 2 0 1 0 29 50 -1 -1 0.000 0 0 -1 0 0 5
> +	 1395 4230 5670 4230 5670 9180 1395 9180 1395 4230
> +4 0 0 50 -1 0 16 1.5708 4 255 1395 225 5400 physical link\001
> +4 0 0 50 -1 0 20 0.0000 4 300 1320 900 2700 Computer\001
> +4 0 0 50 -1 0 20 0.0000 4 285 3330 990 3420 Backend (driver) domain\001
> +4 0 0 50 -1 0 16 1.5708 4 195 1515 3690 7560 virtual switch\001
> +4 0 0 50 -1 16 20 0.0000 4 225 1890 1440 3960 198.51.100.1\001
> +4 0 0 50 -1 18 20 1.5708 4 240 1095 2250 5400 xenbr0\001
> +4 0 0 50 -1 0 16 1.5708 4 255 1185 2520 5490 O/S bridge\001
> +4 0 0 50 -1 0 16 1.5708 4 195 990 2790 5310 interface\001
> +4 0 0 50 -1 0 20 0.0000 4 300 840 4680 4590 bridge\001
> +4 0 0 50 -1 0 20 0.0000 4 225 1185 3330 4590 Software\001
> +4 0 0 50 -1 0 20 0.0000 4 300 1785 7155 3420 guest domain\001
> +4 0 0 50 -1 0 20 0.0000 4 300 1410 7155 3810 domU e.g.\001
> +4 0 0 50 -1 16 20 0.0000 4 240 810 8550 3825 dom4\001
> +4 0 0 50 -1 18 20 0.0000 4 240 825 4500 5490 vif4.0\001
> +4 0 0 50 -1 18 20 0.0000 4 240 675 7875 5490 eth0\001
> +4 0 0 50 -1 16 20 0.0000 4 225 2070 7200 4950 198.51.100.27\001
> +4 0 0 50 -1 0 16 0.0000 4 255 1080 4500 5850 (netback)\001
> +4 0 0 50 -1 0 16 0.0000 4 255 1140 7560 5850 (netfront)\001
> +4 0 0 50 -1 0 16 1.5708 4 195 1350 6750 6210 virtual   link\001
> +4 0 0 50 -1 0 16 0.0000 4 255 1080 4500 8505 (netback)\001
> +4 0 0 50 -1 0 16 0.0000 4 255 1140 7560 8505 (netfront)\001
> +4 0 0 50 -1 0 16 1.5708 4 195 1350 6750 8865 virtual   link\001
> +4 0 0 50 -1 18 20 0.0000 4 240 825 4500 8190 vif7.0\001
> +4 0 0 50 -1 18 20 0.0000 4 240 675 7830 8190 eth0\001



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 25 14:36:54 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 14:36: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 1TGWFb-0004Lv-Og; Tue, 25 Sep 2012 14:36: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 1TGWFZ-0004Lg-Lm
	for xen-devel@lists.xen.org; Tue, 25 Sep 2012 14:36:38 +0000
Received: from [85.158.143.35:34558] by server-3.bemta-4.messagelabs.com id
	74/F9-10986-471C1605; Tue, 25 Sep 2012 14:36:36 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1348583796!16264861!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTEwNzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4513 invoked from network); 25 Sep 2012 14:36:36 -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;
	25 Sep 2012 14:36:36 -0000
X-IronPort-AV: E=Sophos;i="4.80,483,1344211200"; d="scan'208";a="14753500"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Sep 2012 14:36: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.279.1;
	Tue, 25 Sep 2012 15:36:35 +0100
Message-ID: <1348583794.11229.28.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Tue, 25 Sep 2012 15:36:34 +0100
In-Reply-To: <20577.49354.986341.321870@mariner.uk.xensource.com>
References: <20576.36587.698928.396214@mariner.uk.xensource.com>
	<1348579144.11229.6.camel@zakaz.uk.xensource.com>
	<20577.49354.986341.321870@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] docs: network diagrams for the wiki
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-09-25 at 15:33 +0100, Ian Jackson wrote:
> Ian Campbell writes ("Re: [Xen-devel] [PATCH] docs: network diagrams for the wiki"):
> > I think you've forgotten to "git add docs/figs/Makefile" ?
> 
> Oops.
> 
> From: Ian Jackson <ian.jackson@eu.citrix.com>
> Subject: [PATCH v2] docs: network diagrams for the wiki
> 
> We provide two new diagrams
>   docs/figs/network-{bridge,basic}.fig
> which are converted to pngs by the Makefiles and intended for
> consumption by http://wiki.xen.org/wiki/Xen_Networking.
> 
> This is perhaps not the ideal location for this source code but we
> don't have a better one.
> 
> Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>

I'm not totally convinced by this as a home for things referenced from
the wiki like this but lets try it:

Acked-by: Ian Campbell <ian.campbell@citrix.com>

> ---
> v2: add missing docs/figs/Makefile
> 
> ---
>  .gitignore                   |    1 +
>  .hgignore                    |    1 +
>  docs/Makefile                |    7 ++-
>  docs/figs/Makefile           |   15 +++++
>  docs/figs/network-basic.fig  |   73 ++++++++++++++++++++++++
>  docs/figs/network-bridge.fig |  125 ++++++++++++++++++++++++++++++++++++++++++
>  6 files changed, 221 insertions(+), 1 deletions(-)
> 
> diff --git a/.gitignore b/.gitignore
> index 776e4b2..022a7e8 100644
> --- a/.gitignore
> +++ b/.gitignore
> @@ -392,3 +392,4 @@ tools/xenstore/xenstore-watch
>  
>  docs/txt/misc/*.txt
>  docs/txt/man/*.txt
> +docs/figs/*.png
> diff --git a/.hgignore b/.hgignore
> index 141809e..5095722 100644
> --- a/.hgignore
> +++ b/.hgignore
> @@ -45,6 +45,7 @@
>  ^docs/interface/interface\.css$
>  ^docs/interface/interface\.html$
>  ^docs/interface/labels\.pl$
> +^docs/figs/.*\.png
>  ^docs/man1/
>  ^docs/man5/
>  ^docs/pdf/.*$
> diff --git a/docs/Makefile b/docs/Makefile
> index 007a5a9..8806990 100644
> --- a/docs/Makefile
> +++ b/docs/Makefile
> @@ -25,7 +25,7 @@ DOC_TXT         := $(patsubst %.txt,txt/%.txt,$(wildcard misc/*.txt)) \
>  all: build
>  
>  .PHONY: build
> -build: html txt man-pages
> +build: html txt man-pages figs
>  	@if which $(DOT) 1>/dev/null 2>/dev/null ; then              \
>  	$(MAKE) -C xen-api build ; else                              \
>          echo "Graphviz (dot) not installed; skipping xen-api." ; fi
> @@ -40,6 +40,10 @@ html: $(DOC_HTML) html/index.html
>  .PHONY: txt
>  txt: $(DOC_TXT)
>  
> +.PHONY: figs
> +figs:
> +	$(MAKE) -C figs
> +
>  .PHONY: python-dev-docs
>  python-dev-docs:
>  	@mkdir -v -p api/tools/python
> @@ -68,6 +72,7 @@ man5/%.5: man/%.pod.5 Makefile
>  .PHONY: clean
>  clean:
>  	$(MAKE) -C xen-api clean
> +	$(MAKE) -C figs clean
>  	rm -rf .word_count *.aux *.dvi *.bbl *.blg *.glo *.idx *~ 
>  	rm -rf *.ilg *.log *.ind *.toc *.bak core
>  	rm -rf html txt
> diff --git a/docs/figs/Makefile b/docs/figs/Makefile
> new file mode 100644
> index 0000000..5ecdae3
> --- /dev/null
> +++ b/docs/figs/Makefile
> @@ -0,0 +1,15 @@
> +
> +XEN_ROOT=$(CURDIR)/../..
> +include $(XEN_ROOT)/Config.mk
> +include $(XEN_ROOT)/docs/Docs.mk
> +
> +TARGETS= network-bridge.png network-basic.png
> +
> +all: $(TARGETS)
> +
> +%.png:	%.fig
> +	$(FIG2DEV) -L png $< >$@.tmp
> +	mv -f $@.tmp $@
> +
> +clean:
> +	rm -f *~ *.png
> diff --git a/docs/figs/network-basic.fig b/docs/figs/network-basic.fig
> new file mode 100644
> index 0000000..b343def
> --- /dev/null
> +++ b/docs/figs/network-basic.fig
> @@ -0,0 +1,73 @@
> +#FIG 3.2  Produced by xfig version 3.2.5b
> +Landscape
> +Center
> +Metric
> +A4      
> +100.00
> +Single
> +-2
> +1200 2
> +0 32 #c0c0c0
> +6 4275 5160 6105 6315
> +2 2 0 2 0 11 50 -1 28 0.000 0 0 7 0 0 5
> +	 6090 5175 4290 5175 4290 6075 6090 6075 6090 5175
> +2 2 0 2 0 11 50 -1 28 0.000 0 0 7 0 0 5
> +	 4965 6075 5865 6075 5865 6300 4965 6300 4965 6075
> +2 1 0 2 0 11 50 -1 28 0.000 0 0 7 0 0 4
> +	 6090 5400 5865 5400 5865 5625 6090 5625
> +-6
> +6 7170 5145 9000 6300
> +2 2 0 2 0 11 50 -1 28 0.000 0 0 7 0 0 5
> +	 7185 5160 8985 5160 8985 6060 7185 6060 7185 5160
> +2 2 0 2 0 11 50 -1 28 0.000 0 0 7 0 0 5
> +	 8310 6060 7410 6060 7410 6285 8310 6285 8310 6060
> +2 1 0 2 0 11 50 -1 28 0.000 0 0 7 0 0 4
> +	 7185 5385 7410 5385 7410 5610 7185 5610
> +-6
> +6 900 4050 9225 4950
> +4 0 0 50 -1 0 16 0.0000 4 195 1335 1170 4860 of the world\001
> +4 0 0 50 -1 0 16 0.0000 4 240 1815 1080 4590 interface, to rest\001
> +4 0 0 50 -1 0 16 0.0000 4 255 1890 990 4320 Physical network\001
> +4 0 0 50 -1 0 16 0.0000 4 255 1485 4050 4860 guest's traffic\001
> +4 0 0 50 -1 0 16 0.0000 4 195 1305 4050 4590 backend for\001
> +4 0 0 50 -1 0 16 0.0000 4 195 1905 3960 4320 Virtual interface:\001
> +4 0 0 50 -1 0 16 0.0000 4 195 1290 7515 4860 Xen drivers\001
> +4 0 0 50 -1 0 16 0.0000 4 255 1290 7425 4590 provided by\001
> +4 0 0 50 -1 0 16 0.0000 4 195 1905 7155 4320 Virtual interface:\001
> +-6
> +2 2 0 2 0 29 50 -1 20 0.000 0 0 7 0 0 5
> +	 660 5160 2460 5160 2460 6060 660 6060 660 5160
> +2 2 0 2 0 29 50 -1 20 0.000 0 0 7 0 0 5
> +	 1785 6060 885 6060 885 6285 1785 6285 1785 6060
> +2 1 0 2 0 29 50 -1 20 0.000 0 0 7 0 0 4
> +	 660 5385 885 5385 900 5625 675 5625
> +2 1 0 2 0 29 50 -1 -1 0.000 0 0 7 0 0 3
> +	 675 6300 675 4950 450 4950
> +2 1 0 3 1 29 50 -1 -1 0.000 0 0 7 0 0 2
> +	 6075 5490 7200 5490
> +2 1 0 3 4 29 50 -1 -1 0.000 0 0 -1 0 0 2
> +	 675 5490 0 5490
> +2 1 0 3 4 29 50 -1 -1 0.000 0 0 -1 0 0 2
> +	 0 2475 0 6525
> +2 2 0 1 0 32 100 -1 20 0.000 0 0 7 0 0 5
> +	 675 2250 9675 2250 9675 6750 675 6750 675 2250
> +2 2 0 1 0 7 70 -1 20 0.000 0 0 7 0 0 5
> +	 6300 2925 900 2925 900 6525 6300 6525 6300 2925
> +2 2 0 1 0 7 70 -1 20 0.000 0 0 7 0 0 5
> +	 6975 6525 9450 6525 9450 2925 6975 2925 6975 6525
> +2 2 0 1 7 7 125 -1 20 0.000 0 0 -1 0 0 5
> +	 -225 2025 9900 2025 9900 6975 -225 6975 -225 2025
> +4 0 0 50 -1 18 20 0.0000 4 240 735 1170 5490 ethN\001
> +4 0 0 50 -1 18 20 0.0000 4 240 945 4500 5490 vifA.B\001
> +4 0 0 50 -1 16 20 0.0000 4 315 1410 4500 5850 e.g. vif4.0\001
> +4 0 0 50 -1 16 20 0.0000 4 315 1260 1125 5850 e.g. eth0\001
> +4 0 0 50 -1 0 16 1.5708 4 255 1395 225 5400 physical link\001
> +4 0 0 50 -1 18 20 0.0000 4 240 735 7875 5490 ethB\001
> +4 0 0 50 -1 16 20 0.0000 4 315 1260 7650 5850 e.g. eth0\001
> +4 0 0 50 -1 0 20 0.0000 4 300 1995 1530 3870 typically dom0\001
> +4 0 0 50 -1 0 20 0.0000 4 285 3330 990 3420 Backend (driver) domain\001
> +4 0 0 50 -1 0 20 0.0000 4 300 1785 7155 3420 guest domain\001
> +4 0 0 50 -1 0 20 0.0000 4 300 1410 7155 3810 domU e.g.\001
> +4 0 0 50 -1 16 20 0.0000 4 240 810 8550 3825 dom4\001
> +4 0 0 50 -1 0 20 0.0000 4 300 1320 900 2700 Computer\001
> +4 0 0 50 -1 0 16 1.5708 4 195 1350 6750 6210 virtual   link\001
> diff --git a/docs/figs/network-bridge.fig b/docs/figs/network-bridge.fig
> new file mode 100644
> index 0000000..63c6ac4
> --- /dev/null
> +++ b/docs/figs/network-bridge.fig
> @@ -0,0 +1,125 @@
> +#FIG 3.2  Produced by xfig version 3.2.5b
> +Landscape
> +Center
> +Metric
> +A4      
> +100.00
> +Single
> +-2
> +1200 2
> +0 32 #ffc3ff
> +0 33 #c0c0c0
> +6 -225 3825 2475 8325
> +2 2 0 2 0 29 50 -1 20 0.000 0 0 7 0 0 5
> +	 660 6735 2460 6735 2460 7635 660 7635 660 6735
> +2 2 0 2 0 29 50 -1 20 0.000 0 0 7 0 0 5
> +	 1785 7635 885 7635 885 7860 1785 7860 1785 7635
> +2 1 0 2 0 29 50 -1 20 0.000 0 0 7 0 0 4
> +	 660 6960 885 6960 900 7200 675 7200
> +2 1 0 2 0 29 50 -1 -1 0.000 0 0 7 0 0 3
> +	 675 7875 675 6525 450 6525
> +2 1 0 3 4 29 50 -1 -1 0.000 0 0 -1 0 0 2
> +	 675 7065 0 7065
> +2 1 0 3 4 29 50 -1 -1 0.000 0 0 -1 0 0 2
> +	 0 4050 0 8100
> +4 0 0 50 -1 18 20 0.0000 4 240 675 1170 7065 eth0\001
> +-6
> +6 1936 4020 3149 5850
> +2 2 0 2 0 32 50 -1 19 0.000 0 0 7 0 0 5
> +	 1951 5835 1951 4035 2898 4035 2898 5835 1951 5835
> +2 2 0 2 0 32 50 -1 19 0.000 0 0 7 0 0 5
> +	 2898 4710 2898 5610 3134 5610 3134 4710 2898 4710
> +2 1 0 2 0 32 50 -1 19 0.000 0 0 7 0 0 4
> +	 2187 5835 2187 5610 2424 5610 2424 5835
> +-6
> +6 4275 5160 6105 6315
> +2 2 0 2 0 11 50 -1 28 0.000 0 0 7 0 0 5
> +	 6090 5175 4290 5175 4290 6075 6090 6075 6090 5175
> +2 2 0 2 0 11 50 -1 28 0.000 0 0 7 0 0 5
> +	 4965 6075 5865 6075 5865 6300 4965 6300 4965 6075
> +2 1 0 2 0 11 50 -1 28 0.000 0 0 7 0 0 4
> +	 6090 5400 5865 5400 5865 5625 6090 5625
> +-6
> +6 7170 5145 9000 6300
> +2 2 0 2 0 11 50 -1 28 0.000 0 0 7 0 0 5
> +	 7185 5160 8985 5160 8985 6060 7185 6060 7185 5160
> +2 2 0 2 0 11 50 -1 28 0.000 0 0 7 0 0 5
> +	 8310 6060 7410 6060 7410 6285 8310 6285 8310 6060
> +2 1 0 2 0 11 50 -1 28 0.000 0 0 7 0 0 4
> +	 7185 5385 7410 5385 7410 5610 7185 5610
> +-6
> +6 4275 7815 6105 8970
> +2 2 0 2 0 11 50 -1 28 0.000 0 0 7 0 0 5
> +	 6090 7830 4290 7830 4290 8730 6090 8730 6090 7830
> +2 2 0 2 0 11 50 -1 28 0.000 0 0 7 0 0 5
> +	 4965 8730 5865 8730 5865 8955 4965 8955 4965 8730
> +2 1 0 2 0 11 50 -1 28 0.000 0 0 7 0 0 4
> +	 6090 8055 5865 8055 5865 8280 6090 8280
> +-6
> +6 7170 7800 9000 8955
> +2 2 0 2 0 11 50 -1 28 0.000 0 0 7 0 0 5
> +	 7185 7815 8985 7815 8985 8715 7185 8715 7185 7815
> +2 2 0 2 0 11 50 -1 28 0.000 0 0 7 0 0 5
> +	 8310 8715 7410 8715 7410 8940 8310 8940 8310 8715
> +2 1 0 2 0 11 50 -1 28 0.000 0 0 7 0 0 4
> +	 7185 8040 7410 8040 7410 8265 7185 8265
> +-6
> +6 6975 6750 9450 9225
> +6 6975 6750 9450 9225
> +2 2 0 1 0 7 70 -1 20 0.000 0 0 7 0 0 5
> +	 6975 9225 9450 9225 9450 6750 6975 6750 6975 9225
> +4 0 0 50 -1 0 20 0.0000 4 270 705 7200 7200 guest\001
> +4 0 0 50 -1 16 20 0.0000 4 240 810 8100 7200 dom7\001
> +4 0 0 50 -1 16 20 0.0000 4 225 2070 7200 7650 198.51.100.32\001
> +-6
> +-6
> +2 1 0 3 1 29 50 -1 -1 0.000 0 0 -1 0 0 2
> +	 4275 5625 3375 5625
> +2 1 0 3 1 29 50 -1 -1 0.000 0 0 -1 0 0 2
> +	 4275 8325 3375 8325
> +2 1 0 3 1 29 50 -1 -1 0.000 0 0 -1 0 0 2
> +	 3375 7200 2475 7200
> +2 1 0 3 1 29 50 -1 -1 0.000 0 0 -1 0 0 2
> +	 3375 9000 3375 5220
> +2 1 0 3 1 29 50 -1 -1 0.000 0 0 -1 0 0 3
> +	 2250 5850 2250 6300 3375 6300
> +2 2 0 1 0 7 70 -1 20 0.000 0 0 7 0 0 5
> +	 6300 2925 900 2925 900 9450 6300 9450 6300 2925
> +2 2 0 1 0 33 100 -1 20 0.000 0 0 7 0 0 5
> +	 675 2250 9675 2250 9675 9675 675 9675 675 2250
> +2 2 0 1 7 7 125 -1 20 0.000 0 0 7 0 0 5
> +	 -225 9900 9900 9900 9900 2025 -225 2025 -225 9900
> +2 1 0 3 1 29 50 -1 -1 0.000 0 0 7 0 0 2
> +	 6075 5490 7200 5490
> +2 2 0 1 0 7 70 -1 20 0.000 0 0 7 0 0 5
> +	 6975 6525 9450 6525 9450 2925 6975 2925 6975 6525
> +2 1 0 3 1 29 50 -1 -1 0.000 0 0 7 0 0 2
> +	 6075 8145 7200 8145
> +2 2 0 1 0 7 70 -1 20 0.000 0 0 7 0 0 5
> +	 6975 6525 9450 6525 9450 5580 6975 5580 6975 6525
> +2 2 0 1 0 29 50 -1 -1 0.000 0 0 -1 0 0 5
> +	 1395 4230 5670 4230 5670 9180 1395 9180 1395 4230
> +4 0 0 50 -1 0 16 1.5708 4 255 1395 225 5400 physical link\001
> +4 0 0 50 -1 0 20 0.0000 4 300 1320 900 2700 Computer\001
> +4 0 0 50 -1 0 20 0.0000 4 285 3330 990 3420 Backend (driver) domain\001
> +4 0 0 50 -1 0 16 1.5708 4 195 1515 3690 7560 virtual switch\001
> +4 0 0 50 -1 16 20 0.0000 4 225 1890 1440 3960 198.51.100.1\001
> +4 0 0 50 -1 18 20 1.5708 4 240 1095 2250 5400 xenbr0\001
> +4 0 0 50 -1 0 16 1.5708 4 255 1185 2520 5490 O/S bridge\001
> +4 0 0 50 -1 0 16 1.5708 4 195 990 2790 5310 interface\001
> +4 0 0 50 -1 0 20 0.0000 4 300 840 4680 4590 bridge\001
> +4 0 0 50 -1 0 20 0.0000 4 225 1185 3330 4590 Software\001
> +4 0 0 50 -1 0 20 0.0000 4 300 1785 7155 3420 guest domain\001
> +4 0 0 50 -1 0 20 0.0000 4 300 1410 7155 3810 domU e.g.\001
> +4 0 0 50 -1 16 20 0.0000 4 240 810 8550 3825 dom4\001
> +4 0 0 50 -1 18 20 0.0000 4 240 825 4500 5490 vif4.0\001
> +4 0 0 50 -1 18 20 0.0000 4 240 675 7875 5490 eth0\001
> +4 0 0 50 -1 16 20 0.0000 4 225 2070 7200 4950 198.51.100.27\001
> +4 0 0 50 -1 0 16 0.0000 4 255 1080 4500 5850 (netback)\001
> +4 0 0 50 -1 0 16 0.0000 4 255 1140 7560 5850 (netfront)\001
> +4 0 0 50 -1 0 16 1.5708 4 195 1350 6750 6210 virtual   link\001
> +4 0 0 50 -1 0 16 0.0000 4 255 1080 4500 8505 (netback)\001
> +4 0 0 50 -1 0 16 0.0000 4 255 1140 7560 8505 (netfront)\001
> +4 0 0 50 -1 0 16 1.5708 4 195 1350 6750 8865 virtual   link\001
> +4 0 0 50 -1 18 20 0.0000 4 240 825 4500 8190 vif7.0\001
> +4 0 0 50 -1 18 20 0.0000 4 240 675 7830 8190 eth0\001



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 25 14:46:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 14: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 1TGWOZ-0004bq-WD; Tue, 25 Sep 2012 14:45: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 1TGWOY-0004bl-9G
	for xen-devel@lists.xen.org; Tue, 25 Sep 2012 14:45:54 +0000
Received: from [85.158.139.211:27959] by server-15.bemta-5.messagelabs.com id
	71/D1-19430-1A3C1605; Tue, 25 Sep 2012 14:45:53 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-5.tower-206.messagelabs.com!1348584351!19865212!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNzczMzU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20545 invoked from network); 25 Sep 2012 14:45:52 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-5.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Sep 2012 14:45:52 -0000
X-IronPort-AV: E=Sophos;i="4.80,483,1344211200"; d="scan'208";a="209278459"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Sep 2012 14:45:50 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Tue, 25 Sep 2012 10:45:50 -0400
Received: from [10.80.3.61]	by ukmail1.uk.xensource.com with esmtp (Exim 4.69)
	(envelope-from <anthony.perard@citrix.com>)	id 1TGWOU-0007DW-8J;
	Tue, 25 Sep 2012 15:45:50 +0100
Message-ID: <5061C39E.3070904@citrix.com>
Date: Tue, 25 Sep 2012 15:45:50 +0100
From: Anthony PERARD <anthony.perard@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120910 Thunderbird/15.0.1
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <1347906148-9606-1-git-send-email-anthony.perard@citrix.com>
	<1347906148-9606-5-git-send-email-anthony.perard@citrix.com>
	<1348563254.3452.120.camel@zakaz.uk.xensource.com>
In-Reply-To: <1348563254.3452.120.camel@zakaz.uk.xensource.com>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Xen Devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH V2 4/9] libxl_qmp: Introduces helpers to
 create an argument list.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 09/25/2012 09:54 AM, Ian Campbell wrote:
> On Mon, 2012-09-17 at 19:22 +0100, Anthony PERARD wrote:
>> Those functions will be used to create a "list" of parameters that contain more
>> than just strings. This list is converted by qmp_send to a string to be sent to
>> QEMU.
>>
>> Those functions will be used in the next two patches, so right now there are
>> not compiled.
>>
>> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
>> ---
>>  tools/libxl/libxl_qmp.c | 53 +++++++++++++++++++++++++++++++++++++++++++++++++
>>  1 file changed, 53 insertions(+)
>>
>> diff --git a/tools/libxl/libxl_qmp.c b/tools/libxl/libxl_qmp.c
>> index 07a8bd5..1dd5c6c 100644
>> --- a/tools/libxl/libxl_qmp.c
>> +++ b/tools/libxl/libxl_qmp.c
>> @@ -623,6 +623,59 @@ static void qmp_free_handler(libxl__qmp_handler *qmp)
>>      free(qmp);
>>  }
>>  
>> +#if 0
>> +/*
>> + * QMP Parameters Helpers
>> + * Those functions does not use the gc, because of the internal usage of
>> + * flexarray that does not support it.
>> + * The allocated *param need to be free with libxl__json_object_free(gc, param)
>> + */
>> +static void qmp_parameters_common_add(libxl__gc *gc,
>> +                                      libxl__json_object **param,
>> +                                      const char *name,
>> +                                      libxl__json_object *obj)
>> +{
>> +    libxl__json_map_node *arg = NULL;
>> +
>> +    if (!*param) {
>> +        *param = libxl__json_object_alloc(NOGC, JSON_MAP);
>> +    }
>> +
>> +    arg = libxl__zalloc(NOGC, sizeof(*arg));
>> +
>> +    arg->map_key = libxl__strdup(NOGC, name);
>> +    arg->obj = obj;
>> +
>> +    flexarray_append((*param)->u.map, arg);
>> +}
>> +
>> +static void qmp_parameters_add_string(libxl__gc *gc,
>> +                                      libxl__json_object **param,
>> +                                      const char *name, const char *argument)
>> +{
>> +    libxl__json_object *obj;
>> +
>> +    obj = libxl__json_object_alloc(NOGC, JSON_STRING);
>> +    obj->u.string = libxl__strdup(NOGC, argument);
>> +
>> +    qmp_parameters_common_add(gc, param, name, obj);
>> +}
>> +
>> +static void qmp_parameters_add_bool(libxl__gc *gc,
>> +                                    libxl__json_object **param,
>> +                                    const char *name, bool b)
>> +{
>> +    libxl__json_object *obj;
>> +
>> +    obj = libxl__json_object_alloc(NOGC, JSON_TRUE);
> 
> This is pre-existing, but treating JSON_TRUE and JSON_FALSE as distinct
> node types and not specific values of the (currently non-existent)
> JSON_BOOL type is a bit odd.

It was to save a bit of memory, and I probably follow another example
when I wrote those JSON_{TRUE,FALSE}.

I'll add another patch to introduce JSON_BOOL and remove those separated
true/false.

> I noticed it because you don't use the b param here... 

:(.

>> +    qmp_parameters_common_add(gc, param, name, obj);
>> +}
>> +
>> +#define QMP_PARAMETERS_SPRINTF(gc, args, name, format, ...) \
>> +    qmp_parameters_add_string(gc, args, name, \
>> +                              libxl__sprintf(gc, format, __VA_ARGS__))
> 
> I think it would be valid, and in keeping with the similar GC_SPRINTFOO
> macros, to make gc and perhaps args required in the calling environment
> rather than passing them, if you wanted to.

Seams fair to have gc required in the caller but I think I'll keep args
as a parameter of the macro.

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 Tue Sep 25 14:46:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 14: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 1TGWOZ-0004bq-WD; Tue, 25 Sep 2012 14:45: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 1TGWOY-0004bl-9G
	for xen-devel@lists.xen.org; Tue, 25 Sep 2012 14:45:54 +0000
Received: from [85.158.139.211:27959] by server-15.bemta-5.messagelabs.com id
	71/D1-19430-1A3C1605; Tue, 25 Sep 2012 14:45:53 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-5.tower-206.messagelabs.com!1348584351!19865212!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNzczMzU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20545 invoked from network); 25 Sep 2012 14:45:52 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-5.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Sep 2012 14:45:52 -0000
X-IronPort-AV: E=Sophos;i="4.80,483,1344211200"; d="scan'208";a="209278459"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Sep 2012 14:45:50 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Tue, 25 Sep 2012 10:45:50 -0400
Received: from [10.80.3.61]	by ukmail1.uk.xensource.com with esmtp (Exim 4.69)
	(envelope-from <anthony.perard@citrix.com>)	id 1TGWOU-0007DW-8J;
	Tue, 25 Sep 2012 15:45:50 +0100
Message-ID: <5061C39E.3070904@citrix.com>
Date: Tue, 25 Sep 2012 15:45:50 +0100
From: Anthony PERARD <anthony.perard@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120910 Thunderbird/15.0.1
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <1347906148-9606-1-git-send-email-anthony.perard@citrix.com>
	<1347906148-9606-5-git-send-email-anthony.perard@citrix.com>
	<1348563254.3452.120.camel@zakaz.uk.xensource.com>
In-Reply-To: <1348563254.3452.120.camel@zakaz.uk.xensource.com>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Xen Devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH V2 4/9] libxl_qmp: Introduces helpers to
 create an argument list.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 09/25/2012 09:54 AM, Ian Campbell wrote:
> On Mon, 2012-09-17 at 19:22 +0100, Anthony PERARD wrote:
>> Those functions will be used to create a "list" of parameters that contain more
>> than just strings. This list is converted by qmp_send to a string to be sent to
>> QEMU.
>>
>> Those functions will be used in the next two patches, so right now there are
>> not compiled.
>>
>> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
>> ---
>>  tools/libxl/libxl_qmp.c | 53 +++++++++++++++++++++++++++++++++++++++++++++++++
>>  1 file changed, 53 insertions(+)
>>
>> diff --git a/tools/libxl/libxl_qmp.c b/tools/libxl/libxl_qmp.c
>> index 07a8bd5..1dd5c6c 100644
>> --- a/tools/libxl/libxl_qmp.c
>> +++ b/tools/libxl/libxl_qmp.c
>> @@ -623,6 +623,59 @@ static void qmp_free_handler(libxl__qmp_handler *qmp)
>>      free(qmp);
>>  }
>>  
>> +#if 0
>> +/*
>> + * QMP Parameters Helpers
>> + * Those functions does not use the gc, because of the internal usage of
>> + * flexarray that does not support it.
>> + * The allocated *param need to be free with libxl__json_object_free(gc, param)
>> + */
>> +static void qmp_parameters_common_add(libxl__gc *gc,
>> +                                      libxl__json_object **param,
>> +                                      const char *name,
>> +                                      libxl__json_object *obj)
>> +{
>> +    libxl__json_map_node *arg = NULL;
>> +
>> +    if (!*param) {
>> +        *param = libxl__json_object_alloc(NOGC, JSON_MAP);
>> +    }
>> +
>> +    arg = libxl__zalloc(NOGC, sizeof(*arg));
>> +
>> +    arg->map_key = libxl__strdup(NOGC, name);
>> +    arg->obj = obj;
>> +
>> +    flexarray_append((*param)->u.map, arg);
>> +}
>> +
>> +static void qmp_parameters_add_string(libxl__gc *gc,
>> +                                      libxl__json_object **param,
>> +                                      const char *name, const char *argument)
>> +{
>> +    libxl__json_object *obj;
>> +
>> +    obj = libxl__json_object_alloc(NOGC, JSON_STRING);
>> +    obj->u.string = libxl__strdup(NOGC, argument);
>> +
>> +    qmp_parameters_common_add(gc, param, name, obj);
>> +}
>> +
>> +static void qmp_parameters_add_bool(libxl__gc *gc,
>> +                                    libxl__json_object **param,
>> +                                    const char *name, bool b)
>> +{
>> +    libxl__json_object *obj;
>> +
>> +    obj = libxl__json_object_alloc(NOGC, JSON_TRUE);
> 
> This is pre-existing, but treating JSON_TRUE and JSON_FALSE as distinct
> node types and not specific values of the (currently non-existent)
> JSON_BOOL type is a bit odd.

It was to save a bit of memory, and I probably follow another example
when I wrote those JSON_{TRUE,FALSE}.

I'll add another patch to introduce JSON_BOOL and remove those separated
true/false.

> I noticed it because you don't use the b param here... 

:(.

>> +    qmp_parameters_common_add(gc, param, name, obj);
>> +}
>> +
>> +#define QMP_PARAMETERS_SPRINTF(gc, args, name, format, ...) \
>> +    qmp_parameters_add_string(gc, args, name, \
>> +                              libxl__sprintf(gc, format, __VA_ARGS__))
> 
> I think it would be valid, and in keeping with the similar GC_SPRINTFOO
> macros, to make gc and perhaps args required in the calling environment
> rather than passing them, if you wanted to.

Seams fair to have gc required in the caller but I think I'll keep args
as a parameter of the macro.

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 Tue Sep 25 14:48:17 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 14:48: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 1TGWQc-0004hL-Gw; Tue, 25 Sep 2012 14:48:02 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jmarcet@gmail.com>) id 1TGWQa-0004h8-Js
	for xen-devel@lists.xen.org; Tue, 25 Sep 2012 14:48:00 +0000
X-Env-Sender: jmarcet@gmail.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1348584472!7146091!1
X-Originating-IP: [209.85.214.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-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13313 invoked from network); 25 Sep 2012 14:47:54 -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;
	25 Sep 2012 14:47:54 -0000
Received: by obbta14 with SMTP id ta14so8628740obb.32
	for <xen-devel@lists.xen.org>; Tue, 25 Sep 2012 07:47:52 -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=Tkz17wnBdHj5vdCOJd041l5VpWoLcheY2l6hz8lts3g=;
	b=o8VVuON3mX6Bxzfq5DtKxWtTURRm0tiWau/wC4yZPL4r1YEwUoCnqFFddyddMvvgcA
	h5LAbORd1WqGlFguvU1jmbiu52Uzbd8iHAtK6oNLoqKHGah3JDeH4tsMJxxfgMYliwYd
	43hrSETX3iJYFaDVbCL7hW3j6MbIVR+FzDzxA1tWw2lzm/K7GXaahY1SkBxzmOu2VLIm
	9v/qZ+LUNis3vVWpnEdKCj8PtJ7WNwswq6n7ZfUM0ZskT+vL0dHEKVAtmbTW/oIIVf/V
	qfQt6tptQwVRTlRyBr63XUlKUxhJa902JSxfLczQXq55QJoc+gCfDVRop9lMUQ2vj1bP
	dmfQ==
Received: by 10.60.169.148 with SMTP id ae20mr8629988oec.53.1348584472581;
	Tue, 25 Sep 2012 07:47:52 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.60.138.225 with HTTP; Tue, 25 Sep 2012 07:47:32 -0700 (PDT)
In-Reply-To: <20120925140611.GB16478@phenom.dumpdata.com>
References: <CC8273A0.4C9DD%keir@xen.org>
	<50605E9A020000780009D486@nat28.tlf.novell.com>
	<CAOvdn6XmB6rj3_QVU+59V8p24Y5G47AWxVEM=id02JWXkuhibQ@mail.gmail.com>
	<5060640B020000780009D4D2@nat28.tlf.novell.com>
	<CAOvdn6XLy8zR2rb2MEyi2aT9LQiFvFLY_H02p181mTsVLVTZkw@mail.gmail.com>
	<20120924122203.GG8912@reaktio.net>
	<CAOvdn6XV4eoA-FfFns1xhx7HCUqXc7KHxZwyKuT4FHG8s3R5RQ@mail.gmail.com>
	<CAAnFQG9PLQjdh6Ab6=Y5ZGM1s4nGdLekKU=pcKNMxt4rmt_RKA@mail.gmail.com>
	<20120924140411.GH31618@phenom.dumpdata.com>
	<CAAnFQG-tjv5UyF6j-TNHNgme2c4vA0Zxy8AdCiJEVsf2Z0quNA@mail.gmail.com>
	<20120925140611.GB16478@phenom.dumpdata.com>
From: Javier Marcet <jmarcet@gmail.com>
Date: Tue, 25 Sep 2012 16:47:32 +0200
Message-ID: <CAAnFQG88ApxKuscXx53Lt2qOyCe0ws6oXSSqBDfW0+oYo5Y3nA@mail.gmail.com>
To: Konrad Rzeszutek Wilk <konrad@kernel.org>
Cc: Keir Fraser <keir@xen.org>, john.baboval@citrix.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	xen-devel <xen-devel@lists.xen.org>, Ben Guthro <ben@guthro.net>,
	Jan Beulich <JBeulich@suse.com>, Thomas Goetz <thomas.goetz@citrix.com>
Subject: Re: [Xen-devel] Xen4.2 S3 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 Tue, Sep 25, 2012 at 4:06 PM, Konrad Rzeszutek Wilk
<konrad@kernel.org> wrote:

>> >> >> xen-acpi-processor driver was merged to upstream Linux kernel v3.4.
>> >> >>
>> >> >
>> >> > I see - so the advanced methods are not being used then
>> >
>> > You mean with the v3.5 kernel? I would think they would be used..
>> >
>> >> > This same kernel does work with Xen-4.0.x though. Is there an assumption in
>> >> > the code that ties Xen-4.2 to a newer kernel?
>> >>
>> >> I'm being bitten by this bug with a 3.5 kernel and Xen 4.2
>> >
>> > Huh? How so?
>>
>> I've tried adding a wbinvd() call before the halts in
>> xen/arch/x86/domain.c:default_idle and I could do full suspend and
>> resume cycle once, but a reboot later I couldn't resume anymore. Here
>
> Did you use the patch that Jan posted?
>> is the trace I get:
>
> That is a different issue. That is the kernel, while the outstanding
> issue in regards to suspend/resume is in the hypervisor.
>>
>> [  142.322778] ACPI: Preparing to enter system sleep state S3
>> [  142.723286] PM: Saving platform NVS memory
>> [  142.736453] Disabling non-boot CPUs ...
>> [  142.851387] ------------[ cut here ]------------
>> [  142.851397] WARNING: at
>> /home/storage/src/ubuntu-precise/kernel/rcutree.c:1550
>> rcu_do_batch.isra.41+0x5f/0x213()
>
>
> which ought to be fixed, but lets concentrate on one thing at a time.
> If you use the patch that Jan posted, does it work? And I presume
> you also have the two out-of-tree patches to make resume work in the
> dom0?

I haven't been able to see the actual patch, I only read a description
of what it should do. Two possible places where a wbinvd() call should
be added. On the first of these two places there were already calls to
wbinvd() just before the halts. I added it to the other one, within
xen/arch/x86/domain.c:default_idle and I could complete a
suspend/resume cycle without the back trace but after rebooting I
tried it again and it failed, more than once.

I do have the other two out-of-tree patches applied, otherwise it
would break way before than now.

>> [  142.851401] Hardware name: To Be Filled By O.E.M.
>> [  142.851404] Modules linked in: blktap(O) ip6table_filter ip6_tables
>> ipt_MASQUERADE iptable_nat nf_nat nf_conntrack_ipv4 nf_defrag_ipv4
>> xt_state nf_conntrack ipt_REJECT xt_CHECKSUM iptable_mangle xt_tcpudp
>> iptable_filter ip_tables x_tables [last unloaded: cx25840]
>> [  142.851466] Pid: 32, comm: migration/7 Tainted: G           O
>> 3.5.0-14-i7 #18~precise1
>> [  142.851469] Call Trace:
>> [  142.851473]  <IRQ>  [<ffffffff8106a9bd>] warn_slowpath_common+0x7e/0x96
>> [  142.851488]  [<ffffffff8106a9ea>] warn_slowpath_null+0x15/0x17
>> [  142.851496]  [<ffffffff810c6e87>] rcu_do_batch.isra.41+0x5f/0x213
>> [  142.851504]  [<ffffffff810c687f>] ?
>> check_for_new_grace_period.isra.35+0x38/0x44
>> [  142.851512]  [<ffffffff810c7101>] __rcu_process_callbacks+0xc6/0xee
>> [  142.851520]  [<ffffffff810c7149>] rcu_process_callbacks+0x20/0x3e
>> [  142.851527]  [<ffffffff81070c27>] __do_softirq+0x87/0x113
>> [  142.851536]  [<ffffffff812e7b22>] ? __xen_evtchn_do_upcall+0x1a0/0x1dd
>> [  142.851546]  [<ffffffff8162f05c>] call_softirq+0x1c/0x30
>> [  142.851557]  [<ffffffff810343a3>] do_softirq+0x41/0x7e
>> [  142.851566]  [<ffffffff81070e66>] irq_exit+0x3f/0x9a
>> [  142.851573]  [<ffffffff812e95c9>] xen_evtchn_do_upcall+0x2c/0x39
>> [  142.851580]  [<ffffffff8162f0ae>] xen_do_hypervisor_callback+0x1e/0x30
>> [  142.851588]  <EOI>  [<ffffffff8100122a>] ? hypercall_page+0x22a/0x1000
>> [  142.851601]  [<ffffffff8100122a>] ? hypercall_page+0x22a/0x1000
>> [  142.851609]  [<ffffffff8102eee9>] ? xen_force_evtchn_callback+0xd/0xf
>> [  142.851618]  [<ffffffff8102f552>] ? check_events+0x12/0x20
>> [  142.851627]  [<ffffffff8102f53f>] ? xen_restore_fl_direct_reloc+0x4/0x4
>> [  142.851635]  [<ffffffff810b6ff4>] ? arch_local_irq_restore+0xb/0xd
>> [  142.851644]  [<ffffffff810b73f4>] ? stop_machine_cpu_stop+0xc1/0xd3
>> [  142.851652]  [<ffffffff810b7333>] ? queue_stop_cpus_work+0xb5/0xb5
>> [  142.851660]  [<ffffffff810b7152>] ? cpu_stopper_thread+0xf7/0x187
>> [  142.851667]  [<ffffffff8108a927>] ? finish_task_switch+0x82/0xc1
>> [  142.851676]  [<ffffffff8162c50b>] ? __schedule+0x428/0x454
>> [  142.851685]  [<ffffffff8162cff0>] ? _raw_spin_unlock_irqrestore+0x15/0x18
>> [  142.851693]  [<ffffffff810b705b>] ? cpu_stop_signal_done+0x30/0x30
>> [  142.851701]  [<ffffffff81082627>] ? kthread+0x86/0x8e
>> [  142.851710]  [<ffffffff8162ef64>] ? kernel_thread_helper+0x4/0x10
>> [  142.851718]  [<ffffffff8162d338>] ? retint_restore_args+0x5/0x6
>> [  142.851726]  [<ffffffff8162ef60>] ? gs_change+0x13/0x13
>> [  142.851736] ---[ end trace 3722a99bcc5ae37a ]---
>> [  144.257229] ACPI: Low-level resume complete
>> [  144.257322] PM: Restoring platform NVS memory


-- 
Javier Marcet <jmarcet@gmail.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 25 14:48:17 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 14:48: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 1TGWQc-0004hL-Gw; Tue, 25 Sep 2012 14:48:02 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jmarcet@gmail.com>) id 1TGWQa-0004h8-Js
	for xen-devel@lists.xen.org; Tue, 25 Sep 2012 14:48:00 +0000
X-Env-Sender: jmarcet@gmail.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1348584472!7146091!1
X-Originating-IP: [209.85.214.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-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13313 invoked from network); 25 Sep 2012 14:47:54 -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;
	25 Sep 2012 14:47:54 -0000
Received: by obbta14 with SMTP id ta14so8628740obb.32
	for <xen-devel@lists.xen.org>; Tue, 25 Sep 2012 07:47:52 -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=Tkz17wnBdHj5vdCOJd041l5VpWoLcheY2l6hz8lts3g=;
	b=o8VVuON3mX6Bxzfq5DtKxWtTURRm0tiWau/wC4yZPL4r1YEwUoCnqFFddyddMvvgcA
	h5LAbORd1WqGlFguvU1jmbiu52Uzbd8iHAtK6oNLoqKHGah3JDeH4tsMJxxfgMYliwYd
	43hrSETX3iJYFaDVbCL7hW3j6MbIVR+FzDzxA1tWw2lzm/K7GXaahY1SkBxzmOu2VLIm
	9v/qZ+LUNis3vVWpnEdKCj8PtJ7WNwswq6n7ZfUM0ZskT+vL0dHEKVAtmbTW/oIIVf/V
	qfQt6tptQwVRTlRyBr63XUlKUxhJa902JSxfLczQXq55QJoc+gCfDVRop9lMUQ2vj1bP
	dmfQ==
Received: by 10.60.169.148 with SMTP id ae20mr8629988oec.53.1348584472581;
	Tue, 25 Sep 2012 07:47:52 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.60.138.225 with HTTP; Tue, 25 Sep 2012 07:47:32 -0700 (PDT)
In-Reply-To: <20120925140611.GB16478@phenom.dumpdata.com>
References: <CC8273A0.4C9DD%keir@xen.org>
	<50605E9A020000780009D486@nat28.tlf.novell.com>
	<CAOvdn6XmB6rj3_QVU+59V8p24Y5G47AWxVEM=id02JWXkuhibQ@mail.gmail.com>
	<5060640B020000780009D4D2@nat28.tlf.novell.com>
	<CAOvdn6XLy8zR2rb2MEyi2aT9LQiFvFLY_H02p181mTsVLVTZkw@mail.gmail.com>
	<20120924122203.GG8912@reaktio.net>
	<CAOvdn6XV4eoA-FfFns1xhx7HCUqXc7KHxZwyKuT4FHG8s3R5RQ@mail.gmail.com>
	<CAAnFQG9PLQjdh6Ab6=Y5ZGM1s4nGdLekKU=pcKNMxt4rmt_RKA@mail.gmail.com>
	<20120924140411.GH31618@phenom.dumpdata.com>
	<CAAnFQG-tjv5UyF6j-TNHNgme2c4vA0Zxy8AdCiJEVsf2Z0quNA@mail.gmail.com>
	<20120925140611.GB16478@phenom.dumpdata.com>
From: Javier Marcet <jmarcet@gmail.com>
Date: Tue, 25 Sep 2012 16:47:32 +0200
Message-ID: <CAAnFQG88ApxKuscXx53Lt2qOyCe0ws6oXSSqBDfW0+oYo5Y3nA@mail.gmail.com>
To: Konrad Rzeszutek Wilk <konrad@kernel.org>
Cc: Keir Fraser <keir@xen.org>, john.baboval@citrix.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	xen-devel <xen-devel@lists.xen.org>, Ben Guthro <ben@guthro.net>,
	Jan Beulich <JBeulich@suse.com>, Thomas Goetz <thomas.goetz@citrix.com>
Subject: Re: [Xen-devel] Xen4.2 S3 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 Tue, Sep 25, 2012 at 4:06 PM, Konrad Rzeszutek Wilk
<konrad@kernel.org> wrote:

>> >> >> xen-acpi-processor driver was merged to upstream Linux kernel v3.4.
>> >> >>
>> >> >
>> >> > I see - so the advanced methods are not being used then
>> >
>> > You mean with the v3.5 kernel? I would think they would be used..
>> >
>> >> > This same kernel does work with Xen-4.0.x though. Is there an assumption in
>> >> > the code that ties Xen-4.2 to a newer kernel?
>> >>
>> >> I'm being bitten by this bug with a 3.5 kernel and Xen 4.2
>> >
>> > Huh? How so?
>>
>> I've tried adding a wbinvd() call before the halts in
>> xen/arch/x86/domain.c:default_idle and I could do full suspend and
>> resume cycle once, but a reboot later I couldn't resume anymore. Here
>
> Did you use the patch that Jan posted?
>> is the trace I get:
>
> That is a different issue. That is the kernel, while the outstanding
> issue in regards to suspend/resume is in the hypervisor.
>>
>> [  142.322778] ACPI: Preparing to enter system sleep state S3
>> [  142.723286] PM: Saving platform NVS memory
>> [  142.736453] Disabling non-boot CPUs ...
>> [  142.851387] ------------[ cut here ]------------
>> [  142.851397] WARNING: at
>> /home/storage/src/ubuntu-precise/kernel/rcutree.c:1550
>> rcu_do_batch.isra.41+0x5f/0x213()
>
>
> which ought to be fixed, but lets concentrate on one thing at a time.
> If you use the patch that Jan posted, does it work? And I presume
> you also have the two out-of-tree patches to make resume work in the
> dom0?

I haven't been able to see the actual patch, I only read a description
of what it should do. Two possible places where a wbinvd() call should
be added. On the first of these two places there were already calls to
wbinvd() just before the halts. I added it to the other one, within
xen/arch/x86/domain.c:default_idle and I could complete a
suspend/resume cycle without the back trace but after rebooting I
tried it again and it failed, more than once.

I do have the other two out-of-tree patches applied, otherwise it
would break way before than now.

>> [  142.851401] Hardware name: To Be Filled By O.E.M.
>> [  142.851404] Modules linked in: blktap(O) ip6table_filter ip6_tables
>> ipt_MASQUERADE iptable_nat nf_nat nf_conntrack_ipv4 nf_defrag_ipv4
>> xt_state nf_conntrack ipt_REJECT xt_CHECKSUM iptable_mangle xt_tcpudp
>> iptable_filter ip_tables x_tables [last unloaded: cx25840]
>> [  142.851466] Pid: 32, comm: migration/7 Tainted: G           O
>> 3.5.0-14-i7 #18~precise1
>> [  142.851469] Call Trace:
>> [  142.851473]  <IRQ>  [<ffffffff8106a9bd>] warn_slowpath_common+0x7e/0x96
>> [  142.851488]  [<ffffffff8106a9ea>] warn_slowpath_null+0x15/0x17
>> [  142.851496]  [<ffffffff810c6e87>] rcu_do_batch.isra.41+0x5f/0x213
>> [  142.851504]  [<ffffffff810c687f>] ?
>> check_for_new_grace_period.isra.35+0x38/0x44
>> [  142.851512]  [<ffffffff810c7101>] __rcu_process_callbacks+0xc6/0xee
>> [  142.851520]  [<ffffffff810c7149>] rcu_process_callbacks+0x20/0x3e
>> [  142.851527]  [<ffffffff81070c27>] __do_softirq+0x87/0x113
>> [  142.851536]  [<ffffffff812e7b22>] ? __xen_evtchn_do_upcall+0x1a0/0x1dd
>> [  142.851546]  [<ffffffff8162f05c>] call_softirq+0x1c/0x30
>> [  142.851557]  [<ffffffff810343a3>] do_softirq+0x41/0x7e
>> [  142.851566]  [<ffffffff81070e66>] irq_exit+0x3f/0x9a
>> [  142.851573]  [<ffffffff812e95c9>] xen_evtchn_do_upcall+0x2c/0x39
>> [  142.851580]  [<ffffffff8162f0ae>] xen_do_hypervisor_callback+0x1e/0x30
>> [  142.851588]  <EOI>  [<ffffffff8100122a>] ? hypercall_page+0x22a/0x1000
>> [  142.851601]  [<ffffffff8100122a>] ? hypercall_page+0x22a/0x1000
>> [  142.851609]  [<ffffffff8102eee9>] ? xen_force_evtchn_callback+0xd/0xf
>> [  142.851618]  [<ffffffff8102f552>] ? check_events+0x12/0x20
>> [  142.851627]  [<ffffffff8102f53f>] ? xen_restore_fl_direct_reloc+0x4/0x4
>> [  142.851635]  [<ffffffff810b6ff4>] ? arch_local_irq_restore+0xb/0xd
>> [  142.851644]  [<ffffffff810b73f4>] ? stop_machine_cpu_stop+0xc1/0xd3
>> [  142.851652]  [<ffffffff810b7333>] ? queue_stop_cpus_work+0xb5/0xb5
>> [  142.851660]  [<ffffffff810b7152>] ? cpu_stopper_thread+0xf7/0x187
>> [  142.851667]  [<ffffffff8108a927>] ? finish_task_switch+0x82/0xc1
>> [  142.851676]  [<ffffffff8162c50b>] ? __schedule+0x428/0x454
>> [  142.851685]  [<ffffffff8162cff0>] ? _raw_spin_unlock_irqrestore+0x15/0x18
>> [  142.851693]  [<ffffffff810b705b>] ? cpu_stop_signal_done+0x30/0x30
>> [  142.851701]  [<ffffffff81082627>] ? kthread+0x86/0x8e
>> [  142.851710]  [<ffffffff8162ef64>] ? kernel_thread_helper+0x4/0x10
>> [  142.851718]  [<ffffffff8162d338>] ? retint_restore_args+0x5/0x6
>> [  142.851726]  [<ffffffff8162ef60>] ? gs_change+0x13/0x13
>> [  142.851736] ---[ end trace 3722a99bcc5ae37a ]---
>> [  144.257229] ACPI: Low-level resume complete
>> [  144.257322] PM: Restoring platform NVS memory


-- 
Javier Marcet <jmarcet@gmail.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 25 14:51:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 14: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 1TGWTi-0004u7-3m; Tue, 25 Sep 2012 14:51:14 +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 1TGWTg-0004tw-Fn
	for xen-devel@lists.xen.org; Tue, 25 Sep 2012 14:51:12 +0000
Received: from [85.158.143.99:5707] by server-2.bemta-4.messagelabs.com id
	2D/42-06610-FD4C1605; Tue, 25 Sep 2012 14:51:11 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1348584669!25296894!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNzczMzU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7783 invoked from network); 25 Sep 2012 14:51:10 -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;
	25 Sep 2012 14:51:10 -0000
X-IronPort-AV: E=Sophos;i="4.80,483,1344211200"; d="scan'208";a="209279298"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Sep 2012 14:51:08 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Tue, 25 Sep 2012 10:51:08 -0400
Received: from [10.80.3.61]	by ukmail1.uk.xensource.com with esmtp (Exim 4.69)
	(envelope-from <anthony.perard@citrix.com>)	id 1TGWTc-0007Ij-D2;
	Tue, 25 Sep 2012 15:51:08 +0100
Message-ID: <5061C4DC.4010900@citrix.com>
Date: Tue, 25 Sep 2012 15:51:08 +0100
From: Anthony PERARD <anthony.perard@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120910 Thunderbird/15.0.1
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <1347906148-9606-1-git-send-email-anthony.perard@citrix.com>
	<1347906148-9606-8-git-send-email-anthony.perard@citrix.com>
	<1348564001.3452.127.camel@zakaz.uk.xensource.com>
	<1348564200.3452.128.camel@zakaz.uk.xensource.com>
In-Reply-To: <1348564200.3452.128.camel@zakaz.uk.xensource.com>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Xen Devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH V2 7/9] libxl_qmp: Introduce
	libxl__qmp_set_global_dirty_log.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 09/25/2012 10:10 AM, Ian Campbell wrote:
> On Tue, 2012-09-25 at 10:06 +0100, Ian Campbell wrote:
>>> +    rc = qmp_run_command(gc, domid, "xen-set-global-dirty-log", args,
>>> +                         NULL, NULL);
> 
> For got to ask: Is this new function upstream and in our branch already?

No, the patches haven't been accepted yet.

> I suppose there is no ordering constraint since we fail now, and if we
> take this patch we'll just fail more explicitly with an ENOSYS type
> error unless/until the qemu half is in place.

Yep, patches can be apply in any order. If QEMU does not know the
command, then it will return an error, and it will be relayed by libxl.


-- 
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 Sep 25 14:51:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 14: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 1TGWTi-0004u7-3m; Tue, 25 Sep 2012 14:51:14 +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 1TGWTg-0004tw-Fn
	for xen-devel@lists.xen.org; Tue, 25 Sep 2012 14:51:12 +0000
Received: from [85.158.143.99:5707] by server-2.bemta-4.messagelabs.com id
	2D/42-06610-FD4C1605; Tue, 25 Sep 2012 14:51:11 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1348584669!25296894!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNzczMzU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7783 invoked from network); 25 Sep 2012 14:51:10 -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;
	25 Sep 2012 14:51:10 -0000
X-IronPort-AV: E=Sophos;i="4.80,483,1344211200"; d="scan'208";a="209279298"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Sep 2012 14:51:08 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Tue, 25 Sep 2012 10:51:08 -0400
Received: from [10.80.3.61]	by ukmail1.uk.xensource.com with esmtp (Exim 4.69)
	(envelope-from <anthony.perard@citrix.com>)	id 1TGWTc-0007Ij-D2;
	Tue, 25 Sep 2012 15:51:08 +0100
Message-ID: <5061C4DC.4010900@citrix.com>
Date: Tue, 25 Sep 2012 15:51:08 +0100
From: Anthony PERARD <anthony.perard@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120910 Thunderbird/15.0.1
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <1347906148-9606-1-git-send-email-anthony.perard@citrix.com>
	<1347906148-9606-8-git-send-email-anthony.perard@citrix.com>
	<1348564001.3452.127.camel@zakaz.uk.xensource.com>
	<1348564200.3452.128.camel@zakaz.uk.xensource.com>
In-Reply-To: <1348564200.3452.128.camel@zakaz.uk.xensource.com>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Xen Devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH V2 7/9] libxl_qmp: Introduce
	libxl__qmp_set_global_dirty_log.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 09/25/2012 10:10 AM, Ian Campbell wrote:
> On Tue, 2012-09-25 at 10:06 +0100, Ian Campbell wrote:
>>> +    rc = qmp_run_command(gc, domid, "xen-set-global-dirty-log", args,
>>> +                         NULL, NULL);
> 
> For got to ask: Is this new function upstream and in our branch already?

No, the patches haven't been accepted yet.

> I suppose there is no ordering constraint since we fail now, and if we
> take this patch we'll just fail more explicitly with an ENOSYS type
> error unless/until the qemu half is in place.

Yep, patches can be apply in any order. If QEMU does not know the
command, then it will return an error, and it will be relayed by libxl.


-- 
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 Sep 25 14:53:42 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 14:53: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 1TGWVq-00051Y-Kw; Tue, 25 Sep 2012 14:53:26 +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 1TGWVp-00051Q-1l
	for xen-devel@lists.xen.org; Tue, 25 Sep 2012 14:53:25 +0000
Received: from [85.158.143.35:54089] by server-1.bemta-4.messagelabs.com id
	2F/76-05684-465C1605; Tue, 25 Sep 2012 14:53:24 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1348584794!8819684!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzEyNDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32537 invoked from network); 25 Sep 2012 14:53:21 -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;
	25 Sep 2012 14:53:21 -0000
X-IronPort-AV: E=Sophos;i="4.80,483,1344211200"; d="scan'208";a="39097284"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Sep 2012 14:53:11 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Tue, 25 Sep 2012 10:53:11 -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 1TGWVb-0007Kh-2M;
	Tue, 25 Sep 2012 15:53:11 +0100
Message-ID: <5061C556.60406@citrix.com>
Date: Tue, 25 Sep 2012 15:53:10 +0100
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120912 Thunderbird/15.0.1
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <5061BD4E.6000905@citrix.com>
	<1348583626.11229.26.camel@zakaz.uk.xensource.com>
In-Reply-To: <1348583626.11229.26.camel@zakaz.uk.xensource.com>
X-Enigmail-Version: 1.4.4
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] RFC: EFER in crash notes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


On 25/09/12 15:33, Ian Campbell wrote:
> On Tue, 2012-09-25 at 15:18 +0100, Andrew Cooper wrote:
>> While this patch is very simple, and I hope without any objection, it is
>> RFC for the reason that our crash ABI is private.
>>
>> The comments for XEN_ELFNOTE_CRASH_REGS does state that it is
>> architecture specific, and makes no indication about the size or
>> contents of the crash note.  However, any code trying to use one of
>> these types of notes has to make an assumption that it if the note desc
>> length is 4*8 bytes long, it is representing CR{0,2-4}.
>>
>> I guess my question boils down to whether it is acceptable to change a
>> private ABI which is not really so private, or whether we should make a
>> formal public ABI for all of the inards of the crash notes and use that.
> Is it really private? (or even "not so private"), don't external tools
> like crash support it?

This is my point.  It is not in xen/public but is used by crash/kdump
and similar utilities, effectively making it a public ABI.

include/public/elfnote.h even explicitly refers to
include/xen/elfcore.h, which is not public by our definition.

>
> I suppose the size field in the notes is a sort of rudimentary version
> field. Remember you can always add a new note type though.

Yes, although looking through my code, I do raise an error if
sizeof(note->desc) != sizeof(my structure representing this note), which
was put in with the best of intentions, but will break with the this RFC
change.

On the other hand, adding a new crash note for every new register will
not scale well, as it is per PCU.

I guess the only sensible way to continue is to present a formal public ABI.

>
> Ian.
>
>
-- 
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 Sep 25 14:53:42 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 14:53: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 1TGWVq-00051Y-Kw; Tue, 25 Sep 2012 14:53:26 +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 1TGWVp-00051Q-1l
	for xen-devel@lists.xen.org; Tue, 25 Sep 2012 14:53:25 +0000
Received: from [85.158.143.35:54089] by server-1.bemta-4.messagelabs.com id
	2F/76-05684-465C1605; Tue, 25 Sep 2012 14:53:24 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1348584794!8819684!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzEyNDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32537 invoked from network); 25 Sep 2012 14:53:21 -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;
	25 Sep 2012 14:53:21 -0000
X-IronPort-AV: E=Sophos;i="4.80,483,1344211200"; d="scan'208";a="39097284"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Sep 2012 14:53:11 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Tue, 25 Sep 2012 10:53:11 -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 1TGWVb-0007Kh-2M;
	Tue, 25 Sep 2012 15:53:11 +0100
Message-ID: <5061C556.60406@citrix.com>
Date: Tue, 25 Sep 2012 15:53:10 +0100
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120912 Thunderbird/15.0.1
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <5061BD4E.6000905@citrix.com>
	<1348583626.11229.26.camel@zakaz.uk.xensource.com>
In-Reply-To: <1348583626.11229.26.camel@zakaz.uk.xensource.com>
X-Enigmail-Version: 1.4.4
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] RFC: EFER in crash notes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


On 25/09/12 15:33, Ian Campbell wrote:
> On Tue, 2012-09-25 at 15:18 +0100, Andrew Cooper wrote:
>> While this patch is very simple, and I hope without any objection, it is
>> RFC for the reason that our crash ABI is private.
>>
>> The comments for XEN_ELFNOTE_CRASH_REGS does state that it is
>> architecture specific, and makes no indication about the size or
>> contents of the crash note.  However, any code trying to use one of
>> these types of notes has to make an assumption that it if the note desc
>> length is 4*8 bytes long, it is representing CR{0,2-4}.
>>
>> I guess my question boils down to whether it is acceptable to change a
>> private ABI which is not really so private, or whether we should make a
>> formal public ABI for all of the inards of the crash notes and use that.
> Is it really private? (or even "not so private"), don't external tools
> like crash support it?

This is my point.  It is not in xen/public but is used by crash/kdump
and similar utilities, effectively making it a public ABI.

include/public/elfnote.h even explicitly refers to
include/xen/elfcore.h, which is not public by our definition.

>
> I suppose the size field in the notes is a sort of rudimentary version
> field. Remember you can always add a new note type though.

Yes, although looking through my code, I do raise an error if
sizeof(note->desc) != sizeof(my structure representing this note), which
was put in with the best of intentions, but will break with the this RFC
change.

On the other hand, adding a new crash note for every new register will
not scale well, as it is per PCU.

I guess the only sensible way to continue is to present a formal public ABI.

>
> Ian.
>
>
-- 
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 Sep 25 14:55:00 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 14:55:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGWXA-00057o-3x; Tue, 25 Sep 2012 14:54:48 +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 1TGWX8-00057Y-Ua
	for xen-devel@lists.xen.org; Tue, 25 Sep 2012 14:54:47 +0000
Received: from [85.158.138.51:14352] by server-15.bemta-3.messagelabs.com id
	33/36-09665-6B5C1605; Tue, 25 Sep 2012 14:54:46 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1348584854!31881905!1
X-Originating-IP: [74.125.83.45]
X-SpamReason: No, hits=1.4 required=7.0 tests=HTML_20_30,HTML_MESSAGE,
	MIME_QP_LONG_LINE,RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17539 invoked from network); 25 Sep 2012 14:54:44 -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;
	25 Sep 2012 14:54:44 -0000
Received: by eekb47 with SMTP id b47so1300318eek.32
	for <xen-devel@lists.xen.org>; Tue, 25 Sep 2012 07:54:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type;
	bh=JpJyiaXqD6QYtkXoLs1l7Ywb0ssSNINXT8PGcmcAFhQ=;
	b=sxDHjleFIrEA5pSpPbYM6j8hNLEWBuZqLmGqqdbuRd0iK66Ysd19tRXZtgu5HlhydV
	4CNiGN01DF9327j7eJqk8lIEtHXThTVXv3N2raiw+N1B9Owjs39WRbj4SyPzBWzBjb/c
	uisDvGSG8d6CJqO9Mz3ec/dw7J4OSeHVQFIskttnHGxxVYhCr1FOKnNQbUSfHTdfPLD1
	tLoa0hI/Pp+8NgX2TesoN3hTomxXt9oeE4PiH5LjUYHw5SS+oADmYa7CV8qljHtjjtZ9
	cvQ9KeRLIc91up3XoN1Nec7GUS0R6F6bKsf2YCqg2BAhmmigjbMWLygf9hNsclwtDm19
	+1UA==
Received: by 10.14.213.201 with SMTP id a49mr20856383eep.4.1348584848066;
	Tue, 25 Sep 2012 07:54:08 -0700 (PDT)
Received: from [192.168.1.3] (host86-167-82-156.range86-167.btcentralplus.com.
	[86.167.82.156])
	by mx.google.com with ESMTPS id u47sm1513866eeo.9.2012.09.25.07.53.34
	(version=SSLv3 cipher=OTHER); Tue, 25 Sep 2012 07:53:36 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.33.0.120411
Date: Tue, 25 Sep 2012 15:53:29 +0100
From: Keir Fraser <keir@xen.org>
To: Ben Guthro <ben@guthro.net>,
	Jan Beulich <JBeulich@suse.com>
Message-ID: <CC8783F9.4CD7A%keir@xen.org>
Thread-Topic: [Xen-devel] Xen4.2 S3 regression?
Thread-Index: Ac2bLYYkMTrXr1dZgkm7LBgXKc9cnA==
In-Reply-To: <CAOvdn6X6_NwfTNTgwNG7CQOqu2oDb6o6r1Zf+5y0cwZGLKToxA@mail.gmail.com>
Mime-version: 1.0
Cc: John Baboval <john.baboval@citrix.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen4.2 S3 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: multipart/mixed; boundary="===============3281119307470274314=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--===============3281119307470274314==
Content-type: multipart/alternative;
	boundary="B_3431433214_4287069"

> This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--B_3431433214_4287069
Content-type: text/plain;
	charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable

This was introduced as part of a patch to avoid losing cpu and cpupool
affinities/memberships across S3. Looks like it breaks some assumptions in
the scheduler though, probably because all CPUs are not taken offline
atomically, nor brought back online atomically. Hence some other running CP=
U
can execute hypervisor code that observes VCPUs in this bad
can=B9t-run-anywhere state. I guess this is what is happening. I=B9m not
immediately sure of the best fix. :(

 -- Keir

On 25/09/2012 15:22, "Ben Guthro" <ben@guthro.net> wrote:

> I went back to an old patch that had, since it was in this same function =
that
> you made reference to:
> http://markmail.org/message/qpnmiqzt5bngeejk
>=20
> I noticed that I was not seeing the "Breaking vcpu affinity" printk - so =
I
> tried to get that=A0
>=20
> The change proposed in that thread seems to work around this pinning prob=
lem.
> However, I'm not sure that it is the "right thing" to be doing.
>=20
> Do you have any thoughts on this?
>=20
>=20
> On Tue, Sep 25, 2012 at 7:56 AM, Ben Guthro <ben@guthro.net> wrote:
>>=20
>> On Tue, Sep 25, 2012 at 3:00 AM, Jan Beulich <JBeulich@suse.com> wrote:
>>>>>> >>> On 24.09.12 at 23:12, Ben Guthro <ben@guthro.net> wrote:
>>>> > Here's my "Big hammer" debugging patch.
>>>> >
>>>> > If I force the cpu to be scheduled on CPU0 when the appropriate cpu =
is
>>>> not
>>>> > online, I can resume properly.
>>>> >
>>>> > Clearly this is not the proper solution, and I'm sure the fix is sub=
tle.
>>>> > I'm not seeing it right now though. Perhaps tomorrow morning.
>>>> > If you have any ideas, I'm happy to run tests then.
>>>=20
>>> I can't see how the printk() you add in the patch would ever get
>>> reached with the other adjustment you do there.
>>=20
>> Apologies. I failed to separate prior debugging in this patch from the "=
big
>> hammer" fix
>> =A0
>>> A debug build,
>>> as Keir suggested, would not only get the stack trace right, but
>>> would also result in the ASSERT() right after your first modification
>>> to _csched_cpu_pick() to actually do something (and likely trigger).
>>=20
>> Indeed. I was using non-debug builds for 2 reasons that, in hindsight ma=
y not
>> be the best of reasons.
>> 1. It was the default
>> 2. Mukesh's kdb debugger requires debug to be off, which I was making us=
e of
>> previously, and had not disabled.
>> =A0
>> The stack from a debug build can be found below.
>> It did, indeed trigger the ASSERT, as you predicted.
>>=20
>>=20
>> (XEN) Finishing wakeup from ACPI S3 state.
>> (XEN) Enabling non-boot CPUs =A0...
>> (XEN) Booting processor 1/1 eip 8a000
>> (XEN) Initializing CPU#1
>> (XEN) CPU: L1 I cache: 32K, L1 D cache: 32K
>> (XEN) CPU: L2 cache: 3072K
>> (XEN) CPU: Physical Processor ID: 0
>> (XEN) CPU: Processor Core ID: 1
>> (XEN) CMCI: CPU1 has no CMCI support
>> (XEN) CPU1: Thermal monitoring enabled (TM2)
>> (XEN) CPU1: Intel(R) Core(TM)2 Duo CPU =A0 =A0 P8400 =A0@ 2.26GHz stepping 06
>> (XEN) microcode: CPU1 updated from revision 0x60c to 0x60f, date =3D
>> 2010-09-29=A0
>> [ =A0 82.310025] ACPI: Low-level resume complete
>> [ =A0 82.310025] PM: Restoring platform NVS memory
>> [ =A0 82.310025] Enabling non-boot CPUs ...
>> [ =A0 82.310025] installing Xen timer for CPU 1
>> [ =A0 82.310025] cpu 1 spinlock event irq 279
>> (XEN) Assertion '!cpumask_empty(&cpus) && cpumask_test_cpu(cpu, &cpus)'
>> failed at sched_credit.c:477
>> (XEN) ----[ Xen-4.2.1-pre =A0x86_64 =A0debug=3Dy =A0Tainted: =A0 =A0C ]----
>> (XEN) CPU: =A0 =A01
>> (XEN) RIP: =A0 =A0e008:[<ffff82c48011a35a>] _csched_cpu_pick+0x135/0x552
>> (XEN) RFLAGS: 0000000000010002 =A0 CONTEXT: hypervisor
>> (XEN) rax: 0000000000000001 =A0 rbx: 0000000000000004 =A0 rcx: 0000000000000=
004
>> (XEN) rdx: 000000000000000f =A0 rsi: 0000000000000004 =A0 rdi: 0000000000000=
000
>> (XEN) rbp: ffff8301355d7dd8 =A0 rsp: ffff8301355d7d08 =A0 r8: =A00000000000000=
000
>> (XEN) r9: =A0000000000000003e =A0 r10: ffff82c480231700 =A0 r11: 0000000000000=
246
>> (XEN) r12: ffff82c480261b20 =A0 r13: 0000000000000001 =A0 r14: ffff82c480301=
a60
>> (XEN) r15: ffff83013a542068 =A0 cr0: 000000008005003b =A0 cr4: 0000000000002=
6f0
>> (XEN) cr3: 0000000131a05000 =A0 cr2: 0000000000000000
>> (XEN) ds: 002b =A0 es: 002b =A0 fs: 0000 =A0 gs: 0000 =A0 ss: e010 =A0 cs: e008
>> (XEN) Xen stack trace from rsp=3Dffff8301355d7d08:
>> (XEN) =A0 =A00100000131a05000 ffff8301355d7d40 0000000000000082 000000000000=
0002
>> (XEN) =A0 =A0ffff8300bd503000 0000000000000001 0000000000000297 ffff8301355d=
7d58
>> (XEN) =A0 =A0ffff82c480125499 ffff830138216000 ffff8301355d7d98 540000000000=
0002
>> (XEN) =A0 =A00000000000000286 ffff8301355d7d88 ffff82c480125499 ffff83013821=
6000
>> (XEN) =A0 =A00000000000000000 0000000000000000 0000000000000000 000000000000=
0000
>> (XEN) =A0 =A0ffff830134ca6a50 ffff83013a542068 ffff83013a542068 000000000000=
0001
>> (XEN) =A0 =A0ffff82c480301a60 ffff83013a542068 ffff8301355d7de8 ffff82c48011=
a785
>> (XEN) =A0 =A0ffff8301355d7e58 ffff82c480123519 ffff82c480301a60 ffff82c48030=
1a60
>> (XEN) =A0 =A0ffff82c480301a60 ffff8300bd503000 0000000000503060 000000000000=
0246
>> (XEN) =A0 =A0ffff82c480127c31 ffff8300bd503000 ffff82c480301a60 ffff82c4802e=
bd40
>> (XEN) =A0 =A0ffff83013a542068 ffff88003fc8e820 ffff8301355d7e88 ffff82c48012=
37d3
>> (XEN) =A0 =A0fffffffffffffffe ffff8301355ca000 ffff8300bd503000 000000000000=
0000
>> (XEN) =A0 =A0ffff8301355d7ef8 ffff82c480106335 ffff8301355d7f18 ffffffff8100=
30e1
>> (XEN) =A0 =A0ffff8300bd503000 0000000000000000 ffff8301355d7f08 ffff82c48018=
5390
>> (XEN) =A0 =A0ffffffff81aafd32 ffff8300bd503000 0000000000000001 000000000000=
0000
>> (XEN) =A0 =A00000000000000000 ffff88003fc8e820 00007cfecaa280c7 ffff82c48022=
7348
>> (XEN) =A0 =A0ffffffff8100130a 0000000000000018 ffff88003fc8e820 000000000000=
0000
>> (XEN) =A0 =A00000000000000000 0000000000000001 ffff88003976fda0 ffff88003fc8=
bdc0
>> (XEN) =A0 =A00000000000000246 ffff88003976fe60 00000000ffffffff 000000000000=
0000
>> (XEN) =A0 =A00000000000000018 ffffffff8100130a 0000000000000000 000000000000=
0001
>> (XEN) Xen call trace:
>> (XEN) =A0 =A0[<ffff82c48011a35a>] _csched_cpu_pick+0x135/0x552
>> (XEN) =A0 =A0[<ffff82c48011a785>] csched_cpu_pick+0xe/0x10
>> (XEN) =A0 =A0[<ffff82c480123519>] vcpu_migrate+0x19f/0x346
>> (XEN) =A0 =A0[<ffff82c4801237d3>] vcpu_force_reschedule+0xa4/0xb6
>> (XEN) =A0 =A0[<ffff82c480106335>] do_vcpu_op+0x2c9/0x452
>> (XEN) =A0 =A0[<ffff82c480227348>] syscall_enter+0xc8/0x122
>> (XEN) =A0 =A0
>> (XEN)=A0
>> (XEN) ****************************************
>> (XEN) Panic on CPU 1:
>> (XEN) Assertion '!cpumask_empty(&cpus) && cpumask_test_cpu(cpu, &cpus)'
>> failed at sched_credit.c:477
>> (XEN) ****************************************
>> (XEN)=A0
>> (XEN) Reboot in five seconds...
>>=20
>>>=20
>>> Anyway, this might be connected to cpu_disable_scheduler() not
>>> having a counterpart to restore the affinity it broke for pinned
>>> domains (for non-pinned ones I believe this behavior is intentional,
>>> albeit not ideal).
>>>=20
>>> Jan
>>>=20
>>=20
>=20
>=20


--B_3431433214_4287069
Content-type: text/html;
	charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable

<HTML>
<HEAD>
<TITLE>Re: [Xen-devel] Xen4.2 S3 regression?</TITLE>
</HEAD>
<BODY>
<FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN STYLE=3D'font-size:11pt=
'>This was introduced as part of a patch to avoid losing cpu and cpupool aff=
inities/memberships across S3. Looks like it breaks some assumptions in the =
scheduler though, probably because all CPUs are not taken offline atomically=
, nor brought back online atomically. Hence some other running CPU can execu=
te hypervisor code that observes VCPUs in this bad can&#8217;t-run-anywhere =
state. I guess this is what is happening. I&#8217;m not immediately sure of =
the best fix. :(<BR>
<BR>
&nbsp;-- Keir<BR>
<BR>
On 25/09/2012 15:22, &quot;Ben Guthro&quot; &lt;<a href=3D"ben@guthro.net">be=
n@guthro.net</a>&gt; wrote:<BR>
<BR>
</SPAN></FONT><BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><=
SPAN STYLE=3D'font-size:11pt'>I went back to an old patch that had, since it w=
as in this same function that you made reference to:<BR>
<a href=3D"http://markmail.org/message/qpnmiqzt5bngeejk">http://markmail.org/=
message/qpnmiqzt5bngeejk</a><BR>
<BR>
I noticed that I was not seeing the &quot;Breaking vcpu affinity&quot; prin=
tk - so I tried to get that=A0<BR>
<BR>
The change proposed in that thread seems to work around this pinning proble=
m.<BR>
However, I'm not sure that it is the &quot;right thing&quot; to be doing.<B=
R>
<BR>
Do you have any thoughts on this?<BR>
<BR>
<BR>
On Tue, Sep 25, 2012 at 7:56 AM, Ben Guthro &lt;<a href=3D"ben@guthro.net">be=
n@guthro.net</a>&gt; wrote:<BR>
</SPAN></FONT><BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><=
SPAN STYLE=3D'font-size:11pt'><BR>
On Tue, Sep 25, 2012 at 3:00 AM, Jan Beulich &lt;<a href=3D"JBeulich@suse.com=
">JBeulich@suse.com</a>&gt; wrote:<BR>
</SPAN></FONT><BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><=
SPAN STYLE=3D'font-size:11pt'>&gt;&gt;&gt; On 24.09.12 at 23:12, Ben Guthro &l=
t;<a href=3D"ben@guthro.net">ben@guthro.net</a>&gt; wrote:<BR>
&gt; Here's my &quot;Big hammer&quot; debugging patch.<BR>
&gt;<BR>
&gt; If I force the cpu to be scheduled on CPU0 when the appropriate cpu is=
 not<BR>
&gt; online, I can resume properly.<BR>
&gt;<BR>
&gt; Clearly this is not the proper solution, and I'm sure the fix is subtl=
e.<BR>
&gt; I'm not seeing it right now though. Perhaps tomorrow morning.<BR>
&gt; If you have any ideas, I'm happy to run tests then.<BR>
<BR>
I can't see how the printk() you add in the patch would ever get<BR>
reached with the other adjustment you do there. <BR>
</SPAN></FONT></BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial">=
<SPAN STYLE=3D'font-size:11pt'><BR>
Apologies. I failed to separate prior debugging in this patch from the &quo=
t;big hammer&quot; fix<BR>
=A0<BR>
</SPAN></FONT><BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><=
SPAN STYLE=3D'font-size:11pt'>A debug build,<BR>
as Keir suggested, would not only get the stack trace right, but<BR>
would also result in the ASSERT() right after your first modification<BR>
to _csched_cpu_pick() to actually do something (and likely trigger).<BR>
</SPAN></FONT></BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial">=
<SPAN STYLE=3D'font-size:11pt'><BR>
Indeed. I was using non-debug builds for 2 reasons that, in hindsight may n=
ot be the best of reasons.<BR>
1. It was the default<BR>
2. Mukesh's kdb debugger requires debug to be off, which I was making use o=
f previously, and had not disabled.<BR>
=A0<BR>
The stack from a debug build can be found below.<BR>
It did, indeed trigger the ASSERT, as you predicted.<BR>
<BR>
<BR>
(XEN) Finishing wakeup from ACPI S3 state.<BR>
(XEN) Enabling non-boot CPUs =A0...<BR>
(XEN) Booting processor 1/1 eip 8a000<BR>
(XEN) Initializing CPU#1<BR>
(XEN) CPU: L1 I cache: 32K, L1 D cache: 32K<BR>
(XEN) CPU: L2 cache: 3072K<BR>
(XEN) CPU: Physical Processor ID: 0<BR>
(XEN) CPU: Processor Core ID: 1<BR>
(XEN) CMCI: CPU1 has no CMCI support<BR>
(XEN) CPU1: Thermal monitoring enabled (TM2)<BR>
(XEN) CPU1: Intel(R) Core(TM)2 Duo CPU =A0 =A0 P8400 =A0@ 2.26GHz stepping 06<BR>
(XEN) microcode: CPU1 updated from revision 0x60c to 0x60f, date =3D 2010-09-=
29=A0<BR>
[ =A0 82.310025] ACPI: Low-level resume complete<BR>
[ =A0 82.310025] PM: Restoring platform NVS memory<BR>
[ =A0 82.310025] Enabling non-boot CPUs ...<BR>
[ =A0 82.310025] installing Xen timer for CPU 1<BR>
[ =A0 82.310025] cpu 1 spinlock event irq 279<BR>
(XEN) Assertion '!cpumask_empty(&amp;cpus) &amp;&amp; cpumask_test_cpu(cpu,=
 &amp;cpus)' failed at sched_credit.c:477<BR>
(XEN) ----[ Xen-4.2.1-pre =A0x86_64 =A0debug=3Dy =A0Tainted: =A0 =A0C ]----<BR>
(XEN) CPU: =A0 =A01<BR>
(XEN) RIP: =A0 =A0e008:[&lt;ffff82c48011a35a&gt;] _csched_cpu_pick+0x135/0x552<=
BR>
(XEN) RFLAGS: 0000000000010002 =A0 CONTEXT: hypervisor<BR>
(XEN) rax: 0000000000000001 =A0 rbx: 0000000000000004 =A0 rcx: 0000000000000004=
<BR>
(XEN) rdx: 000000000000000f =A0 rsi: 0000000000000004 =A0 rdi: 0000000000000000=
<BR>
(XEN) rbp: ffff8301355d7dd8 =A0 rsp: ffff8301355d7d08 =A0 r8: =A00000000000000000=
<BR>
(XEN) r9: =A0000000000000003e =A0 r10: ffff82c480231700 =A0 r11: 0000000000000246=
<BR>
(XEN) r12: ffff82c480261b20 =A0 r13: 0000000000000001 =A0 r14: ffff82c480301a60=
<BR>
(XEN) r15: ffff83013a542068 =A0 cr0: 000000008005003b =A0 cr4: 00000000000026f0=
<BR>
(XEN) cr3: 0000000131a05000 =A0 cr2: 0000000000000000<BR>
(XEN) ds: 002b =A0 es: 002b =A0 fs: 0000 =A0 gs: 0000 =A0 ss: e010 =A0 cs: e008<BR>
(XEN) Xen stack trace from rsp=3Dffff8301355d7d08:<BR>
(XEN) =A0 =A00100000131a05000 ffff8301355d7d40 0000000000000082 000000000000000=
2<BR>
(XEN) =A0 =A0ffff8300bd503000 0000000000000001 0000000000000297 ffff8301355d7d5=
8<BR>
(XEN) =A0 =A0ffff82c480125499 ffff830138216000 ffff8301355d7d98 540000000000000=
2<BR>
(XEN) =A0 =A00000000000000286 ffff8301355d7d88 ffff82c480125499 ffff83013821600=
0<BR>
(XEN) =A0 =A00000000000000000 0000000000000000 0000000000000000 000000000000000=
0<BR>
(XEN) =A0 =A0ffff830134ca6a50 ffff83013a542068 ffff83013a542068 000000000000000=
1<BR>
(XEN) =A0 =A0ffff82c480301a60 ffff83013a542068 ffff8301355d7de8 ffff82c48011a78=
5<BR>
(XEN) =A0 =A0ffff8301355d7e58 ffff82c480123519 ffff82c480301a60 ffff82c480301a6=
0<BR>
(XEN) =A0 =A0ffff82c480301a60 ffff8300bd503000 0000000000503060 000000000000024=
6<BR>
(XEN) =A0 =A0ffff82c480127c31 ffff8300bd503000 ffff82c480301a60 ffff82c4802ebd4=
0<BR>
(XEN) =A0 =A0ffff83013a542068 ffff88003fc8e820 ffff8301355d7e88 ffff82c4801237d=
3<BR>
(XEN) =A0 =A0fffffffffffffffe ffff8301355ca000 ffff8300bd503000 000000000000000=
0<BR>
(XEN) =A0 =A0ffff8301355d7ef8 ffff82c480106335 ffff8301355d7f18 ffffffff810030e=
1<BR>
(XEN) =A0 =A0ffff8300bd503000 0000000000000000 ffff8301355d7f08 ffff82c48018539=
0<BR>
(XEN) =A0 =A0ffffffff81aafd32 ffff8300bd503000 0000000000000001 000000000000000=
0<BR>
(XEN) =A0 =A00000000000000000 ffff88003fc8e820 00007cfecaa280c7 ffff82c48022734=
8<BR>
(XEN) =A0 =A0ffffffff8100130a 0000000000000018 ffff88003fc8e820 000000000000000=
0<BR>
(XEN) =A0 =A00000000000000000 0000000000000001 ffff88003976fda0 ffff88003fc8bdc=
0<BR>
(XEN) =A0 =A00000000000000246 ffff88003976fe60 00000000ffffffff 000000000000000=
0<BR>
(XEN) =A0 =A00000000000000018 ffffffff8100130a 0000000000000000 000000000000000=
1<BR>
(XEN) Xen call trace:<BR>
(XEN) =A0 =A0[&lt;ffff82c48011a35a&gt;] _csched_cpu_pick+0x135/0x552<BR>
(XEN) =A0 =A0[&lt;ffff82c48011a785&gt;] csched_cpu_pick+0xe/0x10<BR>
(XEN) =A0 =A0[&lt;ffff82c480123519&gt;] vcpu_migrate+0x19f/0x346<BR>
(XEN) =A0 =A0[&lt;ffff82c4801237d3&gt;] vcpu_force_reschedule+0xa4/0xb6<BR>
(XEN) =A0 =A0[&lt;ffff82c480106335&gt;] do_vcpu_op+0x2c9/0x452<BR>
(XEN) =A0 =A0[&lt;ffff82c480227348&gt;] syscall_enter+0xc8/0x122<BR>
(XEN) =A0 =A0<BR>
(XEN)=A0<BR>
(XEN) ****************************************<BR>
(XEN) Panic on CPU 1:<BR>
(XEN) Assertion '!cpumask_empty(&amp;cpus) &amp;&amp; cpumask_test_cpu(cpu,=
 &amp;cpus)' failed at sched_credit.c:477<BR>
(XEN) ****************************************<BR>
(XEN)=A0<BR>
(XEN) Reboot in five seconds...<BR>
<BR>
</SPAN></FONT><BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><=
SPAN STYLE=3D'font-size:11pt'><BR>
Anyway, this might be connected to cpu_disable_scheduler() not<BR>
having a counterpart to restore the affinity it broke for pinned<BR>
domains (for non-pinned ones I believe this behavior is intentional,<BR>
albeit not ideal).<BR>
<FONT COLOR=3D"#888888"><BR>
Jan<BR>
<BR>
</FONT></SPAN></FONT></BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, =
Arial"><SPAN STYLE=3D'font-size:11pt'><BR>
</SPAN></FONT></BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial">=
<SPAN STYLE=3D'font-size:11pt'><BR>
<BR>
</SPAN></FONT></BLOCKQUOTE>
</BODY>
</HTML>


--B_3431433214_4287069--




--===============3281119307470274314==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============3281119307470274314==--




From xen-devel-bounces@lists.xen.org Tue Sep 25 14:55:00 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 14:55:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGWXA-00057o-3x; Tue, 25 Sep 2012 14:54:48 +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 1TGWX8-00057Y-Ua
	for xen-devel@lists.xen.org; Tue, 25 Sep 2012 14:54:47 +0000
Received: from [85.158.138.51:14352] by server-15.bemta-3.messagelabs.com id
	33/36-09665-6B5C1605; Tue, 25 Sep 2012 14:54:46 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1348584854!31881905!1
X-Originating-IP: [74.125.83.45]
X-SpamReason: No, hits=1.4 required=7.0 tests=HTML_20_30,HTML_MESSAGE,
	MIME_QP_LONG_LINE,RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17539 invoked from network); 25 Sep 2012 14:54:44 -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;
	25 Sep 2012 14:54:44 -0000
Received: by eekb47 with SMTP id b47so1300318eek.32
	for <xen-devel@lists.xen.org>; Tue, 25 Sep 2012 07:54:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type;
	bh=JpJyiaXqD6QYtkXoLs1l7Ywb0ssSNINXT8PGcmcAFhQ=;
	b=sxDHjleFIrEA5pSpPbYM6j8hNLEWBuZqLmGqqdbuRd0iK66Ysd19tRXZtgu5HlhydV
	4CNiGN01DF9327j7eJqk8lIEtHXThTVXv3N2raiw+N1B9Owjs39WRbj4SyPzBWzBjb/c
	uisDvGSG8d6CJqO9Mz3ec/dw7J4OSeHVQFIskttnHGxxVYhCr1FOKnNQbUSfHTdfPLD1
	tLoa0hI/Pp+8NgX2TesoN3hTomxXt9oeE4PiH5LjUYHw5SS+oADmYa7CV8qljHtjjtZ9
	cvQ9KeRLIc91up3XoN1Nec7GUS0R6F6bKsf2YCqg2BAhmmigjbMWLygf9hNsclwtDm19
	+1UA==
Received: by 10.14.213.201 with SMTP id a49mr20856383eep.4.1348584848066;
	Tue, 25 Sep 2012 07:54:08 -0700 (PDT)
Received: from [192.168.1.3] (host86-167-82-156.range86-167.btcentralplus.com.
	[86.167.82.156])
	by mx.google.com with ESMTPS id u47sm1513866eeo.9.2012.09.25.07.53.34
	(version=SSLv3 cipher=OTHER); Tue, 25 Sep 2012 07:53:36 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.33.0.120411
Date: Tue, 25 Sep 2012 15:53:29 +0100
From: Keir Fraser <keir@xen.org>
To: Ben Guthro <ben@guthro.net>,
	Jan Beulich <JBeulich@suse.com>
Message-ID: <CC8783F9.4CD7A%keir@xen.org>
Thread-Topic: [Xen-devel] Xen4.2 S3 regression?
Thread-Index: Ac2bLYYkMTrXr1dZgkm7LBgXKc9cnA==
In-Reply-To: <CAOvdn6X6_NwfTNTgwNG7CQOqu2oDb6o6r1Zf+5y0cwZGLKToxA@mail.gmail.com>
Mime-version: 1.0
Cc: John Baboval <john.baboval@citrix.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen4.2 S3 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: multipart/mixed; boundary="===============3281119307470274314=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--===============3281119307470274314==
Content-type: multipart/alternative;
	boundary="B_3431433214_4287069"

> This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--B_3431433214_4287069
Content-type: text/plain;
	charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable

This was introduced as part of a patch to avoid losing cpu and cpupool
affinities/memberships across S3. Looks like it breaks some assumptions in
the scheduler though, probably because all CPUs are not taken offline
atomically, nor brought back online atomically. Hence some other running CP=
U
can execute hypervisor code that observes VCPUs in this bad
can=B9t-run-anywhere state. I guess this is what is happening. I=B9m not
immediately sure of the best fix. :(

 -- Keir

On 25/09/2012 15:22, "Ben Guthro" <ben@guthro.net> wrote:

> I went back to an old patch that had, since it was in this same function =
that
> you made reference to:
> http://markmail.org/message/qpnmiqzt5bngeejk
>=20
> I noticed that I was not seeing the "Breaking vcpu affinity" printk - so =
I
> tried to get that=A0
>=20
> The change proposed in that thread seems to work around this pinning prob=
lem.
> However, I'm not sure that it is the "right thing" to be doing.
>=20
> Do you have any thoughts on this?
>=20
>=20
> On Tue, Sep 25, 2012 at 7:56 AM, Ben Guthro <ben@guthro.net> wrote:
>>=20
>> On Tue, Sep 25, 2012 at 3:00 AM, Jan Beulich <JBeulich@suse.com> wrote:
>>>>>> >>> On 24.09.12 at 23:12, Ben Guthro <ben@guthro.net> wrote:
>>>> > Here's my "Big hammer" debugging patch.
>>>> >
>>>> > If I force the cpu to be scheduled on CPU0 when the appropriate cpu =
is
>>>> not
>>>> > online, I can resume properly.
>>>> >
>>>> > Clearly this is not the proper solution, and I'm sure the fix is sub=
tle.
>>>> > I'm not seeing it right now though. Perhaps tomorrow morning.
>>>> > If you have any ideas, I'm happy to run tests then.
>>>=20
>>> I can't see how the printk() you add in the patch would ever get
>>> reached with the other adjustment you do there.
>>=20
>> Apologies. I failed to separate prior debugging in this patch from the "=
big
>> hammer" fix
>> =A0
>>> A debug build,
>>> as Keir suggested, would not only get the stack trace right, but
>>> would also result in the ASSERT() right after your first modification
>>> to _csched_cpu_pick() to actually do something (and likely trigger).
>>=20
>> Indeed. I was using non-debug builds for 2 reasons that, in hindsight ma=
y not
>> be the best of reasons.
>> 1. It was the default
>> 2. Mukesh's kdb debugger requires debug to be off, which I was making us=
e of
>> previously, and had not disabled.
>> =A0
>> The stack from a debug build can be found below.
>> It did, indeed trigger the ASSERT, as you predicted.
>>=20
>>=20
>> (XEN) Finishing wakeup from ACPI S3 state.
>> (XEN) Enabling non-boot CPUs =A0...
>> (XEN) Booting processor 1/1 eip 8a000
>> (XEN) Initializing CPU#1
>> (XEN) CPU: L1 I cache: 32K, L1 D cache: 32K
>> (XEN) CPU: L2 cache: 3072K
>> (XEN) CPU: Physical Processor ID: 0
>> (XEN) CPU: Processor Core ID: 1
>> (XEN) CMCI: CPU1 has no CMCI support
>> (XEN) CPU1: Thermal monitoring enabled (TM2)
>> (XEN) CPU1: Intel(R) Core(TM)2 Duo CPU =A0 =A0 P8400 =A0@ 2.26GHz stepping 06
>> (XEN) microcode: CPU1 updated from revision 0x60c to 0x60f, date =3D
>> 2010-09-29=A0
>> [ =A0 82.310025] ACPI: Low-level resume complete
>> [ =A0 82.310025] PM: Restoring platform NVS memory
>> [ =A0 82.310025] Enabling non-boot CPUs ...
>> [ =A0 82.310025] installing Xen timer for CPU 1
>> [ =A0 82.310025] cpu 1 spinlock event irq 279
>> (XEN) Assertion '!cpumask_empty(&cpus) && cpumask_test_cpu(cpu, &cpus)'
>> failed at sched_credit.c:477
>> (XEN) ----[ Xen-4.2.1-pre =A0x86_64 =A0debug=3Dy =A0Tainted: =A0 =A0C ]----
>> (XEN) CPU: =A0 =A01
>> (XEN) RIP: =A0 =A0e008:[<ffff82c48011a35a>] _csched_cpu_pick+0x135/0x552
>> (XEN) RFLAGS: 0000000000010002 =A0 CONTEXT: hypervisor
>> (XEN) rax: 0000000000000001 =A0 rbx: 0000000000000004 =A0 rcx: 0000000000000=
004
>> (XEN) rdx: 000000000000000f =A0 rsi: 0000000000000004 =A0 rdi: 0000000000000=
000
>> (XEN) rbp: ffff8301355d7dd8 =A0 rsp: ffff8301355d7d08 =A0 r8: =A00000000000000=
000
>> (XEN) r9: =A0000000000000003e =A0 r10: ffff82c480231700 =A0 r11: 0000000000000=
246
>> (XEN) r12: ffff82c480261b20 =A0 r13: 0000000000000001 =A0 r14: ffff82c480301=
a60
>> (XEN) r15: ffff83013a542068 =A0 cr0: 000000008005003b =A0 cr4: 0000000000002=
6f0
>> (XEN) cr3: 0000000131a05000 =A0 cr2: 0000000000000000
>> (XEN) ds: 002b =A0 es: 002b =A0 fs: 0000 =A0 gs: 0000 =A0 ss: e010 =A0 cs: e008
>> (XEN) Xen stack trace from rsp=3Dffff8301355d7d08:
>> (XEN) =A0 =A00100000131a05000 ffff8301355d7d40 0000000000000082 000000000000=
0002
>> (XEN) =A0 =A0ffff8300bd503000 0000000000000001 0000000000000297 ffff8301355d=
7d58
>> (XEN) =A0 =A0ffff82c480125499 ffff830138216000 ffff8301355d7d98 540000000000=
0002
>> (XEN) =A0 =A00000000000000286 ffff8301355d7d88 ffff82c480125499 ffff83013821=
6000
>> (XEN) =A0 =A00000000000000000 0000000000000000 0000000000000000 000000000000=
0000
>> (XEN) =A0 =A0ffff830134ca6a50 ffff83013a542068 ffff83013a542068 000000000000=
0001
>> (XEN) =A0 =A0ffff82c480301a60 ffff83013a542068 ffff8301355d7de8 ffff82c48011=
a785
>> (XEN) =A0 =A0ffff8301355d7e58 ffff82c480123519 ffff82c480301a60 ffff82c48030=
1a60
>> (XEN) =A0 =A0ffff82c480301a60 ffff8300bd503000 0000000000503060 000000000000=
0246
>> (XEN) =A0 =A0ffff82c480127c31 ffff8300bd503000 ffff82c480301a60 ffff82c4802e=
bd40
>> (XEN) =A0 =A0ffff83013a542068 ffff88003fc8e820 ffff8301355d7e88 ffff82c48012=
37d3
>> (XEN) =A0 =A0fffffffffffffffe ffff8301355ca000 ffff8300bd503000 000000000000=
0000
>> (XEN) =A0 =A0ffff8301355d7ef8 ffff82c480106335 ffff8301355d7f18 ffffffff8100=
30e1
>> (XEN) =A0 =A0ffff8300bd503000 0000000000000000 ffff8301355d7f08 ffff82c48018=
5390
>> (XEN) =A0 =A0ffffffff81aafd32 ffff8300bd503000 0000000000000001 000000000000=
0000
>> (XEN) =A0 =A00000000000000000 ffff88003fc8e820 00007cfecaa280c7 ffff82c48022=
7348
>> (XEN) =A0 =A0ffffffff8100130a 0000000000000018 ffff88003fc8e820 000000000000=
0000
>> (XEN) =A0 =A00000000000000000 0000000000000001 ffff88003976fda0 ffff88003fc8=
bdc0
>> (XEN) =A0 =A00000000000000246 ffff88003976fe60 00000000ffffffff 000000000000=
0000
>> (XEN) =A0 =A00000000000000018 ffffffff8100130a 0000000000000000 000000000000=
0001
>> (XEN) Xen call trace:
>> (XEN) =A0 =A0[<ffff82c48011a35a>] _csched_cpu_pick+0x135/0x552
>> (XEN) =A0 =A0[<ffff82c48011a785>] csched_cpu_pick+0xe/0x10
>> (XEN) =A0 =A0[<ffff82c480123519>] vcpu_migrate+0x19f/0x346
>> (XEN) =A0 =A0[<ffff82c4801237d3>] vcpu_force_reschedule+0xa4/0xb6
>> (XEN) =A0 =A0[<ffff82c480106335>] do_vcpu_op+0x2c9/0x452
>> (XEN) =A0 =A0[<ffff82c480227348>] syscall_enter+0xc8/0x122
>> (XEN) =A0 =A0
>> (XEN)=A0
>> (XEN) ****************************************
>> (XEN) Panic on CPU 1:
>> (XEN) Assertion '!cpumask_empty(&cpus) && cpumask_test_cpu(cpu, &cpus)'
>> failed at sched_credit.c:477
>> (XEN) ****************************************
>> (XEN)=A0
>> (XEN) Reboot in five seconds...
>>=20
>>>=20
>>> Anyway, this might be connected to cpu_disable_scheduler() not
>>> having a counterpart to restore the affinity it broke for pinned
>>> domains (for non-pinned ones I believe this behavior is intentional,
>>> albeit not ideal).
>>>=20
>>> Jan
>>>=20
>>=20
>=20
>=20


--B_3431433214_4287069
Content-type: text/html;
	charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable

<HTML>
<HEAD>
<TITLE>Re: [Xen-devel] Xen4.2 S3 regression?</TITLE>
</HEAD>
<BODY>
<FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN STYLE=3D'font-size:11pt=
'>This was introduced as part of a patch to avoid losing cpu and cpupool aff=
inities/memberships across S3. Looks like it breaks some assumptions in the =
scheduler though, probably because all CPUs are not taken offline atomically=
, nor brought back online atomically. Hence some other running CPU can execu=
te hypervisor code that observes VCPUs in this bad can&#8217;t-run-anywhere =
state. I guess this is what is happening. I&#8217;m not immediately sure of =
the best fix. :(<BR>
<BR>
&nbsp;-- Keir<BR>
<BR>
On 25/09/2012 15:22, &quot;Ben Guthro&quot; &lt;<a href=3D"ben@guthro.net">be=
n@guthro.net</a>&gt; wrote:<BR>
<BR>
</SPAN></FONT><BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><=
SPAN STYLE=3D'font-size:11pt'>I went back to an old patch that had, since it w=
as in this same function that you made reference to:<BR>
<a href=3D"http://markmail.org/message/qpnmiqzt5bngeejk">http://markmail.org/=
message/qpnmiqzt5bngeejk</a><BR>
<BR>
I noticed that I was not seeing the &quot;Breaking vcpu affinity&quot; prin=
tk - so I tried to get that=A0<BR>
<BR>
The change proposed in that thread seems to work around this pinning proble=
m.<BR>
However, I'm not sure that it is the &quot;right thing&quot; to be doing.<B=
R>
<BR>
Do you have any thoughts on this?<BR>
<BR>
<BR>
On Tue, Sep 25, 2012 at 7:56 AM, Ben Guthro &lt;<a href=3D"ben@guthro.net">be=
n@guthro.net</a>&gt; wrote:<BR>
</SPAN></FONT><BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><=
SPAN STYLE=3D'font-size:11pt'><BR>
On Tue, Sep 25, 2012 at 3:00 AM, Jan Beulich &lt;<a href=3D"JBeulich@suse.com=
">JBeulich@suse.com</a>&gt; wrote:<BR>
</SPAN></FONT><BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><=
SPAN STYLE=3D'font-size:11pt'>&gt;&gt;&gt; On 24.09.12 at 23:12, Ben Guthro &l=
t;<a href=3D"ben@guthro.net">ben@guthro.net</a>&gt; wrote:<BR>
&gt; Here's my &quot;Big hammer&quot; debugging patch.<BR>
&gt;<BR>
&gt; If I force the cpu to be scheduled on CPU0 when the appropriate cpu is=
 not<BR>
&gt; online, I can resume properly.<BR>
&gt;<BR>
&gt; Clearly this is not the proper solution, and I'm sure the fix is subtl=
e.<BR>
&gt; I'm not seeing it right now though. Perhaps tomorrow morning.<BR>
&gt; If you have any ideas, I'm happy to run tests then.<BR>
<BR>
I can't see how the printk() you add in the patch would ever get<BR>
reached with the other adjustment you do there. <BR>
</SPAN></FONT></BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial">=
<SPAN STYLE=3D'font-size:11pt'><BR>
Apologies. I failed to separate prior debugging in this patch from the &quo=
t;big hammer&quot; fix<BR>
=A0<BR>
</SPAN></FONT><BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><=
SPAN STYLE=3D'font-size:11pt'>A debug build,<BR>
as Keir suggested, would not only get the stack trace right, but<BR>
would also result in the ASSERT() right after your first modification<BR>
to _csched_cpu_pick() to actually do something (and likely trigger).<BR>
</SPAN></FONT></BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial">=
<SPAN STYLE=3D'font-size:11pt'><BR>
Indeed. I was using non-debug builds for 2 reasons that, in hindsight may n=
ot be the best of reasons.<BR>
1. It was the default<BR>
2. Mukesh's kdb debugger requires debug to be off, which I was making use o=
f previously, and had not disabled.<BR>
=A0<BR>
The stack from a debug build can be found below.<BR>
It did, indeed trigger the ASSERT, as you predicted.<BR>
<BR>
<BR>
(XEN) Finishing wakeup from ACPI S3 state.<BR>
(XEN) Enabling non-boot CPUs =A0...<BR>
(XEN) Booting processor 1/1 eip 8a000<BR>
(XEN) Initializing CPU#1<BR>
(XEN) CPU: L1 I cache: 32K, L1 D cache: 32K<BR>
(XEN) CPU: L2 cache: 3072K<BR>
(XEN) CPU: Physical Processor ID: 0<BR>
(XEN) CPU: Processor Core ID: 1<BR>
(XEN) CMCI: CPU1 has no CMCI support<BR>
(XEN) CPU1: Thermal monitoring enabled (TM2)<BR>
(XEN) CPU1: Intel(R) Core(TM)2 Duo CPU =A0 =A0 P8400 =A0@ 2.26GHz stepping 06<BR>
(XEN) microcode: CPU1 updated from revision 0x60c to 0x60f, date =3D 2010-09-=
29=A0<BR>
[ =A0 82.310025] ACPI: Low-level resume complete<BR>
[ =A0 82.310025] PM: Restoring platform NVS memory<BR>
[ =A0 82.310025] Enabling non-boot CPUs ...<BR>
[ =A0 82.310025] installing Xen timer for CPU 1<BR>
[ =A0 82.310025] cpu 1 spinlock event irq 279<BR>
(XEN) Assertion '!cpumask_empty(&amp;cpus) &amp;&amp; cpumask_test_cpu(cpu,=
 &amp;cpus)' failed at sched_credit.c:477<BR>
(XEN) ----[ Xen-4.2.1-pre =A0x86_64 =A0debug=3Dy =A0Tainted: =A0 =A0C ]----<BR>
(XEN) CPU: =A0 =A01<BR>
(XEN) RIP: =A0 =A0e008:[&lt;ffff82c48011a35a&gt;] _csched_cpu_pick+0x135/0x552<=
BR>
(XEN) RFLAGS: 0000000000010002 =A0 CONTEXT: hypervisor<BR>
(XEN) rax: 0000000000000001 =A0 rbx: 0000000000000004 =A0 rcx: 0000000000000004=
<BR>
(XEN) rdx: 000000000000000f =A0 rsi: 0000000000000004 =A0 rdi: 0000000000000000=
<BR>
(XEN) rbp: ffff8301355d7dd8 =A0 rsp: ffff8301355d7d08 =A0 r8: =A00000000000000000=
<BR>
(XEN) r9: =A0000000000000003e =A0 r10: ffff82c480231700 =A0 r11: 0000000000000246=
<BR>
(XEN) r12: ffff82c480261b20 =A0 r13: 0000000000000001 =A0 r14: ffff82c480301a60=
<BR>
(XEN) r15: ffff83013a542068 =A0 cr0: 000000008005003b =A0 cr4: 00000000000026f0=
<BR>
(XEN) cr3: 0000000131a05000 =A0 cr2: 0000000000000000<BR>
(XEN) ds: 002b =A0 es: 002b =A0 fs: 0000 =A0 gs: 0000 =A0 ss: e010 =A0 cs: e008<BR>
(XEN) Xen stack trace from rsp=3Dffff8301355d7d08:<BR>
(XEN) =A0 =A00100000131a05000 ffff8301355d7d40 0000000000000082 000000000000000=
2<BR>
(XEN) =A0 =A0ffff8300bd503000 0000000000000001 0000000000000297 ffff8301355d7d5=
8<BR>
(XEN) =A0 =A0ffff82c480125499 ffff830138216000 ffff8301355d7d98 540000000000000=
2<BR>
(XEN) =A0 =A00000000000000286 ffff8301355d7d88 ffff82c480125499 ffff83013821600=
0<BR>
(XEN) =A0 =A00000000000000000 0000000000000000 0000000000000000 000000000000000=
0<BR>
(XEN) =A0 =A0ffff830134ca6a50 ffff83013a542068 ffff83013a542068 000000000000000=
1<BR>
(XEN) =A0 =A0ffff82c480301a60 ffff83013a542068 ffff8301355d7de8 ffff82c48011a78=
5<BR>
(XEN) =A0 =A0ffff8301355d7e58 ffff82c480123519 ffff82c480301a60 ffff82c480301a6=
0<BR>
(XEN) =A0 =A0ffff82c480301a60 ffff8300bd503000 0000000000503060 000000000000024=
6<BR>
(XEN) =A0 =A0ffff82c480127c31 ffff8300bd503000 ffff82c480301a60 ffff82c4802ebd4=
0<BR>
(XEN) =A0 =A0ffff83013a542068 ffff88003fc8e820 ffff8301355d7e88 ffff82c4801237d=
3<BR>
(XEN) =A0 =A0fffffffffffffffe ffff8301355ca000 ffff8300bd503000 000000000000000=
0<BR>
(XEN) =A0 =A0ffff8301355d7ef8 ffff82c480106335 ffff8301355d7f18 ffffffff810030e=
1<BR>
(XEN) =A0 =A0ffff8300bd503000 0000000000000000 ffff8301355d7f08 ffff82c48018539=
0<BR>
(XEN) =A0 =A0ffffffff81aafd32 ffff8300bd503000 0000000000000001 000000000000000=
0<BR>
(XEN) =A0 =A00000000000000000 ffff88003fc8e820 00007cfecaa280c7 ffff82c48022734=
8<BR>
(XEN) =A0 =A0ffffffff8100130a 0000000000000018 ffff88003fc8e820 000000000000000=
0<BR>
(XEN) =A0 =A00000000000000000 0000000000000001 ffff88003976fda0 ffff88003fc8bdc=
0<BR>
(XEN) =A0 =A00000000000000246 ffff88003976fe60 00000000ffffffff 000000000000000=
0<BR>
(XEN) =A0 =A00000000000000018 ffffffff8100130a 0000000000000000 000000000000000=
1<BR>
(XEN) Xen call trace:<BR>
(XEN) =A0 =A0[&lt;ffff82c48011a35a&gt;] _csched_cpu_pick+0x135/0x552<BR>
(XEN) =A0 =A0[&lt;ffff82c48011a785&gt;] csched_cpu_pick+0xe/0x10<BR>
(XEN) =A0 =A0[&lt;ffff82c480123519&gt;] vcpu_migrate+0x19f/0x346<BR>
(XEN) =A0 =A0[&lt;ffff82c4801237d3&gt;] vcpu_force_reschedule+0xa4/0xb6<BR>
(XEN) =A0 =A0[&lt;ffff82c480106335&gt;] do_vcpu_op+0x2c9/0x452<BR>
(XEN) =A0 =A0[&lt;ffff82c480227348&gt;] syscall_enter+0xc8/0x122<BR>
(XEN) =A0 =A0<BR>
(XEN)=A0<BR>
(XEN) ****************************************<BR>
(XEN) Panic on CPU 1:<BR>
(XEN) Assertion '!cpumask_empty(&amp;cpus) &amp;&amp; cpumask_test_cpu(cpu,=
 &amp;cpus)' failed at sched_credit.c:477<BR>
(XEN) ****************************************<BR>
(XEN)=A0<BR>
(XEN) Reboot in five seconds...<BR>
<BR>
</SPAN></FONT><BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><=
SPAN STYLE=3D'font-size:11pt'><BR>
Anyway, this might be connected to cpu_disable_scheduler() not<BR>
having a counterpart to restore the affinity it broke for pinned<BR>
domains (for non-pinned ones I believe this behavior is intentional,<BR>
albeit not ideal).<BR>
<FONT COLOR=3D"#888888"><BR>
Jan<BR>
<BR>
</FONT></SPAN></FONT></BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, =
Arial"><SPAN STYLE=3D'font-size:11pt'><BR>
</SPAN></FONT></BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial">=
<SPAN STYLE=3D'font-size:11pt'><BR>
<BR>
</SPAN></FONT></BLOCKQUOTE>
</BODY>
</HTML>


--B_3431433214_4287069--




--===============3281119307470274314==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============3281119307470274314==--




From xen-devel-bounces@lists.xen.org Tue Sep 25 14:55:36 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 14:55:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGWXm-0005Cj-PQ; Tue, 25 Sep 2012 14:55:26 +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 1TGWXk-0005CJ-IY
	for xen-devel@lists.xen.org; Tue, 25 Sep 2012 14:55:24 +0000
Received: from [85.158.138.51:22094] by server-9.bemta-3.messagelabs.com id
	BB/95-15390-BD5C1605; Tue, 25 Sep 2012 14:55:23 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1348584919!13242131!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzEyNDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4989 invoked from network); 25 Sep 2012 14:55:22 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-13.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Sep 2012 14:55:22 -0000
X-IronPort-AV: E=Sophos;i="4.80,483,1344211200"; d="scan'208";a="39097372"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Sep 2012 14:53:57 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Tue, 25 Sep 2012 10:53:57 -0400
Received: from [10.80.3.61]	by ukmail1.uk.xensource.com with esmtp (Exim 4.69)
	(envelope-from <anthony.perard@citrix.com>)	id 1TGWWL-0007Ld-9R;
	Tue, 25 Sep 2012 15:53:57 +0100
Message-ID: <5061C585.9020106@citrix.com>
Date: Tue, 25 Sep 2012 15:53:57 +0100
From: Anthony PERARD <anthony.perard@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120910 Thunderbird/15.0.1
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <1347906148-9606-1-git-send-email-anthony.perard@citrix.com>
	<1347906148-9606-10-git-send-email-anthony.perard@citrix.com>
	<1348565023.3452.136.camel@zakaz.uk.xensource.com>
In-Reply-To: <1348565023.3452.136.camel@zakaz.uk.xensource.com>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Xen Devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH V2 9/9] libxl: Allow migration with qemu-xen.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 09/25/2012 10:23 AM, Ian Campbell wrote:
> On Mon, 2012-09-17 at 19:22 +0100, Anthony PERARD wrote:
>> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
> 
> As far as I'm concerned you can just remove the entire check now, its
> only purpose was to catch this case.

Will do.

-- 
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 Sep 25 14:55:36 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 14:55:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGWXm-0005Cj-PQ; Tue, 25 Sep 2012 14:55:26 +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 1TGWXk-0005CJ-IY
	for xen-devel@lists.xen.org; Tue, 25 Sep 2012 14:55:24 +0000
Received: from [85.158.138.51:22094] by server-9.bemta-3.messagelabs.com id
	BB/95-15390-BD5C1605; Tue, 25 Sep 2012 14:55:23 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1348584919!13242131!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzEyNDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4989 invoked from network); 25 Sep 2012 14:55:22 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-13.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Sep 2012 14:55:22 -0000
X-IronPort-AV: E=Sophos;i="4.80,483,1344211200"; d="scan'208";a="39097372"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Sep 2012 14:53:57 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Tue, 25 Sep 2012 10:53:57 -0400
Received: from [10.80.3.61]	by ukmail1.uk.xensource.com with esmtp (Exim 4.69)
	(envelope-from <anthony.perard@citrix.com>)	id 1TGWWL-0007Ld-9R;
	Tue, 25 Sep 2012 15:53:57 +0100
Message-ID: <5061C585.9020106@citrix.com>
Date: Tue, 25 Sep 2012 15:53:57 +0100
From: Anthony PERARD <anthony.perard@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120910 Thunderbird/15.0.1
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <1347906148-9606-1-git-send-email-anthony.perard@citrix.com>
	<1347906148-9606-10-git-send-email-anthony.perard@citrix.com>
	<1348565023.3452.136.camel@zakaz.uk.xensource.com>
In-Reply-To: <1348565023.3452.136.camel@zakaz.uk.xensource.com>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Xen Devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH V2 9/9] libxl: Allow migration with qemu-xen.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 09/25/2012 10:23 AM, Ian Campbell wrote:
> On Mon, 2012-09-17 at 19:22 +0100, Anthony PERARD wrote:
>> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
> 
> As far as I'm concerned you can just remove the entire check now, its
> only purpose was to catch this case.

Will do.

-- 
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 Sep 25 15:01:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 15:01: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 1TGWdr-0005Zl-Jn; Tue, 25 Sep 2012 15:01: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 1TGWdq-0005Zg-LG
	for xen-devel@lists.xen.org; Tue, 25 Sep 2012 15:01:42 +0000
Received: from [85.158.139.211:43844] by server-1.bemta-5.messagelabs.com id
	15/E4-09825-557C1605; Tue, 25 Sep 2012 15:01:41 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-15.tower-206.messagelabs.com!1348585299!19964150!1
X-Originating-IP: [209.85.215.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8646 invoked from network); 25 Sep 2012 15:01:39 -0000
Received: from mail-ey0-f173.google.com (HELO mail-ey0-f173.google.com)
	(209.85.215.173)
	by server-15.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Sep 2012 15:01:39 -0000
Received: by eaaa1 with SMTP id a1so323076eaa.32
	for <xen-devel@lists.xen.org>; Tue, 25 Sep 2012 08:01:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=O5krq1mazUgHYOS4yOJbal9v2DC1alh8p5KsITV1x/k=;
	b=w+3R7Ta7hGNrryco3wFroqDG7daWqUmAiHfiu0yjEZJ/kcyKsdDjsbDM7J4S12xEDb
	xj/RO6bX3CmnnRPmUqShXiDd8ZcURSE1GE5coG1InZfW5XSnrEqlUTwqOh6CXyDJQPn5
	ReCTM1smYzCc3uxD5RbDSoUF0cKWRQN4hZQ0FN8pnmzws94zSwQEMA6ke5Ngl0IIZREp
	wBSsq9cFQDBKgFB3hto2ujqnBicoOrVX973lyZiWqjSNVUNXeiSPH341UGEfkFQKahux
	SU/PS7r9cYIbZoeyL/ANvZRx9n8GtyVbcXtFF0J+g0UBflLJD8r14ygx1DazvdTBKZQV
	gHaw==
Received: by 10.14.178.72 with SMTP id e48mr20874828eem.1.1348585299572;
	Tue, 25 Sep 2012 08:01:39 -0700 (PDT)
Received: from [192.168.1.3] (host86-167-82-156.range86-167.btcentralplus.com.
	[86.167.82.156])
	by mx.google.com with ESMTPS id e42sm1577764eem.8.2012.09.25.08.01.38
	(version=SSLv3 cipher=OTHER); Tue, 25 Sep 2012 08:01:39 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.33.0.120411
Date: Tue, 25 Sep 2012 16:01:32 +0100
From: Keir Fraser <keir@xen.org>
To: Andrew Cooper <andrew.cooper3@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <CC8785DC.4CD89%keir@xen.org>
Thread-Topic: [Xen-devel] RFC: EFER in crash notes
Thread-Index: Ac2bLqYIPZKs2v243km+nVA865RtRA==
In-Reply-To: <5061C556.60406@citrix.com>
Mime-version: 1.0
Cc: Jan Beulich <jbeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] RFC: EFER in crash notes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 25/09/2012 15:53, "Andrew Cooper" <andrew.cooper3@citrix.com> wrote:

>> I suppose the size field in the notes is a sort of rudimentary version
>> field. Remember you can always add a new note type though.
> 
> Yes, although looking through my code, I do raise an error if
> sizeof(note->desc) != sizeof(my structure representing this note), which
> was put in with the best of intentions, but will break with the this RFC
> change.
> 
> On the other hand, adding a new crash note for every new register will
> not scale well, as it is per PCU.
> 
> I guess the only sensible way to continue is to present a formal public ABI.

That seems a good idea.

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 25 15:01:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 15:01: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 1TGWdr-0005Zl-Jn; Tue, 25 Sep 2012 15:01: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 1TGWdq-0005Zg-LG
	for xen-devel@lists.xen.org; Tue, 25 Sep 2012 15:01:42 +0000
Received: from [85.158.139.211:43844] by server-1.bemta-5.messagelabs.com id
	15/E4-09825-557C1605; Tue, 25 Sep 2012 15:01:41 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-15.tower-206.messagelabs.com!1348585299!19964150!1
X-Originating-IP: [209.85.215.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8646 invoked from network); 25 Sep 2012 15:01:39 -0000
Received: from mail-ey0-f173.google.com (HELO mail-ey0-f173.google.com)
	(209.85.215.173)
	by server-15.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Sep 2012 15:01:39 -0000
Received: by eaaa1 with SMTP id a1so323076eaa.32
	for <xen-devel@lists.xen.org>; Tue, 25 Sep 2012 08:01:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=O5krq1mazUgHYOS4yOJbal9v2DC1alh8p5KsITV1x/k=;
	b=w+3R7Ta7hGNrryco3wFroqDG7daWqUmAiHfiu0yjEZJ/kcyKsdDjsbDM7J4S12xEDb
	xj/RO6bX3CmnnRPmUqShXiDd8ZcURSE1GE5coG1InZfW5XSnrEqlUTwqOh6CXyDJQPn5
	ReCTM1smYzCc3uxD5RbDSoUF0cKWRQN4hZQ0FN8pnmzws94zSwQEMA6ke5Ngl0IIZREp
	wBSsq9cFQDBKgFB3hto2ujqnBicoOrVX973lyZiWqjSNVUNXeiSPH341UGEfkFQKahux
	SU/PS7r9cYIbZoeyL/ANvZRx9n8GtyVbcXtFF0J+g0UBflLJD8r14ygx1DazvdTBKZQV
	gHaw==
Received: by 10.14.178.72 with SMTP id e48mr20874828eem.1.1348585299572;
	Tue, 25 Sep 2012 08:01:39 -0700 (PDT)
Received: from [192.168.1.3] (host86-167-82-156.range86-167.btcentralplus.com.
	[86.167.82.156])
	by mx.google.com with ESMTPS id e42sm1577764eem.8.2012.09.25.08.01.38
	(version=SSLv3 cipher=OTHER); Tue, 25 Sep 2012 08:01:39 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.33.0.120411
Date: Tue, 25 Sep 2012 16:01:32 +0100
From: Keir Fraser <keir@xen.org>
To: Andrew Cooper <andrew.cooper3@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <CC8785DC.4CD89%keir@xen.org>
Thread-Topic: [Xen-devel] RFC: EFER in crash notes
Thread-Index: Ac2bLqYIPZKs2v243km+nVA865RtRA==
In-Reply-To: <5061C556.60406@citrix.com>
Mime-version: 1.0
Cc: Jan Beulich <jbeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] RFC: EFER in crash notes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 25/09/2012 15:53, "Andrew Cooper" <andrew.cooper3@citrix.com> wrote:

>> I suppose the size field in the notes is a sort of rudimentary version
>> field. Remember you can always add a new note type though.
> 
> Yes, although looking through my code, I do raise an error if
> sizeof(note->desc) != sizeof(my structure representing this note), which
> was put in with the best of intentions, but will break with the this RFC
> change.
> 
> On the other hand, adding a new crash note for every new register will
> not scale well, as it is per PCU.
> 
> I guess the only sensible way to continue is to present a formal public ABI.

That seems a good idea.

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 25 15:07:22 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 15:07:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGWj7-0005m0-C5; Tue, 25 Sep 2012 15:07:09 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1TGWj6-0005lv-9K
	for xen-devel@lists.xen.org; Tue, 25 Sep 2012 15:07:08 +0000
Received: from [85.158.143.99:53802] by server-2.bemta-4.messagelabs.com id
	4F/9B-06610-B98C1605; Tue, 25 Sep 2012 15:07:07 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1348585626!31127936!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16601 invoked from network); 25 Sep 2012 15:07:06 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-3.tower-216.messagelabs.com with SMTP;
	25 Sep 2012 15:07:06 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 25 Sep 2012 16:07:06 +0100
Message-Id: <5061E4CF020000780009DB98@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 25 Sep 2012 16:07: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="=__Part2E1F12BF.0__="
Subject: [Xen-devel] [PATCH] x86: slightly improve stack trace on debug
	builds
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<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.

--=__Part2E1F12BF.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

As was rather obvious from crashes recently happening in stage testing,
the debug hypervisor, in that special case, has a drawback compared to
the non-debug one: When a call through a bad pointer happens, there's
no frame, and the top level (and frequently most important for
analysis) stack entry would get skipped:

(XEN) ----[ Xen-4.3-unstable  x86_64  debug=3Dy  Not tainted ]----
(XEN) CPU:    1
(XEN) RIP:    e008:[<0000000000000000>] ???
(XEN) RFLAGS: 0000000000010046   CONTEXT: hypervisor
(XEN) rax: 0000000000000008   rbx: 0000000000000001   rcx: 0000000000000003=

(XEN) rdx: 0000003db54eb700   rsi: 7fffffffffffffff   rdi: 0000000000000001=

(XEN) rbp: ffff8302357e7ee0   rsp: ffff8302357e7e58   r8:  0000000000000000=

(XEN) r9:  000000000000003e   r10: ffff8302357e7f18   r11: ffff8302357e7f18=

(XEN) r12: ffff8302357ee340   r13: ffff82c480263980   r14: ffff8302357ee3d0=

(XEN) r15: 0000000000000001   cr0: 000000008005003b   cr4: 00000000000026f0=

(XEN) cr3: 00000000bf473000   cr2: 0000000000000000
(XEN) ds: 0000   es: 0000   fs: 0000   gs: 0000   ss: 0000   cs: e008
(XEN) Xen stack trace from rsp=3Dffff8302357e7e58:
(XEN)    ffff82c4801a3d05 ffff8302357eca70 0000000800000020 ffff82c4802ead6=
0
(XEN)    0000000000000001 ffff8302357e7ea0 ffff82c48016bf07 000000000000000=
0
(XEN)    0000000000000000 ffff8302357e7ee0 fffff830fffff830 000000000000004=
6
(XEN)    ffff8302357e7f18 ffff82c480263980 ffff8302357e7f18 000000000000000=
0
(XEN)    0000000000000000 ffff8302357e7f10 ffff82c48015c2be 8302357dc0000ff=
f
...
(XEN) Xen call trace:
(XEN)    [<0000000000000000>] ???
(XEN)    [<ffff82c48015c2be>] idle_loop+0x6c/0x7a
(XEN)   =20
(XEN) Pagetable walk from 0000000000000000:

Since the bad pointer is being printed anyway (as part of the register
state), replace it with the top of stack value in such a case.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/arch/x86/traps.c
+++ b/xen/arch/x86/traps.c
@@ -217,8 +217,18 @@ static void show_trace(struct cpu_user_r
=20
     printk("Xen call trace:\n   ");
=20
-    printk("[<%p>]", _p(regs->eip));
-    print_symbol(" %s\n   ", regs->eip);
+    addr =3D regs->eip;
+    while ( !is_kernel_text(addr) &&
+            (system_state > SYS_STATE_boot || !is_kernel_inittext(addr)) =
)
+    {
+        /* Special case when a bad pointer was called. */
+        addr ^=3D regs->eip ^ *ESP_BEFORE_EXCEPTION(regs);
+        if ( addr =3D=3D regs->eip )
+            break;
+    }
+
+    printk("[<%p>]", _p(addr));
+    print_symbol(" %s\n   ", addr);
=20
     /* Bounds for range of valid frame pointer. */
     low  =3D (unsigned long)(ESP_BEFORE_EXCEPTION(regs) - 2);




--=__Part2E1F12BF.0__=
Content-Type: text/plain; name="x86-debug-dump-TOS.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="x86-debug-dump-TOS.patch"

x86: slightly improve stack trace on debug builds=0A=0AAs was rather =
obvious from crashes recently happening in stage testing,=0Athe debug =
hypervisor, in that special case, has a drawback compared to=0Athe =
non-debug one: When a call through a bad pointer happens, there's=0Ano =
frame, and the top level (and frequently most important for=0Aanalysis) =
stack entry would get skipped:=0A=0A(XEN) ----[ Xen-4.3-unstable  x86_64  =
debug=3Dy  Not tainted ]----=0A(XEN) CPU:    1=0A(XEN) RIP:    e008:[<00000=
00000000000>] ???=0A(XEN) RFLAGS: 0000000000010046   CONTEXT: hypervisor=0A=
(XEN) rax: 0000000000000008   rbx: 0000000000000001   rcx: 0000000000000003=
=0A(XEN) rdx: 0000003db54eb700   rsi: 7fffffffffffffff   rdi: 0000000000000=
001=0A(XEN) rbp: ffff8302357e7ee0   rsp: ffff8302357e7e58   r8:  0000000000=
000000=0A(XEN) r9:  000000000000003e   r10: ffff8302357e7f18   r11: =
ffff8302357e7f18=0A(XEN) r12: ffff8302357ee340   r13: ffff82c480263980   =
r14: ffff8302357ee3d0=0A(XEN) r15: 0000000000000001   cr0: 000000008005003b=
   cr4: 00000000000026f0=0A(XEN) cr3: 00000000bf473000   cr2: 0000000000000=
000=0A(XEN) ds: 0000   es: 0000   fs: 0000   gs: 0000   ss: 0000   cs: =
e008=0A(XEN) Xen stack trace from rsp=3Dffff8302357e7e58:=0A(XEN)    =
ffff82c4801a3d05 ffff8302357eca70 0000000800000020 ffff82c4802ead60=0A(XEN)=
    0000000000000001 ffff8302357e7ea0 ffff82c48016bf07 0000000000000000=0A(=
XEN)    0000000000000000 ffff8302357e7ee0 fffff830fffff830 0000000000000046=
=0A(XEN)    ffff8302357e7f18 ffff82c480263980 ffff8302357e7f18 000000000000=
0000=0A(XEN)    0000000000000000 ffff8302357e7f10 ffff82c48015c2be =
8302357dc0000fff=0A...=0A(XEN) Xen call trace:=0A(XEN)    [<000000000000000=
0>] ???=0A(XEN)    [<ffff82c48015c2be>] idle_loop+0x6c/0x7a=0A(XEN)    =
=0A(XEN) Pagetable walk from 0000000000000000:=0A=0ASince the bad pointer =
is being printed anyway (as part of the register=0Astate), replace it with =
the top of stack value in such a case.=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@@ -217,8 +217,18 @@ static void show_trace(struct cpu_user_r=0A =
=0A     printk("Xen call trace:\n   ");=0A =0A-    printk("[<%p>]", =
_p(regs->eip));=0A-    print_symbol(" %s\n   ", regs->eip);=0A+    addr =
=3D regs->eip;=0A+    while ( !is_kernel_text(addr) &&=0A+            =
(system_state > SYS_STATE_boot || !is_kernel_inittext(addr)) )=0A+    =
{=0A+        /* Special case when a bad pointer was called. */=0A+        =
addr ^=3D regs->eip ^ *ESP_BEFORE_EXCEPTION(regs);=0A+        if ( addr =
=3D=3D regs->eip )=0A+            break;=0A+    }=0A+=0A+    printk("[<%p>]=
", _p(addr));=0A+    print_symbol(" %s\n   ", addr);=0A =0A     /* Bounds =
for range of valid frame pointer. */=0A     low  =3D (unsigned long)(ESP_BE=
FORE_EXCEPTION(regs) - 2);=0A
--=__Part2E1F12BF.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

--=__Part2E1F12BF.0__=--


From xen-devel-bounces@lists.xen.org Tue Sep 25 15:07:22 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 15:07:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGWj7-0005m0-C5; Tue, 25 Sep 2012 15:07:09 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1TGWj6-0005lv-9K
	for xen-devel@lists.xen.org; Tue, 25 Sep 2012 15:07:08 +0000
Received: from [85.158.143.99:53802] by server-2.bemta-4.messagelabs.com id
	4F/9B-06610-B98C1605; Tue, 25 Sep 2012 15:07:07 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1348585626!31127936!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16601 invoked from network); 25 Sep 2012 15:07:06 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-3.tower-216.messagelabs.com with SMTP;
	25 Sep 2012 15:07:06 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 25 Sep 2012 16:07:06 +0100
Message-Id: <5061E4CF020000780009DB98@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 25 Sep 2012 16:07: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="=__Part2E1F12BF.0__="
Subject: [Xen-devel] [PATCH] x86: slightly improve stack trace on debug
	builds
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<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.

--=__Part2E1F12BF.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

As was rather obvious from crashes recently happening in stage testing,
the debug hypervisor, in that special case, has a drawback compared to
the non-debug one: When a call through a bad pointer happens, there's
no frame, and the top level (and frequently most important for
analysis) stack entry would get skipped:

(XEN) ----[ Xen-4.3-unstable  x86_64  debug=3Dy  Not tainted ]----
(XEN) CPU:    1
(XEN) RIP:    e008:[<0000000000000000>] ???
(XEN) RFLAGS: 0000000000010046   CONTEXT: hypervisor
(XEN) rax: 0000000000000008   rbx: 0000000000000001   rcx: 0000000000000003=

(XEN) rdx: 0000003db54eb700   rsi: 7fffffffffffffff   rdi: 0000000000000001=

(XEN) rbp: ffff8302357e7ee0   rsp: ffff8302357e7e58   r8:  0000000000000000=

(XEN) r9:  000000000000003e   r10: ffff8302357e7f18   r11: ffff8302357e7f18=

(XEN) r12: ffff8302357ee340   r13: ffff82c480263980   r14: ffff8302357ee3d0=

(XEN) r15: 0000000000000001   cr0: 000000008005003b   cr4: 00000000000026f0=

(XEN) cr3: 00000000bf473000   cr2: 0000000000000000
(XEN) ds: 0000   es: 0000   fs: 0000   gs: 0000   ss: 0000   cs: e008
(XEN) Xen stack trace from rsp=3Dffff8302357e7e58:
(XEN)    ffff82c4801a3d05 ffff8302357eca70 0000000800000020 ffff82c4802ead6=
0
(XEN)    0000000000000001 ffff8302357e7ea0 ffff82c48016bf07 000000000000000=
0
(XEN)    0000000000000000 ffff8302357e7ee0 fffff830fffff830 000000000000004=
6
(XEN)    ffff8302357e7f18 ffff82c480263980 ffff8302357e7f18 000000000000000=
0
(XEN)    0000000000000000 ffff8302357e7f10 ffff82c48015c2be 8302357dc0000ff=
f
...
(XEN) Xen call trace:
(XEN)    [<0000000000000000>] ???
(XEN)    [<ffff82c48015c2be>] idle_loop+0x6c/0x7a
(XEN)   =20
(XEN) Pagetable walk from 0000000000000000:

Since the bad pointer is being printed anyway (as part of the register
state), replace it with the top of stack value in such a case.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/arch/x86/traps.c
+++ b/xen/arch/x86/traps.c
@@ -217,8 +217,18 @@ static void show_trace(struct cpu_user_r
=20
     printk("Xen call trace:\n   ");
=20
-    printk("[<%p>]", _p(regs->eip));
-    print_symbol(" %s\n   ", regs->eip);
+    addr =3D regs->eip;
+    while ( !is_kernel_text(addr) &&
+            (system_state > SYS_STATE_boot || !is_kernel_inittext(addr)) =
)
+    {
+        /* Special case when a bad pointer was called. */
+        addr ^=3D regs->eip ^ *ESP_BEFORE_EXCEPTION(regs);
+        if ( addr =3D=3D regs->eip )
+            break;
+    }
+
+    printk("[<%p>]", _p(addr));
+    print_symbol(" %s\n   ", addr);
=20
     /* Bounds for range of valid frame pointer. */
     low  =3D (unsigned long)(ESP_BEFORE_EXCEPTION(regs) - 2);




--=__Part2E1F12BF.0__=
Content-Type: text/plain; name="x86-debug-dump-TOS.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="x86-debug-dump-TOS.patch"

x86: slightly improve stack trace on debug builds=0A=0AAs was rather =
obvious from crashes recently happening in stage testing,=0Athe debug =
hypervisor, in that special case, has a drawback compared to=0Athe =
non-debug one: When a call through a bad pointer happens, there's=0Ano =
frame, and the top level (and frequently most important for=0Aanalysis) =
stack entry would get skipped:=0A=0A(XEN) ----[ Xen-4.3-unstable  x86_64  =
debug=3Dy  Not tainted ]----=0A(XEN) CPU:    1=0A(XEN) RIP:    e008:[<00000=
00000000000>] ???=0A(XEN) RFLAGS: 0000000000010046   CONTEXT: hypervisor=0A=
(XEN) rax: 0000000000000008   rbx: 0000000000000001   rcx: 0000000000000003=
=0A(XEN) rdx: 0000003db54eb700   rsi: 7fffffffffffffff   rdi: 0000000000000=
001=0A(XEN) rbp: ffff8302357e7ee0   rsp: ffff8302357e7e58   r8:  0000000000=
000000=0A(XEN) r9:  000000000000003e   r10: ffff8302357e7f18   r11: =
ffff8302357e7f18=0A(XEN) r12: ffff8302357ee340   r13: ffff82c480263980   =
r14: ffff8302357ee3d0=0A(XEN) r15: 0000000000000001   cr0: 000000008005003b=
   cr4: 00000000000026f0=0A(XEN) cr3: 00000000bf473000   cr2: 0000000000000=
000=0A(XEN) ds: 0000   es: 0000   fs: 0000   gs: 0000   ss: 0000   cs: =
e008=0A(XEN) Xen stack trace from rsp=3Dffff8302357e7e58:=0A(XEN)    =
ffff82c4801a3d05 ffff8302357eca70 0000000800000020 ffff82c4802ead60=0A(XEN)=
    0000000000000001 ffff8302357e7ea0 ffff82c48016bf07 0000000000000000=0A(=
XEN)    0000000000000000 ffff8302357e7ee0 fffff830fffff830 0000000000000046=
=0A(XEN)    ffff8302357e7f18 ffff82c480263980 ffff8302357e7f18 000000000000=
0000=0A(XEN)    0000000000000000 ffff8302357e7f10 ffff82c48015c2be =
8302357dc0000fff=0A...=0A(XEN) Xen call trace:=0A(XEN)    [<000000000000000=
0>] ???=0A(XEN)    [<ffff82c48015c2be>] idle_loop+0x6c/0x7a=0A(XEN)    =
=0A(XEN) Pagetable walk from 0000000000000000:=0A=0ASince the bad pointer =
is being printed anyway (as part of the register=0Astate), replace it with =
the top of stack value in such a case.=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@@ -217,8 +217,18 @@ static void show_trace(struct cpu_user_r=0A =
=0A     printk("Xen call trace:\n   ");=0A =0A-    printk("[<%p>]", =
_p(regs->eip));=0A-    print_symbol(" %s\n   ", regs->eip);=0A+    addr =
=3D regs->eip;=0A+    while ( !is_kernel_text(addr) &&=0A+            =
(system_state > SYS_STATE_boot || !is_kernel_inittext(addr)) )=0A+    =
{=0A+        /* Special case when a bad pointer was called. */=0A+        =
addr ^=3D regs->eip ^ *ESP_BEFORE_EXCEPTION(regs);=0A+        if ( addr =
=3D=3D regs->eip )=0A+            break;=0A+    }=0A+=0A+    printk("[<%p>]=
", _p(addr));=0A+    print_symbol(" %s\n   ", addr);=0A =0A     /* Bounds =
for range of valid frame pointer. */=0A     low  =3D (unsigned long)(ESP_BE=
FORE_EXCEPTION(regs) - 2);=0A
--=__Part2E1F12BF.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

--=__Part2E1F12BF.0__=--


From xen-devel-bounces@lists.xen.org Tue Sep 25 15:10:44 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 15:10:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGWmM-0005yU-Vs; Tue, 25 Sep 2012 15:10:30 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1TGWmL-0005yD-4i
	for xen-devel@lists.xen.org; Tue, 25 Sep 2012 15:10:29 +0000
Received: from [85.158.143.99:33141] by server-1.bemta-4.messagelabs.com id
	25/61-05684-469C1605; Tue, 25 Sep 2012 15:10:28 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1348585826!21940542!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8313 invoked from network); 25 Sep 2012 15:10:27 -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;
	25 Sep 2012 15:10:27 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 25 Sep 2012 16:10:27 +0100
Message-Id: <5061E599020000780009DBA4@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 25 Sep 2012 16:10:49 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ben Guthro" <ben@guthro.net>
References: <CAOvdn6UCF2A3yP1cqWn=dxwr0ayRbr+rg+xj8META9Dm0+CoNw@mail.gmail.com>
	<CC868168.3FD29%keir.xen@gmail.com>
	<CAOvdn6U-JyLvt96gkLkqzi088tU9_ktv4D+fkJac_BKVe05Y-w@mail.gmail.com>
	<CAOvdn6V+s3AbRzsu8VArbmrZou=im9SqvPf-9Wpif_BrNMv=yg@mail.gmail.com>
	<50617297020000780009D8AA@nat28.tlf.novell.com>
	<CAOvdn6Vsnbcd7m8mh3tSgn3KaEoeiOyVD1mr3uQ3bN=rF=pDUQ@mail.gmail.com>
	<CAOvdn6X6_NwfTNTgwNG7CQOqu2oDb6o6r1Zf+5y0cwZGLKToxA@mail.gmail.com>
In-Reply-To: <CAOvdn6X6_NwfTNTgwNG7CQOqu2oDb6o6r1Zf+5y0cwZGLKToxA@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Keir Fraser <keir.xen@gmail.com>, John Baboval <john.baboval@citrix.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen4.2 S3 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 25.09.12 at 16:22, Ben Guthro <ben@guthro.net> wrote:
> I went back to an old patch that had, since it was in this same function
> that you made reference to:
> http://markmail.org/message/qpnmiqzt5bngeejk 
> 
> I noticed that I was not seeing the "Breaking vcpu affinity" printk - so I
> tried to get that
> 
> The change proposed in that thread seems to work around this pinning
> problem.
> However, I'm not sure that it is the "right thing" to be doing.

As said back then, the original change looks a little suspicious,
and hence reverting it is certainly to be considered.

However, I don't see yet how this is connected to you having
a problem only with pinned vCPU-s.

But - with S3 working again (with the change here) or originally,
did you ever check whether post-resume Dom0 vCPU-s would
still be pinned? I suspect they aren't, and hence addressing the
crash may likely be achieved by properly restoring the pinning.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 25 15:10:44 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 15:10:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGWmM-0005yU-Vs; Tue, 25 Sep 2012 15:10:30 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1TGWmL-0005yD-4i
	for xen-devel@lists.xen.org; Tue, 25 Sep 2012 15:10:29 +0000
Received: from [85.158.143.99:33141] by server-1.bemta-4.messagelabs.com id
	25/61-05684-469C1605; Tue, 25 Sep 2012 15:10:28 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1348585826!21940542!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8313 invoked from network); 25 Sep 2012 15:10:27 -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;
	25 Sep 2012 15:10:27 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 25 Sep 2012 16:10:27 +0100
Message-Id: <5061E599020000780009DBA4@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 25 Sep 2012 16:10:49 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ben Guthro" <ben@guthro.net>
References: <CAOvdn6UCF2A3yP1cqWn=dxwr0ayRbr+rg+xj8META9Dm0+CoNw@mail.gmail.com>
	<CC868168.3FD29%keir.xen@gmail.com>
	<CAOvdn6U-JyLvt96gkLkqzi088tU9_ktv4D+fkJac_BKVe05Y-w@mail.gmail.com>
	<CAOvdn6V+s3AbRzsu8VArbmrZou=im9SqvPf-9Wpif_BrNMv=yg@mail.gmail.com>
	<50617297020000780009D8AA@nat28.tlf.novell.com>
	<CAOvdn6Vsnbcd7m8mh3tSgn3KaEoeiOyVD1mr3uQ3bN=rF=pDUQ@mail.gmail.com>
	<CAOvdn6X6_NwfTNTgwNG7CQOqu2oDb6o6r1Zf+5y0cwZGLKToxA@mail.gmail.com>
In-Reply-To: <CAOvdn6X6_NwfTNTgwNG7CQOqu2oDb6o6r1Zf+5y0cwZGLKToxA@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Keir Fraser <keir.xen@gmail.com>, John Baboval <john.baboval@citrix.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen4.2 S3 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 25.09.12 at 16:22, Ben Guthro <ben@guthro.net> wrote:
> I went back to an old patch that had, since it was in this same function
> that you made reference to:
> http://markmail.org/message/qpnmiqzt5bngeejk 
> 
> I noticed that I was not seeing the "Breaking vcpu affinity" printk - so I
> tried to get that
> 
> The change proposed in that thread seems to work around this pinning
> problem.
> However, I'm not sure that it is the "right thing" to be doing.

As said back then, the original change looks a little suspicious,
and hence reverting it is certainly to be considered.

However, I don't see yet how this is connected to you having
a problem only with pinned vCPU-s.

But - with S3 working again (with the change here) or originally,
did you ever check whether post-resume Dom0 vCPU-s would
still be pinned? I suspect they aren't, and hence addressing the
crash may likely be achieved by properly restoring the pinning.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 25 15:12:07 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 15:12: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 1TGWng-00064Z-ES; Tue, 25 Sep 2012 15:11:52 +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 1TGWnf-00064Q-HT
	for xen-devel@lists.xensource.com; Tue, 25 Sep 2012 15:11:51 +0000
Received: from [85.158.143.35:18726] by server-3.bemta-4.messagelabs.com id
	4B/14-10986-6B9C1605; Tue, 25 Sep 2012 15:11:50 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-6.tower-21.messagelabs.com!1348585910!19823320!1
X-Originating-IP: [188.40.164.121]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17480 invoked from network); 25 Sep 2012 15:11:50 -0000
Received: from static.121.164.40.188.clients.your-server.de (HELO
	smtp.eikelenboom.it) (188.40.164.121)
	by server-6.tower-21.messagelabs.com with AES256-SHA encrypted SMTP;
	25 Sep 2012 15:11:50 -0000
Received: from 132-64-ftth.onsneteindhoven.nl ([88.159.64.132]:51353
	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 1TGWoL-0007Lg-46; Tue, 25 Sep 2012 17:12:33 +0200
Date: Tue, 25 Sep 2012 17:11:43 +0200
From: Sander Eikelenboom <linux@eikelenboom.it>
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <15210025463.20120925171143@eikelenboom.it>
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1348565712.3452.141.camel@zakaz.uk.xensource.com>
References: <patchbomb.1346960486@xentest.example.org>
	<1348565712.3452.141.camel@zakaz.uk.xensource.com>
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 0 of 3] xl and hotplug: Introduce and use
	shutdown and reboot xm compatibility options
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


Tuesday, September 25, 2012, 11:35:12 AM, you wrote:

> On Thu, 2012-09-06 at 20:41 +0100, Sander Eikelenboom wrote:
>> The /etc/init.d/xendomains script makes use of options for the
>> shutdown command defined in xendomains-sysconfig/default.
>> These options were not implemented in xl, this patch series implements
>> the options and by using the short variant makes it compatible with
>> both xm and xl.
>> 
>> Signed-off-by: Sander Eikelenboom <linux@eikelenboom.it>

> Hi Sander,

> Are you still looking into the review feedback on these patches?

> Ian.

Hi Ian,

Yes but had a little time last week and i'm a bit stuck on IanJ's comment  :-(


> This isn't quite right, I think.  Surely it should initiate the
> shutdown for all the domains right away, and then wait for them all to
> finish ?
>
> That's going to make the patch more complicated of course...
>
> Ian.

The only relative simple implementation i thought of was direct shutting down all, and when the -w parameter was set, just loop and wait on events until the only running domain is domain-0.
Although this exactly does what has to be done, it somehow sounds a bit dirty.


--
Sander


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 25 15:12:07 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 15:12: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 1TGWng-00064Z-ES; Tue, 25 Sep 2012 15:11:52 +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 1TGWnf-00064Q-HT
	for xen-devel@lists.xensource.com; Tue, 25 Sep 2012 15:11:51 +0000
Received: from [85.158.143.35:18726] by server-3.bemta-4.messagelabs.com id
	4B/14-10986-6B9C1605; Tue, 25 Sep 2012 15:11:50 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-6.tower-21.messagelabs.com!1348585910!19823320!1
X-Originating-IP: [188.40.164.121]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17480 invoked from network); 25 Sep 2012 15:11:50 -0000
Received: from static.121.164.40.188.clients.your-server.de (HELO
	smtp.eikelenboom.it) (188.40.164.121)
	by server-6.tower-21.messagelabs.com with AES256-SHA encrypted SMTP;
	25 Sep 2012 15:11:50 -0000
Received: from 132-64-ftth.onsneteindhoven.nl ([88.159.64.132]:51353
	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 1TGWoL-0007Lg-46; Tue, 25 Sep 2012 17:12:33 +0200
Date: Tue, 25 Sep 2012 17:11:43 +0200
From: Sander Eikelenboom <linux@eikelenboom.it>
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <15210025463.20120925171143@eikelenboom.it>
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1348565712.3452.141.camel@zakaz.uk.xensource.com>
References: <patchbomb.1346960486@xentest.example.org>
	<1348565712.3452.141.camel@zakaz.uk.xensource.com>
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 0 of 3] xl and hotplug: Introduce and use
	shutdown and reboot xm compatibility options
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


Tuesday, September 25, 2012, 11:35:12 AM, you wrote:

> On Thu, 2012-09-06 at 20:41 +0100, Sander Eikelenboom wrote:
>> The /etc/init.d/xendomains script makes use of options for the
>> shutdown command defined in xendomains-sysconfig/default.
>> These options were not implemented in xl, this patch series implements
>> the options and by using the short variant makes it compatible with
>> both xm and xl.
>> 
>> Signed-off-by: Sander Eikelenboom <linux@eikelenboom.it>

> Hi Sander,

> Are you still looking into the review feedback on these patches?

> Ian.

Hi Ian,

Yes but had a little time last week and i'm a bit stuck on IanJ's comment  :-(


> This isn't quite right, I think.  Surely it should initiate the
> shutdown for all the domains right away, and then wait for them all to
> finish ?
>
> That's going to make the patch more complicated of course...
>
> Ian.

The only relative simple implementation i thought of was direct shutting down all, and when the -w parameter was set, just loop and wait on events until the only running domain is domain-0.
Although this exactly does what has to be done, it somehow sounds a bit dirty.


--
Sander


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 25 15:17:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 15:17:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGWtK-0006JF-8L; Tue, 25 Sep 2012 15:17:42 +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 1TGWtJ-0006JA-5E
	for xen-devel@lists.xen.org; Tue, 25 Sep 2012 15:17:41 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1348586255!6233969!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTEwNzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21762 invoked from network); 25 Sep 2012 15:17:35 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Sep 2012 15:17:35 -0000
X-IronPort-AV: E=Sophos;i="4.80,484,1344211200"; d="scan'208";a="14754716"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Sep 2012 15:17: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.279.1;
	Tue, 25 Sep 2012 16:17:34 +0100
Message-ID: <1348586253.11229.29.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Date: Tue, 25 Sep 2012 16:17:33 +0100
In-Reply-To: <5061C556.60406@citrix.com>
References: <5061BD4E.6000905@citrix.com>
	<1348583626.11229.26.camel@zakaz.uk.xensource.com>
	<5061C556.60406@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-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] RFC: EFER in crash notes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-09-25 at 15:53 +0100, Andrew Cooper wrote:
> On 25/09/12 15:33, Ian Campbell wrote:
> > On Tue, 2012-09-25 at 15:18 +0100, Andrew Cooper wrote:
> >> While this patch is very simple, and I hope without any objection, it is
> >> RFC for the reason that our crash ABI is private.
> >>
> >> The comments for XEN_ELFNOTE_CRASH_REGS does state that it is
> >> architecture specific, and makes no indication about the size or
> >> contents of the crash note.  However, any code trying to use one of
> >> these types of notes has to make an assumption that it if the note desc
> >> length is 4*8 bytes long, it is representing CR{0,2-4}.
> >>
> >> I guess my question boils down to whether it is acceptable to change a
> >> private ABI which is not really so private, or whether we should make a
> >> formal public ABI for all of the inards of the crash notes and use that.
> > Is it really private? (or even "not so private"), don't external tools
> > like crash support it?
> 
> This is my point.  It is not in xen/public but is used by crash/kdump
> and similar utilities, effectively making it a public ABI.
> 
> include/public/elfnote.h even explicitly refers to
> include/xen/elfcore.h, which is not public by our definition.

Hrm, I think it is public despite its location.

> 
> >
> > I suppose the size field in the notes is a sort of rudimentary version
> > field. Remember you can always add a new note type though.
> 
> Yes, although looking through my code, I do raise an error if
> sizeof(note->desc) != sizeof(my structure representing this note), which
> was put in with the best of intentions, but will break with the this RFC
> change.
> 
> On the other hand, adding a new crash note for every new register will
> not scale well, as it is per PCU.

A new note for every batch of registers is what I was thinking. Or a new
note with a more extensible structure.

> 
> I guess the only sensible way to continue is to present a formal public ABI.
> 
> >
> > Ian.
> >
> >



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 25 15:17:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 15:17:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGWtK-0006JF-8L; Tue, 25 Sep 2012 15:17:42 +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 1TGWtJ-0006JA-5E
	for xen-devel@lists.xen.org; Tue, 25 Sep 2012 15:17:41 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1348586255!6233969!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTEwNzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21762 invoked from network); 25 Sep 2012 15:17:35 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Sep 2012 15:17:35 -0000
X-IronPort-AV: E=Sophos;i="4.80,484,1344211200"; d="scan'208";a="14754716"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Sep 2012 15:17: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.279.1;
	Tue, 25 Sep 2012 16:17:34 +0100
Message-ID: <1348586253.11229.29.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Date: Tue, 25 Sep 2012 16:17:33 +0100
In-Reply-To: <5061C556.60406@citrix.com>
References: <5061BD4E.6000905@citrix.com>
	<1348583626.11229.26.camel@zakaz.uk.xensource.com>
	<5061C556.60406@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-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] RFC: EFER in crash notes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-09-25 at 15:53 +0100, Andrew Cooper wrote:
> On 25/09/12 15:33, Ian Campbell wrote:
> > On Tue, 2012-09-25 at 15:18 +0100, Andrew Cooper wrote:
> >> While this patch is very simple, and I hope without any objection, it is
> >> RFC for the reason that our crash ABI is private.
> >>
> >> The comments for XEN_ELFNOTE_CRASH_REGS does state that it is
> >> architecture specific, and makes no indication about the size or
> >> contents of the crash note.  However, any code trying to use one of
> >> these types of notes has to make an assumption that it if the note desc
> >> length is 4*8 bytes long, it is representing CR{0,2-4}.
> >>
> >> I guess my question boils down to whether it is acceptable to change a
> >> private ABI which is not really so private, or whether we should make a
> >> formal public ABI for all of the inards of the crash notes and use that.
> > Is it really private? (or even "not so private"), don't external tools
> > like crash support it?
> 
> This is my point.  It is not in xen/public but is used by crash/kdump
> and similar utilities, effectively making it a public ABI.
> 
> include/public/elfnote.h even explicitly refers to
> include/xen/elfcore.h, which is not public by our definition.

Hrm, I think it is public despite its location.

> 
> >
> > I suppose the size field in the notes is a sort of rudimentary version
> > field. Remember you can always add a new note type though.
> 
> Yes, although looking through my code, I do raise an error if
> sizeof(note->desc) != sizeof(my structure representing this note), which
> was put in with the best of intentions, but will break with the this RFC
> change.
> 
> On the other hand, adding a new crash note for every new register will
> not scale well, as it is per PCU.

A new note for every batch of registers is what I was thinking. Or a new
note with a more extensible structure.

> 
> I guess the only sensible way to continue is to present a formal public ABI.
> 
> >
> > Ian.
> >
> >



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 25 15:18:55 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 15:18:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGWuL-0006NA-Mp; Tue, 25 Sep 2012 15:18: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 1TGWuK-0006N2-2D
	for xen-devel@lists.xensource.com; Tue, 25 Sep 2012 15:18:44 +0000
Received: from [85.158.143.99:41568] by server-2.bemta-4.messagelabs.com id
	7B/AC-06610-35BC1605; Tue, 25 Sep 2012 15:18:43 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1348586322!31385182!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTEwNzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26929 invoked from network); 25 Sep 2012 15:18:43 -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;
	25 Sep 2012 15:18:43 -0000
X-IronPort-AV: E=Sophos;i="4.80,484,1344211200"; d="scan'208";a="14754737"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Sep 2012 15: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.279.1;
	Tue, 25 Sep 2012 16:18:42 +0100
Message-ID: <1348586321.12592.0.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: George Dunlap <george.dunlap@eu.citrix.com>
Date: Tue, 25 Sep 2012 16:18:41 +0100
In-Reply-To: <7e332fd064fac8d9d1ce.1348499997@elijah>
References: <7e332fd064fac8d9d1ce.1348499997@elijah>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] docs: Document scheduler-related Xen
 command-line options
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2012-09-24 at 16:19 +0100, George Dunlap wrote:
> # HG changeset patch
> # User George Dunlap <george.dunlap@eu.citrix.com>
> # Date 1348499935 -3600
> # Node ID 7e332fd064fac8d9d1cea904d5236c8d74389194
> # Parent  7b045d43e59dcb42340097058502bf456e151180
> docs: Document scheduler-related Xen command-line options
> 
> Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>

Acked-by: Ian Campbell <ian.campbell@citrix.com>

> 
> diff --git a/docs/misc/xen-command-line.markdown b/docs/misc/xen-command-line.markdown
> --- a/docs/misc/xen-command-line.markdown
> +++ b/docs/misc/xen-command-line.markdown
> @@ -732,12 +732,34 @@ Choose the default scheduler.
>  ### sched\_credit\_tslice\_ms
>  > `= <integer>`
>  
> +Set the timeslice of the credit1 scheduler, in milliseconds.  The
> +default is 30ms.  Reasonable values may include 10, 5, or even 1 for
> +very latency-sensitive workloads.
> +
>  ### sched\_ratelimit\_us
>  > `= <integer>`
>  
> +In order to limit the rate of context switching, set the minimum
> +amount of time that a vcpu can be scheduled for before preempting it,
> +in microseconds.  The default is 1000us (1ms).  Setting this to 0
> +disables it altogether.
> +
>  ### sched\_smt\_power\_savings
>  > `= <boolean>`
>  
> +Normally Xen will try to maximize performance and cache utilization by
> +spreading out vcpus across as many different divisions as possible
> +(i.e, numa nodes, sockets, cores threads, &c).  This often maximizes
> +throughput, but also maximizes energy usage, since it reduces the
> +depth to which a processor can sleep.
> +
> +This option inverts the logic, so that the scheduler in effect tries
> +to keep the vcpus on the smallest amount of silicon possible; i.e.,
> +first fill up sibling threads, then sibling cores, then sibling
> +sockets, &c.  This will reduce performance somewhat, particularly on
> +systems with hyperthreading enabled, but should reduce power by
> +enabling more sockets and cores to go into deeper sleep states.
> +
>  ### serial\_tx\_buffer
>  > `= <size>`
>  
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel





_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 25 15:18:55 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 15:18:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGWuL-0006NA-Mp; Tue, 25 Sep 2012 15:18: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 1TGWuK-0006N2-2D
	for xen-devel@lists.xensource.com; Tue, 25 Sep 2012 15:18:44 +0000
Received: from [85.158.143.99:41568] by server-2.bemta-4.messagelabs.com id
	7B/AC-06610-35BC1605; Tue, 25 Sep 2012 15:18:43 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1348586322!31385182!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTEwNzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26929 invoked from network); 25 Sep 2012 15:18:43 -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;
	25 Sep 2012 15:18:43 -0000
X-IronPort-AV: E=Sophos;i="4.80,484,1344211200"; d="scan'208";a="14754737"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Sep 2012 15: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.279.1;
	Tue, 25 Sep 2012 16:18:42 +0100
Message-ID: <1348586321.12592.0.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: George Dunlap <george.dunlap@eu.citrix.com>
Date: Tue, 25 Sep 2012 16:18:41 +0100
In-Reply-To: <7e332fd064fac8d9d1ce.1348499997@elijah>
References: <7e332fd064fac8d9d1ce.1348499997@elijah>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] docs: Document scheduler-related Xen
 command-line options
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 2012-09-24 at 16:19 +0100, George Dunlap wrote:
> # HG changeset patch
> # User George Dunlap <george.dunlap@eu.citrix.com>
> # Date 1348499935 -3600
> # Node ID 7e332fd064fac8d9d1cea904d5236c8d74389194
> # Parent  7b045d43e59dcb42340097058502bf456e151180
> docs: Document scheduler-related Xen command-line options
> 
> Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>

Acked-by: Ian Campbell <ian.campbell@citrix.com>

> 
> diff --git a/docs/misc/xen-command-line.markdown b/docs/misc/xen-command-line.markdown
> --- a/docs/misc/xen-command-line.markdown
> +++ b/docs/misc/xen-command-line.markdown
> @@ -732,12 +732,34 @@ Choose the default scheduler.
>  ### sched\_credit\_tslice\_ms
>  > `= <integer>`
>  
> +Set the timeslice of the credit1 scheduler, in milliseconds.  The
> +default is 30ms.  Reasonable values may include 10, 5, or even 1 for
> +very latency-sensitive workloads.
> +
>  ### sched\_ratelimit\_us
>  > `= <integer>`
>  
> +In order to limit the rate of context switching, set the minimum
> +amount of time that a vcpu can be scheduled for before preempting it,
> +in microseconds.  The default is 1000us (1ms).  Setting this to 0
> +disables it altogether.
> +
>  ### sched\_smt\_power\_savings
>  > `= <boolean>`
>  
> +Normally Xen will try to maximize performance and cache utilization by
> +spreading out vcpus across as many different divisions as possible
> +(i.e, numa nodes, sockets, cores threads, &c).  This often maximizes
> +throughput, but also maximizes energy usage, since it reduces the
> +depth to which a processor can sleep.
> +
> +This option inverts the logic, so that the scheduler in effect tries
> +to keep the vcpus on the smallest amount of silicon possible; i.e.,
> +first fill up sibling threads, then sibling cores, then sibling
> +sockets, &c.  This will reduce performance somewhat, particularly on
> +systems with hyperthreading enabled, but should reduce power by
> +enabling more sockets and cores to go into deeper sleep states.
> +
>  ### serial\_tx\_buffer
>  > `= <size>`
>  
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel





_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 25 15:21:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 15:21:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGWwI-0006Ww-Bf; Tue, 25 Sep 2012 15:20:46 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1TGWwH-0006Wm-6E
	for xen-devel@lists.xen.org; Tue, 25 Sep 2012 15:20:45 +0000
Received: from [85.158.143.35:27413] by server-2.bemta-4.messagelabs.com id
	31/8F-06610-CCBC1605; Tue, 25 Sep 2012 15:20:44 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1348586442!4081187!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20433 invoked from network); 25 Sep 2012 15:20:42 -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;
	25 Sep 2012 15:20:42 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 25 Sep 2012 16:20:41 +0100
Message-Id: <5061E800020000780009DBBA@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 25 Sep 2012 16:21:04 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Javier Marcet" <jmarcet@gmail.com>
References: <CC8273A0.4C9DD%keir@xen.org>
	<50605E9A020000780009D486@nat28.tlf.novell.com>
	<CAOvdn6XmB6rj3_QVU+59V8p24Y5G47AWxVEM=id02JWXkuhibQ@mail.gmail.com>
	<5060640B020000780009D4D2@nat28.tlf.novell.com>
	<CAOvdn6XLy8zR2rb2MEyi2aT9LQiFvFLY_H02p181mTsVLVTZkw@mail.gmail.com>
	<20120924122203.GG8912@reaktio.net>
	<CAOvdn6XV4eoA-FfFns1xhx7HCUqXc7KHxZwyKuT4FHG8s3R5RQ@mail.gmail.com>
	<CAAnFQG9PLQjdh6Ab6=Y5ZGM1s4nGdLekKU=pcKNMxt4rmt_RKA@mail.gmail.com>
	<20120924140411.GH31618@phenom.dumpdata.com>
	<CAAnFQG-tjv5UyF6j-TNHNgme2c4vA0Zxy8AdCiJEVsf2Z0quNA@mail.gmail.com>
	<20120925140611.GB16478@phenom.dumpdata.com>
	<CAAnFQG88ApxKuscXx53Lt2qOyCe0ws6oXSSqBDfW0+oYo5Y3nA@mail.gmail.com>
In-Reply-To: <CAAnFQG88ApxKuscXx53Lt2qOyCe0ws6oXSSqBDfW0+oYo5Y3nA@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Keir Fraser <keir@xen.org>, john.baboval@citrix.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	xen-devel <xen-devel@lists.xen.org>,
	Konrad Rzeszutek Wilk <konrad@kernel.org>, Ben Guthro <ben@guthro.net>,
	Thomas Goetz <thomas.goetz@citrix.com>
Subject: Re: [Xen-devel] Xen4.2 S3 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 25.09.12 at 16:47, Javier Marcet <jmarcet@gmail.com> wrote:
> I haven't been able to see the actual patch, I only read a description
> of what it should do. Two possible places where a wbinvd() call should
> be added. On the first of these two places there were already calls to
> wbinvd() just before the halts. I added it to the other one, within
> xen/arch/x86/domain.c:default_idle and I could complete a
> suspend/resume cycle without the back trace but after rebooting I
> tried it again and it failed, more than once.

default_idle() isn't the right place, default_dead_idle() is.

See
http://xenbits.xen.org/hg/staging/xen-unstable.hg/rev/c8d65d91a6f2

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 25 15:21:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 15:21:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGWwI-0006Ww-Bf; Tue, 25 Sep 2012 15:20:46 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1TGWwH-0006Wm-6E
	for xen-devel@lists.xen.org; Tue, 25 Sep 2012 15:20:45 +0000
Received: from [85.158.143.35:27413] by server-2.bemta-4.messagelabs.com id
	31/8F-06610-CCBC1605; Tue, 25 Sep 2012 15:20:44 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1348586442!4081187!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20433 invoked from network); 25 Sep 2012 15:20:42 -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;
	25 Sep 2012 15:20:42 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 25 Sep 2012 16:20:41 +0100
Message-Id: <5061E800020000780009DBBA@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 25 Sep 2012 16:21:04 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Javier Marcet" <jmarcet@gmail.com>
References: <CC8273A0.4C9DD%keir@xen.org>
	<50605E9A020000780009D486@nat28.tlf.novell.com>
	<CAOvdn6XmB6rj3_QVU+59V8p24Y5G47AWxVEM=id02JWXkuhibQ@mail.gmail.com>
	<5060640B020000780009D4D2@nat28.tlf.novell.com>
	<CAOvdn6XLy8zR2rb2MEyi2aT9LQiFvFLY_H02p181mTsVLVTZkw@mail.gmail.com>
	<20120924122203.GG8912@reaktio.net>
	<CAOvdn6XV4eoA-FfFns1xhx7HCUqXc7KHxZwyKuT4FHG8s3R5RQ@mail.gmail.com>
	<CAAnFQG9PLQjdh6Ab6=Y5ZGM1s4nGdLekKU=pcKNMxt4rmt_RKA@mail.gmail.com>
	<20120924140411.GH31618@phenom.dumpdata.com>
	<CAAnFQG-tjv5UyF6j-TNHNgme2c4vA0Zxy8AdCiJEVsf2Z0quNA@mail.gmail.com>
	<20120925140611.GB16478@phenom.dumpdata.com>
	<CAAnFQG88ApxKuscXx53Lt2qOyCe0ws6oXSSqBDfW0+oYo5Y3nA@mail.gmail.com>
In-Reply-To: <CAAnFQG88ApxKuscXx53Lt2qOyCe0ws6oXSSqBDfW0+oYo5Y3nA@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Keir Fraser <keir@xen.org>, john.baboval@citrix.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	xen-devel <xen-devel@lists.xen.org>,
	Konrad Rzeszutek Wilk <konrad@kernel.org>, Ben Guthro <ben@guthro.net>,
	Thomas Goetz <thomas.goetz@citrix.com>
Subject: Re: [Xen-devel] Xen4.2 S3 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 25.09.12 at 16:47, Javier Marcet <jmarcet@gmail.com> wrote:
> I haven't been able to see the actual patch, I only read a description
> of what it should do. Two possible places where a wbinvd() call should
> be added. On the first of these two places there were already calls to
> wbinvd() just before the halts. I added it to the other one, within
> xen/arch/x86/domain.c:default_idle and I could complete a
> suspend/resume cycle without the back trace but after rebooting I
> tried it again and it failed, more than once.

default_idle() isn't the right place, default_dead_idle() is.

See
http://xenbits.xen.org/hg/staging/xen-unstable.hg/rev/c8d65d91a6f2

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 25 15:24:22 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 15:24:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGWzZ-0006jk-Vz; Tue, 25 Sep 2012 15:24:09 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jmarcet@gmail.com>) id 1TGWzZ-0006je-1p
	for xen-devel@lists.xen.org; Tue, 25 Sep 2012 15:24:09 +0000
Received: from [85.158.139.83:3426] by server-7.bemta-5.messagelabs.com id
	74/E9-00431-89CC1605; Tue, 25 Sep 2012 15:24:08 +0000
X-Env-Sender: jmarcet@gmail.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1348586646!31539214!1
X-Originating-IP: [209.85.214.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22995 invoked from network); 25 Sep 2012 15:24:07 -0000
Received: from mail-ob0-f173.google.com (HELO mail-ob0-f173.google.com)
	(209.85.214.173)
	by server-13.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Sep 2012 15:24:07 -0000
Received: by obbta14 with SMTP id ta14so8688016obb.32
	for <xen-devel@lists.xen.org>; Tue, 25 Sep 2012 08:24:05 -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=XnWKA+QRmRQCPseuS9usZ4MpufmJ7wgcqVqrGg+L3W4=;
	b=V/8sC+BJD2GDhQloAXTHpmTAVrGEVVw4QxyIIpLS2b8e0AAoX9DSZQBDguVyskLTbn
	UKYVanYgh+vtdlzRjs0LIAVzSUghDLLeFcLm488wC0LBlzC651IWNnB+jSIBEMysjSbd
	kgq4zw9Y97W0RrsemwD+gwliVCaCpiX4Ibwcn3Garh1MWDhf0EK1FmZVOlD1D4ahYJTN
	Y80WprBTgVnUvxsCS451OG7luatL58qSlqB1WttIwsNw/yz3Bd/9FeXU2kATjenkxuCB
	0xItUk18wJ1/PieOYu0UIIDec5XqoSGMe+WhlP/6QaDeftY/vmHxwjdg4sytu+CquhmQ
	Ly/w==
Received: by 10.182.177.7 with SMTP id cm7mr12557948obc.17.1348586645722; Tue,
	25 Sep 2012 08:24:05 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.60.138.225 with HTTP; Tue, 25 Sep 2012 08:23:45 -0700 (PDT)
In-Reply-To: <5061E800020000780009DBBA@nat28.tlf.novell.com>
References: <CC8273A0.4C9DD%keir@xen.org>
	<50605E9A020000780009D486@nat28.tlf.novell.com>
	<CAOvdn6XmB6rj3_QVU+59V8p24Y5G47AWxVEM=id02JWXkuhibQ@mail.gmail.com>
	<5060640B020000780009D4D2@nat28.tlf.novell.com>
	<CAOvdn6XLy8zR2rb2MEyi2aT9LQiFvFLY_H02p181mTsVLVTZkw@mail.gmail.com>
	<20120924122203.GG8912@reaktio.net>
	<CAOvdn6XV4eoA-FfFns1xhx7HCUqXc7KHxZwyKuT4FHG8s3R5RQ@mail.gmail.com>
	<CAAnFQG9PLQjdh6Ab6=Y5ZGM1s4nGdLekKU=pcKNMxt4rmt_RKA@mail.gmail.com>
	<20120924140411.GH31618@phenom.dumpdata.com>
	<CAAnFQG-tjv5UyF6j-TNHNgme2c4vA0Zxy8AdCiJEVsf2Z0quNA@mail.gmail.com>
	<20120925140611.GB16478@phenom.dumpdata.com>
	<CAAnFQG88ApxKuscXx53Lt2qOyCe0ws6oXSSqBDfW0+oYo5Y3nA@mail.gmail.com>
	<5061E800020000780009DBBA@nat28.tlf.novell.com>
From: Javier Marcet <jmarcet@gmail.com>
Date: Tue, 25 Sep 2012 17:23:45 +0200
Message-ID: <CAAnFQG-sFLrtS3F152xtz6LLtGzDXstEfrZiUVPF82pe54rcWg@mail.gmail.com>
To: Jan Beulich <JBeulich@suse.com>
Cc: Keir Fraser <keir@xen.org>, john.baboval@citrix.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	xen-devel <xen-devel@lists.xen.org>,
	Konrad Rzeszutek Wilk <konrad@kernel.org>, Ben Guthro <ben@guthro.net>,
	Thomas Goetz <thomas.goetz@citrix.com>
Subject: Re: [Xen-devel] Xen4.2 S3 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 Tue, Sep 25, 2012 at 5:21 PM, Jan Beulich <JBeulich@suse.com> wrote:
>>>> On 25.09.12 at 16:47, Javier Marcet <jmarcet@gmail.com> wrote:
>> I haven't been able to see the actual patch, I only read a description
>> of what it should do. Two possible places where a wbinvd() call should
>> be added. On the first of these two places there were already calls to
>> wbinvd() just before the halts. I added it to the other one, within
>> xen/arch/x86/domain.c:default_idle and I could complete a
>> suspend/resume cycle without the back trace but after rebooting I
>> tried it again and it failed, more than once.
>
> default_idle() isn't the right place, default_dead_idle() is.
>
> See
> http://xenbits.xen.org/hg/staging/xen-unstable.hg/rev/c8d65d91a6f2

Thanks for the pointer Jan. This evening I'll try it out and report back.


-- 
Javier Marcet <jmarcet@gmail.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 25 15:24:22 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 15:24:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGWzZ-0006jk-Vz; Tue, 25 Sep 2012 15:24:09 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jmarcet@gmail.com>) id 1TGWzZ-0006je-1p
	for xen-devel@lists.xen.org; Tue, 25 Sep 2012 15:24:09 +0000
Received: from [85.158.139.83:3426] by server-7.bemta-5.messagelabs.com id
	74/E9-00431-89CC1605; Tue, 25 Sep 2012 15:24:08 +0000
X-Env-Sender: jmarcet@gmail.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1348586646!31539214!1
X-Originating-IP: [209.85.214.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22995 invoked from network); 25 Sep 2012 15:24:07 -0000
Received: from mail-ob0-f173.google.com (HELO mail-ob0-f173.google.com)
	(209.85.214.173)
	by server-13.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Sep 2012 15:24:07 -0000
Received: by obbta14 with SMTP id ta14so8688016obb.32
	for <xen-devel@lists.xen.org>; Tue, 25 Sep 2012 08:24:05 -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=XnWKA+QRmRQCPseuS9usZ4MpufmJ7wgcqVqrGg+L3W4=;
	b=V/8sC+BJD2GDhQloAXTHpmTAVrGEVVw4QxyIIpLS2b8e0AAoX9DSZQBDguVyskLTbn
	UKYVanYgh+vtdlzRjs0LIAVzSUghDLLeFcLm488wC0LBlzC651IWNnB+jSIBEMysjSbd
	kgq4zw9Y97W0RrsemwD+gwliVCaCpiX4Ibwcn3Garh1MWDhf0EK1FmZVOlD1D4ahYJTN
	Y80WprBTgVnUvxsCS451OG7luatL58qSlqB1WttIwsNw/yz3Bd/9FeXU2kATjenkxuCB
	0xItUk18wJ1/PieOYu0UIIDec5XqoSGMe+WhlP/6QaDeftY/vmHxwjdg4sytu+CquhmQ
	Ly/w==
Received: by 10.182.177.7 with SMTP id cm7mr12557948obc.17.1348586645722; Tue,
	25 Sep 2012 08:24:05 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.60.138.225 with HTTP; Tue, 25 Sep 2012 08:23:45 -0700 (PDT)
In-Reply-To: <5061E800020000780009DBBA@nat28.tlf.novell.com>
References: <CC8273A0.4C9DD%keir@xen.org>
	<50605E9A020000780009D486@nat28.tlf.novell.com>
	<CAOvdn6XmB6rj3_QVU+59V8p24Y5G47AWxVEM=id02JWXkuhibQ@mail.gmail.com>
	<5060640B020000780009D4D2@nat28.tlf.novell.com>
	<CAOvdn6XLy8zR2rb2MEyi2aT9LQiFvFLY_H02p181mTsVLVTZkw@mail.gmail.com>
	<20120924122203.GG8912@reaktio.net>
	<CAOvdn6XV4eoA-FfFns1xhx7HCUqXc7KHxZwyKuT4FHG8s3R5RQ@mail.gmail.com>
	<CAAnFQG9PLQjdh6Ab6=Y5ZGM1s4nGdLekKU=pcKNMxt4rmt_RKA@mail.gmail.com>
	<20120924140411.GH31618@phenom.dumpdata.com>
	<CAAnFQG-tjv5UyF6j-TNHNgme2c4vA0Zxy8AdCiJEVsf2Z0quNA@mail.gmail.com>
	<20120925140611.GB16478@phenom.dumpdata.com>
	<CAAnFQG88ApxKuscXx53Lt2qOyCe0ws6oXSSqBDfW0+oYo5Y3nA@mail.gmail.com>
	<5061E800020000780009DBBA@nat28.tlf.novell.com>
From: Javier Marcet <jmarcet@gmail.com>
Date: Tue, 25 Sep 2012 17:23:45 +0200
Message-ID: <CAAnFQG-sFLrtS3F152xtz6LLtGzDXstEfrZiUVPF82pe54rcWg@mail.gmail.com>
To: Jan Beulich <JBeulich@suse.com>
Cc: Keir Fraser <keir@xen.org>, john.baboval@citrix.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	xen-devel <xen-devel@lists.xen.org>,
	Konrad Rzeszutek Wilk <konrad@kernel.org>, Ben Guthro <ben@guthro.net>,
	Thomas Goetz <thomas.goetz@citrix.com>
Subject: Re: [Xen-devel] Xen4.2 S3 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 Tue, Sep 25, 2012 at 5:21 PM, Jan Beulich <JBeulich@suse.com> wrote:
>>>> On 25.09.12 at 16:47, Javier Marcet <jmarcet@gmail.com> wrote:
>> I haven't been able to see the actual patch, I only read a description
>> of what it should do. Two possible places where a wbinvd() call should
>> be added. On the first of these two places there were already calls to
>> wbinvd() just before the halts. I added it to the other one, within
>> xen/arch/x86/domain.c:default_idle and I could complete a
>> suspend/resume cycle without the back trace but after rebooting I
>> tried it again and it failed, more than once.
>
> default_idle() isn't the right place, default_dead_idle() is.
>
> See
> http://xenbits.xen.org/hg/staging/xen-unstable.hg/rev/c8d65d91a6f2

Thanks for the pointer Jan. This evening I'll try it out and report back.


-- 
Javier Marcet <jmarcet@gmail.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 25 15:26:44 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 15:26:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGX1t-0006qc-HJ; Tue, 25 Sep 2012 15:26:33 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1TGX1r-0006qX-Pm
	for xen-devel@lists.xen.org; Tue, 25 Sep 2012 15:26:32 +0000
Received: from [85.158.137.99:46722] by server-10.bemta-3.messagelabs.com id
	ED/CE-10411-72DC1605; Tue, 25 Sep 2012 15:26:31 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-5.tower-217.messagelabs.com!1348586790!14333390!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1492 invoked from network); 25 Sep 2012 15:26:30 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-5.tower-217.messagelabs.com with SMTP;
	25 Sep 2012 15:26:30 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 25 Sep 2012 16:26:30 +0100
Message-Id: <5061E95C020000780009DBC5@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 25 Sep 2012 16:26:52 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Andrew Cooper" <andrew.cooper3@citrix.com>
References: <5061BD4E.6000905@citrix.com>
	<1348583626.11229.26.camel@zakaz.uk.xensource.com>
	<5061C556.60406@citrix.com>
In-Reply-To: <5061C556.60406@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "Keir \(Xen.org\)" <keir@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] RFC: EFER in crash notes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 25.09.12 at 16:53, Andrew Cooper <andrew.cooper3@citrix.com> wrote:

> On 25/09/12 15:33, Ian Campbell wrote:
>> On Tue, 2012-09-25 at 15:18 +0100, Andrew Cooper wrote:
>>> While this patch is very simple, and I hope without any objection, it is
>>> RFC for the reason that our crash ABI is private.
>>>
>>> The comments for XEN_ELFNOTE_CRASH_REGS does state that it is
>>> architecture specific, and makes no indication about the size or
>>> contents of the crash note.  However, any code trying to use one of
>>> these types of notes has to make an assumption that it if the note desc
>>> length is 4*8 bytes long, it is representing CR{0,2-4}.
>>>
>>> I guess my question boils down to whether it is acceptable to change a
>>> private ABI which is not really so private, or whether we should make a
>>> formal public ABI for all of the inards of the crash notes and use that.
>> Is it really private? (or even "not so private"), don't external tools
>> like crash support it?
> 
> This is my point.  It is not in xen/public but is used by crash/kdump
> and similar utilities, effectively making it a public ABI.
> 
> include/public/elfnote.h even explicitly refers to
> include/xen/elfcore.h, which is not public by our definition.
> 
>>
>> I suppose the size field in the notes is a sort of rudimentary version
>> field. Remember you can always add a new note type though.
> 
> Yes, although looking through my code, I do raise an error if
> sizeof(note->desc) != sizeof(my structure representing this note), which
> was put in with the best of intentions, but will break with the this RFC
> change.
> 
> On the other hand, adding a new crash note for every new register will
> not scale well, as it is per PCU.

You don't need a not per addition - if you add a new note now
clearly identifying it as "might grow", then subsequently adding
to it shouldn't be a problem.

Adding to an existing one that wasn't considered extensible, as
you see with your own example above, is not an option unless
you have control over _all_ consumers.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 25 15:26:44 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 15:26:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGX1t-0006qc-HJ; Tue, 25 Sep 2012 15:26:33 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1TGX1r-0006qX-Pm
	for xen-devel@lists.xen.org; Tue, 25 Sep 2012 15:26:32 +0000
Received: from [85.158.137.99:46722] by server-10.bemta-3.messagelabs.com id
	ED/CE-10411-72DC1605; Tue, 25 Sep 2012 15:26:31 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-5.tower-217.messagelabs.com!1348586790!14333390!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1492 invoked from network); 25 Sep 2012 15:26:30 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-5.tower-217.messagelabs.com with SMTP;
	25 Sep 2012 15:26:30 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 25 Sep 2012 16:26:30 +0100
Message-Id: <5061E95C020000780009DBC5@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 25 Sep 2012 16:26:52 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Andrew Cooper" <andrew.cooper3@citrix.com>
References: <5061BD4E.6000905@citrix.com>
	<1348583626.11229.26.camel@zakaz.uk.xensource.com>
	<5061C556.60406@citrix.com>
In-Reply-To: <5061C556.60406@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "Keir \(Xen.org\)" <keir@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] RFC: EFER in crash notes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 25.09.12 at 16:53, Andrew Cooper <andrew.cooper3@citrix.com> wrote:

> On 25/09/12 15:33, Ian Campbell wrote:
>> On Tue, 2012-09-25 at 15:18 +0100, Andrew Cooper wrote:
>>> While this patch is very simple, and I hope without any objection, it is
>>> RFC for the reason that our crash ABI is private.
>>>
>>> The comments for XEN_ELFNOTE_CRASH_REGS does state that it is
>>> architecture specific, and makes no indication about the size or
>>> contents of the crash note.  However, any code trying to use one of
>>> these types of notes has to make an assumption that it if the note desc
>>> length is 4*8 bytes long, it is representing CR{0,2-4}.
>>>
>>> I guess my question boils down to whether it is acceptable to change a
>>> private ABI which is not really so private, or whether we should make a
>>> formal public ABI for all of the inards of the crash notes and use that.
>> Is it really private? (or even "not so private"), don't external tools
>> like crash support it?
> 
> This is my point.  It is not in xen/public but is used by crash/kdump
> and similar utilities, effectively making it a public ABI.
> 
> include/public/elfnote.h even explicitly refers to
> include/xen/elfcore.h, which is not public by our definition.
> 
>>
>> I suppose the size field in the notes is a sort of rudimentary version
>> field. Remember you can always add a new note type though.
> 
> Yes, although looking through my code, I do raise an error if
> sizeof(note->desc) != sizeof(my structure representing this note), which
> was put in with the best of intentions, but will break with the this RFC
> change.
> 
> On the other hand, adding a new crash note for every new register will
> not scale well, as it is per PCU.

You don't need a not per addition - if you add a new note now
clearly identifying it as "might grow", then subsequently adding
to it shouldn't be a problem.

Adding to an existing one that wasn't considered extensible, as
you see with your own example above, is not an option unless
you have control over _all_ consumers.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 25 15:29:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 15:29:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGX4W-000711-2I; Tue, 25 Sep 2012 15:29: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 1TGX4V-00070t-MH
	for xen-devel@lists.xensource.com; Tue, 25 Sep 2012 15:29:15 +0000
Received: from [85.158.143.35:30061] by server-2.bemta-4.messagelabs.com id
	32/8B-06610-ACDC1605; Tue, 25 Sep 2012 15:29:14 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1348586951!13970894!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTEwNzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16993 invoked from network); 25 Sep 2012 15:29:12 -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 Sep 2012 15:29:12 -0000
X-IronPort-AV: E=Sophos;i="4.80,484,1344211200"; d="scan'208";a="14754959"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Sep 2012 15:29:11 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Tue, 25 Sep 2012 16:29:11 +0100
Message-ID: <1348586949.12592.10.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Sander Eikelenboom <linux@eikelenboom.it>
Date: Tue, 25 Sep 2012 16:29:09 +0100
In-Reply-To: <15210025463.20120925171143@eikelenboom.it>
References: <patchbomb.1346960486@xentest.example.org>
	<1348565712.3452.141.camel@zakaz.uk.xensource.com>
	<15210025463.20120925171143@eikelenboom.it>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-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 0 of 3] xl and hotplug: Introduce and use
 shutdown and reboot xm compatibility options
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-09-25 at 16:11 +0100, Sander Eikelenboom wrote:

> The only relative simple implementation i thought of was direct
> shutting down all, and when the -w parameter was set, just loop and
> wait on events until the only running domain is domain-0.
> Although this exactly does what has to be done, it somehow sounds a
> bit dirty.

I think you can allocate an array of libxl_evenable_domain_death*, of
nr_doms in size and then as you shutdown each domain call
libxl_evenable_domain_death for it too.

Then you loop waiting for destroy events, calling
libxl_evdisable_domain_death as each domain dies, while counting back
from nr_doms until 0. When it reaches 0 everything you asked for has
been shutdown.

Or something like that, I've not actually implemented 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 Sep 25 15:29:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 15:29:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGX4W-000711-2I; Tue, 25 Sep 2012 15:29: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 1TGX4V-00070t-MH
	for xen-devel@lists.xensource.com; Tue, 25 Sep 2012 15:29:15 +0000
Received: from [85.158.143.35:30061] by server-2.bemta-4.messagelabs.com id
	32/8B-06610-ACDC1605; Tue, 25 Sep 2012 15:29:14 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1348586951!13970894!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTEwNzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16993 invoked from network); 25 Sep 2012 15:29:12 -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 Sep 2012 15:29:12 -0000
X-IronPort-AV: E=Sophos;i="4.80,484,1344211200"; d="scan'208";a="14754959"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Sep 2012 15:29:11 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Tue, 25 Sep 2012 16:29:11 +0100
Message-ID: <1348586949.12592.10.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Sander Eikelenboom <linux@eikelenboom.it>
Date: Tue, 25 Sep 2012 16:29:09 +0100
In-Reply-To: <15210025463.20120925171143@eikelenboom.it>
References: <patchbomb.1346960486@xentest.example.org>
	<1348565712.3452.141.camel@zakaz.uk.xensource.com>
	<15210025463.20120925171143@eikelenboom.it>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-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 0 of 3] xl and hotplug: Introduce and use
 shutdown and reboot xm compatibility options
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-09-25 at 16:11 +0100, Sander Eikelenboom wrote:

> The only relative simple implementation i thought of was direct
> shutting down all, and when the -w parameter was set, just loop and
> wait on events until the only running domain is domain-0.
> Although this exactly does what has to be done, it somehow sounds a
> bit dirty.

I think you can allocate an array of libxl_evenable_domain_death*, of
nr_doms in size and then as you shutdown each domain call
libxl_evenable_domain_death for it too.

Then you loop waiting for destroy events, calling
libxl_evdisable_domain_death as each domain dies, while counting back
from nr_doms until 0. When it reaches 0 everything you asked for has
been shutdown.

Or something like that, I've not actually implemented 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 Sep 25 15:35:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 15:35:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGXA3-0007MB-Rg; Tue, 25 Sep 2012 15:34:59 +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 1TGXA2-0007M4-Nc
	for xen-devel@lists.xen.org; Tue, 25 Sep 2012 15:34:58 +0000
Received: from [85.158.137.99:55562] by server-12.bemta-3.messagelabs.com id
	61/71-10384-12FC1605; Tue, 25 Sep 2012 15:34:57 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-4.tower-217.messagelabs.com!1348587296!19085960!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA1MTM1OTg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12821 invoked from network); 25 Sep 2012 15:34:57 -0000
Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25)
	by server-4.tower-217.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 25 Sep 2012 15:34:57 -0000
X-Originating-Ip: [194.89.68.22]
Received: from ydin.reaktio.net (reaktio.net [194.89.68.22])
	by smtp.tele.fi (Postfix) with ESMTP id 9ADE02F53;
	Tue, 25 Sep 2012 18:34:46 +0300 (EEST)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id B2F2520061; Tue, 25 Sep 2012 18:34:45 +0300 (EEST)
Date: Tue, 25 Sep 2012 18:34:45 +0300
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: Konrad Rzeszutek Wilk <konrad@kernel.org>
Message-ID: <20120925153445.GN8912@reaktio.net>
References: <CALCpXpCvGkjZyG-NOY+fZY0q0f_DxuwPNEnxwKXVhjOe=gcHSQ@mail.gmail.com>
	<20120925140421.GA16478@phenom.dumpdata.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120925140421.GA16478@phenom.dumpdata.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] usbpassthrough of xen-4.1.2 update / Qemu-dm
 PulseAudio/Alsa 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, Sep 25, 2012 at 10:04:22AM -0400, Konrad Rzeszutek Wilk wrote:
>
> # Remember QEMU_AUDIO_DRV=pa
> soundhw='es1370'
>

Hey,

This reminds me.. is qemu-dm (traditional) automatically compiled with PulseAudio support enabled these days? 
How about Alsa support? 

Or do we need Makefile tweaks before building Xen/Qemu..

-- Pasi


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 25 15:35:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 15:35:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGXA3-0007MB-Rg; Tue, 25 Sep 2012 15:34:59 +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 1TGXA2-0007M4-Nc
	for xen-devel@lists.xen.org; Tue, 25 Sep 2012 15:34:58 +0000
Received: from [85.158.137.99:55562] by server-12.bemta-3.messagelabs.com id
	61/71-10384-12FC1605; Tue, 25 Sep 2012 15:34:57 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-4.tower-217.messagelabs.com!1348587296!19085960!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA1MTM1OTg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12821 invoked from network); 25 Sep 2012 15:34:57 -0000
Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25)
	by server-4.tower-217.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 25 Sep 2012 15:34:57 -0000
X-Originating-Ip: [194.89.68.22]
Received: from ydin.reaktio.net (reaktio.net [194.89.68.22])
	by smtp.tele.fi (Postfix) with ESMTP id 9ADE02F53;
	Tue, 25 Sep 2012 18:34:46 +0300 (EEST)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id B2F2520061; Tue, 25 Sep 2012 18:34:45 +0300 (EEST)
Date: Tue, 25 Sep 2012 18:34:45 +0300
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: Konrad Rzeszutek Wilk <konrad@kernel.org>
Message-ID: <20120925153445.GN8912@reaktio.net>
References: <CALCpXpCvGkjZyG-NOY+fZY0q0f_DxuwPNEnxwKXVhjOe=gcHSQ@mail.gmail.com>
	<20120925140421.GA16478@phenom.dumpdata.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120925140421.GA16478@phenom.dumpdata.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] usbpassthrough of xen-4.1.2 update / Qemu-dm
 PulseAudio/Alsa 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, Sep 25, 2012 at 10:04:22AM -0400, Konrad Rzeszutek Wilk wrote:
>
> # Remember QEMU_AUDIO_DRV=pa
> soundhw='es1370'
>

Hey,

This reminds me.. is qemu-dm (traditional) automatically compiled with PulseAudio support enabled these days? 
How about Alsa support? 

Or do we need Makefile tweaks before building Xen/Qemu..

-- Pasi


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 25 15:37:35 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 15:37:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGXCN-0007RV-Dl; Tue, 25 Sep 2012 15:37:23 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1TGXCM-0007RQ-48
	for xen-devel@lists.xensource.com; Tue, 25 Sep 2012 15:37:22 +0000
Received: from [85.158.143.99:26424] by server-2.bemta-4.messagelabs.com id
	92/A6-06610-0BFC1605; Tue, 25 Sep 2012 15:37:20 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1348587438!26443818!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzYyNzYy\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27645 invoked from network); 25 Sep 2012 15:37:20 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-4.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 25 Sep 2012 15:37:20 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q8PFbGUT031135
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 25 Sep 2012 15:37:16 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
	q8PFbEm0003675
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 25 Sep 2012 15:37:15 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
	q8PFbEqk006872; Tue, 25 Sep 2012 10:37:14 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 25 Sep 2012 08:37:14 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 2D44A40357; Tue, 25 Sep 2012 11:26:00 -0400 (EDT)
Date: Tue, 25 Sep 2012 11:26:00 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Justin Gibbs <justing@spectralogic.com>, xen-devel@lists.xensource.com
Message-ID: <20120925152600.GA967@phenom.dumpdata.com>
References: <A21691DE07B84740B5F0B81466D5148A23BE55DE@SHSMSX102.ccr.corp.intel.com>
	<20120817172838.GA3515@phenom.dumpdata.com>
	<A21691DE07B84740B5F0B81466D5148A23BE8F48@SHSMSX102.ccr.corp.intel.com>
	<61DFA8800400A143A5A7C5E136A726DC5F867490@reactor.sldomain.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <61DFA8800400A143A5A7C5E136A726DC5F867490@reactor.sldomain.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: "Duan, Ronghui" <ronghui.duan@intel.com>
Subject: Re: [Xen-devel] xen-vbd interface (segment size expansion) -
 FreeBSD host have it.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Aug 20, 2012 at 06:56:02PM +0000, Justin Gibbs wrote:
> Ronghui,
> 
> It has been a while since I've actively worked on the blkif stuff.  ...
> 
> That said, I'm happy to help in whatever ways I can to help get the blkif interface sorted out.  I see several steps that should be taken:
> 
> 1) Fix the Xen and QEMU builds so that QEMU keeps its own copy of the Xen interface version.  This will allow interfaces to rev safely and in a coordinated fashion (i.e. update interface in Xen, then add support for the new interface in QEMU upstream).
> 
> 2) Complete support in drivers for the existing blkif interface so that you get maximum performance against systems using the existing multi-page extensions.
> 
> 3) Do something to allow for larger and more numerous requests.
> 
> On point 3, my approach was to try to perturb the existing protocol as little as possible in the hopes that other implementations could quickly be enhanced to support the feature.  However, there is a lot of ugliness in the existing blkif interface.  I can certainly understand the desires of some to just replace blkif with a blkif2.
> 
> What are your current plans in this area?  How can I be of assistance?

Hey Justin and Ronghui,

Note: I've expanded the email thread to include xen-devel.

I was wondering how the protocol you developed works when it comes
to migration to a host that does not support the new features?

Specifically how do deal with a guest which tries to replay in progress I/Os
that do not fit within the old-segment size (11)?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 25 15:37:35 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 15:37:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGXCN-0007RV-Dl; Tue, 25 Sep 2012 15:37:23 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1TGXCM-0007RQ-48
	for xen-devel@lists.xensource.com; Tue, 25 Sep 2012 15:37:22 +0000
Received: from [85.158.143.99:26424] by server-2.bemta-4.messagelabs.com id
	92/A6-06610-0BFC1605; Tue, 25 Sep 2012 15:37:20 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1348587438!26443818!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzYyNzYy\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27645 invoked from network); 25 Sep 2012 15:37:20 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-4.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 25 Sep 2012 15:37:20 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q8PFbGUT031135
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 25 Sep 2012 15:37:16 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
	q8PFbEm0003675
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 25 Sep 2012 15:37:15 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
	q8PFbEqk006872; Tue, 25 Sep 2012 10:37:14 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 25 Sep 2012 08:37:14 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 2D44A40357; Tue, 25 Sep 2012 11:26:00 -0400 (EDT)
Date: Tue, 25 Sep 2012 11:26:00 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Justin Gibbs <justing@spectralogic.com>, xen-devel@lists.xensource.com
Message-ID: <20120925152600.GA967@phenom.dumpdata.com>
References: <A21691DE07B84740B5F0B81466D5148A23BE55DE@SHSMSX102.ccr.corp.intel.com>
	<20120817172838.GA3515@phenom.dumpdata.com>
	<A21691DE07B84740B5F0B81466D5148A23BE8F48@SHSMSX102.ccr.corp.intel.com>
	<61DFA8800400A143A5A7C5E136A726DC5F867490@reactor.sldomain.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <61DFA8800400A143A5A7C5E136A726DC5F867490@reactor.sldomain.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: "Duan, Ronghui" <ronghui.duan@intel.com>
Subject: Re: [Xen-devel] xen-vbd interface (segment size expansion) -
 FreeBSD host have it.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Aug 20, 2012 at 06:56:02PM +0000, Justin Gibbs wrote:
> Ronghui,
> 
> It has been a while since I've actively worked on the blkif stuff.  ...
> 
> That said, I'm happy to help in whatever ways I can to help get the blkif interface sorted out.  I see several steps that should be taken:
> 
> 1) Fix the Xen and QEMU builds so that QEMU keeps its own copy of the Xen interface version.  This will allow interfaces to rev safely and in a coordinated fashion (i.e. update interface in Xen, then add support for the new interface in QEMU upstream).
> 
> 2) Complete support in drivers for the existing blkif interface so that you get maximum performance against systems using the existing multi-page extensions.
> 
> 3) Do something to allow for larger and more numerous requests.
> 
> On point 3, my approach was to try to perturb the existing protocol as little as possible in the hopes that other implementations could quickly be enhanced to support the feature.  However, there is a lot of ugliness in the existing blkif interface.  I can certainly understand the desires of some to just replace blkif with a blkif2.
> 
> What are your current plans in this area?  How can I be of assistance?

Hey Justin and Ronghui,

Note: I've expanded the email thread to include xen-devel.

I was wondering how the protocol you developed works when it comes
to migration to a host that does not support the new features?

Specifically how do deal with a guest which tries to replay in progress I/Os
that do not fit within the old-segment size (11)?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 25 15:38:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 15:38:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGXCr-0007V2-RJ; Tue, 25 Sep 2012 15:37:53 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <cutter409@gmail.com>) id 1TGXCp-0007Ug-U5
	for xen-devel@lists.xensource.com; Tue, 25 Sep 2012 15:37:52 +0000
Received: from [85.158.143.35:15041] by server-2.bemta-4.messagelabs.com id
	6B/37-06610-FCFC1605; Tue, 25 Sep 2012 15:37:51 +0000
X-Env-Sender: cutter409@gmail.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1348587469!12697085!1
X-Originating-IP: [209.85.212.43]
X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_10_20,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2709 invoked from network); 25 Sep 2012 15:37:50 -0000
Received: from mail-vb0-f43.google.com (HELO mail-vb0-f43.google.com)
	(209.85.212.43)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Sep 2012 15:37:50 -0000
Received: by vbbfq11 with SMTP id fq11so9321179vbb.30
	for <xen-devel@lists.xensource.com>;
	Tue, 25 Sep 2012 08:37:49 -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=BaEzQqwg2mQfvoEikve+dsh69gqwyKpOgS9Ia8y1FhY=;
	b=HCpfAp/8TjdBT43Znig1E/6FqtVHuZGUuOYgQs20RRVPXwYK0rSxSQHBd8dGGp+lNi
	I22lSYHWMBAQaQkZdf3/XSWOfugLS++EZjphmfzJzO6jsm8spC/lIW9y3ZhY77g4ri5K
	HrMX4YdWt/3Ak4rHSOSud2m00pSK2dTvbCsAxLnOB1QYPIydIfR5NgeJq4TZ7dLgnmTN
	kI4pc6W60RolRCFQHUpZoVtQL/4Z5D/BTXFzS5MTHuH2OkPR3wAGbVeHa9YRpeEQZM6p
	uR9qTUUXXhs0vLbp/l1wN9sAMjpiNnACwTJ16q2Z2IzURL6Vdji/3Y8u0ftzkwrxfM4X
	752w==
MIME-Version: 1.0
Received: by 10.52.23.71 with SMTP id k7mr7868181vdf.26.1348587469157; Tue, 25
	Sep 2012 08:37:49 -0700 (PDT)
Received: by 10.220.162.144 with HTTP; Tue, 25 Sep 2012 08:37:49 -0700 (PDT)
Date: Tue, 25 Sep 2012 11:37:49 -0400
Message-ID: <CAG4Ohu_KDy-bDR8Os71RXwQ6Q9QtRUZ3kSTirdpHBtZfqwaLrw@mail.gmail.com>
From: Cutter 409 <cutter409@gmail.com>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] SVM Trap Flag exiting?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============3485550822361712194=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============3485550822361712194==
Content-Type: multipart/alternative; boundary=20cf3071c8d20c345204ca887d5f

--20cf3071c8d20c345204ca887d5f
Content-Type: text/plain; charset=ISO-8859-1

I'm having a really hard time trying to accomplish something that seems
generally simple. I want to single step some code in an SVM guest.

My current method essentially does the following:

>From a domctl:
   * Pause the target VCPU
   * vmcb_set_exception_intercepts(vmcb,
vmcb_get_exception_intercepts(vmcb) | (1U << TRAP_debug) );
   * v->arch.guest_context.user_regs.rflags |= X86_EFLAGS_TF;
   * I've also tried vmcb->rflags |= X86_EFLAGS_TF;
   * Unpause the VCPU

But the VMEXIT_EXCEPTION_DB case doesn't ever seem to get called. Is there
something I'm missing here?
I've also tried setting both versions of rflags in svm_do_resume() but it
doesn't make a difference.The guest doesn't crash either, so I'm assuming
TF is just not getting set.

Any thoughts would be greatly appreciated.

Thanks!

--20cf3071c8d20c345204ca887d5f
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

I&#39;m having a really hard time trying to accomplish something that seems=
 generally simple. I want to single step some code in an SVM guest.<br><br>=
My current method essentially does the following:<br><br>From a domctl:<br>

=A0=A0 * Pause the target VCPU<br>=A0=A0 * vmcb_set_exception_intercepts(vm=
cb, vmcb_get_exception_intercepts(vmcb) | (1U &lt;&lt; TRAP_debug) );<br>=
=A0=A0 * v-&gt;arch.guest_context.user_regs.rflags |=3D X86_EFLAGS_TF;<br>=
=A0=A0 * I&#39;ve also tried vmcb-&gt;rflags |=3D X86_EFLAGS_TF;<br>
=A0=A0 * Unpause the VCPU<br>
<br>But the VMEXIT_EXCEPTION_DB case doesn&#39;t ever seem to get called. I=
s there something I&#39;m missing here?<br>I&#39;ve also tried setting both=
 versions of rflags in svm_do_resume() but it doesn&#39;t make a difference=
.The guest doesn&#39;t crash either, so I&#39;m assuming TF is just not get=
ting set.<br>
<br>Any thoughts would be greatly appreciated.<br><br>Thanks!<br><br><br>

--20cf3071c8d20c345204ca887d5f--


--===============3485550822361712194==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============3485550822361712194==--


From xen-devel-bounces@lists.xen.org Tue Sep 25 15:38:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 15:38:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGXCr-0007V2-RJ; Tue, 25 Sep 2012 15:37:53 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <cutter409@gmail.com>) id 1TGXCp-0007Ug-U5
	for xen-devel@lists.xensource.com; Tue, 25 Sep 2012 15:37:52 +0000
Received: from [85.158.143.35:15041] by server-2.bemta-4.messagelabs.com id
	6B/37-06610-FCFC1605; Tue, 25 Sep 2012 15:37:51 +0000
X-Env-Sender: cutter409@gmail.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1348587469!12697085!1
X-Originating-IP: [209.85.212.43]
X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_10_20,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2709 invoked from network); 25 Sep 2012 15:37:50 -0000
Received: from mail-vb0-f43.google.com (HELO mail-vb0-f43.google.com)
	(209.85.212.43)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Sep 2012 15:37:50 -0000
Received: by vbbfq11 with SMTP id fq11so9321179vbb.30
	for <xen-devel@lists.xensource.com>;
	Tue, 25 Sep 2012 08:37:49 -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=BaEzQqwg2mQfvoEikve+dsh69gqwyKpOgS9Ia8y1FhY=;
	b=HCpfAp/8TjdBT43Znig1E/6FqtVHuZGUuOYgQs20RRVPXwYK0rSxSQHBd8dGGp+lNi
	I22lSYHWMBAQaQkZdf3/XSWOfugLS++EZjphmfzJzO6jsm8spC/lIW9y3ZhY77g4ri5K
	HrMX4YdWt/3Ak4rHSOSud2m00pSK2dTvbCsAxLnOB1QYPIydIfR5NgeJq4TZ7dLgnmTN
	kI4pc6W60RolRCFQHUpZoVtQL/4Z5D/BTXFzS5MTHuH2OkPR3wAGbVeHa9YRpeEQZM6p
	uR9qTUUXXhs0vLbp/l1wN9sAMjpiNnACwTJ16q2Z2IzURL6Vdji/3Y8u0ftzkwrxfM4X
	752w==
MIME-Version: 1.0
Received: by 10.52.23.71 with SMTP id k7mr7868181vdf.26.1348587469157; Tue, 25
	Sep 2012 08:37:49 -0700 (PDT)
Received: by 10.220.162.144 with HTTP; Tue, 25 Sep 2012 08:37:49 -0700 (PDT)
Date: Tue, 25 Sep 2012 11:37:49 -0400
Message-ID: <CAG4Ohu_KDy-bDR8Os71RXwQ6Q9QtRUZ3kSTirdpHBtZfqwaLrw@mail.gmail.com>
From: Cutter 409 <cutter409@gmail.com>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] SVM Trap Flag exiting?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============3485550822361712194=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============3485550822361712194==
Content-Type: multipart/alternative; boundary=20cf3071c8d20c345204ca887d5f

--20cf3071c8d20c345204ca887d5f
Content-Type: text/plain; charset=ISO-8859-1

I'm having a really hard time trying to accomplish something that seems
generally simple. I want to single step some code in an SVM guest.

My current method essentially does the following:

>From a domctl:
   * Pause the target VCPU
   * vmcb_set_exception_intercepts(vmcb,
vmcb_get_exception_intercepts(vmcb) | (1U << TRAP_debug) );
   * v->arch.guest_context.user_regs.rflags |= X86_EFLAGS_TF;
   * I've also tried vmcb->rflags |= X86_EFLAGS_TF;
   * Unpause the VCPU

But the VMEXIT_EXCEPTION_DB case doesn't ever seem to get called. Is there
something I'm missing here?
I've also tried setting both versions of rflags in svm_do_resume() but it
doesn't make a difference.The guest doesn't crash either, so I'm assuming
TF is just not getting set.

Any thoughts would be greatly appreciated.

Thanks!

--20cf3071c8d20c345204ca887d5f
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

I&#39;m having a really hard time trying to accomplish something that seems=
 generally simple. I want to single step some code in an SVM guest.<br><br>=
My current method essentially does the following:<br><br>From a domctl:<br>

=A0=A0 * Pause the target VCPU<br>=A0=A0 * vmcb_set_exception_intercepts(vm=
cb, vmcb_get_exception_intercepts(vmcb) | (1U &lt;&lt; TRAP_debug) );<br>=
=A0=A0 * v-&gt;arch.guest_context.user_regs.rflags |=3D X86_EFLAGS_TF;<br>=
=A0=A0 * I&#39;ve also tried vmcb-&gt;rflags |=3D X86_EFLAGS_TF;<br>
=A0=A0 * Unpause the VCPU<br>
<br>But the VMEXIT_EXCEPTION_DB case doesn&#39;t ever seem to get called. I=
s there something I&#39;m missing here?<br>I&#39;ve also tried setting both=
 versions of rflags in svm_do_resume() but it doesn&#39;t make a difference=
.The guest doesn&#39;t crash either, so I&#39;m assuming TF is just not get=
ting set.<br>
<br>Any thoughts would be greatly appreciated.<br><br>Thanks!<br><br><br>

--20cf3071c8d20c345204ca887d5f--


--===============3485550822361712194==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============3485550822361712194==--


From xen-devel-bounces@lists.xen.org Tue Sep 25 15:45:21 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 15: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 1TGXJt-0007mj-Os; Tue, 25 Sep 2012 15:45:09 +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 1TGXJs-0007mb-Ji
	for xen-devel@lists.xen.org; Tue, 25 Sep 2012 15:45:08 +0000
Received: from [85.158.139.83:49140] by server-8.bemta-5.messagelabs.com id
	B6/42-18073-381D1605; Tue, 25 Sep 2012 15:45:07 +0000
X-Env-Sender: ben.guthro@gmail.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1348587905!27549376!1
X-Originating-IP: [209.85.223.173]
X-SpamReason: No, hits=0.9 required=7.0 tests=HTML_40_50,HTML_MESSAGE,
	RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26741 invoked from network); 25 Sep 2012 15:45:06 -0000
Received: from mail-ie0-f173.google.com (HELO mail-ie0-f173.google.com)
	(209.85.223.173)
	by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Sep 2012 15:45:06 -0000
Received: by iea17 with SMTP id 17so11972740iea.32
	for <xen-devel@lists.xen.org>; Tue, 25 Sep 2012 08:45:05 -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=m+iIZtZ/7p9/rj3KcXubQMDVUn8+1ps78VAMezh36aU=;
	b=hWB2AjWbKkR6qDU94nKwbgE2+AFsguW7fku0FU2zAvT3XFEbQy1TNhTNe0rmcTfxsU
	qjfj8FXXxC/RNd4U1c6FHecEqur/bBXCvzWlag12FREpIFnAqGRyS69oShy1/08uRWOo
	1zmEYoYHxWbr21O7a9kYyvtdVW/k5UP1z8qRwukWYvEoRsNX3Vhz+7VxFIdhxt/AzuOg
	2klPzOj5K5T+hIa7/wKeO/W3nUJfTiE/UDkNG56Dy7ICY+rL2fRgXvR9lMHsnJ9THWFY
	5wfecqpfKUMpCoiKbIvvYIGAWt1obOZb28/vWZcSJsnM2LgsD8HOwP9+Ge9b17jLKQjZ
	y8sQ==
MIME-Version: 1.0
Received: by 10.42.120.205 with SMTP id g13mr5575419icr.4.1348587905049; Tue,
	25 Sep 2012 08:45:05 -0700 (PDT)
Received: by 10.64.55.132 with HTTP; Tue, 25 Sep 2012 08:45:04 -0700 (PDT)
In-Reply-To: <5061E599020000780009DBA4@nat28.tlf.novell.com>
References: <CAOvdn6UCF2A3yP1cqWn=dxwr0ayRbr+rg+xj8META9Dm0+CoNw@mail.gmail.com>
	<CC868168.3FD29%keir.xen@gmail.com>
	<CAOvdn6U-JyLvt96gkLkqzi088tU9_ktv4D+fkJac_BKVe05Y-w@mail.gmail.com>
	<CAOvdn6V+s3AbRzsu8VArbmrZou=im9SqvPf-9Wpif_BrNMv=yg@mail.gmail.com>
	<50617297020000780009D8AA@nat28.tlf.novell.com>
	<CAOvdn6Vsnbcd7m8mh3tSgn3KaEoeiOyVD1mr3uQ3bN=rF=pDUQ@mail.gmail.com>
	<CAOvdn6X6_NwfTNTgwNG7CQOqu2oDb6o6r1Zf+5y0cwZGLKToxA@mail.gmail.com>
	<5061E599020000780009DBA4@nat28.tlf.novell.com>
Date: Tue, 25 Sep 2012 11:45:04 -0400
X-Google-Sender-Auth: 87Oj41qTBEhuukhtZS7u34lincQ
Message-ID: <CAOvdn6UqKqOfn7U-q6BCPF3UcMRO9J-R+Po62eEjfWh3APoSjg@mail.gmail.com>
From: Ben Guthro <ben@guthro.net>
To: Jan Beulich <JBeulich@suse.com>
Cc: Keir Fraser <keir.xen@gmail.com>, John Baboval <john.baboval@citrix.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen4.2 S3 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: multipart/mixed; boundary="===============1308885078197106040=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============1308885078197106040==
Content-Type: multipart/alternative; boundary=90e6ba61458207654c04ca889701

--90e6ba61458207654c04ca889701
Content-Type: text/plain; charset=ISO-8859-1

oops. I didn't reply-all on this - re-replying.

On Tue, Sep 25, 2012 at 11:10 AM, Jan Beulich <JBeulich@suse.com> wrote:

> >>> On 25.09.12 at 16:22, Ben Guthro <ben@guthro.net> wrote:
> > I went back to an old patch that had, since it was in this same function
> > that you made reference to:
> > http://markmail.org/message/qpnmiqzt5bngeejk
> >
> > I noticed that I was not seeing the "Breaking vcpu affinity" printk - so
> I
> > tried to get that
> >
> > The change proposed in that thread seems to work around this pinning
> > problem.
> > However, I'm not sure that it is the "right thing" to be doing.
>
> As said back then, the original change looks a little suspicious,
> and hence reverting it is certainly to be considered.
>

Which is one of the reasons I brought it up again.


>
> However, I don't see yet how this is connected to you having
> a problem only with pinned vCPU-s.
>

Well - when the command line parameter dom0_vcpu_pin exists -
it crashes without this change. It does not crash with it, or without
the command line parameter.

Perhaps they are unrelated.



>
> But - with S3 working again (with the change here) or originally,
> did you ever check whether post-resume Dom0 vCPU-s would
> still be pinned? I suspect they aren't, and hence addressing the
> crash may likely be achieved by properly restoring the pinning.
>

No, I don't believe they are pinned after resume...so while I
suppose it is not entirely correct, it is also better than crashing.

(it is also the observed behavior in Xen-4.0.x)


>
> Jan
>
>

--90e6ba61458207654c04ca889701
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

oops. I didn&#39;t reply-all on this - re-replying.<br><br><div class=3D"gm=
ail_quote">On Tue, Sep 25, 2012 at 11:10 AM, Jan Beulich <span dir=3D"ltr">=
&lt;<a href=3D"mailto:JBeulich@suse.com" target=3D"_blank">JBeulich@suse.co=
m</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 25.09.12 a=
t 16:22, Ben Guthro &lt;<a href=3D"mailto:ben@guthro.net">ben@guthro.net</a=
>&gt; wrote:<br>

&gt; I went back to an old patch that had, since it was in this same functi=
on<br>
&gt; that you made reference to:<br>
&gt; <a href=3D"http://markmail.org/message/qpnmiqzt5bngeejk" target=3D"_bl=
ank">http://markmail.org/message/qpnmiqzt5bngeejk</a><br>
&gt;<br>
&gt; I noticed that I was not seeing the &quot;Breaking vcpu affinity&quot;=
 printk - so I<br>
&gt; tried to get that<br>
&gt;<br>
&gt; The change proposed in that thread seems to work around this pinning<b=
r>
&gt; problem.<br>
&gt; However, I&#39;m not sure that it is the &quot;right thing&quot; to be=
 doing.<br>
<br>
</div>As said back then, the original change looks a little suspicious,<br>
and hence reverting it is certainly to be considered.<br></blockquote><div>=
=A0</div><div>Which is one of the reasons I brought it up again.</div><div>=
=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;borde=
r-left:1px #ccc solid;padding-left:1ex">

<br>
However, I don&#39;t see yet how this is connected to you having<br>
a problem only with pinned vCPU-s.<br></blockquote><div><br></div><div><div=
>Well - when the command line parameter dom0_vcpu_pin exists -=A0</div><div=
>it crashes without this change. It does not crash with it, or without=A0</=
div>
<div>the command line parameter.</div><div><br></div><div>Perhaps they are =
unrelated.</div></div><div><br></div><div>=A0</div><blockquote class=3D"gma=
il_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-lef=
t:1ex">

<br>
But - with S3 working again (with the change here) or originally,<br>
did you ever check whether post-resume Dom0 vCPU-s would<br>
still be pinned? I suspect they aren&#39;t, and hence addressing the<br>
crash may likely be achieved by properly restoring the pinning.<br></blockq=
uote><div><br></div><div><div>No, I don&#39;t believe they are pinned after=
 resume...so while I=A0</div><div>suppose it is not entirely correct, it is=
 also better than crashing.</div>
</div><div><br></div><div>(it is also the observed behavior in Xen-4.0.x)</=
div><div>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .=
8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
Jan<br>
<br>
</font></span></blockquote></div><br>

--90e6ba61458207654c04ca889701--


--===============1308885078197106040==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============1308885078197106040==--


From xen-devel-bounces@lists.xen.org Tue Sep 25 15:45:21 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 15: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 1TGXJt-0007mj-Os; Tue, 25 Sep 2012 15:45:09 +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 1TGXJs-0007mb-Ji
	for xen-devel@lists.xen.org; Tue, 25 Sep 2012 15:45:08 +0000
Received: from [85.158.139.83:49140] by server-8.bemta-5.messagelabs.com id
	B6/42-18073-381D1605; Tue, 25 Sep 2012 15:45:07 +0000
X-Env-Sender: ben.guthro@gmail.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1348587905!27549376!1
X-Originating-IP: [209.85.223.173]
X-SpamReason: No, hits=0.9 required=7.0 tests=HTML_40_50,HTML_MESSAGE,
	RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26741 invoked from network); 25 Sep 2012 15:45:06 -0000
Received: from mail-ie0-f173.google.com (HELO mail-ie0-f173.google.com)
	(209.85.223.173)
	by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Sep 2012 15:45:06 -0000
Received: by iea17 with SMTP id 17so11972740iea.32
	for <xen-devel@lists.xen.org>; Tue, 25 Sep 2012 08:45:05 -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=m+iIZtZ/7p9/rj3KcXubQMDVUn8+1ps78VAMezh36aU=;
	b=hWB2AjWbKkR6qDU94nKwbgE2+AFsguW7fku0FU2zAvT3XFEbQy1TNhTNe0rmcTfxsU
	qjfj8FXXxC/RNd4U1c6FHecEqur/bBXCvzWlag12FREpIFnAqGRyS69oShy1/08uRWOo
	1zmEYoYHxWbr21O7a9kYyvtdVW/k5UP1z8qRwukWYvEoRsNX3Vhz+7VxFIdhxt/AzuOg
	2klPzOj5K5T+hIa7/wKeO/W3nUJfTiE/UDkNG56Dy7ICY+rL2fRgXvR9lMHsnJ9THWFY
	5wfecqpfKUMpCoiKbIvvYIGAWt1obOZb28/vWZcSJsnM2LgsD8HOwP9+Ge9b17jLKQjZ
	y8sQ==
MIME-Version: 1.0
Received: by 10.42.120.205 with SMTP id g13mr5575419icr.4.1348587905049; Tue,
	25 Sep 2012 08:45:05 -0700 (PDT)
Received: by 10.64.55.132 with HTTP; Tue, 25 Sep 2012 08:45:04 -0700 (PDT)
In-Reply-To: <5061E599020000780009DBA4@nat28.tlf.novell.com>
References: <CAOvdn6UCF2A3yP1cqWn=dxwr0ayRbr+rg+xj8META9Dm0+CoNw@mail.gmail.com>
	<CC868168.3FD29%keir.xen@gmail.com>
	<CAOvdn6U-JyLvt96gkLkqzi088tU9_ktv4D+fkJac_BKVe05Y-w@mail.gmail.com>
	<CAOvdn6V+s3AbRzsu8VArbmrZou=im9SqvPf-9Wpif_BrNMv=yg@mail.gmail.com>
	<50617297020000780009D8AA@nat28.tlf.novell.com>
	<CAOvdn6Vsnbcd7m8mh3tSgn3KaEoeiOyVD1mr3uQ3bN=rF=pDUQ@mail.gmail.com>
	<CAOvdn6X6_NwfTNTgwNG7CQOqu2oDb6o6r1Zf+5y0cwZGLKToxA@mail.gmail.com>
	<5061E599020000780009DBA4@nat28.tlf.novell.com>
Date: Tue, 25 Sep 2012 11:45:04 -0400
X-Google-Sender-Auth: 87Oj41qTBEhuukhtZS7u34lincQ
Message-ID: <CAOvdn6UqKqOfn7U-q6BCPF3UcMRO9J-R+Po62eEjfWh3APoSjg@mail.gmail.com>
From: Ben Guthro <ben@guthro.net>
To: Jan Beulich <JBeulich@suse.com>
Cc: Keir Fraser <keir.xen@gmail.com>, John Baboval <john.baboval@citrix.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen4.2 S3 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: multipart/mixed; boundary="===============1308885078197106040=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============1308885078197106040==
Content-Type: multipart/alternative; boundary=90e6ba61458207654c04ca889701

--90e6ba61458207654c04ca889701
Content-Type: text/plain; charset=ISO-8859-1

oops. I didn't reply-all on this - re-replying.

On Tue, Sep 25, 2012 at 11:10 AM, Jan Beulich <JBeulich@suse.com> wrote:

> >>> On 25.09.12 at 16:22, Ben Guthro <ben@guthro.net> wrote:
> > I went back to an old patch that had, since it was in this same function
> > that you made reference to:
> > http://markmail.org/message/qpnmiqzt5bngeejk
> >
> > I noticed that I was not seeing the "Breaking vcpu affinity" printk - so
> I
> > tried to get that
> >
> > The change proposed in that thread seems to work around this pinning
> > problem.
> > However, I'm not sure that it is the "right thing" to be doing.
>
> As said back then, the original change looks a little suspicious,
> and hence reverting it is certainly to be considered.
>

Which is one of the reasons I brought it up again.


>
> However, I don't see yet how this is connected to you having
> a problem only with pinned vCPU-s.
>

Well - when the command line parameter dom0_vcpu_pin exists -
it crashes without this change. It does not crash with it, or without
the command line parameter.

Perhaps they are unrelated.



>
> But - with S3 working again (with the change here) or originally,
> did you ever check whether post-resume Dom0 vCPU-s would
> still be pinned? I suspect they aren't, and hence addressing the
> crash may likely be achieved by properly restoring the pinning.
>

No, I don't believe they are pinned after resume...so while I
suppose it is not entirely correct, it is also better than crashing.

(it is also the observed behavior in Xen-4.0.x)


>
> Jan
>
>

--90e6ba61458207654c04ca889701
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

oops. I didn&#39;t reply-all on this - re-replying.<br><br><div class=3D"gm=
ail_quote">On Tue, Sep 25, 2012 at 11:10 AM, Jan Beulich <span dir=3D"ltr">=
&lt;<a href=3D"mailto:JBeulich@suse.com" target=3D"_blank">JBeulich@suse.co=
m</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 25.09.12 a=
t 16:22, Ben Guthro &lt;<a href=3D"mailto:ben@guthro.net">ben@guthro.net</a=
>&gt; wrote:<br>

&gt; I went back to an old patch that had, since it was in this same functi=
on<br>
&gt; that you made reference to:<br>
&gt; <a href=3D"http://markmail.org/message/qpnmiqzt5bngeejk" target=3D"_bl=
ank">http://markmail.org/message/qpnmiqzt5bngeejk</a><br>
&gt;<br>
&gt; I noticed that I was not seeing the &quot;Breaking vcpu affinity&quot;=
 printk - so I<br>
&gt; tried to get that<br>
&gt;<br>
&gt; The change proposed in that thread seems to work around this pinning<b=
r>
&gt; problem.<br>
&gt; However, I&#39;m not sure that it is the &quot;right thing&quot; to be=
 doing.<br>
<br>
</div>As said back then, the original change looks a little suspicious,<br>
and hence reverting it is certainly to be considered.<br></blockquote><div>=
=A0</div><div>Which is one of the reasons I brought it up again.</div><div>=
=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;borde=
r-left:1px #ccc solid;padding-left:1ex">

<br>
However, I don&#39;t see yet how this is connected to you having<br>
a problem only with pinned vCPU-s.<br></blockquote><div><br></div><div><div=
>Well - when the command line parameter dom0_vcpu_pin exists -=A0</div><div=
>it crashes without this change. It does not crash with it, or without=A0</=
div>
<div>the command line parameter.</div><div><br></div><div>Perhaps they are =
unrelated.</div></div><div><br></div><div>=A0</div><blockquote class=3D"gma=
il_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-lef=
t:1ex">

<br>
But - with S3 working again (with the change here) or originally,<br>
did you ever check whether post-resume Dom0 vCPU-s would<br>
still be pinned? I suspect they aren&#39;t, and hence addressing the<br>
crash may likely be achieved by properly restoring the pinning.<br></blockq=
uote><div><br></div><div><div>No, I don&#39;t believe they are pinned after=
 resume...so while I=A0</div><div>suppose it is not entirely correct, it is=
 also better than crashing.</div>
</div><div><br></div><div>(it is also the observed behavior in Xen-4.0.x)</=
div><div>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .=
8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
Jan<br>
<br>
</font></span></blockquote></div><br>

--90e6ba61458207654c04ca889701--


--===============1308885078197106040==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============1308885078197106040==--


From xen-devel-bounces@lists.xen.org Tue Sep 25 15:47:39 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 15: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 1TGXM7-0007tv-F2; Tue, 25 Sep 2012 15:47:27 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <linux@eikelenboom.it>) id 1TGXM5-0007tq-Nd
	for xen-devel@lists.xensource.com; Tue, 25 Sep 2012 15:47:25 +0000
Received: from [85.158.139.211:6248] by server-14.bemta-5.messagelabs.com id
	5C/53-05772-D02D1605; Tue, 25 Sep 2012 15:47:25 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-15.tower-206.messagelabs.com!1348588044!19970932!1
X-Originating-IP: [188.40.164.121]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19723 invoked from network); 25 Sep 2012 15:47:24 -0000
Received: from static.121.164.40.188.clients.your-server.de (HELO
	smtp.eikelenboom.it) (188.40.164.121)
	by server-15.tower-206.messagelabs.com with AES256-SHA encrypted SMTP;
	25 Sep 2012 15:47:24 -0000
Received: from 132-64-ftth.onsneteindhoven.nl ([88.159.64.132]:51980
	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 1TGXMp-0007WL-7f; Tue, 25 Sep 2012 17:48:11 +0200
Date: Tue, 25 Sep 2012 17:47:21 +0200
From: Sander Eikelenboom <linux@eikelenboom.it>
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <148921897.20120925174721@eikelenboom.it>
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1348586949.12592.10.camel@zakaz.uk.xensource.com>
References: <patchbomb.1346960486@xentest.example.org>
	<1348565712.3452.141.camel@zakaz.uk.xensource.com>
	<15210025463.20120925171143@eikelenboom.it>
	<1348586949.12592.10.camel@zakaz.uk.xensource.com>
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 0 of 3] xl and hotplug: Introduce and use
	shutdown and reboot xm compatibility options
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


Tuesday, September 25, 2012, 5:29:09 PM, you wrote:

> On Tue, 2012-09-25 at 16:11 +0100, Sander Eikelenboom wrote:

>> The only relative simple implementation i thought of was direct
>> shutting down all, and when the -w parameter was set, just loop and
>> wait on events until the only running domain is domain-0.
>> Although this exactly does what has to be done, it somehow sounds a
>> bit dirty.

> I think you can allocate an array of libxl_evenable_domain_death*, of
> nr_doms in size and then as you shutdown each domain call
> libxl_evenable_domain_death for it too.

> Then you loop waiting for destroy events, calling
> libxl_evdisable_domain_death as each domain dies, while counting back
> from nr_doms until 0. When it reaches 0 everything you asked for has
> been shutdown.

Depends a bit on what you expect -a to do, especially in combination with -w.
The wait gives quite a window for a new guest to be created in the mean time.

The usage in the init.d/xendomains script is as a sort of "catch all", since the iteration is in the script it self.
So for that purpose i would assume that a "xl shutdown -a -w" would shutdown all domains until only dom-0 remains, and not only shutdown the domains that were running at the time the command was actually issued.

> Or something like that, I've not actually implemented 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 Sep 25 15:47:39 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 15: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 1TGXM7-0007tv-F2; Tue, 25 Sep 2012 15:47:27 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <linux@eikelenboom.it>) id 1TGXM5-0007tq-Nd
	for xen-devel@lists.xensource.com; Tue, 25 Sep 2012 15:47:25 +0000
Received: from [85.158.139.211:6248] by server-14.bemta-5.messagelabs.com id
	5C/53-05772-D02D1605; Tue, 25 Sep 2012 15:47:25 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-15.tower-206.messagelabs.com!1348588044!19970932!1
X-Originating-IP: [188.40.164.121]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19723 invoked from network); 25 Sep 2012 15:47:24 -0000
Received: from static.121.164.40.188.clients.your-server.de (HELO
	smtp.eikelenboom.it) (188.40.164.121)
	by server-15.tower-206.messagelabs.com with AES256-SHA encrypted SMTP;
	25 Sep 2012 15:47:24 -0000
Received: from 132-64-ftth.onsneteindhoven.nl ([88.159.64.132]:51980
	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 1TGXMp-0007WL-7f; Tue, 25 Sep 2012 17:48:11 +0200
Date: Tue, 25 Sep 2012 17:47:21 +0200
From: Sander Eikelenboom <linux@eikelenboom.it>
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <148921897.20120925174721@eikelenboom.it>
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1348586949.12592.10.camel@zakaz.uk.xensource.com>
References: <patchbomb.1346960486@xentest.example.org>
	<1348565712.3452.141.camel@zakaz.uk.xensource.com>
	<15210025463.20120925171143@eikelenboom.it>
	<1348586949.12592.10.camel@zakaz.uk.xensource.com>
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 0 of 3] xl and hotplug: Introduce and use
	shutdown and reboot xm compatibility options
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


Tuesday, September 25, 2012, 5:29:09 PM, you wrote:

> On Tue, 2012-09-25 at 16:11 +0100, Sander Eikelenboom wrote:

>> The only relative simple implementation i thought of was direct
>> shutting down all, and when the -w parameter was set, just loop and
>> wait on events until the only running domain is domain-0.
>> Although this exactly does what has to be done, it somehow sounds a
>> bit dirty.

> I think you can allocate an array of libxl_evenable_domain_death*, of
> nr_doms in size and then as you shutdown each domain call
> libxl_evenable_domain_death for it too.

> Then you loop waiting for destroy events, calling
> libxl_evdisable_domain_death as each domain dies, while counting back
> from nr_doms until 0. When it reaches 0 everything you asked for has
> been shutdown.

Depends a bit on what you expect -a to do, especially in combination with -w.
The wait gives quite a window for a new guest to be created in the mean time.

The usage in the init.d/xendomains script is as a sort of "catch all", since the iteration is in the script it self.
So for that purpose i would assume that a "xl shutdown -a -w" would shutdown all domains until only dom-0 remains, and not only shutdown the domains that were running at the time the command was actually issued.

> Or something like that, I've not actually implemented 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 Sep 25 15:48:34 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 15:48:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGXMy-0007yi-U5; Tue, 25 Sep 2012 15:48: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 1TGXMx-0007yT-Bl
	for xen-devel@lists.xensource.com; Tue, 25 Sep 2012 15:48:19 +0000
Received: from [85.158.143.99:36516] by server-2.bemta-4.messagelabs.com id
	9B/55-06610-242D1605; Tue, 25 Sep 2012 15:48:18 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1348588097!25609043!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTEwNzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12297 invoked from network); 25 Sep 2012 15:48:18 -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;
	25 Sep 2012 15:48:18 -0000
X-IronPort-AV: E=Sophos;i="4.80,484,1344211200"; d="scan'208";a="14755459"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Sep 2012 15:48: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.279.1; Tue, 25 Sep 2012 16:48: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
	1TGXMv-0000o1-2M; Tue, 25 Sep 2012 15:48:17 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1TGXMu-0006eK-UC;
	Tue, 25 Sep 2012 16:48:16 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20577.53824.594060.355136@mariner.uk.xensource.com>
Date: Tue, 25 Sep 2012 16:48:16 +0100
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1348586949.12592.10.camel@zakaz.uk.xensource.com>
References: <patchbomb.1346960486@xentest.example.org>
	<1348565712.3452.141.camel@zakaz.uk.xensource.com>
	<15210025463.20120925171143@eikelenboom.it>
	<1348586949.12592.10.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Sander Eikelenboom <linux@eikelenboom.it>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 0 of 3] xl and hotplug: Introduce and use
 shutdown and reboot xm compatibility options
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("Re: [PATCH 0 of 3] xl and hotplug: Introduce and use shutdown and reboot xm compatibility options"):
> On Tue, 2012-09-25 at 16:11 +0100, Sander Eikelenboom wrote:
> > The only relative simple implementation i thought of was direct
> > shutting down all, and when the -w parameter was set, just loop and
> > wait on events until the only running domain is domain-0.
> > Although this exactly does what has to be done, it somehow sounds a
> > bit dirty.
> 
> I think you can allocate an array of libxl_evenable_domain_death*, of
> nr_doms in size and then as you shutdown each domain call
> libxl_evenable_domain_death for it too.

Yes.

> Then you loop waiting for destroy events, calling
> libxl_evdisable_domain_death as each domain dies, while counting back
> from nr_doms until 0. When it reaches 0 everything you asked for has
> been shutdown.

You can do the disable any time later; leaving it lying around is
harmless (although it may leak some memory).

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 25 15:48:34 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 15:48:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGXMy-0007yi-U5; Tue, 25 Sep 2012 15:48: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 1TGXMx-0007yT-Bl
	for xen-devel@lists.xensource.com; Tue, 25 Sep 2012 15:48:19 +0000
Received: from [85.158.143.99:36516] by server-2.bemta-4.messagelabs.com id
	9B/55-06610-242D1605; Tue, 25 Sep 2012 15:48:18 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1348588097!25609043!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTEwNzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12297 invoked from network); 25 Sep 2012 15:48:18 -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;
	25 Sep 2012 15:48:18 -0000
X-IronPort-AV: E=Sophos;i="4.80,484,1344211200"; d="scan'208";a="14755459"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Sep 2012 15:48: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.279.1; Tue, 25 Sep 2012 16:48: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
	1TGXMv-0000o1-2M; Tue, 25 Sep 2012 15:48:17 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1TGXMu-0006eK-UC;
	Tue, 25 Sep 2012 16:48:16 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20577.53824.594060.355136@mariner.uk.xensource.com>
Date: Tue, 25 Sep 2012 16:48:16 +0100
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1348586949.12592.10.camel@zakaz.uk.xensource.com>
References: <patchbomb.1346960486@xentest.example.org>
	<1348565712.3452.141.camel@zakaz.uk.xensource.com>
	<15210025463.20120925171143@eikelenboom.it>
	<1348586949.12592.10.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Sander Eikelenboom <linux@eikelenboom.it>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 0 of 3] xl and hotplug: Introduce and use
 shutdown and reboot xm compatibility options
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("Re: [PATCH 0 of 3] xl and hotplug: Introduce and use shutdown and reboot xm compatibility options"):
> On Tue, 2012-09-25 at 16:11 +0100, Sander Eikelenboom wrote:
> > The only relative simple implementation i thought of was direct
> > shutting down all, and when the -w parameter was set, just loop and
> > wait on events until the only running domain is domain-0.
> > Although this exactly does what has to be done, it somehow sounds a
> > bit dirty.
> 
> I think you can allocate an array of libxl_evenable_domain_death*, of
> nr_doms in size and then as you shutdown each domain call
> libxl_evenable_domain_death for it too.

Yes.

> Then you loop waiting for destroy events, calling
> libxl_evdisable_domain_death as each domain dies, while counting back
> from nr_doms until 0. When it reaches 0 everything you asked for has
> been shutdown.

You can do the disable any time later; leaving it lying around is
harmless (although it may leak some memory).

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 25 15:49:23 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 15: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 1TGXNq-000857-D8; Tue, 25 Sep 2012 15:49:14 +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 1TGXNp-00084z-KT
	for xen-devel@lists.xen.org; Tue, 25 Sep 2012 15:49:13 +0000
Received: from [85.158.138.51:44267] by server-6.bemta-3.messagelabs.com id
	7D/89-29694-872D1605; Tue, 25 Sep 2012 15:49:12 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1348588152!23047016!1
X-Originating-IP: [74.125.83.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8884 invoked from network); 25 Sep 2012 15:49:12 -0000
Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com)
	(74.125.83.45)
	by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Sep 2012 15:49:12 -0000
Received: by eekb47 with SMTP id b47so1359999eek.32
	for <xen-devel@lists.xen.org>; Tue, 25 Sep 2012 08:49:12 -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=e3ki9+bIUbABjIQcmmiA52pdlWJ6M97MbygPRMAnfUw=;
	b=DUjCCuVVF7Sy5DbOsvdKsXIvKGcT5Z3a7kS0NTi6EFEut4meAzgrNu7SoMtryDo+DK
	YHFdf6+qJwDXPmbvhiMAiRPUePB1Jv38pH85a6QbtAEa3LDCFBduh4GgO1yTN4Qt03MM
	nScwNmTqF5SBI6F/B0TD7av0UT2kD/Ys9UUSGh/6chiqMetSLnuyFH4uHJdSde2MFU7F
	OYakTSOpgGXYgwKOndU5PfNiw9NbcsgfBK/UBjP8XCz3vc2wfQh3hi7nJ6Ny/89Rly4A
	4tNUvN5+nIEq2IaDyUVjaEOWARM3fa751V+b8wxl1osAz4KudT7AEc60+I/MTf80Jify
	NtkQ==
Received: by 10.14.199.67 with SMTP id w43mr21093843een.33.1348588152041;
	Tue, 25 Sep 2012 08:49:12 -0700 (PDT)
Received: from [192.168.1.3] (host86-167-82-156.range86-167.btcentralplus.com.
	[86.167.82.156])
	by mx.google.com with ESMTPS id v3sm1893949eep.10.2012.09.25.08.49.06
	(version=SSLv3 cipher=OTHER); Tue, 25 Sep 2012 08:49:11 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.33.0.120411
Date: Tue, 25 Sep 2012 16:48:59 +0100
From: Keir Fraser <keir@xen.org>
To: Jan Beulich <JBeulich@suse.com>,
	xen-devel <xen-devel@lists.xen.org>
Message-ID: <CC8790FB.4CD98%keir@xen.org>
Thread-Topic: [Xen-devel] [PATCH] x86: slightly improve stack trace on debug
	builds
Thread-Index: Ac2bNUb6j6/dHQsWzkSzyg3vSu/9Yw==
In-Reply-To: <5061E4CF020000780009DB98@nat28.tlf.novell.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] [PATCH] x86: slightly improve stack trace on debug
 builds
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/09/2012 16:07, "Jan Beulich" <JBeulich@suse.com> wrote:

> +    addr = regs->eip;
> +    while ( !is_kernel_text(addr) &&
> +            (system_state > SYS_STATE_boot || !is_kernel_inittext(addr)) )
> +    {
> +        /* Special case when a bad pointer was called. */
> +        addr ^= regs->eip ^ *ESP_BEFORE_EXCEPTION(regs);
> +        if ( addr == regs->eip )
> +            break;
> +    }

Lol, how does your brain work this way? It took me 15 minutes to decode this
to something like (also I added range checks on ESP_BEFORE_EXCEPTION(regs),
what do you think?):

bool_t is_current_kernel_text(unsigned long addr)
{
    return (is_kernel_text(addr) ||
            (system_state == SYS_STATE_boot && is_kernel_inittext(addr)));
}

...

/*
 * If RIP is not valid hypervisor code then someone may have called into
 * oblivion. Peek to see if they left a return address at top of stack.
 */
addr = (!is_current_kernel_text(regs->eip) &&
        (ESP_BEFORE_EXCEPTION(regs) >= low) &&
        (ESP_BEFORE_EXCEPTION(regs) < high) &&
        is_current_kernel_text(*ESP_BEFORE_EXCEPTION(regs)))
       ? *ESP_BEFORE_EXCEPTION(regs) : regs->eip;



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 25 15:49:23 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 15: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 1TGXNq-000857-D8; Tue, 25 Sep 2012 15:49:14 +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 1TGXNp-00084z-KT
	for xen-devel@lists.xen.org; Tue, 25 Sep 2012 15:49:13 +0000
Received: from [85.158.138.51:44267] by server-6.bemta-3.messagelabs.com id
	7D/89-29694-872D1605; Tue, 25 Sep 2012 15:49:12 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1348588152!23047016!1
X-Originating-IP: [74.125.83.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8884 invoked from network); 25 Sep 2012 15:49:12 -0000
Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com)
	(74.125.83.45)
	by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Sep 2012 15:49:12 -0000
Received: by eekb47 with SMTP id b47so1359999eek.32
	for <xen-devel@lists.xen.org>; Tue, 25 Sep 2012 08:49:12 -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=e3ki9+bIUbABjIQcmmiA52pdlWJ6M97MbygPRMAnfUw=;
	b=DUjCCuVVF7Sy5DbOsvdKsXIvKGcT5Z3a7kS0NTi6EFEut4meAzgrNu7SoMtryDo+DK
	YHFdf6+qJwDXPmbvhiMAiRPUePB1Jv38pH85a6QbtAEa3LDCFBduh4GgO1yTN4Qt03MM
	nScwNmTqF5SBI6F/B0TD7av0UT2kD/Ys9UUSGh/6chiqMetSLnuyFH4uHJdSde2MFU7F
	OYakTSOpgGXYgwKOndU5PfNiw9NbcsgfBK/UBjP8XCz3vc2wfQh3hi7nJ6Ny/89Rly4A
	4tNUvN5+nIEq2IaDyUVjaEOWARM3fa751V+b8wxl1osAz4KudT7AEc60+I/MTf80Jify
	NtkQ==
Received: by 10.14.199.67 with SMTP id w43mr21093843een.33.1348588152041;
	Tue, 25 Sep 2012 08:49:12 -0700 (PDT)
Received: from [192.168.1.3] (host86-167-82-156.range86-167.btcentralplus.com.
	[86.167.82.156])
	by mx.google.com with ESMTPS id v3sm1893949eep.10.2012.09.25.08.49.06
	(version=SSLv3 cipher=OTHER); Tue, 25 Sep 2012 08:49:11 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.33.0.120411
Date: Tue, 25 Sep 2012 16:48:59 +0100
From: Keir Fraser <keir@xen.org>
To: Jan Beulich <JBeulich@suse.com>,
	xen-devel <xen-devel@lists.xen.org>
Message-ID: <CC8790FB.4CD98%keir@xen.org>
Thread-Topic: [Xen-devel] [PATCH] x86: slightly improve stack trace on debug
	builds
Thread-Index: Ac2bNUb6j6/dHQsWzkSzyg3vSu/9Yw==
In-Reply-To: <5061E4CF020000780009DB98@nat28.tlf.novell.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] [PATCH] x86: slightly improve stack trace on debug
 builds
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/09/2012 16:07, "Jan Beulich" <JBeulich@suse.com> wrote:

> +    addr = regs->eip;
> +    while ( !is_kernel_text(addr) &&
> +            (system_state > SYS_STATE_boot || !is_kernel_inittext(addr)) )
> +    {
> +        /* Special case when a bad pointer was called. */
> +        addr ^= regs->eip ^ *ESP_BEFORE_EXCEPTION(regs);
> +        if ( addr == regs->eip )
> +            break;
> +    }

Lol, how does your brain work this way? It took me 15 minutes to decode this
to something like (also I added range checks on ESP_BEFORE_EXCEPTION(regs),
what do you think?):

bool_t is_current_kernel_text(unsigned long addr)
{
    return (is_kernel_text(addr) ||
            (system_state == SYS_STATE_boot && is_kernel_inittext(addr)));
}

...

/*
 * If RIP is not valid hypervisor code then someone may have called into
 * oblivion. Peek to see if they left a return address at top of stack.
 */
addr = (!is_current_kernel_text(regs->eip) &&
        (ESP_BEFORE_EXCEPTION(regs) >= low) &&
        (ESP_BEFORE_EXCEPTION(regs) < high) &&
        is_current_kernel_text(*ESP_BEFORE_EXCEPTION(regs)))
       ? *ESP_BEFORE_EXCEPTION(regs) : regs->eip;



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 25 15:50:09 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 15: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 1TGXOV-0008A8-R5; Tue, 25 Sep 2012 15:49:55 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1TGXOU-00089m-Bi
	for xen-devel@lists.xensource.com; Tue, 25 Sep 2012 15:49:54 +0000
Received: from [85.158.139.211:21320] by server-10.bemta-5.messagelabs.com id
	5F/1B-16911-C92D1605; Tue, 25 Sep 2012 15:49:48 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-206.messagelabs.com!1348588187!19865434!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTEwNzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28602 invoked from network); 25 Sep 2012 15:49:47 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Sep 2012 15:49:47 -0000
X-IronPort-AV: E=Sophos;i="4.80,484,1344211200"; d="scan'208";a="14755514"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Sep 2012 15:49: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.279.1; Tue, 25 Sep 2012 16:49: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
	1TGXOM-0000oS-Qt; Tue, 25 Sep 2012 15:49:46 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1TGXOM-0006eS-NA;
	Tue, 25 Sep 2012 16:49:46 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20577.53914.614083.759471@mariner.uk.xensource.com>
Date: Tue, 25 Sep 2012 16:49:46 +0100
To: Sander Eikelenboom <linux@eikelenboom.it>
In-Reply-To: <148921897.20120925174721@eikelenboom.it>
References: <patchbomb.1346960486@xentest.example.org>
	<1348565712.3452.141.camel@zakaz.uk.xensource.com>
	<15210025463.20120925171143@eikelenboom.it>
	<1348586949.12592.10.camel@zakaz.uk.xensource.com>
	<148921897.20120925174721@eikelenboom.it>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH 0 of 3] xl and hotplug: Introduce and use
 shutdown and reboot xm compatibility options
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Sander Eikelenboom writes ("Re: [PATCH 0 of 3] xl and hotplug: Introduce and use shutdown and reboot xm compatibility options"):
> Depends a bit on what you expect -a to do, especially in combination with -w.
> The wait gives quite a window for a new guest to be created in the mean time.

I guess.  I think it would be acceptable to say "don't do that then"
but your argument has merit.

If you go down this route, you'll need to remember which domains
you've asked for shutdown for.  I'm not sure that asking again is
safe.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 25 15:50:09 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 15: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 1TGXOV-0008A8-R5; Tue, 25 Sep 2012 15:49:55 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1TGXOU-00089m-Bi
	for xen-devel@lists.xensource.com; Tue, 25 Sep 2012 15:49:54 +0000
Received: from [85.158.139.211:21320] by server-10.bemta-5.messagelabs.com id
	5F/1B-16911-C92D1605; Tue, 25 Sep 2012 15:49:48 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-206.messagelabs.com!1348588187!19865434!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTEwNzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28602 invoked from network); 25 Sep 2012 15:49:47 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Sep 2012 15:49:47 -0000
X-IronPort-AV: E=Sophos;i="4.80,484,1344211200"; d="scan'208";a="14755514"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Sep 2012 15:49: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.279.1; Tue, 25 Sep 2012 16:49: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
	1TGXOM-0000oS-Qt; Tue, 25 Sep 2012 15:49:46 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1TGXOM-0006eS-NA;
	Tue, 25 Sep 2012 16:49:46 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20577.53914.614083.759471@mariner.uk.xensource.com>
Date: Tue, 25 Sep 2012 16:49:46 +0100
To: Sander Eikelenboom <linux@eikelenboom.it>
In-Reply-To: <148921897.20120925174721@eikelenboom.it>
References: <patchbomb.1346960486@xentest.example.org>
	<1348565712.3452.141.camel@zakaz.uk.xensource.com>
	<15210025463.20120925171143@eikelenboom.it>
	<1348586949.12592.10.camel@zakaz.uk.xensource.com>
	<148921897.20120925174721@eikelenboom.it>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH 0 of 3] xl and hotplug: Introduce and use
 shutdown and reboot xm compatibility options
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Sander Eikelenboom writes ("Re: [PATCH 0 of 3] xl and hotplug: Introduce and use shutdown and reboot xm compatibility options"):
> Depends a bit on what you expect -a to do, especially in combination with -w.
> The wait gives quite a window for a new guest to be created in the mean time.

I guess.  I think it would be acceptable to say "don't do that then"
but your argument has merit.

If you go down this route, you'll need to remember which domains
you've asked for shutdown for.  I'm not sure that asking again is
safe.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 25 15:52:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 15: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 1TGXQd-0008PM-Bl; Tue, 25 Sep 2012 15:52:07 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <matthew.fioravante@jhuapl.edu>) id 1TGXQb-0008P9-Mh
	for xen-devel@lists.xensource.com; Tue, 25 Sep 2012 15:52:06 +0000
Received: from [85.158.137.99:32210] by server-16.bemta-3.messagelabs.com id
	CD/B9-31776-423D1605; Tue, 25 Sep 2012 15:52:04 +0000
X-Env-Sender: matthew.fioravante@jhuapl.edu
X-Msg-Ref: server-11.tower-217.messagelabs.com!1348588322!17885701!1
X-Originating-IP: [128.244.251.36]
X-SpamReason: No, hits=0.0 required=7.0 tests=UNPARSEABLE_RELAY
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21455 invoked from network); 25 Sep 2012 15:52:03 -0000
Received: from pilot.jhuapl.edu (HELO jhuapl.edu) (128.244.251.36)
	by server-11.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 25 Sep 2012 15:52:03 -0000
Received: from ([128.244.207.89])
	by pilot.jhuapl.edu with ESMTP with TLS id 63GHCH1.153616572;
	Tue, 25 Sep 2012 11:51:54 -0400
Message-ID: <5061D2CC.3030108@jhuapl.edu>
Date: Tue, 25 Sep 2012 11:50:36 -0400
From: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120827 Thunderbird/15.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <50576368.3070007@jhuapl.edu>
	<1347953926.25803.89.camel@dagon.hellion.org.uk>
	<5058B07C.1070404@jhuapl.edu>
	<1348566822.3452.151.camel@zakaz.uk.xensource.com>
In-Reply-To: <1348566822.3452.151.camel@zakaz.uk.xensource.com>
X-Enigmail-Version: 1.4.4
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] Upgrade vtpmd to berlios version 0.7.4
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0416596930193482670=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a cryptographically signed message in MIME format.

--===============0416596930193482670==
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms070008050603070808090403"

This is a cryptographically signed message in MIME format.

--------------ms070008050603070808090403
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 09/25/2012 05:53 AM, Ian Campbell wrote:
> I just realised while looking at your reposting of this that I never
> replied here, sorry.
>
> On Tue, 2012-09-18 at 18:33 +0100, Matthew Fioravante wrote:
>
>
>>> Perhaps we should consider making this stuff an external dependency
>>> rather than importing it into our code base? This could be done eithe=
r
>>> as a simple dependency (i.e. require vtpm to be installed before
>>> building) or as a repo cloned during build (like how we handle qemu a=
nd
>>> seabios etc).
>>>
>> This might be workable. The vtpm system has 2 mini-so stubdoms and 3
>> mini-os tpm drivers. Does mini-os/stubdom have a nice way of building
>> stuff out of tree? It doesn't appear so at the moment.
> No I don't think it does :-(
>
>>  The whole stubdom setup is basically one large monolithic makefile.
>> vtpm domains also require building openssl, polarssl, and libgmp in
>> the stubdom cross root.
>>
>> Should the tpm drivers should be included in mini-os for potential use=

>> by other projects or also kept in their own separate tree? They are
>> GPL drivers so maybe out of tree makes more sense.
>>
>> vtpmd and vtpm_managerdom (deprecated, the old way of running vtpms as=

>> processes in dom0, instead of separate domains) could easily be moved
>> out of tree. They are just binaries installed on the system.
> Right, this was the main bit I was thinking of.
>
> I think what I didn't appreciate is that the stub domains also build
> this vtm stuff as well as the drivers, is that right? If we need the
> source for stubdoms we might as well have it for vtpmd
>
> Architectural question: Am I right that vtpmd is a host wide daemon for=

> mediating access to the real TPM while vtpm_managerdom (or one of the
> stubdom types?) are responsible for the tpm emulation for a single
> domain -- they communicate with vtpmd to get stuff done?
>
> Is there also a stubdom which can take on the vtpmd role?
>
> Removing vtpm_managerdom sounds like a win to me, assuming it is
> acceptable to require the use of stubdoms for vtpm functionality. Is it=
?
the vtpm manager takes control of the tpm and protects the secrets of
vtpms. Each vtpm emulates a tpm for a virtual machine.

There are basically 3 models that have developed over time:
Process model (deprecated?):
This is the old model that was originally with xen which I also provide
bug fixes for. vtpm_manager is the manager that controls the tpm. There
is one vtpmd process launched for each virtual tpm. Both vtpmd and
vtpm_manager are processes in dom0.

Hybrid model (deprecated?):
This was the beginning of our internal development. Now vtpm_manager
runs in dom0, but there is one vtpm-stubdom instance for each vtpm. It
worked via enabling a #define in the vtpm_manager makefile. This was
developed as an incremental stepping stone to the full domain model.

Domain model:
vtpmmgrdom is now a mini-os domain. It  uses pieces of the vtpm_manager
code. vtpm-stubdom is the same as before except now it talks to the
manager dom. The vtpmmgrdom also has a hardware tpm driver and with
iomem passthrough, so that dom0 is completely removed from the vtpm chain=
=2E

Internally we only use the domain model because of the higher security
guarantees it provides. It would be much nicer from a maintenance
perspective also to get rid of the process and hybrid models. I don't
think my latest patches to xl even work with the process model anymore.

I don't know if there is anyone who would want to still use vtpms as
processes when the stub domains are now available. Security research
people like the domain model because it guarantees a better separation
of components guaranteed by the hypervisor and doesn't have to trust the
dom0 OS.

If we got rid of the process and hybrid model, then the
tools/vtpm_manager code that is still used could be moved into the
vtpmmgrdom stubdom codebase. tools/vtpm could be completely removed
along with the --enable-vtpm stuff in the configure script and the cmake
dependency.

>
>> vtpm support for xm/xl probably has to stay in xen. Unless someone
>> plans on making a plugin architecture for xl. There are also the
>> hotplug scripts, but those go away with xl.
>>
>>>> The first patch I'd like to submit upgrades vtpmd to version 0.7.4
>>>>
>>>> This patch does the following:
>>>> -add checks to configure to check for cmake (required by berlios 0.7=
=2E4)
>>> Is the model with cmake that it is required on all the end systems
>>> building the project (like make), or is it only needed on the project=

>>> maintainer's system (like autoconf/make)?
>> Its the equivalent of running a configure script, so its needed on end=

>> systems.
> That's a shame, but unavoidable I suppose..=20
>
>>  Also you have to download and patch the tpm emulator before running
>> cmake, so if we did want to avoid its usage on end systems we would
>> have to ship the entire source code of the patched emulator.
>>>> -removes all of the 0.5.1 patches
>>>> -adds a single patch for 0.7.4
>>>> -cleans up the makefile, should work for parallel make (avoiding
>>>> version.h discussion from august 2012)
>>>> -builds vtpmd to use berlios 0.7.4
>>>> -Remoed the tpm_emualtor build option. berlios itself provides a ker=
nel
>>>> module if you want to use it in dom0 to emulate the physical tpm.
>>> Is there going to be an associated documentation update/refresh?
>> Right now I don't have a formal doc but I want to write one. I'm
>> looking into getting some time to do this.
> Thanks.
>
> Ian.
>



--------------ms070008050603070808090403
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIDyjCC
A8YwggMvoAMCAQICBD/xyf0wDQYJKoZIhvcNAQEFBQAwLzELMAkGA1UEBhMCVVMxDzANBgNV
BAoTBkpIVUFQTDEPMA0GA1UECxMGQklTRENBMB4XDTEwMDYxMTE4MjIwNloXDTEzMDYxMTE4
NTIwNlowZjELMAkGA1UEBhMCVVMxDzANBgNVBAoTBkpIVUFQTDEPMA0GA1UECxMGUGVvcGxl
MTUwFgYDVQQLEw9WUE5Hcm91cC1CSVNEQ0EwGwYDVQQDExRNYXR0aGV3IEUgRmlvcmF2YW50
ZTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAnpbwVSP6o1Nb5lcW7dd3yTo9iBJdi7qz
4nANOMFPK7JOy5npKN1iiousl28U/scUJES55gPwAWYJK3uVyQAsA4adgDKi5DoD1UHDQEwp
bY7iHLJeq0NPr4BqYNqnCFPbE6HC8zSJrr4qKn+gVUQT39SIFqdiIPJwZL8FYTRQ/zsCAwEA
AaOCAbYwggGyMAsGA1UdDwQEAwIHgDArBgNVHRAEJDAigA8yMDEwMDYxMTE4MjIwNlqBDzIw
MTIwNzE3MjI1MjA2WjAbBg0rBgEEAbMlCwMBAQEBBAoWCGZpb3JhbWUxMBsGDSsGAQQBsyUL
AwEBAQIEChIIMDAxMDQyNjEwWAYJYIZIAYb6ax4BBEsMSVRoZSBwcml2YXRlIGtleSBjb3Jy
ZXNwb25kaW5nIHRvIHRoaXMgY2VydGlmaWNhdGUgbWF5IGhhdmUgYmVlbiBleHBvcnRlZC4w
KAYDVR0RBCEwH4EdTWF0dGhldy5GaW9yYXZhbnRlQGpodWFwbC5lZHUwUgYDVR0fBEswSTBH
oEWgQ6RBMD8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJU0RD
QTEOMAwGA1UEAxMFQ1JMNTYwHwYDVR0jBBgwFoAUCDUpmxH52EU2CyWmF2EJMB1yqeswHQYD
VR0OBBYEFO6LYxg6r9wHZ+zdQtBHn1dZ/YTNMAkGA1UdEwQCMAAwGQYJKoZIhvZ9B0EABAww
ChsEVjcuMQMCBLAwDQYJKoZIhvcNAQEFBQADgYEAJO9HQh4YNChVLzuZqK5ARJARD8JoujGZ
fdo75quvg2jXFQe2sEjvLnxJZgm/pv8fdZakq48CWwjYHKuvIp7sDjTEsQfo+y7SpN/N2NvJ
WU5SqfK1VgYtNLRRoGJUB5Q1aZ+Dg95g3kqpyfpUMISJL8IKVLtJVfN4fggFVUYZ9wwxggGr
MIIBpwIBATA3MC8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJ
U0RDQQIEP/HJ/TAJBgUrDgMCGgUAoIHLMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ
KoZIhvcNAQkFMQ8XDTEyMDkyNTE1NTAzNlowIwYJKoZIhvcNAQkEMRYEFGmKh0Fy8SEhW3SL
pmbBf37w0gDSMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAK
BggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI
KoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEgYBTQqmq6c96QiE3suAzqqXjrruxdVhv4jWV
9cp5af2yAOURB2DG4QgoE7+wjInc4TPFTVK1Lua2SGYVVWtIGNZljt5U1E5/cO+Bn53GGZ8e
dU4Ckn/DwOUbbyjfyueDKEaq3YrGu3cNQhdTXvmCuJe2FpoTL/4zMeWOFlt/SuB2HAAAAAAA
AA==
--------------ms070008050603070808090403--


--===============0416596930193482670==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============0416596930193482670==--


From xen-devel-bounces@lists.xen.org Tue Sep 25 15:52:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 15: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 1TGXQd-0008PM-Bl; Tue, 25 Sep 2012 15:52:07 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <matthew.fioravante@jhuapl.edu>) id 1TGXQb-0008P9-Mh
	for xen-devel@lists.xensource.com; Tue, 25 Sep 2012 15:52:06 +0000
Received: from [85.158.137.99:32210] by server-16.bemta-3.messagelabs.com id
	CD/B9-31776-423D1605; Tue, 25 Sep 2012 15:52:04 +0000
X-Env-Sender: matthew.fioravante@jhuapl.edu
X-Msg-Ref: server-11.tower-217.messagelabs.com!1348588322!17885701!1
X-Originating-IP: [128.244.251.36]
X-SpamReason: No, hits=0.0 required=7.0 tests=UNPARSEABLE_RELAY
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21455 invoked from network); 25 Sep 2012 15:52:03 -0000
Received: from pilot.jhuapl.edu (HELO jhuapl.edu) (128.244.251.36)
	by server-11.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 25 Sep 2012 15:52:03 -0000
Received: from ([128.244.207.89])
	by pilot.jhuapl.edu with ESMTP with TLS id 63GHCH1.153616572;
	Tue, 25 Sep 2012 11:51:54 -0400
Message-ID: <5061D2CC.3030108@jhuapl.edu>
Date: Tue, 25 Sep 2012 11:50:36 -0400
From: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120827 Thunderbird/15.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <50576368.3070007@jhuapl.edu>
	<1347953926.25803.89.camel@dagon.hellion.org.uk>
	<5058B07C.1070404@jhuapl.edu>
	<1348566822.3452.151.camel@zakaz.uk.xensource.com>
In-Reply-To: <1348566822.3452.151.camel@zakaz.uk.xensource.com>
X-Enigmail-Version: 1.4.4
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] Upgrade vtpmd to berlios version 0.7.4
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0416596930193482670=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a cryptographically signed message in MIME format.

--===============0416596930193482670==
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms070008050603070808090403"

This is a cryptographically signed message in MIME format.

--------------ms070008050603070808090403
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 09/25/2012 05:53 AM, Ian Campbell wrote:
> I just realised while looking at your reposting of this that I never
> replied here, sorry.
>
> On Tue, 2012-09-18 at 18:33 +0100, Matthew Fioravante wrote:
>
>
>>> Perhaps we should consider making this stuff an external dependency
>>> rather than importing it into our code base? This could be done eithe=
r
>>> as a simple dependency (i.e. require vtpm to be installed before
>>> building) or as a repo cloned during build (like how we handle qemu a=
nd
>>> seabios etc).
>>>
>> This might be workable. The vtpm system has 2 mini-so stubdoms and 3
>> mini-os tpm drivers. Does mini-os/stubdom have a nice way of building
>> stuff out of tree? It doesn't appear so at the moment.
> No I don't think it does :-(
>
>>  The whole stubdom setup is basically one large monolithic makefile.
>> vtpm domains also require building openssl, polarssl, and libgmp in
>> the stubdom cross root.
>>
>> Should the tpm drivers should be included in mini-os for potential use=

>> by other projects or also kept in their own separate tree? They are
>> GPL drivers so maybe out of tree makes more sense.
>>
>> vtpmd and vtpm_managerdom (deprecated, the old way of running vtpms as=

>> processes in dom0, instead of separate domains) could easily be moved
>> out of tree. They are just binaries installed on the system.
> Right, this was the main bit I was thinking of.
>
> I think what I didn't appreciate is that the stub domains also build
> this vtm stuff as well as the drivers, is that right? If we need the
> source for stubdoms we might as well have it for vtpmd
>
> Architectural question: Am I right that vtpmd is a host wide daemon for=

> mediating access to the real TPM while vtpm_managerdom (or one of the
> stubdom types?) are responsible for the tpm emulation for a single
> domain -- they communicate with vtpmd to get stuff done?
>
> Is there also a stubdom which can take on the vtpmd role?
>
> Removing vtpm_managerdom sounds like a win to me, assuming it is
> acceptable to require the use of stubdoms for vtpm functionality. Is it=
?
the vtpm manager takes control of the tpm and protects the secrets of
vtpms. Each vtpm emulates a tpm for a virtual machine.

There are basically 3 models that have developed over time:
Process model (deprecated?):
This is the old model that was originally with xen which I also provide
bug fixes for. vtpm_manager is the manager that controls the tpm. There
is one vtpmd process launched for each virtual tpm. Both vtpmd and
vtpm_manager are processes in dom0.

Hybrid model (deprecated?):
This was the beginning of our internal development. Now vtpm_manager
runs in dom0, but there is one vtpm-stubdom instance for each vtpm. It
worked via enabling a #define in the vtpm_manager makefile. This was
developed as an incremental stepping stone to the full domain model.

Domain model:
vtpmmgrdom is now a mini-os domain. It  uses pieces of the vtpm_manager
code. vtpm-stubdom is the same as before except now it talks to the
manager dom. The vtpmmgrdom also has a hardware tpm driver and with
iomem passthrough, so that dom0 is completely removed from the vtpm chain=
=2E

Internally we only use the domain model because of the higher security
guarantees it provides. It would be much nicer from a maintenance
perspective also to get rid of the process and hybrid models. I don't
think my latest patches to xl even work with the process model anymore.

I don't know if there is anyone who would want to still use vtpms as
processes when the stub domains are now available. Security research
people like the domain model because it guarantees a better separation
of components guaranteed by the hypervisor and doesn't have to trust the
dom0 OS.

If we got rid of the process and hybrid model, then the
tools/vtpm_manager code that is still used could be moved into the
vtpmmgrdom stubdom codebase. tools/vtpm could be completely removed
along with the --enable-vtpm stuff in the configure script and the cmake
dependency.

>
>> vtpm support for xm/xl probably has to stay in xen. Unless someone
>> plans on making a plugin architecture for xl. There are also the
>> hotplug scripts, but those go away with xl.
>>
>>>> The first patch I'd like to submit upgrades vtpmd to version 0.7.4
>>>>
>>>> This patch does the following:
>>>> -add checks to configure to check for cmake (required by berlios 0.7=
=2E4)
>>> Is the model with cmake that it is required on all the end systems
>>> building the project (like make), or is it only needed on the project=

>>> maintainer's system (like autoconf/make)?
>> Its the equivalent of running a configure script, so its needed on end=

>> systems.
> That's a shame, but unavoidable I suppose..=20
>
>>  Also you have to download and patch the tpm emulator before running
>> cmake, so if we did want to avoid its usage on end systems we would
>> have to ship the entire source code of the patched emulator.
>>>> -removes all of the 0.5.1 patches
>>>> -adds a single patch for 0.7.4
>>>> -cleans up the makefile, should work for parallel make (avoiding
>>>> version.h discussion from august 2012)
>>>> -builds vtpmd to use berlios 0.7.4
>>>> -Remoed the tpm_emualtor build option. berlios itself provides a ker=
nel
>>>> module if you want to use it in dom0 to emulate the physical tpm.
>>> Is there going to be an associated documentation update/refresh?
>> Right now I don't have a formal doc but I want to write one. I'm
>> looking into getting some time to do this.
> Thanks.
>
> Ian.
>



--------------ms070008050603070808090403
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIDyjCC
A8YwggMvoAMCAQICBD/xyf0wDQYJKoZIhvcNAQEFBQAwLzELMAkGA1UEBhMCVVMxDzANBgNV
BAoTBkpIVUFQTDEPMA0GA1UECxMGQklTRENBMB4XDTEwMDYxMTE4MjIwNloXDTEzMDYxMTE4
NTIwNlowZjELMAkGA1UEBhMCVVMxDzANBgNVBAoTBkpIVUFQTDEPMA0GA1UECxMGUGVvcGxl
MTUwFgYDVQQLEw9WUE5Hcm91cC1CSVNEQ0EwGwYDVQQDExRNYXR0aGV3IEUgRmlvcmF2YW50
ZTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAnpbwVSP6o1Nb5lcW7dd3yTo9iBJdi7qz
4nANOMFPK7JOy5npKN1iiousl28U/scUJES55gPwAWYJK3uVyQAsA4adgDKi5DoD1UHDQEwp
bY7iHLJeq0NPr4BqYNqnCFPbE6HC8zSJrr4qKn+gVUQT39SIFqdiIPJwZL8FYTRQ/zsCAwEA
AaOCAbYwggGyMAsGA1UdDwQEAwIHgDArBgNVHRAEJDAigA8yMDEwMDYxMTE4MjIwNlqBDzIw
MTIwNzE3MjI1MjA2WjAbBg0rBgEEAbMlCwMBAQEBBAoWCGZpb3JhbWUxMBsGDSsGAQQBsyUL
AwEBAQIEChIIMDAxMDQyNjEwWAYJYIZIAYb6ax4BBEsMSVRoZSBwcml2YXRlIGtleSBjb3Jy
ZXNwb25kaW5nIHRvIHRoaXMgY2VydGlmaWNhdGUgbWF5IGhhdmUgYmVlbiBleHBvcnRlZC4w
KAYDVR0RBCEwH4EdTWF0dGhldy5GaW9yYXZhbnRlQGpodWFwbC5lZHUwUgYDVR0fBEswSTBH
oEWgQ6RBMD8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJU0RD
QTEOMAwGA1UEAxMFQ1JMNTYwHwYDVR0jBBgwFoAUCDUpmxH52EU2CyWmF2EJMB1yqeswHQYD
VR0OBBYEFO6LYxg6r9wHZ+zdQtBHn1dZ/YTNMAkGA1UdEwQCMAAwGQYJKoZIhvZ9B0EABAww
ChsEVjcuMQMCBLAwDQYJKoZIhvcNAQEFBQADgYEAJO9HQh4YNChVLzuZqK5ARJARD8JoujGZ
fdo75quvg2jXFQe2sEjvLnxJZgm/pv8fdZakq48CWwjYHKuvIp7sDjTEsQfo+y7SpN/N2NvJ
WU5SqfK1VgYtNLRRoGJUB5Q1aZ+Dg95g3kqpyfpUMISJL8IKVLtJVfN4fggFVUYZ9wwxggGr
MIIBpwIBATA3MC8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJ
U0RDQQIEP/HJ/TAJBgUrDgMCGgUAoIHLMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ
KoZIhvcNAQkFMQ8XDTEyMDkyNTE1NTAzNlowIwYJKoZIhvcNAQkEMRYEFGmKh0Fy8SEhW3SL
pmbBf37w0gDSMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAK
BggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI
KoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEgYBTQqmq6c96QiE3suAzqqXjrruxdVhv4jWV
9cp5af2yAOURB2DG4QgoE7+wjInc4TPFTVK1Lua2SGYVVWtIGNZljt5U1E5/cO+Bn53GGZ8e
dU4Ckn/DwOUbbyjfyueDKEaq3YrGu3cNQhdTXvmCuJe2FpoTL/4zMeWOFlt/SuB2HAAAAAAA
AA==
--------------ms070008050603070808090403--


--===============0416596930193482670==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============0416596930193482670==--


From xen-devel-bounces@lists.xen.org Tue Sep 25 15:53:22 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 15: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 1TGXRi-00006G-18; Tue, 25 Sep 2012 15:53:14 +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 1TGXRg-00005m-HP
	for xen-devel@lists.xensource.com; Tue, 25 Sep 2012 15:53:12 +0000
Received: from [85.158.143.99:54750] by server-2.bemta-4.messagelabs.com id
	A7/2C-06610-763D1605; Tue, 25 Sep 2012 15:53:11 +0000
X-Env-Sender: lars.kurth.xen@gmail.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1348588389!30817600!1
X-Originating-IP: [74.125.83.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11122 invoked from network); 25 Sep 2012 15:53:09 -0000
Received: from mail-ee0-f43.google.com (HELO mail-ee0-f43.google.com)
	(74.125.83.43)
	by server-13.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Sep 2012 15:53:09 -0000
Received: by eekc13 with SMTP id c13so1492336eek.30
	for <multiple recipients>; Tue, 25 Sep 2012 08:53:09 -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=fpq6o0nxTX5d9OHIWcP3zpp70+r+zHRpz5GcjDPkx20=;
	b=BxHDtj0aE5it+BypAhyZzDsdr+vbtU7l4vM11kgh/zIRr1lTnkA36UcUfT7jcAuuEs
	X0/UqTWZEQAovq1guqno1216f7JEJn+ongCv7VYX488JkSqC13qFQxMLxuJveo1VI1UP
	loTo+kdpiTWXLc/P015y9f4IgPaXBPAsiQChNOp6si/r1t9jqAyI0lpVmpw1t9idvx3O
	Xf6EfRw5wA0CG6+/TuoMlNf5iNzvoPAt6ar1PJxMoStsJuv6XQMo/CbnFyC/71qT8Edr
	8psf1T0bjyMmxUsk8uK1k+sb4jfFTGM/Ltpae2FOvsfszK7Pg/kYN8znToQm9L9Djsws
	UErw==
Received: by 10.14.182.134 with SMTP id o6mr20974988eem.26.1348588389269;
	Tue, 25 Sep 2012 08:53:09 -0700 (PDT)
Received: from [172.16.26.11] (b0fb5b35.bb.sky.com. [176.251.91.53])
	by mx.google.com with ESMTPS id n17sm851881bks.6.2012.09.25.08.53.07
	(version=SSLv3 cipher=OTHER); Tue, 25 Sep 2012 08:53:08 -0700 (PDT)
Message-ID: <5061D362.8070402@xen.org>
Date: Tue, 25 Sep 2012 16:53:06 +0100
From: Lars Kurth <lars.kurth@xen.org>
User-Agent: Mozilla/5.0 (Windows NT 6.1;
	rv:15.0) Gecko/20120907 Thunderbird/15.0.1
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <CAGnmK4wB3ZJ3Tb9-VFgWCkcZNwibDzRYV8tvb14vLgw1wj2awQ@mail.gmail.com>
	<50607A68.2090604@xen.org>
	<1348561354.3452.105.camel@zakaz.uk.xensource.com>
	<2D15A521-63E8-4CE7-8D42-62A67FBD75B2@recoil.org>
	<1348583438.11229.23.camel@zakaz.uk.xensource.com>
In-Reply-To: <1348583438.11229.23.camel@zakaz.uk.xensource.com>
Cc: "xen-api@lists.xensource.com" <xen-api@lists.xensource.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Anil Madhavapeddy <anil@recoil.org>
Subject: Re: [Xen-devel] [Xen-API]  Proposal - Add xe manpages to xen-org
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: 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

T24gMjUvMDkvMjAxMiAxNTozMCwgSWFuIENhbXBiZWxsIHdyb3RlOgo+IEFjY29yZGluZyB0byB0
aGUgb3JpZ2luYWwgbWFpbCBpdCBpcyBpbiBhc2NpaWRvYyBhbHJlYWR5LCBzbyBtYXliZSAKPiB0
aGlzIGlzIGFscmVhZHkgdGhlIGNhc2U/Ck15IHVuZGVyc3RhbmRpbmcgaXMgdGhhdCB0aGUgZXhp
c3RpbmcgWGVuU2VydmVyL1hDUCBkb2NzIGFyZSBwcmltYXJpbHkgCnRhc2sgZHJpdmVuIChpLmUu
IOKAnHRvIGFjaGlldmUgWCB5b3UgZG8gWeKAnSkuIE1hbiBwYWdlcyBhcmUgcGVyIGNvbW1hbmQg
CnJlZmVyZW5jZXMgKGkuZS4g4oCcZG9pbmcgWSB3aWxsIGNhdXNlIFggdG8gaGFwcGVu4oCdKSwg
d2hpY2ggaXMgaGFyZGx5IApjb3ZlcmVkIGluCmV4aXN0aW5nIFhTIGRvY3VtZW50YXRpb24uCgo+
IEkgYWdyZWUgdGhhdCBhY3R1YWxseSBpbiB0aGUgc291cmNlIGlzIGV2ZW4gYmV0dGVyIHRoYW4g
bmV4dCB0byB0aGUKPiBzb3VyY2UsIGlmIGl0J3MgYW4gb3B0aW9uLi4uCj4KPj4gTWFudWFsbHkg
a2VlcGluZyB0aGUgemlsbGlvbiBjb21tYW5kcyBpbiBzeW5jIHdpbGwgYmUgcXVpdGUgdGhlIG9u
Z29pbmcKPj4gZWZmb3J0Lgo+IFNvbWVvbmUgc3RpbGwgbmVlZHMgdG8gd3JpdGUvdXBkYXRlIHRo
ZSB0ZXh0IHJlZ2FyZGxlc3Mgb2Ygd2hlcmUgaXQKPiBsaXZlcywgYnV0IHRoYXQncyBhcyBtdWNo
IGEgY29kZSByZXZpZXcgdGhpbmcgYXMgYW55dGhpbmcgZWxzZS4KPgpJIHdvdWxkbid0IHdhbnQg
dG8gY3JlYXRlIGEgYmFycmllciBmb3IgR3JhbnQncyBzdHVkZW50cyAob3Igb3RoZXIgCnBlb3Bs
ZSB0aGF0IHdhbnQgdG8gY29udHJpYnV0ZSkuIFJlbWVtYmVyIHRoYXQgbW9zdCBhcmUgbm90IGRl
dmVsb3BlcnMgCmJ1dCB1c2VycyBvZiBYQ1AuICBFbWJlZGRpbmcgdGhlIGRvY3VtZW50YXRpb24g
aW50byB0aGUgY29kZSB3b3VsZCBtZWFuOgphKSBleGlzdGluZyBkb2N1bWVudCBzb3VyY2UgY29k
ZSB3b3VsZCBuZWVkIHRvIGJlIHJlZmFjdG9yZWQKYikgaXQgd291bGQgY3JlYXRlIGEgcHN5Y2hv
bG9naWNhbCBiYXJyaWVyIHRvIGNvbnRyaWJ1dGUKYykgcG9zc2libHkgdW5uZWNlc3NhcnkgcHJv
Y2VzcwoKS2VlcGluZyB0aGUgZG9jdW1lbnRhdGlvbiBzZXBhcmF0ZSAoZWl0aGVyIGluIGEgc2Vw
YXJhdGUgcmVwbywgb3IgCmRpcmVjdG9yeSBpbiBhbiBleGlzdGluZyByZXBvKSBpcyBwcm9iYWJs
eSB0aGUgZWFzaWVzdCBhbmQgcXVpY2tlc3Qgd2F5IAp0byBnZXQgdGhpcyBwcm9qZWN0IG9mZiB0
aGUgZ3JvdW5kIHF1aWNrbHkuCgpMYXJzCgoKCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fXwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0
cy54ZW4ub3JnCmh0dHA6Ly9saXN0cy54ZW4ub3JnL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xen.org Tue Sep 25 15:53:22 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 15: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 1TGXRi-00006G-18; Tue, 25 Sep 2012 15:53:14 +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 1TGXRg-00005m-HP
	for xen-devel@lists.xensource.com; Tue, 25 Sep 2012 15:53:12 +0000
Received: from [85.158.143.99:54750] by server-2.bemta-4.messagelabs.com id
	A7/2C-06610-763D1605; Tue, 25 Sep 2012 15:53:11 +0000
X-Env-Sender: lars.kurth.xen@gmail.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1348588389!30817600!1
X-Originating-IP: [74.125.83.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11122 invoked from network); 25 Sep 2012 15:53:09 -0000
Received: from mail-ee0-f43.google.com (HELO mail-ee0-f43.google.com)
	(74.125.83.43)
	by server-13.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Sep 2012 15:53:09 -0000
Received: by eekc13 with SMTP id c13so1492336eek.30
	for <multiple recipients>; Tue, 25 Sep 2012 08:53:09 -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=fpq6o0nxTX5d9OHIWcP3zpp70+r+zHRpz5GcjDPkx20=;
	b=BxHDtj0aE5it+BypAhyZzDsdr+vbtU7l4vM11kgh/zIRr1lTnkA36UcUfT7jcAuuEs
	X0/UqTWZEQAovq1guqno1216f7JEJn+ongCv7VYX488JkSqC13qFQxMLxuJveo1VI1UP
	loTo+kdpiTWXLc/P015y9f4IgPaXBPAsiQChNOp6si/r1t9jqAyI0lpVmpw1t9idvx3O
	Xf6EfRw5wA0CG6+/TuoMlNf5iNzvoPAt6ar1PJxMoStsJuv6XQMo/CbnFyC/71qT8Edr
	8psf1T0bjyMmxUsk8uK1k+sb4jfFTGM/Ltpae2FOvsfszK7Pg/kYN8znToQm9L9Djsws
	UErw==
Received: by 10.14.182.134 with SMTP id o6mr20974988eem.26.1348588389269;
	Tue, 25 Sep 2012 08:53:09 -0700 (PDT)
Received: from [172.16.26.11] (b0fb5b35.bb.sky.com. [176.251.91.53])
	by mx.google.com with ESMTPS id n17sm851881bks.6.2012.09.25.08.53.07
	(version=SSLv3 cipher=OTHER); Tue, 25 Sep 2012 08:53:08 -0700 (PDT)
Message-ID: <5061D362.8070402@xen.org>
Date: Tue, 25 Sep 2012 16:53:06 +0100
From: Lars Kurth <lars.kurth@xen.org>
User-Agent: Mozilla/5.0 (Windows NT 6.1;
	rv:15.0) Gecko/20120907 Thunderbird/15.0.1
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <CAGnmK4wB3ZJ3Tb9-VFgWCkcZNwibDzRYV8tvb14vLgw1wj2awQ@mail.gmail.com>
	<50607A68.2090604@xen.org>
	<1348561354.3452.105.camel@zakaz.uk.xensource.com>
	<2D15A521-63E8-4CE7-8D42-62A67FBD75B2@recoil.org>
	<1348583438.11229.23.camel@zakaz.uk.xensource.com>
In-Reply-To: <1348583438.11229.23.camel@zakaz.uk.xensource.com>
Cc: "xen-api@lists.xensource.com" <xen-api@lists.xensource.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Anil Madhavapeddy <anil@recoil.org>
Subject: Re: [Xen-devel] [Xen-API]  Proposal - Add xe manpages to xen-org
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: 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

T24gMjUvMDkvMjAxMiAxNTozMCwgSWFuIENhbXBiZWxsIHdyb3RlOgo+IEFjY29yZGluZyB0byB0
aGUgb3JpZ2luYWwgbWFpbCBpdCBpcyBpbiBhc2NpaWRvYyBhbHJlYWR5LCBzbyBtYXliZSAKPiB0
aGlzIGlzIGFscmVhZHkgdGhlIGNhc2U/Ck15IHVuZGVyc3RhbmRpbmcgaXMgdGhhdCB0aGUgZXhp
c3RpbmcgWGVuU2VydmVyL1hDUCBkb2NzIGFyZSBwcmltYXJpbHkgCnRhc2sgZHJpdmVuIChpLmUu
IOKAnHRvIGFjaGlldmUgWCB5b3UgZG8gWeKAnSkuIE1hbiBwYWdlcyBhcmUgcGVyIGNvbW1hbmQg
CnJlZmVyZW5jZXMgKGkuZS4g4oCcZG9pbmcgWSB3aWxsIGNhdXNlIFggdG8gaGFwcGVu4oCdKSwg
d2hpY2ggaXMgaGFyZGx5IApjb3ZlcmVkIGluCmV4aXN0aW5nIFhTIGRvY3VtZW50YXRpb24uCgo+
IEkgYWdyZWUgdGhhdCBhY3R1YWxseSBpbiB0aGUgc291cmNlIGlzIGV2ZW4gYmV0dGVyIHRoYW4g
bmV4dCB0byB0aGUKPiBzb3VyY2UsIGlmIGl0J3MgYW4gb3B0aW9uLi4uCj4KPj4gTWFudWFsbHkg
a2VlcGluZyB0aGUgemlsbGlvbiBjb21tYW5kcyBpbiBzeW5jIHdpbGwgYmUgcXVpdGUgdGhlIG9u
Z29pbmcKPj4gZWZmb3J0Lgo+IFNvbWVvbmUgc3RpbGwgbmVlZHMgdG8gd3JpdGUvdXBkYXRlIHRo
ZSB0ZXh0IHJlZ2FyZGxlc3Mgb2Ygd2hlcmUgaXQKPiBsaXZlcywgYnV0IHRoYXQncyBhcyBtdWNo
IGEgY29kZSByZXZpZXcgdGhpbmcgYXMgYW55dGhpbmcgZWxzZS4KPgpJIHdvdWxkbid0IHdhbnQg
dG8gY3JlYXRlIGEgYmFycmllciBmb3IgR3JhbnQncyBzdHVkZW50cyAob3Igb3RoZXIgCnBlb3Bs
ZSB0aGF0IHdhbnQgdG8gY29udHJpYnV0ZSkuIFJlbWVtYmVyIHRoYXQgbW9zdCBhcmUgbm90IGRl
dmVsb3BlcnMgCmJ1dCB1c2VycyBvZiBYQ1AuICBFbWJlZGRpbmcgdGhlIGRvY3VtZW50YXRpb24g
aW50byB0aGUgY29kZSB3b3VsZCBtZWFuOgphKSBleGlzdGluZyBkb2N1bWVudCBzb3VyY2UgY29k
ZSB3b3VsZCBuZWVkIHRvIGJlIHJlZmFjdG9yZWQKYikgaXQgd291bGQgY3JlYXRlIGEgcHN5Y2hv
bG9naWNhbCBiYXJyaWVyIHRvIGNvbnRyaWJ1dGUKYykgcG9zc2libHkgdW5uZWNlc3NhcnkgcHJv
Y2VzcwoKS2VlcGluZyB0aGUgZG9jdW1lbnRhdGlvbiBzZXBhcmF0ZSAoZWl0aGVyIGluIGEgc2Vw
YXJhdGUgcmVwbywgb3IgCmRpcmVjdG9yeSBpbiBhbiBleGlzdGluZyByZXBvKSBpcyBwcm9iYWJs
eSB0aGUgZWFzaWVzdCBhbmQgcXVpY2tlc3Qgd2F5IAp0byBnZXQgdGhpcyBwcm9qZWN0IG9mZiB0
aGUgZ3JvdW5kIHF1aWNrbHkuCgpMYXJzCgoKCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fXwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0
cy54ZW4ub3JnCmh0dHA6Ly9saXN0cy54ZW4ub3JnL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xen.org Tue Sep 25 15:55:53 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 15:55:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGXU6-0000NG-Pc; Tue, 25 Sep 2012 15:55:42 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1TGXU4-0000Mo-Nj
	for xen-devel@lists.xen.org; Tue, 25 Sep 2012 15:55:40 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1348588379!12346170!1
X-Originating-IP: [74.125.83.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32315 invoked from network); 25 Sep 2012 15:52:59 -0000
Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com)
	(74.125.83.45)
	by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Sep 2012 15:52:59 -0000
Received: by eekb47 with SMTP id b47so1363854eek.32
	for <xen-devel@lists.xen.org>; Tue, 25 Sep 2012 08:52:59 -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=oZ/nkH9CFB6eRhiBx8oKOV+L6Lf1m9IzMdXB6moJ/yw=;
	b=C4/CciSrCZqyad2GGbI+sze8yoUSesfgoAoUfMMVjO2sxEUz0XTgc7DRDu7peOIvD3
	geYslrxHtJejCuVOUESxGOev1EirbCyaFJOyMkTZjsZuRgx3AQJ0oCP1d+1EJpPkcuwa
	Lv+qUj7f6qjOQsEmVOHXMOOu9Q0Oi3iIcbpCgKGz44KkwAgQ7L2Xw4azwmSBbiYWx8DJ
	PyQChemuEyRIiBAwiqNFiLfYdvM38q5A+Q8CUtwLY9/mg4vXzOMvppL8iWOQlvdoiiVG
	MjmAUovbFC+bIPaneVOr95sBt1SEAd0LmnXau4IP/WI/3UM12xKmdamu2NwIVj7AUckI
	Geig==
Received: by 10.14.203.69 with SMTP id e45mr21068131eeo.23.1348588379296;
	Tue, 25 Sep 2012 08:52:59 -0700 (PDT)
Received: from [192.168.1.3] (host86-167-82-156.range86-167.btcentralplus.com.
	[86.167.82.156])
	by mx.google.com with ESMTPS id v3sm1921369eep.10.2012.09.25.08.52.57
	(version=SSLv3 cipher=OTHER); Tue, 25 Sep 2012 08:52:58 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.33.0.120411
Date: Tue, 25 Sep 2012 16:52:46 +0100
From: Keir Fraser <keir@xen.org>
To: Ben Guthro <ben@guthro.net>,
	Jan Beulich <JBeulich@suse.com>
Message-ID: <CC8791DE.4CDAF%keir@xen.org>
Thread-Topic: [Xen-devel] Xen4.2 S3 regression?
Thread-Index: Ac2bNc5HqwDtJetde0G+oi0vrix42w==
In-Reply-To: <CAOvdn6UqKqOfn7U-q6BCPF3UcMRO9J-R+Po62eEjfWh3APoSjg@mail.gmail.com>
Mime-version: 1.0
Cc: John Baboval <john.baboval@citrix.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen4.2 S3 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="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/09/2012 16:45, "Ben Guthro" <ben@guthro.net> wrote:

> Which is one of the reasons I brought it up again.
> =A0
>> =

>> However, I don't see yet how this is connected to you having
>> a problem only with pinned vCPU-s.
> =

> Well - when the command line parameter dom0_vcpu_pin exists -=A0
> it crashes without this change. It does not crash with it, or without=A0
> the command line parameter.
> =

> Perhaps they are unrelated.

Of course they're related. Dom0 kernel is fixing itself up after S3, while
hypervisor is still bringing CPUs back online. It's a race for one of dom0
kernel's running VCPUs to do a hypercall that observes that one of its other
VCPUs is unschedulable (because there are no currently-online CPUs in its
cpu affinity mask!).

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 25 15:55:53 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 15:55:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGXU6-0000NG-Pc; Tue, 25 Sep 2012 15:55:42 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1TGXU4-0000Mo-Nj
	for xen-devel@lists.xen.org; Tue, 25 Sep 2012 15:55:40 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1348588379!12346170!1
X-Originating-IP: [74.125.83.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32315 invoked from network); 25 Sep 2012 15:52:59 -0000
Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com)
	(74.125.83.45)
	by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Sep 2012 15:52:59 -0000
Received: by eekb47 with SMTP id b47so1363854eek.32
	for <xen-devel@lists.xen.org>; Tue, 25 Sep 2012 08:52:59 -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=oZ/nkH9CFB6eRhiBx8oKOV+L6Lf1m9IzMdXB6moJ/yw=;
	b=C4/CciSrCZqyad2GGbI+sze8yoUSesfgoAoUfMMVjO2sxEUz0XTgc7DRDu7peOIvD3
	geYslrxHtJejCuVOUESxGOev1EirbCyaFJOyMkTZjsZuRgx3AQJ0oCP1d+1EJpPkcuwa
	Lv+qUj7f6qjOQsEmVOHXMOOu9Q0Oi3iIcbpCgKGz44KkwAgQ7L2Xw4azwmSBbiYWx8DJ
	PyQChemuEyRIiBAwiqNFiLfYdvM38q5A+Q8CUtwLY9/mg4vXzOMvppL8iWOQlvdoiiVG
	MjmAUovbFC+bIPaneVOr95sBt1SEAd0LmnXau4IP/WI/3UM12xKmdamu2NwIVj7AUckI
	Geig==
Received: by 10.14.203.69 with SMTP id e45mr21068131eeo.23.1348588379296;
	Tue, 25 Sep 2012 08:52:59 -0700 (PDT)
Received: from [192.168.1.3] (host86-167-82-156.range86-167.btcentralplus.com.
	[86.167.82.156])
	by mx.google.com with ESMTPS id v3sm1921369eep.10.2012.09.25.08.52.57
	(version=SSLv3 cipher=OTHER); Tue, 25 Sep 2012 08:52:58 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.33.0.120411
Date: Tue, 25 Sep 2012 16:52:46 +0100
From: Keir Fraser <keir@xen.org>
To: Ben Guthro <ben@guthro.net>,
	Jan Beulich <JBeulich@suse.com>
Message-ID: <CC8791DE.4CDAF%keir@xen.org>
Thread-Topic: [Xen-devel] Xen4.2 S3 regression?
Thread-Index: Ac2bNc5HqwDtJetde0G+oi0vrix42w==
In-Reply-To: <CAOvdn6UqKqOfn7U-q6BCPF3UcMRO9J-R+Po62eEjfWh3APoSjg@mail.gmail.com>
Mime-version: 1.0
Cc: John Baboval <john.baboval@citrix.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen4.2 S3 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="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/09/2012 16:45, "Ben Guthro" <ben@guthro.net> wrote:

> Which is one of the reasons I brought it up again.
> =A0
>> =

>> However, I don't see yet how this is connected to you having
>> a problem only with pinned vCPU-s.
> =

> Well - when the command line parameter dom0_vcpu_pin exists -=A0
> it crashes without this change. It does not crash with it, or without=A0
> the command line parameter.
> =

> Perhaps they are unrelated.

Of course they're related. Dom0 kernel is fixing itself up after S3, while
hypervisor is still bringing CPUs back online. It's a race for one of dom0
kernel's running VCPUs to do a hypercall that observes that one of its other
VCPUs is unschedulable (because there are no currently-online CPUs in its
cpu affinity mask!).

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 25 15:56:18 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 15:56:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGXUX-0000R1-6S; Tue, 25 Sep 2012 15:56: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 1TGXUV-0000Qh-D3
	for xen-devel@lists.xensource.com; Tue, 25 Sep 2012 15:56:07 +0000
Received: from [85.158.138.51:16413] by server-4.bemta-3.messagelabs.com id
	FC/94-24831-614D1605; Tue, 25 Sep 2012 15:56:06 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1348588565!23898266!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTEwNzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11010 invoked from network); 25 Sep 2012 15:56:05 -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;
	25 Sep 2012 15:56:05 -0000
X-IronPort-AV: E=Sophos;i="4.80,484,1344211200"; d="scan'208";a="14755638"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Sep 2012 15:56: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.279.1;
	Tue, 25 Sep 2012 16:56:04 +0100
Message-ID: <1348588563.12592.12.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Sander Eikelenboom <linux@eikelenboom.it>
Date: Tue, 25 Sep 2012 16:56:03 +0100
In-Reply-To: <148921897.20120925174721@eikelenboom.it>
References: <patchbomb.1346960486@xentest.example.org>
	<1348565712.3452.141.camel@zakaz.uk.xensource.com>
	<15210025463.20120925171143@eikelenboom.it>
	<1348586949.12592.10.camel@zakaz.uk.xensource.com>
	<148921897.20120925174721@eikelenboom.it>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-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 0 of 3] xl and hotplug: Introduce and use
 shutdown and reboot xm compatibility options
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-09-25 at 16:47 +0100, Sander Eikelenboom wrote:
> Tuesday, September 25, 2012, 5:29:09 PM, you wrote:
> 
> > On Tue, 2012-09-25 at 16:11 +0100, Sander Eikelenboom wrote:
> 
> >> The only relative simple implementation i thought of was direct
> >> shutting down all, and when the -w parameter was set, just loop and
> >> wait on events until the only running domain is domain-0.
> >> Although this exactly does what has to be done, it somehow sounds a
> >> bit dirty.
> 
> > I think you can allocate an array of libxl_evenable_domain_death*, of
> > nr_doms in size and then as you shutdown each domain call
> > libxl_evenable_domain_death for it too.
> 
> > Then you loop waiting for destroy events, calling
> > libxl_evdisable_domain_death as each domain dies, while counting back
> > from nr_doms until 0. When it reaches 0 everything you asked for has
> > been shutdown.
> 
> Depends a bit on what you expect -a to do, especially in combination with -w.
> The wait gives quite a window for a new guest to be created in the mean time.
> 
> The usage in the init.d/xendomains script is as a sort of "catch all", since the iteration is in the script it self.
> So for that purpose i would assume that a "xl shutdown -a -w" would
> shutdown all domains until only dom-0 remains, and not only shutdown
> the domains that were running at the time the command was actually
> issued.

I'd be happy to assume that no one is starting new domains while the
system is in the process of shutting down...

Or maybe we could just drop a marker in xenstore to prevent new domains
being started. Sort of like how initscripts create /nologin to stop new
loggins during shutdown.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 25 15:56:18 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 15:56:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGXUX-0000R1-6S; Tue, 25 Sep 2012 15:56: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 1TGXUV-0000Qh-D3
	for xen-devel@lists.xensource.com; Tue, 25 Sep 2012 15:56:07 +0000
Received: from [85.158.138.51:16413] by server-4.bemta-3.messagelabs.com id
	FC/94-24831-614D1605; Tue, 25 Sep 2012 15:56:06 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1348588565!23898266!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTEwNzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11010 invoked from network); 25 Sep 2012 15:56:05 -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;
	25 Sep 2012 15:56:05 -0000
X-IronPort-AV: E=Sophos;i="4.80,484,1344211200"; d="scan'208";a="14755638"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Sep 2012 15:56: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.279.1;
	Tue, 25 Sep 2012 16:56:04 +0100
Message-ID: <1348588563.12592.12.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Sander Eikelenboom <linux@eikelenboom.it>
Date: Tue, 25 Sep 2012 16:56:03 +0100
In-Reply-To: <148921897.20120925174721@eikelenboom.it>
References: <patchbomb.1346960486@xentest.example.org>
	<1348565712.3452.141.camel@zakaz.uk.xensource.com>
	<15210025463.20120925171143@eikelenboom.it>
	<1348586949.12592.10.camel@zakaz.uk.xensource.com>
	<148921897.20120925174721@eikelenboom.it>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-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 0 of 3] xl and hotplug: Introduce and use
 shutdown and reboot xm compatibility options
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-09-25 at 16:47 +0100, Sander Eikelenboom wrote:
> Tuesday, September 25, 2012, 5:29:09 PM, you wrote:
> 
> > On Tue, 2012-09-25 at 16:11 +0100, Sander Eikelenboom wrote:
> 
> >> The only relative simple implementation i thought of was direct
> >> shutting down all, and when the -w parameter was set, just loop and
> >> wait on events until the only running domain is domain-0.
> >> Although this exactly does what has to be done, it somehow sounds a
> >> bit dirty.
> 
> > I think you can allocate an array of libxl_evenable_domain_death*, of
> > nr_doms in size and then as you shutdown each domain call
> > libxl_evenable_domain_death for it too.
> 
> > Then you loop waiting for destroy events, calling
> > libxl_evdisable_domain_death as each domain dies, while counting back
> > from nr_doms until 0. When it reaches 0 everything you asked for has
> > been shutdown.
> 
> Depends a bit on what you expect -a to do, especially in combination with -w.
> The wait gives quite a window for a new guest to be created in the mean time.
> 
> The usage in the init.d/xendomains script is as a sort of "catch all", since the iteration is in the script it self.
> So for that purpose i would assume that a "xl shutdown -a -w" would
> shutdown all domains until only dom-0 remains, and not only shutdown
> the domains that were running at the time the command was actually
> issued.

I'd be happy to assume that no one is starting new domains while the
system is in the process of shutting down...

Or maybe we could just drop a marker in xenstore to prevent new domains
being started. Sort of like how initscripts create /nologin to stop new
loggins during shutdown.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 25 16:02:21 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 16: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 1TGXaM-000184-0F; Tue, 25 Sep 2012 16:02:10 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <matthew.fioravante@jhuapl.edu>) id 1TGXaK-00017z-CC
	for xen-devel@lists.xensource.com; Tue, 25 Sep 2012 16:02:08 +0000
Received: from [85.158.143.99:29445] by server-1.bemta-4.messagelabs.com id
	64/6C-05684-F75D1605; Tue, 25 Sep 2012 16:02:07 +0000
X-Env-Sender: matthew.fioravante@jhuapl.edu
X-Msg-Ref: server-10.tower-216.messagelabs.com!1348588925!25305986!1
X-Originating-IP: [128.244.251.36]
X-SpamReason: No, hits=0.0 required=7.0 tests=UNPARSEABLE_RELAY
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15049 invoked from network); 25 Sep 2012 16:02:06 -0000
Received: from pilot.jhuapl.edu (HELO jhuapl.edu) (128.244.251.36)
	by server-10.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 25 Sep 2012 16:02:06 -0000
Received: from ([128.244.207.89])
	by pilot.jhuapl.edu with ESMTP with TLS id 63GHCH1.153617458;
	Tue, 25 Sep 2012 12:02:00 -0400
Message-ID: <5061D52B.9080503@jhuapl.edu>
Date: Tue, 25 Sep 2012 12:00:43 -0400
From: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120827 Thunderbird/15.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <505CBDFD.5070408@jhuapl.edu>
	<1348569397.3452.180.camel@zakaz.uk.xensource.com>
In-Reply-To: <1348569397.3452.180.camel@zakaz.uk.xensource.com>
X-Enigmail-Version: 1.4.4
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH xm/xl enhancements for vptm 5/6] make devid
	a libxl 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: multipart/mixed; boundary="===============5528710076050718605=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a cryptographically signed message in MIME format.

--===============5528710076050718605==
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms000803050900070401010201"

This is a cryptographically signed message in MIME format.

--------------ms000803050900070401010201
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 09/25/2012 06:36 AM, Ian Campbell wrote:
> On Fri, 2012-09-21 at 20:20 +0100, Matthew Fioravante wrote:
>> This fixes a bug in libxl where device ids are not initialized properl=
y.
>> The devid field for each device is set to be an integer type which are=

>> always initialized to 0.
>>
>> This makes the xl DEV-attach commands always fail to add more than one=

>> device, because each time the device id is initialized to 0, when it
>> should be initialized to -1, which in the code will trigger a search f=
or
>> free id.
> Which of the DEV-attach commands can be used to add more than one
> device?
network-attach, block-attach, and also my vtpm-attach.
>
> Where is the code to do the search? I had a look in the disk and networ=
k
> cases and couldn't find it.
libxl.c

void libxl__device_nic_add(

    if (nic->devid =3D=3D -1) {
        if (!(dompath =3D libxl__xs_get_dompath(gc, domid))) {
            rc =3D ERROR_FAIL;
            goto out_free;
        }
        if (!(l =3D libxl__xs_directory(gc, XBT_NULL,
                                     libxl__sprintf(gc, "%s/device/vif",
dompath), &nb))) {
            nic->devid =3D 0;
        } else {
            nic->devid =3D strtoul(l[nb - 1], NULL, 10) + 1;
        }
    }

Right now, nic-devid is 0 on attach. So it always tries to use 0. When
you do a network-attach twice,
the second time it trys and fails to create device/vif/0

>
>> diff --git a/tools/ocaml/libs/xs/xs.mli b/tools/ocaml/libs/xs/xs.mli
>> --- a/tools/ocaml/libs/xs/xs.mli
>> +++ b/tools/ocaml/libs/xs/xs.mli
>> @@ -27,6 +27,7 @@ exception Failed_to_connect
>>  type perms =3D Xsraw.perms
>> =20
>>  type domid =3D int
>> +type devid =3D int
> I can see why these were needed in the xl modules, but I don't see how
> this type can be required in the xenstore ones.
It shouldn't be required for xenstore or xc. The problem is they won't
compile without it because of the way the ocaml build system works. As
far as I understand it creates types for xl, xc, and xs from the
libxl_types.idl. Either the build system needs to be changed, or devid
needs to be a type in all libraries, or we find some other way to fix
this initialization bug.
>
> Ian.
>



--------------ms000803050900070401010201
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIDyjCC
A8YwggMvoAMCAQICBD/xyf0wDQYJKoZIhvcNAQEFBQAwLzELMAkGA1UEBhMCVVMxDzANBgNV
BAoTBkpIVUFQTDEPMA0GA1UECxMGQklTRENBMB4XDTEwMDYxMTE4MjIwNloXDTEzMDYxMTE4
NTIwNlowZjELMAkGA1UEBhMCVVMxDzANBgNVBAoTBkpIVUFQTDEPMA0GA1UECxMGUGVvcGxl
MTUwFgYDVQQLEw9WUE5Hcm91cC1CSVNEQ0EwGwYDVQQDExRNYXR0aGV3IEUgRmlvcmF2YW50
ZTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAnpbwVSP6o1Nb5lcW7dd3yTo9iBJdi7qz
4nANOMFPK7JOy5npKN1iiousl28U/scUJES55gPwAWYJK3uVyQAsA4adgDKi5DoD1UHDQEwp
bY7iHLJeq0NPr4BqYNqnCFPbE6HC8zSJrr4qKn+gVUQT39SIFqdiIPJwZL8FYTRQ/zsCAwEA
AaOCAbYwggGyMAsGA1UdDwQEAwIHgDArBgNVHRAEJDAigA8yMDEwMDYxMTE4MjIwNlqBDzIw
MTIwNzE3MjI1MjA2WjAbBg0rBgEEAbMlCwMBAQEBBAoWCGZpb3JhbWUxMBsGDSsGAQQBsyUL
AwEBAQIEChIIMDAxMDQyNjEwWAYJYIZIAYb6ax4BBEsMSVRoZSBwcml2YXRlIGtleSBjb3Jy
ZXNwb25kaW5nIHRvIHRoaXMgY2VydGlmaWNhdGUgbWF5IGhhdmUgYmVlbiBleHBvcnRlZC4w
KAYDVR0RBCEwH4EdTWF0dGhldy5GaW9yYXZhbnRlQGpodWFwbC5lZHUwUgYDVR0fBEswSTBH
oEWgQ6RBMD8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJU0RD
QTEOMAwGA1UEAxMFQ1JMNTYwHwYDVR0jBBgwFoAUCDUpmxH52EU2CyWmF2EJMB1yqeswHQYD
VR0OBBYEFO6LYxg6r9wHZ+zdQtBHn1dZ/YTNMAkGA1UdEwQCMAAwGQYJKoZIhvZ9B0EABAww
ChsEVjcuMQMCBLAwDQYJKoZIhvcNAQEFBQADgYEAJO9HQh4YNChVLzuZqK5ARJARD8JoujGZ
fdo75quvg2jXFQe2sEjvLnxJZgm/pv8fdZakq48CWwjYHKuvIp7sDjTEsQfo+y7SpN/N2NvJ
WU5SqfK1VgYtNLRRoGJUB5Q1aZ+Dg95g3kqpyfpUMISJL8IKVLtJVfN4fggFVUYZ9wwxggGr
MIIBpwIBATA3MC8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJ
U0RDQQIEP/HJ/TAJBgUrDgMCGgUAoIHLMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ
KoZIhvcNAQkFMQ8XDTEyMDkyNTE2MDA0M1owIwYJKoZIhvcNAQkEMRYEFPGyyfcYJSN7cjuH
jSgPNrb4sfPZMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAK
BggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI
KoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEgYCRFD2yVDs8bH4sJzHLGZ5R4aDZUjmMv4N0
+sOGlfj1XHMrItpa8q0PMB4Kd1KCiegE24S+3T0PGQbcjSyIBp83QvkyBKng329soaDKJyrb
+zCqtMH4fHdFC9DcwVQEuR7X9A9LS/BTAP0qfFflU1cUSBKdJP545z4NTRFco7pOuAAAAAAA
AA==
--------------ms000803050900070401010201--


--===============5528710076050718605==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============5528710076050718605==--


From xen-devel-bounces@lists.xen.org Tue Sep 25 16:02:21 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 16: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 1TGXaM-000184-0F; Tue, 25 Sep 2012 16:02:10 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <matthew.fioravante@jhuapl.edu>) id 1TGXaK-00017z-CC
	for xen-devel@lists.xensource.com; Tue, 25 Sep 2012 16:02:08 +0000
Received: from [85.158.143.99:29445] by server-1.bemta-4.messagelabs.com id
	64/6C-05684-F75D1605; Tue, 25 Sep 2012 16:02:07 +0000
X-Env-Sender: matthew.fioravante@jhuapl.edu
X-Msg-Ref: server-10.tower-216.messagelabs.com!1348588925!25305986!1
X-Originating-IP: [128.244.251.36]
X-SpamReason: No, hits=0.0 required=7.0 tests=UNPARSEABLE_RELAY
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15049 invoked from network); 25 Sep 2012 16:02:06 -0000
Received: from pilot.jhuapl.edu (HELO jhuapl.edu) (128.244.251.36)
	by server-10.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 25 Sep 2012 16:02:06 -0000
Received: from ([128.244.207.89])
	by pilot.jhuapl.edu with ESMTP with TLS id 63GHCH1.153617458;
	Tue, 25 Sep 2012 12:02:00 -0400
Message-ID: <5061D52B.9080503@jhuapl.edu>
Date: Tue, 25 Sep 2012 12:00:43 -0400
From: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120827 Thunderbird/15.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <505CBDFD.5070408@jhuapl.edu>
	<1348569397.3452.180.camel@zakaz.uk.xensource.com>
In-Reply-To: <1348569397.3452.180.camel@zakaz.uk.xensource.com>
X-Enigmail-Version: 1.4.4
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH xm/xl enhancements for vptm 5/6] make devid
	a libxl 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: multipart/mixed; boundary="===============5528710076050718605=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a cryptographically signed message in MIME format.

--===============5528710076050718605==
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms000803050900070401010201"

This is a cryptographically signed message in MIME format.

--------------ms000803050900070401010201
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 09/25/2012 06:36 AM, Ian Campbell wrote:
> On Fri, 2012-09-21 at 20:20 +0100, Matthew Fioravante wrote:
>> This fixes a bug in libxl where device ids are not initialized properl=
y.
>> The devid field for each device is set to be an integer type which are=

>> always initialized to 0.
>>
>> This makes the xl DEV-attach commands always fail to add more than one=

>> device, because each time the device id is initialized to 0, when it
>> should be initialized to -1, which in the code will trigger a search f=
or
>> free id.
> Which of the DEV-attach commands can be used to add more than one
> device?
network-attach, block-attach, and also my vtpm-attach.
>
> Where is the code to do the search? I had a look in the disk and networ=
k
> cases and couldn't find it.
libxl.c

void libxl__device_nic_add(

    if (nic->devid =3D=3D -1) {
        if (!(dompath =3D libxl__xs_get_dompath(gc, domid))) {
            rc =3D ERROR_FAIL;
            goto out_free;
        }
        if (!(l =3D libxl__xs_directory(gc, XBT_NULL,
                                     libxl__sprintf(gc, "%s/device/vif",
dompath), &nb))) {
            nic->devid =3D 0;
        } else {
            nic->devid =3D strtoul(l[nb - 1], NULL, 10) + 1;
        }
    }

Right now, nic-devid is 0 on attach. So it always tries to use 0. When
you do a network-attach twice,
the second time it trys and fails to create device/vif/0

>
>> diff --git a/tools/ocaml/libs/xs/xs.mli b/tools/ocaml/libs/xs/xs.mli
>> --- a/tools/ocaml/libs/xs/xs.mli
>> +++ b/tools/ocaml/libs/xs/xs.mli
>> @@ -27,6 +27,7 @@ exception Failed_to_connect
>>  type perms =3D Xsraw.perms
>> =20
>>  type domid =3D int
>> +type devid =3D int
> I can see why these were needed in the xl modules, but I don't see how
> this type can be required in the xenstore ones.
It shouldn't be required for xenstore or xc. The problem is they won't
compile without it because of the way the ocaml build system works. As
far as I understand it creates types for xl, xc, and xs from the
libxl_types.idl. Either the build system needs to be changed, or devid
needs to be a type in all libraries, or we find some other way to fix
this initialization bug.
>
> Ian.
>



--------------ms000803050900070401010201
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIDyjCC
A8YwggMvoAMCAQICBD/xyf0wDQYJKoZIhvcNAQEFBQAwLzELMAkGA1UEBhMCVVMxDzANBgNV
BAoTBkpIVUFQTDEPMA0GA1UECxMGQklTRENBMB4XDTEwMDYxMTE4MjIwNloXDTEzMDYxMTE4
NTIwNlowZjELMAkGA1UEBhMCVVMxDzANBgNVBAoTBkpIVUFQTDEPMA0GA1UECxMGUGVvcGxl
MTUwFgYDVQQLEw9WUE5Hcm91cC1CSVNEQ0EwGwYDVQQDExRNYXR0aGV3IEUgRmlvcmF2YW50
ZTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAnpbwVSP6o1Nb5lcW7dd3yTo9iBJdi7qz
4nANOMFPK7JOy5npKN1iiousl28U/scUJES55gPwAWYJK3uVyQAsA4adgDKi5DoD1UHDQEwp
bY7iHLJeq0NPr4BqYNqnCFPbE6HC8zSJrr4qKn+gVUQT39SIFqdiIPJwZL8FYTRQ/zsCAwEA
AaOCAbYwggGyMAsGA1UdDwQEAwIHgDArBgNVHRAEJDAigA8yMDEwMDYxMTE4MjIwNlqBDzIw
MTIwNzE3MjI1MjA2WjAbBg0rBgEEAbMlCwMBAQEBBAoWCGZpb3JhbWUxMBsGDSsGAQQBsyUL
AwEBAQIEChIIMDAxMDQyNjEwWAYJYIZIAYb6ax4BBEsMSVRoZSBwcml2YXRlIGtleSBjb3Jy
ZXNwb25kaW5nIHRvIHRoaXMgY2VydGlmaWNhdGUgbWF5IGhhdmUgYmVlbiBleHBvcnRlZC4w
KAYDVR0RBCEwH4EdTWF0dGhldy5GaW9yYXZhbnRlQGpodWFwbC5lZHUwUgYDVR0fBEswSTBH
oEWgQ6RBMD8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJU0RD
QTEOMAwGA1UEAxMFQ1JMNTYwHwYDVR0jBBgwFoAUCDUpmxH52EU2CyWmF2EJMB1yqeswHQYD
VR0OBBYEFO6LYxg6r9wHZ+zdQtBHn1dZ/YTNMAkGA1UdEwQCMAAwGQYJKoZIhvZ9B0EABAww
ChsEVjcuMQMCBLAwDQYJKoZIhvcNAQEFBQADgYEAJO9HQh4YNChVLzuZqK5ARJARD8JoujGZ
fdo75quvg2jXFQe2sEjvLnxJZgm/pv8fdZakq48CWwjYHKuvIp7sDjTEsQfo+y7SpN/N2NvJ
WU5SqfK1VgYtNLRRoGJUB5Q1aZ+Dg95g3kqpyfpUMISJL8IKVLtJVfN4fggFVUYZ9wwxggGr
MIIBpwIBATA3MC8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJ
U0RDQQIEP/HJ/TAJBgUrDgMCGgUAoIHLMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ
KoZIhvcNAQkFMQ8XDTEyMDkyNTE2MDA0M1owIwYJKoZIhvcNAQkEMRYEFPGyyfcYJSN7cjuH
jSgPNrb4sfPZMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAK
BggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI
KoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEgYCRFD2yVDs8bH4sJzHLGZ5R4aDZUjmMv4N0
+sOGlfj1XHMrItpa8q0PMB4Kd1KCiegE24S+3T0PGQbcjSyIBp83QvkyBKng329soaDKJyrb
+zCqtMH4fHdFC9DcwVQEuR7X9A9LS/BTAP0qfFflU1cUSBKdJP545z4NTRFco7pOuAAAAAAA
AA==
--------------ms000803050900070401010201--


--===============5528710076050718605==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============5528710076050718605==--


From xen-devel-bounces@lists.xen.org Tue Sep 25 16:02:46 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 16: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 1TGXam-0001AK-IF; Tue, 25 Sep 2012 16:02: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 1TGXak-00019v-FX
	for xen-devel@lists.xensource.com; Tue, 25 Sep 2012 16:02:34 +0000
Received: from [85.158.138.51:52038] by server-3.bemta-3.messagelabs.com id
	EB/30-21322-995D1605; Tue, 25 Sep 2012 16:02:33 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1348588952!25594531!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTEwNzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16194 invoked from network); 25 Sep 2012 16:02: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;
	25 Sep 2012 16:02:32 -0000
X-IronPort-AV: E=Sophos;i="4.80,484,1344211200"; d="scan'208";a="14755756"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Sep 2012 16:01: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.279.1;
	Tue, 25 Sep 2012 17:01:39 +0100
Message-ID: <1348588898.12592.16.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "lars.kurth@xen.org" <lars.kurth@xen.org>
Date: Tue, 25 Sep 2012 17:01:38 +0100
In-Reply-To: <5061D362.8070402@xen.org>
References: <CAGnmK4wB3ZJ3Tb9-VFgWCkcZNwibDzRYV8tvb14vLgw1wj2awQ@mail.gmail.com>
	<50607A68.2090604@xen.org>
	<1348561354.3452.105.camel@zakaz.uk.xensource.com>
	<2D15A521-63E8-4CE7-8D42-62A67FBD75B2@recoil.org>
	<1348583438.11229.23.camel@zakaz.uk.xensource.com>
	<5061D362.8070402@xen.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-api@lists.xensource.com" <xen-api@lists.xensource.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Anil Madhavapeddy <anil@recoil.org>
Subject: Re: [Xen-devel] [Xen-API]  Proposal - Add xe manpages to xen-org
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gVHVlLCAyMDEyLTA5LTI1IGF0IDE2OjUzICswMTAwLCBMYXJzIEt1cnRoIHdyb3RlOgo+IE9u
IDI1LzA5LzIwMTIgMTU6MzAsIElhbiBDYW1wYmVsbCB3cm90ZToKPiA+IEFjY29yZGluZyB0byB0
aGUgb3JpZ2luYWwgbWFpbCBpdCBpcyBpbiBhc2NpaWRvYyBhbHJlYWR5LCBzbyBtYXliZSAKPiA+
IHRoaXMgaXMgYWxyZWFkeSB0aGUgY2FzZT8KPiBNeSB1bmRlcnN0YW5kaW5nIGlzIHRoYXQgdGhl
IGV4aXN0aW5nIFhlblNlcnZlci9YQ1AgZG9jcyBhcmUgcHJpbWFyaWx5IAo+IHRhc2sgZHJpdmVu
IChpLmUuIOKAnHRvIGFjaGlldmUgWCB5b3UgZG8gWeKAnSkuIE1hbiBwYWdlcyBhcmUgcGVyIGNv
bW1hbmQgCj4gcmVmZXJlbmNlcyAoaS5lLiDigJxkb2luZyBZIHdpbGwgY2F1c2UgWCB0byBoYXBw
ZW7igJ0pLCB3aGljaCBpcyBoYXJkbHkgCj4gY292ZXJlZCBpbgo+IGV4aXN0aW5nIFhTIGRvY3Vt
ZW50YXRpb24uCgpUaGF0IG1heSBhbGwgYmUgdHJ1ZS4gQnV0IEkgd2FzIHRhbGtpbmcgYWJvdXQg
YWJvdXQgdGhlIGRvY3Mgd2hpY2ggR3JhbnQKaGFzIHByb2R1Y2VkLCB3aGljaCBoZSBzYWlkIHdl
cmUgaW4gYXNjaWlkb2MuCgo+ID4gSSBhZ3JlZSB0aGF0IGFjdHVhbGx5IGluIHRoZSBzb3VyY2Ug
aXMgZXZlbiBiZXR0ZXIgdGhhbiBuZXh0IHRvIHRoZQo+ID4gc291cmNlLCBpZiBpdCdzIGFuIG9w
dGlvbi4uLgo+ID4KPiA+PiBNYW51YWxseSBrZWVwaW5nIHRoZSB6aWxsaW9uIGNvbW1hbmRzIGlu
IHN5bmMgd2lsbCBiZSBxdWl0ZSB0aGUgb25nb2luZwo+ID4+IGVmZm9ydC4KPiA+IFNvbWVvbmUg
c3RpbGwgbmVlZHMgdG8gd3JpdGUvdXBkYXRlIHRoZSB0ZXh0IHJlZ2FyZGxlc3Mgb2Ygd2hlcmUg
aXQKPiA+IGxpdmVzLCBidXQgdGhhdCdzIGFzIG11Y2ggYSBjb2RlIHJldmlldyB0aGluZyBhcyBh
bnl0aGluZyBlbHNlLgo+ID4KPiBJIHdvdWxkbid0IHdhbnQgdG8gY3JlYXRlIGEgYmFycmllciBm
b3IgR3JhbnQncyBzdHVkZW50cyAob3Igb3RoZXIgCj4gcGVvcGxlIHRoYXQgd2FudCB0byBjb250
cmlidXRlKS4gUmVtZW1iZXIgdGhhdCBtb3N0IGFyZSBub3QgZGV2ZWxvcGVycyAKPiBidXQgdXNl
cnMgb2YgWENQLiAgRW1iZWRkaW5nIHRoZSBkb2N1bWVudGF0aW9uIGludG8gdGhlIGNvZGUgd291
bGQgbWVhbjoKPiBhKSBleGlzdGluZyBkb2N1bWVudCBzb3VyY2UgY29kZSB3b3VsZCBuZWVkIHRv
IGJlIHJlZmFjdG9yZWQKPiBiKSBpdCB3b3VsZCBjcmVhdGUgYSBwc3ljaG9sb2dpY2FsIGJhcnJp
ZXIgdG8gY29udHJpYnV0ZQo+IGMpIHBvc3NpYmx5IHVubmVjZXNzYXJ5IHByb2Nlc3MKPiAKPiBL
ZWVwaW5nIHRoZSBkb2N1bWVudGF0aW9uIHNlcGFyYXRlIChlaXRoZXIgaW4gYSBzZXBhcmF0ZSBy
ZXBvLCBvciAKPiBkaXJlY3RvcnkgaW4gYW4gZXhpc3RpbmcgcmVwbykgaXMgcHJvYmFibHkgdGhl
IGVhc2llc3QgYW5kIHF1aWNrZXN0IHdheSAKPiB0byBnZXQgdGhpcyBwcm9qZWN0IG9mZiB0aGUg
Z3JvdW5kIHF1aWNrbHkuCgpJbiB3aGljaCBjYXNlIEkgd291bGQgc3VnZ2VzdCBhIGRpcmVjdG9y
eSBvZiB0aGUgZXhpc3RpbmcgeGVuLWFwaSByZXBvCmFuZCBub3QgYSBjb21wbGV0ZWx5IHNlcGFy
YXRlIG9uZS4KCkJUVywgSSB3YXNuJ3Qgc3VnZ2VzdGluZyB0aGF0IHBlb3BsZSBjb250cmlidXRp
bmcgZG9jcyBuZWVkZWQgdG8gYmVjb21lCmNvZGUgY29udHJpYnV0b3JzIHRvby4gT25seSB0aGUg
aW52ZXJzZSB3aGljaCBpcyB0aGF0IHBlb3BsZSBjaGFuZ2luZwp0aGUgY29kZSBzaG91bGQgYmUg
ZXhwZWN0IHRvIHNpbXVsdGFuZW91c2x5IHVwZGF0ZSBhbnkgZG9jcyByZWxldmFudCB0bwp0aGVp
ciBjaGFuZ2UuIE9idmlvdXNseSBpdCBpcyBhbHNvIGZpbmUgdG8gaW1wcm92ZSB0aGUgZG9jcyB3
aXRob3V0CmNoYW5naW5nIHRoZSBjb2RlLgoKSWFuLgoKCl9fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVs
QGxpc3RzLnhlbi5vcmcKaHR0cDovL2xpc3RzLnhlbi5vcmcveGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Tue Sep 25 16:02:46 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 16: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 1TGXam-0001AK-IF; Tue, 25 Sep 2012 16:02: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 1TGXak-00019v-FX
	for xen-devel@lists.xensource.com; Tue, 25 Sep 2012 16:02:34 +0000
Received: from [85.158.138.51:52038] by server-3.bemta-3.messagelabs.com id
	EB/30-21322-995D1605; Tue, 25 Sep 2012 16:02:33 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1348588952!25594531!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTEwNzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16194 invoked from network); 25 Sep 2012 16:02: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;
	25 Sep 2012 16:02:32 -0000
X-IronPort-AV: E=Sophos;i="4.80,484,1344211200"; d="scan'208";a="14755756"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Sep 2012 16:01: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.279.1;
	Tue, 25 Sep 2012 17:01:39 +0100
Message-ID: <1348588898.12592.16.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "lars.kurth@xen.org" <lars.kurth@xen.org>
Date: Tue, 25 Sep 2012 17:01:38 +0100
In-Reply-To: <5061D362.8070402@xen.org>
References: <CAGnmK4wB3ZJ3Tb9-VFgWCkcZNwibDzRYV8tvb14vLgw1wj2awQ@mail.gmail.com>
	<50607A68.2090604@xen.org>
	<1348561354.3452.105.camel@zakaz.uk.xensource.com>
	<2D15A521-63E8-4CE7-8D42-62A67FBD75B2@recoil.org>
	<1348583438.11229.23.camel@zakaz.uk.xensource.com>
	<5061D362.8070402@xen.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-api@lists.xensource.com" <xen-api@lists.xensource.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Anil Madhavapeddy <anil@recoil.org>
Subject: Re: [Xen-devel] [Xen-API]  Proposal - Add xe manpages to xen-org
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gVHVlLCAyMDEyLTA5LTI1IGF0IDE2OjUzICswMTAwLCBMYXJzIEt1cnRoIHdyb3RlOgo+IE9u
IDI1LzA5LzIwMTIgMTU6MzAsIElhbiBDYW1wYmVsbCB3cm90ZToKPiA+IEFjY29yZGluZyB0byB0
aGUgb3JpZ2luYWwgbWFpbCBpdCBpcyBpbiBhc2NpaWRvYyBhbHJlYWR5LCBzbyBtYXliZSAKPiA+
IHRoaXMgaXMgYWxyZWFkeSB0aGUgY2FzZT8KPiBNeSB1bmRlcnN0YW5kaW5nIGlzIHRoYXQgdGhl
IGV4aXN0aW5nIFhlblNlcnZlci9YQ1AgZG9jcyBhcmUgcHJpbWFyaWx5IAo+IHRhc2sgZHJpdmVu
IChpLmUuIOKAnHRvIGFjaGlldmUgWCB5b3UgZG8gWeKAnSkuIE1hbiBwYWdlcyBhcmUgcGVyIGNv
bW1hbmQgCj4gcmVmZXJlbmNlcyAoaS5lLiDigJxkb2luZyBZIHdpbGwgY2F1c2UgWCB0byBoYXBw
ZW7igJ0pLCB3aGljaCBpcyBoYXJkbHkgCj4gY292ZXJlZCBpbgo+IGV4aXN0aW5nIFhTIGRvY3Vt
ZW50YXRpb24uCgpUaGF0IG1heSBhbGwgYmUgdHJ1ZS4gQnV0IEkgd2FzIHRhbGtpbmcgYWJvdXQg
YWJvdXQgdGhlIGRvY3Mgd2hpY2ggR3JhbnQKaGFzIHByb2R1Y2VkLCB3aGljaCBoZSBzYWlkIHdl
cmUgaW4gYXNjaWlkb2MuCgo+ID4gSSBhZ3JlZSB0aGF0IGFjdHVhbGx5IGluIHRoZSBzb3VyY2Ug
aXMgZXZlbiBiZXR0ZXIgdGhhbiBuZXh0IHRvIHRoZQo+ID4gc291cmNlLCBpZiBpdCdzIGFuIG9w
dGlvbi4uLgo+ID4KPiA+PiBNYW51YWxseSBrZWVwaW5nIHRoZSB6aWxsaW9uIGNvbW1hbmRzIGlu
IHN5bmMgd2lsbCBiZSBxdWl0ZSB0aGUgb25nb2luZwo+ID4+IGVmZm9ydC4KPiA+IFNvbWVvbmUg
c3RpbGwgbmVlZHMgdG8gd3JpdGUvdXBkYXRlIHRoZSB0ZXh0IHJlZ2FyZGxlc3Mgb2Ygd2hlcmUg
aXQKPiA+IGxpdmVzLCBidXQgdGhhdCdzIGFzIG11Y2ggYSBjb2RlIHJldmlldyB0aGluZyBhcyBh
bnl0aGluZyBlbHNlLgo+ID4KPiBJIHdvdWxkbid0IHdhbnQgdG8gY3JlYXRlIGEgYmFycmllciBm
b3IgR3JhbnQncyBzdHVkZW50cyAob3Igb3RoZXIgCj4gcGVvcGxlIHRoYXQgd2FudCB0byBjb250
cmlidXRlKS4gUmVtZW1iZXIgdGhhdCBtb3N0IGFyZSBub3QgZGV2ZWxvcGVycyAKPiBidXQgdXNl
cnMgb2YgWENQLiAgRW1iZWRkaW5nIHRoZSBkb2N1bWVudGF0aW9uIGludG8gdGhlIGNvZGUgd291
bGQgbWVhbjoKPiBhKSBleGlzdGluZyBkb2N1bWVudCBzb3VyY2UgY29kZSB3b3VsZCBuZWVkIHRv
IGJlIHJlZmFjdG9yZWQKPiBiKSBpdCB3b3VsZCBjcmVhdGUgYSBwc3ljaG9sb2dpY2FsIGJhcnJp
ZXIgdG8gY29udHJpYnV0ZQo+IGMpIHBvc3NpYmx5IHVubmVjZXNzYXJ5IHByb2Nlc3MKPiAKPiBL
ZWVwaW5nIHRoZSBkb2N1bWVudGF0aW9uIHNlcGFyYXRlIChlaXRoZXIgaW4gYSBzZXBhcmF0ZSBy
ZXBvLCBvciAKPiBkaXJlY3RvcnkgaW4gYW4gZXhpc3RpbmcgcmVwbykgaXMgcHJvYmFibHkgdGhl
IGVhc2llc3QgYW5kIHF1aWNrZXN0IHdheSAKPiB0byBnZXQgdGhpcyBwcm9qZWN0IG9mZiB0aGUg
Z3JvdW5kIHF1aWNrbHkuCgpJbiB3aGljaCBjYXNlIEkgd291bGQgc3VnZ2VzdCBhIGRpcmVjdG9y
eSBvZiB0aGUgZXhpc3RpbmcgeGVuLWFwaSByZXBvCmFuZCBub3QgYSBjb21wbGV0ZWx5IHNlcGFy
YXRlIG9uZS4KCkJUVywgSSB3YXNuJ3Qgc3VnZ2VzdGluZyB0aGF0IHBlb3BsZSBjb250cmlidXRp
bmcgZG9jcyBuZWVkZWQgdG8gYmVjb21lCmNvZGUgY29udHJpYnV0b3JzIHRvby4gT25seSB0aGUg
aW52ZXJzZSB3aGljaCBpcyB0aGF0IHBlb3BsZSBjaGFuZ2luZwp0aGUgY29kZSBzaG91bGQgYmUg
ZXhwZWN0IHRvIHNpbXVsdGFuZW91c2x5IHVwZGF0ZSBhbnkgZG9jcyByZWxldmFudCB0bwp0aGVp
ciBjaGFuZ2UuIE9idmlvdXNseSBpdCBpcyBhbHNvIGZpbmUgdG8gaW1wcm92ZSB0aGUgZG9jcyB3
aXRob3V0CmNoYW5naW5nIHRoZSBjb2RlLgoKSWFuLgoKCl9fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVs
QGxpc3RzLnhlbi5vcmcKaHR0cDovL2xpc3RzLnhlbi5vcmcveGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Tue Sep 25 16:13:37 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 16:13:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGXlF-0001fD-Qu; Tue, 25 Sep 2012 16:13:25 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <matthew.fioravante@jhuapl.edu>) id 1TGXlD-0001f8-R8
	for xen-devel@lists.xensource.com; Tue, 25 Sep 2012 16:13:24 +0000
Received: from [85.158.139.211:27525] by server-3.bemta-5.messagelabs.com id
	64/69-16108-328D1605; Tue, 25 Sep 2012 16:13:23 +0000
X-Env-Sender: matthew.fioravante@jhuapl.edu
X-Msg-Ref: server-13.tower-206.messagelabs.com!1348589599!15941338!1
X-Originating-IP: [128.244.251.36]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG,
	UNPARSEABLE_RELAY
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29093 invoked from network); 25 Sep 2012 16:13:20 -0000
Received: from pilot.jhuapl.edu (HELO jhuapl.edu) (128.244.251.36)
	by server-13.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 25 Sep 2012 16:13:20 -0000
Received: from ([128.244.207.89])
	by pilot.jhuapl.edu with ESMTP with TLS id 63GHCH1.153618834;
	Tue, 25 Sep 2012 12:13:13 -0400
Message-ID: <5061D7CB.3020707@jhuapl.edu>
Date: Tue, 25 Sep 2012 12:11:55 -0400
From: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120827 Thunderbird/15.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <505CBEB4.8060105@jhuapl.edu>
	<1348570160.3452.191.camel@zakaz.uk.xensource.com>
In-Reply-To: <1348570160.3452.191.camel@zakaz.uk.xensource.com>
X-Enigmail-Version: 1.4.4
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH xm/xl enhancements for vptm 6/6] add vtpm
	support to libxl
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1254954324962400588=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a cryptographically signed message in MIME format.

--===============1254954324962400588==
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms020408040900080808080009"

This is a cryptographically signed message in MIME format.

--------------ms020408040900080808080009
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 09/25/2012 06:49 AM, Ian Campbell wrote:
> On Fri, 2012-09-21 at 20:23 +0100, Matthew Fioravante wrote:
>> Add support for vtpm=3D["VTPM_SPEC",...] to domain config files. Also =
add
>> commands vtpm-attach, vtpm-list, and vtpm-detach.
>>
>> Signed off by Matthew Fioravante matthew.fioravante@jhuapl.edu
>>
>> ---
>> Changes since previous:
>> * Rebased to latest xen
>> * Updated xl.cfg and xl manpages
>>
>> 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
>> @@ -298,6 +298,35 @@ 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>.
>> =20
>> +=3Ditem B<vtpm=3D[ "VTPM_SPEC_STRING", "VTPM_SPEC_STRING", ...]>
>> +
>> +Specifies the virtual trusted platform module to be
> can there be more than one?
There can be more than one. I'm not sure if anyone would ever do this
but the capability is there. I don't see any good reason to restrict it.
Also linux usually calls your tpm /dev/tpm0, so I guess its
theoretically possible to have 2 or more tpms.
>
>> +provided to the guest. Please see F<docs/misc/vtpm.txt>
>> +for more details.
>> +
>> +Each B<VTPM_SPEC_STRING> is a comma-separated list of C<KEY=3DVALUE>
>> +settings, from the following list:
>> +
>> +=3Dover 4
>> +
>> +=3Ditem C<backend=3DDOMAIN>
>> +
>> +Specify the backend domain name of id. This value must be
>> +set if you are using the vtpm domain model. If this domain
>> +is a guest, the backend should be set to the vtpm domain name.
>> +If this domain is a vtpm, the backend should be set to the
>> +vtpm manager domain name. The default value is domain 0,
>> +which should be used if you are running the vtpm process model.
> I had a look in docs/misc/vtpm.txt but didn't see anything which
> explained "vtpm process model" vs "vtpm manager domain" vs "vtpm
> domain". I suppose that's part of the future doc work you were talking
> about ;-)
Yes, that vtpm.txt is very old.
>
>> +
>> +=3Ditem C<uuid=3DUUID>
>> +
>> +Specify the uuid of this vtpm device. The uuid is used to uniquely
>> +identify the vtpm device. You can create one using the uuidgen
>> +program on unix systems. If left unspecified, a new uuid
>> +will be randomly generated everytime the domain boots.
>                                    ^missing space here
Thanks fixed below
>> +
>> +=3Dback
>> +
>>  =3Ditem B<vfb=3D[ "VFB_SPEC_STRING", "VFB_SPEC_STRING", ...]>
>> =20
>>  Specifies the paravirtual framebuffer devices which should be supplie=
d
>> [..]
>> diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
>> --- a/tools/libxl/libxl.c
>> +++ b/tools/libxl/libxl.c
> [...]
>> +static void domcreate_attach_vtpms(libxl__egc *egc, libxl__multidev
>> *multidev, int ret) {
>> +   libxl__domain_create_state *dcs =3D CONTAINER_OF(multidev, *dcs,
>> multidev);
>> +   STATE_AO_GC(dcs->ao);
>> +   int domid =3D dcs->guest_domid;
>> +
>> +   libxl_domain_config* const d_config =3D dcs->guest_config;
>> +
>> +   if(ret) {
>> +      LOG(ERROR, "unable to add nic devices");
>> +      goto error_out;
>> +   }
>> +
>> +    /* Plug nic interfaces */
> You mean vtpms here.
Also fixed
>> +int main_vtpmdetach(int argc, char **argv)
>> +{
>> +    uint32_t domid;
>> +    int opt, rc=3D0;
>> +    libxl_device_vtpm vtpm;
>> +    libxl_uuid uuid;
>> +
>> +    if ((opt =3D def_getopt(argc, argv, "", "vtpm-detach", 2)) !=3D -=
1)
>> +        return opt;
>> +
>> +    domid =3D find_domain(argv[optind]);
>> +
>> +    if ( libxl_uuid_from_string(&uuid, argv[optind+1])) {
> Why does vtpm use/need UUID's for identification rather than just a
> domid+devid like other device types?
>
> Is the UUID used for something more than identification?
It uses uuids for long term identification. Each time the vtpm saves its
data to a block device its encrypted with a key. That key is sent to the
vtpm manager for secure storage. When the vtpm boots it requests the key
from the manager. The uuid is used to tell the manager which vtpm this
is. dom/devid cannot be used because it changes on every boot of the vm.

>
> Ian.
>

Signed off by Matthew Fioravante matthew.fioravante@jhuapl.edu

---
Changes since previous:
* Rebased to latest xen
* Updated xl.cfg and xl manpages
* Fixed typos in docs and comments

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
@@ -298,6 +298,35 @@ Specifies the networking provision (both emulated ne=
twork adapters,
 and Xen virtual interfaces) to provided to the guest.  See
 F<docs/misc/xl-network-configuration.markdown>.
=20
+=3Ditem B<vtpm=3D[ "VTPM_SPEC_STRING", "VTPM_SPEC_STRING", ...]>
+
+Specifies the virtual trusted platform module to be
+provided to the guest. Please see F<docs/misc/vtpm.txt>
+for more details.
+
+Each B<VTPM_SPEC_STRING> is a comma-separated list of C<KEY=3DVALUE>
+settings, from the following list:
+
+=3Dover 4
+
+=3Ditem C<backend=3DDOMAIN>
+
+Specify the backend domain name of id. This value must be
+set if you are using the vtpm domain model. If this domain
+is a guest, the backend should be set to the vtpm domain name.
+If this domain is a vtpm, the backend should be set to the
+vtpm manager domain name. The default value is domain 0,
+which should be used if you are running the vtpm process model.
+
+=3Ditem C<uuid=3DUUID>
+
+Specify the uuid of this vtpm device. The uuid is used to uniquely
+identify the vtpm device. You can create one using the uuidgen
+program on unix systems. If left unspecified, a new uuid
+will be randomly generated every time the domain boots.
+
+=3Dback
+
 =3Ditem B<vfb=3D[ "VFB_SPEC_STRING", "VFB_SPEC_STRING", ...]>
=20
 Specifies the paravirtual framebuffer devices which should be supplied
diff --git a/docs/man/xl.pod.1 b/docs/man/xl.pod.1
--- a/docs/man/xl.pod.1
+++ b/docs/man/xl.pod.1
@@ -1101,6 +1101,31 @@ List virtual network interfaces for a domain.
=20
 =3Dback
=20
+=3Dhead2 VTPM DEVICES
+
+=3Dover 4
+
+=3Ditem B<vtpm-attach> I<domain-id> I<vtpm-device>
+
+Creates a new vtpm device in the domain specified by I<domain-id>.
+I<vtpm-device> describes the device to attach, using the same format as =
the
+B<vtpm> string in the domain config file. See L<xl.cfg> for
+more information.
+
+=3Ditem B<vtpm-detach> I<domain-id> I<devid|uuid>
+
+Removes the vtpm device from the domain specified by I<domain-id>.
+I<devid> is the numeric device id given to the virtual trusted
+platform module device. You will need to run B<xl vtpm-list> to determin=
e that number.
+Alternatively the I<uuid> of the vtpm can be used to
+select the virtual device to detach.
+
+=3Ditem B<vtpm-list> I<domain-id>
+
+List virtual trusted platform modules for a domain.
+
+=3Dback
+
 =3Dhead1 PCI PASS-THROUGH
=20
 =3Dover 4
diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -1726,6 +1726,246 @@ out:
 }
=20
 /***********************************************************************=
*******/
+int libxl__device_vtpm_setdefault(libxl__gc *gc, libxl_device_vtpm *vtpm=
)
+{
+   if(libxl_uuid_is_nil(&vtpm->uuid)) {
+      libxl_uuid_generate(&vtpm->uuid);
+   }
+   return 0;
+}
+
+static int libxl__device_from_vtpm(libxl__gc *gc, uint32_t domid,
+                                   libxl_device_vtpm *vtpm,
+                                   libxl__device *device)
+{
+   device->backend_devid   =3D vtpm->devid;
+   device->backend_domid   =3D vtpm->backend_domid;
+   device->backend_kind    =3D LIBXL__DEVICE_KIND_VTPM;
+   device->devid           =3D vtpm->devid;
+   device->domid           =3D domid;
+   device->kind            =3D LIBXL__DEVICE_KIND_VTPM;
+
+   return 0;
+}
+
+void libxl__device_vtpm_add(libxl__egc *egc, uint32_t domid,
+                           libxl_device_vtpm *vtpm,
+                           libxl__ao_device *aodev)
+{
+    STATE_AO_GC(aodev->ao);
+    flexarray_t *front;
+    flexarray_t *back;
+    libxl__device *device;
+    char *dompath, **l;
+    unsigned int nb, rc;
+
+    rc =3D libxl__device_vtpm_setdefault(gc, vtpm);
+    if (rc) goto out;
+
+    front =3D flexarray_make(16, 1);
+    if (!front) {
+        rc =3D ERROR_NOMEM;
+        goto out;
+    }
+    back =3D flexarray_make(16, 1);
+    if (!back) {
+        rc =3D ERROR_NOMEM;
+        goto out;
+    }
+
+    if(vtpm->devid =3D=3D -1) {
+        if (!(dompath =3D libxl__xs_get_dompath(gc, domid))) {
+            rc =3D ERROR_FAIL;
+            goto out_free;
+        }
+        l =3D libxl__xs_directory(gc, XBT_NULL, libxl__sprintf(gc, "%s/d=
evice/vtpm", dompath), &nb);
+        if(l =3D=3D NULL || nb =3D=3D 0) {
+            vtpm->devid =3D 0;
+        } else {
+            vtpm->devid =3D strtoul(l[nb - 1], NULL, 10) + 1;
+        }
+    }
+
+    GCNEW(device);
+    rc =3D libxl__device_from_vtpm(gc, domid, vtpm, device);
+    if ( rc !=3D 0 ) goto out_free;
+
+    flexarray_append(back, "frontend-id");
+    flexarray_append(back, libxl__sprintf(gc, "%d", domid));
+    flexarray_append(back, "online");
+    flexarray_append(back, "1");
+    flexarray_append(back, "state");
+    flexarray_append(back, libxl__sprintf(gc, "%d", 1));
+
+    flexarray_append(back, "uuid");
+    flexarray_append(back, libxl__sprintf(gc, LIBXL_UUID_FMT, LIBXL_UUID=
_BYTES(vtpm->uuid)));
+    flexarray_append(back, "instance"); /* MAYBE CAN GET RID OF THIS */
+    flexarray_append(back, "0");
+    flexarray_append(back, "pref_instance"); /* MAYBE CAN GET RID OF THI=
S */
+    flexarray_append(back, "0");
+    flexarray_append(back, "resume");
+    flexarray_append(back, "False");
+    flexarray_append(back, "ready"); /* MAYBE CAN GET RID OF THIS */
+    flexarray_append(back, "1");
+
+    flexarray_append(front, "backend-id");
+    flexarray_append(front, libxl__sprintf(gc, "%d", vtpm->backend_domid=
));
+    flexarray_append(front, "state");
+    flexarray_append(front, libxl__sprintf(gc, "%d", 1));
+    flexarray_append(front, "handle");
+    flexarray_append(front, libxl__sprintf(gc, "%d", vtpm->devid));
+
+    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));
+
+    aodev->dev =3D device;
+    aodev->action =3D DEVICE_CONNECT;
+    libxl__wait_device_connection(egc, aodev);
+
+    rc =3D 0;
+out_free:
+    flexarray_free(back);
+    flexarray_free(front);
+out:
+    aodev->rc =3D rc;
+    if(rc) aodev->callback(egc, aodev);
+    return;
+}
+
+static void libxl__device_vtpm_from_xs_fe(libxl__gc *gc,
+                                          const char* fe_path,
+                                          libxl_device_vtpm *vtpm)
+{
+   char* tmp;
+
+   memset(vtpm, 0, sizeof(*vtpm));
+   tmp =3D libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/handle", =
fe_path));
+   if (tmp) {
+      vtpm->devid =3D atoi(tmp);
+   }
+   tmp =3D libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/backend-i=
d", fe_path));
+   if(tmp) {
+      vtpm->backend_domid =3D atoi(tmp);
+   }
+   tmp =3D libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/uuid", fe=
_path));
+   if(tmp) {
+      libxl_uuid_from_string(&(vtpm->uuid), tmp);
+   }
+}
+
+libxl_device_vtpm *libxl_device_vtpm_list(libxl_ctx *ctx, uint32_t domid=
, int *num)
+{
+    GC_INIT(ctx);
+
+    libxl_device_vtpm* vtpms =3D NULL;
+    char* fe_path =3D NULL;
+    char** dir =3D NULL;
+    unsigned int ndirs =3D 0;
+
+    *num =3D 0;
+
+    fe_path =3D libxl__sprintf(gc, "%s/device/vtpm", libxl__xs_get_dompa=
th(gc, domid));
+    dir =3D libxl__xs_directory(gc, XBT_NULL, fe_path, &ndirs);
+    if(dir) {
+       vtpms =3D malloc(sizeof(*vtpms) * ndirs);
+       libxl_device_vtpm* vtpm;
+       libxl_device_vtpm* end =3D vtpms + ndirs;
+       for(vtpm =3D vtpms; vtpm < end; ++vtpm, ++dir) {
+          const char* path =3D libxl__sprintf(gc, "%s/%s", fe_path, *dir=
);
+          libxl__device_vtpm_from_xs_fe(gc, path, vtpm);
+       }
+    }
+    *num =3D ndirs;
+
+    GC_FREE;
+    return vtpms;
+}
+
+int libxl_device_vtpm_getinfo(libxl_ctx *ctx, uint32_t domid,
+                               libxl_device_vtpm *vtpm, libxl_vtpminfo *=
vtpminfo)
+{
+    GC_INIT(ctx);
+    char *dompath, *vtpmpath;
+    char *val;
+    int rc =3D 0;
+
+    libxl_vtpminfo_init(vtpminfo);
+    dompath =3D libxl__xs_get_dompath(gc, domid);
+    vtpminfo->devid =3D vtpm->devid;
+
+    vtpmpath =3D libxl__sprintf(gc, "%s/device/vtpm/%d", dompath, vtpmin=
fo->devid);
+    vtpminfo->backend =3D xs_read(ctx->xsh, XBT_NULL,
+                                libxl__sprintf(gc, "%s/backend", vtpmpat=
h), NULL);
+    if (!vtpminfo->backend) {
+        goto err;
+    }
+    if(!libxl__xs_read(gc, XBT_NULL, vtpminfo->backend)) {
+       goto err;
+    }
+
+    val =3D libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/backend-=
id", vtpmpath));
+    vtpminfo->backend_id =3D val ? strtoul(val, NULL, 10) : -1;
+    val =3D libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/state", =
vtpmpath));
+    vtpminfo->state =3D val ? strtoul(val, NULL, 10) : -1;
+    val =3D libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/event-ch=
annel", vtpmpath));
+    vtpminfo->evtch =3D val ? strtoul(val, NULL, 10) : -1;
+    val =3D libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/ring-ref=
", vtpmpath));
+    vtpminfo->rref =3D val ? strtoul(val, NULL, 10) : -1;
+    vtpminfo->frontend =3D xs_read(ctx->xsh, XBT_NULL,
+                                 libxl__sprintf(gc, "%s/frontend", vtpmi=
nfo->backend), NULL);
+    val =3D libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/frontend=
-id", vtpminfo->backend));
+    vtpminfo->frontend_id =3D val ? strtoul(val, NULL, 10) : -1;
+
+    val =3D libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/uuid", v=
tpminfo->backend));
+    if(val =3D=3D NULL) {
+       LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "%s/uuid does not exist!\n", vt=
pminfo->backend);
+       goto err;
+    }
+    if(libxl_uuid_from_string(&(vtpminfo->uuid), val)) {
+       LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "%s/uuid is a malformed uuid?? =
(%s) Probably a bug!\n", vtpminfo->backend, val);
+       goto err;
+    }
+
+    goto exit;
+err:
+    rc =3D ERROR_FAIL;
+exit:
+    GC_FREE;
+    return rc;
+}
+
+int libxl_devid_to_device_vtpm(libxl_ctx *ctx, uint32_t domid,
+                              int devid, libxl_device_vtpm *vtpm)
+{
+    libxl_device_vtpm *vtpms;
+    int nb, i;
+    int rc;
+
+    vtpms =3D libxl_device_vtpm_list(ctx, domid, &nb);
+    if (!vtpms)
+        return ERROR_FAIL;
+
+    memset(vtpm, 0, sizeof (libxl_device_vtpm));
+    rc =3D 1;
+    for (i =3D 0; i < nb; ++i) {
+        if(devid =3D=3D vtpms[i].devid) {
+            vtpm->backend_domid =3D vtpms[i].backend_domid;
+            vtpm->devid =3D vtpms[i].devid;
+            libxl_uuid_copy(&vtpm->uuid, &vtpms[i].uuid);
+            rc =3D 0;
+            break;
+        }
+    }
+
+    for (i=3D0; i<nb; i++)
+        libxl_device_vtpm_dispose(&vtpms[i]);
+    free(vtpms);
+    return rc;
+}
+
+
+/***********************************************************************=
*******/
=20
 int libxl__device_disk_setdefault(libxl__gc *gc, libxl_device_disk *disk=
)
 {
@@ -3174,6 +3414,10 @@ DEFINE_DEVICE_REMOVE(vkb, destroy, 1)
 DEFINE_DEVICE_REMOVE(vfb, remove, 0)
 DEFINE_DEVICE_REMOVE(vfb, destroy, 1)
=20
+/* vtpm */
+DEFINE_DEVICE_REMOVE(vtpm, remove, 0)
+DEFINE_DEVICE_REMOVE(vtpm, destroy, 1)
+
 #undef DEFINE_DEVICE_REMOVE
=20
 /***********************************************************************=
*******/
@@ -3208,6 +3452,9 @@ DEFINE_DEVICE_ADD(disk)
 /* nic */
 DEFINE_DEVICE_ADD(nic)
=20
+/* vtpm */
+DEFINE_DEVICE_ADD(vtpm)
+
 #undef DEFINE_DEVICE_ADD
=20
 /***********************************************************************=
*******/
diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -478,13 +478,14 @@ typedef struct {
     libxl_domain_create_info c_info;
     libxl_domain_build_info b_info;
=20
-    int num_disks, num_nics, num_pcidevs, num_vfbs, num_vkbs;
+    int num_disks, num_nics, num_pcidevs, num_vfbs, num_vkbs, num_vtpms;=

=20
     libxl_device_disk *disks;
     libxl_device_nic *nics;
     libxl_device_pci *pcidevs;
     libxl_device_vfb *vfbs;
     libxl_device_vkb *vkbs;
+    libxl_device_vtpm *vtpms;
=20
     libxl_action_on_shutdown on_poweroff;
     libxl_action_on_shutdown on_reboot;
@@ -745,6 +746,23 @@ libxl_device_nic *libxl_device_nic_list(libxl_ctx *c=
tx, uint32_t domid, int *num
 int libxl_device_nic_getinfo(libxl_ctx *ctx, uint32_t domid,
                               libxl_device_nic *nic, libxl_nicinfo *nici=
nfo);
=20
+/* Virtual TPMs */
+int libxl_device_vtpm_add(libxl_ctx *ctx, uint32_t domid, libxl_device_v=
tpm *vtpm,
+                          const libxl_asyncop_how *ao_how)
+                          LIBXL_EXTERNAL_CALLERS_ONLY;
+int libxl_device_vtpm_remove(libxl_ctx *ctx, uint32_t domid,
+                            libxl_device_vtpm *vtpm,
+                            const libxl_asyncop_how *ao_how)
+                            LIBXL_EXTERNAL_CALLERS_ONLY;
+int libxl_device_vtpm_destroy(libxl_ctx *ctx, uint32_t domid,
+                              libxl_device_vtpm *vtpm,
+                              const libxl_asyncop_how *ao_how)
+                              LIBXL_EXTERNAL_CALLERS_ONLY;
+
+libxl_device_vtpm *libxl_device_vtpm_list(libxl_ctx *ctx, uint32_t domid=
, int *num);
+int libxl_device_vtpm_getinfo(libxl_ctx *ctx, uint32_t domid,
+                               libxl_device_vtpm *vtpm, libxl_vtpminfo *=
vtpminfo);
+
 /* Keyboard */
 int libxl_device_vkb_add(libxl_ctx *ctx, uint32_t domid, libxl_device_vk=
b *vkb,
                          const libxl_asyncop_how *ao_how)
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
@@ -55,6 +55,10 @@ void libxl_domain_config_dispose(libxl_domain_config *=
d_config)
         libxl_device_vkb_dispose(&d_config->vkbs[i]);
     free(d_config->vkbs);
=20
+    for (i=3D0; i<d_config->num_vtpms; i++)
+       libxl_device_vtpm_dispose(&d_config->vtpms[i]);
+    free(d_config->vtpms);
+
     libxl_domain_create_info_dispose(&d_config->c_info);
     libxl_domain_build_info_dispose(&d_config->b_info);
 }
@@ -601,6 +605,8 @@ static void domcreate_bootloader_done(libxl__egc *egc=
,
 static void domcreate_launch_dm(libxl__egc *egc, libxl__multidev *aodevs=
,
                                 int ret);
=20
+static void domcreate_attach_vtpms(libxl__egc *egc, libxl__multidev *mul=
tidev,
+                                   int ret);
 static void domcreate_attach_pci(libxl__egc *egc, libxl__multidev *aodev=
s,
                                  int ret);
=20
@@ -1084,13 +1090,13 @@ static void domcreate_devmodel_started(libxl__egc=
 *egc,
     if (d_config->num_nics > 0) {
         /* Attach nics */
         libxl__multidev_begin(ao, &dcs->multidev);
-        dcs->multidev.callback =3D domcreate_attach_pci;
+        dcs->multidev.callback =3D domcreate_attach_vtpms;
         libxl__add_nics(egc, ao, domid, d_config, &dcs->multidev);
         libxl__multidev_prepared(egc, &dcs->multidev, 0);
         return;
     }
=20
-    domcreate_attach_pci(egc, &dcs->multidev, 0);
+    domcreate_attach_vtpms(egc, &dcs->multidev, 0);
     return;
=20
 error_out:
@@ -1098,6 +1104,36 @@ error_out:
     domcreate_complete(egc, dcs, ret);
 }
=20
+static void domcreate_attach_vtpms(libxl__egc *egc, libxl__multidev *mul=
tidev, int ret) {
+   libxl__domain_create_state *dcs =3D CONTAINER_OF(multidev, *dcs, mult=
idev);
+   STATE_AO_GC(dcs->ao);
+   int domid =3D dcs->guest_domid;
+
+   libxl_domain_config* const d_config =3D dcs->guest_config;
+
+   if(ret) {
+      LOG(ERROR, "unable to add nic devices");
+      goto error_out;
+   }
+
+    /* Plug vtpm devices */
+    if (d_config->num_vtpms > 0) {
+        /* Attach vtpms */
+        libxl__multidev_begin(ao, &dcs->multidev);
+        dcs->multidev.callback =3D domcreate_attach_pci;
+        libxl__add_vtpms(egc, ao, domid, d_config, &dcs->multidev);
+        libxl__multidev_prepared(egc, &dcs->multidev, 0);
+        return;
+    }
+
+   domcreate_attach_pci(egc, multidev, 0);
+   return;
+
+error_out:
+   assert(ret);
+   domcreate_complete(egc, dcs, ret);
+}
+
 static void domcreate_attach_pci(libxl__egc *egc, libxl__multidev *multi=
dev,
                                  int ret)
 {
@@ -1111,7 +1147,7 @@ static void domcreate_attach_pci(libxl__egc *egc, l=
ibxl__multidev *multidev,
     libxl_domain_config *const d_config =3D dcs->guest_config;
=20
     if (ret) {
-        LOG(ERROR, "unable to add nic devices");
+        LOG(ERROR, "unable to add vtpm devices");
         goto error_out;
     }
=20
diff --git a/tools/libxl/libxl_device.c b/tools/libxl/libxl_device.c
--- a/tools/libxl/libxl_device.c
+++ b/tools/libxl/libxl_device.c
@@ -515,6 +515,7 @@ void libxl__multidev_prepared(libxl__egc *egc,
=20
 DEFINE_DEVICES_ADD(disk)
 DEFINE_DEVICES_ADD(nic)
+DEFINE_DEVICES_ADD(vtpm)
=20
 #undef DEFINE_DEVICES_ADD
=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
@@ -954,6 +954,7 @@ _hidden int libxl__device_disk_setdefault(libxl__gc *=
gc,
                                           libxl_device_disk *disk);
 _hidden int libxl__device_nic_setdefault(libxl__gc *gc, libxl_device_nic=
 *nic,
                                          uint32_t domid);
+_hidden int libxl__device_vtpm_setdefault(libxl__gc *gc, libxl_device_vt=
pm *vtpm);
 _hidden int libxl__device_vfb_setdefault(libxl__gc *gc, libxl_device_vfb=
 *vfb);
 _hidden int libxl__device_vkb_setdefault(libxl__gc *gc, libxl_device_vkb=
 *vkb);
 _hidden int libxl__device_pci_setdefault(libxl__gc *gc, libxl_device_pci=
 *pci);
@@ -1975,6 +1976,10 @@ _hidden void libxl__device_nic_add(libxl__egc *egc=
, uint32_t domid,
                                    libxl_device_nic *nic,
                                    libxl__ao_device *aodev);
=20
+_hidden void libxl__device_vtpm_add(libxl__egc *egc, uint32_t domid,
+                                   libxl_device_vtpm *vtpm,
+                                   libxl__ao_device *aodev);
+
 /* Internal function to connect a vkb device */
 _hidden int libxl__device_vkb_add(libxl__gc *gc, uint32_t domid,
                                   libxl_device_vkb *vkb);
@@ -2407,6 +2412,10 @@ _hidden void libxl__add_nics(libxl__egc *egc, libx=
l__ao *ao, uint32_t domid,
                              libxl_domain_config *d_config,
                              libxl__multidev *multidev);
=20
+_hidden void libxl__add_vtpms(libxl__egc *egc, libxl__ao *ao, uint32_t d=
omid,
+                             libxl_domain_config *d_config,
+                             libxl__multidev *multidev);
+
 /*----- device model creation -----*/
=20
 /* First layer; wraps libxl__spawn_spawn. */
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
@@ -395,6 +395,12 @@ libxl_device_pci =3D Struct("device_pci", [
     ("permissive", bool),
     ])
=20
+libxl_device_vtpm =3D Struct("device_vtpm", [
+    ("backend_domid",    libxl_domid),
+    ("devid",            libxl_devid),
+    ("uuid",             libxl_uuid),
+])
+
 libxl_diskinfo =3D Struct("diskinfo", [
     ("backend", string),
     ("backend_id", uint32),
@@ -418,6 +424,18 @@ libxl_nicinfo =3D Struct("nicinfo", [
     ("rref_rx", integer),
     ], dir=3DDIR_OUT)
=20
+libxl_vtpminfo =3D Struct("vtpminfo", [
+    ("backend", string),
+    ("backend_id", uint32),
+    ("frontend", string),
+    ("frontend_id", uint32),
+    ("devid", libxl_devid),
+    ("state", integer),
+    ("evtch", integer),
+    ("rref", integer),
+    ("uuid", libxl_uuid),
+    ], dir=3DDIR_OUT)
+
 libxl_vcpuinfo =3D Struct("vcpuinfo", [
     ("vcpuid", uint32),
     ("cpu", uint32),
diff --git a/tools/libxl/libxl_types_internal.idl b/tools/libxl/libxl_typ=
es_internal.idl
--- a/tools/libxl/libxl_types_internal.idl
+++ b/tools/libxl/libxl_types_internal.idl
@@ -19,6 +19,7 @@ libxl__device_kind =3D Enumeration("device_kind", [
     (5, "VFB"),
     (6, "VKBD"),
     (7, "CONSOLE"),
+    (8, "VTPM"),
     ])
=20
 libxl__console_backend =3D Enumeration("console_backend", [
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
@@ -463,6 +463,35 @@ int libxl_pipe(libxl_ctx *ctx, int pipes[2])
     return 0;
 }
=20
+int libxl_uuid_to_device_vtpm(libxl_ctx *ctx, uint32_t domid,
+                            libxl_uuid* uuid, libxl_device_vtpm *vtpm)
+{
+    libxl_device_vtpm *vtpms;
+    int nb, i;
+    int rc;
+
+    vtpms =3D libxl_device_vtpm_list(ctx, domid, &nb);
+    if (!vtpms)
+        return ERROR_FAIL;
+
+    memset(vtpm, 0, sizeof (libxl_device_vtpm));
+    rc =3D 1;
+    for (i =3D 0; i < nb; ++i) {
+        if(!libxl_uuid_compare(uuid, &vtpms[i].uuid)) {
+            vtpm->backend_domid =3D vtpms[i].backend_domid;
+            vtpm->devid =3D vtpms[i].devid;
+            libxl_uuid_copy(&vtpm->uuid, &vtpms[i].uuid);
+            rc =3D 0;
+            break;
+        }
+    }
+
+    for (i=3D0; i<nb; i++)
+        libxl_device_vtpm_dispose(&vtpms[i]);
+    free(vtpms);
+    return rc;
+}
+
 int libxl_mac_to_device_nic(libxl_ctx *ctx, uint32_t domid,
                             const char *mac, libxl_device_nic *nic)
 {
diff --git a/tools/libxl/libxl_utils.h b/tools/libxl/libxl_utils.h
--- a/tools/libxl/libxl_utils.h
+++ b/tools/libxl/libxl_utils.h
@@ -64,6 +64,11 @@ int libxl_devid_to_device_nic(libxl_ctx *ctx, uint32_t=
 domid, int devid,
 int libxl_vdev_to_device_disk(libxl_ctx *ctx, uint32_t domid, const char=
 *vdev,
                                libxl_device_disk *disk);
=20
+int libxl_uuid_to_device_vtpm(libxl_ctx *ctx, uint32_t domid,
+                               libxl_uuid *uuid, libxl_device_vtpm *vtpm=
);
+int libxl_devid_to_device_vtpm(libxl_ctx *ctx, uint32_t domid,
+                               int devid, libxl_device_vtpm *vtpm);
+
 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. */
diff --git a/tools/libxl/xl.h b/tools/libxl/xl.h
--- a/tools/libxl/xl.h
+++ b/tools/libxl/xl.h
@@ -79,6 +79,9 @@ int main_networkdetach(int argc, char **argv);
 int main_blockattach(int argc, char **argv);
 int main_blocklist(int argc, char **argv);
 int main_blockdetach(int argc, char **argv);
+int main_vtpmattach(int argc, char **argv);
+int main_vtpmlist(int argc, char **argv);
+int main_vtpmdetach(int argc, char **argv);
 int main_uptime(int argc, char **argv);
 int main_tmem_list(int argc, char **argv);
 int main_tmem_freeze(int argc, char **argv);
diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -573,7 +573,7 @@ static void parse_config_data(const char *config_sour=
ce,
     const char *buf;
     long l;
     XLU_Config *config;
-    XLU_ConfigList *cpus, *vbds, *nics, *pcis, *cvfbs, *cpuids;
+    XLU_ConfigList *cpus, *vbds, *nics, *pcis, *cvfbs, *cpuids, *vtpms;
     XLU_ConfigList *ioports, *irqs, *iomem;
     int num_ioports, num_irqs, num_iomem;
     int pci_power_mgmt =3D 0;
@@ -1045,6 +1045,47 @@ static void parse_config_data(const char *config_s=
ource,
         }
     }
=20
+    if (!xlu_cfg_get_list(config, "vtpm", &vtpms, 0, 0)) {
+        d_config->num_vtpms =3D 0;
+        d_config->vtpms =3D NULL;
+        while ((buf =3D xlu_cfg_get_listitem (vtpms, d_config->num_vtpms=
)) !=3D NULL) {
+            libxl_device_vtpm *vtpm;
+            char * buf2 =3D strdup(buf);
+            char *p, *p2;
+
+            d_config->vtpms =3D (libxl_device_vtpm *) realloc(d_config->=
vtpms, sizeof(libxl_device_vtpm) * (d_config->num_vtpms+1));
+            vtpm =3D d_config->vtpms + d_config->num_vtpms;
+            libxl_device_vtpm_init(vtpm);
+            vtpm->devid =3D d_config->num_vtpms;
+
+            p =3D strtok(buf2, ",");
+            if (!p)
+                goto skip_vtpm;
+            do {
+                while(*p =3D=3D ' ')
+                    ++p;
+                if ((p2 =3D strchr(p, '=3D')) =3D=3D NULL)
+                    break;
+                *p2 =3D '\0';
+                if (!strcmp(p, "backend")) {
+                    if(domain_qualifier_to_domid(p2 + 1, &(vtpm->backend=
_domid), 0))
+                    {
+                        fprintf(stderr, "Specified backend domain does n=
ot exist, defaulting to Dom0\n");
+                        vtpm->backend_domid =3D 0;
+                    }
+                } else if(!strcmp(p, "uuid")) {
+                    if( libxl_uuid_from_string(&vtpm->uuid, p2 + 1) ) {
+                        fprintf(stderr, "Failed to parse vtpm UUID: %s\n=
", p2 + 1);
+                        exit(1);
+                    }
+                }
+            } while ((p =3D strtok(NULL, ",")) !=3D NULL);
+skip_vtpm:
+            free(buf2);
+            d_config->num_vtpms++;
+        }
+    }
+
     if (!xlu_cfg_get_list (config, "vif", &nics, 0, 0)) {
         d_config->num_nics =3D 0;
         d_config->nics =3D NULL;
@@ -1070,7 +1111,7 @@ static void parse_config_data(const char *config_so=
urce,
=20
             p =3D strtok(buf2, ",");
             if (!p)
-                goto skip;
+                goto skip_nic;
             do {
                 while (*p =3D=3D ' ')
                     p++;
@@ -1134,7 +1175,7 @@ static void parse_config_data(const char *config_so=
urce,
                     fprintf(stderr, "the accel parameter for vifs is cur=
rently not supported\n");
                 }
             } while ((p =3D strtok(NULL, ",")) !=3D NULL);
-skip:
+skip_nic:
             free(buf2);
             d_config->num_nics++;
         }
@@ -5570,6 +5611,131 @@ int main_blockdetach(int argc, char **argv)
     return rc;
 }
=20
+int main_vtpmattach(int argc, char **argv)
+{
+    int opt;
+    libxl_device_vtpm vtpm;
+    char *oparg;
+    unsigned int val;
+    uint32_t domid;
+
+    if ((opt =3D def_getopt(argc, argv, "", "vtpm-attach", 1)) !=3D -1)
+        return opt;
+
+    if (domain_qualifier_to_domid(argv[optind], &domid, 0) < 0) {
+        fprintf(stderr, "%s is an invalid domain identifier\n", argv[opt=
ind]);
+        return 1;
+    }
+    ++optind;
+
+    libxl_device_vtpm_init(&vtpm);
+    for (argv +=3D optind, argc -=3D optind; argc > 0; ++argv, --argc) {=

+        if (MATCH_OPTION("uuid", *argv, oparg)) {
+            if(libxl_uuid_from_string(&(vtpm.uuid), oparg)) {
+                fprintf(stderr, "Invalid uuid specified (%s)\n", oparg);=

+                return 1;
+            }
+        } else if (MATCH_OPTION("backend", *argv, oparg)) {
+            if(domain_qualifier_to_domid(oparg, &val, 0)) {
+                fprintf(stderr, "Specified backend domain does not exist=
, defaulting to Dom0\n");
+                val =3D 0;
+            }
+            vtpm.backend_domid =3D val;
+        } else {
+            fprintf(stderr, "unrecognized argument `%s'\n", *argv);
+            return 1;
+        }
+    }
+
+    if(dryrun_only) {
+       char* json =3D libxl_device_vtpm_to_json(ctx, &vtpm);
+       printf("vtpm: %s\n", json);
+       free(json);
+       libxl_device_vtpm_dispose(&vtpm);
+       if (ferror(stdout) || fflush(stdout)) { perror("stdout"); exit(-1=
); }
+       return 0;
+    }
+
+    if (libxl_device_vtpm_add(ctx, domid, &vtpm, 0)) {
+        fprintf(stderr, "libxl_device_vtpm_add failed.\n");
+        return 1;
+    }
+    libxl_device_vtpm_dispose(&vtpm);
+    return 0;
+}
+
+int main_vtpmlist(int argc, char **argv)
+{
+    int opt;
+    libxl_device_vtpm *vtpms;
+    libxl_vtpminfo vtpminfo;
+    int nb, i;
+
+    if ((opt =3D def_getopt(argc, argv, "", "vtpm-list", 1)) !=3D -1)
+        return opt;
+
+    /*      Idx  BE   UUID   Hdl  Sta  evch rref  BE-path */
+    printf("%-3s %-2s %-36s %-6s %-5s %-6s %-5s %-10s\n",
+           "Idx", "BE", "Uuid", "handle", "state", "evt-ch", "ring-ref",=
 "BE-path");
+    for (argv +=3D optind, argc -=3D optind; argc > 0; --argc, ++argv) {=

+        uint32_t domid;
+        if (domain_qualifier_to_domid(*argv, &domid, 0) < 0) {
+            fprintf(stderr, "%s is an invalid domain identifier\n", *arg=
v);
+            continue;
+        }
+        if (!(vtpms =3D libxl_device_vtpm_list(ctx, domid, &nb))) {
+            continue;
+        }
+        for (i =3D 0; i < nb; ++i) {
+           if(!libxl_device_vtpm_getinfo(ctx, domid, &vtpms[i], &vtpminf=
o)) {
+              /*      Idx  BE     UUID             Hdl Sta evch rref BE-=
path*/
+              printf("%-3d %-2d " LIBXL_UUID_FMT " %6d %5d %6d %8d %-30s=
\n",
+                    vtpminfo.devid, vtpminfo.backend_id,
+                    LIBXL_UUID_BYTES(vtpminfo.uuid),
+                    vtpminfo.devid, vtpminfo.state, vtpminfo.evtch,
+                    vtpminfo.rref, vtpminfo.backend);
+
+              libxl_vtpminfo_dispose(&vtpminfo);
+           }
+           libxl_device_vtpm_dispose(&vtpms[i]);
+        }
+        free(vtpms);
+    }
+    return 0;
+}
+
+int main_vtpmdetach(int argc, char **argv)
+{
+    uint32_t domid;
+    int opt, rc=3D0;
+    libxl_device_vtpm vtpm;
+    libxl_uuid uuid;
+
+    if ((opt =3D def_getopt(argc, argv, "", "vtpm-detach", 2)) !=3D -1)
+        return opt;
+
+    domid =3D find_domain(argv[optind]);
+
+    if ( libxl_uuid_from_string(&uuid, argv[optind+1])) {
+        if (libxl_devid_to_device_vtpm(ctx, domid, atoi(argv[optind+1]),=
 &vtpm)) {
+            fprintf(stderr, "Unknown device %s.\n", argv[optind+1]);
+            return 1;
+        }
+    } else {
+        if (libxl_uuid_to_device_vtpm(ctx, domid, &uuid, &vtpm)) {
+            fprintf(stderr, "Unknown device %s.\n", argv[optind+1]);
+            return 1;
+        }
+    }
+    rc =3D libxl_device_vtpm_remove(ctx, domid, &vtpm, 0);
+    if (rc) {
+        fprintf(stderr, "libxl_device_vtpm_remove failed.\n");
+    }
+    libxl_device_vtpm_dispose(&vtpm);
+    return rc;
+}
+
+
 static char *uptime_to_string(unsigned long uptime, int short_mode)
 {
     int sec, min, hour, day;
diff --git a/tools/libxl/xl_cmdtable.c b/tools/libxl/xl_cmdtable.c
--- a/tools/libxl/xl_cmdtable.c
+++ b/tools/libxl/xl_cmdtable.c
@@ -338,6 +338,21 @@ struct cmd_spec cmd_table[] =3D {
       "Destroy a domain's virtual block device",
       "<Domain> <DevId>",
     },
+    { "vtpm-attach",
+      &main_vtpmattach, 0, 1,
+      "Create a new virtual TPM device",
+      "<Domain> [uuid=3D<uuid>] [backend=3D<BackDomain>]",
+    },
+    { "vtpm-list",
+      &main_vtpmlist, 0, 0,
+      "List virtual TPM devices for a domain",
+      "<Domain(s)>",
+    },
+    { "vtpm-detach",
+      &main_vtpmdetach, 0, 1,
+      "Destroy a domain's virtual TPM device",
+      "<Domain> <DevId|uuid>",
+    },
     { "uptime",
       &main_uptime, 0, 0,
       "Print uptime for all/some domains",





--------------ms020408040900080808080009
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIDyjCC
A8YwggMvoAMCAQICBD/xyf0wDQYJKoZIhvcNAQEFBQAwLzELMAkGA1UEBhMCVVMxDzANBgNV
BAoTBkpIVUFQTDEPMA0GA1UECxMGQklTRENBMB4XDTEwMDYxMTE4MjIwNloXDTEzMDYxMTE4
NTIwNlowZjELMAkGA1UEBhMCVVMxDzANBgNVBAoTBkpIVUFQTDEPMA0GA1UECxMGUGVvcGxl
MTUwFgYDVQQLEw9WUE5Hcm91cC1CSVNEQ0EwGwYDVQQDExRNYXR0aGV3IEUgRmlvcmF2YW50
ZTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAnpbwVSP6o1Nb5lcW7dd3yTo9iBJdi7qz
4nANOMFPK7JOy5npKN1iiousl28U/scUJES55gPwAWYJK3uVyQAsA4adgDKi5DoD1UHDQEwp
bY7iHLJeq0NPr4BqYNqnCFPbE6HC8zSJrr4qKn+gVUQT39SIFqdiIPJwZL8FYTRQ/zsCAwEA
AaOCAbYwggGyMAsGA1UdDwQEAwIHgDArBgNVHRAEJDAigA8yMDEwMDYxMTE4MjIwNlqBDzIw
MTIwNzE3MjI1MjA2WjAbBg0rBgEEAbMlCwMBAQEBBAoWCGZpb3JhbWUxMBsGDSsGAQQBsyUL
AwEBAQIEChIIMDAxMDQyNjEwWAYJYIZIAYb6ax4BBEsMSVRoZSBwcml2YXRlIGtleSBjb3Jy
ZXNwb25kaW5nIHRvIHRoaXMgY2VydGlmaWNhdGUgbWF5IGhhdmUgYmVlbiBleHBvcnRlZC4w
KAYDVR0RBCEwH4EdTWF0dGhldy5GaW9yYXZhbnRlQGpodWFwbC5lZHUwUgYDVR0fBEswSTBH
oEWgQ6RBMD8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJU0RD
QTEOMAwGA1UEAxMFQ1JMNTYwHwYDVR0jBBgwFoAUCDUpmxH52EU2CyWmF2EJMB1yqeswHQYD
VR0OBBYEFO6LYxg6r9wHZ+zdQtBHn1dZ/YTNMAkGA1UdEwQCMAAwGQYJKoZIhvZ9B0EABAww
ChsEVjcuMQMCBLAwDQYJKoZIhvcNAQEFBQADgYEAJO9HQh4YNChVLzuZqK5ARJARD8JoujGZ
fdo75quvg2jXFQe2sEjvLnxJZgm/pv8fdZakq48CWwjYHKuvIp7sDjTEsQfo+y7SpN/N2NvJ
WU5SqfK1VgYtNLRRoGJUB5Q1aZ+Dg95g3kqpyfpUMISJL8IKVLtJVfN4fggFVUYZ9wwxggGr
MIIBpwIBATA3MC8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJ
U0RDQQIEP/HJ/TAJBgUrDgMCGgUAoIHLMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ
KoZIhvcNAQkFMQ8XDTEyMDkyNTE2MTE1NVowIwYJKoZIhvcNAQkEMRYEFEITSUQL2rhd8Cjb
W8dPpxpMLqLTMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAK
BggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI
KoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEgYBqvpq5U7WCOF0P30eDi89MNSj1tUxQvW1B
bVSKk26zlDNj3ADh7YdBISYtec3neLyXK3v6DcEuQozlZ3P1sc7QUPf58OEQN5znsWdTRyiW
4XJlM6u+CMMQ/SwjOF5M3/YpDUK6JrQoteHRi7QyzPmi5VmnrMq5Sk9dEKfXcSd02wAAAAAA
AA==
--------------ms020408040900080808080009--


--===============1254954324962400588==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============1254954324962400588==--


From xen-devel-bounces@lists.xen.org Tue Sep 25 16:13:37 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 16:13:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGXlF-0001fD-Qu; Tue, 25 Sep 2012 16:13:25 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <matthew.fioravante@jhuapl.edu>) id 1TGXlD-0001f8-R8
	for xen-devel@lists.xensource.com; Tue, 25 Sep 2012 16:13:24 +0000
Received: from [85.158.139.211:27525] by server-3.bemta-5.messagelabs.com id
	64/69-16108-328D1605; Tue, 25 Sep 2012 16:13:23 +0000
X-Env-Sender: matthew.fioravante@jhuapl.edu
X-Msg-Ref: server-13.tower-206.messagelabs.com!1348589599!15941338!1
X-Originating-IP: [128.244.251.36]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG,
	UNPARSEABLE_RELAY
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29093 invoked from network); 25 Sep 2012 16:13:20 -0000
Received: from pilot.jhuapl.edu (HELO jhuapl.edu) (128.244.251.36)
	by server-13.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 25 Sep 2012 16:13:20 -0000
Received: from ([128.244.207.89])
	by pilot.jhuapl.edu with ESMTP with TLS id 63GHCH1.153618834;
	Tue, 25 Sep 2012 12:13:13 -0400
Message-ID: <5061D7CB.3020707@jhuapl.edu>
Date: Tue, 25 Sep 2012 12:11:55 -0400
From: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120827 Thunderbird/15.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <505CBEB4.8060105@jhuapl.edu>
	<1348570160.3452.191.camel@zakaz.uk.xensource.com>
In-Reply-To: <1348570160.3452.191.camel@zakaz.uk.xensource.com>
X-Enigmail-Version: 1.4.4
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH xm/xl enhancements for vptm 6/6] add vtpm
	support to libxl
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1254954324962400588=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a cryptographically signed message in MIME format.

--===============1254954324962400588==
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms020408040900080808080009"

This is a cryptographically signed message in MIME format.

--------------ms020408040900080808080009
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 09/25/2012 06:49 AM, Ian Campbell wrote:
> On Fri, 2012-09-21 at 20:23 +0100, Matthew Fioravante wrote:
>> Add support for vtpm=3D["VTPM_SPEC",...] to domain config files. Also =
add
>> commands vtpm-attach, vtpm-list, and vtpm-detach.
>>
>> Signed off by Matthew Fioravante matthew.fioravante@jhuapl.edu
>>
>> ---
>> Changes since previous:
>> * Rebased to latest xen
>> * Updated xl.cfg and xl manpages
>>
>> 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
>> @@ -298,6 +298,35 @@ 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>.
>> =20
>> +=3Ditem B<vtpm=3D[ "VTPM_SPEC_STRING", "VTPM_SPEC_STRING", ...]>
>> +
>> +Specifies the virtual trusted platform module to be
> can there be more than one?
There can be more than one. I'm not sure if anyone would ever do this
but the capability is there. I don't see any good reason to restrict it.
Also linux usually calls your tpm /dev/tpm0, so I guess its
theoretically possible to have 2 or more tpms.
>
>> +provided to the guest. Please see F<docs/misc/vtpm.txt>
>> +for more details.
>> +
>> +Each B<VTPM_SPEC_STRING> is a comma-separated list of C<KEY=3DVALUE>
>> +settings, from the following list:
>> +
>> +=3Dover 4
>> +
>> +=3Ditem C<backend=3DDOMAIN>
>> +
>> +Specify the backend domain name of id. This value must be
>> +set if you are using the vtpm domain model. If this domain
>> +is a guest, the backend should be set to the vtpm domain name.
>> +If this domain is a vtpm, the backend should be set to the
>> +vtpm manager domain name. The default value is domain 0,
>> +which should be used if you are running the vtpm process model.
> I had a look in docs/misc/vtpm.txt but didn't see anything which
> explained "vtpm process model" vs "vtpm manager domain" vs "vtpm
> domain". I suppose that's part of the future doc work you were talking
> about ;-)
Yes, that vtpm.txt is very old.
>
>> +
>> +=3Ditem C<uuid=3DUUID>
>> +
>> +Specify the uuid of this vtpm device. The uuid is used to uniquely
>> +identify the vtpm device. You can create one using the uuidgen
>> +program on unix systems. If left unspecified, a new uuid
>> +will be randomly generated everytime the domain boots.
>                                    ^missing space here
Thanks fixed below
>> +
>> +=3Dback
>> +
>>  =3Ditem B<vfb=3D[ "VFB_SPEC_STRING", "VFB_SPEC_STRING", ...]>
>> =20
>>  Specifies the paravirtual framebuffer devices which should be supplie=
d
>> [..]
>> diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
>> --- a/tools/libxl/libxl.c
>> +++ b/tools/libxl/libxl.c
> [...]
>> +static void domcreate_attach_vtpms(libxl__egc *egc, libxl__multidev
>> *multidev, int ret) {
>> +   libxl__domain_create_state *dcs =3D CONTAINER_OF(multidev, *dcs,
>> multidev);
>> +   STATE_AO_GC(dcs->ao);
>> +   int domid =3D dcs->guest_domid;
>> +
>> +   libxl_domain_config* const d_config =3D dcs->guest_config;
>> +
>> +   if(ret) {
>> +      LOG(ERROR, "unable to add nic devices");
>> +      goto error_out;
>> +   }
>> +
>> +    /* Plug nic interfaces */
> You mean vtpms here.
Also fixed
>> +int main_vtpmdetach(int argc, char **argv)
>> +{
>> +    uint32_t domid;
>> +    int opt, rc=3D0;
>> +    libxl_device_vtpm vtpm;
>> +    libxl_uuid uuid;
>> +
>> +    if ((opt =3D def_getopt(argc, argv, "", "vtpm-detach", 2)) !=3D -=
1)
>> +        return opt;
>> +
>> +    domid =3D find_domain(argv[optind]);
>> +
>> +    if ( libxl_uuid_from_string(&uuid, argv[optind+1])) {
> Why does vtpm use/need UUID's for identification rather than just a
> domid+devid like other device types?
>
> Is the UUID used for something more than identification?
It uses uuids for long term identification. Each time the vtpm saves its
data to a block device its encrypted with a key. That key is sent to the
vtpm manager for secure storage. When the vtpm boots it requests the key
from the manager. The uuid is used to tell the manager which vtpm this
is. dom/devid cannot be used because it changes on every boot of the vm.

>
> Ian.
>

Signed off by Matthew Fioravante matthew.fioravante@jhuapl.edu

---
Changes since previous:
* Rebased to latest xen
* Updated xl.cfg and xl manpages
* Fixed typos in docs and comments

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
@@ -298,6 +298,35 @@ Specifies the networking provision (both emulated ne=
twork adapters,
 and Xen virtual interfaces) to provided to the guest.  See
 F<docs/misc/xl-network-configuration.markdown>.
=20
+=3Ditem B<vtpm=3D[ "VTPM_SPEC_STRING", "VTPM_SPEC_STRING", ...]>
+
+Specifies the virtual trusted platform module to be
+provided to the guest. Please see F<docs/misc/vtpm.txt>
+for more details.
+
+Each B<VTPM_SPEC_STRING> is a comma-separated list of C<KEY=3DVALUE>
+settings, from the following list:
+
+=3Dover 4
+
+=3Ditem C<backend=3DDOMAIN>
+
+Specify the backend domain name of id. This value must be
+set if you are using the vtpm domain model. If this domain
+is a guest, the backend should be set to the vtpm domain name.
+If this domain is a vtpm, the backend should be set to the
+vtpm manager domain name. The default value is domain 0,
+which should be used if you are running the vtpm process model.
+
+=3Ditem C<uuid=3DUUID>
+
+Specify the uuid of this vtpm device. The uuid is used to uniquely
+identify the vtpm device. You can create one using the uuidgen
+program on unix systems. If left unspecified, a new uuid
+will be randomly generated every time the domain boots.
+
+=3Dback
+
 =3Ditem B<vfb=3D[ "VFB_SPEC_STRING", "VFB_SPEC_STRING", ...]>
=20
 Specifies the paravirtual framebuffer devices which should be supplied
diff --git a/docs/man/xl.pod.1 b/docs/man/xl.pod.1
--- a/docs/man/xl.pod.1
+++ b/docs/man/xl.pod.1
@@ -1101,6 +1101,31 @@ List virtual network interfaces for a domain.
=20
 =3Dback
=20
+=3Dhead2 VTPM DEVICES
+
+=3Dover 4
+
+=3Ditem B<vtpm-attach> I<domain-id> I<vtpm-device>
+
+Creates a new vtpm device in the domain specified by I<domain-id>.
+I<vtpm-device> describes the device to attach, using the same format as =
the
+B<vtpm> string in the domain config file. See L<xl.cfg> for
+more information.
+
+=3Ditem B<vtpm-detach> I<domain-id> I<devid|uuid>
+
+Removes the vtpm device from the domain specified by I<domain-id>.
+I<devid> is the numeric device id given to the virtual trusted
+platform module device. You will need to run B<xl vtpm-list> to determin=
e that number.
+Alternatively the I<uuid> of the vtpm can be used to
+select the virtual device to detach.
+
+=3Ditem B<vtpm-list> I<domain-id>
+
+List virtual trusted platform modules for a domain.
+
+=3Dback
+
 =3Dhead1 PCI PASS-THROUGH
=20
 =3Dover 4
diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -1726,6 +1726,246 @@ out:
 }
=20
 /***********************************************************************=
*******/
+int libxl__device_vtpm_setdefault(libxl__gc *gc, libxl_device_vtpm *vtpm=
)
+{
+   if(libxl_uuid_is_nil(&vtpm->uuid)) {
+      libxl_uuid_generate(&vtpm->uuid);
+   }
+   return 0;
+}
+
+static int libxl__device_from_vtpm(libxl__gc *gc, uint32_t domid,
+                                   libxl_device_vtpm *vtpm,
+                                   libxl__device *device)
+{
+   device->backend_devid   =3D vtpm->devid;
+   device->backend_domid   =3D vtpm->backend_domid;
+   device->backend_kind    =3D LIBXL__DEVICE_KIND_VTPM;
+   device->devid           =3D vtpm->devid;
+   device->domid           =3D domid;
+   device->kind            =3D LIBXL__DEVICE_KIND_VTPM;
+
+   return 0;
+}
+
+void libxl__device_vtpm_add(libxl__egc *egc, uint32_t domid,
+                           libxl_device_vtpm *vtpm,
+                           libxl__ao_device *aodev)
+{
+    STATE_AO_GC(aodev->ao);
+    flexarray_t *front;
+    flexarray_t *back;
+    libxl__device *device;
+    char *dompath, **l;
+    unsigned int nb, rc;
+
+    rc =3D libxl__device_vtpm_setdefault(gc, vtpm);
+    if (rc) goto out;
+
+    front =3D flexarray_make(16, 1);
+    if (!front) {
+        rc =3D ERROR_NOMEM;
+        goto out;
+    }
+    back =3D flexarray_make(16, 1);
+    if (!back) {
+        rc =3D ERROR_NOMEM;
+        goto out;
+    }
+
+    if(vtpm->devid =3D=3D -1) {
+        if (!(dompath =3D libxl__xs_get_dompath(gc, domid))) {
+            rc =3D ERROR_FAIL;
+            goto out_free;
+        }
+        l =3D libxl__xs_directory(gc, XBT_NULL, libxl__sprintf(gc, "%s/d=
evice/vtpm", dompath), &nb);
+        if(l =3D=3D NULL || nb =3D=3D 0) {
+            vtpm->devid =3D 0;
+        } else {
+            vtpm->devid =3D strtoul(l[nb - 1], NULL, 10) + 1;
+        }
+    }
+
+    GCNEW(device);
+    rc =3D libxl__device_from_vtpm(gc, domid, vtpm, device);
+    if ( rc !=3D 0 ) goto out_free;
+
+    flexarray_append(back, "frontend-id");
+    flexarray_append(back, libxl__sprintf(gc, "%d", domid));
+    flexarray_append(back, "online");
+    flexarray_append(back, "1");
+    flexarray_append(back, "state");
+    flexarray_append(back, libxl__sprintf(gc, "%d", 1));
+
+    flexarray_append(back, "uuid");
+    flexarray_append(back, libxl__sprintf(gc, LIBXL_UUID_FMT, LIBXL_UUID=
_BYTES(vtpm->uuid)));
+    flexarray_append(back, "instance"); /* MAYBE CAN GET RID OF THIS */
+    flexarray_append(back, "0");
+    flexarray_append(back, "pref_instance"); /* MAYBE CAN GET RID OF THI=
S */
+    flexarray_append(back, "0");
+    flexarray_append(back, "resume");
+    flexarray_append(back, "False");
+    flexarray_append(back, "ready"); /* MAYBE CAN GET RID OF THIS */
+    flexarray_append(back, "1");
+
+    flexarray_append(front, "backend-id");
+    flexarray_append(front, libxl__sprintf(gc, "%d", vtpm->backend_domid=
));
+    flexarray_append(front, "state");
+    flexarray_append(front, libxl__sprintf(gc, "%d", 1));
+    flexarray_append(front, "handle");
+    flexarray_append(front, libxl__sprintf(gc, "%d", vtpm->devid));
+
+    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));
+
+    aodev->dev =3D device;
+    aodev->action =3D DEVICE_CONNECT;
+    libxl__wait_device_connection(egc, aodev);
+
+    rc =3D 0;
+out_free:
+    flexarray_free(back);
+    flexarray_free(front);
+out:
+    aodev->rc =3D rc;
+    if(rc) aodev->callback(egc, aodev);
+    return;
+}
+
+static void libxl__device_vtpm_from_xs_fe(libxl__gc *gc,
+                                          const char* fe_path,
+                                          libxl_device_vtpm *vtpm)
+{
+   char* tmp;
+
+   memset(vtpm, 0, sizeof(*vtpm));
+   tmp =3D libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/handle", =
fe_path));
+   if (tmp) {
+      vtpm->devid =3D atoi(tmp);
+   }
+   tmp =3D libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/backend-i=
d", fe_path));
+   if(tmp) {
+      vtpm->backend_domid =3D atoi(tmp);
+   }
+   tmp =3D libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/uuid", fe=
_path));
+   if(tmp) {
+      libxl_uuid_from_string(&(vtpm->uuid), tmp);
+   }
+}
+
+libxl_device_vtpm *libxl_device_vtpm_list(libxl_ctx *ctx, uint32_t domid=
, int *num)
+{
+    GC_INIT(ctx);
+
+    libxl_device_vtpm* vtpms =3D NULL;
+    char* fe_path =3D NULL;
+    char** dir =3D NULL;
+    unsigned int ndirs =3D 0;
+
+    *num =3D 0;
+
+    fe_path =3D libxl__sprintf(gc, "%s/device/vtpm", libxl__xs_get_dompa=
th(gc, domid));
+    dir =3D libxl__xs_directory(gc, XBT_NULL, fe_path, &ndirs);
+    if(dir) {
+       vtpms =3D malloc(sizeof(*vtpms) * ndirs);
+       libxl_device_vtpm* vtpm;
+       libxl_device_vtpm* end =3D vtpms + ndirs;
+       for(vtpm =3D vtpms; vtpm < end; ++vtpm, ++dir) {
+          const char* path =3D libxl__sprintf(gc, "%s/%s", fe_path, *dir=
);
+          libxl__device_vtpm_from_xs_fe(gc, path, vtpm);
+       }
+    }
+    *num =3D ndirs;
+
+    GC_FREE;
+    return vtpms;
+}
+
+int libxl_device_vtpm_getinfo(libxl_ctx *ctx, uint32_t domid,
+                               libxl_device_vtpm *vtpm, libxl_vtpminfo *=
vtpminfo)
+{
+    GC_INIT(ctx);
+    char *dompath, *vtpmpath;
+    char *val;
+    int rc =3D 0;
+
+    libxl_vtpminfo_init(vtpminfo);
+    dompath =3D libxl__xs_get_dompath(gc, domid);
+    vtpminfo->devid =3D vtpm->devid;
+
+    vtpmpath =3D libxl__sprintf(gc, "%s/device/vtpm/%d", dompath, vtpmin=
fo->devid);
+    vtpminfo->backend =3D xs_read(ctx->xsh, XBT_NULL,
+                                libxl__sprintf(gc, "%s/backend", vtpmpat=
h), NULL);
+    if (!vtpminfo->backend) {
+        goto err;
+    }
+    if(!libxl__xs_read(gc, XBT_NULL, vtpminfo->backend)) {
+       goto err;
+    }
+
+    val =3D libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/backend-=
id", vtpmpath));
+    vtpminfo->backend_id =3D val ? strtoul(val, NULL, 10) : -1;
+    val =3D libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/state", =
vtpmpath));
+    vtpminfo->state =3D val ? strtoul(val, NULL, 10) : -1;
+    val =3D libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/event-ch=
annel", vtpmpath));
+    vtpminfo->evtch =3D val ? strtoul(val, NULL, 10) : -1;
+    val =3D libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/ring-ref=
", vtpmpath));
+    vtpminfo->rref =3D val ? strtoul(val, NULL, 10) : -1;
+    vtpminfo->frontend =3D xs_read(ctx->xsh, XBT_NULL,
+                                 libxl__sprintf(gc, "%s/frontend", vtpmi=
nfo->backend), NULL);
+    val =3D libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/frontend=
-id", vtpminfo->backend));
+    vtpminfo->frontend_id =3D val ? strtoul(val, NULL, 10) : -1;
+
+    val =3D libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/uuid", v=
tpminfo->backend));
+    if(val =3D=3D NULL) {
+       LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "%s/uuid does not exist!\n", vt=
pminfo->backend);
+       goto err;
+    }
+    if(libxl_uuid_from_string(&(vtpminfo->uuid), val)) {
+       LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "%s/uuid is a malformed uuid?? =
(%s) Probably a bug!\n", vtpminfo->backend, val);
+       goto err;
+    }
+
+    goto exit;
+err:
+    rc =3D ERROR_FAIL;
+exit:
+    GC_FREE;
+    return rc;
+}
+
+int libxl_devid_to_device_vtpm(libxl_ctx *ctx, uint32_t domid,
+                              int devid, libxl_device_vtpm *vtpm)
+{
+    libxl_device_vtpm *vtpms;
+    int nb, i;
+    int rc;
+
+    vtpms =3D libxl_device_vtpm_list(ctx, domid, &nb);
+    if (!vtpms)
+        return ERROR_FAIL;
+
+    memset(vtpm, 0, sizeof (libxl_device_vtpm));
+    rc =3D 1;
+    for (i =3D 0; i < nb; ++i) {
+        if(devid =3D=3D vtpms[i].devid) {
+            vtpm->backend_domid =3D vtpms[i].backend_domid;
+            vtpm->devid =3D vtpms[i].devid;
+            libxl_uuid_copy(&vtpm->uuid, &vtpms[i].uuid);
+            rc =3D 0;
+            break;
+        }
+    }
+
+    for (i=3D0; i<nb; i++)
+        libxl_device_vtpm_dispose(&vtpms[i]);
+    free(vtpms);
+    return rc;
+}
+
+
+/***********************************************************************=
*******/
=20
 int libxl__device_disk_setdefault(libxl__gc *gc, libxl_device_disk *disk=
)
 {
@@ -3174,6 +3414,10 @@ DEFINE_DEVICE_REMOVE(vkb, destroy, 1)
 DEFINE_DEVICE_REMOVE(vfb, remove, 0)
 DEFINE_DEVICE_REMOVE(vfb, destroy, 1)
=20
+/* vtpm */
+DEFINE_DEVICE_REMOVE(vtpm, remove, 0)
+DEFINE_DEVICE_REMOVE(vtpm, destroy, 1)
+
 #undef DEFINE_DEVICE_REMOVE
=20
 /***********************************************************************=
*******/
@@ -3208,6 +3452,9 @@ DEFINE_DEVICE_ADD(disk)
 /* nic */
 DEFINE_DEVICE_ADD(nic)
=20
+/* vtpm */
+DEFINE_DEVICE_ADD(vtpm)
+
 #undef DEFINE_DEVICE_ADD
=20
 /***********************************************************************=
*******/
diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -478,13 +478,14 @@ typedef struct {
     libxl_domain_create_info c_info;
     libxl_domain_build_info b_info;
=20
-    int num_disks, num_nics, num_pcidevs, num_vfbs, num_vkbs;
+    int num_disks, num_nics, num_pcidevs, num_vfbs, num_vkbs, num_vtpms;=

=20
     libxl_device_disk *disks;
     libxl_device_nic *nics;
     libxl_device_pci *pcidevs;
     libxl_device_vfb *vfbs;
     libxl_device_vkb *vkbs;
+    libxl_device_vtpm *vtpms;
=20
     libxl_action_on_shutdown on_poweroff;
     libxl_action_on_shutdown on_reboot;
@@ -745,6 +746,23 @@ libxl_device_nic *libxl_device_nic_list(libxl_ctx *c=
tx, uint32_t domid, int *num
 int libxl_device_nic_getinfo(libxl_ctx *ctx, uint32_t domid,
                               libxl_device_nic *nic, libxl_nicinfo *nici=
nfo);
=20
+/* Virtual TPMs */
+int libxl_device_vtpm_add(libxl_ctx *ctx, uint32_t domid, libxl_device_v=
tpm *vtpm,
+                          const libxl_asyncop_how *ao_how)
+                          LIBXL_EXTERNAL_CALLERS_ONLY;
+int libxl_device_vtpm_remove(libxl_ctx *ctx, uint32_t domid,
+                            libxl_device_vtpm *vtpm,
+                            const libxl_asyncop_how *ao_how)
+                            LIBXL_EXTERNAL_CALLERS_ONLY;
+int libxl_device_vtpm_destroy(libxl_ctx *ctx, uint32_t domid,
+                              libxl_device_vtpm *vtpm,
+                              const libxl_asyncop_how *ao_how)
+                              LIBXL_EXTERNAL_CALLERS_ONLY;
+
+libxl_device_vtpm *libxl_device_vtpm_list(libxl_ctx *ctx, uint32_t domid=
, int *num);
+int libxl_device_vtpm_getinfo(libxl_ctx *ctx, uint32_t domid,
+                               libxl_device_vtpm *vtpm, libxl_vtpminfo *=
vtpminfo);
+
 /* Keyboard */
 int libxl_device_vkb_add(libxl_ctx *ctx, uint32_t domid, libxl_device_vk=
b *vkb,
                          const libxl_asyncop_how *ao_how)
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
@@ -55,6 +55,10 @@ void libxl_domain_config_dispose(libxl_domain_config *=
d_config)
         libxl_device_vkb_dispose(&d_config->vkbs[i]);
     free(d_config->vkbs);
=20
+    for (i=3D0; i<d_config->num_vtpms; i++)
+       libxl_device_vtpm_dispose(&d_config->vtpms[i]);
+    free(d_config->vtpms);
+
     libxl_domain_create_info_dispose(&d_config->c_info);
     libxl_domain_build_info_dispose(&d_config->b_info);
 }
@@ -601,6 +605,8 @@ static void domcreate_bootloader_done(libxl__egc *egc=
,
 static void domcreate_launch_dm(libxl__egc *egc, libxl__multidev *aodevs=
,
                                 int ret);
=20
+static void domcreate_attach_vtpms(libxl__egc *egc, libxl__multidev *mul=
tidev,
+                                   int ret);
 static void domcreate_attach_pci(libxl__egc *egc, libxl__multidev *aodev=
s,
                                  int ret);
=20
@@ -1084,13 +1090,13 @@ static void domcreate_devmodel_started(libxl__egc=
 *egc,
     if (d_config->num_nics > 0) {
         /* Attach nics */
         libxl__multidev_begin(ao, &dcs->multidev);
-        dcs->multidev.callback =3D domcreate_attach_pci;
+        dcs->multidev.callback =3D domcreate_attach_vtpms;
         libxl__add_nics(egc, ao, domid, d_config, &dcs->multidev);
         libxl__multidev_prepared(egc, &dcs->multidev, 0);
         return;
     }
=20
-    domcreate_attach_pci(egc, &dcs->multidev, 0);
+    domcreate_attach_vtpms(egc, &dcs->multidev, 0);
     return;
=20
 error_out:
@@ -1098,6 +1104,36 @@ error_out:
     domcreate_complete(egc, dcs, ret);
 }
=20
+static void domcreate_attach_vtpms(libxl__egc *egc, libxl__multidev *mul=
tidev, int ret) {
+   libxl__domain_create_state *dcs =3D CONTAINER_OF(multidev, *dcs, mult=
idev);
+   STATE_AO_GC(dcs->ao);
+   int domid =3D dcs->guest_domid;
+
+   libxl_domain_config* const d_config =3D dcs->guest_config;
+
+   if(ret) {
+      LOG(ERROR, "unable to add nic devices");
+      goto error_out;
+   }
+
+    /* Plug vtpm devices */
+    if (d_config->num_vtpms > 0) {
+        /* Attach vtpms */
+        libxl__multidev_begin(ao, &dcs->multidev);
+        dcs->multidev.callback =3D domcreate_attach_pci;
+        libxl__add_vtpms(egc, ao, domid, d_config, &dcs->multidev);
+        libxl__multidev_prepared(egc, &dcs->multidev, 0);
+        return;
+    }
+
+   domcreate_attach_pci(egc, multidev, 0);
+   return;
+
+error_out:
+   assert(ret);
+   domcreate_complete(egc, dcs, ret);
+}
+
 static void domcreate_attach_pci(libxl__egc *egc, libxl__multidev *multi=
dev,
                                  int ret)
 {
@@ -1111,7 +1147,7 @@ static void domcreate_attach_pci(libxl__egc *egc, l=
ibxl__multidev *multidev,
     libxl_domain_config *const d_config =3D dcs->guest_config;
=20
     if (ret) {
-        LOG(ERROR, "unable to add nic devices");
+        LOG(ERROR, "unable to add vtpm devices");
         goto error_out;
     }
=20
diff --git a/tools/libxl/libxl_device.c b/tools/libxl/libxl_device.c
--- a/tools/libxl/libxl_device.c
+++ b/tools/libxl/libxl_device.c
@@ -515,6 +515,7 @@ void libxl__multidev_prepared(libxl__egc *egc,
=20
 DEFINE_DEVICES_ADD(disk)
 DEFINE_DEVICES_ADD(nic)
+DEFINE_DEVICES_ADD(vtpm)
=20
 #undef DEFINE_DEVICES_ADD
=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
@@ -954,6 +954,7 @@ _hidden int libxl__device_disk_setdefault(libxl__gc *=
gc,
                                           libxl_device_disk *disk);
 _hidden int libxl__device_nic_setdefault(libxl__gc *gc, libxl_device_nic=
 *nic,
                                          uint32_t domid);
+_hidden int libxl__device_vtpm_setdefault(libxl__gc *gc, libxl_device_vt=
pm *vtpm);
 _hidden int libxl__device_vfb_setdefault(libxl__gc *gc, libxl_device_vfb=
 *vfb);
 _hidden int libxl__device_vkb_setdefault(libxl__gc *gc, libxl_device_vkb=
 *vkb);
 _hidden int libxl__device_pci_setdefault(libxl__gc *gc, libxl_device_pci=
 *pci);
@@ -1975,6 +1976,10 @@ _hidden void libxl__device_nic_add(libxl__egc *egc=
, uint32_t domid,
                                    libxl_device_nic *nic,
                                    libxl__ao_device *aodev);
=20
+_hidden void libxl__device_vtpm_add(libxl__egc *egc, uint32_t domid,
+                                   libxl_device_vtpm *vtpm,
+                                   libxl__ao_device *aodev);
+
 /* Internal function to connect a vkb device */
 _hidden int libxl__device_vkb_add(libxl__gc *gc, uint32_t domid,
                                   libxl_device_vkb *vkb);
@@ -2407,6 +2412,10 @@ _hidden void libxl__add_nics(libxl__egc *egc, libx=
l__ao *ao, uint32_t domid,
                              libxl_domain_config *d_config,
                              libxl__multidev *multidev);
=20
+_hidden void libxl__add_vtpms(libxl__egc *egc, libxl__ao *ao, uint32_t d=
omid,
+                             libxl_domain_config *d_config,
+                             libxl__multidev *multidev);
+
 /*----- device model creation -----*/
=20
 /* First layer; wraps libxl__spawn_spawn. */
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
@@ -395,6 +395,12 @@ libxl_device_pci =3D Struct("device_pci", [
     ("permissive", bool),
     ])
=20
+libxl_device_vtpm =3D Struct("device_vtpm", [
+    ("backend_domid",    libxl_domid),
+    ("devid",            libxl_devid),
+    ("uuid",             libxl_uuid),
+])
+
 libxl_diskinfo =3D Struct("diskinfo", [
     ("backend", string),
     ("backend_id", uint32),
@@ -418,6 +424,18 @@ libxl_nicinfo =3D Struct("nicinfo", [
     ("rref_rx", integer),
     ], dir=3DDIR_OUT)
=20
+libxl_vtpminfo =3D Struct("vtpminfo", [
+    ("backend", string),
+    ("backend_id", uint32),
+    ("frontend", string),
+    ("frontend_id", uint32),
+    ("devid", libxl_devid),
+    ("state", integer),
+    ("evtch", integer),
+    ("rref", integer),
+    ("uuid", libxl_uuid),
+    ], dir=3DDIR_OUT)
+
 libxl_vcpuinfo =3D Struct("vcpuinfo", [
     ("vcpuid", uint32),
     ("cpu", uint32),
diff --git a/tools/libxl/libxl_types_internal.idl b/tools/libxl/libxl_typ=
es_internal.idl
--- a/tools/libxl/libxl_types_internal.idl
+++ b/tools/libxl/libxl_types_internal.idl
@@ -19,6 +19,7 @@ libxl__device_kind =3D Enumeration("device_kind", [
     (5, "VFB"),
     (6, "VKBD"),
     (7, "CONSOLE"),
+    (8, "VTPM"),
     ])
=20
 libxl__console_backend =3D Enumeration("console_backend", [
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
@@ -463,6 +463,35 @@ int libxl_pipe(libxl_ctx *ctx, int pipes[2])
     return 0;
 }
=20
+int libxl_uuid_to_device_vtpm(libxl_ctx *ctx, uint32_t domid,
+                            libxl_uuid* uuid, libxl_device_vtpm *vtpm)
+{
+    libxl_device_vtpm *vtpms;
+    int nb, i;
+    int rc;
+
+    vtpms =3D libxl_device_vtpm_list(ctx, domid, &nb);
+    if (!vtpms)
+        return ERROR_FAIL;
+
+    memset(vtpm, 0, sizeof (libxl_device_vtpm));
+    rc =3D 1;
+    for (i =3D 0; i < nb; ++i) {
+        if(!libxl_uuid_compare(uuid, &vtpms[i].uuid)) {
+            vtpm->backend_domid =3D vtpms[i].backend_domid;
+            vtpm->devid =3D vtpms[i].devid;
+            libxl_uuid_copy(&vtpm->uuid, &vtpms[i].uuid);
+            rc =3D 0;
+            break;
+        }
+    }
+
+    for (i=3D0; i<nb; i++)
+        libxl_device_vtpm_dispose(&vtpms[i]);
+    free(vtpms);
+    return rc;
+}
+
 int libxl_mac_to_device_nic(libxl_ctx *ctx, uint32_t domid,
                             const char *mac, libxl_device_nic *nic)
 {
diff --git a/tools/libxl/libxl_utils.h b/tools/libxl/libxl_utils.h
--- a/tools/libxl/libxl_utils.h
+++ b/tools/libxl/libxl_utils.h
@@ -64,6 +64,11 @@ int libxl_devid_to_device_nic(libxl_ctx *ctx, uint32_t=
 domid, int devid,
 int libxl_vdev_to_device_disk(libxl_ctx *ctx, uint32_t domid, const char=
 *vdev,
                                libxl_device_disk *disk);
=20
+int libxl_uuid_to_device_vtpm(libxl_ctx *ctx, uint32_t domid,
+                               libxl_uuid *uuid, libxl_device_vtpm *vtpm=
);
+int libxl_devid_to_device_vtpm(libxl_ctx *ctx, uint32_t domid,
+                               int devid, libxl_device_vtpm *vtpm);
+
 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. */
diff --git a/tools/libxl/xl.h b/tools/libxl/xl.h
--- a/tools/libxl/xl.h
+++ b/tools/libxl/xl.h
@@ -79,6 +79,9 @@ int main_networkdetach(int argc, char **argv);
 int main_blockattach(int argc, char **argv);
 int main_blocklist(int argc, char **argv);
 int main_blockdetach(int argc, char **argv);
+int main_vtpmattach(int argc, char **argv);
+int main_vtpmlist(int argc, char **argv);
+int main_vtpmdetach(int argc, char **argv);
 int main_uptime(int argc, char **argv);
 int main_tmem_list(int argc, char **argv);
 int main_tmem_freeze(int argc, char **argv);
diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -573,7 +573,7 @@ static void parse_config_data(const char *config_sour=
ce,
     const char *buf;
     long l;
     XLU_Config *config;
-    XLU_ConfigList *cpus, *vbds, *nics, *pcis, *cvfbs, *cpuids;
+    XLU_ConfigList *cpus, *vbds, *nics, *pcis, *cvfbs, *cpuids, *vtpms;
     XLU_ConfigList *ioports, *irqs, *iomem;
     int num_ioports, num_irqs, num_iomem;
     int pci_power_mgmt =3D 0;
@@ -1045,6 +1045,47 @@ static void parse_config_data(const char *config_s=
ource,
         }
     }
=20
+    if (!xlu_cfg_get_list(config, "vtpm", &vtpms, 0, 0)) {
+        d_config->num_vtpms =3D 0;
+        d_config->vtpms =3D NULL;
+        while ((buf =3D xlu_cfg_get_listitem (vtpms, d_config->num_vtpms=
)) !=3D NULL) {
+            libxl_device_vtpm *vtpm;
+            char * buf2 =3D strdup(buf);
+            char *p, *p2;
+
+            d_config->vtpms =3D (libxl_device_vtpm *) realloc(d_config->=
vtpms, sizeof(libxl_device_vtpm) * (d_config->num_vtpms+1));
+            vtpm =3D d_config->vtpms + d_config->num_vtpms;
+            libxl_device_vtpm_init(vtpm);
+            vtpm->devid =3D d_config->num_vtpms;
+
+            p =3D strtok(buf2, ",");
+            if (!p)
+                goto skip_vtpm;
+            do {
+                while(*p =3D=3D ' ')
+                    ++p;
+                if ((p2 =3D strchr(p, '=3D')) =3D=3D NULL)
+                    break;
+                *p2 =3D '\0';
+                if (!strcmp(p, "backend")) {
+                    if(domain_qualifier_to_domid(p2 + 1, &(vtpm->backend=
_domid), 0))
+                    {
+                        fprintf(stderr, "Specified backend domain does n=
ot exist, defaulting to Dom0\n");
+                        vtpm->backend_domid =3D 0;
+                    }
+                } else if(!strcmp(p, "uuid")) {
+                    if( libxl_uuid_from_string(&vtpm->uuid, p2 + 1) ) {
+                        fprintf(stderr, "Failed to parse vtpm UUID: %s\n=
", p2 + 1);
+                        exit(1);
+                    }
+                }
+            } while ((p =3D strtok(NULL, ",")) !=3D NULL);
+skip_vtpm:
+            free(buf2);
+            d_config->num_vtpms++;
+        }
+    }
+
     if (!xlu_cfg_get_list (config, "vif", &nics, 0, 0)) {
         d_config->num_nics =3D 0;
         d_config->nics =3D NULL;
@@ -1070,7 +1111,7 @@ static void parse_config_data(const char *config_so=
urce,
=20
             p =3D strtok(buf2, ",");
             if (!p)
-                goto skip;
+                goto skip_nic;
             do {
                 while (*p =3D=3D ' ')
                     p++;
@@ -1134,7 +1175,7 @@ static void parse_config_data(const char *config_so=
urce,
                     fprintf(stderr, "the accel parameter for vifs is cur=
rently not supported\n");
                 }
             } while ((p =3D strtok(NULL, ",")) !=3D NULL);
-skip:
+skip_nic:
             free(buf2);
             d_config->num_nics++;
         }
@@ -5570,6 +5611,131 @@ int main_blockdetach(int argc, char **argv)
     return rc;
 }
=20
+int main_vtpmattach(int argc, char **argv)
+{
+    int opt;
+    libxl_device_vtpm vtpm;
+    char *oparg;
+    unsigned int val;
+    uint32_t domid;
+
+    if ((opt =3D def_getopt(argc, argv, "", "vtpm-attach", 1)) !=3D -1)
+        return opt;
+
+    if (domain_qualifier_to_domid(argv[optind], &domid, 0) < 0) {
+        fprintf(stderr, "%s is an invalid domain identifier\n", argv[opt=
ind]);
+        return 1;
+    }
+    ++optind;
+
+    libxl_device_vtpm_init(&vtpm);
+    for (argv +=3D optind, argc -=3D optind; argc > 0; ++argv, --argc) {=

+        if (MATCH_OPTION("uuid", *argv, oparg)) {
+            if(libxl_uuid_from_string(&(vtpm.uuid), oparg)) {
+                fprintf(stderr, "Invalid uuid specified (%s)\n", oparg);=

+                return 1;
+            }
+        } else if (MATCH_OPTION("backend", *argv, oparg)) {
+            if(domain_qualifier_to_domid(oparg, &val, 0)) {
+                fprintf(stderr, "Specified backend domain does not exist=
, defaulting to Dom0\n");
+                val =3D 0;
+            }
+            vtpm.backend_domid =3D val;
+        } else {
+            fprintf(stderr, "unrecognized argument `%s'\n", *argv);
+            return 1;
+        }
+    }
+
+    if(dryrun_only) {
+       char* json =3D libxl_device_vtpm_to_json(ctx, &vtpm);
+       printf("vtpm: %s\n", json);
+       free(json);
+       libxl_device_vtpm_dispose(&vtpm);
+       if (ferror(stdout) || fflush(stdout)) { perror("stdout"); exit(-1=
); }
+       return 0;
+    }
+
+    if (libxl_device_vtpm_add(ctx, domid, &vtpm, 0)) {
+        fprintf(stderr, "libxl_device_vtpm_add failed.\n");
+        return 1;
+    }
+    libxl_device_vtpm_dispose(&vtpm);
+    return 0;
+}
+
+int main_vtpmlist(int argc, char **argv)
+{
+    int opt;
+    libxl_device_vtpm *vtpms;
+    libxl_vtpminfo vtpminfo;
+    int nb, i;
+
+    if ((opt =3D def_getopt(argc, argv, "", "vtpm-list", 1)) !=3D -1)
+        return opt;
+
+    /*      Idx  BE   UUID   Hdl  Sta  evch rref  BE-path */
+    printf("%-3s %-2s %-36s %-6s %-5s %-6s %-5s %-10s\n",
+           "Idx", "BE", "Uuid", "handle", "state", "evt-ch", "ring-ref",=
 "BE-path");
+    for (argv +=3D optind, argc -=3D optind; argc > 0; --argc, ++argv) {=

+        uint32_t domid;
+        if (domain_qualifier_to_domid(*argv, &domid, 0) < 0) {
+            fprintf(stderr, "%s is an invalid domain identifier\n", *arg=
v);
+            continue;
+        }
+        if (!(vtpms =3D libxl_device_vtpm_list(ctx, domid, &nb))) {
+            continue;
+        }
+        for (i =3D 0; i < nb; ++i) {
+           if(!libxl_device_vtpm_getinfo(ctx, domid, &vtpms[i], &vtpminf=
o)) {
+              /*      Idx  BE     UUID             Hdl Sta evch rref BE-=
path*/
+              printf("%-3d %-2d " LIBXL_UUID_FMT " %6d %5d %6d %8d %-30s=
\n",
+                    vtpminfo.devid, vtpminfo.backend_id,
+                    LIBXL_UUID_BYTES(vtpminfo.uuid),
+                    vtpminfo.devid, vtpminfo.state, vtpminfo.evtch,
+                    vtpminfo.rref, vtpminfo.backend);
+
+              libxl_vtpminfo_dispose(&vtpminfo);
+           }
+           libxl_device_vtpm_dispose(&vtpms[i]);
+        }
+        free(vtpms);
+    }
+    return 0;
+}
+
+int main_vtpmdetach(int argc, char **argv)
+{
+    uint32_t domid;
+    int opt, rc=3D0;
+    libxl_device_vtpm vtpm;
+    libxl_uuid uuid;
+
+    if ((opt =3D def_getopt(argc, argv, "", "vtpm-detach", 2)) !=3D -1)
+        return opt;
+
+    domid =3D find_domain(argv[optind]);
+
+    if ( libxl_uuid_from_string(&uuid, argv[optind+1])) {
+        if (libxl_devid_to_device_vtpm(ctx, domid, atoi(argv[optind+1]),=
 &vtpm)) {
+            fprintf(stderr, "Unknown device %s.\n", argv[optind+1]);
+            return 1;
+        }
+    } else {
+        if (libxl_uuid_to_device_vtpm(ctx, domid, &uuid, &vtpm)) {
+            fprintf(stderr, "Unknown device %s.\n", argv[optind+1]);
+            return 1;
+        }
+    }
+    rc =3D libxl_device_vtpm_remove(ctx, domid, &vtpm, 0);
+    if (rc) {
+        fprintf(stderr, "libxl_device_vtpm_remove failed.\n");
+    }
+    libxl_device_vtpm_dispose(&vtpm);
+    return rc;
+}
+
+
 static char *uptime_to_string(unsigned long uptime, int short_mode)
 {
     int sec, min, hour, day;
diff --git a/tools/libxl/xl_cmdtable.c b/tools/libxl/xl_cmdtable.c
--- a/tools/libxl/xl_cmdtable.c
+++ b/tools/libxl/xl_cmdtable.c
@@ -338,6 +338,21 @@ struct cmd_spec cmd_table[] =3D {
       "Destroy a domain's virtual block device",
       "<Domain> <DevId>",
     },
+    { "vtpm-attach",
+      &main_vtpmattach, 0, 1,
+      "Create a new virtual TPM device",
+      "<Domain> [uuid=3D<uuid>] [backend=3D<BackDomain>]",
+    },
+    { "vtpm-list",
+      &main_vtpmlist, 0, 0,
+      "List virtual TPM devices for a domain",
+      "<Domain(s)>",
+    },
+    { "vtpm-detach",
+      &main_vtpmdetach, 0, 1,
+      "Destroy a domain's virtual TPM device",
+      "<Domain> <DevId|uuid>",
+    },
     { "uptime",
       &main_uptime, 0, 0,
       "Print uptime for all/some domains",





--------------ms020408040900080808080009
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIDyjCC
A8YwggMvoAMCAQICBD/xyf0wDQYJKoZIhvcNAQEFBQAwLzELMAkGA1UEBhMCVVMxDzANBgNV
BAoTBkpIVUFQTDEPMA0GA1UECxMGQklTRENBMB4XDTEwMDYxMTE4MjIwNloXDTEzMDYxMTE4
NTIwNlowZjELMAkGA1UEBhMCVVMxDzANBgNVBAoTBkpIVUFQTDEPMA0GA1UECxMGUGVvcGxl
MTUwFgYDVQQLEw9WUE5Hcm91cC1CSVNEQ0EwGwYDVQQDExRNYXR0aGV3IEUgRmlvcmF2YW50
ZTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAnpbwVSP6o1Nb5lcW7dd3yTo9iBJdi7qz
4nANOMFPK7JOy5npKN1iiousl28U/scUJES55gPwAWYJK3uVyQAsA4adgDKi5DoD1UHDQEwp
bY7iHLJeq0NPr4BqYNqnCFPbE6HC8zSJrr4qKn+gVUQT39SIFqdiIPJwZL8FYTRQ/zsCAwEA
AaOCAbYwggGyMAsGA1UdDwQEAwIHgDArBgNVHRAEJDAigA8yMDEwMDYxMTE4MjIwNlqBDzIw
MTIwNzE3MjI1MjA2WjAbBg0rBgEEAbMlCwMBAQEBBAoWCGZpb3JhbWUxMBsGDSsGAQQBsyUL
AwEBAQIEChIIMDAxMDQyNjEwWAYJYIZIAYb6ax4BBEsMSVRoZSBwcml2YXRlIGtleSBjb3Jy
ZXNwb25kaW5nIHRvIHRoaXMgY2VydGlmaWNhdGUgbWF5IGhhdmUgYmVlbiBleHBvcnRlZC4w
KAYDVR0RBCEwH4EdTWF0dGhldy5GaW9yYXZhbnRlQGpodWFwbC5lZHUwUgYDVR0fBEswSTBH
oEWgQ6RBMD8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJU0RD
QTEOMAwGA1UEAxMFQ1JMNTYwHwYDVR0jBBgwFoAUCDUpmxH52EU2CyWmF2EJMB1yqeswHQYD
VR0OBBYEFO6LYxg6r9wHZ+zdQtBHn1dZ/YTNMAkGA1UdEwQCMAAwGQYJKoZIhvZ9B0EABAww
ChsEVjcuMQMCBLAwDQYJKoZIhvcNAQEFBQADgYEAJO9HQh4YNChVLzuZqK5ARJARD8JoujGZ
fdo75quvg2jXFQe2sEjvLnxJZgm/pv8fdZakq48CWwjYHKuvIp7sDjTEsQfo+y7SpN/N2NvJ
WU5SqfK1VgYtNLRRoGJUB5Q1aZ+Dg95g3kqpyfpUMISJL8IKVLtJVfN4fggFVUYZ9wwxggGr
MIIBpwIBATA3MC8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJ
U0RDQQIEP/HJ/TAJBgUrDgMCGgUAoIHLMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ
KoZIhvcNAQkFMQ8XDTEyMDkyNTE2MTE1NVowIwYJKoZIhvcNAQkEMRYEFEITSUQL2rhd8Cjb
W8dPpxpMLqLTMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAK
BggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI
KoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEgYBqvpq5U7WCOF0P30eDi89MNSj1tUxQvW1B
bVSKk26zlDNj3ADh7YdBISYtec3neLyXK3v6DcEuQozlZ3P1sc7QUPf58OEQN5znsWdTRyiW
4XJlM6u+CMMQ/SwjOF5M3/YpDUK6JrQoteHRi7QyzPmi5VmnrMq5Sk9dEKfXcSd02wAAAAAA
AA==
--------------ms020408040900080808080009--


--===============1254954324962400588==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============1254954324962400588==--


From xen-devel-bounces@lists.xen.org Tue Sep 25 16:14:39 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 16:14:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGXmD-0001jW-Gg; Tue, 25 Sep 2012 16:14:25 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1TGXmB-0001jP-S8
	for xen-devel@lists.xensource.com; Tue, 25 Sep 2012 16:14:24 +0000
Received: from [85.158.137.99:24999] by server-12.bemta-3.messagelabs.com id
	94/BE-10384-E58D1605; Tue, 25 Sep 2012 16:14:22 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-217.messagelabs.com!1348589662!18972033!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTEwNzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29737 invoked from network); 25 Sep 2012 16:14:22 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Sep 2012 16:14:22 -0000
X-IronPort-AV: E=Sophos;i="4.80,484,1344211200"; d="scan'208";a="14756017"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Sep 2012 16:14: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.279.1;
	Tue, 25 Sep 2012 17:14:22 +0100
Message-ID: <1348589660.12592.19.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
Date: Tue, 25 Sep 2012 17:14:20 +0100
In-Reply-To: <5061D52B.9080503@jhuapl.edu>
References: <505CBDFD.5070408@jhuapl.edu>
	<1348569397.3452.180.camel@zakaz.uk.xensource.com>
	<5061D52B.9080503@jhuapl.edu>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH xm/xl enhancements for vptm 5/6] make devid
	a libxl 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 Tue, 2012-09-25 at 17:00 +0100, Matthew Fioravante wrote:
> On 09/25/2012 06:36 AM, Ian Campbell wrote:
> > On Fri, 2012-09-21 at 20:20 +0100, Matthew Fioravante wrote:
> >> This fixes a bug in libxl where device ids are not initialized properly.
> >> The devid field for each device is set to be an integer type which are
> >> always initialized to 0.
> >>
> >> This makes the xl DEV-attach commands always fail to add more than one
> >> device, because each time the device id is initialized to 0, when it
> >> should be initialized to -1, which in the code will trigger a search for
> >> free id.
> > Which of the DEV-attach commands can be used to add more than one
> > device?
> network-attach, block-attach, and also my vtpm-attach.

Oh, you mean by being called repeatedly, not adding multiple devices in
one go!

> > Where is the code to do the search? I had a look in the disk and network
> > cases and couldn't find it.
> libxl.c
> 
> void libxl__device_nic_add(
> 
>     if (nic->devid == -1) {
>         if (!(dompath = libxl__xs_get_dompath(gc, domid))) {
>             rc = ERROR_FAIL;
>             goto out_free;
>         }
>         if (!(l = libxl__xs_directory(gc, XBT_NULL,
>                                      libxl__sprintf(gc, "%s/device/vif",
> dompath), &nb))) {
>             nic->devid = 0;
>         } else {
>             nic->devid = strtoul(l[nb - 1], NULL, 10) + 1;
>         }
>     }

Not sure how I missed this.

> Right now, nic-devid is 0 on attach.

Is devid not a parameter to network-attach? It is to block-attach.

> So it always tries to use 0. When you do a network-attach twice,
> the second time it trys and fails to create device/vif/0

Your change to use -1 as thye default is certainly correct. I'm just
trying to figure out why xl does things this way in the first place.

> 
> >
> >> diff --git a/tools/ocaml/libs/xs/xs.mli b/tools/ocaml/libs/xs/xs.mli
> >> --- a/tools/ocaml/libs/xs/xs.mli
> >> +++ b/tools/ocaml/libs/xs/xs.mli
> >> @@ -27,6 +27,7 @@ exception Failed_to_connect
> >>  type perms = Xsraw.perms
> >>  
> >>  type domid = int
> >> +type devid = int
> > I can see why these were needed in the xl modules, but I don't see how
> > this type can be required in the xenstore ones.
> It shouldn't be required for xenstore or xc. The problem is they won't
> compile without it because of the way the ocaml build system works. As
> far as I understand it creates types for xl, xc, and xs from the
> libxl_types.idl.

No, only xl does this.

The others are the libxc and xenstore bindings which are completely hand
coded and there is no concept of a devid at those layers anyway. What
error do you get if you omit the changes to those module?

>  Either the build system needs to be changed, or devid
> needs to be a type in all libraries, or we find some other way to fix
> this initialization bug.
> >
> > Ian.
> >
> 
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 25 16:14:39 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 16:14:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGXmD-0001jW-Gg; Tue, 25 Sep 2012 16:14:25 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1TGXmB-0001jP-S8
	for xen-devel@lists.xensource.com; Tue, 25 Sep 2012 16:14:24 +0000
Received: from [85.158.137.99:24999] by server-12.bemta-3.messagelabs.com id
	94/BE-10384-E58D1605; Tue, 25 Sep 2012 16:14:22 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-217.messagelabs.com!1348589662!18972033!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTEwNzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29737 invoked from network); 25 Sep 2012 16:14:22 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Sep 2012 16:14:22 -0000
X-IronPort-AV: E=Sophos;i="4.80,484,1344211200"; d="scan'208";a="14756017"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Sep 2012 16:14: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.279.1;
	Tue, 25 Sep 2012 17:14:22 +0100
Message-ID: <1348589660.12592.19.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
Date: Tue, 25 Sep 2012 17:14:20 +0100
In-Reply-To: <5061D52B.9080503@jhuapl.edu>
References: <505CBDFD.5070408@jhuapl.edu>
	<1348569397.3452.180.camel@zakaz.uk.xensource.com>
	<5061D52B.9080503@jhuapl.edu>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH xm/xl enhancements for vptm 5/6] make devid
	a libxl 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 Tue, 2012-09-25 at 17:00 +0100, Matthew Fioravante wrote:
> On 09/25/2012 06:36 AM, Ian Campbell wrote:
> > On Fri, 2012-09-21 at 20:20 +0100, Matthew Fioravante wrote:
> >> This fixes a bug in libxl where device ids are not initialized properly.
> >> The devid field for each device is set to be an integer type which are
> >> always initialized to 0.
> >>
> >> This makes the xl DEV-attach commands always fail to add more than one
> >> device, because each time the device id is initialized to 0, when it
> >> should be initialized to -1, which in the code will trigger a search for
> >> free id.
> > Which of the DEV-attach commands can be used to add more than one
> > device?
> network-attach, block-attach, and also my vtpm-attach.

Oh, you mean by being called repeatedly, not adding multiple devices in
one go!

> > Where is the code to do the search? I had a look in the disk and network
> > cases and couldn't find it.
> libxl.c
> 
> void libxl__device_nic_add(
> 
>     if (nic->devid == -1) {
>         if (!(dompath = libxl__xs_get_dompath(gc, domid))) {
>             rc = ERROR_FAIL;
>             goto out_free;
>         }
>         if (!(l = libxl__xs_directory(gc, XBT_NULL,
>                                      libxl__sprintf(gc, "%s/device/vif",
> dompath), &nb))) {
>             nic->devid = 0;
>         } else {
>             nic->devid = strtoul(l[nb - 1], NULL, 10) + 1;
>         }
>     }

Not sure how I missed this.

> Right now, nic-devid is 0 on attach.

Is devid not a parameter to network-attach? It is to block-attach.

> So it always tries to use 0. When you do a network-attach twice,
> the second time it trys and fails to create device/vif/0

Your change to use -1 as thye default is certainly correct. I'm just
trying to figure out why xl does things this way in the first place.

> 
> >
> >> diff --git a/tools/ocaml/libs/xs/xs.mli b/tools/ocaml/libs/xs/xs.mli
> >> --- a/tools/ocaml/libs/xs/xs.mli
> >> +++ b/tools/ocaml/libs/xs/xs.mli
> >> @@ -27,6 +27,7 @@ exception Failed_to_connect
> >>  type perms = Xsraw.perms
> >>  
> >>  type domid = int
> >> +type devid = int
> > I can see why these were needed in the xl modules, but I don't see how
> > this type can be required in the xenstore ones.
> It shouldn't be required for xenstore or xc. The problem is they won't
> compile without it because of the way the ocaml build system works. As
> far as I understand it creates types for xl, xc, and xs from the
> libxl_types.idl.

No, only xl does this.

The others are the libxc and xenstore bindings which are completely hand
coded and there is no concept of a devid at those layers anyway. What
error do you get if you omit the changes to those module?

>  Either the build system needs to be changed, or devid
> needs to be a type in all libraries, or we find some other way to fix
> this initialization bug.
> >
> > Ian.
> >
> 
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 25 16:20:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 16: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 1TGXrU-0001xt-9u; Tue, 25 Sep 2012 16:19:52 +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 1TGXrS-0001xb-Vu
	for xen-devel@lists.xen.org; Tue, 25 Sep 2012 16:19:51 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1348589984!7157223!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32206 invoked from network); 25 Sep 2012 16:19:44 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-10.tower-27.messagelabs.com with SMTP;
	25 Sep 2012 16:19:44 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 25 Sep 2012 17:19:44 +0100
Message-Id: <5061F5D7020000780009DC03@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 25 Sep 2012 17:20:07 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Keir Fraser" <keir@xen.org>
References: <5061E4CF020000780009DB98@nat28.tlf.novell.com>
	<CC8790FB.4CD98%keir@xen.org>
In-Reply-To: <CC8790FB.4CD98%keir@xen.org>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] x86: slightly improve stack trace on debug
 builds
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.09.12 at 17:48, Keir Fraser <keir@xen.org> wrote:
> On 25/09/2012 16:07, "Jan Beulich" <JBeulich@suse.com> wrote:
> 
>> +    addr = regs->eip;
>> +    while ( !is_kernel_text(addr) &&
>> +            (system_state > SYS_STATE_boot || !is_kernel_inittext(addr)) )
>> +    {
>> +        /* Special case when a bad pointer was called. */
>> +        addr ^= regs->eip ^ *ESP_BEFORE_EXCEPTION(regs);
>> +        if ( addr == regs->eip )
>> +            break;
>> +    }
> 
> Lol, how does your brain work this way? It took me 15 minutes to decode this
> to something like (also I added range checks on ESP_BEFORE_EXCEPTION(regs),
> what do you think?):

Sorry for this - just wanted to avoid having the condition evaluated
(and spelled out) twice (and it took me a minute at most to find this
iterate-at-most-twice solution). With the helper function ...

> bool_t is_current_kernel_text(unsigned long addr)
> {
>     return (is_kernel_text(addr) ||
>             (system_state == SYS_STATE_boot && is_kernel_inittext(addr)));
> }

... it at least would be reasonable to read at the source level.

So adding (and at once using at wherever else is appropriate)
that helper function is certainly worthwhile. And while I like the
way the rest was coded better than yours, I guess I ought to
change it for your and future readers' sake.

> /*
>  * If RIP is not valid hypervisor code then someone may have called into
>  * oblivion. Peek to see if they left a return address at top of stack.
>  */
> addr = (!is_current_kernel_text(regs->eip) &&
>         (ESP_BEFORE_EXCEPTION(regs) >= low) &&
>         (ESP_BEFORE_EXCEPTION(regs) < high) &&
>         is_current_kernel_text(*ESP_BEFORE_EXCEPTION(regs)))
>        ? *ESP_BEFORE_EXCEPTION(regs) : regs->eip;

Checking against "low" is pointless, as that one is guaranteed
lower than the stack pointer (unless the stack pointer was within
16 bytes from NULL). Checking against "high" is almost pointless
too, as there's only a very small range where %rsp could have
been to make that check fail (plus the 2 slots offset wouldn't be
right in this special case, i.e. we could get a false negative here),
and it wouldn't help preventing eventual #PF on the deref (since
"high" and the possible window above are on the same page).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 25 16:20:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 16: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 1TGXrU-0001xt-9u; Tue, 25 Sep 2012 16:19:52 +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 1TGXrS-0001xb-Vu
	for xen-devel@lists.xen.org; Tue, 25 Sep 2012 16:19:51 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1348589984!7157223!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32206 invoked from network); 25 Sep 2012 16:19:44 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-10.tower-27.messagelabs.com with SMTP;
	25 Sep 2012 16:19:44 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 25 Sep 2012 17:19:44 +0100
Message-Id: <5061F5D7020000780009DC03@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 25 Sep 2012 17:20:07 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Keir Fraser" <keir@xen.org>
References: <5061E4CF020000780009DB98@nat28.tlf.novell.com>
	<CC8790FB.4CD98%keir@xen.org>
In-Reply-To: <CC8790FB.4CD98%keir@xen.org>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] x86: slightly improve stack trace on debug
 builds
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.09.12 at 17:48, Keir Fraser <keir@xen.org> wrote:
> On 25/09/2012 16:07, "Jan Beulich" <JBeulich@suse.com> wrote:
> 
>> +    addr = regs->eip;
>> +    while ( !is_kernel_text(addr) &&
>> +            (system_state > SYS_STATE_boot || !is_kernel_inittext(addr)) )
>> +    {
>> +        /* Special case when a bad pointer was called. */
>> +        addr ^= regs->eip ^ *ESP_BEFORE_EXCEPTION(regs);
>> +        if ( addr == regs->eip )
>> +            break;
>> +    }
> 
> Lol, how does your brain work this way? It took me 15 minutes to decode this
> to something like (also I added range checks on ESP_BEFORE_EXCEPTION(regs),
> what do you think?):

Sorry for this - just wanted to avoid having the condition evaluated
(and spelled out) twice (and it took me a minute at most to find this
iterate-at-most-twice solution). With the helper function ...

> bool_t is_current_kernel_text(unsigned long addr)
> {
>     return (is_kernel_text(addr) ||
>             (system_state == SYS_STATE_boot && is_kernel_inittext(addr)));
> }

... it at least would be reasonable to read at the source level.

So adding (and at once using at wherever else is appropriate)
that helper function is certainly worthwhile. And while I like the
way the rest was coded better than yours, I guess I ought to
change it for your and future readers' sake.

> /*
>  * If RIP is not valid hypervisor code then someone may have called into
>  * oblivion. Peek to see if they left a return address at top of stack.
>  */
> addr = (!is_current_kernel_text(regs->eip) &&
>         (ESP_BEFORE_EXCEPTION(regs) >= low) &&
>         (ESP_BEFORE_EXCEPTION(regs) < high) &&
>         is_current_kernel_text(*ESP_BEFORE_EXCEPTION(regs)))
>        ? *ESP_BEFORE_EXCEPTION(regs) : regs->eip;

Checking against "low" is pointless, as that one is guaranteed
lower than the stack pointer (unless the stack pointer was within
16 bytes from NULL). Checking against "high" is almost pointless
too, as there's only a very small range where %rsp could have
been to make that check fail (plus the 2 slots offset wouldn't be
right in this special case, i.e. we could get a false negative here),
and it wouldn't help preventing eventual #PF on the deref (since
"high" and the possible window above are on the same page).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 25 16:25:19 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 16:25:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGXwY-0002Ho-Lq; Tue, 25 Sep 2012 16:25:06 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <matthew.fioravante@jhuapl.edu>) id 1TGXwX-0002Hf-Fy
	for xen-devel@lists.xensource.com; Tue, 25 Sep 2012 16:25:05 +0000
Received: from [85.158.138.51:15335] by server-14.bemta-3.messagelabs.com id
	2C/4A-21431-0EAD1605; Tue, 25 Sep 2012 16:25:04 +0000
X-Env-Sender: matthew.fioravante@jhuapl.edu
X-Msg-Ref: server-4.tower-174.messagelabs.com!1348590302!31430641!1
X-Originating-IP: [128.244.251.36]
X-SpamReason: No, hits=0.0 required=7.0 tests=UNPARSEABLE_RELAY
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 673 invoked from network); 25 Sep 2012 16:25:03 -0000
Received: from pilot.jhuapl.edu (HELO jhuapl.edu) (128.244.251.36)
	by server-4.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 25 Sep 2012 16:25:03 -0000
Received: from ([128.244.207.89])
	by pilot.jhuapl.edu with ESMTP with TLS id 63GHCH1.153620087;
	Tue, 25 Sep 2012 12:24:56 -0400
Message-ID: <5061DA8A.3080508@jhuapl.edu>
Date: Tue, 25 Sep 2012 12:23:38 -0400
From: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120827 Thunderbird/15.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <505CBDFD.5070408@jhuapl.edu>
	<1348569397.3452.180.camel@zakaz.uk.xensource.com>
	<5061D52B.9080503@jhuapl.edu>
	<1348589660.12592.19.camel@zakaz.uk.xensource.com>
In-Reply-To: <1348589660.12592.19.camel@zakaz.uk.xensource.com>
X-Enigmail-Version: 1.4.4
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH xm/xl enhancements for vptm 5/6] make devid
	a libxl 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: multipart/mixed; boundary="===============0023937725986436489=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a cryptographically signed message in MIME format.

--===============0023937725986436489==
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms000301000008030904040501"

This is a cryptographically signed message in MIME format.

--------------ms000301000008030904040501
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 09/25/2012 12:14 PM, Ian Campbell wrote:
> On Tue, 2012-09-25 at 17:00 +0100, Matthew Fioravante wrote:
>> On 09/25/2012 06:36 AM, Ian Campbell wrote:
>>> On Fri, 2012-09-21 at 20:20 +0100, Matthew Fioravante wrote:
>>>> This fixes a bug in libxl where device ids are not initialized prope=
rly.
>>>> The devid field for each device is set to be an integer type which a=
re
>>>> always initialized to 0.
>>>>
>>>> This makes the xl DEV-attach commands always fail to add more than o=
ne
>>>> device, because each time the device id is initialized to 0, when it=

>>>> should be initialized to -1, which in the code will trigger a search=
 for
>>>> free id.
>>> Which of the DEV-attach commands can be used to add more than one
>>> device?
>> network-attach, block-attach, and also my vtpm-attach.
> Oh, you mean by being called repeatedly, not adding multiple devices in=

> one go!
>
>>> Where is the code to do the search? I had a look in the disk and netw=
ork
>>> cases and couldn't find it.
>> libxl.c
>>
>> void libxl__device_nic_add(
>>
>>     if (nic->devid =3D=3D -1) {
>>         if (!(dompath =3D libxl__xs_get_dompath(gc, domid))) {
>>             rc =3D ERROR_FAIL;
>>             goto out_free;
>>         }
>>         if (!(l =3D libxl__xs_directory(gc, XBT_NULL,
>>                                      libxl__sprintf(gc, "%s/device/vif=
",
>> dompath), &nb))) {
>>             nic->devid =3D 0;
>>         } else {
>>             nic->devid =3D strtoul(l[nb - 1], NULL, 10) + 1;
>>         }
>>     }
> Not sure how I missed this.
>
>> Right now, nic-devid is 0 on attach.
> Is devid not a parameter to network-attach? It is to block-attach.
It might be, but if its not specified I think the logical thing to do is
to automatically choose the next available id.
>
>> So it always tries to use 0. When you do a network-attach twice,
>> the second time it trys and fails to create device/vif/0
> Your change to use -1 as thye default is certainly correct. I'm just
> trying to figure out why xl does things this way in the first place.
>
>>>> diff --git a/tools/ocaml/libs/xs/xs.mli b/tools/ocaml/libs/xs/xs.mli=

>>>> --- a/tools/ocaml/libs/xs/xs.mli
>>>> +++ b/tools/ocaml/libs/xs/xs.mli
>>>> @@ -27,6 +27,7 @@ exception Failed_to_connect
>>>>  type perms =3D Xsraw.perms
>>>> =20
>>>>  type domid =3D int
>>>> +type devid =3D int
>>> I can see why these were needed in the xl modules, but I don't see ho=
w
>>> this type can be required in the xenstore ones.
>> It shouldn't be required for xenstore or xc. The problem is they won't=

>> compile without it because of the way the ocaml build system works. As=

>> far as I understand it creates types for xl, xc, and xs from the
>> libxl_types.idl.
> No, only xl does this.
>
> The others are the libxc and xenstore bindings which are completely han=
d
> coded and there is no concept of a devid at those layers anyway. What
> error do you get if you omit the changes to those module?
Ok I must be crazy. I went back and removed them and tried to compile it
again and it works fine. I think I was forgetting to update both the
=2Emli and the .ml files. Anyway a new patch with the xc/xs removed is
attached.
>
>>  Either the build system needs to be changed, or devid
>> needs to be a type in all libraries, or we find some other way to fix
>> this initialization bug.
>>> Ian.
>>>
>>
>

Signed off by Matthew Fioravante matthew.fioravante@jhuapl.edu

---
* Rebased off of latest xen-unstable
* Fixed whitespace errors
* Removed devid from libxc and libxs

diff --git a/tools/libxl/gentest.py b/tools/libxl/gentest.py
--- a/tools/libxl/gentest.py
+++ b/tools/libxl/gentest.py
@@ -60,7 +60,7 @@ def gen_rand_init(ty, v, indent =3D "    ", parent =3D =
None):
                                         passby=3Didl.PASS_BY_REFERENCE))=

     elif ty.typename in ["libxl_uuid", "libxl_mac", "libxl_hwcap"]:
         s +=3D "rand_bytes((uint8_t *)%s, sizeof(*%s));\n" % (v,v)
-    elif ty.typename in ["libxl_domid"] or isinstance(ty, idl.Number):
+    elif ty.typename in ["libxl_domid", "libxl_devid"] or isinstance(ty,=
 idl.Number):
         s +=3D "%s =3D rand() %% (sizeof(%s)*8);\n" % \
              (ty.pass_arg(v, parent is None),
               ty.pass_arg(v, parent is None))
diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -307,6 +307,7 @@ void libxl_cpuid_dispose(libxl_cpuid_policy_list *cpu=
id_list);
 #define LIBXL_PCI_FUNC_ALL (~0U)
=20
 typedef uint32_t libxl_domid;
+typedef int libxl_devid;
=20
 /*
  * Formatting Enumerations.
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
@@ -8,6 +8,7 @@ namespace("libxl_")
 libxl_defbool =3D Builtin("defbool", passby=3DPASS_BY_REFERENCE)
=20
 libxl_domid =3D Builtin("domid", json_fn =3D "yajl_gen_integer", autogen=
erate_json =3D False)
+libxl_devid =3D Builtin("devid", json_fn =3D "yajl_gen_integer", autogen=
erate_json =3D False, signed =3D True, init_val=3D"-1")
 libxl_uuid =3D Builtin("uuid", passby=3DPASS_BY_REFERENCE)
 libxl_mac =3D Builtin("mac", passby=3DPASS_BY_REFERENCE)
 libxl_bitmap =3D Builtin("bitmap", dispose_fn=3D"libxl_bitmap_dispose", =
passby=3DPASS_BY_REFERENCE)
@@ -343,7 +344,7 @@ libxl_domain_build_info =3D Struct("domain_build_info=
",[
=20
 libxl_device_vfb =3D Struct("device_vfb", [
     ("backend_domid", libxl_domid),
-    ("devid",         integer),
+    ("devid",         libxl_devid),
     ("vnc",           libxl_vnc_info),
     ("sdl",           libxl_sdl_info),
     # set keyboard layout, default is en-us keyboard
@@ -352,7 +353,7 @@ libxl_device_vfb =3D Struct("device_vfb", [
=20
 libxl_device_vkb =3D Struct("device_vkb", [
     ("backend_domid", libxl_domid),
-    ("devid", integer),
+    ("devid", libxl_devid),
     ])
=20
 libxl_device_disk =3D Struct("device_disk", [
@@ -369,7 +370,7 @@ libxl_device_disk =3D Struct("device_disk", [
=20
 libxl_device_nic =3D Struct("device_nic", [
     ("backend_domid", libxl_domid),
-    ("devid", integer),
+    ("devid", libxl_devid),
     ("mtu", integer),
     ("model", string),
     ("mac", libxl_mac),
@@ -399,7 +400,7 @@ libxl_diskinfo =3D Struct("diskinfo", [
     ("backend_id", uint32),
     ("frontend", string),
     ("frontend_id", uint32),
-    ("devid", integer),
+    ("devid", libxl_devid),
     ("state", integer),
     ("evtch", integer),
     ("rref", integer),
@@ -410,7 +411,7 @@ libxl_nicinfo =3D Struct("nicinfo", [
     ("backend_id", uint32),
     ("frontend", string),
     ("frontend_id", uint32),
-    ("devid", integer),
+    ("devid", libxl_devid),
     ("state", integer),
     ("evtch", integer),
     ("rref_tx", integer),
diff --git a/tools/ocaml/libs/xl/genwrap.py b/tools/ocaml/libs/xl/genwrap=
=2Epy
--- a/tools/ocaml/libs/xl/genwrap.py
+++ b/tools/ocaml/libs/xl/genwrap.py
@@ -10,6 +10,7 @@ builtins =3D {
     "int":                  ("int",                    "%(c)s =3D Int_va=
l(%(o)s)",            "Val_int(%(c)s)"  ),
     "char *":               ("string",                 "%(c)s =3D dup_St=
ring_val(gc, %(o)s)", "caml_copy_string(%(c)s)"),
     "libxl_domid":          ("domid",                  "%(c)s =3D Int_va=
l(%(o)s)",            "Val_int(%(c)s)"  ),
+    "libxl_devid":          ("devid",                  "%(c)s =3D Int_va=
l(%(o)s)",            "Val_int(%(c)s)"  ),
     "libxl_defbool":        ("bool option",            "%(c)s =3D Defboo=
l_val(%(o)s)",        "Val_defbool(%(c)s)" ),
     "libxl_uuid":           ("int array",              "Uuid_val(gc, lg,=
 &%(c)s, %(o)s)",   "Val_uuid(&%(c)s)"),
     "libxl_key_value_list": ("(string * string) list", None,            =
                    None),
@@ -41,8 +42,8 @@ def stub_fn_name(ty, name):
     return "stub_xl_%s_%s" % (ty.rawname,name)
    =20
 def ocaml_type_of(ty):
-    if ty.rawname =3D=3D "domid":
-        return "domid"
+    if ty.rawname in ["domid","devid"]:
+        return ty.rawname
     elif isinstance(ty,idl.UInt):
         if ty.width in [8, 16]:
             # handle as ints
diff --git a/tools/ocaml/libs/xl/xenlight.ml.in b/tools/ocaml/libs/xl/xen=
light.ml.in
--- a/tools/ocaml/libs/xl/xenlight.ml.in
+++ b/tools/ocaml/libs/xl/xenlight.ml.in
@@ -16,6 +16,7 @@
 exception Error of string
=20
 type domid =3D int
+type devid =3D int
=20
 (* @@LIBXL_TYPES@@ *)
=20
diff --git a/tools/ocaml/libs/xl/xenlight.mli.in b/tools/ocaml/libs/xl/xe=
nlight.mli.in
--- a/tools/ocaml/libs/xl/xenlight.mli.in
+++ b/tools/ocaml/libs/xl/xenlight.mli.in
@@ -16,6 +16,7 @@
 exception Error of string
=20
 type domid =3D int
+type devid =3D int
=20
 (* @@LIBXL_TYPES@@ *)
=20
diff --git a/tools/python/xen/lowlevel/xl/xl.c b/tools/python/xen/lowleve=
l/xl/xl.c
--- a/tools/python/xen/lowlevel/xl/xl.c
+++ b/tools/python/xen/lowlevel/xl/xl.c
@@ -281,6 +281,11 @@ int attrib__libxl_domid_set(PyObject *v, libxl_domid=
 *domid) {
     return 0;
 }
=20
+int attrib__libxl_devid_set(PyObject *v, libxl_devid *devid) {
+   *devid =3D PyInt_AsLong(v);
+   return 0;
+}
+
 int attrib__struct_in_addr_set(PyObject *v, struct in_addr *pptr)
 {
     PyErr_SetString(PyExc_NotImplementedError, "Setting in_addr");
@@ -342,6 +347,10 @@ PyObject *attrib__libxl_domid_get(libxl_domid *domid=
) {
     return PyInt_FromLong(*domid);
 }
=20
+PyObject *attrib__libxl_devid_get(libxl_devid *devid) {
+    return PyInt_FromLong(*devid);
+}
+
 PyObject *attrib__struct_in_addr_get(struct in_addr *pptr)
 {
     PyErr_SetString(PyExc_NotImplementedError, "Getting in_addr");
--=20
1.7.4.4





--------------ms000301000008030904040501
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIDyjCC
A8YwggMvoAMCAQICBD/xyf0wDQYJKoZIhvcNAQEFBQAwLzELMAkGA1UEBhMCVVMxDzANBgNV
BAoTBkpIVUFQTDEPMA0GA1UECxMGQklTRENBMB4XDTEwMDYxMTE4MjIwNloXDTEzMDYxMTE4
NTIwNlowZjELMAkGA1UEBhMCVVMxDzANBgNVBAoTBkpIVUFQTDEPMA0GA1UECxMGUGVvcGxl
MTUwFgYDVQQLEw9WUE5Hcm91cC1CSVNEQ0EwGwYDVQQDExRNYXR0aGV3IEUgRmlvcmF2YW50
ZTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAnpbwVSP6o1Nb5lcW7dd3yTo9iBJdi7qz
4nANOMFPK7JOy5npKN1iiousl28U/scUJES55gPwAWYJK3uVyQAsA4adgDKi5DoD1UHDQEwp
bY7iHLJeq0NPr4BqYNqnCFPbE6HC8zSJrr4qKn+gVUQT39SIFqdiIPJwZL8FYTRQ/zsCAwEA
AaOCAbYwggGyMAsGA1UdDwQEAwIHgDArBgNVHRAEJDAigA8yMDEwMDYxMTE4MjIwNlqBDzIw
MTIwNzE3MjI1MjA2WjAbBg0rBgEEAbMlCwMBAQEBBAoWCGZpb3JhbWUxMBsGDSsGAQQBsyUL
AwEBAQIEChIIMDAxMDQyNjEwWAYJYIZIAYb6ax4BBEsMSVRoZSBwcml2YXRlIGtleSBjb3Jy
ZXNwb25kaW5nIHRvIHRoaXMgY2VydGlmaWNhdGUgbWF5IGhhdmUgYmVlbiBleHBvcnRlZC4w
KAYDVR0RBCEwH4EdTWF0dGhldy5GaW9yYXZhbnRlQGpodWFwbC5lZHUwUgYDVR0fBEswSTBH
oEWgQ6RBMD8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJU0RD
QTEOMAwGA1UEAxMFQ1JMNTYwHwYDVR0jBBgwFoAUCDUpmxH52EU2CyWmF2EJMB1yqeswHQYD
VR0OBBYEFO6LYxg6r9wHZ+zdQtBHn1dZ/YTNMAkGA1UdEwQCMAAwGQYJKoZIhvZ9B0EABAww
ChsEVjcuMQMCBLAwDQYJKoZIhvcNAQEFBQADgYEAJO9HQh4YNChVLzuZqK5ARJARD8JoujGZ
fdo75quvg2jXFQe2sEjvLnxJZgm/pv8fdZakq48CWwjYHKuvIp7sDjTEsQfo+y7SpN/N2NvJ
WU5SqfK1VgYtNLRRoGJUB5Q1aZ+Dg95g3kqpyfpUMISJL8IKVLtJVfN4fggFVUYZ9wwxggGr
MIIBpwIBATA3MC8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJ
U0RDQQIEP/HJ/TAJBgUrDgMCGgUAoIHLMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ
KoZIhvcNAQkFMQ8XDTEyMDkyNTE2MjMzOFowIwYJKoZIhvcNAQkEMRYEFDQGxeiHvt9t7cG4
ycfIC015MquzMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAK
BggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI
KoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEgYCEqiQVmQfKhuTWqwJJZnwec5bYmGSztt7c
RaYvMxgfPUr0NgfyRnQiA/nC7BDQU5145WJpIzoslDrW76Ce4/UsV/gr2V31jQNbpds/CSWn
N6d734QSedr01ajKbyK5LozCQf9DEo2SvyGOJzCnJBBx3NhwOxFE04QN2DGujAApPwAAAAAA
AA==
--------------ms000301000008030904040501--


--===============0023937725986436489==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============0023937725986436489==--


From xen-devel-bounces@lists.xen.org Tue Sep 25 16:25:19 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 16:25:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGXwY-0002Ho-Lq; Tue, 25 Sep 2012 16:25:06 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <matthew.fioravante@jhuapl.edu>) id 1TGXwX-0002Hf-Fy
	for xen-devel@lists.xensource.com; Tue, 25 Sep 2012 16:25:05 +0000
Received: from [85.158.138.51:15335] by server-14.bemta-3.messagelabs.com id
	2C/4A-21431-0EAD1605; Tue, 25 Sep 2012 16:25:04 +0000
X-Env-Sender: matthew.fioravante@jhuapl.edu
X-Msg-Ref: server-4.tower-174.messagelabs.com!1348590302!31430641!1
X-Originating-IP: [128.244.251.36]
X-SpamReason: No, hits=0.0 required=7.0 tests=UNPARSEABLE_RELAY
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 673 invoked from network); 25 Sep 2012 16:25:03 -0000
Received: from pilot.jhuapl.edu (HELO jhuapl.edu) (128.244.251.36)
	by server-4.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 25 Sep 2012 16:25:03 -0000
Received: from ([128.244.207.89])
	by pilot.jhuapl.edu with ESMTP with TLS id 63GHCH1.153620087;
	Tue, 25 Sep 2012 12:24:56 -0400
Message-ID: <5061DA8A.3080508@jhuapl.edu>
Date: Tue, 25 Sep 2012 12:23:38 -0400
From: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120827 Thunderbird/15.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <505CBDFD.5070408@jhuapl.edu>
	<1348569397.3452.180.camel@zakaz.uk.xensource.com>
	<5061D52B.9080503@jhuapl.edu>
	<1348589660.12592.19.camel@zakaz.uk.xensource.com>
In-Reply-To: <1348589660.12592.19.camel@zakaz.uk.xensource.com>
X-Enigmail-Version: 1.4.4
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH xm/xl enhancements for vptm 5/6] make devid
	a libxl 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: multipart/mixed; boundary="===============0023937725986436489=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a cryptographically signed message in MIME format.

--===============0023937725986436489==
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms000301000008030904040501"

This is a cryptographically signed message in MIME format.

--------------ms000301000008030904040501
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 09/25/2012 12:14 PM, Ian Campbell wrote:
> On Tue, 2012-09-25 at 17:00 +0100, Matthew Fioravante wrote:
>> On 09/25/2012 06:36 AM, Ian Campbell wrote:
>>> On Fri, 2012-09-21 at 20:20 +0100, Matthew Fioravante wrote:
>>>> This fixes a bug in libxl where device ids are not initialized prope=
rly.
>>>> The devid field for each device is set to be an integer type which a=
re
>>>> always initialized to 0.
>>>>
>>>> This makes the xl DEV-attach commands always fail to add more than o=
ne
>>>> device, because each time the device id is initialized to 0, when it=

>>>> should be initialized to -1, which in the code will trigger a search=
 for
>>>> free id.
>>> Which of the DEV-attach commands can be used to add more than one
>>> device?
>> network-attach, block-attach, and also my vtpm-attach.
> Oh, you mean by being called repeatedly, not adding multiple devices in=

> one go!
>
>>> Where is the code to do the search? I had a look in the disk and netw=
ork
>>> cases and couldn't find it.
>> libxl.c
>>
>> void libxl__device_nic_add(
>>
>>     if (nic->devid =3D=3D -1) {
>>         if (!(dompath =3D libxl__xs_get_dompath(gc, domid))) {
>>             rc =3D ERROR_FAIL;
>>             goto out_free;
>>         }
>>         if (!(l =3D libxl__xs_directory(gc, XBT_NULL,
>>                                      libxl__sprintf(gc, "%s/device/vif=
",
>> dompath), &nb))) {
>>             nic->devid =3D 0;
>>         } else {
>>             nic->devid =3D strtoul(l[nb - 1], NULL, 10) + 1;
>>         }
>>     }
> Not sure how I missed this.
>
>> Right now, nic-devid is 0 on attach.
> Is devid not a parameter to network-attach? It is to block-attach.
It might be, but if its not specified I think the logical thing to do is
to automatically choose the next available id.
>
>> So it always tries to use 0. When you do a network-attach twice,
>> the second time it trys and fails to create device/vif/0
> Your change to use -1 as thye default is certainly correct. I'm just
> trying to figure out why xl does things this way in the first place.
>
>>>> diff --git a/tools/ocaml/libs/xs/xs.mli b/tools/ocaml/libs/xs/xs.mli=

>>>> --- a/tools/ocaml/libs/xs/xs.mli
>>>> +++ b/tools/ocaml/libs/xs/xs.mli
>>>> @@ -27,6 +27,7 @@ exception Failed_to_connect
>>>>  type perms =3D Xsraw.perms
>>>> =20
>>>>  type domid =3D int
>>>> +type devid =3D int
>>> I can see why these were needed in the xl modules, but I don't see ho=
w
>>> this type can be required in the xenstore ones.
>> It shouldn't be required for xenstore or xc. The problem is they won't=

>> compile without it because of the way the ocaml build system works. As=

>> far as I understand it creates types for xl, xc, and xs from the
>> libxl_types.idl.
> No, only xl does this.
>
> The others are the libxc and xenstore bindings which are completely han=
d
> coded and there is no concept of a devid at those layers anyway. What
> error do you get if you omit the changes to those module?
Ok I must be crazy. I went back and removed them and tried to compile it
again and it works fine. I think I was forgetting to update both the
=2Emli and the .ml files. Anyway a new patch with the xc/xs removed is
attached.
>
>>  Either the build system needs to be changed, or devid
>> needs to be a type in all libraries, or we find some other way to fix
>> this initialization bug.
>>> Ian.
>>>
>>
>

Signed off by Matthew Fioravante matthew.fioravante@jhuapl.edu

---
* Rebased off of latest xen-unstable
* Fixed whitespace errors
* Removed devid from libxc and libxs

diff --git a/tools/libxl/gentest.py b/tools/libxl/gentest.py
--- a/tools/libxl/gentest.py
+++ b/tools/libxl/gentest.py
@@ -60,7 +60,7 @@ def gen_rand_init(ty, v, indent =3D "    ", parent =3D =
None):
                                         passby=3Didl.PASS_BY_REFERENCE))=

     elif ty.typename in ["libxl_uuid", "libxl_mac", "libxl_hwcap"]:
         s +=3D "rand_bytes((uint8_t *)%s, sizeof(*%s));\n" % (v,v)
-    elif ty.typename in ["libxl_domid"] or isinstance(ty, idl.Number):
+    elif ty.typename in ["libxl_domid", "libxl_devid"] or isinstance(ty,=
 idl.Number):
         s +=3D "%s =3D rand() %% (sizeof(%s)*8);\n" % \
              (ty.pass_arg(v, parent is None),
               ty.pass_arg(v, parent is None))
diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -307,6 +307,7 @@ void libxl_cpuid_dispose(libxl_cpuid_policy_list *cpu=
id_list);
 #define LIBXL_PCI_FUNC_ALL (~0U)
=20
 typedef uint32_t libxl_domid;
+typedef int libxl_devid;
=20
 /*
  * Formatting Enumerations.
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
@@ -8,6 +8,7 @@ namespace("libxl_")
 libxl_defbool =3D Builtin("defbool", passby=3DPASS_BY_REFERENCE)
=20
 libxl_domid =3D Builtin("domid", json_fn =3D "yajl_gen_integer", autogen=
erate_json =3D False)
+libxl_devid =3D Builtin("devid", json_fn =3D "yajl_gen_integer", autogen=
erate_json =3D False, signed =3D True, init_val=3D"-1")
 libxl_uuid =3D Builtin("uuid", passby=3DPASS_BY_REFERENCE)
 libxl_mac =3D Builtin("mac", passby=3DPASS_BY_REFERENCE)
 libxl_bitmap =3D Builtin("bitmap", dispose_fn=3D"libxl_bitmap_dispose", =
passby=3DPASS_BY_REFERENCE)
@@ -343,7 +344,7 @@ libxl_domain_build_info =3D Struct("domain_build_info=
",[
=20
 libxl_device_vfb =3D Struct("device_vfb", [
     ("backend_domid", libxl_domid),
-    ("devid",         integer),
+    ("devid",         libxl_devid),
     ("vnc",           libxl_vnc_info),
     ("sdl",           libxl_sdl_info),
     # set keyboard layout, default is en-us keyboard
@@ -352,7 +353,7 @@ libxl_device_vfb =3D Struct("device_vfb", [
=20
 libxl_device_vkb =3D Struct("device_vkb", [
     ("backend_domid", libxl_domid),
-    ("devid", integer),
+    ("devid", libxl_devid),
     ])
=20
 libxl_device_disk =3D Struct("device_disk", [
@@ -369,7 +370,7 @@ libxl_device_disk =3D Struct("device_disk", [
=20
 libxl_device_nic =3D Struct("device_nic", [
     ("backend_domid", libxl_domid),
-    ("devid", integer),
+    ("devid", libxl_devid),
     ("mtu", integer),
     ("model", string),
     ("mac", libxl_mac),
@@ -399,7 +400,7 @@ libxl_diskinfo =3D Struct("diskinfo", [
     ("backend_id", uint32),
     ("frontend", string),
     ("frontend_id", uint32),
-    ("devid", integer),
+    ("devid", libxl_devid),
     ("state", integer),
     ("evtch", integer),
     ("rref", integer),
@@ -410,7 +411,7 @@ libxl_nicinfo =3D Struct("nicinfo", [
     ("backend_id", uint32),
     ("frontend", string),
     ("frontend_id", uint32),
-    ("devid", integer),
+    ("devid", libxl_devid),
     ("state", integer),
     ("evtch", integer),
     ("rref_tx", integer),
diff --git a/tools/ocaml/libs/xl/genwrap.py b/tools/ocaml/libs/xl/genwrap=
=2Epy
--- a/tools/ocaml/libs/xl/genwrap.py
+++ b/tools/ocaml/libs/xl/genwrap.py
@@ -10,6 +10,7 @@ builtins =3D {
     "int":                  ("int",                    "%(c)s =3D Int_va=
l(%(o)s)",            "Val_int(%(c)s)"  ),
     "char *":               ("string",                 "%(c)s =3D dup_St=
ring_val(gc, %(o)s)", "caml_copy_string(%(c)s)"),
     "libxl_domid":          ("domid",                  "%(c)s =3D Int_va=
l(%(o)s)",            "Val_int(%(c)s)"  ),
+    "libxl_devid":          ("devid",                  "%(c)s =3D Int_va=
l(%(o)s)",            "Val_int(%(c)s)"  ),
     "libxl_defbool":        ("bool option",            "%(c)s =3D Defboo=
l_val(%(o)s)",        "Val_defbool(%(c)s)" ),
     "libxl_uuid":           ("int array",              "Uuid_val(gc, lg,=
 &%(c)s, %(o)s)",   "Val_uuid(&%(c)s)"),
     "libxl_key_value_list": ("(string * string) list", None,            =
                    None),
@@ -41,8 +42,8 @@ def stub_fn_name(ty, name):
     return "stub_xl_%s_%s" % (ty.rawname,name)
    =20
 def ocaml_type_of(ty):
-    if ty.rawname =3D=3D "domid":
-        return "domid"
+    if ty.rawname in ["domid","devid"]:
+        return ty.rawname
     elif isinstance(ty,idl.UInt):
         if ty.width in [8, 16]:
             # handle as ints
diff --git a/tools/ocaml/libs/xl/xenlight.ml.in b/tools/ocaml/libs/xl/xen=
light.ml.in
--- a/tools/ocaml/libs/xl/xenlight.ml.in
+++ b/tools/ocaml/libs/xl/xenlight.ml.in
@@ -16,6 +16,7 @@
 exception Error of string
=20
 type domid =3D int
+type devid =3D int
=20
 (* @@LIBXL_TYPES@@ *)
=20
diff --git a/tools/ocaml/libs/xl/xenlight.mli.in b/tools/ocaml/libs/xl/xe=
nlight.mli.in
--- a/tools/ocaml/libs/xl/xenlight.mli.in
+++ b/tools/ocaml/libs/xl/xenlight.mli.in
@@ -16,6 +16,7 @@
 exception Error of string
=20
 type domid =3D int
+type devid =3D int
=20
 (* @@LIBXL_TYPES@@ *)
=20
diff --git a/tools/python/xen/lowlevel/xl/xl.c b/tools/python/xen/lowleve=
l/xl/xl.c
--- a/tools/python/xen/lowlevel/xl/xl.c
+++ b/tools/python/xen/lowlevel/xl/xl.c
@@ -281,6 +281,11 @@ int attrib__libxl_domid_set(PyObject *v, libxl_domid=
 *domid) {
     return 0;
 }
=20
+int attrib__libxl_devid_set(PyObject *v, libxl_devid *devid) {
+   *devid =3D PyInt_AsLong(v);
+   return 0;
+}
+
 int attrib__struct_in_addr_set(PyObject *v, struct in_addr *pptr)
 {
     PyErr_SetString(PyExc_NotImplementedError, "Setting in_addr");
@@ -342,6 +347,10 @@ PyObject *attrib__libxl_domid_get(libxl_domid *domid=
) {
     return PyInt_FromLong(*domid);
 }
=20
+PyObject *attrib__libxl_devid_get(libxl_devid *devid) {
+    return PyInt_FromLong(*devid);
+}
+
 PyObject *attrib__struct_in_addr_get(struct in_addr *pptr)
 {
     PyErr_SetString(PyExc_NotImplementedError, "Getting in_addr");
--=20
1.7.4.4





--------------ms000301000008030904040501
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIDyjCC
A8YwggMvoAMCAQICBD/xyf0wDQYJKoZIhvcNAQEFBQAwLzELMAkGA1UEBhMCVVMxDzANBgNV
BAoTBkpIVUFQTDEPMA0GA1UECxMGQklTRENBMB4XDTEwMDYxMTE4MjIwNloXDTEzMDYxMTE4
NTIwNlowZjELMAkGA1UEBhMCVVMxDzANBgNVBAoTBkpIVUFQTDEPMA0GA1UECxMGUGVvcGxl
MTUwFgYDVQQLEw9WUE5Hcm91cC1CSVNEQ0EwGwYDVQQDExRNYXR0aGV3IEUgRmlvcmF2YW50
ZTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAnpbwVSP6o1Nb5lcW7dd3yTo9iBJdi7qz
4nANOMFPK7JOy5npKN1iiousl28U/scUJES55gPwAWYJK3uVyQAsA4adgDKi5DoD1UHDQEwp
bY7iHLJeq0NPr4BqYNqnCFPbE6HC8zSJrr4qKn+gVUQT39SIFqdiIPJwZL8FYTRQ/zsCAwEA
AaOCAbYwggGyMAsGA1UdDwQEAwIHgDArBgNVHRAEJDAigA8yMDEwMDYxMTE4MjIwNlqBDzIw
MTIwNzE3MjI1MjA2WjAbBg0rBgEEAbMlCwMBAQEBBAoWCGZpb3JhbWUxMBsGDSsGAQQBsyUL
AwEBAQIEChIIMDAxMDQyNjEwWAYJYIZIAYb6ax4BBEsMSVRoZSBwcml2YXRlIGtleSBjb3Jy
ZXNwb25kaW5nIHRvIHRoaXMgY2VydGlmaWNhdGUgbWF5IGhhdmUgYmVlbiBleHBvcnRlZC4w
KAYDVR0RBCEwH4EdTWF0dGhldy5GaW9yYXZhbnRlQGpodWFwbC5lZHUwUgYDVR0fBEswSTBH
oEWgQ6RBMD8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJU0RD
QTEOMAwGA1UEAxMFQ1JMNTYwHwYDVR0jBBgwFoAUCDUpmxH52EU2CyWmF2EJMB1yqeswHQYD
VR0OBBYEFO6LYxg6r9wHZ+zdQtBHn1dZ/YTNMAkGA1UdEwQCMAAwGQYJKoZIhvZ9B0EABAww
ChsEVjcuMQMCBLAwDQYJKoZIhvcNAQEFBQADgYEAJO9HQh4YNChVLzuZqK5ARJARD8JoujGZ
fdo75quvg2jXFQe2sEjvLnxJZgm/pv8fdZakq48CWwjYHKuvIp7sDjTEsQfo+y7SpN/N2NvJ
WU5SqfK1VgYtNLRRoGJUB5Q1aZ+Dg95g3kqpyfpUMISJL8IKVLtJVfN4fggFVUYZ9wwxggGr
MIIBpwIBATA3MC8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJ
U0RDQQIEP/HJ/TAJBgUrDgMCGgUAoIHLMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ
KoZIhvcNAQkFMQ8XDTEyMDkyNTE2MjMzOFowIwYJKoZIhvcNAQkEMRYEFDQGxeiHvt9t7cG4
ycfIC015MquzMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAK
BggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI
KoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEgYCEqiQVmQfKhuTWqwJJZnwec5bYmGSztt7c
RaYvMxgfPUr0NgfyRnQiA/nC7BDQU5145WJpIzoslDrW76Ce4/UsV/gr2V31jQNbpds/CSWn
N6d734QSedr01ajKbyK5LozCQf9DEo2SvyGOJzCnJBBx3NhwOxFE04QN2DGujAApPwAAAAAA
AA==
--------------ms000301000008030904040501--


--===============0023937725986436489==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============0023937725986436489==--


From xen-devel-bounces@lists.xen.org Tue Sep 25 16:31:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 16: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 1TGY2G-0002WM-KD; Tue, 25 Sep 2012 16:31:00 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony@overnetdata.com>) id 1TGY29-0002WH-Vf
	for xen-devel@lists.xen.org; Tue, 25 Sep 2012 16:30:54 +0000
Received: from [85.158.138.51:58912] by server-8.bemta-3.messagelabs.com id
	4D/97-24700-D3CD1605; Tue, 25 Sep 2012 16:30:53 +0000
X-Env-Sender: anthony@overnetdata.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1348590652!31892875!1
X-Originating-IP: [81.137.131.225]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20213 invoked from network); 25 Sep 2012 16:30:52 -0000
Received: from host81-137-131-225.in-addr.btopenworld.com (HELO
	zimbra.overnetdata.com) (81.137.131.225)
	by server-2.tower-174.messagelabs.com with SMTP;
	25 Sep 2012 16:30:52 -0000
Received: from localhost (localhost.localdomain [127.0.0.1])
	by zimbra.overnetdata.com (Postfix) with ESMTP id D73C5161762;
	Tue, 25 Sep 2012 17:30:51 +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 phuIlS6vAvHq; Tue, 25 Sep 2012 17:30:51 +0100 (BST)
Received: from [192.168.1.53] (unknown [192.168.1.53])
	by zimbra.overnetdata.com (Postfix) with ESMTPSA id 34DE2161689;
	Tue, 25 Sep 2012 17:30:51 +0100 (BST)
Message-ID: <5061DC3A.7070704@overnetdata.com>
Date: Tue, 25 Sep 2012 17:30:50 +0100
From: Anthony Wright <anthony@overnetdata.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:15.0) Gecko/20120907 Thunderbird/15.0.1
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <50607CCF.9050904@overnetdata.com> <506095D3.8090907@citrix.com>
	<1348561254.3452.103.camel@zakaz.uk.xensource.com>
In-Reply-To: <1348561254.3452.103.camel@zakaz.uk.xensource.com>
X-Enigmail-Version: 1.4.4
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] First DomU started goes into a busy loop
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 25/09/2012 09:20, Ian Campbell wrote:
> (putting Anthony back on the CC)
>
> On Mon, 2012-09-24 at 18:18 +0100, Andrew Cooper wrote:
>> 32bit builds of Xen have been removed from 4.3.  As far as I am aware,
>> there has been no serious effort to maintain them.  I highly suggest
>> using a 64bit Xen.
> Anthony's references to 32-bit all seem to be in the context of the
> Linux kernel.
>
> Just to be clear we have removed support for the 32-bit hypervisor only.
> We have not and will not be removing support for 32-bit (PAE) PV
> domains, running as either guest or dom0 on a 64-bit hypervisor. 32-bit
> HVM guests, with or without PAE enabled, also remain fully supported.
>
> Ian.
>
Could you give me some pointers regarding building a 64 bit Xen
hypervisor on a 32 bit linux system, or do I need to build it on a 64
bit system?

I've found the XEN_TARGET_ARCH setting in the makefile which looks like
setting it to x86_64 might be the right direction, but I'm trying to
determine if there's an "official" way of doing it.

thanks,

Anthony.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 25 16:31:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 16: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 1TGY2G-0002WM-KD; Tue, 25 Sep 2012 16:31:00 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony@overnetdata.com>) id 1TGY29-0002WH-Vf
	for xen-devel@lists.xen.org; Tue, 25 Sep 2012 16:30:54 +0000
Received: from [85.158.138.51:58912] by server-8.bemta-3.messagelabs.com id
	4D/97-24700-D3CD1605; Tue, 25 Sep 2012 16:30:53 +0000
X-Env-Sender: anthony@overnetdata.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1348590652!31892875!1
X-Originating-IP: [81.137.131.225]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20213 invoked from network); 25 Sep 2012 16:30:52 -0000
Received: from host81-137-131-225.in-addr.btopenworld.com (HELO
	zimbra.overnetdata.com) (81.137.131.225)
	by server-2.tower-174.messagelabs.com with SMTP;
	25 Sep 2012 16:30:52 -0000
Received: from localhost (localhost.localdomain [127.0.0.1])
	by zimbra.overnetdata.com (Postfix) with ESMTP id D73C5161762;
	Tue, 25 Sep 2012 17:30:51 +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 phuIlS6vAvHq; Tue, 25 Sep 2012 17:30:51 +0100 (BST)
Received: from [192.168.1.53] (unknown [192.168.1.53])
	by zimbra.overnetdata.com (Postfix) with ESMTPSA id 34DE2161689;
	Tue, 25 Sep 2012 17:30:51 +0100 (BST)
Message-ID: <5061DC3A.7070704@overnetdata.com>
Date: Tue, 25 Sep 2012 17:30:50 +0100
From: Anthony Wright <anthony@overnetdata.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:15.0) Gecko/20120907 Thunderbird/15.0.1
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <50607CCF.9050904@overnetdata.com> <506095D3.8090907@citrix.com>
	<1348561254.3452.103.camel@zakaz.uk.xensource.com>
In-Reply-To: <1348561254.3452.103.camel@zakaz.uk.xensource.com>
X-Enigmail-Version: 1.4.4
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] First DomU started goes into a busy loop
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 25/09/2012 09:20, Ian Campbell wrote:
> (putting Anthony back on the CC)
>
> On Mon, 2012-09-24 at 18:18 +0100, Andrew Cooper wrote:
>> 32bit builds of Xen have been removed from 4.3.  As far as I am aware,
>> there has been no serious effort to maintain them.  I highly suggest
>> using a 64bit Xen.
> Anthony's references to 32-bit all seem to be in the context of the
> Linux kernel.
>
> Just to be clear we have removed support for the 32-bit hypervisor only.
> We have not and will not be removing support for 32-bit (PAE) PV
> domains, running as either guest or dom0 on a 64-bit hypervisor. 32-bit
> HVM guests, with or without PAE enabled, also remain fully supported.
>
> Ian.
>
Could you give me some pointers regarding building a 64 bit Xen
hypervisor on a 32 bit linux system, or do I need to build it on a 64
bit system?

I've found the XEN_TARGET_ARCH setting in the makefile which looks like
setting it to x86_64 might be the right direction, but I'm trying to
determine if there's an "official" way of doing it.

thanks,

Anthony.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 25 16:35:06 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 16:35: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 1TGY5w-0002ji-8b; Tue, 25 Sep 2012 16:34:48 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1TGY5u-0002ja-HF
	for xen-devel@lists.xen.org; Tue, 25 Sep 2012 16:34:46 +0000
Received: from [85.158.138.51:16643] by server-9.bemta-3.messagelabs.com id
	A7/C3-15390-52DD1605; Tue, 25 Sep 2012 16:34:45 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1348590884!25597916!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTEwNzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16927 invoked from network); 25 Sep 2012 16:34:45 -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;
	25 Sep 2012 16:34:45 -0000
X-IronPort-AV: E=Sophos;i="4.80,484,1344211200"; d="scan'208";a="14756506"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Sep 2012 16:33: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.279.1;
	Tue, 25 Sep 2012 17:33:35 +0100
Message-ID: <1348590813.12592.20.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Anthony Wright <anthony@overnetdata.com>
Date: Tue, 25 Sep 2012 17:33:33 +0100
In-Reply-To: <5061DC3A.7070704@overnetdata.com>
References: <50607CCF.9050904@overnetdata.com> <506095D3.8090907@citrix.com>
	<1348561254.3452.103.camel@zakaz.uk.xensource.com>
	<5061DC3A.7070704@overnetdata.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-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] First DomU started goes into a busy loop
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-09-25 at 17:30 +0100, Anthony Wright wrote:
> On 25/09/2012 09:20, Ian Campbell wrote:
> > (putting Anthony back on the CC)
> >
> > On Mon, 2012-09-24 at 18:18 +0100, Andrew Cooper wrote:
> >> 32bit builds of Xen have been removed from 4.3.  As far as I am aware,
> >> there has been no serious effort to maintain them.  I highly suggest
> >> using a 64bit Xen.
> > Anthony's references to 32-bit all seem to be in the context of the
> > Linux kernel.
> >
> > Just to be clear we have removed support for the 32-bit hypervisor only.
> > We have not and will not be removing support for 32-bit (PAE) PV
> > domains, running as either guest or dom0 on a 64-bit hypervisor. 32-bit
> > HVM guests, with or without PAE enabled, also remain fully supported.
> >
> > Ian.
> >
> Could you give me some pointers regarding building a 64 bit Xen
> hypervisor on a 32 bit linux system, or do I need to build it on a 64
> bit system?
> 
> I've found the XEN_TARGET_ARCH setting in the makefile which looks like
> setting it to x86_64 might be the right direction, but I'm trying to
> determine if there's an "official" way of doing it.

That is the official way of doing 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 Sep 25 16:35:06 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 16:35: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 1TGY5w-0002ji-8b; Tue, 25 Sep 2012 16:34:48 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1TGY5u-0002ja-HF
	for xen-devel@lists.xen.org; Tue, 25 Sep 2012 16:34:46 +0000
Received: from [85.158.138.51:16643] by server-9.bemta-3.messagelabs.com id
	A7/C3-15390-52DD1605; Tue, 25 Sep 2012 16:34:45 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1348590884!25597916!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTEwNzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16927 invoked from network); 25 Sep 2012 16:34:45 -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;
	25 Sep 2012 16:34:45 -0000
X-IronPort-AV: E=Sophos;i="4.80,484,1344211200"; d="scan'208";a="14756506"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Sep 2012 16:33: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.279.1;
	Tue, 25 Sep 2012 17:33:35 +0100
Message-ID: <1348590813.12592.20.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Anthony Wright <anthony@overnetdata.com>
Date: Tue, 25 Sep 2012 17:33:33 +0100
In-Reply-To: <5061DC3A.7070704@overnetdata.com>
References: <50607CCF.9050904@overnetdata.com> <506095D3.8090907@citrix.com>
	<1348561254.3452.103.camel@zakaz.uk.xensource.com>
	<5061DC3A.7070704@overnetdata.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-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] First DomU started goes into a busy loop
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 2012-09-25 at 17:30 +0100, Anthony Wright wrote:
> On 25/09/2012 09:20, Ian Campbell wrote:
> > (putting Anthony back on the CC)
> >
> > On Mon, 2012-09-24 at 18:18 +0100, Andrew Cooper wrote:
> >> 32bit builds of Xen have been removed from 4.3.  As far as I am aware,
> >> there has been no serious effort to maintain them.  I highly suggest
> >> using a 64bit Xen.
> > Anthony's references to 32-bit all seem to be in the context of the
> > Linux kernel.
> >
> > Just to be clear we have removed support for the 32-bit hypervisor only.
> > We have not and will not be removing support for 32-bit (PAE) PV
> > domains, running as either guest or dom0 on a 64-bit hypervisor. 32-bit
> > HVM guests, with or without PAE enabled, also remain fully supported.
> >
> > Ian.
> >
> Could you give me some pointers regarding building a 64 bit Xen
> hypervisor on a 32 bit linux system, or do I need to build it on a 64
> bit system?
> 
> I've found the XEN_TARGET_ARCH setting in the makefile which looks like
> setting it to x86_64 might be the right direction, but I'm trying to
> determine if there's an "official" way of doing it.

That is the official way of doing 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 Sep 25 16:35:31 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 16:35:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGY6O-0002nP-Qq; Tue, 25 Sep 2012 16:35:16 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1TGY6N-0002nD-Iv
	for xen-devel@lists.xen.org; Tue, 25 Sep 2012 16:35:15 +0000
Received: from [85.158.143.99:16712] by server-2.bemta-4.messagelabs.com id
	BF/1B-06610-24DD1605; Tue, 25 Sep 2012 16:35:14 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1348590912!25614339!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzEyNDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22596 invoked from network); 25 Sep 2012 16:35:13 -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;
	25 Sep 2012 16:35:13 -0000
X-IronPort-AV: E=Sophos;i="4.80,484,1344211200"; d="scan'208";a="39113857"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Sep 2012 16:35:10 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1;
	Tue, 25 Sep 2012 12:35:10 -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 1TGY6I-0000Vw-7q;
	Tue, 25 Sep 2012 17:35:10 +0100
Message-ID: <5061DD3E.8080002@citrix.com>
Date: Tue, 25 Sep 2012 17:35:10 +0100
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120912 Thunderbird/15.0.1
MIME-Version: 1.0
To: Anthony Wright <anthony@overnetdata.com>
References: <50607CCF.9050904@overnetdata.com> <506095D3.8090907@citrix.com>
	<1348561254.3452.103.camel@zakaz.uk.xensource.com>
	<5061DC3A.7070704@overnetdata.com>
In-Reply-To: <5061DC3A.7070704@overnetdata.com>
X-Enigmail-Version: 1.4.4
Cc: Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] First DomU started goes into a busy loop
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


On 25/09/12 17:30, Anthony Wright wrote:
> On 25/09/2012 09:20, Ian Campbell wrote:
>> (putting Anthony back on the CC)
>>
>> On Mon, 2012-09-24 at 18:18 +0100, Andrew Cooper wrote:
>>> 32bit builds of Xen have been removed from 4.3.  As far as I am aware,
>>> there has been no serious effort to maintain them.  I highly suggest
>>> using a 64bit Xen.
>> Anthony's references to 32-bit all seem to be in the context of the
>> Linux kernel.
>>
>> Just to be clear we have removed support for the 32-bit hypervisor only.
>> We have not and will not be removing support for 32-bit (PAE) PV
>> domains, running as either guest or dom0 on a 64-bit hypervisor. 32-bit
>> HVM guests, with or without PAE enabled, also remain fully supported.
>>
>> Ian.
>>
> Could you give me some pointers regarding building a 64 bit Xen
> hypervisor on a 32 bit linux system, or do I need to build it on a 64
> bit system?
>
> I've found the XEN_TARGET_ARCH setting in the makefile which looks like
> setting it to x86_64 might be the right direction, but I'm trying to
> determine if there's an "official" way of doing it.
>
> thanks,
>
> Anthony.

That is indeed the official way of doing it, with an optional
CROSS_COMPILE= prefix if your system gcc can only do 32bit.

-- 
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 Sep 25 16:35:31 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 16:35:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGY6O-0002nP-Qq; Tue, 25 Sep 2012 16:35:16 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1TGY6N-0002nD-Iv
	for xen-devel@lists.xen.org; Tue, 25 Sep 2012 16:35:15 +0000
Received: from [85.158.143.99:16712] by server-2.bemta-4.messagelabs.com id
	BF/1B-06610-24DD1605; Tue, 25 Sep 2012 16:35:14 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1348590912!25614339!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzEyNDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22596 invoked from network); 25 Sep 2012 16:35:13 -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;
	25 Sep 2012 16:35:13 -0000
X-IronPort-AV: E=Sophos;i="4.80,484,1344211200"; d="scan'208";a="39113857"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Sep 2012 16:35:10 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1;
	Tue, 25 Sep 2012 12:35:10 -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 1TGY6I-0000Vw-7q;
	Tue, 25 Sep 2012 17:35:10 +0100
Message-ID: <5061DD3E.8080002@citrix.com>
Date: Tue, 25 Sep 2012 17:35:10 +0100
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120912 Thunderbird/15.0.1
MIME-Version: 1.0
To: Anthony Wright <anthony@overnetdata.com>
References: <50607CCF.9050904@overnetdata.com> <506095D3.8090907@citrix.com>
	<1348561254.3452.103.camel@zakaz.uk.xensource.com>
	<5061DC3A.7070704@overnetdata.com>
In-Reply-To: <5061DC3A.7070704@overnetdata.com>
X-Enigmail-Version: 1.4.4
Cc: Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] First DomU started goes into a busy loop
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


On 25/09/12 17:30, Anthony Wright wrote:
> On 25/09/2012 09:20, Ian Campbell wrote:
>> (putting Anthony back on the CC)
>>
>> On Mon, 2012-09-24 at 18:18 +0100, Andrew Cooper wrote:
>>> 32bit builds of Xen have been removed from 4.3.  As far as I am aware,
>>> there has been no serious effort to maintain them.  I highly suggest
>>> using a 64bit Xen.
>> Anthony's references to 32-bit all seem to be in the context of the
>> Linux kernel.
>>
>> Just to be clear we have removed support for the 32-bit hypervisor only.
>> We have not and will not be removing support for 32-bit (PAE) PV
>> domains, running as either guest or dom0 on a 64-bit hypervisor. 32-bit
>> HVM guests, with or without PAE enabled, also remain fully supported.
>>
>> Ian.
>>
> Could you give me some pointers regarding building a 64 bit Xen
> hypervisor on a 32 bit linux system, or do I need to build it on a 64
> bit system?
>
> I've found the XEN_TARGET_ARCH setting in the makefile which looks like
> setting it to x86_64 might be the right direction, but I'm trying to
> determine if there's an "official" way of doing it.
>
> thanks,
>
> Anthony.

That is indeed the official way of doing it, with an optional
CROSS_COMPILE= prefix if your system gcc can only do 32bit.

-- 
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 Sep 25 16:57:37 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 16:57:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGYRk-0003K8-Qw; Tue, 25 Sep 2012 16:57: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 1TGYRj-0003K3-0L
	for xen-devel@lists.xensource.com; Tue, 25 Sep 2012 16:57:19 +0000
Received: from [85.158.139.211:63055] by server-15.bemta-5.messagelabs.com id
	E2/81-19430-E62E1605; Tue, 25 Sep 2012 16:57:18 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-206.messagelabs.com!1348592237!19915297!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTEwNzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16024 invoked from network); 25 Sep 2012 16:57:17 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Sep 2012 16:57:17 -0000
X-IronPort-AV: E=Sophos;i="4.80,484,1344211200"; d="scan'208";a="14757090"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Sep 2012 16:57: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.279.1; Tue, 25 Sep 2012 17:57: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 1TGYRg-0001WW-Hz;
	Tue, 25 Sep 2012 16:57:16 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1TGYRg-0005L0-42;
	Tue, 25 Sep 2012 17:57:16 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-13864-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Tue, 25 Sep 2012 17:57:16 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.1-testing test] 13864: 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 13864 xen-4.1-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13864/

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-pv            3 host-install(3)         broken REGR. vs. 13820
 test-amd64-i386-xl            3 host-install(3)         broken REGR. vs. 13820
 test-amd64-i386-xend-winxpsp3  3 host-install(3)        broken REGR. vs. 13820
 test-i386-i386-xl-win         3 host-install(3)         broken REGR. vs. 13820

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-pcipt-intel  8 debian-fixup                fail like 13820
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 13820

Tests which did not succeed, but are not blocking:
 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-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 13 guest-stop               fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel 11 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-win          16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 13 guest-stop             fail never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-i386-i386-xl-qemuu-winxpsp3 13 guest-stop                 fail never pass

version targeted for testing:
 xen                  fb0561ba7d9e
baseline version:
 xen                  6a17d5f11d66

------------------------------------------------------------
People who touched revisions under test:
  Dan Magenheimer <dan.magenheimer@oracle.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Jonathan Tripathy <jonnyt@abpni.co.uk>
  Keir Fraser <keir@xen.org>
  Zhenzhong Duan <zhenzhong.duan@oracle.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                                           broken  
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           broken  
 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                                        broken  
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                broken  
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
changeset:   23377:fb0561ba7d9e
tag:         tip
user:        Zhenzhong Duan <zhenzhong.duan@oracle.com>
date:        Tue Sep 25 12:29:29 2012 +0200
    
    tmem: bump pool version to 1 to fix restore issue when tmem enabled
    
    Restore fails when tmem is enabled both in hypervisor and guest. This
    is due to spec version mismatch when restoring a pool.
    
    Signed-off-by: Zhenzhong Duan <zhenzhong.duan@oracle.com>
    Acked-by: Dan Magenheimer <dan.magenheimer@oracle.com>
    xen-unstable changeset: 25929:fee83ac77d8c
    xen-unstable date: Wed Sep 19 15:38:47 UTC 2012
    
    
changeset:   23376:0c3286621912
user:        Jan Beulich <jbeulich@suse.com>
date:        Tue Sep 25 12:28:56 2012 +0200
    
    tmem: cleanup
    
    - one more case of checking for a specific rather than any error
    - drop redundant casts
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Dan Magenheimer <dan.magenheimer@oracle.com>
    xen-unstable changeset: 25860:e4cb84111610
    xen-unstable date: Tue Sep 11 12:19:29 UTC 2012
    
    
changeset:   23375:00ff640ebc7b
user:        Dan Magenheimer <dan.magenheimer@oracle.com>
date:        Tue Sep 25 12:28:24 2012 +0200
    
    tmem: fixup 2010 cleanup patch that breaks tmem save/restore
    
    20918:a3fa6d444b25 "Fix domain reference leaks" (in Feb 2010, by Jan)
    does some cleanup in addition to the leak fixes.  Unfortunately, that
    cleanup inadvertently resulted in an incorrect fallthrough in a switch
    statement which breaks tmem save/restore.
    
    That broken patch was apparently applied to 4.0-testing and 4.1-testing
    so those are broken as well.
    
    What is the process now for requesting back-patches to 4.0 and 4.1?
    
    (Side note: This does not by itself entirely fix save/restore in 4.2.)
    
    Signed-off-by: Dan Magenheimer <dan.magenheimer@oracle.com>
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    xen-unstable changeset: 25859:16e0392c6594
    xen-unstable date: Tue Sep 11 12:19:03 UTC 2012
    
    
changeset:   23374:5a3829c943ff
user:        Jan Beulich <jbeulich@suse.com>
date:        Tue Sep 25 12:27:50 2012 +0200
    
    tmem: reduce severity of log messages
    
    Otherwise they can be used by a guest to spam the hypervisor log with
    all settings at their defaults.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Zhenzhong Duan <zhenzhong.duan@oracle.com>
    xen-unstable changeset: 25858:0520982a602a
    xen-unstable date: Tue Sep 11 12:18:36 UTC 2012
    
    
changeset:   23373:91bf384afc83
user:        Jan Beulich <jbeulich@suse.com>
date:        Tue Sep 25 12:27:21 2012 +0200
    
    tmem: properly drop lock on error path in do_tmem_op()
    
    Reported-by: Tim Deegan <tim@xen.org>
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Dan Magenheimer <dan.magenheimer@oracle.com>
    xen-unstable changeset: 25857:109ea6a0c23a
    xen-unstable date: Tue Sep 11 12:18:26 UTC 2012
    
    
changeset:   23372:397cac9587fe
user:        Jan Beulich <jbeulich@suse.com>
date:        Tue Sep 25 12:26:57 2012 +0200
    
    tmem: properly drop lock on error path in do_tmem_get()
    
    Also remove a bogus assertion.
    
    Reported-by: Tim Deegan <tim@xen.org>
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Dan Magenheimer <dan.magenheimer@oracle.com>
    xen-unstable changeset: 25856:83b97a59888b
    xen-unstable date: Tue Sep 11 12:18:08 UTC 2012
    
    
changeset:   23371:2cce0490a260
user:        Jan Beulich <jbeulich@suse.com>
date:        Tue Sep 25 12:26:29 2012 +0200
    
    tmem: detect arithmetic overflow in tmh_copy_{from,to}_client()
    
    This implies adjusting callers to deal with errors other than -EFAULT
    and removing some comments which would otherwise become stale.
    
    Reported-by: Tim Deegan <tim@xen.org>
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Dan Magenheimer <dan.magenheimer@oracle.com>
    xen-unstable changeset: 25855:33b8c42a87ec
    xen-unstable date: Tue Sep 11 12:17:59 UTC 2012
    
    
changeset:   23370:122caf666c0c
user:        Jan Beulich <jbeulich@suse.com>
date:        Tue Sep 25 12:26:06 2012 +0200
    
    tmem: don't access guest memory without using the accessors intended for this
    
    This is not permitted, not even for buffers coming from Dom0 (and it
    would also break the moment Dom0 runs in HVM mode). An implication from
    the changes here is that tmh_copy_page() can't be used anymore for
    control operations calling tmh_copy_{from,to}_client() (as those pass
    the buffer by virtual address rather than MFN).
    
    Note that tmemc_save_get_next_page() previously didn't set the returned
    handle's pool_id field, while the new code does. It need to be
    confirmed that this is not a problem (otherwise the copy-out operation
    will require further tmh_...() abstractions to be added).
    
    Further note that the patch removes (rather than adjusts) an invalid
    call to unmap_domain_page() (no matching map_domain_page()) from
    tmh_compress_from_client() and adds a missing one to an error return
    path in tmh_copy_from_client().
    
    Finally note that the patch adds a previously missing return statement
    to cli_get_page() (without which that function could de-reference a
    NULL pointer, triggerable from guest mode).
    
    This is part of XSA-15 / CVE-2012-3497.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Dan Magenheimer <dan.magenheimer@oracle.com>
    xen-unstable changeset: 25854:ccd60ed6c555
    xen-unstable date: Tue Sep 11 12:17:49 UTC 2012
    
    
changeset:   23369:8dba0836f71b
user:        Ian Campbell <ian.campbell@citrix.com>
date:        Tue Sep 25 12:25:25 2012 +0200
    
    tmem: check for a valid client ("domain") in the save subops
    
    This is part of XSA-15 / CVE-2012-3497.
    
    Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
    Acked-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Dan Magenheimer <dan.magenheimer@oracle.com>
    xen-unstable changeset: 25853:f53c5aadbba9
    xen-unstable date: Tue Sep 11 12:17:27 UTC 2012
    
    
changeset:   23368:6f61607a074b
user:        Ian Campbell <ian.campbell@citrix.com>
date:        Tue Sep 25 12:24:57 2012 +0200
    
    tmem: check the pool_id is valid when destroying a tmem pool
    
    This is part of XSA-15 / CVE-2012-3497.
    
    Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
    Acked-by: Dan Magenheimer <dan.magenheimer@oracle.com>
    Acked-by: Jan Beulich <jbeulich@suse.com>
    xen-unstable changeset: 25852:d189d99ef00c
    xen-unstable date: Tue Sep 11 12:06:54 UTC 2012
    
    
changeset:   23367:805f0ba5e11b
user:        Ian Campbell <ian.campbell@citrix.com>
date:        Tue Sep 25 12:24:37 2012 +0200
    
    tmem: consistently make pool_id a uint32_t
    
    Treating it as an int could allow a malicious guest to provide a
    negative pool_Id, by passing the MAX_POOLS_PER_DOMAIN limit check and
    allowing access to the negative offsets of the pool array.
    
    This is part of XSA-15 / CVE-2012-3497.
    
    Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
    Acked-by: Dan Magenheimer <dan.magenheimer@oracle.com>
    Acked-by: Jan Beulich <jbeulich@suse.com>
    xen-unstable changeset: 25851:fcf567acc92a
    xen-unstable date: Tue Sep 11 12:06:43 UTC 2012
    
    
changeset:   23366:240b1de53095
user:        Ian Campbell <ian.campbell@citrix.com>
date:        Tue Sep 25 12:24:06 2012 +0200
    
    tmem: only allow tmem control operations from privileged domains
    
    This is part of XSA-15 / CVE-2012-3497.
    
    Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
    Acked-by: Dan Magenheimer <dan.magenheimer@oracle.com>
    Acked-by: Jan Beulich <jbeulich@suse.com>
    xen-unstable changeset: 25850:0dba5a888655
    xen-unstable date: Tue Sep 11 12:06:30 UTC 2012
    
    
changeset:   23365:6a17d5f11d66
user:        Keir Fraser <keir@xen.org>
date:        Thu Sep 20 11:01:04 2012 +0200
    
    x86: Prefer multiboot-provided e820 over bios-provided e801 memory info.
    
    Some UEFI systems do not provide e820 information. In this case we
    should take the detailed memory map provided by a multiboot-capable
    loader, rather than rely on very conservative values from the e801
    bios call. Using the latter on any modern system really hardly makes
    good sense.
    
    Signed-off-by: Keir Fraser <keir@xen.org>
    Tested-by: Jonathan Tripathy <jonnyt@abpni.co.uk>
    xen-unstable changeset: 25786:a0b5f8102a00
    xen-unstable date: Tue Aug 28 21:40:45 UTC 2012
    
    
========================================
commit d7d453f51459b591faa96d1c123b5bfff7c5b6b6
Author: Ian Jackson <ian.jackson@eu.citrix.com>
Date:   Thu Sep 6 17:05:30 2012 +0100

    Disable qemu monitor by default.  The qemu monitor is an overly
    powerful feature which must be protected from untrusted (guest)
    administrators.
    
    Neither xl nor xend expect qemu to produce this monitor unless it is
    explicitly requested.
    
    This is a security problem, XSA-19.  Previously it was CVE-2007-0998
    in Red Hat but we haven't dealt with it in upstream.  We hope to have
    a new CVE for it here but we don't have one yet.
    
    Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
    (cherry picked from commit bacc0d302445c75f18f4c826750fb5853b60e7ca)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 25 16:57:37 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 16:57:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGYRk-0003K8-Qw; Tue, 25 Sep 2012 16:57: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 1TGYRj-0003K3-0L
	for xen-devel@lists.xensource.com; Tue, 25 Sep 2012 16:57:19 +0000
Received: from [85.158.139.211:63055] by server-15.bemta-5.messagelabs.com id
	E2/81-19430-E62E1605; Tue, 25 Sep 2012 16:57:18 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-206.messagelabs.com!1348592237!19915297!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTEwNzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16024 invoked from network); 25 Sep 2012 16:57:17 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Sep 2012 16:57:17 -0000
X-IronPort-AV: E=Sophos;i="4.80,484,1344211200"; d="scan'208";a="14757090"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Sep 2012 16:57: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.279.1; Tue, 25 Sep 2012 17:57: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 1TGYRg-0001WW-Hz;
	Tue, 25 Sep 2012 16:57:16 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1TGYRg-0005L0-42;
	Tue, 25 Sep 2012 17:57:16 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-13864-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Tue, 25 Sep 2012 17:57:16 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.1-testing test] 13864: 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 13864 xen-4.1-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13864/

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-pv            3 host-install(3)         broken REGR. vs. 13820
 test-amd64-i386-xl            3 host-install(3)         broken REGR. vs. 13820
 test-amd64-i386-xend-winxpsp3  3 host-install(3)        broken REGR. vs. 13820
 test-i386-i386-xl-win         3 host-install(3)         broken REGR. vs. 13820

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-pcipt-intel  8 debian-fixup                fail like 13820
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 13820

Tests which did not succeed, but are not blocking:
 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-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 13 guest-stop               fail never pass
 test-amd64-i386-qemuu-rhel6hvm-intel 11 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-win          16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 13 guest-stop             fail never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-i386-i386-xl-qemuu-winxpsp3 13 guest-stop                 fail never pass

version targeted for testing:
 xen                  fb0561ba7d9e
baseline version:
 xen                  6a17d5f11d66

------------------------------------------------------------
People who touched revisions under test:
  Dan Magenheimer <dan.magenheimer@oracle.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Jonathan Tripathy <jonnyt@abpni.co.uk>
  Keir Fraser <keir@xen.org>
  Zhenzhong Duan <zhenzhong.duan@oracle.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                                           broken  
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-i386-qemuu-rhel6hvm-amd                           fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           broken  
 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                                        broken  
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                broken  
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
changeset:   23377:fb0561ba7d9e
tag:         tip
user:        Zhenzhong Duan <zhenzhong.duan@oracle.com>
date:        Tue Sep 25 12:29:29 2012 +0200
    
    tmem: bump pool version to 1 to fix restore issue when tmem enabled
    
    Restore fails when tmem is enabled both in hypervisor and guest. This
    is due to spec version mismatch when restoring a pool.
    
    Signed-off-by: Zhenzhong Duan <zhenzhong.duan@oracle.com>
    Acked-by: Dan Magenheimer <dan.magenheimer@oracle.com>
    xen-unstable changeset: 25929:fee83ac77d8c
    xen-unstable date: Wed Sep 19 15:38:47 UTC 2012
    
    
changeset:   23376:0c3286621912
user:        Jan Beulich <jbeulich@suse.com>
date:        Tue Sep 25 12:28:56 2012 +0200
    
    tmem: cleanup
    
    - one more case of checking for a specific rather than any error
    - drop redundant casts
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Dan Magenheimer <dan.magenheimer@oracle.com>
    xen-unstable changeset: 25860:e4cb84111610
    xen-unstable date: Tue Sep 11 12:19:29 UTC 2012
    
    
changeset:   23375:00ff640ebc7b
user:        Dan Magenheimer <dan.magenheimer@oracle.com>
date:        Tue Sep 25 12:28:24 2012 +0200
    
    tmem: fixup 2010 cleanup patch that breaks tmem save/restore
    
    20918:a3fa6d444b25 "Fix domain reference leaks" (in Feb 2010, by Jan)
    does some cleanup in addition to the leak fixes.  Unfortunately, that
    cleanup inadvertently resulted in an incorrect fallthrough in a switch
    statement which breaks tmem save/restore.
    
    That broken patch was apparently applied to 4.0-testing and 4.1-testing
    so those are broken as well.
    
    What is the process now for requesting back-patches to 4.0 and 4.1?
    
    (Side note: This does not by itself entirely fix save/restore in 4.2.)
    
    Signed-off-by: Dan Magenheimer <dan.magenheimer@oracle.com>
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    xen-unstable changeset: 25859:16e0392c6594
    xen-unstable date: Tue Sep 11 12:19:03 UTC 2012
    
    
changeset:   23374:5a3829c943ff
user:        Jan Beulich <jbeulich@suse.com>
date:        Tue Sep 25 12:27:50 2012 +0200
    
    tmem: reduce severity of log messages
    
    Otherwise they can be used by a guest to spam the hypervisor log with
    all settings at their defaults.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Zhenzhong Duan <zhenzhong.duan@oracle.com>
    xen-unstable changeset: 25858:0520982a602a
    xen-unstable date: Tue Sep 11 12:18:36 UTC 2012
    
    
changeset:   23373:91bf384afc83
user:        Jan Beulich <jbeulich@suse.com>
date:        Tue Sep 25 12:27:21 2012 +0200
    
    tmem: properly drop lock on error path in do_tmem_op()
    
    Reported-by: Tim Deegan <tim@xen.org>
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Dan Magenheimer <dan.magenheimer@oracle.com>
    xen-unstable changeset: 25857:109ea6a0c23a
    xen-unstable date: Tue Sep 11 12:18:26 UTC 2012
    
    
changeset:   23372:397cac9587fe
user:        Jan Beulich <jbeulich@suse.com>
date:        Tue Sep 25 12:26:57 2012 +0200
    
    tmem: properly drop lock on error path in do_tmem_get()
    
    Also remove a bogus assertion.
    
    Reported-by: Tim Deegan <tim@xen.org>
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Dan Magenheimer <dan.magenheimer@oracle.com>
    xen-unstable changeset: 25856:83b97a59888b
    xen-unstable date: Tue Sep 11 12:18:08 UTC 2012
    
    
changeset:   23371:2cce0490a260
user:        Jan Beulich <jbeulich@suse.com>
date:        Tue Sep 25 12:26:29 2012 +0200
    
    tmem: detect arithmetic overflow in tmh_copy_{from,to}_client()
    
    This implies adjusting callers to deal with errors other than -EFAULT
    and removing some comments which would otherwise become stale.
    
    Reported-by: Tim Deegan <tim@xen.org>
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Dan Magenheimer <dan.magenheimer@oracle.com>
    xen-unstable changeset: 25855:33b8c42a87ec
    xen-unstable date: Tue Sep 11 12:17:59 UTC 2012
    
    
changeset:   23370:122caf666c0c
user:        Jan Beulich <jbeulich@suse.com>
date:        Tue Sep 25 12:26:06 2012 +0200
    
    tmem: don't access guest memory without using the accessors intended for this
    
    This is not permitted, not even for buffers coming from Dom0 (and it
    would also break the moment Dom0 runs in HVM mode). An implication from
    the changes here is that tmh_copy_page() can't be used anymore for
    control operations calling tmh_copy_{from,to}_client() (as those pass
    the buffer by virtual address rather than MFN).
    
    Note that tmemc_save_get_next_page() previously didn't set the returned
    handle's pool_id field, while the new code does. It need to be
    confirmed that this is not a problem (otherwise the copy-out operation
    will require further tmh_...() abstractions to be added).
    
    Further note that the patch removes (rather than adjusts) an invalid
    call to unmap_domain_page() (no matching map_domain_page()) from
    tmh_compress_from_client() and adds a missing one to an error return
    path in tmh_copy_from_client().
    
    Finally note that the patch adds a previously missing return statement
    to cli_get_page() (without which that function could de-reference a
    NULL pointer, triggerable from guest mode).
    
    This is part of XSA-15 / CVE-2012-3497.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Dan Magenheimer <dan.magenheimer@oracle.com>
    xen-unstable changeset: 25854:ccd60ed6c555
    xen-unstable date: Tue Sep 11 12:17:49 UTC 2012
    
    
changeset:   23369:8dba0836f71b
user:        Ian Campbell <ian.campbell@citrix.com>
date:        Tue Sep 25 12:25:25 2012 +0200
    
    tmem: check for a valid client ("domain") in the save subops
    
    This is part of XSA-15 / CVE-2012-3497.
    
    Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
    Acked-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Dan Magenheimer <dan.magenheimer@oracle.com>
    xen-unstable changeset: 25853:f53c5aadbba9
    xen-unstable date: Tue Sep 11 12:17:27 UTC 2012
    
    
changeset:   23368:6f61607a074b
user:        Ian Campbell <ian.campbell@citrix.com>
date:        Tue Sep 25 12:24:57 2012 +0200
    
    tmem: check the pool_id is valid when destroying a tmem pool
    
    This is part of XSA-15 / CVE-2012-3497.
    
    Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
    Acked-by: Dan Magenheimer <dan.magenheimer@oracle.com>
    Acked-by: Jan Beulich <jbeulich@suse.com>
    xen-unstable changeset: 25852:d189d99ef00c
    xen-unstable date: Tue Sep 11 12:06:54 UTC 2012
    
    
changeset:   23367:805f0ba5e11b
user:        Ian Campbell <ian.campbell@citrix.com>
date:        Tue Sep 25 12:24:37 2012 +0200
    
    tmem: consistently make pool_id a uint32_t
    
    Treating it as an int could allow a malicious guest to provide a
    negative pool_Id, by passing the MAX_POOLS_PER_DOMAIN limit check and
    allowing access to the negative offsets of the pool array.
    
    This is part of XSA-15 / CVE-2012-3497.
    
    Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
    Acked-by: Dan Magenheimer <dan.magenheimer@oracle.com>
    Acked-by: Jan Beulich <jbeulich@suse.com>
    xen-unstable changeset: 25851:fcf567acc92a
    xen-unstable date: Tue Sep 11 12:06:43 UTC 2012
    
    
changeset:   23366:240b1de53095
user:        Ian Campbell <ian.campbell@citrix.com>
date:        Tue Sep 25 12:24:06 2012 +0200
    
    tmem: only allow tmem control operations from privileged domains
    
    This is part of XSA-15 / CVE-2012-3497.
    
    Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
    Acked-by: Dan Magenheimer <dan.magenheimer@oracle.com>
    Acked-by: Jan Beulich <jbeulich@suse.com>
    xen-unstable changeset: 25850:0dba5a888655
    xen-unstable date: Tue Sep 11 12:06:30 UTC 2012
    
    
changeset:   23365:6a17d5f11d66
user:        Keir Fraser <keir@xen.org>
date:        Thu Sep 20 11:01:04 2012 +0200
    
    x86: Prefer multiboot-provided e820 over bios-provided e801 memory info.
    
    Some UEFI systems do not provide e820 information. In this case we
    should take the detailed memory map provided by a multiboot-capable
    loader, rather than rely on very conservative values from the e801
    bios call. Using the latter on any modern system really hardly makes
    good sense.
    
    Signed-off-by: Keir Fraser <keir@xen.org>
    Tested-by: Jonathan Tripathy <jonnyt@abpni.co.uk>
    xen-unstable changeset: 25786:a0b5f8102a00
    xen-unstable date: Tue Aug 28 21:40:45 UTC 2012
    
    
========================================
commit d7d453f51459b591faa96d1c123b5bfff7c5b6b6
Author: Ian Jackson <ian.jackson@eu.citrix.com>
Date:   Thu Sep 6 17:05:30 2012 +0100

    Disable qemu monitor by default.  The qemu monitor is an overly
    powerful feature which must be protected from untrusted (guest)
    administrators.
    
    Neither xl nor xend expect qemu to produce this monitor unless it is
    explicitly requested.
    
    This is a security problem, XSA-19.  Previously it was CVE-2007-0998
    in Red Hat but we haven't dealt with it in upstream.  We hope to have
    a new CVE for it here but we don't have one yet.
    
    Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
    (cherry picked from commit bacc0d302445c75f18f4c826750fb5853b60e7ca)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 25 16:59:42 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 16:59: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 1TGYTj-0003Pn-Bb; Tue, 25 Sep 2012 16:59:23 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <matthew.fioravante@jhuapl.edu>) id 1TGYTh-0003Pf-K5
	for xen-devel@lists.xensource.com; Tue, 25 Sep 2012 16:59:21 +0000
Received: from [85.158.139.211:15946] by server-3.bemta-5.messagelabs.com id
	82/3B-16108-8E2E1605; Tue, 25 Sep 2012 16:59:20 +0000
X-Env-Sender: matthew.fioravante@jhuapl.edu
X-Msg-Ref: server-16.tower-206.messagelabs.com!1348592358!19960536!1
X-Originating-IP: [128.244.251.36]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG,
	UNPARSEABLE_RELAY
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14265 invoked from network); 25 Sep 2012 16:59:19 -0000
Received: from pilot.jhuapl.edu (HELO jhuapl.edu) (128.244.251.36)
	by server-16.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 25 Sep 2012 16:59:19 -0000
Received: from ([128.244.207.89])
	by pilot.jhuapl.edu with ESMTP with TLS id 63GHCH1.153623978;
	Tue, 25 Sep 2012 12:59:13 -0400
Message-ID: <5061E293.7000106@jhuapl.edu>
Date: Tue, 25 Sep 2012 12:57:55 -0400
From: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120827 Thunderbird/15.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <505CBA02.5040308@jhuapl.edu>
	<1348569044.3452.176.camel@zakaz.uk.xensource.com>
In-Reply-To: <1348569044.3452.176.camel@zakaz.uk.xensource.com>
X-Enigmail-Version: 1.4.4
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] PATCH [base vtpm and libxl patches 4/6] add iomem
 support to libxl
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============3628728076835693966=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a cryptographically signed message in MIME format.

--===============3628728076835693966==
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms070705040602070303010407"

This is a cryptographically signed message in MIME format.

--------------ms070705040602070303010407
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 09/25/2012 06:30 AM, Ian Campbell wrote:
> On Fri, 2012-09-21 at 20:03 +0100, Matthew Fioravante wrote:
>
>> +        if ( ret<0 ){
> Tiny coding style nit, this should be
> 	if (ret < 0) {=20
Will fix
>> +            LOGE(ERROR,
>> +                 "failed give dom%d access to iomem range
>> %"PRIx64"-%"PRIx64,
>> +                 domid, io->start, io->start + io->number - 1);
>> +            ret =3D ERROR_FAIL;
>> +        }
>> +    }
>> +
>> +
>> +
>>      for (i =3D 0; i < d_config->num_nics; i++) {
>>          /* We have to init the nic here, because we still haven't
>>           * called libxl_device_nic_add at this point, but qemu needs
>> @@ -1005,6 +1005,30 @@ static void parse_config_data(const char
>> *config_source,
>>          }
>>      }
>> =20
>> +    if (!xlu_cfg_get_list(config, "iomem", &iomem, &num_iomem, 0)) {
>> +        b_info->num_iomem =3D num_iomem;
>> +        b_info->iomem =3D calloc(num_iomem, sizeof(*b_info->iomem));
>> +        if (b_info->iomem =3D=3D NULL) {
>> +            fprintf(stderr, "unable to allocate memory for iomem\n");=

>> +            exit(-1);
>> +        }
>> +        for (i =3D 0; i < num_iomem; i++) {
>> +            buf =3D xlu_cfg_get_listitem (iomem, i);
>> +            if (!buf) {
>> +                fprintf(stderr,
>> +                        "xl: Unable to get element %d in iomem list\n=
", i);
>> +                exit(1);
>> +            }
>> +            if(sscanf(buf, "%" SCNx64",%" SCNu64,
>> &b_info->iomem[i].start, &b_info->iomem[i].number) !=3D 2) {
> This should be relatively simply to parse with strtoul (see the ioports=

> case) which would allow people to select hex or decimal in their
> configuration files.
Do we want to support hex or decimal? Pretty much anytime people start
talking about physical memory addresses or page numbers they use hex.
Also the ioports code actually only supports hexadecimal as it sets the
base in strtoul to 16. It also explicitly says in the xl.cfg manpage
that ioports should be given in hex.
>
> Ian
>



--------------ms070705040602070303010407
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIDyjCC
A8YwggMvoAMCAQICBD/xyf0wDQYJKoZIhvcNAQEFBQAwLzELMAkGA1UEBhMCVVMxDzANBgNV
BAoTBkpIVUFQTDEPMA0GA1UECxMGQklTRENBMB4XDTEwMDYxMTE4MjIwNloXDTEzMDYxMTE4
NTIwNlowZjELMAkGA1UEBhMCVVMxDzANBgNVBAoTBkpIVUFQTDEPMA0GA1UECxMGUGVvcGxl
MTUwFgYDVQQLEw9WUE5Hcm91cC1CSVNEQ0EwGwYDVQQDExRNYXR0aGV3IEUgRmlvcmF2YW50
ZTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAnpbwVSP6o1Nb5lcW7dd3yTo9iBJdi7qz
4nANOMFPK7JOy5npKN1iiousl28U/scUJES55gPwAWYJK3uVyQAsA4adgDKi5DoD1UHDQEwp
bY7iHLJeq0NPr4BqYNqnCFPbE6HC8zSJrr4qKn+gVUQT39SIFqdiIPJwZL8FYTRQ/zsCAwEA
AaOCAbYwggGyMAsGA1UdDwQEAwIHgDArBgNVHRAEJDAigA8yMDEwMDYxMTE4MjIwNlqBDzIw
MTIwNzE3MjI1MjA2WjAbBg0rBgEEAbMlCwMBAQEBBAoWCGZpb3JhbWUxMBsGDSsGAQQBsyUL
AwEBAQIEChIIMDAxMDQyNjEwWAYJYIZIAYb6ax4BBEsMSVRoZSBwcml2YXRlIGtleSBjb3Jy
ZXNwb25kaW5nIHRvIHRoaXMgY2VydGlmaWNhdGUgbWF5IGhhdmUgYmVlbiBleHBvcnRlZC4w
KAYDVR0RBCEwH4EdTWF0dGhldy5GaW9yYXZhbnRlQGpodWFwbC5lZHUwUgYDVR0fBEswSTBH
oEWgQ6RBMD8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJU0RD
QTEOMAwGA1UEAxMFQ1JMNTYwHwYDVR0jBBgwFoAUCDUpmxH52EU2CyWmF2EJMB1yqeswHQYD
VR0OBBYEFO6LYxg6r9wHZ+zdQtBHn1dZ/YTNMAkGA1UdEwQCMAAwGQYJKoZIhvZ9B0EABAww
ChsEVjcuMQMCBLAwDQYJKoZIhvcNAQEFBQADgYEAJO9HQh4YNChVLzuZqK5ARJARD8JoujGZ
fdo75quvg2jXFQe2sEjvLnxJZgm/pv8fdZakq48CWwjYHKuvIp7sDjTEsQfo+y7SpN/N2NvJ
WU5SqfK1VgYtNLRRoGJUB5Q1aZ+Dg95g3kqpyfpUMISJL8IKVLtJVfN4fggFVUYZ9wwxggGr
MIIBpwIBATA3MC8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJ
U0RDQQIEP/HJ/TAJBgUrDgMCGgUAoIHLMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ
KoZIhvcNAQkFMQ8XDTEyMDkyNTE2NTc1NVowIwYJKoZIhvcNAQkEMRYEFGRjqLrt7wxuetNe
Odrl331/YvQ3MGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAK
BggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI
KoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEgYANIZY+JGO+5wIuaFLz6k1EzjYMiLaKaR43
SZFJNwIQGHmVfD7firrj5rZ+35ohY12bZtcp8ZXzLEC8KF9+/9kpFipk25atc3PWWJPEds34
Dqk6S8FXil5BFMWz/tkz1julSP9fHjFbm0sPGjqTPQmHhRzYhjVx2+O2GnL6dQDLRgAAAAAA
AA==
--------------ms070705040602070303010407--


--===============3628728076835693966==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============3628728076835693966==--


From xen-devel-bounces@lists.xen.org Tue Sep 25 16:59:42 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 16:59: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 1TGYTj-0003Pn-Bb; Tue, 25 Sep 2012 16:59:23 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <matthew.fioravante@jhuapl.edu>) id 1TGYTh-0003Pf-K5
	for xen-devel@lists.xensource.com; Tue, 25 Sep 2012 16:59:21 +0000
Received: from [85.158.139.211:15946] by server-3.bemta-5.messagelabs.com id
	82/3B-16108-8E2E1605; Tue, 25 Sep 2012 16:59:20 +0000
X-Env-Sender: matthew.fioravante@jhuapl.edu
X-Msg-Ref: server-16.tower-206.messagelabs.com!1348592358!19960536!1
X-Originating-IP: [128.244.251.36]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG,
	UNPARSEABLE_RELAY
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14265 invoked from network); 25 Sep 2012 16:59:19 -0000
Received: from pilot.jhuapl.edu (HELO jhuapl.edu) (128.244.251.36)
	by server-16.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 25 Sep 2012 16:59:19 -0000
Received: from ([128.244.207.89])
	by pilot.jhuapl.edu with ESMTP with TLS id 63GHCH1.153623978;
	Tue, 25 Sep 2012 12:59:13 -0400
Message-ID: <5061E293.7000106@jhuapl.edu>
Date: Tue, 25 Sep 2012 12:57:55 -0400
From: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120827 Thunderbird/15.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <505CBA02.5040308@jhuapl.edu>
	<1348569044.3452.176.camel@zakaz.uk.xensource.com>
In-Reply-To: <1348569044.3452.176.camel@zakaz.uk.xensource.com>
X-Enigmail-Version: 1.4.4
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] PATCH [base vtpm and libxl patches 4/6] add iomem
 support to libxl
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============3628728076835693966=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a cryptographically signed message in MIME format.

--===============3628728076835693966==
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms070705040602070303010407"

This is a cryptographically signed message in MIME format.

--------------ms070705040602070303010407
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 09/25/2012 06:30 AM, Ian Campbell wrote:
> On Fri, 2012-09-21 at 20:03 +0100, Matthew Fioravante wrote:
>
>> +        if ( ret<0 ){
> Tiny coding style nit, this should be
> 	if (ret < 0) {=20
Will fix
>> +            LOGE(ERROR,
>> +                 "failed give dom%d access to iomem range
>> %"PRIx64"-%"PRIx64,
>> +                 domid, io->start, io->start + io->number - 1);
>> +            ret =3D ERROR_FAIL;
>> +        }
>> +    }
>> +
>> +
>> +
>>      for (i =3D 0; i < d_config->num_nics; i++) {
>>          /* We have to init the nic here, because we still haven't
>>           * called libxl_device_nic_add at this point, but qemu needs
>> @@ -1005,6 +1005,30 @@ static void parse_config_data(const char
>> *config_source,
>>          }
>>      }
>> =20
>> +    if (!xlu_cfg_get_list(config, "iomem", &iomem, &num_iomem, 0)) {
>> +        b_info->num_iomem =3D num_iomem;
>> +        b_info->iomem =3D calloc(num_iomem, sizeof(*b_info->iomem));
>> +        if (b_info->iomem =3D=3D NULL) {
>> +            fprintf(stderr, "unable to allocate memory for iomem\n");=

>> +            exit(-1);
>> +        }
>> +        for (i =3D 0; i < num_iomem; i++) {
>> +            buf =3D xlu_cfg_get_listitem (iomem, i);
>> +            if (!buf) {
>> +                fprintf(stderr,
>> +                        "xl: Unable to get element %d in iomem list\n=
", i);
>> +                exit(1);
>> +            }
>> +            if(sscanf(buf, "%" SCNx64",%" SCNu64,
>> &b_info->iomem[i].start, &b_info->iomem[i].number) !=3D 2) {
> This should be relatively simply to parse with strtoul (see the ioports=

> case) which would allow people to select hex or decimal in their
> configuration files.
Do we want to support hex or decimal? Pretty much anytime people start
talking about physical memory addresses or page numbers they use hex.
Also the ioports code actually only supports hexadecimal as it sets the
base in strtoul to 16. It also explicitly says in the xl.cfg manpage
that ioports should be given in hex.
>
> Ian
>



--------------ms070705040602070303010407
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIDyjCC
A8YwggMvoAMCAQICBD/xyf0wDQYJKoZIhvcNAQEFBQAwLzELMAkGA1UEBhMCVVMxDzANBgNV
BAoTBkpIVUFQTDEPMA0GA1UECxMGQklTRENBMB4XDTEwMDYxMTE4MjIwNloXDTEzMDYxMTE4
NTIwNlowZjELMAkGA1UEBhMCVVMxDzANBgNVBAoTBkpIVUFQTDEPMA0GA1UECxMGUGVvcGxl
MTUwFgYDVQQLEw9WUE5Hcm91cC1CSVNEQ0EwGwYDVQQDExRNYXR0aGV3IEUgRmlvcmF2YW50
ZTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAnpbwVSP6o1Nb5lcW7dd3yTo9iBJdi7qz
4nANOMFPK7JOy5npKN1iiousl28U/scUJES55gPwAWYJK3uVyQAsA4adgDKi5DoD1UHDQEwp
bY7iHLJeq0NPr4BqYNqnCFPbE6HC8zSJrr4qKn+gVUQT39SIFqdiIPJwZL8FYTRQ/zsCAwEA
AaOCAbYwggGyMAsGA1UdDwQEAwIHgDArBgNVHRAEJDAigA8yMDEwMDYxMTE4MjIwNlqBDzIw
MTIwNzE3MjI1MjA2WjAbBg0rBgEEAbMlCwMBAQEBBAoWCGZpb3JhbWUxMBsGDSsGAQQBsyUL
AwEBAQIEChIIMDAxMDQyNjEwWAYJYIZIAYb6ax4BBEsMSVRoZSBwcml2YXRlIGtleSBjb3Jy
ZXNwb25kaW5nIHRvIHRoaXMgY2VydGlmaWNhdGUgbWF5IGhhdmUgYmVlbiBleHBvcnRlZC4w
KAYDVR0RBCEwH4EdTWF0dGhldy5GaW9yYXZhbnRlQGpodWFwbC5lZHUwUgYDVR0fBEswSTBH
oEWgQ6RBMD8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJU0RD
QTEOMAwGA1UEAxMFQ1JMNTYwHwYDVR0jBBgwFoAUCDUpmxH52EU2CyWmF2EJMB1yqeswHQYD
VR0OBBYEFO6LYxg6r9wHZ+zdQtBHn1dZ/YTNMAkGA1UdEwQCMAAwGQYJKoZIhvZ9B0EABAww
ChsEVjcuMQMCBLAwDQYJKoZIhvcNAQEFBQADgYEAJO9HQh4YNChVLzuZqK5ARJARD8JoujGZ
fdo75quvg2jXFQe2sEjvLnxJZgm/pv8fdZakq48CWwjYHKuvIp7sDjTEsQfo+y7SpN/N2NvJ
WU5SqfK1VgYtNLRRoGJUB5Q1aZ+Dg95g3kqpyfpUMISJL8IKVLtJVfN4fggFVUYZ9wwxggGr
MIIBpwIBATA3MC8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJ
U0RDQQIEP/HJ/TAJBgUrDgMCGgUAoIHLMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ
KoZIhvcNAQkFMQ8XDTEyMDkyNTE2NTc1NVowIwYJKoZIhvcNAQkEMRYEFGRjqLrt7wxuetNe
Odrl331/YvQ3MGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAK
BggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI
KoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEgYANIZY+JGO+5wIuaFLz6k1EzjYMiLaKaR43
SZFJNwIQGHmVfD7firrj5rZ+35ohY12bZtcp8ZXzLEC8KF9+/9kpFipk25atc3PWWJPEds34
Dqk6S8FXil5BFMWz/tkz1julSP9fHjFbm0sPGjqTPQmHhRzYhjVx2+O2GnL6dQDLRgAAAAAA
AA==
--------------ms070705040602070303010407--


--===============3628728076835693966==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============3628728076835693966==--


From xen-devel-bounces@lists.xen.org Tue Sep 25 17:06:53 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 17:06:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGYag-0003ot-7s; Tue, 25 Sep 2012 17:06:34 +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 1TGYae-0003oo-Cx
	for xen-devel@lists.xen.org; Tue, 25 Sep 2012 17:06:32 +0000
Received: from [85.158.137.99:50621] by server-2.bemta-3.messagelabs.com id
	FF/95-04862-794E1605; Tue, 25 Sep 2012 17:06:31 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-13.tower-217.messagelabs.com!1348592790!19110980!1
X-Originating-IP: [74.125.83.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30415 invoked from network); 25 Sep 2012 17:06:31 -0000
Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com)
	(74.125.83.45)
	by server-13.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Sep 2012 17:06:31 -0000
Received: by eekb47 with SMTP id b47so1431794eek.32
	for <xen-devel@lists.xen.org>; Tue, 25 Sep 2012 10:06:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=ely6QACNIQ/nLI8EQyaH+sEWP+C7WswBB3bwLjxLdBY=;
	b=TNUYRf1jjAQVyk7nzLEonkQ/b1M4Vbl1o/9Wm781nDw6WfEjRoBna12D7kWcZEfJ3R
	aWZk6ROW+9y/86FR5PJSm7rwJA5KuAAHauajCiZ5xepP01j40GcipDcgMj51lnE6AEJx
	7UIBp9R+hTt02APNpvqzCjEg0NPf1Wg2sHQgGNkWyfRkecPQ+Xi2g90qROpTGOyAX3Jm
	+Uhv/TFQELxdVNcdfgoi0nuZ7hY2RKEQIJLaW41T2YYFdflVFmMfCITONNvXPjCWCESB
	SXdRr8FwJSKdEhD7M3oYdU+9erSlz87Vg9pWTOB0Vw2SLgReFDuQt6TdXMc6FXAHa1/b
	RXlQ==
Received: by 10.14.212.72 with SMTP id x48mr21513624eeo.40.1348592790747;
	Tue, 25 Sep 2012 10:06:30 -0700 (PDT)
Received: from [192.168.1.3] (host86-167-82-156.range86-167.btcentralplus.com.
	[86.167.82.156])
	by mx.google.com with ESMTPS id k41sm2420826eep.13.2012.09.25.10.06.24
	(version=SSLv3 cipher=OTHER); Tue, 25 Sep 2012 10:06:29 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.33.0.120411
Date: Tue, 25 Sep 2012 18:06:17 +0100
From: Keir Fraser <keir@xen.org>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <CC87A319.4CDD2%keir@xen.org>
Thread-Topic: [Xen-devel] [PATCH] x86: slightly improve stack trace on debug
	builds
Thread-Index: Ac2bQBNxsgPFijZEwUensymehOG/rQ==
In-Reply-To: <5061F5D7020000780009DC03@nat28.tlf.novell.com>
Mime-version: 1.0
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] x86: slightly improve stack trace on debug
 builds
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/09/2012 17:20, "Jan Beulich" <JBeulich@suse.com> wrote:

>> /*
>>  * If RIP is not valid hypervisor code then someone may have called into
>>  * oblivion. Peek to see if they left a return address at top of stack.
>>  */
>> addr = (!is_current_kernel_text(regs->eip) &&
>>         (ESP_BEFORE_EXCEPTION(regs) >= low) &&
>>         (ESP_BEFORE_EXCEPTION(regs) < high) &&
>>         is_current_kernel_text(*ESP_BEFORE_EXCEPTION(regs)))
>>        ? *ESP_BEFORE_EXCEPTION(regs) : regs->eip;
> 
> Checking against "low" is pointless, as that one is guaranteed
> lower than the stack pointer (unless the stack pointer was within
> 16 bytes from NULL). Checking against "high" is almost pointless
> too, as there's only a very small range where %rsp could have
> been to make that check fail (plus the 2 slots offset wouldn't be
> right in this special case, i.e. we could get a false negative here),
> and it wouldn't help preventing eventual #PF on the deref (since
> "high" and the possible window above are on the same page).

Ah of course low and high are derived from ESP_BEFORE_EXCEPTION... Okay,
then my extra checks are quite pointless as you say. Please leave them out
when you re-spin your patch.

 Thanks,
 Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 25 17:06:53 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 17:06:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGYag-0003ot-7s; Tue, 25 Sep 2012 17:06:34 +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 1TGYae-0003oo-Cx
	for xen-devel@lists.xen.org; Tue, 25 Sep 2012 17:06:32 +0000
Received: from [85.158.137.99:50621] by server-2.bemta-3.messagelabs.com id
	FF/95-04862-794E1605; Tue, 25 Sep 2012 17:06:31 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-13.tower-217.messagelabs.com!1348592790!19110980!1
X-Originating-IP: [74.125.83.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30415 invoked from network); 25 Sep 2012 17:06:31 -0000
Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com)
	(74.125.83.45)
	by server-13.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Sep 2012 17:06:31 -0000
Received: by eekb47 with SMTP id b47so1431794eek.32
	for <xen-devel@lists.xen.org>; Tue, 25 Sep 2012 10:06:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=ely6QACNIQ/nLI8EQyaH+sEWP+C7WswBB3bwLjxLdBY=;
	b=TNUYRf1jjAQVyk7nzLEonkQ/b1M4Vbl1o/9Wm781nDw6WfEjRoBna12D7kWcZEfJ3R
	aWZk6ROW+9y/86FR5PJSm7rwJA5KuAAHauajCiZ5xepP01j40GcipDcgMj51lnE6AEJx
	7UIBp9R+hTt02APNpvqzCjEg0NPf1Wg2sHQgGNkWyfRkecPQ+Xi2g90qROpTGOyAX3Jm
	+Uhv/TFQELxdVNcdfgoi0nuZ7hY2RKEQIJLaW41T2YYFdflVFmMfCITONNvXPjCWCESB
	SXdRr8FwJSKdEhD7M3oYdU+9erSlz87Vg9pWTOB0Vw2SLgReFDuQt6TdXMc6FXAHa1/b
	RXlQ==
Received: by 10.14.212.72 with SMTP id x48mr21513624eeo.40.1348592790747;
	Tue, 25 Sep 2012 10:06:30 -0700 (PDT)
Received: from [192.168.1.3] (host86-167-82-156.range86-167.btcentralplus.com.
	[86.167.82.156])
	by mx.google.com with ESMTPS id k41sm2420826eep.13.2012.09.25.10.06.24
	(version=SSLv3 cipher=OTHER); Tue, 25 Sep 2012 10:06:29 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.33.0.120411
Date: Tue, 25 Sep 2012 18:06:17 +0100
From: Keir Fraser <keir@xen.org>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <CC87A319.4CDD2%keir@xen.org>
Thread-Topic: [Xen-devel] [PATCH] x86: slightly improve stack trace on debug
	builds
Thread-Index: Ac2bQBNxsgPFijZEwUensymehOG/rQ==
In-Reply-To: <5061F5D7020000780009DC03@nat28.tlf.novell.com>
Mime-version: 1.0
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] x86: slightly improve stack trace on debug
 builds
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/09/2012 17:20, "Jan Beulich" <JBeulich@suse.com> wrote:

>> /*
>>  * If RIP is not valid hypervisor code then someone may have called into
>>  * oblivion. Peek to see if they left a return address at top of stack.
>>  */
>> addr = (!is_current_kernel_text(regs->eip) &&
>>         (ESP_BEFORE_EXCEPTION(regs) >= low) &&
>>         (ESP_BEFORE_EXCEPTION(regs) < high) &&
>>         is_current_kernel_text(*ESP_BEFORE_EXCEPTION(regs)))
>>        ? *ESP_BEFORE_EXCEPTION(regs) : regs->eip;
> 
> Checking against "low" is pointless, as that one is guaranteed
> lower than the stack pointer (unless the stack pointer was within
> 16 bytes from NULL). Checking against "high" is almost pointless
> too, as there's only a very small range where %rsp could have
> been to make that check fail (plus the 2 slots offset wouldn't be
> right in this special case, i.e. we could get a false negative here),
> and it wouldn't help preventing eventual #PF on the deref (since
> "high" and the possible window above are on the same page).

Ah of course low and high are derived from ESP_BEFORE_EXCEPTION... Okay,
then my extra checks are quite pointless as you say. Please leave them out
when you re-spin your patch.

 Thanks,
 Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 25 17:07:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 17: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 1TGYb6-0003rL-Ty; Tue, 25 Sep 2012 17:07:00 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1TGYb5-0003r6-Jp
	for xen-devel@lists.xen.org; Tue, 25 Sep 2012 17:06:59 +0000
Received: from [85.158.137.99:22748] by server-9.bemta-3.messagelabs.com id
	AB/75-15390-2B4E1605; Tue, 25 Sep 2012 17:06:58 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-13.tower-217.messagelabs.com!1348592790!19110980!2
X-Originating-IP: [74.125.83.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31003 invoked from network); 25 Sep 2012 17:06:58 -0000
Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com)
	(74.125.83.45)
	by server-13.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Sep 2012 17:06:58 -0000
Received: by mail-ee0-f45.google.com with SMTP id b47so1431794eek.32
	for <xen-devel@lists.xen.org>; Tue, 25 Sep 2012 10:06: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=ME8GzX5DdTfcpcL+XZbJd3z5yo4IdaYPkPvdi8kRBUY=;
	b=rEYz7TT5JOKJ2GFqNHz+xxs9CNww4EUDClqtQohHfX8iIzjkmHPAW4OprhbQhTshqh
	lnkjNLRqIWNn9kJqIkiY+L2YlA9MSl5dqXhmSAwtiXC9+zBcK04nlwmrAB/uoFS2+hqq
	mi8eq6Tbkjx3trkKHBFey8Pf+9yEzS7gy5C2sXfX+fq8ub+7Rv1KyBxu966qxtUSpVso
	9e6u+oxmpqM/eSCN0sNAeXuLVGPK0RcAG8UU7uO3aOZVXb7yNi0OiZYvN9uxSbz2kxFW
	q2cc+kPNZlhvHChcWCoOaQ2Cv5ikEpI98C0xoYdopMzeFThYpZ1aKEnIzQq1xvyyTTCr
	wAHw==
Received: by 10.14.211.3 with SMTP id v3mr21510730eeo.43.1348592818315;
	Tue, 25 Sep 2012 10:06:58 -0700 (PDT)
Received: from [192.168.1.3] (host86-167-82-156.range86-167.btcentralplus.com.
	[86.167.82.156])
	by mx.google.com with ESMTPS id k49sm2495745een.4.2012.09.25.10.06.55
	(version=SSLv3 cipher=OTHER); Tue, 25 Sep 2012 10:06:57 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.33.0.120411
Date: Tue, 25 Sep 2012 18:06:51 +0100
From: Keir Fraser <keir@xen.org>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <CC87A33B.4CDD3%keir@xen.org>
Thread-Topic: [Xen-devel] [PATCH] x86: slightly improve stack trace on debug
	builds
Thread-Index: Ac2bQCe16RcN93/91EmW61QV7OHC+g==
In-Reply-To: <5061F5D7020000780009DC03@nat28.tlf.novell.com>
Mime-version: 1.0
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] x86: slightly improve stack trace on debug
 builds
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/09/2012 17:20, "Jan Beulich" <JBeulich@suse.com> wrote:

>> Lol, how does your brain work this way? It took me 15 minutes to decode this
>> to something like (also I added range checks on ESP_BEFORE_EXCEPTION(regs),
>> what do you think?):
> 
> Sorry for this - just wanted to avoid having the condition evaluated
> (and spelled out) twice (and it took me a minute at most to find this
> iterate-at-most-twice solution).

It's the kind of code that is definitely easier to write than to read. ;-)



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 25 17:07:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 17: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 1TGYb6-0003rL-Ty; Tue, 25 Sep 2012 17:07:00 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1TGYb5-0003r6-Jp
	for xen-devel@lists.xen.org; Tue, 25 Sep 2012 17:06:59 +0000
Received: from [85.158.137.99:22748] by server-9.bemta-3.messagelabs.com id
	AB/75-15390-2B4E1605; Tue, 25 Sep 2012 17:06:58 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-13.tower-217.messagelabs.com!1348592790!19110980!2
X-Originating-IP: [74.125.83.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31003 invoked from network); 25 Sep 2012 17:06:58 -0000
Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com)
	(74.125.83.45)
	by server-13.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Sep 2012 17:06:58 -0000
Received: by mail-ee0-f45.google.com with SMTP id b47so1431794eek.32
	for <xen-devel@lists.xen.org>; Tue, 25 Sep 2012 10:06: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=ME8GzX5DdTfcpcL+XZbJd3z5yo4IdaYPkPvdi8kRBUY=;
	b=rEYz7TT5JOKJ2GFqNHz+xxs9CNww4EUDClqtQohHfX8iIzjkmHPAW4OprhbQhTshqh
	lnkjNLRqIWNn9kJqIkiY+L2YlA9MSl5dqXhmSAwtiXC9+zBcK04nlwmrAB/uoFS2+hqq
	mi8eq6Tbkjx3trkKHBFey8Pf+9yEzS7gy5C2sXfX+fq8ub+7Rv1KyBxu966qxtUSpVso
	9e6u+oxmpqM/eSCN0sNAeXuLVGPK0RcAG8UU7uO3aOZVXb7yNi0OiZYvN9uxSbz2kxFW
	q2cc+kPNZlhvHChcWCoOaQ2Cv5ikEpI98C0xoYdopMzeFThYpZ1aKEnIzQq1xvyyTTCr
	wAHw==
Received: by 10.14.211.3 with SMTP id v3mr21510730eeo.43.1348592818315;
	Tue, 25 Sep 2012 10:06:58 -0700 (PDT)
Received: from [192.168.1.3] (host86-167-82-156.range86-167.btcentralplus.com.
	[86.167.82.156])
	by mx.google.com with ESMTPS id k49sm2495745een.4.2012.09.25.10.06.55
	(version=SSLv3 cipher=OTHER); Tue, 25 Sep 2012 10:06:57 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.33.0.120411
Date: Tue, 25 Sep 2012 18:06:51 +0100
From: Keir Fraser <keir@xen.org>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <CC87A33B.4CDD3%keir@xen.org>
Thread-Topic: [Xen-devel] [PATCH] x86: slightly improve stack trace on debug
	builds
Thread-Index: Ac2bQCe16RcN93/91EmW61QV7OHC+g==
In-Reply-To: <5061F5D7020000780009DC03@nat28.tlf.novell.com>
Mime-version: 1.0
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] x86: slightly improve stack trace on debug
 builds
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/09/2012 17:20, "Jan Beulich" <JBeulich@suse.com> wrote:

>> Lol, how does your brain work this way? It took me 15 minutes to decode this
>> to something like (also I added range checks on ESP_BEFORE_EXCEPTION(regs),
>> what do you think?):
> 
> Sorry for this - just wanted to avoid having the condition evaluated
> (and spelled out) twice (and it took me a minute at most to find this
> iterate-at-most-twice solution).

It's the kind of code that is definitely easier to write than to read. ;-)



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 25 17:29:54 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 17:29: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 1TGYwz-0004Ad-0W; Tue, 25 Sep 2012 17:29:37 +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 1TGYwy-0004AX-BA
	for xen-devel@lists.xensource.com; Tue, 25 Sep 2012 17:29:36 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1348594170!7163705!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTEwNzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13051 invoked from network); 25 Sep 2012 17:29:30 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Sep 2012 17:29:30 -0000
X-IronPort-AV: E=Sophos;i="4.80,484,1344211200"; d="scan'208";a="14757510"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Sep 2012 17:29: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.279.1; Tue, 25 Sep 2012 18:29: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
	1TGYwr-00024G-PV	for xen-devel@lists.xensource.com;
	Tue, 25 Sep 2012 17:29:29 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1TGYwr-0006iC-M4	for
	xen-devel@lists.xensource.com; Tue, 25 Sep 2012 18:29:29 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20577.59897.414008.644934@mariner.uk.xensource.com>
Date: Tue, 25 Sep 2012 18:29:29 +0100
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
In-Reply-To: <osstest-13864-mainreport@xen.org>
References: <osstest-13864-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] 13864: trouble:
	broken/fail/pass
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

xen.org writes ("[xen-4.1-testing test] 13864: trouble: broken/fail/pass"):
> flight 13864 xen-4.1-testing real [real]
> http://www.chiark.greenend.org.uk/~xensrcts/logs/13864/
> 
> Failures and problems with tests :-(
> 
> Tests which did not succeed and are blocking,
> including tests which could not be run:
>  test-amd64-i386-pv            3 host-install(3)     broken REGR. vs. 13820

This is another one of these boxes (earwig this time) forgetting that
it was supposed to boot from the network.

I think I will try to go through the logs I have and see if I can
produce a history of each of these machines to see what the common
factor is.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 25 17:29:54 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 17:29: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 1TGYwz-0004Ad-0W; Tue, 25 Sep 2012 17:29:37 +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 1TGYwy-0004AX-BA
	for xen-devel@lists.xensource.com; Tue, 25 Sep 2012 17:29:36 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1348594170!7163705!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTEwNzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13051 invoked from network); 25 Sep 2012 17:29:30 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Sep 2012 17:29:30 -0000
X-IronPort-AV: E=Sophos;i="4.80,484,1344211200"; d="scan'208";a="14757510"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Sep 2012 17:29: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.279.1; Tue, 25 Sep 2012 18:29: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
	1TGYwr-00024G-PV	for xen-devel@lists.xensource.com;
	Tue, 25 Sep 2012 17:29:29 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1TGYwr-0006iC-M4	for
	xen-devel@lists.xensource.com; Tue, 25 Sep 2012 18:29:29 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20577.59897.414008.644934@mariner.uk.xensource.com>
Date: Tue, 25 Sep 2012 18:29:29 +0100
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
In-Reply-To: <osstest-13864-mainreport@xen.org>
References: <osstest-13864-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] 13864: trouble:
	broken/fail/pass
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

xen.org writes ("[xen-4.1-testing test] 13864: trouble: broken/fail/pass"):
> flight 13864 xen-4.1-testing real [real]
> http://www.chiark.greenend.org.uk/~xensrcts/logs/13864/
> 
> Failures and problems with tests :-(
> 
> Tests which did not succeed and are blocking,
> including tests which could not be run:
>  test-amd64-i386-pv            3 host-install(3)     broken REGR. vs. 13820

This is another one of these boxes (earwig this time) forgetting that
it was supposed to boot from the network.

I think I will try to go through the logs I have and see if I can
produce a history of each of these machines to see what the common
factor is.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 25 17:53:22 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 17: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 1TGZJg-0005P1-3z; Tue, 25 Sep 2012 17:53: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 1TGZJe-0005Ov-VA
	for xen-devel@lists.xen.org; Tue, 25 Sep 2012 17:53:03 +0000
Received: from [85.158.143.99:56929] by server-3.bemta-4.messagelabs.com id
	9B/CE-10986-E7FE1605; Tue, 25 Sep 2012 17:53:02 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1348595581!23611840!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTEwNzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5922 invoked from network); 25 Sep 2012 17:53:01 -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;
	25 Sep 2012 17:53:01 -0000
X-IronPort-AV: E=Sophos;i="4.80,484,1344211200"; d="scan'208";a="14757909"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Sep 2012 17:53:01 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Tue, 25 Sep 2012 18:53:01 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1TGZJd-0002Li-6x; Tue, 25 Sep 2012 17:53:01 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1TGZJd-0006lk-2z;
	Tue, 25 Sep 2012 18:53:01 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20577.61307.582095.591599@mariner.uk.xensource.com>
Date: Tue, 25 Sep 2012 18:52:59 +0100
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1348583794.11229.28.camel@zakaz.uk.xensource.com>
References: <20576.36587.698928.396214@mariner.uk.xensource.com>
	<1348579144.11229.6.camel@zakaz.uk.xensource.com>
	<20577.49354.986341.321870@mariner.uk.xensource.com>
	<1348583794.11229.28.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] docs: network diagrams for the wiki
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("Re: [Xen-devel] [PATCH] docs: network diagrams for the wiki"):
> I'm not totally convinced by this as a home for things referenced from
> the wiki like this but lets try it:
> 
> Acked-by: Ian Campbell <ian.campbell@citrix.com>

Thanks.  I have now applied this.  Although with two false starts.
I'm really not having a very good day...

I have however now updated the docs generator script on xenbits, and
the wiki, so the diagrams appear in their proper places.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 25 17:53:22 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 17: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 1TGZJg-0005P1-3z; Tue, 25 Sep 2012 17:53: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 1TGZJe-0005Ov-VA
	for xen-devel@lists.xen.org; Tue, 25 Sep 2012 17:53:03 +0000
Received: from [85.158.143.99:56929] by server-3.bemta-4.messagelabs.com id
	9B/CE-10986-E7FE1605; Tue, 25 Sep 2012 17:53:02 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1348595581!23611840!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTEwNzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5922 invoked from network); 25 Sep 2012 17:53:01 -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;
	25 Sep 2012 17:53:01 -0000
X-IronPort-AV: E=Sophos;i="4.80,484,1344211200"; d="scan'208";a="14757909"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Sep 2012 17:53:01 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Tue, 25 Sep 2012 18:53:01 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1TGZJd-0002Li-6x; Tue, 25 Sep 2012 17:53:01 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1TGZJd-0006lk-2z;
	Tue, 25 Sep 2012 18:53:01 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20577.61307.582095.591599@mariner.uk.xensource.com>
Date: Tue, 25 Sep 2012 18:52:59 +0100
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1348583794.11229.28.camel@zakaz.uk.xensource.com>
References: <20576.36587.698928.396214@mariner.uk.xensource.com>
	<1348579144.11229.6.camel@zakaz.uk.xensource.com>
	<20577.49354.986341.321870@mariner.uk.xensource.com>
	<1348583794.11229.28.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] docs: network diagrams for the wiki
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Ian Campbell writes ("Re: [Xen-devel] [PATCH] docs: network diagrams for the wiki"):
> I'm not totally convinced by this as a home for things referenced from
> the wiki like this but lets try it:
> 
> Acked-by: Ian Campbell <ian.campbell@citrix.com>

Thanks.  I have now applied this.  Although with two false starts.
I'm really not having a very good day...

I have however now updated the docs generator script on xenbits, and
the wiki, so the diagrams appear in their proper places.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 25 17:54:21 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 17:54:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGZKf-0005UU-Ib; Tue, 25 Sep 2012 17:54:05 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1TGZKe-0005Tz-29
	for xen-devel@lists.xensource.com; Tue, 25 Sep 2012 17:54:04 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1348595636!7165496!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzEyNDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5735 invoked from network); 25 Sep 2012 17:53:57 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Sep 2012 17:53:57 -0000
X-IronPort-AV: E=Sophos;i="4.80,484,1344211200"; d="scan'208";a="39125379"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Sep 2012 17:53:56 +0000
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.279.1; Tue, 25 Sep 2012
	13:53:56 -0400
Message-ID: <5061EFB2.1080407@citrix.com>
Date: Tue, 25 Sep 2012 18:53:54 +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 Iceowl/1.0b1 Icedove/3.0.11
MIME-Version: 1.0
To: David Vrabel <david.vrabel@citrix.com>
References: <1348243464-15903-1-git-send-email-david.vrabel@citrix.com>
	<1348243464-15903-3-git-send-email-david.vrabel@citrix.com>
In-Reply-To: <1348243464-15903-3-git-send-email-david.vrabel@citrix.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH 2/6] xen-blkfront: handle backend CLOSED
	without CLOSING
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/09/12 17:04, David Vrabel wrote:
> From: David Vrabel <david.vrabel@citrix.com>
> 
> Backend drivers shouldn't transistion to CLOSED unless the frontend is
> CLOSED.  If a backend does transition to CLOSED too soon then the
> frontend may not see the CLOSING state and will not properly shutdown.
> 
> So, treat an unexpected backend CLOSED state the same as CLOSING.

Didn't handle the frontend block device being mounted. Updated patch here.

8<---------------------------------
xen-blkfront: handle backend CLOSED without CLOSING

Backend drivers shouldn't transistion to CLOSED unless the frontend is
CLOSED.  If a backend does transition to CLOSED too soon then the
frontend may not see the CLOSING state and will not properly shutdown.

So, treat an unexpected backend CLOSED state the same as CLOSING.

If the backend is CLOSED then the frontend can't talk to it so go to
CLOSED immediately without waiting for the block device to be closed
or unmounted.

Signed-off-by: David Vrabel <david.vrabel@citrix.com>
---
 drivers/block/xen-blkfront.c |   13 +++++++++----
 1 files changed, 9 insertions(+), 4 deletions(-)

diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c
index 2c2d2e5..c1f5f38 100644
--- a/drivers/block/xen-blkfront.c
+++ b/drivers/block/xen-blkfront.c
@@ -1143,7 +1143,8 @@ static int blkfront_resume(struct xenbus_device *dev)
 }
 
 static void
-blkfront_closing(struct blkfront_info *info)
+blkfront_closing(struct blkfront_info *info,
+		 enum xenbus_state backend_state)
 {
 	struct xenbus_device *xbdev = info->xbdev;
 	struct block_device *bdev = NULL;
@@ -1167,7 +1168,8 @@ blkfront_closing(struct blkfront_info *info)
 
 	mutex_lock(&bdev->bd_mutex);
 
-	if (bdev->bd_openers) {
+	/* If the backend is already CLOSED, close now. */
+	if (bdev->bd_openers && backend_state != XenbusStateClosed) {
 		xenbus_dev_error(xbdev, -EBUSY,
 				 "Device in use; refusing to close");
 		xenbus_switch_state(xbdev, XenbusStateClosing);
@@ -1340,15 +1342,18 @@ static void blkback_changed(struct xenbus_device *dev,
 	case XenbusStateReconfiguring:
 	case XenbusStateReconfigured:
 	case XenbusStateUnknown:
-	case XenbusStateClosed:
 		break;
 
 	case XenbusStateConnected:
 		blkfront_connect(info);
 		break;
 
+	case XenbusStateClosed:
+		if (dev->state == XenbusStateClosed)
+			break;
+		/* Missed the backend's Closing state -- fallthrough */
 	case XenbusStateClosing:
-		blkfront_closing(info);
+		blkfront_closing(info, backend_state);
 		break;
 	}
 }
-- 
1.7.2.5

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 25 17:54:21 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 17:54:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGZKf-0005UU-Ib; Tue, 25 Sep 2012 17:54:05 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1TGZKe-0005Tz-29
	for xen-devel@lists.xensource.com; Tue, 25 Sep 2012 17:54:04 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1348595636!7165496!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzEyNDc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5735 invoked from network); 25 Sep 2012 17:53:57 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Sep 2012 17:53:57 -0000
X-IronPort-AV: E=Sophos;i="4.80,484,1344211200"; d="scan'208";a="39125379"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Sep 2012 17:53:56 +0000
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.279.1; Tue, 25 Sep 2012
	13:53:56 -0400
Message-ID: <5061EFB2.1080407@citrix.com>
Date: Tue, 25 Sep 2012 18:53:54 +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 Iceowl/1.0b1 Icedove/3.0.11
MIME-Version: 1.0
To: David Vrabel <david.vrabel@citrix.com>
References: <1348243464-15903-1-git-send-email-david.vrabel@citrix.com>
	<1348243464-15903-3-git-send-email-david.vrabel@citrix.com>
In-Reply-To: <1348243464-15903-3-git-send-email-david.vrabel@citrix.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH 2/6] xen-blkfront: handle backend CLOSED
	without CLOSING
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/09/12 17:04, David Vrabel wrote:
> From: David Vrabel <david.vrabel@citrix.com>
> 
> Backend drivers shouldn't transistion to CLOSED unless the frontend is
> CLOSED.  If a backend does transition to CLOSED too soon then the
> frontend may not see the CLOSING state and will not properly shutdown.
> 
> So, treat an unexpected backend CLOSED state the same as CLOSING.

Didn't handle the frontend block device being mounted. Updated patch here.

8<---------------------------------
xen-blkfront: handle backend CLOSED without CLOSING

Backend drivers shouldn't transistion to CLOSED unless the frontend is
CLOSED.  If a backend does transition to CLOSED too soon then the
frontend may not see the CLOSING state and will not properly shutdown.

So, treat an unexpected backend CLOSED state the same as CLOSING.

If the backend is CLOSED then the frontend can't talk to it so go to
CLOSED immediately without waiting for the block device to be closed
or unmounted.

Signed-off-by: David Vrabel <david.vrabel@citrix.com>
---
 drivers/block/xen-blkfront.c |   13 +++++++++----
 1 files changed, 9 insertions(+), 4 deletions(-)

diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c
index 2c2d2e5..c1f5f38 100644
--- a/drivers/block/xen-blkfront.c
+++ b/drivers/block/xen-blkfront.c
@@ -1143,7 +1143,8 @@ static int blkfront_resume(struct xenbus_device *dev)
 }
 
 static void
-blkfront_closing(struct blkfront_info *info)
+blkfront_closing(struct blkfront_info *info,
+		 enum xenbus_state backend_state)
 {
 	struct xenbus_device *xbdev = info->xbdev;
 	struct block_device *bdev = NULL;
@@ -1167,7 +1168,8 @@ blkfront_closing(struct blkfront_info *info)
 
 	mutex_lock(&bdev->bd_mutex);
 
-	if (bdev->bd_openers) {
+	/* If the backend is already CLOSED, close now. */
+	if (bdev->bd_openers && backend_state != XenbusStateClosed) {
 		xenbus_dev_error(xbdev, -EBUSY,
 				 "Device in use; refusing to close");
 		xenbus_switch_state(xbdev, XenbusStateClosing);
@@ -1340,15 +1342,18 @@ static void blkback_changed(struct xenbus_device *dev,
 	case XenbusStateReconfiguring:
 	case XenbusStateReconfigured:
 	case XenbusStateUnknown:
-	case XenbusStateClosed:
 		break;
 
 	case XenbusStateConnected:
 		blkfront_connect(info);
 		break;
 
+	case XenbusStateClosed:
+		if (dev->state == XenbusStateClosed)
+			break;
+		/* Missed the backend's Closing state -- fallthrough */
 	case XenbusStateClosing:
-		blkfront_closing(info);
+		blkfront_closing(info, backend_state);
 		break;
 	}
 }
-- 
1.7.2.5

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 25 17:58:56 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 17:58:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGZP6-0005mC-9b; Tue, 25 Sep 2012 17:58:40 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <julien.grall@citrix.com>) id 1TGZP4-0005m3-HS
	for xen-devel@lists.xen.org; Tue, 25 Sep 2012 17:58:38 +0000
Received: from [85.158.137.99:39454] by server-3.bemta-3.messagelabs.com id
	A4/8F-21322-DC0F1605; Tue, 25 Sep 2012 17:58:37 +0000
X-Env-Sender: julien.grall@citrix.com
X-Msg-Ref: server-4.tower-217.messagelabs.com!1348595915!19100943!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNzczMzU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17818 invoked from network); 25 Sep 2012 17:58:37 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-4.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Sep 2012 17:58:37 -0000
X-IronPort-AV: E=Sophos;i="4.80,484,1344211200"; d="scan'208";a="209308580"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Sep 2012 17:58:35 +0000
Received: from meteora.cam.xci-test.com (10.80.248.22) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1;
	Tue, 25 Sep 2012 13:58:35 -0400
From: Julien Grall <julien.grall@citrix.com>
To: xen-devel@lists.xen.org
Date: Tue, 25 Sep 2012 12:33:37 +0100
Message-ID: <1348572817-13908-1-git-send-email-julien.grall@citrix.com>
X-Mailer: git-send-email 1.7.2.5
MIME-Version: 1.0
Cc: Julien Grall <julien.grall@citrix.com>,
	Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH V2] libxenstore: filter watch events in
	libxenstore when we unwatch
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 on entry to xs_unwatch, there may be an event on its way from
xenstored (eg in the ring or in the local kernel), all such events
will definitely come before the reply to the unwatch command.  So at
the point where the unwatch reply has been processed (after xs_talkv),
any such now-deleted watch events will definitely have made it to
libxenstore's queue where we can remove them.

As for other threads in the same process: if two threads call
xs_read_watch and xs_unwatch, it is acceptable for the xs_read_watch
to return the event being deleted.  What is not allowed is for an
xs_read_watch entered after xs_unwatch returns to return the deleted
event, and this code does indeed ensure that.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Signed-off-by: Julien Grall <julien.grall@citrix.com>
---
 tools/xenstore/xs.c |   73 +++++++++++++++++++++++++++++++++++++++++++++-----
 1 files changed, 65 insertions(+), 8 deletions(-)

diff --git a/tools/xenstore/xs.c b/tools/xenstore/xs.c
index b951015..df89e37 100644
--- a/tools/xenstore/xs.c
+++ b/tools/xenstore/xs.c
@@ -753,6 +753,19 @@ bool xs_watch(struct xs_handle *h, const char *path, const char *token)
 				ARRAY_SIZE(iov), NULL));
 }
 
+
+/* Clear the pipe token if there are no more pending watchs.
+ * We suppose the watch_mutex is already taken.
+ */
+static void xs_clear_watch_pipe(struct xs_handle *h)
+{
+	char c;
+
+	if (list_empty(&h->watch_list) && (h->watch_pipe[0] != -1))
+		while (read(h->watch_pipe[0], &c, 1) != 1)
+			continue;
+}
+
 /* Find out what node change was on (will block if nothing pending).
  * Returns array of two pointers: path and token, or NULL.
  * Call free() after use.
@@ -761,7 +774,7 @@ static char **read_watch_internal(struct xs_handle *h, unsigned int *num,
 				  int nonblocking)
 {
 	struct xs_stored_msg *msg;
-	char **ret, *strings, c = 0;
+	char **ret, *strings;
 	unsigned int num_strings, i;
 
 	mutex_lock(&h->watch_mutex);
@@ -798,11 +811,7 @@ static char **read_watch_internal(struct xs_handle *h, unsigned int *num,
 	msg = list_top(&h->watch_list, struct xs_stored_msg, list);
 	list_del(&msg->list);
 
-	/* Clear the pipe token if there are no more pending watches. */
-	if (list_empty(&h->watch_list) && (h->watch_pipe[0] != -1))
-		while (read(h->watch_pipe[0], &c, 1) != 1)
-			continue;
-
+	xs_clear_watch_pipe(h);
 	mutex_unlock(&h->watch_mutex);
 
 	assert(msg->hdr.type == XS_WATCH_EVENT);
@@ -855,14 +864,62 @@ char **xs_read_watch(struct xs_handle *h, unsigned int *num)
 bool xs_unwatch(struct xs_handle *h, const char *path, const char *token)
 {
 	struct iovec iov[2];
+	struct xs_stored_msg *msg, *tmsg;
+	bool res;
+	char *s, *p;
+	unsigned int i;
+	char *l_token, *l_path;
 
 	iov[0].iov_base = (char *)path;
 	iov[0].iov_len = strlen(path) + 1;
 	iov[1].iov_base = (char *)token;
 	iov[1].iov_len = strlen(token) + 1;
 
-	return xs_bool(xs_talkv(h, XBT_NULL, XS_UNWATCH, iov,
-				ARRAY_SIZE(iov), NULL));
+	res = xs_bool(xs_talkv(h, XBT_NULL, XS_UNWATCH, iov,
+						   ARRAY_SIZE(iov), NULL));
+
+	/* Filter the watch list to remove potential message */
+	mutex_lock(&h->watch_mutex);
+
+	if (list_empty(&h->watch_list)) {
+		mutex_unlock(&h->watch_mutex);
+		return res;
+	}
+
+	list_for_each_entry_safe(msg, tmsg, &h->watch_list, list) {
+		assert(msg->hdr.type == XS_WATCH_EVENT);
+
+		s = msg->body;
+
+		l_token = NULL;
+		l_path = NULL;
+
+		for (p = s, i = 0; p < msg->body + msg->hdr.len; p++) {
+			if (*p == '\0')
+			{
+				if (i == XS_WATCH_TOKEN)
+					l_token = s;
+				else if (i == XS_WATCH_PATH)
+					l_path = s;
+				i++;
+				s = p + 1;
+			}
+		}
+
+		if (l_token && !strcmp(token, l_token)
+			/* Use strncmp because we can have a watch fired on sub-directory */
+			&& l_path && !strncmp(path, l_path, strlen(path))) {
+			fprintf (stderr, "DELETE\n");
+			list_del(&msg->list);
+			free(msg);
+		}
+	}
+
+	xs_clear_watch_pipe(h);
+
+	mutex_unlock(&h->watch_mutex);
+
+	return res;
 }
 
 /* Start a transaction: changes by others will not be seen during this
-- 
Julien Grall


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 25 17:58:56 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 17:58:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGZP6-0005mC-9b; Tue, 25 Sep 2012 17:58:40 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <julien.grall@citrix.com>) id 1TGZP4-0005m3-HS
	for xen-devel@lists.xen.org; Tue, 25 Sep 2012 17:58:38 +0000
Received: from [85.158.137.99:39454] by server-3.bemta-3.messagelabs.com id
	A4/8F-21322-DC0F1605; Tue, 25 Sep 2012 17:58:37 +0000
X-Env-Sender: julien.grall@citrix.com
X-Msg-Ref: server-4.tower-217.messagelabs.com!1348595915!19100943!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNzczMzU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17818 invoked from network); 25 Sep 2012 17:58:37 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-4.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Sep 2012 17:58:37 -0000
X-IronPort-AV: E=Sophos;i="4.80,484,1344211200"; d="scan'208";a="209308580"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Sep 2012 17:58:35 +0000
Received: from meteora.cam.xci-test.com (10.80.248.22) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1;
	Tue, 25 Sep 2012 13:58:35 -0400
From: Julien Grall <julien.grall@citrix.com>
To: xen-devel@lists.xen.org
Date: Tue, 25 Sep 2012 12:33:37 +0100
Message-ID: <1348572817-13908-1-git-send-email-julien.grall@citrix.com>
X-Mailer: git-send-email 1.7.2.5
MIME-Version: 1.0
Cc: Julien Grall <julien.grall@citrix.com>,
	Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH V2] libxenstore: filter watch events in
	libxenstore when we unwatch
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 on entry to xs_unwatch, there may be an event on its way from
xenstored (eg in the ring or in the local kernel), all such events
will definitely come before the reply to the unwatch command.  So at
the point where the unwatch reply has been processed (after xs_talkv),
any such now-deleted watch events will definitely have made it to
libxenstore's queue where we can remove them.

As for other threads in the same process: if two threads call
xs_read_watch and xs_unwatch, it is acceptable for the xs_read_watch
to return the event being deleted.  What is not allowed is for an
xs_read_watch entered after xs_unwatch returns to return the deleted
event, and this code does indeed ensure that.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Signed-off-by: Julien Grall <julien.grall@citrix.com>
---
 tools/xenstore/xs.c |   73 +++++++++++++++++++++++++++++++++++++++++++++-----
 1 files changed, 65 insertions(+), 8 deletions(-)

diff --git a/tools/xenstore/xs.c b/tools/xenstore/xs.c
index b951015..df89e37 100644
--- a/tools/xenstore/xs.c
+++ b/tools/xenstore/xs.c
@@ -753,6 +753,19 @@ bool xs_watch(struct xs_handle *h, const char *path, const char *token)
 				ARRAY_SIZE(iov), NULL));
 }
 
+
+/* Clear the pipe token if there are no more pending watchs.
+ * We suppose the watch_mutex is already taken.
+ */
+static void xs_clear_watch_pipe(struct xs_handle *h)
+{
+	char c;
+
+	if (list_empty(&h->watch_list) && (h->watch_pipe[0] != -1))
+		while (read(h->watch_pipe[0], &c, 1) != 1)
+			continue;
+}
+
 /* Find out what node change was on (will block if nothing pending).
  * Returns array of two pointers: path and token, or NULL.
  * Call free() after use.
@@ -761,7 +774,7 @@ static char **read_watch_internal(struct xs_handle *h, unsigned int *num,
 				  int nonblocking)
 {
 	struct xs_stored_msg *msg;
-	char **ret, *strings, c = 0;
+	char **ret, *strings;
 	unsigned int num_strings, i;
 
 	mutex_lock(&h->watch_mutex);
@@ -798,11 +811,7 @@ static char **read_watch_internal(struct xs_handle *h, unsigned int *num,
 	msg = list_top(&h->watch_list, struct xs_stored_msg, list);
 	list_del(&msg->list);
 
-	/* Clear the pipe token if there are no more pending watches. */
-	if (list_empty(&h->watch_list) && (h->watch_pipe[0] != -1))
-		while (read(h->watch_pipe[0], &c, 1) != 1)
-			continue;
-
+	xs_clear_watch_pipe(h);
 	mutex_unlock(&h->watch_mutex);
 
 	assert(msg->hdr.type == XS_WATCH_EVENT);
@@ -855,14 +864,62 @@ char **xs_read_watch(struct xs_handle *h, unsigned int *num)
 bool xs_unwatch(struct xs_handle *h, const char *path, const char *token)
 {
 	struct iovec iov[2];
+	struct xs_stored_msg *msg, *tmsg;
+	bool res;
+	char *s, *p;
+	unsigned int i;
+	char *l_token, *l_path;
 
 	iov[0].iov_base = (char *)path;
 	iov[0].iov_len = strlen(path) + 1;
 	iov[1].iov_base = (char *)token;
 	iov[1].iov_len = strlen(token) + 1;
 
-	return xs_bool(xs_talkv(h, XBT_NULL, XS_UNWATCH, iov,
-				ARRAY_SIZE(iov), NULL));
+	res = xs_bool(xs_talkv(h, XBT_NULL, XS_UNWATCH, iov,
+						   ARRAY_SIZE(iov), NULL));
+
+	/* Filter the watch list to remove potential message */
+	mutex_lock(&h->watch_mutex);
+
+	if (list_empty(&h->watch_list)) {
+		mutex_unlock(&h->watch_mutex);
+		return res;
+	}
+
+	list_for_each_entry_safe(msg, tmsg, &h->watch_list, list) {
+		assert(msg->hdr.type == XS_WATCH_EVENT);
+
+		s = msg->body;
+
+		l_token = NULL;
+		l_path = NULL;
+
+		for (p = s, i = 0; p < msg->body + msg->hdr.len; p++) {
+			if (*p == '\0')
+			{
+				if (i == XS_WATCH_TOKEN)
+					l_token = s;
+				else if (i == XS_WATCH_PATH)
+					l_path = s;
+				i++;
+				s = p + 1;
+			}
+		}
+
+		if (l_token && !strcmp(token, l_token)
+			/* Use strncmp because we can have a watch fired on sub-directory */
+			&& l_path && !strncmp(path, l_path, strlen(path))) {
+			fprintf (stderr, "DELETE\n");
+			list_del(&msg->list);
+			free(msg);
+		}
+	}
+
+	xs_clear_watch_pipe(h);
+
+	mutex_unlock(&h->watch_mutex);
+
+	return res;
 }
 
 /* Start a transaction: changes by others will not be seen during this
-- 
Julien Grall


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 25 19:09:43 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 19:09:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGaVS-0006zB-Hh; Tue, 25 Sep 2012 19:09:18 +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 1TGaVQ-0006z4-Bt
	for xen-devel@lists.xen.org; Tue, 25 Sep 2012 19:09:16 +0000
Received: from [85.158.143.35:9227] by server-2.bemta-4.messagelabs.com id
	84/4F-06610-B5102605; Tue, 25 Sep 2012 19:09:15 +0000
X-Env-Sender: dan.magenheimer@oracle.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1348600153!12717854!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzYyNzYy\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20768 invoked from network); 25 Sep 2012 19:09:14 -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; 25 Sep 2012 19:09:14 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q8PJ97Dj021060
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 25 Sep 2012 19:09:08 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
	q8PJ96qG028024
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 25 Sep 2012 19:09:07 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
	q8PJ96kH020487; Tue, 25 Sep 2012 14:09:06 -0500
MIME-Version: 1.0
Message-ID: <5be4b632-868b-4080-a3b1-bf68904da077@default>
Date: Tue, 25 Sep 2012 12:08:56 -0700 (PDT)
From: Dan Magenheimer <dan.magenheimer@oracle.com>
To: Jan Beulich <JBeulich@suse.com>, xen-devel@lists.xen.org
References: <cc71cf29-4505-4acf-ac37-5190ce30451b@default>
	<5061A3E1020000780009DA02@nat28.tlf.novell.com>
In-Reply-To: <5061A3E1020000780009DA02@nat28.tlf.novell.com>
X-Priority: 3
X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.7  (607090) [OL
	12.0.6661.5003 (x86)]
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: Zhenzhong Duan <zhenzhong.duan@oracle.com>, tim@xen.org,
	IanJackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>,
	Konrad Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] tmem/XSA-15 backport?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> From: Jan Beulich [mailto:JBeulich@suse.com]
> Sent: Tuesday, September 25, 2012 4:30 AM
> To: xen-devel@lists.xen.org; Dan Magenheimer
> Cc: Ian Campbell; IanJackson; Konrad Wilk; Zhenzhong Duan; tim@xen.org
> Subject: Re: tmem/XSA-15 backport?
> 
> >>> On 19.09.12 at 17:48, Dan Magenheimer <dan.magenheimer@oracle.com> wrote:
> > Once zduan's tmem restore fix is applied, all known
> > tmem security issues have been resolved and tested
> > and tmem is fully functional again in xen-unstable,
> > including save/restore.
> >
> > I'd like to recommend that all tmem patches be backported
> > to 4.1-stable and 4.2-stable prior to the next
> > point release and preferably asap.
> 
> Done.

Excellent!  Thanks much!

Dan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 25 19:09:43 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 19:09:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGaVS-0006zB-Hh; Tue, 25 Sep 2012 19:09:18 +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 1TGaVQ-0006z4-Bt
	for xen-devel@lists.xen.org; Tue, 25 Sep 2012 19:09:16 +0000
Received: from [85.158.143.35:9227] by server-2.bemta-4.messagelabs.com id
	84/4F-06610-B5102605; Tue, 25 Sep 2012 19:09:15 +0000
X-Env-Sender: dan.magenheimer@oracle.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1348600153!12717854!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzYyNzYy\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20768 invoked from network); 25 Sep 2012 19:09:14 -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; 25 Sep 2012 19:09:14 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q8PJ97Dj021060
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 25 Sep 2012 19:09:08 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
	q8PJ96qG028024
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 25 Sep 2012 19:09:07 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
	q8PJ96kH020487; Tue, 25 Sep 2012 14:09:06 -0500
MIME-Version: 1.0
Message-ID: <5be4b632-868b-4080-a3b1-bf68904da077@default>
Date: Tue, 25 Sep 2012 12:08:56 -0700 (PDT)
From: Dan Magenheimer <dan.magenheimer@oracle.com>
To: Jan Beulich <JBeulich@suse.com>, xen-devel@lists.xen.org
References: <cc71cf29-4505-4acf-ac37-5190ce30451b@default>
	<5061A3E1020000780009DA02@nat28.tlf.novell.com>
In-Reply-To: <5061A3E1020000780009DA02@nat28.tlf.novell.com>
X-Priority: 3
X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.7  (607090) [OL
	12.0.6661.5003 (x86)]
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: Zhenzhong Duan <zhenzhong.duan@oracle.com>, tim@xen.org,
	IanJackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>,
	Konrad Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] tmem/XSA-15 backport?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> From: Jan Beulich [mailto:JBeulich@suse.com]
> Sent: Tuesday, September 25, 2012 4:30 AM
> To: xen-devel@lists.xen.org; Dan Magenheimer
> Cc: Ian Campbell; IanJackson; Konrad Wilk; Zhenzhong Duan; tim@xen.org
> Subject: Re: tmem/XSA-15 backport?
> 
> >>> On 19.09.12 at 17:48, Dan Magenheimer <dan.magenheimer@oracle.com> wrote:
> > Once zduan's tmem restore fix is applied, all known
> > tmem security issues have been resolved and tested
> > and tmem is fully functional again in xen-unstable,
> > including save/restore.
> >
> > I'd like to recommend that all tmem patches be backported
> > to 4.1-stable and 4.2-stable prior to the next
> > point release and preferably asap.
> 
> Done.

Excellent!  Thanks much!

Dan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 25 19:56:30 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 19:56:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGbEh-0007g9-1z; Tue, 25 Sep 2012 19:56:03 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jmarcet@gmail.com>) id 1TGbEf-0007g4-T7
	for xen-devel@lists.xen.org; Tue, 25 Sep 2012 19:56:02 +0000
Received: from [85.158.138.51:63199] by server-12.bemta-3.messagelabs.com id
	0E/40-10384-15C02605; Tue, 25 Sep 2012 19:56:01 +0000
X-Env-Sender: jmarcet@gmail.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1348602958!31448228!1
X-Originating-IP: [209.85.219.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22090 invoked from network); 25 Sep 2012 19:56:00 -0000
Received: from mail-oa0-f45.google.com (HELO mail-oa0-f45.google.com)
	(209.85.219.45)
	by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Sep 2012 19:56:00 -0000
Received: by oagi18 with SMTP id i18so3092170oag.32
	for <xen-devel@lists.xen.org>; Tue, 25 Sep 2012 12:55: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=hNZJJroVYPIf0m2EQ7tOZ9fxL9Cr9afaR+JJZtjUESo=;
	b=YUwsantEfBHn2iTm/ElZHcyGTXVNBWbKSSV4iZkwfylTgTASCY8oZUQa9AG1QfGhiC
	+wGV9s71mnhn9Vxc2VNt5EutSFpSrPCAS730FlmFK+X4skve3qi6I0KglPtCXFoTN371
	DlMBXxO2JegnCd2GIj9j9TsovpKGvNGvrh2jsdK22GrITnadjieLZCM2kfGYWRAfqbIP
	cTHkWEmYMToTKLbJXpBrUY7gaxmjSsbx7n9kBO1BBKI/mVX95Y1F/CrexiICXa3uTpUl
	h2Du3ul+vdeR8BSqSuMsbX7/8snN2PkfraD6tVDH5M0zRABVRQD5xzTFWGeug36ad/Yx
	UNBA==
Received: by 10.182.174.68 with SMTP id bq4mr13406249obc.53.1348602958132;
	Tue, 25 Sep 2012 12:55:58 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.60.138.225 with HTTP; Tue, 25 Sep 2012 12:55:37 -0700 (PDT)
In-Reply-To: <5061E800020000780009DBBA@nat28.tlf.novell.com>
References: <CC8273A0.4C9DD%keir@xen.org>
	<50605E9A020000780009D486@nat28.tlf.novell.com>
	<CAOvdn6XmB6rj3_QVU+59V8p24Y5G47AWxVEM=id02JWXkuhibQ@mail.gmail.com>
	<5060640B020000780009D4D2@nat28.tlf.novell.com>
	<CAOvdn6XLy8zR2rb2MEyi2aT9LQiFvFLY_H02p181mTsVLVTZkw@mail.gmail.com>
	<20120924122203.GG8912@reaktio.net>
	<CAOvdn6XV4eoA-FfFns1xhx7HCUqXc7KHxZwyKuT4FHG8s3R5RQ@mail.gmail.com>
	<CAAnFQG9PLQjdh6Ab6=Y5ZGM1s4nGdLekKU=pcKNMxt4rmt_RKA@mail.gmail.com>
	<20120924140411.GH31618@phenom.dumpdata.com>
	<CAAnFQG-tjv5UyF6j-TNHNgme2c4vA0Zxy8AdCiJEVsf2Z0quNA@mail.gmail.com>
	<20120925140611.GB16478@phenom.dumpdata.com>
	<CAAnFQG88ApxKuscXx53Lt2qOyCe0ws6oXSSqBDfW0+oYo5Y3nA@mail.gmail.com>
	<5061E800020000780009DBBA@nat28.tlf.novell.com>
From: Javier Marcet <jmarcet@gmail.com>
Date: Tue, 25 Sep 2012 21:55:37 +0200
Message-ID: <CAAnFQG-6VrwaA_OcUJL5X5HBNo8PTME9pNyJbsXqSO34tbD8=g@mail.gmail.com>
To: Jan Beulich <JBeulich@suse.com>
Cc: Keir Fraser <keir@xen.org>, john.baboval@citrix.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	xen-devel <xen-devel@lists.xen.org>,
	Konrad Rzeszutek Wilk <konrad@kernel.org>, Ben Guthro <ben@guthro.net>,
	Thomas Goetz <thomas.goetz@citrix.com>
Subject: Re: [Xen-devel] Xen4.2 S3 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 Tue, Sep 25, 2012 at 5:21 PM, Jan Beulich <JBeulich@suse.com> wrote:

>>>> On 25.09.12 at 16:47, Javier Marcet <jmarcet@gmail.com> wrote:
>> I haven't been able to see the actual patch, I only read a description
>> of what it should do. Two possible places where a wbinvd() call should
>> be added. On the first of these two places there were already calls to
>> wbinvd() just before the halts. I added it to the other one, within
>> xen/arch/x86/domain.c:default_idle and I could complete a
>> suspend/resume cycle without the back trace but after rebooting I
>> tried it again and it failed, more than once.
>
> default_idle() isn't the right place, default_dead_idle() is.
>
> See
> http://xenbits.xen.org/hg/staging/xen-unstable.hg/rev/c8d65d91a6f2

I'm sorry to say it doesn't fix it on my system, i.e., kernel 3.5.3
and xen 4.2.1-pre (the head from
git://xenbits.xen.org/xen.git#stable-4.2)

It really was basically what I had tried yesterday, just with duplicated code.

Adding the wbinvd() only in xen/arch/x86/domain.c was how I was able
to suspend and resume once without the back trace.

Adding the additional call in xen/arch/x86/acpi/cpu_idle.c causes an
instant reboot on resume.


-- 
Javier Marcet <jmarcet@gmail.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 25 19:56:30 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 19:56:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGbEh-0007g9-1z; Tue, 25 Sep 2012 19:56:03 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jmarcet@gmail.com>) id 1TGbEf-0007g4-T7
	for xen-devel@lists.xen.org; Tue, 25 Sep 2012 19:56:02 +0000
Received: from [85.158.138.51:63199] by server-12.bemta-3.messagelabs.com id
	0E/40-10384-15C02605; Tue, 25 Sep 2012 19:56:01 +0000
X-Env-Sender: jmarcet@gmail.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1348602958!31448228!1
X-Originating-IP: [209.85.219.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22090 invoked from network); 25 Sep 2012 19:56:00 -0000
Received: from mail-oa0-f45.google.com (HELO mail-oa0-f45.google.com)
	(209.85.219.45)
	by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Sep 2012 19:56:00 -0000
Received: by oagi18 with SMTP id i18so3092170oag.32
	for <xen-devel@lists.xen.org>; Tue, 25 Sep 2012 12:55: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=hNZJJroVYPIf0m2EQ7tOZ9fxL9Cr9afaR+JJZtjUESo=;
	b=YUwsantEfBHn2iTm/ElZHcyGTXVNBWbKSSV4iZkwfylTgTASCY8oZUQa9AG1QfGhiC
	+wGV9s71mnhn9Vxc2VNt5EutSFpSrPCAS730FlmFK+X4skve3qi6I0KglPtCXFoTN371
	DlMBXxO2JegnCd2GIj9j9TsovpKGvNGvrh2jsdK22GrITnadjieLZCM2kfGYWRAfqbIP
	cTHkWEmYMToTKLbJXpBrUY7gaxmjSsbx7n9kBO1BBKI/mVX95Y1F/CrexiICXa3uTpUl
	h2Du3ul+vdeR8BSqSuMsbX7/8snN2PkfraD6tVDH5M0zRABVRQD5xzTFWGeug36ad/Yx
	UNBA==
Received: by 10.182.174.68 with SMTP id bq4mr13406249obc.53.1348602958132;
	Tue, 25 Sep 2012 12:55:58 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.60.138.225 with HTTP; Tue, 25 Sep 2012 12:55:37 -0700 (PDT)
In-Reply-To: <5061E800020000780009DBBA@nat28.tlf.novell.com>
References: <CC8273A0.4C9DD%keir@xen.org>
	<50605E9A020000780009D486@nat28.tlf.novell.com>
	<CAOvdn6XmB6rj3_QVU+59V8p24Y5G47AWxVEM=id02JWXkuhibQ@mail.gmail.com>
	<5060640B020000780009D4D2@nat28.tlf.novell.com>
	<CAOvdn6XLy8zR2rb2MEyi2aT9LQiFvFLY_H02p181mTsVLVTZkw@mail.gmail.com>
	<20120924122203.GG8912@reaktio.net>
	<CAOvdn6XV4eoA-FfFns1xhx7HCUqXc7KHxZwyKuT4FHG8s3R5RQ@mail.gmail.com>
	<CAAnFQG9PLQjdh6Ab6=Y5ZGM1s4nGdLekKU=pcKNMxt4rmt_RKA@mail.gmail.com>
	<20120924140411.GH31618@phenom.dumpdata.com>
	<CAAnFQG-tjv5UyF6j-TNHNgme2c4vA0Zxy8AdCiJEVsf2Z0quNA@mail.gmail.com>
	<20120925140611.GB16478@phenom.dumpdata.com>
	<CAAnFQG88ApxKuscXx53Lt2qOyCe0ws6oXSSqBDfW0+oYo5Y3nA@mail.gmail.com>
	<5061E800020000780009DBBA@nat28.tlf.novell.com>
From: Javier Marcet <jmarcet@gmail.com>
Date: Tue, 25 Sep 2012 21:55:37 +0200
Message-ID: <CAAnFQG-6VrwaA_OcUJL5X5HBNo8PTME9pNyJbsXqSO34tbD8=g@mail.gmail.com>
To: Jan Beulich <JBeulich@suse.com>
Cc: Keir Fraser <keir@xen.org>, john.baboval@citrix.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	xen-devel <xen-devel@lists.xen.org>,
	Konrad Rzeszutek Wilk <konrad@kernel.org>, Ben Guthro <ben@guthro.net>,
	Thomas Goetz <thomas.goetz@citrix.com>
Subject: Re: [Xen-devel] Xen4.2 S3 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 Tue, Sep 25, 2012 at 5:21 PM, Jan Beulich <JBeulich@suse.com> wrote:

>>>> On 25.09.12 at 16:47, Javier Marcet <jmarcet@gmail.com> wrote:
>> I haven't been able to see the actual patch, I only read a description
>> of what it should do. Two possible places where a wbinvd() call should
>> be added. On the first of these two places there were already calls to
>> wbinvd() just before the halts. I added it to the other one, within
>> xen/arch/x86/domain.c:default_idle and I could complete a
>> suspend/resume cycle without the back trace but after rebooting I
>> tried it again and it failed, more than once.
>
> default_idle() isn't the right place, default_dead_idle() is.
>
> See
> http://xenbits.xen.org/hg/staging/xen-unstable.hg/rev/c8d65d91a6f2

I'm sorry to say it doesn't fix it on my system, i.e., kernel 3.5.3
and xen 4.2.1-pre (the head from
git://xenbits.xen.org/xen.git#stable-4.2)

It really was basically what I had tried yesterday, just with duplicated code.

Adding the wbinvd() only in xen/arch/x86/domain.c was how I was able
to suspend and resume once without the back trace.

Adding the additional call in xen/arch/x86/acpi/cpu_idle.c causes an
instant reboot on resume.


-- 
Javier Marcet <jmarcet@gmail.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 25 19:58:23 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 19: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 1TGbGa-0007mL-Ni; Tue, 25 Sep 2012 19:58:00 +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 1TGbGZ-0007mE-28
	for xen-devel@lists.xen.org; Tue, 25 Sep 2012 19:57:59 +0000
Received: from [85.158.139.83:46253] by server-8.bemta-5.messagelabs.com id
	9A/B9-18073-6CC02605; Tue, 25 Sep 2012 19:57:58 +0000
X-Env-Sender: ben.guthro@gmail.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1348603075!31744180!1
X-Originating-IP: [209.85.223.173]
X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE,
	RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1607 invoked from network); 25 Sep 2012 19:57:57 -0000
Received: from mail-ie0-f173.google.com (HELO mail-ie0-f173.google.com)
	(209.85.223.173)
	by server-5.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Sep 2012 19:57:57 -0000
Received: by iea17 with SMTP id 17so12788362iea.32
	for <xen-devel@lists.xen.org>; Tue, 25 Sep 2012 12:57: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=qKXtDikiFWXGgRTfLX0stH6Lfn6WAtiUCMr5I2sDEFA=;
	b=My3R6jXo21A+Aa67fKU4W5v8yPU0wfDPiCZteFhMwUtfuXUY6WUpwF6/Y41t8NV5dd
	RHxCdUXszE5tmRvu5mfW2ieccwX4cWOX3JGMR+UfLpxCsKzjLev/3TK9dIUbdAIYlhjW
	oXmT4x8Wvgbda8O/II5eY0kL53japgR9G8ci92kI0Ig+IZVry8AqzDu/Zs6ty1rpzAnC
	jgYO5LdTMK/42KILTp+5edSPjD0o9SdJY5sNRaCOJW5IYOn9IVZ3GeZVcqcYq5WUI3Pa
	vwxXpwUhFXxHwGjHpGtzwZdbO2wIHxxv7AUNuJFS5OVaKgiUrw69GrBNs4qbEL/WxvGn
	O2iQ==
MIME-Version: 1.0
Received: by 10.50.5.133 with SMTP id s5mr9091661igs.49.1348603075206; Tue, 25
	Sep 2012 12:57:55 -0700 (PDT)
Received: by 10.64.55.132 with HTTP; Tue, 25 Sep 2012 12:57:55 -0700 (PDT)
In-Reply-To: <CAAnFQG-6VrwaA_OcUJL5X5HBNo8PTME9pNyJbsXqSO34tbD8=g@mail.gmail.com>
References: <CC8273A0.4C9DD%keir@xen.org>
	<50605E9A020000780009D486@nat28.tlf.novell.com>
	<CAOvdn6XmB6rj3_QVU+59V8p24Y5G47AWxVEM=id02JWXkuhibQ@mail.gmail.com>
	<5060640B020000780009D4D2@nat28.tlf.novell.com>
	<CAOvdn6XLy8zR2rb2MEyi2aT9LQiFvFLY_H02p181mTsVLVTZkw@mail.gmail.com>
	<20120924122203.GG8912@reaktio.net>
	<CAOvdn6XV4eoA-FfFns1xhx7HCUqXc7KHxZwyKuT4FHG8s3R5RQ@mail.gmail.com>
	<CAAnFQG9PLQjdh6Ab6=Y5ZGM1s4nGdLekKU=pcKNMxt4rmt_RKA@mail.gmail.com>
	<20120924140411.GH31618@phenom.dumpdata.com>
	<CAAnFQG-tjv5UyF6j-TNHNgme2c4vA0Zxy8AdCiJEVsf2Z0quNA@mail.gmail.com>
	<20120925140611.GB16478@phenom.dumpdata.com>
	<CAAnFQG88ApxKuscXx53Lt2qOyCe0ws6oXSSqBDfW0+oYo5Y3nA@mail.gmail.com>
	<5061E800020000780009DBBA@nat28.tlf.novell.com>
	<CAAnFQG-6VrwaA_OcUJL5X5HBNo8PTME9pNyJbsXqSO34tbD8=g@mail.gmail.com>
Date: Tue, 25 Sep 2012 15:57:55 -0400
X-Google-Sender-Auth: BlVVRGSHeZVPi9MXLo4G4RvqJ0U
Message-ID: <CAOvdn6V4KpnBOtonLxf5VggWbHhA-ZjYoBfv_MykSdMNH+GJ3w@mail.gmail.com>
From: Ben Guthro <ben@guthro.net>
To: Javier Marcet <jmarcet@gmail.com>
Cc: Keir Fraser <keir@xen.org>, john.baboval@citrix.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	xen-devel <xen-devel@lists.xen.org>,
	Konrad Rzeszutek Wilk <konrad@kernel.org>, Jan Beulich <JBeulich@suse.com>,
	Thomas Goetz <thomas.goetz@citrix.com>
Subject: Re: [Xen-devel] Xen4.2 S3 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: multipart/mixed; boundary="===============7324005957430043236=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============7324005957430043236==
Content-Type: multipart/alternative; boundary=e89a8f5035103d9f8004ca8c1fef

--e89a8f5035103d9f8004ca8c1fef
Content-Type: text/plain; charset=ISO-8859-1

You still haven't said if you have the out-of-tree acpi-s3 patches from
Konrad.
Without these patches applied to linux - this is a non-starter.


On Tue, Sep 25, 2012 at 3:55 PM, Javier Marcet <jmarcet@gmail.com> wrote:

> On Tue, Sep 25, 2012 at 5:21 PM, Jan Beulich <JBeulich@suse.com> wrote:
>
> >>>> On 25.09.12 at 16:47, Javier Marcet <jmarcet@gmail.com> wrote:
> >> I haven't been able to see the actual patch, I only read a description
> >> of what it should do. Two possible places where a wbinvd() call should
> >> be added. On the first of these two places there were already calls to
> >> wbinvd() just before the halts. I added it to the other one, within
> >> xen/arch/x86/domain.c:default_idle and I could complete a
> >> suspend/resume cycle without the back trace but after rebooting I
> >> tried it again and it failed, more than once.
> >
> > default_idle() isn't the right place, default_dead_idle() is.
> >
> > See
> > http://xenbits.xen.org/hg/staging/xen-unstable.hg/rev/c8d65d91a6f2
>
> I'm sorry to say it doesn't fix it on my system, i.e., kernel 3.5.3
> and xen 4.2.1-pre (the head from
> git://xenbits.xen.org/xen.git#stable-4.2)
>
> It really was basically what I had tried yesterday, just with duplicated
> code.
>
> Adding the wbinvd() only in xen/arch/x86/domain.c was how I was able
> to suspend and resume once without the back trace.
>
> Adding the additional call in xen/arch/x86/acpi/cpu_idle.c causes an
> instant reboot on resume.
>
>
> --
> Javier Marcet <jmarcet@gmail.com>
>

--e89a8f5035103d9f8004ca8c1fef
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

You still haven&#39;t said if you have the out-of-tree acpi-s3 patches from=
 Konrad.<div>Without these patches applied to linux - this is a non-starter=
.</div><div><br><br><div class=3D"gmail_quote">On Tue, Sep 25, 2012 at 3:55=
 PM, Javier Marcet <span dir=3D"ltr">&lt;<a href=3D"mailto:jmarcet@gmail.co=
m" target=3D"_blank">jmarcet@gmail.com</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div class=3D"im">On Tue, Sep 25, 2012 at 5:=
21 PM, Jan Beulich &lt;<a href=3D"mailto:JBeulich@suse.com">JBeulich@suse.c=
om</a>&gt; wrote:<br>

<br>
</div><div><div class=3D"h5">&gt;&gt;&gt;&gt; On 25.09.12 at 16:47, Javier =
Marcet &lt;<a href=3D"mailto:jmarcet@gmail.com">jmarcet@gmail.com</a>&gt; w=
rote:<br>
&gt;&gt; I haven&#39;t been able to see the actual patch, I only read a des=
cription<br>
&gt;&gt; of what it should do. Two possible places where a wbinvd() call sh=
ould<br>
&gt;&gt; be added. On the first of these two places there were already call=
s to<br>
&gt;&gt; wbinvd() just before the halts. I added it to the other one, withi=
n<br>
&gt;&gt; xen/arch/x86/domain.c:default_idle and I could complete a<br>
&gt;&gt; suspend/resume cycle without the back trace but after rebooting I<=
br>
&gt;&gt; tried it again and it failed, more than once.<br>
&gt;<br>
&gt; default_idle() isn&#39;t the right place, default_dead_idle() is.<br>
&gt;<br>
&gt; See<br>
&gt; <a href=3D"http://xenbits.xen.org/hg/staging/xen-unstable.hg/rev/c8d65=
d91a6f2" target=3D"_blank">http://xenbits.xen.org/hg/staging/xen-unstable.h=
g/rev/c8d65d91a6f2</a><br>
<br>
</div></div>I&#39;m sorry to say it doesn&#39;t fix it on my system, i.e., =
kernel 3.5.3<br>
and xen 4.2.1-pre (the head from<br>
git://<a href=3D"http://xenbits.xen.org/xen.git#stable-4.2" target=3D"_blan=
k">xenbits.xen.org/xen.git#stable-4.2</a>)<br>
<br>
It really was basically what I had tried yesterday, just with duplicated co=
de.<br>
<br>
Adding the wbinvd() only in xen/arch/x86/domain.c was how I was able<br>
to suspend and resume once without the back trace.<br>
<br>
Adding the additional call in xen/arch/x86/acpi/cpu_idle.c causes an<br>
instant reboot on resume.<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
<br>
--<br>
Javier Marcet &lt;<a href=3D"mailto:jmarcet@gmail.com">jmarcet@gmail.com</a=
>&gt;<br>
</font></span></blockquote></div><br></div>

--e89a8f5035103d9f8004ca8c1fef--


--===============7324005957430043236==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============7324005957430043236==--


From xen-devel-bounces@lists.xen.org Tue Sep 25 19:58:23 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 19: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 1TGbGa-0007mL-Ni; Tue, 25 Sep 2012 19:58:00 +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 1TGbGZ-0007mE-28
	for xen-devel@lists.xen.org; Tue, 25 Sep 2012 19:57:59 +0000
Received: from [85.158.139.83:46253] by server-8.bemta-5.messagelabs.com id
	9A/B9-18073-6CC02605; Tue, 25 Sep 2012 19:57:58 +0000
X-Env-Sender: ben.guthro@gmail.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1348603075!31744180!1
X-Originating-IP: [209.85.223.173]
X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE,
	RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1607 invoked from network); 25 Sep 2012 19:57:57 -0000
Received: from mail-ie0-f173.google.com (HELO mail-ie0-f173.google.com)
	(209.85.223.173)
	by server-5.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Sep 2012 19:57:57 -0000
Received: by iea17 with SMTP id 17so12788362iea.32
	for <xen-devel@lists.xen.org>; Tue, 25 Sep 2012 12:57: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=qKXtDikiFWXGgRTfLX0stH6Lfn6WAtiUCMr5I2sDEFA=;
	b=My3R6jXo21A+Aa67fKU4W5v8yPU0wfDPiCZteFhMwUtfuXUY6WUpwF6/Y41t8NV5dd
	RHxCdUXszE5tmRvu5mfW2ieccwX4cWOX3JGMR+UfLpxCsKzjLev/3TK9dIUbdAIYlhjW
	oXmT4x8Wvgbda8O/II5eY0kL53japgR9G8ci92kI0Ig+IZVry8AqzDu/Zs6ty1rpzAnC
	jgYO5LdTMK/42KILTp+5edSPjD0o9SdJY5sNRaCOJW5IYOn9IVZ3GeZVcqcYq5WUI3Pa
	vwxXpwUhFXxHwGjHpGtzwZdbO2wIHxxv7AUNuJFS5OVaKgiUrw69GrBNs4qbEL/WxvGn
	O2iQ==
MIME-Version: 1.0
Received: by 10.50.5.133 with SMTP id s5mr9091661igs.49.1348603075206; Tue, 25
	Sep 2012 12:57:55 -0700 (PDT)
Received: by 10.64.55.132 with HTTP; Tue, 25 Sep 2012 12:57:55 -0700 (PDT)
In-Reply-To: <CAAnFQG-6VrwaA_OcUJL5X5HBNo8PTME9pNyJbsXqSO34tbD8=g@mail.gmail.com>
References: <CC8273A0.4C9DD%keir@xen.org>
	<50605E9A020000780009D486@nat28.tlf.novell.com>
	<CAOvdn6XmB6rj3_QVU+59V8p24Y5G47AWxVEM=id02JWXkuhibQ@mail.gmail.com>
	<5060640B020000780009D4D2@nat28.tlf.novell.com>
	<CAOvdn6XLy8zR2rb2MEyi2aT9LQiFvFLY_H02p181mTsVLVTZkw@mail.gmail.com>
	<20120924122203.GG8912@reaktio.net>
	<CAOvdn6XV4eoA-FfFns1xhx7HCUqXc7KHxZwyKuT4FHG8s3R5RQ@mail.gmail.com>
	<CAAnFQG9PLQjdh6Ab6=Y5ZGM1s4nGdLekKU=pcKNMxt4rmt_RKA@mail.gmail.com>
	<20120924140411.GH31618@phenom.dumpdata.com>
	<CAAnFQG-tjv5UyF6j-TNHNgme2c4vA0Zxy8AdCiJEVsf2Z0quNA@mail.gmail.com>
	<20120925140611.GB16478@phenom.dumpdata.com>
	<CAAnFQG88ApxKuscXx53Lt2qOyCe0ws6oXSSqBDfW0+oYo5Y3nA@mail.gmail.com>
	<5061E800020000780009DBBA@nat28.tlf.novell.com>
	<CAAnFQG-6VrwaA_OcUJL5X5HBNo8PTME9pNyJbsXqSO34tbD8=g@mail.gmail.com>
Date: Tue, 25 Sep 2012 15:57:55 -0400
X-Google-Sender-Auth: BlVVRGSHeZVPi9MXLo4G4RvqJ0U
Message-ID: <CAOvdn6V4KpnBOtonLxf5VggWbHhA-ZjYoBfv_MykSdMNH+GJ3w@mail.gmail.com>
From: Ben Guthro <ben@guthro.net>
To: Javier Marcet <jmarcet@gmail.com>
Cc: Keir Fraser <keir@xen.org>, john.baboval@citrix.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	xen-devel <xen-devel@lists.xen.org>,
	Konrad Rzeszutek Wilk <konrad@kernel.org>, Jan Beulich <JBeulich@suse.com>,
	Thomas Goetz <thomas.goetz@citrix.com>
Subject: Re: [Xen-devel] Xen4.2 S3 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: multipart/mixed; boundary="===============7324005957430043236=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============7324005957430043236==
Content-Type: multipart/alternative; boundary=e89a8f5035103d9f8004ca8c1fef

--e89a8f5035103d9f8004ca8c1fef
Content-Type: text/plain; charset=ISO-8859-1

You still haven't said if you have the out-of-tree acpi-s3 patches from
Konrad.
Without these patches applied to linux - this is a non-starter.


On Tue, Sep 25, 2012 at 3:55 PM, Javier Marcet <jmarcet@gmail.com> wrote:

> On Tue, Sep 25, 2012 at 5:21 PM, Jan Beulich <JBeulich@suse.com> wrote:
>
> >>>> On 25.09.12 at 16:47, Javier Marcet <jmarcet@gmail.com> wrote:
> >> I haven't been able to see the actual patch, I only read a description
> >> of what it should do. Two possible places where a wbinvd() call should
> >> be added. On the first of these two places there were already calls to
> >> wbinvd() just before the halts. I added it to the other one, within
> >> xen/arch/x86/domain.c:default_idle and I could complete a
> >> suspend/resume cycle without the back trace but after rebooting I
> >> tried it again and it failed, more than once.
> >
> > default_idle() isn't the right place, default_dead_idle() is.
> >
> > See
> > http://xenbits.xen.org/hg/staging/xen-unstable.hg/rev/c8d65d91a6f2
>
> I'm sorry to say it doesn't fix it on my system, i.e., kernel 3.5.3
> and xen 4.2.1-pre (the head from
> git://xenbits.xen.org/xen.git#stable-4.2)
>
> It really was basically what I had tried yesterday, just with duplicated
> code.
>
> Adding the wbinvd() only in xen/arch/x86/domain.c was how I was able
> to suspend and resume once without the back trace.
>
> Adding the additional call in xen/arch/x86/acpi/cpu_idle.c causes an
> instant reboot on resume.
>
>
> --
> Javier Marcet <jmarcet@gmail.com>
>

--e89a8f5035103d9f8004ca8c1fef
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

You still haven&#39;t said if you have the out-of-tree acpi-s3 patches from=
 Konrad.<div>Without these patches applied to linux - this is a non-starter=
.</div><div><br><br><div class=3D"gmail_quote">On Tue, Sep 25, 2012 at 3:55=
 PM, Javier Marcet <span dir=3D"ltr">&lt;<a href=3D"mailto:jmarcet@gmail.co=
m" target=3D"_blank">jmarcet@gmail.com</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div class=3D"im">On Tue, Sep 25, 2012 at 5:=
21 PM, Jan Beulich &lt;<a href=3D"mailto:JBeulich@suse.com">JBeulich@suse.c=
om</a>&gt; wrote:<br>

<br>
</div><div><div class=3D"h5">&gt;&gt;&gt;&gt; On 25.09.12 at 16:47, Javier =
Marcet &lt;<a href=3D"mailto:jmarcet@gmail.com">jmarcet@gmail.com</a>&gt; w=
rote:<br>
&gt;&gt; I haven&#39;t been able to see the actual patch, I only read a des=
cription<br>
&gt;&gt; of what it should do. Two possible places where a wbinvd() call sh=
ould<br>
&gt;&gt; be added. On the first of these two places there were already call=
s to<br>
&gt;&gt; wbinvd() just before the halts. I added it to the other one, withi=
n<br>
&gt;&gt; xen/arch/x86/domain.c:default_idle and I could complete a<br>
&gt;&gt; suspend/resume cycle without the back trace but after rebooting I<=
br>
&gt;&gt; tried it again and it failed, more than once.<br>
&gt;<br>
&gt; default_idle() isn&#39;t the right place, default_dead_idle() is.<br>
&gt;<br>
&gt; See<br>
&gt; <a href=3D"http://xenbits.xen.org/hg/staging/xen-unstable.hg/rev/c8d65=
d91a6f2" target=3D"_blank">http://xenbits.xen.org/hg/staging/xen-unstable.h=
g/rev/c8d65d91a6f2</a><br>
<br>
</div></div>I&#39;m sorry to say it doesn&#39;t fix it on my system, i.e., =
kernel 3.5.3<br>
and xen 4.2.1-pre (the head from<br>
git://<a href=3D"http://xenbits.xen.org/xen.git#stable-4.2" target=3D"_blan=
k">xenbits.xen.org/xen.git#stable-4.2</a>)<br>
<br>
It really was basically what I had tried yesterday, just with duplicated co=
de.<br>
<br>
Adding the wbinvd() only in xen/arch/x86/domain.c was how I was able<br>
to suspend and resume once without the back trace.<br>
<br>
Adding the additional call in xen/arch/x86/acpi/cpu_idle.c causes an<br>
instant reboot on resume.<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
<br>
--<br>
Javier Marcet &lt;<a href=3D"mailto:jmarcet@gmail.com">jmarcet@gmail.com</a=
>&gt;<br>
</font></span></blockquote></div><br></div>

--e89a8f5035103d9f8004ca8c1fef--


--===============7324005957430043236==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============7324005957430043236==--


From xen-devel-bounces@lists.xen.org Tue Sep 25 20:09:01 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 20:09:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGbQv-0008Aj-15; Tue, 25 Sep 2012 20:08:41 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jmarcet@gmail.com>) id 1TGbQu-0008Ae-9U
	for xen-devel@lists.xen.org; Tue, 25 Sep 2012 20:08:40 +0000
Received: from [85.158.138.51:48934] by server-2.bemta-3.messagelabs.com id
	D3/EF-04862-74F02605; Tue, 25 Sep 2012 20:08:39 +0000
X-Env-Sender: jmarcet@gmail.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1348603717!13271289!1
X-Originating-IP: [209.85.214.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5259 invoked from network); 25 Sep 2012 20:08:38 -0000
Received: from mail-ob0-f173.google.com (HELO mail-ob0-f173.google.com)
	(209.85.214.173)
	by server-13.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Sep 2012 20:08:38 -0000
Received: by obbta14 with SMTP id ta14so9105872obb.32
	for <xen-devel@lists.xen.org>; Tue, 25 Sep 2012 13:08: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:from:date:message-id:subject:to
	:cc:content-type;
	bh=uidOHlrcCnMFg5c4mxAhIhG9vHGKvfxtbPvLUReIQK8=;
	b=jTVvLGWLtS7hf19xcoESODI33rvYuZofDvF05ItAXs9nfrEfH6EsGB2K4T8ry48xqY
	58AWNo6Nh24wkMsi2CvCBrMVVu56HFmoHjx0SEyiq0R0QZ4XgCiaZsGJJ0u8OINJDEnS
	62+PKiCTsrWaEbUzO3jaXUTEneFyzOfTVMNHTaJI6+U2RCcCTcYN6/RielHW4onHgXIz
	RAmhnq3wj5YUFK8/DRWtPTXrfqSxJqJIMhLqWJ5oOm9SM0JQMKEViIL2VB9tHDDIrDH0
	7xvOJu6PAUg5g4XmnkujVSkeBRONCu7icvHFvYC1Hk0JFhhb2U5pie9PDXcRBicREDH5
	W/8w==
Received: by 10.182.174.68 with SMTP id bq4mr13434851obc.53.1348603717099;
	Tue, 25 Sep 2012 13:08:37 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.60.138.225 with HTTP; Tue, 25 Sep 2012 13:08:15 -0700 (PDT)
In-Reply-To: <CAOvdn6V4KpnBOtonLxf5VggWbHhA-ZjYoBfv_MykSdMNH+GJ3w@mail.gmail.com>
References: <CC8273A0.4C9DD%keir@xen.org>
	<50605E9A020000780009D486@nat28.tlf.novell.com>
	<CAOvdn6XmB6rj3_QVU+59V8p24Y5G47AWxVEM=id02JWXkuhibQ@mail.gmail.com>
	<5060640B020000780009D4D2@nat28.tlf.novell.com>
	<CAOvdn6XLy8zR2rb2MEyi2aT9LQiFvFLY_H02p181mTsVLVTZkw@mail.gmail.com>
	<20120924122203.GG8912@reaktio.net>
	<CAOvdn6XV4eoA-FfFns1xhx7HCUqXc7KHxZwyKuT4FHG8s3R5RQ@mail.gmail.com>
	<CAAnFQG9PLQjdh6Ab6=Y5ZGM1s4nGdLekKU=pcKNMxt4rmt_RKA@mail.gmail.com>
	<20120924140411.GH31618@phenom.dumpdata.com>
	<CAAnFQG-tjv5UyF6j-TNHNgme2c4vA0Zxy8AdCiJEVsf2Z0quNA@mail.gmail.com>
	<20120925140611.GB16478@phenom.dumpdata.com>
	<CAAnFQG88ApxKuscXx53Lt2qOyCe0ws6oXSSqBDfW0+oYo5Y3nA@mail.gmail.com>
	<5061E800020000780009DBBA@nat28.tlf.novell.com>
	<CAAnFQG-6VrwaA_OcUJL5X5HBNo8PTME9pNyJbsXqSO34tbD8=g@mail.gmail.com>
	<CAOvdn6V4KpnBOtonLxf5VggWbHhA-ZjYoBfv_MykSdMNH+GJ3w@mail.gmail.com>
From: Javier Marcet <jmarcet@gmail.com>
Date: Tue, 25 Sep 2012 22:08:15 +0200
Message-ID: <CAAnFQG80mj_Jxf90KxYo71+ZqS2hR-1xZ9wAQ+f8aji-jy2aSA@mail.gmail.com>
To: Ben Guthro <ben@guthro.net>
Cc: Keir Fraser <keir@xen.org>, john.baboval@citrix.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	xen-devel <xen-devel@lists.xen.org>,
	Konrad Rzeszutek Wilk <konrad@kernel.org>, Jan Beulich <JBeulich@suse.com>,
	Thomas Goetz <thomas.goetz@citrix.com>
Subject: Re: [Xen-devel] Xen4.2 S3 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 Tue, Sep 25, 2012 at 9:57 PM, Ben Guthro <ben@guthro.net> wrote:

> You still haven't said if you have the out-of-tree acpi-s3 patches from
> Konrad.
> Without these patches applied to linux - this is a non-starter.

Yes, I _do_ have them applied. If you re-read my previous messages
you'll see I already said it before. Just to be clear, the patches
are:

- x86/acpi/sleep: Provide registration for acpi_suspend_lowlevel
- xen/acpi/sleep: Register to the acpi_suspend_lowlevel a callback.

Both from Konrad from a patch series posted last December on lklm.

If there is any other patch I need for xen, then I don't have it nor I
know which patch.


-- 
Javier Marcet <jmarcet@gmail.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 25 20:09:01 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 20:09:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGbQv-0008Aj-15; Tue, 25 Sep 2012 20:08:41 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jmarcet@gmail.com>) id 1TGbQu-0008Ae-9U
	for xen-devel@lists.xen.org; Tue, 25 Sep 2012 20:08:40 +0000
Received: from [85.158.138.51:48934] by server-2.bemta-3.messagelabs.com id
	D3/EF-04862-74F02605; Tue, 25 Sep 2012 20:08:39 +0000
X-Env-Sender: jmarcet@gmail.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1348603717!13271289!1
X-Originating-IP: [209.85.214.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5259 invoked from network); 25 Sep 2012 20:08:38 -0000
Received: from mail-ob0-f173.google.com (HELO mail-ob0-f173.google.com)
	(209.85.214.173)
	by server-13.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Sep 2012 20:08:38 -0000
Received: by obbta14 with SMTP id ta14so9105872obb.32
	for <xen-devel@lists.xen.org>; Tue, 25 Sep 2012 13:08: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:from:date:message-id:subject:to
	:cc:content-type;
	bh=uidOHlrcCnMFg5c4mxAhIhG9vHGKvfxtbPvLUReIQK8=;
	b=jTVvLGWLtS7hf19xcoESODI33rvYuZofDvF05ItAXs9nfrEfH6EsGB2K4T8ry48xqY
	58AWNo6Nh24wkMsi2CvCBrMVVu56HFmoHjx0SEyiq0R0QZ4XgCiaZsGJJ0u8OINJDEnS
	62+PKiCTsrWaEbUzO3jaXUTEneFyzOfTVMNHTaJI6+U2RCcCTcYN6/RielHW4onHgXIz
	RAmhnq3wj5YUFK8/DRWtPTXrfqSxJqJIMhLqWJ5oOm9SM0JQMKEViIL2VB9tHDDIrDH0
	7xvOJu6PAUg5g4XmnkujVSkeBRONCu7icvHFvYC1Hk0JFhhb2U5pie9PDXcRBicREDH5
	W/8w==
Received: by 10.182.174.68 with SMTP id bq4mr13434851obc.53.1348603717099;
	Tue, 25 Sep 2012 13:08:37 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.60.138.225 with HTTP; Tue, 25 Sep 2012 13:08:15 -0700 (PDT)
In-Reply-To: <CAOvdn6V4KpnBOtonLxf5VggWbHhA-ZjYoBfv_MykSdMNH+GJ3w@mail.gmail.com>
References: <CC8273A0.4C9DD%keir@xen.org>
	<50605E9A020000780009D486@nat28.tlf.novell.com>
	<CAOvdn6XmB6rj3_QVU+59V8p24Y5G47AWxVEM=id02JWXkuhibQ@mail.gmail.com>
	<5060640B020000780009D4D2@nat28.tlf.novell.com>
	<CAOvdn6XLy8zR2rb2MEyi2aT9LQiFvFLY_H02p181mTsVLVTZkw@mail.gmail.com>
	<20120924122203.GG8912@reaktio.net>
	<CAOvdn6XV4eoA-FfFns1xhx7HCUqXc7KHxZwyKuT4FHG8s3R5RQ@mail.gmail.com>
	<CAAnFQG9PLQjdh6Ab6=Y5ZGM1s4nGdLekKU=pcKNMxt4rmt_RKA@mail.gmail.com>
	<20120924140411.GH31618@phenom.dumpdata.com>
	<CAAnFQG-tjv5UyF6j-TNHNgme2c4vA0Zxy8AdCiJEVsf2Z0quNA@mail.gmail.com>
	<20120925140611.GB16478@phenom.dumpdata.com>
	<CAAnFQG88ApxKuscXx53Lt2qOyCe0ws6oXSSqBDfW0+oYo5Y3nA@mail.gmail.com>
	<5061E800020000780009DBBA@nat28.tlf.novell.com>
	<CAAnFQG-6VrwaA_OcUJL5X5HBNo8PTME9pNyJbsXqSO34tbD8=g@mail.gmail.com>
	<CAOvdn6V4KpnBOtonLxf5VggWbHhA-ZjYoBfv_MykSdMNH+GJ3w@mail.gmail.com>
From: Javier Marcet <jmarcet@gmail.com>
Date: Tue, 25 Sep 2012 22:08:15 +0200
Message-ID: <CAAnFQG80mj_Jxf90KxYo71+ZqS2hR-1xZ9wAQ+f8aji-jy2aSA@mail.gmail.com>
To: Ben Guthro <ben@guthro.net>
Cc: Keir Fraser <keir@xen.org>, john.baboval@citrix.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	xen-devel <xen-devel@lists.xen.org>,
	Konrad Rzeszutek Wilk <konrad@kernel.org>, Jan Beulich <JBeulich@suse.com>,
	Thomas Goetz <thomas.goetz@citrix.com>
Subject: Re: [Xen-devel] Xen4.2 S3 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 Tue, Sep 25, 2012 at 9:57 PM, Ben Guthro <ben@guthro.net> wrote:

> You still haven't said if you have the out-of-tree acpi-s3 patches from
> Konrad.
> Without these patches applied to linux - this is a non-starter.

Yes, I _do_ have them applied. If you re-read my previous messages
you'll see I already said it before. Just to be clear, the patches
are:

- x86/acpi/sleep: Provide registration for acpi_suspend_lowlevel
- xen/acpi/sleep: Register to the acpi_suspend_lowlevel a callback.

Both from Konrad from a patch series posted last December on lklm.

If there is any other patch I need for xen, then I don't have it nor I
know which patch.


-- 
Javier Marcet <jmarcet@gmail.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 25 20:51:32 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 20:51:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGc64-0000ST-1N; Tue, 25 Sep 2012 20:51: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 1TGc62-0000SL-0b
	for xen-devel@lists.xensource.com; Tue, 25 Sep 2012 20:51:10 +0000
Received: from [85.158.138.51:27327] by server-3.bemta-3.messagelabs.com id
	2C/E7-21322-D3912605; Tue, 25 Sep 2012 20:51:09 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1348606267!31451900!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTEwNzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22108 invoked from network); 25 Sep 2012 20:51: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;
	25 Sep 2012 20:51:08 -0000
X-IronPort-AV: E=Sophos;i="4.80,485,1344211200"; d="scan'208";a="14760570"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Sep 2012 20:50: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.279.1; Tue, 25 Sep 2012 21:50: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 1TGc5F-0004Id-72;
	Tue, 25 Sep 2012 20:50:21 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1TGc5E-0002sI-RL;
	Tue, 25 Sep 2012 21:50:21 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-13865-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Tue, 25 Sep 2012 21:50:20 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.2-testing test] 13865: 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 13865 xen-4.2-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13865/

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-pv            3 host-install(3)         broken REGR. vs. 13817
 test-amd64-i386-xl-credit2    3 host-install(3)         broken REGR. vs. 13817
 test-amd64-i386-xl            3 host-install(3)         broken REGR. vs. 13817
 test-amd64-i386-rhel6hvm-intel  3 host-install(3)       broken REGR. vs. 13817
 test-amd64-i386-xl-win7-amd64  3 host-install(3)        broken REGR. vs. 13817
 test-i386-i386-win            3 host-install(3)         broken REGR. vs. 13817
 test-i386-i386-xl-winxpsp3    3 host-install(3)         broken REGR. vs. 13817

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore            fail   never pass
 test-i386-i386-xl-qemuu-winxpsp3  9 guest-localmigrate         fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-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-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  2b59edeb0fdd
baseline version:
 xen                  3462914d95d3

------------------------------------------------------------
People who touched revisions under test:
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  Dan Magenheimer <dan.magenheimer@oracle.com>
  Ian Campbell <ian.campbell@citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Steven Maresca <steve@zentific.com>
  Tim Deegan <tim@xen.org>
  Zhenzhong Duan <zhenzhong.duan@oracle.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                                           broken  
 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                                broken  
 test-amd64-i386-xl-credit2                                   broken  
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               broken  
 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                                           broken  
 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                                           broken  
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   broken  


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.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:   25862:2b59edeb0fdd
tag:         tip
user:        Zhenzhong Duan <zhenzhong.duan@oracle.com>
date:        Tue Sep 25 12:19:33 2012 +0200
    
    tmem: bump pool version to 1 to fix restore issue when tmem enabled
    
    Restore fails when tmem is enabled both in hypervisor and guest. This
    is due to spec version mismatch when restoring a pool.
    
    Signed-off-by: Zhenzhong Duan <zhenzhong.duan@oracle.com>
    Acked-by: Dan Magenheimer <dan.magenheimer@oracle.com>
    xen-unstable changeset: 25929:fee83ac77d8c
    xen-unstable date: Wed Sep 19 15:38:47 UTC 2012
    
    
changeset:   25861:1853e31bb956
user:        Jan Beulich <jbeulich@suse.com>
date:        Tue Sep 25 12:18:28 2012 +0200
    
    tmem: cleanup
    
    - one more case of checking for a specific rather than any error
    - drop no longer needed first parameter from cli_put_page()
    - drop a redundant cast
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Dan Magenheimer <dan.magenheimer@oracle.com>
    xen-unstable changeset: 25860:e4cb84111610
    xen-unstable date: Tue Sep 11 12:19:29 UTC 2012
    
    
changeset:   25860:7904c87be3f3
user:        Dan Magenheimer <dan.magenheimer@oracle.com>
date:        Tue Sep 25 12:17:52 2012 +0200
    
    tmem: fixup 2010 cleanup patch that breaks tmem save/restore
    
    20918:a3fa6d444b25 "Fix domain reference leaks" (in Feb 2010, by Jan)
    does some cleanup in addition to the leak fixes.  Unfortunately, that
    cleanup inadvertently resulted in an incorrect fallthrough in a switch
    statement which breaks tmem save/restore.
    
    That broken patch was apparently applied to 4.0-testing and 4.1-testing
    so those are broken as well.
    
    What is the process now for requesting back-patches to 4.0 and 4.1?
    
    (Side note: This does not by itself entirely fix save/restore in 4.2.)
    
    Signed-off-by: Dan Magenheimer <dan.magenheimer@oracle.com>
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    xen-unstable changeset: 25859:16e0392c6594
    xen-unstable date: Tue Sep 11 12:19:03 UTC 2012
    
    
changeset:   25859:52a0b7ca721b
user:        Jan Beulich <jbeulich@suse.com>
date:        Tue Sep 25 12:17:05 2012 +0200
    
    tmem: reduce severity of log messages
    
    Otherwise they can be used by a guest to spam the hypervisor log with
    all settings at their defaults.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Zhenzhong Duan <zhenzhong.duan@oracle.com>
    xen-unstable changeset: 25858:0520982a602a
    xen-unstable date: Tue Sep 11 12:18:36 UTC 2012
    
    
changeset:   25858:22dfc72fdbf3
user:        Jan Beulich <jbeulich@suse.com>
date:        Tue Sep 25 12:16:34 2012 +0200
    
    tmem: properly drop lock on error path in do_tmem_op()
    
    Reported-by: Tim Deegan <tim@xen.org>
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Dan Magenheimer <dan.magenheimer@oracle.com>
    xen-unstable changeset: 25857:109ea6a0c23a
    xen-unstable date: Tue Sep 11 12:18:26 UTC 2012
    
    
changeset:   25857:b4218d4791cd
user:        Jan Beulich <jbeulich@suse.com>
date:        Tue Sep 25 12:16:14 2012 +0200
    
    tmem: properly drop lock on error path in do_tmem_get()
    
    Also remove a bogus assertion.
    
    Reported-by: Tim Deegan <tim@xen.org>
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Dan Magenheimer <dan.magenheimer@oracle.com>
    xen-unstable changeset: 25856:83b97a59888b
    xen-unstable date: Tue Sep 11 12:18:08 UTC 2012
    
    
changeset:   25856:61c35eaf1a88
user:        Jan Beulich <jbeulich@suse.com>
date:        Tue Sep 25 12:15:01 2012 +0200
    
    tmem: detect arithmetic overflow in tmh_copy_{from,to}_client()
    
    This implies adjusting callers to deal with errors other than -EFAULT
    and removing some comments which would otherwise become stale.
    
    Reported-by: Tim Deegan <tim@xen.org>
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Dan Magenheimer <dan.magenheimer@oracle.com>
    xen-unstable changeset: 25855:33b8c42a87ec
    xen-unstable date: Tue Sep 11 12:17:59 UTC 2012
    
    
changeset:   25855:5bc3e774301c
user:        Jan Beulich <jbeulich@suse.com>
date:        Tue Sep 25 12:14:31 2012 +0200
    
    tmem: don't access guest memory without using the accessors intended for this
    
    This is not permitted, not even for buffers coming from Dom0 (and it
    would also break the moment Dom0 runs in HVM mode). An implication from
    the changes here is that tmh_copy_page() can't be used anymore for
    control operations calling tmh_copy_{from,to}_client() (as those pass
    the buffer by virtual address rather than MFN).
    
    Note that tmemc_save_get_next_page() previously didn't set the returned
    handle's pool_id field, while the new code does. It need to be
    confirmed that this is not a problem (otherwise the copy-out operation
    will require further tmh_...() abstractions to be added).
    
    Further note that the patch removes (rather than adjusts) an invalid
    call to unmap_domain_page() (no matching map_domain_page()) from
    tmh_compress_from_client() and adds a missing one to an error return
    path in tmh_copy_from_client().
    
    Finally note that the patch adds a previously missing return statement
    to cli_get_page() (without which that function could de-reference a
    NULL pointer, triggerable from guest mode).
    
    This is part of XSA-15 / CVE-2012-3497.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Dan Magenheimer <dan.magenheimer@oracle.com>
    xen-unstable changeset: 25854:ccd60ed6c555
    xen-unstable date: Tue Sep 11 12:17:49 UTC 2012
    
    
changeset:   25854:b383875a33f0
user:        Ian Campbell <ian.campbell@citrix.com>
date:        Tue Sep 25 12:13:40 2012 +0200
    
    tmem: check for a valid client ("domain") in the save subops
    
    This is part of XSA-15 / CVE-2012-3497.
    
    Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
    Acked-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Dan Magenheimer <dan.magenheimer@oracle.com>
    xen-unstable changeset: 25853:f53c5aadbba9
    xen-unstable date: Tue Sep 11 12:17:27 UTC 2012
    
    
changeset:   25853:da0fd47f59b4
user:        Ian Campbell <ian.campbell@citrix.com>
date:        Tue Sep 25 12:12:48 2012 +0200
    
    tmem: check the pool_id is valid when destroying a tmem pool
    
    This is part of XSA-15 / CVE-2012-3497.
    
    Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
    Acked-by: Dan Magenheimer <dan.magenheimer@oracle.com>
    Acked-by: Jan Beulich <jbeulich@suse.com>
    xen-unstable changeset: 25852:d189d99ef00c
    xen-unstable date: Tue Sep 11 12:06:54 UTC 2012
    
    
changeset:   25852:d188a7ad6c75
user:        Ian Campbell <ian.campbell@citrix.com>
date:        Tue Sep 25 12:12:04 2012 +0200
    
    tmem: consistently make pool_id a uint32_t
    
    Treating it as an int could allow a malicious guest to provide a
    negative pool_Id, by passing the MAX_POOLS_PER_DOMAIN limit check and
    allowing access to the negative offsets of the pool array.
    
    This is part of XSA-15 / CVE-2012-3497.
    
    Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
    Acked-by: Dan Magenheimer <dan.magenheimer@oracle.com>
    Acked-by: Jan Beulich <jbeulich@suse.com>
    xen-unstable changeset: 25851:fcf567acc92a
    xen-unstable date: Tue Sep 11 12:06:43 UTC 2012
    
    
changeset:   25851:e0dc63c822b2
user:        Ian Campbell <ian.campbell@citrix.com>
date:        Tue Sep 25 12:09:19 2012 +0200
    
    tmem: only allow tmem control operations from privileged domains
    
    This is part of XSA-15 / CVE-2012-3497.
    
    Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
    Acked-by: Dan Magenheimer <dan.magenheimer@oracle.com>
    Acked-by-by: Jan Beulich <jbeulich@suse.com>
    xen-unstable changeset: 25850:0dba5a888655
    xen-unstable date: Tue Sep 11 12:06:30 UTC 2012
    
    
changeset:   25850:3462914d95d3
user:        Steven Maresca <steve@zentific.com>
date:        Wed Sep 19 17:33:05 2012 +0200
    
    mem_event: fix regression affecting CR3, CR4 memory events
    
    This is a patch repairing a regression in code previously functional
    in 4.1.x. It appears that, during some refactoring work, calls to
    hvm_memory_event_cr3 and hvm_memory_event_cr4 were lost.
    
    These functions were originally called in mov_to_cr() of vmx.c, but
    the commit  http://xenbits.xen.org/hg/xen-unstable.hg/rev/1276926e3795
    abstracted the original code into generic functions up a level in
    hvm.c, dropping these calls in the process.
    
    Signed-off-by: Steven Maresca <steve@zentific.com>
    Acked-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
    Acked-by: Tim Deegan <tim@xen.org>
    xen-unstable changeset: 25918:7ab899e46347
    xen-unstable date: Mon Sep 17 16:55:12 UTC 2012
    
    
(qemu changes not included)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 25 20:51:32 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 20:51:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGc64-0000ST-1N; Tue, 25 Sep 2012 20:51: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 1TGc62-0000SL-0b
	for xen-devel@lists.xensource.com; Tue, 25 Sep 2012 20:51:10 +0000
Received: from [85.158.138.51:27327] by server-3.bemta-3.messagelabs.com id
	2C/E7-21322-D3912605; Tue, 25 Sep 2012 20:51:09 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1348606267!31451900!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTEwNzk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22108 invoked from network); 25 Sep 2012 20:51: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;
	25 Sep 2012 20:51:08 -0000
X-IronPort-AV: E=Sophos;i="4.80,485,1344211200"; d="scan'208";a="14760570"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Sep 2012 20:50: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.279.1; Tue, 25 Sep 2012 21:50: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 1TGc5F-0004Id-72;
	Tue, 25 Sep 2012 20:50:21 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1TGc5E-0002sI-RL;
	Tue, 25 Sep 2012 21:50:21 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-13865-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Tue, 25 Sep 2012 21:50:20 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.2-testing test] 13865: 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 13865 xen-4.2-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13865/

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-pv            3 host-install(3)         broken REGR. vs. 13817
 test-amd64-i386-xl-credit2    3 host-install(3)         broken REGR. vs. 13817
 test-amd64-i386-xl            3 host-install(3)         broken REGR. vs. 13817
 test-amd64-i386-rhel6hvm-intel  3 host-install(3)       broken REGR. vs. 13817
 test-amd64-i386-xl-win7-amd64  3 host-install(3)        broken REGR. vs. 13817
 test-i386-i386-win            3 host-install(3)         broken REGR. vs. 13817
 test-i386-i386-xl-winxpsp3    3 host-install(3)         broken REGR. vs. 13817

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore            fail   never pass
 test-i386-i386-xl-qemuu-winxpsp3  9 guest-localmigrate         fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-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-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  2b59edeb0fdd
baseline version:
 xen                  3462914d95d3

------------------------------------------------------------
People who touched revisions under test:
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  Dan Magenheimer <dan.magenheimer@oracle.com>
  Ian Campbell <ian.campbell@citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Steven Maresca <steve@zentific.com>
  Tim Deegan <tim@xen.org>
  Zhenzhong Duan <zhenzhong.duan@oracle.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                                           broken  
 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                                broken  
 test-amd64-i386-xl-credit2                                   broken  
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               broken  
 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                                           broken  
 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                                           broken  
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   broken  


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.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:   25862:2b59edeb0fdd
tag:         tip
user:        Zhenzhong Duan <zhenzhong.duan@oracle.com>
date:        Tue Sep 25 12:19:33 2012 +0200
    
    tmem: bump pool version to 1 to fix restore issue when tmem enabled
    
    Restore fails when tmem is enabled both in hypervisor and guest. This
    is due to spec version mismatch when restoring a pool.
    
    Signed-off-by: Zhenzhong Duan <zhenzhong.duan@oracle.com>
    Acked-by: Dan Magenheimer <dan.magenheimer@oracle.com>
    xen-unstable changeset: 25929:fee83ac77d8c
    xen-unstable date: Wed Sep 19 15:38:47 UTC 2012
    
    
changeset:   25861:1853e31bb956
user:        Jan Beulich <jbeulich@suse.com>
date:        Tue Sep 25 12:18:28 2012 +0200
    
    tmem: cleanup
    
    - one more case of checking for a specific rather than any error
    - drop no longer needed first parameter from cli_put_page()
    - drop a redundant cast
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Dan Magenheimer <dan.magenheimer@oracle.com>
    xen-unstable changeset: 25860:e4cb84111610
    xen-unstable date: Tue Sep 11 12:19:29 UTC 2012
    
    
changeset:   25860:7904c87be3f3
user:        Dan Magenheimer <dan.magenheimer@oracle.com>
date:        Tue Sep 25 12:17:52 2012 +0200
    
    tmem: fixup 2010 cleanup patch that breaks tmem save/restore
    
    20918:a3fa6d444b25 "Fix domain reference leaks" (in Feb 2010, by Jan)
    does some cleanup in addition to the leak fixes.  Unfortunately, that
    cleanup inadvertently resulted in an incorrect fallthrough in a switch
    statement which breaks tmem save/restore.
    
    That broken patch was apparently applied to 4.0-testing and 4.1-testing
    so those are broken as well.
    
    What is the process now for requesting back-patches to 4.0 and 4.1?
    
    (Side note: This does not by itself entirely fix save/restore in 4.2.)
    
    Signed-off-by: Dan Magenheimer <dan.magenheimer@oracle.com>
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    xen-unstable changeset: 25859:16e0392c6594
    xen-unstable date: Tue Sep 11 12:19:03 UTC 2012
    
    
changeset:   25859:52a0b7ca721b
user:        Jan Beulich <jbeulich@suse.com>
date:        Tue Sep 25 12:17:05 2012 +0200
    
    tmem: reduce severity of log messages
    
    Otherwise they can be used by a guest to spam the hypervisor log with
    all settings at their defaults.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Zhenzhong Duan <zhenzhong.duan@oracle.com>
    xen-unstable changeset: 25858:0520982a602a
    xen-unstable date: Tue Sep 11 12:18:36 UTC 2012
    
    
changeset:   25858:22dfc72fdbf3
user:        Jan Beulich <jbeulich@suse.com>
date:        Tue Sep 25 12:16:34 2012 +0200
    
    tmem: properly drop lock on error path in do_tmem_op()
    
    Reported-by: Tim Deegan <tim@xen.org>
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Dan Magenheimer <dan.magenheimer@oracle.com>
    xen-unstable changeset: 25857:109ea6a0c23a
    xen-unstable date: Tue Sep 11 12:18:26 UTC 2012
    
    
changeset:   25857:b4218d4791cd
user:        Jan Beulich <jbeulich@suse.com>
date:        Tue Sep 25 12:16:14 2012 +0200
    
    tmem: properly drop lock on error path in do_tmem_get()
    
    Also remove a bogus assertion.
    
    Reported-by: Tim Deegan <tim@xen.org>
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Dan Magenheimer <dan.magenheimer@oracle.com>
    xen-unstable changeset: 25856:83b97a59888b
    xen-unstable date: Tue Sep 11 12:18:08 UTC 2012
    
    
changeset:   25856:61c35eaf1a88
user:        Jan Beulich <jbeulich@suse.com>
date:        Tue Sep 25 12:15:01 2012 +0200
    
    tmem: detect arithmetic overflow in tmh_copy_{from,to}_client()
    
    This implies adjusting callers to deal with errors other than -EFAULT
    and removing some comments which would otherwise become stale.
    
    Reported-by: Tim Deegan <tim@xen.org>
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Dan Magenheimer <dan.magenheimer@oracle.com>
    xen-unstable changeset: 25855:33b8c42a87ec
    xen-unstable date: Tue Sep 11 12:17:59 UTC 2012
    
    
changeset:   25855:5bc3e774301c
user:        Jan Beulich <jbeulich@suse.com>
date:        Tue Sep 25 12:14:31 2012 +0200
    
    tmem: don't access guest memory without using the accessors intended for this
    
    This is not permitted, not even for buffers coming from Dom0 (and it
    would also break the moment Dom0 runs in HVM mode). An implication from
    the changes here is that tmh_copy_page() can't be used anymore for
    control operations calling tmh_copy_{from,to}_client() (as those pass
    the buffer by virtual address rather than MFN).
    
    Note that tmemc_save_get_next_page() previously didn't set the returned
    handle's pool_id field, while the new code does. It need to be
    confirmed that this is not a problem (otherwise the copy-out operation
    will require further tmh_...() abstractions to be added).
    
    Further note that the patch removes (rather than adjusts) an invalid
    call to unmap_domain_page() (no matching map_domain_page()) from
    tmh_compress_from_client() and adds a missing one to an error return
    path in tmh_copy_from_client().
    
    Finally note that the patch adds a previously missing return statement
    to cli_get_page() (without which that function could de-reference a
    NULL pointer, triggerable from guest mode).
    
    This is part of XSA-15 / CVE-2012-3497.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Dan Magenheimer <dan.magenheimer@oracle.com>
    xen-unstable changeset: 25854:ccd60ed6c555
    xen-unstable date: Tue Sep 11 12:17:49 UTC 2012
    
    
changeset:   25854:b383875a33f0
user:        Ian Campbell <ian.campbell@citrix.com>
date:        Tue Sep 25 12:13:40 2012 +0200
    
    tmem: check for a valid client ("domain") in the save subops
    
    This is part of XSA-15 / CVE-2012-3497.
    
    Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
    Acked-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Dan Magenheimer <dan.magenheimer@oracle.com>
    xen-unstable changeset: 25853:f53c5aadbba9
    xen-unstable date: Tue Sep 11 12:17:27 UTC 2012
    
    
changeset:   25853:da0fd47f59b4
user:        Ian Campbell <ian.campbell@citrix.com>
date:        Tue Sep 25 12:12:48 2012 +0200
    
    tmem: check the pool_id is valid when destroying a tmem pool
    
    This is part of XSA-15 / CVE-2012-3497.
    
    Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
    Acked-by: Dan Magenheimer <dan.magenheimer@oracle.com>
    Acked-by: Jan Beulich <jbeulich@suse.com>
    xen-unstable changeset: 25852:d189d99ef00c
    xen-unstable date: Tue Sep 11 12:06:54 UTC 2012
    
    
changeset:   25852:d188a7ad6c75
user:        Ian Campbell <ian.campbell@citrix.com>
date:        Tue Sep 25 12:12:04 2012 +0200
    
    tmem: consistently make pool_id a uint32_t
    
    Treating it as an int could allow a malicious guest to provide a
    negative pool_Id, by passing the MAX_POOLS_PER_DOMAIN limit check and
    allowing access to the negative offsets of the pool array.
    
    This is part of XSA-15 / CVE-2012-3497.
    
    Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
    Acked-by: Dan Magenheimer <dan.magenheimer@oracle.com>
    Acked-by: Jan Beulich <jbeulich@suse.com>
    xen-unstable changeset: 25851:fcf567acc92a
    xen-unstable date: Tue Sep 11 12:06:43 UTC 2012
    
    
changeset:   25851:e0dc63c822b2
user:        Ian Campbell <ian.campbell@citrix.com>
date:        Tue Sep 25 12:09:19 2012 +0200
    
    tmem: only allow tmem control operations from privileged domains
    
    This is part of XSA-15 / CVE-2012-3497.
    
    Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
    Acked-by: Dan Magenheimer <dan.magenheimer@oracle.com>
    Acked-by-by: Jan Beulich <jbeulich@suse.com>
    xen-unstable changeset: 25850:0dba5a888655
    xen-unstable date: Tue Sep 11 12:06:30 UTC 2012
    
    
changeset:   25850:3462914d95d3
user:        Steven Maresca <steve@zentific.com>
date:        Wed Sep 19 17:33:05 2012 +0200
    
    mem_event: fix regression affecting CR3, CR4 memory events
    
    This is a patch repairing a regression in code previously functional
    in 4.1.x. It appears that, during some refactoring work, calls to
    hvm_memory_event_cr3 and hvm_memory_event_cr4 were lost.
    
    These functions were originally called in mov_to_cr() of vmx.c, but
    the commit  http://xenbits.xen.org/hg/xen-unstable.hg/rev/1276926e3795
    abstracted the original code into generic functions up a level in
    hvm.c, dropping these calls in the process.
    
    Signed-off-by: Steven Maresca <steve@zentific.com>
    Acked-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
    Acked-by: Tim Deegan <tim@xen.org>
    xen-unstable changeset: 25918:7ab899e46347
    xen-unstable date: Mon Sep 17 16:55:12 UTC 2012
    
    
(qemu changes not included)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 25 21:39:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 21:39:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGcq7-0001EV-1g; Tue, 25 Sep 2012 21:38:47 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1TGcq3-0001Dr-KP
	for xen-devel@lists.xensource.com; Tue, 25 Sep 2012 21:38:44 +0000
Received: from [85.158.139.211:10233] by server-6.bemta-5.messagelabs.com id
	30/1C-14717-26422605; Tue, 25 Sep 2012 21:38:42 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-4.tower-206.messagelabs.com!1348609120!19962709!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDc3MjczNg==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31943 invoked from network); 25 Sep 2012 21:38:42 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-4.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 25 Sep 2012 21:38:42 -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 q8PLccNl007055
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 25 Sep 2012 21:38:39 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q8PLcbPa005955
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 25 Sep 2012 21:38:38 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
	q8PLcbjg004824; Tue, 25 Sep 2012 16:38:37 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 25 Sep 2012 14:38:37 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id EBC4D4035E; Tue, 25 Sep 2012 17:27:21 -0400 (EDT)
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: linux-kernel@vger.kernel.org, xen-devel@lists.xensource.com
Date: Tue, 25 Sep 2012 17:27:20 -0400
Message-Id: <1348608440-4018-3-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.7.7.6
In-Reply-To: <1348608440-4018-1-git-send-email-konrad.wilk@oracle.com>
References: <1348608440-4018-1-git-send-email-konrad.wilk@oracle.com>
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: [Xen-devel] [PATCH 2/2] xen/pciback: When resetting the device
	don't disable twice.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 call 'pci_disable_device' which sets the bus_master to zero
and it also disables the PCI_COMMAND. There is no need to
do it outside the PCI library.

Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 drivers/xen/xen-pciback/pciback_ops.c |    4 ----
 1 files changed, 0 insertions(+), 4 deletions(-)

diff --git a/drivers/xen/xen-pciback/pciback_ops.c b/drivers/xen/xen-pciback/pciback_ops.c
index 97f5d26..2e62279 100644
--- a/drivers/xen/xen-pciback/pciback_ops.c
+++ b/drivers/xen/xen-pciback/pciback_ops.c
@@ -114,10 +114,6 @@ void xen_pcibk_reset_device(struct pci_dev *dev)
 			pci_disable_msi(dev);
 #endif
 		pci_disable_device(dev);
-
-		pci_write_config_word(dev, PCI_COMMAND, 0);
-
-		dev->is_busmaster = 0;
 	} else {
 		pci_read_config_word(dev, PCI_COMMAND, &cmd);
 		if (cmd & (PCI_COMMAND_INVALIDATE)) {
-- 
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 Sep 25 21:39:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 21:39:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGcq7-0001EV-1g; Tue, 25 Sep 2012 21:38:47 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1TGcq3-0001Dr-KP
	for xen-devel@lists.xensource.com; Tue, 25 Sep 2012 21:38:44 +0000
Received: from [85.158.139.211:10233] by server-6.bemta-5.messagelabs.com id
	30/1C-14717-26422605; Tue, 25 Sep 2012 21:38:42 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-4.tower-206.messagelabs.com!1348609120!19962709!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDc3MjczNg==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31943 invoked from network); 25 Sep 2012 21:38:42 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-4.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 25 Sep 2012 21:38:42 -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 q8PLccNl007055
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 25 Sep 2012 21:38:39 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q8PLcbPa005955
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 25 Sep 2012 21:38:38 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
	q8PLcbjg004824; Tue, 25 Sep 2012 16:38:37 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 25 Sep 2012 14:38:37 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id EBC4D4035E; Tue, 25 Sep 2012 17:27:21 -0400 (EDT)
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: linux-kernel@vger.kernel.org, xen-devel@lists.xensource.com
Date: Tue, 25 Sep 2012 17:27:20 -0400
Message-Id: <1348608440-4018-3-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.7.7.6
In-Reply-To: <1348608440-4018-1-git-send-email-konrad.wilk@oracle.com>
References: <1348608440-4018-1-git-send-email-konrad.wilk@oracle.com>
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: [Xen-devel] [PATCH 2/2] xen/pciback: When resetting the device
	don't disable twice.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 call 'pci_disable_device' which sets the bus_master to zero
and it also disables the PCI_COMMAND. There is no need to
do it outside the PCI library.

Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 drivers/xen/xen-pciback/pciback_ops.c |    4 ----
 1 files changed, 0 insertions(+), 4 deletions(-)

diff --git a/drivers/xen/xen-pciback/pciback_ops.c b/drivers/xen/xen-pciback/pciback_ops.c
index 97f5d26..2e62279 100644
--- a/drivers/xen/xen-pciback/pciback_ops.c
+++ b/drivers/xen/xen-pciback/pciback_ops.c
@@ -114,10 +114,6 @@ void xen_pcibk_reset_device(struct pci_dev *dev)
 			pci_disable_msi(dev);
 #endif
 		pci_disable_device(dev);
-
-		pci_write_config_word(dev, PCI_COMMAND, 0);
-
-		dev->is_busmaster = 0;
 	} else {
 		pci_read_config_word(dev, PCI_COMMAND, &cmd);
 		if (cmd & (PCI_COMMAND_INVALIDATE)) {
-- 
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 Sep 25 21:39:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 21:39:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGcq9-0001Ez-Eo; Tue, 25 Sep 2012 21:38:49 +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 1TGcq7-0001Dm-CT
	for xen-devel@lists.xensource.com; Tue, 25 Sep 2012 21:38:47 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1348609119!7180587!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzYyNzYy\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2340 invoked from network); 25 Sep 2012 21:38:41 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-10.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 25 Sep 2012 21:38:41 -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 q8PLcciu015750
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 25 Sep 2012 21:38:38 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
	q8PLcbib014305
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 25 Sep 2012 21:38:38 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
	q8PLcbGW030957; Tue, 25 Sep 2012 16:38:37 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 25 Sep 2012 14:38:37 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id E6F1140357; Tue, 25 Sep 2012 17:27:21 -0400 (EDT)
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: linux-kernel@vger.kernel.org, xen-devel@lists.xensource.com
Date: Tue, 25 Sep 2012 17:27:19 -0400
Message-Id: <1348608440-4018-2-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.7.7.6
In-Reply-To: <1348608440-4018-1-git-send-email-konrad.wilk@oracle.com>
References: <1348608440-4018-1-git-send-email-konrad.wilk@oracle.com>
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: stable@vger.kernel.org, konrad.wilk@oracle.com
Subject: [Xen-devel] [PATCH 1/2] xen/pciback: Restore the PCI config space
	after an FLR.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

When we do an FLR, or D0->D3_hot we may lose the BARs as the
device has turned itself off (and on). This means the device cannot
function unless the pci_restore_state is called - which it is
when the PCI device is unbound from the Xen PCI backend driver.
For PV guests it ends up calling pci_enable_device / pci_enable_msi[x]
which does the proper steps

That however is not happening if a HVM guest is run as QEMU
deals with PCI configuration space. QEMU also requires that the
device be "parked"  under the ownership of a pci-stub driver to
guarantee that the PCI device is not being used. Hence we
follow the same incantation as pci_reset_function does - by
doing an FLR, then restoring the PCI configuration space.

The result of this patch is that when you run lspci, you get
now this:

-       Region 0: [virtual] Memory at fe8c0000 (32-bit, non-prefetchable) [size=128K]
-       Region 1: [virtual] Memory at fe800000 (32-bit, non-prefetchable) [size=512K]
+       Region 0: Memory at fe8c0000 (32-bit, non-prefetchable) [size=128K]
+       Region 1: Memory at fe800000 (32-bit, non-prefetchable) [size=512K]
        Region 2: I/O ports at c000 [size=32]
-       Region 3: [virtual] Memory at fe8e0000 (32-bit, non-prefetchable) [size=16K]
+       Region 3: Memory at fe8e0000 (32-bit, non-prefetchable) [size=16K]

The [virtual] means that lspci read those entries from SysFS but when
it read them from the device it got a different value (0xfffffff).

CC: stable@vger.kernel.org # only for v3.4 and v3.5
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 drivers/xen/xen-pciback/pci_stub.c |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/drivers/xen/xen-pciback/pci_stub.c b/drivers/xen/xen-pciback/pci_stub.c
index acec6fa..e5a0c13 100644
--- a/drivers/xen/xen-pciback/pci_stub.c
+++ b/drivers/xen/xen-pciback/pci_stub.c
@@ -362,6 +362,7 @@ static int __devinit pcistub_init_device(struct pci_dev *dev)
 	else {
 		dev_dbg(&dev->dev, "reseting (FLR, D3, etc) the device\n");
 		__pci_reset_function_locked(dev);
+		pci_restore_state(dev);
 	}
 	/* Now disable the device (this also ensures some private device
 	 * data is setup before we export)
-- 
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 Sep 25 21:39:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 21:39:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGcq9-0001Ez-Eo; Tue, 25 Sep 2012 21:38:49 +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 1TGcq7-0001Dm-CT
	for xen-devel@lists.xensource.com; Tue, 25 Sep 2012 21:38:47 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1348609119!7180587!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzYyNzYy\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2340 invoked from network); 25 Sep 2012 21:38:41 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-10.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 25 Sep 2012 21:38:41 -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 q8PLcciu015750
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 25 Sep 2012 21:38:38 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
	q8PLcbib014305
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 25 Sep 2012 21:38:38 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
	q8PLcbGW030957; Tue, 25 Sep 2012 16:38:37 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 25 Sep 2012 14:38:37 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id E6F1140357; Tue, 25 Sep 2012 17:27:21 -0400 (EDT)
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: linux-kernel@vger.kernel.org, xen-devel@lists.xensource.com
Date: Tue, 25 Sep 2012 17:27:19 -0400
Message-Id: <1348608440-4018-2-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.7.7.6
In-Reply-To: <1348608440-4018-1-git-send-email-konrad.wilk@oracle.com>
References: <1348608440-4018-1-git-send-email-konrad.wilk@oracle.com>
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: stable@vger.kernel.org, konrad.wilk@oracle.com
Subject: [Xen-devel] [PATCH 1/2] xen/pciback: Restore the PCI config space
	after an FLR.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

When we do an FLR, or D0->D3_hot we may lose the BARs as the
device has turned itself off (and on). This means the device cannot
function unless the pci_restore_state is called - which it is
when the PCI device is unbound from the Xen PCI backend driver.
For PV guests it ends up calling pci_enable_device / pci_enable_msi[x]
which does the proper steps

That however is not happening if a HVM guest is run as QEMU
deals with PCI configuration space. QEMU also requires that the
device be "parked"  under the ownership of a pci-stub driver to
guarantee that the PCI device is not being used. Hence we
follow the same incantation as pci_reset_function does - by
doing an FLR, then restoring the PCI configuration space.

The result of this patch is that when you run lspci, you get
now this:

-       Region 0: [virtual] Memory at fe8c0000 (32-bit, non-prefetchable) [size=128K]
-       Region 1: [virtual] Memory at fe800000 (32-bit, non-prefetchable) [size=512K]
+       Region 0: Memory at fe8c0000 (32-bit, non-prefetchable) [size=128K]
+       Region 1: Memory at fe800000 (32-bit, non-prefetchable) [size=512K]
        Region 2: I/O ports at c000 [size=32]
-       Region 3: [virtual] Memory at fe8e0000 (32-bit, non-prefetchable) [size=16K]
+       Region 3: Memory at fe8e0000 (32-bit, non-prefetchable) [size=16K]

The [virtual] means that lspci read those entries from SysFS but when
it read them from the device it got a different value (0xfffffff).

CC: stable@vger.kernel.org # only for v3.4 and v3.5
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 drivers/xen/xen-pciback/pci_stub.c |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/drivers/xen/xen-pciback/pci_stub.c b/drivers/xen/xen-pciback/pci_stub.c
index acec6fa..e5a0c13 100644
--- a/drivers/xen/xen-pciback/pci_stub.c
+++ b/drivers/xen/xen-pciback/pci_stub.c
@@ -362,6 +362,7 @@ static int __devinit pcistub_init_device(struct pci_dev *dev)
 	else {
 		dev_dbg(&dev->dev, "reseting (FLR, D3, etc) the device\n");
 		__pci_reset_function_locked(dev);
+		pci_restore_state(dev);
 	}
 	/* Now disable the device (this also ensures some private device
 	 * data is setup before we export)
-- 
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 Sep 25 21:39:09 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 21:39:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGcq4-0001E8-Fo; Tue, 25 Sep 2012 21:38: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 1TGcq2-0001Dl-C0
	for xen-devel@lists.xensource.com; Tue, 25 Sep 2012 21:38:42 +0000
Received: from [85.158.143.35:27745] by server-3.bemta-4.messagelabs.com id
	2F/CF-10986-16422605; Tue, 25 Sep 2012 21:38:41 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1348609119!12728576!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzY0MTUx\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6514 invoked from network); 25 Sep 2012 21:38:40 -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; 25 Sep 2012 21:38:40 -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 q8PLcchS015759
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 25 Sep 2012 21:38:39 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q8PLcbZK005960
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 25 Sep 2012 21:38:38 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
	q8PLcbFQ030953; Tue, 25 Sep 2012 16:38:37 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 25 Sep 2012 14:38:36 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id E0C0E4035A; Tue, 25 Sep 2012 17:27:21 -0400 (EDT)
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: linux-kernel@vger.kernel.org, xen-devel@lists.xensource.com
Date: Tue, 25 Sep 2012 17:27:18 -0400
Message-Id: <1348608440-4018-1-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.7.7.6
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Subject: [Xen-devel] [PATCH] fixes to xen-pciback for v3.7 (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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

One fixes that I thought I had fixed but not so. This was discovered
when trying to passthrough an PCIe network card to an PVHVM guest
and finding that it can't use MSIs. I thought I had it fixed with 
git commit 80ba77dfbce85f2d1be54847de3c866de1b18a9a
"xen/pciback: Fix proper FLR steps." but that fixed only one use
case (bind the device to xen-pciback, then unbind it).
    
The underlaying reason was that after we do an FLR (if the card supports it),
we also do a D3 (so turn off the PCIe card), then followed by a D0
(power is back).  However we did not the follow the rest of the process
that pci_reset_function does - restore the device's PCI configuration state!

(Note: We cannot use pci_reset_function as it holds a mutex that we
hold as well - so we use the low-level reset functions that we can
invoke and hold a mutex - and we forgot to do the right calls that
pci_reset_function does).

With this patch:
 [PATCH 1/2] xen/pciback: Restore the PCI config space after an FLR.

I can pass through an PCIe e1000e card succesfully to my Win7 and Linux
guest.

This patch:
 [PATCH 2/2] xen/pciback: When resetting the device don't disable

is just a cleanup.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 25 21:39:09 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 21:39:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGcq4-0001E8-Fo; Tue, 25 Sep 2012 21:38: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 1TGcq2-0001Dl-C0
	for xen-devel@lists.xensource.com; Tue, 25 Sep 2012 21:38:42 +0000
Received: from [85.158.143.35:27745] by server-3.bemta-4.messagelabs.com id
	2F/CF-10986-16422605; Tue, 25 Sep 2012 21:38:41 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1348609119!12728576!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzY0MTUx\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6514 invoked from network); 25 Sep 2012 21:38:40 -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; 25 Sep 2012 21:38:40 -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 q8PLcchS015759
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 25 Sep 2012 21:38:39 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q8PLcbZK005960
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 25 Sep 2012 21:38:38 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
	q8PLcbFQ030953; Tue, 25 Sep 2012 16:38:37 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 25 Sep 2012 14:38:36 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id E0C0E4035A; Tue, 25 Sep 2012 17:27:21 -0400 (EDT)
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: linux-kernel@vger.kernel.org, xen-devel@lists.xensource.com
Date: Tue, 25 Sep 2012 17:27:18 -0400
Message-Id: <1348608440-4018-1-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.7.7.6
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Subject: [Xen-devel] [PATCH] fixes to xen-pciback for v3.7 (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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

One fixes that I thought I had fixed but not so. This was discovered
when trying to passthrough an PCIe network card to an PVHVM guest
and finding that it can't use MSIs. I thought I had it fixed with 
git commit 80ba77dfbce85f2d1be54847de3c866de1b18a9a
"xen/pciback: Fix proper FLR steps." but that fixed only one use
case (bind the device to xen-pciback, then unbind it).
    
The underlaying reason was that after we do an FLR (if the card supports it),
we also do a D3 (so turn off the PCIe card), then followed by a D0
(power is back).  However we did not the follow the rest of the process
that pci_reset_function does - restore the device's PCI configuration state!

(Note: We cannot use pci_reset_function as it holds a mutex that we
hold as well - so we use the low-level reset functions that we can
invoke and hold a mutex - and we forgot to do the right calls that
pci_reset_function does).

With this patch:
 [PATCH 1/2] xen/pciback: Restore the PCI config space after an FLR.

I can pass through an PCIe e1000e card succesfully to my Win7 and Linux
guest.

This patch:
 [PATCH 2/2] xen/pciback: When resetting the device don't disable

is just a cleanup.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 25 21:48:18 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 21:48:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGcz4-0001wH-60; Tue, 25 Sep 2012 21:48:02 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1TGcz2-0001wB-8j
	for xen-devel@lists.xensource.com; Tue, 25 Sep 2012 21:48:00 +0000
Received: from [85.158.143.35:10208] by server-2.bemta-4.messagelabs.com id
	23/27-06610-F8622605; Tue, 25 Sep 2012 21:47:59 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1348609677!16307289!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDc3NDE3Nw==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14058 invoked from network); 25 Sep 2012 21:47:59 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-14.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 25 Sep 2012 21:47:59 -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 q8PLlj0F014830
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 25 Sep 2012 21:47: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
	q8PLli0b020703
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 25 Sep 2012 21:47:45 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
	q8PLlh9o009029; Tue, 25 Sep 2012 16:47:43 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 25 Sep 2012 14:47:43 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 6B22A4035A; Tue, 25 Sep 2012 17:36:28 -0400 (EDT)
Date: Tue, 25 Sep 2012 17:36:28 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: William Dauchy <wdauchy@gmail.com>
Message-ID: <20120925213628.GA5372@phenom.dumpdata.com>
References: <CAJ75kXZEaCj4Jqs_qm46d7U-s1C2hkAONs8c5Audrw2c3X=nBA@mail.gmail.com>
	<20120920134851.GB1998@localhost.localdomain>
	<CAJ75kXZ0depUJF_h0yok-r4aL0TBGnqTpW_PKT4Q7P1_6R4X2A@mail.gmail.com>
	<20120920162337.GB8912@reaktio.net>
	<CAJ75kXaXbitBvosYp8Sv_548XbvdxU=M_NSSHTb_5d56=-n4nA@mail.gmail.com>
	<20120920163525.GC8912@reaktio.net>
	<CAJ75kXZnb82GnssNWxyGMHjTYiRQCRsNdPeYdEb-tsvkshpfEg@mail.gmail.com>
	<20120920212823.GE27312@konrad-lan.dumpdata.com>
	<CAJ75kXZjuUgQfc=8tz2F_UEwnQWRD7AhyMOM1L+DSMFzoss9Dw@mail.gmail.com>
	<CAJ75kXbaj0vHeNDfu5hwEp8jL9zJOwpryYEY0UesvEJd388HJQ@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAJ75kXbaj0vHeNDfu5hwEp8jL9zJOwpryYEY0UesvEJd388HJQ@mail.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
Subject: Re: [Xen-devel] Error getting mfn
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Sep 25, 2012 at 10:40:00AM +0200, William Dauchy wrote:
> Hello Konrad,
> 
> Just wondering if you forgot about this thread.

No. I had reply saved up and then I got preempted.
> 
> -- 
> William

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 25 21:48:18 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 21:48:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGcz4-0001wH-60; Tue, 25 Sep 2012 21:48:02 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1TGcz2-0001wB-8j
	for xen-devel@lists.xensource.com; Tue, 25 Sep 2012 21:48:00 +0000
Received: from [85.158.143.35:10208] by server-2.bemta-4.messagelabs.com id
	23/27-06610-F8622605; Tue, 25 Sep 2012 21:47:59 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1348609677!16307289!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDc3NDE3Nw==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14058 invoked from network); 25 Sep 2012 21:47:59 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-14.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 25 Sep 2012 21:47:59 -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 q8PLlj0F014830
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 25 Sep 2012 21:47: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
	q8PLli0b020703
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 25 Sep 2012 21:47:45 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
	q8PLlh9o009029; Tue, 25 Sep 2012 16:47:43 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 25 Sep 2012 14:47:43 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 6B22A4035A; Tue, 25 Sep 2012 17:36:28 -0400 (EDT)
Date: Tue, 25 Sep 2012 17:36:28 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: William Dauchy <wdauchy@gmail.com>
Message-ID: <20120925213628.GA5372@phenom.dumpdata.com>
References: <CAJ75kXZEaCj4Jqs_qm46d7U-s1C2hkAONs8c5Audrw2c3X=nBA@mail.gmail.com>
	<20120920134851.GB1998@localhost.localdomain>
	<CAJ75kXZ0depUJF_h0yok-r4aL0TBGnqTpW_PKT4Q7P1_6R4X2A@mail.gmail.com>
	<20120920162337.GB8912@reaktio.net>
	<CAJ75kXaXbitBvosYp8Sv_548XbvdxU=M_NSSHTb_5d56=-n4nA@mail.gmail.com>
	<20120920163525.GC8912@reaktio.net>
	<CAJ75kXZnb82GnssNWxyGMHjTYiRQCRsNdPeYdEb-tsvkshpfEg@mail.gmail.com>
	<20120920212823.GE27312@konrad-lan.dumpdata.com>
	<CAJ75kXZjuUgQfc=8tz2F_UEwnQWRD7AhyMOM1L+DSMFzoss9Dw@mail.gmail.com>
	<CAJ75kXbaj0vHeNDfu5hwEp8jL9zJOwpryYEY0UesvEJd388HJQ@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAJ75kXbaj0vHeNDfu5hwEp8jL9zJOwpryYEY0UesvEJd388HJQ@mail.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
Subject: Re: [Xen-devel] Error getting mfn
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Sep 25, 2012 at 10:40:00AM +0200, William Dauchy wrote:
> Hello Konrad,
> 
> Just wondering if you forgot about this thread.

No. I had reply saved up and then I got preempted.
> 
> -- 
> William

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 25 21:53:01 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 21:53:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGd3e-0002Gb-J2; Tue, 25 Sep 2012 21:52: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 1TGd3d-0002GH-47
	for xen-devel@lists.xensource.com; Tue, 25 Sep 2012 21:52:45 +0000
Received: from [85.158.139.211:12176] by server-6.bemta-5.messagelabs.com id
	5F/C2-14717-CA722605; Tue, 25 Sep 2012 21:52:44 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1348609962!19489455!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzYyNzYy\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11507 invoked from network); 25 Sep 2012 21:52:43 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-7.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 25 Sep 2012 21:52: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 q8PLqUqM028068
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 25 Sep 2012 21:52:31 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
	q8PLqUUY005752
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 25 Sep 2012 21:52:30 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
	q8PLqUnO014145; Tue, 25 Sep 2012 16:52:30 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 25 Sep 2012 14:52:30 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 0EE784035A; Tue, 25 Sep 2012 17:41:15 -0400 (EDT)
Date: Tue, 25 Sep 2012 17:41:15 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: William Dauchy <wdauchy@gmail.com>
Message-ID: <20120925214114.GB5372@phenom.dumpdata.com>
References: <20120918133650.GC12053@phenom.dumpdata.com>
	<CAJ75kXZEaCj4Jqs_qm46d7U-s1C2hkAONs8c5Audrw2c3X=nBA@mail.gmail.com>
	<20120920134851.GB1998@localhost.localdomain>
	<CAJ75kXZ0depUJF_h0yok-r4aL0TBGnqTpW_PKT4Q7P1_6R4X2A@mail.gmail.com>
	<20120920162337.GB8912@reaktio.net>
	<CAJ75kXaXbitBvosYp8Sv_548XbvdxU=M_NSSHTb_5d56=-n4nA@mail.gmail.com>
	<20120920163525.GC8912@reaktio.net>
	<CAJ75kXZnb82GnssNWxyGMHjTYiRQCRsNdPeYdEb-tsvkshpfEg@mail.gmail.com>
	<20120920212823.GE27312@konrad-lan.dumpdata.com>
	<CAJ75kXZjuUgQfc=8tz2F_UEwnQWRD7AhyMOM1L+DSMFzoss9Dw@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAJ75kXZjuUgQfc=8tz2F_UEwnQWRD7AhyMOM1L+DSMFzoss9Dw@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
Subject: Re: [Xen-devel] Error getting mfn
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Sun, Sep 23, 2012 at 05:11:13PM +0200, William Dauchy wrote:
> On Thu, Sep 20, 2012 at 11:28 PM, Konrad Rzeszutek Wilk
> <konrad.wilk@oracle.com> wrote:
> > Ah. OK. so lets deal with one issue at hand. The CONFIG_NUMA - you said
> > you applied I posted for it some time ago? Is it this one?
> > http://lkml.indiana.edu/hypermail/linux/kernel/1205.3/03619.html
> 
> yes; and applied on my tests.
> 
> > For the non-NUMA case - can you try to compile a kernel without
> > NUMA enabled and also include 'earlyprintk=xen' on your Linux command
> > line? That should give me a good approximation of what/where
> > it is being hit.
> 
> Here is the log without NUMA enabled.

Initially I was thinking you might have:

commit 66a27dde9ae96e35278983f2e59bea04eb714cd0
Author: David Vrabel <david.vrabel@citrix.com>
Date:   Mon Jul 9 11:39:06 2012 +0100

    xen/mm: zero PTEs for non-present MFNs in the initial page table
    
    When constructing the initial page tables, if the MFN for a usable PFN
    is missing in the p2m then that frame is initially ballooned out.  In
    this case, zero the PTE (as in decrease_reservation() in
    drivers/xen/balloon.c).
    
    This is obviously safe instead of having an valid PTE with an MFN of
    INVALID_P2M_ENTRY (~0).
    
    Signed-off-by: David Vrabel <david.vrabel@citrix.com>
    Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

but that is the opposite problem - you would have bizzare PTEs like:

0xfffffffff023 which is not what you are seeing.

No, you are seeing us trying to allocate a PTE for which the M2P tells us
that we do not have. That either means somebody is trying to call
ioremap and we are using the PFN as if it was a MFN. Meaning PFN 2009b
is being set.. But I can't fanthom why it would - especially as you
are in the middle of the kernel mapping.

The other option is that our P2M has somewhere been corrupted? And
we decided to give you 2009b instead of something correct.

Can you give me access to your xen/kernel/initramfs images and
also your .config file. Maybe if I run it on my machine it
will shed some light.

> Reserving virtual address space above 0xfcc00000
> Linux version 3.4.11 (gcc version 4.4.5 (Debian 4.4.5-8) ) #18 SMP Sun
> Sep 23 14:32:16 UTC 2012
> KERNEL supported cpus:
>   Intel GenuineIntel
> Freeing  9b-100 pfn range: 101 pages freed
> 1-1 mapping on 9b->100
> 1-1 mapping on bf730->100000
> Released 101 pages of unused memory
> Set 264501 page(s) to 1-1 mapping
> BIOS-provided physical RAM map:
>  Xen: 0000000000000000 - 000000000009b000 (usable)
>  Xen: 000000000009b400 - 0000000000100000 (reserved)
>  Xen: 0000000000100000 - 0000000040065000 (usable)
>  Xen: 0000000040065000 - 00000000bf730000 (unusable)
>  Xen: 00000000bf730000 - 00000000bf73e000 (ACPI data)
>  Xen: 00000000bf73e000 - 00000000bf7a0000 (ACPI NVS)
>  Xen: 00000000bf7a0000 - 00000000bf7b0000 (reserved)
>  Xen: 00000000bf7bc000 - 00000000c0000000 (reserved)
>  Xen: 00000000e0000000 - 00000000f0000000 (reserved)
>  Xen: 00000000fec00000 - 00000000fec01000 (reserved)
>  Xen: 00000000fec8a000 - 00000000fec8b000 (reserved)
>  Xen: 00000000fee00000 - 00000000fee01000 (reserved)
>  Xen: 00000000ffa00000 - 0000000100000000 (reserved)
>  Xen: 0000000100000000 - 0000000c40000000 (unusable)
> bootconsole [xenboot0] enabled
> NX (Execute Disable) protection: active
> DMI present.
> DMI: Dell       C6100           /0D61XP, BIOS 1.66 12/23/2011
> e820 update range: 0000000000000000 - 0000000000010000 (usable) ==> (reserved)
> e820 remove range: 00000000000a0000 - 0000000000100000 (usable)
> last_pfn = 0x40065 max_arch_pfn = 0x1000000
> initial memory mapped : 0 - 027ff000
> Base memory trampoline at [c009a000] 9a000 size 4096
> init_memory_mapping: 0000000000000000-00000000345fe000
>  0000000000 - 00345fe000 page 4k
> kernel direct mapping tables up to 345fe000 @ 2658000-27ff000
> (XEN) mm.c:908:d0 Error getting mfn 2009b (pfn 5555555555555555) from
> L1 entry 000000002009b023 for l1e_owner=0, pg_owner=0
> (XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 000000002009b023
> (XEN) mm.c:908:d0 Error getting mfn 2009c (pfn 5555555555555555) from
> L1 entry 000000002009c023 for l1e_owner=0, pg_owner=0
> (XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 000000002009c023
> (XEN) mm.c:908:d0 Error getting mfn 2009d (pfn 5555555555555555) from
> L1 entry 000000002009d023 for l1e_owner=0, pg_owner=0
> (XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 000000002009d023
> (XEN) mm.c:908:d0 Error getting mfn 2009e (pfn 5555555555555555) from
> L1 entry 000000002009e023 for l1e_owner=0, pg_owner=0
> (XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 000000002009e023
> (XEN) mm.c:908:d0 Error getting mfn 2009f (pfn 5555555555555555) from
> L1 entry 000000002009f023 for l1e_owner=0, pg_owner=0
> (XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 000000002009f023
> xen: setting RW the range 27e9000 - 27ff000
> RAMDISK: 017ce000 - 01ab2000
> ACPI: RSDP 000fa6f0 00024 (v02 ACPIAM)


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 25 21:53:01 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 21:53:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGd3e-0002Gb-J2; Tue, 25 Sep 2012 21:52: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 1TGd3d-0002GH-47
	for xen-devel@lists.xensource.com; Tue, 25 Sep 2012 21:52:45 +0000
Received: from [85.158.139.211:12176] by server-6.bemta-5.messagelabs.com id
	5F/C2-14717-CA722605; Tue, 25 Sep 2012 21:52:44 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1348609962!19489455!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzYyNzYy\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11507 invoked from network); 25 Sep 2012 21:52:43 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-7.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 25 Sep 2012 21:52: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 q8PLqUqM028068
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 25 Sep 2012 21:52:31 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
	q8PLqUUY005752
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 25 Sep 2012 21:52:30 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
	q8PLqUnO014145; Tue, 25 Sep 2012 16:52:30 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 25 Sep 2012 14:52:30 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 0EE784035A; Tue, 25 Sep 2012 17:41:15 -0400 (EDT)
Date: Tue, 25 Sep 2012 17:41:15 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: William Dauchy <wdauchy@gmail.com>
Message-ID: <20120925214114.GB5372@phenom.dumpdata.com>
References: <20120918133650.GC12053@phenom.dumpdata.com>
	<CAJ75kXZEaCj4Jqs_qm46d7U-s1C2hkAONs8c5Audrw2c3X=nBA@mail.gmail.com>
	<20120920134851.GB1998@localhost.localdomain>
	<CAJ75kXZ0depUJF_h0yok-r4aL0TBGnqTpW_PKT4Q7P1_6R4X2A@mail.gmail.com>
	<20120920162337.GB8912@reaktio.net>
	<CAJ75kXaXbitBvosYp8Sv_548XbvdxU=M_NSSHTb_5d56=-n4nA@mail.gmail.com>
	<20120920163525.GC8912@reaktio.net>
	<CAJ75kXZnb82GnssNWxyGMHjTYiRQCRsNdPeYdEb-tsvkshpfEg@mail.gmail.com>
	<20120920212823.GE27312@konrad-lan.dumpdata.com>
	<CAJ75kXZjuUgQfc=8tz2F_UEwnQWRD7AhyMOM1L+DSMFzoss9Dw@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAJ75kXZjuUgQfc=8tz2F_UEwnQWRD7AhyMOM1L+DSMFzoss9Dw@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
Subject: Re: [Xen-devel] Error getting mfn
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Sun, Sep 23, 2012 at 05:11:13PM +0200, William Dauchy wrote:
> On Thu, Sep 20, 2012 at 11:28 PM, Konrad Rzeszutek Wilk
> <konrad.wilk@oracle.com> wrote:
> > Ah. OK. so lets deal with one issue at hand. The CONFIG_NUMA - you said
> > you applied I posted for it some time ago? Is it this one?
> > http://lkml.indiana.edu/hypermail/linux/kernel/1205.3/03619.html
> 
> yes; and applied on my tests.
> 
> > For the non-NUMA case - can you try to compile a kernel without
> > NUMA enabled and also include 'earlyprintk=xen' on your Linux command
> > line? That should give me a good approximation of what/where
> > it is being hit.
> 
> Here is the log without NUMA enabled.

Initially I was thinking you might have:

commit 66a27dde9ae96e35278983f2e59bea04eb714cd0
Author: David Vrabel <david.vrabel@citrix.com>
Date:   Mon Jul 9 11:39:06 2012 +0100

    xen/mm: zero PTEs for non-present MFNs in the initial page table
    
    When constructing the initial page tables, if the MFN for a usable PFN
    is missing in the p2m then that frame is initially ballooned out.  In
    this case, zero the PTE (as in decrease_reservation() in
    drivers/xen/balloon.c).
    
    This is obviously safe instead of having an valid PTE with an MFN of
    INVALID_P2M_ENTRY (~0).
    
    Signed-off-by: David Vrabel <david.vrabel@citrix.com>
    Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

but that is the opposite problem - you would have bizzare PTEs like:

0xfffffffff023 which is not what you are seeing.

No, you are seeing us trying to allocate a PTE for which the M2P tells us
that we do not have. That either means somebody is trying to call
ioremap and we are using the PFN as if it was a MFN. Meaning PFN 2009b
is being set.. But I can't fanthom why it would - especially as you
are in the middle of the kernel mapping.

The other option is that our P2M has somewhere been corrupted? And
we decided to give you 2009b instead of something correct.

Can you give me access to your xen/kernel/initramfs images and
also your .config file. Maybe if I run it on my machine it
will shed some light.

> Reserving virtual address space above 0xfcc00000
> Linux version 3.4.11 (gcc version 4.4.5 (Debian 4.4.5-8) ) #18 SMP Sun
> Sep 23 14:32:16 UTC 2012
> KERNEL supported cpus:
>   Intel GenuineIntel
> Freeing  9b-100 pfn range: 101 pages freed
> 1-1 mapping on 9b->100
> 1-1 mapping on bf730->100000
> Released 101 pages of unused memory
> Set 264501 page(s) to 1-1 mapping
> BIOS-provided physical RAM map:
>  Xen: 0000000000000000 - 000000000009b000 (usable)
>  Xen: 000000000009b400 - 0000000000100000 (reserved)
>  Xen: 0000000000100000 - 0000000040065000 (usable)
>  Xen: 0000000040065000 - 00000000bf730000 (unusable)
>  Xen: 00000000bf730000 - 00000000bf73e000 (ACPI data)
>  Xen: 00000000bf73e000 - 00000000bf7a0000 (ACPI NVS)
>  Xen: 00000000bf7a0000 - 00000000bf7b0000 (reserved)
>  Xen: 00000000bf7bc000 - 00000000c0000000 (reserved)
>  Xen: 00000000e0000000 - 00000000f0000000 (reserved)
>  Xen: 00000000fec00000 - 00000000fec01000 (reserved)
>  Xen: 00000000fec8a000 - 00000000fec8b000 (reserved)
>  Xen: 00000000fee00000 - 00000000fee01000 (reserved)
>  Xen: 00000000ffa00000 - 0000000100000000 (reserved)
>  Xen: 0000000100000000 - 0000000c40000000 (unusable)
> bootconsole [xenboot0] enabled
> NX (Execute Disable) protection: active
> DMI present.
> DMI: Dell       C6100           /0D61XP, BIOS 1.66 12/23/2011
> e820 update range: 0000000000000000 - 0000000000010000 (usable) ==> (reserved)
> e820 remove range: 00000000000a0000 - 0000000000100000 (usable)
> last_pfn = 0x40065 max_arch_pfn = 0x1000000
> initial memory mapped : 0 - 027ff000
> Base memory trampoline at [c009a000] 9a000 size 4096
> init_memory_mapping: 0000000000000000-00000000345fe000
>  0000000000 - 00345fe000 page 4k
> kernel direct mapping tables up to 345fe000 @ 2658000-27ff000
> (XEN) mm.c:908:d0 Error getting mfn 2009b (pfn 5555555555555555) from
> L1 entry 000000002009b023 for l1e_owner=0, pg_owner=0
> (XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 000000002009b023
> (XEN) mm.c:908:d0 Error getting mfn 2009c (pfn 5555555555555555) from
> L1 entry 000000002009c023 for l1e_owner=0, pg_owner=0
> (XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 000000002009c023
> (XEN) mm.c:908:d0 Error getting mfn 2009d (pfn 5555555555555555) from
> L1 entry 000000002009d023 for l1e_owner=0, pg_owner=0
> (XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 000000002009d023
> (XEN) mm.c:908:d0 Error getting mfn 2009e (pfn 5555555555555555) from
> L1 entry 000000002009e023 for l1e_owner=0, pg_owner=0
> (XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 000000002009e023
> (XEN) mm.c:908:d0 Error getting mfn 2009f (pfn 5555555555555555) from
> L1 entry 000000002009f023 for l1e_owner=0, pg_owner=0
> (XEN) mm.c:4990:d0 ptwr_emulate: fixing up invalid PAE PTE 000000002009f023
> xen: setting RW the range 27e9000 - 27ff000
> RAMDISK: 017ce000 - 01ab2000
> ACPI: RSDP 000fa6f0 00024 (v02 ACPIAM)


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 25 22:58:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 22: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 1TGe4b-0003EI-Iy; Tue, 25 Sep 2012 22:57: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 1TGe4a-0003ED-EP
	for xen-devel@lists.xensource.com; Tue, 25 Sep 2012 22:57:48 +0000
Received: from [85.158.143.99:17952] by server-1.bemta-4.messagelabs.com id
	73/75-05684-BE632605; Tue, 25 Sep 2012 22:57:47 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1348613864!23631548!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTEzMTI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27784 invoked from network); 25 Sep 2012 22:57:45 -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;
	25 Sep 2012 22:57:45 -0000
X-IronPort-AV: E=Sophos;i="4.80,486,1344211200"; d="scan'208";a="14762324"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Sep 2012 22:57: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.279.1; Tue, 25 Sep 2012 23:57: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 1TGe4V-00054O-6B;
	Tue, 25 Sep 2012 22:57:43 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1TGe4S-0007gS-MK;
	Tue, 25 Sep 2012 23:57:43 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-13866-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Tue, 25 Sep 2012 23:57:40 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13866: regressions - trouble:
	broken/fail/pass
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 13866 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13866/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-credit2    5 xen-boot                  fail REGR. vs. 13825
 test-amd64-i386-win-vcpus1    5 xen-boot                  fail REGR. vs. 13825
 test-amd64-amd64-pv          10 guest-saverestore         fail REGR. vs. 13825
 test-amd64-i386-rhel6hvm-intel  5 xen-boot                fail REGR. vs. 13825
 test-amd64-amd64-win          3 host-install(3)         broken REGR. vs. 13825
 test-amd64-amd64-xl-winxpsp3  5 xen-boot                  fail REGR. vs. 13825
 test-amd64-i386-pair          8 xen-boot/dst_host         fail REGR. vs. 13825

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-pcipt-intel  5 xen-boot               fail REGR. vs. 13825
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore            fail   like 13825
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail like 13823
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail like 13825

Tests which did not succeed, but are not blocking:
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  16ee1d300cfd
baseline version:
 xen                  d364becfb083

------------------------------------------------------------
People who touched revisions under test:
  Bastian Blank <waldi@debian.org>
  Ben Guthro <ben@guthro.net>
  Ian Campbell <ian.campbell@citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Keir Fraser <keir@xen.org>
  Olaf Hering <olaf@aepfle.de>
------------------------------------------------------------

jobs:
 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-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                                   fail    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          fail    
 test-amd64-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                                         broken  
 test-amd64-i386-win                                          fail    
 test-amd64-amd64-xl-win                                      fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
changeset:   25942:16ee1d300cfd
tag:         tip
user:        Bastian Blank <waldi@debian.org>
date:        Tue Sep 25 11:03:51 2012 +0100
    
    xl: resume the domain on suspend failure
    
    The MUST macro calls exit(3) on failure but we need to cleanup and
    resume.
    
    Signed-off-by: Bastian Blank <waldi@debian.org>
    Acked-by: Ian Campbell <ian.campbell@citrix.com>
    Committed-by: Ian Campbell <ian.campbell@citrix.com>
    
    
changeset:   25941:795c493fe561
user:        Olaf Hering <olaf@aepfle.de>
date:        Tue Sep 25 11:03:51 2012 +0100
    
    pygrub: always append --args
    
    If a bootloader entry in menu.lst has no additional kernel command line
    options listed and the domU.cfg has 'bootargs="--args=something"' the
    additional arguments from the config file are not passed to the kernel.
    The reason for that incorrect behaviour is that run_grub appends arg
    only if the parsed config file has arguments listed.
    
    Fix this by appending args from image section and the config file separatly.
    To avoid adding to a NoneType initialize grubcfg['args'] to an empty string.
    This does not change behaviour but simplifies the code which appends the
    string.
    
    Signed-off-by: Olaf Hering <olaf@aepfle.de>
    Acked-by: Ian Campbell <ian.campbell@citrix.com>
    Committed-by: Ian Campbell <ian.campbell@citrix.com>
    
    
changeset:   25940:c8d65d91a6f2
user:        Ben Guthro <ben@guthro.net>
date:        Tue Sep 25 08:38:14 2012 +0200
    
    x86/S3: add cache flush on secondary CPUs before going to sleep
    
    Secondary CPUs, between doing their final memory writes (particularly
    updating cpu_initialized) and getting a subsequent INIT, may not write
    back all modified data. The INIT itself then causes those modifications
    to be lost, so in the cpu_initialized case the CPU would find itself
    already initialized, (intentionally) entering an infinite loop instead
    of actually coming online.
    
    Signed-off-by: Ben Guthro <ben@guthro.net>
    
    Make acpi_dead_idle() call default_dead_idle() rather than duplicating
    the logic there.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    Committed-by: Jan Beulich <jbeulich@suse.com>
    
    
changeset:   25939:b49f7bf52fa9
user:        Jan Beulich <jbeulich@suse.com>
date:        Tue Sep 25 08:36:33 2012 +0200
    
    x86: fix MWAIT-based idle driver for CPUs without ARAT
    
    lapic_timer_{on,off} need to get initialized in this case. This in turn
    requires getting HPET broadcast setup to be carried out earlier (and
    hence preventing double initialization there).
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    
    
changeset:   25938:8f658b463b78
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Sep 21 17:02:46 2012 +0200
    
    x86: enable VIA CPU support
    
    Newer VIA CPUs have both 64-bit and VMX support. Enable them to be
    recognized for these purposes, at once stripping off any 32-bit CPU
    only bits from the respective CPU support file, and adding 64-bit ones
    found in recent Linux.
    
    This particularly implies untying the VMX == Intel assumption in a few
    places.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   25937:32187301ecc5
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Sep 21 15:20:21 2012 +0200
    
    x86: eliminate code affecting only 64-bit-incapable CPUs
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   25936:c8873f13cec3
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Sep 21 14:25:12 2012 +0200
    
    printk: prefer %#x et at over 0x%x
    
    Performance is not an issue with printk(), so let the function do
    minimally more work and instead save a byte per affected format
    specifier.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   25935:1e6e6b49b4ac
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Sep 21 13:47:18 2012 +0200
    
    x86: introduce MWAIT-based, ACPI-less CPU idle driver
    
    This is a port of Linux'es intel-idle driver serving the same purpose.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   25934:8eab91903e71
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Sep 21 13:45:08 2012 +0200
    
    cpuidle: remove unused latency_ticks member
    
    ... and code used only for initializing it.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   25933:d364becfb083
user:        Jan Beulich <jbeulich@suse.com>
date:        Thu Sep 20 13:31:19 2012 +0200
    
    introduce guest_handle_for_field()
    
    This helper turns a field of a GUEST_HANDLE in a GUEST_HANDLE.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    
    
(qemu changes not included)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Tue Sep 25 22:58:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 25 Sep 2012 22: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 1TGe4b-0003EI-Iy; Tue, 25 Sep 2012 22:57: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 1TGe4a-0003ED-EP
	for xen-devel@lists.xensource.com; Tue, 25 Sep 2012 22:57:48 +0000
Received: from [85.158.143.99:17952] by server-1.bemta-4.messagelabs.com id
	73/75-05684-BE632605; Tue, 25 Sep 2012 22:57:47 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1348613864!23631548!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTEzMTI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27784 invoked from network); 25 Sep 2012 22:57:45 -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;
	25 Sep 2012 22:57:45 -0000
X-IronPort-AV: E=Sophos;i="4.80,486,1344211200"; d="scan'208";a="14762324"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Sep 2012 22:57: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.279.1; Tue, 25 Sep 2012 23:57: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 1TGe4V-00054O-6B;
	Tue, 25 Sep 2012 22:57:43 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1TGe4S-0007gS-MK;
	Tue, 25 Sep 2012 23:57:43 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-13866-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Tue, 25 Sep 2012 23:57:40 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13866: regressions - trouble:
	broken/fail/pass
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 13866 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13866/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-credit2    5 xen-boot                  fail REGR. vs. 13825
 test-amd64-i386-win-vcpus1    5 xen-boot                  fail REGR. vs. 13825
 test-amd64-amd64-pv          10 guest-saverestore         fail REGR. vs. 13825
 test-amd64-i386-rhel6hvm-intel  5 xen-boot                fail REGR. vs. 13825
 test-amd64-amd64-win          3 host-install(3)         broken REGR. vs. 13825
 test-amd64-amd64-xl-winxpsp3  5 xen-boot                  fail REGR. vs. 13825
 test-amd64-i386-pair          8 xen-boot/dst_host         fail REGR. vs. 13825

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-pcipt-intel  5 xen-boot               fail REGR. vs. 13825
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore            fail   like 13825
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail like 13823
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail like 13825

Tests which did not succeed, but are not blocking:
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  16ee1d300cfd
baseline version:
 xen                  d364becfb083

------------------------------------------------------------
People who touched revisions under test:
  Bastian Blank <waldi@debian.org>
  Ben Guthro <ben@guthro.net>
  Ian Campbell <ian.campbell@citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Keir Fraser <keir@xen.org>
  Olaf Hering <olaf@aepfle.de>
------------------------------------------------------------

jobs:
 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-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                                   fail    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          fail    
 test-amd64-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                                         broken  
 test-amd64-i386-win                                          fail    
 test-amd64-amd64-xl-win                                      fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
changeset:   25942:16ee1d300cfd
tag:         tip
user:        Bastian Blank <waldi@debian.org>
date:        Tue Sep 25 11:03:51 2012 +0100
    
    xl: resume the domain on suspend failure
    
    The MUST macro calls exit(3) on failure but we need to cleanup and
    resume.
    
    Signed-off-by: Bastian Blank <waldi@debian.org>
    Acked-by: Ian Campbell <ian.campbell@citrix.com>
    Committed-by: Ian Campbell <ian.campbell@citrix.com>
    
    
changeset:   25941:795c493fe561
user:        Olaf Hering <olaf@aepfle.de>
date:        Tue Sep 25 11:03:51 2012 +0100
    
    pygrub: always append --args
    
    If a bootloader entry in menu.lst has no additional kernel command line
    options listed and the domU.cfg has 'bootargs="--args=something"' the
    additional arguments from the config file are not passed to the kernel.
    The reason for that incorrect behaviour is that run_grub appends arg
    only if the parsed config file has arguments listed.
    
    Fix this by appending args from image section and the config file separatly.
    To avoid adding to a NoneType initialize grubcfg['args'] to an empty string.
    This does not change behaviour but simplifies the code which appends the
    string.
    
    Signed-off-by: Olaf Hering <olaf@aepfle.de>
    Acked-by: Ian Campbell <ian.campbell@citrix.com>
    Committed-by: Ian Campbell <ian.campbell@citrix.com>
    
    
changeset:   25940:c8d65d91a6f2
user:        Ben Guthro <ben@guthro.net>
date:        Tue Sep 25 08:38:14 2012 +0200
    
    x86/S3: add cache flush on secondary CPUs before going to sleep
    
    Secondary CPUs, between doing their final memory writes (particularly
    updating cpu_initialized) and getting a subsequent INIT, may not write
    back all modified data. The INIT itself then causes those modifications
    to be lost, so in the cpu_initialized case the CPU would find itself
    already initialized, (intentionally) entering an infinite loop instead
    of actually coming online.
    
    Signed-off-by: Ben Guthro <ben@guthro.net>
    
    Make acpi_dead_idle() call default_dead_idle() rather than duplicating
    the logic there.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    Committed-by: Jan Beulich <jbeulich@suse.com>
    
    
changeset:   25939:b49f7bf52fa9
user:        Jan Beulich <jbeulich@suse.com>
date:        Tue Sep 25 08:36:33 2012 +0200
    
    x86: fix MWAIT-based idle driver for CPUs without ARAT
    
    lapic_timer_{on,off} need to get initialized in this case. This in turn
    requires getting HPET broadcast setup to be carried out earlier (and
    hence preventing double initialization there).
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    
    
changeset:   25938:8f658b463b78
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Sep 21 17:02:46 2012 +0200
    
    x86: enable VIA CPU support
    
    Newer VIA CPUs have both 64-bit and VMX support. Enable them to be
    recognized for these purposes, at once stripping off any 32-bit CPU
    only bits from the respective CPU support file, and adding 64-bit ones
    found in recent Linux.
    
    This particularly implies untying the VMX == Intel assumption in a few
    places.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   25937:32187301ecc5
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Sep 21 15:20:21 2012 +0200
    
    x86: eliminate code affecting only 64-bit-incapable CPUs
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   25936:c8873f13cec3
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Sep 21 14:25:12 2012 +0200
    
    printk: prefer %#x et at over 0x%x
    
    Performance is not an issue with printk(), so let the function do
    minimally more work and instead save a byte per affected format
    specifier.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   25935:1e6e6b49b4ac
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Sep 21 13:47:18 2012 +0200
    
    x86: introduce MWAIT-based, ACPI-less CPU idle driver
    
    This is a port of Linux'es intel-idle driver serving the same purpose.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   25934:8eab91903e71
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Sep 21 13:45:08 2012 +0200
    
    cpuidle: remove unused latency_ticks member
    
    ... and code used only for initializing it.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   25933:d364becfb083
user:        Jan Beulich <jbeulich@suse.com>
date:        Thu Sep 20 13:31:19 2012 +0200
    
    introduce guest_handle_for_field()
    
    This helper turns a field of a GUEST_HANDLE in a GUEST_HANDLE.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    
    
(qemu changes not included)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 26 00:10:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Sep 2012 00:10:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGfC5-0004Cg-I3; Wed, 26 Sep 2012 00:09:37 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mukesh.rathor@oracle.com>) id 1TGfC3-0004CW-6p
	for Xen-devel@lists.xensource.com; Wed, 26 Sep 2012 00:09:35 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1348618167!12380435!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzY0MTUx\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29560 invoked from network); 26 Sep 2012 00:09:29 -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; 26 Sep 2012 00:09:29 -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 q8Q09KSY032494
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 26 Sep 2012 00:09:21 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q8Q09Jov029833
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 26 Sep 2012 00:09:20 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
	q8Q09JUq015537; Tue, 25 Sep 2012 19:09:19 -0500
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 25 Sep 2012 17:09:18 -0700
Date: Tue, 25 Sep 2012 17:09:17 -0700
From: Mukesh Rathor <mukesh.rathor@oracle.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20120925170917.580b213b@mantra.us.oracle.com>
In-Reply-To: <alpine.DEB.2.02.1209241228460.29232@kaball.uk.xensource.com>
References: <20120921121556.1a0ea8af@mantra.us.oracle.com>
	<alpine.DEB.2.02.1209241228460.29232@kaball.uk.xensource.com>
Organization: Oracle Corporation
X-Mailer: Claws Mail 3.7.6 (GTK+ 2.18.9; x86_64-redhat-linux-gnu)
Mime-Version: 1.0
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: "Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH v1 2/8]: PVH mmu changes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 24 Sep 2012 12:55:31 +0100
Stefano Stabellini <stefano.stabellini@eu.citrix.com> wrote:

> There are few code style issues on this patch, I suggest you run it
> through scripts/checkpatch.pl, it should be able to catch all these
> errors.
> 
> On Fri, 21 Sep 2012, Mukesh Rathor wrote:
> > ---
> >  arch/x86/xen/mmu.c    |  180
> > +++++++++++++++++++++++++++++++++++++++++++++++--
> > arch/x86/xen/mmu.h    |    2 + include/xen/xen-ops.h |   12 +++-
> >  3 files changed, 188 insertions(+), 6 deletions(-)
> > 
> > diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c
> > long addr,
> > +		    		   pte_t *ptep, pte_t pteval)
> > +{
> > +	native_set_pte(ptep, pteval);
> > +}
> 
> can't you just set set_pte_at to native_set_pte?

yup. oh, i had other code there, which is why it's not already 
native_set_pte_at.

> 
> >  static void xen_set_pte_at(struct mm_struct *mm, unsigned long
> > addr, pte_t *ptep, pte_t pteval)
> >  {
> > @@ -1197,6 +1218,10 @@ static void xen_post_allocator_init(void);
> >  static void __init xen_pagetable_setup_done(pgd_t *base)
> >  {
> >  	xen_setup_shared_info();
> > +
> > +	if (xen_feature(XENFEAT_auto_translated_physmap))
> > +		return;
> > +
> >  	xen_post_allocator_init();
> >  }
> 
> Can we move the if..return at the beginning of
> xen_post_allocator_init? It would make it easier to understand what
> it is for. Or maybe we could have xen_setup_shared_info take a pgd_t
> *base parameter so that you can set pagetable_setup_done to
> xen_setup_shared_info directly on pvh.

done.

> 
> > @@ -1455,6 +1480,10 @@ static void __init xen_set_pte_init(pte_t
> > *ptep, pte_t pte) static void pin_pagetable_pfn(unsigned cmd,
> > unsigned long pfn) {
> >  	struct mmuext_op op;
> > +
> > +	if (xen_feature(XENFEAT_writable_page_tables))
> > +		return;
> > +
> >  	op.cmd = cmd;
> >  	op.arg1.mfn = pfn_to_mfn(pfn);
> >  	if (HYPERVISOR_mmuext_op(&op, 1, NULL, DOMID_SELF))
> 
> given the very limited set of mmu pvops that we initialize on pvh, I
> cannot find who would actually call pin_pagetable_pfn on pvh.

xen_setup_kernel_pagetable().

> 
> > @@ -1652,6 +1681,10 @@ static void set_page_prot(void *addr,
> > pgprot_t prot) unsigned long pfn = __pa(addr) >> PAGE_SHIFT;
> > +		/* set_pte* for PCI devices to map iomem. */
> > +		if (xen_initial_domain()) {
> > +			pv_mmu_ops.set_pte = native_set_pte;
> > +			pv_mmu_ops.set_pte_at =
> > xen_dom0pvh_set_pte_at;
> > +		}
> > +		return;
> > +	}
> > +
> >  	x86_init.mapping.pagetable_reserve =
> > xen_mapping_pagetable_reserve;
> > x86_init.paging.pagetable_setup_start = xen_pagetable_setup_start;
> > -	x86_init.paging.pagetable_setup_done =
> > xen_pagetable_setup_done; pv_mmu_ops = xen_mmu_ops;
> >  
> >  	memset(dummy_mapping, 0xff, PAGE_SIZE);
> 
> I wonder whether it would make sense to have a xen_pvh_init_mmu_ops,
> given that they end up being so different...

It's not a pv ops call. It's called from xen_start_kernel in 
enlighten.c. So lets just leave it like that.

> > +			void *data)
> > +{
> > +	int rc;
> > +	struct pvh_remap_data *remapp = data;
> > +	struct xen_pvh_pfn_info *pvhp = remapp->pvhinfop;
> > +	unsigned long pfn =
> > page_to_pfn(pvhp->pi_paga[pvhp->pi_next_todo++]);
> > +	pte_t pteval = pte_mkspecial(pfn_pte(pfn, remapp->prot));
> > +
> > +	if ((rc=pvh_add_to_xen_p2m(pfn, remapp->fgmfn,
> > remapp->domid)))
> > +		return rc;
> > +	native_set_pte(ptep, pteval);
> 
> Do we actually need the pte to be "special"?
> I would think that being in the guest p2m, it is actually quite a
> normal page.

Ah, I remember. The reason I had it special is because earlier I was
allocating pfn's from high up address space. These pfns' were greater
than highest_memmap_pfn. But, now I'm allocating them via ballooing. So
I can change it to normal. If we go back to allocating pfn's space from
high up, then we'd need this back for this check:

vm_normal_page():
        if (unlikely(pfn > highest_memmap_pfn)) {
                print_bad_pte(vma, addr, pte, NULL);
        return NULL;

> > +	return 0;
> > +}
> > +
> > +/* The only caller at moment passes one gmfn at a time.
> > + * PVH TBD/FIXME: expand this in future to honor batch requests.
> > + */
> > +static int pvh_remap_gmfn_range(struct vm_area_struct *vma,
> > +				unsigned long addr, unsigned long
> > mfn, int nr,
> > +				pgprot_t prot, unsigned domid,
> > +				struct xen_pvh_pfn_info *pvhp)
> > +{
> > +	int err;
> > +	struct pvh_remap_data pvhdata;
> > +
> > +	if (nr > 1)
> > +		return -EINVAL;
> > +
> > +	pvhdata.fgmfn = mfn;
> > +	pvhdata.prot = prot;
> > +	pvhdata.domid = domid;
> > +	pvhdata.pvhinfop = pvhp;
> > +	err = apply_to_page_range(vma->vm_mm, addr, nr <<
> > PAGE_SHIFT,
> > +				  pvh_map_pte_fn, &pvhdata);
> > +	flush_tlb_all();
> 
> Maybe we can use one of the flush_tlb_range varieties instead of a
> flush_tlb_all?

changed it to : flush_tlb_page(vma, addr);

> > +
> > +	if (!pvhp || !xen_feature(XENFEAT_auto_translated_physmap))
> > +		return 0;
> > +
> > +	while (pvhp->pi_next_todo--) {
> > +		unsigned long pfn;
> > +
> > +		/* the mmu has already cleaned up the process mmu
> > resources at
> > +		 * this point (lookup_address will return NULL). */
> > +		pfn =
> > page_to_pfn(pvhp->pi_paga[pvhp->pi_next_todo]);
> > +		pvh_rem_xen_p2m(pfn, 1);
> > +		count++;
> > +	}
> > +	flush_tlb_all();
> > +	return count;
> 
> Who is going to remove the corresponding mapping from the vma?
> Also we might be able to replace the flush_tlb_all with a
> flush_tlb_range.

the kernel already does that before privcmd_close is called. 
don't have the addrs for flush_tlb_range in privcmd_close().

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 Sep 26 00:10:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Sep 2012 00:10:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGfC5-0004Cg-I3; Wed, 26 Sep 2012 00:09:37 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mukesh.rathor@oracle.com>) id 1TGfC3-0004CW-6p
	for Xen-devel@lists.xensource.com; Wed, 26 Sep 2012 00:09:35 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1348618167!12380435!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzY0MTUx\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29560 invoked from network); 26 Sep 2012 00:09:29 -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; 26 Sep 2012 00:09:29 -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 q8Q09KSY032494
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 26 Sep 2012 00:09:21 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q8Q09Jov029833
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 26 Sep 2012 00:09:20 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
	q8Q09JUq015537; Tue, 25 Sep 2012 19:09:19 -0500
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 25 Sep 2012 17:09:18 -0700
Date: Tue, 25 Sep 2012 17:09:17 -0700
From: Mukesh Rathor <mukesh.rathor@oracle.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20120925170917.580b213b@mantra.us.oracle.com>
In-Reply-To: <alpine.DEB.2.02.1209241228460.29232@kaball.uk.xensource.com>
References: <20120921121556.1a0ea8af@mantra.us.oracle.com>
	<alpine.DEB.2.02.1209241228460.29232@kaball.uk.xensource.com>
Organization: Oracle Corporation
X-Mailer: Claws Mail 3.7.6 (GTK+ 2.18.9; x86_64-redhat-linux-gnu)
Mime-Version: 1.0
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: "Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH v1 2/8]: PVH mmu changes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 24 Sep 2012 12:55:31 +0100
Stefano Stabellini <stefano.stabellini@eu.citrix.com> wrote:

> There are few code style issues on this patch, I suggest you run it
> through scripts/checkpatch.pl, it should be able to catch all these
> errors.
> 
> On Fri, 21 Sep 2012, Mukesh Rathor wrote:
> > ---
> >  arch/x86/xen/mmu.c    |  180
> > +++++++++++++++++++++++++++++++++++++++++++++++--
> > arch/x86/xen/mmu.h    |    2 + include/xen/xen-ops.h |   12 +++-
> >  3 files changed, 188 insertions(+), 6 deletions(-)
> > 
> > diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c
> > long addr,
> > +		    		   pte_t *ptep, pte_t pteval)
> > +{
> > +	native_set_pte(ptep, pteval);
> > +}
> 
> can't you just set set_pte_at to native_set_pte?

yup. oh, i had other code there, which is why it's not already 
native_set_pte_at.

> 
> >  static void xen_set_pte_at(struct mm_struct *mm, unsigned long
> > addr, pte_t *ptep, pte_t pteval)
> >  {
> > @@ -1197,6 +1218,10 @@ static void xen_post_allocator_init(void);
> >  static void __init xen_pagetable_setup_done(pgd_t *base)
> >  {
> >  	xen_setup_shared_info();
> > +
> > +	if (xen_feature(XENFEAT_auto_translated_physmap))
> > +		return;
> > +
> >  	xen_post_allocator_init();
> >  }
> 
> Can we move the if..return at the beginning of
> xen_post_allocator_init? It would make it easier to understand what
> it is for. Or maybe we could have xen_setup_shared_info take a pgd_t
> *base parameter so that you can set pagetable_setup_done to
> xen_setup_shared_info directly on pvh.

done.

> 
> > @@ -1455,6 +1480,10 @@ static void __init xen_set_pte_init(pte_t
> > *ptep, pte_t pte) static void pin_pagetable_pfn(unsigned cmd,
> > unsigned long pfn) {
> >  	struct mmuext_op op;
> > +
> > +	if (xen_feature(XENFEAT_writable_page_tables))
> > +		return;
> > +
> >  	op.cmd = cmd;
> >  	op.arg1.mfn = pfn_to_mfn(pfn);
> >  	if (HYPERVISOR_mmuext_op(&op, 1, NULL, DOMID_SELF))
> 
> given the very limited set of mmu pvops that we initialize on pvh, I
> cannot find who would actually call pin_pagetable_pfn on pvh.

xen_setup_kernel_pagetable().

> 
> > @@ -1652,6 +1681,10 @@ static void set_page_prot(void *addr,
> > pgprot_t prot) unsigned long pfn = __pa(addr) >> PAGE_SHIFT;
> > +		/* set_pte* for PCI devices to map iomem. */
> > +		if (xen_initial_domain()) {
> > +			pv_mmu_ops.set_pte = native_set_pte;
> > +			pv_mmu_ops.set_pte_at =
> > xen_dom0pvh_set_pte_at;
> > +		}
> > +		return;
> > +	}
> > +
> >  	x86_init.mapping.pagetable_reserve =
> > xen_mapping_pagetable_reserve;
> > x86_init.paging.pagetable_setup_start = xen_pagetable_setup_start;
> > -	x86_init.paging.pagetable_setup_done =
> > xen_pagetable_setup_done; pv_mmu_ops = xen_mmu_ops;
> >  
> >  	memset(dummy_mapping, 0xff, PAGE_SIZE);
> 
> I wonder whether it would make sense to have a xen_pvh_init_mmu_ops,
> given that they end up being so different...

It's not a pv ops call. It's called from xen_start_kernel in 
enlighten.c. So lets just leave it like that.

> > +			void *data)
> > +{
> > +	int rc;
> > +	struct pvh_remap_data *remapp = data;
> > +	struct xen_pvh_pfn_info *pvhp = remapp->pvhinfop;
> > +	unsigned long pfn =
> > page_to_pfn(pvhp->pi_paga[pvhp->pi_next_todo++]);
> > +	pte_t pteval = pte_mkspecial(pfn_pte(pfn, remapp->prot));
> > +
> > +	if ((rc=pvh_add_to_xen_p2m(pfn, remapp->fgmfn,
> > remapp->domid)))
> > +		return rc;
> > +	native_set_pte(ptep, pteval);
> 
> Do we actually need the pte to be "special"?
> I would think that being in the guest p2m, it is actually quite a
> normal page.

Ah, I remember. The reason I had it special is because earlier I was
allocating pfn's from high up address space. These pfns' were greater
than highest_memmap_pfn. But, now I'm allocating them via ballooing. So
I can change it to normal. If we go back to allocating pfn's space from
high up, then we'd need this back for this check:

vm_normal_page():
        if (unlikely(pfn > highest_memmap_pfn)) {
                print_bad_pte(vma, addr, pte, NULL);
        return NULL;

> > +	return 0;
> > +}
> > +
> > +/* The only caller at moment passes one gmfn at a time.
> > + * PVH TBD/FIXME: expand this in future to honor batch requests.
> > + */
> > +static int pvh_remap_gmfn_range(struct vm_area_struct *vma,
> > +				unsigned long addr, unsigned long
> > mfn, int nr,
> > +				pgprot_t prot, unsigned domid,
> > +				struct xen_pvh_pfn_info *pvhp)
> > +{
> > +	int err;
> > +	struct pvh_remap_data pvhdata;
> > +
> > +	if (nr > 1)
> > +		return -EINVAL;
> > +
> > +	pvhdata.fgmfn = mfn;
> > +	pvhdata.prot = prot;
> > +	pvhdata.domid = domid;
> > +	pvhdata.pvhinfop = pvhp;
> > +	err = apply_to_page_range(vma->vm_mm, addr, nr <<
> > PAGE_SHIFT,
> > +				  pvh_map_pte_fn, &pvhdata);
> > +	flush_tlb_all();
> 
> Maybe we can use one of the flush_tlb_range varieties instead of a
> flush_tlb_all?

changed it to : flush_tlb_page(vma, addr);

> > +
> > +	if (!pvhp || !xen_feature(XENFEAT_auto_translated_physmap))
> > +		return 0;
> > +
> > +	while (pvhp->pi_next_todo--) {
> > +		unsigned long pfn;
> > +
> > +		/* the mmu has already cleaned up the process mmu
> > resources at
> > +		 * this point (lookup_address will return NULL). */
> > +		pfn =
> > page_to_pfn(pvhp->pi_paga[pvhp->pi_next_todo]);
> > +		pvh_rem_xen_p2m(pfn, 1);
> > +		count++;
> > +	}
> > +	flush_tlb_all();
> > +	return count;
> 
> Who is going to remove the corresponding mapping from the vma?
> Also we might be able to replace the flush_tlb_all with a
> flush_tlb_range.

the kernel already does that before privcmd_close is called. 
don't have the addrs for flush_tlb_range in privcmd_close().

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 Sep 26 00:27:46 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Sep 2012 00: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 1TGfTC-0004OM-BC; Wed, 26 Sep 2012 00:27:18 +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 1TGfTA-0004OH-LW
	for Xen-devel@lists.xensource.com; Wed, 26 Sep 2012 00:27:16 +0000
Received: from [85.158.139.83:36842] by server-4.bemta-5.messagelabs.com id
	5B/C5-20767-3EB42605; Wed, 26 Sep 2012 00:27:15 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1348619233!27844137!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDc3NDE3Nw==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19592 invoked from network); 26 Sep 2012 00:27:15 -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; 26 Sep 2012 00:27:15 -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 q8Q0R7fe003651
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 26 Sep 2012 00:27:08 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
	q8Q0R7Qw012841
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 26 Sep 2012 00:27:07 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
	q8Q0R7f8023227; Tue, 25 Sep 2012 19:27:07 -0500
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 25 Sep 2012 17:27:06 -0700
Date: Tue, 25 Sep 2012 17:27:05 -0700
From: Mukesh Rathor <mukesh.rathor@oracle.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20120925172705.369e1483@mantra.us.oracle.com>
In-Reply-To: <alpine.DEB.2.02.1209241321240.29232@kaball.uk.xensource.com>
References: <20120921121556.1a0ea8af@mantra.us.oracle.com>
	<alpine.DEB.2.02.1209241228460.29232@kaball.uk.xensource.com>
	<1348488991.3452.69.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.02.1209241321240.29232@kaball.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>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH v1 2/8]: PVH mmu changes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 24 Sep 2012 13:24:12 +0100
Stefano Stabellini <stefano.stabellini@eu.citrix.com> wrote:

> On Mon, 24 Sep 2012, Ian Campbell wrote:
> > On Mon, 2012-09-24 at 12:55 +0100, Stefano Stabellini wrote:
> > > There are few code style issues on this patch, I suggest you run
> > > it through scripts/checkpatch.pl, it should be able to catch all
> > > these errors.
> > 
> > It would also be nice to starting having some changelogs entries for
> > these patches for the next posting. There's a lot of complex stuff
> > > > +	return count;
> > > 
> > > Who is going to remove the corresponding mapping from the vma?
> > > Also we might be able to replace the flush_tlb_all with a
> > > flush_tlb_range.
> > 
> > I'm not convinced that a guest level TLB flush is either necessary
> > or sufficient here. What we are doing is removing entries from the
> > P2M which means that we need to do the appropriate HAP flush in the
> > hypervisor, which must necessarily invalidate any stage 1 mappings
> > which this flush might also touch (i.e. the HAP flush must be a
> > super set of this flush).
> > 
> > Without the HAP flush in the hypervisor you risk guests being able
> > to see old p2m mappings via the TLB entries which is a security
> > issue AFAICT.
> 
> Yes, you are right, we need a flush in the hypervisor to flush the
> EPT. It could probably live in the implementation of
> XENMEM_add_to_physmap.
> 
> This one should be just for the vma mappings, so in the case of
> xen_unmap_domain_mfn_range is unnecessary (given that it is
> not removing the vma mappings).


My head spins looking at INVEPT and INVVPID docs, but doesn't it already
happen in ept_set_entry():

    if ( needs_sync )
        ept_sync_domain(p2m->domain);



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 26 00:27:46 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Sep 2012 00: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 1TGfTC-0004OM-BC; Wed, 26 Sep 2012 00:27:18 +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 1TGfTA-0004OH-LW
	for Xen-devel@lists.xensource.com; Wed, 26 Sep 2012 00:27:16 +0000
Received: from [85.158.139.83:36842] by server-4.bemta-5.messagelabs.com id
	5B/C5-20767-3EB42605; Wed, 26 Sep 2012 00:27:15 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1348619233!27844137!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDc3NDE3Nw==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19592 invoked from network); 26 Sep 2012 00:27:15 -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; 26 Sep 2012 00:27:15 -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 q8Q0R7fe003651
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 26 Sep 2012 00:27:08 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
	q8Q0R7Qw012841
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 26 Sep 2012 00:27:07 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
	q8Q0R7f8023227; Tue, 25 Sep 2012 19:27:07 -0500
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 25 Sep 2012 17:27:06 -0700
Date: Tue, 25 Sep 2012 17:27:05 -0700
From: Mukesh Rathor <mukesh.rathor@oracle.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20120925172705.369e1483@mantra.us.oracle.com>
In-Reply-To: <alpine.DEB.2.02.1209241321240.29232@kaball.uk.xensource.com>
References: <20120921121556.1a0ea8af@mantra.us.oracle.com>
	<alpine.DEB.2.02.1209241228460.29232@kaball.uk.xensource.com>
	<1348488991.3452.69.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.02.1209241321240.29232@kaball.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>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH v1 2/8]: PVH mmu changes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 24 Sep 2012 13:24:12 +0100
Stefano Stabellini <stefano.stabellini@eu.citrix.com> wrote:

> On Mon, 24 Sep 2012, Ian Campbell wrote:
> > On Mon, 2012-09-24 at 12:55 +0100, Stefano Stabellini wrote:
> > > There are few code style issues on this patch, I suggest you run
> > > it through scripts/checkpatch.pl, it should be able to catch all
> > > these errors.
> > 
> > It would also be nice to starting having some changelogs entries for
> > these patches for the next posting. There's a lot of complex stuff
> > > > +	return count;
> > > 
> > > Who is going to remove the corresponding mapping from the vma?
> > > Also we might be able to replace the flush_tlb_all with a
> > > flush_tlb_range.
> > 
> > I'm not convinced that a guest level TLB flush is either necessary
> > or sufficient here. What we are doing is removing entries from the
> > P2M which means that we need to do the appropriate HAP flush in the
> > hypervisor, which must necessarily invalidate any stage 1 mappings
> > which this flush might also touch (i.e. the HAP flush must be a
> > super set of this flush).
> > 
> > Without the HAP flush in the hypervisor you risk guests being able
> > to see old p2m mappings via the TLB entries which is a security
> > issue AFAICT.
> 
> Yes, you are right, we need a flush in the hypervisor to flush the
> EPT. It could probably live in the implementation of
> XENMEM_add_to_physmap.
> 
> This one should be just for the vma mappings, so in the case of
> xen_unmap_domain_mfn_range is unnecessary (given that it is
> not removing the vma mappings).


My head spins looking at INVEPT and INVVPID docs, but doesn't it already
happen in ept_set_entry():

    if ( needs_sync )
        ept_sync_domain(p2m->domain);



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 26 00:33:52 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Sep 2012 00:33: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 1TGfZE-0004XG-5T; Wed, 26 Sep 2012 00:33:32 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mukesh.rathor@oracle.com>) id 1TGfZC-0004X8-7Z
	for Xen-devel@lists.xensource.com; Wed, 26 Sep 2012 00:33:30 +0000
Received: from [85.158.143.35:5057] by server-2.bemta-4.messagelabs.com id
	FC/62-06610-95D42605; Wed, 26 Sep 2012 00:33:29 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1348619607!10475623!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzY0MTUx\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25988 invoked from network); 26 Sep 2012 00:33:28 -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; 26 Sep 2012 00:33:28 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q8Q0XLTb016710
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 26 Sep 2012 00:33:22 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
	q8Q0XKOM001978
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 26 Sep 2012 00:33:21 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
	q8Q0XKdO028171; Tue, 25 Sep 2012 19:33:20 -0500
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 25 Sep 2012 17:33:19 -0700
Date: Tue, 25 Sep 2012 17:33:18 -0700
From: Mukesh Rathor <mukesh.rathor@oracle.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20120925173318.6c829910@mantra.us.oracle.com>
In-Reply-To: <alpine.DEB.2.02.1209241500270.29232@kaball.uk.xensource.com>
References: <20120921121556.1a0ea8af@mantra.us.oracle.com>
	<alpine.DEB.2.02.1209241500270.29232@kaball.uk.xensource.com>
Organization: Oracle Corporation
X-Mailer: Claws Mail 3.7.6 (GTK+ 2.18.9; x86_64-redhat-linux-gnu)
Mime-Version: 1.0
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: "Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH v1 2/8]: PVH mmu changes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 24 Sep 2012 15:04:22 +0100
Stefano Stabellini <stefano.stabellini@eu.citrix.com> wrote:

> On Fri, 21 Sep 2012, Mukesh Rathor wrote:
> > +struct pvh_remap_data {
> >  struct remap_data {
> > @@ -2329,7 +2468,9 @@ static int remap_area_mfn_pte_fn(pte_t *ptep,
> > pgtable_t token, int xen_remap_domain_mfn_range(struct
> > vm_area_struct *vma, unsigned long addr,
> >  			       unsigned long mfn, int nr,
> > -			       pgprot_t prot, unsigned domid)
> > +			       pgprot_t prot, unsigned domid,
> > +			       struct xen_pvh_pfn_info *pvhp)
> > +
> 
> xen_remap_domain_mfn_range is a cross-architecture call (it is
> available on ARM as well). We cannot leak architecture specific
> informations like xen_pvh_pfn_info in the parameter list.
> It seems to be that xen_pvh_pfn_info contains arch-agnostic
> information: in that case you just need to rename the struct to
> something more generic. Otherwise if it really contains x86 specific
> info, you can change it into an opaque pointer.

Ok, how about I just change it to:

-       struct xen_pvh_pfn_info *pvhp)
+       void *arch_spec_info)


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 Sep 26 00:33:52 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Sep 2012 00:33: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 1TGfZE-0004XG-5T; Wed, 26 Sep 2012 00:33:32 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mukesh.rathor@oracle.com>) id 1TGfZC-0004X8-7Z
	for Xen-devel@lists.xensource.com; Wed, 26 Sep 2012 00:33:30 +0000
Received: from [85.158.143.35:5057] by server-2.bemta-4.messagelabs.com id
	FC/62-06610-95D42605; Wed, 26 Sep 2012 00:33:29 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1348619607!10475623!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzY0MTUx\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25988 invoked from network); 26 Sep 2012 00:33:28 -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; 26 Sep 2012 00:33:28 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q8Q0XLTb016710
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 26 Sep 2012 00:33:22 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
	q8Q0XKOM001978
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 26 Sep 2012 00:33:21 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
	q8Q0XKdO028171; Tue, 25 Sep 2012 19:33:20 -0500
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 25 Sep 2012 17:33:19 -0700
Date: Tue, 25 Sep 2012 17:33:18 -0700
From: Mukesh Rathor <mukesh.rathor@oracle.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20120925173318.6c829910@mantra.us.oracle.com>
In-Reply-To: <alpine.DEB.2.02.1209241500270.29232@kaball.uk.xensource.com>
References: <20120921121556.1a0ea8af@mantra.us.oracle.com>
	<alpine.DEB.2.02.1209241500270.29232@kaball.uk.xensource.com>
Organization: Oracle Corporation
X-Mailer: Claws Mail 3.7.6 (GTK+ 2.18.9; x86_64-redhat-linux-gnu)
Mime-Version: 1.0
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: "Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH v1 2/8]: PVH mmu changes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 24 Sep 2012 15:04:22 +0100
Stefano Stabellini <stefano.stabellini@eu.citrix.com> wrote:

> On Fri, 21 Sep 2012, Mukesh Rathor wrote:
> > +struct pvh_remap_data {
> >  struct remap_data {
> > @@ -2329,7 +2468,9 @@ static int remap_area_mfn_pte_fn(pte_t *ptep,
> > pgtable_t token, int xen_remap_domain_mfn_range(struct
> > vm_area_struct *vma, unsigned long addr,
> >  			       unsigned long mfn, int nr,
> > -			       pgprot_t prot, unsigned domid)
> > +			       pgprot_t prot, unsigned domid,
> > +			       struct xen_pvh_pfn_info *pvhp)
> > +
> 
> xen_remap_domain_mfn_range is a cross-architecture call (it is
> available on ARM as well). We cannot leak architecture specific
> informations like xen_pvh_pfn_info in the parameter list.
> It seems to be that xen_pvh_pfn_info contains arch-agnostic
> information: in that case you just need to rename the struct to
> something more generic. Otherwise if it really contains x86 specific
> info, you can change it into an opaque pointer.

Ok, how about I just change it to:

-       struct xen_pvh_pfn_info *pvhp)
+       void *arch_spec_info)


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 Sep 26 00:58:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Sep 2012 00: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 1TGfxN-0004ma-Dx; Wed, 26 Sep 2012 00:58:29 +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 1TGfxL-0004mV-Rr
	for xen-devel@lists.xen.org; Wed, 26 Sep 2012 00:58:28 +0000
Received: from [85.158.138.51:56720] by server-16.bemta-3.messagelabs.com id
	E7/9E-31776-33352605; Wed, 26 Sep 2012 00:58:27 +0000
X-Env-Sender: xudong.hao@intel.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1348621105!23885411!1
X-Originating-IP: [192.55.52.88]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjg4ID0+IDMyMzY2Ng==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6399 invoked from network); 26 Sep 2012 00:58:26 -0000
Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88)
	by server-3.tower-174.messagelabs.com with SMTP;
	26 Sep 2012 00:58:26 -0000
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
	by fmsmga101.fm.intel.com with ESMTP; 25 Sep 2012 17:58:25 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.80,486,1344236400"; d="scan'208";a="226459265"
Received: from fmsmsx105.amr.corp.intel.com ([10.19.9.36])
	by fmsmga001.fm.intel.com with ESMTP; 25 Sep 2012 17:58:24 -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; Tue, 25 Sep 2012 17:58:24 -0700
Received: from shsmsx102.ccr.corp.intel.com ([169.254.2.92]) by
	SHSMSX101.ccr.corp.intel.com ([169.254.1.239]) with mapi id
	14.01.0355.002; Wed, 26 Sep 2012 08:58:22 +0800
From: "Hao, Xudong" <xudong.hao@intel.com>
To: Keir Fraser <keir@xen.org>, "xen-devel@lists.xen.org"
	<xen-devel@lists.xen.org>
Thread-Topic: [Xen-devel] [PATCH v2] xen/tools: Add 64 bits big bar support
Thread-Index: AQHNms4J6w8sNO8+FEeWdkWyUHsLXpealBIAgAE4tVA=
Date: Wed, 26 Sep 2012 00:58:22 +0000
Message-ID: <403610A45A2B5242BD291EDAE8B37D300FEC702B@SHSMSX102.ccr.corp.intel.com>
References: <1348543998-31304-1-git-send-email-xudong.hao@intel.com>
	<CC877A88.4CD63%keir@xen.org>
In-Reply-To: <CC877A88.4CD63%keir@xen.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: "Zhang, Xiantao" <xiantao.zhang@intel.com>,
	"ian.campbell@citrix.com" <ian.campbell@citrix.com>,
	"jbeulich@suse.com" <jbeulich@suse.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v2] xen/tools: Add 64 bits big bar 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: Keir Fraser [mailto:keir.xen@gmail.com] On Behalf Of Keir Fraser
> Sent: Tuesday, September 25, 2012 10:13 PM
> To: xen-devel@lists.xen.org
> Cc: ian.campbell@citrix.com; Stefano Stabellini; Hao, Xudong;
> jbeulich@suse.com; Zhang, Xiantao
> Subject: Re: [Xen-devel] [PATCH v2] xen/tools: Add 64 bits big bar support
> 
> 
> 
> 
> On 25/09/2012 04:33, "" <> wrote:
> 
> > Currently it is assumed PCI device BAR access < 4G memory. If there is such a
> > device whose BAR size is larger than 4G, it must access > 4G memory
> address.
> > This patch enable the 64bits big BAR support on hvmloader.
> >
> > Changes from v1:
> > 1) Set Dynamic MMIO high memory address instead of a fixed number 640G
> > 2) Mask bar_sz earlier to avoid older code changes
> > 3) Add bar size barrier to judge high memory resource
> > 4) Clean up bar64_relocate code
> >
> > Signed-off-by: Xiantao Zhang <xiantao.zhang@intel.com>
> > Signed-off-by: Xudong Hao <xudong.hao@intel.com>
> 
> ...
> 
> > @@ -258,8 +298,8 @@
> >          resource->base = base;
> >
> >          pci_writel(devfn, bar_reg, bar_data);
> > -        printf("pci dev %02x:%x bar %02x size %08x: %08x\n",
> > -               devfn>>3, devfn&7, bar_reg, bar_sz, bar_data);
> > +        if (using_64bar)
> > +            pci_writel(devfn, bar_reg + 4, bar_data_upper);
> 
> Why is the printf removed?
> 

No special reason. It's a successful print, I'll modify patch if we want to remain it.

>  -- Keir
> 
> 
> >          /* Now enable the memory or I/O mapping. */
> >          cmd = pci_readw(devfn, PCI_COMMAND);
> > diff -r dc56a9defa30 tools/firmware/hvmloader/util.h
> > --- a/tools/firmware/hvmloader/util.h Tue Aug 14 10:28:14 2012 +0200
> > +++ b/tools/firmware/hvmloader/util.h Wed Sep 12 14:50:55 2012 +0800
> > @@ -215,6 +215,7 @@
> >  uint32_t rombios_highbios_setup(void);
> >
> >  /* Miscellaneous. */
> > +unsigned int cpu_phys_addr(void);
> >  void cacheattr_init(void);
> >  unsigned long create_mp_tables(void *table);
> >  void hvm_write_smbios_tables(
> >
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xen.org
> > http://lists.xen.org/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 Sep 26 00:58:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Sep 2012 00: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 1TGfxN-0004ma-Dx; Wed, 26 Sep 2012 00:58:29 +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 1TGfxL-0004mV-Rr
	for xen-devel@lists.xen.org; Wed, 26 Sep 2012 00:58:28 +0000
Received: from [85.158.138.51:56720] by server-16.bemta-3.messagelabs.com id
	E7/9E-31776-33352605; Wed, 26 Sep 2012 00:58:27 +0000
X-Env-Sender: xudong.hao@intel.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1348621105!23885411!1
X-Originating-IP: [192.55.52.88]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjg4ID0+IDMyMzY2Ng==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6399 invoked from network); 26 Sep 2012 00:58:26 -0000
Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88)
	by server-3.tower-174.messagelabs.com with SMTP;
	26 Sep 2012 00:58:26 -0000
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
	by fmsmga101.fm.intel.com with ESMTP; 25 Sep 2012 17:58:25 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.80,486,1344236400"; d="scan'208";a="226459265"
Received: from fmsmsx105.amr.corp.intel.com ([10.19.9.36])
	by fmsmga001.fm.intel.com with ESMTP; 25 Sep 2012 17:58:24 -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; Tue, 25 Sep 2012 17:58:24 -0700
Received: from shsmsx102.ccr.corp.intel.com ([169.254.2.92]) by
	SHSMSX101.ccr.corp.intel.com ([169.254.1.239]) with mapi id
	14.01.0355.002; Wed, 26 Sep 2012 08:58:22 +0800
From: "Hao, Xudong" <xudong.hao@intel.com>
To: Keir Fraser <keir@xen.org>, "xen-devel@lists.xen.org"
	<xen-devel@lists.xen.org>
Thread-Topic: [Xen-devel] [PATCH v2] xen/tools: Add 64 bits big bar support
Thread-Index: AQHNms4J6w8sNO8+FEeWdkWyUHsLXpealBIAgAE4tVA=
Date: Wed, 26 Sep 2012 00:58:22 +0000
Message-ID: <403610A45A2B5242BD291EDAE8B37D300FEC702B@SHSMSX102.ccr.corp.intel.com>
References: <1348543998-31304-1-git-send-email-xudong.hao@intel.com>
	<CC877A88.4CD63%keir@xen.org>
In-Reply-To: <CC877A88.4CD63%keir@xen.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: "Zhang, Xiantao" <xiantao.zhang@intel.com>,
	"ian.campbell@citrix.com" <ian.campbell@citrix.com>,
	"jbeulich@suse.com" <jbeulich@suse.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v2] xen/tools: Add 64 bits big bar 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: Keir Fraser [mailto:keir.xen@gmail.com] On Behalf Of Keir Fraser
> Sent: Tuesday, September 25, 2012 10:13 PM
> To: xen-devel@lists.xen.org
> Cc: ian.campbell@citrix.com; Stefano Stabellini; Hao, Xudong;
> jbeulich@suse.com; Zhang, Xiantao
> Subject: Re: [Xen-devel] [PATCH v2] xen/tools: Add 64 bits big bar support
> 
> 
> 
> 
> On 25/09/2012 04:33, "" <> wrote:
> 
> > Currently it is assumed PCI device BAR access < 4G memory. If there is such a
> > device whose BAR size is larger than 4G, it must access > 4G memory
> address.
> > This patch enable the 64bits big BAR support on hvmloader.
> >
> > Changes from v1:
> > 1) Set Dynamic MMIO high memory address instead of a fixed number 640G
> > 2) Mask bar_sz earlier to avoid older code changes
> > 3) Add bar size barrier to judge high memory resource
> > 4) Clean up bar64_relocate code
> >
> > Signed-off-by: Xiantao Zhang <xiantao.zhang@intel.com>
> > Signed-off-by: Xudong Hao <xudong.hao@intel.com>
> 
> ...
> 
> > @@ -258,8 +298,8 @@
> >          resource->base = base;
> >
> >          pci_writel(devfn, bar_reg, bar_data);
> > -        printf("pci dev %02x:%x bar %02x size %08x: %08x\n",
> > -               devfn>>3, devfn&7, bar_reg, bar_sz, bar_data);
> > +        if (using_64bar)
> > +            pci_writel(devfn, bar_reg + 4, bar_data_upper);
> 
> Why is the printf removed?
> 

No special reason. It's a successful print, I'll modify patch if we want to remain it.

>  -- Keir
> 
> 
> >          /* Now enable the memory or I/O mapping. */
> >          cmd = pci_readw(devfn, PCI_COMMAND);
> > diff -r dc56a9defa30 tools/firmware/hvmloader/util.h
> > --- a/tools/firmware/hvmloader/util.h Tue Aug 14 10:28:14 2012 +0200
> > +++ b/tools/firmware/hvmloader/util.h Wed Sep 12 14:50:55 2012 +0800
> > @@ -215,6 +215,7 @@
> >  uint32_t rombios_highbios_setup(void);
> >
> >  /* Miscellaneous. */
> > +unsigned int cpu_phys_addr(void);
> >  void cacheattr_init(void);
> >  unsigned long create_mp_tables(void *table);
> >  void hvm_write_smbios_tables(
> >
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xen.org
> > http://lists.xen.org/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 Sep 26 01:03:06 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Sep 2012 01:03:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGg1O-0000GI-34; Wed, 26 Sep 2012 01:02:38 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <john.krstev@gmail.com>) id 1TGg1N-0000GB-1e
	for xen-devel@lists.xensource.com; Wed, 26 Sep 2012 01:02:37 +0000
Received: from [85.158.139.83:63285] by server-10.bemta-5.messagelabs.com id
	68/57-16911-C2452605; Wed, 26 Sep 2012 01:02:36 +0000
X-Env-Sender: john.krstev@gmail.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1348621353!28167972!1
X-Originating-IP: [209.85.212.43]
X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_20_30,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3410 invoked from network); 26 Sep 2012 01:02:34 -0000
Received: from mail-vb0-f43.google.com (HELO mail-vb0-f43.google.com)
	(209.85.212.43)
	by server-7.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Sep 2012 01:02:34 -0000
Received: by vbbfq11 with SMTP id fq11so59872vbb.30
	for <xen-devel@lists.xensource.com>;
	Tue, 25 Sep 2012 18:02:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=JVN6N6JU86I60MqZl7xrVN/qoIz8eV092hSa6NG0ZXk=;
	b=z2LC5VxbxqZLFbyZAZxpEvmW/9CVt1pso54PHzRT5+UXEY00QzGSR4C/eJLBSB4CNM
	WroIZTnlqWxj3NLvFonDDztKZge56muZXSWXiOGH3HKLkIBK58seEAH8j93ze68JcPEb
	Q/z5kgpYqyrfKiRxL668UBx2m8OtaVWWFIUKXYTQFAr4HAdiY9JjpWHnmDWofPEwBnMe
	TRmWM/avKKtSAkpe0DHH2HOHBVc9eV1sOTc7oXUqjxLXZ/ztsR7FOq6UIp+fkw9m36AC
	plnn/6UTPS4CFpaxLrp1xocwFRecdnQyfDnUMDyoPwy5B0Y5kLLOb8tmBEMURZaySwM4
	/QCg==
MIME-Version: 1.0
Received: by 10.52.29.47 with SMTP id g15mr8035603vdh.89.1348621353347; Tue,
	25 Sep 2012 18:02:33 -0700 (PDT)
Received: by 10.58.29.37 with HTTP; Tue, 25 Sep 2012 18:02:33 -0700 (PDT)
In-Reply-To: <20120925141013.GC16478@phenom.dumpdata.com>
References: <CA+LkAa=RHJCtpncP8AUSeR8Te3ZLMvRctuZqnv_NwUkCQ-im8Q@mail.gmail.com>
	<20120921172901.GA6821@phenom.dumpdata.com>
	<099949C5-C4C0-4D57-A778-849C94781372@gmail.com>
	<20120925141013.GC16478@phenom.dumpdata.com>
Date: Wed, 26 Sep 2012 11:02:33 +1000
Message-ID: <CA+LkAa==rHSiZ5JqDo1MC-HEJWPa=QEBd7X6vSxFjLSRMpM58g@mail.gmail.com>
From: John Krstev <john.krstev@gmail.com>
To: Konrad Rzeszutek Wilk <konrad@kernel.org>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Xen + DVB = not working. memory allocation issue?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============4941203608672683827=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============4941203608672683827==
Content-Type: multipart/alternative; boundary=20cf3079ba3eb3ec4904ca90602a

--20cf3079ba3eb3ec4904ca90602a
Content-Type: text/plain; charset=ISO-8859-1

Hey Konrad,

>Please do not top-post.
Apologies.


>So try also limiting how much memory the hypervisor has to eliminate
>this being a 4GB issue. Meaning on the _hypervisor_ line add 'mem=4G'.

Yes, that was on the hypervisor line which I was specifying mem=3G. I've
also tried mem=4G and still having the same problem.

>And I need to know whether you are running this in a domain or in the
initial domain?

Running in Dom0.

>If you do it manually (cat /dev/video0 > /tmp/file.mpg)
>does the file increase? Is it full of garbage ?

cat: /dev/video0: Input/output error

The file size is 0 bytes.

>Does the channel selection work? Can you select the proper channel?
Analogue selection works ok and I can also watch analogue TV. When using
digital, I get a lock but no video data.

> If you crank up all the debug options do you get anything saying what the
problem is

With debug turned on to level 8 (echo 8 > /proc/sys/kernel/printk) I see
the following in dmesg which may be useful:
[130009.484098] cx88[0]/0: [ffff8802c03b3400/0] timeout - dma=0x96a7e000

Let me know if there's anything else I can try?

Regards,

John

On 26 September 2012 00:10, Konrad Rzeszutek Wilk <konrad@kernel.org> wrote:

> On Tue, Sep 25, 2012 at 10:49:38AM +1000, John Krstev wrote:
> > Hello Konrad,
>
> Hey John,
>
> Please do not top-post.
> >
> > Do you have any patches I can try? FYI I've tried booting dom0 with
> mem=3G and various other options, still does not work. As I mentioned it
> runs fine on bare metal.
>
> So try also limiting how much memory the hypervisor has to eliminate
> this being a 4GB issue. Meaning on the _hypervisor_ line add 'mem=4G'.
>
> The next step is to actually figure out if where in the driver (cx88)
> fails. And I need to know whether you are running this in a domain or
> in the initial domain? If you crank up all the debug options do you
> get anything saying what the problem is? How do you 'capture' the
> video output? If you do it manually (cat /dev/video0 > /tmp/file.mpg)
> does the file increase? Is it full of garbage ?
>
> Does the channel selection work? Can you select the proper channel?
>
> >
> > Last time it did work with xen was Jeremy's kernel + xen 4.0, also
> kernel 3.0.8 with xen 4.0.4 i believe (cannot reproduce success).
> >
> > Thank you again for your input.
> >
> > Regards,
> >
> > John
> >
> >
> >
> > On 22/09/2012, at 3:29, Konrad Rzeszutek Wilk <konrad@kernel.org> wrote:
> >
> > > On Fri, Sep 21, 2012 at 01:02:23PM +1000, John Krstev wrote:
> > >> Hi Konrad,
> > >
> > > Hey John,
> > >
> > > Please next time also include xen-devel on the To header. I've done
> that
> > > for you.
> > >>
> > >> I refer to your patch at:
> > >> http://lists.xen.org/archives/html/xen-devel/2012-01/msg01927.html
> > >> which I found reading
> > >> http://www.gossamer-threads.com/lists/xen/devel/256197
> > >>
> > >> I have a winfast DVT 2000H (cx88) DVB card which is not able to
> > >> scan/watch digital TV when running under Xen.
> > >
> > > Did you first try running it under baremetal Linux (using a Live CD for
> > > example?) Did it work there?
> > >
> > > How does it not work? Can you program it? Is this under a guest or the
> > > main kernel? When it wsa not working, did you try all the debug
> > > options enable (http://wiki.xen.org/wiki/XenSerialConsole) to
> > > see if there is anthing being reported?
> > >
> > >>
> > >> I've tried installing the above patch to the 3.6-rc6 kernel, but did
> > >> not seem to help.
> > >>
> > >> Apologies if this has been asked before (I wasn't able to find another
> > >> patch), but is there a patch to get this (suspected vmalloc_32) fixed
> > >> and DVB card working?
> > >
> > > Eventually yes.
> > >>
> > >> FYI I'm running 64 bit 3.5-rc6 and xen 4.3-unstable.
> > >
> > > 3.5-rc6 or 3.6-rc6?
> > > I presume the latter?
> > >>
> > >> Thank you! :)
> > >>
> > >> Regards,
> > >>
> > >> John
> > >>
> >
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xen.org
> > http://lists.xen.org/xen-devel
> >
>

--20cf3079ba3eb3ec4904ca90602a
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hey Konrad,<br><br>&gt;Please do not top-post.<br>Apologies. <br><br><br>&g=
t;So try also limiting how much memory the hypervisor has to eliminate<br>
&gt;this being a 4GB issue. Meaning on the _hypervisor_ line add &#39;mem=
=3D4G&#39;.<br><br>Yes, that was on the hypervisor line which I was specify=
ing mem=3D3G. I&#39;ve also tried mem=3D4G and still having the same proble=
m.<br>
<br>&gt;And I need to know whether you are running this in a domain or in t=
he initial domain?<br>
<br>Running in Dom0.<br><br>&gt;If you do it manually (cat /dev/video0 &gt;=
 /tmp/file.mpg)<br>
&gt;does the file increase? Is it full of garbage ?<br><br>cat: /dev/video0=
: Input/output error<br><br>The file size is 0 bytes.<br><br>&gt;Does the c=
hannel selection work? Can you select the proper channel?<br>Analogue selec=
tion works ok and I can also watch analogue TV. When using digital, I get a=
 lock but no video data.<br>

<br>&gt; If you crank up all the debug options do you get anything saying w=
hat the problem is<br><br>With debug turned on to level 8 (echo 8 &gt; /pro=
c/sys/kernel/printk) I see the following in dmesg which may be useful:<br>
[130009.484098] cx88[0]/0: [ffff8802c03b3400/0] timeout - dma=3D0x96a7e000<=
br><br>Let me know if there&#39;s anything else I can try?<br><br>Regards,<=
br><br>John<br><br><div class=3D"gmail_quote">On 26 September 2012 00:10, K=
onrad Rzeszutek Wilk <span dir=3D"ltr">&lt;<a href=3D"mailto:konrad@kernel.=
org" target=3D"_blank">konrad@kernel.org</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 Tue, Sep 25, 2012 at 10:49:38AM +1000, John Krstev wrote:<br>
&gt; Hello Konrad,<br>
<br>
Hey John,<br>
<br>
Please do not top-post.<br>
<div>&gt;<br>
&gt; Do you have any patches I can try? FYI I&#39;ve tried booting dom0 wit=
h mem=3D3G and various other options, still does not work. As I mentioned i=
t runs fine on bare metal.<br>
<br>
</div>So try also limiting how much memory the hypervisor has to eliminate<=
br>
this being a 4GB issue. Meaning on the _hypervisor_ line add &#39;mem=3D4G&=
#39;.<br>
<br>
The next step is to actually figure out if where in the driver (cx88)<br>
fails. And I need to know whether you are running this in a domain or<br>
in the initial domain? If you crank up all the debug options do you<br>
get anything saying what the problem is? How do you &#39;capture&#39; the<b=
r>
video output? If you do it manually (cat /dev/video0 &gt; /tmp/file.mpg)<br=
>
does the file increase? Is it full of garbage ?<br>
<br>
Does the channel selection work? Can you select the proper channel?<br>
<div><div><br>
&gt;<br>
&gt; Last time it did work with xen was Jeremy&#39;s kernel + xen 4.0, also=
 kernel 3.0.8 with xen 4.0.4 i believe (cannot reproduce success).<br>
&gt;<br>
&gt; Thank you again for your input.<br>
&gt;<br>
&gt; Regards,<br>
&gt;<br>
&gt; John<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; On 22/09/2012, at 3:29, Konrad Rzeszutek Wilk &lt;<a href=3D"mailto:ko=
nrad@kernel.org" target=3D"_blank">konrad@kernel.org</a>&gt; wrote:<br>
&gt;<br>
&gt; &gt; On Fri, Sep 21, 2012 at 01:02:23PM +1000, John Krstev wrote:<br>
&gt; &gt;&gt; Hi Konrad,<br>
&gt; &gt;<br>
&gt; &gt; Hey John,<br>
&gt; &gt;<br>
&gt; &gt; Please next time also include xen-devel on the To header. I&#39;v=
e done that<br>
&gt; &gt; for you.<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt; I refer to your patch at:<br>
&gt; &gt;&gt; <a href=3D"http://lists.xen.org/archives/html/xen-devel/2012-=
01/msg01927.html" target=3D"_blank">http://lists.xen.org/archives/html/xen-=
devel/2012-01/msg01927.html</a><br>
&gt; &gt;&gt; which I found reading<br>
&gt; &gt;&gt; <a href=3D"http://www.gossamer-threads.com/lists/xen/devel/25=
6197" target=3D"_blank">http://www.gossamer-threads.com/lists/xen/devel/256=
197</a><br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt; I have a winfast DVT 2000H (cx88) DVB card which is not able =
to<br>
&gt; &gt;&gt; scan/watch digital TV when running under Xen.<br>
&gt; &gt;<br>
&gt; &gt; Did you first try running it under baremetal Linux (using a Live =
CD for<br>
&gt; &gt; example?) Did it work there?<br>
&gt; &gt;<br>
&gt; &gt; How does it not work? Can you program it? Is this under a guest o=
r the<br>
&gt; &gt; main kernel? When it wsa not working, did you try all the debug<b=
r>
&gt; &gt; options enable (<a href=3D"http://wiki.xen.org/wiki/XenSerialCons=
ole" target=3D"_blank">http://wiki.xen.org/wiki/XenSerialConsole</a>) to<br=
>
&gt; &gt; see if there is anthing being reported?<br>
&gt; &gt;<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt; I&#39;ve tried installing the above patch to the 3.6-rc6 kern=
el, but did<br>
&gt; &gt;&gt; not seem to help.<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt; Apologies if this has been asked before (I wasn&#39;t able to=
 find another<br>
&gt; &gt;&gt; patch), but is there a patch to get this (suspected vmalloc_3=
2) fixed<br>
&gt; &gt;&gt; and DVB card working?<br>
&gt; &gt;<br>
&gt; &gt; Eventually yes.<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt; FYI I&#39;m running 64 bit 3.5-rc6 and xen 4.3-unstable.<br>
&gt; &gt;<br>
&gt; &gt; 3.5-rc6 or 3.6-rc6?<br>
&gt; &gt; I presume the latter?<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt; Thank you! :)<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt; Regards,<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt; John<br>
&gt; &gt;&gt;<br>
&gt;<br>
</div></div>&gt; _______________________________________________<br>
&gt; Xen-devel mailing list<br>
&gt; <a href=3D"mailto:Xen-devel@lists.xen.org" target=3D"_blank">Xen-devel=
@lists.xen.org</a><br>
&gt; <a href=3D"http://lists.xen.org/xen-devel" target=3D"_blank">http://li=
sts.xen.org/xen-devel</a><br>
&gt;<br>
</blockquote></div><br>

--20cf3079ba3eb3ec4904ca90602a--


--===============4941203608672683827==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============4941203608672683827==--


From xen-devel-bounces@lists.xen.org Wed Sep 26 01:03:06 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Sep 2012 01:03:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGg1O-0000GI-34; Wed, 26 Sep 2012 01:02:38 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <john.krstev@gmail.com>) id 1TGg1N-0000GB-1e
	for xen-devel@lists.xensource.com; Wed, 26 Sep 2012 01:02:37 +0000
Received: from [85.158.139.83:63285] by server-10.bemta-5.messagelabs.com id
	68/57-16911-C2452605; Wed, 26 Sep 2012 01:02:36 +0000
X-Env-Sender: john.krstev@gmail.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1348621353!28167972!1
X-Originating-IP: [209.85.212.43]
X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_20_30,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3410 invoked from network); 26 Sep 2012 01:02:34 -0000
Received: from mail-vb0-f43.google.com (HELO mail-vb0-f43.google.com)
	(209.85.212.43)
	by server-7.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Sep 2012 01:02:34 -0000
Received: by vbbfq11 with SMTP id fq11so59872vbb.30
	for <xen-devel@lists.xensource.com>;
	Tue, 25 Sep 2012 18:02:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=JVN6N6JU86I60MqZl7xrVN/qoIz8eV092hSa6NG0ZXk=;
	b=z2LC5VxbxqZLFbyZAZxpEvmW/9CVt1pso54PHzRT5+UXEY00QzGSR4C/eJLBSB4CNM
	WroIZTnlqWxj3NLvFonDDztKZge56muZXSWXiOGH3HKLkIBK58seEAH8j93ze68JcPEb
	Q/z5kgpYqyrfKiRxL668UBx2m8OtaVWWFIUKXYTQFAr4HAdiY9JjpWHnmDWofPEwBnMe
	TRmWM/avKKtSAkpe0DHH2HOHBVc9eV1sOTc7oXUqjxLXZ/ztsR7FOq6UIp+fkw9m36AC
	plnn/6UTPS4CFpaxLrp1xocwFRecdnQyfDnUMDyoPwy5B0Y5kLLOb8tmBEMURZaySwM4
	/QCg==
MIME-Version: 1.0
Received: by 10.52.29.47 with SMTP id g15mr8035603vdh.89.1348621353347; Tue,
	25 Sep 2012 18:02:33 -0700 (PDT)
Received: by 10.58.29.37 with HTTP; Tue, 25 Sep 2012 18:02:33 -0700 (PDT)
In-Reply-To: <20120925141013.GC16478@phenom.dumpdata.com>
References: <CA+LkAa=RHJCtpncP8AUSeR8Te3ZLMvRctuZqnv_NwUkCQ-im8Q@mail.gmail.com>
	<20120921172901.GA6821@phenom.dumpdata.com>
	<099949C5-C4C0-4D57-A778-849C94781372@gmail.com>
	<20120925141013.GC16478@phenom.dumpdata.com>
Date: Wed, 26 Sep 2012 11:02:33 +1000
Message-ID: <CA+LkAa==rHSiZ5JqDo1MC-HEJWPa=QEBd7X6vSxFjLSRMpM58g@mail.gmail.com>
From: John Krstev <john.krstev@gmail.com>
To: Konrad Rzeszutek Wilk <konrad@kernel.org>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Xen + DVB = not working. memory allocation issue?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============4941203608672683827=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============4941203608672683827==
Content-Type: multipart/alternative; boundary=20cf3079ba3eb3ec4904ca90602a

--20cf3079ba3eb3ec4904ca90602a
Content-Type: text/plain; charset=ISO-8859-1

Hey Konrad,

>Please do not top-post.
Apologies.


>So try also limiting how much memory the hypervisor has to eliminate
>this being a 4GB issue. Meaning on the _hypervisor_ line add 'mem=4G'.

Yes, that was on the hypervisor line which I was specifying mem=3G. I've
also tried mem=4G and still having the same problem.

>And I need to know whether you are running this in a domain or in the
initial domain?

Running in Dom0.

>If you do it manually (cat /dev/video0 > /tmp/file.mpg)
>does the file increase? Is it full of garbage ?

cat: /dev/video0: Input/output error

The file size is 0 bytes.

>Does the channel selection work? Can you select the proper channel?
Analogue selection works ok and I can also watch analogue TV. When using
digital, I get a lock but no video data.

> If you crank up all the debug options do you get anything saying what the
problem is

With debug turned on to level 8 (echo 8 > /proc/sys/kernel/printk) I see
the following in dmesg which may be useful:
[130009.484098] cx88[0]/0: [ffff8802c03b3400/0] timeout - dma=0x96a7e000

Let me know if there's anything else I can try?

Regards,

John

On 26 September 2012 00:10, Konrad Rzeszutek Wilk <konrad@kernel.org> wrote:

> On Tue, Sep 25, 2012 at 10:49:38AM +1000, John Krstev wrote:
> > Hello Konrad,
>
> Hey John,
>
> Please do not top-post.
> >
> > Do you have any patches I can try? FYI I've tried booting dom0 with
> mem=3G and various other options, still does not work. As I mentioned it
> runs fine on bare metal.
>
> So try also limiting how much memory the hypervisor has to eliminate
> this being a 4GB issue. Meaning on the _hypervisor_ line add 'mem=4G'.
>
> The next step is to actually figure out if where in the driver (cx88)
> fails. And I need to know whether you are running this in a domain or
> in the initial domain? If you crank up all the debug options do you
> get anything saying what the problem is? How do you 'capture' the
> video output? If you do it manually (cat /dev/video0 > /tmp/file.mpg)
> does the file increase? Is it full of garbage ?
>
> Does the channel selection work? Can you select the proper channel?
>
> >
> > Last time it did work with xen was Jeremy's kernel + xen 4.0, also
> kernel 3.0.8 with xen 4.0.4 i believe (cannot reproduce success).
> >
> > Thank you again for your input.
> >
> > Regards,
> >
> > John
> >
> >
> >
> > On 22/09/2012, at 3:29, Konrad Rzeszutek Wilk <konrad@kernel.org> wrote:
> >
> > > On Fri, Sep 21, 2012 at 01:02:23PM +1000, John Krstev wrote:
> > >> Hi Konrad,
> > >
> > > Hey John,
> > >
> > > Please next time also include xen-devel on the To header. I've done
> that
> > > for you.
> > >>
> > >> I refer to your patch at:
> > >> http://lists.xen.org/archives/html/xen-devel/2012-01/msg01927.html
> > >> which I found reading
> > >> http://www.gossamer-threads.com/lists/xen/devel/256197
> > >>
> > >> I have a winfast DVT 2000H (cx88) DVB card which is not able to
> > >> scan/watch digital TV when running under Xen.
> > >
> > > Did you first try running it under baremetal Linux (using a Live CD for
> > > example?) Did it work there?
> > >
> > > How does it not work? Can you program it? Is this under a guest or the
> > > main kernel? When it wsa not working, did you try all the debug
> > > options enable (http://wiki.xen.org/wiki/XenSerialConsole) to
> > > see if there is anthing being reported?
> > >
> > >>
> > >> I've tried installing the above patch to the 3.6-rc6 kernel, but did
> > >> not seem to help.
> > >>
> > >> Apologies if this has been asked before (I wasn't able to find another
> > >> patch), but is there a patch to get this (suspected vmalloc_32) fixed
> > >> and DVB card working?
> > >
> > > Eventually yes.
> > >>
> > >> FYI I'm running 64 bit 3.5-rc6 and xen 4.3-unstable.
> > >
> > > 3.5-rc6 or 3.6-rc6?
> > > I presume the latter?
> > >>
> > >> Thank you! :)
> > >>
> > >> Regards,
> > >>
> > >> John
> > >>
> >
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xen.org
> > http://lists.xen.org/xen-devel
> >
>

--20cf3079ba3eb3ec4904ca90602a
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hey Konrad,<br><br>&gt;Please do not top-post.<br>Apologies. <br><br><br>&g=
t;So try also limiting how much memory the hypervisor has to eliminate<br>
&gt;this being a 4GB issue. Meaning on the _hypervisor_ line add &#39;mem=
=3D4G&#39;.<br><br>Yes, that was on the hypervisor line which I was specify=
ing mem=3D3G. I&#39;ve also tried mem=3D4G and still having the same proble=
m.<br>
<br>&gt;And I need to know whether you are running this in a domain or in t=
he initial domain?<br>
<br>Running in Dom0.<br><br>&gt;If you do it manually (cat /dev/video0 &gt;=
 /tmp/file.mpg)<br>
&gt;does the file increase? Is it full of garbage ?<br><br>cat: /dev/video0=
: Input/output error<br><br>The file size is 0 bytes.<br><br>&gt;Does the c=
hannel selection work? Can you select the proper channel?<br>Analogue selec=
tion works ok and I can also watch analogue TV. When using digital, I get a=
 lock but no video data.<br>

<br>&gt; If you crank up all the debug options do you get anything saying w=
hat the problem is<br><br>With debug turned on to level 8 (echo 8 &gt; /pro=
c/sys/kernel/printk) I see the following in dmesg which may be useful:<br>
[130009.484098] cx88[0]/0: [ffff8802c03b3400/0] timeout - dma=3D0x96a7e000<=
br><br>Let me know if there&#39;s anything else I can try?<br><br>Regards,<=
br><br>John<br><br><div class=3D"gmail_quote">On 26 September 2012 00:10, K=
onrad Rzeszutek Wilk <span dir=3D"ltr">&lt;<a href=3D"mailto:konrad@kernel.=
org" target=3D"_blank">konrad@kernel.org</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 Tue, Sep 25, 2012 at 10:49:38AM +1000, John Krstev wrote:<br>
&gt; Hello Konrad,<br>
<br>
Hey John,<br>
<br>
Please do not top-post.<br>
<div>&gt;<br>
&gt; Do you have any patches I can try? FYI I&#39;ve tried booting dom0 wit=
h mem=3D3G and various other options, still does not work. As I mentioned i=
t runs fine on bare metal.<br>
<br>
</div>So try also limiting how much memory the hypervisor has to eliminate<=
br>
this being a 4GB issue. Meaning on the _hypervisor_ line add &#39;mem=3D4G&=
#39;.<br>
<br>
The next step is to actually figure out if where in the driver (cx88)<br>
fails. And I need to know whether you are running this in a domain or<br>
in the initial domain? If you crank up all the debug options do you<br>
get anything saying what the problem is? How do you &#39;capture&#39; the<b=
r>
video output? If you do it manually (cat /dev/video0 &gt; /tmp/file.mpg)<br=
>
does the file increase? Is it full of garbage ?<br>
<br>
Does the channel selection work? Can you select the proper channel?<br>
<div><div><br>
&gt;<br>
&gt; Last time it did work with xen was Jeremy&#39;s kernel + xen 4.0, also=
 kernel 3.0.8 with xen 4.0.4 i believe (cannot reproduce success).<br>
&gt;<br>
&gt; Thank you again for your input.<br>
&gt;<br>
&gt; Regards,<br>
&gt;<br>
&gt; John<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; On 22/09/2012, at 3:29, Konrad Rzeszutek Wilk &lt;<a href=3D"mailto:ko=
nrad@kernel.org" target=3D"_blank">konrad@kernel.org</a>&gt; wrote:<br>
&gt;<br>
&gt; &gt; On Fri, Sep 21, 2012 at 01:02:23PM +1000, John Krstev wrote:<br>
&gt; &gt;&gt; Hi Konrad,<br>
&gt; &gt;<br>
&gt; &gt; Hey John,<br>
&gt; &gt;<br>
&gt; &gt; Please next time also include xen-devel on the To header. I&#39;v=
e done that<br>
&gt; &gt; for you.<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt; I refer to your patch at:<br>
&gt; &gt;&gt; <a href=3D"http://lists.xen.org/archives/html/xen-devel/2012-=
01/msg01927.html" target=3D"_blank">http://lists.xen.org/archives/html/xen-=
devel/2012-01/msg01927.html</a><br>
&gt; &gt;&gt; which I found reading<br>
&gt; &gt;&gt; <a href=3D"http://www.gossamer-threads.com/lists/xen/devel/25=
6197" target=3D"_blank">http://www.gossamer-threads.com/lists/xen/devel/256=
197</a><br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt; I have a winfast DVT 2000H (cx88) DVB card which is not able =
to<br>
&gt; &gt;&gt; scan/watch digital TV when running under Xen.<br>
&gt; &gt;<br>
&gt; &gt; Did you first try running it under baremetal Linux (using a Live =
CD for<br>
&gt; &gt; example?) Did it work there?<br>
&gt; &gt;<br>
&gt; &gt; How does it not work? Can you program it? Is this under a guest o=
r the<br>
&gt; &gt; main kernel? When it wsa not working, did you try all the debug<b=
r>
&gt; &gt; options enable (<a href=3D"http://wiki.xen.org/wiki/XenSerialCons=
ole" target=3D"_blank">http://wiki.xen.org/wiki/XenSerialConsole</a>) to<br=
>
&gt; &gt; see if there is anthing being reported?<br>
&gt; &gt;<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt; I&#39;ve tried installing the above patch to the 3.6-rc6 kern=
el, but did<br>
&gt; &gt;&gt; not seem to help.<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt; Apologies if this has been asked before (I wasn&#39;t able to=
 find another<br>
&gt; &gt;&gt; patch), but is there a patch to get this (suspected vmalloc_3=
2) fixed<br>
&gt; &gt;&gt; and DVB card working?<br>
&gt; &gt;<br>
&gt; &gt; Eventually yes.<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt; FYI I&#39;m running 64 bit 3.5-rc6 and xen 4.3-unstable.<br>
&gt; &gt;<br>
&gt; &gt; 3.5-rc6 or 3.6-rc6?<br>
&gt; &gt; I presume the latter?<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt; Thank you! :)<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt; Regards,<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt; John<br>
&gt; &gt;&gt;<br>
&gt;<br>
</div></div>&gt; _______________________________________________<br>
&gt; Xen-devel mailing list<br>
&gt; <a href=3D"mailto:Xen-devel@lists.xen.org" target=3D"_blank">Xen-devel=
@lists.xen.org</a><br>
&gt; <a href=3D"http://lists.xen.org/xen-devel" target=3D"_blank">http://li=
sts.xen.org/xen-devel</a><br>
&gt;<br>
</blockquote></div><br>

--20cf3079ba3eb3ec4904ca90602a--


--===============4941203608672683827==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============4941203608672683827==--


From xen-devel-bounces@lists.xen.org Wed Sep 26 01:04:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Sep 2012 01:04:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGg3A-0000Pv-QJ; Wed, 26 Sep 2012 01:04:28 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mukesh.rathor@oracle.com>) id 1TGg39-0000Po-3Y
	for Xen-devel@lists.xensource.com; Wed, 26 Sep 2012 01:04:27 +0000
Received: from [85.158.139.211:43297] by server-8.bemta-5.messagelabs.com id
	C3/DC-18073-A9452605; Wed, 26 Sep 2012 01:04:26 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-5.tower-206.messagelabs.com!1348621464!19912761!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzY0MTUx\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5599 invoked from network); 26 Sep 2012 01:04:25 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-5.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 26 Sep 2012 01:04:25 -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 q8Q14J2o004325
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 26 Sep 2012 01:04:20 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q8Q14IZj005187
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 26 Sep 2012 01:04:18 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
	q8Q14IkK004900; Tue, 25 Sep 2012 20:04:18 -0500
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 25 Sep 2012 18:04:17 -0700
Date: Tue, 25 Sep 2012 18:04:16 -0700
From: Mukesh Rathor <mukesh.rathor@oracle.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20120925180416.0137d61a@mantra.us.oracle.com>
In-Reply-To: <alpine.DEB.2.02.1209251054140.29232@kaball.uk.xensource.com>
References: <20120921121659.5a723de9@mantra.us.oracle.com>
	<alpine.DEB.2.02.1209241257440.29232@kaball.uk.xensource.com>
	<20120924154335.097d3fb9@mantra.us.oracle.com>
	<alpine.DEB.2.02.1209251054140.29232@kaball.uk.xensource.com>
Organization: Oracle Corporation
X-Mailer: Claws Mail 3.7.6 (GTK+ 2.18.9; x86_64-redhat-linux-gnu)
Mime-Version: 1.0
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: "Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH v1 3/8]: PVH startup changes (enlighten.c)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 25 Sep 2012 11:03:13 +0100
Stefano Stabellini <stefano.stabellini@eu.citrix.com> wrote:

> On Mon, 24 Sep 2012, Mukesh Rathor wrote:
> > On Mon, 24 Sep 2012 13:07:19 +0100
> > Stefano Stabellini <stefano.stabellini@eu.citrix.com> wrote:
> > 
> > > On Fri, 21 Sep 2012, Mukesh Rathor wrote:
> > > > +		return;
> > > > +
> > > >  	if (!xen_feature(XENFEAT_auto_translated_physmap)) {
> > > >  		set_fixmap(FIX_PARAVIRT_BOOTMAP,
> > > >  			   xen_start_info->shared_info);
> > > >
> > > > @@ -1044,6 +1058,10 @@ void xen_setup_shared_info(void)
> > > >  		HYPERVISOR_shared_info =
> > > >  			(struct shared_info
> > > > *)__va(xen_start_info->shared_info); 
> > > > +	/* PVH TBD/FIXME: vcpu info placement in phase 2 */
> > > > +	if (xen_pvh_domain())
> > > > +		return;
> > > 
> > > It seems that if xen_initial_domain we always skip the
> > > initialization while if !xen_initial_domain we only initialize
> > > HYPERVISOR_shared_info. I don't understand why we have this
> > > difference.
> > 
> > The comment in xen_pvh_guest_init() explains it. For domU the
> > library maps the pfn at shared_info, ie, shared_info is pfn. For
> > dom0, it's the mfn. Dom0 then allocates a pfn via extend_brk, and
> > maps the mfn to it. This happens in the commond hvm code,
> > xen_hvm_init_shared_info().
> 
> This difference is really subtle, it would be nice to get rid of it.
> Could Xen allocate a pfn for dom0?

Not easily.

> Otherwise could we have the tools allocate an mfn instead of a pfn?
> In fact looking at xc_dom_x86.c, alloc_magic_pages is explicitly
> having a different behavior for xc_dom_feature_translated guests and
> allocates pfn instead of an mfn. Maybe we could get rid of that
> special case: less code in libxc, a common way of allocating the
> shared_info page for domU and dom0 => win.

Wish it was simple. But for PV and PVH, domU, it's already setup the 
shared page. All we need to do is __va(shared_info). But for HVM domUs 
and PVH dom0, we need to hcall with pfn to get it remapped. Changing the
tool to map pfn, would result in unnecessary hcall for all PV and PVH
domUs. It's only two lines of code, so lets just leave it. I'll make the
comment better.


thx,
Mukesh

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 26 01:04:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Sep 2012 01:04:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGg3A-0000Pv-QJ; Wed, 26 Sep 2012 01:04:28 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mukesh.rathor@oracle.com>) id 1TGg39-0000Po-3Y
	for Xen-devel@lists.xensource.com; Wed, 26 Sep 2012 01:04:27 +0000
Received: from [85.158.139.211:43297] by server-8.bemta-5.messagelabs.com id
	C3/DC-18073-A9452605; Wed, 26 Sep 2012 01:04:26 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-5.tower-206.messagelabs.com!1348621464!19912761!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzY0MTUx\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5599 invoked from network); 26 Sep 2012 01:04:25 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-5.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 26 Sep 2012 01:04:25 -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 q8Q14J2o004325
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 26 Sep 2012 01:04:20 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q8Q14IZj005187
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 26 Sep 2012 01:04:18 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
	q8Q14IkK004900; Tue, 25 Sep 2012 20:04:18 -0500
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 25 Sep 2012 18:04:17 -0700
Date: Tue, 25 Sep 2012 18:04:16 -0700
From: Mukesh Rathor <mukesh.rathor@oracle.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20120925180416.0137d61a@mantra.us.oracle.com>
In-Reply-To: <alpine.DEB.2.02.1209251054140.29232@kaball.uk.xensource.com>
References: <20120921121659.5a723de9@mantra.us.oracle.com>
	<alpine.DEB.2.02.1209241257440.29232@kaball.uk.xensource.com>
	<20120924154335.097d3fb9@mantra.us.oracle.com>
	<alpine.DEB.2.02.1209251054140.29232@kaball.uk.xensource.com>
Organization: Oracle Corporation
X-Mailer: Claws Mail 3.7.6 (GTK+ 2.18.9; x86_64-redhat-linux-gnu)
Mime-Version: 1.0
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: "Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH v1 3/8]: PVH startup changes (enlighten.c)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, 25 Sep 2012 11:03:13 +0100
Stefano Stabellini <stefano.stabellini@eu.citrix.com> wrote:

> On Mon, 24 Sep 2012, Mukesh Rathor wrote:
> > On Mon, 24 Sep 2012 13:07:19 +0100
> > Stefano Stabellini <stefano.stabellini@eu.citrix.com> wrote:
> > 
> > > On Fri, 21 Sep 2012, Mukesh Rathor wrote:
> > > > +		return;
> > > > +
> > > >  	if (!xen_feature(XENFEAT_auto_translated_physmap)) {
> > > >  		set_fixmap(FIX_PARAVIRT_BOOTMAP,
> > > >  			   xen_start_info->shared_info);
> > > >
> > > > @@ -1044,6 +1058,10 @@ void xen_setup_shared_info(void)
> > > >  		HYPERVISOR_shared_info =
> > > >  			(struct shared_info
> > > > *)__va(xen_start_info->shared_info); 
> > > > +	/* PVH TBD/FIXME: vcpu info placement in phase 2 */
> > > > +	if (xen_pvh_domain())
> > > > +		return;
> > > 
> > > It seems that if xen_initial_domain we always skip the
> > > initialization while if !xen_initial_domain we only initialize
> > > HYPERVISOR_shared_info. I don't understand why we have this
> > > difference.
> > 
> > The comment in xen_pvh_guest_init() explains it. For domU the
> > library maps the pfn at shared_info, ie, shared_info is pfn. For
> > dom0, it's the mfn. Dom0 then allocates a pfn via extend_brk, and
> > maps the mfn to it. This happens in the commond hvm code,
> > xen_hvm_init_shared_info().
> 
> This difference is really subtle, it would be nice to get rid of it.
> Could Xen allocate a pfn for dom0?

Not easily.

> Otherwise could we have the tools allocate an mfn instead of a pfn?
> In fact looking at xc_dom_x86.c, alloc_magic_pages is explicitly
> having a different behavior for xc_dom_feature_translated guests and
> allocates pfn instead of an mfn. Maybe we could get rid of that
> special case: less code in libxc, a common way of allocating the
> shared_info page for domU and dom0 => win.

Wish it was simple. But for PV and PVH, domU, it's already setup the 
shared page. All we need to do is __va(shared_info). But for HVM domUs 
and PVH dom0, we need to hcall with pfn to get it remapped. Changing the
tool to map pfn, would result in unnecessary hcall for all PV and PVH
domUs. It's only two lines of code, so lets just leave it. I'll make the
comment better.


thx,
Mukesh

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 26 01:22:46 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Sep 2012 01: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 1TGgKU-0000eo-Ea; Wed, 26 Sep 2012 01:22:22 +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 1TGgKT-0000ej-1a
	for Xen-devel@lists.xensource.com; Wed, 26 Sep 2012 01:22:21 +0000
Received: from [85.158.139.83:34109] by server-5.bemta-5.messagelabs.com id
	A6/28-21075-CC852605; Wed, 26 Sep 2012 01:22:20 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1348622538!24904019!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDc3NDE3Nw==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20773 invoked from network); 26 Sep 2012 01:22:19 -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; 26 Sep 2012 01:22:19 -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 q8Q1MCNL007694
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 26 Sep 2012 01:22:12 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
	q8Q1MAXp009885
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 26 Sep 2012 01:22:11 GMT
Received: from abhmt101.oracle.com (abhmt101.oracle.com [141.146.116.53])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q8Q1M8Yq018879; Tue, 25 Sep 2012 20:22:08 -0500
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 25 Sep 2012 18:22:07 -0700
Date: Tue, 25 Sep 2012 18:22:06 -0700
From: Mukesh Rathor <mukesh.rathor@oracle.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20120925182206.1d9c7b52@mantra.us.oracle.com>
In-Reply-To: <alpine.DEB.2.02.1209241423450.29232@kaball.uk.xensource.com>
References: <20120921121928.1c5765bc@mantra.us.oracle.com>
	<alpine.DEB.2.02.1209241423450.29232@kaball.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>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH v1 6/8]: PVH ballooning and grant changes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 24 Sep 2012 14:55:06 +0100
Stefano Stabellini <stefano.stabellini@eu.citrix.com> wrote:

> On Fri, 21 Sep 2012, Mukesh Rathor wrote:
> > ---
> >  drivers/xen/balloon.c     |   35
> > ++++++++++++++++++++++++++++------- drivers/xen/gntdev.c      |
> > 3 ++- drivers/xen/grant-table.c |   25 +++++++++++++++++++++----
> >  3 files changed, 51 insertions(+), 12 deletions(-)
> > 
> > diff --git a/drivers/xen/balloon.c b/drivers/xen/balloon.c
> > index 31ab82f..85a6917 100644
> > --- a/drivers/xen/balloon.c
> > +++ b/drivers/xen/balloon.c
> > @@ -358,10 +358,21 @@ static enum bp_state
> > increase_reservation(unsigned long nr_pages)
> > BUG_ON(!xen_feature(XENFEAT_auto_translated_physmap) &&
> > phys_to_machine_mapping_valid(pfn)); 
> > -		set_phys_to_machine(pfn, frame_list[i]);
> > +		if (xen_pv_domain() && 
> > +		    xen_feature(XENFEAT_auto_translated_physmap)) {
> > +			/* PVH: we just need to update native page
> > table */
> > +			pte_t *ptep;
> > +			unsigned int level;
> > +			void *addr = __va(pfn << PAGE_SHIFT);
> > +			ptep = lookup_address((unsigned long)addr,
> > &level);
> > +			set_pte(ptep, pfn_pte(pfn, PAGE_KERNEL));
> > +		} else
> > +			set_phys_to_machine(pfn, frame_list[i]);
> 
> 
> 
> >  		/* Link back into the page tables if not highmem.
> > */
> > -		if (xen_pv_domain() && !PageHighMem(page)) {
> > +		if (xen_pv_domain() && !PageHighMem(page) && 
> > +		    !xen_feature(XENFEAT_auto_translated_physmap))
> > { +
> >  			int ret;
> >  			ret = HYPERVISOR_update_va_mapping(
> >  				(unsigned long)__va(pfn <<
> > PAGE_SHIFT), @@ -418,12 +429,21 @@ static enum bp_state
> > decrease_reservation(unsigned long nr_pages, gfp_t gfp)
> > scrub_page(page); 
> >  		if (xen_pv_domain() && !PageHighMem(page)) {
> > -			ret = HYPERVISOR_update_va_mapping(
> > -				(unsigned long)__va(pfn <<
> > PAGE_SHIFT),
> > -				__pte_ma(0), 0);
> > -			BUG_ON(ret);
> > +			if
> > (xen_feature(XENFEAT_auto_translated_physmap)) {
> > +				unsigned int level;
> > +				pte_t *ptep;
> > +				void *addr = __va(pfn <<
> > PAGE_SHIFT);
> > +				ptep = lookup_address((unsigned
> > long)addr, 
> > +							&level);
> > +				set_pte(ptep, __pte(0));
> > +
> > +			} else {
> > +				ret = HYPERVISOR_update_va_mapping(
> > +					(unsigned long)__va(pfn <<
> > PAGE_SHIFT),
> > +					__pte_ma(0), 0);
> > +				BUG_ON(ret);
> > +			}
> >  		}
> > -
> >  	}
> >  
> >  	/* Ensure that ballooned highmem pages don't have kmaps. */
> > @@ -433,6 +453,7 @@ static enum bp_state
> > decrease_reservation(unsigned long nr_pages, gfp_t gfp) /* No more
> > mappings: invalidate P2M and add to balloon. */ for (i = 0; i <
> > nr_pages; i++) { pfn = mfn_to_pfn(frame_list[i]);
> > +		/* PVH note: following will noop for auto
> > translated */ __set_phys_to_machine(pfn, INVALID_P2M_ENTRY);
> >  		balloon_append(pfn_to_page(pfn));
> >  	}
> 
> Maybe we need a function "update_mapping" internal to balloon.c that
> would be set to HYPERVISOR_update_va_mapping for pv guests, set_pte
> for pvh guests and nothing for pv on hvm guests.
> 
> Speaking of which, why do pvh guests need a set_pte while pv on hvm
> guests don't? I would think that their behaviour should be the same
> regarding ballooning.

you are right, I can remove it. Not sure why I've it there. Cant
recall.




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 26 01:22:46 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Sep 2012 01: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 1TGgKU-0000eo-Ea; Wed, 26 Sep 2012 01:22:22 +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 1TGgKT-0000ej-1a
	for Xen-devel@lists.xensource.com; Wed, 26 Sep 2012 01:22:21 +0000
Received: from [85.158.139.83:34109] by server-5.bemta-5.messagelabs.com id
	A6/28-21075-CC852605; Wed, 26 Sep 2012 01:22:20 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1348622538!24904019!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDc3NDE3Nw==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20773 invoked from network); 26 Sep 2012 01:22:19 -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; 26 Sep 2012 01:22:19 -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 q8Q1MCNL007694
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 26 Sep 2012 01:22:12 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
	q8Q1MAXp009885
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 26 Sep 2012 01:22:11 GMT
Received: from abhmt101.oracle.com (abhmt101.oracle.com [141.146.116.53])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q8Q1M8Yq018879; Tue, 25 Sep 2012 20:22:08 -0500
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 25 Sep 2012 18:22:07 -0700
Date: Tue, 25 Sep 2012 18:22:06 -0700
From: Mukesh Rathor <mukesh.rathor@oracle.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20120925182206.1d9c7b52@mantra.us.oracle.com>
In-Reply-To: <alpine.DEB.2.02.1209241423450.29232@kaball.uk.xensource.com>
References: <20120921121928.1c5765bc@mantra.us.oracle.com>
	<alpine.DEB.2.02.1209241423450.29232@kaball.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>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH v1 6/8]: PVH ballooning and grant changes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 24 Sep 2012 14:55:06 +0100
Stefano Stabellini <stefano.stabellini@eu.citrix.com> wrote:

> On Fri, 21 Sep 2012, Mukesh Rathor wrote:
> > ---
> >  drivers/xen/balloon.c     |   35
> > ++++++++++++++++++++++++++++------- drivers/xen/gntdev.c      |
> > 3 ++- drivers/xen/grant-table.c |   25 +++++++++++++++++++++----
> >  3 files changed, 51 insertions(+), 12 deletions(-)
> > 
> > diff --git a/drivers/xen/balloon.c b/drivers/xen/balloon.c
> > index 31ab82f..85a6917 100644
> > --- a/drivers/xen/balloon.c
> > +++ b/drivers/xen/balloon.c
> > @@ -358,10 +358,21 @@ static enum bp_state
> > increase_reservation(unsigned long nr_pages)
> > BUG_ON(!xen_feature(XENFEAT_auto_translated_physmap) &&
> > phys_to_machine_mapping_valid(pfn)); 
> > -		set_phys_to_machine(pfn, frame_list[i]);
> > +		if (xen_pv_domain() && 
> > +		    xen_feature(XENFEAT_auto_translated_physmap)) {
> > +			/* PVH: we just need to update native page
> > table */
> > +			pte_t *ptep;
> > +			unsigned int level;
> > +			void *addr = __va(pfn << PAGE_SHIFT);
> > +			ptep = lookup_address((unsigned long)addr,
> > &level);
> > +			set_pte(ptep, pfn_pte(pfn, PAGE_KERNEL));
> > +		} else
> > +			set_phys_to_machine(pfn, frame_list[i]);
> 
> 
> 
> >  		/* Link back into the page tables if not highmem.
> > */
> > -		if (xen_pv_domain() && !PageHighMem(page)) {
> > +		if (xen_pv_domain() && !PageHighMem(page) && 
> > +		    !xen_feature(XENFEAT_auto_translated_physmap))
> > { +
> >  			int ret;
> >  			ret = HYPERVISOR_update_va_mapping(
> >  				(unsigned long)__va(pfn <<
> > PAGE_SHIFT), @@ -418,12 +429,21 @@ static enum bp_state
> > decrease_reservation(unsigned long nr_pages, gfp_t gfp)
> > scrub_page(page); 
> >  		if (xen_pv_domain() && !PageHighMem(page)) {
> > -			ret = HYPERVISOR_update_va_mapping(
> > -				(unsigned long)__va(pfn <<
> > PAGE_SHIFT),
> > -				__pte_ma(0), 0);
> > -			BUG_ON(ret);
> > +			if
> > (xen_feature(XENFEAT_auto_translated_physmap)) {
> > +				unsigned int level;
> > +				pte_t *ptep;
> > +				void *addr = __va(pfn <<
> > PAGE_SHIFT);
> > +				ptep = lookup_address((unsigned
> > long)addr, 
> > +							&level);
> > +				set_pte(ptep, __pte(0));
> > +
> > +			} else {
> > +				ret = HYPERVISOR_update_va_mapping(
> > +					(unsigned long)__va(pfn <<
> > PAGE_SHIFT),
> > +					__pte_ma(0), 0);
> > +				BUG_ON(ret);
> > +			}
> >  		}
> > -
> >  	}
> >  
> >  	/* Ensure that ballooned highmem pages don't have kmaps. */
> > @@ -433,6 +453,7 @@ static enum bp_state
> > decrease_reservation(unsigned long nr_pages, gfp_t gfp) /* No more
> > mappings: invalidate P2M and add to balloon. */ for (i = 0; i <
> > nr_pages; i++) { pfn = mfn_to_pfn(frame_list[i]);
> > +		/* PVH note: following will noop for auto
> > translated */ __set_phys_to_machine(pfn, INVALID_P2M_ENTRY);
> >  		balloon_append(pfn_to_page(pfn));
> >  	}
> 
> Maybe we need a function "update_mapping" internal to balloon.c that
> would be set to HYPERVISOR_update_va_mapping for pv guests, set_pte
> for pvh guests and nothing for pv on hvm guests.
> 
> Speaking of which, why do pvh guests need a set_pte while pv on hvm
> guests don't? I would think that their behaviour should be the same
> regarding ballooning.

you are right, I can remove it. Not sure why I've it there. Cant
recall.




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 26 01:29:20 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Sep 2012 01:29:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGgQu-0000ne-Au; Wed, 26 Sep 2012 01:29:00 +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 1TGgQs-0000nZ-Tg
	for Xen-devel@lists.xensource.com; Wed, 26 Sep 2012 01:28:59 +0000
Received: from [85.158.138.51:20917] by server-9.bemta-3.messagelabs.com id
	37/FA-15390-A5A52605; Wed, 26 Sep 2012 01:28:58 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1348622936!25634203!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzY0MTUx\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12824 invoked from network); 26 Sep 2012 01:28:57 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-14.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 26 Sep 2012 01:28: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 q8Q1Sp0r020729
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 26 Sep 2012 01:28:52 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
	q8Q1SnCI012400
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 26 Sep 2012 01:28:51 GMT
Received: from abhmt114.oracle.com (abhmt114.oracle.com [141.146.116.66])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q8Q1SnAv021850; Tue, 25 Sep 2012 20:28:49 -0500
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 25 Sep 2012 18:28:49 -0700
Date: Tue, 25 Sep 2012 18:28:48 -0700
From: Mukesh Rathor <mukesh.rathor@oracle.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20120925182848.52978702@mantra.us.oracle.com>
In-Reply-To: <alpine.DEB.2.02.1209241504410.29232@kaball.uk.xensource.com>
References: <20120921122123.33489ce1@mantra.us.oracle.com>
	<alpine.DEB.2.02.1209241504410.29232@kaball.uk.xensource.com>
Organization: Oracle Corporation
X-Mailer: Claws Mail 3.7.6 (GTK+ 2.18.9; x86_64-redhat-linux-gnu)
Mime-Version: 1.0
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: "Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH v1 7/8]: PVH privcmd changes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 24 Sep 2012 15:24:16 +0100
Stefano Stabellini <stefano.stabellini@eu.citrix.com> wrote:

> On Fri, 21 Sep 2012, Mukesh Rathor wrote:
> > ---
> >  drivers/xen/privcmd.c |   77
> > ++++++++++++++++++++++++++++++++++++++++++++---- 1 files changed,
> > 70 insertions(+), 7 deletions(-)
> > 
> > diff --git a/drivers/xen/privcmd.c b/drivers/xen/privcmd.c
> > index ccee0f1..195d89f 100644
> > -				       st->vma->vm_page_prot,
> > st->domain) < 0) {
> > +	if (xen_remap_domain_mfn_range(vma, st->va & PAGE_MASK,
> > *mfnp, 1,
> > +				       vma->vm_page_prot,
> > st->domain, 
> > +				       pvhp) < 0) {
> >  		*mfnp |= 0xf0000000U;
> >  		st->err++;
> >  	}
> 
> I don't like that a parameter like "xen_pvh_pfn_info" has been added
> to a generic arch-agnostic function like xen_remap_domain_mfn_range.
> 
> If you need to pass more parameters to xen_remap_domain_mfn_range, it
> should be done in a cross-architecture way. In fact, keep in mind that
> privcmd.c compiles on ARM (and IA64?) as well.
> 
> I think that in this particular case you are using pvh to actually
> specify auto_translate_physmap, am I correct?
> Maybe we just need to rename xen_pvh_pfn_info to xen_xlat_pfn_info.

Ok, I renamed it. And for the API, as I mentioned in prev email,
I changed xen_remap_domain_mfn_range to have last parameter be 
called void *arch_specific_info.

> 
> > @@ -274,6 +284,40 @@ static int mmap_return_errors(void *data, void
> > +		return -ENOMEM;
> > +	}
> > +
> > +	rc = alloc_xenballooned_pages(numpgs, pvhp->pi_paga, 0);
> > +	if (rc != 0) {
> > +		pr_warn("%s Could not alloc %d pfns rc:%d\n",
> > __FUNCTION__, 
> > +			numpgs, rc);
> > +		kfree(pvhp->pi_paga);
> > +		kfree(pvhp);
> > +		return -ENOMEM;
> > +	}
> > +	pvhp->pi_num_pgs = numpgs;
> > +	BUG_ON(vma->vm_private_data != (void *)1);
> 
> what?

See privcmd_enforce_singleshot_mapping().

> >  
> > +	if (xen_pv_domain() &&
> > xen_feature(XENFEAT_auto_translated_physmap)) {
> > +		if ((ret=pvh_privcmd_resv_pfns(vma, m.num))) {
> 
> I would change this into:
> 
>     if ((ret = pvh_privcmd_resv_pfns(vma, m.num)) < 0) {
> 

OK.


> > +	count = xen_unmap_domain_mfn_range(vma, pvhp);
> > +	while (count--)
> > +		free_xenballooned_pages(1, &pvhp->pi_paga[count]);
> > +	kfree(pvhp->pi_paga);
> > +	kfree(pvhp);
> 
> So xen_remap_domain_mfn_range adds the mappings to the vma, while
> xen_unmap_domain_mfn_range does not remove them. I take that somehow
> this is done by the generic Linux code that calls into this function?

Correct. The kernel MMU seems to do all cleanup before calling
privcmd_close.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 26 01:29:20 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Sep 2012 01:29:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGgQu-0000ne-Au; Wed, 26 Sep 2012 01:29:00 +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 1TGgQs-0000nZ-Tg
	for Xen-devel@lists.xensource.com; Wed, 26 Sep 2012 01:28:59 +0000
Received: from [85.158.138.51:20917] by server-9.bemta-3.messagelabs.com id
	37/FA-15390-A5A52605; Wed, 26 Sep 2012 01:28:58 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1348622936!25634203!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzY0MTUx\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12824 invoked from network); 26 Sep 2012 01:28:57 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-14.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 26 Sep 2012 01:28: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 q8Q1Sp0r020729
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 26 Sep 2012 01:28:52 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
	q8Q1SnCI012400
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 26 Sep 2012 01:28:51 GMT
Received: from abhmt114.oracle.com (abhmt114.oracle.com [141.146.116.66])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q8Q1SnAv021850; Tue, 25 Sep 2012 20:28:49 -0500
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 25 Sep 2012 18:28:49 -0700
Date: Tue, 25 Sep 2012 18:28:48 -0700
From: Mukesh Rathor <mukesh.rathor@oracle.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20120925182848.52978702@mantra.us.oracle.com>
In-Reply-To: <alpine.DEB.2.02.1209241504410.29232@kaball.uk.xensource.com>
References: <20120921122123.33489ce1@mantra.us.oracle.com>
	<alpine.DEB.2.02.1209241504410.29232@kaball.uk.xensource.com>
Organization: Oracle Corporation
X-Mailer: Claws Mail 3.7.6 (GTK+ 2.18.9; x86_64-redhat-linux-gnu)
Mime-Version: 1.0
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: "Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH v1 7/8]: PVH privcmd changes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, 24 Sep 2012 15:24:16 +0100
Stefano Stabellini <stefano.stabellini@eu.citrix.com> wrote:

> On Fri, 21 Sep 2012, Mukesh Rathor wrote:
> > ---
> >  drivers/xen/privcmd.c |   77
> > ++++++++++++++++++++++++++++++++++++++++++++---- 1 files changed,
> > 70 insertions(+), 7 deletions(-)
> > 
> > diff --git a/drivers/xen/privcmd.c b/drivers/xen/privcmd.c
> > index ccee0f1..195d89f 100644
> > -				       st->vma->vm_page_prot,
> > st->domain) < 0) {
> > +	if (xen_remap_domain_mfn_range(vma, st->va & PAGE_MASK,
> > *mfnp, 1,
> > +				       vma->vm_page_prot,
> > st->domain, 
> > +				       pvhp) < 0) {
> >  		*mfnp |= 0xf0000000U;
> >  		st->err++;
> >  	}
> 
> I don't like that a parameter like "xen_pvh_pfn_info" has been added
> to a generic arch-agnostic function like xen_remap_domain_mfn_range.
> 
> If you need to pass more parameters to xen_remap_domain_mfn_range, it
> should be done in a cross-architecture way. In fact, keep in mind that
> privcmd.c compiles on ARM (and IA64?) as well.
> 
> I think that in this particular case you are using pvh to actually
> specify auto_translate_physmap, am I correct?
> Maybe we just need to rename xen_pvh_pfn_info to xen_xlat_pfn_info.

Ok, I renamed it. And for the API, as I mentioned in prev email,
I changed xen_remap_domain_mfn_range to have last parameter be 
called void *arch_specific_info.

> 
> > @@ -274,6 +284,40 @@ static int mmap_return_errors(void *data, void
> > +		return -ENOMEM;
> > +	}
> > +
> > +	rc = alloc_xenballooned_pages(numpgs, pvhp->pi_paga, 0);
> > +	if (rc != 0) {
> > +		pr_warn("%s Could not alloc %d pfns rc:%d\n",
> > __FUNCTION__, 
> > +			numpgs, rc);
> > +		kfree(pvhp->pi_paga);
> > +		kfree(pvhp);
> > +		return -ENOMEM;
> > +	}
> > +	pvhp->pi_num_pgs = numpgs;
> > +	BUG_ON(vma->vm_private_data != (void *)1);
> 
> what?

See privcmd_enforce_singleshot_mapping().

> >  
> > +	if (xen_pv_domain() &&
> > xen_feature(XENFEAT_auto_translated_physmap)) {
> > +		if ((ret=pvh_privcmd_resv_pfns(vma, m.num))) {
> 
> I would change this into:
> 
>     if ((ret = pvh_privcmd_resv_pfns(vma, m.num)) < 0) {
> 

OK.


> > +	count = xen_unmap_domain_mfn_range(vma, pvhp);
> > +	while (count--)
> > +		free_xenballooned_pages(1, &pvhp->pi_paga[count]);
> > +	kfree(pvhp->pi_paga);
> > +	kfree(pvhp);
> 
> So xen_remap_domain_mfn_range adds the mappings to the vma, while
> xen_unmap_domain_mfn_range does not remove them. I take that somehow
> this is done by the generic Linux code that calls into this function?

Correct. The kernel MMU seems to do all cleanup before calling
privcmd_close.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 26 02:07:49 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Sep 2012 02: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 1TGh25-0001Oy-JH; Wed, 26 Sep 2012 02:07:25 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jfehlig@suse.com>) id 1TGh23-0001Ot-Oy
	for xen-devel@lists.xen.org; Wed, 26 Sep 2012 02:07:23 +0000
Received: from [85.158.139.83:9535] by server-11.bemta-5.messagelabs.com id
	06/60-13866-A5362605; Wed, 26 Sep 2012 02:07:22 +0000
X-Env-Sender: jfehlig@suse.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1348625241!27596979!1
X-Originating-IP: [137.65.248.97]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26936 invoked from network); 26 Sep 2012 02:07:21 -0000
Received: from novprvoes0314.provo.novell.com (HELO mail.novell.com)
	(137.65.248.97) by server-4.tower-182.messagelabs.com with SMTP;
	26 Sep 2012 02:07:21 -0000
Received: from [137.65.223.13] ([::ffff:137.65.223.13])
	by mail.novell.com with ESMTP; Tue, 25 Sep 2012 20:07:18 -0600
Message-ID: <50626355.7080402@suse.com>
Date: Tue, 25 Sep 2012 20:07:17 -0600
From: Jim Fehlig <jfehlig@suse.com>
User-Agent: Thunderbird 2.0.0.18 (X11/20081112)
MIME-Version: 1.0
To: George Dunlap <george.dunlap@eu.citrix.com>
References: <CAFLBxZYtmJ_bKFb90r45=C4Pq1-oe5Fy=eygSsQf4BcGj3EqGA@mail.gmail.com>
	<201209191918.35305.hahn@univention.de>
	<CAFLBxZZko72sMVPr9LEyea7E-tNx74qCvRoxqPZ-eWbvhvctgQ@mail.gmail.com>
	<201209201340.52218.hahn@univention.de>
	<505B88A1.1070701@suse.com> <505C4A82.2040305@eu.citrix.com>
In-Reply-To: <505C4A82.2040305@eu.citrix.com>
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.3 development 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

George Dunlap wrote:
> On 20/09/12 22:20, Jim Fehlig wrote:
>> Chun Yan Liu was working on a patch to implement migration in the
>> libvirt libxl
>> driver, but she wasn't able to finish tidying the patch before
>> departing on
>> maternity leave.  She recently returned to work and I'd expect a
>> refreshed patch
>> soon - after working through her backlog.
>>
>> But why is libvirt integration listed as a Xen 4.3 feature?  AFAIK,
>> all of this
>> work is in libvirt and really doesn't have much to do with the
>> release of 4.3.
> For one, as Ian said, we want xl/libxl to be the default toolstack in
> 4.3; as soon as possible we want to remove xend.

Good :).

>
> But from a broader perspective, the idea is for the Xen.org community
> to be thinking strategically about the success of the Xen project as a
> whole.  Things like distro support and libvirt integration are
> absolutely critical to Xen's success in the open-source ecosystem.  So
> while we don't have to do everything ourselves, we want to think about
> what things need to be done, track them to make sure that *someone*
> does them; and be prepared to pick them up ourselves if necessary. 
> And it just makes more sense to track everything on one list.
>
> Does that make sense?

Yes, it does.  I'm actually quite happy to hear this statement of
support for the broader ecosystem!

WRT libvirt support for libxl in Xen >= 4.2, SUSE will be contributing
some work.  Just today I had to disable the driver in our Factory
libvirt builds where we now have Xen 4.2.  This hack can't last for long.

Regards,
Jim


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 26 02:07:49 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Sep 2012 02: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 1TGh25-0001Oy-JH; Wed, 26 Sep 2012 02:07:25 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jfehlig@suse.com>) id 1TGh23-0001Ot-Oy
	for xen-devel@lists.xen.org; Wed, 26 Sep 2012 02:07:23 +0000
Received: from [85.158.139.83:9535] by server-11.bemta-5.messagelabs.com id
	06/60-13866-A5362605; Wed, 26 Sep 2012 02:07:22 +0000
X-Env-Sender: jfehlig@suse.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1348625241!27596979!1
X-Originating-IP: [137.65.248.97]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26936 invoked from network); 26 Sep 2012 02:07:21 -0000
Received: from novprvoes0314.provo.novell.com (HELO mail.novell.com)
	(137.65.248.97) by server-4.tower-182.messagelabs.com with SMTP;
	26 Sep 2012 02:07:21 -0000
Received: from [137.65.223.13] ([::ffff:137.65.223.13])
	by mail.novell.com with ESMTP; Tue, 25 Sep 2012 20:07:18 -0600
Message-ID: <50626355.7080402@suse.com>
Date: Tue, 25 Sep 2012 20:07:17 -0600
From: Jim Fehlig <jfehlig@suse.com>
User-Agent: Thunderbird 2.0.0.18 (X11/20081112)
MIME-Version: 1.0
To: George Dunlap <george.dunlap@eu.citrix.com>
References: <CAFLBxZYtmJ_bKFb90r45=C4Pq1-oe5Fy=eygSsQf4BcGj3EqGA@mail.gmail.com>
	<201209191918.35305.hahn@univention.de>
	<CAFLBxZZko72sMVPr9LEyea7E-tNx74qCvRoxqPZ-eWbvhvctgQ@mail.gmail.com>
	<201209201340.52218.hahn@univention.de>
	<505B88A1.1070701@suse.com> <505C4A82.2040305@eu.citrix.com>
In-Reply-To: <505C4A82.2040305@eu.citrix.com>
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.3 development 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

George Dunlap wrote:
> On 20/09/12 22:20, Jim Fehlig wrote:
>> Chun Yan Liu was working on a patch to implement migration in the
>> libvirt libxl
>> driver, but she wasn't able to finish tidying the patch before
>> departing on
>> maternity leave.  She recently returned to work and I'd expect a
>> refreshed patch
>> soon - after working through her backlog.
>>
>> But why is libvirt integration listed as a Xen 4.3 feature?  AFAIK,
>> all of this
>> work is in libvirt and really doesn't have much to do with the
>> release of 4.3.
> For one, as Ian said, we want xl/libxl to be the default toolstack in
> 4.3; as soon as possible we want to remove xend.

Good :).

>
> But from a broader perspective, the idea is for the Xen.org community
> to be thinking strategically about the success of the Xen project as a
> whole.  Things like distro support and libvirt integration are
> absolutely critical to Xen's success in the open-source ecosystem.  So
> while we don't have to do everything ourselves, we want to think about
> what things need to be done, track them to make sure that *someone*
> does them; and be prepared to pick them up ourselves if necessary. 
> And it just makes more sense to track everything on one list.
>
> Does that make sense?

Yes, it does.  I'm actually quite happy to hear this statement of
support for the broader ecosystem!

WRT libvirt support for libxl in Xen >= 4.2, SUSE will be contributing
some work.  Just today I had to disable the driver in our Factory
libvirt builds where we now have Xen 4.2.  This hack can't last for long.

Regards,
Jim


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 26 02:55:33 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Sep 2012 02:55: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 1TGhmH-0001eL-Fi; Wed, 26 Sep 2012 02:55: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 1TGhmF-0001eG-N4
	for xen-devel@lists.xensource.com; Wed, 26 Sep 2012 02:55:07 +0000
Received: from [85.158.143.35:22472] by server-1.bemta-4.messagelabs.com id
	61/E1-05684-A8E62605; Wed, 26 Sep 2012 02:55:06 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1348628105!13064729!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTEzMTI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13256 invoked from network); 26 Sep 2012 02:55: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;
	26 Sep 2012 02:55:06 -0000
X-IronPort-AV: E=Sophos;i="4.80,487,1344211200"; d="scan'208";a="14763776"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Sep 2012 02:55: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.279.1; Wed, 26 Sep 2012 03:55: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 1TGhmC-00081N-Vw;
	Wed, 26 Sep 2012 02:55:05 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1TGhmC-00043A-L7;
	Wed, 26 Sep 2012 03:55:04 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-13867-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 26 Sep 2012 03:55:04 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.1-testing test] 13867: 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 13867 xen-4.1-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13867/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-pcipt-intel  8 debian-fixup                fail like 13820
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 13820

Tests which did not succeed, but are not blocking:
 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-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 13 guest-stop               fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-i386-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-win          16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 13 guest-stop             fail never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-i386-i386-xl-qemuu-winxpsp3 13 guest-stop                 fail never pass

version targeted for testing:
 xen                  fb0561ba7d9e
baseline version:
 xen                  6a17d5f11d66

------------------------------------------------------------
People who touched revisions under test:
  Dan Magenheimer <dan.magenheimer@oracle.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Jonathan Tripathy <jonnyt@abpni.co.uk>
  Keir Fraser <keir@xen.org>
  Zhenzhong Duan <zhenzhong.duan@oracle.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


Pushing revision :

+ branch=xen-4.1-testing
+ revision=fb0561ba7d9e
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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 fb0561ba7d9e
+ branch=xen-4.1-testing
+ revision=fb0561ba7d9e
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-4.1-testing
+ '[' xxen = xlinux ']'
+ linuxbranch=linux
+ : master
+ : tested/2.6.39.x
+ . ap-common
++ : xen@xenbits.xensource.com
++ : http://xenbits.xen.org/hg/staging/xen-4.1-testing.hg
++ : git://xenbits.xen.org/staging/qemu-xen-4.1-testing.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : xen@xenbits.xensource.com:git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.xen-4.1-testing
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-4.1-testing.git
++ : daily-cron.xen-4.1-testing
+ TREE_LINUX=xen@xenbits.xensource.com:git/linux-pvops.git
+ TREE_QEMU_UPSTREAM=xen@xenbits.xensource.com:git/qemu-upstream-4.1-testing.git
+ info_linux_tree xen-4.1-testing
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/xen-4.1-testing.hg
+ hg push -r fb0561ba7d9e 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 12 changesets with 17 changes to 3 files

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 26 02:55:33 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Sep 2012 02:55: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 1TGhmH-0001eL-Fi; Wed, 26 Sep 2012 02:55: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 1TGhmF-0001eG-N4
	for xen-devel@lists.xensource.com; Wed, 26 Sep 2012 02:55:07 +0000
Received: from [85.158.143.35:22472] by server-1.bemta-4.messagelabs.com id
	61/E1-05684-A8E62605; Wed, 26 Sep 2012 02:55:06 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1348628105!13064729!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTEzMTI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13256 invoked from network); 26 Sep 2012 02:55: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;
	26 Sep 2012 02:55:06 -0000
X-IronPort-AV: E=Sophos;i="4.80,487,1344211200"; d="scan'208";a="14763776"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Sep 2012 02:55: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.279.1; Wed, 26 Sep 2012 03:55: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 1TGhmC-00081N-Vw;
	Wed, 26 Sep 2012 02:55:05 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1TGhmC-00043A-L7;
	Wed, 26 Sep 2012 03:55:04 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-13867-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 26 Sep 2012 03:55:04 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.1-testing test] 13867: 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 13867 xen-4.1-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13867/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-pcipt-intel  8 debian-fixup                fail like 13820
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 13820

Tests which did not succeed, but are not blocking:
 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-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 13 guest-stop               fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-i386-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-win          16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 13 guest-stop             fail never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-i386-i386-xl-qemuu-winxpsp3 13 guest-stop                 fail never pass

version targeted for testing:
 xen                  fb0561ba7d9e
baseline version:
 xen                  6a17d5f11d66

------------------------------------------------------------
People who touched revisions under test:
  Dan Magenheimer <dan.magenheimer@oracle.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Jonathan Tripathy <jonnyt@abpni.co.uk>
  Keir Fraser <keir@xen.org>
  Zhenzhong Duan <zhenzhong.duan@oracle.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


Pushing revision :

+ branch=xen-4.1-testing
+ revision=fb0561ba7d9e
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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 fb0561ba7d9e
+ branch=xen-4.1-testing
+ revision=fb0561ba7d9e
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-4.1-testing
+ '[' xxen = xlinux ']'
+ linuxbranch=linux
+ : master
+ : tested/2.6.39.x
+ . ap-common
++ : xen@xenbits.xensource.com
++ : http://xenbits.xen.org/hg/staging/xen-4.1-testing.hg
++ : git://xenbits.xen.org/staging/qemu-xen-4.1-testing.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : xen@xenbits.xensource.com:git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.xen-4.1-testing
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-4.1-testing.git
++ : daily-cron.xen-4.1-testing
+ TREE_LINUX=xen@xenbits.xensource.com:git/linux-pvops.git
+ TREE_QEMU_UPSTREAM=xen@xenbits.xensource.com:git/qemu-upstream-4.1-testing.git
+ info_linux_tree xen-4.1-testing
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/xen-4.1-testing.hg
+ hg push -r fb0561ba7d9e 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 12 changesets with 17 changes to 3 files

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 26 03:13:01 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Sep 2012 03:13:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGi35-0002Gq-Ss; Wed, 26 Sep 2012 03:12:31 +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 1TGi34-0002Gl-Br
	for xen-devel@lists.xensource.com; Wed, 26 Sep 2012 03:12:30 +0000
Received: from [85.158.143.35:47594] by server-3.bemta-4.messagelabs.com id
	B8/11-10986-D9272605; Wed, 26 Sep 2012 03:12:29 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1348629148!4136109!1
X-Originating-IP: [134.134.136.24]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjQgPT4gMzQ3OTA1\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21799 invoked from network); 26 Sep 2012 03:12:29 -0000
Received: from mga09.intel.com (HELO mga09.intel.com) (134.134.136.24)
	by server-5.tower-21.messagelabs.com with SMTP;
	26 Sep 2012 03:12:29 -0000
Received: from orsmga001.jf.intel.com ([10.7.209.18])
	by orsmga102.jf.intel.com with ESMTP; 25 Sep 2012 20:12:13 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.80,487,1344236400"; d="scan'208";a="197716115"
Received: from fmsmsx107.amr.corp.intel.com ([10.19.9.54])
	by orsmga001.jf.intel.com with ESMTP; 25 Sep 2012 20:12:27 -0700
Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by
	FMSMSX107.amr.corp.intel.com (10.19.9.54) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Tue, 25 Sep 2012 20:12:26 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.239]) by
	SHSMSX102.ccr.corp.intel.com ([169.254.2.92]) with mapi id
	14.01.0355.002; Wed, 26 Sep 2012 11:11:42 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: Christoph Egger <Christoph.Egger@amd.com>, Jan Beulich <JBeulich@suse.com>
Thread-Topic: [PATCH 6] X86/MCE: update vMCE injection for AMD
Thread-Index: AQHNmxR4bAubMQI3SAyq+zkwzNAc0peb8t4A
Date: Wed, 26 Sep 2012 03:11:41 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC829233533AA6E@SHSMSX101.ccr.corp.intel.com>
References: <DE8DF0795D48FD4CA783C40EC8292335339547@SHSMSX101.ccr.corp.intel.com>
	<506173FB.8070603@amd.com>
	<5061A833020000780009DA1A@nat28.tlf.novell.com>
	<50619B61.2030609@amd.com>
In-Reply-To: <50619B61.2030609@amd.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"keir@xen.org" <keir@xen.org>,
	"Ian.Campbell@citrix.com" <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH 6] X86/MCE: update vMCE injection for AMD
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Christoph Egger wrote:
> On 09/25/12 12:48, Jan Beulich wrote:
> 
>>>>> On 25.09.12 at 11:06, Christoph Egger <Christoph.Egger@amd.com>
>>>>> wrote: 
>>> On 09/25/12 07:00, Liu, Jinsong wrote:
>>> 
>>>> X86/MCE: update vMCE injection for AMD
>>>> 
>>>> For Intel MCE, it broadcasts vMCE to all vcpus. For AMD MCE, it
>>>> injects vMCE only to vcpu0. This patch update inject_vmce for AMD.
>>>> 
>>>> Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>
>>>> Suggested_by: Christoph Egger <Christoph.Egger@amd.com>
>>> 
>>> 
>>> Acked-by: Christoph Egger <Christoph.Egger@amd.com>
>> 
>> Are you sure (see below)?
> 
> Yes, see below.
> 
>>>> diff -r a6d12a1bc758 xen/arch/x86/cpu/mcheck/mce.h
>>>> --- a/xen/arch/x86/cpu/mcheck/mce.h	Thu Sep 20 00:03:25 2012 +0800
>>>> +++ b/xen/arch/x86/cpu/mcheck/mce.h	Tue Sep 25 19:52:20 2012 +0800
>>>> @@ -168,7 +168,7 @@ 
>>>> 
>>>>  int fill_vmsr_data(struct mcinfo_bank *mc_bank, struct domain *d,
>>>> uint64_t gstatus); -int inject_vmce(struct domain *d);
>>>> +int inject_vmce(struct domain *d, bool_t vmce_broadcast);
>>>> 
>>>>  static inline int mce_vendor_bank_msr(const struct vcpu *v,
>>>> uint32_t msr)  { diff -r a6d12a1bc758
>>>> xen/arch/x86/cpu/mcheck/mce_intel.c ---
>>>> a/xen/arch/x86/cpu/mcheck/mce_intel.c	Thu Sep 20 00:03:25 2012
>>>>                  +0800 +++
>>>> b/xen/arch/x86/cpu/mcheck/mce_intel.c	Tue Sep 25 19:52:20 2012
>>>> +0800 @@ -365,7 +365,7 @@ }  
>>>> 
>>>>                  /* We will inject vMCE to DOMU*/
>>>> -                if ( inject_vmce(d) < 0 )
>>>> +                if ( inject_vmce(d, 1) < 0 )
>>>>                  {
>>>>                      mce_printk(MCE_QUIET, "inject vMCE to DOM%d"
>>>>                        " failed\n", d->domain_id);
>>>> diff -r a6d12a1bc758 xen/arch/x86/cpu/mcheck/vmce.c
>>>> --- a/xen/arch/x86/cpu/mcheck/vmce.c	Thu Sep 20 00:03:25 2012 +0800
>>>> +++ b/xen/arch/x86/cpu/mcheck/vmce.c	Tue Sep 25 19:52:20 2012
>>>>  +0800 @@ -344,11 +344,14 @@ HVM_REGISTER_SAVE_RESTORE(VMCE_VCPU,
>>>>                            vmce_save_vcpu_ctxt,
>>>> vmce_load_vcpu_ctxt, 1, HVMSR_PER_VCPU); 
>>>> 
>>>> -int inject_vmce(struct domain *d)
>>>> +/*
>>>> + * for Intel MCE, broadcast vMCE to all vcpus
>>>> + * for AMD MCE, only inject vMCE to vcpu0
>>>> + */
>>>> +int inject_vmce(struct domain *d, bool_t vmce_broadcast)  {
>>>>      struct vcpu *v;
>>>> 
>>>> -    /* inject vMCE to all vcpus */
>>>>      for_each_vcpu(d, v)
>>>>      {
>>>>          if ( !test_and_set_bool(v->mce_pending) && @@ -365,6
>>>>                         +368,9 @@ d->domain_id, v->vcpu_id);
>>>>              return -1;
>>>>          }
>>>> +
>>>> +        if ( !vmce_broadcast )
>>>> +            break;
>> 
>> That'll allow (non-broadcast) injection to vCPU 0 only - is that
>> really the right thing to do?
> 
> 
> On AMD side memory errors are found by the northbridge and the first
> cpu-core reports this. As long as we do not have NUMA support for the
> guest this is fine.
> 
>> I.e. shouldn't the caller rather be given flexibility to specify
>> which vCPU this is to go to (with a negative value meaning
>> broadcast)? 
> 
> This is a good idea. Go for it.
> 
> 
>> And I'm intending to fold this into patch 2 anyway before
>> committing.
> 
> 
> Yes, please.
> 
> Christoph

I fold patch 6 to patch 2, will send out later.

Thanks,
Jinsong
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 26 03:13:01 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Sep 2012 03:13:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGi35-0002Gq-Ss; Wed, 26 Sep 2012 03:12:31 +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 1TGi34-0002Gl-Br
	for xen-devel@lists.xensource.com; Wed, 26 Sep 2012 03:12:30 +0000
Received: from [85.158.143.35:47594] by server-3.bemta-4.messagelabs.com id
	B8/11-10986-D9272605; Wed, 26 Sep 2012 03:12:29 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1348629148!4136109!1
X-Originating-IP: [134.134.136.24]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjQgPT4gMzQ3OTA1\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21799 invoked from network); 26 Sep 2012 03:12:29 -0000
Received: from mga09.intel.com (HELO mga09.intel.com) (134.134.136.24)
	by server-5.tower-21.messagelabs.com with SMTP;
	26 Sep 2012 03:12:29 -0000
Received: from orsmga001.jf.intel.com ([10.7.209.18])
	by orsmga102.jf.intel.com with ESMTP; 25 Sep 2012 20:12:13 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.80,487,1344236400"; d="scan'208";a="197716115"
Received: from fmsmsx107.amr.corp.intel.com ([10.19.9.54])
	by orsmga001.jf.intel.com with ESMTP; 25 Sep 2012 20:12:27 -0700
Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by
	FMSMSX107.amr.corp.intel.com (10.19.9.54) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Tue, 25 Sep 2012 20:12:26 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.239]) by
	SHSMSX102.ccr.corp.intel.com ([169.254.2.92]) with mapi id
	14.01.0355.002; Wed, 26 Sep 2012 11:11:42 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: Christoph Egger <Christoph.Egger@amd.com>, Jan Beulich <JBeulich@suse.com>
Thread-Topic: [PATCH 6] X86/MCE: update vMCE injection for AMD
Thread-Index: AQHNmxR4bAubMQI3SAyq+zkwzNAc0peb8t4A
Date: Wed, 26 Sep 2012 03:11:41 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC829233533AA6E@SHSMSX101.ccr.corp.intel.com>
References: <DE8DF0795D48FD4CA783C40EC8292335339547@SHSMSX101.ccr.corp.intel.com>
	<506173FB.8070603@amd.com>
	<5061A833020000780009DA1A@nat28.tlf.novell.com>
	<50619B61.2030609@amd.com>
In-Reply-To: <50619B61.2030609@amd.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"keir@xen.org" <keir@xen.org>,
	"Ian.Campbell@citrix.com" <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH 6] X86/MCE: update vMCE injection for AMD
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Christoph Egger wrote:
> On 09/25/12 12:48, Jan Beulich wrote:
> 
>>>>> On 25.09.12 at 11:06, Christoph Egger <Christoph.Egger@amd.com>
>>>>> wrote: 
>>> On 09/25/12 07:00, Liu, Jinsong wrote:
>>> 
>>>> X86/MCE: update vMCE injection for AMD
>>>> 
>>>> For Intel MCE, it broadcasts vMCE to all vcpus. For AMD MCE, it
>>>> injects vMCE only to vcpu0. This patch update inject_vmce for AMD.
>>>> 
>>>> Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>
>>>> Suggested_by: Christoph Egger <Christoph.Egger@amd.com>
>>> 
>>> 
>>> Acked-by: Christoph Egger <Christoph.Egger@amd.com>
>> 
>> Are you sure (see below)?
> 
> Yes, see below.
> 
>>>> diff -r a6d12a1bc758 xen/arch/x86/cpu/mcheck/mce.h
>>>> --- a/xen/arch/x86/cpu/mcheck/mce.h	Thu Sep 20 00:03:25 2012 +0800
>>>> +++ b/xen/arch/x86/cpu/mcheck/mce.h	Tue Sep 25 19:52:20 2012 +0800
>>>> @@ -168,7 +168,7 @@ 
>>>> 
>>>>  int fill_vmsr_data(struct mcinfo_bank *mc_bank, struct domain *d,
>>>> uint64_t gstatus); -int inject_vmce(struct domain *d);
>>>> +int inject_vmce(struct domain *d, bool_t vmce_broadcast);
>>>> 
>>>>  static inline int mce_vendor_bank_msr(const struct vcpu *v,
>>>> uint32_t msr)  { diff -r a6d12a1bc758
>>>> xen/arch/x86/cpu/mcheck/mce_intel.c ---
>>>> a/xen/arch/x86/cpu/mcheck/mce_intel.c	Thu Sep 20 00:03:25 2012
>>>>                  +0800 +++
>>>> b/xen/arch/x86/cpu/mcheck/mce_intel.c	Tue Sep 25 19:52:20 2012
>>>> +0800 @@ -365,7 +365,7 @@ }  
>>>> 
>>>>                  /* We will inject vMCE to DOMU*/
>>>> -                if ( inject_vmce(d) < 0 )
>>>> +                if ( inject_vmce(d, 1) < 0 )
>>>>                  {
>>>>                      mce_printk(MCE_QUIET, "inject vMCE to DOM%d"
>>>>                        " failed\n", d->domain_id);
>>>> diff -r a6d12a1bc758 xen/arch/x86/cpu/mcheck/vmce.c
>>>> --- a/xen/arch/x86/cpu/mcheck/vmce.c	Thu Sep 20 00:03:25 2012 +0800
>>>> +++ b/xen/arch/x86/cpu/mcheck/vmce.c	Tue Sep 25 19:52:20 2012
>>>>  +0800 @@ -344,11 +344,14 @@ HVM_REGISTER_SAVE_RESTORE(VMCE_VCPU,
>>>>                            vmce_save_vcpu_ctxt,
>>>> vmce_load_vcpu_ctxt, 1, HVMSR_PER_VCPU); 
>>>> 
>>>> -int inject_vmce(struct domain *d)
>>>> +/*
>>>> + * for Intel MCE, broadcast vMCE to all vcpus
>>>> + * for AMD MCE, only inject vMCE to vcpu0
>>>> + */
>>>> +int inject_vmce(struct domain *d, bool_t vmce_broadcast)  {
>>>>      struct vcpu *v;
>>>> 
>>>> -    /* inject vMCE to all vcpus */
>>>>      for_each_vcpu(d, v)
>>>>      {
>>>>          if ( !test_and_set_bool(v->mce_pending) && @@ -365,6
>>>>                         +368,9 @@ d->domain_id, v->vcpu_id);
>>>>              return -1;
>>>>          }
>>>> +
>>>> +        if ( !vmce_broadcast )
>>>> +            break;
>> 
>> That'll allow (non-broadcast) injection to vCPU 0 only - is that
>> really the right thing to do?
> 
> 
> On AMD side memory errors are found by the northbridge and the first
> cpu-core reports this. As long as we do not have NUMA support for the
> guest this is fine.
> 
>> I.e. shouldn't the caller rather be given flexibility to specify
>> which vCPU this is to go to (with a negative value meaning
>> broadcast)? 
> 
> This is a good idea. Go for it.
> 
> 
>> And I'm intending to fold this into patch 2 anyway before
>> committing.
> 
> 
> Yes, please.
> 
> Christoph

I fold patch 6 to patch 2, will send out later.

Thanks,
Jinsong
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 26 03:16:38 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Sep 2012 03: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 1TGi6i-0002NV-Gt; Wed, 26 Sep 2012 03:16:16 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jinsong.liu@intel.com>) id 1TGi6g-0002NO-OV
	for xen-devel@lists.xensource.com; Wed, 26 Sep 2012 03:16:15 +0000
Received: from [85.158.143.99:4630] by server-3.bemta-4.messagelabs.com id
	CF/52-10986-E7372605; Wed, 26 Sep 2012 03:16:14 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1348629372!23646150!1
X-Originating-IP: [192.55.52.93]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjkzID0+IDM0Njg3Mw==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23084 invoked from network); 26 Sep 2012 03:16:12 -0000
Received: from mga11.intel.com (HELO mga11.intel.com) (192.55.52.93)
	by server-12.tower-216.messagelabs.com with SMTP;
	26 Sep 2012 03:16:12 -0000
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
	by fmsmga102.fm.intel.com with ESMTP; 25 Sep 2012 20:16:11 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.80,487,1344236400"; d="scan'208";a="226497288"
Received: from fmsmsx107.amr.corp.intel.com ([10.19.9.54])
	by fmsmga001.fm.intel.com with ESMTP; 25 Sep 2012 20:16:11 -0700
Received: from fmsmsx152.amr.corp.intel.com (10.19.17.221) by
	FMSMSX107.amr.corp.intel.com (10.19.9.54) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Tue, 25 Sep 2012 20:16:10 -0700
Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by
	fmsmsx152.amr.corp.intel.com (10.19.17.221) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Tue, 25 Sep 2012 20:16:10 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.239]) by
	SHSMSX102.ccr.corp.intel.com ([169.254.2.92]) with mapi id
	14.01.0355.002; Wed, 26 Sep 2012 11:16:08 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: Jan Beulich <JBeulich@suse.com>, Christoph Egger
	<Christoph.Egger@amd.com>, "xen-devel@lists.xensource.com"
	<xen-devel@lists.xensource.com>
Thread-Topic: [PATCH 2/5] Xen/MCE: vMCE injection
Thread-Index: Ac2blUVbGeA6diCIQfes3FeO/UgmEw==
Date: Wed, 26 Sep 2012 03:16:08 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC829233533AAC0@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_DE8DF0795D48FD4CA783C40EC829233533AAC0SHSMSX101ccrcorpi_"
MIME-Version: 1.0
Cc: "keir@xen.org" <keir@xen.org>,
	"Ian.Campbell@citrix.com" <Ian.Campbell@citrix.com>
Subject: [Xen-devel] [PATCH 2/5] Xen/MCE: vMCE injection
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--_002_DE8DF0795D48FD4CA783C40EC829233533AAC0SHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Xen/MCE: vMCE injection

for Intel MCE, broadcast vMCE to all vcpus;
for AMD MCE, only inject vMCE to 1 vcpu, say, vcpu0

Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>
Suggested_by: Christoph Egger <Christoph.Egger@amd.com>
Suggested_by: Jan Beulich <jbeulich@suse.com>

diff -r 570d98e2f1cf xen/arch/x86/cpu/mcheck/mce.h
--- a/xen/arch/x86/cpu/mcheck/mce.h	Wed Sep 19 23:22:57 2012 +0800
+++ b/xen/arch/x86/cpu/mcheck/mce.h	Wed Sep 26 18:59:03 2012 +0800
@@ -168,7 +168,7 @@
=20
 int fill_vmsr_data(struct mcinfo_bank *mc_bank, struct domain *d,
     uint64_t gstatus);
-int inject_vmce(struct domain *d);
+int inject_vmce(struct domain *d, int vcpuid);
=20
 static inline int mce_vendor_bank_msr(const struct vcpu *v, uint32_t msr)
 {
diff -r 570d98e2f1cf xen/arch/x86/cpu/mcheck/mce_intel.c
--- a/xen/arch/x86/cpu/mcheck/mce_intel.c	Wed Sep 19 23:22:57 2012 +0800
+++ b/xen/arch/x86/cpu/mcheck/mce_intel.c	Wed Sep 26 18:59:03 2012 +0800
@@ -359,7 +359,7 @@
                 }
=20
                 /* We will inject vMCE to DOMU*/
-                if ( inject_vmce(d) < 0 )
+                if ( inject_vmce(d, -1) < 0 )
                 {
                     mce_printk(MCE_QUIET, "inject vMCE to DOM%d"
                       " failed\n", d->domain_id);
diff -r 570d98e2f1cf xen/arch/x86/cpu/mcheck/vmce.c
--- a/xen/arch/x86/cpu/mcheck/vmce.c	Wed Sep 19 23:22:57 2012 +0800
+++ b/xen/arch/x86/cpu/mcheck/vmce.c	Wed Sep 26 18:59:03 2012 +0800
@@ -338,51 +338,44 @@
 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)
+/*
+ * for Intel MCE, broadcast vMCE to all vcpus
+ * for AMD MCE, only inject vMCE to 1 vcpu, say, vcpu0
+ * @ d, domain to which would inject vmce
+ * @ vcpuid,
+ *   < 0, broadcast vMCE to all vcpus
+ *   >=3D 0, vcpu who would be injected vMCE
+ * return 0 for success injection, -1 for fail injection
+ */
+int inject_vmce(struct domain *d, int vcpuid)
 {
-    int cpu =3D smp_processor_id();
+    struct vcpu *v;
+    int ret =3D -1;
=20
-    /* PV guest and HVM guest have different vMCE# injection methods. */
-    if ( !test_and_set_bool(d->vcpu[0]->mce_pending) )
+    for_each_vcpu(d, v)
     {
-        if ( d->is_hvm )
+        if ( (vcpuid < 0) || (vcpuid =3D=3D v->vcpu_id) )
         {
-            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) )
+            if ( !test_and_set_bool(v->mce_pending) &&
+                ((d->is_hvm) ||
+                guest_has_trap_callback(d, v->vcpu_id, 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]);
+                mce_printk(MCE_VERBOSE, "MCE: inject vMCE to dom%d vcpu%d\=
n",
+                           d->domain_id, v->vcpu_id);
+                vcpu_kick(v);
+                ret =3D 0;
             }
             else
             {
-                mce_printk(MCE_VERBOSE,
-                           "MCE: Kill PV guest with No MCE handler\n");
-                domain_crash(d);
+                mce_printk(MCE_QUIET, "Fail to inject vMCE to dom%d vcpu%d=
\n",
+                           d->domain_id, v->vcpu_id);
+                ret =3D -1;
+                break;
             }
         }
     }
-    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;
+
+    return ret;
 }
=20
 int fill_vmsr_data(struct mcinfo_bank *mc_bank, struct domain *d,=

--_002_DE8DF0795D48FD4CA783C40EC829233533AAC0SHSMSX101ccrcorpi_
Content-Type: application/octet-stream; name="2_vmce_injection.patch"
Content-Description: 2_vmce_injection.patch
Content-Disposition: attachment; filename="2_vmce_injection.patch"; size=4312;
	creation-date="Wed, 26 Sep 2012 03:09:24 GMT";
	modification-date="Wed, 26 Sep 2012 10:59:04 GMT"
Content-Transfer-Encoding: base64

WGVuL01DRTogdk1DRSBpbmplY3Rpb24KCmZvciBJbnRlbCBNQ0UsIGJyb2FkY2FzdCB2TUNFIHRv
IGFsbCB2Y3B1czsKZm9yIEFNRCBNQ0UsIG9ubHkgaW5qZWN0IHZNQ0UgdG8gMSB2Y3B1LCBzYXks
IHZjcHUwCgpTaWduZWQtb2ZmLWJ5OiBMaXUsIEppbnNvbmcgPGppbnNvbmcubGl1QGludGVsLmNv
bT4KU3VnZ2VzdGVkX2J5OiBDaHJpc3RvcGggRWdnZXIgPENocmlzdG9waC5FZ2dlckBhbWQuY29t
PgpTdWdnZXN0ZWRfYnk6IEphbiBCZXVsaWNoIDxqYmV1bGljaEBzdXNlLmNvbT4KCmRpZmYgLXIg
NTcwZDk4ZTJmMWNmIHhlbi9hcmNoL3g4Ni9jcHUvbWNoZWNrL21jZS5oCi0tLSBhL3hlbi9hcmNo
L3g4Ni9jcHUvbWNoZWNrL21jZS5oCVdlZCBTZXAgMTkgMjM6MjI6NTcgMjAxMiArMDgwMAorKysg
Yi94ZW4vYXJjaC94ODYvY3B1L21jaGVjay9tY2UuaAlXZWQgU2VwIDI2IDE4OjU5OjAzIDIwMTIg
KzA4MDAKQEAgLTE2OCw3ICsxNjgsNyBAQAogCiBpbnQgZmlsbF92bXNyX2RhdGEoc3RydWN0IG1j
aW5mb19iYW5rICptY19iYW5rLCBzdHJ1Y3QgZG9tYWluICpkLAogICAgIHVpbnQ2NF90IGdzdGF0
dXMpOwotaW50IGluamVjdF92bWNlKHN0cnVjdCBkb21haW4gKmQpOworaW50IGluamVjdF92bWNl
KHN0cnVjdCBkb21haW4gKmQsIGludCB2Y3B1aWQpOwogCiBzdGF0aWMgaW5saW5lIGludCBtY2Vf
dmVuZG9yX2JhbmtfbXNyKGNvbnN0IHN0cnVjdCB2Y3B1ICp2LCB1aW50MzJfdCBtc3IpCiB7CmRp
ZmYgLXIgNTcwZDk4ZTJmMWNmIHhlbi9hcmNoL3g4Ni9jcHUvbWNoZWNrL21jZV9pbnRlbC5jCi0t
LSBhL3hlbi9hcmNoL3g4Ni9jcHUvbWNoZWNrL21jZV9pbnRlbC5jCVdlZCBTZXAgMTkgMjM6MjI6
NTcgMjAxMiArMDgwMAorKysgYi94ZW4vYXJjaC94ODYvY3B1L21jaGVjay9tY2VfaW50ZWwuYwlX
ZWQgU2VwIDI2IDE4OjU5OjAzIDIwMTIgKzA4MDAKQEAgLTM1OSw3ICszNTksNyBAQAogICAgICAg
ICAgICAgICAgIH0KIAogICAgICAgICAgICAgICAgIC8qIFdlIHdpbGwgaW5qZWN0IHZNQ0UgdG8g
RE9NVSovCi0gICAgICAgICAgICAgICAgaWYgKCBpbmplY3Rfdm1jZShkKSA8IDAgKQorICAgICAg
ICAgICAgICAgIGlmICggaW5qZWN0X3ZtY2UoZCwgLTEpIDwgMCApCiAgICAgICAgICAgICAgICAg
ewogICAgICAgICAgICAgICAgICAgICBtY2VfcHJpbnRrKE1DRV9RVUlFVCwgImluamVjdCB2TUNF
IHRvIERPTSVkIgogICAgICAgICAgICAgICAgICAgICAgICIgZmFpbGVkXG4iLCBkLT5kb21haW5f
aWQpOwpkaWZmIC1yIDU3MGQ5OGUyZjFjZiB4ZW4vYXJjaC94ODYvY3B1L21jaGVjay92bWNlLmMK
LS0tIGEveGVuL2FyY2gveDg2L2NwdS9tY2hlY2svdm1jZS5jCVdlZCBTZXAgMTkgMjM6MjI6NTcg
MjAxMiArMDgwMAorKysgYi94ZW4vYXJjaC94ODYvY3B1L21jaGVjay92bWNlLmMJV2VkIFNlcCAy
NiAxODo1OTowMyAyMDEyICswODAwCkBAIC0zMzgsNTEgKzMzOCw0NCBAQAogSFZNX1JFR0lTVEVS
X1NBVkVfUkVTVE9SRShWTUNFX1ZDUFUsIHZtY2Vfc2F2ZV92Y3B1X2N0eHQsCiAgICAgICAgICAg
ICAgICAgICAgICAgICAgIHZtY2VfbG9hZF92Y3B1X2N0eHQsIDEsIEhWTVNSX1BFUl9WQ1BVKTsK
IAotaW50IGluamVjdF92bWNlKHN0cnVjdCBkb21haW4gKmQpCisvKgorICogZm9yIEludGVsIE1D
RSwgYnJvYWRjYXN0IHZNQ0UgdG8gYWxsIHZjcHVzCisgKiBmb3IgQU1EIE1DRSwgb25seSBpbmpl
Y3Qgdk1DRSB0byAxIHZjcHUsIHNheSwgdmNwdTAKKyAqIEAgZCwgZG9tYWluIHRvIHdoaWNoIHdv
dWxkIGluamVjdCB2bWNlCisgKiBAIHZjcHVpZCwKKyAqICAgPCAwLCBicm9hZGNhc3Qgdk1DRSB0
byBhbGwgdmNwdXMKKyAqICAgPj0gMCwgdmNwdSB3aG8gd291bGQgYmUgaW5qZWN0ZWQgdk1DRQor
ICogcmV0dXJuIDAgZm9yIHN1Y2Nlc3MgaW5qZWN0aW9uLCAtMSBmb3IgZmFpbCBpbmplY3Rpb24K
KyAqLworaW50IGluamVjdF92bWNlKHN0cnVjdCBkb21haW4gKmQsIGludCB2Y3B1aWQpCiB7Ci0g
ICAgaW50IGNwdSA9IHNtcF9wcm9jZXNzb3JfaWQoKTsKKyAgICBzdHJ1Y3QgdmNwdSAqdjsKKyAg
ICBpbnQgcmV0ID0gLTE7CiAKLSAgICAvKiBQViBndWVzdCBhbmQgSFZNIGd1ZXN0IGhhdmUgZGlm
ZmVyZW50IHZNQ0UjIGluamVjdGlvbiBtZXRob2RzLiAqLwotICAgIGlmICggIXRlc3RfYW5kX3Nl
dF9ib29sKGQtPnZjcHVbMF0tPm1jZV9wZW5kaW5nKSApCisgICAgZm9yX2VhY2hfdmNwdShkLCB2
KQogICAgIHsKLSAgICAgICAgaWYgKCBkLT5pc19odm0gKQorICAgICAgICBpZiAoICh2Y3B1aWQg
PCAwKSB8fCAodmNwdWlkID09IHYtPnZjcHVfaWQpICkKICAgICAgICAgewotICAgICAgICAgICAg
bWNlX3ByaW50ayhNQ0VfVkVSQk9TRSwgIk1DRTogaW5qZWN0IHZNQ0UgdG8gSFZNIERPTSAlZFxu
IiwKLSAgICAgICAgICAgICAgICAgICAgICAgZC0+ZG9tYWluX2lkKTsKLSAgICAgICAgICAgIHZj
cHVfa2ljayhkLT52Y3B1WzBdKTsKLSAgICAgICAgfQotICAgICAgICBlbHNlCi0gICAgICAgIHsK
LSAgICAgICAgICAgIG1jZV9wcmludGsoTUNFX1ZFUkJPU0UsICJNQ0U6IGluamVjdCB2TUNFIHRv
IFBWIERPTSVkXG4iLAotICAgICAgICAgICAgICAgICAgICAgICBkLT5kb21haW5faWQpOwotICAg
ICAgICAgICAgaWYgKCBndWVzdF9oYXNfdHJhcF9jYWxsYmFjayhkLCAwLCBUUkFQX21hY2hpbmVf
Y2hlY2spICkKKyAgICAgICAgICAgIGlmICggIXRlc3RfYW5kX3NldF9ib29sKHYtPm1jZV9wZW5k
aW5nKSAmJgorICAgICAgICAgICAgICAgICgoZC0+aXNfaHZtKSB8fAorICAgICAgICAgICAgICAg
IGd1ZXN0X2hhc190cmFwX2NhbGxiYWNrKGQsIHYtPnZjcHVfaWQsIFRSQVBfbWFjaGluZV9jaGVj
aykpICkKICAgICAgICAgICAgIHsKLSAgICAgICAgICAgICAgICBjcHVtYXNrX2NvcHkoZC0+dmNw
dVswXS0+Y3B1X2FmZmluaXR5X3RtcCwKLSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgZC0+
dmNwdVswXS0+Y3B1X2FmZmluaXR5KTsKLSAgICAgICAgICAgICAgICBtY2VfcHJpbnRrKE1DRV9W
RVJCT1NFLCAiTUNFOiBDUFUlZCBzZXQgYWZmaW5pdHksIG9sZCAlZFxuIiwKLSAgICAgICAgICAg
ICAgICAgICAgICAgICAgIGNwdSwgZC0+dmNwdVswXS0+cHJvY2Vzc29yKTsKLSAgICAgICAgICAg
ICAgICB2Y3B1X3NldF9hZmZpbml0eShkLT52Y3B1WzBdLCBjcHVtYXNrX29mKGNwdSkpOwotICAg
ICAgICAgICAgICAgIHZjcHVfa2ljayhkLT52Y3B1WzBdKTsKKyAgICAgICAgICAgICAgICBtY2Vf
cHJpbnRrKE1DRV9WRVJCT1NFLCAiTUNFOiBpbmplY3Qgdk1DRSB0byBkb20lZCB2Y3B1JWRcbiIs
CisgICAgICAgICAgICAgICAgICAgICAgICAgICBkLT5kb21haW5faWQsIHYtPnZjcHVfaWQpOwor
ICAgICAgICAgICAgICAgIHZjcHVfa2ljayh2KTsKKyAgICAgICAgICAgICAgICByZXQgPSAwOwog
ICAgICAgICAgICAgfQogICAgICAgICAgICAgZWxzZQogICAgICAgICAgICAgewotICAgICAgICAg
ICAgICAgIG1jZV9wcmludGsoTUNFX1ZFUkJPU0UsCi0gICAgICAgICAgICAgICAgICAgICAgICAg
ICAiTUNFOiBLaWxsIFBWIGd1ZXN0IHdpdGggTm8gTUNFIGhhbmRsZXJcbiIpOwotICAgICAgICAg
ICAgICAgIGRvbWFpbl9jcmFzaChkKTsKKyAgICAgICAgICAgICAgICBtY2VfcHJpbnRrKE1DRV9R
VUlFVCwgIkZhaWwgdG8gaW5qZWN0IHZNQ0UgdG8gZG9tJWQgdmNwdSVkXG4iLAorICAgICAgICAg
ICAgICAgICAgICAgICAgICAgZC0+ZG9tYWluX2lkLCB2LT52Y3B1X2lkKTsKKyAgICAgICAgICAg
ICAgICByZXQgPSAtMTsKKyAgICAgICAgICAgICAgICBicmVhazsKICAgICAgICAgICAgIH0KICAg
ICAgICAgfQogICAgIH0KLSAgICBlbHNlCi0gICAgewotICAgICAgICAvKiBuZXcgdk1DRSBjb21l
cyB3aGlsZSBmaXJzdCBvbmUgaGFzIG5vdCBiZWVuIGluamVjdGVkIHlldCwKLSAgICAgICAgICog
aW4gdGhpcyBjYXNlLCBpbmplY3QgZmFpbC4gW1dlIGNhbid0IGxvc2UgdGhpcyB2TUNFIGZvcgot
ICAgICAgICAgKiB0aGUgbWNlIG5vZGUncyBjb25zaXN0ZW5jeV0uCi0gICAgICAgICAqLwotICAg
ICAgICBtY2VfcHJpbnRrKE1DRV9RVUlFVCwgIlRoZXJlJ3MgYSBwZW5kaW5nIHZNQ0Ugd2FpdGlu
ZyB0byBiZSBpbmplY3RlZCAiCi0gICAgICAgICAgICAgICAgICAgIiB0byB0aGlzIERPTSVkIVxu
IiwgZC0+ZG9tYWluX2lkKTsKLSAgICAgICAgcmV0dXJuIC0xOwotICAgIH0KLSAgICByZXR1cm4g
MDsKKworICAgIHJldHVybiByZXQ7CiB9CiAKIGludCBmaWxsX3Ztc3JfZGF0YShzdHJ1Y3QgbWNp
bmZvX2JhbmsgKm1jX2JhbmssIHN0cnVjdCBkb21haW4gKmQsCg==

--_002_DE8DF0795D48FD4CA783C40EC829233533AAC0SHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 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_DE8DF0795D48FD4CA783C40EC829233533AAC0SHSMSX101ccrcorpi_--


From xen-devel-bounces@lists.xen.org Wed Sep 26 03:16:38 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Sep 2012 03: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 1TGi6i-0002NV-Gt; Wed, 26 Sep 2012 03:16:16 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jinsong.liu@intel.com>) id 1TGi6g-0002NO-OV
	for xen-devel@lists.xensource.com; Wed, 26 Sep 2012 03:16:15 +0000
Received: from [85.158.143.99:4630] by server-3.bemta-4.messagelabs.com id
	CF/52-10986-E7372605; Wed, 26 Sep 2012 03:16:14 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1348629372!23646150!1
X-Originating-IP: [192.55.52.93]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjkzID0+IDM0Njg3Mw==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23084 invoked from network); 26 Sep 2012 03:16:12 -0000
Received: from mga11.intel.com (HELO mga11.intel.com) (192.55.52.93)
	by server-12.tower-216.messagelabs.com with SMTP;
	26 Sep 2012 03:16:12 -0000
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
	by fmsmga102.fm.intel.com with ESMTP; 25 Sep 2012 20:16:11 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.80,487,1344236400"; d="scan'208";a="226497288"
Received: from fmsmsx107.amr.corp.intel.com ([10.19.9.54])
	by fmsmga001.fm.intel.com with ESMTP; 25 Sep 2012 20:16:11 -0700
Received: from fmsmsx152.amr.corp.intel.com (10.19.17.221) by
	FMSMSX107.amr.corp.intel.com (10.19.9.54) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Tue, 25 Sep 2012 20:16:10 -0700
Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by
	fmsmsx152.amr.corp.intel.com (10.19.17.221) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Tue, 25 Sep 2012 20:16:10 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.239]) by
	SHSMSX102.ccr.corp.intel.com ([169.254.2.92]) with mapi id
	14.01.0355.002; Wed, 26 Sep 2012 11:16:08 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: Jan Beulich <JBeulich@suse.com>, Christoph Egger
	<Christoph.Egger@amd.com>, "xen-devel@lists.xensource.com"
	<xen-devel@lists.xensource.com>
Thread-Topic: [PATCH 2/5] Xen/MCE: vMCE injection
Thread-Index: Ac2blUVbGeA6diCIQfes3FeO/UgmEw==
Date: Wed, 26 Sep 2012 03:16:08 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC829233533AAC0@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_DE8DF0795D48FD4CA783C40EC829233533AAC0SHSMSX101ccrcorpi_"
MIME-Version: 1.0
Cc: "keir@xen.org" <keir@xen.org>,
	"Ian.Campbell@citrix.com" <Ian.Campbell@citrix.com>
Subject: [Xen-devel] [PATCH 2/5] Xen/MCE: vMCE injection
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--_002_DE8DF0795D48FD4CA783C40EC829233533AAC0SHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Xen/MCE: vMCE injection

for Intel MCE, broadcast vMCE to all vcpus;
for AMD MCE, only inject vMCE to 1 vcpu, say, vcpu0

Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>
Suggested_by: Christoph Egger <Christoph.Egger@amd.com>
Suggested_by: Jan Beulich <jbeulich@suse.com>

diff -r 570d98e2f1cf xen/arch/x86/cpu/mcheck/mce.h
--- a/xen/arch/x86/cpu/mcheck/mce.h	Wed Sep 19 23:22:57 2012 +0800
+++ b/xen/arch/x86/cpu/mcheck/mce.h	Wed Sep 26 18:59:03 2012 +0800
@@ -168,7 +168,7 @@
=20
 int fill_vmsr_data(struct mcinfo_bank *mc_bank, struct domain *d,
     uint64_t gstatus);
-int inject_vmce(struct domain *d);
+int inject_vmce(struct domain *d, int vcpuid);
=20
 static inline int mce_vendor_bank_msr(const struct vcpu *v, uint32_t msr)
 {
diff -r 570d98e2f1cf xen/arch/x86/cpu/mcheck/mce_intel.c
--- a/xen/arch/x86/cpu/mcheck/mce_intel.c	Wed Sep 19 23:22:57 2012 +0800
+++ b/xen/arch/x86/cpu/mcheck/mce_intel.c	Wed Sep 26 18:59:03 2012 +0800
@@ -359,7 +359,7 @@
                 }
=20
                 /* We will inject vMCE to DOMU*/
-                if ( inject_vmce(d) < 0 )
+                if ( inject_vmce(d, -1) < 0 )
                 {
                     mce_printk(MCE_QUIET, "inject vMCE to DOM%d"
                       " failed\n", d->domain_id);
diff -r 570d98e2f1cf xen/arch/x86/cpu/mcheck/vmce.c
--- a/xen/arch/x86/cpu/mcheck/vmce.c	Wed Sep 19 23:22:57 2012 +0800
+++ b/xen/arch/x86/cpu/mcheck/vmce.c	Wed Sep 26 18:59:03 2012 +0800
@@ -338,51 +338,44 @@
 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)
+/*
+ * for Intel MCE, broadcast vMCE to all vcpus
+ * for AMD MCE, only inject vMCE to 1 vcpu, say, vcpu0
+ * @ d, domain to which would inject vmce
+ * @ vcpuid,
+ *   < 0, broadcast vMCE to all vcpus
+ *   >=3D 0, vcpu who would be injected vMCE
+ * return 0 for success injection, -1 for fail injection
+ */
+int inject_vmce(struct domain *d, int vcpuid)
 {
-    int cpu =3D smp_processor_id();
+    struct vcpu *v;
+    int ret =3D -1;
=20
-    /* PV guest and HVM guest have different vMCE# injection methods. */
-    if ( !test_and_set_bool(d->vcpu[0]->mce_pending) )
+    for_each_vcpu(d, v)
     {
-        if ( d->is_hvm )
+        if ( (vcpuid < 0) || (vcpuid =3D=3D v->vcpu_id) )
         {
-            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) )
+            if ( !test_and_set_bool(v->mce_pending) &&
+                ((d->is_hvm) ||
+                guest_has_trap_callback(d, v->vcpu_id, 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]);
+                mce_printk(MCE_VERBOSE, "MCE: inject vMCE to dom%d vcpu%d\=
n",
+                           d->domain_id, v->vcpu_id);
+                vcpu_kick(v);
+                ret =3D 0;
             }
             else
             {
-                mce_printk(MCE_VERBOSE,
-                           "MCE: Kill PV guest with No MCE handler\n");
-                domain_crash(d);
+                mce_printk(MCE_QUIET, "Fail to inject vMCE to dom%d vcpu%d=
\n",
+                           d->domain_id, v->vcpu_id);
+                ret =3D -1;
+                break;
             }
         }
     }
-    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;
+
+    return ret;
 }
=20
 int fill_vmsr_data(struct mcinfo_bank *mc_bank, struct domain *d,=

--_002_DE8DF0795D48FD4CA783C40EC829233533AAC0SHSMSX101ccrcorpi_
Content-Type: application/octet-stream; name="2_vmce_injection.patch"
Content-Description: 2_vmce_injection.patch
Content-Disposition: attachment; filename="2_vmce_injection.patch"; size=4312;
	creation-date="Wed, 26 Sep 2012 03:09:24 GMT";
	modification-date="Wed, 26 Sep 2012 10:59:04 GMT"
Content-Transfer-Encoding: base64

WGVuL01DRTogdk1DRSBpbmplY3Rpb24KCmZvciBJbnRlbCBNQ0UsIGJyb2FkY2FzdCB2TUNFIHRv
IGFsbCB2Y3B1czsKZm9yIEFNRCBNQ0UsIG9ubHkgaW5qZWN0IHZNQ0UgdG8gMSB2Y3B1LCBzYXks
IHZjcHUwCgpTaWduZWQtb2ZmLWJ5OiBMaXUsIEppbnNvbmcgPGppbnNvbmcubGl1QGludGVsLmNv
bT4KU3VnZ2VzdGVkX2J5OiBDaHJpc3RvcGggRWdnZXIgPENocmlzdG9waC5FZ2dlckBhbWQuY29t
PgpTdWdnZXN0ZWRfYnk6IEphbiBCZXVsaWNoIDxqYmV1bGljaEBzdXNlLmNvbT4KCmRpZmYgLXIg
NTcwZDk4ZTJmMWNmIHhlbi9hcmNoL3g4Ni9jcHUvbWNoZWNrL21jZS5oCi0tLSBhL3hlbi9hcmNo
L3g4Ni9jcHUvbWNoZWNrL21jZS5oCVdlZCBTZXAgMTkgMjM6MjI6NTcgMjAxMiArMDgwMAorKysg
Yi94ZW4vYXJjaC94ODYvY3B1L21jaGVjay9tY2UuaAlXZWQgU2VwIDI2IDE4OjU5OjAzIDIwMTIg
KzA4MDAKQEAgLTE2OCw3ICsxNjgsNyBAQAogCiBpbnQgZmlsbF92bXNyX2RhdGEoc3RydWN0IG1j
aW5mb19iYW5rICptY19iYW5rLCBzdHJ1Y3QgZG9tYWluICpkLAogICAgIHVpbnQ2NF90IGdzdGF0
dXMpOwotaW50IGluamVjdF92bWNlKHN0cnVjdCBkb21haW4gKmQpOworaW50IGluamVjdF92bWNl
KHN0cnVjdCBkb21haW4gKmQsIGludCB2Y3B1aWQpOwogCiBzdGF0aWMgaW5saW5lIGludCBtY2Vf
dmVuZG9yX2JhbmtfbXNyKGNvbnN0IHN0cnVjdCB2Y3B1ICp2LCB1aW50MzJfdCBtc3IpCiB7CmRp
ZmYgLXIgNTcwZDk4ZTJmMWNmIHhlbi9hcmNoL3g4Ni9jcHUvbWNoZWNrL21jZV9pbnRlbC5jCi0t
LSBhL3hlbi9hcmNoL3g4Ni9jcHUvbWNoZWNrL21jZV9pbnRlbC5jCVdlZCBTZXAgMTkgMjM6MjI6
NTcgMjAxMiArMDgwMAorKysgYi94ZW4vYXJjaC94ODYvY3B1L21jaGVjay9tY2VfaW50ZWwuYwlX
ZWQgU2VwIDI2IDE4OjU5OjAzIDIwMTIgKzA4MDAKQEAgLTM1OSw3ICszNTksNyBAQAogICAgICAg
ICAgICAgICAgIH0KIAogICAgICAgICAgICAgICAgIC8qIFdlIHdpbGwgaW5qZWN0IHZNQ0UgdG8g
RE9NVSovCi0gICAgICAgICAgICAgICAgaWYgKCBpbmplY3Rfdm1jZShkKSA8IDAgKQorICAgICAg
ICAgICAgICAgIGlmICggaW5qZWN0X3ZtY2UoZCwgLTEpIDwgMCApCiAgICAgICAgICAgICAgICAg
ewogICAgICAgICAgICAgICAgICAgICBtY2VfcHJpbnRrKE1DRV9RVUlFVCwgImluamVjdCB2TUNF
IHRvIERPTSVkIgogICAgICAgICAgICAgICAgICAgICAgICIgZmFpbGVkXG4iLCBkLT5kb21haW5f
aWQpOwpkaWZmIC1yIDU3MGQ5OGUyZjFjZiB4ZW4vYXJjaC94ODYvY3B1L21jaGVjay92bWNlLmMK
LS0tIGEveGVuL2FyY2gveDg2L2NwdS9tY2hlY2svdm1jZS5jCVdlZCBTZXAgMTkgMjM6MjI6NTcg
MjAxMiArMDgwMAorKysgYi94ZW4vYXJjaC94ODYvY3B1L21jaGVjay92bWNlLmMJV2VkIFNlcCAy
NiAxODo1OTowMyAyMDEyICswODAwCkBAIC0zMzgsNTEgKzMzOCw0NCBAQAogSFZNX1JFR0lTVEVS
X1NBVkVfUkVTVE9SRShWTUNFX1ZDUFUsIHZtY2Vfc2F2ZV92Y3B1X2N0eHQsCiAgICAgICAgICAg
ICAgICAgICAgICAgICAgIHZtY2VfbG9hZF92Y3B1X2N0eHQsIDEsIEhWTVNSX1BFUl9WQ1BVKTsK
IAotaW50IGluamVjdF92bWNlKHN0cnVjdCBkb21haW4gKmQpCisvKgorICogZm9yIEludGVsIE1D
RSwgYnJvYWRjYXN0IHZNQ0UgdG8gYWxsIHZjcHVzCisgKiBmb3IgQU1EIE1DRSwgb25seSBpbmpl
Y3Qgdk1DRSB0byAxIHZjcHUsIHNheSwgdmNwdTAKKyAqIEAgZCwgZG9tYWluIHRvIHdoaWNoIHdv
dWxkIGluamVjdCB2bWNlCisgKiBAIHZjcHVpZCwKKyAqICAgPCAwLCBicm9hZGNhc3Qgdk1DRSB0
byBhbGwgdmNwdXMKKyAqICAgPj0gMCwgdmNwdSB3aG8gd291bGQgYmUgaW5qZWN0ZWQgdk1DRQor
ICogcmV0dXJuIDAgZm9yIHN1Y2Nlc3MgaW5qZWN0aW9uLCAtMSBmb3IgZmFpbCBpbmplY3Rpb24K
KyAqLworaW50IGluamVjdF92bWNlKHN0cnVjdCBkb21haW4gKmQsIGludCB2Y3B1aWQpCiB7Ci0g
ICAgaW50IGNwdSA9IHNtcF9wcm9jZXNzb3JfaWQoKTsKKyAgICBzdHJ1Y3QgdmNwdSAqdjsKKyAg
ICBpbnQgcmV0ID0gLTE7CiAKLSAgICAvKiBQViBndWVzdCBhbmQgSFZNIGd1ZXN0IGhhdmUgZGlm
ZmVyZW50IHZNQ0UjIGluamVjdGlvbiBtZXRob2RzLiAqLwotICAgIGlmICggIXRlc3RfYW5kX3Nl
dF9ib29sKGQtPnZjcHVbMF0tPm1jZV9wZW5kaW5nKSApCisgICAgZm9yX2VhY2hfdmNwdShkLCB2
KQogICAgIHsKLSAgICAgICAgaWYgKCBkLT5pc19odm0gKQorICAgICAgICBpZiAoICh2Y3B1aWQg
PCAwKSB8fCAodmNwdWlkID09IHYtPnZjcHVfaWQpICkKICAgICAgICAgewotICAgICAgICAgICAg
bWNlX3ByaW50ayhNQ0VfVkVSQk9TRSwgIk1DRTogaW5qZWN0IHZNQ0UgdG8gSFZNIERPTSAlZFxu
IiwKLSAgICAgICAgICAgICAgICAgICAgICAgZC0+ZG9tYWluX2lkKTsKLSAgICAgICAgICAgIHZj
cHVfa2ljayhkLT52Y3B1WzBdKTsKLSAgICAgICAgfQotICAgICAgICBlbHNlCi0gICAgICAgIHsK
LSAgICAgICAgICAgIG1jZV9wcmludGsoTUNFX1ZFUkJPU0UsICJNQ0U6IGluamVjdCB2TUNFIHRv
IFBWIERPTSVkXG4iLAotICAgICAgICAgICAgICAgICAgICAgICBkLT5kb21haW5faWQpOwotICAg
ICAgICAgICAgaWYgKCBndWVzdF9oYXNfdHJhcF9jYWxsYmFjayhkLCAwLCBUUkFQX21hY2hpbmVf
Y2hlY2spICkKKyAgICAgICAgICAgIGlmICggIXRlc3RfYW5kX3NldF9ib29sKHYtPm1jZV9wZW5k
aW5nKSAmJgorICAgICAgICAgICAgICAgICgoZC0+aXNfaHZtKSB8fAorICAgICAgICAgICAgICAg
IGd1ZXN0X2hhc190cmFwX2NhbGxiYWNrKGQsIHYtPnZjcHVfaWQsIFRSQVBfbWFjaGluZV9jaGVj
aykpICkKICAgICAgICAgICAgIHsKLSAgICAgICAgICAgICAgICBjcHVtYXNrX2NvcHkoZC0+dmNw
dVswXS0+Y3B1X2FmZmluaXR5X3RtcCwKLSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgZC0+
dmNwdVswXS0+Y3B1X2FmZmluaXR5KTsKLSAgICAgICAgICAgICAgICBtY2VfcHJpbnRrKE1DRV9W
RVJCT1NFLCAiTUNFOiBDUFUlZCBzZXQgYWZmaW5pdHksIG9sZCAlZFxuIiwKLSAgICAgICAgICAg
ICAgICAgICAgICAgICAgIGNwdSwgZC0+dmNwdVswXS0+cHJvY2Vzc29yKTsKLSAgICAgICAgICAg
ICAgICB2Y3B1X3NldF9hZmZpbml0eShkLT52Y3B1WzBdLCBjcHVtYXNrX29mKGNwdSkpOwotICAg
ICAgICAgICAgICAgIHZjcHVfa2ljayhkLT52Y3B1WzBdKTsKKyAgICAgICAgICAgICAgICBtY2Vf
cHJpbnRrKE1DRV9WRVJCT1NFLCAiTUNFOiBpbmplY3Qgdk1DRSB0byBkb20lZCB2Y3B1JWRcbiIs
CisgICAgICAgICAgICAgICAgICAgICAgICAgICBkLT5kb21haW5faWQsIHYtPnZjcHVfaWQpOwor
ICAgICAgICAgICAgICAgIHZjcHVfa2ljayh2KTsKKyAgICAgICAgICAgICAgICByZXQgPSAwOwog
ICAgICAgICAgICAgfQogICAgICAgICAgICAgZWxzZQogICAgICAgICAgICAgewotICAgICAgICAg
ICAgICAgIG1jZV9wcmludGsoTUNFX1ZFUkJPU0UsCi0gICAgICAgICAgICAgICAgICAgICAgICAg
ICAiTUNFOiBLaWxsIFBWIGd1ZXN0IHdpdGggTm8gTUNFIGhhbmRsZXJcbiIpOwotICAgICAgICAg
ICAgICAgIGRvbWFpbl9jcmFzaChkKTsKKyAgICAgICAgICAgICAgICBtY2VfcHJpbnRrKE1DRV9R
VUlFVCwgIkZhaWwgdG8gaW5qZWN0IHZNQ0UgdG8gZG9tJWQgdmNwdSVkXG4iLAorICAgICAgICAg
ICAgICAgICAgICAgICAgICAgZC0+ZG9tYWluX2lkLCB2LT52Y3B1X2lkKTsKKyAgICAgICAgICAg
ICAgICByZXQgPSAtMTsKKyAgICAgICAgICAgICAgICBicmVhazsKICAgICAgICAgICAgIH0KICAg
ICAgICAgfQogICAgIH0KLSAgICBlbHNlCi0gICAgewotICAgICAgICAvKiBuZXcgdk1DRSBjb21l
cyB3aGlsZSBmaXJzdCBvbmUgaGFzIG5vdCBiZWVuIGluamVjdGVkIHlldCwKLSAgICAgICAgICog
aW4gdGhpcyBjYXNlLCBpbmplY3QgZmFpbC4gW1dlIGNhbid0IGxvc2UgdGhpcyB2TUNFIGZvcgot
ICAgICAgICAgKiB0aGUgbWNlIG5vZGUncyBjb25zaXN0ZW5jeV0uCi0gICAgICAgICAqLwotICAg
ICAgICBtY2VfcHJpbnRrKE1DRV9RVUlFVCwgIlRoZXJlJ3MgYSBwZW5kaW5nIHZNQ0Ugd2FpdGlu
ZyB0byBiZSBpbmplY3RlZCAiCi0gICAgICAgICAgICAgICAgICAgIiB0byB0aGlzIERPTSVkIVxu
IiwgZC0+ZG9tYWluX2lkKTsKLSAgICAgICAgcmV0dXJuIC0xOwotICAgIH0KLSAgICByZXR1cm4g
MDsKKworICAgIHJldHVybiByZXQ7CiB9CiAKIGludCBmaWxsX3Ztc3JfZGF0YShzdHJ1Y3QgbWNp
bmZvX2JhbmsgKm1jX2JhbmssIHN0cnVjdCBkb21haW4gKmQsCg==

--_002_DE8DF0795D48FD4CA783C40EC829233533AAC0SHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 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_DE8DF0795D48FD4CA783C40EC829233533AAC0SHSMSX101ccrcorpi_--


From xen-devel-bounces@lists.xen.org Wed Sep 26 05:37:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Sep 2012 05:37:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGkIb-0003E5-0E; Wed, 26 Sep 2012 05:36:41 +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 1TGkIY-0003E0-JB
	for xen-devel@lists.xensource.com; Wed, 26 Sep 2012 05:36:39 +0000
Received: from [85.158.139.211:52780] by server-11.bemta-5.messagelabs.com id
	CF/D5-13866-56492605; Wed, 26 Sep 2012 05:36:37 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-9.tower-206.messagelabs.com!1348637795!18464081!1
X-Originating-IP: [192.55.52.93]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjkzID0+IDM0Njg3Mw==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30138 invoked from network); 26 Sep 2012 05:36:36 -0000
Received: from mga11.intel.com (HELO mga11.intel.com) (192.55.52.93)
	by server-9.tower-206.messagelabs.com with SMTP;
	26 Sep 2012 05:36:36 -0000
Received: from fmsmga002.fm.intel.com ([10.253.24.26])
	by fmsmga102.fm.intel.com with ESMTP; 25 Sep 2012 22:36:35 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.80,487,1344236400"; d="scan'208";a="226818194"
Received: from fmsmsx106.amr.corp.intel.com ([10.19.9.37])
	by fmsmga002.fm.intel.com with ESMTP; 25 Sep 2012 22:36:34 -0700
Received: from fmsmsx151.amr.corp.intel.com (10.19.17.220) by
	FMSMSX106.amr.corp.intel.com (10.19.9.37) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Tue, 25 Sep 2012 22:36:34 -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; Tue, 25 Sep 2012 22:36:34 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.239]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.175]) with mapi id
	14.01.0355.002; Wed, 26 Sep 2012 13:36:32 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: "Ian.Campbell@citrix.com" <Ian.Campbell@citrix.com>, Ian Jackson
	<Ian.Jackson@eu.citrix.com>, "xen-devel@lists.xensource.com"
	<xen-devel@lists.xensource.com>
Thread-Topic: Patch review: vMCE patches 4/5 and 5/5
Thread-Index: Ac2bqOKLxDZSgggOQfiF3hPIJjEB6g==
Date: Wed, 26 Sep 2012 05:36:32 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC829233533ABA1@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="_003_DE8DF0795D48FD4CA783C40EC829233533ABA1SHSMSX101ccrcorpi_"
MIME-Version: 1.0
Cc: Christoph Egger <Christoph.Egger@amd.com>, "keir@xen.org" <keir@xen.org>,
	Jan Beulich <JBeulich@suse.com>
Subject: [Xen-devel] Patch review: vMCE patches 4/5 and 5/5
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--_003_DE8DF0795D48FD4CA783C40EC829233533ABA1SHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi,

Attached are 2 patches of Xen vMCE, it mainly handle vMCE when live migrate=
.
Patch4/5 used to handle vMCE while live migrate.
Patch5/5 used handle vMCE before live migrate.

These 2 patches involves some tools logic, would you please kindly help me =
to review them?

Thanks,
Jinsong=

--_003_DE8DF0795D48FD4CA783C40EC829233533ABA1SHSMSX101ccrcorpi_
Content-Type: application/octet-stream; name="4_vmce_when_migrate.patch"
Content-Description: 4_vmce_when_migrate.patch
Content-Disposition: attachment; filename="4_vmce_when_migrate.patch";
	size=7729; creation-date="Wed, 26 Sep 2012 03:09:24 GMT";
	modification-date="Wed, 19 Sep 2012 16:00:18 GMT"
Content-Transfer-Encoding: base64

WGVuL01DRTogQWJvcnQgbGl2ZSBtaWdyYXRpb24gd2hlbiB2TUNFIG9jY3VyCgpUaGlzIHBhdGNo
IG1vbml0b3IgdGhlIGNyaXRpY2FsIGFyZWEgb2YgbGl2ZSBtaWdyYXRpb24gKGZyb20gdk1DRSBw
b2ludCBvZiB2aWV3LAp0aGUgY29weXBhZ2VzIHN0YWdlIG9mIG1pZ3JhdGlvbiBpcyB0aGUgY3Jp
dGljYWwgYXJlYSB3aGlsZSBvdGhlciBhcmVhcyBhcmUgbm90KS4KCklmIGEgdk1DRSBvY2N1ciBh
dCB0aGUgY3JpdGljYWwgYXJlYSBvZiBsaXZlIG1pZ3JhdGlvbiwgYWJvcnQgYW5kIHRyeSBtaWdy
YXRpb24gbGF0ZXIuCgpTaWduZWQtb2ZmLWJ5OiBMaXUsIEppbnNvbmcgPGppbnNvbmcubGl1QGlu
dGVsLmNvbT4KCmRpZmYgLXIgZTcxYzRiZGNjMDVhIHRvb2xzL2xpYnhjL3hjX2RvbWFpbi5jCi0t
LSBhL3Rvb2xzL2xpYnhjL3hjX2RvbWFpbi5jCVdlZCBTZXAgMTkgMjM6Mjc6NDAgMjAxMiArMDgw
MAorKysgYi90b29scy9saWJ4Yy94Y19kb21haW4uYwlUaHUgU2VwIDIwIDAwOjAwOjE3IDIwMTIg
KzA4MDAKQEAgLTI4Myw2ICsyODMsMzcgQEAKICAgICByZXR1cm4gcmV0OwogfQogCisvKiBTdGFy
dCB2bWNlIG1vbml0b3IgKi8KK2ludCB4Y19kb21haW5fdm1jZV9tb25pdG9yX3N0YXJ0KHhjX2lu
dGVyZmFjZSAqeGNoLAorICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgdWludDMyX3Qg
ZG9taWQpCit7CisgICAgaW50IHJldDsKKyAgICBERUNMQVJFX0RPTUNUTDsKKworICAgIGRvbWN0
bC5jbWQgPSBYRU5fRE9NQ1RMX3ZtY2VfbW9uaXRvcl9zdGFydDsKKyAgICBkb21jdGwuZG9tYWlu
ID0gKGRvbWlkX3QpZG9taWQ7CisgICAgcmV0ID0gZG9fZG9tY3RsKHhjaCwgJmRvbWN0bCk7CisK
KyAgICByZXR1cm4gcmV0ID8gLTEgOiAwOworfQorCisvKiBFbmQgdm1jZSBtb25pdG9yICovCitp
bnQgeGNfZG9tYWluX3ZtY2VfbW9uaXRvcl9lbmQoeGNfaW50ZXJmYWNlICp4Y2gsCisgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgdWludDMyX3QgZG9taWQsCisgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgc2lnbmVkIGNoYXIgKnZtY2Vfd2hpbGVfbW9uaXRvcikKK3sKKyAgICBp
bnQgcmV0OworICAgIERFQ0xBUkVfRE9NQ1RMOworCisgICAgZG9tY3RsLmNtZCA9IFhFTl9ET01D
VExfdm1jZV9tb25pdG9yX2VuZDsKKyAgICBkb21jdGwuZG9tYWluID0gKGRvbWlkX3QpZG9taWQ7
CisgICAgcmV0ID0gZG9fZG9tY3RsKHhjaCwgJmRvbWN0bCk7CisgICAgaWYgKCAhcmV0ICkKKyAg
ICAgICAgKnZtY2Vfd2hpbGVfbW9uaXRvciA9IGRvbWN0bC51LnZtY2VfbW9uaXRvci52bWNlX3do
aWxlX21vbml0b3I7CisKKyAgICByZXR1cm4gcmV0ID8gLTEgOiAwOworfQorCiAvKiBnZXQgaW5m
byBmcm9tIGh2bSBndWVzdCBmb3Igc2F2ZSAqLwogaW50IHhjX2RvbWFpbl9odm1fZ2V0Y29udGV4
dCh4Y19pbnRlcmZhY2UgKnhjaCwKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgdWludDMy
X3QgZG9taWQsCmRpZmYgLXIgZTcxYzRiZGNjMDVhIHRvb2xzL2xpYnhjL3hjX2RvbWFpbl9zYXZl
LmMKLS0tIGEvdG9vbHMvbGlieGMveGNfZG9tYWluX3NhdmUuYwlXZWQgU2VwIDE5IDIzOjI3OjQw
IDIwMTIgKzA4MDAKKysrIGIvdG9vbHMvbGlieGMveGNfZG9tYWluX3NhdmUuYwlUaHUgU2VwIDIw
IDAwOjAwOjE3IDIwMTIgKzA4MDAKQEAgLTg5NSw2ICs4OTUsOCBAQAogICAgICAqLwogICAgIGlu
dCBjb21wcmVzc2luZyA9IDA7CiAKKyAgICBzaWduZWQgY2hhciB2bWNlX3doaWxlX21vbml0b3Ig
PSAwOworCiAgICAgaW50IGNvbXBsZXRlZCA9IDA7CiAKICAgICBpZiAoIGh2bSAmJiAhY2FsbGJh
Y2tzLT5zd2l0Y2hfcWVtdV9sb2dkaXJ0eSApCkBAIC0xMTA5LDYgKzExMTEsMTIgQEAKICAgICAg
ICAgZ290byBvdXQ7CiAgICAgfQogCisgICAgaWYgKCB4Y19kb21haW5fdm1jZV9tb25pdG9yX3N0
YXJ0KHhjaCwgZG9tKSApCisgICAgeworICAgICAgICBQRVJST1IoIkVycm9yIHdoZW4gc3RhcnQg
dm1jZSBtb25pdG9yXG4iKTsKKyAgICAgICAgZ290byBvdXQ7CisgICAgfQorCiAgIGNvcHlwYWdl
czoKICNkZWZpbmUgd3JleGFjdChmZCwgYnVmLCBsZW4pIHdyaXRlX2J1ZmZlcih4Y2gsIGxhc3Rf
aXRlciwgb2IsIChmZCksIChidWYpLCAobGVuKSkKICNkZWZpbmUgd3J1bmNhY2hlZChmZCwgbGl2
ZSwgYnVmLCBsZW4pIHdyaXRlX3VuY2FjaGVkKHhjaCwgbGFzdF9pdGVyLCBvYiwgKGZkKSwgKGJ1
ZiksIChsZW4pKQpAQCAtMTU3MSw2ICsxNTc5LDE3IEBACiAKICAgICBEUFJJTlRGKCJBbGwgbWVt
b3J5IGlzIHNhdmVkXG4iKTsKIAorICAgIGlmICggeGNfZG9tYWluX3ZtY2VfbW9uaXRvcl9lbmQo
eGNoLCBkb20sICZ2bWNlX3doaWxlX21vbml0b3IpICkKKyAgICB7CisgICAgICAgIFBFUlJPUigi
RXJyb3Igd2hlbiBlbmQgdm1jZSBtb25pdG9yXG4iKTsKKyAgICAgICAgZ290byBvdXQ7CisgICAg
fQorICAgIGVsc2UgaWYgKCB2bWNlX3doaWxlX21vbml0b3IgPT0gLTEgKQorICAgIHsKKyAgICAg
ICAgZnByaW50ZihzdGRlcnIsICJ2TUNFIG9jY3VycmVkLCBhYm9ydCB0aGlzIHRpbWUgYW5kIHRy
eSBsYXRlci5cbiIpOworICAgICAgICBnb3RvIG91dDsKKyAgICB9CisKICAgICAvKiBBZnRlciBs
YXN0X2l0ZXIsIGJ1ZmZlciB0aGUgcmVzdCBvZiBwYWdlYnVmICYgdGFpbGJ1ZiBkYXRhIGludG8g
YQogICAgICAqIHNlcGFyYXRlIG91dHB1dCBidWZmZXIgYW5kIGZsdXNoIGl0IGFmdGVyIHRoZSBj
b21wcmVzc2VkIHBhZ2UgY2h1bmtzLgogICAgICAqLwpkaWZmIC1yIGU3MWM0YmRjYzA1YSB0b29s
cy9saWJ4Yy94ZW5jdHJsLmgKLS0tIGEvdG9vbHMvbGlieGMveGVuY3RybC5oCVdlZCBTZXAgMTkg
MjM6Mjc6NDAgMjAxMiArMDgwMAorKysgYi90b29scy9saWJ4Yy94ZW5jdHJsLmgJVGh1IFNlcCAy
MCAwMDowMDoxNyAyMDEyICswODAwCkBAIC01NzUsNiArNTc1LDI2IEBACiAgICAgICAgICAgICAg
ICAgICAgICAgICAgIHhjX2RvbWFpbmluZm9fdCAqaW5mbyk7CiAKIC8qKgorICogVGhpcyBmdW5j
dGlvbiBzdGFydCBtb25pdG9yIHZtY2UgZXZlbnQuCisgKiBAcGFybSB4Y2ggYSBoYW5kbGUgdG8g
YW4gb3BlbiBoeXBlcnZpc29yIGludGVyZmFjZQorICogQHBhcm0gZG9taWQgdGhlIGRvbWFpbiBp
ZCBtb25pdG9yZWQKKyAqIEByZXR1cm4gMCBvbiBzdWNjZXNzLCAtMSBvbiBmYWlsdXJlCisgKi8K
K2ludCB4Y19kb21haW5fdm1jZV9tb25pdG9yX3N0YXJ0KHhjX2ludGVyZmFjZSAqeGNoLAorICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgdWludDMyX3QgZG9taWQpOworCisvKioKKyAq
IFRoaXMgZnVuY3Rpb24gZW5kIG1vbml0b3Igdm1jZSBldmVudAorICogQHBhcm0geGNoIGEgaGFu
ZGxlIHRvIGFuIG9wZW4gaHlwZXJ2aXNvciBpbnRlcmZhY2UKKyAqIEBwYXJtIGRvbWlkIHRoZSBk
b21haW4gaWQgbW9uaXRvcmVkCisgKiBAcGFybSB2bWNlX3doaWxlX21pZ3JhdGUgYSBwb2ludGVy
IHJldHVybiB3aGV0aGVyIHZNQ0Ugb2NjdXIgd2hlbiBtaWdyYXRlIAorICogQHJldHVybiAwIG9u
IHN1Y2Nlc3MsIC0xIG9uIGZhaWx1cmUKKyAqLworaW50IHhjX2RvbWFpbl92bWNlX21vbml0b3Jf
ZW5kKHhjX2ludGVyZmFjZSAqeGNoLAorICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHVp
bnQzMl90IGRvbWlkLAorICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHNpZ25lZCBjaGFy
ICp2bWNlX3doaWxlX21vbml0b3IpOworCisvKioKICAqIFRoaXMgZnVuY3Rpb24gcmV0dXJucyBp
bmZvcm1hdGlvbiBhYm91dCB0aGUgY29udGV4dCBvZiBhIGh2bSBkb21haW4KICAqIEBwYXJtIHhj
aCBhIGhhbmRsZSB0byBhbiBvcGVuIGh5cGVydmlzb3IgaW50ZXJmYWNlCiAgKiBAcGFybSBkb21p
ZCB0aGUgZG9tYWluIHRvIGdldCBpbmZvcm1hdGlvbiBmcm9tCmRpZmYgLXIgZTcxYzRiZGNjMDVh
IHhlbi9hcmNoL3g4Ni9jcHUvbWNoZWNrL21jZV9pbnRlbC5jCi0tLSBhL3hlbi9hcmNoL3g4Ni9j
cHUvbWNoZWNrL21jZV9pbnRlbC5jCVdlZCBTZXAgMTkgMjM6Mjc6NDAgMjAxMiArMDgwMAorKysg
Yi94ZW4vYXJjaC94ODYvY3B1L21jaGVjay9tY2VfaW50ZWwuYwlUaHUgU2VwIDIwIDAwOjAwOjE3
IDIwMTIgKzA4MDAKQEAgLTM1OCw2ICszNTgsMTIgQEAKICAgICAgICAgICAgICAgICAgICAgZ290
byB2bWNlX2ZhaWxlZDsKICAgICAgICAgICAgICAgICB9CiAKKyAgICAgICAgICAgICAgICBpZiAo
IHVubGlrZWx5KGQtPmFyY2gudm1jZV9tb25pdG9yKSApCisgICAgICAgICAgICAgICAgeworICAg
ICAgICAgICAgICAgICAgICAvKiB2TUNFIG9jY3VyIHdoZW4gZ3Vlc3QgbWlncmF0aW9uICovCisg
ICAgICAgICAgICAgICAgICAgIGQtPmFyY2gudm1jZV9tb25pdG9yID0gLTE7CisgICAgICAgICAg
ICAgICAgfQorCiAgICAgICAgICAgICAgICAgLyogV2Ugd2lsbCBpbmplY3Qgdk1DRSB0byBET01V
Ki8KICAgICAgICAgICAgICAgICBpZiAoIGluamVjdF92bWNlKGQpIDwgMCApCiAgICAgICAgICAg
ICAgICAgewpkaWZmIC1yIGU3MWM0YmRjYzA1YSB4ZW4vYXJjaC94ODYvZG9tY3RsLmMKLS0tIGEv
eGVuL2FyY2gveDg2L2RvbWN0bC5jCVdlZCBTZXAgMTkgMjM6Mjc6NDAgMjAxMiArMDgwMAorKysg
Yi94ZW4vYXJjaC94ODYvZG9tY3RsLmMJVGh1IFNlcCAyMCAwMDowMDoxNyAyMDEyICswODAwCkBA
IC0xNTE0LDYgKzE1MTQsNDAgQEAKICAgICB9CiAgICAgYnJlYWs7CiAKKyAgICBjYXNlIFhFTl9E
T01DVExfdm1jZV9tb25pdG9yX3N0YXJ0OgorICAgIHsKKyAgICAgICAgc3RydWN0IGRvbWFpbiAq
ZDsKKworICAgICAgICBkID0gcmN1X2xvY2tfZG9tYWluX2J5X2lkKGRvbWN0bC0+ZG9tYWluKTsK
KyAgICAgICAgaWYgKCBkICE9IE5VTEwgKQorICAgICAgICB7CisgICAgICAgICAgICBkLT5hcmNo
LnZtY2VfbW9uaXRvciA9IDE7CisgICAgICAgICAgICByY3VfdW5sb2NrX2RvbWFpbihkKTsKKyAg
ICAgICAgfQorICAgICAgICBlbHNlCisgICAgICAgICAgICByZXQgPSAtRVNSQ0g7CisgICAgfQor
ICAgIGJyZWFrOworCisgICAgY2FzZSBYRU5fRE9NQ1RMX3ZtY2VfbW9uaXRvcl9lbmQ6CisgICAg
eworICAgICAgICBzdHJ1Y3QgZG9tYWluICpkOworCisgICAgICAgIGQgPSByY3VfbG9ja19kb21h
aW5fYnlfaWQoZG9tY3RsLT5kb21haW4pOworICAgICAgICBpZiAoIGQgIT0gTlVMTCkKKyAgICAg
ICAgeworICAgICAgICAgICAgZG9tY3RsLT51LnZtY2VfbW9uaXRvci52bWNlX3doaWxlX21vbml0
b3IgPQorICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBkLT5hcmNoLnZtY2Vf
bW9uaXRvcjsKKyAgICAgICAgICAgIGQtPmFyY2gudm1jZV9tb25pdG9yID0gMDsKKyAgICAgICAg
ICAgIHJjdV91bmxvY2tfZG9tYWluKGQpOworICAgICAgICAgICAgaWYgKCBjb3B5X3RvX2d1ZXN0
KHVfZG9tY3RsLCBkb21jdGwsIDEpICkKKyAgICAgICAgICAgICAgICByZXQgPSAtRUZBVUxUOwor
ICAgICAgICB9CisgICAgICAgIGVsc2UKKyAgICAgICAgICAgIHJldCA9IC1FU1JDSDsKKyAgICB9
CisgICAgYnJlYWs7CisKICAgICBkZWZhdWx0OgogICAgICAgICByZXQgPSBpb21tdV9kb19kb21j
dGwoZG9tY3RsLCB1X2RvbWN0bCk7CiAgICAgICAgIGJyZWFrOwpkaWZmIC1yIGU3MWM0YmRjYzA1
YSB4ZW4vaW5jbHVkZS9hc20teDg2L2RvbWFpbi5oCi0tLSBhL3hlbi9pbmNsdWRlL2FzbS14ODYv
ZG9tYWluLmgJV2VkIFNlcCAxOSAyMzoyNzo0MCAyMDEyICswODAwCisrKyBiL3hlbi9pbmNsdWRl
L2FzbS14ODYvZG9tYWluLmgJVGh1IFNlcCAyMCAwMDowMDoxNyAyMDEyICswODAwCkBAIC0yNzks
NiArMjc5LDExIEBACiAgICAgYm9vbF90IGhhc18zMmJpdF9zaGluZm87CiAgICAgLyogRG9tYWlu
IGNhbm5vdCBoYW5kbGUgc3B1cmlvdXMgcGFnZSBmYXVsdHM/ICovCiAgICAgYm9vbF90IHN1cHBy
ZXNzX3NwdXJpb3VzX3BhZ2VfZmF1bHRzOworICAgIC8qIE1vbml0b3JpbmcgZ3Vlc3QgbWVtb3J5
IGNvcHkgb2YgbWlncmF0aW9uCisgICAgICogPSAwIC0gbm90IG1vbml0b3JpbmcKKyAgICAgKiA+
IDAgLSBtb25pdG9yaW5nCisgICAgICogPCAwIC0gdk1DRSBvY2N1cnJlZCB3aGlsZSBtb25pdG9y
aW5nICovCisgICAgczggdm1jZV9tb25pdG9yOwogCiAgICAgLyogQ29udGludWFibGUgZG9tYWlu
X3JlbGlucXVpc2hfcmVzb3VyY2VzKCkuICovCiAgICAgZW51bSB7CmRpZmYgLXIgZTcxYzRiZGNj
MDVhIHhlbi9pbmNsdWRlL3B1YmxpYy9kb21jdGwuaAotLS0gYS94ZW4vaW5jbHVkZS9wdWJsaWMv
ZG9tY3RsLmgJV2VkIFNlcCAxOSAyMzoyNzo0MCAyMDEyICswODAwCisrKyBiL3hlbi9pbmNsdWRl
L3B1YmxpYy9kb21jdGwuaAlUaHUgU2VwIDIwIDAwOjAwOjE3IDIwMTIgKzA4MDAKQEAgLTgyOCw2
ICs4MjgsMTIgQEAKIHR5cGVkZWYgc3RydWN0IHhlbl9kb21jdGxfc2V0X2FjY2Vzc19yZXF1aXJl
ZCB4ZW5fZG9tY3RsX3NldF9hY2Nlc3NfcmVxdWlyZWRfdDsKIERFRklORV9YRU5fR1VFU1RfSEFO
RExFKHhlbl9kb21jdGxfc2V0X2FjY2Vzc19yZXF1aXJlZF90KTsKIAorc3RydWN0IHhlbl9kb21j
dGxfdm1jZV9tb25pdG9yIHsKKyAgICBzaWduZWQgY2hhciB2bWNlX3doaWxlX21vbml0b3I7Cit9
OwordHlwZWRlZiBzdHJ1Y3QgeGVuX2RvbWN0bF92bWNlX21vbml0b3IgeGVuX2RvbWN0bF92bWNl
X21vbml0b3JfdDsKK0RFRklORV9YRU5fR1VFU1RfSEFORExFKHhlbl9kb21jdGxfdm1jZV9tb25p
dG9yX3QpOworCiBzdHJ1Y3QgeGVuX2RvbWN0bCB7CiAgICAgdWludDMyX3QgY21kOwogI2RlZmlu
ZSBYRU5fRE9NQ1RMX2NyZWF0ZWRvbWFpbiAgICAgICAgICAgICAgICAgICAxCkBAIC04OTMsNiAr
ODk5LDggQEAKICNkZWZpbmUgWEVOX0RPTUNUTF9zZXRfYWNjZXNzX3JlcXVpcmVkICAgICAgICAg
ICA2NAogI2RlZmluZSBYRU5fRE9NQ1RMX2F1ZGl0X3AybSAgICAgICAgICAgICAgICAgICAgIDY1
CiAjZGVmaW5lIFhFTl9ET01DVExfc2V0X3ZpcnFfaGFuZGxlciAgICAgICAgICAgICAgNjYKKyNk
ZWZpbmUgWEVOX0RPTUNUTF92bWNlX21vbml0b3Jfc3RhcnQgICAgICAgICAgICA2NworI2RlZmlu
ZSBYRU5fRE9NQ1RMX3ZtY2VfbW9uaXRvcl9lbmQgICAgICAgICAgICAgIDY4CiAjZGVmaW5lIFhF
Tl9ET01DVExfZ2Ric3hfZ3Vlc3RtZW1pbyAgICAgICAgICAgIDEwMDAKICNkZWZpbmUgWEVOX0RP
TUNUTF9nZGJzeF9wYXVzZXZjcHUgICAgICAgICAgICAgMTAwMQogI2RlZmluZSBYRU5fRE9NQ1RM
X2dkYnN4X3VucGF1c2V2Y3B1ICAgICAgICAgICAxMDAyCkBAIC05NDcsNiArOTU1LDcgQEAKICAg
ICAgICAgc3RydWN0IHhlbl9kb21jdGxfc2V0X2FjY2Vzc19yZXF1aXJlZCBhY2Nlc3NfcmVxdWly
ZWQ7CiAgICAgICAgIHN0cnVjdCB4ZW5fZG9tY3RsX2F1ZGl0X3AybSAgICAgICAgIGF1ZGl0X3Ay
bTsKICAgICAgICAgc3RydWN0IHhlbl9kb21jdGxfc2V0X3ZpcnFfaGFuZGxlciAgc2V0X3ZpcnFf
aGFuZGxlcjsKKyAgICAgICAgc3RydWN0IHhlbl9kb21jdGxfdm1jZV9tb25pdG9yICAgICAgdm1j
ZV9tb25pdG9yOwogICAgICAgICBzdHJ1Y3QgeGVuX2RvbWN0bF9nZGJzeF9tZW1pbyAgICAgICBn
ZGJzeF9ndWVzdF9tZW1pbzsKICAgICAgICAgc3RydWN0IHhlbl9kb21jdGxfZ2Ric3hfcGF1c2V1
bnBfdmNwdSBnZGJzeF9wYXVzZXVucF92Y3B1OwogICAgICAgICBzdHJ1Y3QgeGVuX2RvbWN0bF9n
ZGJzeF9kb21zdGF0dXMgICBnZGJzeF9kb21zdGF0dXM7Cg==

--_003_DE8DF0795D48FD4CA783C40EC829233533ABA1SHSMSX101ccrcorpi_
Content-Type: application/octet-stream;
	name="5_vmce_migration_pfntype_broken.patch"
Content-Description: 5_vmce_migration_pfntype_broken.patch
Content-Disposition: attachment;
	filename="5_vmce_migration_pfntype_broken.patch"; size=8499;
	creation-date="Wed, 26 Sep 2012 03:09:24 GMT";
	modification-date="Wed, 19 Sep 2012 15:27:52 GMT"
Content-Transfer-Encoding: base64

WDg2L3ZNQ0U6IGd1ZXN0IGJyb2tlbiBwYWdlIGhhbmRsaW5nIHdoZW4gbWlncmF0aW9uCgpUaGlz
IHBhdGNoIGlzIHVzZWQgdG8gaGFuZGxlIGd1ZXN0IGJyb2tlbiBwYWdlIHdoZW4gbWlncmF0aW9u
LgoKQXQgc2VuZGVyLCB0aGUgYnJva2VuIHBhZ2Ugd291bGQgbm90IGJlIG1hcHBlZCwgYW5kIHRo
ZSBlcnJvciBwYWdlCmNvbnRlbnQgd291bGQgbm90IGJlIGNvcGllZCB0byB0YXJnZXQsIG90aGVy
d2lzZSBpdCBtYXkgdHJpZ2dlciBtb3JlCnNlcmlvdXMgZXJyb3IgKGkuZS4gU1JBUiBlcnJvciku
IFdoaWxlIGl0cyBwZm5fdHlwZSBhbmQgcGZuIG51bWJlcgp3b3VsZCBiZSB0cmFuc2ZlcnJlZCB0
byB0YXJnZXQgc28gdGhhdCB0YXJnZXQgdGFrZSBhcHByb3ByaWF0ZSBhY3Rpb24uCgpBdCB0YXJn
ZXQsIGl0IHdvdWxkIHNldCBwMm0gYXMgcDJtX3JhbV9icm9rZW4gZm9yIGJyb2tlbiBwYWdlLCBz
byB0aGF0CmlmIGd1ZXN0IGFjY2VzcyB0aGUgYnJva2VuIHBhZ2UgYWdhaW4sIGl0IHdvdWxkIGtp
bGwgZ3Vlc3QgYXMgZXhwZWN0ZWQuCgpTaWduZWQtb2ZmLWJ5OiBMaXUsIEppbnNvbmcgPGppbnNv
bmcubGl1QGludGVsLmNvbT4KCmRpZmYgLXIgYTFkMTA2ZDFhZWM4IHRvb2xzL2xpYnhjL3hjX2Rv
bWFpbi5jCi0tLSBhL3Rvb2xzL2xpYnhjL3hjX2RvbWFpbi5jCVdlZCBTZXAgMTkgMDM6MzE6MzEg
MjAxMiArMDgwMAorKysgYi90b29scy9saWJ4Yy94Y19kb21haW4uYwlXZWQgU2VwIDE5IDA0OjIy
OjI2IDIwMTIgKzA4MDAKQEAgLTMxNCw2ICszMTQsMjIgQEAKICAgICByZXR1cm4gcmV0ID8gLTEg
OiAwOwogfQogCisvKiBzZXQgYnJva2VuIHBhZ2UgcDJtICovCitpbnQgeGNfc2V0X2Jyb2tlbl9w
YWdlX3AybSh4Y19pbnRlcmZhY2UgKnhjaCwKKyAgICAgICAgICAgICAgICAgICAgICAgICAgIHVp
bnQzMl90IGRvbWlkLAorICAgICAgICAgICAgICAgICAgICAgICAgICAgdW5zaWduZWQgbG9uZyBw
Zm4pCit7CisgICAgaW50IHJldDsKKyAgICBERUNMQVJFX0RPTUNUTDsKKworICAgIGRvbWN0bC5j
bWQgPSBYRU5fRE9NQ1RMX3NldF9icm9rZW5fcGFnZV9wMm07CisgICAgZG9tY3RsLmRvbWFpbiA9
IChkb21pZF90KWRvbWlkOworICAgIGRvbWN0bC51LnNldF9icm9rZW5fcGFnZV9wMm0ucGZuID0g
cGZuOworICAgIHJldCA9IGRvX2RvbWN0bCh4Y2gsICZkb21jdGwpOworCisgICAgcmV0dXJuIHJl
dCA/IC0xIDogMDsKK30KKwogLyogZ2V0IGluZm8gZnJvbSBodm0gZ3Vlc3QgZm9yIHNhdmUgKi8K
IGludCB4Y19kb21haW5faHZtX2dldGNvbnRleHQoeGNfaW50ZXJmYWNlICp4Y2gsCiAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgIHVpbnQzMl90IGRvbWlkLApkaWZmIC1yIGExZDEwNmQxYWVj
OCB0b29scy9saWJ4Yy94Y19kb21haW5fcmVzdG9yZS5jCi0tLSBhL3Rvb2xzL2xpYnhjL3hjX2Rv
bWFpbl9yZXN0b3JlLmMJV2VkIFNlcCAxOSAwMzozMTozMSAyMDEyICswODAwCisrKyBiL3Rvb2xz
L2xpYnhjL3hjX2RvbWFpbl9yZXN0b3JlLmMJV2VkIFNlcCAxOSAwNDoyMjoyNiAyMDEyICswODAw
CkBAIC05NjIsOSArOTYyLDE1IEBACiAKICAgICBjb3VudHBhZ2VzID0gY291bnQ7CiAgICAgZm9y
IChpID0gb2xkY291bnQ7IGkgPCBidWYtPm5yX3BhZ2VzOyArK2kpCi0gICAgICAgIGlmICgoYnVm
LT5wZm5fdHlwZXNbaV0gJiBYRU5fRE9NQ1RMX1BGSU5GT19MVEFCX01BU0spID09IFhFTl9ET01D
VExfUEZJTkZPX1hUQUIKLSAgICAgICAgICAgIHx8KGJ1Zi0+cGZuX3R5cGVzW2ldICYgWEVOX0RP
TUNUTF9QRklORk9fTFRBQl9NQVNLKSA9PSBYRU5fRE9NQ1RMX1BGSU5GT19YQUxMT0MpCisgICAg
eworICAgICAgICB1bnNpZ25lZCBsb25nIHBhZ2V0eXBlOworCisgICAgICAgIHBhZ2V0eXBlID0g
YnVmLT5wZm5fdHlwZXNbaV0gJiBYRU5fRE9NQ1RMX1BGSU5GT19MVEFCX01BU0s7CisgICAgICAg
IGlmICggcGFnZXR5cGUgPT0gWEVOX0RPTUNUTF9QRklORk9fWFRBQiB8fAorICAgICAgICAgICAg
IHBhZ2V0eXBlID09IFhFTl9ET01DVExfUEZJTkZPX0JST0tFTiB8fAorICAgICAgICAgICAgIHBh
Z2V0eXBlID09IFhFTl9ET01DVExfUEZJTkZPX1hBTExPQyApCiAgICAgICAgICAgICAtLWNvdW50
cGFnZXM7CisgICAgfQogCiAgICAgaWYgKCFjb3VudHBhZ2VzKQogICAgICAgICByZXR1cm4gY291
bnQ7CkBAIC0xMjAwLDYgKzEyMDYsMTcgQEAKICAgICAgICAgICAgIC8qIGEgYm9ndXMvdW5tYXBw
ZWQvYWxsb2NhdGUtb25seSBwYWdlOiBza2lwIGl0ICovCiAgICAgICAgICAgICBjb250aW51ZTsK
IAorICAgICAgICBpZiAoIHBhZ2V0eXBlID09IFhFTl9ET01DVExfUEZJTkZPX0JST0tFTiApCisg
ICAgICAgIHsKKyAgICAgICAgICAgIGlmICggeGNfc2V0X2Jyb2tlbl9wYWdlX3AybSh4Y2gsIGRv
bSwgcGZuKSApCisgICAgICAgICAgICB7CisgICAgICAgICAgICAgICAgRVJST1IoIlNldCBwMm0g
Zm9yIGJyb2tlbiBwYWdlIGZhaWwsICIKKyAgICAgICAgICAgICAgICAgICAgICAiZG9tPSVkLCBw
Zm49JWx4XG4iLCBkb20sIHBmbik7CisgICAgICAgICAgICAgICAgZ290byBlcnJfbWFwcGVkOwor
ICAgICAgICAgICAgfQorICAgICAgICAgICAgY29udGludWU7CisgICAgICAgIH0KKwogICAgICAg
ICBpZiAocGZuX2VycltpXSkKICAgICAgICAgewogICAgICAgICAgICAgRVJST1IoInVuZXhwZWN0
ZWQgUEZOIG1hcHBpbmcgZmFpbHVyZSBwZm4gJWx4IG1hcF9tZm4gJWx4IHAybV9tZm4gJWx4IiwK
ZGlmZiAtciBhMWQxMDZkMWFlYzggdG9vbHMvbGlieGMveGNfZG9tYWluX3NhdmUuYwotLS0gYS90
b29scy9saWJ4Yy94Y19kb21haW5fc2F2ZS5jCVdlZCBTZXAgMTkgMDM6MzE6MzEgMjAxMiArMDgw
MAorKysgYi90b29scy9saWJ4Yy94Y19kb21haW5fc2F2ZS5jCVdlZCBTZXAgMTkgMDQ6MjI6MjYg
MjAxMiArMDgwMApAQCAtMTI4NSw2ICsxMjg1LDEzIEBACiAgICAgICAgICAgICAgICAgaWYgKCAh
aHZtICkKICAgICAgICAgICAgICAgICAgICAgZ21mbiA9IHBmbl90b19tZm4oZ21mbik7CiAKKyAg
ICAgICAgICAgICAgICBpZiAoIHBmbl90eXBlW2pdID09IFhFTl9ET01DVExfUEZJTkZPX0JST0tF
TiApCisgICAgICAgICAgICAgICAgeworICAgICAgICAgICAgICAgICAgICBwZm5fdHlwZVtqXSB8
PSBwZm5fYmF0Y2hbal07CisgICAgICAgICAgICAgICAgICAgICsrcnVuOworICAgICAgICAgICAg
ICAgICAgICBjb250aW51ZTsKKyAgICAgICAgICAgICAgICB9CisKICAgICAgICAgICAgICAgICBp
ZiAoIHBmbl9lcnJbal0gKQogICAgICAgICAgICAgICAgIHsKICAgICAgICAgICAgICAgICAgICAg
aWYgKCBwZm5fdHlwZVtqXSA9PSBYRU5fRE9NQ1RMX1BGSU5GT19YVEFCICkKQEAgLTEzNzksOCAr
MTM4NiwxMiBAQAogICAgICAgICAgICAgICAgICAgICB9CiAgICAgICAgICAgICAgICAgfQogCi0g
ICAgICAgICAgICAgICAgLyogc2tpcCBwYWdlcyB0aGF0IGFyZW4ndCBwcmVzZW50IG9yIGFyZSBh
bGxvYy1vbmx5ICovCisgICAgICAgICAgICAgICAgLyoKKyAgICAgICAgICAgICAgICAgKiBza2lw
IHBhZ2VzIHRoYXQgYXJlbid0IHByZXNlbnQsCisgICAgICAgICAgICAgICAgICogb3IgYXJlIGJy
b2tlbiwgb3IgYXJlIGFsbG9jLW9ubHkKKyAgICAgICAgICAgICAgICAgKi8KICAgICAgICAgICAg
ICAgICBpZiAoIHBhZ2V0eXBlID09IFhFTl9ET01DVExfUEZJTkZPX1hUQUIKKyAgICAgICAgICAg
ICAgICAgICAgfHwgcGFnZXR5cGUgPT0gWEVOX0RPTUNUTF9QRklORk9fQlJPS0VOCiAgICAgICAg
ICAgICAgICAgICAgIHx8IHBhZ2V0eXBlID09IFhFTl9ET01DVExfUEZJTkZPX1hBTExPQyApCiAg
ICAgICAgICAgICAgICAgICAgIGNvbnRpbnVlOwogCmRpZmYgLXIgYTFkMTA2ZDFhZWM4IHRvb2xz
L2xpYnhjL3hlbmN0cmwuaAotLS0gYS90b29scy9saWJ4Yy94ZW5jdHJsLmgJV2VkIFNlcCAxOSAw
MzozMTozMSAyMDEyICswODAwCisrKyBiL3Rvb2xzL2xpYnhjL3hlbmN0cmwuaAlXZWQgU2VwIDE5
IDA0OjIyOjI2IDIwMTIgKzA4MDAKQEAgLTU5MSw2ICs1OTEsMTcgQEAKICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICBzaWduZWQgY2hhciAqdm1jZV93aGlsZV9tb25pdG9yKTsKIAogLyoq
CisgKiBUaGlzIGZ1bmN0aW9uIHNldCBwMm0gZm9yIGJyb2tlbiBwYWdlCisgKiAmcGFybSB4Y2gg
YSBoYW5kbGUgdG8gYW4gb3BlbiBoeXBlcnZpc29yIGludGVyZmFjZQorICogQHBhcm0gZG9taWQg
dGhlIGRvbWFpbiBpZCB3aGljaCBicm9rZW4gcGFnZSBiZWxvbmcgdG8KKyAqIEBwYXJtIHBmbiB0
aGUgcGZuIG51bWJlciBvZiB0aGUgYnJva2VuIHBhZ2UKKyAqIEByZXR1cm4gMCBvbiBzdWNjZXNz
LCAtMSBvbiBmYWlsdXJlCisgKi8KK2ludCB4Y19zZXRfYnJva2VuX3BhZ2VfcDJtKHhjX2ludGVy
ZmFjZSAqeGNoLAorICAgICAgICAgICAgICAgICAgICAgICAgICAgdWludDMyX3QgZG9taWQsCisg
ICAgICAgICAgICAgICAgICAgICAgICAgICB1bnNpZ25lZCBsb25nIHBmbik7CisKKy8qKgogICog
VGhpcyBmdW5jdGlvbiByZXR1cm5zIGluZm9ybWF0aW9uIGFib3V0IHRoZSBjb250ZXh0IG9mIGEg
aHZtIGRvbWFpbgogICogQHBhcm0geGNoIGEgaGFuZGxlIHRvIGFuIG9wZW4gaHlwZXJ2aXNvciBp
bnRlcmZhY2UKICAqIEBwYXJtIGRvbWlkIHRoZSBkb21haW4gdG8gZ2V0IGluZm9ybWF0aW9uIGZy
b20KZGlmZiAtciBhMWQxMDZkMWFlYzggeGVuL2FyY2gveDg2L2RvbWN0bC5jCi0tLSBhL3hlbi9h
cmNoL3g4Ni9kb21jdGwuYwlXZWQgU2VwIDE5IDAzOjMxOjMxIDIwMTIgKzA4MDAKKysrIGIveGVu
L2FyY2gveDg2L2RvbWN0bC5jCVdlZCBTZXAgMTkgMDQ6MjI6MjYgMjAxMiArMDgwMApAQCAtMjA5
LDEyICsyMDksMTggQEAKICAgICAgICAgICAgICAgICBmb3IgKCBqID0gMDsgaiA8IGs7IGorKyAp
CiAgICAgICAgICAgICAgICAgewogICAgICAgICAgICAgICAgICAgICB1bnNpZ25lZCBsb25nIHR5
cGUgPSAwOworICAgICAgICAgICAgICAgICAgICBwMm1fdHlwZV90IHQ7CiAKLSAgICAgICAgICAg
ICAgICAgICAgcGFnZSA9IGdldF9wYWdlX2Zyb21fZ2ZuKGQsIGFycltqXSwgTlVMTCwgUDJNX0FM
TE9DKTsKKyAgICAgICAgICAgICAgICAgICAgcGFnZSA9IGdldF9wYWdlX2Zyb21fZ2ZuKGQsIGFy
cltqXSwgJnQsIFAyTV9BTExPQyk7CiAKICAgICAgICAgICAgICAgICAgICAgaWYgKCB1bmxpa2Vs
eSghcGFnZSkgfHwKICAgICAgICAgICAgICAgICAgICAgICAgICB1bmxpa2VseShpc194ZW5faGVh
cF9wYWdlKHBhZ2UpKSApCi0gICAgICAgICAgICAgICAgICAgICAgICB0eXBlID0gWEVOX0RPTUNU
TF9QRklORk9fWFRBQjsKKyAgICAgICAgICAgICAgICAgICAgeworICAgICAgICAgICAgICAgICAg
ICAgICAgaWYgKCBwMm1faXNfYnJva2VuKHQpICkKKyAgICAgICAgICAgICAgICAgICAgICAgICAg
ICB0eXBlID0gWEVOX0RPTUNUTF9QRklORk9fQlJPS0VOOworICAgICAgICAgICAgICAgICAgICAg
ICAgZWxzZQorICAgICAgICAgICAgICAgICAgICAgICAgICAgIHR5cGUgPSBYRU5fRE9NQ1RMX1BG
SU5GT19YVEFCOworICAgICAgICAgICAgICAgICAgICB9CiAgICAgICAgICAgICAgICAgICAgIGVs
c2UKICAgICAgICAgICAgICAgICAgICAgewogICAgICAgICAgICAgICAgICAgICAgICAgc3dpdGNo
KCBwYWdlLT51LmludXNlLnR5cGVfaW5mbyAmIFBHVF90eXBlX21hc2sgKQpAQCAtMjM1LDYgKzI0
MSw5IEBACiAKICAgICAgICAgICAgICAgICAgICAgICAgIGlmICggcGFnZS0+dS5pbnVzZS50eXBl
X2luZm8gJiBQR1RfcGlubmVkICkKICAgICAgICAgICAgICAgICAgICAgICAgICAgICB0eXBlIHw9
IFhFTl9ET01DVExfUEZJTkZPX0xQSU5UQUI7CisKKyAgICAgICAgICAgICAgICAgICAgICAgIGlm
ICggcGFnZS0+Y291bnRfaW5mbyAmIFBHQ19icm9rZW4gKQorICAgICAgICAgICAgICAgICAgICAg
ICAgICAgIHR5cGUgPSBYRU5fRE9NQ1RMX1BGSU5GT19CUk9LRU47CiAgICAgICAgICAgICAgICAg
ICAgIH0KIAogICAgICAgICAgICAgICAgICAgICBpZiAoIHBhZ2UgKQpAQCAtMTU0OCw2ICsxNTU3
LDI4IEBACiAgICAgfQogICAgIGJyZWFrOwogCisgICAgY2FzZSBYRU5fRE9NQ1RMX3NldF9icm9r
ZW5fcGFnZV9wMm06CisgICAgeworICAgICAgICBzdHJ1Y3QgZG9tYWluICpkOworICAgICAgICBw
Mm1fdHlwZV90IHB0OworICAgICAgICB1bnNpZ25lZCBsb25nIHBmbjsKKworICAgICAgICBkID0g
cmN1X2xvY2tfZG9tYWluX2J5X2lkKGRvbWN0bC0+ZG9tYWluKTsKKyAgICAgICAgaWYgKCBkICE9
IE5VTEwgKQorICAgICAgICB7CisgICAgICAgICAgICBwZm4gPSBkb21jdGwtPnUuc2V0X2Jyb2tl
bl9wYWdlX3AybS5wZm47CisKKyAgICAgICAgICAgIGdldF9nZm5fcXVlcnkoZCwgcGZuLCAmcHQp
OworICAgICAgICAgICAgcDJtX2NoYW5nZV90eXBlKGQsIHBmbiwgcHQsIHAybV9yYW1fYnJva2Vu
KTsKKyAgICAgICAgICAgIHB1dF9nZm4oZCwgcGZuKTsKKworICAgICAgICAgICAgcmN1X3VubG9j
a19kb21haW4oZCk7CisgICAgICAgIH0KKyAgICAgICAgZWxzZQorICAgICAgICAgICAgcmV0ID0g
LUVTUkNIOworICAgIH0KKyAgICBicmVhazsKKwogICAgIGRlZmF1bHQ6CiAgICAgICAgIHJldCA9
IGlvbW11X2RvX2RvbWN0bChkb21jdGwsIHVfZG9tY3RsKTsKICAgICAgICAgYnJlYWs7CmRpZmYg
LXIgYTFkMTA2ZDFhZWM4IHhlbi9pbmNsdWRlL3B1YmxpYy9kb21jdGwuaAotLS0gYS94ZW4vaW5j
bHVkZS9wdWJsaWMvZG9tY3RsLmgJV2VkIFNlcCAxOSAwMzozMTozMSAyMDEyICswODAwCisrKyBi
L3hlbi9pbmNsdWRlL3B1YmxpYy9kb21jdGwuaAlXZWQgU2VwIDE5IDA0OjIyOjI2IDIwMTIgKzA4
MDAKQEAgLTEzNiw2ICsxMzYsNyBAQAogI2RlZmluZSBYRU5fRE9NQ1RMX1BGSU5GT19MUElOVEFC
ICgweDFVPDwzMSkKICNkZWZpbmUgWEVOX0RPTUNUTF9QRklORk9fWFRBQiAgICAoMHhmVTw8Mjgp
IC8qIGludmFsaWQgcGFnZSAqLwogI2RlZmluZSBYRU5fRE9NQ1RMX1BGSU5GT19YQUxMT0MgICgw
eGVVPDwyOCkgLyogYWxsb2NhdGUtb25seSBwYWdlICovCisjZGVmaW5lIFhFTl9ET01DVExfUEZJ
TkZPX0JST0tFTiAgKDB4ZFU8PDI4KSAvKiBicm9rZW4gcGFnZSAqLwogI2RlZmluZSBYRU5fRE9N
Q1RMX1BGSU5GT19QQUdFRFRBQiAoMHg4VTw8MjgpCiAjZGVmaW5lIFhFTl9ET01DVExfUEZJTkZP
X0xUQUJfTUFTSyAoMHhmVTw8MjgpCiAKQEAgLTgzNCw2ICs4MzUsMTIgQEAKIHR5cGVkZWYgc3Ry
dWN0IHhlbl9kb21jdGxfdm1jZV9tb25pdG9yIHhlbl9kb21jdGxfdm1jZV9tb25pdG9yX3Q7CiBE
RUZJTkVfWEVOX0dVRVNUX0hBTkRMRSh4ZW5fZG9tY3RsX3ZtY2VfbW9uaXRvcl90KTsKIAorc3Ry
dWN0IHhlbl9kb21jdGxfc2V0X2Jyb2tlbl9wYWdlX3AybSB7CisgICAgdWludDY0X3QgcGZuOwor
fTsKK3R5cGVkZWYgc3RydWN0IHhlbl9kb21jdGxfc2V0X2Jyb2tlbl9wYWdlX3AybSB4ZW5fZG9t
Y3RsX3NldF9icm9rZW5fcGFnZV9wMm1fdDsKK0RFRklORV9YRU5fR1VFU1RfSEFORExFKHhlbl9k
b21jdGxfc2V0X2Jyb2tlbl9wYWdlX3AybV90KTsKKwogc3RydWN0IHhlbl9kb21jdGwgewogICAg
IHVpbnQzMl90IGNtZDsKICNkZWZpbmUgWEVOX0RPTUNUTF9jcmVhdGVkb21haW4gICAgICAgICAg
ICAgICAgICAgMQpAQCAtOTAxLDYgKzkwOCw3IEBACiAjZGVmaW5lIFhFTl9ET01DVExfc2V0X3Zp
cnFfaGFuZGxlciAgICAgICAgICAgICAgNjYKICNkZWZpbmUgWEVOX0RPTUNUTF92bWNlX21vbml0
b3Jfc3RhcnQgICAgICAgICAgICA2NwogI2RlZmluZSBYRU5fRE9NQ1RMX3ZtY2VfbW9uaXRvcl9l
bmQgICAgICAgICAgICAgIDY4CisjZGVmaW5lIFhFTl9ET01DVExfc2V0X2Jyb2tlbl9wYWdlX3Ay
bSAgICAgICAgICAgNjkKICNkZWZpbmUgWEVOX0RPTUNUTF9nZGJzeF9ndWVzdG1lbWlvICAgICAg
ICAgICAgMTAwMAogI2RlZmluZSBYRU5fRE9NQ1RMX2dkYnN4X3BhdXNldmNwdSAgICAgICAgICAg
ICAxMDAxCiAjZGVmaW5lIFhFTl9ET01DVExfZ2Ric3hfdW5wYXVzZXZjcHUgICAgICAgICAgIDEw
MDIKQEAgLTk1Nyw2ICs5NjUsNyBAQAogICAgICAgICBzdHJ1Y3QgeGVuX2RvbWN0bF9zZXRfdmly
cV9oYW5kbGVyICBzZXRfdmlycV9oYW5kbGVyOwogICAgICAgICBzdHJ1Y3QgeGVuX2RvbWN0bF92
bWNlX21vbml0b3IgICAgICB2bWNlX21vbml0b3I7CiAgICAgICAgIHN0cnVjdCB4ZW5fZG9tY3Rs
X2dkYnN4X21lbWlvICAgICAgIGdkYnN4X2d1ZXN0X21lbWlvOworICAgICAgICBzdHJ1Y3QgeGVu
X2RvbWN0bF9zZXRfYnJva2VuX3BhZ2VfcDJtIHNldF9icm9rZW5fcGFnZV9wMm07CiAgICAgICAg
IHN0cnVjdCB4ZW5fZG9tY3RsX2dkYnN4X3BhdXNldW5wX3ZjcHUgZ2Ric3hfcGF1c2V1bnBfdmNw
dTsKICAgICAgICAgc3RydWN0IHhlbl9kb21jdGxfZ2Ric3hfZG9tc3RhdHVzICAgZ2Ric3hfZG9t
c3RhdHVzOwogICAgICAgICB1aW50OF90ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBwYWRb
MTI4XTsK

--_003_DE8DF0795D48FD4CA783C40EC829233533ABA1SHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--_003_DE8DF0795D48FD4CA783C40EC829233533ABA1SHSMSX101ccrcorpi_--


From xen-devel-bounces@lists.xen.org Wed Sep 26 05:37:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Sep 2012 05:37:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGkIb-0003E5-0E; Wed, 26 Sep 2012 05:36:41 +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 1TGkIY-0003E0-JB
	for xen-devel@lists.xensource.com; Wed, 26 Sep 2012 05:36:39 +0000
Received: from [85.158.139.211:52780] by server-11.bemta-5.messagelabs.com id
	CF/D5-13866-56492605; Wed, 26 Sep 2012 05:36:37 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-9.tower-206.messagelabs.com!1348637795!18464081!1
X-Originating-IP: [192.55.52.93]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjkzID0+IDM0Njg3Mw==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30138 invoked from network); 26 Sep 2012 05:36:36 -0000
Received: from mga11.intel.com (HELO mga11.intel.com) (192.55.52.93)
	by server-9.tower-206.messagelabs.com with SMTP;
	26 Sep 2012 05:36:36 -0000
Received: from fmsmga002.fm.intel.com ([10.253.24.26])
	by fmsmga102.fm.intel.com with ESMTP; 25 Sep 2012 22:36:35 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.80,487,1344236400"; d="scan'208";a="226818194"
Received: from fmsmsx106.amr.corp.intel.com ([10.19.9.37])
	by fmsmga002.fm.intel.com with ESMTP; 25 Sep 2012 22:36:34 -0700
Received: from fmsmsx151.amr.corp.intel.com (10.19.17.220) by
	FMSMSX106.amr.corp.intel.com (10.19.9.37) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Tue, 25 Sep 2012 22:36:34 -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; Tue, 25 Sep 2012 22:36:34 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.239]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.175]) with mapi id
	14.01.0355.002; Wed, 26 Sep 2012 13:36:32 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: "Ian.Campbell@citrix.com" <Ian.Campbell@citrix.com>, Ian Jackson
	<Ian.Jackson@eu.citrix.com>, "xen-devel@lists.xensource.com"
	<xen-devel@lists.xensource.com>
Thread-Topic: Patch review: vMCE patches 4/5 and 5/5
Thread-Index: Ac2bqOKLxDZSgggOQfiF3hPIJjEB6g==
Date: Wed, 26 Sep 2012 05:36:32 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC829233533ABA1@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="_003_DE8DF0795D48FD4CA783C40EC829233533ABA1SHSMSX101ccrcorpi_"
MIME-Version: 1.0
Cc: Christoph Egger <Christoph.Egger@amd.com>, "keir@xen.org" <keir@xen.org>,
	Jan Beulich <JBeulich@suse.com>
Subject: [Xen-devel] Patch review: vMCE patches 4/5 and 5/5
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--_003_DE8DF0795D48FD4CA783C40EC829233533ABA1SHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi,

Attached are 2 patches of Xen vMCE, it mainly handle vMCE when live migrate=
.
Patch4/5 used to handle vMCE while live migrate.
Patch5/5 used handle vMCE before live migrate.

These 2 patches involves some tools logic, would you please kindly help me =
to review them?

Thanks,
Jinsong=

--_003_DE8DF0795D48FD4CA783C40EC829233533ABA1SHSMSX101ccrcorpi_
Content-Type: application/octet-stream; name="4_vmce_when_migrate.patch"
Content-Description: 4_vmce_when_migrate.patch
Content-Disposition: attachment; filename="4_vmce_when_migrate.patch";
	size=7729; creation-date="Wed, 26 Sep 2012 03:09:24 GMT";
	modification-date="Wed, 19 Sep 2012 16:00:18 GMT"
Content-Transfer-Encoding: base64

WGVuL01DRTogQWJvcnQgbGl2ZSBtaWdyYXRpb24gd2hlbiB2TUNFIG9jY3VyCgpUaGlzIHBhdGNo
IG1vbml0b3IgdGhlIGNyaXRpY2FsIGFyZWEgb2YgbGl2ZSBtaWdyYXRpb24gKGZyb20gdk1DRSBw
b2ludCBvZiB2aWV3LAp0aGUgY29weXBhZ2VzIHN0YWdlIG9mIG1pZ3JhdGlvbiBpcyB0aGUgY3Jp
dGljYWwgYXJlYSB3aGlsZSBvdGhlciBhcmVhcyBhcmUgbm90KS4KCklmIGEgdk1DRSBvY2N1ciBh
dCB0aGUgY3JpdGljYWwgYXJlYSBvZiBsaXZlIG1pZ3JhdGlvbiwgYWJvcnQgYW5kIHRyeSBtaWdy
YXRpb24gbGF0ZXIuCgpTaWduZWQtb2ZmLWJ5OiBMaXUsIEppbnNvbmcgPGppbnNvbmcubGl1QGlu
dGVsLmNvbT4KCmRpZmYgLXIgZTcxYzRiZGNjMDVhIHRvb2xzL2xpYnhjL3hjX2RvbWFpbi5jCi0t
LSBhL3Rvb2xzL2xpYnhjL3hjX2RvbWFpbi5jCVdlZCBTZXAgMTkgMjM6Mjc6NDAgMjAxMiArMDgw
MAorKysgYi90b29scy9saWJ4Yy94Y19kb21haW4uYwlUaHUgU2VwIDIwIDAwOjAwOjE3IDIwMTIg
KzA4MDAKQEAgLTI4Myw2ICsyODMsMzcgQEAKICAgICByZXR1cm4gcmV0OwogfQogCisvKiBTdGFy
dCB2bWNlIG1vbml0b3IgKi8KK2ludCB4Y19kb21haW5fdm1jZV9tb25pdG9yX3N0YXJ0KHhjX2lu
dGVyZmFjZSAqeGNoLAorICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgdWludDMyX3Qg
ZG9taWQpCit7CisgICAgaW50IHJldDsKKyAgICBERUNMQVJFX0RPTUNUTDsKKworICAgIGRvbWN0
bC5jbWQgPSBYRU5fRE9NQ1RMX3ZtY2VfbW9uaXRvcl9zdGFydDsKKyAgICBkb21jdGwuZG9tYWlu
ID0gKGRvbWlkX3QpZG9taWQ7CisgICAgcmV0ID0gZG9fZG9tY3RsKHhjaCwgJmRvbWN0bCk7CisK
KyAgICByZXR1cm4gcmV0ID8gLTEgOiAwOworfQorCisvKiBFbmQgdm1jZSBtb25pdG9yICovCitp
bnQgeGNfZG9tYWluX3ZtY2VfbW9uaXRvcl9lbmQoeGNfaW50ZXJmYWNlICp4Y2gsCisgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgdWludDMyX3QgZG9taWQsCisgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgc2lnbmVkIGNoYXIgKnZtY2Vfd2hpbGVfbW9uaXRvcikKK3sKKyAgICBp
bnQgcmV0OworICAgIERFQ0xBUkVfRE9NQ1RMOworCisgICAgZG9tY3RsLmNtZCA9IFhFTl9ET01D
VExfdm1jZV9tb25pdG9yX2VuZDsKKyAgICBkb21jdGwuZG9tYWluID0gKGRvbWlkX3QpZG9taWQ7
CisgICAgcmV0ID0gZG9fZG9tY3RsKHhjaCwgJmRvbWN0bCk7CisgICAgaWYgKCAhcmV0ICkKKyAg
ICAgICAgKnZtY2Vfd2hpbGVfbW9uaXRvciA9IGRvbWN0bC51LnZtY2VfbW9uaXRvci52bWNlX3do
aWxlX21vbml0b3I7CisKKyAgICByZXR1cm4gcmV0ID8gLTEgOiAwOworfQorCiAvKiBnZXQgaW5m
byBmcm9tIGh2bSBndWVzdCBmb3Igc2F2ZSAqLwogaW50IHhjX2RvbWFpbl9odm1fZ2V0Y29udGV4
dCh4Y19pbnRlcmZhY2UgKnhjaCwKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgdWludDMy
X3QgZG9taWQsCmRpZmYgLXIgZTcxYzRiZGNjMDVhIHRvb2xzL2xpYnhjL3hjX2RvbWFpbl9zYXZl
LmMKLS0tIGEvdG9vbHMvbGlieGMveGNfZG9tYWluX3NhdmUuYwlXZWQgU2VwIDE5IDIzOjI3OjQw
IDIwMTIgKzA4MDAKKysrIGIvdG9vbHMvbGlieGMveGNfZG9tYWluX3NhdmUuYwlUaHUgU2VwIDIw
IDAwOjAwOjE3IDIwMTIgKzA4MDAKQEAgLTg5NSw2ICs4OTUsOCBAQAogICAgICAqLwogICAgIGlu
dCBjb21wcmVzc2luZyA9IDA7CiAKKyAgICBzaWduZWQgY2hhciB2bWNlX3doaWxlX21vbml0b3Ig
PSAwOworCiAgICAgaW50IGNvbXBsZXRlZCA9IDA7CiAKICAgICBpZiAoIGh2bSAmJiAhY2FsbGJh
Y2tzLT5zd2l0Y2hfcWVtdV9sb2dkaXJ0eSApCkBAIC0xMTA5LDYgKzExMTEsMTIgQEAKICAgICAg
ICAgZ290byBvdXQ7CiAgICAgfQogCisgICAgaWYgKCB4Y19kb21haW5fdm1jZV9tb25pdG9yX3N0
YXJ0KHhjaCwgZG9tKSApCisgICAgeworICAgICAgICBQRVJST1IoIkVycm9yIHdoZW4gc3RhcnQg
dm1jZSBtb25pdG9yXG4iKTsKKyAgICAgICAgZ290byBvdXQ7CisgICAgfQorCiAgIGNvcHlwYWdl
czoKICNkZWZpbmUgd3JleGFjdChmZCwgYnVmLCBsZW4pIHdyaXRlX2J1ZmZlcih4Y2gsIGxhc3Rf
aXRlciwgb2IsIChmZCksIChidWYpLCAobGVuKSkKICNkZWZpbmUgd3J1bmNhY2hlZChmZCwgbGl2
ZSwgYnVmLCBsZW4pIHdyaXRlX3VuY2FjaGVkKHhjaCwgbGFzdF9pdGVyLCBvYiwgKGZkKSwgKGJ1
ZiksIChsZW4pKQpAQCAtMTU3MSw2ICsxNTc5LDE3IEBACiAKICAgICBEUFJJTlRGKCJBbGwgbWVt
b3J5IGlzIHNhdmVkXG4iKTsKIAorICAgIGlmICggeGNfZG9tYWluX3ZtY2VfbW9uaXRvcl9lbmQo
eGNoLCBkb20sICZ2bWNlX3doaWxlX21vbml0b3IpICkKKyAgICB7CisgICAgICAgIFBFUlJPUigi
RXJyb3Igd2hlbiBlbmQgdm1jZSBtb25pdG9yXG4iKTsKKyAgICAgICAgZ290byBvdXQ7CisgICAg
fQorICAgIGVsc2UgaWYgKCB2bWNlX3doaWxlX21vbml0b3IgPT0gLTEgKQorICAgIHsKKyAgICAg
ICAgZnByaW50ZihzdGRlcnIsICJ2TUNFIG9jY3VycmVkLCBhYm9ydCB0aGlzIHRpbWUgYW5kIHRy
eSBsYXRlci5cbiIpOworICAgICAgICBnb3RvIG91dDsKKyAgICB9CisKICAgICAvKiBBZnRlciBs
YXN0X2l0ZXIsIGJ1ZmZlciB0aGUgcmVzdCBvZiBwYWdlYnVmICYgdGFpbGJ1ZiBkYXRhIGludG8g
YQogICAgICAqIHNlcGFyYXRlIG91dHB1dCBidWZmZXIgYW5kIGZsdXNoIGl0IGFmdGVyIHRoZSBj
b21wcmVzc2VkIHBhZ2UgY2h1bmtzLgogICAgICAqLwpkaWZmIC1yIGU3MWM0YmRjYzA1YSB0b29s
cy9saWJ4Yy94ZW5jdHJsLmgKLS0tIGEvdG9vbHMvbGlieGMveGVuY3RybC5oCVdlZCBTZXAgMTkg
MjM6Mjc6NDAgMjAxMiArMDgwMAorKysgYi90b29scy9saWJ4Yy94ZW5jdHJsLmgJVGh1IFNlcCAy
MCAwMDowMDoxNyAyMDEyICswODAwCkBAIC01NzUsNiArNTc1LDI2IEBACiAgICAgICAgICAgICAg
ICAgICAgICAgICAgIHhjX2RvbWFpbmluZm9fdCAqaW5mbyk7CiAKIC8qKgorICogVGhpcyBmdW5j
dGlvbiBzdGFydCBtb25pdG9yIHZtY2UgZXZlbnQuCisgKiBAcGFybSB4Y2ggYSBoYW5kbGUgdG8g
YW4gb3BlbiBoeXBlcnZpc29yIGludGVyZmFjZQorICogQHBhcm0gZG9taWQgdGhlIGRvbWFpbiBp
ZCBtb25pdG9yZWQKKyAqIEByZXR1cm4gMCBvbiBzdWNjZXNzLCAtMSBvbiBmYWlsdXJlCisgKi8K
K2ludCB4Y19kb21haW5fdm1jZV9tb25pdG9yX3N0YXJ0KHhjX2ludGVyZmFjZSAqeGNoLAorICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgdWludDMyX3QgZG9taWQpOworCisvKioKKyAq
IFRoaXMgZnVuY3Rpb24gZW5kIG1vbml0b3Igdm1jZSBldmVudAorICogQHBhcm0geGNoIGEgaGFu
ZGxlIHRvIGFuIG9wZW4gaHlwZXJ2aXNvciBpbnRlcmZhY2UKKyAqIEBwYXJtIGRvbWlkIHRoZSBk
b21haW4gaWQgbW9uaXRvcmVkCisgKiBAcGFybSB2bWNlX3doaWxlX21pZ3JhdGUgYSBwb2ludGVy
IHJldHVybiB3aGV0aGVyIHZNQ0Ugb2NjdXIgd2hlbiBtaWdyYXRlIAorICogQHJldHVybiAwIG9u
IHN1Y2Nlc3MsIC0xIG9uIGZhaWx1cmUKKyAqLworaW50IHhjX2RvbWFpbl92bWNlX21vbml0b3Jf
ZW5kKHhjX2ludGVyZmFjZSAqeGNoLAorICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHVp
bnQzMl90IGRvbWlkLAorICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHNpZ25lZCBjaGFy
ICp2bWNlX3doaWxlX21vbml0b3IpOworCisvKioKICAqIFRoaXMgZnVuY3Rpb24gcmV0dXJucyBp
bmZvcm1hdGlvbiBhYm91dCB0aGUgY29udGV4dCBvZiBhIGh2bSBkb21haW4KICAqIEBwYXJtIHhj
aCBhIGhhbmRsZSB0byBhbiBvcGVuIGh5cGVydmlzb3IgaW50ZXJmYWNlCiAgKiBAcGFybSBkb21p
ZCB0aGUgZG9tYWluIHRvIGdldCBpbmZvcm1hdGlvbiBmcm9tCmRpZmYgLXIgZTcxYzRiZGNjMDVh
IHhlbi9hcmNoL3g4Ni9jcHUvbWNoZWNrL21jZV9pbnRlbC5jCi0tLSBhL3hlbi9hcmNoL3g4Ni9j
cHUvbWNoZWNrL21jZV9pbnRlbC5jCVdlZCBTZXAgMTkgMjM6Mjc6NDAgMjAxMiArMDgwMAorKysg
Yi94ZW4vYXJjaC94ODYvY3B1L21jaGVjay9tY2VfaW50ZWwuYwlUaHUgU2VwIDIwIDAwOjAwOjE3
IDIwMTIgKzA4MDAKQEAgLTM1OCw2ICszNTgsMTIgQEAKICAgICAgICAgICAgICAgICAgICAgZ290
byB2bWNlX2ZhaWxlZDsKICAgICAgICAgICAgICAgICB9CiAKKyAgICAgICAgICAgICAgICBpZiAo
IHVubGlrZWx5KGQtPmFyY2gudm1jZV9tb25pdG9yKSApCisgICAgICAgICAgICAgICAgeworICAg
ICAgICAgICAgICAgICAgICAvKiB2TUNFIG9jY3VyIHdoZW4gZ3Vlc3QgbWlncmF0aW9uICovCisg
ICAgICAgICAgICAgICAgICAgIGQtPmFyY2gudm1jZV9tb25pdG9yID0gLTE7CisgICAgICAgICAg
ICAgICAgfQorCiAgICAgICAgICAgICAgICAgLyogV2Ugd2lsbCBpbmplY3Qgdk1DRSB0byBET01V
Ki8KICAgICAgICAgICAgICAgICBpZiAoIGluamVjdF92bWNlKGQpIDwgMCApCiAgICAgICAgICAg
ICAgICAgewpkaWZmIC1yIGU3MWM0YmRjYzA1YSB4ZW4vYXJjaC94ODYvZG9tY3RsLmMKLS0tIGEv
eGVuL2FyY2gveDg2L2RvbWN0bC5jCVdlZCBTZXAgMTkgMjM6Mjc6NDAgMjAxMiArMDgwMAorKysg
Yi94ZW4vYXJjaC94ODYvZG9tY3RsLmMJVGh1IFNlcCAyMCAwMDowMDoxNyAyMDEyICswODAwCkBA
IC0xNTE0LDYgKzE1MTQsNDAgQEAKICAgICB9CiAgICAgYnJlYWs7CiAKKyAgICBjYXNlIFhFTl9E
T01DVExfdm1jZV9tb25pdG9yX3N0YXJ0OgorICAgIHsKKyAgICAgICAgc3RydWN0IGRvbWFpbiAq
ZDsKKworICAgICAgICBkID0gcmN1X2xvY2tfZG9tYWluX2J5X2lkKGRvbWN0bC0+ZG9tYWluKTsK
KyAgICAgICAgaWYgKCBkICE9IE5VTEwgKQorICAgICAgICB7CisgICAgICAgICAgICBkLT5hcmNo
LnZtY2VfbW9uaXRvciA9IDE7CisgICAgICAgICAgICByY3VfdW5sb2NrX2RvbWFpbihkKTsKKyAg
ICAgICAgfQorICAgICAgICBlbHNlCisgICAgICAgICAgICByZXQgPSAtRVNSQ0g7CisgICAgfQor
ICAgIGJyZWFrOworCisgICAgY2FzZSBYRU5fRE9NQ1RMX3ZtY2VfbW9uaXRvcl9lbmQ6CisgICAg
eworICAgICAgICBzdHJ1Y3QgZG9tYWluICpkOworCisgICAgICAgIGQgPSByY3VfbG9ja19kb21h
aW5fYnlfaWQoZG9tY3RsLT5kb21haW4pOworICAgICAgICBpZiAoIGQgIT0gTlVMTCkKKyAgICAg
ICAgeworICAgICAgICAgICAgZG9tY3RsLT51LnZtY2VfbW9uaXRvci52bWNlX3doaWxlX21vbml0
b3IgPQorICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBkLT5hcmNoLnZtY2Vf
bW9uaXRvcjsKKyAgICAgICAgICAgIGQtPmFyY2gudm1jZV9tb25pdG9yID0gMDsKKyAgICAgICAg
ICAgIHJjdV91bmxvY2tfZG9tYWluKGQpOworICAgICAgICAgICAgaWYgKCBjb3B5X3RvX2d1ZXN0
KHVfZG9tY3RsLCBkb21jdGwsIDEpICkKKyAgICAgICAgICAgICAgICByZXQgPSAtRUZBVUxUOwor
ICAgICAgICB9CisgICAgICAgIGVsc2UKKyAgICAgICAgICAgIHJldCA9IC1FU1JDSDsKKyAgICB9
CisgICAgYnJlYWs7CisKICAgICBkZWZhdWx0OgogICAgICAgICByZXQgPSBpb21tdV9kb19kb21j
dGwoZG9tY3RsLCB1X2RvbWN0bCk7CiAgICAgICAgIGJyZWFrOwpkaWZmIC1yIGU3MWM0YmRjYzA1
YSB4ZW4vaW5jbHVkZS9hc20teDg2L2RvbWFpbi5oCi0tLSBhL3hlbi9pbmNsdWRlL2FzbS14ODYv
ZG9tYWluLmgJV2VkIFNlcCAxOSAyMzoyNzo0MCAyMDEyICswODAwCisrKyBiL3hlbi9pbmNsdWRl
L2FzbS14ODYvZG9tYWluLmgJVGh1IFNlcCAyMCAwMDowMDoxNyAyMDEyICswODAwCkBAIC0yNzks
NiArMjc5LDExIEBACiAgICAgYm9vbF90IGhhc18zMmJpdF9zaGluZm87CiAgICAgLyogRG9tYWlu
IGNhbm5vdCBoYW5kbGUgc3B1cmlvdXMgcGFnZSBmYXVsdHM/ICovCiAgICAgYm9vbF90IHN1cHBy
ZXNzX3NwdXJpb3VzX3BhZ2VfZmF1bHRzOworICAgIC8qIE1vbml0b3JpbmcgZ3Vlc3QgbWVtb3J5
IGNvcHkgb2YgbWlncmF0aW9uCisgICAgICogPSAwIC0gbm90IG1vbml0b3JpbmcKKyAgICAgKiA+
IDAgLSBtb25pdG9yaW5nCisgICAgICogPCAwIC0gdk1DRSBvY2N1cnJlZCB3aGlsZSBtb25pdG9y
aW5nICovCisgICAgczggdm1jZV9tb25pdG9yOwogCiAgICAgLyogQ29udGludWFibGUgZG9tYWlu
X3JlbGlucXVpc2hfcmVzb3VyY2VzKCkuICovCiAgICAgZW51bSB7CmRpZmYgLXIgZTcxYzRiZGNj
MDVhIHhlbi9pbmNsdWRlL3B1YmxpYy9kb21jdGwuaAotLS0gYS94ZW4vaW5jbHVkZS9wdWJsaWMv
ZG9tY3RsLmgJV2VkIFNlcCAxOSAyMzoyNzo0MCAyMDEyICswODAwCisrKyBiL3hlbi9pbmNsdWRl
L3B1YmxpYy9kb21jdGwuaAlUaHUgU2VwIDIwIDAwOjAwOjE3IDIwMTIgKzA4MDAKQEAgLTgyOCw2
ICs4MjgsMTIgQEAKIHR5cGVkZWYgc3RydWN0IHhlbl9kb21jdGxfc2V0X2FjY2Vzc19yZXF1aXJl
ZCB4ZW5fZG9tY3RsX3NldF9hY2Nlc3NfcmVxdWlyZWRfdDsKIERFRklORV9YRU5fR1VFU1RfSEFO
RExFKHhlbl9kb21jdGxfc2V0X2FjY2Vzc19yZXF1aXJlZF90KTsKIAorc3RydWN0IHhlbl9kb21j
dGxfdm1jZV9tb25pdG9yIHsKKyAgICBzaWduZWQgY2hhciB2bWNlX3doaWxlX21vbml0b3I7Cit9
OwordHlwZWRlZiBzdHJ1Y3QgeGVuX2RvbWN0bF92bWNlX21vbml0b3IgeGVuX2RvbWN0bF92bWNl
X21vbml0b3JfdDsKK0RFRklORV9YRU5fR1VFU1RfSEFORExFKHhlbl9kb21jdGxfdm1jZV9tb25p
dG9yX3QpOworCiBzdHJ1Y3QgeGVuX2RvbWN0bCB7CiAgICAgdWludDMyX3QgY21kOwogI2RlZmlu
ZSBYRU5fRE9NQ1RMX2NyZWF0ZWRvbWFpbiAgICAgICAgICAgICAgICAgICAxCkBAIC04OTMsNiAr
ODk5LDggQEAKICNkZWZpbmUgWEVOX0RPTUNUTF9zZXRfYWNjZXNzX3JlcXVpcmVkICAgICAgICAg
ICA2NAogI2RlZmluZSBYRU5fRE9NQ1RMX2F1ZGl0X3AybSAgICAgICAgICAgICAgICAgICAgIDY1
CiAjZGVmaW5lIFhFTl9ET01DVExfc2V0X3ZpcnFfaGFuZGxlciAgICAgICAgICAgICAgNjYKKyNk
ZWZpbmUgWEVOX0RPTUNUTF92bWNlX21vbml0b3Jfc3RhcnQgICAgICAgICAgICA2NworI2RlZmlu
ZSBYRU5fRE9NQ1RMX3ZtY2VfbW9uaXRvcl9lbmQgICAgICAgICAgICAgIDY4CiAjZGVmaW5lIFhF
Tl9ET01DVExfZ2Ric3hfZ3Vlc3RtZW1pbyAgICAgICAgICAgIDEwMDAKICNkZWZpbmUgWEVOX0RP
TUNUTF9nZGJzeF9wYXVzZXZjcHUgICAgICAgICAgICAgMTAwMQogI2RlZmluZSBYRU5fRE9NQ1RM
X2dkYnN4X3VucGF1c2V2Y3B1ICAgICAgICAgICAxMDAyCkBAIC05NDcsNiArOTU1LDcgQEAKICAg
ICAgICAgc3RydWN0IHhlbl9kb21jdGxfc2V0X2FjY2Vzc19yZXF1aXJlZCBhY2Nlc3NfcmVxdWly
ZWQ7CiAgICAgICAgIHN0cnVjdCB4ZW5fZG9tY3RsX2F1ZGl0X3AybSAgICAgICAgIGF1ZGl0X3Ay
bTsKICAgICAgICAgc3RydWN0IHhlbl9kb21jdGxfc2V0X3ZpcnFfaGFuZGxlciAgc2V0X3ZpcnFf
aGFuZGxlcjsKKyAgICAgICAgc3RydWN0IHhlbl9kb21jdGxfdm1jZV9tb25pdG9yICAgICAgdm1j
ZV9tb25pdG9yOwogICAgICAgICBzdHJ1Y3QgeGVuX2RvbWN0bF9nZGJzeF9tZW1pbyAgICAgICBn
ZGJzeF9ndWVzdF9tZW1pbzsKICAgICAgICAgc3RydWN0IHhlbl9kb21jdGxfZ2Ric3hfcGF1c2V1
bnBfdmNwdSBnZGJzeF9wYXVzZXVucF92Y3B1OwogICAgICAgICBzdHJ1Y3QgeGVuX2RvbWN0bF9n
ZGJzeF9kb21zdGF0dXMgICBnZGJzeF9kb21zdGF0dXM7Cg==

--_003_DE8DF0795D48FD4CA783C40EC829233533ABA1SHSMSX101ccrcorpi_
Content-Type: application/octet-stream;
	name="5_vmce_migration_pfntype_broken.patch"
Content-Description: 5_vmce_migration_pfntype_broken.patch
Content-Disposition: attachment;
	filename="5_vmce_migration_pfntype_broken.patch"; size=8499;
	creation-date="Wed, 26 Sep 2012 03:09:24 GMT";
	modification-date="Wed, 19 Sep 2012 15:27:52 GMT"
Content-Transfer-Encoding: base64

WDg2L3ZNQ0U6IGd1ZXN0IGJyb2tlbiBwYWdlIGhhbmRsaW5nIHdoZW4gbWlncmF0aW9uCgpUaGlz
IHBhdGNoIGlzIHVzZWQgdG8gaGFuZGxlIGd1ZXN0IGJyb2tlbiBwYWdlIHdoZW4gbWlncmF0aW9u
LgoKQXQgc2VuZGVyLCB0aGUgYnJva2VuIHBhZ2Ugd291bGQgbm90IGJlIG1hcHBlZCwgYW5kIHRo
ZSBlcnJvciBwYWdlCmNvbnRlbnQgd291bGQgbm90IGJlIGNvcGllZCB0byB0YXJnZXQsIG90aGVy
d2lzZSBpdCBtYXkgdHJpZ2dlciBtb3JlCnNlcmlvdXMgZXJyb3IgKGkuZS4gU1JBUiBlcnJvciku
IFdoaWxlIGl0cyBwZm5fdHlwZSBhbmQgcGZuIG51bWJlcgp3b3VsZCBiZSB0cmFuc2ZlcnJlZCB0
byB0YXJnZXQgc28gdGhhdCB0YXJnZXQgdGFrZSBhcHByb3ByaWF0ZSBhY3Rpb24uCgpBdCB0YXJn
ZXQsIGl0IHdvdWxkIHNldCBwMm0gYXMgcDJtX3JhbV9icm9rZW4gZm9yIGJyb2tlbiBwYWdlLCBz
byB0aGF0CmlmIGd1ZXN0IGFjY2VzcyB0aGUgYnJva2VuIHBhZ2UgYWdhaW4sIGl0IHdvdWxkIGtp
bGwgZ3Vlc3QgYXMgZXhwZWN0ZWQuCgpTaWduZWQtb2ZmLWJ5OiBMaXUsIEppbnNvbmcgPGppbnNv
bmcubGl1QGludGVsLmNvbT4KCmRpZmYgLXIgYTFkMTA2ZDFhZWM4IHRvb2xzL2xpYnhjL3hjX2Rv
bWFpbi5jCi0tLSBhL3Rvb2xzL2xpYnhjL3hjX2RvbWFpbi5jCVdlZCBTZXAgMTkgMDM6MzE6MzEg
MjAxMiArMDgwMAorKysgYi90b29scy9saWJ4Yy94Y19kb21haW4uYwlXZWQgU2VwIDE5IDA0OjIy
OjI2IDIwMTIgKzA4MDAKQEAgLTMxNCw2ICszMTQsMjIgQEAKICAgICByZXR1cm4gcmV0ID8gLTEg
OiAwOwogfQogCisvKiBzZXQgYnJva2VuIHBhZ2UgcDJtICovCitpbnQgeGNfc2V0X2Jyb2tlbl9w
YWdlX3AybSh4Y19pbnRlcmZhY2UgKnhjaCwKKyAgICAgICAgICAgICAgICAgICAgICAgICAgIHVp
bnQzMl90IGRvbWlkLAorICAgICAgICAgICAgICAgICAgICAgICAgICAgdW5zaWduZWQgbG9uZyBw
Zm4pCit7CisgICAgaW50IHJldDsKKyAgICBERUNMQVJFX0RPTUNUTDsKKworICAgIGRvbWN0bC5j
bWQgPSBYRU5fRE9NQ1RMX3NldF9icm9rZW5fcGFnZV9wMm07CisgICAgZG9tY3RsLmRvbWFpbiA9
IChkb21pZF90KWRvbWlkOworICAgIGRvbWN0bC51LnNldF9icm9rZW5fcGFnZV9wMm0ucGZuID0g
cGZuOworICAgIHJldCA9IGRvX2RvbWN0bCh4Y2gsICZkb21jdGwpOworCisgICAgcmV0dXJuIHJl
dCA/IC0xIDogMDsKK30KKwogLyogZ2V0IGluZm8gZnJvbSBodm0gZ3Vlc3QgZm9yIHNhdmUgKi8K
IGludCB4Y19kb21haW5faHZtX2dldGNvbnRleHQoeGNfaW50ZXJmYWNlICp4Y2gsCiAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgIHVpbnQzMl90IGRvbWlkLApkaWZmIC1yIGExZDEwNmQxYWVj
OCB0b29scy9saWJ4Yy94Y19kb21haW5fcmVzdG9yZS5jCi0tLSBhL3Rvb2xzL2xpYnhjL3hjX2Rv
bWFpbl9yZXN0b3JlLmMJV2VkIFNlcCAxOSAwMzozMTozMSAyMDEyICswODAwCisrKyBiL3Rvb2xz
L2xpYnhjL3hjX2RvbWFpbl9yZXN0b3JlLmMJV2VkIFNlcCAxOSAwNDoyMjoyNiAyMDEyICswODAw
CkBAIC05NjIsOSArOTYyLDE1IEBACiAKICAgICBjb3VudHBhZ2VzID0gY291bnQ7CiAgICAgZm9y
IChpID0gb2xkY291bnQ7IGkgPCBidWYtPm5yX3BhZ2VzOyArK2kpCi0gICAgICAgIGlmICgoYnVm
LT5wZm5fdHlwZXNbaV0gJiBYRU5fRE9NQ1RMX1BGSU5GT19MVEFCX01BU0spID09IFhFTl9ET01D
VExfUEZJTkZPX1hUQUIKLSAgICAgICAgICAgIHx8KGJ1Zi0+cGZuX3R5cGVzW2ldICYgWEVOX0RP
TUNUTF9QRklORk9fTFRBQl9NQVNLKSA9PSBYRU5fRE9NQ1RMX1BGSU5GT19YQUxMT0MpCisgICAg
eworICAgICAgICB1bnNpZ25lZCBsb25nIHBhZ2V0eXBlOworCisgICAgICAgIHBhZ2V0eXBlID0g
YnVmLT5wZm5fdHlwZXNbaV0gJiBYRU5fRE9NQ1RMX1BGSU5GT19MVEFCX01BU0s7CisgICAgICAg
IGlmICggcGFnZXR5cGUgPT0gWEVOX0RPTUNUTF9QRklORk9fWFRBQiB8fAorICAgICAgICAgICAg
IHBhZ2V0eXBlID09IFhFTl9ET01DVExfUEZJTkZPX0JST0tFTiB8fAorICAgICAgICAgICAgIHBh
Z2V0eXBlID09IFhFTl9ET01DVExfUEZJTkZPX1hBTExPQyApCiAgICAgICAgICAgICAtLWNvdW50
cGFnZXM7CisgICAgfQogCiAgICAgaWYgKCFjb3VudHBhZ2VzKQogICAgICAgICByZXR1cm4gY291
bnQ7CkBAIC0xMjAwLDYgKzEyMDYsMTcgQEAKICAgICAgICAgICAgIC8qIGEgYm9ndXMvdW5tYXBw
ZWQvYWxsb2NhdGUtb25seSBwYWdlOiBza2lwIGl0ICovCiAgICAgICAgICAgICBjb250aW51ZTsK
IAorICAgICAgICBpZiAoIHBhZ2V0eXBlID09IFhFTl9ET01DVExfUEZJTkZPX0JST0tFTiApCisg
ICAgICAgIHsKKyAgICAgICAgICAgIGlmICggeGNfc2V0X2Jyb2tlbl9wYWdlX3AybSh4Y2gsIGRv
bSwgcGZuKSApCisgICAgICAgICAgICB7CisgICAgICAgICAgICAgICAgRVJST1IoIlNldCBwMm0g
Zm9yIGJyb2tlbiBwYWdlIGZhaWwsICIKKyAgICAgICAgICAgICAgICAgICAgICAiZG9tPSVkLCBw
Zm49JWx4XG4iLCBkb20sIHBmbik7CisgICAgICAgICAgICAgICAgZ290byBlcnJfbWFwcGVkOwor
ICAgICAgICAgICAgfQorICAgICAgICAgICAgY29udGludWU7CisgICAgICAgIH0KKwogICAgICAg
ICBpZiAocGZuX2VycltpXSkKICAgICAgICAgewogICAgICAgICAgICAgRVJST1IoInVuZXhwZWN0
ZWQgUEZOIG1hcHBpbmcgZmFpbHVyZSBwZm4gJWx4IG1hcF9tZm4gJWx4IHAybV9tZm4gJWx4IiwK
ZGlmZiAtciBhMWQxMDZkMWFlYzggdG9vbHMvbGlieGMveGNfZG9tYWluX3NhdmUuYwotLS0gYS90
b29scy9saWJ4Yy94Y19kb21haW5fc2F2ZS5jCVdlZCBTZXAgMTkgMDM6MzE6MzEgMjAxMiArMDgw
MAorKysgYi90b29scy9saWJ4Yy94Y19kb21haW5fc2F2ZS5jCVdlZCBTZXAgMTkgMDQ6MjI6MjYg
MjAxMiArMDgwMApAQCAtMTI4NSw2ICsxMjg1LDEzIEBACiAgICAgICAgICAgICAgICAgaWYgKCAh
aHZtICkKICAgICAgICAgICAgICAgICAgICAgZ21mbiA9IHBmbl90b19tZm4oZ21mbik7CiAKKyAg
ICAgICAgICAgICAgICBpZiAoIHBmbl90eXBlW2pdID09IFhFTl9ET01DVExfUEZJTkZPX0JST0tF
TiApCisgICAgICAgICAgICAgICAgeworICAgICAgICAgICAgICAgICAgICBwZm5fdHlwZVtqXSB8
PSBwZm5fYmF0Y2hbal07CisgICAgICAgICAgICAgICAgICAgICsrcnVuOworICAgICAgICAgICAg
ICAgICAgICBjb250aW51ZTsKKyAgICAgICAgICAgICAgICB9CisKICAgICAgICAgICAgICAgICBp
ZiAoIHBmbl9lcnJbal0gKQogICAgICAgICAgICAgICAgIHsKICAgICAgICAgICAgICAgICAgICAg
aWYgKCBwZm5fdHlwZVtqXSA9PSBYRU5fRE9NQ1RMX1BGSU5GT19YVEFCICkKQEAgLTEzNzksOCAr
MTM4NiwxMiBAQAogICAgICAgICAgICAgICAgICAgICB9CiAgICAgICAgICAgICAgICAgfQogCi0g
ICAgICAgICAgICAgICAgLyogc2tpcCBwYWdlcyB0aGF0IGFyZW4ndCBwcmVzZW50IG9yIGFyZSBh
bGxvYy1vbmx5ICovCisgICAgICAgICAgICAgICAgLyoKKyAgICAgICAgICAgICAgICAgKiBza2lw
IHBhZ2VzIHRoYXQgYXJlbid0IHByZXNlbnQsCisgICAgICAgICAgICAgICAgICogb3IgYXJlIGJy
b2tlbiwgb3IgYXJlIGFsbG9jLW9ubHkKKyAgICAgICAgICAgICAgICAgKi8KICAgICAgICAgICAg
ICAgICBpZiAoIHBhZ2V0eXBlID09IFhFTl9ET01DVExfUEZJTkZPX1hUQUIKKyAgICAgICAgICAg
ICAgICAgICAgfHwgcGFnZXR5cGUgPT0gWEVOX0RPTUNUTF9QRklORk9fQlJPS0VOCiAgICAgICAg
ICAgICAgICAgICAgIHx8IHBhZ2V0eXBlID09IFhFTl9ET01DVExfUEZJTkZPX1hBTExPQyApCiAg
ICAgICAgICAgICAgICAgICAgIGNvbnRpbnVlOwogCmRpZmYgLXIgYTFkMTA2ZDFhZWM4IHRvb2xz
L2xpYnhjL3hlbmN0cmwuaAotLS0gYS90b29scy9saWJ4Yy94ZW5jdHJsLmgJV2VkIFNlcCAxOSAw
MzozMTozMSAyMDEyICswODAwCisrKyBiL3Rvb2xzL2xpYnhjL3hlbmN0cmwuaAlXZWQgU2VwIDE5
IDA0OjIyOjI2IDIwMTIgKzA4MDAKQEAgLTU5MSw2ICs1OTEsMTcgQEAKICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICBzaWduZWQgY2hhciAqdm1jZV93aGlsZV9tb25pdG9yKTsKIAogLyoq
CisgKiBUaGlzIGZ1bmN0aW9uIHNldCBwMm0gZm9yIGJyb2tlbiBwYWdlCisgKiAmcGFybSB4Y2gg
YSBoYW5kbGUgdG8gYW4gb3BlbiBoeXBlcnZpc29yIGludGVyZmFjZQorICogQHBhcm0gZG9taWQg
dGhlIGRvbWFpbiBpZCB3aGljaCBicm9rZW4gcGFnZSBiZWxvbmcgdG8KKyAqIEBwYXJtIHBmbiB0
aGUgcGZuIG51bWJlciBvZiB0aGUgYnJva2VuIHBhZ2UKKyAqIEByZXR1cm4gMCBvbiBzdWNjZXNz
LCAtMSBvbiBmYWlsdXJlCisgKi8KK2ludCB4Y19zZXRfYnJva2VuX3BhZ2VfcDJtKHhjX2ludGVy
ZmFjZSAqeGNoLAorICAgICAgICAgICAgICAgICAgICAgICAgICAgdWludDMyX3QgZG9taWQsCisg
ICAgICAgICAgICAgICAgICAgICAgICAgICB1bnNpZ25lZCBsb25nIHBmbik7CisKKy8qKgogICog
VGhpcyBmdW5jdGlvbiByZXR1cm5zIGluZm9ybWF0aW9uIGFib3V0IHRoZSBjb250ZXh0IG9mIGEg
aHZtIGRvbWFpbgogICogQHBhcm0geGNoIGEgaGFuZGxlIHRvIGFuIG9wZW4gaHlwZXJ2aXNvciBp
bnRlcmZhY2UKICAqIEBwYXJtIGRvbWlkIHRoZSBkb21haW4gdG8gZ2V0IGluZm9ybWF0aW9uIGZy
b20KZGlmZiAtciBhMWQxMDZkMWFlYzggeGVuL2FyY2gveDg2L2RvbWN0bC5jCi0tLSBhL3hlbi9h
cmNoL3g4Ni9kb21jdGwuYwlXZWQgU2VwIDE5IDAzOjMxOjMxIDIwMTIgKzA4MDAKKysrIGIveGVu
L2FyY2gveDg2L2RvbWN0bC5jCVdlZCBTZXAgMTkgMDQ6MjI6MjYgMjAxMiArMDgwMApAQCAtMjA5
LDEyICsyMDksMTggQEAKICAgICAgICAgICAgICAgICBmb3IgKCBqID0gMDsgaiA8IGs7IGorKyAp
CiAgICAgICAgICAgICAgICAgewogICAgICAgICAgICAgICAgICAgICB1bnNpZ25lZCBsb25nIHR5
cGUgPSAwOworICAgICAgICAgICAgICAgICAgICBwMm1fdHlwZV90IHQ7CiAKLSAgICAgICAgICAg
ICAgICAgICAgcGFnZSA9IGdldF9wYWdlX2Zyb21fZ2ZuKGQsIGFycltqXSwgTlVMTCwgUDJNX0FM
TE9DKTsKKyAgICAgICAgICAgICAgICAgICAgcGFnZSA9IGdldF9wYWdlX2Zyb21fZ2ZuKGQsIGFy
cltqXSwgJnQsIFAyTV9BTExPQyk7CiAKICAgICAgICAgICAgICAgICAgICAgaWYgKCB1bmxpa2Vs
eSghcGFnZSkgfHwKICAgICAgICAgICAgICAgICAgICAgICAgICB1bmxpa2VseShpc194ZW5faGVh
cF9wYWdlKHBhZ2UpKSApCi0gICAgICAgICAgICAgICAgICAgICAgICB0eXBlID0gWEVOX0RPTUNU
TF9QRklORk9fWFRBQjsKKyAgICAgICAgICAgICAgICAgICAgeworICAgICAgICAgICAgICAgICAg
ICAgICAgaWYgKCBwMm1faXNfYnJva2VuKHQpICkKKyAgICAgICAgICAgICAgICAgICAgICAgICAg
ICB0eXBlID0gWEVOX0RPTUNUTF9QRklORk9fQlJPS0VOOworICAgICAgICAgICAgICAgICAgICAg
ICAgZWxzZQorICAgICAgICAgICAgICAgICAgICAgICAgICAgIHR5cGUgPSBYRU5fRE9NQ1RMX1BG
SU5GT19YVEFCOworICAgICAgICAgICAgICAgICAgICB9CiAgICAgICAgICAgICAgICAgICAgIGVs
c2UKICAgICAgICAgICAgICAgICAgICAgewogICAgICAgICAgICAgICAgICAgICAgICAgc3dpdGNo
KCBwYWdlLT51LmludXNlLnR5cGVfaW5mbyAmIFBHVF90eXBlX21hc2sgKQpAQCAtMjM1LDYgKzI0
MSw5IEBACiAKICAgICAgICAgICAgICAgICAgICAgICAgIGlmICggcGFnZS0+dS5pbnVzZS50eXBl
X2luZm8gJiBQR1RfcGlubmVkICkKICAgICAgICAgICAgICAgICAgICAgICAgICAgICB0eXBlIHw9
IFhFTl9ET01DVExfUEZJTkZPX0xQSU5UQUI7CisKKyAgICAgICAgICAgICAgICAgICAgICAgIGlm
ICggcGFnZS0+Y291bnRfaW5mbyAmIFBHQ19icm9rZW4gKQorICAgICAgICAgICAgICAgICAgICAg
ICAgICAgIHR5cGUgPSBYRU5fRE9NQ1RMX1BGSU5GT19CUk9LRU47CiAgICAgICAgICAgICAgICAg
ICAgIH0KIAogICAgICAgICAgICAgICAgICAgICBpZiAoIHBhZ2UgKQpAQCAtMTU0OCw2ICsxNTU3
LDI4IEBACiAgICAgfQogICAgIGJyZWFrOwogCisgICAgY2FzZSBYRU5fRE9NQ1RMX3NldF9icm9r
ZW5fcGFnZV9wMm06CisgICAgeworICAgICAgICBzdHJ1Y3QgZG9tYWluICpkOworICAgICAgICBw
Mm1fdHlwZV90IHB0OworICAgICAgICB1bnNpZ25lZCBsb25nIHBmbjsKKworICAgICAgICBkID0g
cmN1X2xvY2tfZG9tYWluX2J5X2lkKGRvbWN0bC0+ZG9tYWluKTsKKyAgICAgICAgaWYgKCBkICE9
IE5VTEwgKQorICAgICAgICB7CisgICAgICAgICAgICBwZm4gPSBkb21jdGwtPnUuc2V0X2Jyb2tl
bl9wYWdlX3AybS5wZm47CisKKyAgICAgICAgICAgIGdldF9nZm5fcXVlcnkoZCwgcGZuLCAmcHQp
OworICAgICAgICAgICAgcDJtX2NoYW5nZV90eXBlKGQsIHBmbiwgcHQsIHAybV9yYW1fYnJva2Vu
KTsKKyAgICAgICAgICAgIHB1dF9nZm4oZCwgcGZuKTsKKworICAgICAgICAgICAgcmN1X3VubG9j
a19kb21haW4oZCk7CisgICAgICAgIH0KKyAgICAgICAgZWxzZQorICAgICAgICAgICAgcmV0ID0g
LUVTUkNIOworICAgIH0KKyAgICBicmVhazsKKwogICAgIGRlZmF1bHQ6CiAgICAgICAgIHJldCA9
IGlvbW11X2RvX2RvbWN0bChkb21jdGwsIHVfZG9tY3RsKTsKICAgICAgICAgYnJlYWs7CmRpZmYg
LXIgYTFkMTA2ZDFhZWM4IHhlbi9pbmNsdWRlL3B1YmxpYy9kb21jdGwuaAotLS0gYS94ZW4vaW5j
bHVkZS9wdWJsaWMvZG9tY3RsLmgJV2VkIFNlcCAxOSAwMzozMTozMSAyMDEyICswODAwCisrKyBi
L3hlbi9pbmNsdWRlL3B1YmxpYy9kb21jdGwuaAlXZWQgU2VwIDE5IDA0OjIyOjI2IDIwMTIgKzA4
MDAKQEAgLTEzNiw2ICsxMzYsNyBAQAogI2RlZmluZSBYRU5fRE9NQ1RMX1BGSU5GT19MUElOVEFC
ICgweDFVPDwzMSkKICNkZWZpbmUgWEVOX0RPTUNUTF9QRklORk9fWFRBQiAgICAoMHhmVTw8Mjgp
IC8qIGludmFsaWQgcGFnZSAqLwogI2RlZmluZSBYRU5fRE9NQ1RMX1BGSU5GT19YQUxMT0MgICgw
eGVVPDwyOCkgLyogYWxsb2NhdGUtb25seSBwYWdlICovCisjZGVmaW5lIFhFTl9ET01DVExfUEZJ
TkZPX0JST0tFTiAgKDB4ZFU8PDI4KSAvKiBicm9rZW4gcGFnZSAqLwogI2RlZmluZSBYRU5fRE9N
Q1RMX1BGSU5GT19QQUdFRFRBQiAoMHg4VTw8MjgpCiAjZGVmaW5lIFhFTl9ET01DVExfUEZJTkZP
X0xUQUJfTUFTSyAoMHhmVTw8MjgpCiAKQEAgLTgzNCw2ICs4MzUsMTIgQEAKIHR5cGVkZWYgc3Ry
dWN0IHhlbl9kb21jdGxfdm1jZV9tb25pdG9yIHhlbl9kb21jdGxfdm1jZV9tb25pdG9yX3Q7CiBE
RUZJTkVfWEVOX0dVRVNUX0hBTkRMRSh4ZW5fZG9tY3RsX3ZtY2VfbW9uaXRvcl90KTsKIAorc3Ry
dWN0IHhlbl9kb21jdGxfc2V0X2Jyb2tlbl9wYWdlX3AybSB7CisgICAgdWludDY0X3QgcGZuOwor
fTsKK3R5cGVkZWYgc3RydWN0IHhlbl9kb21jdGxfc2V0X2Jyb2tlbl9wYWdlX3AybSB4ZW5fZG9t
Y3RsX3NldF9icm9rZW5fcGFnZV9wMm1fdDsKK0RFRklORV9YRU5fR1VFU1RfSEFORExFKHhlbl9k
b21jdGxfc2V0X2Jyb2tlbl9wYWdlX3AybV90KTsKKwogc3RydWN0IHhlbl9kb21jdGwgewogICAg
IHVpbnQzMl90IGNtZDsKICNkZWZpbmUgWEVOX0RPTUNUTF9jcmVhdGVkb21haW4gICAgICAgICAg
ICAgICAgICAgMQpAQCAtOTAxLDYgKzkwOCw3IEBACiAjZGVmaW5lIFhFTl9ET01DVExfc2V0X3Zp
cnFfaGFuZGxlciAgICAgICAgICAgICAgNjYKICNkZWZpbmUgWEVOX0RPTUNUTF92bWNlX21vbml0
b3Jfc3RhcnQgICAgICAgICAgICA2NwogI2RlZmluZSBYRU5fRE9NQ1RMX3ZtY2VfbW9uaXRvcl9l
bmQgICAgICAgICAgICAgIDY4CisjZGVmaW5lIFhFTl9ET01DVExfc2V0X2Jyb2tlbl9wYWdlX3Ay
bSAgICAgICAgICAgNjkKICNkZWZpbmUgWEVOX0RPTUNUTF9nZGJzeF9ndWVzdG1lbWlvICAgICAg
ICAgICAgMTAwMAogI2RlZmluZSBYRU5fRE9NQ1RMX2dkYnN4X3BhdXNldmNwdSAgICAgICAgICAg
ICAxMDAxCiAjZGVmaW5lIFhFTl9ET01DVExfZ2Ric3hfdW5wYXVzZXZjcHUgICAgICAgICAgIDEw
MDIKQEAgLTk1Nyw2ICs5NjUsNyBAQAogICAgICAgICBzdHJ1Y3QgeGVuX2RvbWN0bF9zZXRfdmly
cV9oYW5kbGVyICBzZXRfdmlycV9oYW5kbGVyOwogICAgICAgICBzdHJ1Y3QgeGVuX2RvbWN0bF92
bWNlX21vbml0b3IgICAgICB2bWNlX21vbml0b3I7CiAgICAgICAgIHN0cnVjdCB4ZW5fZG9tY3Rs
X2dkYnN4X21lbWlvICAgICAgIGdkYnN4X2d1ZXN0X21lbWlvOworICAgICAgICBzdHJ1Y3QgeGVu
X2RvbWN0bF9zZXRfYnJva2VuX3BhZ2VfcDJtIHNldF9icm9rZW5fcGFnZV9wMm07CiAgICAgICAg
IHN0cnVjdCB4ZW5fZG9tY3RsX2dkYnN4X3BhdXNldW5wX3ZjcHUgZ2Ric3hfcGF1c2V1bnBfdmNw
dTsKICAgICAgICAgc3RydWN0IHhlbl9kb21jdGxfZ2Ric3hfZG9tc3RhdHVzICAgZ2Ric3hfZG9t
c3RhdHVzOwogICAgICAgICB1aW50OF90ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBwYWRb
MTI4XTsK

--_003_DE8DF0795D48FD4CA783C40EC829233533ABA1SHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--_003_DE8DF0795D48FD4CA783C40EC829233533ABA1SHSMSX101ccrcorpi_--


From xen-devel-bounces@lists.xen.org Wed Sep 26 06:26:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Sep 2012 06:26: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 1TGl4C-0003Z4-E1; Wed, 26 Sep 2012 06:25:52 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1TGl4B-0003Yw-N0
	for xen-devel@lists.xen.org; Wed, 26 Sep 2012 06:25:51 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1348640733!12370019!1
X-Originating-IP: [209.85.212.179]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4127 invoked from network); 26 Sep 2012 06:25:34 -0000
Received: from mail-wi0-f179.google.com (HELO mail-wi0-f179.google.com)
	(209.85.212.179)
	by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Sep 2012 06:25:34 -0000
Received: by wibhq7 with SMTP id hq7so201376wib.14
	for <xen-devel@lists.xen.org>; Tue, 25 Sep 2012 23:25:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=rRJpQRF1pZmz8xm5UzsRQ1QtCRdwpytU3+LpqakPG1w=;
	b=GcpYxk1C4m5Xxkjl5nvcRVSBE2uiHzRAUlwXQe4MvS05ZIqLbMz9thjAwWjMoGwh+t
	9khcPmge4pQVuzrB2kp2nA2VFir9KMhX0Fl4gwGPomokrp/tqUeeVTiJUoQWuhf91/ux
	bbm+xMLuC7VesvhZ0hjeo5AsBONizLi/LXVXnlvyt6YEPtHXvlO//2qX0dHoVuBAiTba
	oqSAJZPhNpY4aGXxu9s6yxSzNF50TUBUaKiZSTNPbt0vbyI+L+iaal2WS5U+5xigF8gw
	o4ax5zYD3m00I8SHfqVsjI7jZa5fvdS3usmv07gMKWpjnwBLa0TnHuMrqgrpAOUAOtF/
	3mRA==
Received: by 10.180.86.106 with SMTP id o10mr26815418wiz.22.1348640733812;
	Tue, 25 Sep 2012 23:25:33 -0700 (PDT)
Received: from [192.168.1.69] (host86-167-82-156.range86-167.btcentralplus.com.
	[86.167.82.156])
	by mx.google.com with ESMTPS id v3sm23864817wiw.7.2012.09.25.23.25.31
	(version=SSLv3 cipher=OTHER); Tue, 25 Sep 2012 23:25:33 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Wed, 26 Sep 2012 07:25:29 +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>
Message-ID: <CC885E69.3FF58%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [PATCH v2] xen/tools: Add 64 bits big bar support
Thread-Index: AQHNms4J6w8sNO8+FEeWdkWyUHsLXpealBIAgAE4tVCAAF0PiQ==
In-Reply-To: <403610A45A2B5242BD291EDAE8B37D300FEC702B@SHSMSX102.ccr.corp.intel.com>
Mime-version: 1.0
Cc: "Zhang, Xiantao" <xiantao.zhang@intel.com>,
	"ian.campbell@citrix.com" <ian.campbell@citrix.com>,
	"jbeulich@suse.com" <jbeulich@suse.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v2] xen/tools: Add 64 bits big bar support
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 26/09/2012 01:58, "Hao, Xudong" <xudong.hao@intel.com> wrote:

>>> @@ -258,8 +298,8 @@
>>>          resource->base = base;
>>> 
>>>          pci_writel(devfn, bar_reg, bar_data);
>>> -        printf("pci dev %02x:%x bar %02x size %08x: %08x\n",
>>> -               devfn>>3, devfn&7, bar_reg, bar_sz, bar_data);
>>> +        if (using_64bar)
>>> +            pci_writel(devfn, bar_reg + 4, bar_data_upper);
>> 
>> Why is the printf removed?
>> 
> 
> No special reason. It's a successful print, I'll modify patch if we want to
> remain it.

Yes please.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 26 06:26:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Sep 2012 06:26: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 1TGl4C-0003Z4-E1; Wed, 26 Sep 2012 06:25:52 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1TGl4B-0003Yw-N0
	for xen-devel@lists.xen.org; Wed, 26 Sep 2012 06:25:51 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1348640733!12370019!1
X-Originating-IP: [209.85.212.179]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4127 invoked from network); 26 Sep 2012 06:25:34 -0000
Received: from mail-wi0-f179.google.com (HELO mail-wi0-f179.google.com)
	(209.85.212.179)
	by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Sep 2012 06:25:34 -0000
Received: by wibhq7 with SMTP id hq7so201376wib.14
	for <xen-devel@lists.xen.org>; Tue, 25 Sep 2012 23:25:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=rRJpQRF1pZmz8xm5UzsRQ1QtCRdwpytU3+LpqakPG1w=;
	b=GcpYxk1C4m5Xxkjl5nvcRVSBE2uiHzRAUlwXQe4MvS05ZIqLbMz9thjAwWjMoGwh+t
	9khcPmge4pQVuzrB2kp2nA2VFir9KMhX0Fl4gwGPomokrp/tqUeeVTiJUoQWuhf91/ux
	bbm+xMLuC7VesvhZ0hjeo5AsBONizLi/LXVXnlvyt6YEPtHXvlO//2qX0dHoVuBAiTba
	oqSAJZPhNpY4aGXxu9s6yxSzNF50TUBUaKiZSTNPbt0vbyI+L+iaal2WS5U+5xigF8gw
	o4ax5zYD3m00I8SHfqVsjI7jZa5fvdS3usmv07gMKWpjnwBLa0TnHuMrqgrpAOUAOtF/
	3mRA==
Received: by 10.180.86.106 with SMTP id o10mr26815418wiz.22.1348640733812;
	Tue, 25 Sep 2012 23:25:33 -0700 (PDT)
Received: from [192.168.1.69] (host86-167-82-156.range86-167.btcentralplus.com.
	[86.167.82.156])
	by mx.google.com with ESMTPS id v3sm23864817wiw.7.2012.09.25.23.25.31
	(version=SSLv3 cipher=OTHER); Tue, 25 Sep 2012 23:25:33 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Wed, 26 Sep 2012 07:25:29 +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>
Message-ID: <CC885E69.3FF58%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [PATCH v2] xen/tools: Add 64 bits big bar support
Thread-Index: AQHNms4J6w8sNO8+FEeWdkWyUHsLXpealBIAgAE4tVCAAF0PiQ==
In-Reply-To: <403610A45A2B5242BD291EDAE8B37D300FEC702B@SHSMSX102.ccr.corp.intel.com>
Mime-version: 1.0
Cc: "Zhang, Xiantao" <xiantao.zhang@intel.com>,
	"ian.campbell@citrix.com" <ian.campbell@citrix.com>,
	"jbeulich@suse.com" <jbeulich@suse.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v2] xen/tools: Add 64 bits big bar support
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 26/09/2012 01:58, "Hao, Xudong" <xudong.hao@intel.com> wrote:

>>> @@ -258,8 +298,8 @@
>>>          resource->base = base;
>>> 
>>>          pci_writel(devfn, bar_reg, bar_data);
>>> -        printf("pci dev %02x:%x bar %02x size %08x: %08x\n",
>>> -               devfn>>3, devfn&7, bar_reg, bar_sz, bar_data);
>>> +        if (using_64bar)
>>> +            pci_writel(devfn, bar_reg + 4, bar_data_upper);
>> 
>> Why is the printf removed?
>> 
> 
> No special reason. It's a successful print, I'll modify patch if we want to
> remain it.

Yes please.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 26 06:52:52 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Sep 2012 06:52:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGlTq-0003lm-Qw; Wed, 26 Sep 2012 06:52: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 1TGlTp-0003lh-6z
	for xen-devel@lists.xensource.com; Wed, 26 Sep 2012 06:52:21 +0000
Received: from [85.158.139.83:5343] by server-14.bemta-5.messagelabs.com id
	D3/BD-05772-426A2605; Wed, 26 Sep 2012 06:52:20 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1348642339!32426922!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTEzMTI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22661 invoked from network); 26 Sep 2012 06:52:19 -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;
	26 Sep 2012 06:52:19 -0000
X-IronPort-AV: E=Sophos;i="4.80,488,1344211200"; d="scan'208";a="14766191"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Sep 2012 06: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.279.1; Wed, 26 Sep 2012 07:52: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 1TGlTm-0004MU-Qp;
	Wed, 26 Sep 2012 06:52:18 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1TGlTm-0006zv-Mt;
	Wed, 26 Sep 2012 07:52:18 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-13868-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 26 Sep 2012 07:52:18 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.2-testing test] 13868: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 13868 xen-4.2-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13868/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-i386-i386-win           12 guest-localmigrate/x10    fail REGR. vs. 13817

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore            fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-i386-i386-xl-qemuu-winxpsp3  9 guest-localmigrate         fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-win7-amd64 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-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  2b59edeb0fdd
baseline version:
 xen                  3462914d95d3

------------------------------------------------------------
People who touched revisions under test:
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  Dan Magenheimer <dan.magenheimer@oracle.com>
  Ian Campbell <ian.campbell@citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Steven Maresca <steve@zentific.com>
  Tim Deegan <tim@xen.org>
  Zhenzhong Duan <zhenzhong.duan@oracle.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                                 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                                     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:   25862:2b59edeb0fdd
tag:         tip
user:        Zhenzhong Duan <zhenzhong.duan@oracle.com>
date:        Tue Sep 25 12:19:33 2012 +0200
    
    tmem: bump pool version to 1 to fix restore issue when tmem enabled
    
    Restore fails when tmem is enabled both in hypervisor and guest. This
    is due to spec version mismatch when restoring a pool.
    
    Signed-off-by: Zhenzhong Duan <zhenzhong.duan@oracle.com>
    Acked-by: Dan Magenheimer <dan.magenheimer@oracle.com>
    xen-unstable changeset: 25929:fee83ac77d8c
    xen-unstable date: Wed Sep 19 15:38:47 UTC 2012
    
    
changeset:   25861:1853e31bb956
user:        Jan Beulich <jbeulich@suse.com>
date:        Tue Sep 25 12:18:28 2012 +0200
    
    tmem: cleanup
    
    - one more case of checking for a specific rather than any error
    - drop no longer needed first parameter from cli_put_page()
    - drop a redundant cast
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Dan Magenheimer <dan.magenheimer@oracle.com>
    xen-unstable changeset: 25860:e4cb84111610
    xen-unstable date: Tue Sep 11 12:19:29 UTC 2012
    
    
changeset:   25860:7904c87be3f3
user:        Dan Magenheimer <dan.magenheimer@oracle.com>
date:        Tue Sep 25 12:17:52 2012 +0200
    
    tmem: fixup 2010 cleanup patch that breaks tmem save/restore
    
    20918:a3fa6d444b25 "Fix domain reference leaks" (in Feb 2010, by Jan)
    does some cleanup in addition to the leak fixes.  Unfortunately, that
    cleanup inadvertently resulted in an incorrect fallthrough in a switch
    statement which breaks tmem save/restore.
    
    That broken patch was apparently applied to 4.0-testing and 4.1-testing
    so those are broken as well.
    
    What is the process now for requesting back-patches to 4.0 and 4.1?
    
    (Side note: This does not by itself entirely fix save/restore in 4.2.)
    
    Signed-off-by: Dan Magenheimer <dan.magenheimer@oracle.com>
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    xen-unstable changeset: 25859:16e0392c6594
    xen-unstable date: Tue Sep 11 12:19:03 UTC 2012
    
    
changeset:   25859:52a0b7ca721b
user:        Jan Beulich <jbeulich@suse.com>
date:        Tue Sep 25 12:17:05 2012 +0200
    
    tmem: reduce severity of log messages
    
    Otherwise they can be used by a guest to spam the hypervisor log with
    all settings at their defaults.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Zhenzhong Duan <zhenzhong.duan@oracle.com>
    xen-unstable changeset: 25858:0520982a602a
    xen-unstable date: Tue Sep 11 12:18:36 UTC 2012
    
    
changeset:   25858:22dfc72fdbf3
user:        Jan Beulich <jbeulich@suse.com>
date:        Tue Sep 25 12:16:34 2012 +0200
    
    tmem: properly drop lock on error path in do_tmem_op()
    
    Reported-by: Tim Deegan <tim@xen.org>
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Dan Magenheimer <dan.magenheimer@oracle.com>
    xen-unstable changeset: 25857:109ea6a0c23a
    xen-unstable date: Tue Sep 11 12:18:26 UTC 2012
    
    
changeset:   25857:b4218d4791cd
user:        Jan Beulich <jbeulich@suse.com>
date:        Tue Sep 25 12:16:14 2012 +0200
    
    tmem: properly drop lock on error path in do_tmem_get()
    
    Also remove a bogus assertion.
    
    Reported-by: Tim Deegan <tim@xen.org>
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Dan Magenheimer <dan.magenheimer@oracle.com>
    xen-unstable changeset: 25856:83b97a59888b
    xen-unstable date: Tue Sep 11 12:18:08 UTC 2012
    
    
changeset:   25856:61c35eaf1a88
user:        Jan Beulich <jbeulich@suse.com>
date:        Tue Sep 25 12:15:01 2012 +0200
    
    tmem: detect arithmetic overflow in tmh_copy_{from,to}_client()
    
    This implies adjusting callers to deal with errors other than -EFAULT
    and removing some comments which would otherwise become stale.
    
    Reported-by: Tim Deegan <tim@xen.org>
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Dan Magenheimer <dan.magenheimer@oracle.com>
    xen-unstable changeset: 25855:33b8c42a87ec
    xen-unstable date: Tue Sep 11 12:17:59 UTC 2012
    
    
changeset:   25855:5bc3e774301c
user:        Jan Beulich <jbeulich@suse.com>
date:        Tue Sep 25 12:14:31 2012 +0200
    
    tmem: don't access guest memory without using the accessors intended for this
    
    This is not permitted, not even for buffers coming from Dom0 (and it
    would also break the moment Dom0 runs in HVM mode). An implication from
    the changes here is that tmh_copy_page() can't be used anymore for
    control operations calling tmh_copy_{from,to}_client() (as those pass
    the buffer by virtual address rather than MFN).
    
    Note that tmemc_save_get_next_page() previously didn't set the returned
    handle's pool_id field, while the new code does. It need to be
    confirmed that this is not a problem (otherwise the copy-out operation
    will require further tmh_...() abstractions to be added).
    
    Further note that the patch removes (rather than adjusts) an invalid
    call to unmap_domain_page() (no matching map_domain_page()) from
    tmh_compress_from_client() and adds a missing one to an error return
    path in tmh_copy_from_client().
    
    Finally note that the patch adds a previously missing return statement
    to cli_get_page() (without which that function could de-reference a
    NULL pointer, triggerable from guest mode).
    
    This is part of XSA-15 / CVE-2012-3497.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Dan Magenheimer <dan.magenheimer@oracle.com>
    xen-unstable changeset: 25854:ccd60ed6c555
    xen-unstable date: Tue Sep 11 12:17:49 UTC 2012
    
    
changeset:   25854:b383875a33f0
user:        Ian Campbell <ian.campbell@citrix.com>
date:        Tue Sep 25 12:13:40 2012 +0200
    
    tmem: check for a valid client ("domain") in the save subops
    
    This is part of XSA-15 / CVE-2012-3497.
    
    Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
    Acked-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Dan Magenheimer <dan.magenheimer@oracle.com>
    xen-unstable changeset: 25853:f53c5aadbba9
    xen-unstable date: Tue Sep 11 12:17:27 UTC 2012
    
    
changeset:   25853:da0fd47f59b4
user:        Ian Campbell <ian.campbell@citrix.com>
date:        Tue Sep 25 12:12:48 2012 +0200
    
    tmem: check the pool_id is valid when destroying a tmem pool
    
    This is part of XSA-15 / CVE-2012-3497.
    
    Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
    Acked-by: Dan Magenheimer <dan.magenheimer@oracle.com>
    Acked-by: Jan Beulich <jbeulich@suse.com>
    xen-unstable changeset: 25852:d189d99ef00c
    xen-unstable date: Tue Sep 11 12:06:54 UTC 2012
    
    
changeset:   25852:d188a7ad6c75
user:        Ian Campbell <ian.campbell@citrix.com>
date:        Tue Sep 25 12:12:04 2012 +0200
    
    tmem: consistently make pool_id a uint32_t
    
    Treating it as an int could allow a malicious guest to provide a
    negative pool_Id, by passing the MAX_POOLS_PER_DOMAIN limit check and
    allowing access to the negative offsets of the pool array.
    
    This is part of XSA-15 / CVE-2012-3497.
    
    Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
    Acked-by: Dan Magenheimer <dan.magenheimer@oracle.com>
    Acked-by: Jan Beulich <jbeulich@suse.com>
    xen-unstable changeset: 25851:fcf567acc92a
    xen-unstable date: Tue Sep 11 12:06:43 UTC 2012
    
    
changeset:   25851:e0dc63c822b2
user:        Ian Campbell <ian.campbell@citrix.com>
date:        Tue Sep 25 12:09:19 2012 +0200
    
    tmem: only allow tmem control operations from privileged domains
    
    This is part of XSA-15 / CVE-2012-3497.
    
    Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
    Acked-by: Dan Magenheimer <dan.magenheimer@oracle.com>
    Acked-by-by: Jan Beulich <jbeulich@suse.com>
    xen-unstable changeset: 25850:0dba5a888655
    xen-unstable date: Tue Sep 11 12:06:30 UTC 2012
    
    
changeset:   25850:3462914d95d3
user:        Steven Maresca <steve@zentific.com>
date:        Wed Sep 19 17:33:05 2012 +0200
    
    mem_event: fix regression affecting CR3, CR4 memory events
    
    This is a patch repairing a regression in code previously functional
    in 4.1.x. It appears that, during some refactoring work, calls to
    hvm_memory_event_cr3 and hvm_memory_event_cr4 were lost.
    
    These functions were originally called in mov_to_cr() of vmx.c, but
    the commit  http://xenbits.xen.org/hg/xen-unstable.hg/rev/1276926e3795
    abstracted the original code into generic functions up a level in
    hvm.c, dropping these calls in the process.
    
    Signed-off-by: Steven Maresca <steve@zentific.com>
    Acked-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
    Acked-by: Tim Deegan <tim@xen.org>
    xen-unstable changeset: 25918:7ab899e46347
    xen-unstable date: Mon Sep 17 16:55:12 UTC 2012
    
    
(qemu changes not included)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 26 06:52:52 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Sep 2012 06:52:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGlTq-0003lm-Qw; Wed, 26 Sep 2012 06:52: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 1TGlTp-0003lh-6z
	for xen-devel@lists.xensource.com; Wed, 26 Sep 2012 06:52:21 +0000
Received: from [85.158.139.83:5343] by server-14.bemta-5.messagelabs.com id
	D3/BD-05772-426A2605; Wed, 26 Sep 2012 06:52:20 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1348642339!32426922!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTEzMTI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22661 invoked from network); 26 Sep 2012 06:52:19 -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;
	26 Sep 2012 06:52:19 -0000
X-IronPort-AV: E=Sophos;i="4.80,488,1344211200"; d="scan'208";a="14766191"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Sep 2012 06: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.279.1; Wed, 26 Sep 2012 07:52: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 1TGlTm-0004MU-Qp;
	Wed, 26 Sep 2012 06:52:18 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1TGlTm-0006zv-Mt;
	Wed, 26 Sep 2012 07:52:18 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-13868-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 26 Sep 2012 07:52:18 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.2-testing test] 13868: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 13868 xen-4.2-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13868/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-i386-i386-win           12 guest-localmigrate/x10    fail REGR. vs. 13817

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore            fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-i386-i386-xl-qemuu-winxpsp3  9 guest-localmigrate         fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-win7-amd64 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-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  2b59edeb0fdd
baseline version:
 xen                  3462914d95d3

------------------------------------------------------------
People who touched revisions under test:
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  Dan Magenheimer <dan.magenheimer@oracle.com>
  Ian Campbell <ian.campbell@citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Steven Maresca <steve@zentific.com>
  Tim Deegan <tim@xen.org>
  Zhenzhong Duan <zhenzhong.duan@oracle.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                                 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                                     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:   25862:2b59edeb0fdd
tag:         tip
user:        Zhenzhong Duan <zhenzhong.duan@oracle.com>
date:        Tue Sep 25 12:19:33 2012 +0200
    
    tmem: bump pool version to 1 to fix restore issue when tmem enabled
    
    Restore fails when tmem is enabled both in hypervisor and guest. This
    is due to spec version mismatch when restoring a pool.
    
    Signed-off-by: Zhenzhong Duan <zhenzhong.duan@oracle.com>
    Acked-by: Dan Magenheimer <dan.magenheimer@oracle.com>
    xen-unstable changeset: 25929:fee83ac77d8c
    xen-unstable date: Wed Sep 19 15:38:47 UTC 2012
    
    
changeset:   25861:1853e31bb956
user:        Jan Beulich <jbeulich@suse.com>
date:        Tue Sep 25 12:18:28 2012 +0200
    
    tmem: cleanup
    
    - one more case of checking for a specific rather than any error
    - drop no longer needed first parameter from cli_put_page()
    - drop a redundant cast
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Dan Magenheimer <dan.magenheimer@oracle.com>
    xen-unstable changeset: 25860:e4cb84111610
    xen-unstable date: Tue Sep 11 12:19:29 UTC 2012
    
    
changeset:   25860:7904c87be3f3
user:        Dan Magenheimer <dan.magenheimer@oracle.com>
date:        Tue Sep 25 12:17:52 2012 +0200
    
    tmem: fixup 2010 cleanup patch that breaks tmem save/restore
    
    20918:a3fa6d444b25 "Fix domain reference leaks" (in Feb 2010, by Jan)
    does some cleanup in addition to the leak fixes.  Unfortunately, that
    cleanup inadvertently resulted in an incorrect fallthrough in a switch
    statement which breaks tmem save/restore.
    
    That broken patch was apparently applied to 4.0-testing and 4.1-testing
    so those are broken as well.
    
    What is the process now for requesting back-patches to 4.0 and 4.1?
    
    (Side note: This does not by itself entirely fix save/restore in 4.2.)
    
    Signed-off-by: Dan Magenheimer <dan.magenheimer@oracle.com>
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    xen-unstable changeset: 25859:16e0392c6594
    xen-unstable date: Tue Sep 11 12:19:03 UTC 2012
    
    
changeset:   25859:52a0b7ca721b
user:        Jan Beulich <jbeulich@suse.com>
date:        Tue Sep 25 12:17:05 2012 +0200
    
    tmem: reduce severity of log messages
    
    Otherwise they can be used by a guest to spam the hypervisor log with
    all settings at their defaults.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Zhenzhong Duan <zhenzhong.duan@oracle.com>
    xen-unstable changeset: 25858:0520982a602a
    xen-unstable date: Tue Sep 11 12:18:36 UTC 2012
    
    
changeset:   25858:22dfc72fdbf3
user:        Jan Beulich <jbeulich@suse.com>
date:        Tue Sep 25 12:16:34 2012 +0200
    
    tmem: properly drop lock on error path in do_tmem_op()
    
    Reported-by: Tim Deegan <tim@xen.org>
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Dan Magenheimer <dan.magenheimer@oracle.com>
    xen-unstable changeset: 25857:109ea6a0c23a
    xen-unstable date: Tue Sep 11 12:18:26 UTC 2012
    
    
changeset:   25857:b4218d4791cd
user:        Jan Beulich <jbeulich@suse.com>
date:        Tue Sep 25 12:16:14 2012 +0200
    
    tmem: properly drop lock on error path in do_tmem_get()
    
    Also remove a bogus assertion.
    
    Reported-by: Tim Deegan <tim@xen.org>
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Dan Magenheimer <dan.magenheimer@oracle.com>
    xen-unstable changeset: 25856:83b97a59888b
    xen-unstable date: Tue Sep 11 12:18:08 UTC 2012
    
    
changeset:   25856:61c35eaf1a88
user:        Jan Beulich <jbeulich@suse.com>
date:        Tue Sep 25 12:15:01 2012 +0200
    
    tmem: detect arithmetic overflow in tmh_copy_{from,to}_client()
    
    This implies adjusting callers to deal with errors other than -EFAULT
    and removing some comments which would otherwise become stale.
    
    Reported-by: Tim Deegan <tim@xen.org>
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Dan Magenheimer <dan.magenheimer@oracle.com>
    xen-unstable changeset: 25855:33b8c42a87ec
    xen-unstable date: Tue Sep 11 12:17:59 UTC 2012
    
    
changeset:   25855:5bc3e774301c
user:        Jan Beulich <jbeulich@suse.com>
date:        Tue Sep 25 12:14:31 2012 +0200
    
    tmem: don't access guest memory without using the accessors intended for this
    
    This is not permitted, not even for buffers coming from Dom0 (and it
    would also break the moment Dom0 runs in HVM mode). An implication from
    the changes here is that tmh_copy_page() can't be used anymore for
    control operations calling tmh_copy_{from,to}_client() (as those pass
    the buffer by virtual address rather than MFN).
    
    Note that tmemc_save_get_next_page() previously didn't set the returned
    handle's pool_id field, while the new code does. It need to be
    confirmed that this is not a problem (otherwise the copy-out operation
    will require further tmh_...() abstractions to be added).
    
    Further note that the patch removes (rather than adjusts) an invalid
    call to unmap_domain_page() (no matching map_domain_page()) from
    tmh_compress_from_client() and adds a missing one to an error return
    path in tmh_copy_from_client().
    
    Finally note that the patch adds a previously missing return statement
    to cli_get_page() (without which that function could de-reference a
    NULL pointer, triggerable from guest mode).
    
    This is part of XSA-15 / CVE-2012-3497.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Dan Magenheimer <dan.magenheimer@oracle.com>
    xen-unstable changeset: 25854:ccd60ed6c555
    xen-unstable date: Tue Sep 11 12:17:49 UTC 2012
    
    
changeset:   25854:b383875a33f0
user:        Ian Campbell <ian.campbell@citrix.com>
date:        Tue Sep 25 12:13:40 2012 +0200
    
    tmem: check for a valid client ("domain") in the save subops
    
    This is part of XSA-15 / CVE-2012-3497.
    
    Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
    Acked-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Dan Magenheimer <dan.magenheimer@oracle.com>
    xen-unstable changeset: 25853:f53c5aadbba9
    xen-unstable date: Tue Sep 11 12:17:27 UTC 2012
    
    
changeset:   25853:da0fd47f59b4
user:        Ian Campbell <ian.campbell@citrix.com>
date:        Tue Sep 25 12:12:48 2012 +0200
    
    tmem: check the pool_id is valid when destroying a tmem pool
    
    This is part of XSA-15 / CVE-2012-3497.
    
    Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
    Acked-by: Dan Magenheimer <dan.magenheimer@oracle.com>
    Acked-by: Jan Beulich <jbeulich@suse.com>
    xen-unstable changeset: 25852:d189d99ef00c
    xen-unstable date: Tue Sep 11 12:06:54 UTC 2012
    
    
changeset:   25852:d188a7ad6c75
user:        Ian Campbell <ian.campbell@citrix.com>
date:        Tue Sep 25 12:12:04 2012 +0200
    
    tmem: consistently make pool_id a uint32_t
    
    Treating it as an int could allow a malicious guest to provide a
    negative pool_Id, by passing the MAX_POOLS_PER_DOMAIN limit check and
    allowing access to the negative offsets of the pool array.
    
    This is part of XSA-15 / CVE-2012-3497.
    
    Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
    Acked-by: Dan Magenheimer <dan.magenheimer@oracle.com>
    Acked-by: Jan Beulich <jbeulich@suse.com>
    xen-unstable changeset: 25851:fcf567acc92a
    xen-unstable date: Tue Sep 11 12:06:43 UTC 2012
    
    
changeset:   25851:e0dc63c822b2
user:        Ian Campbell <ian.campbell@citrix.com>
date:        Tue Sep 25 12:09:19 2012 +0200
    
    tmem: only allow tmem control operations from privileged domains
    
    This is part of XSA-15 / CVE-2012-3497.
    
    Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
    Acked-by: Dan Magenheimer <dan.magenheimer@oracle.com>
    Acked-by-by: Jan Beulich <jbeulich@suse.com>
    xen-unstable changeset: 25850:0dba5a888655
    xen-unstable date: Tue Sep 11 12:06:30 UTC 2012
    
    
changeset:   25850:3462914d95d3
user:        Steven Maresca <steve@zentific.com>
date:        Wed Sep 19 17:33:05 2012 +0200
    
    mem_event: fix regression affecting CR3, CR4 memory events
    
    This is a patch repairing a regression in code previously functional
    in 4.1.x. It appears that, during some refactoring work, calls to
    hvm_memory_event_cr3 and hvm_memory_event_cr4 were lost.
    
    These functions were originally called in mov_to_cr() of vmx.c, but
    the commit  http://xenbits.xen.org/hg/xen-unstable.hg/rev/1276926e3795
    abstracted the original code into generic functions up a level in
    hvm.c, dropping these calls in the process.
    
    Signed-off-by: Steven Maresca <steve@zentific.com>
    Acked-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
    Acked-by: Tim Deegan <tim@xen.org>
    xen-unstable changeset: 25918:7ab899e46347
    xen-unstable date: Mon Sep 17 16:55:12 UTC 2012
    
    
(qemu changes not included)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 26 07:04:18 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Sep 2012 07: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 1TGlez-00047Q-J1; Wed, 26 Sep 2012 07:03: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 1TGley-00047L-1N
	for xen-devel@lists.xen.org; Wed, 26 Sep 2012 07:03:52 +0000
Received: from [85.158.139.211:43633] by server-15.bemta-5.messagelabs.com id
	AB/9F-19430-7D8A2605; Wed, 26 Sep 2012 07:03:51 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-206.messagelabs.com!1348643029!19990381!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4422 invoked from network); 26 Sep 2012 07:03:50 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-11.tower-206.messagelabs.com with SMTP;
	26 Sep 2012 07:03:50 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 26 Sep 2012 08:03:48 +0100
Message-Id: <5062C50B020000780009DE1C@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 26 Sep 2012 08:04:11 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Keir Fraser" <keir@xen.org>
References: <5061E4CF020000780009DB98@nat28.tlf.novell.com>
	<CC8790FB.4CD98%keir@xen.org>
In-Reply-To: <CC8790FB.4CD98%keir@xen.org>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part093836FB.0__="
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: [Xen-devel] [PATCH,
	v2] x86: slightly improve stack trace on debug builds
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<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.

--=__Part093836FB.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

As was rather obvious from crashes recently happening in stage testing,
the debug hypervisor, in that special case, has a drawback compared to
the non-debug one: When a call through a bad pointer happens, there's
no frame, and the top level (and frequently most important for
analysis) stack entry would get skipped:

(XEN) ----[ Xen-4.3-unstable  x86_64  debug=3Dy  Not tainted ]----
(XEN) CPU:    1
(XEN) RIP:    e008:[<0000000000000000>] ???
(XEN) RFLAGS: 0000000000010046   CONTEXT: hypervisor
(XEN) rax: 0000000000000008   rbx: 0000000000000001   rcx: 0000000000000003=

(XEN) rdx: 0000003db54eb700   rsi: 7fffffffffffffff   rdi: 0000000000000001=

(XEN) rbp: ffff8302357e7ee0   rsp: ffff8302357e7e58   r8:  0000000000000000=

(XEN) r9:  000000000000003e   r10: ffff8302357e7f18   r11: ffff8302357e7f18=

(XEN) r12: ffff8302357ee340   r13: ffff82c480263980   r14: ffff8302357ee3d0=

(XEN) r15: 0000000000000001   cr0: 000000008005003b   cr4: 00000000000026f0=

(XEN) cr3: 00000000bf473000   cr2: 0000000000000000
(XEN) ds: 0000   es: 0000   fs: 0000   gs: 0000   ss: 0000   cs: e008
(XEN) Xen stack trace from rsp=3Dffff8302357e7e58:
(XEN)    ffff82c4801a3d05 ffff8302357eca70 0000000800000020 ffff82c4802ead6=
0
(XEN)    0000000000000001 ffff8302357e7ea0 ffff82c48016bf07 000000000000000=
0
(XEN)    0000000000000000 ffff8302357e7ee0 fffff830fffff830 000000000000004=
6
(XEN)    ffff8302357e7f18 ffff82c480263980 ffff8302357e7f18 000000000000000=
0
(XEN)    0000000000000000 ffff8302357e7f10 ffff82c48015c2be 8302357dc0000ff=
f
...
(XEN) Xen call trace:
(XEN)    [<0000000000000000>] ???
(XEN)    [<ffff82c48015c2be>] idle_loop+0x6c/0x7a
(XEN)   =20
(XEN) Pagetable walk from 0000000000000000:

Since the bad pointer is being printed anyway (as part of the register
state), replace it with the top of stack value in such a case.

With the introduction of is_active_kernel_text(), use it also at the
(few) other suitable places (I intentionally didn't replace the use in
xen/arch/arm/mm.c - while it would be functionally correct, the
dependency on system_state wouldn't be from an abstract perspective).

Signed-off-by: Jan Beulich <jbeulich@suse.com>
---
v2: Introduce and use is_active_kernel_text(). Make logic to determine
    what address to print at the top of show_trace() more readable.

--- a/xen/arch/x86/traps.c
+++ b/xen/arch/x86/traps.c
@@ -199,7 +199,7 @@ static void show_trace(struct cpu_user_r
     while ( ((long)stack & (STACK_SIZE-BYTES_PER_LONG)) !=3D 0 )
     {
         addr =3D *stack++;
-        if ( is_kernel_text(addr) || is_kernel_inittext(addr) )
+        if ( is_active_kernel_text(addr) )
         {
             printk("[<%p>]", _p(addr));
             print_symbol(" %s\n   ", addr);
@@ -217,8 +217,16 @@ static void show_trace(struct cpu_user_r
=20
     printk("Xen call trace:\n   ");
=20
-    printk("[<%p>]", _p(regs->eip));
-    print_symbol(" %s\n   ", regs->eip);
+    /*
+     * If RIP is not pointing into hypervisor code then someone may have
+     * called into oblivion. Peek to see if they left a return address at
+     * top of stack.
+     */
+    addr =3D is_active_kernel_text(regs->eip) ||
+           !is_active_kernel_text(*ESP_BEFORE_EXCEPTION(regs)) ?
+           regs->eip : *ESP_BEFORE_EXCEPTION(regs);
+    printk("[<%p>]", _p(addr));
+    print_symbol(" %s\n   ", addr);
=20
     /* Bounds for range of valid frame pointer. */
     low  =3D (unsigned long)(ESP_BEFORE_EXCEPTION(regs) - 2);
@@ -322,7 +330,7 @@ void show_stack_overflow(unsigned int cp
     while ( ((long)stack & (STACK_SIZE-BYTES_PER_LONG)) !=3D 0 )
     {
         addr =3D *stack++;
-        if ( is_kernel_text(addr) || is_kernel_inittext(addr) )
+        if ( is_active_kernel_text(addr) )
         {
             printk("%p: [<%p>]", stack, _p(addr));
             print_symbol(" %s\n   ", addr);
--- a/xen/common/symbols.c
+++ b/xen/common/symbols.c
@@ -93,6 +93,12 @@ static unsigned int get_symbol_offset(un
     return name - symbols_names;
 }
=20
+bool_t is_active_kernel_text(unsigned long addr)
+{
+    return (is_kernel_text(addr) ||
+            (system_state =3D=3D SYS_STATE_boot && is_kernel_inittext(addr=
)));
+}
+
 const char *symbols_lookup(unsigned long addr,
                            unsigned long *symbolsize,
                            unsigned long *offset,
@@ -104,7 +110,7 @@ const char *symbols_lookup(unsigned long
     namebuf[KSYM_NAME_LEN] =3D 0;
     namebuf[0] =3D 0;
=20
-    if (!is_kernel_text(addr) && !is_kernel_inittext(addr))
+    if (!is_active_kernel_text(addr))
         return NULL;
=20
         /* do a binary search on the sorted symbols_addresses array */
--- a/xen/include/xen/kernel.h
+++ b/xen/include/xen/kernel.h
@@ -5,6 +5,8 @@
  * 'kernel.h' contains some often-used function prototypes etc
  */
=20
+#include <xen/types.h>
+
 /*
  * min()/max() macros that also do
  * strict type-checking.. See the
@@ -95,5 +97,7 @@ extern enum system_state {
     SYS_STATE_resume
 } system_state;
=20
+bool_t is_active_kernel_text(unsigned long addr);
+
 #endif /* _LINUX_KERNEL_H */
=20



--=__Part093836FB.0__=
Content-Type: text/plain; name="x86-debug-dump-TOS.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="x86-debug-dump-TOS.patch"

x86: slightly improve stack trace on debug builds=0A=0AAs was rather =
obvious from crashes recently happening in stage testing,=0Athe debug =
hypervisor, in that special case, has a drawback compared to=0Athe =
non-debug one: When a call through a bad pointer happens, there's=0Ano =
frame, and the top level (and frequently most important for=0Aanalysis) =
stack entry would get skipped:=0A=0A(XEN) ----[ Xen-4.3-unstable  x86_64  =
debug=3Dy  Not tainted ]----=0A(XEN) CPU:    1=0A(XEN) RIP:    e008:[<00000=
00000000000>] ???=0A(XEN) RFLAGS: 0000000000010046   CONTEXT: hypervisor=0A=
(XEN) rax: 0000000000000008   rbx: 0000000000000001   rcx: 0000000000000003=
=0A(XEN) rdx: 0000003db54eb700   rsi: 7fffffffffffffff   rdi: 0000000000000=
001=0A(XEN) rbp: ffff8302357e7ee0   rsp: ffff8302357e7e58   r8:  0000000000=
000000=0A(XEN) r9:  000000000000003e   r10: ffff8302357e7f18   r11: =
ffff8302357e7f18=0A(XEN) r12: ffff8302357ee340   r13: ffff82c480263980   =
r14: ffff8302357ee3d0=0A(XEN) r15: 0000000000000001   cr0: 000000008005003b=
   cr4: 00000000000026f0=0A(XEN) cr3: 00000000bf473000   cr2: 0000000000000=
000=0A(XEN) ds: 0000   es: 0000   fs: 0000   gs: 0000   ss: 0000   cs: =
e008=0A(XEN) Xen stack trace from rsp=3Dffff8302357e7e58:=0A(XEN)    =
ffff82c4801a3d05 ffff8302357eca70 0000000800000020 ffff82c4802ead60=0A(XEN)=
    0000000000000001 ffff8302357e7ea0 ffff82c48016bf07 0000000000000000=0A(=
XEN)    0000000000000000 ffff8302357e7ee0 fffff830fffff830 0000000000000046=
=0A(XEN)    ffff8302357e7f18 ffff82c480263980 ffff8302357e7f18 000000000000=
0000=0A(XEN)    0000000000000000 ffff8302357e7f10 ffff82c48015c2be =
8302357dc0000fff=0A...=0A(XEN) Xen call trace:=0A(XEN)    [<000000000000000=
0>] ???=0A(XEN)    [<ffff82c48015c2be>] idle_loop+0x6c/0x7a=0A(XEN)    =
=0A(XEN) Pagetable walk from 0000000000000000:=0A=0ASince the bad pointer =
is being printed anyway (as part of the register=0Astate), replace it with =
the top of stack value in such a case.=0A=0AWith the introduction of =
is_active_kernel_text(), use it also at the=0A(few) other suitable places =
(I intentionally didn't replace the use in=0Axen/arch/arm/mm.c - while it =
would be functionally correct, the=0Adependency on system_state wouldn't =
be from an abstract perspective).=0A=0ASigned-off-by: Jan Beulich =
<jbeulich@suse.com>=0A---=0Av2: Introduce and use is_active_kernel_text(). =
Make logic to determine=0A    what address to print at the top of =
show_trace() more readable.=0A=0A--- a/xen/arch/x86/traps.c=0A+++ =
b/xen/arch/x86/traps.c=0A@@ -199,7 +199,7 @@ static void show_trace(struct =
cpu_user_r=0A     while ( ((long)stack & (STACK_SIZE-BYTES_PER_LONG)) !=3D =
0 )=0A     {=0A         addr =3D *stack++;=0A-        if ( is_kernel_text(a=
ddr) || is_kernel_inittext(addr) )=0A+        if ( is_active_kernel_text(ad=
dr) )=0A         {=0A             printk("[<%p>]", _p(addr));=0A           =
  print_symbol(" %s\n   ", addr);=0A@@ -217,8 +217,16 @@ static void =
show_trace(struct cpu_user_r=0A =0A     printk("Xen call trace:\n   ");=0A =
=0A-    printk("[<%p>]", _p(regs->eip));=0A-    print_symbol(" %s\n   ", =
regs->eip);=0A+    /*=0A+     * If RIP is not pointing into hypervisor =
code then someone may have=0A+     * called into oblivion. Peek to see if =
they left a return address at=0A+     * top of stack.=0A+     */=0A+    =
addr =3D is_active_kernel_text(regs->eip) ||=0A+           !is_active_kerne=
l_text(*ESP_BEFORE_EXCEPTION(regs)) ?=0A+           regs->eip : *ESP_BEFORE=
_EXCEPTION(regs);=0A+    printk("[<%p>]", _p(addr));=0A+    print_symbol(" =
%s\n   ", addr);=0A =0A     /* Bounds for range of valid frame pointer. =
*/=0A     low  =3D (unsigned long)(ESP_BEFORE_EXCEPTION(regs) - 2);=0A@@ =
-322,7 +330,7 @@ void show_stack_overflow(unsigned int cp=0A     while ( =
((long)stack & (STACK_SIZE-BYTES_PER_LONG)) !=3D 0 )=0A     {=0A         =
addr =3D *stack++;=0A-        if ( is_kernel_text(addr) || is_kernel_initte=
xt(addr) )=0A+        if ( is_active_kernel_text(addr) )=0A         {=0A   =
          printk("%p: [<%p>]", stack, _p(addr));=0A             print_symbo=
l(" %s\n   ", addr);=0A--- a/xen/common/symbols.c=0A+++ b/xen/common/symbol=
s.c=0A@@ -93,6 +93,12 @@ static unsigned int get_symbol_offset(un=0A     =
return name - symbols_names;=0A }=0A =0A+bool_t is_active_kernel_text(unsig=
ned long addr)=0A+{=0A+    return (is_kernel_text(addr) ||=0A+            =
(system_state =3D=3D SYS_STATE_boot && is_kernel_inittext(addr)));=0A+}=0A+=
=0A const char *symbols_lookup(unsigned long addr,=0A                      =
      unsigned long *symbolsize,=0A                            unsigned =
long *offset,=0A@@ -104,7 +110,7 @@ const char *symbols_lookup(unsigned =
long=0A     namebuf[KSYM_NAME_LEN] =3D 0;=0A     namebuf[0] =3D 0;=0A =0A- =
   if (!is_kernel_text(addr) && !is_kernel_inittext(addr))=0A+    if =
(!is_active_kernel_text(addr))=0A         return NULL;=0A =0A         /* =
do a binary search on the sorted symbols_addresses array */=0A--- =
a/xen/include/xen/kernel.h=0A+++ b/xen/include/xen/kernel.h=0A@@ -5,6 +5,8 =
@@=0A  * 'kernel.h' contains some often-used function prototypes etc=0A  =
*/=0A =0A+#include <xen/types.h>=0A+=0A /*=0A  * min()/max() macros that =
also do=0A  * strict type-checking.. See the=0A@@ -95,5 +97,7 @@ extern =
enum system_state {=0A     SYS_STATE_resume=0A } system_state;=0A =
=0A+bool_t is_active_kernel_text(unsigned long addr);=0A+=0A #endif /* =
_LINUX_KERNEL_H */=0A =0A
--=__Part093836FB.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

--=__Part093836FB.0__=--


From xen-devel-bounces@lists.xen.org Wed Sep 26 07:04:18 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Sep 2012 07: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 1TGlez-00047Q-J1; Wed, 26 Sep 2012 07:03: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 1TGley-00047L-1N
	for xen-devel@lists.xen.org; Wed, 26 Sep 2012 07:03:52 +0000
Received: from [85.158.139.211:43633] by server-15.bemta-5.messagelabs.com id
	AB/9F-19430-7D8A2605; Wed, 26 Sep 2012 07:03:51 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-206.messagelabs.com!1348643029!19990381!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4422 invoked from network); 26 Sep 2012 07:03:50 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-11.tower-206.messagelabs.com with SMTP;
	26 Sep 2012 07:03:50 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 26 Sep 2012 08:03:48 +0100
Message-Id: <5062C50B020000780009DE1C@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 26 Sep 2012 08:04:11 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Keir Fraser" <keir@xen.org>
References: <5061E4CF020000780009DB98@nat28.tlf.novell.com>
	<CC8790FB.4CD98%keir@xen.org>
In-Reply-To: <CC8790FB.4CD98%keir@xen.org>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part093836FB.0__="
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: [Xen-devel] [PATCH,
	v2] x86: slightly improve stack trace on debug builds
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<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.

--=__Part093836FB.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

As was rather obvious from crashes recently happening in stage testing,
the debug hypervisor, in that special case, has a drawback compared to
the non-debug one: When a call through a bad pointer happens, there's
no frame, and the top level (and frequently most important for
analysis) stack entry would get skipped:

(XEN) ----[ Xen-4.3-unstable  x86_64  debug=3Dy  Not tainted ]----
(XEN) CPU:    1
(XEN) RIP:    e008:[<0000000000000000>] ???
(XEN) RFLAGS: 0000000000010046   CONTEXT: hypervisor
(XEN) rax: 0000000000000008   rbx: 0000000000000001   rcx: 0000000000000003=

(XEN) rdx: 0000003db54eb700   rsi: 7fffffffffffffff   rdi: 0000000000000001=

(XEN) rbp: ffff8302357e7ee0   rsp: ffff8302357e7e58   r8:  0000000000000000=

(XEN) r9:  000000000000003e   r10: ffff8302357e7f18   r11: ffff8302357e7f18=

(XEN) r12: ffff8302357ee340   r13: ffff82c480263980   r14: ffff8302357ee3d0=

(XEN) r15: 0000000000000001   cr0: 000000008005003b   cr4: 00000000000026f0=

(XEN) cr3: 00000000bf473000   cr2: 0000000000000000
(XEN) ds: 0000   es: 0000   fs: 0000   gs: 0000   ss: 0000   cs: e008
(XEN) Xen stack trace from rsp=3Dffff8302357e7e58:
(XEN)    ffff82c4801a3d05 ffff8302357eca70 0000000800000020 ffff82c4802ead6=
0
(XEN)    0000000000000001 ffff8302357e7ea0 ffff82c48016bf07 000000000000000=
0
(XEN)    0000000000000000 ffff8302357e7ee0 fffff830fffff830 000000000000004=
6
(XEN)    ffff8302357e7f18 ffff82c480263980 ffff8302357e7f18 000000000000000=
0
(XEN)    0000000000000000 ffff8302357e7f10 ffff82c48015c2be 8302357dc0000ff=
f
...
(XEN) Xen call trace:
(XEN)    [<0000000000000000>] ???
(XEN)    [<ffff82c48015c2be>] idle_loop+0x6c/0x7a
(XEN)   =20
(XEN) Pagetable walk from 0000000000000000:

Since the bad pointer is being printed anyway (as part of the register
state), replace it with the top of stack value in such a case.

With the introduction of is_active_kernel_text(), use it also at the
(few) other suitable places (I intentionally didn't replace the use in
xen/arch/arm/mm.c - while it would be functionally correct, the
dependency on system_state wouldn't be from an abstract perspective).

Signed-off-by: Jan Beulich <jbeulich@suse.com>
---
v2: Introduce and use is_active_kernel_text(). Make logic to determine
    what address to print at the top of show_trace() more readable.

--- a/xen/arch/x86/traps.c
+++ b/xen/arch/x86/traps.c
@@ -199,7 +199,7 @@ static void show_trace(struct cpu_user_r
     while ( ((long)stack & (STACK_SIZE-BYTES_PER_LONG)) !=3D 0 )
     {
         addr =3D *stack++;
-        if ( is_kernel_text(addr) || is_kernel_inittext(addr) )
+        if ( is_active_kernel_text(addr) )
         {
             printk("[<%p>]", _p(addr));
             print_symbol(" %s\n   ", addr);
@@ -217,8 +217,16 @@ static void show_trace(struct cpu_user_r
=20
     printk("Xen call trace:\n   ");
=20
-    printk("[<%p>]", _p(regs->eip));
-    print_symbol(" %s\n   ", regs->eip);
+    /*
+     * If RIP is not pointing into hypervisor code then someone may have
+     * called into oblivion. Peek to see if they left a return address at
+     * top of stack.
+     */
+    addr =3D is_active_kernel_text(regs->eip) ||
+           !is_active_kernel_text(*ESP_BEFORE_EXCEPTION(regs)) ?
+           regs->eip : *ESP_BEFORE_EXCEPTION(regs);
+    printk("[<%p>]", _p(addr));
+    print_symbol(" %s\n   ", addr);
=20
     /* Bounds for range of valid frame pointer. */
     low  =3D (unsigned long)(ESP_BEFORE_EXCEPTION(regs) - 2);
@@ -322,7 +330,7 @@ void show_stack_overflow(unsigned int cp
     while ( ((long)stack & (STACK_SIZE-BYTES_PER_LONG)) !=3D 0 )
     {
         addr =3D *stack++;
-        if ( is_kernel_text(addr) || is_kernel_inittext(addr) )
+        if ( is_active_kernel_text(addr) )
         {
             printk("%p: [<%p>]", stack, _p(addr));
             print_symbol(" %s\n   ", addr);
--- a/xen/common/symbols.c
+++ b/xen/common/symbols.c
@@ -93,6 +93,12 @@ static unsigned int get_symbol_offset(un
     return name - symbols_names;
 }
=20
+bool_t is_active_kernel_text(unsigned long addr)
+{
+    return (is_kernel_text(addr) ||
+            (system_state =3D=3D SYS_STATE_boot && is_kernel_inittext(addr=
)));
+}
+
 const char *symbols_lookup(unsigned long addr,
                            unsigned long *symbolsize,
                            unsigned long *offset,
@@ -104,7 +110,7 @@ const char *symbols_lookup(unsigned long
     namebuf[KSYM_NAME_LEN] =3D 0;
     namebuf[0] =3D 0;
=20
-    if (!is_kernel_text(addr) && !is_kernel_inittext(addr))
+    if (!is_active_kernel_text(addr))
         return NULL;
=20
         /* do a binary search on the sorted symbols_addresses array */
--- a/xen/include/xen/kernel.h
+++ b/xen/include/xen/kernel.h
@@ -5,6 +5,8 @@
  * 'kernel.h' contains some often-used function prototypes etc
  */
=20
+#include <xen/types.h>
+
 /*
  * min()/max() macros that also do
  * strict type-checking.. See the
@@ -95,5 +97,7 @@ extern enum system_state {
     SYS_STATE_resume
 } system_state;
=20
+bool_t is_active_kernel_text(unsigned long addr);
+
 #endif /* _LINUX_KERNEL_H */
=20



--=__Part093836FB.0__=
Content-Type: text/plain; name="x86-debug-dump-TOS.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="x86-debug-dump-TOS.patch"

x86: slightly improve stack trace on debug builds=0A=0AAs was rather =
obvious from crashes recently happening in stage testing,=0Athe debug =
hypervisor, in that special case, has a drawback compared to=0Athe =
non-debug one: When a call through a bad pointer happens, there's=0Ano =
frame, and the top level (and frequently most important for=0Aanalysis) =
stack entry would get skipped:=0A=0A(XEN) ----[ Xen-4.3-unstable  x86_64  =
debug=3Dy  Not tainted ]----=0A(XEN) CPU:    1=0A(XEN) RIP:    e008:[<00000=
00000000000>] ???=0A(XEN) RFLAGS: 0000000000010046   CONTEXT: hypervisor=0A=
(XEN) rax: 0000000000000008   rbx: 0000000000000001   rcx: 0000000000000003=
=0A(XEN) rdx: 0000003db54eb700   rsi: 7fffffffffffffff   rdi: 0000000000000=
001=0A(XEN) rbp: ffff8302357e7ee0   rsp: ffff8302357e7e58   r8:  0000000000=
000000=0A(XEN) r9:  000000000000003e   r10: ffff8302357e7f18   r11: =
ffff8302357e7f18=0A(XEN) r12: ffff8302357ee340   r13: ffff82c480263980   =
r14: ffff8302357ee3d0=0A(XEN) r15: 0000000000000001   cr0: 000000008005003b=
   cr4: 00000000000026f0=0A(XEN) cr3: 00000000bf473000   cr2: 0000000000000=
000=0A(XEN) ds: 0000   es: 0000   fs: 0000   gs: 0000   ss: 0000   cs: =
e008=0A(XEN) Xen stack trace from rsp=3Dffff8302357e7e58:=0A(XEN)    =
ffff82c4801a3d05 ffff8302357eca70 0000000800000020 ffff82c4802ead60=0A(XEN)=
    0000000000000001 ffff8302357e7ea0 ffff82c48016bf07 0000000000000000=0A(=
XEN)    0000000000000000 ffff8302357e7ee0 fffff830fffff830 0000000000000046=
=0A(XEN)    ffff8302357e7f18 ffff82c480263980 ffff8302357e7f18 000000000000=
0000=0A(XEN)    0000000000000000 ffff8302357e7f10 ffff82c48015c2be =
8302357dc0000fff=0A...=0A(XEN) Xen call trace:=0A(XEN)    [<000000000000000=
0>] ???=0A(XEN)    [<ffff82c48015c2be>] idle_loop+0x6c/0x7a=0A(XEN)    =
=0A(XEN) Pagetable walk from 0000000000000000:=0A=0ASince the bad pointer =
is being printed anyway (as part of the register=0Astate), replace it with =
the top of stack value in such a case.=0A=0AWith the introduction of =
is_active_kernel_text(), use it also at the=0A(few) other suitable places =
(I intentionally didn't replace the use in=0Axen/arch/arm/mm.c - while it =
would be functionally correct, the=0Adependency on system_state wouldn't =
be from an abstract perspective).=0A=0ASigned-off-by: Jan Beulich =
<jbeulich@suse.com>=0A---=0Av2: Introduce and use is_active_kernel_text(). =
Make logic to determine=0A    what address to print at the top of =
show_trace() more readable.=0A=0A--- a/xen/arch/x86/traps.c=0A+++ =
b/xen/arch/x86/traps.c=0A@@ -199,7 +199,7 @@ static void show_trace(struct =
cpu_user_r=0A     while ( ((long)stack & (STACK_SIZE-BYTES_PER_LONG)) !=3D =
0 )=0A     {=0A         addr =3D *stack++;=0A-        if ( is_kernel_text(a=
ddr) || is_kernel_inittext(addr) )=0A+        if ( is_active_kernel_text(ad=
dr) )=0A         {=0A             printk("[<%p>]", _p(addr));=0A           =
  print_symbol(" %s\n   ", addr);=0A@@ -217,8 +217,16 @@ static void =
show_trace(struct cpu_user_r=0A =0A     printk("Xen call trace:\n   ");=0A =
=0A-    printk("[<%p>]", _p(regs->eip));=0A-    print_symbol(" %s\n   ", =
regs->eip);=0A+    /*=0A+     * If RIP is not pointing into hypervisor =
code then someone may have=0A+     * called into oblivion. Peek to see if =
they left a return address at=0A+     * top of stack.=0A+     */=0A+    =
addr =3D is_active_kernel_text(regs->eip) ||=0A+           !is_active_kerne=
l_text(*ESP_BEFORE_EXCEPTION(regs)) ?=0A+           regs->eip : *ESP_BEFORE=
_EXCEPTION(regs);=0A+    printk("[<%p>]", _p(addr));=0A+    print_symbol(" =
%s\n   ", addr);=0A =0A     /* Bounds for range of valid frame pointer. =
*/=0A     low  =3D (unsigned long)(ESP_BEFORE_EXCEPTION(regs) - 2);=0A@@ =
-322,7 +330,7 @@ void show_stack_overflow(unsigned int cp=0A     while ( =
((long)stack & (STACK_SIZE-BYTES_PER_LONG)) !=3D 0 )=0A     {=0A         =
addr =3D *stack++;=0A-        if ( is_kernel_text(addr) || is_kernel_initte=
xt(addr) )=0A+        if ( is_active_kernel_text(addr) )=0A         {=0A   =
          printk("%p: [<%p>]", stack, _p(addr));=0A             print_symbo=
l(" %s\n   ", addr);=0A--- a/xen/common/symbols.c=0A+++ b/xen/common/symbol=
s.c=0A@@ -93,6 +93,12 @@ static unsigned int get_symbol_offset(un=0A     =
return name - symbols_names;=0A }=0A =0A+bool_t is_active_kernel_text(unsig=
ned long addr)=0A+{=0A+    return (is_kernel_text(addr) ||=0A+            =
(system_state =3D=3D SYS_STATE_boot && is_kernel_inittext(addr)));=0A+}=0A+=
=0A const char *symbols_lookup(unsigned long addr,=0A                      =
      unsigned long *symbolsize,=0A                            unsigned =
long *offset,=0A@@ -104,7 +110,7 @@ const char *symbols_lookup(unsigned =
long=0A     namebuf[KSYM_NAME_LEN] =3D 0;=0A     namebuf[0] =3D 0;=0A =0A- =
   if (!is_kernel_text(addr) && !is_kernel_inittext(addr))=0A+    if =
(!is_active_kernel_text(addr))=0A         return NULL;=0A =0A         /* =
do a binary search on the sorted symbols_addresses array */=0A--- =
a/xen/include/xen/kernel.h=0A+++ b/xen/include/xen/kernel.h=0A@@ -5,6 +5,8 =
@@=0A  * 'kernel.h' contains some often-used function prototypes etc=0A  =
*/=0A =0A+#include <xen/types.h>=0A+=0A /*=0A  * min()/max() macros that =
also do=0A  * strict type-checking.. See the=0A@@ -95,5 +97,7 @@ extern =
enum system_state {=0A     SYS_STATE_resume=0A } system_state;=0A =
=0A+bool_t is_active_kernel_text(unsigned long addr);=0A+=0A #endif /* =
_LINUX_KERNEL_H */=0A =0A
--=__Part093836FB.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

--=__Part093836FB.0__=--


From xen-devel-bounces@lists.xen.org Wed Sep 26 07:17:22 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Sep 2012 07:17:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGlre-0004Jz-5P; Wed, 26 Sep 2012 07:16:58 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1TGlrd-0004Ju-7d
	for xen-devel@lists.xen.org; Wed, 26 Sep 2012 07:16:57 +0000
Received: from [85.158.138.51:35981] by server-15.bemta-3.messagelabs.com id
	74/94-18313-8EBA2605; Wed, 26 Sep 2012 07:16:56 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1348643815!23911969!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15554 invoked from network); 26 Sep 2012 07:16:56 -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;
	26 Sep 2012 07:16:56 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 26 Sep 2012 08:16:54 +0100
Message-Id: <5062C81D020000780009DE2E@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 26 Sep 2012 08:17:17 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Javier Marcet" <jmarcet@gmail.com>
References: <CC8273A0.4C9DD%keir@xen.org>
	<50605E9A020000780009D486@nat28.tlf.novell.com>
	<CAOvdn6XmB6rj3_QVU+59V8p24Y5G47AWxVEM=id02JWXkuhibQ@mail.gmail.com>
	<5060640B020000780009D4D2@nat28.tlf.novell.com>
	<CAOvdn6XLy8zR2rb2MEyi2aT9LQiFvFLY_H02p181mTsVLVTZkw@mail.gmail.com>
	<20120924122203.GG8912@reaktio.net>
	<CAOvdn6XV4eoA-FfFns1xhx7HCUqXc7KHxZwyKuT4FHG8s3R5RQ@mail.gmail.com>
	<CAAnFQG9PLQjdh6Ab6=Y5ZGM1s4nGdLekKU=pcKNMxt4rmt_RKA@mail.gmail.com>
	<20120924140411.GH31618@phenom.dumpdata.com>
	<CAAnFQG-tjv5UyF6j-TNHNgme2c4vA0Zxy8AdCiJEVsf2Z0quNA@mail.gmail.com>
	<20120925140611.GB16478@phenom.dumpdata.com>
	<CAAnFQG88ApxKuscXx53Lt2qOyCe0ws6oXSSqBDfW0+oYo5Y3nA@mail.gmail.com>
	<5061E800020000780009DBBA@nat28.tlf.novell.com>
	<CAAnFQG-6VrwaA_OcUJL5X5HBNo8PTME9pNyJbsXqSO34tbD8=g@mail.gmail.com>
In-Reply-To: <CAAnFQG-6VrwaA_OcUJL5X5HBNo8PTME9pNyJbsXqSO34tbD8=g@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Keir Fraser <keir@xen.org>, john.baboval@citrix.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	xen-devel <xen-devel@lists.xen.org>,
	Konrad Rzeszutek Wilk <konrad@kernel.org>, Ben Guthro <ben@guthro.net>,
	Thomas Goetz <thomas.goetz@citrix.com>
Subject: Re: [Xen-devel] Xen4.2 S3 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 25.09.12 at 21:55, Javier Marcet <jmarcet@gmail.com> wrote:
> Adding the additional call in xen/arch/x86/acpi/cpu_idle.c causes an
> instant reboot on resume.

That addition can hardly be responsible for a reboot. Did you
have "noreboot" (or "reboot=no") in place on the Xen command
line? "sync_console"?

And then again, for the other failure case, iirc it was the kernel
that died, not the hypervisor, so the problem there isn't directly
related to the problems here I would guess.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 26 07:17:22 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Sep 2012 07:17:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGlre-0004Jz-5P; Wed, 26 Sep 2012 07:16:58 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1TGlrd-0004Ju-7d
	for xen-devel@lists.xen.org; Wed, 26 Sep 2012 07:16:57 +0000
Received: from [85.158.138.51:35981] by server-15.bemta-3.messagelabs.com id
	74/94-18313-8EBA2605; Wed, 26 Sep 2012 07:16:56 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1348643815!23911969!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15554 invoked from network); 26 Sep 2012 07:16:56 -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;
	26 Sep 2012 07:16:56 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 26 Sep 2012 08:16:54 +0100
Message-Id: <5062C81D020000780009DE2E@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 26 Sep 2012 08:17:17 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Javier Marcet" <jmarcet@gmail.com>
References: <CC8273A0.4C9DD%keir@xen.org>
	<50605E9A020000780009D486@nat28.tlf.novell.com>
	<CAOvdn6XmB6rj3_QVU+59V8p24Y5G47AWxVEM=id02JWXkuhibQ@mail.gmail.com>
	<5060640B020000780009D4D2@nat28.tlf.novell.com>
	<CAOvdn6XLy8zR2rb2MEyi2aT9LQiFvFLY_H02p181mTsVLVTZkw@mail.gmail.com>
	<20120924122203.GG8912@reaktio.net>
	<CAOvdn6XV4eoA-FfFns1xhx7HCUqXc7KHxZwyKuT4FHG8s3R5RQ@mail.gmail.com>
	<CAAnFQG9PLQjdh6Ab6=Y5ZGM1s4nGdLekKU=pcKNMxt4rmt_RKA@mail.gmail.com>
	<20120924140411.GH31618@phenom.dumpdata.com>
	<CAAnFQG-tjv5UyF6j-TNHNgme2c4vA0Zxy8AdCiJEVsf2Z0quNA@mail.gmail.com>
	<20120925140611.GB16478@phenom.dumpdata.com>
	<CAAnFQG88ApxKuscXx53Lt2qOyCe0ws6oXSSqBDfW0+oYo5Y3nA@mail.gmail.com>
	<5061E800020000780009DBBA@nat28.tlf.novell.com>
	<CAAnFQG-6VrwaA_OcUJL5X5HBNo8PTME9pNyJbsXqSO34tbD8=g@mail.gmail.com>
In-Reply-To: <CAAnFQG-6VrwaA_OcUJL5X5HBNo8PTME9pNyJbsXqSO34tbD8=g@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Keir Fraser <keir@xen.org>, john.baboval@citrix.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	xen-devel <xen-devel@lists.xen.org>,
	Konrad Rzeszutek Wilk <konrad@kernel.org>, Ben Guthro <ben@guthro.net>,
	Thomas Goetz <thomas.goetz@citrix.com>
Subject: Re: [Xen-devel] Xen4.2 S3 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 25.09.12 at 21:55, Javier Marcet <jmarcet@gmail.com> wrote:
> Adding the additional call in xen/arch/x86/acpi/cpu_idle.c causes an
> instant reboot on resume.

That addition can hardly be responsible for a reboot. Did you
have "noreboot" (or "reboot=no") in place on the Xen command
line? "sync_console"?

And then again, for the other failure case, iirc it was the kernel
that died, not the hypervisor, so the problem there isn't directly
related to the problems here I would guess.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 26 07:32:40 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Sep 2012 07:32: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 1TGm6U-0004Uk-Rp; Wed, 26 Sep 2012 07:32:18 +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 1TGm6T-0004Uc-5n
	for xen-devel@lists.xen.org; Wed, 26 Sep 2012 07:32:17 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1348644724!6301617!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18170 invoked from network); 26 Sep 2012 07:32:06 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-5.tower-27.messagelabs.com with SMTP;
	26 Sep 2012 07:32:06 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 26 Sep 2012 08:32:03 +0100
Message-Id: <5062CBAA020000780009DE3B@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 26 Sep 2012 08:32:26 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
References: <osstest-13866-mainreport@xen.org>
In-Reply-To: <osstest-13866-mainreport@xen.org>
Mime-Version: 1.0
Content-Disposition: inline
Subject: Re: [Xen-devel] [xen-unstable test] 13866: regressions - trouble:
 broken/fail/pass
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 26.09.12 at 00:57, xen.org <ian.jackson@eu.citrix.com> wrote:
> flight 13866 xen-unstable real [real]
> http://www.chiark.greenend.org.uk/~xensrcts/logs/13866/ 
> 
> Regressions :-(
> 
> Tests which did not succeed and are blocking,
> including tests which could not be run:
>  test-amd64-i386-xl-credit2    5 xen-boot                  fail REGR. vs. 13825
>  test-amd64-i386-win-vcpus1    5 xen-boot                  fail REGR. vs. 13825
>  test-amd64-amd64-pv          10 guest-saverestore         fail REGR. vs. 13825
>  test-amd64-i386-rhel6hvm-intel  5 xen-boot                fail REGR. vs. 13825

Looking (as an example) at this failure's log, I can't see what's
wrong at all - the log suggests that boot completed fine.

The host, Dom0, and run queue state dumps also don't hint at
anything being stuck (like wakeups from deep C states not
happening).

Nevertheless, the MWAIT idle driver is to be suspected most.
I'm considering defaulting it to off for now (maybe just for the
non-ARAT case that I'm not able to test myself), but the issue
I see with this is that this may then continue to be that way
forever, if no-one gets to actually look at the problem.

Jan

>  test-amd64-amd64-win          3 host-install(3)         broken REGR. vs. 13825
>  test-amd64-amd64-xl-winxpsp3  5 xen-boot                  fail REGR. vs. 13825
>  test-amd64-i386-pair          8 xen-boot/dst_host         fail REGR. vs. 13825



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 26 07:32:40 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Sep 2012 07:32: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 1TGm6U-0004Uk-Rp; Wed, 26 Sep 2012 07:32:18 +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 1TGm6T-0004Uc-5n
	for xen-devel@lists.xen.org; Wed, 26 Sep 2012 07:32:17 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1348644724!6301617!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18170 invoked from network); 26 Sep 2012 07:32:06 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-5.tower-27.messagelabs.com with SMTP;
	26 Sep 2012 07:32:06 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 26 Sep 2012 08:32:03 +0100
Message-Id: <5062CBAA020000780009DE3B@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 26 Sep 2012 08:32:26 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
References: <osstest-13866-mainreport@xen.org>
In-Reply-To: <osstest-13866-mainreport@xen.org>
Mime-Version: 1.0
Content-Disposition: inline
Subject: Re: [Xen-devel] [xen-unstable test] 13866: regressions - trouble:
 broken/fail/pass
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 26.09.12 at 00:57, xen.org <ian.jackson@eu.citrix.com> wrote:
> flight 13866 xen-unstable real [real]
> http://www.chiark.greenend.org.uk/~xensrcts/logs/13866/ 
> 
> Regressions :-(
> 
> Tests which did not succeed and are blocking,
> including tests which could not be run:
>  test-amd64-i386-xl-credit2    5 xen-boot                  fail REGR. vs. 13825
>  test-amd64-i386-win-vcpus1    5 xen-boot                  fail REGR. vs. 13825
>  test-amd64-amd64-pv          10 guest-saverestore         fail REGR. vs. 13825
>  test-amd64-i386-rhel6hvm-intel  5 xen-boot                fail REGR. vs. 13825

Looking (as an example) at this failure's log, I can't see what's
wrong at all - the log suggests that boot completed fine.

The host, Dom0, and run queue state dumps also don't hint at
anything being stuck (like wakeups from deep C states not
happening).

Nevertheless, the MWAIT idle driver is to be suspected most.
I'm considering defaulting it to off for now (maybe just for the
non-ARAT case that I'm not able to test myself), but the issue
I see with this is that this may then continue to be that way
forever, if no-one gets to actually look at the problem.

Jan

>  test-amd64-amd64-win          3 host-install(3)         broken REGR. vs. 13825
>  test-amd64-amd64-xl-winxpsp3  5 xen-boot                  fail REGR. vs. 13825
>  test-amd64-i386-pair          8 xen-boot/dst_host         fail REGR. vs. 13825



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 26 07:34:34 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Sep 2012 07:34: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 1TGm8M-0004Zk-Bo; Wed, 26 Sep 2012 07:34:14 +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 1TGm8K-0004Zc-SD
	for xen-devel@lists.xensource.com; Wed, 26 Sep 2012 07:34:13 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1348644846!10992357!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31729 invoked from network); 26 Sep 2012 07:34:06 -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;
	26 Sep 2012 07:34:06 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 26 Sep 2012 08:34:05 +0100
Message-Id: <5062CC25020000780009DE44@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 26 Sep 2012 08:34:29 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Jinsong Liu" <jinsong.liu@intel.com>
References: <DE8DF0795D48FD4CA783C40EC8292335339547@SHSMSX101.ccr.corp.intel.com>
	<506173FB.8070603@amd.com>
	<5061A833020000780009DA1A@nat28.tlf.novell.com>
	<50619B61.2030609@amd.com>
	<DE8DF0795D48FD4CA783C40EC829233533AA6E@SHSMSX101.ccr.corp.intel.com>
In-Reply-To: <DE8DF0795D48FD4CA783C40EC829233533AA6E@SHSMSX101.ccr.corp.intel.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Christoph Egger <Christoph.Egger@amd.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"keir@xen.org" <keir@xen.org>,
	"Ian.Campbell@citrix.com" <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH 6] X86/MCE: update vMCE injection for AMD
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 26.09.12 at 05:11, "Liu, Jinsong" <jinsong.liu@intel.com> wrote:
> I fold patch 6 to patch 2, will send out later.

As I had indicated, I had done this already in preparation of things
getting committed, so you will want to check once in staging
(hopefully later today).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 26 07:34:34 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Sep 2012 07:34: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 1TGm8M-0004Zk-Bo; Wed, 26 Sep 2012 07:34:14 +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 1TGm8K-0004Zc-SD
	for xen-devel@lists.xensource.com; Wed, 26 Sep 2012 07:34:13 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-16.tower-27.messagelabs.com!1348644846!10992357!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31729 invoked from network); 26 Sep 2012 07:34:06 -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;
	26 Sep 2012 07:34:06 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 26 Sep 2012 08:34:05 +0100
Message-Id: <5062CC25020000780009DE44@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 26 Sep 2012 08:34:29 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Jinsong Liu" <jinsong.liu@intel.com>
References: <DE8DF0795D48FD4CA783C40EC8292335339547@SHSMSX101.ccr.corp.intel.com>
	<506173FB.8070603@amd.com>
	<5061A833020000780009DA1A@nat28.tlf.novell.com>
	<50619B61.2030609@amd.com>
	<DE8DF0795D48FD4CA783C40EC829233533AA6E@SHSMSX101.ccr.corp.intel.com>
In-Reply-To: <DE8DF0795D48FD4CA783C40EC829233533AA6E@SHSMSX101.ccr.corp.intel.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Christoph Egger <Christoph.Egger@amd.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"keir@xen.org" <keir@xen.org>,
	"Ian.Campbell@citrix.com" <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH 6] X86/MCE: update vMCE injection for AMD
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 26.09.12 at 05:11, "Liu, Jinsong" <jinsong.liu@intel.com> wrote:
> I fold patch 6 to patch 2, will send out later.

As I had indicated, I had done this already in preparation of things
getting committed, so you will want to check once in staging
(hopefully later today).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 26 07:54:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Sep 2012 07:54:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGmRt-0004qB-46; Wed, 26 Sep 2012 07:54:25 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1TGmRr-0004q6-R2
	for xen-devel@lists.xen.org; Wed, 26 Sep 2012 07:54:24 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1348646057!7221217!1
X-Originating-IP: [74.125.82.51]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26768 invoked from network); 26 Sep 2012 07:54:17 -0000
Received: from mail-wg0-f51.google.com (HELO mail-wg0-f51.google.com)
	(74.125.82.51)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Sep 2012 07:54:17 -0000
Received: by wgbed3 with SMTP id ed3so185303wgb.32
	for <xen-devel@lists.xen.org>; Wed, 26 Sep 2012 00:54: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=dBWxXOXpSK+5HG/kGVhy6lDI/FmgClcgI+lHsmgxApU=;
	b=xULpTAjsU6qBBZzzrSC2Sb8aLHBuCuJID5EubUxJM7Qqa3uElh6zuj9IxzW/+2X9kt
	ZBZVP48ITZwsrArY6Y0yR0oaoKkyoSf1zqq1CK2kwXv799y4ZRQKssKdy7syZQLhge9w
	waFh6aPkrbxZEc7Jj0+xioC4w2uw84Z32snvfBBn5x4PaUjqT7hrcpHmpFQ8rL6v5kyC
	MhznkWfKJIqA7A2SdHN9p9m9Oj83W4sv+u+ONWAIkl24zDl+ly576egxm8vSHAzMVGQF
	f4niygrrytvhpqwDjAypIejBZK2uSRCX2bQgv8adGy5x5eCamVVsPcdLli0cVrT5pug2
	fqew==
Received: by 10.180.109.199 with SMTP id hu7mr19501131wib.21.1348646057548;
	Wed, 26 Sep 2012 00:54:17 -0700 (PDT)
Received: from [192.168.1.3] (host86-167-82-156.range86-167.btcentralplus.com.
	[86.167.82.156])
	by mx.google.com with ESMTPS id fb20sm5331894wid.1.2012.09.26.00.54.15
	(version=SSLv3 cipher=OTHER); Wed, 26 Sep 2012 00:54:17 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.33.0.120411
Date: Wed, 26 Sep 2012 08:54:13 +0100
From: Keir Fraser <keir@xen.org>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <CC887335.4CE74%keir@xen.org>
Thread-Topic: [PATCH, v2] x86: slightly improve stack trace on debug builds
Thread-Index: Ac2bvB5pihgt7GxPrUKWPT2WQqo+eg==
In-Reply-To: <5062C50B020000780009DE1C@nat28.tlf.novell.com>
Mime-version: 1.0
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH,
	v2] x86: slightly improve stack trace on debug builds
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/09/2012 08:04, "Jan Beulich" <JBeulich@suse.com> wrote:

> As was rather obvious from crashes recently happening in stage testing,
> the debug hypervisor, in that special case, has a drawback compared to
> the non-debug one: When a call through a bad pointer happens, there's
> no frame, and the top level (and frequently most important for
> analysis) stack entry would get skipped:
> 
...
> 
> Since the bad pointer is being printed anyway (as part of the register
> state), replace it with the top of stack value in such a case.
> 
> With the introduction of is_active_kernel_text(), use it also at the
> (few) other suitable places (I intentionally didn't replace the use in
> xen/arch/arm/mm.c - while it would be functionally correct, the
> dependency on system_state wouldn't be from an abstract perspective).
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Acked-by: Keir Fraser <keir@xen.org>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 26 07:54:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Sep 2012 07:54:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGmRt-0004qB-46; Wed, 26 Sep 2012 07:54:25 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1TGmRr-0004q6-R2
	for xen-devel@lists.xen.org; Wed, 26 Sep 2012 07:54:24 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1348646057!7221217!1
X-Originating-IP: [74.125.82.51]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26768 invoked from network); 26 Sep 2012 07:54:17 -0000
Received: from mail-wg0-f51.google.com (HELO mail-wg0-f51.google.com)
	(74.125.82.51)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Sep 2012 07:54:17 -0000
Received: by wgbed3 with SMTP id ed3so185303wgb.32
	for <xen-devel@lists.xen.org>; Wed, 26 Sep 2012 00:54: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=dBWxXOXpSK+5HG/kGVhy6lDI/FmgClcgI+lHsmgxApU=;
	b=xULpTAjsU6qBBZzzrSC2Sb8aLHBuCuJID5EubUxJM7Qqa3uElh6zuj9IxzW/+2X9kt
	ZBZVP48ITZwsrArY6Y0yR0oaoKkyoSf1zqq1CK2kwXv799y4ZRQKssKdy7syZQLhge9w
	waFh6aPkrbxZEc7Jj0+xioC4w2uw84Z32snvfBBn5x4PaUjqT7hrcpHmpFQ8rL6v5kyC
	MhznkWfKJIqA7A2SdHN9p9m9Oj83W4sv+u+ONWAIkl24zDl+ly576egxm8vSHAzMVGQF
	f4niygrrytvhpqwDjAypIejBZK2uSRCX2bQgv8adGy5x5eCamVVsPcdLli0cVrT5pug2
	fqew==
Received: by 10.180.109.199 with SMTP id hu7mr19501131wib.21.1348646057548;
	Wed, 26 Sep 2012 00:54:17 -0700 (PDT)
Received: from [192.168.1.3] (host86-167-82-156.range86-167.btcentralplus.com.
	[86.167.82.156])
	by mx.google.com with ESMTPS id fb20sm5331894wid.1.2012.09.26.00.54.15
	(version=SSLv3 cipher=OTHER); Wed, 26 Sep 2012 00:54:17 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.33.0.120411
Date: Wed, 26 Sep 2012 08:54:13 +0100
From: Keir Fraser <keir@xen.org>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <CC887335.4CE74%keir@xen.org>
Thread-Topic: [PATCH, v2] x86: slightly improve stack trace on debug builds
Thread-Index: Ac2bvB5pihgt7GxPrUKWPT2WQqo+eg==
In-Reply-To: <5062C50B020000780009DE1C@nat28.tlf.novell.com>
Mime-version: 1.0
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH,
	v2] x86: slightly improve stack trace on debug builds
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/09/2012 08:04, "Jan Beulich" <JBeulich@suse.com> wrote:

> As was rather obvious from crashes recently happening in stage testing,
> the debug hypervisor, in that special case, has a drawback compared to
> the non-debug one: When a call through a bad pointer happens, there's
> no frame, and the top level (and frequently most important for
> analysis) stack entry would get skipped:
> 
...
> 
> Since the bad pointer is being printed anyway (as part of the register
> state), replace it with the top of stack value in such a case.
> 
> With the introduction of is_active_kernel_text(), use it also at the
> (few) other suitable places (I intentionally didn't replace the use in
> xen/arch/arm/mm.c - while it would be functionally correct, the
> dependency on system_state wouldn't be from an abstract perspective).
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Acked-by: Keir Fraser <keir@xen.org>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 26 07:59:53 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Sep 2012 07:59:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGmWp-0004yO-Rs; Wed, 26 Sep 2012 07:59:31 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jmarcet@gmail.com>) id 1TGmWo-0004yI-AC
	for xen-devel@lists.xen.org; Wed, 26 Sep 2012 07:59:30 +0000
Received: from [85.158.139.211:32926] by server-11.bemta-5.messagelabs.com id
	26/2D-13866-1E5B2605; Wed, 26 Sep 2012 07:59:29 +0000
X-Env-Sender: jmarcet@gmail.com
X-Msg-Ref: server-5.tower-206.messagelabs.com!1348646367!19943706!1
X-Originating-IP: [209.85.214.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1696 invoked from network); 26 Sep 2012 07:59:29 -0000
Received: from mail-ob0-f173.google.com (HELO mail-ob0-f173.google.com)
	(209.85.214.173)
	by server-5.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Sep 2012 07:59:29 -0000
Received: by obbta14 with SMTP id ta14so405768obb.32
	for <xen-devel@lists.xen.org>; Wed, 26 Sep 2012 00:59: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:from:date:message-id:subject:to
	:cc:content-type;
	bh=db4eHG34wQ/RJgmHjzXFs8EGTrKNMxdoQAbIvuOr07M=;
	b=XBBwI+lJFuW5etzsFPkksHBGaNFNZrRLXqgHzOty/sPeOlKRvVhasX7wKIe6ObjacF
	E2GLj42/nkuTlwqyBfs8Pb6p9HE9G5Ogd6+DkLIrqkicnZs2xmjHU5mJaL5PPJxxe2fC
	BRAnLrIDQLqcMJQ6z8O0fVYCwKVntFsqfw2HRWCxVOc03A5Iogh13jZVuktD+vO5p5zR
	RX0iTUofB7Ozs+i7KXdYgvvW+ZBDKcfTSFyHT0YxzrpYxWNS33yBxHA6RBWITociWPIS
	mzbpKmV63IY44cXH7dPuRBLG8QysjziMncZG+LUttrHPJXL9XKtAeo2zuDDkLo5E8+eo
	78dg==
Received: by 10.182.177.7 with SMTP id cm7mr14343308obc.17.1348646367358; Wed,
	26 Sep 2012 00:59:27 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.60.138.225 with HTTP; Wed, 26 Sep 2012 00:59:07 -0700 (PDT)
In-Reply-To: <5062C81D020000780009DE2E@nat28.tlf.novell.com>
References: <CC8273A0.4C9DD%keir@xen.org>
	<50605E9A020000780009D486@nat28.tlf.novell.com>
	<CAOvdn6XmB6rj3_QVU+59V8p24Y5G47AWxVEM=id02JWXkuhibQ@mail.gmail.com>
	<5060640B020000780009D4D2@nat28.tlf.novell.com>
	<CAOvdn6XLy8zR2rb2MEyi2aT9LQiFvFLY_H02p181mTsVLVTZkw@mail.gmail.com>
	<20120924122203.GG8912@reaktio.net>
	<CAOvdn6XV4eoA-FfFns1xhx7HCUqXc7KHxZwyKuT4FHG8s3R5RQ@mail.gmail.com>
	<CAAnFQG9PLQjdh6Ab6=Y5ZGM1s4nGdLekKU=pcKNMxt4rmt_RKA@mail.gmail.com>
	<20120924140411.GH31618@phenom.dumpdata.com>
	<CAAnFQG-tjv5UyF6j-TNHNgme2c4vA0Zxy8AdCiJEVsf2Z0quNA@mail.gmail.com>
	<20120925140611.GB16478@phenom.dumpdata.com>
	<CAAnFQG88ApxKuscXx53Lt2qOyCe0ws6oXSSqBDfW0+oYo5Y3nA@mail.gmail.com>
	<5061E800020000780009DBBA@nat28.tlf.novell.com>
	<CAAnFQG-6VrwaA_OcUJL5X5HBNo8PTME9pNyJbsXqSO34tbD8=g@mail.gmail.com>
	<5062C81D020000780009DE2E@nat28.tlf.novell.com>
From: Javier Marcet <jmarcet@gmail.com>
Date: Wed, 26 Sep 2012 09:59:07 +0200
Message-ID: <CAAnFQG9f-97RQTt0YNGds6q9FDRcLEOAXrAdZuJw_p=+3opn7Q@mail.gmail.com>
To: Jan Beulich <JBeulich@suse.com>
Cc: Keir Fraser <keir@xen.org>, john.baboval@citrix.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	xen-devel <xen-devel@lists.xen.org>,
	Konrad Rzeszutek Wilk <konrad@kernel.org>, Ben Guthro <ben@guthro.net>,
	Thomas Goetz <thomas.goetz@citrix.com>
Subject: Re: [Xen-devel] Xen4.2 S3 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 Wed, Sep 26, 2012 at 9:17 AM, Jan Beulich <JBeulich@suse.com> wrote:

>> Adding the additional call in xen/arch/x86/acpi/cpu_idle.c causes an
>> instant reboot on resume.
>
> That addition can hardly be responsible for a reboot. Did you

Just like I could perform a full cycle without issues, the instant
reboot might as well be another way the race ends.

> have "noreboot" (or "reboot=no") in place on the Xen command
> line? "sync_console"?

Neither of them. I have used the sync_console parameter to check
whether it changed anything but I removed it afterwards.

> And then again, for the other failure case, iirc it was the kernel
> that died, not the hypervisor, so the problem there isn't directly
> related to the problems here I would guess.

All I know is that I'm using that same kernel without hypervisor, with
lots of suspend/resume and not a single issue.

With the two kernel patches from Konrad added I can also suspend and
resume fine under the hypervisor but there is always a cpu which
receives an irq while offline.


-- 
Javier Marcet <jmarcet@gmail.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 26 07:59:53 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Sep 2012 07:59:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGmWp-0004yO-Rs; Wed, 26 Sep 2012 07:59:31 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jmarcet@gmail.com>) id 1TGmWo-0004yI-AC
	for xen-devel@lists.xen.org; Wed, 26 Sep 2012 07:59:30 +0000
Received: from [85.158.139.211:32926] by server-11.bemta-5.messagelabs.com id
	26/2D-13866-1E5B2605; Wed, 26 Sep 2012 07:59:29 +0000
X-Env-Sender: jmarcet@gmail.com
X-Msg-Ref: server-5.tower-206.messagelabs.com!1348646367!19943706!1
X-Originating-IP: [209.85.214.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1696 invoked from network); 26 Sep 2012 07:59:29 -0000
Received: from mail-ob0-f173.google.com (HELO mail-ob0-f173.google.com)
	(209.85.214.173)
	by server-5.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Sep 2012 07:59:29 -0000
Received: by obbta14 with SMTP id ta14so405768obb.32
	for <xen-devel@lists.xen.org>; Wed, 26 Sep 2012 00:59: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:from:date:message-id:subject:to
	:cc:content-type;
	bh=db4eHG34wQ/RJgmHjzXFs8EGTrKNMxdoQAbIvuOr07M=;
	b=XBBwI+lJFuW5etzsFPkksHBGaNFNZrRLXqgHzOty/sPeOlKRvVhasX7wKIe6ObjacF
	E2GLj42/nkuTlwqyBfs8Pb6p9HE9G5Ogd6+DkLIrqkicnZs2xmjHU5mJaL5PPJxxe2fC
	BRAnLrIDQLqcMJQ6z8O0fVYCwKVntFsqfw2HRWCxVOc03A5Iogh13jZVuktD+vO5p5zR
	RX0iTUofB7Ozs+i7KXdYgvvW+ZBDKcfTSFyHT0YxzrpYxWNS33yBxHA6RBWITociWPIS
	mzbpKmV63IY44cXH7dPuRBLG8QysjziMncZG+LUttrHPJXL9XKtAeo2zuDDkLo5E8+eo
	78dg==
Received: by 10.182.177.7 with SMTP id cm7mr14343308obc.17.1348646367358; Wed,
	26 Sep 2012 00:59:27 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.60.138.225 with HTTP; Wed, 26 Sep 2012 00:59:07 -0700 (PDT)
In-Reply-To: <5062C81D020000780009DE2E@nat28.tlf.novell.com>
References: <CC8273A0.4C9DD%keir@xen.org>
	<50605E9A020000780009D486@nat28.tlf.novell.com>
	<CAOvdn6XmB6rj3_QVU+59V8p24Y5G47AWxVEM=id02JWXkuhibQ@mail.gmail.com>
	<5060640B020000780009D4D2@nat28.tlf.novell.com>
	<CAOvdn6XLy8zR2rb2MEyi2aT9LQiFvFLY_H02p181mTsVLVTZkw@mail.gmail.com>
	<20120924122203.GG8912@reaktio.net>
	<CAOvdn6XV4eoA-FfFns1xhx7HCUqXc7KHxZwyKuT4FHG8s3R5RQ@mail.gmail.com>
	<CAAnFQG9PLQjdh6Ab6=Y5ZGM1s4nGdLekKU=pcKNMxt4rmt_RKA@mail.gmail.com>
	<20120924140411.GH31618@phenom.dumpdata.com>
	<CAAnFQG-tjv5UyF6j-TNHNgme2c4vA0Zxy8AdCiJEVsf2Z0quNA@mail.gmail.com>
	<20120925140611.GB16478@phenom.dumpdata.com>
	<CAAnFQG88ApxKuscXx53Lt2qOyCe0ws6oXSSqBDfW0+oYo5Y3nA@mail.gmail.com>
	<5061E800020000780009DBBA@nat28.tlf.novell.com>
	<CAAnFQG-6VrwaA_OcUJL5X5HBNo8PTME9pNyJbsXqSO34tbD8=g@mail.gmail.com>
	<5062C81D020000780009DE2E@nat28.tlf.novell.com>
From: Javier Marcet <jmarcet@gmail.com>
Date: Wed, 26 Sep 2012 09:59:07 +0200
Message-ID: <CAAnFQG9f-97RQTt0YNGds6q9FDRcLEOAXrAdZuJw_p=+3opn7Q@mail.gmail.com>
To: Jan Beulich <JBeulich@suse.com>
Cc: Keir Fraser <keir@xen.org>, john.baboval@citrix.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	xen-devel <xen-devel@lists.xen.org>,
	Konrad Rzeszutek Wilk <konrad@kernel.org>, Ben Guthro <ben@guthro.net>,
	Thomas Goetz <thomas.goetz@citrix.com>
Subject: Re: [Xen-devel] Xen4.2 S3 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 Wed, Sep 26, 2012 at 9:17 AM, Jan Beulich <JBeulich@suse.com> wrote:

>> Adding the additional call in xen/arch/x86/acpi/cpu_idle.c causes an
>> instant reboot on resume.
>
> That addition can hardly be responsible for a reboot. Did you

Just like I could perform a full cycle without issues, the instant
reboot might as well be another way the race ends.

> have "noreboot" (or "reboot=no") in place on the Xen command
> line? "sync_console"?

Neither of them. I have used the sync_console parameter to check
whether it changed anything but I removed it afterwards.

> And then again, for the other failure case, iirc it was the kernel
> that died, not the hypervisor, so the problem there isn't directly
> related to the problems here I would guess.

All I know is that I'm using that same kernel without hypervisor, with
lots of suspend/resume and not a single issue.

With the two kernel patches from Konrad added I can also suspend and
resume fine under the hypervisor but there is always a cpu which
receives an irq while offline.


-- 
Javier Marcet <jmarcet@gmail.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 26 08:06:27 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Sep 2012 08: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 1TGmdC-0005ao-Tv; Wed, 26 Sep 2012 08:06:06 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jmarcet@gmail.com>) id 1TGmdB-0005aj-E8
	for xen-devel@lists.xen.org; Wed, 26 Sep 2012 08:06:05 +0000
Received: from [85.158.143.99:10958] by server-1.bemta-4.messagelabs.com id
	2F/20-05684-C67B2605; Wed, 26 Sep 2012 08:06:04 +0000
X-Env-Sender: jmarcet@gmail.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1348646762!31832684!1
X-Originating-IP: [209.85.214.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14440 invoked from network); 26 Sep 2012 08:06:04 -0000
Received: from mail-ob0-f173.google.com (HELO mail-ob0-f173.google.com)
	(209.85.214.173)
	by server-9.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Sep 2012 08:06:04 -0000
Received: by obbta14 with SMTP id ta14so412124obb.32
	for <xen-devel@lists.xen.org>; Wed, 26 Sep 2012 01:06: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
	:cc:content-type;
	bh=XyzGBhRrJr+ssneylB09XM0xoJoNbQpzUv6AZWdqioc=;
	b=mRzAPREveAPQCAcsDO37COU0KC+y2qEnn8WgRUhTKMgx91rSLRppQgb8yp4FP+vKYB
	GEMTW1ylkw/X1N7PuqKVsWgA8Gu70tAAoRemjP6xmb7inKHpp2aHLr/0Oi/ZO96p80Dh
	CCqsVSG6hHtZdwrJ2FWIY/Lbb+mMNk1udC/chmXJzexBE2l2SgH5OcSlQHxJz/DQ/iXw
	WwNlpatu+IkK2RIvFbMjg6JS+/P6HyBz1OBbNovoIIe78vS2kveeUWXwVZRyv7u1lDgc
	i8oJp73T4OiOM+J52CKYLH3tAntZf6gNXVKqt/Se4HE68Kya4VmHdoGocov5Ei3RBx24
	0mYg==
Received: by 10.182.172.74 with SMTP id ba10mr14571039obc.83.1348646762575;
	Wed, 26 Sep 2012 01:06:02 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.60.138.225 with HTTP; Wed, 26 Sep 2012 01:05:42 -0700 (PDT)
In-Reply-To: <5062C81D020000780009DE2E@nat28.tlf.novell.com>
References: <CC8273A0.4C9DD%keir@xen.org>
	<50605E9A020000780009D486@nat28.tlf.novell.com>
	<CAOvdn6XmB6rj3_QVU+59V8p24Y5G47AWxVEM=id02JWXkuhibQ@mail.gmail.com>
	<5060640B020000780009D4D2@nat28.tlf.novell.com>
	<CAOvdn6XLy8zR2rb2MEyi2aT9LQiFvFLY_H02p181mTsVLVTZkw@mail.gmail.com>
	<20120924122203.GG8912@reaktio.net>
	<CAOvdn6XV4eoA-FfFns1xhx7HCUqXc7KHxZwyKuT4FHG8s3R5RQ@mail.gmail.com>
	<CAAnFQG9PLQjdh6Ab6=Y5ZGM1s4nGdLekKU=pcKNMxt4rmt_RKA@mail.gmail.com>
	<20120924140411.GH31618@phenom.dumpdata.com>
	<CAAnFQG-tjv5UyF6j-TNHNgme2c4vA0Zxy8AdCiJEVsf2Z0quNA@mail.gmail.com>
	<20120925140611.GB16478@phenom.dumpdata.com>
	<CAAnFQG88ApxKuscXx53Lt2qOyCe0ws6oXSSqBDfW0+oYo5Y3nA@mail.gmail.com>
	<5061E800020000780009DBBA@nat28.tlf.novell.com>
	<CAAnFQG-6VrwaA_OcUJL5X5HBNo8PTME9pNyJbsXqSO34tbD8=g@mail.gmail.com>
	<5062C81D020000780009DE2E@nat28.tlf.novell.com>
From: Javier Marcet <jmarcet@gmail.com>
Date: Wed, 26 Sep 2012 10:05:42 +0200
Message-ID: <CAAnFQG_2TBtAcc+Bak=66dx2qPerO2JM2eRXTj=kiCkkmmngcw@mail.gmail.com>
To: Jan Beulich <JBeulich@suse.com>
Cc: Keir Fraser <keir@xen.org>, john.baboval@citrix.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	xen-devel <xen-devel@lists.xen.org>,
	Konrad Rzeszutek Wilk <konrad@kernel.org>, Ben Guthro <ben@guthro.net>,
	Thomas Goetz <thomas.goetz@citrix.com>
Subject: Re: [Xen-devel] Xen4.2 S3 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 Wed, Sep 26, 2012 at 9:17 AM, Jan Beulich <JBeulich@suse.com> wrote:

>> Adding the additional call in xen/arch/x86/acpi/cpu_idle.c causes an
>> instant reboot on resume.
>
> That addition can hardly be responsible for a reboot. Did you
> have "noreboot" (or "reboot=no") in place on the Xen command
> line? "sync_console"?
>
> And then again, for the other failure case, iirc it was the kernel
> that died, not the hypervisor, so the problem there isn't directly
> related to the problems here I would guess.

By the way, I still don't have a serial console ready. I should have
it soon, one-two weeks tops. In the meantime, although I have very
little time right now due to what I haven't  followed all the steps
Ben has taken, I'm willing to try anything you deem worth it.


-- 
Javier Marcet <jmarcet@gmail.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 26 08:06:27 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Sep 2012 08: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 1TGmdC-0005ao-Tv; Wed, 26 Sep 2012 08:06:06 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jmarcet@gmail.com>) id 1TGmdB-0005aj-E8
	for xen-devel@lists.xen.org; Wed, 26 Sep 2012 08:06:05 +0000
Received: from [85.158.143.99:10958] by server-1.bemta-4.messagelabs.com id
	2F/20-05684-C67B2605; Wed, 26 Sep 2012 08:06:04 +0000
X-Env-Sender: jmarcet@gmail.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1348646762!31832684!1
X-Originating-IP: [209.85.214.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14440 invoked from network); 26 Sep 2012 08:06:04 -0000
Received: from mail-ob0-f173.google.com (HELO mail-ob0-f173.google.com)
	(209.85.214.173)
	by server-9.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Sep 2012 08:06:04 -0000
Received: by obbta14 with SMTP id ta14so412124obb.32
	for <xen-devel@lists.xen.org>; Wed, 26 Sep 2012 01:06: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
	:cc:content-type;
	bh=XyzGBhRrJr+ssneylB09XM0xoJoNbQpzUv6AZWdqioc=;
	b=mRzAPREveAPQCAcsDO37COU0KC+y2qEnn8WgRUhTKMgx91rSLRppQgb8yp4FP+vKYB
	GEMTW1ylkw/X1N7PuqKVsWgA8Gu70tAAoRemjP6xmb7inKHpp2aHLr/0Oi/ZO96p80Dh
	CCqsVSG6hHtZdwrJ2FWIY/Lbb+mMNk1udC/chmXJzexBE2l2SgH5OcSlQHxJz/DQ/iXw
	WwNlpatu+IkK2RIvFbMjg6JS+/P6HyBz1OBbNovoIIe78vS2kveeUWXwVZRyv7u1lDgc
	i8oJp73T4OiOM+J52CKYLH3tAntZf6gNXVKqt/Se4HE68Kya4VmHdoGocov5Ei3RBx24
	0mYg==
Received: by 10.182.172.74 with SMTP id ba10mr14571039obc.83.1348646762575;
	Wed, 26 Sep 2012 01:06:02 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.60.138.225 with HTTP; Wed, 26 Sep 2012 01:05:42 -0700 (PDT)
In-Reply-To: <5062C81D020000780009DE2E@nat28.tlf.novell.com>
References: <CC8273A0.4C9DD%keir@xen.org>
	<50605E9A020000780009D486@nat28.tlf.novell.com>
	<CAOvdn6XmB6rj3_QVU+59V8p24Y5G47AWxVEM=id02JWXkuhibQ@mail.gmail.com>
	<5060640B020000780009D4D2@nat28.tlf.novell.com>
	<CAOvdn6XLy8zR2rb2MEyi2aT9LQiFvFLY_H02p181mTsVLVTZkw@mail.gmail.com>
	<20120924122203.GG8912@reaktio.net>
	<CAOvdn6XV4eoA-FfFns1xhx7HCUqXc7KHxZwyKuT4FHG8s3R5RQ@mail.gmail.com>
	<CAAnFQG9PLQjdh6Ab6=Y5ZGM1s4nGdLekKU=pcKNMxt4rmt_RKA@mail.gmail.com>
	<20120924140411.GH31618@phenom.dumpdata.com>
	<CAAnFQG-tjv5UyF6j-TNHNgme2c4vA0Zxy8AdCiJEVsf2Z0quNA@mail.gmail.com>
	<20120925140611.GB16478@phenom.dumpdata.com>
	<CAAnFQG88ApxKuscXx53Lt2qOyCe0ws6oXSSqBDfW0+oYo5Y3nA@mail.gmail.com>
	<5061E800020000780009DBBA@nat28.tlf.novell.com>
	<CAAnFQG-6VrwaA_OcUJL5X5HBNo8PTME9pNyJbsXqSO34tbD8=g@mail.gmail.com>
	<5062C81D020000780009DE2E@nat28.tlf.novell.com>
From: Javier Marcet <jmarcet@gmail.com>
Date: Wed, 26 Sep 2012 10:05:42 +0200
Message-ID: <CAAnFQG_2TBtAcc+Bak=66dx2qPerO2JM2eRXTj=kiCkkmmngcw@mail.gmail.com>
To: Jan Beulich <JBeulich@suse.com>
Cc: Keir Fraser <keir@xen.org>, john.baboval@citrix.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	xen-devel <xen-devel@lists.xen.org>,
	Konrad Rzeszutek Wilk <konrad@kernel.org>, Ben Guthro <ben@guthro.net>,
	Thomas Goetz <thomas.goetz@citrix.com>
Subject: Re: [Xen-devel] Xen4.2 S3 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 Wed, Sep 26, 2012 at 9:17 AM, Jan Beulich <JBeulich@suse.com> wrote:

>> Adding the additional call in xen/arch/x86/acpi/cpu_idle.c causes an
>> instant reboot on resume.
>
> That addition can hardly be responsible for a reboot. Did you
> have "noreboot" (or "reboot=no") in place on the Xen command
> line? "sync_console"?
>
> And then again, for the other failure case, iirc it was the kernel
> that died, not the hypervisor, so the problem there isn't directly
> related to the problems here I would guess.

By the way, I still don't have a serial console ready. I should have
it soon, one-two weeks tops. In the meantime, although I have very
little time right now due to what I haven't  followed all the steps
Ben has taken, I'm willing to try anything you deem worth it.


-- 
Javier Marcet <jmarcet@gmail.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 26 08:25:01 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Sep 2012 08: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 1TGmvB-0005ll-O8; Wed, 26 Sep 2012 08:24:41 +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 1TGmvA-0005lg-6c
	for xen-devel@lists.xen.org; Wed, 26 Sep 2012 08:24:40 +0000
Received: from [85.158.143.99:2636] by server-1.bemta-4.messagelabs.com id
	84/0F-05684-7CBB2605; Wed, 26 Sep 2012 08:24:39 +0000
X-Env-Sender: xudong.hao@intel.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1348647876!24281565!1
X-Originating-IP: [143.182.124.21]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMjEgPT4gMjA5MTA0\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4689 invoked from network); 26 Sep 2012 08:24:37 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (143.182.124.21)
	by server-11.tower-216.messagelabs.com with SMTP;
	26 Sep 2012 08:24:37 -0000
Received: from azsmga001.ch.intel.com ([10.2.17.19])
	by azsmga101.ch.intel.com with ESMTP; 26 Sep 2012 01:24:35 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.80,489,1344236400"; d="scan'208";a="197254858"
Received: from fmsmsx105.amr.corp.intel.com ([10.19.9.36])
	by azsmga001.ch.intel.com with ESMTP; 26 Sep 2012 01:24:35 -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; Wed, 26 Sep 2012 01:24:34 -0700
Received: from shsmsx102.ccr.corp.intel.com ([169.254.2.92]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.175]) with mapi id
	14.01.0355.002; Wed, 26 Sep 2012 16:24:33 +0800
From: "Hao, Xudong" <xudong.hao@intel.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Thread-Topic: [PATCH v2] qemu/xen: Add 64 bits big bar support on qemu
Thread-Index: AQHNms7UWaIyHrSFlE24ZH5C7S6v25eaW+6AgAHhrOA=
Date: Wed, 26 Sep 2012 08:24:32 +0000
Message-ID: <403610A45A2B5242BD291EDAE8B37D300FEC73C5@SHSMSX102.ccr.corp.intel.com>
References: <1348544326-31334-1-git-send-email-xudong.hao@intel.com>
	<alpine.DEB.2.02.1209251134460.29232@kaball.uk.xensource.com>
In-Reply-To: <alpine.DEB.2.02.1209251134460.29232@kaball.uk.xensource.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: "qemu-devel@nongnu.org" <qemu-devel@nongnu.org>, "Zhang,
	Xiantao" <xiantao.zhang@intel.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v2] qemu/xen: Add 64 bits big bar support on
	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

> -----Original Message-----
> From: Stefano Stabellini [mailto:stefano.stabellini@eu.citrix.com]
> Sent: Tuesday, September 25, 2012 6:52 PM
> To: Hao, Xudong
> Cc: Stefano Stabellini; xen-devel@lists.xen.org; qemu-devel@nongnu.org;
> Zhang, Xiantao
> Subject: Re: [PATCH v2] qemu/xen: Add 64 bits big bar support on qemu
> 
> On Tue, 25 Sep 2012, Xudong Hao wrote:
> > Changes from v1:
> > - Rebase to qemu upstream from qemu-xen
> 
> Thanks. Please run scripts/checkpatch.pl on this patch, you'll find
> some cody style issues that need to be fixed.
> 
OK, will use this scripts to check code style.

> 
> > Currently it is assumed PCI device BAR access < 4G memory. If there is such a
> > device whose BAR size is larger than 4G, it must access > 4G memory
> address.
> > This patch enable the 64bits big BAR support on qemu.
> >
> > Signed-off-by: Xudong Hao <xudong.hao@intel.com>
> > Signed-off-by: Xiantao Zhang <xiantao.zhang@intel.com>
> > ---
> >  hw/xen_pt.c             |   16 ++++++++--------
> >  hw/xen_pt_config_init.c |   42
> +++++++++++++++++++++++++++++-------------
> >
> > diff --git a/hw/xen_pt.c b/hw/xen_pt.c
> > index 307119a..2a8bcf3 100644
> > --- a/hw/xen_pt.c
> > +++ b/hw/xen_pt.c
> > @@ -403,21 +403,21 @@ static int
> xen_pt_register_regions(XenPCIPassthroughState *s)
> >
> >          s->bases[i].access.u = r->base_addr;
> >
> > -        if (r->type & XEN_HOST_PCI_REGION_TYPE_IO) {
> > +        if (r->type & XEN_HOST_PCI_REGION_TYPE_IO)
> >              type = PCI_BASE_ADDRESS_SPACE_IO;
> > -        } else {
> > +        else if (r->type & XEN_HOST_PCI_REGION_TYPE_MEM_64)
> > +            type = PCI_BASE_ADDRESS_MEM_TYPE_64;
> > +        else if (r->type & XEN_HOST_PCI_REGION_TYPE_PREFETCH)
> > +            type |= PCI_BASE_ADDRESS_MEM_PREFETCH;
> > +        else
> >              type = PCI_BASE_ADDRESS_SPACE_MEMORY;
> > -            if (r->type & XEN_HOST_PCI_REGION_TYPE_PREFETCH) {
> > -                type |= PCI_BASE_ADDRESS_MEM_PREFETCH;
> > -            }
> > -        }
> 
> Aside from the cody style issue here, this changes the behavior for type
> PCI_BASE_ADDRESS_SPACE_MEMORY. Before we could have:
> 
> type =
> PCI_BASE_ADDRESS_SPACE_MEMORY|PCI_BASE_ADDRESS_MEM_PREFETCH;
> 
> now we cannot anymore.
> 

Will change to:
-        if (r->type & XEN_HOST_PCI_REGION_TYPE_IO) {
+        if (r->type & XEN_HOST_PCI_REGION_TYPE_IO)
             type = PCI_BASE_ADDRESS_SPACE_IO;
-        } else {
+        else
             type = PCI_BASE_ADDRESS_SPACE_MEMORY;
-            if (r->type & XEN_HOST_PCI_REGION_TYPE_PREFETCH) {
+            if (r->type & XEN_HOST_PCI_REGION_TYPE_MEM_64)
+                type |= PCI_BASE_ADDRESS_MEM_TYPE_64;
+           else 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",
> > +        XEN_PT_LOG(&s->dev, "IO region %i registered
> (size=0x%lx"PRIx64
> > +                   " base_addr=0x%lx"PRIx64" type: %#x)\n",
> >                     i, r->size, r->base_addr, type);
> >      }
> >
> > diff --git a/hw/xen_pt_config_init.c b/hw/xen_pt_config_init.c
> > index e524a40..5e7ca22 100644
> > --- a/hw/xen_pt_config_init.c
> > +++ b/hw/xen_pt_config_init.c
> > @@ -342,6 +342,7 @@ static int
> xen_pt_cmd_reg_write(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
> >  #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 uint64_t xen_pt_get_bar_size(PCIIORegion *r);
> 
> there is just one user of xen_pt_get_bar_size, maybe you can just
> move the implementation here
> 

Ok, thanks.

> 
> >  static XenPTBarFlag xen_pt_bar_reg_parse(XenPCIPassthroughState *s,
> >                                           XenPTRegInfo *reg)
> >  {
> > @@ -366,7 +367,7 @@ static XenPTBarFlag
> xen_pt_bar_reg_parse(XenPCIPassthroughState *s,
> >
> >      /* check unused BAR */
> >      r = &d->io_regions[index];
> > -    if (r->size == 0) {
> > +    if (!xen_pt_get_bar_size(r)) {
> >          return XEN_PT_BAR_FLAG_UNUSED;
> >      }
> >
> > @@ -383,6 +384,24 @@ static XenPTBarFlag
> xen_pt_bar_reg_parse(XenPCIPassthroughState *s,
> >      }
> >  }
> >
> > +static bool is_64bit_bar(PCIIORegion *r)
> > +{
> > +    return !!(r->type & PCI_BASE_ADDRESS_MEM_TYPE_64);
> > +}
> > +
> > +static uint64_t xen_pt_get_bar_size(PCIIORegion *r)
> > +{
> > +    if (is_64bit_bar(r))
> > +    {
> > +        uint64_t size64;
> > +        size64 = (r + 1)->size;
> > +        size64 <<= 32;
> > +        size64 += r->size;
> > +        return size64;
> > +    }
> > +    return r->size;
> > +}
> > +
> >  static inline uint32_t base_address_with_flags(XenHostPCIIORegion *hr)
> >  {
> >      if (hr->type & XEN_HOST_PCI_REGION_TYPE_IO) {
> > @@ -481,7 +500,10 @@ static int
> xen_pt_bar_reg_write(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
> >      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);
> > +        if (!r_size)
> > +            bar_ro_mask = XEN_PT_BAR_ALLF;
> > +        else
> > +            bar_ro_mask = XEN_PT_BAR_MEM_RO_MASK | (r_size - 1);
> >          break;
> 
> Is this an actual mistake everywhere?

It's low 32bit mask for 64 bit bars.

> There is at least another instance of
> 
> bar_ro_mask = something | (r_size - 1);
> 
> under the XEN_PT_BAR_FLAG_IO case.

Bar_ro_mask under XEN_PT_BAR_FLAG_IO already be done, I don't change IO case.

> Or is it only a problem with 64 bit bars? If so, could you please
> explain why?
> 
> 
> >      case XEN_PT_BAR_FLAG_IO:
> >          bar_emu_mask = XEN_PT_BAR_IO_EMU_MASK;
> > @@ -489,7 +511,10 @@ static int
> xen_pt_bar_reg_write(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
> >          break;
> >      case XEN_PT_BAR_FLAG_UPPER:
> >          bar_emu_mask = XEN_PT_BAR_ALLF;
> > -        bar_ro_mask = 0;    /* all upper 32bit are R/W */
> > +        if (!r_size)
> > +            bar_ro_mask = 0;
> > +        else
> > +            bar_ro_mask = r_size - 1;
> >          break;
> 
> bar_ro_mask = r_size ? r_size - 1 : 0;
> 

Great. :)



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 26 08:25:01 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Sep 2012 08: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 1TGmvB-0005ll-O8; Wed, 26 Sep 2012 08:24:41 +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 1TGmvA-0005lg-6c
	for xen-devel@lists.xen.org; Wed, 26 Sep 2012 08:24:40 +0000
Received: from [85.158.143.99:2636] by server-1.bemta-4.messagelabs.com id
	84/0F-05684-7CBB2605; Wed, 26 Sep 2012 08:24:39 +0000
X-Env-Sender: xudong.hao@intel.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1348647876!24281565!1
X-Originating-IP: [143.182.124.21]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMjEgPT4gMjA5MTA0\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4689 invoked from network); 26 Sep 2012 08:24:37 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (143.182.124.21)
	by server-11.tower-216.messagelabs.com with SMTP;
	26 Sep 2012 08:24:37 -0000
Received: from azsmga001.ch.intel.com ([10.2.17.19])
	by azsmga101.ch.intel.com with ESMTP; 26 Sep 2012 01:24:35 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.80,489,1344236400"; d="scan'208";a="197254858"
Received: from fmsmsx105.amr.corp.intel.com ([10.19.9.36])
	by azsmga001.ch.intel.com with ESMTP; 26 Sep 2012 01:24:35 -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; Wed, 26 Sep 2012 01:24:34 -0700
Received: from shsmsx102.ccr.corp.intel.com ([169.254.2.92]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.175]) with mapi id
	14.01.0355.002; Wed, 26 Sep 2012 16:24:33 +0800
From: "Hao, Xudong" <xudong.hao@intel.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Thread-Topic: [PATCH v2] qemu/xen: Add 64 bits big bar support on qemu
Thread-Index: AQHNms7UWaIyHrSFlE24ZH5C7S6v25eaW+6AgAHhrOA=
Date: Wed, 26 Sep 2012 08:24:32 +0000
Message-ID: <403610A45A2B5242BD291EDAE8B37D300FEC73C5@SHSMSX102.ccr.corp.intel.com>
References: <1348544326-31334-1-git-send-email-xudong.hao@intel.com>
	<alpine.DEB.2.02.1209251134460.29232@kaball.uk.xensource.com>
In-Reply-To: <alpine.DEB.2.02.1209251134460.29232@kaball.uk.xensource.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: "qemu-devel@nongnu.org" <qemu-devel@nongnu.org>, "Zhang,
	Xiantao" <xiantao.zhang@intel.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v2] qemu/xen: Add 64 bits big bar support on
	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

> -----Original Message-----
> From: Stefano Stabellini [mailto:stefano.stabellini@eu.citrix.com]
> Sent: Tuesday, September 25, 2012 6:52 PM
> To: Hao, Xudong
> Cc: Stefano Stabellini; xen-devel@lists.xen.org; qemu-devel@nongnu.org;
> Zhang, Xiantao
> Subject: Re: [PATCH v2] qemu/xen: Add 64 bits big bar support on qemu
> 
> On Tue, 25 Sep 2012, Xudong Hao wrote:
> > Changes from v1:
> > - Rebase to qemu upstream from qemu-xen
> 
> Thanks. Please run scripts/checkpatch.pl on this patch, you'll find
> some cody style issues that need to be fixed.
> 
OK, will use this scripts to check code style.

> 
> > Currently it is assumed PCI device BAR access < 4G memory. If there is such a
> > device whose BAR size is larger than 4G, it must access > 4G memory
> address.
> > This patch enable the 64bits big BAR support on qemu.
> >
> > Signed-off-by: Xudong Hao <xudong.hao@intel.com>
> > Signed-off-by: Xiantao Zhang <xiantao.zhang@intel.com>
> > ---
> >  hw/xen_pt.c             |   16 ++++++++--------
> >  hw/xen_pt_config_init.c |   42
> +++++++++++++++++++++++++++++-------------
> >
> > diff --git a/hw/xen_pt.c b/hw/xen_pt.c
> > index 307119a..2a8bcf3 100644
> > --- a/hw/xen_pt.c
> > +++ b/hw/xen_pt.c
> > @@ -403,21 +403,21 @@ static int
> xen_pt_register_regions(XenPCIPassthroughState *s)
> >
> >          s->bases[i].access.u = r->base_addr;
> >
> > -        if (r->type & XEN_HOST_PCI_REGION_TYPE_IO) {
> > +        if (r->type & XEN_HOST_PCI_REGION_TYPE_IO)
> >              type = PCI_BASE_ADDRESS_SPACE_IO;
> > -        } else {
> > +        else if (r->type & XEN_HOST_PCI_REGION_TYPE_MEM_64)
> > +            type = PCI_BASE_ADDRESS_MEM_TYPE_64;
> > +        else if (r->type & XEN_HOST_PCI_REGION_TYPE_PREFETCH)
> > +            type |= PCI_BASE_ADDRESS_MEM_PREFETCH;
> > +        else
> >              type = PCI_BASE_ADDRESS_SPACE_MEMORY;
> > -            if (r->type & XEN_HOST_PCI_REGION_TYPE_PREFETCH) {
> > -                type |= PCI_BASE_ADDRESS_MEM_PREFETCH;
> > -            }
> > -        }
> 
> Aside from the cody style issue here, this changes the behavior for type
> PCI_BASE_ADDRESS_SPACE_MEMORY. Before we could have:
> 
> type =
> PCI_BASE_ADDRESS_SPACE_MEMORY|PCI_BASE_ADDRESS_MEM_PREFETCH;
> 
> now we cannot anymore.
> 

Will change to:
-        if (r->type & XEN_HOST_PCI_REGION_TYPE_IO) {
+        if (r->type & XEN_HOST_PCI_REGION_TYPE_IO)
             type = PCI_BASE_ADDRESS_SPACE_IO;
-        } else {
+        else
             type = PCI_BASE_ADDRESS_SPACE_MEMORY;
-            if (r->type & XEN_HOST_PCI_REGION_TYPE_PREFETCH) {
+            if (r->type & XEN_HOST_PCI_REGION_TYPE_MEM_64)
+                type |= PCI_BASE_ADDRESS_MEM_TYPE_64;
+           else 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",
> > +        XEN_PT_LOG(&s->dev, "IO region %i registered
> (size=0x%lx"PRIx64
> > +                   " base_addr=0x%lx"PRIx64" type: %#x)\n",
> >                     i, r->size, r->base_addr, type);
> >      }
> >
> > diff --git a/hw/xen_pt_config_init.c b/hw/xen_pt_config_init.c
> > index e524a40..5e7ca22 100644
> > --- a/hw/xen_pt_config_init.c
> > +++ b/hw/xen_pt_config_init.c
> > @@ -342,6 +342,7 @@ static int
> xen_pt_cmd_reg_write(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
> >  #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 uint64_t xen_pt_get_bar_size(PCIIORegion *r);
> 
> there is just one user of xen_pt_get_bar_size, maybe you can just
> move the implementation here
> 

Ok, thanks.

> 
> >  static XenPTBarFlag xen_pt_bar_reg_parse(XenPCIPassthroughState *s,
> >                                           XenPTRegInfo *reg)
> >  {
> > @@ -366,7 +367,7 @@ static XenPTBarFlag
> xen_pt_bar_reg_parse(XenPCIPassthroughState *s,
> >
> >      /* check unused BAR */
> >      r = &d->io_regions[index];
> > -    if (r->size == 0) {
> > +    if (!xen_pt_get_bar_size(r)) {
> >          return XEN_PT_BAR_FLAG_UNUSED;
> >      }
> >
> > @@ -383,6 +384,24 @@ static XenPTBarFlag
> xen_pt_bar_reg_parse(XenPCIPassthroughState *s,
> >      }
> >  }
> >
> > +static bool is_64bit_bar(PCIIORegion *r)
> > +{
> > +    return !!(r->type & PCI_BASE_ADDRESS_MEM_TYPE_64);
> > +}
> > +
> > +static uint64_t xen_pt_get_bar_size(PCIIORegion *r)
> > +{
> > +    if (is_64bit_bar(r))
> > +    {
> > +        uint64_t size64;
> > +        size64 = (r + 1)->size;
> > +        size64 <<= 32;
> > +        size64 += r->size;
> > +        return size64;
> > +    }
> > +    return r->size;
> > +}
> > +
> >  static inline uint32_t base_address_with_flags(XenHostPCIIORegion *hr)
> >  {
> >      if (hr->type & XEN_HOST_PCI_REGION_TYPE_IO) {
> > @@ -481,7 +500,10 @@ static int
> xen_pt_bar_reg_write(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
> >      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);
> > +        if (!r_size)
> > +            bar_ro_mask = XEN_PT_BAR_ALLF;
> > +        else
> > +            bar_ro_mask = XEN_PT_BAR_MEM_RO_MASK | (r_size - 1);
> >          break;
> 
> Is this an actual mistake everywhere?

It's low 32bit mask for 64 bit bars.

> There is at least another instance of
> 
> bar_ro_mask = something | (r_size - 1);
> 
> under the XEN_PT_BAR_FLAG_IO case.

Bar_ro_mask under XEN_PT_BAR_FLAG_IO already be done, I don't change IO case.

> Or is it only a problem with 64 bit bars? If so, could you please
> explain why?
> 
> 
> >      case XEN_PT_BAR_FLAG_IO:
> >          bar_emu_mask = XEN_PT_BAR_IO_EMU_MASK;
> > @@ -489,7 +511,10 @@ static int
> xen_pt_bar_reg_write(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
> >          break;
> >      case XEN_PT_BAR_FLAG_UPPER:
> >          bar_emu_mask = XEN_PT_BAR_ALLF;
> > -        bar_ro_mask = 0;    /* all upper 32bit are R/W */
> > +        if (!r_size)
> > +            bar_ro_mask = 0;
> > +        else
> > +            bar_ro_mask = r_size - 1;
> >          break;
> 
> bar_ro_mask = r_size ? r_size - 1 : 0;
> 

Great. :)



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 26 08:33:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Sep 2012 08:33:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGn2y-0005w4-R0; Wed, 26 Sep 2012 08:32:44 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <george.shuklin@gmail.com>) id 1TGn2x-0005vy-QW
	for xen-devel@lists.xen.org; Wed, 26 Sep 2012 08:32:44 +0000
Received: from [85.158.143.35:36458] by server-2.bemta-4.messagelabs.com id
	A3/E8-06610-BADB2605; Wed, 26 Sep 2012 08:32:43 +0000
X-Env-Sender: george.shuklin@gmail.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1348648362!12780037!1
X-Originating-IP: [209.85.217.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2533 invoked from network); 26 Sep 2012 08:32:42 -0000
Received: from mail-lb0-f173.google.com (HELO mail-lb0-f173.google.com)
	(209.85.217.173)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Sep 2012 08:32:42 -0000
Received: by lbbgj3 with SMTP id gj3so261653lbb.32
	for <xen-devel@lists.xen.org>; Wed, 26 Sep 2012 01:32:41 -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=JCN5gD9LYF4HGxZGz/T1qUj7Tztdu1ugmFQGSBYsojU=;
	b=WRrqxSsv4aXZyUGzfXZPRZ3qzN0FrhZzVMEked89xVwhXQiWGjLklVdCfnGUeWZesU
	MRjroYi99000EsxE9luJVevbM482DPjlgQMTw5Jfza3NfMb1RgMZv0p2SLM3dMaBKENU
	lhL4jHyw3wjUyxUjftrrjPxqhjHwCbEdEasNEhjK0mo6C3XEKavU7wHGXsYeoQTr80g2
	gIbDHeCxxxIEnSNMYGJ4qPNdVmW94vR/roxDoej/xERh3O3QAbTMuAbc5HhDnw6v9H2i
	3zdLRsaF815IuT1cSL32rWPxFJxE/44qv6eYH9UlfG4h8HTQm/lkRRKFHi81Mdbakvyx
	0sRQ==
Received: by 10.112.86.200 with SMTP id r8mr91212lbz.87.1348648361684;
	Wed, 26 Sep 2012 01:32:41 -0700 (PDT)
Received: from [192.168.40.104] (officecvt.selectel.ru. [188.93.16.50])
	by mx.google.com with ESMTPS id ba4sm796958lbb.14.2012.09.26.01.32.40
	(version=SSLv3 cipher=OTHER); Wed, 26 Sep 2012 01:32:41 -0700 (PDT)
Message-ID: <5062BDA8.5@gmail.com>
Date: Wed, 26 Sep 2012 12:32:40 +0400
From: George Shuklin <george.shuklin@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:15.0) Gecko/20120911 Thunderbird/15.0.1
MIME-Version: 1.0
To: xen-devel <xen-devel@lists.xen.org>
Subject: [Xen-devel] start_info content for 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-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Good day.

I've digging in some strange memory/balloon related bug and I've really 
like to see start_info content on linux. I saw in source code

#ifdef CONFIG_X86_32
         mov %esi,xen_start_info
         mov $init_thread_union+THREAD_SIZE,%esp
#else
         mov %rsi,xen_start_info
         mov $init_thread_union+THREAD_SIZE,%rsp
#endif
         jmp xen_start_kernel

Pointer to start_info stored in linux global variable xen_start_info, 
but I can't find way to access it.

Is any way to get it from linux kernel? (well, except writing your own 
module).

Thanks.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 26 08:33:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Sep 2012 08:33:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGn2y-0005w4-R0; Wed, 26 Sep 2012 08:32:44 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <george.shuklin@gmail.com>) id 1TGn2x-0005vy-QW
	for xen-devel@lists.xen.org; Wed, 26 Sep 2012 08:32:44 +0000
Received: from [85.158.143.35:36458] by server-2.bemta-4.messagelabs.com id
	A3/E8-06610-BADB2605; Wed, 26 Sep 2012 08:32:43 +0000
X-Env-Sender: george.shuklin@gmail.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1348648362!12780037!1
X-Originating-IP: [209.85.217.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2533 invoked from network); 26 Sep 2012 08:32:42 -0000
Received: from mail-lb0-f173.google.com (HELO mail-lb0-f173.google.com)
	(209.85.217.173)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Sep 2012 08:32:42 -0000
Received: by lbbgj3 with SMTP id gj3so261653lbb.32
	for <xen-devel@lists.xen.org>; Wed, 26 Sep 2012 01:32:41 -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=JCN5gD9LYF4HGxZGz/T1qUj7Tztdu1ugmFQGSBYsojU=;
	b=WRrqxSsv4aXZyUGzfXZPRZ3qzN0FrhZzVMEked89xVwhXQiWGjLklVdCfnGUeWZesU
	MRjroYi99000EsxE9luJVevbM482DPjlgQMTw5Jfza3NfMb1RgMZv0p2SLM3dMaBKENU
	lhL4jHyw3wjUyxUjftrrjPxqhjHwCbEdEasNEhjK0mo6C3XEKavU7wHGXsYeoQTr80g2
	gIbDHeCxxxIEnSNMYGJ4qPNdVmW94vR/roxDoej/xERh3O3QAbTMuAbc5HhDnw6v9H2i
	3zdLRsaF815IuT1cSL32rWPxFJxE/44qv6eYH9UlfG4h8HTQm/lkRRKFHi81Mdbakvyx
	0sRQ==
Received: by 10.112.86.200 with SMTP id r8mr91212lbz.87.1348648361684;
	Wed, 26 Sep 2012 01:32:41 -0700 (PDT)
Received: from [192.168.40.104] (officecvt.selectel.ru. [188.93.16.50])
	by mx.google.com with ESMTPS id ba4sm796958lbb.14.2012.09.26.01.32.40
	(version=SSLv3 cipher=OTHER); Wed, 26 Sep 2012 01:32:41 -0700 (PDT)
Message-ID: <5062BDA8.5@gmail.com>
Date: Wed, 26 Sep 2012 12:32:40 +0400
From: George Shuklin <george.shuklin@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:15.0) Gecko/20120911 Thunderbird/15.0.1
MIME-Version: 1.0
To: xen-devel <xen-devel@lists.xen.org>
Subject: [Xen-devel] start_info content for 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-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Good day.

I've digging in some strange memory/balloon related bug and I've really 
like to see start_info content on linux. I saw in source code

#ifdef CONFIG_X86_32
         mov %esi,xen_start_info
         mov $init_thread_union+THREAD_SIZE,%esp
#else
         mov %rsi,xen_start_info
         mov $init_thread_union+THREAD_SIZE,%rsp
#endif
         jmp xen_start_kernel

Pointer to start_info stored in linux global variable xen_start_info, 
but I can't find way to access it.

Is any way to get it from linux kernel? (well, except writing your own 
module).

Thanks.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 26 08:33:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Sep 2012 08:33:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGn37-0005ww-6z; Wed, 26 Sep 2012 08:32: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 1TGn35-0005wl-TX
	for xen-devel@lists.xen.org; Wed, 26 Sep 2012 08:32:52 +0000
Received: from [85.158.143.35:45580] by server-1.bemta-4.messagelabs.com id
	3B/EC-05684-3BDB2605; Wed, 26 Sep 2012 08:32:51 +0000
X-Env-Sender: xudong.hao@intel.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1348648369!18515983!1
X-Originating-IP: [192.55.52.88]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjg4ID0+IDMyMzY2Ng==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10355 invoked from network); 26 Sep 2012 08:32:50 -0000
Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88)
	by server-13.tower-21.messagelabs.com with SMTP;
	26 Sep 2012 08:32:50 -0000
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
	by fmsmga101.fm.intel.com with ESMTP; 26 Sep 2012 01:32:48 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.80,489,1344236400"; d="scan'208";a="226648969"
Received: from xhao-dev.sh.intel.com (HELO localhost.localdomain)
	([10.239.48.48])
	by fmsmga001.fm.intel.com with ESMTP; 26 Sep 2012 01:32:46 -0700
From: Xudong Hao <xudong.hao@intel.com>
To: ian.campbell@citrix.com,
	keir@xen.org
Date: Wed, 26 Sep 2012 16:36:22 +0800
Message-Id: <1348648582-11461-1-git-send-email-xudong.hao@intel.com>
X-Mailer: git-send-email 1.5.5
Cc: Stefano.Stabellini@eu.citrix.com, Xudong Hao <xudong.hao@intel.com>,
	xiantao.zhang@intel.com, jbeulich@suse.com, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH v3] xen/tools: Add 64 bits big bar 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

Currently it is assumed PCI device BAR access < 4G memory. If there is such a
device whose BAR size is larger than 4G, it must access > 4G memory address.
This patch enable the 64bits big BAR support on hvmloader.

v3 changes from v2:
- Remain original print information 

v2 changes from v1 as comments by Jan.
1) Set Dynamic MMIO high memory address instead of a fixed number 640G
2) Mask bar_sz earlier to avoid older code changes
3) Add bar size barrier to judge high memory resource
4) Clean up bar64_relocate code

Signed-off-by: Xiantao Zhang <xiantao.zhang@intel.com>
Signed-off-by: Xudong Hao <xudong.hao@intel.com>
---
 tools/firmware/hvmloader/cacheattr.c |   25 +++++++----
 tools/firmware/hvmloader/config.h    |    2 +
 tools/firmware/hvmloader/pci.c       |   77 ++++++++++++++++++++++++++-------
 tools/firmware/hvmloader/util.h      |    1 +
 4 files changed, 80 insertions(+), 25 deletions(-)

diff --git a/tools/firmware/hvmloader/cacheattr.c b/tools/firmware/hvmloader/cacheattr.c
index 646f07f..592b455 100644
--- a/tools/firmware/hvmloader/cacheattr.c
+++ b/tools/firmware/hvmloader/cacheattr.c
@@ -40,24 +40,33 @@
 #define MSR_PAT              0x0277
 #define MSR_MTRRdefType      0x02ff
 
+unsigned int cpu_phys_addr(void)
+{
+    uint32_t eax, ebx, ecx, edx;
+    unsigned int phys_bits = 36;
+    /* Find the physical address size for this CPU. */
+    cpuid(0x80000000, &eax, &ebx, &ecx, &edx);
+    if ( eax >= 0x80000008 )
+    {
+        cpuid(0x80000008, &eax, &ebx, &ecx, &edx);
+        phys_bits = (uint8_t)eax;
+    }
+
+    return phys_bits;
+}
+
 void cacheattr_init(void)
 {
     uint32_t eax, ebx, ecx, edx;
     uint64_t mtrr_cap, mtrr_def, content, addr_mask;
-    unsigned int i, nr_var_ranges, phys_bits = 36;
+    unsigned int i, nr_var_ranges, phys_bits;
 
     /* Does the CPU support architectural MTRRs? */
     cpuid(0x00000001, &eax, &ebx, &ecx, &edx);
     if ( !(edx & (1u << 12)) )
          return;
 
-    /* Find the physical address size for this CPU. */
-    cpuid(0x80000000, &eax, &ebx, &ecx, &edx);
-    if ( eax >= 0x80000008 )
-    {
-        cpuid(0x80000008, &eax, &ebx, &ecx, &edx);
-        phys_bits = (uint8_t)eax;
-    }
+    phys_bits = cpu_phys_addr();
 
     printf("%u-bit phys ... ", phys_bits);
 
diff --git a/tools/firmware/hvmloader/config.h b/tools/firmware/hvmloader/config.h
index 7c0180d..bbf2993 100644
--- a/tools/firmware/hvmloader/config.h
+++ b/tools/firmware/hvmloader/config.h
@@ -53,6 +53,8 @@ extern struct bios_config ovmf_config;
 /* MMIO hole: Hardcoded defaults, which can be dynamically expanded. */
 #define PCI_MEM_START       0xf0000000
 #define PCI_MEM_END         0xfc000000
+#define PCI_MIN_BIG_BAR_SIZE          0x20000000
+
 extern unsigned long pci_mem_start, pci_mem_end;
 
 
diff --git a/tools/firmware/hvmloader/pci.c b/tools/firmware/hvmloader/pci.c
index fd56e50..0500db5 100644
--- a/tools/firmware/hvmloader/pci.c
+++ b/tools/firmware/hvmloader/pci.c
@@ -36,19 +36,25 @@ unsigned long igd_opregion_pgbase = 0;
 
 void pci_setup(void)
 {
-    uint32_t base, devfn, bar_reg, bar_data, bar_sz, cmd, mmio_total = 0;
+    uint8_t is_64bar, using_64bar, bar64_relocate = 0;
+    uint32_t devfn, bar_reg, cmd, bar_data, bar_data_upper;
+    uint64_t base, bar_sz, bar_sz_upper, mmio_total = 0;
     uint32_t vga_devfn = 256;
     uint16_t class, vendor_id, device_id;
     unsigned int bar, pin, link, isa_irq;
+    int64_t mmio_left;
 
     /* Resources assignable to PCI devices via BARs. */
     struct resource {
-        uint32_t base, max;
-    } *resource, mem_resource, io_resource;
+        uint64_t base, max;
+    } *resource, mem_resource, high_mem_resource, io_resource;
 
     /* Create a list of device BARs in descending order of size. */
     struct bars {
-        uint32_t devfn, bar_reg, bar_sz;
+        uint32_t is_64bar;
+        uint32_t devfn;
+        uint32_t bar_reg;
+        uint64_t bar_sz;
     } *bars = (struct bars *)scratch_start;
     unsigned int i, nr_bars = 0;
 
@@ -133,22 +139,34 @@ void pci_setup(void)
         /* Map the I/O memory and port resources. */
         for ( bar = 0; bar < 7; bar++ )
         {
+            bar_sz_upper = 0;
             bar_reg = PCI_BASE_ADDRESS_0 + 4*bar;
             if ( bar == 6 )
                 bar_reg = PCI_ROM_ADDRESS;
 
             bar_data = pci_readl(devfn, bar_reg);
+            is_64bar = !!((bar_data & (PCI_BASE_ADDRESS_SPACE |
+                         PCI_BASE_ADDRESS_MEM_TYPE_MASK)) ==
+                         (PCI_BASE_ADDRESS_SPACE_MEMORY |
+                         PCI_BASE_ADDRESS_MEM_TYPE_64));
             pci_writel(devfn, bar_reg, ~0);
             bar_sz = pci_readl(devfn, bar_reg);
             pci_writel(devfn, bar_reg, bar_data);
-            if ( bar_sz == 0 )
-                continue;
 
             bar_sz &= (((bar_data & PCI_BASE_ADDRESS_SPACE) ==
                         PCI_BASE_ADDRESS_SPACE_MEMORY) ?
                        PCI_BASE_ADDRESS_MEM_MASK :
                        (PCI_BASE_ADDRESS_IO_MASK & 0xffff));
+            if (is_64bar) {
+                bar_data_upper = pci_readl(devfn, bar_reg + 4);
+                pci_writel(devfn, bar_reg + 4, ~0);
+                bar_sz_upper = pci_readl(devfn, bar_reg + 4);
+                pci_writel(devfn, bar_reg + 4, bar_data_upper);
+                bar_sz = (bar_sz_upper << 32) | bar_sz;
+            }
             bar_sz &= ~(bar_sz - 1);
+            if ( bar_sz == 0 )
+                continue;
 
             for ( i = 0; i < nr_bars; i++ )
                 if ( bars[i].bar_sz < bar_sz )
@@ -157,6 +175,7 @@ void pci_setup(void)
             if ( i != nr_bars )
                 memmove(&bars[i+1], &bars[i], (nr_bars-i) * sizeof(*bars));
 
+            bars[i].is_64bar = is_64bar;
             bars[i].devfn   = devfn;
             bars[i].bar_reg = bar_reg;
             bars[i].bar_sz  = bar_sz;
@@ -167,11 +186,8 @@ void pci_setup(void)
 
             nr_bars++;
 
-            /* Skip the upper-half of the address for a 64-bit BAR. */
-            if ( (bar_data & (PCI_BASE_ADDRESS_SPACE |
-                              PCI_BASE_ADDRESS_MEM_TYPE_MASK)) == 
-                 (PCI_BASE_ADDRESS_SPACE_MEMORY | 
-                  PCI_BASE_ADDRESS_MEM_TYPE_64) )
+            /*The upper half is already calculated, skip it! */
+            if (is_64bar)
                 bar++;
         }
 
@@ -197,6 +213,9 @@ void pci_setup(void)
             ((pci_mem_start << 1) != 0) )
         pci_mem_start <<= 1;
 
+    if ( (pci_mem_start << 1) != 0 )
+        bar64_relocate = 1;
+
     /* Relocate RAM that overlaps PCI space (in 64k-page chunks). */
     while ( (pci_mem_start >> PAGE_SHIFT) < hvm_info->low_mem_pgend )
     {
@@ -218,11 +237,15 @@ void pci_setup(void)
         hvm_info->high_mem_pgend += nr_pages;
     }
 
+    high_mem_resource.base = ((uint64_t)hvm_info->high_mem_pgend) << PAGE_SHIFT; 
+    high_mem_resource.max = 1ull << cpu_phys_addr();
     mem_resource.base = pci_mem_start;
     mem_resource.max = pci_mem_end;
     io_resource.base = 0xc000;
     io_resource.max = 0x10000;
 
+    mmio_left = pci_mem_end - pci_mem_start;
+
     /* Assign iomem and ioport resources in descending order of size. */
     for ( i = 0; i < nr_bars; i++ )
     {
@@ -230,13 +253,29 @@ void pci_setup(void)
         bar_reg = bars[i].bar_reg;
         bar_sz  = bars[i].bar_sz;
 
+        using_64bar = bars[i].is_64bar && bar64_relocate && (mmio_left < bar_sz);
         bar_data = pci_readl(devfn, bar_reg);
 
         if ( (bar_data & PCI_BASE_ADDRESS_SPACE) ==
              PCI_BASE_ADDRESS_SPACE_MEMORY )
         {
-            resource = &mem_resource;
-            bar_data &= ~PCI_BASE_ADDRESS_MEM_MASK;
+            /* Mapping high memory if PCI deivce is 64 bits bar and the bar size
+               is larger than 512M */
+            if (using_64bar && (bar_sz > PCI_MIN_BIG_BAR_SIZE)) {
+                if ( high_mem_resource.base & (bar_sz - 1) )
+                    high_mem_resource.base = high_mem_resource.base - 
+                        (high_mem_resource.base & (bar_sz - 1)) + bar_sz;
+                else
+                    high_mem_resource.base = high_mem_resource.base - 
+                        (high_mem_resource.base & (bar_sz - 1));
+                resource = &high_mem_resource;
+                bar_data &= ~PCI_BASE_ADDRESS_MEM_MASK;
+            } 
+            else {
+                resource = &mem_resource;
+                bar_data &= ~PCI_BASE_ADDRESS_MEM_MASK;
+            }
+            mmio_left -= bar_sz;
         }
         else
         {
@@ -244,13 +283,14 @@ void pci_setup(void)
             bar_data &= ~PCI_BASE_ADDRESS_IO_MASK;
         }
 
-        base = (resource->base + bar_sz - 1) & ~(bar_sz - 1);
-        bar_data |= base;
+        base = (resource->base  + bar_sz - 1) & ~(uint64_t)(bar_sz - 1);
+        bar_data |= (uint32_t)base;
+        bar_data_upper = (uint32_t)(base >> 32);
         base += bar_sz;
 
         if ( (base < resource->base) || (base > resource->max) )
         {
-            printf("pci dev %02x:%x bar %02x size %08x: no space for "
+            printf("pci dev %02x:%x bar %02x size %llx: no space for "
                    "resource!\n", devfn>>3, devfn&7, bar_reg, bar_sz);
             continue;
         }
@@ -258,8 +298,11 @@ void pci_setup(void)
         resource->base = base;
 
         pci_writel(devfn, bar_reg, bar_data);
-        printf("pci dev %02x:%x bar %02x size %08x: %08x\n",
+        if (using_64bar)
+            pci_writel(devfn, bar_reg + 4, bar_data_upper);
+        printf("pci dev %02x:%x bar %02x size %llx: %08x\n",
                devfn>>3, devfn&7, bar_reg, bar_sz, bar_data);
+			
 
         /* Now enable the memory or I/O mapping. */
         cmd = pci_readw(devfn, PCI_COMMAND);
diff --git a/tools/firmware/hvmloader/util.h b/tools/firmware/hvmloader/util.h
index 07a9d42..ff06071 100644
--- a/tools/firmware/hvmloader/util.h
+++ b/tools/firmware/hvmloader/util.h
@@ -215,6 +215,7 @@ void pci_setup(void);
 uint32_t rombios_highbios_setup(void);
 
 /* Miscellaneous. */
+unsigned int cpu_phys_addr(void);
 void cacheattr_init(void);
 unsigned long create_mp_tables(void *table);
 void hvm_write_smbios_tables(
-- 
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 Sep 26 08:33:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Sep 2012 08:33:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGn37-0005ww-6z; Wed, 26 Sep 2012 08:32: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 1TGn35-0005wl-TX
	for xen-devel@lists.xen.org; Wed, 26 Sep 2012 08:32:52 +0000
Received: from [85.158.143.35:45580] by server-1.bemta-4.messagelabs.com id
	3B/EC-05684-3BDB2605; Wed, 26 Sep 2012 08:32:51 +0000
X-Env-Sender: xudong.hao@intel.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1348648369!18515983!1
X-Originating-IP: [192.55.52.88]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjg4ID0+IDMyMzY2Ng==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10355 invoked from network); 26 Sep 2012 08:32:50 -0000
Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88)
	by server-13.tower-21.messagelabs.com with SMTP;
	26 Sep 2012 08:32:50 -0000
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
	by fmsmga101.fm.intel.com with ESMTP; 26 Sep 2012 01:32:48 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.80,489,1344236400"; d="scan'208";a="226648969"
Received: from xhao-dev.sh.intel.com (HELO localhost.localdomain)
	([10.239.48.48])
	by fmsmga001.fm.intel.com with ESMTP; 26 Sep 2012 01:32:46 -0700
From: Xudong Hao <xudong.hao@intel.com>
To: ian.campbell@citrix.com,
	keir@xen.org
Date: Wed, 26 Sep 2012 16:36:22 +0800
Message-Id: <1348648582-11461-1-git-send-email-xudong.hao@intel.com>
X-Mailer: git-send-email 1.5.5
Cc: Stefano.Stabellini@eu.citrix.com, Xudong Hao <xudong.hao@intel.com>,
	xiantao.zhang@intel.com, jbeulich@suse.com, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH v3] xen/tools: Add 64 bits big bar 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

Currently it is assumed PCI device BAR access < 4G memory. If there is such a
device whose BAR size is larger than 4G, it must access > 4G memory address.
This patch enable the 64bits big BAR support on hvmloader.

v3 changes from v2:
- Remain original print information 

v2 changes from v1 as comments by Jan.
1) Set Dynamic MMIO high memory address instead of a fixed number 640G
2) Mask bar_sz earlier to avoid older code changes
3) Add bar size barrier to judge high memory resource
4) Clean up bar64_relocate code

Signed-off-by: Xiantao Zhang <xiantao.zhang@intel.com>
Signed-off-by: Xudong Hao <xudong.hao@intel.com>
---
 tools/firmware/hvmloader/cacheattr.c |   25 +++++++----
 tools/firmware/hvmloader/config.h    |    2 +
 tools/firmware/hvmloader/pci.c       |   77 ++++++++++++++++++++++++++-------
 tools/firmware/hvmloader/util.h      |    1 +
 4 files changed, 80 insertions(+), 25 deletions(-)

diff --git a/tools/firmware/hvmloader/cacheattr.c b/tools/firmware/hvmloader/cacheattr.c
index 646f07f..592b455 100644
--- a/tools/firmware/hvmloader/cacheattr.c
+++ b/tools/firmware/hvmloader/cacheattr.c
@@ -40,24 +40,33 @@
 #define MSR_PAT              0x0277
 #define MSR_MTRRdefType      0x02ff
 
+unsigned int cpu_phys_addr(void)
+{
+    uint32_t eax, ebx, ecx, edx;
+    unsigned int phys_bits = 36;
+    /* Find the physical address size for this CPU. */
+    cpuid(0x80000000, &eax, &ebx, &ecx, &edx);
+    if ( eax >= 0x80000008 )
+    {
+        cpuid(0x80000008, &eax, &ebx, &ecx, &edx);
+        phys_bits = (uint8_t)eax;
+    }
+
+    return phys_bits;
+}
+
 void cacheattr_init(void)
 {
     uint32_t eax, ebx, ecx, edx;
     uint64_t mtrr_cap, mtrr_def, content, addr_mask;
-    unsigned int i, nr_var_ranges, phys_bits = 36;
+    unsigned int i, nr_var_ranges, phys_bits;
 
     /* Does the CPU support architectural MTRRs? */
     cpuid(0x00000001, &eax, &ebx, &ecx, &edx);
     if ( !(edx & (1u << 12)) )
          return;
 
-    /* Find the physical address size for this CPU. */
-    cpuid(0x80000000, &eax, &ebx, &ecx, &edx);
-    if ( eax >= 0x80000008 )
-    {
-        cpuid(0x80000008, &eax, &ebx, &ecx, &edx);
-        phys_bits = (uint8_t)eax;
-    }
+    phys_bits = cpu_phys_addr();
 
     printf("%u-bit phys ... ", phys_bits);
 
diff --git a/tools/firmware/hvmloader/config.h b/tools/firmware/hvmloader/config.h
index 7c0180d..bbf2993 100644
--- a/tools/firmware/hvmloader/config.h
+++ b/tools/firmware/hvmloader/config.h
@@ -53,6 +53,8 @@ extern struct bios_config ovmf_config;
 /* MMIO hole: Hardcoded defaults, which can be dynamically expanded. */
 #define PCI_MEM_START       0xf0000000
 #define PCI_MEM_END         0xfc000000
+#define PCI_MIN_BIG_BAR_SIZE          0x20000000
+
 extern unsigned long pci_mem_start, pci_mem_end;
 
 
diff --git a/tools/firmware/hvmloader/pci.c b/tools/firmware/hvmloader/pci.c
index fd56e50..0500db5 100644
--- a/tools/firmware/hvmloader/pci.c
+++ b/tools/firmware/hvmloader/pci.c
@@ -36,19 +36,25 @@ unsigned long igd_opregion_pgbase = 0;
 
 void pci_setup(void)
 {
-    uint32_t base, devfn, bar_reg, bar_data, bar_sz, cmd, mmio_total = 0;
+    uint8_t is_64bar, using_64bar, bar64_relocate = 0;
+    uint32_t devfn, bar_reg, cmd, bar_data, bar_data_upper;
+    uint64_t base, bar_sz, bar_sz_upper, mmio_total = 0;
     uint32_t vga_devfn = 256;
     uint16_t class, vendor_id, device_id;
     unsigned int bar, pin, link, isa_irq;
+    int64_t mmio_left;
 
     /* Resources assignable to PCI devices via BARs. */
     struct resource {
-        uint32_t base, max;
-    } *resource, mem_resource, io_resource;
+        uint64_t base, max;
+    } *resource, mem_resource, high_mem_resource, io_resource;
 
     /* Create a list of device BARs in descending order of size. */
     struct bars {
-        uint32_t devfn, bar_reg, bar_sz;
+        uint32_t is_64bar;
+        uint32_t devfn;
+        uint32_t bar_reg;
+        uint64_t bar_sz;
     } *bars = (struct bars *)scratch_start;
     unsigned int i, nr_bars = 0;
 
@@ -133,22 +139,34 @@ void pci_setup(void)
         /* Map the I/O memory and port resources. */
         for ( bar = 0; bar < 7; bar++ )
         {
+            bar_sz_upper = 0;
             bar_reg = PCI_BASE_ADDRESS_0 + 4*bar;
             if ( bar == 6 )
                 bar_reg = PCI_ROM_ADDRESS;
 
             bar_data = pci_readl(devfn, bar_reg);
+            is_64bar = !!((bar_data & (PCI_BASE_ADDRESS_SPACE |
+                         PCI_BASE_ADDRESS_MEM_TYPE_MASK)) ==
+                         (PCI_BASE_ADDRESS_SPACE_MEMORY |
+                         PCI_BASE_ADDRESS_MEM_TYPE_64));
             pci_writel(devfn, bar_reg, ~0);
             bar_sz = pci_readl(devfn, bar_reg);
             pci_writel(devfn, bar_reg, bar_data);
-            if ( bar_sz == 0 )
-                continue;
 
             bar_sz &= (((bar_data & PCI_BASE_ADDRESS_SPACE) ==
                         PCI_BASE_ADDRESS_SPACE_MEMORY) ?
                        PCI_BASE_ADDRESS_MEM_MASK :
                        (PCI_BASE_ADDRESS_IO_MASK & 0xffff));
+            if (is_64bar) {
+                bar_data_upper = pci_readl(devfn, bar_reg + 4);
+                pci_writel(devfn, bar_reg + 4, ~0);
+                bar_sz_upper = pci_readl(devfn, bar_reg + 4);
+                pci_writel(devfn, bar_reg + 4, bar_data_upper);
+                bar_sz = (bar_sz_upper << 32) | bar_sz;
+            }
             bar_sz &= ~(bar_sz - 1);
+            if ( bar_sz == 0 )
+                continue;
 
             for ( i = 0; i < nr_bars; i++ )
                 if ( bars[i].bar_sz < bar_sz )
@@ -157,6 +175,7 @@ void pci_setup(void)
             if ( i != nr_bars )
                 memmove(&bars[i+1], &bars[i], (nr_bars-i) * sizeof(*bars));
 
+            bars[i].is_64bar = is_64bar;
             bars[i].devfn   = devfn;
             bars[i].bar_reg = bar_reg;
             bars[i].bar_sz  = bar_sz;
@@ -167,11 +186,8 @@ void pci_setup(void)
 
             nr_bars++;
 
-            /* Skip the upper-half of the address for a 64-bit BAR. */
-            if ( (bar_data & (PCI_BASE_ADDRESS_SPACE |
-                              PCI_BASE_ADDRESS_MEM_TYPE_MASK)) == 
-                 (PCI_BASE_ADDRESS_SPACE_MEMORY | 
-                  PCI_BASE_ADDRESS_MEM_TYPE_64) )
+            /*The upper half is already calculated, skip it! */
+            if (is_64bar)
                 bar++;
         }
 
@@ -197,6 +213,9 @@ void pci_setup(void)
             ((pci_mem_start << 1) != 0) )
         pci_mem_start <<= 1;
 
+    if ( (pci_mem_start << 1) != 0 )
+        bar64_relocate = 1;
+
     /* Relocate RAM that overlaps PCI space (in 64k-page chunks). */
     while ( (pci_mem_start >> PAGE_SHIFT) < hvm_info->low_mem_pgend )
     {
@@ -218,11 +237,15 @@ void pci_setup(void)
         hvm_info->high_mem_pgend += nr_pages;
     }
 
+    high_mem_resource.base = ((uint64_t)hvm_info->high_mem_pgend) << PAGE_SHIFT; 
+    high_mem_resource.max = 1ull << cpu_phys_addr();
     mem_resource.base = pci_mem_start;
     mem_resource.max = pci_mem_end;
     io_resource.base = 0xc000;
     io_resource.max = 0x10000;
 
+    mmio_left = pci_mem_end - pci_mem_start;
+
     /* Assign iomem and ioport resources in descending order of size. */
     for ( i = 0; i < nr_bars; i++ )
     {
@@ -230,13 +253,29 @@ void pci_setup(void)
         bar_reg = bars[i].bar_reg;
         bar_sz  = bars[i].bar_sz;
 
+        using_64bar = bars[i].is_64bar && bar64_relocate && (mmio_left < bar_sz);
         bar_data = pci_readl(devfn, bar_reg);
 
         if ( (bar_data & PCI_BASE_ADDRESS_SPACE) ==
              PCI_BASE_ADDRESS_SPACE_MEMORY )
         {
-            resource = &mem_resource;
-            bar_data &= ~PCI_BASE_ADDRESS_MEM_MASK;
+            /* Mapping high memory if PCI deivce is 64 bits bar and the bar size
+               is larger than 512M */
+            if (using_64bar && (bar_sz > PCI_MIN_BIG_BAR_SIZE)) {
+                if ( high_mem_resource.base & (bar_sz - 1) )
+                    high_mem_resource.base = high_mem_resource.base - 
+                        (high_mem_resource.base & (bar_sz - 1)) + bar_sz;
+                else
+                    high_mem_resource.base = high_mem_resource.base - 
+                        (high_mem_resource.base & (bar_sz - 1));
+                resource = &high_mem_resource;
+                bar_data &= ~PCI_BASE_ADDRESS_MEM_MASK;
+            } 
+            else {
+                resource = &mem_resource;
+                bar_data &= ~PCI_BASE_ADDRESS_MEM_MASK;
+            }
+            mmio_left -= bar_sz;
         }
         else
         {
@@ -244,13 +283,14 @@ void pci_setup(void)
             bar_data &= ~PCI_BASE_ADDRESS_IO_MASK;
         }
 
-        base = (resource->base + bar_sz - 1) & ~(bar_sz - 1);
-        bar_data |= base;
+        base = (resource->base  + bar_sz - 1) & ~(uint64_t)(bar_sz - 1);
+        bar_data |= (uint32_t)base;
+        bar_data_upper = (uint32_t)(base >> 32);
         base += bar_sz;
 
         if ( (base < resource->base) || (base > resource->max) )
         {
-            printf("pci dev %02x:%x bar %02x size %08x: no space for "
+            printf("pci dev %02x:%x bar %02x size %llx: no space for "
                    "resource!\n", devfn>>3, devfn&7, bar_reg, bar_sz);
             continue;
         }
@@ -258,8 +298,11 @@ void pci_setup(void)
         resource->base = base;
 
         pci_writel(devfn, bar_reg, bar_data);
-        printf("pci dev %02x:%x bar %02x size %08x: %08x\n",
+        if (using_64bar)
+            pci_writel(devfn, bar_reg + 4, bar_data_upper);
+        printf("pci dev %02x:%x bar %02x size %llx: %08x\n",
                devfn>>3, devfn&7, bar_reg, bar_sz, bar_data);
+			
 
         /* Now enable the memory or I/O mapping. */
         cmd = pci_readw(devfn, PCI_COMMAND);
diff --git a/tools/firmware/hvmloader/util.h b/tools/firmware/hvmloader/util.h
index 07a9d42..ff06071 100644
--- a/tools/firmware/hvmloader/util.h
+++ b/tools/firmware/hvmloader/util.h
@@ -215,6 +215,7 @@ void pci_setup(void);
 uint32_t rombios_highbios_setup(void);
 
 /* Miscellaneous. */
+unsigned int cpu_phys_addr(void);
 void cacheattr_init(void);
 unsigned long create_mp_tables(void *table);
 void hvm_write_smbios_tables(
-- 
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 Sep 26 08:39:44 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Sep 2012 08: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 1TGn9U-0006FB-2r; Wed, 26 Sep 2012 08:39:28 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <qianhu2011@gmail.com>) id 1TGn9R-0006F0-PK
	for xen-devel@lists.xen.org; Wed, 26 Sep 2012 08:39:26 +0000
Received: from [85.158.139.211:32487] by server-15.bemta-5.messagelabs.com id
	86/3B-19430-C3FB2605; Wed, 26 Sep 2012 08:39:24 +0000
X-Env-Sender: qianhu2011@gmail.com
X-Msg-Ref: server-16.tower-206.messagelabs.com!1348648762!20029412!1
X-Originating-IP: [209.85.212.45]
X-SpamReason: No, hits=0.9 required=7.0 tests=HTML_40_50,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27074 invoked from network); 26 Sep 2012 08:39:23 -0000
Received: from mail-vb0-f45.google.com (HELO mail-vb0-f45.google.com)
	(209.85.212.45)
	by server-16.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Sep 2012 08:39:23 -0000
Received: by vbip1 with SMTP id p1so360394vbi.32
	for <xen-devel@lists.xen.org>; Wed, 26 Sep 2012 01:39:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=ogF39iOUasAdLijKjOzEdaXBnZJy30C0vfrz3HQ1TX8=;
	b=tI0oBQa9wC0iU5FnwDmidwh3pckBbLaXN3mvD4v9qhq8nLYSf/D+OBNbXCo05HmMyB
	MGriuv8q9Ajcepu19K33T0aiQzhEx5Y3MQ3N+30Sv1kD3B/T8r8pnrKc0UUlw9OzFSR+
	JDJlqyCRIIGk5pC/fXIcGDvXesi+XwVC98r2cq8Sy9rDWQ0ehPPFjJ6JV+RaEsdaflTt
	7fQCad0BzFaRcNGtfgJnpXT5K0iXqDVhjZLr1D0JeaBXV4KtHqAbHS6qypC19BLJG/X2
	6U+/Hza5uxVRVQh5UpoaJWaOg7HrOaYKOS7V3K+IVT3E5xQgNme9sSRXIBJVWe8LRvS+
	WFEQ==
MIME-Version: 1.0
Received: by 10.58.23.100 with SMTP id l4mr10800232vef.46.1348648762173; Wed,
	26 Sep 2012 01:39:22 -0700 (PDT)
Received: by 10.58.249.236 with HTTP; Wed, 26 Sep 2012 01:39:22 -0700 (PDT)
In-Reply-To: <20120925140421.GA16478@phenom.dumpdata.com>
References: <CALCpXpCvGkjZyG-NOY+fZY0q0f_DxuwPNEnxwKXVhjOe=gcHSQ@mail.gmail.com>
	<20120925140421.GA16478@phenom.dumpdata.com>
Date: Wed, 26 Sep 2012 16:39:22 +0800
Message-ID: <CALCpXpBJj23e3j_W4Mf2CJ57NSgx2YvnFMdB-0NgaJ=Wgvf60w@mail.gmail.com>
From: Qian Hu <qianhu2011@gmail.com>
To: Konrad Rzeszutek Wilk <konrad@kernel.org>
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] usbpassthrough of xen-4.1.2 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: multipart/mixed; boundary="===============4373729542900537773=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============4373729542900537773==
Content-Type: multipart/alternative; boundary=047d7b339d9d6568e604ca96c29d

--047d7b339d9d6568e604ca96c29d
Content-Type: text/plain; charset=ISO-8859-1

I am sorry what does the re-assign mean? By the way, where can I find the
ID C408 0040?

It seems not to be the message listed by "lsusb".

Below is my config file, similar with yours.

import os, re
arch = os.uname()[4]
if re.search('64', arch):
   arch_libdir = 'lib64'
else:
  arch_libdir = 'lib'

name = "win7"
builder = "hvm"
memory = "1024"
disk = [ 'file:/root/win7.img,hda,w',
#         'file:/mnt/win7.iso,hdc:cdrom,r',
        ]
vif = [ 'type=ioemu, mac=00:16:3e:3f:74:01 , bridge=eth0  ,model=e1000', ]
uuid = "11111111-2262-28d2-9b64-b11713adfb20"
device_model = "/home/root1/xen/xen-4.1.2/tools/ioemu-dir/i386-dm/qemu-dm"
kernel = "/usr/lib/xen/boot/hvmloader"
vnc=1
vnclisten="0.0.0.0"
vncdisplay=0
apic=1
acpi=1
pae=1
boot="dc"
vcpus=2
serial = "pty"
on_reboot='restart'
on_crash='restart'
dhcp='off'
stdvga=0
audio=1
soundhw='es1370'
videoram=16
usb=1
usb_add='host:0204:6025'
usbdevice='tablet'



2012/9/25 Konrad Rzeszutek Wilk <konrad@kernel.org>

> On Tue, Sep 25, 2012 at 11:17:03AM +0800, Qian Hu wrote:
> > Hi, everyone! The same question with updated message.
> >
> > I am working on the USB passthrough of Xen-4.1.2. My host OS  is Fedora
> 14
> > and the guest OS is win7.
> >
> > According to the wiki page(http://wiki.xen.org/wiki/Xen_USB_Passthrough
> ),
> >
> > xen supports passthrough of usb device from dom0 to guests. I have tried
> > the Xen HVM guest qemu-dm usb1.1 emulation,
> >
> > by specifying "usb = 1" and "usbdevice = host:xxxx:yyyy". I have also
> tried
> > the command usb_add host:xxxx:yyyy.
>
> Do you also re-assign the device from the Linux kernel? Like this:
>
> (the C408 0040 is my mouse).
>
>  cd /sys/bus/usb/drivers/usbhid
>  for a in `ls -1 | grep :`
>  do
>    for DEV in C408 0040
>    do
>         grep $DEV $a/modalias
>         if [ $? -eq 0 ]; then
>                 echo "Unbinding $a for $DEV"
>                 echo $a > unbind
>         fi
>    done
>  done
>
> This is what the config file looks for me:
> builder='hvm'
> memory = 2048
> name = "Windows7"
> vcpus=3
> disk = [ 'phy:/dev/vg_guest/Win7_Home,hda,w']
> vnc=1
> videoram=8
> vnclisten="0.0.0.0"
> vncpasswd=''
> stdvga=0
> serial='pty'
> tsc_mode=0
> usb=1
> usb_add="host:045e:0040"
> usbdevice='tablet'
> xen_platform_pci=1
> # Remember QEMU_AUDIO_DRV=pa
> soundhw='es1370'
> pci=['01:00.0','01:00.1','02:00.0']
>

--047d7b339d9d6568e604ca96c29d
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

I am sorry what does the re-assign mean? By the way, where can I find the I=
D=A0C408 0040?<div><br></div><div>It seems not to be the message listed by =
&quot;lsusb&quot;.<br><div><br></div><div>Below is my config file, similar =
with yours.</div>
<div><br></div><div><div>import os, re</div><div>arch =3D os.uname()[4]</di=
v><div>if re.search(&#39;64&#39;, arch):</div><div>=A0 =A0arch_libdir =3D &=
#39;lib64&#39;</div><div>else:</div><div>=A0 arch_libdir =3D &#39;lib&#39;<=
/div><div>
<br></div><div>name =3D &quot;win7&quot;</div><div>builder =3D &quot;hvm&qu=
ot;</div><div>memory =3D &quot;1024&quot;</div><div>disk =3D [ &#39;file:/r=
oot/win7.img,hda,w&#39;,</div><div># =A0 =A0 =A0 =A0 &#39;file:/mnt/win7.is=
o,hdc:cdrom,r&#39;,</div>
<div>=A0 =A0 =A0 =A0 ]</div><div>vif =3D [ &#39;type=3Dioemu, mac=3D00:16:3=
e:3f:74:01 , bridge=3Deth0 =A0,model=3De1000&#39;, ]</div><div>uuid =3D &qu=
ot;11111111-2262-28d2-9b64-b11713adfb20&quot;</div><div>device_model =3D &q=
uot;/home/root1/xen/xen-4.1.2/tools/ioemu-dir/i386-dm/qemu-dm&quot;</div>
<div>kernel =3D &quot;/usr/lib/xen/boot/hvmloader&quot;</div><div>vnc=3D1</=
div><div>vnclisten=3D&quot;0.0.0.0&quot;</div><div>vncdisplay=3D0</div><div=
>apic=3D1</div><div>acpi=3D1</div><div>pae=3D1</div><div>boot=3D&quot;dc&qu=
ot;</div><div>
vcpus=3D2</div><div>serial =3D &quot;pty&quot;</div><div>on_reboot=3D&#39;r=
estart&#39;</div><div>on_crash=3D&#39;restart&#39;</div><div>dhcp=3D&#39;of=
f&#39;</div><div>stdvga=3D0</div><div>audio=3D1</div><div>soundhw=3D&#39;es=
1370&#39;</div>
<div>videoram=3D16</div><div>usb=3D1</div><div>usb_add=3D&#39;host:0204:602=
5&#39;</div><div>usbdevice=3D&#39;tablet&#39;</div><div><br></div><div><br>=
<br><div class=3D"gmail_quote">2012/9/25 Konrad Rzeszutek Wilk <span dir=3D=
"ltr">&lt;<a href=3D"mailto:konrad@kernel.org" target=3D"_blank">konrad@ker=
nel.org</a>&gt;</span><br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div class=3D"im">On Tue, Sep 25, 2012 at 11=
:17:03AM +0800, Qian Hu wrote:<br>
</div><div class=3D"im">&gt; Hi, everyone! The same question with updated m=
essage.<br>
&gt;<br>
&gt; I am working on the USB passthrough of Xen-4.1.2. My host OS =A0is Fed=
ora 14<br>
&gt; and the guest OS is win7.<br>
&gt;<br>
&gt; According to the wiki page(<a href=3D"http://wiki.xen.org/wiki/Xen_USB=
_Passthrough" target=3D"_blank">http://wiki.xen.org/wiki/Xen_USB_Passthroug=
h</a>),<br>
&gt;<br>
&gt; xen supports passthrough of usb device from dom0 to guests. I have tri=
ed<br>
&gt; the Xen HVM guest qemu-dm usb1.1 emulation,<br>
&gt;<br>
&gt; by specifying &quot;usb =3D 1&quot; and &quot;usbdevice =3D host:xxxx:=
yyyy&quot;. I have also tried<br>
&gt; the command usb_add host:xxxx:yyyy.<br>
<br>
</div>Do you also re-assign the device from the Linux kernel? Like this:<br=
>
<br>
(the C408 0040 is my mouse).<br>
<br>
=A0cd /sys/bus/usb/drivers/usbhid<br>
=A0for a in `ls -1 | grep :`<br>
=A0do<br>
=A0 =A0for DEV in C408 0040<br>
=A0 =A0do<br>
=A0 =A0 =A0 =A0 grep $DEV $a/modalias<br>
=A0 =A0 =A0 =A0 if [ $? -eq 0 ]; then<br>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 echo &quot;Unbinding $a for $DEV&quot;<br>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 echo $a &gt; unbind<br>
=A0 =A0 =A0 =A0 fi<br>
=A0 =A0done<br>
=A0done<br>
<br>
This is what the config file looks for me:<br>
builder=3D&#39;hvm&#39;<br>
memory =3D 2048<br>
name =3D &quot;Windows7&quot;<br>
vcpus=3D3<br>
disk =3D [ &#39;phy:/dev/vg_guest/Win7_Home,hda,w&#39;]<br>
vnc=3D1<br>
videoram=3D8<br>
vnclisten=3D&quot;0.0.0.0&quot;<br>
vncpasswd=3D&#39;&#39;<br>
stdvga=3D0<br>
serial=3D&#39;pty&#39;<br>
tsc_mode=3D0<br>
usb=3D1<br>
usb_add=3D&quot;host:045e:0040&quot;<br>
usbdevice=3D&#39;tablet&#39;<br>
xen_platform_pci=3D1<br>
# Remember QEMU_AUDIO_DRV=3Dpa<br>
soundhw=3D&#39;es1370&#39;<br>
pci=3D[&#39;01:00.0&#39;,&#39;01:00.1&#39;,&#39;02:00.0&#39;]<br>
</blockquote></div><br></div></div></div>

--047d7b339d9d6568e604ca96c29d--


--===============4373729542900537773==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============4373729542900537773==--


From xen-devel-bounces@lists.xen.org Wed Sep 26 08:39:44 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Sep 2012 08: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 1TGn9U-0006FB-2r; Wed, 26 Sep 2012 08:39:28 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <qianhu2011@gmail.com>) id 1TGn9R-0006F0-PK
	for xen-devel@lists.xen.org; Wed, 26 Sep 2012 08:39:26 +0000
Received: from [85.158.139.211:32487] by server-15.bemta-5.messagelabs.com id
	86/3B-19430-C3FB2605; Wed, 26 Sep 2012 08:39:24 +0000
X-Env-Sender: qianhu2011@gmail.com
X-Msg-Ref: server-16.tower-206.messagelabs.com!1348648762!20029412!1
X-Originating-IP: [209.85.212.45]
X-SpamReason: No, hits=0.9 required=7.0 tests=HTML_40_50,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27074 invoked from network); 26 Sep 2012 08:39:23 -0000
Received: from mail-vb0-f45.google.com (HELO mail-vb0-f45.google.com)
	(209.85.212.45)
	by server-16.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Sep 2012 08:39:23 -0000
Received: by vbip1 with SMTP id p1so360394vbi.32
	for <xen-devel@lists.xen.org>; Wed, 26 Sep 2012 01:39:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=ogF39iOUasAdLijKjOzEdaXBnZJy30C0vfrz3HQ1TX8=;
	b=tI0oBQa9wC0iU5FnwDmidwh3pckBbLaXN3mvD4v9qhq8nLYSf/D+OBNbXCo05HmMyB
	MGriuv8q9Ajcepu19K33T0aiQzhEx5Y3MQ3N+30Sv1kD3B/T8r8pnrKc0UUlw9OzFSR+
	JDJlqyCRIIGk5pC/fXIcGDvXesi+XwVC98r2cq8Sy9rDWQ0ehPPFjJ6JV+RaEsdaflTt
	7fQCad0BzFaRcNGtfgJnpXT5K0iXqDVhjZLr1D0JeaBXV4KtHqAbHS6qypC19BLJG/X2
	6U+/Hza5uxVRVQh5UpoaJWaOg7HrOaYKOS7V3K+IVT3E5xQgNme9sSRXIBJVWe8LRvS+
	WFEQ==
MIME-Version: 1.0
Received: by 10.58.23.100 with SMTP id l4mr10800232vef.46.1348648762173; Wed,
	26 Sep 2012 01:39:22 -0700 (PDT)
Received: by 10.58.249.236 with HTTP; Wed, 26 Sep 2012 01:39:22 -0700 (PDT)
In-Reply-To: <20120925140421.GA16478@phenom.dumpdata.com>
References: <CALCpXpCvGkjZyG-NOY+fZY0q0f_DxuwPNEnxwKXVhjOe=gcHSQ@mail.gmail.com>
	<20120925140421.GA16478@phenom.dumpdata.com>
Date: Wed, 26 Sep 2012 16:39:22 +0800
Message-ID: <CALCpXpBJj23e3j_W4Mf2CJ57NSgx2YvnFMdB-0NgaJ=Wgvf60w@mail.gmail.com>
From: Qian Hu <qianhu2011@gmail.com>
To: Konrad Rzeszutek Wilk <konrad@kernel.org>
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] usbpassthrough of xen-4.1.2 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: multipart/mixed; boundary="===============4373729542900537773=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============4373729542900537773==
Content-Type: multipart/alternative; boundary=047d7b339d9d6568e604ca96c29d

--047d7b339d9d6568e604ca96c29d
Content-Type: text/plain; charset=ISO-8859-1

I am sorry what does the re-assign mean? By the way, where can I find the
ID C408 0040?

It seems not to be the message listed by "lsusb".

Below is my config file, similar with yours.

import os, re
arch = os.uname()[4]
if re.search('64', arch):
   arch_libdir = 'lib64'
else:
  arch_libdir = 'lib'

name = "win7"
builder = "hvm"
memory = "1024"
disk = [ 'file:/root/win7.img,hda,w',
#         'file:/mnt/win7.iso,hdc:cdrom,r',
        ]
vif = [ 'type=ioemu, mac=00:16:3e:3f:74:01 , bridge=eth0  ,model=e1000', ]
uuid = "11111111-2262-28d2-9b64-b11713adfb20"
device_model = "/home/root1/xen/xen-4.1.2/tools/ioemu-dir/i386-dm/qemu-dm"
kernel = "/usr/lib/xen/boot/hvmloader"
vnc=1
vnclisten="0.0.0.0"
vncdisplay=0
apic=1
acpi=1
pae=1
boot="dc"
vcpus=2
serial = "pty"
on_reboot='restart'
on_crash='restart'
dhcp='off'
stdvga=0
audio=1
soundhw='es1370'
videoram=16
usb=1
usb_add='host:0204:6025'
usbdevice='tablet'



2012/9/25 Konrad Rzeszutek Wilk <konrad@kernel.org>

> On Tue, Sep 25, 2012 at 11:17:03AM +0800, Qian Hu wrote:
> > Hi, everyone! The same question with updated message.
> >
> > I am working on the USB passthrough of Xen-4.1.2. My host OS  is Fedora
> 14
> > and the guest OS is win7.
> >
> > According to the wiki page(http://wiki.xen.org/wiki/Xen_USB_Passthrough
> ),
> >
> > xen supports passthrough of usb device from dom0 to guests. I have tried
> > the Xen HVM guest qemu-dm usb1.1 emulation,
> >
> > by specifying "usb = 1" and "usbdevice = host:xxxx:yyyy". I have also
> tried
> > the command usb_add host:xxxx:yyyy.
>
> Do you also re-assign the device from the Linux kernel? Like this:
>
> (the C408 0040 is my mouse).
>
>  cd /sys/bus/usb/drivers/usbhid
>  for a in `ls -1 | grep :`
>  do
>    for DEV in C408 0040
>    do
>         grep $DEV $a/modalias
>         if [ $? -eq 0 ]; then
>                 echo "Unbinding $a for $DEV"
>                 echo $a > unbind
>         fi
>    done
>  done
>
> This is what the config file looks for me:
> builder='hvm'
> memory = 2048
> name = "Windows7"
> vcpus=3
> disk = [ 'phy:/dev/vg_guest/Win7_Home,hda,w']
> vnc=1
> videoram=8
> vnclisten="0.0.0.0"
> vncpasswd=''
> stdvga=0
> serial='pty'
> tsc_mode=0
> usb=1
> usb_add="host:045e:0040"
> usbdevice='tablet'
> xen_platform_pci=1
> # Remember QEMU_AUDIO_DRV=pa
> soundhw='es1370'
> pci=['01:00.0','01:00.1','02:00.0']
>

--047d7b339d9d6568e604ca96c29d
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

I am sorry what does the re-assign mean? By the way, where can I find the I=
D=A0C408 0040?<div><br></div><div>It seems not to be the message listed by =
&quot;lsusb&quot;.<br><div><br></div><div>Below is my config file, similar =
with yours.</div>
<div><br></div><div><div>import os, re</div><div>arch =3D os.uname()[4]</di=
v><div>if re.search(&#39;64&#39;, arch):</div><div>=A0 =A0arch_libdir =3D &=
#39;lib64&#39;</div><div>else:</div><div>=A0 arch_libdir =3D &#39;lib&#39;<=
/div><div>
<br></div><div>name =3D &quot;win7&quot;</div><div>builder =3D &quot;hvm&qu=
ot;</div><div>memory =3D &quot;1024&quot;</div><div>disk =3D [ &#39;file:/r=
oot/win7.img,hda,w&#39;,</div><div># =A0 =A0 =A0 =A0 &#39;file:/mnt/win7.is=
o,hdc:cdrom,r&#39;,</div>
<div>=A0 =A0 =A0 =A0 ]</div><div>vif =3D [ &#39;type=3Dioemu, mac=3D00:16:3=
e:3f:74:01 , bridge=3Deth0 =A0,model=3De1000&#39;, ]</div><div>uuid =3D &qu=
ot;11111111-2262-28d2-9b64-b11713adfb20&quot;</div><div>device_model =3D &q=
uot;/home/root1/xen/xen-4.1.2/tools/ioemu-dir/i386-dm/qemu-dm&quot;</div>
<div>kernel =3D &quot;/usr/lib/xen/boot/hvmloader&quot;</div><div>vnc=3D1</=
div><div>vnclisten=3D&quot;0.0.0.0&quot;</div><div>vncdisplay=3D0</div><div=
>apic=3D1</div><div>acpi=3D1</div><div>pae=3D1</div><div>boot=3D&quot;dc&qu=
ot;</div><div>
vcpus=3D2</div><div>serial =3D &quot;pty&quot;</div><div>on_reboot=3D&#39;r=
estart&#39;</div><div>on_crash=3D&#39;restart&#39;</div><div>dhcp=3D&#39;of=
f&#39;</div><div>stdvga=3D0</div><div>audio=3D1</div><div>soundhw=3D&#39;es=
1370&#39;</div>
<div>videoram=3D16</div><div>usb=3D1</div><div>usb_add=3D&#39;host:0204:602=
5&#39;</div><div>usbdevice=3D&#39;tablet&#39;</div><div><br></div><div><br>=
<br><div class=3D"gmail_quote">2012/9/25 Konrad Rzeszutek Wilk <span dir=3D=
"ltr">&lt;<a href=3D"mailto:konrad@kernel.org" target=3D"_blank">konrad@ker=
nel.org</a>&gt;</span><br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div class=3D"im">On Tue, Sep 25, 2012 at 11=
:17:03AM +0800, Qian Hu wrote:<br>
</div><div class=3D"im">&gt; Hi, everyone! The same question with updated m=
essage.<br>
&gt;<br>
&gt; I am working on the USB passthrough of Xen-4.1.2. My host OS =A0is Fed=
ora 14<br>
&gt; and the guest OS is win7.<br>
&gt;<br>
&gt; According to the wiki page(<a href=3D"http://wiki.xen.org/wiki/Xen_USB=
_Passthrough" target=3D"_blank">http://wiki.xen.org/wiki/Xen_USB_Passthroug=
h</a>),<br>
&gt;<br>
&gt; xen supports passthrough of usb device from dom0 to guests. I have tri=
ed<br>
&gt; the Xen HVM guest qemu-dm usb1.1 emulation,<br>
&gt;<br>
&gt; by specifying &quot;usb =3D 1&quot; and &quot;usbdevice =3D host:xxxx:=
yyyy&quot;. I have also tried<br>
&gt; the command usb_add host:xxxx:yyyy.<br>
<br>
</div>Do you also re-assign the device from the Linux kernel? Like this:<br=
>
<br>
(the C408 0040 is my mouse).<br>
<br>
=A0cd /sys/bus/usb/drivers/usbhid<br>
=A0for a in `ls -1 | grep :`<br>
=A0do<br>
=A0 =A0for DEV in C408 0040<br>
=A0 =A0do<br>
=A0 =A0 =A0 =A0 grep $DEV $a/modalias<br>
=A0 =A0 =A0 =A0 if [ $? -eq 0 ]; then<br>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 echo &quot;Unbinding $a for $DEV&quot;<br>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 echo $a &gt; unbind<br>
=A0 =A0 =A0 =A0 fi<br>
=A0 =A0done<br>
=A0done<br>
<br>
This is what the config file looks for me:<br>
builder=3D&#39;hvm&#39;<br>
memory =3D 2048<br>
name =3D &quot;Windows7&quot;<br>
vcpus=3D3<br>
disk =3D [ &#39;phy:/dev/vg_guest/Win7_Home,hda,w&#39;]<br>
vnc=3D1<br>
videoram=3D8<br>
vnclisten=3D&quot;0.0.0.0&quot;<br>
vncpasswd=3D&#39;&#39;<br>
stdvga=3D0<br>
serial=3D&#39;pty&#39;<br>
tsc_mode=3D0<br>
usb=3D1<br>
usb_add=3D&quot;host:045e:0040&quot;<br>
usbdevice=3D&#39;tablet&#39;<br>
xen_platform_pci=3D1<br>
# Remember QEMU_AUDIO_DRV=3Dpa<br>
soundhw=3D&#39;es1370&#39;<br>
pci=3D[&#39;01:00.0&#39;,&#39;01:00.1&#39;,&#39;02:00.0&#39;]<br>
</blockquote></div><br></div></div></div>

--047d7b339d9d6568e604ca96c29d--


--===============4373729542900537773==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============4373729542900537773==--


From xen-devel-bounces@lists.xen.org Wed Sep 26 08:42:59 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Sep 2012 08: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 1TGnCa-0006Lj-Mm; Wed, 26 Sep 2012 08:42: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 1TGnCZ-0006Lb-FQ
	for xen-devel@lists.xen.org; Wed, 26 Sep 2012 08:42:39 +0000
Received: from [85.158.143.35:24401] by server-2.bemta-4.messagelabs.com id
	26/69-06610-EFFB2605; Wed, 26 Sep 2012 08:42:38 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1348648956!13705671!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTEzMTI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25729 invoked from network); 26 Sep 2012 08:42:37 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Sep 2012 08:42:37 -0000
X-IronPort-AV: E=Sophos;i="4.80,489,1344211200"; d="scan'208";a="14769504"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Sep 2012 08:42: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.279.1;
	Wed, 26 Sep 2012 09:42:25 +0100
Message-ID: <1348648943.19176.8.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: George Shuklin <george.shuklin@gmail.com>
Date: Wed, 26 Sep 2012 09:42:23 +0100
In-Reply-To: <5062BDA8.5@gmail.com>
References: <5062BDA8.5@gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] start_info content for 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

On Wed, 2012-09-26 at 09:32 +0100, George Shuklin wrote:
> Good day.
> 
> I've digging in some strange memory/balloon related bug and I've really 
> like to see start_info content on linux. I saw in source code
> 
> #ifdef CONFIG_X86_32
>          mov %esi,xen_start_info
>          mov $init_thread_union+THREAD_SIZE,%esp
> #else
>          mov %rsi,xen_start_info
>          mov $init_thread_union+THREAD_SIZE,%rsp
> #endif
>          jmp xen_start_kernel
> 
> Pointer to start_info stored in linux global variable xen_start_info, 
> but I can't find way to access it.
>
> Is any way to get it from linux kernel? (well, except writing your own 
> module).

I don't think this structure is exported to userspace, so I'm afraid it
would have to be a module, or use some sort of /dev/kmem capable
debugger (I don't know one to recommend though).

To do any serious debugging of ballooning you are probably going to need
to build a kernel with debugging added anyway 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 Sep 26 08:42:59 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Sep 2012 08: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 1TGnCa-0006Lj-Mm; Wed, 26 Sep 2012 08:42: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 1TGnCZ-0006Lb-FQ
	for xen-devel@lists.xen.org; Wed, 26 Sep 2012 08:42:39 +0000
Received: from [85.158.143.35:24401] by server-2.bemta-4.messagelabs.com id
	26/69-06610-EFFB2605; Wed, 26 Sep 2012 08:42:38 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1348648956!13705671!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTEzMTI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25729 invoked from network); 26 Sep 2012 08:42:37 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Sep 2012 08:42:37 -0000
X-IronPort-AV: E=Sophos;i="4.80,489,1344211200"; d="scan'208";a="14769504"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Sep 2012 08:42: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.279.1;
	Wed, 26 Sep 2012 09:42:25 +0100
Message-ID: <1348648943.19176.8.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: George Shuklin <george.shuklin@gmail.com>
Date: Wed, 26 Sep 2012 09:42:23 +0100
In-Reply-To: <5062BDA8.5@gmail.com>
References: <5062BDA8.5@gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] start_info content for 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

On Wed, 2012-09-26 at 09:32 +0100, George Shuklin wrote:
> Good day.
> 
> I've digging in some strange memory/balloon related bug and I've really 
> like to see start_info content on linux. I saw in source code
> 
> #ifdef CONFIG_X86_32
>          mov %esi,xen_start_info
>          mov $init_thread_union+THREAD_SIZE,%esp
> #else
>          mov %rsi,xen_start_info
>          mov $init_thread_union+THREAD_SIZE,%rsp
> #endif
>          jmp xen_start_kernel
> 
> Pointer to start_info stored in linux global variable xen_start_info, 
> but I can't find way to access it.
>
> Is any way to get it from linux kernel? (well, except writing your own 
> module).

I don't think this structure is exported to userspace, so I'm afraid it
would have to be a module, or use some sort of /dev/kmem capable
debugger (I don't know one to recommend though).

To do any serious debugging of ballooning you are probably going to need
to build a kernel with debugging added anyway 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 Sep 26 08:49:40 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Sep 2012 08: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 1TGnJ9-0006ZA-F9; Wed, 26 Sep 2012 08:49:27 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <zhenzhong.duan@oracle.com>) id 1TGnJ7-0006Ye-Q6
	for xen-devel@lists.xen.org; Wed, 26 Sep 2012 08:49:26 +0000
X-Env-Sender: zhenzhong.duan@oracle.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1348649333!9107045!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDc3NDE3Nw==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19103 invoked from network); 26 Sep 2012 08:48:57 -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; 26 Sep 2012 08:48: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 q8Q8mpEH004095
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK)
	for <xen-devel@lists.xen.org>; Wed, 26 Sep 2012 08:48:52 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
	q8Q8mnZv002754
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for <xen-devel@lists.xen.org>; Wed, 26 Sep 2012 08:48:51 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
	q8Q8mngP021242
	for <xen-devel@lists.xen.org>; Wed, 26 Sep 2012 03:48:49 -0500
Received: from [10.191.12.241] (/10.191.12.241)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 26 Sep 2012 01:48:48 -0700
Message-ID: <5062C16A.1020306@oracle.com>
Date: Wed, 26 Sep 2012 16:48:42 +0800
From: Zhenzhong Duan <zhenzhong.duan@oracle.com>
Organization: oracle
User-Agent: Mozilla/5.0 (Windows NT 5.1;
	rv:12.0) Gecko/20120428 Thunderbird/12.0.1
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
References: <505C3647.1030003@oracle.com>
	<20120921143430.GA3522@phenom.dumpdata.com>
In-Reply-To: <20120921143430.GA3522@phenom.dumpdata.com>
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: Dan Magenheimer <dan.magenheimer@oracle.com>, Feng Jin <joe.jin@oracle.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] an issue with 'xm save'
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: zhenzhong.duan@oracle.com
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============4398659321201040798=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a multi-part message in MIME format.
--===============4398659321201040798==
Content-Type: multipart/alternative;
 boundary="------------030209060703080401070101"

This is a multi-part message in MIME format.
--------------030209060703080401070101
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Konrad Rzeszutek Wilk wrote:
> On Fri, Sep 21, 2012 at 05:41:27PM +0800, Zhenzhong Duan wrote:
>    
>> Hi maintainers,
>>
>> I found there is an issue when 'xm save' a pvm guest. See below:
>>
>> When I do save then restore once, CPU(%) in xentop showed around 99%.
>> When I do that second time, CPU(%) showed 199%
>>
>> top in dom0 showed:
>>      PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
>>     20946 root      18  -2 10984 1284  964 S 19.8  0.3   0:48.93 block
>>     4939 root      18  -2 10984 1288  964 S 19.5  0.3   1:34.68 block
>>
>> I could kill the block process, then all look normal again.
>>      
>
> What is the 'block' process? If you attach 'perf' to it do you get an idea
> of what it is spinning at?
>    
It's /etc/xen/scripts/block
I add 'set -x' to /etc/xen/scripts/block, found it blocked at claim_lock.
When domU was created first time, claim_lock/release_lock finished quickly,
when 'xm save' was called, claim_lock spin in its own while loop.
I can ensure no other domU create/save/etc happen when I test.
>    
>> xen and xen-tools are both generated with xen-unstable.
>> I tried xl, but it segfault.
>>      
>
> It segfaulted? When doing 'xl save'  or 'xl resume'? Or just allocating
> the guest?
>    
When xl create vm.cfg
>    
>> I also tried ovm3.1.1(xen-4.1.2-18.el5.1 and xen-tools-4.1.2-18.el5.1),
>> can't reproduce.
>>      
>
> So the issue is only present with Xen-unstable?
>    
Yes,  I found in /etc/xen/scripts/locking.sh of ovm3.1.1, func 
claim_lock is quite different to xen-unstable
Maybe this is why ovm3.1.1 work with save/restore.
> Did you clear _any_ older Xen libraries/tools when you installed Xen-unstable?
>    
No, I built xen and xen-tools on el5, then installed to ovm3.1.1 on 
other partition.
thanks
zduan

--------------030209060703080401070101
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">
    <title></title>
  </head>
  <body bgcolor="#ffffff" text="#000000">
    Konrad Rzeszutek Wilk wrote:
    <blockquote cite="mid:20120921143430.GA3522@phenom.dumpdata.com"
      type="cite">
      <pre wrap="">On Fri, Sep 21, 2012 at 05:41:27PM +0800, Zhenzhong Duan wrote:
  </pre>
      <blockquote type="cite">
        <pre wrap="">Hi maintainers,

I found there is an issue when 'xm save' a pvm guest. See below:

When I do save then restore once, CPU(%) in xentop showed around 99%.
When I do that second time, CPU(%) showed 199%

top in dom0 showed:
    PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
   20946 root      18  -2 10984 1284  964 S 19.8  0.3   0:48.93 block
   4939 root      18  -2 10984 1288  964 S 19.5  0.3   1:34.68 block

I could kill the block process, then all look normal again.
    </pre>
      </blockquote>
      <pre wrap=""><!---->
What is the 'block' process? If you attach 'perf' to it do you get an idea
of what it is spinning at?
  </pre>
    </blockquote>
    It's /etc/xen/scripts/block<br>
    I add 'set -x' to /etc/xen/scripts/block, found it blocked at
    claim_lock.<br>
    When domU was created first time, claim_lock/release_lock finished
    quickly, <br>
    when 'xm save' was called, claim_lock spin in its own while loop.<br>
    I can ensure no other domU create/save/etc happen when I test.<br>
    <blockquote cite="mid:20120921143430.GA3522@phenom.dumpdata.com"
      type="cite">
      <pre wrap="">  </pre>
      <blockquote type="cite">
        <pre wrap="">xen and xen-tools are both generated with xen-unstable.
I tried xl, but it segfault.
    </pre>
      </blockquote>
      <pre wrap=""><!---->
It segfaulted? When doing 'xl save'  or 'xl resume'? Or just allocating
the guest?
  </pre>
    </blockquote>
    When xl create vm.cfg<br>
    <blockquote cite="mid:20120921143430.GA3522@phenom.dumpdata.com"
      type="cite">
      <pre wrap="">  </pre>
      <blockquote type="cite">
        <pre wrap="">I also tried ovm3.1.1(xen-4.1.2-18.el5.1 and xen-tools-4.1.2-18.el5.1),
can't reproduce.
    </pre>
      </blockquote>
      <pre wrap=""><!---->
So the issue is only present with Xen-unstable?
  </pre>
    </blockquote>
    Yes,&nbsp; I found in /etc/xen/scripts/locking.sh of ovm3.1.1, func
    claim_lock is quite different to xen-unstable<br>
    Maybe this is why ovm3.1.1 work with save/restore.<br>
    <blockquote cite="mid:20120921143430.GA3522@phenom.dumpdata.com"
      type="cite">
      <pre wrap="">Did you clear _any_ older Xen libraries/tools when you installed Xen-unstable?
  </pre>
    </blockquote>
    No, I built xen and xen-tools on el5, then installed to ovm3.1.1 on
    other partition.<br>
    thanks<br>
    zduan
  </body>
</html>

--------------030209060703080401070101--


--===============4398659321201040798==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============4398659321201040798==--


From xen-devel-bounces@lists.xen.org Wed Sep 26 08:49:40 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Sep 2012 08: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 1TGnJ9-0006ZA-F9; Wed, 26 Sep 2012 08:49:27 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <zhenzhong.duan@oracle.com>) id 1TGnJ7-0006Ye-Q6
	for xen-devel@lists.xen.org; Wed, 26 Sep 2012 08:49:26 +0000
X-Env-Sender: zhenzhong.duan@oracle.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1348649333!9107045!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDc3NDE3Nw==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19103 invoked from network); 26 Sep 2012 08:48:57 -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; 26 Sep 2012 08:48: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 q8Q8mpEH004095
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK)
	for <xen-devel@lists.xen.org>; Wed, 26 Sep 2012 08:48:52 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
	q8Q8mnZv002754
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for <xen-devel@lists.xen.org>; Wed, 26 Sep 2012 08:48:51 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
	q8Q8mngP021242
	for <xen-devel@lists.xen.org>; Wed, 26 Sep 2012 03:48:49 -0500
Received: from [10.191.12.241] (/10.191.12.241)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 26 Sep 2012 01:48:48 -0700
Message-ID: <5062C16A.1020306@oracle.com>
Date: Wed, 26 Sep 2012 16:48:42 +0800
From: Zhenzhong Duan <zhenzhong.duan@oracle.com>
Organization: oracle
User-Agent: Mozilla/5.0 (Windows NT 5.1;
	rv:12.0) Gecko/20120428 Thunderbird/12.0.1
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
References: <505C3647.1030003@oracle.com>
	<20120921143430.GA3522@phenom.dumpdata.com>
In-Reply-To: <20120921143430.GA3522@phenom.dumpdata.com>
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: Dan Magenheimer <dan.magenheimer@oracle.com>, Feng Jin <joe.jin@oracle.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] an issue with 'xm save'
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: zhenzhong.duan@oracle.com
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============4398659321201040798=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a multi-part message in MIME format.
--===============4398659321201040798==
Content-Type: multipart/alternative;
 boundary="------------030209060703080401070101"

This is a multi-part message in MIME format.
--------------030209060703080401070101
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Konrad Rzeszutek Wilk wrote:
> On Fri, Sep 21, 2012 at 05:41:27PM +0800, Zhenzhong Duan wrote:
>    
>> Hi maintainers,
>>
>> I found there is an issue when 'xm save' a pvm guest. See below:
>>
>> When I do save then restore once, CPU(%) in xentop showed around 99%.
>> When I do that second time, CPU(%) showed 199%
>>
>> top in dom0 showed:
>>      PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
>>     20946 root      18  -2 10984 1284  964 S 19.8  0.3   0:48.93 block
>>     4939 root      18  -2 10984 1288  964 S 19.5  0.3   1:34.68 block
>>
>> I could kill the block process, then all look normal again.
>>      
>
> What is the 'block' process? If you attach 'perf' to it do you get an idea
> of what it is spinning at?
>    
It's /etc/xen/scripts/block
I add 'set -x' to /etc/xen/scripts/block, found it blocked at claim_lock.
When domU was created first time, claim_lock/release_lock finished quickly,
when 'xm save' was called, claim_lock spin in its own while loop.
I can ensure no other domU create/save/etc happen when I test.
>    
>> xen and xen-tools are both generated with xen-unstable.
>> I tried xl, but it segfault.
>>      
>
> It segfaulted? When doing 'xl save'  or 'xl resume'? Or just allocating
> the guest?
>    
When xl create vm.cfg
>    
>> I also tried ovm3.1.1(xen-4.1.2-18.el5.1 and xen-tools-4.1.2-18.el5.1),
>> can't reproduce.
>>      
>
> So the issue is only present with Xen-unstable?
>    
Yes,  I found in /etc/xen/scripts/locking.sh of ovm3.1.1, func 
claim_lock is quite different to xen-unstable
Maybe this is why ovm3.1.1 work with save/restore.
> Did you clear _any_ older Xen libraries/tools when you installed Xen-unstable?
>    
No, I built xen and xen-tools on el5, then installed to ovm3.1.1 on 
other partition.
thanks
zduan

--------------030209060703080401070101
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">
    <title></title>
  </head>
  <body bgcolor="#ffffff" text="#000000">
    Konrad Rzeszutek Wilk wrote:
    <blockquote cite="mid:20120921143430.GA3522@phenom.dumpdata.com"
      type="cite">
      <pre wrap="">On Fri, Sep 21, 2012 at 05:41:27PM +0800, Zhenzhong Duan wrote:
  </pre>
      <blockquote type="cite">
        <pre wrap="">Hi maintainers,

I found there is an issue when 'xm save' a pvm guest. See below:

When I do save then restore once, CPU(%) in xentop showed around 99%.
When I do that second time, CPU(%) showed 199%

top in dom0 showed:
    PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
   20946 root      18  -2 10984 1284  964 S 19.8  0.3   0:48.93 block
   4939 root      18  -2 10984 1288  964 S 19.5  0.3   1:34.68 block

I could kill the block process, then all look normal again.
    </pre>
      </blockquote>
      <pre wrap=""><!---->
What is the 'block' process? If you attach 'perf' to it do you get an idea
of what it is spinning at?
  </pre>
    </blockquote>
    It's /etc/xen/scripts/block<br>
    I add 'set -x' to /etc/xen/scripts/block, found it blocked at
    claim_lock.<br>
    When domU was created first time, claim_lock/release_lock finished
    quickly, <br>
    when 'xm save' was called, claim_lock spin in its own while loop.<br>
    I can ensure no other domU create/save/etc happen when I test.<br>
    <blockquote cite="mid:20120921143430.GA3522@phenom.dumpdata.com"
      type="cite">
      <pre wrap="">  </pre>
      <blockquote type="cite">
        <pre wrap="">xen and xen-tools are both generated with xen-unstable.
I tried xl, but it segfault.
    </pre>
      </blockquote>
      <pre wrap=""><!---->
It segfaulted? When doing 'xl save'  or 'xl resume'? Or just allocating
the guest?
  </pre>
    </blockquote>
    When xl create vm.cfg<br>
    <blockquote cite="mid:20120921143430.GA3522@phenom.dumpdata.com"
      type="cite">
      <pre wrap="">  </pre>
      <blockquote type="cite">
        <pre wrap="">I also tried ovm3.1.1(xen-4.1.2-18.el5.1 and xen-tools-4.1.2-18.el5.1),
can't reproduce.
    </pre>
      </blockquote>
      <pre wrap=""><!---->
So the issue is only present with Xen-unstable?
  </pre>
    </blockquote>
    Yes,&nbsp; I found in /etc/xen/scripts/locking.sh of ovm3.1.1, func
    claim_lock is quite different to xen-unstable<br>
    Maybe this is why ovm3.1.1 work with save/restore.<br>
    <blockquote cite="mid:20120921143430.GA3522@phenom.dumpdata.com"
      type="cite">
      <pre wrap="">Did you clear _any_ older Xen libraries/tools when you installed Xen-unstable?
  </pre>
    </blockquote>
    No, I built xen and xen-tools on el5, then installed to ovm3.1.1 on
    other partition.<br>
    thanks<br>
    zduan
  </body>
</html>

--------------030209060703080401070101--


--===============4398659321201040798==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============4398659321201040798==--


From xen-devel-bounces@lists.xen.org Wed Sep 26 08:52:45 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Sep 2012 08:52:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGnMA-0006sJ-74; Wed, 26 Sep 2012 08:52:34 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1TGnM8-0006s7-Jy
	for xen-devel@lists.xensource.com; Wed, 26 Sep 2012 08:52:32 +0000
Received: from [85.158.139.83:61286] by server-10.bemta-5.messagelabs.com id
	82/C0-16911-F42C2605; Wed, 26 Sep 2012 08:52:31 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1348649551!32447836!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTEzMTI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15910 invoked from network); 26 Sep 2012 08:52:31 -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 Sep 2012 08:52:31 -0000
X-IronPort-AV: E=Sophos;i="4.80,489,1344211200"; d="scan'208";a="14769905"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Sep 2012 08:52: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.279.1;
	Wed, 26 Sep 2012 09:52:31 +0100
Message-ID: <1348649549.19176.15.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
Date: Wed, 26 Sep 2012 09:52:29 +0100
In-Reply-To: <5061E293.7000106@jhuapl.edu>
References: <505CBA02.5040308@jhuapl.edu>
	<1348569044.3452.176.camel@zakaz.uk.xensource.com>
	<5061E293.7000106@jhuapl.edu>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] PATCH [base vtpm and libxl patches 4/6] add iomem
 support to 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

On Tue, 2012-09-25 at 17:57 +0100, Matthew Fioravante wrote:
> >> @@ -1005,6 +1005,30 @@ static void parse_config_data(const char
> >> *config_source,
> >>          }
> >>      }
> >>  
> >> +    if (!xlu_cfg_get_list(config, "iomem", &iomem, &num_iomem, 0)) {
> >> +        b_info->num_iomem = num_iomem;
> >> +        b_info->iomem = calloc(num_iomem, sizeof(*b_info->iomem));
> >> +        if (b_info->iomem == NULL) {
> >> +            fprintf(stderr, "unable to allocate memory for iomem\n");
> >> +            exit(-1);
> >> +        }
> >> +        for (i = 0; i < num_iomem; i++) {
> >> +            buf = xlu_cfg_get_listitem (iomem, i);
> >> +            if (!buf) {
> >> +                fprintf(stderr,
> >> +                        "xl: Unable to get element %d in iomem list\n", i);
> >> +                exit(1);
> >> +            }
> >> +            if(sscanf(buf, "%" SCNx64",%" SCNu64,
> >> &b_info->iomem[i].start, &b_info->iomem[i].number) != 2) {
> > This should be relatively simply to parse with strtoul (see the ioports
> > case) which would allow people to select hex or decimal in their
> > configuration files.
> Do we want to support hex or decimal? Pretty much anytime people start
> talking about physical memory addresses or page numbers they use hex.
> Also the ioports code actually only supports hexadecimal as it sets the
> base in strtoul to 16. It also explicitly says in the xl.cfg manpage
> that ioports should be given in hex.

Good point. You mix decimal (SCNu64) and hex (SCNx64) though, it would
be better to be consistent (in hex) 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 Wed Sep 26 08:52:45 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Sep 2012 08:52:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGnMA-0006sJ-74; Wed, 26 Sep 2012 08:52:34 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1TGnM8-0006s7-Jy
	for xen-devel@lists.xensource.com; Wed, 26 Sep 2012 08:52:32 +0000
Received: from [85.158.139.83:61286] by server-10.bemta-5.messagelabs.com id
	82/C0-16911-F42C2605; Wed, 26 Sep 2012 08:52:31 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1348649551!32447836!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTEzMTI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15910 invoked from network); 26 Sep 2012 08:52:31 -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 Sep 2012 08:52:31 -0000
X-IronPort-AV: E=Sophos;i="4.80,489,1344211200"; d="scan'208";a="14769905"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Sep 2012 08:52: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.279.1;
	Wed, 26 Sep 2012 09:52:31 +0100
Message-ID: <1348649549.19176.15.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
Date: Wed, 26 Sep 2012 09:52:29 +0100
In-Reply-To: <5061E293.7000106@jhuapl.edu>
References: <505CBA02.5040308@jhuapl.edu>
	<1348569044.3452.176.camel@zakaz.uk.xensource.com>
	<5061E293.7000106@jhuapl.edu>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] PATCH [base vtpm and libxl patches 4/6] add iomem
 support to 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

On Tue, 2012-09-25 at 17:57 +0100, Matthew Fioravante wrote:
> >> @@ -1005,6 +1005,30 @@ static void parse_config_data(const char
> >> *config_source,
> >>          }
> >>      }
> >>  
> >> +    if (!xlu_cfg_get_list(config, "iomem", &iomem, &num_iomem, 0)) {
> >> +        b_info->num_iomem = num_iomem;
> >> +        b_info->iomem = calloc(num_iomem, sizeof(*b_info->iomem));
> >> +        if (b_info->iomem == NULL) {
> >> +            fprintf(stderr, "unable to allocate memory for iomem\n");
> >> +            exit(-1);
> >> +        }
> >> +        for (i = 0; i < num_iomem; i++) {
> >> +            buf = xlu_cfg_get_listitem (iomem, i);
> >> +            if (!buf) {
> >> +                fprintf(stderr,
> >> +                        "xl: Unable to get element %d in iomem list\n", i);
> >> +                exit(1);
> >> +            }
> >> +            if(sscanf(buf, "%" SCNx64",%" SCNu64,
> >> &b_info->iomem[i].start, &b_info->iomem[i].number) != 2) {
> > This should be relatively simply to parse with strtoul (see the ioports
> > case) which would allow people to select hex or decimal in their
> > configuration files.
> Do we want to support hex or decimal? Pretty much anytime people start
> talking about physical memory addresses or page numbers they use hex.
> Also the ioports code actually only supports hexadecimal as it sets the
> base in strtoul to 16. It also explicitly says in the xl.cfg manpage
> that ioports should be given in hex.

Good point. You mix decimal (SCNu64) and hex (SCNx64) though, it would
be better to be consistent (in hex) 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 Wed Sep 26 08:58:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Sep 2012 08: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 1TGnRH-00079Y-Um; Wed, 26 Sep 2012 08:57: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 1TGnRG-00079R-Hh
	for xen-devel@lists.xen.org; Wed, 26 Sep 2012 08:57:50 +0000
Received: from [85.158.143.99:29732] by server-3.bemta-4.messagelabs.com id
	70/98-10986-D83C2605; Wed, 26 Sep 2012 08:57:49 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1348649869!24286542!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2285 invoked from network); 26 Sep 2012 08:57:49 -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;
	26 Sep 2012 08:57:49 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 26 Sep 2012 09:57:49 +0100
Message-Id: <5062DFC4020000780009DEA5@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 26 Sep 2012 09:58:12 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>
References: <1348608440-4018-1-git-send-email-konrad.wilk@oracle.com>
	<1348608440-4018-3-git-send-email-konrad.wilk@oracle.com>
In-Reply-To: <1348608440-4018-3-git-send-email-konrad.wilk@oracle.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: linux-kernel@vger.kernel.org, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 2/2] xen/pciback: When resetting the device
 don't disable twice.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.09.12 at 23:27, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
> We call 'pci_disable_device' which sets the bus_master to zero
> and it also disables the PCI_COMMAND. There is no need to
> do it outside the PCI library.

Not really - pci_disable_device() only does anything if enable_cnt
drops to zero, and only clears the bus master flag in the command
word.

The code you delete fully zeros the command word unconditionally.
(I also noticed that the old [forward ported] code here forced
enable_cnt to zero.)

Hence the question is whether this really isn't a functional
change rather than mere cleanup.

Jan

> --- a/drivers/xen/xen-pciback/pciback_ops.c
> +++ b/drivers/xen/xen-pciback/pciback_ops.c
> @@ -114,10 +114,6 @@ void xen_pcibk_reset_device(struct pci_dev *dev)
>  			pci_disable_msi(dev);
>  #endif
>  		pci_disable_device(dev);
> -
> -		pci_write_config_word(dev, PCI_COMMAND, 0);
> -
> -		dev->is_busmaster = 0;
>  	} else {
>  		pci_read_config_word(dev, PCI_COMMAND, &cmd);
>  		if (cmd & (PCI_COMMAND_INVALIDATE)) {



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 26 08:58:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Sep 2012 08: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 1TGnRH-00079Y-Um; Wed, 26 Sep 2012 08:57: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 1TGnRG-00079R-Hh
	for xen-devel@lists.xen.org; Wed, 26 Sep 2012 08:57:50 +0000
Received: from [85.158.143.99:29732] by server-3.bemta-4.messagelabs.com id
	70/98-10986-D83C2605; Wed, 26 Sep 2012 08:57:49 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1348649869!24286542!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2285 invoked from network); 26 Sep 2012 08:57:49 -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;
	26 Sep 2012 08:57:49 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 26 Sep 2012 09:57:49 +0100
Message-Id: <5062DFC4020000780009DEA5@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 26 Sep 2012 09:58:12 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>
References: <1348608440-4018-1-git-send-email-konrad.wilk@oracle.com>
	<1348608440-4018-3-git-send-email-konrad.wilk@oracle.com>
In-Reply-To: <1348608440-4018-3-git-send-email-konrad.wilk@oracle.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: linux-kernel@vger.kernel.org, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 2/2] xen/pciback: When resetting the device
 don't disable twice.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.09.12 at 23:27, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
> We call 'pci_disable_device' which sets the bus_master to zero
> and it also disables the PCI_COMMAND. There is no need to
> do it outside the PCI library.

Not really - pci_disable_device() only does anything if enable_cnt
drops to zero, and only clears the bus master flag in the command
word.

The code you delete fully zeros the command word unconditionally.
(I also noticed that the old [forward ported] code here forced
enable_cnt to zero.)

Hence the question is whether this really isn't a functional
change rather than mere cleanup.

Jan

> --- a/drivers/xen/xen-pciback/pciback_ops.c
> +++ b/drivers/xen/xen-pciback/pciback_ops.c
> @@ -114,10 +114,6 @@ void xen_pcibk_reset_device(struct pci_dev *dev)
>  			pci_disable_msi(dev);
>  #endif
>  		pci_disable_device(dev);
> -
> -		pci_write_config_word(dev, PCI_COMMAND, 0);
> -
> -		dev->is_busmaster = 0;
>  	} else {
>  		pci_read_config_word(dev, PCI_COMMAND, &cmd);
>  		if (cmd & (PCI_COMMAND_INVALIDATE)) {



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 26 09:41:31 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Sep 2012 09:41:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGo7B-0007ip-0k; Wed, 26 Sep 2012 09:41:09 +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 1TGo78-0007ik-UK
	for xen-devel@lists.xen.org; Wed, 26 Sep 2012 09:41:07 +0000
Received: from [85.158.137.99:60656] by server-2.bemta-3.messagelabs.com id
	D1/B3-16514-2BDC2605; Wed, 26 Sep 2012 09:41:06 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-2.tower-217.messagelabs.com!1348652463!19055213!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNzc0NzM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21191 invoked from network); 26 Sep 2012 09:41:05 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-2.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Sep 2012 09:41:05 -0000
X-IronPort-AV: E=Sophos;i="4.80,489,1344211200"; d="scan'208";a="209380139"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Sep 2012 09:41:03 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 26 Sep 2012 05:41:03 -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 1TGo74-0000hx-V2;
	Wed, 26 Sep 2012 10:41:02 +0100
Message-ID: <5062CCA5.8010903@eu.citrix.com>
Date: Wed, 26 Sep 2012 10:36:37 +0100
From: George Dunlap <george.dunlap@eu.citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120827 Thunderbird/15.0
MIME-Version: 1.0
To: Matt Wilson <msw@amazon.com>
References: <CAFLBxZYtmJ_bKFb90r45=C4Pq1-oe5Fy=eygSsQf4BcGj3EqGA@mail.gmail.com>
	<505ADBCF020000780009C7BE@nat28.tlf.novell.com>
	<20120921031759.GA3953@u002268147cd4502c336d.ant.amazon.com>
In-Reply-To: <20120921031759.GA3953@u002268147cd4502c336d.ant.amazon.com>
Cc: Thanos Makatos <thanos.makatos@citrix.com>, Jan Beulich <JBeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.3 development 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-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 21/09/12 04:18, Matt Wilson wrote:
> On Thu, Sep 20, 2012 at 08:03:11AM +0100, Jan Beulich wrote:
>>> On 19.09.12 at 18:58, George Dunlap <George.Dunlap@eu.citrix.com> wrote:
>>> * Persistent grants
>>>    owner: @citrix
>>>    status: ?
>> Isn't that a guest side only thing (i.e. not really to be tracked
>> here)? Or does that mean migrating active grants?
> I'd assume that the device would be renegotiated during migration, and
> that new grants would be established during the re-connect sequence.
>
> One question I have is how persistent grants intersect with
> blktap3. Will a persistent grant-capable blktap3 implementation be in
> scope for 4.3?
Thanos is working on blktap3 -- Thanos, can you comment?
>
>>> * Multi-page blk rings
>>>   - blkback in kernel (konrad@oracle, ?@intel)
>> This part certainly is a guest side only thing (apart from the
>> interface definition living in the our tree).
> Same question here regarding blktap3.
And here.

  -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 26 09:41:31 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Sep 2012 09:41:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGo7B-0007ip-0k; Wed, 26 Sep 2012 09:41:09 +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 1TGo78-0007ik-UK
	for xen-devel@lists.xen.org; Wed, 26 Sep 2012 09:41:07 +0000
Received: from [85.158.137.99:60656] by server-2.bemta-3.messagelabs.com id
	D1/B3-16514-2BDC2605; Wed, 26 Sep 2012 09:41:06 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-2.tower-217.messagelabs.com!1348652463!19055213!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNzc0NzM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21191 invoked from network); 26 Sep 2012 09:41:05 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-2.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Sep 2012 09:41:05 -0000
X-IronPort-AV: E=Sophos;i="4.80,489,1344211200"; d="scan'208";a="209380139"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Sep 2012 09:41:03 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 26 Sep 2012 05:41:03 -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 1TGo74-0000hx-V2;
	Wed, 26 Sep 2012 10:41:02 +0100
Message-ID: <5062CCA5.8010903@eu.citrix.com>
Date: Wed, 26 Sep 2012 10:36:37 +0100
From: George Dunlap <george.dunlap@eu.citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120827 Thunderbird/15.0
MIME-Version: 1.0
To: Matt Wilson <msw@amazon.com>
References: <CAFLBxZYtmJ_bKFb90r45=C4Pq1-oe5Fy=eygSsQf4BcGj3EqGA@mail.gmail.com>
	<505ADBCF020000780009C7BE@nat28.tlf.novell.com>
	<20120921031759.GA3953@u002268147cd4502c336d.ant.amazon.com>
In-Reply-To: <20120921031759.GA3953@u002268147cd4502c336d.ant.amazon.com>
Cc: Thanos Makatos <thanos.makatos@citrix.com>, Jan Beulich <JBeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.3 development 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-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 21/09/12 04:18, Matt Wilson wrote:
> On Thu, Sep 20, 2012 at 08:03:11AM +0100, Jan Beulich wrote:
>>> On 19.09.12 at 18:58, George Dunlap <George.Dunlap@eu.citrix.com> wrote:
>>> * Persistent grants
>>>    owner: @citrix
>>>    status: ?
>> Isn't that a guest side only thing (i.e. not really to be tracked
>> here)? Or does that mean migrating active grants?
> I'd assume that the device would be renegotiated during migration, and
> that new grants would be established during the re-connect sequence.
>
> One question I have is how persistent grants intersect with
> blktap3. Will a persistent grant-capable blktap3 implementation be in
> scope for 4.3?
Thanos is working on blktap3 -- Thanos, can you comment?
>
>>> * Multi-page blk rings
>>>   - blkback in kernel (konrad@oracle, ?@intel)
>> This part certainly is a guest side only thing (apart from the
>> interface definition living in the our tree).
> Same question here regarding blktap3.
And here.

  -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 26 10:10:21 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Sep 2012 10:10: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 1TGoYz-000876-Qr; Wed, 26 Sep 2012 10:09: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 1TGoYx-000871-W2
	for xen-devel@lists.xen.org; Wed, 26 Sep 2012 10:09:52 +0000
Received: from [85.158.139.211:24626] by server-8.bemta-5.messagelabs.com id
	B8/F1-18073-F64D2605; Wed, 26 Sep 2012 10:09:51 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-16.tower-206.messagelabs.com!1348654190!20043766!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28086 invoked from network); 26 Sep 2012 10:09:50 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-16.tower-206.messagelabs.com with SMTP;
	26 Sep 2012 10:09:50 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 26 Sep 2012 11:09:49 +0100
Message-Id: <5062F0A3020000780009DEF5@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 26 Sep 2012 11:10:11 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Christoph Egger" <Christoph.Egger@amd.com>,
	"Jinsong Liu" <jinsong.liu@intel.com>
References: <DE8DF0795D48FD4CA783C40EC829233533AAC0@SHSMSX101.ccr.corp.intel.com>
In-Reply-To: <DE8DF0795D48FD4CA783C40EC829233533AAC0@SHSMSX101.ccr.corp.intel.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "keir@xen.org" <keir@xen.org>,
	"Ian.Campbell@citrix.com" <Ian.Campbell@citrix.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 2/5] Xen/MCE: vMCE 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 26.09.12 at 05:16, "Liu, Jinsong" <jinsong.liu@intel.com> wrote:
> Xen/MCE: vMCE injection
> 
> for Intel MCE, broadcast vMCE to all vcpus;
> for AMD MCE, only inject vMCE to 1 vcpu, say, vcpu0

Please double check what got committed.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 26 10:10:21 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Sep 2012 10:10: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 1TGoYz-000876-Qr; Wed, 26 Sep 2012 10:09: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 1TGoYx-000871-W2
	for xen-devel@lists.xen.org; Wed, 26 Sep 2012 10:09:52 +0000
Received: from [85.158.139.211:24626] by server-8.bemta-5.messagelabs.com id
	B8/F1-18073-F64D2605; Wed, 26 Sep 2012 10:09:51 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-16.tower-206.messagelabs.com!1348654190!20043766!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28086 invoked from network); 26 Sep 2012 10:09:50 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-16.tower-206.messagelabs.com with SMTP;
	26 Sep 2012 10:09:50 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 26 Sep 2012 11:09:49 +0100
Message-Id: <5062F0A3020000780009DEF5@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 26 Sep 2012 11:10:11 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Christoph Egger" <Christoph.Egger@amd.com>,
	"Jinsong Liu" <jinsong.liu@intel.com>
References: <DE8DF0795D48FD4CA783C40EC829233533AAC0@SHSMSX101.ccr.corp.intel.com>
In-Reply-To: <DE8DF0795D48FD4CA783C40EC829233533AAC0@SHSMSX101.ccr.corp.intel.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "keir@xen.org" <keir@xen.org>,
	"Ian.Campbell@citrix.com" <Ian.Campbell@citrix.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 2/5] Xen/MCE: vMCE 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 26.09.12 at 05:16, "Liu, Jinsong" <jinsong.liu@intel.com> wrote:
> Xen/MCE: vMCE injection
> 
> for Intel MCE, broadcast vMCE to all vcpus;
> for AMD MCE, only inject vMCE to 1 vcpu, say, vcpu0

Please double check what got committed.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 26 10:26:45 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Sep 2012 10:26: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 1TGoow-0008Jx-JH; Wed, 26 Sep 2012 10:26:22 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <thanos.makatos@citrix.com>) id 1TGoou-0008Jp-By
	for xen-devel@lists.xen.org; Wed, 26 Sep 2012 10:26:20 +0000
Received: from [85.158.138.51:35555] by server-15.bemta-3.messagelabs.com id
	7E/43-18313-B48D2605; Wed, 26 Sep 2012 10:26:19 +0000
X-Env-Sender: thanos.makatos@citrix.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1348655178!24094864!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTE1NzQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21852 invoked from network); 26 Sep 2012 10:26:19 -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 Sep 2012 10:26:19 -0000
X-IronPort-AV: E=Sophos;i="4.80,489,1344211200"; d="scan'208";a="14772716"
Received: from lonpmailmx02.citrite.net ([10.30.203.163])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Sep 2012 10:25:55 +0000
Received: from LONPMAILBOX01.citrite.net ([10.30.224.160]) by
	LONPMAILMX02.citrite.net ([10.30.203.163]) with mapi; Wed, 26 Sep 2012
	11:25:55 +0100
From: Thanos Makatos <thanos.makatos@citrix.com>
To: George Dunlap <George.Dunlap@eu.citrix.com>, Matt Wilson <msw@amazon.com>
Date: Wed, 26 Sep 2012 11:25:54 +0100
Thread-Topic: [Xen-devel] Xen 4.3 development update
Thread-Index: Ac2bywxWUAmqzghzT/mrdjHxXD+ulwABN1Eg
Message-ID: <4B45B535F7F6BE4CB1C044ED5115CDDE011A6DD0105E@LONPMAILBOX01.citrite.net>
References: <CAFLBxZYtmJ_bKFb90r45=C4Pq1-oe5Fy=eygSsQf4BcGj3EqGA@mail.gmail.com>
	<505ADBCF020000780009C7BE@nat28.tlf.novell.com>
	<20120921031759.GA3953@u002268147cd4502c336d.ant.amazon.com>
	<5062CCA5.8010903@eu.citrix.com>
In-Reply-To: <5062CCA5.8010903@eu.citrix.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Cc: Jan Beulich <JBeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.3 development 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



> -----Original Message-----
> From: George Dunlap [mailto:george.dunlap@eu.citrix.com]
> Sent: 26 September 2012 10:37
> To: Matt Wilson
> Cc: Jan Beulich; xen-devel@lists.xen.org; Thanos Makatos
> Subject: Re: [Xen-devel] Xen 4.3 development update
> 
> On 21/09/12 04:18, Matt Wilson wrote:
> > On Thu, Sep 20, 2012 at 08:03:11AM +0100, Jan Beulich wrote:
> >>> On 19.09.12 at 18:58, George Dunlap <George.Dunlap@eu.citrix.com>
> wrote:
> >>> * Persistent grants
> >>>    owner: @citrix
> >>>    status: ?
> >> Isn't that a guest side only thing (i.e. not really to be tracked
> >> here)? Or does that mean migrating active grants?
> > I'd assume that the device would be renegotiated during migration,
> and
> > that new grants would be established during the re-connect sequence.
> >
> > One question I have is how persistent grants intersect with blktap3.
> > Will a persistent grant-capable blktap3 implementation be in scope
> for
> > 4.3?
> Thanos is working on blktap3 -- Thanos, can you comment?

Supporting this in 4.3 is not top priority; however I'll do it if I have time.

> >
> >>> * Multi-page blk rings
> >>>   - blkback in kernel (konrad@oracle, ?@intel)
> >> This part certainly is a guest side only thing (apart from the
> >> interface definition living in the our tree).
> > Same question here regarding blktap3.
> And here.

I'm not sure I understand the question, blktap3 doesn't talk to blkback at all, but to blkfront directly -- are you referring to blkfront?

> 
>   -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 26 10:26:45 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Sep 2012 10:26: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 1TGoow-0008Jx-JH; Wed, 26 Sep 2012 10:26:22 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <thanos.makatos@citrix.com>) id 1TGoou-0008Jp-By
	for xen-devel@lists.xen.org; Wed, 26 Sep 2012 10:26:20 +0000
Received: from [85.158.138.51:35555] by server-15.bemta-3.messagelabs.com id
	7E/43-18313-B48D2605; Wed, 26 Sep 2012 10:26:19 +0000
X-Env-Sender: thanos.makatos@citrix.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1348655178!24094864!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTE1NzQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21852 invoked from network); 26 Sep 2012 10:26:19 -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 Sep 2012 10:26:19 -0000
X-IronPort-AV: E=Sophos;i="4.80,489,1344211200"; d="scan'208";a="14772716"
Received: from lonpmailmx02.citrite.net ([10.30.203.163])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Sep 2012 10:25:55 +0000
Received: from LONPMAILBOX01.citrite.net ([10.30.224.160]) by
	LONPMAILMX02.citrite.net ([10.30.203.163]) with mapi; Wed, 26 Sep 2012
	11:25:55 +0100
From: Thanos Makatos <thanos.makatos@citrix.com>
To: George Dunlap <George.Dunlap@eu.citrix.com>, Matt Wilson <msw@amazon.com>
Date: Wed, 26 Sep 2012 11:25:54 +0100
Thread-Topic: [Xen-devel] Xen 4.3 development update
Thread-Index: Ac2bywxWUAmqzghzT/mrdjHxXD+ulwABN1Eg
Message-ID: <4B45B535F7F6BE4CB1C044ED5115CDDE011A6DD0105E@LONPMAILBOX01.citrite.net>
References: <CAFLBxZYtmJ_bKFb90r45=C4Pq1-oe5Fy=eygSsQf4BcGj3EqGA@mail.gmail.com>
	<505ADBCF020000780009C7BE@nat28.tlf.novell.com>
	<20120921031759.GA3953@u002268147cd4502c336d.ant.amazon.com>
	<5062CCA5.8010903@eu.citrix.com>
In-Reply-To: <5062CCA5.8010903@eu.citrix.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Cc: Jan Beulich <JBeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.3 development 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



> -----Original Message-----
> From: George Dunlap [mailto:george.dunlap@eu.citrix.com]
> Sent: 26 September 2012 10:37
> To: Matt Wilson
> Cc: Jan Beulich; xen-devel@lists.xen.org; Thanos Makatos
> Subject: Re: [Xen-devel] Xen 4.3 development update
> 
> On 21/09/12 04:18, Matt Wilson wrote:
> > On Thu, Sep 20, 2012 at 08:03:11AM +0100, Jan Beulich wrote:
> >>> On 19.09.12 at 18:58, George Dunlap <George.Dunlap@eu.citrix.com>
> wrote:
> >>> * Persistent grants
> >>>    owner: @citrix
> >>>    status: ?
> >> Isn't that a guest side only thing (i.e. not really to be tracked
> >> here)? Or does that mean migrating active grants?
> > I'd assume that the device would be renegotiated during migration,
> and
> > that new grants would be established during the re-connect sequence.
> >
> > One question I have is how persistent grants intersect with blktap3.
> > Will a persistent grant-capable blktap3 implementation be in scope
> for
> > 4.3?
> Thanos is working on blktap3 -- Thanos, can you comment?

Supporting this in 4.3 is not top priority; however I'll do it if I have time.

> >
> >>> * Multi-page blk rings
> >>>   - blkback in kernel (konrad@oracle, ?@intel)
> >> This part certainly is a guest side only thing (apart from the
> >> interface definition living in the our tree).
> > Same question here regarding blktap3.
> And here.

I'm not sure I understand the question, blktap3 doesn't talk to blkback at all, but to blkfront directly -- are you referring to blkfront?

> 
>   -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 26 10:43:51 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Sep 2012 10:43: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 1TGp5V-00005C-6N; Wed, 26 Sep 2012 10:43:29 +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 1TGp5T-000056-SO
	for xen-devel@lists.xen.org; Wed, 26 Sep 2012 10:43:28 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1348656201!6330392!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25686 invoked from network); 26 Sep 2012 10:43:21 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-5.tower-27.messagelabs.com with SMTP;
	26 Sep 2012 10:43:21 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 26 Sep 2012 11:43:21 +0100
Message-Id: <5062F880020000780009DF3B@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 26 Sep 2012 11:43:44 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ben Guthro" <ben@guthro.net>
References: <CAOvdn6UCF2A3yP1cqWn=dxwr0ayRbr+rg+xj8META9Dm0+CoNw@mail.gmail.com>
	<CC868168.3FD29%keir.xen@gmail.com>
	<CAOvdn6U-JyLvt96gkLkqzi088tU9_ktv4D+fkJac_BKVe05Y-w@mail.gmail.com>
	<CAOvdn6V+s3AbRzsu8VArbmrZou=im9SqvPf-9Wpif_BrNMv=yg@mail.gmail.com>
	<50617297020000780009D8AA@nat28.tlf.novell.com>
	<CAOvdn6Vsnbcd7m8mh3tSgn3KaEoeiOyVD1mr3uQ3bN=rF=pDUQ@mail.gmail.com>
In-Reply-To: <CAOvdn6Vsnbcd7m8mh3tSgn3KaEoeiOyVD1mr3uQ3bN=rF=pDUQ@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Keir Fraser <keir.xen@gmail.com>, John Baboval <john.baboval@citrix.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen4.2 S3 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 25.09.12 at 13:56, Ben Guthro <ben@guthro.net> wrote:
> (XEN) Finishing wakeup from ACPI S3 state.
> (XEN) Enabling non-boot CPUs  ...
> (XEN) Booting processor 1/1 eip 8a000
> (XEN) Initializing CPU#1
> (XEN) CPU: L1 I cache: 32K, L1 D cache: 32K
> (XEN) CPU: L2 cache: 3072K
> (XEN) CPU: Physical Processor ID: 0
> (XEN) CPU: Processor Core ID: 1
> (XEN) CMCI: CPU1 has no CMCI support
> (XEN) CPU1: Thermal monitoring enabled (TM2)
> (XEN) CPU1: Intel(R) Core(TM)2 Duo CPU     P8400  @ 2.26GHz stepping 06
> (XEN) microcode: CPU1 updated from revision 0x60c to 0x60f, date = 2010-09-29

Btw., I'm also puzzled by only seeing a ucode update message
here for CPU1 - I just went through the logic again and can't see
why this would not also be done for CPU0. Could you make the
pr_debug() in microcode_intel.c actually print something, so we
can see whether at least collect_cpu_info() would get called
for it, hopefully allowing to deduce what happens subsequently?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 26 10:43:51 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Sep 2012 10:43: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 1TGp5V-00005C-6N; Wed, 26 Sep 2012 10:43:29 +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 1TGp5T-000056-SO
	for xen-devel@lists.xen.org; Wed, 26 Sep 2012 10:43:28 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1348656201!6330392!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25686 invoked from network); 26 Sep 2012 10:43:21 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-5.tower-27.messagelabs.com with SMTP;
	26 Sep 2012 10:43:21 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 26 Sep 2012 11:43:21 +0100
Message-Id: <5062F880020000780009DF3B@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 26 Sep 2012 11:43:44 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ben Guthro" <ben@guthro.net>
References: <CAOvdn6UCF2A3yP1cqWn=dxwr0ayRbr+rg+xj8META9Dm0+CoNw@mail.gmail.com>
	<CC868168.3FD29%keir.xen@gmail.com>
	<CAOvdn6U-JyLvt96gkLkqzi088tU9_ktv4D+fkJac_BKVe05Y-w@mail.gmail.com>
	<CAOvdn6V+s3AbRzsu8VArbmrZou=im9SqvPf-9Wpif_BrNMv=yg@mail.gmail.com>
	<50617297020000780009D8AA@nat28.tlf.novell.com>
	<CAOvdn6Vsnbcd7m8mh3tSgn3KaEoeiOyVD1mr3uQ3bN=rF=pDUQ@mail.gmail.com>
In-Reply-To: <CAOvdn6Vsnbcd7m8mh3tSgn3KaEoeiOyVD1mr3uQ3bN=rF=pDUQ@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Keir Fraser <keir.xen@gmail.com>, John Baboval <john.baboval@citrix.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen4.2 S3 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 25.09.12 at 13:56, Ben Guthro <ben@guthro.net> wrote:
> (XEN) Finishing wakeup from ACPI S3 state.
> (XEN) Enabling non-boot CPUs  ...
> (XEN) Booting processor 1/1 eip 8a000
> (XEN) Initializing CPU#1
> (XEN) CPU: L1 I cache: 32K, L1 D cache: 32K
> (XEN) CPU: L2 cache: 3072K
> (XEN) CPU: Physical Processor ID: 0
> (XEN) CPU: Processor Core ID: 1
> (XEN) CMCI: CPU1 has no CMCI support
> (XEN) CPU1: Thermal monitoring enabled (TM2)
> (XEN) CPU1: Intel(R) Core(TM)2 Duo CPU     P8400  @ 2.26GHz stepping 06
> (XEN) microcode: CPU1 updated from revision 0x60c to 0x60f, date = 2010-09-29

Btw., I'm also puzzled by only seeing a ucode update message
here for CPU1 - I just went through the logic again and can't see
why this would not also be done for CPU0. Could you make the
pr_debug() in microcode_intel.c actually print something, so we
can see whether at least collect_cpu_info() would get called
for it, hopefully allowing to deduce what happens subsequently?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 26 10:48:44 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Sep 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 1TGpAC-0000Cv-TT; Wed, 26 Sep 2012 10:48:20 +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 1TGpAB-0000Cq-M2
	for xen-devel@lists.xen.org; Wed, 26 Sep 2012 10:48:19 +0000
Received: from [85.158.143.35:27660] by server-2.bemta-4.messagelabs.com id
	4F/C7-06610-27DD2605; Wed, 26 Sep 2012 10:48:18 +0000
X-Env-Sender: ben.guthro@gmail.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1348656447!18538012!1
X-Originating-IP: [209.85.223.173]
X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE,
	RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17277 invoked from network); 26 Sep 2012 10:47:28 -0000
Received: from mail-ie0-f173.google.com (HELO mail-ie0-f173.google.com)
	(209.85.223.173)
	by server-13.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Sep 2012 10:47:28 -0000
Received: by iea17 with SMTP id 17so1295202iea.32
	for <xen-devel@lists.xen.org>; Wed, 26 Sep 2012 03:47:26 -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=GAREdvfYE8izPLlqWwP/Df37W/2ra9piWKNX6760tUg=;
	b=WbyfByfrFVdLlbnN++UZID9Ea518taLVFybXwM8DNb9868OJAQDC7Bhgbg1hLdi3ZD
	85JFcL3lu4+SbfviYZdhtIdW/vUcrkg6cx0tDHacLDuVjackFMHnljpcbOL1LaBg53CX
	0q+35SZNctWzITD+sKAS61kBuDJyvNXYFTRrRY80TG3FAwPAhM9Nbw280GKE7T9/t0JS
	W5dOeg8lMiMaxBALfDdTmeJLOCRhBPdO1fq+rADt6vkQa1l3o7uEHVYyGGMy4h9Nabc0
	mfHlL4PHgqSyjhr3NEGzpsnJf2asuf497h95zLtpEpo8dahwWEFJMsa7sRsW3934mlWq
	xaAQ==
MIME-Version: 1.0
Received: by 10.50.183.200 with SMTP id eo8mr10862103igc.54.1348656446600;
	Wed, 26 Sep 2012 03:47:26 -0700 (PDT)
Received: by 10.64.55.132 with HTTP; Wed, 26 Sep 2012 03:47:26 -0700 (PDT)
In-Reply-To: <5062F880020000780009DF3B@nat28.tlf.novell.com>
References: <CAOvdn6UCF2A3yP1cqWn=dxwr0ayRbr+rg+xj8META9Dm0+CoNw@mail.gmail.com>
	<CC868168.3FD29%keir.xen@gmail.com>
	<CAOvdn6U-JyLvt96gkLkqzi088tU9_ktv4D+fkJac_BKVe05Y-w@mail.gmail.com>
	<CAOvdn6V+s3AbRzsu8VArbmrZou=im9SqvPf-9Wpif_BrNMv=yg@mail.gmail.com>
	<50617297020000780009D8AA@nat28.tlf.novell.com>
	<CAOvdn6Vsnbcd7m8mh3tSgn3KaEoeiOyVD1mr3uQ3bN=rF=pDUQ@mail.gmail.com>
	<5062F880020000780009DF3B@nat28.tlf.novell.com>
Date: Wed, 26 Sep 2012 06:47:26 -0400
X-Google-Sender-Auth: TyJsBJIaovvF4XXpdPoNgkUoTt0
Message-ID: <CAOvdn6W9c-0nTmgE-y3tnLQbBV=__kT6fgNORcEnDF1rAyLHDA@mail.gmail.com>
From: Ben Guthro <ben@guthro.net>
To: Jan Beulich <JBeulich@suse.com>
Cc: Keir Fraser <keir.xen@gmail.com>, John Baboval <john.baboval@citrix.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen4.2 S3 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: multipart/mixed; boundary="===============6884747504413098287=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============6884747504413098287==
Content-Type: multipart/alternative; boundary=14dae93404356c747c04ca988ce4

--14dae93404356c747c04ca988ce4
Content-Type: text/plain; charset=ISO-8859-1

On Wed, Sep 26, 2012 at 6:43 AM, Jan Beulich <JBeulich@suse.com> wrote:

> >>> On 25.09.12 at 13:56, Ben Guthro <ben@guthro.net> wrote:
> > (XEN) Finishing wakeup from ACPI S3 state.
> > (XEN) Enabling non-boot CPUs  ...
> > (XEN) Booting processor 1/1 eip 8a000
> > (XEN) Initializing CPU#1
> > (XEN) CPU: L1 I cache: 32K, L1 D cache: 32K
> > (XEN) CPU: L2 cache: 3072K
> > (XEN) CPU: Physical Processor ID: 0
> > (XEN) CPU: Processor Core ID: 1
> > (XEN) CMCI: CPU1 has no CMCI support
> > (XEN) CPU1: Thermal monitoring enabled (TM2)
> > (XEN) CPU1: Intel(R) Core(TM)2 Duo CPU     P8400  @ 2.26GHz stepping 06
> > (XEN) microcode: CPU1 updated from revision 0x60c to 0x60f, date =
> 2010-09-29
>
> Btw., I'm also puzzled by only seeing a ucode update message
> here for CPU1 - I just went through the logic again and can't see
> why this would not also be done for CPU0. Could you make the
> pr_debug() in microcode_intel.c actually print something, so we
> can see whether at least collect_cpu_info() would get called
> for it, hopefully allowing to deduce what happens subsequently?
>


Happy to do so - but I may not be able to do this test until tomorrow.

Ben

--14dae93404356c747c04ca988ce4
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div class=3D"gmail_quote">On Wed, Sep 26, 2012 at 6:43 AM, Jan Beulich <sp=
an dir=3D"ltr">&lt;<a href=3D"mailto:JBeulich@suse.com" target=3D"_blank">J=
Beulich@suse.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote"=
 style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class=3D"im">&gt;&gt;&gt; On 25.09.12 at 13:56, Ben Guthro &lt;<a href=
=3D"mailto:ben@guthro.net">ben@guthro.net</a>&gt; wrote:<br>
&gt; (XEN) Finishing wakeup from ACPI S3 state.<br>
&gt; (XEN) Enabling non-boot CPUs =A0...<br>
&gt; (XEN) Booting processor 1/1 eip 8a000<br>
&gt; (XEN) Initializing CPU#1<br>
&gt; (XEN) CPU: L1 I cache: 32K, L1 D cache: 32K<br>
&gt; (XEN) CPU: L2 cache: 3072K<br>
&gt; (XEN) CPU: Physical Processor ID: 0<br>
&gt; (XEN) CPU: Processor Core ID: 1<br>
&gt; (XEN) CMCI: CPU1 has no CMCI support<br>
&gt; (XEN) CPU1: Thermal monitoring enabled (TM2)<br>
&gt; (XEN) CPU1: Intel(R) Core(TM)2 Duo CPU =A0 =A0 P8400 =A0@ 2.26GHz step=
ping 06<br>
&gt; (XEN) microcode: CPU1 updated from revision 0x60c to 0x60f, date =3D 2=
010-09-29<br>
<br>
</div>Btw., I&#39;m also puzzled by only seeing a ucode update message<br>
here for CPU1 - I just went through the logic again and can&#39;t see<br>
why this would not also be done for CPU0. Could you make the<br>
pr_debug() in microcode_intel.c actually print something, so we<br>
can see whether at least collect_cpu_info() would get called<br>
for it, hopefully allowing to deduce what happens subsequently?<br></blockq=
uote><div><br></div><div><br></div><div>Happy to do so - but I may not be a=
ble to do this test until tomorrow.</div><div><br></div><div>Ben</div>
<div><br></div></div>

--14dae93404356c747c04ca988ce4--


--===============6884747504413098287==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============6884747504413098287==--


From xen-devel-bounces@lists.xen.org Wed Sep 26 10:48:44 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Sep 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 1TGpAC-0000Cv-TT; Wed, 26 Sep 2012 10:48:20 +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 1TGpAB-0000Cq-M2
	for xen-devel@lists.xen.org; Wed, 26 Sep 2012 10:48:19 +0000
Received: from [85.158.143.35:27660] by server-2.bemta-4.messagelabs.com id
	4F/C7-06610-27DD2605; Wed, 26 Sep 2012 10:48:18 +0000
X-Env-Sender: ben.guthro@gmail.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1348656447!18538012!1
X-Originating-IP: [209.85.223.173]
X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE,
	RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17277 invoked from network); 26 Sep 2012 10:47:28 -0000
Received: from mail-ie0-f173.google.com (HELO mail-ie0-f173.google.com)
	(209.85.223.173)
	by server-13.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Sep 2012 10:47:28 -0000
Received: by iea17 with SMTP id 17so1295202iea.32
	for <xen-devel@lists.xen.org>; Wed, 26 Sep 2012 03:47:26 -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=GAREdvfYE8izPLlqWwP/Df37W/2ra9piWKNX6760tUg=;
	b=WbyfByfrFVdLlbnN++UZID9Ea518taLVFybXwM8DNb9868OJAQDC7Bhgbg1hLdi3ZD
	85JFcL3lu4+SbfviYZdhtIdW/vUcrkg6cx0tDHacLDuVjackFMHnljpcbOL1LaBg53CX
	0q+35SZNctWzITD+sKAS61kBuDJyvNXYFTRrRY80TG3FAwPAhM9Nbw280GKE7T9/t0JS
	W5dOeg8lMiMaxBALfDdTmeJLOCRhBPdO1fq+rADt6vkQa1l3o7uEHVYyGGMy4h9Nabc0
	mfHlL4PHgqSyjhr3NEGzpsnJf2asuf497h95zLtpEpo8dahwWEFJMsa7sRsW3934mlWq
	xaAQ==
MIME-Version: 1.0
Received: by 10.50.183.200 with SMTP id eo8mr10862103igc.54.1348656446600;
	Wed, 26 Sep 2012 03:47:26 -0700 (PDT)
Received: by 10.64.55.132 with HTTP; Wed, 26 Sep 2012 03:47:26 -0700 (PDT)
In-Reply-To: <5062F880020000780009DF3B@nat28.tlf.novell.com>
References: <CAOvdn6UCF2A3yP1cqWn=dxwr0ayRbr+rg+xj8META9Dm0+CoNw@mail.gmail.com>
	<CC868168.3FD29%keir.xen@gmail.com>
	<CAOvdn6U-JyLvt96gkLkqzi088tU9_ktv4D+fkJac_BKVe05Y-w@mail.gmail.com>
	<CAOvdn6V+s3AbRzsu8VArbmrZou=im9SqvPf-9Wpif_BrNMv=yg@mail.gmail.com>
	<50617297020000780009D8AA@nat28.tlf.novell.com>
	<CAOvdn6Vsnbcd7m8mh3tSgn3KaEoeiOyVD1mr3uQ3bN=rF=pDUQ@mail.gmail.com>
	<5062F880020000780009DF3B@nat28.tlf.novell.com>
Date: Wed, 26 Sep 2012 06:47:26 -0400
X-Google-Sender-Auth: TyJsBJIaovvF4XXpdPoNgkUoTt0
Message-ID: <CAOvdn6W9c-0nTmgE-y3tnLQbBV=__kT6fgNORcEnDF1rAyLHDA@mail.gmail.com>
From: Ben Guthro <ben@guthro.net>
To: Jan Beulich <JBeulich@suse.com>
Cc: Keir Fraser <keir.xen@gmail.com>, John Baboval <john.baboval@citrix.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen4.2 S3 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: multipart/mixed; boundary="===============6884747504413098287=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============6884747504413098287==
Content-Type: multipart/alternative; boundary=14dae93404356c747c04ca988ce4

--14dae93404356c747c04ca988ce4
Content-Type: text/plain; charset=ISO-8859-1

On Wed, Sep 26, 2012 at 6:43 AM, Jan Beulich <JBeulich@suse.com> wrote:

> >>> On 25.09.12 at 13:56, Ben Guthro <ben@guthro.net> wrote:
> > (XEN) Finishing wakeup from ACPI S3 state.
> > (XEN) Enabling non-boot CPUs  ...
> > (XEN) Booting processor 1/1 eip 8a000
> > (XEN) Initializing CPU#1
> > (XEN) CPU: L1 I cache: 32K, L1 D cache: 32K
> > (XEN) CPU: L2 cache: 3072K
> > (XEN) CPU: Physical Processor ID: 0
> > (XEN) CPU: Processor Core ID: 1
> > (XEN) CMCI: CPU1 has no CMCI support
> > (XEN) CPU1: Thermal monitoring enabled (TM2)
> > (XEN) CPU1: Intel(R) Core(TM)2 Duo CPU     P8400  @ 2.26GHz stepping 06
> > (XEN) microcode: CPU1 updated from revision 0x60c to 0x60f, date =
> 2010-09-29
>
> Btw., I'm also puzzled by only seeing a ucode update message
> here for CPU1 - I just went through the logic again and can't see
> why this would not also be done for CPU0. Could you make the
> pr_debug() in microcode_intel.c actually print something, so we
> can see whether at least collect_cpu_info() would get called
> for it, hopefully allowing to deduce what happens subsequently?
>


Happy to do so - but I may not be able to do this test until tomorrow.

Ben

--14dae93404356c747c04ca988ce4
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div class=3D"gmail_quote">On Wed, Sep 26, 2012 at 6:43 AM, Jan Beulich <sp=
an dir=3D"ltr">&lt;<a href=3D"mailto:JBeulich@suse.com" target=3D"_blank">J=
Beulich@suse.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote"=
 style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class=3D"im">&gt;&gt;&gt; On 25.09.12 at 13:56, Ben Guthro &lt;<a href=
=3D"mailto:ben@guthro.net">ben@guthro.net</a>&gt; wrote:<br>
&gt; (XEN) Finishing wakeup from ACPI S3 state.<br>
&gt; (XEN) Enabling non-boot CPUs =A0...<br>
&gt; (XEN) Booting processor 1/1 eip 8a000<br>
&gt; (XEN) Initializing CPU#1<br>
&gt; (XEN) CPU: L1 I cache: 32K, L1 D cache: 32K<br>
&gt; (XEN) CPU: L2 cache: 3072K<br>
&gt; (XEN) CPU: Physical Processor ID: 0<br>
&gt; (XEN) CPU: Processor Core ID: 1<br>
&gt; (XEN) CMCI: CPU1 has no CMCI support<br>
&gt; (XEN) CPU1: Thermal monitoring enabled (TM2)<br>
&gt; (XEN) CPU1: Intel(R) Core(TM)2 Duo CPU =A0 =A0 P8400 =A0@ 2.26GHz step=
ping 06<br>
&gt; (XEN) microcode: CPU1 updated from revision 0x60c to 0x60f, date =3D 2=
010-09-29<br>
<br>
</div>Btw., I&#39;m also puzzled by only seeing a ucode update message<br>
here for CPU1 - I just went through the logic again and can&#39;t see<br>
why this would not also be done for CPU0. Could you make the<br>
pr_debug() in microcode_intel.c actually print something, so we<br>
can see whether at least collect_cpu_info() would get called<br>
for it, hopefully allowing to deduce what happens subsequently?<br></blockq=
uote><div><br></div><div><br></div><div>Happy to do so - but I may not be a=
ble to do this test until tomorrow.</div><div><br></div><div>Ben</div>
<div><br></div></div>

--14dae93404356c747c04ca988ce4--


--===============6884747504413098287==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============6884747504413098287==--


From xen-devel-bounces@lists.xen.org Wed Sep 26 10:58:44 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Sep 2012 10:58:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGpJw-0000Nq-VE; Wed, 26 Sep 2012 10:58: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 1TGpJu-0000Nl-TL
	for xen-devel@lists.xen.org; Wed, 26 Sep 2012 10:58:23 +0000
Received: from [85.158.143.35:65326] by server-2.bemta-4.messagelabs.com id
	C0/48-06610-ECFD2605; Wed, 26 Sep 2012 10:58:22 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1348657092!13815417!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTE1NzQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1204 invoked from network); 26 Sep 2012 10:58:13 -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;
	26 Sep 2012 10:58:13 -0000
X-IronPort-AV: E=Sophos;i="4.80,490,1344211200"; d="scan'208";a="14773640"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Sep 2012 10:58: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.279.1; Wed, 26 Sep 2012 11:58:03 +0100
Date: Wed, 26 Sep 2012 11:57:10 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: "Hao, Xudong" <xudong.hao@intel.com>
In-Reply-To: <403610A45A2B5242BD291EDAE8B37D300FEC73C5@SHSMSX102.ccr.corp.intel.com>
Message-ID: <alpine.DEB.2.02.1209261153210.29232@kaball.uk.xensource.com>
References: <1348544326-31334-1-git-send-email-xudong.hao@intel.com>
	<alpine.DEB.2.02.1209251134460.29232@kaball.uk.xensource.com>
	<403610A45A2B5242BD291EDAE8B37D300FEC73C5@SHSMSX102.ccr.corp.intel.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>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>, "Zhang,
	Xiantao" <xiantao.zhang@intel.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v2] qemu/xen: Add 64 bits big bar support on
	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 Wed, 26 Sep 2012, Hao, Xudong wrote:
> > -----Original Message-----
> > From: Stefano Stabellini [mailto:stefano.stabellini@eu.citrix.com]
> > Sent: Tuesday, September 25, 2012 6:52 PM
> > To: Hao, Xudong
> > Cc: Stefano Stabellini; xen-devel@lists.xen.org; qemu-devel@nongnu.org;
> > Zhang, Xiantao
> > Subject: Re: [PATCH v2] qemu/xen: Add 64 bits big bar support on qemu
> > 
> > On Tue, 25 Sep 2012, Xudong Hao wrote:
> > > Changes from v1:
> > > - Rebase to qemu upstream from qemu-xen
> > 
> > Thanks. Please run scripts/checkpatch.pl on this patch, you'll find
> > some cody style issues that need to be fixed.
> > 
> OK, will use this scripts to check code style.
> 
> > 
> > > Currently it is assumed PCI device BAR access < 4G memory. If there is such a
> > > device whose BAR size is larger than 4G, it must access > 4G memory
> > address.
> > > This patch enable the 64bits big BAR support on qemu.
> > >
> > > Signed-off-by: Xudong Hao <xudong.hao@intel.com>
> > > Signed-off-by: Xiantao Zhang <xiantao.zhang@intel.com>
> > > ---
> > >  hw/xen_pt.c             |   16 ++++++++--------
> > >  hw/xen_pt_config_init.c |   42
> > +++++++++++++++++++++++++++++-------------
> > >
> > > diff --git a/hw/xen_pt.c b/hw/xen_pt.c
> > > index 307119a..2a8bcf3 100644
> > > --- a/hw/xen_pt.c
> > > +++ b/hw/xen_pt.c
> > > @@ -403,21 +403,21 @@ static int
> > xen_pt_register_regions(XenPCIPassthroughState *s)
> > >
> > >          s->bases[i].access.u = r->base_addr;
> > >
> > > -        if (r->type & XEN_HOST_PCI_REGION_TYPE_IO) {
> > > +        if (r->type & XEN_HOST_PCI_REGION_TYPE_IO)
> > >              type = PCI_BASE_ADDRESS_SPACE_IO;
> > > -        } else {
> > > +        else if (r->type & XEN_HOST_PCI_REGION_TYPE_MEM_64)
> > > +            type = PCI_BASE_ADDRESS_MEM_TYPE_64;
> > > +        else if (r->type & XEN_HOST_PCI_REGION_TYPE_PREFETCH)
> > > +            type |= PCI_BASE_ADDRESS_MEM_PREFETCH;
> > > +        else
> > >              type = PCI_BASE_ADDRESS_SPACE_MEMORY;
> > > -            if (r->type & XEN_HOST_PCI_REGION_TYPE_PREFETCH) {
> > > -                type |= PCI_BASE_ADDRESS_MEM_PREFETCH;
> > > -            }
> > > -        }
> > 
> > Aside from the cody style issue here, this changes the behavior for type
> > PCI_BASE_ADDRESS_SPACE_MEMORY. Before we could have:
> > 
> > type =
> > PCI_BASE_ADDRESS_SPACE_MEMORY|PCI_BASE_ADDRESS_MEM_PREFETCH;
> > 
> > now we cannot anymore.
> > 
> 
> Will change to:
> -        if (r->type & XEN_HOST_PCI_REGION_TYPE_IO) {
> +        if (r->type & XEN_HOST_PCI_REGION_TYPE_IO)
>              type = PCI_BASE_ADDRESS_SPACE_IO;
> -        } else {
> +        else
>              type = PCI_BASE_ADDRESS_SPACE_MEMORY;
> -            if (r->type & XEN_HOST_PCI_REGION_TYPE_PREFETCH) {
> +            if (r->type & XEN_HOST_PCI_REGION_TYPE_MEM_64)
> +                type |= PCI_BASE_ADDRESS_MEM_TYPE_64;
> +           else if (r->type & XEN_HOST_PCI_REGION_TYPE_PREFETCH)
>                  type |= PCI_BASE_ADDRESS_MEM_PREFETCH;
> -            }
> -        }

Isn't it possible that both XEN_HOST_PCI_REGION_TYPE_MEM_64 and
XEN_HOST_PCI_REGION_TYPE_PREFETCH are set? It doesn't look like this can
cover that case.
The following seems to be what you are looking for:


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;
    }
    if (r->type & XEN_HOST_PCI_REGION_TYPE_MEM_64) {
        type |= PCI_BASE_ADDRESS_MEM_TYPE_64;
    }
}


> > >  static XenPTBarFlag xen_pt_bar_reg_parse(XenPCIPassthroughState *s,
> > >                                           XenPTRegInfo *reg)
> > >  {
> > > @@ -366,7 +367,7 @@ static XenPTBarFlag
> > xen_pt_bar_reg_parse(XenPCIPassthroughState *s,
> > >
> > >      /* check unused BAR */
> > >      r = &d->io_regions[index];
> > > -    if (r->size == 0) {
> > > +    if (!xen_pt_get_bar_size(r)) {
> > >          return XEN_PT_BAR_FLAG_UNUSED;
> > >      }
> > >
> > > @@ -383,6 +384,24 @@ static XenPTBarFlag
> > xen_pt_bar_reg_parse(XenPCIPassthroughState *s,
> > >      }
> > >  }
> > >
> > > +static bool is_64bit_bar(PCIIORegion *r)
> > > +{
> > > +    return !!(r->type & PCI_BASE_ADDRESS_MEM_TYPE_64);
> > > +}
> > > +
> > > +static uint64_t xen_pt_get_bar_size(PCIIORegion *r)
> > > +{
> > > +    if (is_64bit_bar(r))
> > > +    {
> > > +        uint64_t size64;
> > > +        size64 = (r + 1)->size;
> > > +        size64 <<= 32;
> > > +        size64 += r->size;
> > > +        return size64;
> > > +    }
> > > +    return r->size;
> > > +}
> > > +
> > >  static inline uint32_t base_address_with_flags(XenHostPCIIORegion *hr)
> > >  {
> > >      if (hr->type & XEN_HOST_PCI_REGION_TYPE_IO) {
> > > @@ -481,7 +500,10 @@ static int
> > xen_pt_bar_reg_write(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
> > >      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);
> > > +        if (!r_size)
> > > +            bar_ro_mask = XEN_PT_BAR_ALLF;
> > > +        else
> > > +            bar_ro_mask = XEN_PT_BAR_MEM_RO_MASK | (r_size - 1);
> > >          break;
> > 
> > Is this an actual mistake everywhere?
> 
> It's low 32bit mask for 64 bit bars.

I see. It is a good idea to add a line of comment in the code saying
that.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 26 10:58:44 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Sep 2012 10:58:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGpJw-0000Nq-VE; Wed, 26 Sep 2012 10:58: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 1TGpJu-0000Nl-TL
	for xen-devel@lists.xen.org; Wed, 26 Sep 2012 10:58:23 +0000
Received: from [85.158.143.35:65326] by server-2.bemta-4.messagelabs.com id
	C0/48-06610-ECFD2605; Wed, 26 Sep 2012 10:58:22 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1348657092!13815417!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTE1NzQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1204 invoked from network); 26 Sep 2012 10:58:13 -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;
	26 Sep 2012 10:58:13 -0000
X-IronPort-AV: E=Sophos;i="4.80,490,1344211200"; d="scan'208";a="14773640"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Sep 2012 10:58: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.279.1; Wed, 26 Sep 2012 11:58:03 +0100
Date: Wed, 26 Sep 2012 11:57:10 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: "Hao, Xudong" <xudong.hao@intel.com>
In-Reply-To: <403610A45A2B5242BD291EDAE8B37D300FEC73C5@SHSMSX102.ccr.corp.intel.com>
Message-ID: <alpine.DEB.2.02.1209261153210.29232@kaball.uk.xensource.com>
References: <1348544326-31334-1-git-send-email-xudong.hao@intel.com>
	<alpine.DEB.2.02.1209251134460.29232@kaball.uk.xensource.com>
	<403610A45A2B5242BD291EDAE8B37D300FEC73C5@SHSMSX102.ccr.corp.intel.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>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>, "Zhang,
	Xiantao" <xiantao.zhang@intel.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v2] qemu/xen: Add 64 bits big bar support on
	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 Wed, 26 Sep 2012, Hao, Xudong wrote:
> > -----Original Message-----
> > From: Stefano Stabellini [mailto:stefano.stabellini@eu.citrix.com]
> > Sent: Tuesday, September 25, 2012 6:52 PM
> > To: Hao, Xudong
> > Cc: Stefano Stabellini; xen-devel@lists.xen.org; qemu-devel@nongnu.org;
> > Zhang, Xiantao
> > Subject: Re: [PATCH v2] qemu/xen: Add 64 bits big bar support on qemu
> > 
> > On Tue, 25 Sep 2012, Xudong Hao wrote:
> > > Changes from v1:
> > > - Rebase to qemu upstream from qemu-xen
> > 
> > Thanks. Please run scripts/checkpatch.pl on this patch, you'll find
> > some cody style issues that need to be fixed.
> > 
> OK, will use this scripts to check code style.
> 
> > 
> > > Currently it is assumed PCI device BAR access < 4G memory. If there is such a
> > > device whose BAR size is larger than 4G, it must access > 4G memory
> > address.
> > > This patch enable the 64bits big BAR support on qemu.
> > >
> > > Signed-off-by: Xudong Hao <xudong.hao@intel.com>
> > > Signed-off-by: Xiantao Zhang <xiantao.zhang@intel.com>
> > > ---
> > >  hw/xen_pt.c             |   16 ++++++++--------
> > >  hw/xen_pt_config_init.c |   42
> > +++++++++++++++++++++++++++++-------------
> > >
> > > diff --git a/hw/xen_pt.c b/hw/xen_pt.c
> > > index 307119a..2a8bcf3 100644
> > > --- a/hw/xen_pt.c
> > > +++ b/hw/xen_pt.c
> > > @@ -403,21 +403,21 @@ static int
> > xen_pt_register_regions(XenPCIPassthroughState *s)
> > >
> > >          s->bases[i].access.u = r->base_addr;
> > >
> > > -        if (r->type & XEN_HOST_PCI_REGION_TYPE_IO) {
> > > +        if (r->type & XEN_HOST_PCI_REGION_TYPE_IO)
> > >              type = PCI_BASE_ADDRESS_SPACE_IO;
> > > -        } else {
> > > +        else if (r->type & XEN_HOST_PCI_REGION_TYPE_MEM_64)
> > > +            type = PCI_BASE_ADDRESS_MEM_TYPE_64;
> > > +        else if (r->type & XEN_HOST_PCI_REGION_TYPE_PREFETCH)
> > > +            type |= PCI_BASE_ADDRESS_MEM_PREFETCH;
> > > +        else
> > >              type = PCI_BASE_ADDRESS_SPACE_MEMORY;
> > > -            if (r->type & XEN_HOST_PCI_REGION_TYPE_PREFETCH) {
> > > -                type |= PCI_BASE_ADDRESS_MEM_PREFETCH;
> > > -            }
> > > -        }
> > 
> > Aside from the cody style issue here, this changes the behavior for type
> > PCI_BASE_ADDRESS_SPACE_MEMORY. Before we could have:
> > 
> > type =
> > PCI_BASE_ADDRESS_SPACE_MEMORY|PCI_BASE_ADDRESS_MEM_PREFETCH;
> > 
> > now we cannot anymore.
> > 
> 
> Will change to:
> -        if (r->type & XEN_HOST_PCI_REGION_TYPE_IO) {
> +        if (r->type & XEN_HOST_PCI_REGION_TYPE_IO)
>              type = PCI_BASE_ADDRESS_SPACE_IO;
> -        } else {
> +        else
>              type = PCI_BASE_ADDRESS_SPACE_MEMORY;
> -            if (r->type & XEN_HOST_PCI_REGION_TYPE_PREFETCH) {
> +            if (r->type & XEN_HOST_PCI_REGION_TYPE_MEM_64)
> +                type |= PCI_BASE_ADDRESS_MEM_TYPE_64;
> +           else if (r->type & XEN_HOST_PCI_REGION_TYPE_PREFETCH)
>                  type |= PCI_BASE_ADDRESS_MEM_PREFETCH;
> -            }
> -        }

Isn't it possible that both XEN_HOST_PCI_REGION_TYPE_MEM_64 and
XEN_HOST_PCI_REGION_TYPE_PREFETCH are set? It doesn't look like this can
cover that case.
The following seems to be what you are looking for:


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;
    }
    if (r->type & XEN_HOST_PCI_REGION_TYPE_MEM_64) {
        type |= PCI_BASE_ADDRESS_MEM_TYPE_64;
    }
}


> > >  static XenPTBarFlag xen_pt_bar_reg_parse(XenPCIPassthroughState *s,
> > >                                           XenPTRegInfo *reg)
> > >  {
> > > @@ -366,7 +367,7 @@ static XenPTBarFlag
> > xen_pt_bar_reg_parse(XenPCIPassthroughState *s,
> > >
> > >      /* check unused BAR */
> > >      r = &d->io_regions[index];
> > > -    if (r->size == 0) {
> > > +    if (!xen_pt_get_bar_size(r)) {
> > >          return XEN_PT_BAR_FLAG_UNUSED;
> > >      }
> > >
> > > @@ -383,6 +384,24 @@ static XenPTBarFlag
> > xen_pt_bar_reg_parse(XenPCIPassthroughState *s,
> > >      }
> > >  }
> > >
> > > +static bool is_64bit_bar(PCIIORegion *r)
> > > +{
> > > +    return !!(r->type & PCI_BASE_ADDRESS_MEM_TYPE_64);
> > > +}
> > > +
> > > +static uint64_t xen_pt_get_bar_size(PCIIORegion *r)
> > > +{
> > > +    if (is_64bit_bar(r))
> > > +    {
> > > +        uint64_t size64;
> > > +        size64 = (r + 1)->size;
> > > +        size64 <<= 32;
> > > +        size64 += r->size;
> > > +        return size64;
> > > +    }
> > > +    return r->size;
> > > +}
> > > +
> > >  static inline uint32_t base_address_with_flags(XenHostPCIIORegion *hr)
> > >  {
> > >      if (hr->type & XEN_HOST_PCI_REGION_TYPE_IO) {
> > > @@ -481,7 +500,10 @@ static int
> > xen_pt_bar_reg_write(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
> > >      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);
> > > +        if (!r_size)
> > > +            bar_ro_mask = XEN_PT_BAR_ALLF;
> > > +        else
> > > +            bar_ro_mask = XEN_PT_BAR_MEM_RO_MASK | (r_size - 1);
> > >          break;
> > 
> > Is this an actual mistake everywhere?
> 
> It's low 32bit mask for 64 bit bars.

I see. It is a good idea to add a line of comment in the code saying
that.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 26 11:10:42 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Sep 2012 11:10:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGpVT-0000cP-CM; Wed, 26 Sep 2012 11:10:19 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dunlapg@gmail.com>) id 1TGpVS-0000cK-1Y
	for Xen-devel@lists.xensource.com; Wed, 26 Sep 2012 11:10:18 +0000
Received: from [85.158.143.99:30149] by server-1.bemta-4.messagelabs.com id
	CB/D3-05684-992E2605; Wed, 26 Sep 2012 11:10:17 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1348657812!24826088!1
X-Originating-IP: [209.85.215.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3521 invoked from network); 26 Sep 2012 11:10:15 -0000
Received: from mail-ey0-f171.google.com (HELO mail-ey0-f171.google.com)
	(209.85.215.171)
	by server-6.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Sep 2012 11:10:15 -0000
Received: by eaah11 with SMTP id h11so180789eaa.30
	for <Xen-devel@lists.xensource.com>;
	Wed, 26 Sep 2012 04:10:12 -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=LqMGKja4qea2zGpQwCwoiXLpB54ByFhN7tD+eu8+Vig=;
	b=Db1GiXxmLOceKQJmbfDy2MjzZX++Jrj+48DKNd/N3lCXO79/MTWr5zjtAI2oNPNNpf
	rlQYm+2TczFOLugCJqIIn97jag/tsB9m49NMNL/rf9V6OSjNddBQgB5WukBVjoxK+qum
	peIoRd6zkKlNhbUli7fZun/rko4SHdxHGNW0jG/qtcDGVkXz/gK6HK9Tx6ltKh3gP0MJ
	fMKxu1+3+UpvFr60lwMWyh4AgvsBX0x4Rg/dROEUrw1rhexAEzYHJiF/PTfteVEPUNIe
	FNbDAj/+hNVIYTs2zAkpg2Up+8XbfUcSDL/jg+MF2ctFzn4nRhs4WUxeuNg2dT40jA7M
	4ddA==
MIME-Version: 1.0
Received: by 10.14.180.68 with SMTP id i44mr277421eem.20.1348657812192; Wed,
	26 Sep 2012 04:10:12 -0700 (PDT)
Received: by 10.14.215.195 with HTTP; Wed, 26 Sep 2012 04:10:12 -0700 (PDT)
In-Reply-To: <20120925172705.369e1483@mantra.us.oracle.com>
References: <20120921121556.1a0ea8af@mantra.us.oracle.com>
	<alpine.DEB.2.02.1209241228460.29232@kaball.uk.xensource.com>
	<1348488991.3452.69.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.02.1209241321240.29232@kaball.uk.xensource.com>
	<20120925172705.369e1483@mantra.us.oracle.com>
Date: Wed, 26 Sep 2012 12:10:12 +0100
X-Google-Sender-Auth: pJdLOsql4XlMKx7kVGQdnoev_CU
Message-ID: <CAFLBxZZvf=XmCXKGjFnSgzd3dUOH4X3X8v=cY6GCc3_7XauwKw@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: Mukesh Rathor <mukesh.rathor@oracle.com>
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] [PATCH v1 2/8]: PVH mmu changes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Sep 26, 2012 at 1:27 AM, Mukesh Rathor <mukesh.rathor@oracle.com> wrote:
>> > I'm not convinced that a guest level TLB flush is either necessary
>> > or sufficient here. What we are doing is removing entries from the
>> > P2M which means that we need to do the appropriate HAP flush in the
>> > hypervisor, which must necessarily invalidate any stage 1 mappings
>> > which this flush might also touch (i.e. the HAP flush must be a
>> > super set of this flush).
>> >
>> > Without the HAP flush in the hypervisor you risk guests being able
>> > to see old p2m mappings via the TLB entries which is a security
>> > issue AFAICT.
>>
>> Yes, you are right, we need a flush in the hypervisor to flush the
>> EPT. It could probably live in the implementation of
>> XENMEM_add_to_physmap.
>>
>> This one should be just for the vma mappings, so in the case of
>> xen_unmap_domain_mfn_range is unnecessary (given that it is
>> not removing the vma mappings).
>
>
> My head spins looking at INVEPT and INVVPID docs, but doesn't it already
> happen in ept_set_entry():
>
>     if ( needs_sync )
>         ept_sync_domain(p2m->domain);

Yes, the point of having a clean p2m interface is that you shouldn't
need to figure out when to do hap flushes.

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 26 11:10:42 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Sep 2012 11:10:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGpVT-0000cP-CM; Wed, 26 Sep 2012 11:10:19 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dunlapg@gmail.com>) id 1TGpVS-0000cK-1Y
	for Xen-devel@lists.xensource.com; Wed, 26 Sep 2012 11:10:18 +0000
Received: from [85.158.143.99:30149] by server-1.bemta-4.messagelabs.com id
	CB/D3-05684-992E2605; Wed, 26 Sep 2012 11:10:17 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1348657812!24826088!1
X-Originating-IP: [209.85.215.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3521 invoked from network); 26 Sep 2012 11:10:15 -0000
Received: from mail-ey0-f171.google.com (HELO mail-ey0-f171.google.com)
	(209.85.215.171)
	by server-6.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Sep 2012 11:10:15 -0000
Received: by eaah11 with SMTP id h11so180789eaa.30
	for <Xen-devel@lists.xensource.com>;
	Wed, 26 Sep 2012 04:10:12 -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=LqMGKja4qea2zGpQwCwoiXLpB54ByFhN7tD+eu8+Vig=;
	b=Db1GiXxmLOceKQJmbfDy2MjzZX++Jrj+48DKNd/N3lCXO79/MTWr5zjtAI2oNPNNpf
	rlQYm+2TczFOLugCJqIIn97jag/tsB9m49NMNL/rf9V6OSjNddBQgB5WukBVjoxK+qum
	peIoRd6zkKlNhbUli7fZun/rko4SHdxHGNW0jG/qtcDGVkXz/gK6HK9Tx6ltKh3gP0MJ
	fMKxu1+3+UpvFr60lwMWyh4AgvsBX0x4Rg/dROEUrw1rhexAEzYHJiF/PTfteVEPUNIe
	FNbDAj/+hNVIYTs2zAkpg2Up+8XbfUcSDL/jg+MF2ctFzn4nRhs4WUxeuNg2dT40jA7M
	4ddA==
MIME-Version: 1.0
Received: by 10.14.180.68 with SMTP id i44mr277421eem.20.1348657812192; Wed,
	26 Sep 2012 04:10:12 -0700 (PDT)
Received: by 10.14.215.195 with HTTP; Wed, 26 Sep 2012 04:10:12 -0700 (PDT)
In-Reply-To: <20120925172705.369e1483@mantra.us.oracle.com>
References: <20120921121556.1a0ea8af@mantra.us.oracle.com>
	<alpine.DEB.2.02.1209241228460.29232@kaball.uk.xensource.com>
	<1348488991.3452.69.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.02.1209241321240.29232@kaball.uk.xensource.com>
	<20120925172705.369e1483@mantra.us.oracle.com>
Date: Wed, 26 Sep 2012 12:10:12 +0100
X-Google-Sender-Auth: pJdLOsql4XlMKx7kVGQdnoev_CU
Message-ID: <CAFLBxZZvf=XmCXKGjFnSgzd3dUOH4X3X8v=cY6GCc3_7XauwKw@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: Mukesh Rathor <mukesh.rathor@oracle.com>
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] [PATCH v1 2/8]: PVH mmu changes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Sep 26, 2012 at 1:27 AM, Mukesh Rathor <mukesh.rathor@oracle.com> wrote:
>> > I'm not convinced that a guest level TLB flush is either necessary
>> > or sufficient here. What we are doing is removing entries from the
>> > P2M which means that we need to do the appropriate HAP flush in the
>> > hypervisor, which must necessarily invalidate any stage 1 mappings
>> > which this flush might also touch (i.e. the HAP flush must be a
>> > super set of this flush).
>> >
>> > Without the HAP flush in the hypervisor you risk guests being able
>> > to see old p2m mappings via the TLB entries which is a security
>> > issue AFAICT.
>>
>> Yes, you are right, we need a flush in the hypervisor to flush the
>> EPT. It could probably live in the implementation of
>> XENMEM_add_to_physmap.
>>
>> This one should be just for the vma mappings, so in the case of
>> xen_unmap_domain_mfn_range is unnecessary (given that it is
>> not removing the vma mappings).
>
>
> My head spins looking at INVEPT and INVVPID docs, but doesn't it already
> happen in ept_set_entry():
>
>     if ( needs_sync )
>         ept_sync_domain(p2m->domain);

Yes, the point of having a clean p2m interface is that you shouldn't
need to figure out when to do hap flushes.

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 26 11:17:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Sep 2012 11:17:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGpbl-0000mp-7e; Wed, 26 Sep 2012 11:16: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 1TGpbj-0000mk-F4
	for Xen-devel@lists.xensource.com; Wed, 26 Sep 2012 11:16:47 +0000
Received: from [85.158.143.99:61977] by server-3.bemta-4.messagelabs.com id
	AC/77-10986-E14E2605; Wed, 26 Sep 2012 11:16:46 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1348658206!26546701!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTE1NzQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13866 invoked from network); 26 Sep 2012 11:16:46 -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 Sep 2012 11:16:46 -0000
X-IronPort-AV: E=Sophos;i="4.80,490,1344211200"; d="scan'208";a="14774088"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Sep 2012 11:16: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.279.1; Wed, 26 Sep 2012 12:16:40 +0100
Date: Wed, 26 Sep 2012 12:15:46 +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: <20120925170917.580b213b@mantra.us.oracle.com>
Message-ID: <alpine.DEB.2.02.1209261213190.29232@kaball.uk.xensource.com>
References: <20120921121556.1a0ea8af@mantra.us.oracle.com>
	<alpine.DEB.2.02.1209241228460.29232@kaball.uk.xensource.com>
	<20120925170917.580b213b@mantra.us.oracle.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: Ian Campbell <Ian.Campbell@citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v1 2/8]: PVH mmu changes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 26 Sep 2012, Mukesh Rathor wrote:
> > > @@ -1652,6 +1681,10 @@ static void set_page_prot(void *addr,
> > > pgprot_t prot) unsigned long pfn = __pa(addr) >> PAGE_SHIFT;
> > > +		/* set_pte* for PCI devices to map iomem. */
> > > +		if (xen_initial_domain()) {
> > > +			pv_mmu_ops.set_pte = native_set_pte;
> > > +			pv_mmu_ops.set_pte_at =
> > > xen_dom0pvh_set_pte_at;
> > > +		}
> > > +		return;
> > > +	}
> > > +
> > >  	x86_init.mapping.pagetable_reserve =
> > > xen_mapping_pagetable_reserve;
> > > x86_init.paging.pagetable_setup_start = xen_pagetable_setup_start;
> > > -	x86_init.paging.pagetable_setup_done =
> > > xen_pagetable_setup_done; pv_mmu_ops = xen_mmu_ops;
> > >  
> > >  	memset(dummy_mapping, 0xff, PAGE_SIZE);
> > 
> > I wonder whether it would make sense to have a xen_pvh_init_mmu_ops,
> > given that they end up being so different...
> 
> It's not a pv ops call. It's called from xen_start_kernel in 
> enlighten.c. So lets just leave it like that.

I meant having a completely different initialization function in mmu.c,
instead of trying to reuse xen_init_mmu_ops, because at the end of the
day the two cases are very different

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 26 11:17:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Sep 2012 11:17:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGpbl-0000mp-7e; Wed, 26 Sep 2012 11:16: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 1TGpbj-0000mk-F4
	for Xen-devel@lists.xensource.com; Wed, 26 Sep 2012 11:16:47 +0000
Received: from [85.158.143.99:61977] by server-3.bemta-4.messagelabs.com id
	AC/77-10986-E14E2605; Wed, 26 Sep 2012 11:16:46 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1348658206!26546701!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTE1NzQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13866 invoked from network); 26 Sep 2012 11:16:46 -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 Sep 2012 11:16:46 -0000
X-IronPort-AV: E=Sophos;i="4.80,490,1344211200"; d="scan'208";a="14774088"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Sep 2012 11:16: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.279.1; Wed, 26 Sep 2012 12:16:40 +0100
Date: Wed, 26 Sep 2012 12:15:46 +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: <20120925170917.580b213b@mantra.us.oracle.com>
Message-ID: <alpine.DEB.2.02.1209261213190.29232@kaball.uk.xensource.com>
References: <20120921121556.1a0ea8af@mantra.us.oracle.com>
	<alpine.DEB.2.02.1209241228460.29232@kaball.uk.xensource.com>
	<20120925170917.580b213b@mantra.us.oracle.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: Ian Campbell <Ian.Campbell@citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v1 2/8]: PVH mmu changes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 26 Sep 2012, Mukesh Rathor wrote:
> > > @@ -1652,6 +1681,10 @@ static void set_page_prot(void *addr,
> > > pgprot_t prot) unsigned long pfn = __pa(addr) >> PAGE_SHIFT;
> > > +		/* set_pte* for PCI devices to map iomem. */
> > > +		if (xen_initial_domain()) {
> > > +			pv_mmu_ops.set_pte = native_set_pte;
> > > +			pv_mmu_ops.set_pte_at =
> > > xen_dom0pvh_set_pte_at;
> > > +		}
> > > +		return;
> > > +	}
> > > +
> > >  	x86_init.mapping.pagetable_reserve =
> > > xen_mapping_pagetable_reserve;
> > > x86_init.paging.pagetable_setup_start = xen_pagetable_setup_start;
> > > -	x86_init.paging.pagetable_setup_done =
> > > xen_pagetable_setup_done; pv_mmu_ops = xen_mmu_ops;
> > >  
> > >  	memset(dummy_mapping, 0xff, PAGE_SIZE);
> > 
> > I wonder whether it would make sense to have a xen_pvh_init_mmu_ops,
> > given that they end up being so different...
> 
> It's not a pv ops call. It's called from xen_start_kernel in 
> enlighten.c. So lets just leave it like that.

I meant having a completely different initialization function in mmu.c,
instead of trying to reuse xen_init_mmu_ops, because at the end of the
day the two cases are very different

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 26 11:18:41 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Sep 2012 11: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 1TGpdH-0000re-N4; Wed, 26 Sep 2012 11:18:23 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1TGpdG-0000rR-30
	for Xen-devel@lists.xensource.com; Wed, 26 Sep 2012 11:18:22 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1348658289!5464144!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTE1NzQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7670 invoked from network); 26 Sep 2012 11:18:09 -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;
	26 Sep 2012 11:18:09 -0000
X-IronPort-AV: E=Sophos;i="4.80,490,1344211200"; d="scan'208";a="14774122"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Sep 2012 11:17: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.279.1; Wed, 26 Sep 2012 12:17:51 +0100
Date: Wed, 26 Sep 2012 12:16:58 +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: <20120925172705.369e1483@mantra.us.oracle.com>
Message-ID: <alpine.DEB.2.02.1209261216340.29232@kaball.uk.xensource.com>
References: <20120921121556.1a0ea8af@mantra.us.oracle.com>
	<alpine.DEB.2.02.1209241228460.29232@kaball.uk.xensource.com>
	<1348488991.3452.69.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.02.1209241321240.29232@kaball.uk.xensource.com>
	<20120925172705.369e1483@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>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v1 2/8]: PVH mmu changes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 26 Sep 2012, Mukesh Rathor wrote:
> On Mon, 24 Sep 2012 13:24:12 +0100
> Stefano Stabellini <stefano.stabellini@eu.citrix.com> wrote:
> 
> > On Mon, 24 Sep 2012, Ian Campbell wrote:
> > > On Mon, 2012-09-24 at 12:55 +0100, Stefano Stabellini wrote:
> > > > There are few code style issues on this patch, I suggest you run
> > > > it through scripts/checkpatch.pl, it should be able to catch all
> > > > these errors.
> > > 
> > > It would also be nice to starting having some changelogs entries for
> > > these patches for the next posting. There's a lot of complex stuff
> > > > > +	return count;
> > > > 
> > > > Who is going to remove the corresponding mapping from the vma?
> > > > Also we might be able to replace the flush_tlb_all with a
> > > > flush_tlb_range.
> > > 
> > > I'm not convinced that a guest level TLB flush is either necessary
> > > or sufficient here. What we are doing is removing entries from the
> > > P2M which means that we need to do the appropriate HAP flush in the
> > > hypervisor, which must necessarily invalidate any stage 1 mappings
> > > which this flush might also touch (i.e. the HAP flush must be a
> > > super set of this flush).
> > > 
> > > Without the HAP flush in the hypervisor you risk guests being able
> > > to see old p2m mappings via the TLB entries which is a security
> > > issue AFAICT.
> > 
> > Yes, you are right, we need a flush in the hypervisor to flush the
> > EPT. It could probably live in the implementation of
> > XENMEM_add_to_physmap.
> > 
> > This one should be just for the vma mappings, so in the case of
> > xen_unmap_domain_mfn_range is unnecessary (given that it is
> > not removing the vma mappings).
> 
> 
> My head spins looking at INVEPT and INVVPID docs, but doesn't it already
> happen in ept_set_entry():
> 
>     if ( needs_sync )
>         ept_sync_domain(p2m->domain);
> 

Right. So we should be able to get away without any tlb flushes in
xen_unmap_domain_mfn_range.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 26 11:18:41 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Sep 2012 11: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 1TGpdH-0000re-N4; Wed, 26 Sep 2012 11:18:23 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1TGpdG-0000rR-30
	for Xen-devel@lists.xensource.com; Wed, 26 Sep 2012 11:18:22 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1348658289!5464144!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTE1NzQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7670 invoked from network); 26 Sep 2012 11:18:09 -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;
	26 Sep 2012 11:18:09 -0000
X-IronPort-AV: E=Sophos;i="4.80,490,1344211200"; d="scan'208";a="14774122"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Sep 2012 11:17: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.279.1; Wed, 26 Sep 2012 12:17:51 +0100
Date: Wed, 26 Sep 2012 12:16:58 +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: <20120925172705.369e1483@mantra.us.oracle.com>
Message-ID: <alpine.DEB.2.02.1209261216340.29232@kaball.uk.xensource.com>
References: <20120921121556.1a0ea8af@mantra.us.oracle.com>
	<alpine.DEB.2.02.1209241228460.29232@kaball.uk.xensource.com>
	<1348488991.3452.69.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.02.1209241321240.29232@kaball.uk.xensource.com>
	<20120925172705.369e1483@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>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v1 2/8]: PVH mmu changes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 26 Sep 2012, Mukesh Rathor wrote:
> On Mon, 24 Sep 2012 13:24:12 +0100
> Stefano Stabellini <stefano.stabellini@eu.citrix.com> wrote:
> 
> > On Mon, 24 Sep 2012, Ian Campbell wrote:
> > > On Mon, 2012-09-24 at 12:55 +0100, Stefano Stabellini wrote:
> > > > There are few code style issues on this patch, I suggest you run
> > > > it through scripts/checkpatch.pl, it should be able to catch all
> > > > these errors.
> > > 
> > > It would also be nice to starting having some changelogs entries for
> > > these patches for the next posting. There's a lot of complex stuff
> > > > > +	return count;
> > > > 
> > > > Who is going to remove the corresponding mapping from the vma?
> > > > Also we might be able to replace the flush_tlb_all with a
> > > > flush_tlb_range.
> > > 
> > > I'm not convinced that a guest level TLB flush is either necessary
> > > or sufficient here. What we are doing is removing entries from the
> > > P2M which means that we need to do the appropriate HAP flush in the
> > > hypervisor, which must necessarily invalidate any stage 1 mappings
> > > which this flush might also touch (i.e. the HAP flush must be a
> > > super set of this flush).
> > > 
> > > Without the HAP flush in the hypervisor you risk guests being able
> > > to see old p2m mappings via the TLB entries which is a security
> > > issue AFAICT.
> > 
> > Yes, you are right, we need a flush in the hypervisor to flush the
> > EPT. It could probably live in the implementation of
> > XENMEM_add_to_physmap.
> > 
> > This one should be just for the vma mappings, so in the case of
> > xen_unmap_domain_mfn_range is unnecessary (given that it is
> > not removing the vma mappings).
> 
> 
> My head spins looking at INVEPT and INVVPID docs, but doesn't it already
> happen in ept_set_entry():
> 
>     if ( needs_sync )
>         ept_sync_domain(p2m->domain);
> 

Right. So we should be able to get away without any tlb flushes in
xen_unmap_domain_mfn_range.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 26 11:26:23 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Sep 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 1TGpkl-00015g-VU; Wed, 26 Sep 2012 11:26: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 1TGpkj-00015b-P7
	for Xen-devel@lists.xensource.com; Wed, 26 Sep 2012 11:26:05 +0000
Received: from [85.158.143.99:48261] by server-1.bemta-4.messagelabs.com id
	FE/2F-05684-D46E2605; Wed, 26 Sep 2012 11:26:05 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1348658762!31238753!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTE1NzQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8101 invoked from network); 26 Sep 2012 11:26:02 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Sep 2012 11:26:02 -0000
X-IronPort-AV: E=Sophos;i="4.80,490,1344211200"; d="scan'208";a="14774323"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Sep 2012 11:26: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.279.1; Wed, 26 Sep 2012 12:26:02 +0100
Date: Wed, 26 Sep 2012 12:25:08 +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: <20120925173318.6c829910@mantra.us.oracle.com>
Message-ID: <alpine.DEB.2.02.1209261218510.29232@kaball.uk.xensource.com>
References: <20120921121556.1a0ea8af@mantra.us.oracle.com>
	<alpine.DEB.2.02.1209241500270.29232@kaball.uk.xensource.com>
	<20120925173318.6c829910@mantra.us.oracle.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: Ian Campbell <Ian.Campbell@citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v1 2/8]: PVH mmu changes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 26 Sep 2012, Mukesh Rathor wrote:
> On Mon, 24 Sep 2012 15:04:22 +0100
> Stefano Stabellini <stefano.stabellini@eu.citrix.com> wrote:
> 
> > On Fri, 21 Sep 2012, Mukesh Rathor wrote:
> > > +struct pvh_remap_data {
> > >  struct remap_data {
> > > @@ -2329,7 +2468,9 @@ static int remap_area_mfn_pte_fn(pte_t *ptep,
> > > pgtable_t token, int xen_remap_domain_mfn_range(struct
> > > vm_area_struct *vma, unsigned long addr,
> > >  			       unsigned long mfn, int nr,
> > > -			       pgprot_t prot, unsigned domid)
> > > +			       pgprot_t prot, unsigned domid,
> > > +			       struct xen_pvh_pfn_info *pvhp)
> > > +
> > 
> > xen_remap_domain_mfn_range is a cross-architecture call (it is
> > available on ARM as well). We cannot leak architecture specific
> > informations like xen_pvh_pfn_info in the parameter list.
> > It seems to be that xen_pvh_pfn_info contains arch-agnostic
> > information: in that case you just need to rename the struct to
> > something more generic. Otherwise if it really contains x86 specific
> > info, you can change it into an opaque pointer.
> 
> Ok, how about I just change it to:
> 
> -       struct xen_pvh_pfn_info *pvhp)
> +       void *arch_spec_info)

Sorry for misleading you, but on second thought, an opaque pointer is
not a good idea: xen_remap_domain_mfn_range is called from privcmd.c,
that is arch-agnostic code, so I think that all the parameters should be
well specified and arch-agnostic.

I think that you should:

- rename xen_pvh_pfn_info to something non-x86 specific, for example
  xen_remap_pfn_info;
- move the definition of struct xen_remap_pfn_info to
  include/xen/xen-ops.h;
- add a good comment on top of the struct to explain what each field
  represents, because other people (me and Ian) might have to reimplement
  xen_remap_domain_mfn_range in the near future for another popular
  architecture ;-)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 26 11:26:23 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Sep 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 1TGpkl-00015g-VU; Wed, 26 Sep 2012 11:26: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 1TGpkj-00015b-P7
	for Xen-devel@lists.xensource.com; Wed, 26 Sep 2012 11:26:05 +0000
Received: from [85.158.143.99:48261] by server-1.bemta-4.messagelabs.com id
	FE/2F-05684-D46E2605; Wed, 26 Sep 2012 11:26:05 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1348658762!31238753!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTE1NzQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8101 invoked from network); 26 Sep 2012 11:26:02 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Sep 2012 11:26:02 -0000
X-IronPort-AV: E=Sophos;i="4.80,490,1344211200"; d="scan'208";a="14774323"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Sep 2012 11:26: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.279.1; Wed, 26 Sep 2012 12:26:02 +0100
Date: Wed, 26 Sep 2012 12:25:08 +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: <20120925173318.6c829910@mantra.us.oracle.com>
Message-ID: <alpine.DEB.2.02.1209261218510.29232@kaball.uk.xensource.com>
References: <20120921121556.1a0ea8af@mantra.us.oracle.com>
	<alpine.DEB.2.02.1209241500270.29232@kaball.uk.xensource.com>
	<20120925173318.6c829910@mantra.us.oracle.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: Ian Campbell <Ian.Campbell@citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v1 2/8]: PVH mmu changes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 26 Sep 2012, Mukesh Rathor wrote:
> On Mon, 24 Sep 2012 15:04:22 +0100
> Stefano Stabellini <stefano.stabellini@eu.citrix.com> wrote:
> 
> > On Fri, 21 Sep 2012, Mukesh Rathor wrote:
> > > +struct pvh_remap_data {
> > >  struct remap_data {
> > > @@ -2329,7 +2468,9 @@ static int remap_area_mfn_pte_fn(pte_t *ptep,
> > > pgtable_t token, int xen_remap_domain_mfn_range(struct
> > > vm_area_struct *vma, unsigned long addr,
> > >  			       unsigned long mfn, int nr,
> > > -			       pgprot_t prot, unsigned domid)
> > > +			       pgprot_t prot, unsigned domid,
> > > +			       struct xen_pvh_pfn_info *pvhp)
> > > +
> > 
> > xen_remap_domain_mfn_range is a cross-architecture call (it is
> > available on ARM as well). We cannot leak architecture specific
> > informations like xen_pvh_pfn_info in the parameter list.
> > It seems to be that xen_pvh_pfn_info contains arch-agnostic
> > information: in that case you just need to rename the struct to
> > something more generic. Otherwise if it really contains x86 specific
> > info, you can change it into an opaque pointer.
> 
> Ok, how about I just change it to:
> 
> -       struct xen_pvh_pfn_info *pvhp)
> +       void *arch_spec_info)

Sorry for misleading you, but on second thought, an opaque pointer is
not a good idea: xen_remap_domain_mfn_range is called from privcmd.c,
that is arch-agnostic code, so I think that all the parameters should be
well specified and arch-agnostic.

I think that you should:

- rename xen_pvh_pfn_info to something non-x86 specific, for example
  xen_remap_pfn_info;
- move the definition of struct xen_remap_pfn_info to
  include/xen/xen-ops.h;
- add a good comment on top of the struct to explain what each field
  represents, because other people (me and Ian) might have to reimplement
  xen_remap_domain_mfn_range in the near future for another popular
  architecture ;-)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 26 11:28:55 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Sep 2012 11:28:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGpnG-0001BD-Gn; Wed, 26 Sep 2012 11:28:42 +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 1TGpnE-0001B0-Qs
	for xen-devel@lists.xensource.com; Wed, 26 Sep 2012 11:28:41 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1348658914!8724295!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTE1NzQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2669 invoked from network); 26 Sep 2012 11:28:34 -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;
	26 Sep 2012 11:28:34 -0000
X-IronPort-AV: E=Sophos;i="4.80,490,1344211200"; d="scan'208";a="14774385"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Sep 2012 11:28:24 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Wed, 26 Sep 2012 12:28:24 +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 1TGpmy-00084X-39;
	Wed, 26 Sep 2012 11:28:24 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1TGpmy-0003rw-2M;
	Wed, 26 Sep 2012 12:28:24 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-13869-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 26 Sep 2012 12:28:24 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13869: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 13869 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13869/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-credit2    5 xen-boot                  fail REGR. vs. 13825
 test-amd64-i386-xl-win7-amd64  5 xen-boot                 fail REGR. vs. 13825
 test-amd64-amd64-pv           5 xen-boot                  fail REGR. vs. 13825
 test-amd64-i386-rhel6hvm-intel  5 xen-boot                fail REGR. vs. 13825
 test-amd64-i386-win-vcpus1   12 guest-localmigrate/x10    fail REGR. vs. 13825
 test-amd64-amd64-xl-winxpsp3  5 xen-boot                  fail REGR. vs. 13825
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install   fail REGR. vs. 13825
 test-amd64-i386-pair          8 xen-boot/dst_host         fail REGR. vs. 13825
 test-amd64-i386-pair          7 xen-boot/src_host         fail REGR. vs. 13825

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-pcipt-intel  7 debian-install         fail REGR. vs. 13825
 test-amd64-i386-xl-win-vcpus1 12 guest-localmigrate/x10       fail  like 13825
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore            fail   like 13825
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail like 13823

Tests which did not succeed, but are not blocking:
 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-win7-amd64 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-win      13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  656662f7ea59
baseline version:
 xen                  d364becfb083

------------------------------------------------------------
People who touched revisions under test:
  Bastian Blank <waldi@debian.org>
  Ben Guthro <ben@guthro.net>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Keir Fraser <keir@xen.org>
  Olaf Hering <olaf@aepfle.de>
------------------------------------------------------------

jobs:
 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-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                                   fail    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          fail    
 test-amd64-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-amd64-amd64-xl-win                                      fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
changeset:   25946:656662f7ea59
tag:         tip
user:        Ian Jackson <Ian.Jackson@eu.citrix.com>
date:        Tue Sep 25 18:45:04 2012 +0100
    
    docs: network network diagrams for the wiki (figs)
    
    Add the figs in hg as well as git.  Sorry (again)!
    
    Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
changeset:   25945:0604d4676c6b
user:        Ian Jackson <Ian.Jackson@eu.citrix.com>
date:        Tue Sep 25 18:39:39 2012 +0100
    
    docs: network network diagrams for the wiki (Makefile)
    
    Add the Makefile in hg as well as git.  Sorry.
    
    Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
changeset:   25944:6ec80d1a5630
user:        Ian Jackson <Ian.Jackson@eu.citrix.com>
date:        Tue Sep 25 18:31:20 2012 +0100
    
    docs: network diagrams for the wiki
    
    We provide two new diagrams
      docs/figs/network-{bridge,basic}.fig
    which are converted to pngs by the Makefiles and intended for
    consumption by http://wiki.xen.org/wiki/Xen_Networking.
    
    This is perhaps not the ideal location for this source code but we
    don't have a better one.
    
    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>
    
    
changeset:   25943:0a64f1a3f72c
user:        Ian Campbell <ian.campbell@citrix.com>
date:        Tue Sep 25 13:40:00 2012 +0100
    
    tools: bump SONAMEs for changes during 4.2 development cycle.
    
    We mostly did this as we went along, only a couple of minor number
    bumps were missed http://marc.info/?l=xen-devel&m=134366054929255&w=2:
     - Bumped libxl from 1.0.0 -> 1.0.1
     - Bumped libxenstore from 3.0.1 -> 3.0.2
    
    Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
    Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
    Committed-by: Ian Campbell <ian.campbell@citrix.com>
    
    
changeset:   25942:16ee1d300cfd
user:        Bastian Blank <waldi@debian.org>
date:        Tue Sep 25 11:03:51 2012 +0100
    
    xl: resume the domain on suspend failure
    
    The MUST macro calls exit(3) on failure but we need to cleanup and
    resume.
    
    Signed-off-by: Bastian Blank <waldi@debian.org>
    Acked-by: Ian Campbell <ian.campbell@citrix.com>
    Committed-by: Ian Campbell <ian.campbell@citrix.com>
    
    
changeset:   25941:795c493fe561
user:        Olaf Hering <olaf@aepfle.de>
date:        Tue Sep 25 11:03:51 2012 +0100
    
    pygrub: always append --args
    
    If a bootloader entry in menu.lst has no additional kernel command line
    options listed and the domU.cfg has 'bootargs="--args=something"' the
    additional arguments from the config file are not passed to the kernel.
    The reason for that incorrect behaviour is that run_grub appends arg
    only if the parsed config file has arguments listed.
    
    Fix this by appending args from image section and the config file separatly.
    To avoid adding to a NoneType initialize grubcfg['args'] to an empty string.
    This does not change behaviour but simplifies the code which appends the
    string.
    
    Signed-off-by: Olaf Hering <olaf@aepfle.de>
    Acked-by: Ian Campbell <ian.campbell@citrix.com>
    Committed-by: Ian Campbell <ian.campbell@citrix.com>
    
    
changeset:   25940:c8d65d91a6f2
user:        Ben Guthro <ben@guthro.net>
date:        Tue Sep 25 08:38:14 2012 +0200
    
    x86/S3: add cache flush on secondary CPUs before going to sleep
    
    Secondary CPUs, between doing their final memory writes (particularly
    updating cpu_initialized) and getting a subsequent INIT, may not write
    back all modified data. The INIT itself then causes those modifications
    to be lost, so in the cpu_initialized case the CPU would find itself
    already initialized, (intentionally) entering an infinite loop instead
    of actually coming online.
    
    Signed-off-by: Ben Guthro <ben@guthro.net>
    
    Make acpi_dead_idle() call default_dead_idle() rather than duplicating
    the logic there.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    Committed-by: Jan Beulich <jbeulich@suse.com>
    
    
changeset:   25939:b49f7bf52fa9
user:        Jan Beulich <jbeulich@suse.com>
date:        Tue Sep 25 08:36:33 2012 +0200
    
    x86: fix MWAIT-based idle driver for CPUs without ARAT
    
    lapic_timer_{on,off} need to get initialized in this case. This in turn
    requires getting HPET broadcast setup to be carried out earlier (and
    hence preventing double initialization there).
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    
    
changeset:   25938:8f658b463b78
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Sep 21 17:02:46 2012 +0200
    
    x86: enable VIA CPU support
    
    Newer VIA CPUs have both 64-bit and VMX support. Enable them to be
    recognized for these purposes, at once stripping off any 32-bit CPU
    only bits from the respective CPU support file, and adding 64-bit ones
    found in recent Linux.
    
    This particularly implies untying the VMX == Intel assumption in a few
    places.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   25937:32187301ecc5
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Sep 21 15:20:21 2012 +0200
    
    x86: eliminate code affecting only 64-bit-incapable CPUs
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   25936:c8873f13cec3
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Sep 21 14:25:12 2012 +0200
    
    printk: prefer %#x et at over 0x%x
    
    Performance is not an issue with printk(), so let the function do
    minimally more work and instead save a byte per affected format
    specifier.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   25935:1e6e6b49b4ac
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Sep 21 13:47:18 2012 +0200
    
    x86: introduce MWAIT-based, ACPI-less CPU idle driver
    
    This is a port of Linux'es intel-idle driver serving the same purpose.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   25934:8eab91903e71
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Sep 21 13:45:08 2012 +0200
    
    cpuidle: remove unused latency_ticks member
    
    ... and code used only for initializing it.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   25933:d364becfb083
user:        Jan Beulich <jbeulich@suse.com>
date:        Thu Sep 20 13:31:19 2012 +0200
    
    introduce guest_handle_for_field()
    
    This helper turns a field of a GUEST_HANDLE in a GUEST_HANDLE.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    
    
(qemu changes not included)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 26 11:28:55 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Sep 2012 11:28:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGpnG-0001BD-Gn; Wed, 26 Sep 2012 11:28:42 +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 1TGpnE-0001B0-Qs
	for xen-devel@lists.xensource.com; Wed, 26 Sep 2012 11:28:41 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1348658914!8724295!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTE1NzQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2669 invoked from network); 26 Sep 2012 11:28:34 -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;
	26 Sep 2012 11:28:34 -0000
X-IronPort-AV: E=Sophos;i="4.80,490,1344211200"; d="scan'208";a="14774385"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Sep 2012 11:28:24 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Wed, 26 Sep 2012 12:28:24 +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 1TGpmy-00084X-39;
	Wed, 26 Sep 2012 11:28:24 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1TGpmy-0003rw-2M;
	Wed, 26 Sep 2012 12:28:24 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-13869-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 26 Sep 2012 12:28:24 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13869: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 13869 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13869/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-credit2    5 xen-boot                  fail REGR. vs. 13825
 test-amd64-i386-xl-win7-amd64  5 xen-boot                 fail REGR. vs. 13825
 test-amd64-amd64-pv           5 xen-boot                  fail REGR. vs. 13825
 test-amd64-i386-rhel6hvm-intel  5 xen-boot                fail REGR. vs. 13825
 test-amd64-i386-win-vcpus1   12 guest-localmigrate/x10    fail REGR. vs. 13825
 test-amd64-amd64-xl-winxpsp3  5 xen-boot                  fail REGR. vs. 13825
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install   fail REGR. vs. 13825
 test-amd64-i386-pair          8 xen-boot/dst_host         fail REGR. vs. 13825
 test-amd64-i386-pair          7 xen-boot/src_host         fail REGR. vs. 13825

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-pcipt-intel  7 debian-install         fail REGR. vs. 13825
 test-amd64-i386-xl-win-vcpus1 12 guest-localmigrate/x10       fail  like 13825
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore            fail   like 13825
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail like 13823

Tests which did not succeed, but are not blocking:
 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-win7-amd64 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-win      13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  656662f7ea59
baseline version:
 xen                  d364becfb083

------------------------------------------------------------
People who touched revisions under test:
  Bastian Blank <waldi@debian.org>
  Ben Guthro <ben@guthro.net>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Keir Fraser <keir@xen.org>
  Olaf Hering <olaf@aepfle.de>
------------------------------------------------------------

jobs:
 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-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                                   fail    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          fail    
 test-amd64-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-amd64-amd64-xl-win                                      fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
changeset:   25946:656662f7ea59
tag:         tip
user:        Ian Jackson <Ian.Jackson@eu.citrix.com>
date:        Tue Sep 25 18:45:04 2012 +0100
    
    docs: network network diagrams for the wiki (figs)
    
    Add the figs in hg as well as git.  Sorry (again)!
    
    Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
changeset:   25945:0604d4676c6b
user:        Ian Jackson <Ian.Jackson@eu.citrix.com>
date:        Tue Sep 25 18:39:39 2012 +0100
    
    docs: network network diagrams for the wiki (Makefile)
    
    Add the Makefile in hg as well as git.  Sorry.
    
    Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
changeset:   25944:6ec80d1a5630
user:        Ian Jackson <Ian.Jackson@eu.citrix.com>
date:        Tue Sep 25 18:31:20 2012 +0100
    
    docs: network diagrams for the wiki
    
    We provide two new diagrams
      docs/figs/network-{bridge,basic}.fig
    which are converted to pngs by the Makefiles and intended for
    consumption by http://wiki.xen.org/wiki/Xen_Networking.
    
    This is perhaps not the ideal location for this source code but we
    don't have a better one.
    
    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>
    
    
changeset:   25943:0a64f1a3f72c
user:        Ian Campbell <ian.campbell@citrix.com>
date:        Tue Sep 25 13:40:00 2012 +0100
    
    tools: bump SONAMEs for changes during 4.2 development cycle.
    
    We mostly did this as we went along, only a couple of minor number
    bumps were missed http://marc.info/?l=xen-devel&m=134366054929255&w=2:
     - Bumped libxl from 1.0.0 -> 1.0.1
     - Bumped libxenstore from 3.0.1 -> 3.0.2
    
    Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
    Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
    Committed-by: Ian Campbell <ian.campbell@citrix.com>
    
    
changeset:   25942:16ee1d300cfd
user:        Bastian Blank <waldi@debian.org>
date:        Tue Sep 25 11:03:51 2012 +0100
    
    xl: resume the domain on suspend failure
    
    The MUST macro calls exit(3) on failure but we need to cleanup and
    resume.
    
    Signed-off-by: Bastian Blank <waldi@debian.org>
    Acked-by: Ian Campbell <ian.campbell@citrix.com>
    Committed-by: Ian Campbell <ian.campbell@citrix.com>
    
    
changeset:   25941:795c493fe561
user:        Olaf Hering <olaf@aepfle.de>
date:        Tue Sep 25 11:03:51 2012 +0100
    
    pygrub: always append --args
    
    If a bootloader entry in menu.lst has no additional kernel command line
    options listed and the domU.cfg has 'bootargs="--args=something"' the
    additional arguments from the config file are not passed to the kernel.
    The reason for that incorrect behaviour is that run_grub appends arg
    only if the parsed config file has arguments listed.
    
    Fix this by appending args from image section and the config file separatly.
    To avoid adding to a NoneType initialize grubcfg['args'] to an empty string.
    This does not change behaviour but simplifies the code which appends the
    string.
    
    Signed-off-by: Olaf Hering <olaf@aepfle.de>
    Acked-by: Ian Campbell <ian.campbell@citrix.com>
    Committed-by: Ian Campbell <ian.campbell@citrix.com>
    
    
changeset:   25940:c8d65d91a6f2
user:        Ben Guthro <ben@guthro.net>
date:        Tue Sep 25 08:38:14 2012 +0200
    
    x86/S3: add cache flush on secondary CPUs before going to sleep
    
    Secondary CPUs, between doing their final memory writes (particularly
    updating cpu_initialized) and getting a subsequent INIT, may not write
    back all modified data. The INIT itself then causes those modifications
    to be lost, so in the cpu_initialized case the CPU would find itself
    already initialized, (intentionally) entering an infinite loop instead
    of actually coming online.
    
    Signed-off-by: Ben Guthro <ben@guthro.net>
    
    Make acpi_dead_idle() call default_dead_idle() rather than duplicating
    the logic there.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    Committed-by: Jan Beulich <jbeulich@suse.com>
    
    
changeset:   25939:b49f7bf52fa9
user:        Jan Beulich <jbeulich@suse.com>
date:        Tue Sep 25 08:36:33 2012 +0200
    
    x86: fix MWAIT-based idle driver for CPUs without ARAT
    
    lapic_timer_{on,off} need to get initialized in this case. This in turn
    requires getting HPET broadcast setup to be carried out earlier (and
    hence preventing double initialization there).
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    
    
changeset:   25938:8f658b463b78
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Sep 21 17:02:46 2012 +0200
    
    x86: enable VIA CPU support
    
    Newer VIA CPUs have both 64-bit and VMX support. Enable them to be
    recognized for these purposes, at once stripping off any 32-bit CPU
    only bits from the respective CPU support file, and adding 64-bit ones
    found in recent Linux.
    
    This particularly implies untying the VMX == Intel assumption in a few
    places.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   25937:32187301ecc5
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Sep 21 15:20:21 2012 +0200
    
    x86: eliminate code affecting only 64-bit-incapable CPUs
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   25936:c8873f13cec3
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Sep 21 14:25:12 2012 +0200
    
    printk: prefer %#x et at over 0x%x
    
    Performance is not an issue with printk(), so let the function do
    minimally more work and instead save a byte per affected format
    specifier.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   25935:1e6e6b49b4ac
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Sep 21 13:47:18 2012 +0200
    
    x86: introduce MWAIT-based, ACPI-less CPU idle driver
    
    This is a port of Linux'es intel-idle driver serving the same purpose.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   25934:8eab91903e71
user:        Jan Beulich <jbeulich@suse.com>
date:        Fri Sep 21 13:45:08 2012 +0200
    
    cpuidle: remove unused latency_ticks member
    
    ... and code used only for initializing it.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   25933:d364becfb083
user:        Jan Beulich <jbeulich@suse.com>
date:        Thu Sep 20 13:31:19 2012 +0200
    
    introduce guest_handle_for_field()
    
    This helper turns a field of a GUEST_HANDLE in a GUEST_HANDLE.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    
    
(qemu changes not included)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 26 11:34:51 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Sep 2012 11:34: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 1TGpsy-0001RR-Ex; Wed, 26 Sep 2012 11:34:36 +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 1TGpsx-0001RM-0J
	for Xen-devel@lists.xensource.com; Wed, 26 Sep 2012 11:34:35 +0000
Received: from [85.158.139.211:47626] by server-8.bemta-5.messagelabs.com id
	C7/AC-18073-A48E2605; Wed, 26 Sep 2012 11:34:34 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-4.tower-206.messagelabs.com!1348659273!20040844!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTE1NzQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14059 invoked from network); 26 Sep 2012 11:34:33 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Sep 2012 11:34:33 -0000
X-IronPort-AV: E=Sophos;i="4.80,490,1344211200"; d="scan'208";a="14774539"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Sep 2012 11:34: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.279.1; Wed, 26 Sep 2012 12:34:33 +0100
Date: Wed, 26 Sep 2012 12:33:39 +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: <20120925180416.0137d61a@mantra.us.oracle.com>
Message-ID: <alpine.DEB.2.02.1209261225340.29232@kaball.uk.xensource.com>
References: <20120921121659.5a723de9@mantra.us.oracle.com>
	<alpine.DEB.2.02.1209241257440.29232@kaball.uk.xensource.com>
	<20120924154335.097d3fb9@mantra.us.oracle.com>
	<alpine.DEB.2.02.1209251054140.29232@kaball.uk.xensource.com>
	<20120925180416.0137d61a@mantra.us.oracle.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: Ian Campbell <Ian.Campbell@citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v1 3/8]: PVH startup changes (enlighten.c)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 26 Sep 2012, Mukesh Rathor wrote:
> On Tue, 25 Sep 2012 11:03:13 +0100
> Stefano Stabellini <stefano.stabellini@eu.citrix.com> wrote:
> 
> > On Mon, 24 Sep 2012, Mukesh Rathor wrote:
> > > On Mon, 24 Sep 2012 13:07:19 +0100
> > > Stefano Stabellini <stefano.stabellini@eu.citrix.com> wrote:
> > > 
> > > > On Fri, 21 Sep 2012, Mukesh Rathor wrote:
> > > > > +		return;
> > > > > +
> > > > >  	if (!xen_feature(XENFEAT_auto_translated_physmap)) {
> > > > >  		set_fixmap(FIX_PARAVIRT_BOOTMAP,
> > > > >  			   xen_start_info->shared_info);
> > > > >
> > > > > @@ -1044,6 +1058,10 @@ void xen_setup_shared_info(void)
> > > > >  		HYPERVISOR_shared_info =
> > > > >  			(struct shared_info
> > > > > *)__va(xen_start_info->shared_info); 
> > > > > +	/* PVH TBD/FIXME: vcpu info placement in phase 2 */
> > > > > +	if (xen_pvh_domain())
> > > > > +		return;
> > > > 
> > > > It seems that if xen_initial_domain we always skip the
> > > > initialization while if !xen_initial_domain we only initialize
> > > > HYPERVISOR_shared_info. I don't understand why we have this
> > > > difference.
> > > 
> > > The comment in xen_pvh_guest_init() explains it. For domU the
> > > library maps the pfn at shared_info, ie, shared_info is pfn. For
> > > dom0, it's the mfn. Dom0 then allocates a pfn via extend_brk, and
> > > maps the mfn to it. This happens in the commond hvm code,
> > > xen_hvm_init_shared_info().
> > 
> > This difference is really subtle, it would be nice to get rid of it.
> > Could Xen allocate a pfn for dom0?
> 
> Not easily.
> 
> > Otherwise could we have the tools allocate an mfn instead of a pfn?
> > In fact looking at xc_dom_x86.c, alloc_magic_pages is explicitly
> > having a different behavior for xc_dom_feature_translated guests and
> > allocates pfn instead of an mfn. Maybe we could get rid of that
> > special case: less code in libxc, a common way of allocating the
> > shared_info page for domU and dom0 => win.
> 
> Wish it was simple. But for PV and PVH, domU, it's already setup the 
> shared page. All we need to do is __va(shared_info). But for HVM domUs 
> and PVH dom0, we need to hcall with pfn to get it remapped.

For PVH domU is already setup as a pfn only because in
tools/libxc/xc_dom_x86.c:alloc_magic_pages we have this code:

    if ( xc_dom_feature_translated(dom) )
        dom->shared_info_pfn = xc_dom_alloc_page(dom, "shared info");

and in tools/libxc/xc_dom_x86.c:start_info_x86_64 we have:

    xen_pfn_t shinfo =
        xc_dom_feature_translated(dom) ? dom->shared_info_pfn : dom->
        shared_info_mfn;

if we simply get rid of the two "if xc_dom_feature_translated(dom)"
wouldn't we get an mfn for PVH domU too? AFAICT all the other cases would
remain unmodified, but PVH domU would start getting an mfn for shared_info.

> Changing the
> tool to map pfn, would result in unnecessary hcall for all PV and PVH
> domUs. It's only two lines of code, so lets just leave it. I'll make the
> comment better.

Yes, there would be one more unnecessary hypercall but we would get rid
of 4 "if". I think is a good trade off.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 26 11:34:51 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Sep 2012 11:34: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 1TGpsy-0001RR-Ex; Wed, 26 Sep 2012 11:34:36 +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 1TGpsx-0001RM-0J
	for Xen-devel@lists.xensource.com; Wed, 26 Sep 2012 11:34:35 +0000
Received: from [85.158.139.211:47626] by server-8.bemta-5.messagelabs.com id
	C7/AC-18073-A48E2605; Wed, 26 Sep 2012 11:34:34 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-4.tower-206.messagelabs.com!1348659273!20040844!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTE1NzQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14059 invoked from network); 26 Sep 2012 11:34:33 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Sep 2012 11:34:33 -0000
X-IronPort-AV: E=Sophos;i="4.80,490,1344211200"; d="scan'208";a="14774539"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Sep 2012 11:34: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.279.1; Wed, 26 Sep 2012 12:34:33 +0100
Date: Wed, 26 Sep 2012 12:33:39 +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: <20120925180416.0137d61a@mantra.us.oracle.com>
Message-ID: <alpine.DEB.2.02.1209261225340.29232@kaball.uk.xensource.com>
References: <20120921121659.5a723de9@mantra.us.oracle.com>
	<alpine.DEB.2.02.1209241257440.29232@kaball.uk.xensource.com>
	<20120924154335.097d3fb9@mantra.us.oracle.com>
	<alpine.DEB.2.02.1209251054140.29232@kaball.uk.xensource.com>
	<20120925180416.0137d61a@mantra.us.oracle.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Cc: Ian Campbell <Ian.Campbell@citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v1 3/8]: PVH startup changes (enlighten.c)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 26 Sep 2012, Mukesh Rathor wrote:
> On Tue, 25 Sep 2012 11:03:13 +0100
> Stefano Stabellini <stefano.stabellini@eu.citrix.com> wrote:
> 
> > On Mon, 24 Sep 2012, Mukesh Rathor wrote:
> > > On Mon, 24 Sep 2012 13:07:19 +0100
> > > Stefano Stabellini <stefano.stabellini@eu.citrix.com> wrote:
> > > 
> > > > On Fri, 21 Sep 2012, Mukesh Rathor wrote:
> > > > > +		return;
> > > > > +
> > > > >  	if (!xen_feature(XENFEAT_auto_translated_physmap)) {
> > > > >  		set_fixmap(FIX_PARAVIRT_BOOTMAP,
> > > > >  			   xen_start_info->shared_info);
> > > > >
> > > > > @@ -1044,6 +1058,10 @@ void xen_setup_shared_info(void)
> > > > >  		HYPERVISOR_shared_info =
> > > > >  			(struct shared_info
> > > > > *)__va(xen_start_info->shared_info); 
> > > > > +	/* PVH TBD/FIXME: vcpu info placement in phase 2 */
> > > > > +	if (xen_pvh_domain())
> > > > > +		return;
> > > > 
> > > > It seems that if xen_initial_domain we always skip the
> > > > initialization while if !xen_initial_domain we only initialize
> > > > HYPERVISOR_shared_info. I don't understand why we have this
> > > > difference.
> > > 
> > > The comment in xen_pvh_guest_init() explains it. For domU the
> > > library maps the pfn at shared_info, ie, shared_info is pfn. For
> > > dom0, it's the mfn. Dom0 then allocates a pfn via extend_brk, and
> > > maps the mfn to it. This happens in the commond hvm code,
> > > xen_hvm_init_shared_info().
> > 
> > This difference is really subtle, it would be nice to get rid of it.
> > Could Xen allocate a pfn for dom0?
> 
> Not easily.
> 
> > Otherwise could we have the tools allocate an mfn instead of a pfn?
> > In fact looking at xc_dom_x86.c, alloc_magic_pages is explicitly
> > having a different behavior for xc_dom_feature_translated guests and
> > allocates pfn instead of an mfn. Maybe we could get rid of that
> > special case: less code in libxc, a common way of allocating the
> > shared_info page for domU and dom0 => win.
> 
> Wish it was simple. But for PV and PVH, domU, it's already setup the 
> shared page. All we need to do is __va(shared_info). But for HVM domUs 
> and PVH dom0, we need to hcall with pfn to get it remapped.

For PVH domU is already setup as a pfn only because in
tools/libxc/xc_dom_x86.c:alloc_magic_pages we have this code:

    if ( xc_dom_feature_translated(dom) )
        dom->shared_info_pfn = xc_dom_alloc_page(dom, "shared info");

and in tools/libxc/xc_dom_x86.c:start_info_x86_64 we have:

    xen_pfn_t shinfo =
        xc_dom_feature_translated(dom) ? dom->shared_info_pfn : dom->
        shared_info_mfn;

if we simply get rid of the two "if xc_dom_feature_translated(dom)"
wouldn't we get an mfn for PVH domU too? AFAICT all the other cases would
remain unmodified, but PVH domU would start getting an mfn for shared_info.

> Changing the
> tool to map pfn, would result in unnecessary hcall for all PV and PVH
> domUs. It's only two lines of code, so lets just leave it. I'll make the
> comment better.

Yes, there would be one more unnecessary hypercall but we would get rid
of 4 "if". I think is a good trade off.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 26 11:44:24 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Sep 2012 11: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 1TGq2B-0001aj-Fz; Wed, 26 Sep 2012 11:44: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 1TGq29-0001ae-AF
	for Xen-devel@lists.xensource.com; Wed, 26 Sep 2012 11:44:05 +0000
Received: from [85.158.139.83:14682] by server-7.bemta-5.messagelabs.com id
	71/64-00431-48AE2605; Wed, 26 Sep 2012 11:44:04 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1348659843!32481095!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTE1NzQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 646 invoked from network); 26 Sep 2012 11:44:03 -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 Sep 2012 11:44:03 -0000
X-IronPort-AV: E=Sophos;i="4.80,490,1344211200"; d="scan'208";a="14774803"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Sep 2012 11:44: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.279.1;
	Wed, 26 Sep 2012 12:44:03 +0100
Message-ID: <1348659840.19176.31.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Date: Wed, 26 Sep 2012 12:44:00 +0100
In-Reply-To: <alpine.DEB.2.02.1209261225340.29232@kaball.uk.xensource.com>
References: <20120921121659.5a723de9@mantra.us.oracle.com>
	<alpine.DEB.2.02.1209241257440.29232@kaball.uk.xensource.com>
	<20120924154335.097d3fb9@mantra.us.oracle.com>
	<alpine.DEB.2.02.1209251054140.29232@kaball.uk.xensource.com>
	<20120925180416.0137d61a@mantra.us.oracle.com>
	<alpine.DEB.2.02.1209261225340.29232@kaball.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH v1 3/8]: PVH startup changes (enlighten.c)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-09-26 at 12:33 +0100, Stefano Stabellini wrote:
> On Wed, 26 Sep 2012, Mukesh Rathor wrote:
> > On Tue, 25 Sep 2012 11:03:13 +0100
> > Stefano Stabellini <stefano.stabellini@eu.citrix.com> wrote:
> > 
> > > On Mon, 24 Sep 2012, Mukesh Rathor wrote:
> > > > On Mon, 24 Sep 2012 13:07:19 +0100
> > > > Stefano Stabellini <stefano.stabellini@eu.citrix.com> wrote:
> > > > 
> > > > > On Fri, 21 Sep 2012, Mukesh Rathor wrote:
> > > > > > +		return;
> > > > > > +
> > > > > >  	if (!xen_feature(XENFEAT_auto_translated_physmap)) {
> > > > > >  		set_fixmap(FIX_PARAVIRT_BOOTMAP,
> > > > > >  			   xen_start_info->shared_info);
> > > > > >
> > > > > > @@ -1044,6 +1058,10 @@ void xen_setup_shared_info(void)
> > > > > >  		HYPERVISOR_shared_info =
> > > > > >  			(struct shared_info
> > > > > > *)__va(xen_start_info->shared_info); 
> > > > > > +	/* PVH TBD/FIXME: vcpu info placement in phase 2 */
> > > > > > +	if (xen_pvh_domain())
> > > > > > +		return;
> > > > > 
> > > > > It seems that if xen_initial_domain we always skip the
> > > > > initialization while if !xen_initial_domain we only initialize
> > > > > HYPERVISOR_shared_info. I don't understand why we have this
> > > > > difference.
> > > > 
> > > > The comment in xen_pvh_guest_init() explains it. For domU the
> > > > library maps the pfn at shared_info, ie, shared_info is pfn. For
> > > > dom0, it's the mfn. Dom0 then allocates a pfn via extend_brk, and
> > > > maps the mfn to it. This happens in the commond hvm code,
> > > > xen_hvm_init_shared_info().
> > > 
> > > This difference is really subtle, it would be nice to get rid of it.
> > > Could Xen allocate a pfn for dom0?
> > 
> > Not easily.
> > 
> > > Otherwise could we have the tools allocate an mfn instead of a pfn?
> > > In fact looking at xc_dom_x86.c, alloc_magic_pages is explicitly
> > > having a different behavior for xc_dom_feature_translated guests and
> > > allocates pfn instead of an mfn. Maybe we could get rid of that
> > > special case: less code in libxc, a common way of allocating the
> > > shared_info page for domU and dom0 => win.
> > 
> > Wish it was simple. But for PV and PVH, domU, it's already setup the 
> > shared page. All we need to do is __va(shared_info). But for HVM domUs 
> > and PVH dom0, we need to hcall with pfn to get it remapped.
> 
> For PVH domU is already setup as a pfn only because in
> tools/libxc/xc_dom_x86.c:alloc_magic_pages we have this code:
> 
>     if ( xc_dom_feature_translated(dom) )
>         dom->shared_info_pfn = xc_dom_alloc_page(dom, "shared info");
> 
> and in tools/libxc/xc_dom_x86.c:start_info_x86_64 we have:
> 
>     xen_pfn_t shinfo =
>         xc_dom_feature_translated(dom) ? dom->shared_info_pfn : dom->
>         shared_info_mfn;
> 
> if we simply get rid of the two "if xc_dom_feature_translated(dom)"
> wouldn't we get an mfn for PVH domU too? AFAICT all the other cases would
> remain unmodified, but PVH domU would start getting an mfn for shared_info.

The other option would be to have the hypervisor side builder for a PVH
dom0 add an entry to the P2M for the shared info as well. Arguably that
would be more PV like and therefore the correct thing for a PVH guest
since it makes the shared info immediately available to the dom0.

> > Changing the
> > tool to map pfn, would result in unnecessary hcall for all PV and PVH
> > domUs. It's only two lines of code, so lets just leave it. I'll make the
> > comment better.
> 
> Yes, there would be one more unnecessary hypercall but we would get rid
> of 4 "if". I think is a good trade off.

Certainly minimising the numbers of hypercalls is not the most important
thing in a code path which is run once at start of day.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 26 11:44:24 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Sep 2012 11: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 1TGq2B-0001aj-Fz; Wed, 26 Sep 2012 11:44: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 1TGq29-0001ae-AF
	for Xen-devel@lists.xensource.com; Wed, 26 Sep 2012 11:44:05 +0000
Received: from [85.158.139.83:14682] by server-7.bemta-5.messagelabs.com id
	71/64-00431-48AE2605; Wed, 26 Sep 2012 11:44:04 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1348659843!32481095!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTE1NzQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 646 invoked from network); 26 Sep 2012 11:44:03 -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 Sep 2012 11:44:03 -0000
X-IronPort-AV: E=Sophos;i="4.80,490,1344211200"; d="scan'208";a="14774803"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Sep 2012 11:44: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.279.1;
	Wed, 26 Sep 2012 12:44:03 +0100
Message-ID: <1348659840.19176.31.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Date: Wed, 26 Sep 2012 12:44:00 +0100
In-Reply-To: <alpine.DEB.2.02.1209261225340.29232@kaball.uk.xensource.com>
References: <20120921121659.5a723de9@mantra.us.oracle.com>
	<alpine.DEB.2.02.1209241257440.29232@kaball.uk.xensource.com>
	<20120924154335.097d3fb9@mantra.us.oracle.com>
	<alpine.DEB.2.02.1209251054140.29232@kaball.uk.xensource.com>
	<20120925180416.0137d61a@mantra.us.oracle.com>
	<alpine.DEB.2.02.1209261225340.29232@kaball.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH v1 3/8]: PVH startup changes (enlighten.c)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-09-26 at 12:33 +0100, Stefano Stabellini wrote:
> On Wed, 26 Sep 2012, Mukesh Rathor wrote:
> > On Tue, 25 Sep 2012 11:03:13 +0100
> > Stefano Stabellini <stefano.stabellini@eu.citrix.com> wrote:
> > 
> > > On Mon, 24 Sep 2012, Mukesh Rathor wrote:
> > > > On Mon, 24 Sep 2012 13:07:19 +0100
> > > > Stefano Stabellini <stefano.stabellini@eu.citrix.com> wrote:
> > > > 
> > > > > On Fri, 21 Sep 2012, Mukesh Rathor wrote:
> > > > > > +		return;
> > > > > > +
> > > > > >  	if (!xen_feature(XENFEAT_auto_translated_physmap)) {
> > > > > >  		set_fixmap(FIX_PARAVIRT_BOOTMAP,
> > > > > >  			   xen_start_info->shared_info);
> > > > > >
> > > > > > @@ -1044,6 +1058,10 @@ void xen_setup_shared_info(void)
> > > > > >  		HYPERVISOR_shared_info =
> > > > > >  			(struct shared_info
> > > > > > *)__va(xen_start_info->shared_info); 
> > > > > > +	/* PVH TBD/FIXME: vcpu info placement in phase 2 */
> > > > > > +	if (xen_pvh_domain())
> > > > > > +		return;
> > > > > 
> > > > > It seems that if xen_initial_domain we always skip the
> > > > > initialization while if !xen_initial_domain we only initialize
> > > > > HYPERVISOR_shared_info. I don't understand why we have this
> > > > > difference.
> > > > 
> > > > The comment in xen_pvh_guest_init() explains it. For domU the
> > > > library maps the pfn at shared_info, ie, shared_info is pfn. For
> > > > dom0, it's the mfn. Dom0 then allocates a pfn via extend_brk, and
> > > > maps the mfn to it. This happens in the commond hvm code,
> > > > xen_hvm_init_shared_info().
> > > 
> > > This difference is really subtle, it would be nice to get rid of it.
> > > Could Xen allocate a pfn for dom0?
> > 
> > Not easily.
> > 
> > > Otherwise could we have the tools allocate an mfn instead of a pfn?
> > > In fact looking at xc_dom_x86.c, alloc_magic_pages is explicitly
> > > having a different behavior for xc_dom_feature_translated guests and
> > > allocates pfn instead of an mfn. Maybe we could get rid of that
> > > special case: less code in libxc, a common way of allocating the
> > > shared_info page for domU and dom0 => win.
> > 
> > Wish it was simple. But for PV and PVH, domU, it's already setup the 
> > shared page. All we need to do is __va(shared_info). But for HVM domUs 
> > and PVH dom0, we need to hcall with pfn to get it remapped.
> 
> For PVH domU is already setup as a pfn only because in
> tools/libxc/xc_dom_x86.c:alloc_magic_pages we have this code:
> 
>     if ( xc_dom_feature_translated(dom) )
>         dom->shared_info_pfn = xc_dom_alloc_page(dom, "shared info");
> 
> and in tools/libxc/xc_dom_x86.c:start_info_x86_64 we have:
> 
>     xen_pfn_t shinfo =
>         xc_dom_feature_translated(dom) ? dom->shared_info_pfn : dom->
>         shared_info_mfn;
> 
> if we simply get rid of the two "if xc_dom_feature_translated(dom)"
> wouldn't we get an mfn for PVH domU too? AFAICT all the other cases would
> remain unmodified, but PVH domU would start getting an mfn for shared_info.

The other option would be to have the hypervisor side builder for a PVH
dom0 add an entry to the P2M for the shared info as well. Arguably that
would be more PV like and therefore the correct thing for a PVH guest
since it makes the shared info immediately available to the dom0.

> > Changing the
> > tool to map pfn, would result in unnecessary hcall for all PV and PVH
> > domUs. It's only two lines of code, so lets just leave it. I'll make the
> > comment better.
> 
> Yes, there would be one more unnecessary hypercall but we would get rid
> of 4 "if". I think is a good trade off.

Certainly minimising the numbers of hypercalls is not the most important
thing in a code path which is run once at start of day.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 26 11:47:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Sep 2012 11:47: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 1TGq51-0001gU-2X; Wed, 26 Sep 2012 11:47:03 +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 1TGq4z-0001gN-Jp
	for xen-devel@lists.xensource.com; Wed, 26 Sep 2012 11:47:02 +0000
Received: from [85.158.139.211:37224] by server-11.bemta-5.messagelabs.com id
	7E/B4-13866-43BE2605; Wed, 26 Sep 2012 11:47:00 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-14.tower-206.messagelabs.com!1348660020!19969029!1
X-Originating-IP: [74.125.83.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7442 invoked from network); 26 Sep 2012 11:47:00 -0000
Received: from mail-ee0-f43.google.com (HELO mail-ee0-f43.google.com)
	(74.125.83.43)
	by server-14.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Sep 2012 11:47:00 -0000
Received: by eekc13 with SMTP id c13so259623eek.30
	for <xen-devel@lists.xensource.com>;
	Wed, 26 Sep 2012 04:47: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=DfS//R86l+VkAvBKRIn6s/Cp6qA/hob/k72RyP9v4QA=;
	b=fopGHT8VXU4L8j/LlT/MpDbI/IihcuFB5+LCw6MPnLWvbL4UamNTpU+JFxyg6F5Tsf
	XRIROGZ3ryGOXuE6OXnn24bn8Y29gKz6CmUktK4nDKHtXPTAXQjV/SYHhguEl2oFm/r2
	UKml0Lhfd7PoZSIJxDGVKjAcOfV5GXWkOpJAqN8iVn62gpOqaPCV3M+MskQ0hq1lNzXa
	lVowM6GdnOSHqS4n/pPUNtb+bFlP0XRJePhDd+ZuHnfvk6HpgO3I9Umf3nLZ/7nIuklm
	RAWVjbtEtjaxLAnW/EOlrF8AupUMZcL1BO1Iv/f8MtVDRdcpgE+PdJxHh1Ri8kj+9ImK
	46Nw==
MIME-Version: 1.0
Received: by 10.14.4.201 with SMTP id 49mr503725eej.0.1348660020009; Wed, 26
	Sep 2012 04:47:00 -0700 (PDT)
Received: by 10.14.215.195 with HTTP; Wed, 26 Sep 2012 04:46:59 -0700 (PDT)
In-Reply-To: <5061D2CC.3030108@jhuapl.edu>
References: <50576368.3070007@jhuapl.edu>
	<1347953926.25803.89.camel@dagon.hellion.org.uk>
	<5058B07C.1070404@jhuapl.edu>
	<1348566822.3452.151.camel@zakaz.uk.xensource.com>
	<5061D2CC.3030108@jhuapl.edu>
Date: Wed, 26 Sep 2012 12:46:59 +0100
X-Google-Sender-Auth: H8Hl4QybIitWyHNDB1VLfXQHzdc
Message-ID: <CAFLBxZYh69025_LHq2qWfQMotincb_pvDtCtiAa7sXCg-RQL6A@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH] Upgrade vtpmd to berlios version 0.7.4
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Sep 25, 2012 at 4:50 PM, Matthew Fioravante
<matthew.fioravante@jhuapl.edu> wrote:
> I don't know if there is anyone who would want to still use vtpms as
> processes when the stub domains are now available. Security research
> people like the domain model because it guarantees a better separation
> of components guaranteed by the hypervisor and doesn't have to trust the
> dom0 OS.
>
> If we got rid of the process and hybrid model, then the
> tools/vtpm_manager code that is still used could be moved into the
> vtpmmgrdom stubdom codebase. tools/vtpm could be completely removed
> along with the --enable-vtpm stuff in the configure script and the cmake
> dependency.

I haven't had a chance to look at your patches in detail (because the
few I've looked at have whitespace damage that Ian mentioned before),
but I as long as the user interface (via xl, config files, &c) is the
same, or comparable, I don't see any reason not to move entirely over
the stubdom model; especially if the process or hybrid models are not
being tested or maintained.

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 26 11:47:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Sep 2012 11:47: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 1TGq51-0001gU-2X; Wed, 26 Sep 2012 11:47:03 +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 1TGq4z-0001gN-Jp
	for xen-devel@lists.xensource.com; Wed, 26 Sep 2012 11:47:02 +0000
Received: from [85.158.139.211:37224] by server-11.bemta-5.messagelabs.com id
	7E/B4-13866-43BE2605; Wed, 26 Sep 2012 11:47:00 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-14.tower-206.messagelabs.com!1348660020!19969029!1
X-Originating-IP: [74.125.83.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7442 invoked from network); 26 Sep 2012 11:47:00 -0000
Received: from mail-ee0-f43.google.com (HELO mail-ee0-f43.google.com)
	(74.125.83.43)
	by server-14.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Sep 2012 11:47:00 -0000
Received: by eekc13 with SMTP id c13so259623eek.30
	for <xen-devel@lists.xensource.com>;
	Wed, 26 Sep 2012 04:47: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=DfS//R86l+VkAvBKRIn6s/Cp6qA/hob/k72RyP9v4QA=;
	b=fopGHT8VXU4L8j/LlT/MpDbI/IihcuFB5+LCw6MPnLWvbL4UamNTpU+JFxyg6F5Tsf
	XRIROGZ3ryGOXuE6OXnn24bn8Y29gKz6CmUktK4nDKHtXPTAXQjV/SYHhguEl2oFm/r2
	UKml0Lhfd7PoZSIJxDGVKjAcOfV5GXWkOpJAqN8iVn62gpOqaPCV3M+MskQ0hq1lNzXa
	lVowM6GdnOSHqS4n/pPUNtb+bFlP0XRJePhDd+ZuHnfvk6HpgO3I9Umf3nLZ/7nIuklm
	RAWVjbtEtjaxLAnW/EOlrF8AupUMZcL1BO1Iv/f8MtVDRdcpgE+PdJxHh1Ri8kj+9ImK
	46Nw==
MIME-Version: 1.0
Received: by 10.14.4.201 with SMTP id 49mr503725eej.0.1348660020009; Wed, 26
	Sep 2012 04:47:00 -0700 (PDT)
Received: by 10.14.215.195 with HTTP; Wed, 26 Sep 2012 04:46:59 -0700 (PDT)
In-Reply-To: <5061D2CC.3030108@jhuapl.edu>
References: <50576368.3070007@jhuapl.edu>
	<1347953926.25803.89.camel@dagon.hellion.org.uk>
	<5058B07C.1070404@jhuapl.edu>
	<1348566822.3452.151.camel@zakaz.uk.xensource.com>
	<5061D2CC.3030108@jhuapl.edu>
Date: Wed, 26 Sep 2012 12:46:59 +0100
X-Google-Sender-Auth: H8Hl4QybIitWyHNDB1VLfXQHzdc
Message-ID: <CAFLBxZYh69025_LHq2qWfQMotincb_pvDtCtiAa7sXCg-RQL6A@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH] Upgrade vtpmd to berlios version 0.7.4
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Sep 25, 2012 at 4:50 PM, Matthew Fioravante
<matthew.fioravante@jhuapl.edu> wrote:
> I don't know if there is anyone who would want to still use vtpms as
> processes when the stub domains are now available. Security research
> people like the domain model because it guarantees a better separation
> of components guaranteed by the hypervisor and doesn't have to trust the
> dom0 OS.
>
> If we got rid of the process and hybrid model, then the
> tools/vtpm_manager code that is still used could be moved into the
> vtpmmgrdom stubdom codebase. tools/vtpm could be completely removed
> along with the --enable-vtpm stuff in the configure script and the cmake
> dependency.

I haven't had a chance to look at your patches in detail (because the
few I've looked at have whitespace damage that Ian mentioned before),
but I as long as the user interface (via xl, config files, &c) is the
same, or comparable, I don't see any reason not to move entirely over
the stubdom model; especially if the process or hybrid models are not
being tested or maintained.

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 26 11:47:17 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Sep 2012 11:47:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGq52-0001gl-El; Wed, 26 Sep 2012 11:47:04 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1TGq51-0001gT-6N
	for xen-devel@lists.xensource.com; Wed, 26 Sep 2012 11:47:03 +0000
Received: from [85.158.138.51:51785] by server-13.bemta-3.messagelabs.com id
	88/3A-11249-63BE2605; Wed, 26 Sep 2012 11:47:02 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1348660021!23154836!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTE1NzQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5024 invoked from network); 26 Sep 2012 11:47:02 -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;
	26 Sep 2012 11:47:02 -0000
X-IronPort-AV: E=Sophos;i="4.80,490,1344211200"; d="scan'208";a="14774868"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Sep 2012 11:47:01 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Wed, 26 Sep 2012 12:47:01 +0100
Date: Wed, 26 Sep 2012 12:46:18 +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.1209261241410.29232@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 v2] libxl/qemu-xen: use cache=writeback for IDE
	and SCSI
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 caching mode from writethrough to writeback for upstream QEMU.

After a lengthy discussion, we came up with the conclusion that
WRITEBACK is OK for IDE.
See: http://marc.info/?l=xen-devel&m=133311527009773

Given that the same reasons apply to SCSI as well, change to writeback
for SCSI too.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

---


diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
index 0c0084f..7662b3d 100644
--- a/tools/libxl/libxl_dm.c
+++ b/tools/libxl/libxl_dm.c
@@ -549,10 +549,10 @@ static char ** libxl__build_device_model_args_new(libxl__gc *gc,
             if (disks[i].is_cdrom) {
                 if (disks[i].format == LIBXL_DISK_FORMAT_EMPTY)
                     drive = libxl__sprintf
-                        (gc, "if=ide,index=%d,media=cdrom", disk);
+                        (gc, "if=ide,index=%d,media=cdrom,cache=writeback", disk);
                 else
                     drive = libxl__sprintf
-                        (gc, "file=%s,if=ide,index=%d,media=cdrom,format=%s",
+                        (gc, "file=%s,if=ide,index=%d,media=cdrom,format=%s,cache=writeback",
                          disks[i].pdev_path, disk, format);
             } else {
                 if (disks[i].format == LIBXL_DISK_FORMAT_EMPTY) {
@@ -575,11 +575,11 @@ static char ** libxl__build_device_model_args_new(libxl__gc *gc,
                  */
                 if (strncmp(disks[i].vdev, "sd", 2) == 0)
                     drive = libxl__sprintf
-                        (gc, "file=%s,if=scsi,bus=0,unit=%d,format=%s",
+                        (gc, "file=%s,if=scsi,bus=0,unit=%d,format=%s,cache=writeback",
                          disks[i].pdev_path, disk, format);
                 else if (disk < 4)
                     drive = libxl__sprintf
-                        (gc, "file=%s,if=ide,index=%d,media=disk,format=%s",
+                        (gc, "file=%s,if=ide,index=%d,media=disk,format=%s,cache=writeback",
                          disks[i].pdev_path, disk, format);
                 else
                     continue; /* Do not emulate this disk */

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 26 11:47:17 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Sep 2012 11:47:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGq52-0001gl-El; Wed, 26 Sep 2012 11:47:04 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1TGq51-0001gT-6N
	for xen-devel@lists.xensource.com; Wed, 26 Sep 2012 11:47:03 +0000
Received: from [85.158.138.51:51785] by server-13.bemta-3.messagelabs.com id
	88/3A-11249-63BE2605; Wed, 26 Sep 2012 11:47:02 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1348660021!23154836!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTE1NzQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5024 invoked from network); 26 Sep 2012 11:47:02 -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;
	26 Sep 2012 11:47:02 -0000
X-IronPort-AV: E=Sophos;i="4.80,490,1344211200"; d="scan'208";a="14774868"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Sep 2012 11:47:01 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Wed, 26 Sep 2012 12:47:01 +0100
Date: Wed, 26 Sep 2012 12:46:18 +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.1209261241410.29232@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 v2] libxl/qemu-xen: use cache=writeback for IDE
	and SCSI
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 caching mode from writethrough to writeback for upstream QEMU.

After a lengthy discussion, we came up with the conclusion that
WRITEBACK is OK for IDE.
See: http://marc.info/?l=xen-devel&m=133311527009773

Given that the same reasons apply to SCSI as well, change to writeback
for SCSI too.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

---


diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
index 0c0084f..7662b3d 100644
--- a/tools/libxl/libxl_dm.c
+++ b/tools/libxl/libxl_dm.c
@@ -549,10 +549,10 @@ static char ** libxl__build_device_model_args_new(libxl__gc *gc,
             if (disks[i].is_cdrom) {
                 if (disks[i].format == LIBXL_DISK_FORMAT_EMPTY)
                     drive = libxl__sprintf
-                        (gc, "if=ide,index=%d,media=cdrom", disk);
+                        (gc, "if=ide,index=%d,media=cdrom,cache=writeback", disk);
                 else
                     drive = libxl__sprintf
-                        (gc, "file=%s,if=ide,index=%d,media=cdrom,format=%s",
+                        (gc, "file=%s,if=ide,index=%d,media=cdrom,format=%s,cache=writeback",
                          disks[i].pdev_path, disk, format);
             } else {
                 if (disks[i].format == LIBXL_DISK_FORMAT_EMPTY) {
@@ -575,11 +575,11 @@ static char ** libxl__build_device_model_args_new(libxl__gc *gc,
                  */
                 if (strncmp(disks[i].vdev, "sd", 2) == 0)
                     drive = libxl__sprintf
-                        (gc, "file=%s,if=scsi,bus=0,unit=%d,format=%s",
+                        (gc, "file=%s,if=scsi,bus=0,unit=%d,format=%s,cache=writeback",
                          disks[i].pdev_path, disk, format);
                 else if (disk < 4)
                     drive = libxl__sprintf
-                        (gc, "file=%s,if=ide,index=%d,media=disk,format=%s",
+                        (gc, "file=%s,if=ide,index=%d,media=disk,format=%s,cache=writeback",
                          disks[i].pdev_path, disk, format);
                 else
                     continue; /* Do not emulate this disk */

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 26 11:49:01 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Sep 2012 11:49:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGq6j-0001s5-VA; Wed, 26 Sep 2012 11: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 1TGq6i-0001rq-B9
	for xen-devel@lists.xen.org; Wed, 26 Sep 2012 11:48:48 +0000
Received: from [85.158.139.83:55515] by server-2.bemta-5.messagelabs.com id
	27/D2-28944-F9BE2605; Wed, 26 Sep 2012 11:48:47 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1348660127!24980096!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27395 invoked from network); 26 Sep 2012 11:48:47 -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;
	26 Sep 2012 11:48:47 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 26 Sep 2012 12:48:45 +0100
Message-Id: <506307D4020000780009DF8A@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 26 Sep 2012 12:49:08 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ben Guthro" <ben@guthro.net>
References: <CAOvdn6UCF2A3yP1cqWn=dxwr0ayRbr+rg+xj8META9Dm0+CoNw@mail.gmail.com>
	<CC868168.3FD29%keir.xen@gmail.com>
	<CAOvdn6U-JyLvt96gkLkqzi088tU9_ktv4D+fkJac_BKVe05Y-w@mail.gmail.com>
	<CAOvdn6V+s3AbRzsu8VArbmrZou=im9SqvPf-9Wpif_BrNMv=yg@mail.gmail.com>
	<50617297020000780009D8AA@nat28.tlf.novell.com>
	<CAOvdn6Vsnbcd7m8mh3tSgn3KaEoeiOyVD1mr3uQ3bN=rF=pDUQ@mail.gmail.com>
	<CAOvdn6X6_NwfTNTgwNG7CQOqu2oDb6o6r1Zf+5y0cwZGLKToxA@mail.gmail.com>
	<5061E599020000780009DBA4@nat28.tlf.novell.com>
	<CAOvdn6UqKqOfn7U-q6BCPF3UcMRO9J-R+Po62eEjfWh3APoSjg@mail.gmail.com>
In-Reply-To: <CAOvdn6UqKqOfn7U-q6BCPF3UcMRO9J-R+Po62eEjfWh3APoSjg@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Keir Fraser <keir.xen@gmail.com>, John Baboval <john.baboval@citrix.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen4.2 S3 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 25.09.12 at 17:45, Ben Guthro <ben@guthro.net> wrote:
> On Tue, Sep 25, 2012 at 11:10 AM, Jan Beulich <JBeulich@suse.com> wrote:
>> >>> On 25.09.12 at 16:22, Ben Guthro <ben@guthro.net> wrote:
>> > I went back to an old patch that had, since it was in this same function
>> > that you made reference to:
>> > http://markmail.org/message/qpnmiqzt5bngeejk 
>> >
>> > I noticed that I was not seeing the "Breaking vcpu affinity" printk - so
>> > I tried to get that
>> >
>> > The change proposed in that thread seems to work around this pinning
>> > problem.
>> > However, I'm not sure that it is the "right thing" to be doing.
>>
>> As said back then, the original change looks a little suspicious,
>> and hence reverting it is certainly to be considered.
> 
> Which is one of the reasons I brought it up again.

So could you then do what I suggested back then - make a copy
of the two involved CPU masks (*online and *vc->cpu_affinity)
plus vc->domain->cpupool, vc->processor, and vc->vcpu_id into
on-stack variables (ensuring they don't get eliminated by the
compiler, e.g. by adding a read access anywhere after the
triggering ASSERT())?

Then the source change (i.e. the data layout) available, either
together with the xen-syms, or put them into a structure
together with some magic ID to identify where in the stack dump
the interesting bits are.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 26 11:49:01 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Sep 2012 11:49:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGq6j-0001s5-VA; Wed, 26 Sep 2012 11: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 1TGq6i-0001rq-B9
	for xen-devel@lists.xen.org; Wed, 26 Sep 2012 11:48:48 +0000
Received: from [85.158.139.83:55515] by server-2.bemta-5.messagelabs.com id
	27/D2-28944-F9BE2605; Wed, 26 Sep 2012 11:48:47 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1348660127!24980096!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27395 invoked from network); 26 Sep 2012 11:48:47 -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;
	26 Sep 2012 11:48:47 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 26 Sep 2012 12:48:45 +0100
Message-Id: <506307D4020000780009DF8A@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 26 Sep 2012 12:49:08 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ben Guthro" <ben@guthro.net>
References: <CAOvdn6UCF2A3yP1cqWn=dxwr0ayRbr+rg+xj8META9Dm0+CoNw@mail.gmail.com>
	<CC868168.3FD29%keir.xen@gmail.com>
	<CAOvdn6U-JyLvt96gkLkqzi088tU9_ktv4D+fkJac_BKVe05Y-w@mail.gmail.com>
	<CAOvdn6V+s3AbRzsu8VArbmrZou=im9SqvPf-9Wpif_BrNMv=yg@mail.gmail.com>
	<50617297020000780009D8AA@nat28.tlf.novell.com>
	<CAOvdn6Vsnbcd7m8mh3tSgn3KaEoeiOyVD1mr3uQ3bN=rF=pDUQ@mail.gmail.com>
	<CAOvdn6X6_NwfTNTgwNG7CQOqu2oDb6o6r1Zf+5y0cwZGLKToxA@mail.gmail.com>
	<5061E599020000780009DBA4@nat28.tlf.novell.com>
	<CAOvdn6UqKqOfn7U-q6BCPF3UcMRO9J-R+Po62eEjfWh3APoSjg@mail.gmail.com>
In-Reply-To: <CAOvdn6UqKqOfn7U-q6BCPF3UcMRO9J-R+Po62eEjfWh3APoSjg@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Keir Fraser <keir.xen@gmail.com>, John Baboval <john.baboval@citrix.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen4.2 S3 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 25.09.12 at 17:45, Ben Guthro <ben@guthro.net> wrote:
> On Tue, Sep 25, 2012 at 11:10 AM, Jan Beulich <JBeulich@suse.com> wrote:
>> >>> On 25.09.12 at 16:22, Ben Guthro <ben@guthro.net> wrote:
>> > I went back to an old patch that had, since it was in this same function
>> > that you made reference to:
>> > http://markmail.org/message/qpnmiqzt5bngeejk 
>> >
>> > I noticed that I was not seeing the "Breaking vcpu affinity" printk - so
>> > I tried to get that
>> >
>> > The change proposed in that thread seems to work around this pinning
>> > problem.
>> > However, I'm not sure that it is the "right thing" to be doing.
>>
>> As said back then, the original change looks a little suspicious,
>> and hence reverting it is certainly to be considered.
> 
> Which is one of the reasons I brought it up again.

So could you then do what I suggested back then - make a copy
of the two involved CPU masks (*online and *vc->cpu_affinity)
plus vc->domain->cpupool, vc->processor, and vc->vcpu_id into
on-stack variables (ensuring they don't get eliminated by the
compiler, e.g. by adding a read access anywhere after the
triggering ASSERT())?

Then the source change (i.e. the data layout) available, either
together with the xen-syms, or put them into a structure
together with some magic ID to identify where in the stack dump
the interesting bits are.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 26 11:56:52 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Sep 2012 11: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 1TGqEI-0002A1-Tc; Wed, 26 Sep 2012 11:56:38 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ketuzsezr@gmail.com>) id 1TGqEH-00029w-Nc
	for xen-devel@lists.xen.org; Wed, 26 Sep 2012 11:56:37 +0000
Received: from [85.158.143.99:55605] by server-1.bemta-4.messagelabs.com id
	C6/CE-05684-57DE2605; Wed, 26 Sep 2012 11:56:37 +0000
X-Env-Sender: ketuzsezr@gmail.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1348660594!30925907!1
X-Originating-IP: [209.85.216.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8152 invoked from network); 26 Sep 2012 11:56:35 -0000
Received: from mail-qc0-f173.google.com (HELO mail-qc0-f173.google.com)
	(209.85.216.173)
	by server-13.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Sep 2012 11:56:35 -0000
Received: by qcab12 with SMTP id b12so445026qca.32
	for <xen-devel@lists.xen.org>; Wed, 26 Sep 2012 04:56:34 -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:content-transfer-encoding
	:in-reply-to:user-agent;
	bh=grYEpSCIpC60tlp6hcx6GeO4FvDRsf2t3Xvwo+r/R3A=;
	b=rbqA/7SKdlmsC0mQYEi4TjD4rU1O96ymYtTz6SrRs9nuvKYt7QP/sKE13VGw+XkNOI
	MUfOYoZE8Ytqw00MerI+btEoTzgy18nyE7irL8EzYPRcW/7fBrBhNo21N5lL7Cn+HV5B
	N22fjThQHBnFk/5ZbcDzfk+jzP1GWvDkQCYvPPXf9W7vavIpsVsYzE0M1N/WmuKPLqiN
	/Hy++DK6w3btYFx99W/Hb+Co/x7I/9wCDiTVzBd1Cp0YxLlyx2s6S/HXFHO2Fp2JWMRb
	nfiNsUZYPTimQPBcnbtpeUcK1uAIirKEeE/m372DUQdDMsZ8t0D7FzfiNhN1gufc9J75
	RsJQ==
Received: by 10.224.181.70 with SMTP id bx6mr1370301qab.79.1348660593919;
	Wed, 26 Sep 2012 04:56:33 -0700 (PDT)
Received: from phenom.dumpdata.com
	(50-195-21-189-static.hfc.comcastbusiness.net. [50.195.21.189])
	by mx.google.com with ESMTPS id ca8sm4479932qab.20.2012.09.26.04.56.32
	(version=TLSv1/SSLv3 cipher=OTHER);
	Wed, 26 Sep 2012 04:56:33 -0700 (PDT)
Date: Wed, 26 Sep 2012 07:45:15 -0400
From: Konrad Rzeszutek Wilk <konrad@kernel.org>
To: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
Message-ID: <20120926114514.GB7356@phenom.dumpdata.com>
References: <CALCpXpCvGkjZyG-NOY+fZY0q0f_DxuwPNEnxwKXVhjOe=gcHSQ@mail.gmail.com>
	<20120925140421.GA16478@phenom.dumpdata.com>
	<20120925153445.GN8912@reaktio.net>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120925153445.GN8912@reaktio.net>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] usbpassthrough of xen-4.1.2 update / Qemu-dm
 PulseAudio/Alsa 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 Tue, Sep 25, 2012 at 06:34:45PM +0300, Pasi K=E4rkk=E4inen wrote:
> On Tue, Sep 25, 2012 at 10:04:22AM -0400, Konrad Rzeszutek Wilk wrote:
> >
> > # Remember QEMU_AUDIO_DRV=3Dpa
> > soundhw=3D'es1370'
> >
> =

> Hey,
> =

> This reminds me.. is qemu-dm (traditional) automatically compiled with Pu=
lseAudio support enabled these days? =


Not that I know off. I had to enable it it my makefile/configure script.

But the other thing is that is a pain in the butt to work right.
You have to (as root) set these:

export PULSE_SERVER=3D192.168.101.16
export QEMU_AUDIO_DRV=3Dpa

so that qemu-dm knows to use PA, and that PA knows where to send data.

And then on the client side (so ~/.pulse/default):
load-module module-native-protocol-tcp auth-ip-acl=3D192.168.101.0/24
and then also open a firewall port for it on the client side.

The GSOC work that was done to make a PulseAudio client for PV guests
was more promising - as it would automatically configure the host/client
(if they were running on the same machine). Granted it meant you had
to install some extra-third party under Windows. But it is not ready.

> How about Alsa support? =


Hadn't tried it. I thought that ALSA has gone out of favour and
PulseAudio is the new king?
> =

> Or do we need Makefile tweaks before building Xen/Qemu..


This was the only modification to the ioemu I had to do:
 =

diff --git a/xen-setup b/xen-setup
index c3af79b..f674ba8 100755
--- a/xen-setup
+++ b/xen-setup
@@ -18,7 +18,7 @@ if test -z "${XEN_SCRIPT_DIR}"; then
 	XEN_SCRIPT_DIR=3D"/etc/xen/scripts"
 fi
 =

-${QEMU_ROOT:-.}/configure --disable-gfx-check --disable-curses --disable-s=
lirp "$@" --prefix=3D${PREFIX}
+${QEMU_ROOT:-.}/configure --disable-gfx-check --disable-curses --disable-s=
lirp "$@" --prefix=3D${PREFIX} --audio-drv-list=3Dpa
 =

 if [ "x$XEN_ROOT" !=3D x ]; then
 	echo "XEN_ROOT=3D$XEN_ROOT" >>config-host.mak


The sound quality is not perfect - but when I play Left4Dead under Win7
(with PCI passthrough of a network card and radeon GPU) the moans
of zombies as they get whacked by my baseball is satisfyingly enough.

> -- Pasi
> =

> =

> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Sep 26 11:56:52 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Sep 2012 11: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 1TGqEI-0002A1-Tc; Wed, 26 Sep 2012 11:56:38 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ketuzsezr@gmail.com>) id 1TGqEH-00029w-Nc
	for xen-devel@lists.xen.org; Wed, 26 Sep 2012 11:56:37 +0000
Received: from [85.158.143.99:55605] by server-1.bemta-4.messagelabs.com id
	C6/CE-05684-57DE2605; Wed, 26 Sep 2012 11:56:37 +0000
X-Env-Sender: ketuzsezr@gmail.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1348660594!30925907!1
X-Originating-IP: [209.85.216.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8152 invoked from network); 26 Sep 2012 11:56:35 -0000
Received: from mail-qc0-f173.google.com (HELO mail-qc0-f173.google.com)
	(209.85.216.173)
	by server-13.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Sep 2012 11:56:35 -0000
Received: by qcab12 with SMTP id b12so445026qca.32
	for <xen-devel@lists.xen.org>; Wed, 26 Sep 2012 04:56:34 -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:content-transfer-encoding
	:in-reply-to:user-agent;
	bh=grYEpSCIpC60tlp6hcx6GeO4FvDRsf2t3Xvwo+r/R3A=;
	b=rbqA/7SKdlmsC0mQYEi4TjD4rU1O96ymYtTz6SrRs9nuvKYt7QP/sKE13VGw+XkNOI
	MUfOYoZE8Ytqw00MerI+btEoTzgy18nyE7irL8EzYPRcW/7fBrBhNo21N5lL7Cn+HV5B
	N22fjThQHBnFk/5ZbcDzfk+jzP1GWvDkQCYvPPXf9W7vavIpsVsYzE0M1N/WmuKPLqiN
	/Hy++DK6w3btYFx99W/Hb+Co/x7I/9wCDiTVzBd1Cp0YxLlyx2s6S/HXFHO2Fp2JWMRb
	nfiNsUZYPTimQPBcnbtpeUcK1uAIirKEeE/m372DUQdDMsZ8t0D7FzfiNhN1gufc9J75
	RsJQ==
Received: by 10.224.181.70 with SMTP id bx6mr1370301qab.79.1348660593919;
	Wed, 26 Sep 2012 04:56:33 -0700 (PDT)
Received: from phenom.dumpdata.com
	(50-195-21-189-static.hfc.comcastbusiness.net. [50.195.21.189])
	by mx.google.com with ESMTPS id ca8sm4479932qab.20.2012.09.26.04.56.32
	(version=TLSv1/SSLv3 cipher=OTHER);
	Wed, 26 Sep 2012 04:56:33 -0700 (PDT)
Date: Wed, 26 Sep 2012 07:45:15 -0400
From: Konrad Rzeszutek Wilk <konrad@kernel.org>
To: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
Message-ID: <20120926114514.GB7356@phenom.dumpdata.com>
References: <CALCpXpCvGkjZyG-NOY+fZY0q0f_DxuwPNEnxwKXVhjOe=gcHSQ@mail.gmail.com>
	<20120925140421.GA16478@phenom.dumpdata.com>
	<20120925153445.GN8912@reaktio.net>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120925153445.GN8912@reaktio.net>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] usbpassthrough of xen-4.1.2 update / Qemu-dm
 PulseAudio/Alsa 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 Tue, Sep 25, 2012 at 06:34:45PM +0300, Pasi K=E4rkk=E4inen wrote:
> On Tue, Sep 25, 2012 at 10:04:22AM -0400, Konrad Rzeszutek Wilk wrote:
> >
> > # Remember QEMU_AUDIO_DRV=3Dpa
> > soundhw=3D'es1370'
> >
> =

> Hey,
> =

> This reminds me.. is qemu-dm (traditional) automatically compiled with Pu=
lseAudio support enabled these days? =


Not that I know off. I had to enable it it my makefile/configure script.

But the other thing is that is a pain in the butt to work right.
You have to (as root) set these:

export PULSE_SERVER=3D192.168.101.16
export QEMU_AUDIO_DRV=3Dpa

so that qemu-dm knows to use PA, and that PA knows where to send data.

And then on the client side (so ~/.pulse/default):
load-module module-native-protocol-tcp auth-ip-acl=3D192.168.101.0/24
and then also open a firewall port for it on the client side.

The GSOC work that was done to make a PulseAudio client for PV guests
was more promising - as it would automatically configure the host/client
(if they were running on the same machine). Granted it meant you had
to install some extra-third party under Windows. But it is not ready.

> How about Alsa support? =


Hadn't tried it. I thought that ALSA has gone out of favour and
PulseAudio is the new king?
> =

> Or do we need Makefile tweaks before building Xen/Qemu..


This was the only modification to the ioemu I had to do:
 =

diff --git a/xen-setup b/xen-setup
index c3af79b..f674ba8 100755
--- a/xen-setup
+++ b/xen-setup
@@ -18,7 +18,7 @@ if test -z "${XEN_SCRIPT_DIR}"; then
 	XEN_SCRIPT_DIR=3D"/etc/xen/scripts"
 fi
 =

-${QEMU_ROOT:-.}/configure --disable-gfx-check --disable-curses --disable-s=
lirp "$@" --prefix=3D${PREFIX}
+${QEMU_ROOT:-.}/configure --disable-gfx-check --disable-curses --disable-s=
lirp "$@" --prefix=3D${PREFIX} --audio-drv-list=3Dpa
 =

 if [ "x$XEN_ROOT" !=3D x ]; then
 	echo "XEN_ROOT=3D$XEN_ROOT" >>config-host.mak


The sound quality is not perfect - but when I play Left4Dead under Win7
(with PCI passthrough of a network card and radeon GPU) the moans
of zombies as they get whacked by my baseball is satisfyingly enough.

> -- Pasi
> =

> =

> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Sep 26 12:00:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Sep 2012 12:00: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 1TGqHX-0002IH-Q1; Wed, 26 Sep 2012 11:59:59 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ketuzsezr@gmail.com>) id 1TGqHW-0002IC-Hh
	for xen-devel@lists.xen.org; Wed, 26 Sep 2012 11:59:58 +0000
Received: from [85.158.138.51:16137] by server-13.bemta-3.messagelabs.com id
	CB/10-11249-D3EE2605; Wed, 26 Sep 2012 11:59:57 +0000
X-Env-Sender: ketuzsezr@gmail.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1348660795!24435451!1
X-Originating-IP: [209.85.216.52]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14562 invoked from network); 26 Sep 2012 11:59:56 -0000
Received: from mail-qa0-f52.google.com (HELO mail-qa0-f52.google.com)
	(209.85.216.52)
	by server-10.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Sep 2012 11:59:56 -0000
Received: by qabg24 with SMTP id g24so1079305qab.11
	for <xen-devel@lists.xen.org>; Wed, 26 Sep 2012 04:59:55 -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=YxhtoKYgJa6Nl4B2Phxc09eSXkOTokvWCQ3v73KPm1Y=;
	b=PT34RcrTDh/kXgsaNN6EYeRZkh57nNrDg4qXyDOol90VBb0vGczQnR4s2yFk4vnb1q
	M3ew9qmYdSPzdjRbvak8xPevJTEZV2neXK2S5ylgWjzfiYZfSHEvdl3mz2xAWEVOoATY
	z3zKEhw2DMqjvzK7mjG8b5MFCukbm7GJgzOQqfYxyuePd8QwumVEtY8spbbj+cX+LQAK
	7oayZiNNnAt9sDGvztDTCJHrdJ2nV2d4vINvZDmu2L1Pj3mdwcF/mkiqarlBKsDcUZhc
	9ofL5Y+MOkHYvWmTNWeVxK4vQAEGQMcSRayNeDG4KmwTJ6d0pVZD2j+emn5KXMU9dYZE
	ECHA==
Received: by 10.224.9.9 with SMTP id j9mr1510363qaj.32.1348660795646;
	Wed, 26 Sep 2012 04:59:55 -0700 (PDT)
Received: from phenom.dumpdata.com
	(50-195-21-189-static.hfc.comcastbusiness.net. [50.195.21.189])
	by mx.google.com with ESMTPS id fl3sm4499343qab.3.2012.09.26.04.59.54
	(version=TLSv1/SSLv3 cipher=OTHER);
	Wed, 26 Sep 2012 04:59:55 -0700 (PDT)
Date: Wed, 26 Sep 2012 07:48:37 -0400
From: Konrad Rzeszutek Wilk <konrad@kernel.org>
To: Qian Hu <qianhu2011@gmail.com>
Message-ID: <20120926114836.GC7356@phenom.dumpdata.com>
References: <CALCpXpCvGkjZyG-NOY+fZY0q0f_DxuwPNEnxwKXVhjOe=gcHSQ@mail.gmail.com>
	<20120925140421.GA16478@phenom.dumpdata.com>
	<CALCpXpBJj23e3j_W4Mf2CJ57NSgx2YvnFMdB-0NgaJ=Wgvf60w@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CALCpXpBJj23e3j_W4Mf2CJ57NSgx2YvnFMdB-0NgaJ=Wgvf60w@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] usbpassthrough of xen-4.1.2 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, Sep 26, 2012 at 04:39:22PM +0800, Qian Hu wrote:
> I am sorry what does the re-assign mean? By the way, where can I find the

Please do not top-post.

> ID C408 0040?

<sigh> That is my mouse. Yours would be different of course. It was
an example of what you need to do.
> 
> It seems not to be the message listed by "lsusb".
> 
> Below is my config file, similar with yours.
> 
> import os, re
> arch = os.uname()[4]
> if re.search('64', arch):
>    arch_libdir = 'lib64'
> else:
>   arch_libdir = 'lib'
> 
> name = "win7"
> builder = "hvm"
> memory = "1024"
> disk = [ 'file:/root/win7.img,hda,w',
> #         'file:/mnt/win7.iso,hdc:cdrom,r',
>         ]
> vif = [ 'type=ioemu, mac=00:16:3e:3f:74:01 , bridge=eth0  ,model=e1000', ]
> uuid = "11111111-2262-28d2-9b64-b11713adfb20"
> device_model = "/home/root1/xen/xen-4.1.2/tools/ioemu-dir/i386-dm/qemu-dm"
> kernel = "/usr/lib/xen/boot/hvmloader"
> vnc=1
> vnclisten="0.0.0.0"
> vncdisplay=0
> apic=1
> acpi=1
> pae=1
> boot="dc"
> vcpus=2
> serial = "pty"
> on_reboot='restart'
> on_crash='restart'
> dhcp='off'
> stdvga=0
> audio=1
> soundhw='es1370'
> videoram=16
> usb=1
> usb_add='host:0204:6025'
> usbdevice='tablet'
> 
> 
> 
> 2012/9/25 Konrad Rzeszutek Wilk <konrad@kernel.org>
> 
> > On Tue, Sep 25, 2012 at 11:17:03AM +0800, Qian Hu wrote:
> > > Hi, everyone! The same question with updated message.
> > >
> > > I am working on the USB passthrough of Xen-4.1.2. My host OS  is Fedora
> > 14
> > > and the guest OS is win7.
> > >
> > > According to the wiki page(http://wiki.xen.org/wiki/Xen_USB_Passthrough
> > ),
> > >
> > > xen supports passthrough of usb device from dom0 to guests. I have tried
> > > the Xen HVM guest qemu-dm usb1.1 emulation,
> > >
> > > by specifying "usb = 1" and "usbdevice = host:xxxx:yyyy". I have also
> > tried
> > > the command usb_add host:xxxx:yyyy.
> >
> > Do you also re-assign the device from the Linux kernel? Like this:
> >
> > (the C408 0040 is my mouse).
> >
> >  cd /sys/bus/usb/drivers/usbhid
> >  for a in `ls -1 | grep :`
> >  do
> >    for DEV in C408 0040
> >    do
> >         grep $DEV $a/modalias
> >         if [ $? -eq 0 ]; then
> >                 echo "Unbinding $a for $DEV"
> >                 echo $a > unbind
> >         fi
> >    done
> >  done
> >
> > This is what the config file looks for me:
> > builder='hvm'
> > memory = 2048
> > name = "Windows7"
> > vcpus=3
> > disk = [ 'phy:/dev/vg_guest/Win7_Home,hda,w']
> > vnc=1
> > videoram=8
> > vnclisten="0.0.0.0"
> > vncpasswd=''
> > stdvga=0
> > serial='pty'
> > tsc_mode=0
> > usb=1
> > usb_add="host:045e:0040"
> > usbdevice='tablet'
> > xen_platform_pci=1
> > # Remember QEMU_AUDIO_DRV=pa
> > soundhw='es1370'
> > pci=['01:00.0','01:00.1','02:00.0']
> >

> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 26 12:00:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Sep 2012 12:00: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 1TGqHX-0002IH-Q1; Wed, 26 Sep 2012 11:59:59 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ketuzsezr@gmail.com>) id 1TGqHW-0002IC-Hh
	for xen-devel@lists.xen.org; Wed, 26 Sep 2012 11:59:58 +0000
Received: from [85.158.138.51:16137] by server-13.bemta-3.messagelabs.com id
	CB/10-11249-D3EE2605; Wed, 26 Sep 2012 11:59:57 +0000
X-Env-Sender: ketuzsezr@gmail.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1348660795!24435451!1
X-Originating-IP: [209.85.216.52]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14562 invoked from network); 26 Sep 2012 11:59:56 -0000
Received: from mail-qa0-f52.google.com (HELO mail-qa0-f52.google.com)
	(209.85.216.52)
	by server-10.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Sep 2012 11:59:56 -0000
Received: by qabg24 with SMTP id g24so1079305qab.11
	for <xen-devel@lists.xen.org>; Wed, 26 Sep 2012 04:59:55 -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=YxhtoKYgJa6Nl4B2Phxc09eSXkOTokvWCQ3v73KPm1Y=;
	b=PT34RcrTDh/kXgsaNN6EYeRZkh57nNrDg4qXyDOol90VBb0vGczQnR4s2yFk4vnb1q
	M3ew9qmYdSPzdjRbvak8xPevJTEZV2neXK2S5ylgWjzfiYZfSHEvdl3mz2xAWEVOoATY
	z3zKEhw2DMqjvzK7mjG8b5MFCukbm7GJgzOQqfYxyuePd8QwumVEtY8spbbj+cX+LQAK
	7oayZiNNnAt9sDGvztDTCJHrdJ2nV2d4vINvZDmu2L1Pj3mdwcF/mkiqarlBKsDcUZhc
	9ofL5Y+MOkHYvWmTNWeVxK4vQAEGQMcSRayNeDG4KmwTJ6d0pVZD2j+emn5KXMU9dYZE
	ECHA==
Received: by 10.224.9.9 with SMTP id j9mr1510363qaj.32.1348660795646;
	Wed, 26 Sep 2012 04:59:55 -0700 (PDT)
Received: from phenom.dumpdata.com
	(50-195-21-189-static.hfc.comcastbusiness.net. [50.195.21.189])
	by mx.google.com with ESMTPS id fl3sm4499343qab.3.2012.09.26.04.59.54
	(version=TLSv1/SSLv3 cipher=OTHER);
	Wed, 26 Sep 2012 04:59:55 -0700 (PDT)
Date: Wed, 26 Sep 2012 07:48:37 -0400
From: Konrad Rzeszutek Wilk <konrad@kernel.org>
To: Qian Hu <qianhu2011@gmail.com>
Message-ID: <20120926114836.GC7356@phenom.dumpdata.com>
References: <CALCpXpCvGkjZyG-NOY+fZY0q0f_DxuwPNEnxwKXVhjOe=gcHSQ@mail.gmail.com>
	<20120925140421.GA16478@phenom.dumpdata.com>
	<CALCpXpBJj23e3j_W4Mf2CJ57NSgx2YvnFMdB-0NgaJ=Wgvf60w@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CALCpXpBJj23e3j_W4Mf2CJ57NSgx2YvnFMdB-0NgaJ=Wgvf60w@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] usbpassthrough of xen-4.1.2 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, Sep 26, 2012 at 04:39:22PM +0800, Qian Hu wrote:
> I am sorry what does the re-assign mean? By the way, where can I find the

Please do not top-post.

> ID C408 0040?

<sigh> That is my mouse. Yours would be different of course. It was
an example of what you need to do.
> 
> It seems not to be the message listed by "lsusb".
> 
> Below is my config file, similar with yours.
> 
> import os, re
> arch = os.uname()[4]
> if re.search('64', arch):
>    arch_libdir = 'lib64'
> else:
>   arch_libdir = 'lib'
> 
> name = "win7"
> builder = "hvm"
> memory = "1024"
> disk = [ 'file:/root/win7.img,hda,w',
> #         'file:/mnt/win7.iso,hdc:cdrom,r',
>         ]
> vif = [ 'type=ioemu, mac=00:16:3e:3f:74:01 , bridge=eth0  ,model=e1000', ]
> uuid = "11111111-2262-28d2-9b64-b11713adfb20"
> device_model = "/home/root1/xen/xen-4.1.2/tools/ioemu-dir/i386-dm/qemu-dm"
> kernel = "/usr/lib/xen/boot/hvmloader"
> vnc=1
> vnclisten="0.0.0.0"
> vncdisplay=0
> apic=1
> acpi=1
> pae=1
> boot="dc"
> vcpus=2
> serial = "pty"
> on_reboot='restart'
> on_crash='restart'
> dhcp='off'
> stdvga=0
> audio=1
> soundhw='es1370'
> videoram=16
> usb=1
> usb_add='host:0204:6025'
> usbdevice='tablet'
> 
> 
> 
> 2012/9/25 Konrad Rzeszutek Wilk <konrad@kernel.org>
> 
> > On Tue, Sep 25, 2012 at 11:17:03AM +0800, Qian Hu wrote:
> > > Hi, everyone! The same question with updated message.
> > >
> > > I am working on the USB passthrough of Xen-4.1.2. My host OS  is Fedora
> > 14
> > > and the guest OS is win7.
> > >
> > > According to the wiki page(http://wiki.xen.org/wiki/Xen_USB_Passthrough
> > ),
> > >
> > > xen supports passthrough of usb device from dom0 to guests. I have tried
> > > the Xen HVM guest qemu-dm usb1.1 emulation,
> > >
> > > by specifying "usb = 1" and "usbdevice = host:xxxx:yyyy". I have also
> > tried
> > > the command usb_add host:xxxx:yyyy.
> >
> > Do you also re-assign the device from the Linux kernel? Like this:
> >
> > (the C408 0040 is my mouse).
> >
> >  cd /sys/bus/usb/drivers/usbhid
> >  for a in `ls -1 | grep :`
> >  do
> >    for DEV in C408 0040
> >    do
> >         grep $DEV $a/modalias
> >         if [ $? -eq 0 ]; then
> >                 echo "Unbinding $a for $DEV"
> >                 echo $a > unbind
> >         fi
> >    done
> >  done
> >
> > This is what the config file looks for me:
> > builder='hvm'
> > memory = 2048
> > name = "Windows7"
> > vcpus=3
> > disk = [ 'phy:/dev/vg_guest/Win7_Home,hda,w']
> > vnc=1
> > videoram=8
> > vnclisten="0.0.0.0"
> > vncpasswd=''
> > stdvga=0
> > serial='pty'
> > tsc_mode=0
> > usb=1
> > usb_add="host:045e:0040"
> > usbdevice='tablet'
> > xen_platform_pci=1
> > # Remember QEMU_AUDIO_DRV=pa
> > soundhw='es1370'
> > pci=['01:00.0','01:00.1','02:00.0']
> >

> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 26 12:05:09 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Sep 2012 12: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 1TGqMG-0002bm-SH; Wed, 26 Sep 2012 12:04:52 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ketuzsezr@gmail.com>) id 1TGqMF-0002bg-H9
	for xen-devel@lists.xen.org; Wed, 26 Sep 2012 12:04:51 +0000
Received: from [85.158.143.35:36114] by server-1.bemta-4.messagelabs.com id
	DD/EC-05684-26FE2605; Wed, 26 Sep 2012 12:04:50 +0000
X-Env-Sender: ketuzsezr@gmail.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1348661083!13135050!1
X-Originating-IP: [209.85.216.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28464 invoked from network); 26 Sep 2012 12:04:44 -0000
Received: from mail-qc0-f173.google.com (HELO mail-qc0-f173.google.com)
	(209.85.216.173)
	by server-11.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Sep 2012 12:04:44 -0000
Received: by qcab12 with SMTP id b12so452351qca.32
	for <xen-devel@lists.xen.org>; Wed, 26 Sep 2012 05:04:43 -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=hZMTQIGsu+GszqSzn4JqCrecg7bt/XhlI48EWQUfr6I=;
	b=dIGLX9lvkWGnBUuG+ZDc2NudVHbi5hzV79/YEB4tbCqPaSz95aAH2Hg21MB4g8jKRi
	us5foc3jncsTN09pFvu/6lxBuEFiqfvm+wFpETCuP8xMvkHX5i7leGJdnYpYTyaM625m
	QfWbWQHiEVHg2SeLnqDMFIIZslxssHzsa+cPW/gSiO/6jF0O+ybrdF5fJ+eO/yHk3DHi
	fvT/+CQsPc0FijGSaIxhYNq1my4s5PcDxizPsoCQ1TaMSIYdZd7QgN8kKKXT9Q6xDhz/
	RNMnSVjXcibmnwwWJTZmleknRjJ81xUo+VTCVTjhZn9Ejc7kfxI4gxXdIPMo+vf3UclX
	szyw==
Received: by 10.224.1.129 with SMTP id 1mr1403961qaf.88.1348661083312;
	Wed, 26 Sep 2012 05:04:43 -0700 (PDT)
Received: from phenom.dumpdata.com
	(50-195-21-189-static.hfc.comcastbusiness.net. [50.195.21.189])
	by mx.google.com with ESMTPS id fy1sm4508661qab.10.2012.09.26.05.04.42
	(version=TLSv1/SSLv3 cipher=OTHER);
	Wed, 26 Sep 2012 05:04:42 -0700 (PDT)
Date: Wed, 26 Sep 2012 07:53:25 -0400
From: Konrad Rzeszutek Wilk <konrad@kernel.org>
To: George Shuklin <george.shuklin@gmail.com>
Message-ID: <20120926115324.GD7356@phenom.dumpdata.com>
References: <5062BDA8.5@gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <5062BDA8.5@gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] start_info content for 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

On Wed, Sep 26, 2012 at 12:32:40PM +0400, George Shuklin wrote:
> Good day.
> 
> I've digging in some strange memory/balloon related bug and I've
> really like to see start_info content on linux. I saw in source code
> 
> #ifdef CONFIG_X86_32
>         mov %esi,xen_start_info
>         mov $init_thread_union+THREAD_SIZE,%esp
> #else
>         mov %rsi,xen_start_info
>         mov $init_thread_union+THREAD_SIZE,%rsp
> #endif
>         jmp xen_start_kernel
> 
> Pointer to start_info stored in linux global variable
> xen_start_info, but I can't find way to access it.
> 
> Is any way to get it from linux kernel? (well, except writing your
> own module).

No. That is the only way.

What do you want to get out of the xen_start_kernel structure?
> 
> Thanks.
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Sep 26 12:05:09 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Sep 2012 12: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 1TGqMG-0002bm-SH; Wed, 26 Sep 2012 12:04:52 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ketuzsezr@gmail.com>) id 1TGqMF-0002bg-H9
	for xen-devel@lists.xen.org; Wed, 26 Sep 2012 12:04:51 +0000
Received: from [85.158.143.35:36114] by server-1.bemta-4.messagelabs.com id
	DD/EC-05684-26FE2605; Wed, 26 Sep 2012 12:04:50 +0000
X-Env-Sender: ketuzsezr@gmail.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1348661083!13135050!1
X-Originating-IP: [209.85.216.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28464 invoked from network); 26 Sep 2012 12:04:44 -0000
Received: from mail-qc0-f173.google.com (HELO mail-qc0-f173.google.com)
	(209.85.216.173)
	by server-11.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Sep 2012 12:04:44 -0000
Received: by qcab12 with SMTP id b12so452351qca.32
	for <xen-devel@lists.xen.org>; Wed, 26 Sep 2012 05:04:43 -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=hZMTQIGsu+GszqSzn4JqCrecg7bt/XhlI48EWQUfr6I=;
	b=dIGLX9lvkWGnBUuG+ZDc2NudVHbi5hzV79/YEB4tbCqPaSz95aAH2Hg21MB4g8jKRi
	us5foc3jncsTN09pFvu/6lxBuEFiqfvm+wFpETCuP8xMvkHX5i7leGJdnYpYTyaM625m
	QfWbWQHiEVHg2SeLnqDMFIIZslxssHzsa+cPW/gSiO/6jF0O+ybrdF5fJ+eO/yHk3DHi
	fvT/+CQsPc0FijGSaIxhYNq1my4s5PcDxizPsoCQ1TaMSIYdZd7QgN8kKKXT9Q6xDhz/
	RNMnSVjXcibmnwwWJTZmleknRjJ81xUo+VTCVTjhZn9Ejc7kfxI4gxXdIPMo+vf3UclX
	szyw==
Received: by 10.224.1.129 with SMTP id 1mr1403961qaf.88.1348661083312;
	Wed, 26 Sep 2012 05:04:43 -0700 (PDT)
Received: from phenom.dumpdata.com
	(50-195-21-189-static.hfc.comcastbusiness.net. [50.195.21.189])
	by mx.google.com with ESMTPS id fy1sm4508661qab.10.2012.09.26.05.04.42
	(version=TLSv1/SSLv3 cipher=OTHER);
	Wed, 26 Sep 2012 05:04:42 -0700 (PDT)
Date: Wed, 26 Sep 2012 07:53:25 -0400
From: Konrad Rzeszutek Wilk <konrad@kernel.org>
To: George Shuklin <george.shuklin@gmail.com>
Message-ID: <20120926115324.GD7356@phenom.dumpdata.com>
References: <5062BDA8.5@gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <5062BDA8.5@gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] start_info content for 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

On Wed, Sep 26, 2012 at 12:32:40PM +0400, George Shuklin wrote:
> Good day.
> 
> I've digging in some strange memory/balloon related bug and I've
> really like to see start_info content on linux. I saw in source code
> 
> #ifdef CONFIG_X86_32
>         mov %esi,xen_start_info
>         mov $init_thread_union+THREAD_SIZE,%esp
> #else
>         mov %rsi,xen_start_info
>         mov $init_thread_union+THREAD_SIZE,%rsp
> #endif
>         jmp xen_start_kernel
> 
> Pointer to start_info stored in linux global variable
> xen_start_info, but I can't find way to access it.
> 
> Is any way to get it from linux kernel? (well, except writing your
> own module).

No. That is the only way.

What do you want to get out of the xen_start_kernel structure?
> 
> Thanks.
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Sep 26 12:24:09 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Sep 2012 12:24:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGqed-0002mw-Ov; Wed, 26 Sep 2012 12:23:51 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Paul.Durrant@citrix.com>) id 1TGqeb-0002mr-SJ
	for xen-devel@lists.xen.org; Wed, 26 Sep 2012 12:23:49 +0000
Received: from [85.158.143.99:11913] by server-1.bemta-4.messagelabs.com id
	91/AA-05684-5D3F2605; Wed, 26 Sep 2012 12:23:49 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1348662227!25723150!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzE2MjI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31613 invoked from network); 26 Sep 2012 12:23:48 -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 Sep 2012 12:23:48 -0000
X-IronPort-AV: E=Sophos;i="4.80,490,1344211200"; d="scan'208";a="39213375"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Sep 2012 12:23:47 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 26 Sep 2012 08:23:47 -0400
Received: from cosworth.uk.xensource.com ([10.80.16.52] ident=pauldu)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<paul.durrant@citrix.com>)	id 1TGqeY-0003rs-Ip;
	Wed, 26 Sep 2012 13:23:46 +0100
From: Paul Durrant <paul.durrant@citrix.com>
To: xen-devel@lists.xen.org
Date: Wed, 26 Sep 2012 13:23:32 +0100
Message-ID: <1348662212-3559-3-git-send-email-paul.durrant@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1348662212-3559-1-git-send-email-paul.durrant@citrix.com>
References: <1348662212-3559-1-git-send-email-paul.durrant@citrix.com>
MIME-Version: 1.0
Cc: Paul Durrant <paul.durrant@citrix.com>
Subject: [Xen-devel] [PATCH 2/2] Register Linux PV-on-HVM drivers product
	number.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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 already in use despite never being registereed.
See XEN_IOPORT_LINUX_PRODNUM in include/xen/platform_pci.h

Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
---
 xen/include/public/hvm/pvdrivers.h |    3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/xen/include/public/hvm/pvdrivers.h b/xen/include/public/hvm/pvdrivers.h
index 4be57ac..75fa656 100644
--- a/xen/include/public/hvm/pvdrivers.h
+++ b/xen/include/public/hvm/pvdrivers.h
@@ -44,6 +44,9 @@
 #define	PVDRIVERS_GPLPV_WINDOWS_ID		0x0002	/* James Harper */
 #define	PVDRIVERS_GPLPV_WINDOWS_NAME		"gplpv-windows"
 
+#define	PVDRIVERS_LINUX_ID			0x0003	/* platform_pci.h */
+#define	PVDRIVERS_LINUX_NAME			"linux"
+
 #define	PVDRIVERS_EXPERIMENTAL_ID		0xffff
 #define	PVDRIVERS_EXPERIMENTAL_NAME		"experimental"
 
-- 
1.7.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 Sep 26 12:24:09 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Sep 2012 12:24:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGqed-0002mw-Ov; Wed, 26 Sep 2012 12:23:51 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Paul.Durrant@citrix.com>) id 1TGqeb-0002mr-SJ
	for xen-devel@lists.xen.org; Wed, 26 Sep 2012 12:23:49 +0000
Received: from [85.158.143.99:11913] by server-1.bemta-4.messagelabs.com id
	91/AA-05684-5D3F2605; Wed, 26 Sep 2012 12:23:49 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1348662227!25723150!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzE2MjI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31613 invoked from network); 26 Sep 2012 12:23:48 -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 Sep 2012 12:23:48 -0000
X-IronPort-AV: E=Sophos;i="4.80,490,1344211200"; d="scan'208";a="39213375"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Sep 2012 12:23:47 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 26 Sep 2012 08:23:47 -0400
Received: from cosworth.uk.xensource.com ([10.80.16.52] ident=pauldu)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<paul.durrant@citrix.com>)	id 1TGqeY-0003rs-Ip;
	Wed, 26 Sep 2012 13:23:46 +0100
From: Paul Durrant <paul.durrant@citrix.com>
To: xen-devel@lists.xen.org
Date: Wed, 26 Sep 2012 13:23:32 +0100
Message-ID: <1348662212-3559-3-git-send-email-paul.durrant@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1348662212-3559-1-git-send-email-paul.durrant@citrix.com>
References: <1348662212-3559-1-git-send-email-paul.durrant@citrix.com>
MIME-Version: 1.0
Cc: Paul Durrant <paul.durrant@citrix.com>
Subject: [Xen-devel] [PATCH 2/2] Register Linux PV-on-HVM drivers product
	number.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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 already in use despite never being registereed.
See XEN_IOPORT_LINUX_PRODNUM in include/xen/platform_pci.h

Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
---
 xen/include/public/hvm/pvdrivers.h |    3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/xen/include/public/hvm/pvdrivers.h b/xen/include/public/hvm/pvdrivers.h
index 4be57ac..75fa656 100644
--- a/xen/include/public/hvm/pvdrivers.h
+++ b/xen/include/public/hvm/pvdrivers.h
@@ -44,6 +44,9 @@
 #define	PVDRIVERS_GPLPV_WINDOWS_ID		0x0002	/* James Harper */
 #define	PVDRIVERS_GPLPV_WINDOWS_NAME		"gplpv-windows"
 
+#define	PVDRIVERS_LINUX_ID			0x0003	/* platform_pci.h */
+#define	PVDRIVERS_LINUX_NAME			"linux"
+
 #define	PVDRIVERS_EXPERIMENTAL_ID		0xffff
 #define	PVDRIVERS_EXPERIMENTAL_NAME		"experimental"
 
-- 
1.7.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 Sep 26 12:24:11 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Sep 2012 12:24:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGqei-0002nF-3o; Wed, 26 Sep 2012 12:23:56 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Paul.Durrant@citrix.com>) id 1TGqeg-0002mq-OD
	for xen-devel@lists.xen.org; Wed, 26 Sep 2012 12:23:54 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1348662224!6345529!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNzc3MDY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23180 invoked from network); 26 Sep 2012 12:23:45 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Sep 2012 12:23:45 -0000
X-IronPort-AV: E=Sophos;i="4.80,490,1344211200"; d="scan'208";a="209393934"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Sep 2012 12:23:39 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 26 Sep 2012 08:23:39 -0400
Received: from cosworth.uk.xensource.com ([10.80.16.52] ident=pauldu)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<paul.durrant@citrix.com>)	id 1TGqeQ-0003rs-Pc;
	Wed, 26 Sep 2012 13:23:38 +0100
From: Paul Durrant <paul.durrant@citrix.com>
To: xen-devel@lists.xen.org
Date: Wed, 26 Sep 2012 13:23:30 +0100
Message-ID: <1348662212-3559-1-git-send-email-paul.durrant@citrix.com>
X-Mailer: git-send-email 1.7.2.5
MIME-Version: 1.0
Cc: Paul Durrant <paul.durrant@citrix.com>
Subject: [Xen-devel] [PATCH 0/2] PV drivers product number registration
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

PV drivers in HVM guests typically make use off an 'unplug' protocol in QEMU
to prevent co-existence of emulated devices.
See docs/misc/hvm-emulated-unplug.markdown for details.

The register of product numbers used by the blacklisting feature of this
protocol is currently directly in the xenstore.c source module of
traditional QEMU. It should really be in a Xen header file to prevent
duplication/conflict between QEMU versions.

Moreover the linux PV-on-HVM drivers make use of product number 3 seemingly
without ever registering that number.

This patch series introduces a new header and registers product number 3
for Linux's use. A subsequent patch to qemu-xen-unstable wll be created to
make use of the new header.

Signed-off-by: Paul Durrant <paul.durrant@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 Sep 26 12:24:11 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Sep 2012 12:24:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGqei-0002nF-3o; Wed, 26 Sep 2012 12:23:56 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Paul.Durrant@citrix.com>) id 1TGqeg-0002mq-OD
	for xen-devel@lists.xen.org; Wed, 26 Sep 2012 12:23:54 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1348662224!6345529!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNzc3MDY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23180 invoked from network); 26 Sep 2012 12:23:45 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Sep 2012 12:23:45 -0000
X-IronPort-AV: E=Sophos;i="4.80,490,1344211200"; d="scan'208";a="209393934"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Sep 2012 12:23:39 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 26 Sep 2012 08:23:39 -0400
Received: from cosworth.uk.xensource.com ([10.80.16.52] ident=pauldu)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<paul.durrant@citrix.com>)	id 1TGqeQ-0003rs-Pc;
	Wed, 26 Sep 2012 13:23:38 +0100
From: Paul Durrant <paul.durrant@citrix.com>
To: xen-devel@lists.xen.org
Date: Wed, 26 Sep 2012 13:23:30 +0100
Message-ID: <1348662212-3559-1-git-send-email-paul.durrant@citrix.com>
X-Mailer: git-send-email 1.7.2.5
MIME-Version: 1.0
Cc: Paul Durrant <paul.durrant@citrix.com>
Subject: [Xen-devel] [PATCH 0/2] PV drivers product number registration
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

PV drivers in HVM guests typically make use off an 'unplug' protocol in QEMU
to prevent co-existence of emulated devices.
See docs/misc/hvm-emulated-unplug.markdown for details.

The register of product numbers used by the blacklisting feature of this
protocol is currently directly in the xenstore.c source module of
traditional QEMU. It should really be in a Xen header file to prevent
duplication/conflict between QEMU versions.

Moreover the linux PV-on-HVM drivers make use of product number 3 seemingly
without ever registering that number.

This patch series introduces a new header and registers product number 3
for Linux's use. A subsequent patch to qemu-xen-unstable wll be created to
make use of the new header.

Signed-off-by: Paul Durrant <paul.durrant@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 Sep 26 12:24:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Sep 2012 12:24:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGqel-0002nh-Gd; Wed, 26 Sep 2012 12:23:59 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Paul.Durrant@citrix.com>) id 1TGqek-0002n4-NI
	for xen-devel@lists.xen.org; Wed, 26 Sep 2012 12:23:58 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1348662224!6345529!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNzc3MDY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23338 invoked from network); 26 Sep 2012 12:23:49 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Sep 2012 12:23:49 -0000
X-IronPort-AV: E=Sophos;i="4.80,490,1344211200"; d="scan'208";a="209393939"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Sep 2012 12:23:42 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 26 Sep 2012 08:23:42 -0400
Received: from cosworth.uk.xensource.com ([10.80.16.52] ident=pauldu)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<paul.durrant@citrix.com>)	id 1TGqeT-0003rs-Ui;
	Wed, 26 Sep 2012 13:23:41 +0100
From: Paul Durrant <paul.durrant@citrix.com>
To: xen-devel@lists.xen.org
Date: Wed, 26 Sep 2012 13:23:31 +0100
Message-ID: <1348662212-3559-2-git-send-email-paul.durrant@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1348662212-3559-1-git-send-email-paul.durrant@citrix.com>
References: <1348662212-3559-1-git-send-email-paul.durrant@citrix.com>
MIME-Version: 1.0
Cc: Paul Durrant <paul.durrant@citrix.com>
Subject: [Xen-devel] [PATCH 1/2] Add a new pvdrivers header to serve as the
	register of product numbers.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

These product numbers are used by the QEMU blacklisting protocol in
traditional QEMU and are currently coded directly into the xenstore.c
source module. Since there are now multiple QEMUs this information
should be pulled into a public header to avoid duplication/conflict.
hvm-emulated-unplug.markdown has also been adjusted to reference the
new header.

Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
---
 docs/misc/hvm-emulated-unplug.markdown |    2 +-
 xen/include/public/hvm/pvdrivers.h     |   50 ++++++++++++++++++++++++++++++++
 2 files changed, 51 insertions(+), 1 deletions(-)
 create mode 100644 xen/include/public/hvm/pvdrivers.h

diff --git a/docs/misc/hvm-emulated-unplug.markdown b/docs/misc/hvm-emulated-unplug.markdown
index 707fbab..ec9ce83 100644
--- a/docs/misc/hvm-emulated-unplug.markdown
+++ b/docs/misc/hvm-emulated-unplug.markdown
@@ -65,4 +65,4 @@ decimal number.  `{product_name}` is a string corresponding to the
 product number in step 3.
 
 The master registry of product names and numbers is in
-qemu-xen-unstable's xenstore.c.
+xen/include/public/hvm/pvdrivers.h
diff --git a/xen/include/public/hvm/pvdrivers.h b/xen/include/public/hvm/pvdrivers.h
new file mode 100644
index 0000000..4be57ac
--- /dev/null
+++ b/xen/include/public/hvm/pvdrivers.h
@@ -0,0 +1,50 @@
+/*
+ * pvdrivers.h: Register of PV drivers product numbers.
+ * Copyright (c) 2012, Citrix Systems Inc.
+ * 
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this software and associated documentation files (the "Software"), to
+ * deal in the Software without restriction, including without limitation the
+ * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the Software is
+ * furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+ * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+ * DEALINGS IN THE SOFTWARE.
+ */
+
+#ifndef _XEN_PUBLIC_PVDRIVERS_H_
+#define _XEN_PUBLIC_PVDRIVERS_H_
+
+/*
+ * This is the master registry of product numbers for
+ * PV drivers. 
+ * If you need a new product number allocating, please
+ * post to xen-devel@lists.xensource.com.  You should NOT use
+ * a product number without allocating one.
+ * If you maintain a separate versioning and distribution path
+ * for PV drivers you should have a separate product number so
+ * that your drivers can be separated from others.
+ *
+ * During development, you may use the product ID to
+ * indicate a driver which is yet to be released.
+ */
+
+#define	PVDRIVERS_XENSOURCE_WINDOWS_ID		0x0001	/* Citrix */
+#define	PVDRIVERS_XENSOURCE_WINDOWS_NAME	"xensource-windows"
+
+#define	PVDRIVERS_GPLPV_WINDOWS_ID		0x0002	/* James Harper */
+#define	PVDRIVERS_GPLPV_WINDOWS_NAME		"gplpv-windows"
+
+#define	PVDRIVERS_EXPERIMENTAL_ID		0xffff
+#define	PVDRIVERS_EXPERIMENTAL_NAME		"experimental"
+
+#endif /* _XEN_PUBLIC_PVDRIVERS_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 Wed Sep 26 12:24:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Sep 2012 12:24:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGqel-0002nh-Gd; Wed, 26 Sep 2012 12:23:59 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Paul.Durrant@citrix.com>) id 1TGqek-0002n4-NI
	for xen-devel@lists.xen.org; Wed, 26 Sep 2012 12:23:58 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1348662224!6345529!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNzc3MDY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23338 invoked from network); 26 Sep 2012 12:23:49 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Sep 2012 12:23:49 -0000
X-IronPort-AV: E=Sophos;i="4.80,490,1344211200"; d="scan'208";a="209393939"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Sep 2012 12:23:42 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 26 Sep 2012 08:23:42 -0400
Received: from cosworth.uk.xensource.com ([10.80.16.52] ident=pauldu)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<paul.durrant@citrix.com>)	id 1TGqeT-0003rs-Ui;
	Wed, 26 Sep 2012 13:23:41 +0100
From: Paul Durrant <paul.durrant@citrix.com>
To: xen-devel@lists.xen.org
Date: Wed, 26 Sep 2012 13:23:31 +0100
Message-ID: <1348662212-3559-2-git-send-email-paul.durrant@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1348662212-3559-1-git-send-email-paul.durrant@citrix.com>
References: <1348662212-3559-1-git-send-email-paul.durrant@citrix.com>
MIME-Version: 1.0
Cc: Paul Durrant <paul.durrant@citrix.com>
Subject: [Xen-devel] [PATCH 1/2] Add a new pvdrivers header to serve as the
	register of product numbers.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

These product numbers are used by the QEMU blacklisting protocol in
traditional QEMU and are currently coded directly into the xenstore.c
source module. Since there are now multiple QEMUs this information
should be pulled into a public header to avoid duplication/conflict.
hvm-emulated-unplug.markdown has also been adjusted to reference the
new header.

Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
---
 docs/misc/hvm-emulated-unplug.markdown |    2 +-
 xen/include/public/hvm/pvdrivers.h     |   50 ++++++++++++++++++++++++++++++++
 2 files changed, 51 insertions(+), 1 deletions(-)
 create mode 100644 xen/include/public/hvm/pvdrivers.h

diff --git a/docs/misc/hvm-emulated-unplug.markdown b/docs/misc/hvm-emulated-unplug.markdown
index 707fbab..ec9ce83 100644
--- a/docs/misc/hvm-emulated-unplug.markdown
+++ b/docs/misc/hvm-emulated-unplug.markdown
@@ -65,4 +65,4 @@ decimal number.  `{product_name}` is a string corresponding to the
 product number in step 3.
 
 The master registry of product names and numbers is in
-qemu-xen-unstable's xenstore.c.
+xen/include/public/hvm/pvdrivers.h
diff --git a/xen/include/public/hvm/pvdrivers.h b/xen/include/public/hvm/pvdrivers.h
new file mode 100644
index 0000000..4be57ac
--- /dev/null
+++ b/xen/include/public/hvm/pvdrivers.h
@@ -0,0 +1,50 @@
+/*
+ * pvdrivers.h: Register of PV drivers product numbers.
+ * Copyright (c) 2012, Citrix Systems Inc.
+ * 
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this software and associated documentation files (the "Software"), to
+ * deal in the Software without restriction, including without limitation the
+ * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the Software is
+ * furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+ * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+ * DEALINGS IN THE SOFTWARE.
+ */
+
+#ifndef _XEN_PUBLIC_PVDRIVERS_H_
+#define _XEN_PUBLIC_PVDRIVERS_H_
+
+/*
+ * This is the master registry of product numbers for
+ * PV drivers. 
+ * If you need a new product number allocating, please
+ * post to xen-devel@lists.xensource.com.  You should NOT use
+ * a product number without allocating one.
+ * If you maintain a separate versioning and distribution path
+ * for PV drivers you should have a separate product number so
+ * that your drivers can be separated from others.
+ *
+ * During development, you may use the product ID to
+ * indicate a driver which is yet to be released.
+ */
+
+#define	PVDRIVERS_XENSOURCE_WINDOWS_ID		0x0001	/* Citrix */
+#define	PVDRIVERS_XENSOURCE_WINDOWS_NAME	"xensource-windows"
+
+#define	PVDRIVERS_GPLPV_WINDOWS_ID		0x0002	/* James Harper */
+#define	PVDRIVERS_GPLPV_WINDOWS_NAME		"gplpv-windows"
+
+#define	PVDRIVERS_EXPERIMENTAL_ID		0xffff
+#define	PVDRIVERS_EXPERIMENTAL_NAME		"experimental"
+
+#endif /* _XEN_PUBLIC_PVDRIVERS_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 Wed Sep 26 12:34:23 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Sep 2012 12:34:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGqob-0003HG-KG; Wed, 26 Sep 2012 12:34:09 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Paul.Durrant@citrix.com>) id 1TGqoZ-0003HB-OD
	for xen-devel@lists.xen.org; Wed, 26 Sep 2012 12:34:07 +0000
Received: from [85.158.139.211:11089] by server-8.bemta-5.messagelabs.com id
	C3/32-18073-E36F2605; Wed, 26 Sep 2012 12:34:06 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-3.tower-206.messagelabs.com!1348662844!20020416!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNzc3MDY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15092 invoked from network); 26 Sep 2012 12:34:06 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-3.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Sep 2012 12:34:06 -0000
X-IronPort-AV: E=Sophos;i="4.80,490,1344211200"; d="scan'208";a="209394980"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Sep 2012 12:33:58 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 26 Sep 2012 08:33:57 -0400
Received: from cosworth.uk.xensource.com ([10.80.16.52] ident=pauldu)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<paul.durrant@citrix.com>)	id 1TGqoP-00041C-ET;
	Wed, 26 Sep 2012 13:33:57 +0100
From: Paul Durrant <paul.durrant@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Wed, 26 Sep 2012 13:33:50 +0100
Message-ID: <1348662830-11832-1-git-send-email-paul.durrant@citrix.com>
X-Mailer: git-send-email 1.7.2.5
MIME-Version: 1.0
Cc: Paul Durrant <paul.durrant@citrix.com>,
	Paul Durrant <paul.durrent@citrix.com>
Subject: [Xen-devel] [PATCH] Use new Xen public header for product numbers
	and names
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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/include/public/hvm/pvdrivers.h has been added as the
register of product numbers used by the blacklisting protocol.
Use the definitions therein rather then locally coded values.

Signed-off-by: Paul Durrant <paul.durrent@citrix.com>
---
 xenstore.c |   30 ++++++++++++++----------------
 1 files changed, 14 insertions(+), 16 deletions(-)

diff --git a/xenstore.c b/xenstore.c
index 1857160..04ae199 100644
--- a/xenstore.c
+++ b/xenstore.c
@@ -23,6 +23,8 @@
 #include "qemu-timer.h"
 #include "qemu-xen.h"
 
+#include <xen/hvm/pvdrivers.h>
+
 struct xs_handle *xsh = NULL;
 static char *media_filename[MAX_DRIVES+1];
 static QEMUTimer *insert_timer = NULL;
@@ -961,22 +963,18 @@ xenstore_pv_driver_build_blacklisted(uint16_t product_nr,
     const char *product;
 
     switch (product_nr) {
-    /*
-     * In qemu-xen-unstable, this is the master registry of product
-     * numbers.  If you need a new product number allocating, please
-     * post to xen-devel@lists.xensource.com.  You should NOT use
-     * an existing product number without allocating one.
-     *
-     * If you maintain a seaparate versioning and distribution path
-     * for PV drivers you should have a separate product number so
-     * that your drivers can be separated from others'.
-     *
-     * During development, you may use the product ID 0xffff to
-     * indicate a driver which is yet to be released.
-     */
-    case 1: product = "xensource-windows";  break; /* Citrix */
-    case 2: product = "gplpv-windows";      break; /* James Harper */
-    case 0xffff: product = "experimental";  break;
+    case PVDRIVERS_XENSOURCE_WINDOWS_ID:
+        product = PVDRIVERS_XENSOURCE_WINDOWS_NAME;
+        break;
+    case PVDRIVERS_GPLPV_WINDOWS_ID:
+        product = PVDRIVERS_GPLPV_WINDOWS_NAME;
+        break;
+    case PVDRIVERS_LINUX_ID:
+        product = PVDRIVERS_LINUX_NAME;
+        break;
+    case PVDRIVERS_EXPERIMENTAL_ID:
+        product = PVDRIVERS_EXPERIMENTAL_NAME; 
+        break;
     default:
         /* Don't know what product this is -> we can't blacklist
          * it. */
-- 
1.7.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 Sep 26 12:34:23 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Sep 2012 12:34:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGqob-0003HG-KG; Wed, 26 Sep 2012 12:34:09 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Paul.Durrant@citrix.com>) id 1TGqoZ-0003HB-OD
	for xen-devel@lists.xen.org; Wed, 26 Sep 2012 12:34:07 +0000
Received: from [85.158.139.211:11089] by server-8.bemta-5.messagelabs.com id
	C3/32-18073-E36F2605; Wed, 26 Sep 2012 12:34:06 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-3.tower-206.messagelabs.com!1348662844!20020416!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNzc3MDY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15092 invoked from network); 26 Sep 2012 12:34:06 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-3.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Sep 2012 12:34:06 -0000
X-IronPort-AV: E=Sophos;i="4.80,490,1344211200"; d="scan'208";a="209394980"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Sep 2012 12:33:58 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 26 Sep 2012 08:33:57 -0400
Received: from cosworth.uk.xensource.com ([10.80.16.52] ident=pauldu)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<paul.durrant@citrix.com>)	id 1TGqoP-00041C-ET;
	Wed, 26 Sep 2012 13:33:57 +0100
From: Paul Durrant <paul.durrant@citrix.com>
To: <xen-devel@lists.xen.org>
Date: Wed, 26 Sep 2012 13:33:50 +0100
Message-ID: <1348662830-11832-1-git-send-email-paul.durrant@citrix.com>
X-Mailer: git-send-email 1.7.2.5
MIME-Version: 1.0
Cc: Paul Durrant <paul.durrant@citrix.com>,
	Paul Durrant <paul.durrent@citrix.com>
Subject: [Xen-devel] [PATCH] Use new Xen public header for product numbers
	and names
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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/include/public/hvm/pvdrivers.h has been added as the
register of product numbers used by the blacklisting protocol.
Use the definitions therein rather then locally coded values.

Signed-off-by: Paul Durrant <paul.durrent@citrix.com>
---
 xenstore.c |   30 ++++++++++++++----------------
 1 files changed, 14 insertions(+), 16 deletions(-)

diff --git a/xenstore.c b/xenstore.c
index 1857160..04ae199 100644
--- a/xenstore.c
+++ b/xenstore.c
@@ -23,6 +23,8 @@
 #include "qemu-timer.h"
 #include "qemu-xen.h"
 
+#include <xen/hvm/pvdrivers.h>
+
 struct xs_handle *xsh = NULL;
 static char *media_filename[MAX_DRIVES+1];
 static QEMUTimer *insert_timer = NULL;
@@ -961,22 +963,18 @@ xenstore_pv_driver_build_blacklisted(uint16_t product_nr,
     const char *product;
 
     switch (product_nr) {
-    /*
-     * In qemu-xen-unstable, this is the master registry of product
-     * numbers.  If you need a new product number allocating, please
-     * post to xen-devel@lists.xensource.com.  You should NOT use
-     * an existing product number without allocating one.
-     *
-     * If you maintain a seaparate versioning and distribution path
-     * for PV drivers you should have a separate product number so
-     * that your drivers can be separated from others'.
-     *
-     * During development, you may use the product ID 0xffff to
-     * indicate a driver which is yet to be released.
-     */
-    case 1: product = "xensource-windows";  break; /* Citrix */
-    case 2: product = "gplpv-windows";      break; /* James Harper */
-    case 0xffff: product = "experimental";  break;
+    case PVDRIVERS_XENSOURCE_WINDOWS_ID:
+        product = PVDRIVERS_XENSOURCE_WINDOWS_NAME;
+        break;
+    case PVDRIVERS_GPLPV_WINDOWS_ID:
+        product = PVDRIVERS_GPLPV_WINDOWS_NAME;
+        break;
+    case PVDRIVERS_LINUX_ID:
+        product = PVDRIVERS_LINUX_NAME;
+        break;
+    case PVDRIVERS_EXPERIMENTAL_ID:
+        product = PVDRIVERS_EXPERIMENTAL_NAME; 
+        break;
     default:
         /* Don't know what product this is -> we can't blacklist
          * it. */
-- 
1.7.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 Sep 26 12:45:38 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Sep 2012 12:45:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGqzO-0003Ql-PO; Wed, 26 Sep 2012 12:45:18 +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 1TGqzN-0003Qg-Fo
	for xen-devel@lists.xen.org; Wed, 26 Sep 2012 12:45:17 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1348663510!9140961!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=UPPERCASE_25_50
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27430 invoked from network); 26 Sep 2012 12:45:11 -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;
	26 Sep 2012 12:45:11 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 26 Sep 2012 13:45:10 +0100
Message-Id: <5063150E020000780009DFD9@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 26 Sep 2012 13:45:34 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Paul Durrant" <paul.durrant@citrix.com>
References: <1348662212-3559-1-git-send-email-paul.durrant@citrix.com>
	<1348662212-3559-2-git-send-email-paul.durrant@citrix.com>
In-Reply-To: <1348662212-3559-2-git-send-email-paul.durrant@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 1/2] Add a new pvdrivers header to serve as
 the register of product numbers.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 26.09.12 at 14:23, Paul Durrant <paul.durrant@citrix.com> wrote:
> --- /dev/null
> +++ b/xen/include/public/hvm/pvdrivers.h
> @@ -0,0 +1,50 @@
> +/*
> + * pvdrivers.h: Register of PV drivers product numbers.
> + * Copyright (c) 2012, Citrix Systems Inc.
> + * 
> + * Permission is hereby granted, free of charge, to any person obtaining a copy
> + * of this software and associated documentation files (the "Software"), to
> + * deal in the Software without restriction, including without limitation the
> + * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or
> + * sell copies of the Software, and to permit persons to whom the Software is
> + * furnished to do so, subject to the following conditions:
> + *
> + * The above copyright notice and this permission notice shall be included in
> + * all copies or substantial portions of the Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
> + * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
> + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
> + * DEALINGS IN THE SOFTWARE.
> + */
> +
> +#ifndef _XEN_PUBLIC_PVDRIVERS_H_
> +#define _XEN_PUBLIC_PVDRIVERS_H_
> +
> +/*
> + * This is the master registry of product numbers for
> + * PV drivers. 
> + * If you need a new product number allocating, please
> + * post to xen-devel@lists.xensource.com.  You should NOT use

@lists.xen.org

> + * a product number without allocating one.
> + * If you maintain a separate versioning and distribution path
> + * for PV drivers you should have a separate product number so
> + * that your drivers can be separated from others.
> + *
> + * During development, you may use the product ID to
> + * indicate a driver which is yet to be released.

Which "the product ID"?

Jan

> + */
> +
> +#define	PVDRIVERS_XENSOURCE_WINDOWS_ID		0x0001	/* Citrix */
> +#define	PVDRIVERS_XENSOURCE_WINDOWS_NAME	"xensource-windows"
> +
> +#define	PVDRIVERS_GPLPV_WINDOWS_ID		0x0002	/* James Harper */
> +#define	PVDRIVERS_GPLPV_WINDOWS_NAME		"gplpv-windows"
> +
> +#define	PVDRIVERS_EXPERIMENTAL_ID		0xffff
> +#define	PVDRIVERS_EXPERIMENTAL_NAME		"experimental"
> +
> +#endif /* _XEN_PUBLIC_PVDRIVERS_H_ */
> -- 
> 1.7.2.5
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org 
> http://lists.xen.org/xen-devel 




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 26 12:45:38 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Sep 2012 12:45:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGqzO-0003Ql-PO; Wed, 26 Sep 2012 12:45:18 +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 1TGqzN-0003Qg-Fo
	for xen-devel@lists.xen.org; Wed, 26 Sep 2012 12:45:17 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1348663510!9140961!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=UPPERCASE_25_50
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27430 invoked from network); 26 Sep 2012 12:45:11 -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;
	26 Sep 2012 12:45:11 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 26 Sep 2012 13:45:10 +0100
Message-Id: <5063150E020000780009DFD9@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 26 Sep 2012 13:45:34 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Paul Durrant" <paul.durrant@citrix.com>
References: <1348662212-3559-1-git-send-email-paul.durrant@citrix.com>
	<1348662212-3559-2-git-send-email-paul.durrant@citrix.com>
In-Reply-To: <1348662212-3559-2-git-send-email-paul.durrant@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 1/2] Add a new pvdrivers header to serve as
 the register of product numbers.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 26.09.12 at 14:23, Paul Durrant <paul.durrant@citrix.com> wrote:
> --- /dev/null
> +++ b/xen/include/public/hvm/pvdrivers.h
> @@ -0,0 +1,50 @@
> +/*
> + * pvdrivers.h: Register of PV drivers product numbers.
> + * Copyright (c) 2012, Citrix Systems Inc.
> + * 
> + * Permission is hereby granted, free of charge, to any person obtaining a copy
> + * of this software and associated documentation files (the "Software"), to
> + * deal in the Software without restriction, including without limitation the
> + * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or
> + * sell copies of the Software, and to permit persons to whom the Software is
> + * furnished to do so, subject to the following conditions:
> + *
> + * The above copyright notice and this permission notice shall be included in
> + * all copies or substantial portions of the Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
> + * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
> + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
> + * DEALINGS IN THE SOFTWARE.
> + */
> +
> +#ifndef _XEN_PUBLIC_PVDRIVERS_H_
> +#define _XEN_PUBLIC_PVDRIVERS_H_
> +
> +/*
> + * This is the master registry of product numbers for
> + * PV drivers. 
> + * If you need a new product number allocating, please
> + * post to xen-devel@lists.xensource.com.  You should NOT use

@lists.xen.org

> + * a product number without allocating one.
> + * If you maintain a separate versioning and distribution path
> + * for PV drivers you should have a separate product number so
> + * that your drivers can be separated from others.
> + *
> + * During development, you may use the product ID to
> + * indicate a driver which is yet to be released.

Which "the product ID"?

Jan

> + */
> +
> +#define	PVDRIVERS_XENSOURCE_WINDOWS_ID		0x0001	/* Citrix */
> +#define	PVDRIVERS_XENSOURCE_WINDOWS_NAME	"xensource-windows"
> +
> +#define	PVDRIVERS_GPLPV_WINDOWS_ID		0x0002	/* James Harper */
> +#define	PVDRIVERS_GPLPV_WINDOWS_NAME		"gplpv-windows"
> +
> +#define	PVDRIVERS_EXPERIMENTAL_ID		0xffff
> +#define	PVDRIVERS_EXPERIMENTAL_NAME		"experimental"
> +
> +#endif /* _XEN_PUBLIC_PVDRIVERS_H_ */
> -- 
> 1.7.2.5
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org 
> http://lists.xen.org/xen-devel 




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 26 12:47:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Sep 2012 12:47: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 1TGr10-0003Uy-8M; Wed, 26 Sep 2012 12:46:58 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ketuzsezr@gmail.com>) id 1TGr0z-0003Ur-Gy
	for xen-devel@lists.xen.org; Wed, 26 Sep 2012 12:46:57 +0000
Received: from [85.158.139.211:58669] by server-7.bemta-5.messagelabs.com id
	43/7C-00431-049F2605; Wed, 26 Sep 2012 12:46:56 +0000
X-Env-Sender: ketuzsezr@gmail.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1348663614!19577601!1
X-Originating-IP: [209.85.216.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1503 invoked from network); 26 Sep 2012 12:46:55 -0000
Received: from mail-qa0-f45.google.com (HELO mail-qa0-f45.google.com)
	(209.85.216.45)
	by server-7.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Sep 2012 12:46:55 -0000
Received: by qaas11 with SMTP id s11so1499653qaa.11
	for <xen-devel@lists.xen.org>; Wed, 26 Sep 2012 05:46:54 -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=t46tGyvr8km5ZAqpBAH5wqjs1X7tkJPRkzOOs2OJRqY=;
	b=uWKsAS0JejtqwUTwnRofMZBRmgVtdOnna6vAssR9gxLm8VtZ64mudKOzt6IebrwhQk
	xiniIEKnXfmmTZVAxIYEbPXpST7vCy7Ofj0Uxr22FPmNoGR4FPQoDeE5tEFdP3OrrkPs
	kvBXSaTrF5hzzlCnwOVur9Y6BgKC7KzXr3kB3RhkhbhUWr7noQvC0IipR4NVWqDTBRSM
	robwt0ycBKkstYnXbgUq2Rg7bXSZB6vadCNpsnc6Xbhh0aHrrODCGYu54UTL2LgCiTvK
	nckrPwGLqXdi0vZFwTWkNBjdszPAiu95+f5sS6EHNwIOOuWis+/YLxisQ2+VYWT3eEbl
	NqXQ==
Received: by 10.229.136.81 with SMTP id q17mr264127qct.105.1348663614132;
	Wed, 26 Sep 2012 05:46:54 -0700 (PDT)
Received: from phenom.dumpdata.com
	(50-195-21-189-static.hfc.comcastbusiness.net. [50.195.21.189])
	by mx.google.com with ESMTPS id h8sm4635671qap.16.2012.09.26.05.46.52
	(version=TLSv1/SSLv3 cipher=OTHER);
	Wed, 26 Sep 2012 05:46:53 -0700 (PDT)
Date: Wed, 26 Sep 2012 08:35:35 -0400
From: Konrad Rzeszutek Wilk <konrad@kernel.org>
To: Zhenzhong Duan <zhenzhong.duan@oracle.com>
Message-ID: <20120926123534.GF7356@phenom.dumpdata.com>
References: <505C3647.1030003@oracle.com>
	<20120921143430.GA3522@phenom.dumpdata.com>
	<5062C16A.1020306@oracle.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <5062C16A.1020306@oracle.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: Dan Magenheimer <dan.magenheimer@oracle.com>,
	xen-devel <xen-devel@lists.xen.org>, Feng Jin <joe.jin@oracle.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] an issue with 'xm save'
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Sep 26, 2012 at 04:48:42PM +0800, Zhenzhong Duan wrote:
> Konrad Rzeszutek Wilk wrote:
> >On Fri, Sep 21, 2012 at 05:41:27PM +0800, Zhenzhong Duan wrote:
> >>Hi maintainers,
> >>
> >>I found there is an issue when 'xm save' a pvm guest. See below:
> >>
> >>When I do save then restore once, CPU(%) in xentop showed around 99%.
> >>When I do that second time, CPU(%) showed 199%
> >>
> >>top in dom0 showed:
> >>     PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
> >>    20946 root      18  -2 10984 1284  964 S 19.8  0.3   0:48.93 block
> >>    4939 root      18  -2 10984 1288  964 S 19.5  0.3   1:34.68 block
> >>
> >>I could kill the block process, then all look normal again.
> >
> >What is the 'block' process? If you attach 'perf' to it do you get an idea
> >of what it is spinning at?
> It's /etc/xen/scripts/block
> I add 'set -x' to /etc/xen/scripts/block, found it blocked at claim_lock.
> When domU was created first time, claim_lock/release_lock finished quickly,
> when 'xm save' was called, claim_lock spin in its own while loop.
> I can ensure no other domU create/save/etc happen when I test.

OK, so how come you have two block processes? Is it b/c you have two
disks attached to the guest? The are multiple claim_lock in the shell
script - do you know where each of two threads are spinning? Are they
spinning on the same function?


> >>xen and xen-tools are both generated with xen-unstable.
> >>I tried xl, but it segfault.
> >
> >It segfaulted? When doing 'xl save'  or 'xl resume'? Or just allocating
> >the guest?
> When xl create vm.cfg
> >>I also tried ovm3.1.1(xen-4.1.2-18.el5.1 and xen-tools-4.1.2-18.el5.1),
> >>can't reproduce.
> >
> >So the issue is only present with Xen-unstable?
> Yes,  I found in /etc/xen/scripts/locking.sh of ovm3.1.1, func
> claim_lock is quite different to xen-unstable

Could that be upstreamed? Perhaps that was fix that was added for this
exact reason and it just never got upstreamed?

> Maybe this is why ovm3.1.1 work with save/restore.
> >Did you clear _any_ older Xen libraries/tools when you installed Xen-unstable?
> No, I built xen and xen-tools on el5, then installed to ovm3.1.1 on
> other partition.

Excellent.
> thanks
> zduan

> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Sep 26 12:47:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Sep 2012 12:47: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 1TGr10-0003Uy-8M; Wed, 26 Sep 2012 12:46:58 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ketuzsezr@gmail.com>) id 1TGr0z-0003Ur-Gy
	for xen-devel@lists.xen.org; Wed, 26 Sep 2012 12:46:57 +0000
Received: from [85.158.139.211:58669] by server-7.bemta-5.messagelabs.com id
	43/7C-00431-049F2605; Wed, 26 Sep 2012 12:46:56 +0000
X-Env-Sender: ketuzsezr@gmail.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1348663614!19577601!1
X-Originating-IP: [209.85.216.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1503 invoked from network); 26 Sep 2012 12:46:55 -0000
Received: from mail-qa0-f45.google.com (HELO mail-qa0-f45.google.com)
	(209.85.216.45)
	by server-7.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Sep 2012 12:46:55 -0000
Received: by qaas11 with SMTP id s11so1499653qaa.11
	for <xen-devel@lists.xen.org>; Wed, 26 Sep 2012 05:46:54 -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=t46tGyvr8km5ZAqpBAH5wqjs1X7tkJPRkzOOs2OJRqY=;
	b=uWKsAS0JejtqwUTwnRofMZBRmgVtdOnna6vAssR9gxLm8VtZ64mudKOzt6IebrwhQk
	xiniIEKnXfmmTZVAxIYEbPXpST7vCy7Ofj0Uxr22FPmNoGR4FPQoDeE5tEFdP3OrrkPs
	kvBXSaTrF5hzzlCnwOVur9Y6BgKC7KzXr3kB3RhkhbhUWr7noQvC0IipR4NVWqDTBRSM
	robwt0ycBKkstYnXbgUq2Rg7bXSZB6vadCNpsnc6Xbhh0aHrrODCGYu54UTL2LgCiTvK
	nckrPwGLqXdi0vZFwTWkNBjdszPAiu95+f5sS6EHNwIOOuWis+/YLxisQ2+VYWT3eEbl
	NqXQ==
Received: by 10.229.136.81 with SMTP id q17mr264127qct.105.1348663614132;
	Wed, 26 Sep 2012 05:46:54 -0700 (PDT)
Received: from phenom.dumpdata.com
	(50-195-21-189-static.hfc.comcastbusiness.net. [50.195.21.189])
	by mx.google.com with ESMTPS id h8sm4635671qap.16.2012.09.26.05.46.52
	(version=TLSv1/SSLv3 cipher=OTHER);
	Wed, 26 Sep 2012 05:46:53 -0700 (PDT)
Date: Wed, 26 Sep 2012 08:35:35 -0400
From: Konrad Rzeszutek Wilk <konrad@kernel.org>
To: Zhenzhong Duan <zhenzhong.duan@oracle.com>
Message-ID: <20120926123534.GF7356@phenom.dumpdata.com>
References: <505C3647.1030003@oracle.com>
	<20120921143430.GA3522@phenom.dumpdata.com>
	<5062C16A.1020306@oracle.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <5062C16A.1020306@oracle.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: Dan Magenheimer <dan.magenheimer@oracle.com>,
	xen-devel <xen-devel@lists.xen.org>, Feng Jin <joe.jin@oracle.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] an issue with 'xm save'
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Sep 26, 2012 at 04:48:42PM +0800, Zhenzhong Duan wrote:
> Konrad Rzeszutek Wilk wrote:
> >On Fri, Sep 21, 2012 at 05:41:27PM +0800, Zhenzhong Duan wrote:
> >>Hi maintainers,
> >>
> >>I found there is an issue when 'xm save' a pvm guest. See below:
> >>
> >>When I do save then restore once, CPU(%) in xentop showed around 99%.
> >>When I do that second time, CPU(%) showed 199%
> >>
> >>top in dom0 showed:
> >>     PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
> >>    20946 root      18  -2 10984 1284  964 S 19.8  0.3   0:48.93 block
> >>    4939 root      18  -2 10984 1288  964 S 19.5  0.3   1:34.68 block
> >>
> >>I could kill the block process, then all look normal again.
> >
> >What is the 'block' process? If you attach 'perf' to it do you get an idea
> >of what it is spinning at?
> It's /etc/xen/scripts/block
> I add 'set -x' to /etc/xen/scripts/block, found it blocked at claim_lock.
> When domU was created first time, claim_lock/release_lock finished quickly,
> when 'xm save' was called, claim_lock spin in its own while loop.
> I can ensure no other domU create/save/etc happen when I test.

OK, so how come you have two block processes? Is it b/c you have two
disks attached to the guest? The are multiple claim_lock in the shell
script - do you know where each of two threads are spinning? Are they
spinning on the same function?


> >>xen and xen-tools are both generated with xen-unstable.
> >>I tried xl, but it segfault.
> >
> >It segfaulted? When doing 'xl save'  or 'xl resume'? Or just allocating
> >the guest?
> When xl create vm.cfg
> >>I also tried ovm3.1.1(xen-4.1.2-18.el5.1 and xen-tools-4.1.2-18.el5.1),
> >>can't reproduce.
> >
> >So the issue is only present with Xen-unstable?
> Yes,  I found in /etc/xen/scripts/locking.sh of ovm3.1.1, func
> claim_lock is quite different to xen-unstable

Could that be upstreamed? Perhaps that was fix that was added for this
exact reason and it just never got upstreamed?

> Maybe this is why ovm3.1.1 work with save/restore.
> >Did you clear _any_ older Xen libraries/tools when you installed Xen-unstable?
> No, I built xen and xen-tools on el5, then installed to ovm3.1.1 on
> other partition.

Excellent.
> thanks
> zduan

> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Sep 26 12:55:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Sep 2012 12: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 1TGr8m-0003js-C6; Wed, 26 Sep 2012 12:55:00 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ketuzsezr@gmail.com>) id 1TGr8k-0003jn-BB
	for xen-devel@lists.xen.org; Wed, 26 Sep 2012 12:54:58 +0000
Received: from [85.158.138.51:24170] by server-12.bemta-3.messagelabs.com id
	1F/08-23730-12BF2605; Wed, 26 Sep 2012 12:54:57 +0000
X-Env-Sender: ketuzsezr@gmail.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1348664095!24444306!1
X-Originating-IP: [209.85.216.52]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1712 invoked from network); 26 Sep 2012 12:54:56 -0000
Received: from mail-qa0-f52.google.com (HELO mail-qa0-f52.google.com)
	(209.85.216.52)
	by server-10.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Sep 2012 12:54:56 -0000
Received: by qabg24 with SMTP id g24so1124778qab.11
	for <xen-devel@lists.xen.org>; Wed, 26 Sep 2012 05:54:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=googlemail.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=jItk/kYImET2S1xTZMsMDAfyAU0U6dfoLkTayVjy4VA=;
	b=Yt/LrnkopA/ZGUEsQDjKwTAjsZAu4/F2qvRnJe8KGbRdD4/MZPmcuCyBHrIWysWMHp
	T/QQGz5UKQL6OCXgemC7JVNQz46D4TPgzcxZu7mdspep05xHff87TA5olkbWF1k41CgV
	fLS6wIRamyVDrq3vFstgCcHsGGcLTOGfVLFTSF7AF+QDgBuWfPRpSTZacPyJpNFmC0Nj
	8sjU0ZQ0QA99OwddWrQNF4AKa34SPEBAmNz7/pGIBPhAiS0bm1B77avESY57w346i83z
	SE9psRdck3QkY2zp5gdkchGRa5055zNuLjDjxKhWbyyrVY+eGhLFte90MRqLqdj/Kc/E
	nUHA==
Received: by 10.224.78.141 with SMTP id l13mr1874032qak.25.1348664095180;
	Wed, 26 Sep 2012 05:54:55 -0700 (PDT)
Received: from phenom.dumpdata.com
	(50-195-21-189-static.hfc.comcastbusiness.net. [50.195.21.189])
	by mx.google.com with ESMTPS id ca8sm4658704qab.20.2012.09.26.05.54.53
	(version=TLSv1/SSLv3 cipher=OTHER);
	Wed, 26 Sep 2012 05:54:54 -0700 (PDT)
Date: Wed, 26 Sep 2012 08:43:36 -0400
From: Konrad Rzeszutek Wilk <konrad@kernel.org>
To: Javier Marcet <jmarcet@gmail.com>
Message-ID: <20120926124335.GG7356@phenom.dumpdata.com>
References: <CAOvdn6XV4eoA-FfFns1xhx7HCUqXc7KHxZwyKuT4FHG8s3R5RQ@mail.gmail.com>
	<CAAnFQG9PLQjdh6Ab6=Y5ZGM1s4nGdLekKU=pcKNMxt4rmt_RKA@mail.gmail.com>
	<20120924140411.GH31618@phenom.dumpdata.com>
	<CAAnFQG-tjv5UyF6j-TNHNgme2c4vA0Zxy8AdCiJEVsf2Z0quNA@mail.gmail.com>
	<20120925140611.GB16478@phenom.dumpdata.com>
	<CAAnFQG88ApxKuscXx53Lt2qOyCe0ws6oXSSqBDfW0+oYo5Y3nA@mail.gmail.com>
	<5061E800020000780009DBBA@nat28.tlf.novell.com>
	<CAAnFQG-6VrwaA_OcUJL5X5HBNo8PTME9pNyJbsXqSO34tbD8=g@mail.gmail.com>
	<5062C81D020000780009DE2E@nat28.tlf.novell.com>
	<CAAnFQG9f-97RQTt0YNGds6q9FDRcLEOAXrAdZuJw_p=+3opn7Q@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAAnFQG9f-97RQTt0YNGds6q9FDRcLEOAXrAdZuJw_p=+3opn7Q@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: Keir Fraser <keir@xen.org>, john.baboval@citrix.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	xen-devel <xen-devel@lists.xen.org>, Ben Guthro <ben@guthro.net>,
	Jan Beulich <JBeulich@suse.com>, Thomas Goetz <thomas.goetz@citrix.com>
Subject: Re: [Xen-devel] Xen4.2 S3 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 Wed, Sep 26, 2012 at 09:59:07AM +0200, Javier Marcet wrote:
> On Wed, Sep 26, 2012 at 9:17 AM, Jan Beulich <JBeulich@suse.com> wrote:
> 
> >> Adding the additional call in xen/arch/x86/acpi/cpu_idle.c causes an
> >> instant reboot on resume.
> >
> > That addition can hardly be responsible for a reboot. Did you
> 
> Just like I could perform a full cycle without issues, the instant
> reboot might as well be another way the race ends.
> 
> > have "noreboot" (or "reboot=no") in place on the Xen command
> > line? "sync_console"?
> 
> Neither of them. I have used the sync_console parameter to check
> whether it changed anything but I removed it afterwards.
> 
> > And then again, for the other failure case, iirc it was the kernel
> > that died, not the hypervisor, so the problem there isn't directly
> > related to the problems here I would guess.
> 
> All I know is that I'm using that same kernel without hypervisor, with
> lots of suspend/resume and not a single issue.
> 
> With the two kernel patches from Konrad added I can also suspend and
> resume fine under the hypervisor but there is always a cpu which
> receives an irq while offline.

And that error you get - can you reproduce it without going to
suspend/resume? Meaning if you offline/online a VCPU in the
guest by manipulating the /sys/../cpuX/online attribute?

And actually - we should move that discussion to a completlty different
thread as it has nothing to do with the hypervisor. That is a PV kernel
issue.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 26 12:55:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Sep 2012 12: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 1TGr8m-0003js-C6; Wed, 26 Sep 2012 12:55:00 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ketuzsezr@gmail.com>) id 1TGr8k-0003jn-BB
	for xen-devel@lists.xen.org; Wed, 26 Sep 2012 12:54:58 +0000
Received: from [85.158.138.51:24170] by server-12.bemta-3.messagelabs.com id
	1F/08-23730-12BF2605; Wed, 26 Sep 2012 12:54:57 +0000
X-Env-Sender: ketuzsezr@gmail.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1348664095!24444306!1
X-Originating-IP: [209.85.216.52]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1712 invoked from network); 26 Sep 2012 12:54:56 -0000
Received: from mail-qa0-f52.google.com (HELO mail-qa0-f52.google.com)
	(209.85.216.52)
	by server-10.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Sep 2012 12:54:56 -0000
Received: by qabg24 with SMTP id g24so1124778qab.11
	for <xen-devel@lists.xen.org>; Wed, 26 Sep 2012 05:54:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=googlemail.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=jItk/kYImET2S1xTZMsMDAfyAU0U6dfoLkTayVjy4VA=;
	b=Yt/LrnkopA/ZGUEsQDjKwTAjsZAu4/F2qvRnJe8KGbRdD4/MZPmcuCyBHrIWysWMHp
	T/QQGz5UKQL6OCXgemC7JVNQz46D4TPgzcxZu7mdspep05xHff87TA5olkbWF1k41CgV
	fLS6wIRamyVDrq3vFstgCcHsGGcLTOGfVLFTSF7AF+QDgBuWfPRpSTZacPyJpNFmC0Nj
	8sjU0ZQ0QA99OwddWrQNF4AKa34SPEBAmNz7/pGIBPhAiS0bm1B77avESY57w346i83z
	SE9psRdck3QkY2zp5gdkchGRa5055zNuLjDjxKhWbyyrVY+eGhLFte90MRqLqdj/Kc/E
	nUHA==
Received: by 10.224.78.141 with SMTP id l13mr1874032qak.25.1348664095180;
	Wed, 26 Sep 2012 05:54:55 -0700 (PDT)
Received: from phenom.dumpdata.com
	(50-195-21-189-static.hfc.comcastbusiness.net. [50.195.21.189])
	by mx.google.com with ESMTPS id ca8sm4658704qab.20.2012.09.26.05.54.53
	(version=TLSv1/SSLv3 cipher=OTHER);
	Wed, 26 Sep 2012 05:54:54 -0700 (PDT)
Date: Wed, 26 Sep 2012 08:43:36 -0400
From: Konrad Rzeszutek Wilk <konrad@kernel.org>
To: Javier Marcet <jmarcet@gmail.com>
Message-ID: <20120926124335.GG7356@phenom.dumpdata.com>
References: <CAOvdn6XV4eoA-FfFns1xhx7HCUqXc7KHxZwyKuT4FHG8s3R5RQ@mail.gmail.com>
	<CAAnFQG9PLQjdh6Ab6=Y5ZGM1s4nGdLekKU=pcKNMxt4rmt_RKA@mail.gmail.com>
	<20120924140411.GH31618@phenom.dumpdata.com>
	<CAAnFQG-tjv5UyF6j-TNHNgme2c4vA0Zxy8AdCiJEVsf2Z0quNA@mail.gmail.com>
	<20120925140611.GB16478@phenom.dumpdata.com>
	<CAAnFQG88ApxKuscXx53Lt2qOyCe0ws6oXSSqBDfW0+oYo5Y3nA@mail.gmail.com>
	<5061E800020000780009DBBA@nat28.tlf.novell.com>
	<CAAnFQG-6VrwaA_OcUJL5X5HBNo8PTME9pNyJbsXqSO34tbD8=g@mail.gmail.com>
	<5062C81D020000780009DE2E@nat28.tlf.novell.com>
	<CAAnFQG9f-97RQTt0YNGds6q9FDRcLEOAXrAdZuJw_p=+3opn7Q@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAAnFQG9f-97RQTt0YNGds6q9FDRcLEOAXrAdZuJw_p=+3opn7Q@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: Keir Fraser <keir@xen.org>, john.baboval@citrix.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	xen-devel <xen-devel@lists.xen.org>, Ben Guthro <ben@guthro.net>,
	Jan Beulich <JBeulich@suse.com>, Thomas Goetz <thomas.goetz@citrix.com>
Subject: Re: [Xen-devel] Xen4.2 S3 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 Wed, Sep 26, 2012 at 09:59:07AM +0200, Javier Marcet wrote:
> On Wed, Sep 26, 2012 at 9:17 AM, Jan Beulich <JBeulich@suse.com> wrote:
> 
> >> Adding the additional call in xen/arch/x86/acpi/cpu_idle.c causes an
> >> instant reboot on resume.
> >
> > That addition can hardly be responsible for a reboot. Did you
> 
> Just like I could perform a full cycle without issues, the instant
> reboot might as well be another way the race ends.
> 
> > have "noreboot" (or "reboot=no") in place on the Xen command
> > line? "sync_console"?
> 
> Neither of them. I have used the sync_console parameter to check
> whether it changed anything but I removed it afterwards.
> 
> > And then again, for the other failure case, iirc it was the kernel
> > that died, not the hypervisor, so the problem there isn't directly
> > related to the problems here I would guess.
> 
> All I know is that I'm using that same kernel without hypervisor, with
> lots of suspend/resume and not a single issue.
> 
> With the two kernel patches from Konrad added I can also suspend and
> resume fine under the hypervisor but there is always a cpu which
> receives an irq while offline.

And that error you get - can you reproduce it without going to
suspend/resume? Meaning if you offline/online a VCPU in the
guest by manipulating the /sys/../cpuX/online attribute?

And actually - we should move that discussion to a completlty different
thread as it has nothing to do with the hypervisor. That is a PV kernel
issue.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 26 12:55:35 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Sep 2012 12: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 1TGr96-0003lN-Oz; Wed, 26 Sep 2012 12:55: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 1TGr95-0003lA-E5
	for xen-devel@lists.xen.org; Wed, 26 Sep 2012 12:55:19 +0000
Received: from [85.158.143.99:3158] by server-2.bemta-4.messagelabs.com id
	89/55-06610-63BF2605; Wed, 26 Sep 2012 12:55:18 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1348664093!30935096!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTE1NzQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13477 invoked from network); 26 Sep 2012 12:54:53 -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;
	26 Sep 2012 12:54:53 -0000
X-IronPort-AV: E=Sophos;i="4.80,490,1344211200"; d="scan'208";a="14776787"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Sep 2012 12:54: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.279.1;
	Wed, 26 Sep 2012 13:54:36 +0100
Message-ID: <1348664074.19176.32.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Paul Durrant <paul.durrant@citrix.com>
Date: Wed, 26 Sep 2012 13:54:34 +0100
In-Reply-To: <1348662212-3559-2-git-send-email-paul.durrant@citrix.com>
References: <1348662212-3559-1-git-send-email-paul.durrant@citrix.com>
	<1348662212-3559-2-git-send-email-paul.durrant@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 1/2] Add a new pvdrivers header to serve as
 the register of product numbers.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-09-26 at 13:23 +0100, Paul Durrant wrote:
> These product numbers are used by the QEMU blacklisting protocol in
> traditional QEMU and are currently coded directly into the xenstore.c
> source module. Since there are now multiple QEMUs this information
> should be pulled into a public header to avoid duplication/conflict.
> hvm-emulated-unplug.markdown has also been adjusted to reference the
> new header.
> 
> Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
> ---
>  docs/misc/hvm-emulated-unplug.markdown |    2 +-
>  xen/include/public/hvm/pvdrivers.h     |   50 ++++++++++++++++++++++++++++++++
>  2 files changed, 51 insertions(+), 1 deletions(-)
>  create mode 100644 xen/include/public/hvm/pvdrivers.h
> 
> diff --git a/docs/misc/hvm-emulated-unplug.markdown b/docs/misc/hvm-emulated-unplug.markdown
> index 707fbab..ec9ce83 100644
> --- a/docs/misc/hvm-emulated-unplug.markdown
> +++ b/docs/misc/hvm-emulated-unplug.markdown
> @@ -65,4 +65,4 @@ decimal number.  `{product_name}` is a string corresponding to the
>  product number in step 3.
>  
>  The master registry of product names and numbers is in
> -qemu-xen-unstable's xenstore.c.
> +xen/include/public/hvm/pvdrivers.h
> diff --git a/xen/include/public/hvm/pvdrivers.h b/xen/include/public/hvm/pvdrivers.h
> new file mode 100644
> index 0000000..4be57ac
> --- /dev/null
> +++ b/xen/include/public/hvm/pvdrivers.h
> @@ -0,0 +1,50 @@
> +/*
> + * pvdrivers.h: Register of PV drivers product numbers.
> + * Copyright (c) 2012, Citrix Systems Inc.
> + * 
> + * Permission is hereby granted, free of charge, to any person obtaining a copy
> + * of this software and associated documentation files (the "Software"), to
> + * deal in the Software without restriction, including without limitation the
> + * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or
> + * sell copies of the Software, and to permit persons to whom the Software is
> + * furnished to do so, subject to the following conditions:
> + *
> + * The above copyright notice and this permission notice shall be included in
> + * all copies or substantial portions of the Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
> + * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
> + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
> + * DEALINGS IN THE SOFTWARE.
> + */
> +
> +#ifndef _XEN_PUBLIC_PVDRIVERS_H_
> +#define _XEN_PUBLIC_PVDRIVERS_H_
> +
> +/*
> + * This is the master registry of product numbers for
> + * PV drivers. 
> + * If you need a new product number allocating, please
> + * post to xen-devel@lists.xensource.com.  You should NOT use
> + * a product number without allocating one.
> + * If you maintain a separate versioning and distribution path
> + * for PV drivers you should have a separate product number so
> + * that your drivers can be separated from others.
> + *
> + * During development, you may use the product ID to
> + * indicate a driver which is yet to be released.

Can we add a reference to the unplug protocol doc here too please.

> + */
> +
> +#define	PVDRIVERS_XENSOURCE_WINDOWS_ID		0x0001	/* Citrix */
> +#define	PVDRIVERS_XENSOURCE_WINDOWS_NAME	"xensource-windows"
> +
> +#define	PVDRIVERS_GPLPV_WINDOWS_ID		0x0002	/* James Harper */
> +#define	PVDRIVERS_GPLPV_WINDOWS_NAME		"gplpv-windows"
> +
> +#define	PVDRIVERS_EXPERIMENTAL_ID		0xffff
> +#define	PVDRIVERS_EXPERIMENTAL_NAME		"experimental"
> +
> +#endif /* _XEN_PUBLIC_PVDRIVERS_H_ */



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 26 12:55:35 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Sep 2012 12: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 1TGr96-0003lN-Oz; Wed, 26 Sep 2012 12:55: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 1TGr95-0003lA-E5
	for xen-devel@lists.xen.org; Wed, 26 Sep 2012 12:55:19 +0000
Received: from [85.158.143.99:3158] by server-2.bemta-4.messagelabs.com id
	89/55-06610-63BF2605; Wed, 26 Sep 2012 12:55:18 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1348664093!30935096!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTE1NzQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13477 invoked from network); 26 Sep 2012 12:54:53 -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;
	26 Sep 2012 12:54:53 -0000
X-IronPort-AV: E=Sophos;i="4.80,490,1344211200"; d="scan'208";a="14776787"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Sep 2012 12:54: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.279.1;
	Wed, 26 Sep 2012 13:54:36 +0100
Message-ID: <1348664074.19176.32.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Paul Durrant <paul.durrant@citrix.com>
Date: Wed, 26 Sep 2012 13:54:34 +0100
In-Reply-To: <1348662212-3559-2-git-send-email-paul.durrant@citrix.com>
References: <1348662212-3559-1-git-send-email-paul.durrant@citrix.com>
	<1348662212-3559-2-git-send-email-paul.durrant@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 1/2] Add a new pvdrivers header to serve as
 the register of product numbers.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-09-26 at 13:23 +0100, Paul Durrant wrote:
> These product numbers are used by the QEMU blacklisting protocol in
> traditional QEMU and are currently coded directly into the xenstore.c
> source module. Since there are now multiple QEMUs this information
> should be pulled into a public header to avoid duplication/conflict.
> hvm-emulated-unplug.markdown has also been adjusted to reference the
> new header.
> 
> Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
> ---
>  docs/misc/hvm-emulated-unplug.markdown |    2 +-
>  xen/include/public/hvm/pvdrivers.h     |   50 ++++++++++++++++++++++++++++++++
>  2 files changed, 51 insertions(+), 1 deletions(-)
>  create mode 100644 xen/include/public/hvm/pvdrivers.h
> 
> diff --git a/docs/misc/hvm-emulated-unplug.markdown b/docs/misc/hvm-emulated-unplug.markdown
> index 707fbab..ec9ce83 100644
> --- a/docs/misc/hvm-emulated-unplug.markdown
> +++ b/docs/misc/hvm-emulated-unplug.markdown
> @@ -65,4 +65,4 @@ decimal number.  `{product_name}` is a string corresponding to the
>  product number in step 3.
>  
>  The master registry of product names and numbers is in
> -qemu-xen-unstable's xenstore.c.
> +xen/include/public/hvm/pvdrivers.h
> diff --git a/xen/include/public/hvm/pvdrivers.h b/xen/include/public/hvm/pvdrivers.h
> new file mode 100644
> index 0000000..4be57ac
> --- /dev/null
> +++ b/xen/include/public/hvm/pvdrivers.h
> @@ -0,0 +1,50 @@
> +/*
> + * pvdrivers.h: Register of PV drivers product numbers.
> + * Copyright (c) 2012, Citrix Systems Inc.
> + * 
> + * Permission is hereby granted, free of charge, to any person obtaining a copy
> + * of this software and associated documentation files (the "Software"), to
> + * deal in the Software without restriction, including without limitation the
> + * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or
> + * sell copies of the Software, and to permit persons to whom the Software is
> + * furnished to do so, subject to the following conditions:
> + *
> + * The above copyright notice and this permission notice shall be included in
> + * all copies or substantial portions of the Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
> + * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
> + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
> + * DEALINGS IN THE SOFTWARE.
> + */
> +
> +#ifndef _XEN_PUBLIC_PVDRIVERS_H_
> +#define _XEN_PUBLIC_PVDRIVERS_H_
> +
> +/*
> + * This is the master registry of product numbers for
> + * PV drivers. 
> + * If you need a new product number allocating, please
> + * post to xen-devel@lists.xensource.com.  You should NOT use
> + * a product number without allocating one.
> + * If you maintain a separate versioning and distribution path
> + * for PV drivers you should have a separate product number so
> + * that your drivers can be separated from others.
> + *
> + * During development, you may use the product ID to
> + * indicate a driver which is yet to be released.

Can we add a reference to the unplug protocol doc here too please.

> + */
> +
> +#define	PVDRIVERS_XENSOURCE_WINDOWS_ID		0x0001	/* Citrix */
> +#define	PVDRIVERS_XENSOURCE_WINDOWS_NAME	"xensource-windows"
> +
> +#define	PVDRIVERS_GPLPV_WINDOWS_ID		0x0002	/* James Harper */
> +#define	PVDRIVERS_GPLPV_WINDOWS_NAME		"gplpv-windows"
> +
> +#define	PVDRIVERS_EXPERIMENTAL_ID		0xffff
> +#define	PVDRIVERS_EXPERIMENTAL_NAME		"experimental"
> +
> +#endif /* _XEN_PUBLIC_PVDRIVERS_H_ */



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 26 13:01:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Sep 2012 13: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 1TGrEc-00042B-HY; Wed, 26 Sep 2012 13:01:02 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ketuzsezr@gmail.com>) id 1TGrEb-000424-9m
	for xen-devel@lists.xen.org; Wed, 26 Sep 2012 13:01:01 +0000
Received: from [85.158.143.35:6502] by server-1.bemta-4.messagelabs.com id
	79/D5-05684-C8CF2605; Wed, 26 Sep 2012 13:01:00 +0000
X-Env-Sender: ketuzsezr@gmail.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1348664434!5202333!1
X-Originating-IP: [209.85.216.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24667 invoked from network); 26 Sep 2012 13:00:36 -0000
Received: from mail-qa0-f45.google.com (HELO mail-qa0-f45.google.com)
	(209.85.216.45)
	by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Sep 2012 13:00:36 -0000
Received: by qaas11 with SMTP id s11so1512644qaa.11
	for <xen-devel@lists.xen.org>; Wed, 26 Sep 2012 06:00:34 -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=gFRCjdQHX7UOE/4uDzZs17O1RZdV3RJ/XzIeLqmZ07Q=;
	b=C6TNDUmCNPISHD9gVOLGKKP2rQ2hmbJyzpxYF8EOjqPT+EOYxCd/RRRfUN9G/tB3ur
	JPNwsVmNhgy2cC2LAM4doi/KnxqckeFrloyRQGi/htj6UrL9c51RDFlZ2Qv7gmkffhPB
	aJ8ee2N1F2awSqepI0QgqWQiHdBhdC2ywQ4RPZjNt16DGqRLvhMbLEDQu7yrpc65mCQz
	EqCac32YgUEDa5RkbaNqS64ZGqd/NVSotQnWidp56YUlNAnY0Ywj8rGXd61dRG0RGn/5
	9Y6PB41lzFqjflqvW4eNTzXuWIcLQAhvnyBdP6+MUDQVvVTle5pfOWYWqHJNU6pXhBGb
	XxEA==
Received: by 10.224.207.8 with SMTP id fw8mr1758825qab.92.1348664434311;
	Wed, 26 Sep 2012 06:00:34 -0700 (PDT)
Received: from phenom.dumpdata.com
	(50-195-21-189-static.hfc.comcastbusiness.net. [50.195.21.189])
	by mx.google.com with ESMTPS id k6sm4684985qac.0.2012.09.26.06.00.33
	(version=TLSv1/SSLv3 cipher=OTHER);
	Wed, 26 Sep 2012 06:00:33 -0700 (PDT)
Date: Wed, 26 Sep 2012 08:49:16 -0400
From: Konrad Rzeszutek Wilk <konrad@kernel.org>
To: Paul Durrant <paul.durrant@citrix.com>, steve.prochniak@oracle.com,
	annie.li@oracle.com
Message-ID: <20120926124915.GH7356@phenom.dumpdata.com>
References: <1348662212-3559-1-git-send-email-paul.durrant@citrix.com>
	<1348662212-3559-2-git-send-email-paul.durrant@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1348662212-3559-2-git-send-email-paul.durrant@citrix.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 1/2] Add a new pvdrivers header to serve as
 the register of product numbers.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Sep 26, 2012 at 01:23:31PM +0100, Paul Durrant wrote:
> These product numbers are used by the QEMU blacklisting protocol in
> traditional QEMU and are currently coded directly into the xenstore.c
> source module. Since there are now multiple QEMUs this information
> should be pulled into a public header to avoid duplication/conflict.
> hvm-emulated-unplug.markdown has also been adjusted to reference the
> new header.
> 
> Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
> ---
>  docs/misc/hvm-emulated-unplug.markdown |    2 +-
>  xen/include/public/hvm/pvdrivers.h     |   50 ++++++++++++++++++++++++++++++++
>  2 files changed, 51 insertions(+), 1 deletions(-)
>  create mode 100644 xen/include/public/hvm/pvdrivers.h
> 
> diff --git a/docs/misc/hvm-emulated-unplug.markdown b/docs/misc/hvm-emulated-unplug.markdown
> index 707fbab..ec9ce83 100644
> --- a/docs/misc/hvm-emulated-unplug.markdown
> +++ b/docs/misc/hvm-emulated-unplug.markdown
> @@ -65,4 +65,4 @@ decimal number.  `{product_name}` is a string corresponding to the
>  product number in step 3.
>  
>  The master registry of product names and numbers is in
> -qemu-xen-unstable's xenstore.c.
> +xen/include/public/hvm/pvdrivers.h
> diff --git a/xen/include/public/hvm/pvdrivers.h b/xen/include/public/hvm/pvdrivers.h
> new file mode 100644
> index 0000000..4be57ac
> --- /dev/null
> +++ b/xen/include/public/hvm/pvdrivers.h
> @@ -0,0 +1,50 @@
> +/*
> + * pvdrivers.h: Register of PV drivers product numbers.
> + * Copyright (c) 2012, Citrix Systems Inc.
> + * 
> + * Permission is hereby granted, free of charge, to any person obtaining a copy
> + * of this software and associated documentation files (the "Software"), to
> + * deal in the Software without restriction, including without limitation the
> + * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or
> + * sell copies of the Software, and to permit persons to whom the Software is
> + * furnished to do so, subject to the following conditions:
> + *
> + * The above copyright notice and this permission notice shall be included in
> + * all copies or substantial portions of the Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
> + * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
> + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
> + * DEALINGS IN THE SOFTWARE.
> + */
> +
> +#ifndef _XEN_PUBLIC_PVDRIVERS_H_
> +#define _XEN_PUBLIC_PVDRIVERS_H_
> +
> +/*
> + * This is the master registry of product numbers for
> + * PV drivers. 
> + * If you need a new product number allocating, please
> + * post to xen-devel@lists.xensource.com.  You should NOT use
> + * a product number without allocating one.
> + * If you maintain a separate versioning and distribution path
> + * for PV drivers you should have a separate product number so
> + * that your drivers can be separated from others.
> + *
> + * During development, you may use the product ID to
> + * indicate a driver which is yet to be released.
> + */
> +
> +#define	PVDRIVERS_XENSOURCE_WINDOWS_ID		0x0001	/* Citrix */
> +#define	PVDRIVERS_XENSOURCE_WINDOWS_NAME	"xensource-windows"
> +
> +#define	PVDRIVERS_GPLPV_WINDOWS_ID		0x0002	/* James Harper */
> +#define	PVDRIVERS_GPLPV_WINDOWS_NAME		"gplpv-windows"

And also the Oracle one :-)

The Novell one looks to be using 107?
> +
> +#define	PVDRIVERS_EXPERIMENTAL_ID		0xffff
> +#define	PVDRIVERS_EXPERIMENTAL_NAME		"experimental"
> +
> +#endif /* _XEN_PUBLIC_PVDRIVERS_H_ */
> -- 
> 1.7.2.5
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 26 13:01:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Sep 2012 13: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 1TGrEc-00042B-HY; Wed, 26 Sep 2012 13:01:02 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ketuzsezr@gmail.com>) id 1TGrEb-000424-9m
	for xen-devel@lists.xen.org; Wed, 26 Sep 2012 13:01:01 +0000
Received: from [85.158.143.35:6502] by server-1.bemta-4.messagelabs.com id
	79/D5-05684-C8CF2605; Wed, 26 Sep 2012 13:01:00 +0000
X-Env-Sender: ketuzsezr@gmail.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1348664434!5202333!1
X-Originating-IP: [209.85.216.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24667 invoked from network); 26 Sep 2012 13:00:36 -0000
Received: from mail-qa0-f45.google.com (HELO mail-qa0-f45.google.com)
	(209.85.216.45)
	by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Sep 2012 13:00:36 -0000
Received: by qaas11 with SMTP id s11so1512644qaa.11
	for <xen-devel@lists.xen.org>; Wed, 26 Sep 2012 06:00:34 -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=gFRCjdQHX7UOE/4uDzZs17O1RZdV3RJ/XzIeLqmZ07Q=;
	b=C6TNDUmCNPISHD9gVOLGKKP2rQ2hmbJyzpxYF8EOjqPT+EOYxCd/RRRfUN9G/tB3ur
	JPNwsVmNhgy2cC2LAM4doi/KnxqckeFrloyRQGi/htj6UrL9c51RDFlZ2Qv7gmkffhPB
	aJ8ee2N1F2awSqepI0QgqWQiHdBhdC2ywQ4RPZjNt16DGqRLvhMbLEDQu7yrpc65mCQz
	EqCac32YgUEDa5RkbaNqS64ZGqd/NVSotQnWidp56YUlNAnY0Ywj8rGXd61dRG0RGn/5
	9Y6PB41lzFqjflqvW4eNTzXuWIcLQAhvnyBdP6+MUDQVvVTle5pfOWYWqHJNU6pXhBGb
	XxEA==
Received: by 10.224.207.8 with SMTP id fw8mr1758825qab.92.1348664434311;
	Wed, 26 Sep 2012 06:00:34 -0700 (PDT)
Received: from phenom.dumpdata.com
	(50-195-21-189-static.hfc.comcastbusiness.net. [50.195.21.189])
	by mx.google.com with ESMTPS id k6sm4684985qac.0.2012.09.26.06.00.33
	(version=TLSv1/SSLv3 cipher=OTHER);
	Wed, 26 Sep 2012 06:00:33 -0700 (PDT)
Date: Wed, 26 Sep 2012 08:49:16 -0400
From: Konrad Rzeszutek Wilk <konrad@kernel.org>
To: Paul Durrant <paul.durrant@citrix.com>, steve.prochniak@oracle.com,
	annie.li@oracle.com
Message-ID: <20120926124915.GH7356@phenom.dumpdata.com>
References: <1348662212-3559-1-git-send-email-paul.durrant@citrix.com>
	<1348662212-3559-2-git-send-email-paul.durrant@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1348662212-3559-2-git-send-email-paul.durrant@citrix.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 1/2] Add a new pvdrivers header to serve as
 the register of product numbers.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Sep 26, 2012 at 01:23:31PM +0100, Paul Durrant wrote:
> These product numbers are used by the QEMU blacklisting protocol in
> traditional QEMU and are currently coded directly into the xenstore.c
> source module. Since there are now multiple QEMUs this information
> should be pulled into a public header to avoid duplication/conflict.
> hvm-emulated-unplug.markdown has also been adjusted to reference the
> new header.
> 
> Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
> ---
>  docs/misc/hvm-emulated-unplug.markdown |    2 +-
>  xen/include/public/hvm/pvdrivers.h     |   50 ++++++++++++++++++++++++++++++++
>  2 files changed, 51 insertions(+), 1 deletions(-)
>  create mode 100644 xen/include/public/hvm/pvdrivers.h
> 
> diff --git a/docs/misc/hvm-emulated-unplug.markdown b/docs/misc/hvm-emulated-unplug.markdown
> index 707fbab..ec9ce83 100644
> --- a/docs/misc/hvm-emulated-unplug.markdown
> +++ b/docs/misc/hvm-emulated-unplug.markdown
> @@ -65,4 +65,4 @@ decimal number.  `{product_name}` is a string corresponding to the
>  product number in step 3.
>  
>  The master registry of product names and numbers is in
> -qemu-xen-unstable's xenstore.c.
> +xen/include/public/hvm/pvdrivers.h
> diff --git a/xen/include/public/hvm/pvdrivers.h b/xen/include/public/hvm/pvdrivers.h
> new file mode 100644
> index 0000000..4be57ac
> --- /dev/null
> +++ b/xen/include/public/hvm/pvdrivers.h
> @@ -0,0 +1,50 @@
> +/*
> + * pvdrivers.h: Register of PV drivers product numbers.
> + * Copyright (c) 2012, Citrix Systems Inc.
> + * 
> + * Permission is hereby granted, free of charge, to any person obtaining a copy
> + * of this software and associated documentation files (the "Software"), to
> + * deal in the Software without restriction, including without limitation the
> + * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or
> + * sell copies of the Software, and to permit persons to whom the Software is
> + * furnished to do so, subject to the following conditions:
> + *
> + * The above copyright notice and this permission notice shall be included in
> + * all copies or substantial portions of the Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
> + * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
> + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
> + * DEALINGS IN THE SOFTWARE.
> + */
> +
> +#ifndef _XEN_PUBLIC_PVDRIVERS_H_
> +#define _XEN_PUBLIC_PVDRIVERS_H_
> +
> +/*
> + * This is the master registry of product numbers for
> + * PV drivers. 
> + * If you need a new product number allocating, please
> + * post to xen-devel@lists.xensource.com.  You should NOT use
> + * a product number without allocating one.
> + * If you maintain a separate versioning and distribution path
> + * for PV drivers you should have a separate product number so
> + * that your drivers can be separated from others.
> + *
> + * During development, you may use the product ID to
> + * indicate a driver which is yet to be released.
> + */
> +
> +#define	PVDRIVERS_XENSOURCE_WINDOWS_ID		0x0001	/* Citrix */
> +#define	PVDRIVERS_XENSOURCE_WINDOWS_NAME	"xensource-windows"
> +
> +#define	PVDRIVERS_GPLPV_WINDOWS_ID		0x0002	/* James Harper */
> +#define	PVDRIVERS_GPLPV_WINDOWS_NAME		"gplpv-windows"

And also the Oracle one :-)

The Novell one looks to be using 107?
> +
> +#define	PVDRIVERS_EXPERIMENTAL_ID		0xffff
> +#define	PVDRIVERS_EXPERIMENTAL_NAME		"experimental"
> +
> +#endif /* _XEN_PUBLIC_PVDRIVERS_H_ */
> -- 
> 1.7.2.5
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 26 13:03:24 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Sep 2012 13:03:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGrGh-00049E-2S; Wed, 26 Sep 2012 13:03:11 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ketuzsezr@gmail.com>) id 1TGrGf-000494-MC
	for xen-devel@lists.xen.org; Wed, 26 Sep 2012 13:03:09 +0000
Received: from [85.158.138.51:30056] by server-13.bemta-3.messagelabs.com id
	1C/D1-11249-C0DF2605; Wed, 26 Sep 2012 13:03:08 +0000
X-Env-Sender: ketuzsezr@gmail.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1348664587!32029090!1
X-Originating-IP: [209.85.216.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15330 invoked from network); 26 Sep 2012 13:03:08 -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;
	26 Sep 2012 13:03:08 -0000
Received: by qaas11 with SMTP id s11so1515625qaa.11
	for <xen-devel@lists.xen.org>; Wed, 26 Sep 2012 06:03:06 -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=pRsmjYUUlM6fnNelPbY8BXDvgdv3hav1deMhR5E0MBQ=;
	b=Y9YhJnObhbP1D6Y8kvuNdol5p3WTnzNjibfG02SIIgLG7lapondwq8HGsOKj8cwcU/
	VRLVRaH2bEe2NnFJIoYGPdyQtj/4+/xSLu2CKWTayJAT8/yftVgNSbRqUCDOS6icJwsQ
	GpeXKQVJs0YQhPlxknZQJ6oJevH8M1Ov7fH0VZDu4eIDtOn6MUX+jAfB2xiLCGt8opxg
	DBBojAI+QDg1XVXhiOlhRKzBvJwrMESsZ93tphAY3aQC1568jPMJACCzGxvk97WPD+5o
	aEZjt+LzbPDwZWDxp2jrAvM/F8G4xsvgK9ANvmQBcRyen0P5w3cjWgX5j8WYf5gPZQhV
	eClg==
Received: by 10.229.172.84 with SMTP id k20mr321153qcz.42.1348664586818;
	Wed, 26 Sep 2012 06:03:06 -0700 (PDT)
Received: from phenom.dumpdata.com
	(50-195-21-189-static.hfc.comcastbusiness.net. [50.195.21.189])
	by mx.google.com with ESMTPS id d11sm4681468qaj.18.2012.09.26.06.03.05
	(version=TLSv1/SSLv3 cipher=OTHER);
	Wed, 26 Sep 2012 06:03:06 -0700 (PDT)
Date: Wed, 26 Sep 2012 08:51:48 -0400
From: Konrad Rzeszutek Wilk <konrad@kernel.org>
To: Paul Durrant <paul.durrant@citrix.com>
Message-ID: <20120926125148.GI7356@phenom.dumpdata.com>
References: <1348662212-3559-1-git-send-email-paul.durrant@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1348662212-3559-1-git-send-email-paul.durrant@citrix.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 0/2] PV drivers product number registration
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Sep 26, 2012 at 01:23:30PM +0100, Paul Durrant wrote:
> PV drivers in HVM guests typically make use off an 'unplug' protocol in QEMU
> to prevent co-existence of emulated devices.
> See docs/misc/hvm-emulated-unplug.markdown for details.
> 
> The register of product numbers used by the blacklisting feature of this
> protocol is currently directly in the xenstore.c source module of
> traditional QEMU. It should really be in a Xen header file to prevent

Why do we want to blacklist them? Isn't it a whitelist (as in it is
the right values?)

> duplication/conflict between QEMU versions.
> 
> Moreover the linux PV-on-HVM drivers make use of product number 3 seemingly
> without ever registering that number.
> 
> This patch series introduces a new header and registers product number 3
> for Linux's use. A subsequent patch to qemu-xen-unstable wll be created to
> make use of the new header.
> 
> Signed-off-by: Paul Durrant <paul.durrant@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 Wed Sep 26 13:03:24 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Sep 2012 13:03:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGrGh-00049E-2S; Wed, 26 Sep 2012 13:03:11 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ketuzsezr@gmail.com>) id 1TGrGf-000494-MC
	for xen-devel@lists.xen.org; Wed, 26 Sep 2012 13:03:09 +0000
Received: from [85.158.138.51:30056] by server-13.bemta-3.messagelabs.com id
	1C/D1-11249-C0DF2605; Wed, 26 Sep 2012 13:03:08 +0000
X-Env-Sender: ketuzsezr@gmail.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1348664587!32029090!1
X-Originating-IP: [209.85.216.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15330 invoked from network); 26 Sep 2012 13:03:08 -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;
	26 Sep 2012 13:03:08 -0000
Received: by qaas11 with SMTP id s11so1515625qaa.11
	for <xen-devel@lists.xen.org>; Wed, 26 Sep 2012 06:03:06 -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=pRsmjYUUlM6fnNelPbY8BXDvgdv3hav1deMhR5E0MBQ=;
	b=Y9YhJnObhbP1D6Y8kvuNdol5p3WTnzNjibfG02SIIgLG7lapondwq8HGsOKj8cwcU/
	VRLVRaH2bEe2NnFJIoYGPdyQtj/4+/xSLu2CKWTayJAT8/yftVgNSbRqUCDOS6icJwsQ
	GpeXKQVJs0YQhPlxknZQJ6oJevH8M1Ov7fH0VZDu4eIDtOn6MUX+jAfB2xiLCGt8opxg
	DBBojAI+QDg1XVXhiOlhRKzBvJwrMESsZ93tphAY3aQC1568jPMJACCzGxvk97WPD+5o
	aEZjt+LzbPDwZWDxp2jrAvM/F8G4xsvgK9ANvmQBcRyen0P5w3cjWgX5j8WYf5gPZQhV
	eClg==
Received: by 10.229.172.84 with SMTP id k20mr321153qcz.42.1348664586818;
	Wed, 26 Sep 2012 06:03:06 -0700 (PDT)
Received: from phenom.dumpdata.com
	(50-195-21-189-static.hfc.comcastbusiness.net. [50.195.21.189])
	by mx.google.com with ESMTPS id d11sm4681468qaj.18.2012.09.26.06.03.05
	(version=TLSv1/SSLv3 cipher=OTHER);
	Wed, 26 Sep 2012 06:03:06 -0700 (PDT)
Date: Wed, 26 Sep 2012 08:51:48 -0400
From: Konrad Rzeszutek Wilk <konrad@kernel.org>
To: Paul Durrant <paul.durrant@citrix.com>
Message-ID: <20120926125148.GI7356@phenom.dumpdata.com>
References: <1348662212-3559-1-git-send-email-paul.durrant@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1348662212-3559-1-git-send-email-paul.durrant@citrix.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 0/2] PV drivers product number registration
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Sep 26, 2012 at 01:23:30PM +0100, Paul Durrant wrote:
> PV drivers in HVM guests typically make use off an 'unplug' protocol in QEMU
> to prevent co-existence of emulated devices.
> See docs/misc/hvm-emulated-unplug.markdown for details.
> 
> The register of product numbers used by the blacklisting feature of this
> protocol is currently directly in the xenstore.c source module of
> traditional QEMU. It should really be in a Xen header file to prevent

Why do we want to blacklist them? Isn't it a whitelist (as in it is
the right values?)

> duplication/conflict between QEMU versions.
> 
> Moreover the linux PV-on-HVM drivers make use of product number 3 seemingly
> without ever registering that number.
> 
> This patch series introduces a new header and registers product number 3
> for Linux's use. A subsequent patch to qemu-xen-unstable wll be created to
> make use of the new header.
> 
> Signed-off-by: Paul Durrant <paul.durrant@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 Wed Sep 26 13:06:58 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Sep 2012 13: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 1TGrKA-0004M4-M8; Wed, 26 Sep 2012 13:06:46 +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 1TGrK8-0004Lg-Qk
	for xen-devel@lists.xen.org; Wed, 26 Sep 2012 13:06:45 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1348664739!5455102!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTE1NzQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24123 invoked from network); 26 Sep 2012 13:05:39 -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 Sep 2012 13:05:39 -0000
X-IronPort-AV: E=Sophos;i="4.80,490,1344211200"; d="scan'208";a="14777131"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Sep 2012 13:05:38 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 26 Sep 2012 14:05:38 +0100
Message-ID: <1348664737.19176.34.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Konrad Rzeszutek Wilk <konrad@kernel.org>
Date: Wed, 26 Sep 2012 14:05:37 +0100
In-Reply-To: <20120926124915.GH7356@phenom.dumpdata.com>
References: <1348662212-3559-1-git-send-email-paul.durrant@citrix.com>
	<1348662212-3559-2-git-send-email-paul.durrant@citrix.com>
	<20120926124915.GH7356@phenom.dumpdata.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "annie.li@oracle.com" <annie.li@oracle.com>,
	Paul Durrant <Paul.Durrant@citrix.com>,
	"steve.prochniak@oracle.com" <steve.prochniak@oracle.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 1/2] Add a new pvdrivers header to serve as
 the register of product numbers.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-09-26 at 13:49 +0100, Konrad Rzeszutek Wilk wrote:
> On Wed, Sep 26, 2012 at 01:23:31PM +0100, Paul Durrant wrote:
> > These product numbers are used by the QEMU blacklisting protocol in
> > traditional QEMU and are currently coded directly into the xenstore.c
> > source module. Since there are now multiple QEMUs this information
> > should be pulled into a public header to avoid duplication/conflict.
> > hvm-emulated-unplug.markdown has also been adjusted to reference the
> > new header.
> > 
> > Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
> > ---
> >  docs/misc/hvm-emulated-unplug.markdown |    2 +-
> >  xen/include/public/hvm/pvdrivers.h     |   50 ++++++++++++++++++++++++++++++++
> >  2 files changed, 51 insertions(+), 1 deletions(-)
> >  create mode 100644 xen/include/public/hvm/pvdrivers.h
> > 
> > diff --git a/docs/misc/hvm-emulated-unplug.markdown b/docs/misc/hvm-emulated-unplug.markdown
> > index 707fbab..ec9ce83 100644
> > --- a/docs/misc/hvm-emulated-unplug.markdown
> > +++ b/docs/misc/hvm-emulated-unplug.markdown
> > @@ -65,4 +65,4 @@ decimal number.  `{product_name}` is a string corresponding to the
> >  product number in step 3.
> >  
> >  The master registry of product names and numbers is in
> > -qemu-xen-unstable's xenstore.c.
> > +xen/include/public/hvm/pvdrivers.h
> > diff --git a/xen/include/public/hvm/pvdrivers.h b/xen/include/public/hvm/pvdrivers.h
> > new file mode 100644
> > index 0000000..4be57ac
> > --- /dev/null
> > +++ b/xen/include/public/hvm/pvdrivers.h
> > @@ -0,0 +1,50 @@
> > +/*
> > + * pvdrivers.h: Register of PV drivers product numbers.
> > + * Copyright (c) 2012, Citrix Systems Inc.
> > + * 
> > + * Permission is hereby granted, free of charge, to any person obtaining a copy
> > + * of this software and associated documentation files (the "Software"), to
> > + * deal in the Software without restriction, including without limitation the
> > + * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or
> > + * sell copies of the Software, and to permit persons to whom the Software is
> > + * furnished to do so, subject to the following conditions:
> > + *
> > + * The above copyright notice and this permission notice shall be included in
> > + * all copies or substantial portions of the Software.
> > + *
> > + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
> > + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> > + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
> > + * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
> > + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> > + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
> > + * DEALINGS IN THE SOFTWARE.
> > + */
> > +
> > +#ifndef _XEN_PUBLIC_PVDRIVERS_H_
> > +#define _XEN_PUBLIC_PVDRIVERS_H_
> > +
> > +/*
> > + * This is the master registry of product numbers for
> > + * PV drivers. 
> > + * If you need a new product number allocating, please
> > + * post to xen-devel@lists.xensource.com.  You should NOT use
> > + * a product number without allocating one.
> > + * If you maintain a separate versioning and distribution path
> > + * for PV drivers you should have a separate product number so
> > + * that your drivers can be separated from others.
> > + *
> > + * During development, you may use the product ID to
> > + * indicate a driver which is yet to be released.
> > + */
> > +
> > +#define	PVDRIVERS_XENSOURCE_WINDOWS_ID		0x0001	/* Citrix */
> > +#define	PVDRIVERS_XENSOURCE_WINDOWS_NAME	"xensource-windows"
> > +
> > +#define	PVDRIVERS_GPLPV_WINDOWS_ID		0x0002	/* James Harper */
> > +#define	PVDRIVERS_GPLPV_WINDOWS_NAME		"gplpv-windows"
> 
> And also the Oracle one :-)

Oracle is using 0x0002? That would be unfortunate...

> 
> The Novell one looks to be using 107?
> > +
> > +#define	PVDRIVERS_EXPERIMENTAL_ID		0xffff
> > +#define	PVDRIVERS_EXPERIMENTAL_NAME		"experimental"
> > +
> > +#endif /* _XEN_PUBLIC_PVDRIVERS_H_ */
> > -- 
> > 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



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 26 13:06:58 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Sep 2012 13: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 1TGrKA-0004M4-M8; Wed, 26 Sep 2012 13:06:46 +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 1TGrK8-0004Lg-Qk
	for xen-devel@lists.xen.org; Wed, 26 Sep 2012 13:06:45 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1348664739!5455102!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTE1NzQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24123 invoked from network); 26 Sep 2012 13:05:39 -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 Sep 2012 13:05:39 -0000
X-IronPort-AV: E=Sophos;i="4.80,490,1344211200"; d="scan'208";a="14777131"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Sep 2012 13:05:38 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 26 Sep 2012 14:05:38 +0100
Message-ID: <1348664737.19176.34.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Konrad Rzeszutek Wilk <konrad@kernel.org>
Date: Wed, 26 Sep 2012 14:05:37 +0100
In-Reply-To: <20120926124915.GH7356@phenom.dumpdata.com>
References: <1348662212-3559-1-git-send-email-paul.durrant@citrix.com>
	<1348662212-3559-2-git-send-email-paul.durrant@citrix.com>
	<20120926124915.GH7356@phenom.dumpdata.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "annie.li@oracle.com" <annie.li@oracle.com>,
	Paul Durrant <Paul.Durrant@citrix.com>,
	"steve.prochniak@oracle.com" <steve.prochniak@oracle.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 1/2] Add a new pvdrivers header to serve as
 the register of product numbers.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-09-26 at 13:49 +0100, Konrad Rzeszutek Wilk wrote:
> On Wed, Sep 26, 2012 at 01:23:31PM +0100, Paul Durrant wrote:
> > These product numbers are used by the QEMU blacklisting protocol in
> > traditional QEMU and are currently coded directly into the xenstore.c
> > source module. Since there are now multiple QEMUs this information
> > should be pulled into a public header to avoid duplication/conflict.
> > hvm-emulated-unplug.markdown has also been adjusted to reference the
> > new header.
> > 
> > Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
> > ---
> >  docs/misc/hvm-emulated-unplug.markdown |    2 +-
> >  xen/include/public/hvm/pvdrivers.h     |   50 ++++++++++++++++++++++++++++++++
> >  2 files changed, 51 insertions(+), 1 deletions(-)
> >  create mode 100644 xen/include/public/hvm/pvdrivers.h
> > 
> > diff --git a/docs/misc/hvm-emulated-unplug.markdown b/docs/misc/hvm-emulated-unplug.markdown
> > index 707fbab..ec9ce83 100644
> > --- a/docs/misc/hvm-emulated-unplug.markdown
> > +++ b/docs/misc/hvm-emulated-unplug.markdown
> > @@ -65,4 +65,4 @@ decimal number.  `{product_name}` is a string corresponding to the
> >  product number in step 3.
> >  
> >  The master registry of product names and numbers is in
> > -qemu-xen-unstable's xenstore.c.
> > +xen/include/public/hvm/pvdrivers.h
> > diff --git a/xen/include/public/hvm/pvdrivers.h b/xen/include/public/hvm/pvdrivers.h
> > new file mode 100644
> > index 0000000..4be57ac
> > --- /dev/null
> > +++ b/xen/include/public/hvm/pvdrivers.h
> > @@ -0,0 +1,50 @@
> > +/*
> > + * pvdrivers.h: Register of PV drivers product numbers.
> > + * Copyright (c) 2012, Citrix Systems Inc.
> > + * 
> > + * Permission is hereby granted, free of charge, to any person obtaining a copy
> > + * of this software and associated documentation files (the "Software"), to
> > + * deal in the Software without restriction, including without limitation the
> > + * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or
> > + * sell copies of the Software, and to permit persons to whom the Software is
> > + * furnished to do so, subject to the following conditions:
> > + *
> > + * The above copyright notice and this permission notice shall be included in
> > + * all copies or substantial portions of the Software.
> > + *
> > + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
> > + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> > + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
> > + * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
> > + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> > + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
> > + * DEALINGS IN THE SOFTWARE.
> > + */
> > +
> > +#ifndef _XEN_PUBLIC_PVDRIVERS_H_
> > +#define _XEN_PUBLIC_PVDRIVERS_H_
> > +
> > +/*
> > + * This is the master registry of product numbers for
> > + * PV drivers. 
> > + * If you need a new product number allocating, please
> > + * post to xen-devel@lists.xensource.com.  You should NOT use
> > + * a product number without allocating one.
> > + * If you maintain a separate versioning and distribution path
> > + * for PV drivers you should have a separate product number so
> > + * that your drivers can be separated from others.
> > + *
> > + * During development, you may use the product ID to
> > + * indicate a driver which is yet to be released.
> > + */
> > +
> > +#define	PVDRIVERS_XENSOURCE_WINDOWS_ID		0x0001	/* Citrix */
> > +#define	PVDRIVERS_XENSOURCE_WINDOWS_NAME	"xensource-windows"
> > +
> > +#define	PVDRIVERS_GPLPV_WINDOWS_ID		0x0002	/* James Harper */
> > +#define	PVDRIVERS_GPLPV_WINDOWS_NAME		"gplpv-windows"
> 
> And also the Oracle one :-)

Oracle is using 0x0002? That would be unfortunate...

> 
> The Novell one looks to be using 107?
> > +
> > +#define	PVDRIVERS_EXPERIMENTAL_ID		0xffff
> > +#define	PVDRIVERS_EXPERIMENTAL_NAME		"experimental"
> > +
> > +#endif /* _XEN_PUBLIC_PVDRIVERS_H_ */
> > -- 
> > 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



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 26 13:08:38 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Sep 2012 13:08: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 1TGrLn-0004ST-5h; Wed, 26 Sep 2012 13:08: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 1TGrLl-0004SK-9c
	for xen-devel@lists.xen.org; Wed, 26 Sep 2012 13:08:25 +0000
Received: from [85.158.139.83:10876] by server-9.bemta-5.messagelabs.com id
	8F/87-14846-84EF2605; Wed, 26 Sep 2012 13:08:24 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1348664903!24994957!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTE1NzQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19741 invoked from network); 26 Sep 2012 13:08:24 -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;
	26 Sep 2012 13:08:24 -0000
X-IronPort-AV: E=Sophos;i="4.80,490,1344211200"; d="scan'208";a="14777222"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Sep 2012 13:08: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.279.1;
	Wed, 26 Sep 2012 14:08:23 +0100
Message-ID: <1348664902.19176.36.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Konrad Rzeszutek Wilk <konrad@kernel.org>
Date: Wed, 26 Sep 2012 14:08:22 +0100
In-Reply-To: <20120926125148.GI7356@phenom.dumpdata.com>
References: <1348662212-3559-1-git-send-email-paul.durrant@citrix.com>
	<20120926125148.GI7356@phenom.dumpdata.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Paul Durrant <Paul.Durrant@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 0/2] PV drivers product number registration
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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-09-26 at 13:51 +0100, Konrad Rzeszutek Wilk wrote:
> On Wed, Sep 26, 2012 at 01:23:30PM +0100, Paul Durrant wrote:
> > PV drivers in HVM guests typically make use off an 'unplug' protocol in QEMU
> > to prevent co-existence of emulated devices.
> > See docs/misc/hvm-emulated-unplug.markdown for details.
> > 
> > The register of product numbers used by the blacklisting feature of this
> > protocol is currently directly in the xenstore.c source module of
> > traditional QEMU. It should really be in a Xen header file to prevent
> 
> Why do we want to blacklist them? Isn't it a whitelist (as in it is
> the right values?)

We don't *want* to blacklist them, but this gives us a mechanism whereby
in the future we can blacklist drivers which turn out to be buggy from
the host level (via qemu). See docs/misc/hvm-emulated-unplug.markdown

AFAIK qemu currently doesn't blacklist anything.

Ian.

> 
> > duplication/conflict between QEMU versions.
> > 
> > Moreover the linux PV-on-HVM drivers make use of product number 3 seemingly
> > without ever registering that number.
> > 
> > This patch series introduces a new header and registers product number 3
> > for Linux's use. A subsequent patch to qemu-xen-unstable wll be created to
> > make use of the new header.
> > 
> > Signed-off-by: Paul Durrant <paul.durrant@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 Wed Sep 26 13:08:38 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Sep 2012 13:08: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 1TGrLn-0004ST-5h; Wed, 26 Sep 2012 13:08: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 1TGrLl-0004SK-9c
	for xen-devel@lists.xen.org; Wed, 26 Sep 2012 13:08:25 +0000
Received: from [85.158.139.83:10876] by server-9.bemta-5.messagelabs.com id
	8F/87-14846-84EF2605; Wed, 26 Sep 2012 13:08:24 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1348664903!24994957!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTE1NzQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19741 invoked from network); 26 Sep 2012 13:08:24 -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;
	26 Sep 2012 13:08:24 -0000
X-IronPort-AV: E=Sophos;i="4.80,490,1344211200"; d="scan'208";a="14777222"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Sep 2012 13:08: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.279.1;
	Wed, 26 Sep 2012 14:08:23 +0100
Message-ID: <1348664902.19176.36.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Konrad Rzeszutek Wilk <konrad@kernel.org>
Date: Wed, 26 Sep 2012 14:08:22 +0100
In-Reply-To: <20120926125148.GI7356@phenom.dumpdata.com>
References: <1348662212-3559-1-git-send-email-paul.durrant@citrix.com>
	<20120926125148.GI7356@phenom.dumpdata.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: Paul Durrant <Paul.Durrant@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 0/2] PV drivers product number registration
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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-09-26 at 13:51 +0100, Konrad Rzeszutek Wilk wrote:
> On Wed, Sep 26, 2012 at 01:23:30PM +0100, Paul Durrant wrote:
> > PV drivers in HVM guests typically make use off an 'unplug' protocol in QEMU
> > to prevent co-existence of emulated devices.
> > See docs/misc/hvm-emulated-unplug.markdown for details.
> > 
> > The register of product numbers used by the blacklisting feature of this
> > protocol is currently directly in the xenstore.c source module of
> > traditional QEMU. It should really be in a Xen header file to prevent
> 
> Why do we want to blacklist them? Isn't it a whitelist (as in it is
> the right values?)

We don't *want* to blacklist them, but this gives us a mechanism whereby
in the future we can blacklist drivers which turn out to be buggy from
the host level (via qemu). See docs/misc/hvm-emulated-unplug.markdown

AFAIK qemu currently doesn't blacklist anything.

Ian.

> 
> > duplication/conflict between QEMU versions.
> > 
> > Moreover the linux PV-on-HVM drivers make use of product number 3 seemingly
> > without ever registering that number.
> > 
> > This patch series introduces a new header and registers product number 3
> > for Linux's use. A subsequent patch to qemu-xen-unstable wll be created to
> > make use of the new header.
> > 
> > Signed-off-by: Paul Durrant <paul.durrant@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 Wed Sep 26 13:16:22 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Sep 2012 13: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 1TGrTF-0004hP-6c; Wed, 26 Sep 2012 13:16:09 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Paul.Durrant@citrix.com>) id 1TGrTE-0004hK-0z
	for xen-devel@lists.xen.org; Wed, 26 Sep 2012 13:16:08 +0000
Received: from [85.158.139.83:51052] by server-8.bemta-5.messagelabs.com id
	F7/CC-18073-71003605; Wed, 26 Sep 2012 13:16:07 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1348665366!27688281!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTE1NzQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1986 invoked from network); 26 Sep 2012 13:16:06 -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;
	26 Sep 2012 13:16:06 -0000
X-IronPort-AV: E=Sophos;i="4.80,490,1344211200"; d="scan'208";a="14777429"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Sep 2012 13:16:06 +0000
Received: from LONPMAILBOX01.citrite.net ([10.30.224.160]) by
	LONPMAILMX01.citrite.net ([10.30.203.162]) with mapi; Wed, 26 Sep 2012
	14:16:06 +0100
From: Paul Durrant <Paul.Durrant@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Wed, 26 Sep 2012 14:16:23 +0100
Thread-Topic: [Xen-devel] [PATCH 1/2] Add a new pvdrivers header to serve as
	the register of product numbers.
Thread-Index: Ac2b5MhCbDhy9fMiTeWObE6YvF9U4gABDgfA
Message-ID: <291EDFCB1E9E224A99088639C4762022EFF91D9B74@LONPMAILBOX01.citrite.net>
References: <1348662212-3559-1-git-send-email-paul.durrant@citrix.com>
	<1348662212-3559-2-git-send-email-paul.durrant@citrix.com>
	<5063150E020000780009DFD9@nat28.tlf.novell.com>
In-Reply-To: <5063150E020000780009DFD9@nat28.tlf.novell.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 1/2] Add a new pvdrivers header to serve as
 the register of product numbers.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> -----Original Message-----
> From: Jan Beulich [mailto:JBeulich@suse.com]
> Sent: 26 September 2012 13:46
> To: Paul Durrant
> Cc: xen-devel@lists.xen.org
> Subject: Re: [Xen-devel] [PATCH 1/2] Add a new pvdrivers header to serve
> as the register of product numbers.
> 
> >>> On 26.09.12 at 14:23, Paul Durrant <paul.durrant@citrix.com> wrote:
> > --- /dev/null
> > +++ b/xen/include/public/hvm/pvdrivers.h
> > @@ -0,0 +1,50 @@
> > +/*
> > + * pvdrivers.h: Register of PV drivers product numbers.
> > + * Copyright (c) 2012, Citrix Systems Inc.
> > + *
> > + * Permission is hereby granted, free of charge, to any person obtaining a
> copy
> > + * of this software and associated documentation files (the "Software"),
> to
> > + * deal in the Software without restriction, including without limitation
> the
> > + * rights to use, copy, modify, merge, publish, distribute, sublicense,
> and/or
> > + * sell copies of the Software, and to permit persons to whom the
> Software is
> > + * furnished to do so, subject to the following conditions:
> > + *
> > + * The above copyright notice and this permission notice shall be
> included in
> > + * all copies or substantial portions of the Software.
> > + *
> > + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY
> KIND, EXPRESS OR
> > + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
> MERCHANTABILITY,
> > + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO
> EVENT SHALL THE
> > + * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM,
> DAMAGES OR OTHER
> > + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR
> OTHERWISE, ARISING
> > + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE
> OR OTHER
> > + * DEALINGS IN THE SOFTWARE.
> > + */
> > +
> > +#ifndef _XEN_PUBLIC_PVDRIVERS_H_
> > +#define _XEN_PUBLIC_PVDRIVERS_H_
> > +
> > +/*
> > + * This is the master registry of product numbers for
> > + * PV drivers.
> > + * If you need a new product number allocating, please
> > + * post to xen-devel@lists.xensource.com.  You should NOT use
> 
> @lists.xen.org
>

Good point. That was historic. I'll fix it up.
 
> > + * a product number without allocating one.
> > + * If you maintain a separate versioning and distribution path
> > + * for PV drivers you should have a separate product number so
> > + * that your drivers can be separated from others.
> > + *
> > + * During development, you may use the product ID to
> > + * indicate a driver which is yet to be released.
> 
> Which "the product ID"?
> 

The ones post-fixed '_ID'.

  Paul

> Jan
> 
> > + */
> > +
> > +#define	PVDRIVERS_XENSOURCE_WINDOWS_ID
> 	0x0001	/* Citrix */
> > +#define	PVDRIVERS_XENSOURCE_WINDOWS_NAME	"xensource-
> windows"
> > +
> > +#define	PVDRIVERS_GPLPV_WINDOWS_ID		0x0002	/*
> James Harper */
> > +#define	PVDRIVERS_GPLPV_WINDOWS_NAME		"gplpv-
> windows"
> > +
> > +#define	PVDRIVERS_EXPERIMENTAL_ID		0xffff
> > +#define	PVDRIVERS_EXPERIMENTAL_NAME
> 	"experimental"
> > +
> > +#endif /* _XEN_PUBLIC_PVDRIVERS_H_ */
> > --
> > 1.7.2.5
> >
> >
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xen.org
> > http://lists.xen.org/xen-devel
> 
> 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 26 13:16:22 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Sep 2012 13: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 1TGrTF-0004hP-6c; Wed, 26 Sep 2012 13:16:09 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Paul.Durrant@citrix.com>) id 1TGrTE-0004hK-0z
	for xen-devel@lists.xen.org; Wed, 26 Sep 2012 13:16:08 +0000
Received: from [85.158.139.83:51052] by server-8.bemta-5.messagelabs.com id
	F7/CC-18073-71003605; Wed, 26 Sep 2012 13:16:07 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1348665366!27688281!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTE1NzQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1986 invoked from network); 26 Sep 2012 13:16:06 -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;
	26 Sep 2012 13:16:06 -0000
X-IronPort-AV: E=Sophos;i="4.80,490,1344211200"; d="scan'208";a="14777429"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Sep 2012 13:16:06 +0000
Received: from LONPMAILBOX01.citrite.net ([10.30.224.160]) by
	LONPMAILMX01.citrite.net ([10.30.203.162]) with mapi; Wed, 26 Sep 2012
	14:16:06 +0100
From: Paul Durrant <Paul.Durrant@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Wed, 26 Sep 2012 14:16:23 +0100
Thread-Topic: [Xen-devel] [PATCH 1/2] Add a new pvdrivers header to serve as
	the register of product numbers.
Thread-Index: Ac2b5MhCbDhy9fMiTeWObE6YvF9U4gABDgfA
Message-ID: <291EDFCB1E9E224A99088639C4762022EFF91D9B74@LONPMAILBOX01.citrite.net>
References: <1348662212-3559-1-git-send-email-paul.durrant@citrix.com>
	<1348662212-3559-2-git-send-email-paul.durrant@citrix.com>
	<5063150E020000780009DFD9@nat28.tlf.novell.com>
In-Reply-To: <5063150E020000780009DFD9@nat28.tlf.novell.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 1/2] Add a new pvdrivers header to serve as
 the register of product numbers.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> -----Original Message-----
> From: Jan Beulich [mailto:JBeulich@suse.com]
> Sent: 26 September 2012 13:46
> To: Paul Durrant
> Cc: xen-devel@lists.xen.org
> Subject: Re: [Xen-devel] [PATCH 1/2] Add a new pvdrivers header to serve
> as the register of product numbers.
> 
> >>> On 26.09.12 at 14:23, Paul Durrant <paul.durrant@citrix.com> wrote:
> > --- /dev/null
> > +++ b/xen/include/public/hvm/pvdrivers.h
> > @@ -0,0 +1,50 @@
> > +/*
> > + * pvdrivers.h: Register of PV drivers product numbers.
> > + * Copyright (c) 2012, Citrix Systems Inc.
> > + *
> > + * Permission is hereby granted, free of charge, to any person obtaining a
> copy
> > + * of this software and associated documentation files (the "Software"),
> to
> > + * deal in the Software without restriction, including without limitation
> the
> > + * rights to use, copy, modify, merge, publish, distribute, sublicense,
> and/or
> > + * sell copies of the Software, and to permit persons to whom the
> Software is
> > + * furnished to do so, subject to the following conditions:
> > + *
> > + * The above copyright notice and this permission notice shall be
> included in
> > + * all copies or substantial portions of the Software.
> > + *
> > + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY
> KIND, EXPRESS OR
> > + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
> MERCHANTABILITY,
> > + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO
> EVENT SHALL THE
> > + * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM,
> DAMAGES OR OTHER
> > + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR
> OTHERWISE, ARISING
> > + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE
> OR OTHER
> > + * DEALINGS IN THE SOFTWARE.
> > + */
> > +
> > +#ifndef _XEN_PUBLIC_PVDRIVERS_H_
> > +#define _XEN_PUBLIC_PVDRIVERS_H_
> > +
> > +/*
> > + * This is the master registry of product numbers for
> > + * PV drivers.
> > + * If you need a new product number allocating, please
> > + * post to xen-devel@lists.xensource.com.  You should NOT use
> 
> @lists.xen.org
>

Good point. That was historic. I'll fix it up.
 
> > + * a product number without allocating one.
> > + * If you maintain a separate versioning and distribution path
> > + * for PV drivers you should have a separate product number so
> > + * that your drivers can be separated from others.
> > + *
> > + * During development, you may use the product ID to
> > + * indicate a driver which is yet to be released.
> 
> Which "the product ID"?
> 

The ones post-fixed '_ID'.

  Paul

> Jan
> 
> > + */
> > +
> > +#define	PVDRIVERS_XENSOURCE_WINDOWS_ID
> 	0x0001	/* Citrix */
> > +#define	PVDRIVERS_XENSOURCE_WINDOWS_NAME	"xensource-
> windows"
> > +
> > +#define	PVDRIVERS_GPLPV_WINDOWS_ID		0x0002	/*
> James Harper */
> > +#define	PVDRIVERS_GPLPV_WINDOWS_NAME		"gplpv-
> windows"
> > +
> > +#define	PVDRIVERS_EXPERIMENTAL_ID		0xffff
> > +#define	PVDRIVERS_EXPERIMENTAL_NAME
> 	"experimental"
> > +
> > +#endif /* _XEN_PUBLIC_PVDRIVERS_H_ */
> > --
> > 1.7.2.5
> >
> >
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xen.org
> > http://lists.xen.org/xen-devel
> 
> 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 26 13:24:54 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Sep 2012 13:24: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 1TGrbS-0004rP-58; Wed, 26 Sep 2012 13:24:38 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1TGrbR-0004rJ-1x
	for Xen-devel@lists.xensource.com; Wed, 26 Sep 2012 13:24:37 +0000
Received: from [85.158.139.83:44373] by server-7.bemta-5.messagelabs.com id
	C8/0C-00431-41203605; Wed, 26 Sep 2012 13:24:36 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1348665867!32041192!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzY1NzE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24181 invoked from network); 26 Sep 2012 13:24:28 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-12.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 26 Sep 2012 13:24:28 -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 q8QDOJiO028622
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 26 Sep 2012 13:24:20 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
	q8QDOJ6X023782
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 26 Sep 2012 13:24:19 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
	q8QDOIei008033; Wed, 26 Sep 2012 08:24:19 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 26 Sep 2012 06:24:18 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 27E6E402E4; Wed, 26 Sep 2012 09:13:00 -0400 (EDT)
Date: Wed, 26 Sep 2012 09:13:00 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Mukesh Rathor <mukesh.rathor@oracle.com>
Message-ID: <20120926131300.GB9309@phenom.dumpdata.com>
References: <20120921122123.33489ce1@mantra.us.oracle.com>
	<alpine.DEB.2.02.1209241504410.29232@kaball.uk.xensource.com>
	<20120925182848.52978702@mantra.us.oracle.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120925182848.52978702@mantra.us.oracle.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>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v1 7/8]: PVH privcmd changes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Sep 25, 2012 at 06:28:48PM -0700, Mukesh Rathor wrote:
> On Mon, 24 Sep 2012 15:24:16 +0100
> Stefano Stabellini <stefano.stabellini@eu.citrix.com> wrote:
> 
> > On Fri, 21 Sep 2012, Mukesh Rathor wrote:
> > > ---
> > >  drivers/xen/privcmd.c |   77
> > > ++++++++++++++++++++++++++++++++++++++++++++---- 1 files changed,
> > > 70 insertions(+), 7 deletions(-)
> > > 
> > > diff --git a/drivers/xen/privcmd.c b/drivers/xen/privcmd.c
> > > index ccee0f1..195d89f 100644
> > > -				       st->vma->vm_page_prot,
> > > st->domain) < 0) {
> > > +	if (xen_remap_domain_mfn_range(vma, st->va & PAGE_MASK,
> > > *mfnp, 1,
> > > +				       vma->vm_page_prot,
> > > st->domain, 
> > > +				       pvhp) < 0) {
> > >  		*mfnp |= 0xf0000000U;
> > >  		st->err++;
> > >  	}
> > 
> > I don't like that a parameter like "xen_pvh_pfn_info" has been added
> > to a generic arch-agnostic function like xen_remap_domain_mfn_range.
> > 
> > If you need to pass more parameters to xen_remap_domain_mfn_range, it
> > should be done in a cross-architecture way. In fact, keep in mind that
> > privcmd.c compiles on ARM (and IA64?) as well.
> > 
> > I think that in this particular case you are using pvh to actually
> > specify auto_translate_physmap, am I correct?
> > Maybe we just need to rename xen_pvh_pfn_info to xen_xlat_pfn_info.
> 
> Ok, I renamed it. And for the API, as I mentioned in prev email,
> I changed xen_remap_domain_mfn_range to have last parameter be 
> called void *arch_specific_info.
> 
> > 
> > > @@ -274,6 +284,40 @@ static int mmap_return_errors(void *data, void
> > > +		return -ENOMEM;
> > > +	}
> > > +
> > > +	rc = alloc_xenballooned_pages(numpgs, pvhp->pi_paga, 0);
> > > +	if (rc != 0) {
> > > +		pr_warn("%s Could not alloc %d pfns rc:%d\n",
> > > __FUNCTION__, 
> > > +			numpgs, rc);
> > > +		kfree(pvhp->pi_paga);
> > > +		kfree(pvhp);
> > > +		return -ENOMEM;
> > > +	}
> > > +	pvhp->pi_num_pgs = numpgs;
> > > +	BUG_ON(vma->vm_private_data != (void *)1);
> > 
> > what?
> 

Make sure you have a comment explaining it in here. In 3 months
neither you or me are going to recall why this is there.

Can the 1 become a #define?

> See privcmd_enforce_singleshot_mapping().
> 
> > >  
> > > +	if (xen_pv_domain() &&
> > > xen_feature(XENFEAT_auto_translated_physmap)) {
> > > +		if ((ret=pvh_privcmd_resv_pfns(vma, m.num))) {
> > 
> > I would change this into:
> > 
> >     if ((ret = pvh_privcmd_resv_pfns(vma, m.num)) < 0) {
> > 
> 
> OK.
> 
> 
> > > +	count = xen_unmap_domain_mfn_range(vma, pvhp);
> > > +	while (count--)
> > > +		free_xenballooned_pages(1, &pvhp->pi_paga[count]);
> > > +	kfree(pvhp->pi_paga);
> > > +	kfree(pvhp);
> > 
> > So xen_remap_domain_mfn_range adds the mappings to the vma, while
> > xen_unmap_domain_mfn_range does not remove them. I take that somehow
> > this is done by the generic Linux code that calls into this function?
> 
> Correct. The kernel MMU seems to do all cleanup before calling
> privcmd_close.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 26 13:24:54 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Sep 2012 13:24: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 1TGrbS-0004rP-58; Wed, 26 Sep 2012 13:24:38 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1TGrbR-0004rJ-1x
	for Xen-devel@lists.xensource.com; Wed, 26 Sep 2012 13:24:37 +0000
Received: from [85.158.139.83:44373] by server-7.bemta-5.messagelabs.com id
	C8/0C-00431-41203605; Wed, 26 Sep 2012 13:24:36 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1348665867!32041192!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzY1NzE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24181 invoked from network); 26 Sep 2012 13:24:28 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-12.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 26 Sep 2012 13:24:28 -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 q8QDOJiO028622
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 26 Sep 2012 13:24:20 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
	q8QDOJ6X023782
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 26 Sep 2012 13:24:19 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
	q8QDOIei008033; Wed, 26 Sep 2012 08:24:19 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 26 Sep 2012 06:24:18 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 27E6E402E4; Wed, 26 Sep 2012 09:13:00 -0400 (EDT)
Date: Wed, 26 Sep 2012 09:13:00 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Mukesh Rathor <mukesh.rathor@oracle.com>
Message-ID: <20120926131300.GB9309@phenom.dumpdata.com>
References: <20120921122123.33489ce1@mantra.us.oracle.com>
	<alpine.DEB.2.02.1209241504410.29232@kaball.uk.xensource.com>
	<20120925182848.52978702@mantra.us.oracle.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120925182848.52978702@mantra.us.oracle.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>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v1 7/8]: PVH privcmd changes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Sep 25, 2012 at 06:28:48PM -0700, Mukesh Rathor wrote:
> On Mon, 24 Sep 2012 15:24:16 +0100
> Stefano Stabellini <stefano.stabellini@eu.citrix.com> wrote:
> 
> > On Fri, 21 Sep 2012, Mukesh Rathor wrote:
> > > ---
> > >  drivers/xen/privcmd.c |   77
> > > ++++++++++++++++++++++++++++++++++++++++++++---- 1 files changed,
> > > 70 insertions(+), 7 deletions(-)
> > > 
> > > diff --git a/drivers/xen/privcmd.c b/drivers/xen/privcmd.c
> > > index ccee0f1..195d89f 100644
> > > -				       st->vma->vm_page_prot,
> > > st->domain) < 0) {
> > > +	if (xen_remap_domain_mfn_range(vma, st->va & PAGE_MASK,
> > > *mfnp, 1,
> > > +				       vma->vm_page_prot,
> > > st->domain, 
> > > +				       pvhp) < 0) {
> > >  		*mfnp |= 0xf0000000U;
> > >  		st->err++;
> > >  	}
> > 
> > I don't like that a parameter like "xen_pvh_pfn_info" has been added
> > to a generic arch-agnostic function like xen_remap_domain_mfn_range.
> > 
> > If you need to pass more parameters to xen_remap_domain_mfn_range, it
> > should be done in a cross-architecture way. In fact, keep in mind that
> > privcmd.c compiles on ARM (and IA64?) as well.
> > 
> > I think that in this particular case you are using pvh to actually
> > specify auto_translate_physmap, am I correct?
> > Maybe we just need to rename xen_pvh_pfn_info to xen_xlat_pfn_info.
> 
> Ok, I renamed it. And for the API, as I mentioned in prev email,
> I changed xen_remap_domain_mfn_range to have last parameter be 
> called void *arch_specific_info.
> 
> > 
> > > @@ -274,6 +284,40 @@ static int mmap_return_errors(void *data, void
> > > +		return -ENOMEM;
> > > +	}
> > > +
> > > +	rc = alloc_xenballooned_pages(numpgs, pvhp->pi_paga, 0);
> > > +	if (rc != 0) {
> > > +		pr_warn("%s Could not alloc %d pfns rc:%d\n",
> > > __FUNCTION__, 
> > > +			numpgs, rc);
> > > +		kfree(pvhp->pi_paga);
> > > +		kfree(pvhp);
> > > +		return -ENOMEM;
> > > +	}
> > > +	pvhp->pi_num_pgs = numpgs;
> > > +	BUG_ON(vma->vm_private_data != (void *)1);
> > 
> > what?
> 

Make sure you have a comment explaining it in here. In 3 months
neither you or me are going to recall why this is there.

Can the 1 become a #define?

> See privcmd_enforce_singleshot_mapping().
> 
> > >  
> > > +	if (xen_pv_domain() &&
> > > xen_feature(XENFEAT_auto_translated_physmap)) {
> > > +		if ((ret=pvh_privcmd_resv_pfns(vma, m.num))) {
> > 
> > I would change this into:
> > 
> >     if ((ret = pvh_privcmd_resv_pfns(vma, m.num)) < 0) {
> > 
> 
> OK.
> 
> 
> > > +	count = xen_unmap_domain_mfn_range(vma, pvhp);
> > > +	while (count--)
> > > +		free_xenballooned_pages(1, &pvhp->pi_paga[count]);
> > > +	kfree(pvhp->pi_paga);
> > > +	kfree(pvhp);
> > 
> > So xen_remap_domain_mfn_range adds the mappings to the vma, while
> > xen_unmap_domain_mfn_range does not remove them. I take that somehow
> > this is done by the generic Linux code that calls into this function?
> 
> Correct. The kernel MMU seems to do all cleanup before calling
> privcmd_close.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 26 13:25:39 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Sep 2012 13: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 1TGrcH-0004uX-8L; Wed, 26 Sep 2012 13:25:29 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1TGrcF-0004u3-T9
	for Xen-devel@lists.xensource.com; Wed, 26 Sep 2012 13:25:28 +0000
Received: from [85.158.139.211:37132] by server-12.bemta-5.messagelabs.com id
	E2/FB-20729-74203605; Wed, 26 Sep 2012 13:25:27 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-206.messagelabs.com!1348665926!20058436!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTE1NzQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3322 invoked from network); 26 Sep 2012 13:25:26 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Sep 2012 13:25:26 -0000
X-IronPort-AV: E=Sophos;i="4.80,490,1344211200"; d="scan'208";a="14777718"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Sep 2012 13:25: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.279.1;
	Wed, 26 Sep 2012 14:25:26 +0100
Message-ID: <1348665924.19176.41.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Mukesh Rathor <mukesh.rathor@oracle.com>
Date: Wed, 26 Sep 2012 14:25:24 +0100
In-Reply-To: <20120921121202.3163c379@mantra.us.oracle.com>
References: <20120921121202.3163c379@mantra.us.oracle.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-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] [PATCH v1 0/8]: PVH (PV guest with extensions)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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-09-21 at 20:12 +0100, Mukesh Rathor wrote:
> Hi guys,
> 
> Ok, I've made all the changes from prev RFC patch submission. Tested
> all the combinations. The patches are a bit smaller from before, and
> couldn't be separated like before, so I can't state whats different in
> each patch. But, it's not too bad to review now.
> 
> As before, they were built on top of
> fc6bdb59a501740b28ed3b616641a22c8dc5dd31 from the following tree:
>         
> git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git

Is that correct? That's this commit:

commit fc6bdb59a501740b28ed3b616641a22c8dc5dd31
Merge: 44d82e2 1fcfd08
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date:   Thu Aug 2 11:52:39 2012 -0700

Why so old? Makes it hard to take these for a spin due to the
rebasing...

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 26 13:25:39 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Sep 2012 13: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 1TGrcH-0004uX-8L; Wed, 26 Sep 2012 13:25:29 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1TGrcF-0004u3-T9
	for Xen-devel@lists.xensource.com; Wed, 26 Sep 2012 13:25:28 +0000
Received: from [85.158.139.211:37132] by server-12.bemta-5.messagelabs.com id
	E2/FB-20729-74203605; Wed, 26 Sep 2012 13:25:27 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-206.messagelabs.com!1348665926!20058436!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTE1NzQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3322 invoked from network); 26 Sep 2012 13:25:26 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Sep 2012 13:25:26 -0000
X-IronPort-AV: E=Sophos;i="4.80,490,1344211200"; d="scan'208";a="14777718"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Sep 2012 13:25: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.279.1;
	Wed, 26 Sep 2012 14:25:26 +0100
Message-ID: <1348665924.19176.41.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Mukesh Rathor <mukesh.rathor@oracle.com>
Date: Wed, 26 Sep 2012 14:25:24 +0100
In-Reply-To: <20120921121202.3163c379@mantra.us.oracle.com>
References: <20120921121202.3163c379@mantra.us.oracle.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-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] [PATCH v1 0/8]: PVH (PV guest with extensions)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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-09-21 at 20:12 +0100, Mukesh Rathor wrote:
> Hi guys,
> 
> Ok, I've made all the changes from prev RFC patch submission. Tested
> all the combinations. The patches are a bit smaller from before, and
> couldn't be separated like before, so I can't state whats different in
> each patch. But, it's not too bad to review now.
> 
> As before, they were built on top of
> fc6bdb59a501740b28ed3b616641a22c8dc5dd31 from the following tree:
>         
> git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git

Is that correct? That's this commit:

commit fc6bdb59a501740b28ed3b616641a22c8dc5dd31
Merge: 44d82e2 1fcfd08
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date:   Thu Aug 2 11:52:39 2012 -0700

Why so old? Makes it hard to take these for a spin due to the
rebasing...

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 26 13:25:39 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Sep 2012 13: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 1TGrcF-0004u4-JS; Wed, 26 Sep 2012 13:25:27 +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 1TGrcD-0004tw-Ou
	for xen-devel@lists.xensource.com; Wed, 26 Sep 2012 13:25:26 +0000
Received: from [85.158.143.35:38905] by server-1.bemta-4.messagelabs.com id
	09/71-05684-44203605; Wed, 26 Sep 2012 13:25:24 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1348665916!13148415!1
X-Originating-IP: [209.85.215.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26853 invoked from network); 26 Sep 2012 13:25:16 -0000
Received: from mail-ey0-f171.google.com (HELO mail-ey0-f171.google.com)
	(209.85.215.171)
	by server-11.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Sep 2012 13:25:16 -0000
Received: by eaah11 with SMTP id h11so236133eaa.30
	for <xen-devel@lists.xensource.com>;
	Wed, 26 Sep 2012 06:25: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;
	bh=dk9m5PtFDj7ztv8gOQAq8/T+UZJNR7vyvhdxffifN/I=;
	b=A6i3G7680A9N5Zy5BIEJzefkiiM0Hdo6XCASn17nbipPlHMGXplCZFic3YMq2XUmK/
	e+qvebbS01ttDZSjHnweBCq2+8awVhz13Ewn4XOoLg/AYYWQYbNhFqIQY9xuQHyBCl02
	ZEYv5bGL+NHr5mwMXQD/J6qIRwmtlGoyKRWko9G9Oin1nTqO7HRrVGXKx4Gjw0gWTm6J
	wWNNPK9PQrsVV4WOQhLOk/ujqx7tmnjA2GplVEV7mI4R/8maODLUuIbD2X7WGgLYN0a+
	EGGsOESgGjDwuhXF0G9JgwXC586PDYixMfhR/jSoR2lx19ciOx7/65HPQpvGxfnwh8bw
	Q8Lg==
MIME-Version: 1.0
Received: by 10.14.201.73 with SMTP id a49mr869489eeo.39.1348665916044; Wed,
	26 Sep 2012 06:25:16 -0700 (PDT)
Received: by 10.14.215.195 with HTTP; Wed, 26 Sep 2012 06:25:15 -0700 (PDT)
In-Reply-To: <50579F53.4070302@jhuapl.edu>
References: <50579F53.4070302@jhuapl.edu>
Date: Wed, 26 Sep 2012 14:25:15 +0100
X-Google-Sender-Auth: 2z5sgRSicICFu5ZTcCvSKLqmGAU
Message-ID: <CAFLBxZY+cCBXvT_F-M5b78cQ+Hp+xMeJeE5WGbP+igfWsiTy9w@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
Cc: Samuel Thibault <samuel.thibault@ens-lyon.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH mini-os enhancements for vtpm 8/8] Add 3 tpm
 drivers to mini-os
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Sep 17, 2012 at 11:08 PM, Matthew Fioravante
<matthew.fioravante@jhuapl.edu> wrote:
> This patch adds 3 new drivers to mini-os.
>
> tpmfront - paravirtualized tpm frontend driver
> tpmback - paravirtualized tpm backend driver
> tpm_tis - hardware tpm driver

Just trying to understand this -- tpmback is so that you can run a
vtpm instance in the stubdom.  But what is tmpfront for?  Is that for
running qemu stub domains?

 -George

>
> Unfortunately these drivers were derived from GPL licensed linux kernel
> drivers so they must carry the GPL license. However, since mini-os now
> supports conditional compilation, hopefully these drivers can be
> included into the xen tree and conditionally removed from non-gpl
> projects. By default they are disabled in the makefile.
>
> Signed off by: Matthew Fioravante matthew.fioravante@jhuapl.edu
>
> diff --git a/extras/mini-os/Makefile b/extras/mini-os/Makefile
> --- a/extras/mini-os/Makefile
> +++ b/extras/mini-os/Makefile
> @@ -22,6 +22,9 @@ CONFIG_QEMU_XS_ARGS ?= n
>  CONFIG_TEST ?= n
>  CONFIG_PCIFRONT ?= n
>  CONFIG_BLKFRONT ?= y
> +CONFIG_TPMFRONT ?= n
> +CONFIG_TPM_TIS ?= n
> +CONFIG_TPMBACK ?= n
>  CONFIG_NETFRONT ?= y
>  CONFIG_FBFRONT ?= y
>  CONFIG_KBDFRONT ?= y
> @@ -36,6 +39,9 @@ flags-$(CONFIG_SPARSE_BSS) += -DCONFIG_SPARSE_BSS
>  flags-$(CONFIG_QEMU_XS_ARGS) += -DCONFIG_QEMU_XS_ARGS
>  flags-$(CONFIG_PCIFRONT) += -DCONFIG_PCIFRONT
>  flags-$(CONFIG_BLKFRONT) += -DCONFIG_BLKFRONT
> +flags-$(CONFIG_TPMFRONT) += -DCONFIG_TPMFRONT
> +flags-$(CONFIG_TPM_TIS) += -DCONFIG_TPM_TIS
> +flags-$(CONFIG_TPMBACK) += -DCONFIG_TPMBACK
>  flags-$(CONFIG_NETFRONT) += -DCONFIG_NETFRONT
>  flags-$(CONFIG_KBDFRONT) += -DCONFIG_KBDFRONT
>  flags-$(CONFIG_FBFRONT) += -DCONFIG_FBFRONT
> @@ -67,6 +73,9 @@ TARGET := mini-os
>  SUBDIRS := lib xenbus console
>
>  src-$(CONFIG_BLKFRONT) += blkfront.c
> +src-$(CONFIG_TPMFRONT) += tpmfront.c
> +src-$(CONFIG_TPM_TIS) += tpm_tis.c
> +src-$(CONFIG_TPMBACK) += tpmback.c
>  src-y += daytime.c
>  src-y += events.c
>  src-$(CONFIG_FBFRONT) += fbfront.c
> diff --git a/extras/mini-os/include/lib.h b/extras/mini-os/include/lib.h
> --- a/extras/mini-os/include/lib.h
> +++ b/extras/mini-os/include/lib.h
> @@ -142,6 +142,8 @@ enum fd_type {
>      FTYPE_FB,
>      FTYPE_MEM,
>      FTYPE_SAVEFILE,
> +    FTYPE_TPMFRONT,
> +    FTYPE_TPM_TIS,
>  };
>
>  LIST_HEAD(evtchn_port_list, evtchn_port_info);
> @@ -185,6 +187,20 @@ extern struct file {
>      struct {
>          struct consfront_dev *dev;
>      } cons;
> +#ifdef CONFIG_TPMFRONT
> +    struct {
> +       struct tpmfront_dev *dev;
> +       int respgot;
> +       off_t offset;
> +    } tpmfront;
> +#endif
> +#ifdef CONFIG_TPM_TIS
> +    struct {
> +       struct tpm_chip *dev;
> +       int respgot;
> +       off_t offset;
> +    } tpm_tis;
> +#endif
>  #ifdef CONFIG_XENBUS
>          struct {
>              /* To each xenbus FD is associated a queue of watch events
> for this
> diff --git a/extras/mini-os/include/tpm_tis.h
> b/extras/mini-os/include/tpm_tis.h
> --- /dev/null
> +++ b/extras/mini-os/include/tpm_tis.h
> @@ -0,0 +1,63 @@
> +/*
> + * Copyright (c) 2010-2012 United States Government, as represented by
> + * the Secretary of Defense.  All rights reserved.
> + *
> + * This driver 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 3 of the License, or
> + * (at your option) any later version.
> + *
> + * This driver is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program.  If not, see <http://www.gnu.org/licenses/>.
> + *
> + * Based upon the files:
> + *  drivers/char/tpm/tpm_tis.c
> + *  drivers/char/tpm/tpm.c
> + * from the Linux kernel, which are Copyright (C) 2006 IBM Corporation
> + */
> +#ifndef TPM_TIS_H
> +#define TPM_TIS_H
> +
> +#include <mini-os/types.h>
> +#include <mini-os/byteorder.h>
> +
> +#define TPM_TIS_EN_LOCL0 1
> +#define TPM_TIS_EN_LOCL1 (1 << 1)
> +#define TPM_TIS_EN_LOCL2 (1 << 2)
> +#define TPM_TIS_EN_LOCL3 (1 << 3)
> +#define TPM_TIS_EN_LOCL4 (1 << 4)
> +#define TPM_TIS_EN_LOCLALL (TPM_TIS_EN_LOCL0 | TPM_TIS_EN_LOCL1  |
> TPM_TIS_EN_LOCL2 | TPM_TIS_EN_LOCL3 | TPM_TIS_EN_LOCL4)
> +#define TPM_TIS_LOCL_INT_TO_FLAG(x) (1 << x)
> +#define TPM_BASEADDR 0xFED40000
> +#define TPM_PROBE_IRQ 0xFFFF
> +
> +struct tpm_chip;
> +
> +struct tpm_chip* init_tpm_tis(unsigned long baseaddr, int localities,
> unsigned int irq);
> +void shutdown_tpm_tis(struct tpm_chip* tpm);
> +
> +int tpm_tis_request_locality(struct tpm_chip* tpm, int locality);
> +int tpm_tis_cmd(struct tpm_chip* tpm, uint8_t* req, size_t reqlen,
> uint8_t** resp, size_t* resplen);
> +
> +#ifdef HAVE_LIBC
> +#include <sys/stat.h>
> +#include <fcntl.h>
> +/* POSIX IO functions:
> + * use tpm_tis_open() to get a file descriptor to the tpm device
> + * use write() on the fd to send a command to the backend. You must
> + * include the entire command in a single call to write().
> + * use read() on the fd to read the response. You can use
> + * fstat() to get the size of the response and lseek() to seek on it.
> + */
> +int tpm_tis_open(struct tpm_chip* tpm);
> +int tpm_tis_posix_read(int fd, uint8_t* buf, size_t count);
> +int tpm_tis_posix_write(int fd, const uint8_t* buf, size_t count);
> +int tpm_tis_posix_fstat(int fd, struct stat* buf);
> +#endif
> +
> +#endif
> diff --git a/extras/mini-os/include/tpmback.h
> b/extras/mini-os/include/tpmback.h
> --- /dev/null
> +++ b/extras/mini-os/include/tpmback.h
> @@ -0,0 +1,95 @@
> +/*
> + * Copyright (c) 2010-2012 United States Government, as represented by
> + * the Secretary of Defense.  All rights reserved.
> + *
> + * This driver 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 3 of the License, or
> + * (at your option) any later version.
> + *
> + * This driver is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program.  If not, see <http://www.gnu.org/licenses/>.
> + *
> + * Based upon the files:
> + *  drivers/xen/tpmbk.c
> + * from the Linux kernel, which are Copyright (C) 2006 IBM Corporation
> + */
> +#include <xen/io/tpmif.h>
> +#include <xen/io/xenbus.h>
> +#include <mini-os/types.h>
> +#include <xen/xen.h>
> +#ifndef TPMBACK_H
> +#define TPMBACK_H
> +
> +struct tpmcmd {
> +   domid_t domid;        /* Domid of the frontend */
> +   unsigned int handle;    /* Handle of the frontend */
> +   char* uuid;            /* uuid of the tpm interface - allocated
> internally, dont free it */
> +
> +   unsigned int req_len;        /* Size of the command in buf - set by
> tpmback driver */
> +   uint8_t* req;            /* tpm command bits, allocated by driver,
> DON'T FREE IT */
> +   unsigned int resp_len;    /* Size of the outgoing command,
> +                   you set this before passing the cmd object to
> tpmback_resp */
> +   uint8_t* resp;        /* Buffer for response - YOU MUST ALLOCATE IT,
> YOU MUST ALSO FREE IT */
> +};
> +typedef struct tpmcmd tpmcmd_t;
> +
> +/* Initialize the tpm backend driver
> + * @exclusive_domname - This is NULL terminated list of vtpm uuid
> strings. If this list
> + *             is non-empty, then only frontend domains with vtpm
> uuid's matching
> + *             entries in this list will be allowed to connect.
> + *             Other connections will be immediatly closed.
> + *             Set this argument to NULL to allow any vtpm to connect.
> + */
> +void init_tpmback(char** exclusive_uuids);
> +/* Shutdown tpm backend driver */
> +void shutdown_tpmback(void);
> +
> +/* Blocks until a tpm command is sent from any front end.
> + * Returns a pointer to the tpm command to handle.
> + * Do not try to free this pointer or the req buffer
> + * This function will return NULL if the tpm backend driver
> + * is shutdown or any other error occurs */
> +tpmcmd_t* tpmback_req_any(void);
> +
> +/* Blocks until a tpm command from the frontend at domid/handle
> + * is sent.
> + * Returns NULL if domid/handle is not connected, tpmback is
> + * shutdown or shutting down, or if there is an error
> + */
> +tpmcmd_t* tpmback_req(domid_t domid, unsigned int handle);
> +
> +/* Send the response to the tpm command back to the frontend
> + * This function will free the tpmcmd object, but you must free the resp
> + * buffer yourself */
> +void tpmback_resp(tpmcmd_t* tpmcmd);
> +
> +/* Waits for the first frontend to connect and then sets domid and
> handle appropriately.
> + * If one or more frontends are already connected, this will set domid
> and handle to one
> + * of them arbitrarily. The main use for this function is to wait until
> a single
> + * frontend connection has occured.
> + * returns 0 on success, non-zero on failure */
> +int tpmback_wait_for_frontend_connect(domid_t *domid, unsigned int
> *handle);
> +
> +/* returns the number of frontends connected */
> +int tpmback_num_frontends(void);
> +
> +/* Returns the uuid of the specified frontend, NULL on error */
> +char* tpmback_get_uuid(domid_t domid, unsigned int handle);
> +
> +/* Specify a function to call when a new tpm device connects */
> +void tpmback_set_open_callback(void (*cb)(domid_t, unsigned int));
> +
> +/* Specify a function to call when a tpm device disconnects */
> +void tpmback_set_close_callback(void (*cb)(domid_t, unsigned int));
> +
> +//Not Implemented
> +void tpmback_set_suspend_callback(void (*cb)(domid_t, unsigned int));
> +void tpmback_set_resume_callback(void (*cb)(domid_t, unsigned int));
> +
> +#endif
> diff --git a/extras/mini-os/include/tpmfront.h
> b/extras/mini-os/include/tpmfront.h
> --- /dev/null
> +++ b/extras/mini-os/include/tpmfront.h
> @@ -0,0 +1,94 @@
> +/*
> + * Copyright (c) 2010-2012 United States Government, as represented by
> + * the Secretary of Defense.  All rights reserved.
> + *
> + * This driver 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 3 of the License, or
> + * (at your option) any later version.
> + *
> + * This driver is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program.  If not, see <http://www.gnu.org/licenses/>.
> + *
> + * Based upon the files:
> + *  drivers/char/tpm/tpm_vtpm.c
> + *  drivers/char/tpm/tpm_xen.c
> + * from the Linux kernel, which are Copyright (C) 2006 IBM Corporation
> + */
> +#ifndef TPMFRONT_H
> +#define TPMFRONT_H
> +
> +#include <mini-os/types.h>
> +#include <mini-os/os.h>
> +#include <mini-os/events.h>
> +#include <mini-os/wait.h>
> +#include <xen/xen.h>
> +#include <xen/io/xenbus.h>
> +#include <xen/io/tpmif.h>
> +
> +struct tpmfront_dev {
> +   grant_ref_t ring_ref;
> +   evtchn_port_t evtchn;
> +
> +   tpmif_tx_interface_t* tx;
> +
> +   void** pages;
> +
> +   domid_t bedomid;
> +   char* nodename;
> +   char* bepath;
> +
> +   XenbusState state;
> +
> +   uint8_t waiting;
> +   struct wait_queue_head waitq;
> +
> +   uint8_t* respbuf;
> +   size_t resplen;
> +
> +#ifdef HAVE_LIBC
> +   int fd;
> +#endif
> +
> +};
> +
> +
> +/*Initialize frontend */
> +struct tpmfront_dev* init_tpmfront(const char* nodename);
> +/*Shutdown frontend */
> +void shutdown_tpmfront(struct tpmfront_dev* dev);
> +
> +/* Send a tpm command to the backend and wait for the response
> + *
> + * @dev - frontend device
> + * @req - request buffer
> + * @reqlen - length of request buffer
> + * @resp - *resp will be set to internal response buffer, don't free
> it! Value is undefined on error
> + * @resplen - *resplen will be set to the length of the response. Value
> is undefined on error
> + *
> + * returns 0 on success, non zero on failure.
> + * */
> +int tpmfront_cmd(struct tpmfront_dev* dev, uint8_t* req, size_t reqlen,
> uint8_t** resp, size_t* resplen);
> +
> +#ifdef HAVE_LIBC
> +#include <sys/stat.h>
> +/* POSIX IO functions:
> + * use tpmfront_open() to get a file descriptor to the tpm device
> + * use write() on the fd to send a command to the backend. You must
> + * include the entire command in a single call to write().
> + * use read() on the fd to read the response. You can use
> + * fstat() to get the size of the response and lseek() to seek on it.
> + */
> +int tpmfront_open(struct tpmfront_dev* dev);
> +int tpmfront_posix_read(int fd, uint8_t* buf, size_t count);
> +int tpmfront_posix_write(int fd, const uint8_t* buf, size_t count);
> +int tpmfront_posix_fstat(int fd, struct stat* buf);
> +#endif
> +
> +
> +#endif
> diff --git a/extras/mini-os/lib/sys.c b/extras/mini-os/lib/sys.c
> --- a/extras/mini-os/lib/sys.c
> +++ b/extras/mini-os/lib/sys.c
> @@ -27,6 +27,8 @@
>  #include <netfront.h>
>  #include <blkfront.h>
>  #include <fbfront.h>
> +#include <tpmfront.h>
> +#include <tpm_tis.h>
>  #include <xenbus.h>
>  #include <xenstore.h>
>
> @@ -294,6 +296,16 @@ int read(int fd, void *buf, size_t nbytes)
>          return blkfront_posix_read(fd, buf, nbytes);
>          }
>  #endif
> +#ifdef CONFIG_TPMFRONT
> +        case FTYPE_TPMFRONT: {
> +        return tpmfront_posix_read(fd, buf, nbytes);
> +        }
> +#endif
> +#ifdef CONFIG_TPM_TIS
> +        case FTYPE_TPM_TIS: {
> +        return tpm_tis_posix_read(fd, buf, nbytes);
> +        }
> +#endif
>      default:
>          break;
>      }
> @@ -330,6 +342,14 @@ int write(int fd, const void *buf, size_t nbytes)
>      case FTYPE_BLK:
>          return blkfront_posix_write(fd, buf, nbytes);
>  #endif
> +#ifdef CONFIG_TPMFRONT
> +    case FTYPE_TPMFRONT:
> +        return tpmfront_posix_write(fd, buf, nbytes);
> +#endif
> +#ifdef CONFIG_TPM_TIS
> +    case FTYPE_TPM_TIS:
> +        return tpm_tis_posix_write(fd, buf, nbytes);
> +#endif
>      default:
>          break;
>      }
> @@ -341,8 +361,16 @@ int write(int fd, const void *buf, size_t nbytes)
>  off_t lseek(int fd, off_t offset, int whence)
>  {
>      switch(files[fd].type) {
> +#if defined(CONFIG_BLKFRONT) || defined(CONFIG_TPMFRONT) ||
> defined(CONFIG_TPM_TIS)
>  #ifdef CONFIG_BLKFRONT
>         case FTYPE_BLK:
> +#endif
> +#ifdef CONFIG_TPMFRNT
> +       case FTYPE_TPMFRONT:
> +#endif
> +#ifdef CONFIG_TPM_TIS
> +       case FTYPE_TPM_TIS:
> +#endif
>        switch (whence) {
>           case SEEK_SET:
>          files[fd].file.offset = offset;
> @@ -420,6 +448,18 @@ int close(int fd)
>          files[fd].type = FTYPE_NONE;
>          return 0;
>  #endif
> +#ifdef CONFIG_TPMFRONT
> +    case FTYPE_TPMFRONT:
> +            shutdown_tpmfront(files[fd].tpmfront.dev);
> +        files[fd].type = FTYPE_NONE;
> +        return 0;
> +#endif
> +#ifdef CONFIG_TPM_TIS
> +    case FTYPE_TPM_TIS:
> +            shutdown_tpm_tis(files[fd].tpm_tis.dev);
> +        files[fd].type = FTYPE_NONE;
> +        return 0;
> +#endif
>  #ifdef CONFIG_KBDFRONT
>      case FTYPE_KBD:
>              shutdown_kbdfront(files[fd].kbd.dev);
> @@ -489,6 +529,14 @@ int fstat(int fd, struct stat *buf)
>      case FTYPE_BLK:
>         return blkfront_posix_fstat(fd, buf);
>  #endif
> +#ifdef CONFIG_TPMFRONT
> +    case FTYPE_TPMFRONT:
> +       return tpmfront_posix_fstat(fd, buf);
> +#endif
> +#ifdef CONFIG_TPM_TIS
> +    case FTYPE_TPM_TIS:
> +       return tpm_tis_posix_fstat(fd, buf);
> +#endif
>      default:
>          break;
>      }
> diff --git a/extras/mini-os/tpm_tis.c b/extras/mini-os/tpm_tis.c
> --- /dev/null
> +++ b/extras/mini-os/tpm_tis.c
> @@ -0,0 +1,1344 @@
> +/*
> + * Copyright (c) 2010-2012 United States Government, as represented by
> + * the Secretary of Defense.  All rights reserved.
> + *
> + * This driver 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 3 of the License, or
> + * (at your option) any later version.
> + *
> + * This driver is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program.  If not, see <http://www.gnu.org/licenses/>.
> + *
> + * Based upon the files:
> + *  drivers/char/tpm/tpm_tis.c
> + *  drivers/char/tpm/tpm.c
> + * from the Linux kernel, which are Copyright (C) 2006 IBM Corporation
> + */
> +#include <mini-os/ioremap.h>
> +#include <mini-os/iorw.h>
> +#include <mini-os/tpm_tis.h>
> +#include <mini-os/os.h>
> +#include <mini-os/sched.h>
> +#include <mini-os/byteorder.h>
> +#include <mini-os/events.h>
> +#include <mini-os/wait.h>
> +#include <mini-os/xmalloc.h>
> +#include <errno.h>
> +#include <stdbool.h>
> +
> +#ifndef min
> +    #define min( a, b ) ( ((a) < (b)) ? (a) : (b) )
> +#endif
> +
> +#define TPM_HEADER_SIZE 10
> +
> +#define TPM_BUFSIZE 2048
> +
> +struct tpm_input_header {
> +        uint16_t  tag;
> +        uint32_t  length;
> +        uint32_t  ordinal;
> +}__attribute__((packed));
> +
> +struct tpm_output_header {
> +        uint16_t  tag;
> +        uint32_t  length;
> +        uint32_t  return_code;
> +}__attribute__((packed));
> +
> +struct  stclear_flags_t {
> +        uint16_t  tag;
> +        uint8_t      deactivated;
> +        uint8_t      disableForceClear;
> +        uint8_t      physicalPresence;
> +        uint8_t      physicalPresenceLock;
> +        uint8_t      bGlobalLock;
> +}__attribute__((packed));
> +
> +struct  tpm_version_t {
> +        uint8_t      Major;
> +        uint8_t      Minor;
> +        uint8_t      revMajor;
> +        uint8_t      revMinor;
> +}__attribute__((packed));
> +
> +struct  tpm_version_1_2_t {
> +        uint16_t  tag;
> +        uint8_t      Major;
> +        uint8_t      Minor;
> +        uint8_t      revMajor;
> +        uint8_t      revMinor;
> +}__attribute__((packed));
> +
> +struct  timeout_t {
> +        uint32_t  a;
> +        uint32_t  b;
> +        uint32_t  c;
> +        uint32_t  d;
> +}__attribute__((packed));
> +
> +struct duration_t {
> +        uint32_t  tpm_short;
> +        uint32_t  tpm_medium;
> +        uint32_t  tpm_long;
> +}__attribute__((packed));
> +
> +struct permanent_flags_t {
> +        uint16_t  tag;
> +        uint8_t      disable;
> +        uint8_t      ownership;
> +        uint8_t      deactivated;
> +        uint8_t      readPubek;
> +        uint8_t      disableOwnerClear;
> +        uint8_t      allowMaintenance;
> +        uint8_t      physicalPresenceLifetimeLock;
> +        uint8_t      physicalPresenceHWEnable;
> +        uint8_t      physicalPresenceCMDEnable;
> +        uint8_t      CEKPUsed;
> +        uint8_t      TPMpost;
> +        uint8_t      TPMpostLock;
> +        uint8_t      FIPS;
> +        uint8_t      operator;
> +        uint8_t      enableRevokeEK;
> +        uint8_t      nvLocked;
> +        uint8_t      readSRKPub;
> +        uint8_t      tpmEstablished;
> +        uint8_t      maintenanceDone;
> +        uint8_t      disableFullDALogicInfo;
> +}__attribute__((packed));
> +
> +typedef union {
> +        struct  permanent_flags_t perm_flags;
> +        struct  stclear_flags_t stclear_flags;
> +        bool    owned;
> +        uint32_t  num_pcrs;
> +        struct  tpm_version_t   tpm_version;
> +        struct  tpm_version_1_2_t tpm_version_1_2;
> +        uint32_t  manufacturer_id;
> +        struct timeout_t  timeout;
> +        struct duration_t duration;
> +} cap_t;
> +
> +struct  tpm_getcap_params_in {
> +        uint32_t  cap;
> +        uint32_t  subcap_size;
> +        uint32_t  subcap;
> +}__attribute__((packed));
> +
> +struct  tpm_getcap_params_out {
> +        uint32_t  cap_size;
> +        cap_t   cap;
> +}__attribute__((packed));
> +
> +struct  tpm_readpubek_params_out {
> +        uint8_t      algorithm[4];
> +        uint8_t      encscheme[2];
> +        uint8_t      sigscheme[2];
> +        uint32_t  paramsize;
> +        uint8_t      parameters[12]; /*assuming RSA*/
> +        uint32_t  keysize;
> +        uint8_t      modulus[256];
> +        uint8_t      checksum[20];
> +}__attribute__((packed));
> +
> +typedef union {
> +        struct  tpm_input_header in;
> +        struct  tpm_output_header out;
> +} tpm_cmd_header;
> +
> +#define TPM_DIGEST_SIZE 20
> +struct tpm_pcrread_out {
> +        uint8_t      pcr_result[TPM_DIGEST_SIZE];
> +}__attribute__((packed));
> +
> +struct tpm_pcrread_in {
> +        uint32_t  pcr_idx;
> +}__attribute__((packed));
> +
> +struct tpm_pcrextend_in {
> +        uint32_t  pcr_idx;
> +        uint8_t      hash[TPM_DIGEST_SIZE];
> +}__attribute__((packed));
> +
> +typedef union {
> +        struct  tpm_getcap_params_out getcap_out;
> +        struct  tpm_readpubek_params_out readpubek_out;
> +        uint8_t      readpubek_out_buffer[sizeof(struct
> tpm_readpubek_params_out)];
> +        struct  tpm_getcap_params_in getcap_in;
> +        struct  tpm_pcrread_in  pcrread_in;
> +        struct  tpm_pcrread_out pcrread_out;
> +        struct  tpm_pcrextend_in pcrextend_in;
> +} tpm_cmd_params;
> +
> +struct tpm_cmd_t {
> +        tpm_cmd_header  header;
> +        tpm_cmd_params  params;
> +}__attribute__((packed));
> +
> +
> +enum tpm_duration {
> +   TPM_SHORT = 0,
> +   TPM_MEDIUM = 1,
> +   TPM_LONG = 2,
> +   TPM_UNDEFINED,
> +};
> +
> +#define TPM_MAX_ORDINAL 243
> +#define TPM_MAX_PROTECTED_ORDINAL 12
> +#define TPM_PROTECTED_ORDINAL_MASK 0xFF
> +
> +extern const uint8_t
> tpm_protected_ordinal_duration[TPM_MAX_PROTECTED_ORDINAL];
> +extern const uint8_t tpm_ordinal_duration[TPM_MAX_ORDINAL];
> +
> +#define TPM_DIGEST_SIZE 20
> +#define TPM_ERROR_SIZE 10
> +#define TPM_RET_CODE_IDX 6
> +
> +/* tpm_capabilities */
> +#define TPM_CAP_FLAG cpu_to_be32(4)
> +#define TPM_CAP_PROP cpu_to_be32(5)
> +#define CAP_VERSION_1_1 cpu_to_be32(0x06)
> +#define CAP_VERSION_1_2 cpu_to_be32(0x1A)
> +
> +/* tpm_sub_capabilities */
> +#define TPM_CAP_PROP_PCR cpu_to_be32(0x101)
> +#define TPM_CAP_PROP_MANUFACTURER cpu_to_be32(0x103)
> +#define TPM_CAP_FLAG_PERM cpu_to_be32(0x108)
> +#define TPM_CAP_FLAG_VOL cpu_to_be32(0x109)
> +#define TPM_CAP_PROP_OWNER cpu_to_be32(0x111)
> +#define TPM_CAP_PROP_TIS_TIMEOUT cpu_to_be32(0x115)
> +#define TPM_CAP_PROP_TIS_DURATION cpu_to_be32(0x120)
> +
> +
> +#define TPM_INTERNAL_RESULT_SIZE 200
> +#define TPM_TAG_RQU_COMMAND cpu_to_be16(193)
> +#define TPM_ORD_GET_CAP cpu_to_be32(101)
> +
> +extern const struct tpm_input_header tpm_getcap_header;
> +
> +
> +
> +const uint8_t tpm_protected_ordinal_duration[TPM_MAX_PROTECTED_ORDINAL] = {
> +   TPM_UNDEFINED,          /* 0 */
> +   TPM_UNDEFINED,
> +   TPM_UNDEFINED,
> +   TPM_UNDEFINED,
> +   TPM_UNDEFINED,
> +   TPM_UNDEFINED,          /* 5 */
> +   TPM_UNDEFINED,
> +   TPM_UNDEFINED,
> +   TPM_UNDEFINED,
> +   TPM_UNDEFINED,
> +   TPM_SHORT,              /* 10 */
> +   TPM_SHORT,
> +};
> +
> +const uint8_t tpm_ordinal_duration[TPM_MAX_ORDINAL] = {
> +   TPM_UNDEFINED,          /* 0 */
> +   TPM_UNDEFINED,
> +   TPM_UNDEFINED,
> +   TPM_UNDEFINED,
> +   TPM_UNDEFINED,
> +   TPM_UNDEFINED,          /* 5 */
> +   TPM_UNDEFINED,
> +   TPM_UNDEFINED,
> +   TPM_UNDEFINED,
> +   TPM_UNDEFINED,
> +   TPM_SHORT,              /* 10 */
> +   TPM_SHORT,
> +   TPM_MEDIUM,
> +   TPM_LONG,
> +   TPM_LONG,
> +   TPM_MEDIUM,             /* 15 */
> +   TPM_SHORT,
> +   TPM_SHORT,
> +   TPM_MEDIUM,
> +   TPM_LONG,
> +   TPM_SHORT,              /* 20 */
> +   TPM_SHORT,
> +   TPM_MEDIUM,
> +   TPM_MEDIUM,
> +   TPM_MEDIUM,
> +   TPM_SHORT,              /* 25 */
> +   TPM_SHORT,
> +   TPM_MEDIUM,
> +   TPM_SHORT,
> +   TPM_SHORT,
> +   TPM_MEDIUM,             /* 30 */
> +   TPM_LONG,
> +   TPM_MEDIUM,
> +   TPM_SHORT,
> +   TPM_SHORT,
> +   TPM_SHORT,              /* 35 */
> +   TPM_MEDIUM,
> +   TPM_MEDIUM,
> +   TPM_UNDEFINED,
> +   TPM_UNDEFINED,
> +   TPM_MEDIUM,             /* 40 */
> +   TPM_LONG,
> +   TPM_MEDIUM,
> +   TPM_SHORT,
> +   TPM_SHORT,
> +   TPM_SHORT,              /* 45 */
> +   TPM_SHORT,
> +   TPM_SHORT,
> +   TPM_SHORT,
> +   TPM_LONG,
> +   TPM_MEDIUM,             /* 50 */
> +   TPM_MEDIUM,
> +   TPM_UNDEFINED,
> +   TPM_UNDEFINED,
> +   TPM_UNDEFINED,
> +   TPM_UNDEFINED,          /* 55 */
> +   TPM_UNDEFINED,
> +   TPM_UNDEFINED,
> +   TPM_UNDEFINED,
> +   TPM_UNDEFINED,
> +   TPM_MEDIUM,             /* 60 */
> +   TPM_MEDIUM,
> +   TPM_MEDIUM,
> +   TPM_SHORT,
> +   TPM_SHORT,
> +   TPM_MEDIUM,             /* 65 */
> +   TPM_UNDEFINED,
> +   TPM_UNDEFINED,
> +   TPM_UNDEFINED,
> +   TPM_UNDEFINED,
> +   TPM_SHORT,              /* 70 */
> +   TPM_SHORT,
> +   TPM_UNDEFINED,
> +   TPM_UNDEFINED,
> +   TPM_UNDEFINED,
> +   TPM_UNDEFINED,          /* 75 */
> +   TPM_UNDEFINED,
> +   TPM_UNDEFINED,
> +   TPM_UNDEFINED,
> +   TPM_UNDEFINED,
> +   TPM_LONG,               /* 80 */
> +   TPM_UNDEFINED,
> +   TPM_MEDIUM,
> +   TPM_LONG,
> +   TPM_SHORT,
> +   TPM_UNDEFINED,          /* 85 */
> +   TPM_UNDEFINED,
> +   TPM_UNDEFINED,
> +   TPM_UNDEFINED,
> +   TPM_UNDEFINED,
> +   TPM_SHORT,              /* 90 */
> +   TPM_SHORT,
> +   TPM_SHORT,
> +   TPM_SHORT,
> +   TPM_SHORT,
> +   TPM_UNDEFINED,          /* 95 */
> +   TPM_UNDEFINED,
> +   TPM_UNDEFINED,
> +   TPM_UNDEFINED,
> +   TPM_UNDEFINED,
> +   TPM_MEDIUM,             /* 100 */
> +   TPM_SHORT,
> +   TPM_SHORT,
> +   TPM_UNDEFINED,
> +   TPM_UNDEFINED,
> +   TPM_UNDEFINED,          /* 105 */
> +   TPM_UNDEFINED,
> +   TPM_UNDEFINED,
> +   TPM_UNDEFINED,
> +   TPM_UNDEFINED,
> +   TPM_SHORT,              /* 110 */
> +   TPM_SHORT,
> +   TPM_SHORT,
> +   TPM_SHORT,
> +   TPM_SHORT,
> +   TPM_SHORT,              /* 115 */
> +   TPM_SHORT,
> +   TPM_SHORT,
> +   TPM_UNDEFINED,
> +   TPM_UNDEFINED,
> +   TPM_LONG,               /* 120 */
> +   TPM_LONG,
> +   TPM_MEDIUM,
> +   TPM_UNDEFINED,
> +   TPM_SHORT,
> +   TPM_SHORT,              /* 125 */
> +   TPM_SHORT,
> +   TPM_LONG,
> +   TPM_SHORT,
> +   TPM_SHORT,
> +   TPM_SHORT,              /* 130 */
> +   TPM_MEDIUM,
> +   TPM_UNDEFINED,
> +   TPM_SHORT,
> +   TPM_MEDIUM,
> +   TPM_UNDEFINED,          /* 135 */
> +   TPM_UNDEFINED,
> +   TPM_UNDEFINED,
> +   TPM_UNDEFINED,
> +   TPM_UNDEFINED,
> +   TPM_SHORT,              /* 140 */
> +   TPM_SHORT,
> +   TPM_UNDEFINED,
> +   TPM_UNDEFINED,
> +   TPM_UNDEFINED,
> +   TPM_UNDEFINED,          /* 145 */
> +   TPM_UNDEFINED,
> +   TPM_UNDEFINED,
> +   TPM_UNDEFINED,
> +   TPM_UNDEFINED,
> +   TPM_SHORT,              /* 150 */
> +   TPM_MEDIUM,
> +   TPM_MEDIUM,
> +   TPM_SHORT,
> +   TPM_SHORT,
> +   TPM_UNDEFINED,          /* 155 */
> +   TPM_UNDEFINED,
> +   TPM_UNDEFINED,
> +   TPM_UNDEFINED,
> +   TPM_UNDEFINED,
> +   TPM_SHORT,              /* 160 */
> +   TPM_SHORT,
> +   TPM_SHORT,
> +   TPM_SHORT,
> +   TPM_UNDEFINED,
> +   TPM_UNDEFINED,          /* 165 */
> +   TPM_UNDEFINED,
> +   TPM_UNDEFINED,
> +   TPM_UNDEFINED,
> +   TPM_UNDEFINED,
> +   TPM_LONG,               /* 170 */
> +   TPM_UNDEFINED,
> +   TPM_UNDEFINED,
> +   TPM_UNDEFINED,
> +   TPM_UNDEFINED,
> +   TPM_UNDEFINED,          /* 175 */
> +   TPM_UNDEFINED,
> +   TPM_UNDEFINED,
> +   TPM_UNDEFINED,
> +   TPM_UNDEFINED,
> +   TPM_MEDIUM,             /* 180 */
> +   TPM_SHORT,
> +   TPM_MEDIUM,
> +   TPM_MEDIUM,
> +   TPM_MEDIUM,
> +   TPM_MEDIUM,             /* 185 */
> +   TPM_SHORT,
> +   TPM_UNDEFINED,
> +   TPM_UNDEFINED,
> +   TPM_UNDEFINED,
> +   TPM_UNDEFINED,          /* 190 */
> +   TPM_UNDEFINED,
> +   TPM_UNDEFINED,
> +   TPM_UNDEFINED,
> +   TPM_UNDEFINED,
> +   TPM_UNDEFINED,          /* 195 */
> +   TPM_UNDEFINED,
> +   TPM_UNDEFINED,
> +   TPM_UNDEFINED,
> +   TPM_UNDEFINED,
> +   TPM_SHORT,              /* 200 */
> +   TPM_UNDEFINED,
> +   TPM_UNDEFINED,
> +   TPM_UNDEFINED,
> +   TPM_SHORT,
> +   TPM_SHORT,              /* 205 */
> +   TPM_SHORT,
> +   TPM_SHORT,
> +   TPM_SHORT,
> +   TPM_SHORT,
> +   TPM_MEDIUM,             /* 210 */
> +   TPM_UNDEFINED,
> +   TPM_MEDIUM,
> +   TPM_MEDIUM,
> +   TPM_MEDIUM,
> +   TPM_UNDEFINED,          /* 215 */
> +   TPM_MEDIUM,
> +   TPM_UNDEFINED,
> +   TPM_UNDEFINED,
> +   TPM_SHORT,
> +   TPM_SHORT,              /* 220 */
> +   TPM_SHORT,
> +   TPM_SHORT,
> +   TPM_SHORT,
> +   TPM_SHORT,
> +   TPM_UNDEFINED,          /* 225 */
> +   TPM_UNDEFINED,
> +   TPM_UNDEFINED,
> +   TPM_UNDEFINED,
> +   TPM_UNDEFINED,
> +   TPM_SHORT,              /* 230 */
> +   TPM_LONG,
> +   TPM_MEDIUM,
> +   TPM_UNDEFINED,
> +   TPM_UNDEFINED,
> +   TPM_UNDEFINED,          /* 235 */
> +   TPM_UNDEFINED,
> +   TPM_UNDEFINED,
> +   TPM_UNDEFINED,
> +   TPM_UNDEFINED,
> +   TPM_SHORT,              /* 240 */
> +   TPM_UNDEFINED,
> +   TPM_MEDIUM,
> +};
> +
> +const struct tpm_input_header tpm_getcap_header = {
> +        .tag = TPM_TAG_RQU_COMMAND,
> +        .length = cpu_to_be32(22),
> +        .ordinal = TPM_ORD_GET_CAP
> +};
> +
> +
> +enum tis_access {
> +   TPM_ACCESS_VALID = 0x80,
> +   TPM_ACCESS_ACTIVE_LOCALITY = 0x20,    /* (R) */
> +   TPM_ACCESS_RELINQUISH_LOCALITY = 0x20,/* (W) */
> +   TPM_ACCESS_REQUEST_PENDING = 0x04,    /* (W) */
> +   TPM_ACCESS_REQUEST_USE = 0x02,    /* (W) */
> +};
> +
> +enum tis_status {
> +   TPM_STS_VALID = 0x80,        /* (R) */
> +   TPM_STS_COMMAND_READY = 0x40,    /* (R) */
> +   TPM_STS_DATA_AVAIL = 0x10,        /* (R) */
> +   TPM_STS_DATA_EXPECT = 0x08,        /* (R) */
> +   TPM_STS_GO = 0x20,            /* (W) */
> +};
> +
> +enum tis_int_flags {
> +   TPM_GLOBAL_INT_ENABLE = 0x80000000,
> +   TPM_INTF_BURST_COUNT_STATIC = 0x100,
> +   TPM_INTF_CMD_READY_INT = 0x080,
> +   TPM_INTF_INT_EDGE_FALLING = 0x040,
> +   TPM_INTF_INT_EDGE_RISING = 0x020,
> +   TPM_INTF_INT_LEVEL_LOW = 0x010,
> +   TPM_INTF_INT_LEVEL_HIGH = 0x008,
> +   TPM_INTF_LOCALITY_CHANGE_INT = 0x004,
> +   TPM_INTF_STS_VALID_INT = 0x002,
> +   TPM_INTF_DATA_AVAIL_INT = 0x001,
> +};
> +
> +enum tis_defaults {
> +   TIS_MEM_BASE = 0xFED40000,
> +   TIS_MEM_LEN  = 0x5000,
> +   TIS_SHORT_TIMEOUT = 750, /*ms*/
> +   TIS_LONG_TIMEOUT = 2000, /*2 sec */
> +};
> +
> +#define TPM_TIMEOUT 5
> +
> +#define TPM_ACCESS(t, l)                   (((uint8_t*)t->pages[l]) +
> 0x0000)
> +#define TPM_INT_ENABLE(t, l)
> ((uint32_t*)(((uint8_t*)t->pages[l]) + 0x0008))
> +#define TPM_INT_VECTOR(t, l)               (((uint8_t*)t->pages[l]) +
> 0x000C)
> +#define TPM_INT_STATUS(t, l)               (((uint8_t*)t->pages[l]) +
> 0x0010)
> +#define TPM_INTF_CAPS(t, l)
> ((uint32_t*)(((uint8_t*)t->pages[l]) + 0x0014))
> +#define TPM_STS(t, l)
> ((uint8_t*)(((uint8_t*)t->pages[l]) + 0x0018))
> +#define TPM_DATA_FIFO(t, l)                (((uint8_t*)t->pages[l]) +
> 0x0024)
> +
> +#define TPM_DID_VID(t, l)
> ((uint32_t*)(((uint8_t*)t->pages[l]) + 0x0F00))
> +#define TPM_RID(t, l)                      (((uint8_t*)t->pages[l]) +
> 0x0F04)
> +
> +struct tpm_chip {
> +   int enabled_localities;
> +   int locality;
> +   unsigned long baseaddr;
> +   uint8_t* pages[5];
> +   int did, vid, rid;
> +
> +   uint8_t data_buffer[TPM_BUFSIZE];
> +   int data_len;
> +
> +   s_time_t timeout_a, timeout_b, timeout_c, timeout_d;
> +   s_time_t duration[3];
> +
> +#ifdef HAVE_LIBC
> +   int fd;
> +#endif
> +
> +   unsigned int irq;
> +   struct wait_queue_head read_queue;
> +   struct wait_queue_head int_queue;
> +};
> +
> +
> +static void __init_tpm_chip(struct tpm_chip* tpm) {
> +   tpm->enabled_localities = TPM_TIS_EN_LOCLALL;
> +   tpm->locality = -1;
> +   tpm->baseaddr = 0;
> +   tpm->pages[0] = tpm->pages[1] = tpm->pages[2] = tpm->pages[3] =
> tpm->pages[4] = NULL;
> +   tpm->vid = 0;
> +   tpm->did = 0;
> +   tpm->irq = 0;
> +   init_waitqueue_head(&tpm->read_queue);
> +   init_waitqueue_head(&tpm->int_queue);
> +
> +   tpm->data_len = -1;
> +
> +#ifdef HAVE_LIBC
> +   tpm->fd = -1;
> +#endif
> +}
> +
> +/*
> + * Returns max number of nsecs to wait
> + */
> +s_time_t tpm_calc_ordinal_duration(struct tpm_chip *chip,
> +      uint32_t ordinal)
> +{
> +   int duration_idx = TPM_UNDEFINED;
> +   s_time_t duration = 0;
> +
> +   if (ordinal < TPM_MAX_ORDINAL)
> +      duration_idx = tpm_ordinal_duration[ordinal];
> +   else if ((ordinal & TPM_PROTECTED_ORDINAL_MASK) <
> +     TPM_MAX_PROTECTED_ORDINAL)
> +      duration_idx =
> +     tpm_protected_ordinal_duration[ordinal &
> +     TPM_PROTECTED_ORDINAL_MASK];
> +
> +   if (duration_idx != TPM_UNDEFINED) {
> +      duration = chip->duration[duration_idx];
> +   }
> +
> +   if (duration <= 0) {
> +      return SECONDS(120);
> +   }
> +   else
> +   {
> +      return duration;
> +   }
> +}
> +
> +
> +static int locality_enabled(struct tpm_chip* tpm, int l) {
> +   return tpm->enabled_localities & (1 << l);
> +}
> +
> +static int check_locality(struct tpm_chip* tpm, int l) {
> +   if(locality_enabled(tpm, l) && (ioread8(TPM_ACCESS(tpm, l)) &
> +        (TPM_ACCESS_ACTIVE_LOCALITY | TPM_ACCESS_VALID)) ==
> +     (TPM_ACCESS_ACTIVE_LOCALITY | TPM_ACCESS_VALID)) {
> +      return l;
> +   }
> +   return -1;
> +}
> +
> +void release_locality(struct tpm_chip* tpm, int l, int force)
> +{
> +   if (locality_enabled(tpm, l) && (force || (ioread8(TPM_ACCESS(tpm, l)) &
> +           (TPM_ACCESS_REQUEST_PENDING | TPM_ACCESS_VALID)) ==
> +        (TPM_ACCESS_REQUEST_PENDING | TPM_ACCESS_VALID))) {
> +      iowrite8(TPM_ACCESS(tpm, l), TPM_ACCESS_RELINQUISH_LOCALITY);
> +   }
> +}
> +
> +int tpm_tis_request_locality(struct tpm_chip* tpm, int l) {
> +
> +   s_time_t stop;
> +   /*Make sure locality is valid */
> +   if(!locality_enabled(tpm, l)) {
> +      printk("tpm_tis_change_locality() Tried to change to locality %d,
> but it is disabled or invalid!\n", l);
> +      return -1;
> +   }
> +   /* Check if we already have the current locality */
> +   if(check_locality(tpm, l) >= 0) {
> +      return tpm->locality = l;
> +   }
> +   /* Set the new locality*/
> +   iowrite8(TPM_ACCESS(tpm, l), TPM_ACCESS_REQUEST_USE);
> +
> +   if(tpm->irq) {
> +      /* Wait for interrupt */
> +      wait_event_deadline(tpm->int_queue, (check_locality(tpm, l) >=
> 0), NOW() + tpm->timeout_a);
> +
> +      /* FIXME: Handle timeout event, should return error in that case */
> +      return l;
> +   } else {
> +      /* Wait for burstcount */
> +      stop = NOW() + tpm->timeout_a;
> +      do {
> +     if(check_locality(tpm, l) >= 0) {
> +        return tpm->locality = l;
> +     }
> +     msleep(TPM_TIMEOUT);
> +      } while(NOW() < stop);
> +   }
> +
> +   printk("REQ LOCALITY FAILURE\n");
> +   return -1;
> +}
> +
> +static uint8_t tpm_tis_status(struct tpm_chip* tpm) {
> +   return ioread8(TPM_STS(tpm, tpm->locality));
> +}
> +
> +/* This causes the current command to be aborted */
> +static void tpm_tis_ready(struct tpm_chip* tpm) {
> +   iowrite8(TPM_STS(tpm, tpm->locality), TPM_STS_COMMAND_READY);
> +}
> +#define tpm_tis_cancel_cmd(v) tpm_tis_ready(v)
> +
> +static int get_burstcount(struct tpm_chip* tpm) {
> +   s_time_t stop;
> +   int burstcnt;
> +
> +   stop = NOW() + tpm->timeout_d;
> +   do {
> +      burstcnt = ioread8((TPM_STS(tpm, tpm->locality) + 1));
> +      burstcnt += ioread8(TPM_STS(tpm, tpm->locality) + 2) << 8;
> +
> +      if (burstcnt) {
> +     return burstcnt;
> +      }
> +      msleep(TPM_TIMEOUT);
> +   } while(NOW() < stop);
> +   return -EBUSY;
> +}
> +
> +static int wait_for_stat(struct tpm_chip* tpm, uint8_t mask,
> +      unsigned long timeout, struct wait_queue_head* queue) {
> +   s_time_t stop;
> +   uint8_t status;
> +
> +   status = tpm_tis_status(tpm);
> +   if((status & mask) == mask) {
> +      return 0;
> +   }
> +
> +   if(tpm->irq) {
> +      wait_event_deadline(*queue, ((tpm_tis_status(tpm) & mask) ==
> mask), timeout);
> +      /* FIXME: Check for timeout and return -ETIME */
> +      return 0;
> +   } else {
> +      stop = NOW() + timeout;
> +      do {
> +     msleep(TPM_TIMEOUT);
> +     status = tpm_tis_status(tpm);
> +     if((status & mask) == mask)
> +        return 0;
> +      } while( NOW() < stop);
> +   }
> +   return -ETIME;
> +}
> +
> +static int recv_data(struct tpm_chip* tpm, uint8_t* buf, size_t count) {
> +   int size = 0;
> +   int burstcnt;
> +   while( size < count &&
> +     wait_for_stat(tpm,
> +        TPM_STS_DATA_AVAIL | TPM_STS_VALID,
> +        tpm->timeout_c,
> +        &tpm->read_queue)
> +     == 0) {
> +      burstcnt = get_burstcount(tpm);
> +      for(; burstcnt > 0 && size < count; --burstcnt)
> +      {
> +     buf[size++] = ioread8(TPM_DATA_FIFO(tpm, tpm->locality));
> +      }
> +   }
> +   return size;
> +}
> +
> +int tpm_tis_recv(struct tpm_chip* tpm, uint8_t* buf, size_t count) {
> +   int size = 0;
> +   int expected, status;
> +
> +   if (count < TPM_HEADER_SIZE) {
> +      size = -EIO;
> +      goto out;
> +   }
> +
> +   /* read first 10 bytes, including tag, paramsize, and result */
> +   if((size =
> +        recv_data(tpm, buf, TPM_HEADER_SIZE)) < TPM_HEADER_SIZE) {
> +      printk("Error reading tpm cmd header\n");
> +      goto out;
> +   }
> +
> +   expected = be32_to_cpu(*((uint32_t*)(buf + 2)));
> +   if(expected > count) {
> +      size = -EIO;
> +      goto out;
> +   }
> +
> +   if((size += recv_data(tpm, & buf[TPM_HEADER_SIZE],
> +           expected - TPM_HEADER_SIZE)) < expected) {
> +      printk("Unable to read rest of tpm command size=%d
> expected=%d\n", size, expected);
> +      size = -ETIME;
> +      goto out;
> +   }
> +
> +   wait_for_stat(tpm, TPM_STS_VALID, tpm->timeout_c, &tpm->int_queue);
> +   status = tpm_tis_status(tpm);
> +   if(status & TPM_STS_DATA_AVAIL) {
> +      printk("Error: left over data\n");
> +      size = -EIO;
> +      goto out;
> +   }
> +
> +out:
> +   tpm_tis_ready(tpm);
> +   release_locality(tpm, tpm->locality, 0);
> +   return size;
> +}
> +int tpm_tis_send(struct tpm_chip* tpm, uint8_t* buf, size_t len) {
> +   int rc;
> +   int status, burstcnt = 0;
> +   int count = 0;
> +   uint32_t ordinal;
> +
> +   if(tpm_tis_request_locality(tpm, tpm->locality) < 0) {
> +      return -EBUSY;
> +   }
> +
> +   status = tpm_tis_status(tpm);
> +   if((status & TPM_STS_COMMAND_READY) == 0) {
> +      tpm_tis_ready(tpm);
> +      if(wait_for_stat(tpm, TPM_STS_COMMAND_READY, tpm->timeout_b,
> &tpm->int_queue) < 0) {
> +     rc = -ETIME;
> +     goto out_err;
> +      }
> +   }
> +
> +   while(count < len - 1) {
> +      burstcnt = get_burstcount(tpm);
> +      for(;burstcnt > 0 && count < len -1; --burstcnt) {
> +     iowrite8(TPM_DATA_FIFO(tpm, tpm->locality), buf[count++]);
> +      }
> +
> +      wait_for_stat(tpm, TPM_STS_VALID, tpm->timeout_c, &tpm->int_queue);
> +      status = tpm_tis_status(tpm);
> +      if((status & TPM_STS_DATA_EXPECT) == 0) {
> +     rc = -EIO;
> +     goto out_err;
> +      }
> +   }
> +
> +   /*Write last byte*/
> +   iowrite8(TPM_DATA_FIFO(tpm, tpm->locality), buf[count]);
> +   wait_for_stat(tpm, TPM_STS_VALID, tpm->timeout_c, &tpm->read_queue);
> +   status = tpm_tis_status(tpm);
> +   if((status & TPM_STS_DATA_EXPECT) != 0) {
> +      rc = -EIO;
> +      goto out_err;
> +   }
> +
> +   /*go and do it*/
> +   iowrite8(TPM_STS(tpm, tpm->locality), TPM_STS_GO);
> +
> +   if(tpm->irq) {
> +      /*Wait for interrupt */
> +      ordinal = be32_to_cpu(*(buf + 6));
> +      if(wait_for_stat(tpm,
> +           TPM_STS_DATA_AVAIL | TPM_STS_VALID,
> +           tpm_calc_ordinal_duration(tpm, ordinal),
> +           &tpm->read_queue) < 0) {
> +     rc = -ETIME;
> +     goto out_err;
> +      }
> +   }
> +#ifdef HAVE_LIBC
> +   if(tpm->fd >= 0) {
> +      files[tpm->fd].read = 0;
> +      files[tpm->fd].tpm_tis.respgot = 0;
> +      files[tpm->fd].tpm_tis.offset = 0;
> +   }
> +#endif
> +   return len;
> +
> +out_err:
> +   tpm_tis_ready(tpm);
> +   release_locality(tpm, tpm->locality, 0);
> +   return rc;
> +}
> +
> +static void tpm_tis_irq_handler(evtchn_port_t port, struct pt_regs
> *regs, void* data)
> +{
> +   struct tpm_chip* tpm = data;
> +   uint32_t interrupt;
> +   int i;
> +
> +   interrupt = ioread32(TPM_INT_STATUS(tpm, tpm->locality));
> +   if(interrupt == 0) {
> +      return;
> +   }
> +
> +   if(interrupt & TPM_INTF_DATA_AVAIL_INT) {
> +      wake_up(&tpm->read_queue);
> +   }
> +   if(interrupt & TPM_INTF_LOCALITY_CHANGE_INT) {
> +      for(i = 0; i < 5; ++i) {
> +     if(check_locality(tpm, i) >= 0) {
> +        break;
> +     }
> +      }
> +   }
> +   if(interrupt & (TPM_INTF_LOCALITY_CHANGE_INT | TPM_INTF_STS_VALID_INT |
> +        TPM_INTF_CMD_READY_INT)) {
> +      wake_up(&tpm->int_queue);
> +   }
> +
> +   /* Clear interrupts handled with TPM_EOI */
> +   iowrite32(TPM_INT_STATUS(tpm, tpm->locality), interrupt);
> +   ioread32(TPM_INT_STATUS(tpm, tpm->locality));
> +   return;
> +}
> +
> +/*
> + * Internal kernel interface to transmit TPM commands
> + */
> +static ssize_t tpm_transmit(struct tpm_chip *chip, const uint8_t *buf,
> +      size_t bufsiz)
> +{
> +   ssize_t rc;
> +   uint32_t count, ordinal;
> +   s_time_t stop;
> +
> +   count = be32_to_cpu(*((uint32_t *) (buf + 2)));
> +   ordinal = be32_to_cpu(*((uint32_t *) (buf + 6)));
> +   if (count == 0)
> +      return -ENODATA;
> +   if (count > bufsiz) {
> +      printk("Error: invalid count value %x %zx \n", count, bufsiz);
> +      return -E2BIG;
> +   }
> +
> +   //down(&chip->tpm_mutex);
> +
> +   if ((rc = tpm_tis_send(chip, (uint8_t *) buf, count)) < 0) {
> +      printk("tpm_transmit: tpm_send: error %zd\n", rc);
> +      goto out;
> +   }
> +
> +   if (chip->irq)
> +      goto out_recv;
> +
> +   stop = NOW() + tpm_calc_ordinal_duration(chip, ordinal);
> +   do {
> +      uint8_t status = tpm_tis_status(chip);
> +      if ((status & (TPM_STS_DATA_AVAIL | TPM_STS_VALID)) ==
> +        (TPM_STS_DATA_AVAIL | TPM_STS_VALID))
> +     goto out_recv;
> +
> +      if ((status == TPM_STS_COMMAND_READY)) {
> +     printk("TPM Error: Operation Canceled\n");
> +     rc = -ECANCELED;
> +     goto out;
> +      }
> +
> +      msleep(TPM_TIMEOUT);    /* CHECK */
> +      rmb();
> +   } while (NOW() < stop);
> +
> +   /* Cancel the command */
> +   tpm_tis_cancel_cmd(chip);
> +   printk("TPM Operation Timed out\n");
> +   rc = -ETIME;
> +   goto out;
> +
> +out_recv:
> +   if((rc = tpm_tis_recv(chip, (uint8_t *) buf, bufsiz)) < 0) {
> +      printk("tpm_transmit: tpm_recv: error %d\n", rc);
> +   }
> +out:
> +   //up(&chip->tpm_mutex);
> +   return rc;
> +}
> +
> +static ssize_t transmit_cmd(struct tpm_chip *chip, struct tpm_cmd_t *cmd,
> +                            int len, const char *desc)
> +{
> +        int err;
> +
> +        len = tpm_transmit(chip,(uint8_t *) cmd, len);
> +        if (len <  0)
> +                return len;
> +        if (len == TPM_ERROR_SIZE) {
> +                err = be32_to_cpu(cmd->header.out.return_code);
> +                printk("A TPM error (%d) occurred %s\n", err, desc);
> +                return err;
> +        }
> +        return 0;
> +}
> +
> +void tpm_get_timeouts(struct tpm_chip *chip)
> +{
> +   struct tpm_cmd_t tpm_cmd;
> +   struct timeout_t *timeout_cap;
> +   struct duration_t *duration_cap;
> +   ssize_t rc;
> +   uint32_t timeout;
> +
> +   tpm_cmd.header.in = tpm_getcap_header;
> +   tpm_cmd.params.getcap_in.cap = TPM_CAP_PROP;
> +   tpm_cmd.params.getcap_in.subcap_size = cpu_to_be32(4);
> +   tpm_cmd.params.getcap_in.subcap = TPM_CAP_PROP_TIS_TIMEOUT;
> +
> +   if((rc = transmit_cmd(chip, &tpm_cmd, TPM_INTERNAL_RESULT_SIZE,
> +     "attempting to determine the timeouts")) != 0) {
> +      printk("transmit failed %d\n", rc);
> +      goto duration;
> +   }
> +
> +   if (be32_to_cpu(tpm_cmd.params.getcap_out.cap_size)
> +     != 4 * sizeof(uint32_t)) {
> +      printk("Out len check failure %lu \n",
> be32_to_cpu(tpm_cmd.header.out.length));
> +      goto duration;
> +   }
> +
> +   timeout_cap = &tpm_cmd.params.getcap_out.cap.timeout;
> +   /* Don't overwrite default if value is 0 */
> +   timeout = be32_to_cpu(timeout_cap->a);
> +   if (timeout)
> +      chip->timeout_a = MICROSECS(timeout); /*Convert to msec */
> +   timeout = be32_to_cpu(timeout_cap->b);
> +   if (timeout)
> +      chip->timeout_b = MICROSECS(timeout); /*Convert to msec */
> +   timeout = be32_to_cpu(timeout_cap->c);
> +   if (timeout)
> +      chip->timeout_c = MICROSECS(timeout); /*Convert to msec */
> +   timeout = be32_to_cpu(timeout_cap->d);
> +   if (timeout)
> +      chip->timeout_d = MICROSECS(timeout); /*Convert to msec */
> +
> +duration:
> +   tpm_cmd.header.in = tpm_getcap_header;
> +   tpm_cmd.params.getcap_in.cap = TPM_CAP_PROP;
> +   tpm_cmd.params.getcap_in.subcap_size = cpu_to_be32(4);
> +   tpm_cmd.params.getcap_in.subcap = TPM_CAP_PROP_TIS_DURATION;
> +
> +   if((rc = transmit_cmd(chip, &tpm_cmd, TPM_INTERNAL_RESULT_SIZE,
> +     "attempting to determine the durations")) < 0) {
> +      return;
> +   }
> +
> +   if (be32_to_cpu(tpm_cmd.params.getcap_out.cap_size)
> +     != 3 * sizeof(uint32_t)) {
> +      return;
> +   }
> +        duration_cap = &tpm_cmd.params.getcap_out.cap.duration;
> +        chip->duration[TPM_SHORT] = be32_to_cpu(duration_cap->tpm_short);
> +        /* The Broadcom BCM0102 chipset in a Dell Latitude D820 gets
> the above
> +         * value wrong and apparently reports msecs rather than usecs.
> So we
> +         * fix up the resulting too-small TPM_SHORT value to make
> things work.
> +         */
> +        if (chip->duration[TPM_SHORT] < 10) {
> +       chip->duration[TPM_SHORT] = MILLISECS(chip->duration[TPM_SHORT]);
> +    } else {
> +       chip->duration[TPM_SHORT] = MICROSECS(chip->duration[TPM_SHORT]);
> +    }
> +
> +        chip->duration[TPM_MEDIUM] =
> MICROSECS(be32_to_cpu(duration_cap->tpm_medium));
> +        chip->duration[TPM_LONG] =
> MICROSECS(be32_to_cpu(duration_cap->tpm_long));
> +}
> +
> +
> +
> +void tpm_continue_selftest(struct tpm_chip* chip) {
> +   uint8_t data[] = {
> +      0, 193,                 /* TPM_TAG_RQU_COMMAND */
> +      0, 0, 0, 10,            /* length */
> +      0, 0, 0, 83,            /* TPM_ORD_GetCapability */
> +   };
> +
> +   tpm_transmit(chip, data, sizeof(data));
> +}
> +
> +ssize_t tpm_getcap(struct tpm_chip *chip, uint32_t subcap_id, cap_t *cap,
> +                   const char *desc)
> +{
> +        struct tpm_cmd_t tpm_cmd;
> +        int rc;
> +
> +        tpm_cmd.header.in = tpm_getcap_header;
> +        if (subcap_id == CAP_VERSION_1_1 || subcap_id == CAP_VERSION_1_2) {
> +                tpm_cmd.params.getcap_in.cap = subcap_id;
> +                /*subcap field not necessary */
> +                tpm_cmd.params.getcap_in.subcap_size = cpu_to_be32(0);
> +                tpm_cmd.header.in.length -= cpu_to_be32(sizeof(uint32_t));
> +        } else {
> +                if (subcap_id == TPM_CAP_FLAG_PERM ||
> +                    subcap_id == TPM_CAP_FLAG_VOL)
> +                        tpm_cmd.params.getcap_in.cap = TPM_CAP_FLAG;
> +                else
> +                        tpm_cmd.params.getcap_in.cap = TPM_CAP_PROP;
> +                tpm_cmd.params.getcap_in.subcap_size = cpu_to_be32(4);
> +                tpm_cmd.params.getcap_in.subcap = subcap_id;
> +        }
> +        rc = transmit_cmd(chip, &tpm_cmd, TPM_INTERNAL_RESULT_SIZE, desc);
> +        if (!rc)
> +                *cap = tpm_cmd.params.getcap_out.cap;
> +        return rc;
> +}
> +
> +
> +struct tpm_chip* init_tpm_tis(unsigned long baseaddr, int localities,
> unsigned int irq)
> +{
> +   int i;
> +   unsigned long addr;
> +   struct tpm_chip* tpm = NULL;
> +   uint32_t didvid;
> +   uint32_t intfcaps;
> +   uint32_t intmask;
> +
> +   printk("============= Init TPM TIS Driver ==============\n");
> +
> +   /*Sanity check the localities input */
> +   if(localities & ~TPM_TIS_EN_LOCLALL) {
> +      printk("init_tpm_tis() Invalid locality specification! %X\n",
> localities);
> +      goto abort_egress;
> +   }
> +
> +   printk("IOMEM Machine Base Address: %lX\n", baseaddr);
> +
> +   /* Create the tpm data structure */
> +   tpm = malloc(sizeof(struct tpm_chip));
> +   __init_tpm_chip(tpm);
> +
> +   /* Set the enabled localities - if 0 we leave default as all enabled */
> +   if(localities != 0) {
> +      tpm->enabled_localities = localities;
> +   }
> +   printk("Enabled Localities: ");
> +   for(i = 0; i < 5; ++i) {
> +      if(locality_enabled(tpm, i)) {
> +     printk("%d ", i);
> +      }
> +   }
> +   printk("\n");
> +
> +   /* Set the base machine address */
> +   tpm->baseaddr = baseaddr;
> +
> +   /* Set default timeouts */
> +   tpm->timeout_a = MILLISECS(TIS_SHORT_TIMEOUT);
> +   tpm->timeout_b = MILLISECS(TIS_LONG_TIMEOUT);
> +   tpm->timeout_c = MILLISECS(TIS_SHORT_TIMEOUT);
> +   tpm->timeout_d = MILLISECS(TIS_SHORT_TIMEOUT);
> +
> +   /*Map the mmio pages */
> +   addr = tpm->baseaddr;
> +   for(i = 0; i < 5; ++i) {
> +      if(locality_enabled(tpm, i)) {
> +     /* Map the page in now */
> +     if((tpm->pages[i] = ioremap_nocache(addr, PAGE_SIZE)) == NULL) {
> +        printk("Unable to map iomem page a address %p\n", addr);
> +        goto abort_egress;
> +     }
> +
> +     /* Set default locality to the first enabled one */
> +     if (tpm->locality < 0) {
> +        if(tpm_tis_request_locality(tpm, i) < 0) {
> +           printk("Unable to request locality %d??\n", i);
> +           goto abort_egress;
> +        }
> +     }
> +      }
> +      addr += PAGE_SIZE;
> +   }
> +
> +
> +   /* Get the vendor and device ids */
> +   didvid = ioread32(TPM_DID_VID(tpm, tpm->locality));
> +   tpm->did = didvid >> 16;
> +   tpm->vid = didvid & 0xFFFF;
> +
> +
> +   /* Get the revision id */
> +   tpm->rid = ioread8(TPM_RID(tpm, tpm->locality));
> +
> +   printk("1.2 TPM (device-id=0x%X vendor-id = %X rev-id = %X)\n",
> tpm->did, tpm->vid, tpm->rid);
> +
> +   intfcaps = ioread32(TPM_INTF_CAPS(tpm, tpm->locality));
> +   printk("TPM interface capabilities (0x%x):\n", intfcaps);
> +   if (intfcaps & TPM_INTF_BURST_COUNT_STATIC)
> +      printk("\tBurst Count Static\n");
> +   if (intfcaps & TPM_INTF_CMD_READY_INT)
> +      printk("\tCommand Ready Int Support\n");
> +   if (intfcaps & TPM_INTF_INT_EDGE_FALLING)
> +      printk("\tInterrupt Edge Falling\n");
> +   if (intfcaps & TPM_INTF_INT_EDGE_RISING)
> +      printk("\tInterrupt Edge Rising\n");
> +   if (intfcaps & TPM_INTF_INT_LEVEL_LOW)
> +      printk("\tInterrupt Level Low\n");
> +   if (intfcaps & TPM_INTF_INT_LEVEL_HIGH)
> +      printk("\tInterrupt Level High\n");
> +   if (intfcaps & TPM_INTF_LOCALITY_CHANGE_INT)
> +      printk("\tLocality Change Int Support\n");
> +   if (intfcaps & TPM_INTF_STS_VALID_INT)
> +      printk("\tSts Valid Int Support\n");
> +   if (intfcaps & TPM_INTF_DATA_AVAIL_INT)
> +      printk("\tData Avail Int Support\n");
> +
> +   /*Interupt setup */
> +   intmask = ioread32(TPM_INT_ENABLE(tpm, tpm->locality));
> +
> +   intmask |= TPM_INTF_CMD_READY_INT
> +      | TPM_INTF_LOCALITY_CHANGE_INT | TPM_INTF_DATA_AVAIL_INT
> +      | TPM_INTF_STS_VALID_INT;
> +
> +   iowrite32(TPM_INT_ENABLE(tpm, tpm->locality), intmask);
> +
> +   /*If interupts are enabled, handle it */
> +   if(irq) {
> +      if(irq != TPM_PROBE_IRQ) {
> +     tpm->irq = irq;
> +      } else {
> +     /*FIXME add irq probing feature later */
> +     printk("IRQ probing not implemented\n");
> +      }
> +   }
> +
> +   if(tpm->irq) {
> +      iowrite8(TPM_INT_VECTOR(tpm, tpm->locality), tpm->irq);
> +
> +      if(bind_pirq(tpm->irq, 1, tpm_tis_irq_handler, tpm) != 0) {
> +     printk("Unabled to request irq: %u for use\n", tpm->irq);
> +     printk("Will use polling mode\n");
> +     tpm->irq = 0;
> +      } else {
> +     /* Clear all existing */
> +     iowrite32(TPM_INT_STATUS(tpm, tpm->locality),
> ioread32(TPM_INT_STATUS(tpm, tpm->locality)));
> +
> +     /* Turn on interrupts */
> +     iowrite32(TPM_INT_ENABLE(tpm, tpm->locality), intmask |
> TPM_GLOBAL_INT_ENABLE);
> +      }
> +   }
> +
> +   tpm_get_timeouts(tpm);
> +   tpm_continue_selftest(tpm);
> +
> +
> +   return tpm;
> +abort_egress:
> +   if(tpm != NULL) {
> +      shutdown_tpm_tis(tpm);
> +   }
> +   return NULL;
> +}
> +
> +void shutdown_tpm_tis(struct tpm_chip* tpm){
> +   int i;
> +
> +   printk("Shutting down tpm_tis device\n");
> +
> +   iowrite32(TPM_INT_ENABLE(tpm, tpm->locality), ~TPM_GLOBAL_INT_ENABLE);
> +
> +   /*Unmap all of the mmio pages */
> +   for(i = 0; i < 5; ++i) {
> +      if(tpm->pages[i] != NULL) {
> +     iounmap(tpm->pages[i], PAGE_SIZE);
> +     tpm->pages[i] = NULL;
> +      }
> +   }
> +   free(tpm);
> +   return;
> +}
> +
> +
> +int tpm_tis_cmd(struct tpm_chip* tpm, uint8_t* req, size_t reqlen,
> uint8_t** resp, size_t* resplen)
> +{
> +   if(tpm->locality < 0) {
> +      printk("tpm_tis_cmd() failed! locality not set!\n");
> +      return -1;
> +   }
> +   if(reqlen > TPM_BUFSIZE) {
> +      reqlen = TPM_BUFSIZE;
> +   }
> +   memcpy(tpm->data_buffer, req, reqlen);
> +   *resplen = tpm_transmit(tpm, tpm->data_buffer, TPM_BUFSIZE);
> +
> +   *resp = malloc(*resplen);
> +   memcpy(*resp, tpm->data_buffer, *resplen);
> +   return 0;
> +}
> +
> +#ifdef HAVE_LIBC
> +int tpm_tis_open(struct tpm_chip* tpm)
> +{
> +   /* Silently prevent multiple opens */
> +   if(tpm->fd != -1) {
> +      return tpm->fd;
> +   }
> +
> +   tpm->fd = alloc_fd(FTYPE_TPM_TIS);
> +   printk("tpm_tis_open() -> %d\n", tpm->fd);
> +   files[tpm->fd].tpm_tis.dev = tpm;
> +   files[tpm->fd].tpm_tis.offset = 0;
> +   files[tpm->fd].tpm_tis.respgot = 0;
> +   return tpm->fd;
> +}
> +
> +int tpm_tis_posix_write(int fd, const uint8_t* buf, size_t count)
> +{
> +   struct tpm_chip* tpm;
> +   tpm = files[fd].tpm_tis.dev;
> +
> +   if(tpm->locality < 0) {
> +      printk("tpm_tis_posix_write() failed! locality not set!\n");
> +      errno = EINPROGRESS;
> +      return -1;
> +   }
> +   if(count == 0) {
> +      return 0;
> +   }
> +
> +   /* Return an error if we are already processing a command */
> +   if(count > TPM_BUFSIZE) {
> +      count = TPM_BUFSIZE;
> +   }
> +   /* Send the command now */
> +   memcpy(tpm->data_buffer, buf, count);
> +   if((tpm->data_len = tpm_transmit(tpm, tpm->data_buffer,
> TPM_BUFSIZE)) < 0) {
> +      errno = EIO;
> +      return -1;
> +   }
> +   return count;
> +}
> +
> +int tpm_tis_posix_read(int fd, uint8_t* buf, size_t count)
> +{
> +   int rc;
> +   struct tpm_chip* tpm;
> +   tpm = files[fd].tpm_tis.dev;
> +
> +   if(count == 0) {
> +      return 0;
> +   }
> +
> +   /* If there is no tpm resp to read, return EIO */
> +   if(tpm->data_len < 0) {
> +      errno = EIO;
> +      return -1;
> +   }
> +
> +
> +   /* Handle EOF case */
> +   if(files[fd].tpm_tis.offset >= tpm->data_len) {
> +      rc = 0;
> +   } else {
> +      rc = min(tpm->data_len - files[fd].tpm_tis.offset, count);
> +      memcpy(buf, tpm->data_buffer + files[fd].tpm_tis.offset, rc);
> +   }
> +   files[fd].tpm_tis.offset += rc;
> +   /* Reset the data pending flag */
> +   return rc;
> +}
> +int tpm_tis_posix_fstat(int fd, struct stat* buf)
> +{
> +   struct tpm_chip* tpm;
> +   tpm = files[fd].tpm_tis.dev;
> +
> +   buf->st_mode = O_RDWR;
> +   buf->st_uid = 0;
> +   buf->st_gid = 0;
> +   buf->st_size = be32_to_cpu(*((uint32_t*)(tpm->data_buffer + 2)));
> +   buf->st_atime = buf->st_mtime = buf->st_ctime = time(NULL);
> +   return 0;
> +}
> +
> +
> +#endif
> diff --git a/extras/mini-os/tpmback.c b/extras/mini-os/tpmback.c
> --- /dev/null
> +++ b/extras/mini-os/tpmback.c
> @@ -0,0 +1,1114 @@
> +/*
> + * Copyright (c) 2010-2012 United States Government, as represented by
> + * the Secretary of Defense.  All rights reserved.
> + *
> + * This driver 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 3 of the License, or
> + * (at your option) any later version.
> + *
> + * This driver is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program.  If not, see <http://www.gnu.org/licenses/>.
> + *
> + * Based upon the files:
> + *  drivers/xen/tpmbk.c
> + * from the Linux kernel, which are Copyright (C) 2006 IBM Corporation
> + */
> +#include <mini-os/os.h>
> +#include <mini-os/xenbus.h>
> +#include <mini-os/events.h>
> +#include <errno.h>
> +#include <mini-os/gnttab.h>
> +#include <xen/io/xenbus.h>
> +#include <xen/io/tpmif.h>
> +#include <xen/io/protocols.h>
> +#include <mini-os/xmalloc.h>
> +#include <time.h>
> +#include <mini-os/tpmback.h>
> +#include <mini-os/lib.h>
> +#include <fcntl.h>
> +#include <mini-os/mm.h>
> +#include <mini-os/posix/sys/mman.h>
> +#include <mini-os/semaphore.h>
> +#include <mini-os/wait.h>
> +
> +
> +#ifndef HAVE_LIBC
> +#define strtoul simple_strtoul
> +#endif
> +
> +//#define TPMBACK_PRINT_DEBUG
> +#ifdef TPMBACK_PRINT_DEBUG
> +#define TPMBACK_DEBUG(fmt,...) printk("Tpmback:Debug("__FILE__":%d) "
> fmt, __LINE__, ##__VA_ARGS__)
> +#define TPMBACK_DEBUG_MORE(fmt,...) printk(fmt, ##__VA_ARGS__)
> +#else
> +#define TPMBACK_DEBUG(fmt,...)
> +#endif
> +#define TPMBACK_ERR(fmt,...) printk("Tpmback:Error " fmt, ##__VA_ARGS__)
> +#define TPMBACK_LOG(fmt,...) printk("Tpmback:Info " fmt, ##__VA_ARGS__)
> +
> +#define min(a,b) (((a) < (b)) ? (a) : (b))
> +
> +/* Default size of the tpmif array at initialization */
> +#define DEF_ARRAY_SIZE 1
> +
> +/* tpmif and tpmdev flags */
> +#define TPMIF_CLOSED 1
> +#define TPMIF_REQ_READY 2
> +
> +struct tpmif {
> +   domid_t domid;
> +   unsigned int handle;
> +
> +   char* fe_path;
> +   char* fe_state_path;
> +
> +   /* Locally bound event channel*/
> +   evtchn_port_t evtchn;
> +
> +   /* Shared page */
> +   tpmif_tx_interface_t* tx;
> +
> +   /* pointer to TPMIF_RX_RING_SIZE pages */
> +   void** pages;
> +
> +   enum xenbus_state state;
> +   enum { DISCONNECTED, DISCONNECTING, CONNECTED } status;
> +
> +   char* uuid;
> +
> +   /* state flags */
> +   int flags;
> +};
> +typedef struct tpmif tpmif_t;
> +
> +struct tpmback_dev {
> +
> +   tpmif_t** tpmlist;
> +   unsigned long num_tpms;
> +   unsigned long num_alloc;
> +
> +   struct gntmap map;
> +
> +   /* True if at least one tpmif has a request to be handled */
> +   int flags;
> +
> +   /* exclusive domains, see init_tpmback comment in tpmback.h */
> +   char** exclusive_uuids;
> +
> +   xenbus_event_queue events;
> +
> +   /* Callbacks */
> +   void (*open_callback)(domid_t, unsigned int);
> +   void (*close_callback)(domid_t, unsigned int);
> +   void (*suspend_callback)(domid_t, unsigned int);
> +   void (*resume_callback)(domid_t, unsigned int);
> +};
> +typedef struct tpmback_dev tpmback_dev_t;
> +
> +enum { EV_NONE, EV_NEWFE, EV_STCHNG } tpm_ev_enum;
> +
> +/* Global objects */
> +static struct thread* eventthread = NULL;
> +static tpmback_dev_t gtpmdev = {
> +   .tpmlist = NULL,
> +   .num_tpms = 0,
> +   .num_alloc = 0,
> +   .flags = TPMIF_CLOSED,
> +   .events = NULL,
> +   .open_callback = NULL,
> +   .close_callback = NULL,
> +   .suspend_callback = NULL,
> +   .resume_callback = NULL,
> +};
> +struct wait_queue_head waitq;
> +int globalinit = 0;
> +
> +/************************************
> + * TPMIF SORTED ARRAY FUNCTIONS
> + * tpmback_dev_t.tpmlist is a sorted array, sorted by domid and then
> handle number
> + * Duplicates are not allowed
> + * **********************************/
> +
> +inline void tpmif_req_ready(tpmif_t* tpmif) {
> +   tpmif->flags |= TPMIF_REQ_READY;
> +   gtpmdev.flags |= TPMIF_REQ_READY;
> +}
> +
> +inline void tpmdev_check_req(void) {
> +   int i;
> +   int flags;
> +   local_irq_save(flags);
> +   for(i = 0; i < gtpmdev.num_tpms; ++i) {
> +      if(gtpmdev.tpmlist[i]->flags & TPMIF_REQ_READY) {
> +     gtpmdev.flags |= TPMIF_REQ_READY;
> +     local_irq_restore(flags);
> +     return;
> +      }
> +   }
> +   gtpmdev.flags &= ~TPMIF_REQ_READY;
> +   local_irq_restore(flags);
> +}
> +
> +inline void tpmif_req_finished(tpmif_t* tpmif) {
> +   tpmif->flags &= ~TPMIF_REQ_READY;
> +   tpmdev_check_req();
> +}
> +
> +int __get_tpmif_index(int st, int n, domid_t domid, unsigned int handle)
> +{
> +   int i = st + n /2;
> +   tpmif_t* tmp;
> +
> +   if( n <= 0 )
> +      return -1;
> +
> +   tmp = gtpmdev.tpmlist[i];
> +   if(domid == tmp->domid && tmp->handle == handle) {
> +      return i;
> +   } else if ( (domid < tmp->domid) ||
> +     (domid == tmp->domid && handle < tmp->handle)) {
> +      return __get_tpmif_index(st, n/2, domid, handle);
> +   } else {
> +      return __get_tpmif_index(i + 1, n/2 - ((n +1) % 2), domid, handle);
> +   }
> +}
> +
> +/* Returns the array index of the tpmif domid/handle. Returns -1 if no
> such tpmif exists */
> +int get_tpmif_index(domid_t domid, unsigned int handle)
> +{
> +   int flags;
> +   int index;
> +   local_irq_save(flags);
> +   index = __get_tpmif_index(0, gtpmdev.num_tpms, domid, handle);
> +   local_irq_restore(flags);
> +   return index;
> +}
> +
> +/* Returns the tpmif domid/handle or NULL if none exists */
> +tpmif_t* get_tpmif(domid_t domid, unsigned int handle)
> +{
> +   int flags;
> +   int i;
> +   tpmif_t* ret;
> +   local_irq_save(flags);
> +   i = get_tpmif_index(domid, handle);
> +   if (i < 0) {
> +      ret = NULL;
> +   } else {
> +      ret = gtpmdev.tpmlist[i];
> +   }
> +   local_irq_restore(flags);
> +   return ret;
> +}
> +
> +/* Remove the given tpmif. Returns 0 if it was removed, -1 if it was
> not removed */
> +int remove_tpmif(tpmif_t* tpmif)
> +{
> +   int i, j;
> +   char* err;
> +   int flags;
> +   local_irq_save(flags);
> +
> +   /* Find the index in the array if it exists */
> +   i = get_tpmif_index(tpmif->domid, tpmif->handle);
> +   if (i < 0) {
> +      goto error;
> +   }
> +
> +   /* Remove the interface from the list */
> +   for(j = i; j < gtpmdev.num_tpms - 1; ++j) {
> +      gtpmdev.tpmlist[j] = gtpmdev.tpmlist[j+1];
> +   }
> +   gtpmdev.tpmlist[j] = NULL;
> +   --gtpmdev.num_tpms;
> +
> +   /* If removed tpm was the only ready tpm, then we need to check and
> turn off the ready flag */
> +   tpmdev_check_req();
> +
> +   local_irq_restore(flags);
> +
> +   /* Stop listening for events on this tpm interface */
> +   if((err = xenbus_unwatch_path_token(XBT_NIL, tpmif->fe_state_path,
> tpmif->fe_state_path))) {
> +      TPMBACK_ERR("Unable to unwatch path token `%s' Error was %s
> Ignoring..\n", tpmif->fe_state_path, err);
> +      free(err);
> +   }
> +
> +   return 0;
> +error:
> +   local_irq_restore(flags);
> +   return -1;
> +}
> +
> +/* Insert tpmif into dev->tpmlist. Returns 0 on success and non zero on
> error.
> + * It is an error to insert a tpmif with the same domid and handle
> + * number
> + * as something already in the list */
> +int insert_tpmif(tpmif_t* tpmif)
> +{
> +   int flags;
> +   unsigned int i, j;
> +   tpmif_t* tmp;
> +   char* err;
> +
> +   local_irq_save(flags);
> +
> +   /*Check if we need to allocate more space */
> +   if (gtpmdev.num_tpms == gtpmdev.num_alloc) {
> +      gtpmdev.num_alloc *= 2;
> +      gtpmdev.tpmlist = realloc(gtpmdev.tpmlist, gtpmdev.num_alloc);
> +   }
> +
> +   /*Find where to put the new interface */
> +   for(i = 0; i < gtpmdev.num_tpms; ++i)
> +   {
> +      tmp = gtpmdev.tpmlist[i];
> +      if(tpmif->domid == tmp->domid && tpmif->handle == tmp->handle) {
> +     TPMBACK_ERR("Tried to insert duplicate tpm interface %u/%u\n",
> (unsigned int) tpmif->domid, tpmif->handle);
> +     goto error;
> +      }
> +      if((tpmif->domid < tmp->domid) ||
> +        (tpmif->domid == tmp->domid && tpmif->handle < tmp->handle)) {
> +     break;
> +      }
> +   }
> +
> +   /*Shift all the tpm pointers past i down one */
> +   for(j = gtpmdev.num_tpms; j > i; --j) {
> +      gtpmdev.tpmlist[j] = gtpmdev.tpmlist[j-1];
> +   }
> +
> +   /*Add the new interface */
> +   gtpmdev.tpmlist[i] = tpmif;
> +   ++gtpmdev.num_tpms;
> +
> +   /*Should not be needed, anything inserted with ready flag is
> probably an error */
> +   tpmdev_check_req();
> +
> +   local_irq_restore(flags);
> +
> +   /*Listen for state changes on the new interface */
> +   if((err = xenbus_watch_path_token(XBT_NIL, tpmif->fe_state_path,
> tpmif->fe_state_path, &gtpmdev.events)))
> +   {
> +      /* if we got an error here we should carefully remove the
> interface and then return */
> +      TPMBACK_ERR("Unable to watch path token `%s' Error was %s\n",
> tpmif->fe_state_path, err);
> +      free(err);
> +      remove_tpmif(tpmif);
> +      goto error_post_irq;
> +   }
> +
> +   return 0;
> +error:
> +   local_irq_restore(flags);
> +error_post_irq:
> +   return -1;
> +}
> +
> +
> +/*****************
> + * CHANGE BACKEND STATE
> + * *****************/
> +/*Attempts to change the backend state in xenstore
> + * returns 0 on success and non-zero on error */
> +int tpmif_change_state(tpmif_t* tpmif, enum xenbus_state state)
> +{
> +   char path[512];
> +   char *value;
> +   char *err;
> +   enum xenbus_state readst;
> +   TPMBACK_DEBUG("Backend state change %u/%u from=%d to=%d\n",
> (unsigned int) tpmif->domid, tpmif->handle, tpmif->state, state);
> +   if (tpmif->state == state)
> +      return 0;
> +
> +   snprintf(path, 512, "backend/vtpm/%u/%u/state", (unsigned int)
> tpmif->domid, tpmif->handle);
> +
> +   if((err = xenbus_read(XBT_NIL, path, &value))) {
> +      TPMBACK_ERR("Unable to read backend state %s, error was %s\n",
> path, err);
> +      free(err);
> +      return -1;
> +   }
> +   if(sscanf(value, "%d", &readst) != 1) {
> +      TPMBACK_ERR("Non integer value (%s) in %s ??\n", value, path);
> +      free(value);
> +      return -1;
> +   }
> +   free(value);
> +
> +   /* It's possible that the backend state got updated by hotplug or
> something else behind our back */
> +   if(readst != tpmif->state) {
> +      TPMBACK_DEBUG("tpm interface state was %d but xenstore state was
> %d!\n", tpmif->state, readst);
> +      tpmif->state = readst;
> +   }
> +
> +   /*If if the state isnt changing, then we dont update xenstore b/c we
> dont want to fire extraneous events */
> +   if(tpmif->state == state) {
> +      return 0;
> +   }
> +
> +   /*update xenstore*/
> +   snprintf(path, 512, "backend/vtpm/%u/%u", (unsigned int)
> tpmif->domid, tpmif->handle);
> +   if((err = xenbus_printf(XBT_NIL, path, "state", "%u", state))) {
> +      TPMBACK_ERR("Error writing to xenstore %s, error was %s new
> state=%d\n", path, err, state);
> +      free(err);
> +      return -1;
> +   }
> +
> +   tpmif->state = state;
> +
> +   return 0;
> +}
> +/**********************************
> + * TPMIF CREATION AND DELETION
> + * *******************************/
> +inline tpmif_t* __init_tpmif(domid_t domid, unsigned int handle)
> +{
> +   tpmif_t* tpmif;
> +   tpmif = malloc(sizeof(*tpmif));
> +   tpmif->domid = domid;
> +   tpmif->handle = handle;
> +   tpmif->fe_path = NULL;
> +   tpmif->fe_state_path = NULL;
> +   tpmif->state = XenbusStateInitialising;
> +   tpmif->status = DISCONNECTED;
> +   tpmif->tx = NULL;
> +   tpmif->pages = NULL;
> +   tpmif->flags = 0;
> +   tpmif->uuid = NULL;
> +   return tpmif;
> +}
> +
> +void __free_tpmif(tpmif_t* tpmif)
> +{
> +   if(tpmif->pages) {
> +      free(tpmif->pages);
> +   }
> +   if(tpmif->fe_path) {
> +      free(tpmif->fe_path);
> +   }
> +   if(tpmif->fe_state_path) {
> +      free(tpmif->fe_state_path);
> +   }
> +   if(tpmif->uuid) {
> +      free(tpmif->uuid);
> +   }
> +   free(tpmif);
> +}
> +/* Creates a new tpm interface, adds it to the sorted array and returns it.
> + * returns NULL on error
> + * If the tpm interface already exists, it is returned*/
> +tpmif_t* new_tpmif(domid_t domid, unsigned int handle)
> +{
> +   tpmif_t* tpmif;
> +   char* err;
> +   char path[512];
> +
> +   /* Make sure we haven't already created this tpm
> +    * Double events can occur */
> +   if((tpmif = get_tpmif(domid, handle)) != NULL) {
> +      return tpmif;
> +   }
> +
> +   tpmif = __init_tpmif(domid, handle);
> +
> +   /* Get the uuid from xenstore */
> +   snprintf(path, 512, "backend/vtpm/%u/%u/uuid", (unsigned int) domid,
> handle);
> +   if((err = xenbus_read(XBT_NIL, path, &tpmif->uuid))) {
> +      TPMBACK_ERR("Error reading %s, Error = %s\n", path, err);
> +      free(err);
> +      goto error;
> +   }
> +
> +   /* Do the exclusive uuid check now */
> +   if(gtpmdev.exclusive_uuids != NULL) {
> +      char** ptr;
> +
> +      /* Check that its in the whitelist */
> +      for(ptr = gtpmdev.exclusive_uuids; *ptr != NULL; ++ptr) {
> +     if(!strcmp(tpmif->uuid, *ptr)) {
> +        break;
> +     }
> +      }
> +      /* If *ptr == NULL then we went through the whole list without a
> match, so close the connection */
> +      if(*ptr == NULL) {
> +     tpmif_change_state(tpmif, XenbusStateClosed);
> +     TPMBACK_ERR("Frontend %u/%u tried to connect with invalid
> uuid=%s\n", (unsigned int) domid, handle, tpmif->uuid);
> +     goto error;
> +      }
> +   }
> +
> +   /* allocate pages to be used for shared mapping */
> +   if((tpmif->pages = malloc(sizeof(void*) * TPMIF_TX_RING_SIZE)) ==
> NULL) {
> +      goto error;
> +   }
> +   memset(tpmif->pages, 0, sizeof(void*) * TPMIF_TX_RING_SIZE);
> +
> +   if(tpmif_change_state(tpmif, XenbusStateInitWait)) {
> +      goto error;
> +   }
> +
> +   snprintf(path, 512, "backend/vtpm/%u/%u/frontend", (unsigned int)
> domid, handle);
> +   if((err = xenbus_read(XBT_NIL, path, &tpmif->fe_path))) {
> +      TPMBACK_ERR("Error creating new tpm instance xenbus_read(%s),
> Error = %s", path, err);
> +      free(err);
> +      goto error;
> +   }
> +
> +   /*Set the state path */
> +   tpmif->fe_state_path = malloc(strlen(tpmif->fe_path) + 7);
> +   strcpy(tpmif->fe_state_path, tpmif->fe_path);
> +   strcat(tpmif->fe_state_path, "/state");
> +
> +   if(insert_tpmif(tpmif)) {
> +      goto error;
> +   }
> +   TPMBACK_DEBUG("New tpmif %u/%u\n", (unsigned int) tpmif->domid,
> tpmif->handle);
> +   /* Do the callback now */
> +   if(gtpmdev.open_callback) {
> +      gtpmdev.open_callback(tpmif->domid, tpmif->handle);
> +   }
> +   return tpmif;
> +error:
> +   __free_tpmif(tpmif);
> +   return NULL;
> +
> +}
> +
> +/* Removes tpmif from dev->tpmlist and frees it's memory usage */
> +void free_tpmif(tpmif_t* tpmif)
> +{
> +   char* err;
> +   char path[512];
> +   TPMBACK_DEBUG("Free tpmif %u/%u\n", (unsigned int) tpmif->domid,
> tpmif->handle);
> +   if(tpmif->flags & TPMIF_CLOSED) {
> +      TPMBACK_ERR("Tried to free an instance twice! Theres a bug
> somewhere!\n");
> +      BUG();
> +   }
> +   tpmif->flags = TPMIF_CLOSED;
> +
> +   tpmif_change_state(tpmif, XenbusStateClosing);
> +
> +   /* Unmap share page and unbind event channel */
> +   if(tpmif->status == CONNECTED) {
> +      tpmif->status = DISCONNECTING;
> +      mask_evtchn(tpmif->evtchn);
> +
> +      if(gntmap_munmap(&gtpmdev.map, (unsigned long)tpmif->tx, 1)) {
> +     TPMBACK_ERR("%u/%u Error occured while trying to unmap shared
> page\n", (unsigned int) tpmif->domid, tpmif->handle);
> +      }
> +
> +      unbind_evtchn(tpmif->evtchn);
> +   }
> +   tpmif->status = DISCONNECTED;
> +   tpmif_change_state(tpmif, XenbusStateClosed);
> +
> +   /* Do the callback now */
> +   if(gtpmdev.close_callback) {
> +      gtpmdev.close_callback(tpmif->domid, tpmif->handle);
> +   }
> +
> +   /* remove from array */
> +   remove_tpmif(tpmif);
> +
> +   /* Wake up anyone possibly waiting on this interface and let them
> exit */
> +   wake_up(&waitq);
> +   schedule();
> +
> +   /* Remove the old xenbus entries */
> +   snprintf(path, 512, "backend/vtpm/%u/%u", (unsigned int)
> tpmif->domid, tpmif->handle);
> +   if((err = xenbus_rm(XBT_NIL, path))) {
> +      TPMBACK_ERR("Error cleaning up xenbus entries path=%s
> error=%s\n", path, err);
> +      free(err);
> +   }
> +
> +   TPMBACK_LOG("Frontend %u/%u disconnected\n", (unsigned int)
> tpmif->domid, tpmif->handle);
> +
> +   /* free memory */
> +   __free_tpmif(tpmif);
> +
> +}
> +
> +/**********************
> + * REMAINING TPMBACK FUNCTIONS
> + * ********************/
> +
> +/*Event channel handler */
> +void tpmback_handler(evtchn_port_t port, struct pt_regs *regs, void *data)
> +{
> +   tpmif_t* tpmif = (tpmif_t*) data;
> +   tpmif_tx_request_t* tx = &tpmif->tx->ring[0].req;
> +   /* Throw away 0 size events, these can trigger from event channel
> unmasking */
> +   if(tx->size == 0)
> +      return;
> +
> +   TPMBACK_DEBUG("EVENT CHANNEL FIRE %u/%u\n", (unsigned int)
> tpmif->domid, tpmif->handle);
> +   tpmif_req_ready(tpmif);
> +   wake_up(&waitq);
> +
> +}
> +
> +/* Connect to frontend */
> +int connect_fe(tpmif_t* tpmif)
> +{
> +   char path[512];
> +   char* err, *value;
> +   uint32_t domid;
> +   grant_ref_t ringref;
> +   evtchn_port_t evtchn;
> +
> +   /* If already connected then quit */
> +   if (tpmif->status == CONNECTED) {
> +      TPMBACK_DEBUG("%u/%u tried to connect while it was already
> connected?\n", (unsigned int) tpmif->domid, tpmif->handle);
> +      return 0;
> +   }
> +
> +   /* Fetch the grant reference */
> +   snprintf(path, 512, "%s/ring-ref", tpmif->fe_path);
> +   if((err = xenbus_read(XBT_NIL, path, &value))) {
> +      TPMBACK_ERR("Error creating new tpm instance xenbus_read(%s)
> Error = %s", path, err);
> +      free(err);
> +      return -1;
> +   }
> +   if(sscanf(value, "%d", &ringref) != 1) {
> +      TPMBACK_ERR("Non integer value (%s) in %s ??\n", value, path);
> +      free(value);
> +      return -1;
> +   }
> +   free(value);
> +
> +
> +   /* Fetch the event channel*/
> +   snprintf(path, 512, "%s/event-channel", tpmif->fe_path);
> +   if((err = xenbus_read(XBT_NIL, path, &value))) {
> +      TPMBACK_ERR("Error creating new tpm instance xenbus_read(%s)
> Error = %s", path, err);
> +      free(err);
> +      return -1;
> +   }
> +   if(sscanf(value, "%d", &evtchn) != 1) {
> +      TPMBACK_ERR("Non integer value (%s) in %s ??\n", value, path);
> +      free(value);
> +      return -1;
> +   }
> +   free(value);
> +
> +   domid = tpmif->domid;
> +   if((tpmif->tx = gntmap_map_grant_refs(&gtpmdev.map, 1, &domid, 0,
> &ringref, PROT_READ | PROT_WRITE)) == NULL) {
> +      TPMBACK_ERR("Failed to map grant reference %u/%u\n", (unsigned
> int) tpmif->domid, tpmif->handle);
> +      return -1;
> +   }
> +   memset(tpmif->tx, 0, PAGE_SIZE);
> +
> +   /*Bind the event channel */
> +   if((evtchn_bind_interdomain(tpmif->domid, evtchn, tpmback_handler,
> tpmif, &tpmif->evtchn)))
> +   {
> +      TPMBACK_ERR("%u/%u Unable to bind to interdomain event
> channel!\n", (unsigned int) tpmif->domid, tpmif->handle);
> +      goto error_post_map;
> +   }
> +   unmask_evtchn(tpmif->evtchn);
> +
> +   /* Write the ready flag and change status to connected */
> +   snprintf(path, 512, "backend/vtpm/%u/%u", (unsigned int)
> tpmif->domid, tpmif->handle);
> +   if((err = xenbus_printf(XBT_NIL, path, "ready", "%u", 1))) {
> +      TPMBACK_ERR("%u/%u Unable to write ready flag on connect_fe()\n",
> (unsigned int) tpmif->domid, tpmif->handle);
> +      free(err);
> +      goto error_post_evtchn;
> +   }
> +   tpmif->status = CONNECTED;
> +   if((tpmif_change_state(tpmif, XenbusStateConnected))){
> +      goto error_post_evtchn;
> +   }
> +
> +   TPMBACK_LOG("Frontend %u/%u connected\n", (unsigned int)
> tpmif->domid, tpmif->handle);
> +
> +   return 0;
> +error_post_evtchn:
> +   mask_evtchn(tpmif->evtchn);
> +   unbind_evtchn(tpmif->evtchn);
> +error_post_map:
> +   gntmap_munmap(&gtpmdev.map, (unsigned long)tpmif->tx, 1);
> +   return -1;
> +}
> +
> +static int frontend_changed(tpmif_t* tpmif)
> +{
> +   int state = xenbus_read_integer(tpmif->fe_state_path);
> +   if(state < 0) {
> +      state = XenbusStateUnknown;
> +   }
> +
> +   TPMBACK_DEBUG("Frontend %u/%u state changed to %d\n", (unsigned int)
> tpmif->domid, tpmif->handle, state);
> +
> +   switch (state) {
> +      case XenbusStateInitialising:
> +      case XenbusStateInitialised:
> +     break;
> +
> +      case XenbusStateConnected:
> +     if(connect_fe(tpmif)) {
> +        TPMBACK_ERR("Failed to connect to front end %u/%u\n", (unsigned
> int) tpmif->domid, tpmif->handle);
> +        tpmif_change_state(tpmif, XenbusStateClosed);
> +        return -1;
> +     }
> +     break;
> +
> +      case XenbusStateClosing:
> +     tpmif_change_state(tpmif, XenbusStateClosing);
> +     break;
> +
> +      case XenbusStateUnknown: /* keep it here */
> +      case XenbusStateClosed:
> +     free_tpmif(tpmif);
> +     break;
> +
> +      default:
> +     TPMBACK_DEBUG("BAD STATE CHANGE %u/%u state = %d for tpmif\n",
> (unsigned int) tpmif->domid, tpmif->handle, state);
> +     return -1;
> +   }
> +   return 0;
> +}
> +
> +
> +/* parses the string that comes out of xenbus_watch_wait_return. */
> +static int parse_eventstr(const char* evstr, domid_t* domid, unsigned
> int* handle)
> +{
> +   int ret;
> +   char cmd[40];
> +   char* err;
> +   char* value;
> +   unsigned int udomid = 0;
> +   tpmif_t* tpmif;
> +   /* First check for new frontends, this occurs when
> /backend/vtpm/<domid>/<handle> gets created. Note we what the sscanf to
> fail on the last %s */
> +   if (sscanf(evstr, "backend/vtpm/%u/%u/%40s", &udomid, handle, cmd)
> == 2) {
> +      *domid = udomid;
> +      /* Make sure the entry exists, if this event triggers because the
> entry dissapeared then ignore it */
> +      if((err = xenbus_read(XBT_NIL, evstr, &value))) {
> +     free(err);
> +     return EV_NONE;
> +      }
> +      free(value);
> +      /* Make sure the tpmif entry does not already exist, this should
> not happen */
> +      if((tpmif = get_tpmif(*domid, *handle)) != NULL) {
> +     TPMBACK_DEBUG("Duplicate tpm entries! %u %u\n", tpmif->domid,
> tpmif->handle);
> +     return EV_NONE;
> +      }
> +      return EV_NEWFE;
> +   } else if((ret = sscanf(evstr,
> "/local/domain/%u/device/vtpm/%u/%40s", &udomid, handle, cmd)) == 3) {
> +      *domid = udomid;
> +      if (!strcmp(cmd, "state"))
> +     return EV_STCHNG;
> +   }
> +   return EV_NONE;
> +}
> +
> +void handle_backend_event(char* evstr) {
> +   tpmif_t* tpmif;
> +   domid_t domid;
> +   unsigned int handle;
> +   int event;
> +
> +   TPMBACK_DEBUG("Xenbus Event: %s\n", evstr);
> +
> +   event = parse_eventstr(evstr, &domid, &handle);
> +
> +   switch(event) {
> +      case EV_NEWFE:
> +     if(new_tpmif(domid, handle) == NULL) {
> +        TPMBACK_ERR("Failed to create new tpm instance %u/%u\n",
> (unsigned int) domid, handle);
> +     }
> +     wake_up(&waitq);
> +     break;
> +      case EV_STCHNG:
> +     if((tpmif = get_tpmif(domid, handle))) {
> +        frontend_changed(tpmif);
> +     } else {
> +        TPMBACK_DEBUG("Event Received for non-existant tpm!
> instance=%u/%u xenbus_event=%s\n", (unsigned int) domid, handle, evstr);
> +     }
> +     break;
> +   }
> +}
> +
> +/* Runs through the given path and creates events recursively
> + * for all of its children.
> + * @path - xenstore path to scan */
> +static void generate_backend_events(const char* path)
> +{
> +   char* err;
> +   int i, len;
> +   char **dirs;
> +   char *entry;
> +
> +   if((err = xenbus_ls(XBT_NIL, path, &dirs)) != NULL) {
> +      free(err);
> +      return;
> +   }
> +
> +   for(i = 0; dirs[i] != NULL; ++i) {
> +      len = strlen(path) + strlen(dirs[i]) + 2;
> +      entry = malloc(len);
> +      snprintf(entry, len, "%s/%s", path, dirs[i]);
> +
> +      /* Generate and handle event for the entry itself */
> +      handle_backend_event(entry);
> +
> +      /* Do children */
> +      generate_backend_events(entry);
> +
> +      /* Cleanup */
> +      free(entry);
> +      free(dirs[i]);
> +   }
> +   free(dirs);
> +   return;
> +}
> +
> +char* tpmback_get_uuid(domid_t domid, unsigned int handle)
> +{
> +   tpmif_t* tpmif;
> +   if((tpmif = get_tpmif(domid, handle)) == NULL) {
> +      TPMBACK_DEBUG("get_uuid() failed, %u/%u is an invalid
> frontend\n", (unsigned int) domid, handle);
> +      return NULL;
> +   }
> +
> +   return tpmif->uuid;
> +}
> +
> +void tpmback_set_open_callback(void (*cb)(domid_t, unsigned int))
> +{
> +   gtpmdev.open_callback = cb;
> +}
> +void tpmback_set_close_callback(void (*cb)(domid_t, unsigned int))
> +{
> +   gtpmdev.close_callback = cb;
> +}
> +void tpmback_set_suspend_callback(void (*cb)(domid_t, unsigned int))
> +{
> +   gtpmdev.suspend_callback = cb;
> +}
> +void tpmback_set_resume_callback(void (*cb)(domid_t, unsigned int))
> +{
> +   gtpmdev.resume_callback = cb;
> +}
> +
> +static void event_listener(void)
> +{
> +   const char* bepath = "backend/vtpm";
> +   char **path;
> +   char* err;
> +
> +   /* Setup the backend device watch */
> +   if((err = xenbus_watch_path_token(XBT_NIL, bepath, bepath,
> &gtpmdev.events)) != NULL) {
> +      TPMBACK_ERR("xenbus_watch_path_token(%s) failed with error
> %s!\n", bepath, err);
> +      free(err);
> +      goto egress;
> +   }
> +
> +   /* Check for any frontends that connected before we set the watch.
> +    * This is almost guaranteed to happen if both domains are started
> +    * immediatly one after the other.
> +    * We do this by manually generating events on everything in the backend
> +    * path */
> +   generate_backend_events(bepath);
> +
> +   /* Wait and listen for changes in frontend connections */
> +   while(1) {
> +      path = xenbus_wait_for_watch_return(&gtpmdev.events);
> +
> +      /*If quit flag was set then exit */
> +      if(gtpmdev.flags & TPMIF_CLOSED) {
> +     TPMBACK_DEBUG("listener thread got quit event. Exiting..\n");
> +     free(path);
> +     break;
> +      }
> +      handle_backend_event(*path);
> +      free(path);
> +
> +   }
> +
> +   if((err = xenbus_unwatch_path_token(XBT_NIL, bepath, bepath)) != NULL) {
> +      free(err);
> +   }
> +egress:
> +   return;
> +}
> +
> +void event_thread(void* p) {
> +   event_listener();
> +}
> +
> +void init_tpmback(char** exclusive_uuids)
> +{
> +   if(!globalinit) {
> +      init_waitqueue_head(&waitq);
> +      globalinit = 1;
> +   }
> +   printk("============= Init TPM BACK ================\n");
> +   gtpmdev.tpmlist = malloc(sizeof(tpmif_t*) * DEF_ARRAY_SIZE);
> +   gtpmdev.num_alloc = DEF_ARRAY_SIZE;
> +   gtpmdev.num_tpms = 0;
> +   gtpmdev.flags = 0;
> +   gtpmdev.exclusive_uuids = exclusive_uuids;
> +
> +   gtpmdev.open_callback = gtpmdev.close_callback = NULL;
> +   gtpmdev.suspend_callback = gtpmdev.resume_callback = NULL;
> +
> +   eventthread = create_thread("tpmback-listener", event_thread, NULL);
> +
> +}
> +
> +void shutdown_tpmback(void)
> +{
> +   /* Disable callbacks */
> +   gtpmdev.open_callback = gtpmdev.close_callback = NULL;
> +   gtpmdev.suspend_callback = gtpmdev.resume_callback = NULL;
> +
> +   TPMBACK_LOG("Shutting down tpm backend\n");
> +   /* Set the quit flag */
> +   gtpmdev.flags = TPMIF_CLOSED;
> +
> +   //printk("num tpms is %d\n", gtpmdev.num_tpms);
> +   /*Free all backend instances */
> +   while(gtpmdev.num_tpms) {
> +      free_tpmif(gtpmdev.tpmlist[0]);
> +   }
> +   free(gtpmdev.tpmlist);
> +   gtpmdev.tpmlist = NULL;
> +   gtpmdev.num_alloc = 0;
> +
> +   /* Wake up anyone possibly waiting on the device and let them exit */
> +   wake_up(&waitq);
> +   schedule();
> +}
> +
> +inline void init_tpmcmd(tpmcmd_t* tpmcmd, domid_t domid, unsigned int
> handle, char* uuid)
> +{
> +   tpmcmd->domid = domid;
> +   tpmcmd->handle = handle;
> +   tpmcmd->uuid = uuid;
> +   tpmcmd->req = NULL;
> +   tpmcmd->req_len = 0;
> +   tpmcmd->resp = NULL;
> +   tpmcmd->resp_len = 0;
> +}
> +
> +tpmcmd_t* get_request(tpmif_t* tpmif) {
> +   tpmcmd_t* cmd;
> +   tpmif_tx_request_t* tx;
> +   int offset;
> +   int tocopy;
> +   int i;
> +   uint32_t domid;
> +   int flags;
> +
> +   local_irq_save(flags);
> +
> +   /* Allocate the cmd object to hold the data */
> +   if((cmd = malloc(sizeof(*cmd))) == NULL) {
> +      goto error;
> +   }
> +   init_tpmcmd(cmd, tpmif->domid, tpmif->handle, tpmif->uuid);
> +
> +   tx = &tpmif->tx->ring[0].req;
> +   cmd->req_len = tx->size;
> +   /* Allocate the buffer */
> +   if(cmd->req_len) {
> +      if((cmd->req = malloc(cmd->req_len)) == NULL) {
> +     goto error;
> +      }
> +   }
> +   /* Copy the bits from the shared pages */
> +   offset = 0;
> +   for(i = 0; i < TPMIF_TX_RING_SIZE && offset < cmd->req_len; ++i) {
> +      tx = &tpmif->tx->ring[i].req;
> +
> +      /* Map the page with the data */
> +      domid = (uint32_t)tpmif->domid;
> +      if((tpmif->pages[i] = gntmap_map_grant_refs(&gtpmdev.map, 1,
> &domid, 0, &tx->ref, PROT_READ)) == NULL) {
> +     TPMBACK_ERR("%u/%u Unable to map shared page during read!\n",
> (unsigned int) tpmif->domid, tpmif->handle);
> +     goto error;
> +      }
> +
> +      /* do the copy now */
> +      tocopy = min(cmd->req_len - offset, PAGE_SIZE);
> +      memcpy(&cmd->req[offset], tpmif->pages[i], tocopy);
> +      offset += tocopy;
> +
> +      /* release the page */
> +      gntmap_munmap(&gtpmdev.map, (unsigned long)tpmif->pages[i], 1);
> +
> +   }
> +
> +#ifdef TPMBACK_PRINT_DEBUG
> +   TPMBACK_DEBUG("Received Tpm Command from %u/%u of size %u",
> (unsigned int) tpmif->domid, tpmif->handle, cmd->req_len);
> +   for(i = 0; i < cmd->req_len; ++i) {
> +      if (!(i % 30)) {
> +     TPMBACK_DEBUG_MORE("\n");
> +      }
> +      TPMBACK_DEBUG_MORE("%02hhX ", cmd->req[i]);
> +   }
> +   TPMBACK_DEBUG_MORE("\n\n");
> +#endif
> +
> +   local_irq_restore(flags);
> +   return cmd;
> +error:
> +   if(cmd != NULL) {
> +      if (cmd->req != NULL) {
> +     free(cmd->req);
> +     cmd->req = NULL;
> +      }
> +      free(cmd);
> +      cmd = NULL;
> +   }
> +   local_irq_restore(flags);
> +   return NULL;
> +
> +}
> +
> +void send_response(tpmcmd_t* cmd, tpmif_t* tpmif)
> +{
> +   tpmif_tx_request_t* tx;
> +   int offset;
> +   int i;
> +   uint32_t domid;
> +   int tocopy;
> +   int flags;
> +
> +   local_irq_save(flags);
> +
> +   tx = &tpmif->tx->ring[0].req;
> +   tx->size = cmd->resp_len;
> +
> +   offset = 0;
> +   for(i = 0; i < TPMIF_TX_RING_SIZE && offset < cmd->resp_len; ++i) {
> +      tx = &tpmif->tx->ring[i].req;
> +
> +      /* Map the page with the data */
> +      domid = (uint32_t)tpmif->domid;
> +      if((tpmif->pages[i] = gntmap_map_grant_refs(&gtpmdev.map, 1,
> &domid, 0, &tx->ref, PROT_WRITE)) == NULL) {
> +     TPMBACK_ERR("%u/%u Unable to map shared page during write!\n",
> (unsigned int) tpmif->domid, tpmif->handle);
> +     goto error;
> +      }
> +
> +      /* do the copy now */
> +      tocopy = min(cmd->resp_len - offset, PAGE_SIZE);
> +      memcpy(tpmif->pages[i], &cmd->resp[offset], tocopy);
> +      offset += tocopy;
> +
> +      /* release the page */
> +      gntmap_munmap(&gtpmdev.map, (unsigned long)tpmif->pages[i], 1);
> +
> +   }
> +
> +#ifdef TPMBACK_PRINT_DEBUG
> +   TPMBACK_DEBUG("Sent response to %u/%u of size %u", (unsigned int)
> tpmif->domid, tpmif->handle, cmd->resp_len);
> +   for(i = 0; i < cmd->resp_len; ++i) {
> +      if (!(i % 30)) {
> +     TPMBACK_DEBUG_MORE("\n");
> +      }
> +      TPMBACK_DEBUG_MORE("%02hhX ", cmd->resp[i]);
> +   }
> +   TPMBACK_DEBUG_MORE("\n\n");
> +#endif
> +   /* clear the ready flag and send the event channel notice to the
> frontend */
> +   tpmif_req_finished(tpmif);
> +   notify_remote_via_evtchn(tpmif->evtchn);
> +error:
> +   local_irq_restore(flags);
> +   return;
> +}
> +
> +tpmcmd_t* tpmback_req_any(void)
> +{
> +   int i;
> +   /* Block until something has a request */
> +   wait_event(waitq, (gtpmdev.flags & (TPMIF_REQ_READY | TPMIF_CLOSED)));
> +
> +   /* Check if were shutting down */
> +   if(gtpmdev.flags & TPMIF_CLOSED) {
> +      /* if something was waiting for us to give up the queue so it can
> shutdown, let it finish */
> +      schedule();
> +      return NULL;
> +   }
> +
> +   for(i = 0; i < gtpmdev.num_tpms; ++i) {
> +      if(gtpmdev.tpmlist[i]->flags & TPMIF_REQ_READY) {
> +     return get_request(gtpmdev.tpmlist[i]);
> +      }
> +   }
> +
> +   TPMBACK_ERR("backend request ready flag was set but no interfaces
> were actually ready\n");
> +   return NULL;
> +}
> +
> +tpmcmd_t* tpmback_req(domid_t domid, unsigned int handle)
> +{
> +   tpmif_t* tpmif;
> +   tpmif = get_tpmif(domid, handle);
> +   if(tpmif == NULL) {
> +      return NULL;
> +   }
> +
> +   wait_event(waitq, (tpmif->flags & (TPMIF_REQ_READY | TPMIF_CLOSED)
> || gtpmdev.flags & TPMIF_CLOSED));
> +
> +   /* Check if were shutting down */
> +   if(tpmif->flags & TPMIF_CLOSED || gtpmdev.flags & TPMIF_CLOSED) {
> +      /* if something was waiting for us to give up the queue so it can
> free this instance, let it finish */
> +      schedule();
> +      return NULL;
> +   }
> +
> +   return get_request(tpmif);
> +}
> +
> +void tpmback_resp(tpmcmd_t* tpmcmd)
> +{
> +   tpmif_t* tpmif;
> +
> +   /* Get the associated interface, if it doesnt exist then just quit */
> +   tpmif = get_tpmif(tpmcmd->domid, tpmcmd->handle);
> +   if(tpmif == NULL) {
> +      TPMBACK_ERR("Tried to send a reponse to non existant frontend
> %u/%u\n", (unsigned int) tpmcmd->domid, tpmcmd->handle);
> +      goto end;
> +   }
> +
> +   if(!(tpmif->flags & TPMIF_REQ_READY)) {
> +      TPMBACK_ERR("Tried to send response to a frontend that was not
> waiting for one %u/%u\n", (unsigned int) tpmcmd->domid, tpmcmd->handle);
> +      goto end;
> +   }
> +
> +   /* Send response to frontend */
> +   send_response(tpmcmd, tpmif);
> +
> +end:
> +   if(tpmcmd->req != NULL) {
> +      free(tpmcmd->req);
> +   }
> +   free(tpmcmd);
> +   return;
> +}
> +
> +int tpmback_wait_for_frontend_connect(domid_t *domid, unsigned int *handle)
> +{
> +   tpmif_t* tpmif;
> +   int flags;
> +   wait_event(waitq, ((gtpmdev.num_tpms > 0) || gtpmdev.flags &
> TPMIF_CLOSED));
> +   if(gtpmdev.flags & TPMIF_CLOSED) {
> +      return -1;
> +   }
> +   local_irq_save(flags);
> +   tpmif = gtpmdev.tpmlist[0];
> +   *domid = tpmif->domid;
> +   *handle = tpmif->handle;
> +   local_irq_restore(flags);
> +
> +   return 0;
> +}
> +
> +int tpmback_num_frontends(void)
> +{
> +   return gtpmdev.num_tpms;
> +}
> diff --git a/extras/mini-os/tpmfront.c b/extras/mini-os/tpmfront.c
> --- /dev/null
> +++ b/extras/mini-os/tpmfront.c
> @@ -0,0 +1,606 @@
> +/*
> + * Copyright (c) 2010-2012 United States Government, as represented by
> + * the Secretary of Defense.  All rights reserved.
> + *
> + * This driver 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 3 of the License, or
> + * (at your option) any later version.
> + *
> + * This driver is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program.  If not, see <http://www.gnu.org/licenses/>.
> + *
> + * Based upon the files:
> + *  drivers/char/tpm/tpm_vtpm.c
> + *  drivers/char/tpm/tpm_xen.c
> + * from the Linux kernel, which are Copyright (C) 2006 IBM Corporation
> + */
> +#include <mini-os/os.h>
> +#include <mini-os/xenbus.h>
> +#include <mini-os/xmalloc.h>
> +#include <mini-os/events.h>
> +#include <mini-os/wait.h>
> +#include <mini-os/gnttab.h>
> +#include <xen/io/xenbus.h>
> +#include <xen/io/tpmif.h>
> +#include <mini-os/tpmfront.h>
> +#include <fcntl.h>
> +
> +//#define TPMFRONT_PRINT_DEBUG
> +#ifdef TPMFRONT_PRINT_DEBUG
> +#define TPMFRONT_DEBUG(fmt,...) printk("Tpmfront:Debug("__FILE__":%d) "
> fmt, __LINE__, ##__VA_ARGS__)
> +#define TPMFRONT_DEBUG_MORE(fmt,...) printk(fmt, ##__VA_ARGS__)
> +#else
> +#define TPMFRONT_DEBUG(fmt,...)
> +#endif
> +#define TPMFRONT_ERR(fmt,...) printk("Tpmfront:Error " fmt, ##__VA_ARGS__)
> +#define TPMFRONT_LOG(fmt,...) printk("Tpmfront:Info " fmt, ##__VA_ARGS__)
> +
> +#define min(a,b) (((a) < (b)) ? (a) : (b))
> +
> +void tpmfront_handler(evtchn_port_t port, struct pt_regs *regs, void
> *data) {
> +   struct tpmfront_dev* dev = (struct tpmfront_dev*) data;
> +   /*If we get a response when we didnt make a request, just ignore it */
> +   if(!dev->waiting) {
> +      return;
> +   }
> +
> +   dev->waiting = 0;
> +#ifdef HAVE_LIBC
> +   if(dev->fd >= 0) {
> +      files[dev->fd].read = 1;
> +   }
> +#endif
> +   wake_up(&dev->waitq);
> +}
> +
> +static int publish_xenbus(struct tpmfront_dev* dev) {
> +   xenbus_transaction_t xbt;
> +   int retry;
> +   char* err;
> +   /* Write the grant reference and event channel to xenstore */
> +again:
> +   if((err = xenbus_transaction_start(&xbt))) {
> +      TPMFRONT_ERR("Unable to start xenbus transaction, error was
> %s\n", err);
> +      free(err);
> +      return -1;
> +   }
> +
> +   if((err = xenbus_printf(xbt, dev->nodename, "ring-ref", "%u",
> (unsigned int) dev->ring_ref))) {
> +      TPMFRONT_ERR("Unable to write %s/ring-ref, error was %s\n",
> dev->nodename, err);
> +      free(err);
> +      goto abort_transaction;
> +   }
> +
> +   if((err = xenbus_printf(xbt, dev->nodename, "event-channel", "%u",
> (unsigned int) dev->evtchn))) {
> +      TPMFRONT_ERR("Unable to write %s/event-channel, error was %s\n",
> dev->nodename, err);
> +      free(err);
> +      goto abort_transaction;
> +   }
> +
> +   if((err = xenbus_transaction_end(xbt, 0, &retry))) {
> +      TPMFRONT_ERR("Unable to complete xenbus transaction, error was
> %s\n", err);
> +      free(err);
> +      return -1;
> +   }
> +   if(retry) {
> +      goto again;
> +   }
> +
> +   return 0;
> +abort_transaction:
> +   if((err = xenbus_transaction_end(xbt, 1, &retry))) {
> +      free(err);
> +   }
> +   return -1;
> +}
> +
> +static int wait_for_backend_connect(xenbus_event_queue* events, char* path)
> +{
> +   int state;
> +
> +   TPMFRONT_LOG("Waiting for backend connection..\n");
> +   /* Wait for the backend to connect */
> +   while(1) {
> +      state = xenbus_read_integer(path);
> +      if ( state < 0)
> +     state = XenbusStateUnknown;
> +      switch(state) {
> +     /* Bad states, we quit with error */
> +     case XenbusStateUnknown:
> +     case XenbusStateClosing:
> +     case XenbusStateClosed:
> +        TPMFRONT_ERR("Unable to connect to backend\n");
> +        return -1;
> +     /* If backend is connected then break out of loop */
> +     case XenbusStateConnected:
> +        TPMFRONT_LOG("Backend Connected\n");
> +        return 0;
> +     default:
> +        xenbus_wait_for_watch(events);
> +      }
> +   }
> +
> +}
> +
> +static int wait_for_backend_closed(xenbus_event_queue* events, char* path)
> +{
> +   int state;
> +
> +   TPMFRONT_LOG("Waiting for backend to close..\n");
> +   while(1) {
> +      state = xenbus_read_integer(path);
> +      if ( state < 0)
> +     state = XenbusStateUnknown;
> +      switch(state) {
> +     case XenbusStateUnknown:
> +        TPMFRONT_ERR("Backend Unknown state, forcing shutdown\n");
> +        return -1;
> +     case XenbusStateClosed:
> +        TPMFRONT_LOG("Backend Closed\n");
> +        return 0;
> +     default:
> +        xenbus_wait_for_watch(events);
> +      }
> +   }
> +
> +}
> +
> +static int wait_for_backend_state_changed(struct tpmfront_dev* dev,
> XenbusState state) {
> +   char* err;
> +   int ret = 0;
> +   xenbus_event_queue events = NULL;
> +   char path[512];
> +
> +   snprintf(path, 512, "%s/state", dev->bepath);
> +   /*Setup the watch to wait for the backend */
> +   if((err = xenbus_watch_path_token(XBT_NIL, path, path, &events))) {
> +      TPMFRONT_ERR("Could not set a watch on %s, error was %s\n", path,
> err);
> +      free(err);
> +      return -1;
> +   }
> +
> +   /* Do the actual wait loop now */
> +   switch(state) {
> +      case XenbusStateConnected:
> +     ret = wait_for_backend_connect(&events, path);
> +     break;
> +      case XenbusStateClosed:
> +     ret = wait_for_backend_closed(&events, path);
> +     break;
> +      default:
> +     break;
> +   }
> +
> +   if((err = xenbus_unwatch_path_token(XBT_NIL, path, path))) {
> +      TPMFRONT_ERR("Unable to unwatch %s, error was %s, ignoring..\n",
> path, err);
> +      free(err);
> +   }
> +   return ret;
> +}
> +
> +static int tpmfront_connect(struct tpmfront_dev* dev)
> +{
> +   char* err;
> +   /* Create shared page */
> +   dev->tx = (tpmif_tx_interface_t*) alloc_page();
> +   if(dev->tx == NULL) {
> +      TPMFRONT_ERR("Unable to allocate page for shared memory\n");
> +      goto error;
> +   }
> +   memset(dev->tx, 0, PAGE_SIZE);
> +   dev->ring_ref = gnttab_grant_access(dev->bedomid,
> virt_to_mfn(dev->tx), 0);
> +   TPMFRONT_DEBUG("grant ref is %lu\n", (unsigned long) dev->ring_ref);
> +
> +   /*Create event channel */
> +   if(evtchn_alloc_unbound(dev->bedomid, tpmfront_handler, dev,
> &dev->evtchn)) {
> +      TPMFRONT_ERR("Unable to allocate event channel\n");
> +      goto error_postmap;
> +   }
> +   unmask_evtchn(dev->evtchn);
> +   TPMFRONT_DEBUG("event channel is %lu\n", (unsigned long) dev->evtchn);
> +
> +   /* Write the entries to xenstore */
> +   if(publish_xenbus(dev)) {
> +      goto error_postevtchn;
> +   }
> +
> +   /* Change state to connected */
> +   dev->state = XenbusStateConnected;
> +
> +   /* Tell the backend that we are ready */
> +   if((err = xenbus_printf(XBT_NIL, dev->nodename, "state", "%u",
> dev->state))) {
> +      TPMFRONT_ERR("Unable to write to xenstore %s/state, value=%u",
> dev->nodename, XenbusStateConnected);
> +      free(err);
> +      goto error;
> +   }
> +
> +   return 0;
> +error_postevtchn:
> +      mask_evtchn(dev->evtchn);
> +      unbind_evtchn(dev->evtchn);
> +error_postmap:
> +      gnttab_end_access(dev->ring_ref);
> +      free_page(dev->tx);
> +error:
> +   return -1;
> +}
> +
> +struct tpmfront_dev* init_tpmfront(const char* _nodename)
> +{
> +   struct tpmfront_dev* dev;
> +   const char* nodename;
> +   char path[512];
> +   char* value, *err;
> +   unsigned long long ival;
> +   int i;
> +
> +   printk("============= Init TPM Front ================\n");
> +
> +   dev = malloc(sizeof(struct tpmfront_dev));
> +   memset(dev, 0, sizeof(struct tpmfront_dev));
> +
> +#ifdef HAVE_LIBC
> +   dev->fd = -1;
> +#endif
> +
> +   nodename = _nodename ? _nodename : "device/vtpm/0";
> +   dev->nodename = strdup(nodename);
> +
> +   init_waitqueue_head(&dev->waitq);
> +
> +   /* Get backend domid */
> +   snprintf(path, 512, "%s/backend-id", dev->nodename);
> +   if((err = xenbus_read(XBT_NIL, path, &value))) {
> +      TPMFRONT_ERR("Unable to read %s during tpmfront initialization!
> error = %s\n", path, err);
> +      free(err);
> +      goto error;
> +   }
> +   if(sscanf(value, "%llu", &ival) != 1) {
> +      TPMFRONT_ERR("%s has non-integer value (%s)\n", path, value);
> +      free(value);
> +      goto error;
> +   }
> +   free(value);
> +   dev->bedomid = ival;
> +
> +   /* Get backend xenstore path */
> +   snprintf(path, 512, "%s/backend", dev->nodename);
> +   if((err = xenbus_read(XBT_NIL, path, &dev->bepath))) {
> +      TPMFRONT_ERR("Unable to read %s during tpmfront initialization!
> error = %s\n", path, err);
> +      free(err);
> +      goto error;
> +   }
> +
> +   /* Create and publish grant reference and event channel */
> +   if (tpmfront_connect(dev)) {
> +      goto error;
> +   }
> +
> +   /* Wait for backend to connect */
> +   if( wait_for_backend_state_changed(dev, XenbusStateConnected)) {
> +      goto error;
> +   }
> +
> +   /* Allocate pages that will contain the messages */
> +   dev->pages = malloc(sizeof(void*) * TPMIF_TX_RING_SIZE);
> +   if(dev->pages == NULL) {
> +      goto error;
> +   }
> +   memset(dev->pages, 0, sizeof(void*) * TPMIF_TX_RING_SIZE);
> +   for(i = 0; i < TPMIF_TX_RING_SIZE; ++i) {
> +      dev->pages[i] = (void*)alloc_page();
> +      if(dev->pages[i] == NULL) {
> +     goto error;
> +      }
> +   }
> +
> +   TPMFRONT_LOG("Initialization Completed successfully\n");
> +
> +   return dev;
> +
> +error:
> +   shutdown_tpmfront(dev);
> +   return NULL;
> +}
> +void shutdown_tpmfront(struct tpmfront_dev* dev)
> +{
> +   char* err;
> +   char path[512];
> +   int i;
> +   tpmif_tx_request_t* tx;
> +   if(dev == NULL) {
> +      return;
> +   }
> +   TPMFRONT_LOG("Shutting down tpmfront\n");
> +   /* disconnect */
> +   if(dev->state == XenbusStateConnected) {
> +      dev->state = XenbusStateClosing;
> +      //FIXME: Transaction for this?
> +      /* Tell backend we are closing */
> +      if((err = xenbus_printf(XBT_NIL, dev->nodename, "state", "%u",
> (unsigned int) dev->state))) {
> +     free(err);
> +      }
> +
> +      /* Clean up xenstore entries */
> +      snprintf(path, 512, "%s/event-channel", dev->nodename);
> +      if((err = xenbus_rm(XBT_NIL, path))) {
> +     free(err);
> +      }
> +      snprintf(path, 512, "%s/ring-ref", dev->nodename);
> +      if((err = xenbus_rm(XBT_NIL, path))) {
> +     free(err);
> +      }
> +
> +      /* Tell backend we are closed */
> +      dev->state = XenbusStateClosed;
> +      if((err = xenbus_printf(XBT_NIL, dev->nodename, "state", "%u",
> (unsigned int) dev->state))) {
> +     TPMFRONT_ERR("Unable to write to %s, error was %s", dev->nodename,
> err);
> +     free(err);
> +      }
> +
> +      /* Wait for the backend to close and unmap shared pages, ignore
> any errors */
> +      wait_for_backend_state_changed(dev, XenbusStateClosed);
> +
> +      /* Cleanup any shared pages */
> +      if(dev->pages) {
> +     for(i = 0; i < TPMIF_TX_RING_SIZE; ++i) {
> +        if(dev->pages[i]) {
> +           tx = &dev->tx->ring[i].req;
> +           if(tx->ref != 0) {
> +          gnttab_end_access(tx->ref);
> +           }
> +           free_page(dev->pages[i]);
> +        }
> +     }
> +     free(dev->pages);
> +      }
> +
> +      /* Close event channel and unmap shared page */
> +      mask_evtchn(dev->evtchn);
> +      unbind_evtchn(dev->evtchn);
> +      gnttab_end_access(dev->ring_ref);
> +
> +      free_page(dev->tx);
> +
> +   }
> +
> +   /* Cleanup memory usage */
> +   if(dev->respbuf) {
> +      free(dev->respbuf);
> +   }
> +   if(dev->bepath) {
> +      free(dev->bepath);
> +   }
> +   if(dev->nodename) {
> +      free(dev->nodename);
> +   }
> +   free(dev);
> +}
> +
> +int tpmfront_send(struct tpmfront_dev* dev, const uint8_t* msg, size_t
> length)
> +{
> +   int i;
> +   tpmif_tx_request_t* tx = NULL;
> +   /* Error Checking */
> +   if(dev == NULL || dev->state != XenbusStateConnected) {
> +      TPMFRONT_ERR("Tried to send message through disconnected
> frontend\n");
> +      return -1;
> +   }
> +
> +#ifdef TPMFRONT_PRINT_DEBUG
> +   TPMFRONT_DEBUG("Sending Msg to backend size=%u", (unsigned int) length);
> +   for(i = 0; i < length; ++i) {
> +      if(!(i % 30)) {
> +     TPMFRONT_DEBUG_MORE("\n");
> +      }
> +      TPMFRONT_DEBUG_MORE("%02X ", msg[i]);
> +   }
> +   TPMFRONT_DEBUG_MORE("\n");
> +#endif
> +
> +   /* Copy to shared pages now */
> +   for(i = 0; length > 0 && i < TPMIF_TX_RING_SIZE; ++i) {
> +      /* Share the page */
> +      tx = &dev->tx->ring[i].req;
> +      tx->unused = 0;
> +      tx->addr = virt_to_mach(dev->pages[i]);
> +      tx->ref = gnttab_grant_access(dev->bedomid,
> virt_to_mfn(dev->pages[i]), 0);
> +      /* Copy the bits to the page */
> +      tx->size = length > PAGE_SIZE ? PAGE_SIZE : length;
> +      memcpy(dev->pages[i], &msg[i * PAGE_SIZE], tx->size);
> +
> +      /* Update counters */
> +      length -= tx->size;
> +   }
> +   dev->waiting = 1;
> +   dev->resplen = 0;
> +#ifdef HAVE_LIBC
> +   if(dev->fd >= 0) {
> +      files[dev->fd].read = 0;
> +      files[dev->fd].tpmfront.respgot = 0;
> +      files[dev->fd].tpmfront.offset = 0;
> +   }
> +#endif
> +   notify_remote_via_evtchn(dev->evtchn);
> +   return 0;
> +}
> +int tpmfront_recv(struct tpmfront_dev* dev, uint8_t** msg, size_t *length)
> +{
> +   tpmif_tx_request_t* tx;
> +   int i;
> +   if(dev == NULL || dev->state != XenbusStateConnected) {
> +      TPMFRONT_ERR("Tried to receive message from disconnected
> frontend\n");
> +      return -1;
> +   }
> +   /*Wait for the response */
> +   wait_event(dev->waitq, (!dev->waiting));
> +
> +   /* Initialize */
> +   *msg = NULL;
> +   *length = 0;
> +
> +   /* special case, just quit */
> +   tx = &dev->tx->ring[0].req;
> +   if(tx->size == 0 ) {
> +       goto quit;
> +   }
> +   /* Get the total size */
> +   tx = &dev->tx->ring[0].req;
> +   for(i = 0; i < TPMIF_TX_RING_SIZE && tx->size > 0; ++i) {
> +      tx = &dev->tx->ring[i].req;
> +      *length += tx->size;
> +   }
> +   /* Alloc the buffer */
> +   if(dev->respbuf) {
> +      free(dev->respbuf);
> +   }
> +   *msg = dev->respbuf = malloc(*length);
> +   dev->resplen = *length;
> +   /* Copy the bits */
> +   tx = &dev->tx->ring[0].req;
> +   for(i = 0; i < TPMIF_TX_RING_SIZE && tx->size > 0; ++i) {
> +      tx = &dev->tx->ring[i].req;
> +      memcpy(&(*msg)[i * PAGE_SIZE], dev->pages[i], tx->size);
> +      gnttab_end_access(tx->ref);
> +      tx->ref = 0;
> +   }
> +#ifdef TPMFRONT_PRINT_DEBUG
> +   TPMFRONT_DEBUG("Received response from backend size=%u", (unsigned
> int) *length);
> +   for(i = 0; i < *length; ++i) {
> +      if(!(i % 30)) {
> +     TPMFRONT_DEBUG_MORE("\n");
> +      }
> +      TPMFRONT_DEBUG_MORE("%02X ", (*msg)[i]);
> +   }
> +   TPMFRONT_DEBUG_MORE("\n");
> +#endif
> +#ifdef HAVE_LIBC
> +   if(dev->fd >= 0) {
> +      files[dev->fd].tpmfront.respgot = 1;
> +   }
> +#endif
> +quit:
> +   return 0;
> +}
> +
> +int tpmfront_cmd(struct tpmfront_dev* dev, uint8_t* req, size_t reqlen,
> uint8_t** resp, size_t* resplen)
> +{
> +   int rc;
> +   if((rc = tpmfront_send(dev, req, reqlen))) {
> +      return rc;
> +   }
> +   if((rc = tpmfront_recv(dev, resp, resplen))) {
> +      return rc;
> +   }
> +
> +   return 0;
> +}
> +
> +#ifdef HAVE_LIBC
> +#include <errno.h>
> +int tpmfront_open(struct tpmfront_dev* dev)
> +{
> +   /* Silently prevent multiple opens */
> +   if(dev->fd != -1) {
> +      return dev->fd;
> +   }
> +
> +   dev->fd = alloc_fd(FTYPE_TPMFRONT);
> +   printk("tpmfront_open(%s) -> %d\n", dev->nodename, dev->fd);
> +   files[dev->fd].tpmfront.dev = dev;
> +   files[dev->fd].tpmfront.offset = 0;
> +   files[dev->fd].tpmfront.respgot = 0;
> +   return dev->fd;
> +}
> +
> +int tpmfront_posix_write(int fd, const uint8_t* buf, size_t count)
> +{
> +   int rc;
> +   struct tpmfront_dev* dev;
> +   dev = files[fd].tpmfront.dev;
> +
> +   if(count == 0) {
> +      return 0;
> +   }
> +
> +   /* Return an error if we are already processing a command */
> +   if(dev->waiting) {
> +      errno = EINPROGRESS;
> +      return -1;
> +   }
> +   /* Send the command now */
> +   if((rc = tpmfront_send(dev, buf, count)) != 0) {
> +      errno = EIO;
> +      return -1;
> +   }
> +   return count;
> +}
> +
> +int tpmfront_posix_read(int fd, uint8_t* buf, size_t count)
> +{
> +   int rc;
> +   uint8_t* dummybuf;
> +   size_t dummysz;
> +   struct tpmfront_dev* dev;
> +
> +   dev = files[fd].tpmfront.dev;
> +
> +   if(count == 0) {
> +      return 0;
> +   }
> +
> +   /* get the response if we haven't already */
> +   if(files[dev->fd].tpmfront.respgot == 0) {
> +      if ((rc = tpmfront_recv(dev, &dummybuf, &dummysz)) != 0) {
> +     errno = EIO;
> +     return -1;
> +      }
> +   }
> +
> +   /* handle EOF case */
> +   if(files[dev->fd].tpmfront.offset >= dev->resplen) {
> +      return 0;
> +   }
> +
> +   /* Compute the number of bytes and do the copy operation */
> +   if((rc = min(count, dev->resplen - files[dev->fd].tpmfront.offset))
> != 0) {
> +      memcpy(buf, dev->respbuf + files[dev->fd].tpmfront.offset, rc);
> +      files[dev->fd].tpmfront.offset += rc;
> +   }
> +
> +   return rc;
> +}
> +
> +int tpmfront_posix_fstat(int fd, struct stat* buf)
> +{
> +   uint8_t* dummybuf;
> +   size_t dummysz;
> +   int rc;
> +   struct tpmfront_dev* dev = files[fd].tpmfront.dev;
> +
> +   /* If we have a response waiting, then read it now from the backend
> +    * so we can get its length*/
> +   if(dev->waiting || (files[dev->fd].read == 1 &&
> !files[dev->fd].tpmfront.respgot)) {
> +      if ((rc = tpmfront_recv(dev, &dummybuf, &dummysz)) != 0) {
> +     errno = EIO;
> +     return -1;
> +      }
> +   }
> +
> +   buf->st_mode = O_RDWR;
> +   buf->st_uid = 0;
> +   buf->st_gid = 0;
> +   buf->st_size = dev->resplen;
> +   buf->st_atime = buf->st_mtime = buf->st_ctime = time(NULL);
> +
> +   return 0;
> +}
> +
> +
> +#endif
> --
> 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 Wed Sep 26 13:25:39 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Sep 2012 13: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 1TGrcF-0004u4-JS; Wed, 26 Sep 2012 13:25:27 +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 1TGrcD-0004tw-Ou
	for xen-devel@lists.xensource.com; Wed, 26 Sep 2012 13:25:26 +0000
Received: from [85.158.143.35:38905] by server-1.bemta-4.messagelabs.com id
	09/71-05684-44203605; Wed, 26 Sep 2012 13:25:24 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1348665916!13148415!1
X-Originating-IP: [209.85.215.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26853 invoked from network); 26 Sep 2012 13:25:16 -0000
Received: from mail-ey0-f171.google.com (HELO mail-ey0-f171.google.com)
	(209.85.215.171)
	by server-11.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Sep 2012 13:25:16 -0000
Received: by eaah11 with SMTP id h11so236133eaa.30
	for <xen-devel@lists.xensource.com>;
	Wed, 26 Sep 2012 06:25: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;
	bh=dk9m5PtFDj7ztv8gOQAq8/T+UZJNR7vyvhdxffifN/I=;
	b=A6i3G7680A9N5Zy5BIEJzefkiiM0Hdo6XCASn17nbipPlHMGXplCZFic3YMq2XUmK/
	e+qvebbS01ttDZSjHnweBCq2+8awVhz13Ewn4XOoLg/AYYWQYbNhFqIQY9xuQHyBCl02
	ZEYv5bGL+NHr5mwMXQD/J6qIRwmtlGoyKRWko9G9Oin1nTqO7HRrVGXKx4Gjw0gWTm6J
	wWNNPK9PQrsVV4WOQhLOk/ujqx7tmnjA2GplVEV7mI4R/8maODLUuIbD2X7WGgLYN0a+
	EGGsOESgGjDwuhXF0G9JgwXC586PDYixMfhR/jSoR2lx19ciOx7/65HPQpvGxfnwh8bw
	Q8Lg==
MIME-Version: 1.0
Received: by 10.14.201.73 with SMTP id a49mr869489eeo.39.1348665916044; Wed,
	26 Sep 2012 06:25:16 -0700 (PDT)
Received: by 10.14.215.195 with HTTP; Wed, 26 Sep 2012 06:25:15 -0700 (PDT)
In-Reply-To: <50579F53.4070302@jhuapl.edu>
References: <50579F53.4070302@jhuapl.edu>
Date: Wed, 26 Sep 2012 14:25:15 +0100
X-Google-Sender-Auth: 2z5sgRSicICFu5ZTcCvSKLqmGAU
Message-ID: <CAFLBxZY+cCBXvT_F-M5b78cQ+Hp+xMeJeE5WGbP+igfWsiTy9w@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
Cc: Samuel Thibault <samuel.thibault@ens-lyon.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH mini-os enhancements for vtpm 8/8] Add 3 tpm
 drivers to mini-os
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Mon, Sep 17, 2012 at 11:08 PM, Matthew Fioravante
<matthew.fioravante@jhuapl.edu> wrote:
> This patch adds 3 new drivers to mini-os.
>
> tpmfront - paravirtualized tpm frontend driver
> tpmback - paravirtualized tpm backend driver
> tpm_tis - hardware tpm driver

Just trying to understand this -- tpmback is so that you can run a
vtpm instance in the stubdom.  But what is tmpfront for?  Is that for
running qemu stub domains?

 -George

>
> Unfortunately these drivers were derived from GPL licensed linux kernel
> drivers so they must carry the GPL license. However, since mini-os now
> supports conditional compilation, hopefully these drivers can be
> included into the xen tree and conditionally removed from non-gpl
> projects. By default they are disabled in the makefile.
>
> Signed off by: Matthew Fioravante matthew.fioravante@jhuapl.edu
>
> diff --git a/extras/mini-os/Makefile b/extras/mini-os/Makefile
> --- a/extras/mini-os/Makefile
> +++ b/extras/mini-os/Makefile
> @@ -22,6 +22,9 @@ CONFIG_QEMU_XS_ARGS ?= n
>  CONFIG_TEST ?= n
>  CONFIG_PCIFRONT ?= n
>  CONFIG_BLKFRONT ?= y
> +CONFIG_TPMFRONT ?= n
> +CONFIG_TPM_TIS ?= n
> +CONFIG_TPMBACK ?= n
>  CONFIG_NETFRONT ?= y
>  CONFIG_FBFRONT ?= y
>  CONFIG_KBDFRONT ?= y
> @@ -36,6 +39,9 @@ flags-$(CONFIG_SPARSE_BSS) += -DCONFIG_SPARSE_BSS
>  flags-$(CONFIG_QEMU_XS_ARGS) += -DCONFIG_QEMU_XS_ARGS
>  flags-$(CONFIG_PCIFRONT) += -DCONFIG_PCIFRONT
>  flags-$(CONFIG_BLKFRONT) += -DCONFIG_BLKFRONT
> +flags-$(CONFIG_TPMFRONT) += -DCONFIG_TPMFRONT
> +flags-$(CONFIG_TPM_TIS) += -DCONFIG_TPM_TIS
> +flags-$(CONFIG_TPMBACK) += -DCONFIG_TPMBACK
>  flags-$(CONFIG_NETFRONT) += -DCONFIG_NETFRONT
>  flags-$(CONFIG_KBDFRONT) += -DCONFIG_KBDFRONT
>  flags-$(CONFIG_FBFRONT) += -DCONFIG_FBFRONT
> @@ -67,6 +73,9 @@ TARGET := mini-os
>  SUBDIRS := lib xenbus console
>
>  src-$(CONFIG_BLKFRONT) += blkfront.c
> +src-$(CONFIG_TPMFRONT) += tpmfront.c
> +src-$(CONFIG_TPM_TIS) += tpm_tis.c
> +src-$(CONFIG_TPMBACK) += tpmback.c
>  src-y += daytime.c
>  src-y += events.c
>  src-$(CONFIG_FBFRONT) += fbfront.c
> diff --git a/extras/mini-os/include/lib.h b/extras/mini-os/include/lib.h
> --- a/extras/mini-os/include/lib.h
> +++ b/extras/mini-os/include/lib.h
> @@ -142,6 +142,8 @@ enum fd_type {
>      FTYPE_FB,
>      FTYPE_MEM,
>      FTYPE_SAVEFILE,
> +    FTYPE_TPMFRONT,
> +    FTYPE_TPM_TIS,
>  };
>
>  LIST_HEAD(evtchn_port_list, evtchn_port_info);
> @@ -185,6 +187,20 @@ extern struct file {
>      struct {
>          struct consfront_dev *dev;
>      } cons;
> +#ifdef CONFIG_TPMFRONT
> +    struct {
> +       struct tpmfront_dev *dev;
> +       int respgot;
> +       off_t offset;
> +    } tpmfront;
> +#endif
> +#ifdef CONFIG_TPM_TIS
> +    struct {
> +       struct tpm_chip *dev;
> +       int respgot;
> +       off_t offset;
> +    } tpm_tis;
> +#endif
>  #ifdef CONFIG_XENBUS
>          struct {
>              /* To each xenbus FD is associated a queue of watch events
> for this
> diff --git a/extras/mini-os/include/tpm_tis.h
> b/extras/mini-os/include/tpm_tis.h
> --- /dev/null
> +++ b/extras/mini-os/include/tpm_tis.h
> @@ -0,0 +1,63 @@
> +/*
> + * Copyright (c) 2010-2012 United States Government, as represented by
> + * the Secretary of Defense.  All rights reserved.
> + *
> + * This driver 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 3 of the License, or
> + * (at your option) any later version.
> + *
> + * This driver is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program.  If not, see <http://www.gnu.org/licenses/>.
> + *
> + * Based upon the files:
> + *  drivers/char/tpm/tpm_tis.c
> + *  drivers/char/tpm/tpm.c
> + * from the Linux kernel, which are Copyright (C) 2006 IBM Corporation
> + */
> +#ifndef TPM_TIS_H
> +#define TPM_TIS_H
> +
> +#include <mini-os/types.h>
> +#include <mini-os/byteorder.h>
> +
> +#define TPM_TIS_EN_LOCL0 1
> +#define TPM_TIS_EN_LOCL1 (1 << 1)
> +#define TPM_TIS_EN_LOCL2 (1 << 2)
> +#define TPM_TIS_EN_LOCL3 (1 << 3)
> +#define TPM_TIS_EN_LOCL4 (1 << 4)
> +#define TPM_TIS_EN_LOCLALL (TPM_TIS_EN_LOCL0 | TPM_TIS_EN_LOCL1  |
> TPM_TIS_EN_LOCL2 | TPM_TIS_EN_LOCL3 | TPM_TIS_EN_LOCL4)
> +#define TPM_TIS_LOCL_INT_TO_FLAG(x) (1 << x)
> +#define TPM_BASEADDR 0xFED40000
> +#define TPM_PROBE_IRQ 0xFFFF
> +
> +struct tpm_chip;
> +
> +struct tpm_chip* init_tpm_tis(unsigned long baseaddr, int localities,
> unsigned int irq);
> +void shutdown_tpm_tis(struct tpm_chip* tpm);
> +
> +int tpm_tis_request_locality(struct tpm_chip* tpm, int locality);
> +int tpm_tis_cmd(struct tpm_chip* tpm, uint8_t* req, size_t reqlen,
> uint8_t** resp, size_t* resplen);
> +
> +#ifdef HAVE_LIBC
> +#include <sys/stat.h>
> +#include <fcntl.h>
> +/* POSIX IO functions:
> + * use tpm_tis_open() to get a file descriptor to the tpm device
> + * use write() on the fd to send a command to the backend. You must
> + * include the entire command in a single call to write().
> + * use read() on the fd to read the response. You can use
> + * fstat() to get the size of the response and lseek() to seek on it.
> + */
> +int tpm_tis_open(struct tpm_chip* tpm);
> +int tpm_tis_posix_read(int fd, uint8_t* buf, size_t count);
> +int tpm_tis_posix_write(int fd, const uint8_t* buf, size_t count);
> +int tpm_tis_posix_fstat(int fd, struct stat* buf);
> +#endif
> +
> +#endif
> diff --git a/extras/mini-os/include/tpmback.h
> b/extras/mini-os/include/tpmback.h
> --- /dev/null
> +++ b/extras/mini-os/include/tpmback.h
> @@ -0,0 +1,95 @@
> +/*
> + * Copyright (c) 2010-2012 United States Government, as represented by
> + * the Secretary of Defense.  All rights reserved.
> + *
> + * This driver 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 3 of the License, or
> + * (at your option) any later version.
> + *
> + * This driver is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program.  If not, see <http://www.gnu.org/licenses/>.
> + *
> + * Based upon the files:
> + *  drivers/xen/tpmbk.c
> + * from the Linux kernel, which are Copyright (C) 2006 IBM Corporation
> + */
> +#include <xen/io/tpmif.h>
> +#include <xen/io/xenbus.h>
> +#include <mini-os/types.h>
> +#include <xen/xen.h>
> +#ifndef TPMBACK_H
> +#define TPMBACK_H
> +
> +struct tpmcmd {
> +   domid_t domid;        /* Domid of the frontend */
> +   unsigned int handle;    /* Handle of the frontend */
> +   char* uuid;            /* uuid of the tpm interface - allocated
> internally, dont free it */
> +
> +   unsigned int req_len;        /* Size of the command in buf - set by
> tpmback driver */
> +   uint8_t* req;            /* tpm command bits, allocated by driver,
> DON'T FREE IT */
> +   unsigned int resp_len;    /* Size of the outgoing command,
> +                   you set this before passing the cmd object to
> tpmback_resp */
> +   uint8_t* resp;        /* Buffer for response - YOU MUST ALLOCATE IT,
> YOU MUST ALSO FREE IT */
> +};
> +typedef struct tpmcmd tpmcmd_t;
> +
> +/* Initialize the tpm backend driver
> + * @exclusive_domname - This is NULL terminated list of vtpm uuid
> strings. If this list
> + *             is non-empty, then only frontend domains with vtpm
> uuid's matching
> + *             entries in this list will be allowed to connect.
> + *             Other connections will be immediatly closed.
> + *             Set this argument to NULL to allow any vtpm to connect.
> + */
> +void init_tpmback(char** exclusive_uuids);
> +/* Shutdown tpm backend driver */
> +void shutdown_tpmback(void);
> +
> +/* Blocks until a tpm command is sent from any front end.
> + * Returns a pointer to the tpm command to handle.
> + * Do not try to free this pointer or the req buffer
> + * This function will return NULL if the tpm backend driver
> + * is shutdown or any other error occurs */
> +tpmcmd_t* tpmback_req_any(void);
> +
> +/* Blocks until a tpm command from the frontend at domid/handle
> + * is sent.
> + * Returns NULL if domid/handle is not connected, tpmback is
> + * shutdown or shutting down, or if there is an error
> + */
> +tpmcmd_t* tpmback_req(domid_t domid, unsigned int handle);
> +
> +/* Send the response to the tpm command back to the frontend
> + * This function will free the tpmcmd object, but you must free the resp
> + * buffer yourself */
> +void tpmback_resp(tpmcmd_t* tpmcmd);
> +
> +/* Waits for the first frontend to connect and then sets domid and
> handle appropriately.
> + * If one or more frontends are already connected, this will set domid
> and handle to one
> + * of them arbitrarily. The main use for this function is to wait until
> a single
> + * frontend connection has occured.
> + * returns 0 on success, non-zero on failure */
> +int tpmback_wait_for_frontend_connect(domid_t *domid, unsigned int
> *handle);
> +
> +/* returns the number of frontends connected */
> +int tpmback_num_frontends(void);
> +
> +/* Returns the uuid of the specified frontend, NULL on error */
> +char* tpmback_get_uuid(domid_t domid, unsigned int handle);
> +
> +/* Specify a function to call when a new tpm device connects */
> +void tpmback_set_open_callback(void (*cb)(domid_t, unsigned int));
> +
> +/* Specify a function to call when a tpm device disconnects */
> +void tpmback_set_close_callback(void (*cb)(domid_t, unsigned int));
> +
> +//Not Implemented
> +void tpmback_set_suspend_callback(void (*cb)(domid_t, unsigned int));
> +void tpmback_set_resume_callback(void (*cb)(domid_t, unsigned int));
> +
> +#endif
> diff --git a/extras/mini-os/include/tpmfront.h
> b/extras/mini-os/include/tpmfront.h
> --- /dev/null
> +++ b/extras/mini-os/include/tpmfront.h
> @@ -0,0 +1,94 @@
> +/*
> + * Copyright (c) 2010-2012 United States Government, as represented by
> + * the Secretary of Defense.  All rights reserved.
> + *
> + * This driver 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 3 of the License, or
> + * (at your option) any later version.
> + *
> + * This driver is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program.  If not, see <http://www.gnu.org/licenses/>.
> + *
> + * Based upon the files:
> + *  drivers/char/tpm/tpm_vtpm.c
> + *  drivers/char/tpm/tpm_xen.c
> + * from the Linux kernel, which are Copyright (C) 2006 IBM Corporation
> + */
> +#ifndef TPMFRONT_H
> +#define TPMFRONT_H
> +
> +#include <mini-os/types.h>
> +#include <mini-os/os.h>
> +#include <mini-os/events.h>
> +#include <mini-os/wait.h>
> +#include <xen/xen.h>
> +#include <xen/io/xenbus.h>
> +#include <xen/io/tpmif.h>
> +
> +struct tpmfront_dev {
> +   grant_ref_t ring_ref;
> +   evtchn_port_t evtchn;
> +
> +   tpmif_tx_interface_t* tx;
> +
> +   void** pages;
> +
> +   domid_t bedomid;
> +   char* nodename;
> +   char* bepath;
> +
> +   XenbusState state;
> +
> +   uint8_t waiting;
> +   struct wait_queue_head waitq;
> +
> +   uint8_t* respbuf;
> +   size_t resplen;
> +
> +#ifdef HAVE_LIBC
> +   int fd;
> +#endif
> +
> +};
> +
> +
> +/*Initialize frontend */
> +struct tpmfront_dev* init_tpmfront(const char* nodename);
> +/*Shutdown frontend */
> +void shutdown_tpmfront(struct tpmfront_dev* dev);
> +
> +/* Send a tpm command to the backend and wait for the response
> + *
> + * @dev - frontend device
> + * @req - request buffer
> + * @reqlen - length of request buffer
> + * @resp - *resp will be set to internal response buffer, don't free
> it! Value is undefined on error
> + * @resplen - *resplen will be set to the length of the response. Value
> is undefined on error
> + *
> + * returns 0 on success, non zero on failure.
> + * */
> +int tpmfront_cmd(struct tpmfront_dev* dev, uint8_t* req, size_t reqlen,
> uint8_t** resp, size_t* resplen);
> +
> +#ifdef HAVE_LIBC
> +#include <sys/stat.h>
> +/* POSIX IO functions:
> + * use tpmfront_open() to get a file descriptor to the tpm device
> + * use write() on the fd to send a command to the backend. You must
> + * include the entire command in a single call to write().
> + * use read() on the fd to read the response. You can use
> + * fstat() to get the size of the response and lseek() to seek on it.
> + */
> +int tpmfront_open(struct tpmfront_dev* dev);
> +int tpmfront_posix_read(int fd, uint8_t* buf, size_t count);
> +int tpmfront_posix_write(int fd, const uint8_t* buf, size_t count);
> +int tpmfront_posix_fstat(int fd, struct stat* buf);
> +#endif
> +
> +
> +#endif
> diff --git a/extras/mini-os/lib/sys.c b/extras/mini-os/lib/sys.c
> --- a/extras/mini-os/lib/sys.c
> +++ b/extras/mini-os/lib/sys.c
> @@ -27,6 +27,8 @@
>  #include <netfront.h>
>  #include <blkfront.h>
>  #include <fbfront.h>
> +#include <tpmfront.h>
> +#include <tpm_tis.h>
>  #include <xenbus.h>
>  #include <xenstore.h>
>
> @@ -294,6 +296,16 @@ int read(int fd, void *buf, size_t nbytes)
>          return blkfront_posix_read(fd, buf, nbytes);
>          }
>  #endif
> +#ifdef CONFIG_TPMFRONT
> +        case FTYPE_TPMFRONT: {
> +        return tpmfront_posix_read(fd, buf, nbytes);
> +        }
> +#endif
> +#ifdef CONFIG_TPM_TIS
> +        case FTYPE_TPM_TIS: {
> +        return tpm_tis_posix_read(fd, buf, nbytes);
> +        }
> +#endif
>      default:
>          break;
>      }
> @@ -330,6 +342,14 @@ int write(int fd, const void *buf, size_t nbytes)
>      case FTYPE_BLK:
>          return blkfront_posix_write(fd, buf, nbytes);
>  #endif
> +#ifdef CONFIG_TPMFRONT
> +    case FTYPE_TPMFRONT:
> +        return tpmfront_posix_write(fd, buf, nbytes);
> +#endif
> +#ifdef CONFIG_TPM_TIS
> +    case FTYPE_TPM_TIS:
> +        return tpm_tis_posix_write(fd, buf, nbytes);
> +#endif
>      default:
>          break;
>      }
> @@ -341,8 +361,16 @@ int write(int fd, const void *buf, size_t nbytes)
>  off_t lseek(int fd, off_t offset, int whence)
>  {
>      switch(files[fd].type) {
> +#if defined(CONFIG_BLKFRONT) || defined(CONFIG_TPMFRONT) ||
> defined(CONFIG_TPM_TIS)
>  #ifdef CONFIG_BLKFRONT
>         case FTYPE_BLK:
> +#endif
> +#ifdef CONFIG_TPMFRNT
> +       case FTYPE_TPMFRONT:
> +#endif
> +#ifdef CONFIG_TPM_TIS
> +       case FTYPE_TPM_TIS:
> +#endif
>        switch (whence) {
>           case SEEK_SET:
>          files[fd].file.offset = offset;
> @@ -420,6 +448,18 @@ int close(int fd)
>          files[fd].type = FTYPE_NONE;
>          return 0;
>  #endif
> +#ifdef CONFIG_TPMFRONT
> +    case FTYPE_TPMFRONT:
> +            shutdown_tpmfront(files[fd].tpmfront.dev);
> +        files[fd].type = FTYPE_NONE;
> +        return 0;
> +#endif
> +#ifdef CONFIG_TPM_TIS
> +    case FTYPE_TPM_TIS:
> +            shutdown_tpm_tis(files[fd].tpm_tis.dev);
> +        files[fd].type = FTYPE_NONE;
> +        return 0;
> +#endif
>  #ifdef CONFIG_KBDFRONT
>      case FTYPE_KBD:
>              shutdown_kbdfront(files[fd].kbd.dev);
> @@ -489,6 +529,14 @@ int fstat(int fd, struct stat *buf)
>      case FTYPE_BLK:
>         return blkfront_posix_fstat(fd, buf);
>  #endif
> +#ifdef CONFIG_TPMFRONT
> +    case FTYPE_TPMFRONT:
> +       return tpmfront_posix_fstat(fd, buf);
> +#endif
> +#ifdef CONFIG_TPM_TIS
> +    case FTYPE_TPM_TIS:
> +       return tpm_tis_posix_fstat(fd, buf);
> +#endif
>      default:
>          break;
>      }
> diff --git a/extras/mini-os/tpm_tis.c b/extras/mini-os/tpm_tis.c
> --- /dev/null
> +++ b/extras/mini-os/tpm_tis.c
> @@ -0,0 +1,1344 @@
> +/*
> + * Copyright (c) 2010-2012 United States Government, as represented by
> + * the Secretary of Defense.  All rights reserved.
> + *
> + * This driver 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 3 of the License, or
> + * (at your option) any later version.
> + *
> + * This driver is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program.  If not, see <http://www.gnu.org/licenses/>.
> + *
> + * Based upon the files:
> + *  drivers/char/tpm/tpm_tis.c
> + *  drivers/char/tpm/tpm.c
> + * from the Linux kernel, which are Copyright (C) 2006 IBM Corporation
> + */
> +#include <mini-os/ioremap.h>
> +#include <mini-os/iorw.h>
> +#include <mini-os/tpm_tis.h>
> +#include <mini-os/os.h>
> +#include <mini-os/sched.h>
> +#include <mini-os/byteorder.h>
> +#include <mini-os/events.h>
> +#include <mini-os/wait.h>
> +#include <mini-os/xmalloc.h>
> +#include <errno.h>
> +#include <stdbool.h>
> +
> +#ifndef min
> +    #define min( a, b ) ( ((a) < (b)) ? (a) : (b) )
> +#endif
> +
> +#define TPM_HEADER_SIZE 10
> +
> +#define TPM_BUFSIZE 2048
> +
> +struct tpm_input_header {
> +        uint16_t  tag;
> +        uint32_t  length;
> +        uint32_t  ordinal;
> +}__attribute__((packed));
> +
> +struct tpm_output_header {
> +        uint16_t  tag;
> +        uint32_t  length;
> +        uint32_t  return_code;
> +}__attribute__((packed));
> +
> +struct  stclear_flags_t {
> +        uint16_t  tag;
> +        uint8_t      deactivated;
> +        uint8_t      disableForceClear;
> +        uint8_t      physicalPresence;
> +        uint8_t      physicalPresenceLock;
> +        uint8_t      bGlobalLock;
> +}__attribute__((packed));
> +
> +struct  tpm_version_t {
> +        uint8_t      Major;
> +        uint8_t      Minor;
> +        uint8_t      revMajor;
> +        uint8_t      revMinor;
> +}__attribute__((packed));
> +
> +struct  tpm_version_1_2_t {
> +        uint16_t  tag;
> +        uint8_t      Major;
> +        uint8_t      Minor;
> +        uint8_t      revMajor;
> +        uint8_t      revMinor;
> +}__attribute__((packed));
> +
> +struct  timeout_t {
> +        uint32_t  a;
> +        uint32_t  b;
> +        uint32_t  c;
> +        uint32_t  d;
> +}__attribute__((packed));
> +
> +struct duration_t {
> +        uint32_t  tpm_short;
> +        uint32_t  tpm_medium;
> +        uint32_t  tpm_long;
> +}__attribute__((packed));
> +
> +struct permanent_flags_t {
> +        uint16_t  tag;
> +        uint8_t      disable;
> +        uint8_t      ownership;
> +        uint8_t      deactivated;
> +        uint8_t      readPubek;
> +        uint8_t      disableOwnerClear;
> +        uint8_t      allowMaintenance;
> +        uint8_t      physicalPresenceLifetimeLock;
> +        uint8_t      physicalPresenceHWEnable;
> +        uint8_t      physicalPresenceCMDEnable;
> +        uint8_t      CEKPUsed;
> +        uint8_t      TPMpost;
> +        uint8_t      TPMpostLock;
> +        uint8_t      FIPS;
> +        uint8_t      operator;
> +        uint8_t      enableRevokeEK;
> +        uint8_t      nvLocked;
> +        uint8_t      readSRKPub;
> +        uint8_t      tpmEstablished;
> +        uint8_t      maintenanceDone;
> +        uint8_t      disableFullDALogicInfo;
> +}__attribute__((packed));
> +
> +typedef union {
> +        struct  permanent_flags_t perm_flags;
> +        struct  stclear_flags_t stclear_flags;
> +        bool    owned;
> +        uint32_t  num_pcrs;
> +        struct  tpm_version_t   tpm_version;
> +        struct  tpm_version_1_2_t tpm_version_1_2;
> +        uint32_t  manufacturer_id;
> +        struct timeout_t  timeout;
> +        struct duration_t duration;
> +} cap_t;
> +
> +struct  tpm_getcap_params_in {
> +        uint32_t  cap;
> +        uint32_t  subcap_size;
> +        uint32_t  subcap;
> +}__attribute__((packed));
> +
> +struct  tpm_getcap_params_out {
> +        uint32_t  cap_size;
> +        cap_t   cap;
> +}__attribute__((packed));
> +
> +struct  tpm_readpubek_params_out {
> +        uint8_t      algorithm[4];
> +        uint8_t      encscheme[2];
> +        uint8_t      sigscheme[2];
> +        uint32_t  paramsize;
> +        uint8_t      parameters[12]; /*assuming RSA*/
> +        uint32_t  keysize;
> +        uint8_t      modulus[256];
> +        uint8_t      checksum[20];
> +}__attribute__((packed));
> +
> +typedef union {
> +        struct  tpm_input_header in;
> +        struct  tpm_output_header out;
> +} tpm_cmd_header;
> +
> +#define TPM_DIGEST_SIZE 20
> +struct tpm_pcrread_out {
> +        uint8_t      pcr_result[TPM_DIGEST_SIZE];
> +}__attribute__((packed));
> +
> +struct tpm_pcrread_in {
> +        uint32_t  pcr_idx;
> +}__attribute__((packed));
> +
> +struct tpm_pcrextend_in {
> +        uint32_t  pcr_idx;
> +        uint8_t      hash[TPM_DIGEST_SIZE];
> +}__attribute__((packed));
> +
> +typedef union {
> +        struct  tpm_getcap_params_out getcap_out;
> +        struct  tpm_readpubek_params_out readpubek_out;
> +        uint8_t      readpubek_out_buffer[sizeof(struct
> tpm_readpubek_params_out)];
> +        struct  tpm_getcap_params_in getcap_in;
> +        struct  tpm_pcrread_in  pcrread_in;
> +        struct  tpm_pcrread_out pcrread_out;
> +        struct  tpm_pcrextend_in pcrextend_in;
> +} tpm_cmd_params;
> +
> +struct tpm_cmd_t {
> +        tpm_cmd_header  header;
> +        tpm_cmd_params  params;
> +}__attribute__((packed));
> +
> +
> +enum tpm_duration {
> +   TPM_SHORT = 0,
> +   TPM_MEDIUM = 1,
> +   TPM_LONG = 2,
> +   TPM_UNDEFINED,
> +};
> +
> +#define TPM_MAX_ORDINAL 243
> +#define TPM_MAX_PROTECTED_ORDINAL 12
> +#define TPM_PROTECTED_ORDINAL_MASK 0xFF
> +
> +extern const uint8_t
> tpm_protected_ordinal_duration[TPM_MAX_PROTECTED_ORDINAL];
> +extern const uint8_t tpm_ordinal_duration[TPM_MAX_ORDINAL];
> +
> +#define TPM_DIGEST_SIZE 20
> +#define TPM_ERROR_SIZE 10
> +#define TPM_RET_CODE_IDX 6
> +
> +/* tpm_capabilities */
> +#define TPM_CAP_FLAG cpu_to_be32(4)
> +#define TPM_CAP_PROP cpu_to_be32(5)
> +#define CAP_VERSION_1_1 cpu_to_be32(0x06)
> +#define CAP_VERSION_1_2 cpu_to_be32(0x1A)
> +
> +/* tpm_sub_capabilities */
> +#define TPM_CAP_PROP_PCR cpu_to_be32(0x101)
> +#define TPM_CAP_PROP_MANUFACTURER cpu_to_be32(0x103)
> +#define TPM_CAP_FLAG_PERM cpu_to_be32(0x108)
> +#define TPM_CAP_FLAG_VOL cpu_to_be32(0x109)
> +#define TPM_CAP_PROP_OWNER cpu_to_be32(0x111)
> +#define TPM_CAP_PROP_TIS_TIMEOUT cpu_to_be32(0x115)
> +#define TPM_CAP_PROP_TIS_DURATION cpu_to_be32(0x120)
> +
> +
> +#define TPM_INTERNAL_RESULT_SIZE 200
> +#define TPM_TAG_RQU_COMMAND cpu_to_be16(193)
> +#define TPM_ORD_GET_CAP cpu_to_be32(101)
> +
> +extern const struct tpm_input_header tpm_getcap_header;
> +
> +
> +
> +const uint8_t tpm_protected_ordinal_duration[TPM_MAX_PROTECTED_ORDINAL] = {
> +   TPM_UNDEFINED,          /* 0 */
> +   TPM_UNDEFINED,
> +   TPM_UNDEFINED,
> +   TPM_UNDEFINED,
> +   TPM_UNDEFINED,
> +   TPM_UNDEFINED,          /* 5 */
> +   TPM_UNDEFINED,
> +   TPM_UNDEFINED,
> +   TPM_UNDEFINED,
> +   TPM_UNDEFINED,
> +   TPM_SHORT,              /* 10 */
> +   TPM_SHORT,
> +};
> +
> +const uint8_t tpm_ordinal_duration[TPM_MAX_ORDINAL] = {
> +   TPM_UNDEFINED,          /* 0 */
> +   TPM_UNDEFINED,
> +   TPM_UNDEFINED,
> +   TPM_UNDEFINED,
> +   TPM_UNDEFINED,
> +   TPM_UNDEFINED,          /* 5 */
> +   TPM_UNDEFINED,
> +   TPM_UNDEFINED,
> +   TPM_UNDEFINED,
> +   TPM_UNDEFINED,
> +   TPM_SHORT,              /* 10 */
> +   TPM_SHORT,
> +   TPM_MEDIUM,
> +   TPM_LONG,
> +   TPM_LONG,
> +   TPM_MEDIUM,             /* 15 */
> +   TPM_SHORT,
> +   TPM_SHORT,
> +   TPM_MEDIUM,
> +   TPM_LONG,
> +   TPM_SHORT,              /* 20 */
> +   TPM_SHORT,
> +   TPM_MEDIUM,
> +   TPM_MEDIUM,
> +   TPM_MEDIUM,
> +   TPM_SHORT,              /* 25 */
> +   TPM_SHORT,
> +   TPM_MEDIUM,
> +   TPM_SHORT,
> +   TPM_SHORT,
> +   TPM_MEDIUM,             /* 30 */
> +   TPM_LONG,
> +   TPM_MEDIUM,
> +   TPM_SHORT,
> +   TPM_SHORT,
> +   TPM_SHORT,              /* 35 */
> +   TPM_MEDIUM,
> +   TPM_MEDIUM,
> +   TPM_UNDEFINED,
> +   TPM_UNDEFINED,
> +   TPM_MEDIUM,             /* 40 */
> +   TPM_LONG,
> +   TPM_MEDIUM,
> +   TPM_SHORT,
> +   TPM_SHORT,
> +   TPM_SHORT,              /* 45 */
> +   TPM_SHORT,
> +   TPM_SHORT,
> +   TPM_SHORT,
> +   TPM_LONG,
> +   TPM_MEDIUM,             /* 50 */
> +   TPM_MEDIUM,
> +   TPM_UNDEFINED,
> +   TPM_UNDEFINED,
> +   TPM_UNDEFINED,
> +   TPM_UNDEFINED,          /* 55 */
> +   TPM_UNDEFINED,
> +   TPM_UNDEFINED,
> +   TPM_UNDEFINED,
> +   TPM_UNDEFINED,
> +   TPM_MEDIUM,             /* 60 */
> +   TPM_MEDIUM,
> +   TPM_MEDIUM,
> +   TPM_SHORT,
> +   TPM_SHORT,
> +   TPM_MEDIUM,             /* 65 */
> +   TPM_UNDEFINED,
> +   TPM_UNDEFINED,
> +   TPM_UNDEFINED,
> +   TPM_UNDEFINED,
> +   TPM_SHORT,              /* 70 */
> +   TPM_SHORT,
> +   TPM_UNDEFINED,
> +   TPM_UNDEFINED,
> +   TPM_UNDEFINED,
> +   TPM_UNDEFINED,          /* 75 */
> +   TPM_UNDEFINED,
> +   TPM_UNDEFINED,
> +   TPM_UNDEFINED,
> +   TPM_UNDEFINED,
> +   TPM_LONG,               /* 80 */
> +   TPM_UNDEFINED,
> +   TPM_MEDIUM,
> +   TPM_LONG,
> +   TPM_SHORT,
> +   TPM_UNDEFINED,          /* 85 */
> +   TPM_UNDEFINED,
> +   TPM_UNDEFINED,
> +   TPM_UNDEFINED,
> +   TPM_UNDEFINED,
> +   TPM_SHORT,              /* 90 */
> +   TPM_SHORT,
> +   TPM_SHORT,
> +   TPM_SHORT,
> +   TPM_SHORT,
> +   TPM_UNDEFINED,          /* 95 */
> +   TPM_UNDEFINED,
> +   TPM_UNDEFINED,
> +   TPM_UNDEFINED,
> +   TPM_UNDEFINED,
> +   TPM_MEDIUM,             /* 100 */
> +   TPM_SHORT,
> +   TPM_SHORT,
> +   TPM_UNDEFINED,
> +   TPM_UNDEFINED,
> +   TPM_UNDEFINED,          /* 105 */
> +   TPM_UNDEFINED,
> +   TPM_UNDEFINED,
> +   TPM_UNDEFINED,
> +   TPM_UNDEFINED,
> +   TPM_SHORT,              /* 110 */
> +   TPM_SHORT,
> +   TPM_SHORT,
> +   TPM_SHORT,
> +   TPM_SHORT,
> +   TPM_SHORT,              /* 115 */
> +   TPM_SHORT,
> +   TPM_SHORT,
> +   TPM_UNDEFINED,
> +   TPM_UNDEFINED,
> +   TPM_LONG,               /* 120 */
> +   TPM_LONG,
> +   TPM_MEDIUM,
> +   TPM_UNDEFINED,
> +   TPM_SHORT,
> +   TPM_SHORT,              /* 125 */
> +   TPM_SHORT,
> +   TPM_LONG,
> +   TPM_SHORT,
> +   TPM_SHORT,
> +   TPM_SHORT,              /* 130 */
> +   TPM_MEDIUM,
> +   TPM_UNDEFINED,
> +   TPM_SHORT,
> +   TPM_MEDIUM,
> +   TPM_UNDEFINED,          /* 135 */
> +   TPM_UNDEFINED,
> +   TPM_UNDEFINED,
> +   TPM_UNDEFINED,
> +   TPM_UNDEFINED,
> +   TPM_SHORT,              /* 140 */
> +   TPM_SHORT,
> +   TPM_UNDEFINED,
> +   TPM_UNDEFINED,
> +   TPM_UNDEFINED,
> +   TPM_UNDEFINED,          /* 145 */
> +   TPM_UNDEFINED,
> +   TPM_UNDEFINED,
> +   TPM_UNDEFINED,
> +   TPM_UNDEFINED,
> +   TPM_SHORT,              /* 150 */
> +   TPM_MEDIUM,
> +   TPM_MEDIUM,
> +   TPM_SHORT,
> +   TPM_SHORT,
> +   TPM_UNDEFINED,          /* 155 */
> +   TPM_UNDEFINED,
> +   TPM_UNDEFINED,
> +   TPM_UNDEFINED,
> +   TPM_UNDEFINED,
> +   TPM_SHORT,              /* 160 */
> +   TPM_SHORT,
> +   TPM_SHORT,
> +   TPM_SHORT,
> +   TPM_UNDEFINED,
> +   TPM_UNDEFINED,          /* 165 */
> +   TPM_UNDEFINED,
> +   TPM_UNDEFINED,
> +   TPM_UNDEFINED,
> +   TPM_UNDEFINED,
> +   TPM_LONG,               /* 170 */
> +   TPM_UNDEFINED,
> +   TPM_UNDEFINED,
> +   TPM_UNDEFINED,
> +   TPM_UNDEFINED,
> +   TPM_UNDEFINED,          /* 175 */
> +   TPM_UNDEFINED,
> +   TPM_UNDEFINED,
> +   TPM_UNDEFINED,
> +   TPM_UNDEFINED,
> +   TPM_MEDIUM,             /* 180 */
> +   TPM_SHORT,
> +   TPM_MEDIUM,
> +   TPM_MEDIUM,
> +   TPM_MEDIUM,
> +   TPM_MEDIUM,             /* 185 */
> +   TPM_SHORT,
> +   TPM_UNDEFINED,
> +   TPM_UNDEFINED,
> +   TPM_UNDEFINED,
> +   TPM_UNDEFINED,          /* 190 */
> +   TPM_UNDEFINED,
> +   TPM_UNDEFINED,
> +   TPM_UNDEFINED,
> +   TPM_UNDEFINED,
> +   TPM_UNDEFINED,          /* 195 */
> +   TPM_UNDEFINED,
> +   TPM_UNDEFINED,
> +   TPM_UNDEFINED,
> +   TPM_UNDEFINED,
> +   TPM_SHORT,              /* 200 */
> +   TPM_UNDEFINED,
> +   TPM_UNDEFINED,
> +   TPM_UNDEFINED,
> +   TPM_SHORT,
> +   TPM_SHORT,              /* 205 */
> +   TPM_SHORT,
> +   TPM_SHORT,
> +   TPM_SHORT,
> +   TPM_SHORT,
> +   TPM_MEDIUM,             /* 210 */
> +   TPM_UNDEFINED,
> +   TPM_MEDIUM,
> +   TPM_MEDIUM,
> +   TPM_MEDIUM,
> +   TPM_UNDEFINED,          /* 215 */
> +   TPM_MEDIUM,
> +   TPM_UNDEFINED,
> +   TPM_UNDEFINED,
> +   TPM_SHORT,
> +   TPM_SHORT,              /* 220 */
> +   TPM_SHORT,
> +   TPM_SHORT,
> +   TPM_SHORT,
> +   TPM_SHORT,
> +   TPM_UNDEFINED,          /* 225 */
> +   TPM_UNDEFINED,
> +   TPM_UNDEFINED,
> +   TPM_UNDEFINED,
> +   TPM_UNDEFINED,
> +   TPM_SHORT,              /* 230 */
> +   TPM_LONG,
> +   TPM_MEDIUM,
> +   TPM_UNDEFINED,
> +   TPM_UNDEFINED,
> +   TPM_UNDEFINED,          /* 235 */
> +   TPM_UNDEFINED,
> +   TPM_UNDEFINED,
> +   TPM_UNDEFINED,
> +   TPM_UNDEFINED,
> +   TPM_SHORT,              /* 240 */
> +   TPM_UNDEFINED,
> +   TPM_MEDIUM,
> +};
> +
> +const struct tpm_input_header tpm_getcap_header = {
> +        .tag = TPM_TAG_RQU_COMMAND,
> +        .length = cpu_to_be32(22),
> +        .ordinal = TPM_ORD_GET_CAP
> +};
> +
> +
> +enum tis_access {
> +   TPM_ACCESS_VALID = 0x80,
> +   TPM_ACCESS_ACTIVE_LOCALITY = 0x20,    /* (R) */
> +   TPM_ACCESS_RELINQUISH_LOCALITY = 0x20,/* (W) */
> +   TPM_ACCESS_REQUEST_PENDING = 0x04,    /* (W) */
> +   TPM_ACCESS_REQUEST_USE = 0x02,    /* (W) */
> +};
> +
> +enum tis_status {
> +   TPM_STS_VALID = 0x80,        /* (R) */
> +   TPM_STS_COMMAND_READY = 0x40,    /* (R) */
> +   TPM_STS_DATA_AVAIL = 0x10,        /* (R) */
> +   TPM_STS_DATA_EXPECT = 0x08,        /* (R) */
> +   TPM_STS_GO = 0x20,            /* (W) */
> +};
> +
> +enum tis_int_flags {
> +   TPM_GLOBAL_INT_ENABLE = 0x80000000,
> +   TPM_INTF_BURST_COUNT_STATIC = 0x100,
> +   TPM_INTF_CMD_READY_INT = 0x080,
> +   TPM_INTF_INT_EDGE_FALLING = 0x040,
> +   TPM_INTF_INT_EDGE_RISING = 0x020,
> +   TPM_INTF_INT_LEVEL_LOW = 0x010,
> +   TPM_INTF_INT_LEVEL_HIGH = 0x008,
> +   TPM_INTF_LOCALITY_CHANGE_INT = 0x004,
> +   TPM_INTF_STS_VALID_INT = 0x002,
> +   TPM_INTF_DATA_AVAIL_INT = 0x001,
> +};
> +
> +enum tis_defaults {
> +   TIS_MEM_BASE = 0xFED40000,
> +   TIS_MEM_LEN  = 0x5000,
> +   TIS_SHORT_TIMEOUT = 750, /*ms*/
> +   TIS_LONG_TIMEOUT = 2000, /*2 sec */
> +};
> +
> +#define TPM_TIMEOUT 5
> +
> +#define TPM_ACCESS(t, l)                   (((uint8_t*)t->pages[l]) +
> 0x0000)
> +#define TPM_INT_ENABLE(t, l)
> ((uint32_t*)(((uint8_t*)t->pages[l]) + 0x0008))
> +#define TPM_INT_VECTOR(t, l)               (((uint8_t*)t->pages[l]) +
> 0x000C)
> +#define TPM_INT_STATUS(t, l)               (((uint8_t*)t->pages[l]) +
> 0x0010)
> +#define TPM_INTF_CAPS(t, l)
> ((uint32_t*)(((uint8_t*)t->pages[l]) + 0x0014))
> +#define TPM_STS(t, l)
> ((uint8_t*)(((uint8_t*)t->pages[l]) + 0x0018))
> +#define TPM_DATA_FIFO(t, l)                (((uint8_t*)t->pages[l]) +
> 0x0024)
> +
> +#define TPM_DID_VID(t, l)
> ((uint32_t*)(((uint8_t*)t->pages[l]) + 0x0F00))
> +#define TPM_RID(t, l)                      (((uint8_t*)t->pages[l]) +
> 0x0F04)
> +
> +struct tpm_chip {
> +   int enabled_localities;
> +   int locality;
> +   unsigned long baseaddr;
> +   uint8_t* pages[5];
> +   int did, vid, rid;
> +
> +   uint8_t data_buffer[TPM_BUFSIZE];
> +   int data_len;
> +
> +   s_time_t timeout_a, timeout_b, timeout_c, timeout_d;
> +   s_time_t duration[3];
> +
> +#ifdef HAVE_LIBC
> +   int fd;
> +#endif
> +
> +   unsigned int irq;
> +   struct wait_queue_head read_queue;
> +   struct wait_queue_head int_queue;
> +};
> +
> +
> +static void __init_tpm_chip(struct tpm_chip* tpm) {
> +   tpm->enabled_localities = TPM_TIS_EN_LOCLALL;
> +   tpm->locality = -1;
> +   tpm->baseaddr = 0;
> +   tpm->pages[0] = tpm->pages[1] = tpm->pages[2] = tpm->pages[3] =
> tpm->pages[4] = NULL;
> +   tpm->vid = 0;
> +   tpm->did = 0;
> +   tpm->irq = 0;
> +   init_waitqueue_head(&tpm->read_queue);
> +   init_waitqueue_head(&tpm->int_queue);
> +
> +   tpm->data_len = -1;
> +
> +#ifdef HAVE_LIBC
> +   tpm->fd = -1;
> +#endif
> +}
> +
> +/*
> + * Returns max number of nsecs to wait
> + */
> +s_time_t tpm_calc_ordinal_duration(struct tpm_chip *chip,
> +      uint32_t ordinal)
> +{
> +   int duration_idx = TPM_UNDEFINED;
> +   s_time_t duration = 0;
> +
> +   if (ordinal < TPM_MAX_ORDINAL)
> +      duration_idx = tpm_ordinal_duration[ordinal];
> +   else if ((ordinal & TPM_PROTECTED_ORDINAL_MASK) <
> +     TPM_MAX_PROTECTED_ORDINAL)
> +      duration_idx =
> +     tpm_protected_ordinal_duration[ordinal &
> +     TPM_PROTECTED_ORDINAL_MASK];
> +
> +   if (duration_idx != TPM_UNDEFINED) {
> +      duration = chip->duration[duration_idx];
> +   }
> +
> +   if (duration <= 0) {
> +      return SECONDS(120);
> +   }
> +   else
> +   {
> +      return duration;
> +   }
> +}
> +
> +
> +static int locality_enabled(struct tpm_chip* tpm, int l) {
> +   return tpm->enabled_localities & (1 << l);
> +}
> +
> +static int check_locality(struct tpm_chip* tpm, int l) {
> +   if(locality_enabled(tpm, l) && (ioread8(TPM_ACCESS(tpm, l)) &
> +        (TPM_ACCESS_ACTIVE_LOCALITY | TPM_ACCESS_VALID)) ==
> +     (TPM_ACCESS_ACTIVE_LOCALITY | TPM_ACCESS_VALID)) {
> +      return l;
> +   }
> +   return -1;
> +}
> +
> +void release_locality(struct tpm_chip* tpm, int l, int force)
> +{
> +   if (locality_enabled(tpm, l) && (force || (ioread8(TPM_ACCESS(tpm, l)) &
> +           (TPM_ACCESS_REQUEST_PENDING | TPM_ACCESS_VALID)) ==
> +        (TPM_ACCESS_REQUEST_PENDING | TPM_ACCESS_VALID))) {
> +      iowrite8(TPM_ACCESS(tpm, l), TPM_ACCESS_RELINQUISH_LOCALITY);
> +   }
> +}
> +
> +int tpm_tis_request_locality(struct tpm_chip* tpm, int l) {
> +
> +   s_time_t stop;
> +   /*Make sure locality is valid */
> +   if(!locality_enabled(tpm, l)) {
> +      printk("tpm_tis_change_locality() Tried to change to locality %d,
> but it is disabled or invalid!\n", l);
> +      return -1;
> +   }
> +   /* Check if we already have the current locality */
> +   if(check_locality(tpm, l) >= 0) {
> +      return tpm->locality = l;
> +   }
> +   /* Set the new locality*/
> +   iowrite8(TPM_ACCESS(tpm, l), TPM_ACCESS_REQUEST_USE);
> +
> +   if(tpm->irq) {
> +      /* Wait for interrupt */
> +      wait_event_deadline(tpm->int_queue, (check_locality(tpm, l) >=
> 0), NOW() + tpm->timeout_a);
> +
> +      /* FIXME: Handle timeout event, should return error in that case */
> +      return l;
> +   } else {
> +      /* Wait for burstcount */
> +      stop = NOW() + tpm->timeout_a;
> +      do {
> +     if(check_locality(tpm, l) >= 0) {
> +        return tpm->locality = l;
> +     }
> +     msleep(TPM_TIMEOUT);
> +      } while(NOW() < stop);
> +   }
> +
> +   printk("REQ LOCALITY FAILURE\n");
> +   return -1;
> +}
> +
> +static uint8_t tpm_tis_status(struct tpm_chip* tpm) {
> +   return ioread8(TPM_STS(tpm, tpm->locality));
> +}
> +
> +/* This causes the current command to be aborted */
> +static void tpm_tis_ready(struct tpm_chip* tpm) {
> +   iowrite8(TPM_STS(tpm, tpm->locality), TPM_STS_COMMAND_READY);
> +}
> +#define tpm_tis_cancel_cmd(v) tpm_tis_ready(v)
> +
> +static int get_burstcount(struct tpm_chip* tpm) {
> +   s_time_t stop;
> +   int burstcnt;
> +
> +   stop = NOW() + tpm->timeout_d;
> +   do {
> +      burstcnt = ioread8((TPM_STS(tpm, tpm->locality) + 1));
> +      burstcnt += ioread8(TPM_STS(tpm, tpm->locality) + 2) << 8;
> +
> +      if (burstcnt) {
> +     return burstcnt;
> +      }
> +      msleep(TPM_TIMEOUT);
> +   } while(NOW() < stop);
> +   return -EBUSY;
> +}
> +
> +static int wait_for_stat(struct tpm_chip* tpm, uint8_t mask,
> +      unsigned long timeout, struct wait_queue_head* queue) {
> +   s_time_t stop;
> +   uint8_t status;
> +
> +   status = tpm_tis_status(tpm);
> +   if((status & mask) == mask) {
> +      return 0;
> +   }
> +
> +   if(tpm->irq) {
> +      wait_event_deadline(*queue, ((tpm_tis_status(tpm) & mask) ==
> mask), timeout);
> +      /* FIXME: Check for timeout and return -ETIME */
> +      return 0;
> +   } else {
> +      stop = NOW() + timeout;
> +      do {
> +     msleep(TPM_TIMEOUT);
> +     status = tpm_tis_status(tpm);
> +     if((status & mask) == mask)
> +        return 0;
> +      } while( NOW() < stop);
> +   }
> +   return -ETIME;
> +}
> +
> +static int recv_data(struct tpm_chip* tpm, uint8_t* buf, size_t count) {
> +   int size = 0;
> +   int burstcnt;
> +   while( size < count &&
> +     wait_for_stat(tpm,
> +        TPM_STS_DATA_AVAIL | TPM_STS_VALID,
> +        tpm->timeout_c,
> +        &tpm->read_queue)
> +     == 0) {
> +      burstcnt = get_burstcount(tpm);
> +      for(; burstcnt > 0 && size < count; --burstcnt)
> +      {
> +     buf[size++] = ioread8(TPM_DATA_FIFO(tpm, tpm->locality));
> +      }
> +   }
> +   return size;
> +}
> +
> +int tpm_tis_recv(struct tpm_chip* tpm, uint8_t* buf, size_t count) {
> +   int size = 0;
> +   int expected, status;
> +
> +   if (count < TPM_HEADER_SIZE) {
> +      size = -EIO;
> +      goto out;
> +   }
> +
> +   /* read first 10 bytes, including tag, paramsize, and result */
> +   if((size =
> +        recv_data(tpm, buf, TPM_HEADER_SIZE)) < TPM_HEADER_SIZE) {
> +      printk("Error reading tpm cmd header\n");
> +      goto out;
> +   }
> +
> +   expected = be32_to_cpu(*((uint32_t*)(buf + 2)));
> +   if(expected > count) {
> +      size = -EIO;
> +      goto out;
> +   }
> +
> +   if((size += recv_data(tpm, & buf[TPM_HEADER_SIZE],
> +           expected - TPM_HEADER_SIZE)) < expected) {
> +      printk("Unable to read rest of tpm command size=%d
> expected=%d\n", size, expected);
> +      size = -ETIME;
> +      goto out;
> +   }
> +
> +   wait_for_stat(tpm, TPM_STS_VALID, tpm->timeout_c, &tpm->int_queue);
> +   status = tpm_tis_status(tpm);
> +   if(status & TPM_STS_DATA_AVAIL) {
> +      printk("Error: left over data\n");
> +      size = -EIO;
> +      goto out;
> +   }
> +
> +out:
> +   tpm_tis_ready(tpm);
> +   release_locality(tpm, tpm->locality, 0);
> +   return size;
> +}
> +int tpm_tis_send(struct tpm_chip* tpm, uint8_t* buf, size_t len) {
> +   int rc;
> +   int status, burstcnt = 0;
> +   int count = 0;
> +   uint32_t ordinal;
> +
> +   if(tpm_tis_request_locality(tpm, tpm->locality) < 0) {
> +      return -EBUSY;
> +   }
> +
> +   status = tpm_tis_status(tpm);
> +   if((status & TPM_STS_COMMAND_READY) == 0) {
> +      tpm_tis_ready(tpm);
> +      if(wait_for_stat(tpm, TPM_STS_COMMAND_READY, tpm->timeout_b,
> &tpm->int_queue) < 0) {
> +     rc = -ETIME;
> +     goto out_err;
> +      }
> +   }
> +
> +   while(count < len - 1) {
> +      burstcnt = get_burstcount(tpm);
> +      for(;burstcnt > 0 && count < len -1; --burstcnt) {
> +     iowrite8(TPM_DATA_FIFO(tpm, tpm->locality), buf[count++]);
> +      }
> +
> +      wait_for_stat(tpm, TPM_STS_VALID, tpm->timeout_c, &tpm->int_queue);
> +      status = tpm_tis_status(tpm);
> +      if((status & TPM_STS_DATA_EXPECT) == 0) {
> +     rc = -EIO;
> +     goto out_err;
> +      }
> +   }
> +
> +   /*Write last byte*/
> +   iowrite8(TPM_DATA_FIFO(tpm, tpm->locality), buf[count]);
> +   wait_for_stat(tpm, TPM_STS_VALID, tpm->timeout_c, &tpm->read_queue);
> +   status = tpm_tis_status(tpm);
> +   if((status & TPM_STS_DATA_EXPECT) != 0) {
> +      rc = -EIO;
> +      goto out_err;
> +   }
> +
> +   /*go and do it*/
> +   iowrite8(TPM_STS(tpm, tpm->locality), TPM_STS_GO);
> +
> +   if(tpm->irq) {
> +      /*Wait for interrupt */
> +      ordinal = be32_to_cpu(*(buf + 6));
> +      if(wait_for_stat(tpm,
> +           TPM_STS_DATA_AVAIL | TPM_STS_VALID,
> +           tpm_calc_ordinal_duration(tpm, ordinal),
> +           &tpm->read_queue) < 0) {
> +     rc = -ETIME;
> +     goto out_err;
> +      }
> +   }
> +#ifdef HAVE_LIBC
> +   if(tpm->fd >= 0) {
> +      files[tpm->fd].read = 0;
> +      files[tpm->fd].tpm_tis.respgot = 0;
> +      files[tpm->fd].tpm_tis.offset = 0;
> +   }
> +#endif
> +   return len;
> +
> +out_err:
> +   tpm_tis_ready(tpm);
> +   release_locality(tpm, tpm->locality, 0);
> +   return rc;
> +}
> +
> +static void tpm_tis_irq_handler(evtchn_port_t port, struct pt_regs
> *regs, void* data)
> +{
> +   struct tpm_chip* tpm = data;
> +   uint32_t interrupt;
> +   int i;
> +
> +   interrupt = ioread32(TPM_INT_STATUS(tpm, tpm->locality));
> +   if(interrupt == 0) {
> +      return;
> +   }
> +
> +   if(interrupt & TPM_INTF_DATA_AVAIL_INT) {
> +      wake_up(&tpm->read_queue);
> +   }
> +   if(interrupt & TPM_INTF_LOCALITY_CHANGE_INT) {
> +      for(i = 0; i < 5; ++i) {
> +     if(check_locality(tpm, i) >= 0) {
> +        break;
> +     }
> +      }
> +   }
> +   if(interrupt & (TPM_INTF_LOCALITY_CHANGE_INT | TPM_INTF_STS_VALID_INT |
> +        TPM_INTF_CMD_READY_INT)) {
> +      wake_up(&tpm->int_queue);
> +   }
> +
> +   /* Clear interrupts handled with TPM_EOI */
> +   iowrite32(TPM_INT_STATUS(tpm, tpm->locality), interrupt);
> +   ioread32(TPM_INT_STATUS(tpm, tpm->locality));
> +   return;
> +}
> +
> +/*
> + * Internal kernel interface to transmit TPM commands
> + */
> +static ssize_t tpm_transmit(struct tpm_chip *chip, const uint8_t *buf,
> +      size_t bufsiz)
> +{
> +   ssize_t rc;
> +   uint32_t count, ordinal;
> +   s_time_t stop;
> +
> +   count = be32_to_cpu(*((uint32_t *) (buf + 2)));
> +   ordinal = be32_to_cpu(*((uint32_t *) (buf + 6)));
> +   if (count == 0)
> +      return -ENODATA;
> +   if (count > bufsiz) {
> +      printk("Error: invalid count value %x %zx \n", count, bufsiz);
> +      return -E2BIG;
> +   }
> +
> +   //down(&chip->tpm_mutex);
> +
> +   if ((rc = tpm_tis_send(chip, (uint8_t *) buf, count)) < 0) {
> +      printk("tpm_transmit: tpm_send: error %zd\n", rc);
> +      goto out;
> +   }
> +
> +   if (chip->irq)
> +      goto out_recv;
> +
> +   stop = NOW() + tpm_calc_ordinal_duration(chip, ordinal);
> +   do {
> +      uint8_t status = tpm_tis_status(chip);
> +      if ((status & (TPM_STS_DATA_AVAIL | TPM_STS_VALID)) ==
> +        (TPM_STS_DATA_AVAIL | TPM_STS_VALID))
> +     goto out_recv;
> +
> +      if ((status == TPM_STS_COMMAND_READY)) {
> +     printk("TPM Error: Operation Canceled\n");
> +     rc = -ECANCELED;
> +     goto out;
> +      }
> +
> +      msleep(TPM_TIMEOUT);    /* CHECK */
> +      rmb();
> +   } while (NOW() < stop);
> +
> +   /* Cancel the command */
> +   tpm_tis_cancel_cmd(chip);
> +   printk("TPM Operation Timed out\n");
> +   rc = -ETIME;
> +   goto out;
> +
> +out_recv:
> +   if((rc = tpm_tis_recv(chip, (uint8_t *) buf, bufsiz)) < 0) {
> +      printk("tpm_transmit: tpm_recv: error %d\n", rc);
> +   }
> +out:
> +   //up(&chip->tpm_mutex);
> +   return rc;
> +}
> +
> +static ssize_t transmit_cmd(struct tpm_chip *chip, struct tpm_cmd_t *cmd,
> +                            int len, const char *desc)
> +{
> +        int err;
> +
> +        len = tpm_transmit(chip,(uint8_t *) cmd, len);
> +        if (len <  0)
> +                return len;
> +        if (len == TPM_ERROR_SIZE) {
> +                err = be32_to_cpu(cmd->header.out.return_code);
> +                printk("A TPM error (%d) occurred %s\n", err, desc);
> +                return err;
> +        }
> +        return 0;
> +}
> +
> +void tpm_get_timeouts(struct tpm_chip *chip)
> +{
> +   struct tpm_cmd_t tpm_cmd;
> +   struct timeout_t *timeout_cap;
> +   struct duration_t *duration_cap;
> +   ssize_t rc;
> +   uint32_t timeout;
> +
> +   tpm_cmd.header.in = tpm_getcap_header;
> +   tpm_cmd.params.getcap_in.cap = TPM_CAP_PROP;
> +   tpm_cmd.params.getcap_in.subcap_size = cpu_to_be32(4);
> +   tpm_cmd.params.getcap_in.subcap = TPM_CAP_PROP_TIS_TIMEOUT;
> +
> +   if((rc = transmit_cmd(chip, &tpm_cmd, TPM_INTERNAL_RESULT_SIZE,
> +     "attempting to determine the timeouts")) != 0) {
> +      printk("transmit failed %d\n", rc);
> +      goto duration;
> +   }
> +
> +   if (be32_to_cpu(tpm_cmd.params.getcap_out.cap_size)
> +     != 4 * sizeof(uint32_t)) {
> +      printk("Out len check failure %lu \n",
> be32_to_cpu(tpm_cmd.header.out.length));
> +      goto duration;
> +   }
> +
> +   timeout_cap = &tpm_cmd.params.getcap_out.cap.timeout;
> +   /* Don't overwrite default if value is 0 */
> +   timeout = be32_to_cpu(timeout_cap->a);
> +   if (timeout)
> +      chip->timeout_a = MICROSECS(timeout); /*Convert to msec */
> +   timeout = be32_to_cpu(timeout_cap->b);
> +   if (timeout)
> +      chip->timeout_b = MICROSECS(timeout); /*Convert to msec */
> +   timeout = be32_to_cpu(timeout_cap->c);
> +   if (timeout)
> +      chip->timeout_c = MICROSECS(timeout); /*Convert to msec */
> +   timeout = be32_to_cpu(timeout_cap->d);
> +   if (timeout)
> +      chip->timeout_d = MICROSECS(timeout); /*Convert to msec */
> +
> +duration:
> +   tpm_cmd.header.in = tpm_getcap_header;
> +   tpm_cmd.params.getcap_in.cap = TPM_CAP_PROP;
> +   tpm_cmd.params.getcap_in.subcap_size = cpu_to_be32(4);
> +   tpm_cmd.params.getcap_in.subcap = TPM_CAP_PROP_TIS_DURATION;
> +
> +   if((rc = transmit_cmd(chip, &tpm_cmd, TPM_INTERNAL_RESULT_SIZE,
> +     "attempting to determine the durations")) < 0) {
> +      return;
> +   }
> +
> +   if (be32_to_cpu(tpm_cmd.params.getcap_out.cap_size)
> +     != 3 * sizeof(uint32_t)) {
> +      return;
> +   }
> +        duration_cap = &tpm_cmd.params.getcap_out.cap.duration;
> +        chip->duration[TPM_SHORT] = be32_to_cpu(duration_cap->tpm_short);
> +        /* The Broadcom BCM0102 chipset in a Dell Latitude D820 gets
> the above
> +         * value wrong and apparently reports msecs rather than usecs.
> So we
> +         * fix up the resulting too-small TPM_SHORT value to make
> things work.
> +         */
> +        if (chip->duration[TPM_SHORT] < 10) {
> +       chip->duration[TPM_SHORT] = MILLISECS(chip->duration[TPM_SHORT]);
> +    } else {
> +       chip->duration[TPM_SHORT] = MICROSECS(chip->duration[TPM_SHORT]);
> +    }
> +
> +        chip->duration[TPM_MEDIUM] =
> MICROSECS(be32_to_cpu(duration_cap->tpm_medium));
> +        chip->duration[TPM_LONG] =
> MICROSECS(be32_to_cpu(duration_cap->tpm_long));
> +}
> +
> +
> +
> +void tpm_continue_selftest(struct tpm_chip* chip) {
> +   uint8_t data[] = {
> +      0, 193,                 /* TPM_TAG_RQU_COMMAND */
> +      0, 0, 0, 10,            /* length */
> +      0, 0, 0, 83,            /* TPM_ORD_GetCapability */
> +   };
> +
> +   tpm_transmit(chip, data, sizeof(data));
> +}
> +
> +ssize_t tpm_getcap(struct tpm_chip *chip, uint32_t subcap_id, cap_t *cap,
> +                   const char *desc)
> +{
> +        struct tpm_cmd_t tpm_cmd;
> +        int rc;
> +
> +        tpm_cmd.header.in = tpm_getcap_header;
> +        if (subcap_id == CAP_VERSION_1_1 || subcap_id == CAP_VERSION_1_2) {
> +                tpm_cmd.params.getcap_in.cap = subcap_id;
> +                /*subcap field not necessary */
> +                tpm_cmd.params.getcap_in.subcap_size = cpu_to_be32(0);
> +                tpm_cmd.header.in.length -= cpu_to_be32(sizeof(uint32_t));
> +        } else {
> +                if (subcap_id == TPM_CAP_FLAG_PERM ||
> +                    subcap_id == TPM_CAP_FLAG_VOL)
> +                        tpm_cmd.params.getcap_in.cap = TPM_CAP_FLAG;
> +                else
> +                        tpm_cmd.params.getcap_in.cap = TPM_CAP_PROP;
> +                tpm_cmd.params.getcap_in.subcap_size = cpu_to_be32(4);
> +                tpm_cmd.params.getcap_in.subcap = subcap_id;
> +        }
> +        rc = transmit_cmd(chip, &tpm_cmd, TPM_INTERNAL_RESULT_SIZE, desc);
> +        if (!rc)
> +                *cap = tpm_cmd.params.getcap_out.cap;
> +        return rc;
> +}
> +
> +
> +struct tpm_chip* init_tpm_tis(unsigned long baseaddr, int localities,
> unsigned int irq)
> +{
> +   int i;
> +   unsigned long addr;
> +   struct tpm_chip* tpm = NULL;
> +   uint32_t didvid;
> +   uint32_t intfcaps;
> +   uint32_t intmask;
> +
> +   printk("============= Init TPM TIS Driver ==============\n");
> +
> +   /*Sanity check the localities input */
> +   if(localities & ~TPM_TIS_EN_LOCLALL) {
> +      printk("init_tpm_tis() Invalid locality specification! %X\n",
> localities);
> +      goto abort_egress;
> +   }
> +
> +   printk("IOMEM Machine Base Address: %lX\n", baseaddr);
> +
> +   /* Create the tpm data structure */
> +   tpm = malloc(sizeof(struct tpm_chip));
> +   __init_tpm_chip(tpm);
> +
> +   /* Set the enabled localities - if 0 we leave default as all enabled */
> +   if(localities != 0) {
> +      tpm->enabled_localities = localities;
> +   }
> +   printk("Enabled Localities: ");
> +   for(i = 0; i < 5; ++i) {
> +      if(locality_enabled(tpm, i)) {
> +     printk("%d ", i);
> +      }
> +   }
> +   printk("\n");
> +
> +   /* Set the base machine address */
> +   tpm->baseaddr = baseaddr;
> +
> +   /* Set default timeouts */
> +   tpm->timeout_a = MILLISECS(TIS_SHORT_TIMEOUT);
> +   tpm->timeout_b = MILLISECS(TIS_LONG_TIMEOUT);
> +   tpm->timeout_c = MILLISECS(TIS_SHORT_TIMEOUT);
> +   tpm->timeout_d = MILLISECS(TIS_SHORT_TIMEOUT);
> +
> +   /*Map the mmio pages */
> +   addr = tpm->baseaddr;
> +   for(i = 0; i < 5; ++i) {
> +      if(locality_enabled(tpm, i)) {
> +     /* Map the page in now */
> +     if((tpm->pages[i] = ioremap_nocache(addr, PAGE_SIZE)) == NULL) {
> +        printk("Unable to map iomem page a address %p\n", addr);
> +        goto abort_egress;
> +     }
> +
> +     /* Set default locality to the first enabled one */
> +     if (tpm->locality < 0) {
> +        if(tpm_tis_request_locality(tpm, i) < 0) {
> +           printk("Unable to request locality %d??\n", i);
> +           goto abort_egress;
> +        }
> +     }
> +      }
> +      addr += PAGE_SIZE;
> +   }
> +
> +
> +   /* Get the vendor and device ids */
> +   didvid = ioread32(TPM_DID_VID(tpm, tpm->locality));
> +   tpm->did = didvid >> 16;
> +   tpm->vid = didvid & 0xFFFF;
> +
> +
> +   /* Get the revision id */
> +   tpm->rid = ioread8(TPM_RID(tpm, tpm->locality));
> +
> +   printk("1.2 TPM (device-id=0x%X vendor-id = %X rev-id = %X)\n",
> tpm->did, tpm->vid, tpm->rid);
> +
> +   intfcaps = ioread32(TPM_INTF_CAPS(tpm, tpm->locality));
> +   printk("TPM interface capabilities (0x%x):\n", intfcaps);
> +   if (intfcaps & TPM_INTF_BURST_COUNT_STATIC)
> +      printk("\tBurst Count Static\n");
> +   if (intfcaps & TPM_INTF_CMD_READY_INT)
> +      printk("\tCommand Ready Int Support\n");
> +   if (intfcaps & TPM_INTF_INT_EDGE_FALLING)
> +      printk("\tInterrupt Edge Falling\n");
> +   if (intfcaps & TPM_INTF_INT_EDGE_RISING)
> +      printk("\tInterrupt Edge Rising\n");
> +   if (intfcaps & TPM_INTF_INT_LEVEL_LOW)
> +      printk("\tInterrupt Level Low\n");
> +   if (intfcaps & TPM_INTF_INT_LEVEL_HIGH)
> +      printk("\tInterrupt Level High\n");
> +   if (intfcaps & TPM_INTF_LOCALITY_CHANGE_INT)
> +      printk("\tLocality Change Int Support\n");
> +   if (intfcaps & TPM_INTF_STS_VALID_INT)
> +      printk("\tSts Valid Int Support\n");
> +   if (intfcaps & TPM_INTF_DATA_AVAIL_INT)
> +      printk("\tData Avail Int Support\n");
> +
> +   /*Interupt setup */
> +   intmask = ioread32(TPM_INT_ENABLE(tpm, tpm->locality));
> +
> +   intmask |= TPM_INTF_CMD_READY_INT
> +      | TPM_INTF_LOCALITY_CHANGE_INT | TPM_INTF_DATA_AVAIL_INT
> +      | TPM_INTF_STS_VALID_INT;
> +
> +   iowrite32(TPM_INT_ENABLE(tpm, tpm->locality), intmask);
> +
> +   /*If interupts are enabled, handle it */
> +   if(irq) {
> +      if(irq != TPM_PROBE_IRQ) {
> +     tpm->irq = irq;
> +      } else {
> +     /*FIXME add irq probing feature later */
> +     printk("IRQ probing not implemented\n");
> +      }
> +   }
> +
> +   if(tpm->irq) {
> +      iowrite8(TPM_INT_VECTOR(tpm, tpm->locality), tpm->irq);
> +
> +      if(bind_pirq(tpm->irq, 1, tpm_tis_irq_handler, tpm) != 0) {
> +     printk("Unabled to request irq: %u for use\n", tpm->irq);
> +     printk("Will use polling mode\n");
> +     tpm->irq = 0;
> +      } else {
> +     /* Clear all existing */
> +     iowrite32(TPM_INT_STATUS(tpm, tpm->locality),
> ioread32(TPM_INT_STATUS(tpm, tpm->locality)));
> +
> +     /* Turn on interrupts */
> +     iowrite32(TPM_INT_ENABLE(tpm, tpm->locality), intmask |
> TPM_GLOBAL_INT_ENABLE);
> +      }
> +   }
> +
> +   tpm_get_timeouts(tpm);
> +   tpm_continue_selftest(tpm);
> +
> +
> +   return tpm;
> +abort_egress:
> +   if(tpm != NULL) {
> +      shutdown_tpm_tis(tpm);
> +   }
> +   return NULL;
> +}
> +
> +void shutdown_tpm_tis(struct tpm_chip* tpm){
> +   int i;
> +
> +   printk("Shutting down tpm_tis device\n");
> +
> +   iowrite32(TPM_INT_ENABLE(tpm, tpm->locality), ~TPM_GLOBAL_INT_ENABLE);
> +
> +   /*Unmap all of the mmio pages */
> +   for(i = 0; i < 5; ++i) {
> +      if(tpm->pages[i] != NULL) {
> +     iounmap(tpm->pages[i], PAGE_SIZE);
> +     tpm->pages[i] = NULL;
> +      }
> +   }
> +   free(tpm);
> +   return;
> +}
> +
> +
> +int tpm_tis_cmd(struct tpm_chip* tpm, uint8_t* req, size_t reqlen,
> uint8_t** resp, size_t* resplen)
> +{
> +   if(tpm->locality < 0) {
> +      printk("tpm_tis_cmd() failed! locality not set!\n");
> +      return -1;
> +   }
> +   if(reqlen > TPM_BUFSIZE) {
> +      reqlen = TPM_BUFSIZE;
> +   }
> +   memcpy(tpm->data_buffer, req, reqlen);
> +   *resplen = tpm_transmit(tpm, tpm->data_buffer, TPM_BUFSIZE);
> +
> +   *resp = malloc(*resplen);
> +   memcpy(*resp, tpm->data_buffer, *resplen);
> +   return 0;
> +}
> +
> +#ifdef HAVE_LIBC
> +int tpm_tis_open(struct tpm_chip* tpm)
> +{
> +   /* Silently prevent multiple opens */
> +   if(tpm->fd != -1) {
> +      return tpm->fd;
> +   }
> +
> +   tpm->fd = alloc_fd(FTYPE_TPM_TIS);
> +   printk("tpm_tis_open() -> %d\n", tpm->fd);
> +   files[tpm->fd].tpm_tis.dev = tpm;
> +   files[tpm->fd].tpm_tis.offset = 0;
> +   files[tpm->fd].tpm_tis.respgot = 0;
> +   return tpm->fd;
> +}
> +
> +int tpm_tis_posix_write(int fd, const uint8_t* buf, size_t count)
> +{
> +   struct tpm_chip* tpm;
> +   tpm = files[fd].tpm_tis.dev;
> +
> +   if(tpm->locality < 0) {
> +      printk("tpm_tis_posix_write() failed! locality not set!\n");
> +      errno = EINPROGRESS;
> +      return -1;
> +   }
> +   if(count == 0) {
> +      return 0;
> +   }
> +
> +   /* Return an error if we are already processing a command */
> +   if(count > TPM_BUFSIZE) {
> +      count = TPM_BUFSIZE;
> +   }
> +   /* Send the command now */
> +   memcpy(tpm->data_buffer, buf, count);
> +   if((tpm->data_len = tpm_transmit(tpm, tpm->data_buffer,
> TPM_BUFSIZE)) < 0) {
> +      errno = EIO;
> +      return -1;
> +   }
> +   return count;
> +}
> +
> +int tpm_tis_posix_read(int fd, uint8_t* buf, size_t count)
> +{
> +   int rc;
> +   struct tpm_chip* tpm;
> +   tpm = files[fd].tpm_tis.dev;
> +
> +   if(count == 0) {
> +      return 0;
> +   }
> +
> +   /* If there is no tpm resp to read, return EIO */
> +   if(tpm->data_len < 0) {
> +      errno = EIO;
> +      return -1;
> +   }
> +
> +
> +   /* Handle EOF case */
> +   if(files[fd].tpm_tis.offset >= tpm->data_len) {
> +      rc = 0;
> +   } else {
> +      rc = min(tpm->data_len - files[fd].tpm_tis.offset, count);
> +      memcpy(buf, tpm->data_buffer + files[fd].tpm_tis.offset, rc);
> +   }
> +   files[fd].tpm_tis.offset += rc;
> +   /* Reset the data pending flag */
> +   return rc;
> +}
> +int tpm_tis_posix_fstat(int fd, struct stat* buf)
> +{
> +   struct tpm_chip* tpm;
> +   tpm = files[fd].tpm_tis.dev;
> +
> +   buf->st_mode = O_RDWR;
> +   buf->st_uid = 0;
> +   buf->st_gid = 0;
> +   buf->st_size = be32_to_cpu(*((uint32_t*)(tpm->data_buffer + 2)));
> +   buf->st_atime = buf->st_mtime = buf->st_ctime = time(NULL);
> +   return 0;
> +}
> +
> +
> +#endif
> diff --git a/extras/mini-os/tpmback.c b/extras/mini-os/tpmback.c
> --- /dev/null
> +++ b/extras/mini-os/tpmback.c
> @@ -0,0 +1,1114 @@
> +/*
> + * Copyright (c) 2010-2012 United States Government, as represented by
> + * the Secretary of Defense.  All rights reserved.
> + *
> + * This driver 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 3 of the License, or
> + * (at your option) any later version.
> + *
> + * This driver is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program.  If not, see <http://www.gnu.org/licenses/>.
> + *
> + * Based upon the files:
> + *  drivers/xen/tpmbk.c
> + * from the Linux kernel, which are Copyright (C) 2006 IBM Corporation
> + */
> +#include <mini-os/os.h>
> +#include <mini-os/xenbus.h>
> +#include <mini-os/events.h>
> +#include <errno.h>
> +#include <mini-os/gnttab.h>
> +#include <xen/io/xenbus.h>
> +#include <xen/io/tpmif.h>
> +#include <xen/io/protocols.h>
> +#include <mini-os/xmalloc.h>
> +#include <time.h>
> +#include <mini-os/tpmback.h>
> +#include <mini-os/lib.h>
> +#include <fcntl.h>
> +#include <mini-os/mm.h>
> +#include <mini-os/posix/sys/mman.h>
> +#include <mini-os/semaphore.h>
> +#include <mini-os/wait.h>
> +
> +
> +#ifndef HAVE_LIBC
> +#define strtoul simple_strtoul
> +#endif
> +
> +//#define TPMBACK_PRINT_DEBUG
> +#ifdef TPMBACK_PRINT_DEBUG
> +#define TPMBACK_DEBUG(fmt,...) printk("Tpmback:Debug("__FILE__":%d) "
> fmt, __LINE__, ##__VA_ARGS__)
> +#define TPMBACK_DEBUG_MORE(fmt,...) printk(fmt, ##__VA_ARGS__)
> +#else
> +#define TPMBACK_DEBUG(fmt,...)
> +#endif
> +#define TPMBACK_ERR(fmt,...) printk("Tpmback:Error " fmt, ##__VA_ARGS__)
> +#define TPMBACK_LOG(fmt,...) printk("Tpmback:Info " fmt, ##__VA_ARGS__)
> +
> +#define min(a,b) (((a) < (b)) ? (a) : (b))
> +
> +/* Default size of the tpmif array at initialization */
> +#define DEF_ARRAY_SIZE 1
> +
> +/* tpmif and tpmdev flags */
> +#define TPMIF_CLOSED 1
> +#define TPMIF_REQ_READY 2
> +
> +struct tpmif {
> +   domid_t domid;
> +   unsigned int handle;
> +
> +   char* fe_path;
> +   char* fe_state_path;
> +
> +   /* Locally bound event channel*/
> +   evtchn_port_t evtchn;
> +
> +   /* Shared page */
> +   tpmif_tx_interface_t* tx;
> +
> +   /* pointer to TPMIF_RX_RING_SIZE pages */
> +   void** pages;
> +
> +   enum xenbus_state state;
> +   enum { DISCONNECTED, DISCONNECTING, CONNECTED } status;
> +
> +   char* uuid;
> +
> +   /* state flags */
> +   int flags;
> +};
> +typedef struct tpmif tpmif_t;
> +
> +struct tpmback_dev {
> +
> +   tpmif_t** tpmlist;
> +   unsigned long num_tpms;
> +   unsigned long num_alloc;
> +
> +   struct gntmap map;
> +
> +   /* True if at least one tpmif has a request to be handled */
> +   int flags;
> +
> +   /* exclusive domains, see init_tpmback comment in tpmback.h */
> +   char** exclusive_uuids;
> +
> +   xenbus_event_queue events;
> +
> +   /* Callbacks */
> +   void (*open_callback)(domid_t, unsigned int);
> +   void (*close_callback)(domid_t, unsigned int);
> +   void (*suspend_callback)(domid_t, unsigned int);
> +   void (*resume_callback)(domid_t, unsigned int);
> +};
> +typedef struct tpmback_dev tpmback_dev_t;
> +
> +enum { EV_NONE, EV_NEWFE, EV_STCHNG } tpm_ev_enum;
> +
> +/* Global objects */
> +static struct thread* eventthread = NULL;
> +static tpmback_dev_t gtpmdev = {
> +   .tpmlist = NULL,
> +   .num_tpms = 0,
> +   .num_alloc = 0,
> +   .flags = TPMIF_CLOSED,
> +   .events = NULL,
> +   .open_callback = NULL,
> +   .close_callback = NULL,
> +   .suspend_callback = NULL,
> +   .resume_callback = NULL,
> +};
> +struct wait_queue_head waitq;
> +int globalinit = 0;
> +
> +/************************************
> + * TPMIF SORTED ARRAY FUNCTIONS
> + * tpmback_dev_t.tpmlist is a sorted array, sorted by domid and then
> handle number
> + * Duplicates are not allowed
> + * **********************************/
> +
> +inline void tpmif_req_ready(tpmif_t* tpmif) {
> +   tpmif->flags |= TPMIF_REQ_READY;
> +   gtpmdev.flags |= TPMIF_REQ_READY;
> +}
> +
> +inline void tpmdev_check_req(void) {
> +   int i;
> +   int flags;
> +   local_irq_save(flags);
> +   for(i = 0; i < gtpmdev.num_tpms; ++i) {
> +      if(gtpmdev.tpmlist[i]->flags & TPMIF_REQ_READY) {
> +     gtpmdev.flags |= TPMIF_REQ_READY;
> +     local_irq_restore(flags);
> +     return;
> +      }
> +   }
> +   gtpmdev.flags &= ~TPMIF_REQ_READY;
> +   local_irq_restore(flags);
> +}
> +
> +inline void tpmif_req_finished(tpmif_t* tpmif) {
> +   tpmif->flags &= ~TPMIF_REQ_READY;
> +   tpmdev_check_req();
> +}
> +
> +int __get_tpmif_index(int st, int n, domid_t domid, unsigned int handle)
> +{
> +   int i = st + n /2;
> +   tpmif_t* tmp;
> +
> +   if( n <= 0 )
> +      return -1;
> +
> +   tmp = gtpmdev.tpmlist[i];
> +   if(domid == tmp->domid && tmp->handle == handle) {
> +      return i;
> +   } else if ( (domid < tmp->domid) ||
> +     (domid == tmp->domid && handle < tmp->handle)) {
> +      return __get_tpmif_index(st, n/2, domid, handle);
> +   } else {
> +      return __get_tpmif_index(i + 1, n/2 - ((n +1) % 2), domid, handle);
> +   }
> +}
> +
> +/* Returns the array index of the tpmif domid/handle. Returns -1 if no
> such tpmif exists */
> +int get_tpmif_index(domid_t domid, unsigned int handle)
> +{
> +   int flags;
> +   int index;
> +   local_irq_save(flags);
> +   index = __get_tpmif_index(0, gtpmdev.num_tpms, domid, handle);
> +   local_irq_restore(flags);
> +   return index;
> +}
> +
> +/* Returns the tpmif domid/handle or NULL if none exists */
> +tpmif_t* get_tpmif(domid_t domid, unsigned int handle)
> +{
> +   int flags;
> +   int i;
> +   tpmif_t* ret;
> +   local_irq_save(flags);
> +   i = get_tpmif_index(domid, handle);
> +   if (i < 0) {
> +      ret = NULL;
> +   } else {
> +      ret = gtpmdev.tpmlist[i];
> +   }
> +   local_irq_restore(flags);
> +   return ret;
> +}
> +
> +/* Remove the given tpmif. Returns 0 if it was removed, -1 if it was
> not removed */
> +int remove_tpmif(tpmif_t* tpmif)
> +{
> +   int i, j;
> +   char* err;
> +   int flags;
> +   local_irq_save(flags);
> +
> +   /* Find the index in the array if it exists */
> +   i = get_tpmif_index(tpmif->domid, tpmif->handle);
> +   if (i < 0) {
> +      goto error;
> +   }
> +
> +   /* Remove the interface from the list */
> +   for(j = i; j < gtpmdev.num_tpms - 1; ++j) {
> +      gtpmdev.tpmlist[j] = gtpmdev.tpmlist[j+1];
> +   }
> +   gtpmdev.tpmlist[j] = NULL;
> +   --gtpmdev.num_tpms;
> +
> +   /* If removed tpm was the only ready tpm, then we need to check and
> turn off the ready flag */
> +   tpmdev_check_req();
> +
> +   local_irq_restore(flags);
> +
> +   /* Stop listening for events on this tpm interface */
> +   if((err = xenbus_unwatch_path_token(XBT_NIL, tpmif->fe_state_path,
> tpmif->fe_state_path))) {
> +      TPMBACK_ERR("Unable to unwatch path token `%s' Error was %s
> Ignoring..\n", tpmif->fe_state_path, err);
> +      free(err);
> +   }
> +
> +   return 0;
> +error:
> +   local_irq_restore(flags);
> +   return -1;
> +}
> +
> +/* Insert tpmif into dev->tpmlist. Returns 0 on success and non zero on
> error.
> + * It is an error to insert a tpmif with the same domid and handle
> + * number
> + * as something already in the list */
> +int insert_tpmif(tpmif_t* tpmif)
> +{
> +   int flags;
> +   unsigned int i, j;
> +   tpmif_t* tmp;
> +   char* err;
> +
> +   local_irq_save(flags);
> +
> +   /*Check if we need to allocate more space */
> +   if (gtpmdev.num_tpms == gtpmdev.num_alloc) {
> +      gtpmdev.num_alloc *= 2;
> +      gtpmdev.tpmlist = realloc(gtpmdev.tpmlist, gtpmdev.num_alloc);
> +   }
> +
> +   /*Find where to put the new interface */
> +   for(i = 0; i < gtpmdev.num_tpms; ++i)
> +   {
> +      tmp = gtpmdev.tpmlist[i];
> +      if(tpmif->domid == tmp->domid && tpmif->handle == tmp->handle) {
> +     TPMBACK_ERR("Tried to insert duplicate tpm interface %u/%u\n",
> (unsigned int) tpmif->domid, tpmif->handle);
> +     goto error;
> +      }
> +      if((tpmif->domid < tmp->domid) ||
> +        (tpmif->domid == tmp->domid && tpmif->handle < tmp->handle)) {
> +     break;
> +      }
> +   }
> +
> +   /*Shift all the tpm pointers past i down one */
> +   for(j = gtpmdev.num_tpms; j > i; --j) {
> +      gtpmdev.tpmlist[j] = gtpmdev.tpmlist[j-1];
> +   }
> +
> +   /*Add the new interface */
> +   gtpmdev.tpmlist[i] = tpmif;
> +   ++gtpmdev.num_tpms;
> +
> +   /*Should not be needed, anything inserted with ready flag is
> probably an error */
> +   tpmdev_check_req();
> +
> +   local_irq_restore(flags);
> +
> +   /*Listen for state changes on the new interface */
> +   if((err = xenbus_watch_path_token(XBT_NIL, tpmif->fe_state_path,
> tpmif->fe_state_path, &gtpmdev.events)))
> +   {
> +      /* if we got an error here we should carefully remove the
> interface and then return */
> +      TPMBACK_ERR("Unable to watch path token `%s' Error was %s\n",
> tpmif->fe_state_path, err);
> +      free(err);
> +      remove_tpmif(tpmif);
> +      goto error_post_irq;
> +   }
> +
> +   return 0;
> +error:
> +   local_irq_restore(flags);
> +error_post_irq:
> +   return -1;
> +}
> +
> +
> +/*****************
> + * CHANGE BACKEND STATE
> + * *****************/
> +/*Attempts to change the backend state in xenstore
> + * returns 0 on success and non-zero on error */
> +int tpmif_change_state(tpmif_t* tpmif, enum xenbus_state state)
> +{
> +   char path[512];
> +   char *value;
> +   char *err;
> +   enum xenbus_state readst;
> +   TPMBACK_DEBUG("Backend state change %u/%u from=%d to=%d\n",
> (unsigned int) tpmif->domid, tpmif->handle, tpmif->state, state);
> +   if (tpmif->state == state)
> +      return 0;
> +
> +   snprintf(path, 512, "backend/vtpm/%u/%u/state", (unsigned int)
> tpmif->domid, tpmif->handle);
> +
> +   if((err = xenbus_read(XBT_NIL, path, &value))) {
> +      TPMBACK_ERR("Unable to read backend state %s, error was %s\n",
> path, err);
> +      free(err);
> +      return -1;
> +   }
> +   if(sscanf(value, "%d", &readst) != 1) {
> +      TPMBACK_ERR("Non integer value (%s) in %s ??\n", value, path);
> +      free(value);
> +      return -1;
> +   }
> +   free(value);
> +
> +   /* It's possible that the backend state got updated by hotplug or
> something else behind our back */
> +   if(readst != tpmif->state) {
> +      TPMBACK_DEBUG("tpm interface state was %d but xenstore state was
> %d!\n", tpmif->state, readst);
> +      tpmif->state = readst;
> +   }
> +
> +   /*If if the state isnt changing, then we dont update xenstore b/c we
> dont want to fire extraneous events */
> +   if(tpmif->state == state) {
> +      return 0;
> +   }
> +
> +   /*update xenstore*/
> +   snprintf(path, 512, "backend/vtpm/%u/%u", (unsigned int)
> tpmif->domid, tpmif->handle);
> +   if((err = xenbus_printf(XBT_NIL, path, "state", "%u", state))) {
> +      TPMBACK_ERR("Error writing to xenstore %s, error was %s new
> state=%d\n", path, err, state);
> +      free(err);
> +      return -1;
> +   }
> +
> +   tpmif->state = state;
> +
> +   return 0;
> +}
> +/**********************************
> + * TPMIF CREATION AND DELETION
> + * *******************************/
> +inline tpmif_t* __init_tpmif(domid_t domid, unsigned int handle)
> +{
> +   tpmif_t* tpmif;
> +   tpmif = malloc(sizeof(*tpmif));
> +   tpmif->domid = domid;
> +   tpmif->handle = handle;
> +   tpmif->fe_path = NULL;
> +   tpmif->fe_state_path = NULL;
> +   tpmif->state = XenbusStateInitialising;
> +   tpmif->status = DISCONNECTED;
> +   tpmif->tx = NULL;
> +   tpmif->pages = NULL;
> +   tpmif->flags = 0;
> +   tpmif->uuid = NULL;
> +   return tpmif;
> +}
> +
> +void __free_tpmif(tpmif_t* tpmif)
> +{
> +   if(tpmif->pages) {
> +      free(tpmif->pages);
> +   }
> +   if(tpmif->fe_path) {
> +      free(tpmif->fe_path);
> +   }
> +   if(tpmif->fe_state_path) {
> +      free(tpmif->fe_state_path);
> +   }
> +   if(tpmif->uuid) {
> +      free(tpmif->uuid);
> +   }
> +   free(tpmif);
> +}
> +/* Creates a new tpm interface, adds it to the sorted array and returns it.
> + * returns NULL on error
> + * If the tpm interface already exists, it is returned*/
> +tpmif_t* new_tpmif(domid_t domid, unsigned int handle)
> +{
> +   tpmif_t* tpmif;
> +   char* err;
> +   char path[512];
> +
> +   /* Make sure we haven't already created this tpm
> +    * Double events can occur */
> +   if((tpmif = get_tpmif(domid, handle)) != NULL) {
> +      return tpmif;
> +   }
> +
> +   tpmif = __init_tpmif(domid, handle);
> +
> +   /* Get the uuid from xenstore */
> +   snprintf(path, 512, "backend/vtpm/%u/%u/uuid", (unsigned int) domid,
> handle);
> +   if((err = xenbus_read(XBT_NIL, path, &tpmif->uuid))) {
> +      TPMBACK_ERR("Error reading %s, Error = %s\n", path, err);
> +      free(err);
> +      goto error;
> +   }
> +
> +   /* Do the exclusive uuid check now */
> +   if(gtpmdev.exclusive_uuids != NULL) {
> +      char** ptr;
> +
> +      /* Check that its in the whitelist */
> +      for(ptr = gtpmdev.exclusive_uuids; *ptr != NULL; ++ptr) {
> +     if(!strcmp(tpmif->uuid, *ptr)) {
> +        break;
> +     }
> +      }
> +      /* If *ptr == NULL then we went through the whole list without a
> match, so close the connection */
> +      if(*ptr == NULL) {
> +     tpmif_change_state(tpmif, XenbusStateClosed);
> +     TPMBACK_ERR("Frontend %u/%u tried to connect with invalid
> uuid=%s\n", (unsigned int) domid, handle, tpmif->uuid);
> +     goto error;
> +      }
> +   }
> +
> +   /* allocate pages to be used for shared mapping */
> +   if((tpmif->pages = malloc(sizeof(void*) * TPMIF_TX_RING_SIZE)) ==
> NULL) {
> +      goto error;
> +   }
> +   memset(tpmif->pages, 0, sizeof(void*) * TPMIF_TX_RING_SIZE);
> +
> +   if(tpmif_change_state(tpmif, XenbusStateInitWait)) {
> +      goto error;
> +   }
> +
> +   snprintf(path, 512, "backend/vtpm/%u/%u/frontend", (unsigned int)
> domid, handle);
> +   if((err = xenbus_read(XBT_NIL, path, &tpmif->fe_path))) {
> +      TPMBACK_ERR("Error creating new tpm instance xenbus_read(%s),
> Error = %s", path, err);
> +      free(err);
> +      goto error;
> +   }
> +
> +   /*Set the state path */
> +   tpmif->fe_state_path = malloc(strlen(tpmif->fe_path) + 7);
> +   strcpy(tpmif->fe_state_path, tpmif->fe_path);
> +   strcat(tpmif->fe_state_path, "/state");
> +
> +   if(insert_tpmif(tpmif)) {
> +      goto error;
> +   }
> +   TPMBACK_DEBUG("New tpmif %u/%u\n", (unsigned int) tpmif->domid,
> tpmif->handle);
> +   /* Do the callback now */
> +   if(gtpmdev.open_callback) {
> +      gtpmdev.open_callback(tpmif->domid, tpmif->handle);
> +   }
> +   return tpmif;
> +error:
> +   __free_tpmif(tpmif);
> +   return NULL;
> +
> +}
> +
> +/* Removes tpmif from dev->tpmlist and frees it's memory usage */
> +void free_tpmif(tpmif_t* tpmif)
> +{
> +   char* err;
> +   char path[512];
> +   TPMBACK_DEBUG("Free tpmif %u/%u\n", (unsigned int) tpmif->domid,
> tpmif->handle);
> +   if(tpmif->flags & TPMIF_CLOSED) {
> +      TPMBACK_ERR("Tried to free an instance twice! Theres a bug
> somewhere!\n");
> +      BUG();
> +   }
> +   tpmif->flags = TPMIF_CLOSED;
> +
> +   tpmif_change_state(tpmif, XenbusStateClosing);
> +
> +   /* Unmap share page and unbind event channel */
> +   if(tpmif->status == CONNECTED) {
> +      tpmif->status = DISCONNECTING;
> +      mask_evtchn(tpmif->evtchn);
> +
> +      if(gntmap_munmap(&gtpmdev.map, (unsigned long)tpmif->tx, 1)) {
> +     TPMBACK_ERR("%u/%u Error occured while trying to unmap shared
> page\n", (unsigned int) tpmif->domid, tpmif->handle);
> +      }
> +
> +      unbind_evtchn(tpmif->evtchn);
> +   }
> +   tpmif->status = DISCONNECTED;
> +   tpmif_change_state(tpmif, XenbusStateClosed);
> +
> +   /* Do the callback now */
> +   if(gtpmdev.close_callback) {
> +      gtpmdev.close_callback(tpmif->domid, tpmif->handle);
> +   }
> +
> +   /* remove from array */
> +   remove_tpmif(tpmif);
> +
> +   /* Wake up anyone possibly waiting on this interface and let them
> exit */
> +   wake_up(&waitq);
> +   schedule();
> +
> +   /* Remove the old xenbus entries */
> +   snprintf(path, 512, "backend/vtpm/%u/%u", (unsigned int)
> tpmif->domid, tpmif->handle);
> +   if((err = xenbus_rm(XBT_NIL, path))) {
> +      TPMBACK_ERR("Error cleaning up xenbus entries path=%s
> error=%s\n", path, err);
> +      free(err);
> +   }
> +
> +   TPMBACK_LOG("Frontend %u/%u disconnected\n", (unsigned int)
> tpmif->domid, tpmif->handle);
> +
> +   /* free memory */
> +   __free_tpmif(tpmif);
> +
> +}
> +
> +/**********************
> + * REMAINING TPMBACK FUNCTIONS
> + * ********************/
> +
> +/*Event channel handler */
> +void tpmback_handler(evtchn_port_t port, struct pt_regs *regs, void *data)
> +{
> +   tpmif_t* tpmif = (tpmif_t*) data;
> +   tpmif_tx_request_t* tx = &tpmif->tx->ring[0].req;
> +   /* Throw away 0 size events, these can trigger from event channel
> unmasking */
> +   if(tx->size == 0)
> +      return;
> +
> +   TPMBACK_DEBUG("EVENT CHANNEL FIRE %u/%u\n", (unsigned int)
> tpmif->domid, tpmif->handle);
> +   tpmif_req_ready(tpmif);
> +   wake_up(&waitq);
> +
> +}
> +
> +/* Connect to frontend */
> +int connect_fe(tpmif_t* tpmif)
> +{
> +   char path[512];
> +   char* err, *value;
> +   uint32_t domid;
> +   grant_ref_t ringref;
> +   evtchn_port_t evtchn;
> +
> +   /* If already connected then quit */
> +   if (tpmif->status == CONNECTED) {
> +      TPMBACK_DEBUG("%u/%u tried to connect while it was already
> connected?\n", (unsigned int) tpmif->domid, tpmif->handle);
> +      return 0;
> +   }
> +
> +   /* Fetch the grant reference */
> +   snprintf(path, 512, "%s/ring-ref", tpmif->fe_path);
> +   if((err = xenbus_read(XBT_NIL, path, &value))) {
> +      TPMBACK_ERR("Error creating new tpm instance xenbus_read(%s)
> Error = %s", path, err);
> +      free(err);
> +      return -1;
> +   }
> +   if(sscanf(value, "%d", &ringref) != 1) {
> +      TPMBACK_ERR("Non integer value (%s) in %s ??\n", value, path);
> +      free(value);
> +      return -1;
> +   }
> +   free(value);
> +
> +
> +   /* Fetch the event channel*/
> +   snprintf(path, 512, "%s/event-channel", tpmif->fe_path);
> +   if((err = xenbus_read(XBT_NIL, path, &value))) {
> +      TPMBACK_ERR("Error creating new tpm instance xenbus_read(%s)
> Error = %s", path, err);
> +      free(err);
> +      return -1;
> +   }
> +   if(sscanf(value, "%d", &evtchn) != 1) {
> +      TPMBACK_ERR("Non integer value (%s) in %s ??\n", value, path);
> +      free(value);
> +      return -1;
> +   }
> +   free(value);
> +
> +   domid = tpmif->domid;
> +   if((tpmif->tx = gntmap_map_grant_refs(&gtpmdev.map, 1, &domid, 0,
> &ringref, PROT_READ | PROT_WRITE)) == NULL) {
> +      TPMBACK_ERR("Failed to map grant reference %u/%u\n", (unsigned
> int) tpmif->domid, tpmif->handle);
> +      return -1;
> +   }
> +   memset(tpmif->tx, 0, PAGE_SIZE);
> +
> +   /*Bind the event channel */
> +   if((evtchn_bind_interdomain(tpmif->domid, evtchn, tpmback_handler,
> tpmif, &tpmif->evtchn)))
> +   {
> +      TPMBACK_ERR("%u/%u Unable to bind to interdomain event
> channel!\n", (unsigned int) tpmif->domid, tpmif->handle);
> +      goto error_post_map;
> +   }
> +   unmask_evtchn(tpmif->evtchn);
> +
> +   /* Write the ready flag and change status to connected */
> +   snprintf(path, 512, "backend/vtpm/%u/%u", (unsigned int)
> tpmif->domid, tpmif->handle);
> +   if((err = xenbus_printf(XBT_NIL, path, "ready", "%u", 1))) {
> +      TPMBACK_ERR("%u/%u Unable to write ready flag on connect_fe()\n",
> (unsigned int) tpmif->domid, tpmif->handle);
> +      free(err);
> +      goto error_post_evtchn;
> +   }
> +   tpmif->status = CONNECTED;
> +   if((tpmif_change_state(tpmif, XenbusStateConnected))){
> +      goto error_post_evtchn;
> +   }
> +
> +   TPMBACK_LOG("Frontend %u/%u connected\n", (unsigned int)
> tpmif->domid, tpmif->handle);
> +
> +   return 0;
> +error_post_evtchn:
> +   mask_evtchn(tpmif->evtchn);
> +   unbind_evtchn(tpmif->evtchn);
> +error_post_map:
> +   gntmap_munmap(&gtpmdev.map, (unsigned long)tpmif->tx, 1);
> +   return -1;
> +}
> +
> +static int frontend_changed(tpmif_t* tpmif)
> +{
> +   int state = xenbus_read_integer(tpmif->fe_state_path);
> +   if(state < 0) {
> +      state = XenbusStateUnknown;
> +   }
> +
> +   TPMBACK_DEBUG("Frontend %u/%u state changed to %d\n", (unsigned int)
> tpmif->domid, tpmif->handle, state);
> +
> +   switch (state) {
> +      case XenbusStateInitialising:
> +      case XenbusStateInitialised:
> +     break;
> +
> +      case XenbusStateConnected:
> +     if(connect_fe(tpmif)) {
> +        TPMBACK_ERR("Failed to connect to front end %u/%u\n", (unsigned
> int) tpmif->domid, tpmif->handle);
> +        tpmif_change_state(tpmif, XenbusStateClosed);
> +        return -1;
> +     }
> +     break;
> +
> +      case XenbusStateClosing:
> +     tpmif_change_state(tpmif, XenbusStateClosing);
> +     break;
> +
> +      case XenbusStateUnknown: /* keep it here */
> +      case XenbusStateClosed:
> +     free_tpmif(tpmif);
> +     break;
> +
> +      default:
> +     TPMBACK_DEBUG("BAD STATE CHANGE %u/%u state = %d for tpmif\n",
> (unsigned int) tpmif->domid, tpmif->handle, state);
> +     return -1;
> +   }
> +   return 0;
> +}
> +
> +
> +/* parses the string that comes out of xenbus_watch_wait_return. */
> +static int parse_eventstr(const char* evstr, domid_t* domid, unsigned
> int* handle)
> +{
> +   int ret;
> +   char cmd[40];
> +   char* err;
> +   char* value;
> +   unsigned int udomid = 0;
> +   tpmif_t* tpmif;
> +   /* First check for new frontends, this occurs when
> /backend/vtpm/<domid>/<handle> gets created. Note we what the sscanf to
> fail on the last %s */
> +   if (sscanf(evstr, "backend/vtpm/%u/%u/%40s", &udomid, handle, cmd)
> == 2) {
> +      *domid = udomid;
> +      /* Make sure the entry exists, if this event triggers because the
> entry dissapeared then ignore it */
> +      if((err = xenbus_read(XBT_NIL, evstr, &value))) {
> +     free(err);
> +     return EV_NONE;
> +      }
> +      free(value);
> +      /* Make sure the tpmif entry does not already exist, this should
> not happen */
> +      if((tpmif = get_tpmif(*domid, *handle)) != NULL) {
> +     TPMBACK_DEBUG("Duplicate tpm entries! %u %u\n", tpmif->domid,
> tpmif->handle);
> +     return EV_NONE;
> +      }
> +      return EV_NEWFE;
> +   } else if((ret = sscanf(evstr,
> "/local/domain/%u/device/vtpm/%u/%40s", &udomid, handle, cmd)) == 3) {
> +      *domid = udomid;
> +      if (!strcmp(cmd, "state"))
> +     return EV_STCHNG;
> +   }
> +   return EV_NONE;
> +}
> +
> +void handle_backend_event(char* evstr) {
> +   tpmif_t* tpmif;
> +   domid_t domid;
> +   unsigned int handle;
> +   int event;
> +
> +   TPMBACK_DEBUG("Xenbus Event: %s\n", evstr);
> +
> +   event = parse_eventstr(evstr, &domid, &handle);
> +
> +   switch(event) {
> +      case EV_NEWFE:
> +     if(new_tpmif(domid, handle) == NULL) {
> +        TPMBACK_ERR("Failed to create new tpm instance %u/%u\n",
> (unsigned int) domid, handle);
> +     }
> +     wake_up(&waitq);
> +     break;
> +      case EV_STCHNG:
> +     if((tpmif = get_tpmif(domid, handle))) {
> +        frontend_changed(tpmif);
> +     } else {
> +        TPMBACK_DEBUG("Event Received for non-existant tpm!
> instance=%u/%u xenbus_event=%s\n", (unsigned int) domid, handle, evstr);
> +     }
> +     break;
> +   }
> +}
> +
> +/* Runs through the given path and creates events recursively
> + * for all of its children.
> + * @path - xenstore path to scan */
> +static void generate_backend_events(const char* path)
> +{
> +   char* err;
> +   int i, len;
> +   char **dirs;
> +   char *entry;
> +
> +   if((err = xenbus_ls(XBT_NIL, path, &dirs)) != NULL) {
> +      free(err);
> +      return;
> +   }
> +
> +   for(i = 0; dirs[i] != NULL; ++i) {
> +      len = strlen(path) + strlen(dirs[i]) + 2;
> +      entry = malloc(len);
> +      snprintf(entry, len, "%s/%s", path, dirs[i]);
> +
> +      /* Generate and handle event for the entry itself */
> +      handle_backend_event(entry);
> +
> +      /* Do children */
> +      generate_backend_events(entry);
> +
> +      /* Cleanup */
> +      free(entry);
> +      free(dirs[i]);
> +   }
> +   free(dirs);
> +   return;
> +}
> +
> +char* tpmback_get_uuid(domid_t domid, unsigned int handle)
> +{
> +   tpmif_t* tpmif;
> +   if((tpmif = get_tpmif(domid, handle)) == NULL) {
> +      TPMBACK_DEBUG("get_uuid() failed, %u/%u is an invalid
> frontend\n", (unsigned int) domid, handle);
> +      return NULL;
> +   }
> +
> +   return tpmif->uuid;
> +}
> +
> +void tpmback_set_open_callback(void (*cb)(domid_t, unsigned int))
> +{
> +   gtpmdev.open_callback = cb;
> +}
> +void tpmback_set_close_callback(void (*cb)(domid_t, unsigned int))
> +{
> +   gtpmdev.close_callback = cb;
> +}
> +void tpmback_set_suspend_callback(void (*cb)(domid_t, unsigned int))
> +{
> +   gtpmdev.suspend_callback = cb;
> +}
> +void tpmback_set_resume_callback(void (*cb)(domid_t, unsigned int))
> +{
> +   gtpmdev.resume_callback = cb;
> +}
> +
> +static void event_listener(void)
> +{
> +   const char* bepath = "backend/vtpm";
> +   char **path;
> +   char* err;
> +
> +   /* Setup the backend device watch */
> +   if((err = xenbus_watch_path_token(XBT_NIL, bepath, bepath,
> &gtpmdev.events)) != NULL) {
> +      TPMBACK_ERR("xenbus_watch_path_token(%s) failed with error
> %s!\n", bepath, err);
> +      free(err);
> +      goto egress;
> +   }
> +
> +   /* Check for any frontends that connected before we set the watch.
> +    * This is almost guaranteed to happen if both domains are started
> +    * immediatly one after the other.
> +    * We do this by manually generating events on everything in the backend
> +    * path */
> +   generate_backend_events(bepath);
> +
> +   /* Wait and listen for changes in frontend connections */
> +   while(1) {
> +      path = xenbus_wait_for_watch_return(&gtpmdev.events);
> +
> +      /*If quit flag was set then exit */
> +      if(gtpmdev.flags & TPMIF_CLOSED) {
> +     TPMBACK_DEBUG("listener thread got quit event. Exiting..\n");
> +     free(path);
> +     break;
> +      }
> +      handle_backend_event(*path);
> +      free(path);
> +
> +   }
> +
> +   if((err = xenbus_unwatch_path_token(XBT_NIL, bepath, bepath)) != NULL) {
> +      free(err);
> +   }
> +egress:
> +   return;
> +}
> +
> +void event_thread(void* p) {
> +   event_listener();
> +}
> +
> +void init_tpmback(char** exclusive_uuids)
> +{
> +   if(!globalinit) {
> +      init_waitqueue_head(&waitq);
> +      globalinit = 1;
> +   }
> +   printk("============= Init TPM BACK ================\n");
> +   gtpmdev.tpmlist = malloc(sizeof(tpmif_t*) * DEF_ARRAY_SIZE);
> +   gtpmdev.num_alloc = DEF_ARRAY_SIZE;
> +   gtpmdev.num_tpms = 0;
> +   gtpmdev.flags = 0;
> +   gtpmdev.exclusive_uuids = exclusive_uuids;
> +
> +   gtpmdev.open_callback = gtpmdev.close_callback = NULL;
> +   gtpmdev.suspend_callback = gtpmdev.resume_callback = NULL;
> +
> +   eventthread = create_thread("tpmback-listener", event_thread, NULL);
> +
> +}
> +
> +void shutdown_tpmback(void)
> +{
> +   /* Disable callbacks */
> +   gtpmdev.open_callback = gtpmdev.close_callback = NULL;
> +   gtpmdev.suspend_callback = gtpmdev.resume_callback = NULL;
> +
> +   TPMBACK_LOG("Shutting down tpm backend\n");
> +   /* Set the quit flag */
> +   gtpmdev.flags = TPMIF_CLOSED;
> +
> +   //printk("num tpms is %d\n", gtpmdev.num_tpms);
> +   /*Free all backend instances */
> +   while(gtpmdev.num_tpms) {
> +      free_tpmif(gtpmdev.tpmlist[0]);
> +   }
> +   free(gtpmdev.tpmlist);
> +   gtpmdev.tpmlist = NULL;
> +   gtpmdev.num_alloc = 0;
> +
> +   /* Wake up anyone possibly waiting on the device and let them exit */
> +   wake_up(&waitq);
> +   schedule();
> +}
> +
> +inline void init_tpmcmd(tpmcmd_t* tpmcmd, domid_t domid, unsigned int
> handle, char* uuid)
> +{
> +   tpmcmd->domid = domid;
> +   tpmcmd->handle = handle;
> +   tpmcmd->uuid = uuid;
> +   tpmcmd->req = NULL;
> +   tpmcmd->req_len = 0;
> +   tpmcmd->resp = NULL;
> +   tpmcmd->resp_len = 0;
> +}
> +
> +tpmcmd_t* get_request(tpmif_t* tpmif) {
> +   tpmcmd_t* cmd;
> +   tpmif_tx_request_t* tx;
> +   int offset;
> +   int tocopy;
> +   int i;
> +   uint32_t domid;
> +   int flags;
> +
> +   local_irq_save(flags);
> +
> +   /* Allocate the cmd object to hold the data */
> +   if((cmd = malloc(sizeof(*cmd))) == NULL) {
> +      goto error;
> +   }
> +   init_tpmcmd(cmd, tpmif->domid, tpmif->handle, tpmif->uuid);
> +
> +   tx = &tpmif->tx->ring[0].req;
> +   cmd->req_len = tx->size;
> +   /* Allocate the buffer */
> +   if(cmd->req_len) {
> +      if((cmd->req = malloc(cmd->req_len)) == NULL) {
> +     goto error;
> +      }
> +   }
> +   /* Copy the bits from the shared pages */
> +   offset = 0;
> +   for(i = 0; i < TPMIF_TX_RING_SIZE && offset < cmd->req_len; ++i) {
> +      tx = &tpmif->tx->ring[i].req;
> +
> +      /* Map the page with the data */
> +      domid = (uint32_t)tpmif->domid;
> +      if((tpmif->pages[i] = gntmap_map_grant_refs(&gtpmdev.map, 1,
> &domid, 0, &tx->ref, PROT_READ)) == NULL) {
> +     TPMBACK_ERR("%u/%u Unable to map shared page during read!\n",
> (unsigned int) tpmif->domid, tpmif->handle);
> +     goto error;
> +      }
> +
> +      /* do the copy now */
> +      tocopy = min(cmd->req_len - offset, PAGE_SIZE);
> +      memcpy(&cmd->req[offset], tpmif->pages[i], tocopy);
> +      offset += tocopy;
> +
> +      /* release the page */
> +      gntmap_munmap(&gtpmdev.map, (unsigned long)tpmif->pages[i], 1);
> +
> +   }
> +
> +#ifdef TPMBACK_PRINT_DEBUG
> +   TPMBACK_DEBUG("Received Tpm Command from %u/%u of size %u",
> (unsigned int) tpmif->domid, tpmif->handle, cmd->req_len);
> +   for(i = 0; i < cmd->req_len; ++i) {
> +      if (!(i % 30)) {
> +     TPMBACK_DEBUG_MORE("\n");
> +      }
> +      TPMBACK_DEBUG_MORE("%02hhX ", cmd->req[i]);
> +   }
> +   TPMBACK_DEBUG_MORE("\n\n");
> +#endif
> +
> +   local_irq_restore(flags);
> +   return cmd;
> +error:
> +   if(cmd != NULL) {
> +      if (cmd->req != NULL) {
> +     free(cmd->req);
> +     cmd->req = NULL;
> +      }
> +      free(cmd);
> +      cmd = NULL;
> +   }
> +   local_irq_restore(flags);
> +   return NULL;
> +
> +}
> +
> +void send_response(tpmcmd_t* cmd, tpmif_t* tpmif)
> +{
> +   tpmif_tx_request_t* tx;
> +   int offset;
> +   int i;
> +   uint32_t domid;
> +   int tocopy;
> +   int flags;
> +
> +   local_irq_save(flags);
> +
> +   tx = &tpmif->tx->ring[0].req;
> +   tx->size = cmd->resp_len;
> +
> +   offset = 0;
> +   for(i = 0; i < TPMIF_TX_RING_SIZE && offset < cmd->resp_len; ++i) {
> +      tx = &tpmif->tx->ring[i].req;
> +
> +      /* Map the page with the data */
> +      domid = (uint32_t)tpmif->domid;
> +      if((tpmif->pages[i] = gntmap_map_grant_refs(&gtpmdev.map, 1,
> &domid, 0, &tx->ref, PROT_WRITE)) == NULL) {
> +     TPMBACK_ERR("%u/%u Unable to map shared page during write!\n",
> (unsigned int) tpmif->domid, tpmif->handle);
> +     goto error;
> +      }
> +
> +      /* do the copy now */
> +      tocopy = min(cmd->resp_len - offset, PAGE_SIZE);
> +      memcpy(tpmif->pages[i], &cmd->resp[offset], tocopy);
> +      offset += tocopy;
> +
> +      /* release the page */
> +      gntmap_munmap(&gtpmdev.map, (unsigned long)tpmif->pages[i], 1);
> +
> +   }
> +
> +#ifdef TPMBACK_PRINT_DEBUG
> +   TPMBACK_DEBUG("Sent response to %u/%u of size %u", (unsigned int)
> tpmif->domid, tpmif->handle, cmd->resp_len);
> +   for(i = 0; i < cmd->resp_len; ++i) {
> +      if (!(i % 30)) {
> +     TPMBACK_DEBUG_MORE("\n");
> +      }
> +      TPMBACK_DEBUG_MORE("%02hhX ", cmd->resp[i]);
> +   }
> +   TPMBACK_DEBUG_MORE("\n\n");
> +#endif
> +   /* clear the ready flag and send the event channel notice to the
> frontend */
> +   tpmif_req_finished(tpmif);
> +   notify_remote_via_evtchn(tpmif->evtchn);
> +error:
> +   local_irq_restore(flags);
> +   return;
> +}
> +
> +tpmcmd_t* tpmback_req_any(void)
> +{
> +   int i;
> +   /* Block until something has a request */
> +   wait_event(waitq, (gtpmdev.flags & (TPMIF_REQ_READY | TPMIF_CLOSED)));
> +
> +   /* Check if were shutting down */
> +   if(gtpmdev.flags & TPMIF_CLOSED) {
> +      /* if something was waiting for us to give up the queue so it can
> shutdown, let it finish */
> +      schedule();
> +      return NULL;
> +   }
> +
> +   for(i = 0; i < gtpmdev.num_tpms; ++i) {
> +      if(gtpmdev.tpmlist[i]->flags & TPMIF_REQ_READY) {
> +     return get_request(gtpmdev.tpmlist[i]);
> +      }
> +   }
> +
> +   TPMBACK_ERR("backend request ready flag was set but no interfaces
> were actually ready\n");
> +   return NULL;
> +}
> +
> +tpmcmd_t* tpmback_req(domid_t domid, unsigned int handle)
> +{
> +   tpmif_t* tpmif;
> +   tpmif = get_tpmif(domid, handle);
> +   if(tpmif == NULL) {
> +      return NULL;
> +   }
> +
> +   wait_event(waitq, (tpmif->flags & (TPMIF_REQ_READY | TPMIF_CLOSED)
> || gtpmdev.flags & TPMIF_CLOSED));
> +
> +   /* Check if were shutting down */
> +   if(tpmif->flags & TPMIF_CLOSED || gtpmdev.flags & TPMIF_CLOSED) {
> +      /* if something was waiting for us to give up the queue so it can
> free this instance, let it finish */
> +      schedule();
> +      return NULL;
> +   }
> +
> +   return get_request(tpmif);
> +}
> +
> +void tpmback_resp(tpmcmd_t* tpmcmd)
> +{
> +   tpmif_t* tpmif;
> +
> +   /* Get the associated interface, if it doesnt exist then just quit */
> +   tpmif = get_tpmif(tpmcmd->domid, tpmcmd->handle);
> +   if(tpmif == NULL) {
> +      TPMBACK_ERR("Tried to send a reponse to non existant frontend
> %u/%u\n", (unsigned int) tpmcmd->domid, tpmcmd->handle);
> +      goto end;
> +   }
> +
> +   if(!(tpmif->flags & TPMIF_REQ_READY)) {
> +      TPMBACK_ERR("Tried to send response to a frontend that was not
> waiting for one %u/%u\n", (unsigned int) tpmcmd->domid, tpmcmd->handle);
> +      goto end;
> +   }
> +
> +   /* Send response to frontend */
> +   send_response(tpmcmd, tpmif);
> +
> +end:
> +   if(tpmcmd->req != NULL) {
> +      free(tpmcmd->req);
> +   }
> +   free(tpmcmd);
> +   return;
> +}
> +
> +int tpmback_wait_for_frontend_connect(domid_t *domid, unsigned int *handle)
> +{
> +   tpmif_t* tpmif;
> +   int flags;
> +   wait_event(waitq, ((gtpmdev.num_tpms > 0) || gtpmdev.flags &
> TPMIF_CLOSED));
> +   if(gtpmdev.flags & TPMIF_CLOSED) {
> +      return -1;
> +   }
> +   local_irq_save(flags);
> +   tpmif = gtpmdev.tpmlist[0];
> +   *domid = tpmif->domid;
> +   *handle = tpmif->handle;
> +   local_irq_restore(flags);
> +
> +   return 0;
> +}
> +
> +int tpmback_num_frontends(void)
> +{
> +   return gtpmdev.num_tpms;
> +}
> diff --git a/extras/mini-os/tpmfront.c b/extras/mini-os/tpmfront.c
> --- /dev/null
> +++ b/extras/mini-os/tpmfront.c
> @@ -0,0 +1,606 @@
> +/*
> + * Copyright (c) 2010-2012 United States Government, as represented by
> + * the Secretary of Defense.  All rights reserved.
> + *
> + * This driver 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 3 of the License, or
> + * (at your option) any later version.
> + *
> + * This driver is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program.  If not, see <http://www.gnu.org/licenses/>.
> + *
> + * Based upon the files:
> + *  drivers/char/tpm/tpm_vtpm.c
> + *  drivers/char/tpm/tpm_xen.c
> + * from the Linux kernel, which are Copyright (C) 2006 IBM Corporation
> + */
> +#include <mini-os/os.h>
> +#include <mini-os/xenbus.h>
> +#include <mini-os/xmalloc.h>
> +#include <mini-os/events.h>
> +#include <mini-os/wait.h>
> +#include <mini-os/gnttab.h>
> +#include <xen/io/xenbus.h>
> +#include <xen/io/tpmif.h>
> +#include <mini-os/tpmfront.h>
> +#include <fcntl.h>
> +
> +//#define TPMFRONT_PRINT_DEBUG
> +#ifdef TPMFRONT_PRINT_DEBUG
> +#define TPMFRONT_DEBUG(fmt,...) printk("Tpmfront:Debug("__FILE__":%d) "
> fmt, __LINE__, ##__VA_ARGS__)
> +#define TPMFRONT_DEBUG_MORE(fmt,...) printk(fmt, ##__VA_ARGS__)
> +#else
> +#define TPMFRONT_DEBUG(fmt,...)
> +#endif
> +#define TPMFRONT_ERR(fmt,...) printk("Tpmfront:Error " fmt, ##__VA_ARGS__)
> +#define TPMFRONT_LOG(fmt,...) printk("Tpmfront:Info " fmt, ##__VA_ARGS__)
> +
> +#define min(a,b) (((a) < (b)) ? (a) : (b))
> +
> +void tpmfront_handler(evtchn_port_t port, struct pt_regs *regs, void
> *data) {
> +   struct tpmfront_dev* dev = (struct tpmfront_dev*) data;
> +   /*If we get a response when we didnt make a request, just ignore it */
> +   if(!dev->waiting) {
> +      return;
> +   }
> +
> +   dev->waiting = 0;
> +#ifdef HAVE_LIBC
> +   if(dev->fd >= 0) {
> +      files[dev->fd].read = 1;
> +   }
> +#endif
> +   wake_up(&dev->waitq);
> +}
> +
> +static int publish_xenbus(struct tpmfront_dev* dev) {
> +   xenbus_transaction_t xbt;
> +   int retry;
> +   char* err;
> +   /* Write the grant reference and event channel to xenstore */
> +again:
> +   if((err = xenbus_transaction_start(&xbt))) {
> +      TPMFRONT_ERR("Unable to start xenbus transaction, error was
> %s\n", err);
> +      free(err);
> +      return -1;
> +   }
> +
> +   if((err = xenbus_printf(xbt, dev->nodename, "ring-ref", "%u",
> (unsigned int) dev->ring_ref))) {
> +      TPMFRONT_ERR("Unable to write %s/ring-ref, error was %s\n",
> dev->nodename, err);
> +      free(err);
> +      goto abort_transaction;
> +   }
> +
> +   if((err = xenbus_printf(xbt, dev->nodename, "event-channel", "%u",
> (unsigned int) dev->evtchn))) {
> +      TPMFRONT_ERR("Unable to write %s/event-channel, error was %s\n",
> dev->nodename, err);
> +      free(err);
> +      goto abort_transaction;
> +   }
> +
> +   if((err = xenbus_transaction_end(xbt, 0, &retry))) {
> +      TPMFRONT_ERR("Unable to complete xenbus transaction, error was
> %s\n", err);
> +      free(err);
> +      return -1;
> +   }
> +   if(retry) {
> +      goto again;
> +   }
> +
> +   return 0;
> +abort_transaction:
> +   if((err = xenbus_transaction_end(xbt, 1, &retry))) {
> +      free(err);
> +   }
> +   return -1;
> +}
> +
> +static int wait_for_backend_connect(xenbus_event_queue* events, char* path)
> +{
> +   int state;
> +
> +   TPMFRONT_LOG("Waiting for backend connection..\n");
> +   /* Wait for the backend to connect */
> +   while(1) {
> +      state = xenbus_read_integer(path);
> +      if ( state < 0)
> +     state = XenbusStateUnknown;
> +      switch(state) {
> +     /* Bad states, we quit with error */
> +     case XenbusStateUnknown:
> +     case XenbusStateClosing:
> +     case XenbusStateClosed:
> +        TPMFRONT_ERR("Unable to connect to backend\n");
> +        return -1;
> +     /* If backend is connected then break out of loop */
> +     case XenbusStateConnected:
> +        TPMFRONT_LOG("Backend Connected\n");
> +        return 0;
> +     default:
> +        xenbus_wait_for_watch(events);
> +      }
> +   }
> +
> +}
> +
> +static int wait_for_backend_closed(xenbus_event_queue* events, char* path)
> +{
> +   int state;
> +
> +   TPMFRONT_LOG("Waiting for backend to close..\n");
> +   while(1) {
> +      state = xenbus_read_integer(path);
> +      if ( state < 0)
> +     state = XenbusStateUnknown;
> +      switch(state) {
> +     case XenbusStateUnknown:
> +        TPMFRONT_ERR("Backend Unknown state, forcing shutdown\n");
> +        return -1;
> +     case XenbusStateClosed:
> +        TPMFRONT_LOG("Backend Closed\n");
> +        return 0;
> +     default:
> +        xenbus_wait_for_watch(events);
> +      }
> +   }
> +
> +}
> +
> +static int wait_for_backend_state_changed(struct tpmfront_dev* dev,
> XenbusState state) {
> +   char* err;
> +   int ret = 0;
> +   xenbus_event_queue events = NULL;
> +   char path[512];
> +
> +   snprintf(path, 512, "%s/state", dev->bepath);
> +   /*Setup the watch to wait for the backend */
> +   if((err = xenbus_watch_path_token(XBT_NIL, path, path, &events))) {
> +      TPMFRONT_ERR("Could not set a watch on %s, error was %s\n", path,
> err);
> +      free(err);
> +      return -1;
> +   }
> +
> +   /* Do the actual wait loop now */
> +   switch(state) {
> +      case XenbusStateConnected:
> +     ret = wait_for_backend_connect(&events, path);
> +     break;
> +      case XenbusStateClosed:
> +     ret = wait_for_backend_closed(&events, path);
> +     break;
> +      default:
> +     break;
> +   }
> +
> +   if((err = xenbus_unwatch_path_token(XBT_NIL, path, path))) {
> +      TPMFRONT_ERR("Unable to unwatch %s, error was %s, ignoring..\n",
> path, err);
> +      free(err);
> +   }
> +   return ret;
> +}
> +
> +static int tpmfront_connect(struct tpmfront_dev* dev)
> +{
> +   char* err;
> +   /* Create shared page */
> +   dev->tx = (tpmif_tx_interface_t*) alloc_page();
> +   if(dev->tx == NULL) {
> +      TPMFRONT_ERR("Unable to allocate page for shared memory\n");
> +      goto error;
> +   }
> +   memset(dev->tx, 0, PAGE_SIZE);
> +   dev->ring_ref = gnttab_grant_access(dev->bedomid,
> virt_to_mfn(dev->tx), 0);
> +   TPMFRONT_DEBUG("grant ref is %lu\n", (unsigned long) dev->ring_ref);
> +
> +   /*Create event channel */
> +   if(evtchn_alloc_unbound(dev->bedomid, tpmfront_handler, dev,
> &dev->evtchn)) {
> +      TPMFRONT_ERR("Unable to allocate event channel\n");
> +      goto error_postmap;
> +   }
> +   unmask_evtchn(dev->evtchn);
> +   TPMFRONT_DEBUG("event channel is %lu\n", (unsigned long) dev->evtchn);
> +
> +   /* Write the entries to xenstore */
> +   if(publish_xenbus(dev)) {
> +      goto error_postevtchn;
> +   }
> +
> +   /* Change state to connected */
> +   dev->state = XenbusStateConnected;
> +
> +   /* Tell the backend that we are ready */
> +   if((err = xenbus_printf(XBT_NIL, dev->nodename, "state", "%u",
> dev->state))) {
> +      TPMFRONT_ERR("Unable to write to xenstore %s/state, value=%u",
> dev->nodename, XenbusStateConnected);
> +      free(err);
> +      goto error;
> +   }
> +
> +   return 0;
> +error_postevtchn:
> +      mask_evtchn(dev->evtchn);
> +      unbind_evtchn(dev->evtchn);
> +error_postmap:
> +      gnttab_end_access(dev->ring_ref);
> +      free_page(dev->tx);
> +error:
> +   return -1;
> +}
> +
> +struct tpmfront_dev* init_tpmfront(const char* _nodename)
> +{
> +   struct tpmfront_dev* dev;
> +   const char* nodename;
> +   char path[512];
> +   char* value, *err;
> +   unsigned long long ival;
> +   int i;
> +
> +   printk("============= Init TPM Front ================\n");
> +
> +   dev = malloc(sizeof(struct tpmfront_dev));
> +   memset(dev, 0, sizeof(struct tpmfront_dev));
> +
> +#ifdef HAVE_LIBC
> +   dev->fd = -1;
> +#endif
> +
> +   nodename = _nodename ? _nodename : "device/vtpm/0";
> +   dev->nodename = strdup(nodename);
> +
> +   init_waitqueue_head(&dev->waitq);
> +
> +   /* Get backend domid */
> +   snprintf(path, 512, "%s/backend-id", dev->nodename);
> +   if((err = xenbus_read(XBT_NIL, path, &value))) {
> +      TPMFRONT_ERR("Unable to read %s during tpmfront initialization!
> error = %s\n", path, err);
> +      free(err);
> +      goto error;
> +   }
> +   if(sscanf(value, "%llu", &ival) != 1) {
> +      TPMFRONT_ERR("%s has non-integer value (%s)\n", path, value);
> +      free(value);
> +      goto error;
> +   }
> +   free(value);
> +   dev->bedomid = ival;
> +
> +   /* Get backend xenstore path */
> +   snprintf(path, 512, "%s/backend", dev->nodename);
> +   if((err = xenbus_read(XBT_NIL, path, &dev->bepath))) {
> +      TPMFRONT_ERR("Unable to read %s during tpmfront initialization!
> error = %s\n", path, err);
> +      free(err);
> +      goto error;
> +   }
> +
> +   /* Create and publish grant reference and event channel */
> +   if (tpmfront_connect(dev)) {
> +      goto error;
> +   }
> +
> +   /* Wait for backend to connect */
> +   if( wait_for_backend_state_changed(dev, XenbusStateConnected)) {
> +      goto error;
> +   }
> +
> +   /* Allocate pages that will contain the messages */
> +   dev->pages = malloc(sizeof(void*) * TPMIF_TX_RING_SIZE);
> +   if(dev->pages == NULL) {
> +      goto error;
> +   }
> +   memset(dev->pages, 0, sizeof(void*) * TPMIF_TX_RING_SIZE);
> +   for(i = 0; i < TPMIF_TX_RING_SIZE; ++i) {
> +      dev->pages[i] = (void*)alloc_page();
> +      if(dev->pages[i] == NULL) {
> +     goto error;
> +      }
> +   }
> +
> +   TPMFRONT_LOG("Initialization Completed successfully\n");
> +
> +   return dev;
> +
> +error:
> +   shutdown_tpmfront(dev);
> +   return NULL;
> +}
> +void shutdown_tpmfront(struct tpmfront_dev* dev)
> +{
> +   char* err;
> +   char path[512];
> +   int i;
> +   tpmif_tx_request_t* tx;
> +   if(dev == NULL) {
> +      return;
> +   }
> +   TPMFRONT_LOG("Shutting down tpmfront\n");
> +   /* disconnect */
> +   if(dev->state == XenbusStateConnected) {
> +      dev->state = XenbusStateClosing;
> +      //FIXME: Transaction for this?
> +      /* Tell backend we are closing */
> +      if((err = xenbus_printf(XBT_NIL, dev->nodename, "state", "%u",
> (unsigned int) dev->state))) {
> +     free(err);
> +      }
> +
> +      /* Clean up xenstore entries */
> +      snprintf(path, 512, "%s/event-channel", dev->nodename);
> +      if((err = xenbus_rm(XBT_NIL, path))) {
> +     free(err);
> +      }
> +      snprintf(path, 512, "%s/ring-ref", dev->nodename);
> +      if((err = xenbus_rm(XBT_NIL, path))) {
> +     free(err);
> +      }
> +
> +      /* Tell backend we are closed */
> +      dev->state = XenbusStateClosed;
> +      if((err = xenbus_printf(XBT_NIL, dev->nodename, "state", "%u",
> (unsigned int) dev->state))) {
> +     TPMFRONT_ERR("Unable to write to %s, error was %s", dev->nodename,
> err);
> +     free(err);
> +      }
> +
> +      /* Wait for the backend to close and unmap shared pages, ignore
> any errors */
> +      wait_for_backend_state_changed(dev, XenbusStateClosed);
> +
> +      /* Cleanup any shared pages */
> +      if(dev->pages) {
> +     for(i = 0; i < TPMIF_TX_RING_SIZE; ++i) {
> +        if(dev->pages[i]) {
> +           tx = &dev->tx->ring[i].req;
> +           if(tx->ref != 0) {
> +          gnttab_end_access(tx->ref);
> +           }
> +           free_page(dev->pages[i]);
> +        }
> +     }
> +     free(dev->pages);
> +      }
> +
> +      /* Close event channel and unmap shared page */
> +      mask_evtchn(dev->evtchn);
> +      unbind_evtchn(dev->evtchn);
> +      gnttab_end_access(dev->ring_ref);
> +
> +      free_page(dev->tx);
> +
> +   }
> +
> +   /* Cleanup memory usage */
> +   if(dev->respbuf) {
> +      free(dev->respbuf);
> +   }
> +   if(dev->bepath) {
> +      free(dev->bepath);
> +   }
> +   if(dev->nodename) {
> +      free(dev->nodename);
> +   }
> +   free(dev);
> +}
> +
> +int tpmfront_send(struct tpmfront_dev* dev, const uint8_t* msg, size_t
> length)
> +{
> +   int i;
> +   tpmif_tx_request_t* tx = NULL;
> +   /* Error Checking */
> +   if(dev == NULL || dev->state != XenbusStateConnected) {
> +      TPMFRONT_ERR("Tried to send message through disconnected
> frontend\n");
> +      return -1;
> +   }
> +
> +#ifdef TPMFRONT_PRINT_DEBUG
> +   TPMFRONT_DEBUG("Sending Msg to backend size=%u", (unsigned int) length);
> +   for(i = 0; i < length; ++i) {
> +      if(!(i % 30)) {
> +     TPMFRONT_DEBUG_MORE("\n");
> +      }
> +      TPMFRONT_DEBUG_MORE("%02X ", msg[i]);
> +   }
> +   TPMFRONT_DEBUG_MORE("\n");
> +#endif
> +
> +   /* Copy to shared pages now */
> +   for(i = 0; length > 0 && i < TPMIF_TX_RING_SIZE; ++i) {
> +      /* Share the page */
> +      tx = &dev->tx->ring[i].req;
> +      tx->unused = 0;
> +      tx->addr = virt_to_mach(dev->pages[i]);
> +      tx->ref = gnttab_grant_access(dev->bedomid,
> virt_to_mfn(dev->pages[i]), 0);
> +      /* Copy the bits to the page */
> +      tx->size = length > PAGE_SIZE ? PAGE_SIZE : length;
> +      memcpy(dev->pages[i], &msg[i * PAGE_SIZE], tx->size);
> +
> +      /* Update counters */
> +      length -= tx->size;
> +   }
> +   dev->waiting = 1;
> +   dev->resplen = 0;
> +#ifdef HAVE_LIBC
> +   if(dev->fd >= 0) {
> +      files[dev->fd].read = 0;
> +      files[dev->fd].tpmfront.respgot = 0;
> +      files[dev->fd].tpmfront.offset = 0;
> +   }
> +#endif
> +   notify_remote_via_evtchn(dev->evtchn);
> +   return 0;
> +}
> +int tpmfront_recv(struct tpmfront_dev* dev, uint8_t** msg, size_t *length)
> +{
> +   tpmif_tx_request_t* tx;
> +   int i;
> +   if(dev == NULL || dev->state != XenbusStateConnected) {
> +      TPMFRONT_ERR("Tried to receive message from disconnected
> frontend\n");
> +      return -1;
> +   }
> +   /*Wait for the response */
> +   wait_event(dev->waitq, (!dev->waiting));
> +
> +   /* Initialize */
> +   *msg = NULL;
> +   *length = 0;
> +
> +   /* special case, just quit */
> +   tx = &dev->tx->ring[0].req;
> +   if(tx->size == 0 ) {
> +       goto quit;
> +   }
> +   /* Get the total size */
> +   tx = &dev->tx->ring[0].req;
> +   for(i = 0; i < TPMIF_TX_RING_SIZE && tx->size > 0; ++i) {
> +      tx = &dev->tx->ring[i].req;
> +      *length += tx->size;
> +   }
> +   /* Alloc the buffer */
> +   if(dev->respbuf) {
> +      free(dev->respbuf);
> +   }
> +   *msg = dev->respbuf = malloc(*length);
> +   dev->resplen = *length;
> +   /* Copy the bits */
> +   tx = &dev->tx->ring[0].req;
> +   for(i = 0; i < TPMIF_TX_RING_SIZE && tx->size > 0; ++i) {
> +      tx = &dev->tx->ring[i].req;
> +      memcpy(&(*msg)[i * PAGE_SIZE], dev->pages[i], tx->size);
> +      gnttab_end_access(tx->ref);
> +      tx->ref = 0;
> +   }
> +#ifdef TPMFRONT_PRINT_DEBUG
> +   TPMFRONT_DEBUG("Received response from backend size=%u", (unsigned
> int) *length);
> +   for(i = 0; i < *length; ++i) {
> +      if(!(i % 30)) {
> +     TPMFRONT_DEBUG_MORE("\n");
> +      }
> +      TPMFRONT_DEBUG_MORE("%02X ", (*msg)[i]);
> +   }
> +   TPMFRONT_DEBUG_MORE("\n");
> +#endif
> +#ifdef HAVE_LIBC
> +   if(dev->fd >= 0) {
> +      files[dev->fd].tpmfront.respgot = 1;
> +   }
> +#endif
> +quit:
> +   return 0;
> +}
> +
> +int tpmfront_cmd(struct tpmfront_dev* dev, uint8_t* req, size_t reqlen,
> uint8_t** resp, size_t* resplen)
> +{
> +   int rc;
> +   if((rc = tpmfront_send(dev, req, reqlen))) {
> +      return rc;
> +   }
> +   if((rc = tpmfront_recv(dev, resp, resplen))) {
> +      return rc;
> +   }
> +
> +   return 0;
> +}
> +
> +#ifdef HAVE_LIBC
> +#include <errno.h>
> +int tpmfront_open(struct tpmfront_dev* dev)
> +{
> +   /* Silently prevent multiple opens */
> +   if(dev->fd != -1) {
> +      return dev->fd;
> +   }
> +
> +   dev->fd = alloc_fd(FTYPE_TPMFRONT);
> +   printk("tpmfront_open(%s) -> %d\n", dev->nodename, dev->fd);
> +   files[dev->fd].tpmfront.dev = dev;
> +   files[dev->fd].tpmfront.offset = 0;
> +   files[dev->fd].tpmfront.respgot = 0;
> +   return dev->fd;
> +}
> +
> +int tpmfront_posix_write(int fd, const uint8_t* buf, size_t count)
> +{
> +   int rc;
> +   struct tpmfront_dev* dev;
> +   dev = files[fd].tpmfront.dev;
> +
> +   if(count == 0) {
> +      return 0;
> +   }
> +
> +   /* Return an error if we are already processing a command */
> +   if(dev->waiting) {
> +      errno = EINPROGRESS;
> +      return -1;
> +   }
> +   /* Send the command now */
> +   if((rc = tpmfront_send(dev, buf, count)) != 0) {
> +      errno = EIO;
> +      return -1;
> +   }
> +   return count;
> +}
> +
> +int tpmfront_posix_read(int fd, uint8_t* buf, size_t count)
> +{
> +   int rc;
> +   uint8_t* dummybuf;
> +   size_t dummysz;
> +   struct tpmfront_dev* dev;
> +
> +   dev = files[fd].tpmfront.dev;
> +
> +   if(count == 0) {
> +      return 0;
> +   }
> +
> +   /* get the response if we haven't already */
> +   if(files[dev->fd].tpmfront.respgot == 0) {
> +      if ((rc = tpmfront_recv(dev, &dummybuf, &dummysz)) != 0) {
> +     errno = EIO;
> +     return -1;
> +      }
> +   }
> +
> +   /* handle EOF case */
> +   if(files[dev->fd].tpmfront.offset >= dev->resplen) {
> +      return 0;
> +   }
> +
> +   /* Compute the number of bytes and do the copy operation */
> +   if((rc = min(count, dev->resplen - files[dev->fd].tpmfront.offset))
> != 0) {
> +      memcpy(buf, dev->respbuf + files[dev->fd].tpmfront.offset, rc);
> +      files[dev->fd].tpmfront.offset += rc;
> +   }
> +
> +   return rc;
> +}
> +
> +int tpmfront_posix_fstat(int fd, struct stat* buf)
> +{
> +   uint8_t* dummybuf;
> +   size_t dummysz;
> +   int rc;
> +   struct tpmfront_dev* dev = files[fd].tpmfront.dev;
> +
> +   /* If we have a response waiting, then read it now from the backend
> +    * so we can get its length*/
> +   if(dev->waiting || (files[dev->fd].read == 1 &&
> !files[dev->fd].tpmfront.respgot)) {
> +      if ((rc = tpmfront_recv(dev, &dummybuf, &dummysz)) != 0) {
> +     errno = EIO;
> +     return -1;
> +      }
> +   }
> +
> +   buf->st_mode = O_RDWR;
> +   buf->st_uid = 0;
> +   buf->st_gid = 0;
> +   buf->st_size = dev->resplen;
> +   buf->st_atime = buf->st_mtime = buf->st_ctime = time(NULL);
> +
> +   return 0;
> +}
> +
> +
> +#endif
> --
> 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 Wed Sep 26 13:27:09 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Sep 2012 13:27:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGrdj-000561-P2; Wed, 26 Sep 2012 13:26:59 +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 1TGrdi-00055l-7i
	for xen-devel@lists.xen.org; Wed, 26 Sep 2012 13:26:58 +0000
Received: from [85.158.139.83:43351] by server-6.bemta-5.messagelabs.com id
	11/58-14717-1A203605; Wed, 26 Sep 2012 13:26:57 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1348666015!27943302!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzE2MjI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16273 invoked from network); 26 Sep 2012 13:26:56 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-14.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Sep 2012 13:26:56 -0000
X-IronPort-AV: E=Sophos;i="4.80,490,1344211200"; d="scan'208";a="39221469"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Sep 2012 13:26:55 +0000
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.279.1; Wed, 26 Sep 2012
	09:26:54 -0400
Message-ID: <5063029D.3090305@citrix.com>
Date: Wed, 26 Sep 2012 14:26: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 Iceowl/1.0b1 Icedove/3.0.11
MIME-Version: 1.0
To: Paul Durrant <paul.durrant@citrix.com>
References: <1348662212-3559-1-git-send-email-paul.durrant@citrix.com>
	<1348662212-3559-2-git-send-email-paul.durrant@citrix.com>
In-Reply-To: <1348662212-3559-2-git-send-email-paul.durrant@citrix.com>
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 1/2] Add a new pvdrivers header to serve as
 the	register of product numbers.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 26/09/12 13:23, Paul Durrant wrote:
> 
> + * During development, you may use the product ID to
                                     ^ EXPERIMENTAL ?
> + * indicate a driver which is yet to be released.

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 26 13:27:09 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Sep 2012 13:27:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGrdj-000561-P2; Wed, 26 Sep 2012 13:26:59 +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 1TGrdi-00055l-7i
	for xen-devel@lists.xen.org; Wed, 26 Sep 2012 13:26:58 +0000
Received: from [85.158.139.83:43351] by server-6.bemta-5.messagelabs.com id
	11/58-14717-1A203605; Wed, 26 Sep 2012 13:26:57 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1348666015!27943302!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzE2MjI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16273 invoked from network); 26 Sep 2012 13:26:56 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-14.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Sep 2012 13:26:56 -0000
X-IronPort-AV: E=Sophos;i="4.80,490,1344211200"; d="scan'208";a="39221469"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Sep 2012 13:26:55 +0000
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.279.1; Wed, 26 Sep 2012
	09:26:54 -0400
Message-ID: <5063029D.3090305@citrix.com>
Date: Wed, 26 Sep 2012 14:26: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 Iceowl/1.0b1 Icedove/3.0.11
MIME-Version: 1.0
To: Paul Durrant <paul.durrant@citrix.com>
References: <1348662212-3559-1-git-send-email-paul.durrant@citrix.com>
	<1348662212-3559-2-git-send-email-paul.durrant@citrix.com>
In-Reply-To: <1348662212-3559-2-git-send-email-paul.durrant@citrix.com>
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 1/2] Add a new pvdrivers header to serve as
 the	register of product numbers.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 26/09/12 13:23, Paul Durrant wrote:
> 
> + * During development, you may use the product ID to
                                     ^ EXPERIMENTAL ?
> + * indicate a driver which is yet to be released.

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 26 13:30:36 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Sep 2012 13:30:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGrh5-0005MO-Ds; Wed, 26 Sep 2012 13:30:27 +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 1TGrh3-0005MI-Cg
	for xen-devel@lists.xensource.com; Wed, 26 Sep 2012 13:30:25 +0000
Received: from [85.158.138.51:55267] by server-15.bemta-3.messagelabs.com id
	6D/86-18313-07303605; Wed, 26 Sep 2012 13:30:24 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1348666223!24450467!1
X-Originating-IP: [209.85.215.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29622 invoked from network); 26 Sep 2012 13:30:24 -0000
Received: from mail-ey0-f171.google.com (HELO mail-ey0-f171.google.com)
	(209.85.215.171)
	by server-10.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Sep 2012 13:30:24 -0000
Received: by eaah11 with SMTP id h11so238508eaa.30
	for <xen-devel@lists.xensource.com>;
	Wed, 26 Sep 2012 06:30:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
	bh=Fog+3j4UygHGCypaxnPNgcLNgQGmirtCzobFaIHlFmg=;
	b=iN+tIfWFBKn4QHDvgkv/oIOAYbR+tCQz3rf0hEEmDWEBr/c4lBL1XCriud4tT/dAiK
	B3Fgc8k5vogtkxWYdRnraguLcmtsHewSgcdZ4DVnuBRzHceSvvnvaTKQDtgMS36Tz+Ph
	ztW9bbH6bv2X0vu8O9XctJIw/rCYVQadu+Bcll3pqMMqcuJW9d45i3Zn9ZM/4CHyvrEj
	fZoMajqWvbbl0jd691N74nJp0iFVuB5tak5+YSQAic/qWz/xEig9SzAw/P+RX7foPs/1
	eW8zR8jwOTzRvMPlbbdE3UbMFFm6deVhQNoCVuXWng2Mlq4J2RfNi4KlvqSIm5GM5UxD
	peqw==
MIME-Version: 1.0
Received: by 10.14.212.72 with SMTP id x48mr910167eeo.40.1348666223588; Wed,
	26 Sep 2012 06:30:23 -0700 (PDT)
Received: by 10.14.215.195 with HTTP; Wed, 26 Sep 2012 06:30:23 -0700 (PDT)
In-Reply-To: <5058BC47.8070907@jhuapl.edu>
References: <50579F53.4070302@jhuapl.edu>
	<20120917225245.GP5110@type.youpi.perso.aquilenet.fr>
	<5058BC47.8070907@jhuapl.edu>
Date: Wed, 26 Sep 2012 14:30:23 +0100
X-Google-Sender-Auth: 879Vu17K9ZPwGYDDdCjp10rz0ko
Message-ID: <CAFLBxZZMR1AdaaJN=BNPsmjYFcFV13RLCwS8_JLFqukfFZy96w@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
Cc: Samuel Thibault <samuel.thibault@ens-lyon.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH mini-os enhancements for vtpm 8/8] Add 3 tpm
 drivers to mini-os
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Sep 18, 2012 at 7:24 PM, Matthew Fioravante
<matthew.fioravante@jhuapl.edu> wrote:
> Is there anyone on the dev list that is familiar enough to review it?
>
> I can tell you we have been using all 3 of these drivers internally for
> about 2 years now without issue. All of them are basically ports of the
> linux drivers to mini-os.

If you're willing to be the TPM maintainer (which would involve adding
your name to the MAINTAINERS file), and if Samuel is OK with you
owning the tpm-related files in stubdom, I think it wouldn't
necessarily need a thorough review to get in, as long as people are
happy with how it integrates with the rest of the code.  What do
people think?

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 26 13:30:36 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Sep 2012 13:30:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGrh5-0005MO-Ds; Wed, 26 Sep 2012 13:30:27 +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 1TGrh3-0005MI-Cg
	for xen-devel@lists.xensource.com; Wed, 26 Sep 2012 13:30:25 +0000
Received: from [85.158.138.51:55267] by server-15.bemta-3.messagelabs.com id
	6D/86-18313-07303605; Wed, 26 Sep 2012 13:30:24 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1348666223!24450467!1
X-Originating-IP: [209.85.215.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29622 invoked from network); 26 Sep 2012 13:30:24 -0000
Received: from mail-ey0-f171.google.com (HELO mail-ey0-f171.google.com)
	(209.85.215.171)
	by server-10.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Sep 2012 13:30:24 -0000
Received: by eaah11 with SMTP id h11so238508eaa.30
	for <xen-devel@lists.xensource.com>;
	Wed, 26 Sep 2012 06:30:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
	bh=Fog+3j4UygHGCypaxnPNgcLNgQGmirtCzobFaIHlFmg=;
	b=iN+tIfWFBKn4QHDvgkv/oIOAYbR+tCQz3rf0hEEmDWEBr/c4lBL1XCriud4tT/dAiK
	B3Fgc8k5vogtkxWYdRnraguLcmtsHewSgcdZ4DVnuBRzHceSvvnvaTKQDtgMS36Tz+Ph
	ztW9bbH6bv2X0vu8O9XctJIw/rCYVQadu+Bcll3pqMMqcuJW9d45i3Zn9ZM/4CHyvrEj
	fZoMajqWvbbl0jd691N74nJp0iFVuB5tak5+YSQAic/qWz/xEig9SzAw/P+RX7foPs/1
	eW8zR8jwOTzRvMPlbbdE3UbMFFm6deVhQNoCVuXWng2Mlq4J2RfNi4KlvqSIm5GM5UxD
	peqw==
MIME-Version: 1.0
Received: by 10.14.212.72 with SMTP id x48mr910167eeo.40.1348666223588; Wed,
	26 Sep 2012 06:30:23 -0700 (PDT)
Received: by 10.14.215.195 with HTTP; Wed, 26 Sep 2012 06:30:23 -0700 (PDT)
In-Reply-To: <5058BC47.8070907@jhuapl.edu>
References: <50579F53.4070302@jhuapl.edu>
	<20120917225245.GP5110@type.youpi.perso.aquilenet.fr>
	<5058BC47.8070907@jhuapl.edu>
Date: Wed, 26 Sep 2012 14:30:23 +0100
X-Google-Sender-Auth: 879Vu17K9ZPwGYDDdCjp10rz0ko
Message-ID: <CAFLBxZZMR1AdaaJN=BNPsmjYFcFV13RLCwS8_JLFqukfFZy96w@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
Cc: Samuel Thibault <samuel.thibault@ens-lyon.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH mini-os enhancements for vtpm 8/8] Add 3 tpm
 drivers to mini-os
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Sep 18, 2012 at 7:24 PM, Matthew Fioravante
<matthew.fioravante@jhuapl.edu> wrote:
> Is there anyone on the dev list that is familiar enough to review it?
>
> I can tell you we have been using all 3 of these drivers internally for
> about 2 years now without issue. All of them are basically ports of the
> linux drivers to mini-os.

If you're willing to be the TPM maintainer (which would involve adding
your name to the MAINTAINERS file), and if Samuel is OK with you
owning the tpm-related files in stubdom, I think it wouldn't
necessarily need a thorough review to get in, as long as people are
happy with how it integrates with the rest of the code.  What do
people think?

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 26 13:31:56 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Sep 2012 13:31:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGriK-0005Su-Tf; Wed, 26 Sep 2012 13:31:44 +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 1TGriJ-0005Si-52
	for xen-devel@lists.xen.org; Wed, 26 Sep 2012 13:31:43 +0000
Received: from [85.158.137.99:29100] by server-12.bemta-3.messagelabs.com id
	89/DD-23730-EB303605; Wed, 26 Sep 2012 13:31:42 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-3.tower-217.messagelabs.com!1348666299!14145578!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzE2MjI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8842 invoked from network); 26 Sep 2012 13:31:41 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-3.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Sep 2012 13:31:41 -0000
X-IronPort-AV: E=Sophos;i="4.80,490,1344211200"; d="scan'208";a="39222279"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Sep 2012 13:31:39 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 26 Sep 2012 09:31:39 -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 1TGriE-00053j-Ix;
	Wed, 26 Sep 2012 14:31:38 +0100
From: Anthony PERARD <anthony.perard@citrix.com>
To: Xen Devel <xen-devel@lists.xen.org>
Date: Wed, 26 Sep 2012 14:31:33 +0100
Message-ID: <1348666294-18182-2-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.12.1
In-Reply-To: <1348666294-18182-1-git-send-email-anthony.perard@citrix.com>
References: <1348666294-18182-1-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Cc: Anthony PERARD <anthony.perard@citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH 1/2] libxl_json: Use libxl alloc 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 patch makes use of the libxl allocation API and removes the check for
allocation failure.

This patch also assume that flexarray does not need to be freed as it will be
gc'd in the next patch.

Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
 tools/libxl/libxl_internal.h |   1 -
 tools/libxl/libxl_json.c     | 135 ++++++-------------------------------------
 tools/libxl/libxl_qmp.c      |   1 -
 3 files changed, 18 insertions(+), 119 deletions(-)

diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index b6f54ba..55fa771 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -1519,7 +1519,6 @@ libxl__json_map_node *libxl__json_map_node_get(const libxl__json_object *o,
 _hidden const libxl__json_object *libxl__json_map_get(const char *key,
                                           const libxl__json_object *o,
                                           libxl__json_node_type expected_type);
-_hidden void libxl__json_object_free(libxl__gc *gc, libxl__json_object *obj);
 
 _hidden libxl__json_object *libxl__json_parse(libxl__gc *gc, const char *s);
 
diff --git a/tools/libxl/libxl_json.c b/tools/libxl/libxl_json.c
index 8e17842..25df4a9 100644
--- a/tools/libxl/libxl_json.c
+++ b/tools/libxl/libxl_json.c
@@ -210,23 +210,12 @@ static libxl__json_object *json_object_alloc(libxl__gc *gc,
 {
     libxl__json_object *obj;
 
-    obj = calloc(1, sizeof (libxl__json_object));
-    if (obj == NULL) {
-        LIBXL__LOG_ERRNO(libxl__gc_owner(gc), LIBXL__LOG_ERROR,
-                         "Failed to allocate a libxl__json_object");
-        return NULL;
-    }
+    obj = libxl__zalloc(gc, sizeof(*obj));
 
     obj->type = type;
 
     if (type == JSON_MAP || type == JSON_ARRAY) {
         flexarray_t *array = flexarray_make(1, 1);
-        if (array == NULL) {
-            LIBXL__LOG_ERRNO(libxl__gc_owner(gc), LIBXL__LOG_ERROR,
-                             "Failed to allocate a flexarray");
-            free(obj);
-            return NULL;
-        }
         if (type == JSON_MAP)
             obj->u.map = array;
         else
@@ -256,11 +245,7 @@ static int json_object_append_to(libxl__gc *gc,
         break;
     }
     case JSON_ARRAY:
-        if (flexarray_append(dst->u.array, obj) == 2) {
-            LIBXL__LOG_ERRNO(libxl__gc_owner(gc), LIBXL__LOG_ERROR,
-                             "Failed to grow a flexarray");
-            return -1;
-        }
+        flexarray_append(dst->u.array, obj);
         break;
     default:
         LIBXL__LOG(libxl__gc_owner(gc), LIBXL__LOG_ERROR,
@@ -273,50 +258,6 @@ static int json_object_append_to(libxl__gc *gc,
     return 0;
 }
 
-void libxl__json_object_free(libxl__gc *gc, libxl__json_object *obj)
-{
-    int idx = 0;
-
-    if (obj == NULL)
-        return;
-    switch (obj->type) {
-    case JSON_STRING:
-    case JSON_NUMBER:
-        free(obj->u.string);
-        break;
-    case JSON_MAP: {
-        libxl__json_map_node *node = NULL;
-
-        for (idx = 0; idx < obj->u.map->count; idx++) {
-            if (flexarray_get(obj->u.map, idx, (void**)&node) != 0)
-                break;
-            libxl__json_object_free(gc, node->obj);
-            free(node->map_key);
-            free(node);
-            node = NULL;
-        }
-        flexarray_free(obj->u.map);
-        break;
-    }
-    case JSON_ARRAY: {
-        libxl__json_object *node = NULL;
-        break;
-
-        for (idx = 0; idx < obj->u.array->count; idx++) {
-            if (flexarray_get(obj->u.array, idx, (void**)&node) != 0)
-                break;
-            libxl__json_object_free(gc, node);
-            node = NULL;
-        }
-        flexarray_free(obj->u.array);
-        break;
-    }
-    default:
-        break;
-    }
-    free(obj);
-}
-
 libxl__json_object *libxl__json_array_get(const libxl__json_object *o, int i)
 {
     flexarray_t *array = NULL;
@@ -393,11 +334,9 @@ static int json_callback_null(void *opaque)
 
     DEBUG_GEN(ctx, null);
 
-    if ((obj = json_object_alloc(ctx->gc, JSON_NULL)) == NULL)
-        return 0;
+    obj = json_object_alloc(ctx->gc, JSON_NULL);
 
     if (json_object_append_to(ctx->gc, obj, ctx->current) == -1) {
-        libxl__json_object_free(ctx->gc, obj);
         return 0;
     }
 
@@ -411,12 +350,10 @@ static int json_callback_boolean(void *opaque, int boolean)
 
     DEBUG_GEN_VALUE(ctx, bool, boolean);
 
-    if ((obj = json_object_alloc(ctx->gc,
-                                 boolean ? JSON_TRUE : JSON_FALSE)) == NULL)
-        return 0;
+    obj = json_object_alloc(ctx->gc,
+                            boolean ? JSON_TRUE : JSON_FALSE);
 
     if (json_object_append_to(ctx->gc, obj, ctx->current) == -1) {
-        libxl__json_object_free(ctx->gc, obj);
         return 0;
     }
 
@@ -448,8 +385,7 @@ static int json_callback_number(void *opaque, const char *s, libxl_yajl_length l
             goto error;
         }
 
-        if ((obj = json_object_alloc(ctx->gc, JSON_DOUBLE)) == NULL)
-            return 0;
+        obj = json_object_alloc(ctx->gc, JSON_DOUBLE);
         obj->u.d = d;
     } else {
         long long i = strtoll(s, NULL, 10);
@@ -458,23 +394,16 @@ static int json_callback_number(void *opaque, const char *s, libxl_yajl_length l
             goto error;
         }
 
-        if ((obj = json_object_alloc(ctx->gc, JSON_INTEGER)) == NULL)
-            return 0;
+        obj = json_object_alloc(ctx->gc, JSON_INTEGER);
         obj->u.i = i;
     }
     goto out;
 
 error:
     /* If the conversion fail, we just store the original string. */
-    if ((obj = json_object_alloc(ctx->gc, JSON_NUMBER)) == NULL)
-        return 0;
+    obj = json_object_alloc(ctx->gc, JSON_NUMBER);
 
-    t = malloc(len + 1);
-    if (t == NULL) {
-        LIBXL__LOG_ERRNO(libxl__gc_owner(ctx->gc), LIBXL__LOG_ERROR,
-                         "Failed to allocate");
-        return 0;
-    }
+    t = libxl__zalloc(ctx->gc, len + 1);
     strncpy(t, s, len);
     t[len] = 0;
 
@@ -482,7 +411,6 @@ error:
 
 out:
     if (json_object_append_to(ctx->gc, obj, ctx->current) == -1) {
-        libxl__json_object_free(ctx->gc, obj);
         return 0;
     }
 
@@ -496,26 +424,17 @@ static int json_callback_string(void *opaque, const unsigned char *str,
     char *t = NULL;
     libxl__json_object *obj = NULL;
 
-    t = malloc(len + 1);
-    if (t == NULL) {
-        LIBXL__LOG_ERRNO(libxl__gc_owner(ctx->gc), LIBXL__LOG_ERROR,
-                         "Failed to allocate");
-        return 0;
-    }
+    t = libxl__zalloc(ctx->gc, len + 1);
 
     DEBUG_GEN_STRING(ctx, str, len);
 
     strncpy(t, (const char *) str, len);
     t[len] = 0;
 
-    if ((obj = json_object_alloc(ctx->gc, JSON_STRING)) == NULL) {
-        free(t);
-        return 0;
-    }
+    obj = json_object_alloc(ctx->gc, JSON_STRING);
     obj->u.string = t;
 
     if (json_object_append_to(ctx->gc, obj, ctx->current) == -1) {
-        libxl__json_object_free(ctx->gc, obj);
         return 0;
     }
 
@@ -528,13 +447,9 @@ static int json_callback_map_key(void *opaque, const unsigned char *str,
     libxl__yajl_ctx *ctx = opaque;
     char *t = NULL;
     libxl__json_object *obj = ctx->current;
+    libxl__gc *gc = ctx->gc;
 
-    t = malloc(len + 1);
-    if (t == NULL) {
-        LIBXL__LOG_ERRNO(libxl__gc_owner(ctx->gc), LIBXL__LOG_ERROR,
-                         "Failed to allocate");
-        return 0;
-    }
+    t = libxl__zalloc(gc, len + 1);
 
     DEBUG_GEN_STRING(ctx, str, len);
 
@@ -542,21 +457,13 @@ static int json_callback_map_key(void *opaque, const unsigned char *str,
     t[len] = 0;
 
     if (libxl__json_object_is_map(obj)) {
-        libxl__json_map_node *node = malloc(sizeof (libxl__json_map_node));
-        if (node == NULL) {
-            LIBXL__LOG_ERRNO(libxl__gc_owner(ctx->gc), LIBXL__LOG_ERROR,
-                             "Failed to allocate");
-            return 0;
-        }
+        libxl__json_map_node *node;
 
+        GCNEW(node);
         node->map_key = t;
         node->obj = NULL;
 
-        if (flexarray_append(obj->u.map, node) == 2) {
-            LIBXL__LOG_ERRNO(libxl__gc_owner(ctx->gc), LIBXL__LOG_ERROR,
-                             "Failed to grow a flexarray");
-            return 0;
-        }
+        flexarray_append(obj->u.map, node);
     } else {
         LIBXL__LOG(libxl__gc_owner(ctx->gc), LIBXL__LOG_ERROR,
                    "Current json object is not a map");
@@ -573,12 +480,10 @@ static int json_callback_start_map(void *opaque)
 
     DEBUG_GEN(ctx, map_open);
 
-    if ((obj = json_object_alloc(ctx->gc, JSON_MAP)) == NULL)
-        return 0;
+    obj = json_object_alloc(ctx->gc, JSON_MAP);
 
     if (ctx->current) {
         if (json_object_append_to(ctx->gc, obj, ctx->current) == -1) {
-            libxl__json_object_free(ctx->gc, obj);
             return 0;
         }
     }
@@ -615,12 +520,10 @@ static int json_callback_start_array(void *opaque)
 
     DEBUG_GEN(ctx, array_open);
 
-    if ((obj = json_object_alloc(ctx->gc, JSON_ARRAY)) == NULL)
-        return 0;
+    obj = json_object_alloc(ctx->gc, JSON_ARRAY);
 
     if (ctx->current) {
         if (json_object_append_to(ctx->gc, obj, ctx->current) == -1) {
-            libxl__json_object_free(ctx->gc, obj);
             return 0;
         }
     }
@@ -710,8 +613,6 @@ out:
 
     LIBXL__LOG(libxl__gc_owner(gc), LIBXL__LOG_ERROR, "yajl error: %s", str);
     yajl_free_error(yajl_ctx.hand, str);
-
-    libxl__json_object_free(gc, yajl_ctx.head);
     yajl_ctx_free(&yajl_ctx);
     return NULL;
 }
diff --git a/tools/libxl/libxl_qmp.c b/tools/libxl/libxl_qmp.c
index 2c4d269..0757fc2 100644
--- a/tools/libxl/libxl_qmp.c
+++ b/tools/libxl/libxl_qmp.c
@@ -484,7 +484,6 @@ static int qmp_next(libxl__gc *gc, libxl__qmp_handler *qmp)
 
                 if (o) {
                     rc = qmp_handle_response(qmp, o);
-                    libxl__json_object_free(gc, o);
                 } else {
                     LIBXL__LOG(qmp->ctx, LIBXL__LOG_ERROR,
                                "Parse error of : %s\n", s);
-- 
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 Sep 26 13:31:56 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Sep 2012 13:31:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGriK-0005Su-Tf; Wed, 26 Sep 2012 13:31:44 +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 1TGriJ-0005Si-52
	for xen-devel@lists.xen.org; Wed, 26 Sep 2012 13:31:43 +0000
Received: from [85.158.137.99:29100] by server-12.bemta-3.messagelabs.com id
	89/DD-23730-EB303605; Wed, 26 Sep 2012 13:31:42 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-3.tower-217.messagelabs.com!1348666299!14145578!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzE2MjI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8842 invoked from network); 26 Sep 2012 13:31:41 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-3.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Sep 2012 13:31:41 -0000
X-IronPort-AV: E=Sophos;i="4.80,490,1344211200"; d="scan'208";a="39222279"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Sep 2012 13:31:39 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 26 Sep 2012 09:31:39 -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 1TGriE-00053j-Ix;
	Wed, 26 Sep 2012 14:31:38 +0100
From: Anthony PERARD <anthony.perard@citrix.com>
To: Xen Devel <xen-devel@lists.xen.org>
Date: Wed, 26 Sep 2012 14:31:33 +0100
Message-ID: <1348666294-18182-2-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.12.1
In-Reply-To: <1348666294-18182-1-git-send-email-anthony.perard@citrix.com>
References: <1348666294-18182-1-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Cc: Anthony PERARD <anthony.perard@citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH 1/2] libxl_json: Use libxl alloc 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 patch makes use of the libxl allocation API and removes the check for
allocation failure.

This patch also assume that flexarray does not need to be freed as it will be
gc'd in the next patch.

Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
 tools/libxl/libxl_internal.h |   1 -
 tools/libxl/libxl_json.c     | 135 ++++++-------------------------------------
 tools/libxl/libxl_qmp.c      |   1 -
 3 files changed, 18 insertions(+), 119 deletions(-)

diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index b6f54ba..55fa771 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -1519,7 +1519,6 @@ libxl__json_map_node *libxl__json_map_node_get(const libxl__json_object *o,
 _hidden const libxl__json_object *libxl__json_map_get(const char *key,
                                           const libxl__json_object *o,
                                           libxl__json_node_type expected_type);
-_hidden void libxl__json_object_free(libxl__gc *gc, libxl__json_object *obj);
 
 _hidden libxl__json_object *libxl__json_parse(libxl__gc *gc, const char *s);
 
diff --git a/tools/libxl/libxl_json.c b/tools/libxl/libxl_json.c
index 8e17842..25df4a9 100644
--- a/tools/libxl/libxl_json.c
+++ b/tools/libxl/libxl_json.c
@@ -210,23 +210,12 @@ static libxl__json_object *json_object_alloc(libxl__gc *gc,
 {
     libxl__json_object *obj;
 
-    obj = calloc(1, sizeof (libxl__json_object));
-    if (obj == NULL) {
-        LIBXL__LOG_ERRNO(libxl__gc_owner(gc), LIBXL__LOG_ERROR,
-                         "Failed to allocate a libxl__json_object");
-        return NULL;
-    }
+    obj = libxl__zalloc(gc, sizeof(*obj));
 
     obj->type = type;
 
     if (type == JSON_MAP || type == JSON_ARRAY) {
         flexarray_t *array = flexarray_make(1, 1);
-        if (array == NULL) {
-            LIBXL__LOG_ERRNO(libxl__gc_owner(gc), LIBXL__LOG_ERROR,
-                             "Failed to allocate a flexarray");
-            free(obj);
-            return NULL;
-        }
         if (type == JSON_MAP)
             obj->u.map = array;
         else
@@ -256,11 +245,7 @@ static int json_object_append_to(libxl__gc *gc,
         break;
     }
     case JSON_ARRAY:
-        if (flexarray_append(dst->u.array, obj) == 2) {
-            LIBXL__LOG_ERRNO(libxl__gc_owner(gc), LIBXL__LOG_ERROR,
-                             "Failed to grow a flexarray");
-            return -1;
-        }
+        flexarray_append(dst->u.array, obj);
         break;
     default:
         LIBXL__LOG(libxl__gc_owner(gc), LIBXL__LOG_ERROR,
@@ -273,50 +258,6 @@ static int json_object_append_to(libxl__gc *gc,
     return 0;
 }
 
-void libxl__json_object_free(libxl__gc *gc, libxl__json_object *obj)
-{
-    int idx = 0;
-
-    if (obj == NULL)
-        return;
-    switch (obj->type) {
-    case JSON_STRING:
-    case JSON_NUMBER:
-        free(obj->u.string);
-        break;
-    case JSON_MAP: {
-        libxl__json_map_node *node = NULL;
-
-        for (idx = 0; idx < obj->u.map->count; idx++) {
-            if (flexarray_get(obj->u.map, idx, (void**)&node) != 0)
-                break;
-            libxl__json_object_free(gc, node->obj);
-            free(node->map_key);
-            free(node);
-            node = NULL;
-        }
-        flexarray_free(obj->u.map);
-        break;
-    }
-    case JSON_ARRAY: {
-        libxl__json_object *node = NULL;
-        break;
-
-        for (idx = 0; idx < obj->u.array->count; idx++) {
-            if (flexarray_get(obj->u.array, idx, (void**)&node) != 0)
-                break;
-            libxl__json_object_free(gc, node);
-            node = NULL;
-        }
-        flexarray_free(obj->u.array);
-        break;
-    }
-    default:
-        break;
-    }
-    free(obj);
-}
-
 libxl__json_object *libxl__json_array_get(const libxl__json_object *o, int i)
 {
     flexarray_t *array = NULL;
@@ -393,11 +334,9 @@ static int json_callback_null(void *opaque)
 
     DEBUG_GEN(ctx, null);
 
-    if ((obj = json_object_alloc(ctx->gc, JSON_NULL)) == NULL)
-        return 0;
+    obj = json_object_alloc(ctx->gc, JSON_NULL);
 
     if (json_object_append_to(ctx->gc, obj, ctx->current) == -1) {
-        libxl__json_object_free(ctx->gc, obj);
         return 0;
     }
 
@@ -411,12 +350,10 @@ static int json_callback_boolean(void *opaque, int boolean)
 
     DEBUG_GEN_VALUE(ctx, bool, boolean);
 
-    if ((obj = json_object_alloc(ctx->gc,
-                                 boolean ? JSON_TRUE : JSON_FALSE)) == NULL)
-        return 0;
+    obj = json_object_alloc(ctx->gc,
+                            boolean ? JSON_TRUE : JSON_FALSE);
 
     if (json_object_append_to(ctx->gc, obj, ctx->current) == -1) {
-        libxl__json_object_free(ctx->gc, obj);
         return 0;
     }
 
@@ -448,8 +385,7 @@ static int json_callback_number(void *opaque, const char *s, libxl_yajl_length l
             goto error;
         }
 
-        if ((obj = json_object_alloc(ctx->gc, JSON_DOUBLE)) == NULL)
-            return 0;
+        obj = json_object_alloc(ctx->gc, JSON_DOUBLE);
         obj->u.d = d;
     } else {
         long long i = strtoll(s, NULL, 10);
@@ -458,23 +394,16 @@ static int json_callback_number(void *opaque, const char *s, libxl_yajl_length l
             goto error;
         }
 
-        if ((obj = json_object_alloc(ctx->gc, JSON_INTEGER)) == NULL)
-            return 0;
+        obj = json_object_alloc(ctx->gc, JSON_INTEGER);
         obj->u.i = i;
     }
     goto out;
 
 error:
     /* If the conversion fail, we just store the original string. */
-    if ((obj = json_object_alloc(ctx->gc, JSON_NUMBER)) == NULL)
-        return 0;
+    obj = json_object_alloc(ctx->gc, JSON_NUMBER);
 
-    t = malloc(len + 1);
-    if (t == NULL) {
-        LIBXL__LOG_ERRNO(libxl__gc_owner(ctx->gc), LIBXL__LOG_ERROR,
-                         "Failed to allocate");
-        return 0;
-    }
+    t = libxl__zalloc(ctx->gc, len + 1);
     strncpy(t, s, len);
     t[len] = 0;
 
@@ -482,7 +411,6 @@ error:
 
 out:
     if (json_object_append_to(ctx->gc, obj, ctx->current) == -1) {
-        libxl__json_object_free(ctx->gc, obj);
         return 0;
     }
 
@@ -496,26 +424,17 @@ static int json_callback_string(void *opaque, const unsigned char *str,
     char *t = NULL;
     libxl__json_object *obj = NULL;
 
-    t = malloc(len + 1);
-    if (t == NULL) {
-        LIBXL__LOG_ERRNO(libxl__gc_owner(ctx->gc), LIBXL__LOG_ERROR,
-                         "Failed to allocate");
-        return 0;
-    }
+    t = libxl__zalloc(ctx->gc, len + 1);
 
     DEBUG_GEN_STRING(ctx, str, len);
 
     strncpy(t, (const char *) str, len);
     t[len] = 0;
 
-    if ((obj = json_object_alloc(ctx->gc, JSON_STRING)) == NULL) {
-        free(t);
-        return 0;
-    }
+    obj = json_object_alloc(ctx->gc, JSON_STRING);
     obj->u.string = t;
 
     if (json_object_append_to(ctx->gc, obj, ctx->current) == -1) {
-        libxl__json_object_free(ctx->gc, obj);
         return 0;
     }
 
@@ -528,13 +447,9 @@ static int json_callback_map_key(void *opaque, const unsigned char *str,
     libxl__yajl_ctx *ctx = opaque;
     char *t = NULL;
     libxl__json_object *obj = ctx->current;
+    libxl__gc *gc = ctx->gc;
 
-    t = malloc(len + 1);
-    if (t == NULL) {
-        LIBXL__LOG_ERRNO(libxl__gc_owner(ctx->gc), LIBXL__LOG_ERROR,
-                         "Failed to allocate");
-        return 0;
-    }
+    t = libxl__zalloc(gc, len + 1);
 
     DEBUG_GEN_STRING(ctx, str, len);
 
@@ -542,21 +457,13 @@ static int json_callback_map_key(void *opaque, const unsigned char *str,
     t[len] = 0;
 
     if (libxl__json_object_is_map(obj)) {
-        libxl__json_map_node *node = malloc(sizeof (libxl__json_map_node));
-        if (node == NULL) {
-            LIBXL__LOG_ERRNO(libxl__gc_owner(ctx->gc), LIBXL__LOG_ERROR,
-                             "Failed to allocate");
-            return 0;
-        }
+        libxl__json_map_node *node;
 
+        GCNEW(node);
         node->map_key = t;
         node->obj = NULL;
 
-        if (flexarray_append(obj->u.map, node) == 2) {
-            LIBXL__LOG_ERRNO(libxl__gc_owner(ctx->gc), LIBXL__LOG_ERROR,
-                             "Failed to grow a flexarray");
-            return 0;
-        }
+        flexarray_append(obj->u.map, node);
     } else {
         LIBXL__LOG(libxl__gc_owner(ctx->gc), LIBXL__LOG_ERROR,
                    "Current json object is not a map");
@@ -573,12 +480,10 @@ static int json_callback_start_map(void *opaque)
 
     DEBUG_GEN(ctx, map_open);
 
-    if ((obj = json_object_alloc(ctx->gc, JSON_MAP)) == NULL)
-        return 0;
+    obj = json_object_alloc(ctx->gc, JSON_MAP);
 
     if (ctx->current) {
         if (json_object_append_to(ctx->gc, obj, ctx->current) == -1) {
-            libxl__json_object_free(ctx->gc, obj);
             return 0;
         }
     }
@@ -615,12 +520,10 @@ static int json_callback_start_array(void *opaque)
 
     DEBUG_GEN(ctx, array_open);
 
-    if ((obj = json_object_alloc(ctx->gc, JSON_ARRAY)) == NULL)
-        return 0;
+    obj = json_object_alloc(ctx->gc, JSON_ARRAY);
 
     if (ctx->current) {
         if (json_object_append_to(ctx->gc, obj, ctx->current) == -1) {
-            libxl__json_object_free(ctx->gc, obj);
             return 0;
         }
     }
@@ -710,8 +613,6 @@ out:
 
     LIBXL__LOG(libxl__gc_owner(gc), LIBXL__LOG_ERROR, "yajl error: %s", str);
     yajl_free_error(yajl_ctx.hand, str);
-
-    libxl__json_object_free(gc, yajl_ctx.head);
     yajl_ctx_free(&yajl_ctx);
     return NULL;
 }
diff --git a/tools/libxl/libxl_qmp.c b/tools/libxl/libxl_qmp.c
index 2c4d269..0757fc2 100644
--- a/tools/libxl/libxl_qmp.c
+++ b/tools/libxl/libxl_qmp.c
@@ -484,7 +484,6 @@ static int qmp_next(libxl__gc *gc, libxl__qmp_handler *qmp)
 
                 if (o) {
                     rc = qmp_handle_response(qmp, o);
-                    libxl__json_object_free(gc, o);
                 } else {
                     LIBXL__LOG(qmp->ctx, LIBXL__LOG_ERROR,
                                "Parse error of : %s\n", s);
-- 
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 Sep 26 13:31:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Sep 2012 13:31:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGriP-0005TV-AU; Wed, 26 Sep 2012 13:31:49 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony.perard@citrix.com>) id 1TGriN-0005Sh-HI
	for xen-devel@lists.xen.org; Wed, 26 Sep 2012 13:31:47 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1348666299!3155849!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNzc3MDY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 849 invoked from network); 26 Sep 2012 13:31:41 -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;
	26 Sep 2012 13:31:41 -0000
X-IronPort-AV: E=Sophos;i="4.80,490,1344211200"; d="scan'208";a="209402982"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Sep 2012 13:31:39 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 26 Sep 2012 09:31:39 -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 1TGriE-00053j-HK;
	Wed, 26 Sep 2012 14:31:38 +0100
From: Anthony PERARD <anthony.perard@citrix.com>
To: Xen Devel <xen-devel@lists.xen.org>
Date: Wed, 26 Sep 2012 14:31:32 +0100
Message-ID: <1348666294-18182-1-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.12.1
MIME-Version: 1.0
Cc: Anthony PERARD <anthony.perard@citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH 0/2] Cleanup: flexarray taking gc.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This two patches do a bit of cleanup in the memomy managment in libxl,
regarding the use of flexarray.

The first one does some cleanup only in libxl_json.

The second one modify flexarray_make to take gc as argument and update every
user in libxl to pass gc and to not call flexarray_free anymore.


Anthony PERARD (2):
  libxl_json: Use libxl alloc function
  libxl: Have flexarray using the GC

 tools/libxl/flexarray.c      |  45 +++++++-------
 tools/libxl/flexarray.h      |   8 ++-
 tools/libxl/libxl.c          |  99 ++++++-------------------------
 tools/libxl/libxl_dm.c       |  15 +----
 tools/libxl/libxl_internal.h |   1 -
 tools/libxl/libxl_json.c     | 137 ++++++-------------------------------------
 tools/libxl/libxl_pci.c      |  18 +-----
 tools/libxl/libxl_qmp.c      |  29 ++-------
 8 files changed, 74 insertions(+), 278 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 Wed Sep 26 13:31:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Sep 2012 13:31:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGriP-0005TV-AU; Wed, 26 Sep 2012 13:31:49 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony.perard@citrix.com>) id 1TGriN-0005Sh-HI
	for xen-devel@lists.xen.org; Wed, 26 Sep 2012 13:31:47 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1348666299!3155849!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNzc3MDY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 849 invoked from network); 26 Sep 2012 13:31:41 -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;
	26 Sep 2012 13:31:41 -0000
X-IronPort-AV: E=Sophos;i="4.80,490,1344211200"; d="scan'208";a="209402982"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Sep 2012 13:31:39 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 26 Sep 2012 09:31:39 -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 1TGriE-00053j-HK;
	Wed, 26 Sep 2012 14:31:38 +0100
From: Anthony PERARD <anthony.perard@citrix.com>
To: Xen Devel <xen-devel@lists.xen.org>
Date: Wed, 26 Sep 2012 14:31:32 +0100
Message-ID: <1348666294-18182-1-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.12.1
MIME-Version: 1.0
Cc: Anthony PERARD <anthony.perard@citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH 0/2] Cleanup: flexarray taking gc.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This two patches do a bit of cleanup in the memomy managment in libxl,
regarding the use of flexarray.

The first one does some cleanup only in libxl_json.

The second one modify flexarray_make to take gc as argument and update every
user in libxl to pass gc and to not call flexarray_free anymore.


Anthony PERARD (2):
  libxl_json: Use libxl alloc function
  libxl: Have flexarray using the GC

 tools/libxl/flexarray.c      |  45 +++++++-------
 tools/libxl/flexarray.h      |   8 ++-
 tools/libxl/libxl.c          |  99 ++++++-------------------------
 tools/libxl/libxl_dm.c       |  15 +----
 tools/libxl/libxl_internal.h |   1 -
 tools/libxl/libxl_json.c     | 137 ++++++-------------------------------------
 tools/libxl/libxl_pci.c      |  18 +-----
 tools/libxl/libxl_qmp.c      |  29 ++-------
 8 files changed, 74 insertions(+), 278 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 Wed Sep 26 13:31:58 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Sep 2012 13: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 1TGriQ-0005Tn-N6; Wed, 26 Sep 2012 13:31:50 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony.perard@citrix.com>) id 1TGriO-0005Sk-GP
	for xen-devel@lists.xen.org; Wed, 26 Sep 2012 13:31:48 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1348666299!3155849!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNzc3MDY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 922 invoked from network); 26 Sep 2012 13:31:41 -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;
	26 Sep 2012 13:31:41 -0000
X-IronPort-AV: E=Sophos;i="4.80,490,1344211200"; d="scan'208";a="209402984"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Sep 2012 13:31:39 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 26 Sep 2012 09:31:39 -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 1TGriE-00053j-JK;
	Wed, 26 Sep 2012 14:31:38 +0100
From: Anthony PERARD <anthony.perard@citrix.com>
To: Xen Devel <xen-devel@lists.xen.org>
Date: Wed, 26 Sep 2012 14:31:34 +0100
Message-ID: <1348666294-18182-3-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.12.1
In-Reply-To: <1348666294-18182-1-git-send-email-anthony.perard@citrix.com>
References: <1348666294-18182-1-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Cc: Anthony PERARD <anthony.perard@citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH 2/2] libxl: Have flexarray using the GC
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This patch makes the flexarray function libxl__gc aware.

It also updates every function that use a flexarray to pass the gc and removes
every memory allocation check and free.

Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
 tools/libxl/flexarray.c  | 45 ++++++++++------------
 tools/libxl/flexarray.h  |  8 ++--
 tools/libxl/libxl.c      | 99 ++++++++++--------------------------------------
 tools/libxl/libxl_dm.c   | 15 ++------
 tools/libxl/libxl_json.c |  2 +-
 tools/libxl/libxl_pci.c  | 18 ++-------
 tools/libxl/libxl_qmp.c  | 28 ++------------
 7 files changed, 56 insertions(+), 159 deletions(-)

diff --git a/tools/libxl/flexarray.c b/tools/libxl/flexarray.c
index edf616c..1c2de1b 100644
--- a/tools/libxl/flexarray.c
+++ b/tools/libxl/flexarray.c
@@ -16,36 +16,28 @@
 #include "libxl_internal.h"
 #include <stdarg.h>
 
-flexarray_t *flexarray_make(int size, int autogrow)
+flexarray_t *flexarray_make(libxl__gc *gc, int size, int autogrow)
 {
-    flexarray_t *array = malloc(sizeof(struct flexarray));
-    if (array) {
-        array->size = size;
-        array->autogrow = autogrow;
-        array->count = 0;
-        array->data = calloc(size, sizeof(void *));
-    }
-    return array;
-}
+    flexarray_t *array;
 
-void flexarray_free(flexarray_t *array)
-{
-    free(array->data);
-    free(array);
+    GCNEW(array);
+    array->size = size;
+    array->autogrow = autogrow;
+    array->count = 0;
+    array->gc = gc;
+    GCNEW_ARRAY(array->data, size);
+
+    return array;
 }
 
-int flexarray_grow(flexarray_t *array, int extents)
+void flexarray_grow(flexarray_t *array, int extents)
 {
-    void **data;
     int newsize;
+    libxl__gc *gc = array->gc;
 
     newsize = array->size + extents;
-    data = realloc(array->data, sizeof(void *) * newsize);
-    if (!data)
-        return 1;
+    GCREALLOC_ARRAY(array->data, newsize);
     array->size += extents;
-    array->data = data;
-    return 0;
 }
 
 int flexarray_set(flexarray_t *array, unsigned int idx, void *ptr)
@@ -55,8 +47,7 @@ int flexarray_set(flexarray_t *array, unsigned int idx, void *ptr)
         if (!array->autogrow)
             return 1;
         newsize = (array->size * 2 < idx) ? idx + 1 : array->size * 2;
-        if (flexarray_grow(array, newsize - array->size))
-            return 2;
+        flexarray_grow(array, newsize - array->size);
     }
     if ( idx + 1 > array->count )
         array->count = idx + 1;
@@ -100,11 +91,17 @@ int flexarray_get(flexarray_t *array, int idx, void **ptr)
     return 0;
 }
 
+static int gc_is_real(const libxl__gc *gc)
+{
+    return gc->alloc_maxsize >= 0;
+}
+
 void **flexarray_contents(flexarray_t *array)
 {
     void **data;
     data = array->data;
-    free(array);
+    if (!gc_is_real(array->gc))
+        free(array);
     return data;
 }
 
diff --git a/tools/libxl/flexarray.h b/tools/libxl/flexarray.h
index ae17f3b..7e2bc5a 100644
--- a/tools/libxl/flexarray.h
+++ b/tools/libxl/flexarray.h
@@ -16,16 +16,18 @@
 #ifndef FLEXARRAY_H
 #define FLEXARRAY_H
 
+struct libxl__gc;
+
 typedef struct flexarray {
     int size;
     int autogrow;
     unsigned int count;
     void **data; /* array of pointer */
+    struct libxl__gc *gc;
 } flexarray_t;
 
-_hidden flexarray_t *flexarray_make(int size, int autogrow);
-_hidden void flexarray_free(flexarray_t *array);
-_hidden int flexarray_grow(flexarray_t *array, int extents);
+_hidden flexarray_t *flexarray_make(struct libxl__gc *gc, int size, int autogrow);
+_hidden void flexarray_grow(flexarray_t *array, int extents);
 _hidden int flexarray_set(flexarray_t *array, unsigned int index, void *ptr);
 _hidden int flexarray_append(flexarray_t *array, void *ptr);
 _hidden int flexarray_append_pair(flexarray_t *array, void *ptr1, void *ptr2);
diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 1606eb1..af3682f 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -1820,27 +1820,15 @@ static void device_disk_add(libxl__egc *egc, uint32_t domid,
         rc = libxl__device_disk_setdefault(gc, disk);
         if (rc) goto out;
 
-        if (front)
-            flexarray_free(front);
-        front = flexarray_make(16, 1);
-        if (!front) {
-            rc = ERROR_NOMEM;
-            goto out;
-        }
-        if (back)
-            flexarray_free(back);
-        back = flexarray_make(16, 1);
-        if (!back) {
-            rc = ERROR_NOMEM;
-            goto out_free;
-        }
+        front = flexarray_make(gc, 16, 1);
+        back = flexarray_make(gc, 16, 1);
 
         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);
-            goto out_free;
+            goto out;
         }
 
         switch (disk->backend) {
@@ -1878,7 +1866,7 @@ static void device_disk_add(libxl__egc *egc, uint32_t domid,
                     LOG(ERROR, "failed to get blktap devpath for %p\n",
                         disk->pdev_path);
                     rc = ERROR_FAIL;
-                    goto out_free;
+                    goto out;
                 }
                 flexarray_append(back, "tapdisk-params");
                 flexarray_append(back, libxl__sprintf(gc, "%s:%s",
@@ -1900,7 +1888,7 @@ static void device_disk_add(libxl__egc *egc, uint32_t domid,
             default:
                 LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unrecognized disk backend type: %d\n", disk->backend);
                 rc = ERROR_INVAL;
-                goto out_free;
+                goto out;
         }
 
         flexarray_append(back, "frontend-id");
@@ -1937,7 +1925,7 @@ static void device_disk_add(libxl__egc *egc, uint32_t domid,
 
         rc = libxl__xs_transaction_commit(gc, &t);
         if (!rc) break;
-        if (rc < 0) goto out_free;
+        if (rc < 0) goto out;
     }
 
     aodev->dev = device;
@@ -1946,9 +1934,6 @@ static void device_disk_add(libxl__egc *egc, uint32_t domid,
 
     rc = 0;
 
-out_free:
-    flexarray_free(back);
-    flexarray_free(front);
 out:
     libxl__xs_transaction_abort(gc, &t);
     aodev->rc = rc;
@@ -2204,7 +2189,7 @@ int libxl_cdrom_insert(libxl_ctx *ctx, uint32_t domid, libxl_device_disk *disk,
     if (rc) goto out;
     path = libxl__device_backend_path(gc, &device);
 
-    insert = flexarray_make(4, 1);
+    insert = flexarray_make(gc, 4, 1);
 
     flexarray_append_pair(insert, "type",
                           libxl__device_disk_string_of_backend(disk->backend));
@@ -2230,8 +2215,6 @@ out:
         libxl_device_disk_dispose(&disks[i]);
     free(disks);
 
-    if (insert) flexarray_free(insert);
-
     if (rc) return AO_ABORT(rc);
     return AO_INPROGRESS;
 }
@@ -2567,21 +2550,13 @@ void libxl__device_nic_add(libxl__egc *egc, uint32_t domid,
     rc = libxl__device_nic_setdefault(gc, nic, domid);
     if (rc) goto out;
 
-    front = flexarray_make(16, 1);
-    if (!front) {
-        rc = ERROR_NOMEM;
-        goto out;
-    }
-    back = flexarray_make(16, 1);
-    if (!back) {
-        rc = ERROR_NOMEM;
-        goto out_free;
-    }
+    front = flexarray_make(gc, 16, 1);
+    back = flexarray_make(gc, 16, 1);
 
     if (nic->devid == -1) {
         if (!(dompath = libxl__xs_get_dompath(gc, domid))) {
             rc = ERROR_FAIL;
-            goto out_free;
+            goto out;
         }
         if (!(l = libxl__xs_directory(gc, XBT_NULL,
                                      libxl__sprintf(gc, "%s/device/vif", dompath), &nb))) {
@@ -2593,7 +2568,7 @@ void libxl__device_nic_add(libxl__egc *egc, uint32_t domid,
 
     GCNEW(device);
     rc = libxl__device_from_nic(gc, domid, nic, device);
-    if ( rc != 0 ) goto out_free;
+    if ( rc != 0 ) goto out;
 
     flexarray_append(back, "frontend-id");
     flexarray_append(back, libxl__sprintf(gc, "%d", domid));
@@ -2652,9 +2627,6 @@ void libxl__device_nic_add(libxl__egc *egc, uint32_t domid,
     libxl__wait_device_connection(egc, aodev);
 
     rc = 0;
-out_free:
-    flexarray_free(back);
-    flexarray_free(front);
 out:
     aodev->rc = rc;
     if (rc) aodev->callback(egc, aodev);
@@ -2851,16 +2823,8 @@ int libxl__device_console_add(libxl__gc *gc, uint32_t domid,
         goto out;
     }
 
-    front = flexarray_make(16, 1);
-    if (!front) {
-        rc = ERROR_NOMEM;
-        goto out;
-    }
-    back = flexarray_make(16, 1);
-    if (!back) {
-        rc = ERROR_NOMEM;
-        goto out_free;
-    }
+    front = flexarray_make(gc, 16, 1);
+    back = flexarray_make(gc, 16, 1);
 
     device.backend_devid = console->devid;
     device.backend_domid = console->backend_domid;
@@ -2908,9 +2872,6 @@ int libxl__device_console_add(libxl__gc *gc, uint32_t domid,
                              libxl__xs_kvs_of_flexarray(gc, back, back->count),
                              libxl__xs_kvs_of_flexarray(gc, front, front->count));
     rc = 0;
-out_free:
-    flexarray_free(back);
-    flexarray_free(front);
 out:
     return rc;
 }
@@ -2964,19 +2925,11 @@ int libxl__device_vkb_add(libxl__gc *gc, uint32_t domid,
     rc = libxl__device_vkb_setdefault(gc, vkb);
     if (rc) goto out;
 
-    front = flexarray_make(16, 1);
-    if (!front) {
-        rc = ERROR_NOMEM;
-        goto out;
-    }
-    back = flexarray_make(16, 1);
-    if (!back) {
-        rc = ERROR_NOMEM;
-        goto out_free;
-    }
+    front = flexarray_make(gc, 16, 1);
+    back = flexarray_make(gc, 16, 1);
 
     rc = libxl__device_from_vkb(gc, domid, vkb, &device);
-    if (rc != 0) goto out_free;
+    if (rc != 0) goto out;
 
     flexarray_append(back, "frontend-id");
     flexarray_append(back, libxl__sprintf(gc, "%d", domid));
@@ -2996,9 +2949,6 @@ int libxl__device_vkb_add(libxl__gc *gc, uint32_t domid,
                              libxl__xs_kvs_of_flexarray(gc, back, back->count),
                              libxl__xs_kvs_of_flexarray(gc, front, front->count));
     rc = 0;
-out_free:
-    flexarray_free(back);
-    flexarray_free(front);
 out:
     return rc;
 }
@@ -3063,19 +3013,11 @@ int libxl__device_vfb_add(libxl__gc *gc, uint32_t domid, libxl_device_vfb *vfb)
     rc = libxl__device_vfb_setdefault(gc, vfb);
     if (rc) goto out;
 
-    front = flexarray_make(16, 1);
-    if (!front) {
-        rc = ERROR_NOMEM;
-        goto out;
-    }
-    back = flexarray_make(16, 1);
-    if (!back) {
-        rc = ERROR_NOMEM;
-        goto out_free;
-    }
+    front = flexarray_make(gc, 16, 1);
+    back = flexarray_make(gc, 16, 1);
 
     rc = libxl__device_from_vfb(gc, domid, vfb, &device);
-    if (rc != 0) goto out_free;
+    if (rc != 0) goto out;
 
     flexarray_append_pair(back, "frontend-id", libxl__sprintf(gc, "%d", domid));
     flexarray_append_pair(back, "online", "1");
@@ -3108,9 +3050,6 @@ int libxl__device_vfb_add(libxl__gc *gc, uint32_t domid, libxl_device_vfb *vfb)
                              libxl__xs_kvs_of_flexarray(gc, back, back->count),
                              libxl__xs_kvs_of_flexarray(gc, front, front->count));
     rc = 0;
-out_free:
-    flexarray_free(front);
-    flexarray_free(back);
 out:
     return rc;
 }
diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
index 3be7bad..82d2009 100644
--- a/tools/libxl/libxl_dm.c
+++ b/tools/libxl/libxl_dm.c
@@ -109,10 +109,7 @@ static char ** libxl__build_device_model_args_old(libxl__gc *gc,
     const char *keymap = dm_keymap(guest_config);
     int i;
     flexarray_t *dm_args;
-    dm_args = flexarray_make(16, 1);
-
-    if (!dm_args)
-        return NULL;
+    dm_args = flexarray_make(gc, 16, 1);
 
     flexarray_vappend(dm_args, dm,
                       "-d", libxl__sprintf(gc, "%d", domid), NULL);
@@ -340,9 +337,7 @@ static char ** libxl__build_device_model_args_new(libxl__gc *gc,
     int i;
     uint64_t ram_size;
 
-    dm_args = flexarray_make(16, 1);
-    if (!dm_args)
-        return NULL;
+    dm_args = flexarray_make(gc, 16, 1);
 
     flexarray_vappend(dm_args, dm,
                       "-xen-domid",
@@ -837,7 +832,7 @@ void libxl__spawn_stub_dm(libxl__egc *egc, libxl__stub_dm_spawn_state *sdss)
                          "setting target domain %d -> %d",
                          dm_domid, guest_domid);
         ret = ERROR_FAIL;
-        goto out_free;
+        goto out;
     }
     xs_set_target(ctx->xsh, dm_domid, guest_domid);
 
@@ -861,11 +856,8 @@ retry_transaction:
     libxl__add_disks(egc, ao, dm_domid, dm_config, &sdss->multidev);
     libxl__multidev_prepared(egc, &sdss->multidev, 0);
 
-    free(args);
     return;
 
-out_free:
-    free(args);
 out:
     assert(ret);
     spawn_stubdom_pvqemu_cb(egc, &sdss->pvqemu, ret);
@@ -1165,7 +1157,6 @@ retry_transaction:
 out_close:
     close(null);
     close(logfile_w);
-    free(args);
 out:
     if (rc)
         device_model_spawn_outcome(egc, dmss, rc);
diff --git a/tools/libxl/libxl_json.c b/tools/libxl/libxl_json.c
index 25df4a9..52fed51 100644
--- a/tools/libxl/libxl_json.c
+++ b/tools/libxl/libxl_json.c
@@ -215,7 +215,7 @@ static libxl__json_object *json_object_alloc(libxl__gc *gc,
     obj->type = type;
 
     if (type == JSON_MAP || type == JSON_ARRAY) {
-        flexarray_t *array = flexarray_make(1, 1);
+        flexarray_t *array = flexarray_make(gc, 1, 1);
         if (type == JSON_MAP)
             obj->u.map = array;
         else
diff --git a/tools/libxl/libxl_pci.c b/tools/libxl/libxl_pci.c
index ff447e7..eac35c1 100644
--- a/tools/libxl/libxl_pci.c
+++ b/tools/libxl/libxl_pci.c
@@ -73,12 +73,8 @@ int libxl__create_pci_backend(libxl__gc *gc, uint32_t domid,
     libxl__device device;
     int ret = ERROR_NOMEM, i;
 
-    front = flexarray_make(16, 1);
-    if (!front)
-        goto out;
-    back = flexarray_make(16, 1);
-    if (!back)
-        goto out;
+    front = flexarray_make(gc, 16, 1);
+    back = flexarray_make(gc, 16, 1);
 
     ret = 0;
 
@@ -108,11 +104,6 @@ int libxl__create_pci_backend(libxl__gc *gc, uint32_t domid,
                               libxl__xs_kvs_of_flexarray(gc, back, back->count),
                               libxl__xs_kvs_of_flexarray(gc, front, front->count));
 
-out:
-    if (back)
-        flexarray_free(back);
-    if (front)
-        flexarray_free(front);
     return 0;
 }
 
@@ -138,9 +129,7 @@ static int libxl__device_pci_add_xenstore(libxl__gc *gc, uint32_t domid, libxl_d
             return ERROR_FAIL;
     }
 
-    back = flexarray_make(16, 1);
-    if (!back)
-        return ERROR_NOMEM;
+    back = flexarray_make(gc, 16, 1);
 
     LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "Adding new pci device to xenstore");
     num = atoi(num_devs);
@@ -157,7 +146,6 @@ retry_transaction:
         if (errno == EAGAIN)
             goto retry_transaction;
 
-    flexarray_free(back);
     return 0;
 }
 
diff --git a/tools/libxl/libxl_qmp.c b/tools/libxl/libxl_qmp.c
index 0757fc2..15550e7 100644
--- a/tools/libxl/libxl_qmp.c
+++ b/tools/libxl/libxl_qmp.c
@@ -762,7 +762,7 @@ int libxl__qmp_pci_add(libxl__gc *gc, int domid, libxl_device_pci *pcidev)
     if (!hostaddr)
         return -1;
 
-    parameters = flexarray_make(6, 1);
+    parameters = flexarray_make(gc, 6, 1);
     flexarray_append_pair(parameters, "driver", "xen-pci-passthrough");
     flexarray_append_pair(parameters, "id",
                           libxl__sprintf(gc, PCI_PT_QDEV_ID,
@@ -776,8 +776,6 @@ int libxl__qmp_pci_add(libxl__gc *gc, int domid, libxl_device_pci *pcidev)
                                              PCI_FUNC(pcidev->vdevfn)));
     }
     args = libxl__xs_kvs_of_flexarray(gc, parameters, parameters->count);
-    if (!args)
-        return -1;
 
     rc = qmp_synchronous_send(qmp, "device_add", &args,
                               NULL, NULL, qmp->timeout);
@@ -786,7 +784,6 @@ int libxl__qmp_pci_add(libxl__gc *gc, int domid, libxl_device_pci *pcidev)
                                   pci_add_callback, pcidev, qmp->timeout);
     }
 
-    flexarray_free(parameters);
     libxl__qmp_close(qmp);
     return rc;
 }
@@ -802,16 +799,13 @@ static int qmp_device_del(libxl__gc *gc, int domid, char *id)
     if (!qmp)
         return ERROR_FAIL;
 
-    parameters = flexarray_make(2, 1);
+    parameters = flexarray_make(gc, 2, 1);
     flexarray_append_pair(parameters, "id", id);
     args = libxl__xs_kvs_of_flexarray(gc, parameters, parameters->count);
-    if (!args)
-        return ERROR_NOMEM;
 
     rc = qmp_synchronous_send(qmp, "device_del", &args,
                               NULL, NULL, qmp->timeout);
 
-    flexarray_free(parameters);
     libxl__qmp_close(qmp);
     return rc;
 }
@@ -837,24 +831,13 @@ int libxl__qmp_save(libxl__gc *gc, int domid, const char *filename)
     if (!qmp)
         return ERROR_FAIL;
 
-    parameters = flexarray_make(2, 1);
-    if (!parameters) {
-        rc = ERROR_NOMEM;
-        goto out;
-    }
+    parameters = flexarray_make(gc, 2, 1);
     flexarray_append_pair(parameters, "filename", (char *)filename);
     args = libxl__xs_kvs_of_flexarray(gc, parameters, parameters->count);
-    if (!args) {
-        rc = ERROR_NOMEM;
-        goto out2;
-    }
 
     rc = qmp_synchronous_send(qmp, "xen-save-devices-state", &args,
                               NULL, NULL, qmp->timeout);
 
-out2:
-    flexarray_free(parameters);
-out:
     libxl__qmp_close(qmp);
     return rc;
 }
@@ -866,19 +849,16 @@ static int qmp_change(libxl__gc *gc, libxl__qmp_handler *qmp,
     libxl_key_value_list args = NULL;
     int rc = 0;
 
-    parameters = flexarray_make(6, 1);
+    parameters = flexarray_make(gc, 6, 1);
     flexarray_append_pair(parameters, "device", device);
     flexarray_append_pair(parameters, "target", target);
     if (arg)
         flexarray_append_pair(parameters, "arg", arg);
     args = libxl__xs_kvs_of_flexarray(gc, parameters, parameters->count);
-    if (!args)
-        return ERROR_NOMEM;
 
     rc = qmp_synchronous_send(qmp, "change", &args,
                               NULL, NULL, qmp->timeout);
 
-    flexarray_free(parameters);
     return rc;
 }
 
-- 
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 Sep 26 13:31:58 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Sep 2012 13: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 1TGriQ-0005Tn-N6; Wed, 26 Sep 2012 13:31:50 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony.perard@citrix.com>) id 1TGriO-0005Sk-GP
	for xen-devel@lists.xen.org; Wed, 26 Sep 2012 13:31:48 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1348666299!3155849!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNzc3MDY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 922 invoked from network); 26 Sep 2012 13:31:41 -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;
	26 Sep 2012 13:31:41 -0000
X-IronPort-AV: E=Sophos;i="4.80,490,1344211200"; d="scan'208";a="209402984"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Sep 2012 13:31:39 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 26 Sep 2012 09:31:39 -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 1TGriE-00053j-JK;
	Wed, 26 Sep 2012 14:31:38 +0100
From: Anthony PERARD <anthony.perard@citrix.com>
To: Xen Devel <xen-devel@lists.xen.org>
Date: Wed, 26 Sep 2012 14:31:34 +0100
Message-ID: <1348666294-18182-3-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.12.1
In-Reply-To: <1348666294-18182-1-git-send-email-anthony.perard@citrix.com>
References: <1348666294-18182-1-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Cc: Anthony PERARD <anthony.perard@citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH 2/2] libxl: Have flexarray using the GC
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This patch makes the flexarray function libxl__gc aware.

It also updates every function that use a flexarray to pass the gc and removes
every memory allocation check and free.

Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
 tools/libxl/flexarray.c  | 45 ++++++++++------------
 tools/libxl/flexarray.h  |  8 ++--
 tools/libxl/libxl.c      | 99 ++++++++++--------------------------------------
 tools/libxl/libxl_dm.c   | 15 ++------
 tools/libxl/libxl_json.c |  2 +-
 tools/libxl/libxl_pci.c  | 18 ++-------
 tools/libxl/libxl_qmp.c  | 28 ++------------
 7 files changed, 56 insertions(+), 159 deletions(-)

diff --git a/tools/libxl/flexarray.c b/tools/libxl/flexarray.c
index edf616c..1c2de1b 100644
--- a/tools/libxl/flexarray.c
+++ b/tools/libxl/flexarray.c
@@ -16,36 +16,28 @@
 #include "libxl_internal.h"
 #include <stdarg.h>
 
-flexarray_t *flexarray_make(int size, int autogrow)
+flexarray_t *flexarray_make(libxl__gc *gc, int size, int autogrow)
 {
-    flexarray_t *array = malloc(sizeof(struct flexarray));
-    if (array) {
-        array->size = size;
-        array->autogrow = autogrow;
-        array->count = 0;
-        array->data = calloc(size, sizeof(void *));
-    }
-    return array;
-}
+    flexarray_t *array;
 
-void flexarray_free(flexarray_t *array)
-{
-    free(array->data);
-    free(array);
+    GCNEW(array);
+    array->size = size;
+    array->autogrow = autogrow;
+    array->count = 0;
+    array->gc = gc;
+    GCNEW_ARRAY(array->data, size);
+
+    return array;
 }
 
-int flexarray_grow(flexarray_t *array, int extents)
+void flexarray_grow(flexarray_t *array, int extents)
 {
-    void **data;
     int newsize;
+    libxl__gc *gc = array->gc;
 
     newsize = array->size + extents;
-    data = realloc(array->data, sizeof(void *) * newsize);
-    if (!data)
-        return 1;
+    GCREALLOC_ARRAY(array->data, newsize);
     array->size += extents;
-    array->data = data;
-    return 0;
 }
 
 int flexarray_set(flexarray_t *array, unsigned int idx, void *ptr)
@@ -55,8 +47,7 @@ int flexarray_set(flexarray_t *array, unsigned int idx, void *ptr)
         if (!array->autogrow)
             return 1;
         newsize = (array->size * 2 < idx) ? idx + 1 : array->size * 2;
-        if (flexarray_grow(array, newsize - array->size))
-            return 2;
+        flexarray_grow(array, newsize - array->size);
     }
     if ( idx + 1 > array->count )
         array->count = idx + 1;
@@ -100,11 +91,17 @@ int flexarray_get(flexarray_t *array, int idx, void **ptr)
     return 0;
 }
 
+static int gc_is_real(const libxl__gc *gc)
+{
+    return gc->alloc_maxsize >= 0;
+}
+
 void **flexarray_contents(flexarray_t *array)
 {
     void **data;
     data = array->data;
-    free(array);
+    if (!gc_is_real(array->gc))
+        free(array);
     return data;
 }
 
diff --git a/tools/libxl/flexarray.h b/tools/libxl/flexarray.h
index ae17f3b..7e2bc5a 100644
--- a/tools/libxl/flexarray.h
+++ b/tools/libxl/flexarray.h
@@ -16,16 +16,18 @@
 #ifndef FLEXARRAY_H
 #define FLEXARRAY_H
 
+struct libxl__gc;
+
 typedef struct flexarray {
     int size;
     int autogrow;
     unsigned int count;
     void **data; /* array of pointer */
+    struct libxl__gc *gc;
 } flexarray_t;
 
-_hidden flexarray_t *flexarray_make(int size, int autogrow);
-_hidden void flexarray_free(flexarray_t *array);
-_hidden int flexarray_grow(flexarray_t *array, int extents);
+_hidden flexarray_t *flexarray_make(struct libxl__gc *gc, int size, int autogrow);
+_hidden void flexarray_grow(flexarray_t *array, int extents);
 _hidden int flexarray_set(flexarray_t *array, unsigned int index, void *ptr);
 _hidden int flexarray_append(flexarray_t *array, void *ptr);
 _hidden int flexarray_append_pair(flexarray_t *array, void *ptr1, void *ptr2);
diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 1606eb1..af3682f 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -1820,27 +1820,15 @@ static void device_disk_add(libxl__egc *egc, uint32_t domid,
         rc = libxl__device_disk_setdefault(gc, disk);
         if (rc) goto out;
 
-        if (front)
-            flexarray_free(front);
-        front = flexarray_make(16, 1);
-        if (!front) {
-            rc = ERROR_NOMEM;
-            goto out;
-        }
-        if (back)
-            flexarray_free(back);
-        back = flexarray_make(16, 1);
-        if (!back) {
-            rc = ERROR_NOMEM;
-            goto out_free;
-        }
+        front = flexarray_make(gc, 16, 1);
+        back = flexarray_make(gc, 16, 1);
 
         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);
-            goto out_free;
+            goto out;
         }
 
         switch (disk->backend) {
@@ -1878,7 +1866,7 @@ static void device_disk_add(libxl__egc *egc, uint32_t domid,
                     LOG(ERROR, "failed to get blktap devpath for %p\n",
                         disk->pdev_path);
                     rc = ERROR_FAIL;
-                    goto out_free;
+                    goto out;
                 }
                 flexarray_append(back, "tapdisk-params");
                 flexarray_append(back, libxl__sprintf(gc, "%s:%s",
@@ -1900,7 +1888,7 @@ static void device_disk_add(libxl__egc *egc, uint32_t domid,
             default:
                 LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unrecognized disk backend type: %d\n", disk->backend);
                 rc = ERROR_INVAL;
-                goto out_free;
+                goto out;
         }
 
         flexarray_append(back, "frontend-id");
@@ -1937,7 +1925,7 @@ static void device_disk_add(libxl__egc *egc, uint32_t domid,
 
         rc = libxl__xs_transaction_commit(gc, &t);
         if (!rc) break;
-        if (rc < 0) goto out_free;
+        if (rc < 0) goto out;
     }
 
     aodev->dev = device;
@@ -1946,9 +1934,6 @@ static void device_disk_add(libxl__egc *egc, uint32_t domid,
 
     rc = 0;
 
-out_free:
-    flexarray_free(back);
-    flexarray_free(front);
 out:
     libxl__xs_transaction_abort(gc, &t);
     aodev->rc = rc;
@@ -2204,7 +2189,7 @@ int libxl_cdrom_insert(libxl_ctx *ctx, uint32_t domid, libxl_device_disk *disk,
     if (rc) goto out;
     path = libxl__device_backend_path(gc, &device);
 
-    insert = flexarray_make(4, 1);
+    insert = flexarray_make(gc, 4, 1);
 
     flexarray_append_pair(insert, "type",
                           libxl__device_disk_string_of_backend(disk->backend));
@@ -2230,8 +2215,6 @@ out:
         libxl_device_disk_dispose(&disks[i]);
     free(disks);
 
-    if (insert) flexarray_free(insert);
-
     if (rc) return AO_ABORT(rc);
     return AO_INPROGRESS;
 }
@@ -2567,21 +2550,13 @@ void libxl__device_nic_add(libxl__egc *egc, uint32_t domid,
     rc = libxl__device_nic_setdefault(gc, nic, domid);
     if (rc) goto out;
 
-    front = flexarray_make(16, 1);
-    if (!front) {
-        rc = ERROR_NOMEM;
-        goto out;
-    }
-    back = flexarray_make(16, 1);
-    if (!back) {
-        rc = ERROR_NOMEM;
-        goto out_free;
-    }
+    front = flexarray_make(gc, 16, 1);
+    back = flexarray_make(gc, 16, 1);
 
     if (nic->devid == -1) {
         if (!(dompath = libxl__xs_get_dompath(gc, domid))) {
             rc = ERROR_FAIL;
-            goto out_free;
+            goto out;
         }
         if (!(l = libxl__xs_directory(gc, XBT_NULL,
                                      libxl__sprintf(gc, "%s/device/vif", dompath), &nb))) {
@@ -2593,7 +2568,7 @@ void libxl__device_nic_add(libxl__egc *egc, uint32_t domid,
 
     GCNEW(device);
     rc = libxl__device_from_nic(gc, domid, nic, device);
-    if ( rc != 0 ) goto out_free;
+    if ( rc != 0 ) goto out;
 
     flexarray_append(back, "frontend-id");
     flexarray_append(back, libxl__sprintf(gc, "%d", domid));
@@ -2652,9 +2627,6 @@ void libxl__device_nic_add(libxl__egc *egc, uint32_t domid,
     libxl__wait_device_connection(egc, aodev);
 
     rc = 0;
-out_free:
-    flexarray_free(back);
-    flexarray_free(front);
 out:
     aodev->rc = rc;
     if (rc) aodev->callback(egc, aodev);
@@ -2851,16 +2823,8 @@ int libxl__device_console_add(libxl__gc *gc, uint32_t domid,
         goto out;
     }
 
-    front = flexarray_make(16, 1);
-    if (!front) {
-        rc = ERROR_NOMEM;
-        goto out;
-    }
-    back = flexarray_make(16, 1);
-    if (!back) {
-        rc = ERROR_NOMEM;
-        goto out_free;
-    }
+    front = flexarray_make(gc, 16, 1);
+    back = flexarray_make(gc, 16, 1);
 
     device.backend_devid = console->devid;
     device.backend_domid = console->backend_domid;
@@ -2908,9 +2872,6 @@ int libxl__device_console_add(libxl__gc *gc, uint32_t domid,
                              libxl__xs_kvs_of_flexarray(gc, back, back->count),
                              libxl__xs_kvs_of_flexarray(gc, front, front->count));
     rc = 0;
-out_free:
-    flexarray_free(back);
-    flexarray_free(front);
 out:
     return rc;
 }
@@ -2964,19 +2925,11 @@ int libxl__device_vkb_add(libxl__gc *gc, uint32_t domid,
     rc = libxl__device_vkb_setdefault(gc, vkb);
     if (rc) goto out;
 
-    front = flexarray_make(16, 1);
-    if (!front) {
-        rc = ERROR_NOMEM;
-        goto out;
-    }
-    back = flexarray_make(16, 1);
-    if (!back) {
-        rc = ERROR_NOMEM;
-        goto out_free;
-    }
+    front = flexarray_make(gc, 16, 1);
+    back = flexarray_make(gc, 16, 1);
 
     rc = libxl__device_from_vkb(gc, domid, vkb, &device);
-    if (rc != 0) goto out_free;
+    if (rc != 0) goto out;
 
     flexarray_append(back, "frontend-id");
     flexarray_append(back, libxl__sprintf(gc, "%d", domid));
@@ -2996,9 +2949,6 @@ int libxl__device_vkb_add(libxl__gc *gc, uint32_t domid,
                              libxl__xs_kvs_of_flexarray(gc, back, back->count),
                              libxl__xs_kvs_of_flexarray(gc, front, front->count));
     rc = 0;
-out_free:
-    flexarray_free(back);
-    flexarray_free(front);
 out:
     return rc;
 }
@@ -3063,19 +3013,11 @@ int libxl__device_vfb_add(libxl__gc *gc, uint32_t domid, libxl_device_vfb *vfb)
     rc = libxl__device_vfb_setdefault(gc, vfb);
     if (rc) goto out;
 
-    front = flexarray_make(16, 1);
-    if (!front) {
-        rc = ERROR_NOMEM;
-        goto out;
-    }
-    back = flexarray_make(16, 1);
-    if (!back) {
-        rc = ERROR_NOMEM;
-        goto out_free;
-    }
+    front = flexarray_make(gc, 16, 1);
+    back = flexarray_make(gc, 16, 1);
 
     rc = libxl__device_from_vfb(gc, domid, vfb, &device);
-    if (rc != 0) goto out_free;
+    if (rc != 0) goto out;
 
     flexarray_append_pair(back, "frontend-id", libxl__sprintf(gc, "%d", domid));
     flexarray_append_pair(back, "online", "1");
@@ -3108,9 +3050,6 @@ int libxl__device_vfb_add(libxl__gc *gc, uint32_t domid, libxl_device_vfb *vfb)
                              libxl__xs_kvs_of_flexarray(gc, back, back->count),
                              libxl__xs_kvs_of_flexarray(gc, front, front->count));
     rc = 0;
-out_free:
-    flexarray_free(front);
-    flexarray_free(back);
 out:
     return rc;
 }
diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
index 3be7bad..82d2009 100644
--- a/tools/libxl/libxl_dm.c
+++ b/tools/libxl/libxl_dm.c
@@ -109,10 +109,7 @@ static char ** libxl__build_device_model_args_old(libxl__gc *gc,
     const char *keymap = dm_keymap(guest_config);
     int i;
     flexarray_t *dm_args;
-    dm_args = flexarray_make(16, 1);
-
-    if (!dm_args)
-        return NULL;
+    dm_args = flexarray_make(gc, 16, 1);
 
     flexarray_vappend(dm_args, dm,
                       "-d", libxl__sprintf(gc, "%d", domid), NULL);
@@ -340,9 +337,7 @@ static char ** libxl__build_device_model_args_new(libxl__gc *gc,
     int i;
     uint64_t ram_size;
 
-    dm_args = flexarray_make(16, 1);
-    if (!dm_args)
-        return NULL;
+    dm_args = flexarray_make(gc, 16, 1);
 
     flexarray_vappend(dm_args, dm,
                       "-xen-domid",
@@ -837,7 +832,7 @@ void libxl__spawn_stub_dm(libxl__egc *egc, libxl__stub_dm_spawn_state *sdss)
                          "setting target domain %d -> %d",
                          dm_domid, guest_domid);
         ret = ERROR_FAIL;
-        goto out_free;
+        goto out;
     }
     xs_set_target(ctx->xsh, dm_domid, guest_domid);
 
@@ -861,11 +856,8 @@ retry_transaction:
     libxl__add_disks(egc, ao, dm_domid, dm_config, &sdss->multidev);
     libxl__multidev_prepared(egc, &sdss->multidev, 0);
 
-    free(args);
     return;
 
-out_free:
-    free(args);
 out:
     assert(ret);
     spawn_stubdom_pvqemu_cb(egc, &sdss->pvqemu, ret);
@@ -1165,7 +1157,6 @@ retry_transaction:
 out_close:
     close(null);
     close(logfile_w);
-    free(args);
 out:
     if (rc)
         device_model_spawn_outcome(egc, dmss, rc);
diff --git a/tools/libxl/libxl_json.c b/tools/libxl/libxl_json.c
index 25df4a9..52fed51 100644
--- a/tools/libxl/libxl_json.c
+++ b/tools/libxl/libxl_json.c
@@ -215,7 +215,7 @@ static libxl__json_object *json_object_alloc(libxl__gc *gc,
     obj->type = type;
 
     if (type == JSON_MAP || type == JSON_ARRAY) {
-        flexarray_t *array = flexarray_make(1, 1);
+        flexarray_t *array = flexarray_make(gc, 1, 1);
         if (type == JSON_MAP)
             obj->u.map = array;
         else
diff --git a/tools/libxl/libxl_pci.c b/tools/libxl/libxl_pci.c
index ff447e7..eac35c1 100644
--- a/tools/libxl/libxl_pci.c
+++ b/tools/libxl/libxl_pci.c
@@ -73,12 +73,8 @@ int libxl__create_pci_backend(libxl__gc *gc, uint32_t domid,
     libxl__device device;
     int ret = ERROR_NOMEM, i;
 
-    front = flexarray_make(16, 1);
-    if (!front)
-        goto out;
-    back = flexarray_make(16, 1);
-    if (!back)
-        goto out;
+    front = flexarray_make(gc, 16, 1);
+    back = flexarray_make(gc, 16, 1);
 
     ret = 0;
 
@@ -108,11 +104,6 @@ int libxl__create_pci_backend(libxl__gc *gc, uint32_t domid,
                               libxl__xs_kvs_of_flexarray(gc, back, back->count),
                               libxl__xs_kvs_of_flexarray(gc, front, front->count));
 
-out:
-    if (back)
-        flexarray_free(back);
-    if (front)
-        flexarray_free(front);
     return 0;
 }
 
@@ -138,9 +129,7 @@ static int libxl__device_pci_add_xenstore(libxl__gc *gc, uint32_t domid, libxl_d
             return ERROR_FAIL;
     }
 
-    back = flexarray_make(16, 1);
-    if (!back)
-        return ERROR_NOMEM;
+    back = flexarray_make(gc, 16, 1);
 
     LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "Adding new pci device to xenstore");
     num = atoi(num_devs);
@@ -157,7 +146,6 @@ retry_transaction:
         if (errno == EAGAIN)
             goto retry_transaction;
 
-    flexarray_free(back);
     return 0;
 }
 
diff --git a/tools/libxl/libxl_qmp.c b/tools/libxl/libxl_qmp.c
index 0757fc2..15550e7 100644
--- a/tools/libxl/libxl_qmp.c
+++ b/tools/libxl/libxl_qmp.c
@@ -762,7 +762,7 @@ int libxl__qmp_pci_add(libxl__gc *gc, int domid, libxl_device_pci *pcidev)
     if (!hostaddr)
         return -1;
 
-    parameters = flexarray_make(6, 1);
+    parameters = flexarray_make(gc, 6, 1);
     flexarray_append_pair(parameters, "driver", "xen-pci-passthrough");
     flexarray_append_pair(parameters, "id",
                           libxl__sprintf(gc, PCI_PT_QDEV_ID,
@@ -776,8 +776,6 @@ int libxl__qmp_pci_add(libxl__gc *gc, int domid, libxl_device_pci *pcidev)
                                              PCI_FUNC(pcidev->vdevfn)));
     }
     args = libxl__xs_kvs_of_flexarray(gc, parameters, parameters->count);
-    if (!args)
-        return -1;
 
     rc = qmp_synchronous_send(qmp, "device_add", &args,
                               NULL, NULL, qmp->timeout);
@@ -786,7 +784,6 @@ int libxl__qmp_pci_add(libxl__gc *gc, int domid, libxl_device_pci *pcidev)
                                   pci_add_callback, pcidev, qmp->timeout);
     }
 
-    flexarray_free(parameters);
     libxl__qmp_close(qmp);
     return rc;
 }
@@ -802,16 +799,13 @@ static int qmp_device_del(libxl__gc *gc, int domid, char *id)
     if (!qmp)
         return ERROR_FAIL;
 
-    parameters = flexarray_make(2, 1);
+    parameters = flexarray_make(gc, 2, 1);
     flexarray_append_pair(parameters, "id", id);
     args = libxl__xs_kvs_of_flexarray(gc, parameters, parameters->count);
-    if (!args)
-        return ERROR_NOMEM;
 
     rc = qmp_synchronous_send(qmp, "device_del", &args,
                               NULL, NULL, qmp->timeout);
 
-    flexarray_free(parameters);
     libxl__qmp_close(qmp);
     return rc;
 }
@@ -837,24 +831,13 @@ int libxl__qmp_save(libxl__gc *gc, int domid, const char *filename)
     if (!qmp)
         return ERROR_FAIL;
 
-    parameters = flexarray_make(2, 1);
-    if (!parameters) {
-        rc = ERROR_NOMEM;
-        goto out;
-    }
+    parameters = flexarray_make(gc, 2, 1);
     flexarray_append_pair(parameters, "filename", (char *)filename);
     args = libxl__xs_kvs_of_flexarray(gc, parameters, parameters->count);
-    if (!args) {
-        rc = ERROR_NOMEM;
-        goto out2;
-    }
 
     rc = qmp_synchronous_send(qmp, "xen-save-devices-state", &args,
                               NULL, NULL, qmp->timeout);
 
-out2:
-    flexarray_free(parameters);
-out:
     libxl__qmp_close(qmp);
     return rc;
 }
@@ -866,19 +849,16 @@ static int qmp_change(libxl__gc *gc, libxl__qmp_handler *qmp,
     libxl_key_value_list args = NULL;
     int rc = 0;
 
-    parameters = flexarray_make(6, 1);
+    parameters = flexarray_make(gc, 6, 1);
     flexarray_append_pair(parameters, "device", device);
     flexarray_append_pair(parameters, "target", target);
     if (arg)
         flexarray_append_pair(parameters, "arg", arg);
     args = libxl__xs_kvs_of_flexarray(gc, parameters, parameters->count);
-    if (!args)
-        return ERROR_NOMEM;
 
     rc = qmp_synchronous_send(qmp, "change", &args,
                               NULL, NULL, qmp->timeout);
 
-    flexarray_free(parameters);
     return rc;
 }
 
-- 
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 Sep 26 13:42:32 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Sep 2012 13:42:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGrsY-0006AG-6t; Wed, 26 Sep 2012 13:42: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 1TGrsX-0006AB-4Q
	for Xen-devel@lists.xensource.com; Wed, 26 Sep 2012 13:42:17 +0000
Received: from [85.158.137.99:30828] by server-14.bemta-3.messagelabs.com id
	A7/F3-25886-83603605; Wed, 26 Sep 2012 13:42:16 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-217.messagelabs.com!1348666935!19232312!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTE1NzQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5025 invoked from network); 26 Sep 2012 13:42:15 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Sep 2012 13:42:15 -0000
X-IronPort-AV: E=Sophos;i="4.80,490,1344211200"; d="scan'208";a="14778412"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Sep 2012 13:42: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.279.1;
	Wed, 26 Sep 2012 14:42:15 +0100
Message-ID: <1348666933.19176.43.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Mukesh Rathor <mukesh.rathor@oracle.com>
Date: Wed, 26 Sep 2012 14:42:13 +0100
In-Reply-To: <20120921121511.30001c08@mantra.us.oracle.com>
References: <20120921121511.30001c08@mantra.us.oracle.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-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] [PATCH v1 1/8]: PVH  basic and hader file 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

NB typo in the subject line.
On Fri, 2012-09-21 at 20:15 +0100, Mukesh Rathor wrote:
>  drivers/xen/xenbus/xenbus_client.c   |    2 +-

I needed this fixup to build on ARM after this patch:

8<----------------------------------------------

>From f4d7d3ea58d1cb673632d8e65fc40a4c84a1d213 Mon Sep 17 00:00:00 2001
From: Ian Campbell <ian.campbell@citrix.com>
Date: Wed, 26 Sep 2012 14:35:39 +0100
Subject: [PATCH] xenbus: include features header.

Fixes:
drivers/xen/xenbus/xenbus_probe.c: In function 'xenbus_init':
drivers/xen/xenbus/xenbus_probe.c:760:3: error: implicit declaration of function 'xen_feature' [-Werror=implicit-function-declaration]
drivers/xen/xenbus/xenbus_probe.c:760:19: error: 'XENFEAT_auto_translated_physmap' undeclared (first use in this function)
drivers/xen/xenbus/xenbus_probe.c:760:19: note: each undeclared identifier is reported only once for each function it appears in
cc1: some warnings being treated as errors

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 drivers/xen/xenbus/xenbus_probe.c |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/drivers/xen/xenbus/xenbus_probe.c b/drivers/xen/xenbus/xenbus_probe.c
index b92c024..974bea0 100644
--- a/drivers/xen/xenbus/xenbus_probe.c
+++ b/drivers/xen/xenbus/xenbus_probe.c
@@ -56,6 +56,7 @@
 #include <xen/xenbus.h>
 #include <xen/events.h>
 #include <xen/page.h>
+#include <xen/features.h>
 
 #include <xen/hvm.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 Wed Sep 26 13:42:32 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Sep 2012 13:42:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGrsY-0006AG-6t; Wed, 26 Sep 2012 13:42: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 1TGrsX-0006AB-4Q
	for Xen-devel@lists.xensource.com; Wed, 26 Sep 2012 13:42:17 +0000
Received: from [85.158.137.99:30828] by server-14.bemta-3.messagelabs.com id
	A7/F3-25886-83603605; Wed, 26 Sep 2012 13:42:16 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-217.messagelabs.com!1348666935!19232312!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTE1NzQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5025 invoked from network); 26 Sep 2012 13:42:15 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Sep 2012 13:42:15 -0000
X-IronPort-AV: E=Sophos;i="4.80,490,1344211200"; d="scan'208";a="14778412"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Sep 2012 13:42: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.279.1;
	Wed, 26 Sep 2012 14:42:15 +0100
Message-ID: <1348666933.19176.43.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Mukesh Rathor <mukesh.rathor@oracle.com>
Date: Wed, 26 Sep 2012 14:42:13 +0100
In-Reply-To: <20120921121511.30001c08@mantra.us.oracle.com>
References: <20120921121511.30001c08@mantra.us.oracle.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-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] [PATCH v1 1/8]: PVH  basic and hader file 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

NB typo in the subject line.
On Fri, 2012-09-21 at 20:15 +0100, Mukesh Rathor wrote:
>  drivers/xen/xenbus/xenbus_client.c   |    2 +-

I needed this fixup to build on ARM after this patch:

8<----------------------------------------------

>From f4d7d3ea58d1cb673632d8e65fc40a4c84a1d213 Mon Sep 17 00:00:00 2001
From: Ian Campbell <ian.campbell@citrix.com>
Date: Wed, 26 Sep 2012 14:35:39 +0100
Subject: [PATCH] xenbus: include features header.

Fixes:
drivers/xen/xenbus/xenbus_probe.c: In function 'xenbus_init':
drivers/xen/xenbus/xenbus_probe.c:760:3: error: implicit declaration of function 'xen_feature' [-Werror=implicit-function-declaration]
drivers/xen/xenbus/xenbus_probe.c:760:19: error: 'XENFEAT_auto_translated_physmap' undeclared (first use in this function)
drivers/xen/xenbus/xenbus_probe.c:760:19: note: each undeclared identifier is reported only once for each function it appears in
cc1: some warnings being treated as errors

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 drivers/xen/xenbus/xenbus_probe.c |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/drivers/xen/xenbus/xenbus_probe.c b/drivers/xen/xenbus/xenbus_probe.c
index b92c024..974bea0 100644
--- a/drivers/xen/xenbus/xenbus_probe.c
+++ b/drivers/xen/xenbus/xenbus_probe.c
@@ -56,6 +56,7 @@
 #include <xen/xenbus.h>
 #include <xen/events.h>
 #include <xen/page.h>
+#include <xen/features.h>
 
 #include <xen/hvm.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 Wed Sep 26 13:45:37 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Sep 2012 13: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 1TGrva-0006GO-Py; Wed, 26 Sep 2012 13:45: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 1TGrvZ-0006GF-9p
	for Xen-devel@lists.xensource.com; Wed, 26 Sep 2012 13:45:25 +0000
Received: from [85.158.138.51:49380] by server-6.bemta-3.messagelabs.com id
	67/2A-11085-4F603605; Wed, 26 Sep 2012 13:45:24 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1348667123!25722048!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTE1NzQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5391 invoked from network); 26 Sep 2012 13:45:24 -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;
	26 Sep 2012 13:45:24 -0000
X-IronPort-AV: E=Sophos;i="4.80,490,1344211200"; d="scan'208";a="14778526"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Sep 2012 13: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.279.1;
	Wed, 26 Sep 2012 14:45:19 +0100
Message-ID: <1348667117.19176.46.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Mukesh Rathor <mukesh.rathor@oracle.com>
Date: Wed, 26 Sep 2012 14:45:17 +0100
In-Reply-To: <20120921121511.30001c08@mantra.us.oracle.com>
References: <20120921121511.30001c08@mantra.us.oracle.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-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] [PATCH v1 1/8]: PVH  basic and hader file changes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-09-21 at 20:15 +0100, Mukesh Rathor wrote:
> diff --git a/drivers/xen/events.c b/drivers/xen/events.c
> index 7595581..f656791 100644
> --- a/drivers/xen/events.c
> +++ b/drivers/xen/events.c
> @@ -1755,7 +1755,7 @@ int xen_set_callback_via(uint64_t via)
>  }
>  EXPORT_SYMBOL_GPL(xen_set_callback_via);
>  
> -#ifdef CONFIG_XEN_PVHVM
> +
>  /* Vector callbacks are better than PCI interrupts to receive event
>   * channel notifications because we can receive vector callbacks on
> any
>   * vcpu and we don't need PCI support or APIC interactions. */
> @@ -1779,9 +1779,6 @@ void xen_callback_vector(void)
>                         alloc_intr_gate(XEN_HVM_EVTCHN_CALLBACK,
> xen_hvm_callback_vector);
>         }
>  }
> -#else
> -void xen_callback_vector(void) {}
> -#endif
>  
>  void __init xen_init_IRQ(void)
>  { 

This breaks on ARM because this like XEN_HVM_EVTCHN_CALLBACK, which are
inside this ifdef, are actually X86 specific.

I suspect that xen_callback_vector needs to be moved in to an arch
specific file so that we can supply a suitably different implementation
on ARM -- Stefano 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 Wed Sep 26 13:45:37 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Sep 2012 13: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 1TGrva-0006GO-Py; Wed, 26 Sep 2012 13:45: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 1TGrvZ-0006GF-9p
	for Xen-devel@lists.xensource.com; Wed, 26 Sep 2012 13:45:25 +0000
Received: from [85.158.138.51:49380] by server-6.bemta-3.messagelabs.com id
	67/2A-11085-4F603605; Wed, 26 Sep 2012 13:45:24 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1348667123!25722048!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTE1NzQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5391 invoked from network); 26 Sep 2012 13:45:24 -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;
	26 Sep 2012 13:45:24 -0000
X-IronPort-AV: E=Sophos;i="4.80,490,1344211200"; d="scan'208";a="14778526"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Sep 2012 13: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.279.1;
	Wed, 26 Sep 2012 14:45:19 +0100
Message-ID: <1348667117.19176.46.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Mukesh Rathor <mukesh.rathor@oracle.com>
Date: Wed, 26 Sep 2012 14:45:17 +0100
In-Reply-To: <20120921121511.30001c08@mantra.us.oracle.com>
References: <20120921121511.30001c08@mantra.us.oracle.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-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] [PATCH v1 1/8]: PVH  basic and hader file changes
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, 2012-09-21 at 20:15 +0100, Mukesh Rathor wrote:
> diff --git a/drivers/xen/events.c b/drivers/xen/events.c
> index 7595581..f656791 100644
> --- a/drivers/xen/events.c
> +++ b/drivers/xen/events.c
> @@ -1755,7 +1755,7 @@ int xen_set_callback_via(uint64_t via)
>  }
>  EXPORT_SYMBOL_GPL(xen_set_callback_via);
>  
> -#ifdef CONFIG_XEN_PVHVM
> +
>  /* Vector callbacks are better than PCI interrupts to receive event
>   * channel notifications because we can receive vector callbacks on
> any
>   * vcpu and we don't need PCI support or APIC interactions. */
> @@ -1779,9 +1779,6 @@ void xen_callback_vector(void)
>                         alloc_intr_gate(XEN_HVM_EVTCHN_CALLBACK,
> xen_hvm_callback_vector);
>         }
>  }
> -#else
> -void xen_callback_vector(void) {}
> -#endif
>  
>  void __init xen_init_IRQ(void)
>  { 

This breaks on ARM because this like XEN_HVM_EVTCHN_CALLBACK, which are
inside this ifdef, are actually X86 specific.

I suspect that xen_callback_vector needs to be moved in to an arch
specific file so that we can supply a suitably different implementation
on ARM -- Stefano 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 Wed Sep 26 13:49:22 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Sep 2012 13:49: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 1TGrz9-0006Q9-E8; Wed, 26 Sep 2012 13:49:07 +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 1TGrz8-0006Pw-PY
	for Xen-devel@lists.xensource.com; Wed, 26 Sep 2012 13:49:06 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1348667339!4773604!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDc3NTczOQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11489 invoked from network); 26 Sep 2012 13:49:00 -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; 26 Sep 2012 13:49:00 -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 q8QDmsd5020187
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 26 Sep 2012 13:48:54 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q8QDmrPv015226
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 26 Sep 2012 13:48:53 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
	q8QDmrbW023306; Wed, 26 Sep 2012 08:48:53 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 26 Sep 2012 06:48:52 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 901A84032D; Wed, 26 Sep 2012 09:37:36 -0400 (EDT)
Date: Wed, 26 Sep 2012 09:37:36 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120926133736.GA9919@phenom.dumpdata.com>
References: <20120921121202.3163c379@mantra.us.oracle.com>
	<1348665924.19176.41.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1348665924.19176.41.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: "Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v1 0/8]: PVH (PV guest with extensions)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Sep 26, 2012 at 02:25:24PM +0100, Ian Campbell wrote:
> On Fri, 2012-09-21 at 20:12 +0100, Mukesh Rathor wrote:
> > Hi guys,
> > 
> > Ok, I've made all the changes from prev RFC patch submission. Tested
> > all the combinations. The patches are a bit smaller from before, and
> > couldn't be separated like before, so I can't state whats different in
> > each patch. But, it's not too bad to review now.
> > 
> > As before, they were built on top of
> > fc6bdb59a501740b28ed3b616641a22c8dc5dd31 from the following tree:
> >         
> > git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
> 
> Is that correct? That's this commit:
> 
> commit fc6bdb59a501740b28ed3b616641a22c8dc5dd31
> Merge: 44d82e2 1fcfd08
> Author: Linus Torvalds <torvalds@linux-foundation.org>
> Date:   Thu Aug 2 11:52:39 2012 -0700
> 
> Why so old? Makes it hard to take these for a spin due to the
> rebasing...

I rebased them on top v3.6-rc6 (look in #linux-next-pvh) but I must
have done something wrong b/c it won't boot as PVHVM. Time to do some git
bisection and see where I failed.

> 
> Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 26 13:49:22 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Sep 2012 13:49: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 1TGrz9-0006Q9-E8; Wed, 26 Sep 2012 13:49:07 +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 1TGrz8-0006Pw-PY
	for Xen-devel@lists.xensource.com; Wed, 26 Sep 2012 13:49:06 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1348667339!4773604!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDc3NTczOQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11489 invoked from network); 26 Sep 2012 13:49:00 -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; 26 Sep 2012 13:49:00 -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 q8QDmsd5020187
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 26 Sep 2012 13:48:54 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q8QDmrPv015226
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 26 Sep 2012 13:48:53 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
	q8QDmrbW023306; Wed, 26 Sep 2012 08:48:53 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 26 Sep 2012 06:48:52 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 901A84032D; Wed, 26 Sep 2012 09:37:36 -0400 (EDT)
Date: Wed, 26 Sep 2012 09:37:36 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120926133736.GA9919@phenom.dumpdata.com>
References: <20120921121202.3163c379@mantra.us.oracle.com>
	<1348665924.19176.41.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1348665924.19176.41.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: "Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v1 0/8]: PVH (PV guest with extensions)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Sep 26, 2012 at 02:25:24PM +0100, Ian Campbell wrote:
> On Fri, 2012-09-21 at 20:12 +0100, Mukesh Rathor wrote:
> > Hi guys,
> > 
> > Ok, I've made all the changes from prev RFC patch submission. Tested
> > all the combinations. The patches are a bit smaller from before, and
> > couldn't be separated like before, so I can't state whats different in
> > each patch. But, it's not too bad to review now.
> > 
> > As before, they were built on top of
> > fc6bdb59a501740b28ed3b616641a22c8dc5dd31 from the following tree:
> >         
> > git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
> 
> Is that correct? That's this commit:
> 
> commit fc6bdb59a501740b28ed3b616641a22c8dc5dd31
> Merge: 44d82e2 1fcfd08
> Author: Linus Torvalds <torvalds@linux-foundation.org>
> Date:   Thu Aug 2 11:52:39 2012 -0700
> 
> Why so old? Makes it hard to take these for a spin due to the
> rebasing...

I rebased them on top v3.6-rc6 (look in #linux-next-pvh) but I must
have done something wrong b/c it won't boot as PVHVM. Time to do some git
bisection and see where I failed.

> 
> Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 26 13:51:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Sep 2012 13:51:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGs0s-0006W3-Ul; Wed, 26 Sep 2012 13:50:54 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Paul.Durrant@citrix.com>) id 1TGs0s-0006Vv-0J
	for xen-devel@lists.xen.org; Wed, 26 Sep 2012 13:50:54 +0000
Received: from [85.158.139.211:29212] by server-11.bemta-5.messagelabs.com id
	DF/D5-13866-D3803605; Wed, 26 Sep 2012 13:50:53 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-8.tower-206.messagelabs.com!1348667450!20028959!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzE2MjI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 501 invoked from network); 26 Sep 2012 13:50:51 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-8.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Sep 2012 13:50:51 -0000
X-IronPort-AV: E=Sophos;i="4.80,490,1344211200"; d="scan'208";a="39224983"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Sep 2012 13:50:49 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 26 Sep 2012 09:50:49 -0400
Received: from cosworth.uk.xensource.com ([10.80.16.52] ident=pauldu)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<paul.durrant@citrix.com>)	id 1TGs0n-0005OU-9V;
	Wed, 26 Sep 2012 14:50:49 +0100
From: Paul Durrant <paul.durrant@citrix.com>
To: xen-devel@lists.xen.org
Date: Wed, 26 Sep 2012 14:50:36 +0100
Message-ID: <1348667438-28496-1-git-send-email-paul.durrant@citrix.com>
X-Mailer: git-send-email 1.7.2.5
MIME-Version: 1.0
Cc: Paul Durrant <paul.durrant@citrix.com>
Subject: [Xen-devel] [PATCH 0/2] PV drivers product number registration
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

PV drivers in HVM guests typically make use off an 'unplug' protocol in QEMU
to prevent co-existence of emulated devices.
See docs/misc/hvm-emulated-unplug.markdown for details.

The register of product numbers used by the blacklisting feature of this
protocol is currently directly in the xenstore.c source module of traditional
QEMU. It should really be in a Xen header file to prevent duplication/conflict
between QEMU versions.

Moreover the linux PV-on-HVM drivers make use of product number 3 seemingly
without ever registering that number.

This patch series introduces a new header and registers product number 3 for
Linux's use. A subsequent patch to qemu-xen-unstable wll be created to make
use of the new header.

Signed-off-by: Paul Durrant <paul.durrant@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 Sep 26 13:51:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Sep 2012 13:51:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGs0s-0006W3-Ul; Wed, 26 Sep 2012 13:50:54 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Paul.Durrant@citrix.com>) id 1TGs0s-0006Vv-0J
	for xen-devel@lists.xen.org; Wed, 26 Sep 2012 13:50:54 +0000
Received: from [85.158.139.211:29212] by server-11.bemta-5.messagelabs.com id
	DF/D5-13866-D3803605; Wed, 26 Sep 2012 13:50:53 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-8.tower-206.messagelabs.com!1348667450!20028959!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzE2MjI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 501 invoked from network); 26 Sep 2012 13:50:51 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-8.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Sep 2012 13:50:51 -0000
X-IronPort-AV: E=Sophos;i="4.80,490,1344211200"; d="scan'208";a="39224983"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Sep 2012 13:50:49 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 26 Sep 2012 09:50:49 -0400
Received: from cosworth.uk.xensource.com ([10.80.16.52] ident=pauldu)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<paul.durrant@citrix.com>)	id 1TGs0n-0005OU-9V;
	Wed, 26 Sep 2012 14:50:49 +0100
From: Paul Durrant <paul.durrant@citrix.com>
To: xen-devel@lists.xen.org
Date: Wed, 26 Sep 2012 14:50:36 +0100
Message-ID: <1348667438-28496-1-git-send-email-paul.durrant@citrix.com>
X-Mailer: git-send-email 1.7.2.5
MIME-Version: 1.0
Cc: Paul Durrant <paul.durrant@citrix.com>
Subject: [Xen-devel] [PATCH 0/2] PV drivers product number registration
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

PV drivers in HVM guests typically make use off an 'unplug' protocol in QEMU
to prevent co-existence of emulated devices.
See docs/misc/hvm-emulated-unplug.markdown for details.

The register of product numbers used by the blacklisting feature of this
protocol is currently directly in the xenstore.c source module of traditional
QEMU. It should really be in a Xen header file to prevent duplication/conflict
between QEMU versions.

Moreover the linux PV-on-HVM drivers make use of product number 3 seemingly
without ever registering that number.

This patch series introduces a new header and registers product number 3 for
Linux's use. A subsequent patch to qemu-xen-unstable wll be created to make
use of the new header.

Signed-off-by: Paul Durrant <paul.durrant@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 Sep 26 13:51:06 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Sep 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 1TGs0u-0006WP-Ao; Wed, 26 Sep 2012 13:50:56 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Paul.Durrant@citrix.com>) id 1TGs0s-0006W2-RP
	for xen-devel@lists.xen.org; Wed, 26 Sep 2012 13:50:55 +0000
Received: from [85.158.139.211:11881] by server-12.bemta-5.messagelabs.com id
	E6/EA-20729-E3803605; Wed, 26 Sep 2012 13:50:54 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-8.tower-206.messagelabs.com!1348667450!20028959!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzE2MjI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 543 invoked from network); 26 Sep 2012 13:50:53 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-8.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Sep 2012 13:50:53 -0000
X-IronPort-AV: E=Sophos;i="4.80,490,1344211200"; d="scan'208";a="39224984"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Sep 2012 13:50:49 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 26 Sep 2012 09:50:49 -0400
Received: from cosworth.uk.xensource.com ([10.80.16.52] ident=pauldu)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<paul.durrant@citrix.com>)	id 1TGs0n-0005OU-BJ;
	Wed, 26 Sep 2012 14:50:49 +0100
From: Paul Durrant <paul.durrant@citrix.com>
To: xen-devel@lists.xen.org
Date: Wed, 26 Sep 2012 14:50:37 +0100
Message-ID: <1348667438-28496-2-git-send-email-paul.durrant@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1348667438-28496-1-git-send-email-paul.durrant@citrix.com>
References: <1348667438-28496-1-git-send-email-paul.durrant@citrix.com>
MIME-Version: 1.0
Cc: Paul Durrant <paul.durrant@citrix.com>
Subject: [Xen-devel] [PATCH 1/2] Add a new pvdrivers header to serve as the
	register of product numbers.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

These product numbers are used by the QEMU blacklisting protocol in
traditional QEMU and are currently coded directly into the xenstore.c
source module. Since there are now multiple QEMUs this information
should be pulled into a public header to avoid duplication/conflict.
hvm-emulated-unplug.markdown has also been adjusted to reference the
new header.

Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
---
 docs/misc/hvm-emulated-unplug.markdown |    2 +-
 xen/include/public/hvm/pvdrivers.h     |   53 ++++++++++++++++++++++++++++++++
 2 files changed, 54 insertions(+), 1 deletions(-)
 create mode 100644 xen/include/public/hvm/pvdrivers.h

diff --git a/docs/misc/hvm-emulated-unplug.markdown b/docs/misc/hvm-emulated-unplug.markdown
index 707fbab..ec9ce83 100644
--- a/docs/misc/hvm-emulated-unplug.markdown
+++ b/docs/misc/hvm-emulated-unplug.markdown
@@ -65,4 +65,4 @@ decimal number.  `{product_name}` is a string corresponding to the
 product number in step 3.
 
 The master registry of product names and numbers is in
-qemu-xen-unstable's xenstore.c.
+xen/include/public/hvm/pvdrivers.h
diff --git a/xen/include/public/hvm/pvdrivers.h b/xen/include/public/hvm/pvdrivers.h
new file mode 100644
index 0000000..98d61d0
--- /dev/null
+++ b/xen/include/public/hvm/pvdrivers.h
@@ -0,0 +1,53 @@
+/*
+ * pvdrivers.h: Register of PV drivers product numbers.
+ * Copyright (c) 2012, Citrix Systems Inc.
+ * 
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this software and associated documentation files (the "Software"), to
+ * deal in the Software without restriction, including without limitation the
+ * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the Software is
+ * furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+ * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+ * DEALINGS IN THE SOFTWARE.
+ */
+
+#ifndef _XEN_PUBLIC_PVDRIVERS_H_
+#define _XEN_PUBLIC_PVDRIVERS_H_
+
+/*
+ * This is the master registry of product numbers for
+ * PV drivers. 
+ * If you need a new product number allocating, please
+ * post to xen-devel@lists.xen.org.  You should NOT use
+ * a product number without allocating one.
+ * If you maintain a separate versioning and distribution path
+ * for PV drivers you should have a separate product number so
+ * that your drivers can be separated from others.
+ *
+ * During development, you may use the EXPERIMENTAL product ID to
+ * indicate a driver which is yet to be released.
+ *
+ * See docs/misc/hvm-emulated-unplug.markdown for details of how
+ * the product number is used.
+ */
+
+#define	PVDRIVERS_XENSOURCE_WINDOWS_ID		0x0001	/* Citrix */
+#define	PVDRIVERS_XENSOURCE_WINDOWS_NAME	"xensource-windows"
+
+#define	PVDRIVERS_GPLPV_WINDOWS_ID		0x0002	/* James Harper */
+#define	PVDRIVERS_GPLPV_WINDOWS_NAME		"gplpv-windows"
+
+#define	PVDRIVERS_EXPERIMENTAL_ID		0xffff
+#define	PVDRIVERS_EXPERIMENTAL_NAME		"experimental"
+
+#endif /* _XEN_PUBLIC_PVDRIVERS_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 Wed Sep 26 13:51:06 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Sep 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 1TGs0u-0006WP-Ao; Wed, 26 Sep 2012 13:50:56 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Paul.Durrant@citrix.com>) id 1TGs0s-0006W2-RP
	for xen-devel@lists.xen.org; Wed, 26 Sep 2012 13:50:55 +0000
Received: from [85.158.139.211:11881] by server-12.bemta-5.messagelabs.com id
	E6/EA-20729-E3803605; Wed, 26 Sep 2012 13:50:54 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-8.tower-206.messagelabs.com!1348667450!20028959!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzE2MjI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 543 invoked from network); 26 Sep 2012 13:50:53 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-8.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Sep 2012 13:50:53 -0000
X-IronPort-AV: E=Sophos;i="4.80,490,1344211200"; d="scan'208";a="39224984"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Sep 2012 13:50:49 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 26 Sep 2012 09:50:49 -0400
Received: from cosworth.uk.xensource.com ([10.80.16.52] ident=pauldu)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<paul.durrant@citrix.com>)	id 1TGs0n-0005OU-BJ;
	Wed, 26 Sep 2012 14:50:49 +0100
From: Paul Durrant <paul.durrant@citrix.com>
To: xen-devel@lists.xen.org
Date: Wed, 26 Sep 2012 14:50:37 +0100
Message-ID: <1348667438-28496-2-git-send-email-paul.durrant@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1348667438-28496-1-git-send-email-paul.durrant@citrix.com>
References: <1348667438-28496-1-git-send-email-paul.durrant@citrix.com>
MIME-Version: 1.0
Cc: Paul Durrant <paul.durrant@citrix.com>
Subject: [Xen-devel] [PATCH 1/2] Add a new pvdrivers header to serve as the
	register of product numbers.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

These product numbers are used by the QEMU blacklisting protocol in
traditional QEMU and are currently coded directly into the xenstore.c
source module. Since there are now multiple QEMUs this information
should be pulled into a public header to avoid duplication/conflict.
hvm-emulated-unplug.markdown has also been adjusted to reference the
new header.

Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
---
 docs/misc/hvm-emulated-unplug.markdown |    2 +-
 xen/include/public/hvm/pvdrivers.h     |   53 ++++++++++++++++++++++++++++++++
 2 files changed, 54 insertions(+), 1 deletions(-)
 create mode 100644 xen/include/public/hvm/pvdrivers.h

diff --git a/docs/misc/hvm-emulated-unplug.markdown b/docs/misc/hvm-emulated-unplug.markdown
index 707fbab..ec9ce83 100644
--- a/docs/misc/hvm-emulated-unplug.markdown
+++ b/docs/misc/hvm-emulated-unplug.markdown
@@ -65,4 +65,4 @@ decimal number.  `{product_name}` is a string corresponding to the
 product number in step 3.
 
 The master registry of product names and numbers is in
-qemu-xen-unstable's xenstore.c.
+xen/include/public/hvm/pvdrivers.h
diff --git a/xen/include/public/hvm/pvdrivers.h b/xen/include/public/hvm/pvdrivers.h
new file mode 100644
index 0000000..98d61d0
--- /dev/null
+++ b/xen/include/public/hvm/pvdrivers.h
@@ -0,0 +1,53 @@
+/*
+ * pvdrivers.h: Register of PV drivers product numbers.
+ * Copyright (c) 2012, Citrix Systems Inc.
+ * 
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this software and associated documentation files (the "Software"), to
+ * deal in the Software without restriction, including without limitation the
+ * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the Software is
+ * furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+ * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+ * DEALINGS IN THE SOFTWARE.
+ */
+
+#ifndef _XEN_PUBLIC_PVDRIVERS_H_
+#define _XEN_PUBLIC_PVDRIVERS_H_
+
+/*
+ * This is the master registry of product numbers for
+ * PV drivers. 
+ * If you need a new product number allocating, please
+ * post to xen-devel@lists.xen.org.  You should NOT use
+ * a product number without allocating one.
+ * If you maintain a separate versioning and distribution path
+ * for PV drivers you should have a separate product number so
+ * that your drivers can be separated from others.
+ *
+ * During development, you may use the EXPERIMENTAL product ID to
+ * indicate a driver which is yet to be released.
+ *
+ * See docs/misc/hvm-emulated-unplug.markdown for details of how
+ * the product number is used.
+ */
+
+#define	PVDRIVERS_XENSOURCE_WINDOWS_ID		0x0001	/* Citrix */
+#define	PVDRIVERS_XENSOURCE_WINDOWS_NAME	"xensource-windows"
+
+#define	PVDRIVERS_GPLPV_WINDOWS_ID		0x0002	/* James Harper */
+#define	PVDRIVERS_GPLPV_WINDOWS_NAME		"gplpv-windows"
+
+#define	PVDRIVERS_EXPERIMENTAL_ID		0xffff
+#define	PVDRIVERS_EXPERIMENTAL_NAME		"experimental"
+
+#endif /* _XEN_PUBLIC_PVDRIVERS_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 Wed Sep 26 13:51:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Sep 2012 13:51:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGs0v-0006Wg-NA; Wed, 26 Sep 2012 13:50:57 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Paul.Durrant@citrix.com>) id 1TGs0t-0006WD-Q0
	for xen-devel@lists.xen.org; Wed, 26 Sep 2012 13:50:55 +0000
Received: from [85.158.139.211:62031] by server-7.bemta-5.messagelabs.com id
	91/3C-00431-E3803605; Wed, 26 Sep 2012 13:50:54 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-8.tower-206.messagelabs.com!1348667450!20028959!3
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzE2MjI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 685 invoked from network); 26 Sep 2012 13:50:53 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-8.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Sep 2012 13:50:53 -0000
X-IronPort-AV: E=Sophos;i="4.80,490,1344211200"; d="scan'208";a="39224988"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Sep 2012 13:50:50 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 26 Sep 2012 09:50:49 -0400
Received: from cosworth.uk.xensource.com ([10.80.16.52] ident=pauldu)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<paul.durrant@citrix.com>)	id 1TGs0n-0005OU-D4;
	Wed, 26 Sep 2012 14:50:49 +0100
From: Paul Durrant <paul.durrant@citrix.com>
To: xen-devel@lists.xen.org
Date: Wed, 26 Sep 2012 14:50:38 +0100
Message-ID: <1348667438-28496-3-git-send-email-paul.durrant@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1348667438-28496-1-git-send-email-paul.durrant@citrix.com>
References: <1348667438-28496-1-git-send-email-paul.durrant@citrix.com>
MIME-Version: 1.0
Cc: Paul Durrant <paul.durrant@citrix.com>
Subject: [Xen-devel] [PATCH 2/2] Register Linux PV-on-HVM drivers product
	number.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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 already in use despite never being registereed.
See XEN_IOPORT_LINUX_PRODNUM in include/xen/platform_pci.h

Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
---
 xen/include/public/hvm/pvdrivers.h |   10 +++++-----
 1 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/xen/include/public/hvm/pvdrivers.h b/xen/include/public/hvm/pvdrivers.h
index 98d61d0..75fa656 100644
--- a/xen/include/public/hvm/pvdrivers.h
+++ b/xen/include/public/hvm/pvdrivers.h
@@ -28,17 +28,14 @@
  * This is the master registry of product numbers for
  * PV drivers. 
  * If you need a new product number allocating, please
- * post to xen-devel@lists.xen.org.  You should NOT use
+ * post to xen-devel@lists.xensource.com.  You should NOT use
  * a product number without allocating one.
  * If you maintain a separate versioning and distribution path
  * for PV drivers you should have a separate product number so
  * that your drivers can be separated from others.
  *
- * During development, you may use the EXPERIMENTAL product ID to
+ * During development, you may use the product ID to
  * indicate a driver which is yet to be released.
- *
- * See docs/misc/hvm-emulated-unplug.markdown for details of how
- * the product number is used.
  */
 
 #define	PVDRIVERS_XENSOURCE_WINDOWS_ID		0x0001	/* Citrix */
@@ -47,6 +44,9 @@
 #define	PVDRIVERS_GPLPV_WINDOWS_ID		0x0002	/* James Harper */
 #define	PVDRIVERS_GPLPV_WINDOWS_NAME		"gplpv-windows"
 
+#define	PVDRIVERS_LINUX_ID			0x0003	/* platform_pci.h */
+#define	PVDRIVERS_LINUX_NAME			"linux"
+
 #define	PVDRIVERS_EXPERIMENTAL_ID		0xffff
 #define	PVDRIVERS_EXPERIMENTAL_NAME		"experimental"
 
-- 
1.7.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 Sep 26 13:51:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Sep 2012 13:51:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGs0v-0006Wg-NA; Wed, 26 Sep 2012 13:50:57 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Paul.Durrant@citrix.com>) id 1TGs0t-0006WD-Q0
	for xen-devel@lists.xen.org; Wed, 26 Sep 2012 13:50:55 +0000
Received: from [85.158.139.211:62031] by server-7.bemta-5.messagelabs.com id
	91/3C-00431-E3803605; Wed, 26 Sep 2012 13:50:54 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-8.tower-206.messagelabs.com!1348667450!20028959!3
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzE2MjI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 685 invoked from network); 26 Sep 2012 13:50:53 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-8.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Sep 2012 13:50:53 -0000
X-IronPort-AV: E=Sophos;i="4.80,490,1344211200"; d="scan'208";a="39224988"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Sep 2012 13:50:50 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 26 Sep 2012 09:50:49 -0400
Received: from cosworth.uk.xensource.com ([10.80.16.52] ident=pauldu)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<paul.durrant@citrix.com>)	id 1TGs0n-0005OU-D4;
	Wed, 26 Sep 2012 14:50:49 +0100
From: Paul Durrant <paul.durrant@citrix.com>
To: xen-devel@lists.xen.org
Date: Wed, 26 Sep 2012 14:50:38 +0100
Message-ID: <1348667438-28496-3-git-send-email-paul.durrant@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1348667438-28496-1-git-send-email-paul.durrant@citrix.com>
References: <1348667438-28496-1-git-send-email-paul.durrant@citrix.com>
MIME-Version: 1.0
Cc: Paul Durrant <paul.durrant@citrix.com>
Subject: [Xen-devel] [PATCH 2/2] Register Linux PV-on-HVM drivers product
	number.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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 already in use despite never being registereed.
See XEN_IOPORT_LINUX_PRODNUM in include/xen/platform_pci.h

Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
---
 xen/include/public/hvm/pvdrivers.h |   10 +++++-----
 1 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/xen/include/public/hvm/pvdrivers.h b/xen/include/public/hvm/pvdrivers.h
index 98d61d0..75fa656 100644
--- a/xen/include/public/hvm/pvdrivers.h
+++ b/xen/include/public/hvm/pvdrivers.h
@@ -28,17 +28,14 @@
  * This is the master registry of product numbers for
  * PV drivers. 
  * If you need a new product number allocating, please
- * post to xen-devel@lists.xen.org.  You should NOT use
+ * post to xen-devel@lists.xensource.com.  You should NOT use
  * a product number without allocating one.
  * If you maintain a separate versioning and distribution path
  * for PV drivers you should have a separate product number so
  * that your drivers can be separated from others.
  *
- * During development, you may use the EXPERIMENTAL product ID to
+ * During development, you may use the product ID to
  * indicate a driver which is yet to be released.
- *
- * See docs/misc/hvm-emulated-unplug.markdown for details of how
- * the product number is used.
  */
 
 #define	PVDRIVERS_XENSOURCE_WINDOWS_ID		0x0001	/* Citrix */
@@ -47,6 +44,9 @@
 #define	PVDRIVERS_GPLPV_WINDOWS_ID		0x0002	/* James Harper */
 #define	PVDRIVERS_GPLPV_WINDOWS_NAME		"gplpv-windows"
 
+#define	PVDRIVERS_LINUX_ID			0x0003	/* platform_pci.h */
+#define	PVDRIVERS_LINUX_NAME			"linux"
+
 #define	PVDRIVERS_EXPERIMENTAL_ID		0xffff
 #define	PVDRIVERS_EXPERIMENTAL_NAME		"experimental"
 
-- 
1.7.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 Sep 26 13:55:09 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Sep 2012 13:55:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGs4p-0006vs-Dy; Wed, 26 Sep 2012 13: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 1TGs4o-0006vh-4E
	for xen-devel@lists.xen.org; Wed, 26 Sep 2012 13:54:58 +0000
Received: from [85.158.143.35:5215] by server-2.bemta-4.messagelabs.com id
	C7/7B-06610-13903605; Wed, 26 Sep 2012 13:54:57 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1348667693!16415073!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22181 invoked from network); 26 Sep 2012 13:54:55 -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;
	26 Sep 2012 13:54:55 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 26 Sep 2012 14:54:53 +0100
Message-Id: <50632564020000780009E00E@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 26 Sep 2012 14:55:16 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
References: <osstest-13866-mainreport@xen.org>
	<5062CBAA020000780009DE3B@nat28.tlf.novell.com>
In-Reply-To: <5062CBAA020000780009DE3B@nat28.tlf.novell.com>
Mime-Version: 1.0
Content-Disposition: inline
Subject: Re: [Xen-devel] [xen-unstable test] 13866: regressions - trouble:
 broken/fail/pass
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 26.09.12 at 09:32, "Jan Beulich" <JBeulich@suse.com> wrote:
>>>> On 26.09.12 at 00:57, xen.org <ian.jackson@eu.citrix.com> wrote:
>> flight 13866 xen-unstable real [real]
>> http://www.chiark.greenend.org.uk/~xensrcts/logs/13866/ 
>> 
>> Regressions :-(
>> 
>> Tests which did not succeed and are blocking,
>> including tests which could not be run:
>>  test-amd64-i386-xl-credit2    5 xen-boot                  fail REGR. vs. 13825
>>  test-amd64-i386-win-vcpus1    5 xen-boot                  fail REGR. vs. 13825
>>  test-amd64-amd64-pv          10 guest-saverestore         fail REGR. vs. 13825
>>  test-amd64-i386-rhel6hvm-intel  5 xen-boot                fail REGR. vs. 13825
> 
> Looking (as an example) at this failure's log, I can't see what's
> wrong at all - the log suggests that boot completed fine.
> 
> The host, Dom0, and run queue state dumps also don't hint at
> anything being stuck (like wakeups from deep C states not
> happening).
> 
> Nevertheless, the MWAIT idle driver is to be suspected most.
> I'm considering defaulting it to off for now (maybe just for the
> non-ARAT case that I'm not able to test myself), but the issue
> I see with this is that this may then continue to be that way
> forever, if no-one gets to actually look at the problem.

One of the three boxes I have using this new idle driver, when
suppressing ARAT detection, actually exhibits intermittent (but
frequent) hangs, so I apparently now have found a way to
debug what's going on. I'll send a patch in a minute disabling the
feature by default when ARAT isn't there.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 26 13:55:09 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Sep 2012 13:55:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGs4p-0006vs-Dy; Wed, 26 Sep 2012 13: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 1TGs4o-0006vh-4E
	for xen-devel@lists.xen.org; Wed, 26 Sep 2012 13:54:58 +0000
Received: from [85.158.143.35:5215] by server-2.bemta-4.messagelabs.com id
	C7/7B-06610-13903605; Wed, 26 Sep 2012 13:54:57 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1348667693!16415073!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22181 invoked from network); 26 Sep 2012 13:54:55 -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;
	26 Sep 2012 13:54:55 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 26 Sep 2012 14:54:53 +0100
Message-Id: <50632564020000780009E00E@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 26 Sep 2012 14:55:16 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
References: <osstest-13866-mainreport@xen.org>
	<5062CBAA020000780009DE3B@nat28.tlf.novell.com>
In-Reply-To: <5062CBAA020000780009DE3B@nat28.tlf.novell.com>
Mime-Version: 1.0
Content-Disposition: inline
Subject: Re: [Xen-devel] [xen-unstable test] 13866: regressions - trouble:
 broken/fail/pass
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 26.09.12 at 09:32, "Jan Beulich" <JBeulich@suse.com> wrote:
>>>> On 26.09.12 at 00:57, xen.org <ian.jackson@eu.citrix.com> wrote:
>> flight 13866 xen-unstable real [real]
>> http://www.chiark.greenend.org.uk/~xensrcts/logs/13866/ 
>> 
>> Regressions :-(
>> 
>> Tests which did not succeed and are blocking,
>> including tests which could not be run:
>>  test-amd64-i386-xl-credit2    5 xen-boot                  fail REGR. vs. 13825
>>  test-amd64-i386-win-vcpus1    5 xen-boot                  fail REGR. vs. 13825
>>  test-amd64-amd64-pv          10 guest-saverestore         fail REGR. vs. 13825
>>  test-amd64-i386-rhel6hvm-intel  5 xen-boot                fail REGR. vs. 13825
> 
> Looking (as an example) at this failure's log, I can't see what's
> wrong at all - the log suggests that boot completed fine.
> 
> The host, Dom0, and run queue state dumps also don't hint at
> anything being stuck (like wakeups from deep C states not
> happening).
> 
> Nevertheless, the MWAIT idle driver is to be suspected most.
> I'm considering defaulting it to off for now (maybe just for the
> non-ARAT case that I'm not able to test myself), but the issue
> I see with this is that this may then continue to be that way
> forever, if no-one gets to actually look at the problem.

One of the three boxes I have using this new idle driver, when
suppressing ARAT detection, actually exhibits intermittent (but
frequent) hangs, so I apparently now have found a way to
debug what's going on. I'll send a patch in a minute disabling the
feature by default when ARAT isn't there.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 26 13:56:19 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Sep 2012 13:56:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGs5x-00072O-Sz; Wed, 26 Sep 2012 13:56:09 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Paul.Durrant@citrix.com>) id 1TGs5w-000727-Mz
	for xen-devel@lists.xen.org; Wed, 26 Sep 2012 13:56:08 +0000
Received: from [85.158.138.51:9247] by server-4.bemta-3.messagelabs.com id
	BA/2C-14155-77903605; Wed, 26 Sep 2012 13:56:07 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1348667747!31555475!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzE2MjI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19332 invoked from network); 26 Sep 2012 13:55:49 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Sep 2012 13:55:49 -0000
X-IronPort-AV: E=Sophos;i="4.80,490,1344211200"; d="scan'208";a="39225631"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Sep 2012 13:55:02 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 26 Sep 2012 09:54:46 -0400
Received: from cosworth.uk.xensource.com ([10.80.16.52] ident=pauldu)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<paul.durrant@citrix.com>)	id 1TGs4c-0005TG-DE;
	Wed, 26 Sep 2012 14:54:46 +0100
From: Paul Durrant <paul.durrant@citrix.com>
To: xen-devel@lists.xen.org
Date: Wed, 26 Sep 2012 14:54:44 +0100
Message-ID: <1348667684-29202-1-git-send-email-paul.durrant@citrix.com>
X-Mailer: git-send-email 1.7.2.5
MIME-Version: 1.0
Cc: Paul Durrant <paul.durrant@citrix.com>
Subject: [Xen-devel] [PATCH] Use new Xen public header for product numbers
	and names
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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/include/public/hvm/pvdrivers.h has been added as the
register of product numbers used by the blacklisting protocol.
Use the definitions therein rather then locally coded values.

Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
---
 xenstore.c |   30 ++++++++++++++----------------
 1 files changed, 14 insertions(+), 16 deletions(-)

diff --git a/xenstore.c b/xenstore.c
index 1857160..04ae199 100644
--- a/xenstore.c
+++ b/xenstore.c
@@ -23,6 +23,8 @@
 #include "qemu-timer.h"
 #include "qemu-xen.h"
 
+#include <xen/hvm/pvdrivers.h>
+
 struct xs_handle *xsh = NULL;
 static char *media_filename[MAX_DRIVES+1];
 static QEMUTimer *insert_timer = NULL;
@@ -961,22 +963,18 @@ xenstore_pv_driver_build_blacklisted(uint16_t product_nr,
     const char *product;
 
     switch (product_nr) {
-    /*
-     * In qemu-xen-unstable, this is the master registry of product
-     * numbers.  If you need a new product number allocating, please
-     * post to xen-devel@lists.xensource.com.  You should NOT use
-     * an existing product number without allocating one.
-     *
-     * If you maintain a seaparate versioning and distribution path
-     * for PV drivers you should have a separate product number so
-     * that your drivers can be separated from others'.
-     *
-     * During development, you may use the product ID 0xffff to
-     * indicate a driver which is yet to be released.
-     */
-    case 1: product = "xensource-windows";  break; /* Citrix */
-    case 2: product = "gplpv-windows";      break; /* James Harper */
-    case 0xffff: product = "experimental";  break;
+    case PVDRIVERS_XENSOURCE_WINDOWS_ID:
+        product = PVDRIVERS_XENSOURCE_WINDOWS_NAME;
+        break;
+    case PVDRIVERS_GPLPV_WINDOWS_ID:
+        product = PVDRIVERS_GPLPV_WINDOWS_NAME;
+        break;
+    case PVDRIVERS_LINUX_ID:
+        product = PVDRIVERS_LINUX_NAME;
+        break;
+    case PVDRIVERS_EXPERIMENTAL_ID:
+        product = PVDRIVERS_EXPERIMENTAL_NAME; 
+        break;
     default:
         /* Don't know what product this is -> we can't blacklist
          * it. */
-- 
1.7.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 Sep 26 13:56:19 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Sep 2012 13:56:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGs5x-00072O-Sz; Wed, 26 Sep 2012 13:56:09 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Paul.Durrant@citrix.com>) id 1TGs5w-000727-Mz
	for xen-devel@lists.xen.org; Wed, 26 Sep 2012 13:56:08 +0000
Received: from [85.158.138.51:9247] by server-4.bemta-3.messagelabs.com id
	BA/2C-14155-77903605; Wed, 26 Sep 2012 13:56:07 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1348667747!31555475!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzE2MjI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19332 invoked from network); 26 Sep 2012 13:55:49 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Sep 2012 13:55:49 -0000
X-IronPort-AV: E=Sophos;i="4.80,490,1344211200"; d="scan'208";a="39225631"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Sep 2012 13:55:02 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 26 Sep 2012 09:54:46 -0400
Received: from cosworth.uk.xensource.com ([10.80.16.52] ident=pauldu)	by
	ukmail1.uk.xensource.com with esmtp (Exim 4.69)	(envelope-from
	<paul.durrant@citrix.com>)	id 1TGs4c-0005TG-DE;
	Wed, 26 Sep 2012 14:54:46 +0100
From: Paul Durrant <paul.durrant@citrix.com>
To: xen-devel@lists.xen.org
Date: Wed, 26 Sep 2012 14:54:44 +0100
Message-ID: <1348667684-29202-1-git-send-email-paul.durrant@citrix.com>
X-Mailer: git-send-email 1.7.2.5
MIME-Version: 1.0
Cc: Paul Durrant <paul.durrant@citrix.com>
Subject: [Xen-devel] [PATCH] Use new Xen public header for product numbers
	and names
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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/include/public/hvm/pvdrivers.h has been added as the
register of product numbers used by the blacklisting protocol.
Use the definitions therein rather then locally coded values.

Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
---
 xenstore.c |   30 ++++++++++++++----------------
 1 files changed, 14 insertions(+), 16 deletions(-)

diff --git a/xenstore.c b/xenstore.c
index 1857160..04ae199 100644
--- a/xenstore.c
+++ b/xenstore.c
@@ -23,6 +23,8 @@
 #include "qemu-timer.h"
 #include "qemu-xen.h"
 
+#include <xen/hvm/pvdrivers.h>
+
 struct xs_handle *xsh = NULL;
 static char *media_filename[MAX_DRIVES+1];
 static QEMUTimer *insert_timer = NULL;
@@ -961,22 +963,18 @@ xenstore_pv_driver_build_blacklisted(uint16_t product_nr,
     const char *product;
 
     switch (product_nr) {
-    /*
-     * In qemu-xen-unstable, this is the master registry of product
-     * numbers.  If you need a new product number allocating, please
-     * post to xen-devel@lists.xensource.com.  You should NOT use
-     * an existing product number without allocating one.
-     *
-     * If you maintain a seaparate versioning and distribution path
-     * for PV drivers you should have a separate product number so
-     * that your drivers can be separated from others'.
-     *
-     * During development, you may use the product ID 0xffff to
-     * indicate a driver which is yet to be released.
-     */
-    case 1: product = "xensource-windows";  break; /* Citrix */
-    case 2: product = "gplpv-windows";      break; /* James Harper */
-    case 0xffff: product = "experimental";  break;
+    case PVDRIVERS_XENSOURCE_WINDOWS_ID:
+        product = PVDRIVERS_XENSOURCE_WINDOWS_NAME;
+        break;
+    case PVDRIVERS_GPLPV_WINDOWS_ID:
+        product = PVDRIVERS_GPLPV_WINDOWS_NAME;
+        break;
+    case PVDRIVERS_LINUX_ID:
+        product = PVDRIVERS_LINUX_NAME;
+        break;
+    case PVDRIVERS_EXPERIMENTAL_ID:
+        product = PVDRIVERS_EXPERIMENTAL_NAME; 
+        break;
     default:
         /* Don't know what product this is -> we can't blacklist
          * it. */
-- 
1.7.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 Sep 26 14:00:50 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Sep 2012 14:00: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 1TGsAH-0007Ku-Nn; Wed, 26 Sep 2012 14:00:37 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1TGsAF-0007Kl-BM
	for xen-devel@lists.xen.org; Wed, 26 Sep 2012 14:00:35 +0000
Received: from [85.158.139.83:43118] by server-8.bemta-5.messagelabs.com id
	91/BF-18073-28A03605; Wed, 26 Sep 2012 14:00:34 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1348668033!18140585!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24295 invoked from network); 26 Sep 2012 14:00:33 -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;
	26 Sep 2012 14:00:33 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 26 Sep 2012 15:00:33 +0100
Message-Id: <506326B7020000780009E013@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 26 Sep 2012 15:00: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="=__PartD6E7E887.0__="
Subject: [Xen-devel] [PATCH] x86: default-disable MWAIT-based idle driver
 for CPUs without ARAT
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<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.

--=__PartD6E7E887.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Without ARAT, and apparently only when using HPET broadcast mode as
replacement, CPUs occasionally fail to wake up, causing the system to
(transiently) hang. Until the reason is understood, disable the driver
on such systems.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/arch/x86/cpu/mwait-idle.c
+++ b/xen/arch/x86/cpu/mwait-idle.c
@@ -71,7 +71,7 @@
 # define pr_debug(fmt...)
 #endif
=20
-static __initdata bool_t no_mwait_idle;
+static __initdata s8 no_mwait_idle =3D -1;
 invbool_param("mwait-idle", no_mwait_idle);
=20
 static unsigned int mwait_substates;
@@ -500,6 +500,13 @@ int __init mwait_idle_init(struct notifi
 	if (pm_idle_save)
 		return -ENODEV;
=20
+	/* XXX The no-ARAT case is supposedly being taken care of, but at
+	 * least some systems without ARAT hang for some reason, apparently=

+	 * only when using HPET broadcast mode (PIT broadcast mode seems =
to
+	 * be fine). */
+	if (no_mwait_idle < 0 && boot_cpu_has(X86_FEATURE_ARAT))
+		no_mwait_idle =3D 0;
+
 	err =3D mwait_idle_probe();
 	if (!err) {
 		if (!boot_cpu_has(X86_FEATURE_ARAT))




--=__PartD6E7E887.0__=
Content-Type: text/plain; name="x86-mwait-idle-no-ARAT.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="x86-mwait-idle-no-ARAT.patch"

x86: default-disable MWAIT-based idle driver for CPUs without ARAT=0A=0AWit=
hout ARAT, and apparently only when using HPET broadcast mode as=0Areplacem=
ent, CPUs occasionally fail to wake up, causing the system to=0A(transientl=
y) hang. Until the reason is understood, disable the driver=0Aon such =
systems.=0A=0ASigned-off-by: Jan Beulich <jbeulich@suse.com>=0A=0A--- =
a/xen/arch/x86/cpu/mwait-idle.c=0A+++ b/xen/arch/x86/cpu/mwait-idle.c=0A@@ =
-71,7 +71,7 @@=0A # define pr_debug(fmt...)=0A #endif=0A =0A-static =
__initdata bool_t no_mwait_idle;=0A+static __initdata s8 no_mwait_idle =3D =
-1;=0A invbool_param("mwait-idle", no_mwait_idle);=0A =0A static unsigned =
int mwait_substates;=0A@@ -500,6 +500,13 @@ int __init mwait_idle_init(stru=
ct notifi=0A 	if (pm_idle_save)=0A 		return -ENODEV;=0A =0A+	/* =
XXX The no-ARAT case is supposedly being taken care of, but at=0A+	 * =
least some systems without ARAT hang for some reason, apparently=0A+	 * =
only when using HPET broadcast mode (PIT broadcast mode seems to=0A+	 * =
be fine). */=0A+	if (no_mwait_idle < 0 && boot_cpu_has(X86_FEATURE_A=
RAT))=0A+		no_mwait_idle =3D 0;=0A+=0A 	err =3D mwait_idle_=
probe();=0A 	if (!err) {=0A 		if (!boot_cpu_has(X86_FEATURE_ARAT)=
)=0A
--=__PartD6E7E887.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

--=__PartD6E7E887.0__=--


From xen-devel-bounces@lists.xen.org Wed Sep 26 14:00:50 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Sep 2012 14:00: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 1TGsAH-0007Ku-Nn; Wed, 26 Sep 2012 14:00:37 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1TGsAF-0007Kl-BM
	for xen-devel@lists.xen.org; Wed, 26 Sep 2012 14:00:35 +0000
Received: from [85.158.139.83:43118] by server-8.bemta-5.messagelabs.com id
	91/BF-18073-28A03605; Wed, 26 Sep 2012 14:00:34 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1348668033!18140585!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24295 invoked from network); 26 Sep 2012 14:00:33 -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;
	26 Sep 2012 14:00:33 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 26 Sep 2012 15:00:33 +0100
Message-Id: <506326B7020000780009E013@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 26 Sep 2012 15:00: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="=__PartD6E7E887.0__="
Subject: [Xen-devel] [PATCH] x86: default-disable MWAIT-based idle driver
 for CPUs without ARAT
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<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.

--=__PartD6E7E887.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Without ARAT, and apparently only when using HPET broadcast mode as
replacement, CPUs occasionally fail to wake up, causing the system to
(transiently) hang. Until the reason is understood, disable the driver
on such systems.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/arch/x86/cpu/mwait-idle.c
+++ b/xen/arch/x86/cpu/mwait-idle.c
@@ -71,7 +71,7 @@
 # define pr_debug(fmt...)
 #endif
=20
-static __initdata bool_t no_mwait_idle;
+static __initdata s8 no_mwait_idle =3D -1;
 invbool_param("mwait-idle", no_mwait_idle);
=20
 static unsigned int mwait_substates;
@@ -500,6 +500,13 @@ int __init mwait_idle_init(struct notifi
 	if (pm_idle_save)
 		return -ENODEV;
=20
+	/* XXX The no-ARAT case is supposedly being taken care of, but at
+	 * least some systems without ARAT hang for some reason, apparently=

+	 * only when using HPET broadcast mode (PIT broadcast mode seems =
to
+	 * be fine). */
+	if (no_mwait_idle < 0 && boot_cpu_has(X86_FEATURE_ARAT))
+		no_mwait_idle =3D 0;
+
 	err =3D mwait_idle_probe();
 	if (!err) {
 		if (!boot_cpu_has(X86_FEATURE_ARAT))




--=__PartD6E7E887.0__=
Content-Type: text/plain; name="x86-mwait-idle-no-ARAT.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="x86-mwait-idle-no-ARAT.patch"

x86: default-disable MWAIT-based idle driver for CPUs without ARAT=0A=0AWit=
hout ARAT, and apparently only when using HPET broadcast mode as=0Areplacem=
ent, CPUs occasionally fail to wake up, causing the system to=0A(transientl=
y) hang. Until the reason is understood, disable the driver=0Aon such =
systems.=0A=0ASigned-off-by: Jan Beulich <jbeulich@suse.com>=0A=0A--- =
a/xen/arch/x86/cpu/mwait-idle.c=0A+++ b/xen/arch/x86/cpu/mwait-idle.c=0A@@ =
-71,7 +71,7 @@=0A # define pr_debug(fmt...)=0A #endif=0A =0A-static =
__initdata bool_t no_mwait_idle;=0A+static __initdata s8 no_mwait_idle =3D =
-1;=0A invbool_param("mwait-idle", no_mwait_idle);=0A =0A static unsigned =
int mwait_substates;=0A@@ -500,6 +500,13 @@ int __init mwait_idle_init(stru=
ct notifi=0A 	if (pm_idle_save)=0A 		return -ENODEV;=0A =0A+	/* =
XXX The no-ARAT case is supposedly being taken care of, but at=0A+	 * =
least some systems without ARAT hang for some reason, apparently=0A+	 * =
only when using HPET broadcast mode (PIT broadcast mode seems to=0A+	 * =
be fine). */=0A+	if (no_mwait_idle < 0 && boot_cpu_has(X86_FEATURE_A=
RAT))=0A+		no_mwait_idle =3D 0;=0A+=0A 	err =3D mwait_idle_=
probe();=0A 	if (!err) {=0A 		if (!boot_cpu_has(X86_FEATURE_ARAT)=
)=0A
--=__PartD6E7E887.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

--=__PartD6E7E887.0__=--


From xen-devel-bounces@lists.xen.org Wed Sep 26 14:06:25 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Sep 2012 14:06: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 1TGsFg-0007ZT-Ga; Wed, 26 Sep 2012 14:06:12 +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 1TGsFf-0007ZI-Jl
	for Xen-devel@lists.xensource.com; Wed, 26 Sep 2012 14:06:11 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1348668343!11868135!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDc3NTczOQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14943 invoked from network); 26 Sep 2012 14:05:44 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-4.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 26 Sep 2012 14:05:44 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q8QE5bjS009723
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 26 Sep 2012 14:05:38 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q8QE5avI021207
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 26 Sep 2012 14:05:37 GMT
Received: from abhmt109.oracle.com (abhmt109.oracle.com [141.146.116.61])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q8QE5Zoh005676; Wed, 26 Sep 2012 09:05:35 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 26 Sep 2012 07:05:35 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id D814A4032D; Wed, 26 Sep 2012 09:54:18 -0400 (EDT)
Date: Wed, 26 Sep 2012 09:54:18 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Mukesh Rathor <mukesh.rathor@oracle.com>
Message-ID: <20120926135418.GA18392@phenom.dumpdata.com>
References: <20120921121556.1a0ea8af@mantra.us.oracle.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120921121556.1a0ea8af@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] [PATCH v1 2/8]: PVH mmu 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="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

PiBAQCAtMjQsOSArMjQsMTkgQEAgaW50IHhlbl9jcmVhdGVfY29udGlndW91c19yZWdpb24odW5z
aWduZWQgbG9uZyB2c3RhcnQsIHVuc2lnbmVkIGludCBvcmRlciwKPiAgdm9pZCB4ZW5fZGVzdHJv
eV9jb250aWd1b3VzX3JlZ2lvbih1bnNpZ25lZCBsb25nIHZzdGFydCwgdW5zaWduZWQgaW50IG9y
ZGVyKTsKPiAgCj4gIHN0cnVjdCB2bV9hcmVhX3N0cnVjdDsKPiArc3RydWN0IHhlbl9wdmhfcGZu
X2luZm87Cj4gIGludCB4ZW5fcmVtYXBfZG9tYWluX21mbl9yYW5nZShzdHJ1Y3Qgdm1fYXJlYV9z
dHJ1Y3QgKnZtYSwKPiAgCQkJICAgICAgIHVuc2lnbmVkIGxvbmcgYWRkciwKPiAgCQkJICAgICAg
IHVuc2lnbmVkIGxvbmcgbWZuLCBpbnQgbnIsCj4gLQkJCSAgICAgICBwZ3Byb3RfdCBwcm90LCB1
bnNpZ25lZCBkb21pZCk7Cj4gKwkJCSAgICAgICBwZ3Byb3RfdCBwcm90LCB1bnNpZ25lZCBkb21p
ZCwKPiArCQkJICAgICAgIHN0cnVjdCB4ZW5fcHZoX3Bmbl9pbmZvICpwdmhwKTsKClRoaXMgY2hh
bmdlIGR1cmluZyBhIGdpdCBiaXNlY3Rpb24gKHdoZXJlIHdlIG9ubHkgYXBwbGllZCBwYXRjaCAj
MQphbmQgcGF0Y2ggIzIpIHdpbGwgY2F1c2UgYSBidWlsZCBicmVha2FnZSBsaWtlIHRoaXM6Cgov
aG9tZS9rb25yYWQvc3NkL2xpbnV4L2RyaXZlcnMveGVuL3ByaXZjbWQuYzogSW4gZnVuY3Rpb24g
4oCYbW1hcF9tZm5fcmFuZ2XigJk6Ci9ob21lL2tvbnJhZC9zc2QvbGludXgvZHJpdmVycy94ZW4v
cHJpdmNtZC5jOjE4MTogZXJyb3I6IHRvbyBmZXcgYXJndW1lbnRzIHRvIGZ1bmN0aW9uIOKAmHhl
bl9yZW1hcF9kb21haW5fbWZuX3Jhbmdl4oCZCi9ob21lL2tvbnJhZC9zc2QvbGludXgvZHJpdmVy
cy94ZW4vcHJpdmNtZC5jOiBJbiBmdW5jdGlvbiDigJhtbWFwX2JhdGNoX2Zu4oCZOgovaG9tZS9r
b25yYWQvc3NkL2xpbnV4L2RyaXZlcnMveGVuL3ByaXZjbWQuYzoyNzA6IGVycm9yOiB0b28gZmV3
IGFyZ3VtZW50cyB0byBmdW5jdGlvbiDigJh4ZW5fcmVtYXBfZG9tYWluX21mbl9yYW5nZeKAmQpt
YWtlWzRdOiAqKiogW2RyaXZlcnMveGVuL3ByaXZjbWQub10gRXJyb3IgMQptYWtlWzNdOiAqKiog
W2RyaXZlcnMveGVuXSBFcnJvciAyCgoKUGxlYXNlIHNxdWFzaCB0aGlzIHBhdGNoOgoKZGlmZiAt
LWdpdCBhL2RyaXZlcnMveGVuL3ByaXZjbWQuYyBiL2RyaXZlcnMveGVuL3ByaXZjbWQuYwppbmRl
eCBlZjYzODk1Li44MDI3MjBjIDEwMDY0NAotLS0gYS9kcml2ZXJzL3hlbi9wcml2Y21kLmMKKysr
IGIvZHJpdmVycy94ZW4vcHJpdmNtZC5jCkBAIC0xNzgsNyArMTc4LDcgQEAgc3RhdGljIGludCBt
bWFwX21mbl9yYW5nZSh2b2lkICpkYXRhLCB2b2lkICpzdGF0ZSkKIAkJCQkJbXNnLT52YSAmIFBB
R0VfTUFTSywKIAkJCQkJbXNnLT5tZm4sIG1zZy0+bnBhZ2VzLAogCQkJCQl2bWEtPnZtX3BhZ2Vf
cHJvdCwKLQkJCQkJc3QtPmRvbWFpbik7CisJCQkJCXN0LT5kb21haW4sIE5VTEwpOwogCWlmIChy
YyA8IDApCiAJCXJldHVybiByYzsKIApAQCAtMjY3LDcgKzI2Nyw3IEBAIHN0YXRpYyBpbnQgbW1h
cF9iYXRjaF9mbih2b2lkICpkYXRhLCB2b2lkICpzdGF0ZSkKIAlpbnQgcmV0OwogCiAJcmV0ID0g
eGVuX3JlbWFwX2RvbWFpbl9tZm5fcmFuZ2Uoc3QtPnZtYSwgc3QtPnZhICYgUEFHRV9NQVNLLCAq
bWZucCwgMSwKLQkJCQkJIHN0LT52bWEtPnZtX3BhZ2VfcHJvdCwgc3QtPmRvbWFpbik7CisJCQkJ
CSBzdC0+dm1hLT52bV9wYWdlX3Byb3QsIHN0LT5kb21haW4sIE5VTEwpOwogCiAJLyogU3RvcmUg
ZXJyb3IgY29kZSBmb3Igc2Vjb25kIHBhc3MuICovCiAJKihzdC0+ZXJyKyspID0gcmV0OwoKaW50
byB0aGlzIHBhdGNoLgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRw
Oi8vbGlzdHMueGVuLm9yZy94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xen.org Wed Sep 26 14:06:25 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Sep 2012 14:06: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 1TGsFg-0007ZT-Ga; Wed, 26 Sep 2012 14:06:12 +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 1TGsFf-0007ZI-Jl
	for Xen-devel@lists.xensource.com; Wed, 26 Sep 2012 14:06:11 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1348668343!11868135!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDc3NTczOQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14943 invoked from network); 26 Sep 2012 14:05:44 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-4.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 26 Sep 2012 14:05:44 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q8QE5bjS009723
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 26 Sep 2012 14:05:38 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q8QE5avI021207
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 26 Sep 2012 14:05:37 GMT
Received: from abhmt109.oracle.com (abhmt109.oracle.com [141.146.116.61])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q8QE5Zoh005676; Wed, 26 Sep 2012 09:05:35 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 26 Sep 2012 07:05:35 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id D814A4032D; Wed, 26 Sep 2012 09:54:18 -0400 (EDT)
Date: Wed, 26 Sep 2012 09:54:18 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Mukesh Rathor <mukesh.rathor@oracle.com>
Message-ID: <20120926135418.GA18392@phenom.dumpdata.com>
References: <20120921121556.1a0ea8af@mantra.us.oracle.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120921121556.1a0ea8af@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] [PATCH v1 2/8]: PVH mmu 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="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

PiBAQCAtMjQsOSArMjQsMTkgQEAgaW50IHhlbl9jcmVhdGVfY29udGlndW91c19yZWdpb24odW5z
aWduZWQgbG9uZyB2c3RhcnQsIHVuc2lnbmVkIGludCBvcmRlciwKPiAgdm9pZCB4ZW5fZGVzdHJv
eV9jb250aWd1b3VzX3JlZ2lvbih1bnNpZ25lZCBsb25nIHZzdGFydCwgdW5zaWduZWQgaW50IG9y
ZGVyKTsKPiAgCj4gIHN0cnVjdCB2bV9hcmVhX3N0cnVjdDsKPiArc3RydWN0IHhlbl9wdmhfcGZu
X2luZm87Cj4gIGludCB4ZW5fcmVtYXBfZG9tYWluX21mbl9yYW5nZShzdHJ1Y3Qgdm1fYXJlYV9z
dHJ1Y3QgKnZtYSwKPiAgCQkJICAgICAgIHVuc2lnbmVkIGxvbmcgYWRkciwKPiAgCQkJICAgICAg
IHVuc2lnbmVkIGxvbmcgbWZuLCBpbnQgbnIsCj4gLQkJCSAgICAgICBwZ3Byb3RfdCBwcm90LCB1
bnNpZ25lZCBkb21pZCk7Cj4gKwkJCSAgICAgICBwZ3Byb3RfdCBwcm90LCB1bnNpZ25lZCBkb21p
ZCwKPiArCQkJICAgICAgIHN0cnVjdCB4ZW5fcHZoX3Bmbl9pbmZvICpwdmhwKTsKClRoaXMgY2hh
bmdlIGR1cmluZyBhIGdpdCBiaXNlY3Rpb24gKHdoZXJlIHdlIG9ubHkgYXBwbGllZCBwYXRjaCAj
MQphbmQgcGF0Y2ggIzIpIHdpbGwgY2F1c2UgYSBidWlsZCBicmVha2FnZSBsaWtlIHRoaXM6Cgov
aG9tZS9rb25yYWQvc3NkL2xpbnV4L2RyaXZlcnMveGVuL3ByaXZjbWQuYzogSW4gZnVuY3Rpb24g
4oCYbW1hcF9tZm5fcmFuZ2XigJk6Ci9ob21lL2tvbnJhZC9zc2QvbGludXgvZHJpdmVycy94ZW4v
cHJpdmNtZC5jOjE4MTogZXJyb3I6IHRvbyBmZXcgYXJndW1lbnRzIHRvIGZ1bmN0aW9uIOKAmHhl
bl9yZW1hcF9kb21haW5fbWZuX3Jhbmdl4oCZCi9ob21lL2tvbnJhZC9zc2QvbGludXgvZHJpdmVy
cy94ZW4vcHJpdmNtZC5jOiBJbiBmdW5jdGlvbiDigJhtbWFwX2JhdGNoX2Zu4oCZOgovaG9tZS9r
b25yYWQvc3NkL2xpbnV4L2RyaXZlcnMveGVuL3ByaXZjbWQuYzoyNzA6IGVycm9yOiB0b28gZmV3
IGFyZ3VtZW50cyB0byBmdW5jdGlvbiDigJh4ZW5fcmVtYXBfZG9tYWluX21mbl9yYW5nZeKAmQpt
YWtlWzRdOiAqKiogW2RyaXZlcnMveGVuL3ByaXZjbWQub10gRXJyb3IgMQptYWtlWzNdOiAqKiog
W2RyaXZlcnMveGVuXSBFcnJvciAyCgoKUGxlYXNlIHNxdWFzaCB0aGlzIHBhdGNoOgoKZGlmZiAt
LWdpdCBhL2RyaXZlcnMveGVuL3ByaXZjbWQuYyBiL2RyaXZlcnMveGVuL3ByaXZjbWQuYwppbmRl
eCBlZjYzODk1Li44MDI3MjBjIDEwMDY0NAotLS0gYS9kcml2ZXJzL3hlbi9wcml2Y21kLmMKKysr
IGIvZHJpdmVycy94ZW4vcHJpdmNtZC5jCkBAIC0xNzgsNyArMTc4LDcgQEAgc3RhdGljIGludCBt
bWFwX21mbl9yYW5nZSh2b2lkICpkYXRhLCB2b2lkICpzdGF0ZSkKIAkJCQkJbXNnLT52YSAmIFBB
R0VfTUFTSywKIAkJCQkJbXNnLT5tZm4sIG1zZy0+bnBhZ2VzLAogCQkJCQl2bWEtPnZtX3BhZ2Vf
cHJvdCwKLQkJCQkJc3QtPmRvbWFpbik7CisJCQkJCXN0LT5kb21haW4sIE5VTEwpOwogCWlmIChy
YyA8IDApCiAJCXJldHVybiByYzsKIApAQCAtMjY3LDcgKzI2Nyw3IEBAIHN0YXRpYyBpbnQgbW1h
cF9iYXRjaF9mbih2b2lkICpkYXRhLCB2b2lkICpzdGF0ZSkKIAlpbnQgcmV0OwogCiAJcmV0ID0g
eGVuX3JlbWFwX2RvbWFpbl9tZm5fcmFuZ2Uoc3QtPnZtYSwgc3QtPnZhICYgUEFHRV9NQVNLLCAq
bWZucCwgMSwKLQkJCQkJIHN0LT52bWEtPnZtX3BhZ2VfcHJvdCwgc3QtPmRvbWFpbik7CisJCQkJ
CSBzdC0+dm1hLT52bV9wYWdlX3Byb3QsIHN0LT5kb21haW4sIE5VTEwpOwogCiAJLyogU3RvcmUg
ZXJyb3IgY29kZSBmb3Igc2Vjb25kIHBhc3MuICovCiAJKihzdC0+ZXJyKyspID0gcmV0OwoKaW50
byB0aGlzIHBhdGNoLgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRw
Oi8vbGlzdHMueGVuLm9yZy94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xen.org Wed Sep 26 14:14:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Sep 2012 14: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 1TGsN5-0007jZ-EO; Wed, 26 Sep 2012 14:13:51 +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 1TGsN3-0007jR-RL
	for xen-devel@lists.xensource.com; Wed, 26 Sep 2012 14:13:50 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1348668616!11868902!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzY1NzE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28543 invoked from network); 26 Sep 2012 14:10:18 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-4.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 26 Sep 2012 14:10:18 -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 q8QEAD14020807
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 26 Sep 2012 14:10: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
	q8QEACGC000940
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 26 Sep 2012 14:10:12 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
	q8QEAC4B017606; Wed, 26 Sep 2012 09:10:12 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 26 Sep 2012 07:10:11 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id AD46D4032D; Wed, 26 Sep 2012 09:58:55 -0400 (EDT)
Date: Wed, 26 Sep 2012 09:58:55 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: axboe@kernel.dk, linux-kernel@vger.kernel.org
Message-ID: <20120926135855.GA6685@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-jens-3.7
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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,

I've one more patch (a small change) that I was hoping you could
pull in your v3.7 branch.

The branch is:
 git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git stable/for-jens-3.7

and has this tiny patch:

Oliver Chick (1):
      xen/blkback: Change xen_vbd's flush_support and discard_secure to have type unsigned int, rather than bool

 drivers/block/xen-blkback/common.h |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 26 14:14:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Sep 2012 14: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 1TGsN5-0007jZ-EO; Wed, 26 Sep 2012 14:13:51 +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 1TGsN3-0007jR-RL
	for xen-devel@lists.xensource.com; Wed, 26 Sep 2012 14:13:50 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1348668616!11868902!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzY1NzE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28543 invoked from network); 26 Sep 2012 14:10:18 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-4.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 26 Sep 2012 14:10:18 -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 q8QEAD14020807
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 26 Sep 2012 14:10: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
	q8QEACGC000940
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 26 Sep 2012 14:10:12 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
	q8QEAC4B017606; Wed, 26 Sep 2012 09:10:12 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 26 Sep 2012 07:10:11 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id AD46D4032D; Wed, 26 Sep 2012 09:58:55 -0400 (EDT)
Date: Wed, 26 Sep 2012 09:58:55 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: axboe@kernel.dk, linux-kernel@vger.kernel.org
Message-ID: <20120926135855.GA6685@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-jens-3.7
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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,

I've one more patch (a small change) that I was hoping you could
pull in your v3.7 branch.

The branch is:
 git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git stable/for-jens-3.7

and has this tiny patch:

Oliver Chick (1):
      xen/blkback: Change xen_vbd's flush_support and discard_secure to have type unsigned int, rather than bool

 drivers/block/xen-blkback/common.h |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 26 14:15:24 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Sep 2012 14:15:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGsOP-0007my-TT; Wed, 26 Sep 2012 14:15:13 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jmarcet@gmail.com>) id 1TGsOO-0007mq-2n
	for xen-devel@lists.xen.org; Wed, 26 Sep 2012 14:15:12 +0000
Received: from [85.158.137.99:18221] by server-13.bemta-3.messagelabs.com id
	AA/45-11249-FED03605; Wed, 26 Sep 2012 14:15:11 +0000
X-Env-Sender: jmarcet@gmail.com
X-Msg-Ref: server-9.tower-217.messagelabs.com!1348668908!16061539!1
X-Originating-IP: [209.85.219.45]
X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21192 invoked from network); 26 Sep 2012 14:15:10 -0000
Received: from mail-oa0-f45.google.com (HELO mail-oa0-f45.google.com)
	(209.85.219.45)
	by server-9.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Sep 2012 14:15:10 -0000
Received: by oagi18 with SMTP id i18so836759oag.32
	for <xen-devel@lists.xen.org>; Wed, 26 Sep 2012 07:15: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;
	bh=FcjflDLe9PD7MmnYmPDThGxu7iwWQkMqEWHdD/XoRn0=;
	b=V1cjmWAp6VX338FmScbHjmsckWVAmkkvLaanbHuOZCPJ5W1ele9JvlpFfGvKH6gpBO
	YRSJHFUSwKRKN7L1U/ZOO7IxjL96fD6rRMtGmaJH3GGWiJtksUi7VEGvehuiFtQX7wr0
	fDD/NQ57kI8M8lADgU4tUisqoGxP18x//DOOhdoV1wWYJV1zOmkvSrKTEvAhNIW1GdVa
	vRsTCQ9DtozEHmitaRpMgOUGxAGvNt5Uw3ZRfNKwigMAyDgaFZcJbg5+14xUENLvmZKX
	MjKS/4KtZRcan/ntel1/EZtD1nuSktcTJZDmRuc+eKCdWit7Sop3iAwWQoC/GYyKGcR0
	pmDw==
Received: by 10.60.8.39 with SMTP id o7mr497589oea.122.1348668908295; Wed, 26
	Sep 2012 07:15:08 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.60.138.225 with HTTP; Wed, 26 Sep 2012 07:14:48 -0700 (PDT)
In-Reply-To: <20120926124335.GG7356@phenom.dumpdata.com>
References: <CAOvdn6XV4eoA-FfFns1xhx7HCUqXc7KHxZwyKuT4FHG8s3R5RQ@mail.gmail.com>
	<CAAnFQG9PLQjdh6Ab6=Y5ZGM1s4nGdLekKU=pcKNMxt4rmt_RKA@mail.gmail.com>
	<20120924140411.GH31618@phenom.dumpdata.com>
	<CAAnFQG-tjv5UyF6j-TNHNgme2c4vA0Zxy8AdCiJEVsf2Z0quNA@mail.gmail.com>
	<20120925140611.GB16478@phenom.dumpdata.com>
	<CAAnFQG88ApxKuscXx53Lt2qOyCe0ws6oXSSqBDfW0+oYo5Y3nA@mail.gmail.com>
	<5061E800020000780009DBBA@nat28.tlf.novell.com>
	<CAAnFQG-6VrwaA_OcUJL5X5HBNo8PTME9pNyJbsXqSO34tbD8=g@mail.gmail.com>
	<5062C81D020000780009DE2E@nat28.tlf.novell.com>
	<CAAnFQG9f-97RQTt0YNGds6q9FDRcLEOAXrAdZuJw_p=+3opn7Q@mail.gmail.com>
	<20120926124335.GG7356@phenom.dumpdata.com>
From: Javier Marcet <jmarcet@gmail.com>
Date: Wed, 26 Sep 2012 16:14:48 +0200
Message-ID: <CAAnFQG-cJW=h1UFCu3W6AmgarhV7O2Z2xjxfHs=apcyvMthbAg@mail.gmail.com>
To: Konrad Rzeszutek Wilk <konrad@kernel.org>
Cc: Keir Fraser <keir@xen.org>, john.baboval@citrix.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	xen-devel <xen-devel@lists.xen.org>, Ben Guthro <ben@guthro.net>,
	Jan Beulich <JBeulich@suse.com>, Thomas Goetz <thomas.goetz@citrix.com>
Subject: Re: [Xen-devel] Xen4.2 S3 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: multipart/mixed; boundary="===============2491176442452359269=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============2491176442452359269==
Content-Type: multipart/alternative; boundary=e89a8ff1c7e032d4a304ca9b731d

--e89a8ff1c7e032d4a304ca9b731d
Content-Type: text/plain; charset=UTF-8

On Wed, Sep 26, 2012 at 2:43 PM, Konrad Rzeszutek Wilk <konrad@kernel.org>wrote:

> >> Adding the additional call in xen/arch/x86/acpi/cpu_idle.c causes an
> > >> instant reboot on resume.
> > >
> > > That addition can hardly be responsible for a reboot. Did you
> >
> > Just like I could perform a full cycle without issues, the instant
> > reboot might as well be another way the race ends.
> >
> > > have "noreboot" (or "reboot=no") in place on the Xen command
> > > line? "sync_console"?
> >
> > Neither of them. I have used the sync_console parameter to check
> > whether it changed anything but I removed it afterwards.
> >
> > > And then again, for the other failure case, iirc it was the kernel
> > > that died, not the hypervisor, so the problem there isn't directly
> > > related to the problems here I would guess.
> >
> > All I know is that I'm using that same kernel without hypervisor, with
> > lots of suspend/resume and not a single issue.
> >
> > With the two kernel patches from Konrad added I can also suspend and
> > resume fine under the hypervisor but there is always a cpu which
> > receives an irq while offline.
>
> And that error you get - can you reproduce it without going to
> suspend/resume? Meaning if you offline/online a VCPU in the
> guest by manipulating the /sys/../cpuX/online attribute?
>
> And actually - we should move that discussion to a completlty different
> thread as it has nothing to do with the hypervisor. That is a PV kernel
> issue.
>

Konrad, this is on a dom0 with no guest running.


-- 
Javier Marcet <jmarcet@gmail.com>

--e89a8ff1c7e032d4a304ca9b731d
Content-Type: text/html; charset=UTF-8

<div class="gmail_quote">On Wed, Sep 26, 2012 at 2:43 PM, Konrad Rzeszutek Wilk <span dir="ltr">&lt;<a href="mailto:konrad@kernel.org" target="_blank">konrad@kernel.org</a>&gt;</span> wrote:</div><div class="gmail_quote"><br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">&gt; &gt;&gt; Adding the additional call in xen/arch/x86/acpi/cpu_idle.c causes an<br>


&gt; &gt;&gt; instant reboot on resume.<br>
&gt; &gt;<br>
&gt; &gt; That addition can hardly be responsible for a reboot. Did you<br>
&gt;<br>
&gt; Just like I could perform a full cycle without issues, the instant<br>
&gt; reboot might as well be another way the race ends.<br>
&gt;<br>
&gt; &gt; have &quot;noreboot&quot; (or &quot;reboot=no&quot;) in place on the Xen command<br>
&gt; &gt; line? &quot;sync_console&quot;?<br>
&gt;<br>
&gt; Neither of them. I have used the sync_console parameter to check<br>
&gt; whether it changed anything but I removed it afterwards.<br>
&gt;<br>
&gt; &gt; And then again, for the other failure case, iirc it was the kernel<br>
&gt; &gt; that died, not the hypervisor, so the problem there isn&#39;t directly<br>
&gt; &gt; related to the problems here I would guess.<br>
&gt;<br>
&gt; All I know is that I&#39;m using that same kernel without hypervisor, with<br>
&gt; lots of suspend/resume and not a single issue.<br>
&gt;<br>
&gt; With the two kernel patches from Konrad added I can also suspend and<br>
&gt; resume fine under the hypervisor but there is always a cpu which<br>
&gt; receives an irq while offline.<br>
<br>
</div></div>And that error you get - can you reproduce it without going to<br>
suspend/resume? Meaning if you offline/online a VCPU in the<br>
guest by manipulating the /sys/../cpuX/online attribute?<br>
<br>
And actually - we should move that discussion to a completlty different<br>
thread as it has nothing to do with the hypervisor. That is a PV kernel<br>
issue.<br>
</blockquote></div><div><br></div>Konrad, this is on a dom0 with no guest running.<br><br clear="all"><div><br></div>-- <br>Javier Marcet &lt;<a href="mailto:jmarcet@gmail.com" target="_blank">jmarcet@gmail.com</a>&gt;<br>

<br>

--e89a8ff1c7e032d4a304ca9b731d--


--===============2491176442452359269==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============2491176442452359269==--


From xen-devel-bounces@lists.xen.org Wed Sep 26 14:15:24 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Sep 2012 14:15:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGsOP-0007my-TT; Wed, 26 Sep 2012 14:15:13 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jmarcet@gmail.com>) id 1TGsOO-0007mq-2n
	for xen-devel@lists.xen.org; Wed, 26 Sep 2012 14:15:12 +0000
Received: from [85.158.137.99:18221] by server-13.bemta-3.messagelabs.com id
	AA/45-11249-FED03605; Wed, 26 Sep 2012 14:15:11 +0000
X-Env-Sender: jmarcet@gmail.com
X-Msg-Ref: server-9.tower-217.messagelabs.com!1348668908!16061539!1
X-Originating-IP: [209.85.219.45]
X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21192 invoked from network); 26 Sep 2012 14:15:10 -0000
Received: from mail-oa0-f45.google.com (HELO mail-oa0-f45.google.com)
	(209.85.219.45)
	by server-9.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Sep 2012 14:15:10 -0000
Received: by oagi18 with SMTP id i18so836759oag.32
	for <xen-devel@lists.xen.org>; Wed, 26 Sep 2012 07:15: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;
	bh=FcjflDLe9PD7MmnYmPDThGxu7iwWQkMqEWHdD/XoRn0=;
	b=V1cjmWAp6VX338FmScbHjmsckWVAmkkvLaanbHuOZCPJ5W1ele9JvlpFfGvKH6gpBO
	YRSJHFUSwKRKN7L1U/ZOO7IxjL96fD6rRMtGmaJH3GGWiJtksUi7VEGvehuiFtQX7wr0
	fDD/NQ57kI8M8lADgU4tUisqoGxP18x//DOOhdoV1wWYJV1zOmkvSrKTEvAhNIW1GdVa
	vRsTCQ9DtozEHmitaRpMgOUGxAGvNt5Uw3ZRfNKwigMAyDgaFZcJbg5+14xUENLvmZKX
	MjKS/4KtZRcan/ntel1/EZtD1nuSktcTJZDmRuc+eKCdWit7Sop3iAwWQoC/GYyKGcR0
	pmDw==
Received: by 10.60.8.39 with SMTP id o7mr497589oea.122.1348668908295; Wed, 26
	Sep 2012 07:15:08 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.60.138.225 with HTTP; Wed, 26 Sep 2012 07:14:48 -0700 (PDT)
In-Reply-To: <20120926124335.GG7356@phenom.dumpdata.com>
References: <CAOvdn6XV4eoA-FfFns1xhx7HCUqXc7KHxZwyKuT4FHG8s3R5RQ@mail.gmail.com>
	<CAAnFQG9PLQjdh6Ab6=Y5ZGM1s4nGdLekKU=pcKNMxt4rmt_RKA@mail.gmail.com>
	<20120924140411.GH31618@phenom.dumpdata.com>
	<CAAnFQG-tjv5UyF6j-TNHNgme2c4vA0Zxy8AdCiJEVsf2Z0quNA@mail.gmail.com>
	<20120925140611.GB16478@phenom.dumpdata.com>
	<CAAnFQG88ApxKuscXx53Lt2qOyCe0ws6oXSSqBDfW0+oYo5Y3nA@mail.gmail.com>
	<5061E800020000780009DBBA@nat28.tlf.novell.com>
	<CAAnFQG-6VrwaA_OcUJL5X5HBNo8PTME9pNyJbsXqSO34tbD8=g@mail.gmail.com>
	<5062C81D020000780009DE2E@nat28.tlf.novell.com>
	<CAAnFQG9f-97RQTt0YNGds6q9FDRcLEOAXrAdZuJw_p=+3opn7Q@mail.gmail.com>
	<20120926124335.GG7356@phenom.dumpdata.com>
From: Javier Marcet <jmarcet@gmail.com>
Date: Wed, 26 Sep 2012 16:14:48 +0200
Message-ID: <CAAnFQG-cJW=h1UFCu3W6AmgarhV7O2Z2xjxfHs=apcyvMthbAg@mail.gmail.com>
To: Konrad Rzeszutek Wilk <konrad@kernel.org>
Cc: Keir Fraser <keir@xen.org>, john.baboval@citrix.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	xen-devel <xen-devel@lists.xen.org>, Ben Guthro <ben@guthro.net>,
	Jan Beulich <JBeulich@suse.com>, Thomas Goetz <thomas.goetz@citrix.com>
Subject: Re: [Xen-devel] Xen4.2 S3 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: multipart/mixed; boundary="===============2491176442452359269=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============2491176442452359269==
Content-Type: multipart/alternative; boundary=e89a8ff1c7e032d4a304ca9b731d

--e89a8ff1c7e032d4a304ca9b731d
Content-Type: text/plain; charset=UTF-8

On Wed, Sep 26, 2012 at 2:43 PM, Konrad Rzeszutek Wilk <konrad@kernel.org>wrote:

> >> Adding the additional call in xen/arch/x86/acpi/cpu_idle.c causes an
> > >> instant reboot on resume.
> > >
> > > That addition can hardly be responsible for a reboot. Did you
> >
> > Just like I could perform a full cycle without issues, the instant
> > reboot might as well be another way the race ends.
> >
> > > have "noreboot" (or "reboot=no") in place on the Xen command
> > > line? "sync_console"?
> >
> > Neither of them. I have used the sync_console parameter to check
> > whether it changed anything but I removed it afterwards.
> >
> > > And then again, for the other failure case, iirc it was the kernel
> > > that died, not the hypervisor, so the problem there isn't directly
> > > related to the problems here I would guess.
> >
> > All I know is that I'm using that same kernel without hypervisor, with
> > lots of suspend/resume and not a single issue.
> >
> > With the two kernel patches from Konrad added I can also suspend and
> > resume fine under the hypervisor but there is always a cpu which
> > receives an irq while offline.
>
> And that error you get - can you reproduce it without going to
> suspend/resume? Meaning if you offline/online a VCPU in the
> guest by manipulating the /sys/../cpuX/online attribute?
>
> And actually - we should move that discussion to a completlty different
> thread as it has nothing to do with the hypervisor. That is a PV kernel
> issue.
>

Konrad, this is on a dom0 with no guest running.


-- 
Javier Marcet <jmarcet@gmail.com>

--e89a8ff1c7e032d4a304ca9b731d
Content-Type: text/html; charset=UTF-8

<div class="gmail_quote">On Wed, Sep 26, 2012 at 2:43 PM, Konrad Rzeszutek Wilk <span dir="ltr">&lt;<a href="mailto:konrad@kernel.org" target="_blank">konrad@kernel.org</a>&gt;</span> wrote:</div><div class="gmail_quote"><br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">&gt; &gt;&gt; Adding the additional call in xen/arch/x86/acpi/cpu_idle.c causes an<br>


&gt; &gt;&gt; instant reboot on resume.<br>
&gt; &gt;<br>
&gt; &gt; That addition can hardly be responsible for a reboot. Did you<br>
&gt;<br>
&gt; Just like I could perform a full cycle without issues, the instant<br>
&gt; reboot might as well be another way the race ends.<br>
&gt;<br>
&gt; &gt; have &quot;noreboot&quot; (or &quot;reboot=no&quot;) in place on the Xen command<br>
&gt; &gt; line? &quot;sync_console&quot;?<br>
&gt;<br>
&gt; Neither of them. I have used the sync_console parameter to check<br>
&gt; whether it changed anything but I removed it afterwards.<br>
&gt;<br>
&gt; &gt; And then again, for the other failure case, iirc it was the kernel<br>
&gt; &gt; that died, not the hypervisor, so the problem there isn&#39;t directly<br>
&gt; &gt; related to the problems here I would guess.<br>
&gt;<br>
&gt; All I know is that I&#39;m using that same kernel without hypervisor, with<br>
&gt; lots of suspend/resume and not a single issue.<br>
&gt;<br>
&gt; With the two kernel patches from Konrad added I can also suspend and<br>
&gt; resume fine under the hypervisor but there is always a cpu which<br>
&gt; receives an irq while offline.<br>
<br>
</div></div>And that error you get - can you reproduce it without going to<br>
suspend/resume? Meaning if you offline/online a VCPU in the<br>
guest by manipulating the /sys/../cpuX/online attribute?<br>
<br>
And actually - we should move that discussion to a completlty different<br>
thread as it has nothing to do with the hypervisor. That is a PV kernel<br>
issue.<br>
</blockquote></div><div><br></div>Konrad, this is on a dom0 with no guest running.<br><br clear="all"><div><br></div>-- <br>Javier Marcet &lt;<a href="mailto:jmarcet@gmail.com" target="_blank">jmarcet@gmail.com</a>&gt;<br>

<br>

--e89a8ff1c7e032d4a304ca9b731d--


--===============2491176442452359269==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============2491176442452359269==--


From xen-devel-bounces@lists.xen.org Wed Sep 26 14:26:34 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Sep 2012 14: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 1TGsZ8-00081U-35; Wed, 26 Sep 2012 14:26:18 +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 1TGsZ6-00081P-C6
	for xen-devel@lists.xen.org; Wed, 26 Sep 2012 14:26:16 +0000
Received: from [85.158.139.83:24973] by server-16.bemta-5.messagelabs.com id
	00/31-05998-78013605; Wed, 26 Sep 2012 14:26:15 +0000
X-Env-Sender: ben.guthro@gmail.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1348669573!18145461!1
X-Originating-IP: [209.85.223.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-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1785 invoked from network); 26 Sep 2012 14:26:14 -0000
Received: from mail-ie0-f173.google.com (HELO mail-ie0-f173.google.com)
	(209.85.223.173)
	by server-8.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Sep 2012 14:26:14 -0000
Received: by iea17 with SMTP id 17so1968061iea.32
	for <xen-devel@lists.xen.org>; Wed, 26 Sep 2012 07:26:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=references:from:mime-version:in-reply-to:date:message-id:subject:to
	:cc:content-type;
	bh=qpMmt/2XJyaTv6PrCuZV2YiKu04WOCJiIm16cdQpiuU=;
	b=p04n33dddY2ehQHa6U5cd5c8bX8xfw/Vqbg6yVHbOPjYdTWZ2UPBlh3TDaRkfKbAyQ
	QyNEtv/6kF5Q/v4LDhPgZGQKOjYuaMRx/CUEGP3X4DUrINamT/nM/6WVHghneBSjJWWx
	FJkbWQvAOlRupTDzICP8Xpc7eWjTimfo7zrzy4IE0hSMf+3QAw2CMoNT+Dh8eDxAOxXi
	QSokyiLA45qpk/6POhnkUh3SUfQleuk1alqA8/jaqViSqmbygVy7w3BGoVuWu09nwuQI
	1SF3Gj7E3Nc4gMT2ud4Y8meXo86pF6pC9gb6nu0SHvkd94/Ioq5pJjc7bV36SzT/Gzrp
	+6ow==
Received: by 10.50.95.195 with SMTP id dm3mr604969igb.54.1348669572746; Wed,
	26 Sep 2012 07:26:12 -0700 (PDT)
References: <CAOvdn6XV4eoA-FfFns1xhx7HCUqXc7KHxZwyKuT4FHG8s3R5RQ@mail.gmail.com>
	<CAAnFQG9PLQjdh6Ab6=Y5ZGM1s4nGdLekKU=pcKNMxt4rmt_RKA@mail.gmail.com>
	<20120924140411.GH31618@phenom.dumpdata.com>
	<CAAnFQG-tjv5UyF6j-TNHNgme2c4vA0Zxy8AdCiJEVsf2Z0quNA@mail.gmail.com>
	<20120925140611.GB16478@phenom.dumpdata.com>
	<CAAnFQG88ApxKuscXx53Lt2qOyCe0ws6oXSSqBDfW0+oYo5Y3nA@mail.gmail.com>
	<5061E800020000780009DBBA@nat28.tlf.novell.com>
	<CAAnFQG-6VrwaA_OcUJL5X5HBNo8PTME9pNyJbsXqSO34tbD8=g@mail.gmail.com>
	<5062C81D020000780009DE2E@nat28.tlf.novell.com>
	<CAAnFQG9f-97RQTt0YNGds6q9FDRcLEOAXrAdZuJw_p=+3opn7Q@mail.gmail.com>
	<20120926124335.GG7356@phenom.dumpdata.com>
	<CAAnFQG-cJW=h1UFCu3W6AmgarhV7O2Z2xjxfHs=apcyvMthbAg@mail.gmail.com>
From: Ben Guthro <ben.guthro@gmail.com>
Mime-Version: 1.0 (1.0)
In-Reply-To: <CAAnFQG-cJW=h1UFCu3W6AmgarhV7O2Z2xjxfHs=apcyvMthbAg@mail.gmail.com>
Date: Wed, 26 Sep 2012 10:26:10 -0400
Message-ID: <7838417303277258895@unknownmsgid>
To: Javier Marcet <jmarcet@gmail.com>
Cc: Keir Fraser <keir@xen.org>,
	"john.baboval@citrix.com" <john.baboval@citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	xen-devel <xen-devel@lists.xen.org>,
	Konrad Rzeszutek Wilk <konrad@kernel.org>,
	Ben Guthro <ben@guthro.net>, Jan Beulich <JBeulich@suse.com>,
	Thomas Goetz <thomas.goetz@citrix.com>
Subject: Re: [Xen-devel] Xen4.2 S3 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: multipart/mixed; boundary="===============7173399404261529213=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============7173399404261529213==
Content-Type: multipart/alternative; boundary=e89a8f2349cbcd8c9d04ca9b9a90

--e89a8f2349cbcd8c9d04ca9b9a90
Content-Type: text/plain; charset=ISO-8859-1

Yes. Pvops PV dom0 kernel.

It is really more appropriate to start a new thread, than having 2
disparate conversations in this one. It makes it confusing to follow.

On Sep 26, 2012, at 10:15 AM, Javier Marcet <jmarcet@gmail.com> wrote:

On Wed, Sep 26, 2012 at 2:43 PM, Konrad Rzeszutek Wilk <konrad@kernel.org>wrote:

> >> Adding the additional call in xen/arch/x86/acpi/cpu_idle.c causes an
> > >> instant reboot on resume.
> > >
> > > That addition can hardly be responsible for a reboot. Did you
> >
> > Just like I could perform a full cycle without issues, the instant
> > reboot might as well be another way the race ends.
> >
> > > have "noreboot" (or "reboot=no") in place on the Xen command
> > > line? "sync_console"?
> >
> > Neither of them. I have used the sync_console parameter to check
> > whether it changed anything but I removed it afterwards.
> >
> > > And then again, for the other failure case, iirc it was the kernel
> > > that died, not the hypervisor, so the problem there isn't directly
> > > related to the problems here I would guess.
> >
> > All I know is that I'm using that same kernel without hypervisor, with
> > lots of suspend/resume and not a single issue.
> >
> > With the two kernel patches from Konrad added I can also suspend and
> > resume fine under the hypervisor but there is always a cpu which
> > receives an irq while offline.
>
> And that error you get - can you reproduce it without going to
> suspend/resume? Meaning if you offline/online a VCPU in the
> guest by manipulating the /sys/../cpuX/online attribute?
>
> And actually - we should move that discussion to a completlty different
> thread as it has nothing to do with the hypervisor. That is a PV kernel
> issue.
>

Konrad, this is on a dom0 with no guest running.


-- 
Javier Marcet <jmarcet@gmail.com>

--e89a8f2349cbcd8c9d04ca9b9a90
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<html><head><meta http-equiv=3D"content-type" content=3D"text/html; charset=
=3Dutf-8"></head><body dir=3D"auto"><div>Yes. Pvops PV dom0 kernel.=A0</div=
><div><br></div><div>It is really more appropriate to start a new thread, t=
han having 2 disparate conversations in this one. It makes it confusing to =
follow.=A0<br>
<br>On Sep 26, 2012, at 10:15 AM, Javier Marcet &lt;<a href=3D"mailto:jmarc=
et@gmail.com">jmarcet@gmail.com</a>&gt; wrote:<br><br></div><blockquote typ=
e=3D"cite"><div><div class=3D"gmail_quote">On Wed, Sep 26, 2012 at 2:43 PM,=
 Konrad Rzeszutek Wilk <span dir=3D"ltr">&lt;<a href=3D"mailto:konrad@kerne=
l.org" target=3D"_blank">konrad@kernel.org</a>&gt;</span> wrote:</div>
<div class=3D"gmail_quote"><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">&gt;=
 &gt;&gt; Adding the additional call in xen/arch/x86/acpi/cpu_idle.c causes=
 an<br>



&gt; &gt;&gt; instant reboot on resume.<br>
&gt; &gt;<br>
&gt; &gt; That addition can hardly be responsible for a reboot. Did you<br>
&gt;<br>
&gt; Just like I could perform a full cycle without issues, the instant<br>
&gt; reboot might as well be another way the race ends.<br>
&gt;<br>
&gt; &gt; have &quot;noreboot&quot; (or &quot;reboot=3Dno&quot;) in place o=
n the Xen command<br>
&gt; &gt; line? &quot;sync_console&quot;?<br>
&gt;<br>
&gt; Neither of them. I have used the sync_console parameter to check<br>
&gt; whether it changed anything but I removed it afterwards.<br>
&gt;<br>
&gt; &gt; And then again, for the other failure case, iirc it was the kerne=
l<br>
&gt; &gt; that died, not the hypervisor, so the problem there isn&#39;t dir=
ectly<br>
&gt; &gt; related to the problems here I would guess.<br>
&gt;<br>
&gt; All I know is that I&#39;m using that same kernel without hypervisor, =
with<br>
&gt; lots of suspend/resume and not a single issue.<br>
&gt;<br>
&gt; With the two kernel patches from Konrad added I can also suspend and<b=
r>
&gt; resume fine under the hypervisor but there is always a cpu which<br>
&gt; receives an irq while offline.<br>
<br>
</div></div>And that error you get - can you reproduce it without going to<=
br>
suspend/resume? Meaning if you offline/online a VCPU in the<br>
guest by manipulating the /sys/../cpuX/online attribute?<br>
<br>
And actually - we should move that discussion to a completlty different<br>
thread as it has nothing to do with the hypervisor. That is a PV kernel<br>
issue.<br>
</blockquote></div><div><br></div>Konrad, this is on a dom0 with no guest r=
unning.<br><br clear=3D"all"><div><br></div>-- <br>Javier Marcet &lt;<a hre=
f=3D"mailto:jmarcet@gmail.com" target=3D"_blank">jmarcet@gmail.com</a>&gt;<=
br>


<br>
</div></blockquote></body></html>

--e89a8f2349cbcd8c9d04ca9b9a90--


--===============7173399404261529213==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============7173399404261529213==--


From xen-devel-bounces@lists.xen.org Wed Sep 26 14:26:34 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Sep 2012 14: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 1TGsZ8-00081U-35; Wed, 26 Sep 2012 14:26:18 +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 1TGsZ6-00081P-C6
	for xen-devel@lists.xen.org; Wed, 26 Sep 2012 14:26:16 +0000
Received: from [85.158.139.83:24973] by server-16.bemta-5.messagelabs.com id
	00/31-05998-78013605; Wed, 26 Sep 2012 14:26:15 +0000
X-Env-Sender: ben.guthro@gmail.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1348669573!18145461!1
X-Originating-IP: [209.85.223.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-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1785 invoked from network); 26 Sep 2012 14:26:14 -0000
Received: from mail-ie0-f173.google.com (HELO mail-ie0-f173.google.com)
	(209.85.223.173)
	by server-8.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Sep 2012 14:26:14 -0000
Received: by iea17 with SMTP id 17so1968061iea.32
	for <xen-devel@lists.xen.org>; Wed, 26 Sep 2012 07:26:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=references:from:mime-version:in-reply-to:date:message-id:subject:to
	:cc:content-type;
	bh=qpMmt/2XJyaTv6PrCuZV2YiKu04WOCJiIm16cdQpiuU=;
	b=p04n33dddY2ehQHa6U5cd5c8bX8xfw/Vqbg6yVHbOPjYdTWZ2UPBlh3TDaRkfKbAyQ
	QyNEtv/6kF5Q/v4LDhPgZGQKOjYuaMRx/CUEGP3X4DUrINamT/nM/6WVHghneBSjJWWx
	FJkbWQvAOlRupTDzICP8Xpc7eWjTimfo7zrzy4IE0hSMf+3QAw2CMoNT+Dh8eDxAOxXi
	QSokyiLA45qpk/6POhnkUh3SUfQleuk1alqA8/jaqViSqmbygVy7w3BGoVuWu09nwuQI
	1SF3Gj7E3Nc4gMT2ud4Y8meXo86pF6pC9gb6nu0SHvkd94/Ioq5pJjc7bV36SzT/Gzrp
	+6ow==
Received: by 10.50.95.195 with SMTP id dm3mr604969igb.54.1348669572746; Wed,
	26 Sep 2012 07:26:12 -0700 (PDT)
References: <CAOvdn6XV4eoA-FfFns1xhx7HCUqXc7KHxZwyKuT4FHG8s3R5RQ@mail.gmail.com>
	<CAAnFQG9PLQjdh6Ab6=Y5ZGM1s4nGdLekKU=pcKNMxt4rmt_RKA@mail.gmail.com>
	<20120924140411.GH31618@phenom.dumpdata.com>
	<CAAnFQG-tjv5UyF6j-TNHNgme2c4vA0Zxy8AdCiJEVsf2Z0quNA@mail.gmail.com>
	<20120925140611.GB16478@phenom.dumpdata.com>
	<CAAnFQG88ApxKuscXx53Lt2qOyCe0ws6oXSSqBDfW0+oYo5Y3nA@mail.gmail.com>
	<5061E800020000780009DBBA@nat28.tlf.novell.com>
	<CAAnFQG-6VrwaA_OcUJL5X5HBNo8PTME9pNyJbsXqSO34tbD8=g@mail.gmail.com>
	<5062C81D020000780009DE2E@nat28.tlf.novell.com>
	<CAAnFQG9f-97RQTt0YNGds6q9FDRcLEOAXrAdZuJw_p=+3opn7Q@mail.gmail.com>
	<20120926124335.GG7356@phenom.dumpdata.com>
	<CAAnFQG-cJW=h1UFCu3W6AmgarhV7O2Z2xjxfHs=apcyvMthbAg@mail.gmail.com>
From: Ben Guthro <ben.guthro@gmail.com>
Mime-Version: 1.0 (1.0)
In-Reply-To: <CAAnFQG-cJW=h1UFCu3W6AmgarhV7O2Z2xjxfHs=apcyvMthbAg@mail.gmail.com>
Date: Wed, 26 Sep 2012 10:26:10 -0400
Message-ID: <7838417303277258895@unknownmsgid>
To: Javier Marcet <jmarcet@gmail.com>
Cc: Keir Fraser <keir@xen.org>,
	"john.baboval@citrix.com" <john.baboval@citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	xen-devel <xen-devel@lists.xen.org>,
	Konrad Rzeszutek Wilk <konrad@kernel.org>,
	Ben Guthro <ben@guthro.net>, Jan Beulich <JBeulich@suse.com>,
	Thomas Goetz <thomas.goetz@citrix.com>
Subject: Re: [Xen-devel] Xen4.2 S3 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: multipart/mixed; boundary="===============7173399404261529213=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============7173399404261529213==
Content-Type: multipart/alternative; boundary=e89a8f2349cbcd8c9d04ca9b9a90

--e89a8f2349cbcd8c9d04ca9b9a90
Content-Type: text/plain; charset=ISO-8859-1

Yes. Pvops PV dom0 kernel.

It is really more appropriate to start a new thread, than having 2
disparate conversations in this one. It makes it confusing to follow.

On Sep 26, 2012, at 10:15 AM, Javier Marcet <jmarcet@gmail.com> wrote:

On Wed, Sep 26, 2012 at 2:43 PM, Konrad Rzeszutek Wilk <konrad@kernel.org>wrote:

> >> Adding the additional call in xen/arch/x86/acpi/cpu_idle.c causes an
> > >> instant reboot on resume.
> > >
> > > That addition can hardly be responsible for a reboot. Did you
> >
> > Just like I could perform a full cycle without issues, the instant
> > reboot might as well be another way the race ends.
> >
> > > have "noreboot" (or "reboot=no") in place on the Xen command
> > > line? "sync_console"?
> >
> > Neither of them. I have used the sync_console parameter to check
> > whether it changed anything but I removed it afterwards.
> >
> > > And then again, for the other failure case, iirc it was the kernel
> > > that died, not the hypervisor, so the problem there isn't directly
> > > related to the problems here I would guess.
> >
> > All I know is that I'm using that same kernel without hypervisor, with
> > lots of suspend/resume and not a single issue.
> >
> > With the two kernel patches from Konrad added I can also suspend and
> > resume fine under the hypervisor but there is always a cpu which
> > receives an irq while offline.
>
> And that error you get - can you reproduce it without going to
> suspend/resume? Meaning if you offline/online a VCPU in the
> guest by manipulating the /sys/../cpuX/online attribute?
>
> And actually - we should move that discussion to a completlty different
> thread as it has nothing to do with the hypervisor. That is a PV kernel
> issue.
>

Konrad, this is on a dom0 with no guest running.


-- 
Javier Marcet <jmarcet@gmail.com>

--e89a8f2349cbcd8c9d04ca9b9a90
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<html><head><meta http-equiv=3D"content-type" content=3D"text/html; charset=
=3Dutf-8"></head><body dir=3D"auto"><div>Yes. Pvops PV dom0 kernel.=A0</div=
><div><br></div><div>It is really more appropriate to start a new thread, t=
han having 2 disparate conversations in this one. It makes it confusing to =
follow.=A0<br>
<br>On Sep 26, 2012, at 10:15 AM, Javier Marcet &lt;<a href=3D"mailto:jmarc=
et@gmail.com">jmarcet@gmail.com</a>&gt; wrote:<br><br></div><blockquote typ=
e=3D"cite"><div><div class=3D"gmail_quote">On Wed, Sep 26, 2012 at 2:43 PM,=
 Konrad Rzeszutek Wilk <span dir=3D"ltr">&lt;<a href=3D"mailto:konrad@kerne=
l.org" target=3D"_blank">konrad@kernel.org</a>&gt;</span> wrote:</div>
<div class=3D"gmail_quote"><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">&gt;=
 &gt;&gt; Adding the additional call in xen/arch/x86/acpi/cpu_idle.c causes=
 an<br>



&gt; &gt;&gt; instant reboot on resume.<br>
&gt; &gt;<br>
&gt; &gt; That addition can hardly be responsible for a reboot. Did you<br>
&gt;<br>
&gt; Just like I could perform a full cycle without issues, the instant<br>
&gt; reboot might as well be another way the race ends.<br>
&gt;<br>
&gt; &gt; have &quot;noreboot&quot; (or &quot;reboot=3Dno&quot;) in place o=
n the Xen command<br>
&gt; &gt; line? &quot;sync_console&quot;?<br>
&gt;<br>
&gt; Neither of them. I have used the sync_console parameter to check<br>
&gt; whether it changed anything but I removed it afterwards.<br>
&gt;<br>
&gt; &gt; And then again, for the other failure case, iirc it was the kerne=
l<br>
&gt; &gt; that died, not the hypervisor, so the problem there isn&#39;t dir=
ectly<br>
&gt; &gt; related to the problems here I would guess.<br>
&gt;<br>
&gt; All I know is that I&#39;m using that same kernel without hypervisor, =
with<br>
&gt; lots of suspend/resume and not a single issue.<br>
&gt;<br>
&gt; With the two kernel patches from Konrad added I can also suspend and<b=
r>
&gt; resume fine under the hypervisor but there is always a cpu which<br>
&gt; receives an irq while offline.<br>
<br>
</div></div>And that error you get - can you reproduce it without going to<=
br>
suspend/resume? Meaning if you offline/online a VCPU in the<br>
guest by manipulating the /sys/../cpuX/online attribute?<br>
<br>
And actually - we should move that discussion to a completlty different<br>
thread as it has nothing to do with the hypervisor. That is a PV kernel<br>
issue.<br>
</blockquote></div><div><br></div>Konrad, this is on a dom0 with no guest r=
unning.<br><br clear=3D"all"><div><br></div>-- <br>Javier Marcet &lt;<a hre=
f=3D"mailto:jmarcet@gmail.com" target=3D"_blank">jmarcet@gmail.com</a>&gt;<=
br>


<br>
</div></blockquote></body></html>

--e89a8f2349cbcd8c9d04ca9b9a90--


--===============7173399404261529213==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============7173399404261529213==--


From xen-devel-bounces@lists.xen.org Wed Sep 26 14:28:56 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Sep 2012 14:28:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGsbQ-00086k-KZ; Wed, 26 Sep 2012 14:28:40 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <matthew.fioravante@jhuapl.edu>) id 1TGsbO-00086R-T2
	for xen-devel@lists.xensource.com; Wed, 26 Sep 2012 14:28:39 +0000
X-Env-Sender: matthew.fioravante@jhuapl.edu
X-Msg-Ref: server-12.tower-27.messagelabs.com!1348669711!12471797!1
X-Originating-IP: [128.244.251.36]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG,
	UNPARSEABLE_RELAY
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8378 invoked from network); 26 Sep 2012 14:28:32 -0000
Received: from pilot.jhuapl.edu (HELO jhuapl.edu) (128.244.251.36)
	by server-12.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 26 Sep 2012 14:28:32 -0000
Received: from ([128.244.207.89])
	by pilot.jhuapl.edu with ESMTP with TLS id 63GHCH1.153692140;
	Wed, 26 Sep 2012 10:28:25 -0400
Message-ID: <506310BA.9080202@jhuapl.edu>
Date: Wed, 26 Sep 2012 10:27:06 -0400
From: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120827 Thunderbird/15.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <505CBA02.5040308@jhuapl.edu>
	<1348569044.3452.176.camel@zakaz.uk.xensource.com>
	<5061E293.7000106@jhuapl.edu>
	<1348649549.19176.15.camel@zakaz.uk.xensource.com>
In-Reply-To: <1348649549.19176.15.camel@zakaz.uk.xensource.com>
X-Enigmail-Version: 1.4.4
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] PATCH [base vtpm and libxl patches 4/6] add iomem
 support to libxl
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1203492048997987591=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a cryptographically signed message in MIME format.

--===============1203492048997987591==
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms030505060402090605070901"

This is a cryptographically signed message in MIME format.

--------------ms030505060402090605070901
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 09/26/2012 04:52 AM, Ian Campbell wrote:
> On Tue, 2012-09-25 at 17:57 +0100, Matthew Fioravante wrote:
>>>> @@ -1005,6 +1005,30 @@ static void parse_config_data(const char
>>>> *config_source,
>>>>          }
>>>>      }
>>>> =20
>>>> +    if (!xlu_cfg_get_list(config, "iomem", &iomem, &num_iomem, 0)) =
{
>>>> +        b_info->num_iomem =3D num_iomem;
>>>> +        b_info->iomem =3D calloc(num_iomem, sizeof(*b_info->iomem))=
;
>>>> +        if (b_info->iomem =3D=3D NULL) {
>>>> +            fprintf(stderr, "unable to allocate memory for iomem\n"=
);
>>>> +            exit(-1);
>>>> +        }
>>>> +        for (i =3D 0; i < num_iomem; i++) {
>>>> +            buf =3D xlu_cfg_get_listitem (iomem, i);
>>>> +            if (!buf) {
>>>> +                fprintf(stderr,
>>>> +                        "xl: Unable to get element %d in iomem list=
\n", i);
>>>> +                exit(1);
>>>> +            }
>>>> +            if(sscanf(buf, "%" SCNx64",%" SCNu64,
>>>> &b_info->iomem[i].start, &b_info->iomem[i].number) !=3D 2) {
>>> This should be relatively simply to parse with strtoul (see the iopor=
ts
>>> case) which would allow people to select hex or decimal in their
>>> configuration files.
>> Do we want to support hex or decimal? Pretty much anytime people start=

>> talking about physical memory addresses or page numbers they use hex.
>> Also the ioports code actually only supports hexadecimal as it sets th=
e
>> base in strtoul to 16. It also explicitly says in the xl.cfg manpage
>> that ioports should be given in hex.
> Good point. You mix decimal (SCNu64) and hex (SCNx64) though, it would
> be better to be consistent (in hex) I think.
>
> Ian
>
It seemed natural to me that when someone thinks they want N pages they
would think in decimal. It might be better to be hex though for consisten=
cy.


--------------ms030505060402090605070901
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIDyjCC
A8YwggMvoAMCAQICBD/xyf0wDQYJKoZIhvcNAQEFBQAwLzELMAkGA1UEBhMCVVMxDzANBgNV
BAoTBkpIVUFQTDEPMA0GA1UECxMGQklTRENBMB4XDTEwMDYxMTE4MjIwNloXDTEzMDYxMTE4
NTIwNlowZjELMAkGA1UEBhMCVVMxDzANBgNVBAoTBkpIVUFQTDEPMA0GA1UECxMGUGVvcGxl
MTUwFgYDVQQLEw9WUE5Hcm91cC1CSVNEQ0EwGwYDVQQDExRNYXR0aGV3IEUgRmlvcmF2YW50
ZTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAnpbwVSP6o1Nb5lcW7dd3yTo9iBJdi7qz
4nANOMFPK7JOy5npKN1iiousl28U/scUJES55gPwAWYJK3uVyQAsA4adgDKi5DoD1UHDQEwp
bY7iHLJeq0NPr4BqYNqnCFPbE6HC8zSJrr4qKn+gVUQT39SIFqdiIPJwZL8FYTRQ/zsCAwEA
AaOCAbYwggGyMAsGA1UdDwQEAwIHgDArBgNVHRAEJDAigA8yMDEwMDYxMTE4MjIwNlqBDzIw
MTIwNzE3MjI1MjA2WjAbBg0rBgEEAbMlCwMBAQEBBAoWCGZpb3JhbWUxMBsGDSsGAQQBsyUL
AwEBAQIEChIIMDAxMDQyNjEwWAYJYIZIAYb6ax4BBEsMSVRoZSBwcml2YXRlIGtleSBjb3Jy
ZXNwb25kaW5nIHRvIHRoaXMgY2VydGlmaWNhdGUgbWF5IGhhdmUgYmVlbiBleHBvcnRlZC4w
KAYDVR0RBCEwH4EdTWF0dGhldy5GaW9yYXZhbnRlQGpodWFwbC5lZHUwUgYDVR0fBEswSTBH
oEWgQ6RBMD8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJU0RD
QTEOMAwGA1UEAxMFQ1JMNTYwHwYDVR0jBBgwFoAUCDUpmxH52EU2CyWmF2EJMB1yqeswHQYD
VR0OBBYEFO6LYxg6r9wHZ+zdQtBHn1dZ/YTNMAkGA1UdEwQCMAAwGQYJKoZIhvZ9B0EABAww
ChsEVjcuMQMCBLAwDQYJKoZIhvcNAQEFBQADgYEAJO9HQh4YNChVLzuZqK5ARJARD8JoujGZ
fdo75quvg2jXFQe2sEjvLnxJZgm/pv8fdZakq48CWwjYHKuvIp7sDjTEsQfo+y7SpN/N2NvJ
WU5SqfK1VgYtNLRRoGJUB5Q1aZ+Dg95g3kqpyfpUMISJL8IKVLtJVfN4fggFVUYZ9wwxggGr
MIIBpwIBATA3MC8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJ
U0RDQQIEP/HJ/TAJBgUrDgMCGgUAoIHLMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ
KoZIhvcNAQkFMQ8XDTEyMDkyNjE0MjcwNlowIwYJKoZIhvcNAQkEMRYEFNyE8BkhmAkekHZ7
eWWhFkMTZVlMMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAK
BggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI
KoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEgYB5wFhHZc7je8Y3UILszfeHvcQaCuZcMhi0
RMPLli9KclAQSQ1VyoCzmzArsQrWgtEyEieqqkLWkjiowCymV+PN/ZJ1hZH0OK0lxv9IbyOo
mGSC+4iMX6iNLBMQ+SykpNxUnTS9W/sXDc67I7XqhVUEUFAiqfdsKVjk2Mj2YkNhvgAAAAAA
AA==
--------------ms030505060402090605070901--


--===============1203492048997987591==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============1203492048997987591==--


From xen-devel-bounces@lists.xen.org Wed Sep 26 14:28:56 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Sep 2012 14:28:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGsbQ-00086k-KZ; Wed, 26 Sep 2012 14:28:40 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <matthew.fioravante@jhuapl.edu>) id 1TGsbO-00086R-T2
	for xen-devel@lists.xensource.com; Wed, 26 Sep 2012 14:28:39 +0000
X-Env-Sender: matthew.fioravante@jhuapl.edu
X-Msg-Ref: server-12.tower-27.messagelabs.com!1348669711!12471797!1
X-Originating-IP: [128.244.251.36]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG,
	UNPARSEABLE_RELAY
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8378 invoked from network); 26 Sep 2012 14:28:32 -0000
Received: from pilot.jhuapl.edu (HELO jhuapl.edu) (128.244.251.36)
	by server-12.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 26 Sep 2012 14:28:32 -0000
Received: from ([128.244.207.89])
	by pilot.jhuapl.edu with ESMTP with TLS id 63GHCH1.153692140;
	Wed, 26 Sep 2012 10:28:25 -0400
Message-ID: <506310BA.9080202@jhuapl.edu>
Date: Wed, 26 Sep 2012 10:27:06 -0400
From: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120827 Thunderbird/15.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <505CBA02.5040308@jhuapl.edu>
	<1348569044.3452.176.camel@zakaz.uk.xensource.com>
	<5061E293.7000106@jhuapl.edu>
	<1348649549.19176.15.camel@zakaz.uk.xensource.com>
In-Reply-To: <1348649549.19176.15.camel@zakaz.uk.xensource.com>
X-Enigmail-Version: 1.4.4
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] PATCH [base vtpm and libxl patches 4/6] add iomem
 support to libxl
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1203492048997987591=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a cryptographically signed message in MIME format.

--===============1203492048997987591==
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms030505060402090605070901"

This is a cryptographically signed message in MIME format.

--------------ms030505060402090605070901
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 09/26/2012 04:52 AM, Ian Campbell wrote:
> On Tue, 2012-09-25 at 17:57 +0100, Matthew Fioravante wrote:
>>>> @@ -1005,6 +1005,30 @@ static void parse_config_data(const char
>>>> *config_source,
>>>>          }
>>>>      }
>>>> =20
>>>> +    if (!xlu_cfg_get_list(config, "iomem", &iomem, &num_iomem, 0)) =
{
>>>> +        b_info->num_iomem =3D num_iomem;
>>>> +        b_info->iomem =3D calloc(num_iomem, sizeof(*b_info->iomem))=
;
>>>> +        if (b_info->iomem =3D=3D NULL) {
>>>> +            fprintf(stderr, "unable to allocate memory for iomem\n"=
);
>>>> +            exit(-1);
>>>> +        }
>>>> +        for (i =3D 0; i < num_iomem; i++) {
>>>> +            buf =3D xlu_cfg_get_listitem (iomem, i);
>>>> +            if (!buf) {
>>>> +                fprintf(stderr,
>>>> +                        "xl: Unable to get element %d in iomem list=
\n", i);
>>>> +                exit(1);
>>>> +            }
>>>> +            if(sscanf(buf, "%" SCNx64",%" SCNu64,
>>>> &b_info->iomem[i].start, &b_info->iomem[i].number) !=3D 2) {
>>> This should be relatively simply to parse with strtoul (see the iopor=
ts
>>> case) which would allow people to select hex or decimal in their
>>> configuration files.
>> Do we want to support hex or decimal? Pretty much anytime people start=

>> talking about physical memory addresses or page numbers they use hex.
>> Also the ioports code actually only supports hexadecimal as it sets th=
e
>> base in strtoul to 16. It also explicitly says in the xl.cfg manpage
>> that ioports should be given in hex.
> Good point. You mix decimal (SCNu64) and hex (SCNx64) though, it would
> be better to be consistent (in hex) I think.
>
> Ian
>
It seemed natural to me that when someone thinks they want N pages they
would think in decimal. It might be better to be hex though for consisten=
cy.


--------------ms030505060402090605070901
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIDyjCC
A8YwggMvoAMCAQICBD/xyf0wDQYJKoZIhvcNAQEFBQAwLzELMAkGA1UEBhMCVVMxDzANBgNV
BAoTBkpIVUFQTDEPMA0GA1UECxMGQklTRENBMB4XDTEwMDYxMTE4MjIwNloXDTEzMDYxMTE4
NTIwNlowZjELMAkGA1UEBhMCVVMxDzANBgNVBAoTBkpIVUFQTDEPMA0GA1UECxMGUGVvcGxl
MTUwFgYDVQQLEw9WUE5Hcm91cC1CSVNEQ0EwGwYDVQQDExRNYXR0aGV3IEUgRmlvcmF2YW50
ZTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAnpbwVSP6o1Nb5lcW7dd3yTo9iBJdi7qz
4nANOMFPK7JOy5npKN1iiousl28U/scUJES55gPwAWYJK3uVyQAsA4adgDKi5DoD1UHDQEwp
bY7iHLJeq0NPr4BqYNqnCFPbE6HC8zSJrr4qKn+gVUQT39SIFqdiIPJwZL8FYTRQ/zsCAwEA
AaOCAbYwggGyMAsGA1UdDwQEAwIHgDArBgNVHRAEJDAigA8yMDEwMDYxMTE4MjIwNlqBDzIw
MTIwNzE3MjI1MjA2WjAbBg0rBgEEAbMlCwMBAQEBBAoWCGZpb3JhbWUxMBsGDSsGAQQBsyUL
AwEBAQIEChIIMDAxMDQyNjEwWAYJYIZIAYb6ax4BBEsMSVRoZSBwcml2YXRlIGtleSBjb3Jy
ZXNwb25kaW5nIHRvIHRoaXMgY2VydGlmaWNhdGUgbWF5IGhhdmUgYmVlbiBleHBvcnRlZC4w
KAYDVR0RBCEwH4EdTWF0dGhldy5GaW9yYXZhbnRlQGpodWFwbC5lZHUwUgYDVR0fBEswSTBH
oEWgQ6RBMD8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJU0RD
QTEOMAwGA1UEAxMFQ1JMNTYwHwYDVR0jBBgwFoAUCDUpmxH52EU2CyWmF2EJMB1yqeswHQYD
VR0OBBYEFO6LYxg6r9wHZ+zdQtBHn1dZ/YTNMAkGA1UdEwQCMAAwGQYJKoZIhvZ9B0EABAww
ChsEVjcuMQMCBLAwDQYJKoZIhvcNAQEFBQADgYEAJO9HQh4YNChVLzuZqK5ARJARD8JoujGZ
fdo75quvg2jXFQe2sEjvLnxJZgm/pv8fdZakq48CWwjYHKuvIp7sDjTEsQfo+y7SpN/N2NvJ
WU5SqfK1VgYtNLRRoGJUB5Q1aZ+Dg95g3kqpyfpUMISJL8IKVLtJVfN4fggFVUYZ9wwxggGr
MIIBpwIBATA3MC8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJ
U0RDQQIEP/HJ/TAJBgUrDgMCGgUAoIHLMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ
KoZIhvcNAQkFMQ8XDTEyMDkyNjE0MjcwNlowIwYJKoZIhvcNAQkEMRYEFNyE8BkhmAkekHZ7
eWWhFkMTZVlMMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAK
BggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI
KoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEgYB5wFhHZc7je8Y3UILszfeHvcQaCuZcMhi0
RMPLli9KclAQSQ1VyoCzmzArsQrWgtEyEieqqkLWkjiowCymV+PN/ZJ1hZH0OK0lxv9IbyOo
mGSC+4iMX6iNLBMQ+SykpNxUnTS9W/sXDc67I7XqhVUEUFAiqfdsKVjk2Mj2YkNhvgAAAAAA
AA==
--------------ms030505060402090605070901--


--===============1203492048997987591==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============1203492048997987591==--


From xen-devel-bounces@lists.xen.org Wed Sep 26 14:32:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Sep 2012 14:32:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGseQ-0008IM-DY; Wed, 26 Sep 2012 14:31:46 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <matthew.fioravante@jhuapl.edu>) id 1TGseN-0008IB-VT
	for xen-devel@lists.xensource.com; Wed, 26 Sep 2012 14:31:44 +0000
Received: from [85.158.143.99:44566] by server-3.bemta-4.messagelabs.com id
	37/18-10986-FC113605; Wed, 26 Sep 2012 14:31:43 +0000
X-Env-Sender: matthew.fioravante@jhuapl.edu
X-Msg-Ref: server-7.tower-216.messagelabs.com!1348669896!25743595!1
X-Originating-IP: [128.244.251.36]
X-SpamReason: No, hits=0.0 required=7.0 tests=UNPARSEABLE_RELAY
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14349 invoked from network); 26 Sep 2012 14:31:37 -0000
Received: from pilot.jhuapl.edu (HELO jhuapl.edu) (128.244.251.36)
	by server-7.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 26 Sep 2012 14:31:37 -0000
Received: from ([128.244.207.89])
	by pilot.jhuapl.edu with ESMTP with TLS id 63GHCH1.153692445;
	Wed, 26 Sep 2012 10:31:17 -0400
Message-ID: <50631166.5010709@jhuapl.edu>
Date: Wed, 26 Sep 2012 10:29:58 -0400
From: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120827 Thunderbird/15.0
MIME-Version: 1.0
To: George Dunlap <George.Dunlap@eu.citrix.com>
References: <50579F53.4070302@jhuapl.edu>
	<CAFLBxZY+cCBXvT_F-M5b78cQ+Hp+xMeJeE5WGbP+igfWsiTy9w@mail.gmail.com>
In-Reply-To: <CAFLBxZY+cCBXvT_F-M5b78cQ+Hp+xMeJeE5WGbP+igfWsiTy9w@mail.gmail.com>
X-Enigmail-Version: 1.4.4
Cc: Samuel Thibault <samuel.thibault@ens-lyon.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH mini-os enhancements for vtpm 8/8] Add 3 tpm
 drivers to mini-os
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============3681841939449735748=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a cryptographically signed message in MIME format.

--===============3681841939449735748==
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms090403080908030504050400"

This is a cryptographically signed message in MIME format.

--------------ms090403080908030504050400
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On 09/26/2012 09:25 AM, George Dunlap wrote:
> On Mon, Sep 17, 2012 at 11:08 PM, Matthew Fioravante
> <matthew.fioravante@jhuapl.edu> wrote:
>> This patch adds 3 new drivers to mini-os.
>>
>> tpmfront - paravirtualized tpm frontend driver
>> tpmback - paravirtualized tpm backend driver
>> tpm_tis - hardware tpm driver
> Just trying to understand this -- tpmback is so that you can run a
> vtpm instance in the stubdom.  But what is tmpfront for?  Is that for
> running qemu stub domains?
>
>  -George
tpmfront and tpmback are like traditional frontend/backend
paravirtualized xen drivers. vtpm-stubdom uses tpmback to talk to the
linux guest. tpmfront and tpmback are also used by vtpm-stubdom and
vtpmmgrdom to communicate with one another.

The driver chain looks like this.

linux guest [tpm_xenu] -> [tpmback] vtpm-stubdom
[tpmfront]->[tpmback]vtpmmgrdom[tpm_tis]->TPM


>
>> Unfortunately these drivers were derived from GPL licensed linux kerne=
l
>> drivers so they must carry the GPL license. However, since mini-os now=

>> supports conditional compilation, hopefully these drivers can be
>> included into the xen tree and conditionally removed from non-gpl
>> projects. By default they are disabled in the makefile.
>>
>> Signed off by: Matthew Fioravante matthew.fioravante@jhuapl.edu
>>
>> diff --git a/extras/mini-os/Makefile b/extras/mini-os/Makefile
>> --- a/extras/mini-os/Makefile
>> +++ b/extras/mini-os/Makefile
>> @@ -22,6 +22,9 @@ CONFIG_QEMU_XS_ARGS ?=3D n
>>  CONFIG_TEST ?=3D n
>>  CONFIG_PCIFRONT ?=3D n
>>  CONFIG_BLKFRONT ?=3D y
>> +CONFIG_TPMFRONT ?=3D n
>> +CONFIG_TPM_TIS ?=3D n
>> +CONFIG_TPMBACK ?=3D n
>>  CONFIG_NETFRONT ?=3D y
>>  CONFIG_FBFRONT ?=3D y
>>  CONFIG_KBDFRONT ?=3D y
>> @@ -36,6 +39,9 @@ flags-$(CONFIG_SPARSE_BSS) +=3D -DCONFIG_SPARSE_BSS
>>  flags-$(CONFIG_QEMU_XS_ARGS) +=3D -DCONFIG_QEMU_XS_ARGS
>>  flags-$(CONFIG_PCIFRONT) +=3D -DCONFIG_PCIFRONT
>>  flags-$(CONFIG_BLKFRONT) +=3D -DCONFIG_BLKFRONT
>> +flags-$(CONFIG_TPMFRONT) +=3D -DCONFIG_TPMFRONT
>> +flags-$(CONFIG_TPM_TIS) +=3D -DCONFIG_TPM_TIS
>> +flags-$(CONFIG_TPMBACK) +=3D -DCONFIG_TPMBACK
>>  flags-$(CONFIG_NETFRONT) +=3D -DCONFIG_NETFRONT
>>  flags-$(CONFIG_KBDFRONT) +=3D -DCONFIG_KBDFRONT
>>  flags-$(CONFIG_FBFRONT) +=3D -DCONFIG_FBFRONT
>> @@ -67,6 +73,9 @@ TARGET :=3D mini-os
>>  SUBDIRS :=3D lib xenbus console
>>
>>  src-$(CONFIG_BLKFRONT) +=3D blkfront.c
>> +src-$(CONFIG_TPMFRONT) +=3D tpmfront.c
>> +src-$(CONFIG_TPM_TIS) +=3D tpm_tis.c
>> +src-$(CONFIG_TPMBACK) +=3D tpmback.c
>>  src-y +=3D daytime.c
>>  src-y +=3D events.c
>>  src-$(CONFIG_FBFRONT) +=3D fbfront.c
>> diff --git a/extras/mini-os/include/lib.h b/extras/mini-os/include/lib=
=2Eh
>> --- a/extras/mini-os/include/lib.h
>> +++ b/extras/mini-os/include/lib.h
>> @@ -142,6 +142,8 @@ enum fd_type {
>>      FTYPE_FB,
>>      FTYPE_MEM,
>>      FTYPE_SAVEFILE,
>> +    FTYPE_TPMFRONT,
>> +    FTYPE_TPM_TIS,
>>  };
>>
>>  LIST_HEAD(evtchn_port_list, evtchn_port_info);
>> @@ -185,6 +187,20 @@ extern struct file {
>>      struct {
>>          struct consfront_dev *dev;
>>      } cons;
>> +#ifdef CONFIG_TPMFRONT
>> +    struct {
>> +       struct tpmfront_dev *dev;
>> +       int respgot;
>> +       off_t offset;
>> +    } tpmfront;
>> +#endif
>> +#ifdef CONFIG_TPM_TIS
>> +    struct {
>> +       struct tpm_chip *dev;
>> +       int respgot;
>> +       off_t offset;
>> +    } tpm_tis;
>> +#endif
>>  #ifdef CONFIG_XENBUS
>>          struct {
>>              /* To each xenbus FD is associated a queue of watch event=
s
>> for this
>> diff --git a/extras/mini-os/include/tpm_tis.h
>> b/extras/mini-os/include/tpm_tis.h
>> --- /dev/null
>> +++ b/extras/mini-os/include/tpm_tis.h
>> @@ -0,0 +1,63 @@
>> +/*
>> + * Copyright (c) 2010-2012 United States Government, as represented b=
y
>> + * the Secretary of Defense.  All rights reserved.
>> + *
>> + * This driver is free software: you can redistribute it and/or modif=
y
>> + * it under the terms of the GNU General Public License as published =
by
>> + * the Free Software Foundation, either version 3 of the License, or
>> + * (at your option) any later version.
>> + *
>> + * This driver is distributed in the hope that it will be useful,
>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
>> + * GNU General Public License for more details.
>> + *
>> + * You should have received a copy of the GNU General Public License
>> + * along with this program.  If not, see <http://www.gnu.org/licenses=
/>.
>> + *
>> + * Based upon the files:
>> + *  drivers/char/tpm/tpm_tis.c
>> + *  drivers/char/tpm/tpm.c
>> + * from the Linux kernel, which are Copyright (C) 2006 IBM Corporatio=
n
>> + */
>> +#ifndef TPM_TIS_H
>> +#define TPM_TIS_H
>> +
>> +#include <mini-os/types.h>
>> +#include <mini-os/byteorder.h>
>> +
>> +#define TPM_TIS_EN_LOCL0 1
>> +#define TPM_TIS_EN_LOCL1 (1 << 1)
>> +#define TPM_TIS_EN_LOCL2 (1 << 2)
>> +#define TPM_TIS_EN_LOCL3 (1 << 3)
>> +#define TPM_TIS_EN_LOCL4 (1 << 4)
>> +#define TPM_TIS_EN_LOCLALL (TPM_TIS_EN_LOCL0 | TPM_TIS_EN_LOCL1  |
>> TPM_TIS_EN_LOCL2 | TPM_TIS_EN_LOCL3 | TPM_TIS_EN_LOCL4)
>> +#define TPM_TIS_LOCL_INT_TO_FLAG(x) (1 << x)
>> +#define TPM_BASEADDR 0xFED40000
>> +#define TPM_PROBE_IRQ 0xFFFF
>> +
>> +struct tpm_chip;
>> +
>> +struct tpm_chip* init_tpm_tis(unsigned long baseaddr, int localities,=

>> unsigned int irq);
>> +void shutdown_tpm_tis(struct tpm_chip* tpm);
>> +
>> +int tpm_tis_request_locality(struct tpm_chip* tpm, int locality);
>> +int tpm_tis_cmd(struct tpm_chip* tpm, uint8_t* req, size_t reqlen,
>> uint8_t** resp, size_t* resplen);
>> +
>> +#ifdef HAVE_LIBC
>> +#include <sys/stat.h>
>> +#include <fcntl.h>
>> +/* POSIX IO functions:
>> + * use tpm_tis_open() to get a file descriptor to the tpm device
>> + * use write() on the fd to send a command to the backend. You must
>> + * include the entire command in a single call to write().
>> + * use read() on the fd to read the response. You can use
>> + * fstat() to get the size of the response and lseek() to seek on it.=

>> + */
>> +int tpm_tis_open(struct tpm_chip* tpm);
>> +int tpm_tis_posix_read(int fd, uint8_t* buf, size_t count);
>> +int tpm_tis_posix_write(int fd, const uint8_t* buf, size_t count);
>> +int tpm_tis_posix_fstat(int fd, struct stat* buf);
>> +#endif
>> +
>> +#endif
>> diff --git a/extras/mini-os/include/tpmback.h
>> b/extras/mini-os/include/tpmback.h
>> --- /dev/null
>> +++ b/extras/mini-os/include/tpmback.h
>> @@ -0,0 +1,95 @@
>> +/*
>> + * Copyright (c) 2010-2012 United States Government, as represented b=
y
>> + * the Secretary of Defense.  All rights reserved.
>> + *
>> + * This driver is free software: you can redistribute it and/or modif=
y
>> + * it under the terms of the GNU General Public License as published =
by
>> + * the Free Software Foundation, either version 3 of the License, or
>> + * (at your option) any later version.
>> + *
>> + * This driver is distributed in the hope that it will be useful,
>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
>> + * GNU General Public License for more details.
>> + *
>> + * You should have received a copy of the GNU General Public License
>> + * along with this program.  If not, see <http://www.gnu.org/licenses=
/>.
>> + *
>> + * Based upon the files:
>> + *  drivers/xen/tpmbk.c
>> + * from the Linux kernel, which are Copyright (C) 2006 IBM Corporatio=
n
>> + */
>> +#include <xen/io/tpmif.h>
>> +#include <xen/io/xenbus.h>
>> +#include <mini-os/types.h>
>> +#include <xen/xen.h>
>> +#ifndef TPMBACK_H
>> +#define TPMBACK_H
>> +
>> +struct tpmcmd {
>> +   domid_t domid;        /* Domid of the frontend */
>> +   unsigned int handle;    /* Handle of the frontend */
>> +   char* uuid;            /* uuid of the tpm interface - allocated
>> internally, dont free it */
>> +
>> +   unsigned int req_len;        /* Size of the command in buf - set b=
y
>> tpmback driver */
>> +   uint8_t* req;            /* tpm command bits, allocated by driver,=

>> DON'T FREE IT */
>> +   unsigned int resp_len;    /* Size of the outgoing command,
>> +                   you set this before passing the cmd object to
>> tpmback_resp */
>> +   uint8_t* resp;        /* Buffer for response - YOU MUST ALLOCATE I=
T,
>> YOU MUST ALSO FREE IT */
>> +};
>> +typedef struct tpmcmd tpmcmd_t;
>> +
>> +/* Initialize the tpm backend driver
>> + * @exclusive_domname - This is NULL terminated list of vtpm uuid
>> strings. If this list
>> + *             is non-empty, then only frontend domains with vtpm
>> uuid's matching
>> + *             entries in this list will be allowed to connect.
>> + *             Other connections will be immediatly closed.
>> + *             Set this argument to NULL to allow any vtpm to connect=
=2E
>> + */
>> +void init_tpmback(char** exclusive_uuids);
>> +/* Shutdown tpm backend driver */
>> +void shutdown_tpmback(void);
>> +
>> +/* Blocks until a tpm command is sent from any front end.
>> + * Returns a pointer to the tpm command to handle.
>> + * Do not try to free this pointer or the req buffer
>> + * This function will return NULL if the tpm backend driver
>> + * is shutdown or any other error occurs */
>> +tpmcmd_t* tpmback_req_any(void);
>> +
>> +/* Blocks until a tpm command from the frontend at domid/handle
>> + * is sent.
>> + * Returns NULL if domid/handle is not connected, tpmback is
>> + * shutdown or shutting down, or if there is an error
>> + */
>> +tpmcmd_t* tpmback_req(domid_t domid, unsigned int handle);
>> +
>> +/* Send the response to the tpm command back to the frontend
>> + * This function will free the tpmcmd object, but you must free the r=
esp
>> + * buffer yourself */
>> +void tpmback_resp(tpmcmd_t* tpmcmd);
>> +
>> +/* Waits for the first frontend to connect and then sets domid and
>> handle appropriately.
>> + * If one or more frontends are already connected, this will set domi=
d
>> and handle to one
>> + * of them arbitrarily. The main use for this function is to wait unt=
il
>> a single
>> + * frontend connection has occured.
>> + * returns 0 on success, non-zero on failure */
>> +int tpmback_wait_for_frontend_connect(domid_t *domid, unsigned int
>> *handle);
>> +
>> +/* returns the number of frontends connected */
>> +int tpmback_num_frontends(void);
>> +
>> +/* Returns the uuid of the specified frontend, NULL on error */
>> +char* tpmback_get_uuid(domid_t domid, unsigned int handle);
>> +
>> +/* Specify a function to call when a new tpm device connects */
>> +void tpmback_set_open_callback(void (*cb)(domid_t, unsigned int));
>> +
>> +/* Specify a function to call when a tpm device disconnects */
>> +void tpmback_set_close_callback(void (*cb)(domid_t, unsigned int));
>> +
>> +//Not Implemented
>> +void tpmback_set_suspend_callback(void (*cb)(domid_t, unsigned int));=

>> +void tpmback_set_resume_callback(void (*cb)(domid_t, unsigned int));
>> +
>> +#endif
>> diff --git a/extras/mini-os/include/tpmfront.h
>> b/extras/mini-os/include/tpmfront.h
>> --- /dev/null
>> +++ b/extras/mini-os/include/tpmfront.h
>> @@ -0,0 +1,94 @@
>> +/*
>> + * Copyright (c) 2010-2012 United States Government, as represented b=
y
>> + * the Secretary of Defense.  All rights reserved.
>> + *
>> + * This driver is free software: you can redistribute it and/or modif=
y
>> + * it under the terms of the GNU General Public License as published =
by
>> + * the Free Software Foundation, either version 3 of the License, or
>> + * (at your option) any later version.
>> + *
>> + * This driver is distributed in the hope that it will be useful,
>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
>> + * GNU General Public License for more details.
>> + *
>> + * You should have received a copy of the GNU General Public License
>> + * along with this program.  If not, see <http://www.gnu.org/licenses=
/>.
>> + *
>> + * Based upon the files:
>> + *  drivers/char/tpm/tpm_vtpm.c
>> + *  drivers/char/tpm/tpm_xen.c
>> + * from the Linux kernel, which are Copyright (C) 2006 IBM Corporatio=
n
>> + */
>> +#ifndef TPMFRONT_H
>> +#define TPMFRONT_H
>> +
>> +#include <mini-os/types.h>
>> +#include <mini-os/os.h>
>> +#include <mini-os/events.h>
>> +#include <mini-os/wait.h>
>> +#include <xen/xen.h>
>> +#include <xen/io/xenbus.h>
>> +#include <xen/io/tpmif.h>
>> +
>> +struct tpmfront_dev {
>> +   grant_ref_t ring_ref;
>> +   evtchn_port_t evtchn;
>> +
>> +   tpmif_tx_interface_t* tx;
>> +
>> +   void** pages;
>> +
>> +   domid_t bedomid;
>> +   char* nodename;
>> +   char* bepath;
>> +
>> +   XenbusState state;
>> +
>> +   uint8_t waiting;
>> +   struct wait_queue_head waitq;
>> +
>> +   uint8_t* respbuf;
>> +   size_t resplen;
>> +
>> +#ifdef HAVE_LIBC
>> +   int fd;
>> +#endif
>> +
>> +};
>> +
>> +
>> +/*Initialize frontend */
>> +struct tpmfront_dev* init_tpmfront(const char* nodename);
>> +/*Shutdown frontend */
>> +void shutdown_tpmfront(struct tpmfront_dev* dev);
>> +
>> +/* Send a tpm command to the backend and wait for the response
>> + *
>> + * @dev - frontend device
>> + * @req - request buffer
>> + * @reqlen - length of request buffer
>> + * @resp - *resp will be set to internal response buffer, don't free
>> it! Value is undefined on error
>> + * @resplen - *resplen will be set to the length of the response. Val=
ue
>> is undefined on error
>> + *
>> + * returns 0 on success, non zero on failure.
>> + * */
>> +int tpmfront_cmd(struct tpmfront_dev* dev, uint8_t* req, size_t reqle=
n,
>> uint8_t** resp, size_t* resplen);
>> +
>> +#ifdef HAVE_LIBC
>> +#include <sys/stat.h>
>> +/* POSIX IO functions:
>> + * use tpmfront_open() to get a file descriptor to the tpm device
>> + * use write() on the fd to send a command to the backend. You must
>> + * include the entire command in a single call to write().
>> + * use read() on the fd to read the response. You can use
>> + * fstat() to get the size of the response and lseek() to seek on it.=

>> + */
>> +int tpmfront_open(struct tpmfront_dev* dev);
>> +int tpmfront_posix_read(int fd, uint8_t* buf, size_t count);
>> +int tpmfront_posix_write(int fd, const uint8_t* buf, size_t count);
>> +int tpmfront_posix_fstat(int fd, struct stat* buf);
>> +#endif
>> +
>> +
>> +#endif
>> diff --git a/extras/mini-os/lib/sys.c b/extras/mini-os/lib/sys.c
>> --- a/extras/mini-os/lib/sys.c
>> +++ b/extras/mini-os/lib/sys.c
>> @@ -27,6 +27,8 @@
>>  #include <netfront.h>
>>  #include <blkfront.h>
>>  #include <fbfront.h>
>> +#include <tpmfront.h>
>> +#include <tpm_tis.h>
>>  #include <xenbus.h>
>>  #include <xenstore.h>
>>
>> @@ -294,6 +296,16 @@ int read(int fd, void *buf, size_t nbytes)
>>          return blkfront_posix_read(fd, buf, nbytes);
>>          }
>>  #endif
>> +#ifdef CONFIG_TPMFRONT
>> +        case FTYPE_TPMFRONT: {
>> +        return tpmfront_posix_read(fd, buf, nbytes);
>> +        }
>> +#endif
>> +#ifdef CONFIG_TPM_TIS
>> +        case FTYPE_TPM_TIS: {
>> +        return tpm_tis_posix_read(fd, buf, nbytes);
>> +        }
>> +#endif
>>      default:
>>          break;
>>      }
>> @@ -330,6 +342,14 @@ int write(int fd, const void *buf, size_t nbytes)=

>>      case FTYPE_BLK:
>>          return blkfront_posix_write(fd, buf, nbytes);
>>  #endif
>> +#ifdef CONFIG_TPMFRONT
>> +    case FTYPE_TPMFRONT:
>> +        return tpmfront_posix_write(fd, buf, nbytes);
>> +#endif
>> +#ifdef CONFIG_TPM_TIS
>> +    case FTYPE_TPM_TIS:
>> +        return tpm_tis_posix_write(fd, buf, nbytes);
>> +#endif
>>      default:
>>          break;
>>      }
>> @@ -341,8 +361,16 @@ int write(int fd, const void *buf, size_t nbytes)=

>>  off_t lseek(int fd, off_t offset, int whence)
>>  {
>>      switch(files[fd].type) {
>> +#if defined(CONFIG_BLKFRONT) || defined(CONFIG_TPMFRONT) ||
>> defined(CONFIG_TPM_TIS)
>>  #ifdef CONFIG_BLKFRONT
>>         case FTYPE_BLK:
>> +#endif
>> +#ifdef CONFIG_TPMFRNT
>> +       case FTYPE_TPMFRONT:
>> +#endif
>> +#ifdef CONFIG_TPM_TIS
>> +       case FTYPE_TPM_TIS:
>> +#endif
>>        switch (whence) {
>>           case SEEK_SET:
>>          files[fd].file.offset =3D offset;
>> @@ -420,6 +448,18 @@ int close(int fd)
>>          files[fd].type =3D FTYPE_NONE;
>>          return 0;
>>  #endif
>> +#ifdef CONFIG_TPMFRONT
>> +    case FTYPE_TPMFRONT:
>> +            shutdown_tpmfront(files[fd].tpmfront.dev);
>> +        files[fd].type =3D FTYPE_NONE;
>> +        return 0;
>> +#endif
>> +#ifdef CONFIG_TPM_TIS
>> +    case FTYPE_TPM_TIS:
>> +            shutdown_tpm_tis(files[fd].tpm_tis.dev);
>> +        files[fd].type =3D FTYPE_NONE;
>> +        return 0;
>> +#endif
>>  #ifdef CONFIG_KBDFRONT
>>      case FTYPE_KBD:
>>              shutdown_kbdfront(files[fd].kbd.dev);
>> @@ -489,6 +529,14 @@ int fstat(int fd, struct stat *buf)
>>      case FTYPE_BLK:
>>         return blkfront_posix_fstat(fd, buf);
>>  #endif
>> +#ifdef CONFIG_TPMFRONT
>> +    case FTYPE_TPMFRONT:
>> +       return tpmfront_posix_fstat(fd, buf);
>> +#endif
>> +#ifdef CONFIG_TPM_TIS
>> +    case FTYPE_TPM_TIS:
>> +       return tpm_tis_posix_fstat(fd, buf);
>> +#endif
>>      default:
>>          break;
>>      }
>> diff --git a/extras/mini-os/tpm_tis.c b/extras/mini-os/tpm_tis.c
>> --- /dev/null
>> +++ b/extras/mini-os/tpm_tis.c
>> @@ -0,0 +1,1344 @@
>> +/*
>> + * Copyright (c) 2010-2012 United States Government, as represented b=
y
>> + * the Secretary of Defense.  All rights reserved.
>> + *
>> + * This driver is free software: you can redistribute it and/or modif=
y
>> + * it under the terms of the GNU General Public License as published =
by
>> + * the Free Software Foundation, either version 3 of the License, or
>> + * (at your option) any later version.
>> + *
>> + * This driver is distributed in the hope that it will be useful,
>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
>> + * GNU General Public License for more details.
>> + *
>> + * You should have received a copy of the GNU General Public License
>> + * along with this program.  If not, see <http://www.gnu.org/licenses=
/>.
>> + *
>> + * Based upon the files:
>> + *  drivers/char/tpm/tpm_tis.c
>> + *  drivers/char/tpm/tpm.c
>> + * from the Linux kernel, which are Copyright (C) 2006 IBM Corporatio=
n
>> + */
>> +#include <mini-os/ioremap.h>
>> +#include <mini-os/iorw.h>
>> +#include <mini-os/tpm_tis.h>
>> +#include <mini-os/os.h>
>> +#include <mini-os/sched.h>
>> +#include <mini-os/byteorder.h>
>> +#include <mini-os/events.h>
>> +#include <mini-os/wait.h>
>> +#include <mini-os/xmalloc.h>
>> +#include <errno.h>
>> +#include <stdbool.h>
>> +
>> +#ifndef min
>> +    #define min( a, b ) ( ((a) < (b)) ? (a) : (b) )
>> +#endif
>> +
>> +#define TPM_HEADER_SIZE 10
>> +
>> +#define TPM_BUFSIZE 2048
>> +
>> +struct tpm_input_header {
>> +        uint16_t  tag;
>> +        uint32_t  length;
>> +        uint32_t  ordinal;
>> +}__attribute__((packed));
>> +
>> +struct tpm_output_header {
>> +        uint16_t  tag;
>> +        uint32_t  length;
>> +        uint32_t  return_code;
>> +}__attribute__((packed));
>> +
>> +struct  stclear_flags_t {
>> +        uint16_t  tag;
>> +        uint8_t      deactivated;
>> +        uint8_t      disableForceClear;
>> +        uint8_t      physicalPresence;
>> +        uint8_t      physicalPresenceLock;
>> +        uint8_t      bGlobalLock;
>> +}__attribute__((packed));
>> +
>> +struct  tpm_version_t {
>> +        uint8_t      Major;
>> +        uint8_t      Minor;
>> +        uint8_t      revMajor;
>> +        uint8_t      revMinor;
>> +}__attribute__((packed));
>> +
>> +struct  tpm_version_1_2_t {
>> +        uint16_t  tag;
>> +        uint8_t      Major;
>> +        uint8_t      Minor;
>> +        uint8_t      revMajor;
>> +        uint8_t      revMinor;
>> +}__attribute__((packed));
>> +
>> +struct  timeout_t {
>> +        uint32_t  a;
>> +        uint32_t  b;
>> +        uint32_t  c;
>> +        uint32_t  d;
>> +}__attribute__((packed));
>> +
>> +struct duration_t {
>> +        uint32_t  tpm_short;
>> +        uint32_t  tpm_medium;
>> +        uint32_t  tpm_long;
>> +}__attribute__((packed));
>> +
>> +struct permanent_flags_t {
>> +        uint16_t  tag;
>> +        uint8_t      disable;
>> +        uint8_t      ownership;
>> +        uint8_t      deactivated;
>> +        uint8_t      readPubek;
>> +        uint8_t      disableOwnerClear;
>> +        uint8_t      allowMaintenance;
>> +        uint8_t      physicalPresenceLifetimeLock;
>> +        uint8_t      physicalPresenceHWEnable;
>> +        uint8_t      physicalPresenceCMDEnable;
>> +        uint8_t      CEKPUsed;
>> +        uint8_t      TPMpost;
>> +        uint8_t      TPMpostLock;
>> +        uint8_t      FIPS;
>> +        uint8_t      operator;
>> +        uint8_t      enableRevokeEK;
>> +        uint8_t      nvLocked;
>> +        uint8_t      readSRKPub;
>> +        uint8_t      tpmEstablished;
>> +        uint8_t      maintenanceDone;
>> +        uint8_t      disableFullDALogicInfo;
>> +}__attribute__((packed));
>> +
>> +typedef union {
>> +        struct  permanent_flags_t perm_flags;
>> +        struct  stclear_flags_t stclear_flags;
>> +        bool    owned;
>> +        uint32_t  num_pcrs;
>> +        struct  tpm_version_t   tpm_version;
>> +        struct  tpm_version_1_2_t tpm_version_1_2;
>> +        uint32_t  manufacturer_id;
>> +        struct timeout_t  timeout;
>> +        struct duration_t duration;
>> +} cap_t;
>> +
>> +struct  tpm_getcap_params_in {
>> +        uint32_t  cap;
>> +        uint32_t  subcap_size;
>> +        uint32_t  subcap;
>> +}__attribute__((packed));
>> +
>> +struct  tpm_getcap_params_out {
>> +        uint32_t  cap_size;
>> +        cap_t   cap;
>> +}__attribute__((packed));
>> +
>> +struct  tpm_readpubek_params_out {
>> +        uint8_t      algorithm[4];
>> +        uint8_t      encscheme[2];
>> +        uint8_t      sigscheme[2];
>> +        uint32_t  paramsize;
>> +        uint8_t      parameters[12]; /*assuming RSA*/
>> +        uint32_t  keysize;
>> +        uint8_t      modulus[256];
>> +        uint8_t      checksum[20];
>> +}__attribute__((packed));
>> +
>> +typedef union {
>> +        struct  tpm_input_header in;
>> +        struct  tpm_output_header out;
>> +} tpm_cmd_header;
>> +
>> +#define TPM_DIGEST_SIZE 20
>> +struct tpm_pcrread_out {
>> +        uint8_t      pcr_result[TPM_DIGEST_SIZE];
>> +}__attribute__((packed));
>> +
>> +struct tpm_pcrread_in {
>> +        uint32_t  pcr_idx;
>> +}__attribute__((packed));
>> +
>> +struct tpm_pcrextend_in {
>> +        uint32_t  pcr_idx;
>> +        uint8_t      hash[TPM_DIGEST_SIZE];
>> +}__attribute__((packed));
>> +
>> +typedef union {
>> +        struct  tpm_getcap_params_out getcap_out;
>> +        struct  tpm_readpubek_params_out readpubek_out;
>> +        uint8_t      readpubek_out_buffer[sizeof(struct
>> tpm_readpubek_params_out)];
>> +        struct  tpm_getcap_params_in getcap_in;
>> +        struct  tpm_pcrread_in  pcrread_in;
>> +        struct  tpm_pcrread_out pcrread_out;
>> +        struct  tpm_pcrextend_in pcrextend_in;
>> +} tpm_cmd_params;
>> +
>> +struct tpm_cmd_t {
>> +        tpm_cmd_header  header;
>> +        tpm_cmd_params  params;
>> +}__attribute__((packed));
>> +
>> +
>> +enum tpm_duration {
>> +   TPM_SHORT =3D 0,
>> +   TPM_MEDIUM =3D 1,
>> +   TPM_LONG =3D 2,
>> +   TPM_UNDEFINED,
>> +};
>> +
>> +#define TPM_MAX_ORDINAL 243
>> +#define TPM_MAX_PROTECTED_ORDINAL 12
>> +#define TPM_PROTECTED_ORDINAL_MASK 0xFF
>> +
>> +extern const uint8_t
>> tpm_protected_ordinal_duration[TPM_MAX_PROTECTED_ORDINAL];
>> +extern const uint8_t tpm_ordinal_duration[TPM_MAX_ORDINAL];
>> +
>> +#define TPM_DIGEST_SIZE 20
>> +#define TPM_ERROR_SIZE 10
>> +#define TPM_RET_CODE_IDX 6
>> +
>> +/* tpm_capabilities */
>> +#define TPM_CAP_FLAG cpu_to_be32(4)
>> +#define TPM_CAP_PROP cpu_to_be32(5)
>> +#define CAP_VERSION_1_1 cpu_to_be32(0x06)
>> +#define CAP_VERSION_1_2 cpu_to_be32(0x1A)
>> +
>> +/* tpm_sub_capabilities */
>> +#define TPM_CAP_PROP_PCR cpu_to_be32(0x101)
>> +#define TPM_CAP_PROP_MANUFACTURER cpu_to_be32(0x103)
>> +#define TPM_CAP_FLAG_PERM cpu_to_be32(0x108)
>> +#define TPM_CAP_FLAG_VOL cpu_to_be32(0x109)
>> +#define TPM_CAP_PROP_OWNER cpu_to_be32(0x111)
>> +#define TPM_CAP_PROP_TIS_TIMEOUT cpu_to_be32(0x115)
>> +#define TPM_CAP_PROP_TIS_DURATION cpu_to_be32(0x120)
>> +
>> +
>> +#define TPM_INTERNAL_RESULT_SIZE 200
>> +#define TPM_TAG_RQU_COMMAND cpu_to_be16(193)
>> +#define TPM_ORD_GET_CAP cpu_to_be32(101)
>> +
>> +extern const struct tpm_input_header tpm_getcap_header;
>> +
>> +
>> +
>> +const uint8_t tpm_protected_ordinal_duration[TPM_MAX_PROTECTED_ORDINA=
L] =3D {
>> +   TPM_UNDEFINED,          /* 0 */
>> +   TPM_UNDEFINED,
>> +   TPM_UNDEFINED,
>> +   TPM_UNDEFINED,
>> +   TPM_UNDEFINED,
>> +   TPM_UNDEFINED,          /* 5 */
>> +   TPM_UNDEFINED,
>> +   TPM_UNDEFINED,
>> +   TPM_UNDEFINED,
>> +   TPM_UNDEFINED,
>> +   TPM_SHORT,              /* 10 */
>> +   TPM_SHORT,
>> +};
>> +
>> +const uint8_t tpm_ordinal_duration[TPM_MAX_ORDINAL] =3D {
>> +   TPM_UNDEFINED,          /* 0 */
>> +   TPM_UNDEFINED,
>> +   TPM_UNDEFINED,
>> +   TPM_UNDEFINED,
>> +   TPM_UNDEFINED,
>> +   TPM_UNDEFINED,          /* 5 */
>> +   TPM_UNDEFINED,
>> +   TPM_UNDEFINED,
>> +   TPM_UNDEFINED,
>> +   TPM_UNDEFINED,
>> +   TPM_SHORT,              /* 10 */
>> +   TPM_SHORT,
>> +   TPM_MEDIUM,
>> +   TPM_LONG,
>> +   TPM_LONG,
>> +   TPM_MEDIUM,             /* 15 */
>> +   TPM_SHORT,
>> +   TPM_SHORT,
>> +   TPM_MEDIUM,
>> +   TPM_LONG,
>> +   TPM_SHORT,              /* 20 */
>> +   TPM_SHORT,
>> +   TPM_MEDIUM,
>> +   TPM_MEDIUM,
>> +   TPM_MEDIUM,
>> +   TPM_SHORT,              /* 25 */
>> +   TPM_SHORT,
>> +   TPM_MEDIUM,
>> +   TPM_SHORT,
>> +   TPM_SHORT,
>> +   TPM_MEDIUM,             /* 30 */
>> +   TPM_LONG,
>> +   TPM_MEDIUM,
>> +   TPM_SHORT,
>> +   TPM_SHORT,
>> +   TPM_SHORT,              /* 35 */
>> +   TPM_MEDIUM,
>> +   TPM_MEDIUM,
>> +   TPM_UNDEFINED,
>> +   TPM_UNDEFINED,
>> +   TPM_MEDIUM,             /* 40 */
>> +   TPM_LONG,
>> +   TPM_MEDIUM,
>> +   TPM_SHORT,
>> +   TPM_SHORT,
>> +   TPM_SHORT,              /* 45 */
>> +   TPM_SHORT,
>> +   TPM_SHORT,
>> +   TPM_SHORT,
>> +   TPM_LONG,
>> +   TPM_MEDIUM,             /* 50 */
>> +   TPM_MEDIUM,
>> +   TPM_UNDEFINED,
>> +   TPM_UNDEFINED,
>> +   TPM_UNDEFINED,
>> +   TPM_UNDEFINED,          /* 55 */
>> +   TPM_UNDEFINED,
>> +   TPM_UNDEFINED,
>> +   TPM_UNDEFINED,
>> +   TPM_UNDEFINED,
>> +   TPM_MEDIUM,             /* 60 */
>> +   TPM_MEDIUM,
>> +   TPM_MEDIUM,
>> +   TPM_SHORT,
>> +   TPM_SHORT,
>> +   TPM_MEDIUM,             /* 65 */
>> +   TPM_UNDEFINED,
>> +   TPM_UNDEFINED,
>> +   TPM_UNDEFINED,
>> +   TPM_UNDEFINED,
>> +   TPM_SHORT,              /* 70 */
>> +   TPM_SHORT,
>> +   TPM_UNDEFINED,
>> +   TPM_UNDEFINED,
>> +   TPM_UNDEFINED,
>> +   TPM_UNDEFINED,          /* 75 */
>> +   TPM_UNDEFINED,
>> +   TPM_UNDEFINED,
>> +   TPM_UNDEFINED,
>> +   TPM_UNDEFINED,
>> +   TPM_LONG,               /* 80 */
>> +   TPM_UNDEFINED,
>> +   TPM_MEDIUM,
>> +   TPM_LONG,
>> +   TPM_SHORT,
>> +   TPM_UNDEFINED,          /* 85 */
>> +   TPM_UNDEFINED,
>> +   TPM_UNDEFINED,
>> +   TPM_UNDEFINED,
>> +   TPM_UNDEFINED,
>> +   TPM_SHORT,              /* 90 */
>> +   TPM_SHORT,
>> +   TPM_SHORT,
>> +   TPM_SHORT,
>> +   TPM_SHORT,
>> +   TPM_UNDEFINED,          /* 95 */
>> +   TPM_UNDEFINED,
>> +   TPM_UNDEFINED,
>> +   TPM_UNDEFINED,
>> +   TPM_UNDEFINED,
>> +   TPM_MEDIUM,             /* 100 */
>> +   TPM_SHORT,
>> +   TPM_SHORT,
>> +   TPM_UNDEFINED,
>> +   TPM_UNDEFINED,
>> +   TPM_UNDEFINED,          /* 105 */
>> +   TPM_UNDEFINED,
>> +   TPM_UNDEFINED,
>> +   TPM_UNDEFINED,
>> +   TPM_UNDEFINED,
>> +   TPM_SHORT,              /* 110 */
>> +   TPM_SHORT,
>> +   TPM_SHORT,
>> +   TPM_SHORT,
>> +   TPM_SHORT,
>> +   TPM_SHORT,              /* 115 */
>> +   TPM_SHORT,
>> +   TPM_SHORT,
>> +   TPM_UNDEFINED,
>> +   TPM_UNDEFINED,
>> +   TPM_LONG,               /* 120 */
>> +   TPM_LONG,
>> +   TPM_MEDIUM,
>> +   TPM_UNDEFINED,
>> +   TPM_SHORT,
>> +   TPM_SHORT,              /* 125 */
>> +   TPM_SHORT,
>> +   TPM_LONG,
>> +   TPM_SHORT,
>> +   TPM_SHORT,
>> +   TPM_SHORT,              /* 130 */
>> +   TPM_MEDIUM,
>> +   TPM_UNDEFINED,
>> +   TPM_SHORT,
>> +   TPM_MEDIUM,
>> +   TPM_UNDEFINED,          /* 135 */
>> +   TPM_UNDEFINED,
>> +   TPM_UNDEFINED,
>> +   TPM_UNDEFINED,
>> +   TPM_UNDEFINED,
>> +   TPM_SHORT,              /* 140 */
>> +   TPM_SHORT,
>> +   TPM_UNDEFINED,
>> +   TPM_UNDEFINED,
>> +   TPM_UNDEFINED,
>> +   TPM_UNDEFINED,          /* 145 */
>> +   TPM_UNDEFINED,
>> +   TPM_UNDEFINED,
>> +   TPM_UNDEFINED,
>> +   TPM_UNDEFINED,
>> +   TPM_SHORT,              /* 150 */
>> +   TPM_MEDIUM,
>> +   TPM_MEDIUM,
>> +   TPM_SHORT,
>> +   TPM_SHORT,
>> +   TPM_UNDEFINED,          /* 155 */
>> +   TPM_UNDEFINED,
>> +   TPM_UNDEFINED,
>> +   TPM_UNDEFINED,
>> +   TPM_UNDEFINED,
>> +   TPM_SHORT,              /* 160 */
>> +   TPM_SHORT,
>> +   TPM_SHORT,
>> +   TPM_SHORT,
>> +   TPM_UNDEFINED,
>> +   TPM_UNDEFINED,          /* 165 */
>> +   TPM_UNDEFINED,
>> +   TPM_UNDEFINED,
>> +   TPM_UNDEFINED,
>> +   TPM_UNDEFINED,
>> +   TPM_LONG,               /* 170 */
>> +   TPM_UNDEFINED,
>> +   TPM_UNDEFINED,
>> +   TPM_UNDEFINED,
>> +   TPM_UNDEFINED,
>> +   TPM_UNDEFINED,          /* 175 */
>> +   TPM_UNDEFINED,
>> +   TPM_UNDEFINED,
>> +   TPM_UNDEFINED,
>> +   TPM_UNDEFINED,
>> +   TPM_MEDIUM,             /* 180 */
>> +   TPM_SHORT,
>> +   TPM_MEDIUM,
>> +   TPM_MEDIUM,
>> +   TPM_MEDIUM,
>> +   TPM_MEDIUM,             /* 185 */
>> +   TPM_SHORT,
>> +   TPM_UNDEFINED,
>> +   TPM_UNDEFINED,
>> +   TPM_UNDEFINED,
>> +   TPM_UNDEFINED,          /* 190 */
>> +   TPM_UNDEFINED,
>> +   TPM_UNDEFINED,
>> +   TPM_UNDEFINED,
>> +   TPM_UNDEFINED,
>> +   TPM_UNDEFINED,          /* 195 */
>> +   TPM_UNDEFINED,
>> +   TPM_UNDEFINED,
>> +   TPM_UNDEFINED,
>> +   TPM_UNDEFINED,
>> +   TPM_SHORT,              /* 200 */
>> +   TPM_UNDEFINED,
>> +   TPM_UNDEFINED,
>> +   TPM_UNDEFINED,
>> +   TPM_SHORT,
>> +   TPM_SHORT,              /* 205 */
>> +   TPM_SHORT,
>> +   TPM_SHORT,
>> +   TPM_SHORT,
>> +   TPM_SHORT,
>> +   TPM_MEDIUM,             /* 210 */
>> +   TPM_UNDEFINED,
>> +   TPM_MEDIUM,
>> +   TPM_MEDIUM,
>> +   TPM_MEDIUM,
>> +   TPM_UNDEFINED,          /* 215 */
>> +   TPM_MEDIUM,
>> +   TPM_UNDEFINED,
>> +   TPM_UNDEFINED,
>> +   TPM_SHORT,
>> +   TPM_SHORT,              /* 220 */
>> +   TPM_SHORT,
>> +   TPM_SHORT,
>> +   TPM_SHORT,
>> +   TPM_SHORT,
>> +   TPM_UNDEFINED,          /* 225 */
>> +   TPM_UNDEFINED,
>> +   TPM_UNDEFINED,
>> +   TPM_UNDEFINED,
>> +   TPM_UNDEFINED,
>> +   TPM_SHORT,              /* 230 */
>> +   TPM_LONG,
>> +   TPM_MEDIUM,
>> +   TPM_UNDEFINED,
>> +   TPM_UNDEFINED,
>> +   TPM_UNDEFINED,          /* 235 */
>> +   TPM_UNDEFINED,
>> +   TPM_UNDEFINED,
>> +   TPM_UNDEFINED,
>> +   TPM_UNDEFINED,
>> +   TPM_SHORT,              /* 240 */
>> +   TPM_UNDEFINED,
>> +   TPM_MEDIUM,
>> +};
>> +
>> +const struct tpm_input_header tpm_getcap_header =3D {
>> +        .tag =3D TPM_TAG_RQU_COMMAND,
>> +        .length =3D cpu_to_be32(22),
>> +        .ordinal =3D TPM_ORD_GET_CAP
>> +};
>> +
>> +
>> +enum tis_access {
>> +   TPM_ACCESS_VALID =3D 0x80,
>> +   TPM_ACCESS_ACTIVE_LOCALITY =3D 0x20,    /* (R) */
>> +   TPM_ACCESS_RELINQUISH_LOCALITY =3D 0x20,/* (W) */
>> +   TPM_ACCESS_REQUEST_PENDING =3D 0x04,    /* (W) */
>> +   TPM_ACCESS_REQUEST_USE =3D 0x02,    /* (W) */
>> +};
>> +
>> +enum tis_status {
>> +   TPM_STS_VALID =3D 0x80,        /* (R) */
>> +   TPM_STS_COMMAND_READY =3D 0x40,    /* (R) */
>> +   TPM_STS_DATA_AVAIL =3D 0x10,        /* (R) */
>> +   TPM_STS_DATA_EXPECT =3D 0x08,        /* (R) */
>> +   TPM_STS_GO =3D 0x20,            /* (W) */
>> +};
>> +
>> +enum tis_int_flags {
>> +   TPM_GLOBAL_INT_ENABLE =3D 0x80000000,
>> +   TPM_INTF_BURST_COUNT_STATIC =3D 0x100,
>> +   TPM_INTF_CMD_READY_INT =3D 0x080,
>> +   TPM_INTF_INT_EDGE_FALLING =3D 0x040,
>> +   TPM_INTF_INT_EDGE_RISING =3D 0x020,
>> +   TPM_INTF_INT_LEVEL_LOW =3D 0x010,
>> +   TPM_INTF_INT_LEVEL_HIGH =3D 0x008,
>> +   TPM_INTF_LOCALITY_CHANGE_INT =3D 0x004,
>> +   TPM_INTF_STS_VALID_INT =3D 0x002,
>> +   TPM_INTF_DATA_AVAIL_INT =3D 0x001,
>> +};
>> +
>> +enum tis_defaults {
>> +   TIS_MEM_BASE =3D 0xFED40000,
>> +   TIS_MEM_LEN  =3D 0x5000,
>> +   TIS_SHORT_TIMEOUT =3D 750, /*ms*/
>> +   TIS_LONG_TIMEOUT =3D 2000, /*2 sec */
>> +};
>> +
>> +#define TPM_TIMEOUT 5
>> +
>> +#define TPM_ACCESS(t, l)                   (((uint8_t*)t->pages[l]) +=

>> 0x0000)
>> +#define TPM_INT_ENABLE(t, l)
>> ((uint32_t*)(((uint8_t*)t->pages[l]) + 0x0008))
>> +#define TPM_INT_VECTOR(t, l)               (((uint8_t*)t->pages[l]) +=

>> 0x000C)
>> +#define TPM_INT_STATUS(t, l)               (((uint8_t*)t->pages[l]) +=

>> 0x0010)
>> +#define TPM_INTF_CAPS(t, l)
>> ((uint32_t*)(((uint8_t*)t->pages[l]) + 0x0014))
>> +#define TPM_STS(t, l)
>> ((uint8_t*)(((uint8_t*)t->pages[l]) + 0x0018))
>> +#define TPM_DATA_FIFO(t, l)                (((uint8_t*)t->pages[l]) +=

>> 0x0024)
>> +
>> +#define TPM_DID_VID(t, l)
>> ((uint32_t*)(((uint8_t*)t->pages[l]) + 0x0F00))
>> +#define TPM_RID(t, l)                      (((uint8_t*)t->pages[l]) +=

>> 0x0F04)
>> +
>> +struct tpm_chip {
>> +   int enabled_localities;
>> +   int locality;
>> +   unsigned long baseaddr;
>> +   uint8_t* pages[5];
>> +   int did, vid, rid;
>> +
>> +   uint8_t data_buffer[TPM_BUFSIZE];
>> +   int data_len;
>> +
>> +   s_time_t timeout_a, timeout_b, timeout_c, timeout_d;
>> +   s_time_t duration[3];
>> +
>> +#ifdef HAVE_LIBC
>> +   int fd;
>> +#endif
>> +
>> +   unsigned int irq;
>> +   struct wait_queue_head read_queue;
>> +   struct wait_queue_head int_queue;
>> +};
>> +
>> +
>> +static void __init_tpm_chip(struct tpm_chip* tpm) {
>> +   tpm->enabled_localities =3D TPM_TIS_EN_LOCLALL;
>> +   tpm->locality =3D -1;
>> +   tpm->baseaddr =3D 0;
>> +   tpm->pages[0] =3D tpm->pages[1] =3D tpm->pages[2] =3D tpm->pages[3=
] =3D
>> tpm->pages[4] =3D NULL;
>> +   tpm->vid =3D 0;
>> +   tpm->did =3D 0;
>> +   tpm->irq =3D 0;
>> +   init_waitqueue_head(&tpm->read_queue);
>> +   init_waitqueue_head(&tpm->int_queue);
>> +
>> +   tpm->data_len =3D -1;
>> +
>> +#ifdef HAVE_LIBC
>> +   tpm->fd =3D -1;
>> +#endif
>> +}
>> +
>> +/*
>> + * Returns max number of nsecs to wait
>> + */
>> +s_time_t tpm_calc_ordinal_duration(struct tpm_chip *chip,
>> +      uint32_t ordinal)
>> +{
>> +   int duration_idx =3D TPM_UNDEFINED;
>> +   s_time_t duration =3D 0;
>> +
>> +   if (ordinal < TPM_MAX_ORDINAL)
>> +      duration_idx =3D tpm_ordinal_duration[ordinal];
>> +   else if ((ordinal & TPM_PROTECTED_ORDINAL_MASK) <
>> +     TPM_MAX_PROTECTED_ORDINAL)
>> +      duration_idx =3D
>> +     tpm_protected_ordinal_duration[ordinal &
>> +     TPM_PROTECTED_ORDINAL_MASK];
>> +
>> +   if (duration_idx !=3D TPM_UNDEFINED) {
>> +      duration =3D chip->duration[duration_idx];
>> +   }
>> +
>> +   if (duration <=3D 0) {
>> +      return SECONDS(120);
>> +   }
>> +   else
>> +   {
>> +      return duration;
>> +   }
>> +}
>> +
>> +
>> +static int locality_enabled(struct tpm_chip* tpm, int l) {
>> +   return tpm->enabled_localities & (1 << l);
>> +}
>> +
>> +static int check_locality(struct tpm_chip* tpm, int l) {
>> +   if(locality_enabled(tpm, l) && (ioread8(TPM_ACCESS(tpm, l)) &
>> +        (TPM_ACCESS_ACTIVE_LOCALITY | TPM_ACCESS_VALID)) =3D=3D
>> +     (TPM_ACCESS_ACTIVE_LOCALITY | TPM_ACCESS_VALID)) {
>> +      return l;
>> +   }
>> +   return -1;
>> +}
>> +
>> +void release_locality(struct tpm_chip* tpm, int l, int force)
>> +{
>> +   if (locality_enabled(tpm, l) && (force || (ioread8(TPM_ACCESS(tpm,=
 l)) &
>> +           (TPM_ACCESS_REQUEST_PENDING | TPM_ACCESS_VALID)) =3D=3D
>> +        (TPM_ACCESS_REQUEST_PENDING | TPM_ACCESS_VALID))) {
>> +      iowrite8(TPM_ACCESS(tpm, l), TPM_ACCESS_RELINQUISH_LOCALITY);
>> +   }
>> +}
>> +
>> +int tpm_tis_request_locality(struct tpm_chip* tpm, int l) {
>> +
>> +   s_time_t stop;
>> +   /*Make sure locality is valid */
>> +   if(!locality_enabled(tpm, l)) {
>> +      printk("tpm_tis_change_locality() Tried to change to locality %=
d,
>> but it is disabled or invalid!\n", l);
>> +      return -1;
>> +   }
>> +   /* Check if we already have the current locality */
>> +   if(check_locality(tpm, l) >=3D 0) {
>> +      return tpm->locality =3D l;
>> +   }
>> +   /* Set the new locality*/
>> +   iowrite8(TPM_ACCESS(tpm, l), TPM_ACCESS_REQUEST_USE);
>> +
>> +   if(tpm->irq) {
>> +      /* Wait for interrupt */
>> +      wait_event_deadline(tpm->int_queue, (check_locality(tpm, l) >=3D=

>> 0), NOW() + tpm->timeout_a);
>> +
>> +      /* FIXME: Handle timeout event, should return error in that cas=
e */
>> +      return l;
>> +   } else {
>> +      /* Wait for burstcount */
>> +      stop =3D NOW() + tpm->timeout_a;
>> +      do {
>> +     if(check_locality(tpm, l) >=3D 0) {
>> +        return tpm->locality =3D l;
>> +     }
>> +     msleep(TPM_TIMEOUT);
>> +      } while(NOW() < stop);
>> +   }
>> +
>> +   printk("REQ LOCALITY FAILURE\n");
>> +   return -1;
>> +}
>> +
>> +static uint8_t tpm_tis_status(struct tpm_chip* tpm) {
>> +   return ioread8(TPM_STS(tpm, tpm->locality));
>> +}
>> +
>> +/* This causes the current command to be aborted */
>> +static void tpm_tis_ready(struct tpm_chip* tpm) {
>> +   iowrite8(TPM_STS(tpm, tpm->locality), TPM_STS_COMMAND_READY);
>> +}
>> +#define tpm_tis_cancel_cmd(v) tpm_tis_ready(v)
>> +
>> +static int get_burstcount(struct tpm_chip* tpm) {
>> +   s_time_t stop;
>> +   int burstcnt;
>> +
>> +   stop =3D NOW() + tpm->timeout_d;
>> +   do {
>> +      burstcnt =3D ioread8((TPM_STS(tpm, tpm->locality) + 1));
>> +      burstcnt +=3D ioread8(TPM_STS(tpm, tpm->locality) + 2) << 8;
>> +
>> +      if (burstcnt) {
>> +     return burstcnt;
>> +      }
>> +      msleep(TPM_TIMEOUT);
>> +   } while(NOW() < stop);
>> +   return -EBUSY;
>> +}
>> +
>> +static int wait_for_stat(struct tpm_chip* tpm, uint8_t mask,
>> +      unsigned long timeout, struct wait_queue_head* queue) {
>> +   s_time_t stop;
>> +   uint8_t status;
>> +
>> +   status =3D tpm_tis_status(tpm);
>> +   if((status & mask) =3D=3D mask) {
>> +      return 0;
>> +   }
>> +
>> +   if(tpm->irq) {
>> +      wait_event_deadline(*queue, ((tpm_tis_status(tpm) & mask) =3D=3D=

>> mask), timeout);
>> +      /* FIXME: Check for timeout and return -ETIME */
>> +      return 0;
>> +   } else {
>> +      stop =3D NOW() + timeout;
>> +      do {
>> +     msleep(TPM_TIMEOUT);
>> +     status =3D tpm_tis_status(tpm);
>> +     if((status & mask) =3D=3D mask)
>> +        return 0;
>> +      } while( NOW() < stop);
>> +   }
>> +   return -ETIME;
>> +}
>> +
>> +static int recv_data(struct tpm_chip* tpm, uint8_t* buf, size_t count=
) {
>> +   int size =3D 0;
>> +   int burstcnt;
>> +   while( size < count &&
>> +     wait_for_stat(tpm,
>> +        TPM_STS_DATA_AVAIL | TPM_STS_VALID,
>> +        tpm->timeout_c,
>> +        &tpm->read_queue)
>> +     =3D=3D 0) {
>> +      burstcnt =3D get_burstcount(tpm);
>> +      for(; burstcnt > 0 && size < count; --burstcnt)
>> +      {
>> +     buf[size++] =3D ioread8(TPM_DATA_FIFO(tpm, tpm->locality));
>> +      }
>> +   }
>> +   return size;
>> +}
>> +
>> +int tpm_tis_recv(struct tpm_chip* tpm, uint8_t* buf, size_t count) {
>> +   int size =3D 0;
>> +   int expected, status;
>> +
>> +   if (count < TPM_HEADER_SIZE) {
>> +      size =3D -EIO;
>> +      goto out;
>> +   }
>> +
>> +   /* read first 10 bytes, including tag, paramsize, and result */
>> +   if((size =3D
>> +        recv_data(tpm, buf, TPM_HEADER_SIZE)) < TPM_HEADER_SIZE) {
>> +      printk("Error reading tpm cmd header\n");
>> +      goto out;
>> +   }
>> +
>> +   expected =3D be32_to_cpu(*((uint32_t*)(buf + 2)));
>> +   if(expected > count) {
>> +      size =3D -EIO;
>> +      goto out;
>> +   }
>> +
>> +   if((size +=3D recv_data(tpm, & buf[TPM_HEADER_SIZE],
>> +           expected - TPM_HEADER_SIZE)) < expected) {
>> +      printk("Unable to read rest of tpm command size=3D%d
>> expected=3D%d\n", size, expected);
>> +      size =3D -ETIME;
>> +      goto out;
>> +   }
>> +
>> +   wait_for_stat(tpm, TPM_STS_VALID, tpm->timeout_c, &tpm->int_queue)=
;
>> +   status =3D tpm_tis_status(tpm);
>> +   if(status & TPM_STS_DATA_AVAIL) {
>> +      printk("Error: left over data\n");
>> +      size =3D -EIO;
>> +      goto out;
>> +   }
>> +
>> +out:
>> +   tpm_tis_ready(tpm);
>> +   release_locality(tpm, tpm->locality, 0);
>> +   return size;
>> +}
>> +int tpm_tis_send(struct tpm_chip* tpm, uint8_t* buf, size_t len) {
>> +   int rc;
>> +   int status, burstcnt =3D 0;
>> +   int count =3D 0;
>> +   uint32_t ordinal;
>> +
>> +   if(tpm_tis_request_locality(tpm, tpm->locality) < 0) {
>> +      return -EBUSY;
>> +   }
>> +
>> +   status =3D tpm_tis_status(tpm);
>> +   if((status & TPM_STS_COMMAND_READY) =3D=3D 0) {
>> +      tpm_tis_ready(tpm);
>> +      if(wait_for_stat(tpm, TPM_STS_COMMAND_READY, tpm->timeout_b,
>> &tpm->int_queue) < 0) {
>> +     rc =3D -ETIME;
>> +     goto out_err;
>> +      }
>> +   }
>> +
>> +   while(count < len - 1) {
>> +      burstcnt =3D get_burstcount(tpm);
>> +      for(;burstcnt > 0 && count < len -1; --burstcnt) {
>> +     iowrite8(TPM_DATA_FIFO(tpm, tpm->locality), buf[count++]);
>> +      }
>> +
>> +      wait_for_stat(tpm, TPM_STS_VALID, tpm->timeout_c, &tpm->int_que=
ue);
>> +      status =3D tpm_tis_status(tpm);
>> +      if((status & TPM_STS_DATA_EXPECT) =3D=3D 0) {
>> +     rc =3D -EIO;
>> +     goto out_err;
>> +      }
>> +   }
>> +
>> +   /*Write last byte*/
>> +   iowrite8(TPM_DATA_FIFO(tpm, tpm->locality), buf[count]);
>> +   wait_for_stat(tpm, TPM_STS_VALID, tpm->timeout_c, &tpm->read_queue=
);
>> +   status =3D tpm_tis_status(tpm);
>> +   if((status & TPM_STS_DATA_EXPECT) !=3D 0) {
>> +      rc =3D -EIO;
>> +      goto out_err;
>> +   }
>> +
>> +   /*go and do it*/
>> +   iowrite8(TPM_STS(tpm, tpm->locality), TPM_STS_GO);
>> +
>> +   if(tpm->irq) {
>> +      /*Wait for interrupt */
>> +      ordinal =3D be32_to_cpu(*(buf + 6));
>> +      if(wait_for_stat(tpm,
>> +           TPM_STS_DATA_AVAIL | TPM_STS_VALID,
>> +           tpm_calc_ordinal_duration(tpm, ordinal),
>> +           &tpm->read_queue) < 0) {
>> +     rc =3D -ETIME;
>> +     goto out_err;
>> +      }
>> +   }
>> +#ifdef HAVE_LIBC
>> +   if(tpm->fd >=3D 0) {
>> +      files[tpm->fd].read =3D 0;
>> +      files[tpm->fd].tpm_tis.respgot =3D 0;
>> +      files[tpm->fd].tpm_tis.offset =3D 0;
>> +   }
>> +#endif
>> +   return len;
>> +
>> +out_err:
>> +   tpm_tis_ready(tpm);
>> +   release_locality(tpm, tpm->locality, 0);
>> +   return rc;
>> +}
>> +
>> +static void tpm_tis_irq_handler(evtchn_port_t port, struct pt_regs
>> *regs, void* data)
>> +{
>> +   struct tpm_chip* tpm =3D data;
>> +   uint32_t interrupt;
>> +   int i;
>> +
>> +   interrupt =3D ioread32(TPM_INT_STATUS(tpm, tpm->locality));
>> +   if(interrupt =3D=3D 0) {
>> +      return;
>> +   }
>> +
>> +   if(interrupt & TPM_INTF_DATA_AVAIL_INT) {
>> +      wake_up(&tpm->read_queue);
>> +   }
>> +   if(interrupt & TPM_INTF_LOCALITY_CHANGE_INT) {
>> +      for(i =3D 0; i < 5; ++i) {
>> +     if(check_locality(tpm, i) >=3D 0) {
>> +        break;
>> +     }
>> +      }
>> +   }
>> +   if(interrupt & (TPM_INTF_LOCALITY_CHANGE_INT | TPM_INTF_STS_VALID_=
INT |
>> +        TPM_INTF_CMD_READY_INT)) {
>> +      wake_up(&tpm->int_queue);
>> +   }
>> +
>> +   /* Clear interrupts handled with TPM_EOI */
>> +   iowrite32(TPM_INT_STATUS(tpm, tpm->locality), interrupt);
>> +   ioread32(TPM_INT_STATUS(tpm, tpm->locality));
>> +   return;
>> +}
>> +
>> +/*
>> + * Internal kernel interface to transmit TPM commands
>> + */
>> +static ssize_t tpm_transmit(struct tpm_chip *chip, const uint8_t *buf=
,
>> +      size_t bufsiz)
>> +{
>> +   ssize_t rc;
>> +   uint32_t count, ordinal;
>> +   s_time_t stop;
>> +
>> +   count =3D be32_to_cpu(*((uint32_t *) (buf + 2)));
>> +   ordinal =3D be32_to_cpu(*((uint32_t *) (buf + 6)));
>> +   if (count =3D=3D 0)
>> +      return -ENODATA;
>> +   if (count > bufsiz) {
>> +      printk("Error: invalid count value %x %zx \n", count, bufsiz);
>> +      return -E2BIG;
>> +   }
>> +
>> +   //down(&chip->tpm_mutex);
>> +
>> +   if ((rc =3D tpm_tis_send(chip, (uint8_t *) buf, count)) < 0) {
>> +      printk("tpm_transmit: tpm_send: error %zd\n", rc);
>> +      goto out;
>> +   }
>> +
>> +   if (chip->irq)
>> +      goto out_recv;
>> +
>> +   stop =3D NOW() + tpm_calc_ordinal_duration(chip, ordinal);
>> +   do {
>> +      uint8_t status =3D tpm_tis_status(chip);
>> +      if ((status & (TPM_STS_DATA_AVAIL | TPM_STS_VALID)) =3D=3D
>> +        (TPM_STS_DATA_AVAIL | TPM_STS_VALID))
>> +     goto out_recv;
>> +
>> +      if ((status =3D=3D TPM_STS_COMMAND_READY)) {
>> +     printk("TPM Error: Operation Canceled\n");
>> +     rc =3D -ECANCELED;
>> +     goto out;
>> +      }
>> +
>> +      msleep(TPM_TIMEOUT);    /* CHECK */
>> +      rmb();
>> +   } while (NOW() < stop);
>> +
>> +   /* Cancel the command */
>> +   tpm_tis_cancel_cmd(chip);
>> +   printk("TPM Operation Timed out\n");
>> +   rc =3D -ETIME;
>> +   goto out;
>> +
>> +out_recv:
>> +   if((rc =3D tpm_tis_recv(chip, (uint8_t *) buf, bufsiz)) < 0) {
>> +      printk("tpm_transmit: tpm_recv: error %d\n", rc);
>> +   }
>> +out:
>> +   //up(&chip->tpm_mutex);
>> +   return rc;
>> +}
>> +
>> +static ssize_t transmit_cmd(struct tpm_chip *chip, struct tpm_cmd_t *=
cmd,
>> +                            int len, const char *desc)
>> +{
>> +        int err;
>> +
>> +        len =3D tpm_transmit(chip,(uint8_t *) cmd, len);
>> +        if (len <  0)
>> +                return len;
>> +        if (len =3D=3D TPM_ERROR_SIZE) {
>> +                err =3D be32_to_cpu(cmd->header.out.return_code);
>> +                printk("A TPM error (%d) occurred %s\n", err, desc);
>> +                return err;
>> +        }
>> +        return 0;
>> +}
>> +
>> +void tpm_get_timeouts(struct tpm_chip *chip)
>> +{
>> +   struct tpm_cmd_t tpm_cmd;
>> +   struct timeout_t *timeout_cap;
>> +   struct duration_t *duration_cap;
>> +   ssize_t rc;
>> +   uint32_t timeout;
>> +
>> +   tpm_cmd.header.in =3D tpm_getcap_header;
>> +   tpm_cmd.params.getcap_in.cap =3D TPM_CAP_PROP;
>> +   tpm_cmd.params.getcap_in.subcap_size =3D cpu_to_be32(4);
>> +   tpm_cmd.params.getcap_in.subcap =3D TPM_CAP_PROP_TIS_TIMEOUT;
>> +
>> +   if((rc =3D transmit_cmd(chip, &tpm_cmd, TPM_INTERNAL_RESULT_SIZE,
>> +     "attempting to determine the timeouts")) !=3D 0) {
>> +      printk("transmit failed %d\n", rc);
>> +      goto duration;
>> +   }
>> +
>> +   if (be32_to_cpu(tpm_cmd.params.getcap_out.cap_size)
>> +     !=3D 4 * sizeof(uint32_t)) {
>> +      printk("Out len check failure %lu \n",
>> be32_to_cpu(tpm_cmd.header.out.length));
>> +      goto duration;
>> +   }
>> +
>> +   timeout_cap =3D &tpm_cmd.params.getcap_out.cap.timeout;
>> +   /* Don't overwrite default if value is 0 */
>> +   timeout =3D be32_to_cpu(timeout_cap->a);
>> +   if (timeout)
>> +      chip->timeout_a =3D MICROSECS(timeout); /*Convert to msec */
>> +   timeout =3D be32_to_cpu(timeout_cap->b);
>> +   if (timeout)
>> +      chip->timeout_b =3D MICROSECS(timeout); /*Convert to msec */
>> +   timeout =3D be32_to_cpu(timeout_cap->c);
>> +   if (timeout)
>> +      chip->timeout_c =3D MICROSECS(timeout); /*Convert to msec */
>> +   timeout =3D be32_to_cpu(timeout_cap->d);
>> +   if (timeout)
>> +      chip->timeout_d =3D MICROSECS(timeout); /*Convert to msec */
>> +
>> +duration:
>> +   tpm_cmd.header.in =3D tpm_getcap_header;
>> +   tpm_cmd.params.getcap_in.cap =3D TPM_CAP_PROP;
>> +   tpm_cmd.params.getcap_in.subcap_size =3D cpu_to_be32(4);
>> +   tpm_cmd.params.getcap_in.subcap =3D TPM_CAP_PROP_TIS_DURATION;
>> +
>> +   if((rc =3D transmit_cmd(chip, &tpm_cmd, TPM_INTERNAL_RESULT_SIZE,
>> +     "attempting to determine the durations")) < 0) {
>> +      return;
>> +   }
>> +
>> +   if (be32_to_cpu(tpm_cmd.params.getcap_out.cap_size)
>> +     !=3D 3 * sizeof(uint32_t)) {
>> +      return;
>> +   }
>> +        duration_cap =3D &tpm_cmd.params.getcap_out.cap.duration;
>> +        chip->duration[TPM_SHORT] =3D be32_to_cpu(duration_cap->tpm_s=
hort);
>> +        /* The Broadcom BCM0102 chipset in a Dell Latitude D820 gets
>> the above
>> +         * value wrong and apparently reports msecs rather than usecs=
=2E
>> So we
>> +         * fix up the resulting too-small TPM_SHORT value to make
>> things work.
>> +         */
>> +        if (chip->duration[TPM_SHORT] < 10) {
>> +       chip->duration[TPM_SHORT] =3D MILLISECS(chip->duration[TPM_SHO=
RT]);
>> +    } else {
>> +       chip->duration[TPM_SHORT] =3D MICROSECS(chip->duration[TPM_SHO=
RT]);
>> +    }
>> +
>> +        chip->duration[TPM_MEDIUM] =3D
>> MICROSECS(be32_to_cpu(duration_cap->tpm_medium));
>> +        chip->duration[TPM_LONG] =3D
>> MICROSECS(be32_to_cpu(duration_cap->tpm_long));
>> +}
>> +
>> +
>> +
>> +void tpm_continue_selftest(struct tpm_chip* chip) {
>> +   uint8_t data[] =3D {
>> +      0, 193,                 /* TPM_TAG_RQU_COMMAND */
>> +      0, 0, 0, 10,            /* length */
>> +      0, 0, 0, 83,            /* TPM_ORD_GetCapability */
>> +   };
>> +
>> +   tpm_transmit(chip, data, sizeof(data));
>> +}
>> +
>> +ssize_t tpm_getcap(struct tpm_chip *chip, uint32_t subcap_id, cap_t *=
cap,
>> +                   const char *desc)
>> +{
>> +        struct tpm_cmd_t tpm_cmd;
>> +        int rc;
>> +
>> +        tpm_cmd.header.in =3D tpm_getcap_header;
>> +        if (subcap_id =3D=3D CAP_VERSION_1_1 || subcap_id =3D=3D CAP_=
VERSION_1_2) {
>> +                tpm_cmd.params.getcap_in.cap =3D subcap_id;
>> +                /*subcap field not necessary */
>> +                tpm_cmd.params.getcap_in.subcap_size =3D cpu_to_be32(=
0);
>> +                tpm_cmd.header.in.length -=3D cpu_to_be32(sizeof(uint=
32_t));
>> +        } else {
>> +                if (subcap_id =3D=3D TPM_CAP_FLAG_PERM ||
>> +                    subcap_id =3D=3D TPM_CAP_FLAG_VOL)
>> +                        tpm_cmd.params.getcap_in.cap =3D TPM_CAP_FLAG=
;
>> +                else
>> +                        tpm_cmd.params.getcap_in.cap =3D TPM_CAP_PROP=
;
>> +                tpm_cmd.params.getcap_in.subcap_size =3D cpu_to_be32(=
4);
>> +                tpm_cmd.params.getcap_in.subcap =3D subcap_id;
>> +        }
>> +        rc =3D transmit_cmd(chip, &tpm_cmd, TPM_INTERNAL_RESULT_SIZE,=
 desc);
>> +        if (!rc)
>> +                *cap =3D tpm_cmd.params.getcap_out.cap;
>> +        return rc;
>> +}
>> +
>> +
>> +struct tpm_chip* init_tpm_tis(unsigned long baseaddr, int localities,=

>> unsigned int irq)
>> +{
>> +   int i;
>> +   unsigned long addr;
>> +   struct tpm_chip* tpm =3D NULL;
>> +   uint32_t didvid;
>> +   uint32_t intfcaps;
>> +   uint32_t intmask;
>> +
>> +   printk("=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Init TPM TIS Drive=
r =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D\n");
>> +
>> +   /*Sanity check the localities input */
>> +   if(localities & ~TPM_TIS_EN_LOCLALL) {
>> +      printk("init_tpm_tis() Invalid locality specification! %X\n",
>> localities);
>> +      goto abort_egress;
>> +   }
>> +
>> +   printk("IOMEM Machine Base Address: %lX\n", baseaddr);
>> +
>> +   /* Create the tpm data structure */
>> +   tpm =3D malloc(sizeof(struct tpm_chip));
>> +   __init_tpm_chip(tpm);
>> +
>> +   /* Set the enabled localities - if 0 we leave default as all enabl=
ed */
>> +   if(localities !=3D 0) {
>> +      tpm->enabled_localities =3D localities;
>> +   }
>> +   printk("Enabled Localities: ");
>> +   for(i =3D 0; i < 5; ++i) {
>> +      if(locality_enabled(tpm, i)) {
>> +     printk("%d ", i);
>> +      }
>> +   }
>> +   printk("\n");
>> +
>> +   /* Set the base machine address */
>> +   tpm->baseaddr =3D baseaddr;
>> +
>> +   /* Set default timeouts */
>> +   tpm->timeout_a =3D MILLISECS(TIS_SHORT_TIMEOUT);
>> +   tpm->timeout_b =3D MILLISECS(TIS_LONG_TIMEOUT);
>> +   tpm->timeout_c =3D MILLISECS(TIS_SHORT_TIMEOUT);
>> +   tpm->timeout_d =3D MILLISECS(TIS_SHORT_TIMEOUT);
>> +
>> +   /*Map the mmio pages */
>> +   addr =3D tpm->baseaddr;
>> +   for(i =3D 0; i < 5; ++i) {
>> +      if(locality_enabled(tpm, i)) {
>> +     /* Map the page in now */
>> +     if((tpm->pages[i] =3D ioremap_nocache(addr, PAGE_SIZE)) =3D=3D N=
ULL) {
>> +        printk("Unable to map iomem page a address %p\n", addr);
>> +        goto abort_egress;
>> +     }
>> +
>> +     /* Set default locality to the first enabled one */
>> +     if (tpm->locality < 0) {
>> +        if(tpm_tis_request_locality(tpm, i) < 0) {
>> +           printk("Unable to request locality %d??\n", i);
>> +           goto abort_egress;
>> +        }
>> +     }
>> +      }
>> +      addr +=3D PAGE_SIZE;
>> +   }
>> +
>> +
>> +   /* Get the vendor and device ids */
>> +   didvid =3D ioread32(TPM_DID_VID(tpm, tpm->locality));
>> +   tpm->did =3D didvid >> 16;
>> +   tpm->vid =3D didvid & 0xFFFF;
>> +
>> +
>> +   /* Get the revision id */
>> +   tpm->rid =3D ioread8(TPM_RID(tpm, tpm->locality));
>> +
>> +   printk("1.2 TPM (device-id=3D0x%X vendor-id =3D %X rev-id =3D %X)\=
n",
>> tpm->did, tpm->vid, tpm->rid);
>> +
>> +   intfcaps =3D ioread32(TPM_INTF_CAPS(tpm, tpm->locality));
>> +   printk("TPM interface capabilities (0x%x):\n", intfcaps);
>> +   if (intfcaps & TPM_INTF_BURST_COUNT_STATIC)
>> +      printk("\tBurst Count Static\n");
>> +   if (intfcaps & TPM_INTF_CMD_READY_INT)
>> +      printk("\tCommand Ready Int Support\n");
>> +   if (intfcaps & TPM_INTF_INT_EDGE_FALLING)
>> +      printk("\tInterrupt Edge Falling\n");
>> +   if (intfcaps & TPM_INTF_INT_EDGE_RISING)
>> +      printk("\tInterrupt Edge Rising\n");
>> +   if (intfcaps & TPM_INTF_INT_LEVEL_LOW)
>> +      printk("\tInterrupt Level Low\n");
>> +   if (intfcaps & TPM_INTF_INT_LEVEL_HIGH)
>> +      printk("\tInterrupt Level High\n");
>> +   if (intfcaps & TPM_INTF_LOCALITY_CHANGE_INT)
>> +      printk("\tLocality Change Int Support\n");
>> +   if (intfcaps & TPM_INTF_STS_VALID_INT)
>> +      printk("\tSts Valid Int Support\n");
>> +   if (intfcaps & TPM_INTF_DATA_AVAIL_INT)
>> +      printk("\tData Avail Int Support\n");
>> +
>> +   /*Interupt setup */
>> +   intmask =3D ioread32(TPM_INT_ENABLE(tpm, tpm->locality));
>> +
>> +   intmask |=3D TPM_INTF_CMD_READY_INT
>> +      | TPM_INTF_LOCALITY_CHANGE_INT | TPM_INTF_DATA_AVAIL_INT
>> +      | TPM_INTF_STS_VALID_INT;
>> +
>> +   iowrite32(TPM_INT_ENABLE(tpm, tpm->locality), intmask);
>> +
>> +   /*If interupts are enabled, handle it */
>> +   if(irq) {
>> +      if(irq !=3D TPM_PROBE_IRQ) {
>> +     tpm->irq =3D irq;
>> +      } else {
>> +     /*FIXME add irq probing feature later */
>> +     printk("IRQ probing not implemented\n");
>> +      }
>> +   }
>> +
>> +   if(tpm->irq) {
>> +      iowrite8(TPM_INT_VECTOR(tpm, tpm->locality), tpm->irq);
>> +
>> +      if(bind_pirq(tpm->irq, 1, tpm_tis_irq_handler, tpm) !=3D 0) {
>> +     printk("Unabled to request irq: %u for use\n", tpm->irq);
>> +     printk("Will use polling mode\n");
>> +     tpm->irq =3D 0;
>> +      } else {
>> +     /* Clear all existing */
>> +     iowrite32(TPM_INT_STATUS(tpm, tpm->locality),
>> ioread32(TPM_INT_STATUS(tpm, tpm->locality)));
>> +
>> +     /* Turn on interrupts */
>> +     iowrite32(TPM_INT_ENABLE(tpm, tpm->locality), intmask |
>> TPM_GLOBAL_INT_ENABLE);
>> +      }
>> +   }
>> +
>> +   tpm_get_timeouts(tpm);
>> +   tpm_continue_selftest(tpm);
>> +
>> +
>> +   return tpm;
>> +abort_egress:
>> +   if(tpm !=3D NULL) {
>> +      shutdown_tpm_tis(tpm);
>> +   }
>> +   return NULL;
>> +}
>> +
>> +void shutdown_tpm_tis(struct tpm_chip* tpm){
>> +   int i;
>> +
>> +   printk("Shutting down tpm_tis device\n");
>> +
>> +   iowrite32(TPM_INT_ENABLE(tpm, tpm->locality), ~TPM_GLOBAL_INT_ENAB=
LE);
>> +
>> +   /*Unmap all of the mmio pages */
>> +   for(i =3D 0; i < 5; ++i) {
>> +      if(tpm->pages[i] !=3D NULL) {
>> +     iounmap(tpm->pages[i], PAGE_SIZE);
>> +     tpm->pages[i] =3D NULL;
>> +      }
>> +   }
>> +   free(tpm);
>> +   return;
>> +}
>> +
>> +
>> +int tpm_tis_cmd(struct tpm_chip* tpm, uint8_t* req, size_t reqlen,
>> uint8_t** resp, size_t* resplen)
>> +{
>> +   if(tpm->locality < 0) {
>> +      printk("tpm_tis_cmd() failed! locality not set!\n");
>> +      return -1;
>> +   }
>> +   if(reqlen > TPM_BUFSIZE) {
>> +      reqlen =3D TPM_BUFSIZE;
>> +   }
>> +   memcpy(tpm->data_buffer, req, reqlen);
>> +   *resplen =3D tpm_transmit(tpm, tpm->data_buffer, TPM_BUFSIZE);
>> +
>> +   *resp =3D malloc(*resplen);
>> +   memcpy(*resp, tpm->data_buffer, *resplen);
>> +   return 0;
>> +}
>> +
>> +#ifdef HAVE_LIBC
>> +int tpm_tis_open(struct tpm_chip* tpm)
>> +{
>> +   /* Silently prevent multiple opens */
>> +   if(tpm->fd !=3D -1) {
>> +      return tpm->fd;
>> +   }
>> +
>> +   tpm->fd =3D alloc_fd(FTYPE_TPM_TIS);
>> +   printk("tpm_tis_open() -> %d\n", tpm->fd);
>> +   files[tpm->fd].tpm_tis.dev =3D tpm;
>> +   files[tpm->fd].tpm_tis.offset =3D 0;
>> +   files[tpm->fd].tpm_tis.respgot =3D 0;
>> +   return tpm->fd;
>> +}
>> +
>> +int tpm_tis_posix_write(int fd, const uint8_t* buf, size_t count)
>> +{
>> +   struct tpm_chip* tpm;
>> +   tpm =3D files[fd].tpm_tis.dev;
>> +
>> +   if(tpm->locality < 0) {
>> +      printk("tpm_tis_posix_write() failed! locality not set!\n");
>> +      errno =3D EINPROGRESS;
>> +      return -1;
>> +   }
>> +   if(count =3D=3D 0) {
>> +      return 0;
>> +   }
>> +
>> +   /* Return an error if we are already processing a command */
>> +   if(count > TPM_BUFSIZE) {
>> +      count =3D TPM_BUFSIZE;
>> +   }
>> +   /* Send the command now */
>> +   memcpy(tpm->data_buffer, buf, count);
>> +   if((tpm->data_len =3D tpm_transmit(tpm, tpm->data_buffer,
>> TPM_BUFSIZE)) < 0) {
>> +      errno =3D EIO;
>> +      return -1;
>> +   }
>> +   return count;
>> +}
>> +
>> +int tpm_tis_posix_read(int fd, uint8_t* buf, size_t count)
>> +{
>> +   int rc;
>> +   struct tpm_chip* tpm;
>> +   tpm =3D files[fd].tpm_tis.dev;
>> +
>> +   if(count =3D=3D 0) {
>> +      return 0;
>> +   }
>> +
>> +   /* If there is no tpm resp to read, return EIO */
>> +   if(tpm->data_len < 0) {
>> +      errno =3D EIO;
>> +      return -1;
>> +   }
>> +
>> +
>> +   /* Handle EOF case */
>> +   if(files[fd].tpm_tis.offset >=3D tpm->data_len) {
>> +      rc =3D 0;
>> +   } else {
>> +      rc =3D min(tpm->data_len - files[fd].tpm_tis.offset, count);
>> +      memcpy(buf, tpm->data_buffer + files[fd].tpm_tis.offset, rc);
>> +   }
>> +   files[fd].tpm_tis.offset +=3D rc;
>> +   /* Reset the data pending flag */
>> +   return rc;
>> +}
>> +int tpm_tis_posix_fstat(int fd, struct stat* buf)
>> +{
>> +   struct tpm_chip* tpm;
>> +   tpm =3D files[fd].tpm_tis.dev;
>> +
>> +   buf->st_mode =3D O_RDWR;
>> +   buf->st_uid =3D 0;
>> +   buf->st_gid =3D 0;
>> +   buf->st_size =3D be32_to_cpu(*((uint32_t*)(tpm->data_buffer + 2)))=
;
>> +   buf->st_atime =3D buf->st_mtime =3D buf->st_ctime =3D time(NULL);
>> +   return 0;
>> +}
>> +
>> +
>> +#endif
>> diff --git a/extras/mini-os/tpmback.c b/extras/mini-os/tpmback.c
>> --- /dev/null
>> +++ b/extras/mini-os/tpmback.c
>> @@ -0,0 +1,1114 @@
>> +/*
>> + * Copyright (c) 2010-2012 United States Government, as represented b=
y
>> + * the Secretary of Defense.  All rights reserved.
>> + *
>> + * This driver is free software: you can redistribute it and/or modif=
y
>> + * it under the terms of the GNU General Public License as published =
by
>> + * the Free Software Foundation, either version 3 of the License, or
>> + * (at your option) any later version.
>> + *
>> + * This driver is distributed in the hope that it will be useful,
>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
>> + * GNU General Public License for more details.
>> + *
>> + * You should have received a copy of the GNU General Public License
>> + * along with this program.  If not, see <http://www.gnu.org/licenses=
/>.
>> + *
>> + * Based upon the files:
>> + *  drivers/xen/tpmbk.c
>> + * from the Linux kernel, which are Copyright (C) 2006 IBM Corporatio=
n
>> + */
>> +#include <mini-os/os.h>
>> +#include <mini-os/xenbus.h>
>> +#include <mini-os/events.h>
>> +#include <errno.h>
>> +#include <mini-os/gnttab.h>
>> +#include <xen/io/xenbus.h>
>> +#include <xen/io/tpmif.h>
>> +#include <xen/io/protocols.h>
>> +#include <mini-os/xmalloc.h>
>> +#include <time.h>
>> +#include <mini-os/tpmback.h>
>> +#include <mini-os/lib.h>
>> +#include <fcntl.h>
>> +#include <mini-os/mm.h>
>> +#include <mini-os/posix/sys/mman.h>
>> +#include <mini-os/semaphore.h>
>> +#include <mini-os/wait.h>
>> +
>> +
>> +#ifndef HAVE_LIBC
>> +#define strtoul simple_strtoul
>> +#endif
>> +
>> +//#define TPMBACK_PRINT_DEBUG
>> +#ifdef TPMBACK_PRINT_DEBUG
>> +#define TPMBACK_DEBUG(fmt,...) printk("Tpmback:Debug("__FILE__":%d) "=

>> fmt, __LINE__, ##__VA_ARGS__)
>> +#define TPMBACK_DEBUG_MORE(fmt,...) printk(fmt, ##__VA_ARGS__)
>> +#else
>> +#define TPMBACK_DEBUG(fmt,...)
>> +#endif
>> +#define TPMBACK_ERR(fmt,...) printk("Tpmback:Error " fmt, ##__VA_ARGS=
__)
>> +#define TPMBACK_LOG(fmt,...) printk("Tpmback:Info " fmt, ##__VA_ARGS_=
_)
>> +
>> +#define min(a,b) (((a) < (b)) ? (a) : (b))
>> +
>> +/* Default size of the tpmif array at initialization */
>> +#define DEF_ARRAY_SIZE 1
>> +
>> +/* tpmif and tpmdev flags */
>> +#define TPMIF_CLOSED 1
>> +#define TPMIF_REQ_READY 2
>> +
>> +struct tpmif {
>> +   domid_t domid;
>> +   unsigned int handle;
>> +
>> +   char* fe_path;
>> +   char* fe_state_path;
>> +
>> +   /* Locally bound event channel*/
>> +   evtchn_port_t evtchn;
>> +
>> +   /* Shared page */
>> +   tpmif_tx_interface_t* tx;
>> +
>> +   /* pointer to TPMIF_RX_RING_SIZE pages */
>> +   void** pages;
>> +
>> +   enum xenbus_state state;
>> +   enum { DISCONNECTED, DISCONNECTING, CONNECTED } status;
>> +
>> +   char* uuid;
>> +
>> +   /* state flags */
>> +   int flags;
>> +};
>> +typedef struct tpmif tpmif_t;
>> +
>> +struct tpmback_dev {
>> +
>> +   tpmif_t** tpmlist;
>> +   unsigned long num_tpms;
>> +   unsigned long num_alloc;
>> +
>> +   struct gntmap map;
>> +
>> +   /* True if at least one tpmif has a request to be handled */
>> +   int flags;
>> +
>> +   /* exclusive domains, see init_tpmback comment in tpmback.h */
>> +   char** exclusive_uuids;
>> +
>> +   xenbus_event_queue events;
>> +
>> +   /* Callbacks */
>> +   void (*open_callback)(domid_t, unsigned int);
>> +   void (*close_callback)(domid_t, unsigned int);
>> +   void (*suspend_callback)(domid_t, unsigned int);
>> +   void (*resume_callback)(domid_t, unsigned int);
>> +};
>> +typedef struct tpmback_dev tpmback_dev_t;
>> +
>> +enum { EV_NONE, EV_NEWFE, EV_STCHNG } tpm_ev_enum;
>> +
>> +/* Global objects */
>> +static struct thread* eventthread =3D NULL;
>> +static tpmback_dev_t gtpmdev =3D {
>> +   .tpmlist =3D NULL,
>> +   .num_tpms =3D 0,
>> +   .num_alloc =3D 0,
>> +   .flags =3D TPMIF_CLOSED,
>> +   .events =3D NULL,
>> +   .open_callback =3D NULL,
>> +   .close_callback =3D NULL,
>> +   .suspend_callback =3D NULL,
>> +   .resume_callback =3D NULL,
>> +};
>> +struct wait_queue_head waitq;
>> +int globalinit =3D 0;
>> +
>> +/************************************
>> + * TPMIF SORTED ARRAY FUNCTIONS
>> + * tpmback_dev_t.tpmlist is a sorted array, sorted by domid and then
>> handle number
>> + * Duplicates are not allowed
>> + * **********************************/
>> +
>> +inline void tpmif_req_ready(tpmif_t* tpmif) {
>> +   tpmif->flags |=3D TPMIF_REQ_READY;
>> +   gtpmdev.flags |=3D TPMIF_REQ_READY;
>> +}
>> +
>> +inline void tpmdev_check_req(void) {
>> +   int i;
>> +   int flags;
>> +   local_irq_save(flags);
>> +   for(i =3D 0; i < gtpmdev.num_tpms; ++i) {
>> +      if(gtpmdev.tpmlist[i]->flags & TPMIF_REQ_READY) {
>> +     gtpmdev.flags |=3D TPMIF_REQ_READY;
>> +     local_irq_restore(flags);
>> +     return;
>> +      }
>> +   }
>> +   gtpmdev.flags &=3D ~TPMIF_REQ_READY;
>> +   local_irq_restore(flags);
>> +}
>> +
>> +inline void tpmif_req_finished(tpmif_t* tpmif) {
>> +   tpmif->flags &=3D ~TPMIF_REQ_READY;
>> +   tpmdev_check_req();
>> +}
>> +
>> +int __get_tpmif_index(int st, int n, domid_t domid, unsigned int hand=
le)
>> +{
>> +   int i =3D st + n /2;
>> +   tpmif_t* tmp;
>> +
>> +   if( n <=3D 0 )
>> +      return -1;
>> +
>> +   tmp =3D gtpmdev.tpmlist[i];
>> +   if(domid =3D=3D tmp->domid && tmp->handle =3D=3D handle) {
>> +      return i;
>> +   } else if ( (domid < tmp->domid) ||
>> +     (domid =3D=3D tmp->domid && handle < tmp->handle)) {
>> +      return __get_tpmif_index(st, n/2, domid, handle);
>> +   } else {
>> +      return __get_tpmif_index(i + 1, n/2 - ((n +1) % 2), domid, hand=
le);
>> +   }
>> +}
>> +
>> +/* Returns the array index of the tpmif domid/handle. Returns -1 if n=
o
>> such tpmif exists */
>> +int get_tpmif_index(domid_t domid, unsigned int handle)
>> +{
>> +   int flags;
>> +   int index;
>> +   local_irq_save(flags);
>> +   index =3D __get_tpmif_index(0, gtpmdev.num_tpms, domid, handle);
>> +   local_irq_restore(flags);
>> +   return index;
>> +}
>> +
>> +/* Returns the tpmif domid/handle or NULL if none exists */
>> +tpmif_t* get_tpmif(domid_t domid, unsigned int handle)
>> +{
>> +   int flags;
>> +   int i;
>> +   tpmif_t* ret;
>> +   local_irq_save(flags);
>> +   i =3D get_tpmif_index(domid, handle);
>> +   if (i < 0) {
>> +      ret =3D NULL;
>> +   } else {
>> +      ret =3D gtpmdev.tpmlist[i];
>> +   }
>> +   local_irq_restore(flags);
>> +   return ret;
>> +}
>> +
>> +/* Remove the given tpmif. Returns 0 if it was removed, -1 if it was
>> not removed */
>> +int remove_tpmif(tpmif_t* tpmif)
>> +{
>> +   int i, j;
>> +   char* err;
>> +   int flags;
>> +   local_irq_save(flags);
>> +
>> +   /* Find the index in the array if it exists */
>> +   i =3D get_tpmif_index(tpmif->domid, tpmif->handle);
>> +   if (i < 0) {
>> +      goto error;
>> +   }
>> +
>> +   /* Remove the interface from the list */
>> +   for(j =3D i; j < gtpmdev.num_tpms - 1; ++j) {
>> +      gtpmdev.tpmlist[j] =3D gtpmdev.tpmlist[j+1];
>> +   }
>> +   gtpmdev.tpmlist[j] =3D NULL;
>> +   --gtpmdev.num_tpms;
>> +
>> +   /* If removed tpm was the only ready tpm, then we need to check an=
d
>> turn off the ready flag */
>> +   tpmdev_check_req();
>> +
>> +   local_irq_restore(flags);
>> +
>> +   /* Stop listening for events on this tpm interface */
>> +   if((err =3D xenbus_unwatch_path_token(XBT_NIL, tpmif->fe_state_pat=
h,
>> tpmif->fe_state_path))) {
>> +      TPMBACK_ERR("Unable to unwatch path token `%s' Error was %s
>> Ignoring..\n", tpmif->fe_state_path, err);
>> +      free(err);
>> +   }
>> +
>> +   return 0;
>> +error:
>> +   local_irq_restore(flags);
>> +   return -1;
>> +}
>> +
>> +/* Insert tpmif into dev->tpmlist. Returns 0 on success and non zero =
on
>> error.
>> + * It is an error to insert a tpmif with the same domid and handle
>> + * number
>> + * as something already in the list */
>> +int insert_tpmif(tpmif_t* tpmif)
>> +{
>> +   int flags;
>> +   unsigned int i, j;
>> +   tpmif_t* tmp;
>> +   char* err;
>> +
>> +   local_irq_save(flags);
>> +
>> +   /*Check if we need to allocate more space */
>> +   if (gtpmdev.num_tpms =3D=3D gtpmdev.num_alloc) {
>> +      gtpmdev.num_alloc *=3D 2;
>> +      gtpmdev.tpmlist =3D realloc(gtpmdev.tpmlist, gtpmdev.num_alloc)=
;
>> +   }
>> +
>> +   /*Find where to put the new interface */
>> +   for(i =3D 0; i < gtpmdev.num_tpms; ++i)
>> +   {
>> +      tmp =3D gtpmdev.tpmlist[i];
>> +      if(tpmif->domid =3D=3D tmp->domid && tpmif->handle =3D=3D tmp->=
handle) {
>> +     TPMBACK_ERR("Tried to insert duplicate tpm interface %u/%u\n",
>> (unsigned int) tpmif->domid, tpmif->handle);
>> +     goto error;
>> +      }
>> +      if((tpmif->domid < tmp->domid) ||
>> +        (tpmif->domid =3D=3D tmp->domid && tpmif->handle < tmp->handl=
e)) {
>> +     break;
>> +      }
>> +   }
>> +
>> +   /*Shift all the tpm pointers past i down one */
>> +   for(j =3D gtpmdev.num_tpms; j > i; --j) {
>> +      gtpmdev.tpmlist[j] =3D gtpmdev.tpmlist[j-1];
>> +   }
>> +
>> +   /*Add the new interface */
>> +   gtpmdev.tpmlist[i] =3D tpmif;
>> +   ++gtpmdev.num_tpms;
>> +
>> +   /*Should not be needed, anything inserted with ready flag is
>> probably an error */
>> +   tpmdev_check_req();
>> +
>> +   local_irq_restore(flags);
>> +
>> +   /*Listen for state changes on the new interface */
>> +   if((err =3D xenbus_watch_path_token(XBT_NIL, tpmif->fe_state_path,=

>> tpmif->fe_state_path, &gtpmdev.events)))
>> +   {
>> +      /* if we got an error here we should carefully remove the
>> interface and then return */
>> +      TPMBACK_ERR("Unable to watch path token `%s' Error was %s\n",
>> tpmif->fe_state_path, err);
>> +      free(err);
>> +      remove_tpmif(tpmif);
>> +      goto error_post_irq;
>> +   }
>> +
>> +   return 0;
>> +error:
>> +   local_irq_restore(flags);
>> +error_post_irq:
>> +   return -1;
>> +}
>> +
>> +
>> +/*****************
>> + * CHANGE BACKEND STATE
>> + * *****************/
>> +/*Attempts to change the backend state in xenstore
>> + * returns 0 on success and non-zero on error */
>> +int tpmif_change_state(tpmif_t* tpmif, enum xenbus_state state)
>> +{
>> +   char path[512];
>> +   char *value;
>> +   char *err;
>> +   enum xenbus_state readst;
>> +   TPMBACK_DEBUG("Backend state change %u/%u from=3D%d to=3D%d\n",
>> (unsigned int) tpmif->domid, tpmif->handle, tpmif->state, state);
>> +   if (tpmif->state =3D=3D state)
>> +      return 0;
>> +
>> +   snprintf(path, 512, "backend/vtpm/%u/%u/state", (unsigned int)
>> tpmif->domid, tpmif->handle);
>> +
>> +   if((err =3D xenbus_read(XBT_NIL, path, &value))) {
>> +      TPMBACK_ERR("Unable to read backend state %s, error was %s\n",
>> path, err);
>> +      free(err);
>> +      return -1;
>> +   }
>> +   if(sscanf(value, "%d", &readst) !=3D 1) {
>> +      TPMBACK_ERR("Non integer value (%s) in %s ??\n", value, path);
>> +      free(value);
>> +      return -1;
>> +   }
>> +   free(value);
>> +
>> +   /* It's possible that the backend state got updated by hotplug or
>> something else behind our back */
>> +   if(readst !=3D tpmif->state) {
>> +      TPMBACK_DEBUG("tpm interface state was %d but xenstore state wa=
s
>> %d!\n", tpmif->state, readst);
>> +      tpmif->state =3D readst;
>> +   }
>> +
>> +   /*If if the state isnt changing, then we dont update xenstore b/c =
we
>> dont want to fire extraneous events */
>> +   if(tpmif->state =3D=3D state) {
>> +      return 0;
>> +   }
>> +
>> +   /*update xenstore*/
>> +   snprintf(path, 512, "backend/vtpm/%u/%u", (unsigned int)
>> tpmif->domid, tpmif->handle);
>> +   if((err =3D xenbus_printf(XBT_NIL, path, "state", "%u", state))) {=

>> +      TPMBACK_ERR("Error writing to xenstore %s, error was %s new
>> state=3D%d\n", path, err, state);
>> +      free(err);
>> +      return -1;
>> +   }
>> +
>> +   tpmif->state =3D state;
>> +
>> +   return 0;
>> +}
>> +/**********************************
>> + * TPMIF CREATION AND DELETION
>> + * *******************************/
>> +inline tpmif_t* __init_tpmif(domid_t domid, unsigned int handle)
>> +{
>> +   tpmif_t* tpmif;
>> +   tpmif =3D malloc(sizeof(*tpmif));
>> +   tpmif->domid =3D domid;
>> +   tpmif->handle =3D handle;
>> +   tpmif->fe_path =3D NULL;
>> +   tpmif->fe_state_path =3D NULL;
>> +   tpmif->state =3D XenbusStateInitialising;
>> +   tpmif->status =3D DISCONNECTED;
>> +   tpmif->tx =3D NULL;
>> +   tpmif->pages =3D NULL;
>> +   tpmif->flags =3D 0;
>> +   tpmif->uuid =3D NULL;
>> +   return tpmif;
>> +}
>> +
>> +void __free_tpmif(tpmif_t* tpmif)
>> +{
>> +   if(tpmif->pages) {
>> +      free(tpmif->pages);
>> +   }
>> +   if(tpmif->fe_path) {
>> +      free(tpmif->fe_path);
>> +   }
>> +   if(tpmif->fe_state_path) {
>> +      free(tpmif->fe_state_path);
>> +   }
>> +   if(tpmif->uuid) {
>> +      free(tpmif->uuid);
>> +   }
>> +   free(tpmif);
>> +}
>> +/* Creates a new tpm interface, adds it to the sorted array and retur=
ns it.
>> + * returns NULL on error
>> + * If the tpm interface already exists, it is returned*/
>> +tpmif_t* new_tpmif(domid_t domid, unsigned int handle)
>> +{
>> +   tpmif_t* tpmif;
>> +   char* err;
>> +   char path[512];
>> +
>> +   /* Make sure we haven't already created this tpm
>> +    * Double events can occur */
>> +   if((tpmif =3D get_tpmif(domid, handle)) !=3D NULL) {
>> +      return tpmif;
>> +   }
>> +
>> +   tpmif =3D __init_tpmif(domid, handle);
>> +
>> +   /* Get the uuid from xenstore */
>> +   snprintf(path, 512, "backend/vtpm/%u/%u/uuid", (unsigned int) domi=
d,
>> handle);
>> +   if((err =3D xenbus_read(XBT_NIL, path, &tpmif->uuid))) {
>> +      TPMBACK_ERR("Error reading %s, Error =3D %s\n", path, err);
>> +      free(err);
>> +      goto error;
>> +   }
>> +
>> +   /* Do the exclusive uuid check now */
>> +   if(gtpmdev.exclusive_uuids !=3D NULL) {
>> +      char** ptr;
>> +
>> +      /* Check that its in the whitelist */
>> +      for(ptr =3D gtpmdev.exclusive_uuids; *ptr !=3D NULL; ++ptr) {
>> +     if(!strcmp(tpmif->uuid, *ptr)) {
>> +        break;
>> +     }
>> +      }
>> +      /* If *ptr =3D=3D NULL then we went through the whole list with=
out a
>> match, so close the connection */
>> +      if(*ptr =3D=3D NULL) {
>> +     tpmif_change_state(tpmif, XenbusStateClosed);
>> +     TPMBACK_ERR("Frontend %u/%u tried to connect with invalid
>> uuid=3D%s\n", (unsigned int) domid, handle, tpmif->uuid);
>> +     goto error;
>> +      }
>> +   }
>> +
>> +   /* allocate pages to be used for shared mapping */
>> +   if((tpmif->pages =3D malloc(sizeof(void*) * TPMIF_TX_RING_SIZE)) =3D=
=3D
>> NULL) {
>> +      goto error;
>> +   }
>> +   memset(tpmif->pages, 0, sizeof(void*) * TPMIF_TX_RING_SIZE);
>> +
>> +   if(tpmif_change_state(tpmif, XenbusStateInitWait)) {
>> +      goto error;
>> +   }
>> +
>> +   snprintf(path, 512, "backend/vtpm/%u/%u/frontend", (unsigned int)
>> domid, handle);
>> +   if((err =3D xenbus_read(XBT_NIL, path, &tpmif->fe_path))) {
>> +      TPMBACK_ERR("Error creating new tpm instance xenbus_read(%s),
>> Error =3D %s", path, err);
>> +      free(err);
>> +      goto error;
>> +   }
>> +
>> +   /*Set the state path */
>> +   tpmif->fe_state_path =3D malloc(strlen(tpmif->fe_path) + 7);
>> +   strcpy(tpmif->fe_state_path, tpmif->fe_path);
>> +   strcat(tpmif->fe_state_path, "/state");
>> +
>> +   if(insert_tpmif(tpmif)) {
>> +      goto error;
>> +   }
>> +   TPMBACK_DEBUG("New tpmif %u/%u\n", (unsigned int) tpmif->domid,
>> tpmif->handle);
>> +   /* Do the callback now */
>> +   if(gtpmdev.open_callback) {
>> +      gtpmdev.open_callback(tpmif->domid, tpmif->handle);
>> +   }
>> +   return tpmif;
>> +error:
>> +   __free_tpmif(tpmif);
>> +   return NULL;
>> +
>> +}
>> +
>> +/* Removes tpmif from dev->tpmlist and frees it's memory usage */
>> +void free_tpmif(tpmif_t* tpmif)
>> +{
>> +   char* err;
>> +   char path[512];
>> +   TPMBACK_DEBUG("Free tpmif %u/%u\n", (unsigned int) tpmif->domid,
>> tpmif->handle);
>> +   if(tpmif->flags & TPMIF_CLOSED) {
>> +      TPMBACK_ERR("Tried to free an instance twice! Theres a bug
>> somewhere!\n");
>> +      BUG();
>> +   }
>> +   tpmif->flags =3D TPMIF_CLOSED;
>> +
>> +   tpmif_change_state(tpmif, XenbusStateClosing);
>> +
>> +   /* Unmap share page and unbind event channel */
>> +   if(tpmif->status =3D=3D CONNECTED) {
>> +      tpmif->status =3D DISCONNECTING;
>> +      mask_evtchn(tpmif->evtchn);
>> +
>> +      if(gntmap_munmap(&gtpmdev.map, (unsigned long)tpmif->tx, 1)) {
>> +     TPMBACK_ERR("%u/%u Error occured while trying to unmap shared
>> page\n", (unsigned int) tpmif->domid, tpmif->handle);
>> +      }
>> +
>> +      unbind_evtchn(tpmif->evtchn);
>> +   }
>> +   tpmif->status =3D DISCONNECTED;
>> +   tpmif_change_state(tpmif, XenbusStateClosed);
>> +
>> +   /* Do the callback now */
>> +   if(gtpmdev.close_callback) {
>> +      gtpmdev.close_callback(tpmif->domid, tpmif->handle);
>> +   }
>> +
>> +   /* remove from array */
>> +   remove_tpmif(tpmif);
>> +
>> +   /* Wake up anyone possibly waiting on this interface and let them
>> exit */
>> +   wake_up(&waitq);
>> +   schedule();
>> +
>> +   /* Remove the old xenbus entries */
>> +   snprintf(path, 512, "backend/vtpm/%u/%u", (unsigned int)
>> tpmif->domid, tpmif->handle);
>> +   if((err =3D xenbus_rm(XBT_NIL, path))) {
>> +      TPMBACK_ERR("Error cleaning up xenbus entries path=3D%s
>> error=3D%s\n", path, err);
>> +      free(err);
>> +   }
>> +
>> +   TPMBACK_LOG("Frontend %u/%u disconnected\n", (unsigned int)
>> tpmif->domid, tpmif->handle);
>> +
>> +   /* free memory */
>> +   __free_tpmif(tpmif);
>> +
>> +}
>> +
>> +/**********************
>> + * REMAINING TPMBACK FUNCTIONS
>> + * ********************/
>> +
>> +/*Event channel handler */
>> +void tpmback_handler(evtchn_port_t port, struct pt_regs *regs, void *=
data)
>> +{
>> +   tpmif_t* tpmif =3D (tpmif_t*) data;
>> +   tpmif_tx_request_t* tx =3D &tpmif->tx->ring[0].req;
>> +   /* Throw away 0 size events, these can trigger from event channel
>> unmasking */
>> +   if(tx->size =3D=3D 0)
>> +      return;
>> +
>> +   TPMBACK_DEBUG("EVENT CHANNEL FIRE %u/%u\n", (unsigned int)
>> tpmif->domid, tpmif->handle);
>> +   tpmif_req_ready(tpmif);
>> +   wake_up(&waitq);
>> +
>> +}
>> +
>> +/* Connect to frontend */
>> +int connect_fe(tpmif_t* tpmif)
>> +{
>> +   char path[512];
>> +   char* err, *value;
>> +   uint32_t domid;
>> +   grant_ref_t ringref;
>> +   evtchn_port_t evtchn;
>> +
>> +   /* If already connected then quit */
>> +   if (tpmif->status =3D=3D CONNECTED) {
>> +      TPMBACK_DEBUG("%u/%u tried to connect while it was already
>> connected?\n", (unsigned int) tpmif->domid, tpmif->handle);
>> +      return 0;
>> +   }
>> +
>> +   /* Fetch the grant reference */
>> +   snprintf(path, 512, "%s/ring-ref", tpmif->fe_path);
>> +   if((err =3D xenbus_read(XBT_NIL, path, &value))) {
>> +      TPMBACK_ERR("Error creating new tpm instance xenbus_read(%s)
>> Error =3D %s", path, err);
>> +      free(err);
>> +      return -1;
>> +   }
>> +   if(sscanf(value, "%d", &ringref) !=3D 1) {
>> +      TPMBACK_ERR("Non integer value (%s) in %s ??\n", value, path);
>> +      free(value);
>> +      return -1;
>> +   }
>> +   free(value);
>> +
>> +
>> +   /* Fetch the event channel*/
>> +   snprintf(path, 512, "%s/event-channel", tpmif->fe_path);
>> +   if((err =3D xenbus_read(XBT_NIL, path, &value))) {
>> +      TPMBACK_ERR("Error creating new tpm instance xenbus_read(%s)
>> Error =3D %s", path, err);
>> +      free(err);
>> +      return -1;
>> +   }
>> +   if(sscanf(value, "%d", &evtchn) !=3D 1) {
>> +      TPMBACK_ERR("Non integer value (%s) in %s ??\n", value, path);
>> +      free(value);
>> +      return -1;
>> +   }
>> +   free(value);
>> +
>> +   domid =3D tpmif->domid;
>> +   if((tpmif->tx =3D gntmap_map_grant_refs(&gtpmdev.map, 1, &domid, 0=
,
>> &ringref, PROT_READ | PROT_WRITE)) =3D=3D NULL) {
>> +      TPMBACK_ERR("Failed to map grant reference %u/%u\n", (unsigned
>> int) tpmif->domid, tpmif->handle);
>> +      return -1;
>> +   }
>> +   memset(tpmif->tx, 0, PAGE_SIZE);
>> +
>> +   /*Bind the event channel */
>> +   if((evtchn_bind_interdomain(tpmif->domid, evtchn, tpmback_handler,=

>> tpmif, &tpmif->evtchn)))
>> +   {
>> +      TPMBACK_ERR("%u/%u Unable to bind to interdomain event
>> channel!\n", (unsigned int) tpmif->domid, tpmif->handle);
>> +      goto error_post_map;
>> +   }
>> +   unmask_evtchn(tpmif->evtchn);
>> +
>> +   /* Write the ready flag and change status to connected */
>> +   snprintf(path, 512, "backend/vtpm/%u/%u", (unsigned int)
>> tpmif->domid, tpmif->handle);
>> +   if((err =3D xenbus_printf(XBT_NIL, path, "ready", "%u", 1))) {
>> +      TPMBACK_ERR("%u/%u Unable to write ready flag on connect_fe()\n=
",
>> (unsigned int) tpmif->domid, tpmif->handle);
>> +      free(err);
>> +      goto error_post_evtchn;
>> +   }
>> +   tpmif->status =3D CONNECTED;
>> +   if((tpmif_change_state(tpmif, XenbusStateConnected))){
>> +      goto error_post_evtchn;
>> +   }
>> +
>> +   TPMBACK_LOG("Frontend %u/%u connected\n", (unsigned int)
>> tpmif->domid, tpmif->handle);
>> +
>> +   return 0;
>> +error_post_evtchn:
>> +   mask_evtchn(tpmif->evtchn);
>> +   unbind_evtchn(tpmif->evtchn);
>> +error_post_map:
>> +   gntmap_munmap(&gtpmdev.map, (unsigned long)tpmif->tx, 1);
>> +   return -1;
>> +}
>> +
>> +static int frontend_changed(tpmif_t* tpmif)
>> +{
>> +   int state =3D xenbus_read_integer(tpmif->fe_state_path);
>> +   if(state < 0) {
>> +      state =3D XenbusStateUnknown;
>> +   }
>> +
>> +   TPMBACK_DEBUG("Frontend %u/%u state changed to %d\n", (unsigned in=
t)
>> tpmif->domid, tpmif->handle, state);
>> +
>> +   switch (state) {
>> +      case XenbusStateInitialising:
>> +      case XenbusStateInitialised:
>> +     break;
>> +
>> +      case XenbusStateConnected:
>> +     if(connect_fe(tpmif)) {
>> +        TPMBACK_ERR("Failed to connect to front end %u/%u\n", (unsign=
ed
>> int) tpmif->domid, tpmif->handle);
>> +        tpmif_change_state(tpmif, XenbusStateClosed);
>> +        return -1;
>> +     }
>> +     break;
>> +
>> +      case XenbusStateClosing:
>> +     tpmif_change_state(tpmif, XenbusStateClosing);
>> +     break;
>> +
>> +      case XenbusStateUnknown: /* keep it here */
>> +      case XenbusStateClosed:
>> +     free_tpmif(tpmif);
>> +     break;
>> +
>> +      default:
>> +     TPMBACK_DEBUG("BAD STATE CHANGE %u/%u state =3D %d for tpmif\n",=

>> (unsigned int) tpmif->domid, tpmif->handle, state);
>> +     return -1;
>> +   }
>> +   return 0;
>> +}
>> +
>> +
>> +/* parses the string that comes out of xenbus_watch_wait_return. */
>> +static int parse_eventstr(const char* evstr, domid_t* domid, unsigned=

>> int* handle)
>> +{
>> +   int ret;
>> +   char cmd[40];
>> +   char* err;
>> +   char* value;
>> +   unsigned int udomid =3D 0;
>> +   tpmif_t* tpmif;
>> +   /* First check for new frontends, this occurs when
>> /backend/vtpm/<domid>/<handle> gets created. Note we what the sscanf t=
o
>> fail on the last %s */
>> +   if (sscanf(evstr, "backend/vtpm/%u/%u/%40s", &udomid, handle, cmd)=

>> =3D=3D 2) {
>> +      *domid =3D udomid;
>> +      /* Make sure the entry exists, if this event triggers because t=
he
>> entry dissapeared then ignore it */
>> +      if((err =3D xenbus_read(XBT_NIL, evstr, &value))) {
>> +     free(err);
>> +     return EV_NONE;
>> +      }
>> +      free(value);
>> +      /* Make sure the tpmif entry does not already exist, this shoul=
d
>> not happen */
>> +      if((tpmif =3D get_tpmif(*domid, *handle)) !=3D NULL) {
>> +     TPMBACK_DEBUG("Duplicate tpm entries! %u %u\n", tpmif->domid,
>> tpmif->handle);
>> +     return EV_NONE;
>> +      }
>> +      return EV_NEWFE;
>> +   } else if((ret =3D sscanf(evstr,
>> "/local/domain/%u/device/vtpm/%u/%40s", &udomid, handle, cmd)) =3D=3D =
3) {
>> +      *domid =3D udomid;
>> +      if (!strcmp(cmd, "state"))
>> +     return EV_STCHNG;
>> +   }
>> +   return EV_NONE;
>> +}
>> +
>> +void handle_backend_event(char* evstr) {
>> +   tpmif_t* tpmif;
>> +   domid_t domid;
>> +   unsigned int handle;
>> +   int event;
>> +
>> +   TPMBACK_DEBUG("Xenbus Event: %s\n", evstr);
>> +
>> +   event =3D parse_eventstr(evstr, &domid, &handle);
>> +
>> +   switch(event) {
>> +      case EV_NEWFE:
>> +     if(new_tpmif(domid, handle) =3D=3D NULL) {
>> +        TPMBACK_ERR("Failed to create new tpm instance %u/%u\n",
>> (unsigned int) domid, handle);
>> +     }
>> +     wake_up(&waitq);
>> +     break;
>> +      case EV_STCHNG:
>> +     if((tpmif =3D get_tpmif(domid, handle))) {
>> +        frontend_changed(tpmif);
>> +     } else {
>> +        TPMBACK_DEBUG("Event Received for non-existant tpm!
>> instance=3D%u/%u xenbus_event=3D%s\n", (unsigned int) domid, handle, e=
vstr);
>> +     }
>> +     break;
>> +   }
>> +}
>> +
>> +/* Runs through the given path and creates events recursively
>> + * for all of its children.
>> + * @path - xenstore path to scan */
>> +static void generate_backend_events(const char* path)
>> +{
>> +   char* err;
>> +   int i, len;
>> +   char **dirs;
>> +   char *entry;
>> +
>> +   if((err =3D xenbus_ls(XBT_NIL, path, &dirs)) !=3D NULL) {
>> +      free(err);
>> +      return;
>> +   }
>> +
>> +   for(i =3D 0; dirs[i] !=3D NULL; ++i) {
>> +      len =3D strlen(path) + strlen(dirs[i]) + 2;
>> +      entry =3D malloc(len);
>> +      snprintf(entry, len, "%s/%s", path, dirs[i]);
>> +
>> +      /* Generate and handle event for the entry itself */
>> +      handle_backend_event(entry);
>> +
>> +      /* Do children */
>> +      generate_backend_events(entry);
>> +
>> +      /* Cleanup */
>> +      free(entry);
>> +      free(dirs[i]);
>> +   }
>> +   free(dirs);
>> +   return;
>> +}
>> +
>> +char* tpmback_get_uuid(domid_t domid, unsigned int handle)
>> +{
>> +   tpmif_t* tpmif;
>> +   if((tpmif =3D get_tpmif(domid, handle)) =3D=3D NULL) {
>> +      TPMBACK_DEBUG("get_uuid() failed, %u/%u is an invalid
>> frontend\n", (unsigned int) domid, handle);
>> +      return NULL;
>> +   }
>> +
>> +   return tpmif->uuid;
>> +}
>> +
>> +void tpmback_set_open_callback(void (*cb)(domid_t, unsigned int))
>> +{
>> +   gtpmdev.open_callback =3D cb;
>> +}
>> +void tpmback_set_close_callback(void (*cb)(domid_t, unsigned int))
>> +{
>> +   gtpmdev.close_callback =3D cb;
>> +}
>> +void tpmback_set_suspend_callback(void (*cb)(domid_t, unsigned int))
>> +{
>> +   gtpmdev.suspend_callback =3D cb;
>> +}
>> +void tpmback_set_resume_callback(void (*cb)(domid_t, unsigned int))
>> +{
>> +   gtpmdev.resume_callback =3D cb;
>> +}
>> +
>> +static void event_listener(void)
>> +{
>> +   const char* bepath =3D "backend/vtpm";
>> +   char **path;
>> +   char* err;
>> +
>> +   /* Setup the backend device watch */
>> +   if((err =3D xenbus_watch_path_token(XBT_NIL, bepath, bepath,
>> &gtpmdev.events)) !=3D NULL) {
>> +      TPMBACK_ERR("xenbus_watch_path_token(%s) failed with error
>> %s!\n", bepath, err);
>> +      free(err);
>> +      goto egress;
>> +   }
>> +
>> +   /* Check for any frontends that connected before we set the watch.=

>> +    * This is almost guaranteed to happen if both domains are started=

>> +    * immediatly one after the other.
>> +    * We do this by manually generating events on everything in the b=
ackend
>> +    * path */
>> +   generate_backend_events(bepath);
>> +
>> +   /* Wait and listen for changes in frontend connections */
>> +   while(1) {
>> +      path =3D xenbus_wait_for_watch_return(&gtpmdev.events);
>> +
>> +      /*If quit flag was set then exit */
>> +      if(gtpmdev.flags & TPMIF_CLOSED) {
>> +     TPMBACK_DEBUG("listener thread got quit event. Exiting..\n");
>> +     free(path);
>> +     break;
>> +      }
>> +      handle_backend_event(*path);
>> +      free(path);
>> +
>> +   }
>> +
>> +   if((err =3D xenbus_unwatch_path_token(XBT_NIL, bepath, bepath)) !=3D=
 NULL) {
>> +      free(err);
>> +   }
>> +egress:
>> +   return;
>> +}
>> +
>> +void event_thread(void* p) {
>> +   event_listener();
>> +}
>> +
>> +void init_tpmback(char** exclusive_uuids)
>> +{
>> +   if(!globalinit) {
>> +      init_waitqueue_head(&waitq);
>> +      globalinit =3D 1;
>> +   }
>> +   printk("=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Init TPM BACK =3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D\n");
>> +   gtpmdev.tpmlist =3D malloc(sizeof(tpmif_t*) * DEF_ARRAY_SIZE);
>> +   gtpmdev.num_alloc =3D DEF_ARRAY_SIZE;
>> +   gtpmdev.num_tpms =3D 0;
>> +   gtpmdev.flags =3D 0;
>> +   gtpmdev.exclusive_uuids =3D exclusive_uuids;
>> +
>> +   gtpmdev.open_callback =3D gtpmdev.close_callback =3D NULL;
>> +   gtpmdev.suspend_callback =3D gtpmdev.resume_callback =3D NULL;
>> +
>> +   eventthread =3D create_thread("tpmback-listener", event_thread, NU=
LL);
>> +
>> +}
>> +
>> +void shutdown_tpmback(void)
>> +{
>> +   /* Disable callbacks */
>> +   gtpmdev.open_callback =3D gtpmdev.close_callback =3D NULL;
>> +   gtpmdev.suspend_callback =3D gtpmdev.resume_callback =3D NULL;
>> +
>> +   TPMBACK_LOG("Shutting down tpm backend\n");
>> +   /* Set the quit flag */
>> +   gtpmdev.flags =3D TPMIF_CLOSED;
>> +
>> +   //printk("num tpms is %d\n", gtpmdev.num_tpms);
>> +   /*Free all backend instances */
>> +   while(gtpmdev.num_tpms) {
>> +      free_tpmif(gtpmdev.tpmlist[0]);
>> +   }
>> +   free(gtpmdev.tpmlist);
>> +   gtpmdev.tpmlist =3D NULL;
>> +   gtpmdev.num_alloc =3D 0;
>> +
>> +   /* Wake up anyone possibly waiting on the device and let them exit=
 */
>> +   wake_up(&waitq);
>> +   schedule();
>> +}
>> +
>> +inline void init_tpmcmd(tpmcmd_t* tpmcmd, domid_t domid, unsigned int=

>> handle, char* uuid)
>> +{
>> +   tpmcmd->domid =3D domid;
>> +   tpmcmd->handle =3D handle;
>> +   tpmcmd->uuid =3D uuid;
>> +   tpmcmd->req =3D NULL;
>> +   tpmcmd->req_len =3D 0;
>> +   tpmcmd->resp =3D NULL;
>> +   tpmcmd->resp_len =3D 0;
>> +}
>> +
>> +tpmcmd_t* get_request(tpmif_t* tpmif) {
>> +   tpmcmd_t* cmd;
>> +   tpmif_tx_request_t* tx;
>> +   int offset;
>> +   int tocopy;
>> +   int i;
>> +   uint32_t domid;
>> +   int flags;
>> +
>> +   local_irq_save(flags);
>> +
>> +   /* Allocate the cmd object to hold the data */
>> +   if((cmd =3D malloc(sizeof(*cmd))) =3D=3D NULL) {
>> +      goto error;
>> +   }
>> +   init_tpmcmd(cmd, tpmif->domid, tpmif->handle, tpmif->uuid);
>> +
>> +   tx =3D &tpmif->tx->ring[0].req;
>> +   cmd->req_len =3D tx->size;
>> +   /* Allocate the buffer */
>> +   if(cmd->req_len) {
>> +      if((cmd->req =3D malloc(cmd->req_len)) =3D=3D NULL) {
>> +     goto error;
>> +      }
>> +   }
>> +   /* Copy the bits from the shared pages */
>> +   offset =3D 0;
>> +   for(i =3D 0; i < TPMIF_TX_RING_SIZE && offset < cmd->req_len; ++i)=
 {
>> +      tx =3D &tpmif->tx->ring[i].req;
>> +
>> +      /* Map the page with the data */
>> +      domid =3D (uint32_t)tpmif->domid;
>> +      if((tpmif->pages[i] =3D gntmap_map_grant_refs(&gtpmdev.map, 1,
>> &domid, 0, &tx->ref, PROT_READ)) =3D=3D NULL) {
>> +     TPMBACK_ERR("%u/%u Unable to map shared page during read!\n",
>> (unsigned int) tpmif->domid, tpmif->handle);
>> +     goto error;
>> +      }
>> +
>> +      /* do the copy now */
>> +      tocopy =3D min(cmd->req_len - offset, PAGE_SIZE);
>> +      memcpy(&cmd->req[offset], tpmif->pages[i], tocopy);
>> +      offset +=3D tocopy;
>> +
>> +      /* release the page */
>> +      gntmap_munmap(&gtpmdev.map, (unsigned long)tpmif->pages[i], 1);=

>> +
>> +   }
>> +
>> +#ifdef TPMBACK_PRINT_DEBUG
>> +   TPMBACK_DEBUG("Received Tpm Command from %u/%u of size %u",
>> (unsigned int) tpmif->domid, tpmif->handle, cmd->req_len);
>> +   for(i =3D 0; i < cmd->req_len; ++i) {
>> +      if (!(i % 30)) {
>> +     TPMBACK_DEBUG_MORE("\n");
>> +      }
>> +      TPMBACK_DEBUG_MORE("%02hhX ", cmd->req[i]);
>> +   }
>> +   TPMBACK_DEBUG_MORE("\n\n");
>> +#endif
>> +
>> +   local_irq_restore(flags);
>> +   return cmd;
>> +error:
>> +   if(cmd !=3D NULL) {
>> +      if (cmd->req !=3D NULL) {
>> +     free(cmd->req);
>> +     cmd->req =3D NULL;
>> +      }
>> +      free(cmd);
>> +      cmd =3D NULL;
>> +   }
>> +   local_irq_restore(flags);
>> +   return NULL;
>> +
>> +}
>> +
>> +void send_response(tpmcmd_t* cmd, tpmif_t* tpmif)
>> +{
>> +   tpmif_tx_request_t* tx;
>> +   int offset;
>> +   int i;
>> +   uint32_t domid;
>> +   int tocopy;
>> +   int flags;
>> +
>> +   local_irq_save(flags);
>> +
>> +   tx =3D &tpmif->tx->ring[0].req;
>> +   tx->size =3D cmd->resp_len;
>> +
>> +   offset =3D 0;
>> +   for(i =3D 0; i < TPMIF_TX_RING_SIZE && offset < cmd->resp_len; ++i=
) {
>> +      tx =3D &tpmif->tx->ring[i].req;
>> +
>> +      /* Map the page with the data */
>> +      domid =3D (uint32_t)tpmif->domid;
>> +      if((tpmif->pages[i] =3D gntmap_map_grant_refs(&gtpmdev.map, 1,
>> &domid, 0, &tx->ref, PROT_WRITE)) =3D=3D NULL) {
>> +     TPMBACK_ERR("%u/%u Unable to map shared page during write!\n",
>> (unsigned int) tpmif->domid, tpmif->handle);
>> +     goto error;
>> +      }
>> +
>> +      /* do the copy now */
>> +      tocopy =3D min(cmd->resp_len - offset, PAGE_SIZE);
>> +      memcpy(tpmif->pages[i], &cmd->resp[offset], tocopy);
>> +      offset +=3D tocopy;
>> +
>> +      /* release the page */
>> +      gntmap_munmap(&gtpmdev.map, (unsigned long)tpmif->pages[i], 1);=

>> +
>> +   }
>> +
>> +#ifdef TPMBACK_PRINT_DEBUG
>> +   TPMBACK_DEBUG("Sent response to %u/%u of size %u", (unsigned int)
>> tpmif->domid, tpmif->handle, cmd->resp_len);
>> +   for(i =3D 0; i < cmd->resp_len; ++i) {
>> +      if (!(i % 30)) {
>> +     TPMBACK_DEBUG_MORE("\n");
>> +      }
>> +      TPMBACK_DEBUG_MORE("%02hhX ", cmd->resp[i]);
>> +   }
>> +   TPMBACK_DEBUG_MORE("\n\n");
>> +#endif
>> +   /* clear the ready flag and send the event channel notice to the
>> frontend */
>> +   tpmif_req_finished(tpmif);
>> +   notify_remote_via_evtchn(tpmif->evtchn);
>> +error:
>> +   local_irq_restore(flags);
>> +   return;
>> +}
>> +
>> +tpmcmd_t* tpmback_req_any(void)
>> +{
>> +   int i;
>> +   /* Block until something has a request */
>> +   wait_event(waitq, (gtpmdev.flags & (TPMIF_REQ_READY | TPMIF_CLOSED=
)));
>> +
>> +   /* Check if were shutting down */
>> +   if(gtpmdev.flags & TPMIF_CLOSED) {
>> +      /* if something was waiting for us to give up the queue so it c=
an
>> shutdown, let it finish */
>> +      schedule();
>> +      return NULL;
>> +   }
>> +
>> +   for(i =3D 0; i < gtpmdev.num_tpms; ++i) {
>> +      if(gtpmdev.tpmlist[i]->flags & TPMIF_REQ_READY) {
>> +     return get_request(gtpmdev.tpmlist[i]);
>> +      }
>> +   }
>> +
>> +   TPMBACK_ERR("backend request ready flag was set but no interfaces
>> were actually ready\n");
>> +   return NULL;
>> +}
>> +
>> +tpmcmd_t* tpmback_req(domid_t domid, unsigned int handle)
>> +{
>> +   tpmif_t* tpmif;
>> +   tpmif =3D get_tpmif(domid, handle);
>> +   if(tpmif =3D=3D NULL) {
>> +      return NULL;
>> +   }
>> +
>> +   wait_event(waitq, (tpmif->flags & (TPMIF_REQ_READY | TPMIF_CLOSED)=

>> || gtpmdev.flags & TPMIF_CLOSED));
>> +
>> +   /* Check if were shutting down */
>> +   if(tpmif->flags & TPMIF_CLOSED || gtpmdev.flags & TPMIF_CLOSED) {
>> +      /* if something was waiting for us to give up the queue so it c=
an
>> free this instance, let it finish */
>> +      schedule();
>> +      return NULL;
>> +   }
>> +
>> +   return get_request(tpmif);
>> +}
>> +
>> +void tpmback_resp(tpmcmd_t* tpmcmd)
>> +{
>> +   tpmif_t* tpmif;
>> +
>> +   /* Get the associated interface, if it doesnt exist then just quit=
 */
>> +   tpmif =3D get_tpmif(tpmcmd->domid, tpmcmd->handle);
>> +   if(tpmif =3D=3D NULL) {
>> +      TPMBACK_ERR("Tried to send a reponse to non existant frontend
>> %u/%u\n", (unsigned int) tpmcmd->domid, tpmcmd->handle);
>> +      goto end;
>> +   }
>> +
>> +   if(!(tpmif->flags & TPMIF_REQ_READY)) {
>> +      TPMBACK_ERR("Tried to send response to a frontend that was not
>> waiting for one %u/%u\n", (unsigned int) tpmcmd->domid, tpmcmd->handle=
);
>> +      goto end;
>> +   }
>> +
>> +   /* Send response to frontend */
>> +   send_response(tpmcmd, tpmif);
>> +
>> +end:
>> +   if(tpmcmd->req !=3D NULL) {
>> +      free(tpmcmd->req);
>> +   }
>> +   free(tpmcmd);
>> +   return;
>> +}
>> +
>> +int tpmback_wait_for_frontend_connect(domid_t *domid, unsigned int *h=
andle)
>> +{
>> +   tpmif_t* tpmif;
>> +   int flags;
>> +   wait_event(waitq, ((gtpmdev.num_tpms > 0) || gtpmdev.flags &
>> TPMIF_CLOSED));
>> +   if(gtpmdev.flags & TPMIF_CLOSED) {
>> +      return -1;
>> +   }
>> +   local_irq_save(flags);
>> +   tpmif =3D gtpmdev.tpmlist[0];
>> +   *domid =3D tpmif->domid;
>> +   *handle =3D tpmif->handle;
>> +   local_irq_restore(flags);
>> +
>> +   return 0;
>> +}
>> +
>> +int tpmback_num_frontends(void)
>> +{
>> +   return gtpmdev.num_tpms;
>> +}
>> diff --git a/extras/mini-os/tpmfront.c b/extras/mini-os/tpmfront.c
>> --- /dev/null
>> +++ b/extras/mini-os/tpmfront.c
>> @@ -0,0 +1,606 @@
>> +/*
>> + * Copyright (c) 2010-2012 United States Government, as represented b=
y
>> + * the Secretary of Defense.  All rights reserved.
>> + *
>> + * This driver is free software: you can redistribute it and/or modif=
y
>> + * it under the terms of the GNU General Public License as published =
by
>> + * the Free Software Foundation, either version 3 of the License, or
>> + * (at your option) any later version.
>> + *
>> + * This driver is distributed in the hope that it will be useful,
>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
>> + * GNU General Public License for more details.
>> + *
>> + * You should have received a copy of the GNU General Public License
>> + * along with this program.  If not, see <http://www.gnu.org/licenses=
/>.
>> + *
>> + * Based upon the files:
>> + *  drivers/char/tpm/tpm_vtpm.c
>> + *  drivers/char/tpm/tpm_xen.c
>> + * from the Linux kernel, which are Copyright (C) 2006 IBM Corporatio=
n
>> + */
>> +#include <mini-os/os.h>
>> +#include <mini-os/xenbus.h>
>> +#include <mini-os/xmalloc.h>
>> +#include <mini-os/events.h>
>> +#include <mini-os/wait.h>
>> +#include <mini-os/gnttab.h>
>> +#include <xen/io/xenbus.h>
>> +#include <xen/io/tpmif.h>
>> +#include <mini-os/tpmfront.h>
>> +#include <fcntl.h>
>> +
>> +//#define TPMFRONT_PRINT_DEBUG
>> +#ifdef TPMFRONT_PRINT_DEBUG
>> +#define TPMFRONT_DEBUG(fmt,...) printk("Tpmfront:Debug("__FILE__":%d)=
 "
>> fmt, __LINE__, ##__VA_ARGS__)
>> +#define TPMFRONT_DEBUG_MORE(fmt,...) printk(fmt, ##__VA_ARGS__)
>> +#else
>> +#define TPMFRONT_DEBUG(fmt,...)
>> +#endif
>> +#define TPMFRONT_ERR(fmt,...) printk("Tpmfront:Error " fmt, ##__VA_AR=
GS__)
>> +#define TPMFRONT_LOG(fmt,...) printk("Tpmfront:Info " fmt, ##__VA_ARG=
S__)
>> +
>> +#define min(a,b) (((a) < (b)) ? (a) : (b))
>> +
>> +void tpmfront_handler(evtchn_port_t port, struct pt_regs *regs, void
>> *data) {
>> +   struct tpmfront_dev* dev =3D (struct tpmfront_dev*) data;
>> +   /*If we get a response when we didnt make a request, just ignore i=
t */
>> +   if(!dev->waiting) {
>> +      return;
>> +   }
>> +
>> +   dev->waiting =3D 0;
>> +#ifdef HAVE_LIBC
>> +   if(dev->fd >=3D 0) {
>> +      files[dev->fd].read =3D 1;
>> +   }
>> +#endif
>> +   wake_up(&dev->waitq);
>> +}
>> +
>> +static int publish_xenbus(struct tpmfront_dev* dev) {
>> +   xenbus_transaction_t xbt;
>> +   int retry;
>> +   char* err;
>> +   /* Write the grant reference and event channel to xenstore */
>> +again:
>> +   if((err =3D xenbus_transaction_start(&xbt))) {
>> +      TPMFRONT_ERR("Unable to start xenbus transaction, error was
>> %s\n", err);
>> +      free(err);
>> +      return -1;
>> +   }
>> +
>> +   if((err =3D xenbus_printf(xbt, dev->nodename, "ring-ref", "%u",
>> (unsigned int) dev->ring_ref))) {
>> +      TPMFRONT_ERR("Unable to write %s/ring-ref, error was %s\n",
>> dev->nodename, err);
>> +      free(err);
>> +      goto abort_transaction;
>> +   }
>> +
>> +   if((err =3D xenbus_printf(xbt, dev->nodename, "event-channel", "%u=
",
>> (unsigned int) dev->evtchn))) {
>> +      TPMFRONT_ERR("Unable to write %s/event-channel, error was %s\n"=
,
>> dev->nodename, err);
>> +      free(err);
>> +      goto abort_transaction;
>> +   }
>> +
>> +   if((err =3D xenbus_transaction_end(xbt, 0, &retry))) {
>> +      TPMFRONT_ERR("Unable to complete xenbus transaction, error was
>> %s\n", err);
>> +      free(err);
>> +      return -1;
>> +   }
>> +   if(retry) {
>> +      goto again;
>> +   }
>> +
>> +   return 0;
>> +abort_transaction:
>> +   if((err =3D xenbus_transaction_end(xbt, 1, &retry))) {
>> +      free(err);
>> +   }
>> +   return -1;
>> +}
>> +
>> +static int wait_for_backend_connect(xenbus_event_queue* events, char*=
 path)
>> +{
>> +   int state;
>> +
>> +   TPMFRONT_LOG("Waiting for backend connection..\n");
>> +   /* Wait for the backend to connect */
>> +   while(1) {
>> +      state =3D xenbus_read_integer(path);
>> +      if ( state < 0)
>> +     state =3D XenbusStateUnknown;
>> +      switch(state) {
>> +     /* Bad states, we quit with error */
>> +     case XenbusStateUnknown:
>> +     case XenbusStateClosing:
>> +     case XenbusStateClosed:
>> +        TPMFRONT_ERR("Unable to connect to backend\n");
>> +        return -1;
>> +     /* If backend is connected then break out of loop */
>> +     case XenbusStateConnected:
>> +        TPMFRONT_LOG("Backend Connected\n");
>> +        return 0;
>> +     default:
>> +        xenbus_wait_for_watch(events);
>> +      }
>> +   }
>> +
>> +}
>> +
>> +static int wait_for_backend_closed(xenbus_event_queue* events, char* =
path)
>> +{
>> +   int state;
>> +
>> +   TPMFRONT_LOG("Waiting for backend to close..\n");
>> +   while(1) {
>> +      state =3D xenbus_read_integer(path);
>> +      if ( state < 0)
>> +     state =3D XenbusStateUnknown;
>> +      switch(state) {
>> +     case XenbusStateUnknown:
>> +        TPMFRONT_ERR("Backend Unknown state, forcing shutdown\n");
>> +        return -1;
>> +     case XenbusStateClosed:
>> +        TPMFRONT_LOG("Backend Closed\n");
>> +        return 0;
>> +     default:
>> +        xenbus_wait_for_watch(events);
>> +      }
>> +   }
>> +
>> +}
>> +
>> +static int wait_for_backend_state_changed(struct tpmfront_dev* dev,
>> XenbusState state) {
>> +   char* err;
>> +   int ret =3D 0;
>> +   xenbus_event_queue events =3D NULL;
>> +   char path[512];
>> +
>> +   snprintf(path, 512, "%s/state", dev->bepath);
>> +   /*Setup the watch to wait for the backend */
>> +   if((err =3D xenbus_watch_path_token(XBT_NIL, path, path, &events))=
) {
>> +      TPMFRONT_ERR("Could not set a watch on %s, error was %s\n", pat=
h,
>> err);
>> +      free(err);
>> +      return -1;
>> +   }
>> +
>> +   /* Do the actual wait loop now */
>> +   switch(state) {
>> +      case XenbusStateConnected:
>> +     ret =3D wait_for_backend_connect(&events, path);
>> +     break;
>> +      case XenbusStateClosed:
>> +     ret =3D wait_for_backend_closed(&events, path);
>> +     break;
>> +      default:
>> +     break;
>> +   }
>> +
>> +   if((err =3D xenbus_unwatch_path_token(XBT_NIL, path, path))) {
>> +      TPMFRONT_ERR("Unable to unwatch %s, error was %s, ignoring..\n"=
,
>> path, err);
>> +      free(err);
>> +   }
>> +   return ret;
>> +}
>> +
>> +static int tpmfront_connect(struct tpmfront_dev* dev)
>> +{
>> +   char* err;
>> +   /* Create shared page */
>> +   dev->tx =3D (tpmif_tx_interface_t*) alloc_page();
>> +   if(dev->tx =3D=3D NULL) {
>> +      TPMFRONT_ERR("Unable to allocate page for shared memory\n");
>> +      goto error;
>> +   }
>> +   memset(dev->tx, 0, PAGE_SIZE);
>> +   dev->ring_ref =3D gnttab_grant_access(dev->bedomid,
>> virt_to_mfn(dev->tx), 0);
>> +   TPMFRONT_DEBUG("grant ref is %lu\n", (unsigned long) dev->ring_ref=
);
>> +
>> +   /*Create event channel */
>> +   if(evtchn_alloc_unbound(dev->bedomid, tpmfront_handler, dev,
>> &dev->evtchn)) {
>> +      TPMFRONT_ERR("Unable to allocate event channel\n");
>> +      goto error_postmap;
>> +   }
>> +   unmask_evtchn(dev->evtchn);
>> +   TPMFRONT_DEBUG("event channel is %lu\n", (unsigned long) dev->evtc=
hn);
>> +
>> +   /* Write the entries to xenstore */
>> +   if(publish_xenbus(dev)) {
>> +      goto error_postevtchn;
>> +   }
>> +
>> +   /* Change state to connected */
>> +   dev->state =3D XenbusStateConnected;
>> +
>> +   /* Tell the backend that we are ready */
>> +   if((err =3D xenbus_printf(XBT_NIL, dev->nodename, "state", "%u",
>> dev->state))) {
>> +      TPMFRONT_ERR("Unable to write to xenstore %s/state, value=3D%u"=
,
>> dev->nodename, XenbusStateConnected);
>> +      free(err);
>> +      goto error;
>> +   }
>> +
>> +   return 0;
>> +error_postevtchn:
>> +      mask_evtchn(dev->evtchn);
>> +      unbind_evtchn(dev->evtchn);
>> +error_postmap:
>> +      gnttab_end_access(dev->ring_ref);
>> +      free_page(dev->tx);
>> +error:
>> +   return -1;
>> +}
>> +
>> +struct tpmfront_dev* init_tpmfront(const char* _nodename)
>> +{
>> +   struct tpmfront_dev* dev;
>> +   const char* nodename;
>> +   char path[512];
>> +   char* value, *err;
>> +   unsigned long long ival;
>> +   int i;
>> +
>> +   printk("=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Init TPM Front =3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D\n");
>> +
>> +   dev =3D malloc(sizeof(struct tpmfront_dev));
>> +   memset(dev, 0, sizeof(struct tpmfront_dev));
>> +
>> +#ifdef HAVE_LIBC
>> +   dev->fd =3D -1;
>> +#endif
>> +
>> +   nodename =3D _nodename ? _nodename : "device/vtpm/0";
>> +   dev->nodename =3D strdup(nodename);
>> +
>> +   init_waitqueue_head(&dev->waitq);
>> +
>> +   /* Get backend domid */
>> +   snprintf(path, 512, "%s/backend-id", dev->nodename);
>> +   if((err =3D xenbus_read(XBT_NIL, path, &value))) {
>> +      TPMFRONT_ERR("Unable to read %s during tpmfront initialization!=

>> error =3D %s\n", path, err);
>> +      free(err);
>> +      goto error;
>> +   }
>> +   if(sscanf(value, "%llu", &ival) !=3D 1) {
>> +      TPMFRONT_ERR("%s has non-integer value (%s)\n", path, value);
>> +      free(value);
>> +      goto error;
>> +   }
>> +   free(value);
>> +   dev->bedomid =3D ival;
>> +
>> +   /* Get backend xenstore path */
>> +   snprintf(path, 512, "%s/backend", dev->nodename);
>> +   if((err =3D xenbus_read(XBT_NIL, path, &dev->bepath))) {
>> +      TPMFRONT_ERR("Unable to read %s during tpmfront initialization!=

>> error =3D %s\n", path, err);
>> +      free(err);
>> +      goto error;
>> +   }
>> +
>> +   /* Create and publish grant reference and event channel */
>> +   if (tpmfront_connect(dev)) {
>> +      goto error;
>> +   }
>> +
>> +   /* Wait for backend to connect */
>> +   if( wait_for_backend_state_changed(dev, XenbusStateConnected)) {
>> +      goto error;
>> +   }
>> +
>> +   /* Allocate pages that will contain the messages */
>> +   dev->pages =3D malloc(sizeof(void*) * TPMIF_TX_RING_SIZE);
>> +   if(dev->pages =3D=3D NULL) {
>> +      goto error;
>> +   }
>> +   memset(dev->pages, 0, sizeof(void*) * TPMIF_TX_RING_SIZE);
>> +   for(i =3D 0; i < TPMIF_TX_RING_SIZE; ++i) {
>> +      dev->pages[i] =3D (void*)alloc_page();
>> +      if(dev->pages[i] =3D=3D NULL) {
>> +     goto error;
>> +      }
>> +   }
>> +
>> +   TPMFRONT_LOG("Initialization Completed successfully\n");
>> +
>> +   return dev;
>> +
>> +error:
>> +   shutdown_tpmfront(dev);
>> +   return NULL;
>> +}
>> +void shutdown_tpmfront(struct tpmfront_dev* dev)
>> +{
>> +   char* err;
>> +   char path[512];
>> +   int i;
>> +   tpmif_tx_request_t* tx;
>> +   if(dev =3D=3D NULL) {
>> +      return;
>> +   }
>> +   TPMFRONT_LOG("Shutting down tpmfront\n");
>> +   /* disconnect */
>> +   if(dev->state =3D=3D XenbusStateConnected) {
>> +      dev->state =3D XenbusStateClosing;
>> +      //FIXME: Transaction for this?
>> +      /* Tell backend we are closing */
>> +      if((err =3D xenbus_printf(XBT_NIL, dev->nodename, "state", "%u"=
,
>> (unsigned int) dev->state))) {
>> +     free(err);
>> +      }
>> +
>> +      /* Clean up xenstore entries */
>> +      snprintf(path, 512, "%s/event-channel", dev->nodename);
>> +      if((err =3D xenbus_rm(XBT_NIL, path))) {
>> +     free(err);
>> +      }
>> +      snprintf(path, 512, "%s/ring-ref", dev->nodename);
>> +      if((err =3D xenbus_rm(XBT_NIL, path))) {
>> +     free(err);
>> +      }
>> +
>> +      /* Tell backend we are closed */
>> +      dev->state =3D XenbusStateClosed;
>> +      if((err =3D xenbus_printf(XBT_NIL, dev->nodename, "state", "%u"=
,
>> (unsigned int) dev->state))) {
>> +     TPMFRONT_ERR("Unable to write to %s, error was %s", dev->nodenam=
e,
>> err);
>> +     free(err);
>> +      }
>> +
>> +      /* Wait for the backend to close and unmap shared pages, ignore=

>> any errors */
>> +      wait_for_backend_state_changed(dev, XenbusStateClosed);
>> +
>> +      /* Cleanup any shared pages */
>> +      if(dev->pages) {
>> +     for(i =3D 0; i < TPMIF_TX_RING_SIZE; ++i) {
>> +        if(dev->pages[i]) {
>> +           tx =3D &dev->tx->ring[i].req;
>> +           if(tx->ref !=3D 0) {
>> +          gnttab_end_access(tx->ref);
>> +           }
>> +           free_page(dev->pages[i]);
>> +        }
>> +     }
>> +     free(dev->pages);
>> +      }
>> +
>> +      /* Close event channel and unmap shared page */
>> +      mask_evtchn(dev->evtchn);
>> +      unbind_evtchn(dev->evtchn);
>> +      gnttab_end_access(dev->ring_ref);
>> +
>> +      free_page(dev->tx);
>> +
>> +   }
>> +
>> +   /* Cleanup memory usage */
>> +   if(dev->respbuf) {
>> +      free(dev->respbuf);
>> +   }
>> +   if(dev->bepath) {
>> +      free(dev->bepath);
>> +   }
>> +   if(dev->nodename) {
>> +      free(dev->nodename);
>> +   }
>> +   free(dev);
>> +}
>> +
>> +int tpmfront_send(struct tpmfront_dev* dev, const uint8_t* msg, size_=
t
>> length)
>> +{
>> +   int i;
>> +   tpmif_tx_request_t* tx =3D NULL;
>> +   /* Error Checking */
>> +   if(dev =3D=3D NULL || dev->state !=3D XenbusStateConnected) {
>> +      TPMFRONT_ERR("Tried to send message through disconnected
>> frontend\n");
>> +      return -1;
>> +   }
>> +
>> +#ifdef TPMFRONT_PRINT_DEBUG
>> +   TPMFRONT_DEBUG("Sending Msg to backend size=3D%u", (unsigned int) =
length);
>> +   for(i =3D 0; i < length; ++i) {
>> +      if(!(i % 30)) {
>> +     TPMFRONT_DEBUG_MORE("\n");
>> +      }
>> +      TPMFRONT_DEBUG_MORE("%02X ", msg[i]);
>> +   }
>> +   TPMFRONT_DEBUG_MORE("\n");
>> +#endif
>> +
>> +   /* Copy to shared pages now */
>> +   for(i =3D 0; length > 0 && i < TPMIF_TX_RING_SIZE; ++i) {
>> +      /* Share the page */
>> +      tx =3D &dev->tx->ring[i].req;
>> +      tx->unused =3D 0;
>> +      tx->addr =3D virt_to_mach(dev->pages[i]);
>> +      tx->ref =3D gnttab_grant_access(dev->bedomid,
>> virt_to_mfn(dev->pages[i]), 0);
>> +      /* Copy the bits to the page */
>> +      tx->size =3D length > PAGE_SIZE ? PAGE_SIZE : length;
>> +      memcpy(dev->pages[i], &msg[i * PAGE_SIZE], tx->size);
>> +
>> +      /* Update counters */
>> +      length -=3D tx->size;
>> +   }
>> +   dev->waiting =3D 1;
>> +   dev->resplen =3D 0;
>> +#ifdef HAVE_LIBC
>> +   if(dev->fd >=3D 0) {
>> +      files[dev->fd].read =3D 0;
>> +      files[dev->fd].tpmfront.respgot =3D 0;
>> +      files[dev->fd].tpmfront.offset =3D 0;
>> +   }
>> +#endif
>> +   notify_remote_via_evtchn(dev->evtchn);
>> +   return 0;
>> +}
>> +int tpmfront_recv(struct tpmfront_dev* dev, uint8_t** msg, size_t *le=
ngth)
>> +{
>> +   tpmif_tx_request_t* tx;
>> +   int i;
>> +   if(dev =3D=3D NULL || dev->state !=3D XenbusStateConnected) {
>> +      TPMFRONT_ERR("Tried to receive message from disconnected
>> frontend\n");
>> +      return -1;
>> +   }
>> +   /*Wait for the response */
>> +   wait_event(dev->waitq, (!dev->waiting));
>> +
>> +   /* Initialize */
>> +   *msg =3D NULL;
>> +   *length =3D 0;
>> +
>> +   /* special case, just quit */
>> +   tx =3D &dev->tx->ring[0].req;
>> +   if(tx->size =3D=3D 0 ) {
>> +       goto quit;
>> +   }
>> +   /* Get the total size */
>> +   tx =3D &dev->tx->ring[0].req;
>> +   for(i =3D 0; i < TPMIF_TX_RING_SIZE && tx->size > 0; ++i) {
>> +      tx =3D &dev->tx->ring[i].req;
>> +      *length +=3D tx->size;
>> +   }
>> +   /* Alloc the buffer */
>> +   if(dev->respbuf) {
>> +      free(dev->respbuf);
>> +   }
>> +   *msg =3D dev->respbuf =3D malloc(*length);
>> +   dev->resplen =3D *length;
>> +   /* Copy the bits */
>> +   tx =3D &dev->tx->ring[0].req;
>> +   for(i =3D 0; i < TPMIF_TX_RING_SIZE && tx->size > 0; ++i) {
>> +      tx =3D &dev->tx->ring[i].req;
>> +      memcpy(&(*msg)[i * PAGE_SIZE], dev->pages[i], tx->size);
>> +      gnttab_end_access(tx->ref);
>> +      tx->ref =3D 0;
>> +   }
>> +#ifdef TPMFRONT_PRINT_DEBUG
>> +   TPMFRONT_DEBUG("Received response from backend size=3D%u", (unsign=
ed
>> int) *length);
>> +   for(i =3D 0; i < *length; ++i) {
>> +      if(!(i % 30)) {
>> +     TPMFRONT_DEBUG_MORE("\n");
>> +      }
>> +      TPMFRONT_DEBUG_MORE("%02X ", (*msg)[i]);
>> +   }
>> +   TPMFRONT_DEBUG_MORE("\n");
>> +#endif
>> +#ifdef HAVE_LIBC
>> +   if(dev->fd >=3D 0) {
>> +      files[dev->fd].tpmfront.respgot =3D 1;
>> +   }
>> +#endif
>> +quit:
>> +   return 0;
>> +}
>> +
>> +int tpmfront_cmd(struct tpmfront_dev* dev, uint8_t* req, size_t reqle=
n,
>> uint8_t** resp, size_t* resplen)
>> +{
>> +   int rc;
>> +   if((rc =3D tpmfront_send(dev, req, reqlen))) {
>> +      return rc;
>> +   }
>> +   if((rc =3D tpmfront_recv(dev, resp, resplen))) {
>> +      return rc;
>> +   }
>> +
>> +   return 0;
>> +}
>> +
>> +#ifdef HAVE_LIBC
>> +#include <errno.h>
>> +int tpmfront_open(struct tpmfront_dev* dev)
>> +{
>> +   /* Silently prevent multiple opens */
>> +   if(dev->fd !=3D -1) {
>> +      return dev->fd;
>> +   }
>> +
>> +   dev->fd =3D alloc_fd(FTYPE_TPMFRONT);
>> +   printk("tpmfront_open(%s) -> %d\n", dev->nodename, dev->fd);
>> +   files[dev->fd].tpmfront.dev =3D dev;
>> +   files[dev->fd].tpmfront.offset =3D 0;
>> +   files[dev->fd].tpmfront.respgot =3D 0;
>> +   return dev->fd;
>> +}
>> +
>> +int tpmfront_posix_write(int fd, const uint8_t* buf, size_t count)
>> +{
>> +   int rc;
>> +   struct tpmfront_dev* dev;
>> +   dev =3D files[fd].tpmfront.dev;
>> +
>> +   if(count =3D=3D 0) {
>> +      return 0;
>> +   }
>> +
>> +   /* Return an error if we are already processing a command */
>> +   if(dev->waiting) {
>> +      errno =3D EINPROGRESS;
>> +      return -1;
>> +   }
>> +   /* Send the command now */
>> +   if((rc =3D tpmfront_send(dev, buf, count)) !=3D 0) {
>> +      errno =3D EIO;
>> +      return -1;
>> +   }
>> +   return count;
>> +}
>> +
>> +int tpmfront_posix_read(int fd, uint8_t* buf, size_t count)
>> +{
>> +   int rc;
>> +   uint8_t* dummybuf;
>> +   size_t dummysz;
>> +   struct tpmfront_dev* dev;
>> +
>> +   dev =3D files[fd].tpmfront.dev;
>> +
>> +   if(count =3D=3D 0) {
>> +      return 0;
>> +   }
>> +
>> +   /* get the response if we haven't already */
>> +   if(files[dev->fd].tpmfront.respgot =3D=3D 0) {
>> +      if ((rc =3D tpmfront_recv(dev, &dummybuf, &dummysz)) !=3D 0) {
>> +     errno =3D EIO;
>> +     return -1;
>> +      }
>> +   }
>> +
>> +   /* handle EOF case */
>> +   if(files[dev->fd].tpmfront.offset >=3D dev->resplen) {
>> +      return 0;
>> +   }
>> +
>> +   /* Compute the number of bytes and do the copy operation */
>> +   if((rc =3D min(count, dev->resplen - files[dev->fd].tpmfront.offse=
t))
>> !=3D 0) {
>> +      memcpy(buf, dev->respbuf + files[dev->fd].tpmfront.offset, rc);=

>> +      files[dev->fd].tpmfront.offset +=3D rc;
>> +   }
>> +
>> +   return rc;
>> +}
>> +
>> +int tpmfront_posix_fstat(int fd, struct stat* buf)
>> +{
>> +   uint8_t* dummybuf;
>> +   size_t dummysz;
>> +   int rc;
>> +   struct tpmfront_dev* dev =3D files[fd].tpmfront.dev;
>> +
>> +   /* If we have a response waiting, then read it now from the backen=
d
>> +    * so we can get its length*/
>> +   if(dev->waiting || (files[dev->fd].read =3D=3D 1 &&
>> !files[dev->fd].tpmfront.respgot)) {
>> +      if ((rc =3D tpmfront_recv(dev, &dummybuf, &dummysz)) !=3D 0) {
>> +     errno =3D EIO;
>> +     return -1;
>> +      }
>> +   }
>> +
>> +   buf->st_mode =3D O_RDWR;
>> +   buf->st_uid =3D 0;
>> +   buf->st_gid =3D 0;
>> +   buf->st_size =3D dev->resplen;
>> +   buf->st_atime =3D buf->st_mtime =3D buf->st_ctime =3D time(NULL);
>> +
>> +   return 0;
>> +}
>> +
>> +
>> +#endif
>> --
>> 1.7.4.4
>>
>>
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xen.org
>> http://lists.xen.org/xen-devel
>>



--------------ms090403080908030504050400
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIDyjCC
A8YwggMvoAMCAQICBD/xyf0wDQYJKoZIhvcNAQEFBQAwLzELMAkGA1UEBhMCVVMxDzANBgNV
BAoTBkpIVUFQTDEPMA0GA1UECxMGQklTRENBMB4XDTEwMDYxMTE4MjIwNloXDTEzMDYxMTE4
NTIwNlowZjELMAkGA1UEBhMCVVMxDzANBgNVBAoTBkpIVUFQTDEPMA0GA1UECxMGUGVvcGxl
MTUwFgYDVQQLEw9WUE5Hcm91cC1CSVNEQ0EwGwYDVQQDExRNYXR0aGV3IEUgRmlvcmF2YW50
ZTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAnpbwVSP6o1Nb5lcW7dd3yTo9iBJdi7qz
4nANOMFPK7JOy5npKN1iiousl28U/scUJES55gPwAWYJK3uVyQAsA4adgDKi5DoD1UHDQEwp
bY7iHLJeq0NPr4BqYNqnCFPbE6HC8zSJrr4qKn+gVUQT39SIFqdiIPJwZL8FYTRQ/zsCAwEA
AaOCAbYwggGyMAsGA1UdDwQEAwIHgDArBgNVHRAEJDAigA8yMDEwMDYxMTE4MjIwNlqBDzIw
MTIwNzE3MjI1MjA2WjAbBg0rBgEEAbMlCwMBAQEBBAoWCGZpb3JhbWUxMBsGDSsGAQQBsyUL
AwEBAQIEChIIMDAxMDQyNjEwWAYJYIZIAYb6ax4BBEsMSVRoZSBwcml2YXRlIGtleSBjb3Jy
ZXNwb25kaW5nIHRvIHRoaXMgY2VydGlmaWNhdGUgbWF5IGhhdmUgYmVlbiBleHBvcnRlZC4w
KAYDVR0RBCEwH4EdTWF0dGhldy5GaW9yYXZhbnRlQGpodWFwbC5lZHUwUgYDVR0fBEswSTBH
oEWgQ6RBMD8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJU0RD
QTEOMAwGA1UEAxMFQ1JMNTYwHwYDVR0jBBgwFoAUCDUpmxH52EU2CyWmF2EJMB1yqeswHQYD
VR0OBBYEFO6LYxg6r9wHZ+zdQtBHn1dZ/YTNMAkGA1UdEwQCMAAwGQYJKoZIhvZ9B0EABAww
ChsEVjcuMQMCBLAwDQYJKoZIhvcNAQEFBQADgYEAJO9HQh4YNChVLzuZqK5ARJARD8JoujGZ
fdo75quvg2jXFQe2sEjvLnxJZgm/pv8fdZakq48CWwjYHKuvIp7sDjTEsQfo+y7SpN/N2NvJ
WU5SqfK1VgYtNLRRoGJUB5Q1aZ+Dg95g3kqpyfpUMISJL8IKVLtJVfN4fggFVUYZ9wwxggGr
MIIBpwIBATA3MC8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJ
U0RDQQIEP/HJ/TAJBgUrDgMCGgUAoIHLMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ
KoZIhvcNAQkFMQ8XDTEyMDkyNjE0Mjk1OFowIwYJKoZIhvcNAQkEMRYEFEcAzP5UnVPMuk+D
YwJMwsDYNzS0MGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAK
BggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI
KoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEgYAfBuN5r3MFy9ps+PxEWtNxfD9eymkuuk6B
74uumrrsob4qbEMW+ola9EMrfENRKhFKeVWl1AF8NPnGUzyHaJ4+Fa7MvrPmD3W/NYo7Cngp
9AQkPJNAWHPqSWXpWoBh4qnB4QxR+rUs+g4Dcp91jGKqBwEhatRbyChMq0n76gBysQAAAAAA
AA==
--------------ms090403080908030504050400--


--===============3681841939449735748==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============3681841939449735748==--


From xen-devel-bounces@lists.xen.org Wed Sep 26 14:32:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Sep 2012 14:32:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGseQ-0008IM-DY; Wed, 26 Sep 2012 14:31:46 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <matthew.fioravante@jhuapl.edu>) id 1TGseN-0008IB-VT
	for xen-devel@lists.xensource.com; Wed, 26 Sep 2012 14:31:44 +0000
Received: from [85.158.143.99:44566] by server-3.bemta-4.messagelabs.com id
	37/18-10986-FC113605; Wed, 26 Sep 2012 14:31:43 +0000
X-Env-Sender: matthew.fioravante@jhuapl.edu
X-Msg-Ref: server-7.tower-216.messagelabs.com!1348669896!25743595!1
X-Originating-IP: [128.244.251.36]
X-SpamReason: No, hits=0.0 required=7.0 tests=UNPARSEABLE_RELAY
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14349 invoked from network); 26 Sep 2012 14:31:37 -0000
Received: from pilot.jhuapl.edu (HELO jhuapl.edu) (128.244.251.36)
	by server-7.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 26 Sep 2012 14:31:37 -0000
Received: from ([128.244.207.89])
	by pilot.jhuapl.edu with ESMTP with TLS id 63GHCH1.153692445;
	Wed, 26 Sep 2012 10:31:17 -0400
Message-ID: <50631166.5010709@jhuapl.edu>
Date: Wed, 26 Sep 2012 10:29:58 -0400
From: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120827 Thunderbird/15.0
MIME-Version: 1.0
To: George Dunlap <George.Dunlap@eu.citrix.com>
References: <50579F53.4070302@jhuapl.edu>
	<CAFLBxZY+cCBXvT_F-M5b78cQ+Hp+xMeJeE5WGbP+igfWsiTy9w@mail.gmail.com>
In-Reply-To: <CAFLBxZY+cCBXvT_F-M5b78cQ+Hp+xMeJeE5WGbP+igfWsiTy9w@mail.gmail.com>
X-Enigmail-Version: 1.4.4
Cc: Samuel Thibault <samuel.thibault@ens-lyon.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH mini-os enhancements for vtpm 8/8] Add 3 tpm
 drivers to mini-os
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============3681841939449735748=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a cryptographically signed message in MIME format.

--===============3681841939449735748==
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms090403080908030504050400"

This is a cryptographically signed message in MIME format.

--------------ms090403080908030504050400
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On 09/26/2012 09:25 AM, George Dunlap wrote:
> On Mon, Sep 17, 2012 at 11:08 PM, Matthew Fioravante
> <matthew.fioravante@jhuapl.edu> wrote:
>> This patch adds 3 new drivers to mini-os.
>>
>> tpmfront - paravirtualized tpm frontend driver
>> tpmback - paravirtualized tpm backend driver
>> tpm_tis - hardware tpm driver
> Just trying to understand this -- tpmback is so that you can run a
> vtpm instance in the stubdom.  But what is tmpfront for?  Is that for
> running qemu stub domains?
>
>  -George
tpmfront and tpmback are like traditional frontend/backend
paravirtualized xen drivers. vtpm-stubdom uses tpmback to talk to the
linux guest. tpmfront and tpmback are also used by vtpm-stubdom and
vtpmmgrdom to communicate with one another.

The driver chain looks like this.

linux guest [tpm_xenu] -> [tpmback] vtpm-stubdom
[tpmfront]->[tpmback]vtpmmgrdom[tpm_tis]->TPM


>
>> Unfortunately these drivers were derived from GPL licensed linux kerne=
l
>> drivers so they must carry the GPL license. However, since mini-os now=

>> supports conditional compilation, hopefully these drivers can be
>> included into the xen tree and conditionally removed from non-gpl
>> projects. By default they are disabled in the makefile.
>>
>> Signed off by: Matthew Fioravante matthew.fioravante@jhuapl.edu
>>
>> diff --git a/extras/mini-os/Makefile b/extras/mini-os/Makefile
>> --- a/extras/mini-os/Makefile
>> +++ b/extras/mini-os/Makefile
>> @@ -22,6 +22,9 @@ CONFIG_QEMU_XS_ARGS ?=3D n
>>  CONFIG_TEST ?=3D n
>>  CONFIG_PCIFRONT ?=3D n
>>  CONFIG_BLKFRONT ?=3D y
>> +CONFIG_TPMFRONT ?=3D n
>> +CONFIG_TPM_TIS ?=3D n
>> +CONFIG_TPMBACK ?=3D n
>>  CONFIG_NETFRONT ?=3D y
>>  CONFIG_FBFRONT ?=3D y
>>  CONFIG_KBDFRONT ?=3D y
>> @@ -36,6 +39,9 @@ flags-$(CONFIG_SPARSE_BSS) +=3D -DCONFIG_SPARSE_BSS
>>  flags-$(CONFIG_QEMU_XS_ARGS) +=3D -DCONFIG_QEMU_XS_ARGS
>>  flags-$(CONFIG_PCIFRONT) +=3D -DCONFIG_PCIFRONT
>>  flags-$(CONFIG_BLKFRONT) +=3D -DCONFIG_BLKFRONT
>> +flags-$(CONFIG_TPMFRONT) +=3D -DCONFIG_TPMFRONT
>> +flags-$(CONFIG_TPM_TIS) +=3D -DCONFIG_TPM_TIS
>> +flags-$(CONFIG_TPMBACK) +=3D -DCONFIG_TPMBACK
>>  flags-$(CONFIG_NETFRONT) +=3D -DCONFIG_NETFRONT
>>  flags-$(CONFIG_KBDFRONT) +=3D -DCONFIG_KBDFRONT
>>  flags-$(CONFIG_FBFRONT) +=3D -DCONFIG_FBFRONT
>> @@ -67,6 +73,9 @@ TARGET :=3D mini-os
>>  SUBDIRS :=3D lib xenbus console
>>
>>  src-$(CONFIG_BLKFRONT) +=3D blkfront.c
>> +src-$(CONFIG_TPMFRONT) +=3D tpmfront.c
>> +src-$(CONFIG_TPM_TIS) +=3D tpm_tis.c
>> +src-$(CONFIG_TPMBACK) +=3D tpmback.c
>>  src-y +=3D daytime.c
>>  src-y +=3D events.c
>>  src-$(CONFIG_FBFRONT) +=3D fbfront.c
>> diff --git a/extras/mini-os/include/lib.h b/extras/mini-os/include/lib=
=2Eh
>> --- a/extras/mini-os/include/lib.h
>> +++ b/extras/mini-os/include/lib.h
>> @@ -142,6 +142,8 @@ enum fd_type {
>>      FTYPE_FB,
>>      FTYPE_MEM,
>>      FTYPE_SAVEFILE,
>> +    FTYPE_TPMFRONT,
>> +    FTYPE_TPM_TIS,
>>  };
>>
>>  LIST_HEAD(evtchn_port_list, evtchn_port_info);
>> @@ -185,6 +187,20 @@ extern struct file {
>>      struct {
>>          struct consfront_dev *dev;
>>      } cons;
>> +#ifdef CONFIG_TPMFRONT
>> +    struct {
>> +       struct tpmfront_dev *dev;
>> +       int respgot;
>> +       off_t offset;
>> +    } tpmfront;
>> +#endif
>> +#ifdef CONFIG_TPM_TIS
>> +    struct {
>> +       struct tpm_chip *dev;
>> +       int respgot;
>> +       off_t offset;
>> +    } tpm_tis;
>> +#endif
>>  #ifdef CONFIG_XENBUS
>>          struct {
>>              /* To each xenbus FD is associated a queue of watch event=
s
>> for this
>> diff --git a/extras/mini-os/include/tpm_tis.h
>> b/extras/mini-os/include/tpm_tis.h
>> --- /dev/null
>> +++ b/extras/mini-os/include/tpm_tis.h
>> @@ -0,0 +1,63 @@
>> +/*
>> + * Copyright (c) 2010-2012 United States Government, as represented b=
y
>> + * the Secretary of Defense.  All rights reserved.
>> + *
>> + * This driver is free software: you can redistribute it and/or modif=
y
>> + * it under the terms of the GNU General Public License as published =
by
>> + * the Free Software Foundation, either version 3 of the License, or
>> + * (at your option) any later version.
>> + *
>> + * This driver is distributed in the hope that it will be useful,
>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
>> + * GNU General Public License for more details.
>> + *
>> + * You should have received a copy of the GNU General Public License
>> + * along with this program.  If not, see <http://www.gnu.org/licenses=
/>.
>> + *
>> + * Based upon the files:
>> + *  drivers/char/tpm/tpm_tis.c
>> + *  drivers/char/tpm/tpm.c
>> + * from the Linux kernel, which are Copyright (C) 2006 IBM Corporatio=
n
>> + */
>> +#ifndef TPM_TIS_H
>> +#define TPM_TIS_H
>> +
>> +#include <mini-os/types.h>
>> +#include <mini-os/byteorder.h>
>> +
>> +#define TPM_TIS_EN_LOCL0 1
>> +#define TPM_TIS_EN_LOCL1 (1 << 1)
>> +#define TPM_TIS_EN_LOCL2 (1 << 2)
>> +#define TPM_TIS_EN_LOCL3 (1 << 3)
>> +#define TPM_TIS_EN_LOCL4 (1 << 4)
>> +#define TPM_TIS_EN_LOCLALL (TPM_TIS_EN_LOCL0 | TPM_TIS_EN_LOCL1  |
>> TPM_TIS_EN_LOCL2 | TPM_TIS_EN_LOCL3 | TPM_TIS_EN_LOCL4)
>> +#define TPM_TIS_LOCL_INT_TO_FLAG(x) (1 << x)
>> +#define TPM_BASEADDR 0xFED40000
>> +#define TPM_PROBE_IRQ 0xFFFF
>> +
>> +struct tpm_chip;
>> +
>> +struct tpm_chip* init_tpm_tis(unsigned long baseaddr, int localities,=

>> unsigned int irq);
>> +void shutdown_tpm_tis(struct tpm_chip* tpm);
>> +
>> +int tpm_tis_request_locality(struct tpm_chip* tpm, int locality);
>> +int tpm_tis_cmd(struct tpm_chip* tpm, uint8_t* req, size_t reqlen,
>> uint8_t** resp, size_t* resplen);
>> +
>> +#ifdef HAVE_LIBC
>> +#include <sys/stat.h>
>> +#include <fcntl.h>
>> +/* POSIX IO functions:
>> + * use tpm_tis_open() to get a file descriptor to the tpm device
>> + * use write() on the fd to send a command to the backend. You must
>> + * include the entire command in a single call to write().
>> + * use read() on the fd to read the response. You can use
>> + * fstat() to get the size of the response and lseek() to seek on it.=

>> + */
>> +int tpm_tis_open(struct tpm_chip* tpm);
>> +int tpm_tis_posix_read(int fd, uint8_t* buf, size_t count);
>> +int tpm_tis_posix_write(int fd, const uint8_t* buf, size_t count);
>> +int tpm_tis_posix_fstat(int fd, struct stat* buf);
>> +#endif
>> +
>> +#endif
>> diff --git a/extras/mini-os/include/tpmback.h
>> b/extras/mini-os/include/tpmback.h
>> --- /dev/null
>> +++ b/extras/mini-os/include/tpmback.h
>> @@ -0,0 +1,95 @@
>> +/*
>> + * Copyright (c) 2010-2012 United States Government, as represented b=
y
>> + * the Secretary of Defense.  All rights reserved.
>> + *
>> + * This driver is free software: you can redistribute it and/or modif=
y
>> + * it under the terms of the GNU General Public License as published =
by
>> + * the Free Software Foundation, either version 3 of the License, or
>> + * (at your option) any later version.
>> + *
>> + * This driver is distributed in the hope that it will be useful,
>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
>> + * GNU General Public License for more details.
>> + *
>> + * You should have received a copy of the GNU General Public License
>> + * along with this program.  If not, see <http://www.gnu.org/licenses=
/>.
>> + *
>> + * Based upon the files:
>> + *  drivers/xen/tpmbk.c
>> + * from the Linux kernel, which are Copyright (C) 2006 IBM Corporatio=
n
>> + */
>> +#include <xen/io/tpmif.h>
>> +#include <xen/io/xenbus.h>
>> +#include <mini-os/types.h>
>> +#include <xen/xen.h>
>> +#ifndef TPMBACK_H
>> +#define TPMBACK_H
>> +
>> +struct tpmcmd {
>> +   domid_t domid;        /* Domid of the frontend */
>> +   unsigned int handle;    /* Handle of the frontend */
>> +   char* uuid;            /* uuid of the tpm interface - allocated
>> internally, dont free it */
>> +
>> +   unsigned int req_len;        /* Size of the command in buf - set b=
y
>> tpmback driver */
>> +   uint8_t* req;            /* tpm command bits, allocated by driver,=

>> DON'T FREE IT */
>> +   unsigned int resp_len;    /* Size of the outgoing command,
>> +                   you set this before passing the cmd object to
>> tpmback_resp */
>> +   uint8_t* resp;        /* Buffer for response - YOU MUST ALLOCATE I=
T,
>> YOU MUST ALSO FREE IT */
>> +};
>> +typedef struct tpmcmd tpmcmd_t;
>> +
>> +/* Initialize the tpm backend driver
>> + * @exclusive_domname - This is NULL terminated list of vtpm uuid
>> strings. If this list
>> + *             is non-empty, then only frontend domains with vtpm
>> uuid's matching
>> + *             entries in this list will be allowed to connect.
>> + *             Other connections will be immediatly closed.
>> + *             Set this argument to NULL to allow any vtpm to connect=
=2E
>> + */
>> +void init_tpmback(char** exclusive_uuids);
>> +/* Shutdown tpm backend driver */
>> +void shutdown_tpmback(void);
>> +
>> +/* Blocks until a tpm command is sent from any front end.
>> + * Returns a pointer to the tpm command to handle.
>> + * Do not try to free this pointer or the req buffer
>> + * This function will return NULL if the tpm backend driver
>> + * is shutdown or any other error occurs */
>> +tpmcmd_t* tpmback_req_any(void);
>> +
>> +/* Blocks until a tpm command from the frontend at domid/handle
>> + * is sent.
>> + * Returns NULL if domid/handle is not connected, tpmback is
>> + * shutdown or shutting down, or if there is an error
>> + */
>> +tpmcmd_t* tpmback_req(domid_t domid, unsigned int handle);
>> +
>> +/* Send the response to the tpm command back to the frontend
>> + * This function will free the tpmcmd object, but you must free the r=
esp
>> + * buffer yourself */
>> +void tpmback_resp(tpmcmd_t* tpmcmd);
>> +
>> +/* Waits for the first frontend to connect and then sets domid and
>> handle appropriately.
>> + * If one or more frontends are already connected, this will set domi=
d
>> and handle to one
>> + * of them arbitrarily. The main use for this function is to wait unt=
il
>> a single
>> + * frontend connection has occured.
>> + * returns 0 on success, non-zero on failure */
>> +int tpmback_wait_for_frontend_connect(domid_t *domid, unsigned int
>> *handle);
>> +
>> +/* returns the number of frontends connected */
>> +int tpmback_num_frontends(void);
>> +
>> +/* Returns the uuid of the specified frontend, NULL on error */
>> +char* tpmback_get_uuid(domid_t domid, unsigned int handle);
>> +
>> +/* Specify a function to call when a new tpm device connects */
>> +void tpmback_set_open_callback(void (*cb)(domid_t, unsigned int));
>> +
>> +/* Specify a function to call when a tpm device disconnects */
>> +void tpmback_set_close_callback(void (*cb)(domid_t, unsigned int));
>> +
>> +//Not Implemented
>> +void tpmback_set_suspend_callback(void (*cb)(domid_t, unsigned int));=

>> +void tpmback_set_resume_callback(void (*cb)(domid_t, unsigned int));
>> +
>> +#endif
>> diff --git a/extras/mini-os/include/tpmfront.h
>> b/extras/mini-os/include/tpmfront.h
>> --- /dev/null
>> +++ b/extras/mini-os/include/tpmfront.h
>> @@ -0,0 +1,94 @@
>> +/*
>> + * Copyright (c) 2010-2012 United States Government, as represented b=
y
>> + * the Secretary of Defense.  All rights reserved.
>> + *
>> + * This driver is free software: you can redistribute it and/or modif=
y
>> + * it under the terms of the GNU General Public License as published =
by
>> + * the Free Software Foundation, either version 3 of the License, or
>> + * (at your option) any later version.
>> + *
>> + * This driver is distributed in the hope that it will be useful,
>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
>> + * GNU General Public License for more details.
>> + *
>> + * You should have received a copy of the GNU General Public License
>> + * along with this program.  If not, see <http://www.gnu.org/licenses=
/>.
>> + *
>> + * Based upon the files:
>> + *  drivers/char/tpm/tpm_vtpm.c
>> + *  drivers/char/tpm/tpm_xen.c
>> + * from the Linux kernel, which are Copyright (C) 2006 IBM Corporatio=
n
>> + */
>> +#ifndef TPMFRONT_H
>> +#define TPMFRONT_H
>> +
>> +#include <mini-os/types.h>
>> +#include <mini-os/os.h>
>> +#include <mini-os/events.h>
>> +#include <mini-os/wait.h>
>> +#include <xen/xen.h>
>> +#include <xen/io/xenbus.h>
>> +#include <xen/io/tpmif.h>
>> +
>> +struct tpmfront_dev {
>> +   grant_ref_t ring_ref;
>> +   evtchn_port_t evtchn;
>> +
>> +   tpmif_tx_interface_t* tx;
>> +
>> +   void** pages;
>> +
>> +   domid_t bedomid;
>> +   char* nodename;
>> +   char* bepath;
>> +
>> +   XenbusState state;
>> +
>> +   uint8_t waiting;
>> +   struct wait_queue_head waitq;
>> +
>> +   uint8_t* respbuf;
>> +   size_t resplen;
>> +
>> +#ifdef HAVE_LIBC
>> +   int fd;
>> +#endif
>> +
>> +};
>> +
>> +
>> +/*Initialize frontend */
>> +struct tpmfront_dev* init_tpmfront(const char* nodename);
>> +/*Shutdown frontend */
>> +void shutdown_tpmfront(struct tpmfront_dev* dev);
>> +
>> +/* Send a tpm command to the backend and wait for the response
>> + *
>> + * @dev - frontend device
>> + * @req - request buffer
>> + * @reqlen - length of request buffer
>> + * @resp - *resp will be set to internal response buffer, don't free
>> it! Value is undefined on error
>> + * @resplen - *resplen will be set to the length of the response. Val=
ue
>> is undefined on error
>> + *
>> + * returns 0 on success, non zero on failure.
>> + * */
>> +int tpmfront_cmd(struct tpmfront_dev* dev, uint8_t* req, size_t reqle=
n,
>> uint8_t** resp, size_t* resplen);
>> +
>> +#ifdef HAVE_LIBC
>> +#include <sys/stat.h>
>> +/* POSIX IO functions:
>> + * use tpmfront_open() to get a file descriptor to the tpm device
>> + * use write() on the fd to send a command to the backend. You must
>> + * include the entire command in a single call to write().
>> + * use read() on the fd to read the response. You can use
>> + * fstat() to get the size of the response and lseek() to seek on it.=

>> + */
>> +int tpmfront_open(struct tpmfront_dev* dev);
>> +int tpmfront_posix_read(int fd, uint8_t* buf, size_t count);
>> +int tpmfront_posix_write(int fd, const uint8_t* buf, size_t count);
>> +int tpmfront_posix_fstat(int fd, struct stat* buf);
>> +#endif
>> +
>> +
>> +#endif
>> diff --git a/extras/mini-os/lib/sys.c b/extras/mini-os/lib/sys.c
>> --- a/extras/mini-os/lib/sys.c
>> +++ b/extras/mini-os/lib/sys.c
>> @@ -27,6 +27,8 @@
>>  #include <netfront.h>
>>  #include <blkfront.h>
>>  #include <fbfront.h>
>> +#include <tpmfront.h>
>> +#include <tpm_tis.h>
>>  #include <xenbus.h>
>>  #include <xenstore.h>
>>
>> @@ -294,6 +296,16 @@ int read(int fd, void *buf, size_t nbytes)
>>          return blkfront_posix_read(fd, buf, nbytes);
>>          }
>>  #endif
>> +#ifdef CONFIG_TPMFRONT
>> +        case FTYPE_TPMFRONT: {
>> +        return tpmfront_posix_read(fd, buf, nbytes);
>> +        }
>> +#endif
>> +#ifdef CONFIG_TPM_TIS
>> +        case FTYPE_TPM_TIS: {
>> +        return tpm_tis_posix_read(fd, buf, nbytes);
>> +        }
>> +#endif
>>      default:
>>          break;
>>      }
>> @@ -330,6 +342,14 @@ int write(int fd, const void *buf, size_t nbytes)=

>>      case FTYPE_BLK:
>>          return blkfront_posix_write(fd, buf, nbytes);
>>  #endif
>> +#ifdef CONFIG_TPMFRONT
>> +    case FTYPE_TPMFRONT:
>> +        return tpmfront_posix_write(fd, buf, nbytes);
>> +#endif
>> +#ifdef CONFIG_TPM_TIS
>> +    case FTYPE_TPM_TIS:
>> +        return tpm_tis_posix_write(fd, buf, nbytes);
>> +#endif
>>      default:
>>          break;
>>      }
>> @@ -341,8 +361,16 @@ int write(int fd, const void *buf, size_t nbytes)=

>>  off_t lseek(int fd, off_t offset, int whence)
>>  {
>>      switch(files[fd].type) {
>> +#if defined(CONFIG_BLKFRONT) || defined(CONFIG_TPMFRONT) ||
>> defined(CONFIG_TPM_TIS)
>>  #ifdef CONFIG_BLKFRONT
>>         case FTYPE_BLK:
>> +#endif
>> +#ifdef CONFIG_TPMFRNT
>> +       case FTYPE_TPMFRONT:
>> +#endif
>> +#ifdef CONFIG_TPM_TIS
>> +       case FTYPE_TPM_TIS:
>> +#endif
>>        switch (whence) {
>>           case SEEK_SET:
>>          files[fd].file.offset =3D offset;
>> @@ -420,6 +448,18 @@ int close(int fd)
>>          files[fd].type =3D FTYPE_NONE;
>>          return 0;
>>  #endif
>> +#ifdef CONFIG_TPMFRONT
>> +    case FTYPE_TPMFRONT:
>> +            shutdown_tpmfront(files[fd].tpmfront.dev);
>> +        files[fd].type =3D FTYPE_NONE;
>> +        return 0;
>> +#endif
>> +#ifdef CONFIG_TPM_TIS
>> +    case FTYPE_TPM_TIS:
>> +            shutdown_tpm_tis(files[fd].tpm_tis.dev);
>> +        files[fd].type =3D FTYPE_NONE;
>> +        return 0;
>> +#endif
>>  #ifdef CONFIG_KBDFRONT
>>      case FTYPE_KBD:
>>              shutdown_kbdfront(files[fd].kbd.dev);
>> @@ -489,6 +529,14 @@ int fstat(int fd, struct stat *buf)
>>      case FTYPE_BLK:
>>         return blkfront_posix_fstat(fd, buf);
>>  #endif
>> +#ifdef CONFIG_TPMFRONT
>> +    case FTYPE_TPMFRONT:
>> +       return tpmfront_posix_fstat(fd, buf);
>> +#endif
>> +#ifdef CONFIG_TPM_TIS
>> +    case FTYPE_TPM_TIS:
>> +       return tpm_tis_posix_fstat(fd, buf);
>> +#endif
>>      default:
>>          break;
>>      }
>> diff --git a/extras/mini-os/tpm_tis.c b/extras/mini-os/tpm_tis.c
>> --- /dev/null
>> +++ b/extras/mini-os/tpm_tis.c
>> @@ -0,0 +1,1344 @@
>> +/*
>> + * Copyright (c) 2010-2012 United States Government, as represented b=
y
>> + * the Secretary of Defense.  All rights reserved.
>> + *
>> + * This driver is free software: you can redistribute it and/or modif=
y
>> + * it under the terms of the GNU General Public License as published =
by
>> + * the Free Software Foundation, either version 3 of the License, or
>> + * (at your option) any later version.
>> + *
>> + * This driver is distributed in the hope that it will be useful,
>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
>> + * GNU General Public License for more details.
>> + *
>> + * You should have received a copy of the GNU General Public License
>> + * along with this program.  If not, see <http://www.gnu.org/licenses=
/>.
>> + *
>> + * Based upon the files:
>> + *  drivers/char/tpm/tpm_tis.c
>> + *  drivers/char/tpm/tpm.c
>> + * from the Linux kernel, which are Copyright (C) 2006 IBM Corporatio=
n
>> + */
>> +#include <mini-os/ioremap.h>
>> +#include <mini-os/iorw.h>
>> +#include <mini-os/tpm_tis.h>
>> +#include <mini-os/os.h>
>> +#include <mini-os/sched.h>
>> +#include <mini-os/byteorder.h>
>> +#include <mini-os/events.h>
>> +#include <mini-os/wait.h>
>> +#include <mini-os/xmalloc.h>
>> +#include <errno.h>
>> +#include <stdbool.h>
>> +
>> +#ifndef min
>> +    #define min( a, b ) ( ((a) < (b)) ? (a) : (b) )
>> +#endif
>> +
>> +#define TPM_HEADER_SIZE 10
>> +
>> +#define TPM_BUFSIZE 2048
>> +
>> +struct tpm_input_header {
>> +        uint16_t  tag;
>> +        uint32_t  length;
>> +        uint32_t  ordinal;
>> +}__attribute__((packed));
>> +
>> +struct tpm_output_header {
>> +        uint16_t  tag;
>> +        uint32_t  length;
>> +        uint32_t  return_code;
>> +}__attribute__((packed));
>> +
>> +struct  stclear_flags_t {
>> +        uint16_t  tag;
>> +        uint8_t      deactivated;
>> +        uint8_t      disableForceClear;
>> +        uint8_t      physicalPresence;
>> +        uint8_t      physicalPresenceLock;
>> +        uint8_t      bGlobalLock;
>> +}__attribute__((packed));
>> +
>> +struct  tpm_version_t {
>> +        uint8_t      Major;
>> +        uint8_t      Minor;
>> +        uint8_t      revMajor;
>> +        uint8_t      revMinor;
>> +}__attribute__((packed));
>> +
>> +struct  tpm_version_1_2_t {
>> +        uint16_t  tag;
>> +        uint8_t      Major;
>> +        uint8_t      Minor;
>> +        uint8_t      revMajor;
>> +        uint8_t      revMinor;
>> +}__attribute__((packed));
>> +
>> +struct  timeout_t {
>> +        uint32_t  a;
>> +        uint32_t  b;
>> +        uint32_t  c;
>> +        uint32_t  d;
>> +}__attribute__((packed));
>> +
>> +struct duration_t {
>> +        uint32_t  tpm_short;
>> +        uint32_t  tpm_medium;
>> +        uint32_t  tpm_long;
>> +}__attribute__((packed));
>> +
>> +struct permanent_flags_t {
>> +        uint16_t  tag;
>> +        uint8_t      disable;
>> +        uint8_t      ownership;
>> +        uint8_t      deactivated;
>> +        uint8_t      readPubek;
>> +        uint8_t      disableOwnerClear;
>> +        uint8_t      allowMaintenance;
>> +        uint8_t      physicalPresenceLifetimeLock;
>> +        uint8_t      physicalPresenceHWEnable;
>> +        uint8_t      physicalPresenceCMDEnable;
>> +        uint8_t      CEKPUsed;
>> +        uint8_t      TPMpost;
>> +        uint8_t      TPMpostLock;
>> +        uint8_t      FIPS;
>> +        uint8_t      operator;
>> +        uint8_t      enableRevokeEK;
>> +        uint8_t      nvLocked;
>> +        uint8_t      readSRKPub;
>> +        uint8_t      tpmEstablished;
>> +        uint8_t      maintenanceDone;
>> +        uint8_t      disableFullDALogicInfo;
>> +}__attribute__((packed));
>> +
>> +typedef union {
>> +        struct  permanent_flags_t perm_flags;
>> +        struct  stclear_flags_t stclear_flags;
>> +        bool    owned;
>> +        uint32_t  num_pcrs;
>> +        struct  tpm_version_t   tpm_version;
>> +        struct  tpm_version_1_2_t tpm_version_1_2;
>> +        uint32_t  manufacturer_id;
>> +        struct timeout_t  timeout;
>> +        struct duration_t duration;
>> +} cap_t;
>> +
>> +struct  tpm_getcap_params_in {
>> +        uint32_t  cap;
>> +        uint32_t  subcap_size;
>> +        uint32_t  subcap;
>> +}__attribute__((packed));
>> +
>> +struct  tpm_getcap_params_out {
>> +        uint32_t  cap_size;
>> +        cap_t   cap;
>> +}__attribute__((packed));
>> +
>> +struct  tpm_readpubek_params_out {
>> +        uint8_t      algorithm[4];
>> +        uint8_t      encscheme[2];
>> +        uint8_t      sigscheme[2];
>> +        uint32_t  paramsize;
>> +        uint8_t      parameters[12]; /*assuming RSA*/
>> +        uint32_t  keysize;
>> +        uint8_t      modulus[256];
>> +        uint8_t      checksum[20];
>> +}__attribute__((packed));
>> +
>> +typedef union {
>> +        struct  tpm_input_header in;
>> +        struct  tpm_output_header out;
>> +} tpm_cmd_header;
>> +
>> +#define TPM_DIGEST_SIZE 20
>> +struct tpm_pcrread_out {
>> +        uint8_t      pcr_result[TPM_DIGEST_SIZE];
>> +}__attribute__((packed));
>> +
>> +struct tpm_pcrread_in {
>> +        uint32_t  pcr_idx;
>> +}__attribute__((packed));
>> +
>> +struct tpm_pcrextend_in {
>> +        uint32_t  pcr_idx;
>> +        uint8_t      hash[TPM_DIGEST_SIZE];
>> +}__attribute__((packed));
>> +
>> +typedef union {
>> +        struct  tpm_getcap_params_out getcap_out;
>> +        struct  tpm_readpubek_params_out readpubek_out;
>> +        uint8_t      readpubek_out_buffer[sizeof(struct
>> tpm_readpubek_params_out)];
>> +        struct  tpm_getcap_params_in getcap_in;
>> +        struct  tpm_pcrread_in  pcrread_in;
>> +        struct  tpm_pcrread_out pcrread_out;
>> +        struct  tpm_pcrextend_in pcrextend_in;
>> +} tpm_cmd_params;
>> +
>> +struct tpm_cmd_t {
>> +        tpm_cmd_header  header;
>> +        tpm_cmd_params  params;
>> +}__attribute__((packed));
>> +
>> +
>> +enum tpm_duration {
>> +   TPM_SHORT =3D 0,
>> +   TPM_MEDIUM =3D 1,
>> +   TPM_LONG =3D 2,
>> +   TPM_UNDEFINED,
>> +};
>> +
>> +#define TPM_MAX_ORDINAL 243
>> +#define TPM_MAX_PROTECTED_ORDINAL 12
>> +#define TPM_PROTECTED_ORDINAL_MASK 0xFF
>> +
>> +extern const uint8_t
>> tpm_protected_ordinal_duration[TPM_MAX_PROTECTED_ORDINAL];
>> +extern const uint8_t tpm_ordinal_duration[TPM_MAX_ORDINAL];
>> +
>> +#define TPM_DIGEST_SIZE 20
>> +#define TPM_ERROR_SIZE 10
>> +#define TPM_RET_CODE_IDX 6
>> +
>> +/* tpm_capabilities */
>> +#define TPM_CAP_FLAG cpu_to_be32(4)
>> +#define TPM_CAP_PROP cpu_to_be32(5)
>> +#define CAP_VERSION_1_1 cpu_to_be32(0x06)
>> +#define CAP_VERSION_1_2 cpu_to_be32(0x1A)
>> +
>> +/* tpm_sub_capabilities */
>> +#define TPM_CAP_PROP_PCR cpu_to_be32(0x101)
>> +#define TPM_CAP_PROP_MANUFACTURER cpu_to_be32(0x103)
>> +#define TPM_CAP_FLAG_PERM cpu_to_be32(0x108)
>> +#define TPM_CAP_FLAG_VOL cpu_to_be32(0x109)
>> +#define TPM_CAP_PROP_OWNER cpu_to_be32(0x111)
>> +#define TPM_CAP_PROP_TIS_TIMEOUT cpu_to_be32(0x115)
>> +#define TPM_CAP_PROP_TIS_DURATION cpu_to_be32(0x120)
>> +
>> +
>> +#define TPM_INTERNAL_RESULT_SIZE 200
>> +#define TPM_TAG_RQU_COMMAND cpu_to_be16(193)
>> +#define TPM_ORD_GET_CAP cpu_to_be32(101)
>> +
>> +extern const struct tpm_input_header tpm_getcap_header;
>> +
>> +
>> +
>> +const uint8_t tpm_protected_ordinal_duration[TPM_MAX_PROTECTED_ORDINA=
L] =3D {
>> +   TPM_UNDEFINED,          /* 0 */
>> +   TPM_UNDEFINED,
>> +   TPM_UNDEFINED,
>> +   TPM_UNDEFINED,
>> +   TPM_UNDEFINED,
>> +   TPM_UNDEFINED,          /* 5 */
>> +   TPM_UNDEFINED,
>> +   TPM_UNDEFINED,
>> +   TPM_UNDEFINED,
>> +   TPM_UNDEFINED,
>> +   TPM_SHORT,              /* 10 */
>> +   TPM_SHORT,
>> +};
>> +
>> +const uint8_t tpm_ordinal_duration[TPM_MAX_ORDINAL] =3D {
>> +   TPM_UNDEFINED,          /* 0 */
>> +   TPM_UNDEFINED,
>> +   TPM_UNDEFINED,
>> +   TPM_UNDEFINED,
>> +   TPM_UNDEFINED,
>> +   TPM_UNDEFINED,          /* 5 */
>> +   TPM_UNDEFINED,
>> +   TPM_UNDEFINED,
>> +   TPM_UNDEFINED,
>> +   TPM_UNDEFINED,
>> +   TPM_SHORT,              /* 10 */
>> +   TPM_SHORT,
>> +   TPM_MEDIUM,
>> +   TPM_LONG,
>> +   TPM_LONG,
>> +   TPM_MEDIUM,             /* 15 */
>> +   TPM_SHORT,
>> +   TPM_SHORT,
>> +   TPM_MEDIUM,
>> +   TPM_LONG,
>> +   TPM_SHORT,              /* 20 */
>> +   TPM_SHORT,
>> +   TPM_MEDIUM,
>> +   TPM_MEDIUM,
>> +   TPM_MEDIUM,
>> +   TPM_SHORT,              /* 25 */
>> +   TPM_SHORT,
>> +   TPM_MEDIUM,
>> +   TPM_SHORT,
>> +   TPM_SHORT,
>> +   TPM_MEDIUM,             /* 30 */
>> +   TPM_LONG,
>> +   TPM_MEDIUM,
>> +   TPM_SHORT,
>> +   TPM_SHORT,
>> +   TPM_SHORT,              /* 35 */
>> +   TPM_MEDIUM,
>> +   TPM_MEDIUM,
>> +   TPM_UNDEFINED,
>> +   TPM_UNDEFINED,
>> +   TPM_MEDIUM,             /* 40 */
>> +   TPM_LONG,
>> +   TPM_MEDIUM,
>> +   TPM_SHORT,
>> +   TPM_SHORT,
>> +   TPM_SHORT,              /* 45 */
>> +   TPM_SHORT,
>> +   TPM_SHORT,
>> +   TPM_SHORT,
>> +   TPM_LONG,
>> +   TPM_MEDIUM,             /* 50 */
>> +   TPM_MEDIUM,
>> +   TPM_UNDEFINED,
>> +   TPM_UNDEFINED,
>> +   TPM_UNDEFINED,
>> +   TPM_UNDEFINED,          /* 55 */
>> +   TPM_UNDEFINED,
>> +   TPM_UNDEFINED,
>> +   TPM_UNDEFINED,
>> +   TPM_UNDEFINED,
>> +   TPM_MEDIUM,             /* 60 */
>> +   TPM_MEDIUM,
>> +   TPM_MEDIUM,
>> +   TPM_SHORT,
>> +   TPM_SHORT,
>> +   TPM_MEDIUM,             /* 65 */
>> +   TPM_UNDEFINED,
>> +   TPM_UNDEFINED,
>> +   TPM_UNDEFINED,
>> +   TPM_UNDEFINED,
>> +   TPM_SHORT,              /* 70 */
>> +   TPM_SHORT,
>> +   TPM_UNDEFINED,
>> +   TPM_UNDEFINED,
>> +   TPM_UNDEFINED,
>> +   TPM_UNDEFINED,          /* 75 */
>> +   TPM_UNDEFINED,
>> +   TPM_UNDEFINED,
>> +   TPM_UNDEFINED,
>> +   TPM_UNDEFINED,
>> +   TPM_LONG,               /* 80 */
>> +   TPM_UNDEFINED,
>> +   TPM_MEDIUM,
>> +   TPM_LONG,
>> +   TPM_SHORT,
>> +   TPM_UNDEFINED,          /* 85 */
>> +   TPM_UNDEFINED,
>> +   TPM_UNDEFINED,
>> +   TPM_UNDEFINED,
>> +   TPM_UNDEFINED,
>> +   TPM_SHORT,              /* 90 */
>> +   TPM_SHORT,
>> +   TPM_SHORT,
>> +   TPM_SHORT,
>> +   TPM_SHORT,
>> +   TPM_UNDEFINED,          /* 95 */
>> +   TPM_UNDEFINED,
>> +   TPM_UNDEFINED,
>> +   TPM_UNDEFINED,
>> +   TPM_UNDEFINED,
>> +   TPM_MEDIUM,             /* 100 */
>> +   TPM_SHORT,
>> +   TPM_SHORT,
>> +   TPM_UNDEFINED,
>> +   TPM_UNDEFINED,
>> +   TPM_UNDEFINED,          /* 105 */
>> +   TPM_UNDEFINED,
>> +   TPM_UNDEFINED,
>> +   TPM_UNDEFINED,
>> +   TPM_UNDEFINED,
>> +   TPM_SHORT,              /* 110 */
>> +   TPM_SHORT,
>> +   TPM_SHORT,
>> +   TPM_SHORT,
>> +   TPM_SHORT,
>> +   TPM_SHORT,              /* 115 */
>> +   TPM_SHORT,
>> +   TPM_SHORT,
>> +   TPM_UNDEFINED,
>> +   TPM_UNDEFINED,
>> +   TPM_LONG,               /* 120 */
>> +   TPM_LONG,
>> +   TPM_MEDIUM,
>> +   TPM_UNDEFINED,
>> +   TPM_SHORT,
>> +   TPM_SHORT,              /* 125 */
>> +   TPM_SHORT,
>> +   TPM_LONG,
>> +   TPM_SHORT,
>> +   TPM_SHORT,
>> +   TPM_SHORT,              /* 130 */
>> +   TPM_MEDIUM,
>> +   TPM_UNDEFINED,
>> +   TPM_SHORT,
>> +   TPM_MEDIUM,
>> +   TPM_UNDEFINED,          /* 135 */
>> +   TPM_UNDEFINED,
>> +   TPM_UNDEFINED,
>> +   TPM_UNDEFINED,
>> +   TPM_UNDEFINED,
>> +   TPM_SHORT,              /* 140 */
>> +   TPM_SHORT,
>> +   TPM_UNDEFINED,
>> +   TPM_UNDEFINED,
>> +   TPM_UNDEFINED,
>> +   TPM_UNDEFINED,          /* 145 */
>> +   TPM_UNDEFINED,
>> +   TPM_UNDEFINED,
>> +   TPM_UNDEFINED,
>> +   TPM_UNDEFINED,
>> +   TPM_SHORT,              /* 150 */
>> +   TPM_MEDIUM,
>> +   TPM_MEDIUM,
>> +   TPM_SHORT,
>> +   TPM_SHORT,
>> +   TPM_UNDEFINED,          /* 155 */
>> +   TPM_UNDEFINED,
>> +   TPM_UNDEFINED,
>> +   TPM_UNDEFINED,
>> +   TPM_UNDEFINED,
>> +   TPM_SHORT,              /* 160 */
>> +   TPM_SHORT,
>> +   TPM_SHORT,
>> +   TPM_SHORT,
>> +   TPM_UNDEFINED,
>> +   TPM_UNDEFINED,          /* 165 */
>> +   TPM_UNDEFINED,
>> +   TPM_UNDEFINED,
>> +   TPM_UNDEFINED,
>> +   TPM_UNDEFINED,
>> +   TPM_LONG,               /* 170 */
>> +   TPM_UNDEFINED,
>> +   TPM_UNDEFINED,
>> +   TPM_UNDEFINED,
>> +   TPM_UNDEFINED,
>> +   TPM_UNDEFINED,          /* 175 */
>> +   TPM_UNDEFINED,
>> +   TPM_UNDEFINED,
>> +   TPM_UNDEFINED,
>> +   TPM_UNDEFINED,
>> +   TPM_MEDIUM,             /* 180 */
>> +   TPM_SHORT,
>> +   TPM_MEDIUM,
>> +   TPM_MEDIUM,
>> +   TPM_MEDIUM,
>> +   TPM_MEDIUM,             /* 185 */
>> +   TPM_SHORT,
>> +   TPM_UNDEFINED,
>> +   TPM_UNDEFINED,
>> +   TPM_UNDEFINED,
>> +   TPM_UNDEFINED,          /* 190 */
>> +   TPM_UNDEFINED,
>> +   TPM_UNDEFINED,
>> +   TPM_UNDEFINED,
>> +   TPM_UNDEFINED,
>> +   TPM_UNDEFINED,          /* 195 */
>> +   TPM_UNDEFINED,
>> +   TPM_UNDEFINED,
>> +   TPM_UNDEFINED,
>> +   TPM_UNDEFINED,
>> +   TPM_SHORT,              /* 200 */
>> +   TPM_UNDEFINED,
>> +   TPM_UNDEFINED,
>> +   TPM_UNDEFINED,
>> +   TPM_SHORT,
>> +   TPM_SHORT,              /* 205 */
>> +   TPM_SHORT,
>> +   TPM_SHORT,
>> +   TPM_SHORT,
>> +   TPM_SHORT,
>> +   TPM_MEDIUM,             /* 210 */
>> +   TPM_UNDEFINED,
>> +   TPM_MEDIUM,
>> +   TPM_MEDIUM,
>> +   TPM_MEDIUM,
>> +   TPM_UNDEFINED,          /* 215 */
>> +   TPM_MEDIUM,
>> +   TPM_UNDEFINED,
>> +   TPM_UNDEFINED,
>> +   TPM_SHORT,
>> +   TPM_SHORT,              /* 220 */
>> +   TPM_SHORT,
>> +   TPM_SHORT,
>> +   TPM_SHORT,
>> +   TPM_SHORT,
>> +   TPM_UNDEFINED,          /* 225 */
>> +   TPM_UNDEFINED,
>> +   TPM_UNDEFINED,
>> +   TPM_UNDEFINED,
>> +   TPM_UNDEFINED,
>> +   TPM_SHORT,              /* 230 */
>> +   TPM_LONG,
>> +   TPM_MEDIUM,
>> +   TPM_UNDEFINED,
>> +   TPM_UNDEFINED,
>> +   TPM_UNDEFINED,          /* 235 */
>> +   TPM_UNDEFINED,
>> +   TPM_UNDEFINED,
>> +   TPM_UNDEFINED,
>> +   TPM_UNDEFINED,
>> +   TPM_SHORT,              /* 240 */
>> +   TPM_UNDEFINED,
>> +   TPM_MEDIUM,
>> +};
>> +
>> +const struct tpm_input_header tpm_getcap_header =3D {
>> +        .tag =3D TPM_TAG_RQU_COMMAND,
>> +        .length =3D cpu_to_be32(22),
>> +        .ordinal =3D TPM_ORD_GET_CAP
>> +};
>> +
>> +
>> +enum tis_access {
>> +   TPM_ACCESS_VALID =3D 0x80,
>> +   TPM_ACCESS_ACTIVE_LOCALITY =3D 0x20,    /* (R) */
>> +   TPM_ACCESS_RELINQUISH_LOCALITY =3D 0x20,/* (W) */
>> +   TPM_ACCESS_REQUEST_PENDING =3D 0x04,    /* (W) */
>> +   TPM_ACCESS_REQUEST_USE =3D 0x02,    /* (W) */
>> +};
>> +
>> +enum tis_status {
>> +   TPM_STS_VALID =3D 0x80,        /* (R) */
>> +   TPM_STS_COMMAND_READY =3D 0x40,    /* (R) */
>> +   TPM_STS_DATA_AVAIL =3D 0x10,        /* (R) */
>> +   TPM_STS_DATA_EXPECT =3D 0x08,        /* (R) */
>> +   TPM_STS_GO =3D 0x20,            /* (W) */
>> +};
>> +
>> +enum tis_int_flags {
>> +   TPM_GLOBAL_INT_ENABLE =3D 0x80000000,
>> +   TPM_INTF_BURST_COUNT_STATIC =3D 0x100,
>> +   TPM_INTF_CMD_READY_INT =3D 0x080,
>> +   TPM_INTF_INT_EDGE_FALLING =3D 0x040,
>> +   TPM_INTF_INT_EDGE_RISING =3D 0x020,
>> +   TPM_INTF_INT_LEVEL_LOW =3D 0x010,
>> +   TPM_INTF_INT_LEVEL_HIGH =3D 0x008,
>> +   TPM_INTF_LOCALITY_CHANGE_INT =3D 0x004,
>> +   TPM_INTF_STS_VALID_INT =3D 0x002,
>> +   TPM_INTF_DATA_AVAIL_INT =3D 0x001,
>> +};
>> +
>> +enum tis_defaults {
>> +   TIS_MEM_BASE =3D 0xFED40000,
>> +   TIS_MEM_LEN  =3D 0x5000,
>> +   TIS_SHORT_TIMEOUT =3D 750, /*ms*/
>> +   TIS_LONG_TIMEOUT =3D 2000, /*2 sec */
>> +};
>> +
>> +#define TPM_TIMEOUT 5
>> +
>> +#define TPM_ACCESS(t, l)                   (((uint8_t*)t->pages[l]) +=

>> 0x0000)
>> +#define TPM_INT_ENABLE(t, l)
>> ((uint32_t*)(((uint8_t*)t->pages[l]) + 0x0008))
>> +#define TPM_INT_VECTOR(t, l)               (((uint8_t*)t->pages[l]) +=

>> 0x000C)
>> +#define TPM_INT_STATUS(t, l)               (((uint8_t*)t->pages[l]) +=

>> 0x0010)
>> +#define TPM_INTF_CAPS(t, l)
>> ((uint32_t*)(((uint8_t*)t->pages[l]) + 0x0014))
>> +#define TPM_STS(t, l)
>> ((uint8_t*)(((uint8_t*)t->pages[l]) + 0x0018))
>> +#define TPM_DATA_FIFO(t, l)                (((uint8_t*)t->pages[l]) +=

>> 0x0024)
>> +
>> +#define TPM_DID_VID(t, l)
>> ((uint32_t*)(((uint8_t*)t->pages[l]) + 0x0F00))
>> +#define TPM_RID(t, l)                      (((uint8_t*)t->pages[l]) +=

>> 0x0F04)
>> +
>> +struct tpm_chip {
>> +   int enabled_localities;
>> +   int locality;
>> +   unsigned long baseaddr;
>> +   uint8_t* pages[5];
>> +   int did, vid, rid;
>> +
>> +   uint8_t data_buffer[TPM_BUFSIZE];
>> +   int data_len;
>> +
>> +   s_time_t timeout_a, timeout_b, timeout_c, timeout_d;
>> +   s_time_t duration[3];
>> +
>> +#ifdef HAVE_LIBC
>> +   int fd;
>> +#endif
>> +
>> +   unsigned int irq;
>> +   struct wait_queue_head read_queue;
>> +   struct wait_queue_head int_queue;
>> +};
>> +
>> +
>> +static void __init_tpm_chip(struct tpm_chip* tpm) {
>> +   tpm->enabled_localities =3D TPM_TIS_EN_LOCLALL;
>> +   tpm->locality =3D -1;
>> +   tpm->baseaddr =3D 0;
>> +   tpm->pages[0] =3D tpm->pages[1] =3D tpm->pages[2] =3D tpm->pages[3=
] =3D
>> tpm->pages[4] =3D NULL;
>> +   tpm->vid =3D 0;
>> +   tpm->did =3D 0;
>> +   tpm->irq =3D 0;
>> +   init_waitqueue_head(&tpm->read_queue);
>> +   init_waitqueue_head(&tpm->int_queue);
>> +
>> +   tpm->data_len =3D -1;
>> +
>> +#ifdef HAVE_LIBC
>> +   tpm->fd =3D -1;
>> +#endif
>> +}
>> +
>> +/*
>> + * Returns max number of nsecs to wait
>> + */
>> +s_time_t tpm_calc_ordinal_duration(struct tpm_chip *chip,
>> +      uint32_t ordinal)
>> +{
>> +   int duration_idx =3D TPM_UNDEFINED;
>> +   s_time_t duration =3D 0;
>> +
>> +   if (ordinal < TPM_MAX_ORDINAL)
>> +      duration_idx =3D tpm_ordinal_duration[ordinal];
>> +   else if ((ordinal & TPM_PROTECTED_ORDINAL_MASK) <
>> +     TPM_MAX_PROTECTED_ORDINAL)
>> +      duration_idx =3D
>> +     tpm_protected_ordinal_duration[ordinal &
>> +     TPM_PROTECTED_ORDINAL_MASK];
>> +
>> +   if (duration_idx !=3D TPM_UNDEFINED) {
>> +      duration =3D chip->duration[duration_idx];
>> +   }
>> +
>> +   if (duration <=3D 0) {
>> +      return SECONDS(120);
>> +   }
>> +   else
>> +   {
>> +      return duration;
>> +   }
>> +}
>> +
>> +
>> +static int locality_enabled(struct tpm_chip* tpm, int l) {
>> +   return tpm->enabled_localities & (1 << l);
>> +}
>> +
>> +static int check_locality(struct tpm_chip* tpm, int l) {
>> +   if(locality_enabled(tpm, l) && (ioread8(TPM_ACCESS(tpm, l)) &
>> +        (TPM_ACCESS_ACTIVE_LOCALITY | TPM_ACCESS_VALID)) =3D=3D
>> +     (TPM_ACCESS_ACTIVE_LOCALITY | TPM_ACCESS_VALID)) {
>> +      return l;
>> +   }
>> +   return -1;
>> +}
>> +
>> +void release_locality(struct tpm_chip* tpm, int l, int force)
>> +{
>> +   if (locality_enabled(tpm, l) && (force || (ioread8(TPM_ACCESS(tpm,=
 l)) &
>> +           (TPM_ACCESS_REQUEST_PENDING | TPM_ACCESS_VALID)) =3D=3D
>> +        (TPM_ACCESS_REQUEST_PENDING | TPM_ACCESS_VALID))) {
>> +      iowrite8(TPM_ACCESS(tpm, l), TPM_ACCESS_RELINQUISH_LOCALITY);
>> +   }
>> +}
>> +
>> +int tpm_tis_request_locality(struct tpm_chip* tpm, int l) {
>> +
>> +   s_time_t stop;
>> +   /*Make sure locality is valid */
>> +   if(!locality_enabled(tpm, l)) {
>> +      printk("tpm_tis_change_locality() Tried to change to locality %=
d,
>> but it is disabled or invalid!\n", l);
>> +      return -1;
>> +   }
>> +   /* Check if we already have the current locality */
>> +   if(check_locality(tpm, l) >=3D 0) {
>> +      return tpm->locality =3D l;
>> +   }
>> +   /* Set the new locality*/
>> +   iowrite8(TPM_ACCESS(tpm, l), TPM_ACCESS_REQUEST_USE);
>> +
>> +   if(tpm->irq) {
>> +      /* Wait for interrupt */
>> +      wait_event_deadline(tpm->int_queue, (check_locality(tpm, l) >=3D=

>> 0), NOW() + tpm->timeout_a);
>> +
>> +      /* FIXME: Handle timeout event, should return error in that cas=
e */
>> +      return l;
>> +   } else {
>> +      /* Wait for burstcount */
>> +      stop =3D NOW() + tpm->timeout_a;
>> +      do {
>> +     if(check_locality(tpm, l) >=3D 0) {
>> +        return tpm->locality =3D l;
>> +     }
>> +     msleep(TPM_TIMEOUT);
>> +      } while(NOW() < stop);
>> +   }
>> +
>> +   printk("REQ LOCALITY FAILURE\n");
>> +   return -1;
>> +}
>> +
>> +static uint8_t tpm_tis_status(struct tpm_chip* tpm) {
>> +   return ioread8(TPM_STS(tpm, tpm->locality));
>> +}
>> +
>> +/* This causes the current command to be aborted */
>> +static void tpm_tis_ready(struct tpm_chip* tpm) {
>> +   iowrite8(TPM_STS(tpm, tpm->locality), TPM_STS_COMMAND_READY);
>> +}
>> +#define tpm_tis_cancel_cmd(v) tpm_tis_ready(v)
>> +
>> +static int get_burstcount(struct tpm_chip* tpm) {
>> +   s_time_t stop;
>> +   int burstcnt;
>> +
>> +   stop =3D NOW() + tpm->timeout_d;
>> +   do {
>> +      burstcnt =3D ioread8((TPM_STS(tpm, tpm->locality) + 1));
>> +      burstcnt +=3D ioread8(TPM_STS(tpm, tpm->locality) + 2) << 8;
>> +
>> +      if (burstcnt) {
>> +     return burstcnt;
>> +      }
>> +      msleep(TPM_TIMEOUT);
>> +   } while(NOW() < stop);
>> +   return -EBUSY;
>> +}
>> +
>> +static int wait_for_stat(struct tpm_chip* tpm, uint8_t mask,
>> +      unsigned long timeout, struct wait_queue_head* queue) {
>> +   s_time_t stop;
>> +   uint8_t status;
>> +
>> +   status =3D tpm_tis_status(tpm);
>> +   if((status & mask) =3D=3D mask) {
>> +      return 0;
>> +   }
>> +
>> +   if(tpm->irq) {
>> +      wait_event_deadline(*queue, ((tpm_tis_status(tpm) & mask) =3D=3D=

>> mask), timeout);
>> +      /* FIXME: Check for timeout and return -ETIME */
>> +      return 0;
>> +   } else {
>> +      stop =3D NOW() + timeout;
>> +      do {
>> +     msleep(TPM_TIMEOUT);
>> +     status =3D tpm_tis_status(tpm);
>> +     if((status & mask) =3D=3D mask)
>> +        return 0;
>> +      } while( NOW() < stop);
>> +   }
>> +   return -ETIME;
>> +}
>> +
>> +static int recv_data(struct tpm_chip* tpm, uint8_t* buf, size_t count=
) {
>> +   int size =3D 0;
>> +   int burstcnt;
>> +   while( size < count &&
>> +     wait_for_stat(tpm,
>> +        TPM_STS_DATA_AVAIL | TPM_STS_VALID,
>> +        tpm->timeout_c,
>> +        &tpm->read_queue)
>> +     =3D=3D 0) {
>> +      burstcnt =3D get_burstcount(tpm);
>> +      for(; burstcnt > 0 && size < count; --burstcnt)
>> +      {
>> +     buf[size++] =3D ioread8(TPM_DATA_FIFO(tpm, tpm->locality));
>> +      }
>> +   }
>> +   return size;
>> +}
>> +
>> +int tpm_tis_recv(struct tpm_chip* tpm, uint8_t* buf, size_t count) {
>> +   int size =3D 0;
>> +   int expected, status;
>> +
>> +   if (count < TPM_HEADER_SIZE) {
>> +      size =3D -EIO;
>> +      goto out;
>> +   }
>> +
>> +   /* read first 10 bytes, including tag, paramsize, and result */
>> +   if((size =3D
>> +        recv_data(tpm, buf, TPM_HEADER_SIZE)) < TPM_HEADER_SIZE) {
>> +      printk("Error reading tpm cmd header\n");
>> +      goto out;
>> +   }
>> +
>> +   expected =3D be32_to_cpu(*((uint32_t*)(buf + 2)));
>> +   if(expected > count) {
>> +      size =3D -EIO;
>> +      goto out;
>> +   }
>> +
>> +   if((size +=3D recv_data(tpm, & buf[TPM_HEADER_SIZE],
>> +           expected - TPM_HEADER_SIZE)) < expected) {
>> +      printk("Unable to read rest of tpm command size=3D%d
>> expected=3D%d\n", size, expected);
>> +      size =3D -ETIME;
>> +      goto out;
>> +   }
>> +
>> +   wait_for_stat(tpm, TPM_STS_VALID, tpm->timeout_c, &tpm->int_queue)=
;
>> +   status =3D tpm_tis_status(tpm);
>> +   if(status & TPM_STS_DATA_AVAIL) {
>> +      printk("Error: left over data\n");
>> +      size =3D -EIO;
>> +      goto out;
>> +   }
>> +
>> +out:
>> +   tpm_tis_ready(tpm);
>> +   release_locality(tpm, tpm->locality, 0);
>> +   return size;
>> +}
>> +int tpm_tis_send(struct tpm_chip* tpm, uint8_t* buf, size_t len) {
>> +   int rc;
>> +   int status, burstcnt =3D 0;
>> +   int count =3D 0;
>> +   uint32_t ordinal;
>> +
>> +   if(tpm_tis_request_locality(tpm, tpm->locality) < 0) {
>> +      return -EBUSY;
>> +   }
>> +
>> +   status =3D tpm_tis_status(tpm);
>> +   if((status & TPM_STS_COMMAND_READY) =3D=3D 0) {
>> +      tpm_tis_ready(tpm);
>> +      if(wait_for_stat(tpm, TPM_STS_COMMAND_READY, tpm->timeout_b,
>> &tpm->int_queue) < 0) {
>> +     rc =3D -ETIME;
>> +     goto out_err;
>> +      }
>> +   }
>> +
>> +   while(count < len - 1) {
>> +      burstcnt =3D get_burstcount(tpm);
>> +      for(;burstcnt > 0 && count < len -1; --burstcnt) {
>> +     iowrite8(TPM_DATA_FIFO(tpm, tpm->locality), buf[count++]);
>> +      }
>> +
>> +      wait_for_stat(tpm, TPM_STS_VALID, tpm->timeout_c, &tpm->int_que=
ue);
>> +      status =3D tpm_tis_status(tpm);
>> +      if((status & TPM_STS_DATA_EXPECT) =3D=3D 0) {
>> +     rc =3D -EIO;
>> +     goto out_err;
>> +      }
>> +   }
>> +
>> +   /*Write last byte*/
>> +   iowrite8(TPM_DATA_FIFO(tpm, tpm->locality), buf[count]);
>> +   wait_for_stat(tpm, TPM_STS_VALID, tpm->timeout_c, &tpm->read_queue=
);
>> +   status =3D tpm_tis_status(tpm);
>> +   if((status & TPM_STS_DATA_EXPECT) !=3D 0) {
>> +      rc =3D -EIO;
>> +      goto out_err;
>> +   }
>> +
>> +   /*go and do it*/
>> +   iowrite8(TPM_STS(tpm, tpm->locality), TPM_STS_GO);
>> +
>> +   if(tpm->irq) {
>> +      /*Wait for interrupt */
>> +      ordinal =3D be32_to_cpu(*(buf + 6));
>> +      if(wait_for_stat(tpm,
>> +           TPM_STS_DATA_AVAIL | TPM_STS_VALID,
>> +           tpm_calc_ordinal_duration(tpm, ordinal),
>> +           &tpm->read_queue) < 0) {
>> +     rc =3D -ETIME;
>> +     goto out_err;
>> +      }
>> +   }
>> +#ifdef HAVE_LIBC
>> +   if(tpm->fd >=3D 0) {
>> +      files[tpm->fd].read =3D 0;
>> +      files[tpm->fd].tpm_tis.respgot =3D 0;
>> +      files[tpm->fd].tpm_tis.offset =3D 0;
>> +   }
>> +#endif
>> +   return len;
>> +
>> +out_err:
>> +   tpm_tis_ready(tpm);
>> +   release_locality(tpm, tpm->locality, 0);
>> +   return rc;
>> +}
>> +
>> +static void tpm_tis_irq_handler(evtchn_port_t port, struct pt_regs
>> *regs, void* data)
>> +{
>> +   struct tpm_chip* tpm =3D data;
>> +   uint32_t interrupt;
>> +   int i;
>> +
>> +   interrupt =3D ioread32(TPM_INT_STATUS(tpm, tpm->locality));
>> +   if(interrupt =3D=3D 0) {
>> +      return;
>> +   }
>> +
>> +   if(interrupt & TPM_INTF_DATA_AVAIL_INT) {
>> +      wake_up(&tpm->read_queue);
>> +   }
>> +   if(interrupt & TPM_INTF_LOCALITY_CHANGE_INT) {
>> +      for(i =3D 0; i < 5; ++i) {
>> +     if(check_locality(tpm, i) >=3D 0) {
>> +        break;
>> +     }
>> +      }
>> +   }
>> +   if(interrupt & (TPM_INTF_LOCALITY_CHANGE_INT | TPM_INTF_STS_VALID_=
INT |
>> +        TPM_INTF_CMD_READY_INT)) {
>> +      wake_up(&tpm->int_queue);
>> +   }
>> +
>> +   /* Clear interrupts handled with TPM_EOI */
>> +   iowrite32(TPM_INT_STATUS(tpm, tpm->locality), interrupt);
>> +   ioread32(TPM_INT_STATUS(tpm, tpm->locality));
>> +   return;
>> +}
>> +
>> +/*
>> + * Internal kernel interface to transmit TPM commands
>> + */
>> +static ssize_t tpm_transmit(struct tpm_chip *chip, const uint8_t *buf=
,
>> +      size_t bufsiz)
>> +{
>> +   ssize_t rc;
>> +   uint32_t count, ordinal;
>> +   s_time_t stop;
>> +
>> +   count =3D be32_to_cpu(*((uint32_t *) (buf + 2)));
>> +   ordinal =3D be32_to_cpu(*((uint32_t *) (buf + 6)));
>> +   if (count =3D=3D 0)
>> +      return -ENODATA;
>> +   if (count > bufsiz) {
>> +      printk("Error: invalid count value %x %zx \n", count, bufsiz);
>> +      return -E2BIG;
>> +   }
>> +
>> +   //down(&chip->tpm_mutex);
>> +
>> +   if ((rc =3D tpm_tis_send(chip, (uint8_t *) buf, count)) < 0) {
>> +      printk("tpm_transmit: tpm_send: error %zd\n", rc);
>> +      goto out;
>> +   }
>> +
>> +   if (chip->irq)
>> +      goto out_recv;
>> +
>> +   stop =3D NOW() + tpm_calc_ordinal_duration(chip, ordinal);
>> +   do {
>> +      uint8_t status =3D tpm_tis_status(chip);
>> +      if ((status & (TPM_STS_DATA_AVAIL | TPM_STS_VALID)) =3D=3D
>> +        (TPM_STS_DATA_AVAIL | TPM_STS_VALID))
>> +     goto out_recv;
>> +
>> +      if ((status =3D=3D TPM_STS_COMMAND_READY)) {
>> +     printk("TPM Error: Operation Canceled\n");
>> +     rc =3D -ECANCELED;
>> +     goto out;
>> +      }
>> +
>> +      msleep(TPM_TIMEOUT);    /* CHECK */
>> +      rmb();
>> +   } while (NOW() < stop);
>> +
>> +   /* Cancel the command */
>> +   tpm_tis_cancel_cmd(chip);
>> +   printk("TPM Operation Timed out\n");
>> +   rc =3D -ETIME;
>> +   goto out;
>> +
>> +out_recv:
>> +   if((rc =3D tpm_tis_recv(chip, (uint8_t *) buf, bufsiz)) < 0) {
>> +      printk("tpm_transmit: tpm_recv: error %d\n", rc);
>> +   }
>> +out:
>> +   //up(&chip->tpm_mutex);
>> +   return rc;
>> +}
>> +
>> +static ssize_t transmit_cmd(struct tpm_chip *chip, struct tpm_cmd_t *=
cmd,
>> +                            int len, const char *desc)
>> +{
>> +        int err;
>> +
>> +        len =3D tpm_transmit(chip,(uint8_t *) cmd, len);
>> +        if (len <  0)
>> +                return len;
>> +        if (len =3D=3D TPM_ERROR_SIZE) {
>> +                err =3D be32_to_cpu(cmd->header.out.return_code);
>> +                printk("A TPM error (%d) occurred %s\n", err, desc);
>> +                return err;
>> +        }
>> +        return 0;
>> +}
>> +
>> +void tpm_get_timeouts(struct tpm_chip *chip)
>> +{
>> +   struct tpm_cmd_t tpm_cmd;
>> +   struct timeout_t *timeout_cap;
>> +   struct duration_t *duration_cap;
>> +   ssize_t rc;
>> +   uint32_t timeout;
>> +
>> +   tpm_cmd.header.in =3D tpm_getcap_header;
>> +   tpm_cmd.params.getcap_in.cap =3D TPM_CAP_PROP;
>> +   tpm_cmd.params.getcap_in.subcap_size =3D cpu_to_be32(4);
>> +   tpm_cmd.params.getcap_in.subcap =3D TPM_CAP_PROP_TIS_TIMEOUT;
>> +
>> +   if((rc =3D transmit_cmd(chip, &tpm_cmd, TPM_INTERNAL_RESULT_SIZE,
>> +     "attempting to determine the timeouts")) !=3D 0) {
>> +      printk("transmit failed %d\n", rc);
>> +      goto duration;
>> +   }
>> +
>> +   if (be32_to_cpu(tpm_cmd.params.getcap_out.cap_size)
>> +     !=3D 4 * sizeof(uint32_t)) {
>> +      printk("Out len check failure %lu \n",
>> be32_to_cpu(tpm_cmd.header.out.length));
>> +      goto duration;
>> +   }
>> +
>> +   timeout_cap =3D &tpm_cmd.params.getcap_out.cap.timeout;
>> +   /* Don't overwrite default if value is 0 */
>> +   timeout =3D be32_to_cpu(timeout_cap->a);
>> +   if (timeout)
>> +      chip->timeout_a =3D MICROSECS(timeout); /*Convert to msec */
>> +   timeout =3D be32_to_cpu(timeout_cap->b);
>> +   if (timeout)
>> +      chip->timeout_b =3D MICROSECS(timeout); /*Convert to msec */
>> +   timeout =3D be32_to_cpu(timeout_cap->c);
>> +   if (timeout)
>> +      chip->timeout_c =3D MICROSECS(timeout); /*Convert to msec */
>> +   timeout =3D be32_to_cpu(timeout_cap->d);
>> +   if (timeout)
>> +      chip->timeout_d =3D MICROSECS(timeout); /*Convert to msec */
>> +
>> +duration:
>> +   tpm_cmd.header.in =3D tpm_getcap_header;
>> +   tpm_cmd.params.getcap_in.cap =3D TPM_CAP_PROP;
>> +   tpm_cmd.params.getcap_in.subcap_size =3D cpu_to_be32(4);
>> +   tpm_cmd.params.getcap_in.subcap =3D TPM_CAP_PROP_TIS_DURATION;
>> +
>> +   if((rc =3D transmit_cmd(chip, &tpm_cmd, TPM_INTERNAL_RESULT_SIZE,
>> +     "attempting to determine the durations")) < 0) {
>> +      return;
>> +   }
>> +
>> +   if (be32_to_cpu(tpm_cmd.params.getcap_out.cap_size)
>> +     !=3D 3 * sizeof(uint32_t)) {
>> +      return;
>> +   }
>> +        duration_cap =3D &tpm_cmd.params.getcap_out.cap.duration;
>> +        chip->duration[TPM_SHORT] =3D be32_to_cpu(duration_cap->tpm_s=
hort);
>> +        /* The Broadcom BCM0102 chipset in a Dell Latitude D820 gets
>> the above
>> +         * value wrong and apparently reports msecs rather than usecs=
=2E
>> So we
>> +         * fix up the resulting too-small TPM_SHORT value to make
>> things work.
>> +         */
>> +        if (chip->duration[TPM_SHORT] < 10) {
>> +       chip->duration[TPM_SHORT] =3D MILLISECS(chip->duration[TPM_SHO=
RT]);
>> +    } else {
>> +       chip->duration[TPM_SHORT] =3D MICROSECS(chip->duration[TPM_SHO=
RT]);
>> +    }
>> +
>> +        chip->duration[TPM_MEDIUM] =3D
>> MICROSECS(be32_to_cpu(duration_cap->tpm_medium));
>> +        chip->duration[TPM_LONG] =3D
>> MICROSECS(be32_to_cpu(duration_cap->tpm_long));
>> +}
>> +
>> +
>> +
>> +void tpm_continue_selftest(struct tpm_chip* chip) {
>> +   uint8_t data[] =3D {
>> +      0, 193,                 /* TPM_TAG_RQU_COMMAND */
>> +      0, 0, 0, 10,            /* length */
>> +      0, 0, 0, 83,            /* TPM_ORD_GetCapability */
>> +   };
>> +
>> +   tpm_transmit(chip, data, sizeof(data));
>> +}
>> +
>> +ssize_t tpm_getcap(struct tpm_chip *chip, uint32_t subcap_id, cap_t *=
cap,
>> +                   const char *desc)
>> +{
>> +        struct tpm_cmd_t tpm_cmd;
>> +        int rc;
>> +
>> +        tpm_cmd.header.in =3D tpm_getcap_header;
>> +        if (subcap_id =3D=3D CAP_VERSION_1_1 || subcap_id =3D=3D CAP_=
VERSION_1_2) {
>> +                tpm_cmd.params.getcap_in.cap =3D subcap_id;
>> +                /*subcap field not necessary */
>> +                tpm_cmd.params.getcap_in.subcap_size =3D cpu_to_be32(=
0);
>> +                tpm_cmd.header.in.length -=3D cpu_to_be32(sizeof(uint=
32_t));
>> +        } else {
>> +                if (subcap_id =3D=3D TPM_CAP_FLAG_PERM ||
>> +                    subcap_id =3D=3D TPM_CAP_FLAG_VOL)
>> +                        tpm_cmd.params.getcap_in.cap =3D TPM_CAP_FLAG=
;
>> +                else
>> +                        tpm_cmd.params.getcap_in.cap =3D TPM_CAP_PROP=
;
>> +                tpm_cmd.params.getcap_in.subcap_size =3D cpu_to_be32(=
4);
>> +                tpm_cmd.params.getcap_in.subcap =3D subcap_id;
>> +        }
>> +        rc =3D transmit_cmd(chip, &tpm_cmd, TPM_INTERNAL_RESULT_SIZE,=
 desc);
>> +        if (!rc)
>> +                *cap =3D tpm_cmd.params.getcap_out.cap;
>> +        return rc;
>> +}
>> +
>> +
>> +struct tpm_chip* init_tpm_tis(unsigned long baseaddr, int localities,=

>> unsigned int irq)
>> +{
>> +   int i;
>> +   unsigned long addr;
>> +   struct tpm_chip* tpm =3D NULL;
>> +   uint32_t didvid;
>> +   uint32_t intfcaps;
>> +   uint32_t intmask;
>> +
>> +   printk("=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Init TPM TIS Drive=
r =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D\n");
>> +
>> +   /*Sanity check the localities input */
>> +   if(localities & ~TPM_TIS_EN_LOCLALL) {
>> +      printk("init_tpm_tis() Invalid locality specification! %X\n",
>> localities);
>> +      goto abort_egress;
>> +   }
>> +
>> +   printk("IOMEM Machine Base Address: %lX\n", baseaddr);
>> +
>> +   /* Create the tpm data structure */
>> +   tpm =3D malloc(sizeof(struct tpm_chip));
>> +   __init_tpm_chip(tpm);
>> +
>> +   /* Set the enabled localities - if 0 we leave default as all enabl=
ed */
>> +   if(localities !=3D 0) {
>> +      tpm->enabled_localities =3D localities;
>> +   }
>> +   printk("Enabled Localities: ");
>> +   for(i =3D 0; i < 5; ++i) {
>> +      if(locality_enabled(tpm, i)) {
>> +     printk("%d ", i);
>> +      }
>> +   }
>> +   printk("\n");
>> +
>> +   /* Set the base machine address */
>> +   tpm->baseaddr =3D baseaddr;
>> +
>> +   /* Set default timeouts */
>> +   tpm->timeout_a =3D MILLISECS(TIS_SHORT_TIMEOUT);
>> +   tpm->timeout_b =3D MILLISECS(TIS_LONG_TIMEOUT);
>> +   tpm->timeout_c =3D MILLISECS(TIS_SHORT_TIMEOUT);
>> +   tpm->timeout_d =3D MILLISECS(TIS_SHORT_TIMEOUT);
>> +
>> +   /*Map the mmio pages */
>> +   addr =3D tpm->baseaddr;
>> +   for(i =3D 0; i < 5; ++i) {
>> +      if(locality_enabled(tpm, i)) {
>> +     /* Map the page in now */
>> +     if((tpm->pages[i] =3D ioremap_nocache(addr, PAGE_SIZE)) =3D=3D N=
ULL) {
>> +        printk("Unable to map iomem page a address %p\n", addr);
>> +        goto abort_egress;
>> +     }
>> +
>> +     /* Set default locality to the first enabled one */
>> +     if (tpm->locality < 0) {
>> +        if(tpm_tis_request_locality(tpm, i) < 0) {
>> +           printk("Unable to request locality %d??\n", i);
>> +           goto abort_egress;
>> +        }
>> +     }
>> +      }
>> +      addr +=3D PAGE_SIZE;
>> +   }
>> +
>> +
>> +   /* Get the vendor and device ids */
>> +   didvid =3D ioread32(TPM_DID_VID(tpm, tpm->locality));
>> +   tpm->did =3D didvid >> 16;
>> +   tpm->vid =3D didvid & 0xFFFF;
>> +
>> +
>> +   /* Get the revision id */
>> +   tpm->rid =3D ioread8(TPM_RID(tpm, tpm->locality));
>> +
>> +   printk("1.2 TPM (device-id=3D0x%X vendor-id =3D %X rev-id =3D %X)\=
n",
>> tpm->did, tpm->vid, tpm->rid);
>> +
>> +   intfcaps =3D ioread32(TPM_INTF_CAPS(tpm, tpm->locality));
>> +   printk("TPM interface capabilities (0x%x):\n", intfcaps);
>> +   if (intfcaps & TPM_INTF_BURST_COUNT_STATIC)
>> +      printk("\tBurst Count Static\n");
>> +   if (intfcaps & TPM_INTF_CMD_READY_INT)
>> +      printk("\tCommand Ready Int Support\n");
>> +   if (intfcaps & TPM_INTF_INT_EDGE_FALLING)
>> +      printk("\tInterrupt Edge Falling\n");
>> +   if (intfcaps & TPM_INTF_INT_EDGE_RISING)
>> +      printk("\tInterrupt Edge Rising\n");
>> +   if (intfcaps & TPM_INTF_INT_LEVEL_LOW)
>> +      printk("\tInterrupt Level Low\n");
>> +   if (intfcaps & TPM_INTF_INT_LEVEL_HIGH)
>> +      printk("\tInterrupt Level High\n");
>> +   if (intfcaps & TPM_INTF_LOCALITY_CHANGE_INT)
>> +      printk("\tLocality Change Int Support\n");
>> +   if (intfcaps & TPM_INTF_STS_VALID_INT)
>> +      printk("\tSts Valid Int Support\n");
>> +   if (intfcaps & TPM_INTF_DATA_AVAIL_INT)
>> +      printk("\tData Avail Int Support\n");
>> +
>> +   /*Interupt setup */
>> +   intmask =3D ioread32(TPM_INT_ENABLE(tpm, tpm->locality));
>> +
>> +   intmask |=3D TPM_INTF_CMD_READY_INT
>> +      | TPM_INTF_LOCALITY_CHANGE_INT | TPM_INTF_DATA_AVAIL_INT
>> +      | TPM_INTF_STS_VALID_INT;
>> +
>> +   iowrite32(TPM_INT_ENABLE(tpm, tpm->locality), intmask);
>> +
>> +   /*If interupts are enabled, handle it */
>> +   if(irq) {
>> +      if(irq !=3D TPM_PROBE_IRQ) {
>> +     tpm->irq =3D irq;
>> +      } else {
>> +     /*FIXME add irq probing feature later */
>> +     printk("IRQ probing not implemented\n");
>> +      }
>> +   }
>> +
>> +   if(tpm->irq) {
>> +      iowrite8(TPM_INT_VECTOR(tpm, tpm->locality), tpm->irq);
>> +
>> +      if(bind_pirq(tpm->irq, 1, tpm_tis_irq_handler, tpm) !=3D 0) {
>> +     printk("Unabled to request irq: %u for use\n", tpm->irq);
>> +     printk("Will use polling mode\n");
>> +     tpm->irq =3D 0;
>> +      } else {
>> +     /* Clear all existing */
>> +     iowrite32(TPM_INT_STATUS(tpm, tpm->locality),
>> ioread32(TPM_INT_STATUS(tpm, tpm->locality)));
>> +
>> +     /* Turn on interrupts */
>> +     iowrite32(TPM_INT_ENABLE(tpm, tpm->locality), intmask |
>> TPM_GLOBAL_INT_ENABLE);
>> +      }
>> +   }
>> +
>> +   tpm_get_timeouts(tpm);
>> +   tpm_continue_selftest(tpm);
>> +
>> +
>> +   return tpm;
>> +abort_egress:
>> +   if(tpm !=3D NULL) {
>> +      shutdown_tpm_tis(tpm);
>> +   }
>> +   return NULL;
>> +}
>> +
>> +void shutdown_tpm_tis(struct tpm_chip* tpm){
>> +   int i;
>> +
>> +   printk("Shutting down tpm_tis device\n");
>> +
>> +   iowrite32(TPM_INT_ENABLE(tpm, tpm->locality), ~TPM_GLOBAL_INT_ENAB=
LE);
>> +
>> +   /*Unmap all of the mmio pages */
>> +   for(i =3D 0; i < 5; ++i) {
>> +      if(tpm->pages[i] !=3D NULL) {
>> +     iounmap(tpm->pages[i], PAGE_SIZE);
>> +     tpm->pages[i] =3D NULL;
>> +      }
>> +   }
>> +   free(tpm);
>> +   return;
>> +}
>> +
>> +
>> +int tpm_tis_cmd(struct tpm_chip* tpm, uint8_t* req, size_t reqlen,
>> uint8_t** resp, size_t* resplen)
>> +{
>> +   if(tpm->locality < 0) {
>> +      printk("tpm_tis_cmd() failed! locality not set!\n");
>> +      return -1;
>> +   }
>> +   if(reqlen > TPM_BUFSIZE) {
>> +      reqlen =3D TPM_BUFSIZE;
>> +   }
>> +   memcpy(tpm->data_buffer, req, reqlen);
>> +   *resplen =3D tpm_transmit(tpm, tpm->data_buffer, TPM_BUFSIZE);
>> +
>> +   *resp =3D malloc(*resplen);
>> +   memcpy(*resp, tpm->data_buffer, *resplen);
>> +   return 0;
>> +}
>> +
>> +#ifdef HAVE_LIBC
>> +int tpm_tis_open(struct tpm_chip* tpm)
>> +{
>> +   /* Silently prevent multiple opens */
>> +   if(tpm->fd !=3D -1) {
>> +      return tpm->fd;
>> +   }
>> +
>> +   tpm->fd =3D alloc_fd(FTYPE_TPM_TIS);
>> +   printk("tpm_tis_open() -> %d\n", tpm->fd);
>> +   files[tpm->fd].tpm_tis.dev =3D tpm;
>> +   files[tpm->fd].tpm_tis.offset =3D 0;
>> +   files[tpm->fd].tpm_tis.respgot =3D 0;
>> +   return tpm->fd;
>> +}
>> +
>> +int tpm_tis_posix_write(int fd, const uint8_t* buf, size_t count)
>> +{
>> +   struct tpm_chip* tpm;
>> +   tpm =3D files[fd].tpm_tis.dev;
>> +
>> +   if(tpm->locality < 0) {
>> +      printk("tpm_tis_posix_write() failed! locality not set!\n");
>> +      errno =3D EINPROGRESS;
>> +      return -1;
>> +   }
>> +   if(count =3D=3D 0) {
>> +      return 0;
>> +   }
>> +
>> +   /* Return an error if we are already processing a command */
>> +   if(count > TPM_BUFSIZE) {
>> +      count =3D TPM_BUFSIZE;
>> +   }
>> +   /* Send the command now */
>> +   memcpy(tpm->data_buffer, buf, count);
>> +   if((tpm->data_len =3D tpm_transmit(tpm, tpm->data_buffer,
>> TPM_BUFSIZE)) < 0) {
>> +      errno =3D EIO;
>> +      return -1;
>> +   }
>> +   return count;
>> +}
>> +
>> +int tpm_tis_posix_read(int fd, uint8_t* buf, size_t count)
>> +{
>> +   int rc;
>> +   struct tpm_chip* tpm;
>> +   tpm =3D files[fd].tpm_tis.dev;
>> +
>> +   if(count =3D=3D 0) {
>> +      return 0;
>> +   }
>> +
>> +   /* If there is no tpm resp to read, return EIO */
>> +   if(tpm->data_len < 0) {
>> +      errno =3D EIO;
>> +      return -1;
>> +   }
>> +
>> +
>> +   /* Handle EOF case */
>> +   if(files[fd].tpm_tis.offset >=3D tpm->data_len) {
>> +      rc =3D 0;
>> +   } else {
>> +      rc =3D min(tpm->data_len - files[fd].tpm_tis.offset, count);
>> +      memcpy(buf, tpm->data_buffer + files[fd].tpm_tis.offset, rc);
>> +   }
>> +   files[fd].tpm_tis.offset +=3D rc;
>> +   /* Reset the data pending flag */
>> +   return rc;
>> +}
>> +int tpm_tis_posix_fstat(int fd, struct stat* buf)
>> +{
>> +   struct tpm_chip* tpm;
>> +   tpm =3D files[fd].tpm_tis.dev;
>> +
>> +   buf->st_mode =3D O_RDWR;
>> +   buf->st_uid =3D 0;
>> +   buf->st_gid =3D 0;
>> +   buf->st_size =3D be32_to_cpu(*((uint32_t*)(tpm->data_buffer + 2)))=
;
>> +   buf->st_atime =3D buf->st_mtime =3D buf->st_ctime =3D time(NULL);
>> +   return 0;
>> +}
>> +
>> +
>> +#endif
>> diff --git a/extras/mini-os/tpmback.c b/extras/mini-os/tpmback.c
>> --- /dev/null
>> +++ b/extras/mini-os/tpmback.c
>> @@ -0,0 +1,1114 @@
>> +/*
>> + * Copyright (c) 2010-2012 United States Government, as represented b=
y
>> + * the Secretary of Defense.  All rights reserved.
>> + *
>> + * This driver is free software: you can redistribute it and/or modif=
y
>> + * it under the terms of the GNU General Public License as published =
by
>> + * the Free Software Foundation, either version 3 of the License, or
>> + * (at your option) any later version.
>> + *
>> + * This driver is distributed in the hope that it will be useful,
>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
>> + * GNU General Public License for more details.
>> + *
>> + * You should have received a copy of the GNU General Public License
>> + * along with this program.  If not, see <http://www.gnu.org/licenses=
/>.
>> + *
>> + * Based upon the files:
>> + *  drivers/xen/tpmbk.c
>> + * from the Linux kernel, which are Copyright (C) 2006 IBM Corporatio=
n
>> + */
>> +#include <mini-os/os.h>
>> +#include <mini-os/xenbus.h>
>> +#include <mini-os/events.h>
>> +#include <errno.h>
>> +#include <mini-os/gnttab.h>
>> +#include <xen/io/xenbus.h>
>> +#include <xen/io/tpmif.h>
>> +#include <xen/io/protocols.h>
>> +#include <mini-os/xmalloc.h>
>> +#include <time.h>
>> +#include <mini-os/tpmback.h>
>> +#include <mini-os/lib.h>
>> +#include <fcntl.h>
>> +#include <mini-os/mm.h>
>> +#include <mini-os/posix/sys/mman.h>
>> +#include <mini-os/semaphore.h>
>> +#include <mini-os/wait.h>
>> +
>> +
>> +#ifndef HAVE_LIBC
>> +#define strtoul simple_strtoul
>> +#endif
>> +
>> +//#define TPMBACK_PRINT_DEBUG
>> +#ifdef TPMBACK_PRINT_DEBUG
>> +#define TPMBACK_DEBUG(fmt,...) printk("Tpmback:Debug("__FILE__":%d) "=

>> fmt, __LINE__, ##__VA_ARGS__)
>> +#define TPMBACK_DEBUG_MORE(fmt,...) printk(fmt, ##__VA_ARGS__)
>> +#else
>> +#define TPMBACK_DEBUG(fmt,...)
>> +#endif
>> +#define TPMBACK_ERR(fmt,...) printk("Tpmback:Error " fmt, ##__VA_ARGS=
__)
>> +#define TPMBACK_LOG(fmt,...) printk("Tpmback:Info " fmt, ##__VA_ARGS_=
_)
>> +
>> +#define min(a,b) (((a) < (b)) ? (a) : (b))
>> +
>> +/* Default size of the tpmif array at initialization */
>> +#define DEF_ARRAY_SIZE 1
>> +
>> +/* tpmif and tpmdev flags */
>> +#define TPMIF_CLOSED 1
>> +#define TPMIF_REQ_READY 2
>> +
>> +struct tpmif {
>> +   domid_t domid;
>> +   unsigned int handle;
>> +
>> +   char* fe_path;
>> +   char* fe_state_path;
>> +
>> +   /* Locally bound event channel*/
>> +   evtchn_port_t evtchn;
>> +
>> +   /* Shared page */
>> +   tpmif_tx_interface_t* tx;
>> +
>> +   /* pointer to TPMIF_RX_RING_SIZE pages */
>> +   void** pages;
>> +
>> +   enum xenbus_state state;
>> +   enum { DISCONNECTED, DISCONNECTING, CONNECTED } status;
>> +
>> +   char* uuid;
>> +
>> +   /* state flags */
>> +   int flags;
>> +};
>> +typedef struct tpmif tpmif_t;
>> +
>> +struct tpmback_dev {
>> +
>> +   tpmif_t** tpmlist;
>> +   unsigned long num_tpms;
>> +   unsigned long num_alloc;
>> +
>> +   struct gntmap map;
>> +
>> +   /* True if at least one tpmif has a request to be handled */
>> +   int flags;
>> +
>> +   /* exclusive domains, see init_tpmback comment in tpmback.h */
>> +   char** exclusive_uuids;
>> +
>> +   xenbus_event_queue events;
>> +
>> +   /* Callbacks */
>> +   void (*open_callback)(domid_t, unsigned int);
>> +   void (*close_callback)(domid_t, unsigned int);
>> +   void (*suspend_callback)(domid_t, unsigned int);
>> +   void (*resume_callback)(domid_t, unsigned int);
>> +};
>> +typedef struct tpmback_dev tpmback_dev_t;
>> +
>> +enum { EV_NONE, EV_NEWFE, EV_STCHNG } tpm_ev_enum;
>> +
>> +/* Global objects */
>> +static struct thread* eventthread =3D NULL;
>> +static tpmback_dev_t gtpmdev =3D {
>> +   .tpmlist =3D NULL,
>> +   .num_tpms =3D 0,
>> +   .num_alloc =3D 0,
>> +   .flags =3D TPMIF_CLOSED,
>> +   .events =3D NULL,
>> +   .open_callback =3D NULL,
>> +   .close_callback =3D NULL,
>> +   .suspend_callback =3D NULL,
>> +   .resume_callback =3D NULL,
>> +};
>> +struct wait_queue_head waitq;
>> +int globalinit =3D 0;
>> +
>> +/************************************
>> + * TPMIF SORTED ARRAY FUNCTIONS
>> + * tpmback_dev_t.tpmlist is a sorted array, sorted by domid and then
>> handle number
>> + * Duplicates are not allowed
>> + * **********************************/
>> +
>> +inline void tpmif_req_ready(tpmif_t* tpmif) {
>> +   tpmif->flags |=3D TPMIF_REQ_READY;
>> +   gtpmdev.flags |=3D TPMIF_REQ_READY;
>> +}
>> +
>> +inline void tpmdev_check_req(void) {
>> +   int i;
>> +   int flags;
>> +   local_irq_save(flags);
>> +   for(i =3D 0; i < gtpmdev.num_tpms; ++i) {
>> +      if(gtpmdev.tpmlist[i]->flags & TPMIF_REQ_READY) {
>> +     gtpmdev.flags |=3D TPMIF_REQ_READY;
>> +     local_irq_restore(flags);
>> +     return;
>> +      }
>> +   }
>> +   gtpmdev.flags &=3D ~TPMIF_REQ_READY;
>> +   local_irq_restore(flags);
>> +}
>> +
>> +inline void tpmif_req_finished(tpmif_t* tpmif) {
>> +   tpmif->flags &=3D ~TPMIF_REQ_READY;
>> +   tpmdev_check_req();
>> +}
>> +
>> +int __get_tpmif_index(int st, int n, domid_t domid, unsigned int hand=
le)
>> +{
>> +   int i =3D st + n /2;
>> +   tpmif_t* tmp;
>> +
>> +   if( n <=3D 0 )
>> +      return -1;
>> +
>> +   tmp =3D gtpmdev.tpmlist[i];
>> +   if(domid =3D=3D tmp->domid && tmp->handle =3D=3D handle) {
>> +      return i;
>> +   } else if ( (domid < tmp->domid) ||
>> +     (domid =3D=3D tmp->domid && handle < tmp->handle)) {
>> +      return __get_tpmif_index(st, n/2, domid, handle);
>> +   } else {
>> +      return __get_tpmif_index(i + 1, n/2 - ((n +1) % 2), domid, hand=
le);
>> +   }
>> +}
>> +
>> +/* Returns the array index of the tpmif domid/handle. Returns -1 if n=
o
>> such tpmif exists */
>> +int get_tpmif_index(domid_t domid, unsigned int handle)
>> +{
>> +   int flags;
>> +   int index;
>> +   local_irq_save(flags);
>> +   index =3D __get_tpmif_index(0, gtpmdev.num_tpms, domid, handle);
>> +   local_irq_restore(flags);
>> +   return index;
>> +}
>> +
>> +/* Returns the tpmif domid/handle or NULL if none exists */
>> +tpmif_t* get_tpmif(domid_t domid, unsigned int handle)
>> +{
>> +   int flags;
>> +   int i;
>> +   tpmif_t* ret;
>> +   local_irq_save(flags);
>> +   i =3D get_tpmif_index(domid, handle);
>> +   if (i < 0) {
>> +      ret =3D NULL;
>> +   } else {
>> +      ret =3D gtpmdev.tpmlist[i];
>> +   }
>> +   local_irq_restore(flags);
>> +   return ret;
>> +}
>> +
>> +/* Remove the given tpmif. Returns 0 if it was removed, -1 if it was
>> not removed */
>> +int remove_tpmif(tpmif_t* tpmif)
>> +{
>> +   int i, j;
>> +   char* err;
>> +   int flags;
>> +   local_irq_save(flags);
>> +
>> +   /* Find the index in the array if it exists */
>> +   i =3D get_tpmif_index(tpmif->domid, tpmif->handle);
>> +   if (i < 0) {
>> +      goto error;
>> +   }
>> +
>> +   /* Remove the interface from the list */
>> +   for(j =3D i; j < gtpmdev.num_tpms - 1; ++j) {
>> +      gtpmdev.tpmlist[j] =3D gtpmdev.tpmlist[j+1];
>> +   }
>> +   gtpmdev.tpmlist[j] =3D NULL;
>> +   --gtpmdev.num_tpms;
>> +
>> +   /* If removed tpm was the only ready tpm, then we need to check an=
d
>> turn off the ready flag */
>> +   tpmdev_check_req();
>> +
>> +   local_irq_restore(flags);
>> +
>> +   /* Stop listening for events on this tpm interface */
>> +   if((err =3D xenbus_unwatch_path_token(XBT_NIL, tpmif->fe_state_pat=
h,
>> tpmif->fe_state_path))) {
>> +      TPMBACK_ERR("Unable to unwatch path token `%s' Error was %s
>> Ignoring..\n", tpmif->fe_state_path, err);
>> +      free(err);
>> +   }
>> +
>> +   return 0;
>> +error:
>> +   local_irq_restore(flags);
>> +   return -1;
>> +}
>> +
>> +/* Insert tpmif into dev->tpmlist. Returns 0 on success and non zero =
on
>> error.
>> + * It is an error to insert a tpmif with the same domid and handle
>> + * number
>> + * as something already in the list */
>> +int insert_tpmif(tpmif_t* tpmif)
>> +{
>> +   int flags;
>> +   unsigned int i, j;
>> +   tpmif_t* tmp;
>> +   char* err;
>> +
>> +   local_irq_save(flags);
>> +
>> +   /*Check if we need to allocate more space */
>> +   if (gtpmdev.num_tpms =3D=3D gtpmdev.num_alloc) {
>> +      gtpmdev.num_alloc *=3D 2;
>> +      gtpmdev.tpmlist =3D realloc(gtpmdev.tpmlist, gtpmdev.num_alloc)=
;
>> +   }
>> +
>> +   /*Find where to put the new interface */
>> +   for(i =3D 0; i < gtpmdev.num_tpms; ++i)
>> +   {
>> +      tmp =3D gtpmdev.tpmlist[i];
>> +      if(tpmif->domid =3D=3D tmp->domid && tpmif->handle =3D=3D tmp->=
handle) {
>> +     TPMBACK_ERR("Tried to insert duplicate tpm interface %u/%u\n",
>> (unsigned int) tpmif->domid, tpmif->handle);
>> +     goto error;
>> +      }
>> +      if((tpmif->domid < tmp->domid) ||
>> +        (tpmif->domid =3D=3D tmp->domid && tpmif->handle < tmp->handl=
e)) {
>> +     break;
>> +      }
>> +   }
>> +
>> +   /*Shift all the tpm pointers past i down one */
>> +   for(j =3D gtpmdev.num_tpms; j > i; --j) {
>> +      gtpmdev.tpmlist[j] =3D gtpmdev.tpmlist[j-1];
>> +   }
>> +
>> +   /*Add the new interface */
>> +   gtpmdev.tpmlist[i] =3D tpmif;
>> +   ++gtpmdev.num_tpms;
>> +
>> +   /*Should not be needed, anything inserted with ready flag is
>> probably an error */
>> +   tpmdev_check_req();
>> +
>> +   local_irq_restore(flags);
>> +
>> +   /*Listen for state changes on the new interface */
>> +   if((err =3D xenbus_watch_path_token(XBT_NIL, tpmif->fe_state_path,=

>> tpmif->fe_state_path, &gtpmdev.events)))
>> +   {
>> +      /* if we got an error here we should carefully remove the
>> interface and then return */
>> +      TPMBACK_ERR("Unable to watch path token `%s' Error was %s\n",
>> tpmif->fe_state_path, err);
>> +      free(err);
>> +      remove_tpmif(tpmif);
>> +      goto error_post_irq;
>> +   }
>> +
>> +   return 0;
>> +error:
>> +   local_irq_restore(flags);
>> +error_post_irq:
>> +   return -1;
>> +}
>> +
>> +
>> +/*****************
>> + * CHANGE BACKEND STATE
>> + * *****************/
>> +/*Attempts to change the backend state in xenstore
>> + * returns 0 on success and non-zero on error */
>> +int tpmif_change_state(tpmif_t* tpmif, enum xenbus_state state)
>> +{
>> +   char path[512];
>> +   char *value;
>> +   char *err;
>> +   enum xenbus_state readst;
>> +   TPMBACK_DEBUG("Backend state change %u/%u from=3D%d to=3D%d\n",
>> (unsigned int) tpmif->domid, tpmif->handle, tpmif->state, state);
>> +   if (tpmif->state =3D=3D state)
>> +      return 0;
>> +
>> +   snprintf(path, 512, "backend/vtpm/%u/%u/state", (unsigned int)
>> tpmif->domid, tpmif->handle);
>> +
>> +   if((err =3D xenbus_read(XBT_NIL, path, &value))) {
>> +      TPMBACK_ERR("Unable to read backend state %s, error was %s\n",
>> path, err);
>> +      free(err);
>> +      return -1;
>> +   }
>> +   if(sscanf(value, "%d", &readst) !=3D 1) {
>> +      TPMBACK_ERR("Non integer value (%s) in %s ??\n", value, path);
>> +      free(value);
>> +      return -1;
>> +   }
>> +   free(value);
>> +
>> +   /* It's possible that the backend state got updated by hotplug or
>> something else behind our back */
>> +   if(readst !=3D tpmif->state) {
>> +      TPMBACK_DEBUG("tpm interface state was %d but xenstore state wa=
s
>> %d!\n", tpmif->state, readst);
>> +      tpmif->state =3D readst;
>> +   }
>> +
>> +   /*If if the state isnt changing, then we dont update xenstore b/c =
we
>> dont want to fire extraneous events */
>> +   if(tpmif->state =3D=3D state) {
>> +      return 0;
>> +   }
>> +
>> +   /*update xenstore*/
>> +   snprintf(path, 512, "backend/vtpm/%u/%u", (unsigned int)
>> tpmif->domid, tpmif->handle);
>> +   if((err =3D xenbus_printf(XBT_NIL, path, "state", "%u", state))) {=

>> +      TPMBACK_ERR("Error writing to xenstore %s, error was %s new
>> state=3D%d\n", path, err, state);
>> +      free(err);
>> +      return -1;
>> +   }
>> +
>> +   tpmif->state =3D state;
>> +
>> +   return 0;
>> +}
>> +/**********************************
>> + * TPMIF CREATION AND DELETION
>> + * *******************************/
>> +inline tpmif_t* __init_tpmif(domid_t domid, unsigned int handle)
>> +{
>> +   tpmif_t* tpmif;
>> +   tpmif =3D malloc(sizeof(*tpmif));
>> +   tpmif->domid =3D domid;
>> +   tpmif->handle =3D handle;
>> +   tpmif->fe_path =3D NULL;
>> +   tpmif->fe_state_path =3D NULL;
>> +   tpmif->state =3D XenbusStateInitialising;
>> +   tpmif->status =3D DISCONNECTED;
>> +   tpmif->tx =3D NULL;
>> +   tpmif->pages =3D NULL;
>> +   tpmif->flags =3D 0;
>> +   tpmif->uuid =3D NULL;
>> +   return tpmif;
>> +}
>> +
>> +void __free_tpmif(tpmif_t* tpmif)
>> +{
>> +   if(tpmif->pages) {
>> +      free(tpmif->pages);
>> +   }
>> +   if(tpmif->fe_path) {
>> +      free(tpmif->fe_path);
>> +   }
>> +   if(tpmif->fe_state_path) {
>> +      free(tpmif->fe_state_path);
>> +   }
>> +   if(tpmif->uuid) {
>> +      free(tpmif->uuid);
>> +   }
>> +   free(tpmif);
>> +}
>> +/* Creates a new tpm interface, adds it to the sorted array and retur=
ns it.
>> + * returns NULL on error
>> + * If the tpm interface already exists, it is returned*/
>> +tpmif_t* new_tpmif(domid_t domid, unsigned int handle)
>> +{
>> +   tpmif_t* tpmif;
>> +   char* err;
>> +   char path[512];
>> +
>> +   /* Make sure we haven't already created this tpm
>> +    * Double events can occur */
>> +   if((tpmif =3D get_tpmif(domid, handle)) !=3D NULL) {
>> +      return tpmif;
>> +   }
>> +
>> +   tpmif =3D __init_tpmif(domid, handle);
>> +
>> +   /* Get the uuid from xenstore */
>> +   snprintf(path, 512, "backend/vtpm/%u/%u/uuid", (unsigned int) domi=
d,
>> handle);
>> +   if((err =3D xenbus_read(XBT_NIL, path, &tpmif->uuid))) {
>> +      TPMBACK_ERR("Error reading %s, Error =3D %s\n", path, err);
>> +      free(err);
>> +      goto error;
>> +   }
>> +
>> +   /* Do the exclusive uuid check now */
>> +   if(gtpmdev.exclusive_uuids !=3D NULL) {
>> +      char** ptr;
>> +
>> +      /* Check that its in the whitelist */
>> +      for(ptr =3D gtpmdev.exclusive_uuids; *ptr !=3D NULL; ++ptr) {
>> +     if(!strcmp(tpmif->uuid, *ptr)) {
>> +        break;
>> +     }
>> +      }
>> +      /* If *ptr =3D=3D NULL then we went through the whole list with=
out a
>> match, so close the connection */
>> +      if(*ptr =3D=3D NULL) {
>> +     tpmif_change_state(tpmif, XenbusStateClosed);
>> +     TPMBACK_ERR("Frontend %u/%u tried to connect with invalid
>> uuid=3D%s\n", (unsigned int) domid, handle, tpmif->uuid);
>> +     goto error;
>> +      }
>> +   }
>> +
>> +   /* allocate pages to be used for shared mapping */
>> +   if((tpmif->pages =3D malloc(sizeof(void*) * TPMIF_TX_RING_SIZE)) =3D=
=3D
>> NULL) {
>> +      goto error;
>> +   }
>> +   memset(tpmif->pages, 0, sizeof(void*) * TPMIF_TX_RING_SIZE);
>> +
>> +   if(tpmif_change_state(tpmif, XenbusStateInitWait)) {
>> +      goto error;
>> +   }
>> +
>> +   snprintf(path, 512, "backend/vtpm/%u/%u/frontend", (unsigned int)
>> domid, handle);
>> +   if((err =3D xenbus_read(XBT_NIL, path, &tpmif->fe_path))) {
>> +      TPMBACK_ERR("Error creating new tpm instance xenbus_read(%s),
>> Error =3D %s", path, err);
>> +      free(err);
>> +      goto error;
>> +   }
>> +
>> +   /*Set the state path */
>> +   tpmif->fe_state_path =3D malloc(strlen(tpmif->fe_path) + 7);
>> +   strcpy(tpmif->fe_state_path, tpmif->fe_path);
>> +   strcat(tpmif->fe_state_path, "/state");
>> +
>> +   if(insert_tpmif(tpmif)) {
>> +      goto error;
>> +   }
>> +   TPMBACK_DEBUG("New tpmif %u/%u\n", (unsigned int) tpmif->domid,
>> tpmif->handle);
>> +   /* Do the callback now */
>> +   if(gtpmdev.open_callback) {
>> +      gtpmdev.open_callback(tpmif->domid, tpmif->handle);
>> +   }
>> +   return tpmif;
>> +error:
>> +   __free_tpmif(tpmif);
>> +   return NULL;
>> +
>> +}
>> +
>> +/* Removes tpmif from dev->tpmlist and frees it's memory usage */
>> +void free_tpmif(tpmif_t* tpmif)
>> +{
>> +   char* err;
>> +   char path[512];
>> +   TPMBACK_DEBUG("Free tpmif %u/%u\n", (unsigned int) tpmif->domid,
>> tpmif->handle);
>> +   if(tpmif->flags & TPMIF_CLOSED) {
>> +      TPMBACK_ERR("Tried to free an instance twice! Theres a bug
>> somewhere!\n");
>> +      BUG();
>> +   }
>> +   tpmif->flags =3D TPMIF_CLOSED;
>> +
>> +   tpmif_change_state(tpmif, XenbusStateClosing);
>> +
>> +   /* Unmap share page and unbind event channel */
>> +   if(tpmif->status =3D=3D CONNECTED) {
>> +      tpmif->status =3D DISCONNECTING;
>> +      mask_evtchn(tpmif->evtchn);
>> +
>> +      if(gntmap_munmap(&gtpmdev.map, (unsigned long)tpmif->tx, 1)) {
>> +     TPMBACK_ERR("%u/%u Error occured while trying to unmap shared
>> page\n", (unsigned int) tpmif->domid, tpmif->handle);
>> +      }
>> +
>> +      unbind_evtchn(tpmif->evtchn);
>> +   }
>> +   tpmif->status =3D DISCONNECTED;
>> +   tpmif_change_state(tpmif, XenbusStateClosed);
>> +
>> +   /* Do the callback now */
>> +   if(gtpmdev.close_callback) {
>> +      gtpmdev.close_callback(tpmif->domid, tpmif->handle);
>> +   }
>> +
>> +   /* remove from array */
>> +   remove_tpmif(tpmif);
>> +
>> +   /* Wake up anyone possibly waiting on this interface and let them
>> exit */
>> +   wake_up(&waitq);
>> +   schedule();
>> +
>> +   /* Remove the old xenbus entries */
>> +   snprintf(path, 512, "backend/vtpm/%u/%u", (unsigned int)
>> tpmif->domid, tpmif->handle);
>> +   if((err =3D xenbus_rm(XBT_NIL, path))) {
>> +      TPMBACK_ERR("Error cleaning up xenbus entries path=3D%s
>> error=3D%s\n", path, err);
>> +      free(err);
>> +   }
>> +
>> +   TPMBACK_LOG("Frontend %u/%u disconnected\n", (unsigned int)
>> tpmif->domid, tpmif->handle);
>> +
>> +   /* free memory */
>> +   __free_tpmif(tpmif);
>> +
>> +}
>> +
>> +/**********************
>> + * REMAINING TPMBACK FUNCTIONS
>> + * ********************/
>> +
>> +/*Event channel handler */
>> +void tpmback_handler(evtchn_port_t port, struct pt_regs *regs, void *=
data)
>> +{
>> +   tpmif_t* tpmif =3D (tpmif_t*) data;
>> +   tpmif_tx_request_t* tx =3D &tpmif->tx->ring[0].req;
>> +   /* Throw away 0 size events, these can trigger from event channel
>> unmasking */
>> +   if(tx->size =3D=3D 0)
>> +      return;
>> +
>> +   TPMBACK_DEBUG("EVENT CHANNEL FIRE %u/%u\n", (unsigned int)
>> tpmif->domid, tpmif->handle);
>> +   tpmif_req_ready(tpmif);
>> +   wake_up(&waitq);
>> +
>> +}
>> +
>> +/* Connect to frontend */
>> +int connect_fe(tpmif_t* tpmif)
>> +{
>> +   char path[512];
>> +   char* err, *value;
>> +   uint32_t domid;
>> +   grant_ref_t ringref;
>> +   evtchn_port_t evtchn;
>> +
>> +   /* If already connected then quit */
>> +   if (tpmif->status =3D=3D CONNECTED) {
>> +      TPMBACK_DEBUG("%u/%u tried to connect while it was already
>> connected?\n", (unsigned int) tpmif->domid, tpmif->handle);
>> +      return 0;
>> +   }
>> +
>> +   /* Fetch the grant reference */
>> +   snprintf(path, 512, "%s/ring-ref", tpmif->fe_path);
>> +   if((err =3D xenbus_read(XBT_NIL, path, &value))) {
>> +      TPMBACK_ERR("Error creating new tpm instance xenbus_read(%s)
>> Error =3D %s", path, err);
>> +      free(err);
>> +      return -1;
>> +   }
>> +   if(sscanf(value, "%d", &ringref) !=3D 1) {
>> +      TPMBACK_ERR("Non integer value (%s) in %s ??\n", value, path);
>> +      free(value);
>> +      return -1;
>> +   }
>> +   free(value);
>> +
>> +
>> +   /* Fetch the event channel*/
>> +   snprintf(path, 512, "%s/event-channel", tpmif->fe_path);
>> +   if((err =3D xenbus_read(XBT_NIL, path, &value))) {
>> +      TPMBACK_ERR("Error creating new tpm instance xenbus_read(%s)
>> Error =3D %s", path, err);
>> +      free(err);
>> +      return -1;
>> +   }
>> +   if(sscanf(value, "%d", &evtchn) !=3D 1) {
>> +      TPMBACK_ERR("Non integer value (%s) in %s ??\n", value, path);
>> +      free(value);
>> +      return -1;
>> +   }
>> +   free(value);
>> +
>> +   domid =3D tpmif->domid;
>> +   if((tpmif->tx =3D gntmap_map_grant_refs(&gtpmdev.map, 1, &domid, 0=
,
>> &ringref, PROT_READ | PROT_WRITE)) =3D=3D NULL) {
>> +      TPMBACK_ERR("Failed to map grant reference %u/%u\n", (unsigned
>> int) tpmif->domid, tpmif->handle);
>> +      return -1;
>> +   }
>> +   memset(tpmif->tx, 0, PAGE_SIZE);
>> +
>> +   /*Bind the event channel */
>> +   if((evtchn_bind_interdomain(tpmif->domid, evtchn, tpmback_handler,=

>> tpmif, &tpmif->evtchn)))
>> +   {
>> +      TPMBACK_ERR("%u/%u Unable to bind to interdomain event
>> channel!\n", (unsigned int) tpmif->domid, tpmif->handle);
>> +      goto error_post_map;
>> +   }
>> +   unmask_evtchn(tpmif->evtchn);
>> +
>> +   /* Write the ready flag and change status to connected */
>> +   snprintf(path, 512, "backend/vtpm/%u/%u", (unsigned int)
>> tpmif->domid, tpmif->handle);
>> +   if((err =3D xenbus_printf(XBT_NIL, path, "ready", "%u", 1))) {
>> +      TPMBACK_ERR("%u/%u Unable to write ready flag on connect_fe()\n=
",
>> (unsigned int) tpmif->domid, tpmif->handle);
>> +      free(err);
>> +      goto error_post_evtchn;
>> +   }
>> +   tpmif->status =3D CONNECTED;
>> +   if((tpmif_change_state(tpmif, XenbusStateConnected))){
>> +      goto error_post_evtchn;
>> +   }
>> +
>> +   TPMBACK_LOG("Frontend %u/%u connected\n", (unsigned int)
>> tpmif->domid, tpmif->handle);
>> +
>> +   return 0;
>> +error_post_evtchn:
>> +   mask_evtchn(tpmif->evtchn);
>> +   unbind_evtchn(tpmif->evtchn);
>> +error_post_map:
>> +   gntmap_munmap(&gtpmdev.map, (unsigned long)tpmif->tx, 1);
>> +   return -1;
>> +}
>> +
>> +static int frontend_changed(tpmif_t* tpmif)
>> +{
>> +   int state =3D xenbus_read_integer(tpmif->fe_state_path);
>> +   if(state < 0) {
>> +      state =3D XenbusStateUnknown;
>> +   }
>> +
>> +   TPMBACK_DEBUG("Frontend %u/%u state changed to %d\n", (unsigned in=
t)
>> tpmif->domid, tpmif->handle, state);
>> +
>> +   switch (state) {
>> +      case XenbusStateInitialising:
>> +      case XenbusStateInitialised:
>> +     break;
>> +
>> +      case XenbusStateConnected:
>> +     if(connect_fe(tpmif)) {
>> +        TPMBACK_ERR("Failed to connect to front end %u/%u\n", (unsign=
ed
>> int) tpmif->domid, tpmif->handle);
>> +        tpmif_change_state(tpmif, XenbusStateClosed);
>> +        return -1;
>> +     }
>> +     break;
>> +
>> +      case XenbusStateClosing:
>> +     tpmif_change_state(tpmif, XenbusStateClosing);
>> +     break;
>> +
>> +      case XenbusStateUnknown: /* keep it here */
>> +      case XenbusStateClosed:
>> +     free_tpmif(tpmif);
>> +     break;
>> +
>> +      default:
>> +     TPMBACK_DEBUG("BAD STATE CHANGE %u/%u state =3D %d for tpmif\n",=

>> (unsigned int) tpmif->domid, tpmif->handle, state);
>> +     return -1;
>> +   }
>> +   return 0;
>> +}
>> +
>> +
>> +/* parses the string that comes out of xenbus_watch_wait_return. */
>> +static int parse_eventstr(const char* evstr, domid_t* domid, unsigned=

>> int* handle)
>> +{
>> +   int ret;
>> +   char cmd[40];
>> +   char* err;
>> +   char* value;
>> +   unsigned int udomid =3D 0;
>> +   tpmif_t* tpmif;
>> +   /* First check for new frontends, this occurs when
>> /backend/vtpm/<domid>/<handle> gets created. Note we what the sscanf t=
o
>> fail on the last %s */
>> +   if (sscanf(evstr, "backend/vtpm/%u/%u/%40s", &udomid, handle, cmd)=

>> =3D=3D 2) {
>> +      *domid =3D udomid;
>> +      /* Make sure the entry exists, if this event triggers because t=
he
>> entry dissapeared then ignore it */
>> +      if((err =3D xenbus_read(XBT_NIL, evstr, &value))) {
>> +     free(err);
>> +     return EV_NONE;
>> +      }
>> +      free(value);
>> +      /* Make sure the tpmif entry does not already exist, this shoul=
d
>> not happen */
>> +      if((tpmif =3D get_tpmif(*domid, *handle)) !=3D NULL) {
>> +     TPMBACK_DEBUG("Duplicate tpm entries! %u %u\n", tpmif->domid,
>> tpmif->handle);
>> +     return EV_NONE;
>> +      }
>> +      return EV_NEWFE;
>> +   } else if((ret =3D sscanf(evstr,
>> "/local/domain/%u/device/vtpm/%u/%40s", &udomid, handle, cmd)) =3D=3D =
3) {
>> +      *domid =3D udomid;
>> +      if (!strcmp(cmd, "state"))
>> +     return EV_STCHNG;
>> +   }
>> +   return EV_NONE;
>> +}
>> +
>> +void handle_backend_event(char* evstr) {
>> +   tpmif_t* tpmif;
>> +   domid_t domid;
>> +   unsigned int handle;
>> +   int event;
>> +
>> +   TPMBACK_DEBUG("Xenbus Event: %s\n", evstr);
>> +
>> +   event =3D parse_eventstr(evstr, &domid, &handle);
>> +
>> +   switch(event) {
>> +      case EV_NEWFE:
>> +     if(new_tpmif(domid, handle) =3D=3D NULL) {
>> +        TPMBACK_ERR("Failed to create new tpm instance %u/%u\n",
>> (unsigned int) domid, handle);
>> +     }
>> +     wake_up(&waitq);
>> +     break;
>> +      case EV_STCHNG:
>> +     if((tpmif =3D get_tpmif(domid, handle))) {
>> +        frontend_changed(tpmif);
>> +     } else {
>> +        TPMBACK_DEBUG("Event Received for non-existant tpm!
>> instance=3D%u/%u xenbus_event=3D%s\n", (unsigned int) domid, handle, e=
vstr);
>> +     }
>> +     break;
>> +   }
>> +}
>> +
>> +/* Runs through the given path and creates events recursively
>> + * for all of its children.
>> + * @path - xenstore path to scan */
>> +static void generate_backend_events(const char* path)
>> +{
>> +   char* err;
>> +   int i, len;
>> +   char **dirs;
>> +   char *entry;
>> +
>> +   if((err =3D xenbus_ls(XBT_NIL, path, &dirs)) !=3D NULL) {
>> +      free(err);
>> +      return;
>> +   }
>> +
>> +   for(i =3D 0; dirs[i] !=3D NULL; ++i) {
>> +      len =3D strlen(path) + strlen(dirs[i]) + 2;
>> +      entry =3D malloc(len);
>> +      snprintf(entry, len, "%s/%s", path, dirs[i]);
>> +
>> +      /* Generate and handle event for the entry itself */
>> +      handle_backend_event(entry);
>> +
>> +      /* Do children */
>> +      generate_backend_events(entry);
>> +
>> +      /* Cleanup */
>> +      free(entry);
>> +      free(dirs[i]);
>> +   }
>> +   free(dirs);
>> +   return;
>> +}
>> +
>> +char* tpmback_get_uuid(domid_t domid, unsigned int handle)
>> +{
>> +   tpmif_t* tpmif;
>> +   if((tpmif =3D get_tpmif(domid, handle)) =3D=3D NULL) {
>> +      TPMBACK_DEBUG("get_uuid() failed, %u/%u is an invalid
>> frontend\n", (unsigned int) domid, handle);
>> +      return NULL;
>> +   }
>> +
>> +   return tpmif->uuid;
>> +}
>> +
>> +void tpmback_set_open_callback(void (*cb)(domid_t, unsigned int))
>> +{
>> +   gtpmdev.open_callback =3D cb;
>> +}
>> +void tpmback_set_close_callback(void (*cb)(domid_t, unsigned int))
>> +{
>> +   gtpmdev.close_callback =3D cb;
>> +}
>> +void tpmback_set_suspend_callback(void (*cb)(domid_t, unsigned int))
>> +{
>> +   gtpmdev.suspend_callback =3D cb;
>> +}
>> +void tpmback_set_resume_callback(void (*cb)(domid_t, unsigned int))
>> +{
>> +   gtpmdev.resume_callback =3D cb;
>> +}
>> +
>> +static void event_listener(void)
>> +{
>> +   const char* bepath =3D "backend/vtpm";
>> +   char **path;
>> +   char* err;
>> +
>> +   /* Setup the backend device watch */
>> +   if((err =3D xenbus_watch_path_token(XBT_NIL, bepath, bepath,
>> &gtpmdev.events)) !=3D NULL) {
>> +      TPMBACK_ERR("xenbus_watch_path_token(%s) failed with error
>> %s!\n", bepath, err);
>> +      free(err);
>> +      goto egress;
>> +   }
>> +
>> +   /* Check for any frontends that connected before we set the watch.=

>> +    * This is almost guaranteed to happen if both domains are started=

>> +    * immediatly one after the other.
>> +    * We do this by manually generating events on everything in the b=
ackend
>> +    * path */
>> +   generate_backend_events(bepath);
>> +
>> +   /* Wait and listen for changes in frontend connections */
>> +   while(1) {
>> +      path =3D xenbus_wait_for_watch_return(&gtpmdev.events);
>> +
>> +      /*If quit flag was set then exit */
>> +      if(gtpmdev.flags & TPMIF_CLOSED) {
>> +     TPMBACK_DEBUG("listener thread got quit event. Exiting..\n");
>> +     free(path);
>> +     break;
>> +      }
>> +      handle_backend_event(*path);
>> +      free(path);
>> +
>> +   }
>> +
>> +   if((err =3D xenbus_unwatch_path_token(XBT_NIL, bepath, bepath)) !=3D=
 NULL) {
>> +      free(err);
>> +   }
>> +egress:
>> +   return;
>> +}
>> +
>> +void event_thread(void* p) {
>> +   event_listener();
>> +}
>> +
>> +void init_tpmback(char** exclusive_uuids)
>> +{
>> +   if(!globalinit) {
>> +      init_waitqueue_head(&waitq);
>> +      globalinit =3D 1;
>> +   }
>> +   printk("=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Init TPM BACK =3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D\n");
>> +   gtpmdev.tpmlist =3D malloc(sizeof(tpmif_t*) * DEF_ARRAY_SIZE);
>> +   gtpmdev.num_alloc =3D DEF_ARRAY_SIZE;
>> +   gtpmdev.num_tpms =3D 0;
>> +   gtpmdev.flags =3D 0;
>> +   gtpmdev.exclusive_uuids =3D exclusive_uuids;
>> +
>> +   gtpmdev.open_callback =3D gtpmdev.close_callback =3D NULL;
>> +   gtpmdev.suspend_callback =3D gtpmdev.resume_callback =3D NULL;
>> +
>> +   eventthread =3D create_thread("tpmback-listener", event_thread, NU=
LL);
>> +
>> +}
>> +
>> +void shutdown_tpmback(void)
>> +{
>> +   /* Disable callbacks */
>> +   gtpmdev.open_callback =3D gtpmdev.close_callback =3D NULL;
>> +   gtpmdev.suspend_callback =3D gtpmdev.resume_callback =3D NULL;
>> +
>> +   TPMBACK_LOG("Shutting down tpm backend\n");
>> +   /* Set the quit flag */
>> +   gtpmdev.flags =3D TPMIF_CLOSED;
>> +
>> +   //printk("num tpms is %d\n", gtpmdev.num_tpms);
>> +   /*Free all backend instances */
>> +   while(gtpmdev.num_tpms) {
>> +      free_tpmif(gtpmdev.tpmlist[0]);
>> +   }
>> +   free(gtpmdev.tpmlist);
>> +   gtpmdev.tpmlist =3D NULL;
>> +   gtpmdev.num_alloc =3D 0;
>> +
>> +   /* Wake up anyone possibly waiting on the device and let them exit=
 */
>> +   wake_up(&waitq);
>> +   schedule();
>> +}
>> +
>> +inline void init_tpmcmd(tpmcmd_t* tpmcmd, domid_t domid, unsigned int=

>> handle, char* uuid)
>> +{
>> +   tpmcmd->domid =3D domid;
>> +   tpmcmd->handle =3D handle;
>> +   tpmcmd->uuid =3D uuid;
>> +   tpmcmd->req =3D NULL;
>> +   tpmcmd->req_len =3D 0;
>> +   tpmcmd->resp =3D NULL;
>> +   tpmcmd->resp_len =3D 0;
>> +}
>> +
>> +tpmcmd_t* get_request(tpmif_t* tpmif) {
>> +   tpmcmd_t* cmd;
>> +   tpmif_tx_request_t* tx;
>> +   int offset;
>> +   int tocopy;
>> +   int i;
>> +   uint32_t domid;
>> +   int flags;
>> +
>> +   local_irq_save(flags);
>> +
>> +   /* Allocate the cmd object to hold the data */
>> +   if((cmd =3D malloc(sizeof(*cmd))) =3D=3D NULL) {
>> +      goto error;
>> +   }
>> +   init_tpmcmd(cmd, tpmif->domid, tpmif->handle, tpmif->uuid);
>> +
>> +   tx =3D &tpmif->tx->ring[0].req;
>> +   cmd->req_len =3D tx->size;
>> +   /* Allocate the buffer */
>> +   if(cmd->req_len) {
>> +      if((cmd->req =3D malloc(cmd->req_len)) =3D=3D NULL) {
>> +     goto error;
>> +      }
>> +   }
>> +   /* Copy the bits from the shared pages */
>> +   offset =3D 0;
>> +   for(i =3D 0; i < TPMIF_TX_RING_SIZE && offset < cmd->req_len; ++i)=
 {
>> +      tx =3D &tpmif->tx->ring[i].req;
>> +
>> +      /* Map the page with the data */
>> +      domid =3D (uint32_t)tpmif->domid;
>> +      if((tpmif->pages[i] =3D gntmap_map_grant_refs(&gtpmdev.map, 1,
>> &domid, 0, &tx->ref, PROT_READ)) =3D=3D NULL) {
>> +     TPMBACK_ERR("%u/%u Unable to map shared page during read!\n",
>> (unsigned int) tpmif->domid, tpmif->handle);
>> +     goto error;
>> +      }
>> +
>> +      /* do the copy now */
>> +      tocopy =3D min(cmd->req_len - offset, PAGE_SIZE);
>> +      memcpy(&cmd->req[offset], tpmif->pages[i], tocopy);
>> +      offset +=3D tocopy;
>> +
>> +      /* release the page */
>> +      gntmap_munmap(&gtpmdev.map, (unsigned long)tpmif->pages[i], 1);=

>> +
>> +   }
>> +
>> +#ifdef TPMBACK_PRINT_DEBUG
>> +   TPMBACK_DEBUG("Received Tpm Command from %u/%u of size %u",
>> (unsigned int) tpmif->domid, tpmif->handle, cmd->req_len);
>> +   for(i =3D 0; i < cmd->req_len; ++i) {
>> +      if (!(i % 30)) {
>> +     TPMBACK_DEBUG_MORE("\n");
>> +      }
>> +      TPMBACK_DEBUG_MORE("%02hhX ", cmd->req[i]);
>> +   }
>> +   TPMBACK_DEBUG_MORE("\n\n");
>> +#endif
>> +
>> +   local_irq_restore(flags);
>> +   return cmd;
>> +error:
>> +   if(cmd !=3D NULL) {
>> +      if (cmd->req !=3D NULL) {
>> +     free(cmd->req);
>> +     cmd->req =3D NULL;
>> +      }
>> +      free(cmd);
>> +      cmd =3D NULL;
>> +   }
>> +   local_irq_restore(flags);
>> +   return NULL;
>> +
>> +}
>> +
>> +void send_response(tpmcmd_t* cmd, tpmif_t* tpmif)
>> +{
>> +   tpmif_tx_request_t* tx;
>> +   int offset;
>> +   int i;
>> +   uint32_t domid;
>> +   int tocopy;
>> +   int flags;
>> +
>> +   local_irq_save(flags);
>> +
>> +   tx =3D &tpmif->tx->ring[0].req;
>> +   tx->size =3D cmd->resp_len;
>> +
>> +   offset =3D 0;
>> +   for(i =3D 0; i < TPMIF_TX_RING_SIZE && offset < cmd->resp_len; ++i=
) {
>> +      tx =3D &tpmif->tx->ring[i].req;
>> +
>> +      /* Map the page with the data */
>> +      domid =3D (uint32_t)tpmif->domid;
>> +      if((tpmif->pages[i] =3D gntmap_map_grant_refs(&gtpmdev.map, 1,
>> &domid, 0, &tx->ref, PROT_WRITE)) =3D=3D NULL) {
>> +     TPMBACK_ERR("%u/%u Unable to map shared page during write!\n",
>> (unsigned int) tpmif->domid, tpmif->handle);
>> +     goto error;
>> +      }
>> +
>> +      /* do the copy now */
>> +      tocopy =3D min(cmd->resp_len - offset, PAGE_SIZE);
>> +      memcpy(tpmif->pages[i], &cmd->resp[offset], tocopy);
>> +      offset +=3D tocopy;
>> +
>> +      /* release the page */
>> +      gntmap_munmap(&gtpmdev.map, (unsigned long)tpmif->pages[i], 1);=

>> +
>> +   }
>> +
>> +#ifdef TPMBACK_PRINT_DEBUG
>> +   TPMBACK_DEBUG("Sent response to %u/%u of size %u", (unsigned int)
>> tpmif->domid, tpmif->handle, cmd->resp_len);
>> +   for(i =3D 0; i < cmd->resp_len; ++i) {
>> +      if (!(i % 30)) {
>> +     TPMBACK_DEBUG_MORE("\n");
>> +      }
>> +      TPMBACK_DEBUG_MORE("%02hhX ", cmd->resp[i]);
>> +   }
>> +   TPMBACK_DEBUG_MORE("\n\n");
>> +#endif
>> +   /* clear the ready flag and send the event channel notice to the
>> frontend */
>> +   tpmif_req_finished(tpmif);
>> +   notify_remote_via_evtchn(tpmif->evtchn);
>> +error:
>> +   local_irq_restore(flags);
>> +   return;
>> +}
>> +
>> +tpmcmd_t* tpmback_req_any(void)
>> +{
>> +   int i;
>> +   /* Block until something has a request */
>> +   wait_event(waitq, (gtpmdev.flags & (TPMIF_REQ_READY | TPMIF_CLOSED=
)));
>> +
>> +   /* Check if were shutting down */
>> +   if(gtpmdev.flags & TPMIF_CLOSED) {
>> +      /* if something was waiting for us to give up the queue so it c=
an
>> shutdown, let it finish */
>> +      schedule();
>> +      return NULL;
>> +   }
>> +
>> +   for(i =3D 0; i < gtpmdev.num_tpms; ++i) {
>> +      if(gtpmdev.tpmlist[i]->flags & TPMIF_REQ_READY) {
>> +     return get_request(gtpmdev.tpmlist[i]);
>> +      }
>> +   }
>> +
>> +   TPMBACK_ERR("backend request ready flag was set but no interfaces
>> were actually ready\n");
>> +   return NULL;
>> +}
>> +
>> +tpmcmd_t* tpmback_req(domid_t domid, unsigned int handle)
>> +{
>> +   tpmif_t* tpmif;
>> +   tpmif =3D get_tpmif(domid, handle);
>> +   if(tpmif =3D=3D NULL) {
>> +      return NULL;
>> +   }
>> +
>> +   wait_event(waitq, (tpmif->flags & (TPMIF_REQ_READY | TPMIF_CLOSED)=

>> || gtpmdev.flags & TPMIF_CLOSED));
>> +
>> +   /* Check if were shutting down */
>> +   if(tpmif->flags & TPMIF_CLOSED || gtpmdev.flags & TPMIF_CLOSED) {
>> +      /* if something was waiting for us to give up the queue so it c=
an
>> free this instance, let it finish */
>> +      schedule();
>> +      return NULL;
>> +   }
>> +
>> +   return get_request(tpmif);
>> +}
>> +
>> +void tpmback_resp(tpmcmd_t* tpmcmd)
>> +{
>> +   tpmif_t* tpmif;
>> +
>> +   /* Get the associated interface, if it doesnt exist then just quit=
 */
>> +   tpmif =3D get_tpmif(tpmcmd->domid, tpmcmd->handle);
>> +   if(tpmif =3D=3D NULL) {
>> +      TPMBACK_ERR("Tried to send a reponse to non existant frontend
>> %u/%u\n", (unsigned int) tpmcmd->domid, tpmcmd->handle);
>> +      goto end;
>> +   }
>> +
>> +   if(!(tpmif->flags & TPMIF_REQ_READY)) {
>> +      TPMBACK_ERR("Tried to send response to a frontend that was not
>> waiting for one %u/%u\n", (unsigned int) tpmcmd->domid, tpmcmd->handle=
);
>> +      goto end;
>> +   }
>> +
>> +   /* Send response to frontend */
>> +   send_response(tpmcmd, tpmif);
>> +
>> +end:
>> +   if(tpmcmd->req !=3D NULL) {
>> +      free(tpmcmd->req);
>> +   }
>> +   free(tpmcmd);
>> +   return;
>> +}
>> +
>> +int tpmback_wait_for_frontend_connect(domid_t *domid, unsigned int *h=
andle)
>> +{
>> +   tpmif_t* tpmif;
>> +   int flags;
>> +   wait_event(waitq, ((gtpmdev.num_tpms > 0) || gtpmdev.flags &
>> TPMIF_CLOSED));
>> +   if(gtpmdev.flags & TPMIF_CLOSED) {
>> +      return -1;
>> +   }
>> +   local_irq_save(flags);
>> +   tpmif =3D gtpmdev.tpmlist[0];
>> +   *domid =3D tpmif->domid;
>> +   *handle =3D tpmif->handle;
>> +   local_irq_restore(flags);
>> +
>> +   return 0;
>> +}
>> +
>> +int tpmback_num_frontends(void)
>> +{
>> +   return gtpmdev.num_tpms;
>> +}
>> diff --git a/extras/mini-os/tpmfront.c b/extras/mini-os/tpmfront.c
>> --- /dev/null
>> +++ b/extras/mini-os/tpmfront.c
>> @@ -0,0 +1,606 @@
>> +/*
>> + * Copyright (c) 2010-2012 United States Government, as represented b=
y
>> + * the Secretary of Defense.  All rights reserved.
>> + *
>> + * This driver is free software: you can redistribute it and/or modif=
y
>> + * it under the terms of the GNU General Public License as published =
by
>> + * the Free Software Foundation, either version 3 of the License, or
>> + * (at your option) any later version.
>> + *
>> + * This driver is distributed in the hope that it will be useful,
>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
>> + * GNU General Public License for more details.
>> + *
>> + * You should have received a copy of the GNU General Public License
>> + * along with this program.  If not, see <http://www.gnu.org/licenses=
/>.
>> + *
>> + * Based upon the files:
>> + *  drivers/char/tpm/tpm_vtpm.c
>> + *  drivers/char/tpm/tpm_xen.c
>> + * from the Linux kernel, which are Copyright (C) 2006 IBM Corporatio=
n
>> + */
>> +#include <mini-os/os.h>
>> +#include <mini-os/xenbus.h>
>> +#include <mini-os/xmalloc.h>
>> +#include <mini-os/events.h>
>> +#include <mini-os/wait.h>
>> +#include <mini-os/gnttab.h>
>> +#include <xen/io/xenbus.h>
>> +#include <xen/io/tpmif.h>
>> +#include <mini-os/tpmfront.h>
>> +#include <fcntl.h>
>> +
>> +//#define TPMFRONT_PRINT_DEBUG
>> +#ifdef TPMFRONT_PRINT_DEBUG
>> +#define TPMFRONT_DEBUG(fmt,...) printk("Tpmfront:Debug("__FILE__":%d)=
 "
>> fmt, __LINE__, ##__VA_ARGS__)
>> +#define TPMFRONT_DEBUG_MORE(fmt,...) printk(fmt, ##__VA_ARGS__)
>> +#else
>> +#define TPMFRONT_DEBUG(fmt,...)
>> +#endif
>> +#define TPMFRONT_ERR(fmt,...) printk("Tpmfront:Error " fmt, ##__VA_AR=
GS__)
>> +#define TPMFRONT_LOG(fmt,...) printk("Tpmfront:Info " fmt, ##__VA_ARG=
S__)
>> +
>> +#define min(a,b) (((a) < (b)) ? (a) : (b))
>> +
>> +void tpmfront_handler(evtchn_port_t port, struct pt_regs *regs, void
>> *data) {
>> +   struct tpmfront_dev* dev =3D (struct tpmfront_dev*) data;
>> +   /*If we get a response when we didnt make a request, just ignore i=
t */
>> +   if(!dev->waiting) {
>> +      return;
>> +   }
>> +
>> +   dev->waiting =3D 0;
>> +#ifdef HAVE_LIBC
>> +   if(dev->fd >=3D 0) {
>> +      files[dev->fd].read =3D 1;
>> +   }
>> +#endif
>> +   wake_up(&dev->waitq);
>> +}
>> +
>> +static int publish_xenbus(struct tpmfront_dev* dev) {
>> +   xenbus_transaction_t xbt;
>> +   int retry;
>> +   char* err;
>> +   /* Write the grant reference and event channel to xenstore */
>> +again:
>> +   if((err =3D xenbus_transaction_start(&xbt))) {
>> +      TPMFRONT_ERR("Unable to start xenbus transaction, error was
>> %s\n", err);
>> +      free(err);
>> +      return -1;
>> +   }
>> +
>> +   if((err =3D xenbus_printf(xbt, dev->nodename, "ring-ref", "%u",
>> (unsigned int) dev->ring_ref))) {
>> +      TPMFRONT_ERR("Unable to write %s/ring-ref, error was %s\n",
>> dev->nodename, err);
>> +      free(err);
>> +      goto abort_transaction;
>> +   }
>> +
>> +   if((err =3D xenbus_printf(xbt, dev->nodename, "event-channel", "%u=
",
>> (unsigned int) dev->evtchn))) {
>> +      TPMFRONT_ERR("Unable to write %s/event-channel, error was %s\n"=
,
>> dev->nodename, err);
>> +      free(err);
>> +      goto abort_transaction;
>> +   }
>> +
>> +   if((err =3D xenbus_transaction_end(xbt, 0, &retry))) {
>> +      TPMFRONT_ERR("Unable to complete xenbus transaction, error was
>> %s\n", err);
>> +      free(err);
>> +      return -1;
>> +   }
>> +   if(retry) {
>> +      goto again;
>> +   }
>> +
>> +   return 0;
>> +abort_transaction:
>> +   if((err =3D xenbus_transaction_end(xbt, 1, &retry))) {
>> +      free(err);
>> +   }
>> +   return -1;
>> +}
>> +
>> +static int wait_for_backend_connect(xenbus_event_queue* events, char*=
 path)
>> +{
>> +   int state;
>> +
>> +   TPMFRONT_LOG("Waiting for backend connection..\n");
>> +   /* Wait for the backend to connect */
>> +   while(1) {
>> +      state =3D xenbus_read_integer(path);
>> +      if ( state < 0)
>> +     state =3D XenbusStateUnknown;
>> +      switch(state) {
>> +     /* Bad states, we quit with error */
>> +     case XenbusStateUnknown:
>> +     case XenbusStateClosing:
>> +     case XenbusStateClosed:
>> +        TPMFRONT_ERR("Unable to connect to backend\n");
>> +        return -1;
>> +     /* If backend is connected then break out of loop */
>> +     case XenbusStateConnected:
>> +        TPMFRONT_LOG("Backend Connected\n");
>> +        return 0;
>> +     default:
>> +        xenbus_wait_for_watch(events);
>> +      }
>> +   }
>> +
>> +}
>> +
>> +static int wait_for_backend_closed(xenbus_event_queue* events, char* =
path)
>> +{
>> +   int state;
>> +
>> +   TPMFRONT_LOG("Waiting for backend to close..\n");
>> +   while(1) {
>> +      state =3D xenbus_read_integer(path);
>> +      if ( state < 0)
>> +     state =3D XenbusStateUnknown;
>> +      switch(state) {
>> +     case XenbusStateUnknown:
>> +        TPMFRONT_ERR("Backend Unknown state, forcing shutdown\n");
>> +        return -1;
>> +     case XenbusStateClosed:
>> +        TPMFRONT_LOG("Backend Closed\n");
>> +        return 0;
>> +     default:
>> +        xenbus_wait_for_watch(events);
>> +      }
>> +   }
>> +
>> +}
>> +
>> +static int wait_for_backend_state_changed(struct tpmfront_dev* dev,
>> XenbusState state) {
>> +   char* err;
>> +   int ret =3D 0;
>> +   xenbus_event_queue events =3D NULL;
>> +   char path[512];
>> +
>> +   snprintf(path, 512, "%s/state", dev->bepath);
>> +   /*Setup the watch to wait for the backend */
>> +   if((err =3D xenbus_watch_path_token(XBT_NIL, path, path, &events))=
) {
>> +      TPMFRONT_ERR("Could not set a watch on %s, error was %s\n", pat=
h,
>> err);
>> +      free(err);
>> +      return -1;
>> +   }
>> +
>> +   /* Do the actual wait loop now */
>> +   switch(state) {
>> +      case XenbusStateConnected:
>> +     ret =3D wait_for_backend_connect(&events, path);
>> +     break;
>> +      case XenbusStateClosed:
>> +     ret =3D wait_for_backend_closed(&events, path);
>> +     break;
>> +      default:
>> +     break;
>> +   }
>> +
>> +   if((err =3D xenbus_unwatch_path_token(XBT_NIL, path, path))) {
>> +      TPMFRONT_ERR("Unable to unwatch %s, error was %s, ignoring..\n"=
,
>> path, err);
>> +      free(err);
>> +   }
>> +   return ret;
>> +}
>> +
>> +static int tpmfront_connect(struct tpmfront_dev* dev)
>> +{
>> +   char* err;
>> +   /* Create shared page */
>> +   dev->tx =3D (tpmif_tx_interface_t*) alloc_page();
>> +   if(dev->tx =3D=3D NULL) {
>> +      TPMFRONT_ERR("Unable to allocate page for shared memory\n");
>> +      goto error;
>> +   }
>> +   memset(dev->tx, 0, PAGE_SIZE);
>> +   dev->ring_ref =3D gnttab_grant_access(dev->bedomid,
>> virt_to_mfn(dev->tx), 0);
>> +   TPMFRONT_DEBUG("grant ref is %lu\n", (unsigned long) dev->ring_ref=
);
>> +
>> +   /*Create event channel */
>> +   if(evtchn_alloc_unbound(dev->bedomid, tpmfront_handler, dev,
>> &dev->evtchn)) {
>> +      TPMFRONT_ERR("Unable to allocate event channel\n");
>> +      goto error_postmap;
>> +   }
>> +   unmask_evtchn(dev->evtchn);
>> +   TPMFRONT_DEBUG("event channel is %lu\n", (unsigned long) dev->evtc=
hn);
>> +
>> +   /* Write the entries to xenstore */
>> +   if(publish_xenbus(dev)) {
>> +      goto error_postevtchn;
>> +   }
>> +
>> +   /* Change state to connected */
>> +   dev->state =3D XenbusStateConnected;
>> +
>> +   /* Tell the backend that we are ready */
>> +   if((err =3D xenbus_printf(XBT_NIL, dev->nodename, "state", "%u",
>> dev->state))) {
>> +      TPMFRONT_ERR("Unable to write to xenstore %s/state, value=3D%u"=
,
>> dev->nodename, XenbusStateConnected);
>> +      free(err);
>> +      goto error;
>> +   }
>> +
>> +   return 0;
>> +error_postevtchn:
>> +      mask_evtchn(dev->evtchn);
>> +      unbind_evtchn(dev->evtchn);
>> +error_postmap:
>> +      gnttab_end_access(dev->ring_ref);
>> +      free_page(dev->tx);
>> +error:
>> +   return -1;
>> +}
>> +
>> +struct tpmfront_dev* init_tpmfront(const char* _nodename)
>> +{
>> +   struct tpmfront_dev* dev;
>> +   const char* nodename;
>> +   char path[512];
>> +   char* value, *err;
>> +   unsigned long long ival;
>> +   int i;
>> +
>> +   printk("=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Init TPM Front =3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D\n");
>> +
>> +   dev =3D malloc(sizeof(struct tpmfront_dev));
>> +   memset(dev, 0, sizeof(struct tpmfront_dev));
>> +
>> +#ifdef HAVE_LIBC
>> +   dev->fd =3D -1;
>> +#endif
>> +
>> +   nodename =3D _nodename ? _nodename : "device/vtpm/0";
>> +   dev->nodename =3D strdup(nodename);
>> +
>> +   init_waitqueue_head(&dev->waitq);
>> +
>> +   /* Get backend domid */
>> +   snprintf(path, 512, "%s/backend-id", dev->nodename);
>> +   if((err =3D xenbus_read(XBT_NIL, path, &value))) {
>> +      TPMFRONT_ERR("Unable to read %s during tpmfront initialization!=

>> error =3D %s\n", path, err);
>> +      free(err);
>> +      goto error;
>> +   }
>> +   if(sscanf(value, "%llu", &ival) !=3D 1) {
>> +      TPMFRONT_ERR("%s has non-integer value (%s)\n", path, value);
>> +      free(value);
>> +      goto error;
>> +   }
>> +   free(value);
>> +   dev->bedomid =3D ival;
>> +
>> +   /* Get backend xenstore path */
>> +   snprintf(path, 512, "%s/backend", dev->nodename);
>> +   if((err =3D xenbus_read(XBT_NIL, path, &dev->bepath))) {
>> +      TPMFRONT_ERR("Unable to read %s during tpmfront initialization!=

>> error =3D %s\n", path, err);
>> +      free(err);
>> +      goto error;
>> +   }
>> +
>> +   /* Create and publish grant reference and event channel */
>> +   if (tpmfront_connect(dev)) {
>> +      goto error;
>> +   }
>> +
>> +   /* Wait for backend to connect */
>> +   if( wait_for_backend_state_changed(dev, XenbusStateConnected)) {
>> +      goto error;
>> +   }
>> +
>> +   /* Allocate pages that will contain the messages */
>> +   dev->pages =3D malloc(sizeof(void*) * TPMIF_TX_RING_SIZE);
>> +   if(dev->pages =3D=3D NULL) {
>> +      goto error;
>> +   }
>> +   memset(dev->pages, 0, sizeof(void*) * TPMIF_TX_RING_SIZE);
>> +   for(i =3D 0; i < TPMIF_TX_RING_SIZE; ++i) {
>> +      dev->pages[i] =3D (void*)alloc_page();
>> +      if(dev->pages[i] =3D=3D NULL) {
>> +     goto error;
>> +      }
>> +   }
>> +
>> +   TPMFRONT_LOG("Initialization Completed successfully\n");
>> +
>> +   return dev;
>> +
>> +error:
>> +   shutdown_tpmfront(dev);
>> +   return NULL;
>> +}
>> +void shutdown_tpmfront(struct tpmfront_dev* dev)
>> +{
>> +   char* err;
>> +   char path[512];
>> +   int i;
>> +   tpmif_tx_request_t* tx;
>> +   if(dev =3D=3D NULL) {
>> +      return;
>> +   }
>> +   TPMFRONT_LOG("Shutting down tpmfront\n");
>> +   /* disconnect */
>> +   if(dev->state =3D=3D XenbusStateConnected) {
>> +      dev->state =3D XenbusStateClosing;
>> +      //FIXME: Transaction for this?
>> +      /* Tell backend we are closing */
>> +      if((err =3D xenbus_printf(XBT_NIL, dev->nodename, "state", "%u"=
,
>> (unsigned int) dev->state))) {
>> +     free(err);
>> +      }
>> +
>> +      /* Clean up xenstore entries */
>> +      snprintf(path, 512, "%s/event-channel", dev->nodename);
>> +      if((err =3D xenbus_rm(XBT_NIL, path))) {
>> +     free(err);
>> +      }
>> +      snprintf(path, 512, "%s/ring-ref", dev->nodename);
>> +      if((err =3D xenbus_rm(XBT_NIL, path))) {
>> +     free(err);
>> +      }
>> +
>> +      /* Tell backend we are closed */
>> +      dev->state =3D XenbusStateClosed;
>> +      if((err =3D xenbus_printf(XBT_NIL, dev->nodename, "state", "%u"=
,
>> (unsigned int) dev->state))) {
>> +     TPMFRONT_ERR("Unable to write to %s, error was %s", dev->nodenam=
e,
>> err);
>> +     free(err);
>> +      }
>> +
>> +      /* Wait for the backend to close and unmap shared pages, ignore=

>> any errors */
>> +      wait_for_backend_state_changed(dev, XenbusStateClosed);
>> +
>> +      /* Cleanup any shared pages */
>> +      if(dev->pages) {
>> +     for(i =3D 0; i < TPMIF_TX_RING_SIZE; ++i) {
>> +        if(dev->pages[i]) {
>> +           tx =3D &dev->tx->ring[i].req;
>> +           if(tx->ref !=3D 0) {
>> +          gnttab_end_access(tx->ref);
>> +           }
>> +           free_page(dev->pages[i]);
>> +        }
>> +     }
>> +     free(dev->pages);
>> +      }
>> +
>> +      /* Close event channel and unmap shared page */
>> +      mask_evtchn(dev->evtchn);
>> +      unbind_evtchn(dev->evtchn);
>> +      gnttab_end_access(dev->ring_ref);
>> +
>> +      free_page(dev->tx);
>> +
>> +   }
>> +
>> +   /* Cleanup memory usage */
>> +   if(dev->respbuf) {
>> +      free(dev->respbuf);
>> +   }
>> +   if(dev->bepath) {
>> +      free(dev->bepath);
>> +   }
>> +   if(dev->nodename) {
>> +      free(dev->nodename);
>> +   }
>> +   free(dev);
>> +}
>> +
>> +int tpmfront_send(struct tpmfront_dev* dev, const uint8_t* msg, size_=
t
>> length)
>> +{
>> +   int i;
>> +   tpmif_tx_request_t* tx =3D NULL;
>> +   /* Error Checking */
>> +   if(dev =3D=3D NULL || dev->state !=3D XenbusStateConnected) {
>> +      TPMFRONT_ERR("Tried to send message through disconnected
>> frontend\n");
>> +      return -1;
>> +   }
>> +
>> +#ifdef TPMFRONT_PRINT_DEBUG
>> +   TPMFRONT_DEBUG("Sending Msg to backend size=3D%u", (unsigned int) =
length);
>> +   for(i =3D 0; i < length; ++i) {
>> +      if(!(i % 30)) {
>> +     TPMFRONT_DEBUG_MORE("\n");
>> +      }
>> +      TPMFRONT_DEBUG_MORE("%02X ", msg[i]);
>> +   }
>> +   TPMFRONT_DEBUG_MORE("\n");
>> +#endif
>> +
>> +   /* Copy to shared pages now */
>> +   for(i =3D 0; length > 0 && i < TPMIF_TX_RING_SIZE; ++i) {
>> +      /* Share the page */
>> +      tx =3D &dev->tx->ring[i].req;
>> +      tx->unused =3D 0;
>> +      tx->addr =3D virt_to_mach(dev->pages[i]);
>> +      tx->ref =3D gnttab_grant_access(dev->bedomid,
>> virt_to_mfn(dev->pages[i]), 0);
>> +      /* Copy the bits to the page */
>> +      tx->size =3D length > PAGE_SIZE ? PAGE_SIZE : length;
>> +      memcpy(dev->pages[i], &msg[i * PAGE_SIZE], tx->size);
>> +
>> +      /* Update counters */
>> +      length -=3D tx->size;
>> +   }
>> +   dev->waiting =3D 1;
>> +   dev->resplen =3D 0;
>> +#ifdef HAVE_LIBC
>> +   if(dev->fd >=3D 0) {
>> +      files[dev->fd].read =3D 0;
>> +      files[dev->fd].tpmfront.respgot =3D 0;
>> +      files[dev->fd].tpmfront.offset =3D 0;
>> +   }
>> +#endif
>> +   notify_remote_via_evtchn(dev->evtchn);
>> +   return 0;
>> +}
>> +int tpmfront_recv(struct tpmfront_dev* dev, uint8_t** msg, size_t *le=
ngth)
>> +{
>> +   tpmif_tx_request_t* tx;
>> +   int i;
>> +   if(dev =3D=3D NULL || dev->state !=3D XenbusStateConnected) {
>> +      TPMFRONT_ERR("Tried to receive message from disconnected
>> frontend\n");
>> +      return -1;
>> +   }
>> +   /*Wait for the response */
>> +   wait_event(dev->waitq, (!dev->waiting));
>> +
>> +   /* Initialize */
>> +   *msg =3D NULL;
>> +   *length =3D 0;
>> +
>> +   /* special case, just quit */
>> +   tx =3D &dev->tx->ring[0].req;
>> +   if(tx->size =3D=3D 0 ) {
>> +       goto quit;
>> +   }
>> +   /* Get the total size */
>> +   tx =3D &dev->tx->ring[0].req;
>> +   for(i =3D 0; i < TPMIF_TX_RING_SIZE && tx->size > 0; ++i) {
>> +      tx =3D &dev->tx->ring[i].req;
>> +      *length +=3D tx->size;
>> +   }
>> +   /* Alloc the buffer */
>> +   if(dev->respbuf) {
>> +      free(dev->respbuf);
>> +   }
>> +   *msg =3D dev->respbuf =3D malloc(*length);
>> +   dev->resplen =3D *length;
>> +   /* Copy the bits */
>> +   tx =3D &dev->tx->ring[0].req;
>> +   for(i =3D 0; i < TPMIF_TX_RING_SIZE && tx->size > 0; ++i) {
>> +      tx =3D &dev->tx->ring[i].req;
>> +      memcpy(&(*msg)[i * PAGE_SIZE], dev->pages[i], tx->size);
>> +      gnttab_end_access(tx->ref);
>> +      tx->ref =3D 0;
>> +   }
>> +#ifdef TPMFRONT_PRINT_DEBUG
>> +   TPMFRONT_DEBUG("Received response from backend size=3D%u", (unsign=
ed
>> int) *length);
>> +   for(i =3D 0; i < *length; ++i) {
>> +      if(!(i % 30)) {
>> +     TPMFRONT_DEBUG_MORE("\n");
>> +      }
>> +      TPMFRONT_DEBUG_MORE("%02X ", (*msg)[i]);
>> +   }
>> +   TPMFRONT_DEBUG_MORE("\n");
>> +#endif
>> +#ifdef HAVE_LIBC
>> +   if(dev->fd >=3D 0) {
>> +      files[dev->fd].tpmfront.respgot =3D 1;
>> +   }
>> +#endif
>> +quit:
>> +   return 0;
>> +}
>> +
>> +int tpmfront_cmd(struct tpmfront_dev* dev, uint8_t* req, size_t reqle=
n,
>> uint8_t** resp, size_t* resplen)
>> +{
>> +   int rc;
>> +   if((rc =3D tpmfront_send(dev, req, reqlen))) {
>> +      return rc;
>> +   }
>> +   if((rc =3D tpmfront_recv(dev, resp, resplen))) {
>> +      return rc;
>> +   }
>> +
>> +   return 0;
>> +}
>> +
>> +#ifdef HAVE_LIBC
>> +#include <errno.h>
>> +int tpmfront_open(struct tpmfront_dev* dev)
>> +{
>> +   /* Silently prevent multiple opens */
>> +   if(dev->fd !=3D -1) {
>> +      return dev->fd;
>> +   }
>> +
>> +   dev->fd =3D alloc_fd(FTYPE_TPMFRONT);
>> +   printk("tpmfront_open(%s) -> %d\n", dev->nodename, dev->fd);
>> +   files[dev->fd].tpmfront.dev =3D dev;
>> +   files[dev->fd].tpmfront.offset =3D 0;
>> +   files[dev->fd].tpmfront.respgot =3D 0;
>> +   return dev->fd;
>> +}
>> +
>> +int tpmfront_posix_write(int fd, const uint8_t* buf, size_t count)
>> +{
>> +   int rc;
>> +   struct tpmfront_dev* dev;
>> +   dev =3D files[fd].tpmfront.dev;
>> +
>> +   if(count =3D=3D 0) {
>> +      return 0;
>> +   }
>> +
>> +   /* Return an error if we are already processing a command */
>> +   if(dev->waiting) {
>> +      errno =3D EINPROGRESS;
>> +      return -1;
>> +   }
>> +   /* Send the command now */
>> +   if((rc =3D tpmfront_send(dev, buf, count)) !=3D 0) {
>> +      errno =3D EIO;
>> +      return -1;
>> +   }
>> +   return count;
>> +}
>> +
>> +int tpmfront_posix_read(int fd, uint8_t* buf, size_t count)
>> +{
>> +   int rc;
>> +   uint8_t* dummybuf;
>> +   size_t dummysz;
>> +   struct tpmfront_dev* dev;
>> +
>> +   dev =3D files[fd].tpmfront.dev;
>> +
>> +   if(count =3D=3D 0) {
>> +      return 0;
>> +   }
>> +
>> +   /* get the response if we haven't already */
>> +   if(files[dev->fd].tpmfront.respgot =3D=3D 0) {
>> +      if ((rc =3D tpmfront_recv(dev, &dummybuf, &dummysz)) !=3D 0) {
>> +     errno =3D EIO;
>> +     return -1;
>> +      }
>> +   }
>> +
>> +   /* handle EOF case */
>> +   if(files[dev->fd].tpmfront.offset >=3D dev->resplen) {
>> +      return 0;
>> +   }
>> +
>> +   /* Compute the number of bytes and do the copy operation */
>> +   if((rc =3D min(count, dev->resplen - files[dev->fd].tpmfront.offse=
t))
>> !=3D 0) {
>> +      memcpy(buf, dev->respbuf + files[dev->fd].tpmfront.offset, rc);=

>> +      files[dev->fd].tpmfront.offset +=3D rc;
>> +   }
>> +
>> +   return rc;
>> +}
>> +
>> +int tpmfront_posix_fstat(int fd, struct stat* buf)
>> +{
>> +   uint8_t* dummybuf;
>> +   size_t dummysz;
>> +   int rc;
>> +   struct tpmfront_dev* dev =3D files[fd].tpmfront.dev;
>> +
>> +   /* If we have a response waiting, then read it now from the backen=
d
>> +    * so we can get its length*/
>> +   if(dev->waiting || (files[dev->fd].read =3D=3D 1 &&
>> !files[dev->fd].tpmfront.respgot)) {
>> +      if ((rc =3D tpmfront_recv(dev, &dummybuf, &dummysz)) !=3D 0) {
>> +     errno =3D EIO;
>> +     return -1;
>> +      }
>> +   }
>> +
>> +   buf->st_mode =3D O_RDWR;
>> +   buf->st_uid =3D 0;
>> +   buf->st_gid =3D 0;
>> +   buf->st_size =3D dev->resplen;
>> +   buf->st_atime =3D buf->st_mtime =3D buf->st_ctime =3D time(NULL);
>> +
>> +   return 0;
>> +}
>> +
>> +
>> +#endif
>> --
>> 1.7.4.4
>>
>>
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xen.org
>> http://lists.xen.org/xen-devel
>>



--------------ms090403080908030504050400
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIDyjCC
A8YwggMvoAMCAQICBD/xyf0wDQYJKoZIhvcNAQEFBQAwLzELMAkGA1UEBhMCVVMxDzANBgNV
BAoTBkpIVUFQTDEPMA0GA1UECxMGQklTRENBMB4XDTEwMDYxMTE4MjIwNloXDTEzMDYxMTE4
NTIwNlowZjELMAkGA1UEBhMCVVMxDzANBgNVBAoTBkpIVUFQTDEPMA0GA1UECxMGUGVvcGxl
MTUwFgYDVQQLEw9WUE5Hcm91cC1CSVNEQ0EwGwYDVQQDExRNYXR0aGV3IEUgRmlvcmF2YW50
ZTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAnpbwVSP6o1Nb5lcW7dd3yTo9iBJdi7qz
4nANOMFPK7JOy5npKN1iiousl28U/scUJES55gPwAWYJK3uVyQAsA4adgDKi5DoD1UHDQEwp
bY7iHLJeq0NPr4BqYNqnCFPbE6HC8zSJrr4qKn+gVUQT39SIFqdiIPJwZL8FYTRQ/zsCAwEA
AaOCAbYwggGyMAsGA1UdDwQEAwIHgDArBgNVHRAEJDAigA8yMDEwMDYxMTE4MjIwNlqBDzIw
MTIwNzE3MjI1MjA2WjAbBg0rBgEEAbMlCwMBAQEBBAoWCGZpb3JhbWUxMBsGDSsGAQQBsyUL
AwEBAQIEChIIMDAxMDQyNjEwWAYJYIZIAYb6ax4BBEsMSVRoZSBwcml2YXRlIGtleSBjb3Jy
ZXNwb25kaW5nIHRvIHRoaXMgY2VydGlmaWNhdGUgbWF5IGhhdmUgYmVlbiBleHBvcnRlZC4w
KAYDVR0RBCEwH4EdTWF0dGhldy5GaW9yYXZhbnRlQGpodWFwbC5lZHUwUgYDVR0fBEswSTBH
oEWgQ6RBMD8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJU0RD
QTEOMAwGA1UEAxMFQ1JMNTYwHwYDVR0jBBgwFoAUCDUpmxH52EU2CyWmF2EJMB1yqeswHQYD
VR0OBBYEFO6LYxg6r9wHZ+zdQtBHn1dZ/YTNMAkGA1UdEwQCMAAwGQYJKoZIhvZ9B0EABAww
ChsEVjcuMQMCBLAwDQYJKoZIhvcNAQEFBQADgYEAJO9HQh4YNChVLzuZqK5ARJARD8JoujGZ
fdo75quvg2jXFQe2sEjvLnxJZgm/pv8fdZakq48CWwjYHKuvIp7sDjTEsQfo+y7SpN/N2NvJ
WU5SqfK1VgYtNLRRoGJUB5Q1aZ+Dg95g3kqpyfpUMISJL8IKVLtJVfN4fggFVUYZ9wwxggGr
MIIBpwIBATA3MC8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJ
U0RDQQIEP/HJ/TAJBgUrDgMCGgUAoIHLMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ
KoZIhvcNAQkFMQ8XDTEyMDkyNjE0Mjk1OFowIwYJKoZIhvcNAQkEMRYEFEcAzP5UnVPMuk+D
YwJMwsDYNzS0MGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAK
BggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI
KoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEgYAfBuN5r3MFy9ps+PxEWtNxfD9eymkuuk6B
74uumrrsob4qbEMW+ola9EMrfENRKhFKeVWl1AF8NPnGUzyHaJ4+Fa7MvrPmD3W/NYo7Cngp
9AQkPJNAWHPqSWXpWoBh4qnB4QxR+rUs+g4Dcp91jGKqBwEhatRbyChMq0n76gBysQAAAAAA
AA==
--------------ms090403080908030504050400--


--===============3681841939449735748==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============3681841939449735748==--


From xen-devel-bounces@lists.xen.org Wed Sep 26 14:33:21 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Sep 2012 14: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 1TGsfh-0008PE-75; Wed, 26 Sep 2012 14:33:05 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <matthew.fioravante@jhuapl.edu>) id 1TGsfg-0008P6-6I
	for xen-devel@lists.xensource.com; Wed, 26 Sep 2012 14:33:04 +0000
Received: from [85.158.143.35:42643] by server-1.bemta-4.messagelabs.com id
	D8/A7-05684-F1213605; Wed, 26 Sep 2012 14:33:03 +0000
X-Env-Sender: matthew.fioravante@jhuapl.edu
X-Msg-Ref: server-6.tower-21.messagelabs.com!1348669981!19972255!1
X-Originating-IP: [128.244.251.36]
X-SpamReason: No, hits=0.0 required=7.0 tests=UNPARSEABLE_RELAY
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3632 invoked from network); 26 Sep 2012 14:33:02 -0000
Received: from pilot.jhuapl.edu (HELO jhuapl.edu) (128.244.251.36)
	by server-6.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 26 Sep 2012 14:33:02 -0000
Received: from ([128.244.207.89])
	by pilot.jhuapl.edu with ESMTP with TLS id 63GHCH1.153692594;
	Wed, 26 Sep 2012 10:32:42 -0400
Message-ID: <506311BB.3000406@jhuapl.edu>
Date: Wed, 26 Sep 2012 10:31:23 -0400
From: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120827 Thunderbird/15.0
MIME-Version: 1.0
To: George Dunlap <George.Dunlap@eu.citrix.com>
References: <50579F53.4070302@jhuapl.edu>
	<20120917225245.GP5110@type.youpi.perso.aquilenet.fr>
	<5058BC47.8070907@jhuapl.edu>
	<CAFLBxZZMR1AdaaJN=BNPsmjYFcFV13RLCwS8_JLFqukfFZy96w@mail.gmail.com>
In-Reply-To: <CAFLBxZZMR1AdaaJN=BNPsmjYFcFV13RLCwS8_JLFqukfFZy96w@mail.gmail.com>
X-Enigmail-Version: 1.4.4
Cc: Samuel Thibault <samuel.thibault@ens-lyon.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH mini-os enhancements for vtpm 8/8] Add 3 tpm
 drivers to mini-os
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============8367798572148550434=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a cryptographically signed message in MIME format.

--===============8367798572148550434==
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms050707000703050702050108"

This is a cryptographically signed message in MIME format.

--------------ms050707000703050702050108
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On 09/26/2012 09:30 AM, George Dunlap wrote:
> On Tue, Sep 18, 2012 at 7:24 PM, Matthew Fioravante
> <matthew.fioravante@jhuapl.edu> wrote:
>> Is there anyone on the dev list that is familiar enough to review it?
>>
>> I can tell you we have been using all 3 of these drivers internally fo=
r
>> about 2 years now without issue. All of them are basically ports of th=
e
>> linux drivers to mini-os.
> If you're willing to be the TPM maintainer (which would involve adding
> your name to the MAINTAINERS file), and if Samuel is OK with you
> owning the tpm-related files in stubdom, I think it wouldn't
> necessarily need a thorough review to get in, as long as people are
> happy with how it integrates with the rest of the code.  What do
> people think?
>
>  -George
Looking into the maintainer question now. I'll get back to you all on thi=
s.
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel



--------------ms050707000703050702050108
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIDyjCC
A8YwggMvoAMCAQICBD/xyf0wDQYJKoZIhvcNAQEFBQAwLzELMAkGA1UEBhMCVVMxDzANBgNV
BAoTBkpIVUFQTDEPMA0GA1UECxMGQklTRENBMB4XDTEwMDYxMTE4MjIwNloXDTEzMDYxMTE4
NTIwNlowZjELMAkGA1UEBhMCVVMxDzANBgNVBAoTBkpIVUFQTDEPMA0GA1UECxMGUGVvcGxl
MTUwFgYDVQQLEw9WUE5Hcm91cC1CSVNEQ0EwGwYDVQQDExRNYXR0aGV3IEUgRmlvcmF2YW50
ZTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAnpbwVSP6o1Nb5lcW7dd3yTo9iBJdi7qz
4nANOMFPK7JOy5npKN1iiousl28U/scUJES55gPwAWYJK3uVyQAsA4adgDKi5DoD1UHDQEwp
bY7iHLJeq0NPr4BqYNqnCFPbE6HC8zSJrr4qKn+gVUQT39SIFqdiIPJwZL8FYTRQ/zsCAwEA
AaOCAbYwggGyMAsGA1UdDwQEAwIHgDArBgNVHRAEJDAigA8yMDEwMDYxMTE4MjIwNlqBDzIw
MTIwNzE3MjI1MjA2WjAbBg0rBgEEAbMlCwMBAQEBBAoWCGZpb3JhbWUxMBsGDSsGAQQBsyUL
AwEBAQIEChIIMDAxMDQyNjEwWAYJYIZIAYb6ax4BBEsMSVRoZSBwcml2YXRlIGtleSBjb3Jy
ZXNwb25kaW5nIHRvIHRoaXMgY2VydGlmaWNhdGUgbWF5IGhhdmUgYmVlbiBleHBvcnRlZC4w
KAYDVR0RBCEwH4EdTWF0dGhldy5GaW9yYXZhbnRlQGpodWFwbC5lZHUwUgYDVR0fBEswSTBH
oEWgQ6RBMD8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJU0RD
QTEOMAwGA1UEAxMFQ1JMNTYwHwYDVR0jBBgwFoAUCDUpmxH52EU2CyWmF2EJMB1yqeswHQYD
VR0OBBYEFO6LYxg6r9wHZ+zdQtBHn1dZ/YTNMAkGA1UdEwQCMAAwGQYJKoZIhvZ9B0EABAww
ChsEVjcuMQMCBLAwDQYJKoZIhvcNAQEFBQADgYEAJO9HQh4YNChVLzuZqK5ARJARD8JoujGZ
fdo75quvg2jXFQe2sEjvLnxJZgm/pv8fdZakq48CWwjYHKuvIp7sDjTEsQfo+y7SpN/N2NvJ
WU5SqfK1VgYtNLRRoGJUB5Q1aZ+Dg95g3kqpyfpUMISJL8IKVLtJVfN4fggFVUYZ9wwxggGr
MIIBpwIBATA3MC8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJ
U0RDQQIEP/HJ/TAJBgUrDgMCGgUAoIHLMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ
KoZIhvcNAQkFMQ8XDTEyMDkyNjE0MzEyM1owIwYJKoZIhvcNAQkEMRYEFDCIM+iTw3oyd5T0
+PRbjWBJOJ8aMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAK
BggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI
KoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEgYCNMH0gkG6p4Edar7gVeXZdtiIZPs0I2dYU
Vkth5j+z/ZZSSTCm20pUyAXpf5agAONZHnO9wDxH9CSHZDgRO5BQb3Qi7ty9B2JFq5XemLMA
cZOT7DXweN3fYbtHPp1tYRFgWI/heZAx/8PK72EHttaJlvpju4J4h57Lv0esJVOzqAAAAAAA
AA==
--------------ms050707000703050702050108--


--===============8367798572148550434==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============8367798572148550434==--


From xen-devel-bounces@lists.xen.org Wed Sep 26 14:33:21 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Sep 2012 14: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 1TGsfh-0008PE-75; Wed, 26 Sep 2012 14:33:05 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <matthew.fioravante@jhuapl.edu>) id 1TGsfg-0008P6-6I
	for xen-devel@lists.xensource.com; Wed, 26 Sep 2012 14:33:04 +0000
Received: from [85.158.143.35:42643] by server-1.bemta-4.messagelabs.com id
	D8/A7-05684-F1213605; Wed, 26 Sep 2012 14:33:03 +0000
X-Env-Sender: matthew.fioravante@jhuapl.edu
X-Msg-Ref: server-6.tower-21.messagelabs.com!1348669981!19972255!1
X-Originating-IP: [128.244.251.36]
X-SpamReason: No, hits=0.0 required=7.0 tests=UNPARSEABLE_RELAY
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3632 invoked from network); 26 Sep 2012 14:33:02 -0000
Received: from pilot.jhuapl.edu (HELO jhuapl.edu) (128.244.251.36)
	by server-6.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 26 Sep 2012 14:33:02 -0000
Received: from ([128.244.207.89])
	by pilot.jhuapl.edu with ESMTP with TLS id 63GHCH1.153692594;
	Wed, 26 Sep 2012 10:32:42 -0400
Message-ID: <506311BB.3000406@jhuapl.edu>
Date: Wed, 26 Sep 2012 10:31:23 -0400
From: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120827 Thunderbird/15.0
MIME-Version: 1.0
To: George Dunlap <George.Dunlap@eu.citrix.com>
References: <50579F53.4070302@jhuapl.edu>
	<20120917225245.GP5110@type.youpi.perso.aquilenet.fr>
	<5058BC47.8070907@jhuapl.edu>
	<CAFLBxZZMR1AdaaJN=BNPsmjYFcFV13RLCwS8_JLFqukfFZy96w@mail.gmail.com>
In-Reply-To: <CAFLBxZZMR1AdaaJN=BNPsmjYFcFV13RLCwS8_JLFqukfFZy96w@mail.gmail.com>
X-Enigmail-Version: 1.4.4
Cc: Samuel Thibault <samuel.thibault@ens-lyon.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH mini-os enhancements for vtpm 8/8] Add 3 tpm
 drivers to mini-os
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============8367798572148550434=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a cryptographically signed message in MIME format.

--===============8367798572148550434==
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms050707000703050702050108"

This is a cryptographically signed message in MIME format.

--------------ms050707000703050702050108
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On 09/26/2012 09:30 AM, George Dunlap wrote:
> On Tue, Sep 18, 2012 at 7:24 PM, Matthew Fioravante
> <matthew.fioravante@jhuapl.edu> wrote:
>> Is there anyone on the dev list that is familiar enough to review it?
>>
>> I can tell you we have been using all 3 of these drivers internally fo=
r
>> about 2 years now without issue. All of them are basically ports of th=
e
>> linux drivers to mini-os.
> If you're willing to be the TPM maintainer (which would involve adding
> your name to the MAINTAINERS file), and if Samuel is OK with you
> owning the tpm-related files in stubdom, I think it wouldn't
> necessarily need a thorough review to get in, as long as people are
> happy with how it integrates with the rest of the code.  What do
> people think?
>
>  -George
Looking into the maintainer question now. I'll get back to you all on thi=
s.
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel



--------------ms050707000703050702050108
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIDyjCC
A8YwggMvoAMCAQICBD/xyf0wDQYJKoZIhvcNAQEFBQAwLzELMAkGA1UEBhMCVVMxDzANBgNV
BAoTBkpIVUFQTDEPMA0GA1UECxMGQklTRENBMB4XDTEwMDYxMTE4MjIwNloXDTEzMDYxMTE4
NTIwNlowZjELMAkGA1UEBhMCVVMxDzANBgNVBAoTBkpIVUFQTDEPMA0GA1UECxMGUGVvcGxl
MTUwFgYDVQQLEw9WUE5Hcm91cC1CSVNEQ0EwGwYDVQQDExRNYXR0aGV3IEUgRmlvcmF2YW50
ZTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAnpbwVSP6o1Nb5lcW7dd3yTo9iBJdi7qz
4nANOMFPK7JOy5npKN1iiousl28U/scUJES55gPwAWYJK3uVyQAsA4adgDKi5DoD1UHDQEwp
bY7iHLJeq0NPr4BqYNqnCFPbE6HC8zSJrr4qKn+gVUQT39SIFqdiIPJwZL8FYTRQ/zsCAwEA
AaOCAbYwggGyMAsGA1UdDwQEAwIHgDArBgNVHRAEJDAigA8yMDEwMDYxMTE4MjIwNlqBDzIw
MTIwNzE3MjI1MjA2WjAbBg0rBgEEAbMlCwMBAQEBBAoWCGZpb3JhbWUxMBsGDSsGAQQBsyUL
AwEBAQIEChIIMDAxMDQyNjEwWAYJYIZIAYb6ax4BBEsMSVRoZSBwcml2YXRlIGtleSBjb3Jy
ZXNwb25kaW5nIHRvIHRoaXMgY2VydGlmaWNhdGUgbWF5IGhhdmUgYmVlbiBleHBvcnRlZC4w
KAYDVR0RBCEwH4EdTWF0dGhldy5GaW9yYXZhbnRlQGpodWFwbC5lZHUwUgYDVR0fBEswSTBH
oEWgQ6RBMD8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJU0RD
QTEOMAwGA1UEAxMFQ1JMNTYwHwYDVR0jBBgwFoAUCDUpmxH52EU2CyWmF2EJMB1yqeswHQYD
VR0OBBYEFO6LYxg6r9wHZ+zdQtBHn1dZ/YTNMAkGA1UdEwQCMAAwGQYJKoZIhvZ9B0EABAww
ChsEVjcuMQMCBLAwDQYJKoZIhvcNAQEFBQADgYEAJO9HQh4YNChVLzuZqK5ARJARD8JoujGZ
fdo75quvg2jXFQe2sEjvLnxJZgm/pv8fdZakq48CWwjYHKuvIp7sDjTEsQfo+y7SpN/N2NvJ
WU5SqfK1VgYtNLRRoGJUB5Q1aZ+Dg95g3kqpyfpUMISJL8IKVLtJVfN4fggFVUYZ9wwxggGr
MIIBpwIBATA3MC8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJ
U0RDQQIEP/HJ/TAJBgUrDgMCGgUAoIHLMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ
KoZIhvcNAQkFMQ8XDTEyMDkyNjE0MzEyM1owIwYJKoZIhvcNAQkEMRYEFDCIM+iTw3oyd5T0
+PRbjWBJOJ8aMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAK
BggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI
KoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEgYCNMH0gkG6p4Edar7gVeXZdtiIZPs0I2dYU
Vkth5j+z/ZZSSTCm20pUyAXpf5agAONZHnO9wDxH9CSHZDgRO5BQb3Qi7ty9B2JFq5XemLMA
cZOT7DXweN3fYbtHPp1tYRFgWI/heZAx/8PK72EHttaJlvpju4J4h57Lv0esJVOzqAAAAAAA
AA==
--------------ms050707000703050702050108--


--===============8367798572148550434==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============8367798572148550434==--


From xen-devel-bounces@lists.xen.org Wed Sep 26 14:37:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Sep 2012 14: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 1TGsk1-0000H0-TY; Wed, 26 Sep 2012 14:37:33 +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 1TGsk0-0000Gs-IS
	for xen-devel@lists.xen.org; Wed, 26 Sep 2012 14:37:32 +0000
Received: from [85.158.139.83:8385] by server-1.bemta-5.messagelabs.com id
	46/4B-09825-B2313605; Wed, 26 Sep 2012 14:37:31 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1348670250!29388821!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-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24344 invoked from network); 26 Sep 2012 14:37:31 -0000
Received: from mail-ey0-f173.google.com (HELO mail-ey0-f173.google.com)
	(209.85.215.173)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Sep 2012 14:37:31 -0000
Received: by eaaa1 with SMTP id a1so275232eaa.32
	for <xen-devel@lists.xen.org>; Wed, 26 Sep 2012 07:37:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=user-agent:date:subject:from:to:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=nDRDh6Ap8rR5t101CI0rWPDpq0doCk0Naaysk+WfNzE=;
	b=qGNzQOHk59dhbu6F+Ec1XpIqmMYB8L2f8v0XLFhpdGm9umK27SXvfMzkBQQHT/o9e/
	AK3TAUIkiCEmc0VLyzVeBT+Rv5q0ZBmxWKWUpK/EXFIg2wEUVfujJrsygL4QNRe7oTLK
	71E8c3a4sJgCDpWJFgxm4l8gNKSywmTmIjpcjJCc+xsxHj9QUT8U9vX4OQOXZQOPgpzX
	29KOGKDU/cJpt4RhbppkyYdjOYrod+ERf1zUnyROrutqyZw4nmR8XhtT8vognOhBAi6A
	XziazU1YRZqbt0M/v7FtLmZZDnhoZgatHKwwdFeD+UbRQh5Yj9uWD+yb5RLR4muMs07n
	veCw==
Received: by 10.14.202.71 with SMTP id c47mr1466442eeo.42.1348670250851;
	Wed, 26 Sep 2012 07:37:30 -0700 (PDT)
Received: from [192.168.1.69]
	(host86-160-224-180.range86-160.btcentralplus.com. [86.160.224.180])
	by mx.google.com with ESMTPS id a7sm9801746eep.14.2012.09.26.07.37.26
	(version=SSLv3 cipher=OTHER); Wed, 26 Sep 2012 07:37:29 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Wed, 26 Sep 2012 15:37:19 +0100
From: Keir Fraser <keir.xen@gmail.com>
To: Jan Beulich <JBeulich@suse.com>,
	xen-devel <xen-devel@lists.xen.org>
Message-ID: <CC88D1AF.40008%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [PATCH] x86: default-disable MWAIT-based idle driver
	for CPUs without ARAT
Thread-Index: Ac2b9G5kFfmToo+KLkadUTrHVTJWTg==
In-Reply-To: <506326B7020000780009E013@nat28.tlf.novell.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] [PATCH] x86: default-disable MWAIT-based idle
 driver for CPUs without ARAT
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/09/2012 15:00, "Jan Beulich" <JBeulich@suse.com> wrote:

> Without ARAT, and apparently only when using HPET broadcast mode as
> replacement, CPUs occasionally fail to wake up, causing the system to
> (transiently) hang. Until the reason is understood, disable the driver
> on such systems.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Acked-by: Keir Fraser <keir@xen.org>

> --- a/xen/arch/x86/cpu/mwait-idle.c
> +++ b/xen/arch/x86/cpu/mwait-idle.c
> @@ -71,7 +71,7 @@
>  # define pr_debug(fmt...)
>  #endif
>  
> -static __initdata bool_t no_mwait_idle;
> +static __initdata s8 no_mwait_idle = -1;
>  invbool_param("mwait-idle", no_mwait_idle);
>  
>  static unsigned int mwait_substates;
> @@ -500,6 +500,13 @@ int __init mwait_idle_init(struct notifi
> if (pm_idle_save)
> return -ENODEV;
>  
> + /* XXX The no-ARAT case is supposedly being taken care of, but at
> +  * least some systems without ARAT hang for some reason, apparently
> +  * only when using HPET broadcast mode (PIT broadcast mode seems to
> +  * be fine). */
> + if (no_mwait_idle < 0 && boot_cpu_has(X86_FEATURE_ARAT))
> +  no_mwait_idle = 0;
> +
> err = mwait_idle_probe();
> if (!err) {
> if (!boot_cpu_has(X86_FEATURE_ARAT))
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Sep 26 14:37:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Sep 2012 14: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 1TGsk1-0000H0-TY; Wed, 26 Sep 2012 14:37:33 +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 1TGsk0-0000Gs-IS
	for xen-devel@lists.xen.org; Wed, 26 Sep 2012 14:37:32 +0000
Received: from [85.158.139.83:8385] by server-1.bemta-5.messagelabs.com id
	46/4B-09825-B2313605; Wed, 26 Sep 2012 14:37:31 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1348670250!29388821!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-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24344 invoked from network); 26 Sep 2012 14:37:31 -0000
Received: from mail-ey0-f173.google.com (HELO mail-ey0-f173.google.com)
	(209.85.215.173)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Sep 2012 14:37:31 -0000
Received: by eaaa1 with SMTP id a1so275232eaa.32
	for <xen-devel@lists.xen.org>; Wed, 26 Sep 2012 07:37:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=user-agent:date:subject:from:to:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=nDRDh6Ap8rR5t101CI0rWPDpq0doCk0Naaysk+WfNzE=;
	b=qGNzQOHk59dhbu6F+Ec1XpIqmMYB8L2f8v0XLFhpdGm9umK27SXvfMzkBQQHT/o9e/
	AK3TAUIkiCEmc0VLyzVeBT+Rv5q0ZBmxWKWUpK/EXFIg2wEUVfujJrsygL4QNRe7oTLK
	71E8c3a4sJgCDpWJFgxm4l8gNKSywmTmIjpcjJCc+xsxHj9QUT8U9vX4OQOXZQOPgpzX
	29KOGKDU/cJpt4RhbppkyYdjOYrod+ERf1zUnyROrutqyZw4nmR8XhtT8vognOhBAi6A
	XziazU1YRZqbt0M/v7FtLmZZDnhoZgatHKwwdFeD+UbRQh5Yj9uWD+yb5RLR4muMs07n
	veCw==
Received: by 10.14.202.71 with SMTP id c47mr1466442eeo.42.1348670250851;
	Wed, 26 Sep 2012 07:37:30 -0700 (PDT)
Received: from [192.168.1.69]
	(host86-160-224-180.range86-160.btcentralplus.com. [86.160.224.180])
	by mx.google.com with ESMTPS id a7sm9801746eep.14.2012.09.26.07.37.26
	(version=SSLv3 cipher=OTHER); Wed, 26 Sep 2012 07:37:29 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Wed, 26 Sep 2012 15:37:19 +0100
From: Keir Fraser <keir.xen@gmail.com>
To: Jan Beulich <JBeulich@suse.com>,
	xen-devel <xen-devel@lists.xen.org>
Message-ID: <CC88D1AF.40008%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [PATCH] x86: default-disable MWAIT-based idle driver
	for CPUs without ARAT
Thread-Index: Ac2b9G5kFfmToo+KLkadUTrHVTJWTg==
In-Reply-To: <506326B7020000780009E013@nat28.tlf.novell.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] [PATCH] x86: default-disable MWAIT-based idle
 driver for CPUs without ARAT
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/09/2012 15:00, "Jan Beulich" <JBeulich@suse.com> wrote:

> Without ARAT, and apparently only when using HPET broadcast mode as
> replacement, CPUs occasionally fail to wake up, causing the system to
> (transiently) hang. Until the reason is understood, disable the driver
> on such systems.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Acked-by: Keir Fraser <keir@xen.org>

> --- a/xen/arch/x86/cpu/mwait-idle.c
> +++ b/xen/arch/x86/cpu/mwait-idle.c
> @@ -71,7 +71,7 @@
>  # define pr_debug(fmt...)
>  #endif
>  
> -static __initdata bool_t no_mwait_idle;
> +static __initdata s8 no_mwait_idle = -1;
>  invbool_param("mwait-idle", no_mwait_idle);
>  
>  static unsigned int mwait_substates;
> @@ -500,6 +500,13 @@ int __init mwait_idle_init(struct notifi
> if (pm_idle_save)
> return -ENODEV;
>  
> + /* XXX The no-ARAT case is supposedly being taken care of, but at
> +  * least some systems without ARAT hang for some reason, apparently
> +  * only when using HPET broadcast mode (PIT broadcast mode seems to
> +  * be fine). */
> + if (no_mwait_idle < 0 && boot_cpu_has(X86_FEATURE_ARAT))
> +  no_mwait_idle = 0;
> +
> err = mwait_idle_probe();
> if (!err) {
> if (!boot_cpu_has(X86_FEATURE_ARAT))
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Sep 26 14:40:43 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Sep 2012 14:40: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 1TGsmt-0000PU-Fx; Wed, 26 Sep 2012 14:40:31 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1TGsmr-0000PI-Hs
	for xen-devel@lists.xensource.com; Wed, 26 Sep 2012 14:40:29 +0000
Received: from [85.158.139.211:57038] by server-9.bemta-5.messagelabs.com id
	D0/EF-14846-CD313605; Wed, 26 Sep 2012 14:40:28 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1348670427!19595422!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTE1NzQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25208 invoked from network); 26 Sep 2012 14:40:27 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Sep 2012 14:40:27 -0000
X-IronPort-AV: E=Sophos;i="4.80,490,1344211200"; d="scan'208";a="14780513"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Sep 2012 14:39:45 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Wed, 26 Sep 2012 15:39: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 1TGsm9-0001IZ-JU;
	Wed, 26 Sep 2012 14:39:45 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1TGsm9-0000gr-5C;
	Wed, 26 Sep 2012 15:39:45 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-13873-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 26 Sep 2012 15:39:45 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.2-testing test] 13873: 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 13873 xen-4.2-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13873/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore            fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-i386-i386-xl-qemuu-winxpsp3  9 guest-localmigrate         fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     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-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  2b59edeb0fdd
baseline version:
 xen                  3462914d95d3

------------------------------------------------------------
People who touched revisions under test:
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  Dan Magenheimer <dan.magenheimer@oracle.com>
  Ian Campbell <ian.campbell@citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Steven Maresca <steve@zentific.com>
  Tim Deegan <tim@xen.org>
  Zhenzhong Duan <zhenzhong.duan@oracle.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                                 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                                     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-4.2-testing
+ revision=2b59edeb0fdd
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push xen-4.2-testing 2b59edeb0fdd
+ branch=xen-4.2-testing
+ revision=2b59edeb0fdd
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-4.2-testing
+ '[' xxen = xlinux ']'
+ linuxbranch=linux
+ : master
+ : tested/2.6.39.x
+ . ap-common
++ : xen@xenbits.xensource.com
++ : http://xenbits.xen.org/hg/staging/xen-4.2-testing.hg
++ : git://xenbits.xen.org/staging/qemu-xen-4.2-testing.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : xen@xenbits.xensource.com:git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.xen-4.2-testing
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-4.2-testing.git
++ : daily-cron.xen-4.2-testing
+ TREE_LINUX=xen@xenbits.xensource.com:git/linux-pvops.git
+ TREE_QEMU_UPSTREAM=xen@xenbits.xensource.com:git/qemu-upstream-4.2-testing.git
+ info_linux_tree xen-4.2-testing
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/xen-4.2-testing.hg
+ hg push -r 2b59edeb0fdd ssh://xen@xenbits.xensource.com/HG/xen-4.2-testing.hg
pushing to ssh://xen@xenbits.xensource.com/HG/xen-4.2-testing.hg
searching for changes
remote: adding changesets
remote: adding manifests
remote: adding file changes
remote: added 12 changesets with 17 changes to 3 files

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 26 14:40:43 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Sep 2012 14:40: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 1TGsmt-0000PU-Fx; Wed, 26 Sep 2012 14:40:31 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1TGsmr-0000PI-Hs
	for xen-devel@lists.xensource.com; Wed, 26 Sep 2012 14:40:29 +0000
Received: from [85.158.139.211:57038] by server-9.bemta-5.messagelabs.com id
	D0/EF-14846-CD313605; Wed, 26 Sep 2012 14:40:28 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-206.messagelabs.com!1348670427!19595422!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTE1NzQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25208 invoked from network); 26 Sep 2012 14:40:27 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Sep 2012 14:40:27 -0000
X-IronPort-AV: E=Sophos;i="4.80,490,1344211200"; d="scan'208";a="14780513"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Sep 2012 14:39:45 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Wed, 26 Sep 2012 15:39: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 1TGsm9-0001IZ-JU;
	Wed, 26 Sep 2012 14:39:45 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1TGsm9-0000gr-5C;
	Wed, 26 Sep 2012 15:39:45 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-13873-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 26 Sep 2012 15:39:45 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.2-testing test] 13873: 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 13873 xen-4.2-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13873/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore            fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-i386-i386-xl-qemuu-winxpsp3  9 guest-localmigrate         fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     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-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  2b59edeb0fdd
baseline version:
 xen                  3462914d95d3

------------------------------------------------------------
People who touched revisions under test:
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  Dan Magenheimer <dan.magenheimer@oracle.com>
  Ian Campbell <ian.campbell@citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Steven Maresca <steve@zentific.com>
  Tim Deegan <tim@xen.org>
  Zhenzhong Duan <zhenzhong.duan@oracle.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                                 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                                     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-4.2-testing
+ revision=2b59edeb0fdd
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push xen-4.2-testing 2b59edeb0fdd
+ branch=xen-4.2-testing
+ revision=2b59edeb0fdd
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-4.2-testing
+ '[' xxen = xlinux ']'
+ linuxbranch=linux
+ : master
+ : tested/2.6.39.x
+ . ap-common
++ : xen@xenbits.xensource.com
++ : http://xenbits.xen.org/hg/staging/xen-4.2-testing.hg
++ : git://xenbits.xen.org/staging/qemu-xen-4.2-testing.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : xen@xenbits.xensource.com:git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.xen-4.2-testing
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-4.2-testing.git
++ : daily-cron.xen-4.2-testing
+ TREE_LINUX=xen@xenbits.xensource.com:git/linux-pvops.git
+ TREE_QEMU_UPSTREAM=xen@xenbits.xensource.com:git/qemu-upstream-4.2-testing.git
+ info_linux_tree xen-4.2-testing
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/xen-4.2-testing.hg
+ hg push -r 2b59edeb0fdd ssh://xen@xenbits.xensource.com/HG/xen-4.2-testing.hg
pushing to ssh://xen@xenbits.xensource.com/HG/xen-4.2-testing.hg
searching for changes
remote: adding changesets
remote: adding manifests
remote: adding file changes
remote: added 12 changesets with 17 changes to 3 files

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 26 14:41:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Sep 2012 14:41: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 1TGsnQ-0000Sa-T2; Wed, 26 Sep 2012 14:41:04 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jmarcet@gmail.com>) id 1TGsnQ-0000ST-AX
	for xen-devel@lists.xen.org; Wed, 26 Sep 2012 14:41:04 +0000
Received: from [85.158.139.211:34281] by server-9.bemta-5.messagelabs.com id
	16/11-14846-FF313605; Wed, 26 Sep 2012 14:41:03 +0000
X-Env-Sender: jmarcet@gmail.com
X-Msg-Ref: server-4.tower-206.messagelabs.com!1348670461!20070651!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-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17953 invoked from network); 26 Sep 2012 14:41:03 -0000
Received: from mail-ob0-f173.google.com (HELO mail-ob0-f173.google.com)
	(209.85.214.173)
	by server-4.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Sep 2012 14:41:03 -0000
Received: by obbta14 with SMTP id ta14so876005obb.32
	for <xen-devel@lists.xen.org>; Wed, 26 Sep 2012 07:41:01 -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=cmuZ2ZVnxVh1biHy4xPVtiOwdbLexMPnfBUSoCmnRhM=;
	b=M45+by+0l7EiI6MqnI7H14y+hp+UcjKtZA9LlNlfiHlRg0s+uotRlJVtkbmaWAiRX/
	sDov3DNgCQNf35vY959SB3JX50UMdz/f+mUrj3yHOcHQTf+MG0Txhz1csr3FQ6/YREjZ
	QqRkeMZ3pBuE9Zkv6dF80cNNPY7smqtIGCJXAnzlF08ei6WdWRot9VSyPuPtPvoXnCER
	OmpZ/ZDCICBc9yMYt7BmElDz0q4AEvV5OjmHNkrYIb/G9DAwIoBISrcxm4FOwvnErAP1
	QVbbWxgucQwW+047Yw/vVR1YqqoP68xEv7OLusUQo1q22VykqnJ8zDxXOTbQkL3V85EV
	jc5g==
Received: by 10.60.7.99 with SMTP id i3mr565967oea.86.1348670461439; Wed, 26
	Sep 2012 07:41:01 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.60.138.225 with HTTP; Wed, 26 Sep 2012 07:40:41 -0700 (PDT)
In-Reply-To: <7838417303277258895@unknownmsgid>
References: <CAOvdn6XV4eoA-FfFns1xhx7HCUqXc7KHxZwyKuT4FHG8s3R5RQ@mail.gmail.com>
	<CAAnFQG9PLQjdh6Ab6=Y5ZGM1s4nGdLekKU=pcKNMxt4rmt_RKA@mail.gmail.com>
	<20120924140411.GH31618@phenom.dumpdata.com>
	<CAAnFQG-tjv5UyF6j-TNHNgme2c4vA0Zxy8AdCiJEVsf2Z0quNA@mail.gmail.com>
	<20120925140611.GB16478@phenom.dumpdata.com>
	<CAAnFQG88ApxKuscXx53Lt2qOyCe0ws6oXSSqBDfW0+oYo5Y3nA@mail.gmail.com>
	<5061E800020000780009DBBA@nat28.tlf.novell.com>
	<CAAnFQG-6VrwaA_OcUJL5X5HBNo8PTME9pNyJbsXqSO34tbD8=g@mail.gmail.com>
	<5062C81D020000780009DE2E@nat28.tlf.novell.com>
	<CAAnFQG9f-97RQTt0YNGds6q9FDRcLEOAXrAdZuJw_p=+3opn7Q@mail.gmail.com>
	<20120926124335.GG7356@phenom.dumpdata.com>
	<CAAnFQG-cJW=h1UFCu3W6AmgarhV7O2Z2xjxfHs=apcyvMthbAg@mail.gmail.com>
	<7838417303277258895@unknownmsgid>
From: Javier Marcet <jmarcet@gmail.com>
Date: Wed, 26 Sep 2012 16:40:41 +0200
Message-ID: <CAAnFQG_-Y-WSb5UstyUm=p7AL8NKLzza7_Jz0PmsATddPhn3QQ@mail.gmail.com>
To: Ben Guthro <ben.guthro@gmail.com>
Cc: Keir Fraser <keir@xen.org>,
	"john.baboval@citrix.com" <john.baboval@citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	xen-devel <xen-devel@lists.xen.org>,
	Konrad Rzeszutek Wilk <konrad@kernel.org>,
	Ben Guthro <ben@guthro.net>, Jan Beulich <JBeulich@suse.com>,
	Thomas Goetz <thomas.goetz@citrix.com>
Subject: Re: [Xen-devel] Xen4.2 S3 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: multipart/mixed; boundary="===============7301634806165040239=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============7301634806165040239==
Content-Type: multipart/alternative; boundary=e89a8fb2052cc5ef6304ca9bcf72

--e89a8fb2052cc5ef6304ca9bcf72
Content-Type: text/plain; charset=UTF-8

On Wed, Sep 26, 2012 at 4:26 PM, Ben Guthro <ben.guthro@gmail.com> wrote:

Yes. Pvops PV dom0 kernel.
>
> It is really more appropriate to start a new thread, than having 2
> disparate conversations in this one. It makes it confusing to follow.
>

OK. I started it a few days ago, with the back trace et all but I have got
no response so far. I'll try what you suggest and continue on the other
thread.


-- 
Javier Marcet <jmarcet@gmail.com>

--e89a8fb2052cc5ef6304ca9bcf72
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div class=3D"gmail_quote">On Wed, Sep 26, 2012 at 4:26 PM, Ben Guthro <spa=
n dir=3D"ltr">&lt;<a href=3D"mailto:ben.guthro@gmail.com" target=3D"_blank"=
>ben.guthro@gmail.com</a>&gt;</span> wrote:</div><div class=3D"gmail_quote"=
><br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-le=
ft:1px #ccc solid;padding-left:1ex">

<div dir=3D"auto"><div>Yes. Pvops PV dom0 kernel.=C2=A0</div><div><br></div=
><div>It is really more appropriate to start a new thread, than having 2 di=
sparate conversations in this one. It makes it confusing to follow.=C2=A0</=
div></div>

</blockquote><div><br></div><div>OK. I started it a few days ago, with the =
back trace et all but I have got no response so far. I&#39;ll try what you =
suggest and continue on the other thread.</div><div>=C2=A0</div></div><div>
<br>
</div>-- <br>Javier Marcet &lt;<a href=3D"mailto:jmarcet@gmail.com" target=
=3D"_blank">jmarcet@gmail.com</a>&gt;<br><br>

--e89a8fb2052cc5ef6304ca9bcf72--


--===============7301634806165040239==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============7301634806165040239==--


From xen-devel-bounces@lists.xen.org Wed Sep 26 14:41:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Sep 2012 14:41: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 1TGsnQ-0000Sa-T2; Wed, 26 Sep 2012 14:41:04 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jmarcet@gmail.com>) id 1TGsnQ-0000ST-AX
	for xen-devel@lists.xen.org; Wed, 26 Sep 2012 14:41:04 +0000
Received: from [85.158.139.211:34281] by server-9.bemta-5.messagelabs.com id
	16/11-14846-FF313605; Wed, 26 Sep 2012 14:41:03 +0000
X-Env-Sender: jmarcet@gmail.com
X-Msg-Ref: server-4.tower-206.messagelabs.com!1348670461!20070651!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-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17953 invoked from network); 26 Sep 2012 14:41:03 -0000
Received: from mail-ob0-f173.google.com (HELO mail-ob0-f173.google.com)
	(209.85.214.173)
	by server-4.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Sep 2012 14:41:03 -0000
Received: by obbta14 with SMTP id ta14so876005obb.32
	for <xen-devel@lists.xen.org>; Wed, 26 Sep 2012 07:41:01 -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=cmuZ2ZVnxVh1biHy4xPVtiOwdbLexMPnfBUSoCmnRhM=;
	b=M45+by+0l7EiI6MqnI7H14y+hp+UcjKtZA9LlNlfiHlRg0s+uotRlJVtkbmaWAiRX/
	sDov3DNgCQNf35vY959SB3JX50UMdz/f+mUrj3yHOcHQTf+MG0Txhz1csr3FQ6/YREjZ
	QqRkeMZ3pBuE9Zkv6dF80cNNPY7smqtIGCJXAnzlF08ei6WdWRot9VSyPuPtPvoXnCER
	OmpZ/ZDCICBc9yMYt7BmElDz0q4AEvV5OjmHNkrYIb/G9DAwIoBISrcxm4FOwvnErAP1
	QVbbWxgucQwW+047Yw/vVR1YqqoP68xEv7OLusUQo1q22VykqnJ8zDxXOTbQkL3V85EV
	jc5g==
Received: by 10.60.7.99 with SMTP id i3mr565967oea.86.1348670461439; Wed, 26
	Sep 2012 07:41:01 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.60.138.225 with HTTP; Wed, 26 Sep 2012 07:40:41 -0700 (PDT)
In-Reply-To: <7838417303277258895@unknownmsgid>
References: <CAOvdn6XV4eoA-FfFns1xhx7HCUqXc7KHxZwyKuT4FHG8s3R5RQ@mail.gmail.com>
	<CAAnFQG9PLQjdh6Ab6=Y5ZGM1s4nGdLekKU=pcKNMxt4rmt_RKA@mail.gmail.com>
	<20120924140411.GH31618@phenom.dumpdata.com>
	<CAAnFQG-tjv5UyF6j-TNHNgme2c4vA0Zxy8AdCiJEVsf2Z0quNA@mail.gmail.com>
	<20120925140611.GB16478@phenom.dumpdata.com>
	<CAAnFQG88ApxKuscXx53Lt2qOyCe0ws6oXSSqBDfW0+oYo5Y3nA@mail.gmail.com>
	<5061E800020000780009DBBA@nat28.tlf.novell.com>
	<CAAnFQG-6VrwaA_OcUJL5X5HBNo8PTME9pNyJbsXqSO34tbD8=g@mail.gmail.com>
	<5062C81D020000780009DE2E@nat28.tlf.novell.com>
	<CAAnFQG9f-97RQTt0YNGds6q9FDRcLEOAXrAdZuJw_p=+3opn7Q@mail.gmail.com>
	<20120926124335.GG7356@phenom.dumpdata.com>
	<CAAnFQG-cJW=h1UFCu3W6AmgarhV7O2Z2xjxfHs=apcyvMthbAg@mail.gmail.com>
	<7838417303277258895@unknownmsgid>
From: Javier Marcet <jmarcet@gmail.com>
Date: Wed, 26 Sep 2012 16:40:41 +0200
Message-ID: <CAAnFQG_-Y-WSb5UstyUm=p7AL8NKLzza7_Jz0PmsATddPhn3QQ@mail.gmail.com>
To: Ben Guthro <ben.guthro@gmail.com>
Cc: Keir Fraser <keir@xen.org>,
	"john.baboval@citrix.com" <john.baboval@citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	xen-devel <xen-devel@lists.xen.org>,
	Konrad Rzeszutek Wilk <konrad@kernel.org>,
	Ben Guthro <ben@guthro.net>, Jan Beulich <JBeulich@suse.com>,
	Thomas Goetz <thomas.goetz@citrix.com>
Subject: Re: [Xen-devel] Xen4.2 S3 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: multipart/mixed; boundary="===============7301634806165040239=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============7301634806165040239==
Content-Type: multipart/alternative; boundary=e89a8fb2052cc5ef6304ca9bcf72

--e89a8fb2052cc5ef6304ca9bcf72
Content-Type: text/plain; charset=UTF-8

On Wed, Sep 26, 2012 at 4:26 PM, Ben Guthro <ben.guthro@gmail.com> wrote:

Yes. Pvops PV dom0 kernel.
>
> It is really more appropriate to start a new thread, than having 2
> disparate conversations in this one. It makes it confusing to follow.
>

OK. I started it a few days ago, with the back trace et all but I have got
no response so far. I'll try what you suggest and continue on the other
thread.


-- 
Javier Marcet <jmarcet@gmail.com>

--e89a8fb2052cc5ef6304ca9bcf72
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div class=3D"gmail_quote">On Wed, Sep 26, 2012 at 4:26 PM, Ben Guthro <spa=
n dir=3D"ltr">&lt;<a href=3D"mailto:ben.guthro@gmail.com" target=3D"_blank"=
>ben.guthro@gmail.com</a>&gt;</span> wrote:</div><div class=3D"gmail_quote"=
><br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-le=
ft:1px #ccc solid;padding-left:1ex">

<div dir=3D"auto"><div>Yes. Pvops PV dom0 kernel.=C2=A0</div><div><br></div=
><div>It is really more appropriate to start a new thread, than having 2 di=
sparate conversations in this one. It makes it confusing to follow.=C2=A0</=
div></div>

</blockquote><div><br></div><div>OK. I started it a few days ago, with the =
back trace et all but I have got no response so far. I&#39;ll try what you =
suggest and continue on the other thread.</div><div>=C2=A0</div></div><div>
<br>
</div>-- <br>Javier Marcet &lt;<a href=3D"mailto:jmarcet@gmail.com" target=
=3D"_blank">jmarcet@gmail.com</a>&gt;<br><br>

--e89a8fb2052cc5ef6304ca9bcf72--


--===============7301634806165040239==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============7301634806165040239==--


From xen-devel-bounces@lists.xen.org Wed Sep 26 14:41:37 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Sep 2012 14:41:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGsnn-0000WI-A3; Wed, 26 Sep 2012 14:41:27 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <matthew.fioravante@jhuapl.edu>) id 1TGsnm-0000W3-82
	for xen-devel@lists.xensource.com; Wed, 26 Sep 2012 14:41:26 +0000
Received: from [85.158.139.211:35637] by server-5.bemta-5.messagelabs.com id
	81/F3-21075-51413605; Wed, 26 Sep 2012 14:41:25 +0000
X-Env-Sender: matthew.fioravante@jhuapl.edu
X-Msg-Ref: server-2.tower-206.messagelabs.com!1348670483!20037158!1
X-Originating-IP: [128.244.251.36]
X-SpamReason: No, hits=0.0 required=7.0 tests=UNPARSEABLE_RELAY
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7033 invoked from network); 26 Sep 2012 14:41:24 -0000
Received: from pilot.jhuapl.edu (HELO jhuapl.edu) (128.244.251.36)
	by server-2.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 26 Sep 2012 14:41:24 -0000
Received: from ([128.244.207.89])
	by pilot.jhuapl.edu with ESMTP with TLS id 63GHCH1.153693928;
	Wed, 26 Sep 2012 10:41:16 -0400
Message-ID: <506313BD.7020600@jhuapl.edu>
Date: Wed, 26 Sep 2012 10:39:57 -0400
From: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120827 Thunderbird/15.0
MIME-Version: 1.0
To: George Dunlap <George.Dunlap@eu.citrix.com>
References: <50576368.3070007@jhuapl.edu>
	<1347953926.25803.89.camel@dagon.hellion.org.uk>
	<5058B07C.1070404@jhuapl.edu>
	<1348566822.3452.151.camel@zakaz.uk.xensource.com>
	<5061D2CC.3030108@jhuapl.edu>
	<CAFLBxZYh69025_LHq2qWfQMotincb_pvDtCtiAa7sXCg-RQL6A@mail.gmail.com>
In-Reply-To: <CAFLBxZYh69025_LHq2qWfQMotincb_pvDtCtiAa7sXCg-RQL6A@mail.gmail.com>
X-Enigmail-Version: 1.4.4
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH] Upgrade vtpmd to berlios version 0.7.4
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============4323764241346593571=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a cryptographically signed message in MIME format.

--===============4323764241346593571==
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms010807040300020508080801"

This is a cryptographically signed message in MIME format.

--------------ms010807040300020508080801
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On 09/26/2012 07:46 AM, George Dunlap wrote:
> On Tue, Sep 25, 2012 at 4:50 PM, Matthew Fioravante
> <matthew.fioravante@jhuapl.edu> wrote:
>> I don't know if there is anyone who would want to still use vtpms as
>> processes when the stub domains are now available. Security research
>> people like the domain model because it guarantees a better separation=

>> of components guaranteed by the hypervisor and doesn't have to trust t=
he
>> dom0 OS.
>>
>> If we got rid of the process and hybrid model, then the
>> tools/vtpm_manager code that is still used could be moved into the
>> vtpmmgrdom stubdom codebase. tools/vtpm could be completely removed
>> along with the --enable-vtpm stuff in the configure script and the cma=
ke
>> dependency.
> I haven't had a chance to look at your patches in detail (because the
> few I've looked at have whitespace damage that Ian mentioned before),
> but I as long as the user interface (via xl, config files, &c) is the
> same, or comparable, I don't see any reason not to move entirely over
> the stubdom model; especially if the process or hybrid models are not
> being tested or maintained.
It would also simplify the whole system quite a bit. If I am to maintain
vtpm I'd like to not have to deal with bugs in the old code.

So how should we proceed with this then? Do you all want to remove the
vtpm process/hybrid model entirely now or just deprecate it for a while?
If we deprecate it do you still want my updates for it?

Let me know and I'll provide patches to make it happen either way.

The last piece of this puzzle that I haven't figured out is the linux
tpm frontend driver. Its not in the main linux tree. Its from the old
2006 vtpm code but it still works. I believe it shipped with the old xen
2.6.18 kernel but now I don't know whats happened to it. I still have a
copy we have been porting to newer kernels internally.

Should we try to get it in mainline linux? Or maybe provide it in the
xen tree as an externally compilable kernel module?

There also exists a linux tpm backend driver, but if were only going to
support the domain model that is no longer needed and can go away.
>  -George



--------------ms010807040300020508080801
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIDyjCC
A8YwggMvoAMCAQICBD/xyf0wDQYJKoZIhvcNAQEFBQAwLzELMAkGA1UEBhMCVVMxDzANBgNV
BAoTBkpIVUFQTDEPMA0GA1UECxMGQklTRENBMB4XDTEwMDYxMTE4MjIwNloXDTEzMDYxMTE4
NTIwNlowZjELMAkGA1UEBhMCVVMxDzANBgNVBAoTBkpIVUFQTDEPMA0GA1UECxMGUGVvcGxl
MTUwFgYDVQQLEw9WUE5Hcm91cC1CSVNEQ0EwGwYDVQQDExRNYXR0aGV3IEUgRmlvcmF2YW50
ZTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAnpbwVSP6o1Nb5lcW7dd3yTo9iBJdi7qz
4nANOMFPK7JOy5npKN1iiousl28U/scUJES55gPwAWYJK3uVyQAsA4adgDKi5DoD1UHDQEwp
bY7iHLJeq0NPr4BqYNqnCFPbE6HC8zSJrr4qKn+gVUQT39SIFqdiIPJwZL8FYTRQ/zsCAwEA
AaOCAbYwggGyMAsGA1UdDwQEAwIHgDArBgNVHRAEJDAigA8yMDEwMDYxMTE4MjIwNlqBDzIw
MTIwNzE3MjI1MjA2WjAbBg0rBgEEAbMlCwMBAQEBBAoWCGZpb3JhbWUxMBsGDSsGAQQBsyUL
AwEBAQIEChIIMDAxMDQyNjEwWAYJYIZIAYb6ax4BBEsMSVRoZSBwcml2YXRlIGtleSBjb3Jy
ZXNwb25kaW5nIHRvIHRoaXMgY2VydGlmaWNhdGUgbWF5IGhhdmUgYmVlbiBleHBvcnRlZC4w
KAYDVR0RBCEwH4EdTWF0dGhldy5GaW9yYXZhbnRlQGpodWFwbC5lZHUwUgYDVR0fBEswSTBH
oEWgQ6RBMD8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJU0RD
QTEOMAwGA1UEAxMFQ1JMNTYwHwYDVR0jBBgwFoAUCDUpmxH52EU2CyWmF2EJMB1yqeswHQYD
VR0OBBYEFO6LYxg6r9wHZ+zdQtBHn1dZ/YTNMAkGA1UdEwQCMAAwGQYJKoZIhvZ9B0EABAww
ChsEVjcuMQMCBLAwDQYJKoZIhvcNAQEFBQADgYEAJO9HQh4YNChVLzuZqK5ARJARD8JoujGZ
fdo75quvg2jXFQe2sEjvLnxJZgm/pv8fdZakq48CWwjYHKuvIp7sDjTEsQfo+y7SpN/N2NvJ
WU5SqfK1VgYtNLRRoGJUB5Q1aZ+Dg95g3kqpyfpUMISJL8IKVLtJVfN4fggFVUYZ9wwxggGr
MIIBpwIBATA3MC8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJ
U0RDQQIEP/HJ/TAJBgUrDgMCGgUAoIHLMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ
KoZIhvcNAQkFMQ8XDTEyMDkyNjE0Mzk1N1owIwYJKoZIhvcNAQkEMRYEFFR6OPocJN67psiJ
MAqxT+zYpFB6MGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAK
BggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI
KoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEgYBc367hrKrRi01IHT0HPm7XrOb42FjbhYAl
1CT2LEqnX49Ul/p9gO6lJEiBuHE72vebPHZKsWWdl1Qa3IKEnkOiZ7dN9alLsb0s0UZSycfe
eLPT58PaZvBsl/DGyFla9qFv86c8yeK1qo2jt9RFkARj8Bpjh4y0lnqVaZXZzjJBXwAAAAAA
AA==
--------------ms010807040300020508080801--


--===============4323764241346593571==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============4323764241346593571==--


From xen-devel-bounces@lists.xen.org Wed Sep 26 14:41:37 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Sep 2012 14:41:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGsnn-0000WI-A3; Wed, 26 Sep 2012 14:41:27 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <matthew.fioravante@jhuapl.edu>) id 1TGsnm-0000W3-82
	for xen-devel@lists.xensource.com; Wed, 26 Sep 2012 14:41:26 +0000
Received: from [85.158.139.211:35637] by server-5.bemta-5.messagelabs.com id
	81/F3-21075-51413605; Wed, 26 Sep 2012 14:41:25 +0000
X-Env-Sender: matthew.fioravante@jhuapl.edu
X-Msg-Ref: server-2.tower-206.messagelabs.com!1348670483!20037158!1
X-Originating-IP: [128.244.251.36]
X-SpamReason: No, hits=0.0 required=7.0 tests=UNPARSEABLE_RELAY
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7033 invoked from network); 26 Sep 2012 14:41:24 -0000
Received: from pilot.jhuapl.edu (HELO jhuapl.edu) (128.244.251.36)
	by server-2.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 26 Sep 2012 14:41:24 -0000
Received: from ([128.244.207.89])
	by pilot.jhuapl.edu with ESMTP with TLS id 63GHCH1.153693928;
	Wed, 26 Sep 2012 10:41:16 -0400
Message-ID: <506313BD.7020600@jhuapl.edu>
Date: Wed, 26 Sep 2012 10:39:57 -0400
From: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120827 Thunderbird/15.0
MIME-Version: 1.0
To: George Dunlap <George.Dunlap@eu.citrix.com>
References: <50576368.3070007@jhuapl.edu>
	<1347953926.25803.89.camel@dagon.hellion.org.uk>
	<5058B07C.1070404@jhuapl.edu>
	<1348566822.3452.151.camel@zakaz.uk.xensource.com>
	<5061D2CC.3030108@jhuapl.edu>
	<CAFLBxZYh69025_LHq2qWfQMotincb_pvDtCtiAa7sXCg-RQL6A@mail.gmail.com>
In-Reply-To: <CAFLBxZYh69025_LHq2qWfQMotincb_pvDtCtiAa7sXCg-RQL6A@mail.gmail.com>
X-Enigmail-Version: 1.4.4
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH] Upgrade vtpmd to berlios version 0.7.4
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============4323764241346593571=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a cryptographically signed message in MIME format.

--===============4323764241346593571==
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms010807040300020508080801"

This is a cryptographically signed message in MIME format.

--------------ms010807040300020508080801
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On 09/26/2012 07:46 AM, George Dunlap wrote:
> On Tue, Sep 25, 2012 at 4:50 PM, Matthew Fioravante
> <matthew.fioravante@jhuapl.edu> wrote:
>> I don't know if there is anyone who would want to still use vtpms as
>> processes when the stub domains are now available. Security research
>> people like the domain model because it guarantees a better separation=

>> of components guaranteed by the hypervisor and doesn't have to trust t=
he
>> dom0 OS.
>>
>> If we got rid of the process and hybrid model, then the
>> tools/vtpm_manager code that is still used could be moved into the
>> vtpmmgrdom stubdom codebase. tools/vtpm could be completely removed
>> along with the --enable-vtpm stuff in the configure script and the cma=
ke
>> dependency.
> I haven't had a chance to look at your patches in detail (because the
> few I've looked at have whitespace damage that Ian mentioned before),
> but I as long as the user interface (via xl, config files, &c) is the
> same, or comparable, I don't see any reason not to move entirely over
> the stubdom model; especially if the process or hybrid models are not
> being tested or maintained.
It would also simplify the whole system quite a bit. If I am to maintain
vtpm I'd like to not have to deal with bugs in the old code.

So how should we proceed with this then? Do you all want to remove the
vtpm process/hybrid model entirely now or just deprecate it for a while?
If we deprecate it do you still want my updates for it?

Let me know and I'll provide patches to make it happen either way.

The last piece of this puzzle that I haven't figured out is the linux
tpm frontend driver. Its not in the main linux tree. Its from the old
2006 vtpm code but it still works. I believe it shipped with the old xen
2.6.18 kernel but now I don't know whats happened to it. I still have a
copy we have been porting to newer kernels internally.

Should we try to get it in mainline linux? Or maybe provide it in the
xen tree as an externally compilable kernel module?

There also exists a linux tpm backend driver, but if were only going to
support the domain model that is no longer needed and can go away.
>  -George



--------------ms010807040300020508080801
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIDyjCC
A8YwggMvoAMCAQICBD/xyf0wDQYJKoZIhvcNAQEFBQAwLzELMAkGA1UEBhMCVVMxDzANBgNV
BAoTBkpIVUFQTDEPMA0GA1UECxMGQklTRENBMB4XDTEwMDYxMTE4MjIwNloXDTEzMDYxMTE4
NTIwNlowZjELMAkGA1UEBhMCVVMxDzANBgNVBAoTBkpIVUFQTDEPMA0GA1UECxMGUGVvcGxl
MTUwFgYDVQQLEw9WUE5Hcm91cC1CSVNEQ0EwGwYDVQQDExRNYXR0aGV3IEUgRmlvcmF2YW50
ZTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAnpbwVSP6o1Nb5lcW7dd3yTo9iBJdi7qz
4nANOMFPK7JOy5npKN1iiousl28U/scUJES55gPwAWYJK3uVyQAsA4adgDKi5DoD1UHDQEwp
bY7iHLJeq0NPr4BqYNqnCFPbE6HC8zSJrr4qKn+gVUQT39SIFqdiIPJwZL8FYTRQ/zsCAwEA
AaOCAbYwggGyMAsGA1UdDwQEAwIHgDArBgNVHRAEJDAigA8yMDEwMDYxMTE4MjIwNlqBDzIw
MTIwNzE3MjI1MjA2WjAbBg0rBgEEAbMlCwMBAQEBBAoWCGZpb3JhbWUxMBsGDSsGAQQBsyUL
AwEBAQIEChIIMDAxMDQyNjEwWAYJYIZIAYb6ax4BBEsMSVRoZSBwcml2YXRlIGtleSBjb3Jy
ZXNwb25kaW5nIHRvIHRoaXMgY2VydGlmaWNhdGUgbWF5IGhhdmUgYmVlbiBleHBvcnRlZC4w
KAYDVR0RBCEwH4EdTWF0dGhldy5GaW9yYXZhbnRlQGpodWFwbC5lZHUwUgYDVR0fBEswSTBH
oEWgQ6RBMD8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJU0RD
QTEOMAwGA1UEAxMFQ1JMNTYwHwYDVR0jBBgwFoAUCDUpmxH52EU2CyWmF2EJMB1yqeswHQYD
VR0OBBYEFO6LYxg6r9wHZ+zdQtBHn1dZ/YTNMAkGA1UdEwQCMAAwGQYJKoZIhvZ9B0EABAww
ChsEVjcuMQMCBLAwDQYJKoZIhvcNAQEFBQADgYEAJO9HQh4YNChVLzuZqK5ARJARD8JoujGZ
fdo75quvg2jXFQe2sEjvLnxJZgm/pv8fdZakq48CWwjYHKuvIp7sDjTEsQfo+y7SpN/N2NvJ
WU5SqfK1VgYtNLRRoGJUB5Q1aZ+Dg95g3kqpyfpUMISJL8IKVLtJVfN4fggFVUYZ9wwxggGr
MIIBpwIBATA3MC8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJ
U0RDQQIEP/HJ/TAJBgUrDgMCGgUAoIHLMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ
KoZIhvcNAQkFMQ8XDTEyMDkyNjE0Mzk1N1owIwYJKoZIhvcNAQkEMRYEFFR6OPocJN67psiJ
MAqxT+zYpFB6MGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAK
BggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI
KoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEgYBc367hrKrRi01IHT0HPm7XrOb42FjbhYAl
1CT2LEqnX49Ul/p9gO6lJEiBuHE72vebPHZKsWWdl1Qa3IKEnkOiZ7dN9alLsb0s0UZSycfe
eLPT58PaZvBsl/DGyFla9qFv86c8yeK1qo2jt9RFkARj8Bpjh4y0lnqVaZXZzjJBXwAAAAAA
AA==
--------------ms010807040300020508080801--


--===============4323764241346593571==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============4323764241346593571==--


From xen-devel-bounces@lists.xen.org Wed Sep 26 14:44:09 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Sep 2012 14:44:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGsqI-0000mr-1Y; Wed, 26 Sep 2012 14:44:02 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Wei.Wang2@amd.com>) id 1TGsqG-0000mR-EI
	for xen-devel@lists.xensource.com; Wed, 26 Sep 2012 14:44:00 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1348670632!9160206!1
X-Originating-IP: [216.32.180.31]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20701 invoked from network); 26 Sep 2012 14:43:53 -0000
Received: from va3ehsobe005.messaging.microsoft.com (HELO
	va3outboundpool.messaging.microsoft.com) (216.32.180.31)
	by server-8.tower-27.messagelabs.com with AES128-SHA encrypted SMTP;
	26 Sep 2012 14:43:53 -0000
Received: from mail80-va3-R.bigfish.com (10.7.14.242) by
	VA3EHSOBE002.bigfish.com (10.7.40.22) with Microsoft SMTP Server id
	14.1.225.23; Wed, 26 Sep 2012 14:43:52 +0000
Received: from mail80-va3 (localhost [127.0.0.1])	by mail80-va3-R.bigfish.com
	(Postfix) with ESMTP id 713C9E012C;
	Wed, 26 Sep 2012 14:43: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: -1
X-BigFish: VPS-1(zzc857h4015Izz1202h1d1ah1d2ahzzz2dh668h839he5bhf0ah107ah1288h12a5h12bdh137ah34h1155h)
Received: from mail80-va3 (localhost.localdomain [127.0.0.1]) by mail80-va3
	(MessageSwitch) id 1348670631350563_15262;
	Wed, 26 Sep 2012 14:43:51 +0000 (UTC)
Received: from VA3EHSMHS017.bigfish.com (unknown [10.7.14.243])	by
	mail80-va3.bigfish.com (Postfix) with ESMTP id 5124F60249;
	Wed, 26 Sep 2012 14:43:51 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	VA3EHSMHS017.bigfish.com (10.7.99.27) with Microsoft SMTP Server id
	14.1.225.23; Wed, 26 Sep 2012 14:43:50 +0000
X-WSS-ID: 0MAYOWZ-02-2VA-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 2C50AC8147;	Wed, 26 Sep 2012 09:43:46 -0500 (CDT)
Received: from SAUSEXDAG06.amd.com (163.181.55.7) by sausexedgep01.amd.com
	(163.181.36.54) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Wed, 26 Sep 2012 09:44:00 -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, 26 Sep 2012 09:43:48 -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, 26 Sep 2012
	10:43:44 -0400
Received: from [165.204.15.57] (gran.osrc.amd.com [165.204.15.57])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id 7FFF749C14F; Wed, 26 Sep 2012
	15:43:43 +0100 (BST)
Message-ID: <50631523.3060602@amd.com>
Date: Wed, 26 Sep 2012 16:45:55 +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: "qemu-devel@nongnu.org" <qemu-devel@nongnu.org>
Content-Type: multipart/mixed; boundary="------------080306080505040702010200"
X-OriginatorOrg: amd.com
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: [Xen-devel] [PATCH] Add amd iommu emulation for Xen.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--------------080306080505040702010200
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 7bit

HI,
Attached patch adds amd iommu emulation for Xen. Please review it.
Thanks,
Wei






--------------080306080505040702010200
Content-Type: text/plain; charset="UTF-8";
	name="0001-Add-amd-iommu-emulation-for-Xen.patch"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="0001-Add-amd-iommu-emulation-for-Xen.patch"
Content-Description: 0001-Add-amd-iommu-emulation-for-Xen.patch

RnJvbSAxMjI1MTc0MzU2NDEzODRlNGY1ZTM2ZWFhZDgzMDJmZjI3MzY0OGU4IE1vbiBTZXAg
MTcgMDA6MDA6MDAgMjAwMQpGcm9tOiBXZWkgV2FuZyA8d2VpLndhbmcyQGFtZC5jb20+CkRh
dGU6IFdlZCwgMjYgU2VwIDIwMTIgMTY6NDM6NDAgKzAyMDAKU3ViamVjdDogW1BBVENIXSBB
ZGQgYW1kIGlvbW11IGVtdWxhdGlvbiBmb3IgWGVuLgoKVG8gcGFzc3Rocm91Z2ggYW1kIHNv
dXRoZXJuIGlzbGFuZHMgc2VyaWVzIGdwdSB0byBndWVzdCwgYSB2aXJ0dWFsIGlvbW11IGRl
dmljZSBtdXN0CmJlIHJlZ2lzdGVyZWQgb24gcWVtdSBwY2kgYnVzLiBJdCB1c2VzIGEgbmV3
IGh5cGVyY2FsbCB4Y19kb21haW5fdXBkYXRlX2lvbW11X21zaQp0byBub3RpZnkgeGVuIHRo
ZSBtc2kgdmVjdG9yIG9mIGlvbW11LgoKU2lnbmVkLW9mZi1ieTogV2VpIFdhbmcgPHdlaS53
YW5nMkBhbWQuY29tPgotLS0KIGh3L2kzODYvTWFrZWZpbGUub2JqcyB8ICAgIDIgKy0KIGh3
L3BjX3BpaXguYyAgICAgICAgICB8ICAgIDYgKysKIGh3L3hlbl9pb21tdS5jICAgICAgICB8
ICAxOTEgKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr
KwogaHcveGVuX3B0LmggICAgICAgICAgIHwgICAgMSArCiA0IGZpbGVzIGNoYW5nZWQsIDE5
OSBpbnNlcnRpb25zKCspLCAxIGRlbGV0aW9ucygtKQogY3JlYXRlIG1vZGUgMTAwNjQ0IGh3
L3hlbl9pb21tdS5jCgpkaWZmIC0tZ2l0IGEvaHcvaTM4Ni9NYWtlZmlsZS5vYmpzIGIvaHcv
aTM4Ni9NYWtlZmlsZS5vYmpzCmluZGV4IDhjNzY0YmIuLjhiMjMxYWIgMTAwNjQ0Ci0tLSBh
L2h3L2kzODYvTWFrZWZpbGUub2JqcworKysgYi9ody9pMzg2L01ha2VmaWxlLm9ianMKQEAg
LTgsNyArOCw3IEBAIG9iai15ICs9IHBjX3BpaXgubwogb2JqLXkgKz0gcGNfc3lzZncubwog
b2JqLSQoQ09ORklHX1hFTikgKz0geGVuX3BsYXRmb3JtLm8geGVuX2FwaWMubwogb2JqLSQo
Q09ORklHX1hFTl9QQ0lfUEFTU1RIUk9VR0gpICs9IHhlbi1ob3N0LXBjaS1kZXZpY2Uubwot
b2JqLSQoQ09ORklHX1hFTl9QQ0lfUEFTU1RIUk9VR0gpICs9IHhlbl9wdC5vIHhlbl9wdF9j
b25maWdfaW5pdC5vIHhlbl9wdF9tc2kubworb2JqLSQoQ09ORklHX1hFTl9QQ0lfUEFTU1RI
Uk9VR0gpICs9IHhlbl9wdC5vIHhlbl9wdF9jb25maWdfaW5pdC5vIHhlbl9wdF9tc2kubyB4
ZW5faW9tbXUubwogb2JqLXkgKz0ga3ZtLwogb2JqLSQoQ09ORklHX1NQSUNFKSArPSBxeGwu
byBxeGwtbG9nZ2VyLm8gcXhsLXJlbmRlci5vCiAKZGlmZiAtLWdpdCBhL2h3L3BjX3BpaXgu
YyBiL2h3L3BjX3BpaXguYwppbmRleCBmZDU4OThmLi4wYjVkMDM0IDEwMDY0NAotLS0gYS9o
dy9wY19waWl4LmMKKysrIGIvaHcvcGNfcGlpeC5jCkBAIC00Niw2ICs0Niw5IEBACiAjaWZk
ZWYgQ09ORklHX1hFTgogIyAgaW5jbHVkZSA8eGVuL2h2bS9odm1faW5mb190YWJsZS5oPgog
I2VuZGlmCisjaWZkZWYgQ09ORklHX1hFTl9QQ0lfUEFTU1RIUk9VR0gKKyMgIGluY2x1ZGUg
Inhlbl9wdC5oIgorI2VuZGlmCiAKICNkZWZpbmUgTUFYX0lERV9CVVMgMgogCkBAIC0yMjgs
NiArMjMxLDkgQEAgc3RhdGljIHZvaWQgcGNfaW5pdDEoTWVtb3J5UmVnaW9uICpzeXN0ZW1f
bWVtb3J5LAogICAgIHBjX3ZnYV9pbml0KGlzYV9idXMsIHBjaV9lbmFibGVkID8gcGNpX2J1
cyA6IE5VTEwpOwogICAgIGlmICh4ZW5fZW5hYmxlZCgpKSB7CiAgICAgICAgIHBjaV9jcmVh
dGVfc2ltcGxlKHBjaV9idXMsIC0xLCAieGVuLXBsYXRmb3JtIik7CisjaWZkZWYgQ09ORklH
X1hFTl9QQ0lfUEFTU1RIUk9VR0gKKyAgICAgICAgeGVuX3B0X2lvbW11X2NyZWF0ZShwY2lf
YnVzKTsKKyNlbmRpZgogICAgIH0KIAogICAgIC8qIGluaXQgYmFzaWMgUEMgaGFyZHdhcmUg
Ki8KZGlmZiAtLWdpdCBhL2h3L3hlbl9pb21tdS5jIGIvaHcveGVuX2lvbW11LmMKbmV3IGZp
bGUgbW9kZSAxMDA2NDQKaW5kZXggMDAwMDAwMC4uOWE5ZWRlNAotLS0gL2Rldi9udWxsCisr
KyBiL2h3L3hlbl9pb21tdS5jCkBAIC0wLDAgKzEsMTkxIEBACisvKgorICogYW1kIGlvbW11
IHN1cHBvcnQKKyAqCisgKiBDb3B5cmlnaHQgKEMpIDIwMTIgQWR2YW5jZWQgTWljcm8gRGV2
aWNlcywgSW5jLgorICogQXV0aG9yOiBXZWkgV2FuZyA8d2VpLndhbmcyQGFtZC5jb20+IAor
ICoKKyAqIFRoaXMgd29yayBpcyBsaWNlbnNlZCB1bmRlciB0aGUgdGVybXMgb2YgdGhlIEdO
VSBHUEwsIHZlcnNpb24gMi4gIFNlZQorICogdGhlIENPUFlJTkcgZmlsZSBpbiB0aGUgdG9w
LWxldmVsIGRpcmVjdG9yeS4KKyAqLworCisjaW5jbHVkZSAieGVuX3B0LmgiCisjaW5jbHVk
ZSAieGVuX2JhY2tlbmQuaCIKKworI3ByYWdtYSBwYWNrKDEpCisKK3R5cGVkZWYgc3RydWN0
IGlvbW11X2NhcGFiaWxpdHlfYmxvY2sgeworICAgIHVpbnQ4X3QgICAgIGlkOworICAgIHVp
bnQ4X3QgICAgIG5leHRfcHRyOworICAgIHVpbnQ4X3QgICAgIGNhcF9pbmZvOworICAgIHVp
bnQ4X3QgICAgIGZsYWdzOworICAgIHVpbnQzMl90ICAgIGJhc2VfbG93OworICAgIHVpbnQz
Ml90ICAgIGJhc2VfaGlnaDsKKyAgICB1aW50MzJfdCAgICByYW5nZTsKKyAgICB1aW50MzJf
dCAgICBtaXNjOworfSBpb21tdV9jYXBhYmlsaXR5X3Q7CisKK3R5cGVkZWYgc3RydWN0IG1z
aV9jYXBhYmlsaXR5X2Jsb2NrIHsKKyAgICB1aW50OF90ICAgICBpZDsKKyAgICB1aW50OF90
ICAgICBuZXh0X3B0cjsKKyAgICB1aW50MTZfdCAgICBtc2dfY3RybDsKKyAgICB1aW50MzJf
dCAgICBhZGRyX2xvdzsKKyAgICB1aW50MzJfdCAgICBhZGRyX2hpZ2g7CisgICAgdWludDMy
X3QgICAgbXNpX2RhdGE7Cit9IG1zaV9jYXBhYmlsaXR5X3Q7CisKK3N0cnVjdCBhbWRfaW9t
bXVfY29uZmlnIHsKKyAgICB1aW50MTZfdCAgICB2ZW5kb3JfaWQ7CisgICAgdWludDE2X3Qg
ICAgZGV2aWNlX2lkOworICAgIHVpbnQxNl90ICAgIGNvbW1hbmQ7CisgICAgdWludDE2X3Qg
ICAgc3RhdHVzOworICAgIHVpbnQ4X3QgICAgIHJldmlzaW9uOworICAgIHVpbnQ4X3QgICAg
IGFwaTsKKyAgICB1aW50OF90ICAgICBzdWJjbGFzczsKKyAgICB1aW50OF90ICAgICBjbGFz
czsKKyAgICB1aW50OF90ICAgICBjYWNoZV9saW5lX3NpemU7CisgICAgdWludDhfdCAgICAg
bGF0ZW5jeV90aW1lcjsKKyAgICB1aW50OF90ICAgICBoZWFkZXJfdHlwZTsKKyAgICB1aW50
OF90ICAgICBiaXN0OworICAgIHVpbnQzMl90ICAgIGJhc2VfYWRkcmVzc19yZWdzWzZdOwor
ICAgIHVpbnQzMl90ICAgIHJlc2VydmVkMTsKKyAgICB1aW50MTZfdCAgICBzdWJzeXN0ZW1f
dmVuZG9yX2lkOworICAgIHVpbnQxNl90ICAgIHN1YnN5c3RlbV9pZDsKKyAgICB1aW50MzJf
dCAgICByb21fYWRkcjsKKyAgICB1aW50OF90ICAgICBjYXBfcHRyOworICAgIHVpbnQ4X3Qg
ICAgIHJlc2VydmVkM1szXTsKKyAgICB1aW50MzJfdCAgICByZXNlcnZlZDQ7CisgICAgdWlu
dDhfdCAgICAgaW50ZXJydXB0X2xpbmU7CisgICAgdWludDhfdCAgICAgaW50ZXJydXB0X3Bp
bjsKKyAgICB1aW50OF90ICAgICBtaW5fZ250OworICAgIHVpbnQ4X3QgICAgIG1heF9sYXQ7
CisgICAgaW9tbXVfY2FwYWJpbGl0eV90IGNhcDsKKyAgICBtc2lfY2FwYWJpbGl0eV90ICAg
bXNpOworfTsKKyNwcmFnbWEgcGFjaygpCisKKyNpZm5kZWYgUENJX0NBUF9JRF9TRUMKKyNk
ZWZpbmUgUENJX0NBUF9JRF9TRUMgICAgICAgICAgICAgICAgICAweDBGCisjZW5kaWYKKyNk
ZWZpbmUgUENJX0NMQVNTX1NZU1RFTV9BTURfSU9NTVUgICAgICAweDA4MDYKKyNkZWZpbmUg
UENJX0RFVklDRV9BTURfSU9NTVVfVjIgICAgICAgICAweEZGRkYKKyNkZWZpbmUgSU9NTVVf
Q0FQX0ZMQUdTX0lPVExCICAgICAgICAgICAwCisjZGVmaW5lIElPTU1VX0NBUF9GTEFHU19F
RlJTVVAgICAgICAgICAgMworI2RlZmluZSBJT01NVV9DQVBfVFlQRSAgICAgICAgICAgICAg
ICAgIDB4MworI2RlZmluZSBJT01NVV9DQVBfUkVWICAgICAgICAgICAgICAgICAgIDB4MQor
CisjZGVmaW5lIE1TSV9EQVRBX1ZFQ1RPUl9TSElGVCAgICAgICAgICAwCisjZGVmaW5lIE1T
SV9EQVRBX0RFTElWRVJZX1NISUZUICAgICAgICA4CisjZGVmaW5lIE1TSV9EQVRBX0xFVkVM
X1NISUZUICAgICAgICAgICAxNAorI2RlZmluZSBNU0lfREFUQV9UUklHR0VSX1NISUZUICAg
ICAgICAgMTUKKyNkZWZpbmUgTVNJX0FERFJfREVTVElEX01BU0sgICAgICAgICAgIDB4ZmZm
MDAwMGYKKyNkZWZpbmUgTVNJX0FERFJfREVTVE1PREVfU0hJRlQgICAgICAgIDIKKyNkZWZp
bmUgTVNJX0FERFJfUkVESVJFQ1RJT05fU0hJRlQgICAgIDMKKyNkZWZpbmUgTVNJX1RBUkdF
VF9DUFVfU0hJRlQgICAgICAgICAgIDEyCisjZGVmaW5lIFBDSV9TVEFUVVNfQ0FQQUJJTElU
SUVTICAgICAgICAweDAxMAorCitzdGF0aWMgdm9pZCBhbWRfaW9tbXVfcGNpX3dyaXRlX2Nv
bmZpZyhQQ0lEZXZpY2UgKmQsIHVpbnQzMl90IGFkZHJlc3MsCisgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICB1aW50MzJfdCB2YWwsIGludCBsZW4pCit7CisgICAg
c3RydWN0IGFtZF9pb21tdV9jb25maWcgKmlvbW11X2NvbmZpZzsKKyAgICB1aW50NjRfdCBt
c2lfYWRkcjsKKyAgICB1aW50MzJfdCBtc2lfZGF0YTsKKyAgICB1aW50OF90IG9mZnNldF9t
c2lfZGF0YSwgdmVjdG9yLCBlbjsKKyAgICB1aW50OF90IGRlc3RfbW9kZSwgZGVzdCwgZGVs
aXZlcnlfbW9kZSwgdHJpZ19tb2RlOworCisgICAgcGNpX2RlZmF1bHRfd3JpdGVfY29uZmln
KGQsIGFkZHJlc3MsIHZhbCwgbGVuKTsKKworICAgIGlvbW11X2NvbmZpZyA9IChzdHJ1Y3Qg
YW1kX2lvbW11X2NvbmZpZyAqKWQtPmNvbmZpZzsKKworICAgIG9mZnNldF9tc2lfZGF0YSA9
IGlvbW11X2NvbmZpZy0+Y2FwLm5leHRfcHRyICsgc2l6ZW9mKHVpbnQzMl90KSArCisgICAg
ICAgICAgICAgICAgICAgICAgc2l6ZW9mKHVpbnQ2NF90KTsKKworICAgIGlmICggYWRkcmVz
cyA9PSBvZmZzZXRfbXNpX2RhdGEgKQorICAgIHsKKyAgICAgICAgbXNpX2FkZHIgPSAodWlu
dDY0X3QpaW9tbXVfY29uZmlnLT5tc2kuYWRkcl9oaWdoIDw8IDMyIHwgCisgICAgICAgICAg
ICAgICAgICAgaW9tbXVfY29uZmlnLT5tc2kuYWRkcl9sb3c7CisgICAgICAgIG1zaV9kYXRh
ID0gdmFsOworICAgICAgICB2ZWN0b3IgPSBtc2lfZGF0YSAmIDB4RkY7CisgICAgICAgIGVu
ID0gaW9tbXVfY29uZmlnLT5tc2kubXNnX2N0cmwgJiAweDE7CisgICAgICAgIAorICAgICAg
ICBpZiAoICFlbiApCisgICAgICAgICAgICByZXR1cm47CisKKyAgICAgICAgZGVzdF9tb2Rl
ID0gKG1zaV9hZGRyID4+IE1TSV9BRERSX0RFU1RNT0RFX1NISUZUKSAmIDB4MTsKKyAgICAg
ICAgZGVzdCA9IChtc2lfYWRkciA+PiBNU0lfVEFSR0VUX0NQVV9TSElGVCkgJiAweGZmOwor
ICAgICAgICBkZWxpdmVyeV9tb2RlID0gKG1zaV9kYXRhID4+IE1TSV9EQVRBX0RFTElWRVJZ
X1NISUZUKSAmIDB4NzsKKyAgICAgICAgdHJpZ19tb2RlID0gKG1zaV9kYXRhID4+IE1TSV9E
QVRBX1RSSUdHRVJfU0hJRlQpICYgMHgxOworCisgICAgICAgIHhjX2RvbWFpbl91cGRhdGVf
aW9tbXVfbXNpKHhlbl94YywgeGVuX2RvbWlkLCB2ZWN0b3IsIGRlc3QsIAorICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICBkZXN0X21vZGUsIGRlbGl2ZXJ5X21vZGUsIHRy
aWdfbW9kZSk7CisgICAgfQorfQorCitzdGF0aWMgaW50IGFtZF9pb21tdV9pbml0Zm4oUENJ
RGV2aWNlICpkKQoreworICAgIHN0cnVjdCBhbWRfaW9tbXVfY29uZmlnICpjZmc7CisKKyAg
ICBjZmcgPSAoc3RydWN0IGFtZF9pb21tdV9jb25maWcgKilkLT5jb25maWc7CisKKyAgICBj
ZmctPnN0YXR1cyAgICAgICA9ICAgUENJX1NUQVRVU19DQVBBQklMSVRJRVM7CisgICAgY2Zn
LT5jYXBfcHRyICAgICAgPSAgIHNpemVvZihzdHJ1Y3QgYW1kX2lvbW11X2NvbmZpZykgLSAK
KyAgICAgICAgICAgICAgICAgICAgICAgICAgc2l6ZW9mKGlvbW11X2NhcGFiaWxpdHlfdCkt
IHNpemVvZihtc2lfY2FwYWJpbGl0eV90KTsKKworICAgIGNmZy0+Y2FwLmlkICAgICAgID0g
UENJX0NBUF9JRF9TRUM7CisgICAgY2ZnLT5jYXAuY2FwX2luZm8gPSBJT01NVV9DQVBfUkVW
IDw8IDMgfCBJT01NVV9DQVBfVFlQRTsKKworICAgIGNmZy0+Y2FwLmZsYWdzICAgfD0gMSA8
PCBJT01NVV9DQVBfRkxBR1NfSU9UTEI7CisgICAgY2ZnLT5jYXAuZmxhZ3MgICB8PSAxIDw8
IElPTU1VX0NBUF9GTEFHU19FRlJTVVA7CisKKyAgICBjZmctPmNhcC5uZXh0X3B0ciA9IGNm
Zy0+Y2FwX3B0ciArIHNpemVvZihpb21tdV9jYXBhYmlsaXR5X3QpOworICAgIGNmZy0+bXNp
LmlkICAgICAgID0gUENJX0NBUF9JRF9NU0k7CisgICAgY2ZnLT5tc2kubXNnX2N0cmwgPSBQ
Q0lfTVNJX0ZMQUdTXzY0QklUOworCisgICAgcmV0dXJuIDA7Cit9CisKK3N0YXRpYyB2b2lk
IHhlbl9pb21tdV9jbGFzc19pbml0KE9iamVjdENsYXNzICprbGFzcywgdm9pZCAqZGF0YSkK
K3sKKyAgICBQQ0lEZXZpY2VDbGFzcyAqayA9IFBDSV9ERVZJQ0VfQ0xBU1Moa2xhc3MpOwor
CisgICAgay0+aW5pdCA9IGFtZF9pb21tdV9pbml0Zm47CisgICAgay0+dmVuZG9yX2lkID0g
UENJX1ZFTkRPUl9JRF9BTUQ7CisgICAgay0+ZGV2aWNlX2lkID0gUENJX0RFVklDRV9BTURf
SU9NTVVfVjI7CisgICAgay0+Y2xhc3NfaWQgPSBQQ0lfQ0xBU1NfU1lTVEVNX0FNRF9JT01N
VTsKKyAgICBrLT5zdWJzeXN0ZW1fdmVuZG9yX2lkID0gUENJX1ZFTkRPUl9JRF9BTUQ7Cisg
ICAgay0+c3Vic3lzdGVtX2lkID0gUENJX0RFVklDRV9BTURfSU9NTVVfVjI7CisgICAgay0+
Y29uZmlnX3dyaXRlID0gYW1kX2lvbW11X3BjaV93cml0ZV9jb25maWc7Cit9OworCit0eXBl
ZGVmIHN0cnVjdCBYZW5Jb21tdVN0YXRlIHsKKyAgICBQQ0lEZXZpY2UgZGV2OworfSBYZW5J
b21tdVN0YXRlOworCitzdGF0aWMgVHlwZUluZm8geGVuX2lvbW11X2luZm8gPSB7CisgICAg
Lm5hbWUgPSAieGVuLWlvbW11IiwKKyAgICAucGFyZW50ID0gVFlQRV9QQ0lfREVWSUNFLAor
ICAgIC5pbnN0YW5jZV9zaXplID0gc2l6ZW9mKFhlbklvbW11U3RhdGUpLAorICAgIC5jbGFz
c19pbml0ID0geGVuX2lvbW11X2NsYXNzX2luaXQsCit9OworCitzdGF0aWMgdm9pZCB4ZW5f
aW9tbXVfcmVnaXN0ZXJfdHlwZXModm9pZCkKK3sKKyAgICB0eXBlX3JlZ2lzdGVyX3N0YXRp
YygmeGVuX2lvbW11X2luZm8pOworfQorCit0eXBlX2luaXQoeGVuX2lvbW11X3JlZ2lzdGVy
X3R5cGVzKQorCit2b2lkIHhlbl9wdF9pb21tdV9jcmVhdGUoUENJQnVzICpwY2lfYnVzKQor
eworICAgIGNoYXIgKnBhdGg7CisgICAgY2hhciAqaW9tbXU7CisgICAgc3RydWN0IHhzX2hh
bmRsZSAqeHMgPSB4c19vcGVuKDApOworICAgICAgICAgICAgCisgICAgcGF0aCA9IHhzX2dl
dF9kb21haW5fcGF0aCh4cywgeGVuX2RvbWlkKTsKKyAgICBpb21tdSA9IHhlbnN0b3JlX3Jl
YWRfc3RyKHBhdGgsICJndWVzdF9pb21tdSIpOworICAgIAorICAgIGlmICggIXN0cmNtcChp
b21tdSwgIjEiKSApCisgICAgICAgIHBjaV9jcmVhdGVfc2ltcGxlKHBjaV9idXMsIC0xLCAi
eGVuLWlvbW11Iik7CisgICAgCisgICAgZnJlZShwYXRoKTsKKyAgICB4c19jbG9zZSh4cyk7
Cit9CmRpZmYgLS1naXQgYS9ody94ZW5fcHQuaCBiL2h3L3hlbl9wdC5oCmluZGV4IDExMjQ3
N2EuLmI1NGEwZmIgMTAwNjQ0Ci0tLSBhL2h3L3hlbl9wdC5oCisrKyBiL2h3L3hlbl9wdC5o
CkBAIC0yOTEsNiArMjkxLDcgQEAgdm9pZCB4ZW5fcHRfbXNpeF9kZWxldGUoWGVuUENJUGFz
c3Rocm91Z2hTdGF0ZSAqcyk7CiBpbnQgeGVuX3B0X21zaXhfdXBkYXRlKFhlblBDSVBhc3N0
aHJvdWdoU3RhdGUgKnMpOwogaW50IHhlbl9wdF9tc2l4X3VwZGF0ZV9yZW1hcChYZW5QQ0lQ
YXNzdGhyb3VnaFN0YXRlICpzLCBpbnQgYmFyX2luZGV4KTsKIHZvaWQgeGVuX3B0X21zaXhf
ZGlzYWJsZShYZW5QQ0lQYXNzdGhyb3VnaFN0YXRlICpzKTsKK3ZvaWQgeGVuX3B0X2lvbW11
X2NyZWF0ZShQQ0lCdXMgKnBjaV9idXMpOwogCiBzdGF0aWMgaW5saW5lIGJvb2wgeGVuX3B0
X2hhc19tc2l4X21hcHBpbmcoWGVuUENJUGFzc3Rocm91Z2hTdGF0ZSAqcywgaW50IGJhcikK
IHsKLS0gCjEuNy40Cgo=
--------------080306080505040702010200
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--------------080306080505040702010200--


From xen-devel-bounces@lists.xen.org Wed Sep 26 14:44:09 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Sep 2012 14:44:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGsqI-0000mr-1Y; Wed, 26 Sep 2012 14:44:02 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Wei.Wang2@amd.com>) id 1TGsqG-0000mR-EI
	for xen-devel@lists.xensource.com; Wed, 26 Sep 2012 14:44:00 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1348670632!9160206!1
X-Originating-IP: [216.32.180.31]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20701 invoked from network); 26 Sep 2012 14:43:53 -0000
Received: from va3ehsobe005.messaging.microsoft.com (HELO
	va3outboundpool.messaging.microsoft.com) (216.32.180.31)
	by server-8.tower-27.messagelabs.com with AES128-SHA encrypted SMTP;
	26 Sep 2012 14:43:53 -0000
Received: from mail80-va3-R.bigfish.com (10.7.14.242) by
	VA3EHSOBE002.bigfish.com (10.7.40.22) with Microsoft SMTP Server id
	14.1.225.23; Wed, 26 Sep 2012 14:43:52 +0000
Received: from mail80-va3 (localhost [127.0.0.1])	by mail80-va3-R.bigfish.com
	(Postfix) with ESMTP id 713C9E012C;
	Wed, 26 Sep 2012 14:43: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: -1
X-BigFish: VPS-1(zzc857h4015Izz1202h1d1ah1d2ahzzz2dh668h839he5bhf0ah107ah1288h12a5h12bdh137ah34h1155h)
Received: from mail80-va3 (localhost.localdomain [127.0.0.1]) by mail80-va3
	(MessageSwitch) id 1348670631350563_15262;
	Wed, 26 Sep 2012 14:43:51 +0000 (UTC)
Received: from VA3EHSMHS017.bigfish.com (unknown [10.7.14.243])	by
	mail80-va3.bigfish.com (Postfix) with ESMTP id 5124F60249;
	Wed, 26 Sep 2012 14:43:51 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	VA3EHSMHS017.bigfish.com (10.7.99.27) with Microsoft SMTP Server id
	14.1.225.23; Wed, 26 Sep 2012 14:43:50 +0000
X-WSS-ID: 0MAYOWZ-02-2VA-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 2C50AC8147;	Wed, 26 Sep 2012 09:43:46 -0500 (CDT)
Received: from SAUSEXDAG06.amd.com (163.181.55.7) by sausexedgep01.amd.com
	(163.181.36.54) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Wed, 26 Sep 2012 09:44:00 -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, 26 Sep 2012 09:43:48 -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, 26 Sep 2012
	10:43:44 -0400
Received: from [165.204.15.57] (gran.osrc.amd.com [165.204.15.57])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id 7FFF749C14F; Wed, 26 Sep 2012
	15:43:43 +0100 (BST)
Message-ID: <50631523.3060602@amd.com>
Date: Wed, 26 Sep 2012 16:45:55 +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: "qemu-devel@nongnu.org" <qemu-devel@nongnu.org>
Content-Type: multipart/mixed; boundary="------------080306080505040702010200"
X-OriginatorOrg: amd.com
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: [Xen-devel] [PATCH] Add amd iommu emulation for Xen.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--------------080306080505040702010200
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 7bit

HI,
Attached patch adds amd iommu emulation for Xen. Please review it.
Thanks,
Wei






--------------080306080505040702010200
Content-Type: text/plain; charset="UTF-8";
	name="0001-Add-amd-iommu-emulation-for-Xen.patch"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="0001-Add-amd-iommu-emulation-for-Xen.patch"
Content-Description: 0001-Add-amd-iommu-emulation-for-Xen.patch

RnJvbSAxMjI1MTc0MzU2NDEzODRlNGY1ZTM2ZWFhZDgzMDJmZjI3MzY0OGU4IE1vbiBTZXAg
MTcgMDA6MDA6MDAgMjAwMQpGcm9tOiBXZWkgV2FuZyA8d2VpLndhbmcyQGFtZC5jb20+CkRh
dGU6IFdlZCwgMjYgU2VwIDIwMTIgMTY6NDM6NDAgKzAyMDAKU3ViamVjdDogW1BBVENIXSBB
ZGQgYW1kIGlvbW11IGVtdWxhdGlvbiBmb3IgWGVuLgoKVG8gcGFzc3Rocm91Z2ggYW1kIHNv
dXRoZXJuIGlzbGFuZHMgc2VyaWVzIGdwdSB0byBndWVzdCwgYSB2aXJ0dWFsIGlvbW11IGRl
dmljZSBtdXN0CmJlIHJlZ2lzdGVyZWQgb24gcWVtdSBwY2kgYnVzLiBJdCB1c2VzIGEgbmV3
IGh5cGVyY2FsbCB4Y19kb21haW5fdXBkYXRlX2lvbW11X21zaQp0byBub3RpZnkgeGVuIHRo
ZSBtc2kgdmVjdG9yIG9mIGlvbW11LgoKU2lnbmVkLW9mZi1ieTogV2VpIFdhbmcgPHdlaS53
YW5nMkBhbWQuY29tPgotLS0KIGh3L2kzODYvTWFrZWZpbGUub2JqcyB8ICAgIDIgKy0KIGh3
L3BjX3BpaXguYyAgICAgICAgICB8ICAgIDYgKysKIGh3L3hlbl9pb21tdS5jICAgICAgICB8
ICAxOTEgKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr
KwogaHcveGVuX3B0LmggICAgICAgICAgIHwgICAgMSArCiA0IGZpbGVzIGNoYW5nZWQsIDE5
OSBpbnNlcnRpb25zKCspLCAxIGRlbGV0aW9ucygtKQogY3JlYXRlIG1vZGUgMTAwNjQ0IGh3
L3hlbl9pb21tdS5jCgpkaWZmIC0tZ2l0IGEvaHcvaTM4Ni9NYWtlZmlsZS5vYmpzIGIvaHcv
aTM4Ni9NYWtlZmlsZS5vYmpzCmluZGV4IDhjNzY0YmIuLjhiMjMxYWIgMTAwNjQ0Ci0tLSBh
L2h3L2kzODYvTWFrZWZpbGUub2JqcworKysgYi9ody9pMzg2L01ha2VmaWxlLm9ianMKQEAg
LTgsNyArOCw3IEBAIG9iai15ICs9IHBjX3BpaXgubwogb2JqLXkgKz0gcGNfc3lzZncubwog
b2JqLSQoQ09ORklHX1hFTikgKz0geGVuX3BsYXRmb3JtLm8geGVuX2FwaWMubwogb2JqLSQo
Q09ORklHX1hFTl9QQ0lfUEFTU1RIUk9VR0gpICs9IHhlbi1ob3N0LXBjaS1kZXZpY2Uubwot
b2JqLSQoQ09ORklHX1hFTl9QQ0lfUEFTU1RIUk9VR0gpICs9IHhlbl9wdC5vIHhlbl9wdF9j
b25maWdfaW5pdC5vIHhlbl9wdF9tc2kubworb2JqLSQoQ09ORklHX1hFTl9QQ0lfUEFTU1RI
Uk9VR0gpICs9IHhlbl9wdC5vIHhlbl9wdF9jb25maWdfaW5pdC5vIHhlbl9wdF9tc2kubyB4
ZW5faW9tbXUubwogb2JqLXkgKz0ga3ZtLwogb2JqLSQoQ09ORklHX1NQSUNFKSArPSBxeGwu
byBxeGwtbG9nZ2VyLm8gcXhsLXJlbmRlci5vCiAKZGlmZiAtLWdpdCBhL2h3L3BjX3BpaXgu
YyBiL2h3L3BjX3BpaXguYwppbmRleCBmZDU4OThmLi4wYjVkMDM0IDEwMDY0NAotLS0gYS9o
dy9wY19waWl4LmMKKysrIGIvaHcvcGNfcGlpeC5jCkBAIC00Niw2ICs0Niw5IEBACiAjaWZk
ZWYgQ09ORklHX1hFTgogIyAgaW5jbHVkZSA8eGVuL2h2bS9odm1faW5mb190YWJsZS5oPgog
I2VuZGlmCisjaWZkZWYgQ09ORklHX1hFTl9QQ0lfUEFTU1RIUk9VR0gKKyMgIGluY2x1ZGUg
Inhlbl9wdC5oIgorI2VuZGlmCiAKICNkZWZpbmUgTUFYX0lERV9CVVMgMgogCkBAIC0yMjgs
NiArMjMxLDkgQEAgc3RhdGljIHZvaWQgcGNfaW5pdDEoTWVtb3J5UmVnaW9uICpzeXN0ZW1f
bWVtb3J5LAogICAgIHBjX3ZnYV9pbml0KGlzYV9idXMsIHBjaV9lbmFibGVkID8gcGNpX2J1
cyA6IE5VTEwpOwogICAgIGlmICh4ZW5fZW5hYmxlZCgpKSB7CiAgICAgICAgIHBjaV9jcmVh
dGVfc2ltcGxlKHBjaV9idXMsIC0xLCAieGVuLXBsYXRmb3JtIik7CisjaWZkZWYgQ09ORklH
X1hFTl9QQ0lfUEFTU1RIUk9VR0gKKyAgICAgICAgeGVuX3B0X2lvbW11X2NyZWF0ZShwY2lf
YnVzKTsKKyNlbmRpZgogICAgIH0KIAogICAgIC8qIGluaXQgYmFzaWMgUEMgaGFyZHdhcmUg
Ki8KZGlmZiAtLWdpdCBhL2h3L3hlbl9pb21tdS5jIGIvaHcveGVuX2lvbW11LmMKbmV3IGZp
bGUgbW9kZSAxMDA2NDQKaW5kZXggMDAwMDAwMC4uOWE5ZWRlNAotLS0gL2Rldi9udWxsCisr
KyBiL2h3L3hlbl9pb21tdS5jCkBAIC0wLDAgKzEsMTkxIEBACisvKgorICogYW1kIGlvbW11
IHN1cHBvcnQKKyAqCisgKiBDb3B5cmlnaHQgKEMpIDIwMTIgQWR2YW5jZWQgTWljcm8gRGV2
aWNlcywgSW5jLgorICogQXV0aG9yOiBXZWkgV2FuZyA8d2VpLndhbmcyQGFtZC5jb20+IAor
ICoKKyAqIFRoaXMgd29yayBpcyBsaWNlbnNlZCB1bmRlciB0aGUgdGVybXMgb2YgdGhlIEdO
VSBHUEwsIHZlcnNpb24gMi4gIFNlZQorICogdGhlIENPUFlJTkcgZmlsZSBpbiB0aGUgdG9w
LWxldmVsIGRpcmVjdG9yeS4KKyAqLworCisjaW5jbHVkZSAieGVuX3B0LmgiCisjaW5jbHVk
ZSAieGVuX2JhY2tlbmQuaCIKKworI3ByYWdtYSBwYWNrKDEpCisKK3R5cGVkZWYgc3RydWN0
IGlvbW11X2NhcGFiaWxpdHlfYmxvY2sgeworICAgIHVpbnQ4X3QgICAgIGlkOworICAgIHVp
bnQ4X3QgICAgIG5leHRfcHRyOworICAgIHVpbnQ4X3QgICAgIGNhcF9pbmZvOworICAgIHVp
bnQ4X3QgICAgIGZsYWdzOworICAgIHVpbnQzMl90ICAgIGJhc2VfbG93OworICAgIHVpbnQz
Ml90ICAgIGJhc2VfaGlnaDsKKyAgICB1aW50MzJfdCAgICByYW5nZTsKKyAgICB1aW50MzJf
dCAgICBtaXNjOworfSBpb21tdV9jYXBhYmlsaXR5X3Q7CisKK3R5cGVkZWYgc3RydWN0IG1z
aV9jYXBhYmlsaXR5X2Jsb2NrIHsKKyAgICB1aW50OF90ICAgICBpZDsKKyAgICB1aW50OF90
ICAgICBuZXh0X3B0cjsKKyAgICB1aW50MTZfdCAgICBtc2dfY3RybDsKKyAgICB1aW50MzJf
dCAgICBhZGRyX2xvdzsKKyAgICB1aW50MzJfdCAgICBhZGRyX2hpZ2g7CisgICAgdWludDMy
X3QgICAgbXNpX2RhdGE7Cit9IG1zaV9jYXBhYmlsaXR5X3Q7CisKK3N0cnVjdCBhbWRfaW9t
bXVfY29uZmlnIHsKKyAgICB1aW50MTZfdCAgICB2ZW5kb3JfaWQ7CisgICAgdWludDE2X3Qg
ICAgZGV2aWNlX2lkOworICAgIHVpbnQxNl90ICAgIGNvbW1hbmQ7CisgICAgdWludDE2X3Qg
ICAgc3RhdHVzOworICAgIHVpbnQ4X3QgICAgIHJldmlzaW9uOworICAgIHVpbnQ4X3QgICAg
IGFwaTsKKyAgICB1aW50OF90ICAgICBzdWJjbGFzczsKKyAgICB1aW50OF90ICAgICBjbGFz
czsKKyAgICB1aW50OF90ICAgICBjYWNoZV9saW5lX3NpemU7CisgICAgdWludDhfdCAgICAg
bGF0ZW5jeV90aW1lcjsKKyAgICB1aW50OF90ICAgICBoZWFkZXJfdHlwZTsKKyAgICB1aW50
OF90ICAgICBiaXN0OworICAgIHVpbnQzMl90ICAgIGJhc2VfYWRkcmVzc19yZWdzWzZdOwor
ICAgIHVpbnQzMl90ICAgIHJlc2VydmVkMTsKKyAgICB1aW50MTZfdCAgICBzdWJzeXN0ZW1f
dmVuZG9yX2lkOworICAgIHVpbnQxNl90ICAgIHN1YnN5c3RlbV9pZDsKKyAgICB1aW50MzJf
dCAgICByb21fYWRkcjsKKyAgICB1aW50OF90ICAgICBjYXBfcHRyOworICAgIHVpbnQ4X3Qg
ICAgIHJlc2VydmVkM1szXTsKKyAgICB1aW50MzJfdCAgICByZXNlcnZlZDQ7CisgICAgdWlu
dDhfdCAgICAgaW50ZXJydXB0X2xpbmU7CisgICAgdWludDhfdCAgICAgaW50ZXJydXB0X3Bp
bjsKKyAgICB1aW50OF90ICAgICBtaW5fZ250OworICAgIHVpbnQ4X3QgICAgIG1heF9sYXQ7
CisgICAgaW9tbXVfY2FwYWJpbGl0eV90IGNhcDsKKyAgICBtc2lfY2FwYWJpbGl0eV90ICAg
bXNpOworfTsKKyNwcmFnbWEgcGFjaygpCisKKyNpZm5kZWYgUENJX0NBUF9JRF9TRUMKKyNk
ZWZpbmUgUENJX0NBUF9JRF9TRUMgICAgICAgICAgICAgICAgICAweDBGCisjZW5kaWYKKyNk
ZWZpbmUgUENJX0NMQVNTX1NZU1RFTV9BTURfSU9NTVUgICAgICAweDA4MDYKKyNkZWZpbmUg
UENJX0RFVklDRV9BTURfSU9NTVVfVjIgICAgICAgICAweEZGRkYKKyNkZWZpbmUgSU9NTVVf
Q0FQX0ZMQUdTX0lPVExCICAgICAgICAgICAwCisjZGVmaW5lIElPTU1VX0NBUF9GTEFHU19F
RlJTVVAgICAgICAgICAgMworI2RlZmluZSBJT01NVV9DQVBfVFlQRSAgICAgICAgICAgICAg
ICAgIDB4MworI2RlZmluZSBJT01NVV9DQVBfUkVWICAgICAgICAgICAgICAgICAgIDB4MQor
CisjZGVmaW5lIE1TSV9EQVRBX1ZFQ1RPUl9TSElGVCAgICAgICAgICAwCisjZGVmaW5lIE1T
SV9EQVRBX0RFTElWRVJZX1NISUZUICAgICAgICA4CisjZGVmaW5lIE1TSV9EQVRBX0xFVkVM
X1NISUZUICAgICAgICAgICAxNAorI2RlZmluZSBNU0lfREFUQV9UUklHR0VSX1NISUZUICAg
ICAgICAgMTUKKyNkZWZpbmUgTVNJX0FERFJfREVTVElEX01BU0sgICAgICAgICAgIDB4ZmZm
MDAwMGYKKyNkZWZpbmUgTVNJX0FERFJfREVTVE1PREVfU0hJRlQgICAgICAgIDIKKyNkZWZp
bmUgTVNJX0FERFJfUkVESVJFQ1RJT05fU0hJRlQgICAgIDMKKyNkZWZpbmUgTVNJX1RBUkdF
VF9DUFVfU0hJRlQgICAgICAgICAgIDEyCisjZGVmaW5lIFBDSV9TVEFUVVNfQ0FQQUJJTElU
SUVTICAgICAgICAweDAxMAorCitzdGF0aWMgdm9pZCBhbWRfaW9tbXVfcGNpX3dyaXRlX2Nv
bmZpZyhQQ0lEZXZpY2UgKmQsIHVpbnQzMl90IGFkZHJlc3MsCisgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICB1aW50MzJfdCB2YWwsIGludCBsZW4pCit7CisgICAg
c3RydWN0IGFtZF9pb21tdV9jb25maWcgKmlvbW11X2NvbmZpZzsKKyAgICB1aW50NjRfdCBt
c2lfYWRkcjsKKyAgICB1aW50MzJfdCBtc2lfZGF0YTsKKyAgICB1aW50OF90IG9mZnNldF9t
c2lfZGF0YSwgdmVjdG9yLCBlbjsKKyAgICB1aW50OF90IGRlc3RfbW9kZSwgZGVzdCwgZGVs
aXZlcnlfbW9kZSwgdHJpZ19tb2RlOworCisgICAgcGNpX2RlZmF1bHRfd3JpdGVfY29uZmln
KGQsIGFkZHJlc3MsIHZhbCwgbGVuKTsKKworICAgIGlvbW11X2NvbmZpZyA9IChzdHJ1Y3Qg
YW1kX2lvbW11X2NvbmZpZyAqKWQtPmNvbmZpZzsKKworICAgIG9mZnNldF9tc2lfZGF0YSA9
IGlvbW11X2NvbmZpZy0+Y2FwLm5leHRfcHRyICsgc2l6ZW9mKHVpbnQzMl90KSArCisgICAg
ICAgICAgICAgICAgICAgICAgc2l6ZW9mKHVpbnQ2NF90KTsKKworICAgIGlmICggYWRkcmVz
cyA9PSBvZmZzZXRfbXNpX2RhdGEgKQorICAgIHsKKyAgICAgICAgbXNpX2FkZHIgPSAodWlu
dDY0X3QpaW9tbXVfY29uZmlnLT5tc2kuYWRkcl9oaWdoIDw8IDMyIHwgCisgICAgICAgICAg
ICAgICAgICAgaW9tbXVfY29uZmlnLT5tc2kuYWRkcl9sb3c7CisgICAgICAgIG1zaV9kYXRh
ID0gdmFsOworICAgICAgICB2ZWN0b3IgPSBtc2lfZGF0YSAmIDB4RkY7CisgICAgICAgIGVu
ID0gaW9tbXVfY29uZmlnLT5tc2kubXNnX2N0cmwgJiAweDE7CisgICAgICAgIAorICAgICAg
ICBpZiAoICFlbiApCisgICAgICAgICAgICByZXR1cm47CisKKyAgICAgICAgZGVzdF9tb2Rl
ID0gKG1zaV9hZGRyID4+IE1TSV9BRERSX0RFU1RNT0RFX1NISUZUKSAmIDB4MTsKKyAgICAg
ICAgZGVzdCA9IChtc2lfYWRkciA+PiBNU0lfVEFSR0VUX0NQVV9TSElGVCkgJiAweGZmOwor
ICAgICAgICBkZWxpdmVyeV9tb2RlID0gKG1zaV9kYXRhID4+IE1TSV9EQVRBX0RFTElWRVJZ
X1NISUZUKSAmIDB4NzsKKyAgICAgICAgdHJpZ19tb2RlID0gKG1zaV9kYXRhID4+IE1TSV9E
QVRBX1RSSUdHRVJfU0hJRlQpICYgMHgxOworCisgICAgICAgIHhjX2RvbWFpbl91cGRhdGVf
aW9tbXVfbXNpKHhlbl94YywgeGVuX2RvbWlkLCB2ZWN0b3IsIGRlc3QsIAorICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICBkZXN0X21vZGUsIGRlbGl2ZXJ5X21vZGUsIHRy
aWdfbW9kZSk7CisgICAgfQorfQorCitzdGF0aWMgaW50IGFtZF9pb21tdV9pbml0Zm4oUENJ
RGV2aWNlICpkKQoreworICAgIHN0cnVjdCBhbWRfaW9tbXVfY29uZmlnICpjZmc7CisKKyAg
ICBjZmcgPSAoc3RydWN0IGFtZF9pb21tdV9jb25maWcgKilkLT5jb25maWc7CisKKyAgICBj
ZmctPnN0YXR1cyAgICAgICA9ICAgUENJX1NUQVRVU19DQVBBQklMSVRJRVM7CisgICAgY2Zn
LT5jYXBfcHRyICAgICAgPSAgIHNpemVvZihzdHJ1Y3QgYW1kX2lvbW11X2NvbmZpZykgLSAK
KyAgICAgICAgICAgICAgICAgICAgICAgICAgc2l6ZW9mKGlvbW11X2NhcGFiaWxpdHlfdCkt
IHNpemVvZihtc2lfY2FwYWJpbGl0eV90KTsKKworICAgIGNmZy0+Y2FwLmlkICAgICAgID0g
UENJX0NBUF9JRF9TRUM7CisgICAgY2ZnLT5jYXAuY2FwX2luZm8gPSBJT01NVV9DQVBfUkVW
IDw8IDMgfCBJT01NVV9DQVBfVFlQRTsKKworICAgIGNmZy0+Y2FwLmZsYWdzICAgfD0gMSA8
PCBJT01NVV9DQVBfRkxBR1NfSU9UTEI7CisgICAgY2ZnLT5jYXAuZmxhZ3MgICB8PSAxIDw8
IElPTU1VX0NBUF9GTEFHU19FRlJTVVA7CisKKyAgICBjZmctPmNhcC5uZXh0X3B0ciA9IGNm
Zy0+Y2FwX3B0ciArIHNpemVvZihpb21tdV9jYXBhYmlsaXR5X3QpOworICAgIGNmZy0+bXNp
LmlkICAgICAgID0gUENJX0NBUF9JRF9NU0k7CisgICAgY2ZnLT5tc2kubXNnX2N0cmwgPSBQ
Q0lfTVNJX0ZMQUdTXzY0QklUOworCisgICAgcmV0dXJuIDA7Cit9CisKK3N0YXRpYyB2b2lk
IHhlbl9pb21tdV9jbGFzc19pbml0KE9iamVjdENsYXNzICprbGFzcywgdm9pZCAqZGF0YSkK
K3sKKyAgICBQQ0lEZXZpY2VDbGFzcyAqayA9IFBDSV9ERVZJQ0VfQ0xBU1Moa2xhc3MpOwor
CisgICAgay0+aW5pdCA9IGFtZF9pb21tdV9pbml0Zm47CisgICAgay0+dmVuZG9yX2lkID0g
UENJX1ZFTkRPUl9JRF9BTUQ7CisgICAgay0+ZGV2aWNlX2lkID0gUENJX0RFVklDRV9BTURf
SU9NTVVfVjI7CisgICAgay0+Y2xhc3NfaWQgPSBQQ0lfQ0xBU1NfU1lTVEVNX0FNRF9JT01N
VTsKKyAgICBrLT5zdWJzeXN0ZW1fdmVuZG9yX2lkID0gUENJX1ZFTkRPUl9JRF9BTUQ7Cisg
ICAgay0+c3Vic3lzdGVtX2lkID0gUENJX0RFVklDRV9BTURfSU9NTVVfVjI7CisgICAgay0+
Y29uZmlnX3dyaXRlID0gYW1kX2lvbW11X3BjaV93cml0ZV9jb25maWc7Cit9OworCit0eXBl
ZGVmIHN0cnVjdCBYZW5Jb21tdVN0YXRlIHsKKyAgICBQQ0lEZXZpY2UgZGV2OworfSBYZW5J
b21tdVN0YXRlOworCitzdGF0aWMgVHlwZUluZm8geGVuX2lvbW11X2luZm8gPSB7CisgICAg
Lm5hbWUgPSAieGVuLWlvbW11IiwKKyAgICAucGFyZW50ID0gVFlQRV9QQ0lfREVWSUNFLAor
ICAgIC5pbnN0YW5jZV9zaXplID0gc2l6ZW9mKFhlbklvbW11U3RhdGUpLAorICAgIC5jbGFz
c19pbml0ID0geGVuX2lvbW11X2NsYXNzX2luaXQsCit9OworCitzdGF0aWMgdm9pZCB4ZW5f
aW9tbXVfcmVnaXN0ZXJfdHlwZXModm9pZCkKK3sKKyAgICB0eXBlX3JlZ2lzdGVyX3N0YXRp
YygmeGVuX2lvbW11X2luZm8pOworfQorCit0eXBlX2luaXQoeGVuX2lvbW11X3JlZ2lzdGVy
X3R5cGVzKQorCit2b2lkIHhlbl9wdF9pb21tdV9jcmVhdGUoUENJQnVzICpwY2lfYnVzKQor
eworICAgIGNoYXIgKnBhdGg7CisgICAgY2hhciAqaW9tbXU7CisgICAgc3RydWN0IHhzX2hh
bmRsZSAqeHMgPSB4c19vcGVuKDApOworICAgICAgICAgICAgCisgICAgcGF0aCA9IHhzX2dl
dF9kb21haW5fcGF0aCh4cywgeGVuX2RvbWlkKTsKKyAgICBpb21tdSA9IHhlbnN0b3JlX3Jl
YWRfc3RyKHBhdGgsICJndWVzdF9pb21tdSIpOworICAgIAorICAgIGlmICggIXN0cmNtcChp
b21tdSwgIjEiKSApCisgICAgICAgIHBjaV9jcmVhdGVfc2ltcGxlKHBjaV9idXMsIC0xLCAi
eGVuLWlvbW11Iik7CisgICAgCisgICAgZnJlZShwYXRoKTsKKyAgICB4c19jbG9zZSh4cyk7
Cit9CmRpZmYgLS1naXQgYS9ody94ZW5fcHQuaCBiL2h3L3hlbl9wdC5oCmluZGV4IDExMjQ3
N2EuLmI1NGEwZmIgMTAwNjQ0Ci0tLSBhL2h3L3hlbl9wdC5oCisrKyBiL2h3L3hlbl9wdC5o
CkBAIC0yOTEsNiArMjkxLDcgQEAgdm9pZCB4ZW5fcHRfbXNpeF9kZWxldGUoWGVuUENJUGFz
c3Rocm91Z2hTdGF0ZSAqcyk7CiBpbnQgeGVuX3B0X21zaXhfdXBkYXRlKFhlblBDSVBhc3N0
aHJvdWdoU3RhdGUgKnMpOwogaW50IHhlbl9wdF9tc2l4X3VwZGF0ZV9yZW1hcChYZW5QQ0lQ
YXNzdGhyb3VnaFN0YXRlICpzLCBpbnQgYmFyX2luZGV4KTsKIHZvaWQgeGVuX3B0X21zaXhf
ZGlzYWJsZShYZW5QQ0lQYXNzdGhyb3VnaFN0YXRlICpzKTsKK3ZvaWQgeGVuX3B0X2lvbW11
X2NyZWF0ZShQQ0lCdXMgKnBjaV9idXMpOwogCiBzdGF0aWMgaW5saW5lIGJvb2wgeGVuX3B0
X2hhc19tc2l4X21hcHBpbmcoWGVuUENJUGFzc3Rocm91Z2hTdGF0ZSAqcywgaW50IGJhcikK
IHsKLS0gCjEuNy40Cgo=
--------------080306080505040702010200
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--------------080306080505040702010200--


From xen-devel-bounces@lists.xen.org Wed Sep 26 14:44:56 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Sep 2012 14:44:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGsr2-000151-Vn; Wed, 26 Sep 2012 14:44:48 +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 1TGsr1-00014h-UZ
	for xen-devel@lists.xen.org; Wed, 26 Sep 2012 14:44:48 +0000
Received: from [85.158.139.83:52809] by server-12.bemta-5.messagelabs.com id
	7F/8B-20729-FD413605; Wed, 26 Sep 2012 14:44:47 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1348670684!18149254!1
X-Originating-IP: [216.32.180.14]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26557 invoked from network); 26 Sep 2012 14:44:45 -0000
Received: from va3ehsobe004.messaging.microsoft.com (HELO
	va3outboundpool.messaging.microsoft.com) (216.32.180.14)
	by server-8.tower-182.messagelabs.com with AES128-SHA encrypted SMTP;
	26 Sep 2012 14:44:45 -0000
Received: from mail218-va3-R.bigfish.com (10.7.14.252) by
	VA3EHSOBE004.bigfish.com (10.7.40.24) with Microsoft SMTP Server id
	14.1.225.23; Wed, 26 Sep 2012 14:44:44 +0000
Received: from mail218-va3 (localhost [127.0.0.1])	by
	mail218-va3-R.bigfish.com (Postfix) with ESMTP id 56F8F9A0215;
	Wed, 26 Sep 2012 14:44: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: 0
X-BigFish: VPS0(zzc857hzz1202h1d1ah1d2ahzzz2dh668h839he5bhf0ah107ah1288h12a5h12bdh137ah34h1155h)
Received: from mail218-va3 (localhost.localdomain [127.0.0.1]) by mail218-va3
	(MessageSwitch) id 134867068276376_13411;
	Wed, 26 Sep 2012 14:44:42 +0000 (UTC)
Received: from VA3EHSMHS006.bigfish.com (unknown [10.7.14.239])	by
	mail218-va3.bigfish.com (Postfix) with ESMTP id 0350BD8004C;
	Wed, 26 Sep 2012 14:44:42 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	VA3EHSMHS006.bigfish.com (10.7.99.16) with Microsoft SMTP Server id
	14.1.225.23; Wed, 26 Sep 2012 14:44:38 +0000
X-WSS-ID: 0MAYOYA-02-2XN-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 28602C8004;	Wed, 26 Sep 2012 09:44:33 -0500 (CDT)
Received: from SAUSEXDAG05.amd.com (163.181.55.6) by sausexedgep02.amd.com
	(163.181.36.59) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Wed, 26 Sep 2012 09:44:47 -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;
	Wed, 26 Sep 2012 09:44:34 -0500
Received: from gwo.osrc.amd.com (165.204.16.204) by storexhtp01.amd.com
	(172.24.4.3) with Microsoft SMTP Server id 8.3.213.0; Wed, 26 Sep 2012
	10:44:33 -0400
Received: from [165.204.15.57] (gran.osrc.amd.com [165.204.15.57])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id 7530249C14F; Wed, 26 Sep 2012
	15:44:32 +0100 (BST)
Message-ID: <50631554.1080100@amd.com>
Date: Wed, 26 Sep 2012 16:46: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: xen-devel <xen-devel@lists.xen.org>, Ian Campbell
	<Ian.Campbell@citrix.com>, Ian Jackson <Ian.Jackson@eu.citrix.com>, Jan
	Beulich <JBeulich@suse.com>, Keir Fraser <keir@xen.org>
Content-Type: multipart/mixed; boundary="------------040102030109070306030606"
X-OriginatorOrg: amd.com
Subject: [Xen-devel] [PATCH 1 of 6 V6] amd iommu: Add 2 hypercalls for libxc
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--------------040102030109070306030606
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 7bit





--------------040102030109070306030606
Content-Type: text/plain; charset="UTF-8";
	name="0001-amd-iommu-Add-2-hypercalls-for-libxc.patch"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="0001-amd-iommu-Add-2-hypercalls-for-libxc.patch"
Content-Description: 0001-amd-iommu-Add-2-hypercalls-for-libxc.patch

RnJvbSBhZjViMzAyZGQ0NjBhZjEyZTAzYWFhMTcyYTlhYTg3ZDBmMWNmZmY1IE1vbiBTZXAg
MTcgMDA6MDA6MDAgMjAwMQpGcm9tOiBXZWkgV2FuZyA8d2VpLndhbmcyQGFtZC5jb20+CkRh
dGU6IFdlZCwgMjYgU2VwIDIwMTIgMTE6NDI6NDEgKzAyMDAKU3ViamVjdDogW1BBVENIIDEv
Nl0gYW1kIGlvbW11OiBBZGQgMiBoeXBlcmNhbGxzIGZvciBsaWJ4YwoKaW9tbXVfc2V0X21z
aTogdXNlZCBieSBxZW11IHRvIGluZm9ybSBoeXBlcnZpc29yIGlvbW11IHZlY3RvciBudW1i
ZXIgaW4KZ3Vlc3Qgc3BhY2UuIEh5cGVydmlzb3IgbmVlZHMgdGhpcyB2ZWN0b3IgdG8gaW5q
ZWN0IG1zaSBpbnRvIGd1ZXN0IGFmdGVyCndyaXRpbmcgUFBSIGxvZ3MgYmFjayB0byBndWVz
dC4KCmlvbW11X2JpbmRfYmRmOiB1c2VkIGJ5IHhsIHRvIGJpbmQgdmlydHVhbCBiZGYgdG8g
bWFjaGluZSBiZGYgZm9yIHBhc3N0aHJ1CmRldmljZXMuIElPTU1VIGVtdWxhdG9yIHJlY2Vp
dmVzIGlvbW11IGNtZCBmcm9tIGd1ZXN0IE9TIGFuZCB0aGVuIGZvcndhcmRzCnRoZW0gdG8g
aG9zdCBpb21tdS4gVmlydHVhbCBkZXZpY2UgaWRzIGluIGd1ZXN0IGlvbW11IGNvbW1hbmRz
IG11c3QgYmUKY29udmVydGVkIGludG8gcGh5c2ljYWwgaWRzIGJlZm9yZSBzZW5kaW5nIHRo
ZW0gdG8gcmVhbCBoYXJkd2FyZS4KClNpZ25lZC1vZmYtYnk6IFdlaSBXYW5nIDx3ZWkud2Fu
ZzJAYW1kLmNvbT4KLS0tCiB4ZW4vZHJpdmVycy9wYXNzdGhyb3VnaC9hbWQvaW9tbXVfZ3Vl
c3QuYyB8ICAgNzYgKysrKysrKysrKysrKysrKysrKysrKysrKy0tLQogeGVuL2RyaXZlcnMv
cGFzc3Rocm91Z2gvaW9tbXUuYyAgICAgICAgICAgfCAgIDM0ICsrKysrKysrKysrKysKIHhl
bi9pbmNsdWRlL3B1YmxpYy9kb21jdGwuaCAgICAgICAgICAgICAgIHwgICAyNyArKysrKysr
KysrCiB4ZW4vaW5jbHVkZS94ZW4vaW9tbXUuaCAgICAgICAgICAgICAgICAgICB8ICAgIDUg
KysKIHhlbi9pbmNsdWRlL3hlbi9wY2kuaCAgICAgICAgICAgICAgICAgICAgIHwgICAgNSAr
KwogNSBmaWxlcyBjaGFuZ2VkLCAxMzggaW5zZXJ0aW9ucygrKSwgOSBkZWxldGlvbnMoLSkK
CmRpZmYgLS1naXQgYS94ZW4vZHJpdmVycy9wYXNzdGhyb3VnaC9hbWQvaW9tbXVfZ3Vlc3Qu
YyBiL3hlbi9kcml2ZXJzL3Bhc3N0aHJvdWdoL2FtZC9pb21tdV9ndWVzdC5jCmluZGV4IGUy
ZGFmMGUuLmZhYzJmZjYgMTAwNjQ0Ci0tLSBhL3hlbi9kcml2ZXJzL3Bhc3N0aHJvdWdoL2Ft
ZC9pb21tdV9ndWVzdC5jCisrKyBiL3hlbi9kcml2ZXJzL3Bhc3N0aHJvdWdoL2FtZC9pb21t
dV9ndWVzdC5jCkBAIC00OCwxNCArNDgsMzEgQEAKICAgICAgICAgKHJlZyktPmhpID0gKHZh
bCkgPj4gMzI7IFwKICAgICB9IHdoaWxlICgwKQogCi1zdGF0aWMgdW5zaWduZWQgaW50IG1h
Y2hpbmVfYmRmKHN0cnVjdCBkb21haW4gKmQsIHVpbnQxNl90IGd1ZXN0X2JkZikKK3N0YXRp
YyB1bnNpZ25lZCBpbnQgbWFjaGluZV9iZGYoc3RydWN0IGRvbWFpbiAqZCwgdWludDE2X3Qg
Z3Vlc3Rfc2VnLAorICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB1aW50MTZfdCBn
dWVzdF9iZGYpCiB7Ci0gICAgcmV0dXJuIGd1ZXN0X2JkZjsKKyAgICBzdHJ1Y3QgcGNpX2Rl
diAqcGRldjsKKyAgICB1aW50MTZfdCBtYmRmID0gMDsKKworICAgIGZvcl9lYWNoX3BkZXYo
IGQsIHBkZXYgKQorICAgIHsKKyAgICAgICAgaWYgKCAocGRldi0+Z2JkZiA9PSBndWVzdF9i
ZGYpICYmIChwZGV2LT5nc2VnID09IGd1ZXN0X3NlZykgKQorICAgICAgICB7CisgICAgICAg
ICAgICBtYmRmID0gUENJX0JERjIocGRldi0+YnVzLCBwZGV2LT5kZXZmbik7CisgICAgICAg
ICAgICBicmVhazsKKyAgICAgICAgfQorICAgIH0KKyAgICByZXR1cm4gbWJkZjsKIH0KIAot
c3RhdGljIHVpbnQxNl90IGd1ZXN0X2JkZihzdHJ1Y3QgZG9tYWluICpkLCB1aW50MTZfdCBt
YWNoaW5lX2JkZikKK3N0YXRpYyB1aW50MTZfdCBndWVzdF9iZGYoc3RydWN0IGRvbWFpbiAq
ZCwgdWludDE2X3QgbWFjaGluZV9zZWcsCisgICAgICAgICAgICAgICAgICAgICAgICAgIHVp
bnQxNl90IG1hY2hpbmVfYmRmKQogewotICAgIHJldHVybiBtYWNoaW5lX2JkZjsKKyAgICBz
dHJ1Y3QgcGNpX2RldiAqcGRldjsKKworICAgIHBkZXYgPSBwY2lfZ2V0X3BkZXZfYnlfZG9t
YWluKGQsIG1hY2hpbmVfc2VnLCBQQ0lfQlVTKG1hY2hpbmVfYmRmKSwKKyAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICBQQ0lfREVWRk4yKG1hY2hpbmVfYmRmKSk7CisgICAg
cmV0dXJuIHBkZXYtPmdiZGY7CiB9CiAKIHN0YXRpYyBpbmxpbmUgc3RydWN0IGd1ZXN0X2lv
bW11ICpkb21haW5faW9tbXUoc3RydWN0IGRvbWFpbiAqZCkKQEAgLTIwNyw3ICsyMjQsNyBA
QCB2b2lkIGd1ZXN0X2lvbW11X2FkZF9wcHJfbG9nKHN0cnVjdCBkb21haW4gKmQsIHUzMiBl
bnRyeVtdKQogICAgIGxvZyA9IGxvZ19iYXNlICsgdGFpbCAlIChQQUdFX1NJWkUgLyBzaXpl
b2YocHByX2VudHJ5X3QpKTsKIAogICAgIC8qIENvbnZlcnQgcGh5c2ljYWwgZGV2aWNlIGlk
IGJhY2sgaW50byB2aXJ0dWFsIGRldmljZSBpZCAqLwotICAgIGdkZXZfaWQgPSBndWVzdF9i
ZGYoZCwgaW9tbXVfZ2V0X2RldmlkX2Zyb21fY21kKGVudHJ5WzBdKSk7CisgICAgZ2Rldl9p
ZCA9IGd1ZXN0X2JkZihkLCAwLCBpb21tdV9nZXRfZGV2aWRfZnJvbV9jbWQoZW50cnlbMF0p
KTsKICAgICBpb21tdV9zZXRfZGV2aWRfdG9fY21kKCZlbnRyeVswXSwgZ2Rldl9pZCk7CiAK
ICAgICBtZW1jcHkobG9nLCBlbnRyeSwgc2l6ZW9mKHBwcl9lbnRyeV90KSk7CkBAIC0yNTYs
NyArMjczLDcgQEAgdm9pZCBndWVzdF9pb21tdV9hZGRfZXZlbnRfbG9nKHN0cnVjdCBkb21h
aW4gKmQsIHUzMiBlbnRyeVtdKQogICAgIGxvZyA9IGxvZ19iYXNlICsgdGFpbCAlIChQQUdF
X1NJWkUgLyBzaXplb2YoZXZlbnRfZW50cnlfdCkpOwogCiAgICAgLyogcmUtd3JpdGUgcGh5
c2ljYWwgZGV2aWNlIGlkIGludG8gdmlydHVhbCBkZXZpY2UgaWQgKi8KLSAgICBkZXZfaWQg
PSBndWVzdF9iZGYoZCwgaW9tbXVfZ2V0X2RldmlkX2Zyb21fY21kKGVudHJ5WzBdKSk7Cisg
ICAgZGV2X2lkID0gZ3Vlc3RfYmRmKGQsIDAsIGlvbW11X2dldF9kZXZpZF9mcm9tX2NtZChl
bnRyeVswXSkpOwogICAgIGlvbW11X3NldF9kZXZpZF90b19jbWQoJmVudHJ5WzBdLCBkZXZf
aWQpOwogICAgIG1lbWNweShsb2csIGVudHJ5LCBzaXplb2YoZXZlbnRfZW50cnlfdCkpOwog
CkBAIC0yNzgsNyArMjk1LDcgQEAgc3RhdGljIGludCBkb19jb21wbGV0ZV9wcHJfcmVxdWVz
dChzdHJ1Y3QgZG9tYWluICpkLCBjbWRfZW50cnlfdCAqY21kKQogICAgIHVpbnQxNl90IGRl
dl9pZDsKICAgICBzdHJ1Y3QgYW1kX2lvbW11ICppb21tdTsKIAotICAgIGRldl9pZCA9IG1h
Y2hpbmVfYmRmKGQsIGlvbW11X2dldF9kZXZpZF9mcm9tX2NtZChjbWQtPmRhdGFbMF0pKTsK
KyAgICBkZXZfaWQgPSBtYWNoaW5lX2JkZihkLCAwLCBpb21tdV9nZXRfZGV2aWRfZnJvbV9j
bWQoY21kLT5kYXRhWzBdKSk7CiAgICAgaW9tbXUgPSBmaW5kX2lvbW11X2Zvcl9kZXZpY2Uo
MCwgZGV2X2lkKTsKIAogICAgIGlmICggIWlvbW11ICkKQEAgLTMzMCw3ICszNDcsNyBAQCBz
dGF0aWMgaW50IGRvX2ludmFsaWRhdGVfaW90bGJfcGFnZXMoc3RydWN0IGRvbWFpbiAqZCwg
Y21kX2VudHJ5X3QgKmNtZCkKICAgICBzdHJ1Y3QgYW1kX2lvbW11ICppb21tdTsKICAgICB1
aW50MTZfdCBkZXZfaWQ7CiAKLSAgICBkZXZfaWQgPSBtYWNoaW5lX2JkZihkLCBpb21tdV9n
ZXRfZGV2aWRfZnJvbV9jbWQoY21kLT5kYXRhWzBdKSk7CisgICAgZGV2X2lkID0gbWFjaGlu
ZV9iZGYoZCwgMCwgaW9tbXVfZ2V0X2RldmlkX2Zyb21fY21kKGNtZC0+ZGF0YVswXSkpOwog
CiAgICAgaW9tbXUgPSBmaW5kX2lvbW11X2Zvcl9kZXZpY2UoMCwgZGV2X2lkKTsKICAgICBp
ZiAoICFpb21tdSApCkBAIC00MDksNyArNDI2LDcgQEAgc3RhdGljIGludCBkb19pbnZhbGlk
YXRlX2R0ZShzdHJ1Y3QgZG9tYWluICpkLCBjbWRfZW50cnlfdCAqY21kKQogCiAgICAgZ19p
b21tdSA9IGRvbWFpbl9pb21tdShkKTsKICAgICBnYmRmID0gaW9tbXVfZ2V0X2RldmlkX2Zy
b21fY21kKGNtZC0+ZGF0YVswXSk7Ci0gICAgbWJkZiA9IG1hY2hpbmVfYmRmKGQsIGdiZGYp
OworICAgIG1iZGYgPSBtYWNoaW5lX2JkZihkLCAwLCBnYmRmKTsKIAogICAgIC8qIEd1ZXN0
IGNhbiBvbmx5IHVwZGF0ZSBEVEVzIGZvciBpdHMgcGFzc3RocnUgZGV2aWNlcyAqLwogICAg
IGlmICggbWJkZiA9PSAwIHx8IGdiZGYgPT0gMCApCkBAIC05MTYsMyArOTMzLDQ0IEBAIGNv
bnN0IHN0cnVjdCBodm1fbW1pb19oYW5kbGVyIGlvbW11X21taW9faGFuZGxlciA9IHsKICAg
ICAucmVhZF9oYW5kbGVyID0gZ3Vlc3RfaW9tbXVfbW1pb19yZWFkLAogICAgIC53cml0ZV9o
YW5kbGVyID0gZ3Vlc3RfaW9tbXVfbW1pb193cml0ZQogfTsKKworLyogaW9tbXUgaHlwZXJj
YWxsIGhhbmRsZXIgKi8KK2ludCBpb21tdV9iaW5kX2JkZihzdHJ1Y3QgZG9tYWluKiBkLCB1
aW50MTZfdCBnc2VnLCB1aW50MTZfdCBnYmRmLAorICAgICAgICAgICAgICAgICAgIHVpbnQx
Nl90IG1zZWcsIHVpbnQxNl90IG1iZGYpCit7CisgICAgc3RydWN0IHBjaV9kZXYgKnBkZXY7
CisgICAgaW50IHJldCA9IC1FTk9ERVY7CisKKyAgICBpZiAoICFpb21tdV9mb3VuZCgpIHx8
ICFpb21tdV9lbmFibGVkIHx8ICFpb21tdXYyX2VuYWJsZWQgKQorICAgICAgICByZXR1cm4g
MDsKKworICAgIHNwaW5fbG9jaygmcGNpZGV2c19sb2NrKTsKKworICAgIGZvcl9lYWNoX3Bk
ZXYoIGQsIHBkZXYgKQorICAgIHsKKyAgICAgICAgaWYgKCAocGRldi0+c2VnICE9IG1zZWcp
IHx8IChwZGV2LT5idXMgIT0gUENJX0JVUyhtYmRmKSApIHx8IAorICAgICAgICAgICAgIChw
ZGV2LT5kZXZmbiAhPSBQQ0lfREVWRk4yKG1iZGYpKSApCisgICAgICAgICAgICBjb250aW51
ZTsKKworICAgICAgICBwZGV2LT5nc2VnID0gZ3NlZzsKKyAgICAgICAgcGRldi0+Z2JkZiA9
IGdiZGY7CisgICAgICAgIHJldCA9IDA7CisgICAgfQorCisgICAgc3Bpbl91bmxvY2soJnBj
aWRldnNfbG9jayk7CisgICAgcmV0dXJuIHJldDsKK30KKwordm9pZCBpb21tdV9zZXRfbXNp
KHN0cnVjdCBkb21haW4qIGQsIHVpbnQ4X3QgdmVjdG9yLCB1aW50OF90IGRlc3QsCisgICAg
ICAgICAgICAgICAgICAgdWludDhfdCBkZXN0X21vZGUsIHVpbnQ4X3QgZGVsaXZlcnlfbW9k
ZSwgdWludDhfdCB0cmlnX21vZGUpCit7CisgICAgc3RydWN0IGd1ZXN0X2lvbW11ICppb21t
dSA9IGRvbWFpbl9pb21tdShkKTsKKworICAgIGlmICggIWlvbW11ICkKKyAgICAgICAgcmV0
dXJuOworCisgICAgaW9tbXUtPm1zaS52ZWN0b3IgPSB2ZWN0b3I7CisgICAgaW9tbXUtPm1z
aS5kZXN0ID0gZGVzdDsKKyAgICBpb21tdS0+bXNpLmRlc3RfbW9kZSA9IGRlc3RfbW9kZTsK
KyAgICBpb21tdS0+bXNpLnRyaWdfbW9kZSA9IHRyaWdfbW9kZTsKK30KZGlmZiAtLWdpdCBh
L3hlbi9kcml2ZXJzL3Bhc3N0aHJvdWdoL2lvbW11LmMgYi94ZW4vZHJpdmVycy9wYXNzdGhy
b3VnaC9pb21tdS5jCmluZGV4IGI0Y2YxNmMuLmY4ZjIzY2IgMTAwNjQ0Ci0tLSBhL3hlbi9k
cml2ZXJzL3Bhc3N0aHJvdWdoL2lvbW11LmMKKysrIGIveGVuL2RyaXZlcnMvcGFzc3Rocm91
Z2gvaW9tbXUuYwpAQCAtNjU2LDYgKzY1Niw0MCBAQCBpbnQgaW9tbXVfZG9fZG9tY3RsKAog
ICAgICAgICBwdXRfZG9tYWluKGQpOwogICAgICAgICBicmVhazsKIAorICAgIGNhc2UgWEVO
X0RPTUNUTF9ndWVzdF9pb21tdV9vcDoKKyAgICB7CisgICAgICAgIHhlbl9kb21jdGxfZ3Vl
c3RfaW9tbXVfb3BfdCAqZ3Vlc3Rfb3A7CisKKyAgICAgICAgaWYgKCB1bmxpa2VseSgoZCA9
IGdldF9kb21haW5fYnlfaWQoZG9tY3RsLT5kb21haW4pKSA9PSBOVUxMKSApCisgICAgICAg
IHsKKyAgICAgICAgICAgIGdkcHJpbnRrKFhFTkxPR19FUlIsCisgICAgICAgICAgICAgICAg
ICAgICJYRU5fRE9NQ1RMX2d1ZXN0X2lvbW11X29wOiBnZXRfZG9tYWluX2J5X2lkKCkgZmFp
bGVkXG4iKTsKKyAgICAgICAgICAgIHJldCA9IC1FSU5WQUw7CisgICAgICAgICAgICBicmVh
azsKKyAgICAgICAgfQorCisgICAgICAgIGd1ZXN0X29wID0gJihkb21jdGwtPnUuZ3Vlc3Rf
aW9tbXVfb3ApOworICAgICAgICBzd2l0Y2ggKCBndWVzdF9vcC0+b3AgKQorICAgICAgICB7
CisgICAgICAgIGNhc2UgWEVOX0RPTUNUTF9HVUVTVF9JT01NVV9PUF9TRVRfTVNJOgorICAg
ICAgICAgICAgIGlvbW11X3NldF9tc2koZCwgZ3Vlc3Rfb3AtPnUubXNpLnZlY3RvciwgCisg
ICAgICAgICAgICAgICAgICAgICAgICAgICBndWVzdF9vcC0+dS5tc2kuZGVzdCwKKyAgICAg
ICAgICAgICAgICAgICAgICAgICAgIGd1ZXN0X29wLT51Lm1zaS5kZXN0X21vZGUsIAorICAg
ICAgICAgICAgICAgICAgICAgICAgICAgZ3Vlc3Rfb3AtPnUubXNpLmRlbGl2ZXJ5X21vZGUs
CisgICAgICAgICAgICAgICAgICAgICAgICAgICBndWVzdF9vcC0+dS5tc2kudHJpZ19tb2Rl
KTsKKyAgICAgICAgICAgICByZXQgPSAwOworICAgICAgICAgICAgIGJyZWFrOworICAgICAg
ICBjYXNlIFhFTl9ET01DVExfR1VFU1RfSU9NTVVfT1BfQklORF9CREY6CisgICAgICAgICAg
ICAgcmV0ID0gaW9tbXVfYmluZF9iZGYoZCwgZ3Vlc3Rfb3AtPnUuYmRmX2JpbmQuZ19zZWcs
CisgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgZ3Vlc3Rfb3AtPnUuYmRmX2Jp
bmQuZ19iZGYsCisgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgZ3Vlc3Rfb3At
PnUuYmRmX2JpbmQubV9zZWcsCisgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
Z3Vlc3Rfb3AtPnUuYmRmX2JpbmQubV9iZGYpOworICAgICAgICAgICAgIGJyZWFrOworICAg
ICAgICB9CisgICAgICAgIHB1dF9kb21haW4oZCk7CisgICAgICAgIGJyZWFrOworICAgIH0K
KwogICAgIGRlZmF1bHQ6CiAgICAgICAgIHJldCA9IC1FTk9TWVM7CiAgICAgICAgIGJyZWFr
OwpkaWZmIC0tZ2l0IGEveGVuL2luY2x1ZGUvcHVibGljL2RvbWN0bC5oIGIveGVuL2luY2x1
ZGUvcHVibGljL2RvbWN0bC5oCmluZGV4IGYzNjdjZTIuLmY3YTViZGEgMTAwNjQ0Ci0tLSBh
L3hlbi9pbmNsdWRlL3B1YmxpYy9kb21jdGwuaAorKysgYi94ZW4vaW5jbHVkZS9wdWJsaWMv
ZG9tY3RsLmgKQEAgLTgyNyw2ICs4MjcsMzEgQEAgc3RydWN0IHhlbl9kb21jdGxfc2V0X2Fj
Y2Vzc19yZXF1aXJlZCB7CiB0eXBlZGVmIHN0cnVjdCB4ZW5fZG9tY3RsX3NldF9hY2Nlc3Nf
cmVxdWlyZWQgeGVuX2RvbWN0bF9zZXRfYWNjZXNzX3JlcXVpcmVkX3Q7CiBERUZJTkVfWEVO
X0dVRVNUX0hBTkRMRSh4ZW5fZG9tY3RsX3NldF9hY2Nlc3NfcmVxdWlyZWRfdCk7CiAKKy8q
IFN1cHBvcnQgZm9yIGd1ZXN0IGlvbW11IGVtdWxhdGlvbiAqLworc3RydWN0IHhlbl9kb21j
dGxfZ3Vlc3RfaW9tbXVfb3AgeworICAgIC8qIFhFTl9ET01DVExfR1VFU1RfSU9NTVVfT1Bf
KiAqLworI2RlZmluZSBYRU5fRE9NQ1RMX0dVRVNUX0lPTU1VX09QX1NFVF9NU0kgICAgICAg
ICAgICAgICAwCisjZGVmaW5lIFhFTl9ET01DVExfR1VFU1RfSU9NTVVfT1BfQklORF9CREYg
ICAgICAgICAgICAgIDEKKyAgICB1aW50OF90IG9wOworICAgIHVuaW9uIHsKKyAgICAgICAg
c3RydWN0IGlvbW11X21zaSB7CisgICAgICAgICAgICB1aW50OF90ICAgICB2ZWN0b3I7Cisg
ICAgICAgICAgICB1aW50OF90ICAgICBkZXN0OworICAgICAgICAgICAgdWludDhfdCAgICAg
ZGVzdF9tb2RlOworICAgICAgICAgICAgdWludDhfdCAgICAgZGVsaXZlcnlfbW9kZTsKKyAg
ICAgICAgICAgIHVpbnQ4X3QgICAgIHRyaWdfbW9kZTsKKyAgICAgICAgfSBtc2k7CisgICAg
ICAgIHN0cnVjdCBiZGZfYmluZCB7CisgICAgICAgICAgICB1aW50MTZfdCAgICBnX3NlZzsK
KyAgICAgICAgICAgIHVpbnQxNl90ICAgIGdfYmRmOworICAgICAgICAgICAgdWludDE2X3Qg
ICAgbV9zZWc7CisgICAgICAgICAgICB1aW50MTZfdCAgICBtX2JkZjsKKyAgICAgICAgfSBi
ZGZfYmluZDsKKyAgICB9IHU7Cit9OwordHlwZWRlZiBzdHJ1Y3QgeGVuX2RvbWN0bF9ndWVz
dF9pb21tdV9vcCB4ZW5fZG9tY3RsX2d1ZXN0X2lvbW11X29wX3Q7CitERUZJTkVfWEVOX0dV
RVNUX0hBTkRMRSh4ZW5fZG9tY3RsX2d1ZXN0X2lvbW11X29wX3QpOworCiBzdHJ1Y3QgeGVu
X2RvbWN0bCB7CiAgICAgdWludDMyX3QgY21kOwogI2RlZmluZSBYRU5fRE9NQ1RMX2NyZWF0
ZWRvbWFpbiAgICAgICAgICAgICAgICAgICAxCkBAIC04OTIsNiArOTE3LDcgQEAgc3RydWN0
IHhlbl9kb21jdGwgewogI2RlZmluZSBYRU5fRE9NQ1RMX3NldF9hY2Nlc3NfcmVxdWlyZWQg
ICAgICAgICAgIDY0CiAjZGVmaW5lIFhFTl9ET01DVExfYXVkaXRfcDJtICAgICAgICAgICAg
ICAgICAgICAgNjUKICNkZWZpbmUgWEVOX0RPTUNUTF9zZXRfdmlycV9oYW5kbGVyICAgICAg
ICAgICAgICA2NgorI2RlZmluZSBYRU5fRE9NQ1RMX2d1ZXN0X2lvbW11X29wICAgICAgICAg
ICAgICAgIDY3CiAjZGVmaW5lIFhFTl9ET01DVExfZ2Ric3hfZ3Vlc3RtZW1pbyAgICAgICAg
ICAgIDEwMDAKICNkZWZpbmUgWEVOX0RPTUNUTF9nZGJzeF9wYXVzZXZjcHUgICAgICAgICAg
ICAgMTAwMQogI2RlZmluZSBYRU5fRE9NQ1RMX2dkYnN4X3VucGF1c2V2Y3B1ICAgICAgICAg
ICAxMDAyCkBAIC05MzksNiArOTY1LDcgQEAgc3RydWN0IHhlbl9kb21jdGwgewogICAgICAg
ICBzdHJ1Y3QgeGVuX2RvbWN0bF9kZWJ1Z19vcCAgICAgICAgICBkZWJ1Z19vcDsKICAgICAg
ICAgc3RydWN0IHhlbl9kb21jdGxfbWVtX2V2ZW50X29wICAgICAgbWVtX2V2ZW50X29wOwog
ICAgICAgICBzdHJ1Y3QgeGVuX2RvbWN0bF9tZW1fc2hhcmluZ19vcCAgICBtZW1fc2hhcmlu
Z19vcDsKKyAgICAgICAgc3RydWN0IHhlbl9kb21jdGxfZ3Vlc3RfaW9tbXVfb3AgICAgZ3Vl
c3RfaW9tbXVfb3A7CiAjaWYgZGVmaW5lZChfX2kzODZfXykgfHwgZGVmaW5lZChfX3g4Nl82
NF9fKQogICAgICAgICBzdHJ1Y3QgeGVuX2RvbWN0bF9jcHVpZCAgICAgICAgICAgICBjcHVp
ZDsKICAgICAgICAgc3RydWN0IHhlbl9kb21jdGxfdmNwdWV4dHN0YXRlICAgICAgdmNwdWV4
dHN0YXRlOwpkaWZmIC0tZ2l0IGEveGVuL2luY2x1ZGUveGVuL2lvbW11LmggYi94ZW4vaW5j
bHVkZS94ZW4vaW9tbXUuaAppbmRleCA2MDVjN2IzLi42MWE2ODFiIDEwMDY0NAotLS0gYS94
ZW4vaW5jbHVkZS94ZW4vaW9tbXUuaAorKysgYi94ZW4vaW5jbHVkZS94ZW4vaW9tbXUuaApA
QCAtMTYxLDYgKzE2MSwxMSBAQCBpbnQgaW9tbXVfZG9fZG9tY3RsKHN0cnVjdCB4ZW5fZG9t
Y3RsICosIFhFTl9HVUVTVF9IQU5ETEUoeGVuX2RvbWN0bF90KSk7CiB2b2lkIGlvbW11X2lv
dGxiX2ZsdXNoKHN0cnVjdCBkb21haW4gKmQsIHVuc2lnbmVkIGxvbmcgZ2ZuLCB1bnNpZ25l
ZCBpbnQgcGFnZV9jb3VudCk7CiB2b2lkIGlvbW11X2lvdGxiX2ZsdXNoX2FsbChzdHJ1Y3Qg
ZG9tYWluICpkKTsKIAorLyogT25seSB1c2VkIGJ5IEFNRCBJT01NVSBzbyBmYXIgKi8KK3Zv
aWQgaW9tbXVfc2V0X21zaShzdHJ1Y3QgZG9tYWluKiBkLCB1aW50OF90IHZlY3RvciwgdWlu
dDhfdCBkZXN0LAorICAgICAgICAgICAgICAgICAgIHVpbnQ4X3QgZGVzdF9tb2RlLCB1aW50
OF90IGRlbGl2ZXJ5X21vZGUsIHVpbnQ4X3QgdHJpZ19tb2RlKTsKK2ludCBpb21tdV9iaW5k
X2JkZihzdHJ1Y3QgZG9tYWluKiBkLCB1aW50MTZfdCBnc2VnLCB1aW50MTZfdCBnYmRmLCAK
KyAgICAgICAgICAgICAgICAgICB1aW50MTZfdCBtc2VnLCB1aW50MTZfdCBtYmRmKTsKIC8q
CiAgKiBUaGUgcHVycG9zZSBvZiB0aGUgaW9tbXVfZG9udF9mbHVzaF9pb3RsYiBvcHRpb25h
bCBjcHUgZmxhZyBpcyB0bwogICogYXZvaWQgdW5lY2Vzc2FyeSBpb3RsYl9mbHVzaCBpbiB0
aGUgbG93IGxldmVsIElPTU1VIGNvZGUuCmRpZmYgLS1naXQgYS94ZW4vaW5jbHVkZS94ZW4v
cGNpLmggYi94ZW4vaW5jbHVkZS94ZW4vcGNpLmgKaW5kZXggMThiN2ZiMS4uODBkZDM3OCAx
MDA2NDQKLS0tIGEveGVuL2luY2x1ZGUveGVuL3BjaS5oCisrKyBiL3hlbi9pbmNsdWRlL3hl
bi9wY2kuaApAQCAtNjIsNiArNjIsMTEgQEAgc3RydWN0IHBjaV9kZXYgewogICAgIGNvbnN0
IHUxNiBzZWc7CiAgICAgY29uc3QgdTggYnVzOwogICAgIGNvbnN0IHU4IGRldmZuOworCisg
ICAgLyogVXNlZCBieSBpb21tdSB0byByZXByZXNlbnQgdmlydHVhbCBzZWcgYW5kIGJkZiB2
YWx1ZSBpbiBndWVzdCBzcGFjZSAqLworICAgIHUxNiBnc2VnOworICAgIHUxNiBnYmRmOwor
CiAgICAgc3RydWN0IHBjaV9kZXZfaW5mbyBpbmZvOwogICAgIHN0cnVjdCBhcmNoX3BjaV9k
ZXYgYXJjaDsKICAgICB1NjQgdmZfcmxlbls2XTsKLS0gCjEuNy40CgoK
--------------040102030109070306030606
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--------------040102030109070306030606--


From xen-devel-bounces@lists.xen.org Wed Sep 26 14:44:56 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Sep 2012 14:44:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGsr2-000151-Vn; Wed, 26 Sep 2012 14:44:48 +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 1TGsr1-00014h-UZ
	for xen-devel@lists.xen.org; Wed, 26 Sep 2012 14:44:48 +0000
Received: from [85.158.139.83:52809] by server-12.bemta-5.messagelabs.com id
	7F/8B-20729-FD413605; Wed, 26 Sep 2012 14:44:47 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1348670684!18149254!1
X-Originating-IP: [216.32.180.14]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26557 invoked from network); 26 Sep 2012 14:44:45 -0000
Received: from va3ehsobe004.messaging.microsoft.com (HELO
	va3outboundpool.messaging.microsoft.com) (216.32.180.14)
	by server-8.tower-182.messagelabs.com with AES128-SHA encrypted SMTP;
	26 Sep 2012 14:44:45 -0000
Received: from mail218-va3-R.bigfish.com (10.7.14.252) by
	VA3EHSOBE004.bigfish.com (10.7.40.24) with Microsoft SMTP Server id
	14.1.225.23; Wed, 26 Sep 2012 14:44:44 +0000
Received: from mail218-va3 (localhost [127.0.0.1])	by
	mail218-va3-R.bigfish.com (Postfix) with ESMTP id 56F8F9A0215;
	Wed, 26 Sep 2012 14:44: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: 0
X-BigFish: VPS0(zzc857hzz1202h1d1ah1d2ahzzz2dh668h839he5bhf0ah107ah1288h12a5h12bdh137ah34h1155h)
Received: from mail218-va3 (localhost.localdomain [127.0.0.1]) by mail218-va3
	(MessageSwitch) id 134867068276376_13411;
	Wed, 26 Sep 2012 14:44:42 +0000 (UTC)
Received: from VA3EHSMHS006.bigfish.com (unknown [10.7.14.239])	by
	mail218-va3.bigfish.com (Postfix) with ESMTP id 0350BD8004C;
	Wed, 26 Sep 2012 14:44:42 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	VA3EHSMHS006.bigfish.com (10.7.99.16) with Microsoft SMTP Server id
	14.1.225.23; Wed, 26 Sep 2012 14:44:38 +0000
X-WSS-ID: 0MAYOYA-02-2XN-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 28602C8004;	Wed, 26 Sep 2012 09:44:33 -0500 (CDT)
Received: from SAUSEXDAG05.amd.com (163.181.55.6) by sausexedgep02.amd.com
	(163.181.36.59) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Wed, 26 Sep 2012 09:44:47 -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;
	Wed, 26 Sep 2012 09:44:34 -0500
Received: from gwo.osrc.amd.com (165.204.16.204) by storexhtp01.amd.com
	(172.24.4.3) with Microsoft SMTP Server id 8.3.213.0; Wed, 26 Sep 2012
	10:44:33 -0400
Received: from [165.204.15.57] (gran.osrc.amd.com [165.204.15.57])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id 7530249C14F; Wed, 26 Sep 2012
	15:44:32 +0100 (BST)
Message-ID: <50631554.1080100@amd.com>
Date: Wed, 26 Sep 2012 16:46: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: xen-devel <xen-devel@lists.xen.org>, Ian Campbell
	<Ian.Campbell@citrix.com>, Ian Jackson <Ian.Jackson@eu.citrix.com>, Jan
	Beulich <JBeulich@suse.com>, Keir Fraser <keir@xen.org>
Content-Type: multipart/mixed; boundary="------------040102030109070306030606"
X-OriginatorOrg: amd.com
Subject: [Xen-devel] [PATCH 1 of 6 V6] amd iommu: Add 2 hypercalls for libxc
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--------------040102030109070306030606
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 7bit





--------------040102030109070306030606
Content-Type: text/plain; charset="UTF-8";
	name="0001-amd-iommu-Add-2-hypercalls-for-libxc.patch"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="0001-amd-iommu-Add-2-hypercalls-for-libxc.patch"
Content-Description: 0001-amd-iommu-Add-2-hypercalls-for-libxc.patch

RnJvbSBhZjViMzAyZGQ0NjBhZjEyZTAzYWFhMTcyYTlhYTg3ZDBmMWNmZmY1IE1vbiBTZXAg
MTcgMDA6MDA6MDAgMjAwMQpGcm9tOiBXZWkgV2FuZyA8d2VpLndhbmcyQGFtZC5jb20+CkRh
dGU6IFdlZCwgMjYgU2VwIDIwMTIgMTE6NDI6NDEgKzAyMDAKU3ViamVjdDogW1BBVENIIDEv
Nl0gYW1kIGlvbW11OiBBZGQgMiBoeXBlcmNhbGxzIGZvciBsaWJ4YwoKaW9tbXVfc2V0X21z
aTogdXNlZCBieSBxZW11IHRvIGluZm9ybSBoeXBlcnZpc29yIGlvbW11IHZlY3RvciBudW1i
ZXIgaW4KZ3Vlc3Qgc3BhY2UuIEh5cGVydmlzb3IgbmVlZHMgdGhpcyB2ZWN0b3IgdG8gaW5q
ZWN0IG1zaSBpbnRvIGd1ZXN0IGFmdGVyCndyaXRpbmcgUFBSIGxvZ3MgYmFjayB0byBndWVz
dC4KCmlvbW11X2JpbmRfYmRmOiB1c2VkIGJ5IHhsIHRvIGJpbmQgdmlydHVhbCBiZGYgdG8g
bWFjaGluZSBiZGYgZm9yIHBhc3N0aHJ1CmRldmljZXMuIElPTU1VIGVtdWxhdG9yIHJlY2Vp
dmVzIGlvbW11IGNtZCBmcm9tIGd1ZXN0IE9TIGFuZCB0aGVuIGZvcndhcmRzCnRoZW0gdG8g
aG9zdCBpb21tdS4gVmlydHVhbCBkZXZpY2UgaWRzIGluIGd1ZXN0IGlvbW11IGNvbW1hbmRz
IG11c3QgYmUKY29udmVydGVkIGludG8gcGh5c2ljYWwgaWRzIGJlZm9yZSBzZW5kaW5nIHRo
ZW0gdG8gcmVhbCBoYXJkd2FyZS4KClNpZ25lZC1vZmYtYnk6IFdlaSBXYW5nIDx3ZWkud2Fu
ZzJAYW1kLmNvbT4KLS0tCiB4ZW4vZHJpdmVycy9wYXNzdGhyb3VnaC9hbWQvaW9tbXVfZ3Vl
c3QuYyB8ICAgNzYgKysrKysrKysrKysrKysrKysrKysrKysrKy0tLQogeGVuL2RyaXZlcnMv
cGFzc3Rocm91Z2gvaW9tbXUuYyAgICAgICAgICAgfCAgIDM0ICsrKysrKysrKysrKysKIHhl
bi9pbmNsdWRlL3B1YmxpYy9kb21jdGwuaCAgICAgICAgICAgICAgIHwgICAyNyArKysrKysr
KysrCiB4ZW4vaW5jbHVkZS94ZW4vaW9tbXUuaCAgICAgICAgICAgICAgICAgICB8ICAgIDUg
KysKIHhlbi9pbmNsdWRlL3hlbi9wY2kuaCAgICAgICAgICAgICAgICAgICAgIHwgICAgNSAr
KwogNSBmaWxlcyBjaGFuZ2VkLCAxMzggaW5zZXJ0aW9ucygrKSwgOSBkZWxldGlvbnMoLSkK
CmRpZmYgLS1naXQgYS94ZW4vZHJpdmVycy9wYXNzdGhyb3VnaC9hbWQvaW9tbXVfZ3Vlc3Qu
YyBiL3hlbi9kcml2ZXJzL3Bhc3N0aHJvdWdoL2FtZC9pb21tdV9ndWVzdC5jCmluZGV4IGUy
ZGFmMGUuLmZhYzJmZjYgMTAwNjQ0Ci0tLSBhL3hlbi9kcml2ZXJzL3Bhc3N0aHJvdWdoL2Ft
ZC9pb21tdV9ndWVzdC5jCisrKyBiL3hlbi9kcml2ZXJzL3Bhc3N0aHJvdWdoL2FtZC9pb21t
dV9ndWVzdC5jCkBAIC00OCwxNCArNDgsMzEgQEAKICAgICAgICAgKHJlZyktPmhpID0gKHZh
bCkgPj4gMzI7IFwKICAgICB9IHdoaWxlICgwKQogCi1zdGF0aWMgdW5zaWduZWQgaW50IG1h
Y2hpbmVfYmRmKHN0cnVjdCBkb21haW4gKmQsIHVpbnQxNl90IGd1ZXN0X2JkZikKK3N0YXRp
YyB1bnNpZ25lZCBpbnQgbWFjaGluZV9iZGYoc3RydWN0IGRvbWFpbiAqZCwgdWludDE2X3Qg
Z3Vlc3Rfc2VnLAorICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB1aW50MTZfdCBn
dWVzdF9iZGYpCiB7Ci0gICAgcmV0dXJuIGd1ZXN0X2JkZjsKKyAgICBzdHJ1Y3QgcGNpX2Rl
diAqcGRldjsKKyAgICB1aW50MTZfdCBtYmRmID0gMDsKKworICAgIGZvcl9lYWNoX3BkZXYo
IGQsIHBkZXYgKQorICAgIHsKKyAgICAgICAgaWYgKCAocGRldi0+Z2JkZiA9PSBndWVzdF9i
ZGYpICYmIChwZGV2LT5nc2VnID09IGd1ZXN0X3NlZykgKQorICAgICAgICB7CisgICAgICAg
ICAgICBtYmRmID0gUENJX0JERjIocGRldi0+YnVzLCBwZGV2LT5kZXZmbik7CisgICAgICAg
ICAgICBicmVhazsKKyAgICAgICAgfQorICAgIH0KKyAgICByZXR1cm4gbWJkZjsKIH0KIAot
c3RhdGljIHVpbnQxNl90IGd1ZXN0X2JkZihzdHJ1Y3QgZG9tYWluICpkLCB1aW50MTZfdCBt
YWNoaW5lX2JkZikKK3N0YXRpYyB1aW50MTZfdCBndWVzdF9iZGYoc3RydWN0IGRvbWFpbiAq
ZCwgdWludDE2X3QgbWFjaGluZV9zZWcsCisgICAgICAgICAgICAgICAgICAgICAgICAgIHVp
bnQxNl90IG1hY2hpbmVfYmRmKQogewotICAgIHJldHVybiBtYWNoaW5lX2JkZjsKKyAgICBz
dHJ1Y3QgcGNpX2RldiAqcGRldjsKKworICAgIHBkZXYgPSBwY2lfZ2V0X3BkZXZfYnlfZG9t
YWluKGQsIG1hY2hpbmVfc2VnLCBQQ0lfQlVTKG1hY2hpbmVfYmRmKSwKKyAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICBQQ0lfREVWRk4yKG1hY2hpbmVfYmRmKSk7CisgICAg
cmV0dXJuIHBkZXYtPmdiZGY7CiB9CiAKIHN0YXRpYyBpbmxpbmUgc3RydWN0IGd1ZXN0X2lv
bW11ICpkb21haW5faW9tbXUoc3RydWN0IGRvbWFpbiAqZCkKQEAgLTIwNyw3ICsyMjQsNyBA
QCB2b2lkIGd1ZXN0X2lvbW11X2FkZF9wcHJfbG9nKHN0cnVjdCBkb21haW4gKmQsIHUzMiBl
bnRyeVtdKQogICAgIGxvZyA9IGxvZ19iYXNlICsgdGFpbCAlIChQQUdFX1NJWkUgLyBzaXpl
b2YocHByX2VudHJ5X3QpKTsKIAogICAgIC8qIENvbnZlcnQgcGh5c2ljYWwgZGV2aWNlIGlk
IGJhY2sgaW50byB2aXJ0dWFsIGRldmljZSBpZCAqLwotICAgIGdkZXZfaWQgPSBndWVzdF9i
ZGYoZCwgaW9tbXVfZ2V0X2RldmlkX2Zyb21fY21kKGVudHJ5WzBdKSk7CisgICAgZ2Rldl9p
ZCA9IGd1ZXN0X2JkZihkLCAwLCBpb21tdV9nZXRfZGV2aWRfZnJvbV9jbWQoZW50cnlbMF0p
KTsKICAgICBpb21tdV9zZXRfZGV2aWRfdG9fY21kKCZlbnRyeVswXSwgZ2Rldl9pZCk7CiAK
ICAgICBtZW1jcHkobG9nLCBlbnRyeSwgc2l6ZW9mKHBwcl9lbnRyeV90KSk7CkBAIC0yNTYs
NyArMjczLDcgQEAgdm9pZCBndWVzdF9pb21tdV9hZGRfZXZlbnRfbG9nKHN0cnVjdCBkb21h
aW4gKmQsIHUzMiBlbnRyeVtdKQogICAgIGxvZyA9IGxvZ19iYXNlICsgdGFpbCAlIChQQUdF
X1NJWkUgLyBzaXplb2YoZXZlbnRfZW50cnlfdCkpOwogCiAgICAgLyogcmUtd3JpdGUgcGh5
c2ljYWwgZGV2aWNlIGlkIGludG8gdmlydHVhbCBkZXZpY2UgaWQgKi8KLSAgICBkZXZfaWQg
PSBndWVzdF9iZGYoZCwgaW9tbXVfZ2V0X2RldmlkX2Zyb21fY21kKGVudHJ5WzBdKSk7Cisg
ICAgZGV2X2lkID0gZ3Vlc3RfYmRmKGQsIDAsIGlvbW11X2dldF9kZXZpZF9mcm9tX2NtZChl
bnRyeVswXSkpOwogICAgIGlvbW11X3NldF9kZXZpZF90b19jbWQoJmVudHJ5WzBdLCBkZXZf
aWQpOwogICAgIG1lbWNweShsb2csIGVudHJ5LCBzaXplb2YoZXZlbnRfZW50cnlfdCkpOwog
CkBAIC0yNzgsNyArMjk1LDcgQEAgc3RhdGljIGludCBkb19jb21wbGV0ZV9wcHJfcmVxdWVz
dChzdHJ1Y3QgZG9tYWluICpkLCBjbWRfZW50cnlfdCAqY21kKQogICAgIHVpbnQxNl90IGRl
dl9pZDsKICAgICBzdHJ1Y3QgYW1kX2lvbW11ICppb21tdTsKIAotICAgIGRldl9pZCA9IG1h
Y2hpbmVfYmRmKGQsIGlvbW11X2dldF9kZXZpZF9mcm9tX2NtZChjbWQtPmRhdGFbMF0pKTsK
KyAgICBkZXZfaWQgPSBtYWNoaW5lX2JkZihkLCAwLCBpb21tdV9nZXRfZGV2aWRfZnJvbV9j
bWQoY21kLT5kYXRhWzBdKSk7CiAgICAgaW9tbXUgPSBmaW5kX2lvbW11X2Zvcl9kZXZpY2Uo
MCwgZGV2X2lkKTsKIAogICAgIGlmICggIWlvbW11ICkKQEAgLTMzMCw3ICszNDcsNyBAQCBz
dGF0aWMgaW50IGRvX2ludmFsaWRhdGVfaW90bGJfcGFnZXMoc3RydWN0IGRvbWFpbiAqZCwg
Y21kX2VudHJ5X3QgKmNtZCkKICAgICBzdHJ1Y3QgYW1kX2lvbW11ICppb21tdTsKICAgICB1
aW50MTZfdCBkZXZfaWQ7CiAKLSAgICBkZXZfaWQgPSBtYWNoaW5lX2JkZihkLCBpb21tdV9n
ZXRfZGV2aWRfZnJvbV9jbWQoY21kLT5kYXRhWzBdKSk7CisgICAgZGV2X2lkID0gbWFjaGlu
ZV9iZGYoZCwgMCwgaW9tbXVfZ2V0X2RldmlkX2Zyb21fY21kKGNtZC0+ZGF0YVswXSkpOwog
CiAgICAgaW9tbXUgPSBmaW5kX2lvbW11X2Zvcl9kZXZpY2UoMCwgZGV2X2lkKTsKICAgICBp
ZiAoICFpb21tdSApCkBAIC00MDksNyArNDI2LDcgQEAgc3RhdGljIGludCBkb19pbnZhbGlk
YXRlX2R0ZShzdHJ1Y3QgZG9tYWluICpkLCBjbWRfZW50cnlfdCAqY21kKQogCiAgICAgZ19p
b21tdSA9IGRvbWFpbl9pb21tdShkKTsKICAgICBnYmRmID0gaW9tbXVfZ2V0X2RldmlkX2Zy
b21fY21kKGNtZC0+ZGF0YVswXSk7Ci0gICAgbWJkZiA9IG1hY2hpbmVfYmRmKGQsIGdiZGYp
OworICAgIG1iZGYgPSBtYWNoaW5lX2JkZihkLCAwLCBnYmRmKTsKIAogICAgIC8qIEd1ZXN0
IGNhbiBvbmx5IHVwZGF0ZSBEVEVzIGZvciBpdHMgcGFzc3RocnUgZGV2aWNlcyAqLwogICAg
IGlmICggbWJkZiA9PSAwIHx8IGdiZGYgPT0gMCApCkBAIC05MTYsMyArOTMzLDQ0IEBAIGNv
bnN0IHN0cnVjdCBodm1fbW1pb19oYW5kbGVyIGlvbW11X21taW9faGFuZGxlciA9IHsKICAg
ICAucmVhZF9oYW5kbGVyID0gZ3Vlc3RfaW9tbXVfbW1pb19yZWFkLAogICAgIC53cml0ZV9o
YW5kbGVyID0gZ3Vlc3RfaW9tbXVfbW1pb193cml0ZQogfTsKKworLyogaW9tbXUgaHlwZXJj
YWxsIGhhbmRsZXIgKi8KK2ludCBpb21tdV9iaW5kX2JkZihzdHJ1Y3QgZG9tYWluKiBkLCB1
aW50MTZfdCBnc2VnLCB1aW50MTZfdCBnYmRmLAorICAgICAgICAgICAgICAgICAgIHVpbnQx
Nl90IG1zZWcsIHVpbnQxNl90IG1iZGYpCit7CisgICAgc3RydWN0IHBjaV9kZXYgKnBkZXY7
CisgICAgaW50IHJldCA9IC1FTk9ERVY7CisKKyAgICBpZiAoICFpb21tdV9mb3VuZCgpIHx8
ICFpb21tdV9lbmFibGVkIHx8ICFpb21tdXYyX2VuYWJsZWQgKQorICAgICAgICByZXR1cm4g
MDsKKworICAgIHNwaW5fbG9jaygmcGNpZGV2c19sb2NrKTsKKworICAgIGZvcl9lYWNoX3Bk
ZXYoIGQsIHBkZXYgKQorICAgIHsKKyAgICAgICAgaWYgKCAocGRldi0+c2VnICE9IG1zZWcp
IHx8IChwZGV2LT5idXMgIT0gUENJX0JVUyhtYmRmKSApIHx8IAorICAgICAgICAgICAgIChw
ZGV2LT5kZXZmbiAhPSBQQ0lfREVWRk4yKG1iZGYpKSApCisgICAgICAgICAgICBjb250aW51
ZTsKKworICAgICAgICBwZGV2LT5nc2VnID0gZ3NlZzsKKyAgICAgICAgcGRldi0+Z2JkZiA9
IGdiZGY7CisgICAgICAgIHJldCA9IDA7CisgICAgfQorCisgICAgc3Bpbl91bmxvY2soJnBj
aWRldnNfbG9jayk7CisgICAgcmV0dXJuIHJldDsKK30KKwordm9pZCBpb21tdV9zZXRfbXNp
KHN0cnVjdCBkb21haW4qIGQsIHVpbnQ4X3QgdmVjdG9yLCB1aW50OF90IGRlc3QsCisgICAg
ICAgICAgICAgICAgICAgdWludDhfdCBkZXN0X21vZGUsIHVpbnQ4X3QgZGVsaXZlcnlfbW9k
ZSwgdWludDhfdCB0cmlnX21vZGUpCit7CisgICAgc3RydWN0IGd1ZXN0X2lvbW11ICppb21t
dSA9IGRvbWFpbl9pb21tdShkKTsKKworICAgIGlmICggIWlvbW11ICkKKyAgICAgICAgcmV0
dXJuOworCisgICAgaW9tbXUtPm1zaS52ZWN0b3IgPSB2ZWN0b3I7CisgICAgaW9tbXUtPm1z
aS5kZXN0ID0gZGVzdDsKKyAgICBpb21tdS0+bXNpLmRlc3RfbW9kZSA9IGRlc3RfbW9kZTsK
KyAgICBpb21tdS0+bXNpLnRyaWdfbW9kZSA9IHRyaWdfbW9kZTsKK30KZGlmZiAtLWdpdCBh
L3hlbi9kcml2ZXJzL3Bhc3N0aHJvdWdoL2lvbW11LmMgYi94ZW4vZHJpdmVycy9wYXNzdGhy
b3VnaC9pb21tdS5jCmluZGV4IGI0Y2YxNmMuLmY4ZjIzY2IgMTAwNjQ0Ci0tLSBhL3hlbi9k
cml2ZXJzL3Bhc3N0aHJvdWdoL2lvbW11LmMKKysrIGIveGVuL2RyaXZlcnMvcGFzc3Rocm91
Z2gvaW9tbXUuYwpAQCAtNjU2LDYgKzY1Niw0MCBAQCBpbnQgaW9tbXVfZG9fZG9tY3RsKAog
ICAgICAgICBwdXRfZG9tYWluKGQpOwogICAgICAgICBicmVhazsKIAorICAgIGNhc2UgWEVO
X0RPTUNUTF9ndWVzdF9pb21tdV9vcDoKKyAgICB7CisgICAgICAgIHhlbl9kb21jdGxfZ3Vl
c3RfaW9tbXVfb3BfdCAqZ3Vlc3Rfb3A7CisKKyAgICAgICAgaWYgKCB1bmxpa2VseSgoZCA9
IGdldF9kb21haW5fYnlfaWQoZG9tY3RsLT5kb21haW4pKSA9PSBOVUxMKSApCisgICAgICAg
IHsKKyAgICAgICAgICAgIGdkcHJpbnRrKFhFTkxPR19FUlIsCisgICAgICAgICAgICAgICAg
ICAgICJYRU5fRE9NQ1RMX2d1ZXN0X2lvbW11X29wOiBnZXRfZG9tYWluX2J5X2lkKCkgZmFp
bGVkXG4iKTsKKyAgICAgICAgICAgIHJldCA9IC1FSU5WQUw7CisgICAgICAgICAgICBicmVh
azsKKyAgICAgICAgfQorCisgICAgICAgIGd1ZXN0X29wID0gJihkb21jdGwtPnUuZ3Vlc3Rf
aW9tbXVfb3ApOworICAgICAgICBzd2l0Y2ggKCBndWVzdF9vcC0+b3AgKQorICAgICAgICB7
CisgICAgICAgIGNhc2UgWEVOX0RPTUNUTF9HVUVTVF9JT01NVV9PUF9TRVRfTVNJOgorICAg
ICAgICAgICAgIGlvbW11X3NldF9tc2koZCwgZ3Vlc3Rfb3AtPnUubXNpLnZlY3RvciwgCisg
ICAgICAgICAgICAgICAgICAgICAgICAgICBndWVzdF9vcC0+dS5tc2kuZGVzdCwKKyAgICAg
ICAgICAgICAgICAgICAgICAgICAgIGd1ZXN0X29wLT51Lm1zaS5kZXN0X21vZGUsIAorICAg
ICAgICAgICAgICAgICAgICAgICAgICAgZ3Vlc3Rfb3AtPnUubXNpLmRlbGl2ZXJ5X21vZGUs
CisgICAgICAgICAgICAgICAgICAgICAgICAgICBndWVzdF9vcC0+dS5tc2kudHJpZ19tb2Rl
KTsKKyAgICAgICAgICAgICByZXQgPSAwOworICAgICAgICAgICAgIGJyZWFrOworICAgICAg
ICBjYXNlIFhFTl9ET01DVExfR1VFU1RfSU9NTVVfT1BfQklORF9CREY6CisgICAgICAgICAg
ICAgcmV0ID0gaW9tbXVfYmluZF9iZGYoZCwgZ3Vlc3Rfb3AtPnUuYmRmX2JpbmQuZ19zZWcs
CisgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgZ3Vlc3Rfb3AtPnUuYmRmX2Jp
bmQuZ19iZGYsCisgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgZ3Vlc3Rfb3At
PnUuYmRmX2JpbmQubV9zZWcsCisgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
Z3Vlc3Rfb3AtPnUuYmRmX2JpbmQubV9iZGYpOworICAgICAgICAgICAgIGJyZWFrOworICAg
ICAgICB9CisgICAgICAgIHB1dF9kb21haW4oZCk7CisgICAgICAgIGJyZWFrOworICAgIH0K
KwogICAgIGRlZmF1bHQ6CiAgICAgICAgIHJldCA9IC1FTk9TWVM7CiAgICAgICAgIGJyZWFr
OwpkaWZmIC0tZ2l0IGEveGVuL2luY2x1ZGUvcHVibGljL2RvbWN0bC5oIGIveGVuL2luY2x1
ZGUvcHVibGljL2RvbWN0bC5oCmluZGV4IGYzNjdjZTIuLmY3YTViZGEgMTAwNjQ0Ci0tLSBh
L3hlbi9pbmNsdWRlL3B1YmxpYy9kb21jdGwuaAorKysgYi94ZW4vaW5jbHVkZS9wdWJsaWMv
ZG9tY3RsLmgKQEAgLTgyNyw2ICs4MjcsMzEgQEAgc3RydWN0IHhlbl9kb21jdGxfc2V0X2Fj
Y2Vzc19yZXF1aXJlZCB7CiB0eXBlZGVmIHN0cnVjdCB4ZW5fZG9tY3RsX3NldF9hY2Nlc3Nf
cmVxdWlyZWQgeGVuX2RvbWN0bF9zZXRfYWNjZXNzX3JlcXVpcmVkX3Q7CiBERUZJTkVfWEVO
X0dVRVNUX0hBTkRMRSh4ZW5fZG9tY3RsX3NldF9hY2Nlc3NfcmVxdWlyZWRfdCk7CiAKKy8q
IFN1cHBvcnQgZm9yIGd1ZXN0IGlvbW11IGVtdWxhdGlvbiAqLworc3RydWN0IHhlbl9kb21j
dGxfZ3Vlc3RfaW9tbXVfb3AgeworICAgIC8qIFhFTl9ET01DVExfR1VFU1RfSU9NTVVfT1Bf
KiAqLworI2RlZmluZSBYRU5fRE9NQ1RMX0dVRVNUX0lPTU1VX09QX1NFVF9NU0kgICAgICAg
ICAgICAgICAwCisjZGVmaW5lIFhFTl9ET01DVExfR1VFU1RfSU9NTVVfT1BfQklORF9CREYg
ICAgICAgICAgICAgIDEKKyAgICB1aW50OF90IG9wOworICAgIHVuaW9uIHsKKyAgICAgICAg
c3RydWN0IGlvbW11X21zaSB7CisgICAgICAgICAgICB1aW50OF90ICAgICB2ZWN0b3I7Cisg
ICAgICAgICAgICB1aW50OF90ICAgICBkZXN0OworICAgICAgICAgICAgdWludDhfdCAgICAg
ZGVzdF9tb2RlOworICAgICAgICAgICAgdWludDhfdCAgICAgZGVsaXZlcnlfbW9kZTsKKyAg
ICAgICAgICAgIHVpbnQ4X3QgICAgIHRyaWdfbW9kZTsKKyAgICAgICAgfSBtc2k7CisgICAg
ICAgIHN0cnVjdCBiZGZfYmluZCB7CisgICAgICAgICAgICB1aW50MTZfdCAgICBnX3NlZzsK
KyAgICAgICAgICAgIHVpbnQxNl90ICAgIGdfYmRmOworICAgICAgICAgICAgdWludDE2X3Qg
ICAgbV9zZWc7CisgICAgICAgICAgICB1aW50MTZfdCAgICBtX2JkZjsKKyAgICAgICAgfSBi
ZGZfYmluZDsKKyAgICB9IHU7Cit9OwordHlwZWRlZiBzdHJ1Y3QgeGVuX2RvbWN0bF9ndWVz
dF9pb21tdV9vcCB4ZW5fZG9tY3RsX2d1ZXN0X2lvbW11X29wX3Q7CitERUZJTkVfWEVOX0dV
RVNUX0hBTkRMRSh4ZW5fZG9tY3RsX2d1ZXN0X2lvbW11X29wX3QpOworCiBzdHJ1Y3QgeGVu
X2RvbWN0bCB7CiAgICAgdWludDMyX3QgY21kOwogI2RlZmluZSBYRU5fRE9NQ1RMX2NyZWF0
ZWRvbWFpbiAgICAgICAgICAgICAgICAgICAxCkBAIC04OTIsNiArOTE3LDcgQEAgc3RydWN0
IHhlbl9kb21jdGwgewogI2RlZmluZSBYRU5fRE9NQ1RMX3NldF9hY2Nlc3NfcmVxdWlyZWQg
ICAgICAgICAgIDY0CiAjZGVmaW5lIFhFTl9ET01DVExfYXVkaXRfcDJtICAgICAgICAgICAg
ICAgICAgICAgNjUKICNkZWZpbmUgWEVOX0RPTUNUTF9zZXRfdmlycV9oYW5kbGVyICAgICAg
ICAgICAgICA2NgorI2RlZmluZSBYRU5fRE9NQ1RMX2d1ZXN0X2lvbW11X29wICAgICAgICAg
ICAgICAgIDY3CiAjZGVmaW5lIFhFTl9ET01DVExfZ2Ric3hfZ3Vlc3RtZW1pbyAgICAgICAg
ICAgIDEwMDAKICNkZWZpbmUgWEVOX0RPTUNUTF9nZGJzeF9wYXVzZXZjcHUgICAgICAgICAg
ICAgMTAwMQogI2RlZmluZSBYRU5fRE9NQ1RMX2dkYnN4X3VucGF1c2V2Y3B1ICAgICAgICAg
ICAxMDAyCkBAIC05MzksNiArOTY1LDcgQEAgc3RydWN0IHhlbl9kb21jdGwgewogICAgICAg
ICBzdHJ1Y3QgeGVuX2RvbWN0bF9kZWJ1Z19vcCAgICAgICAgICBkZWJ1Z19vcDsKICAgICAg
ICAgc3RydWN0IHhlbl9kb21jdGxfbWVtX2V2ZW50X29wICAgICAgbWVtX2V2ZW50X29wOwog
ICAgICAgICBzdHJ1Y3QgeGVuX2RvbWN0bF9tZW1fc2hhcmluZ19vcCAgICBtZW1fc2hhcmlu
Z19vcDsKKyAgICAgICAgc3RydWN0IHhlbl9kb21jdGxfZ3Vlc3RfaW9tbXVfb3AgICAgZ3Vl
c3RfaW9tbXVfb3A7CiAjaWYgZGVmaW5lZChfX2kzODZfXykgfHwgZGVmaW5lZChfX3g4Nl82
NF9fKQogICAgICAgICBzdHJ1Y3QgeGVuX2RvbWN0bF9jcHVpZCAgICAgICAgICAgICBjcHVp
ZDsKICAgICAgICAgc3RydWN0IHhlbl9kb21jdGxfdmNwdWV4dHN0YXRlICAgICAgdmNwdWV4
dHN0YXRlOwpkaWZmIC0tZ2l0IGEveGVuL2luY2x1ZGUveGVuL2lvbW11LmggYi94ZW4vaW5j
bHVkZS94ZW4vaW9tbXUuaAppbmRleCA2MDVjN2IzLi42MWE2ODFiIDEwMDY0NAotLS0gYS94
ZW4vaW5jbHVkZS94ZW4vaW9tbXUuaAorKysgYi94ZW4vaW5jbHVkZS94ZW4vaW9tbXUuaApA
QCAtMTYxLDYgKzE2MSwxMSBAQCBpbnQgaW9tbXVfZG9fZG9tY3RsKHN0cnVjdCB4ZW5fZG9t
Y3RsICosIFhFTl9HVUVTVF9IQU5ETEUoeGVuX2RvbWN0bF90KSk7CiB2b2lkIGlvbW11X2lv
dGxiX2ZsdXNoKHN0cnVjdCBkb21haW4gKmQsIHVuc2lnbmVkIGxvbmcgZ2ZuLCB1bnNpZ25l
ZCBpbnQgcGFnZV9jb3VudCk7CiB2b2lkIGlvbW11X2lvdGxiX2ZsdXNoX2FsbChzdHJ1Y3Qg
ZG9tYWluICpkKTsKIAorLyogT25seSB1c2VkIGJ5IEFNRCBJT01NVSBzbyBmYXIgKi8KK3Zv
aWQgaW9tbXVfc2V0X21zaShzdHJ1Y3QgZG9tYWluKiBkLCB1aW50OF90IHZlY3RvciwgdWlu
dDhfdCBkZXN0LAorICAgICAgICAgICAgICAgICAgIHVpbnQ4X3QgZGVzdF9tb2RlLCB1aW50
OF90IGRlbGl2ZXJ5X21vZGUsIHVpbnQ4X3QgdHJpZ19tb2RlKTsKK2ludCBpb21tdV9iaW5k
X2JkZihzdHJ1Y3QgZG9tYWluKiBkLCB1aW50MTZfdCBnc2VnLCB1aW50MTZfdCBnYmRmLCAK
KyAgICAgICAgICAgICAgICAgICB1aW50MTZfdCBtc2VnLCB1aW50MTZfdCBtYmRmKTsKIC8q
CiAgKiBUaGUgcHVycG9zZSBvZiB0aGUgaW9tbXVfZG9udF9mbHVzaF9pb3RsYiBvcHRpb25h
bCBjcHUgZmxhZyBpcyB0bwogICogYXZvaWQgdW5lY2Vzc2FyeSBpb3RsYl9mbHVzaCBpbiB0
aGUgbG93IGxldmVsIElPTU1VIGNvZGUuCmRpZmYgLS1naXQgYS94ZW4vaW5jbHVkZS94ZW4v
cGNpLmggYi94ZW4vaW5jbHVkZS94ZW4vcGNpLmgKaW5kZXggMThiN2ZiMS4uODBkZDM3OCAx
MDA2NDQKLS0tIGEveGVuL2luY2x1ZGUveGVuL3BjaS5oCisrKyBiL3hlbi9pbmNsdWRlL3hl
bi9wY2kuaApAQCAtNjIsNiArNjIsMTEgQEAgc3RydWN0IHBjaV9kZXYgewogICAgIGNvbnN0
IHUxNiBzZWc7CiAgICAgY29uc3QgdTggYnVzOwogICAgIGNvbnN0IHU4IGRldmZuOworCisg
ICAgLyogVXNlZCBieSBpb21tdSB0byByZXByZXNlbnQgdmlydHVhbCBzZWcgYW5kIGJkZiB2
YWx1ZSBpbiBndWVzdCBzcGFjZSAqLworICAgIHUxNiBnc2VnOworICAgIHUxNiBnYmRmOwor
CiAgICAgc3RydWN0IHBjaV9kZXZfaW5mbyBpbmZvOwogICAgIHN0cnVjdCBhcmNoX3BjaV9k
ZXYgYXJjaDsKICAgICB1NjQgdmZfcmxlbls2XTsKLS0gCjEuNy40CgoK
--------------040102030109070306030606
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--------------040102030109070306030606--


From xen-devel-bounces@lists.xen.org Wed Sep 26 14:44:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Sep 2012 14:44: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 1TGsqy-00013o-JC; Wed, 26 Sep 2012 14:44: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 1TGsqx-00013F-AQ
	for Xen-devel@lists.xensource.com; Wed, 26 Sep 2012 14:44:43 +0000
Received: from [85.158.143.99:26229] by server-3.bemta-4.messagelabs.com id
	CD/DC-10986-AD413605; Wed, 26 Sep 2012 14:44:42 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1348670680!20626030!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDc3NTczOQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9169 invoked from network); 26 Sep 2012 14:44:42 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-16.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 26 Sep 2012 14:44:42 -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 q8QEiZ2l026513
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 26 Sep 2012 14:44: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
	q8QEiYDI012930
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 26 Sep 2012 14:44:35 GMT
Received: from abhmt107.oracle.com (abhmt107.oracle.com [141.146.116.59])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q8QEiYa9007011; Wed, 26 Sep 2012 09:44:34 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 26 Sep 2012 07:44:34 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id F13DB4035A; Wed, 26 Sep 2012 10:33:17 -0400 (EDT)
Date: Wed, 26 Sep 2012 10:33:17 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Mukesh Rathor <mukesh.rathor@oracle.com>
Message-ID: <20120926143317.GA24866@phenom.dumpdata.com>
References: <20120921121511.30001c08@mantra.us.oracle.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120921121511.30001c08@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] [PATCH v1 1/8]: PVH  basic and hader file 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

> diff --git a/include/xen/interface/memory.h b/include/xen/interface/memory.h
> index eac3ce1..f150fa1c 100644
> --- a/include/xen/interface/memory.h
> +++ b/include/xen/interface/memory.h
> @@ -163,11 +163,22 @@ struct xen_add_to_physmap {
>      /* Which domain to change the mapping for. */
>      domid_t domid;
>  
> +    union {
> +        /* Number of pages to go through for gmfn_range */
> +        uint16_t    size;
> +	/* IFF XENMAPSPACE_gmfn_foreign */
> +        domid_t foreign_domid;
> +    } u;
>      /* Source mapping space. */

So found out why it crashed on PVHVM. If you rebase your patch
on top of  b58aaa4b0b3506c094308342d746f600468c63d9

Author: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date:   Mon Aug 6 15:27:24 2012 +0100

    xen: update xen_add_to_physmap interface
    
    Update struct xen_add_to_physmap to be in sync with Xen's version of the
    structure.
    The size field was introduced by:
    
    changeset:   24164:707d27fe03e7
    user:        Jean Guyader <jean.guyader@eu.citrix.com>
    date:        Fri Nov 18 13:42:08 2011 +0000
    summary:     mm: New XENMEM space, XENMAPSPACE_gmfn_range
    
    According to the comment:
    
    "This new field .size is located in the 16 bits padding between .domid
    and .space in struct xen_add_to_physmap to stay compatible with older
    versions."
    
    Changes in v2:
    
    - remove erroneous comment in the commit message.
    
    Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
    Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

the merge ends up looking like this:
@ -166,11 +166,22 @@ struct xen_add_to_physmap {
     /* Number of pages to go through for gmfn_range */
     uint16_t    size;
 
+    union {
+        /* Number of pages to go through for gmfn_range */
+        uint16_t    size;
+	/* IFF XENMAPSPACE_gmfn_foreign */
+        domid_t foreign_domid;
+    } u;

Grrrr..


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 26 14:44:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Sep 2012 14:44: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 1TGsqy-00013o-JC; Wed, 26 Sep 2012 14:44: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 1TGsqx-00013F-AQ
	for Xen-devel@lists.xensource.com; Wed, 26 Sep 2012 14:44:43 +0000
Received: from [85.158.143.99:26229] by server-3.bemta-4.messagelabs.com id
	CD/DC-10986-AD413605; Wed, 26 Sep 2012 14:44:42 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1348670680!20626030!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDc3NTczOQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9169 invoked from network); 26 Sep 2012 14:44:42 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-16.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 26 Sep 2012 14:44:42 -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 q8QEiZ2l026513
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 26 Sep 2012 14:44: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
	q8QEiYDI012930
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 26 Sep 2012 14:44:35 GMT
Received: from abhmt107.oracle.com (abhmt107.oracle.com [141.146.116.59])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q8QEiYa9007011; Wed, 26 Sep 2012 09:44:34 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 26 Sep 2012 07:44:34 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id F13DB4035A; Wed, 26 Sep 2012 10:33:17 -0400 (EDT)
Date: Wed, 26 Sep 2012 10:33:17 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Mukesh Rathor <mukesh.rathor@oracle.com>
Message-ID: <20120926143317.GA24866@phenom.dumpdata.com>
References: <20120921121511.30001c08@mantra.us.oracle.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120921121511.30001c08@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] [PATCH v1 1/8]: PVH  basic and hader file 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

> diff --git a/include/xen/interface/memory.h b/include/xen/interface/memory.h
> index eac3ce1..f150fa1c 100644
> --- a/include/xen/interface/memory.h
> +++ b/include/xen/interface/memory.h
> @@ -163,11 +163,22 @@ struct xen_add_to_physmap {
>      /* Which domain to change the mapping for. */
>      domid_t domid;
>  
> +    union {
> +        /* Number of pages to go through for gmfn_range */
> +        uint16_t    size;
> +	/* IFF XENMAPSPACE_gmfn_foreign */
> +        domid_t foreign_domid;
> +    } u;
>      /* Source mapping space. */

So found out why it crashed on PVHVM. If you rebase your patch
on top of  b58aaa4b0b3506c094308342d746f600468c63d9

Author: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date:   Mon Aug 6 15:27:24 2012 +0100

    xen: update xen_add_to_physmap interface
    
    Update struct xen_add_to_physmap to be in sync with Xen's version of the
    structure.
    The size field was introduced by:
    
    changeset:   24164:707d27fe03e7
    user:        Jean Guyader <jean.guyader@eu.citrix.com>
    date:        Fri Nov 18 13:42:08 2011 +0000
    summary:     mm: New XENMEM space, XENMAPSPACE_gmfn_range
    
    According to the comment:
    
    "This new field .size is located in the 16 bits padding between .domid
    and .space in struct xen_add_to_physmap to stay compatible with older
    versions."
    
    Changes in v2:
    
    - remove erroneous comment in the commit message.
    
    Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
    Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

the merge ends up looking like this:
@ -166,11 +166,22 @@ struct xen_add_to_physmap {
     /* Number of pages to go through for gmfn_range */
     uint16_t    size;
 
+    union {
+        /* Number of pages to go through for gmfn_range */
+        uint16_t    size;
+	/* IFF XENMAPSPACE_gmfn_foreign */
+        domid_t foreign_domid;
+    } u;

Grrrr..


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 26 14:45:00 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Sep 2012 14:45:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGsr5-00016b-K6; Wed, 26 Sep 2012 14:44:51 +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 1TGsr4-00015O-7W
	for xen-devel@lists.xensource.com; Wed, 26 Sep 2012 14:44:50 +0000
Received: from [85.158.139.211:26053] by server-12.bemta-5.messagelabs.com id
	05/AB-20729-1E413605; Wed, 26 Sep 2012 14:44:49 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-12.tower-206.messagelabs.com!1348670688!19050349!1
X-Originating-IP: [213.199.154.209]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12752 invoked from network); 26 Sep 2012 14:44:48 -0000
Received: from am1ehsobe006.messaging.microsoft.com (HELO
	am1outboundpool.messaging.microsoft.com) (213.199.154.209)
	by server-12.tower-206.messagelabs.com with AES128-SHA encrypted SMTP;
	26 Sep 2012 14:44:48 -0000
Received: from mail36-am1-R.bigfish.com (10.3.201.243) by
	AM1EHSOBE003.bigfish.com (10.3.204.23) with Microsoft SMTP Server id
	14.1.225.23; Wed, 26 Sep 2012 14:44:48 +0000
Received: from mail36-am1 (localhost [127.0.0.1])	by mail36-am1-R.bigfish.com
	(Postfix) with ESMTP id 4CC633400BC;
	Wed, 26 Sep 2012 14:44:48 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:163.181.249.109; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp02.amd.com; RD:none; EFVD:NLI
X-SpamScore: 0
X-BigFish: VPS0(zzc857hzz1202h1d1ah1d2ahzzz2dh668h839hd25he5bhf0ah107ah1288h12a5h12bdh137ah34h1155h)
Received: from mail36-am1 (localhost.localdomain [127.0.0.1]) by mail36-am1
	(MessageSwitch) id 1348670686395012_13184;
	Wed, 26 Sep 2012 14:44:46 +0000 (UTC)
Received: from AM1EHSMHS007.bigfish.com (unknown [10.3.201.251])	by
	mail36-am1.bigfish.com (Postfix) with ESMTP id 5DE7430004B;
	Wed, 26 Sep 2012 14:44:46 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	AM1EHSMHS007.bigfish.com (10.3.207.107) with Microsoft SMTP Server id
	14.1.225.23; Wed, 26 Sep 2012 14:44:44 +0000
X-WSS-ID: 0MAYOYF-02-2XW-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 2D33FC8004;	Wed, 26 Sep 2012 09:44:39 -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;
	Wed, 26 Sep 2012 09:44:53 -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;
	Wed, 26 Sep 2012 09:44:40 -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, 26 Sep 2012
	10:44:39 -0400
Received: from [165.204.15.57] (gran.osrc.amd.com [165.204.15.57])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id AF50C49C14F; Wed, 26 Sep 2012
	15:44:38 +0100 (BST)
Message-ID: <5063155A.4070307@amd.com>
Date: Wed, 26 Sep 2012 16:46: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: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, Ian
	Campbell <Ian.Campbell@citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, 
	Jan Beulich <JBeulich@suse.com>, Keir Fraser <keir@xen.org>
Content-Type: multipart/mixed; boundary="------------080101000405030904060006"
X-OriginatorOrg: amd.com
Subject: [Xen-devel] [PATCH 2 of 6 V6] amd iommu: call guest_iommu_set_base
	from hvmloader
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--------------080101000405030904060006
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 7bit




--------------080101000405030904060006
Content-Type: text/plain; charset="UTF-8";
	name="0002-amd-iommu-call-guest_iommu_set_base-from-hvmloader.patch"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="0002-amd-iommu-call-guest_iommu_set_base-from-hvmloader.patch"
Content-Description: 0002-amd-iommu-call-guest_iommu_set_base-from-hvmloader.patch

RnJvbSA4MTEwZTBhMjIzNDg4YTExMjNmYTgwNTA1MTkwNWQ4Nzg4NjEwY2YyIE1vbiBTZXAg
MTcgMDA6MDA6MDAgMjAwMQpGcm9tOiBXZWkgV2FuZyA8d2VpLndhbmcyQGFtZC5jb20+CkRh
dGU6IFdlZCwgMjYgU2VwIDIwMTIgMTE6NDQ6MTkgKzAyMDAKU3ViamVjdDogW1BBVENIIDIv
Nl0gYW1kIGlvbW11OiBjYWxsIGd1ZXN0X2lvbW11X3NldF9iYXNlIGZyb20gaHZtbG9hZGVy
LgoKSU9NTVUgTU1JTyBiYXNlIGFkZHJlc3MgaXMgZHluYW1pY2FsbHkgYWxsb2NhdGVkIGJ5
IGZpcm13YXJlLgpUaGlzIHBhdGNoIGFsbG93cyBodm1sb2FkZXIgdG8gbm90aWZ5IGh5cGVy
dmlzb3Igd2hlcmUgdGhlCmlvbW11IG1taW8gcGFnZXMgYXJlLgoKU2lnbmVkLW9mZi1ieTog
V2VpIFdhbmcgPHdlaS53YW5nMkBhbWQuY29tPgotLS0KIHhlbi9hcmNoL3g4Ni9odm0vaHZt
LmMgICAgICAgICAgfCAgICA0ICsrKysKIHhlbi9pbmNsdWRlL3B1YmxpYy9odm0vcGFyYW1z
LmggfCAgICAzICsrLQogMiBmaWxlcyBjaGFuZ2VkLCA2IGluc2VydGlvbnMoKyksIDEgZGVs
ZXRpb25zKC0pCgpkaWZmIC0tZ2l0IGEveGVuL2FyY2gveDg2L2h2bS9odm0uYyBiL3hlbi9h
cmNoL3g4Ni9odm0vaHZtLmMKaW5kZXggZDY5ZTQxOS4uZTVjMWUzMiAxMDA2NDQKLS0tIGEv
eGVuL2FyY2gveDg2L2h2bS9odm0uYworKysgYi94ZW4vYXJjaC94ODYvaHZtL2h2bS5jCkBA
IC02Niw2ICs2Niw3IEBACiAjaW5jbHVkZSA8YXNtL21lbV9ldmVudC5oPgogI2luY2x1ZGUg
PGFzbS9tZW1fYWNjZXNzLmg+CiAjaW5jbHVkZSA8cHVibGljL21lbV9ldmVudC5oPgorI2lu
Y2x1ZGUgPGFzbS9odm0vc3ZtL2FtZC1pb21tdS1wcm90by5oPgogCiBib29sX3QgX19yZWFk
X21vc3RseSBodm1fZW5hYmxlZDsKIApAQCAtMzgzNCw2ICszODM1LDkgQEAgbG9uZyBkb19o
dm1fb3AodW5zaWduZWQgbG9uZyBvcCwgWEVOX0dVRVNUX0hBTkRMRSh2b2lkKSBhcmcpCiAg
ICAgICAgICAgICBjYXNlIEhWTV9QQVJBTV9CVUZJT1JFUV9FVlRDSE46CiAgICAgICAgICAg
ICAgICAgcmMgPSAtRUlOVkFMOwogICAgICAgICAgICAgICAgIGJyZWFrOworICAgICAgICAg
ICAgY2FzZSBIVk1fUEFSQU1fSU9NTVVfQkFTRToKKyAgICAgICAgICAgICAgICByYyA9IGd1
ZXN0X2lvbW11X3NldF9iYXNlKGQsIGEudmFsdWUpOworICAgICAgICAgICAgICAgIGJyZWFr
OwogICAgICAgICAgICAgfQogCiAgICAgICAgICAgICBpZiAoIHJjID09IDAgKSAKZGlmZiAt
LWdpdCBhL3hlbi9pbmNsdWRlL3B1YmxpYy9odm0vcGFyYW1zLmggYi94ZW4vaW5jbHVkZS9w
dWJsaWMvaHZtL3BhcmFtcy5oCmluZGV4IDZiMDVmNjEuLmFhYjZiN2EgMTAwNjQ0Ci0tLSBh
L3hlbi9pbmNsdWRlL3B1YmxpYy9odm0vcGFyYW1zLmgKKysrIGIveGVuL2luY2x1ZGUvcHVi
bGljL2h2bS9wYXJhbXMuaApAQCAtMTQwLDcgKzE0MCw4IEBACiAjZGVmaW5lIEhWTV9QQVJB
TV9QQUdJTkdfUklOR19QRk4gICAyNwogI2RlZmluZSBIVk1fUEFSQU1fQUNDRVNTX1JJTkdf
UEZOICAgMjgKICNkZWZpbmUgSFZNX1BBUkFNX1NIQVJJTkdfUklOR19QRk4gIDI5CisjZGVm
aW5lIEhWTV9QQVJBTV9JT01NVV9CQVNFICAgMzAKIAotI2RlZmluZSBIVk1fTlJfUEFSQU1T
ICAgICAgICAgIDMwCisjZGVmaW5lIEhWTV9OUl9QQVJBTVMgICAgICAgICAgMzEKIAogI2Vu
ZGlmIC8qIF9fWEVOX1BVQkxJQ19IVk1fUEFSQU1TX0hfXyAqLwotLSAKMS43LjQKCgo=
--------------080101000405030904060006
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--------------080101000405030904060006--


From xen-devel-bounces@lists.xen.org Wed Sep 26 14:45:00 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Sep 2012 14:45:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGsr5-00016b-K6; Wed, 26 Sep 2012 14:44:51 +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 1TGsr4-00015O-7W
	for xen-devel@lists.xensource.com; Wed, 26 Sep 2012 14:44:50 +0000
Received: from [85.158.139.211:26053] by server-12.bemta-5.messagelabs.com id
	05/AB-20729-1E413605; Wed, 26 Sep 2012 14:44:49 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-12.tower-206.messagelabs.com!1348670688!19050349!1
X-Originating-IP: [213.199.154.209]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12752 invoked from network); 26 Sep 2012 14:44:48 -0000
Received: from am1ehsobe006.messaging.microsoft.com (HELO
	am1outboundpool.messaging.microsoft.com) (213.199.154.209)
	by server-12.tower-206.messagelabs.com with AES128-SHA encrypted SMTP;
	26 Sep 2012 14:44:48 -0000
Received: from mail36-am1-R.bigfish.com (10.3.201.243) by
	AM1EHSOBE003.bigfish.com (10.3.204.23) with Microsoft SMTP Server id
	14.1.225.23; Wed, 26 Sep 2012 14:44:48 +0000
Received: from mail36-am1 (localhost [127.0.0.1])	by mail36-am1-R.bigfish.com
	(Postfix) with ESMTP id 4CC633400BC;
	Wed, 26 Sep 2012 14:44:48 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:163.181.249.109; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp02.amd.com; RD:none; EFVD:NLI
X-SpamScore: 0
X-BigFish: VPS0(zzc857hzz1202h1d1ah1d2ahzzz2dh668h839hd25he5bhf0ah107ah1288h12a5h12bdh137ah34h1155h)
Received: from mail36-am1 (localhost.localdomain [127.0.0.1]) by mail36-am1
	(MessageSwitch) id 1348670686395012_13184;
	Wed, 26 Sep 2012 14:44:46 +0000 (UTC)
Received: from AM1EHSMHS007.bigfish.com (unknown [10.3.201.251])	by
	mail36-am1.bigfish.com (Postfix) with ESMTP id 5DE7430004B;
	Wed, 26 Sep 2012 14:44:46 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	AM1EHSMHS007.bigfish.com (10.3.207.107) with Microsoft SMTP Server id
	14.1.225.23; Wed, 26 Sep 2012 14:44:44 +0000
X-WSS-ID: 0MAYOYF-02-2XW-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 2D33FC8004;	Wed, 26 Sep 2012 09:44:39 -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;
	Wed, 26 Sep 2012 09:44:53 -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;
	Wed, 26 Sep 2012 09:44:40 -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, 26 Sep 2012
	10:44:39 -0400
Received: from [165.204.15.57] (gran.osrc.amd.com [165.204.15.57])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id AF50C49C14F; Wed, 26 Sep 2012
	15:44:38 +0100 (BST)
Message-ID: <5063155A.4070307@amd.com>
Date: Wed, 26 Sep 2012 16:46: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: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, Ian
	Campbell <Ian.Campbell@citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, 
	Jan Beulich <JBeulich@suse.com>, Keir Fraser <keir@xen.org>
Content-Type: multipart/mixed; boundary="------------080101000405030904060006"
X-OriginatorOrg: amd.com
Subject: [Xen-devel] [PATCH 2 of 6 V6] amd iommu: call guest_iommu_set_base
	from hvmloader
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--------------080101000405030904060006
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 7bit




--------------080101000405030904060006
Content-Type: text/plain; charset="UTF-8";
	name="0002-amd-iommu-call-guest_iommu_set_base-from-hvmloader.patch"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="0002-amd-iommu-call-guest_iommu_set_base-from-hvmloader.patch"
Content-Description: 0002-amd-iommu-call-guest_iommu_set_base-from-hvmloader.patch

RnJvbSA4MTEwZTBhMjIzNDg4YTExMjNmYTgwNTA1MTkwNWQ4Nzg4NjEwY2YyIE1vbiBTZXAg
MTcgMDA6MDA6MDAgMjAwMQpGcm9tOiBXZWkgV2FuZyA8d2VpLndhbmcyQGFtZC5jb20+CkRh
dGU6IFdlZCwgMjYgU2VwIDIwMTIgMTE6NDQ6MTkgKzAyMDAKU3ViamVjdDogW1BBVENIIDIv
Nl0gYW1kIGlvbW11OiBjYWxsIGd1ZXN0X2lvbW11X3NldF9iYXNlIGZyb20gaHZtbG9hZGVy
LgoKSU9NTVUgTU1JTyBiYXNlIGFkZHJlc3MgaXMgZHluYW1pY2FsbHkgYWxsb2NhdGVkIGJ5
IGZpcm13YXJlLgpUaGlzIHBhdGNoIGFsbG93cyBodm1sb2FkZXIgdG8gbm90aWZ5IGh5cGVy
dmlzb3Igd2hlcmUgdGhlCmlvbW11IG1taW8gcGFnZXMgYXJlLgoKU2lnbmVkLW9mZi1ieTog
V2VpIFdhbmcgPHdlaS53YW5nMkBhbWQuY29tPgotLS0KIHhlbi9hcmNoL3g4Ni9odm0vaHZt
LmMgICAgICAgICAgfCAgICA0ICsrKysKIHhlbi9pbmNsdWRlL3B1YmxpYy9odm0vcGFyYW1z
LmggfCAgICAzICsrLQogMiBmaWxlcyBjaGFuZ2VkLCA2IGluc2VydGlvbnMoKyksIDEgZGVs
ZXRpb25zKC0pCgpkaWZmIC0tZ2l0IGEveGVuL2FyY2gveDg2L2h2bS9odm0uYyBiL3hlbi9h
cmNoL3g4Ni9odm0vaHZtLmMKaW5kZXggZDY5ZTQxOS4uZTVjMWUzMiAxMDA2NDQKLS0tIGEv
eGVuL2FyY2gveDg2L2h2bS9odm0uYworKysgYi94ZW4vYXJjaC94ODYvaHZtL2h2bS5jCkBA
IC02Niw2ICs2Niw3IEBACiAjaW5jbHVkZSA8YXNtL21lbV9ldmVudC5oPgogI2luY2x1ZGUg
PGFzbS9tZW1fYWNjZXNzLmg+CiAjaW5jbHVkZSA8cHVibGljL21lbV9ldmVudC5oPgorI2lu
Y2x1ZGUgPGFzbS9odm0vc3ZtL2FtZC1pb21tdS1wcm90by5oPgogCiBib29sX3QgX19yZWFk
X21vc3RseSBodm1fZW5hYmxlZDsKIApAQCAtMzgzNCw2ICszODM1LDkgQEAgbG9uZyBkb19o
dm1fb3AodW5zaWduZWQgbG9uZyBvcCwgWEVOX0dVRVNUX0hBTkRMRSh2b2lkKSBhcmcpCiAg
ICAgICAgICAgICBjYXNlIEhWTV9QQVJBTV9CVUZJT1JFUV9FVlRDSE46CiAgICAgICAgICAg
ICAgICAgcmMgPSAtRUlOVkFMOwogICAgICAgICAgICAgICAgIGJyZWFrOworICAgICAgICAg
ICAgY2FzZSBIVk1fUEFSQU1fSU9NTVVfQkFTRToKKyAgICAgICAgICAgICAgICByYyA9IGd1
ZXN0X2lvbW11X3NldF9iYXNlKGQsIGEudmFsdWUpOworICAgICAgICAgICAgICAgIGJyZWFr
OwogICAgICAgICAgICAgfQogCiAgICAgICAgICAgICBpZiAoIHJjID09IDAgKSAKZGlmZiAt
LWdpdCBhL3hlbi9pbmNsdWRlL3B1YmxpYy9odm0vcGFyYW1zLmggYi94ZW4vaW5jbHVkZS9w
dWJsaWMvaHZtL3BhcmFtcy5oCmluZGV4IDZiMDVmNjEuLmFhYjZiN2EgMTAwNjQ0Ci0tLSBh
L3hlbi9pbmNsdWRlL3B1YmxpYy9odm0vcGFyYW1zLmgKKysrIGIveGVuL2luY2x1ZGUvcHVi
bGljL2h2bS9wYXJhbXMuaApAQCAtMTQwLDcgKzE0MCw4IEBACiAjZGVmaW5lIEhWTV9QQVJB
TV9QQUdJTkdfUklOR19QRk4gICAyNwogI2RlZmluZSBIVk1fUEFSQU1fQUNDRVNTX1JJTkdf
UEZOICAgMjgKICNkZWZpbmUgSFZNX1BBUkFNX1NIQVJJTkdfUklOR19QRk4gIDI5CisjZGVm
aW5lIEhWTV9QQVJBTV9JT01NVV9CQVNFICAgMzAKIAotI2RlZmluZSBIVk1fTlJfUEFSQU1T
ICAgICAgICAgIDMwCisjZGVmaW5lIEhWTV9OUl9QQVJBTVMgICAgICAgICAgMzEKIAogI2Vu
ZGlmIC8qIF9fWEVOX1BVQkxJQ19IVk1fUEFSQU1TX0hfXyAqLwotLSAKMS43LjQKCgo=
--------------080101000405030904060006
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--------------080101000405030904060006--


From xen-devel-bounces@lists.xen.org Wed Sep 26 14:45:02 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Sep 2012 14:45:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGsr8-00018K-1Q; Wed, 26 Sep 2012 14:44:54 +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 1TGsr6-00016a-3t
	for xen-devel@lists.xensource.com; Wed, 26 Sep 2012 14:44:52 +0000
Received: from [85.158.138.51:18084] by server-15.bemta-3.messagelabs.com id
	07/AC-18313-3E413605; Wed, 26 Sep 2012 14:44:51 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1348670688!30277164!1
X-Originating-IP: [216.32.180.186]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13155 invoked from network); 26 Sep 2012 14:44:50 -0000
Received: from co1ehsobe003.messaging.microsoft.com (HELO
	co1outboundpool.messaging.microsoft.com) (216.32.180.186)
	by server-15.tower-174.messagelabs.com with AES128-SHA encrypted SMTP;
	26 Sep 2012 14:44:50 -0000
Received: from mail31-co1-R.bigfish.com (10.243.78.251) by
	CO1EHSOBE004.bigfish.com (10.243.66.67) with Microsoft SMTP Server id
	14.1.225.23; Wed, 26 Sep 2012 14:44:48 +0000
Received: from mail31-co1 (localhost [127.0.0.1])	by mail31-co1-R.bigfish.com
	(Postfix) with ESMTP id 27264D00241;
	Wed, 26 Sep 2012 14:44:30 +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(zz4015Izz1202h1d1ah1d2ahzz17326ah8275dhz2dh668h839hd25he5bhf0ah107ah1288h12a5h12a9h12bdh137ah13b6h1155h)
Received: from mail31-co1 (localhost.localdomain [127.0.0.1]) by mail31-co1
	(MessageSwitch) id 1348670662396801_16072;
	Wed, 26 Sep 2012 14:44:22 +0000 (UTC)
Received: from CO1EHSMHS009.bigfish.com (unknown [10.243.78.225])	by
	mail31-co1.bigfish.com (Postfix) with ESMTP id 58F14C80056;
	Wed, 26 Sep 2012 14:44:22 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	CO1EHSMHS009.bigfish.com (10.243.66.19) with Microsoft SMTP Server id
	14.1.225.23; Wed, 26 Sep 2012 14:44:12 +0000
X-WSS-ID: 0MAYOXJ-02-2WH-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 2B980C8149;	Wed, 26 Sep 2012 09:44: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;
	Wed, 26 Sep 2012 09:44:21 -0500
Received: from storexhtp02.amd.com (172.24.4.4) by sausexdag03.amd.com
	(163.181.55.3) with Microsoft SMTP Server (TLS) id 14.1.323.3;
	Wed, 26 Sep 2012 09:44: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; Wed, 26 Sep 2012
	10:44:08 -0400
Received: from [165.204.15.57] (gran.osrc.amd.com [165.204.15.57])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id 0770B49C14F; Wed, 26 Sep 2012
	15:44:07 +0100 (BST)
Message-ID: <5063153B.30805@amd.com>
Date: Wed, 26 Sep 2012 16:46:19 +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: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, Ian
	Campbell <Ian.Campbell@citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, 
	Jan Beulich <JBeulich@suse.com>, Keir Fraser <keir@xen.org>
X-OriginatorOrg: amd.com
Subject: [Xen-devel] [PATCH 0 of 6 V6] amd iommu: support ats-gpu passthru
 on iommuv2 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

This is a resend of patch set v6 after xen-unstable reopened for new 
features. Please review it. Thanks.

For more details, please refer to old threads.
http://lists.xen.org/archives/html/xen-devel/2012-02/msg00889.html
http://lists.xen.org/archives/html/xen-devel/2012-01/msg01646.html

and, for an overview of the design, please refer to
http://www.amd64.org/pub/iommuv2.png

======================================================================
changes in v6:
* Fix indentation issues.
* Fix definition of iommu_set_msi.
* Rebase on top of tip.

changes in v5:
* Remove patch 2 after upstream c/s 24729:6f6a6d1d2fb6

changes in v4:
* Only tool part in this version, since hypervisor patches have already 
been committed.
* rename guest config option from "iommu = {0,1}" to "guest_iommu = {0,1}"
* add description into docs/man/xl.cfg.pod.5


changes in v3:
* Use xenstore to receive guest iommu configuration instead of adding in 
a new field in hvm_info_table.
* Support pci segment in vbdf to mbdf bind.
* Make hypercalls visible for non-x86 platforms.
* A few code cleanups according to comments from Jan and Ian.

Changes in v2:
* Do not use linked list to access guest iommu tables.
* Do not parse iommu parameter in libxl_device_model_info again.
* Fix incorrect logical calculation in patch 11.
* Fix hypercall definition for non-x86 systems.


Thanks,
Wei


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 26 14:45:02 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Sep 2012 14:45:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGsr8-00018K-1Q; Wed, 26 Sep 2012 14:44:54 +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 1TGsr6-00016a-3t
	for xen-devel@lists.xensource.com; Wed, 26 Sep 2012 14:44:52 +0000
Received: from [85.158.138.51:18084] by server-15.bemta-3.messagelabs.com id
	07/AC-18313-3E413605; Wed, 26 Sep 2012 14:44:51 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1348670688!30277164!1
X-Originating-IP: [216.32.180.186]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13155 invoked from network); 26 Sep 2012 14:44:50 -0000
Received: from co1ehsobe003.messaging.microsoft.com (HELO
	co1outboundpool.messaging.microsoft.com) (216.32.180.186)
	by server-15.tower-174.messagelabs.com with AES128-SHA encrypted SMTP;
	26 Sep 2012 14:44:50 -0000
Received: from mail31-co1-R.bigfish.com (10.243.78.251) by
	CO1EHSOBE004.bigfish.com (10.243.66.67) with Microsoft SMTP Server id
	14.1.225.23; Wed, 26 Sep 2012 14:44:48 +0000
Received: from mail31-co1 (localhost [127.0.0.1])	by mail31-co1-R.bigfish.com
	(Postfix) with ESMTP id 27264D00241;
	Wed, 26 Sep 2012 14:44:30 +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(zz4015Izz1202h1d1ah1d2ahzz17326ah8275dhz2dh668h839hd25he5bhf0ah107ah1288h12a5h12a9h12bdh137ah13b6h1155h)
Received: from mail31-co1 (localhost.localdomain [127.0.0.1]) by mail31-co1
	(MessageSwitch) id 1348670662396801_16072;
	Wed, 26 Sep 2012 14:44:22 +0000 (UTC)
Received: from CO1EHSMHS009.bigfish.com (unknown [10.243.78.225])	by
	mail31-co1.bigfish.com (Postfix) with ESMTP id 58F14C80056;
	Wed, 26 Sep 2012 14:44:22 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	CO1EHSMHS009.bigfish.com (10.243.66.19) with Microsoft SMTP Server id
	14.1.225.23; Wed, 26 Sep 2012 14:44:12 +0000
X-WSS-ID: 0MAYOXJ-02-2WH-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 2B980C8149;	Wed, 26 Sep 2012 09:44: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;
	Wed, 26 Sep 2012 09:44:21 -0500
Received: from storexhtp02.amd.com (172.24.4.4) by sausexdag03.amd.com
	(163.181.55.3) with Microsoft SMTP Server (TLS) id 14.1.323.3;
	Wed, 26 Sep 2012 09:44: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; Wed, 26 Sep 2012
	10:44:08 -0400
Received: from [165.204.15.57] (gran.osrc.amd.com [165.204.15.57])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id 0770B49C14F; Wed, 26 Sep 2012
	15:44:07 +0100 (BST)
Message-ID: <5063153B.30805@amd.com>
Date: Wed, 26 Sep 2012 16:46:19 +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: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, Ian
	Campbell <Ian.Campbell@citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, 
	Jan Beulich <JBeulich@suse.com>, Keir Fraser <keir@xen.org>
X-OriginatorOrg: amd.com
Subject: [Xen-devel] [PATCH 0 of 6 V6] amd iommu: support ats-gpu passthru
 on iommuv2 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

This is a resend of patch set v6 after xen-unstable reopened for new 
features. Please review it. Thanks.

For more details, please refer to old threads.
http://lists.xen.org/archives/html/xen-devel/2012-02/msg00889.html
http://lists.xen.org/archives/html/xen-devel/2012-01/msg01646.html

and, for an overview of the design, please refer to
http://www.amd64.org/pub/iommuv2.png

======================================================================
changes in v6:
* Fix indentation issues.
* Fix definition of iommu_set_msi.
* Rebase on top of tip.

changes in v5:
* Remove patch 2 after upstream c/s 24729:6f6a6d1d2fb6

changes in v4:
* Only tool part in this version, since hypervisor patches have already 
been committed.
* rename guest config option from "iommu = {0,1}" to "guest_iommu = {0,1}"
* add description into docs/man/xl.cfg.pod.5


changes in v3:
* Use xenstore to receive guest iommu configuration instead of adding in 
a new field in hvm_info_table.
* Support pci segment in vbdf to mbdf bind.
* Make hypercalls visible for non-x86 platforms.
* A few code cleanups according to comments from Jan and Ian.

Changes in v2:
* Do not use linked list to access guest iommu tables.
* Do not parse iommu parameter in libxl_device_model_info again.
* Fix incorrect logical calculation in patch 11.
* Fix hypercall definition for non-x86 systems.


Thanks,
Wei


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 26 14:45:09 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Sep 2012 14:45: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 1TGsrJ-0001Gf-FU; Wed, 26 Sep 2012 14:45:05 +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 1TGsrI-0001Fk-C1
	for xen-devel@lists.xensource.com; Wed, 26 Sep 2012 14:45:04 +0000
Received: from [85.158.139.83:44021] by server-15.bemta-5.messagelabs.com id
	2C/E1-19430-FE413605; Wed, 26 Sep 2012 14:45:03 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1348670701!30037762!1
X-Originating-IP: [216.32.180.11]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2826 invoked from network); 26 Sep 2012 14:45:02 -0000
Received: from va3ehsobe001.messaging.microsoft.com (HELO
	va3outboundpool.messaging.microsoft.com) (216.32.180.11)
	by server-15.tower-182.messagelabs.com with AES128-SHA encrypted SMTP;
	26 Sep 2012 14:45:02 -0000
Received: from mail169-va3-R.bigfish.com (10.7.14.244) by
	VA3EHSOBE008.bigfish.com (10.7.40.28) with Microsoft SMTP Server id
	14.1.225.23; Wed, 26 Sep 2012 14:45:00 +0000
Received: from mail169-va3 (localhost [127.0.0.1])	by
	mail169-va3-R.bigfish.com (Postfix) with ESMTP id B88A44401A6;
	Wed, 26 Sep 2012 14:45:00 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:163.181.249.109; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp02.amd.com; RD:none; EFVD:NLI
X-SpamScore: 1
X-BigFish: VPS1(zzc857hd6f1izz1202h1d1ah1d2ahzzz2dh668h839he5bhf0ah107ah1288h12a5h12bdh137ah34h1155h)
Received: from mail169-va3 (localhost.localdomain [127.0.0.1]) by mail169-va3
	(MessageSwitch) id 1348670698927223_19346;
	Wed, 26 Sep 2012 14:44:58 +0000 (UTC)
Received: from VA3EHSMHS032.bigfish.com (unknown [10.7.14.242])	by
	mail169-va3.bigfish.com (Postfix) with ESMTP id DA4F236005D;
	Wed, 26 Sep 2012 14:44:58 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	VA3EHSMHS032.bigfish.com (10.7.99.42) with Microsoft SMTP Server id
	14.1.225.23; Wed, 26 Sep 2012 14:44:54 +0000
X-WSS-ID: 0MAYOYR-02-2YH-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 2CF14C8141;	Wed, 26 Sep 2012 09:44:50 -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;
	Wed, 26 Sep 2012 09:45:05 -0500
Received: from storexhtp01.amd.com (172.24.4.3) by sausexdag02.amd.com
	(163.181.55.2) with Microsoft SMTP Server (TLS) id 14.1.323.3;
	Wed, 26 Sep 2012 09:44:52 -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, 26 Sep 2012
	10:44: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 DC98349C14F; Wed, 26 Sep 2012
	15:44:49 +0100 (BST)
Message-ID: <50631565.6070809@amd.com>
Date: Wed, 26 Sep 2012 16:47:01 +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: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	<jbeulich@suse.com>, Keir Fraser <keir@xen.org>, Ian Campbell
	<Ian.Campbell@citrix.com>, Ian Jackson <Ian.Jackson@eu.citrix.com>
Content-Type: multipart/mixed; boundary="------------000909030808070602050501"
X-OriginatorOrg: amd.com
Subject: [Xen-devel] [PATCH 3 of 6 V6] hvmloader: Build IVRS table
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--------------000909030808070602050501
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 7bit




--------------000909030808070602050501
Content-Type: text/plain; charset="UTF-8";
	name="0003-hvmloader-Build-IVRS-table.patch"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="0003-hvmloader-Build-IVRS-table.patch"
Content-Description: 0003-hvmloader-Build-IVRS-table.patch

RnJvbSAyN2IxODMwZDdiZjA0NmJkYjYzOTYyNTM3YTk4OThjOTRmYTNhZjAxIE1vbiBTZXAg
MTcgMDA6MDA6MDAgMjAwMQpGcm9tOiBXZWkgV2FuZyA8d2VpLndhbmcyQGFtZC5jb20+CkRh
dGU6IFdlZCwgMjYgU2VwIDIwMTIgMTE6NDY6MzQgKzAyMDAKU3ViamVjdDogW1BBVENIIDMv
Nl0gaHZtbG9hZGVyOiBCdWlsZCBJVlJTIHRhYmxlLgoKVGhlcmUgYXJlIDMyIGl2cnMgcGFk
ZGluZyBlbnRyaWVzIGFsbG9jYXRlZCBhdCB0aGUgYmVnaW5uaW5nLiBJZiBhIHBhc3N0aHJ1
CmRldmljZSBoYXMgYmVlbiBmb3VuZCBmcm9tIHFlbXUgYnVzLCBhIHBhZGRpbmcgZW50cnkg
d2lsbCBiZSByZXBsYWNlZCBieSBhCnJlYWwgZGV2aWNlIGVudHJ5LiBUaGlzIHBhdGNoIGhh
cyBiZWVuIHRlc3RlZCB3aXRoIGJvdGggcm9tYmlvcyBhbmQgc2VhYmlvcwoKU2lnbmVkLW9m
Zi1ieTogV2VpIFdhbmcgPHdlaS53YW5nMkBhbWQuY29tPgotLS0KIENvbmZpZy5tayAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgIDIgKy0KIHRvb2xzL2Zpcm13YXJlL2h2
bWxvYWRlci9hY3BpL2FjcGkyXzAuaCB8ICAgNTQgKysrKysrKysrKysrKysrKysrCiB0b29s
cy9maXJtd2FyZS9odm1sb2FkZXIvYWNwaS9idWlsZC5jICAgfCAgIDkxICsrKysrKysrKysr
KysrKysrKysrKysrKysrKysrKysKIHRvb2xzL2Zpcm13YXJlL2h2bWxvYWRlci9wY2kuYyAg
ICAgICAgICB8ICAgMzAgKysrKysrKysrKy0KIDQgZmlsZXMgY2hhbmdlZCwgMTc1IGluc2Vy
dGlvbnMoKyksIDIgZGVsZXRpb25zKC0pCgpkaWZmIC0tZ2l0IGEvQ29uZmlnLm1rIGIvQ29u
ZmlnLm1rCmluZGV4IGQ5OWI5YTEuLjk3NWE3ZTAgMTAwNjQ0Ci0tLSBhL0NvbmZpZy5tawor
KysgYi9Db25maWcubWsKQEAgLTIwMiw3ICsyMDIsNyBAQCBRRU1VX1VQU1RSRUFNX1VSTCA/
PSBodHRwOi8veGVuYml0cy54ZW4ub3JnL2dpdC1odHRwL3FlbXUtdXBzdHJlYW0tdW5zdGFi
bGUuZ2l0CiBTRUFCSU9TX1VQU1RSRUFNX1VSTCA/PSBodHRwOi8veGVuYml0cy54ZW4ub3Jn
L2dpdC1odHRwL3NlYWJpb3MuZ2l0CiBlbHNlCiBPVk1GX1VQU1RSRUFNX1VSTCA/PSBnaXQ6
Ly94ZW5iaXRzLnhlbi5vcmcvb3ZtZi5naXQKLVFFTVVfVVBTVFJFQU1fVVJMID89IGdpdDov
L3hlbmJpdHMueGVuLm9yZy9xZW11LXVwc3RyZWFtLXVuc3RhYmxlLmdpdAorUUVNVV9VUFNU
UkVBTV9VUkwgPz0gZ2l0Oi8vZ2l0LnFlbXUub3JnL3FlbXUuZ2l0CiBTRUFCSU9TX1VQU1RS
RUFNX1VSTCA/PSBnaXQ6Ly94ZW5iaXRzLnhlbi5vcmcvc2VhYmlvcy5naXQKIGVuZGlmCiBP
Vk1GX1VQU1RSRUFNX1JFVklTSU9OID89IGIwODU1ZjkyNWM2ZTJlMGIyMWZiYjAzZmFiNGI1
ZmI1YjY4NzY4NzEKZGlmZiAtLWdpdCBhL3Rvb2xzL2Zpcm13YXJlL2h2bWxvYWRlci9hY3Bp
L2FjcGkyXzAuaCBiL3Rvb2xzL2Zpcm13YXJlL2h2bWxvYWRlci9hY3BpL2FjcGkyXzAuaApp
bmRleCBiMjgxZWMwLi42NjkzMDViIDEwMDY0NAotLS0gYS90b29scy9maXJtd2FyZS9odm1s
b2FkZXIvYWNwaS9hY3BpMl8wLmgKKysrIGIvdG9vbHMvZmlybXdhcmUvaHZtbG9hZGVyL2Fj
cGkvYWNwaTJfMC5oCkBAIC0zODksNiArMzg5LDYwIEBAIHN0cnVjdCBhY3BpXzIwX21hZHRf
aW50c3Jjb3ZyIHsKICNkZWZpbmUgQUNQSV8yXzBfV0FFVF9SRVZJU0lPTiAweDAxCiAjZGVm
aW5lIEFDUElfMV8wX0ZBRFRfUkVWSVNJT04gMHgwMQogCisjZGVmaW5lIElWUlNfU0lHTkFU
VVJFIEFTQ0lJMzIoJ0knLCdWJywnUicsJ1MnKQorI2RlZmluZSBJVlJTX1JFVklTSU9OICAg
ICAgICAgICAxCisjZGVmaW5lIElWUlNfVkFTSVpFICAgICAgICAgICAgIDY0CisjZGVmaW5l
IElWUlNfUEFTSVpFICAgICAgICAgICAgIDUyCisjZGVmaW5lIElWUlNfR1ZBU0laRSAgICAg
ICAgICAgIDY0CisKKyNkZWZpbmUgSVZIRF9CTE9DS19UWVBFICAgICAgICAgMHgxMAorI2Rl
ZmluZSBJVkhEX0ZMQUdfSFRUVU5FTiAgICAgICAoMSA8PCAwKQorI2RlZmluZSBJVkhEX0ZM
QUdfUEFTU1BXICAgICAgICAoMSA8PCAxKQorI2RlZmluZSBJVkhEX0ZMQUdfUkVTUEFTU1BX
ICAgICAoMSA8PCAyKQorI2RlZmluZSBJVkhEX0ZMQUdfSVNPQyAgICAgICAgICAoMSA8PCAz
KQorI2RlZmluZSBJVkhEX0ZMQUdfSU9UTEJTVVAgICAgICAoMSA8PCA0KQorI2RlZmluZSBJ
VkhEX0ZMQUdfQ09IRVJFTlQgICAgICAoMSA8PCA1KQorI2RlZmluZSBJVkhEX0ZMQUdfUFJF
RlNVUCAgICAgICAoMSA8PCA2KQorI2RlZmluZSBJVkhEX0ZMQUdfUFBSU1VQICAgICAgICAo
MSA8PCA3KQorCisjZGVmaW5lIElWSERfRUZSX0dUU1VQICAgICAgICAgICgxIDw8IDIpCisj
ZGVmaW5lIElWSERfRUZSX0lBU1VQICAgICAgICAgICgxIDw8IDUpCisKKyNkZWZpbmUgSVZI
RF9TRUxFQ1RfNF9CWVRFICAgICAgMHgyCisKK3N0cnVjdCBpdnJzX2l2aGRfYmxvY2sKK3sK
KyAgICB1aW50OF90ICAgIHR5cGU7CisgICAgdWludDhfdCAgICBmbGFnczsKKyAgICB1aW50
MTZfdCAgIGxlbmd0aDsKKyAgICB1aW50MTZfdCAgIGRldmlkOworICAgIHVpbnQxNl90ICAg
Y2FwX29mZnNldDsKKyAgICB1aW50NjRfdCAgIGlvbW11X2Jhc2VfYWRkcjsKKyAgICB1aW50
MTZfdCAgIHBjaV9zZWdtZW50OworICAgIHVpbnQxNl90ICAgaW9tbXVfaW5mbzsKKyAgICB1
aW50MzJfdCAgIHJlc2VydmVkOworfTsKKworLyogSVZIRCA0LWJ5dGUgZGV2aWNlIGVudHJp
ZXMgKi8KK3N0cnVjdCBpdnJzX2l2aGRfZGV2aWNlCit7CisgICB1aW50OF90ICB0eXBlOwor
ICAgdWludDE2X3QgZGV2X2lkOworICAgdWludDhfdCAgZmxhZ3M7Cit9OworCisjZGVmaW5l
IFBUX0RFVl9NQVhfTlIgICAgICAgICAgIDMyCisjZGVmaW5lIElPTU1VX0NBUF9PRkZTRVQg
ICAgICAgIDB4NDAKK3N0cnVjdCBhY3BpXzQwX2l2cnMKK3sKKyAgICBzdHJ1Y3QgYWNwaV9o
ZWFkZXIgICAgICAgICAgICAgICAgICAgICAgaGVhZGVyOworICAgIHVpbnQzMl90ICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICBpdl9pbmZvOworICAgIHVpbnQzMl90ICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICByZXNlcnZlZFsyXTsKKyAgICBzdHJ1Y3QgaXZy
c19pdmhkX2Jsb2NrICAgICAgICAgICAgICAgICAgaXZoZF9ibG9jazsKKyAgICBzdHJ1Y3Qg
aXZyc19pdmhkX2RldmljZSAgICAgICAgICAgICAgICAgaXZoZF9kZXZpY2VbUFRfREVWX01B
WF9OUl07Cit9OworCisKICNwcmFnbWEgcGFjayAoKQogCiBzdHJ1Y3QgYWNwaV9jb25maWcg
ewpkaWZmIC0tZ2l0IGEvdG9vbHMvZmlybXdhcmUvaHZtbG9hZGVyL2FjcGkvYnVpbGQuYyBi
L3Rvb2xzL2Zpcm13YXJlL2h2bWxvYWRlci9hY3BpL2J1aWxkLmMKaW5kZXggZDA5Nzg1ZC4u
Y2EzNjk3YiAxMDA2NDQKLS0tIGEvdG9vbHMvZmlybXdhcmUvaHZtbG9hZGVyL2FjcGkvYnVp
bGQuYworKysgYi90b29scy9maXJtd2FyZS9odm1sb2FkZXIvYWNwaS9idWlsZC5jCkBAIC0y
Myw2ICsyMyw4IEBACiAjaW5jbHVkZSAic3NkdF9wbS5oIgogI2luY2x1ZGUgIi4uL2NvbmZp
Zy5oIgogI2luY2x1ZGUgIi4uL3V0aWwuaCIKKyNpbmNsdWRlICIuLi9oeXBlcmNhbGwuaCIK
KyNpbmNsdWRlIDx4ZW4vaHZtL3BhcmFtcy5oPgogCiAjZGVmaW5lIGFsaWduMTYoc3opICAg
ICAgICAoKChzeikgKyAxNSkgJiB+MTUpCiAjZGVmaW5lIGZpeGVkX3N0cmNweShkLCBzKSBz
dHJuY3B5KChkKSwgKHMpLCBzaXplb2YoZCkpCkBAIC0xOTgsNiArMjAwLDg3IEBAIHN0YXRp
YyBzdHJ1Y3QgYWNwaV8yMF93YWV0ICpjb25zdHJ1Y3Rfd2FldCh2b2lkKQogICAgIHJldHVy
biB3YWV0OwogfQogCitleHRlcm4gdWludDMyX3QgcHRkZXZfYmRmW1BUX0RFVl9NQVhfTlJd
OworZXh0ZXJuIHVpbnQzMl90IHB0ZGV2X25yOworZXh0ZXJuIHVpbnQzMl90IGlvbW11X2Jk
ZjsKK3N0YXRpYyBzdHJ1Y3QgYWNwaV80MF9pdnJzKiBjb25zdHJ1Y3RfaXZycyh2b2lkKQor
eworICAgIHN0cnVjdCBhY3BpXzQwX2l2cnMgKml2cnM7CisgICAgdWludDY0X3QgbW1pbzsK
KyAgICBzdHJ1Y3QgaXZyc19pdmhkX2Jsb2NrICppdmhkOworICAgIHN0cnVjdCBpdnJzX2l2
aGRfZGV2aWNlICpkZXZfZW50cnk7CisgICAgc3RydWN0IHhlbl9odm1fcGFyYW0gcDsKKwor
ICAgIGlmIChwdGRldl9uciA9PSAwIHx8IGlvbW11X2JkZiA9PSAwKSByZXR1cm4gTlVMTDsK
KworICAgIGl2cnMgPSBtZW1fYWxsb2Moc2l6ZW9mKCppdnJzKSwgMTYpOworICAgIGlmICgh
aXZycykgCisgICAgeworICAgICAgICBwcmludGYoInVuYWJsZSB0byBidWlsZCBJVlJTIHRh
Ymxlczogb3V0IG9mIG1lbW9yeVxuIik7CisgICAgICAgIHJldHVybiBOVUxMOworICAgIH0K
KyAgICBtZW1zZXQoaXZycywgMCwgc2l6ZW9mKCppdnJzKSk7CisKKyAgICAvKiBpbml0aWFs
aXplIGFjcGkgaGVhZGVyICovCisgICAgaXZycy0+aGVhZGVyLnNpZ25hdHVyZSA9IElWUlNf
U0lHTkFUVVJFOworICAgIGl2cnMtPmhlYWRlci5yZXZpc2lvbiA9IElWUlNfUkVWSVNJT047
CisgICAgZml4ZWRfc3RyY3B5KGl2cnMtPmhlYWRlci5vZW1faWQsIEFDUElfT0VNX0lEKTsK
KyAgICBmaXhlZF9zdHJjcHkoaXZycy0+aGVhZGVyLm9lbV90YWJsZV9pZCwgQUNQSV9PRU1f
VEFCTEVfSUQpOworCisgICAgaXZycy0+aGVhZGVyLm9lbV9yZXZpc2lvbiA9IEFDUElfT0VN
X1JFVklTSU9OOworICAgIGl2cnMtPmhlYWRlci5jcmVhdG9yX2lkICAgPSBBQ1BJX0NSRUFU
T1JfSUQ7CisgICAgaXZycy0+aGVhZGVyLmNyZWF0b3JfcmV2aXNpb24gPSBBQ1BJX0NSRUFU
T1JfUkVWSVNJT047CisKKyAgICBpdnJzLT5oZWFkZXIubGVuZ3RoID0gc2l6ZW9mKCppdnJz
KTsKKworICAgIC8qIGluaXRpYWxpemUgSVZIRCBCbG9jayAqLworICAgIGl2aGQgPSAmaXZy
cy0+aXZoZF9ibG9jazsKKyAgICBpdnJzLT5pdl9pbmZvID0gKElWUlNfVkFTSVpFIDw8IDE1
KSB8IChJVlJTX1BBU0laRSA8PCA4KSB8CisgICAgICAgICAgICAgICAgICAgIChJVlJTX0dW
QVNJWkUgPDwgNSk7CisKKyAgICBpdmhkLT50eXBlICAgICAgICAgID0gSVZIRF9CTE9DS19U
WVBFOworICAgIGl2aGQtPmZsYWdzICAgICAgICAgPSBJVkhEX0ZMQUdfUFBSU1VQIHwgSVZI
RF9GTEFHX0lPVExCU1VQOworICAgIGl2aGQtPmRldmlkICAgICAgICAgPSBpb21tdV9iZGY7
CisgICAgaXZoZC0+Y2FwX29mZnNldCAgICA9IElPTU1VX0NBUF9PRkZTRVQ7CisKKyAgICAv
KnJlc2VydmUgMzJLIElPTU1VIE1NSU8gc3BhY2UgKi8KKyAgICBtbWlvID0gdmlydF90b19w
aHlzKG1lbV9hbGxvYygweDgwMDAsIDB4MTAwMCkpOworICAgIGlmICghbW1pbykgCisgICAg
eyAgIAorICAgICAgICBwcmludGYoInVuYWJsZSB0byByZXNlcnZlIGlvbW11IG1taW8gcGFn
ZXM6IG91dCBvZiBtZW1vcnlcbiIpOworICAgICAgICByZXR1cm4gTlVMTDsKKyAgICB9Cisg
ICAgCisgICAgcC5kb21pZCA9IERPTUlEX1NFTEY7CisgICAgcC5pbmRleCA9IEhWTV9QQVJB
TV9JT01NVV9CQVNFOworICAgIHAudmFsdWUgPSBtbWlvOworCisgICAgLyogUmV0dXJuIG5v
bi16ZXJvIGlmIElPTU1VdjIgaGFyZHdhcmUgaXMgbm90IGF2YWxpYWJsZSAqLworICAgIGlm
ICggaHlwZXJjYWxsX2h2bV9vcChIVk1PUF9zZXRfcGFyYW0sICZwKSApCisgICAgeworICAg
ICAgICBwcmludGYoInVuYWJsZSB0byBzZXQgaW9tbXUgbW1pbyBiYXNlIGFkZHJlc3NcbiIp
OworICAgICAgICByZXR1cm4gTlVMTDsKKyAgICB9CisgICAgICAgIAorICAgIGl2aGQtPmlv
bW11X2Jhc2VfYWRkciA9IG1taW87CisgICAgaXZoZC0+cmVzZXJ2ZWQgPSBJVkhEX0VGUl9J
QVNVUCB8IElWSERfRUZSX0dUU1VQOworCisgICAgLyogQnVpbGQgSVZIRCBkZXZpY2UgZW50
cmllcyAqLworICAgIGRldl9lbnRyeSA9IGl2cnMtPml2aGRfZGV2aWNlOworICAgIGZvciAo
IGludCBpID0gMDsgaSA8IHB0ZGV2X25yOyBpKysgKQorICAgIHsKKyAgICAgICAgZGV2X2Vu
dHJ5W2ldLnR5cGUgICA9IElWSERfU0VMRUNUXzRfQllURTsKKyAgICAgICAgZGV2X2VudHJ5
W2ldLmRldl9pZCA9IHB0ZGV2X2JkZltpXTsKKyAgICAgICAgZGV2X2VudHJ5W2ldLmZsYWdz
ICA9IDA7CisgICAgfQorCisgICAgaXZoZC0+bGVuZ3RoID0gc2l6ZW9mKCppdmhkKSArIHNp
emVvZigqZGV2X2VudHJ5KSAqIFBUX0RFVl9NQVhfTlI7CisgICAgc2V0X2NoZWNrc3VtKGl2
cnMsIG9mZnNldG9mKHN0cnVjdCBhY3BpX2hlYWRlciwgY2hlY2tzdW0pLCAKKyAgICAgICAg
ICAgICAgICAgaXZycy0+aGVhZGVyLmxlbmd0aCk7CisKKyAgICByZXR1cm4gaXZyczsKK30K
Kwogc3RhdGljIGludCBjb25zdHJ1Y3Rfc2Vjb25kYXJ5X3RhYmxlcyh1bnNpZ25lZCBsb25n
ICp0YWJsZV9wdHJzLAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBz
dHJ1Y3QgYWNwaV9pbmZvICppbmZvKQogewpAQCAtMjA2LDYgKzI4OSw3IEBAIHN0YXRpYyBp
bnQgY29uc3RydWN0X3NlY29uZGFyeV90YWJsZXModW5zaWduZWQgbG9uZyAqdGFibGVfcHRy
cywKICAgICBzdHJ1Y3QgYWNwaV8yMF9ocGV0ICpocGV0OwogICAgIHN0cnVjdCBhY3BpXzIw
X3dhZXQgKndhZXQ7CiAgICAgc3RydWN0IGFjcGlfMjBfdGNwYSAqdGNwYTsKKyAgICBzdHJ1
Y3QgYWNwaV80MF9pdnJzICppdnJzOwogICAgIHVuc2lnbmVkIGNoYXIgKnNzZHQ7CiAgICAg
c3RhdGljIGNvbnN0IHVpbnQxNl90IHRpc19zaWduYXR1cmVbXSA9IHsweDAwMDEsIDB4MDAw
MSwgMHgwMDAxfTsKICAgICB1aW50MTZfdCAqdGlzX2hkcjsKQEAgLTI5Myw2ICszNzcsMTMg
QEAgc3RhdGljIGludCBjb25zdHJ1Y3Rfc2Vjb25kYXJ5X3RhYmxlcyh1bnNpZ25lZCBsb25n
ICp0YWJsZV9wdHJzLAogICAgICAgICB9CiAgICAgfQogCisgICAgaWYgKCAhc3RybmNtcCh4
ZW5zdG9yZV9yZWFkKCJndWVzdF9pb21tdSIsICIxIiksICIxIiwgMSkgKQorICAgIHsKKyAg
ICAgICAgaXZycyA9IGNvbnN0cnVjdF9pdnJzKCk7CisgICAgICAgIGlmICggaXZycyAhPSBO
VUxMICkKKyAgICAgICAgICAgIHRhYmxlX3B0cnNbbnJfdGFibGVzKytdID0gKHVuc2lnbmVk
IGxvbmcpaXZyczsKKyAgICB9CisKICAgICB0YWJsZV9wdHJzW25yX3RhYmxlc10gPSAwOwog
ICAgIHJldHVybiBucl90YWJsZXM7CiB9CmRpZmYgLS1naXQgYS90b29scy9maXJtd2FyZS9o
dm1sb2FkZXIvcGNpLmMgYi90b29scy9maXJtd2FyZS9odm1sb2FkZXIvcGNpLmMKaW5kZXgg
ZmQ1NmU1MC4uY2Q4ZTgyMSAxMDA2NDQKLS0tIGEvdG9vbHMvZmlybXdhcmUvaHZtbG9hZGVy
L3BjaS5jCisrKyBiL3Rvb2xzL2Zpcm13YXJlL2h2bWxvYWRlci9wY2kuYwpAQCAtMzQsMTEg
KzM0LDE3IEBAIHVuc2lnbmVkIGxvbmcgcGNpX21lbV9lbmQgPSBQQ0lfTUVNX0VORDsKIGVu
dW0gdmlydHVhbF92Z2EgdmlydHVhbF92Z2EgPSBWR0Ffbm9uZTsKIHVuc2lnbmVkIGxvbmcg
aWdkX29wcmVnaW9uX3BnYmFzZSA9IDA7CiAKKy8qIHN1cHBvcnQgdXAgdG8gMzIgcGFzc3Ro
cm91Z2ggZGV2aWNlcyAqLworI2RlZmluZSBQVF9ERVZfTUFYX05SICAgICAgICAgICAzMgor
dWludDMyX3QgcHRkZXZfYmRmW1BUX0RFVl9NQVhfTlJdOwordWludDMyX3QgcHRkZXZfbnI7
Cit1aW50MzJfdCBpb21tdV9iZGYgPSAwOworCiB2b2lkIHBjaV9zZXR1cCh2b2lkKQogewog
ICAgIHVpbnQzMl90IGJhc2UsIGRldmZuLCBiYXJfcmVnLCBiYXJfZGF0YSwgYmFyX3N6LCBj
bWQsIG1taW9fdG90YWwgPSAwOwogICAgIHVpbnQzMl90IHZnYV9kZXZmbiA9IDI1NjsKLSAg
ICB1aW50MTZfdCBjbGFzcywgdmVuZG9yX2lkLCBkZXZpY2VfaWQ7CisgICAgdWludDE2X3Qg
Y2xhc3MsIHZlbmRvcl9pZCwgZGV2aWNlX2lkLCBzdWJfdmVuZG9yX2lkOwogICAgIHVuc2ln
bmVkIGludCBiYXIsIHBpbiwgbGluaywgaXNhX2lycTsKIAogICAgIC8qIFJlc291cmNlcyBh
c3NpZ25hYmxlIHRvIFBDSSBkZXZpY2VzIHZpYSBCQVJzLiAqLwpAQCAtNzIsMTIgKzc4LDM0
IEBAIHZvaWQgcGNpX3NldHVwKHZvaWQpCiAgICAgICAgIGNsYXNzICAgICA9IHBjaV9yZWFk
dyhkZXZmbiwgUENJX0NMQVNTX0RFVklDRSk7CiAgICAgICAgIHZlbmRvcl9pZCA9IHBjaV9y
ZWFkdyhkZXZmbiwgUENJX1ZFTkRPUl9JRCk7CiAgICAgICAgIGRldmljZV9pZCA9IHBjaV9y
ZWFkdyhkZXZmbiwgUENJX0RFVklDRV9JRCk7CisgICAgICAgIHN1Yl92ZW5kb3JfaWQgPSBw
Y2lfcmVhZHcoZGV2Zm4sIFBDSV9TVUJTWVNURU1fVkVORE9SX0lEKTsKKwogICAgICAgICBp
ZiAoICh2ZW5kb3JfaWQgPT0gMHhmZmZmKSAmJiAoZGV2aWNlX2lkID09IDB4ZmZmZikgKQog
ICAgICAgICAgICAgY29udGludWU7CiAKICAgICAgICAgQVNTRVJUKChkZXZmbiAhPSBQQ0lf
SVNBX0RFVkZOKSB8fAogICAgICAgICAgICAgICAgKCh2ZW5kb3JfaWQgPT0gMHg4MDg2KSAm
JiAoZGV2aWNlX2lkID09IDB4NzAwMCkpKTsKIAorICAgICAgICAvKiBGb3VuZCBhbWQgaW9t
bXUgZGV2aWNlLiAqLworICAgICAgICBpZiAoIGNsYXNzID09IDB4MDgwNiAmJiB2ZW5kb3Jf
aWQgPT0gMHgxMDIyICkKKyAgICAgICAgeworICAgICAgICAgICAgaW9tbXVfYmRmID0gZGV2
Zm47CisgICAgICAgICAgICBjb250aW51ZTsKKyAgICAgICAgfQorICAgICAgICAvKiBJVlJT
OiBEZXRlY3RpbmcgcGFzc3Rocm91Z2ggZGV2aWNlcy4KKyAgICAgICAgICogc3ViX3ZlbmRv
cl9pZCAhPSBjaXRyaXggJiYgc3ViX3ZlbmRvcl9pZCAhPSBxZW11ICovCisgICAgICAgIGlm
ICggc3ViX3ZlbmRvcl9pZCAhPSAweDU4NTMgJiYgc3ViX3ZlbmRvcl9pZCAhPSAweDFhZjQg
KQorICAgICAgICB7CisgICAgICAgICAgICAvKiBmb3VuZCBhIHBhc3N0aHJ1IGRldmljZSAq
LworICAgICAgICAgICAgaWYgKCBwdGRldl9uciA8IFBUX0RFVl9NQVhfTlIgKQorICAgICAg
ICAgICAgeworICAgICAgICAgICAgICAgIHB0ZGV2X2JkZltwdGRldl9ucl0gPSBkZXZmbjsK
KyAgICAgICAgICAgICAgICBwdGRldl9ucisrOworICAgICAgICAgICAgfQorICAgICAgICAg
ICAgZWxzZQorICAgICAgICAgICAgICAgIHByaW50ZigiTnVtYmVyIG9mIHBhc3N0aHJ1IGRl
dmljZXMgPiBQVF9ERVZfTUFYX05SIFxuIik7CisgICAgICAgIH0KKwogICAgICAgICBzd2l0
Y2ggKCBjbGFzcyApCiAgICAgICAgIHsKICAgICAgICAgY2FzZSAweDAzMDA6Ci0tIAoxLjcu
NAoKCg==
--------------000909030808070602050501
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--------------000909030808070602050501--


From xen-devel-bounces@lists.xen.org Wed Sep 26 14:45:09 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Sep 2012 14:45: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 1TGsrJ-0001Gf-FU; Wed, 26 Sep 2012 14:45:05 +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 1TGsrI-0001Fk-C1
	for xen-devel@lists.xensource.com; Wed, 26 Sep 2012 14:45:04 +0000
Received: from [85.158.139.83:44021] by server-15.bemta-5.messagelabs.com id
	2C/E1-19430-FE413605; Wed, 26 Sep 2012 14:45:03 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1348670701!30037762!1
X-Originating-IP: [216.32.180.11]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2826 invoked from network); 26 Sep 2012 14:45:02 -0000
Received: from va3ehsobe001.messaging.microsoft.com (HELO
	va3outboundpool.messaging.microsoft.com) (216.32.180.11)
	by server-15.tower-182.messagelabs.com with AES128-SHA encrypted SMTP;
	26 Sep 2012 14:45:02 -0000
Received: from mail169-va3-R.bigfish.com (10.7.14.244) by
	VA3EHSOBE008.bigfish.com (10.7.40.28) with Microsoft SMTP Server id
	14.1.225.23; Wed, 26 Sep 2012 14:45:00 +0000
Received: from mail169-va3 (localhost [127.0.0.1])	by
	mail169-va3-R.bigfish.com (Postfix) with ESMTP id B88A44401A6;
	Wed, 26 Sep 2012 14:45:00 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:163.181.249.109; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp02.amd.com; RD:none; EFVD:NLI
X-SpamScore: 1
X-BigFish: VPS1(zzc857hd6f1izz1202h1d1ah1d2ahzzz2dh668h839he5bhf0ah107ah1288h12a5h12bdh137ah34h1155h)
Received: from mail169-va3 (localhost.localdomain [127.0.0.1]) by mail169-va3
	(MessageSwitch) id 1348670698927223_19346;
	Wed, 26 Sep 2012 14:44:58 +0000 (UTC)
Received: from VA3EHSMHS032.bigfish.com (unknown [10.7.14.242])	by
	mail169-va3.bigfish.com (Postfix) with ESMTP id DA4F236005D;
	Wed, 26 Sep 2012 14:44:58 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	VA3EHSMHS032.bigfish.com (10.7.99.42) with Microsoft SMTP Server id
	14.1.225.23; Wed, 26 Sep 2012 14:44:54 +0000
X-WSS-ID: 0MAYOYR-02-2YH-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 2CF14C8141;	Wed, 26 Sep 2012 09:44:50 -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;
	Wed, 26 Sep 2012 09:45:05 -0500
Received: from storexhtp01.amd.com (172.24.4.3) by sausexdag02.amd.com
	(163.181.55.2) with Microsoft SMTP Server (TLS) id 14.1.323.3;
	Wed, 26 Sep 2012 09:44:52 -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, 26 Sep 2012
	10:44: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 DC98349C14F; Wed, 26 Sep 2012
	15:44:49 +0100 (BST)
Message-ID: <50631565.6070809@amd.com>
Date: Wed, 26 Sep 2012 16:47:01 +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: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	<jbeulich@suse.com>, Keir Fraser <keir@xen.org>, Ian Campbell
	<Ian.Campbell@citrix.com>, Ian Jackson <Ian.Jackson@eu.citrix.com>
Content-Type: multipart/mixed; boundary="------------000909030808070602050501"
X-OriginatorOrg: amd.com
Subject: [Xen-devel] [PATCH 3 of 6 V6] hvmloader: Build IVRS table
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--------------000909030808070602050501
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 7bit




--------------000909030808070602050501
Content-Type: text/plain; charset="UTF-8";
	name="0003-hvmloader-Build-IVRS-table.patch"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="0003-hvmloader-Build-IVRS-table.patch"
Content-Description: 0003-hvmloader-Build-IVRS-table.patch

RnJvbSAyN2IxODMwZDdiZjA0NmJkYjYzOTYyNTM3YTk4OThjOTRmYTNhZjAxIE1vbiBTZXAg
MTcgMDA6MDA6MDAgMjAwMQpGcm9tOiBXZWkgV2FuZyA8d2VpLndhbmcyQGFtZC5jb20+CkRh
dGU6IFdlZCwgMjYgU2VwIDIwMTIgMTE6NDY6MzQgKzAyMDAKU3ViamVjdDogW1BBVENIIDMv
Nl0gaHZtbG9hZGVyOiBCdWlsZCBJVlJTIHRhYmxlLgoKVGhlcmUgYXJlIDMyIGl2cnMgcGFk
ZGluZyBlbnRyaWVzIGFsbG9jYXRlZCBhdCB0aGUgYmVnaW5uaW5nLiBJZiBhIHBhc3N0aHJ1
CmRldmljZSBoYXMgYmVlbiBmb3VuZCBmcm9tIHFlbXUgYnVzLCBhIHBhZGRpbmcgZW50cnkg
d2lsbCBiZSByZXBsYWNlZCBieSBhCnJlYWwgZGV2aWNlIGVudHJ5LiBUaGlzIHBhdGNoIGhh
cyBiZWVuIHRlc3RlZCB3aXRoIGJvdGggcm9tYmlvcyBhbmQgc2VhYmlvcwoKU2lnbmVkLW9m
Zi1ieTogV2VpIFdhbmcgPHdlaS53YW5nMkBhbWQuY29tPgotLS0KIENvbmZpZy5tayAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgIDIgKy0KIHRvb2xzL2Zpcm13YXJlL2h2
bWxvYWRlci9hY3BpL2FjcGkyXzAuaCB8ICAgNTQgKysrKysrKysrKysrKysrKysrCiB0b29s
cy9maXJtd2FyZS9odm1sb2FkZXIvYWNwaS9idWlsZC5jICAgfCAgIDkxICsrKysrKysrKysr
KysrKysrKysrKysrKysrKysrKysKIHRvb2xzL2Zpcm13YXJlL2h2bWxvYWRlci9wY2kuYyAg
ICAgICAgICB8ICAgMzAgKysrKysrKysrKy0KIDQgZmlsZXMgY2hhbmdlZCwgMTc1IGluc2Vy
dGlvbnMoKyksIDIgZGVsZXRpb25zKC0pCgpkaWZmIC0tZ2l0IGEvQ29uZmlnLm1rIGIvQ29u
ZmlnLm1rCmluZGV4IGQ5OWI5YTEuLjk3NWE3ZTAgMTAwNjQ0Ci0tLSBhL0NvbmZpZy5tawor
KysgYi9Db25maWcubWsKQEAgLTIwMiw3ICsyMDIsNyBAQCBRRU1VX1VQU1RSRUFNX1VSTCA/
PSBodHRwOi8veGVuYml0cy54ZW4ub3JnL2dpdC1odHRwL3FlbXUtdXBzdHJlYW0tdW5zdGFi
bGUuZ2l0CiBTRUFCSU9TX1VQU1RSRUFNX1VSTCA/PSBodHRwOi8veGVuYml0cy54ZW4ub3Jn
L2dpdC1odHRwL3NlYWJpb3MuZ2l0CiBlbHNlCiBPVk1GX1VQU1RSRUFNX1VSTCA/PSBnaXQ6
Ly94ZW5iaXRzLnhlbi5vcmcvb3ZtZi5naXQKLVFFTVVfVVBTVFJFQU1fVVJMID89IGdpdDov
L3hlbmJpdHMueGVuLm9yZy9xZW11LXVwc3RyZWFtLXVuc3RhYmxlLmdpdAorUUVNVV9VUFNU
UkVBTV9VUkwgPz0gZ2l0Oi8vZ2l0LnFlbXUub3JnL3FlbXUuZ2l0CiBTRUFCSU9TX1VQU1RS
RUFNX1VSTCA/PSBnaXQ6Ly94ZW5iaXRzLnhlbi5vcmcvc2VhYmlvcy5naXQKIGVuZGlmCiBP
Vk1GX1VQU1RSRUFNX1JFVklTSU9OID89IGIwODU1ZjkyNWM2ZTJlMGIyMWZiYjAzZmFiNGI1
ZmI1YjY4NzY4NzEKZGlmZiAtLWdpdCBhL3Rvb2xzL2Zpcm13YXJlL2h2bWxvYWRlci9hY3Bp
L2FjcGkyXzAuaCBiL3Rvb2xzL2Zpcm13YXJlL2h2bWxvYWRlci9hY3BpL2FjcGkyXzAuaApp
bmRleCBiMjgxZWMwLi42NjkzMDViIDEwMDY0NAotLS0gYS90b29scy9maXJtd2FyZS9odm1s
b2FkZXIvYWNwaS9hY3BpMl8wLmgKKysrIGIvdG9vbHMvZmlybXdhcmUvaHZtbG9hZGVyL2Fj
cGkvYWNwaTJfMC5oCkBAIC0zODksNiArMzg5LDYwIEBAIHN0cnVjdCBhY3BpXzIwX21hZHRf
aW50c3Jjb3ZyIHsKICNkZWZpbmUgQUNQSV8yXzBfV0FFVF9SRVZJU0lPTiAweDAxCiAjZGVm
aW5lIEFDUElfMV8wX0ZBRFRfUkVWSVNJT04gMHgwMQogCisjZGVmaW5lIElWUlNfU0lHTkFU
VVJFIEFTQ0lJMzIoJ0knLCdWJywnUicsJ1MnKQorI2RlZmluZSBJVlJTX1JFVklTSU9OICAg
ICAgICAgICAxCisjZGVmaW5lIElWUlNfVkFTSVpFICAgICAgICAgICAgIDY0CisjZGVmaW5l
IElWUlNfUEFTSVpFICAgICAgICAgICAgIDUyCisjZGVmaW5lIElWUlNfR1ZBU0laRSAgICAg
ICAgICAgIDY0CisKKyNkZWZpbmUgSVZIRF9CTE9DS19UWVBFICAgICAgICAgMHgxMAorI2Rl
ZmluZSBJVkhEX0ZMQUdfSFRUVU5FTiAgICAgICAoMSA8PCAwKQorI2RlZmluZSBJVkhEX0ZM
QUdfUEFTU1BXICAgICAgICAoMSA8PCAxKQorI2RlZmluZSBJVkhEX0ZMQUdfUkVTUEFTU1BX
ICAgICAoMSA8PCAyKQorI2RlZmluZSBJVkhEX0ZMQUdfSVNPQyAgICAgICAgICAoMSA8PCAz
KQorI2RlZmluZSBJVkhEX0ZMQUdfSU9UTEJTVVAgICAgICAoMSA8PCA0KQorI2RlZmluZSBJ
VkhEX0ZMQUdfQ09IRVJFTlQgICAgICAoMSA8PCA1KQorI2RlZmluZSBJVkhEX0ZMQUdfUFJF
RlNVUCAgICAgICAoMSA8PCA2KQorI2RlZmluZSBJVkhEX0ZMQUdfUFBSU1VQICAgICAgICAo
MSA8PCA3KQorCisjZGVmaW5lIElWSERfRUZSX0dUU1VQICAgICAgICAgICgxIDw8IDIpCisj
ZGVmaW5lIElWSERfRUZSX0lBU1VQICAgICAgICAgICgxIDw8IDUpCisKKyNkZWZpbmUgSVZI
RF9TRUxFQ1RfNF9CWVRFICAgICAgMHgyCisKK3N0cnVjdCBpdnJzX2l2aGRfYmxvY2sKK3sK
KyAgICB1aW50OF90ICAgIHR5cGU7CisgICAgdWludDhfdCAgICBmbGFnczsKKyAgICB1aW50
MTZfdCAgIGxlbmd0aDsKKyAgICB1aW50MTZfdCAgIGRldmlkOworICAgIHVpbnQxNl90ICAg
Y2FwX29mZnNldDsKKyAgICB1aW50NjRfdCAgIGlvbW11X2Jhc2VfYWRkcjsKKyAgICB1aW50
MTZfdCAgIHBjaV9zZWdtZW50OworICAgIHVpbnQxNl90ICAgaW9tbXVfaW5mbzsKKyAgICB1
aW50MzJfdCAgIHJlc2VydmVkOworfTsKKworLyogSVZIRCA0LWJ5dGUgZGV2aWNlIGVudHJp
ZXMgKi8KK3N0cnVjdCBpdnJzX2l2aGRfZGV2aWNlCit7CisgICB1aW50OF90ICB0eXBlOwor
ICAgdWludDE2X3QgZGV2X2lkOworICAgdWludDhfdCAgZmxhZ3M7Cit9OworCisjZGVmaW5l
IFBUX0RFVl9NQVhfTlIgICAgICAgICAgIDMyCisjZGVmaW5lIElPTU1VX0NBUF9PRkZTRVQg
ICAgICAgIDB4NDAKK3N0cnVjdCBhY3BpXzQwX2l2cnMKK3sKKyAgICBzdHJ1Y3QgYWNwaV9o
ZWFkZXIgICAgICAgICAgICAgICAgICAgICAgaGVhZGVyOworICAgIHVpbnQzMl90ICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICBpdl9pbmZvOworICAgIHVpbnQzMl90ICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICByZXNlcnZlZFsyXTsKKyAgICBzdHJ1Y3QgaXZy
c19pdmhkX2Jsb2NrICAgICAgICAgICAgICAgICAgaXZoZF9ibG9jazsKKyAgICBzdHJ1Y3Qg
aXZyc19pdmhkX2RldmljZSAgICAgICAgICAgICAgICAgaXZoZF9kZXZpY2VbUFRfREVWX01B
WF9OUl07Cit9OworCisKICNwcmFnbWEgcGFjayAoKQogCiBzdHJ1Y3QgYWNwaV9jb25maWcg
ewpkaWZmIC0tZ2l0IGEvdG9vbHMvZmlybXdhcmUvaHZtbG9hZGVyL2FjcGkvYnVpbGQuYyBi
L3Rvb2xzL2Zpcm13YXJlL2h2bWxvYWRlci9hY3BpL2J1aWxkLmMKaW5kZXggZDA5Nzg1ZC4u
Y2EzNjk3YiAxMDA2NDQKLS0tIGEvdG9vbHMvZmlybXdhcmUvaHZtbG9hZGVyL2FjcGkvYnVp
bGQuYworKysgYi90b29scy9maXJtd2FyZS9odm1sb2FkZXIvYWNwaS9idWlsZC5jCkBAIC0y
Myw2ICsyMyw4IEBACiAjaW5jbHVkZSAic3NkdF9wbS5oIgogI2luY2x1ZGUgIi4uL2NvbmZp
Zy5oIgogI2luY2x1ZGUgIi4uL3V0aWwuaCIKKyNpbmNsdWRlICIuLi9oeXBlcmNhbGwuaCIK
KyNpbmNsdWRlIDx4ZW4vaHZtL3BhcmFtcy5oPgogCiAjZGVmaW5lIGFsaWduMTYoc3opICAg
ICAgICAoKChzeikgKyAxNSkgJiB+MTUpCiAjZGVmaW5lIGZpeGVkX3N0cmNweShkLCBzKSBz
dHJuY3B5KChkKSwgKHMpLCBzaXplb2YoZCkpCkBAIC0xOTgsNiArMjAwLDg3IEBAIHN0YXRp
YyBzdHJ1Y3QgYWNwaV8yMF93YWV0ICpjb25zdHJ1Y3Rfd2FldCh2b2lkKQogICAgIHJldHVy
biB3YWV0OwogfQogCitleHRlcm4gdWludDMyX3QgcHRkZXZfYmRmW1BUX0RFVl9NQVhfTlJd
OworZXh0ZXJuIHVpbnQzMl90IHB0ZGV2X25yOworZXh0ZXJuIHVpbnQzMl90IGlvbW11X2Jk
ZjsKK3N0YXRpYyBzdHJ1Y3QgYWNwaV80MF9pdnJzKiBjb25zdHJ1Y3RfaXZycyh2b2lkKQor
eworICAgIHN0cnVjdCBhY3BpXzQwX2l2cnMgKml2cnM7CisgICAgdWludDY0X3QgbW1pbzsK
KyAgICBzdHJ1Y3QgaXZyc19pdmhkX2Jsb2NrICppdmhkOworICAgIHN0cnVjdCBpdnJzX2l2
aGRfZGV2aWNlICpkZXZfZW50cnk7CisgICAgc3RydWN0IHhlbl9odm1fcGFyYW0gcDsKKwor
ICAgIGlmIChwdGRldl9uciA9PSAwIHx8IGlvbW11X2JkZiA9PSAwKSByZXR1cm4gTlVMTDsK
KworICAgIGl2cnMgPSBtZW1fYWxsb2Moc2l6ZW9mKCppdnJzKSwgMTYpOworICAgIGlmICgh
aXZycykgCisgICAgeworICAgICAgICBwcmludGYoInVuYWJsZSB0byBidWlsZCBJVlJTIHRh
Ymxlczogb3V0IG9mIG1lbW9yeVxuIik7CisgICAgICAgIHJldHVybiBOVUxMOworICAgIH0K
KyAgICBtZW1zZXQoaXZycywgMCwgc2l6ZW9mKCppdnJzKSk7CisKKyAgICAvKiBpbml0aWFs
aXplIGFjcGkgaGVhZGVyICovCisgICAgaXZycy0+aGVhZGVyLnNpZ25hdHVyZSA9IElWUlNf
U0lHTkFUVVJFOworICAgIGl2cnMtPmhlYWRlci5yZXZpc2lvbiA9IElWUlNfUkVWSVNJT047
CisgICAgZml4ZWRfc3RyY3B5KGl2cnMtPmhlYWRlci5vZW1faWQsIEFDUElfT0VNX0lEKTsK
KyAgICBmaXhlZF9zdHJjcHkoaXZycy0+aGVhZGVyLm9lbV90YWJsZV9pZCwgQUNQSV9PRU1f
VEFCTEVfSUQpOworCisgICAgaXZycy0+aGVhZGVyLm9lbV9yZXZpc2lvbiA9IEFDUElfT0VN
X1JFVklTSU9OOworICAgIGl2cnMtPmhlYWRlci5jcmVhdG9yX2lkICAgPSBBQ1BJX0NSRUFU
T1JfSUQ7CisgICAgaXZycy0+aGVhZGVyLmNyZWF0b3JfcmV2aXNpb24gPSBBQ1BJX0NSRUFU
T1JfUkVWSVNJT047CisKKyAgICBpdnJzLT5oZWFkZXIubGVuZ3RoID0gc2l6ZW9mKCppdnJz
KTsKKworICAgIC8qIGluaXRpYWxpemUgSVZIRCBCbG9jayAqLworICAgIGl2aGQgPSAmaXZy
cy0+aXZoZF9ibG9jazsKKyAgICBpdnJzLT5pdl9pbmZvID0gKElWUlNfVkFTSVpFIDw8IDE1
KSB8IChJVlJTX1BBU0laRSA8PCA4KSB8CisgICAgICAgICAgICAgICAgICAgIChJVlJTX0dW
QVNJWkUgPDwgNSk7CisKKyAgICBpdmhkLT50eXBlICAgICAgICAgID0gSVZIRF9CTE9DS19U
WVBFOworICAgIGl2aGQtPmZsYWdzICAgICAgICAgPSBJVkhEX0ZMQUdfUFBSU1VQIHwgSVZI
RF9GTEFHX0lPVExCU1VQOworICAgIGl2aGQtPmRldmlkICAgICAgICAgPSBpb21tdV9iZGY7
CisgICAgaXZoZC0+Y2FwX29mZnNldCAgICA9IElPTU1VX0NBUF9PRkZTRVQ7CisKKyAgICAv
KnJlc2VydmUgMzJLIElPTU1VIE1NSU8gc3BhY2UgKi8KKyAgICBtbWlvID0gdmlydF90b19w
aHlzKG1lbV9hbGxvYygweDgwMDAsIDB4MTAwMCkpOworICAgIGlmICghbW1pbykgCisgICAg
eyAgIAorICAgICAgICBwcmludGYoInVuYWJsZSB0byByZXNlcnZlIGlvbW11IG1taW8gcGFn
ZXM6IG91dCBvZiBtZW1vcnlcbiIpOworICAgICAgICByZXR1cm4gTlVMTDsKKyAgICB9Cisg
ICAgCisgICAgcC5kb21pZCA9IERPTUlEX1NFTEY7CisgICAgcC5pbmRleCA9IEhWTV9QQVJB
TV9JT01NVV9CQVNFOworICAgIHAudmFsdWUgPSBtbWlvOworCisgICAgLyogUmV0dXJuIG5v
bi16ZXJvIGlmIElPTU1VdjIgaGFyZHdhcmUgaXMgbm90IGF2YWxpYWJsZSAqLworICAgIGlm
ICggaHlwZXJjYWxsX2h2bV9vcChIVk1PUF9zZXRfcGFyYW0sICZwKSApCisgICAgeworICAg
ICAgICBwcmludGYoInVuYWJsZSB0byBzZXQgaW9tbXUgbW1pbyBiYXNlIGFkZHJlc3NcbiIp
OworICAgICAgICByZXR1cm4gTlVMTDsKKyAgICB9CisgICAgICAgIAorICAgIGl2aGQtPmlv
bW11X2Jhc2VfYWRkciA9IG1taW87CisgICAgaXZoZC0+cmVzZXJ2ZWQgPSBJVkhEX0VGUl9J
QVNVUCB8IElWSERfRUZSX0dUU1VQOworCisgICAgLyogQnVpbGQgSVZIRCBkZXZpY2UgZW50
cmllcyAqLworICAgIGRldl9lbnRyeSA9IGl2cnMtPml2aGRfZGV2aWNlOworICAgIGZvciAo
IGludCBpID0gMDsgaSA8IHB0ZGV2X25yOyBpKysgKQorICAgIHsKKyAgICAgICAgZGV2X2Vu
dHJ5W2ldLnR5cGUgICA9IElWSERfU0VMRUNUXzRfQllURTsKKyAgICAgICAgZGV2X2VudHJ5
W2ldLmRldl9pZCA9IHB0ZGV2X2JkZltpXTsKKyAgICAgICAgZGV2X2VudHJ5W2ldLmZsYWdz
ICA9IDA7CisgICAgfQorCisgICAgaXZoZC0+bGVuZ3RoID0gc2l6ZW9mKCppdmhkKSArIHNp
emVvZigqZGV2X2VudHJ5KSAqIFBUX0RFVl9NQVhfTlI7CisgICAgc2V0X2NoZWNrc3VtKGl2
cnMsIG9mZnNldG9mKHN0cnVjdCBhY3BpX2hlYWRlciwgY2hlY2tzdW0pLCAKKyAgICAgICAg
ICAgICAgICAgaXZycy0+aGVhZGVyLmxlbmd0aCk7CisKKyAgICByZXR1cm4gaXZyczsKK30K
Kwogc3RhdGljIGludCBjb25zdHJ1Y3Rfc2Vjb25kYXJ5X3RhYmxlcyh1bnNpZ25lZCBsb25n
ICp0YWJsZV9wdHJzLAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBz
dHJ1Y3QgYWNwaV9pbmZvICppbmZvKQogewpAQCAtMjA2LDYgKzI4OSw3IEBAIHN0YXRpYyBp
bnQgY29uc3RydWN0X3NlY29uZGFyeV90YWJsZXModW5zaWduZWQgbG9uZyAqdGFibGVfcHRy
cywKICAgICBzdHJ1Y3QgYWNwaV8yMF9ocGV0ICpocGV0OwogICAgIHN0cnVjdCBhY3BpXzIw
X3dhZXQgKndhZXQ7CiAgICAgc3RydWN0IGFjcGlfMjBfdGNwYSAqdGNwYTsKKyAgICBzdHJ1
Y3QgYWNwaV80MF9pdnJzICppdnJzOwogICAgIHVuc2lnbmVkIGNoYXIgKnNzZHQ7CiAgICAg
c3RhdGljIGNvbnN0IHVpbnQxNl90IHRpc19zaWduYXR1cmVbXSA9IHsweDAwMDEsIDB4MDAw
MSwgMHgwMDAxfTsKICAgICB1aW50MTZfdCAqdGlzX2hkcjsKQEAgLTI5Myw2ICszNzcsMTMg
QEAgc3RhdGljIGludCBjb25zdHJ1Y3Rfc2Vjb25kYXJ5X3RhYmxlcyh1bnNpZ25lZCBsb25n
ICp0YWJsZV9wdHJzLAogICAgICAgICB9CiAgICAgfQogCisgICAgaWYgKCAhc3RybmNtcCh4
ZW5zdG9yZV9yZWFkKCJndWVzdF9pb21tdSIsICIxIiksICIxIiwgMSkgKQorICAgIHsKKyAg
ICAgICAgaXZycyA9IGNvbnN0cnVjdF9pdnJzKCk7CisgICAgICAgIGlmICggaXZycyAhPSBO
VUxMICkKKyAgICAgICAgICAgIHRhYmxlX3B0cnNbbnJfdGFibGVzKytdID0gKHVuc2lnbmVk
IGxvbmcpaXZyczsKKyAgICB9CisKICAgICB0YWJsZV9wdHJzW25yX3RhYmxlc10gPSAwOwog
ICAgIHJldHVybiBucl90YWJsZXM7CiB9CmRpZmYgLS1naXQgYS90b29scy9maXJtd2FyZS9o
dm1sb2FkZXIvcGNpLmMgYi90b29scy9maXJtd2FyZS9odm1sb2FkZXIvcGNpLmMKaW5kZXgg
ZmQ1NmU1MC4uY2Q4ZTgyMSAxMDA2NDQKLS0tIGEvdG9vbHMvZmlybXdhcmUvaHZtbG9hZGVy
L3BjaS5jCisrKyBiL3Rvb2xzL2Zpcm13YXJlL2h2bWxvYWRlci9wY2kuYwpAQCAtMzQsMTEg
KzM0LDE3IEBAIHVuc2lnbmVkIGxvbmcgcGNpX21lbV9lbmQgPSBQQ0lfTUVNX0VORDsKIGVu
dW0gdmlydHVhbF92Z2EgdmlydHVhbF92Z2EgPSBWR0Ffbm9uZTsKIHVuc2lnbmVkIGxvbmcg
aWdkX29wcmVnaW9uX3BnYmFzZSA9IDA7CiAKKy8qIHN1cHBvcnQgdXAgdG8gMzIgcGFzc3Ro
cm91Z2ggZGV2aWNlcyAqLworI2RlZmluZSBQVF9ERVZfTUFYX05SICAgICAgICAgICAzMgor
dWludDMyX3QgcHRkZXZfYmRmW1BUX0RFVl9NQVhfTlJdOwordWludDMyX3QgcHRkZXZfbnI7
Cit1aW50MzJfdCBpb21tdV9iZGYgPSAwOworCiB2b2lkIHBjaV9zZXR1cCh2b2lkKQogewog
ICAgIHVpbnQzMl90IGJhc2UsIGRldmZuLCBiYXJfcmVnLCBiYXJfZGF0YSwgYmFyX3N6LCBj
bWQsIG1taW9fdG90YWwgPSAwOwogICAgIHVpbnQzMl90IHZnYV9kZXZmbiA9IDI1NjsKLSAg
ICB1aW50MTZfdCBjbGFzcywgdmVuZG9yX2lkLCBkZXZpY2VfaWQ7CisgICAgdWludDE2X3Qg
Y2xhc3MsIHZlbmRvcl9pZCwgZGV2aWNlX2lkLCBzdWJfdmVuZG9yX2lkOwogICAgIHVuc2ln
bmVkIGludCBiYXIsIHBpbiwgbGluaywgaXNhX2lycTsKIAogICAgIC8qIFJlc291cmNlcyBh
c3NpZ25hYmxlIHRvIFBDSSBkZXZpY2VzIHZpYSBCQVJzLiAqLwpAQCAtNzIsMTIgKzc4LDM0
IEBAIHZvaWQgcGNpX3NldHVwKHZvaWQpCiAgICAgICAgIGNsYXNzICAgICA9IHBjaV9yZWFk
dyhkZXZmbiwgUENJX0NMQVNTX0RFVklDRSk7CiAgICAgICAgIHZlbmRvcl9pZCA9IHBjaV9y
ZWFkdyhkZXZmbiwgUENJX1ZFTkRPUl9JRCk7CiAgICAgICAgIGRldmljZV9pZCA9IHBjaV9y
ZWFkdyhkZXZmbiwgUENJX0RFVklDRV9JRCk7CisgICAgICAgIHN1Yl92ZW5kb3JfaWQgPSBw
Y2lfcmVhZHcoZGV2Zm4sIFBDSV9TVUJTWVNURU1fVkVORE9SX0lEKTsKKwogICAgICAgICBp
ZiAoICh2ZW5kb3JfaWQgPT0gMHhmZmZmKSAmJiAoZGV2aWNlX2lkID09IDB4ZmZmZikgKQog
ICAgICAgICAgICAgY29udGludWU7CiAKICAgICAgICAgQVNTRVJUKChkZXZmbiAhPSBQQ0lf
SVNBX0RFVkZOKSB8fAogICAgICAgICAgICAgICAgKCh2ZW5kb3JfaWQgPT0gMHg4MDg2KSAm
JiAoZGV2aWNlX2lkID09IDB4NzAwMCkpKTsKIAorICAgICAgICAvKiBGb3VuZCBhbWQgaW9t
bXUgZGV2aWNlLiAqLworICAgICAgICBpZiAoIGNsYXNzID09IDB4MDgwNiAmJiB2ZW5kb3Jf
aWQgPT0gMHgxMDIyICkKKyAgICAgICAgeworICAgICAgICAgICAgaW9tbXVfYmRmID0gZGV2
Zm47CisgICAgICAgICAgICBjb250aW51ZTsKKyAgICAgICAgfQorICAgICAgICAvKiBJVlJT
OiBEZXRlY3RpbmcgcGFzc3Rocm91Z2ggZGV2aWNlcy4KKyAgICAgICAgICogc3ViX3ZlbmRv
cl9pZCAhPSBjaXRyaXggJiYgc3ViX3ZlbmRvcl9pZCAhPSBxZW11ICovCisgICAgICAgIGlm
ICggc3ViX3ZlbmRvcl9pZCAhPSAweDU4NTMgJiYgc3ViX3ZlbmRvcl9pZCAhPSAweDFhZjQg
KQorICAgICAgICB7CisgICAgICAgICAgICAvKiBmb3VuZCBhIHBhc3N0aHJ1IGRldmljZSAq
LworICAgICAgICAgICAgaWYgKCBwdGRldl9uciA8IFBUX0RFVl9NQVhfTlIgKQorICAgICAg
ICAgICAgeworICAgICAgICAgICAgICAgIHB0ZGV2X2JkZltwdGRldl9ucl0gPSBkZXZmbjsK
KyAgICAgICAgICAgICAgICBwdGRldl9ucisrOworICAgICAgICAgICAgfQorICAgICAgICAg
ICAgZWxzZQorICAgICAgICAgICAgICAgIHByaW50ZigiTnVtYmVyIG9mIHBhc3N0aHJ1IGRl
dmljZXMgPiBQVF9ERVZfTUFYX05SIFxuIik7CisgICAgICAgIH0KKwogICAgICAgICBzd2l0
Y2ggKCBjbGFzcyApCiAgICAgICAgIHsKICAgICAgICAgY2FzZSAweDAzMDA6Ci0tIAoxLjcu
NAoKCg==
--------------000909030808070602050501
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--------------000909030808070602050501--


From xen-devel-bounces@lists.xen.org Wed Sep 26 14:45:21 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Sep 2012 14: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 1TGsrR-0001LD-UH; Wed, 26 Sep 2012 14:45:13 +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 1TGsrQ-0001KD-BR
	for xen-devel@lists.xensource.com; Wed, 26 Sep 2012 14:45:12 +0000
Received: from [85.158.138.51:55610] by server-5.bemta-3.messagelabs.com id
	F5/69-00589-7F413605; Wed, 26 Sep 2012 14:45:11 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1348670709!30277220!1
X-Originating-IP: [216.32.180.31]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14119 invoked from network); 26 Sep 2012 14:45:10 -0000
Received: from va3ehsobe005.messaging.microsoft.com (HELO
	va3outboundpool.messaging.microsoft.com) (216.32.180.31)
	by server-15.tower-174.messagelabs.com with AES128-SHA encrypted SMTP;
	26 Sep 2012 14:45:10 -0000
Received: from mail205-va3-R.bigfish.com (10.7.14.237) by
	VA3EHSOBE010.bigfish.com (10.7.40.12) with Microsoft SMTP Server id
	14.1.225.23; Wed, 26 Sep 2012 14:45:08 +0000
Received: from mail205-va3 (localhost [127.0.0.1])	by
	mail205-va3-R.bigfish.com (Postfix) with ESMTP id 82056360209;
	Wed, 26 Sep 2012 14:45:08 +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(zzc857hzz1202h1d1ah1d2ahzzz2dh668h839hd25he5bhf0ah107ah1288h12a5h12bdh137ah34h1155h)
Received: from mail205-va3 (localhost.localdomain [127.0.0.1]) by mail205-va3
	(MessageSwitch) id 1348670706844547_30968;
	Wed, 26 Sep 2012 14:45:06 +0000 (UTC)
Received: from VA3EHSMHS029.bigfish.com (unknown [10.7.14.240])	by
	mail205-va3.bigfish.com (Postfix) with ESMTP id C1543DC00BC;
	Wed, 26 Sep 2012 14:45:06 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	VA3EHSMHS029.bigfish.com (10.7.99.39) with Microsoft SMTP Server id
	14.1.225.23; Wed, 26 Sep 2012 14:45:06 +0000
X-WSS-ID: 0MAYOZ3-01-5UM-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 2CC5A1028008;	Wed, 26 Sep 2012 09:45:02 -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, 26 Sep 2012 09:45:14 -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, 26 Sep 2012 09:45:02 -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, 26 Sep 2012
	10:45:01 -0400
Received: from [165.204.15.57] (gran.osrc.amd.com [165.204.15.57])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id C84D649C14F; Wed, 26 Sep 2012
	15:44:59 +0100 (BST)
Message-ID: <5063156F.9050208@amd.com>
Date: Wed, 26 Sep 2012 16:47: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: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Content-Type: multipart/mixed; boundary="------------050801090304000903000502"
X-OriginatorOrg: amd.com
Cc: Keir Fraser <keir@xen.org>, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	Jan Beulich <JBeulich@suse.com>, Ian Campbell <Ian.Campbell@citrix.com>
Subject: [Xen-devel] [PATCH 4 of 6 V6] libxc: add wrappers for new hypercalls
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--------------050801090304000903000502
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 7bit




--------------050801090304000903000502
Content-Type: text/plain; charset="UTF-8";
	name="0004-libxc-add-wrappers-for-new-hypercalls.patch"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="0004-libxc-add-wrappers-for-new-hypercalls.patch"
Content-Description: 0004-libxc-add-wrappers-for-new-hypercalls.patch

RnJvbSAwZTUyNTkxNjFhNjA1NWRjYmViYjdiOWU5NzhiNWMzODRjN2EzZWZlIE1vbiBTZXAg
MTcgMDA6MDA6MDAgMjAwMQpGcm9tOiBXZWkgV2FuZyA8d2VpLndhbmcyQGFtZC5jb20+CkRh
dGU6IFdlZCwgMjYgU2VwIDIwMTIgMTE6NDc6MDMgKzAyMDAKU3ViamVjdDogW1BBVENIIDQv
Nl0gbGlieGM6IGFkZCB3cmFwcGVycyBmb3IgbmV3IGh5cGVyY2FsbHMKClBsZWFzZSBzZWUg
cGF0Y2ggMSBmb3IgaHlwZXJjYWxsIGRlc2NyaXB0aW9uLgoKU2lnbmVkLW9mZi1ieTogV2Vp
IFdhbmcgPHdlaS53YW5nMkBhbWQuY29tPgotLS0KIHRvb2xzL2xpYnhjL3hjX2RvbWFpbi5j
IHwgICA1MyArKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr
KwogdG9vbHMvbGlieGMveGVuY3RybC5oICAgfCAgIDE1ICsrKysrKysrKysrKysKIDIgZmls
ZXMgY2hhbmdlZCwgNjggaW5zZXJ0aW9ucygrKSwgMCBkZWxldGlvbnMoLSkKCmRpZmYgLS1n
aXQgYS90b29scy9saWJ4Yy94Y19kb21haW4uYyBiL3Rvb2xzL2xpYnhjL3hjX2RvbWFpbi5j
CmluZGV4IGQ5OGU2OGIuLjdhMGQ0MzcgMTAwNjQ0Ci0tLSBhL3Rvb2xzL2xpYnhjL3hjX2Rv
bWFpbi5jCisrKyBiL3Rvb2xzL2xpYnhjL3hjX2RvbWFpbi5jCkBAIC0xMzUyLDYgKzEzNTIs
NTkgQEAgaW50IHhjX2RvbWFpbl9iaW5kX3B0X2lzYV9pcnEoCiAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgUFRfSVJRX1RZUEVfSVNBLCAwLCAwLCAwLCBtYWNoaW5lX2ly
cSkpOwogfQogCitpbnQgeGNfZG9tYWluX3VwZGF0ZV9pb21tdV9tc2koCisgICAgeGNfaW50
ZXJmYWNlICp4Y2gsCisgICAgdWludDMyX3QgZG9taWQsCisgICAgdWludDhfdCB2ZWN0b3Is
CisgICAgdWludDhfdCBkZXN0LAorICAgIHVpbnQ4X3QgZGVzdF9tb2RlLAorICAgIHVpbnQ4
X3QgZGVsaXZlcnlfbW9kZSwKKyAgICB1aW50OF90IHRyaWdfbW9kZSkKK3sKKyAgICBpbnQg
cmM7CisgICAgREVDTEFSRV9ET01DVEw7CisgICAgeGVuX2RvbWN0bF9ndWVzdF9pb21tdV9v
cF90ICogaW9tbXVfb3A7CisKKyAgICBkb21jdGwuY21kID0gWEVOX0RPTUNUTF9ndWVzdF9p
b21tdV9vcDsKKyAgICBkb21jdGwuZG9tYWluID0gKGRvbWlkX3QpZG9taWQ7CisKKyAgICBp
b21tdV9vcCA9ICYoZG9tY3RsLnUuZ3Vlc3RfaW9tbXVfb3ApOworICAgIGlvbW11X29wLT5v
cCA9IFhFTl9ET01DVExfR1VFU1RfSU9NTVVfT1BfU0VUX01TSTsKKyAgICBpb21tdV9vcC0+
dS5tc2kudmVjdG9yID0gdmVjdG9yOworICAgIGlvbW11X29wLT51Lm1zaS5kZXN0ID0gZGVz
dDsKKyAgICBpb21tdV9vcC0+dS5tc2kuZGVzdF9tb2RlID0gZGVzdF9tb2RlOworICAgIGlv
bW11X29wLT51Lm1zaS5kZWxpdmVyeV9tb2RlID0gZGVsaXZlcnlfbW9kZTsKKyAgICBpb21t
dV9vcC0+dS5tc2kudHJpZ19tb2RlID0gdHJpZ19tb2RlOworCisgICAgcmMgPSBkb19kb21j
dGwoeGNoLCAmZG9tY3RsKTsKKyAgICByZXR1cm4gcmM7Cit9CisKK2ludCB4Y19kb21haW5f
YmluZF9wdF9iZGYoeGNfaW50ZXJmYWNlICp4Y2gsCisgICAgdWludDMyX3QgZG9taWQsCisg
ICAgdWludDE2X3QgZ3NlZywKKyAgICB1aW50MTZfdCBnYmRmLAorICAgIHVpbnQxNl90IG1z
ZWcsCisgICAgdWludDE2X3QgbWJkZikKK3sKKyAgICBpbnQgcmM7CisgICAgREVDTEFSRV9E
T01DVEw7CisgICAgeGVuX2RvbWN0bF9ndWVzdF9pb21tdV9vcF90ICogZ3Vlc3Rfb3A7CisK
KyAgICBkb21jdGwuY21kID0gWEVOX0RPTUNUTF9ndWVzdF9pb21tdV9vcDsKKyAgICBkb21j
dGwuZG9tYWluID0gKGRvbWlkX3QpZG9taWQ7CisKKyAgICBndWVzdF9vcCA9ICYoZG9tY3Rs
LnUuZ3Vlc3RfaW9tbXVfb3ApOworICAgIGd1ZXN0X29wLT5vcCA9IFhFTl9ET01DVExfR1VF
U1RfSU9NTVVfT1BfQklORF9CREY7CisgICAgZ3Vlc3Rfb3AtPnUuYmRmX2JpbmQuZ19zZWcg
PSBnc2VnOworICAgIGd1ZXN0X29wLT51LmJkZl9iaW5kLmdfYmRmID0gZ2JkZjsKKyAgICBn
dWVzdF9vcC0+dS5iZGZfYmluZC5tX3NlZyA9IG1zZWc7CisgICAgZ3Vlc3Rfb3AtPnUuYmRm
X2JpbmQubV9iZGYgPSBtYmRmOworCisgICAgcmMgPSBkb19kb21jdGwoeGNoLCAmZG9tY3Rs
KTsKKyAgICByZXR1cm4gcmM7Cit9CisKIGludCB4Y19kb21haW5fbWVtb3J5X21hcHBpbmco
CiAgICAgeGNfaW50ZXJmYWNlICp4Y2gsCiAgICAgdWludDMyX3QgZG9taWQsCmRpZmYgLS1n
aXQgYS90b29scy9saWJ4Yy94ZW5jdHJsLmggYi90b29scy9saWJ4Yy94ZW5jdHJsLmgKaW5k
ZXggN2ViNTc0My4uMWU1MTBhMCAxMDA2NDQKLS0tIGEvdG9vbHMvbGlieGMveGVuY3RybC5o
CisrKyBiL3Rvb2xzL2xpYnhjL3hlbmN0cmwuaApAQCAtMTczMCw2ICsxNzMwLDIxIEBAIGlu
dCB4Y19kb21haW5fYmluZF9wdF9pc2FfaXJxKHhjX2ludGVyZmFjZSAqeGNoLAogICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgdWludDMyX3QgZG9taWQsCiAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICB1aW50OF90IG1hY2hpbmVfaXJxKTsKIAoraW50IHhjX2RvbWFp
bl9iaW5kX3B0X2JkZih4Y19pbnRlcmZhY2UgKnhjaCwKKyAgICAgICAgICAgICAgICAgICAg
ICAgICAgdWludDMyX3QgZG9taWQsCisgICAgICAgICAgICAgICAgICAgICAgICAgIHVpbnQx
Nl90IGdzZWcsCisgICAgICAgICAgICAgICAgICAgICAgICAgIHVpbnQxNl90IGdiZGYsCisg
ICAgICAgICAgICAgICAgICAgICAgICAgIHVpbnQxNl90IG1zZWcsIAorICAgICAgICAgICAg
ICAgICAgICAgICAgICB1aW50MTZfdCBtYmRmKTsKKworaW50IHhjX2RvbWFpbl91cGRhdGVf
aW9tbXVfbXNpKHhjX2ludGVyZmFjZSAqeGNoLAorICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgIHVpbnQzMl90IGRvbWlkLAorICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
IHVpbnQ4X3QgdmVjdG9yLAorICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHVpbnQ4
X3QgZGVzdCwKKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB1aW50OF90IGRlc3Rf
bW9kZSwKKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB1aW50OF90IGRlbGl2ZXJ5
X21vZGUsCisgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgdWludDhfdCB0cmlnX21v
ZGUpOworCiBpbnQgeGNfZG9tYWluX3NldF9tYWNoaW5lX2FkZHJlc3Nfc2l6ZSh4Y19pbnRl
cmZhY2UgKnhjaCwKIAkJCQkgICAgICAgdWludDMyX3QgZG9taWQsCiAJCQkJICAgICAgIHVu
c2lnbmVkIGludCB3aWR0aCk7Ci0tIAoxLjcuNAoKCg==
--------------050801090304000903000502
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--------------050801090304000903000502--


From xen-devel-bounces@lists.xen.org Wed Sep 26 14:45:21 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Sep 2012 14: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 1TGsrR-0001LD-UH; Wed, 26 Sep 2012 14:45:13 +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 1TGsrQ-0001KD-BR
	for xen-devel@lists.xensource.com; Wed, 26 Sep 2012 14:45:12 +0000
Received: from [85.158.138.51:55610] by server-5.bemta-3.messagelabs.com id
	F5/69-00589-7F413605; Wed, 26 Sep 2012 14:45:11 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1348670709!30277220!1
X-Originating-IP: [216.32.180.31]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14119 invoked from network); 26 Sep 2012 14:45:10 -0000
Received: from va3ehsobe005.messaging.microsoft.com (HELO
	va3outboundpool.messaging.microsoft.com) (216.32.180.31)
	by server-15.tower-174.messagelabs.com with AES128-SHA encrypted SMTP;
	26 Sep 2012 14:45:10 -0000
Received: from mail205-va3-R.bigfish.com (10.7.14.237) by
	VA3EHSOBE010.bigfish.com (10.7.40.12) with Microsoft SMTP Server id
	14.1.225.23; Wed, 26 Sep 2012 14:45:08 +0000
Received: from mail205-va3 (localhost [127.0.0.1])	by
	mail205-va3-R.bigfish.com (Postfix) with ESMTP id 82056360209;
	Wed, 26 Sep 2012 14:45:08 +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(zzc857hzz1202h1d1ah1d2ahzzz2dh668h839hd25he5bhf0ah107ah1288h12a5h12bdh137ah34h1155h)
Received: from mail205-va3 (localhost.localdomain [127.0.0.1]) by mail205-va3
	(MessageSwitch) id 1348670706844547_30968;
	Wed, 26 Sep 2012 14:45:06 +0000 (UTC)
Received: from VA3EHSMHS029.bigfish.com (unknown [10.7.14.240])	by
	mail205-va3.bigfish.com (Postfix) with ESMTP id C1543DC00BC;
	Wed, 26 Sep 2012 14:45:06 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	VA3EHSMHS029.bigfish.com (10.7.99.39) with Microsoft SMTP Server id
	14.1.225.23; Wed, 26 Sep 2012 14:45:06 +0000
X-WSS-ID: 0MAYOZ3-01-5UM-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 2CC5A1028008;	Wed, 26 Sep 2012 09:45:02 -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, 26 Sep 2012 09:45:14 -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, 26 Sep 2012 09:45:02 -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, 26 Sep 2012
	10:45:01 -0400
Received: from [165.204.15.57] (gran.osrc.amd.com [165.204.15.57])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id C84D649C14F; Wed, 26 Sep 2012
	15:44:59 +0100 (BST)
Message-ID: <5063156F.9050208@amd.com>
Date: Wed, 26 Sep 2012 16:47: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: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Content-Type: multipart/mixed; boundary="------------050801090304000903000502"
X-OriginatorOrg: amd.com
Cc: Keir Fraser <keir@xen.org>, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	Jan Beulich <JBeulich@suse.com>, Ian Campbell <Ian.Campbell@citrix.com>
Subject: [Xen-devel] [PATCH 4 of 6 V6] libxc: add wrappers for new hypercalls
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--------------050801090304000903000502
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 7bit




--------------050801090304000903000502
Content-Type: text/plain; charset="UTF-8";
	name="0004-libxc-add-wrappers-for-new-hypercalls.patch"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="0004-libxc-add-wrappers-for-new-hypercalls.patch"
Content-Description: 0004-libxc-add-wrappers-for-new-hypercalls.patch

RnJvbSAwZTUyNTkxNjFhNjA1NWRjYmViYjdiOWU5NzhiNWMzODRjN2EzZWZlIE1vbiBTZXAg
MTcgMDA6MDA6MDAgMjAwMQpGcm9tOiBXZWkgV2FuZyA8d2VpLndhbmcyQGFtZC5jb20+CkRh
dGU6IFdlZCwgMjYgU2VwIDIwMTIgMTE6NDc6MDMgKzAyMDAKU3ViamVjdDogW1BBVENIIDQv
Nl0gbGlieGM6IGFkZCB3cmFwcGVycyBmb3IgbmV3IGh5cGVyY2FsbHMKClBsZWFzZSBzZWUg
cGF0Y2ggMSBmb3IgaHlwZXJjYWxsIGRlc2NyaXB0aW9uLgoKU2lnbmVkLW9mZi1ieTogV2Vp
IFdhbmcgPHdlaS53YW5nMkBhbWQuY29tPgotLS0KIHRvb2xzL2xpYnhjL3hjX2RvbWFpbi5j
IHwgICA1MyArKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr
KwogdG9vbHMvbGlieGMveGVuY3RybC5oICAgfCAgIDE1ICsrKysrKysrKysrKysKIDIgZmls
ZXMgY2hhbmdlZCwgNjggaW5zZXJ0aW9ucygrKSwgMCBkZWxldGlvbnMoLSkKCmRpZmYgLS1n
aXQgYS90b29scy9saWJ4Yy94Y19kb21haW4uYyBiL3Rvb2xzL2xpYnhjL3hjX2RvbWFpbi5j
CmluZGV4IGQ5OGU2OGIuLjdhMGQ0MzcgMTAwNjQ0Ci0tLSBhL3Rvb2xzL2xpYnhjL3hjX2Rv
bWFpbi5jCisrKyBiL3Rvb2xzL2xpYnhjL3hjX2RvbWFpbi5jCkBAIC0xMzUyLDYgKzEzNTIs
NTkgQEAgaW50IHhjX2RvbWFpbl9iaW5kX3B0X2lzYV9pcnEoCiAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgUFRfSVJRX1RZUEVfSVNBLCAwLCAwLCAwLCBtYWNoaW5lX2ly
cSkpOwogfQogCitpbnQgeGNfZG9tYWluX3VwZGF0ZV9pb21tdV9tc2koCisgICAgeGNfaW50
ZXJmYWNlICp4Y2gsCisgICAgdWludDMyX3QgZG9taWQsCisgICAgdWludDhfdCB2ZWN0b3Is
CisgICAgdWludDhfdCBkZXN0LAorICAgIHVpbnQ4X3QgZGVzdF9tb2RlLAorICAgIHVpbnQ4
X3QgZGVsaXZlcnlfbW9kZSwKKyAgICB1aW50OF90IHRyaWdfbW9kZSkKK3sKKyAgICBpbnQg
cmM7CisgICAgREVDTEFSRV9ET01DVEw7CisgICAgeGVuX2RvbWN0bF9ndWVzdF9pb21tdV9v
cF90ICogaW9tbXVfb3A7CisKKyAgICBkb21jdGwuY21kID0gWEVOX0RPTUNUTF9ndWVzdF9p
b21tdV9vcDsKKyAgICBkb21jdGwuZG9tYWluID0gKGRvbWlkX3QpZG9taWQ7CisKKyAgICBp
b21tdV9vcCA9ICYoZG9tY3RsLnUuZ3Vlc3RfaW9tbXVfb3ApOworICAgIGlvbW11X29wLT5v
cCA9IFhFTl9ET01DVExfR1VFU1RfSU9NTVVfT1BfU0VUX01TSTsKKyAgICBpb21tdV9vcC0+
dS5tc2kudmVjdG9yID0gdmVjdG9yOworICAgIGlvbW11X29wLT51Lm1zaS5kZXN0ID0gZGVz
dDsKKyAgICBpb21tdV9vcC0+dS5tc2kuZGVzdF9tb2RlID0gZGVzdF9tb2RlOworICAgIGlv
bW11X29wLT51Lm1zaS5kZWxpdmVyeV9tb2RlID0gZGVsaXZlcnlfbW9kZTsKKyAgICBpb21t
dV9vcC0+dS5tc2kudHJpZ19tb2RlID0gdHJpZ19tb2RlOworCisgICAgcmMgPSBkb19kb21j
dGwoeGNoLCAmZG9tY3RsKTsKKyAgICByZXR1cm4gcmM7Cit9CisKK2ludCB4Y19kb21haW5f
YmluZF9wdF9iZGYoeGNfaW50ZXJmYWNlICp4Y2gsCisgICAgdWludDMyX3QgZG9taWQsCisg
ICAgdWludDE2X3QgZ3NlZywKKyAgICB1aW50MTZfdCBnYmRmLAorICAgIHVpbnQxNl90IG1z
ZWcsCisgICAgdWludDE2X3QgbWJkZikKK3sKKyAgICBpbnQgcmM7CisgICAgREVDTEFSRV9E
T01DVEw7CisgICAgeGVuX2RvbWN0bF9ndWVzdF9pb21tdV9vcF90ICogZ3Vlc3Rfb3A7CisK
KyAgICBkb21jdGwuY21kID0gWEVOX0RPTUNUTF9ndWVzdF9pb21tdV9vcDsKKyAgICBkb21j
dGwuZG9tYWluID0gKGRvbWlkX3QpZG9taWQ7CisKKyAgICBndWVzdF9vcCA9ICYoZG9tY3Rs
LnUuZ3Vlc3RfaW9tbXVfb3ApOworICAgIGd1ZXN0X29wLT5vcCA9IFhFTl9ET01DVExfR1VF
U1RfSU9NTVVfT1BfQklORF9CREY7CisgICAgZ3Vlc3Rfb3AtPnUuYmRmX2JpbmQuZ19zZWcg
PSBnc2VnOworICAgIGd1ZXN0X29wLT51LmJkZl9iaW5kLmdfYmRmID0gZ2JkZjsKKyAgICBn
dWVzdF9vcC0+dS5iZGZfYmluZC5tX3NlZyA9IG1zZWc7CisgICAgZ3Vlc3Rfb3AtPnUuYmRm
X2JpbmQubV9iZGYgPSBtYmRmOworCisgICAgcmMgPSBkb19kb21jdGwoeGNoLCAmZG9tY3Rs
KTsKKyAgICByZXR1cm4gcmM7Cit9CisKIGludCB4Y19kb21haW5fbWVtb3J5X21hcHBpbmco
CiAgICAgeGNfaW50ZXJmYWNlICp4Y2gsCiAgICAgdWludDMyX3QgZG9taWQsCmRpZmYgLS1n
aXQgYS90b29scy9saWJ4Yy94ZW5jdHJsLmggYi90b29scy9saWJ4Yy94ZW5jdHJsLmgKaW5k
ZXggN2ViNTc0My4uMWU1MTBhMCAxMDA2NDQKLS0tIGEvdG9vbHMvbGlieGMveGVuY3RybC5o
CisrKyBiL3Rvb2xzL2xpYnhjL3hlbmN0cmwuaApAQCAtMTczMCw2ICsxNzMwLDIxIEBAIGlu
dCB4Y19kb21haW5fYmluZF9wdF9pc2FfaXJxKHhjX2ludGVyZmFjZSAqeGNoLAogICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgdWludDMyX3QgZG9taWQsCiAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICB1aW50OF90IG1hY2hpbmVfaXJxKTsKIAoraW50IHhjX2RvbWFp
bl9iaW5kX3B0X2JkZih4Y19pbnRlcmZhY2UgKnhjaCwKKyAgICAgICAgICAgICAgICAgICAg
ICAgICAgdWludDMyX3QgZG9taWQsCisgICAgICAgICAgICAgICAgICAgICAgICAgIHVpbnQx
Nl90IGdzZWcsCisgICAgICAgICAgICAgICAgICAgICAgICAgIHVpbnQxNl90IGdiZGYsCisg
ICAgICAgICAgICAgICAgICAgICAgICAgIHVpbnQxNl90IG1zZWcsIAorICAgICAgICAgICAg
ICAgICAgICAgICAgICB1aW50MTZfdCBtYmRmKTsKKworaW50IHhjX2RvbWFpbl91cGRhdGVf
aW9tbXVfbXNpKHhjX2ludGVyZmFjZSAqeGNoLAorICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgIHVpbnQzMl90IGRvbWlkLAorICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
IHVpbnQ4X3QgdmVjdG9yLAorICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHVpbnQ4
X3QgZGVzdCwKKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB1aW50OF90IGRlc3Rf
bW9kZSwKKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB1aW50OF90IGRlbGl2ZXJ5
X21vZGUsCisgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgdWludDhfdCB0cmlnX21v
ZGUpOworCiBpbnQgeGNfZG9tYWluX3NldF9tYWNoaW5lX2FkZHJlc3Nfc2l6ZSh4Y19pbnRl
cmZhY2UgKnhjaCwKIAkJCQkgICAgICAgdWludDMyX3QgZG9taWQsCiAJCQkJICAgICAgIHVu
c2lnbmVkIGludCB3aWR0aCk7Ci0tIAoxLjcuNAoKCg==
--------------050801090304000903000502
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--------------050801090304000903000502--


From xen-devel-bounces@lists.xen.org Wed Sep 26 14:45:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Sep 2012 14: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 1TGsrb-0001Qr-GU; Wed, 26 Sep 2012 14:45:23 +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 1TGsra-0001Pt-4R
	for xen-devel@lists.xensource.com; Wed, 26 Sep 2012 14:45:22 +0000
Received: from [85.158.143.99:32225] by server-2.bemta-4.messagelabs.com id
	A9/21-06610-10513605; Wed, 26 Sep 2012 14:45:21 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1348670719!25440861!1
X-Originating-IP: [213.199.154.205]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15161 invoked from network); 26 Sep 2012 14:45:20 -0000
Received: from am1ehsobe002.messaging.microsoft.com (HELO
	am1outboundpool.messaging.microsoft.com) (213.199.154.205)
	by server-10.tower-216.messagelabs.com with AES128-SHA encrypted SMTP;
	26 Sep 2012 14:45:20 -0000
Received: from mail77-am1-R.bigfish.com (10.3.201.253) by
	AM1EHSOBE006.bigfish.com (10.3.204.26) with Microsoft SMTP Server id
	14.1.225.23; Wed, 26 Sep 2012 14:45:18 +0000
Received: from mail77-am1 (localhost [127.0.0.1])	by mail77-am1-R.bigfish.com
	(Postfix) with ESMTP id B45603600B7;
	Wed, 26 Sep 2012 14:45:18 +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(zzc857hzz1202h1d1ah1d2ahzzz2dh668h839he5bhf0ah107ah1288h12a5h12bdh137ah34h1155h)
Received: from mail77-am1 (localhost.localdomain [127.0.0.1]) by mail77-am1
	(MessageSwitch) id 1348670715871423_30952;
	Wed, 26 Sep 2012 14:45:15 +0000 (UTC)
Received: from AM1EHSMHS009.bigfish.com (unknown [10.3.201.235])	by
	mail77-am1.bigfish.com (Postfix) with ESMTP id C586A1C00A4;
	Wed, 26 Sep 2012 14:45:15 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	AM1EHSMHS009.bigfish.com (10.3.207.109) with Microsoft SMTP Server id
	14.1.225.23; Wed, 26 Sep 2012 14:45:13 +0000
X-WSS-ID: 0MAYOZ9-02-2ZH-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 24095C801B;	Wed, 26 Sep 2012 09:45:09 -0500 (CDT)
Received: from sausexhtp02.amd.com (163.181.3.152) by sausexedgep01.amd.com
	(163.181.36.54) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Wed, 26 Sep 2012 09:45:23 -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, 26 Sep 2012 09:45:10 -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, 26 Sep 2012
	10:45:09 -0400
Received: from [165.204.15.57] (gran.osrc.amd.com [165.204.15.57])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id 5E54E49C14F; Wed, 26 Sep 2012
	15:45:08 +0100 (BST)
Message-ID: <50631578.3080201@amd.com>
Date: Wed, 26 Sep 2012 16:47: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: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, Ian
	Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, 
	Keir Fraser <keir@xen.org>, Jan Beulich <JBeulich@suse.com>
Content-Type: multipart/mixed; boundary="------------030906040805020201070309"
X-OriginatorOrg: amd.com
Subject: [Xen-devel] [PATCH 5 of 6 V6] libxl: bind virtual bdf to physical
 bdf after device 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

--------------030906040805020201070309
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 7bit




--------------030906040805020201070309
Content-Type: text/plain; charset="UTF-8";
	name="0005-libxl-bind-virtual-bdf-to-physical-bdf-after-device-.patch"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="0005-libxl-bind-virtual-bdf-to-physical-bdf-after-device-.patch"
Content-Description: 0005-libxl-bind-virtual-bdf-to-physical-bdf-after-device-.patch

RnJvbSAzMDdkZWM4MGQwM2IxYTdlYzcwNDhlMzVjYTlkYTJmOWVjOTQyMDY2IE1vbiBTZXAg
MTcgMDA6MDA6MDAgMjAwMQpGcm9tOiBXZWkgV2FuZyA8d2VpLndhbmcyQGFtZC5jb20+CkRh
dGU6IFdlZCwgMjYgU2VwIDIwMTIgMTE6NDc6NTUgKzAyMDAKU3ViamVjdDogW1BBVENIIDUv
Nl0gbGlieGw6IGJpbmQgdmlydHVhbCBiZGYgdG8gcGh5c2ljYWwgYmRmIGFmdGVyIGRldmlj
ZSBhc3NpZ25tZW50CgpTaWduZWQtb2ZmLWJ5OiBXZWkgV2FuZyA8d2VpLndhbmcyQGFtZC5j
b20+Ci0tLQogdG9vbHMvbGlieGwvbGlieGxfcGNpLmMgfCAgIDEwICsrKysrKysrKy0KIDEg
ZmlsZXMgY2hhbmdlZCwgOSBpbnNlcnRpb25zKCspLCAxIGRlbGV0aW9ucygtKQoKZGlmZiAt
LWdpdCBhL3Rvb2xzL2xpYnhsL2xpYnhsX3BjaS5jIGIvdG9vbHMvbGlieGwvbGlieGxfcGNp
LmMKaW5kZXggZmY0NDdlNy4uZWNkNWUyYiAxMDA2NDQKLS0tIGEvdG9vbHMvbGlieGwvbGli
eGxfcGNpLmMKKysrIGIvdG9vbHMvbGlieGwvbGlieGxfcGNpLmMKQEAgLTg1OCw4ICs4NTgs
OSBAQCBzdGF0aWMgaW50IGRvX3BjaV9hZGQobGlieGxfX2djICpnYywgdWludDMyX3QgZG9t
aWQsIGxpYnhsX2RldmljZV9wY2kgKnBjaWRldiwgaQogewogICAgIGxpYnhsX2N0eCAqY3R4
ID0gbGlieGxfX2djX293bmVyKGdjKTsKICAgICBpbnQgcmMsIGh2bSA9IDA7CisgICAgbGli
eGxfZG9tYWluX3R5cGUgdHlwZSA9IGxpYnhsX19kb21haW5fdHlwZShnYywgZG9taWQpOwog
Ci0gICAgc3dpdGNoIChsaWJ4bF9fZG9tYWluX3R5cGUoZ2MsIGRvbWlkKSkgeworICAgIHN3
aXRjaCAodHlwZSkgewogICAgIGNhc2UgTElCWExfRE9NQUlOX1RZUEVfSFZNOgogICAgICAg
ICBodm0gPSAxOwogICAgICAgICBpZiAobGlieGxfX3dhaXRfZm9yX2RldmljZV9tb2RlbChn
YywgZG9taWQsICJydW5uaW5nIiwKQEAgLTk2MCw2ICs5NjEsMTMgQEAgb3V0OgogICAgICAg
ICAgICAgTElCWExfX0xPR19FUlJOT1ZBTChjdHgsIExJQlhMX19MT0dfRVJST1IsIHJjLCAi
eGNfYXNzaWduX2RldmljZSBmYWlsZWQiKTsKICAgICAgICAgICAgIHJldHVybiBFUlJPUl9G
QUlMOwogICAgICAgICB9CisgICAgICAgIGlmICh0eXBlID09IExJQlhMX0RPTUFJTl9UWVBF
X0hWTSkgeworICAgICAgICAgICAgcmMgPSB4Y19kb21haW5fYmluZF9wdF9iZGYoY3R4LT54
Y2gsIGRvbWlkLCAwLCBwY2lkZXYtPnZkZXZmbiwgcGNpZGV2LT5kb21haW4sIHBjaWRldl9l
bmNvZGVfYmRmKHBjaWRldikpOworICAgICAgICAgICAgaWYgKCByYyApIHsKKyAgICAgICAg
ICAgICAgICBMSUJYTF9fTE9HX0VSUk5PVkFMKGN0eCwgTElCWExfX0xPR19FUlJPUiwgcmMs
ICJ4Y19kb21haW5fYmluZF9wdF9iZGYgZmFpbGVkIik7CisgICAgICAgICAgICAgICAgcmV0
dXJuIEVSUk9SX0ZBSUw7CisgICAgICAgICAgICB9CisgICAgICAgIH0KICAgICB9CiAKICAg
ICBpZiAoIXN0YXJ0aW5nKQotLSAKMS43LjQKCgo=
--------------030906040805020201070309
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--------------030906040805020201070309--


From xen-devel-bounces@lists.xen.org Wed Sep 26 14:45:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Sep 2012 14: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 1TGsrb-0001Qr-GU; Wed, 26 Sep 2012 14:45:23 +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 1TGsra-0001Pt-4R
	for xen-devel@lists.xensource.com; Wed, 26 Sep 2012 14:45:22 +0000
Received: from [85.158.143.99:32225] by server-2.bemta-4.messagelabs.com id
	A9/21-06610-10513605; Wed, 26 Sep 2012 14:45:21 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1348670719!25440861!1
X-Originating-IP: [213.199.154.205]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15161 invoked from network); 26 Sep 2012 14:45:20 -0000
Received: from am1ehsobe002.messaging.microsoft.com (HELO
	am1outboundpool.messaging.microsoft.com) (213.199.154.205)
	by server-10.tower-216.messagelabs.com with AES128-SHA encrypted SMTP;
	26 Sep 2012 14:45:20 -0000
Received: from mail77-am1-R.bigfish.com (10.3.201.253) by
	AM1EHSOBE006.bigfish.com (10.3.204.26) with Microsoft SMTP Server id
	14.1.225.23; Wed, 26 Sep 2012 14:45:18 +0000
Received: from mail77-am1 (localhost [127.0.0.1])	by mail77-am1-R.bigfish.com
	(Postfix) with ESMTP id B45603600B7;
	Wed, 26 Sep 2012 14:45:18 +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(zzc857hzz1202h1d1ah1d2ahzzz2dh668h839he5bhf0ah107ah1288h12a5h12bdh137ah34h1155h)
Received: from mail77-am1 (localhost.localdomain [127.0.0.1]) by mail77-am1
	(MessageSwitch) id 1348670715871423_30952;
	Wed, 26 Sep 2012 14:45:15 +0000 (UTC)
Received: from AM1EHSMHS009.bigfish.com (unknown [10.3.201.235])	by
	mail77-am1.bigfish.com (Postfix) with ESMTP id C586A1C00A4;
	Wed, 26 Sep 2012 14:45:15 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	AM1EHSMHS009.bigfish.com (10.3.207.109) with Microsoft SMTP Server id
	14.1.225.23; Wed, 26 Sep 2012 14:45:13 +0000
X-WSS-ID: 0MAYOZ9-02-2ZH-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 24095C801B;	Wed, 26 Sep 2012 09:45:09 -0500 (CDT)
Received: from sausexhtp02.amd.com (163.181.3.152) by sausexedgep01.amd.com
	(163.181.36.54) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Wed, 26 Sep 2012 09:45:23 -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, 26 Sep 2012 09:45:10 -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, 26 Sep 2012
	10:45:09 -0400
Received: from [165.204.15.57] (gran.osrc.amd.com [165.204.15.57])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id 5E54E49C14F; Wed, 26 Sep 2012
	15:45:08 +0100 (BST)
Message-ID: <50631578.3080201@amd.com>
Date: Wed, 26 Sep 2012 16:47: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: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, Ian
	Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, 
	Keir Fraser <keir@xen.org>, Jan Beulich <JBeulich@suse.com>
Content-Type: multipart/mixed; boundary="------------030906040805020201070309"
X-OriginatorOrg: amd.com
Subject: [Xen-devel] [PATCH 5 of 6 V6] libxl: bind virtual bdf to physical
 bdf after device 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

--------------030906040805020201070309
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 7bit




--------------030906040805020201070309
Content-Type: text/plain; charset="UTF-8";
	name="0005-libxl-bind-virtual-bdf-to-physical-bdf-after-device-.patch"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="0005-libxl-bind-virtual-bdf-to-physical-bdf-after-device-.patch"
Content-Description: 0005-libxl-bind-virtual-bdf-to-physical-bdf-after-device-.patch

RnJvbSAzMDdkZWM4MGQwM2IxYTdlYzcwNDhlMzVjYTlkYTJmOWVjOTQyMDY2IE1vbiBTZXAg
MTcgMDA6MDA6MDAgMjAwMQpGcm9tOiBXZWkgV2FuZyA8d2VpLndhbmcyQGFtZC5jb20+CkRh
dGU6IFdlZCwgMjYgU2VwIDIwMTIgMTE6NDc6NTUgKzAyMDAKU3ViamVjdDogW1BBVENIIDUv
Nl0gbGlieGw6IGJpbmQgdmlydHVhbCBiZGYgdG8gcGh5c2ljYWwgYmRmIGFmdGVyIGRldmlj
ZSBhc3NpZ25tZW50CgpTaWduZWQtb2ZmLWJ5OiBXZWkgV2FuZyA8d2VpLndhbmcyQGFtZC5j
b20+Ci0tLQogdG9vbHMvbGlieGwvbGlieGxfcGNpLmMgfCAgIDEwICsrKysrKysrKy0KIDEg
ZmlsZXMgY2hhbmdlZCwgOSBpbnNlcnRpb25zKCspLCAxIGRlbGV0aW9ucygtKQoKZGlmZiAt
LWdpdCBhL3Rvb2xzL2xpYnhsL2xpYnhsX3BjaS5jIGIvdG9vbHMvbGlieGwvbGlieGxfcGNp
LmMKaW5kZXggZmY0NDdlNy4uZWNkNWUyYiAxMDA2NDQKLS0tIGEvdG9vbHMvbGlieGwvbGli
eGxfcGNpLmMKKysrIGIvdG9vbHMvbGlieGwvbGlieGxfcGNpLmMKQEAgLTg1OCw4ICs4NTgs
OSBAQCBzdGF0aWMgaW50IGRvX3BjaV9hZGQobGlieGxfX2djICpnYywgdWludDMyX3QgZG9t
aWQsIGxpYnhsX2RldmljZV9wY2kgKnBjaWRldiwgaQogewogICAgIGxpYnhsX2N0eCAqY3R4
ID0gbGlieGxfX2djX293bmVyKGdjKTsKICAgICBpbnQgcmMsIGh2bSA9IDA7CisgICAgbGli
eGxfZG9tYWluX3R5cGUgdHlwZSA9IGxpYnhsX19kb21haW5fdHlwZShnYywgZG9taWQpOwog
Ci0gICAgc3dpdGNoIChsaWJ4bF9fZG9tYWluX3R5cGUoZ2MsIGRvbWlkKSkgeworICAgIHN3
aXRjaCAodHlwZSkgewogICAgIGNhc2UgTElCWExfRE9NQUlOX1RZUEVfSFZNOgogICAgICAg
ICBodm0gPSAxOwogICAgICAgICBpZiAobGlieGxfX3dhaXRfZm9yX2RldmljZV9tb2RlbChn
YywgZG9taWQsICJydW5uaW5nIiwKQEAgLTk2MCw2ICs5NjEsMTMgQEAgb3V0OgogICAgICAg
ICAgICAgTElCWExfX0xPR19FUlJOT1ZBTChjdHgsIExJQlhMX19MT0dfRVJST1IsIHJjLCAi
eGNfYXNzaWduX2RldmljZSBmYWlsZWQiKTsKICAgICAgICAgICAgIHJldHVybiBFUlJPUl9G
QUlMOwogICAgICAgICB9CisgICAgICAgIGlmICh0eXBlID09IExJQlhMX0RPTUFJTl9UWVBF
X0hWTSkgeworICAgICAgICAgICAgcmMgPSB4Y19kb21haW5fYmluZF9wdF9iZGYoY3R4LT54
Y2gsIGRvbWlkLCAwLCBwY2lkZXYtPnZkZXZmbiwgcGNpZGV2LT5kb21haW4sIHBjaWRldl9l
bmNvZGVfYmRmKHBjaWRldikpOworICAgICAgICAgICAgaWYgKCByYyApIHsKKyAgICAgICAg
ICAgICAgICBMSUJYTF9fTE9HX0VSUk5PVkFMKGN0eCwgTElCWExfX0xPR19FUlJPUiwgcmMs
ICJ4Y19kb21haW5fYmluZF9wdF9iZGYgZmFpbGVkIik7CisgICAgICAgICAgICAgICAgcmV0
dXJuIEVSUk9SX0ZBSUw7CisgICAgICAgICAgICB9CisgICAgICAgIH0KICAgICB9CiAKICAg
ICBpZiAoIXN0YXJ0aW5nKQotLSAKMS43LjQKCgo=
--------------030906040805020201070309
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--------------030906040805020201070309--


From xen-devel-bounces@lists.xen.org Wed Sep 26 14:45:37 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Sep 2012 14: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 1TGsrj-0001VU-Th; Wed, 26 Sep 2012 14:45:31 +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 1TGsrj-0001Ux-4Z
	for xen-devel@lists.xensource.com; Wed, 26 Sep 2012 14:45:31 +0000
Received: from [85.158.143.99:32735] by server-2.bemta-4.messagelabs.com id
	D0/61-06610-A0513605; Wed, 26 Sep 2012 14:45:30 +0000
X-Env-Sender: axboe@kernel.dk
X-Msg-Ref: server-10.tower-216.messagelabs.com!1348670726!25440879!1
X-Originating-IP: [205.233.59.134]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA1LjIzMy41OS4xMzQgPT4gOTIzMTk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15493 invoked from network); 26 Sep 2012 14:45:27 -0000
Received: from merlin.infradead.org (HELO merlin.infradead.org)
	(205.233.59.134)
	by server-10.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 26 Sep 2012 14:45:27 -0000
Received: from canuck.infradead.org ([2001:4978:20e::1])
	by merlin.infradead.org with esmtps (Exim 4.76 #1 (Red Hat Linux))
	id 1TGsrb-00081L-TB; Wed, 26 Sep 2012 14:45:23 +0000
Received: from 87-104-106-3-dynamic-customer.profibernet.dk ([87.104.106.3]
	helo=kernel.dk)
	by canuck.infradead.org with esmtpsa (Exim 4.76 #1 (Red Hat Linux))
	id 1TGsrb-0006iy-B9; Wed, 26 Sep 2012 14:45:23 +0000
Received: from [192.168.0.26] (lenny.home.kernel.dk [192.168.0.26])
	by kernel.dk (Postfix) with ESMTPA id BD7A7561A8;
	Wed, 26 Sep 2012 16:45:21 +0200 (CEST)
Message-ID: <50631501.7020706@kernel.dk>
Date: Wed, 26 Sep 2012 16:45:21 +0200
From: Jens Axboe <axboe@kernel.dk>
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
References: <20120926135855.GA6685@phenom.dumpdata.com>
In-Reply-To: <20120926135855.GA6685@phenom.dumpdata.com>
X-Enigmail-Version: 1.4.4
Cc: xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org
Subject: Re: [Xen-devel] [GIT PULL] (xen) stable/for-jens-3.7
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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-09-26 15:58, Konrad Rzeszutek Wilk wrote:
> Hey Jens,
> 
> I've one more patch (a small change) that I was hoping you could
> pull in your v3.7 branch.
> 
> The branch is:
>  git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git stable/for-jens-3.7
> 
> and has this tiny patch:
> 
> Oliver Chick (1):
>       xen/blkback: Change xen_vbd's flush_support and discard_secure to have type unsigned int, rather than bool

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 Sep 26 14:45:37 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Sep 2012 14: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 1TGsrj-0001VU-Th; Wed, 26 Sep 2012 14:45:31 +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 1TGsrj-0001Ux-4Z
	for xen-devel@lists.xensource.com; Wed, 26 Sep 2012 14:45:31 +0000
Received: from [85.158.143.99:32735] by server-2.bemta-4.messagelabs.com id
	D0/61-06610-A0513605; Wed, 26 Sep 2012 14:45:30 +0000
X-Env-Sender: axboe@kernel.dk
X-Msg-Ref: server-10.tower-216.messagelabs.com!1348670726!25440879!1
X-Originating-IP: [205.233.59.134]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA1LjIzMy41OS4xMzQgPT4gOTIzMTk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15493 invoked from network); 26 Sep 2012 14:45:27 -0000
Received: from merlin.infradead.org (HELO merlin.infradead.org)
	(205.233.59.134)
	by server-10.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 26 Sep 2012 14:45:27 -0000
Received: from canuck.infradead.org ([2001:4978:20e::1])
	by merlin.infradead.org with esmtps (Exim 4.76 #1 (Red Hat Linux))
	id 1TGsrb-00081L-TB; Wed, 26 Sep 2012 14:45:23 +0000
Received: from 87-104-106-3-dynamic-customer.profibernet.dk ([87.104.106.3]
	helo=kernel.dk)
	by canuck.infradead.org with esmtpsa (Exim 4.76 #1 (Red Hat Linux))
	id 1TGsrb-0006iy-B9; Wed, 26 Sep 2012 14:45:23 +0000
Received: from [192.168.0.26] (lenny.home.kernel.dk [192.168.0.26])
	by kernel.dk (Postfix) with ESMTPA id BD7A7561A8;
	Wed, 26 Sep 2012 16:45:21 +0200 (CEST)
Message-ID: <50631501.7020706@kernel.dk>
Date: Wed, 26 Sep 2012 16:45:21 +0200
From: Jens Axboe <axboe@kernel.dk>
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
References: <20120926135855.GA6685@phenom.dumpdata.com>
In-Reply-To: <20120926135855.GA6685@phenom.dumpdata.com>
X-Enigmail-Version: 1.4.4
Cc: xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org
Subject: Re: [Xen-devel] [GIT PULL] (xen) stable/for-jens-3.7
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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-09-26 15:58, Konrad Rzeszutek Wilk wrote:
> Hey Jens,
> 
> I've one more patch (a small change) that I was hoping you could
> pull in your v3.7 branch.
> 
> The branch is:
>  git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git stable/for-jens-3.7
> 
> and has this tiny patch:
> 
> Oliver Chick (1):
>       xen/blkback: Change xen_vbd's flush_support and discard_secure to have type unsigned int, rather than bool

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 Sep 26 14:45:45 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Sep 2012 14: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 1TGsrr-0001Ze-AA; Wed, 26 Sep 2012 14:45:39 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Wei.Wang2@amd.com>) id 1TGsrp-0001Vd-C3
	for xen-devel@lists.xensource.com; Wed, 26 Sep 2012 14:45:37 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1348670728!7282464!1
X-Originating-IP: [216.32.180.30]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2016 invoked from network); 26 Sep 2012 14:45:29 -0000
Received: from va3ehsobe010.messaging.microsoft.com (HELO
	va3outboundpool.messaging.microsoft.com) (216.32.180.30)
	by server-10.tower-27.messagelabs.com with AES128-SHA encrypted SMTP;
	26 Sep 2012 14:45:29 -0000
Received: from mail212-va3-R.bigfish.com (10.7.14.240) by
	VA3EHSOBE014.bigfish.com (10.7.40.64) with Microsoft SMTP Server id
	14.1.225.23; Wed, 26 Sep 2012 14:45:27 +0000
Received: from mail212-va3 (localhost [127.0.0.1])	by
	mail212-va3-R.bigfish.com (Postfix) with ESMTP id 98EF02A01E0;
	Wed, 26 Sep 2012 14:45:27 +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(zzc857hzz1202h1d1ah1d2ahzzz2dh668h839he5bhf0ah107ah1288h12a5h12bdh137ah34h1155h)
Received: from mail212-va3 (localhost.localdomain [127.0.0.1]) by mail212-va3
	(MessageSwitch) id 1348670725336616_7607;
	Wed, 26 Sep 2012 14:45:25 +0000 (UTC)
Received: from VA3EHSMHS008.bigfish.com (unknown [10.7.14.248])	by
	mail212-va3.bigfish.com (Postfix) with ESMTP id 45D3AD40042;
	Wed, 26 Sep 2012 14:45:25 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	VA3EHSMHS008.bigfish.com (10.7.99.18) with Microsoft SMTP Server id
	14.1.225.23; Wed, 26 Sep 2012 14:45:23 +0000
X-WSS-ID: 0MAYOZJ-02-2ZU-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 29253C804C;	Wed, 26 Sep 2012 09:45:18 -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;
	Wed, 26 Sep 2012 09:45:32 -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;
	Wed, 26 Sep 2012 09:45: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, 26 Sep 2012
	10:45:19 -0400
Received: from [165.204.15.57] (gran.osrc.amd.com [165.204.15.57])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id CDBA149C14F; Wed, 26 Sep 2012
	15:45:17 +0100 (BST)
Message-ID: <50631581.6000001@amd.com>
Date: Wed, 26 Sep 2012 16:47:29 +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: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, Jan
	Beulich <JBeulich@suse.com>, Keir Fraser <keir@xen.org>, Ian Campbell
	<Ian.Campbell@citrix.com>, Ian Jackson <Ian.Jackson@eu.citrix.com>
Content-Type: multipart/mixed; boundary="------------000205050606050908020401"
X-OriginatorOrg: amd.com
Subject: [Xen-devel] [PATCH 6 of 6 V6] libxl: Introduce a new guest config
	file parameter
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--------------000205050606050908020401
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 7bit




--------------000205050606050908020401
Content-Type: text/plain; charset="UTF-8";
	name="0006-libxl-Introduce-a-new-guest-config-file-parameter.patch"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="0006-libxl-Introduce-a-new-guest-config-file-parameter.patch"
Content-Description: 0006-libxl-Introduce-a-new-guest-config-file-parameter.patch

RnJvbSAzYjE3YWFkM2YxMjc1Y2FiNDM5ZjY5YTRkMDM3MDk3ZjFjYmNkNmY2IE1vbiBTZXAg
MTcgMDA6MDA6MDAgMjAwMQpGcm9tOiBXZWkgV2FuZyA8d2VpLndhbmcyQGFtZC5jb20+CkRh
dGU6IFdlZCwgMjYgU2VwIDIwMTIgMTE6NDg6MjMgKzAyMDAKU3ViamVjdDogW1BBVENIIDYv
Nl0gbGlieGw6IEludHJvZHVjZSBhIG5ldyBndWVzdCBjb25maWcgZmlsZSBwYXJhbWV0ZXIK
ClVzZSBndWVzdF9pb21tdSA9IHsxLDB9IHRvIGVuYWJsZSBvciBkaXNhYmxlIGd1ZXN0IGlv
bW11IGVtdWxhdGlvbi4KRGVmYXVsdCB2YWx1ZSBpcyAwLiBSZWdyZXNzaW9uIHRlc3RzIGhh
dmUgYmVlbiBkb25lIHRvIG1ha2Ugc3VyZQppdCBkb2VzIG5vdCBicmVhayBub24taW9tbXV2
MiBzeXN0ZW1zLgoKU2lnbmVkLW9mZi1ieTogV2VpIFdhbmcgPHdlaS53YW5nMkBhbWQuY29t
PgotLS0KIGRvY3MvbWFuL3hsLmNmZy5wb2QuNSAgICAgICB8ICAgIDUgKysrKysKIHRvb2xz
L2xpYnhsL2xpYnhsX2NyZWF0ZS5jICB8ICAgIDUgKysrKy0KIHRvb2xzL2xpYnhsL2xpYnhs
X3R5cGVzLmlkbCB8ICAgIDEgKwogdG9vbHMvbGlieGwveGxfY21kaW1wbC5jICAgIHwgICAg
MSArCiA0IGZpbGVzIGNoYW5nZWQsIDExIGluc2VydGlvbnMoKyksIDEgZGVsZXRpb25zKC0p
CgpkaWZmIC0tZ2l0IGEvZG9jcy9tYW4veGwuY2ZnLnBvZC41IGIvZG9jcy9tYW4veGwuY2Zn
LnBvZC41CmluZGV4IDAxMzI3MGQuLjJiZWY0MjkgMTAwNjQ0Ci0tLSBhL2RvY3MvbWFuL3hs
LmNmZy5wb2QuNQorKysgYi9kb2NzL21hbi94bC5jZmcucG9kLjUKQEAgLTI3MCw2ICsyNzAs
MTEgQEAgVVVJRCB3aWxsIGJlIGdlbmVyYXRlZC4KIAogQXNzaWduIGFuIFhTTSBzZWN1cml0
eSBsYWJlbCB0byB0aGlzIGRvbWFpbi4KIAorPWl0ZW0gQjxndWVzdF9pb21tdT1CT09MRUFO
PgorCitFbmFibGUgYSB2aXJ0dWFsIGlvbW11IGRldmljZSBmb3IgaHZtIGd1ZXN0LiBJdCBz
aG91bGQgYmUgZW5hYmxlZCB0byAKK3Bhc3N0aHJvdWdoIEFNRCBIRDc5MDAgc2VyaWVzIEdQ
R1BVLgorCiA9aXRlbSBCPG5vbWlncmF0ZT1CT09MRUFOPgogCiBEaXNhYmxlIG1pZ3JhdGlv
biBvZiB0aGlzIGRvbWFpbi4gIFRoaXMgZW5hYmxlcyBjZXJ0YWluIG90aGVyIGZlYXR1cmVz
CmRpZmYgLS1naXQgYS90b29scy9saWJ4bC9saWJ4bF9jcmVhdGUuYyBiL3Rvb2xzL2xpYnhs
L2xpYnhsX2NyZWF0ZS5jCmluZGV4IGVmMTdmMDUuLjU4NTRhMTMgMTAwNjQ0Ci0tLSBhL3Rv
b2xzL2xpYnhsL2xpYnhsX2NyZWF0ZS5jCisrKyBiL3Rvb2xzL2xpYnhsL2xpYnhsX2NyZWF0
ZS5jCkBAIC0yNTAsNiArMjUwLDcgQEAgaW50IGxpYnhsX19kb21haW5fYnVpbGRfaW5mb19z
ZXRkZWZhdWx0KGxpYnhsX19nYyAqZ2MsCiAgICAgICAgIGxpYnhsX2RlZmJvb2xfc2V0ZGVm
YXVsdCgmYl9pbmZvLT51Lmh2bS5uZXN0ZWRfaHZtLCAgICAgICAgIGZhbHNlKTsKICAgICAg
ICAgbGlieGxfZGVmYm9vbF9zZXRkZWZhdWx0KCZiX2luZm8tPnUuaHZtLnVzYiwgICAgICAg
ICAgICAgICAgZmFsc2UpOwogICAgICAgICBsaWJ4bF9kZWZib29sX3NldGRlZmF1bHQoJmJf
aW5mby0+dS5odm0ueGVuX3BsYXRmb3JtX3BjaSwgICB0cnVlKTsKKyAgICAgICAgbGlieGxf
ZGVmYm9vbF9zZXRkZWZhdWx0KCZiX2luZm8tPnUuaHZtLmd1ZXN0X2lvbW11LCAgICAgICAg
ZmFsc2UpOwogCiAgICAgICAgIGlmICghYl9pbmZvLT51Lmh2bS5ib290KSB7CiAgICAgICAg
ICAgICBiX2luZm8tPnUuaHZtLmJvb3QgPSBzdHJkdXAoImNkYSIpOwpAQCAtMzQwLDEzICsz
NDEsMTUgQEAgaW50IGxpYnhsX19kb21haW5fYnVpbGQobGlieGxfX2djICpnYywKICAgICAg
ICAgdm1lbnRzWzRdID0gInN0YXJ0X3RpbWUiOwogICAgICAgICB2bWVudHNbNV0gPSBsaWJ4
bF9fc3ByaW50ZihnYywgIiVsdS4lMDJkIiwgc3RhcnRfdGltZS50dl9zZWMsKGludClzdGFy
dF90aW1lLnR2X3VzZWMvMTAwMDApOwogCi0gICAgICAgIGxvY2FsZW50cyA9IGxpYnhsX19j
YWxsb2MoZ2MsIDcsIHNpemVvZihjaGFyICopKTsKKyAgICAgICAgbG9jYWxlbnRzID0gbGli
eGxfX2NhbGxvYyhnYywgOSwgc2l6ZW9mKGNoYXIgKikpOwogICAgICAgICBsb2NhbGVudHNb
MF0gPSAicGxhdGZvcm0vYWNwaSI7CiAgICAgICAgIGxvY2FsZW50c1sxXSA9IGxpYnhsX2Rl
ZmJvb2xfdmFsKGluZm8tPnUuaHZtLmFjcGkpID8gIjEiIDogIjAiOwogICAgICAgICBsb2Nh
bGVudHNbMl0gPSAicGxhdGZvcm0vYWNwaV9zMyI7CiAgICAgICAgIGxvY2FsZW50c1szXSA9
IGxpYnhsX2RlZmJvb2xfdmFsKGluZm8tPnUuaHZtLmFjcGlfczMpID8gIjEiIDogIjAiOwog
ICAgICAgICBsb2NhbGVudHNbNF0gPSAicGxhdGZvcm0vYWNwaV9zNCI7CiAgICAgICAgIGxv
Y2FsZW50c1s1XSA9IGxpYnhsX2RlZmJvb2xfdmFsKGluZm8tPnUuaHZtLmFjcGlfczQpID8g
IjEiIDogIjAiOworICAgICAgICBsb2NhbGVudHNbNl0gPSAiZ3Vlc3RfaW9tbXUiOworICAg
ICAgICBsb2NhbGVudHNbN10gPSBsaWJ4bF9kZWZib29sX3ZhbChpbmZvLT51Lmh2bS5ndWVz
dF9pb21tdSkgPyAiMSIgOiAiMCI7CiAKICAgICAgICAgYnJlYWs7CiAgICAgY2FzZSBMSUJY
TF9ET01BSU5fVFlQRV9QVjoKZGlmZiAtLWdpdCBhL3Rvb2xzL2xpYnhsL2xpYnhsX3R5cGVz
LmlkbCBiL3Rvb2xzL2xpYnhsL2xpYnhsX3R5cGVzLmlkbAppbmRleCA2ZDVjNTc4Li5hZmQ1
MGExIDEwMDY0NAotLS0gYS90b29scy9saWJ4bC9saWJ4bF90eXBlcy5pZGwKKysrIGIvdG9v
bHMvbGlieGwvbGlieGxfdHlwZXMuaWRsCkBAIC0zMTksNiArMzE5LDcgQEAgbGlieGxfZG9t
YWluX2J1aWxkX2luZm8gPSBTdHJ1Y3QoImRvbWFpbl9idWlsZF9pbmZvIixbCiAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAoInVzYmRldmljZSIsICAgICAgICBz
dHJpbmcpLAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKCJzb3Vu
ZGh3IiwgICAgICAgICAgc3RyaW5nKSwKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICgieGVuX3BsYXRmb3JtX3BjaSIsIGxpYnhsX2RlZmJvb2wpLAorICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKCJndWVzdF9pb21tdSIsICAgICAg
bGlieGxfZGVmYm9vbCksCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICBdKSksCiAgICAgICAgICAgICAgICAgICgicHYiLCBTdHJ1Y3QoTm9uZSwgWygia2VybmVs
Iiwgc3RyaW5nKSwKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKCJz
bGFja19tZW1rYiIsIE1lbUtCKSwKZGlmZiAtLWdpdCBhL3Rvb2xzL2xpYnhsL3hsX2NtZGlt
cGwuYyBiL3Rvb2xzL2xpYnhsL3hsX2NtZGltcGwuYwppbmRleCAxNjI3Y2FjLi5iN2UxMGI2
IDEwMDY0NAotLS0gYS90b29scy9saWJ4bC94bF9jbWRpbXBsLmMKKysrIGIvdG9vbHMvbGli
eGwveGxfY21kaW1wbC5jCkBAIC04NjQsNiArODY0LDcgQEAgc3RhdGljIHZvaWQgcGFyc2Vf
Y29uZmlnX2RhdGEoY29uc3QgY2hhciAqY29uZmlnX3NvdXJjZSwKICAgICAgICAgfQogCiAg
ICAgICAgIHhsdV9jZmdfZ2V0X2RlZmJvb2woY29uZmlnLCAibmVzdGVkaHZtIiwgJmJfaW5m
by0+dS5odm0ubmVzdGVkX2h2bSwgMCk7CisgICAgICAgIHhsdV9jZmdfZ2V0X2RlZmJvb2wo
Y29uZmlnLCAiZ3Vlc3RfaW9tbXUiLCAmYl9pbmZvLT51Lmh2bS5ndWVzdF9pb21tdSwgMCk7
CiAgICAgICAgIGJyZWFrOwogICAgIGNhc2UgTElCWExfRE9NQUlOX1RZUEVfUFY6CiAgICAg
ewotLSAKMS43LjQKCgo=
--------------000205050606050908020401
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--------------000205050606050908020401--


From xen-devel-bounces@lists.xen.org Wed Sep 26 14:45:45 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Sep 2012 14: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 1TGsrr-0001Ze-AA; Wed, 26 Sep 2012 14:45:39 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Wei.Wang2@amd.com>) id 1TGsrp-0001Vd-C3
	for xen-devel@lists.xensource.com; Wed, 26 Sep 2012 14:45:37 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1348670728!7282464!1
X-Originating-IP: [216.32.180.30]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2016 invoked from network); 26 Sep 2012 14:45:29 -0000
Received: from va3ehsobe010.messaging.microsoft.com (HELO
	va3outboundpool.messaging.microsoft.com) (216.32.180.30)
	by server-10.tower-27.messagelabs.com with AES128-SHA encrypted SMTP;
	26 Sep 2012 14:45:29 -0000
Received: from mail212-va3-R.bigfish.com (10.7.14.240) by
	VA3EHSOBE014.bigfish.com (10.7.40.64) with Microsoft SMTP Server id
	14.1.225.23; Wed, 26 Sep 2012 14:45:27 +0000
Received: from mail212-va3 (localhost [127.0.0.1])	by
	mail212-va3-R.bigfish.com (Postfix) with ESMTP id 98EF02A01E0;
	Wed, 26 Sep 2012 14:45:27 +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(zzc857hzz1202h1d1ah1d2ahzzz2dh668h839he5bhf0ah107ah1288h12a5h12bdh137ah34h1155h)
Received: from mail212-va3 (localhost.localdomain [127.0.0.1]) by mail212-va3
	(MessageSwitch) id 1348670725336616_7607;
	Wed, 26 Sep 2012 14:45:25 +0000 (UTC)
Received: from VA3EHSMHS008.bigfish.com (unknown [10.7.14.248])	by
	mail212-va3.bigfish.com (Postfix) with ESMTP id 45D3AD40042;
	Wed, 26 Sep 2012 14:45:25 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	VA3EHSMHS008.bigfish.com (10.7.99.18) with Microsoft SMTP Server id
	14.1.225.23; Wed, 26 Sep 2012 14:45:23 +0000
X-WSS-ID: 0MAYOZJ-02-2ZU-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 29253C804C;	Wed, 26 Sep 2012 09:45:18 -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;
	Wed, 26 Sep 2012 09:45:32 -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;
	Wed, 26 Sep 2012 09:45: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, 26 Sep 2012
	10:45:19 -0400
Received: from [165.204.15.57] (gran.osrc.amd.com [165.204.15.57])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id CDBA149C14F; Wed, 26 Sep 2012
	15:45:17 +0100 (BST)
Message-ID: <50631581.6000001@amd.com>
Date: Wed, 26 Sep 2012 16:47:29 +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: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, Jan
	Beulich <JBeulich@suse.com>, Keir Fraser <keir@xen.org>, Ian Campbell
	<Ian.Campbell@citrix.com>, Ian Jackson <Ian.Jackson@eu.citrix.com>
Content-Type: multipart/mixed; boundary="------------000205050606050908020401"
X-OriginatorOrg: amd.com
Subject: [Xen-devel] [PATCH 6 of 6 V6] libxl: Introduce a new guest config
	file parameter
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--------------000205050606050908020401
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 7bit




--------------000205050606050908020401
Content-Type: text/plain; charset="UTF-8";
	name="0006-libxl-Introduce-a-new-guest-config-file-parameter.patch"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="0006-libxl-Introduce-a-new-guest-config-file-parameter.patch"
Content-Description: 0006-libxl-Introduce-a-new-guest-config-file-parameter.patch

RnJvbSAzYjE3YWFkM2YxMjc1Y2FiNDM5ZjY5YTRkMDM3MDk3ZjFjYmNkNmY2IE1vbiBTZXAg
MTcgMDA6MDA6MDAgMjAwMQpGcm9tOiBXZWkgV2FuZyA8d2VpLndhbmcyQGFtZC5jb20+CkRh
dGU6IFdlZCwgMjYgU2VwIDIwMTIgMTE6NDg6MjMgKzAyMDAKU3ViamVjdDogW1BBVENIIDYv
Nl0gbGlieGw6IEludHJvZHVjZSBhIG5ldyBndWVzdCBjb25maWcgZmlsZSBwYXJhbWV0ZXIK
ClVzZSBndWVzdF9pb21tdSA9IHsxLDB9IHRvIGVuYWJsZSBvciBkaXNhYmxlIGd1ZXN0IGlv
bW11IGVtdWxhdGlvbi4KRGVmYXVsdCB2YWx1ZSBpcyAwLiBSZWdyZXNzaW9uIHRlc3RzIGhh
dmUgYmVlbiBkb25lIHRvIG1ha2Ugc3VyZQppdCBkb2VzIG5vdCBicmVhayBub24taW9tbXV2
MiBzeXN0ZW1zLgoKU2lnbmVkLW9mZi1ieTogV2VpIFdhbmcgPHdlaS53YW5nMkBhbWQuY29t
PgotLS0KIGRvY3MvbWFuL3hsLmNmZy5wb2QuNSAgICAgICB8ICAgIDUgKysrKysKIHRvb2xz
L2xpYnhsL2xpYnhsX2NyZWF0ZS5jICB8ICAgIDUgKysrKy0KIHRvb2xzL2xpYnhsL2xpYnhs
X3R5cGVzLmlkbCB8ICAgIDEgKwogdG9vbHMvbGlieGwveGxfY21kaW1wbC5jICAgIHwgICAg
MSArCiA0IGZpbGVzIGNoYW5nZWQsIDExIGluc2VydGlvbnMoKyksIDEgZGVsZXRpb25zKC0p
CgpkaWZmIC0tZ2l0IGEvZG9jcy9tYW4veGwuY2ZnLnBvZC41IGIvZG9jcy9tYW4veGwuY2Zn
LnBvZC41CmluZGV4IDAxMzI3MGQuLjJiZWY0MjkgMTAwNjQ0Ci0tLSBhL2RvY3MvbWFuL3hs
LmNmZy5wb2QuNQorKysgYi9kb2NzL21hbi94bC5jZmcucG9kLjUKQEAgLTI3MCw2ICsyNzAs
MTEgQEAgVVVJRCB3aWxsIGJlIGdlbmVyYXRlZC4KIAogQXNzaWduIGFuIFhTTSBzZWN1cml0
eSBsYWJlbCB0byB0aGlzIGRvbWFpbi4KIAorPWl0ZW0gQjxndWVzdF9pb21tdT1CT09MRUFO
PgorCitFbmFibGUgYSB2aXJ0dWFsIGlvbW11IGRldmljZSBmb3IgaHZtIGd1ZXN0LiBJdCBz
aG91bGQgYmUgZW5hYmxlZCB0byAKK3Bhc3N0aHJvdWdoIEFNRCBIRDc5MDAgc2VyaWVzIEdQ
R1BVLgorCiA9aXRlbSBCPG5vbWlncmF0ZT1CT09MRUFOPgogCiBEaXNhYmxlIG1pZ3JhdGlv
biBvZiB0aGlzIGRvbWFpbi4gIFRoaXMgZW5hYmxlcyBjZXJ0YWluIG90aGVyIGZlYXR1cmVz
CmRpZmYgLS1naXQgYS90b29scy9saWJ4bC9saWJ4bF9jcmVhdGUuYyBiL3Rvb2xzL2xpYnhs
L2xpYnhsX2NyZWF0ZS5jCmluZGV4IGVmMTdmMDUuLjU4NTRhMTMgMTAwNjQ0Ci0tLSBhL3Rv
b2xzL2xpYnhsL2xpYnhsX2NyZWF0ZS5jCisrKyBiL3Rvb2xzL2xpYnhsL2xpYnhsX2NyZWF0
ZS5jCkBAIC0yNTAsNiArMjUwLDcgQEAgaW50IGxpYnhsX19kb21haW5fYnVpbGRfaW5mb19z
ZXRkZWZhdWx0KGxpYnhsX19nYyAqZ2MsCiAgICAgICAgIGxpYnhsX2RlZmJvb2xfc2V0ZGVm
YXVsdCgmYl9pbmZvLT51Lmh2bS5uZXN0ZWRfaHZtLCAgICAgICAgIGZhbHNlKTsKICAgICAg
ICAgbGlieGxfZGVmYm9vbF9zZXRkZWZhdWx0KCZiX2luZm8tPnUuaHZtLnVzYiwgICAgICAg
ICAgICAgICAgZmFsc2UpOwogICAgICAgICBsaWJ4bF9kZWZib29sX3NldGRlZmF1bHQoJmJf
aW5mby0+dS5odm0ueGVuX3BsYXRmb3JtX3BjaSwgICB0cnVlKTsKKyAgICAgICAgbGlieGxf
ZGVmYm9vbF9zZXRkZWZhdWx0KCZiX2luZm8tPnUuaHZtLmd1ZXN0X2lvbW11LCAgICAgICAg
ZmFsc2UpOwogCiAgICAgICAgIGlmICghYl9pbmZvLT51Lmh2bS5ib290KSB7CiAgICAgICAg
ICAgICBiX2luZm8tPnUuaHZtLmJvb3QgPSBzdHJkdXAoImNkYSIpOwpAQCAtMzQwLDEzICsz
NDEsMTUgQEAgaW50IGxpYnhsX19kb21haW5fYnVpbGQobGlieGxfX2djICpnYywKICAgICAg
ICAgdm1lbnRzWzRdID0gInN0YXJ0X3RpbWUiOwogICAgICAgICB2bWVudHNbNV0gPSBsaWJ4
bF9fc3ByaW50ZihnYywgIiVsdS4lMDJkIiwgc3RhcnRfdGltZS50dl9zZWMsKGludClzdGFy
dF90aW1lLnR2X3VzZWMvMTAwMDApOwogCi0gICAgICAgIGxvY2FsZW50cyA9IGxpYnhsX19j
YWxsb2MoZ2MsIDcsIHNpemVvZihjaGFyICopKTsKKyAgICAgICAgbG9jYWxlbnRzID0gbGli
eGxfX2NhbGxvYyhnYywgOSwgc2l6ZW9mKGNoYXIgKikpOwogICAgICAgICBsb2NhbGVudHNb
MF0gPSAicGxhdGZvcm0vYWNwaSI7CiAgICAgICAgIGxvY2FsZW50c1sxXSA9IGxpYnhsX2Rl
ZmJvb2xfdmFsKGluZm8tPnUuaHZtLmFjcGkpID8gIjEiIDogIjAiOwogICAgICAgICBsb2Nh
bGVudHNbMl0gPSAicGxhdGZvcm0vYWNwaV9zMyI7CiAgICAgICAgIGxvY2FsZW50c1szXSA9
IGxpYnhsX2RlZmJvb2xfdmFsKGluZm8tPnUuaHZtLmFjcGlfczMpID8gIjEiIDogIjAiOwog
ICAgICAgICBsb2NhbGVudHNbNF0gPSAicGxhdGZvcm0vYWNwaV9zNCI7CiAgICAgICAgIGxv
Y2FsZW50c1s1XSA9IGxpYnhsX2RlZmJvb2xfdmFsKGluZm8tPnUuaHZtLmFjcGlfczQpID8g
IjEiIDogIjAiOworICAgICAgICBsb2NhbGVudHNbNl0gPSAiZ3Vlc3RfaW9tbXUiOworICAg
ICAgICBsb2NhbGVudHNbN10gPSBsaWJ4bF9kZWZib29sX3ZhbChpbmZvLT51Lmh2bS5ndWVz
dF9pb21tdSkgPyAiMSIgOiAiMCI7CiAKICAgICAgICAgYnJlYWs7CiAgICAgY2FzZSBMSUJY
TF9ET01BSU5fVFlQRV9QVjoKZGlmZiAtLWdpdCBhL3Rvb2xzL2xpYnhsL2xpYnhsX3R5cGVz
LmlkbCBiL3Rvb2xzL2xpYnhsL2xpYnhsX3R5cGVzLmlkbAppbmRleCA2ZDVjNTc4Li5hZmQ1
MGExIDEwMDY0NAotLS0gYS90b29scy9saWJ4bC9saWJ4bF90eXBlcy5pZGwKKysrIGIvdG9v
bHMvbGlieGwvbGlieGxfdHlwZXMuaWRsCkBAIC0zMTksNiArMzE5LDcgQEAgbGlieGxfZG9t
YWluX2J1aWxkX2luZm8gPSBTdHJ1Y3QoImRvbWFpbl9idWlsZF9pbmZvIixbCiAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAoInVzYmRldmljZSIsICAgICAgICBz
dHJpbmcpLAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKCJzb3Vu
ZGh3IiwgICAgICAgICAgc3RyaW5nKSwKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICgieGVuX3BsYXRmb3JtX3BjaSIsIGxpYnhsX2RlZmJvb2wpLAorICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKCJndWVzdF9pb21tdSIsICAgICAg
bGlieGxfZGVmYm9vbCksCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICBdKSksCiAgICAgICAgICAgICAgICAgICgicHYiLCBTdHJ1Y3QoTm9uZSwgWygia2VybmVs
Iiwgc3RyaW5nKSwKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKCJz
bGFja19tZW1rYiIsIE1lbUtCKSwKZGlmZiAtLWdpdCBhL3Rvb2xzL2xpYnhsL3hsX2NtZGlt
cGwuYyBiL3Rvb2xzL2xpYnhsL3hsX2NtZGltcGwuYwppbmRleCAxNjI3Y2FjLi5iN2UxMGI2
IDEwMDY0NAotLS0gYS90b29scy9saWJ4bC94bF9jbWRpbXBsLmMKKysrIGIvdG9vbHMvbGli
eGwveGxfY21kaW1wbC5jCkBAIC04NjQsNiArODY0LDcgQEAgc3RhdGljIHZvaWQgcGFyc2Vf
Y29uZmlnX2RhdGEoY29uc3QgY2hhciAqY29uZmlnX3NvdXJjZSwKICAgICAgICAgfQogCiAg
ICAgICAgIHhsdV9jZmdfZ2V0X2RlZmJvb2woY29uZmlnLCAibmVzdGVkaHZtIiwgJmJfaW5m
by0+dS5odm0ubmVzdGVkX2h2bSwgMCk7CisgICAgICAgIHhsdV9jZmdfZ2V0X2RlZmJvb2wo
Y29uZmlnLCAiZ3Vlc3RfaW9tbXUiLCAmYl9pbmZvLT51Lmh2bS5ndWVzdF9pb21tdSwgMCk7
CiAgICAgICAgIGJyZWFrOwogICAgIGNhc2UgTElCWExfRE9NQUlOX1RZUEVfUFY6CiAgICAg
ewotLSAKMS43LjQKCgo=
--------------000205050606050908020401
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--------------000205050606050908020401--


From xen-devel-bounces@lists.xen.org Wed Sep 26 14:57:44 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Sep 2012 14: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 1TGt3M-0002fe-Iq; Wed, 26 Sep 2012 14:57: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 1TGt3K-0002fZ-R8
	for Xen-devel@lists.xensource.com; Wed, 26 Sep 2012 14:57:31 +0000
Received: from [85.158.143.99:11390] by server-3.bemta-4.messagelabs.com id
	4F/11-10986-AD713605; Wed, 26 Sep 2012 14:57:30 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1348671447!23738105!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDc3NTczOQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3140 invoked from network); 26 Sep 2012 14:57:29 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-12.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 26 Sep 2012 14:57: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 q8QEvLLY012005
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 26 Sep 2012 14:57:21 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q8QEvKdr001176
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 26 Sep 2012 14:57:21 GMT
Received: from abhmt106.oracle.com (abhmt106.oracle.com [141.146.116.58])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q8QEvKSh026718; Wed, 26 Sep 2012 09:57:20 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 26 Sep 2012 07:57:20 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id E13EB4035A; Wed, 26 Sep 2012 10:46:03 -0400 (EDT)
Date: Wed, 26 Sep 2012 10:46:03 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120926144603.GB24866@phenom.dumpdata.com>
References: <20120921121202.3163c379@mantra.us.oracle.com>
	<1348665924.19176.41.camel@zakaz.uk.xensource.com>
	<20120926133736.GA9919@phenom.dumpdata.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120926133736.GA9919@phenom.dumpdata.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: "Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v1 0/8]: PVH (PV guest with extensions)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Sep 26, 2012 at 09:37:36AM -0400, Konrad Rzeszutek Wilk wrote:
> On Wed, Sep 26, 2012 at 02:25:24PM +0100, Ian Campbell wrote:
> > On Fri, 2012-09-21 at 20:12 +0100, Mukesh Rathor wrote:
> > > Hi guys,
> > > 
> > > Ok, I've made all the changes from prev RFC patch submission. Tested
> > > all the combinations. The patches are a bit smaller from before, and
> > > couldn't be separated like before, so I can't state whats different in
> > > each patch. But, it's not too bad to review now.
> > > 
> > > As before, they were built on top of
> > > fc6bdb59a501740b28ed3b616641a22c8dc5dd31 from the following tree:
> > >         
> > > git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
> > 
> > Is that correct? That's this commit:
> > 
> > commit fc6bdb59a501740b28ed3b616641a22c8dc5dd31
> > Merge: 44d82e2 1fcfd08
> > Author: Linus Torvalds <torvalds@linux-foundation.org>
> > Date:   Thu Aug 2 11:52:39 2012 -0700
> > 
> > Why so old? Makes it hard to take these for a spin due to the
> > rebasing...
> 
> I rebased them on top v3.6-rc6 (look in #linux-next-pvh) but I must
> have done something wrong b/c it won't boot as PVHVM. Time to do some git
> bisection and see where I failed.

Culprit found. I've rebased and added some of my patches to the branch.
They are on top of v3.6-rc6 + patches going in for v3.7.

git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git linux-next-pvh

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 26 14:57:44 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Sep 2012 14: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 1TGt3M-0002fe-Iq; Wed, 26 Sep 2012 14:57: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 1TGt3K-0002fZ-R8
	for Xen-devel@lists.xensource.com; Wed, 26 Sep 2012 14:57:31 +0000
Received: from [85.158.143.99:11390] by server-3.bemta-4.messagelabs.com id
	4F/11-10986-AD713605; Wed, 26 Sep 2012 14:57:30 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1348671447!23738105!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDc3NTczOQ==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3140 invoked from network); 26 Sep 2012 14:57:29 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-12.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 26 Sep 2012 14:57: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 q8QEvLLY012005
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 26 Sep 2012 14:57:21 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q8QEvKdr001176
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 26 Sep 2012 14:57:21 GMT
Received: from abhmt106.oracle.com (abhmt106.oracle.com [141.146.116.58])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q8QEvKSh026718; Wed, 26 Sep 2012 09:57:20 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 26 Sep 2012 07:57:20 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id E13EB4035A; Wed, 26 Sep 2012 10:46:03 -0400 (EDT)
Date: Wed, 26 Sep 2012 10:46:03 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120926144603.GB24866@phenom.dumpdata.com>
References: <20120921121202.3163c379@mantra.us.oracle.com>
	<1348665924.19176.41.camel@zakaz.uk.xensource.com>
	<20120926133736.GA9919@phenom.dumpdata.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120926133736.GA9919@phenom.dumpdata.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: "Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v1 0/8]: PVH (PV guest with extensions)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Sep 26, 2012 at 09:37:36AM -0400, Konrad Rzeszutek Wilk wrote:
> On Wed, Sep 26, 2012 at 02:25:24PM +0100, Ian Campbell wrote:
> > On Fri, 2012-09-21 at 20:12 +0100, Mukesh Rathor wrote:
> > > Hi guys,
> > > 
> > > Ok, I've made all the changes from prev RFC patch submission. Tested
> > > all the combinations. The patches are a bit smaller from before, and
> > > couldn't be separated like before, so I can't state whats different in
> > > each patch. But, it's not too bad to review now.
> > > 
> > > As before, they were built on top of
> > > fc6bdb59a501740b28ed3b616641a22c8dc5dd31 from the following tree:
> > >         
> > > git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
> > 
> > Is that correct? That's this commit:
> > 
> > commit fc6bdb59a501740b28ed3b616641a22c8dc5dd31
> > Merge: 44d82e2 1fcfd08
> > Author: Linus Torvalds <torvalds@linux-foundation.org>
> > Date:   Thu Aug 2 11:52:39 2012 -0700
> > 
> > Why so old? Makes it hard to take these for a spin due to the
> > rebasing...
> 
> I rebased them on top v3.6-rc6 (look in #linux-next-pvh) but I must
> have done something wrong b/c it won't boot as PVHVM. Time to do some git
> bisection and see where I failed.

Culprit found. I've rebased and added some of my patches to the branch.
They are on top of v3.6-rc6 + patches going in for v3.7.

git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git linux-next-pvh

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 26 15:03:18 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Sep 2012 15: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 1TGt8k-0002u4-Bk; Wed, 26 Sep 2012 15: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 1TGt8j-0002tx-A8
	for xen-devel@lists.xen.org; Wed, 26 Sep 2012 15:03:05 +0000
Received: from [85.158.139.211:12448] by server-14.bemta-5.messagelabs.com id
	8B/F8-05772-82913605; Wed, 26 Sep 2012 15:03:04 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-206.messagelabs.com!1348671783!20040752!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTE1NzQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2383 invoked from network); 26 Sep 2012 15:03:04 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Sep 2012 15:03:04 -0000
X-IronPort-AV: E=Sophos;i="4.80,490,1344211200"; d="scan'208";a="14781292"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Sep 2012 15:03: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.279.1; Wed, 26 Sep 2012 16:03: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
	1TGt8g-0001eR-UW; Wed, 26 Sep 2012 15:03:02 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1TGt8g-0007ew-R2;
	Wed, 26 Sep 2012 16:03:02 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20579.6438.538065.533618@mariner.uk.xensource.com>
Date: Wed, 26 Sep 2012 16:03:02 +0100
To: Julien Grall <julien.grall@citrix.com>
In-Reply-To: <1348572817-13908-1-git-send-email-julien.grall@citrix.com>
References: <1348572817-13908-1-git-send-email-julien.grall@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 V2] libxenstore: filter watch events in
 libxenstore when we unwatch
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Julien Grall writes ("[PATCH V2] libxenstore: filter watch events in libxenstore when we unwatch"):
> While on entry to xs_unwatch, there may be an event on its way from
> xenstored (eg in the ring or in the local kernel), all such events
> will definitely come before the reply to the unwatch command.  So at
> the point where the unwatch reply has been processed (after xs_talkv),
> any such now-deleted watch events will definitely have made it to
> libxenstore's queue where we can remove them.

Thanks.

> +
> +/* Clear the pipe token if there are no more pending watchs.
> + * We suppose the watch_mutex is already taken.
> + */
> +static void xs_clear_watch_pipe(struct xs_handle *h)

I think this would be better called xs_maybe_clear_watch_pipe or
something.  Since it doesn't always clear the watch pipe, it makes the
call sites confusing.

> @@ -855,14 +864,62 @@ char **xs_read_watch(struct xs_handle *h, unsigned int *num)
>  bool xs_unwatch(struct xs_handle *h, const char *path, const char *token)
>  {
>  	struct iovec iov[2];
> +	struct xs_stored_msg *msg, *tmsg;
> +	bool res;
> +	char *s, *p;
> +	unsigned int i;
> +	char *l_token, *l_path;
>  
>  	iov[0].iov_base = (char *)path;
>  	iov[0].iov_len = strlen(path) + 1;
>  	iov[1].iov_base = (char *)token;
>  	iov[1].iov_len = strlen(token) + 1;
>  
> -	return xs_bool(xs_talkv(h, XBT_NULL, XS_UNWATCH, iov,
> -				ARRAY_SIZE(iov), NULL));
> +	res = xs_bool(xs_talkv(h, XBT_NULL, XS_UNWATCH, iov,
> +						   ARRAY_SIZE(iov), NULL));
> +
> +	/* Filter the watch list to remove potential message */
> +	mutex_lock(&h->watch_mutex);
> +
> +	if (list_empty(&h->watch_list)) {
> +		mutex_unlock(&h->watch_mutex);
> +		return res;
> +	}

I still think this is redundant, so it should not be here.

> +	list_for_each_entry_safe(msg, tmsg, &h->watch_list, list) {
> +		assert(msg->hdr.type == XS_WATCH_EVENT);
> +
> +		s = msg->body;
> +
> +		l_token = NULL;
> +		l_path = NULL;
> +
> +		for (p = s, i = 0; p < msg->body + msg->hdr.len; p++) {
> +			if (*p == '\0')
> +			{
> +				if (i == XS_WATCH_TOKEN)
> +					l_token = s;
> +				else if (i == XS_WATCH_PATH)
> +					l_path = s;
> +				i++;
> +				s = p + 1;
> +			}
> +		}
> +
> +		if (l_token && !strcmp(token, l_token)
> +			/* Use strncmp because we can have a watch fired on sub-directory */

Oh bum.  I see a problem.  This is quite a bad problem.

It is legal to do this:

   client:

     XS_WATCH /foo token1
     XS_WATCH /foo/bar token1

Now if you get a watch event you get the token and the actual path.
So suppose we have, simultaneously:

   our client:                          another client:
     XS_UNWATCH /foo/bar token1          WRITE /foo/bar/zonk sponge

Then xenstored will generate two watch events:
                                WATCH_EVENT /foo/bar/zonk token1
                                WATCH_EVENT /foo/bar/zonk token1

With your patch, both of these would be thrown away.  Whereas in fact
one of them should still be presented.

How confident are we that there are no clients which rely on this not
changing ?

At the very least this needs a documentation patch explaining the
undesirable consequences of setting multiple watches with the same
token.  Arguably it needs a flag to the library (or a new function
name) to ask for this new behaviour.

I would have to think, for example, about whether the new libxl event
sub-library would make any mistakes as a result of this proposed
change.  I think it wouldn'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 Sep 26 15:03:18 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Sep 2012 15: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 1TGt8k-0002u4-Bk; Wed, 26 Sep 2012 15: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 1TGt8j-0002tx-A8
	for xen-devel@lists.xen.org; Wed, 26 Sep 2012 15:03:05 +0000
Received: from [85.158.139.211:12448] by server-14.bemta-5.messagelabs.com id
	8B/F8-05772-82913605; Wed, 26 Sep 2012 15:03:04 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-206.messagelabs.com!1348671783!20040752!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTE1NzQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2383 invoked from network); 26 Sep 2012 15:03:04 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Sep 2012 15:03:04 -0000
X-IronPort-AV: E=Sophos;i="4.80,490,1344211200"; d="scan'208";a="14781292"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Sep 2012 15:03: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.279.1; Wed, 26 Sep 2012 16:03: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
	1TGt8g-0001eR-UW; Wed, 26 Sep 2012 15:03:02 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1TGt8g-0007ew-R2;
	Wed, 26 Sep 2012 16:03:02 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20579.6438.538065.533618@mariner.uk.xensource.com>
Date: Wed, 26 Sep 2012 16:03:02 +0100
To: Julien Grall <julien.grall@citrix.com>
In-Reply-To: <1348572817-13908-1-git-send-email-julien.grall@citrix.com>
References: <1348572817-13908-1-git-send-email-julien.grall@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 V2] libxenstore: filter watch events in
 libxenstore when we unwatch
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Julien Grall writes ("[PATCH V2] libxenstore: filter watch events in libxenstore when we unwatch"):
> While on entry to xs_unwatch, there may be an event on its way from
> xenstored (eg in the ring or in the local kernel), all such events
> will definitely come before the reply to the unwatch command.  So at
> the point where the unwatch reply has been processed (after xs_talkv),
> any such now-deleted watch events will definitely have made it to
> libxenstore's queue where we can remove them.

Thanks.

> +
> +/* Clear the pipe token if there are no more pending watchs.
> + * We suppose the watch_mutex is already taken.
> + */
> +static void xs_clear_watch_pipe(struct xs_handle *h)

I think this would be better called xs_maybe_clear_watch_pipe or
something.  Since it doesn't always clear the watch pipe, it makes the
call sites confusing.

> @@ -855,14 +864,62 @@ char **xs_read_watch(struct xs_handle *h, unsigned int *num)
>  bool xs_unwatch(struct xs_handle *h, const char *path, const char *token)
>  {
>  	struct iovec iov[2];
> +	struct xs_stored_msg *msg, *tmsg;
> +	bool res;
> +	char *s, *p;
> +	unsigned int i;
> +	char *l_token, *l_path;
>  
>  	iov[0].iov_base = (char *)path;
>  	iov[0].iov_len = strlen(path) + 1;
>  	iov[1].iov_base = (char *)token;
>  	iov[1].iov_len = strlen(token) + 1;
>  
> -	return xs_bool(xs_talkv(h, XBT_NULL, XS_UNWATCH, iov,
> -				ARRAY_SIZE(iov), NULL));
> +	res = xs_bool(xs_talkv(h, XBT_NULL, XS_UNWATCH, iov,
> +						   ARRAY_SIZE(iov), NULL));
> +
> +	/* Filter the watch list to remove potential message */
> +	mutex_lock(&h->watch_mutex);
> +
> +	if (list_empty(&h->watch_list)) {
> +		mutex_unlock(&h->watch_mutex);
> +		return res;
> +	}

I still think this is redundant, so it should not be here.

> +	list_for_each_entry_safe(msg, tmsg, &h->watch_list, list) {
> +		assert(msg->hdr.type == XS_WATCH_EVENT);
> +
> +		s = msg->body;
> +
> +		l_token = NULL;
> +		l_path = NULL;
> +
> +		for (p = s, i = 0; p < msg->body + msg->hdr.len; p++) {
> +			if (*p == '\0')
> +			{
> +				if (i == XS_WATCH_TOKEN)
> +					l_token = s;
> +				else if (i == XS_WATCH_PATH)
> +					l_path = s;
> +				i++;
> +				s = p + 1;
> +			}
> +		}
> +
> +		if (l_token && !strcmp(token, l_token)
> +			/* Use strncmp because we can have a watch fired on sub-directory */

Oh bum.  I see a problem.  This is quite a bad problem.

It is legal to do this:

   client:

     XS_WATCH /foo token1
     XS_WATCH /foo/bar token1

Now if you get a watch event you get the token and the actual path.
So suppose we have, simultaneously:

   our client:                          another client:
     XS_UNWATCH /foo/bar token1          WRITE /foo/bar/zonk sponge

Then xenstored will generate two watch events:
                                WATCH_EVENT /foo/bar/zonk token1
                                WATCH_EVENT /foo/bar/zonk token1

With your patch, both of these would be thrown away.  Whereas in fact
one of them should still be presented.

How confident are we that there are no clients which rely on this not
changing ?

At the very least this needs a documentation patch explaining the
undesirable consequences of setting multiple watches with the same
token.  Arguably it needs a flag to the library (or a new function
name) to ask for this new behaviour.

I would have to think, for example, about whether the new libxl event
sub-library would make any mistakes as a result of this proposed
change.  I think it wouldn'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 Sep 26 15:14:37 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Sep 2012 15: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 1TGtJg-0003R9-8N; Wed, 26 Sep 2012 15:14:24 +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 1TGtJe-0003QZ-H4
	for xen-devel@lists.xensource.com; Wed, 26 Sep 2012 15:14:22 +0000
Received: from [85.158.143.35:21631] by server-3.bemta-4.messagelabs.com id
	B3/1C-10986-DCB13605; Wed, 26 Sep 2012 15:14:21 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1348672459!15278264!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzE2MjI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10787 invoked from network); 26 Sep 2012 15:14:21 -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;
	26 Sep 2012 15:14:21 -0000
X-IronPort-AV: E=Sophos;i="4.80,490,1344211200"; d="scan'208";a="39241131"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Sep 2012 15:14:19 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 26 Sep 2012 11:14:19 -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 1TGtJa-00071c-RZ;
	Wed, 26 Sep 2012 16:14:18 +0100
Message-ID: <50631AC1.1040000@eu.citrix.com>
Date: Wed, 26 Sep 2012 16:09:53 +0100
From: George Dunlap <george.dunlap@eu.citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120827 Thunderbird/15.0
MIME-Version: 1.0
To: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
References: <50576368.3070007@jhuapl.edu>
	<1347953926.25803.89.camel@dagon.hellion.org.uk>
	<5058B07C.1070404@jhuapl.edu>
	<1348566822.3452.151.camel@zakaz.uk.xensource.com>
	<5061D2CC.3030108@jhuapl.edu>
	<CAFLBxZYh69025_LHq2qWfQMotincb_pvDtCtiAa7sXCg-RQL6A@mail.gmail.com>
	<506313BD.7020600@jhuapl.edu>
In-Reply-To: <506313BD.7020600@jhuapl.edu>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH] Upgrade vtpmd to berlios version 0.7.4
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 26/09/12 15:39, Matthew Fioravante wrote:
> The last piece of this puzzle that I haven't figured out is the linux
> tpm frontend driver. Its not in the main linux tree. Its from the old
> 2006 vtpm code but it still works. I believe it shipped with the old xen
> 2.6.18 kernel but now I don't know whats happened to it. I still have a
> copy we have been porting to newer kernels internally.
>
> Should we try to get it in mainline linux? Or maybe provide it in the
> xen tree as an externally compilable kernel module?
>
> There also exists a linux tpm backend driver, but if were only going to
> support the domain model that is no longer needed and can go away.
We should absolutely get it into mainline Linux.  I presume it's mainly 
the front/back code, which would live in the xen/ tree, and then hooks 
to make it work with /dev/tpm?  It seems like that should be fairly 
straightforward to get upstream.

Re the backend driver: obviously you're going to be the one doing the 
work, so the final call will be up to you.  But it seems to me that if 
it's not too difficult (and from the docs I looked at, it seemed like 
not much more than a dumb pipe?), I think you might as well port it.  
That would make it easy to run vtpm and vtpmmgr in Linux stubdoms 
instead of a mini-os stubdoms, should it ever becomes necessary to do so 
(for instance, if the vtpm code ever requires more functionality than 
the mini-os libc has).

To upstream, I think the SOP is to rebase to the most recently released 
Linux kernel (3.6 now I think), and cross-post the patches to xen-devel 
and linux-kernel, CC'ing the Xen maintainer, Konrad Wilk 
<konrad.wilk@oracle.com>, and probably the TPM maintianer as well.  
(Correct me if I'm wrong, Konrad!)

  -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 26 15:14:37 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Sep 2012 15: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 1TGtJg-0003R9-8N; Wed, 26 Sep 2012 15:14:24 +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 1TGtJe-0003QZ-H4
	for xen-devel@lists.xensource.com; Wed, 26 Sep 2012 15:14:22 +0000
Received: from [85.158.143.35:21631] by server-3.bemta-4.messagelabs.com id
	B3/1C-10986-DCB13605; Wed, 26 Sep 2012 15:14:21 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1348672459!15278264!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzE2MjI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10787 invoked from network); 26 Sep 2012 15:14:21 -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;
	26 Sep 2012 15:14:21 -0000
X-IronPort-AV: E=Sophos;i="4.80,490,1344211200"; d="scan'208";a="39241131"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Sep 2012 15:14:19 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 26 Sep 2012 11:14:19 -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 1TGtJa-00071c-RZ;
	Wed, 26 Sep 2012 16:14:18 +0100
Message-ID: <50631AC1.1040000@eu.citrix.com>
Date: Wed, 26 Sep 2012 16:09:53 +0100
From: George Dunlap <george.dunlap@eu.citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120827 Thunderbird/15.0
MIME-Version: 1.0
To: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
References: <50576368.3070007@jhuapl.edu>
	<1347953926.25803.89.camel@dagon.hellion.org.uk>
	<5058B07C.1070404@jhuapl.edu>
	<1348566822.3452.151.camel@zakaz.uk.xensource.com>
	<5061D2CC.3030108@jhuapl.edu>
	<CAFLBxZYh69025_LHq2qWfQMotincb_pvDtCtiAa7sXCg-RQL6A@mail.gmail.com>
	<506313BD.7020600@jhuapl.edu>
In-Reply-To: <506313BD.7020600@jhuapl.edu>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH] Upgrade vtpmd to berlios version 0.7.4
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 26/09/12 15:39, Matthew Fioravante wrote:
> The last piece of this puzzle that I haven't figured out is the linux
> tpm frontend driver. Its not in the main linux tree. Its from the old
> 2006 vtpm code but it still works. I believe it shipped with the old xen
> 2.6.18 kernel but now I don't know whats happened to it. I still have a
> copy we have been porting to newer kernels internally.
>
> Should we try to get it in mainline linux? Or maybe provide it in the
> xen tree as an externally compilable kernel module?
>
> There also exists a linux tpm backend driver, but if were only going to
> support the domain model that is no longer needed and can go away.
We should absolutely get it into mainline Linux.  I presume it's mainly 
the front/back code, which would live in the xen/ tree, and then hooks 
to make it work with /dev/tpm?  It seems like that should be fairly 
straightforward to get upstream.

Re the backend driver: obviously you're going to be the one doing the 
work, so the final call will be up to you.  But it seems to me that if 
it's not too difficult (and from the docs I looked at, it seemed like 
not much more than a dumb pipe?), I think you might as well port it.  
That would make it easy to run vtpm and vtpmmgr in Linux stubdoms 
instead of a mini-os stubdoms, should it ever becomes necessary to do so 
(for instance, if the vtpm code ever requires more functionality than 
the mini-os libc has).

To upstream, I think the SOP is to rebase to the most recently released 
Linux kernel (3.6 now I think), and cross-post the patches to xen-devel 
and linux-kernel, CC'ing the Xen maintainer, Konrad Wilk 
<konrad.wilk@oracle.com>, and probably the TPM maintianer as well.  
(Correct me if I'm wrong, Konrad!)

  -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 26 15:21:54 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Sep 2012 15:21:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGtQi-0003i6-9R; Wed, 26 Sep 2012 15:21:40 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1TGtQh-0003i1-Kq
	for xen-devel@lists.xensource.com; Wed, 26 Sep 2012 15:21:39 +0000
Received: from [85.158.139.83:43374] by server-9.bemta-5.messagelabs.com id
	4B/CB-14846-28D13605; Wed, 26 Sep 2012 15:21:38 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1348672898!32228069!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTE1NzQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26361 invoked from network); 26 Sep 2012 15:21:38 -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 Sep 2012 15:21:38 -0000
X-IronPort-AV: E=Sophos;i="4.80,490,1344211200"; d="scan'208";a="14781971"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Sep 2012 15:21:37 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 26 Sep 2012 16:21:38 +0100
Message-ID: <1348672896.19176.54.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
Date: Wed, 26 Sep 2012 16:21:36 +0100
In-Reply-To: <506313BD.7020600@jhuapl.edu>
References: <50576368.3070007@jhuapl.edu>
	<1347953926.25803.89.camel@dagon.hellion.org.uk>
	<5058B07C.1070404@jhuapl.edu>
	<1348566822.3452.151.camel@zakaz.uk.xensource.com>
	<5061D2CC.3030108@jhuapl.edu>
	<CAFLBxZYh69025_LHq2qWfQMotincb_pvDtCtiAa7sXCg-RQL6A@mail.gmail.com>
	<506313BD.7020600@jhuapl.edu>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-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] [PATCH] Upgrade vtpmd to berlios version 0.7.4
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-09-26 at 15:39 +0100, Matthew Fioravante wrote:
> On 09/26/2012 07:46 AM, George Dunlap wrote:
> > On Tue, Sep 25, 2012 at 4:50 PM, Matthew Fioravante
> > <matthew.fioravante@jhuapl.edu> wrote:
> >> I don't know if there is anyone who would want to still use vtpms as
> >> processes when the stub domains are now available. Security research
> >> people like the domain model because it guarantees a better separation
> >> of components guaranteed by the hypervisor and doesn't have to trust the
> >> dom0 OS.
> >>
> >> If we got rid of the process and hybrid model, then the
> >> tools/vtpm_manager code that is still used could be moved into the
> >> vtpmmgrdom stubdom codebase. tools/vtpm could be completely removed
> >> along with the --enable-vtpm stuff in the configure script and the cmake
> >> dependency.
> > I haven't had a chance to look at your patches in detail (because the
> > few I've looked at have whitespace damage that Ian mentioned before),
> > but I as long as the user interface (via xl, config files, &c) is the
> > same, or comparable, I don't see any reason not to move entirely over
> > the stubdom model; especially if the process or hybrid models are not
> > being tested or maintained.
> It would also simplify the whole system quite a bit. If I am to maintain
> vtpm I'd like to not have to deal with bugs in the old code.
> 
> So how should we proceed with this then? Do you all want to remove the
> vtpm process/hybrid model entirely now or just deprecate it for a while?
> If we deprecate it do you still want my updates for it?

I'm happy for you to just remove the hybrid and process variants.

I think if anyone is really attached to those then it is up to them to
step up and maintain them, if someone does turn up then they can always
resurrect it from the VCS history and start from there.

> Let me know and I'll provide patches to make it happen either way.
> 
> The last piece of this puzzle that I haven't figured out is the linux
> tpm frontend driver. Its not in the main linux tree. Its from the old
> 2006 vtpm code but it still works. I believe it shipped with the old xen
> 2.6.18 kernel but now I don't know whats happened to it. I still have a
> copy we have been porting to newer kernels internally.
> 
> Should we try to get it in mainline linux?

This is the preferred approach.

> Or maybe provide it in the
> xen tree as an externally compilable kernel module?

We generally try and avoid that these days.

> There also exists a linux tpm backend driver, but if were only going to
> support the domain model that is no longer needed and can go away.

Indeed.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 26 15:21:54 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Sep 2012 15:21:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGtQi-0003i6-9R; Wed, 26 Sep 2012 15:21:40 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1TGtQh-0003i1-Kq
	for xen-devel@lists.xensource.com; Wed, 26 Sep 2012 15:21:39 +0000
Received: from [85.158.139.83:43374] by server-9.bemta-5.messagelabs.com id
	4B/CB-14846-28D13605; Wed, 26 Sep 2012 15:21:38 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1348672898!32228069!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTE1NzQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26361 invoked from network); 26 Sep 2012 15:21:38 -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 Sep 2012 15:21:38 -0000
X-IronPort-AV: E=Sophos;i="4.80,490,1344211200"; d="scan'208";a="14781971"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Sep 2012 15:21:37 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 26 Sep 2012 16:21:38 +0100
Message-ID: <1348672896.19176.54.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
Date: Wed, 26 Sep 2012 16:21:36 +0100
In-Reply-To: <506313BD.7020600@jhuapl.edu>
References: <50576368.3070007@jhuapl.edu>
	<1347953926.25803.89.camel@dagon.hellion.org.uk>
	<5058B07C.1070404@jhuapl.edu>
	<1348566822.3452.151.camel@zakaz.uk.xensource.com>
	<5061D2CC.3030108@jhuapl.edu>
	<CAFLBxZYh69025_LHq2qWfQMotincb_pvDtCtiAa7sXCg-RQL6A@mail.gmail.com>
	<506313BD.7020600@jhuapl.edu>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-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] [PATCH] Upgrade vtpmd to berlios version 0.7.4
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, 2012-09-26 at 15:39 +0100, Matthew Fioravante wrote:
> On 09/26/2012 07:46 AM, George Dunlap wrote:
> > On Tue, Sep 25, 2012 at 4:50 PM, Matthew Fioravante
> > <matthew.fioravante@jhuapl.edu> wrote:
> >> I don't know if there is anyone who would want to still use vtpms as
> >> processes when the stub domains are now available. Security research
> >> people like the domain model because it guarantees a better separation
> >> of components guaranteed by the hypervisor and doesn't have to trust the
> >> dom0 OS.
> >>
> >> If we got rid of the process and hybrid model, then the
> >> tools/vtpm_manager code that is still used could be moved into the
> >> vtpmmgrdom stubdom codebase. tools/vtpm could be completely removed
> >> along with the --enable-vtpm stuff in the configure script and the cmake
> >> dependency.
> > I haven't had a chance to look at your patches in detail (because the
> > few I've looked at have whitespace damage that Ian mentioned before),
> > but I as long as the user interface (via xl, config files, &c) is the
> > same, or comparable, I don't see any reason not to move entirely over
> > the stubdom model; especially if the process or hybrid models are not
> > being tested or maintained.
> It would also simplify the whole system quite a bit. If I am to maintain
> vtpm I'd like to not have to deal with bugs in the old code.
> 
> So how should we proceed with this then? Do you all want to remove the
> vtpm process/hybrid model entirely now or just deprecate it for a while?
> If we deprecate it do you still want my updates for it?

I'm happy for you to just remove the hybrid and process variants.

I think if anyone is really attached to those then it is up to them to
step up and maintain them, if someone does turn up then they can always
resurrect it from the VCS history and start from there.

> Let me know and I'll provide patches to make it happen either way.
> 
> The last piece of this puzzle that I haven't figured out is the linux
> tpm frontend driver. Its not in the main linux tree. Its from the old
> 2006 vtpm code but it still works. I believe it shipped with the old xen
> 2.6.18 kernel but now I don't know whats happened to it. I still have a
> copy we have been porting to newer kernels internally.
> 
> Should we try to get it in mainline linux?

This is the preferred approach.

> Or maybe provide it in the
> xen tree as an externally compilable kernel module?

We generally try and avoid that these days.

> There also exists a linux tpm backend driver, but if were only going to
> support the domain model that is no longer needed and can go away.

Indeed.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 26 15:21:55 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Sep 2012 15: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 1TGtQm-0003iQ-L8; Wed, 26 Sep 2012 15:21:44 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1TGtQl-0003iH-Ha
	for Xen-devel@lists.xensource.com; Wed, 26 Sep 2012 15:21:43 +0000
Received: from [85.158.139.83:43654] by server-8.bemta-5.messagelabs.com id
	03/41-18073-68D13605; Wed, 26 Sep 2012 15:21:42 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1348672898!32228069!2
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTE1NzQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26576 invoked from network); 26 Sep 2012 15:21:42 -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 Sep 2012 15:21:42 -0000
X-IronPort-AV: E=Sophos;i="4.80,490,1344211200"; d="scan'208";a="14781976"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Sep 2012 15:21: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.279.1;
	Wed, 26 Sep 2012 16:21:42 +0100
Message-ID: <1348672900.19176.55.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Wed, 26 Sep 2012 16:21:40 +0100
In-Reply-To: <20120926133736.GA9919@phenom.dumpdata.com>
References: <20120921121202.3163c379@mantra.us.oracle.com>
	<1348665924.19176.41.camel@zakaz.uk.xensource.com>
	<20120926133736.GA9919@phenom.dumpdata.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-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 v1 0/8]: PVH (PV guest with extensions)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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-09-26 at 14:37 +0100, Konrad Rzeszutek Wilk wrote:
> On Wed, Sep 26, 2012 at 02:25:24PM +0100, Ian Campbell wrote:
> > On Fri, 2012-09-21 at 20:12 +0100, Mukesh Rathor wrote:
> > > Hi guys,
> > > 
> > > Ok, I've made all the changes from prev RFC patch submission. Tested
> > > all the combinations. The patches are a bit smaller from before, and
> > > couldn't be separated like before, so I can't state whats different in
> > > each patch. But, it's not too bad to review now.
> > > 
> > > As before, they were built on top of
> > > fc6bdb59a501740b28ed3b616641a22c8dc5dd31 from the following tree:
> > >         
> > > git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
> > 
> > Is that correct? That's this commit:
> > 
> > commit fc6bdb59a501740b28ed3b616641a22c8dc5dd31
> > Merge: 44d82e2 1fcfd08
> > Author: Linus Torvalds <torvalds@linux-foundation.org>
> > Date:   Thu Aug 2 11:52:39 2012 -0700
> > 
> > Why so old? Makes it hard to take these for a spin due to the
> > rebasing...
> 
> I rebased them on top v3.6-rc6 (look in #linux-next-pvh)

I found this, thanks.

>  but I must
> have done something wrong b/c it won't boot as PVHVM. Time to do some git
> bisection and see where I failed.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 26 15:21:55 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Sep 2012 15: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 1TGtQm-0003iQ-L8; Wed, 26 Sep 2012 15:21:44 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1TGtQl-0003iH-Ha
	for Xen-devel@lists.xensource.com; Wed, 26 Sep 2012 15:21:43 +0000
Received: from [85.158.139.83:43654] by server-8.bemta-5.messagelabs.com id
	03/41-18073-68D13605; Wed, 26 Sep 2012 15:21:42 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1348672898!32228069!2
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTE1NzQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26576 invoked from network); 26 Sep 2012 15:21:42 -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 Sep 2012 15:21:42 -0000
X-IronPort-AV: E=Sophos;i="4.80,490,1344211200"; d="scan'208";a="14781976"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Sep 2012 15:21: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.279.1;
	Wed, 26 Sep 2012 16:21:42 +0100
Message-ID: <1348672900.19176.55.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Wed, 26 Sep 2012 16:21:40 +0100
In-Reply-To: <20120926133736.GA9919@phenom.dumpdata.com>
References: <20120921121202.3163c379@mantra.us.oracle.com>
	<1348665924.19176.41.camel@zakaz.uk.xensource.com>
	<20120926133736.GA9919@phenom.dumpdata.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-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 v1 0/8]: PVH (PV guest with extensions)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; 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-09-26 at 14:37 +0100, Konrad Rzeszutek Wilk wrote:
> On Wed, Sep 26, 2012 at 02:25:24PM +0100, Ian Campbell wrote:
> > On Fri, 2012-09-21 at 20:12 +0100, Mukesh Rathor wrote:
> > > Hi guys,
> > > 
> > > Ok, I've made all the changes from prev RFC patch submission. Tested
> > > all the combinations. The patches are a bit smaller from before, and
> > > couldn't be separated like before, so I can't state whats different in
> > > each patch. But, it's not too bad to review now.
> > > 
> > > As before, they were built on top of
> > > fc6bdb59a501740b28ed3b616641a22c8dc5dd31 from the following tree:
> > >         
> > > git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
> > 
> > Is that correct? That's this commit:
> > 
> > commit fc6bdb59a501740b28ed3b616641a22c8dc5dd31
> > Merge: 44d82e2 1fcfd08
> > Author: Linus Torvalds <torvalds@linux-foundation.org>
> > Date:   Thu Aug 2 11:52:39 2012 -0700
> > 
> > Why so old? Makes it hard to take these for a spin due to the
> > rebasing...
> 
> I rebased them on top v3.6-rc6 (look in #linux-next-pvh)

I found this, thanks.

>  but I must
> have done something wrong b/c it won't boot as PVHVM. Time to do some git
> bisection and see where I failed.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 26 15:50:19 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Sep 2012 15:50:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGts7-0004Jv-DM; Wed, 26 Sep 2012 15:49:59 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <grantmasterflash@gmail.com>) id 1TGto2-0004Ek-Tf
	for xen-devel@lists.xensource.com; Wed, 26 Sep 2012 15:45:47 +0000
Received: from [85.158.139.83:31466] by server-10.bemta-5.messagelabs.com id
	4E/91-16911-92323605; Wed, 26 Sep 2012 15:45:45 +0000
X-Env-Sender: grantmasterflash@gmail.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1348674343!32068392!1
X-Originating-IP: [209.85.212.43]
X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_20_30,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22126 invoked from network); 26 Sep 2012 15:45:44 -0000
Received: from mail-vb0-f43.google.com (HELO mail-vb0-f43.google.com)
	(209.85.212.43)
	by server-12.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Sep 2012 15:45:44 -0000
Received: by vbbfq11 with SMTP id fq11so1009562vbb.30
	for <multiple recipients>; Wed, 26 Sep 2012 08:45:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to
	:cc:content-type;
	bh=yR4Kd5/DynHVPFA1L4KG5VUnIWZNLO2e2ZpnGcnsna4=;
	b=R5YUJxg1oPiOZTGZ3cpJUc+HDJBzjR1mfCxXl+hPpMUlquEYlqBKTXwIVlUrhVuHBH
	xeD9aLKArsG2/IzIcyxN0+hI+JD1WC3uMG+OLEV84pr/2q0w/JPM0+2/VDt0sAnwN0AR
	RPn9jxEbIYPK+eBV1samWeUzmkzI7DE3k/+G6BIRYL2RxFztXhdIYrxXjGj0YDytZsk4
	e10uYJcF9gUiM/Aq3xGdUV8gcoah6ECFuuakJeY9C3Rq2svP8tfeKSRA3toAJHdOAcNM
	YDNzOYXQVuyizBckWlyPIw/jHEWl9HjRWLMR7n2jvWw+1GFZ/qdxER4CTpVM18OMqZdh
	TPag==
Received: by 10.52.175.130 with SMTP id ca2mr393300vdc.112.1348674342953; Wed,
	26 Sep 2012 08:45:42 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.58.133.133 with HTTP; Wed, 26 Sep 2012 08:45:02 -0700 (PDT)
In-Reply-To: <1348588898.12592.16.camel@zakaz.uk.xensource.com>
References: <CAGnmK4wB3ZJ3Tb9-VFgWCkcZNwibDzRYV8tvb14vLgw1wj2awQ@mail.gmail.com>
	<50607A68.2090604@xen.org>
	<1348561354.3452.105.camel@zakaz.uk.xensource.com>
	<2D15A521-63E8-4CE7-8D42-62A67FBD75B2@recoil.org>
	<1348583438.11229.23.camel@zakaz.uk.xensource.com>
	<5061D362.8070402@xen.org>
	<1348588898.12592.16.camel@zakaz.uk.xensource.com>
From: Grant McWilliams <grantmasterflash@gmail.com>
Date: Wed, 26 Sep 2012 08:45:02 -0700
Message-ID: <CAGnmK4xZg5_rPwSqXB_j6BFi8QkOj3OO4s7UBpXNgyper84Mdw@mail.gmail.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
X-Mailman-Approved-At: Wed, 26 Sep 2012 15:49:58 +0000
Cc: "lars.kurth@xen.org" <lars.kurth@xen.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"xen-api@lists.xensource.com" <xen-api@lists.xensource.com>
Subject: Re: [Xen-devel] [Xen-API]  Proposal - Add xe manpages to xen-org
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1755999101193448697=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============1755999101193448697==
Content-Type: multipart/alternative; boundary=bcaec5014c1d21224004ca9cb7da

--bcaec5014c1d21224004ca9cb7da
Content-Type: text/plain; charset=UTF-8

On Tue, Sep 25, 2012 at 9:01 AM, Ian Campbell <Ian.Campbell@citrix.com>wrote:
>
> That may all be true. But I was talking about about the docs which Grant
> has produced, which he said were in asciidoc.
>
> > > I agree that actually in the source is even better than next to the
> > > source, if it's an option...
> > >
> > >> Manually keeping the zillion commands in sync will be quite the
> ongoing
> > >> effort.
> > > Someone still needs to write/update the text regardless of where it
> > > lives, but that's as much a code review thing as anything else.
> > >
> > I wouldn't want to create a barrier for Grant's students (or other
> > people that want to contribute). Remember that most are not developers
> > but users of XCP.  Embedding the documentation into the code would mean:
> > a) existing document source code would need to be refactored
> > b) it would create a psychological barrier to contribute
> > c) possibly unnecessary process
> >
> > Keeping the documentation separate (either in a separate repo, or
> > directory in an existing repo) is probably the easiest and quickest way
> > to get this project off the ground quickly.
>
> In which case I would suggest a directory of the existing xen-api repo
> and not a completely separate one.
>

I agree a directory within xen-api would be great.


> BTW, I wasn't suggesting that people contributing docs needed to become
> code contributors too. Only the inverse which is that people changing
> the code should be expect to simultaneously update any docs relevant to
> their change. Obviously it is also fine to improve the docs without
> changing the code.
>
> Ian.
>

The way I see it is we can create documentation for the xe help command
in source code the way it's done now (I'm guessing) and export that to man
pages or we can go the other way around.

The way I'd envisioned this is we create the ALL documentation in asciidoc
which gets transformed into Docbook. From Docbook
we can use XSLT to make anything we want including Admin Guide, manpages
and xe help. We can export only the sections we need and in the format
we need so for xe help we could include only NAME, SYNOPSIS and DESCRIPTION
whereas for manpages we'd include all sections etc... I'd need to know more
about how the current xe help is created to know if we could transform to
that. This way
it keeps the documentation people writing in a publishing system they know
and the coders could either jump over to xen-api github
and update the docs when needed or they could ping the people maintaining
them.

This is all theory of course.

Grant McWilliams

--bcaec5014c1d21224004ca9cb7da
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div class=3D"gmail_quote">On Tue, Sep 25, 2012 at 9:01 AM, Ian Campbell <s=
pan dir=3D"ltr">&lt;<a href=3D"mailto:Ian.Campbell@citrix.com" target=3D"_b=
lank">Ian.Campbell@citrix.com</a>&gt;</span> wrote:<blockquote class=3D"gma=
il_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-lef=
t:1ex">

That may all be true. But I was talking about about the docs which Grant<br=
>
has produced, which he said were in asciidoc.<br>
<div class=3D"im"><br>
&gt; &gt; I agree that actually in the source is even better than next to t=
he<br>
&gt; &gt; source, if it&#39;s an option...<br>
&gt; &gt;<br>
&gt; &gt;&gt; Manually keeping the zillion commands in sync will be quite t=
he ongoing<br>
&gt; &gt;&gt; effort.<br>
&gt; &gt; Someone still needs to write/update the text regardless of where =
it<br>
&gt; &gt; lives, but that&#39;s as much a code review thing as anything els=
e.<br>
&gt; &gt;<br>
&gt; I wouldn&#39;t want to create a barrier for Grant&#39;s students (or o=
ther<br>
&gt; people that want to contribute). Remember that most are not developers=
<br>
&gt; but users of XCP. =C2=A0Embedding the documentation into the code woul=
d mean:<br>
&gt; a) existing document source code would need to be refactored<br>
&gt; b) it would create a psychological barrier to contribute<br>
&gt; c) possibly unnecessary process<br>
&gt;<br>
&gt; Keeping the documentation separate (either in a separate repo, or<br>
&gt; directory in an existing repo) is probably the easiest and quickest wa=
y<br>
&gt; to get this project off the ground quickly.<br>
<br>
</div>In which case I would suggest a directory of the existing xen-api rep=
o<br>
and not a completely separate one.<br></blockquote><div><br></div><div>I ag=
ree a directory within xen-api would be great.=C2=A0</div><div>=C2=A0</div>=
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">


BTW, I wasn&#39;t suggesting that people contributing docs needed to become=
<br>
code contributors too. Only the inverse which is that people changing<br>
the code should be expect to simultaneously update any docs relevant to<br>
their change. Obviously it is also fine to improve the docs without<br>
changing the code.<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
Ian.<br></font></span></blockquote><div><br></div><div>The way I see it is =
we can create documentation for the xe help command</div><div>in source cod=
e the way it&#39;s done now (I&#39;m guessing) and export that to man pages=
 or we can go the other way around.</div>

<div><br></div><div>The way I&#39;d envisioned this is we create the ALL do=
cumentation in asciidoc which gets transformed into Docbook. From Docbook</=
div><div>we can use XSLT to make anything we want including Admin Guide, ma=
npages and xe help. We can export only the sections we need and in the form=
at we=C2=A0need so for xe help we could include only NAME, SYNOPSIS and DES=
CRIPTION whereas for manpages we&#39;d include all=C2=A0sections etc... I&#=
39;d need to know more about how the current xe help is created to know if =
we could transform to that. This way</div>

<div>it keeps the=C2=A0documentation people writing in a publishing system =
they know and the coders could either jump over to xen-api github</div><div=
>and update the docs when needed or they could ping the people maintaining =
them.</div>

<div><br></div><div>This is all theory of course.</div><div><br></div><div>=
Grant McWilliams</div></div><br>

--bcaec5014c1d21224004ca9cb7da--


--===============1755999101193448697==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============1755999101193448697==--


From xen-devel-bounces@lists.xen.org Wed Sep 26 15:50:19 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Sep 2012 15:50:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGts7-0004Jv-DM; Wed, 26 Sep 2012 15:49:59 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <grantmasterflash@gmail.com>) id 1TGto2-0004Ek-Tf
	for xen-devel@lists.xensource.com; Wed, 26 Sep 2012 15:45:47 +0000
Received: from [85.158.139.83:31466] by server-10.bemta-5.messagelabs.com id
	4E/91-16911-92323605; Wed, 26 Sep 2012 15:45:45 +0000
X-Env-Sender: grantmasterflash@gmail.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1348674343!32068392!1
X-Originating-IP: [209.85.212.43]
X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_20_30,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22126 invoked from network); 26 Sep 2012 15:45:44 -0000
Received: from mail-vb0-f43.google.com (HELO mail-vb0-f43.google.com)
	(209.85.212.43)
	by server-12.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Sep 2012 15:45:44 -0000
Received: by vbbfq11 with SMTP id fq11so1009562vbb.30
	for <multiple recipients>; Wed, 26 Sep 2012 08:45:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to
	:cc:content-type;
	bh=yR4Kd5/DynHVPFA1L4KG5VUnIWZNLO2e2ZpnGcnsna4=;
	b=R5YUJxg1oPiOZTGZ3cpJUc+HDJBzjR1mfCxXl+hPpMUlquEYlqBKTXwIVlUrhVuHBH
	xeD9aLKArsG2/IzIcyxN0+hI+JD1WC3uMG+OLEV84pr/2q0w/JPM0+2/VDt0sAnwN0AR
	RPn9jxEbIYPK+eBV1samWeUzmkzI7DE3k/+G6BIRYL2RxFztXhdIYrxXjGj0YDytZsk4
	e10uYJcF9gUiM/Aq3xGdUV8gcoah6ECFuuakJeY9C3Rq2svP8tfeKSRA3toAJHdOAcNM
	YDNzOYXQVuyizBckWlyPIw/jHEWl9HjRWLMR7n2jvWw+1GFZ/qdxER4CTpVM18OMqZdh
	TPag==
Received: by 10.52.175.130 with SMTP id ca2mr393300vdc.112.1348674342953; Wed,
	26 Sep 2012 08:45:42 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.58.133.133 with HTTP; Wed, 26 Sep 2012 08:45:02 -0700 (PDT)
In-Reply-To: <1348588898.12592.16.camel@zakaz.uk.xensource.com>
References: <CAGnmK4wB3ZJ3Tb9-VFgWCkcZNwibDzRYV8tvb14vLgw1wj2awQ@mail.gmail.com>
	<50607A68.2090604@xen.org>
	<1348561354.3452.105.camel@zakaz.uk.xensource.com>
	<2D15A521-63E8-4CE7-8D42-62A67FBD75B2@recoil.org>
	<1348583438.11229.23.camel@zakaz.uk.xensource.com>
	<5061D362.8070402@xen.org>
	<1348588898.12592.16.camel@zakaz.uk.xensource.com>
From: Grant McWilliams <grantmasterflash@gmail.com>
Date: Wed, 26 Sep 2012 08:45:02 -0700
Message-ID: <CAGnmK4xZg5_rPwSqXB_j6BFi8QkOj3OO4s7UBpXNgyper84Mdw@mail.gmail.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
X-Mailman-Approved-At: Wed, 26 Sep 2012 15:49:58 +0000
Cc: "lars.kurth@xen.org" <lars.kurth@xen.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"xen-api@lists.xensource.com" <xen-api@lists.xensource.com>
Subject: Re: [Xen-devel] [Xen-API]  Proposal - Add xe manpages to xen-org
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1755999101193448697=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============1755999101193448697==
Content-Type: multipart/alternative; boundary=bcaec5014c1d21224004ca9cb7da

--bcaec5014c1d21224004ca9cb7da
Content-Type: text/plain; charset=UTF-8

On Tue, Sep 25, 2012 at 9:01 AM, Ian Campbell <Ian.Campbell@citrix.com>wrote:
>
> That may all be true. But I was talking about about the docs which Grant
> has produced, which he said were in asciidoc.
>
> > > I agree that actually in the source is even better than next to the
> > > source, if it's an option...
> > >
> > >> Manually keeping the zillion commands in sync will be quite the
> ongoing
> > >> effort.
> > > Someone still needs to write/update the text regardless of where it
> > > lives, but that's as much a code review thing as anything else.
> > >
> > I wouldn't want to create a barrier for Grant's students (or other
> > people that want to contribute). Remember that most are not developers
> > but users of XCP.  Embedding the documentation into the code would mean:
> > a) existing document source code would need to be refactored
> > b) it would create a psychological barrier to contribute
> > c) possibly unnecessary process
> >
> > Keeping the documentation separate (either in a separate repo, or
> > directory in an existing repo) is probably the easiest and quickest way
> > to get this project off the ground quickly.
>
> In which case I would suggest a directory of the existing xen-api repo
> and not a completely separate one.
>

I agree a directory within xen-api would be great.


> BTW, I wasn't suggesting that people contributing docs needed to become
> code contributors too. Only the inverse which is that people changing
> the code should be expect to simultaneously update any docs relevant to
> their change. Obviously it is also fine to improve the docs without
> changing the code.
>
> Ian.
>

The way I see it is we can create documentation for the xe help command
in source code the way it's done now (I'm guessing) and export that to man
pages or we can go the other way around.

The way I'd envisioned this is we create the ALL documentation in asciidoc
which gets transformed into Docbook. From Docbook
we can use XSLT to make anything we want including Admin Guide, manpages
and xe help. We can export only the sections we need and in the format
we need so for xe help we could include only NAME, SYNOPSIS and DESCRIPTION
whereas for manpages we'd include all sections etc... I'd need to know more
about how the current xe help is created to know if we could transform to
that. This way
it keeps the documentation people writing in a publishing system they know
and the coders could either jump over to xen-api github
and update the docs when needed or they could ping the people maintaining
them.

This is all theory of course.

Grant McWilliams

--bcaec5014c1d21224004ca9cb7da
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div class=3D"gmail_quote">On Tue, Sep 25, 2012 at 9:01 AM, Ian Campbell <s=
pan dir=3D"ltr">&lt;<a href=3D"mailto:Ian.Campbell@citrix.com" target=3D"_b=
lank">Ian.Campbell@citrix.com</a>&gt;</span> wrote:<blockquote class=3D"gma=
il_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-lef=
t:1ex">

That may all be true. But I was talking about about the docs which Grant<br=
>
has produced, which he said were in asciidoc.<br>
<div class=3D"im"><br>
&gt; &gt; I agree that actually in the source is even better than next to t=
he<br>
&gt; &gt; source, if it&#39;s an option...<br>
&gt; &gt;<br>
&gt; &gt;&gt; Manually keeping the zillion commands in sync will be quite t=
he ongoing<br>
&gt; &gt;&gt; effort.<br>
&gt; &gt; Someone still needs to write/update the text regardless of where =
it<br>
&gt; &gt; lives, but that&#39;s as much a code review thing as anything els=
e.<br>
&gt; &gt;<br>
&gt; I wouldn&#39;t want to create a barrier for Grant&#39;s students (or o=
ther<br>
&gt; people that want to contribute). Remember that most are not developers=
<br>
&gt; but users of XCP. =C2=A0Embedding the documentation into the code woul=
d mean:<br>
&gt; a) existing document source code would need to be refactored<br>
&gt; b) it would create a psychological barrier to contribute<br>
&gt; c) possibly unnecessary process<br>
&gt;<br>
&gt; Keeping the documentation separate (either in a separate repo, or<br>
&gt; directory in an existing repo) is probably the easiest and quickest wa=
y<br>
&gt; to get this project off the ground quickly.<br>
<br>
</div>In which case I would suggest a directory of the existing xen-api rep=
o<br>
and not a completely separate one.<br></blockquote><div><br></div><div>I ag=
ree a directory within xen-api would be great.=C2=A0</div><div>=C2=A0</div>=
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">


BTW, I wasn&#39;t suggesting that people contributing docs needed to become=
<br>
code contributors too. Only the inverse which is that people changing<br>
the code should be expect to simultaneously update any docs relevant to<br>
their change. Obviously it is also fine to improve the docs without<br>
changing the code.<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
Ian.<br></font></span></blockquote><div><br></div><div>The way I see it is =
we can create documentation for the xe help command</div><div>in source cod=
e the way it&#39;s done now (I&#39;m guessing) and export that to man pages=
 or we can go the other way around.</div>

<div><br></div><div>The way I&#39;d envisioned this is we create the ALL do=
cumentation in asciidoc which gets transformed into Docbook. From Docbook</=
div><div>we can use XSLT to make anything we want including Admin Guide, ma=
npages and xe help. We can export only the sections we need and in the form=
at we=C2=A0need so for xe help we could include only NAME, SYNOPSIS and DES=
CRIPTION whereas for manpages we&#39;d include all=C2=A0sections etc... I&#=
39;d need to know more about how the current xe help is created to know if =
we could transform to that. This way</div>

<div>it keeps the=C2=A0documentation people writing in a publishing system =
they know and the coders could either jump over to xen-api github</div><div=
>and update the docs when needed or they could ping the people maintaining =
them.</div>

<div><br></div><div>This is all theory of course.</div><div><br></div><div>=
Grant McWilliams</div></div><br>

--bcaec5014c1d21224004ca9cb7da--


--===============1755999101193448697==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============1755999101193448697==--


From xen-devel-bounces@lists.xen.org Wed Sep 26 16:00:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Sep 2012 16:00:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGu1X-0004TR-GI; Wed, 26 Sep 2012 15:59:43 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <matthew.fioravante@jhuapl.edu>) id 1TGu1V-0004TM-GL
	for xen-devel@lists.xensource.com; Wed, 26 Sep 2012 15:59:41 +0000
Received: from [85.158.143.35:43433] by server-2.bemta-4.messagelabs.com id
	73/DB-06610-C6623605; Wed, 26 Sep 2012 15:59:40 +0000
X-Env-Sender: matthew.fioravante@jhuapl.edu
X-Msg-Ref: server-9.tower-21.messagelabs.com!1348675177!5233371!1
X-Originating-IP: [128.244.251.36]
X-SpamReason: No, hits=0.0 required=7.0 tests=UNPARSEABLE_RELAY
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23084 invoked from network); 26 Sep 2012 15:59:38 -0000
Received: from pilot.jhuapl.edu (HELO jhuapl.edu) (128.244.251.36)
	by server-9.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 26 Sep 2012 15:59:38 -0000
Received: from ([128.244.207.89])
	by pilot.jhuapl.edu with ESMTP with TLS id 63GHCH1.153706012;
	Wed, 26 Sep 2012 11:59:27 -0400
Message-ID: <50632610.2070709@jhuapl.edu>
Date: Wed, 26 Sep 2012 11:58:08 -0400
From: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120827 Thunderbird/15.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <50576368.3070007@jhuapl.edu>
	<1347953926.25803.89.camel@dagon.hellion.org.uk>
	<5058B07C.1070404@jhuapl.edu>
	<1348566822.3452.151.camel@zakaz.uk.xensource.com>
	<5061D2CC.3030108@jhuapl.edu>
	<CAFLBxZYh69025_LHq2qWfQMotincb_pvDtCtiAa7sXCg-RQL6A@mail.gmail.com>
	<506313BD.7020600@jhuapl.edu>
	<1348672896.19176.54.camel@zakaz.uk.xensource.com>
In-Reply-To: <1348672896.19176.54.camel@zakaz.uk.xensource.com>
X-Enigmail-Version: 1.4.4
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] Upgrade vtpmd to berlios version 0.7.4
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============4660389707984739233=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a cryptographically signed message in MIME format.

--===============4660389707984739233==
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms080806010300010705070902"

This is a cryptographically signed message in MIME format.

--------------ms080806010300010705070902
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 09/26/2012 11:21 AM, Ian Campbell wrote:
> On Wed, 2012-09-26 at 15:39 +0100, Matthew Fioravante wrote:
>> On 09/26/2012 07:46 AM, George Dunlap wrote:
>>> On Tue, Sep 25, 2012 at 4:50 PM, Matthew Fioravante
>>> <matthew.fioravante@jhuapl.edu> wrote:
>>>> I don't know if there is anyone who would want to still use vtpms as=

>>>> processes when the stub domains are now available. Security research=

>>>> people like the domain model because it guarantees a better separati=
on
>>>> of components guaranteed by the hypervisor and doesn't have to trust=
 the
>>>> dom0 OS.
>>>>
>>>> If we got rid of the process and hybrid model, then the
>>>> tools/vtpm_manager code that is still used could be moved into the
>>>> vtpmmgrdom stubdom codebase. tools/vtpm could be completely removed
>>>> along with the --enable-vtpm stuff in the configure script and the c=
make
>>>> dependency.
>>> I haven't had a chance to look at your patches in detail (because the=

>>> few I've looked at have whitespace damage that Ian mentioned before),=

>>> but I as long as the user interface (via xl, config files, &c) is the=

>>> same, or comparable, I don't see any reason not to move entirely over=

>>> the stubdom model; especially if the process or hybrid models are not=

>>> being tested or maintained.
>> It would also simplify the whole system quite a bit. If I am to mainta=
in
>> vtpm I'd like to not have to deal with bugs in the old code.
>>
>> So how should we proceed with this then? Do you all want to remove the=

>> vtpm process/hybrid model entirely now or just deprecate it for a whil=
e?
>> If we deprecate it do you still want my updates for it?
> I'm happy for you to just remove the hybrid and process variants.
>
> I think if anyone is really attached to those then it is up to them to
> step up and maintain them, if someone does turn up then they can always=

> resurrect it from the VCS history and start from there.
Ok then in that case, ignore the vtpmd and vtpm_manager patches I sent
before. The only ones that are not applicable are the mini-os patches
and the libxl patches. The stubdoms are coming soon. I'd like to rework
them so that the vtpm_manager code is just included directly into
vtpmmgrdom.
>> Let me know and I'll provide patches to make it happen either way.
>>
>> The last piece of this puzzle that I haven't figured out is the linux
>> tpm frontend driver. Its not in the main linux tree. Its from the old
>> 2006 vtpm code but it still works. I believe it shipped with the old x=
en
>> 2.6.18 kernel but now I don't know whats happened to it. I still have =
a
>> copy we have been porting to newer kernels internally.
>>
>> Should we try to get it in mainline linux?
> This is the preferred approach.
>
>> Or maybe provide it in the
>> xen tree as an externally compilable kernel module?
> We generally try and avoid that these days.
>
>> There also exists a linux tpm backend driver, but if were only going t=
o
>> support the domain model that is no longer needed and can go away.
> Indeed.
>
> Ian.
>



--------------ms080806010300010705070902
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIDyjCC
A8YwggMvoAMCAQICBD/xyf0wDQYJKoZIhvcNAQEFBQAwLzELMAkGA1UEBhMCVVMxDzANBgNV
BAoTBkpIVUFQTDEPMA0GA1UECxMGQklTRENBMB4XDTEwMDYxMTE4MjIwNloXDTEzMDYxMTE4
NTIwNlowZjELMAkGA1UEBhMCVVMxDzANBgNVBAoTBkpIVUFQTDEPMA0GA1UECxMGUGVvcGxl
MTUwFgYDVQQLEw9WUE5Hcm91cC1CSVNEQ0EwGwYDVQQDExRNYXR0aGV3IEUgRmlvcmF2YW50
ZTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAnpbwVSP6o1Nb5lcW7dd3yTo9iBJdi7qz
4nANOMFPK7JOy5npKN1iiousl28U/scUJES55gPwAWYJK3uVyQAsA4adgDKi5DoD1UHDQEwp
bY7iHLJeq0NPr4BqYNqnCFPbE6HC8zSJrr4qKn+gVUQT39SIFqdiIPJwZL8FYTRQ/zsCAwEA
AaOCAbYwggGyMAsGA1UdDwQEAwIHgDArBgNVHRAEJDAigA8yMDEwMDYxMTE4MjIwNlqBDzIw
MTIwNzE3MjI1MjA2WjAbBg0rBgEEAbMlCwMBAQEBBAoWCGZpb3JhbWUxMBsGDSsGAQQBsyUL
AwEBAQIEChIIMDAxMDQyNjEwWAYJYIZIAYb6ax4BBEsMSVRoZSBwcml2YXRlIGtleSBjb3Jy
ZXNwb25kaW5nIHRvIHRoaXMgY2VydGlmaWNhdGUgbWF5IGhhdmUgYmVlbiBleHBvcnRlZC4w
KAYDVR0RBCEwH4EdTWF0dGhldy5GaW9yYXZhbnRlQGpodWFwbC5lZHUwUgYDVR0fBEswSTBH
oEWgQ6RBMD8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJU0RD
QTEOMAwGA1UEAxMFQ1JMNTYwHwYDVR0jBBgwFoAUCDUpmxH52EU2CyWmF2EJMB1yqeswHQYD
VR0OBBYEFO6LYxg6r9wHZ+zdQtBHn1dZ/YTNMAkGA1UdEwQCMAAwGQYJKoZIhvZ9B0EABAww
ChsEVjcuMQMCBLAwDQYJKoZIhvcNAQEFBQADgYEAJO9HQh4YNChVLzuZqK5ARJARD8JoujGZ
fdo75quvg2jXFQe2sEjvLnxJZgm/pv8fdZakq48CWwjYHKuvIp7sDjTEsQfo+y7SpN/N2NvJ
WU5SqfK1VgYtNLRRoGJUB5Q1aZ+Dg95g3kqpyfpUMISJL8IKVLtJVfN4fggFVUYZ9wwxggGr
MIIBpwIBATA3MC8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJ
U0RDQQIEP/HJ/TAJBgUrDgMCGgUAoIHLMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ
KoZIhvcNAQkFMQ8XDTEyMDkyNjE1NTgwOFowIwYJKoZIhvcNAQkEMRYEFIHcL3PmTkYCSQdV
i/cw/2XZzSGFMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAK
BggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI
KoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEgYBPPlkJaJuqw9KMxuGr4WN6eSrgJd9o1AIn
VUUM54WUViH58eN2bjVCaxY/QPAL00l3eg/m784iHqyExYPWwpmaWz/T7602xmOxaBcFA7SH
wLu1Kbq0hZWbG8g0ybHJz+IJPV/t80nsOgoibrnyBSs2Bi6E+hBS+Fqp7WaKdyKF3QAAAAAA
AA==
--------------ms080806010300010705070902--


--===============4660389707984739233==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============4660389707984739233==--


From xen-devel-bounces@lists.xen.org Wed Sep 26 16:00:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Sep 2012 16:00:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGu1X-0004TR-GI; Wed, 26 Sep 2012 15:59:43 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <matthew.fioravante@jhuapl.edu>) id 1TGu1V-0004TM-GL
	for xen-devel@lists.xensource.com; Wed, 26 Sep 2012 15:59:41 +0000
Received: from [85.158.143.35:43433] by server-2.bemta-4.messagelabs.com id
	73/DB-06610-C6623605; Wed, 26 Sep 2012 15:59:40 +0000
X-Env-Sender: matthew.fioravante@jhuapl.edu
X-Msg-Ref: server-9.tower-21.messagelabs.com!1348675177!5233371!1
X-Originating-IP: [128.244.251.36]
X-SpamReason: No, hits=0.0 required=7.0 tests=UNPARSEABLE_RELAY
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23084 invoked from network); 26 Sep 2012 15:59:38 -0000
Received: from pilot.jhuapl.edu (HELO jhuapl.edu) (128.244.251.36)
	by server-9.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 26 Sep 2012 15:59:38 -0000
Received: from ([128.244.207.89])
	by pilot.jhuapl.edu with ESMTP with TLS id 63GHCH1.153706012;
	Wed, 26 Sep 2012 11:59:27 -0400
Message-ID: <50632610.2070709@jhuapl.edu>
Date: Wed, 26 Sep 2012 11:58:08 -0400
From: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120827 Thunderbird/15.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <50576368.3070007@jhuapl.edu>
	<1347953926.25803.89.camel@dagon.hellion.org.uk>
	<5058B07C.1070404@jhuapl.edu>
	<1348566822.3452.151.camel@zakaz.uk.xensource.com>
	<5061D2CC.3030108@jhuapl.edu>
	<CAFLBxZYh69025_LHq2qWfQMotincb_pvDtCtiAa7sXCg-RQL6A@mail.gmail.com>
	<506313BD.7020600@jhuapl.edu>
	<1348672896.19176.54.camel@zakaz.uk.xensource.com>
In-Reply-To: <1348672896.19176.54.camel@zakaz.uk.xensource.com>
X-Enigmail-Version: 1.4.4
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] Upgrade vtpmd to berlios version 0.7.4
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============4660389707984739233=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a cryptographically signed message in MIME format.

--===============4660389707984739233==
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms080806010300010705070902"

This is a cryptographically signed message in MIME format.

--------------ms080806010300010705070902
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 09/26/2012 11:21 AM, Ian Campbell wrote:
> On Wed, 2012-09-26 at 15:39 +0100, Matthew Fioravante wrote:
>> On 09/26/2012 07:46 AM, George Dunlap wrote:
>>> On Tue, Sep 25, 2012 at 4:50 PM, Matthew Fioravante
>>> <matthew.fioravante@jhuapl.edu> wrote:
>>>> I don't know if there is anyone who would want to still use vtpms as=

>>>> processes when the stub domains are now available. Security research=

>>>> people like the domain model because it guarantees a better separati=
on
>>>> of components guaranteed by the hypervisor and doesn't have to trust=
 the
>>>> dom0 OS.
>>>>
>>>> If we got rid of the process and hybrid model, then the
>>>> tools/vtpm_manager code that is still used could be moved into the
>>>> vtpmmgrdom stubdom codebase. tools/vtpm could be completely removed
>>>> along with the --enable-vtpm stuff in the configure script and the c=
make
>>>> dependency.
>>> I haven't had a chance to look at your patches in detail (because the=

>>> few I've looked at have whitespace damage that Ian mentioned before),=

>>> but I as long as the user interface (via xl, config files, &c) is the=

>>> same, or comparable, I don't see any reason not to move entirely over=

>>> the stubdom model; especially if the process or hybrid models are not=

>>> being tested or maintained.
>> It would also simplify the whole system quite a bit. If I am to mainta=
in
>> vtpm I'd like to not have to deal with bugs in the old code.
>>
>> So how should we proceed with this then? Do you all want to remove the=

>> vtpm process/hybrid model entirely now or just deprecate it for a whil=
e?
>> If we deprecate it do you still want my updates for it?
> I'm happy for you to just remove the hybrid and process variants.
>
> I think if anyone is really attached to those then it is up to them to
> step up and maintain them, if someone does turn up then they can always=

> resurrect it from the VCS history and start from there.
Ok then in that case, ignore the vtpmd and vtpm_manager patches I sent
before. The only ones that are not applicable are the mini-os patches
and the libxl patches. The stubdoms are coming soon. I'd like to rework
them so that the vtpm_manager code is just included directly into
vtpmmgrdom.
>> Let me know and I'll provide patches to make it happen either way.
>>
>> The last piece of this puzzle that I haven't figured out is the linux
>> tpm frontend driver. Its not in the main linux tree. Its from the old
>> 2006 vtpm code but it still works. I believe it shipped with the old x=
en
>> 2.6.18 kernel but now I don't know whats happened to it. I still have =
a
>> copy we have been porting to newer kernels internally.
>>
>> Should we try to get it in mainline linux?
> This is the preferred approach.
>
>> Or maybe provide it in the
>> xen tree as an externally compilable kernel module?
> We generally try and avoid that these days.
>
>> There also exists a linux tpm backend driver, but if were only going t=
o
>> support the domain model that is no longer needed and can go away.
> Indeed.
>
> Ian.
>



--------------ms080806010300010705070902
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIDyjCC
A8YwggMvoAMCAQICBD/xyf0wDQYJKoZIhvcNAQEFBQAwLzELMAkGA1UEBhMCVVMxDzANBgNV
BAoTBkpIVUFQTDEPMA0GA1UECxMGQklTRENBMB4XDTEwMDYxMTE4MjIwNloXDTEzMDYxMTE4
NTIwNlowZjELMAkGA1UEBhMCVVMxDzANBgNVBAoTBkpIVUFQTDEPMA0GA1UECxMGUGVvcGxl
MTUwFgYDVQQLEw9WUE5Hcm91cC1CSVNEQ0EwGwYDVQQDExRNYXR0aGV3IEUgRmlvcmF2YW50
ZTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAnpbwVSP6o1Nb5lcW7dd3yTo9iBJdi7qz
4nANOMFPK7JOy5npKN1iiousl28U/scUJES55gPwAWYJK3uVyQAsA4adgDKi5DoD1UHDQEwp
bY7iHLJeq0NPr4BqYNqnCFPbE6HC8zSJrr4qKn+gVUQT39SIFqdiIPJwZL8FYTRQ/zsCAwEA
AaOCAbYwggGyMAsGA1UdDwQEAwIHgDArBgNVHRAEJDAigA8yMDEwMDYxMTE4MjIwNlqBDzIw
MTIwNzE3MjI1MjA2WjAbBg0rBgEEAbMlCwMBAQEBBAoWCGZpb3JhbWUxMBsGDSsGAQQBsyUL
AwEBAQIEChIIMDAxMDQyNjEwWAYJYIZIAYb6ax4BBEsMSVRoZSBwcml2YXRlIGtleSBjb3Jy
ZXNwb25kaW5nIHRvIHRoaXMgY2VydGlmaWNhdGUgbWF5IGhhdmUgYmVlbiBleHBvcnRlZC4w
KAYDVR0RBCEwH4EdTWF0dGhldy5GaW9yYXZhbnRlQGpodWFwbC5lZHUwUgYDVR0fBEswSTBH
oEWgQ6RBMD8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJU0RD
QTEOMAwGA1UEAxMFQ1JMNTYwHwYDVR0jBBgwFoAUCDUpmxH52EU2CyWmF2EJMB1yqeswHQYD
VR0OBBYEFO6LYxg6r9wHZ+zdQtBHn1dZ/YTNMAkGA1UdEwQCMAAwGQYJKoZIhvZ9B0EABAww
ChsEVjcuMQMCBLAwDQYJKoZIhvcNAQEFBQADgYEAJO9HQh4YNChVLzuZqK5ARJARD8JoujGZ
fdo75quvg2jXFQe2sEjvLnxJZgm/pv8fdZakq48CWwjYHKuvIp7sDjTEsQfo+y7SpN/N2NvJ
WU5SqfK1VgYtNLRRoGJUB5Q1aZ+Dg95g3kqpyfpUMISJL8IKVLtJVfN4fggFVUYZ9wwxggGr
MIIBpwIBATA3MC8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJ
U0RDQQIEP/HJ/TAJBgUrDgMCGgUAoIHLMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ
KoZIhvcNAQkFMQ8XDTEyMDkyNjE1NTgwOFowIwYJKoZIhvcNAQkEMRYEFIHcL3PmTkYCSQdV
i/cw/2XZzSGFMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAK
BggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI
KoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEgYBPPlkJaJuqw9KMxuGr4WN6eSrgJd9o1AIn
VUUM54WUViH58eN2bjVCaxY/QPAL00l3eg/m784iHqyExYPWwpmaWz/T7602xmOxaBcFA7SH
wLu1Kbq0hZWbG8g0ybHJz+IJPV/t80nsOgoibrnyBSs2Bi6E+hBS+Fqp7WaKdyKF3QAAAAAA
AA==
--------------ms080806010300010705070902--


--===============4660389707984739233==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============4660389707984739233==--


From xen-devel-bounces@lists.xen.org Wed Sep 26 16:07:11 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Sep 2012 16:07:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGu8P-0005BU-C9; Wed, 26 Sep 2012 16:06:49 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <matthew.fioravante@jhuapl.edu>) id 1TGu8N-0005B9-DN
	for xen-devel@lists.xensource.com; Wed, 26 Sep 2012 16:06:47 +0000
Received: from [85.158.139.83:14943] by server-6.bemta-5.messagelabs.com id
	E8/07-14717-61823605; Wed, 26 Sep 2012 16:06:46 +0000
X-Env-Sender: matthew.fioravante@jhuapl.edu
X-Msg-Ref: server-15.tower-182.messagelabs.com!1348675604!30053139!1
X-Originating-IP: [128.244.251.36]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG,
	UNPARSEABLE_RELAY
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25049 invoked from network); 26 Sep 2012 16:06:45 -0000
Received: from pilot.jhuapl.edu (HELO jhuapl.edu) (128.244.251.36)
	by server-15.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 26 Sep 2012 16:06:45 -0000
Received: from ([128.244.207.89])
	by pilot.jhuapl.edu with ESMTP with TLS id 63GHCH1.153706889;
	Wed, 26 Sep 2012 12:06:38 -0400
Message-ID: <506327BF.2080802@jhuapl.edu>
Date: Wed, 26 Sep 2012 12:05:19 -0400
From: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120827 Thunderbird/15.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <505CBA02.5040308@jhuapl.edu>
	<1348569044.3452.176.camel@zakaz.uk.xensource.com>
	<5061E293.7000106@jhuapl.edu>
	<1348649549.19176.15.camel@zakaz.uk.xensource.com>
	<506310BA.9080202@jhuapl.edu>
In-Reply-To: <506310BA.9080202@jhuapl.edu>
X-Enigmail-Version: 1.4.4
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] PATCH [base vtpm and libxl patches 4/6] add iomem
 support to libxl
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1298253401627824443=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a cryptographically signed message in MIME format.

--===============1298253401627824443==
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms010709000901080708070108"

This is a cryptographically signed message in MIME format.

--------------ms010709000901080708070108
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 09/26/2012 10:27 AM, Matthew Fioravante wrote:
> On 09/26/2012 04:52 AM, Ian Campbell wrote:
>> On Tue, 2012-09-25 at 17:57 +0100, Matthew Fioravante wrote:
>>>>> @@ -1005,6 +1005,30 @@ static void parse_config_data(const char
>>>>> *config_source,
>>>>>          }
>>>>>      }
>>>>> =20
>>>>> +    if (!xlu_cfg_get_list(config, "iomem", &iomem, &num_iomem, 0))=
 {
>>>>> +        b_info->num_iomem =3D num_iomem;
>>>>> +        b_info->iomem =3D calloc(num_iomem, sizeof(*b_info->iomem)=
);
>>>>> +        if (b_info->iomem =3D=3D NULL) {
>>>>> +            fprintf(stderr, "unable to allocate memory for iomem\n=
");
>>>>> +            exit(-1);
>>>>> +        }
>>>>> +        for (i =3D 0; i < num_iomem; i++) {
>>>>> +            buf =3D xlu_cfg_get_listitem (iomem, i);
>>>>> +            if (!buf) {
>>>>> +                fprintf(stderr,
>>>>> +                        "xl: Unable to get element %d in iomem lis=
t\n", i);
>>>>> +                exit(1);
>>>>> +            }
>>>>> +            if(sscanf(buf, "%" SCNx64",%" SCNu64,
>>>>> &b_info->iomem[i].start, &b_info->iomem[i].number) !=3D 2) {
>>>> This should be relatively simply to parse with strtoul (see the iopo=
rts
>>>> case) which would allow people to select hex or decimal in their
>>>> configuration files.
>>> Do we want to support hex or decimal? Pretty much anytime people star=
t
>>> talking about physical memory addresses or page numbers they use hex.=

>>> Also the ioports code actually only supports hexadecimal as it sets t=
he
>>> base in strtoul to 16. It also explicitly says in the xl.cfg manpage
>>> that ioports should be given in hex.
>> Good point. You mix decimal (SCNu64) and hex (SCNx64) though, it would=

>> be better to be consistent (in hex) I think.
>>
>> Ian
>>
> It seemed natural to me that when someone thinks they want N pages they=

> would think in decimal. It might be better to be hex though for consist=
ency.
>
New patch

Signed off by Matthew Fioravante: matthew.fioravante@jhuapl.edu

---
Changes from previous
* Rebased onto latest xen-unstable
* Rewrote the feature to mimic the style used by iports and irqs in
current libxl
* Updated xl.cfg manpage
* removed the redundant "allow" field, its not used by irq or ioports
either.
* fixed whitespace errors
* s/everytime/every time/
* Make num_pages argument a hex value

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
@@ -496,6 +496,17 @@ is given in hexadecimal and may either a span e.g.
C<2f8-2ff>
 It is recommended to use this option only for trusted VMs under
 administrator control.
=20
+=3Ditem B<iomem=3D[ "IOMEM_START,NUM_PAGES", "IOMEM_START,NUM_PAGES", ..=
=2E ]>
+
+Allow guest to access specific hardware I/O memory pages. B<IOMEM_START>=

+is a physical page number. B<NUM_PAGES> is the number
+of pages beginning with B<START_PAGE> to allow access. Both values
+must be given in hexadecimal.
+
+It is recommended to use this option only for trusted VMs under
+administrator control.
+
+
 =3Ditem B<irqs=3D[ NUMBER, NUMBER, ... ]>
=20
 Allow a guest to access specific physical IRQs.
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
@@ -963,6 +963,24 @@ static void domcreate_launch_dm(libxl__egc *egc,
libxl__multidev *multidev,
         }
     }
=20
+    for (i =3D 0; i < d_config->b_info.num_iomem; i++) {
+        libxl_iomem_range *io =3D &d_config->b_info.iomem[i];
+
+        LOG(DEBUG, "dom%d iomem %"PRIx64"-%"PRIx64,
+            domid, io->start, io->start + io->number - 1);
+
+        ret =3D xc_domain_iomem_permission(CTX->xch, domid,
+                                          io->start, io->number, 1);
+        if ( ret<0 ) {
+            LOGE(ERROR,
+                 "failed give dom%d access to iomem range
%"PRIx64"-%"PRIx64,
+                 domid, io->start, io->start + io->number - 1);
+            ret =3D ERROR_FAIL;
+        }
+    }
+
+
+
     for (i =3D 0; i < d_config->num_nics; i++) {
         /* We have to init the nic here, because we still haven't
          * called libxl_device_nic_add at this point, but qemu needs
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
@@ -140,6 +140,11 @@ libxl_ioport_range =3D Struct("ioport_range", [
     ("number", uint32),
     ])
=20
+libxl_iomem_range =3D Struct("iomem_range", [
+    ("start", uint64),
+    ("number", uint64),
+    ])
+
 libxl_vga_interface_info =3D Struct("vga_interface_info", [
     ("kind",    libxl_vga_interface_type),
     ])
@@ -284,6 +289,7 @@ libxl_domain_build_info =3D Struct("domain_build_info=
",[
=20
     ("ioports",          Array(libxl_ioport_range, "num_ioports")),
     ("irqs",             Array(uint32, "num_irqs")),
+    ("iomem",            Array(libxl_iomem_range, "num_iomem")),
=20
     ("u", KeyedUnion(None, libxl_domain_type, "type",
                 [("hvm", Struct(None, [("firmware",         string),
diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -574,8 +574,8 @@ static void parse_config_data(const char *config_sour=
ce,
     long l;
     XLU_Config *config;
     XLU_ConfigList *cpus, *vbds, *nics, *pcis, *cvfbs, *cpuids;
-    XLU_ConfigList *ioports, *irqs;
-    int num_ioports, num_irqs;
+    XLU_ConfigList *ioports, *irqs, *iomem;
+    int num_ioports, num_irqs, num_iomem;
     int pci_power_mgmt =3D 0;
     int pci_msitranslate =3D 0;
     int pci_permissive =3D 0;
@@ -1005,6 +1005,30 @@ static void parse_config_data(const char
*config_source,
         }
     }
=20
+    if (!xlu_cfg_get_list(config, "iomem", &iomem, &num_iomem, 0)) {
+        b_info->num_iomem =3D num_iomem;
+        b_info->iomem =3D calloc(num_iomem, sizeof(*b_info->iomem));
+        if (b_info->iomem =3D=3D NULL) {
+            fprintf(stderr, "unable to allocate memory for iomem\n");
+            exit(-1);
+        }
+        for (i =3D 0; i < num_iomem; i++) {
+            buf =3D xlu_cfg_get_listitem (iomem, i);
+            if (!buf) {
+                fprintf(stderr,
+                        "xl: Unable to get element %d in iomem list\n", =
i);
+                exit(1);
+            }
+            if(sscanf(buf, "%" SCNx64",%" SCNx64,
&b_info->iomem[i].start, &b_info->iomem[i].number) !=3D 2) {
+               fprintf(stderr,
+                       "xl: Invalid argument parsing iomem: %s\n", buf);=

+               exit(1);
+            }
+        }
+    }
+
+
+
     if (!xlu_cfg_get_list (config, "disk", &vbds, 0, 0)) {
         d_config->num_disks =3D 0;
         d_config->disks =3D NULL;







--------------ms010709000901080708070108
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIDyjCC
A8YwggMvoAMCAQICBD/xyf0wDQYJKoZIhvcNAQEFBQAwLzELMAkGA1UEBhMCVVMxDzANBgNV
BAoTBkpIVUFQTDEPMA0GA1UECxMGQklTRENBMB4XDTEwMDYxMTE4MjIwNloXDTEzMDYxMTE4
NTIwNlowZjELMAkGA1UEBhMCVVMxDzANBgNVBAoTBkpIVUFQTDEPMA0GA1UECxMGUGVvcGxl
MTUwFgYDVQQLEw9WUE5Hcm91cC1CSVNEQ0EwGwYDVQQDExRNYXR0aGV3IEUgRmlvcmF2YW50
ZTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAnpbwVSP6o1Nb5lcW7dd3yTo9iBJdi7qz
4nANOMFPK7JOy5npKN1iiousl28U/scUJES55gPwAWYJK3uVyQAsA4adgDKi5DoD1UHDQEwp
bY7iHLJeq0NPr4BqYNqnCFPbE6HC8zSJrr4qKn+gVUQT39SIFqdiIPJwZL8FYTRQ/zsCAwEA
AaOCAbYwggGyMAsGA1UdDwQEAwIHgDArBgNVHRAEJDAigA8yMDEwMDYxMTE4MjIwNlqBDzIw
MTIwNzE3MjI1MjA2WjAbBg0rBgEEAbMlCwMBAQEBBAoWCGZpb3JhbWUxMBsGDSsGAQQBsyUL
AwEBAQIEChIIMDAxMDQyNjEwWAYJYIZIAYb6ax4BBEsMSVRoZSBwcml2YXRlIGtleSBjb3Jy
ZXNwb25kaW5nIHRvIHRoaXMgY2VydGlmaWNhdGUgbWF5IGhhdmUgYmVlbiBleHBvcnRlZC4w
KAYDVR0RBCEwH4EdTWF0dGhldy5GaW9yYXZhbnRlQGpodWFwbC5lZHUwUgYDVR0fBEswSTBH
oEWgQ6RBMD8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJU0RD
QTEOMAwGA1UEAxMFQ1JMNTYwHwYDVR0jBBgwFoAUCDUpmxH52EU2CyWmF2EJMB1yqeswHQYD
VR0OBBYEFO6LYxg6r9wHZ+zdQtBHn1dZ/YTNMAkGA1UdEwQCMAAwGQYJKoZIhvZ9B0EABAww
ChsEVjcuMQMCBLAwDQYJKoZIhvcNAQEFBQADgYEAJO9HQh4YNChVLzuZqK5ARJARD8JoujGZ
fdo75quvg2jXFQe2sEjvLnxJZgm/pv8fdZakq48CWwjYHKuvIp7sDjTEsQfo+y7SpN/N2NvJ
WU5SqfK1VgYtNLRRoGJUB5Q1aZ+Dg95g3kqpyfpUMISJL8IKVLtJVfN4fggFVUYZ9wwxggGr
MIIBpwIBATA3MC8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJ
U0RDQQIEP/HJ/TAJBgUrDgMCGgUAoIHLMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ
KoZIhvcNAQkFMQ8XDTEyMDkyNjE2MDUxOVowIwYJKoZIhvcNAQkEMRYEFHwDnu5tOI64mey5
vDSKIsQOE03iMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAK
BggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI
KoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEgYB5CffQxtgzxaZGDQRrk6CwmY2r06m/p7Yt
OP6rjtYrz3Wwcb2lNUU9lJMo5kqTKHnuJznLNqcazt9i816Hs2LOYgyJRh96+7tr75Saz9qu
5dq1m5v9t6zWnR2zmEM6V4/pFelRKE7t6NA+GOP4/F70NrYSoIXXmffc3Y9Iw7+I7QAAAAAA
AA==
--------------ms010709000901080708070108--


--===============1298253401627824443==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============1298253401627824443==--


From xen-devel-bounces@lists.xen.org Wed Sep 26 16:07:11 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Sep 2012 16:07:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGu8P-0005BU-C9; Wed, 26 Sep 2012 16:06:49 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <matthew.fioravante@jhuapl.edu>) id 1TGu8N-0005B9-DN
	for xen-devel@lists.xensource.com; Wed, 26 Sep 2012 16:06:47 +0000
Received: from [85.158.139.83:14943] by server-6.bemta-5.messagelabs.com id
	E8/07-14717-61823605; Wed, 26 Sep 2012 16:06:46 +0000
X-Env-Sender: matthew.fioravante@jhuapl.edu
X-Msg-Ref: server-15.tower-182.messagelabs.com!1348675604!30053139!1
X-Originating-IP: [128.244.251.36]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG,
	UNPARSEABLE_RELAY
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25049 invoked from network); 26 Sep 2012 16:06:45 -0000
Received: from pilot.jhuapl.edu (HELO jhuapl.edu) (128.244.251.36)
	by server-15.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 26 Sep 2012 16:06:45 -0000
Received: from ([128.244.207.89])
	by pilot.jhuapl.edu with ESMTP with TLS id 63GHCH1.153706889;
	Wed, 26 Sep 2012 12:06:38 -0400
Message-ID: <506327BF.2080802@jhuapl.edu>
Date: Wed, 26 Sep 2012 12:05:19 -0400
From: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120827 Thunderbird/15.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <505CBA02.5040308@jhuapl.edu>
	<1348569044.3452.176.camel@zakaz.uk.xensource.com>
	<5061E293.7000106@jhuapl.edu>
	<1348649549.19176.15.camel@zakaz.uk.xensource.com>
	<506310BA.9080202@jhuapl.edu>
In-Reply-To: <506310BA.9080202@jhuapl.edu>
X-Enigmail-Version: 1.4.4
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] PATCH [base vtpm and libxl patches 4/6] add iomem
 support to libxl
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1298253401627824443=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a cryptographically signed message in MIME format.

--===============1298253401627824443==
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms010709000901080708070108"

This is a cryptographically signed message in MIME format.

--------------ms010709000901080708070108
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 09/26/2012 10:27 AM, Matthew Fioravante wrote:
> On 09/26/2012 04:52 AM, Ian Campbell wrote:
>> On Tue, 2012-09-25 at 17:57 +0100, Matthew Fioravante wrote:
>>>>> @@ -1005,6 +1005,30 @@ static void parse_config_data(const char
>>>>> *config_source,
>>>>>          }
>>>>>      }
>>>>> =20
>>>>> +    if (!xlu_cfg_get_list(config, "iomem", &iomem, &num_iomem, 0))=
 {
>>>>> +        b_info->num_iomem =3D num_iomem;
>>>>> +        b_info->iomem =3D calloc(num_iomem, sizeof(*b_info->iomem)=
);
>>>>> +        if (b_info->iomem =3D=3D NULL) {
>>>>> +            fprintf(stderr, "unable to allocate memory for iomem\n=
");
>>>>> +            exit(-1);
>>>>> +        }
>>>>> +        for (i =3D 0; i < num_iomem; i++) {
>>>>> +            buf =3D xlu_cfg_get_listitem (iomem, i);
>>>>> +            if (!buf) {
>>>>> +                fprintf(stderr,
>>>>> +                        "xl: Unable to get element %d in iomem lis=
t\n", i);
>>>>> +                exit(1);
>>>>> +            }
>>>>> +            if(sscanf(buf, "%" SCNx64",%" SCNu64,
>>>>> &b_info->iomem[i].start, &b_info->iomem[i].number) !=3D 2) {
>>>> This should be relatively simply to parse with strtoul (see the iopo=
rts
>>>> case) which would allow people to select hex or decimal in their
>>>> configuration files.
>>> Do we want to support hex or decimal? Pretty much anytime people star=
t
>>> talking about physical memory addresses or page numbers they use hex.=

>>> Also the ioports code actually only supports hexadecimal as it sets t=
he
>>> base in strtoul to 16. It also explicitly says in the xl.cfg manpage
>>> that ioports should be given in hex.
>> Good point. You mix decimal (SCNu64) and hex (SCNx64) though, it would=

>> be better to be consistent (in hex) I think.
>>
>> Ian
>>
> It seemed natural to me that when someone thinks they want N pages they=

> would think in decimal. It might be better to be hex though for consist=
ency.
>
New patch

Signed off by Matthew Fioravante: matthew.fioravante@jhuapl.edu

---
Changes from previous
* Rebased onto latest xen-unstable
* Rewrote the feature to mimic the style used by iports and irqs in
current libxl
* Updated xl.cfg manpage
* removed the redundant "allow" field, its not used by irq or ioports
either.
* fixed whitespace errors
* s/everytime/every time/
* Make num_pages argument a hex value

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
@@ -496,6 +496,17 @@ is given in hexadecimal and may either a span e.g.
C<2f8-2ff>
 It is recommended to use this option only for trusted VMs under
 administrator control.
=20
+=3Ditem B<iomem=3D[ "IOMEM_START,NUM_PAGES", "IOMEM_START,NUM_PAGES", ..=
=2E ]>
+
+Allow guest to access specific hardware I/O memory pages. B<IOMEM_START>=

+is a physical page number. B<NUM_PAGES> is the number
+of pages beginning with B<START_PAGE> to allow access. Both values
+must be given in hexadecimal.
+
+It is recommended to use this option only for trusted VMs under
+administrator control.
+
+
 =3Ditem B<irqs=3D[ NUMBER, NUMBER, ... ]>
=20
 Allow a guest to access specific physical IRQs.
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
@@ -963,6 +963,24 @@ static void domcreate_launch_dm(libxl__egc *egc,
libxl__multidev *multidev,
         }
     }
=20
+    for (i =3D 0; i < d_config->b_info.num_iomem; i++) {
+        libxl_iomem_range *io =3D &d_config->b_info.iomem[i];
+
+        LOG(DEBUG, "dom%d iomem %"PRIx64"-%"PRIx64,
+            domid, io->start, io->start + io->number - 1);
+
+        ret =3D xc_domain_iomem_permission(CTX->xch, domid,
+                                          io->start, io->number, 1);
+        if ( ret<0 ) {
+            LOGE(ERROR,
+                 "failed give dom%d access to iomem range
%"PRIx64"-%"PRIx64,
+                 domid, io->start, io->start + io->number - 1);
+            ret =3D ERROR_FAIL;
+        }
+    }
+
+
+
     for (i =3D 0; i < d_config->num_nics; i++) {
         /* We have to init the nic here, because we still haven't
          * called libxl_device_nic_add at this point, but qemu needs
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
@@ -140,6 +140,11 @@ libxl_ioport_range =3D Struct("ioport_range", [
     ("number", uint32),
     ])
=20
+libxl_iomem_range =3D Struct("iomem_range", [
+    ("start", uint64),
+    ("number", uint64),
+    ])
+
 libxl_vga_interface_info =3D Struct("vga_interface_info", [
     ("kind",    libxl_vga_interface_type),
     ])
@@ -284,6 +289,7 @@ libxl_domain_build_info =3D Struct("domain_build_info=
",[
=20
     ("ioports",          Array(libxl_ioport_range, "num_ioports")),
     ("irqs",             Array(uint32, "num_irqs")),
+    ("iomem",            Array(libxl_iomem_range, "num_iomem")),
=20
     ("u", KeyedUnion(None, libxl_domain_type, "type",
                 [("hvm", Struct(None, [("firmware",         string),
diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -574,8 +574,8 @@ static void parse_config_data(const char *config_sour=
ce,
     long l;
     XLU_Config *config;
     XLU_ConfigList *cpus, *vbds, *nics, *pcis, *cvfbs, *cpuids;
-    XLU_ConfigList *ioports, *irqs;
-    int num_ioports, num_irqs;
+    XLU_ConfigList *ioports, *irqs, *iomem;
+    int num_ioports, num_irqs, num_iomem;
     int pci_power_mgmt =3D 0;
     int pci_msitranslate =3D 0;
     int pci_permissive =3D 0;
@@ -1005,6 +1005,30 @@ static void parse_config_data(const char
*config_source,
         }
     }
=20
+    if (!xlu_cfg_get_list(config, "iomem", &iomem, &num_iomem, 0)) {
+        b_info->num_iomem =3D num_iomem;
+        b_info->iomem =3D calloc(num_iomem, sizeof(*b_info->iomem));
+        if (b_info->iomem =3D=3D NULL) {
+            fprintf(stderr, "unable to allocate memory for iomem\n");
+            exit(-1);
+        }
+        for (i =3D 0; i < num_iomem; i++) {
+            buf =3D xlu_cfg_get_listitem (iomem, i);
+            if (!buf) {
+                fprintf(stderr,
+                        "xl: Unable to get element %d in iomem list\n", =
i);
+                exit(1);
+            }
+            if(sscanf(buf, "%" SCNx64",%" SCNx64,
&b_info->iomem[i].start, &b_info->iomem[i].number) !=3D 2) {
+               fprintf(stderr,
+                       "xl: Invalid argument parsing iomem: %s\n", buf);=

+               exit(1);
+            }
+        }
+    }
+
+
+
     if (!xlu_cfg_get_list (config, "disk", &vbds, 0, 0)) {
         d_config->num_disks =3D 0;
         d_config->disks =3D NULL;







--------------ms010709000901080708070108
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIDyjCC
A8YwggMvoAMCAQICBD/xyf0wDQYJKoZIhvcNAQEFBQAwLzELMAkGA1UEBhMCVVMxDzANBgNV
BAoTBkpIVUFQTDEPMA0GA1UECxMGQklTRENBMB4XDTEwMDYxMTE4MjIwNloXDTEzMDYxMTE4
NTIwNlowZjELMAkGA1UEBhMCVVMxDzANBgNVBAoTBkpIVUFQTDEPMA0GA1UECxMGUGVvcGxl
MTUwFgYDVQQLEw9WUE5Hcm91cC1CSVNEQ0EwGwYDVQQDExRNYXR0aGV3IEUgRmlvcmF2YW50
ZTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAnpbwVSP6o1Nb5lcW7dd3yTo9iBJdi7qz
4nANOMFPK7JOy5npKN1iiousl28U/scUJES55gPwAWYJK3uVyQAsA4adgDKi5DoD1UHDQEwp
bY7iHLJeq0NPr4BqYNqnCFPbE6HC8zSJrr4qKn+gVUQT39SIFqdiIPJwZL8FYTRQ/zsCAwEA
AaOCAbYwggGyMAsGA1UdDwQEAwIHgDArBgNVHRAEJDAigA8yMDEwMDYxMTE4MjIwNlqBDzIw
MTIwNzE3MjI1MjA2WjAbBg0rBgEEAbMlCwMBAQEBBAoWCGZpb3JhbWUxMBsGDSsGAQQBsyUL
AwEBAQIEChIIMDAxMDQyNjEwWAYJYIZIAYb6ax4BBEsMSVRoZSBwcml2YXRlIGtleSBjb3Jy
ZXNwb25kaW5nIHRvIHRoaXMgY2VydGlmaWNhdGUgbWF5IGhhdmUgYmVlbiBleHBvcnRlZC4w
KAYDVR0RBCEwH4EdTWF0dGhldy5GaW9yYXZhbnRlQGpodWFwbC5lZHUwUgYDVR0fBEswSTBH
oEWgQ6RBMD8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJU0RD
QTEOMAwGA1UEAxMFQ1JMNTYwHwYDVR0jBBgwFoAUCDUpmxH52EU2CyWmF2EJMB1yqeswHQYD
VR0OBBYEFO6LYxg6r9wHZ+zdQtBHn1dZ/YTNMAkGA1UdEwQCMAAwGQYJKoZIhvZ9B0EABAww
ChsEVjcuMQMCBLAwDQYJKoZIhvcNAQEFBQADgYEAJO9HQh4YNChVLzuZqK5ARJARD8JoujGZ
fdo75quvg2jXFQe2sEjvLnxJZgm/pv8fdZakq48CWwjYHKuvIp7sDjTEsQfo+y7SpN/N2NvJ
WU5SqfK1VgYtNLRRoGJUB5Q1aZ+Dg95g3kqpyfpUMISJL8IKVLtJVfN4fggFVUYZ9wwxggGr
MIIBpwIBATA3MC8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJ
U0RDQQIEP/HJ/TAJBgUrDgMCGgUAoIHLMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ
KoZIhvcNAQkFMQ8XDTEyMDkyNjE2MDUxOVowIwYJKoZIhvcNAQkEMRYEFHwDnu5tOI64mey5
vDSKIsQOE03iMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAK
BggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI
KoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEgYB5CffQxtgzxaZGDQRrk6CwmY2r06m/p7Yt
OP6rjtYrz3Wwcb2lNUU9lJMo5kqTKHnuJznLNqcazt9i816Hs2LOYgyJRh96+7tr75Saz9qu
5dq1m5v9t6zWnR2zmEM6V4/pFelRKE7t6NA+GOP4/F70NrYSoIXXmffc3Y9Iw7+I7QAAAAAA
AA==
--------------ms010709000901080708070108--


--===============1298253401627824443==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============1298253401627824443==--


From xen-devel-bounces@lists.xen.org Wed Sep 26 16:08:56 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Sep 2012 16:08:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGuAD-0005Hz-2A; Wed, 26 Sep 2012 16:08: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 1TGuAB-0005Hr-SX
	for xen-devel@lists.xensource.com; Wed, 26 Sep 2012 16:08:39 +0000
Received: from [85.158.139.211:54294] by server-9.bemta-5.messagelabs.com id
	48/55-14846-78823605; Wed, 26 Sep 2012 16:08:39 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-206.messagelabs.com!1348675718!20008276!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTE1NzQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18181 invoked from network); 26 Sep 2012 16:08:38 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Sep 2012 16:08:38 -0000
X-IronPort-AV: E=Sophos;i="4.80,491,1344211200"; d="scan'208";a="14783477"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Sep 2012 16:08: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.279.1;
	Wed, 26 Sep 2012 17:08:38 +0100
Message-ID: <1348675717.19176.71.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
Date: Wed, 26 Sep 2012 17:08:37 +0100
In-Reply-To: <506327BF.2080802@jhuapl.edu>
References: <505CBA02.5040308@jhuapl.edu>
	<1348569044.3452.176.camel@zakaz.uk.xensource.com>
	<5061E293.7000106@jhuapl.edu>
	<1348649549.19176.15.camel@zakaz.uk.xensource.com>
	<506310BA.9080202@jhuapl.edu> <506327BF.2080802@jhuapl.edu>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] PATCH [base vtpm and libxl patches 4/6] add iomem
 support to 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

On Wed, 2012-09-26 at 17:05 +0100, Matthew Fioravante wrote:
> New patch

Thanks, but I'm afraid this one is still whitespace damaged.

I'm afraid there is no way we can apply any of these patches until you
sort that out.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 26 16:08:56 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Sep 2012 16:08:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGuAD-0005Hz-2A; Wed, 26 Sep 2012 16:08: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 1TGuAB-0005Hr-SX
	for xen-devel@lists.xensource.com; Wed, 26 Sep 2012 16:08:39 +0000
Received: from [85.158.139.211:54294] by server-9.bemta-5.messagelabs.com id
	48/55-14846-78823605; Wed, 26 Sep 2012 16:08:39 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-206.messagelabs.com!1348675718!20008276!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTE1NzQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18181 invoked from network); 26 Sep 2012 16:08:38 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Sep 2012 16:08:38 -0000
X-IronPort-AV: E=Sophos;i="4.80,491,1344211200"; d="scan'208";a="14783477"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Sep 2012 16:08: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.279.1;
	Wed, 26 Sep 2012 17:08:38 +0100
Message-ID: <1348675717.19176.71.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
Date: Wed, 26 Sep 2012 17:08:37 +0100
In-Reply-To: <506327BF.2080802@jhuapl.edu>
References: <505CBA02.5040308@jhuapl.edu>
	<1348569044.3452.176.camel@zakaz.uk.xensource.com>
	<5061E293.7000106@jhuapl.edu>
	<1348649549.19176.15.camel@zakaz.uk.xensource.com>
	<506310BA.9080202@jhuapl.edu> <506327BF.2080802@jhuapl.edu>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] PATCH [base vtpm and libxl patches 4/6] add iomem
 support to 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

On Wed, 2012-09-26 at 17:05 +0100, Matthew Fioravante wrote:
> New patch

Thanks, but I'm afraid this one is still whitespace damaged.

I'm afraid there is no way we can apply any of these patches until you
sort that out.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 26 16:19:20 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Sep 2012 16: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 1TGuKE-0005Vp-5T; Wed, 26 Sep 2012 16:19:02 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <matthew.fioravante@jhuapl.edu>) id 1TGuKC-0005Vk-CP
	for xen-devel@lists.xensource.com; Wed, 26 Sep 2012 16:19:00 +0000
Received: from [85.158.138.51:65438] by server-14.bemta-3.messagelabs.com id
	E5/94-25886-3FA23605; Wed, 26 Sep 2012 16:18:59 +0000
X-Env-Sender: matthew.fioravante@jhuapl.edu
X-Msg-Ref: server-3.tower-174.messagelabs.com!1348676337!23996578!1
X-Originating-IP: [128.244.251.36]
X-SpamReason: No, hits=0.0 required=7.0 tests=UNPARSEABLE_RELAY
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1680 invoked from network); 26 Sep 2012 16:18:58 -0000
Received: from pilot.jhuapl.edu (HELO jhuapl.edu) (128.244.251.36)
	by server-3.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 26 Sep 2012 16:18:58 -0000
Received: from ([128.244.207.89])
	by pilot.jhuapl.edu with ESMTP with TLS id 63GHCH1.153708178;
	Wed, 26 Sep 2012 12:18:51 -0400
Message-ID: <50632A9C.3030903@jhuapl.edu>
Date: Wed, 26 Sep 2012 12:17:32 -0400
From: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120827 Thunderbird/15.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <505CBA02.5040308@jhuapl.edu>
	<1348569044.3452.176.camel@zakaz.uk.xensource.com>
	<5061E293.7000106@jhuapl.edu>
	<1348649549.19176.15.camel@zakaz.uk.xensource.com>
	<506310BA.9080202@jhuapl.edu> <506327BF.2080802@jhuapl.edu>
	<1348675717.19176.71.camel@zakaz.uk.xensource.com>
In-Reply-To: <1348675717.19176.71.camel@zakaz.uk.xensource.com>
X-Enigmail-Version: 1.4.4
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] PATCH [base vtpm and libxl patches 4/6] add iomem
 support to libxl
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0830011265465155026=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a cryptographically signed message in MIME format.

--===============0830011265465155026==
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms060401090503080709070804"

This is a cryptographically signed message in MIME format.

--------------ms060401090503080709070804
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Sigh.. its probably my email client. Anyway I'll fix them all and resubmi=
t

On 09/26/2012 12:08 PM, Ian Campbell wrote:
> On Wed, 2012-09-26 at 17:05 +0100, Matthew Fioravante wrote:
>> New patch
> Thanks, but I'm afraid this one is still whitespace damaged.
>
> I'm afraid there is no way we can apply any of these patches until you
> sort that out.
>
> Ian.
>



--------------ms060401090503080709070804
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIDyjCC
A8YwggMvoAMCAQICBD/xyf0wDQYJKoZIhvcNAQEFBQAwLzELMAkGA1UEBhMCVVMxDzANBgNV
BAoTBkpIVUFQTDEPMA0GA1UECxMGQklTRENBMB4XDTEwMDYxMTE4MjIwNloXDTEzMDYxMTE4
NTIwNlowZjELMAkGA1UEBhMCVVMxDzANBgNVBAoTBkpIVUFQTDEPMA0GA1UECxMGUGVvcGxl
MTUwFgYDVQQLEw9WUE5Hcm91cC1CSVNEQ0EwGwYDVQQDExRNYXR0aGV3IEUgRmlvcmF2YW50
ZTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAnpbwVSP6o1Nb5lcW7dd3yTo9iBJdi7qz
4nANOMFPK7JOy5npKN1iiousl28U/scUJES55gPwAWYJK3uVyQAsA4adgDKi5DoD1UHDQEwp
bY7iHLJeq0NPr4BqYNqnCFPbE6HC8zSJrr4qKn+gVUQT39SIFqdiIPJwZL8FYTRQ/zsCAwEA
AaOCAbYwggGyMAsGA1UdDwQEAwIHgDArBgNVHRAEJDAigA8yMDEwMDYxMTE4MjIwNlqBDzIw
MTIwNzE3MjI1MjA2WjAbBg0rBgEEAbMlCwMBAQEBBAoWCGZpb3JhbWUxMBsGDSsGAQQBsyUL
AwEBAQIEChIIMDAxMDQyNjEwWAYJYIZIAYb6ax4BBEsMSVRoZSBwcml2YXRlIGtleSBjb3Jy
ZXNwb25kaW5nIHRvIHRoaXMgY2VydGlmaWNhdGUgbWF5IGhhdmUgYmVlbiBleHBvcnRlZC4w
KAYDVR0RBCEwH4EdTWF0dGhldy5GaW9yYXZhbnRlQGpodWFwbC5lZHUwUgYDVR0fBEswSTBH
oEWgQ6RBMD8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJU0RD
QTEOMAwGA1UEAxMFQ1JMNTYwHwYDVR0jBBgwFoAUCDUpmxH52EU2CyWmF2EJMB1yqeswHQYD
VR0OBBYEFO6LYxg6r9wHZ+zdQtBHn1dZ/YTNMAkGA1UdEwQCMAAwGQYJKoZIhvZ9B0EABAww
ChsEVjcuMQMCBLAwDQYJKoZIhvcNAQEFBQADgYEAJO9HQh4YNChVLzuZqK5ARJARD8JoujGZ
fdo75quvg2jXFQe2sEjvLnxJZgm/pv8fdZakq48CWwjYHKuvIp7sDjTEsQfo+y7SpN/N2NvJ
WU5SqfK1VgYtNLRRoGJUB5Q1aZ+Dg95g3kqpyfpUMISJL8IKVLtJVfN4fggFVUYZ9wwxggGr
MIIBpwIBATA3MC8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJ
U0RDQQIEP/HJ/TAJBgUrDgMCGgUAoIHLMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ
KoZIhvcNAQkFMQ8XDTEyMDkyNjE2MTczMlowIwYJKoZIhvcNAQkEMRYEFKIrBJ14mgnYj+Et
NZsIHhxAZWZPMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAK
BggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI
KoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEgYANEzJUbfL9X7AKRwXg22YpaB9YWSuBSlYP
zXGZLGJiS5LQA+31zmCOd/aszqeYqK2e6aNx5lbTVSFLqdQvCnu6b0qbAt5IWRNjVX6RJ4+g
bRqw6/wNTHabIx/Jr+DAl+GLJjcri3NK3qjOahI+lyRt/dgUSSZXof/RUedvYy08aQAAAAAA
AA==
--------------ms060401090503080709070804--


--===============0830011265465155026==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============0830011265465155026==--


From xen-devel-bounces@lists.xen.org Wed Sep 26 16:19:20 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Sep 2012 16: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 1TGuKE-0005Vp-5T; Wed, 26 Sep 2012 16:19:02 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <matthew.fioravante@jhuapl.edu>) id 1TGuKC-0005Vk-CP
	for xen-devel@lists.xensource.com; Wed, 26 Sep 2012 16:19:00 +0000
Received: from [85.158.138.51:65438] by server-14.bemta-3.messagelabs.com id
	E5/94-25886-3FA23605; Wed, 26 Sep 2012 16:18:59 +0000
X-Env-Sender: matthew.fioravante@jhuapl.edu
X-Msg-Ref: server-3.tower-174.messagelabs.com!1348676337!23996578!1
X-Originating-IP: [128.244.251.36]
X-SpamReason: No, hits=0.0 required=7.0 tests=UNPARSEABLE_RELAY
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1680 invoked from network); 26 Sep 2012 16:18:58 -0000
Received: from pilot.jhuapl.edu (HELO jhuapl.edu) (128.244.251.36)
	by server-3.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 26 Sep 2012 16:18:58 -0000
Received: from ([128.244.207.89])
	by pilot.jhuapl.edu with ESMTP with TLS id 63GHCH1.153708178;
	Wed, 26 Sep 2012 12:18:51 -0400
Message-ID: <50632A9C.3030903@jhuapl.edu>
Date: Wed, 26 Sep 2012 12:17:32 -0400
From: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120827 Thunderbird/15.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <505CBA02.5040308@jhuapl.edu>
	<1348569044.3452.176.camel@zakaz.uk.xensource.com>
	<5061E293.7000106@jhuapl.edu>
	<1348649549.19176.15.camel@zakaz.uk.xensource.com>
	<506310BA.9080202@jhuapl.edu> <506327BF.2080802@jhuapl.edu>
	<1348675717.19176.71.camel@zakaz.uk.xensource.com>
In-Reply-To: <1348675717.19176.71.camel@zakaz.uk.xensource.com>
X-Enigmail-Version: 1.4.4
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] PATCH [base vtpm and libxl patches 4/6] add iomem
 support to libxl
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0830011265465155026=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a cryptographically signed message in MIME format.

--===============0830011265465155026==
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms060401090503080709070804"

This is a cryptographically signed message in MIME format.

--------------ms060401090503080709070804
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Sigh.. its probably my email client. Anyway I'll fix them all and resubmi=
t

On 09/26/2012 12:08 PM, Ian Campbell wrote:
> On Wed, 2012-09-26 at 17:05 +0100, Matthew Fioravante wrote:
>> New patch
> Thanks, but I'm afraid this one is still whitespace damaged.
>
> I'm afraid there is no way we can apply any of these patches until you
> sort that out.
>
> Ian.
>



--------------ms060401090503080709070804
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIDyjCC
A8YwggMvoAMCAQICBD/xyf0wDQYJKoZIhvcNAQEFBQAwLzELMAkGA1UEBhMCVVMxDzANBgNV
BAoTBkpIVUFQTDEPMA0GA1UECxMGQklTRENBMB4XDTEwMDYxMTE4MjIwNloXDTEzMDYxMTE4
NTIwNlowZjELMAkGA1UEBhMCVVMxDzANBgNVBAoTBkpIVUFQTDEPMA0GA1UECxMGUGVvcGxl
MTUwFgYDVQQLEw9WUE5Hcm91cC1CSVNEQ0EwGwYDVQQDExRNYXR0aGV3IEUgRmlvcmF2YW50
ZTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAnpbwVSP6o1Nb5lcW7dd3yTo9iBJdi7qz
4nANOMFPK7JOy5npKN1iiousl28U/scUJES55gPwAWYJK3uVyQAsA4adgDKi5DoD1UHDQEwp
bY7iHLJeq0NPr4BqYNqnCFPbE6HC8zSJrr4qKn+gVUQT39SIFqdiIPJwZL8FYTRQ/zsCAwEA
AaOCAbYwggGyMAsGA1UdDwQEAwIHgDArBgNVHRAEJDAigA8yMDEwMDYxMTE4MjIwNlqBDzIw
MTIwNzE3MjI1MjA2WjAbBg0rBgEEAbMlCwMBAQEBBAoWCGZpb3JhbWUxMBsGDSsGAQQBsyUL
AwEBAQIEChIIMDAxMDQyNjEwWAYJYIZIAYb6ax4BBEsMSVRoZSBwcml2YXRlIGtleSBjb3Jy
ZXNwb25kaW5nIHRvIHRoaXMgY2VydGlmaWNhdGUgbWF5IGhhdmUgYmVlbiBleHBvcnRlZC4w
KAYDVR0RBCEwH4EdTWF0dGhldy5GaW9yYXZhbnRlQGpodWFwbC5lZHUwUgYDVR0fBEswSTBH
oEWgQ6RBMD8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJU0RD
QTEOMAwGA1UEAxMFQ1JMNTYwHwYDVR0jBBgwFoAUCDUpmxH52EU2CyWmF2EJMB1yqeswHQYD
VR0OBBYEFO6LYxg6r9wHZ+zdQtBHn1dZ/YTNMAkGA1UdEwQCMAAwGQYJKoZIhvZ9B0EABAww
ChsEVjcuMQMCBLAwDQYJKoZIhvcNAQEFBQADgYEAJO9HQh4YNChVLzuZqK5ARJARD8JoujGZ
fdo75quvg2jXFQe2sEjvLnxJZgm/pv8fdZakq48CWwjYHKuvIp7sDjTEsQfo+y7SpN/N2NvJ
WU5SqfK1VgYtNLRRoGJUB5Q1aZ+Dg95g3kqpyfpUMISJL8IKVLtJVfN4fggFVUYZ9wwxggGr
MIIBpwIBATA3MC8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJ
U0RDQQIEP/HJ/TAJBgUrDgMCGgUAoIHLMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ
KoZIhvcNAQkFMQ8XDTEyMDkyNjE2MTczMlowIwYJKoZIhvcNAQkEMRYEFKIrBJ14mgnYj+Et
NZsIHhxAZWZPMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAK
BggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI
KoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEgYANEzJUbfL9X7AKRwXg22YpaB9YWSuBSlYP
zXGZLGJiS5LQA+31zmCOd/aszqeYqK2e6aNx5lbTVSFLqdQvCnu6b0qbAt5IWRNjVX6RJ4+g
bRqw6/wNTHabIx/Jr+DAl+GLJjcri3NK3qjOahI+lyRt/dgUSSZXof/RUedvYy08aQAAAAAA
AA==
--------------ms060401090503080709070804--


--===============0830011265465155026==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============0830011265465155026==--


From xen-devel-bounces@lists.xen.org Wed Sep 26 16:20:18 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Sep 2012 16:20:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGuL8-0005Yk-Ja; Wed, 26 Sep 2012 16:19:58 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <julien.grall@citrix.com>) id 1TGuL7-0005Yb-7Q
	for xen-devel@lists.xen.org; Wed, 26 Sep 2012 16:19:57 +0000
Received: from [85.158.143.35:15001] by server-1.bemta-4.messagelabs.com id
	A1/ED-05684-C2B23605; Wed, 26 Sep 2012 16:19:56 +0000
X-Env-Sender: julien.grall@citrix.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1348676393!13175806!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzE2MjI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5259 invoked from network); 26 Sep 2012 16:19:55 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-11.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Sep 2012 16:19:55 -0000
X-IronPort-AV: E=Sophos;i="4.80,491,1344211200"; d="scan'208";a="39252649"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Sep 2012 16:19:19 +0000
Received: from [10.80.248.240] (10.80.248.240) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1; Wed, 26 Sep 2012
	12:19:18 -0400
Message-ID: <50632C23.3080200@citrix.com>
Date: Wed, 26 Sep 2012 17:24:03 +0100
From: Julien Grall <julien.grall@citrix.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US;
	rv:1.9.1.16) Gecko/20120726 Icedove/3.0.11
MIME-Version: 1.0
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
References: <1348572817-13908-1-git-send-email-julien.grall@citrix.com>
	<20579.6438.538065.533618@mariner.uk.xensource.com>
In-Reply-To: <20579.6438.538065.533618@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 V2] libxenstore: filter watch events in
 libxenstore when we unwatch
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 09/26/2012 04:03 PM, Ian Jackson wrote:

> Julien Grall writes ("[PATCH V2] libxenstore: filter watch events in libxenstore when we unwatch"):
>> +
>> +/* Clear the pipe token if there are no more pending watchs.
>> + * We suppose the watch_mutex is already taken.
>> + */
>> +static void xs_clear_watch_pipe(struct xs_handle *h)
> 
> I think this would be better called xs_maybe_clear_watch_pipe or
> something.  Since it doesn't always clear the watch pipe, it makes the
> call sites confusing.

I will fix on the next patch version.

>> @@ -855,14 +864,62 @@ char **xs_read_watch(struct xs_handle *h, unsigned int *num)
>>  bool xs_unwatch(struct xs_handle *h, const char *path, const char *token)
>>  {
>>  	struct iovec iov[2];
>> +	struct xs_stored_msg *msg, *tmsg;
>> +	bool res;
>> +	char *s, *p;
>> +	unsigned int i;
>> +	char *l_token, *l_path;
>>  
>>  	iov[0].iov_base = (char *)path;
>>  	iov[0].iov_len = strlen(path) + 1;
>>  	iov[1].iov_base = (char *)token;
>>  	iov[1].iov_len = strlen(token) + 1;
>>  
>> -	return xs_bool(xs_talkv(h, XBT_NULL, XS_UNWATCH, iov,
>> -				ARRAY_SIZE(iov), NULL));
>> +	res = xs_bool(xs_talkv(h, XBT_NULL, XS_UNWATCH, iov,
>> +						   ARRAY_SIZE(iov), NULL));
>> +
>> +	/* Filter the watch list to remove potential message */
>> +	mutex_lock(&h->watch_mutex);
>> +
>> +	if (list_empty(&h->watch_list)) {
>> +		mutex_unlock(&h->watch_mutex);
>> +		return res;
>> +	}
> 
> I still think this is redundant, so it should not be here.


The piece of code I moved in the new function expects to read one
character in the pipe. So if the pipe is empty it will either block (if
the file descriptor is not set to NONBLOCK) either loop as read return 0
or -1.

This code is definitely usefull if we want to avoid this annoying
problem. Perhaps we should modify the behavior of this piece of code.

>> +	list_for_each_entry_safe(msg, tmsg, &h->watch_list, list) {
>> +		assert(msg->hdr.type == XS_WATCH_EVENT);
>> +
>> +		s = msg->body;
>> +
>> +		l_token = NULL;
>> +		l_path = NULL;
>> +
>> +		for (p = s, i = 0; p < msg->body + msg->hdr.len; p++) {
>> +			if (*p == '\0')
>> +			{
>> +				if (i == XS_WATCH_TOKEN)
>> +					l_token = s;
>> +				else if (i == XS_WATCH_PATH)
>> +					l_path = s;
>> +				i++;
>> +				s = p + 1;
>> +			}
>> +		}
>> +
>> +		if (l_token && !strcmp(token, l_token)
>> +			/* Use strncmp because we can have a watch fired on sub-directory */
> 
> Oh bum.  I see a problem.  This is quite a bad problem.
> 
> It is legal to do this:
> 
>    client:
> 
>      XS_WATCH /foo token1
>      XS_WATCH /foo/bar token1
> 
> Now if you get a watch event you get the token and the actual path.
> So suppose we have, simultaneously:
> 
>    our client:                          another client:
>      XS_UNWATCH /foo/bar token1          WRITE /foo/bar/zonk sponge
> 
> Then xenstored will generate two watch events:
>                                 WATCH_EVENT /foo/bar/zonk token1
>                                 WATCH_EVENT /foo/bar/zonk token1
> 
> With your patch, both of these would be thrown away.  Whereas in fact
> one of them should still be presented.
> 
> How confident are we that there are no clients which rely on this not
> changing ?
>
> At the very least this needs a documentation patch explaining the
> undesirable consequences of setting multiple watches with the same
> token.  Arguably it needs a flag to the library (or a new function
> name) to ask for this new behaviour.
> 
> I would have to think, for example, about whether the new libxl event
> sub-library would make any mistakes as a result of this proposed
> change.  I think it wouldn't...


If a client decides to use the same token for multiple path (including
one which is the sub-directory), it's not possible to know which
WATCH_EVENT we need to remove.

The current problem that the patch tries to resolve is mainly for
clients who use token with a pointer inside (as QEMU made).

Adding a flag to xs_open could be a good solution as:
#define XS_UNWATCH_SAFE 1UL<<2

If the flag is not enabled, xs_unwatch has the same (buggy?) behaviour
as before. When it's enabled, xs_unwatch will browse the watch list and
will remove spurious watch event.

What do you think?

Sincerely yours,

-- 
Julien Grall



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 26 16:20:18 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Sep 2012 16:20:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGuL8-0005Yk-Ja; Wed, 26 Sep 2012 16:19:58 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <julien.grall@citrix.com>) id 1TGuL7-0005Yb-7Q
	for xen-devel@lists.xen.org; Wed, 26 Sep 2012 16:19:57 +0000
Received: from [85.158.143.35:15001] by server-1.bemta-4.messagelabs.com id
	A1/ED-05684-C2B23605; Wed, 26 Sep 2012 16:19:56 +0000
X-Env-Sender: julien.grall@citrix.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1348676393!13175806!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzE2MjI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5259 invoked from network); 26 Sep 2012 16:19:55 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-11.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Sep 2012 16:19:55 -0000
X-IronPort-AV: E=Sophos;i="4.80,491,1344211200"; d="scan'208";a="39252649"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Sep 2012 16:19:19 +0000
Received: from [10.80.248.240] (10.80.248.240) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1; Wed, 26 Sep 2012
	12:19:18 -0400
Message-ID: <50632C23.3080200@citrix.com>
Date: Wed, 26 Sep 2012 17:24:03 +0100
From: Julien Grall <julien.grall@citrix.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US;
	rv:1.9.1.16) Gecko/20120726 Icedove/3.0.11
MIME-Version: 1.0
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
References: <1348572817-13908-1-git-send-email-julien.grall@citrix.com>
	<20579.6438.538065.533618@mariner.uk.xensource.com>
In-Reply-To: <20579.6438.538065.533618@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 V2] libxenstore: filter watch events in
 libxenstore when we unwatch
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 09/26/2012 04:03 PM, Ian Jackson wrote:

> Julien Grall writes ("[PATCH V2] libxenstore: filter watch events in libxenstore when we unwatch"):
>> +
>> +/* Clear the pipe token if there are no more pending watchs.
>> + * We suppose the watch_mutex is already taken.
>> + */
>> +static void xs_clear_watch_pipe(struct xs_handle *h)
> 
> I think this would be better called xs_maybe_clear_watch_pipe or
> something.  Since it doesn't always clear the watch pipe, it makes the
> call sites confusing.

I will fix on the next patch version.

>> @@ -855,14 +864,62 @@ char **xs_read_watch(struct xs_handle *h, unsigned int *num)
>>  bool xs_unwatch(struct xs_handle *h, const char *path, const char *token)
>>  {
>>  	struct iovec iov[2];
>> +	struct xs_stored_msg *msg, *tmsg;
>> +	bool res;
>> +	char *s, *p;
>> +	unsigned int i;
>> +	char *l_token, *l_path;
>>  
>>  	iov[0].iov_base = (char *)path;
>>  	iov[0].iov_len = strlen(path) + 1;
>>  	iov[1].iov_base = (char *)token;
>>  	iov[1].iov_len = strlen(token) + 1;
>>  
>> -	return xs_bool(xs_talkv(h, XBT_NULL, XS_UNWATCH, iov,
>> -				ARRAY_SIZE(iov), NULL));
>> +	res = xs_bool(xs_talkv(h, XBT_NULL, XS_UNWATCH, iov,
>> +						   ARRAY_SIZE(iov), NULL));
>> +
>> +	/* Filter the watch list to remove potential message */
>> +	mutex_lock(&h->watch_mutex);
>> +
>> +	if (list_empty(&h->watch_list)) {
>> +		mutex_unlock(&h->watch_mutex);
>> +		return res;
>> +	}
> 
> I still think this is redundant, so it should not be here.


The piece of code I moved in the new function expects to read one
character in the pipe. So if the pipe is empty it will either block (if
the file descriptor is not set to NONBLOCK) either loop as read return 0
or -1.

This code is definitely usefull if we want to avoid this annoying
problem. Perhaps we should modify the behavior of this piece of code.

>> +	list_for_each_entry_safe(msg, tmsg, &h->watch_list, list) {
>> +		assert(msg->hdr.type == XS_WATCH_EVENT);
>> +
>> +		s = msg->body;
>> +
>> +		l_token = NULL;
>> +		l_path = NULL;
>> +
>> +		for (p = s, i = 0; p < msg->body + msg->hdr.len; p++) {
>> +			if (*p == '\0')
>> +			{
>> +				if (i == XS_WATCH_TOKEN)
>> +					l_token = s;
>> +				else if (i == XS_WATCH_PATH)
>> +					l_path = s;
>> +				i++;
>> +				s = p + 1;
>> +			}
>> +		}
>> +
>> +		if (l_token && !strcmp(token, l_token)
>> +			/* Use strncmp because we can have a watch fired on sub-directory */
> 
> Oh bum.  I see a problem.  This is quite a bad problem.
> 
> It is legal to do this:
> 
>    client:
> 
>      XS_WATCH /foo token1
>      XS_WATCH /foo/bar token1
> 
> Now if you get a watch event you get the token and the actual path.
> So suppose we have, simultaneously:
> 
>    our client:                          another client:
>      XS_UNWATCH /foo/bar token1          WRITE /foo/bar/zonk sponge
> 
> Then xenstored will generate two watch events:
>                                 WATCH_EVENT /foo/bar/zonk token1
>                                 WATCH_EVENT /foo/bar/zonk token1
> 
> With your patch, both of these would be thrown away.  Whereas in fact
> one of them should still be presented.
> 
> How confident are we that there are no clients which rely on this not
> changing ?
>
> At the very least this needs a documentation patch explaining the
> undesirable consequences of setting multiple watches with the same
> token.  Arguably it needs a flag to the library (or a new function
> name) to ask for this new behaviour.
> 
> I would have to think, for example, about whether the new libxl event
> sub-library would make any mistakes as a result of this proposed
> change.  I think it wouldn't...


If a client decides to use the same token for multiple path (including
one which is the sub-directory), it's not possible to know which
WATCH_EVENT we need to remove.

The current problem that the patch tries to resolve is mainly for
clients who use token with a pointer inside (as QEMU made).

Adding a flag to xs_open could be a good solution as:
#define XS_UNWATCH_SAFE 1UL<<2

If the flag is not enabled, xs_unwatch has the same (buggy?) behaviour
as before. When it's enabled, xs_unwatch will browse the watch list and
will remove spurious watch event.

What do you think?

Sincerely yours,

-- 
Julien Grall



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 26 16:32:38 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Sep 2012 16: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 1TGuX8-0005o8-V5; Wed, 26 Sep 2012 16:32: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 1TGuX7-0005o3-DS
	for xen-devel@lists.xensource.com; Wed, 26 Sep 2012 16:32:21 +0000
Received: from [85.158.143.99:20999] by server-3.bemta-4.messagelabs.com id
	04/F4-10986-41E23605; Wed, 26 Sep 2012 16:32:20 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1348677140!23691464!1
X-Originating-IP: [209.85.215.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7703 invoked from network); 26 Sep 2012 16:32:20 -0000
Received: from mail-ey0-f171.google.com (HELO mail-ey0-f171.google.com)
	(209.85.215.171)
	by server-2.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Sep 2012 16:32:20 -0000
Received: by eaah11 with SMTP id h11so318236eaa.30
	for <xen-devel@lists.xensource.com>;
	Wed, 26 Sep 2012 09:32:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
	bh=oaJMfELc/LQ6mZVVvHwHtdRzkfWufoMJc5Z1frb3Rz0=;
	b=1Da2lnrXLIr+w+fXYwZx4WNKBgRpfCJPv7+B7ERQwleaXdDHZ7pN48bqV7foczD3pl
	rk+EIPovIQjPKeTUgy5+LGeVNObB1vvQt3a8+WqmEngVH4I+8P3D/Xouv03sP+byVPXA
	avp+58DyhJmC+FuG0j4GT+jd1lfYTRO0gyLc0984oy6ukhADBki68N6BAYLVVDF/OJS1
	qdEV55cxQSEnCnlYnJcBYLlGFogAEozvW4E1r+H4y6Di1LyU6BiH234GQAUbMypB8hWx
	1/n0YOsOtrG/EeHrgit7s0mPMm3nSdalQQPgRT3Xbf6A1QQmPQQu/IqWe3wAWmTrECc+
	Ocmg==
MIME-Version: 1.0
Received: by 10.14.209.129 with SMTP id s1mr2286215eeo.24.1348677139854; Wed,
	26 Sep 2012 09:32:19 -0700 (PDT)
Received: by 10.14.215.195 with HTTP; Wed, 26 Sep 2012 09:32:19 -0700 (PDT)
In-Reply-To: <50632A9C.3030903@jhuapl.edu>
References: <505CBA02.5040308@jhuapl.edu>
	<1348569044.3452.176.camel@zakaz.uk.xensource.com>
	<5061E293.7000106@jhuapl.edu>
	<1348649549.19176.15.camel@zakaz.uk.xensource.com>
	<506310BA.9080202@jhuapl.edu> <506327BF.2080802@jhuapl.edu>
	<1348675717.19176.71.camel@zakaz.uk.xensource.com>
	<50632A9C.3030903@jhuapl.edu>
Date: Wed, 26 Sep 2012 17:32:19 +0100
X-Google-Sender-Auth: NnVh0ww8HYDxXJNS-8bIYc97Iz8
Message-ID: <CAFLBxZYG2EnsAFsz1jaAOmpkwFq8=hdESSwcWVhUTDesWr4gnQ@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] PATCH [base vtpm and libxl patches 4/6] add iomem
 support to 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

On Wed, Sep 26, 2012 at 5:17 PM, Matthew Fioravante
<matthew.fioravante@jhuapl.edu> wrote:
> Sigh.. its probably my email client. Anyway I'll fix them all and resubmit

It's definitely worth the effort to get the git patchbomb extension
set up. That makes all these mailer problems just disappear. :-)

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 26 16:32:38 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Sep 2012 16: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 1TGuX8-0005o8-V5; Wed, 26 Sep 2012 16:32: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 1TGuX7-0005o3-DS
	for xen-devel@lists.xensource.com; Wed, 26 Sep 2012 16:32:21 +0000
Received: from [85.158.143.99:20999] by server-3.bemta-4.messagelabs.com id
	04/F4-10986-41E23605; Wed, 26 Sep 2012 16:32:20 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1348677140!23691464!1
X-Originating-IP: [209.85.215.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7703 invoked from network); 26 Sep 2012 16:32:20 -0000
Received: from mail-ey0-f171.google.com (HELO mail-ey0-f171.google.com)
	(209.85.215.171)
	by server-2.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Sep 2012 16:32:20 -0000
Received: by eaah11 with SMTP id h11so318236eaa.30
	for <xen-devel@lists.xensource.com>;
	Wed, 26 Sep 2012 09:32:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
	bh=oaJMfELc/LQ6mZVVvHwHtdRzkfWufoMJc5Z1frb3Rz0=;
	b=1Da2lnrXLIr+w+fXYwZx4WNKBgRpfCJPv7+B7ERQwleaXdDHZ7pN48bqV7foczD3pl
	rk+EIPovIQjPKeTUgy5+LGeVNObB1vvQt3a8+WqmEngVH4I+8P3D/Xouv03sP+byVPXA
	avp+58DyhJmC+FuG0j4GT+jd1lfYTRO0gyLc0984oy6ukhADBki68N6BAYLVVDF/OJS1
	qdEV55cxQSEnCnlYnJcBYLlGFogAEozvW4E1r+H4y6Di1LyU6BiH234GQAUbMypB8hWx
	1/n0YOsOtrG/EeHrgit7s0mPMm3nSdalQQPgRT3Xbf6A1QQmPQQu/IqWe3wAWmTrECc+
	Ocmg==
MIME-Version: 1.0
Received: by 10.14.209.129 with SMTP id s1mr2286215eeo.24.1348677139854; Wed,
	26 Sep 2012 09:32:19 -0700 (PDT)
Received: by 10.14.215.195 with HTTP; Wed, 26 Sep 2012 09:32:19 -0700 (PDT)
In-Reply-To: <50632A9C.3030903@jhuapl.edu>
References: <505CBA02.5040308@jhuapl.edu>
	<1348569044.3452.176.camel@zakaz.uk.xensource.com>
	<5061E293.7000106@jhuapl.edu>
	<1348649549.19176.15.camel@zakaz.uk.xensource.com>
	<506310BA.9080202@jhuapl.edu> <506327BF.2080802@jhuapl.edu>
	<1348675717.19176.71.camel@zakaz.uk.xensource.com>
	<50632A9C.3030903@jhuapl.edu>
Date: Wed, 26 Sep 2012 17:32:19 +0100
X-Google-Sender-Auth: NnVh0ww8HYDxXJNS-8bIYc97Iz8
Message-ID: <CAFLBxZYG2EnsAFsz1jaAOmpkwFq8=hdESSwcWVhUTDesWr4gnQ@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] PATCH [base vtpm and libxl patches 4/6] add iomem
 support to 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

On Wed, Sep 26, 2012 at 5:17 PM, Matthew Fioravante
<matthew.fioravante@jhuapl.edu> wrote:
> Sigh.. its probably my email client. Anyway I'll fix them all and resubmit

It's definitely worth the effort to get the git patchbomb extension
set up. That makes all these mailer problems just disappear. :-)

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 26 17:16:18 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Sep 2012 17:16:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGvDI-0006LJ-Mf; Wed, 26 Sep 2012 17:15:56 +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 1TGvDG-0006LE-QG
	for xen-devel@lists.xen.org; Wed, 26 Sep 2012 17:15:55 +0000
Received: from [85.158.143.99:57077] by server-2.bemta-4.messagelabs.com id
	65/96-06610-A4833605; Wed, 26 Sep 2012 17:15:54 +0000
X-Env-Sender: msw@amazon.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1348679751!20646027!1
X-Originating-IP: [207.171.189.228]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA3LjE3MS4xODkuMjI4ID0+IDg0MzI2\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21062 invoked from network); 26 Sep 2012 17:15:53 -0000
Received: from smtp-fw-33001.amazon.com (HELO smtp-fw-33001.amazon.com)
	(207.171.189.228)
	by server-16.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Sep 2012 17:15:53 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=amazon.com; i=msw@amazon.com; q=dns/txt;
	s=amazon201209; t=1348679753; x=1380215753;
	h=date:from:to:cc:subject:message-id:references:
	mime-version:in-reply-to;
	bh=A9e70P9ke19C1L7FpPE/7lEAf4bVqGmcTW7WXWAzAlA=;
	b=pBtz8zsuGbwXBuflRopiRh36XU5TGYLHBBf9NhH0WujhFByyHOFgqzlw
	0mQvbDVWVEi/7en5o5OMTwFODoz3Ig+7/q2yCT0T3s4xrvnHjFhrAaKNa
	wTrGgOYfr3cPEu8cpmaBbP2XSCjbGDLu6xAf+2JkvXclAwZev59SkVv2T c=;
X-IronPort-AV: E=Sophos;i="4.80,492,1344211200"; d="scan'208";a="366651269"
Received: from smtp-in-9002.sea19.amazon.com ([10.186.174.20])
	by smtp-border-fw-out-33001.sea14.amazon.com with
	ESMTP/TLS/DHE-RSA-AES256-SHA; 26 Sep 2012 17:15:50 +0000
Received: from ex10-hub-9003.ant.amazon.com (ex10-hub-9003.ant.amazon.com
	[10.185.137.132])
	by smtp-in-9002.sea19.amazon.com (8.13.8/8.13.8) with ESMTP id
	q8QHFnKC022234
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL);
	Wed, 26 Sep 2012 17:15:49 GMT
Received: from u002268147cd4502c336d.ant.amazon.com (10.224.80.42) by
	ex10-hub-9003.ant.amazon.com (10.185.137.132) with Microsoft SMTP
	Server id 14.2.247.3; Wed, 26 Sep 2012 10:15:45 -0700
Received: by u002268147cd4502c336d.ant.amazon.com (sSMTP sendmail emulation); 
	Wed, 26 Sep 2012 10:15:42 -0700
Date: Wed, 26 Sep 2012 10:15:42 -0700
From: Matt Wilson <msw@amazon.com>
To: Thanos Makatos <thanos.makatos@citrix.com>
Message-ID: <20120926171540.GA24005@u002268147cd4502c336d.ant.amazon.com>
References: <CAFLBxZYtmJ_bKFb90r45=C4Pq1-oe5Fy=eygSsQf4BcGj3EqGA@mail.gmail.com>
	<505ADBCF020000780009C7BE@nat28.tlf.novell.com>
	<20120921031759.GA3953@u002268147cd4502c336d.ant.amazon.com>
	<5062CCA5.8010903@eu.citrix.com>
	<4B45B535F7F6BE4CB1C044ED5115CDDE011A6DD0105E@LONPMAILBOX01.citrite.net>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4B45B535F7F6BE4CB1C044ED5115CDDE011A6DD0105E@LONPMAILBOX01.citrite.net>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	Jan Beulich <JBeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.3 development 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, Sep 26, 2012 at 11:25:54AM +0100, Thanos Makatos wrote:
> > -----Original Message-----
> > From: George Dunlap [mailto:george.dunlap@eu.citrix.com]
> > Sent: 26 September 2012 10:37
> > To: Matt Wilson
> > Cc: Jan Beulich; xen-devel@lists.xen.org; Thanos Makatos
> > Subject: Re: [Xen-devel] Xen 4.3 development update
> > 
> > On 21/09/12 04:18, Matt Wilson wrote:
> > > On Thu, Sep 20, 2012 at 08:03:11AM +0100, Jan Beulich wrote:
> > >>> On 19.09.12 at 18:58, George Dunlap <George.Dunlap@eu.citrix.com>
> > wrote:
> > >>> * Persistent grants
> > >>>    owner: @citrix
> > >>>    status: ?
> > >> Isn't that a guest side only thing (i.e. not really to be tracked
> > >> here)? Or does that mean migrating active grants?
> > > I'd assume that the device would be renegotiated during migration,
> > and
> > > that new grants would be established during the re-connect sequence.
> > >
> > > One question I have is how persistent grants intersect with blktap3.
> > > Will a persistent grant-capable blktap3 implementation be in scope
> > for
> > > 4.3?
> > Thanos is working on blktap3 -- Thanos, can you comment?
> 
> Supporting this in 4.3 is not top priority; however I'll do it if I
> have time.

I brought this up in response to Jan's question as to if persistent
grants should be on the 4.3 release plan. With the introduction of
blktap3, we have a separate implementation of the protocol in a Xen
component. One worry I have about blktap3 is that it will lag behind
the in-kernel blkback implementation.

> > >>> * Multi-page blk rings
> > >>>   - blkback in kernel (konrad@oracle, ?@intel)
> > >> This part certainly is a guest side only thing (apart from the
> > >> interface definition living in the our tree).
> > > Same question here regarding blktap3.
> > And here.
> 
> I'm not sure I understand the question, blktap3 doesn't talk to
> blkback at all, but to blkfront directly -- are you referring to
> blkfront?

blktap3 would need to implement the new multi-page blk ring protocol,
correct?

Matt

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 26 17:16:18 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Sep 2012 17:16:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGvDI-0006LJ-Mf; Wed, 26 Sep 2012 17:15:56 +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 1TGvDG-0006LE-QG
	for xen-devel@lists.xen.org; Wed, 26 Sep 2012 17:15:55 +0000
Received: from [85.158.143.99:57077] by server-2.bemta-4.messagelabs.com id
	65/96-06610-A4833605; Wed, 26 Sep 2012 17:15:54 +0000
X-Env-Sender: msw@amazon.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1348679751!20646027!1
X-Originating-IP: [207.171.189.228]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA3LjE3MS4xODkuMjI4ID0+IDg0MzI2\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21062 invoked from network); 26 Sep 2012 17:15:53 -0000
Received: from smtp-fw-33001.amazon.com (HELO smtp-fw-33001.amazon.com)
	(207.171.189.228)
	by server-16.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Sep 2012 17:15:53 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=amazon.com; i=msw@amazon.com; q=dns/txt;
	s=amazon201209; t=1348679753; x=1380215753;
	h=date:from:to:cc:subject:message-id:references:
	mime-version:in-reply-to;
	bh=A9e70P9ke19C1L7FpPE/7lEAf4bVqGmcTW7WXWAzAlA=;
	b=pBtz8zsuGbwXBuflRopiRh36XU5TGYLHBBf9NhH0WujhFByyHOFgqzlw
	0mQvbDVWVEi/7en5o5OMTwFODoz3Ig+7/q2yCT0T3s4xrvnHjFhrAaKNa
	wTrGgOYfr3cPEu8cpmaBbP2XSCjbGDLu6xAf+2JkvXclAwZev59SkVv2T c=;
X-IronPort-AV: E=Sophos;i="4.80,492,1344211200"; d="scan'208";a="366651269"
Received: from smtp-in-9002.sea19.amazon.com ([10.186.174.20])
	by smtp-border-fw-out-33001.sea14.amazon.com with
	ESMTP/TLS/DHE-RSA-AES256-SHA; 26 Sep 2012 17:15:50 +0000
Received: from ex10-hub-9003.ant.amazon.com (ex10-hub-9003.ant.amazon.com
	[10.185.137.132])
	by smtp-in-9002.sea19.amazon.com (8.13.8/8.13.8) with ESMTP id
	q8QHFnKC022234
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL);
	Wed, 26 Sep 2012 17:15:49 GMT
Received: from u002268147cd4502c336d.ant.amazon.com (10.224.80.42) by
	ex10-hub-9003.ant.amazon.com (10.185.137.132) with Microsoft SMTP
	Server id 14.2.247.3; Wed, 26 Sep 2012 10:15:45 -0700
Received: by u002268147cd4502c336d.ant.amazon.com (sSMTP sendmail emulation); 
	Wed, 26 Sep 2012 10:15:42 -0700
Date: Wed, 26 Sep 2012 10:15:42 -0700
From: Matt Wilson <msw@amazon.com>
To: Thanos Makatos <thanos.makatos@citrix.com>
Message-ID: <20120926171540.GA24005@u002268147cd4502c336d.ant.amazon.com>
References: <CAFLBxZYtmJ_bKFb90r45=C4Pq1-oe5Fy=eygSsQf4BcGj3EqGA@mail.gmail.com>
	<505ADBCF020000780009C7BE@nat28.tlf.novell.com>
	<20120921031759.GA3953@u002268147cd4502c336d.ant.amazon.com>
	<5062CCA5.8010903@eu.citrix.com>
	<4B45B535F7F6BE4CB1C044ED5115CDDE011A6DD0105E@LONPMAILBOX01.citrite.net>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4B45B535F7F6BE4CB1C044ED5115CDDE011A6DD0105E@LONPMAILBOX01.citrite.net>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	Jan Beulich <JBeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.3 development 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, Sep 26, 2012 at 11:25:54AM +0100, Thanos Makatos wrote:
> > -----Original Message-----
> > From: George Dunlap [mailto:george.dunlap@eu.citrix.com]
> > Sent: 26 September 2012 10:37
> > To: Matt Wilson
> > Cc: Jan Beulich; xen-devel@lists.xen.org; Thanos Makatos
> > Subject: Re: [Xen-devel] Xen 4.3 development update
> > 
> > On 21/09/12 04:18, Matt Wilson wrote:
> > > On Thu, Sep 20, 2012 at 08:03:11AM +0100, Jan Beulich wrote:
> > >>> On 19.09.12 at 18:58, George Dunlap <George.Dunlap@eu.citrix.com>
> > wrote:
> > >>> * Persistent grants
> > >>>    owner: @citrix
> > >>>    status: ?
> > >> Isn't that a guest side only thing (i.e. not really to be tracked
> > >> here)? Or does that mean migrating active grants?
> > > I'd assume that the device would be renegotiated during migration,
> > and
> > > that new grants would be established during the re-connect sequence.
> > >
> > > One question I have is how persistent grants intersect with blktap3.
> > > Will a persistent grant-capable blktap3 implementation be in scope
> > for
> > > 4.3?
> > Thanos is working on blktap3 -- Thanos, can you comment?
> 
> Supporting this in 4.3 is not top priority; however I'll do it if I
> have time.

I brought this up in response to Jan's question as to if persistent
grants should be on the 4.3 release plan. With the introduction of
blktap3, we have a separate implementation of the protocol in a Xen
component. One worry I have about blktap3 is that it will lag behind
the in-kernel blkback implementation.

> > >>> * Multi-page blk rings
> > >>>   - blkback in kernel (konrad@oracle, ?@intel)
> > >> This part certainly is a guest side only thing (apart from the
> > >> interface definition living in the our tree).
> > > Same question here regarding blktap3.
> > And here.
> 
> I'm not sure I understand the question, blktap3 doesn't talk to
> blkback at all, but to blkfront directly -- are you referring to
> blkfront?

blktap3 would need to implement the new multi-page blk ring protocol,
correct?

Matt

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 26 17:43:56 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Sep 2012 17:43:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGvdy-0006fp-3v; Wed, 26 Sep 2012 17:43:30 +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 1TGvdw-0006fk-2F
	for xen-devel@lists.xensource.com; Wed, 26 Sep 2012 17:43:28 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1348681401!12494920!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTE1NzQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24621 invoked from network); 26 Sep 2012 17:43:21 -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 Sep 2012 17:43:21 -0000
X-IronPort-AV: E=Sophos;i="4.80,491,1344211200"; d="scan'208";a="14785313"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Sep 2012 17:43: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.279.1; Wed, 26 Sep 2012 18:43: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 1TGvdp-0003Mx-Cb;
	Wed, 26 Sep 2012 17:43:21 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1TGvdp-00011v-Ar;
	Wed, 26 Sep 2012 18:43:21 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <E1TGvdp-00011v-Ar@woking.cam.xci-test.com>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 26 Sep 2012 18:43:21 +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-i386-xl-credit2
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

branch xen-unstable
xen branch xen-unstable
job test-amd64-i386-xl-credit2
test xen-boot

Tree: linux git://xenbits.xen.org/linux-pvops.git
Tree: qemu git://xenbits.xen.org/staging/qemu-xen-unstable.git
Tree: qemuu git://xenbits.xen.org/staging/qemu-upstream-unstable.git
Tree: xen http://xenbits.xen.org/hg/staging/xen-unstable.hg

*** Found and reproduced problem changeset ***

  Bug is in tree:  xen http://xenbits.xen.org/hg/staging/xen-unstable.hg
  Bug introduced:  1e6e6b49b4ac
  Bug not present: 8eab91903e71


  changeset:   25935:1e6e6b49b4ac
  user:        Jan Beulich <jbeulich@suse.com>
  date:        Fri Sep 21 13:47:18 2012 +0200
      
      x86: introduce MWAIT-based, ACPI-less CPU idle driver
      
      This is a port of Linux'es intel-idle driver serving the same purpose.
      
      Signed-off-by: Jan Beulich <jbeulich@suse.com>
      Acked-by: Keir Fraser <keir@xen.org>
      
      


For bisection revision-tuple graph see:
   http://www.chiark.greenend.org.uk/~xensrcts/results/bisect.xen-unstable.test-amd64-i386-xl-credit2.xen-boot.html
Revision IDs in each graph node refer, respectively, to the Trees above.

----------------------------------------
Searching for failure / basis pass:
 13869 fail [host=gall-mite] / 13827 [host=potato-beetle] 13823 [host=itch-mite] 13821 [host=leaf-beetle] 13819 [host=potato-beetle] 13816 [host=moss-bug] 13812 [host=field-cricket] 13809 [host=earwig] 13805 [host=lace-bug] 13802 ok.
Failure / basis pass flights: 13869 / 13802
Tree: linux git://xenbits.xen.org/linux-pvops.git
Tree: qemu git://xenbits.xen.org/staging/qemu-xen-unstable.git
Tree: qemuu git://xenbits.xen.org/staging/qemu-upstream-unstable.git
Tree: xen http://xenbits.xen.org/hg/staging/xen-unstable.hg
Latest a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 656662f7ea59
Basis pass a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 d1c3375c3f11
Generating revisions with ./adhoc-revtuple-generator  git://xenbits.xen.org/linux-pvops.git#a938a246d34912423c560f475ccf1ce0c71d9d00-a938a246d34912423c560f475ccf1ce0c71d9d00 git://xenbits.xen.org/staging/qemu-xen-unstable.git#bacc0d302445c75f18f4c826750fb5853b60e7ca-bacc0d302445c75f18f4c826750fb5853b60e7ca git://xenbits.xen.org/staging/qemu-upstream-unstable.git#cdf4d2bb4006805f209712fbb8ed1f83127e9984-cdf4d2bb4006805f209712fbb8ed1f83127e9984 http://xenbits.xen.org/hg/staging/xen-unstable.hg#d1c3375c3f11-656662f7ea59
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 125 nodes in revision graph
Searching for test results:
 13805 [host=lace-bug]
 13809 [host=earwig]
 13827 [host=potato-beetle]
 13812 [host=field-cricket]
 13801 [host=leaf-beetle]
 13816 [host=moss-bug]
 13802 pass a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 d1c3375c3f11
 13819 [host=potato-beetle]
 13821 [host=leaf-beetle]
 13823 [host=itch-mite]
 13841 fail a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 8f658b463b78
 13870 pass a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 d1c3375c3f11
 13872 pass a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 149805919569
 13877 pass a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 8eab91903e71
 13871 fail a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 8f658b463b78
 13874 pass a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 8eab91903e71
 13876 fail a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 1e6e6b49b4ac
 13875 fail a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 c8873f13cec3
 13869 fail a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 656662f7ea59
 13881 pass a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 8eab91903e71
 13879 fail a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 656662f7ea59
 13880 fail a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 1e6e6b49b4ac
 13882 fail a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 1e6e6b49b4ac
Searching for interesting versions
 Result found: flight 13802 (pass), for basis pass
 Result found: flight 13869 (fail), for basis failure
 Repro found: flight 13870 (pass), for basis pass
 Repro found: flight 13879 (fail), for basis failure
 0 revisions at a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 8eab91903e71
No revisions left to test, checking graph state.
 Result found: flight 13874 (pass), for last pass
 Result found: flight 13876 (fail), for first failure
 Repro found: flight 13877 (pass), for last pass
 Repro found: flight 13880 (fail), for first failure
 Repro found: flight 13881 (pass), for last pass
 Repro found: flight 13882 (fail), for first failure

*** Found and reproduced problem changeset ***

  Bug is in tree:  xen http://xenbits.xen.org/hg/staging/xen-unstable.hg
  Bug introduced:  1e6e6b49b4ac
  Bug not present: 8eab91903e71

pulling from ssh://xen@xenbits.xen.org/HG/staging/xen-unstable.hg
searching for changes
no changes found

  changeset:   25935:1e6e6b49b4ac
  user:        Jan Beulich <jbeulich@suse.com>
  date:        Fri Sep 21 13:47:18 2012 +0200
      
      x86: introduce MWAIT-based, ACPI-less CPU idle driver
      
      This is a port of Linux'es intel-idle driver serving the same purpose.
      
      Signed-off-by: Jan Beulich <jbeulich@suse.com>
      Acked-by: Keir Fraser <keir@xen.org>
      
      

Revision graph left in /home/xc_osstest/results/bisect.xen-unstable.test-amd64-i386-xl-credit2.xen-boot.{dot,ps,png,html}.
----------------------------------------
13882: tolerable ALL FAIL

flight 13882 xen-unstable real-bisect [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13882/

Failures :-/ but no regressions.

Tests which did not succeed,
including tests which could not be run:
 test-amd64-i386-xl-credit2    5 xen-boot                fail baseline untested


jobs:
 test-amd64-i386-xl-credit2                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 26 17:43:56 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Sep 2012 17:43:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGvdy-0006fp-3v; Wed, 26 Sep 2012 17:43:30 +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 1TGvdw-0006fk-2F
	for xen-devel@lists.xensource.com; Wed, 26 Sep 2012 17:43:28 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1348681401!12494920!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTE1NzQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24621 invoked from network); 26 Sep 2012 17:43:21 -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 Sep 2012 17:43:21 -0000
X-IronPort-AV: E=Sophos;i="4.80,491,1344211200"; d="scan'208";a="14785313"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Sep 2012 17:43: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.279.1; Wed, 26 Sep 2012 18:43: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 1TGvdp-0003Mx-Cb;
	Wed, 26 Sep 2012 17:43:21 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1TGvdp-00011v-Ar;
	Wed, 26 Sep 2012 18:43:21 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <E1TGvdp-00011v-Ar@woking.cam.xci-test.com>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 26 Sep 2012 18:43:21 +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-i386-xl-credit2
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

branch xen-unstable
xen branch xen-unstable
job test-amd64-i386-xl-credit2
test xen-boot

Tree: linux git://xenbits.xen.org/linux-pvops.git
Tree: qemu git://xenbits.xen.org/staging/qemu-xen-unstable.git
Tree: qemuu git://xenbits.xen.org/staging/qemu-upstream-unstable.git
Tree: xen http://xenbits.xen.org/hg/staging/xen-unstable.hg

*** Found and reproduced problem changeset ***

  Bug is in tree:  xen http://xenbits.xen.org/hg/staging/xen-unstable.hg
  Bug introduced:  1e6e6b49b4ac
  Bug not present: 8eab91903e71


  changeset:   25935:1e6e6b49b4ac
  user:        Jan Beulich <jbeulich@suse.com>
  date:        Fri Sep 21 13:47:18 2012 +0200
      
      x86: introduce MWAIT-based, ACPI-less CPU idle driver
      
      This is a port of Linux'es intel-idle driver serving the same purpose.
      
      Signed-off-by: Jan Beulich <jbeulich@suse.com>
      Acked-by: Keir Fraser <keir@xen.org>
      
      


For bisection revision-tuple graph see:
   http://www.chiark.greenend.org.uk/~xensrcts/results/bisect.xen-unstable.test-amd64-i386-xl-credit2.xen-boot.html
Revision IDs in each graph node refer, respectively, to the Trees above.

----------------------------------------
Searching for failure / basis pass:
 13869 fail [host=gall-mite] / 13827 [host=potato-beetle] 13823 [host=itch-mite] 13821 [host=leaf-beetle] 13819 [host=potato-beetle] 13816 [host=moss-bug] 13812 [host=field-cricket] 13809 [host=earwig] 13805 [host=lace-bug] 13802 ok.
Failure / basis pass flights: 13869 / 13802
Tree: linux git://xenbits.xen.org/linux-pvops.git
Tree: qemu git://xenbits.xen.org/staging/qemu-xen-unstable.git
Tree: qemuu git://xenbits.xen.org/staging/qemu-upstream-unstable.git
Tree: xen http://xenbits.xen.org/hg/staging/xen-unstable.hg
Latest a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 656662f7ea59
Basis pass a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 d1c3375c3f11
Generating revisions with ./adhoc-revtuple-generator  git://xenbits.xen.org/linux-pvops.git#a938a246d34912423c560f475ccf1ce0c71d9d00-a938a246d34912423c560f475ccf1ce0c71d9d00 git://xenbits.xen.org/staging/qemu-xen-unstable.git#bacc0d302445c75f18f4c826750fb5853b60e7ca-bacc0d302445c75f18f4c826750fb5853b60e7ca git://xenbits.xen.org/staging/qemu-upstream-unstable.git#cdf4d2bb4006805f209712fbb8ed1f83127e9984-cdf4d2bb4006805f209712fbb8ed1f83127e9984 http://xenbits.xen.org/hg/staging/xen-unstable.hg#d1c3375c3f11-656662f7ea59
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 125 nodes in revision graph
Searching for test results:
 13805 [host=lace-bug]
 13809 [host=earwig]
 13827 [host=potato-beetle]
 13812 [host=field-cricket]
 13801 [host=leaf-beetle]
 13816 [host=moss-bug]
 13802 pass a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 d1c3375c3f11
 13819 [host=potato-beetle]
 13821 [host=leaf-beetle]
 13823 [host=itch-mite]
 13841 fail a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 8f658b463b78
 13870 pass a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 d1c3375c3f11
 13872 pass a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 149805919569
 13877 pass a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 8eab91903e71
 13871 fail a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 8f658b463b78
 13874 pass a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 8eab91903e71
 13876 fail a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 1e6e6b49b4ac
 13875 fail a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 c8873f13cec3
 13869 fail a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 656662f7ea59
 13881 pass a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 8eab91903e71
 13879 fail a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 656662f7ea59
 13880 fail a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 1e6e6b49b4ac
 13882 fail a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 1e6e6b49b4ac
Searching for interesting versions
 Result found: flight 13802 (pass), for basis pass
 Result found: flight 13869 (fail), for basis failure
 Repro found: flight 13870 (pass), for basis pass
 Repro found: flight 13879 (fail), for basis failure
 0 revisions at a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 8eab91903e71
No revisions left to test, checking graph state.
 Result found: flight 13874 (pass), for last pass
 Result found: flight 13876 (fail), for first failure
 Repro found: flight 13877 (pass), for last pass
 Repro found: flight 13880 (fail), for first failure
 Repro found: flight 13881 (pass), for last pass
 Repro found: flight 13882 (fail), for first failure

*** Found and reproduced problem changeset ***

  Bug is in tree:  xen http://xenbits.xen.org/hg/staging/xen-unstable.hg
  Bug introduced:  1e6e6b49b4ac
  Bug not present: 8eab91903e71

pulling from ssh://xen@xenbits.xen.org/HG/staging/xen-unstable.hg
searching for changes
no changes found

  changeset:   25935:1e6e6b49b4ac
  user:        Jan Beulich <jbeulich@suse.com>
  date:        Fri Sep 21 13:47:18 2012 +0200
      
      x86: introduce MWAIT-based, ACPI-less CPU idle driver
      
      This is a port of Linux'es intel-idle driver serving the same purpose.
      
      Signed-off-by: Jan Beulich <jbeulich@suse.com>
      Acked-by: Keir Fraser <keir@xen.org>
      
      

Revision graph left in /home/xc_osstest/results/bisect.xen-unstable.test-amd64-i386-xl-credit2.xen-boot.{dot,ps,png,html}.
----------------------------------------
13882: tolerable ALL FAIL

flight 13882 xen-unstable real-bisect [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13882/

Failures :-/ but no regressions.

Tests which did not succeed,
including tests which could not be run:
 test-amd64-i386-xl-credit2    5 xen-boot                fail baseline untested


jobs:
 test-amd64-i386-xl-credit2                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 26 18:16:00 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Sep 2012 18: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 1TGw98-00078W-Fk; Wed, 26 Sep 2012 18:15:42 +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 1TGw96-00077g-C1
	for xen-devel@lists.xen.org; Wed, 26 Sep 2012 18:15:40 +0000
Received: from [85.158.143.99:18733] by server-2.bemta-4.messagelabs.com id
	65/BB-06610-B4643605; Wed, 26 Sep 2012 18:15:39 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1348683336!31551611!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNzc3MDY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32574 invoked from network); 26 Sep 2012 18:15:38 -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;
	26 Sep 2012 18:15:38 -0000
X-IronPort-AV: E=Sophos;i="4.80,491,1344211200"; d="scan'208";a="209449518"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Sep 2012 18:15:36 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 26 Sep 2012 14:15:35 -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 1TGw91-0001cN-DI;
	Wed, 26 Sep 2012 19:15:35 +0100
From: Anthony PERARD <anthony.perard@citrix.com>
To: Xen Devel <xen-devel@lists.xen.org>
Date: Wed, 26 Sep 2012 19:15:16 +0100
Message-ID: <1348683325-12367-2-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.12.1
In-Reply-To: <1348683325-12367-1-git-send-email-anthony.perard@citrix.com>
References: <1348683325-12367-1-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Cc: Anthony PERARD <anthony.perard@citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH V3 01/10] libxl_json: Export json_object related
	function.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Export libxl__json_object_alloc and libxl__json_object_append_to to use them in
a later patch.

Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/libxl/libxl_internal.h |  8 ++++++++
 tools/libxl/libxl_json.c     | 34 +++++++++++++++++-----------------
 2 files changed, 25 insertions(+), 17 deletions(-)

diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 55fa771..f69f58d 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -1511,6 +1511,14 @@ static inline long long libxl__json_object_get_integer(const libxl__json_object
         return -1;
 }
 
+/* Objects allocated using this function must be free with
+ * libxl__json_object_free.
+ */
+_hidden libxl__json_object *libxl__json_object_alloc(libxl__gc *gc,
+                                                     libxl__json_node_type type);
+_hidden int libxl__json_object_append_to(libxl__gc *gc,
+                                         libxl__json_object *obj,
+                                         libxl__json_object *dst);
 _hidden libxl__json_object *libxl__json_array_get(const libxl__json_object *o,
                                                   int i);
 _hidden
diff --git a/tools/libxl/libxl_json.c b/tools/libxl/libxl_json.c
index 52fed51..30b2980 100644
--- a/tools/libxl/libxl_json.c
+++ b/tools/libxl/libxl_json.c
@@ -205,7 +205,7 @@ yajl_gen_status libxl__string_gen_json(yajl_gen hand,
  * libxl__json_object helper functions
  */
 
-static libxl__json_object *json_object_alloc(libxl__gc *gc,
+libxl__json_object *libxl__json_object_alloc(libxl__gc *gc,
                                              libxl__json_node_type type)
 {
     libxl__json_object *obj;
@@ -225,7 +225,7 @@ static libxl__json_object *json_object_alloc(libxl__gc *gc,
     return obj;
 }
 
-static int json_object_append_to(libxl__gc *gc,
+int libxl__json_object_append_to(libxl__gc *gc,
                                  libxl__json_object *obj,
                                  libxl__json_object *dst)
 {
@@ -334,9 +334,9 @@ static int json_callback_null(void *opaque)
 
     DEBUG_GEN(ctx, null);
 
-    obj = json_object_alloc(ctx->gc, JSON_NULL);
+    obj = libxl__json_object_alloc(ctx->gc, JSON_NULL);
 
-    if (json_object_append_to(ctx->gc, obj, ctx->current) == -1) {
+    if (libxl__json_object_append_to(ctx->gc, obj, ctx->current) == -1) {
         return 0;
     }
 
@@ -350,10 +350,10 @@ static int json_callback_boolean(void *opaque, int boolean)
 
     DEBUG_GEN_VALUE(ctx, bool, boolean);
 
-    obj = json_object_alloc(ctx->gc,
-                            boolean ? JSON_TRUE : JSON_FALSE);
+    obj = libxl__json_object_alloc(ctx->gc,
+                                   boolean ? JSON_TRUE : JSON_FALSE);
 
-    if (json_object_append_to(ctx->gc, obj, ctx->current) == -1) {
+    if (libxl__json_object_append_to(ctx->gc, obj, ctx->current) == -1) {
         return 0;
     }
 
@@ -385,7 +385,7 @@ static int json_callback_number(void *opaque, const char *s, libxl_yajl_length l
             goto error;
         }
 
-        obj = json_object_alloc(ctx->gc, JSON_DOUBLE);
+        obj = libxl__json_object_alloc(ctx->gc, JSON_DOUBLE);
         obj->u.d = d;
     } else {
         long long i = strtoll(s, NULL, 10);
@@ -394,14 +394,14 @@ static int json_callback_number(void *opaque, const char *s, libxl_yajl_length l
             goto error;
         }
 
-        obj = json_object_alloc(ctx->gc, JSON_INTEGER);
+        obj = libxl__json_object_alloc(ctx->gc, JSON_INTEGER);
         obj->u.i = i;
     }
     goto out;
 
 error:
     /* If the conversion fail, we just store the original string. */
-    obj = json_object_alloc(ctx->gc, JSON_NUMBER);
+    obj = libxl__json_object_alloc(ctx->gc, JSON_NUMBER);
 
     t = libxl__zalloc(ctx->gc, len + 1);
     strncpy(t, s, len);
@@ -410,7 +410,7 @@ error:
     obj->u.string = t;
 
 out:
-    if (json_object_append_to(ctx->gc, obj, ctx->current) == -1) {
+    if (libxl__json_object_append_to(ctx->gc, obj, ctx->current) == -1) {
         return 0;
     }
 
@@ -431,10 +431,10 @@ static int json_callback_string(void *opaque, const unsigned char *str,
     strncpy(t, (const char *) str, len);
     t[len] = 0;
 
-    obj = json_object_alloc(ctx->gc, JSON_STRING);
+    obj = libxl__json_object_alloc(ctx->gc, JSON_STRING);
     obj->u.string = t;
 
-    if (json_object_append_to(ctx->gc, obj, ctx->current) == -1) {
+    if (libxl__json_object_append_to(ctx->gc, obj, ctx->current) == -1) {
         return 0;
     }
 
@@ -480,10 +480,10 @@ static int json_callback_start_map(void *opaque)
 
     DEBUG_GEN(ctx, map_open);
 
-    obj = json_object_alloc(ctx->gc, JSON_MAP);
+    obj = libxl__json_object_alloc(ctx->gc, JSON_MAP);
 
     if (ctx->current) {
-        if (json_object_append_to(ctx->gc, obj, ctx->current) == -1) {
+        if (libxl__json_object_append_to(ctx->gc, obj, ctx->current) == -1) {
             return 0;
         }
     }
@@ -520,10 +520,10 @@ static int json_callback_start_array(void *opaque)
 
     DEBUG_GEN(ctx, array_open);
 
-    obj = json_object_alloc(ctx->gc, JSON_ARRAY);
+    obj = libxl__json_object_alloc(ctx->gc, JSON_ARRAY);
 
     if (ctx->current) {
-        if (json_object_append_to(ctx->gc, obj, ctx->current) == -1) {
+        if (libxl__json_object_append_to(ctx->gc, obj, ctx->current) == -1) {
             return 0;
         }
     }
-- 
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 Sep 26 18:16:00 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Sep 2012 18: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 1TGw98-00078W-Fk; Wed, 26 Sep 2012 18:15:42 +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 1TGw96-00077g-C1
	for xen-devel@lists.xen.org; Wed, 26 Sep 2012 18:15:40 +0000
Received: from [85.158.143.99:18733] by server-2.bemta-4.messagelabs.com id
	65/BB-06610-B4643605; Wed, 26 Sep 2012 18:15:39 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1348683336!31551611!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNzc3MDY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32574 invoked from network); 26 Sep 2012 18:15:38 -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;
	26 Sep 2012 18:15:38 -0000
X-IronPort-AV: E=Sophos;i="4.80,491,1344211200"; d="scan'208";a="209449518"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Sep 2012 18:15:36 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 26 Sep 2012 14:15:35 -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 1TGw91-0001cN-DI;
	Wed, 26 Sep 2012 19:15:35 +0100
From: Anthony PERARD <anthony.perard@citrix.com>
To: Xen Devel <xen-devel@lists.xen.org>
Date: Wed, 26 Sep 2012 19:15:16 +0100
Message-ID: <1348683325-12367-2-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.12.1
In-Reply-To: <1348683325-12367-1-git-send-email-anthony.perard@citrix.com>
References: <1348683325-12367-1-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Cc: Anthony PERARD <anthony.perard@citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH V3 01/10] libxl_json: Export json_object related
	function.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Export libxl__json_object_alloc and libxl__json_object_append_to to use them in
a later patch.

Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/libxl/libxl_internal.h |  8 ++++++++
 tools/libxl/libxl_json.c     | 34 +++++++++++++++++-----------------
 2 files changed, 25 insertions(+), 17 deletions(-)

diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 55fa771..f69f58d 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -1511,6 +1511,14 @@ static inline long long libxl__json_object_get_integer(const libxl__json_object
         return -1;
 }
 
+/* Objects allocated using this function must be free with
+ * libxl__json_object_free.
+ */
+_hidden libxl__json_object *libxl__json_object_alloc(libxl__gc *gc,
+                                                     libxl__json_node_type type);
+_hidden int libxl__json_object_append_to(libxl__gc *gc,
+                                         libxl__json_object *obj,
+                                         libxl__json_object *dst);
 _hidden libxl__json_object *libxl__json_array_get(const libxl__json_object *o,
                                                   int i);
 _hidden
diff --git a/tools/libxl/libxl_json.c b/tools/libxl/libxl_json.c
index 52fed51..30b2980 100644
--- a/tools/libxl/libxl_json.c
+++ b/tools/libxl/libxl_json.c
@@ -205,7 +205,7 @@ yajl_gen_status libxl__string_gen_json(yajl_gen hand,
  * libxl__json_object helper functions
  */
 
-static libxl__json_object *json_object_alloc(libxl__gc *gc,
+libxl__json_object *libxl__json_object_alloc(libxl__gc *gc,
                                              libxl__json_node_type type)
 {
     libxl__json_object *obj;
@@ -225,7 +225,7 @@ static libxl__json_object *json_object_alloc(libxl__gc *gc,
     return obj;
 }
 
-static int json_object_append_to(libxl__gc *gc,
+int libxl__json_object_append_to(libxl__gc *gc,
                                  libxl__json_object *obj,
                                  libxl__json_object *dst)
 {
@@ -334,9 +334,9 @@ static int json_callback_null(void *opaque)
 
     DEBUG_GEN(ctx, null);
 
-    obj = json_object_alloc(ctx->gc, JSON_NULL);
+    obj = libxl__json_object_alloc(ctx->gc, JSON_NULL);
 
-    if (json_object_append_to(ctx->gc, obj, ctx->current) == -1) {
+    if (libxl__json_object_append_to(ctx->gc, obj, ctx->current) == -1) {
         return 0;
     }
 
@@ -350,10 +350,10 @@ static int json_callback_boolean(void *opaque, int boolean)
 
     DEBUG_GEN_VALUE(ctx, bool, boolean);
 
-    obj = json_object_alloc(ctx->gc,
-                            boolean ? JSON_TRUE : JSON_FALSE);
+    obj = libxl__json_object_alloc(ctx->gc,
+                                   boolean ? JSON_TRUE : JSON_FALSE);
 
-    if (json_object_append_to(ctx->gc, obj, ctx->current) == -1) {
+    if (libxl__json_object_append_to(ctx->gc, obj, ctx->current) == -1) {
         return 0;
     }
 
@@ -385,7 +385,7 @@ static int json_callback_number(void *opaque, const char *s, libxl_yajl_length l
             goto error;
         }
 
-        obj = json_object_alloc(ctx->gc, JSON_DOUBLE);
+        obj = libxl__json_object_alloc(ctx->gc, JSON_DOUBLE);
         obj->u.d = d;
     } else {
         long long i = strtoll(s, NULL, 10);
@@ -394,14 +394,14 @@ static int json_callback_number(void *opaque, const char *s, libxl_yajl_length l
             goto error;
         }
 
-        obj = json_object_alloc(ctx->gc, JSON_INTEGER);
+        obj = libxl__json_object_alloc(ctx->gc, JSON_INTEGER);
         obj->u.i = i;
     }
     goto out;
 
 error:
     /* If the conversion fail, we just store the original string. */
-    obj = json_object_alloc(ctx->gc, JSON_NUMBER);
+    obj = libxl__json_object_alloc(ctx->gc, JSON_NUMBER);
 
     t = libxl__zalloc(ctx->gc, len + 1);
     strncpy(t, s, len);
@@ -410,7 +410,7 @@ error:
     obj->u.string = t;
 
 out:
-    if (json_object_append_to(ctx->gc, obj, ctx->current) == -1) {
+    if (libxl__json_object_append_to(ctx->gc, obj, ctx->current) == -1) {
         return 0;
     }
 
@@ -431,10 +431,10 @@ static int json_callback_string(void *opaque, const unsigned char *str,
     strncpy(t, (const char *) str, len);
     t[len] = 0;
 
-    obj = json_object_alloc(ctx->gc, JSON_STRING);
+    obj = libxl__json_object_alloc(ctx->gc, JSON_STRING);
     obj->u.string = t;
 
-    if (json_object_append_to(ctx->gc, obj, ctx->current) == -1) {
+    if (libxl__json_object_append_to(ctx->gc, obj, ctx->current) == -1) {
         return 0;
     }
 
@@ -480,10 +480,10 @@ static int json_callback_start_map(void *opaque)
 
     DEBUG_GEN(ctx, map_open);
 
-    obj = json_object_alloc(ctx->gc, JSON_MAP);
+    obj = libxl__json_object_alloc(ctx->gc, JSON_MAP);
 
     if (ctx->current) {
-        if (json_object_append_to(ctx->gc, obj, ctx->current) == -1) {
+        if (libxl__json_object_append_to(ctx->gc, obj, ctx->current) == -1) {
             return 0;
         }
     }
@@ -520,10 +520,10 @@ static int json_callback_start_array(void *opaque)
 
     DEBUG_GEN(ctx, array_open);
 
-    obj = json_object_alloc(ctx->gc, JSON_ARRAY);
+    obj = libxl__json_object_alloc(ctx->gc, JSON_ARRAY);
 
     if (ctx->current) {
-        if (json_object_append_to(ctx->gc, obj, ctx->current) == -1) {
+        if (libxl__json_object_append_to(ctx->gc, obj, ctx->current) == -1) {
             return 0;
         }
     }
-- 
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 Sep 26 18:16:00 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Sep 2012 18: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 1TGw97-000787-2v; Wed, 26 Sep 2012 18:15:41 +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 1TGw95-00077b-Q7
	for xen-devel@lists.xen.org; Wed, 26 Sep 2012 18:15:39 +0000
Received: from [85.158.143.99:18707] by server-1.bemta-4.messagelabs.com id
	36/16-05684-B4643605; Wed, 26 Sep 2012 18:15:39 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1348683336!24884357!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzE2MjI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15517 invoked from network); 26 Sep 2012 18:15:38 -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;
	26 Sep 2012 18:15:38 -0000
X-IronPort-AV: E=Sophos;i="4.80,491,1344211200"; d="scan'208";a="39270292"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Sep 2012 18:15:36 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 26 Sep 2012 14:15:36 -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 1TGw92-0001cN-0g;
	Wed, 26 Sep 2012 19:15:36 +0100
From: Anthony PERARD <anthony.perard@citrix.com>
To: Xen Devel <xen-devel@lists.xen.org>
Date: Wed, 26 Sep 2012 19:15:19 +0100
Message-ID: <1348683325-12367-5-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.12.1
In-Reply-To: <1348683325-12367-1-git-send-email-anthony.perard@citrix.com>
References: <1348683325-12367-1-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Cc: Anthony PERARD <anthony.perard@citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH V3 04/10] libxl_json: Introduce
	libxl__json_object_to_yajl_gen.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This function converts a libxl__json_object to yajl by calling every yajl_gen_*
function on a preallocated yajl_gen hand.

This helps to integrate a json_object into an already existing yajl_gen tree.

This function is used in a later patch.

Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
 tools/libxl/libxl_internal.h |  3 +++
 tools/libxl/libxl_json.c     | 61 ++++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 64 insertions(+)

diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 5604256..bf888ee 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -1537,6 +1537,9 @@ libxl__json_map_node *libxl__json_map_node_get(const libxl__json_object *o,
 _hidden const libxl__json_object *libxl__json_map_get(const char *key,
                                           const libxl__json_object *o,
                                           libxl__json_node_type expected_type);
+_hidden yajl_status libxl__json_object_to_yajl_gen(libxl__gc *gc,
+                                                   yajl_gen hand,
+                                                   libxl__json_object *param);
 
 _hidden libxl__json_object *libxl__json_parse(libxl__gc *gc, const char *s);
 
diff --git a/tools/libxl/libxl_json.c b/tools/libxl/libxl_json.c
index 34fd8c7..3d74046 100644
--- a/tools/libxl/libxl_json.c
+++ b/tools/libxl/libxl_json.c
@@ -322,6 +322,67 @@ const libxl__json_object *libxl__json_map_get(const char *key,
     return NULL;
 }
 
+yajl_status libxl__json_object_to_yajl_gen(libxl__gc *gc,
+                                           yajl_gen hand,
+                                           libxl__json_object *obj)
+{
+    int index = 0;
+    yajl_status rc;
+
+    switch (obj->type) {
+    case JSON_NULL:
+        return yajl_gen_null(hand);
+    case JSON_BOOL:
+        return yajl_gen_bool(hand, obj->u.b);
+    case JSON_INTEGER:
+        return yajl_gen_integer(hand, obj->u.i);
+    case JSON_DOUBLE:
+        return yajl_gen_double(hand, obj->u.d);
+    case JSON_NUMBER:
+        return yajl_gen_number(hand, obj->u.string, strlen(obj->u.string));
+    case JSON_STRING:
+        return libxl__yajl_gen_asciiz(hand, obj->u.string);
+    case JSON_MAP: {
+        libxl__json_map_node *node = NULL;
+
+        rc = yajl_gen_map_open(hand);
+        if (rc != yajl_status_ok)
+            return rc;
+        for (index = 0; index < obj->u.map->count; index++) {
+            if (flexarray_get(obj->u.map, index, (void**)&node) != 0)
+                break;
+
+            rc = libxl__yajl_gen_asciiz(hand, node->map_key);
+            if (rc != yajl_status_ok)
+                return rc;
+            rc = libxl__json_object_to_yajl_gen(gc, hand, node->obj);
+            if (rc != yajl_status_ok)
+                return rc;
+        }
+        return yajl_gen_map_close(hand);
+    }
+    case JSON_ARRAY: {
+        libxl__json_object *node = NULL;
+
+        rc = yajl_gen_array_open(hand);
+        if (rc != yajl_status_ok)
+            return rc;
+        for (index = 0; index < obj->u.array->count; index++) {
+            if (flexarray_get(obj->u.array, index, (void**)&node) != 0)
+                break;
+            rc = libxl__json_object_to_yajl_gen(gc, hand, node);
+            if (rc != yajl_status_ok)
+                return rc;
+        }
+        return yajl_gen_array_close(hand);
+    }
+    case JSON_ANY:
+        /* JSON_ANY is not a valid value for obj->type. */
+        ;
+    }
+    abort();
+}
+
 
 /*
  * JSON callbacks
-- 
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 Sep 26 18:16:00 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Sep 2012 18: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 1TGw99-000799-PH; Wed, 26 Sep 2012 18:15:43 +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 1TGw97-00077b-9L
	for xen-devel@lists.xen.org; Wed, 26 Sep 2012 18:15:41 +0000
Received: from [85.158.143.99:15810] by server-1.bemta-4.messagelabs.com id
	0B/16-05684-D4643605; Wed, 26 Sep 2012 18:15:41 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1348683336!31551611!4
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNzc3MDY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32623 invoked from network); 26 Sep 2012 18:15:40 -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;
	26 Sep 2012 18:15:40 -0000
X-IronPort-AV: E=Sophos;i="4.80,491,1344211200"; d="scan'208";a="209449524"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Sep 2012 18:15:36 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 26 Sep 2012 14:15:36 -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 1TGw92-0001cN-By;
	Wed, 26 Sep 2012 19:15:36 +0100
From: Anthony PERARD <anthony.perard@citrix.com>
To: Xen Devel <xen-devel@lists.xen.org>
Date: Wed, 26 Sep 2012 19:15:23 +0100
Message-ID: <1348683325-12367-9-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.12.1
In-Reply-To: <1348683325-12367-1-git-send-email-anthony.perard@citrix.com>
References: <1348683325-12367-1-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Cc: Anthony PERARD <anthony.perard@citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH V3 08/10] libxl_qmp: Introduce
	libxl__qmp_set_global_dirty_log.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This function will enable or disable the global dirty log on QEMU, used during
a migration.

Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/libxl/libxl_internal.h |  2 ++
 tools/libxl/libxl_qmp.c      | 12 ++++++++++--
 2 files changed, 12 insertions(+), 2 deletions(-)

diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index bf888ee..8950ea5 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -1399,6 +1399,8 @@ _hidden int libxl__qmp_stop(libxl__gc *gc, int domid);
 _hidden int libxl__qmp_resume(libxl__gc *gc, int domid);
 /* Save current QEMU state into fd. */
 _hidden int libxl__qmp_save(libxl__gc *gc, int domid, const char *filename);
+/* Set dirty bitmap logging status */
+_hidden int libxl__qmp_set_global_dirty_log(libxl__gc *gc, int domid, bool enable);
 /* close and free the QMP handler */
 _hidden void libxl__qmp_close(libxl__qmp_handler *qmp);
 /* remove the socket file, if the file has already been removed,
diff --git a/tools/libxl/libxl_qmp.c b/tools/libxl/libxl_qmp.c
index 7bf56a7..5fa0c65 100644
--- a/tools/libxl/libxl_qmp.c
+++ b/tools/libxl/libxl_qmp.c
@@ -657,7 +657,6 @@ static void qmp_parameters_add_string(libxl__gc *gc,
     qmp_parameters_common_add(gc, param, name, obj);
 }
 
-#if 0
 static void qmp_parameters_add_bool(libxl__gc *gc,
                                     libxl__json_object **param,
                                     const char *name, bool b)
@@ -668,7 +667,6 @@ static void qmp_parameters_add_bool(libxl__gc *gc,
     obj->u.b = b;
     qmp_parameters_common_add(gc, param, name, obj);
 }
-#endif
 
 #define QMP_PARAMETERS_SPRINTF(args, name, format, ...) \
     qmp_parameters_add_string(gc, args, name, \
@@ -905,6 +903,16 @@ int libxl__qmp_resume(libxl__gc *gc, int domid)
     return qmp_run_command(gc, domid, "cont", NULL, NULL, NULL);
 }
 
+int libxl__qmp_set_global_dirty_log(libxl__gc *gc, int domid, bool enable)
+{
+    libxl__json_object *args = NULL;
+
+    qmp_parameters_add_bool(gc, &args, "enable", enable);
+
+    return qmp_run_command(gc, domid, "xen-set-global-dirty-log", args,
+                           NULL, NULL);
+}
+
 int libxl__qmp_initializations(libxl__gc *gc, uint32_t domid,
                                const libxl_domain_config *guest_config)
 {
-- 
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 Sep 26 18:16:00 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Sep 2012 18: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 1TGw97-000787-2v; Wed, 26 Sep 2012 18:15:41 +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 1TGw95-00077b-Q7
	for xen-devel@lists.xen.org; Wed, 26 Sep 2012 18:15:39 +0000
Received: from [85.158.143.99:18707] by server-1.bemta-4.messagelabs.com id
	36/16-05684-B4643605; Wed, 26 Sep 2012 18:15:39 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1348683336!24884357!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzE2MjI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15517 invoked from network); 26 Sep 2012 18:15:38 -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;
	26 Sep 2012 18:15:38 -0000
X-IronPort-AV: E=Sophos;i="4.80,491,1344211200"; d="scan'208";a="39270292"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Sep 2012 18:15:36 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 26 Sep 2012 14:15:36 -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 1TGw92-0001cN-0g;
	Wed, 26 Sep 2012 19:15:36 +0100
From: Anthony PERARD <anthony.perard@citrix.com>
To: Xen Devel <xen-devel@lists.xen.org>
Date: Wed, 26 Sep 2012 19:15:19 +0100
Message-ID: <1348683325-12367-5-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.12.1
In-Reply-To: <1348683325-12367-1-git-send-email-anthony.perard@citrix.com>
References: <1348683325-12367-1-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Cc: Anthony PERARD <anthony.perard@citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH V3 04/10] libxl_json: Introduce
	libxl__json_object_to_yajl_gen.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This function converts a libxl__json_object to yajl by calling every yajl_gen_*
function on a preallocated yajl_gen hand.

This helps to integrate a json_object into an already existing yajl_gen tree.

This function is used in a later patch.

Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
 tools/libxl/libxl_internal.h |  3 +++
 tools/libxl/libxl_json.c     | 61 ++++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 64 insertions(+)

diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 5604256..bf888ee 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -1537,6 +1537,9 @@ libxl__json_map_node *libxl__json_map_node_get(const libxl__json_object *o,
 _hidden const libxl__json_object *libxl__json_map_get(const char *key,
                                           const libxl__json_object *o,
                                           libxl__json_node_type expected_type);
+_hidden yajl_status libxl__json_object_to_yajl_gen(libxl__gc *gc,
+                                                   yajl_gen hand,
+                                                   libxl__json_object *param);
 
 _hidden libxl__json_object *libxl__json_parse(libxl__gc *gc, const char *s);
 
diff --git a/tools/libxl/libxl_json.c b/tools/libxl/libxl_json.c
index 34fd8c7..3d74046 100644
--- a/tools/libxl/libxl_json.c
+++ b/tools/libxl/libxl_json.c
@@ -322,6 +322,67 @@ const libxl__json_object *libxl__json_map_get(const char *key,
     return NULL;
 }
 
+yajl_status libxl__json_object_to_yajl_gen(libxl__gc *gc,
+                                           yajl_gen hand,
+                                           libxl__json_object *obj)
+{
+    int index = 0;
+    yajl_status rc;
+
+    switch (obj->type) {
+    case JSON_NULL:
+        return yajl_gen_null(hand);
+    case JSON_BOOL:
+        return yajl_gen_bool(hand, obj->u.b);
+    case JSON_INTEGER:
+        return yajl_gen_integer(hand, obj->u.i);
+    case JSON_DOUBLE:
+        return yajl_gen_double(hand, obj->u.d);
+    case JSON_NUMBER:
+        return yajl_gen_number(hand, obj->u.string, strlen(obj->u.string));
+    case JSON_STRING:
+        return libxl__yajl_gen_asciiz(hand, obj->u.string);
+    case JSON_MAP: {
+        libxl__json_map_node *node = NULL;
+
+        rc = yajl_gen_map_open(hand);
+        if (rc != yajl_status_ok)
+            return rc;
+        for (index = 0; index < obj->u.map->count; index++) {
+            if (flexarray_get(obj->u.map, index, (void**)&node) != 0)
+                break;
+
+            rc = libxl__yajl_gen_asciiz(hand, node->map_key);
+            if (rc != yajl_status_ok)
+                return rc;
+            rc = libxl__json_object_to_yajl_gen(gc, hand, node->obj);
+            if (rc != yajl_status_ok)
+                return rc;
+        }
+        return yajl_gen_map_close(hand);
+    }
+    case JSON_ARRAY: {
+        libxl__json_object *node = NULL;
+
+        rc = yajl_gen_array_open(hand);
+        if (rc != yajl_status_ok)
+            return rc;
+        for (index = 0; index < obj->u.array->count; index++) {
+            if (flexarray_get(obj->u.array, index, (void**)&node) != 0)
+                break;
+            rc = libxl__json_object_to_yajl_gen(gc, hand, node);
+            if (rc != yajl_status_ok)
+                return rc;
+        }
+        return yajl_gen_array_close(hand);
+    }
+    case JSON_ANY:
+        /* JSON_ANY is not a valid value for obj->type. */
+        ;
+    }
+    abort();
+}
+
 
 /*
  * JSON callbacks
-- 
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 Sep 26 18:16:00 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Sep 2012 18: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 1TGw99-000799-PH; Wed, 26 Sep 2012 18:15:43 +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 1TGw97-00077b-9L
	for xen-devel@lists.xen.org; Wed, 26 Sep 2012 18:15:41 +0000
Received: from [85.158.143.99:15810] by server-1.bemta-4.messagelabs.com id
	0B/16-05684-D4643605; Wed, 26 Sep 2012 18:15:41 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1348683336!31551611!4
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNzc3MDY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32623 invoked from network); 26 Sep 2012 18:15:40 -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;
	26 Sep 2012 18:15:40 -0000
X-IronPort-AV: E=Sophos;i="4.80,491,1344211200"; d="scan'208";a="209449524"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Sep 2012 18:15:36 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 26 Sep 2012 14:15:36 -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 1TGw92-0001cN-By;
	Wed, 26 Sep 2012 19:15:36 +0100
From: Anthony PERARD <anthony.perard@citrix.com>
To: Xen Devel <xen-devel@lists.xen.org>
Date: Wed, 26 Sep 2012 19:15:23 +0100
Message-ID: <1348683325-12367-9-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.12.1
In-Reply-To: <1348683325-12367-1-git-send-email-anthony.perard@citrix.com>
References: <1348683325-12367-1-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Cc: Anthony PERARD <anthony.perard@citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH V3 08/10] libxl_qmp: Introduce
	libxl__qmp_set_global_dirty_log.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This function will enable or disable the global dirty log on QEMU, used during
a migration.

Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/libxl/libxl_internal.h |  2 ++
 tools/libxl/libxl_qmp.c      | 12 ++++++++++--
 2 files changed, 12 insertions(+), 2 deletions(-)

diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index bf888ee..8950ea5 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -1399,6 +1399,8 @@ _hidden int libxl__qmp_stop(libxl__gc *gc, int domid);
 _hidden int libxl__qmp_resume(libxl__gc *gc, int domid);
 /* Save current QEMU state into fd. */
 _hidden int libxl__qmp_save(libxl__gc *gc, int domid, const char *filename);
+/* Set dirty bitmap logging status */
+_hidden int libxl__qmp_set_global_dirty_log(libxl__gc *gc, int domid, bool enable);
 /* close and free the QMP handler */
 _hidden void libxl__qmp_close(libxl__qmp_handler *qmp);
 /* remove the socket file, if the file has already been removed,
diff --git a/tools/libxl/libxl_qmp.c b/tools/libxl/libxl_qmp.c
index 7bf56a7..5fa0c65 100644
--- a/tools/libxl/libxl_qmp.c
+++ b/tools/libxl/libxl_qmp.c
@@ -657,7 +657,6 @@ static void qmp_parameters_add_string(libxl__gc *gc,
     qmp_parameters_common_add(gc, param, name, obj);
 }
 
-#if 0
 static void qmp_parameters_add_bool(libxl__gc *gc,
                                     libxl__json_object **param,
                                     const char *name, bool b)
@@ -668,7 +667,6 @@ static void qmp_parameters_add_bool(libxl__gc *gc,
     obj->u.b = b;
     qmp_parameters_common_add(gc, param, name, obj);
 }
-#endif
 
 #define QMP_PARAMETERS_SPRINTF(args, name, format, ...) \
     qmp_parameters_add_string(gc, args, name, \
@@ -905,6 +903,16 @@ int libxl__qmp_resume(libxl__gc *gc, int domid)
     return qmp_run_command(gc, domid, "cont", NULL, NULL, NULL);
 }
 
+int libxl__qmp_set_global_dirty_log(libxl__gc *gc, int domid, bool enable)
+{
+    libxl__json_object *args = NULL;
+
+    qmp_parameters_add_bool(gc, &args, "enable", enable);
+
+    return qmp_run_command(gc, domid, "xen-set-global-dirty-log", args,
+                           NULL, NULL);
+}
+
 int libxl__qmp_initializations(libxl__gc *gc, uint32_t domid,
                                const libxl_domain_config *guest_config)
 {
-- 
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 Sep 26 18:16:00 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Sep 2012 18: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 1TGw9B-0007A7-3C; Wed, 26 Sep 2012 18:15:45 +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 1TGw98-00078N-Kl
	for xen-devel@lists.xen.org; Wed, 26 Sep 2012 18:15:42 +0000
Received: from [85.158.138.51:61522] by server-8.bemta-3.messagelabs.com id
	11/DC-16337-D4643605; Wed, 26 Sep 2012 18:15:41 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1348683338!24007998!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNzc3MDY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18746 invoked from network); 26 Sep 2012 18:15:41 -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;
	26 Sep 2012 18:15:41 -0000
X-IronPort-AV: E=Sophos;i="4.80,491,1344211200"; d="scan'208";a="209449525"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Sep 2012 18:15:37 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 26 Sep 2012 14:15:36 -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 1TGw92-0001cN-8A;
	Wed, 26 Sep 2012 19:15:36 +0100
From: Anthony PERARD <anthony.perard@citrix.com>
To: Xen Devel <xen-devel@lists.xen.org>
Date: Wed, 26 Sep 2012 19:15:21 +0100
Message-ID: <1348683325-12367-7-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.12.1
In-Reply-To: <1348683325-12367-1-git-send-email-anthony.perard@citrix.com>
References: <1348683325-12367-1-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Cc: Anthony PERARD <anthony.perard@citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH V3 06/10] libxl_qmp: Use qmp_parameters_*
	functions for param list of a QMP command.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/libxl/libxl_qmp.c | 71 +++++++++++++++++++------------------------------
 1 file changed, 28 insertions(+), 43 deletions(-)

diff --git a/tools/libxl/libxl_qmp.c b/tools/libxl/libxl_qmp.c
index d86f290..caf2a59 100644
--- a/tools/libxl/libxl_qmp.c
+++ b/tools/libxl/libxl_qmp.c
@@ -78,7 +78,7 @@ struct libxl__qmp_handler {
 };
 
 static int qmp_send(libxl__qmp_handler *qmp,
-                    const char *cmd, libxl_key_value_list *args,
+                    const char *cmd, libxl__json_object *args,
                     qmp_callback_t callback, void *opaque,
                     qmp_request_context *context);
 
@@ -502,7 +502,7 @@ static int qmp_next(libxl__gc *gc, libxl__qmp_handler *qmp)
 }
 
 static char *qmp_send_prepare(libxl__gc *gc, libxl__qmp_handler *qmp,
-                              const char *cmd, libxl_key_value_list *args,
+                              const char *cmd, libxl__json_object *args,
                               qmp_callback_t callback, void *opaque,
                               qmp_request_context *context)
 {
@@ -526,7 +526,7 @@ static char *qmp_send_prepare(libxl__gc *gc, libxl__qmp_handler *qmp,
     yajl_gen_integer(hand, ++qmp->last_id_used);
     if (args) {
         libxl__yajl_gen_asciiz(hand, "arguments");
-        libxl_key_value_list_gen_json(hand, args);
+        libxl__json_object_to_yajl_gen(gc, hand, args);
     }
     yajl_gen_map_close(hand);
 
@@ -560,7 +560,7 @@ out:
 }
 
 static int qmp_send(libxl__qmp_handler *qmp,
-                    const char *cmd, libxl_key_value_list *args,
+                    const char *cmd, libxl__json_object *args,
                     qmp_callback_t callback, void *opaque,
                     qmp_request_context *context)
 {
@@ -588,7 +588,7 @@ out:
 }
 
 static int qmp_synchronous_send(libxl__qmp_handler *qmp, const char *cmd,
-                                libxl_key_value_list *args,
+                                libxl__json_object *args,
                                 qmp_callback_t callback, void *opaque,
                                 int ask_timeout)
 {
@@ -623,7 +623,6 @@ static void qmp_free_handler(libxl__qmp_handler *qmp)
     free(qmp);
 }
 
-#if 0
 /*
  * QMP Parameters Helpers
  */
@@ -658,6 +657,7 @@ static void qmp_parameters_add_string(libxl__gc *gc,
     qmp_parameters_common_add(gc, param, name, obj);
 }
 
+#if 0
 static void qmp_parameters_add_bool(libxl__gc *gc,
                                     libxl__json_object **param,
                                     const char *name, bool b)
@@ -668,11 +668,11 @@ static void qmp_parameters_add_bool(libxl__gc *gc,
     obj->u.b = b;
     qmp_parameters_common_add(gc, param, name, obj);
 }
+#endif
 
 #define QMP_PARAMETERS_SPRINTF(args, name, format, ...) \
     qmp_parameters_add_string(gc, args, name, \
                               libxl__sprintf(gc, format, __VA_ARGS__))
-#endif
 
 /*
  * API
@@ -800,8 +800,7 @@ out:
 int libxl__qmp_pci_add(libxl__gc *gc, int domid, libxl_device_pci *pcidev)
 {
     libxl__qmp_handler *qmp = NULL;
-    flexarray_t *parameters = NULL;
-    libxl_key_value_list args = NULL;
+    libxl__json_object *args = NULL;
     char *hostaddr = NULL;
     int rc = 0;
 
@@ -814,22 +813,16 @@ int libxl__qmp_pci_add(libxl__gc *gc, int domid, libxl_device_pci *pcidev)
     if (!hostaddr)
         return -1;
 
-    parameters = flexarray_make(gc, 6, 1);
-    flexarray_append_pair(parameters, "driver", "xen-pci-passthrough");
-    flexarray_append_pair(parameters, "id",
-                          libxl__sprintf(gc, PCI_PT_QDEV_ID,
-                                         pcidev->bus, pcidev->dev,
-                                         pcidev->func));
-    flexarray_append_pair(parameters, "hostaddr", hostaddr);
+    qmp_parameters_add_string(gc, &args, "driver", "xen-pci-passthrough");
+    QMP_PARAMETERS_SPRINTF(&args, "id", PCI_PT_QDEV_ID,
+                           pcidev->bus, pcidev->dev, pcidev->func);
+    qmp_parameters_add_string(gc, &args, "hostaddr", hostaddr);
     if (pcidev->vdevfn) {
-        flexarray_append_pair(parameters, "addr",
-                              libxl__sprintf(gc, "%x.%x",
-                                             PCI_SLOT(pcidev->vdevfn),
-                                             PCI_FUNC(pcidev->vdevfn)));
+        QMP_PARAMETERS_SPRINTF(&args, "addr", "%x.%x",
+                               PCI_SLOT(pcidev->vdevfn), PCI_FUNC(pcidev->vdevfn));
     }
-    args = libxl__xs_kvs_of_flexarray(gc, parameters, parameters->count);
 
-    rc = qmp_synchronous_send(qmp, "device_add", &args,
+    rc = qmp_synchronous_send(qmp, "device_add", args,
                               NULL, NULL, qmp->timeout);
     if (rc == 0) {
         rc = qmp_synchronous_send(qmp, "query-pci", NULL,
@@ -843,19 +836,16 @@ int libxl__qmp_pci_add(libxl__gc *gc, int domid, libxl_device_pci *pcidev)
 static int qmp_device_del(libxl__gc *gc, int domid, char *id)
 {
     libxl__qmp_handler *qmp = NULL;
-    flexarray_t *parameters = NULL;
-    libxl_key_value_list args = NULL;
+    libxl__json_object *args = NULL;
     int rc = 0;
 
     qmp = libxl__qmp_initialize(gc, domid);
     if (!qmp)
         return ERROR_FAIL;
 
-    parameters = flexarray_make(gc, 2, 1);
-    flexarray_append_pair(parameters, "id", id);
-    args = libxl__xs_kvs_of_flexarray(gc, parameters, parameters->count);
+    qmp_parameters_add_string(gc, &args, "id", id);
 
-    rc = qmp_synchronous_send(qmp, "device_del", &args,
+    rc = qmp_synchronous_send(qmp, "device_del", args,
                               NULL, NULL, qmp->timeout);
 
     libxl__qmp_close(qmp);
@@ -875,19 +865,16 @@ int libxl__qmp_pci_del(libxl__gc *gc, int domid, libxl_device_pci *pcidev)
 int libxl__qmp_save(libxl__gc *gc, int domid, const char *filename)
 {
     libxl__qmp_handler *qmp = NULL;
-    flexarray_t *parameters = NULL;
-    libxl_key_value_list args = NULL;
+    libxl__json_object *args = NULL;
     int rc = 0;
 
     qmp = libxl__qmp_initialize(gc, domid);
     if (!qmp)
         return ERROR_FAIL;
 
-    parameters = flexarray_make(gc, 2, 1);
-    flexarray_append_pair(parameters, "filename", (char *)filename);
-    args = libxl__xs_kvs_of_flexarray(gc, parameters, parameters->count);
+    qmp_parameters_add_string(gc, &args, "filename", (char *)filename);
 
-    rc = qmp_synchronous_send(qmp, "xen-save-devices-state", &args,
+    rc = qmp_synchronous_send(qmp, "xen-save-devices-state", args,
                               NULL, NULL, qmp->timeout);
 
     libxl__qmp_close(qmp);
@@ -897,18 +884,16 @@ int libxl__qmp_save(libxl__gc *gc, int domid, const char *filename)
 static int qmp_change(libxl__gc *gc, libxl__qmp_handler *qmp,
                       char *device, char *target, char *arg)
 {
-    flexarray_t *parameters = NULL;
-    libxl_key_value_list args = NULL;
+    libxl__json_object *args = NULL;
     int rc = 0;
 
-    parameters = flexarray_make(gc, 6, 1);
-    flexarray_append_pair(parameters, "device", device);
-    flexarray_append_pair(parameters, "target", target);
-    if (arg)
-        flexarray_append_pair(parameters, "arg", arg);
-    args = libxl__xs_kvs_of_flexarray(gc, parameters, parameters->count);
+    qmp_parameters_add_string(gc, &args, "device", device);
+    qmp_parameters_add_string(gc, &args, "target", target);
+    if (arg) {
+        qmp_parameters_add_string(gc, &args, "arg", arg);
+    }
 
-    rc = qmp_synchronous_send(qmp, "change", &args,
+    rc = qmp_synchronous_send(qmp, "change", args,
                               NULL, NULL, qmp->timeout);
 
     return rc;
-- 
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 Sep 26 18:16:00 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Sep 2012 18: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 1TGw98-00078h-UZ; Wed, 26 Sep 2012 18:15:42 +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 1TGw96-00077W-IR
	for xen-devel@lists.xen.org; Wed, 26 Sep 2012 18:15:40 +0000
Received: from [85.158.143.99:18750] by server-3.bemta-4.messagelabs.com id
	EF/40-10986-C4643605; Wed, 26 Sep 2012 18:15:40 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1348683336!31551611!3
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNzc3MDY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32593 invoked from network); 26 Sep 2012 18:15:39 -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;
	26 Sep 2012 18:15:39 -0000
X-IronPort-AV: E=Sophos;i="4.80,491,1344211200"; d="scan'208";a="209449520"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Sep 2012 18:15:36 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 26 Sep 2012 14:15:36 -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 1TGw91-0001cN-JG;
	Wed, 26 Sep 2012 19:15:35 +0100
From: Anthony PERARD <anthony.perard@citrix.com>
To: Xen Devel <xen-devel@lists.xen.org>
Date: Wed, 26 Sep 2012 19:15:18 +0100
Message-ID: <1348683325-12367-4-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.12.1
In-Reply-To: <1348683325-12367-1-git-send-email-anthony.perard@citrix.com>
References: <1348683325-12367-1-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Cc: Anthony PERARD <anthony.perard@citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH V3 03/10] libxl_json: Replace JSON_TRUE/FALSE by
	JSON_BOOL.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Those two JSON_TRUE and JSON_FALSE were types of node. But it's better to have
a unique JSON_BOOL type.

Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
 tools/libxl/libxl_internal.h | 15 +++++++++++++--
 tools/libxl/libxl_json.c     |  4 ++--
 tools/libxl/libxl_qmp.c      |  3 ++-
 3 files changed, 17 insertions(+), 5 deletions(-)

diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 49c62c0..5604256 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -1428,8 +1428,7 @@ _hidden yajl_gen_status libxl__yajl_gen_enum(yajl_gen hand, const char *str);
 
 typedef enum {
     JSON_NULL,
-    JSON_TRUE,
-    JSON_FALSE,
+    JSON_BOOL,
     JSON_INTEGER,
     JSON_DOUBLE,
     /* number is store in string, it's too big to be a long long or a double */
@@ -1443,6 +1442,7 @@ typedef enum {
 typedef struct libxl__json_object {
     libxl__json_node_type type;
     union {
+        bool b;
         long long i;
         double d;
         char *string;
@@ -1461,6 +1461,10 @@ typedef struct {
 
 typedef struct libxl__yajl_ctx libxl__yajl_ctx;
 
+static inline bool libxl__json_object_is_bool(const libxl__json_object *o)
+{
+    return o != NULL && o->type == JSON_BOOL;
+}
 static inline bool libxl__json_object_is_string(const libxl__json_object *o)
 {
     return o != NULL && o->type == JSON_STRING;
@@ -1478,6 +1482,13 @@ static inline bool libxl__json_object_is_array(const libxl__json_object *o)
     return o != NULL && o->type == JSON_ARRAY;
 }
 
+static inline bool libxl__json_object_get_bool(const libxl__json_object *o)
+{
+    if (libxl__json_object_is_bool(o))
+        return o->u.b;
+    else
+        return false;
+}
 static inline
 const char *libxl__json_object_get_string(const libxl__json_object *o)
 {
diff --git a/tools/libxl/libxl_json.c b/tools/libxl/libxl_json.c
index 30b2980..34fd8c7 100644
--- a/tools/libxl/libxl_json.c
+++ b/tools/libxl/libxl_json.c
@@ -350,8 +350,8 @@ static int json_callback_boolean(void *opaque, int boolean)
 
     DEBUG_GEN_VALUE(ctx, bool, boolean);
 
-    obj = libxl__json_object_alloc(ctx->gc,
-                                   boolean ? JSON_TRUE : JSON_FALSE);
+    obj = libxl__json_object_alloc(ctx->gc, JSON_BOOL);
+    obj->u.b = boolean;
 
     if (libxl__json_object_append_to(ctx->gc, obj, ctx->current) == -1) {
         return 0;
diff --git a/tools/libxl/libxl_qmp.c b/tools/libxl/libxl_qmp.c
index 15550e7..9109ac5 100644
--- a/tools/libxl/libxl_qmp.c
+++ b/tools/libxl/libxl_qmp.c
@@ -178,7 +178,8 @@ static int qmp_register_vnc_callback(libxl__qmp_handler *qmp,
         goto out;
     }
 
-    if (libxl__json_map_get("enabled", o, JSON_FALSE)) {
+    obj = libxl__json_map_get("enabled", o, JSON_BOOL);
+    if (!obj || !libxl__json_object_get_bool(obj)) {
         rc = 0;
         goto out;
     }
-- 
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 Sep 26 18:16:00 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Sep 2012 18: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 1TGw9B-0007A7-3C; Wed, 26 Sep 2012 18:15:45 +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 1TGw98-00078N-Kl
	for xen-devel@lists.xen.org; Wed, 26 Sep 2012 18:15:42 +0000
Received: from [85.158.138.51:61522] by server-8.bemta-3.messagelabs.com id
	11/DC-16337-D4643605; Wed, 26 Sep 2012 18:15:41 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1348683338!24007998!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNzc3MDY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18746 invoked from network); 26 Sep 2012 18:15:41 -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;
	26 Sep 2012 18:15:41 -0000
X-IronPort-AV: E=Sophos;i="4.80,491,1344211200"; d="scan'208";a="209449525"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Sep 2012 18:15:37 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 26 Sep 2012 14:15:36 -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 1TGw92-0001cN-8A;
	Wed, 26 Sep 2012 19:15:36 +0100
From: Anthony PERARD <anthony.perard@citrix.com>
To: Xen Devel <xen-devel@lists.xen.org>
Date: Wed, 26 Sep 2012 19:15:21 +0100
Message-ID: <1348683325-12367-7-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.12.1
In-Reply-To: <1348683325-12367-1-git-send-email-anthony.perard@citrix.com>
References: <1348683325-12367-1-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Cc: Anthony PERARD <anthony.perard@citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH V3 06/10] libxl_qmp: Use qmp_parameters_*
	functions for param list of a QMP command.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/libxl/libxl_qmp.c | 71 +++++++++++++++++++------------------------------
 1 file changed, 28 insertions(+), 43 deletions(-)

diff --git a/tools/libxl/libxl_qmp.c b/tools/libxl/libxl_qmp.c
index d86f290..caf2a59 100644
--- a/tools/libxl/libxl_qmp.c
+++ b/tools/libxl/libxl_qmp.c
@@ -78,7 +78,7 @@ struct libxl__qmp_handler {
 };
 
 static int qmp_send(libxl__qmp_handler *qmp,
-                    const char *cmd, libxl_key_value_list *args,
+                    const char *cmd, libxl__json_object *args,
                     qmp_callback_t callback, void *opaque,
                     qmp_request_context *context);
 
@@ -502,7 +502,7 @@ static int qmp_next(libxl__gc *gc, libxl__qmp_handler *qmp)
 }
 
 static char *qmp_send_prepare(libxl__gc *gc, libxl__qmp_handler *qmp,
-                              const char *cmd, libxl_key_value_list *args,
+                              const char *cmd, libxl__json_object *args,
                               qmp_callback_t callback, void *opaque,
                               qmp_request_context *context)
 {
@@ -526,7 +526,7 @@ static char *qmp_send_prepare(libxl__gc *gc, libxl__qmp_handler *qmp,
     yajl_gen_integer(hand, ++qmp->last_id_used);
     if (args) {
         libxl__yajl_gen_asciiz(hand, "arguments");
-        libxl_key_value_list_gen_json(hand, args);
+        libxl__json_object_to_yajl_gen(gc, hand, args);
     }
     yajl_gen_map_close(hand);
 
@@ -560,7 +560,7 @@ out:
 }
 
 static int qmp_send(libxl__qmp_handler *qmp,
-                    const char *cmd, libxl_key_value_list *args,
+                    const char *cmd, libxl__json_object *args,
                     qmp_callback_t callback, void *opaque,
                     qmp_request_context *context)
 {
@@ -588,7 +588,7 @@ out:
 }
 
 static int qmp_synchronous_send(libxl__qmp_handler *qmp, const char *cmd,
-                                libxl_key_value_list *args,
+                                libxl__json_object *args,
                                 qmp_callback_t callback, void *opaque,
                                 int ask_timeout)
 {
@@ -623,7 +623,6 @@ static void qmp_free_handler(libxl__qmp_handler *qmp)
     free(qmp);
 }
 
-#if 0
 /*
  * QMP Parameters Helpers
  */
@@ -658,6 +657,7 @@ static void qmp_parameters_add_string(libxl__gc *gc,
     qmp_parameters_common_add(gc, param, name, obj);
 }
 
+#if 0
 static void qmp_parameters_add_bool(libxl__gc *gc,
                                     libxl__json_object **param,
                                     const char *name, bool b)
@@ -668,11 +668,11 @@ static void qmp_parameters_add_bool(libxl__gc *gc,
     obj->u.b = b;
     qmp_parameters_common_add(gc, param, name, obj);
 }
+#endif
 
 #define QMP_PARAMETERS_SPRINTF(args, name, format, ...) \
     qmp_parameters_add_string(gc, args, name, \
                               libxl__sprintf(gc, format, __VA_ARGS__))
-#endif
 
 /*
  * API
@@ -800,8 +800,7 @@ out:
 int libxl__qmp_pci_add(libxl__gc *gc, int domid, libxl_device_pci *pcidev)
 {
     libxl__qmp_handler *qmp = NULL;
-    flexarray_t *parameters = NULL;
-    libxl_key_value_list args = NULL;
+    libxl__json_object *args = NULL;
     char *hostaddr = NULL;
     int rc = 0;
 
@@ -814,22 +813,16 @@ int libxl__qmp_pci_add(libxl__gc *gc, int domid, libxl_device_pci *pcidev)
     if (!hostaddr)
         return -1;
 
-    parameters = flexarray_make(gc, 6, 1);
-    flexarray_append_pair(parameters, "driver", "xen-pci-passthrough");
-    flexarray_append_pair(parameters, "id",
-                          libxl__sprintf(gc, PCI_PT_QDEV_ID,
-                                         pcidev->bus, pcidev->dev,
-                                         pcidev->func));
-    flexarray_append_pair(parameters, "hostaddr", hostaddr);
+    qmp_parameters_add_string(gc, &args, "driver", "xen-pci-passthrough");
+    QMP_PARAMETERS_SPRINTF(&args, "id", PCI_PT_QDEV_ID,
+                           pcidev->bus, pcidev->dev, pcidev->func);
+    qmp_parameters_add_string(gc, &args, "hostaddr", hostaddr);
     if (pcidev->vdevfn) {
-        flexarray_append_pair(parameters, "addr",
-                              libxl__sprintf(gc, "%x.%x",
-                                             PCI_SLOT(pcidev->vdevfn),
-                                             PCI_FUNC(pcidev->vdevfn)));
+        QMP_PARAMETERS_SPRINTF(&args, "addr", "%x.%x",
+                               PCI_SLOT(pcidev->vdevfn), PCI_FUNC(pcidev->vdevfn));
     }
-    args = libxl__xs_kvs_of_flexarray(gc, parameters, parameters->count);
 
-    rc = qmp_synchronous_send(qmp, "device_add", &args,
+    rc = qmp_synchronous_send(qmp, "device_add", args,
                               NULL, NULL, qmp->timeout);
     if (rc == 0) {
         rc = qmp_synchronous_send(qmp, "query-pci", NULL,
@@ -843,19 +836,16 @@ int libxl__qmp_pci_add(libxl__gc *gc, int domid, libxl_device_pci *pcidev)
 static int qmp_device_del(libxl__gc *gc, int domid, char *id)
 {
     libxl__qmp_handler *qmp = NULL;
-    flexarray_t *parameters = NULL;
-    libxl_key_value_list args = NULL;
+    libxl__json_object *args = NULL;
     int rc = 0;
 
     qmp = libxl__qmp_initialize(gc, domid);
     if (!qmp)
         return ERROR_FAIL;
 
-    parameters = flexarray_make(gc, 2, 1);
-    flexarray_append_pair(parameters, "id", id);
-    args = libxl__xs_kvs_of_flexarray(gc, parameters, parameters->count);
+    qmp_parameters_add_string(gc, &args, "id", id);
 
-    rc = qmp_synchronous_send(qmp, "device_del", &args,
+    rc = qmp_synchronous_send(qmp, "device_del", args,
                               NULL, NULL, qmp->timeout);
 
     libxl__qmp_close(qmp);
@@ -875,19 +865,16 @@ int libxl__qmp_pci_del(libxl__gc *gc, int domid, libxl_device_pci *pcidev)
 int libxl__qmp_save(libxl__gc *gc, int domid, const char *filename)
 {
     libxl__qmp_handler *qmp = NULL;
-    flexarray_t *parameters = NULL;
-    libxl_key_value_list args = NULL;
+    libxl__json_object *args = NULL;
     int rc = 0;
 
     qmp = libxl__qmp_initialize(gc, domid);
     if (!qmp)
         return ERROR_FAIL;
 
-    parameters = flexarray_make(gc, 2, 1);
-    flexarray_append_pair(parameters, "filename", (char *)filename);
-    args = libxl__xs_kvs_of_flexarray(gc, parameters, parameters->count);
+    qmp_parameters_add_string(gc, &args, "filename", (char *)filename);
 
-    rc = qmp_synchronous_send(qmp, "xen-save-devices-state", &args,
+    rc = qmp_synchronous_send(qmp, "xen-save-devices-state", args,
                               NULL, NULL, qmp->timeout);
 
     libxl__qmp_close(qmp);
@@ -897,18 +884,16 @@ int libxl__qmp_save(libxl__gc *gc, int domid, const char *filename)
 static int qmp_change(libxl__gc *gc, libxl__qmp_handler *qmp,
                       char *device, char *target, char *arg)
 {
-    flexarray_t *parameters = NULL;
-    libxl_key_value_list args = NULL;
+    libxl__json_object *args = NULL;
     int rc = 0;
 
-    parameters = flexarray_make(gc, 6, 1);
-    flexarray_append_pair(parameters, "device", device);
-    flexarray_append_pair(parameters, "target", target);
-    if (arg)
-        flexarray_append_pair(parameters, "arg", arg);
-    args = libxl__xs_kvs_of_flexarray(gc, parameters, parameters->count);
+    qmp_parameters_add_string(gc, &args, "device", device);
+    qmp_parameters_add_string(gc, &args, "target", target);
+    if (arg) {
+        qmp_parameters_add_string(gc, &args, "arg", arg);
+    }
 
-    rc = qmp_synchronous_send(qmp, "change", &args,
+    rc = qmp_synchronous_send(qmp, "change", args,
                               NULL, NULL, qmp->timeout);
 
     return rc;
-- 
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 Sep 26 18:16:00 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Sep 2012 18: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 1TGw98-00078h-UZ; Wed, 26 Sep 2012 18:15:42 +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 1TGw96-00077W-IR
	for xen-devel@lists.xen.org; Wed, 26 Sep 2012 18:15:40 +0000
Received: from [85.158.143.99:18750] by server-3.bemta-4.messagelabs.com id
	EF/40-10986-C4643605; Wed, 26 Sep 2012 18:15:40 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1348683336!31551611!3
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNzc3MDY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32593 invoked from network); 26 Sep 2012 18:15:39 -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;
	26 Sep 2012 18:15:39 -0000
X-IronPort-AV: E=Sophos;i="4.80,491,1344211200"; d="scan'208";a="209449520"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Sep 2012 18:15:36 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 26 Sep 2012 14:15:36 -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 1TGw91-0001cN-JG;
	Wed, 26 Sep 2012 19:15:35 +0100
From: Anthony PERARD <anthony.perard@citrix.com>
To: Xen Devel <xen-devel@lists.xen.org>
Date: Wed, 26 Sep 2012 19:15:18 +0100
Message-ID: <1348683325-12367-4-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.12.1
In-Reply-To: <1348683325-12367-1-git-send-email-anthony.perard@citrix.com>
References: <1348683325-12367-1-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Cc: Anthony PERARD <anthony.perard@citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH V3 03/10] libxl_json: Replace JSON_TRUE/FALSE by
	JSON_BOOL.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Those two JSON_TRUE and JSON_FALSE were types of node. But it's better to have
a unique JSON_BOOL type.

Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
 tools/libxl/libxl_internal.h | 15 +++++++++++++--
 tools/libxl/libxl_json.c     |  4 ++--
 tools/libxl/libxl_qmp.c      |  3 ++-
 3 files changed, 17 insertions(+), 5 deletions(-)

diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 49c62c0..5604256 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -1428,8 +1428,7 @@ _hidden yajl_gen_status libxl__yajl_gen_enum(yajl_gen hand, const char *str);
 
 typedef enum {
     JSON_NULL,
-    JSON_TRUE,
-    JSON_FALSE,
+    JSON_BOOL,
     JSON_INTEGER,
     JSON_DOUBLE,
     /* number is store in string, it's too big to be a long long or a double */
@@ -1443,6 +1442,7 @@ typedef enum {
 typedef struct libxl__json_object {
     libxl__json_node_type type;
     union {
+        bool b;
         long long i;
         double d;
         char *string;
@@ -1461,6 +1461,10 @@ typedef struct {
 
 typedef struct libxl__yajl_ctx libxl__yajl_ctx;
 
+static inline bool libxl__json_object_is_bool(const libxl__json_object *o)
+{
+    return o != NULL && o->type == JSON_BOOL;
+}
 static inline bool libxl__json_object_is_string(const libxl__json_object *o)
 {
     return o != NULL && o->type == JSON_STRING;
@@ -1478,6 +1482,13 @@ static inline bool libxl__json_object_is_array(const libxl__json_object *o)
     return o != NULL && o->type == JSON_ARRAY;
 }
 
+static inline bool libxl__json_object_get_bool(const libxl__json_object *o)
+{
+    if (libxl__json_object_is_bool(o))
+        return o->u.b;
+    else
+        return false;
+}
 static inline
 const char *libxl__json_object_get_string(const libxl__json_object *o)
 {
diff --git a/tools/libxl/libxl_json.c b/tools/libxl/libxl_json.c
index 30b2980..34fd8c7 100644
--- a/tools/libxl/libxl_json.c
+++ b/tools/libxl/libxl_json.c
@@ -350,8 +350,8 @@ static int json_callback_boolean(void *opaque, int boolean)
 
     DEBUG_GEN_VALUE(ctx, bool, boolean);
 
-    obj = libxl__json_object_alloc(ctx->gc,
-                                   boolean ? JSON_TRUE : JSON_FALSE);
+    obj = libxl__json_object_alloc(ctx->gc, JSON_BOOL);
+    obj->u.b = boolean;
 
     if (libxl__json_object_append_to(ctx->gc, obj, ctx->current) == -1) {
         return 0;
diff --git a/tools/libxl/libxl_qmp.c b/tools/libxl/libxl_qmp.c
index 15550e7..9109ac5 100644
--- a/tools/libxl/libxl_qmp.c
+++ b/tools/libxl/libxl_qmp.c
@@ -178,7 +178,8 @@ static int qmp_register_vnc_callback(libxl__qmp_handler *qmp,
         goto out;
     }
 
-    if (libxl__json_map_get("enabled", o, JSON_FALSE)) {
+    obj = libxl__json_map_get("enabled", o, JSON_BOOL);
+    if (!obj || !libxl__json_object_get_bool(obj)) {
         rc = 0;
         goto out;
     }
-- 
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 Sep 26 18:16:00 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Sep 2012 18: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 1TGw96-00077t-Mm; Wed, 26 Sep 2012 18:15:40 +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 1TGw95-00077W-BM
	for xen-devel@lists.xen.org; Wed, 26 Sep 2012 18:15:39 +0000
Received: from [85.158.143.99:15743] by server-3.bemta-4.messagelabs.com id
	6C/40-10986-A4643605; Wed, 26 Sep 2012 18:15:38 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1348683336!31551611!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNzc3MDY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32540 invoked from network); 26 Sep 2012 18:15:38 -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;
	26 Sep 2012 18:15:38 -0000
X-IronPort-AV: E=Sophos;i="4.80,491,1344211200"; d="scan'208";a="209449517"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Sep 2012 18:15:36 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 26 Sep 2012 14:15:35 -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 1TGw91-0001cN-7G;
	Wed, 26 Sep 2012 19:15:35 +0100
From: Anthony PERARD <anthony.perard@citrix.com>
To: Xen Devel <xen-devel@lists.xen.org>
Date: Wed, 26 Sep 2012 19:15:15 +0100
Message-ID: <1348683325-12367-1-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.12.1
MIME-Version: 1.0
Cc: Anthony PERARD <anthony.perard@citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH V3 00/10] Set dirty log on 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

Note: Now depend on "Cleanup: flexarray taking gc" sent earlier.


This patch series enables libxl to set dirty log on QEMU upstream during
migration through a new QMP command.

The success of the call depends on the presence of the specific QMP command
xen-set-global-dirty-log in QEMU. Patches for this command have been sent.

There is several patches that cleanup a bit the libxl_json/qmp codes.

Change since v2:
  - New patch to remove the unused JSON_ERROR enum value.
  - New patch to replace JSON_TRUE/FALSE by JSON_BOOL.
  - libxl__json_object_to_yajl_gen will now abort() if there is a wrong type
    for a node.
  - The macro QMP_PARAMETERS_SPRINTF now expect the var gc to be present in the
    environment of the caller.
  - The last patch remove the all check instead of just the return error for
    qemu-xen.

Changes since v1:
  - Use libxl allocation function with NOGC when requiered.
  - No more check of failed allocation.
  - New qmp_run_command function, to factorize the libxl_qmp code.
  - cleanup ...


Anthony PERARD (10):
  libxl_json: Export json_object related function.
  libxl_json: Remove JSON_ERROR from enum.
  libxl_json: Replace JSON_TRUE/FALSE by JSON_BOOL.
  libxl_json: Introduce libxl__json_object_to_yajl_gen.
  libxl_qmp: Introduces helpers to create an argument list.
  libxl_qmp: Use qmp_parameters_* functions for param list of a QMP
    command.
  libxl_qmp: Simplify run of single QMP commands.
  libxl_qmp: Introduce libxl__qmp_set_global_dirty_log.
  libxl_dom: Call the right switch logdirty for the right DM.
  libxl: Allow migration with qemu-xen.

 tools/libxl/libxl.c          |  17 ----
 tools/libxl/libxl_dom.c      |  45 ++++++++++-
 tools/libxl/libxl_internal.h |  29 ++++++-
 tools/libxl/libxl_json.c     |  95 ++++++++++++++++++----
 tools/libxl/libxl_qmp.c      | 189 ++++++++++++++++++++++++-------------------
 5 files changed, 250 insertions(+), 125 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 Wed Sep 26 18:16:00 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Sep 2012 18: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 1TGw9A-00079r-NJ; Wed, 26 Sep 2012 18:15:44 +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 1TGw98-00077W-5N
	for xen-devel@lists.xen.org; Wed, 26 Sep 2012 18:15:42 +0000
Received: from [85.158.143.99:18811] by server-3.bemta-4.messagelabs.com id
	82/50-10986-D4643605; Wed, 26 Sep 2012 18:15:41 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1348683338!23701261!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzE2MjI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5209 invoked from network); 26 Sep 2012 18:15:39 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-2.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Sep 2012 18:15:39 -0000
X-IronPort-AV: E=Sophos;i="4.80,491,1344211200"; d="scan'208";a="39270294"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Sep 2012 18:15:37 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 26 Sep 2012 14:15:36 -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 1TGw92-0001cN-EB;
	Wed, 26 Sep 2012 19:15:36 +0100
From: Anthony PERARD <anthony.perard@citrix.com>
To: Xen Devel <xen-devel@lists.xen.org>
Date: Wed, 26 Sep 2012 19:15:24 +0100
Message-ID: <1348683325-12367-10-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.12.1
In-Reply-To: <1348683325-12367-1-git-send-email-anthony.perard@citrix.com>
References: <1348683325-12367-1-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Cc: Anthony PERARD <anthony.perard@citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH V3 09/10] libxl_dom: Call the right switch
	logdirty for the right DM.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This patch dispatch the switch logdirty call depending on which device model
version is running.

The call to qemu-xen right now is synchronous, not like the one to
qemu-xen-traditional.

Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/libxl/libxl_dom.c | 45 ++++++++++++++++++++++++++++++++++++++++++---
 1 file changed, 42 insertions(+), 3 deletions(-)

diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index e1de832..95da18e 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -685,10 +685,10 @@ static void logdirty_init(libxl__logdirty_switch *lds)
     libxl__ev_time_init(&lds->timeout);
 }
 
-void libxl__domain_suspend_common_switch_qemu_logdirty
-                               (int domid, unsigned enable, void *user)
+static void domain_suspend_switch_qemu_xen_traditional_logdirty
+                               (int domid, unsigned enable,
+                                libxl__save_helper_state *shs)
 {
-    libxl__save_helper_state *shs = user;
     libxl__egc *egc = shs->egc;
     libxl__domain_suspend_state *dss = CONTAINER_OF(shs, *dss, shs);
     libxl__logdirty_switch *lds = &dss->logdirty;
@@ -756,6 +756,45 @@ void libxl__domain_suspend_common_switch_qemu_logdirty
     switch_logdirty_done(egc,dss,-1);
 }
 
+static void domain_suspend_switch_qemu_xen_logdirty
+                               (int domid, unsigned enable,
+                                libxl__save_helper_state *shs)
+{
+    libxl__egc *egc = shs->egc;
+    libxl__domain_suspend_state *dss = CONTAINER_OF(shs, *dss, shs);
+    STATE_AO_GC(dss->ao);
+    int rc;
+
+    rc = libxl__qmp_set_global_dirty_log(gc, domid, enable);
+    if (!rc) {
+        libxl__xc_domain_saverestore_async_callback_done(egc, shs, 0);
+    } else {
+        LOG(ERROR,"logdirty switch failed (rc=%d), aborting suspend",rc);
+        libxl__xc_domain_saverestore_async_callback_done(egc, shs, -1);
+    }
+}
+
+void libxl__domain_suspend_common_switch_qemu_logdirty
+                               (int domid, unsigned enable, void *user)
+{
+    libxl__save_helper_state *shs = user;
+    libxl__egc *egc = shs->egc;
+    libxl__domain_suspend_state *dss = CONTAINER_OF(shs, *dss, shs);
+    STATE_AO_GC(dss->ao);
+
+    switch (libxl__device_model_version_running(gc, domid)) {
+    case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL:
+        domain_suspend_switch_qemu_xen_traditional_logdirty(domid, enable, shs);
+        break;
+    case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN:
+        domain_suspend_switch_qemu_xen_logdirty(domid, enable, shs);
+        break;
+    default:
+        LOG(ERROR,"logdirty switch failed"
+            ", no valid device model version found, aborting suspend");
+        libxl__xc_domain_saverestore_async_callback_done(egc, shs, -1);
+    }
+}
 static void switch_logdirty_timeout(libxl__egc *egc, libxl__ev_time *ev,
                                     const struct timeval *requested_abs)
 {
-- 
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 Sep 26 18:16:00 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Sep 2012 18: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 1TGw9A-00079c-Ba; Wed, 26 Sep 2012 18:15:44 +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 1TGw97-00078G-UM
	for xen-devel@lists.xen.org; Wed, 26 Sep 2012 18:15:42 +0000
Received: from [85.158.138.51:61502] by server-13.bemta-3.messagelabs.com id
	77/3E-11249-C4643605; Wed, 26 Sep 2012 18:15:40 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1348683338!24007998!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNzc3MDY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18725 invoked from network); 26 Sep 2012 18:15:40 -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;
	26 Sep 2012 18:15:40 -0000
X-IronPort-AV: E=Sophos;i="4.80,491,1344211200"; d="scan'208";a="209449523"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Sep 2012 18:15:36 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 26 Sep 2012 14:15:36 -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 1TGw92-0001cN-9H;
	Wed, 26 Sep 2012 19:15:36 +0100
From: Anthony PERARD <anthony.perard@citrix.com>
To: Xen Devel <xen-devel@lists.xen.org>
Date: Wed, 26 Sep 2012 19:15:22 +0100
Message-ID: <1348683325-12367-8-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.12.1
In-Reply-To: <1348683325-12367-1-git-send-email-anthony.perard@citrix.com>
References: <1348683325-12367-1-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Cc: Anthony PERARD <anthony.perard@citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH V3 07/10] libxl_qmp: Simplify run of single QMP
	commands.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This new function connects to QEMU, sends the command and disconnects.

Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/libxl/libxl_qmp.c | 70 ++++++++++++++++---------------------------------
 1 file changed, 22 insertions(+), 48 deletions(-)

diff --git a/tools/libxl/libxl_qmp.c b/tools/libxl/libxl_qmp.c
index caf2a59..7bf56a7 100644
--- a/tools/libxl/libxl_qmp.c
+++ b/tools/libxl/libxl_qmp.c
@@ -797,6 +797,23 @@ out:
     return rc;
 }
 
+static int qmp_run_command(libxl__gc *gc, int domid,
+                           const char *cmd, libxl__json_object *args,
+                           qmp_callback_t callback, void *opaque)
+{
+    libxl__qmp_handler *qmp = NULL;
+    int rc = 0;
+
+    qmp = libxl__qmp_initialize(gc, domid);
+    if (!qmp)
+        return ERROR_FAIL;
+
+    rc = qmp_synchronous_send(qmp, cmd, args, callback, opaque, qmp->timeout);
+
+    libxl__qmp_close(qmp);
+    return rc;
+}
+
 int libxl__qmp_pci_add(libxl__gc *gc, int domid, libxl_device_pci *pcidev)
 {
     libxl__qmp_handler *qmp = NULL;
@@ -835,21 +852,10 @@ int libxl__qmp_pci_add(libxl__gc *gc, int domid, libxl_device_pci *pcidev)
 
 static int qmp_device_del(libxl__gc *gc, int domid, char *id)
 {
-    libxl__qmp_handler *qmp = NULL;
     libxl__json_object *args = NULL;
-    int rc = 0;
-
-    qmp = libxl__qmp_initialize(gc, domid);
-    if (!qmp)
-        return ERROR_FAIL;
 
     qmp_parameters_add_string(gc, &args, "id", id);
-
-    rc = qmp_synchronous_send(qmp, "device_del", args,
-                              NULL, NULL, qmp->timeout);
-
-    libxl__qmp_close(qmp);
-    return rc;
+    return qmp_run_command(gc, domid, "device_del", args, NULL, NULL);
 }
 
 int libxl__qmp_pci_del(libxl__gc *gc, int domid, libxl_device_pci *pcidev)
@@ -864,21 +870,11 @@ int libxl__qmp_pci_del(libxl__gc *gc, int domid, libxl_device_pci *pcidev)
 
 int libxl__qmp_save(libxl__gc *gc, int domid, const char *filename)
 {
-    libxl__qmp_handler *qmp = NULL;
     libxl__json_object *args = NULL;
-    int rc = 0;
-
-    qmp = libxl__qmp_initialize(gc, domid);
-    if (!qmp)
-        return ERROR_FAIL;
 
     qmp_parameters_add_string(gc, &args, "filename", (char *)filename);
-
-    rc = qmp_synchronous_send(qmp, "xen-save-devices-state", args,
-                              NULL, NULL, qmp->timeout);
-
-    libxl__qmp_close(qmp);
-    return rc;
+    return qmp_run_command(gc, domid, "xen-save-devices-state", args,
+                           NULL, NULL);
 }
 
 static int qmp_change(libxl__gc *gc, libxl__qmp_handler *qmp,
@@ -901,34 +897,12 @@ static int qmp_change(libxl__gc *gc, libxl__qmp_handler *qmp,
 
 int libxl__qmp_stop(libxl__gc *gc, int domid)
 {
-    libxl__qmp_handler *qmp = NULL;
-    int rc = 0;
-
-    qmp = libxl__qmp_initialize(gc, domid);
-    if (!qmp)
-        return ERROR_FAIL;
-
-    rc = qmp_synchronous_send(qmp, "stop", NULL,
-                              NULL, NULL, qmp->timeout);
-
-    libxl__qmp_close(qmp);
-    return rc;
+    return qmp_run_command(gc, domid, "stop", NULL, NULL, NULL);
 }
 
 int libxl__qmp_resume(libxl__gc *gc, int domid)
 {
-    libxl__qmp_handler *qmp = NULL;
-    int rc = 0;
-
-    qmp = libxl__qmp_initialize(gc, domid);
-    if (!qmp)
-        return ERROR_FAIL;
-
-    rc = qmp_synchronous_send(qmp, "cont", NULL,
-                              NULL, NULL, qmp->timeout);
-
-    libxl__qmp_close(qmp);
-    return rc;
+    return qmp_run_command(gc, domid, "cont", NULL, NULL, NULL);
 }
 
 int libxl__qmp_initializations(libxl__gc *gc, uint32_t domid,
-- 
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 Sep 26 18:16:00 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Sep 2012 18: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 1TGw96-00077t-Mm; Wed, 26 Sep 2012 18:15:40 +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 1TGw95-00077W-BM
	for xen-devel@lists.xen.org; Wed, 26 Sep 2012 18:15:39 +0000
Received: from [85.158.143.99:15743] by server-3.bemta-4.messagelabs.com id
	6C/40-10986-A4643605; Wed, 26 Sep 2012 18:15:38 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1348683336!31551611!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNzc3MDY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32540 invoked from network); 26 Sep 2012 18:15:38 -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;
	26 Sep 2012 18:15:38 -0000
X-IronPort-AV: E=Sophos;i="4.80,491,1344211200"; d="scan'208";a="209449517"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Sep 2012 18:15:36 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 26 Sep 2012 14:15:35 -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 1TGw91-0001cN-7G;
	Wed, 26 Sep 2012 19:15:35 +0100
From: Anthony PERARD <anthony.perard@citrix.com>
To: Xen Devel <xen-devel@lists.xen.org>
Date: Wed, 26 Sep 2012 19:15:15 +0100
Message-ID: <1348683325-12367-1-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.12.1
MIME-Version: 1.0
Cc: Anthony PERARD <anthony.perard@citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH V3 00/10] Set dirty log on 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

Note: Now depend on "Cleanup: flexarray taking gc" sent earlier.


This patch series enables libxl to set dirty log on QEMU upstream during
migration through a new QMP command.

The success of the call depends on the presence of the specific QMP command
xen-set-global-dirty-log in QEMU. Patches for this command have been sent.

There is several patches that cleanup a bit the libxl_json/qmp codes.

Change since v2:
  - New patch to remove the unused JSON_ERROR enum value.
  - New patch to replace JSON_TRUE/FALSE by JSON_BOOL.
  - libxl__json_object_to_yajl_gen will now abort() if there is a wrong type
    for a node.
  - The macro QMP_PARAMETERS_SPRINTF now expect the var gc to be present in the
    environment of the caller.
  - The last patch remove the all check instead of just the return error for
    qemu-xen.

Changes since v1:
  - Use libxl allocation function with NOGC when requiered.
  - No more check of failed allocation.
  - New qmp_run_command function, to factorize the libxl_qmp code.
  - cleanup ...


Anthony PERARD (10):
  libxl_json: Export json_object related function.
  libxl_json: Remove JSON_ERROR from enum.
  libxl_json: Replace JSON_TRUE/FALSE by JSON_BOOL.
  libxl_json: Introduce libxl__json_object_to_yajl_gen.
  libxl_qmp: Introduces helpers to create an argument list.
  libxl_qmp: Use qmp_parameters_* functions for param list of a QMP
    command.
  libxl_qmp: Simplify run of single QMP commands.
  libxl_qmp: Introduce libxl__qmp_set_global_dirty_log.
  libxl_dom: Call the right switch logdirty for the right DM.
  libxl: Allow migration with qemu-xen.

 tools/libxl/libxl.c          |  17 ----
 tools/libxl/libxl_dom.c      |  45 ++++++++++-
 tools/libxl/libxl_internal.h |  29 ++++++-
 tools/libxl/libxl_json.c     |  95 ++++++++++++++++++----
 tools/libxl/libxl_qmp.c      | 189 ++++++++++++++++++++++++-------------------
 5 files changed, 250 insertions(+), 125 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 Wed Sep 26 18:16:00 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Sep 2012 18: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 1TGw96-00077l-AZ; Wed, 26 Sep 2012 18:15:40 +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 1TGw94-00077W-VM
	for xen-devel@lists.xen.org; Wed, 26 Sep 2012 18:15:39 +0000
Received: from [85.158.143.99:18674] by server-3.bemta-4.messagelabs.com id
	2B/40-10986-A4643605; Wed, 26 Sep 2012 18:15:38 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1348683336!24884357!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzE2MjI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15509 invoked from network); 26 Sep 2012 18:15:37 -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;
	26 Sep 2012 18:15:37 -0000
X-IronPort-AV: E=Sophos;i="4.80,491,1344211200"; d="scan'208";a="39270291"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Sep 2012 18:15:36 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 26 Sep 2012 14:15:36 -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 1TGw91-0001cN-Fq;
	Wed, 26 Sep 2012 19:15:35 +0100
From: Anthony PERARD <anthony.perard@citrix.com>
To: Xen Devel <xen-devel@lists.xen.org>
Date: Wed, 26 Sep 2012 19:15:17 +0100
Message-ID: <1348683325-12367-3-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.12.1
In-Reply-To: <1348683325-12367-1-git-send-email-anthony.perard@citrix.com>
References: <1348683325-12367-1-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Cc: Anthony PERARD <anthony.perard@citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH V3 02/10] libxl_json: Remove JSON_ERROR from
	enum.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This value from libxl__json_node_type is never used.

Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
 tools/libxl/libxl_internal.h | 1 -
 1 file changed, 1 deletion(-)

diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index f69f58d..49c62c0 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -1427,7 +1427,6 @@ _hidden yajl_gen_status libxl__yajl_gen_asciiz(yajl_gen hand, const char *str);
 _hidden yajl_gen_status libxl__yajl_gen_enum(yajl_gen hand, const char *str);
 
 typedef enum {
-    JSON_ERROR,
     JSON_NULL,
     JSON_TRUE,
     JSON_FALSE,
-- 
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 Sep 26 18:16:00 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Sep 2012 18: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 1TGw99-00078w-Af; Wed, 26 Sep 2012 18:15:43 +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 1TGw96-00077g-UN
	for xen-devel@lists.xen.org; Wed, 26 Sep 2012 18:15:41 +0000
Received: from [85.158.143.99:18734] by server-2.bemta-4.messagelabs.com id
	85/BB-06610-B4643605; Wed, 26 Sep 2012 18:15:39 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1348683336!24884357!3
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzE2MjI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15541 invoked from network); 26 Sep 2012 18:15:39 -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;
	26 Sep 2012 18:15:39 -0000
X-IronPort-AV: E=Sophos;i="4.80,491,1344211200"; d="scan'208";a="39270293"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Sep 2012 18:15:36 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 26 Sep 2012 14:15:36 -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 1TGw92-0001cN-5u;
	Wed, 26 Sep 2012 19:15:36 +0100
From: Anthony PERARD <anthony.perard@citrix.com>
To: Xen Devel <xen-devel@lists.xen.org>
Date: Wed, 26 Sep 2012 19:15:20 +0100
Message-ID: <1348683325-12367-6-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.12.1
In-Reply-To: <1348683325-12367-1-git-send-email-anthony.perard@citrix.com>
References: <1348683325-12367-1-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Cc: Anthony PERARD <anthony.perard@citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH V3 05/10] libxl_qmp: Introduces helpers to
	create an argument list.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Those functions will be used to create a "list" of parameters that contain more
than just strings. This list is converted by qmp_send to a string to be sent to
QEMU.

Those functions will be used in the next two patches, so right now there are
not compiled.

Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
 tools/libxl/libxl_qmp.c | 51 +++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 51 insertions(+)

diff --git a/tools/libxl/libxl_qmp.c b/tools/libxl/libxl_qmp.c
index 9109ac5..d86f290 100644
--- a/tools/libxl/libxl_qmp.c
+++ b/tools/libxl/libxl_qmp.c
@@ -623,6 +623,57 @@ static void qmp_free_handler(libxl__qmp_handler *qmp)
     free(qmp);
 }
 
+#if 0
+/*
+ * QMP Parameters Helpers
+ */
+static void qmp_parameters_common_add(libxl__gc *gc,
+                                      libxl__json_object **param,
+                                      const char *name,
+                                      libxl__json_object *obj)
+{
+    libxl__json_map_node *arg = NULL;
+
+    if (!*param) {
+        *param = libxl__json_object_alloc(gc, JSON_MAP);
+    }
+
+    arg = libxl__zalloc(gc, sizeof(*arg));
+
+    arg->map_key = libxl__strdup(gc, name);
+    arg->obj = obj;
+
+    flexarray_append((*param)->u.map, arg);
+}
+
+static void qmp_parameters_add_string(libxl__gc *gc,
+                                      libxl__json_object **param,
+                                      const char *name, const char *argument)
+{
+    libxl__json_object *obj;
+
+    obj = libxl__json_object_alloc(gc, JSON_STRING);
+    obj->u.string = libxl__strdup(gc, argument);
+
+    qmp_parameters_common_add(gc, param, name, obj);
+}
+
+static void qmp_parameters_add_bool(libxl__gc *gc,
+                                    libxl__json_object **param,
+                                    const char *name, bool b)
+{
+    libxl__json_object *obj;
+
+    obj = libxl__json_object_alloc(gc, JSON_BOOL);
+    obj->u.b = b;
+    qmp_parameters_common_add(gc, param, name, obj);
+}
+
+#define QMP_PARAMETERS_SPRINTF(args, name, format, ...) \
+    qmp_parameters_add_string(gc, args, name, \
+                              libxl__sprintf(gc, format, __VA_ARGS__))
+#endif
+
 /*
  * API
  */
-- 
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 Sep 26 18:16:00 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Sep 2012 18: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 1TGw9A-00079c-Ba; Wed, 26 Sep 2012 18:15:44 +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 1TGw97-00078G-UM
	for xen-devel@lists.xen.org; Wed, 26 Sep 2012 18:15:42 +0000
Received: from [85.158.138.51:61502] by server-13.bemta-3.messagelabs.com id
	77/3E-11249-C4643605; Wed, 26 Sep 2012 18:15:40 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1348683338!24007998!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNzc3MDY=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18725 invoked from network); 26 Sep 2012 18:15:40 -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;
	26 Sep 2012 18:15:40 -0000
X-IronPort-AV: E=Sophos;i="4.80,491,1344211200"; d="scan'208";a="209449523"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Sep 2012 18:15:36 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 26 Sep 2012 14:15:36 -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 1TGw92-0001cN-9H;
	Wed, 26 Sep 2012 19:15:36 +0100
From: Anthony PERARD <anthony.perard@citrix.com>
To: Xen Devel <xen-devel@lists.xen.org>
Date: Wed, 26 Sep 2012 19:15:22 +0100
Message-ID: <1348683325-12367-8-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.12.1
In-Reply-To: <1348683325-12367-1-git-send-email-anthony.perard@citrix.com>
References: <1348683325-12367-1-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Cc: Anthony PERARD <anthony.perard@citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH V3 07/10] libxl_qmp: Simplify run of single QMP
	commands.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This new function connects to QEMU, sends the command and disconnects.

Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/libxl/libxl_qmp.c | 70 ++++++++++++++++---------------------------------
 1 file changed, 22 insertions(+), 48 deletions(-)

diff --git a/tools/libxl/libxl_qmp.c b/tools/libxl/libxl_qmp.c
index caf2a59..7bf56a7 100644
--- a/tools/libxl/libxl_qmp.c
+++ b/tools/libxl/libxl_qmp.c
@@ -797,6 +797,23 @@ out:
     return rc;
 }
 
+static int qmp_run_command(libxl__gc *gc, int domid,
+                           const char *cmd, libxl__json_object *args,
+                           qmp_callback_t callback, void *opaque)
+{
+    libxl__qmp_handler *qmp = NULL;
+    int rc = 0;
+
+    qmp = libxl__qmp_initialize(gc, domid);
+    if (!qmp)
+        return ERROR_FAIL;
+
+    rc = qmp_synchronous_send(qmp, cmd, args, callback, opaque, qmp->timeout);
+
+    libxl__qmp_close(qmp);
+    return rc;
+}
+
 int libxl__qmp_pci_add(libxl__gc *gc, int domid, libxl_device_pci *pcidev)
 {
     libxl__qmp_handler *qmp = NULL;
@@ -835,21 +852,10 @@ int libxl__qmp_pci_add(libxl__gc *gc, int domid, libxl_device_pci *pcidev)
 
 static int qmp_device_del(libxl__gc *gc, int domid, char *id)
 {
-    libxl__qmp_handler *qmp = NULL;
     libxl__json_object *args = NULL;
-    int rc = 0;
-
-    qmp = libxl__qmp_initialize(gc, domid);
-    if (!qmp)
-        return ERROR_FAIL;
 
     qmp_parameters_add_string(gc, &args, "id", id);
-
-    rc = qmp_synchronous_send(qmp, "device_del", args,
-                              NULL, NULL, qmp->timeout);
-
-    libxl__qmp_close(qmp);
-    return rc;
+    return qmp_run_command(gc, domid, "device_del", args, NULL, NULL);
 }
 
 int libxl__qmp_pci_del(libxl__gc *gc, int domid, libxl_device_pci *pcidev)
@@ -864,21 +870,11 @@ int libxl__qmp_pci_del(libxl__gc *gc, int domid, libxl_device_pci *pcidev)
 
 int libxl__qmp_save(libxl__gc *gc, int domid, const char *filename)
 {
-    libxl__qmp_handler *qmp = NULL;
     libxl__json_object *args = NULL;
-    int rc = 0;
-
-    qmp = libxl__qmp_initialize(gc, domid);
-    if (!qmp)
-        return ERROR_FAIL;
 
     qmp_parameters_add_string(gc, &args, "filename", (char *)filename);
-
-    rc = qmp_synchronous_send(qmp, "xen-save-devices-state", args,
-                              NULL, NULL, qmp->timeout);
-
-    libxl__qmp_close(qmp);
-    return rc;
+    return qmp_run_command(gc, domid, "xen-save-devices-state", args,
+                           NULL, NULL);
 }
 
 static int qmp_change(libxl__gc *gc, libxl__qmp_handler *qmp,
@@ -901,34 +897,12 @@ static int qmp_change(libxl__gc *gc, libxl__qmp_handler *qmp,
 
 int libxl__qmp_stop(libxl__gc *gc, int domid)
 {
-    libxl__qmp_handler *qmp = NULL;
-    int rc = 0;
-
-    qmp = libxl__qmp_initialize(gc, domid);
-    if (!qmp)
-        return ERROR_FAIL;
-
-    rc = qmp_synchronous_send(qmp, "stop", NULL,
-                              NULL, NULL, qmp->timeout);
-
-    libxl__qmp_close(qmp);
-    return rc;
+    return qmp_run_command(gc, domid, "stop", NULL, NULL, NULL);
 }
 
 int libxl__qmp_resume(libxl__gc *gc, int domid)
 {
-    libxl__qmp_handler *qmp = NULL;
-    int rc = 0;
-
-    qmp = libxl__qmp_initialize(gc, domid);
-    if (!qmp)
-        return ERROR_FAIL;
-
-    rc = qmp_synchronous_send(qmp, "cont", NULL,
-                              NULL, NULL, qmp->timeout);
-
-    libxl__qmp_close(qmp);
-    return rc;
+    return qmp_run_command(gc, domid, "cont", NULL, NULL, NULL);
 }
 
 int libxl__qmp_initializations(libxl__gc *gc, uint32_t domid,
-- 
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 Sep 26 18:16:00 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Sep 2012 18: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 1TGw9A-00079r-NJ; Wed, 26 Sep 2012 18:15:44 +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 1TGw98-00077W-5N
	for xen-devel@lists.xen.org; Wed, 26 Sep 2012 18:15:42 +0000
Received: from [85.158.143.99:18811] by server-3.bemta-4.messagelabs.com id
	82/50-10986-D4643605; Wed, 26 Sep 2012 18:15:41 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1348683338!23701261!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzE2MjI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5209 invoked from network); 26 Sep 2012 18:15:39 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-2.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Sep 2012 18:15:39 -0000
X-IronPort-AV: E=Sophos;i="4.80,491,1344211200"; d="scan'208";a="39270294"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Sep 2012 18:15:37 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 26 Sep 2012 14:15:36 -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 1TGw92-0001cN-EB;
	Wed, 26 Sep 2012 19:15:36 +0100
From: Anthony PERARD <anthony.perard@citrix.com>
To: Xen Devel <xen-devel@lists.xen.org>
Date: Wed, 26 Sep 2012 19:15:24 +0100
Message-ID: <1348683325-12367-10-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.12.1
In-Reply-To: <1348683325-12367-1-git-send-email-anthony.perard@citrix.com>
References: <1348683325-12367-1-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Cc: Anthony PERARD <anthony.perard@citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH V3 09/10] libxl_dom: Call the right switch
	logdirty for the right DM.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This patch dispatch the switch logdirty call depending on which device model
version is running.

The call to qemu-xen right now is synchronous, not like the one to
qemu-xen-traditional.

Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/libxl/libxl_dom.c | 45 ++++++++++++++++++++++++++++++++++++++++++---
 1 file changed, 42 insertions(+), 3 deletions(-)

diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index e1de832..95da18e 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -685,10 +685,10 @@ static void logdirty_init(libxl__logdirty_switch *lds)
     libxl__ev_time_init(&lds->timeout);
 }
 
-void libxl__domain_suspend_common_switch_qemu_logdirty
-                               (int domid, unsigned enable, void *user)
+static void domain_suspend_switch_qemu_xen_traditional_logdirty
+                               (int domid, unsigned enable,
+                                libxl__save_helper_state *shs)
 {
-    libxl__save_helper_state *shs = user;
     libxl__egc *egc = shs->egc;
     libxl__domain_suspend_state *dss = CONTAINER_OF(shs, *dss, shs);
     libxl__logdirty_switch *lds = &dss->logdirty;
@@ -756,6 +756,45 @@ void libxl__domain_suspend_common_switch_qemu_logdirty
     switch_logdirty_done(egc,dss,-1);
 }
 
+static void domain_suspend_switch_qemu_xen_logdirty
+                               (int domid, unsigned enable,
+                                libxl__save_helper_state *shs)
+{
+    libxl__egc *egc = shs->egc;
+    libxl__domain_suspend_state *dss = CONTAINER_OF(shs, *dss, shs);
+    STATE_AO_GC(dss->ao);
+    int rc;
+
+    rc = libxl__qmp_set_global_dirty_log(gc, domid, enable);
+    if (!rc) {
+        libxl__xc_domain_saverestore_async_callback_done(egc, shs, 0);
+    } else {
+        LOG(ERROR,"logdirty switch failed (rc=%d), aborting suspend",rc);
+        libxl__xc_domain_saverestore_async_callback_done(egc, shs, -1);
+    }
+}
+
+void libxl__domain_suspend_common_switch_qemu_logdirty
+                               (int domid, unsigned enable, void *user)
+{
+    libxl__save_helper_state *shs = user;
+    libxl__egc *egc = shs->egc;
+    libxl__domain_suspend_state *dss = CONTAINER_OF(shs, *dss, shs);
+    STATE_AO_GC(dss->ao);
+
+    switch (libxl__device_model_version_running(gc, domid)) {
+    case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL:
+        domain_suspend_switch_qemu_xen_traditional_logdirty(domid, enable, shs);
+        break;
+    case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN:
+        domain_suspend_switch_qemu_xen_logdirty(domid, enable, shs);
+        break;
+    default:
+        LOG(ERROR,"logdirty switch failed"
+            ", no valid device model version found, aborting suspend");
+        libxl__xc_domain_saverestore_async_callback_done(egc, shs, -1);
+    }
+}
 static void switch_logdirty_timeout(libxl__egc *egc, libxl__ev_time *ev,
                                     const struct timeval *requested_abs)
 {
-- 
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 Sep 26 18:16:00 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Sep 2012 18: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 1TGw99-00078w-Af; Wed, 26 Sep 2012 18:15:43 +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 1TGw96-00077g-UN
	for xen-devel@lists.xen.org; Wed, 26 Sep 2012 18:15:41 +0000
Received: from [85.158.143.99:18734] by server-2.bemta-4.messagelabs.com id
	85/BB-06610-B4643605; Wed, 26 Sep 2012 18:15:39 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1348683336!24884357!3
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzE2MjI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15541 invoked from network); 26 Sep 2012 18:15:39 -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;
	26 Sep 2012 18:15:39 -0000
X-IronPort-AV: E=Sophos;i="4.80,491,1344211200"; d="scan'208";a="39270293"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Sep 2012 18:15:36 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 26 Sep 2012 14:15:36 -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 1TGw92-0001cN-5u;
	Wed, 26 Sep 2012 19:15:36 +0100
From: Anthony PERARD <anthony.perard@citrix.com>
To: Xen Devel <xen-devel@lists.xen.org>
Date: Wed, 26 Sep 2012 19:15:20 +0100
Message-ID: <1348683325-12367-6-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.12.1
In-Reply-To: <1348683325-12367-1-git-send-email-anthony.perard@citrix.com>
References: <1348683325-12367-1-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Cc: Anthony PERARD <anthony.perard@citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH V3 05/10] libxl_qmp: Introduces helpers to
	create an argument list.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Those functions will be used to create a "list" of parameters that contain more
than just strings. This list is converted by qmp_send to a string to be sent to
QEMU.

Those functions will be used in the next two patches, so right now there are
not compiled.

Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
 tools/libxl/libxl_qmp.c | 51 +++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 51 insertions(+)

diff --git a/tools/libxl/libxl_qmp.c b/tools/libxl/libxl_qmp.c
index 9109ac5..d86f290 100644
--- a/tools/libxl/libxl_qmp.c
+++ b/tools/libxl/libxl_qmp.c
@@ -623,6 +623,57 @@ static void qmp_free_handler(libxl__qmp_handler *qmp)
     free(qmp);
 }
 
+#if 0
+/*
+ * QMP Parameters Helpers
+ */
+static void qmp_parameters_common_add(libxl__gc *gc,
+                                      libxl__json_object **param,
+                                      const char *name,
+                                      libxl__json_object *obj)
+{
+    libxl__json_map_node *arg = NULL;
+
+    if (!*param) {
+        *param = libxl__json_object_alloc(gc, JSON_MAP);
+    }
+
+    arg = libxl__zalloc(gc, sizeof(*arg));
+
+    arg->map_key = libxl__strdup(gc, name);
+    arg->obj = obj;
+
+    flexarray_append((*param)->u.map, arg);
+}
+
+static void qmp_parameters_add_string(libxl__gc *gc,
+                                      libxl__json_object **param,
+                                      const char *name, const char *argument)
+{
+    libxl__json_object *obj;
+
+    obj = libxl__json_object_alloc(gc, JSON_STRING);
+    obj->u.string = libxl__strdup(gc, argument);
+
+    qmp_parameters_common_add(gc, param, name, obj);
+}
+
+static void qmp_parameters_add_bool(libxl__gc *gc,
+                                    libxl__json_object **param,
+                                    const char *name, bool b)
+{
+    libxl__json_object *obj;
+
+    obj = libxl__json_object_alloc(gc, JSON_BOOL);
+    obj->u.b = b;
+    qmp_parameters_common_add(gc, param, name, obj);
+}
+
+#define QMP_PARAMETERS_SPRINTF(args, name, format, ...) \
+    qmp_parameters_add_string(gc, args, name, \
+                              libxl__sprintf(gc, format, __VA_ARGS__))
+#endif
+
 /*
  * API
  */
-- 
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 Sep 26 18:16:00 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Sep 2012 18: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 1TGw96-00077l-AZ; Wed, 26 Sep 2012 18:15:40 +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 1TGw94-00077W-VM
	for xen-devel@lists.xen.org; Wed, 26 Sep 2012 18:15:39 +0000
Received: from [85.158.143.99:18674] by server-3.bemta-4.messagelabs.com id
	2B/40-10986-A4643605; Wed, 26 Sep 2012 18:15:38 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1348683336!24884357!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzE2MjI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15509 invoked from network); 26 Sep 2012 18:15:37 -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;
	26 Sep 2012 18:15:37 -0000
X-IronPort-AV: E=Sophos;i="4.80,491,1344211200"; d="scan'208";a="39270291"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Sep 2012 18:15:36 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 26 Sep 2012 14:15:36 -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 1TGw91-0001cN-Fq;
	Wed, 26 Sep 2012 19:15:35 +0100
From: Anthony PERARD <anthony.perard@citrix.com>
To: Xen Devel <xen-devel@lists.xen.org>
Date: Wed, 26 Sep 2012 19:15:17 +0100
Message-ID: <1348683325-12367-3-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.12.1
In-Reply-To: <1348683325-12367-1-git-send-email-anthony.perard@citrix.com>
References: <1348683325-12367-1-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Cc: Anthony PERARD <anthony.perard@citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH V3 02/10] libxl_json: Remove JSON_ERROR from
	enum.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This value from libxl__json_node_type is never used.

Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
 tools/libxl/libxl_internal.h | 1 -
 1 file changed, 1 deletion(-)

diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index f69f58d..49c62c0 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -1427,7 +1427,6 @@ _hidden yajl_gen_status libxl__yajl_gen_asciiz(yajl_gen hand, const char *str);
 _hidden yajl_gen_status libxl__yajl_gen_enum(yajl_gen hand, const char *str);
 
 typedef enum {
-    JSON_ERROR,
     JSON_NULL,
     JSON_TRUE,
     JSON_FALSE,
-- 
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 Sep 26 18:21:55 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Sep 2012 18: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 1TGwEy-0008QE-Ei; Wed, 26 Sep 2012 18:21:44 +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 1TGwEx-0008Pv-6R
	for xen-devel@lists.xen.org; Wed, 26 Sep 2012 18:21:43 +0000
Received: from [85.158.143.99:51371] by server-2.bemta-4.messagelabs.com id
	60/FE-06610-6B743605; Wed, 26 Sep 2012 18:21:42 +0000
X-Env-Sender: ben.guthro@gmail.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1348683700!31878267!1
X-Originating-IP: [209.85.223.173]
X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_20_30,HTML_MESSAGE,
	RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16728 invoked from network); 26 Sep 2012 18:21:41 -0000
Received: from mail-ie0-f173.google.com (HELO mail-ie0-f173.google.com)
	(209.85.223.173)
	by server-15.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Sep 2012 18:21:41 -0000
Received: by iea17 with SMTP id 17so2831169iea.32
	for <xen-devel@lists.xen.org>; Wed, 26 Sep 2012 11:21:39 -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=BLDY6hd1MYUM+ThOcYGvSLN0BuZgWDpzjeOoNg0E9VY=;
	b=Fbr3/Vp9cjbaJ4skSiMhe8SWDoYSOMNMIpaUQy8eO8Nd3LnDdxeX5ABe+5umkfJJ/r
	GEcm1vyEJtTqlHt3giCYTHNd+CZoklHa9IGkHcuoJoFSA1VaOhwX4wC8CGECB5ERhR8Z
	2xzgyN8NH5rcZmSk2lp2PKFym+r6GHglYV7xv98AE7XYt75zrAMTsh9x7PpI68TqllaF
	FRLT5tuPDhuPue4u+k6MihyWmUqrFn7BBtFaURa3Hd3/eVEjA8vTNkJGYJrGwQ2piqYU
	IdD+bwbPm7apJzJp9kKikNdu1tIzRe0EGluF6oE6VZgLziaWEC8GiLlpO9KhC3GQ7c5n
	jAAQ==
MIME-Version: 1.0
Received: by 10.50.183.200 with SMTP id eo8mr12098209igc.54.1348683699785;
	Wed, 26 Sep 2012 11:21:39 -0700 (PDT)
Received: by 10.64.55.132 with HTTP; Wed, 26 Sep 2012 11:21:39 -0700 (PDT)
In-Reply-To: <5062F880020000780009DF3B@nat28.tlf.novell.com>
References: <CAOvdn6UCF2A3yP1cqWn=dxwr0ayRbr+rg+xj8META9Dm0+CoNw@mail.gmail.com>
	<CC868168.3FD29%keir.xen@gmail.com>
	<CAOvdn6U-JyLvt96gkLkqzi088tU9_ktv4D+fkJac_BKVe05Y-w@mail.gmail.com>
	<CAOvdn6V+s3AbRzsu8VArbmrZou=im9SqvPf-9Wpif_BrNMv=yg@mail.gmail.com>
	<50617297020000780009D8AA@nat28.tlf.novell.com>
	<CAOvdn6Vsnbcd7m8mh3tSgn3KaEoeiOyVD1mr3uQ3bN=rF=pDUQ@mail.gmail.com>
	<5062F880020000780009DF3B@nat28.tlf.novell.com>
Date: Wed, 26 Sep 2012 14:21:39 -0400
X-Google-Sender-Auth: 3bDLA3GUv2hhIi6jiTaAJO1i3GU
Message-ID: <CAOvdn6VyAVg24=c1OxqttxuGFyN_NzpfZ7RoCYc2mVF84c5big@mail.gmail.com>
From: Ben Guthro <ben@guthro.net>
To: Jan Beulich <JBeulich@suse.com>
Cc: Keir Fraser <keir.xen@gmail.com>, John Baboval <john.baboval@citrix.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen4.2 S3 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: multipart/mixed; boundary="===============0320081220717227132=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============0320081220717227132==
Content-Type: multipart/alternative; boundary=14dae9340435d70fee04ca9ee429

--14dae9340435d70fee04ca9ee429
Content-Type: text/plain; charset=ISO-8859-1

On Wed, Sep 26, 2012 at 6:43 AM, Jan Beulich <JBeulich@suse.com> wrote:

>
> Btw., I'm also puzzled by only seeing a ucode update message
> here for CPU1 - I just went through the logic again and can't see
> why this would not also be done for CPU0. Could you make the
> pr_debug() in microcode_intel.c actually print something, so we
> can see whether at least collect_cpu_info() would get called
> for it, hopefully allowing to deduce what happens subsequently?
>
>
I put a pr_debug at the top of collect_cpu_info - and from the trace below
- it appears everything is as it should be,
dom0 and Xen serial output get interspersed there for a few lines, but the
microcode is, in fact being loaded for both CPUs.


[   36.787452] ACPI: Preparing to enter system sleep state S3
[   37.240118] PM: Saving platform NVS memory
[   37.313160] Disabling non-boot CPUs ...
(XEN) Preparing system for ACPI S3 state.
(XEN) Disabling non-boot CPUs ...
(XEN) Breaking vcpu affinity for domain 0 vcpu 1
(XEN) Entering ACPI S3 state.
(XEN) mce_intel.c:1239: MCA Capability: BCAST 1 SER 0 CMCI 0 firstbank 1
extended MCE MSR 0
(XEN) CMCI: CPU0 has no CMCI support
(XEN) CPU0: Thermal monitoring enabled (TM2)
(XEN) Finishing wakeup from ACPI S3 state.
(XEN) microcode: collect_cpu_info for CPU0
(XEN) microcode: collect_cpu_info : sig=0x10676, pf=0x80, rev=0x60c
(XEN) Enabling non-boot CPUs  ...
(XEN) Booting processor 1/1 eip 8a000
(XEN) Initializing CPU#1
(XEN) CPU: L1 I cache: 32K, L1 D cache: 32K
(XEN) CPU: L2 cache: 3072K
(XEN) CPU: Physical Processor ID: 0
(XEN) CPU: Processor Core ID: 1
(XEN) CMCI: CPU1 has no CMCI support
(XEN) CPU1: Thermal monitoring enabled (TM2)
(XEN) CPU1: Intel(R) Core(TM)2 Duo CPU     P8400  @ 2.26GHz stepping 06
(XEN) microcode: collect_cpu_info for CPU1
[   37.420030] A(XEN) microcode: collect_cpu_info : sig=0x10676, pf=0x80,
rev=0x60c
CPI: Low-level r(XEN) microcode: CPU1 found a matching microcode update
with version 0x60f (current=0x60c)
esume complete
(XEN) microcode: CPU1 updated from revision 0x60c to 0x60f, date =
2010-09-29
[   37.420030] PM: Restoring platform NVS memory
(XEN) microcode: collect_cpu_info for CPU0
(XEN) microcode: collect_cpu_info : sig=0x10676, pf=0x80, rev=0x60c
(XEN) microcode: collect_cpu_info for CPU1
(XEN) microcode: collect_cpu_info : sig=0x10676, pf=0x80, rev=0x60f
[   37.431008] Enabling non-boot CPUs ...
[   37.434851] installing Xen timer for CPU 1
[   37.439031] cpu 1 spinlock event irq 279
[   37.327214] Disabled fast string operations
[   37.458040] CPU1 is up
[   37.465417] ACPI: Waking up from system sleep state S3

--14dae9340435d70fee04ca9ee429
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div>On Wed, Sep 26, 2012 at 6:43 AM, Jan Beulich <span dir=3D"ltr">&lt;<a =
href=3D"mailto:JBeulich@suse.com" target=3D"_blank">JBeulich@suse.com</a>&g=
t;</span> wrote:</div><div class=3D"gmail_quote"><blockquote class=3D"gmail=
_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:=
1ex">
<div class=3D"im"><br>
</div>Btw., I&#39;m also puzzled by only seeing a ucode update message<br>
here for CPU1 - I just went through the logic again and can&#39;t see<br>
why this would not also be done for CPU0. Could you make the<br>
pr_debug() in microcode_intel.c actually print something, so we<br>
can see whether at least collect_cpu_info() would get called<br>
for it, hopefully allowing to deduce what happens subsequently?<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br></font></span></blockquo=
te><div><br></div><div>I put a pr_debug at the top of collect_cpu_info - an=
d from the trace below - it appears everything is as it should be,</div><di=
v>
dom0 and Xen serial output get interspersed there for a few lines, but the =
microcode is, in fact being loaded for both CPUs.</div><div><br></div><div>=
<div><br></div><div><div>[ =A0 36.787452] ACPI: Preparing to enter system s=
leep state S3</div>
<div>[ =A0 37.240118] PM: Saving platform NVS memory</div><div>[ =A0 37.313=
160] Disabling non-boot CPUs ...</div><div>(XEN) Preparing system for ACPI =
S3 state.</div><div>(XEN) Disabling non-boot CPUs ...</div><div>(XEN) Break=
ing vcpu affinity for domain 0 vcpu 1</div>
<div>(XEN) Entering ACPI S3 state.</div><div>(XEN) mce_intel.c:1239: MCA Ca=
pability: BCAST 1 SER 0 CMCI 0 firstbank 1 extended MCE MSR 0</div><div>(XE=
N) CMCI: CPU0 has no CMCI support</div><div>(XEN) CPU0: Thermal monitoring =
enabled (TM2)</div>
<div>(XEN) Finishing wakeup from ACPI S3 state.</div><div>(XEN) microcode: =
collect_cpu_info for CPU0</div><div>(XEN) microcode: collect_cpu_info : sig=
=3D0x10676, pf=3D0x80, rev=3D0x60c</div><div>(XEN) Enabling non-boot CPUs =
=A0...</div>
<div>(XEN) Booting processor 1/1 eip 8a000</div><div>(XEN) Initializing CPU=
#1</div><div>(XEN) CPU: L1 I cache: 32K, L1 D cache: 32K</div><div>(XEN) CP=
U: L2 cache: 3072K</div><div>(XEN) CPU: Physical Processor ID: 0</div><div>
(XEN) CPU: Processor Core ID: 1</div><div>(XEN) CMCI: CPU1 has no CMCI supp=
ort</div><div>(XEN) CPU1: Thermal monitoring enabled (TM2)</div><div>(XEN) =
CPU1: Intel(R) Core(TM)2 Duo CPU =A0 =A0 P8400 =A0@ 2.26GHz stepping 06</di=
v>
<div>(XEN) microcode: collect_cpu_info for CPU1</div><div>[ =A0 37.420030] =
A(XEN) microcode: collect_cpu_info : sig=3D0x10676, pf=3D0x80, rev=3D0x60c<=
/div><div>CPI: Low-level r(XEN) microcode: CPU1 found a matching microcode =
update with version 0x60f (current=3D0x60c)</div>
<div>esume complete</div><div>(XEN) microcode: CPU1 updated from revision 0=
x60c to 0x60f, date =3D 2010-09-29=A0</div><div>[ =A0 37.420030] PM: Restor=
ing platform NVS memory</div><div>(XEN) microcode: collect_cpu_info for CPU=
0</div>
<div>(XEN) microcode: collect_cpu_info : sig=3D0x10676, pf=3D0x80, rev=3D0x=
60c</div><div>(XEN) microcode: collect_cpu_info for CPU1</div><div>(XEN) mi=
crocode: collect_cpu_info : sig=3D0x10676, pf=3D0x80, rev=3D0x60f</div><div=
>[ =A0 37.431008] Enabling non-boot CPUs ...</div>
<div>[ =A0 37.434851] installing Xen timer for CPU 1</div><div>[ =A0 37.439=
031] cpu 1 spinlock event irq 279</div><div>[ =A0 37.327214] Disabled fast =
string operations</div><div>[ =A0 37.458040] CPU1 is up</div><div>[ =A0 37.=
465417] ACPI: Waking up from system sleep state S3</div>
</div></div><div><br></div></div>

--14dae9340435d70fee04ca9ee429--


--===============0320081220717227132==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============0320081220717227132==--


From xen-devel-bounces@lists.xen.org Wed Sep 26 18:21:55 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Sep 2012 18: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 1TGwEy-0008QE-Ei; Wed, 26 Sep 2012 18:21:44 +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 1TGwEx-0008Pv-6R
	for xen-devel@lists.xen.org; Wed, 26 Sep 2012 18:21:43 +0000
Received: from [85.158.143.99:51371] by server-2.bemta-4.messagelabs.com id
	60/FE-06610-6B743605; Wed, 26 Sep 2012 18:21:42 +0000
X-Env-Sender: ben.guthro@gmail.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1348683700!31878267!1
X-Originating-IP: [209.85.223.173]
X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_20_30,HTML_MESSAGE,
	RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16728 invoked from network); 26 Sep 2012 18:21:41 -0000
Received: from mail-ie0-f173.google.com (HELO mail-ie0-f173.google.com)
	(209.85.223.173)
	by server-15.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Sep 2012 18:21:41 -0000
Received: by iea17 with SMTP id 17so2831169iea.32
	for <xen-devel@lists.xen.org>; Wed, 26 Sep 2012 11:21:39 -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=BLDY6hd1MYUM+ThOcYGvSLN0BuZgWDpzjeOoNg0E9VY=;
	b=Fbr3/Vp9cjbaJ4skSiMhe8SWDoYSOMNMIpaUQy8eO8Nd3LnDdxeX5ABe+5umkfJJ/r
	GEcm1vyEJtTqlHt3giCYTHNd+CZoklHa9IGkHcuoJoFSA1VaOhwX4wC8CGECB5ERhR8Z
	2xzgyN8NH5rcZmSk2lp2PKFym+r6GHglYV7xv98AE7XYt75zrAMTsh9x7PpI68TqllaF
	FRLT5tuPDhuPue4u+k6MihyWmUqrFn7BBtFaURa3Hd3/eVEjA8vTNkJGYJrGwQ2piqYU
	IdD+bwbPm7apJzJp9kKikNdu1tIzRe0EGluF6oE6VZgLziaWEC8GiLlpO9KhC3GQ7c5n
	jAAQ==
MIME-Version: 1.0
Received: by 10.50.183.200 with SMTP id eo8mr12098209igc.54.1348683699785;
	Wed, 26 Sep 2012 11:21:39 -0700 (PDT)
Received: by 10.64.55.132 with HTTP; Wed, 26 Sep 2012 11:21:39 -0700 (PDT)
In-Reply-To: <5062F880020000780009DF3B@nat28.tlf.novell.com>
References: <CAOvdn6UCF2A3yP1cqWn=dxwr0ayRbr+rg+xj8META9Dm0+CoNw@mail.gmail.com>
	<CC868168.3FD29%keir.xen@gmail.com>
	<CAOvdn6U-JyLvt96gkLkqzi088tU9_ktv4D+fkJac_BKVe05Y-w@mail.gmail.com>
	<CAOvdn6V+s3AbRzsu8VArbmrZou=im9SqvPf-9Wpif_BrNMv=yg@mail.gmail.com>
	<50617297020000780009D8AA@nat28.tlf.novell.com>
	<CAOvdn6Vsnbcd7m8mh3tSgn3KaEoeiOyVD1mr3uQ3bN=rF=pDUQ@mail.gmail.com>
	<5062F880020000780009DF3B@nat28.tlf.novell.com>
Date: Wed, 26 Sep 2012 14:21:39 -0400
X-Google-Sender-Auth: 3bDLA3GUv2hhIi6jiTaAJO1i3GU
Message-ID: <CAOvdn6VyAVg24=c1OxqttxuGFyN_NzpfZ7RoCYc2mVF84c5big@mail.gmail.com>
From: Ben Guthro <ben@guthro.net>
To: Jan Beulich <JBeulich@suse.com>
Cc: Keir Fraser <keir.xen@gmail.com>, John Baboval <john.baboval@citrix.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen4.2 S3 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: multipart/mixed; boundary="===============0320081220717227132=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============0320081220717227132==
Content-Type: multipart/alternative; boundary=14dae9340435d70fee04ca9ee429

--14dae9340435d70fee04ca9ee429
Content-Type: text/plain; charset=ISO-8859-1

On Wed, Sep 26, 2012 at 6:43 AM, Jan Beulich <JBeulich@suse.com> wrote:

>
> Btw., I'm also puzzled by only seeing a ucode update message
> here for CPU1 - I just went through the logic again and can't see
> why this would not also be done for CPU0. Could you make the
> pr_debug() in microcode_intel.c actually print something, so we
> can see whether at least collect_cpu_info() would get called
> for it, hopefully allowing to deduce what happens subsequently?
>
>
I put a pr_debug at the top of collect_cpu_info - and from the trace below
- it appears everything is as it should be,
dom0 and Xen serial output get interspersed there for a few lines, but the
microcode is, in fact being loaded for both CPUs.


[   36.787452] ACPI: Preparing to enter system sleep state S3
[   37.240118] PM: Saving platform NVS memory
[   37.313160] Disabling non-boot CPUs ...
(XEN) Preparing system for ACPI S3 state.
(XEN) Disabling non-boot CPUs ...
(XEN) Breaking vcpu affinity for domain 0 vcpu 1
(XEN) Entering ACPI S3 state.
(XEN) mce_intel.c:1239: MCA Capability: BCAST 1 SER 0 CMCI 0 firstbank 1
extended MCE MSR 0
(XEN) CMCI: CPU0 has no CMCI support
(XEN) CPU0: Thermal monitoring enabled (TM2)
(XEN) Finishing wakeup from ACPI S3 state.
(XEN) microcode: collect_cpu_info for CPU0
(XEN) microcode: collect_cpu_info : sig=0x10676, pf=0x80, rev=0x60c
(XEN) Enabling non-boot CPUs  ...
(XEN) Booting processor 1/1 eip 8a000
(XEN) Initializing CPU#1
(XEN) CPU: L1 I cache: 32K, L1 D cache: 32K
(XEN) CPU: L2 cache: 3072K
(XEN) CPU: Physical Processor ID: 0
(XEN) CPU: Processor Core ID: 1
(XEN) CMCI: CPU1 has no CMCI support
(XEN) CPU1: Thermal monitoring enabled (TM2)
(XEN) CPU1: Intel(R) Core(TM)2 Duo CPU     P8400  @ 2.26GHz stepping 06
(XEN) microcode: collect_cpu_info for CPU1
[   37.420030] A(XEN) microcode: collect_cpu_info : sig=0x10676, pf=0x80,
rev=0x60c
CPI: Low-level r(XEN) microcode: CPU1 found a matching microcode update
with version 0x60f (current=0x60c)
esume complete
(XEN) microcode: CPU1 updated from revision 0x60c to 0x60f, date =
2010-09-29
[   37.420030] PM: Restoring platform NVS memory
(XEN) microcode: collect_cpu_info for CPU0
(XEN) microcode: collect_cpu_info : sig=0x10676, pf=0x80, rev=0x60c
(XEN) microcode: collect_cpu_info for CPU1
(XEN) microcode: collect_cpu_info : sig=0x10676, pf=0x80, rev=0x60f
[   37.431008] Enabling non-boot CPUs ...
[   37.434851] installing Xen timer for CPU 1
[   37.439031] cpu 1 spinlock event irq 279
[   37.327214] Disabled fast string operations
[   37.458040] CPU1 is up
[   37.465417] ACPI: Waking up from system sleep state S3

--14dae9340435d70fee04ca9ee429
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div>On Wed, Sep 26, 2012 at 6:43 AM, Jan Beulich <span dir=3D"ltr">&lt;<a =
href=3D"mailto:JBeulich@suse.com" target=3D"_blank">JBeulich@suse.com</a>&g=
t;</span> wrote:</div><div class=3D"gmail_quote"><blockquote class=3D"gmail=
_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:=
1ex">
<div class=3D"im"><br>
</div>Btw., I&#39;m also puzzled by only seeing a ucode update message<br>
here for CPU1 - I just went through the logic again and can&#39;t see<br>
why this would not also be done for CPU0. Could you make the<br>
pr_debug() in microcode_intel.c actually print something, so we<br>
can see whether at least collect_cpu_info() would get called<br>
for it, hopefully allowing to deduce what happens subsequently?<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br></font></span></blockquo=
te><div><br></div><div>I put a pr_debug at the top of collect_cpu_info - an=
d from the trace below - it appears everything is as it should be,</div><di=
v>
dom0 and Xen serial output get interspersed there for a few lines, but the =
microcode is, in fact being loaded for both CPUs.</div><div><br></div><div>=
<div><br></div><div><div>[ =A0 36.787452] ACPI: Preparing to enter system s=
leep state S3</div>
<div>[ =A0 37.240118] PM: Saving platform NVS memory</div><div>[ =A0 37.313=
160] Disabling non-boot CPUs ...</div><div>(XEN) Preparing system for ACPI =
S3 state.</div><div>(XEN) Disabling non-boot CPUs ...</div><div>(XEN) Break=
ing vcpu affinity for domain 0 vcpu 1</div>
<div>(XEN) Entering ACPI S3 state.</div><div>(XEN) mce_intel.c:1239: MCA Ca=
pability: BCAST 1 SER 0 CMCI 0 firstbank 1 extended MCE MSR 0</div><div>(XE=
N) CMCI: CPU0 has no CMCI support</div><div>(XEN) CPU0: Thermal monitoring =
enabled (TM2)</div>
<div>(XEN) Finishing wakeup from ACPI S3 state.</div><div>(XEN) microcode: =
collect_cpu_info for CPU0</div><div>(XEN) microcode: collect_cpu_info : sig=
=3D0x10676, pf=3D0x80, rev=3D0x60c</div><div>(XEN) Enabling non-boot CPUs =
=A0...</div>
<div>(XEN) Booting processor 1/1 eip 8a000</div><div>(XEN) Initializing CPU=
#1</div><div>(XEN) CPU: L1 I cache: 32K, L1 D cache: 32K</div><div>(XEN) CP=
U: L2 cache: 3072K</div><div>(XEN) CPU: Physical Processor ID: 0</div><div>
(XEN) CPU: Processor Core ID: 1</div><div>(XEN) CMCI: CPU1 has no CMCI supp=
ort</div><div>(XEN) CPU1: Thermal monitoring enabled (TM2)</div><div>(XEN) =
CPU1: Intel(R) Core(TM)2 Duo CPU =A0 =A0 P8400 =A0@ 2.26GHz stepping 06</di=
v>
<div>(XEN) microcode: collect_cpu_info for CPU1</div><div>[ =A0 37.420030] =
A(XEN) microcode: collect_cpu_info : sig=3D0x10676, pf=3D0x80, rev=3D0x60c<=
/div><div>CPI: Low-level r(XEN) microcode: CPU1 found a matching microcode =
update with version 0x60f (current=3D0x60c)</div>
<div>esume complete</div><div>(XEN) microcode: CPU1 updated from revision 0=
x60c to 0x60f, date =3D 2010-09-29=A0</div><div>[ =A0 37.420030] PM: Restor=
ing platform NVS memory</div><div>(XEN) microcode: collect_cpu_info for CPU=
0</div>
<div>(XEN) microcode: collect_cpu_info : sig=3D0x10676, pf=3D0x80, rev=3D0x=
60c</div><div>(XEN) microcode: collect_cpu_info for CPU1</div><div>(XEN) mi=
crocode: collect_cpu_info : sig=3D0x10676, pf=3D0x80, rev=3D0x60f</div><div=
>[ =A0 37.431008] Enabling non-boot CPUs ...</div>
<div>[ =A0 37.434851] installing Xen timer for CPU 1</div><div>[ =A0 37.439=
031] cpu 1 spinlock event irq 279</div><div>[ =A0 37.327214] Disabled fast =
string operations</div><div>[ =A0 37.458040] CPU1 is up</div><div>[ =A0 37.=
465417] ACPI: Waking up from system sleep state S3</div>
</div></div><div><br></div></div>

--14dae9340435d70fee04ca9ee429--


--===============0320081220717227132==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============0320081220717227132==--


From xen-devel-bounces@lists.xen.org Wed Sep 26 18:41:00 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Sep 2012 18:41:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGwXQ-0000rC-Ek; Wed, 26 Sep 2012 18:40:48 +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 1TGwXO-0000r4-Ds
	for xen-devel@lists.xen.org; Wed, 26 Sep 2012 18:40:46 +0000
Received: from [85.158.139.83:22117] by server-11.bemta-5.messagelabs.com id
	14/6A-13866-D2C43605; Wed, 26 Sep 2012 18:40:45 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1348684842!27987819!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzE2MjI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5368 invoked from network); 26 Sep 2012 18:40:43 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-14.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Sep 2012 18:40:43 -0000
X-IronPort-AV: E=Sophos;i="4.80,491,1344211200"; d="scan'208";a="39273857"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Sep 2012 18:40:41 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 26 Sep 2012 14:40:41 -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 1TGw92-0001cN-GZ;
	Wed, 26 Sep 2012 19:15:36 +0100
From: Anthony PERARD <anthony.perard@citrix.com>
To: Xen Devel <xen-devel@lists.xen.org>
Date: Wed, 26 Sep 2012 19:15:25 +0100
Message-ID: <1348683325-12367-11-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.12.1
In-Reply-To: <1348683325-12367-1-git-send-email-anthony.perard@citrix.com>
References: <1348683325-12367-1-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Cc: Anthony PERARD <anthony.perard@citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH V3 10/10] libxl: Allow migration with qemu-xen.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
 tools/libxl/libxl.c | 17 -----------------
 1 file changed, 17 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index af3682f..0cf4768 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -767,23 +767,6 @@ int libxl_domain_suspend(libxl_ctx *ctx, uint32_t domid, int fd, int flags,
         goto out_err;
     }
 
-    if (type == LIBXL_DOMAIN_TYPE_HVM && flags & LIBXL_SUSPEND_LIVE) {
-        switch (libxl__device_model_version_running(gc, domid)) {
-        case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN:
-            LOG(ERROR,
-                "cannot live migrate HVM domains with qemu-xen device-model");
-            rc = ERROR_FAIL;
-            goto out_err;
-        case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL:
-            /* No problem */
-            break;
-        case -1:
-            rc = ERROR_FAIL;
-            goto out_err;
-        default: abort();
-        }
-    }
-
     libxl__domain_suspend_state *dss;
     GCNEW(dss);
 
-- 
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 Sep 26 18:41:00 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Sep 2012 18:41:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGwXQ-0000rC-Ek; Wed, 26 Sep 2012 18:40:48 +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 1TGwXO-0000r4-Ds
	for xen-devel@lists.xen.org; Wed, 26 Sep 2012 18:40:46 +0000
Received: from [85.158.139.83:22117] by server-11.bemta-5.messagelabs.com id
	14/6A-13866-D2C43605; Wed, 26 Sep 2012 18:40:45 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1348684842!27987819!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzE2MjI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5368 invoked from network); 26 Sep 2012 18:40:43 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-14.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Sep 2012 18:40:43 -0000
X-IronPort-AV: E=Sophos;i="4.80,491,1344211200"; d="scan'208";a="39273857"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Sep 2012 18:40:41 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 26 Sep 2012 14:40:41 -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 1TGw92-0001cN-GZ;
	Wed, 26 Sep 2012 19:15:36 +0100
From: Anthony PERARD <anthony.perard@citrix.com>
To: Xen Devel <xen-devel@lists.xen.org>
Date: Wed, 26 Sep 2012 19:15:25 +0100
Message-ID: <1348683325-12367-11-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.12.1
In-Reply-To: <1348683325-12367-1-git-send-email-anthony.perard@citrix.com>
References: <1348683325-12367-1-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Cc: Anthony PERARD <anthony.perard@citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH V3 10/10] libxl: Allow migration with qemu-xen.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
 tools/libxl/libxl.c | 17 -----------------
 1 file changed, 17 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index af3682f..0cf4768 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -767,23 +767,6 @@ int libxl_domain_suspend(libxl_ctx *ctx, uint32_t domid, int fd, int flags,
         goto out_err;
     }
 
-    if (type == LIBXL_DOMAIN_TYPE_HVM && flags & LIBXL_SUSPEND_LIVE) {
-        switch (libxl__device_model_version_running(gc, domid)) {
-        case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN:
-            LOG(ERROR,
-                "cannot live migrate HVM domains with qemu-xen device-model");
-            rc = ERROR_FAIL;
-            goto out_err;
-        case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL:
-            /* No problem */
-            break;
-        case -1:
-            rc = ERROR_FAIL;
-            goto out_err;
-        default: abort();
-        }
-    }
-
     libxl__domain_suspend_state *dss;
     GCNEW(dss);
 
-- 
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 Sep 26 18:59:54 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Sep 2012 18: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 1TGwpc-00011v-6c; Wed, 26 Sep 2012 18:59: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 1TGwpa-00011q-Hx
	for xen-devel@lists.xen.org; Wed, 26 Sep 2012 18:59:34 +0000
Received: from [85.158.143.35:55227] by server-3.bemta-4.messagelabs.com id
	AA/77-10986-59053605; Wed, 26 Sep 2012 18:59:33 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1348685973!20004091!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTE1NzQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18741 invoked from network); 26 Sep 2012 18:59:33 -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;
	26 Sep 2012 18:59:33 -0000
X-IronPort-AV: E=Sophos;i="4.80,491,1344211200"; d="scan'208";a="14786375"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Sep 2012 18:59:32 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 26 Sep 2012 19:59:32 +0100
Message-ID: <1348685971.18736.11.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Matt Wilson <msw@amazon.com>
Date: Wed, 26 Sep 2012 19:59:31 +0100
In-Reply-To: <20120926171540.GA24005@u002268147cd4502c336d.ant.amazon.com>
References: <CAFLBxZYtmJ_bKFb90r45=C4Pq1-oe5Fy=eygSsQf4BcGj3EqGA@mail.gmail.com>
	<505ADBCF020000780009C7BE@nat28.tlf.novell.com>
	<20120921031759.GA3953@u002268147cd4502c336d.ant.amazon.com>
	<5062CCA5.8010903@eu.citrix.com>
	<4B45B535F7F6BE4CB1C044ED5115CDDE011A6DD0105E@LONPMAILBOX01.citrite.net>
	<20120926171540.GA24005@u002268147cd4502c336d.ant.amazon.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	Thanos Makatos <thanos.makatos@citrix.com>,
	Jan Beulich <JBeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.3 development 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-09-26 at 18:15 +0100, Matt Wilson wrote:
> On Wed, Sep 26, 2012 at 11:25:54AM +0100, Thanos Makatos wrote:
> > > -----Original Message-----
> > > From: George Dunlap [mailto:george.dunlap@eu.citrix.com]
> > > Sent: 26 September 2012 10:37
> > > To: Matt Wilson
> > > Cc: Jan Beulich; xen-devel@lists.xen.org; Thanos Makatos
> > > Subject: Re: [Xen-devel] Xen 4.3 development update
> > > 
> > > On 21/09/12 04:18, Matt Wilson wrote:
> > > > On Thu, Sep 20, 2012 at 08:03:11AM +0100, Jan Beulich wrote:
> > > >>> On 19.09.12 at 18:58, George Dunlap <George.Dunlap@eu.citrix.com>
> > > wrote:
> > > >>> * Persistent grants
> > > >>>    owner: @citrix
> > > >>>    status: ?
> > > >> Isn't that a guest side only thing (i.e. not really to be tracked
> > > >> here)? Or does that mean migrating active grants?
> > > > I'd assume that the device would be renegotiated during migration,
> > > and
> > > > that new grants would be established during the re-connect sequence.
> > > >
> > > > One question I have is how persistent grants intersect with blktap3.
> > > > Will a persistent grant-capable blktap3 implementation be in scope
> > > for
> > > > 4.3?
> > > Thanos is working on blktap3 -- Thanos, can you comment?
> > 
> > Supporting this in 4.3 is not top priority; however I'll do it if I
> > have time.
> 
> I brought this up in response to Jan's question as to if persistent
> grants should be on the 4.3 release plan. With the introduction of
> blktap3, we have a separate implementation of the protocol in a Xen
> component. One worry I have about blktap3 is that it will lag behind
> the in-kernel blkback implementation.

We already have multiple block backend implementations (blktap1,
blktap2, qdisk, non-Linux dom0s), so I don't think that is a new
concern.

If anything blktap3 improves things by making blktap1 + 2 obsolete, plus
it comes with an active maintainer!

I think getting a working blktap3 implementation of the basic blk
protocol for 4.3 is a big enough chunk of work in its own right, it's
more than enough to fill someone's time for one release cycle IMHO.

So, I don't think implementing extensions (persistent grants, multipage
rings etc) need to be a requirement for blktap3 in 4.3, there's always
4.4 and beyond. Of course if someone wants to contribute patches I'm
sure Thanos would be very pleased ;-)

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 26 18:59:54 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Sep 2012 18: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 1TGwpc-00011v-6c; Wed, 26 Sep 2012 18:59: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 1TGwpa-00011q-Hx
	for xen-devel@lists.xen.org; Wed, 26 Sep 2012 18:59:34 +0000
Received: from [85.158.143.35:55227] by server-3.bemta-4.messagelabs.com id
	AA/77-10986-59053605; Wed, 26 Sep 2012 18:59:33 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1348685973!20004091!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTE1NzQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18741 invoked from network); 26 Sep 2012 18:59:33 -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;
	26 Sep 2012 18:59:33 -0000
X-IronPort-AV: E=Sophos;i="4.80,491,1344211200"; d="scan'208";a="14786375"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Sep 2012 18:59:32 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Wed, 26 Sep 2012 19:59:32 +0100
Message-ID: <1348685971.18736.11.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Matt Wilson <msw@amazon.com>
Date: Wed, 26 Sep 2012 19:59:31 +0100
In-Reply-To: <20120926171540.GA24005@u002268147cd4502c336d.ant.amazon.com>
References: <CAFLBxZYtmJ_bKFb90r45=C4Pq1-oe5Fy=eygSsQf4BcGj3EqGA@mail.gmail.com>
	<505ADBCF020000780009C7BE@nat28.tlf.novell.com>
	<20120921031759.GA3953@u002268147cd4502c336d.ant.amazon.com>
	<5062CCA5.8010903@eu.citrix.com>
	<4B45B535F7F6BE4CB1C044ED5115CDDE011A6DD0105E@LONPMAILBOX01.citrite.net>
	<20120926171540.GA24005@u002268147cd4502c336d.ant.amazon.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.4.3-1 
MIME-Version: 1.0
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	Thanos Makatos <thanos.makatos@citrix.com>,
	Jan Beulich <JBeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.3 development 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-09-26 at 18:15 +0100, Matt Wilson wrote:
> On Wed, Sep 26, 2012 at 11:25:54AM +0100, Thanos Makatos wrote:
> > > -----Original Message-----
> > > From: George Dunlap [mailto:george.dunlap@eu.citrix.com]
> > > Sent: 26 September 2012 10:37
> > > To: Matt Wilson
> > > Cc: Jan Beulich; xen-devel@lists.xen.org; Thanos Makatos
> > > Subject: Re: [Xen-devel] Xen 4.3 development update
> > > 
> > > On 21/09/12 04:18, Matt Wilson wrote:
> > > > On Thu, Sep 20, 2012 at 08:03:11AM +0100, Jan Beulich wrote:
> > > >>> On 19.09.12 at 18:58, George Dunlap <George.Dunlap@eu.citrix.com>
> > > wrote:
> > > >>> * Persistent grants
> > > >>>    owner: @citrix
> > > >>>    status: ?
> > > >> Isn't that a guest side only thing (i.e. not really to be tracked
> > > >> here)? Or does that mean migrating active grants?
> > > > I'd assume that the device would be renegotiated during migration,
> > > and
> > > > that new grants would be established during the re-connect sequence.
> > > >
> > > > One question I have is how persistent grants intersect with blktap3.
> > > > Will a persistent grant-capable blktap3 implementation be in scope
> > > for
> > > > 4.3?
> > > Thanos is working on blktap3 -- Thanos, can you comment?
> > 
> > Supporting this in 4.3 is not top priority; however I'll do it if I
> > have time.
> 
> I brought this up in response to Jan's question as to if persistent
> grants should be on the 4.3 release plan. With the introduction of
> blktap3, we have a separate implementation of the protocol in a Xen
> component. One worry I have about blktap3 is that it will lag behind
> the in-kernel blkback implementation.

We already have multiple block backend implementations (blktap1,
blktap2, qdisk, non-Linux dom0s), so I don't think that is a new
concern.

If anything blktap3 improves things by making blktap1 + 2 obsolete, plus
it comes with an active maintainer!

I think getting a working blktap3 implementation of the basic blk
protocol for 4.3 is a big enough chunk of work in its own right, it's
more than enough to fill someone's time for one release cycle IMHO.

So, I don't think implementing extensions (persistent grants, multipage
rings etc) need to be a requirement for blktap3 in 4.3, there's always
4.4 and beyond. Of course if someone wants to contribute patches I'm
sure Thanos would be very pleased ;-)

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 26 20:47:33 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Sep 2012 20:47:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGyVc-0002cc-P3; Wed, 26 Sep 2012 20:47:04 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jmarcet@gmail.com>) id 1TGyVa-0002cX-Hv
	for xen-devel@lists.xen.org; Wed, 26 Sep 2012 20:47:03 +0000
Received: from [85.158.139.211:4808] by server-1.bemta-5.messagelabs.com id
	83/70-09825-5C963605; Wed, 26 Sep 2012 20:47:01 +0000
X-Env-Sender: jmarcet@gmail.com
X-Msg-Ref: server-6.tower-206.messagelabs.com!1348692419!20096474!1
X-Originating-IP: [209.85.223.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-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20034 invoked from network); 26 Sep 2012 20:47:00 -0000
Received: from mail-ie0-f173.google.com (HELO mail-ie0-f173.google.com)
	(209.85.223.173)
	by server-6.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Sep 2012 20:47:00 -0000
Received: by iea17 with SMTP id 17so3293913iea.32
	for <xen-devel@lists.xen.org>; Wed, 26 Sep 2012 13:46:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to
	:content-type; bh=+UpuOESZROzYn47uCv98ZJ8xEO+KhCNqIFh5hQCdiUA=;
	b=Rjz5vi0BwJv+pP0Q+cG6NaK5F4p9fLr55UGJ2mDNIC9maZYzAn/6JsbZGzpthiHyqd
	+bjgAd61EwAEfH5XHhi9AqeNEpiMgx3jIfeLfUQRJKgPDG/CPqF2Ug4WeVqd3yK0SxWo
	SiR5JKd9EEBBb4Aq3YV4xy/gTOVTvJFDNHSYHf7bEzmqcPmwJHPSDx55RYq4J8W/aNni
	1V4Sml7rgB/TPWDLcIeAz9CIEKpwDDkf2k1qtSBSDUHuK1vpGssuMcI6GD2wumKF8q2x
	LMQE5Y4rIZVeXAVGjJewByN7SkiP02iX3RuLbnWHikHDp+9cMQAwNfG3fqHdg0Gplv55
	2M9w==
Received: by 10.50.183.200 with SMTP id eo8mr12458663igc.54.1348692418838;
	Wed, 26 Sep 2012 13:46:58 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.64.107.10 with HTTP; Wed, 26 Sep 2012 13:46:38 -0700 (PDT)
In-Reply-To: <CAAnFQG9YZ0bsr=QnHaRxKTwNSCJvRiZ4ddCEMpsOZMNN+j7+vg@mail.gmail.com>
References: <CAAnFQG9YZ0bsr=QnHaRxKTwNSCJvRiZ4ddCEMpsOZMNN+j7+vg@mail.gmail.com>
From: Javier Marcet <jmarcet@gmail.com>
Date: Wed, 26 Sep 2012 22:46:38 +0200
Message-ID: <CAAnFQG-SpgvO+MLuUmBYW+dvO54mSi9WE4885-k7q5x3rGwBLA@mail.gmail.com>
To: Xen Devel Mailing list <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Back trace from rcutree.c after resuming from S3
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Sep 18, 2012 at 8:57 PM, Javier Marcet <jmarcet@gmail.com> wrote:

> after solving the issue I had with a DVB tuner I tested again
> suspending and resuming from S3.
>
> I am now running Xen 4.2.0 and have applied patches [1] and [2] (any
> idea why they are still not in mainline?) over a 3.5.3 kernel. I only
> tried once since I upgraded my Xen, but after resuming I got the
> following back trace:
>
> [  142.267299] pcieport 0000:00:1c.5: wake-up capability enabled by ACPI
> [  142.278312] ehci_hcd 0000:00:1d.0: wake-up capability enabled by ACPI
> [  142.289169] ehci_hcd 0000:00:1a.0: wake-up capability enabled by ACPI
> [  142.311116] xhci_hcd 0000:00:14.0: wake-up capability enabled by ACPI
> [  142.322209] PM: noirq suspend of devices complete after 55.650 msecs
> [  142.322778] ACPI: Preparing to enter system sleep state S3
> [  142.723286] PM: Saving platform NVS memory
> [  142.736453] Disabling non-boot CPUs ...
> [  142.851387] ------------[ cut here ]------------
> [  142.851397] WARNING: at
> /home/storage/src/ubuntu-precise/kernel/rcutree.c:1550
> rcu_do_batch.isra.41+0x5f/0x213()
> [  142.851401] Hardware name: To Be Filled By O.E.M.
> [  142.851404] Modules linked in: blktap(O) ip6table_filter ip6_tables
> ipt_MASQUERADE iptable_nat nf_nat nf_conntrack_ipv4 nf_defrag_ipv4
> xt_state nf_conntrack ipt_REJECT xt_CHECKSUM iptable_mangle xt_tcpudp
> iptable_filter ip_tables x_tables [last unloaded: cx25840]
> [  142.851466] Pid: 32, comm: migration/7 Tainted: G           O
> 3.5.0-14-i7 #18~precise1
> [  142.851469] Call Trace:
> [  142.851473]  <IRQ>  [<ffffffff8106a9bd>] warn_slowpath_common+0x7e/0x96
> [  142.851488]  [<ffffffff8106a9ea>] warn_slowpath_null+0x15/0x17
> [  142.851496]  [<ffffffff810c6e87>] rcu_do_batch.isra.41+0x5f/0x213
> [  142.851504]  [<ffffffff810c687f>] ?
> check_for_new_grace_period.isra.35+0x38/0x44
> [  142.851512]  [<ffffffff810c7101>] __rcu_process_callbacks+0xc6/0xee
> [  142.851520]  [<ffffffff810c7149>] rcu_process_callbacks+0x20/0x3e
> [  142.851527]  [<ffffffff81070c27>] __do_softirq+0x87/0x113
> [  142.851536]  [<ffffffff812e7b22>] ? __xen_evtchn_do_upcall+0x1a0/0x1dd
> [  142.851546]  [<ffffffff8162f05c>] call_softirq+0x1c/0x30
> [  142.851557]  [<ffffffff810343a3>] do_softirq+0x41/0x7e
> [  142.851566]  [<ffffffff81070e66>] irq_exit+0x3f/0x9a
> [  142.851573]  [<ffffffff812e95c9>] xen_evtchn_do_upcall+0x2c/0x39
> [  142.851580]  [<ffffffff8162f0ae>] xen_do_hypervisor_callback+0x1e/0x30
> [  142.851588]  <EOI>  [<ffffffff8100122a>] ? hypercall_page+0x22a/0x1000
> [  142.851601]  [<ffffffff8100122a>] ? hypercall_page+0x22a/0x1000
> [  142.851609]  [<ffffffff8102eee9>] ? xen_force_evtchn_callback+0xd/0xf
> [  142.851618]  [<ffffffff8102f552>] ? check_events+0x12/0x20
> [  142.851627]  [<ffffffff8102f53f>] ? xen_restore_fl_direct_reloc+0x4/0x4
> [  142.851635]  [<ffffffff810b6ff4>] ? arch_local_irq_restore+0xb/0xd
> [  142.851644]  [<ffffffff810b73f4>] ? stop_machine_cpu_stop+0xc1/0xd3
> [  142.851652]  [<ffffffff810b7333>] ? queue_stop_cpus_work+0xb5/0xb5
> [  142.851660]  [<ffffffff810b7152>] ? cpu_stopper_thread+0xf7/0x187
> [  142.851667]  [<ffffffff8108a927>] ? finish_task_switch+0x82/0xc1
> [  142.851676]  [<ffffffff8162c50b>] ? __schedule+0x428/0x454
> [  142.851685]  [<ffffffff8162cff0>] ? _raw_spin_unlock_irqrestore+0x15/0x18
> [  142.851693]  [<ffffffff810b705b>] ? cpu_stop_signal_done+0x30/0x30
> [  142.851701]  [<ffffffff81082627>] ? kthread+0x86/0x8e
> [  142.851710]  [<ffffffff8162ef64>] ? kernel_thread_helper+0x4/0x10
> [  142.851718]  [<ffffffff8162d338>] ? retint_restore_args+0x5/0x6
> [  142.851726]  [<ffffffff8162ef60>] ? gs_change+0x13/0x13
> [  142.851736] ---[ end trace 3722a99bcc5ae37a ]---
> [  144.257229] ACPI: Low-level resume complete
> [  144.257322] PM: Restoring platform NVS memory
> [  144.257866] Enabling non-boot CPUs ...
> [  144.258042] installing Xen timer for CPU 1
> [  144.258080] cpu 1 spinlock event irq 48
> [  144.322077] CPU1 is up
> [  144.322352] installing Xen timer for CPU 2
> [  144.322379] cpu 2 spinlock event irq 55
> [  144.340819] CPU2 is up
> [  144.340940] installing Xen timer for CPU 3
> [  144.340968] cpu 3 spinlock event irq 62
> [  144.404393] CPU3 is up
> [  144.404522] installing Xen timer for CPU 4
> [  144.404548] cpu 4 spinlock event irq 69
> [  144.468656] CPU4 is up
> [  144.468780] installing Xen timer for CPU 5
> [  144.468807] cpu 5 spinlock event irq 76
> [  144.532834] CPU5 is up
> [  144.532959] installing Xen timer for CPU 6
> [  144.532986] cpu 6 spinlock event irq 83
> [  144.597255] CPU6 is up
> [  144.597481] installing Xen timer for CPU 7
> [  144.597509] cpu 7 spinlock event irq 90
> [  144.661253] CPU7 is up
> [  144.662834] ACPI: Waking up from system sleep state S3
>
> [1] https://patchwork.kernel.org/patch/1120842/
> [2] https://patchwork.kernel.org/patch/1120872/

With Jen's patch still applied on my xen, besides the other two quoted
above on a 3.5.4 kernel, I tried putting offline and back online 4 of
my 8 cores and didn't have a single issue. Resuming from S3, on the
other hand, is completely random. Most of the times I get the above
backtrace, sometimes it works perfectly and a few other times it
doesn't even resume but directly reboots.


-- 
Javier Marcet <jmarcet@gmail.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 26 20:47:33 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Sep 2012 20:47:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGyVc-0002cc-P3; Wed, 26 Sep 2012 20:47:04 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jmarcet@gmail.com>) id 1TGyVa-0002cX-Hv
	for xen-devel@lists.xen.org; Wed, 26 Sep 2012 20:47:03 +0000
Received: from [85.158.139.211:4808] by server-1.bemta-5.messagelabs.com id
	83/70-09825-5C963605; Wed, 26 Sep 2012 20:47:01 +0000
X-Env-Sender: jmarcet@gmail.com
X-Msg-Ref: server-6.tower-206.messagelabs.com!1348692419!20096474!1
X-Originating-IP: [209.85.223.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-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20034 invoked from network); 26 Sep 2012 20:47:00 -0000
Received: from mail-ie0-f173.google.com (HELO mail-ie0-f173.google.com)
	(209.85.223.173)
	by server-6.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Sep 2012 20:47:00 -0000
Received: by iea17 with SMTP id 17so3293913iea.32
	for <xen-devel@lists.xen.org>; Wed, 26 Sep 2012 13:46:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to
	:content-type; bh=+UpuOESZROzYn47uCv98ZJ8xEO+KhCNqIFh5hQCdiUA=;
	b=Rjz5vi0BwJv+pP0Q+cG6NaK5F4p9fLr55UGJ2mDNIC9maZYzAn/6JsbZGzpthiHyqd
	+bjgAd61EwAEfH5XHhi9AqeNEpiMgx3jIfeLfUQRJKgPDG/CPqF2Ug4WeVqd3yK0SxWo
	SiR5JKd9EEBBb4Aq3YV4xy/gTOVTvJFDNHSYHf7bEzmqcPmwJHPSDx55RYq4J8W/aNni
	1V4Sml7rgB/TPWDLcIeAz9CIEKpwDDkf2k1qtSBSDUHuK1vpGssuMcI6GD2wumKF8q2x
	LMQE5Y4rIZVeXAVGjJewByN7SkiP02iX3RuLbnWHikHDp+9cMQAwNfG3fqHdg0Gplv55
	2M9w==
Received: by 10.50.183.200 with SMTP id eo8mr12458663igc.54.1348692418838;
	Wed, 26 Sep 2012 13:46:58 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.64.107.10 with HTTP; Wed, 26 Sep 2012 13:46:38 -0700 (PDT)
In-Reply-To: <CAAnFQG9YZ0bsr=QnHaRxKTwNSCJvRiZ4ddCEMpsOZMNN+j7+vg@mail.gmail.com>
References: <CAAnFQG9YZ0bsr=QnHaRxKTwNSCJvRiZ4ddCEMpsOZMNN+j7+vg@mail.gmail.com>
From: Javier Marcet <jmarcet@gmail.com>
Date: Wed, 26 Sep 2012 22:46:38 +0200
Message-ID: <CAAnFQG-SpgvO+MLuUmBYW+dvO54mSi9WE4885-k7q5x3rGwBLA@mail.gmail.com>
To: Xen Devel Mailing list <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Back trace from rcutree.c after resuming from S3
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Tue, Sep 18, 2012 at 8:57 PM, Javier Marcet <jmarcet@gmail.com> wrote:

> after solving the issue I had with a DVB tuner I tested again
> suspending and resuming from S3.
>
> I am now running Xen 4.2.0 and have applied patches [1] and [2] (any
> idea why they are still not in mainline?) over a 3.5.3 kernel. I only
> tried once since I upgraded my Xen, but after resuming I got the
> following back trace:
>
> [  142.267299] pcieport 0000:00:1c.5: wake-up capability enabled by ACPI
> [  142.278312] ehci_hcd 0000:00:1d.0: wake-up capability enabled by ACPI
> [  142.289169] ehci_hcd 0000:00:1a.0: wake-up capability enabled by ACPI
> [  142.311116] xhci_hcd 0000:00:14.0: wake-up capability enabled by ACPI
> [  142.322209] PM: noirq suspend of devices complete after 55.650 msecs
> [  142.322778] ACPI: Preparing to enter system sleep state S3
> [  142.723286] PM: Saving platform NVS memory
> [  142.736453] Disabling non-boot CPUs ...
> [  142.851387] ------------[ cut here ]------------
> [  142.851397] WARNING: at
> /home/storage/src/ubuntu-precise/kernel/rcutree.c:1550
> rcu_do_batch.isra.41+0x5f/0x213()
> [  142.851401] Hardware name: To Be Filled By O.E.M.
> [  142.851404] Modules linked in: blktap(O) ip6table_filter ip6_tables
> ipt_MASQUERADE iptable_nat nf_nat nf_conntrack_ipv4 nf_defrag_ipv4
> xt_state nf_conntrack ipt_REJECT xt_CHECKSUM iptable_mangle xt_tcpudp
> iptable_filter ip_tables x_tables [last unloaded: cx25840]
> [  142.851466] Pid: 32, comm: migration/7 Tainted: G           O
> 3.5.0-14-i7 #18~precise1
> [  142.851469] Call Trace:
> [  142.851473]  <IRQ>  [<ffffffff8106a9bd>] warn_slowpath_common+0x7e/0x96
> [  142.851488]  [<ffffffff8106a9ea>] warn_slowpath_null+0x15/0x17
> [  142.851496]  [<ffffffff810c6e87>] rcu_do_batch.isra.41+0x5f/0x213
> [  142.851504]  [<ffffffff810c687f>] ?
> check_for_new_grace_period.isra.35+0x38/0x44
> [  142.851512]  [<ffffffff810c7101>] __rcu_process_callbacks+0xc6/0xee
> [  142.851520]  [<ffffffff810c7149>] rcu_process_callbacks+0x20/0x3e
> [  142.851527]  [<ffffffff81070c27>] __do_softirq+0x87/0x113
> [  142.851536]  [<ffffffff812e7b22>] ? __xen_evtchn_do_upcall+0x1a0/0x1dd
> [  142.851546]  [<ffffffff8162f05c>] call_softirq+0x1c/0x30
> [  142.851557]  [<ffffffff810343a3>] do_softirq+0x41/0x7e
> [  142.851566]  [<ffffffff81070e66>] irq_exit+0x3f/0x9a
> [  142.851573]  [<ffffffff812e95c9>] xen_evtchn_do_upcall+0x2c/0x39
> [  142.851580]  [<ffffffff8162f0ae>] xen_do_hypervisor_callback+0x1e/0x30
> [  142.851588]  <EOI>  [<ffffffff8100122a>] ? hypercall_page+0x22a/0x1000
> [  142.851601]  [<ffffffff8100122a>] ? hypercall_page+0x22a/0x1000
> [  142.851609]  [<ffffffff8102eee9>] ? xen_force_evtchn_callback+0xd/0xf
> [  142.851618]  [<ffffffff8102f552>] ? check_events+0x12/0x20
> [  142.851627]  [<ffffffff8102f53f>] ? xen_restore_fl_direct_reloc+0x4/0x4
> [  142.851635]  [<ffffffff810b6ff4>] ? arch_local_irq_restore+0xb/0xd
> [  142.851644]  [<ffffffff810b73f4>] ? stop_machine_cpu_stop+0xc1/0xd3
> [  142.851652]  [<ffffffff810b7333>] ? queue_stop_cpus_work+0xb5/0xb5
> [  142.851660]  [<ffffffff810b7152>] ? cpu_stopper_thread+0xf7/0x187
> [  142.851667]  [<ffffffff8108a927>] ? finish_task_switch+0x82/0xc1
> [  142.851676]  [<ffffffff8162c50b>] ? __schedule+0x428/0x454
> [  142.851685]  [<ffffffff8162cff0>] ? _raw_spin_unlock_irqrestore+0x15/0x18
> [  142.851693]  [<ffffffff810b705b>] ? cpu_stop_signal_done+0x30/0x30
> [  142.851701]  [<ffffffff81082627>] ? kthread+0x86/0x8e
> [  142.851710]  [<ffffffff8162ef64>] ? kernel_thread_helper+0x4/0x10
> [  142.851718]  [<ffffffff8162d338>] ? retint_restore_args+0x5/0x6
> [  142.851726]  [<ffffffff8162ef60>] ? gs_change+0x13/0x13
> [  142.851736] ---[ end trace 3722a99bcc5ae37a ]---
> [  144.257229] ACPI: Low-level resume complete
> [  144.257322] PM: Restoring platform NVS memory
> [  144.257866] Enabling non-boot CPUs ...
> [  144.258042] installing Xen timer for CPU 1
> [  144.258080] cpu 1 spinlock event irq 48
> [  144.322077] CPU1 is up
> [  144.322352] installing Xen timer for CPU 2
> [  144.322379] cpu 2 spinlock event irq 55
> [  144.340819] CPU2 is up
> [  144.340940] installing Xen timer for CPU 3
> [  144.340968] cpu 3 spinlock event irq 62
> [  144.404393] CPU3 is up
> [  144.404522] installing Xen timer for CPU 4
> [  144.404548] cpu 4 spinlock event irq 69
> [  144.468656] CPU4 is up
> [  144.468780] installing Xen timer for CPU 5
> [  144.468807] cpu 5 spinlock event irq 76
> [  144.532834] CPU5 is up
> [  144.532959] installing Xen timer for CPU 6
> [  144.532986] cpu 6 spinlock event irq 83
> [  144.597255] CPU6 is up
> [  144.597481] installing Xen timer for CPU 7
> [  144.597509] cpu 7 spinlock event irq 90
> [  144.661253] CPU7 is up
> [  144.662834] ACPI: Waking up from system sleep state S3
>
> [1] https://patchwork.kernel.org/patch/1120842/
> [2] https://patchwork.kernel.org/patch/1120872/

With Jen's patch still applied on my xen, besides the other two quoted
above on a 3.5.4 kernel, I tried putting offline and back online 4 of
my 8 cores and didn't have a single issue. Resuming from S3, on the
other hand, is completely random. Most of the times I get the above
backtrace, sometimes it works perfectly and a few other times it
doesn't even resume but directly reboots.


-- 
Javier Marcet <jmarcet@gmail.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 26 21:17:58 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Sep 2012 21: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 1TGyz3-0002yG-In; Wed, 26 Sep 2012 21:17:29 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dan.magenheimer@oracle.com>) id 1TGyz1-0002yB-Vt
	for xen-devel@lists.xen.org; Wed, 26 Sep 2012 21:17:28 +0000
X-Env-Sender: dan.magenheimer@oracle.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1348694240!6404086!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzY1NzE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9882 invoked from network); 26 Sep 2012 21:17:21 -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; 26 Sep 2012 21:17:21 -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 q8QLHJux010264
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK)
	for <xen-devel@lists.xen.org>; Wed, 26 Sep 2012 21:17:20 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
	q8QLHHDe026490
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for <xen-devel@lists.xen.org>; Wed, 26 Sep 2012 21:17:19 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
	q8QLHHl6028407
	for <xen-devel@lists.xen.org>; Wed, 26 Sep 2012 16:17:17 -0500
MIME-Version: 1.0
Message-ID: <53b8c758-2675-42a7-b63f-4f9ad0006d84@default>
Date: Wed, 26 Sep 2012 14:17:06 -0700 (PDT)
From: Dan Magenheimer <dan.magenheimer@oracle.com>
To: xen-devel@lists.xen.org
X-Priority: 3
X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.7  (607090) [OL
	12.0.6661.5003 (x86)]
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: Kurt Hackel <kurt.hackel@oracle.com>, Konrad Wilk <konrad.wilk@oracle.com>
Subject: [Xen-devel] domain creation vs querying free memory (xend and 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

I was asked a question that seems like it should be obvious
but it doesn't seem to be, at least in xm-land.  I'll look
into it further, as well as for xl, but I thought I'd ask
first to see if there is a known answer or if this is a known
problem:

Suppose that xm/xl create is issued on a large-memory
domain (PV or HVM or, future, PVH).  It takes awhile
for this domain to launch and during at least part of this
time, the toolset hasn't yet requested all of the
required memory from the hypervisor to complete the
launch of the domain...  or perhaps the toolset has,
but the hypervisor is slow about calling the long sequence
of page allocations (e.g. maybe because it is zeroing
each page?).

Then it is desired to launch a second large-memory domain.
The tools can query Xen to see if there is sufficient RAM
and there is, because the first launch has not yet
allocated all the RAM assigned to it.

But the second domain launch fails, possibly after
several minutes because, actually, there isn't enough
physical RAM for both.

Does this make sense?  Should the tools "reserve"
maxmem as a "transaction" and/or ensure that "xm/xl
free" calls account for the entire requested amount
of RAM?  Or maybe xl _does_ work this way?

Thanks for any comments or discussion!

Dan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 26 21:17:58 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Sep 2012 21: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 1TGyz3-0002yG-In; Wed, 26 Sep 2012 21:17:29 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dan.magenheimer@oracle.com>) id 1TGyz1-0002yB-Vt
	for xen-devel@lists.xen.org; Wed, 26 Sep 2012 21:17:28 +0000
X-Env-Sender: dan.magenheimer@oracle.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1348694240!6404086!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzY1NzE4\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9882 invoked from network); 26 Sep 2012 21:17:21 -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; 26 Sep 2012 21:17:21 -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 q8QLHJux010264
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK)
	for <xen-devel@lists.xen.org>; Wed, 26 Sep 2012 21:17:20 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
	q8QLHHDe026490
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for <xen-devel@lists.xen.org>; Wed, 26 Sep 2012 21:17:19 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
	q8QLHHl6028407
	for <xen-devel@lists.xen.org>; Wed, 26 Sep 2012 16:17:17 -0500
MIME-Version: 1.0
Message-ID: <53b8c758-2675-42a7-b63f-4f9ad0006d84@default>
Date: Wed, 26 Sep 2012 14:17:06 -0700 (PDT)
From: Dan Magenheimer <dan.magenheimer@oracle.com>
To: xen-devel@lists.xen.org
X-Priority: 3
X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.7  (607090) [OL
	12.0.6661.5003 (x86)]
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: Kurt Hackel <kurt.hackel@oracle.com>, Konrad Wilk <konrad.wilk@oracle.com>
Subject: [Xen-devel] domain creation vs querying free memory (xend and 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

I was asked a question that seems like it should be obvious
but it doesn't seem to be, at least in xm-land.  I'll look
into it further, as well as for xl, but I thought I'd ask
first to see if there is a known answer or if this is a known
problem:

Suppose that xm/xl create is issued on a large-memory
domain (PV or HVM or, future, PVH).  It takes awhile
for this domain to launch and during at least part of this
time, the toolset hasn't yet requested all of the
required memory from the hypervisor to complete the
launch of the domain...  or perhaps the toolset has,
but the hypervisor is slow about calling the long sequence
of page allocations (e.g. maybe because it is zeroing
each page?).

Then it is desired to launch a second large-memory domain.
The tools can query Xen to see if there is sufficient RAM
and there is, because the first launch has not yet
allocated all the RAM assigned to it.

But the second domain launch fails, possibly after
several minutes because, actually, there isn't enough
physical RAM for both.

Does this make sense?  Should the tools "reserve"
maxmem as a "transaction" and/or ensure that "xm/xl
free" calls account for the entire requested amount
of RAM?  Or maybe xl _does_ work this way?

Thanks for any comments or discussion!

Dan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 26 21:31:01 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Sep 2012 21: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 1TGzBi-00038D-0o; Wed, 26 Sep 2012 21:30:34 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <arvind.viswanathan@gmail.com>) id 1TGz7J-00037Q-4n
	for xen-devel@lists.xen.org; Wed, 26 Sep 2012 21:26:01 +0000
Received: from [85.158.139.83:8770] by server-2.bemta-5.messagelabs.com id
	66/A7-28944-8E273605; Wed, 26 Sep 2012 21:26:00 +0000
X-Env-Sender: arvind.viswanathan@gmail.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1348694759!24938900!1
X-Originating-IP: [209.85.215.45]
X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_10_20,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31122 invoked from network); 26 Sep 2012 21:25:59 -0000
Received: from mail-la0-f45.google.com (HELO mail-la0-f45.google.com)
	(209.85.215.45)
	by server-16.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Sep 2012 21:25:59 -0000
Received: by lahm13 with SMTP id m13so166709lah.32
	for <xen-devel@lists.xen.org>; Wed, 26 Sep 2012 14:25:59 -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=OF8wUo2WF7Thg+1j0EFBFPUlBtZRKbfcCYPyNCaQcls=;
	b=jYT7KEwr1ZNC6400r31+kBoByw3Ckn3mWI8W9abcq9zaenAQPvjB6L6NX3TXyWu+mK
	o0fD3vXxNWPlJVbNx/QZ0U+r1oqs6R+8/p265h+SNScq2RH9YAIVWE0K+IECFLExpUO8
	nOEMc88IGaIaESLwDWC4Iri7TfEJA+x940WBcJI8STt9/njwomoDhHTzNCh2yNysC9me
	ziugRT8Govk43A4GOAK2cvndZPDbm1sodzJG6EQZO2gAEqhYLTaBl6GTgSqmuP9cqXJc
	0D+kXDWrwKIh4MQAx78Jt28VjxkjV2cn+fTrIN86kLkBk40XBQumsUtGlcGvg1vcJ6B5
	bSWQ==
MIME-Version: 1.0
Received: by 10.152.111.227 with SMTP id il3mr1639587lab.23.1348694759033;
	Wed, 26 Sep 2012 14:25:59 -0700 (PDT)
Received: by 10.112.43.198 with HTTP; Wed, 26 Sep 2012 14:25:58 -0700 (PDT)
Date: Wed, 26 Sep 2012 14:25:58 -0700
Message-ID: <CAFOzg+HARCb6UN5yu3hmsDRNVyLmwv0rnw6z2+E8b=5mtKqPFQ@mail.gmail.com>
From: arvind viswanathan <arvind.viswanathan@gmail.com>
To: xen-devel@lists.xen.org
X-Mailman-Approved-At: Wed, 26 Sep 2012 21:30:32 +0000
Subject: [Xen-devel] xen PVHVM
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============7477969636917175344=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============7477969636917175344==
Content-Type: multipart/alternative; boundary=f46d040839eb05c98604caa178a1

--f46d040839eb05c98604caa178a1
Content-Type: text/plain; charset=ISO-8859-1

Hi

I have a freeBSD compiled as a xen PVHVM. I am not sure how the
network_connect gets called in this case.
This function is called upon setting XenbusStateInitWait. In the source
code I only see netback changing the state.
I was not sure how to find out who sets the state to XenbusStateInitWait in
case PVHVM. Any help would be appreciated.
thanks
Arvind

--f46d040839eb05c98604caa178a1
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi=A0<div><br></div><div>I have a freeBSD compiled as a xen PVHVM. I am not=
 sure how the network_connect gets called in this case.</div><div>This func=
tion is called upon setting=A0XenbusStateInitWait. In the source code I onl=
y see netback changing the state.</div>
<div>I was not sure how to find out who sets the state to=A0XenbusStateInit=
Wait in case PVHVM. Any help would be appreciated.</div><div>thanks</div><d=
iv>Arvind</div><div><br></div>

--f46d040839eb05c98604caa178a1--


--===============7477969636917175344==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============7477969636917175344==--


From xen-devel-bounces@lists.xen.org Wed Sep 26 21:31:01 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Sep 2012 21: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 1TGzBi-00038D-0o; Wed, 26 Sep 2012 21:30:34 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <arvind.viswanathan@gmail.com>) id 1TGz7J-00037Q-4n
	for xen-devel@lists.xen.org; Wed, 26 Sep 2012 21:26:01 +0000
Received: from [85.158.139.83:8770] by server-2.bemta-5.messagelabs.com id
	66/A7-28944-8E273605; Wed, 26 Sep 2012 21:26:00 +0000
X-Env-Sender: arvind.viswanathan@gmail.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1348694759!24938900!1
X-Originating-IP: [209.85.215.45]
X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_10_20,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31122 invoked from network); 26 Sep 2012 21:25:59 -0000
Received: from mail-la0-f45.google.com (HELO mail-la0-f45.google.com)
	(209.85.215.45)
	by server-16.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Sep 2012 21:25:59 -0000
Received: by lahm13 with SMTP id m13so166709lah.32
	for <xen-devel@lists.xen.org>; Wed, 26 Sep 2012 14:25:59 -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=OF8wUo2WF7Thg+1j0EFBFPUlBtZRKbfcCYPyNCaQcls=;
	b=jYT7KEwr1ZNC6400r31+kBoByw3Ckn3mWI8W9abcq9zaenAQPvjB6L6NX3TXyWu+mK
	o0fD3vXxNWPlJVbNx/QZ0U+r1oqs6R+8/p265h+SNScq2RH9YAIVWE0K+IECFLExpUO8
	nOEMc88IGaIaESLwDWC4Iri7TfEJA+x940WBcJI8STt9/njwomoDhHTzNCh2yNysC9me
	ziugRT8Govk43A4GOAK2cvndZPDbm1sodzJG6EQZO2gAEqhYLTaBl6GTgSqmuP9cqXJc
	0D+kXDWrwKIh4MQAx78Jt28VjxkjV2cn+fTrIN86kLkBk40XBQumsUtGlcGvg1vcJ6B5
	bSWQ==
MIME-Version: 1.0
Received: by 10.152.111.227 with SMTP id il3mr1639587lab.23.1348694759033;
	Wed, 26 Sep 2012 14:25:59 -0700 (PDT)
Received: by 10.112.43.198 with HTTP; Wed, 26 Sep 2012 14:25:58 -0700 (PDT)
Date: Wed, 26 Sep 2012 14:25:58 -0700
Message-ID: <CAFOzg+HARCb6UN5yu3hmsDRNVyLmwv0rnw6z2+E8b=5mtKqPFQ@mail.gmail.com>
From: arvind viswanathan <arvind.viswanathan@gmail.com>
To: xen-devel@lists.xen.org
X-Mailman-Approved-At: Wed, 26 Sep 2012 21:30:32 +0000
Subject: [Xen-devel] xen PVHVM
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============7477969636917175344=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============7477969636917175344==
Content-Type: multipart/alternative; boundary=f46d040839eb05c98604caa178a1

--f46d040839eb05c98604caa178a1
Content-Type: text/plain; charset=ISO-8859-1

Hi

I have a freeBSD compiled as a xen PVHVM. I am not sure how the
network_connect gets called in this case.
This function is called upon setting XenbusStateInitWait. In the source
code I only see netback changing the state.
I was not sure how to find out who sets the state to XenbusStateInitWait in
case PVHVM. Any help would be appreciated.
thanks
Arvind

--f46d040839eb05c98604caa178a1
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi=A0<div><br></div><div>I have a freeBSD compiled as a xen PVHVM. I am not=
 sure how the network_connect gets called in this case.</div><div>This func=
tion is called upon setting=A0XenbusStateInitWait. In the source code I onl=
y see netback changing the state.</div>
<div>I was not sure how to find out who sets the state to=A0XenbusStateInit=
Wait in case PVHVM. Any help would be appreciated.</div><div>thanks</div><d=
iv>Arvind</div><div><br></div>

--f46d040839eb05c98604caa178a1--


--===============7477969636917175344==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============7477969636917175344==--


From xen-devel-bounces@lists.xen.org Wed Sep 26 21:44:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Sep 2012 21:44:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGzOX-0003Pr-C1; Wed, 26 Sep 2012 21:43:49 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <samuel.thibault@ens-lyon.org>) id 1TGzOW-0003Pm-2Z
	for xen-devel@lists.xensource.com; Wed, 26 Sep 2012 21:43:48 +0000
Received: from [85.158.143.35:18172] by server-1.bemta-4.messagelabs.com id
	6E/F9-05684-31773605; Wed, 26 Sep 2012 21:43:47 +0000
X-Env-Sender: samuel.thibault@ens-lyon.org
X-Msg-Ref: server-11.tower-21.messagelabs.com!1348695826!13203864!1
X-Originating-IP: [140.77.166.68]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1989 invoked from network); 26 Sep 2012 21:43:46 -0000
Received: from toccata.ens-lyon.fr (HELO toccata.ens-lyon.org) (140.77.166.68)
	by server-11.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 26 Sep 2012 21:43:46 -0000
Received: from localhost (localhost [127.0.0.1])
	by toccata.ens-lyon.org (Postfix) with ESMTP id 844BE840A9;
	Wed, 26 Sep 2012 23:43:45 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at toccata.ens-lyon.org
Received: from toccata.ens-lyon.org ([127.0.0.1])
	by localhost (toccata.ens-lyon.org [127.0.0.1]) (amavisd-new,
	port 10024)
	with ESMTP id 5MExQECfreUe; Wed, 26 Sep 2012 23:43:45 +0200 (CEST)
Received: from type.ipv6 (youpi.is-a-geek.org [80.67.176.89])
	(using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits))
	(No client certificate requested)
	by toccata.ens-lyon.org (Postfix) with ESMTPSA id 28C4B84093;
	Wed, 26 Sep 2012 23:43:45 +0200 (CEST)
Received: from samy by type.ipv6 with local (Exim 4.80)
	(envelope-from <samuel.thibault@ens-lyon.org>)
	id 1TGzOR-0004UI-Mg; Wed, 26 Sep 2012 23:43:43 +0200
Date: Wed, 26 Sep 2012 23:43:43 +0200
From: Samuel Thibault <samuel.thibault@ens-lyon.org>
To: George Dunlap <George.Dunlap@eu.citrix.com>
Message-ID: <20120926214343.GC4407@type>
Mail-Followup-To: Samuel Thibault <samuel.thibault@ens-lyon.org>,
	George Dunlap <George.Dunlap@eu.citrix.com>,
	Matthew Fioravante <matthew.fioravante@jhuapl.edu>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
References: <50579F53.4070302@jhuapl.edu>
	<20120917225245.GP5110@type.youpi.perso.aquilenet.fr>
	<5058BC47.8070907@jhuapl.edu>
	<CAFLBxZZMR1AdaaJN=BNPsmjYFcFV13RLCwS8_JLFqukfFZy96w@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAFLBxZZMR1AdaaJN=BNPsmjYFcFV13RLCwS8_JLFqukfFZy96w@mail.gmail.com>
User-Agent: Mutt/1.5.21+34 (58baf7c9f32f) (2010-12-30)
Cc: Matthew Fioravante <matthew.fioravante@jhuapl.edu>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH mini-os enhancements for vtpm 8/8] Add 3 tpm
 drivers to mini-os
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

George Dunlap, le Wed 26 Sep 2012 14:30:23 +0100, a =E9crit :
> On Tue, Sep 18, 2012 at 7:24 PM, Matthew Fioravante
> <matthew.fioravante@jhuapl.edu> wrote:
> > Is there anyone on the dev list that is familiar enough to review it?
> >
> > I can tell you we have been using all 3 of these drivers internally for
> > about 2 years now without issue. All of them are basically ports of the
> > linux drivers to mini-os.
> =

> If you're willing to be the TPM maintainer (which would involve adding
> your name to the MAINTAINERS file), and if Samuel is OK with you
> owning the tpm-related files in stubdom, I think it wouldn't
> necessarily need a thorough review to get in, as long as people are
> happy with how it integrates with the rest of the code.  What do
> people think?

I'm completely fine with it.

Samuel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 26 21:44:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Sep 2012 21:44:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TGzOX-0003Pr-C1; Wed, 26 Sep 2012 21:43:49 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <samuel.thibault@ens-lyon.org>) id 1TGzOW-0003Pm-2Z
	for xen-devel@lists.xensource.com; Wed, 26 Sep 2012 21:43:48 +0000
Received: from [85.158.143.35:18172] by server-1.bemta-4.messagelabs.com id
	6E/F9-05684-31773605; Wed, 26 Sep 2012 21:43:47 +0000
X-Env-Sender: samuel.thibault@ens-lyon.org
X-Msg-Ref: server-11.tower-21.messagelabs.com!1348695826!13203864!1
X-Originating-IP: [140.77.166.68]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1989 invoked from network); 26 Sep 2012 21:43:46 -0000
Received: from toccata.ens-lyon.fr (HELO toccata.ens-lyon.org) (140.77.166.68)
	by server-11.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 26 Sep 2012 21:43:46 -0000
Received: from localhost (localhost [127.0.0.1])
	by toccata.ens-lyon.org (Postfix) with ESMTP id 844BE840A9;
	Wed, 26 Sep 2012 23:43:45 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at toccata.ens-lyon.org
Received: from toccata.ens-lyon.org ([127.0.0.1])
	by localhost (toccata.ens-lyon.org [127.0.0.1]) (amavisd-new,
	port 10024)
	with ESMTP id 5MExQECfreUe; Wed, 26 Sep 2012 23:43:45 +0200 (CEST)
Received: from type.ipv6 (youpi.is-a-geek.org [80.67.176.89])
	(using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits))
	(No client certificate requested)
	by toccata.ens-lyon.org (Postfix) with ESMTPSA id 28C4B84093;
	Wed, 26 Sep 2012 23:43:45 +0200 (CEST)
Received: from samy by type.ipv6 with local (Exim 4.80)
	(envelope-from <samuel.thibault@ens-lyon.org>)
	id 1TGzOR-0004UI-Mg; Wed, 26 Sep 2012 23:43:43 +0200
Date: Wed, 26 Sep 2012 23:43:43 +0200
From: Samuel Thibault <samuel.thibault@ens-lyon.org>
To: George Dunlap <George.Dunlap@eu.citrix.com>
Message-ID: <20120926214343.GC4407@type>
Mail-Followup-To: Samuel Thibault <samuel.thibault@ens-lyon.org>,
	George Dunlap <George.Dunlap@eu.citrix.com>,
	Matthew Fioravante <matthew.fioravante@jhuapl.edu>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
References: <50579F53.4070302@jhuapl.edu>
	<20120917225245.GP5110@type.youpi.perso.aquilenet.fr>
	<5058BC47.8070907@jhuapl.edu>
	<CAFLBxZZMR1AdaaJN=BNPsmjYFcFV13RLCwS8_JLFqukfFZy96w@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAFLBxZZMR1AdaaJN=BNPsmjYFcFV13RLCwS8_JLFqukfFZy96w@mail.gmail.com>
User-Agent: Mutt/1.5.21+34 (58baf7c9f32f) (2010-12-30)
Cc: Matthew Fioravante <matthew.fioravante@jhuapl.edu>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH mini-os enhancements for vtpm 8/8] Add 3 tpm
 drivers to mini-os
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

George Dunlap, le Wed 26 Sep 2012 14:30:23 +0100, a =E9crit :
> On Tue, Sep 18, 2012 at 7:24 PM, Matthew Fioravante
> <matthew.fioravante@jhuapl.edu> wrote:
> > Is there anyone on the dev list that is familiar enough to review it?
> >
> > I can tell you we have been using all 3 of these drivers internally for
> > about 2 years now without issue. All of them are basically ports of the
> > linux drivers to mini-os.
> =

> If you're willing to be the TPM maintainer (which would involve adding
> your name to the MAINTAINERS file), and if Samuel is OK with you
> owning the tpm-related files in stubdom, I think it wouldn't
> necessarily need a thorough review to get in, as long as people are
> happy with how it integrates with the rest of the code.  What do
> people think?

I'm completely fine with it.

Samuel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 26 22:37:10 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Sep 2012 22: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 1TH0Di-0003w7-KS; Wed, 26 Sep 2012 22:36: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 1TH0Dh-0003w2-T4
	for xen-devel@lists.xensource.com; Wed, 26 Sep 2012 22:36:42 +0000
Received: from [85.158.143.35:52973] by server-1.bemta-4.messagelabs.com id
	88/4C-05684-97383605; Wed, 26 Sep 2012 22:36:41 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1348699000!13207290!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTE1NzQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28271 invoked from network); 26 Sep 2012 22:36:40 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Sep 2012 22:36:40 -0000
X-IronPort-AV: E=Sophos;i="4.80,492,1344211200"; d="scan'208";a="14788910"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Sep 2012 22:36: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.279.1; Wed, 26 Sep 2012 23:36: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 1TH0Df-0006iE-3b;
	Wed, 26 Sep 2012 22: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 1TH0Df-0003YW-3I;
	Wed, 26 Sep 2012 23:36:39 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-13878-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 26 Sep 2012 23:36:39 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13878: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 13878 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13878/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-win7-amd64  5 xen-boot                 fail REGR. vs. 13825
 test-amd64-amd64-pv           5 xen-boot                  fail REGR. vs. 13825
 test-amd64-i386-rhel6hvm-intel  5 xen-boot                fail REGR. vs. 13825
 test-amd64-i386-pair          8 xen-boot/dst_host         fail REGR. vs. 13825

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore            fail   like 13825
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail like 13823
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail like 13825

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-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-amd64-amd64-xl-win      13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  3aa66543a51b
baseline version:
 xen                  d364becfb083

------------------------------------------------------------
People who touched revisions under test:
  Bastian Blank <waldi@debian.org>
  Ben Guthro <ben@guthro.net>
  Christoph Egger <Christoph.Egger@amd.com>
  Christoph Egger <Christoph.Egger@amd.com> (on just this change)
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Keir Fraser <keir@xen.org>
  Liu, Jinsong <jinsong.liu@intel.com>
  Olaf Hering <olaf@aepfle.de>
------------------------------------------------------------

jobs:
 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-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                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          fail    
 test-amd64-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-amd64-amd64-xl-win                                      fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

(No revision log; it would be 490 lines long.)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Wed Sep 26 22:37:10 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 26 Sep 2012 22: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 1TH0Di-0003w7-KS; Wed, 26 Sep 2012 22:36: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 1TH0Dh-0003w2-T4
	for xen-devel@lists.xensource.com; Wed, 26 Sep 2012 22:36:42 +0000
Received: from [85.158.143.35:52973] by server-1.bemta-4.messagelabs.com id
	88/4C-05684-97383605; Wed, 26 Sep 2012 22:36:41 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1348699000!13207290!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTE1NzQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28271 invoked from network); 26 Sep 2012 22:36:40 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Sep 2012 22:36:40 -0000
X-IronPort-AV: E=Sophos;i="4.80,492,1344211200"; d="scan'208";a="14788910"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Sep 2012 22:36: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.279.1; Wed, 26 Sep 2012 23:36: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 1TH0Df-0006iE-3b;
	Wed, 26 Sep 2012 22: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 1TH0Df-0003YW-3I;
	Wed, 26 Sep 2012 23:36:39 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-13878-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 26 Sep 2012 23:36:39 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13878: regressions - FAIL
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

flight 13878 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13878/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-win7-amd64  5 xen-boot                 fail REGR. vs. 13825
 test-amd64-amd64-pv           5 xen-boot                  fail REGR. vs. 13825
 test-amd64-i386-rhel6hvm-intel  5 xen-boot                fail REGR. vs. 13825
 test-amd64-i386-pair          8 xen-boot/dst_host         fail REGR. vs. 13825

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore            fail   like 13825
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail like 13823
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail like 13825

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-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-amd64-amd64-xl-win      13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  3aa66543a51b
baseline version:
 xen                  d364becfb083

------------------------------------------------------------
People who touched revisions under test:
  Bastian Blank <waldi@debian.org>
  Ben Guthro <ben@guthro.net>
  Christoph Egger <Christoph.Egger@amd.com>
  Christoph Egger <Christoph.Egger@amd.com> (on just this change)
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Keir Fraser <keir@xen.org>
  Liu, Jinsong <jinsong.liu@intel.com>
  Olaf Hering <olaf@aepfle.de>
------------------------------------------------------------

jobs:
 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-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                               fail    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         fail    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          fail    
 test-amd64-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-amd64-amd64-xl-win                                      fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

(No revision log; it would be 490 lines long.)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 27 01:22:19 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Sep 2012 01: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 1TH2nR-0001DQ-Tn; Thu, 27 Sep 2012 01:21:45 +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 1TH2nQ-0001DL-GM
	for xen-devel@lists.xen.org; Thu, 27 Sep 2012 01:21:44 +0000
Received: from [85.158.143.99:43555] by server-1.bemta-4.messagelabs.com id
	9E/F5-05684-72AA3605; Thu, 27 Sep 2012 01:21:43 +0000
X-Env-Sender: xudong.hao@intel.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1348708902!31906052!1
X-Originating-IP: [143.182.124.21]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMjEgPT4gMjA5ODk2\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31840 invoked from network); 27 Sep 2012 01:21:43 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (143.182.124.21)
	by server-15.tower-216.messagelabs.com with SMTP;
	27 Sep 2012 01:21:43 -0000
Received: from azsmga002.ch.intel.com ([10.2.17.35])
	by azsmga101.ch.intel.com with ESMTP; 26 Sep 2012 18:21:41 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.80,492,1344236400"; d="scan'208";a="149620389"
Received: from fmsmsx105.amr.corp.intel.com ([10.19.9.36])
	by AZSMGA002.ch.intel.com with ESMTP; 26 Sep 2012 18:21:40 -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; Wed, 26 Sep 2012 18:21:40 -0700
Received: from shsmsx102.ccr.corp.intel.com ([169.254.2.92]) by
	SHSMSX101.ccr.corp.intel.com ([169.254.1.239]) with mapi id
	14.01.0355.002; Thu, 27 Sep 2012 09:21:38 +0800
From: "Hao, Xudong" <xudong.hao@intel.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Thread-Topic: [PATCH v2] qemu/xen: Add 64 bits big bar support on qemu
Thread-Index: AQHNms7UWaIyHrSFlE24ZH5C7S6v25eaW+6AgAHhrOD//7IGAIABduRw
Date: Thu, 27 Sep 2012 01:21:38 +0000
Message-ID: <403610A45A2B5242BD291EDAE8B37D300FEC7A1F@SHSMSX102.ccr.corp.intel.com>
References: <1348544326-31334-1-git-send-email-xudong.hao@intel.com>
	<alpine.DEB.2.02.1209251134460.29232@kaball.uk.xensource.com>
	<403610A45A2B5242BD291EDAE8B37D300FEC73C5@SHSMSX102.ccr.corp.intel.com>
	<alpine.DEB.2.02.1209261153210.29232@kaball.uk.xensource.com>
In-Reply-To: <alpine.DEB.2.02.1209261153210.29232@kaball.uk.xensource.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: "qemu-devel@nongnu.org" <qemu-devel@nongnu.org>, "Zhang,
	Xiantao" <xiantao.zhang@intel.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v2] qemu/xen: Add 64 bits big bar support on
	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

> -----Original Message-----
> From: Stefano Stabellini [mailto:stefano.stabellini@eu.citrix.com]
> Sent: Wednesday, September 26, 2012 6:57 PM
> To: Hao, Xudong
> Cc: Stefano Stabellini; xen-devel@lists.xen.org; qemu-devel@nongnu.org;
> Zhang, Xiantao
> Subject: RE: [PATCH v2] qemu/xen: Add 64 bits big bar support on qemu
> 
> > Will change to:
> > -        if (r->type & XEN_HOST_PCI_REGION_TYPE_IO) {
> > +        if (r->type & XEN_HOST_PCI_REGION_TYPE_IO)
> >              type = PCI_BASE_ADDRESS_SPACE_IO;
> > -        } else {
> > +        else
> >              type = PCI_BASE_ADDRESS_SPACE_MEMORY;
> > -            if (r->type & XEN_HOST_PCI_REGION_TYPE_PREFETCH) {
> > +            if (r->type & XEN_HOST_PCI_REGION_TYPE_MEM_64)
> > +                type |= PCI_BASE_ADDRESS_MEM_TYPE_64;
> > +           else if (r->type & XEN_HOST_PCI_REGION_TYPE_PREFETCH)
> >                  type |= PCI_BASE_ADDRESS_MEM_PREFETCH;
> > -            }
> > -        }
> 
> Isn't it possible that both XEN_HOST_PCI_REGION_TYPE_MEM_64 and
> XEN_HOST_PCI_REGION_TYPE_PREFETCH are set? It doesn't look like this can
> cover that case.
It's possible. Thanks comments.

> The following seems to be what you are looking for:
> 
> 
> 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;
>     }
>     if (r->type & XEN_HOST_PCI_REGION_TYPE_MEM_64) {
>         type |= PCI_BASE_ADDRESS_MEM_TYPE_64;
>     }
> }
> 
> 
> > > >  static XenPTBarFlag xen_pt_bar_reg_parse(XenPCIPassthroughState
> *s,
> > > >                                           XenPTRegInfo *reg)
> > > >  {
> > > > @@ -366,7 +367,7 @@ static XenPTBarFlag
> > > xen_pt_bar_reg_parse(XenPCIPassthroughState *s,
> > > >
> > > >      /* check unused BAR */
> > > >      r = &d->io_regions[index];
> > > > -    if (r->size == 0) {
> > > > +    if (!xen_pt_get_bar_size(r)) {
> > > >          return XEN_PT_BAR_FLAG_UNUSED;
> > > >      }
> > > >
> > > > @@ -383,6 +384,24 @@ static XenPTBarFlag
> > > xen_pt_bar_reg_parse(XenPCIPassthroughState *s,
> > > >      }
> > > >  }
> > > >
> > > > +static bool is_64bit_bar(PCIIORegion *r)
> > > > +{
> > > > +    return !!(r->type & PCI_BASE_ADDRESS_MEM_TYPE_64);
> > > > +}
> > > > +
> > > > +static uint64_t xen_pt_get_bar_size(PCIIORegion *r)
> > > > +{
> > > > +    if (is_64bit_bar(r))
> > > > +    {
> > > > +        uint64_t size64;
> > > > +        size64 = (r + 1)->size;
> > > > +        size64 <<= 32;
> > > > +        size64 += r->size;
> > > > +        return size64;
> > > > +    }
> > > > +    return r->size;
> > > > +}
> > > > +
> > > >  static inline uint32_t base_address_with_flags(XenHostPCIIORegion
> *hr)
> > > >  {
> > > >      if (hr->type & XEN_HOST_PCI_REGION_TYPE_IO) {
> > > > @@ -481,7 +500,10 @@ static int
> > > xen_pt_bar_reg_write(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
> > > >      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);
> > > > +        if (!r_size)
> > > > +            bar_ro_mask = XEN_PT_BAR_ALLF;
> > > > +        else
> > > > +            bar_ro_mask = XEN_PT_BAR_MEM_RO_MASK | (r_size -
> 1);
> > > >          break;
> > >
> > > Is this an actual mistake everywhere?
> >
> > It's low 32bit mask for 64 bit bars.
> 
> I see. It is a good idea to add a line of comment in the code saying
> that.

OK, I'll add code comment.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 27 01:22:19 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Sep 2012 01: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 1TH2nR-0001DQ-Tn; Thu, 27 Sep 2012 01:21:45 +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 1TH2nQ-0001DL-GM
	for xen-devel@lists.xen.org; Thu, 27 Sep 2012 01:21:44 +0000
Received: from [85.158.143.99:43555] by server-1.bemta-4.messagelabs.com id
	9E/F5-05684-72AA3605; Thu, 27 Sep 2012 01:21:43 +0000
X-Env-Sender: xudong.hao@intel.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1348708902!31906052!1
X-Originating-IP: [143.182.124.21]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMjEgPT4gMjA5ODk2\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31840 invoked from network); 27 Sep 2012 01:21:43 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (143.182.124.21)
	by server-15.tower-216.messagelabs.com with SMTP;
	27 Sep 2012 01:21:43 -0000
Received: from azsmga002.ch.intel.com ([10.2.17.35])
	by azsmga101.ch.intel.com with ESMTP; 26 Sep 2012 18:21:41 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.80,492,1344236400"; d="scan'208";a="149620389"
Received: from fmsmsx105.amr.corp.intel.com ([10.19.9.36])
	by AZSMGA002.ch.intel.com with ESMTP; 26 Sep 2012 18:21:40 -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; Wed, 26 Sep 2012 18:21:40 -0700
Received: from shsmsx102.ccr.corp.intel.com ([169.254.2.92]) by
	SHSMSX101.ccr.corp.intel.com ([169.254.1.239]) with mapi id
	14.01.0355.002; Thu, 27 Sep 2012 09:21:38 +0800
From: "Hao, Xudong" <xudong.hao@intel.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Thread-Topic: [PATCH v2] qemu/xen: Add 64 bits big bar support on qemu
Thread-Index: AQHNms7UWaIyHrSFlE24ZH5C7S6v25eaW+6AgAHhrOD//7IGAIABduRw
Date: Thu, 27 Sep 2012 01:21:38 +0000
Message-ID: <403610A45A2B5242BD291EDAE8B37D300FEC7A1F@SHSMSX102.ccr.corp.intel.com>
References: <1348544326-31334-1-git-send-email-xudong.hao@intel.com>
	<alpine.DEB.2.02.1209251134460.29232@kaball.uk.xensource.com>
	<403610A45A2B5242BD291EDAE8B37D300FEC73C5@SHSMSX102.ccr.corp.intel.com>
	<alpine.DEB.2.02.1209261153210.29232@kaball.uk.xensource.com>
In-Reply-To: <alpine.DEB.2.02.1209261153210.29232@kaball.uk.xensource.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: "qemu-devel@nongnu.org" <qemu-devel@nongnu.org>, "Zhang,
	Xiantao" <xiantao.zhang@intel.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v2] qemu/xen: Add 64 bits big bar support on
	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

> -----Original Message-----
> From: Stefano Stabellini [mailto:stefano.stabellini@eu.citrix.com]
> Sent: Wednesday, September 26, 2012 6:57 PM
> To: Hao, Xudong
> Cc: Stefano Stabellini; xen-devel@lists.xen.org; qemu-devel@nongnu.org;
> Zhang, Xiantao
> Subject: RE: [PATCH v2] qemu/xen: Add 64 bits big bar support on qemu
> 
> > Will change to:
> > -        if (r->type & XEN_HOST_PCI_REGION_TYPE_IO) {
> > +        if (r->type & XEN_HOST_PCI_REGION_TYPE_IO)
> >              type = PCI_BASE_ADDRESS_SPACE_IO;
> > -        } else {
> > +        else
> >              type = PCI_BASE_ADDRESS_SPACE_MEMORY;
> > -            if (r->type & XEN_HOST_PCI_REGION_TYPE_PREFETCH) {
> > +            if (r->type & XEN_HOST_PCI_REGION_TYPE_MEM_64)
> > +                type |= PCI_BASE_ADDRESS_MEM_TYPE_64;
> > +           else if (r->type & XEN_HOST_PCI_REGION_TYPE_PREFETCH)
> >                  type |= PCI_BASE_ADDRESS_MEM_PREFETCH;
> > -            }
> > -        }
> 
> Isn't it possible that both XEN_HOST_PCI_REGION_TYPE_MEM_64 and
> XEN_HOST_PCI_REGION_TYPE_PREFETCH are set? It doesn't look like this can
> cover that case.
It's possible. Thanks comments.

> The following seems to be what you are looking for:
> 
> 
> 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;
>     }
>     if (r->type & XEN_HOST_PCI_REGION_TYPE_MEM_64) {
>         type |= PCI_BASE_ADDRESS_MEM_TYPE_64;
>     }
> }
> 
> 
> > > >  static XenPTBarFlag xen_pt_bar_reg_parse(XenPCIPassthroughState
> *s,
> > > >                                           XenPTRegInfo *reg)
> > > >  {
> > > > @@ -366,7 +367,7 @@ static XenPTBarFlag
> > > xen_pt_bar_reg_parse(XenPCIPassthroughState *s,
> > > >
> > > >      /* check unused BAR */
> > > >      r = &d->io_regions[index];
> > > > -    if (r->size == 0) {
> > > > +    if (!xen_pt_get_bar_size(r)) {
> > > >          return XEN_PT_BAR_FLAG_UNUSED;
> > > >      }
> > > >
> > > > @@ -383,6 +384,24 @@ static XenPTBarFlag
> > > xen_pt_bar_reg_parse(XenPCIPassthroughState *s,
> > > >      }
> > > >  }
> > > >
> > > > +static bool is_64bit_bar(PCIIORegion *r)
> > > > +{
> > > > +    return !!(r->type & PCI_BASE_ADDRESS_MEM_TYPE_64);
> > > > +}
> > > > +
> > > > +static uint64_t xen_pt_get_bar_size(PCIIORegion *r)
> > > > +{
> > > > +    if (is_64bit_bar(r))
> > > > +    {
> > > > +        uint64_t size64;
> > > > +        size64 = (r + 1)->size;
> > > > +        size64 <<= 32;
> > > > +        size64 += r->size;
> > > > +        return size64;
> > > > +    }
> > > > +    return r->size;
> > > > +}
> > > > +
> > > >  static inline uint32_t base_address_with_flags(XenHostPCIIORegion
> *hr)
> > > >  {
> > > >      if (hr->type & XEN_HOST_PCI_REGION_TYPE_IO) {
> > > > @@ -481,7 +500,10 @@ static int
> > > xen_pt_bar_reg_write(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
> > > >      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);
> > > > +        if (!r_size)
> > > > +            bar_ro_mask = XEN_PT_BAR_ALLF;
> > > > +        else
> > > > +            bar_ro_mask = XEN_PT_BAR_MEM_RO_MASK | (r_size -
> 1);
> > > >          break;
> > >
> > > Is this an actual mistake everywhere?
> >
> > It's low 32bit mask for 64 bit bars.
> 
> I see. It is a good idea to add a line of comment in the code saying
> that.

OK, I'll add code comment.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 27 02:58:51 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Sep 2012 02: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 1TH4Iw-0003Bp-3E; Thu, 27 Sep 2012 02:58:22 +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 1TH4Iu-0003Bk-Pp
	for xen-devel@lists.xen.org; Thu, 27 Sep 2012 02:58:21 +0000
Received: from [85.158.138.51:40668] by server-1.bemta-3.messagelabs.com id
	65/82-16425-BC0C3605; Thu, 27 Sep 2012 02:58:19 +0000
X-Env-Sender: xudong.hao@intel.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1348714698!32043904!1
X-Originating-IP: [134.134.136.24]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjQgPT4gMzQ4NTg4\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7419 invoked from network); 27 Sep 2012 02:58:19 -0000
Received: from mga09.intel.com (HELO mga09.intel.com) (134.134.136.24)
	by server-16.tower-174.messagelabs.com with SMTP;
	27 Sep 2012 02:58:19 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga102.jf.intel.com with ESMTP; 26 Sep 2012 19:58:02 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.80,493,1344236400"; d="scan'208";a="214035616"
Received: from xhao-dev.sh.intel.com (HELO localhost.localdomain)
	([10.239.48.48])
	by orsmga002.jf.intel.com with ESMTP; 26 Sep 2012 19:58:16 -0700
From: Xudong Hao <xudong.hao@intel.com>
To: stefano.stabellini@eu.citrix.com
Date: Thu, 27 Sep 2012 11:01:52 +0800
Message-Id: <1348714912-18953-1-git-send-email-xudong.hao@intel.com>
X-Mailer: git-send-email 1.5.5
Cc: Xudong Hao <xudong.hao@intel.com>, qemu-devel@nongnu.org,
	Xiantao Zhang <xiantao.zhang@intel.com>, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH v3] qemu/xen: Add 64 bits big bar support on qemu
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

v3 changes from v2:
- Refine code following by the qemu code style
- As suggestion by Stefano, cheanup code, add some code comment

v2 changes from v1:
- Rebase to qemu upstream from qemu-xen

Currently it is assumed PCI device BAR access < 4G memory. If there is such a
device whose BAR size is larger than 4G, it must access > 4G memory address.
This patch enable the 64bits big BAR support on qemu.

Signed-off-by: Xudong Hao <xudong.hao@intel.com>
Signed-off-by: Xiantao Zhang <xiantao.zhang@intel.com>
---
 hw/xen_pt.c             |    7 +++++--
 hw/xen_pt_config_init.c |   39 ++++++++++++++++++++++++++-------------
 2 files changed, 31 insertions(+), 15 deletions(-)

diff --git a/hw/xen_pt.c b/hw/xen_pt.c
index 307119a..838bcea 100644
--- a/hw/xen_pt.c
+++ b/hw/xen_pt.c
@@ -410,14 +410,17 @@ static int xen_pt_register_regions(XenPCIPassthroughState *s)
             if (r->type & XEN_HOST_PCI_REGION_TYPE_PREFETCH) {
                 type |= PCI_BASE_ADDRESS_MEM_PREFETCH;
             }
+            if (r->type & XEN_HOST_PCI_REGION_TYPE_MEM_64) {
+                type |= PCI_BASE_ADDRESS_MEM_TYPE_64;
+            }
         }
 
         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",
+        XEN_PT_LOG(&s->dev, "IO region %i registered (size=0x%lx"PRIx64
+                   " base_addr=0x%lx"PRIx64" type: %#x)\n",
                    i, r->size, r->base_addr, type);
     }
 
diff --git a/hw/xen_pt_config_init.c b/hw/xen_pt_config_init.c
index e524a40..0a5f82c 100644
--- a/hw/xen_pt_config_init.c
+++ b/hw/xen_pt_config_init.c
@@ -342,6 +342,23 @@ static int xen_pt_cmd_reg_write(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
 #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 bool is_64bit_bar(PCIIORegion *r)
+{
+    return !!(r->type & PCI_BASE_ADDRESS_MEM_TYPE_64);
+}
+
+static uint64_t xen_pt_get_bar_size(PCIIORegion *r)
+{
+    if (is_64bit_bar(r)) {
+        uint64_t size64;
+        size64 = (r + 1)->size;
+        size64 <<= 32;
+        size64 += r->size;
+        return size64;
+    }
+    return r->size;
+}
+
 static XenPTBarFlag xen_pt_bar_reg_parse(XenPCIPassthroughState *s,
                                          XenPTRegInfo *reg)
 {
@@ -366,7 +383,7 @@ static XenPTBarFlag xen_pt_bar_reg_parse(XenPCIPassthroughState *s,
 
     /* check unused BAR */
     r = &d->io_regions[index];
-    if (r->size == 0) {
+    if (!xen_pt_get_bar_size(r)) {
         return XEN_PT_BAR_FLAG_UNUSED;
     }
 
@@ -481,7 +498,12 @@ static int xen_pt_bar_reg_write(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
     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);
+        if (!r_size) {
+            /* low 32 bits mask for 64 bit bars */
+            bar_ro_mask = XEN_PT_BAR_ALLF;
+        } else {
+            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;
@@ -489,7 +511,7 @@ static int xen_pt_bar_reg_write(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
         break;
     case XEN_PT_BAR_FLAG_UPPER:
         bar_emu_mask = XEN_PT_BAR_ALLF;
-        bar_ro_mask = 0;    /* all upper 32bit are R/W */
+        bar_ro_mask = r_size ? r_size - 1 : 0;
         break;
     default:
         break;
@@ -501,22 +523,13 @@ static int xen_pt_bar_reg_write(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
 
     /* check whether we need to update the virtual region address or not */
     switch (s->bases[index].bar_flag) {
+    case XEN_PT_BAR_FLAG_UPPER:
     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;
     }
-- 
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 Thu Sep 27 02:58:51 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Sep 2012 02: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 1TH4Iw-0003Bp-3E; Thu, 27 Sep 2012 02:58:22 +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 1TH4Iu-0003Bk-Pp
	for xen-devel@lists.xen.org; Thu, 27 Sep 2012 02:58:21 +0000
Received: from [85.158.138.51:40668] by server-1.bemta-3.messagelabs.com id
	65/82-16425-BC0C3605; Thu, 27 Sep 2012 02:58:19 +0000
X-Env-Sender: xudong.hao@intel.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1348714698!32043904!1
X-Originating-IP: [134.134.136.24]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjQgPT4gMzQ4NTg4\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7419 invoked from network); 27 Sep 2012 02:58:19 -0000
Received: from mga09.intel.com (HELO mga09.intel.com) (134.134.136.24)
	by server-16.tower-174.messagelabs.com with SMTP;
	27 Sep 2012 02:58:19 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga102.jf.intel.com with ESMTP; 26 Sep 2012 19:58:02 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.80,493,1344236400"; d="scan'208";a="214035616"
Received: from xhao-dev.sh.intel.com (HELO localhost.localdomain)
	([10.239.48.48])
	by orsmga002.jf.intel.com with ESMTP; 26 Sep 2012 19:58:16 -0700
From: Xudong Hao <xudong.hao@intel.com>
To: stefano.stabellini@eu.citrix.com
Date: Thu, 27 Sep 2012 11:01:52 +0800
Message-Id: <1348714912-18953-1-git-send-email-xudong.hao@intel.com>
X-Mailer: git-send-email 1.5.5
Cc: Xudong Hao <xudong.hao@intel.com>, qemu-devel@nongnu.org,
	Xiantao Zhang <xiantao.zhang@intel.com>, xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH v3] qemu/xen: Add 64 bits big bar support on qemu
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

v3 changes from v2:
- Refine code following by the qemu code style
- As suggestion by Stefano, cheanup code, add some code comment

v2 changes from v1:
- Rebase to qemu upstream from qemu-xen

Currently it is assumed PCI device BAR access < 4G memory. If there is such a
device whose BAR size is larger than 4G, it must access > 4G memory address.
This patch enable the 64bits big BAR support on qemu.

Signed-off-by: Xudong Hao <xudong.hao@intel.com>
Signed-off-by: Xiantao Zhang <xiantao.zhang@intel.com>
---
 hw/xen_pt.c             |    7 +++++--
 hw/xen_pt_config_init.c |   39 ++++++++++++++++++++++++++-------------
 2 files changed, 31 insertions(+), 15 deletions(-)

diff --git a/hw/xen_pt.c b/hw/xen_pt.c
index 307119a..838bcea 100644
--- a/hw/xen_pt.c
+++ b/hw/xen_pt.c
@@ -410,14 +410,17 @@ static int xen_pt_register_regions(XenPCIPassthroughState *s)
             if (r->type & XEN_HOST_PCI_REGION_TYPE_PREFETCH) {
                 type |= PCI_BASE_ADDRESS_MEM_PREFETCH;
             }
+            if (r->type & XEN_HOST_PCI_REGION_TYPE_MEM_64) {
+                type |= PCI_BASE_ADDRESS_MEM_TYPE_64;
+            }
         }
 
         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",
+        XEN_PT_LOG(&s->dev, "IO region %i registered (size=0x%lx"PRIx64
+                   " base_addr=0x%lx"PRIx64" type: %#x)\n",
                    i, r->size, r->base_addr, type);
     }
 
diff --git a/hw/xen_pt_config_init.c b/hw/xen_pt_config_init.c
index e524a40..0a5f82c 100644
--- a/hw/xen_pt_config_init.c
+++ b/hw/xen_pt_config_init.c
@@ -342,6 +342,23 @@ static int xen_pt_cmd_reg_write(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
 #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 bool is_64bit_bar(PCIIORegion *r)
+{
+    return !!(r->type & PCI_BASE_ADDRESS_MEM_TYPE_64);
+}
+
+static uint64_t xen_pt_get_bar_size(PCIIORegion *r)
+{
+    if (is_64bit_bar(r)) {
+        uint64_t size64;
+        size64 = (r + 1)->size;
+        size64 <<= 32;
+        size64 += r->size;
+        return size64;
+    }
+    return r->size;
+}
+
 static XenPTBarFlag xen_pt_bar_reg_parse(XenPCIPassthroughState *s,
                                          XenPTRegInfo *reg)
 {
@@ -366,7 +383,7 @@ static XenPTBarFlag xen_pt_bar_reg_parse(XenPCIPassthroughState *s,
 
     /* check unused BAR */
     r = &d->io_regions[index];
-    if (r->size == 0) {
+    if (!xen_pt_get_bar_size(r)) {
         return XEN_PT_BAR_FLAG_UNUSED;
     }
 
@@ -481,7 +498,12 @@ static int xen_pt_bar_reg_write(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
     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);
+        if (!r_size) {
+            /* low 32 bits mask for 64 bit bars */
+            bar_ro_mask = XEN_PT_BAR_ALLF;
+        } else {
+            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;
@@ -489,7 +511,7 @@ static int xen_pt_bar_reg_write(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
         break;
     case XEN_PT_BAR_FLAG_UPPER:
         bar_emu_mask = XEN_PT_BAR_ALLF;
-        bar_ro_mask = 0;    /* all upper 32bit are R/W */
+        bar_ro_mask = r_size ? r_size - 1 : 0;
         break;
     default:
         break;
@@ -501,22 +523,13 @@ static int xen_pt_bar_reg_write(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
 
     /* check whether we need to update the virtual region address or not */
     switch (s->bases[index].bar_flag) {
+    case XEN_PT_BAR_FLAG_UPPER:
     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;
     }
-- 
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 Thu Sep 27 05:23:30 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Sep 2012 05:23: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 1TH6Ym-0004Ww-2s; Thu, 27 Sep 2012 05:22:52 +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 1TH6Yk-0004Wr-7I
	for xen-devel@lists.xensource.com; Thu, 27 Sep 2012 05:22:50 +0000
Received: from [85.158.137.99:22928] by server-10.bemta-3.messagelabs.com id
	1E/CE-02525-9A2E3605; Thu, 27 Sep 2012 05:22:49 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-3.tower-217.messagelabs.com!1348723367!14228593!1
X-Originating-IP: [143.182.124.21]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMjEgPT4gMjA5ODk2\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13769 invoked from network); 27 Sep 2012 05:22:48 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (143.182.124.21)
	by server-3.tower-217.messagelabs.com with SMTP;
	27 Sep 2012 05:22:48 -0000
Received: from azsmga002.ch.intel.com ([10.2.17.35])
	by azsmga101.ch.intel.com with ESMTP; 26 Sep 2012 22:22:46 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.80,493,1344236400"; d="scan'208";a="149681975"
Received: from fmsmsx107.amr.corp.intel.com ([10.19.9.54])
	by AZSMGA002.ch.intel.com with ESMTP; 26 Sep 2012 22:22:44 -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; Wed, 26 Sep 2012 22:22:42 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.239]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.175]) with mapi id
	14.01.0355.002; Thu, 27 Sep 2012 13:22:38 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: Jan Beulich <JBeulich@suse.com>
Thread-Topic: [PATCH 6] X86/MCE: update vMCE injection for AMD
Thread-Index: AQHNm7lcbAubMQI3SAyq+zkwzNAc0pedqDSg
Date: Thu, 27 Sep 2012 05:22:38 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC829233533C01C@SHSMSX101.ccr.corp.intel.com>
References: <DE8DF0795D48FD4CA783C40EC8292335339547@SHSMSX101.ccr.corp.intel.com>
	<506173FB.8070603@amd.com>
	<5061A833020000780009DA1A@nat28.tlf.novell.com>
	<50619B61.2030609@amd.com>
	<DE8DF0795D48FD4CA783C40EC829233533AA6E@SHSMSX101.ccr.corp.intel.com>
	<5062CC25020000780009DE44@nat28.tlf.novell.com>
In-Reply-To: <5062CC25020000780009DE44@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_DE8DF0795D48FD4CA783C40EC829233533C01CSHSMSX101ccrcorpi_"
MIME-Version: 1.0
Cc: Christoph Egger <Christoph.Egger@amd.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"keir@xen.org" <keir@xen.org>,
	"Ian.Campbell@citrix.com" <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH 6] X86/MCE: update vMCE injection for AMD
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--_002_DE8DF0795D48FD4CA783C40EC829233533C01CSHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Jan Beulich wrote:
>>>> On 26.09.12 at 05:11, "Liu, Jinsong" <jinsong.liu@intel.com> wrote:
>> I fold patch 6 to patch 2, will send out later.
>=20
> As I had indicated, I had done this already in preparation of things
> getting committed, so you will want to check once in staging
> (hopefully later today).
>=20
> Jan

Got it, thanks! It's OK to me, but how about add sanity check and some comm=
ents like

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Xen/MCE: add sanity check and comments for vmce injection

Add sanity check for input vcpu so that malicious value would not return 0.
Add comments since vcpu<0 (broadcast) is some implicit to code reader.

Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>

diff -r adc7f057011e xen/arch/x86/cpu/mcheck/vmce.c
--- a/xen/arch/x86/cpu/mcheck/vmce.c	Thu Sep 27 19:52:13 2012 +0800
+++ b/xen/arch/x86/cpu/mcheck/vmce.c	Thu Sep 27 20:56:52 2012 +0800
@@ -341,10 +341,16 @@
 /*
  * for Intel MCE, broadcast vMCE to all vcpus
  * for AMD MCE, only inject vMCE to vcpu0
+ *
+ * @ d, domain to which would inject vmce
+ * @ vcpu,
+ *   < 0, broadcast vMCE to all vcpus
+ *   >=3D 0, vcpu who would be injected vMCE
  */
 int inject_vmce(struct domain *d, int vcpu)
 {
     struct vcpu *v;
+    int ret =3D -EINVAL;
=20
     for_each_vcpu ( d, v )
     {
@@ -358,19 +364,21 @@
             mce_printk(MCE_VERBOSE, "MCE: inject vMCE to d%d:v%d\n",
                        d->domain_id, v->vcpu_id);
             vcpu_kick(v);
+            ret =3D 0;
         }
         else
         {
             mce_printk(MCE_QUIET, "Failed to inject vMCE to d%d:v%d\n",
                        d->domain_id, v->vcpu_id);
-            return -EBUSY;
+            ret =3D -EBUSY;
+            break;
         }
=20
         if ( vcpu >=3D 0 )
-            return 0;
+            break;
     }
=20
-    return v ? -ESRCH : 0;
+    return ret;
 }
=20
 int fill_vmsr_data(struct mcinfo_bank *mc_bank, struct domain *d,=

--_002_DE8DF0795D48FD4CA783C40EC829233533C01CSHSMSX101ccrcorpi_
Content-Type: application/octet-stream; name="vmce_injection_update.patch"
Content-Description: vmce_injection_update.patch
Content-Disposition: attachment; filename="vmce_injection_update.patch";
	size=1476; creation-date="Thu, 27 Sep 2012 05:15:25 GMT";
	modification-date="Thu, 27 Sep 2012 13:06:10 GMT"
Content-Transfer-Encoding: base64

WGVuL01DRTogYWRkIHNhbml0eSBjaGVjayBhbmQgY29tbWVudHMgZm9yIHZtY2UgaW5qZWN0aW9u
CgpBZGQgc2FuaXR5IGNoZWNrIGZvciBpbnB1dCB2Y3B1IHNvIHRoYXQgbWFsaWNpb3VzIHZhbHVl
IHdvdWxkIG5vdCByZXR1cm4gMC4KQWRkIGNvbW1lbnRzIHNpbmNlIHZjcHU8MCAoYnJvYWRjYXN0
KSBpcyBzb21lIGltcGxpY2l0IHRvIGNvZGUgcmVhZGVyLgoKU2lnbmVkLW9mZi1ieTogTGl1LCBK
aW5zb25nIDxqaW5zb25nLmxpdUBpbnRlbC5jb20+CgpkaWZmIC1yIGFkYzdmMDU3MDExZSB4ZW4v
YXJjaC94ODYvY3B1L21jaGVjay92bWNlLmMKLS0tIGEveGVuL2FyY2gveDg2L2NwdS9tY2hlY2sv
dm1jZS5jCVRodSBTZXAgMjcgMTk6NTI6MTMgMjAxMiArMDgwMAorKysgYi94ZW4vYXJjaC94ODYv
Y3B1L21jaGVjay92bWNlLmMJVGh1IFNlcCAyNyAyMDo1Njo1MiAyMDEyICswODAwCkBAIC0zNDEs
MTAgKzM0MSwxNiBAQAogLyoKICAqIGZvciBJbnRlbCBNQ0UsIGJyb2FkY2FzdCB2TUNFIHRvIGFs
bCB2Y3B1cwogICogZm9yIEFNRCBNQ0UsIG9ubHkgaW5qZWN0IHZNQ0UgdG8gdmNwdTAKKyAqCisg
KiBAIGQsIGRvbWFpbiB0byB3aGljaCB3b3VsZCBpbmplY3Qgdm1jZQorICogQCB2Y3B1LAorICog
ICA8IDAsIGJyb2FkY2FzdCB2TUNFIHRvIGFsbCB2Y3B1cworICogICA+PSAwLCB2Y3B1IHdobyB3
b3VsZCBiZSBpbmplY3RlZCB2TUNFCiAgKi8KIGludCBpbmplY3Rfdm1jZShzdHJ1Y3QgZG9tYWlu
ICpkLCBpbnQgdmNwdSkKIHsKICAgICBzdHJ1Y3QgdmNwdSAqdjsKKyAgICBpbnQgcmV0ID0gLUVJ
TlZBTDsKIAogICAgIGZvcl9lYWNoX3ZjcHUgKCBkLCB2ICkKICAgICB7CkBAIC0zNTgsMTkgKzM2
NCwyMSBAQAogICAgICAgICAgICAgbWNlX3ByaW50ayhNQ0VfVkVSQk9TRSwgIk1DRTogaW5qZWN0
IHZNQ0UgdG8gZCVkOnYlZFxuIiwKICAgICAgICAgICAgICAgICAgICAgICAgZC0+ZG9tYWluX2lk
LCB2LT52Y3B1X2lkKTsKICAgICAgICAgICAgIHZjcHVfa2ljayh2KTsKKyAgICAgICAgICAgIHJl
dCA9IDA7CiAgICAgICAgIH0KICAgICAgICAgZWxzZQogICAgICAgICB7CiAgICAgICAgICAgICBt
Y2VfcHJpbnRrKE1DRV9RVUlFVCwgIkZhaWxlZCB0byBpbmplY3Qgdk1DRSB0byBkJWQ6diVkXG4i
LAogICAgICAgICAgICAgICAgICAgICAgICBkLT5kb21haW5faWQsIHYtPnZjcHVfaWQpOwotICAg
ICAgICAgICAgcmV0dXJuIC1FQlVTWTsKKyAgICAgICAgICAgIHJldCA9IC1FQlVTWTsKKyAgICAg
ICAgICAgIGJyZWFrOwogICAgICAgICB9CiAKICAgICAgICAgaWYgKCB2Y3B1ID49IDAgKQotICAg
ICAgICAgICAgcmV0dXJuIDA7CisgICAgICAgICAgICBicmVhazsKICAgICB9CiAKLSAgICByZXR1
cm4gdiA/IC1FU1JDSCA6IDA7CisgICAgcmV0dXJuIHJldDsKIH0KIAogaW50IGZpbGxfdm1zcl9k
YXRhKHN0cnVjdCBtY2luZm9fYmFuayAqbWNfYmFuaywgc3RydWN0IGRvbWFpbiAqZCwK

--_002_DE8DF0795D48FD4CA783C40EC829233533C01CSHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 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_DE8DF0795D48FD4CA783C40EC829233533C01CSHSMSX101ccrcorpi_--


From xen-devel-bounces@lists.xen.org Thu Sep 27 05:23:30 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Sep 2012 05:23: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 1TH6Ym-0004Ww-2s; Thu, 27 Sep 2012 05:22:52 +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 1TH6Yk-0004Wr-7I
	for xen-devel@lists.xensource.com; Thu, 27 Sep 2012 05:22:50 +0000
Received: from [85.158.137.99:22928] by server-10.bemta-3.messagelabs.com id
	1E/CE-02525-9A2E3605; Thu, 27 Sep 2012 05:22:49 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-3.tower-217.messagelabs.com!1348723367!14228593!1
X-Originating-IP: [143.182.124.21]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMjEgPT4gMjA5ODk2\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13769 invoked from network); 27 Sep 2012 05:22:48 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (143.182.124.21)
	by server-3.tower-217.messagelabs.com with SMTP;
	27 Sep 2012 05:22:48 -0000
Received: from azsmga002.ch.intel.com ([10.2.17.35])
	by azsmga101.ch.intel.com with ESMTP; 26 Sep 2012 22:22:46 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.80,493,1344236400"; d="scan'208";a="149681975"
Received: from fmsmsx107.amr.corp.intel.com ([10.19.9.54])
	by AZSMGA002.ch.intel.com with ESMTP; 26 Sep 2012 22:22:44 -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; Wed, 26 Sep 2012 22:22:42 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.239]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.175]) with mapi id
	14.01.0355.002; Thu, 27 Sep 2012 13:22:38 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: Jan Beulich <JBeulich@suse.com>
Thread-Topic: [PATCH 6] X86/MCE: update vMCE injection for AMD
Thread-Index: AQHNm7lcbAubMQI3SAyq+zkwzNAc0pedqDSg
Date: Thu, 27 Sep 2012 05:22:38 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC829233533C01C@SHSMSX101.ccr.corp.intel.com>
References: <DE8DF0795D48FD4CA783C40EC8292335339547@SHSMSX101.ccr.corp.intel.com>
	<506173FB.8070603@amd.com>
	<5061A833020000780009DA1A@nat28.tlf.novell.com>
	<50619B61.2030609@amd.com>
	<DE8DF0795D48FD4CA783C40EC829233533AA6E@SHSMSX101.ccr.corp.intel.com>
	<5062CC25020000780009DE44@nat28.tlf.novell.com>
In-Reply-To: <5062CC25020000780009DE44@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_DE8DF0795D48FD4CA783C40EC829233533C01CSHSMSX101ccrcorpi_"
MIME-Version: 1.0
Cc: Christoph Egger <Christoph.Egger@amd.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"keir@xen.org" <keir@xen.org>,
	"Ian.Campbell@citrix.com" <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH 6] X86/MCE: update vMCE injection for AMD
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--_002_DE8DF0795D48FD4CA783C40EC829233533C01CSHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Jan Beulich wrote:
>>>> On 26.09.12 at 05:11, "Liu, Jinsong" <jinsong.liu@intel.com> wrote:
>> I fold patch 6 to patch 2, will send out later.
>=20
> As I had indicated, I had done this already in preparation of things
> getting committed, so you will want to check once in staging
> (hopefully later today).
>=20
> Jan

Got it, thanks! It's OK to me, but how about add sanity check and some comm=
ents like

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Xen/MCE: add sanity check and comments for vmce injection

Add sanity check for input vcpu so that malicious value would not return 0.
Add comments since vcpu<0 (broadcast) is some implicit to code reader.

Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>

diff -r adc7f057011e xen/arch/x86/cpu/mcheck/vmce.c
--- a/xen/arch/x86/cpu/mcheck/vmce.c	Thu Sep 27 19:52:13 2012 +0800
+++ b/xen/arch/x86/cpu/mcheck/vmce.c	Thu Sep 27 20:56:52 2012 +0800
@@ -341,10 +341,16 @@
 /*
  * for Intel MCE, broadcast vMCE to all vcpus
  * for AMD MCE, only inject vMCE to vcpu0
+ *
+ * @ d, domain to which would inject vmce
+ * @ vcpu,
+ *   < 0, broadcast vMCE to all vcpus
+ *   >=3D 0, vcpu who would be injected vMCE
  */
 int inject_vmce(struct domain *d, int vcpu)
 {
     struct vcpu *v;
+    int ret =3D -EINVAL;
=20
     for_each_vcpu ( d, v )
     {
@@ -358,19 +364,21 @@
             mce_printk(MCE_VERBOSE, "MCE: inject vMCE to d%d:v%d\n",
                        d->domain_id, v->vcpu_id);
             vcpu_kick(v);
+            ret =3D 0;
         }
         else
         {
             mce_printk(MCE_QUIET, "Failed to inject vMCE to d%d:v%d\n",
                        d->domain_id, v->vcpu_id);
-            return -EBUSY;
+            ret =3D -EBUSY;
+            break;
         }
=20
         if ( vcpu >=3D 0 )
-            return 0;
+            break;
     }
=20
-    return v ? -ESRCH : 0;
+    return ret;
 }
=20
 int fill_vmsr_data(struct mcinfo_bank *mc_bank, struct domain *d,=

--_002_DE8DF0795D48FD4CA783C40EC829233533C01CSHSMSX101ccrcorpi_
Content-Type: application/octet-stream; name="vmce_injection_update.patch"
Content-Description: vmce_injection_update.patch
Content-Disposition: attachment; filename="vmce_injection_update.patch";
	size=1476; creation-date="Thu, 27 Sep 2012 05:15:25 GMT";
	modification-date="Thu, 27 Sep 2012 13:06:10 GMT"
Content-Transfer-Encoding: base64

WGVuL01DRTogYWRkIHNhbml0eSBjaGVjayBhbmQgY29tbWVudHMgZm9yIHZtY2UgaW5qZWN0aW9u
CgpBZGQgc2FuaXR5IGNoZWNrIGZvciBpbnB1dCB2Y3B1IHNvIHRoYXQgbWFsaWNpb3VzIHZhbHVl
IHdvdWxkIG5vdCByZXR1cm4gMC4KQWRkIGNvbW1lbnRzIHNpbmNlIHZjcHU8MCAoYnJvYWRjYXN0
KSBpcyBzb21lIGltcGxpY2l0IHRvIGNvZGUgcmVhZGVyLgoKU2lnbmVkLW9mZi1ieTogTGl1LCBK
aW5zb25nIDxqaW5zb25nLmxpdUBpbnRlbC5jb20+CgpkaWZmIC1yIGFkYzdmMDU3MDExZSB4ZW4v
YXJjaC94ODYvY3B1L21jaGVjay92bWNlLmMKLS0tIGEveGVuL2FyY2gveDg2L2NwdS9tY2hlY2sv
dm1jZS5jCVRodSBTZXAgMjcgMTk6NTI6MTMgMjAxMiArMDgwMAorKysgYi94ZW4vYXJjaC94ODYv
Y3B1L21jaGVjay92bWNlLmMJVGh1IFNlcCAyNyAyMDo1Njo1MiAyMDEyICswODAwCkBAIC0zNDEs
MTAgKzM0MSwxNiBAQAogLyoKICAqIGZvciBJbnRlbCBNQ0UsIGJyb2FkY2FzdCB2TUNFIHRvIGFs
bCB2Y3B1cwogICogZm9yIEFNRCBNQ0UsIG9ubHkgaW5qZWN0IHZNQ0UgdG8gdmNwdTAKKyAqCisg
KiBAIGQsIGRvbWFpbiB0byB3aGljaCB3b3VsZCBpbmplY3Qgdm1jZQorICogQCB2Y3B1LAorICog
ICA8IDAsIGJyb2FkY2FzdCB2TUNFIHRvIGFsbCB2Y3B1cworICogICA+PSAwLCB2Y3B1IHdobyB3
b3VsZCBiZSBpbmplY3RlZCB2TUNFCiAgKi8KIGludCBpbmplY3Rfdm1jZShzdHJ1Y3QgZG9tYWlu
ICpkLCBpbnQgdmNwdSkKIHsKICAgICBzdHJ1Y3QgdmNwdSAqdjsKKyAgICBpbnQgcmV0ID0gLUVJ
TlZBTDsKIAogICAgIGZvcl9lYWNoX3ZjcHUgKCBkLCB2ICkKICAgICB7CkBAIC0zNTgsMTkgKzM2
NCwyMSBAQAogICAgICAgICAgICAgbWNlX3ByaW50ayhNQ0VfVkVSQk9TRSwgIk1DRTogaW5qZWN0
IHZNQ0UgdG8gZCVkOnYlZFxuIiwKICAgICAgICAgICAgICAgICAgICAgICAgZC0+ZG9tYWluX2lk
LCB2LT52Y3B1X2lkKTsKICAgICAgICAgICAgIHZjcHVfa2ljayh2KTsKKyAgICAgICAgICAgIHJl
dCA9IDA7CiAgICAgICAgIH0KICAgICAgICAgZWxzZQogICAgICAgICB7CiAgICAgICAgICAgICBt
Y2VfcHJpbnRrKE1DRV9RVUlFVCwgIkZhaWxlZCB0byBpbmplY3Qgdk1DRSB0byBkJWQ6diVkXG4i
LAogICAgICAgICAgICAgICAgICAgICAgICBkLT5kb21haW5faWQsIHYtPnZjcHVfaWQpOwotICAg
ICAgICAgICAgcmV0dXJuIC1FQlVTWTsKKyAgICAgICAgICAgIHJldCA9IC1FQlVTWTsKKyAgICAg
ICAgICAgIGJyZWFrOwogICAgICAgICB9CiAKICAgICAgICAgaWYgKCB2Y3B1ID49IDAgKQotICAg
ICAgICAgICAgcmV0dXJuIDA7CisgICAgICAgICAgICBicmVhazsKICAgICB9CiAKLSAgICByZXR1
cm4gdiA/IC1FU1JDSCA6IDA7CisgICAgcmV0dXJuIHJldDsKIH0KIAogaW50IGZpbGxfdm1zcl9k
YXRhKHN0cnVjdCBtY2luZm9fYmFuayAqbWNfYmFuaywgc3RydWN0IGRvbWFpbiAqZCwK

--_002_DE8DF0795D48FD4CA783C40EC829233533C01CSHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 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_DE8DF0795D48FD4CA783C40EC829233533C01CSHSMSX101ccrcorpi_--


From xen-devel-bounces@lists.xen.org Thu Sep 27 05:59:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Sep 2012 05: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 1TH77U-0004rw-35; Thu, 27 Sep 2012 05:58:44 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <zhenzhong.duan@oracle.com>) id 1TH77T-0004rr-7v
	for xen-devel@lists.xen.org; Thu, 27 Sep 2012 05:58:43 +0000
Received: from [85.158.138.51:45715] by server-5.bemta-3.messagelabs.com id
	B0/A7-00589-21BE3605; Thu, 27 Sep 2012 05:58:42 +0000
X-Env-Sender: zhenzhong.duan@oracle.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1348725520!32055797!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzY3MTA2\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4462 invoked from network); 27 Sep 2012 05:58:41 -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; 27 Sep 2012 05:58:41 -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 q8R5wZpX025820
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 27 Sep 2012 05:58:36 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
	q8R5wXMb026351
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 27 Sep 2012 05:58:34 GMT
Received: from abhmt104.oracle.com (abhmt104.oracle.com [141.146.116.56])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q8R5wX4d016480; Thu, 27 Sep 2012 00:58:33 -0500
Received: from [10.191.1.53] (/10.191.1.53)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 26 Sep 2012 22:58:33 -0700
Message-ID: <5063EAFB.1070307@oracle.com>
Date: Thu, 27 Sep 2012 13:58:19 +0800
From: Zhenzhong Duan <zhenzhong.duan@oracle.com>
Organization: oracle
User-Agent: Mozilla/5.0 (Windows NT 5.1;
	rv:12.0) Gecko/20120428 Thunderbird/12.0.1
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk <konrad@kernel.org>
References: <505C3647.1030003@oracle.com>
	<20120921143430.GA3522@phenom.dumpdata.com>
	<5062C16A.1020306@oracle.com>
	<20120926123534.GF7356@phenom.dumpdata.com>
In-Reply-To: <20120926123534.GF7356@phenom.dumpdata.com>
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: Dan Magenheimer <dan.magenheimer@oracle.com>,
	xen-devel <xen-devel@lists.xen.org>, Feng Jin <joe.jin@oracle.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] an issue with 'xm save'
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: zhenzhong.duan@oracle.com
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org



On 2012-09-26 20:35, Konrad Rzeszutek Wilk wrote:
> On Wed, Sep 26, 2012 at 04:48:42PM +0800, Zhenzhong Duan wrote:
>> Konrad Rzeszutek Wilk wrote:
>>> On Fri, Sep 21, 2012 at 05:41:27PM +0800, Zhenzhong Duan wrote:
>>>> Hi maintainers,
>>>>
>>>> I found there is an issue when 'xm save' a pvm guest. See below:
>>>>
>>>> When I do save then restore once, CPU(%) in xentop showed around 99%.
>>>> When I do that second time, CPU(%) showed 199%
>>>>
>>>> top in dom0 showed:
>>>>      PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
>>>>     20946 root      18  -2 10984 1284  964 S 19.8  0.3   0:48.93 block
>>>>     4939 root      18  -2 10984 1288  964 S 19.5  0.3   1:34.68 block
>>>>
>>>> I could kill the block process, then all look normal again.
>>> What is the 'block' process? If you attach 'perf' to it do you get an idea
>>> of what it is spinning at?
>> It's /etc/xen/scripts/block
>> I add 'set -x' to /etc/xen/scripts/block, found it blocked at claim_lock.
>> When domU was created first time, claim_lock/release_lock finished quickly,
>> when 'xm save' was called, claim_lock spin in its own while loop.
>> I can ensure no other domU create/save/etc happen when I test.
> OK, so how come you have two block processes? Is it b/c you have two
> disks attached to the guest? The are multiple claim_lock in the shell
> script - do you know where each of two threads are spinning? Are they
> spinning on the same function?
In above test, I run save/restore twice, so two block processes.
In other test, run save/restore once, there is only one block process.
After do 'xm save', I see block process spin at line 328:
321   remove)
322     case $t in
323       phy)
324         exit 0
325         ;;
326
327       file)
328         claim_lock "block"
329         node=$(xenstore_read "$XENBUS_PATH/node")
330         losetup -d "$node"
331         release_lock "block"
332         exit 0
333         ;;

thanks
zduan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 27 05:59:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Sep 2012 05: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 1TH77U-0004rw-35; Thu, 27 Sep 2012 05:58:44 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <zhenzhong.duan@oracle.com>) id 1TH77T-0004rr-7v
	for xen-devel@lists.xen.org; Thu, 27 Sep 2012 05:58:43 +0000
Received: from [85.158.138.51:45715] by server-5.bemta-3.messagelabs.com id
	B0/A7-00589-21BE3605; Thu, 27 Sep 2012 05:58:42 +0000
X-Env-Sender: zhenzhong.duan@oracle.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1348725520!32055797!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzY3MTA2\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4462 invoked from network); 27 Sep 2012 05:58:41 -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; 27 Sep 2012 05:58:41 -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 q8R5wZpX025820
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 27 Sep 2012 05:58:36 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
	q8R5wXMb026351
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 27 Sep 2012 05:58:34 GMT
Received: from abhmt104.oracle.com (abhmt104.oracle.com [141.146.116.56])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q8R5wX4d016480; Thu, 27 Sep 2012 00:58:33 -0500
Received: from [10.191.1.53] (/10.191.1.53)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 26 Sep 2012 22:58:33 -0700
Message-ID: <5063EAFB.1070307@oracle.com>
Date: Thu, 27 Sep 2012 13:58:19 +0800
From: Zhenzhong Duan <zhenzhong.duan@oracle.com>
Organization: oracle
User-Agent: Mozilla/5.0 (Windows NT 5.1;
	rv:12.0) Gecko/20120428 Thunderbird/12.0.1
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk <konrad@kernel.org>
References: <505C3647.1030003@oracle.com>
	<20120921143430.GA3522@phenom.dumpdata.com>
	<5062C16A.1020306@oracle.com>
	<20120926123534.GF7356@phenom.dumpdata.com>
In-Reply-To: <20120926123534.GF7356@phenom.dumpdata.com>
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: Dan Magenheimer <dan.magenheimer@oracle.com>,
	xen-devel <xen-devel@lists.xen.org>, Feng Jin <joe.jin@oracle.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] an issue with 'xm save'
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: zhenzhong.duan@oracle.com
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org



On 2012-09-26 20:35, Konrad Rzeszutek Wilk wrote:
> On Wed, Sep 26, 2012 at 04:48:42PM +0800, Zhenzhong Duan wrote:
>> Konrad Rzeszutek Wilk wrote:
>>> On Fri, Sep 21, 2012 at 05:41:27PM +0800, Zhenzhong Duan wrote:
>>>> Hi maintainers,
>>>>
>>>> I found there is an issue when 'xm save' a pvm guest. See below:
>>>>
>>>> When I do save then restore once, CPU(%) in xentop showed around 99%.
>>>> When I do that second time, CPU(%) showed 199%
>>>>
>>>> top in dom0 showed:
>>>>      PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
>>>>     20946 root      18  -2 10984 1284  964 S 19.8  0.3   0:48.93 block
>>>>     4939 root      18  -2 10984 1288  964 S 19.5  0.3   1:34.68 block
>>>>
>>>> I could kill the block process, then all look normal again.
>>> What is the 'block' process? If you attach 'perf' to it do you get an idea
>>> of what it is spinning at?
>> It's /etc/xen/scripts/block
>> I add 'set -x' to /etc/xen/scripts/block, found it blocked at claim_lock.
>> When domU was created first time, claim_lock/release_lock finished quickly,
>> when 'xm save' was called, claim_lock spin in its own while loop.
>> I can ensure no other domU create/save/etc happen when I test.
> OK, so how come you have two block processes? Is it b/c you have two
> disks attached to the guest? The are multiple claim_lock in the shell
> script - do you know where each of two threads are spinning? Are they
> spinning on the same function?
In above test, I run save/restore twice, so two block processes.
In other test, run save/restore once, there is only one block process.
After do 'xm save', I see block process spin at line 328:
321   remove)
322     case $t in
323       phy)
324         exit 0
325         ;;
326
327       file)
328         claim_lock "block"
329         node=$(xenstore_read "$XENBUS_PATH/node")
330         losetup -d "$node"
331         release_lock "block"
332         exit 0
333         ;;

thanks
zduan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 27 06:49:23 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Sep 2012 06: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 1TH7u2-0005UG-4a; Thu, 27 Sep 2012 06:48:54 +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 1TH7tz-0005UB-7a
	for xen-devel@lists.xen.org; Thu, 27 Sep 2012 06:48:52 +0000
Received: from [85.158.143.35:55967] by server-3.bemta-4.messagelabs.com id
	0C/4E-10986-2D6F3605; Thu, 27 Sep 2012 06:48:50 +0000
X-Env-Sender: msw@amazon.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1348728528!15354770!1
X-Originating-IP: [207.171.184.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA3LjE3MS4xODQuMjUgPT4gMzE5MDg4\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20289 invoked from network); 27 Sep 2012 06:48:49 -0000
Received: from smtp-fw-9101.amazon.com (HELO smtp-fw-9101.amazon.com)
	(207.171.184.25)
	by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Sep 2012 06:48:49 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=amazon.com; i=msw@amazon.com; q=dns/txt;
	s=amazon201209; t=1348728529; x=1380264529;
	h=date:from:to:cc:subject:message-id:references:
	mime-version:in-reply-to;
	bh=q7YCUC0SACSvgYjj/ZdgTpShaRgirKV+ofIFDEBBWnY=;
	b=HnEKaOyamtU6gIxh6ruK2Sy2uRgPHrEzs2k6vi2tizu/HMp5DKwT79GO
	jmqAIubN2U0uwO9SOuBO4Mvxnw0NzJX/HiRrbjpw5oYj01RcGRdHoMzjc
	KNA68Z/6ANaG+DXq8dGrw+AiqV8WX70BL0ZU1/qrUeZLbinBvfZMdYbxR s=;
X-IronPort-AV: E=Sophos;i="4.80,495,1344211200"; d="scan'208";a="1031845159"
Received: from smtp-in-5102.iad5.amazon.com ([10.218.9.29])
	by smtp-border-fw-out-9101.sea19.amazon.com with
	ESMTP/TLS/DHE-RSA-AES256-SHA; 27 Sep 2012 06:48:46 +0000
Received: from ex10-hub-31005.ant.amazon.com (ex10-hub-31005.sea31.amazon.com
	[10.185.176.12])
	by smtp-in-5102.iad5.amazon.com (8.13.8/8.13.8) with ESMTP id
	q8R6mUHf017656
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL);
	Thu, 27 Sep 2012 06:48:31 GMT
Received: from u002268147cd4502c336d.ant.amazon.com (10.224.80.38) by
	ex10-hub-31005.ant.amazon.com (10.185.176.12) with Microsoft SMTP
	Server id 14.2.247.3; Wed, 26 Sep 2012 23:48:00 -0700
Received: by u002268147cd4502c336d.ant.amazon.com (sSMTP sendmail emulation); 
	Wed, 26 Sep 2012 23:47:58 -0700
Date: Wed, 26 Sep 2012 23:47:57 -0700
From: Matt Wilson <msw@amazon.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120927064755.GA9588@u002268147cd4502c336d.ant.amazon.com>
References: <CAFLBxZYtmJ_bKFb90r45=C4Pq1-oe5Fy=eygSsQf4BcGj3EqGA@mail.gmail.com>
	<505ADBCF020000780009C7BE@nat28.tlf.novell.com>
	<20120921031759.GA3953@u002268147cd4502c336d.ant.amazon.com>
	<5062CCA5.8010903@eu.citrix.com>
	<4B45B535F7F6BE4CB1C044ED5115CDDE011A6DD0105E@LONPMAILBOX01.citrite.net>
	<20120926171540.GA24005@u002268147cd4502c336d.ant.amazon.com>
	<1348685971.18736.11.camel@dagon.hellion.org.uk>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1348685971.18736.11.camel@dagon.hellion.org.uk>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	Thanos Makatos <thanos.makatos@citrix.com>,
	Jan Beulich <JBeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.3 development 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, Sep 26, 2012 at 07:59:31PM +0100, Ian Campbell wrote:
> On Wed, 2012-09-26 at 18:15 +0100, Matt Wilson wrote:
[...]
> > I brought this up in response to Jan's question as to if persistent
> > grants should be on the 4.3 release plan. With the introduction of
> > blktap3, we have a separate implementation of the protocol in a Xen
> > component. One worry I have about blktap3 is that it will lag behind
> > the in-kernel blkback implementation.
> 
> We already have multiple block backend implementations (blktap1,
> blktap2, qdisk, non-Linux dom0s), so I don't think that is a new
> concern.

For blktap2 we use blkback, so blktap2 users should be able to take
advantage of the improvements made there.

> If anything blktap3 improves things by making blktap1 + 2 obsolete, plus
> it comes with an active maintainer!

I'm not saying that blktap3 is a bad thing! It's definitely exciting.

> I think getting a working blktap3 implementation of the basic blk
> protocol for 4.3 is a big enough chunk of work in its own right, it's
> more than enough to fill someone's time for one release cycle IMHO.

Indeed, I'm impressed that it can be done. :-)

> So, I don't think implementing extensions (persistent grants, multipage
> rings etc) need to be a requirement for blktap3 in 4.3, there's always
> 4.4 and beyond. Of course if someone wants to contribute patches I'm
> sure Thanos would be very pleased ;-)

Definitely not a requirement, but a 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 Sep 27 06:49:23 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Sep 2012 06: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 1TH7u2-0005UG-4a; Thu, 27 Sep 2012 06:48:54 +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 1TH7tz-0005UB-7a
	for xen-devel@lists.xen.org; Thu, 27 Sep 2012 06:48:52 +0000
Received: from [85.158.143.35:55967] by server-3.bemta-4.messagelabs.com id
	0C/4E-10986-2D6F3605; Thu, 27 Sep 2012 06:48:50 +0000
X-Env-Sender: msw@amazon.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1348728528!15354770!1
X-Originating-IP: [207.171.184.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA3LjE3MS4xODQuMjUgPT4gMzE5MDg4\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20289 invoked from network); 27 Sep 2012 06:48:49 -0000
Received: from smtp-fw-9101.amazon.com (HELO smtp-fw-9101.amazon.com)
	(207.171.184.25)
	by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Sep 2012 06:48:49 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=amazon.com; i=msw@amazon.com; q=dns/txt;
	s=amazon201209; t=1348728529; x=1380264529;
	h=date:from:to:cc:subject:message-id:references:
	mime-version:in-reply-to;
	bh=q7YCUC0SACSvgYjj/ZdgTpShaRgirKV+ofIFDEBBWnY=;
	b=HnEKaOyamtU6gIxh6ruK2Sy2uRgPHrEzs2k6vi2tizu/HMp5DKwT79GO
	jmqAIubN2U0uwO9SOuBO4Mvxnw0NzJX/HiRrbjpw5oYj01RcGRdHoMzjc
	KNA68Z/6ANaG+DXq8dGrw+AiqV8WX70BL0ZU1/qrUeZLbinBvfZMdYbxR s=;
X-IronPort-AV: E=Sophos;i="4.80,495,1344211200"; d="scan'208";a="1031845159"
Received: from smtp-in-5102.iad5.amazon.com ([10.218.9.29])
	by smtp-border-fw-out-9101.sea19.amazon.com with
	ESMTP/TLS/DHE-RSA-AES256-SHA; 27 Sep 2012 06:48:46 +0000
Received: from ex10-hub-31005.ant.amazon.com (ex10-hub-31005.sea31.amazon.com
	[10.185.176.12])
	by smtp-in-5102.iad5.amazon.com (8.13.8/8.13.8) with ESMTP id
	q8R6mUHf017656
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL);
	Thu, 27 Sep 2012 06:48:31 GMT
Received: from u002268147cd4502c336d.ant.amazon.com (10.224.80.38) by
	ex10-hub-31005.ant.amazon.com (10.185.176.12) with Microsoft SMTP
	Server id 14.2.247.3; Wed, 26 Sep 2012 23:48:00 -0700
Received: by u002268147cd4502c336d.ant.amazon.com (sSMTP sendmail emulation); 
	Wed, 26 Sep 2012 23:47:58 -0700
Date: Wed, 26 Sep 2012 23:47:57 -0700
From: Matt Wilson <msw@amazon.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120927064755.GA9588@u002268147cd4502c336d.ant.amazon.com>
References: <CAFLBxZYtmJ_bKFb90r45=C4Pq1-oe5Fy=eygSsQf4BcGj3EqGA@mail.gmail.com>
	<505ADBCF020000780009C7BE@nat28.tlf.novell.com>
	<20120921031759.GA3953@u002268147cd4502c336d.ant.amazon.com>
	<5062CCA5.8010903@eu.citrix.com>
	<4B45B535F7F6BE4CB1C044ED5115CDDE011A6DD0105E@LONPMAILBOX01.citrite.net>
	<20120926171540.GA24005@u002268147cd4502c336d.ant.amazon.com>
	<1348685971.18736.11.camel@dagon.hellion.org.uk>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1348685971.18736.11.camel@dagon.hellion.org.uk>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	Thanos Makatos <thanos.makatos@citrix.com>,
	Jan Beulich <JBeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen 4.3 development 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, Sep 26, 2012 at 07:59:31PM +0100, Ian Campbell wrote:
> On Wed, 2012-09-26 at 18:15 +0100, Matt Wilson wrote:
[...]
> > I brought this up in response to Jan's question as to if persistent
> > grants should be on the 4.3 release plan. With the introduction of
> > blktap3, we have a separate implementation of the protocol in a Xen
> > component. One worry I have about blktap3 is that it will lag behind
> > the in-kernel blkback implementation.
> 
> We already have multiple block backend implementations (blktap1,
> blktap2, qdisk, non-Linux dom0s), so I don't think that is a new
> concern.

For blktap2 we use blkback, so blktap2 users should be able to take
advantage of the improvements made there.

> If anything blktap3 improves things by making blktap1 + 2 obsolete, plus
> it comes with an active maintainer!

I'm not saying that blktap3 is a bad thing! It's definitely exciting.

> I think getting a working blktap3 implementation of the basic blk
> protocol for 4.3 is a big enough chunk of work in its own right, it's
> more than enough to fill someone's time for one release cycle IMHO.

Indeed, I'm impressed that it can be done. :-)

> So, I don't think implementing extensions (persistent grants, multipage
> rings etc) need to be a requirement for blktap3 in 4.3, there's always
> 4.4 and beyond. Of course if someone wants to contribute patches I'm
> sure Thanos would be very pleased ;-)

Definitely not a requirement, but a 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 Sep 27 07:21:06 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Sep 2012 07:21:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TH8Ol-0006KB-LA; Thu, 27 Sep 2012 07:20: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 1TH8Ok-0006K6-4x
	for xen-devel@lists.xen.org; Thu, 27 Sep 2012 07:20:38 +0000
Received: from [85.158.138.51:33089] by server-11.bemta-3.messagelabs.com id
	CD/3F-21460-54EF3605; Thu, 27 Sep 2012 07:20:37 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1348730436!32125251!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 834 invoked from network); 27 Sep 2012 07:20:36 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-11.tower-174.messagelabs.com with SMTP;
	27 Sep 2012 07:20:36 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 27 Sep 2012 08:20:35 +0100
Message-Id: <50641A7B020000780009E2D1@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 27 Sep 2012 08:20:59 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Paul Durrant" <Paul.Durrant@citrix.com>
References: <1348662212-3559-1-git-send-email-paul.durrant@citrix.com>
	<1348662212-3559-2-git-send-email-paul.durrant@citrix.com>
	<5063150E020000780009DFD9@nat28.tlf.novell.com>
	<291EDFCB1E9E224A99088639C4762022EFF91D9B74@LONPMAILBOX01.citrite.net>
In-Reply-To: <291EDFCB1E9E224A99088639C4762022EFF91D9B74@LONPMAILBOX01.citrite.net>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 1/2] Add a new pvdrivers header to serve as
 the register of product numbers.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 26.09.12 at 15:16, Paul Durrant <Paul.Durrant@citrix.com> wrote:
>> From: Jan Beulich [mailto:JBeulich@suse.com]
>> >>> On 26.09.12 at 14:23, Paul Durrant <paul.durrant@citrix.com> wrote:
>> > + * a product number without allocating one.
>> > + * If you maintain a separate versioning and distribution path
>> > + * for PV drivers you should have a separate product number so
>> > + * that your drivers can be separated from others.
>> > + *
>> > + * During development, you may use the product ID to
>> > + * indicate a driver which is yet to be released.
>> 
>> Which "the product ID"?
>> 
> 
> The ones post-fixed '_ID'.

I would have thought it's meant to be specifically
PVDRIVERS_EXPERIMENTAL_ID, and hence expected that to be
spelled out.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 27 07:21:06 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Sep 2012 07:21:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TH8Ol-0006KB-LA; Thu, 27 Sep 2012 07:20: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 1TH8Ok-0006K6-4x
	for xen-devel@lists.xen.org; Thu, 27 Sep 2012 07:20:38 +0000
Received: from [85.158.138.51:33089] by server-11.bemta-3.messagelabs.com id
	CD/3F-21460-54EF3605; Thu, 27 Sep 2012 07:20:37 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1348730436!32125251!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 834 invoked from network); 27 Sep 2012 07:20:36 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-11.tower-174.messagelabs.com with SMTP;
	27 Sep 2012 07:20:36 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 27 Sep 2012 08:20:35 +0100
Message-Id: <50641A7B020000780009E2D1@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 27 Sep 2012 08:20:59 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Paul Durrant" <Paul.Durrant@citrix.com>
References: <1348662212-3559-1-git-send-email-paul.durrant@citrix.com>
	<1348662212-3559-2-git-send-email-paul.durrant@citrix.com>
	<5063150E020000780009DFD9@nat28.tlf.novell.com>
	<291EDFCB1E9E224A99088639C4762022EFF91D9B74@LONPMAILBOX01.citrite.net>
In-Reply-To: <291EDFCB1E9E224A99088639C4762022EFF91D9B74@LONPMAILBOX01.citrite.net>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 1/2] Add a new pvdrivers header to serve as
 the register of product numbers.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 26.09.12 at 15:16, Paul Durrant <Paul.Durrant@citrix.com> wrote:
>> From: Jan Beulich [mailto:JBeulich@suse.com]
>> >>> On 26.09.12 at 14:23, Paul Durrant <paul.durrant@citrix.com> wrote:
>> > + * a product number without allocating one.
>> > + * If you maintain a separate versioning and distribution path
>> > + * for PV drivers you should have a separate product number so
>> > + * that your drivers can be separated from others.
>> > + *
>> > + * During development, you may use the product ID to
>> > + * indicate a driver which is yet to be released.
>> 
>> Which "the product ID"?
>> 
> 
> The ones post-fixed '_ID'.

I would have thought it's meant to be specifically
PVDRIVERS_EXPERIMENTAL_ID, and hence expected that to be
spelled out.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 27 07:38:20 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Sep 2012 07:38:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TH8fS-0006Xj-8F; Thu, 27 Sep 2012 07:37:54 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1TH8fQ-0006Xe-Mf
	for xen-devel@lists.xen.org; Thu, 27 Sep 2012 07:37:52 +0000
Received: from [85.158.139.83:4784] by server-7.bemta-5.messagelabs.com id
	22/B6-00431-F4204605; Thu, 27 Sep 2012 07:37:51 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1348731471!32606126!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4446 invoked from network); 27 Sep 2012 07:37:51 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-10.tower-182.messagelabs.com with SMTP;
	27 Sep 2012 07:37:51 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 27 Sep 2012 08:37:50 +0100
Message-Id: <50641E86020000780009E2E3@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 27 Sep 2012 08:38:13 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ben Guthro" <ben@guthro.net>
References: <CAOvdn6UCF2A3yP1cqWn=dxwr0ayRbr+rg+xj8META9Dm0+CoNw@mail.gmail.com>
	<CC868168.3FD29%keir.xen@gmail.com>
	<CAOvdn6U-JyLvt96gkLkqzi088tU9_ktv4D+fkJac_BKVe05Y-w@mail.gmail.com>
	<CAOvdn6V+s3AbRzsu8VArbmrZou=im9SqvPf-9Wpif_BrNMv=yg@mail.gmail.com>
	<50617297020000780009D8AA@nat28.tlf.novell.com>
	<CAOvdn6Vsnbcd7m8mh3tSgn3KaEoeiOyVD1mr3uQ3bN=rF=pDUQ@mail.gmail.com>
	<5062F880020000780009DF3B@nat28.tlf.novell.com>
	<CAOvdn6VyAVg24=c1OxqttxuGFyN_NzpfZ7RoCYc2mVF84c5big@mail.gmail.com>
In-Reply-To: <CAOvdn6VyAVg24=c1OxqttxuGFyN_NzpfZ7RoCYc2mVF84c5big@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Keir Fraser <keir.xen@gmail.com>, John Baboval <john.baboval@citrix.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen4.2 S3 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 26.09.12 at 20:21, Ben Guthro <ben@guthro.net> wrote:
> I put a pr_debug at the top of collect_cpu_info - and from the trace below
> - it appears everything is as it should be,
> dom0 and Xen serial output get interspersed there for a few lines, but the
> microcode is, in fact being loaded for both CPUs.

Definitely not:

> [   36.787452] ACPI: Preparing to enter system sleep state S3
> [   37.240118] PM: Saving platform NVS memory
> [   37.313160] Disabling non-boot CPUs ...
> (XEN) Preparing system for ACPI S3 state.
> (XEN) Disabling non-boot CPUs ...
> (XEN) Breaking vcpu affinity for domain 0 vcpu 1
> (XEN) Entering ACPI S3 state.
> (XEN) mce_intel.c:1239: MCA Capability: BCAST 1 SER 0 CMCI 0 firstbank 1
> extended MCE MSR 0
> (XEN) CMCI: CPU0 has no CMCI support
> (XEN) CPU0: Thermal monitoring enabled (TM2)
> (XEN) Finishing wakeup from ACPI S3 state.
> (XEN) microcode: collect_cpu_info for CPU0
> (XEN) microcode: collect_cpu_info : sig=0x10676, pf=0x80, rev=0x60c

Rev 0x60c is being found installed, but no action is being done.

> (XEN) Enabling non-boot CPUs  ...
> (XEN) Booting processor 1/1 eip 8a000
> (XEN) Initializing CPU#1
> (XEN) CPU: L1 I cache: 32K, L1 D cache: 32K
> (XEN) CPU: L2 cache: 3072K
> (XEN) CPU: Physical Processor ID: 0
> (XEN) CPU: Processor Core ID: 1
> (XEN) CMCI: CPU1 has no CMCI support
> (XEN) CPU1: Thermal monitoring enabled (TM2)
> (XEN) CPU1: Intel(R) Core(TM)2 Duo CPU     P8400  @ 2.26GHz stepping 06
> (XEN) microcode: collect_cpu_info for CPU1
> [   37.420030] A(XEN) microcode: collect_cpu_info : sig=0x10676, pf=0x80, rev=0x60c
> CPI: Low-level r(XEN) microcode: CPU1 found a matching microcode update
> with version 0x60f (current=0x60c)
> esume complete
> (XEN) microcode: CPU1 updated from revision 0x60c to 0x60f, date = 2010-09-29

Whereas here an update is being done.

> [   37.420030] PM: Restoring platform NVS memory
> (XEN) microcode: collect_cpu_info for CPU0
> (XEN) microcode: collect_cpu_info : sig=0x10676, pf=0x80, rev=0x60c
> (XEN) microcode: collect_cpu_info for CPU1
> (XEN) microcode: collect_cpu_info : sig=0x10676, pf=0x80, rev=0x60f

And in the end we see that both cores run on different revisions.

The mixup of Xen and Dom0 messages puzzles me too - in my
understanding, all APs should be brought back up before
domains get unpaused. Is that perhaps part of your problem
with pinned vCPU-s? Or is the mixup not indicative of things
actually happening in parallel?

Jan

> [   37.431008] Enabling non-boot CPUs ...
> [   37.434851] installing Xen timer for CPU 1
> [   37.439031] cpu 1 spinlock event irq 279
> [   37.327214] Disabled fast string operations
> [   37.458040] CPU1 is up
> [   37.465417] ACPI: Waking up from system sleep state S3




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 27 07:38:20 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Sep 2012 07:38:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TH8fS-0006Xj-8F; Thu, 27 Sep 2012 07:37:54 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1TH8fQ-0006Xe-Mf
	for xen-devel@lists.xen.org; Thu, 27 Sep 2012 07:37:52 +0000
Received: from [85.158.139.83:4784] by server-7.bemta-5.messagelabs.com id
	22/B6-00431-F4204605; Thu, 27 Sep 2012 07:37:51 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1348731471!32606126!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4446 invoked from network); 27 Sep 2012 07:37:51 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-10.tower-182.messagelabs.com with SMTP;
	27 Sep 2012 07:37:51 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 27 Sep 2012 08:37:50 +0100
Message-Id: <50641E86020000780009E2E3@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 27 Sep 2012 08:38:13 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ben Guthro" <ben@guthro.net>
References: <CAOvdn6UCF2A3yP1cqWn=dxwr0ayRbr+rg+xj8META9Dm0+CoNw@mail.gmail.com>
	<CC868168.3FD29%keir.xen@gmail.com>
	<CAOvdn6U-JyLvt96gkLkqzi088tU9_ktv4D+fkJac_BKVe05Y-w@mail.gmail.com>
	<CAOvdn6V+s3AbRzsu8VArbmrZou=im9SqvPf-9Wpif_BrNMv=yg@mail.gmail.com>
	<50617297020000780009D8AA@nat28.tlf.novell.com>
	<CAOvdn6Vsnbcd7m8mh3tSgn3KaEoeiOyVD1mr3uQ3bN=rF=pDUQ@mail.gmail.com>
	<5062F880020000780009DF3B@nat28.tlf.novell.com>
	<CAOvdn6VyAVg24=c1OxqttxuGFyN_NzpfZ7RoCYc2mVF84c5big@mail.gmail.com>
In-Reply-To: <CAOvdn6VyAVg24=c1OxqttxuGFyN_NzpfZ7RoCYc2mVF84c5big@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Keir Fraser <keir.xen@gmail.com>, John Baboval <john.baboval@citrix.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen4.2 S3 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 26.09.12 at 20:21, Ben Guthro <ben@guthro.net> wrote:
> I put a pr_debug at the top of collect_cpu_info - and from the trace below
> - it appears everything is as it should be,
> dom0 and Xen serial output get interspersed there for a few lines, but the
> microcode is, in fact being loaded for both CPUs.

Definitely not:

> [   36.787452] ACPI: Preparing to enter system sleep state S3
> [   37.240118] PM: Saving platform NVS memory
> [   37.313160] Disabling non-boot CPUs ...
> (XEN) Preparing system for ACPI S3 state.
> (XEN) Disabling non-boot CPUs ...
> (XEN) Breaking vcpu affinity for domain 0 vcpu 1
> (XEN) Entering ACPI S3 state.
> (XEN) mce_intel.c:1239: MCA Capability: BCAST 1 SER 0 CMCI 0 firstbank 1
> extended MCE MSR 0
> (XEN) CMCI: CPU0 has no CMCI support
> (XEN) CPU0: Thermal monitoring enabled (TM2)
> (XEN) Finishing wakeup from ACPI S3 state.
> (XEN) microcode: collect_cpu_info for CPU0
> (XEN) microcode: collect_cpu_info : sig=0x10676, pf=0x80, rev=0x60c

Rev 0x60c is being found installed, but no action is being done.

> (XEN) Enabling non-boot CPUs  ...
> (XEN) Booting processor 1/1 eip 8a000
> (XEN) Initializing CPU#1
> (XEN) CPU: L1 I cache: 32K, L1 D cache: 32K
> (XEN) CPU: L2 cache: 3072K
> (XEN) CPU: Physical Processor ID: 0
> (XEN) CPU: Processor Core ID: 1
> (XEN) CMCI: CPU1 has no CMCI support
> (XEN) CPU1: Thermal monitoring enabled (TM2)
> (XEN) CPU1: Intel(R) Core(TM)2 Duo CPU     P8400  @ 2.26GHz stepping 06
> (XEN) microcode: collect_cpu_info for CPU1
> [   37.420030] A(XEN) microcode: collect_cpu_info : sig=0x10676, pf=0x80, rev=0x60c
> CPI: Low-level r(XEN) microcode: CPU1 found a matching microcode update
> with version 0x60f (current=0x60c)
> esume complete
> (XEN) microcode: CPU1 updated from revision 0x60c to 0x60f, date = 2010-09-29

Whereas here an update is being done.

> [   37.420030] PM: Restoring platform NVS memory
> (XEN) microcode: collect_cpu_info for CPU0
> (XEN) microcode: collect_cpu_info : sig=0x10676, pf=0x80, rev=0x60c
> (XEN) microcode: collect_cpu_info for CPU1
> (XEN) microcode: collect_cpu_info : sig=0x10676, pf=0x80, rev=0x60f

And in the end we see that both cores run on different revisions.

The mixup of Xen and Dom0 messages puzzles me too - in my
understanding, all APs should be brought back up before
domains get unpaused. Is that perhaps part of your problem
with pinned vCPU-s? Or is the mixup not indicative of things
actually happening in parallel?

Jan

> [   37.431008] Enabling non-boot CPUs ...
> [   37.434851] installing Xen timer for CPU 1
> [   37.439031] cpu 1 spinlock event irq 279
> [   37.327214] Disabled fast string operations
> [   37.458040] CPU1 is up
> [   37.465417] ACPI: Waking up from system sleep state S3




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 27 07:45:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Sep 2012 07: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 1TH8lz-0006lH-Of; Thu, 27 Sep 2012 07:44:39 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Paul.Durrant@citrix.com>) id 1TH8ly-0006ks-AX
	for xen-devel@lists.xen.org; Thu, 27 Sep 2012 07:44:38 +0000
Received: from [85.158.139.83:18460] by server-5.bemta-5.messagelabs.com id
	95/8F-21075-5E304605; Thu, 27 Sep 2012 07:44:37 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1348731876!29483614!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTE4ODI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32514 invoked from network); 27 Sep 2012 07:44:36 -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;
	27 Sep 2012 07:44:36 -0000
X-IronPort-AV: E=Sophos;i="4.80,494,1344211200"; d="scan'208";a="14794014"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Sep 2012 07:44:33 +0000
Received: from LONPMAILBOX01.citrite.net ([10.30.224.160]) by
	LONPMAILMX01.citrite.net ([10.30.203.162]) with mapi; Thu, 27 Sep 2012
	08:44:33 +0100
From: Paul Durrant <Paul.Durrant@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Thu, 27 Sep 2012 08:44:46 +0100
Thread-Topic: [Xen-devel] [PATCH 1/2] Add a new pvdrivers header to serve as
	the register of product numbers.
Thread-Index: Ac2cgJmAGPwJygcQRO29g5+/i4L71QAA0q+w
Message-ID: <291EDFCB1E9E224A99088639C4762022EFF91D9C0C@LONPMAILBOX01.citrite.net>
References: <1348662212-3559-1-git-send-email-paul.durrant@citrix.com>
	<1348662212-3559-2-git-send-email-paul.durrant@citrix.com>
	<5063150E020000780009DFD9@nat28.tlf.novell.com>
	<291EDFCB1E9E224A99088639C4762022EFF91D9B74@LONPMAILBOX01.citrite.net>
	<50641A7B020000780009E2D1@nat28.tlf.novell.com>
In-Reply-To: <50641A7B020000780009E2D1@nat28.tlf.novell.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 1/2] Add a new pvdrivers header to serve as
 the register of product numbers.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> -----Original Message-----
> From: Jan Beulich [mailto:JBeulich@suse.com]
> Sent: 27 September 2012 08:21
> To: Paul Durrant
> Cc: xen-devel@lists.xen.org
> Subject: Re: [Xen-devel] [PATCH 1/2] Add a new pvdrivers header to serve
> as the register of product numbers.
> 
> >>> On 26.09.12 at 15:16, Paul Durrant <Paul.Durrant@citrix.com> wrote:
> >> From: Jan Beulich [mailto:JBeulich@suse.com]
> >> >>> On 26.09.12 at 14:23, Paul Durrant <paul.durrant@citrix.com> wrote:
> >> > + * a product number without allocating one.
> >> > + * If you maintain a separate versioning and distribution path
> >> > + * for PV drivers you should have a separate product number so
> >> > + * that your drivers can be separated from others.
> >> > + *
> >> > + * During development, you may use the product ID to
> >> > + * indicate a driver which is yet to be released.
> >>
> >> Which "the product ID"?
> >>
> >
> > The ones post-fixed '_ID'.
> 
> I would have thought it's meant to be specifically
> PVDRIVERS_EXPERIMENTAL_ID, and hence expected that to be spelled out.
> 

Sorry, I misread what you'd said. Fixed in the 2nd version anyway.

  Paul


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 27 07:45:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Sep 2012 07: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 1TH8lz-0006lH-Of; Thu, 27 Sep 2012 07:44:39 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Paul.Durrant@citrix.com>) id 1TH8ly-0006ks-AX
	for xen-devel@lists.xen.org; Thu, 27 Sep 2012 07:44:38 +0000
Received: from [85.158.139.83:18460] by server-5.bemta-5.messagelabs.com id
	95/8F-21075-5E304605; Thu, 27 Sep 2012 07:44:37 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1348731876!29483614!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTE4ODI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32514 invoked from network); 27 Sep 2012 07:44:36 -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;
	27 Sep 2012 07:44:36 -0000
X-IronPort-AV: E=Sophos;i="4.80,494,1344211200"; d="scan'208";a="14794014"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Sep 2012 07:44:33 +0000
Received: from LONPMAILBOX01.citrite.net ([10.30.224.160]) by
	LONPMAILMX01.citrite.net ([10.30.203.162]) with mapi; Thu, 27 Sep 2012
	08:44:33 +0100
From: Paul Durrant <Paul.Durrant@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Thu, 27 Sep 2012 08:44:46 +0100
Thread-Topic: [Xen-devel] [PATCH 1/2] Add a new pvdrivers header to serve as
	the register of product numbers.
Thread-Index: Ac2cgJmAGPwJygcQRO29g5+/i4L71QAA0q+w
Message-ID: <291EDFCB1E9E224A99088639C4762022EFF91D9C0C@LONPMAILBOX01.citrite.net>
References: <1348662212-3559-1-git-send-email-paul.durrant@citrix.com>
	<1348662212-3559-2-git-send-email-paul.durrant@citrix.com>
	<5063150E020000780009DFD9@nat28.tlf.novell.com>
	<291EDFCB1E9E224A99088639C4762022EFF91D9B74@LONPMAILBOX01.citrite.net>
	<50641A7B020000780009E2D1@nat28.tlf.novell.com>
In-Reply-To: <50641A7B020000780009E2D1@nat28.tlf.novell.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 1/2] Add a new pvdrivers header to serve as
 the register of product numbers.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> -----Original Message-----
> From: Jan Beulich [mailto:JBeulich@suse.com]
> Sent: 27 September 2012 08:21
> To: Paul Durrant
> Cc: xen-devel@lists.xen.org
> Subject: Re: [Xen-devel] [PATCH 1/2] Add a new pvdrivers header to serve
> as the register of product numbers.
> 
> >>> On 26.09.12 at 15:16, Paul Durrant <Paul.Durrant@citrix.com> wrote:
> >> From: Jan Beulich [mailto:JBeulich@suse.com]
> >> >>> On 26.09.12 at 14:23, Paul Durrant <paul.durrant@citrix.com> wrote:
> >> > + * a product number without allocating one.
> >> > + * If you maintain a separate versioning and distribution path
> >> > + * for PV drivers you should have a separate product number so
> >> > + * that your drivers can be separated from others.
> >> > + *
> >> > + * During development, you may use the product ID to
> >> > + * indicate a driver which is yet to be released.
> >>
> >> Which "the product ID"?
> >>
> >
> > The ones post-fixed '_ID'.
> 
> I would have thought it's meant to be specifically
> PVDRIVERS_EXPERIMENTAL_ID, and hence expected that to be spelled out.
> 

Sorry, I misread what you'd said. Fixed in the 2nd version anyway.

  Paul


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 27 07:47:18 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Sep 2012 07:47:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TH8oG-0006zs-9T; Thu, 27 Sep 2012 07:47:00 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1TH8oF-0006zb-2D
	for xen-devel@lists.xen.org; Thu, 27 Sep 2012 07:46:59 +0000
Received: from [85.158.143.99:28301] by server-3.bemta-4.messagelabs.com id
	6B/78-10986-27404605; Thu, 27 Sep 2012 07:46:58 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1348732017!31979053!1
X-Originating-IP: [209.85.215.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23004 invoked from network); 27 Sep 2012 07:46:57 -0000
Received: from mail-ey0-f173.google.com (HELO mail-ey0-f173.google.com)
	(209.85.215.173)
	by server-9.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Sep 2012 07:46:57 -0000
Received: by eaaa1 with SMTP id a1so564681eaa.32
	for <xen-devel@lists.xen.org>; Thu, 27 Sep 2012 00:46:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=BdOVMwTIlXuK3YCHqbgkKS1Wl31KZcbkATD/8eIbmoQ=;
	b=sUi5YzPI6ZDvnqvmBJ9I8TS/EHsbua0Uv1lh29g9SygofYcrk4hSV75QE+h3gWEwuL
	y5EQo8g6aV0L1bg0OQXh06FJnFD04h1ClLLyamB4bFK2LyUG36zIhVAVI82eMhWiap4h
	SDjDsV+ylY0m65Sfv9qOkGWRfvsBPRw9AjwmZqlgKbh626M85/De2wJJESq1VQh0IdFo
	z3uADdrWPDSueQLqAtx6QDOUrCE47d7sDmuc8x9ExdnuhTKNR2DRn1LnIU8NrEvp66HO
	8Y3XvYFbfiZB7JNPF7blnrrpmmvItZcqAis9KhlDRHvuQlT2lqGLJubofCfxBfOjcynI
	rs4g==
Received: by 10.14.202.131 with SMTP id d3mr4813577eeo.32.1348732017084;
	Thu, 27 Sep 2012 00:46:57 -0700 (PDT)
Received: from [192.168.1.3] (host86-160-224-180.range86-160.btcentralplus.com.
	[86.160.224.180])
	by mx.google.com with ESMTPS id v3sm15473779eep.10.2012.09.27.00.46.55
	(version=SSLv3 cipher=OTHER); Thu, 27 Sep 2012 00:46:56 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.33.0.120411
Date: Thu, 27 Sep 2012 08:46:52 +0100
From: Keir Fraser <keir@xen.org>
To: Jan Beulich <JBeulich@suse.com>,
	Ben Guthro <ben@guthro.net>
Message-ID: <CC89C2FC.4CF7C%keir@xen.org>
Thread-Topic: [Xen-devel] Xen4.2 S3 regression?
Thread-Index: Ac2chEH313Dvhis2R0+J8U6LfLnnYA==
In-Reply-To: <50641E86020000780009E2E3@nat28.tlf.novell.com>
Mime-version: 1.0
Cc: John Baboval <john.baboval@citrix.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen4.2 S3 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 27/09/2012 08:38, "Jan Beulich" <JBeulich@suse.com> wrote:

>> [   37.420030] PM: Restoring platform NVS memory
>> (XEN) microcode: collect_cpu_info for CPU0
>> (XEN) microcode: collect_cpu_info : sig=0x10676, pf=0x80, rev=0x60c
>> (XEN) microcode: collect_cpu_info for CPU1
>> (XEN) microcode: collect_cpu_info : sig=0x10676, pf=0x80, rev=0x60f
> 
> And in the end we see that both cores run on different revisions.
> 
> The mixup of Xen and Dom0 messages puzzles me too - in my
> understanding, all APs should be brought back up before
> domains get unpaused.

Ah, of course! This makes a nonsense of my explanation of the observed crash
in _csched_cpu_pick -- dom0 cannot be running while Aps are still being
brought back online, because domains are not unpaused until all CPUs are
back online.

So it's a mystery again. :)

 -- Keir

> Is that perhaps part of your problem
> with pinned vCPU-s? Or is the mixup not indicative of things
> actually happening in parallel?
> 
> Jan
> 
>> [   37.431008] Enabling non-boot CPUs ...
>> [   37.434851] installing Xen timer for CPU 1
>> [   37.439031] cpu 1 spinlock event irq 279
>> [   37.327214] Disabled fast string operations
>> [   37.458040] CPU1 is up
>> [   37.465417] ACPI: Waking up from system sleep state S3
> 
> 
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 27 07:47:18 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Sep 2012 07:47:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TH8oG-0006zs-9T; Thu, 27 Sep 2012 07:47:00 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1TH8oF-0006zb-2D
	for xen-devel@lists.xen.org; Thu, 27 Sep 2012 07:46:59 +0000
Received: from [85.158.143.99:28301] by server-3.bemta-4.messagelabs.com id
	6B/78-10986-27404605; Thu, 27 Sep 2012 07:46:58 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1348732017!31979053!1
X-Originating-IP: [209.85.215.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23004 invoked from network); 27 Sep 2012 07:46:57 -0000
Received: from mail-ey0-f173.google.com (HELO mail-ey0-f173.google.com)
	(209.85.215.173)
	by server-9.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Sep 2012 07:46:57 -0000
Received: by eaaa1 with SMTP id a1so564681eaa.32
	for <xen-devel@lists.xen.org>; Thu, 27 Sep 2012 00:46:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=BdOVMwTIlXuK3YCHqbgkKS1Wl31KZcbkATD/8eIbmoQ=;
	b=sUi5YzPI6ZDvnqvmBJ9I8TS/EHsbua0Uv1lh29g9SygofYcrk4hSV75QE+h3gWEwuL
	y5EQo8g6aV0L1bg0OQXh06FJnFD04h1ClLLyamB4bFK2LyUG36zIhVAVI82eMhWiap4h
	SDjDsV+ylY0m65Sfv9qOkGWRfvsBPRw9AjwmZqlgKbh626M85/De2wJJESq1VQh0IdFo
	z3uADdrWPDSueQLqAtx6QDOUrCE47d7sDmuc8x9ExdnuhTKNR2DRn1LnIU8NrEvp66HO
	8Y3XvYFbfiZB7JNPF7blnrrpmmvItZcqAis9KhlDRHvuQlT2lqGLJubofCfxBfOjcynI
	rs4g==
Received: by 10.14.202.131 with SMTP id d3mr4813577eeo.32.1348732017084;
	Thu, 27 Sep 2012 00:46:57 -0700 (PDT)
Received: from [192.168.1.3] (host86-160-224-180.range86-160.btcentralplus.com.
	[86.160.224.180])
	by mx.google.com with ESMTPS id v3sm15473779eep.10.2012.09.27.00.46.55
	(version=SSLv3 cipher=OTHER); Thu, 27 Sep 2012 00:46:56 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.33.0.120411
Date: Thu, 27 Sep 2012 08:46:52 +0100
From: Keir Fraser <keir@xen.org>
To: Jan Beulich <JBeulich@suse.com>,
	Ben Guthro <ben@guthro.net>
Message-ID: <CC89C2FC.4CF7C%keir@xen.org>
Thread-Topic: [Xen-devel] Xen4.2 S3 regression?
Thread-Index: Ac2chEH313Dvhis2R0+J8U6LfLnnYA==
In-Reply-To: <50641E86020000780009E2E3@nat28.tlf.novell.com>
Mime-version: 1.0
Cc: John Baboval <john.baboval@citrix.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen4.2 S3 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 27/09/2012 08:38, "Jan Beulich" <JBeulich@suse.com> wrote:

>> [   37.420030] PM: Restoring platform NVS memory
>> (XEN) microcode: collect_cpu_info for CPU0
>> (XEN) microcode: collect_cpu_info : sig=0x10676, pf=0x80, rev=0x60c
>> (XEN) microcode: collect_cpu_info for CPU1
>> (XEN) microcode: collect_cpu_info : sig=0x10676, pf=0x80, rev=0x60f
> 
> And in the end we see that both cores run on different revisions.
> 
> The mixup of Xen and Dom0 messages puzzles me too - in my
> understanding, all APs should be brought back up before
> domains get unpaused.

Ah, of course! This makes a nonsense of my explanation of the observed crash
in _csched_cpu_pick -- dom0 cannot be running while Aps are still being
brought back online, because domains are not unpaused until all CPUs are
back online.

So it's a mystery again. :)

 -- Keir

> Is that perhaps part of your problem
> with pinned vCPU-s? Or is the mixup not indicative of things
> actually happening in parallel?
> 
> Jan
> 
>> [   37.431008] Enabling non-boot CPUs ...
>> [   37.434851] installing Xen timer for CPU 1
>> [   37.439031] cpu 1 spinlock event irq 279
>> [   37.327214] Disabled fast string operations
>> [   37.458040] CPU1 is up
>> [   37.465417] ACPI: Waking up from system sleep state S3
> 
> 
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 27 08:06:58 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Sep 2012 08: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 1TH97C-0007ui-0n; Thu, 27 Sep 2012 08:06:34 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1TH97A-0007ud-6T
	for xen-devel@lists.xen.org; Thu, 27 Sep 2012 08:06:32 +0000
Received: from [85.158.137.99:7180] by server-14.bemta-3.messagelabs.com id
	C9/50-25886-70904605; Thu, 27 Sep 2012 08:06:31 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-4.tower-217.messagelabs.com!1348733190!19317501!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=UPPERCASE_25_50
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5572 invoked from network); 27 Sep 2012 08:06:30 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-4.tower-217.messagelabs.com with SMTP;
	27 Sep 2012 08:06:30 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 27 Sep 2012 09:06:29 +0100
Message-Id: <5064253C020000780009E312@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 27 Sep 2012 09:06:52 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Konrad Rzeszutek Wilk" <konrad@kernel.org>
References: <1348662212-3559-1-git-send-email-paul.durrant@citrix.com>
	<1348662212-3559-2-git-send-email-paul.durrant@citrix.com>
	<20120926124915.GH7356@phenom.dumpdata.com>
In-Reply-To: <20120926124915.GH7356@phenom.dumpdata.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: annie.li@oracle.com, Paul Durrant <paul.durrant@citrix.com>,
	steve.prochniak@oracle.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 1/2] Add a new pvdrivers header to serve as
 the register of product numbers.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 26.09.12 at 14:49, Konrad Rzeszutek Wilk <konrad@kernel.org> wrote:
> On Wed, Sep 26, 2012 at 01:23:31PM +0100, Paul Durrant wrote:
>> +#define	PVDRIVERS_XENSOURCE_WINDOWS_ID		0x0001	/* Citrix */
>> +#define	PVDRIVERS_XENSOURCE_WINDOWS_NAME	"xensource-windows"
>> +
>> +#define	PVDRIVERS_GPLPV_WINDOWS_ID		0x0002	/* James Harper */
>> +#define	PVDRIVERS_GPLPV_WINDOWS_NAME		"gplpv-windows"
> 
> And also the Oracle one :-)
> 
> The Novell one looks to be using 107?

Where did you spot that one? I was only able to locate use of
0xffff...

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 27 08:06:58 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Sep 2012 08: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 1TH97C-0007ui-0n; Thu, 27 Sep 2012 08:06:34 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1TH97A-0007ud-6T
	for xen-devel@lists.xen.org; Thu, 27 Sep 2012 08:06:32 +0000
Received: from [85.158.137.99:7180] by server-14.bemta-3.messagelabs.com id
	C9/50-25886-70904605; Thu, 27 Sep 2012 08:06:31 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-4.tower-217.messagelabs.com!1348733190!19317501!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=UPPERCASE_25_50
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5572 invoked from network); 27 Sep 2012 08:06:30 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-4.tower-217.messagelabs.com with SMTP;
	27 Sep 2012 08:06:30 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 27 Sep 2012 09:06:29 +0100
Message-Id: <5064253C020000780009E312@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 27 Sep 2012 09:06:52 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Konrad Rzeszutek Wilk" <konrad@kernel.org>
References: <1348662212-3559-1-git-send-email-paul.durrant@citrix.com>
	<1348662212-3559-2-git-send-email-paul.durrant@citrix.com>
	<20120926124915.GH7356@phenom.dumpdata.com>
In-Reply-To: <20120926124915.GH7356@phenom.dumpdata.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: annie.li@oracle.com, Paul Durrant <paul.durrant@citrix.com>,
	steve.prochniak@oracle.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 1/2] Add a new pvdrivers header to serve as
 the register of product numbers.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 26.09.12 at 14:49, Konrad Rzeszutek Wilk <konrad@kernel.org> wrote:
> On Wed, Sep 26, 2012 at 01:23:31PM +0100, Paul Durrant wrote:
>> +#define	PVDRIVERS_XENSOURCE_WINDOWS_ID		0x0001	/* Citrix */
>> +#define	PVDRIVERS_XENSOURCE_WINDOWS_NAME	"xensource-windows"
>> +
>> +#define	PVDRIVERS_GPLPV_WINDOWS_ID		0x0002	/* James Harper */
>> +#define	PVDRIVERS_GPLPV_WINDOWS_NAME		"gplpv-windows"
> 
> And also the Oracle one :-)
> 
> The Novell one looks to be using 107?

Where did you spot that one? I was only able to locate use of
0xffff...

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 27 08:25:53 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Sep 2012 08: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 1TH9PW-00084q-Nf; Thu, 27 Sep 2012 08:25:30 +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 1TH9PV-00084l-Ha
	for xen-devel@lists.xen.org; Thu, 27 Sep 2012 08:25:29 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1348734322!11958621!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26479 invoked from network); 27 Sep 2012 08:25:23 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-4.tower-27.messagelabs.com with SMTP;
	27 Sep 2012 08:25:23 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 27 Sep 2012 09:25:22 +0100
Message-Id: <506429A9020000780009E32A@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 27 Sep 2012 09:25:45 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Wei Wang" <wei.wang2@amd.com>
References: <50631554.1080100@amd.com>
In-Reply-To: <50631554.1080100@amd.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Keir Fraser <keir@xen.org>, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 1 of 6 V6] amd iommu: Add 2 hypercalls for
	libxc
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 26.09.12 at 16:46, Wei Wang <wei.wang2@amd.com> wrote:
>-static unsigned int machine_bdf(struct domain *d, uint16_t guest_bdf)
>+static unsigned int machine_bdf(struct domain *d, uint16_t guest_seg,
>+                                uint16_t guest_bdf)
> {
>-    return guest_bdf;
>+    struct pci_dev *pdev;
>+    uint16_t mbdf = 0;

Is that really a suitable error indicator?

>@@ -207,7 +224,7 @@ void guest_iommu_add_ppr_log(struct domain *d, u32 entry[])
>     log = log_base + tail % (PAGE_SIZE / sizeof(ppr_entry_t));
> 
>     /* Convert physical device id back into virtual device id */
>-    gdev_id = guest_bdf(d, iommu_get_devid_from_cmd(entry[0]));
>+    gdev_id = guest_bdf(d, 0, iommu_get_devid_from_cmd(entry[0]));

Zero (here and below)? You'll have to get the segment out of
the physical IOMMU's control structure. Using plain zero is only
okay (for the time being) for guest devices (under the
assumption that they will all get surfaced on segment zero), i.e.
for calls to machine_bdf() (and you could shrink the patch by not
doing the adjustment there in the first place if only segment 0 is
possible right now).

>+/* Support for guest iommu emulation */
>+struct xen_domctl_guest_iommu_op {
>+    /* XEN_DOMCTL_GUEST_IOMMU_OP_* */
>+#define XEN_DOMCTL_GUEST_IOMMU_OP_SET_MSI               0
>+#define XEN_DOMCTL_GUEST_IOMMU_OP_BIND_BDF              1
>+    uint8_t op;
>+    union {
>+        struct iommu_msi {
>+            uint8_t     vector;
>+            uint8_t     dest;

For virtual x2APIC support, this ought to be 32 bits wide.

>+            uint8_t     dest_mode;
>+            uint8_t     delivery_mode;
>+            uint8_t     trig_mode;
>+        } msi;

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 27 08:25:53 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Sep 2012 08: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 1TH9PW-00084q-Nf; Thu, 27 Sep 2012 08:25:30 +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 1TH9PV-00084l-Ha
	for xen-devel@lists.xen.org; Thu, 27 Sep 2012 08:25:29 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1348734322!11958621!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26479 invoked from network); 27 Sep 2012 08:25:23 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-4.tower-27.messagelabs.com with SMTP;
	27 Sep 2012 08:25:23 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 27 Sep 2012 09:25:22 +0100
Message-Id: <506429A9020000780009E32A@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 27 Sep 2012 09:25:45 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Wei Wang" <wei.wang2@amd.com>
References: <50631554.1080100@amd.com>
In-Reply-To: <50631554.1080100@amd.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Keir Fraser <keir@xen.org>, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 1 of 6 V6] amd iommu: Add 2 hypercalls for
	libxc
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 26.09.12 at 16:46, Wei Wang <wei.wang2@amd.com> wrote:
>-static unsigned int machine_bdf(struct domain *d, uint16_t guest_bdf)
>+static unsigned int machine_bdf(struct domain *d, uint16_t guest_seg,
>+                                uint16_t guest_bdf)
> {
>-    return guest_bdf;
>+    struct pci_dev *pdev;
>+    uint16_t mbdf = 0;

Is that really a suitable error indicator?

>@@ -207,7 +224,7 @@ void guest_iommu_add_ppr_log(struct domain *d, u32 entry[])
>     log = log_base + tail % (PAGE_SIZE / sizeof(ppr_entry_t));
> 
>     /* Convert physical device id back into virtual device id */
>-    gdev_id = guest_bdf(d, iommu_get_devid_from_cmd(entry[0]));
>+    gdev_id = guest_bdf(d, 0, iommu_get_devid_from_cmd(entry[0]));

Zero (here and below)? You'll have to get the segment out of
the physical IOMMU's control structure. Using plain zero is only
okay (for the time being) for guest devices (under the
assumption that they will all get surfaced on segment zero), i.e.
for calls to machine_bdf() (and you could shrink the patch by not
doing the adjustment there in the first place if only segment 0 is
possible right now).

>+/* Support for guest iommu emulation */
>+struct xen_domctl_guest_iommu_op {
>+    /* XEN_DOMCTL_GUEST_IOMMU_OP_* */
>+#define XEN_DOMCTL_GUEST_IOMMU_OP_SET_MSI               0
>+#define XEN_DOMCTL_GUEST_IOMMU_OP_BIND_BDF              1
>+    uint8_t op;
>+    union {
>+        struct iommu_msi {
>+            uint8_t     vector;
>+            uint8_t     dest;

For virtual x2APIC support, this ought to be 32 bits wide.

>+            uint8_t     dest_mode;
>+            uint8_t     delivery_mode;
>+            uint8_t     trig_mode;
>+        } msi;

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 27 08:28:43 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Sep 2012 08:28:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TH9SH-0008AV-9w; Thu, 27 Sep 2012 08:28:21 +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 1TH9SG-0008AJ-DR
	for xen-devel@lists.xensource.com; Thu, 27 Sep 2012 08:28:20 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1348734456!12531400!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23625 invoked from network); 27 Sep 2012 08:27:36 -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;
	27 Sep 2012 08:27:36 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 27 Sep 2012 09:27:36 +0100
Message-Id: <50642A2A020000780009E32D@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 27 Sep 2012 09:27:54 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Wei Wang" <wei.wang2@amd.com>
References: <5063155A.4070307@amd.com>
In-Reply-To: <5063155A.4070307@amd.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Keir Fraser <keir@xen.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	IanCampbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH 2 of 6 V6] amd iommu: call
 guest_iommu_set_base from hvmloader
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.09.12 at 16:46, Wei Wang <wei.wang2@amd.com> wrote:
>@@ -3834,6 +3835,9 @@ long do_hvm_op(unsigned long op, XEN_GUEST_HANDLE(void) arg)
>             case HVM_PARAM_BUFIOREQ_EVTCHN:
>                 rc = -EINVAL;
>                 break;
>+            case HVM_PARAM_IOMMU_BASE:
>+                rc = guest_iommu_set_base(d, a.value);

This suggests that you're allowing for only a single IOMMU per
guest - is that not going to become an issue sooner or later?

Jan

>+                break;
>             }
> 
>             if ( rc == 0 ) 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 27 08:28:43 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Sep 2012 08:28:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TH9SH-0008AV-9w; Thu, 27 Sep 2012 08:28:21 +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 1TH9SG-0008AJ-DR
	for xen-devel@lists.xensource.com; Thu, 27 Sep 2012 08:28:20 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1348734456!12531400!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23625 invoked from network); 27 Sep 2012 08:27:36 -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;
	27 Sep 2012 08:27:36 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 27 Sep 2012 09:27:36 +0100
Message-Id: <50642A2A020000780009E32D@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 27 Sep 2012 09:27:54 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Wei Wang" <wei.wang2@amd.com>
References: <5063155A.4070307@amd.com>
In-Reply-To: <5063155A.4070307@amd.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Keir Fraser <keir@xen.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	IanCampbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH 2 of 6 V6] amd iommu: call
 guest_iommu_set_base from hvmloader
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.09.12 at 16:46, Wei Wang <wei.wang2@amd.com> wrote:
>@@ -3834,6 +3835,9 @@ long do_hvm_op(unsigned long op, XEN_GUEST_HANDLE(void) arg)
>             case HVM_PARAM_BUFIOREQ_EVTCHN:
>                 rc = -EINVAL;
>                 break;
>+            case HVM_PARAM_IOMMU_BASE:
>+                rc = guest_iommu_set_base(d, a.value);

This suggests that you're allowing for only a single IOMMU per
guest - is that not going to become an issue sooner or later?

Jan

>+                break;
>             }
> 
>             if ( rc == 0 ) 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 27 08:55:00 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Sep 2012 08:55:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TH9rh-0008Sf-KV; Thu, 27 Sep 2012 08:54:37 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Christoph.Egger@amd.com>) id 1TH9rf-0008Sa-Lq
	for xen-devel@lists.xensource.com; Thu, 27 Sep 2012 08:54:35 +0000
Received: from [85.158.143.99:7283] by server-3.bemta-4.messagelabs.com id
	B0/30-10986-A4414605; Thu, 27 Sep 2012 08:54:34 +0000
X-Env-Sender: Christoph.Egger@amd.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1348736071!31619425!1
X-Originating-IP: [216.32.180.188]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14942 invoked from network); 27 Sep 2012 08:54:33 -0000
Received: from co1ehsobe005.messaging.microsoft.com (HELO
	co1outboundpool.messaging.microsoft.com) (216.32.180.188)
	by server-5.tower-216.messagelabs.com with AES128-SHA encrypted SMTP;
	27 Sep 2012 08:54:33 -0000
Received: from mail31-co1-R.bigfish.com (10.243.78.237) by
	CO1EHSOBE013.bigfish.com (10.243.66.76) with Microsoft SMTP Server id
	14.1.225.23; Thu, 27 Sep 2012 08:54:31 +0000
Received: from mail31-co1 (localhost [127.0.0.1])	by mail31-co1-R.bigfish.com
	(Postfix) with ESMTP id 10515D000FA;
	Thu, 27 Sep 2012 08:54:31 +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: -6
X-BigFish: VPS-6(zzbb2dI98dI103dK1432Izz1202h1d1ah1d2ahzz8275bhz2dh668h839hd25he5bhf0ah107ah1288h12a5h12a9h12bdh137ah13b6h1155h)
Received: from mail31-co1 (localhost.localdomain [127.0.0.1]) by mail31-co1
	(MessageSwitch) id 1348736068677285_21949;
	Thu, 27 Sep 2012 08:54:28 +0000 (UTC)
Received: from CO1EHSMHS001.bigfish.com (unknown [10.243.78.243])	by
	mail31-co1.bigfish.com (Postfix) with ESMTP id 97451C80019;
	Thu, 27 Sep 2012 08:54:28 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	CO1EHSMHS001.bigfish.com (10.243.66.11) with Microsoft SMTP Server id
	14.1.225.23; Thu, 27 Sep 2012 08:54:26 +0000
X-WSS-ID: 0MB03EO-01-IQ8-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 291791028036;	Thu, 27 Sep 2012 03:54:23 -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;
	Thu, 27 Sep 2012 03:54:39 -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;
	Thu, 27 Sep 2012 03:54:23 -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, 27 Sep 2012
	04:54:22 -0400
Message-ID: <5064143A.6070203@amd.com>
Date: Thu, 27 Sep 2012 10:54: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: "Liu, Jinsong" <jinsong.liu@intel.com>
References: <DE8DF0795D48FD4CA783C40EC8292335339547@SHSMSX101.ccr.corp.intel.com>
	<506173FB.8070603@amd.com>
	<5061A833020000780009DA1A@nat28.tlf.novell.com>
	<50619B61.2030609@amd.com>
	<DE8DF0795D48FD4CA783C40EC829233533AA6E@SHSMSX101.ccr.corp.intel.com>
	<5062CC25020000780009DE44@nat28.tlf.novell.com>
	<DE8DF0795D48FD4CA783C40EC829233533C01C@SHSMSX101.ccr.corp.intel.com>
In-Reply-To: <DE8DF0795D48FD4CA783C40EC829233533C01C@SHSMSX101.ccr.corp.intel.com>
X-OriginatorOrg: amd.com
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"keir@xen.org" <keir@xen.org>,
	"Ian.Campbell@citrix.com" <Ian.Campbell@citrix.com>,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH 6] X86/MCE: update vMCE injection for AMD
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 09/27/12 07:22, Liu, Jinsong wrote:

> Jan Beulich wrote:
>>>>> On 26.09.12 at 05:11, "Liu, Jinsong" <jinsong.liu@intel.com> wrote:
>>> I fold patch 6 to patch 2, will send out later.
>>
>> As I had indicated, I had done this already in preparation of things
>> getting committed, so you will want to check once in staging
>> (hopefully later today).
>>
>> Jan
> 
> Got it, thanks! It's OK to me, but how about add sanity check and some comments like
> 
> ==================
> Xen/MCE: add sanity check and comments for vmce injection
> 
> Add sanity check for input vcpu so that malicious value would not return 0.
> Add comments since vcpu<0 (broadcast) is some implicit to code reader.


Yeah, a like #define VMCE_INJECT_BROADCAST is also helpful.

> 
> Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>
> 
> diff -r adc7f057011e xen/arch/x86/cpu/mcheck/vmce.c
> --- a/xen/arch/x86/cpu/mcheck/vmce.c	Thu Sep 27 19:52:13 2012 +0800
> +++ b/xen/arch/x86/cpu/mcheck/vmce.c	Thu Sep 27 20:56:52 2012 +0800
> @@ -341,10 +341,16 @@
>  /*
>   * for Intel MCE, broadcast vMCE to all vcpus
>   * for AMD MCE, only inject vMCE to vcpu0
> + *
> + * @ d, domain to which would inject vmce
> + * @ vcpu,
> + *   < 0, broadcast vMCE to all vcpus
> + *   >= 0, vcpu who would be injected vMCE


Better wording:
 >= 0, vcpu, the vMCE is injected to

Christoph

>   */
>  int inject_vmce(struct domain *d, int vcpu)
>  {
>      struct vcpu *v;
> +    int ret = -EINVAL;
>  
>      for_each_vcpu ( d, v )
>      {
> @@ -358,19 +364,21 @@
>              mce_printk(MCE_VERBOSE, "MCE: inject vMCE to d%d:v%d\n",
>                         d->domain_id, v->vcpu_id);
>              vcpu_kick(v);
> +            ret = 0;
>          }
>          else
>          {
>              mce_printk(MCE_QUIET, "Failed to inject vMCE to d%d:v%d\n",
>                         d->domain_id, v->vcpu_id);
> -            return -EBUSY;
> +            ret = -EBUSY;
> +            break;
>          }
>  
>          if ( vcpu >= 0 )
> -            return 0;
> +            break;
>      }
>  
> -    return v ? -ESRCH : 0;
> +    return ret;
>  }
>  
>  int fill_vmsr_data(struct mcinfo_bank *mc_bank, struct domain *d,



-- 
---to satisfy European Law for business letters:
Advanced Micro Devices GmbH
Einsteinring 24, 85689 Dornach b. Muenchen
Geschaeftsfuehrer: Alberto Bozzo
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 Thu Sep 27 08:55:00 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Sep 2012 08:55:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TH9rh-0008Sf-KV; Thu, 27 Sep 2012 08:54:37 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Christoph.Egger@amd.com>) id 1TH9rf-0008Sa-Lq
	for xen-devel@lists.xensource.com; Thu, 27 Sep 2012 08:54:35 +0000
Received: from [85.158.143.99:7283] by server-3.bemta-4.messagelabs.com id
	B0/30-10986-A4414605; Thu, 27 Sep 2012 08:54:34 +0000
X-Env-Sender: Christoph.Egger@amd.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1348736071!31619425!1
X-Originating-IP: [216.32.180.188]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14942 invoked from network); 27 Sep 2012 08:54:33 -0000
Received: from co1ehsobe005.messaging.microsoft.com (HELO
	co1outboundpool.messaging.microsoft.com) (216.32.180.188)
	by server-5.tower-216.messagelabs.com with AES128-SHA encrypted SMTP;
	27 Sep 2012 08:54:33 -0000
Received: from mail31-co1-R.bigfish.com (10.243.78.237) by
	CO1EHSOBE013.bigfish.com (10.243.66.76) with Microsoft SMTP Server id
	14.1.225.23; Thu, 27 Sep 2012 08:54:31 +0000
Received: from mail31-co1 (localhost [127.0.0.1])	by mail31-co1-R.bigfish.com
	(Postfix) with ESMTP id 10515D000FA;
	Thu, 27 Sep 2012 08:54:31 +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: -6
X-BigFish: VPS-6(zzbb2dI98dI103dK1432Izz1202h1d1ah1d2ahzz8275bhz2dh668h839hd25he5bhf0ah107ah1288h12a5h12a9h12bdh137ah13b6h1155h)
Received: from mail31-co1 (localhost.localdomain [127.0.0.1]) by mail31-co1
	(MessageSwitch) id 1348736068677285_21949;
	Thu, 27 Sep 2012 08:54:28 +0000 (UTC)
Received: from CO1EHSMHS001.bigfish.com (unknown [10.243.78.243])	by
	mail31-co1.bigfish.com (Postfix) with ESMTP id 97451C80019;
	Thu, 27 Sep 2012 08:54:28 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	CO1EHSMHS001.bigfish.com (10.243.66.11) with Microsoft SMTP Server id
	14.1.225.23; Thu, 27 Sep 2012 08:54:26 +0000
X-WSS-ID: 0MB03EO-01-IQ8-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 291791028036;	Thu, 27 Sep 2012 03:54:23 -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;
	Thu, 27 Sep 2012 03:54:39 -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;
	Thu, 27 Sep 2012 03:54:23 -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, 27 Sep 2012
	04:54:22 -0400
Message-ID: <5064143A.6070203@amd.com>
Date: Thu, 27 Sep 2012 10:54: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: "Liu, Jinsong" <jinsong.liu@intel.com>
References: <DE8DF0795D48FD4CA783C40EC8292335339547@SHSMSX101.ccr.corp.intel.com>
	<506173FB.8070603@amd.com>
	<5061A833020000780009DA1A@nat28.tlf.novell.com>
	<50619B61.2030609@amd.com>
	<DE8DF0795D48FD4CA783C40EC829233533AA6E@SHSMSX101.ccr.corp.intel.com>
	<5062CC25020000780009DE44@nat28.tlf.novell.com>
	<DE8DF0795D48FD4CA783C40EC829233533C01C@SHSMSX101.ccr.corp.intel.com>
In-Reply-To: <DE8DF0795D48FD4CA783C40EC829233533C01C@SHSMSX101.ccr.corp.intel.com>
X-OriginatorOrg: amd.com
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"keir@xen.org" <keir@xen.org>,
	"Ian.Campbell@citrix.com" <Ian.Campbell@citrix.com>,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH 6] X86/MCE: update vMCE injection for AMD
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 09/27/12 07:22, Liu, Jinsong wrote:

> Jan Beulich wrote:
>>>>> On 26.09.12 at 05:11, "Liu, Jinsong" <jinsong.liu@intel.com> wrote:
>>> I fold patch 6 to patch 2, will send out later.
>>
>> As I had indicated, I had done this already in preparation of things
>> getting committed, so you will want to check once in staging
>> (hopefully later today).
>>
>> Jan
> 
> Got it, thanks! It's OK to me, but how about add sanity check and some comments like
> 
> ==================
> Xen/MCE: add sanity check and comments for vmce injection
> 
> Add sanity check for input vcpu so that malicious value would not return 0.
> Add comments since vcpu<0 (broadcast) is some implicit to code reader.


Yeah, a like #define VMCE_INJECT_BROADCAST is also helpful.

> 
> Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>
> 
> diff -r adc7f057011e xen/arch/x86/cpu/mcheck/vmce.c
> --- a/xen/arch/x86/cpu/mcheck/vmce.c	Thu Sep 27 19:52:13 2012 +0800
> +++ b/xen/arch/x86/cpu/mcheck/vmce.c	Thu Sep 27 20:56:52 2012 +0800
> @@ -341,10 +341,16 @@
>  /*
>   * for Intel MCE, broadcast vMCE to all vcpus
>   * for AMD MCE, only inject vMCE to vcpu0
> + *
> + * @ d, domain to which would inject vmce
> + * @ vcpu,
> + *   < 0, broadcast vMCE to all vcpus
> + *   >= 0, vcpu who would be injected vMCE


Better wording:
 >= 0, vcpu, the vMCE is injected to

Christoph

>   */
>  int inject_vmce(struct domain *d, int vcpu)
>  {
>      struct vcpu *v;
> +    int ret = -EINVAL;
>  
>      for_each_vcpu ( d, v )
>      {
> @@ -358,19 +364,21 @@
>              mce_printk(MCE_VERBOSE, "MCE: inject vMCE to d%d:v%d\n",
>                         d->domain_id, v->vcpu_id);
>              vcpu_kick(v);
> +            ret = 0;
>          }
>          else
>          {
>              mce_printk(MCE_QUIET, "Failed to inject vMCE to d%d:v%d\n",
>                         d->domain_id, v->vcpu_id);
> -            return -EBUSY;
> +            ret = -EBUSY;
> +            break;
>          }
>  
>          if ( vcpu >= 0 )
> -            return 0;
> +            break;
>      }
>  
> -    return v ? -ESRCH : 0;
> +    return ret;
>  }
>  
>  int fill_vmsr_data(struct mcinfo_bank *mc_bank, struct domain *d,



-- 
---to satisfy European Law for business letters:
Advanced Micro Devices GmbH
Einsteinring 24, 85689 Dornach b. Muenchen
Geschaeftsfuehrer: Alberto Bozzo
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 Thu Sep 27 09:38:32 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Sep 2012 09: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 1THAXj-0000SP-Rw; Thu, 27 Sep 2012 09:38:03 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jean.guyader@gmail.com>) id 1THAXi-0000SK-Rt
	for xen-devel@lists.xen.org; Thu, 27 Sep 2012 09:38:03 +0000
Received: from [85.158.137.99:59145] by server-11.bemta-3.messagelabs.com id
	4E/A4-21460-A7E14605; Thu, 27 Sep 2012 09:38:02 +0000
X-Env-Sender: jean.guyader@gmail.com
X-Msg-Ref: server-2.tower-217.messagelabs.com!1348738680!19208760!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-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29159 invoked from network); 27 Sep 2012 09:38:01 -0000
Received: from mail-vc0-f173.google.com (HELO mail-vc0-f173.google.com)
	(209.85.220.173)
	by server-2.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Sep 2012 09:38:01 -0000
Received: by vcbfl15 with SMTP id fl15so2250914vcb.32
	for <xen-devel@lists.xen.org>; Thu, 27 Sep 2012 02:38:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to
	:cc:content-type;
	bh=YL2ClnnshJQWfidGG5JdgRsBM7FZpGQlSdus5n7sWc0=;
	b=hENURmeGt/qBlQaTKRrd9D96xsEw8bFa6eNyfWG0kg8sbvlXd3lrLdDlPeVZKac2ex
	c4aVS09MNvYks8cKHChOu0+y1J4LZSD7lKSGgRNRR1N2RqWB1gjT6KXZhd1oqsmJ6hBD
	lvkpGomJ9j/ivVsv6wdSaoTL7x6q+x9GmAngHEFK2s+EnQoOyepNNOQ68q5HRPPEkinl
	7QnWo7ItaZg4DhDdu3aWvXlOwamloLznZyqUHtPyRRMUw/K/TTV5uufo0ylumejvvEzD
	kyIsnrc0lrNtB8JqK252Sm/P5qSMbIuz0jVHpnTSKhUmiqwg6pXFde2RrfDD903HEjoq
	Ombw==
Received: by 10.220.8.138 with SMTP id h10mr1904276vch.35.1348738679795; Thu,
	27 Sep 2012 02:37:59 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.58.234.5 with HTTP; Thu, 27 Sep 2012 02:37:39 -0700 (PDT)
In-Reply-To: <505DC16E.6050303@gmail.com>
References: <1348141322-28657-1-git-send-email-jean.guyader@citrix.com>
	<1348141322-28657-5-git-send-email-jean.guyader@citrix.com>
	<505DC16E.6050303@gmail.com>
From: Jean Guyader <jean.guyader@gmail.com>
Date: Thu, 27 Sep 2012 10:37:39 +0100
Message-ID: <CAEBdQ903u9wUpxJVVk6xwANBbxVp-CMW1YwF-0ftDe3S0d=srA@mail.gmail.com>
To: Julian Pidancet <julian.pidancet@gmail.com>
Cc: tim@xen.org, JBeulich@suse.com, Jean Guyader <jean.guyader@citrix.com>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 4/4] 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 22 September 2012 14:47, Julian Pidancet <julian.pidancet@gmail.com> wrote:
> On 09/20/12 12:42, Jean Guyader wrote:
>>
>> 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.
>>
>
> Could we rename "viptables" in "v4vtables", or something that doesn't
> contain "IP" in the name ? Since IP is a totally unrelated protocol, it
> doesn't make sense here.
>

Ok sure, I don't have any objections to 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 Sep 27 09:38:32 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Sep 2012 09: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 1THAXj-0000SP-Rw; Thu, 27 Sep 2012 09:38:03 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jean.guyader@gmail.com>) id 1THAXi-0000SK-Rt
	for xen-devel@lists.xen.org; Thu, 27 Sep 2012 09:38:03 +0000
Received: from [85.158.137.99:59145] by server-11.bemta-3.messagelabs.com id
	4E/A4-21460-A7E14605; Thu, 27 Sep 2012 09:38:02 +0000
X-Env-Sender: jean.guyader@gmail.com
X-Msg-Ref: server-2.tower-217.messagelabs.com!1348738680!19208760!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-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29159 invoked from network); 27 Sep 2012 09:38:01 -0000
Received: from mail-vc0-f173.google.com (HELO mail-vc0-f173.google.com)
	(209.85.220.173)
	by server-2.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Sep 2012 09:38:01 -0000
Received: by vcbfl15 with SMTP id fl15so2250914vcb.32
	for <xen-devel@lists.xen.org>; Thu, 27 Sep 2012 02:38:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to
	:cc:content-type;
	bh=YL2ClnnshJQWfidGG5JdgRsBM7FZpGQlSdus5n7sWc0=;
	b=hENURmeGt/qBlQaTKRrd9D96xsEw8bFa6eNyfWG0kg8sbvlXd3lrLdDlPeVZKac2ex
	c4aVS09MNvYks8cKHChOu0+y1J4LZSD7lKSGgRNRR1N2RqWB1gjT6KXZhd1oqsmJ6hBD
	lvkpGomJ9j/ivVsv6wdSaoTL7x6q+x9GmAngHEFK2s+EnQoOyepNNOQ68q5HRPPEkinl
	7QnWo7ItaZg4DhDdu3aWvXlOwamloLznZyqUHtPyRRMUw/K/TTV5uufo0ylumejvvEzD
	kyIsnrc0lrNtB8JqK252Sm/P5qSMbIuz0jVHpnTSKhUmiqwg6pXFde2RrfDD903HEjoq
	Ombw==
Received: by 10.220.8.138 with SMTP id h10mr1904276vch.35.1348738679795; Thu,
	27 Sep 2012 02:37:59 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.58.234.5 with HTTP; Thu, 27 Sep 2012 02:37:39 -0700 (PDT)
In-Reply-To: <505DC16E.6050303@gmail.com>
References: <1348141322-28657-1-git-send-email-jean.guyader@citrix.com>
	<1348141322-28657-5-git-send-email-jean.guyader@citrix.com>
	<505DC16E.6050303@gmail.com>
From: Jean Guyader <jean.guyader@gmail.com>
Date: Thu, 27 Sep 2012 10:37:39 +0100
Message-ID: <CAEBdQ903u9wUpxJVVk6xwANBbxVp-CMW1YwF-0ftDe3S0d=srA@mail.gmail.com>
To: Julian Pidancet <julian.pidancet@gmail.com>
Cc: tim@xen.org, JBeulich@suse.com, Jean Guyader <jean.guyader@citrix.com>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 4/4] 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 22 September 2012 14:47, Julian Pidancet <julian.pidancet@gmail.com> wrote:
> On 09/20/12 12:42, Jean Guyader wrote:
>>
>> 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.
>>
>
> Could we rename "viptables" in "v4vtables", or something that doesn't
> contain "IP" in the name ? Since IP is a totally unrelated protocol, it
> doesn't make sense here.
>

Ok sure, I don't have any objections to 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 Sep 27 09:46:22 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Sep 2012 09: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 1THAfN-0000bv-PO; Thu, 27 Sep 2012 09:45:57 +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 1THAfL-0000bq-SV
	for xen-devel@lists.xensource.com; Thu, 27 Sep 2012 09:45:56 +0000
Received: from [85.158.138.51:31851] by server-5.bemta-3.messagelabs.com id
	B5/6F-00589-25024605; Thu, 27 Sep 2012 09:45:54 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1348739153!23289754!1
X-Originating-IP: [134.134.136.20]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjAgPT4gMzA0ODAz\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7005 invoked from network); 27 Sep 2012 09:45:53 -0000
Received: from mga02.intel.com (HELO mga02.intel.com) (134.134.136.20)
	by server-7.tower-174.messagelabs.com with SMTP;
	27 Sep 2012 09:45:53 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga101.jf.intel.com with ESMTP; 27 Sep 2012 02:45:52 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.80,494,1344236400"; d="scan'208";a="214247762"
Received: from fmsmsx107.amr.corp.intel.com ([10.19.9.54])
	by orsmga002.jf.intel.com with ESMTP; 27 Sep 2012 02:45:37 -0700
Received: from fmsmsx151.amr.corp.intel.com (10.19.17.220) by
	FMSMSX107.amr.corp.intel.com (10.19.9.54) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Thu, 27 Sep 2012 02:45:32 -0700
Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by
	FMSMSX151.amr.corp.intel.com (10.19.17.220) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Thu, 27 Sep 2012 02:45:32 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.239]) by
	SHSMSX102.ccr.corp.intel.com ([169.254.2.92]) with mapi id
	14.01.0355.002; Thu, 27 Sep 2012 17:45:14 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: Christoph Egger <Christoph.Egger@amd.com>
Thread-Topic: [PATCH 6] X86/MCE: update vMCE injection for AMD
Thread-Index: AQHNnI2tbAubMQI3SAyq+zkwzNAc0ped76xw
Date: Thu, 27 Sep 2012 09:45:14 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC829233533C32B@SHSMSX101.ccr.corp.intel.com>
References: <DE8DF0795D48FD4CA783C40EC8292335339547@SHSMSX101.ccr.corp.intel.com>
	<506173FB.8070603@amd.com>
	<5061A833020000780009DA1A@nat28.tlf.novell.com>
	<50619B61.2030609@amd.com>
	<DE8DF0795D48FD4CA783C40EC829233533AA6E@SHSMSX101.ccr.corp.intel.com>
	<5062CC25020000780009DE44@nat28.tlf.novell.com>
	<DE8DF0795D48FD4CA783C40EC829233533C01C@SHSMSX101.ccr.corp.intel.com>
	<5064143A.6070203@amd.com>
In-Reply-To: <5064143A.6070203@amd.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_DE8DF0795D48FD4CA783C40EC829233533C32BSHSMSX101ccrcorpi_"
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"keir@xen.org" <keir@xen.org>,
	"Ian.Campbell@citrix.com" <Ian.Campbell@citrix.com>,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH 6] X86/MCE: update vMCE injection for AMD
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--_002_DE8DF0795D48FD4CA783C40EC829233533C32BSHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

>>=20
>> Got it, thanks! It's OK to me, but how about add sanity check and
>> some comments like=20
>>=20
>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>> Xen/MCE: add sanity check and comments for vmce injection
>>=20
>> Add sanity check for input vcpu so that malicious value would not
>> return 0.=20
>> Add comments since vcpu<0 (broadcast) is some implicit to code
>> reader.=20
>=20
>=20
> Yeah, a like #define VMCE_INJECT_BROADCAST is also helpful.
>=20
>>=20
>> Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>
>>=20
>> diff -r adc7f057011e xen/arch/x86/cpu/mcheck/vmce.c
>> --- a/xen/arch/x86/cpu/mcheck/vmce.c	Thu Sep 27 19:52:13 2012 +0800
>> +++ b/xen/arch/x86/cpu/mcheck/vmce.c	Thu Sep 27 20:56:52 2012 +0800
>>  @@ -341,10 +341,16 @@ /*
>>   * for Intel MCE, broadcast vMCE to all vcpus
>>   * for AMD MCE, only inject vMCE to vcpu0
>> + *
>> + * @ d, domain to which would inject vmce
>> + * @ vcpu,
>> + *   < 0, broadcast vMCE to all vcpus
>> + *   >=3D 0, vcpu who would be injected vMCE
>=20
>=20
> Better wording:
>  >=3D 0, vcpu, the vMCE is injected to
>=20
> Christoph
>=20

Fine to me, updated accordingly.

Thanks,
Jinsong

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Xen/MCE: add sanity check and comments for vmce injection

Add sanity check for input vcpu so that malicious value would not return 0.
Add comments since vcpu=3D-1 (broadcast) is some implicit to code reader.

Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>
Suggested_by: Christoph Egger <Christoph.Egger@amd.com>

diff -r adc7f057011e xen/arch/x86/cpu/mcheck/mce_intel.c
--- a/xen/arch/x86/cpu/mcheck/mce_intel.c	Thu Sep 27 19:52:13 2012 +0800
+++ b/xen/arch/x86/cpu/mcheck/mce_intel.c	Fri Sep 28 01:25:19 2012 +0800
@@ -360,7 +360,7 @@
                 }
=20
                 /* We will inject vMCE to DOMU*/
-                if ( inject_vmce(d, -1) < 0 )
+                if ( inject_vmce(d, VMCE_INJECT_BROADCAST) < 0 )
                 {
                     mce_printk(MCE_QUIET, "inject vMCE to DOM%d"
                       " failed\n", d->domain_id);
diff -r adc7f057011e xen/arch/x86/cpu/mcheck/vmce.c
--- a/xen/arch/x86/cpu/mcheck/vmce.c	Thu Sep 27 19:52:13 2012 +0800
+++ b/xen/arch/x86/cpu/mcheck/vmce.c	Fri Sep 28 01:25:19 2012 +0800
@@ -341,14 +341,20 @@
 /*
  * for Intel MCE, broadcast vMCE to all vcpus
  * for AMD MCE, only inject vMCE to vcpu0
+ *
+ * @ d, domain to which would inject vmce
+ * @ vcpu,
+ *   -1 (VMCE_INJECT_BROADCAST), broadcast vMCE to all vcpus
+ *   >=3D 0, vcpu, the vMCE is injected to
  */
 int inject_vmce(struct domain *d, int vcpu)
 {
     struct vcpu *v;
+    int ret =3D -EINVAL;
=20
     for_each_vcpu ( d, v )
     {
-        if ( vcpu >=3D 0 && v->vcpu_id !=3D vcpu )
+        if ( vcpu !=3D VMCE_INJECT_BROADCAST && vcpu !=3D v->vcpu_id )
             continue;
=20
         if ( (is_hvm_domain(d) ||
@@ -358,19 +364,21 @@
             mce_printk(MCE_VERBOSE, "MCE: inject vMCE to d%d:v%d\n",
                        d->domain_id, v->vcpu_id);
             vcpu_kick(v);
+            ret =3D 0;
         }
         else
         {
             mce_printk(MCE_QUIET, "Failed to inject vMCE to d%d:v%d\n",
                        d->domain_id, v->vcpu_id);
-            return -EBUSY;
+            ret =3D -EBUSY;
+            break;
         }
=20
         if ( vcpu >=3D 0 )
-            return 0;
+            break;
     }
=20
-    return v ? -ESRCH : 0;
+    return ret;
 }
=20
 int fill_vmsr_data(struct mcinfo_bank *mc_bank, struct domain *d,
diff -r adc7f057011e xen/arch/x86/cpu/mcheck/vmce.h
--- a/xen/arch/x86/cpu/mcheck/vmce.h	Thu Sep 27 19:52:13 2012 +0800
+++ b/xen/arch/x86/cpu/mcheck/vmce.h	Fri Sep 28 01:25:19 2012 +0800
@@ -18,6 +18,8 @@
=20
 int fill_vmsr_data(struct mcinfo_bank *mc_bank, struct domain *d,
     uint64_t gstatus);
+
+#define VMCE_INJECT_BROADCAST -1
 int inject_vmce(struct domain *d, int vcpu);
=20
 #endif

--_002_DE8DF0795D48FD4CA783C40EC829233533C32BSHSMSX101ccrcorpi_
Content-Type: application/octet-stream; name="vmce_injection_update.patch"
Content-Description: vmce_injection_update.patch
Content-Disposition: attachment; filename="vmce_injection_update.patch";
	size=2664; creation-date="Thu, 27 Sep 2012 09:42:02 GMT";
	modification-date="Thu, 27 Sep 2012 17:33:42 GMT"
Content-Transfer-Encoding: base64

WGVuL01DRTogYWRkIHNhbml0eSBjaGVjayBhbmQgY29tbWVudHMgZm9yIHZtY2UgaW5qZWN0aW9u
CgpBZGQgc2FuaXR5IGNoZWNrIGZvciBpbnB1dCB2Y3B1IHNvIHRoYXQgbWFsaWNpb3VzIHZhbHVl
IHdvdWxkIG5vdCByZXR1cm4gMC4KQWRkIGNvbW1lbnRzIHNpbmNlIHZjcHU9LTEgKGJyb2FkY2Fz
dCkgaXMgc29tZSBpbXBsaWNpdCB0byBjb2RlIHJlYWRlci4KClNpZ25lZC1vZmYtYnk6IExpdSwg
Smluc29uZyA8amluc29uZy5saXVAaW50ZWwuY29tPgpTdWdnZXN0ZWRfYnk6IENocmlzdG9waCBF
Z2dlciA8Q2hyaXN0b3BoLkVnZ2VyQGFtZC5jb20+CgpkaWZmIC1yIGFkYzdmMDU3MDExZSB4ZW4v
YXJjaC94ODYvY3B1L21jaGVjay9tY2VfaW50ZWwuYwotLS0gYS94ZW4vYXJjaC94ODYvY3B1L21j
aGVjay9tY2VfaW50ZWwuYwlUaHUgU2VwIDI3IDE5OjUyOjEzIDIwMTIgKzA4MDAKKysrIGIveGVu
L2FyY2gveDg2L2NwdS9tY2hlY2svbWNlX2ludGVsLmMJRnJpIFNlcCAyOCAwMToyNToxOSAyMDEy
ICswODAwCkBAIC0zNjAsNyArMzYwLDcgQEAKICAgICAgICAgICAgICAgICB9CiAKICAgICAgICAg
ICAgICAgICAvKiBXZSB3aWxsIGluamVjdCB2TUNFIHRvIERPTVUqLwotICAgICAgICAgICAgICAg
IGlmICggaW5qZWN0X3ZtY2UoZCwgLTEpIDwgMCApCisgICAgICAgICAgICAgICAgaWYgKCBpbmpl
Y3Rfdm1jZShkLCBWTUNFX0lOSkVDVF9CUk9BRENBU1QpIDwgMCApCiAgICAgICAgICAgICAgICAg
ewogICAgICAgICAgICAgICAgICAgICBtY2VfcHJpbnRrKE1DRV9RVUlFVCwgImluamVjdCB2TUNF
IHRvIERPTSVkIgogICAgICAgICAgICAgICAgICAgICAgICIgZmFpbGVkXG4iLCBkLT5kb21haW5f
aWQpOwpkaWZmIC1yIGFkYzdmMDU3MDExZSB4ZW4vYXJjaC94ODYvY3B1L21jaGVjay92bWNlLmMK
LS0tIGEveGVuL2FyY2gveDg2L2NwdS9tY2hlY2svdm1jZS5jCVRodSBTZXAgMjcgMTk6NTI6MTMg
MjAxMiArMDgwMAorKysgYi94ZW4vYXJjaC94ODYvY3B1L21jaGVjay92bWNlLmMJRnJpIFNlcCAy
OCAwMToyNToxOSAyMDEyICswODAwCkBAIC0zNDEsMTQgKzM0MSwyMCBAQAogLyoKICAqIGZvciBJ
bnRlbCBNQ0UsIGJyb2FkY2FzdCB2TUNFIHRvIGFsbCB2Y3B1cwogICogZm9yIEFNRCBNQ0UsIG9u
bHkgaW5qZWN0IHZNQ0UgdG8gdmNwdTAKKyAqCisgKiBAIGQsIGRvbWFpbiB0byB3aGljaCB3b3Vs
ZCBpbmplY3Qgdm1jZQorICogQCB2Y3B1LAorICogICAtMSAoVk1DRV9JTkpFQ1RfQlJPQURDQVNU
KSwgYnJvYWRjYXN0IHZNQ0UgdG8gYWxsIHZjcHVzCisgKiAgID49IDAsIHZjcHUsIHRoZSB2TUNF
IGlzIGluamVjdGVkIHRvCiAgKi8KIGludCBpbmplY3Rfdm1jZShzdHJ1Y3QgZG9tYWluICpkLCBp
bnQgdmNwdSkKIHsKICAgICBzdHJ1Y3QgdmNwdSAqdjsKKyAgICBpbnQgcmV0ID0gLUVJTlZBTDsK
IAogICAgIGZvcl9lYWNoX3ZjcHUgKCBkLCB2ICkKICAgICB7Ci0gICAgICAgIGlmICggdmNwdSA+
PSAwICYmIHYtPnZjcHVfaWQgIT0gdmNwdSApCisgICAgICAgIGlmICggdmNwdSAhPSBWTUNFX0lO
SkVDVF9CUk9BRENBU1QgJiYgdmNwdSAhPSB2LT52Y3B1X2lkICkKICAgICAgICAgICAgIGNvbnRp
bnVlOwogCiAgICAgICAgIGlmICggKGlzX2h2bV9kb21haW4oZCkgfHwKQEAgLTM1OCwxOSArMzY0
LDIxIEBACiAgICAgICAgICAgICBtY2VfcHJpbnRrKE1DRV9WRVJCT1NFLCAiTUNFOiBpbmplY3Qg
dk1DRSB0byBkJWQ6diVkXG4iLAogICAgICAgICAgICAgICAgICAgICAgICBkLT5kb21haW5faWQs
IHYtPnZjcHVfaWQpOwogICAgICAgICAgICAgdmNwdV9raWNrKHYpOworICAgICAgICAgICAgcmV0
ID0gMDsKICAgICAgICAgfQogICAgICAgICBlbHNlCiAgICAgICAgIHsKICAgICAgICAgICAgIG1j
ZV9wcmludGsoTUNFX1FVSUVULCAiRmFpbGVkIHRvIGluamVjdCB2TUNFIHRvIGQlZDp2JWRcbiIs
CiAgICAgICAgICAgICAgICAgICAgICAgIGQtPmRvbWFpbl9pZCwgdi0+dmNwdV9pZCk7Ci0gICAg
ICAgICAgICByZXR1cm4gLUVCVVNZOworICAgICAgICAgICAgcmV0ID0gLUVCVVNZOworICAgICAg
ICAgICAgYnJlYWs7CiAgICAgICAgIH0KIAogICAgICAgICBpZiAoIHZjcHUgPj0gMCApCi0gICAg
ICAgICAgICByZXR1cm4gMDsKKyAgICAgICAgICAgIGJyZWFrOwogICAgIH0KIAotICAgIHJldHVy
biB2ID8gLUVTUkNIIDogMDsKKyAgICByZXR1cm4gcmV0OwogfQogCiBpbnQgZmlsbF92bXNyX2Rh
dGEoc3RydWN0IG1jaW5mb19iYW5rICptY19iYW5rLCBzdHJ1Y3QgZG9tYWluICpkLApkaWZmIC1y
IGFkYzdmMDU3MDExZSB4ZW4vYXJjaC94ODYvY3B1L21jaGVjay92bWNlLmgKLS0tIGEveGVuL2Fy
Y2gveDg2L2NwdS9tY2hlY2svdm1jZS5oCVRodSBTZXAgMjcgMTk6NTI6MTMgMjAxMiArMDgwMAor
KysgYi94ZW4vYXJjaC94ODYvY3B1L21jaGVjay92bWNlLmgJRnJpIFNlcCAyOCAwMToyNToxOSAy
MDEyICswODAwCkBAIC0xOCw2ICsxOCw4IEBACiAKIGludCBmaWxsX3Ztc3JfZGF0YShzdHJ1Y3Qg
bWNpbmZvX2JhbmsgKm1jX2JhbmssIHN0cnVjdCBkb21haW4gKmQsCiAgICAgdWludDY0X3QgZ3N0
YXR1cyk7CisKKyNkZWZpbmUgVk1DRV9JTkpFQ1RfQlJPQURDQVNUIC0xCiBpbnQgaW5qZWN0X3Zt
Y2Uoc3RydWN0IGRvbWFpbiAqZCwgaW50IHZjcHUpOwogCiAjZW5kaWYK

--_002_DE8DF0795D48FD4CA783C40EC829233533C32BSHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 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_DE8DF0795D48FD4CA783C40EC829233533C32BSHSMSX101ccrcorpi_--


From xen-devel-bounces@lists.xen.org Thu Sep 27 09:46:22 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Sep 2012 09: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 1THAfN-0000bv-PO; Thu, 27 Sep 2012 09:45:57 +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 1THAfL-0000bq-SV
	for xen-devel@lists.xensource.com; Thu, 27 Sep 2012 09:45:56 +0000
Received: from [85.158.138.51:31851] by server-5.bemta-3.messagelabs.com id
	B5/6F-00589-25024605; Thu, 27 Sep 2012 09:45:54 +0000
X-Env-Sender: jinsong.liu@intel.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1348739153!23289754!1
X-Originating-IP: [134.134.136.20]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjAgPT4gMzA0ODAz\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7005 invoked from network); 27 Sep 2012 09:45:53 -0000
Received: from mga02.intel.com (HELO mga02.intel.com) (134.134.136.20)
	by server-7.tower-174.messagelabs.com with SMTP;
	27 Sep 2012 09:45:53 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga101.jf.intel.com with ESMTP; 27 Sep 2012 02:45:52 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.80,494,1344236400"; d="scan'208";a="214247762"
Received: from fmsmsx107.amr.corp.intel.com ([10.19.9.54])
	by orsmga002.jf.intel.com with ESMTP; 27 Sep 2012 02:45:37 -0700
Received: from fmsmsx151.amr.corp.intel.com (10.19.17.220) by
	FMSMSX107.amr.corp.intel.com (10.19.9.54) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Thu, 27 Sep 2012 02:45:32 -0700
Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by
	FMSMSX151.amr.corp.intel.com (10.19.17.220) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Thu, 27 Sep 2012 02:45:32 -0700
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.239]) by
	SHSMSX102.ccr.corp.intel.com ([169.254.2.92]) with mapi id
	14.01.0355.002; Thu, 27 Sep 2012 17:45:14 +0800
From: "Liu, Jinsong" <jinsong.liu@intel.com>
To: Christoph Egger <Christoph.Egger@amd.com>
Thread-Topic: [PATCH 6] X86/MCE: update vMCE injection for AMD
Thread-Index: AQHNnI2tbAubMQI3SAyq+zkwzNAc0ped76xw
Date: Thu, 27 Sep 2012 09:45:14 +0000
Message-ID: <DE8DF0795D48FD4CA783C40EC829233533C32B@SHSMSX101.ccr.corp.intel.com>
References: <DE8DF0795D48FD4CA783C40EC8292335339547@SHSMSX101.ccr.corp.intel.com>
	<506173FB.8070603@amd.com>
	<5061A833020000780009DA1A@nat28.tlf.novell.com>
	<50619B61.2030609@amd.com>
	<DE8DF0795D48FD4CA783C40EC829233533AA6E@SHSMSX101.ccr.corp.intel.com>
	<5062CC25020000780009DE44@nat28.tlf.novell.com>
	<DE8DF0795D48FD4CA783C40EC829233533C01C@SHSMSX101.ccr.corp.intel.com>
	<5064143A.6070203@amd.com>
In-Reply-To: <5064143A.6070203@amd.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_DE8DF0795D48FD4CA783C40EC829233533C32BSHSMSX101ccrcorpi_"
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"keir@xen.org" <keir@xen.org>,
	"Ian.Campbell@citrix.com" <Ian.Campbell@citrix.com>,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH 6] X86/MCE: update vMCE injection for AMD
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--_002_DE8DF0795D48FD4CA783C40EC829233533C32BSHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

>>=20
>> Got it, thanks! It's OK to me, but how about add sanity check and
>> some comments like=20
>>=20
>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>> Xen/MCE: add sanity check and comments for vmce injection
>>=20
>> Add sanity check for input vcpu so that malicious value would not
>> return 0.=20
>> Add comments since vcpu<0 (broadcast) is some implicit to code
>> reader.=20
>=20
>=20
> Yeah, a like #define VMCE_INJECT_BROADCAST is also helpful.
>=20
>>=20
>> Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>
>>=20
>> diff -r adc7f057011e xen/arch/x86/cpu/mcheck/vmce.c
>> --- a/xen/arch/x86/cpu/mcheck/vmce.c	Thu Sep 27 19:52:13 2012 +0800
>> +++ b/xen/arch/x86/cpu/mcheck/vmce.c	Thu Sep 27 20:56:52 2012 +0800
>>  @@ -341,10 +341,16 @@ /*
>>   * for Intel MCE, broadcast vMCE to all vcpus
>>   * for AMD MCE, only inject vMCE to vcpu0
>> + *
>> + * @ d, domain to which would inject vmce
>> + * @ vcpu,
>> + *   < 0, broadcast vMCE to all vcpus
>> + *   >=3D 0, vcpu who would be injected vMCE
>=20
>=20
> Better wording:
>  >=3D 0, vcpu, the vMCE is injected to
>=20
> Christoph
>=20

Fine to me, updated accordingly.

Thanks,
Jinsong

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Xen/MCE: add sanity check and comments for vmce injection

Add sanity check for input vcpu so that malicious value would not return 0.
Add comments since vcpu=3D-1 (broadcast) is some implicit to code reader.

Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>
Suggested_by: Christoph Egger <Christoph.Egger@amd.com>

diff -r adc7f057011e xen/arch/x86/cpu/mcheck/mce_intel.c
--- a/xen/arch/x86/cpu/mcheck/mce_intel.c	Thu Sep 27 19:52:13 2012 +0800
+++ b/xen/arch/x86/cpu/mcheck/mce_intel.c	Fri Sep 28 01:25:19 2012 +0800
@@ -360,7 +360,7 @@
                 }
=20
                 /* We will inject vMCE to DOMU*/
-                if ( inject_vmce(d, -1) < 0 )
+                if ( inject_vmce(d, VMCE_INJECT_BROADCAST) < 0 )
                 {
                     mce_printk(MCE_QUIET, "inject vMCE to DOM%d"
                       " failed\n", d->domain_id);
diff -r adc7f057011e xen/arch/x86/cpu/mcheck/vmce.c
--- a/xen/arch/x86/cpu/mcheck/vmce.c	Thu Sep 27 19:52:13 2012 +0800
+++ b/xen/arch/x86/cpu/mcheck/vmce.c	Fri Sep 28 01:25:19 2012 +0800
@@ -341,14 +341,20 @@
 /*
  * for Intel MCE, broadcast vMCE to all vcpus
  * for AMD MCE, only inject vMCE to vcpu0
+ *
+ * @ d, domain to which would inject vmce
+ * @ vcpu,
+ *   -1 (VMCE_INJECT_BROADCAST), broadcast vMCE to all vcpus
+ *   >=3D 0, vcpu, the vMCE is injected to
  */
 int inject_vmce(struct domain *d, int vcpu)
 {
     struct vcpu *v;
+    int ret =3D -EINVAL;
=20
     for_each_vcpu ( d, v )
     {
-        if ( vcpu >=3D 0 && v->vcpu_id !=3D vcpu )
+        if ( vcpu !=3D VMCE_INJECT_BROADCAST && vcpu !=3D v->vcpu_id )
             continue;
=20
         if ( (is_hvm_domain(d) ||
@@ -358,19 +364,21 @@
             mce_printk(MCE_VERBOSE, "MCE: inject vMCE to d%d:v%d\n",
                        d->domain_id, v->vcpu_id);
             vcpu_kick(v);
+            ret =3D 0;
         }
         else
         {
             mce_printk(MCE_QUIET, "Failed to inject vMCE to d%d:v%d\n",
                        d->domain_id, v->vcpu_id);
-            return -EBUSY;
+            ret =3D -EBUSY;
+            break;
         }
=20
         if ( vcpu >=3D 0 )
-            return 0;
+            break;
     }
=20
-    return v ? -ESRCH : 0;
+    return ret;
 }
=20
 int fill_vmsr_data(struct mcinfo_bank *mc_bank, struct domain *d,
diff -r adc7f057011e xen/arch/x86/cpu/mcheck/vmce.h
--- a/xen/arch/x86/cpu/mcheck/vmce.h	Thu Sep 27 19:52:13 2012 +0800
+++ b/xen/arch/x86/cpu/mcheck/vmce.h	Fri Sep 28 01:25:19 2012 +0800
@@ -18,6 +18,8 @@
=20
 int fill_vmsr_data(struct mcinfo_bank *mc_bank, struct domain *d,
     uint64_t gstatus);
+
+#define VMCE_INJECT_BROADCAST -1
 int inject_vmce(struct domain *d, int vcpu);
=20
 #endif

--_002_DE8DF0795D48FD4CA783C40EC829233533C32BSHSMSX101ccrcorpi_
Content-Type: application/octet-stream; name="vmce_injection_update.patch"
Content-Description: vmce_injection_update.patch
Content-Disposition: attachment; filename="vmce_injection_update.patch";
	size=2664; creation-date="Thu, 27 Sep 2012 09:42:02 GMT";
	modification-date="Thu, 27 Sep 2012 17:33:42 GMT"
Content-Transfer-Encoding: base64

WGVuL01DRTogYWRkIHNhbml0eSBjaGVjayBhbmQgY29tbWVudHMgZm9yIHZtY2UgaW5qZWN0aW9u
CgpBZGQgc2FuaXR5IGNoZWNrIGZvciBpbnB1dCB2Y3B1IHNvIHRoYXQgbWFsaWNpb3VzIHZhbHVl
IHdvdWxkIG5vdCByZXR1cm4gMC4KQWRkIGNvbW1lbnRzIHNpbmNlIHZjcHU9LTEgKGJyb2FkY2Fz
dCkgaXMgc29tZSBpbXBsaWNpdCB0byBjb2RlIHJlYWRlci4KClNpZ25lZC1vZmYtYnk6IExpdSwg
Smluc29uZyA8amluc29uZy5saXVAaW50ZWwuY29tPgpTdWdnZXN0ZWRfYnk6IENocmlzdG9waCBF
Z2dlciA8Q2hyaXN0b3BoLkVnZ2VyQGFtZC5jb20+CgpkaWZmIC1yIGFkYzdmMDU3MDExZSB4ZW4v
YXJjaC94ODYvY3B1L21jaGVjay9tY2VfaW50ZWwuYwotLS0gYS94ZW4vYXJjaC94ODYvY3B1L21j
aGVjay9tY2VfaW50ZWwuYwlUaHUgU2VwIDI3IDE5OjUyOjEzIDIwMTIgKzA4MDAKKysrIGIveGVu
L2FyY2gveDg2L2NwdS9tY2hlY2svbWNlX2ludGVsLmMJRnJpIFNlcCAyOCAwMToyNToxOSAyMDEy
ICswODAwCkBAIC0zNjAsNyArMzYwLDcgQEAKICAgICAgICAgICAgICAgICB9CiAKICAgICAgICAg
ICAgICAgICAvKiBXZSB3aWxsIGluamVjdCB2TUNFIHRvIERPTVUqLwotICAgICAgICAgICAgICAg
IGlmICggaW5qZWN0X3ZtY2UoZCwgLTEpIDwgMCApCisgICAgICAgICAgICAgICAgaWYgKCBpbmpl
Y3Rfdm1jZShkLCBWTUNFX0lOSkVDVF9CUk9BRENBU1QpIDwgMCApCiAgICAgICAgICAgICAgICAg
ewogICAgICAgICAgICAgICAgICAgICBtY2VfcHJpbnRrKE1DRV9RVUlFVCwgImluamVjdCB2TUNF
IHRvIERPTSVkIgogICAgICAgICAgICAgICAgICAgICAgICIgZmFpbGVkXG4iLCBkLT5kb21haW5f
aWQpOwpkaWZmIC1yIGFkYzdmMDU3MDExZSB4ZW4vYXJjaC94ODYvY3B1L21jaGVjay92bWNlLmMK
LS0tIGEveGVuL2FyY2gveDg2L2NwdS9tY2hlY2svdm1jZS5jCVRodSBTZXAgMjcgMTk6NTI6MTMg
MjAxMiArMDgwMAorKysgYi94ZW4vYXJjaC94ODYvY3B1L21jaGVjay92bWNlLmMJRnJpIFNlcCAy
OCAwMToyNToxOSAyMDEyICswODAwCkBAIC0zNDEsMTQgKzM0MSwyMCBAQAogLyoKICAqIGZvciBJ
bnRlbCBNQ0UsIGJyb2FkY2FzdCB2TUNFIHRvIGFsbCB2Y3B1cwogICogZm9yIEFNRCBNQ0UsIG9u
bHkgaW5qZWN0IHZNQ0UgdG8gdmNwdTAKKyAqCisgKiBAIGQsIGRvbWFpbiB0byB3aGljaCB3b3Vs
ZCBpbmplY3Qgdm1jZQorICogQCB2Y3B1LAorICogICAtMSAoVk1DRV9JTkpFQ1RfQlJPQURDQVNU
KSwgYnJvYWRjYXN0IHZNQ0UgdG8gYWxsIHZjcHVzCisgKiAgID49IDAsIHZjcHUsIHRoZSB2TUNF
IGlzIGluamVjdGVkIHRvCiAgKi8KIGludCBpbmplY3Rfdm1jZShzdHJ1Y3QgZG9tYWluICpkLCBp
bnQgdmNwdSkKIHsKICAgICBzdHJ1Y3QgdmNwdSAqdjsKKyAgICBpbnQgcmV0ID0gLUVJTlZBTDsK
IAogICAgIGZvcl9lYWNoX3ZjcHUgKCBkLCB2ICkKICAgICB7Ci0gICAgICAgIGlmICggdmNwdSA+
PSAwICYmIHYtPnZjcHVfaWQgIT0gdmNwdSApCisgICAgICAgIGlmICggdmNwdSAhPSBWTUNFX0lO
SkVDVF9CUk9BRENBU1QgJiYgdmNwdSAhPSB2LT52Y3B1X2lkICkKICAgICAgICAgICAgIGNvbnRp
bnVlOwogCiAgICAgICAgIGlmICggKGlzX2h2bV9kb21haW4oZCkgfHwKQEAgLTM1OCwxOSArMzY0
LDIxIEBACiAgICAgICAgICAgICBtY2VfcHJpbnRrKE1DRV9WRVJCT1NFLCAiTUNFOiBpbmplY3Qg
dk1DRSB0byBkJWQ6diVkXG4iLAogICAgICAgICAgICAgICAgICAgICAgICBkLT5kb21haW5faWQs
IHYtPnZjcHVfaWQpOwogICAgICAgICAgICAgdmNwdV9raWNrKHYpOworICAgICAgICAgICAgcmV0
ID0gMDsKICAgICAgICAgfQogICAgICAgICBlbHNlCiAgICAgICAgIHsKICAgICAgICAgICAgIG1j
ZV9wcmludGsoTUNFX1FVSUVULCAiRmFpbGVkIHRvIGluamVjdCB2TUNFIHRvIGQlZDp2JWRcbiIs
CiAgICAgICAgICAgICAgICAgICAgICAgIGQtPmRvbWFpbl9pZCwgdi0+dmNwdV9pZCk7Ci0gICAg
ICAgICAgICByZXR1cm4gLUVCVVNZOworICAgICAgICAgICAgcmV0ID0gLUVCVVNZOworICAgICAg
ICAgICAgYnJlYWs7CiAgICAgICAgIH0KIAogICAgICAgICBpZiAoIHZjcHUgPj0gMCApCi0gICAg
ICAgICAgICByZXR1cm4gMDsKKyAgICAgICAgICAgIGJyZWFrOwogICAgIH0KIAotICAgIHJldHVy
biB2ID8gLUVTUkNIIDogMDsKKyAgICByZXR1cm4gcmV0OwogfQogCiBpbnQgZmlsbF92bXNyX2Rh
dGEoc3RydWN0IG1jaW5mb19iYW5rICptY19iYW5rLCBzdHJ1Y3QgZG9tYWluICpkLApkaWZmIC1y
IGFkYzdmMDU3MDExZSB4ZW4vYXJjaC94ODYvY3B1L21jaGVjay92bWNlLmgKLS0tIGEveGVuL2Fy
Y2gveDg2L2NwdS9tY2hlY2svdm1jZS5oCVRodSBTZXAgMjcgMTk6NTI6MTMgMjAxMiArMDgwMAor
KysgYi94ZW4vYXJjaC94ODYvY3B1L21jaGVjay92bWNlLmgJRnJpIFNlcCAyOCAwMToyNToxOSAy
MDEyICswODAwCkBAIC0xOCw2ICsxOCw4IEBACiAKIGludCBmaWxsX3Ztc3JfZGF0YShzdHJ1Y3Qg
bWNpbmZvX2JhbmsgKm1jX2JhbmssIHN0cnVjdCBkb21haW4gKmQsCiAgICAgdWludDY0X3QgZ3N0
YXR1cyk7CisKKyNkZWZpbmUgVk1DRV9JTkpFQ1RfQlJPQURDQVNUIC0xCiBpbnQgaW5qZWN0X3Zt
Y2Uoc3RydWN0IGRvbWFpbiAqZCwgaW50IHZjcHUpOwogCiAjZW5kaWYK

--_002_DE8DF0795D48FD4CA783C40EC829233533C32BSHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 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_DE8DF0795D48FD4CA783C40EC829233533C32BSHSMSX101ccrcorpi_--


From xen-devel-bounces@lists.xen.org Thu Sep 27 09:50:36 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Sep 2012 09:50:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1THAjW-0000iz-Fd; Thu, 27 Sep 2012 09:50:14 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1THAjU-0000is-ET
	for xen-devel@lists.xen.org; Thu, 27 Sep 2012 09:50:12 +0000
Received: from [85.158.139.211:3089] by server-5.bemta-5.messagelabs.com id
	2C/70-21075-35124605; Thu, 27 Sep 2012 09:50:11 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-9.tower-206.messagelabs.com!1348739410!18648241!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTE5OTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24400 invoked from network); 27 Sep 2012 09:50:11 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Sep 2012 09:50:11 -0000
X-IronPort-AV: E=Sophos;i="4.80,494,1344211200"; d="scan'208";a="14797984"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Sep 2012 09:50: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.279.1; Thu, 27 Sep 2012 10:50:03 +0100
Date: Thu, 27 Sep 2012 10:49:08 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: arvind viswanathan <arvind.viswanathan@gmail.com>
In-Reply-To: <CAFOzg+HARCb6UN5yu3hmsDRNVyLmwv0rnw6z2+E8b=5mtKqPFQ@mail.gmail.com>
Message-ID: <alpine.DEB.2.02.1209271048200.29232@kaball.uk.xensource.com>
References: <CAFOzg+HARCb6UN5yu3hmsDRNVyLmwv0rnw6z2+E8b=5mtKqPFQ@mail.gmail.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Content-Type: multipart/mixed;
	boundary="1342847746-1308590784-1348739364=:29232"
Cc: Attilio Rao <attilio.rao@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] xen PVHVM
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<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-1308590784-1348739364=:29232
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8BIT

On Wed, 26 Sep 2012, arvind viswanathan wrote:
> Hi 
> I have a freeBSD compiled as a xen PVHVM. I am not sure how the network_connect gets called in this case.
> This function is called upon setting XenbusStateInitWait. In the source code I only see netback changing the state.
> I was not sure how to find out who sets the state to XenbusStateInitWait in case PVHVM. Any help would be appreciated.

you might want to cc the freebsd development list as well
--1342847746-1308590784-1348739364=:29232
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 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-1308590784-1348739364=:29232--


From xen-devel-bounces@lists.xen.org Thu Sep 27 09:50:36 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Sep 2012 09:50:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1THAjW-0000iz-Fd; Thu, 27 Sep 2012 09:50:14 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1THAjU-0000is-ET
	for xen-devel@lists.xen.org; Thu, 27 Sep 2012 09:50:12 +0000
Received: from [85.158.139.211:3089] by server-5.bemta-5.messagelabs.com id
	2C/70-21075-35124605; Thu, 27 Sep 2012 09:50:11 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-9.tower-206.messagelabs.com!1348739410!18648241!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTE5OTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24400 invoked from network); 27 Sep 2012 09:50:11 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Sep 2012 09:50:11 -0000
X-IronPort-AV: E=Sophos;i="4.80,494,1344211200"; d="scan'208";a="14797984"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Sep 2012 09:50: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.279.1; Thu, 27 Sep 2012 10:50:03 +0100
Date: Thu, 27 Sep 2012 10:49:08 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: arvind viswanathan <arvind.viswanathan@gmail.com>
In-Reply-To: <CAFOzg+HARCb6UN5yu3hmsDRNVyLmwv0rnw6z2+E8b=5mtKqPFQ@mail.gmail.com>
Message-ID: <alpine.DEB.2.02.1209271048200.29232@kaball.uk.xensource.com>
References: <CAFOzg+HARCb6UN5yu3hmsDRNVyLmwv0rnw6z2+E8b=5mtKqPFQ@mail.gmail.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Content-Type: multipart/mixed;
	boundary="1342847746-1308590784-1348739364=:29232"
Cc: Attilio Rao <attilio.rao@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] xen PVHVM
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<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-1308590784-1348739364=:29232
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8BIT

On Wed, 26 Sep 2012, arvind viswanathan wrote:
> Hi 
> I have a freeBSD compiled as a xen PVHVM. I am not sure how the network_connect gets called in this case.
> This function is called upon setting XenbusStateInitWait. In the source code I only see netback changing the state.
> I was not sure how to find out who sets the state to XenbusStateInitWait in case PVHVM. Any help would be appreciated.

you might want to cc the freebsd development list as well
--1342847746-1308590784-1348739364=:29232
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 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-1308590784-1348739364=:29232--


From xen-devel-bounces@lists.xen.org Thu Sep 27 09:57:51 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Sep 2012 09:57: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 1THAqY-0000tZ-CH; Thu, 27 Sep 2012 09:57:30 +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 1THAqX-0000tU-3L
	for xen-devel@lists.xensource.com; Thu, 27 Sep 2012 09:57:29 +0000
Received: from [85.158.143.35:47154] by server-3.bemta-4.messagelabs.com id
	EC/79-10986-80324605; Thu, 27 Sep 2012 09:57:28 +0000
X-Env-Sender: Christoph.Egger@amd.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1348739827!12963417!1
X-Originating-IP: [216.32.180.188]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12673 invoked from network); 27 Sep 2012 09:57:10 -0000
Received: from co1ehsobe005.messaging.microsoft.com (HELO
	co1outboundpool.messaging.microsoft.com) (216.32.180.188)
	by server-8.tower-21.messagelabs.com with AES128-SHA encrypted SMTP;
	27 Sep 2012 09:57:10 -0000
Received: from mail115-co1-R.bigfish.com (10.243.78.251) by
	CO1EHSOBE006.bigfish.com (10.243.66.69) with Microsoft SMTP Server id
	14.1.225.23; Thu, 27 Sep 2012 09:57:06 +0000
Received: from mail115-co1 (localhost [127.0.0.1])	by
	mail115-co1-R.bigfish.com (Postfix) with ESMTP id 7CA919000FE;
	Thu, 27 Sep 2012 09:57:06 +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: -6
X-BigFish: VPS-6(zzbb2dI98dI103dK1432I4015Id6f1izz1202h1d1ah1d2ahzz8275bhz2dh668h839hd25he5bhf0ah107ah1288h12a5h12a9h12bdh137ah13b6h1155h)
Received: from mail115-co1 (localhost.localdomain [127.0.0.1]) by mail115-co1
	(MessageSwitch) id 1348739824494429_11289;
	Thu, 27 Sep 2012 09:57:04 +0000 (UTC)
Received: from CO1EHSMHS004.bigfish.com (unknown [10.243.78.234])	by
	mail115-co1.bigfish.com (Postfix) with ESMTP id 6B40BC0050;
	Thu, 27 Sep 2012 09:57:04 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	CO1EHSMHS004.bigfish.com (10.243.66.14) with Microsoft SMTP Server id
	14.1.225.23; Thu, 27 Sep 2012 09:57:02 +0000
X-WSS-ID: 0MB06B0-01-LTZ-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 28E7B1028002;	Thu, 27 Sep 2012 04:57:00 -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, 27 Sep 2012 04:57:16 -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, 27 Sep 2012 04:57:00 -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; Thu, 27 Sep 2012
	05:56:59 -0400
Message-ID: <506422E9.3060100@amd.com>
Date: Thu, 27 Sep 2012 11:56:57 +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: <DE8DF0795D48FD4CA783C40EC8292335339547@SHSMSX101.ccr.corp.intel.com>
	<506173FB.8070603@amd.com>
	<5061A833020000780009DA1A@nat28.tlf.novell.com>
	<50619B61.2030609@amd.com>
	<DE8DF0795D48FD4CA783C40EC829233533AA6E@SHSMSX101.ccr.corp.intel.com>
	<5062CC25020000780009DE44@nat28.tlf.novell.com>
	<DE8DF0795D48FD4CA783C40EC829233533C01C@SHSMSX101.ccr.corp.intel.com>
	<5064143A.6070203@amd.com>
	<DE8DF0795D48FD4CA783C40EC829233533C32B@SHSMSX101.ccr.corp.intel.com>
In-Reply-To: <DE8DF0795D48FD4CA783C40EC829233533C32B@SHSMSX101.ccr.corp.intel.com>
X-OriginatorOrg: amd.com
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"keir@xen.org" <keir@xen.org>,
	"Ian.Campbell@citrix.com" <Ian.Campbell@citrix.com>,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH 6] X86/MCE: update vMCE injection for AMD
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 09/27/12 11:45, Liu, Jinsong wrote:

>>>
>>> Got it, thanks! It's OK to me, but how about add sanity check and
>>> some comments like 
>>>
>>> ==================
>>> Xen/MCE: add sanity check and comments for vmce injection
>>>
>>> Add sanity check for input vcpu so that malicious value would not
>>> return 0. 
>>> Add comments since vcpu<0 (broadcast) is some implicit to code
>>> reader. 
>>
>>
>> Yeah, a like #define VMCE_INJECT_BROADCAST is also helpful.
>>
>>>
>>> Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>
>>>
>>> diff -r adc7f057011e xen/arch/x86/cpu/mcheck/vmce.c
>>> --- a/xen/arch/x86/cpu/mcheck/vmce.c	Thu Sep 27 19:52:13 2012 +0800
>>> +++ b/xen/arch/x86/cpu/mcheck/vmce.c	Thu Sep 27 20:56:52 2012 +0800
>>>  @@ -341,10 +341,16 @@ /*
>>>   * for Intel MCE, broadcast vMCE to all vcpus
>>>   * for AMD MCE, only inject vMCE to vcpu0
>>> + *
>>> + * @ d, domain to which would inject vmce
>>> + * @ vcpu,
>>> + *   < 0, broadcast vMCE to all vcpus
>>> + *   >= 0, vcpu who would be injected vMCE
>>
>>
>> Better wording:
>>  >= 0, vcpu, the vMCE is injected to
>>
>> Christoph
>>
> 
> Fine to me, updated accordingly.
> 
> Thanks,
> Jinsong
> 
> ===============
> Xen/MCE: add sanity check and comments for vmce injection
> 
> Add sanity check for input vcpu so that malicious value would not return 0.
> Add comments since vcpu=-1 (broadcast) is some implicit to code reader.
> 
> Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>
> Suggested_by: Christoph Egger <Christoph.Egger@amd.com>


Acked-by: Christoph Egger <Christoph.Egger@amd.com>

> 
> diff -r adc7f057011e xen/arch/x86/cpu/mcheck/mce_intel.c
> --- a/xen/arch/x86/cpu/mcheck/mce_intel.c	Thu Sep 27 19:52:13 2012 +0800
> +++ b/xen/arch/x86/cpu/mcheck/mce_intel.c	Fri Sep 28 01:25:19 2012 +0800
> @@ -360,7 +360,7 @@
>                  }
>  
>                  /* We will inject vMCE to DOMU*/
> -                if ( inject_vmce(d, -1) < 0 )
> +                if ( inject_vmce(d, VMCE_INJECT_BROADCAST) < 0 )
>                  {
>                      mce_printk(MCE_QUIET, "inject vMCE to DOM%d"
>                        " failed\n", d->domain_id);
> diff -r adc7f057011e xen/arch/x86/cpu/mcheck/vmce.c
> --- a/xen/arch/x86/cpu/mcheck/vmce.c	Thu Sep 27 19:52:13 2012 +0800
> +++ b/xen/arch/x86/cpu/mcheck/vmce.c	Fri Sep 28 01:25:19 2012 +0800
> @@ -341,14 +341,20 @@
>  /*
>   * for Intel MCE, broadcast vMCE to all vcpus
>   * for AMD MCE, only inject vMCE to vcpu0
> + *
> + * @ d, domain to which would inject vmce
> + * @ vcpu,
> + *   -1 (VMCE_INJECT_BROADCAST), broadcast vMCE to all vcpus
> + *   >= 0, vcpu, the vMCE is injected to
>   */
>  int inject_vmce(struct domain *d, int vcpu)
>  {
>      struct vcpu *v;
> +    int ret = -EINVAL;
>  
>      for_each_vcpu ( d, v )
>      {
> -        if ( vcpu >= 0 && v->vcpu_id != vcpu )
> +        if ( vcpu != VMCE_INJECT_BROADCAST && vcpu != v->vcpu_id )
>              continue;
>  
>          if ( (is_hvm_domain(d) ||
> @@ -358,19 +364,21 @@
>              mce_printk(MCE_VERBOSE, "MCE: inject vMCE to d%d:v%d\n",
>                         d->domain_id, v->vcpu_id);
>              vcpu_kick(v);
> +            ret = 0;
>          }
>          else
>          {
>              mce_printk(MCE_QUIET, "Failed to inject vMCE to d%d:v%d\n",
>                         d->domain_id, v->vcpu_id);
> -            return -EBUSY;
> +            ret = -EBUSY;
> +            break;
>          }
>  
>          if ( vcpu >= 0 )
> -            return 0;
> +            break;
>      }
>  
> -    return v ? -ESRCH : 0;
> +    return ret;
>  }
>  
>  int fill_vmsr_data(struct mcinfo_bank *mc_bank, struct domain *d,
> diff -r adc7f057011e xen/arch/x86/cpu/mcheck/vmce.h
> --- a/xen/arch/x86/cpu/mcheck/vmce.h	Thu Sep 27 19:52:13 2012 +0800
> +++ b/xen/arch/x86/cpu/mcheck/vmce.h	Fri Sep 28 01:25:19 2012 +0800
> @@ -18,6 +18,8 @@
>  
>  int fill_vmsr_data(struct mcinfo_bank *mc_bank, struct domain *d,
>      uint64_t gstatus);
> +
> +#define VMCE_INJECT_BROADCAST -1
>  int inject_vmce(struct domain *d, int vcpu);
>  
>  #endif



-- 
---to satisfy European Law for business letters:
Advanced Micro Devices GmbH
Einsteinring 24, 85689 Dornach b. Muenchen
Geschaeftsfuehrer: Alberto Bozzo
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 Thu Sep 27 09:57:51 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Sep 2012 09:57: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 1THAqY-0000tZ-CH; Thu, 27 Sep 2012 09:57:30 +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 1THAqX-0000tU-3L
	for xen-devel@lists.xensource.com; Thu, 27 Sep 2012 09:57:29 +0000
Received: from [85.158.143.35:47154] by server-3.bemta-4.messagelabs.com id
	EC/79-10986-80324605; Thu, 27 Sep 2012 09:57:28 +0000
X-Env-Sender: Christoph.Egger@amd.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1348739827!12963417!1
X-Originating-IP: [216.32.180.188]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12673 invoked from network); 27 Sep 2012 09:57:10 -0000
Received: from co1ehsobe005.messaging.microsoft.com (HELO
	co1outboundpool.messaging.microsoft.com) (216.32.180.188)
	by server-8.tower-21.messagelabs.com with AES128-SHA encrypted SMTP;
	27 Sep 2012 09:57:10 -0000
Received: from mail115-co1-R.bigfish.com (10.243.78.251) by
	CO1EHSOBE006.bigfish.com (10.243.66.69) with Microsoft SMTP Server id
	14.1.225.23; Thu, 27 Sep 2012 09:57:06 +0000
Received: from mail115-co1 (localhost [127.0.0.1])	by
	mail115-co1-R.bigfish.com (Postfix) with ESMTP id 7CA919000FE;
	Thu, 27 Sep 2012 09:57:06 +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: -6
X-BigFish: VPS-6(zzbb2dI98dI103dK1432I4015Id6f1izz1202h1d1ah1d2ahzz8275bhz2dh668h839hd25he5bhf0ah107ah1288h12a5h12a9h12bdh137ah13b6h1155h)
Received: from mail115-co1 (localhost.localdomain [127.0.0.1]) by mail115-co1
	(MessageSwitch) id 1348739824494429_11289;
	Thu, 27 Sep 2012 09:57:04 +0000 (UTC)
Received: from CO1EHSMHS004.bigfish.com (unknown [10.243.78.234])	by
	mail115-co1.bigfish.com (Postfix) with ESMTP id 6B40BC0050;
	Thu, 27 Sep 2012 09:57:04 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	CO1EHSMHS004.bigfish.com (10.243.66.14) with Microsoft SMTP Server id
	14.1.225.23; Thu, 27 Sep 2012 09:57:02 +0000
X-WSS-ID: 0MB06B0-01-LTZ-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 28E7B1028002;	Thu, 27 Sep 2012 04:57:00 -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, 27 Sep 2012 04:57:16 -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, 27 Sep 2012 04:57:00 -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; Thu, 27 Sep 2012
	05:56:59 -0400
Message-ID: <506422E9.3060100@amd.com>
Date: Thu, 27 Sep 2012 11:56:57 +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: <DE8DF0795D48FD4CA783C40EC8292335339547@SHSMSX101.ccr.corp.intel.com>
	<506173FB.8070603@amd.com>
	<5061A833020000780009DA1A@nat28.tlf.novell.com>
	<50619B61.2030609@amd.com>
	<DE8DF0795D48FD4CA783C40EC829233533AA6E@SHSMSX101.ccr.corp.intel.com>
	<5062CC25020000780009DE44@nat28.tlf.novell.com>
	<DE8DF0795D48FD4CA783C40EC829233533C01C@SHSMSX101.ccr.corp.intel.com>
	<5064143A.6070203@amd.com>
	<DE8DF0795D48FD4CA783C40EC829233533C32B@SHSMSX101.ccr.corp.intel.com>
In-Reply-To: <DE8DF0795D48FD4CA783C40EC829233533C32B@SHSMSX101.ccr.corp.intel.com>
X-OriginatorOrg: amd.com
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"keir@xen.org" <keir@xen.org>,
	"Ian.Campbell@citrix.com" <Ian.Campbell@citrix.com>,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH 6] X86/MCE: update vMCE injection for AMD
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 09/27/12 11:45, Liu, Jinsong wrote:

>>>
>>> Got it, thanks! It's OK to me, but how about add sanity check and
>>> some comments like 
>>>
>>> ==================
>>> Xen/MCE: add sanity check and comments for vmce injection
>>>
>>> Add sanity check for input vcpu so that malicious value would not
>>> return 0. 
>>> Add comments since vcpu<0 (broadcast) is some implicit to code
>>> reader. 
>>
>>
>> Yeah, a like #define VMCE_INJECT_BROADCAST is also helpful.
>>
>>>
>>> Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>
>>>
>>> diff -r adc7f057011e xen/arch/x86/cpu/mcheck/vmce.c
>>> --- a/xen/arch/x86/cpu/mcheck/vmce.c	Thu Sep 27 19:52:13 2012 +0800
>>> +++ b/xen/arch/x86/cpu/mcheck/vmce.c	Thu Sep 27 20:56:52 2012 +0800
>>>  @@ -341,10 +341,16 @@ /*
>>>   * for Intel MCE, broadcast vMCE to all vcpus
>>>   * for AMD MCE, only inject vMCE to vcpu0
>>> + *
>>> + * @ d, domain to which would inject vmce
>>> + * @ vcpu,
>>> + *   < 0, broadcast vMCE to all vcpus
>>> + *   >= 0, vcpu who would be injected vMCE
>>
>>
>> Better wording:
>>  >= 0, vcpu, the vMCE is injected to
>>
>> Christoph
>>
> 
> Fine to me, updated accordingly.
> 
> Thanks,
> Jinsong
> 
> ===============
> Xen/MCE: add sanity check and comments for vmce injection
> 
> Add sanity check for input vcpu so that malicious value would not return 0.
> Add comments since vcpu=-1 (broadcast) is some implicit to code reader.
> 
> Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>
> Suggested_by: Christoph Egger <Christoph.Egger@amd.com>


Acked-by: Christoph Egger <Christoph.Egger@amd.com>

> 
> diff -r adc7f057011e xen/arch/x86/cpu/mcheck/mce_intel.c
> --- a/xen/arch/x86/cpu/mcheck/mce_intel.c	Thu Sep 27 19:52:13 2012 +0800
> +++ b/xen/arch/x86/cpu/mcheck/mce_intel.c	Fri Sep 28 01:25:19 2012 +0800
> @@ -360,7 +360,7 @@
>                  }
>  
>                  /* We will inject vMCE to DOMU*/
> -                if ( inject_vmce(d, -1) < 0 )
> +                if ( inject_vmce(d, VMCE_INJECT_BROADCAST) < 0 )
>                  {
>                      mce_printk(MCE_QUIET, "inject vMCE to DOM%d"
>                        " failed\n", d->domain_id);
> diff -r adc7f057011e xen/arch/x86/cpu/mcheck/vmce.c
> --- a/xen/arch/x86/cpu/mcheck/vmce.c	Thu Sep 27 19:52:13 2012 +0800
> +++ b/xen/arch/x86/cpu/mcheck/vmce.c	Fri Sep 28 01:25:19 2012 +0800
> @@ -341,14 +341,20 @@
>  /*
>   * for Intel MCE, broadcast vMCE to all vcpus
>   * for AMD MCE, only inject vMCE to vcpu0
> + *
> + * @ d, domain to which would inject vmce
> + * @ vcpu,
> + *   -1 (VMCE_INJECT_BROADCAST), broadcast vMCE to all vcpus
> + *   >= 0, vcpu, the vMCE is injected to
>   */
>  int inject_vmce(struct domain *d, int vcpu)
>  {
>      struct vcpu *v;
> +    int ret = -EINVAL;
>  
>      for_each_vcpu ( d, v )
>      {
> -        if ( vcpu >= 0 && v->vcpu_id != vcpu )
> +        if ( vcpu != VMCE_INJECT_BROADCAST && vcpu != v->vcpu_id )
>              continue;
>  
>          if ( (is_hvm_domain(d) ||
> @@ -358,19 +364,21 @@
>              mce_printk(MCE_VERBOSE, "MCE: inject vMCE to d%d:v%d\n",
>                         d->domain_id, v->vcpu_id);
>              vcpu_kick(v);
> +            ret = 0;
>          }
>          else
>          {
>              mce_printk(MCE_QUIET, "Failed to inject vMCE to d%d:v%d\n",
>                         d->domain_id, v->vcpu_id);
> -            return -EBUSY;
> +            ret = -EBUSY;
> +            break;
>          }
>  
>          if ( vcpu >= 0 )
> -            return 0;
> +            break;
>      }
>  
> -    return v ? -ESRCH : 0;
> +    return ret;
>  }
>  
>  int fill_vmsr_data(struct mcinfo_bank *mc_bank, struct domain *d,
> diff -r adc7f057011e xen/arch/x86/cpu/mcheck/vmce.h
> --- a/xen/arch/x86/cpu/mcheck/vmce.h	Thu Sep 27 19:52:13 2012 +0800
> +++ b/xen/arch/x86/cpu/mcheck/vmce.h	Fri Sep 28 01:25:19 2012 +0800
> @@ -18,6 +18,8 @@
>  
>  int fill_vmsr_data(struct mcinfo_bank *mc_bank, struct domain *d,
>      uint64_t gstatus);
> +
> +#define VMCE_INJECT_BROADCAST -1
>  int inject_vmce(struct domain *d, int vcpu);
>  
>  #endif



-- 
---to satisfy European Law for business letters:
Advanced Micro Devices GmbH
Einsteinring 24, 85689 Dornach b. Muenchen
Geschaeftsfuehrer: Alberto Bozzo
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 Thu Sep 27 10:07:37 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Sep 2012 10:07: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 1THB01-0001BO-EY; Thu, 27 Sep 2012 10:07:17 +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 1THB00-0001BJ-51
	for xen-devel@lists.xen.org; Thu, 27 Sep 2012 10:07:16 +0000
Received: from [85.158.139.83:39664] by server-9.bemta-5.messagelabs.com id
	B3/A4-14846-35524605; Thu, 27 Sep 2012 10:07:15 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1348740434!25015961!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTE5OTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32586 invoked from network); 27 Sep 2012 10:07:15 -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;
	27 Sep 2012 10:07:15 -0000
X-IronPort-AV: E=Sophos;i="4.80,495,1344211200"; d="scan'208";a="14798512"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Sep 2012 10:07: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.279.1; Thu, 27 Sep 2012 11:07:14 +0100
Date: Thu, 27 Sep 2012 11:06:20 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Xudong Hao <xudong.hao@intel.com>
In-Reply-To: <1348714912-18953-1-git-send-email-xudong.hao@intel.com>
Message-ID: <alpine.DEB.2.02.1209271106060.29232@kaball.uk.xensource.com>
References: <1348714912-18953-1-git-send-email-xudong.hao@intel.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>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	Xiantao Zhang <xiantao.zhang@intel.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v3] qemu/xen: Add 64 bits big bar support on
	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, 27 Sep 2012, Xudong Hao wrote:
> v3 changes from v2:
> - Refine code following by the qemu code style
> - As suggestion by Stefano, cheanup code, add some code comment
> 
> v2 changes from v1:
> - Rebase to qemu upstream from qemu-xen
> 
> Currently it is assumed PCI device BAR access < 4G memory. If there is such a
> device whose BAR size is larger than 4G, it must access > 4G memory address.
> This patch enable the 64bits big BAR support on qemu.
> 
> Signed-off-by: Xudong Hao <xudong.hao@intel.com>
> Signed-off-by: Xiantao Zhang <xiantao.zhang@intel.com>

Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>


>  hw/xen_pt.c             |    7 +++++--
>  hw/xen_pt_config_init.c |   39 ++++++++++++++++++++++++++-------------
>  2 files changed, 31 insertions(+), 15 deletions(-)
> 
> diff --git a/hw/xen_pt.c b/hw/xen_pt.c
> index 307119a..838bcea 100644
> --- a/hw/xen_pt.c
> +++ b/hw/xen_pt.c
> @@ -410,14 +410,17 @@ static int xen_pt_register_regions(XenPCIPassthroughState *s)
>              if (r->type & XEN_HOST_PCI_REGION_TYPE_PREFETCH) {
>                  type |= PCI_BASE_ADDRESS_MEM_PREFETCH;
>              }
> +            if (r->type & XEN_HOST_PCI_REGION_TYPE_MEM_64) {
> +                type |= PCI_BASE_ADDRESS_MEM_TYPE_64;
> +            }
>          }
>  
>          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",
> +        XEN_PT_LOG(&s->dev, "IO region %i registered (size=0x%lx"PRIx64
> +                   " base_addr=0x%lx"PRIx64" type: %#x)\n",
>                     i, r->size, r->base_addr, type);
>      }
>  
> diff --git a/hw/xen_pt_config_init.c b/hw/xen_pt_config_init.c
> index e524a40..0a5f82c 100644
> --- a/hw/xen_pt_config_init.c
> +++ b/hw/xen_pt_config_init.c
> @@ -342,6 +342,23 @@ static int xen_pt_cmd_reg_write(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
>  #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 bool is_64bit_bar(PCIIORegion *r)
> +{
> +    return !!(r->type & PCI_BASE_ADDRESS_MEM_TYPE_64);
> +}
> +
> +static uint64_t xen_pt_get_bar_size(PCIIORegion *r)
> +{
> +    if (is_64bit_bar(r)) {
> +        uint64_t size64;
> +        size64 = (r + 1)->size;
> +        size64 <<= 32;
> +        size64 += r->size;
> +        return size64;
> +    }
> +    return r->size;
> +}
> +
>  static XenPTBarFlag xen_pt_bar_reg_parse(XenPCIPassthroughState *s,
>                                           XenPTRegInfo *reg)
>  {
> @@ -366,7 +383,7 @@ static XenPTBarFlag xen_pt_bar_reg_parse(XenPCIPassthroughState *s,
>  
>      /* check unused BAR */
>      r = &d->io_regions[index];
> -    if (r->size == 0) {
> +    if (!xen_pt_get_bar_size(r)) {
>          return XEN_PT_BAR_FLAG_UNUSED;
>      }
>  
> @@ -481,7 +498,12 @@ static int xen_pt_bar_reg_write(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
>      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);
> +        if (!r_size) {
> +            /* low 32 bits mask for 64 bit bars */
> +            bar_ro_mask = XEN_PT_BAR_ALLF;
> +        } else {
> +            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;
> @@ -489,7 +511,7 @@ static int xen_pt_bar_reg_write(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
>          break;
>      case XEN_PT_BAR_FLAG_UPPER:
>          bar_emu_mask = XEN_PT_BAR_ALLF;
> -        bar_ro_mask = 0;    /* all upper 32bit are R/W */
> +        bar_ro_mask = r_size ? r_size - 1 : 0;
>          break;
>      default:
>          break;
> @@ -501,22 +523,13 @@ static int xen_pt_bar_reg_write(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
>  
>      /* check whether we need to update the virtual region address or not */
>      switch (s->bases[index].bar_flag) {
> +    case XEN_PT_BAR_FLAG_UPPER:
>      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;
>      }
> -- 
> 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 Thu Sep 27 10:07:37 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Sep 2012 10:07: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 1THB01-0001BO-EY; Thu, 27 Sep 2012 10:07:17 +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 1THB00-0001BJ-51
	for xen-devel@lists.xen.org; Thu, 27 Sep 2012 10:07:16 +0000
Received: from [85.158.139.83:39664] by server-9.bemta-5.messagelabs.com id
	B3/A4-14846-35524605; Thu, 27 Sep 2012 10:07:15 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1348740434!25015961!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTE5OTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32586 invoked from network); 27 Sep 2012 10:07:15 -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;
	27 Sep 2012 10:07:15 -0000
X-IronPort-AV: E=Sophos;i="4.80,495,1344211200"; d="scan'208";a="14798512"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Sep 2012 10:07: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.279.1; Thu, 27 Sep 2012 11:07:14 +0100
Date: Thu, 27 Sep 2012 11:06:20 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball.uk.xensource.com
To: Xudong Hao <xudong.hao@intel.com>
In-Reply-To: <1348714912-18953-1-git-send-email-xudong.hao@intel.com>
Message-ID: <alpine.DEB.2.02.1209271106060.29232@kaball.uk.xensource.com>
References: <1348714912-18953-1-git-send-email-xudong.hao@intel.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>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	Xiantao Zhang <xiantao.zhang@intel.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v3] qemu/xen: Add 64 bits big bar support on
	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, 27 Sep 2012, Xudong Hao wrote:
> v3 changes from v2:
> - Refine code following by the qemu code style
> - As suggestion by Stefano, cheanup code, add some code comment
> 
> v2 changes from v1:
> - Rebase to qemu upstream from qemu-xen
> 
> Currently it is assumed PCI device BAR access < 4G memory. If there is such a
> device whose BAR size is larger than 4G, it must access > 4G memory address.
> This patch enable the 64bits big BAR support on qemu.
> 
> Signed-off-by: Xudong Hao <xudong.hao@intel.com>
> Signed-off-by: Xiantao Zhang <xiantao.zhang@intel.com>

Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>


>  hw/xen_pt.c             |    7 +++++--
>  hw/xen_pt_config_init.c |   39 ++++++++++++++++++++++++++-------------
>  2 files changed, 31 insertions(+), 15 deletions(-)
> 
> diff --git a/hw/xen_pt.c b/hw/xen_pt.c
> index 307119a..838bcea 100644
> --- a/hw/xen_pt.c
> +++ b/hw/xen_pt.c
> @@ -410,14 +410,17 @@ static int xen_pt_register_regions(XenPCIPassthroughState *s)
>              if (r->type & XEN_HOST_PCI_REGION_TYPE_PREFETCH) {
>                  type |= PCI_BASE_ADDRESS_MEM_PREFETCH;
>              }
> +            if (r->type & XEN_HOST_PCI_REGION_TYPE_MEM_64) {
> +                type |= PCI_BASE_ADDRESS_MEM_TYPE_64;
> +            }
>          }
>  
>          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",
> +        XEN_PT_LOG(&s->dev, "IO region %i registered (size=0x%lx"PRIx64
> +                   " base_addr=0x%lx"PRIx64" type: %#x)\n",
>                     i, r->size, r->base_addr, type);
>      }
>  
> diff --git a/hw/xen_pt_config_init.c b/hw/xen_pt_config_init.c
> index e524a40..0a5f82c 100644
> --- a/hw/xen_pt_config_init.c
> +++ b/hw/xen_pt_config_init.c
> @@ -342,6 +342,23 @@ static int xen_pt_cmd_reg_write(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
>  #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 bool is_64bit_bar(PCIIORegion *r)
> +{
> +    return !!(r->type & PCI_BASE_ADDRESS_MEM_TYPE_64);
> +}
> +
> +static uint64_t xen_pt_get_bar_size(PCIIORegion *r)
> +{
> +    if (is_64bit_bar(r)) {
> +        uint64_t size64;
> +        size64 = (r + 1)->size;
> +        size64 <<= 32;
> +        size64 += r->size;
> +        return size64;
> +    }
> +    return r->size;
> +}
> +
>  static XenPTBarFlag xen_pt_bar_reg_parse(XenPCIPassthroughState *s,
>                                           XenPTRegInfo *reg)
>  {
> @@ -366,7 +383,7 @@ static XenPTBarFlag xen_pt_bar_reg_parse(XenPCIPassthroughState *s,
>  
>      /* check unused BAR */
>      r = &d->io_regions[index];
> -    if (r->size == 0) {
> +    if (!xen_pt_get_bar_size(r)) {
>          return XEN_PT_BAR_FLAG_UNUSED;
>      }
>  
> @@ -481,7 +498,12 @@ static int xen_pt_bar_reg_write(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
>      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);
> +        if (!r_size) {
> +            /* low 32 bits mask for 64 bit bars */
> +            bar_ro_mask = XEN_PT_BAR_ALLF;
> +        } else {
> +            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;
> @@ -489,7 +511,7 @@ static int xen_pt_bar_reg_write(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
>          break;
>      case XEN_PT_BAR_FLAG_UPPER:
>          bar_emu_mask = XEN_PT_BAR_ALLF;
> -        bar_ro_mask = 0;    /* all upper 32bit are R/W */
> +        bar_ro_mask = r_size ? r_size - 1 : 0;
>          break;
>      default:
>          break;
> @@ -501,22 +523,13 @@ static int xen_pt_bar_reg_write(XenPCIPassthroughState *s, XenPTReg *cfg_entry,
>  
>      /* check whether we need to update the virtual region address or not */
>      switch (s->bases[index].bar_flag) {
> +    case XEN_PT_BAR_FLAG_UPPER:
>      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;
>      }
> -- 
> 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 Thu Sep 27 10:31:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Sep 2012 10:31:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1THBMp-0001O5-Rd; Thu, 27 Sep 2012 10:30:51 +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 1THBMo-0001Nl-KA
	for xen-devel@lists.xen.org; Thu, 27 Sep 2012 10:30:50 +0000
Received: from [85.158.143.99:2104] by server-1.bemta-4.messagelabs.com id
	D1/18-05684-9DA24605; Thu, 27 Sep 2012 10:30:49 +0000
X-Env-Sender: lars.kurth.xen@gmail.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1348741847!22363696!1
X-Originating-IP: [209.85.214.45]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
	ML_RADAR_SPEW_LINKS_23,RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31204 invoked from network); 27 Sep 2012 10:30:48 -0000
Received: from mail-bk0-f45.google.com (HELO mail-bk0-f45.google.com)
	(209.85.214.45)
	by server-14.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Sep 2012 10:30:48 -0000
Received: by bkcjf3 with SMTP id jf3so1002477bkc.32
	for <multiple recipients>; Thu, 27 Sep 2012 03:30:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:message-id:date:from:reply-to:user-agent:mime-version:to
	:subject:content-type:content-transfer-encoding;
	bh=RyWPaBVV5EKIt/pyKTe1/0Bs8HPukr02t3D1+RIvw9s=;
	b=KQLf4aMacCbwgbeyG+edywB1N/syJ/IhYsoebJDb7lFtFF0vBP2nP4rbfsEPFEiQ2y
	GWX1Hs6oeAtvt0Jkup0WMHaAu372reo7h2GHPyho2/cGc+D/2/T94xmPl8KMuVDb5U+G
	X+mrYy+MFA7wJSKuvEhVDLJ7UOeG9vhECQiqK8EzjppoxNUCtSpszbk5k0kH494tV/UV
	5d+KePeX2EszCqjd5QvAPj594Ne0xtLTuBGlF3A6lU70qemOzU4QpunsVXZSOF3vaxDm
	oPXDUoXJhUQEkP6TPDEn33tXS3Tb4Ij5jC/yfo+RzUqXKURBIkEwcyODqDZ/CeHcd8pb
	SN+w==
Received: by 10.204.155.133 with SMTP id s5mr1876405bkw.112.1348741847301;
	Thu, 27 Sep 2012 03:30:47 -0700 (PDT)
Received: from [172.16.26.11] (b0fb5b35.bb.sky.com. [176.251.91.53])
	by mx.google.com with ESMTPS id j24sm4168320bkv.0.2012.09.27.03.30.40
	(version=SSLv3 cipher=OTHER); Thu, 27 Sep 2012 03:30:46 -0700 (PDT)
Message-ID: <50642AC8.2070302@xen.org>
Date: Thu, 27 Sep 2012 11:30:32 +0100
From: Lars Kurth <lars.kurth@xen.org>
User-Agent: Mozilla/5.0 (Windows NT 6.1;
	rv:15.0) Gecko/20120907 Thunderbird/15.0.1
MIME-Version: 1.0
To: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>, 
	"xen-api@lists.xen.org" <xen-api@lists.xen.org>, xen-users@lists.xen.org
Subject: [Xen-devel] Apache CloudStack Collaborotion Summit - Call for Xen
	Community Participation
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

Dear Community Members,

Apache CloudStack is holding it's first Collaboration Summit, Nov 30 - 
Dec 2, in Las Vegas. The event takes place immediately after the AWS re: 
Invent conference in the same location. As a large proportion of 
CloudStack users use XCP, it would be really good if our community had  
a presence. The type of contributions which make sense are: XCP 
introduction and XCP+CloudStack case studies.

Here is a little bit more information about the conference: "The 
Collaboration Conference will give CloudStack users an opportunity to 
learn about improvements in the upcoming Apache CloudStack 4.0 release, 
and best practices for deploying and managing CloudStack. Users will 
also be able to attend sessions on projects and tools that work well 
with CloudStack for configuration management, storage, monitoring, 
creating a Platform-as-a-Service (PaaS) on top of CloudStack, and more."

1) http://collab12.cloudstack.org/
2) http://collab12.cloudstack.org/proposals/ (Deadline Oct 5th)
3)http://cloudstack.org/blog/183-announcing-the-cloudstack-collaboration-conference-november-30-december-2%2C-2012-in-las-vegas.html

You can submit proposals directly via the cloudstack site above. However, if you need help with material (there is plenty, which can be re-used), support for travel, or maybe cannot make the CFP deadline, drop me a line and I will see what I can do.

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 Thu Sep 27 10:31:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Sep 2012 10:31:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1THBMp-0001O5-Rd; Thu, 27 Sep 2012 10:30:51 +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 1THBMo-0001Nl-KA
	for xen-devel@lists.xen.org; Thu, 27 Sep 2012 10:30:50 +0000
Received: from [85.158.143.99:2104] by server-1.bemta-4.messagelabs.com id
	D1/18-05684-9DA24605; Thu, 27 Sep 2012 10:30:49 +0000
X-Env-Sender: lars.kurth.xen@gmail.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1348741847!22363696!1
X-Originating-IP: [209.85.214.45]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
	ML_RADAR_SPEW_LINKS_23,RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31204 invoked from network); 27 Sep 2012 10:30:48 -0000
Received: from mail-bk0-f45.google.com (HELO mail-bk0-f45.google.com)
	(209.85.214.45)
	by server-14.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Sep 2012 10:30:48 -0000
Received: by bkcjf3 with SMTP id jf3so1002477bkc.32
	for <multiple recipients>; Thu, 27 Sep 2012 03:30:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:message-id:date:from:reply-to:user-agent:mime-version:to
	:subject:content-type:content-transfer-encoding;
	bh=RyWPaBVV5EKIt/pyKTe1/0Bs8HPukr02t3D1+RIvw9s=;
	b=KQLf4aMacCbwgbeyG+edywB1N/syJ/IhYsoebJDb7lFtFF0vBP2nP4rbfsEPFEiQ2y
	GWX1Hs6oeAtvt0Jkup0WMHaAu372reo7h2GHPyho2/cGc+D/2/T94xmPl8KMuVDb5U+G
	X+mrYy+MFA7wJSKuvEhVDLJ7UOeG9vhECQiqK8EzjppoxNUCtSpszbk5k0kH494tV/UV
	5d+KePeX2EszCqjd5QvAPj594Ne0xtLTuBGlF3A6lU70qemOzU4QpunsVXZSOF3vaxDm
	oPXDUoXJhUQEkP6TPDEn33tXS3Tb4Ij5jC/yfo+RzUqXKURBIkEwcyODqDZ/CeHcd8pb
	SN+w==
Received: by 10.204.155.133 with SMTP id s5mr1876405bkw.112.1348741847301;
	Thu, 27 Sep 2012 03:30:47 -0700 (PDT)
Received: from [172.16.26.11] (b0fb5b35.bb.sky.com. [176.251.91.53])
	by mx.google.com with ESMTPS id j24sm4168320bkv.0.2012.09.27.03.30.40
	(version=SSLv3 cipher=OTHER); Thu, 27 Sep 2012 03:30:46 -0700 (PDT)
Message-ID: <50642AC8.2070302@xen.org>
Date: Thu, 27 Sep 2012 11:30:32 +0100
From: Lars Kurth <lars.kurth@xen.org>
User-Agent: Mozilla/5.0 (Windows NT 6.1;
	rv:15.0) Gecko/20120907 Thunderbird/15.0.1
MIME-Version: 1.0
To: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>, 
	"xen-api@lists.xen.org" <xen-api@lists.xen.org>, xen-users@lists.xen.org
Subject: [Xen-devel] Apache CloudStack Collaborotion Summit - Call for Xen
	Community Participation
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

Dear Community Members,

Apache CloudStack is holding it's first Collaboration Summit, Nov 30 - 
Dec 2, in Las Vegas. The event takes place immediately after the AWS re: 
Invent conference in the same location. As a large proportion of 
CloudStack users use XCP, it would be really good if our community had  
a presence. The type of contributions which make sense are: XCP 
introduction and XCP+CloudStack case studies.

Here is a little bit more information about the conference: "The 
Collaboration Conference will give CloudStack users an opportunity to 
learn about improvements in the upcoming Apache CloudStack 4.0 release, 
and best practices for deploying and managing CloudStack. Users will 
also be able to attend sessions on projects and tools that work well 
with CloudStack for configuration management, storage, monitoring, 
creating a Platform-as-a-Service (PaaS) on top of CloudStack, and more."

1) http://collab12.cloudstack.org/
2) http://collab12.cloudstack.org/proposals/ (Deadline Oct 5th)
3)http://cloudstack.org/blog/183-announcing-the-cloudstack-collaboration-conference-november-30-december-2%2C-2012-in-las-vegas.html

You can submit proposals directly via the cloudstack site above. However, if you need help with material (there is plenty, which can be re-used), support for travel, or maybe cannot make the CFP deadline, drop me a line and I will see what I can do.

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 Thu Sep 27 11:13:23 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Sep 2012 11:13:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1THC1i-0002QQ-38; Thu, 27 Sep 2012 11:13:06 +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 1THC1f-0002Pd-NQ
	for xen-devel@lists.xen.org; Thu, 27 Sep 2012 11:13:04 +0000
Received: from [85.158.138.51:46807] by server-3.bemta-3.messagelabs.com id
	96/84-25962-EB434605; Thu, 27 Sep 2012 11:13:02 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1348744378!30394415!4
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzE5Njc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31702 invoked from network); 27 Sep 2012 11:13:02 -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;
	27 Sep 2012 11:13:02 -0000
X-IronPort-AV: E=Sophos;i="4.80,495,1344211200"; d="scan'208";a="39351829"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Sep 2012 11:12:42 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1;
	Thu, 27 Sep 2012 07:12:41 -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 1THC1J-0000pN-Eb;
	Thu, 27 Sep 2012 12:12:41 +0100
From: Anthony PERARD <anthony.perard@citrix.com>
To: QEMU-devel <qemu-devel@nongnu.org>,
	Stefano Stabellini <stefano.stabellini@citrix.com>
Date: Thu, 27 Sep 2012 12:12:37 +0100
Message-ID: <1348744360-2989-3-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.12.1
In-Reply-To: <1348744360-2989-1-git-send-email-anthony.perard@citrix.com>
References: <1348744360-2989-1-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Cc: Anthony PERARD <anthony.perard@citrix.com>,
	Xen Devel <xen-devel@lists.xen.org>
Subject: [Xen-devel] [PATCH V4 2/5] xen: Introduce xen_modified_memory.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This function is to be used during live migration. Every write access to the
guest memory should call this funcion so the Xen tools knows which pages are
dirty.

Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
 hw/xen.h   |  1 +
 xen-all.c  | 21 +++++++++++++++++++++
 xen-stub.c |  4 ++++
 3 files changed, 26 insertions(+)

diff --git a/hw/xen.h b/hw/xen.h
index e5926b7..d14e92d 100644
--- a/hw/xen.h
+++ b/hw/xen.h
@@ -48,6 +48,7 @@ void xenstore_store_pv_console_info(int i, struct CharDriverState *chr);
 struct MemoryRegion;
 void xen_ram_alloc(ram_addr_t ram_addr, ram_addr_t size,
                    struct MemoryRegion *mr);
+void xen_modified_memory(ram_addr_t start, ram_addr_t length);
 #endif
 
 struct MemoryRegion;
diff --git a/xen-all.c b/xen-all.c
index f75ae9f..b11542c 100644
--- a/xen-all.c
+++ b/xen-all.c
@@ -1228,3 +1228,24 @@ void xen_shutdown_fatal_error(const char *fmt, ...)
     /* destroy the domain */
     qemu_system_shutdown_request();
 }
+
+void xen_modified_memory(ram_addr_t start, ram_addr_t length)
+{
+    if (unlikely(xen_in_migration)) {
+        int rc;
+        ram_addr_t start_pfn, nb_pages;
+
+        if (length == 0) {
+            length = TARGET_PAGE_SIZE;
+        }
+        start_pfn = start >> TARGET_PAGE_BITS;
+        nb_pages = ((start + length + TARGET_PAGE_SIZE - 1) >> TARGET_PAGE_BITS)
+            - start_pfn;
+        rc = xc_hvm_modified_memory(xen_xc, xen_domid, start_pfn, nb_pages);
+        if (rc) {
+            fprintf(stderr,
+                    "%s failed for "RAM_ADDR_FMT" ("RAM_ADDR_FMT"): %i, %s\n",
+                    __func__, start, nb_pages, rc, strerror(-rc));
+        }
+    }
+}
diff --git a/xen-stub.c b/xen-stub.c
index 5e66ba8..9214392 100644
--- a/xen-stub.c
+++ b/xen-stub.c
@@ -59,3 +59,7 @@ void xen_register_framebuffer(MemoryRegion *mr)
 void qmp_xen_set_global_dirty_log(bool enable, Error **errp)
 {
 }
+
+void xen_modified_memory(ram_addr_t start, ram_addr_t length)
+{
+}
-- 
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 Sep 27 11:13:23 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Sep 2012 11:13:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1THC1i-0002QQ-38; Thu, 27 Sep 2012 11:13:06 +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 1THC1f-0002Pd-NQ
	for xen-devel@lists.xen.org; Thu, 27 Sep 2012 11:13:04 +0000
Received: from [85.158.138.51:46807] by server-3.bemta-3.messagelabs.com id
	96/84-25962-EB434605; Thu, 27 Sep 2012 11:13:02 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1348744378!30394415!4
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzE5Njc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31702 invoked from network); 27 Sep 2012 11:13:02 -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;
	27 Sep 2012 11:13:02 -0000
X-IronPort-AV: E=Sophos;i="4.80,495,1344211200"; d="scan'208";a="39351829"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Sep 2012 11:12:42 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1;
	Thu, 27 Sep 2012 07:12:41 -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 1THC1J-0000pN-Eb;
	Thu, 27 Sep 2012 12:12:41 +0100
From: Anthony PERARD <anthony.perard@citrix.com>
To: QEMU-devel <qemu-devel@nongnu.org>,
	Stefano Stabellini <stefano.stabellini@citrix.com>
Date: Thu, 27 Sep 2012 12:12:37 +0100
Message-ID: <1348744360-2989-3-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.12.1
In-Reply-To: <1348744360-2989-1-git-send-email-anthony.perard@citrix.com>
References: <1348744360-2989-1-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Cc: Anthony PERARD <anthony.perard@citrix.com>,
	Xen Devel <xen-devel@lists.xen.org>
Subject: [Xen-devel] [PATCH V4 2/5] xen: Introduce xen_modified_memory.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This function is to be used during live migration. Every write access to the
guest memory should call this funcion so the Xen tools knows which pages are
dirty.

Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
 hw/xen.h   |  1 +
 xen-all.c  | 21 +++++++++++++++++++++
 xen-stub.c |  4 ++++
 3 files changed, 26 insertions(+)

diff --git a/hw/xen.h b/hw/xen.h
index e5926b7..d14e92d 100644
--- a/hw/xen.h
+++ b/hw/xen.h
@@ -48,6 +48,7 @@ void xenstore_store_pv_console_info(int i, struct CharDriverState *chr);
 struct MemoryRegion;
 void xen_ram_alloc(ram_addr_t ram_addr, ram_addr_t size,
                    struct MemoryRegion *mr);
+void xen_modified_memory(ram_addr_t start, ram_addr_t length);
 #endif
 
 struct MemoryRegion;
diff --git a/xen-all.c b/xen-all.c
index f75ae9f..b11542c 100644
--- a/xen-all.c
+++ b/xen-all.c
@@ -1228,3 +1228,24 @@ void xen_shutdown_fatal_error(const char *fmt, ...)
     /* destroy the domain */
     qemu_system_shutdown_request();
 }
+
+void xen_modified_memory(ram_addr_t start, ram_addr_t length)
+{
+    if (unlikely(xen_in_migration)) {
+        int rc;
+        ram_addr_t start_pfn, nb_pages;
+
+        if (length == 0) {
+            length = TARGET_PAGE_SIZE;
+        }
+        start_pfn = start >> TARGET_PAGE_BITS;
+        nb_pages = ((start + length + TARGET_PAGE_SIZE - 1) >> TARGET_PAGE_BITS)
+            - start_pfn;
+        rc = xc_hvm_modified_memory(xen_xc, xen_domid, start_pfn, nb_pages);
+        if (rc) {
+            fprintf(stderr,
+                    "%s failed for "RAM_ADDR_FMT" ("RAM_ADDR_FMT"): %i, %s\n",
+                    __func__, start, nb_pages, rc, strerror(-rc));
+        }
+    }
+}
diff --git a/xen-stub.c b/xen-stub.c
index 5e66ba8..9214392 100644
--- a/xen-stub.c
+++ b/xen-stub.c
@@ -59,3 +59,7 @@ void xen_register_framebuffer(MemoryRegion *mr)
 void qmp_xen_set_global_dirty_log(bool enable, Error **errp)
 {
 }
+
+void xen_modified_memory(ram_addr_t start, ram_addr_t length)
+{
+}
-- 
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 Sep 27 11:13:23 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Sep 2012 11:13:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1THC1h-0002Q7-BJ; Thu, 27 Sep 2012 11:13:05 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony.perard@citrix.com>) id 1THC1f-0002PU-2I
	for xen-devel@lists.xen.org; Thu, 27 Sep 2012 11:13:03 +0000
Received: from [85.158.138.51:46747] by server-6.bemta-3.messagelabs.com id
	EB/FC-11085-EB434605; Thu, 27 Sep 2012 11:13:02 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1348744378!30394415!3
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzE5Njc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31627 invoked from network); 27 Sep 2012 11:13:01 -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;
	27 Sep 2012 11:13:01 -0000
X-IronPort-AV: E=Sophos;i="4.80,495,1344211200"; d="scan'208";a="39351827"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Sep 2012 11:12:42 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1;
	Thu, 27 Sep 2012 07:12:41 -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 1THC1J-0000pN-Ev;
	Thu, 27 Sep 2012 12:12:41 +0100
From: Anthony PERARD <anthony.perard@citrix.com>
To: QEMU-devel <qemu-devel@nongnu.org>,
	Stefano Stabellini <stefano.stabellini@citrix.com>
Date: Thu, 27 Sep 2012 12:12:38 +0100
Message-ID: <1348744360-2989-4-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.12.1
In-Reply-To: <1348744360-2989-1-git-send-email-anthony.perard@citrix.com>
References: <1348744360-2989-1-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Cc: Anthony PERARD <anthony.perard@citrix.com>,
	Xen Devel <xen-devel@lists.xen.org>
Subject: [Xen-devel] [PATCH V4 3/5] exec: Introduce helper to set dirty
	flags.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This new helper/hook is used in the next patch to add an extra call in a single
place.

Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Reviewed-by: Avi Kivity <avi@redhat.com>
---
 exec.c | 52 +++++++++++++++++-----------------------------------
 1 file changed, 17 insertions(+), 35 deletions(-)

diff --git a/exec.c b/exec.c
index bb6aa4a..366684c 100644
--- a/exec.c
+++ b/exec.c
@@ -3417,6 +3417,18 @@ int cpu_memory_rw_debug(CPUArchState *env, target_ulong addr,
 }
 
 #else
+
+static void invalidate_and_set_dirty(target_phys_addr_t addr,
+                                     target_phys_addr_t length)
+{
+    if (!cpu_physical_memory_is_dirty(addr)) {
+        /* invalidate code */
+        tb_invalidate_phys_page_range(addr, addr + length, 0);
+        /* set dirty bit */
+        cpu_physical_memory_set_dirty_flags(addr, (0xff & ~CODE_DIRTY_FLAG));
+    }
+}
+
 void cpu_physical_memory_rw(target_phys_addr_t addr, uint8_t *buf,
                             int len, int is_write)
 {
@@ -3462,13 +3474,7 @@ void cpu_physical_memory_rw(target_phys_addr_t addr, uint8_t *buf,
                 /* RAM case */
                 ptr = qemu_get_ram_ptr(addr1);
                 memcpy(ptr, buf, l);
-                if (!cpu_physical_memory_is_dirty(addr1)) {
-                    /* invalidate code */
-                    tb_invalidate_phys_page_range(addr1, addr1 + l, 0);
-                    /* set dirty bit */
-                    cpu_physical_memory_set_dirty_flags(
-                        addr1, (0xff & ~CODE_DIRTY_FLAG));
-                }
+                invalidate_and_set_dirty(addr1, l);
                 qemu_put_ram_ptr(ptr);
             }
         } else {
@@ -3534,13 +3540,7 @@ void cpu_physical_memory_write_rom(target_phys_addr_t addr,
             /* ROM/RAM case */
             ptr = qemu_get_ram_ptr(addr1);
             memcpy(ptr, buf, l);
-            if (!cpu_physical_memory_is_dirty(addr1)) {
-                /* invalidate code */
-                tb_invalidate_phys_page_range(addr1, addr1 + l, 0);
-                /* set dirty bit */
-                cpu_physical_memory_set_dirty_flags(
-                    addr1, (0xff & ~CODE_DIRTY_FLAG));
-            }
+            invalidate_and_set_dirty(addr1, l);
             qemu_put_ram_ptr(ptr);
         }
         len -= l;
@@ -3666,13 +3666,7 @@ void cpu_physical_memory_unmap(void *buffer, target_phys_addr_t len,
                 l = TARGET_PAGE_SIZE;
                 if (l > access_len)
                     l = access_len;
-                if (!cpu_physical_memory_is_dirty(addr1)) {
-                    /* invalidate code */
-                    tb_invalidate_phys_page_range(addr1, addr1 + l, 0);
-                    /* set dirty bit */
-                    cpu_physical_memory_set_dirty_flags(
-                        addr1, (0xff & ~CODE_DIRTY_FLAG));
-                }
+                invalidate_and_set_dirty(addr1, l);
                 addr1 += l;
                 access_len -= l;
             }
@@ -3978,13 +3972,7 @@ static inline void stl_phys_internal(target_phys_addr_t addr, uint32_t val,
             stl_p(ptr, val);
             break;
         }
-        if (!cpu_physical_memory_is_dirty(addr1)) {
-            /* invalidate code */
-            tb_invalidate_phys_page_range(addr1, addr1 + 4, 0);
-            /* set dirty bit */
-            cpu_physical_memory_set_dirty_flags(addr1,
-                (0xff & ~CODE_DIRTY_FLAG));
-        }
+        invalidate_and_set_dirty(addr1, 4);
     }
 }
 
@@ -4051,13 +4039,7 @@ static inline void stw_phys_internal(target_phys_addr_t addr, uint32_t val,
             stw_p(ptr, val);
             break;
         }
-        if (!cpu_physical_memory_is_dirty(addr1)) {
-            /* invalidate code */
-            tb_invalidate_phys_page_range(addr1, addr1 + 2, 0);
-            /* set dirty bit */
-            cpu_physical_memory_set_dirty_flags(addr1,
-                (0xff & ~CODE_DIRTY_FLAG));
-        }
+        invalidate_and_set_dirty(addr1, 2);
     }
 }
 
-- 
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 Sep 27 11:13:23 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Sep 2012 11:13:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1THC1h-0002Q7-BJ; Thu, 27 Sep 2012 11:13:05 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony.perard@citrix.com>) id 1THC1f-0002PU-2I
	for xen-devel@lists.xen.org; Thu, 27 Sep 2012 11:13:03 +0000
Received: from [85.158.138.51:46747] by server-6.bemta-3.messagelabs.com id
	EB/FC-11085-EB434605; Thu, 27 Sep 2012 11:13:02 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1348744378!30394415!3
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzE5Njc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31627 invoked from network); 27 Sep 2012 11:13:01 -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;
	27 Sep 2012 11:13:01 -0000
X-IronPort-AV: E=Sophos;i="4.80,495,1344211200"; d="scan'208";a="39351827"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Sep 2012 11:12:42 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1;
	Thu, 27 Sep 2012 07:12:41 -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 1THC1J-0000pN-Ev;
	Thu, 27 Sep 2012 12:12:41 +0100
From: Anthony PERARD <anthony.perard@citrix.com>
To: QEMU-devel <qemu-devel@nongnu.org>,
	Stefano Stabellini <stefano.stabellini@citrix.com>
Date: Thu, 27 Sep 2012 12:12:38 +0100
Message-ID: <1348744360-2989-4-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.12.1
In-Reply-To: <1348744360-2989-1-git-send-email-anthony.perard@citrix.com>
References: <1348744360-2989-1-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Cc: Anthony PERARD <anthony.perard@citrix.com>,
	Xen Devel <xen-devel@lists.xen.org>
Subject: [Xen-devel] [PATCH V4 3/5] exec: Introduce helper to set dirty
	flags.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This new helper/hook is used in the next patch to add an extra call in a single
place.

Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Reviewed-by: Avi Kivity <avi@redhat.com>
---
 exec.c | 52 +++++++++++++++++-----------------------------------
 1 file changed, 17 insertions(+), 35 deletions(-)

diff --git a/exec.c b/exec.c
index bb6aa4a..366684c 100644
--- a/exec.c
+++ b/exec.c
@@ -3417,6 +3417,18 @@ int cpu_memory_rw_debug(CPUArchState *env, target_ulong addr,
 }
 
 #else
+
+static void invalidate_and_set_dirty(target_phys_addr_t addr,
+                                     target_phys_addr_t length)
+{
+    if (!cpu_physical_memory_is_dirty(addr)) {
+        /* invalidate code */
+        tb_invalidate_phys_page_range(addr, addr + length, 0);
+        /* set dirty bit */
+        cpu_physical_memory_set_dirty_flags(addr, (0xff & ~CODE_DIRTY_FLAG));
+    }
+}
+
 void cpu_physical_memory_rw(target_phys_addr_t addr, uint8_t *buf,
                             int len, int is_write)
 {
@@ -3462,13 +3474,7 @@ void cpu_physical_memory_rw(target_phys_addr_t addr, uint8_t *buf,
                 /* RAM case */
                 ptr = qemu_get_ram_ptr(addr1);
                 memcpy(ptr, buf, l);
-                if (!cpu_physical_memory_is_dirty(addr1)) {
-                    /* invalidate code */
-                    tb_invalidate_phys_page_range(addr1, addr1 + l, 0);
-                    /* set dirty bit */
-                    cpu_physical_memory_set_dirty_flags(
-                        addr1, (0xff & ~CODE_DIRTY_FLAG));
-                }
+                invalidate_and_set_dirty(addr1, l);
                 qemu_put_ram_ptr(ptr);
             }
         } else {
@@ -3534,13 +3540,7 @@ void cpu_physical_memory_write_rom(target_phys_addr_t addr,
             /* ROM/RAM case */
             ptr = qemu_get_ram_ptr(addr1);
             memcpy(ptr, buf, l);
-            if (!cpu_physical_memory_is_dirty(addr1)) {
-                /* invalidate code */
-                tb_invalidate_phys_page_range(addr1, addr1 + l, 0);
-                /* set dirty bit */
-                cpu_physical_memory_set_dirty_flags(
-                    addr1, (0xff & ~CODE_DIRTY_FLAG));
-            }
+            invalidate_and_set_dirty(addr1, l);
             qemu_put_ram_ptr(ptr);
         }
         len -= l;
@@ -3666,13 +3666,7 @@ void cpu_physical_memory_unmap(void *buffer, target_phys_addr_t len,
                 l = TARGET_PAGE_SIZE;
                 if (l > access_len)
                     l = access_len;
-                if (!cpu_physical_memory_is_dirty(addr1)) {
-                    /* invalidate code */
-                    tb_invalidate_phys_page_range(addr1, addr1 + l, 0);
-                    /* set dirty bit */
-                    cpu_physical_memory_set_dirty_flags(
-                        addr1, (0xff & ~CODE_DIRTY_FLAG));
-                }
+                invalidate_and_set_dirty(addr1, l);
                 addr1 += l;
                 access_len -= l;
             }
@@ -3978,13 +3972,7 @@ static inline void stl_phys_internal(target_phys_addr_t addr, uint32_t val,
             stl_p(ptr, val);
             break;
         }
-        if (!cpu_physical_memory_is_dirty(addr1)) {
-            /* invalidate code */
-            tb_invalidate_phys_page_range(addr1, addr1 + 4, 0);
-            /* set dirty bit */
-            cpu_physical_memory_set_dirty_flags(addr1,
-                (0xff & ~CODE_DIRTY_FLAG));
-        }
+        invalidate_and_set_dirty(addr1, 4);
     }
 }
 
@@ -4051,13 +4039,7 @@ static inline void stw_phys_internal(target_phys_addr_t addr, uint32_t val,
             stw_p(ptr, val);
             break;
         }
-        if (!cpu_physical_memory_is_dirty(addr1)) {
-            /* invalidate code */
-            tb_invalidate_phys_page_range(addr1, addr1 + 2, 0);
-            /* set dirty bit */
-            cpu_physical_memory_set_dirty_flags(addr1,
-                (0xff & ~CODE_DIRTY_FLAG));
-        }
+        invalidate_and_set_dirty(addr1, 2);
     }
 }
 
-- 
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 Sep 27 11:13:23 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Sep 2012 11:13:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1THC1f-0002Po-Vr; Thu, 27 Sep 2012 11:13:03 +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 1THC1d-0002PL-V7
	for xen-devel@lists.xen.org; Thu, 27 Sep 2012 11:13:02 +0000
Received: from [85.158.138.51:62838] by server-8.bemta-3.messagelabs.com id
	3B/97-16337-DB434605; Thu, 27 Sep 2012 11:13:01 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1348744378!30394415!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzE5Njc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31556 invoked from network); 27 Sep 2012 11:13:00 -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;
	27 Sep 2012 11:13:00 -0000
X-IronPort-AV: E=Sophos;i="4.80,495,1344211200"; d="scan'208";a="39351828"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Sep 2012 11:12:42 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1;
	Thu, 27 Sep 2012 07:12:41 -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 1THC1J-0000pN-Cx;
	Thu, 27 Sep 2012 12:12:41 +0100
From: Anthony PERARD <anthony.perard@citrix.com>
To: QEMU-devel <qemu-devel@nongnu.org>,
	Stefano Stabellini <stefano.stabellini@citrix.com>
Date: Thu, 27 Sep 2012 12:12:36 +0100
Message-ID: <1348744360-2989-2-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.12.1
In-Reply-To: <1348744360-2989-1-git-send-email-anthony.perard@citrix.com>
References: <1348744360-2989-1-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Cc: Anthony PERARD <anthony.perard@citrix.com>,
	Xen Devel <xen-devel@lists.xen.org>
Subject: [Xen-devel] [PATCH V4 1/5] QMP,
	Introduce xen-set-global-dirty-log command.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This command is used during a migration of a guest under Xen. It calls
memory_global_dirty_log_start or memory_global_dirty_log_stop according to the
argument pass to the command.

Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Reviewed-by: Luiz Capitulino <lcapitulino@redhat.com>
---
 qapi-schema.json | 13 +++++++++++++
 qmp-commands.hx  | 24 ++++++++++++++++++++++++
 xen-all.c        | 15 +++++++++++++++
 xen-stub.c       |  5 +++++
 4 files changed, 57 insertions(+)

diff --git a/qapi-schema.json b/qapi-schema.json
index 14e4419..696f45a 100644
--- a/qapi-schema.json
+++ b/qapi-schema.json
@@ -1956,6 +1956,19 @@
 { 'command': 'xen-save-devices-state', 'data': {'filename': 'str'} }
 
 ##
+# @xen-set-global-dirty-log
+#
+# Enable or disable the global dirty log mode.
+#
+# @enable: true to enable, false to disable.
+#
+# Returns: nothing
+#
+# Since: 1.2
+##
+{ 'command': 'xen-set-global-dirty-log', 'data': { 'enable': 'bool' } }
+
+##
 # @device_del:
 #
 # Remove a device from a guest
diff --git a/qmp-commands.hx b/qmp-commands.hx
index 6e21ddb..662b7cf 100644
--- a/qmp-commands.hx
+++ b/qmp-commands.hx
@@ -493,6 +493,30 @@ Example:
 EQMP
 
     {
+        .name       = "xen-set-global-dirty-log",
+        .args_type  = "enable:b",
+        .mhandler.cmd_new = qmp_marshal_input_xen_set_global_dirty_log,
+    },
+
+SQMP
+xen-set-global-dirty-log
+-------
+
+Enable or disable the global dirty log mode.
+
+Arguments:
+
+- "enable": Enable it or disable it.
+
+Example:
+
+-> { "execute": "xen-set-global-dirty-log",
+     "arguments": { "enable": true } }
+<- { "return": {} }
+
+EQMP
+
+    {
         .name       = "migrate",
         .args_type  = "detach:-d,blk:-b,inc:-i,uri:s",
         .mhandler.cmd_new = qmp_marshal_input_migrate,
diff --git a/xen-all.c b/xen-all.c
index f76b051..f75ae9f 100644
--- a/xen-all.c
+++ b/xen-all.c
@@ -14,6 +14,7 @@
 #include "hw/pc.h"
 #include "hw/xen_common.h"
 #include "hw/xen_backend.h"
+#include "qmp-commands.h"
 
 #include "range.h"
 #include "xen-mapcache.h"
@@ -36,6 +37,7 @@
 
 static MemoryRegion ram_memory, ram_640k, ram_lo, ram_hi;
 static MemoryRegion *framebuffer;
+static bool xen_in_migration;
 
 /* Compatibility with older version */
 #if __XEN_LATEST_INTERFACE_VERSION__ < 0x0003020a
@@ -552,10 +554,14 @@ static void xen_log_sync(MemoryListener *listener, MemoryRegionSection *section)
 
 static void xen_log_global_start(MemoryListener *listener)
 {
+    if (xen_enabled()) {
+        xen_in_migration = true;
+    }
 }
 
 static void xen_log_global_stop(MemoryListener *listener)
 {
+    xen_in_migration = false;
 }
 
 static void xen_eventfd_add(MemoryListener *listener,
@@ -588,6 +594,15 @@ static MemoryListener xen_memory_listener = {
     .priority = 10,
 };
 
+void qmp_xen_set_global_dirty_log(bool enable, Error **errp)
+{
+    if (enable) {
+        memory_global_dirty_log_start();
+    } else {
+        memory_global_dirty_log_stop();
+    }
+}
+
 /* VCPU Operations, MMIO, IO ring ... */
 
 static void xen_reset_vcpu(void *opaque)
diff --git a/xen-stub.c b/xen-stub.c
index 8ff2b79..5e66ba8 100644
--- a/xen-stub.c
+++ b/xen-stub.c
@@ -11,6 +11,7 @@
 #include "qemu-common.h"
 #include "hw/xen.h"
 #include "memory.h"
+#include "qmp-commands.h"
 
 void xenstore_store_pv_console_info(int i, CharDriverState *chr)
 {
@@ -54,3 +55,7 @@ int xen_init(void)
 void xen_register_framebuffer(MemoryRegion *mr)
 {
 }
+
+void qmp_xen_set_global_dirty_log(bool enable, Error **errp)
+{
+}
-- 
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 Sep 27 11:13:23 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Sep 2012 11:13:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1THC1f-0002Po-Vr; Thu, 27 Sep 2012 11:13:03 +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 1THC1d-0002PL-V7
	for xen-devel@lists.xen.org; Thu, 27 Sep 2012 11:13:02 +0000
Received: from [85.158.138.51:62838] by server-8.bemta-3.messagelabs.com id
	3B/97-16337-DB434605; Thu, 27 Sep 2012 11:13:01 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1348744378!30394415!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzE5Njc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31556 invoked from network); 27 Sep 2012 11:13:00 -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;
	27 Sep 2012 11:13:00 -0000
X-IronPort-AV: E=Sophos;i="4.80,495,1344211200"; d="scan'208";a="39351828"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Sep 2012 11:12:42 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1;
	Thu, 27 Sep 2012 07:12:41 -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 1THC1J-0000pN-Cx;
	Thu, 27 Sep 2012 12:12:41 +0100
From: Anthony PERARD <anthony.perard@citrix.com>
To: QEMU-devel <qemu-devel@nongnu.org>,
	Stefano Stabellini <stefano.stabellini@citrix.com>
Date: Thu, 27 Sep 2012 12:12:36 +0100
Message-ID: <1348744360-2989-2-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.12.1
In-Reply-To: <1348744360-2989-1-git-send-email-anthony.perard@citrix.com>
References: <1348744360-2989-1-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Cc: Anthony PERARD <anthony.perard@citrix.com>,
	Xen Devel <xen-devel@lists.xen.org>
Subject: [Xen-devel] [PATCH V4 1/5] QMP,
	Introduce xen-set-global-dirty-log command.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This command is used during a migration of a guest under Xen. It calls
memory_global_dirty_log_start or memory_global_dirty_log_stop according to the
argument pass to the command.

Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Reviewed-by: Luiz Capitulino <lcapitulino@redhat.com>
---
 qapi-schema.json | 13 +++++++++++++
 qmp-commands.hx  | 24 ++++++++++++++++++++++++
 xen-all.c        | 15 +++++++++++++++
 xen-stub.c       |  5 +++++
 4 files changed, 57 insertions(+)

diff --git a/qapi-schema.json b/qapi-schema.json
index 14e4419..696f45a 100644
--- a/qapi-schema.json
+++ b/qapi-schema.json
@@ -1956,6 +1956,19 @@
 { 'command': 'xen-save-devices-state', 'data': {'filename': 'str'} }
 
 ##
+# @xen-set-global-dirty-log
+#
+# Enable or disable the global dirty log mode.
+#
+# @enable: true to enable, false to disable.
+#
+# Returns: nothing
+#
+# Since: 1.2
+##
+{ 'command': 'xen-set-global-dirty-log', 'data': { 'enable': 'bool' } }
+
+##
 # @device_del:
 #
 # Remove a device from a guest
diff --git a/qmp-commands.hx b/qmp-commands.hx
index 6e21ddb..662b7cf 100644
--- a/qmp-commands.hx
+++ b/qmp-commands.hx
@@ -493,6 +493,30 @@ Example:
 EQMP
 
     {
+        .name       = "xen-set-global-dirty-log",
+        .args_type  = "enable:b",
+        .mhandler.cmd_new = qmp_marshal_input_xen_set_global_dirty_log,
+    },
+
+SQMP
+xen-set-global-dirty-log
+-------
+
+Enable or disable the global dirty log mode.
+
+Arguments:
+
+- "enable": Enable it or disable it.
+
+Example:
+
+-> { "execute": "xen-set-global-dirty-log",
+     "arguments": { "enable": true } }
+<- { "return": {} }
+
+EQMP
+
+    {
         .name       = "migrate",
         .args_type  = "detach:-d,blk:-b,inc:-i,uri:s",
         .mhandler.cmd_new = qmp_marshal_input_migrate,
diff --git a/xen-all.c b/xen-all.c
index f76b051..f75ae9f 100644
--- a/xen-all.c
+++ b/xen-all.c
@@ -14,6 +14,7 @@
 #include "hw/pc.h"
 #include "hw/xen_common.h"
 #include "hw/xen_backend.h"
+#include "qmp-commands.h"
 
 #include "range.h"
 #include "xen-mapcache.h"
@@ -36,6 +37,7 @@
 
 static MemoryRegion ram_memory, ram_640k, ram_lo, ram_hi;
 static MemoryRegion *framebuffer;
+static bool xen_in_migration;
 
 /* Compatibility with older version */
 #if __XEN_LATEST_INTERFACE_VERSION__ < 0x0003020a
@@ -552,10 +554,14 @@ static void xen_log_sync(MemoryListener *listener, MemoryRegionSection *section)
 
 static void xen_log_global_start(MemoryListener *listener)
 {
+    if (xen_enabled()) {
+        xen_in_migration = true;
+    }
 }
 
 static void xen_log_global_stop(MemoryListener *listener)
 {
+    xen_in_migration = false;
 }
 
 static void xen_eventfd_add(MemoryListener *listener,
@@ -588,6 +594,15 @@ static MemoryListener xen_memory_listener = {
     .priority = 10,
 };
 
+void qmp_xen_set_global_dirty_log(bool enable, Error **errp)
+{
+    if (enable) {
+        memory_global_dirty_log_start();
+    } else {
+        memory_global_dirty_log_stop();
+    }
+}
+
 /* VCPU Operations, MMIO, IO ring ... */
 
 static void xen_reset_vcpu(void *opaque)
diff --git a/xen-stub.c b/xen-stub.c
index 8ff2b79..5e66ba8 100644
--- a/xen-stub.c
+++ b/xen-stub.c
@@ -11,6 +11,7 @@
 #include "qemu-common.h"
 #include "hw/xen.h"
 #include "memory.h"
+#include "qmp-commands.h"
 
 void xenstore_store_pv_console_info(int i, CharDriverState *chr)
 {
@@ -54,3 +55,7 @@ int xen_init(void)
 void xen_register_framebuffer(MemoryRegion *mr)
 {
 }
+
+void qmp_xen_set_global_dirty_log(bool enable, Error **errp)
+{
+}
-- 
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 Sep 27 11:13:23 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Sep 2012 11:13:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1THC1i-0002QZ-Gb; Thu, 27 Sep 2012 11:13:06 +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 1THC1f-0002Pi-T8
	for xen-devel@lists.xen.org; Thu, 27 Sep 2012 11:13:04 +0000
Received: from [85.158.139.83:64749] by server-13.bemta-5.messagelabs.com id
	7C/A9-16359-FB434605; Thu, 27 Sep 2012 11:13:03 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1348744380!31828884!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzE5Njc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 581 invoked from network); 27 Sep 2012 11:13:02 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-13.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Sep 2012 11:13:02 -0000
X-IronPort-AV: E=Sophos;i="4.80,495,1344211200"; d="scan'208";a="39351830"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Sep 2012 11:12:42 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1;
	Thu, 27 Sep 2012 07:12:41 -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 1THC1J-0000pN-FZ;
	Thu, 27 Sep 2012 12:12:41 +0100
From: Anthony PERARD <anthony.perard@citrix.com>
To: QEMU-devel <qemu-devel@nongnu.org>,
	Stefano Stabellini <stefano.stabellini@citrix.com>
Date: Thu, 27 Sep 2012 12:12:40 +0100
Message-ID: <1348744360-2989-6-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.12.1
In-Reply-To: <1348744360-2989-1-git-send-email-anthony.perard@citrix.com>
References: <1348744360-2989-1-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Cc: Anthony PERARD <anthony.perard@citrix.com>,
	Xen Devel <xen-devel@lists.xen.org>
Subject: [Xen-devel] [PATCH V4 5/5] xen: Set the vram dirty when an error
	occur.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

If the call to xc_hvm_track_dirty_vram() fails, then we set dirtybit on all the
video ram. This case happens during migration.

Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
 xen-all.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/xen-all.c b/xen-all.c
index b11542c..e6308be 100644
--- a/xen-all.c
+++ b/xen-all.c
@@ -507,7 +507,8 @@ static void xen_sync_dirty_bitmap(XenIOState *state,
                                  bitmap);
     if (rc < 0) {
         if (rc != -ENODATA) {
-            fprintf(stderr, "xen: track_dirty_vram failed (0x" TARGET_FMT_plx
+            memory_region_set_dirty(framebuffer, 0, size);
+            DPRINTF("xen: track_dirty_vram failed (0x" TARGET_FMT_plx
                     ", 0x" TARGET_FMT_plx "): %s\n",
                     start_addr, start_addr + size, strerror(-rc));
         }
-- 
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 Sep 27 11:13:23 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Sep 2012 11:13:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1THC1i-0002QZ-Gb; Thu, 27 Sep 2012 11:13:06 +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 1THC1f-0002Pi-T8
	for xen-devel@lists.xen.org; Thu, 27 Sep 2012 11:13:04 +0000
Received: from [85.158.139.83:64749] by server-13.bemta-5.messagelabs.com id
	7C/A9-16359-FB434605; Thu, 27 Sep 2012 11:13:03 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1348744380!31828884!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzE5Njc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 581 invoked from network); 27 Sep 2012 11:13:02 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-13.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Sep 2012 11:13:02 -0000
X-IronPort-AV: E=Sophos;i="4.80,495,1344211200"; d="scan'208";a="39351830"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Sep 2012 11:12:42 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1;
	Thu, 27 Sep 2012 07:12:41 -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 1THC1J-0000pN-FZ;
	Thu, 27 Sep 2012 12:12:41 +0100
From: Anthony PERARD <anthony.perard@citrix.com>
To: QEMU-devel <qemu-devel@nongnu.org>,
	Stefano Stabellini <stefano.stabellini@citrix.com>
Date: Thu, 27 Sep 2012 12:12:40 +0100
Message-ID: <1348744360-2989-6-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.12.1
In-Reply-To: <1348744360-2989-1-git-send-email-anthony.perard@citrix.com>
References: <1348744360-2989-1-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Cc: Anthony PERARD <anthony.perard@citrix.com>,
	Xen Devel <xen-devel@lists.xen.org>
Subject: [Xen-devel] [PATCH V4 5/5] xen: Set the vram dirty when an error
	occur.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

If the call to xc_hvm_track_dirty_vram() fails, then we set dirtybit on all the
video ram. This case happens during migration.

Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
 xen-all.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/xen-all.c b/xen-all.c
index b11542c..e6308be 100644
--- a/xen-all.c
+++ b/xen-all.c
@@ -507,7 +507,8 @@ static void xen_sync_dirty_bitmap(XenIOState *state,
                                  bitmap);
     if (rc < 0) {
         if (rc != -ENODATA) {
-            fprintf(stderr, "xen: track_dirty_vram failed (0x" TARGET_FMT_plx
+            memory_region_set_dirty(framebuffer, 0, size);
+            DPRINTF("xen: track_dirty_vram failed (0x" TARGET_FMT_plx
                     ", 0x" TARGET_FMT_plx "): %s\n",
                     start_addr, start_addr + size, strerror(-rc));
         }
-- 
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 Sep 27 11:13:23 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Sep 2012 11:13:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1THC1h-0002QF-NA; Thu, 27 Sep 2012 11:13:05 +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 1THC1f-0002Pa-8Z
	for xen-devel@lists.xen.org; Thu, 27 Sep 2012 11:13:03 +0000
Received: from [85.158.139.83:64699] by server-16.bemta-5.messagelabs.com id
	02/5C-05998-EB434605; Thu, 27 Sep 2012 11:13:02 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1348744380!31828884!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzE5Njc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 557 invoked from network); 27 Sep 2012 11:13:01 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-13.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Sep 2012 11:13:01 -0000
X-IronPort-AV: E=Sophos;i="4.80,495,1344211200"; d="scan'208";a="39351825"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Sep 2012 11:12:42 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1;
	Thu, 27 Sep 2012 07:12:41 -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 1THC1J-0000pN-CX;
	Thu, 27 Sep 2012 12:12:41 +0100
From: Anthony PERARD <anthony.perard@citrix.com>
To: QEMU-devel <qemu-devel@nongnu.org>,
	Stefano Stabellini <stefano.stabellini@citrix.com>
Date: Thu, 27 Sep 2012 12:12:35 +0100
Message-ID: <1348744360-2989-1-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.12.1
MIME-Version: 1.0
Cc: Anthony PERARD <anthony.perard@citrix.com>,
	Xen Devel <xen-devel@lists.xen.org>
Subject: [Xen-devel] [PATCH V4 0/5] Xen, introducing dirty log for 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

Hi,

This patch set will fix live migration under Xen. For this I introduce a new
QMP command to switch global-dirty log and few calls (in exec.c and memory.c)
to xen set_dirty function.

Change since v3:
  - Coding style of patch 2
  - Reword last patch comment

Change since v2:
  - renamed set_dirty_helper to invalidate_and_set_dirty.
  - in the last patch, set vram as dirty if the xen call fails, instead of only
    during migration.

Change v1-v2:
  - New patch to set dirty if not, in exec.c
    => only one place to add the xen call in exec.c


Thanks for your reviews,

Anthony PERARD (5):
  QMP, Introduce xen-set-global-dirty-log command.
  xen: Introduce xen_modified_memory.
  exec: Introduce helper to set dirty flags.
  exec, memory: Call to xen_modified_memory.
  xen: Set the vram dirty when an error occur.

 exec.c           | 53 ++++++++++++++++++-----------------------------------
 hw/xen.h         |  1 +
 memory.c         |  2 ++
 qapi-schema.json | 13 +++++++++++++
 qmp-commands.hx  | 24 ++++++++++++++++++++++++
 xen-all.c        | 39 ++++++++++++++++++++++++++++++++++++++-
 xen-stub.c       |  9 +++++++++
 7 files changed, 105 insertions(+), 36 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 Thu Sep 27 11:13:23 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Sep 2012 11:13:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1THC1h-0002QF-NA; Thu, 27 Sep 2012 11:13:05 +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 1THC1f-0002Pa-8Z
	for xen-devel@lists.xen.org; Thu, 27 Sep 2012 11:13:03 +0000
Received: from [85.158.139.83:64699] by server-16.bemta-5.messagelabs.com id
	02/5C-05998-EB434605; Thu, 27 Sep 2012 11:13:02 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1348744380!31828884!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzE5Njc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 557 invoked from network); 27 Sep 2012 11:13:01 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-13.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Sep 2012 11:13:01 -0000
X-IronPort-AV: E=Sophos;i="4.80,495,1344211200"; d="scan'208";a="39351825"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Sep 2012 11:12:42 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1;
	Thu, 27 Sep 2012 07:12:41 -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 1THC1J-0000pN-CX;
	Thu, 27 Sep 2012 12:12:41 +0100
From: Anthony PERARD <anthony.perard@citrix.com>
To: QEMU-devel <qemu-devel@nongnu.org>,
	Stefano Stabellini <stefano.stabellini@citrix.com>
Date: Thu, 27 Sep 2012 12:12:35 +0100
Message-ID: <1348744360-2989-1-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.12.1
MIME-Version: 1.0
Cc: Anthony PERARD <anthony.perard@citrix.com>,
	Xen Devel <xen-devel@lists.xen.org>
Subject: [Xen-devel] [PATCH V4 0/5] Xen, introducing dirty log for 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

Hi,

This patch set will fix live migration under Xen. For this I introduce a new
QMP command to switch global-dirty log and few calls (in exec.c and memory.c)
to xen set_dirty function.

Change since v3:
  - Coding style of patch 2
  - Reword last patch comment

Change since v2:
  - renamed set_dirty_helper to invalidate_and_set_dirty.
  - in the last patch, set vram as dirty if the xen call fails, instead of only
    during migration.

Change v1-v2:
  - New patch to set dirty if not, in exec.c
    => only one place to add the xen call in exec.c


Thanks for your reviews,

Anthony PERARD (5):
  QMP, Introduce xen-set-global-dirty-log command.
  xen: Introduce xen_modified_memory.
  exec: Introduce helper to set dirty flags.
  exec, memory: Call to xen_modified_memory.
  xen: Set the vram dirty when an error occur.

 exec.c           | 53 ++++++++++++++++++-----------------------------------
 hw/xen.h         |  1 +
 memory.c         |  2 ++
 qapi-schema.json | 13 +++++++++++++
 qmp-commands.hx  | 24 ++++++++++++++++++++++++
 xen-all.c        | 39 ++++++++++++++++++++++++++++++++++++++-
 xen-stub.c       |  9 +++++++++
 7 files changed, 105 insertions(+), 36 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 Thu Sep 27 11:13:23 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Sep 2012 11:13:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1THC1e-0002PV-Jd; Thu, 27 Sep 2012 11:13:02 +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 1THC1d-0002PK-A8
	for xen-devel@lists.xen.org; Thu, 27 Sep 2012 11:13:01 +0000
Received: from [85.158.138.51:62732] by server-7.bemta-3.messagelabs.com id
	A5/DC-15765-CB434605; Thu, 27 Sep 2012 11:13:00 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1348744378!30394415!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzE5Njc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31516 invoked from network); 27 Sep 2012 11:12:59 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-15.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Sep 2012 11:12:59 -0000
X-IronPort-AV: E=Sophos;i="4.80,495,1344211200"; d="scan'208";a="39351826"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Sep 2012 11:12:42 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1;
	Thu, 27 Sep 2012 07:12:41 -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 1THC1J-0000pN-FF;
	Thu, 27 Sep 2012 12:12:41 +0100
From: Anthony PERARD <anthony.perard@citrix.com>
To: QEMU-devel <qemu-devel@nongnu.org>,
	Stefano Stabellini <stefano.stabellini@citrix.com>
Date: Thu, 27 Sep 2012 12:12:39 +0100
Message-ID: <1348744360-2989-5-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.12.1
In-Reply-To: <1348744360-2989-1-git-send-email-anthony.perard@citrix.com>
References: <1348744360-2989-1-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Cc: Anthony PERARD <anthony.perard@citrix.com>,
	Xen Devel <xen-devel@lists.xen.org>
Subject: [Xen-devel] [PATCH V4 4/5] exec,
	memory: Call to xen_modified_memory.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This patch add some calls to xen_modified_memory to notify Xen about dirtybits
during migration.

Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
 exec.c   | 1 +
 memory.c | 2 ++
 2 files changed, 3 insertions(+)

diff --git a/exec.c b/exec.c
index 366684c..1114a09 100644
--- a/exec.c
+++ b/exec.c
@@ -3427,6 +3427,7 @@ static void invalidate_and_set_dirty(target_phys_addr_t addr,
         /* set dirty bit */
         cpu_physical_memory_set_dirty_flags(addr, (0xff & ~CODE_DIRTY_FLAG));
     }
+    xen_modified_memory(addr, length);
 }
 
 void cpu_physical_memory_rw(target_phys_addr_t addr, uint8_t *buf,
diff --git a/memory.c b/memory.c
index 4f3ade0..015c544 100644
--- a/memory.c
+++ b/memory.c
@@ -19,6 +19,7 @@
 #include "bitops.h"
 #include "kvm.h"
 #include <assert.h>
+#include "hw/xen.h"
 
 #define WANT_EXEC_OBSOLETE
 #include "exec-obsolete.h"
@@ -1077,6 +1078,7 @@ void memory_region_set_dirty(MemoryRegion *mr, target_phys_addr_t addr,
                              target_phys_addr_t size)
 {
     assert(mr->terminates);
+    xen_modified_memory(mr->ram_addr + addr, size);
     return cpu_physical_memory_set_dirty_range(mr->ram_addr + addr, size, -1);
 }
 
-- 
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 Sep 27 11:13:23 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Sep 2012 11:13:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1THC1e-0002PV-Jd; Thu, 27 Sep 2012 11:13:02 +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 1THC1d-0002PK-A8
	for xen-devel@lists.xen.org; Thu, 27 Sep 2012 11:13:01 +0000
Received: from [85.158.138.51:62732] by server-7.bemta-3.messagelabs.com id
	A5/DC-15765-CB434605; Thu, 27 Sep 2012 11:13:00 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1348744378!30394415!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzE5Njc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31516 invoked from network); 27 Sep 2012 11:12:59 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-15.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Sep 2012 11:12:59 -0000
X-IronPort-AV: E=Sophos;i="4.80,495,1344211200"; d="scan'208";a="39351826"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Sep 2012 11:12:42 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1;
	Thu, 27 Sep 2012 07:12:41 -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 1THC1J-0000pN-FF;
	Thu, 27 Sep 2012 12:12:41 +0100
From: Anthony PERARD <anthony.perard@citrix.com>
To: QEMU-devel <qemu-devel@nongnu.org>,
	Stefano Stabellini <stefano.stabellini@citrix.com>
Date: Thu, 27 Sep 2012 12:12:39 +0100
Message-ID: <1348744360-2989-5-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.12.1
In-Reply-To: <1348744360-2989-1-git-send-email-anthony.perard@citrix.com>
References: <1348744360-2989-1-git-send-email-anthony.perard@citrix.com>
MIME-Version: 1.0
Cc: Anthony PERARD <anthony.perard@citrix.com>,
	Xen Devel <xen-devel@lists.xen.org>
Subject: [Xen-devel] [PATCH V4 4/5] exec,
	memory: Call to xen_modified_memory.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This patch add some calls to xen_modified_memory to notify Xen about dirtybits
during migration.

Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
---
 exec.c   | 1 +
 memory.c | 2 ++
 2 files changed, 3 insertions(+)

diff --git a/exec.c b/exec.c
index 366684c..1114a09 100644
--- a/exec.c
+++ b/exec.c
@@ -3427,6 +3427,7 @@ static void invalidate_and_set_dirty(target_phys_addr_t addr,
         /* set dirty bit */
         cpu_physical_memory_set_dirty_flags(addr, (0xff & ~CODE_DIRTY_FLAG));
     }
+    xen_modified_memory(addr, length);
 }
 
 void cpu_physical_memory_rw(target_phys_addr_t addr, uint8_t *buf,
diff --git a/memory.c b/memory.c
index 4f3ade0..015c544 100644
--- a/memory.c
+++ b/memory.c
@@ -19,6 +19,7 @@
 #include "bitops.h"
 #include "kvm.h"
 #include <assert.h>
+#include "hw/xen.h"
 
 #define WANT_EXEC_OBSOLETE
 #include "exec-obsolete.h"
@@ -1077,6 +1078,7 @@ void memory_region_set_dirty(MemoryRegion *mr, target_phys_addr_t addr,
                              target_phys_addr_t size)
 {
     assert(mr->terminates);
+    xen_modified_memory(mr->ram_addr + addr, size);
     return cpu_physical_memory_set_dirty_range(mr->ram_addr + addr, size, -1);
 }
 
-- 
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 Sep 27 11:38:06 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Sep 2012 11: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 1THCPe-0003gb-Fq; Thu, 27 Sep 2012 11:37: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 1THCPc-0003gV-MI
	for xen-devel@lists.xen.org; Thu, 27 Sep 2012 11:37:48 +0000
Received: from [85.158.137.99:38471] by server-7.bemta-3.messagelabs.com id
	9A/93-15765-B8A34605; Thu, 27 Sep 2012 11:37:47 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-15.tower-217.messagelabs.com!1348745865!16981468!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzY4ODAw\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23989 invoked from network); 27 Sep 2012 11:37:47 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-15.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 27 Sep 2012 11:37:47 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q8RBbhxu009958
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 27 Sep 2012 11:37: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
	q8RBbgI3023768
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 27 Sep 2012 11:37:42 GMT
Received: from abhmt114.oracle.com (abhmt114.oracle.com [141.146.116.66])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q8RBbfbq031281; Thu, 27 Sep 2012 06:37:41 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 27 Sep 2012 04:37:41 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 9F21E402E8; Thu, 27 Sep 2012 07:26:24 -0400 (EDT)
Date: Thu, 27 Sep 2012 07:26:24 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Dan Magenheimer <dan.magenheimer@oracle.com>, mike.mcclurg@citrix.com,
	anil@recoil.org
Message-ID: <20120927112624.GA8576@phenom.dumpdata.com>
References: <53b8c758-2675-42a7-b63f-4f9ad0006d84@default>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <53b8c758-2675-42a7-b63f-4f9ad0006d84@default>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: Kurt Hackel <kurt.hackel@oracle.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] domain creation vs querying free memory (xend and
	xl)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Sep 26, 2012 at 02:17:06PM -0700, Dan Magenheimer wrote:
> I was asked a question that seems like it should be obvious
> but it doesn't seem to be, at least in xm-land.  I'll look
> into it further, as well as for xl, but I thought I'd ask
> first to see if there is a known answer or if this is a known
> problem:
> 
> Suppose that xm/xl create is issued on a large-memory
> domain (PV or HVM or, future, PVH).  It takes awhile
> for this domain to launch and during at least part of this
> time, the toolset hasn't yet requested all of the
> required memory from the hypervisor to complete the
> launch of the domain...  or perhaps the toolset has,
> but the hypervisor is slow about calling the long sequence
> of page allocations (e.g. maybe because it is zeroing
> each page?).
> 
> Then it is desired to launch a second large-memory domain.
> The tools can query Xen to see if there is sufficient RAM
> and there is, because the first launch has not yet
> allocated all the RAM assigned to it.
> 
> But the second domain launch fails, possibly after
> several minutes because, actually, there isn't enough
> physical RAM for both.
> 
> Does this make sense?  Should the tools "reserve"
> maxmem as a "transaction" and/or ensure that "xm/xl
> free" calls account for the entire requested amount
> of RAM?  Or maybe xl _does_ work this way?

So say "freeze" the amount of free memory. Lets CC the XCP folks
> 
> Thanks for any comments or discussion!
> 
> Dan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 27 11:38:06 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Sep 2012 11: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 1THCPe-0003gb-Fq; Thu, 27 Sep 2012 11:37: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 1THCPc-0003gV-MI
	for xen-devel@lists.xen.org; Thu, 27 Sep 2012 11:37:48 +0000
Received: from [85.158.137.99:38471] by server-7.bemta-3.messagelabs.com id
	9A/93-15765-B8A34605; Thu, 27 Sep 2012 11:37:47 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-15.tower-217.messagelabs.com!1348745865!16981468!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzY4ODAw\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23989 invoked from network); 27 Sep 2012 11:37:47 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-15.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 27 Sep 2012 11:37:47 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q8RBbhxu009958
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 27 Sep 2012 11:37: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
	q8RBbgI3023768
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 27 Sep 2012 11:37:42 GMT
Received: from abhmt114.oracle.com (abhmt114.oracle.com [141.146.116.66])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q8RBbfbq031281; Thu, 27 Sep 2012 06:37:41 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 27 Sep 2012 04:37:41 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 9F21E402E8; Thu, 27 Sep 2012 07:26:24 -0400 (EDT)
Date: Thu, 27 Sep 2012 07:26:24 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Dan Magenheimer <dan.magenheimer@oracle.com>, mike.mcclurg@citrix.com,
	anil@recoil.org
Message-ID: <20120927112624.GA8576@phenom.dumpdata.com>
References: <53b8c758-2675-42a7-b63f-4f9ad0006d84@default>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <53b8c758-2675-42a7-b63f-4f9ad0006d84@default>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: Kurt Hackel <kurt.hackel@oracle.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] domain creation vs querying free memory (xend and
	xl)
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Wed, Sep 26, 2012 at 02:17:06PM -0700, Dan Magenheimer wrote:
> I was asked a question that seems like it should be obvious
> but it doesn't seem to be, at least in xm-land.  I'll look
> into it further, as well as for xl, but I thought I'd ask
> first to see if there is a known answer or if this is a known
> problem:
> 
> Suppose that xm/xl create is issued on a large-memory
> domain (PV or HVM or, future, PVH).  It takes awhile
> for this domain to launch and during at least part of this
> time, the toolset hasn't yet requested all of the
> required memory from the hypervisor to complete the
> launch of the domain...  or perhaps the toolset has,
> but the hypervisor is slow about calling the long sequence
> of page allocations (e.g. maybe because it is zeroing
> each page?).
> 
> Then it is desired to launch a second large-memory domain.
> The tools can query Xen to see if there is sufficient RAM
> and there is, because the first launch has not yet
> allocated all the RAM assigned to it.
> 
> But the second domain launch fails, possibly after
> several minutes because, actually, there isn't enough
> physical RAM for both.
> 
> Does this make sense?  Should the tools "reserve"
> maxmem as a "transaction" and/or ensure that "xm/xl
> free" calls account for the entire requested amount
> of RAM?  Or maybe xl _does_ work this way?

So say "freeze" the amount of free memory. Lets CC the XCP folks
> 
> Thanks for any comments or discussion!
> 
> Dan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 27 12:01:16 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Sep 2012 12:01: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 1THCm0-00041A-Cn; Thu, 27 Sep 2012 12:00:56 +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 1THClz-00040x-4l
	for xen-devel@lists.xen.org; Thu, 27 Sep 2012 12:00:55 +0000
Received: from [85.158.138.51:44779] by server-11.bemta-3.messagelabs.com id
	BB/29-21460-6FF34605; Thu, 27 Sep 2012 12:00:54 +0000
X-Env-Sender: lars.kurth.xen@gmail.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1348747253!24587405!1
X-Originating-IP: [209.85.215.45]
X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3823 invoked from network); 27 Sep 2012 12:00:53 -0000
Received: from mail-la0-f45.google.com (HELO mail-la0-f45.google.com)
	(209.85.215.45)
	by server-10.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Sep 2012 12:00:53 -0000
Received: by lahm13 with SMTP id m13so505470lah.32
	for <xen-devel@lists.xen.org>; Thu, 27 Sep 2012 05:00: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=2wjXzY5vBZUycn/vwPnaSOfitBDKGsp3xzYvxUGpcTI=;
	b=Dlwio7fxQPz5VCMwghPC/pfQD6sh+if6b0lg3YKXFfWMRa9G7o0/Grm024IsqBDaRW
	l2cLKIzxHlvLlw59HZsVeBM3ZZlZBsXxxMEDRhPXYnf3rK3BFe5CjmBYd0dZykcD0Z/K
	/W7pL4o6Xs2fdNHaj5iqXPewur2UAVQPh1TMQvNHPGWlh6TUeR5lmc6HTl8zeGtVDq3L
	EskFwv5kdKe/ZYP94WZ/W32LLs4QgNvjQ2R0jE3fY6vsXfKcTrRXSfmZSUo0VoJYdMUh
	zovfoYbLN/B3HwESOlU1VnpOnAmKGUrN2rdnPo7P2cq3XOcQwzUBwXyD/qMtO+tYIf4S
	pcxQ==
MIME-Version: 1.0
Received: by 10.152.105.236 with SMTP id gp12mr3145207lab.35.1348747250813;
	Thu, 27 Sep 2012 05:00:50 -0700 (PDT)
Received: by 10.112.120.138 with HTTP; Thu, 27 Sep 2012 05:00:50 -0700 (PDT)
In-Reply-To: <CC72390B.3E2D0%keir.xen@gmail.com>
References: <CC72390B.3E2D0%keir.xen@gmail.com>
Date: Thu, 27 Sep 2012 13:00:50 +0100
Message-ID: <CAOqnZH5qZAHOw2xLZXNF6KT6qGiqJmYR-L9BLaviBkjAOCAPFA@mail.gmail.com>
From: Lars Kurth <lars.kurth.xen@gmail.com>
To: Keir Fraser <keir.xen@gmail.com>
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [ANNOUNCE] Switching to git for primary Xen
	repositories
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============9001096716136100816=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============9001096716136100816==
Content-Type: multipart/alternative; boundary=f46d0407144bc6ca5b04caadb0f0

--f46d0407144bc6ca5b04caadb0f0
Content-Type: text/plain; charset=ISO-8859-1

Hi everybody,
I am wondering whether it wouldn't be better to have a vote about this. At
least in this case, nobody will be able to complain in the future.
Regards
Lars

On Sun, Sep 9, 2012 at 12:16 PM, Keir Fraser <keir.xen@gmail.com> wrote:

> Folks,
>
> The Xen project has used mercurial for the primary repositories for many
> years. However, with external projects (including Linux and qemu) using
> git,
> this has led to us using and supporting two revision-control systems. Our
> plan therefore, with the 4.2.0 release soon out of the way, is to switch to
> git for all of our primary repositories. We will plan to mirror development
> activity into the old mercurial repositories at least in the short term.
>
> We will make a further announcement nearer to the time of the switchover.
>
>  Regards,
>  Keir & The Xen Team
>
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
>

--f46d0407144bc6ca5b04caadb0f0
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi everybody,<br>I am wondering whether it wouldn&#39;t be better to have a=
 vote about this. At least in this case, nobody will be able to complain in=
 the future.<br>Regards<br>Lars<br><br><div class=3D"gmail_quote">On Sun, S=
ep 9, 2012 at 12:16 PM, Keir Fraser <span dir=3D"ltr">&lt;<a href=3D"mailto=
:keir.xen@gmail.com" target=3D"_blank">keir.xen@gmail.com</a>&gt;</span> wr=
ote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">Folks,<br>
<br>
The Xen project has used mercurial for the primary repositories for many<br=
>
years. However, with external projects (including Linux and qemu) using git=
,<br>
this has led to us using and supporting two revision-control systems. Our<b=
r>
plan therefore, with the 4.2.0 release soon out of the way, is to switch to=
<br>
git for all of our primary repositories. We will plan to mirror development=
<br>
activity into the old mercurial repositories at least in the short term.<br=
>
<br>
We will make a further announcement nearer to the time of the switchover.<b=
r>
<br>
=A0Regards,<br>
=A0Keir &amp; The Xen Team<br>
<br>
<br>
<br>
_______________________________________________<br>
Xen-devel mailing list<br>
<a href=3D"mailto:Xen-devel@lists.xen.org">Xen-devel@lists.xen.org</a><br>
<a href=3D"http://lists.xen.org/xen-devel" target=3D"_blank">http://lists.x=
en.org/xen-devel</a><br>
</blockquote></div><br>

--f46d0407144bc6ca5b04caadb0f0--


--===============9001096716136100816==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============9001096716136100816==--


From xen-devel-bounces@lists.xen.org Thu Sep 27 12:01:16 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Sep 2012 12:01: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 1THCm0-00041A-Cn; Thu, 27 Sep 2012 12:00:56 +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 1THClz-00040x-4l
	for xen-devel@lists.xen.org; Thu, 27 Sep 2012 12:00:55 +0000
Received: from [85.158.138.51:44779] by server-11.bemta-3.messagelabs.com id
	BB/29-21460-6FF34605; Thu, 27 Sep 2012 12:00:54 +0000
X-Env-Sender: lars.kurth.xen@gmail.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1348747253!24587405!1
X-Originating-IP: [209.85.215.45]
X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3823 invoked from network); 27 Sep 2012 12:00:53 -0000
Received: from mail-la0-f45.google.com (HELO mail-la0-f45.google.com)
	(209.85.215.45)
	by server-10.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Sep 2012 12:00:53 -0000
Received: by lahm13 with SMTP id m13so505470lah.32
	for <xen-devel@lists.xen.org>; Thu, 27 Sep 2012 05:00: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=2wjXzY5vBZUycn/vwPnaSOfitBDKGsp3xzYvxUGpcTI=;
	b=Dlwio7fxQPz5VCMwghPC/pfQD6sh+if6b0lg3YKXFfWMRa9G7o0/Grm024IsqBDaRW
	l2cLKIzxHlvLlw59HZsVeBM3ZZlZBsXxxMEDRhPXYnf3rK3BFe5CjmBYd0dZykcD0Z/K
	/W7pL4o6Xs2fdNHaj5iqXPewur2UAVQPh1TMQvNHPGWlh6TUeR5lmc6HTl8zeGtVDq3L
	EskFwv5kdKe/ZYP94WZ/W32LLs4QgNvjQ2R0jE3fY6vsXfKcTrRXSfmZSUo0VoJYdMUh
	zovfoYbLN/B3HwESOlU1VnpOnAmKGUrN2rdnPo7P2cq3XOcQwzUBwXyD/qMtO+tYIf4S
	pcxQ==
MIME-Version: 1.0
Received: by 10.152.105.236 with SMTP id gp12mr3145207lab.35.1348747250813;
	Thu, 27 Sep 2012 05:00:50 -0700 (PDT)
Received: by 10.112.120.138 with HTTP; Thu, 27 Sep 2012 05:00:50 -0700 (PDT)
In-Reply-To: <CC72390B.3E2D0%keir.xen@gmail.com>
References: <CC72390B.3E2D0%keir.xen@gmail.com>
Date: Thu, 27 Sep 2012 13:00:50 +0100
Message-ID: <CAOqnZH5qZAHOw2xLZXNF6KT6qGiqJmYR-L9BLaviBkjAOCAPFA@mail.gmail.com>
From: Lars Kurth <lars.kurth.xen@gmail.com>
To: Keir Fraser <keir.xen@gmail.com>
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [ANNOUNCE] Switching to git for primary Xen
	repositories
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============9001096716136100816=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============9001096716136100816==
Content-Type: multipart/alternative; boundary=f46d0407144bc6ca5b04caadb0f0

--f46d0407144bc6ca5b04caadb0f0
Content-Type: text/plain; charset=ISO-8859-1

Hi everybody,
I am wondering whether it wouldn't be better to have a vote about this. At
least in this case, nobody will be able to complain in the future.
Regards
Lars

On Sun, Sep 9, 2012 at 12:16 PM, Keir Fraser <keir.xen@gmail.com> wrote:

> Folks,
>
> The Xen project has used mercurial for the primary repositories for many
> years. However, with external projects (including Linux and qemu) using
> git,
> this has led to us using and supporting two revision-control systems. Our
> plan therefore, with the 4.2.0 release soon out of the way, is to switch to
> git for all of our primary repositories. We will plan to mirror development
> activity into the old mercurial repositories at least in the short term.
>
> We will make a further announcement nearer to the time of the switchover.
>
>  Regards,
>  Keir & The Xen Team
>
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
>

--f46d0407144bc6ca5b04caadb0f0
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi everybody,<br>I am wondering whether it wouldn&#39;t be better to have a=
 vote about this. At least in this case, nobody will be able to complain in=
 the future.<br>Regards<br>Lars<br><br><div class=3D"gmail_quote">On Sun, S=
ep 9, 2012 at 12:16 PM, Keir Fraser <span dir=3D"ltr">&lt;<a href=3D"mailto=
:keir.xen@gmail.com" target=3D"_blank">keir.xen@gmail.com</a>&gt;</span> wr=
ote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">Folks,<br>
<br>
The Xen project has used mercurial for the primary repositories for many<br=
>
years. However, with external projects (including Linux and qemu) using git=
,<br>
this has led to us using and supporting two revision-control systems. Our<b=
r>
plan therefore, with the 4.2.0 release soon out of the way, is to switch to=
<br>
git for all of our primary repositories. We will plan to mirror development=
<br>
activity into the old mercurial repositories at least in the short term.<br=
>
<br>
We will make a further announcement nearer to the time of the switchover.<b=
r>
<br>
=A0Regards,<br>
=A0Keir &amp; The Xen Team<br>
<br>
<br>
<br>
_______________________________________________<br>
Xen-devel mailing list<br>
<a href=3D"mailto:Xen-devel@lists.xen.org">Xen-devel@lists.xen.org</a><br>
<a href=3D"http://lists.xen.org/xen-devel" target=3D"_blank">http://lists.x=
en.org/xen-devel</a><br>
</blockquote></div><br>

--f46d0407144bc6ca5b04caadb0f0--


--===============9001096716136100816==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============9001096716136100816==--


From xen-devel-bounces@lists.xen.org Thu Sep 27 12:11:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Sep 2012 12: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 1THCvW-0004M7-JS; Thu, 27 Sep 2012 12:10:46 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1THCvU-0004M1-Ij
	for xen-devel@lists.xen.org; Thu, 27 Sep 2012 12:10:44 +0000
Received: from [85.158.143.35:53403] by server-3.bemta-4.messagelabs.com id
	FD/20-10986-34244605; Thu, 27 Sep 2012 12:10:43 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1348747841!10718353!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDc3ODg1Mg==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28885 invoked from network); 27 Sep 2012 12:10:42 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-10.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 27 Sep 2012 12:10: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 q8RCAbNf000314
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 27 Sep 2012 12:10:38 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
	q8RCAb1A007944
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 27 Sep 2012 12:10:37 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
	q8RCAZvu027148; Thu, 27 Sep 2012 07:10:37 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 27 Sep 2012 05:10:35 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 53D0A402E8; Thu, 27 Sep 2012 07:59:18 -0400 (EDT)
Date: Thu, 27 Sep 2012 07:59:18 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Zhenzhong Duan <zhenzhong.duan@oracle.com>
Message-ID: <20120927115918.GE8832@phenom.dumpdata.com>
References: <505C3647.1030003@oracle.com>
	<20120921143430.GA3522@phenom.dumpdata.com>
	<5062C16A.1020306@oracle.com>
	<20120926123534.GF7356@phenom.dumpdata.com>
	<5063EAFB.1070307@oracle.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <5063EAFB.1070307@oracle.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: Konrad Rzeszutek Wilk <konrad@kernel.org>,
	Dan Magenheimer <dan.magenheimer@oracle.com>,
	Feng Jin <joe.jin@oracle.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] an issue with 'xm save'
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Sep 27, 2012 at 01:58:19PM +0800, Zhenzhong Duan wrote:
> 
> 
> On 2012-09-26 20:35, Konrad Rzeszutek Wilk wrote:
> >On Wed, Sep 26, 2012 at 04:48:42PM +0800, Zhenzhong Duan wrote:
> >>Konrad Rzeszutek Wilk wrote:
> >>>On Fri, Sep 21, 2012 at 05:41:27PM +0800, Zhenzhong Duan wrote:
> >>>>Hi maintainers,
> >>>>
> >>>>I found there is an issue when 'xm save' a pvm guest. See below:
> >>>>
> >>>>When I do save then restore once, CPU(%) in xentop showed around 99%.
> >>>>When I do that second time, CPU(%) showed 199%
> >>>>
> >>>>top in dom0 showed:
> >>>>     PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
> >>>>    20946 root      18  -2 10984 1284  964 S 19.8  0.3   0:48.93 block
> >>>>    4939 root      18  -2 10984 1288  964 S 19.5  0.3   1:34.68 block
> >>>>
> >>>>I could kill the block process, then all look normal again.
> >>>What is the 'block' process? If you attach 'perf' to it do you get an idea
> >>>of what it is spinning at?
> >>It's /etc/xen/scripts/block
> >>I add 'set -x' to /etc/xen/scripts/block, found it blocked at claim_lock.
> >>When domU was created first time, claim_lock/release_lock finished quickly,
> >>when 'xm save' was called, claim_lock spin in its own while loop.
> >>I can ensure no other domU create/save/etc happen when I test.
> >OK, so how come you have two block processes? Is it b/c you have two
> >disks attached to the guest? The are multiple claim_lock in the shell
> >script - do you know where each of two threads are spinning? Are they
> >spinning on the same function?
> In above test, I run save/restore twice, so two block processes.
> In other test, run save/restore once, there is only one block process.
> After do 'xm save', I see block process spin at line 328:
> 321   remove)
> 322     case $t in
> 323       phy)
> 324         exit 0
> 325         ;;
> 326
> 327       file)
> 328         claim_lock "block"
> 329         node=$(xenstore_read "$XENBUS_PATH/node")
> 330         losetup -d "$node"
> 331         release_lock "block"
> 332         exit 0
> 333         ;;

So with the patches in OVM - do they have this fixed? Can they be upstreamed
or are the dependent on some magic OVM sauce?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 27 12:11:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Sep 2012 12: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 1THCvW-0004M7-JS; Thu, 27 Sep 2012 12:10:46 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1THCvU-0004M1-Ij
	for xen-devel@lists.xen.org; Thu, 27 Sep 2012 12:10:44 +0000
Received: from [85.158.143.35:53403] by server-3.bemta-4.messagelabs.com id
	FD/20-10986-34244605; Thu, 27 Sep 2012 12:10:43 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1348747841!10718353!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDc3ODg1Mg==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28885 invoked from network); 27 Sep 2012 12:10:42 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-10.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 27 Sep 2012 12:10: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 q8RCAbNf000314
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 27 Sep 2012 12:10:38 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
	q8RCAb1A007944
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 27 Sep 2012 12:10:37 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
	q8RCAZvu027148; Thu, 27 Sep 2012 07:10:37 -0500
Received: from phenom.dumpdata.com (/50.195.21.189)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 27 Sep 2012 05:10:35 -0700
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 53D0A402E8; Thu, 27 Sep 2012 07:59:18 -0400 (EDT)
Date: Thu, 27 Sep 2012 07:59:18 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Zhenzhong Duan <zhenzhong.duan@oracle.com>
Message-ID: <20120927115918.GE8832@phenom.dumpdata.com>
References: <505C3647.1030003@oracle.com>
	<20120921143430.GA3522@phenom.dumpdata.com>
	<5062C16A.1020306@oracle.com>
	<20120926123534.GF7356@phenom.dumpdata.com>
	<5063EAFB.1070307@oracle.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <5063EAFB.1070307@oracle.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: Konrad Rzeszutek Wilk <konrad@kernel.org>,
	Dan Magenheimer <dan.magenheimer@oracle.com>,
	Feng Jin <joe.jin@oracle.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] an issue with 'xm save'
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Sep 27, 2012 at 01:58:19PM +0800, Zhenzhong Duan wrote:
> 
> 
> On 2012-09-26 20:35, Konrad Rzeszutek Wilk wrote:
> >On Wed, Sep 26, 2012 at 04:48:42PM +0800, Zhenzhong Duan wrote:
> >>Konrad Rzeszutek Wilk wrote:
> >>>On Fri, Sep 21, 2012 at 05:41:27PM +0800, Zhenzhong Duan wrote:
> >>>>Hi maintainers,
> >>>>
> >>>>I found there is an issue when 'xm save' a pvm guest. See below:
> >>>>
> >>>>When I do save then restore once, CPU(%) in xentop showed around 99%.
> >>>>When I do that second time, CPU(%) showed 199%
> >>>>
> >>>>top in dom0 showed:
> >>>>     PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
> >>>>    20946 root      18  -2 10984 1284  964 S 19.8  0.3   0:48.93 block
> >>>>    4939 root      18  -2 10984 1288  964 S 19.5  0.3   1:34.68 block
> >>>>
> >>>>I could kill the block process, then all look normal again.
> >>>What is the 'block' process? If you attach 'perf' to it do you get an idea
> >>>of what it is spinning at?
> >>It's /etc/xen/scripts/block
> >>I add 'set -x' to /etc/xen/scripts/block, found it blocked at claim_lock.
> >>When domU was created first time, claim_lock/release_lock finished quickly,
> >>when 'xm save' was called, claim_lock spin in its own while loop.
> >>I can ensure no other domU create/save/etc happen when I test.
> >OK, so how come you have two block processes? Is it b/c you have two
> >disks attached to the guest? The are multiple claim_lock in the shell
> >script - do you know where each of two threads are spinning? Are they
> >spinning on the same function?
> In above test, I run save/restore twice, so two block processes.
> In other test, run save/restore once, there is only one block process.
> After do 'xm save', I see block process spin at line 328:
> 321   remove)
> 322     case $t in
> 323       phy)
> 324         exit 0
> 325         ;;
> 326
> 327       file)
> 328         claim_lock "block"
> 329         node=$(xenstore_read "$XENBUS_PATH/node")
> 330         losetup -d "$node"
> 331         release_lock "block"
> 332         exit 0
> 333         ;;

So with the patches in OVM - do they have this fixed? Can they be upstreamed
or are the dependent on some magic OVM sauce?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 27 12:13:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Sep 2012 12:13:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1THCxT-0004R6-3T; Thu, 27 Sep 2012 12:12:47 +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 1THCxR-0004Qv-Ql
	for xen-devel@lists.xen.org; Thu, 27 Sep 2012 12:12:46 +0000
Received: from [85.158.139.211:16286] by server-3.bemta-5.messagelabs.com id
	49/92-16108-CB244605; Thu, 27 Sep 2012 12:12:44 +0000
X-Env-Sender: ben.guthro@gmail.com
X-Msg-Ref: server-15.tower-206.messagelabs.com!1348747962!20230411!1
X-Originating-IP: [209.85.223.173]
X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE,
	RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10608 invoked from network); 27 Sep 2012 12:12:43 -0000
Received: from mail-ie0-f173.google.com (HELO mail-ie0-f173.google.com)
	(209.85.223.173)
	by server-15.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Sep 2012 12:12:43 -0000
Received: by iea17 with SMTP id 17so5303539iea.32
	for <xen-devel@lists.xen.org>; Thu, 27 Sep 2012 05:12: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;
	bh=PNHhZixv650gdh/gTiIvBrs/8ZpGWW03LHF5LRBbSlI=;
	b=b0ArI7Xa9uaErc1cR/CDwk8EURxiBbXZQ48xQvemCmgP7er07EZ6Khamze48UBkH0t
	sAkpb/0wbfSyqSqLcqQvLScA0TdGwT0sSFXG9N8KmpvKWJpa8s+24Iiym8W0zCoFBq5t
	86HTr3bWYaE8635pf1zmlfsckMZAKinD7GI1dk7drTVERe4EpssbbjPHon52Vtwb7s7g
	15euaT7tucLvar41s8QPxOrQ1IUv2Kf4QspBgtFE3qmYJ4Md165VIeKG53uLZNWa117O
	xcbtcX0kNWbrPNYDsYP2eyUf/LLdgib0wxdnf9KRgL0jgiUUCGwPg6CZxwT2fILOZ0k4
	7m+g==
MIME-Version: 1.0
Received: by 10.50.158.226 with SMTP id wx2mr13861429igb.70.1348747962244;
	Thu, 27 Sep 2012 05:12:42 -0700 (PDT)
Received: by 10.64.55.132 with HTTP; Thu, 27 Sep 2012 05:12:42 -0700 (PDT)
In-Reply-To: <50641E86020000780009E2E3@nat28.tlf.novell.com>
References: <CAOvdn6UCF2A3yP1cqWn=dxwr0ayRbr+rg+xj8META9Dm0+CoNw@mail.gmail.com>
	<CC868168.3FD29%keir.xen@gmail.com>
	<CAOvdn6U-JyLvt96gkLkqzi088tU9_ktv4D+fkJac_BKVe05Y-w@mail.gmail.com>
	<CAOvdn6V+s3AbRzsu8VArbmrZou=im9SqvPf-9Wpif_BrNMv=yg@mail.gmail.com>
	<50617297020000780009D8AA@nat28.tlf.novell.com>
	<CAOvdn6Vsnbcd7m8mh3tSgn3KaEoeiOyVD1mr3uQ3bN=rF=pDUQ@mail.gmail.com>
	<5062F880020000780009DF3B@nat28.tlf.novell.com>
	<CAOvdn6VyAVg24=c1OxqttxuGFyN_NzpfZ7RoCYc2mVF84c5big@mail.gmail.com>
	<50641E86020000780009E2E3@nat28.tlf.novell.com>
Date: Thu, 27 Sep 2012 08:12:42 -0400
X-Google-Sender-Auth: xP1Mi7OY0Ew3cRREVOaDNvjecfk
Message-ID: <CAOvdn6VE13fOSjrKU4Ryr=344u+YwygASj6z1ag_U-x-qvOC9g@mail.gmail.com>
From: Ben Guthro <ben@guthro.net>
To: Jan Beulich <JBeulich@suse.com>
Cc: Keir Fraser <keir.xen@gmail.com>, John Baboval <john.baboval@citrix.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen4.2 S3 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: multipart/mixed; boundary="===============0132483815118084183=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============0132483815118084183==
Content-Type: multipart/alternative; boundary=14dae9340c892e5fe304caaddb7d

--14dae9340c892e5fe304caaddb7d
Content-Type: text/plain; charset=ISO-8859-1

On Thu, Sep 27, 2012 at 3:38 AM, Jan Beulich <JBeulich@suse.com> wrote:

>
>
> > [   37.420030] PM: Restoring platform NVS memory
> > (XEN) microcode: collect_cpu_info for CPU0
> > (XEN) microcode: collect_cpu_info : sig=0x10676, pf=0x80, rev=0x60c
> > (XEN) microcode: collect_cpu_info for CPU1
> > (XEN) microcode: collect_cpu_info : sig=0x10676, pf=0x80, rev=0x60f
>
> And in the end we see that both cores run on different revisions.
>
>
very interesting. I had overlooked that.


> The mixup of Xen and Dom0 messages puzzles me too - in my
> understanding, all APs should be brought back up before
> domains get unpaused. Is that perhaps part of your problem
> with pinned vCPU-s? Or is the mixup not indicative of things
> actually happening in parallel?
>

It seems like it may be related, but I'm unsure how.
When I run without the dom0_vcpu_pin option, I don't see the
collect_cpu_info messages,
nor do I see the microcode revision printout for CPU0
nor do I see the dom0 / Xen messages mised up.

[   41.567458] ACPI: Preparing to enter system sleep state S3
[   42.020120] PM: Saving platform NVS memory
[   42.092643] Disabling non-boot CPUs ...
(XEN) Preparing system for ACPI S3 state.
(XEN) Disabling non-boot CPUs ...
(XEN) Entering ACPI S3 state.
(XEN) mce_intel.c:1239: MCA Capability: BCAST 1 SER 0 CMCI 0 firstbank 1
extended MCE MSR 0
(XEN) CMCI: CPU0 has no CMCI support
(XEN) CPU0: Thermal monitoring enabled (TM2)
(XEN) Finishing wakeup from ACPI S3 state.
(XEN) Enabling non-boot CPUs  ...
(XEN) Booting processor 1/1 eip 8a000
(XEN) Initializing CPU#1
(XEN) CPU: L1 I cache: 32K, L1 D cache: 32K
(XEN) CPU: L2 cache: 3072K
(XEN) CPU: Physical Processor ID: 0
(XEN) CPU: Processor Core ID: 1
(XEN) CMCI: CPU1 has no CMCI support
(XEN) CPU1: Thermal monitoring enabled (TM2)
(XEN) CPU1: Intel(R) Core(TM)2 Duo CPU     P8400  @ 2.26GHz stepping 06
(XEN) microcode: CPU1 updated from revision 0x60c to 0x60f, date =
2010-09-29
[   42.200055] ACPI: Low-level resume complete
[   42.200055] PM: Restoring platform NVS memory
[   42.200055] Enabling non-boot CPUs ...


Any pointers are appreciated.

/btg

--14dae9340c892e5fe304caaddb7d
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div class=3D"gmail_quote">On Thu, Sep 27, 2012 at 3:38 AM, Jan Beulich <sp=
an dir=3D"ltr">&lt;<a href=3D"mailto:JBeulich@suse.com" target=3D"_blank">J=
Beulich@suse.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote"=
 style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class=3D"im"><br></div>
<div class=3D"im"><br>
&gt; [ =A0 37.420030] PM: Restoring platform NVS memory<br>
&gt; (XEN) microcode: collect_cpu_info for CPU0<br>
&gt; (XEN) microcode: collect_cpu_info : sig=3D0x10676, pf=3D0x80, rev=3D0x=
60c<br>
&gt; (XEN) microcode: collect_cpu_info for CPU1<br>
&gt; (XEN) microcode: collect_cpu_info : sig=3D0x10676, pf=3D0x80, rev=3D0x=
60f<br>
<br>
</div>And in the end we see that both cores run on different revisions.<br>
<br></blockquote><div><br></div><div>very interesting. I had overlooked tha=
t.=A0</div><div>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:=
0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
The mixup of Xen and Dom0 messages puzzles me too - in my<br>
understanding, all APs should be brought back up before<br>
domains get unpaused. Is that perhaps part of your problem<br>
with pinned vCPU-s? Or is the mixup not indicative of things<br>
actually happening in parallel?<br></blockquote><div><br></div><div>It seem=
s like it may be related, but I&#39;m unsure how.</div><div>When I run with=
out the dom0_vcpu_pin option, I don&#39;t see the collect_cpu_info messages=
,=A0</div>
<div>nor do I see the microcode revision printout for CPU0</div><div>nor do=
 I see the dom0 / Xen messages mised up.</div><div><br></div><div><div>[ =
=A0 41.567458] ACPI: Preparing to enter system sleep state S3</div><div>[ =
=A0 42.020120] PM: Saving platform NVS memory</div>
<div>[ =A0 42.092643] Disabling non-boot CPUs ...</div><div>(XEN) Preparing=
 system for ACPI S3 state.</div><div>(XEN) Disabling non-boot CPUs ...</div=
><div>(XEN) Entering ACPI S3 state.</div><div>(XEN) mce_intel.c:1239: MCA C=
apability: BCAST 1 SER 0 CMCI 0 firstbank 1 extended MCE MSR 0</div>
<div>(XEN) CMCI: CPU0 has no CMCI support</div><div>(XEN) CPU0: Thermal mon=
itoring enabled (TM2)</div><div>(XEN) Finishing wakeup from ACPI S3 state.<=
/div><div>(XEN) Enabling non-boot CPUs =A0...</div><div>(XEN) Booting proce=
ssor 1/1 eip 8a000</div>
<div>(XEN) Initializing CPU#1</div><div>(XEN) CPU: L1 I cache: 32K, L1 D ca=
che: 32K</div><div>(XEN) CPU: L2 cache: 3072K</div><div>(XEN) CPU: Physical=
 Processor ID: 0</div><div>(XEN) CPU: Processor Core ID: 1</div><div>(XEN) =
CMCI: CPU1 has no CMCI support</div>
<div>(XEN) CPU1: Thermal monitoring enabled (TM2)</div><div>(XEN) CPU1: Int=
el(R) Core(TM)2 Duo CPU =A0 =A0 P8400 =A0@ 2.26GHz stepping 06</div><div>(X=
EN) microcode: CPU1 updated from revision 0x60c to 0x60f, date =3D 2010-09-=
29=A0</div>
<div>[ =A0 42.200055] ACPI: Low-level resume complete</div><div>[ =A0 42.20=
0055] PM: Restoring platform NVS memory</div><div>[ =A0 42.200055] Enabling=
 non-boot CPUs ...</div></div><div><br></div><div><br></div><div>Any pointe=
rs are appreciated.</div>
<div><br></div><div>/btg</div></div>

--14dae9340c892e5fe304caaddb7d--


--===============0132483815118084183==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============0132483815118084183==--


From xen-devel-bounces@lists.xen.org Thu Sep 27 12:13:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Sep 2012 12:13:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1THCxT-0004R6-3T; Thu, 27 Sep 2012 12:12:47 +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 1THCxR-0004Qv-Ql
	for xen-devel@lists.xen.org; Thu, 27 Sep 2012 12:12:46 +0000
Received: from [85.158.139.211:16286] by server-3.bemta-5.messagelabs.com id
	49/92-16108-CB244605; Thu, 27 Sep 2012 12:12:44 +0000
X-Env-Sender: ben.guthro@gmail.com
X-Msg-Ref: server-15.tower-206.messagelabs.com!1348747962!20230411!1
X-Originating-IP: [209.85.223.173]
X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE,
	RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10608 invoked from network); 27 Sep 2012 12:12:43 -0000
Received: from mail-ie0-f173.google.com (HELO mail-ie0-f173.google.com)
	(209.85.223.173)
	by server-15.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Sep 2012 12:12:43 -0000
Received: by iea17 with SMTP id 17so5303539iea.32
	for <xen-devel@lists.xen.org>; Thu, 27 Sep 2012 05:12: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;
	bh=PNHhZixv650gdh/gTiIvBrs/8ZpGWW03LHF5LRBbSlI=;
	b=b0ArI7Xa9uaErc1cR/CDwk8EURxiBbXZQ48xQvemCmgP7er07EZ6Khamze48UBkH0t
	sAkpb/0wbfSyqSqLcqQvLScA0TdGwT0sSFXG9N8KmpvKWJpa8s+24Iiym8W0zCoFBq5t
	86HTr3bWYaE8635pf1zmlfsckMZAKinD7GI1dk7drTVERe4EpssbbjPHon52Vtwb7s7g
	15euaT7tucLvar41s8QPxOrQ1IUv2Kf4QspBgtFE3qmYJ4Md165VIeKG53uLZNWa117O
	xcbtcX0kNWbrPNYDsYP2eyUf/LLdgib0wxdnf9KRgL0jgiUUCGwPg6CZxwT2fILOZ0k4
	7m+g==
MIME-Version: 1.0
Received: by 10.50.158.226 with SMTP id wx2mr13861429igb.70.1348747962244;
	Thu, 27 Sep 2012 05:12:42 -0700 (PDT)
Received: by 10.64.55.132 with HTTP; Thu, 27 Sep 2012 05:12:42 -0700 (PDT)
In-Reply-To: <50641E86020000780009E2E3@nat28.tlf.novell.com>
References: <CAOvdn6UCF2A3yP1cqWn=dxwr0ayRbr+rg+xj8META9Dm0+CoNw@mail.gmail.com>
	<CC868168.3FD29%keir.xen@gmail.com>
	<CAOvdn6U-JyLvt96gkLkqzi088tU9_ktv4D+fkJac_BKVe05Y-w@mail.gmail.com>
	<CAOvdn6V+s3AbRzsu8VArbmrZou=im9SqvPf-9Wpif_BrNMv=yg@mail.gmail.com>
	<50617297020000780009D8AA@nat28.tlf.novell.com>
	<CAOvdn6Vsnbcd7m8mh3tSgn3KaEoeiOyVD1mr3uQ3bN=rF=pDUQ@mail.gmail.com>
	<5062F880020000780009DF3B@nat28.tlf.novell.com>
	<CAOvdn6VyAVg24=c1OxqttxuGFyN_NzpfZ7RoCYc2mVF84c5big@mail.gmail.com>
	<50641E86020000780009E2E3@nat28.tlf.novell.com>
Date: Thu, 27 Sep 2012 08:12:42 -0400
X-Google-Sender-Auth: xP1Mi7OY0Ew3cRREVOaDNvjecfk
Message-ID: <CAOvdn6VE13fOSjrKU4Ryr=344u+YwygASj6z1ag_U-x-qvOC9g@mail.gmail.com>
From: Ben Guthro <ben@guthro.net>
To: Jan Beulich <JBeulich@suse.com>
Cc: Keir Fraser <keir.xen@gmail.com>, John Baboval <john.baboval@citrix.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen4.2 S3 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: multipart/mixed; boundary="===============0132483815118084183=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============0132483815118084183==
Content-Type: multipart/alternative; boundary=14dae9340c892e5fe304caaddb7d

--14dae9340c892e5fe304caaddb7d
Content-Type: text/plain; charset=ISO-8859-1

On Thu, Sep 27, 2012 at 3:38 AM, Jan Beulich <JBeulich@suse.com> wrote:

>
>
> > [   37.420030] PM: Restoring platform NVS memory
> > (XEN) microcode: collect_cpu_info for CPU0
> > (XEN) microcode: collect_cpu_info : sig=0x10676, pf=0x80, rev=0x60c
> > (XEN) microcode: collect_cpu_info for CPU1
> > (XEN) microcode: collect_cpu_info : sig=0x10676, pf=0x80, rev=0x60f
>
> And in the end we see that both cores run on different revisions.
>
>
very interesting. I had overlooked that.


> The mixup of Xen and Dom0 messages puzzles me too - in my
> understanding, all APs should be brought back up before
> domains get unpaused. Is that perhaps part of your problem
> with pinned vCPU-s? Or is the mixup not indicative of things
> actually happening in parallel?
>

It seems like it may be related, but I'm unsure how.
When I run without the dom0_vcpu_pin option, I don't see the
collect_cpu_info messages,
nor do I see the microcode revision printout for CPU0
nor do I see the dom0 / Xen messages mised up.

[   41.567458] ACPI: Preparing to enter system sleep state S3
[   42.020120] PM: Saving platform NVS memory
[   42.092643] Disabling non-boot CPUs ...
(XEN) Preparing system for ACPI S3 state.
(XEN) Disabling non-boot CPUs ...
(XEN) Entering ACPI S3 state.
(XEN) mce_intel.c:1239: MCA Capability: BCAST 1 SER 0 CMCI 0 firstbank 1
extended MCE MSR 0
(XEN) CMCI: CPU0 has no CMCI support
(XEN) CPU0: Thermal monitoring enabled (TM2)
(XEN) Finishing wakeup from ACPI S3 state.
(XEN) Enabling non-boot CPUs  ...
(XEN) Booting processor 1/1 eip 8a000
(XEN) Initializing CPU#1
(XEN) CPU: L1 I cache: 32K, L1 D cache: 32K
(XEN) CPU: L2 cache: 3072K
(XEN) CPU: Physical Processor ID: 0
(XEN) CPU: Processor Core ID: 1
(XEN) CMCI: CPU1 has no CMCI support
(XEN) CPU1: Thermal monitoring enabled (TM2)
(XEN) CPU1: Intel(R) Core(TM)2 Duo CPU     P8400  @ 2.26GHz stepping 06
(XEN) microcode: CPU1 updated from revision 0x60c to 0x60f, date =
2010-09-29
[   42.200055] ACPI: Low-level resume complete
[   42.200055] PM: Restoring platform NVS memory
[   42.200055] Enabling non-boot CPUs ...


Any pointers are appreciated.

/btg

--14dae9340c892e5fe304caaddb7d
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div class=3D"gmail_quote">On Thu, Sep 27, 2012 at 3:38 AM, Jan Beulich <sp=
an dir=3D"ltr">&lt;<a href=3D"mailto:JBeulich@suse.com" target=3D"_blank">J=
Beulich@suse.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote"=
 style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class=3D"im"><br></div>
<div class=3D"im"><br>
&gt; [ =A0 37.420030] PM: Restoring platform NVS memory<br>
&gt; (XEN) microcode: collect_cpu_info for CPU0<br>
&gt; (XEN) microcode: collect_cpu_info : sig=3D0x10676, pf=3D0x80, rev=3D0x=
60c<br>
&gt; (XEN) microcode: collect_cpu_info for CPU1<br>
&gt; (XEN) microcode: collect_cpu_info : sig=3D0x10676, pf=3D0x80, rev=3D0x=
60f<br>
<br>
</div>And in the end we see that both cores run on different revisions.<br>
<br></blockquote><div><br></div><div>very interesting. I had overlooked tha=
t.=A0</div><div>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:=
0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
The mixup of Xen and Dom0 messages puzzles me too - in my<br>
understanding, all APs should be brought back up before<br>
domains get unpaused. Is that perhaps part of your problem<br>
with pinned vCPU-s? Or is the mixup not indicative of things<br>
actually happening in parallel?<br></blockquote><div><br></div><div>It seem=
s like it may be related, but I&#39;m unsure how.</div><div>When I run with=
out the dom0_vcpu_pin option, I don&#39;t see the collect_cpu_info messages=
,=A0</div>
<div>nor do I see the microcode revision printout for CPU0</div><div>nor do=
 I see the dom0 / Xen messages mised up.</div><div><br></div><div><div>[ =
=A0 41.567458] ACPI: Preparing to enter system sleep state S3</div><div>[ =
=A0 42.020120] PM: Saving platform NVS memory</div>
<div>[ =A0 42.092643] Disabling non-boot CPUs ...</div><div>(XEN) Preparing=
 system for ACPI S3 state.</div><div>(XEN) Disabling non-boot CPUs ...</div=
><div>(XEN) Entering ACPI S3 state.</div><div>(XEN) mce_intel.c:1239: MCA C=
apability: BCAST 1 SER 0 CMCI 0 firstbank 1 extended MCE MSR 0</div>
<div>(XEN) CMCI: CPU0 has no CMCI support</div><div>(XEN) CPU0: Thermal mon=
itoring enabled (TM2)</div><div>(XEN) Finishing wakeup from ACPI S3 state.<=
/div><div>(XEN) Enabling non-boot CPUs =A0...</div><div>(XEN) Booting proce=
ssor 1/1 eip 8a000</div>
<div>(XEN) Initializing CPU#1</div><div>(XEN) CPU: L1 I cache: 32K, L1 D ca=
che: 32K</div><div>(XEN) CPU: L2 cache: 3072K</div><div>(XEN) CPU: Physical=
 Processor ID: 0</div><div>(XEN) CPU: Processor Core ID: 1</div><div>(XEN) =
CMCI: CPU1 has no CMCI support</div>
<div>(XEN) CPU1: Thermal monitoring enabled (TM2)</div><div>(XEN) CPU1: Int=
el(R) Core(TM)2 Duo CPU =A0 =A0 P8400 =A0@ 2.26GHz stepping 06</div><div>(X=
EN) microcode: CPU1 updated from revision 0x60c to 0x60f, date =3D 2010-09-=
29=A0</div>
<div>[ =A0 42.200055] ACPI: Low-level resume complete</div><div>[ =A0 42.20=
0055] PM: Restoring platform NVS memory</div><div>[ =A0 42.200055] Enabling=
 non-boot CPUs ...</div></div><div><br></div><div><br></div><div>Any pointe=
rs are appreciated.</div>
<div><br></div><div>/btg</div></div>

--14dae9340c892e5fe304caaddb7d--


--===============0132483815118084183==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============0132483815118084183==--


From xen-devel-bounces@lists.xen.org Thu Sep 27 13:10:09 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Sep 2012 13: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 1THDqY-000583-Cc; Thu, 27 Sep 2012 13:09:42 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1THDqW-00057r-UK
	for xen-devel@lists.xen.org; Thu, 27 Sep 2012 13:09:41 +0000
Received: from [85.158.143.99:23590] by server-2.bemta-4.messagelabs.com id
	44/13-06610-41054605; Thu, 27 Sep 2012 13:09:40 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1348751379!22218565!1
X-Originating-IP: [74.125.83.45]
X-SpamReason: No, hits=1.1 required=7.0 tests=HTML_40_50,HTML_MESSAGE,
	MIME_QP_LONG_LINE,ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30389 invoked from network); 27 Sep 2012 13:09:39 -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;
	27 Sep 2012 13:09:39 -0000
Received: by eekb47 with SMTP id b47so976379eek.32
	for <xen-devel@lists.xen.org>; Thu, 27 Sep 2012 06:09:39 -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;
	bh=rl/bf7z023crzn48ZDYU2iX8bspHLv2yAz5iz7BFUKE=;
	b=Stbw9oaIs5zZUNTE7Zf3oB83Y+HRSlZ2rSx3jTp/hsp/4uHGe5LpVUzsY2eYXIGbKN
	wrSFkS9+XIIX+05zA0C4nRgP281a2n2zG5ENIXNboxC1BdGLWXEinQRU0LAYoLagZx3L
	SaidmelUcI6O4w1krPx0FNekkNtGdbB+1oo1dFoLVbXCniGGqBwwaX0ypB6AkmG1GBR7
	NpZsKohk3PSNWBbQrFQ0F2vK2YVKcXMLE2kcCQCuWohkOcM98OOce1owU35qGxs2YEzs
	CSBxYHqWhSZYkpWJq4XsSL3HrZJg3jrSUM3nYUXTQyC5QfLwic66QKTs7n2hx9+7d2iO
	+uoQ==
Received: by 10.14.202.131 with SMTP id d3mr5871849eeo.32.1348751379307;
	Thu, 27 Sep 2012 06:09:39 -0700 (PDT)
Received: from [192.168.1.69]
	(host86-160-224-180.range86-160.btcentralplus.com. [86.160.224.180])
	by mx.google.com with ESMTPS id r45sm17596378eem.6.2012.09.27.06.09.37
	(version=SSLv3 cipher=OTHER); Thu, 27 Sep 2012 06:09:38 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Thu, 27 Sep 2012 14:09:35 +0100
From: Keir Fraser <keir.xen@gmail.com>
To: Lars Kurth <lars.kurth.xen@gmail.com>
Message-ID: <CC8A0E9F.400A6%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [ANNOUNCE] Switching to git for primary Xen
	repositories
Thread-Index: Ac2csVc3FyGvx3xHe02U33zKcrXWRg==
In-Reply-To: <CAOqnZH5qZAHOw2xLZXNF6KT6qGiqJmYR-L9BLaviBkjAOCAPFA@mail.gmail.com>
Mime-version: 1.0
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [ANNOUNCE] Switching to git for primary Xen
 repositories
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============2894814048581325928=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--===============2894814048581325928==
Content-type: multipart/alternative;
	boundary="B_3431599777_87635907"

> This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--B_3431599777_87635907
Content-type: text/plain;
	charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable

That would be fine by me!

 -- Keir

On 27/09/2012 13:00, "Lars Kurth" <lars.kurth.xen@gmail.com> wrote:

> Hi everybody,
> I am wondering whether it wouldn't be better to have a vote about this. A=
t
> least in this case, nobody will be able to complain in the future.
> Regards
> Lars
>=20
> On Sun, Sep 9, 2012 at 12:16 PM, Keir Fraser <keir.xen@gmail.com> wrote:
>> Folks,
>>=20
>> The Xen project has used mercurial for the primary repositories for many
>> years. However, with external projects (including Linux and qemu) using =
git,
>> this has led to us using and supporting two revision-control systems. Ou=
r
>> plan therefore, with the 4.2.0 release soon out of the way, is to switch=
 to
>> git for all of our primary repositories. We will plan to mirror developm=
ent
>> activity into the old mercurial repositories at least in the short term.
>>=20
>> We will make a further announcement nearer to the time of the switchover=
.
>>=20
>> =A0Regards,
>> =A0Keir & The Xen Team
>>=20
>>=20
>>=20
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xen.org
>> http://lists.xen.org/xen-devel
>=20
>=20


--B_3431599777_87635907
Content-type: text/html;
	charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable

<HTML>
<HEAD>
<TITLE>Re: [Xen-devel] [ANNOUNCE] Switching to git for primary Xen reposito=
ries</TITLE>
</HEAD>
<BODY>
<FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN STYLE=3D'font-size:11pt=
'>That would be fine by me!<BR>
<BR>
&nbsp;-- Keir<BR>
<BR>
On 27/09/2012 13:00, &quot;Lars Kurth&quot; &lt;<a href=3D"lars.kurth.xen@gma=
il.com">lars.kurth.xen@gmail.com</a>&gt; wrote:<BR>
<BR>
</SPAN></FONT><BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><=
SPAN STYLE=3D'font-size:11pt'>Hi everybody,<BR>
I am wondering whether it wouldn't be better to have a vote about this. At =
least in this case, nobody will be able to complain in the future.<BR>
Regards<BR>
Lars<BR>
<BR>
On Sun, Sep 9, 2012 at 12:16 PM, Keir Fraser &lt;<a href=3D"keir.xen@gmail.co=
m">keir.xen@gmail.com</a>&gt; wrote:<BR>
</SPAN></FONT><BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><=
SPAN STYLE=3D'font-size:11pt'>Folks,<BR>
<BR>
The Xen project has used mercurial for the primary repositories for many<BR=
>
years. However, with external projects (including Linux and qemu) using git=
,<BR>
this has led to us using and supporting two revision-control systems. Our<B=
R>
plan therefore, with the 4.2.0 release soon out of the way, is to switch to=
<BR>
git for all of our primary repositories. We will plan to mirror development=
<BR>
activity into the old mercurial repositories at least in the short term.<BR=
>
<BR>
We will make a further announcement nearer to the time of the switchover.<B=
R>
<BR>
=A0Regards,<BR>
=A0Keir &amp; The Xen Team<BR>
<BR>
<BR>
<BR>
_______________________________________________<BR>
Xen-devel mailing list<BR>
<a href=3D"Xen-devel@lists.xen.org">Xen-devel@lists.xen.org</a><BR>
<a href=3D"http://lists.xen.org/xen-devel">http://lists.xen.org/xen-devel</a>=
<BR>
</SPAN></FONT></BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial">=
<SPAN STYLE=3D'font-size:11pt'><BR>
<BR>
</SPAN></FONT></BLOCKQUOTE>
</BODY>
</HTML>


--B_3431599777_87635907--




--===============2894814048581325928==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============2894814048581325928==--




From xen-devel-bounces@lists.xen.org Thu Sep 27 13:10:09 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Sep 2012 13: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 1THDqY-000583-Cc; Thu, 27 Sep 2012 13:09:42 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1THDqW-00057r-UK
	for xen-devel@lists.xen.org; Thu, 27 Sep 2012 13:09:41 +0000
Received: from [85.158.143.99:23590] by server-2.bemta-4.messagelabs.com id
	44/13-06610-41054605; Thu, 27 Sep 2012 13:09:40 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1348751379!22218565!1
X-Originating-IP: [74.125.83.45]
X-SpamReason: No, hits=1.1 required=7.0 tests=HTML_40_50,HTML_MESSAGE,
	MIME_QP_LONG_LINE,ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30389 invoked from network); 27 Sep 2012 13:09:39 -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;
	27 Sep 2012 13:09:39 -0000
Received: by eekb47 with SMTP id b47so976379eek.32
	for <xen-devel@lists.xen.org>; Thu, 27 Sep 2012 06:09:39 -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;
	bh=rl/bf7z023crzn48ZDYU2iX8bspHLv2yAz5iz7BFUKE=;
	b=Stbw9oaIs5zZUNTE7Zf3oB83Y+HRSlZ2rSx3jTp/hsp/4uHGe5LpVUzsY2eYXIGbKN
	wrSFkS9+XIIX+05zA0C4nRgP281a2n2zG5ENIXNboxC1BdGLWXEinQRU0LAYoLagZx3L
	SaidmelUcI6O4w1krPx0FNekkNtGdbB+1oo1dFoLVbXCniGGqBwwaX0ypB6AkmG1GBR7
	NpZsKohk3PSNWBbQrFQ0F2vK2YVKcXMLE2kcCQCuWohkOcM98OOce1owU35qGxs2YEzs
	CSBxYHqWhSZYkpWJq4XsSL3HrZJg3jrSUM3nYUXTQyC5QfLwic66QKTs7n2hx9+7d2iO
	+uoQ==
Received: by 10.14.202.131 with SMTP id d3mr5871849eeo.32.1348751379307;
	Thu, 27 Sep 2012 06:09:39 -0700 (PDT)
Received: from [192.168.1.69]
	(host86-160-224-180.range86-160.btcentralplus.com. [86.160.224.180])
	by mx.google.com with ESMTPS id r45sm17596378eem.6.2012.09.27.06.09.37
	(version=SSLv3 cipher=OTHER); Thu, 27 Sep 2012 06:09:38 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Thu, 27 Sep 2012 14:09:35 +0100
From: Keir Fraser <keir.xen@gmail.com>
To: Lars Kurth <lars.kurth.xen@gmail.com>
Message-ID: <CC8A0E9F.400A6%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [ANNOUNCE] Switching to git for primary Xen
	repositories
Thread-Index: Ac2csVc3FyGvx3xHe02U33zKcrXWRg==
In-Reply-To: <CAOqnZH5qZAHOw2xLZXNF6KT6qGiqJmYR-L9BLaviBkjAOCAPFA@mail.gmail.com>
Mime-version: 1.0
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [ANNOUNCE] Switching to git for primary Xen
 repositories
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============2894814048581325928=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--===============2894814048581325928==
Content-type: multipart/alternative;
	boundary="B_3431599777_87635907"

> This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--B_3431599777_87635907
Content-type: text/plain;
	charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable

That would be fine by me!

 -- Keir

On 27/09/2012 13:00, "Lars Kurth" <lars.kurth.xen@gmail.com> wrote:

> Hi everybody,
> I am wondering whether it wouldn't be better to have a vote about this. A=
t
> least in this case, nobody will be able to complain in the future.
> Regards
> Lars
>=20
> On Sun, Sep 9, 2012 at 12:16 PM, Keir Fraser <keir.xen@gmail.com> wrote:
>> Folks,
>>=20
>> The Xen project has used mercurial for the primary repositories for many
>> years. However, with external projects (including Linux and qemu) using =
git,
>> this has led to us using and supporting two revision-control systems. Ou=
r
>> plan therefore, with the 4.2.0 release soon out of the way, is to switch=
 to
>> git for all of our primary repositories. We will plan to mirror developm=
ent
>> activity into the old mercurial repositories at least in the short term.
>>=20
>> We will make a further announcement nearer to the time of the switchover=
.
>>=20
>> =A0Regards,
>> =A0Keir & The Xen Team
>>=20
>>=20
>>=20
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xen.org
>> http://lists.xen.org/xen-devel
>=20
>=20


--B_3431599777_87635907
Content-type: text/html;
	charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable

<HTML>
<HEAD>
<TITLE>Re: [Xen-devel] [ANNOUNCE] Switching to git for primary Xen reposito=
ries</TITLE>
</HEAD>
<BODY>
<FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN STYLE=3D'font-size:11pt=
'>That would be fine by me!<BR>
<BR>
&nbsp;-- Keir<BR>
<BR>
On 27/09/2012 13:00, &quot;Lars Kurth&quot; &lt;<a href=3D"lars.kurth.xen@gma=
il.com">lars.kurth.xen@gmail.com</a>&gt; wrote:<BR>
<BR>
</SPAN></FONT><BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><=
SPAN STYLE=3D'font-size:11pt'>Hi everybody,<BR>
I am wondering whether it wouldn't be better to have a vote about this. At =
least in this case, nobody will be able to complain in the future.<BR>
Regards<BR>
Lars<BR>
<BR>
On Sun, Sep 9, 2012 at 12:16 PM, Keir Fraser &lt;<a href=3D"keir.xen@gmail.co=
m">keir.xen@gmail.com</a>&gt; wrote:<BR>
</SPAN></FONT><BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><=
SPAN STYLE=3D'font-size:11pt'>Folks,<BR>
<BR>
The Xen project has used mercurial for the primary repositories for many<BR=
>
years. However, with external projects (including Linux and qemu) using git=
,<BR>
this has led to us using and supporting two revision-control systems. Our<B=
R>
plan therefore, with the 4.2.0 release soon out of the way, is to switch to=
<BR>
git for all of our primary repositories. We will plan to mirror development=
<BR>
activity into the old mercurial repositories at least in the short term.<BR=
>
<BR>
We will make a further announcement nearer to the time of the switchover.<B=
R>
<BR>
=A0Regards,<BR>
=A0Keir &amp; The Xen Team<BR>
<BR>
<BR>
<BR>
_______________________________________________<BR>
Xen-devel mailing list<BR>
<a href=3D"Xen-devel@lists.xen.org">Xen-devel@lists.xen.org</a><BR>
<a href=3D"http://lists.xen.org/xen-devel">http://lists.xen.org/xen-devel</a>=
<BR>
</SPAN></FONT></BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial">=
<SPAN STYLE=3D'font-size:11pt'><BR>
<BR>
</SPAN></FONT></BLOCKQUOTE>
</BODY>
</HTML>


--B_3431599777_87635907--




--===============2894814048581325928==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============2894814048581325928==--




From xen-devel-bounces@lists.xen.org Thu Sep 27 13:10:18 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Sep 2012 13: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 1THDqt-0005A8-Pi; Thu, 27 Sep 2012 13:10:03 +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 1THDqs-00059m-92
	for xen-devel@lists.xen.org; Thu, 27 Sep 2012 13:10:02 +0000
Received: from [85.158.138.51:39047] by server-9.bemta-3.messagelabs.com id
	BA/F0-20338-92054605; Thu, 27 Sep 2012 13:10:01 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-4.tower-174.messagelabs.com!1348751399!31700944!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5507 invoked from network); 27 Sep 2012 13:10:00 -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; 27 Sep 2012 13:10:00 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1THDqm-0002sa-5X; Thu, 27 Sep 2012 13:09:56 +0000
Date: Thu, 27 Sep 2012 14:09:56 +0100
From: Tim Deegan <tim@xen.org>
To: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Message-ID: <20120927130956.GE8831@ocelot.phlegethon.org>
References: <1347895425-17959-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1347895425-17959-19-git-send-email-dgdegra@tycho.nsa.gov>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1347895425-17959-19-git-send-email-dgdegra@tycho.nsa.gov>
User-Agent: Mutt/1.4.2.1i
Cc: Joe Epstein <jepstein98@gmail.com>, keir@xen.org,
	Jan Beulich <jbeulich@suse.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 18/23] arch/x86: Add missing mem_sharing XSM
	hooks
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Cc'ing Joe, the author of the original check I'm talking about below. 

At 11:23 -0400 on 17 Sep (1347881020), Daniel De Graaf wrote:
> diff --git a/xen/arch/x86/domctl.c b/xen/arch/x86/domctl.c
> index 24e2d93..7062f02 100644
> --- a/xen/arch/x86/domctl.c
> +++ b/xen/arch/x86/domctl.c
> @@ -1447,10 +1447,8 @@ long arch_do_domctl(
>          d = rcu_lock_domain_by_id(domctl->domain);
>          if ( d != NULL )
>          {
> -            ret = xsm_mem_event(d);
> -            if ( !ret )
> -                ret = mem_event_domctl(d, &domctl->u.mem_event_op,
> -                                       guest_handle_cast(u_domctl, void));
> +            ret = mem_event_domctl(d, &domctl->u.mem_event_op,
> +                                   guest_handle_cast(u_domctl, void));
>              rcu_unlock_domain(d);
>              copy_to_guest(u_domctl, domctl, 1);
>          } 
> @@ -1506,7 +1504,7 @@ long arch_do_domctl(
>          d = rcu_lock_domain_by_id(domctl->domain);
>          if ( d != NULL )
>          {
> -            ret = xsm_mem_event(d);
> +            ret = xsm_mem_event_setup(d);
>              if ( !ret ) {
>                  p2m = p2m_get_hostp2m(d);
>                  p2m->access_required = domctl->u.access_required.access_required;

[...]

> diff --git a/xen/include/xsm/dummy.h b/xen/include/xsm/dummy.h
> index 626a332..5fb0afe 100644
> --- a/xen/include/xsm/dummy.h
> +++ b/xen/include/xsm/dummy.h
> @@ -551,16 +551,37 @@ static XSM_DEFAULT(int, hvm_inject_msi) (struct domain *d)
>      return 0;
>  }
>  
> -static XSM_DEFAULT(int, mem_event) (struct domain *d)
> +static XSM_DEFAULT(int, mem_event_setup) (struct domain *d)
>  {
>      return 0;
>  }

I think this ought to be at least IS_PRIV_FOR.  I can see the original
code allowed all callers to use it, but surely it ought to be only for
the tools.  Since only the tools can actually set the mem-access rights
(and so this is pretty much a noop) I don't think this causes any
substantial problem but we might as well adjust it anyway.

Tim.

> +static XSM_DEFAULT(int, mem_event_control) (struct domain *d, int mode, int op)
> +{
> +    if ( !IS_PRIV(current->domain) )
> +        return -EPERM;
> +    return 0;
> +}
> +
> +static XSM_DEFAULT(int, mem_event_op) (struct domain *d, int op)
> +{
> +    if ( !IS_PRIV_FOR(current->domain, d) )
> +        return -EPERM;
> +    return 0;
> +}
> +
>  static XSM_DEFAULT(int, mem_sharing) (struct domain *d)
>  {
>      return 0;
>  }
>  
> +static XSM_DEFAULT(int, mem_sharing_op) (struct domain *d, struct domain *cd, int op)
> +{
> +    if ( !IS_PRIV_FOR(current->domain, cd) )
> +        return -EPERM;
> +    return 0;
> +}
> +
>  static XSM_DEFAULT(int, apic) (struct domain *d, int cmd)
>  {
>      if ( !IS_PRIV(d) )
> diff --git a/xen/include/xsm/xsm.h b/xen/include/xsm/xsm.h
> index 96e4b13..c08a664 100644
> --- a/xen/include/xsm/xsm.h
> +++ b/xen/include/xsm/xsm.h
> @@ -151,8 +151,11 @@ struct xsm_operations {
>      int (*hvm_set_isa_irq_level) (struct domain *d);
>      int (*hvm_set_pci_link_route) (struct domain *d);
>      int (*hvm_inject_msi) (struct domain *d);
> -    int (*mem_event) (struct domain *d);
> +    int (*mem_event_setup) (struct domain *d);
> +    int (*mem_event_control) (struct domain *d, int mode, int op);
> +    int (*mem_event_op) (struct domain *d, int op);
>      int (*mem_sharing) (struct domain *d);
> +    int (*mem_sharing_op) (struct domain *d, struct domain *cd, int op);
>      int (*apic) (struct domain *d, int cmd);
>      int (*xen_settime) (void);
>      int (*memtype) (uint32_t access);
> @@ -663,9 +666,19 @@ static inline int xsm_hvm_inject_msi (struct domain *d)
>      return xsm_ops->hvm_inject_msi(d);
>  }
>  
> -static inline int xsm_mem_event (struct domain *d)
> +static inline int xsm_mem_event_setup (struct domain *d)
>  {
> -    return xsm_ops->mem_event(d);
> +    return xsm_ops->mem_event_setup(d);
> +}
> +
> +static inline int xsm_mem_event_control (struct domain *d, int mode, int op)
> +{
> +    return xsm_ops->mem_event_control(d, mode, op);
> +}
> +
> +static inline int xsm_mem_event_op (struct domain *d, int op)
> +{
> +    return xsm_ops->mem_event_op(d, op);
>  }
>  
>  static inline int xsm_mem_sharing (struct domain *d)
> @@ -673,6 +686,11 @@ static inline int xsm_mem_sharing (struct domain *d)
>      return xsm_ops->mem_sharing(d);
>  }
>  
> +static inline int xsm_mem_sharing_op (struct domain *d, struct domain *cd, int op)
> +{
> +    return xsm_ops->mem_sharing_op(d, cd, op);
> +}
> +
>  static inline int xsm_apic (struct domain *d, int cmd)
>  {
>      return xsm_ops->apic(d, cmd);
> diff --git a/xen/xsm/dummy.c b/xen/xsm/dummy.c
> index 43e8617..3926b2b 100644
> --- a/xen/xsm/dummy.c
> +++ b/xen/xsm/dummy.c
> @@ -135,8 +135,11 @@ void xsm_fixup_ops (struct xsm_operations *ops)
>      set_to_dummy_if_null(ops, hvm_set_isa_irq_level);
>      set_to_dummy_if_null(ops, hvm_set_pci_link_route);
>      set_to_dummy_if_null(ops, hvm_inject_msi);
> -    set_to_dummy_if_null(ops, mem_event);
> +    set_to_dummy_if_null(ops, mem_event_setup);
> +    set_to_dummy_if_null(ops, mem_event_control);
> +    set_to_dummy_if_null(ops, mem_event_op);
>      set_to_dummy_if_null(ops, mem_sharing);
> +    set_to_dummy_if_null(ops, mem_sharing_op);
>      set_to_dummy_if_null(ops, apic);
>      set_to_dummy_if_null(ops, xen_settime);
>      set_to_dummy_if_null(ops, memtype);
> diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
> index a242d65..65db2b7 100644
> --- a/xen/xsm/flask/hooks.c
> +++ b/xen/xsm/flask/hooks.c
> @@ -1277,7 +1277,17 @@ static int flask_hvm_inject_msi(struct domain *d)
>      return current_has_perm(d, SECCLASS_HVM, HVM__SEND_IRQ);
>  }
>  
> -static int flask_mem_event(struct domain *d)
> +static int flask_mem_event_setup(struct domain *d)
> +{
> +    return current_has_perm(d, SECCLASS_HVM, HVM__MEM_EVENT);
> +}
> +
> +static int flask_mem_event_control(struct domain *d, int mode, int op)
> +{
> +    return current_has_perm(d, SECCLASS_HVM, HVM__MEM_EVENT);
> +}
> +
> +static int flask_mem_event_op(struct domain *d, int op)
>  {
>      return current_has_perm(d, SECCLASS_HVM, HVM__MEM_EVENT);
>  }
> @@ -1287,6 +1297,14 @@ static int flask_mem_sharing(struct domain *d)
>      return current_has_perm(d, SECCLASS_HVM, HVM__MEM_SHARING);
>  }
>  
> +static int flask_mem_sharing_op(struct domain *d, struct domain *cd, int op)
> +{
> +    int rc = current_has_perm(cd, SECCLASS_HVM, HVM__MEM_SHARING);
> +    if ( rc )
> +        return rc;
> +    return domain_has_perm(d, cd, SECCLASS_HVM, HVM__SHARE_MEM);
> +}
> +
>  static int flask_apic(struct domain *d, int cmd)
>  {
>      u32 perm;
> @@ -1736,8 +1754,11 @@ static struct xsm_operations flask_ops = {
>      .hvm_set_isa_irq_level = flask_hvm_set_isa_irq_level,
>      .hvm_set_pci_link_route = flask_hvm_set_pci_link_route,
>      .hvm_inject_msi = flask_hvm_inject_msi,
> -    .mem_event = flask_mem_event,
> +    .mem_event_setup = flask_mem_event_setup,
> +    .mem_event_control = flask_mem_event_control,
> +    .mem_event_op = flask_mem_event_op,
>      .mem_sharing = flask_mem_sharing,
> +    .mem_sharing_op = flask_mem_sharing_op,
>      .apic = flask_apic,
>      .xen_settime = flask_xen_settime,
>      .memtype = flask_memtype,
> diff --git a/xen/xsm/flask/include/av_perm_to_string.h b/xen/xsm/flask/include/av_perm_to_string.h
> index 894910c..186f1fa 100644
> --- a/xen/xsm/flask/include/av_perm_to_string.h
> +++ b/xen/xsm/flask/include/av_perm_to_string.h
> @@ -84,6 +84,7 @@
>     S_(SECCLASS_HVM, HVM__MEM_SHARING, "mem_sharing")
>     S_(SECCLASS_HVM, HVM__AUDIT_P2M, "audit_p2m")
>     S_(SECCLASS_HVM, HVM__SEND_IRQ, "send_irq")
> +   S_(SECCLASS_HVM, HVM__SHARE_MEM, "share_mem")
>     S_(SECCLASS_EVENT, EVENT__BIND, "bind")
>     S_(SECCLASS_EVENT, EVENT__SEND, "send")
>     S_(SECCLASS_EVENT, EVENT__STATUS, "status")
> diff --git a/xen/xsm/flask/include/av_permissions.h b/xen/xsm/flask/include/av_permissions.h
> index 1bdb515..b3831f6 100644
> --- a/xen/xsm/flask/include/av_permissions.h
> +++ b/xen/xsm/flask/include/av_permissions.h
> @@ -87,6 +87,7 @@
>  #define HVM__MEM_SHARING                          0x00001000UL
>  #define HVM__AUDIT_P2M                            0x00002000UL
>  #define HVM__SEND_IRQ                             0x00004000UL
> +#define HVM__SHARE_MEM                            0x00008000UL
>  
>  #define EVENT__BIND                               0x00000001UL
>  #define EVENT__SEND                               0x00000002UL
> -- 
> 1.7.11.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 Thu Sep 27 13:10:18 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Sep 2012 13: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 1THDqt-0005A8-Pi; Thu, 27 Sep 2012 13:10:03 +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 1THDqs-00059m-92
	for xen-devel@lists.xen.org; Thu, 27 Sep 2012 13:10:02 +0000
Received: from [85.158.138.51:39047] by server-9.bemta-3.messagelabs.com id
	BA/F0-20338-92054605; Thu, 27 Sep 2012 13:10:01 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-4.tower-174.messagelabs.com!1348751399!31700944!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5507 invoked from network); 27 Sep 2012 13:10:00 -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; 27 Sep 2012 13:10:00 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1THDqm-0002sa-5X; Thu, 27 Sep 2012 13:09:56 +0000
Date: Thu, 27 Sep 2012 14:09:56 +0100
From: Tim Deegan <tim@xen.org>
To: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Message-ID: <20120927130956.GE8831@ocelot.phlegethon.org>
References: <1347895425-17959-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1347895425-17959-19-git-send-email-dgdegra@tycho.nsa.gov>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1347895425-17959-19-git-send-email-dgdegra@tycho.nsa.gov>
User-Agent: Mutt/1.4.2.1i
Cc: Joe Epstein <jepstein98@gmail.com>, keir@xen.org,
	Jan Beulich <jbeulich@suse.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 18/23] arch/x86: Add missing mem_sharing XSM
	hooks
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Cc'ing Joe, the author of the original check I'm talking about below. 

At 11:23 -0400 on 17 Sep (1347881020), Daniel De Graaf wrote:
> diff --git a/xen/arch/x86/domctl.c b/xen/arch/x86/domctl.c
> index 24e2d93..7062f02 100644
> --- a/xen/arch/x86/domctl.c
> +++ b/xen/arch/x86/domctl.c
> @@ -1447,10 +1447,8 @@ long arch_do_domctl(
>          d = rcu_lock_domain_by_id(domctl->domain);
>          if ( d != NULL )
>          {
> -            ret = xsm_mem_event(d);
> -            if ( !ret )
> -                ret = mem_event_domctl(d, &domctl->u.mem_event_op,
> -                                       guest_handle_cast(u_domctl, void));
> +            ret = mem_event_domctl(d, &domctl->u.mem_event_op,
> +                                   guest_handle_cast(u_domctl, void));
>              rcu_unlock_domain(d);
>              copy_to_guest(u_domctl, domctl, 1);
>          } 
> @@ -1506,7 +1504,7 @@ long arch_do_domctl(
>          d = rcu_lock_domain_by_id(domctl->domain);
>          if ( d != NULL )
>          {
> -            ret = xsm_mem_event(d);
> +            ret = xsm_mem_event_setup(d);
>              if ( !ret ) {
>                  p2m = p2m_get_hostp2m(d);
>                  p2m->access_required = domctl->u.access_required.access_required;

[...]

> diff --git a/xen/include/xsm/dummy.h b/xen/include/xsm/dummy.h
> index 626a332..5fb0afe 100644
> --- a/xen/include/xsm/dummy.h
> +++ b/xen/include/xsm/dummy.h
> @@ -551,16 +551,37 @@ static XSM_DEFAULT(int, hvm_inject_msi) (struct domain *d)
>      return 0;
>  }
>  
> -static XSM_DEFAULT(int, mem_event) (struct domain *d)
> +static XSM_DEFAULT(int, mem_event_setup) (struct domain *d)
>  {
>      return 0;
>  }

I think this ought to be at least IS_PRIV_FOR.  I can see the original
code allowed all callers to use it, but surely it ought to be only for
the tools.  Since only the tools can actually set the mem-access rights
(and so this is pretty much a noop) I don't think this causes any
substantial problem but we might as well adjust it anyway.

Tim.

> +static XSM_DEFAULT(int, mem_event_control) (struct domain *d, int mode, int op)
> +{
> +    if ( !IS_PRIV(current->domain) )
> +        return -EPERM;
> +    return 0;
> +}
> +
> +static XSM_DEFAULT(int, mem_event_op) (struct domain *d, int op)
> +{
> +    if ( !IS_PRIV_FOR(current->domain, d) )
> +        return -EPERM;
> +    return 0;
> +}
> +
>  static XSM_DEFAULT(int, mem_sharing) (struct domain *d)
>  {
>      return 0;
>  }
>  
> +static XSM_DEFAULT(int, mem_sharing_op) (struct domain *d, struct domain *cd, int op)
> +{
> +    if ( !IS_PRIV_FOR(current->domain, cd) )
> +        return -EPERM;
> +    return 0;
> +}
> +
>  static XSM_DEFAULT(int, apic) (struct domain *d, int cmd)
>  {
>      if ( !IS_PRIV(d) )
> diff --git a/xen/include/xsm/xsm.h b/xen/include/xsm/xsm.h
> index 96e4b13..c08a664 100644
> --- a/xen/include/xsm/xsm.h
> +++ b/xen/include/xsm/xsm.h
> @@ -151,8 +151,11 @@ struct xsm_operations {
>      int (*hvm_set_isa_irq_level) (struct domain *d);
>      int (*hvm_set_pci_link_route) (struct domain *d);
>      int (*hvm_inject_msi) (struct domain *d);
> -    int (*mem_event) (struct domain *d);
> +    int (*mem_event_setup) (struct domain *d);
> +    int (*mem_event_control) (struct domain *d, int mode, int op);
> +    int (*mem_event_op) (struct domain *d, int op);
>      int (*mem_sharing) (struct domain *d);
> +    int (*mem_sharing_op) (struct domain *d, struct domain *cd, int op);
>      int (*apic) (struct domain *d, int cmd);
>      int (*xen_settime) (void);
>      int (*memtype) (uint32_t access);
> @@ -663,9 +666,19 @@ static inline int xsm_hvm_inject_msi (struct domain *d)
>      return xsm_ops->hvm_inject_msi(d);
>  }
>  
> -static inline int xsm_mem_event (struct domain *d)
> +static inline int xsm_mem_event_setup (struct domain *d)
>  {
> -    return xsm_ops->mem_event(d);
> +    return xsm_ops->mem_event_setup(d);
> +}
> +
> +static inline int xsm_mem_event_control (struct domain *d, int mode, int op)
> +{
> +    return xsm_ops->mem_event_control(d, mode, op);
> +}
> +
> +static inline int xsm_mem_event_op (struct domain *d, int op)
> +{
> +    return xsm_ops->mem_event_op(d, op);
>  }
>  
>  static inline int xsm_mem_sharing (struct domain *d)
> @@ -673,6 +686,11 @@ static inline int xsm_mem_sharing (struct domain *d)
>      return xsm_ops->mem_sharing(d);
>  }
>  
> +static inline int xsm_mem_sharing_op (struct domain *d, struct domain *cd, int op)
> +{
> +    return xsm_ops->mem_sharing_op(d, cd, op);
> +}
> +
>  static inline int xsm_apic (struct domain *d, int cmd)
>  {
>      return xsm_ops->apic(d, cmd);
> diff --git a/xen/xsm/dummy.c b/xen/xsm/dummy.c
> index 43e8617..3926b2b 100644
> --- a/xen/xsm/dummy.c
> +++ b/xen/xsm/dummy.c
> @@ -135,8 +135,11 @@ void xsm_fixup_ops (struct xsm_operations *ops)
>      set_to_dummy_if_null(ops, hvm_set_isa_irq_level);
>      set_to_dummy_if_null(ops, hvm_set_pci_link_route);
>      set_to_dummy_if_null(ops, hvm_inject_msi);
> -    set_to_dummy_if_null(ops, mem_event);
> +    set_to_dummy_if_null(ops, mem_event_setup);
> +    set_to_dummy_if_null(ops, mem_event_control);
> +    set_to_dummy_if_null(ops, mem_event_op);
>      set_to_dummy_if_null(ops, mem_sharing);
> +    set_to_dummy_if_null(ops, mem_sharing_op);
>      set_to_dummy_if_null(ops, apic);
>      set_to_dummy_if_null(ops, xen_settime);
>      set_to_dummy_if_null(ops, memtype);
> diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
> index a242d65..65db2b7 100644
> --- a/xen/xsm/flask/hooks.c
> +++ b/xen/xsm/flask/hooks.c
> @@ -1277,7 +1277,17 @@ static int flask_hvm_inject_msi(struct domain *d)
>      return current_has_perm(d, SECCLASS_HVM, HVM__SEND_IRQ);
>  }
>  
> -static int flask_mem_event(struct domain *d)
> +static int flask_mem_event_setup(struct domain *d)
> +{
> +    return current_has_perm(d, SECCLASS_HVM, HVM__MEM_EVENT);
> +}
> +
> +static int flask_mem_event_control(struct domain *d, int mode, int op)
> +{
> +    return current_has_perm(d, SECCLASS_HVM, HVM__MEM_EVENT);
> +}
> +
> +static int flask_mem_event_op(struct domain *d, int op)
>  {
>      return current_has_perm(d, SECCLASS_HVM, HVM__MEM_EVENT);
>  }
> @@ -1287,6 +1297,14 @@ static int flask_mem_sharing(struct domain *d)
>      return current_has_perm(d, SECCLASS_HVM, HVM__MEM_SHARING);
>  }
>  
> +static int flask_mem_sharing_op(struct domain *d, struct domain *cd, int op)
> +{
> +    int rc = current_has_perm(cd, SECCLASS_HVM, HVM__MEM_SHARING);
> +    if ( rc )
> +        return rc;
> +    return domain_has_perm(d, cd, SECCLASS_HVM, HVM__SHARE_MEM);
> +}
> +
>  static int flask_apic(struct domain *d, int cmd)
>  {
>      u32 perm;
> @@ -1736,8 +1754,11 @@ static struct xsm_operations flask_ops = {
>      .hvm_set_isa_irq_level = flask_hvm_set_isa_irq_level,
>      .hvm_set_pci_link_route = flask_hvm_set_pci_link_route,
>      .hvm_inject_msi = flask_hvm_inject_msi,
> -    .mem_event = flask_mem_event,
> +    .mem_event_setup = flask_mem_event_setup,
> +    .mem_event_control = flask_mem_event_control,
> +    .mem_event_op = flask_mem_event_op,
>      .mem_sharing = flask_mem_sharing,
> +    .mem_sharing_op = flask_mem_sharing_op,
>      .apic = flask_apic,
>      .xen_settime = flask_xen_settime,
>      .memtype = flask_memtype,
> diff --git a/xen/xsm/flask/include/av_perm_to_string.h b/xen/xsm/flask/include/av_perm_to_string.h
> index 894910c..186f1fa 100644
> --- a/xen/xsm/flask/include/av_perm_to_string.h
> +++ b/xen/xsm/flask/include/av_perm_to_string.h
> @@ -84,6 +84,7 @@
>     S_(SECCLASS_HVM, HVM__MEM_SHARING, "mem_sharing")
>     S_(SECCLASS_HVM, HVM__AUDIT_P2M, "audit_p2m")
>     S_(SECCLASS_HVM, HVM__SEND_IRQ, "send_irq")
> +   S_(SECCLASS_HVM, HVM__SHARE_MEM, "share_mem")
>     S_(SECCLASS_EVENT, EVENT__BIND, "bind")
>     S_(SECCLASS_EVENT, EVENT__SEND, "send")
>     S_(SECCLASS_EVENT, EVENT__STATUS, "status")
> diff --git a/xen/xsm/flask/include/av_permissions.h b/xen/xsm/flask/include/av_permissions.h
> index 1bdb515..b3831f6 100644
> --- a/xen/xsm/flask/include/av_permissions.h
> +++ b/xen/xsm/flask/include/av_permissions.h
> @@ -87,6 +87,7 @@
>  #define HVM__MEM_SHARING                          0x00001000UL
>  #define HVM__AUDIT_P2M                            0x00002000UL
>  #define HVM__SEND_IRQ                             0x00004000UL
> +#define HVM__SHARE_MEM                            0x00008000UL
>  
>  #define EVENT__BIND                               0x00000001UL
>  #define EVENT__SEND                               0x00000002UL
> -- 
> 1.7.11.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 Thu Sep 27 13:41:25 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Sep 2012 13:41:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1THEKv-00067h-CK; Thu, 27 Sep 2012 13:41:05 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1THEKt-00067a-B6
	for xen-devel@lists.xen.org; Thu, 27 Sep 2012 13:41:03 +0000
Received: from [85.158.143.35:9311] by server-2.bemta-4.messagelabs.com id
	B2/E9-06610-E6754605; Thu, 27 Sep 2012 13:41:02 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1348753256!9116340!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30394 invoked from network); 27 Sep 2012 13:40: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;
	27 Sep 2012 13:40:56 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 27 Sep 2012 14:40:54 +0100
Message-Id: <5064739D020000780009E3EF@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 27 Sep 2012 14:41:17 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ben Guthro" <ben@guthro.net>
References: <CAOvdn6UCF2A3yP1cqWn=dxwr0ayRbr+rg+xj8META9Dm0+CoNw@mail.gmail.com>
	<CC868168.3FD29%keir.xen@gmail.com>
	<CAOvdn6U-JyLvt96gkLkqzi088tU9_ktv4D+fkJac_BKVe05Y-w@mail.gmail.com>
	<CAOvdn6V+s3AbRzsu8VArbmrZou=im9SqvPf-9Wpif_BrNMv=yg@mail.gmail.com>
	<50617297020000780009D8AA@nat28.tlf.novell.com>
	<CAOvdn6Vsnbcd7m8mh3tSgn3KaEoeiOyVD1mr3uQ3bN=rF=pDUQ@mail.gmail.com>
	<5062F880020000780009DF3B@nat28.tlf.novell.com>
	<CAOvdn6VyAVg24=c1OxqttxuGFyN_NzpfZ7RoCYc2mVF84c5big@mail.gmail.com>
	<50641E86020000780009E2E3@nat28.tlf.novell.com>
	<CAOvdn6VE13fOSjrKU4Ryr=344u+YwygASj6z1ag_U-x-qvOC9g@mail.gmail.com>
In-Reply-To: <CAOvdn6VE13fOSjrKU4Ryr=344u+YwygASj6z1ag_U-x-qvOC9g@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Keir Fraser <keir.xen@gmail.com>, John Baboval <john.baboval@citrix.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen4.2 S3 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 27.09.12 at 14:12, Ben Guthro <ben@guthro.net> wrote:
> On Thu, Sep 27, 2012 at 3:38 AM, Jan Beulich <JBeulich@suse.com> wrote:
>> > (XEN) microcode: collect_cpu_info for CPU0
>> > (XEN) microcode: collect_cpu_info : sig=0x10676, pf=0x80, rev=0x60c
>> > (XEN) microcode: collect_cpu_info for CPU1
>> > (XEN) microcode: collect_cpu_info : sig=0x10676, pf=0x80, rev=0x60f
>>
>> And in the end we see that both cores run on different revisions.
>>
>>
> very interesting. I had overlooked that.
> 
> 
>> The mixup of Xen and Dom0 messages puzzles me too - in my
>> understanding, all APs should be brought back up before
>> domains get unpaused. Is that perhaps part of your problem
>> with pinned vCPU-s? Or is the mixup not indicative of things
>> actually happening in parallel?
>>
> 
> It seems like it may be related, but I'm unsure how.
> When I run without the dom0_vcpu_pin option, I don't see the
> collect_cpu_info messages,
> nor do I see the microcode revision printout for CPU0

That's more likely because of either running different
(unpatched) code, or at a lower log level, because ...

> nor do I see the dom0 / Xen messages mised up.
> 
> [   41.567458] ACPI: Preparing to enter system sleep state S3
> [   42.020120] PM: Saving platform NVS memory
> [   42.092643] Disabling non-boot CPUs ...
> (XEN) Preparing system for ACPI S3 state.
> (XEN) Disabling non-boot CPUs ...
> (XEN) Entering ACPI S3 state.
> (XEN) mce_intel.c:1239: MCA Capability: BCAST 1 SER 0 CMCI 0 firstbank 1 extended MCE MSR 0
> (XEN) CMCI: CPU0 has no CMCI support
> (XEN) CPU0: Thermal monitoring enabled (TM2)
> (XEN) Finishing wakeup from ACPI S3 state.
> (XEN) Enabling non-boot CPUs  ...
> (XEN) Booting processor 1/1 eip 8a000
> (XEN) Initializing CPU#1
> (XEN) CPU: L1 I cache: 32K, L1 D cache: 32K
> (XEN) CPU: L2 cache: 3072K
> (XEN) CPU: Physical Processor ID: 0
> (XEN) CPU: Processor Core ID: 1
> (XEN) CMCI: CPU1 has no CMCI support
> (XEN) CPU1: Thermal monitoring enabled (TM2)
> (XEN) CPU1: Intel(R) Core(TM)2 Duo CPU     P8400  @ 2.26GHz stepping 06
> (XEN) microcode: CPU1 updated from revision 0x60c to 0x60f, date = 2010-09-29

... you can't get here without going through collect_cpu_info().

> [   42.200055] ACPI: Low-level resume complete
> [   42.200055] PM: Restoring platform NVS memory
> [   42.200055] Enabling non-boot CPUs ...
> 
> 
> Any pointers are appreciated.

Same for me (regarding the mixup of messages). Maybe widening
the console_{start,end}_sync() window from right after freezing
domains until right before thawing them could make clear whether
this is an artifact.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 27 13:41:25 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Sep 2012 13:41:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1THEKv-00067h-CK; Thu, 27 Sep 2012 13:41:05 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1THEKt-00067a-B6
	for xen-devel@lists.xen.org; Thu, 27 Sep 2012 13:41:03 +0000
Received: from [85.158.143.35:9311] by server-2.bemta-4.messagelabs.com id
	B2/E9-06610-E6754605; Thu, 27 Sep 2012 13:41:02 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1348753256!9116340!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30394 invoked from network); 27 Sep 2012 13:40: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;
	27 Sep 2012 13:40:56 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 27 Sep 2012 14:40:54 +0100
Message-Id: <5064739D020000780009E3EF@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 27 Sep 2012 14:41:17 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ben Guthro" <ben@guthro.net>
References: <CAOvdn6UCF2A3yP1cqWn=dxwr0ayRbr+rg+xj8META9Dm0+CoNw@mail.gmail.com>
	<CC868168.3FD29%keir.xen@gmail.com>
	<CAOvdn6U-JyLvt96gkLkqzi088tU9_ktv4D+fkJac_BKVe05Y-w@mail.gmail.com>
	<CAOvdn6V+s3AbRzsu8VArbmrZou=im9SqvPf-9Wpif_BrNMv=yg@mail.gmail.com>
	<50617297020000780009D8AA@nat28.tlf.novell.com>
	<CAOvdn6Vsnbcd7m8mh3tSgn3KaEoeiOyVD1mr3uQ3bN=rF=pDUQ@mail.gmail.com>
	<5062F880020000780009DF3B@nat28.tlf.novell.com>
	<CAOvdn6VyAVg24=c1OxqttxuGFyN_NzpfZ7RoCYc2mVF84c5big@mail.gmail.com>
	<50641E86020000780009E2E3@nat28.tlf.novell.com>
	<CAOvdn6VE13fOSjrKU4Ryr=344u+YwygASj6z1ag_U-x-qvOC9g@mail.gmail.com>
In-Reply-To: <CAOvdn6VE13fOSjrKU4Ryr=344u+YwygASj6z1ag_U-x-qvOC9g@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Keir Fraser <keir.xen@gmail.com>, John Baboval <john.baboval@citrix.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen4.2 S3 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 27.09.12 at 14:12, Ben Guthro <ben@guthro.net> wrote:
> On Thu, Sep 27, 2012 at 3:38 AM, Jan Beulich <JBeulich@suse.com> wrote:
>> > (XEN) microcode: collect_cpu_info for CPU0
>> > (XEN) microcode: collect_cpu_info : sig=0x10676, pf=0x80, rev=0x60c
>> > (XEN) microcode: collect_cpu_info for CPU1
>> > (XEN) microcode: collect_cpu_info : sig=0x10676, pf=0x80, rev=0x60f
>>
>> And in the end we see that both cores run on different revisions.
>>
>>
> very interesting. I had overlooked that.
> 
> 
>> The mixup of Xen and Dom0 messages puzzles me too - in my
>> understanding, all APs should be brought back up before
>> domains get unpaused. Is that perhaps part of your problem
>> with pinned vCPU-s? Or is the mixup not indicative of things
>> actually happening in parallel?
>>
> 
> It seems like it may be related, but I'm unsure how.
> When I run without the dom0_vcpu_pin option, I don't see the
> collect_cpu_info messages,
> nor do I see the microcode revision printout for CPU0

That's more likely because of either running different
(unpatched) code, or at a lower log level, because ...

> nor do I see the dom0 / Xen messages mised up.
> 
> [   41.567458] ACPI: Preparing to enter system sleep state S3
> [   42.020120] PM: Saving platform NVS memory
> [   42.092643] Disabling non-boot CPUs ...
> (XEN) Preparing system for ACPI S3 state.
> (XEN) Disabling non-boot CPUs ...
> (XEN) Entering ACPI S3 state.
> (XEN) mce_intel.c:1239: MCA Capability: BCAST 1 SER 0 CMCI 0 firstbank 1 extended MCE MSR 0
> (XEN) CMCI: CPU0 has no CMCI support
> (XEN) CPU0: Thermal monitoring enabled (TM2)
> (XEN) Finishing wakeup from ACPI S3 state.
> (XEN) Enabling non-boot CPUs  ...
> (XEN) Booting processor 1/1 eip 8a000
> (XEN) Initializing CPU#1
> (XEN) CPU: L1 I cache: 32K, L1 D cache: 32K
> (XEN) CPU: L2 cache: 3072K
> (XEN) CPU: Physical Processor ID: 0
> (XEN) CPU: Processor Core ID: 1
> (XEN) CMCI: CPU1 has no CMCI support
> (XEN) CPU1: Thermal monitoring enabled (TM2)
> (XEN) CPU1: Intel(R) Core(TM)2 Duo CPU     P8400  @ 2.26GHz stepping 06
> (XEN) microcode: CPU1 updated from revision 0x60c to 0x60f, date = 2010-09-29

... you can't get here without going through collect_cpu_info().

> [   42.200055] ACPI: Low-level resume complete
> [   42.200055] PM: Restoring platform NVS memory
> [   42.200055] Enabling non-boot CPUs ...
> 
> 
> Any pointers are appreciated.

Same for me (regarding the mixup of messages). Maybe widening
the console_{start,end}_sync() window from right after freezing
domains until right before thawing them could make clear whether
this is an artifact.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 27 13:46:38 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Sep 2012 13: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 1THEPy-0006Fi-3z; Thu, 27 Sep 2012 13:46: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 1THEPv-0006Fd-Sw
	for xen-devel@lists.xensource.com; Thu, 27 Sep 2012 13:46:16 +0000
Received: from [85.158.143.99:35619] by server-2.bemta-4.messagelabs.com id
	E7/A3-06610-7A854605; Thu, 27 Sep 2012 13:46:15 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1348753574!25581706!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTE5OTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27931 invoked from network); 27 Sep 2012 13:46:14 -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;
	27 Sep 2012 13:46:14 -0000
X-IronPort-AV: E=Sophos;i="4.80,495,1344211200"; d="scan'208";a="14806103"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Sep 2012 13:46:13 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Thu, 27 Sep 2012 14:46: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 1THEPt-0007Dq-9o;
	Thu, 27 Sep 2012 13:46:13 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1THEPt-0006HR-4D;
	Thu, 27 Sep 2012 14:46:13 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-13888-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 27 Sep 2012 14:46:13 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13888: 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 13888 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13888/

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-pv            3 host-install(3)         broken REGR. vs. 13825
 test-amd64-i386-xl            3 host-install(3)         broken REGR. vs. 13825
 test-amd64-i386-xl-credit2    3 host-install(3)         broken REGR. vs. 13825
 test-amd64-i386-qemuu-rhel6hvm-amd  3 host-install(3)   broken REGR. vs. 13825
 test-amd64-i386-xl-win-vcpus1  3 host-install(3)        broken REGR. vs. 13825
 test-amd64-i386-qemuu-rhel6hvm-intel  3 host-install(3) broken REGR. vs. 13825
 test-amd64-i386-xl-multivcpu  3 host-install(3)         broken REGR. vs. 13825
 test-amd64-i386-xl-win7-amd64  3 host-install(3)        broken REGR. vs. 13825
 test-amd64-i386-xend-winxpsp3  3 host-install(3)        broken REGR. vs. 13825
 test-amd64-i386-win           3 host-install(3)         broken REGR. vs. 13825
 test-amd64-i386-xl-winxpsp3-vcpus1  3 host-install(3)   broken REGR. vs. 13825
 test-amd64-i386-rhel6hvm-amd  3 host-install(3)         broken REGR. vs. 13825
 test-amd64-amd64-xl           3 host-install(3)         broken REGR. vs. 13825
 test-amd64-amd64-xl-win7-amd64  3 host-install(3)       broken REGR. vs. 13825
 test-amd64-amd64-pv           3 host-install(3)         broken REGR. vs. 13825
 test-amd64-amd64-xl-qemuu-winxpsp3  3 host-install(3)   broken REGR. vs. 13825
 test-amd64-amd64-win          3 host-install(3)         broken REGR. vs. 13825
 test-amd64-amd64-xl-winxpsp3  3 host-install(3)         broken REGR. vs. 13825
 test-amd64-amd64-xl-qemuu-win7-amd64  3 host-install(3) broken REGR. vs. 13825
 test-amd64-amd64-xl-win       3 host-install(3)         broken REGR. vs. 13825
 test-amd64-amd64-pair        3 host-install/src_host(3) broken REGR. vs. 13825
 test-amd64-amd64-pair        4 host-install/dst_host(4) broken REGR. vs. 13825

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf      3 host-install(3)              broken like 13825
 test-amd64-amd64-xl-sedf-pin  3 host-install(3)         broken REGR. vs. 13825
 test-amd64-amd64-xl-pcipt-intel  3 host-install(3)      broken REGR. vs. 13825

Tests which did not succeed, but are not blocking:
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass

version targeted for testing:
 xen                  6bf8b882df8f
baseline version:
 xen                  d364becfb083

------------------------------------------------------------
People who touched revisions under test:
  Bastian Blank <waldi@debian.org>
  Ben Guthro <ben@guthro.net>
  Christoph Egger <Christoph.Egger@amd.com>
  Christoph Egger <Christoph.Egger@amd.com> (on just this change)
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Keir Fraser <keir@xen.org>
  Liu, Jinsong <jinsong.liu@intel.com>
  Olaf Hering <olaf@aepfle.de>
------------------------------------------------------------

jobs:
 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                                          broken  
 test-amd64-i386-xl                                           broken  
 test-amd64-i386-rhel6hvm-amd                                 broken  
 test-amd64-i386-qemuu-rhel6hvm-amd                           broken  
 test-amd64-amd64-xl-qemuu-win7-amd64                         broken  
 test-amd64-amd64-xl-win7-amd64                               broken  
 test-amd64-i386-xl-win7-amd64                                broken  
 test-amd64-i386-xl-credit2                                   broken  
 test-amd64-amd64-xl-pcipt-intel                              broken  
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         broken  
 test-amd64-i386-xl-multivcpu                                 broken  
 test-amd64-amd64-pair                                        broken  
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-xl-sedf-pin                                 broken  
 test-amd64-amd64-pv                                          broken  
 test-amd64-i386-pv                                           broken  
 test-amd64-amd64-xl-sedf                                     broken  
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                broken  
 test-amd64-i386-xl-winxpsp3-vcpus1                           broken  
 test-amd64-amd64-win                                         broken  
 test-amd64-i386-win                                          broken  
 test-amd64-amd64-xl-win                                      broken  
 test-amd64-amd64-xl-qemuu-winxpsp3                           broken  
 test-amd64-i386-xend-winxpsp3                                broken  
 test-amd64-amd64-xl-winxpsp3                                 broken  


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.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 505 lines long.)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 27 13:46:38 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Sep 2012 13: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 1THEPy-0006Fi-3z; Thu, 27 Sep 2012 13:46: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 1THEPv-0006Fd-Sw
	for xen-devel@lists.xensource.com; Thu, 27 Sep 2012 13:46:16 +0000
Received: from [85.158.143.99:35619] by server-2.bemta-4.messagelabs.com id
	E7/A3-06610-7A854605; Thu, 27 Sep 2012 13:46:15 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1348753574!25581706!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTE5OTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27931 invoked from network); 27 Sep 2012 13:46:14 -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;
	27 Sep 2012 13:46:14 -0000
X-IronPort-AV: E=Sophos;i="4.80,495,1344211200"; d="scan'208";a="14806103"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Sep 2012 13:46:13 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Thu, 27 Sep 2012 14:46: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 1THEPt-0007Dq-9o;
	Thu, 27 Sep 2012 13:46:13 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1THEPt-0006HR-4D;
	Thu, 27 Sep 2012 14:46:13 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-13888-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 27 Sep 2012 14:46:13 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13888: 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 13888 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13888/

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-pv            3 host-install(3)         broken REGR. vs. 13825
 test-amd64-i386-xl            3 host-install(3)         broken REGR. vs. 13825
 test-amd64-i386-xl-credit2    3 host-install(3)         broken REGR. vs. 13825
 test-amd64-i386-qemuu-rhel6hvm-amd  3 host-install(3)   broken REGR. vs. 13825
 test-amd64-i386-xl-win-vcpus1  3 host-install(3)        broken REGR. vs. 13825
 test-amd64-i386-qemuu-rhel6hvm-intel  3 host-install(3) broken REGR. vs. 13825
 test-amd64-i386-xl-multivcpu  3 host-install(3)         broken REGR. vs. 13825
 test-amd64-i386-xl-win7-amd64  3 host-install(3)        broken REGR. vs. 13825
 test-amd64-i386-xend-winxpsp3  3 host-install(3)        broken REGR. vs. 13825
 test-amd64-i386-win           3 host-install(3)         broken REGR. vs. 13825
 test-amd64-i386-xl-winxpsp3-vcpus1  3 host-install(3)   broken REGR. vs. 13825
 test-amd64-i386-rhel6hvm-amd  3 host-install(3)         broken REGR. vs. 13825
 test-amd64-amd64-xl           3 host-install(3)         broken REGR. vs. 13825
 test-amd64-amd64-xl-win7-amd64  3 host-install(3)       broken REGR. vs. 13825
 test-amd64-amd64-pv           3 host-install(3)         broken REGR. vs. 13825
 test-amd64-amd64-xl-qemuu-winxpsp3  3 host-install(3)   broken REGR. vs. 13825
 test-amd64-amd64-win          3 host-install(3)         broken REGR. vs. 13825
 test-amd64-amd64-xl-winxpsp3  3 host-install(3)         broken REGR. vs. 13825
 test-amd64-amd64-xl-qemuu-win7-amd64  3 host-install(3) broken REGR. vs. 13825
 test-amd64-amd64-xl-win       3 host-install(3)         broken REGR. vs. 13825
 test-amd64-amd64-pair        3 host-install/src_host(3) broken REGR. vs. 13825
 test-amd64-amd64-pair        4 host-install/dst_host(4) broken REGR. vs. 13825

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf      3 host-install(3)              broken like 13825
 test-amd64-amd64-xl-sedf-pin  3 host-install(3)         broken REGR. vs. 13825
 test-amd64-amd64-xl-pcipt-intel  3 host-install(3)      broken REGR. vs. 13825

Tests which did not succeed, but are not blocking:
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass

version targeted for testing:
 xen                  6bf8b882df8f
baseline version:
 xen                  d364becfb083

------------------------------------------------------------
People who touched revisions under test:
  Bastian Blank <waldi@debian.org>
  Ben Guthro <ben@guthro.net>
  Christoph Egger <Christoph.Egger@amd.com>
  Christoph Egger <Christoph.Egger@amd.com> (on just this change)
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Keir Fraser <keir@xen.org>
  Liu, Jinsong <jinsong.liu@intel.com>
  Olaf Hering <olaf@aepfle.de>
------------------------------------------------------------

jobs:
 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                                          broken  
 test-amd64-i386-xl                                           broken  
 test-amd64-i386-rhel6hvm-amd                                 broken  
 test-amd64-i386-qemuu-rhel6hvm-amd                           broken  
 test-amd64-amd64-xl-qemuu-win7-amd64                         broken  
 test-amd64-amd64-xl-win7-amd64                               broken  
 test-amd64-i386-xl-win7-amd64                                broken  
 test-amd64-i386-xl-credit2                                   broken  
 test-amd64-amd64-xl-pcipt-intel                              broken  
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         broken  
 test-amd64-i386-xl-multivcpu                                 broken  
 test-amd64-amd64-pair                                        broken  
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-xl-sedf-pin                                 broken  
 test-amd64-amd64-pv                                          broken  
 test-amd64-i386-pv                                           broken  
 test-amd64-amd64-xl-sedf                                     broken  
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                broken  
 test-amd64-i386-xl-winxpsp3-vcpus1                           broken  
 test-amd64-amd64-win                                         broken  
 test-amd64-i386-win                                          broken  
 test-amd64-amd64-xl-win                                      broken  
 test-amd64-amd64-xl-qemuu-winxpsp3                           broken  
 test-amd64-i386-xend-winxpsp3                                broken  
 test-amd64-amd64-xl-winxpsp3                                 broken  


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.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 505 lines long.)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 27 13:51:18 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Sep 2012 13:51:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1THEUV-0006Nq-Qj; Thu, 27 Sep 2012 13:50:59 +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 1THEUU-0006Nj-ME
	for xen-devel@lists.xen.org; Thu, 27 Sep 2012 13:50:58 +0000
Received: from [85.158.138.51:32150] by server-2.bemta-3.messagelabs.com id
	06/2D-16514-1C954605; Thu, 27 Sep 2012 13:50:57 +0000
X-Env-Sender: Christoph.Egger@amd.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1348753856!13528203!1
X-Originating-IP: [213.199.154.140]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11317 invoked from network); 27 Sep 2012 13:50:57 -0000
Received: from db3ehsobe002.messaging.microsoft.com (HELO
	db3outboundpool.messaging.microsoft.com) (213.199.154.140)
	by server-13.tower-174.messagelabs.com with AES128-SHA encrypted SMTP;
	27 Sep 2012 13:50:57 -0000
Received: from mail115-db3-R.bigfish.com (10.3.81.233) by
	DB3EHSOBE009.bigfish.com (10.3.84.29) with Microsoft SMTP Server id
	14.1.225.23; Thu, 27 Sep 2012 13:50:56 +0000
Received: from mail115-db3 (localhost [127.0.0.1])	by
	mail115-db3-R.bigfish.com (Postfix) with ESMTP id 40E462A00DC	for
	<xen-devel@lists.xen.org>; Thu, 27 Sep 2012 13:50:56 +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(zzbb2dI98dI9371I1432I14ffIzz1202h1d1ah1d2ahzz17326ah8275bh8275dhz2dh668h839hd25he5bhf0ah107ah1288h12a5h12a9h12bdh137ah13b6h1155h)
Received: from mail115-db3 (localhost.localdomain [127.0.0.1]) by mail115-db3
	(MessageSwitch) id 1348753854102713_4913;
	Thu, 27 Sep 2012 13:50:54 +0000 (UTC)
Received: from DB3EHSMHS017.bigfish.com (unknown [10.3.81.237])	by
	mail115-db3.bigfish.com (Postfix) with ESMTP id 149583E003F	for
	<xen-devel@lists.xen.org>; Thu, 27 Sep 2012 13:50:54 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	DB3EHSMHS017.bigfish.com (10.3.87.117) with Microsoft SMTP Server id
	14.1.225.23; Thu, 27 Sep 2012 13:50:52 +0000
X-WSS-ID: 0MB0H4Q-01-88X-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 277A41028008	for <xen-devel@lists.xen.org>;
	Thu, 27 Sep 2012 08:50:49 -0500 (CDT)
Received: from SAUSEXDAG05.amd.com (163.181.55.6) by sausexedgep02.amd.com
	(163.181.36.59) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Thu, 27 Sep 2012 08:51:07 -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, 27 Sep 2012 08:50:50 -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, 27 Sep 2012
	09:50:49 -0400
Message-ID: <506459B8.4090401@amd.com>
Date: Thu, 27 Sep 2012 15:50:48 +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>
References: <CC8A0E9F.400A6%keir.xen@gmail.com>
In-Reply-To: <CC8A0E9F.400A6%keir.xen@gmail.com>
X-OriginatorOrg: amd.com
Subject: Re: [Xen-devel] [ANNOUNCE] Switching to git for primary Xen
	repositories
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 09/27/12 15:09, Keir Fraser wrote:

> That would be fine by me!


For the vote to have a base for a better decision:
http://mercurial.selenic.com/wiki/GitConcepts#Command_equivalence_table

Christoph

 
>  -- Keir
> 
> On 27/09/2012 13:00, "Lars Kurth" <lars.kurth.xen@gmail.com> wrote:
> 
>> Hi everybody,
>> I am wondering whether it wouldn't be better to have a vote about this. At
>> least in this case, nobody will be able to complain in the future.
>> Regards
>> Lars
>>
>> On Sun, Sep 9, 2012 at 12:16 PM, Keir Fraser <keir.xen@gmail.com> wrote:
>>> Folks,
>>>
>>> The Xen project has used mercurial for the primary repositories for many
>>> years. However, with external projects (including Linux and qemu) using git,
>>> this has led to us using and supporting two revision-control systems. Our
>>> plan therefore, with the 4.2.0 release soon out of the way, is to switch to
>>> git for all of our primary repositories. We will plan to mirror development
>>> activity into the old mercurial repositories at least in the short term.
>>>
>>> We will make a further announcement nearer to the time of the switchover.
>>>
>>>  Regards,
>>>  Keir & The Xen Team
>>>
>>>
>>>
>>> _______________________________________________
>>> Xen-devel mailing list
>>> Xen-devel@lists.xen.org
>>> http://lists.xen.org/xen-devel
>>
>>
> 
> 



-- 
---to satisfy European Law for business letters:
Advanced Micro Devices GmbH
Einsteinring 24, 85689 Dornach b. Muenchen
Geschaeftsfuehrer: Alberto Bozzo
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 Thu Sep 27 13:51:18 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Sep 2012 13:51:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1THEUV-0006Nq-Qj; Thu, 27 Sep 2012 13:50:59 +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 1THEUU-0006Nj-ME
	for xen-devel@lists.xen.org; Thu, 27 Sep 2012 13:50:58 +0000
Received: from [85.158.138.51:32150] by server-2.bemta-3.messagelabs.com id
	06/2D-16514-1C954605; Thu, 27 Sep 2012 13:50:57 +0000
X-Env-Sender: Christoph.Egger@amd.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1348753856!13528203!1
X-Originating-IP: [213.199.154.140]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11317 invoked from network); 27 Sep 2012 13:50:57 -0000
Received: from db3ehsobe002.messaging.microsoft.com (HELO
	db3outboundpool.messaging.microsoft.com) (213.199.154.140)
	by server-13.tower-174.messagelabs.com with AES128-SHA encrypted SMTP;
	27 Sep 2012 13:50:57 -0000
Received: from mail115-db3-R.bigfish.com (10.3.81.233) by
	DB3EHSOBE009.bigfish.com (10.3.84.29) with Microsoft SMTP Server id
	14.1.225.23; Thu, 27 Sep 2012 13:50:56 +0000
Received: from mail115-db3 (localhost [127.0.0.1])	by
	mail115-db3-R.bigfish.com (Postfix) with ESMTP id 40E462A00DC	for
	<xen-devel@lists.xen.org>; Thu, 27 Sep 2012 13:50:56 +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(zzbb2dI98dI9371I1432I14ffIzz1202h1d1ah1d2ahzz17326ah8275bh8275dhz2dh668h839hd25he5bhf0ah107ah1288h12a5h12a9h12bdh137ah13b6h1155h)
Received: from mail115-db3 (localhost.localdomain [127.0.0.1]) by mail115-db3
	(MessageSwitch) id 1348753854102713_4913;
	Thu, 27 Sep 2012 13:50:54 +0000 (UTC)
Received: from DB3EHSMHS017.bigfish.com (unknown [10.3.81.237])	by
	mail115-db3.bigfish.com (Postfix) with ESMTP id 149583E003F	for
	<xen-devel@lists.xen.org>; Thu, 27 Sep 2012 13:50:54 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	DB3EHSMHS017.bigfish.com (10.3.87.117) with Microsoft SMTP Server id
	14.1.225.23; Thu, 27 Sep 2012 13:50:52 +0000
X-WSS-ID: 0MB0H4Q-01-88X-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 277A41028008	for <xen-devel@lists.xen.org>;
	Thu, 27 Sep 2012 08:50:49 -0500 (CDT)
Received: from SAUSEXDAG05.amd.com (163.181.55.6) by sausexedgep02.amd.com
	(163.181.36.59) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Thu, 27 Sep 2012 08:51:07 -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, 27 Sep 2012 08:50:50 -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, 27 Sep 2012
	09:50:49 -0400
Message-ID: <506459B8.4090401@amd.com>
Date: Thu, 27 Sep 2012 15:50:48 +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>
References: <CC8A0E9F.400A6%keir.xen@gmail.com>
In-Reply-To: <CC8A0E9F.400A6%keir.xen@gmail.com>
X-OriginatorOrg: amd.com
Subject: Re: [Xen-devel] [ANNOUNCE] Switching to git for primary Xen
	repositories
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 09/27/12 15:09, Keir Fraser wrote:

> That would be fine by me!


For the vote to have a base for a better decision:
http://mercurial.selenic.com/wiki/GitConcepts#Command_equivalence_table

Christoph

 
>  -- Keir
> 
> On 27/09/2012 13:00, "Lars Kurth" <lars.kurth.xen@gmail.com> wrote:
> 
>> Hi everybody,
>> I am wondering whether it wouldn't be better to have a vote about this. At
>> least in this case, nobody will be able to complain in the future.
>> Regards
>> Lars
>>
>> On Sun, Sep 9, 2012 at 12:16 PM, Keir Fraser <keir.xen@gmail.com> wrote:
>>> Folks,
>>>
>>> The Xen project has used mercurial for the primary repositories for many
>>> years. However, with external projects (including Linux and qemu) using git,
>>> this has led to us using and supporting two revision-control systems. Our
>>> plan therefore, with the 4.2.0 release soon out of the way, is to switch to
>>> git for all of our primary repositories. We will plan to mirror development
>>> activity into the old mercurial repositories at least in the short term.
>>>
>>> We will make a further announcement nearer to the time of the switchover.
>>>
>>>  Regards,
>>>  Keir & The Xen Team
>>>
>>>
>>>
>>> _______________________________________________
>>> Xen-devel mailing list
>>> Xen-devel@lists.xen.org
>>> http://lists.xen.org/xen-devel
>>
>>
> 
> 



-- 
---to satisfy European Law for business letters:
Advanced Micro Devices GmbH
Einsteinring 24, 85689 Dornach b. Muenchen
Geschaeftsfuehrer: Alberto Bozzo
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 Thu Sep 27 14:17:42 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Sep 2012 14:17:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1THEtu-0006nx-CB; Thu, 27 Sep 2012 14:17:14 +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 1THEts-0006ns-H4
	for xen-devel@lists.xen.org; Thu, 27 Sep 2012 14:17:12 +0000
Received: from [85.158.143.99:63876] by server-3.bemta-4.messagelabs.com id
	AE/B1-10986-7EF54605; Thu, 27 Sep 2012 14:17:11 +0000
X-Env-Sender: Christoph.Egger@amd.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1348755428!32001217!1
X-Originating-IP: [216.32.180.187]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6789 invoked from network); 27 Sep 2012 14:17:10 -0000
Received: from co1ehsobe004.messaging.microsoft.com (HELO
	co1outboundpool.messaging.microsoft.com) (216.32.180.187)
	by server-15.tower-216.messagelabs.com with AES128-SHA encrypted SMTP;
	27 Sep 2012 14:17:10 -0000
Received: from mail181-co1-R.bigfish.com (10.243.78.237) by
	CO1EHSOBE001.bigfish.com (10.243.66.64) with Microsoft SMTP Server id
	14.1.225.23; Thu, 27 Sep 2012 14:17:07 +0000
Received: from mail181-co1 (localhost [127.0.0.1])	by
	mail181-co1-R.bigfish.com (Postfix) with ESMTP id D5E01DC0109	for
	<xen-devel@lists.xen.org>; Thu, 27 Sep 2012 14:17: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: 0
X-BigFish: VPS0(zzc85fhc85dhzz1202h1d1ah1d2ahzz8275bhz2dh668h839hd25he5bhf0ah107ah1288h12a5h12bdh137ah34h1155h)
Received: from mail181-co1 (localhost.localdomain [127.0.0.1]) by mail181-co1
	(MessageSwitch) id 134875542542936_28309;
	Thu, 27 Sep 2012 14:17:05 +0000 (UTC)
Received: from CO1EHSMHS022.bigfish.com (unknown [10.243.78.244])	by
	mail181-co1.bigfish.com (Postfix) with ESMTP id E886B98004A	for
	<xen-devel@lists.xen.org>; Thu, 27 Sep 2012 14:17:04 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	CO1EHSMHS022.bigfish.com (10.243.66.32) with Microsoft SMTP Server id
	14.1.225.23; Thu, 27 Sep 2012 14:17:01 +0000
X-WSS-ID: 0MB0IC9-02-EUY-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 227FCC8147	for <xen-devel@lists.xen.org>; Thu, 27 Sep 2012
	09:16:57 -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;
	Thu, 27 Sep 2012 09:17:15 -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;
	Thu, 27 Sep 2012 09:16:58 -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, 27 Sep 2012
	10:16:57 -0400
Message-ID: <50645FD8.9020502@amd.com>
Date: Thu, 27 Sep 2012 16:16:56 +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="------------080508050609000908010209"
X-OriginatorOrg: amd.com
Subject: [Xen-devel] [PATCH] MCE: implement recoverscan for AMD
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--------------080508050609000908010209
Content-Type: text/plain; charset="ISO-8859-15"
Content-Transfer-Encoding: 7bit


Implement recoverable_scan() for AMD

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
Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen
Registergericht Muenchen, HRB Nr. 43632

--------------080508050609000908010209
Content-Type: text/plain; charset="us-ascii";
	name="xen_mce_recoverscan.diff"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="xen_mce_recoverscan.diff"
Content-Description: xen_mce_recoverscan.diff

# User Christoph Egger
# Date 1348750048 -7200
Implement recoverable_scan() for AMD

Signed-off-by: Christoph Egger <Christoph.Egger@amd.com>

diff -r af8840f1d82d -r 9b057c716549 xen/arch/x86/cpu/mcheck/Makefile
--- a/xen/arch/x86/cpu/mcheck/Makefile
+++ b/xen/arch/x86/cpu/mcheck/Makefile
@@ -2,6 +2,7 @@ obj-y += amd_nonfatal.o
 obj-y += k7.o
 obj-y += amd_k8.o
 obj-y += amd_f10.o
+obj-y += mce_amd.o
 obj-y += barrier.o
 obj-y += mctelem.o
 obj-y += mce.o
diff -r af8840f1d82d -r 9b057c716549 xen/arch/x86/cpu/mcheck/amd_f10.c
--- a/xen/arch/x86/cpu/mcheck/amd_f10.c
+++ b/xen/arch/x86/cpu/mcheck/amd_f10.c
@@ -37,18 +37,13 @@
 
 #include <xen/init.h>
 #include <xen/types.h>
-#include <xen/kernel.h>
-#include <xen/config.h>
-#include <xen/smp.h>
 
-#include <asm/processor.h>
-#include <asm/system.h>
 #include <asm/msr.h>
 
 #include "mce.h"
 #include "mce_quirks.h"
 #include "x86_mca.h"
-
+#include "mce_amd.h"
 
 static struct mcinfo_extended *
 amd_f10_handler(struct mc_info *mi, uint16_t bank, uint64_t status)
@@ -89,6 +84,11 @@ amd_f10_handler(struct mc_info *mi, uint
 	return mc_ext;
 }
 
+static int amd_f10_recoverable_scan(uint64_t status)
+{
+	return mc_amd_recoverable_scan(status);
+}
+
 /* AMD Family10 machine check */
 enum mcheck_type amd_f10_mcheck_init(struct cpuinfo_x86 *c)
 { 
@@ -101,6 +101,7 @@ enum mcheck_type amd_f10_mcheck_init(str
 		mcequirk_amd_apply(quirkflag);
 
 	x86_mce_callback_register(amd_f10_handler);
+	mce_recoverable_register(amd_f10_recoverable_scan);
 
 	return mcheck_amd_famXX;
 }
diff -r af8840f1d82d -r 9b057c716549 xen/arch/x86/cpu/mcheck/mce.h
--- a/xen/arch/x86/cpu/mcheck/mce.h
+++ b/xen/arch/x86/cpu/mcheck/mce.h
@@ -73,7 +73,7 @@ extern void mcheck_cmn_handler(struct cp
     struct mca_banks *, struct mca_banks *);
 
 /* Register a handler for judging whether mce is recoverable. */
-typedef int (*mce_recoverable_t)(u64 status);
+typedef int (*mce_recoverable_t)(uint64_t status);
 extern void mce_recoverable_register(mce_recoverable_t);
 
 /* Read an MSR, checking for an interposed value first */
diff -r af8840f1d82d -r 9b057c716549 xen/arch/x86/cpu/mcheck/mce_amd.c
--- /dev/null
+++ b/xen/arch/x86/cpu/mcheck/mce_amd.c
@@ -0,0 +1,76 @@
+/*
+ * common MCA implementation for AMD CPUs.
+ * Copyright (c) 2012 Advanced Micro Devices, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
+ */
+
+#include <xen/init.h>
+#include <xen/types.h>
+
+#include <asm/msr.h>
+
+#include "mce.h"
+#include "x86_mca.h"
+#include "mce_amd.h"
+
+/* Error Code Types */
+enum mc_ec_type {
+    MC_EC_TLB_TYPE = 0x0010,
+    MC_EC_MEM_TYPE = 0x0100,
+    MC_EC_BUS_TYPE = 0x0800,
+};
+
+enum mc_ec_type
+mc_ec2type(uint16_t errorcode)
+{
+    if ((errorcode & MC_EC_BUS_TYPE) == MC_EC_BUS_TYPE)
+        return MC_EC_BUS_TYPE;
+    if ((errorcode & MC_EC_MEM_TYPE) == MC_EC_MEM_TYPE)
+        return MC_EC_MEM_TYPE;
+    if ((errorcode & MC_EC_TLB_TYPE) == MC_EC_TLB_TYPE)
+        return MC_EC_TLB_TYPE;
+    /* Unreached */
+    BUG();
+    return 0;
+}
+
+int
+mc_amd_recoverable_scan(uint64_t status)
+{
+    int ret = 0;
+    enum mc_ec_type ectype;
+    uint16_t errorcode;
+
+    if ( !(status & MCi_STATUS_UC) )
+        return 1;
+
+    errorcode = status & (MCi_STATUS_MCA | MCi_STATUS_MSEC);
+    ectype = mc_ec2type(errorcode);
+
+    switch (ectype) {
+    case MC_EC_BUS_TYPE: /* value in addr MSR is physical */
+        /* should run cpu offline action */
+        break;
+    case MC_EC_MEM_TYPE: /* value in addr MSR is physical */
+        ret = 1; /* run memory page offline action */
+        break;
+    case MC_EC_TLB_TYPE: /* value in addr MSR is virtual */
+        /* should run tlb flush action and retry */
+        break;
+    }
+
+    return ret;
+}
diff -r af8840f1d82d -r 9b057c716549 xen/arch/x86/cpu/mcheck/mce_amd.h
--- /dev/null
+++ b/xen/arch/x86/cpu/mcheck/mce_amd.h
@@ -0,0 +1,6 @@
+#ifndef _MCHECK_AMD_H
+#define _MCHECK_AMD_H
+
+int mc_amd_recoverable_scan(uint64_t status);
+
+#endif
diff -r af8840f1d82d -r 9b057c716549 xen/arch/x86/cpu/mcheck/mce_intel.c
--- a/xen/arch/x86/cpu/mcheck/mce_intel.c
+++ b/xen/arch/x86/cpu/mcheck/mce_intel.c
@@ -560,7 +560,7 @@ static int intel_need_clearbank_scan(enu
  * 4) SRAO ser_support = 1, PCC = 0, S = 1, AR = 0, EN = 1 [UC = 1]
  * 5) UCNA ser_support = 1, OVER = 0, EN = 1, PCC = 0, S = 0, AR = 0, [UC = 1]
  */
-static int intel_recoverable_scan(u64 status)
+static int intel_recoverable_scan(uint64_t status)
 {
 
     if ( !(status & MCi_STATUS_UC ) )

--------------080508050609000908010209
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--------------080508050609000908010209--


From xen-devel-bounces@lists.xen.org Thu Sep 27 14:17:42 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Sep 2012 14:17:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1THEtu-0006nx-CB; Thu, 27 Sep 2012 14:17:14 +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 1THEts-0006ns-H4
	for xen-devel@lists.xen.org; Thu, 27 Sep 2012 14:17:12 +0000
Received: from [85.158.143.99:63876] by server-3.bemta-4.messagelabs.com id
	AE/B1-10986-7EF54605; Thu, 27 Sep 2012 14:17:11 +0000
X-Env-Sender: Christoph.Egger@amd.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1348755428!32001217!1
X-Originating-IP: [216.32.180.187]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6789 invoked from network); 27 Sep 2012 14:17:10 -0000
Received: from co1ehsobe004.messaging.microsoft.com (HELO
	co1outboundpool.messaging.microsoft.com) (216.32.180.187)
	by server-15.tower-216.messagelabs.com with AES128-SHA encrypted SMTP;
	27 Sep 2012 14:17:10 -0000
Received: from mail181-co1-R.bigfish.com (10.243.78.237) by
	CO1EHSOBE001.bigfish.com (10.243.66.64) with Microsoft SMTP Server id
	14.1.225.23; Thu, 27 Sep 2012 14:17:07 +0000
Received: from mail181-co1 (localhost [127.0.0.1])	by
	mail181-co1-R.bigfish.com (Postfix) with ESMTP id D5E01DC0109	for
	<xen-devel@lists.xen.org>; Thu, 27 Sep 2012 14:17: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: 0
X-BigFish: VPS0(zzc85fhc85dhzz1202h1d1ah1d2ahzz8275bhz2dh668h839hd25he5bhf0ah107ah1288h12a5h12bdh137ah34h1155h)
Received: from mail181-co1 (localhost.localdomain [127.0.0.1]) by mail181-co1
	(MessageSwitch) id 134875542542936_28309;
	Thu, 27 Sep 2012 14:17:05 +0000 (UTC)
Received: from CO1EHSMHS022.bigfish.com (unknown [10.243.78.244])	by
	mail181-co1.bigfish.com (Postfix) with ESMTP id E886B98004A	for
	<xen-devel@lists.xen.org>; Thu, 27 Sep 2012 14:17:04 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	CO1EHSMHS022.bigfish.com (10.243.66.32) with Microsoft SMTP Server id
	14.1.225.23; Thu, 27 Sep 2012 14:17:01 +0000
X-WSS-ID: 0MB0IC9-02-EUY-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 227FCC8147	for <xen-devel@lists.xen.org>; Thu, 27 Sep 2012
	09:16:57 -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;
	Thu, 27 Sep 2012 09:17:15 -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;
	Thu, 27 Sep 2012 09:16:58 -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, 27 Sep 2012
	10:16:57 -0400
Message-ID: <50645FD8.9020502@amd.com>
Date: Thu, 27 Sep 2012 16:16:56 +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="------------080508050609000908010209"
X-OriginatorOrg: amd.com
Subject: [Xen-devel] [PATCH] MCE: implement recoverscan for AMD
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--------------080508050609000908010209
Content-Type: text/plain; charset="ISO-8859-15"
Content-Transfer-Encoding: 7bit


Implement recoverable_scan() for AMD

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
Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen
Registergericht Muenchen, HRB Nr. 43632

--------------080508050609000908010209
Content-Type: text/plain; charset="us-ascii";
	name="xen_mce_recoverscan.diff"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="xen_mce_recoverscan.diff"
Content-Description: xen_mce_recoverscan.diff

# User Christoph Egger
# Date 1348750048 -7200
Implement recoverable_scan() for AMD

Signed-off-by: Christoph Egger <Christoph.Egger@amd.com>

diff -r af8840f1d82d -r 9b057c716549 xen/arch/x86/cpu/mcheck/Makefile
--- a/xen/arch/x86/cpu/mcheck/Makefile
+++ b/xen/arch/x86/cpu/mcheck/Makefile
@@ -2,6 +2,7 @@ obj-y += amd_nonfatal.o
 obj-y += k7.o
 obj-y += amd_k8.o
 obj-y += amd_f10.o
+obj-y += mce_amd.o
 obj-y += barrier.o
 obj-y += mctelem.o
 obj-y += mce.o
diff -r af8840f1d82d -r 9b057c716549 xen/arch/x86/cpu/mcheck/amd_f10.c
--- a/xen/arch/x86/cpu/mcheck/amd_f10.c
+++ b/xen/arch/x86/cpu/mcheck/amd_f10.c
@@ -37,18 +37,13 @@
 
 #include <xen/init.h>
 #include <xen/types.h>
-#include <xen/kernel.h>
-#include <xen/config.h>
-#include <xen/smp.h>
 
-#include <asm/processor.h>
-#include <asm/system.h>
 #include <asm/msr.h>
 
 #include "mce.h"
 #include "mce_quirks.h"
 #include "x86_mca.h"
-
+#include "mce_amd.h"
 
 static struct mcinfo_extended *
 amd_f10_handler(struct mc_info *mi, uint16_t bank, uint64_t status)
@@ -89,6 +84,11 @@ amd_f10_handler(struct mc_info *mi, uint
 	return mc_ext;
 }
 
+static int amd_f10_recoverable_scan(uint64_t status)
+{
+	return mc_amd_recoverable_scan(status);
+}
+
 /* AMD Family10 machine check */
 enum mcheck_type amd_f10_mcheck_init(struct cpuinfo_x86 *c)
 { 
@@ -101,6 +101,7 @@ enum mcheck_type amd_f10_mcheck_init(str
 		mcequirk_amd_apply(quirkflag);
 
 	x86_mce_callback_register(amd_f10_handler);
+	mce_recoverable_register(amd_f10_recoverable_scan);
 
 	return mcheck_amd_famXX;
 }
diff -r af8840f1d82d -r 9b057c716549 xen/arch/x86/cpu/mcheck/mce.h
--- a/xen/arch/x86/cpu/mcheck/mce.h
+++ b/xen/arch/x86/cpu/mcheck/mce.h
@@ -73,7 +73,7 @@ extern void mcheck_cmn_handler(struct cp
     struct mca_banks *, struct mca_banks *);
 
 /* Register a handler for judging whether mce is recoverable. */
-typedef int (*mce_recoverable_t)(u64 status);
+typedef int (*mce_recoverable_t)(uint64_t status);
 extern void mce_recoverable_register(mce_recoverable_t);
 
 /* Read an MSR, checking for an interposed value first */
diff -r af8840f1d82d -r 9b057c716549 xen/arch/x86/cpu/mcheck/mce_amd.c
--- /dev/null
+++ b/xen/arch/x86/cpu/mcheck/mce_amd.c
@@ -0,0 +1,76 @@
+/*
+ * common MCA implementation for AMD CPUs.
+ * Copyright (c) 2012 Advanced Micro Devices, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
+ */
+
+#include <xen/init.h>
+#include <xen/types.h>
+
+#include <asm/msr.h>
+
+#include "mce.h"
+#include "x86_mca.h"
+#include "mce_amd.h"
+
+/* Error Code Types */
+enum mc_ec_type {
+    MC_EC_TLB_TYPE = 0x0010,
+    MC_EC_MEM_TYPE = 0x0100,
+    MC_EC_BUS_TYPE = 0x0800,
+};
+
+enum mc_ec_type
+mc_ec2type(uint16_t errorcode)
+{
+    if ((errorcode & MC_EC_BUS_TYPE) == MC_EC_BUS_TYPE)
+        return MC_EC_BUS_TYPE;
+    if ((errorcode & MC_EC_MEM_TYPE) == MC_EC_MEM_TYPE)
+        return MC_EC_MEM_TYPE;
+    if ((errorcode & MC_EC_TLB_TYPE) == MC_EC_TLB_TYPE)
+        return MC_EC_TLB_TYPE;
+    /* Unreached */
+    BUG();
+    return 0;
+}
+
+int
+mc_amd_recoverable_scan(uint64_t status)
+{
+    int ret = 0;
+    enum mc_ec_type ectype;
+    uint16_t errorcode;
+
+    if ( !(status & MCi_STATUS_UC) )
+        return 1;
+
+    errorcode = status & (MCi_STATUS_MCA | MCi_STATUS_MSEC);
+    ectype = mc_ec2type(errorcode);
+
+    switch (ectype) {
+    case MC_EC_BUS_TYPE: /* value in addr MSR is physical */
+        /* should run cpu offline action */
+        break;
+    case MC_EC_MEM_TYPE: /* value in addr MSR is physical */
+        ret = 1; /* run memory page offline action */
+        break;
+    case MC_EC_TLB_TYPE: /* value in addr MSR is virtual */
+        /* should run tlb flush action and retry */
+        break;
+    }
+
+    return ret;
+}
diff -r af8840f1d82d -r 9b057c716549 xen/arch/x86/cpu/mcheck/mce_amd.h
--- /dev/null
+++ b/xen/arch/x86/cpu/mcheck/mce_amd.h
@@ -0,0 +1,6 @@
+#ifndef _MCHECK_AMD_H
+#define _MCHECK_AMD_H
+
+int mc_amd_recoverable_scan(uint64_t status);
+
+#endif
diff -r af8840f1d82d -r 9b057c716549 xen/arch/x86/cpu/mcheck/mce_intel.c
--- a/xen/arch/x86/cpu/mcheck/mce_intel.c
+++ b/xen/arch/x86/cpu/mcheck/mce_intel.c
@@ -560,7 +560,7 @@ static int intel_need_clearbank_scan(enu
  * 4) SRAO ser_support = 1, PCC = 0, S = 1, AR = 0, EN = 1 [UC = 1]
  * 5) UCNA ser_support = 1, OVER = 0, EN = 1, PCC = 0, S = 0, AR = 0, [UC = 1]
  */
-static int intel_recoverable_scan(u64 status)
+static int intel_recoverable_scan(uint64_t status)
 {
 
     if ( !(status & MCi_STATUS_UC ) )

--------------080508050609000908010209
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--------------080508050609000908010209--


From xen-devel-bounces@lists.xen.org Thu Sep 27 14:40:09 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Sep 2012 14:40:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1THFFf-00073j-D2; Thu, 27 Sep 2012 14:39: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 1THFFe-00073e-EN
	for xen-devel@lists.xen.org; Thu, 27 Sep 2012 14:39:42 +0000
Received: from [85.158.143.35:25822] by server-1.bemta-4.messagelabs.com id
	4A/C5-05684-D2564605; Thu, 27 Sep 2012 14:39:41 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1348756777!13013116!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4797 invoked from network); 27 Sep 2012 14:39:37 -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;
	27 Sep 2012 14:39:37 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 27 Sep 2012 15:39:36 +0100
Message-Id: <50648161020000780009E418@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 27 Sep 2012 15:40:01 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part68595151.0__="
Subject: [Xen-devel] [PATCH] x86/HPET: don't disable interrupt delivery
 right after setting it up
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

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.

--=__Part68595151.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

We shouldn't clear HPET_TN_FSB right after we (indirectly, via
request_irq()) enabled it for the channels we intend to use for
broadcasts.

This fixes a regression introduced by c/s 25103:0b0e42dc4f0a.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
---
This fixes the MWAIT idle driver problem on the box that I was able to
(artificially) reproduce it with. Hence I subsequently intend to revert
25960:6bf8b882df8f, but I'm not intending to do this before getting a
push there.

I'm surprised that this didn't hit anyone so far with the ACPI-based
idle driver...

--- 2012-09-21.orig/xen/arch/x86/hpet.c	2012-09-27 16:10:35.000000000 =
+0200
+++ 2012-09-21/xen/arch/x86/hpet.c	2012-09-27 16:10:07.000000000 =
+0200
@@ -533,7 +533,7 @@ void __init hpet_broadcast_init(void)
     {
         /* set HPET Tn as oneshot */
         cfg =3D hpet_read32(HPET_Tn_CFG(hpet_events[i].idx));
-        cfg &=3D ~(HPET_TN_LEVEL | HPET_TN_PERIODIC | HPET_TN_FSB);
+        cfg &=3D ~(HPET_TN_LEVEL | HPET_TN_PERIODIC);
         cfg |=3D HPET_TN_ENABLE | HPET_TN_32BIT;
         hpet_write32(cfg, HPET_Tn_CFG(hpet_events[i].idx));
=20
@@ -590,7 +590,7 @@ void hpet_broadcast_resume(void)
=20
         /* set HPET Tn as oneshot */
         cfg =3D hpet_read32(HPET_Tn_CFG(hpet_events[i].idx));
-        cfg &=3D ~(HPET_TN_LEVEL | HPET_TN_PERIODIC | HPET_TN_FSB);
+        cfg &=3D ~(HPET_TN_LEVEL | HPET_TN_PERIODIC);
         cfg |=3D HPET_TN_ENABLE | HPET_TN_32BIT;
         hpet_write32(cfg, HPET_Tn_CFG(hpet_events[i].idx));
=20




--=__Part68595151.0__=
Content-Type: text/plain; name="x86-HPET-interrupts.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="x86-HPET-interrupts.patch"

x86/HPET: don't disable interrupt delivery right after setting it =
up=0A=0AWe shouldn't clear HPET_TN_FSB right after we (indirectly, =
via=0Arequest_irq()) enabled it for the channels we intend to use =
for=0Abroadcasts.=0A=0AThis fixes a regression introduced by c/s 25103:0b0e=
42dc4f0a.=0A=0ASigned-off-by: Jan Beulich <jbeulich@suse.com>=0A---=0AThis =
fixes the MWAIT idle driver problem on the box that I was able to=0A(artifi=
cially) reproduce it with. Hence I subsequently intend to revert=0A25960:6b=
f8b882df8f, but I'm not intending to do this before getting a=0Apush =
there.=0A=0AI'm surprised that this didn't hit anyone so far with the =
ACPI-based=0Aidle driver...=0A=0A--- 2012-09-21.orig/xen/arch/x86/hpet.c	=
2012-09-27 16:10:35.000000000 +0200=0A+++ 2012-09-21/xen/arch/x86/hpet.c	=
2012-09-27 16:10:07.000000000 +0200=0A@@ -533,7 +533,7 @@ void __init =
hpet_broadcast_init(void)=0A     {=0A         /* set HPET Tn as oneshot =
*/=0A         cfg =3D hpet_read32(HPET_Tn_CFG(hpet_events[i].idx));=0A-    =
    cfg &=3D ~(HPET_TN_LEVEL | HPET_TN_PERIODIC | HPET_TN_FSB);=0A+        =
cfg &=3D ~(HPET_TN_LEVEL | HPET_TN_PERIODIC);=0A         cfg |=3D =
HPET_TN_ENABLE | HPET_TN_32BIT;=0A         hpet_write32(cfg, HPET_Tn_CFG(hp=
et_events[i].idx));=0A =0A@@ -590,7 +590,7 @@ void hpet_broadcast_resume(vo=
id)=0A =0A         /* set HPET Tn as oneshot */=0A         cfg =3D =
hpet_read32(HPET_Tn_CFG(hpet_events[i].idx));=0A-        cfg &=3D =
~(HPET_TN_LEVEL | HPET_TN_PERIODIC | HPET_TN_FSB);=0A+        cfg &=3D =
~(HPET_TN_LEVEL | HPET_TN_PERIODIC);=0A         cfg |=3D HPET_TN_ENABLE | =
HPET_TN_32BIT;=0A         hpet_write32(cfg, HPET_Tn_CFG(hpet_events[i].idx)=
);=0A =0A
--=__Part68595151.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

--=__Part68595151.0__=--


From xen-devel-bounces@lists.xen.org Thu Sep 27 14:40:09 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Sep 2012 14:40:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1THFFf-00073j-D2; Thu, 27 Sep 2012 14:39: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 1THFFe-00073e-EN
	for xen-devel@lists.xen.org; Thu, 27 Sep 2012 14:39:42 +0000
Received: from [85.158.143.35:25822] by server-1.bemta-4.messagelabs.com id
	4A/C5-05684-D2564605; Thu, 27 Sep 2012 14:39:41 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1348756777!13013116!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4797 invoked from network); 27 Sep 2012 14:39:37 -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;
	27 Sep 2012 14:39:37 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 27 Sep 2012 15:39:36 +0100
Message-Id: <50648161020000780009E418@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 27 Sep 2012 15:40:01 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part68595151.0__="
Subject: [Xen-devel] [PATCH] x86/HPET: don't disable interrupt delivery
 right after setting it up
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

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.

--=__Part68595151.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

We shouldn't clear HPET_TN_FSB right after we (indirectly, via
request_irq()) enabled it for the channels we intend to use for
broadcasts.

This fixes a regression introduced by c/s 25103:0b0e42dc4f0a.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
---
This fixes the MWAIT idle driver problem on the box that I was able to
(artificially) reproduce it with. Hence I subsequently intend to revert
25960:6bf8b882df8f, but I'm not intending to do this before getting a
push there.

I'm surprised that this didn't hit anyone so far with the ACPI-based
idle driver...

--- 2012-09-21.orig/xen/arch/x86/hpet.c	2012-09-27 16:10:35.000000000 =
+0200
+++ 2012-09-21/xen/arch/x86/hpet.c	2012-09-27 16:10:07.000000000 =
+0200
@@ -533,7 +533,7 @@ void __init hpet_broadcast_init(void)
     {
         /* set HPET Tn as oneshot */
         cfg =3D hpet_read32(HPET_Tn_CFG(hpet_events[i].idx));
-        cfg &=3D ~(HPET_TN_LEVEL | HPET_TN_PERIODIC | HPET_TN_FSB);
+        cfg &=3D ~(HPET_TN_LEVEL | HPET_TN_PERIODIC);
         cfg |=3D HPET_TN_ENABLE | HPET_TN_32BIT;
         hpet_write32(cfg, HPET_Tn_CFG(hpet_events[i].idx));
=20
@@ -590,7 +590,7 @@ void hpet_broadcast_resume(void)
=20
         /* set HPET Tn as oneshot */
         cfg =3D hpet_read32(HPET_Tn_CFG(hpet_events[i].idx));
-        cfg &=3D ~(HPET_TN_LEVEL | HPET_TN_PERIODIC | HPET_TN_FSB);
+        cfg &=3D ~(HPET_TN_LEVEL | HPET_TN_PERIODIC);
         cfg |=3D HPET_TN_ENABLE | HPET_TN_32BIT;
         hpet_write32(cfg, HPET_Tn_CFG(hpet_events[i].idx));
=20




--=__Part68595151.0__=
Content-Type: text/plain; name="x86-HPET-interrupts.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="x86-HPET-interrupts.patch"

x86/HPET: don't disable interrupt delivery right after setting it =
up=0A=0AWe shouldn't clear HPET_TN_FSB right after we (indirectly, =
via=0Arequest_irq()) enabled it for the channels we intend to use =
for=0Abroadcasts.=0A=0AThis fixes a regression introduced by c/s 25103:0b0e=
42dc4f0a.=0A=0ASigned-off-by: Jan Beulich <jbeulich@suse.com>=0A---=0AThis =
fixes the MWAIT idle driver problem on the box that I was able to=0A(artifi=
cially) reproduce it with. Hence I subsequently intend to revert=0A25960:6b=
f8b882df8f, but I'm not intending to do this before getting a=0Apush =
there.=0A=0AI'm surprised that this didn't hit anyone so far with the =
ACPI-based=0Aidle driver...=0A=0A--- 2012-09-21.orig/xen/arch/x86/hpet.c	=
2012-09-27 16:10:35.000000000 +0200=0A+++ 2012-09-21/xen/arch/x86/hpet.c	=
2012-09-27 16:10:07.000000000 +0200=0A@@ -533,7 +533,7 @@ void __init =
hpet_broadcast_init(void)=0A     {=0A         /* set HPET Tn as oneshot =
*/=0A         cfg =3D hpet_read32(HPET_Tn_CFG(hpet_events[i].idx));=0A-    =
    cfg &=3D ~(HPET_TN_LEVEL | HPET_TN_PERIODIC | HPET_TN_FSB);=0A+        =
cfg &=3D ~(HPET_TN_LEVEL | HPET_TN_PERIODIC);=0A         cfg |=3D =
HPET_TN_ENABLE | HPET_TN_32BIT;=0A         hpet_write32(cfg, HPET_Tn_CFG(hp=
et_events[i].idx));=0A =0A@@ -590,7 +590,7 @@ void hpet_broadcast_resume(vo=
id)=0A =0A         /* set HPET Tn as oneshot */=0A         cfg =3D =
hpet_read32(HPET_Tn_CFG(hpet_events[i].idx));=0A-        cfg &=3D =
~(HPET_TN_LEVEL | HPET_TN_PERIODIC | HPET_TN_FSB);=0A+        cfg &=3D =
~(HPET_TN_LEVEL | HPET_TN_PERIODIC);=0A         cfg |=3D HPET_TN_ENABLE | =
HPET_TN_32BIT;=0A         hpet_write32(cfg, HPET_Tn_CFG(hpet_events[i].idx)=
);=0A =0A
--=__Part68595151.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

--=__Part68595151.0__=--


From xen-devel-bounces@lists.xen.org Thu Sep 27 14:42:35 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Sep 2012 14:42: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 1THFI5-0007AQ-3Z; Thu, 27 Sep 2012 14:42: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 1THFI3-0007AD-OB
	for xen-devel@lists.xensource.com; Thu, 27 Sep 2012 14:42:11 +0000
Received: from [85.158.139.83:63648] by server-15.bemta-5.messagelabs.com id
	CC/2A-19430-3C564605; Thu, 27 Sep 2012 14:42:11 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1348756929!31867870!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTE5OTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32217 invoked from network); 27 Sep 2012 14:42:09 -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;
	27 Sep 2012 14:42:09 -0000
X-IronPort-AV: E=Sophos;i="4.80,496,1344211200"; d="scan'208";a="14808159"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Sep 2012 14:42: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.279.1; Thu, 27 Sep 2012 15:42: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
	1THFI0-0007rr-ND	for xen-devel@lists.xensource.com;
	Thu, 27 Sep 2012 14:42:08 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1THFI0-0000bA-Jx	for
	xen-devel@lists.xensource.com; Thu, 27 Sep 2012 15:42:08 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20580.26048.446991.279161@mariner.uk.xensource.com>
Date: Thu, 27 Sep 2012 15:42:08 +0100
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
In-Reply-To: <osstest-13888-mainreport@xen.org>
References: <osstest-13888-mainreport@xen.org>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Subject: Re: [Xen-devel] [xen-unstable test] 13888: trouble: broken/fail/pass
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

xen.org writes ("[xen-unstable test] 13888: trouble: broken/fail/pass"):
> flight 13888 xen-unstable real [real]
> http://www.chiark.greenend.org.uk/~xensrcts/logs/13888/
> 
> Failures and problems with tests :-(
> 
> Tests which did not succeed and are blocking,
> including tests which could not be run:
>  test-amd64-i386-pv            3 host-install(3)     broken REGR. vs. 13825

This is due to an infrastructure problem: our local apt-cacher stopped
working and was restarted some time this morning.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 27 14:42:35 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Sep 2012 14:42: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 1THFI5-0007AQ-3Z; Thu, 27 Sep 2012 14:42: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 1THFI3-0007AD-OB
	for xen-devel@lists.xensource.com; Thu, 27 Sep 2012 14:42:11 +0000
Received: from [85.158.139.83:63648] by server-15.bemta-5.messagelabs.com id
	CC/2A-19430-3C564605; Thu, 27 Sep 2012 14:42:11 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1348756929!31867870!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTE5OTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32217 invoked from network); 27 Sep 2012 14:42:09 -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;
	27 Sep 2012 14:42:09 -0000
X-IronPort-AV: E=Sophos;i="4.80,496,1344211200"; d="scan'208";a="14808159"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Sep 2012 14:42: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.279.1; Thu, 27 Sep 2012 15:42: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
	1THFI0-0007rr-ND	for xen-devel@lists.xensource.com;
	Thu, 27 Sep 2012 14:42:08 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1THFI0-0000bA-Jx	for
	xen-devel@lists.xensource.com; Thu, 27 Sep 2012 15:42:08 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20580.26048.446991.279161@mariner.uk.xensource.com>
Date: Thu, 27 Sep 2012 15:42:08 +0100
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
In-Reply-To: <osstest-13888-mainreport@xen.org>
References: <osstest-13888-mainreport@xen.org>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Subject: Re: [Xen-devel] [xen-unstable test] 13888: trouble: broken/fail/pass
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

xen.org writes ("[xen-unstable test] 13888: trouble: broken/fail/pass"):
> flight 13888 xen-unstable real [real]
> http://www.chiark.greenend.org.uk/~xensrcts/logs/13888/
> 
> Failures and problems with tests :-(
> 
> Tests which did not succeed and are blocking,
> including tests which could not be run:
>  test-amd64-i386-pv            3 host-install(3)     broken REGR. vs. 13825

This is due to an infrastructure problem: our local apt-cacher stopped
working and was restarted some time this morning.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 27 14:45:52 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Sep 2012 14:45:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1THFLA-0007JV-NM; Thu, 27 Sep 2012 14:45: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 1THFL8-0007JP-HF
	for xen-devel@lists.xen.org; Thu, 27 Sep 2012 14:45:22 +0000
Received: from [85.158.143.99:4437] by server-3.bemta-4.messagelabs.com id
	6C/90-10986-18664605; Thu, 27 Sep 2012 14:45:21 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-3.tower-216.messagelabs.com!1348757120!31419150!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26912 invoked from network); 27 Sep 2012 14:45:20 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-3.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 27 Sep 2012 14:45:20 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1THFL5-00036f-54; Thu, 27 Sep 2012 14:45:19 +0000
Date: Thu, 27 Sep 2012 15:45:19 +0100
From: Tim Deegan <tim@xen.org>
To: "Ding, ShengGe" <ShengGe.Ding@amd.com>
Message-ID: <20120927144519.GF8831@ocelot.phlegethon.org>
References: <4DEE49724F3FA0438F8949D4497F451A05620D7B@SCYBEXDAG03.amd.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4DEE49724F3FA0438F8949D4497F451A05620D7B@SCYBEXDAG03.amd.com>
User-Agent: Mutt/1.4.2.1i
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] dom0 crashes while domain_pause in NPF handler
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi,

At 05:25 +0000 on 18 Sep (1347945907), Ding, ShengGe wrote:
> Hi all,
> 
> I checked the domain_id again and I'm sure the paused domain is domU.
> But the crashing seems like dom0 is paused, then whole system is killed and reboots.
> 
> In Nested page fault handler, hypervisor get the VCPU via current macro and this VCPU is bound to domU(the domain_id is so).
> I'm really confused, how does dom0 crash if I pause domU here? Maybe this is a logic issue of hypervisor, the same codes could run well in old version.
> 

You haven't given enough information to understand what's gone wrong. 

What do you mean my 'dom0 crashes'?  Can you post a log of the serial
console of the machine showing the actual crash?

What changes have you made to Xen?  If your patches are very small,
maybe you could post them; if not, at least a description of what you've
done would be a good idea.

Calling domain_pause() on domU from inside a domU fault handler is
probably unsafe -- if two vcpus take the fault at the same time they
might deadlock. 

Tim.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 27 14:45:52 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Sep 2012 14:45:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1THFLA-0007JV-NM; Thu, 27 Sep 2012 14:45: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 1THFL8-0007JP-HF
	for xen-devel@lists.xen.org; Thu, 27 Sep 2012 14:45:22 +0000
Received: from [85.158.143.99:4437] by server-3.bemta-4.messagelabs.com id
	6C/90-10986-18664605; Thu, 27 Sep 2012 14:45:21 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-3.tower-216.messagelabs.com!1348757120!31419150!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26912 invoked from network); 27 Sep 2012 14:45:20 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-3.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 27 Sep 2012 14:45:20 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1THFL5-00036f-54; Thu, 27 Sep 2012 14:45:19 +0000
Date: Thu, 27 Sep 2012 15:45:19 +0100
From: Tim Deegan <tim@xen.org>
To: "Ding, ShengGe" <ShengGe.Ding@amd.com>
Message-ID: <20120927144519.GF8831@ocelot.phlegethon.org>
References: <4DEE49724F3FA0438F8949D4497F451A05620D7B@SCYBEXDAG03.amd.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4DEE49724F3FA0438F8949D4497F451A05620D7B@SCYBEXDAG03.amd.com>
User-Agent: Mutt/1.4.2.1i
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] dom0 crashes while domain_pause in NPF handler
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi,

At 05:25 +0000 on 18 Sep (1347945907), Ding, ShengGe wrote:
> Hi all,
> 
> I checked the domain_id again and I'm sure the paused domain is domU.
> But the crashing seems like dom0 is paused, then whole system is killed and reboots.
> 
> In Nested page fault handler, hypervisor get the VCPU via current macro and this VCPU is bound to domU(the domain_id is so).
> I'm really confused, how does dom0 crash if I pause domU here? Maybe this is a logic issue of hypervisor, the same codes could run well in old version.
> 

You haven't given enough information to understand what's gone wrong. 

What do you mean my 'dom0 crashes'?  Can you post a log of the serial
console of the machine showing the actual crash?

What changes have you made to Xen?  If your patches are very small,
maybe you could post them; if not, at least a description of what you've
done would be a good idea.

Calling domain_pause() on domU from inside a domU fault handler is
probably unsafe -- if two vcpus take the fault at the same time they
might deadlock. 

Tim.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 27 14:50:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Sep 2012 14: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 1THFPS-0007UD-DN; Thu, 27 Sep 2012 14:49:50 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <malcolm.crossley@citrix.com>) id 1THFPR-0007U8-He
	for xen-devel@lists.xen.org; Thu, 27 Sep 2012 14:49:49 +0000
Received: from [85.158.139.83:3234] by server-12.bemta-5.messagelabs.com id
	7F/76-20729-C8764605; Thu, 27 Sep 2012 14:49:48 +0000
X-Env-Sender: malcolm.crossley@citrix.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1348757386!25069342!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNzgwNTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30805 invoked from network); 27 Sep 2012 14:49:48 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-16.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Sep 2012 14:49:48 -0000
X-IronPort-AV: E=Sophos;i="4.80,496,1344211200"; d="scan'208";a="209559241"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Sep 2012 14:49:04 +0000
Received: from [10.80.3.206] (10.80.3.206) by FTLPMAILMX02.citrite.net
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1; Thu, 27 Sep 2012
	10:49:04 -0400
Message-ID: <5064675F.307@citrix.com>
Date: Thu, 27 Sep 2012 15:49:03 +0100
From: Malcolm Crossley <malcolm.crossley@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120912 Thunderbird/15.0.1
MIME-Version: 1.0
To: <xen-devel@lists.xen.org>
References: <50648161020000780009E418@nat28.tlf.novell.com>
In-Reply-To: <50648161020000780009E418@nat28.tlf.novell.com>
Subject: Re: [Xen-devel] [PATCH] x86/HPET: don't disable interrupt delivery
 right after setting it up
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-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/09/12 15:40, Jan Beulich wrote:
> We shouldn't clear HPET_TN_FSB right after we (indirectly, via
> request_irq()) enabled it for the channels we intend to use for
> broadcasts.
>
> This fixes a regression introduced by c/s 25103:0b0e42dc4f0a.
>
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> ---
> This fixes the MWAIT idle driver problem on the box that I was able to
> (artificially) reproduce it with. Hence I subsequently intend to revert
> 25960:6bf8b882df8f, but I'm not intending to do this before getting a
> push there.
>
> I'm surprised that this didn't hit anyone so far with the ACPI-based
> idle driver...
Good catch Jan, Does this fix need backporting to Xen 4.2 and 4.1?
> --- 2012-09-21.orig/xen/arch/x86/hpet.c	2012-09-27 16:10:35.000000000 +0200
> +++ 2012-09-21/xen/arch/x86/hpet.c	2012-09-27 16:10:07.000000000 +0200
> @@ -533,7 +533,7 @@ void __init hpet_broadcast_init(void)
>       {
>           /* set HPET Tn as oneshot */
>           cfg = hpet_read32(HPET_Tn_CFG(hpet_events[i].idx));
> -        cfg &= ~(HPET_TN_LEVEL | HPET_TN_PERIODIC | HPET_TN_FSB);
> +        cfg &= ~(HPET_TN_LEVEL | HPET_TN_PERIODIC);
>           cfg |= HPET_TN_ENABLE | HPET_TN_32BIT;
>           hpet_write32(cfg, HPET_Tn_CFG(hpet_events[i].idx));
>   
> @@ -590,7 +590,7 @@ void hpet_broadcast_resume(void)
>   
>           /* set HPET Tn as oneshot */
>           cfg = hpet_read32(HPET_Tn_CFG(hpet_events[i].idx));
> -        cfg &= ~(HPET_TN_LEVEL | HPET_TN_PERIODIC | HPET_TN_FSB);
> +        cfg &= ~(HPET_TN_LEVEL | HPET_TN_PERIODIC);
>           cfg |= HPET_TN_ENABLE | HPET_TN_32BIT;
>           hpet_write32(cfg, HPET_Tn_CFG(hpet_events[i].idx));
>   
>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 27 14:50:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Sep 2012 14: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 1THFPS-0007UD-DN; Thu, 27 Sep 2012 14:49:50 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <malcolm.crossley@citrix.com>) id 1THFPR-0007U8-He
	for xen-devel@lists.xen.org; Thu, 27 Sep 2012 14:49:49 +0000
Received: from [85.158.139.83:3234] by server-12.bemta-5.messagelabs.com id
	7F/76-20729-C8764605; Thu, 27 Sep 2012 14:49:48 +0000
X-Env-Sender: malcolm.crossley@citrix.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1348757386!25069342!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNzgwNTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30805 invoked from network); 27 Sep 2012 14:49:48 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-16.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Sep 2012 14:49:48 -0000
X-IronPort-AV: E=Sophos;i="4.80,496,1344211200"; d="scan'208";a="209559241"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Sep 2012 14:49:04 +0000
Received: from [10.80.3.206] (10.80.3.206) by FTLPMAILMX02.citrite.net
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1; Thu, 27 Sep 2012
	10:49:04 -0400
Message-ID: <5064675F.307@citrix.com>
Date: Thu, 27 Sep 2012 15:49:03 +0100
From: Malcolm Crossley <malcolm.crossley@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120912 Thunderbird/15.0.1
MIME-Version: 1.0
To: <xen-devel@lists.xen.org>
References: <50648161020000780009E418@nat28.tlf.novell.com>
In-Reply-To: <50648161020000780009E418@nat28.tlf.novell.com>
Subject: Re: [Xen-devel] [PATCH] x86/HPET: don't disable interrupt delivery
 right after setting it up
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-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/09/12 15:40, Jan Beulich wrote:
> We shouldn't clear HPET_TN_FSB right after we (indirectly, via
> request_irq()) enabled it for the channels we intend to use for
> broadcasts.
>
> This fixes a regression introduced by c/s 25103:0b0e42dc4f0a.
>
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> ---
> This fixes the MWAIT idle driver problem on the box that I was able to
> (artificially) reproduce it with. Hence I subsequently intend to revert
> 25960:6bf8b882df8f, but I'm not intending to do this before getting a
> push there.
>
> I'm surprised that this didn't hit anyone so far with the ACPI-based
> idle driver...
Good catch Jan, Does this fix need backporting to Xen 4.2 and 4.1?
> --- 2012-09-21.orig/xen/arch/x86/hpet.c	2012-09-27 16:10:35.000000000 +0200
> +++ 2012-09-21/xen/arch/x86/hpet.c	2012-09-27 16:10:07.000000000 +0200
> @@ -533,7 +533,7 @@ void __init hpet_broadcast_init(void)
>       {
>           /* set HPET Tn as oneshot */
>           cfg = hpet_read32(HPET_Tn_CFG(hpet_events[i].idx));
> -        cfg &= ~(HPET_TN_LEVEL | HPET_TN_PERIODIC | HPET_TN_FSB);
> +        cfg &= ~(HPET_TN_LEVEL | HPET_TN_PERIODIC);
>           cfg |= HPET_TN_ENABLE | HPET_TN_32BIT;
>           hpet_write32(cfg, HPET_Tn_CFG(hpet_events[i].idx));
>   
> @@ -590,7 +590,7 @@ void hpet_broadcast_resume(void)
>   
>           /* set HPET Tn as oneshot */
>           cfg = hpet_read32(HPET_Tn_CFG(hpet_events[i].idx));
> -        cfg &= ~(HPET_TN_LEVEL | HPET_TN_PERIODIC | HPET_TN_FSB);
> +        cfg &= ~(HPET_TN_LEVEL | HPET_TN_PERIODIC);
>           cfg |= HPET_TN_ENABLE | HPET_TN_32BIT;
>           hpet_write32(cfg, HPET_Tn_CFG(hpet_events[i].idx));
>   
>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 27 14:50:17 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Sep 2012 14: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 1THFPe-0007VB-0p; Thu, 27 Sep 2012 14:50:02 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1THFPc-0007Ut-1k
	for xen-devel@lists.xen.org; Thu, 27 Sep 2012 14:50:00 +0000
Received: from [85.158.139.211:8410] by server-13.bemta-5.messagelabs.com id
	F3/A5-16359-79764605; Thu, 27 Sep 2012 14:49:59 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-16.tower-206.messagelabs.com!1348757398!20238113!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7757 invoked from network); 27 Sep 2012 14:49:58 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-16.tower-206.messagelabs.com with SMTP;
	27 Sep 2012 14:49:58 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 27 Sep 2012 15:49:58 +0100
Message-Id: <506483CC020000780009E42C@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 27 Sep 2012 15:50:20 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part87B6BEBC.1__="
Cc: andrew.cooper3@citrix.com
Subject: [Xen-devel] [PATCH] x86/IRQ: fix valid-old-vector checks in
 __assign_irq_vector()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<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.

--=__Part87B6BEBC.1__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

There are two greater-than-zero checks for the old vector retrieved,
which don't work when a negative value got stashed into the respective
arch_irq_desc field. The effect of this was that for interrupts that
are intended to get their affinity adjusted the first time before the
first interrupt occurs, the affinity change would fail, because the
original vector assignment would have caused the move_in_progress flag
to get set (which causes subsequent re-assignments to fail until it
gets cleared, which only happens from the ->ack() actor, i.e. when an
interrupt actually occurred).

This addresses a problem introduced in c/s 23816:7f357e1ef60a (by
changing IRQ_VECTOR_UNASSIGNED from 0 to -1).

Signed-off-by: Jan Beulich <jbeulich@suse.com>
---
I have to admit that I don't understand why the value got changed in
the first place: 0 is as invalid a value as -1 for a vector to be used
for delivering hardware interrupts.

--- 2012-09-21.orig/xen/arch/x86/irq.c	2012-09-19 08:48:33.000000000 =
+0200
+++ 2012-09-21/xen/arch/x86/irq.c	2012-09-27 13:33:45.000000000 =
+0200
@@ -430,8 +430,7 @@ static int __assign_irq_vector(
      * 0x80, because int 0x80 is hm, kind of importantish. ;)
      */
     static int current_vector =3D FIRST_DYNAMIC_VECTOR, current_offset =
=3D 0;
-    unsigned int old_vector;
-    int cpu, err;
+    int cpu, err, old_vector;
     cpumask_t tmp_mask;
     vmask_t *irq_used_vectors =3D NULL;
=20




--=__Part87B6BEBC.1__=
Content-Type: text/plain; name="x86-assign-irq-vector-old.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="x86-assign-irq-vector-old.patch"

x86/IRQ: fix valid-old-vector checks in __assign_irq_vector()=0A=0AThere =
are two greater-than-zero checks for the old vector retrieved,=0Awhich =
don't work when a negative value got stashed into the respective=0Aarch_irq=
_desc field. The effect of this was that for interrupts that=0Aare =
intended to get their affinity adjusted the first time before the=0Afirst =
interrupt occurs, the affinity change would fail, because the=0Aoriginal =
vector assignment would have caused the move_in_progress flag=0Ato get set =
(which causes subsequent re-assignments to fail until it=0Agets cleared, =
which only happens from the ->ack() actor, i.e. when an=0Ainterrupt =
actually occurred).=0A=0AThis addresses a problem introduced in c/s =
23816:7f357e1ef60a (by=0Achanging IRQ_VECTOR_UNASSIGNED from 0 to =
-1).=0A=0ASigned-off-by: Jan Beulich <jbeulich@suse.com>=0A---=0AI have to =
admit that I don't understand why the value got changed in=0Athe first =
place: 0 is as invalid a value as -1 for a vector to be used=0Afor =
delivering hardware interrupts.=0A=0A--- 2012-09-21.orig/xen/arch/x86/irq.c=
	2012-09-19 08:48:33.000000000 +0200=0A+++ 2012-09-21/xen/arch/x86/i=
rq.c	2012-09-27 13:33:45.000000000 +0200=0A@@ -430,8 +430,7 @@ static =
int __assign_irq_vector(=0A      * 0x80, because int 0x80 is hm, kind of =
importantish. ;)=0A      */=0A     static int current_vector =3D FIRST_DYNA=
MIC_VECTOR, current_offset =3D 0;=0A-    unsigned int old_vector;=0A-    =
int cpu, err;=0A+    int cpu, err, old_vector;=0A     cpumask_t =
tmp_mask;=0A     vmask_t *irq_used_vectors =3D NULL;=0A =0A
--=__Part87B6BEBC.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

--=__Part87B6BEBC.1__=--


From xen-devel-bounces@lists.xen.org Thu Sep 27 14:50:17 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Sep 2012 14: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 1THFPe-0007VB-0p; Thu, 27 Sep 2012 14:50:02 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1THFPc-0007Ut-1k
	for xen-devel@lists.xen.org; Thu, 27 Sep 2012 14:50:00 +0000
Received: from [85.158.139.211:8410] by server-13.bemta-5.messagelabs.com id
	F3/A5-16359-79764605; Thu, 27 Sep 2012 14:49:59 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-16.tower-206.messagelabs.com!1348757398!20238113!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7757 invoked from network); 27 Sep 2012 14:49:58 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-16.tower-206.messagelabs.com with SMTP;
	27 Sep 2012 14:49:58 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 27 Sep 2012 15:49:58 +0100
Message-Id: <506483CC020000780009E42C@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 27 Sep 2012 15:50:20 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part87B6BEBC.1__="
Cc: andrew.cooper3@citrix.com
Subject: [Xen-devel] [PATCH] x86/IRQ: fix valid-old-vector checks in
 __assign_irq_vector()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<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.

--=__Part87B6BEBC.1__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

There are two greater-than-zero checks for the old vector retrieved,
which don't work when a negative value got stashed into the respective
arch_irq_desc field. The effect of this was that for interrupts that
are intended to get their affinity adjusted the first time before the
first interrupt occurs, the affinity change would fail, because the
original vector assignment would have caused the move_in_progress flag
to get set (which causes subsequent re-assignments to fail until it
gets cleared, which only happens from the ->ack() actor, i.e. when an
interrupt actually occurred).

This addresses a problem introduced in c/s 23816:7f357e1ef60a (by
changing IRQ_VECTOR_UNASSIGNED from 0 to -1).

Signed-off-by: Jan Beulich <jbeulich@suse.com>
---
I have to admit that I don't understand why the value got changed in
the first place: 0 is as invalid a value as -1 for a vector to be used
for delivering hardware interrupts.

--- 2012-09-21.orig/xen/arch/x86/irq.c	2012-09-19 08:48:33.000000000 =
+0200
+++ 2012-09-21/xen/arch/x86/irq.c	2012-09-27 13:33:45.000000000 =
+0200
@@ -430,8 +430,7 @@ static int __assign_irq_vector(
      * 0x80, because int 0x80 is hm, kind of importantish. ;)
      */
     static int current_vector =3D FIRST_DYNAMIC_VECTOR, current_offset =
=3D 0;
-    unsigned int old_vector;
-    int cpu, err;
+    int cpu, err, old_vector;
     cpumask_t tmp_mask;
     vmask_t *irq_used_vectors =3D NULL;
=20




--=__Part87B6BEBC.1__=
Content-Type: text/plain; name="x86-assign-irq-vector-old.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="x86-assign-irq-vector-old.patch"

x86/IRQ: fix valid-old-vector checks in __assign_irq_vector()=0A=0AThere =
are two greater-than-zero checks for the old vector retrieved,=0Awhich =
don't work when a negative value got stashed into the respective=0Aarch_irq=
_desc field. The effect of this was that for interrupts that=0Aare =
intended to get their affinity adjusted the first time before the=0Afirst =
interrupt occurs, the affinity change would fail, because the=0Aoriginal =
vector assignment would have caused the move_in_progress flag=0Ato get set =
(which causes subsequent re-assignments to fail until it=0Agets cleared, =
which only happens from the ->ack() actor, i.e. when an=0Ainterrupt =
actually occurred).=0A=0AThis addresses a problem introduced in c/s =
23816:7f357e1ef60a (by=0Achanging IRQ_VECTOR_UNASSIGNED from 0 to =
-1).=0A=0ASigned-off-by: Jan Beulich <jbeulich@suse.com>=0A---=0AI have to =
admit that I don't understand why the value got changed in=0Athe first =
place: 0 is as invalid a value as -1 for a vector to be used=0Afor =
delivering hardware interrupts.=0A=0A--- 2012-09-21.orig/xen/arch/x86/irq.c=
	2012-09-19 08:48:33.000000000 +0200=0A+++ 2012-09-21/xen/arch/x86/i=
rq.c	2012-09-27 13:33:45.000000000 +0200=0A@@ -430,8 +430,7 @@ static =
int __assign_irq_vector(=0A      * 0x80, because int 0x80 is hm, kind of =
importantish. ;)=0A      */=0A     static int current_vector =3D FIRST_DYNA=
MIC_VECTOR, current_offset =3D 0;=0A-    unsigned int old_vector;=0A-    =
int cpu, err;=0A+    int cpu, err, old_vector;=0A     cpumask_t =
tmp_mask;=0A     vmask_t *irq_used_vectors =3D NULL;=0A =0A
--=__Part87B6BEBC.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

--=__Part87B6BEBC.1__=--


From xen-devel-bounces@lists.xen.org Thu Sep 27 14:54:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Sep 2012 14:54: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 1THFTT-0007jo-Nj; Thu, 27 Sep 2012 14:53: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 1THFTS-0007jf-P5
	for xen-devel@lists.xen.org; Thu, 27 Sep 2012 14:53:58 +0000
Received: from [85.158.139.83:56665] by server-5.bemta-5.messagelabs.com id
	73/4C-21075-58864605; Thu, 27 Sep 2012 14:53:57 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-9.tower-182.messagelabs.com!1348757637!31742669!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14497 invoked from network); 27 Sep 2012 14:53:57 -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; 27 Sep 2012 14:53:57 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1THFTQ-00037h-3W; Thu, 27 Sep 2012 14:53:56 +0000
Date: Thu, 27 Sep 2012 15:53:56 +0100
From: Tim Deegan <tim@xen.org>
To: Christoph Egger <Christoph.Egger@amd.com>
Message-ID: <20120927145356.GG8831@ocelot.phlegethon.org>
References: <505C733B.50205@amd.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <505C733B.50205@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] nestedsvm: fix paging mode
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At 16:01 +0200 on 21 Sep (1348243291), Christoph Egger wrote:
> 
> On VMRUN and VMEXIT emulation update the paging mode
> for Shadow-on-Nested. This allows Xen to walk the
> l1 hypervisors shadow page table correctly.
> Problem found with 64bit Win7 and 32bit XPMode where
> Win7 switches forth and back between long mode and
> PAE legacy pagetables.
> 
> Signed-off-by: Christoph Egger <Christoph.Egger@amd.com>

Don't you have to do this in other cases as well?  I think that
shadow-on-shadow might need it, at least.

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 27 14:54:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Sep 2012 14:54: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 1THFTT-0007jo-Nj; Thu, 27 Sep 2012 14:53: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 1THFTS-0007jf-P5
	for xen-devel@lists.xen.org; Thu, 27 Sep 2012 14:53:58 +0000
Received: from [85.158.139.83:56665] by server-5.bemta-5.messagelabs.com id
	73/4C-21075-58864605; Thu, 27 Sep 2012 14:53:57 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-9.tower-182.messagelabs.com!1348757637!31742669!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14497 invoked from network); 27 Sep 2012 14:53:57 -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; 27 Sep 2012 14:53:57 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1THFTQ-00037h-3W; Thu, 27 Sep 2012 14:53:56 +0000
Date: Thu, 27 Sep 2012 15:53:56 +0100
From: Tim Deegan <tim@xen.org>
To: Christoph Egger <Christoph.Egger@amd.com>
Message-ID: <20120927145356.GG8831@ocelot.phlegethon.org>
References: <505C733B.50205@amd.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <505C733B.50205@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] nestedsvm: fix paging mode
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

At 16:01 +0200 on 21 Sep (1348243291), Christoph Egger wrote:
> 
> On VMRUN and VMEXIT emulation update the paging mode
> for Shadow-on-Nested. This allows Xen to walk the
> l1 hypervisors shadow page table correctly.
> Problem found with 64bit Win7 and 32bit XPMode where
> Win7 switches forth and back between long mode and
> PAE legacy pagetables.
> 
> Signed-off-by: Christoph Egger <Christoph.Egger@amd.com>

Don't you have to do this in other cases as well?  I think that
shadow-on-shadow might need it, at least.

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 27 14:55:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Sep 2012 14:55:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1THFUV-0007oe-64; Thu, 27 Sep 2012 14:55:03 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1THFUU-0007oU-0S
	for xen-devel@lists.xen.org; Thu, 27 Sep 2012 14:55:02 +0000
Received: from [85.158.137.99:31704] by server-9.bemta-3.messagelabs.com id
	44/55-20338-5C864605; Thu, 27 Sep 2012 14:55:01 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-6.tower-217.messagelabs.com!1348757700!14244829!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4391 invoked from network); 27 Sep 2012 14:55:00 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-6.tower-217.messagelabs.com with SMTP;
	27 Sep 2012 14:55:00 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 27 Sep 2012 15:55:00 +0100
Message-Id: <506484FA020000780009E43D@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 27 Sep 2012 15:55:22 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__PartFECFC7CA.0__="
Subject: [Xen-devel] [PATCH] x86/HPET: don't needlessly set up channels for
 broadcast
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<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.

--=__PartFECFC7CA.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

When there are more FSB delivery capable HPET channels than CPU cores
(or threads), we can simply use a dedicated channel per CPU. This
avoids wasting the resources to handle the excess channels (including
the pointless triggering of the respective interrupt on each
wraparound) as well as the ping-pong of the interrupts' affinities
(when getting assigned to different CPUs).

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/arch/x86/hpet.c
+++ b/xen/arch/x86/hpet.c
@@ -369,7 +369,7 @@ static void __init hpet_fsb_cap_lookup(v
     if ( !hpet_events )
         return;
=20
-    for ( i =3D 0; i < num_chs; i++ )
+    for ( i =3D 0; i < num_chs && num_hpets_used < nr_cpu_ids; i++ )
     {
         struct hpet_event_channel *ch =3D &hpet_events[num_hpets_used];
         u32 cfg =3D hpet_read32(HPET_Tn_CFG(i));
@@ -408,6 +408,9 @@ static struct hpet_event_channel *hpet_g
     if ( num_hpets_used =3D=3D 0 )
         return hpet_events;
=20
+    if ( num_hpets_used >=3D nr_cpu_ids )
+        return &hpet_events[cpu];
+
     do {
         next =3D next_channel;
         if ( (i =3D next + 1) =3D=3D num_hpets_used )




--=__PartFECFC7CA.0__=
Content-Type: text/plain; name="x86-HPET-reduce.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="x86-HPET-reduce.patch"

x86/HPET: don't needlessly set up channels for broadcast=0A=0AWhen there =
are more FSB delivery capable HPET channels than CPU cores=0A(or threads), =
we can simply use a dedicated channel per CPU. This=0Aavoids wasting the =
resources to handle the excess channels (including=0Athe pointless =
triggering of the respective interrupt on each=0Awraparound) as well as =
the ping-pong of the interrupts' affinities=0A(when getting assigned to =
different CPUs).=0A=0ASigned-off-by: Jan Beulich <jbeulich@suse.com>=0A=0A-=
-- a/xen/arch/x86/hpet.c=0A+++ b/xen/arch/x86/hpet.c=0A@@ -369,7 +369,7 @@ =
static void __init hpet_fsb_cap_lookup(v=0A     if ( !hpet_events )=0A     =
    return;=0A =0A-    for ( i =3D 0; i < num_chs; i++ )=0A+    for ( i =
=3D 0; i < num_chs && num_hpets_used < nr_cpu_ids; i++ )=0A     {=0A       =
  struct hpet_event_channel *ch =3D &hpet_events[num_hpets_used];=0A       =
  u32 cfg =3D hpet_read32(HPET_Tn_CFG(i));=0A@@ -408,6 +408,9 @@ static =
struct hpet_event_channel *hpet_g=0A     if ( num_hpets_used =3D=3D 0 )=0A =
        return hpet_events;=0A =0A+    if ( num_hpets_used >=3D nr_cpu_ids =
)=0A+        return &hpet_events[cpu];=0A+=0A     do {=0A         next =3D =
next_channel;=0A         if ( (i =3D next + 1) =3D=3D num_hpets_used )=0A
--=__PartFECFC7CA.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

--=__PartFECFC7CA.0__=--


From xen-devel-bounces@lists.xen.org Thu Sep 27 14:55:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Sep 2012 14:55:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1THFUV-0007oe-64; Thu, 27 Sep 2012 14:55:03 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1THFUU-0007oU-0S
	for xen-devel@lists.xen.org; Thu, 27 Sep 2012 14:55:02 +0000
Received: from [85.158.137.99:31704] by server-9.bemta-3.messagelabs.com id
	44/55-20338-5C864605; Thu, 27 Sep 2012 14:55:01 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-6.tower-217.messagelabs.com!1348757700!14244829!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4391 invoked from network); 27 Sep 2012 14:55:00 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-6.tower-217.messagelabs.com with SMTP;
	27 Sep 2012 14:55:00 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 27 Sep 2012 15:55:00 +0100
Message-Id: <506484FA020000780009E43D@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 27 Sep 2012 15:55:22 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__PartFECFC7CA.0__="
Subject: [Xen-devel] [PATCH] x86/HPET: don't needlessly set up channels for
 broadcast
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<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.

--=__PartFECFC7CA.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

When there are more FSB delivery capable HPET channels than CPU cores
(or threads), we can simply use a dedicated channel per CPU. This
avoids wasting the resources to handle the excess channels (including
the pointless triggering of the respective interrupt on each
wraparound) as well as the ping-pong of the interrupts' affinities
(when getting assigned to different CPUs).

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/arch/x86/hpet.c
+++ b/xen/arch/x86/hpet.c
@@ -369,7 +369,7 @@ static void __init hpet_fsb_cap_lookup(v
     if ( !hpet_events )
         return;
=20
-    for ( i =3D 0; i < num_chs; i++ )
+    for ( i =3D 0; i < num_chs && num_hpets_used < nr_cpu_ids; i++ )
     {
         struct hpet_event_channel *ch =3D &hpet_events[num_hpets_used];
         u32 cfg =3D hpet_read32(HPET_Tn_CFG(i));
@@ -408,6 +408,9 @@ static struct hpet_event_channel *hpet_g
     if ( num_hpets_used =3D=3D 0 )
         return hpet_events;
=20
+    if ( num_hpets_used >=3D nr_cpu_ids )
+        return &hpet_events[cpu];
+
     do {
         next =3D next_channel;
         if ( (i =3D next + 1) =3D=3D num_hpets_used )




--=__PartFECFC7CA.0__=
Content-Type: text/plain; name="x86-HPET-reduce.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="x86-HPET-reduce.patch"

x86/HPET: don't needlessly set up channels for broadcast=0A=0AWhen there =
are more FSB delivery capable HPET channels than CPU cores=0A(or threads), =
we can simply use a dedicated channel per CPU. This=0Aavoids wasting the =
resources to handle the excess channels (including=0Athe pointless =
triggering of the respective interrupt on each=0Awraparound) as well as =
the ping-pong of the interrupts' affinities=0A(when getting assigned to =
different CPUs).=0A=0ASigned-off-by: Jan Beulich <jbeulich@suse.com>=0A=0A-=
-- a/xen/arch/x86/hpet.c=0A+++ b/xen/arch/x86/hpet.c=0A@@ -369,7 +369,7 @@ =
static void __init hpet_fsb_cap_lookup(v=0A     if ( !hpet_events )=0A     =
    return;=0A =0A-    for ( i =3D 0; i < num_chs; i++ )=0A+    for ( i =
=3D 0; i < num_chs && num_hpets_used < nr_cpu_ids; i++ )=0A     {=0A       =
  struct hpet_event_channel *ch =3D &hpet_events[num_hpets_used];=0A       =
  u32 cfg =3D hpet_read32(HPET_Tn_CFG(i));=0A@@ -408,6 +408,9 @@ static =
struct hpet_event_channel *hpet_g=0A     if ( num_hpets_used =3D=3D 0 )=0A =
        return hpet_events;=0A =0A+    if ( num_hpets_used >=3D nr_cpu_ids =
)=0A+        return &hpet_events[cpu];=0A+=0A     do {=0A         next =3D =
next_channel;=0A         if ( (i =3D next + 1) =3D=3D num_hpets_used )=0A
--=__PartFECFC7CA.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

--=__PartFECFC7CA.0__=--


From xen-devel-bounces@lists.xen.org Thu Sep 27 14:57:24 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Sep 2012 14:57:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1THFWZ-0007yU-N4; Thu, 27 Sep 2012 14:57: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 1THFWY-0007yM-Jo
	for xen-devel@lists.xen.org; Thu, 27 Sep 2012 14:57:10 +0000
Received: from [85.158.137.99:38691] by server-2.bemta-3.messagelabs.com id
	5A/7C-16514-54964605; Thu, 27 Sep 2012 14:57:09 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-2.tower-217.messagelabs.com!1348757829!19261452!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31165 invoked from network); 27 Sep 2012 14:57:09 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-2.tower-217.messagelabs.com with SMTP;
	27 Sep 2012 14:57:09 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 27 Sep 2012 15:57:08 +0100
Message-Id: <5064857B020000780009E440@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 27 Sep 2012 15:57:31 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Malcolm Crossley" <malcolm.crossley@citrix.com>
References: <50648161020000780009E418@nat28.tlf.novell.com>
	<5064675F.307@citrix.com>
In-Reply-To: <5064675F.307@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] x86/HPET: don't disable interrupt delivery
 right after setting it up
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 27.09.12 at 16:49, Malcolm Crossley <malcolm.crossley@citrix.com> wrote:
> On 27/09/12 15:40, Jan Beulich wrote:
>> We shouldn't clear HPET_TN_FSB right after we (indirectly, via
>> request_irq()) enabled it for the channels we intend to use for
>> broadcasts.
>>
>> This fixes a regression introduced by c/s 25103:0b0e42dc4f0a.
>>
>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
>> ---
>> This fixes the MWAIT idle driver problem on the box that I was able to
>> (artificially) reproduce it with. Hence I subsequently intend to revert
>> 25960:6bf8b882df8f, but I'm not intending to do this before getting a
>> push there.
>>
>> I'm surprised that this didn't hit anyone so far with the ACPI-based
>> idle driver...
> Good catch Jan, Does this fix need backporting to Xen 4.2 and 4.1?

Definitely to 4.2. Didn't check yet whether the offending patch got
backported to 4.1.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 27 14:57:24 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Sep 2012 14:57:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1THFWZ-0007yU-N4; Thu, 27 Sep 2012 14:57: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 1THFWY-0007yM-Jo
	for xen-devel@lists.xen.org; Thu, 27 Sep 2012 14:57:10 +0000
Received: from [85.158.137.99:38691] by server-2.bemta-3.messagelabs.com id
	5A/7C-16514-54964605; Thu, 27 Sep 2012 14:57:09 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-2.tower-217.messagelabs.com!1348757829!19261452!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31165 invoked from network); 27 Sep 2012 14:57:09 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-2.tower-217.messagelabs.com with SMTP;
	27 Sep 2012 14:57:09 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 27 Sep 2012 15:57:08 +0100
Message-Id: <5064857B020000780009E440@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 27 Sep 2012 15:57:31 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Malcolm Crossley" <malcolm.crossley@citrix.com>
References: <50648161020000780009E418@nat28.tlf.novell.com>
	<5064675F.307@citrix.com>
In-Reply-To: <5064675F.307@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] x86/HPET: don't disable interrupt delivery
 right after setting it up
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

>>> On 27.09.12 at 16:49, Malcolm Crossley <malcolm.crossley@citrix.com> wrote:
> On 27/09/12 15:40, Jan Beulich wrote:
>> We shouldn't clear HPET_TN_FSB right after we (indirectly, via
>> request_irq()) enabled it for the channels we intend to use for
>> broadcasts.
>>
>> This fixes a regression introduced by c/s 25103:0b0e42dc4f0a.
>>
>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
>> ---
>> This fixes the MWAIT idle driver problem on the box that I was able to
>> (artificially) reproduce it with. Hence I subsequently intend to revert
>> 25960:6bf8b882df8f, but I'm not intending to do this before getting a
>> push there.
>>
>> I'm surprised that this didn't hit anyone so far with the ACPI-based
>> idle driver...
> Good catch Jan, Does this fix need backporting to Xen 4.2 and 4.1?

Definitely to 4.2. Didn't check yet whether the offending patch got
backported to 4.1.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 27 14:57:49 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Sep 2012 14:57:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1THFX0-00081p-3h; Thu, 27 Sep 2012 14:57:38 +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 1THFWy-00081Y-5F
	for xen-devel@lists.xen.org; Thu, 27 Sep 2012 14:57:36 +0000
Received: from [85.158.139.83:39467] by server-10.bemta-5.messagelabs.com id
	C3/62-16911-F5964605; Thu, 27 Sep 2012 14:57:35 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1348757853!28529845!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNzgwNTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22556 invoked from network); 27 Sep 2012 14:57:34 -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;
	27 Sep 2012 14:57:34 -0000
X-IronPort-AV: E=Sophos;i="4.80,496,1344211200"; d="scan'208";a="209560814"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Sep 2012 14:57:32 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Thu, 27 Sep 2012 10:57: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 1THFWt-0004BT-VG;
	Thu, 27 Sep 2012 15:57:31 +0100
Message-ID: <5064695B.1010805@citrix.com>
Date: Thu, 27 Sep 2012 15:57:31 +0100
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120912 Thunderbird/15.0.1
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <506483CC020000780009E42C@nat28.tlf.novell.com>
In-Reply-To: <506483CC020000780009E42C@nat28.tlf.novell.com>
X-Enigmail-Version: 1.4.4
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] x86/IRQ: fix valid-old-vector checks in
	__assign_irq_vector()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/09/12 15:50, Jan Beulich wrote:
> There are two greater-than-zero checks for the old vector retrieved,
> which don't work when a negative value got stashed into the respective
> arch_irq_desc field. The effect of this was that for interrupts that
> are intended to get their affinity adjusted the first time before the
> first interrupt occurs, the affinity change would fail, because the
> original vector assignment would have caused the move_in_progress flag
> to get set (which causes subsequent re-assignments to fail until it
> gets cleared, which only happens from the ->ack() actor, i.e. when an
> interrupt actually occurred).
>
> This addresses a problem introduced in c/s 23816:7f357e1ef60a (by
> changing IRQ_VECTOR_UNASSIGNED from 0 to -1).
>
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> ---
> I have to admit that I don't understand why the value got changed in
> the first place: 0 is as invalid a value as -1 for a vector to be used
> for delivering hardware interrupts.

http://lists.xen.org/archives/html/xen-devel/2011-09/msg00193.html

It was a suggestion for consistency with using -1 elsewhere in the irq
code to mean unassigned.

~Andrew

>
> --- 2012-09-21.orig/xen/arch/x86/irq.c	2012-09-19 08:48:33.000000000 +0200
> +++ 2012-09-21/xen/arch/x86/irq.c	2012-09-27 13:33:45.000000000 +0200
> @@ -430,8 +430,7 @@ static int __assign_irq_vector(
>       * 0x80, because int 0x80 is hm, kind of importantish. ;)
>       */
>      static int current_vector = FIRST_DYNAMIC_VECTOR, current_offset = 0;
> -    unsigned int old_vector;
> -    int cpu, err;
> +    int cpu, err, old_vector;
>      cpumask_t tmp_mask;
>      vmask_t *irq_used_vectors = NULL;
>  
>
>
>

-- 
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 Sep 27 14:57:49 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Sep 2012 14:57:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1THFX0-00081p-3h; Thu, 27 Sep 2012 14:57:38 +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 1THFWy-00081Y-5F
	for xen-devel@lists.xen.org; Thu, 27 Sep 2012 14:57:36 +0000
Received: from [85.158.139.83:39467] by server-10.bemta-5.messagelabs.com id
	C3/62-16911-F5964605; Thu, 27 Sep 2012 14:57:35 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1348757853!28529845!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNzgwNTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22556 invoked from network); 27 Sep 2012 14:57:34 -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;
	27 Sep 2012 14:57:34 -0000
X-IronPort-AV: E=Sophos;i="4.80,496,1344211200"; d="scan'208";a="209560814"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Sep 2012 14:57:32 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Thu, 27 Sep 2012 10:57: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 1THFWt-0004BT-VG;
	Thu, 27 Sep 2012 15:57:31 +0100
Message-ID: <5064695B.1010805@citrix.com>
Date: Thu, 27 Sep 2012 15:57:31 +0100
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120912 Thunderbird/15.0.1
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <506483CC020000780009E42C@nat28.tlf.novell.com>
In-Reply-To: <506483CC020000780009E42C@nat28.tlf.novell.com>
X-Enigmail-Version: 1.4.4
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] x86/IRQ: fix valid-old-vector checks in
	__assign_irq_vector()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/09/12 15:50, Jan Beulich wrote:
> There are two greater-than-zero checks for the old vector retrieved,
> which don't work when a negative value got stashed into the respective
> arch_irq_desc field. The effect of this was that for interrupts that
> are intended to get their affinity adjusted the first time before the
> first interrupt occurs, the affinity change would fail, because the
> original vector assignment would have caused the move_in_progress flag
> to get set (which causes subsequent re-assignments to fail until it
> gets cleared, which only happens from the ->ack() actor, i.e. when an
> interrupt actually occurred).
>
> This addresses a problem introduced in c/s 23816:7f357e1ef60a (by
> changing IRQ_VECTOR_UNASSIGNED from 0 to -1).
>
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> ---
> I have to admit that I don't understand why the value got changed in
> the first place: 0 is as invalid a value as -1 for a vector to be used
> for delivering hardware interrupts.

http://lists.xen.org/archives/html/xen-devel/2011-09/msg00193.html

It was a suggestion for consistency with using -1 elsewhere in the irq
code to mean unassigned.

~Andrew

>
> --- 2012-09-21.orig/xen/arch/x86/irq.c	2012-09-19 08:48:33.000000000 +0200
> +++ 2012-09-21/xen/arch/x86/irq.c	2012-09-27 13:33:45.000000000 +0200
> @@ -430,8 +430,7 @@ static int __assign_irq_vector(
>       * 0x80, because int 0x80 is hm, kind of importantish. ;)
>       */
>      static int current_vector = FIRST_DYNAMIC_VECTOR, current_offset = 0;
> -    unsigned int old_vector;
> -    int cpu, err;
> +    int cpu, err, old_vector;
>      cpumask_t tmp_mask;
>      vmask_t *irq_used_vectors = NULL;
>  
>
>
>

-- 
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 Sep 27 15:01:31 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Sep 2012 15:01:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1THFaa-0008LU-UY; Thu, 27 Sep 2012 15:01: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 1THFaZ-0008LL-DW
	for xen-devel@lists.xen.org; Thu, 27 Sep 2012 15:01:19 +0000
Received: from [85.158.137.99:31703] by server-3.bemta-3.messagelabs.com id
	E7/37-25962-E3A64605; Thu, 27 Sep 2012 15:01:18 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-2.tower-217.messagelabs.com!1348758076!19261882!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8329 invoked from network); 27 Sep 2012 15:01:16 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-2.tower-217.messagelabs.com with SMTP;
	27 Sep 2012 15:01:16 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 27 Sep 2012 16:01:16 +0100
Message-Id: <50648672020000780009E45F@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 27 Sep 2012 16:01:38 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part74454D42.0__="
Subject: [Xen-devel] [PATCH] x86: remove further code applicable to 32-bit
 CPUs 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>
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.

--=__Part74454D42.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

On the AMD side, anything prior to family 0xf can now be ignored, as
well as very low model numbers of family 6 on the Intel side.

Apart from that, there were several made up CPU features that turned
out entirely unused throughout the tree.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/arch/x86/cpu/amd.c
+++ b/xen/arch/x86/cpu/amd.c
@@ -180,7 +180,7 @@ static void __devinit set_cpuidmask(cons
 	if (c->x86 >=3D 0x10) {
 		wrmsr(MSR_K8_FEATURE_MASK, feat_edx, feat_ecx);
 		wrmsr(MSR_K8_EXT_FEATURE_MASK, extfeat_edx, extfeat_ecx);
-	} else if (c->x86 =3D=3D 0x0f) {
+	} else {
 		wrmsr_amd(MSR_K8_FEATURE_MASK, feat_edx, feat_ecx);
 		wrmsr_amd(MSR_K8_EXT_FEATURE_MASK, extfeat_edx, extfeat_ecx=
);
 	}
@@ -234,14 +234,7 @@ int cpu_has_amd_erratum(const struct cpu
 /* Can this system suffer from TSC drift due to C1 clock ramping? */
 static int c1_ramping_may_cause_clock_drift(struct cpuinfo_x86 *c)=20
 {=20
-	if (c->x86 < 0xf) {
-		/*
-		 * TSC drift doesn't exist on 7th Gen or less
-		 * However, OS still needs to consider effects
-		 * of P-state changes on TSC
-		 */
-		return 0;
-	} else if (cpuid_edx(0x80000007) & (1<<8)) {
+	if (cpuid_edx(0x80000007) & (1<<8)) {
 		/*
 		 * CPUID.AdvPowerMgmtInfo.TscInvariant
 		 * EDX bit 8, 8000_0007
@@ -416,41 +409,7 @@ static void __devinit init_amd(struct cp
=20
 	switch(c->x86)
 	{
-	case 6: /* An Athlon/Duron */
-=20
-		/* Bit 15 of Athlon specific MSR 15, needs to be 0
-		 * to enable SSE on Palomino/Morgan/Barton CPU's.
-		 * If the BIOS didn't enable it already, enable it here.
-		 */
-		if (c->x86_model >=3D 6 && c->x86_model <=3D 10) {
-			if (!cpu_has(c, X86_FEATURE_XMM)) {
-				printk(KERN_INFO "Enabling disabled K7/SSE =
Support.\n");
-				rdmsr(MSR_K7_HWCR, l, h);
-				l &=3D ~0x00008000;
-				wrmsr(MSR_K7_HWCR, l, h);
-				set_bit(X86_FEATURE_XMM, c->x86_capability)=
;
-			}
-		}
-
-		/* It's been determined by AMD that Athlons since model 8 =
stepping 1
-		 * are more robust with CLK_CTL set to 200xxxxx instead of =
600xxxxx
-		 * As per AMD technical note 27212 0.2
-		 */
-		if ((c->x86_model =3D=3D 8 && c->x86_mask>=3D1) || =
(c->x86_model > 8)) {
-			rdmsr(MSR_K7_CLK_CTL, l, h);
-			if ((l & 0xfff00000) !=3D 0x20000000) {
-				printk ("CPU: CLK_CTL MSR was %x. =
Reprogramming to %x\n", l,
-					((l & 0x000fffff)|0x20000000));
-				wrmsr(MSR_K7_CLK_CTL, (l & 0x000fffff)|0x20=
000000, h);
-			}
-		}
-		set_bit(X86_FEATURE_K7, c->x86_capability);
-		break;
-
-	case 0xf:
-	/* Use K8 tuning for Fam10h and Fam11h */
-	case 0x10 ... 0x17:
-		set_bit(X86_FEATURE_K8, c->x86_capability);
+	case 0xf ... 0x17:
 		disable_c1e(NULL);
 		if (acpi_smi_cmd && (acpi_enable_value | acpi_disable_value=
))
 			pv_post_outb_hook =3D check_disable_c1e;
--- a/xen/arch/x86/cpu/intel.c
+++ b/xen/arch/x86/cpu/intel.c
@@ -192,7 +192,6 @@ static int __devinit num_cpu_cores(struc
 static void __devinit init_intel(struct cpuinfo_x86 *c)
 {
 	unsigned int l2 =3D 0;
-	char *p =3D NULL;
=20
 	/* Detect the extended topology information if available */
 	detect_extended_topology(c);
@@ -210,37 +209,6 @@ static void __devinit init_intel(struct=20
 	if ((c->x86<<8 | c->x86_model<<4 | c->x86_mask) < 0x633)
 		clear_bit(X86_FEATURE_SEP, c->x86_capability);
=20
-	/* Names for the Pentium II/Celeron processors=20
-	   detectable only by also checking the cache size.
-	   Dixon is NOT a Celeron. */
-	if (c->x86 =3D=3D 6) {
-		switch (c->x86_model) {
-		case 5:
-			if (c->x86_mask =3D=3D 0) {
-				if (l2 =3D=3D 0)
-					p =3D "Celeron (Covington)";
-				else if (l2 =3D=3D 256)
-					p =3D "Mobile Pentium II (Dixon)";
-			}
-			break;
-		=09
-		case 6:
-			if (l2 =3D=3D 128)
-				p =3D "Celeron (Mendocino)";
-			else if (c->x86_mask =3D=3D 0 || c->x86_mask =
=3D=3D 5)
-				p =3D "Celeron-A";
-			break;
-		=09
-		case 8:
-			if (l2 =3D=3D 128)
-				p =3D "Celeron (Coppermine)";
-			break;
-		}
-	}
-
-	if ( p )
-		safe_strcpy(c->x86_model_id, p);
-
 	if ( !cpu_has(c, X86_FEATURE_XTOPOLOGY) )
 	{
 		c->x86_max_cores =3D num_cpu_cores(c);
@@ -275,10 +243,6 @@ static void __devinit init_intel(struct=20
 	}
 #endif
=20
-	if (c->x86 =3D=3D 15)
-		set_bit(X86_FEATURE_P4, c->x86_capability);
-	if (c->x86 =3D=3D 6)=20
-		set_bit(X86_FEATURE_P3, c->x86_capability);
 	if ((c->x86 =3D=3D 0xf && c->x86_model >=3D 0x03) ||
 		(c->x86 =3D=3D 0x6 && c->x86_model >=3D 0x0e))
 		set_bit(X86_FEATURE_CONSTANT_TSC, c->x86_capability);
--- a/xen/include/asm-x86/cpufeature.h
+++ b/xen/include/asm-x86/cpufeature.h
@@ -64,15 +64,6 @@
=20
 /* Other features, Linux-defined mapping, word 3 */
 /* This range is used for feature bits which conflict or are synthesized =
*/
-#define X86_FEATURE_CXMMX	(3*32+ 0) /* Cyrix MMX extensions */
-#define X86_FEATURE_K6_MTRR	(3*32+ 1) /* AMD K6 nonstandard MTRRs */
-#define X86_FEATURE_CYRIX_ARR	(3*32+ 2) /* Cyrix ARRs (=3D MTRRs) */
-#define X86_FEATURE_CENTAUR_MCR	(3*32+ 3) /* Centaur MCRs (=3D =
MTRRs) */
-/* cpu types for specific tunings: */
-#define X86_FEATURE_K8		(3*32+ 4) /* Opteron, Athlon64 */
-#define X86_FEATURE_K7		(3*32+ 5) /* Athlon */
-#define X86_FEATURE_P3		(3*32+ 6) /* P3 */
-#define X86_FEATURE_P4		(3*32+ 7) /* P4 */
 #define X86_FEATURE_CONSTANT_TSC (3*32+ 8) /* TSC ticks at a constant =
rate */
 #define X86_FEATURE_NONSTOP_TSC	(3*32+ 9) /* TSC does not stop in =
C states */
 #define X86_FEATURE_ARAT	(3*32+ 10) /* Always running APIC timer */



--=__Part74454D42.0__=
Content-Type: text/plain; name="x86-no-PIII.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="x86-no-PIII.patch"

x86: remove further code applicable to 32-bit CPUs only=0A=0AOn the AMD =
side, anything prior to family 0xf can now be ignored, as=0Awell as very =
low model numbers of family 6 on the Intel side.=0A=0AApart from that, =
there were several made up CPU features that turned=0Aout entirely unused =
throughout the tree.=0A=0ASigned-off-by: Jan Beulich <jbeulich@suse.com>=0A=
=0A--- a/xen/arch/x86/cpu/amd.c=0A+++ b/xen/arch/x86/cpu/amd.c=0A@@ -180,7 =
+180,7 @@ static void __devinit set_cpuidmask(cons=0A 	if (c->x86 >=3D =
0x10) {=0A 		wrmsr(MSR_K8_FEATURE_MASK, feat_edx, feat_ecx);=0A =
		wrmsr(MSR_K8_EXT_FEATURE_MASK, extfeat_edx, extfeat_ecx);=
=0A-	} else if (c->x86 =3D=3D 0x0f) {=0A+	} else {=0A 		=
wrmsr_amd(MSR_K8_FEATURE_MASK, feat_edx, feat_ecx);=0A 		wrmsr_amd(M=
SR_K8_EXT_FEATURE_MASK, extfeat_edx, extfeat_ecx);=0A 	}=0A@@ -234,14 =
+234,7 @@ int cpu_has_amd_erratum(const struct cpu=0A /* Can this system =
suffer from TSC drift due to C1 clock ramping? */=0A static int c1_ramping_=
may_cause_clock_drift(struct cpuinfo_x86 *c) =0A { =0A-	if (c->x86 < 0xf) =
{=0A-		/*=0A-		 * TSC drift doesn't exist on 7th Gen or =
less=0A-		 * However, OS still needs to consider effects=0A-	=
	 * of P-state changes on TSC=0A-		 */=0A-		=
return 0;=0A-	} else if (cpuid_edx(0x80000007) & (1<<8)) {=0A+	if =
(cpuid_edx(0x80000007) & (1<<8)) {=0A 		/*=0A 		 * =
CPUID.AdvPowerMgmtInfo.TscInvariant=0A 		 * EDX bit 8, 8000_0007=0A@=
@ -416,41 +409,7 @@ static void __devinit init_amd(struct cp=0A =0A 	=
switch(c->x86)=0A 	{=0A-	case 6: /* An Athlon/Duron */=0A- =0A-		=
/* Bit 15 of Athlon specific MSR 15, needs to be 0=0A-		 * to =
enable SSE on Palomino/Morgan/Barton CPU's.=0A-		 * If the BIOS =
didn't enable it already, enable it here.=0A-		 */=0A-		if =
(c->x86_model >=3D 6 && c->x86_model <=3D 10) {=0A-			if =
(!cpu_has(c, X86_FEATURE_XMM)) {=0A-				printk(KERN=
_INFO "Enabling disabled K7/SSE Support.\n");=0A-				=
rdmsr(MSR_K7_HWCR, l, h);=0A-				l &=3D ~0x00008000;=
=0A-				wrmsr(MSR_K7_HWCR, l, h);=0A-			=
	set_bit(X86_FEATURE_XMM, c->x86_capability);=0A-			=
}=0A-		}=0A-=0A-		/* It's been determined by AMD =
that Athlons since model 8 stepping 1=0A-		 * are more robust =
with CLK_CTL set to 200xxxxx instead of 600xxxxx=0A-		 * As per =
AMD technical note 27212 0.2=0A-		 */=0A-		if =
((c->x86_model =3D=3D 8 && c->x86_mask>=3D1) || (c->x86_model > 8)) {=0A-	=
		rdmsr(MSR_K7_CLK_CTL, l, h);=0A-			if =
((l & 0xfff00000) !=3D 0x20000000) {=0A-				=
printk ("CPU: CLK_CTL MSR was %x. Reprogramming to %x\n", l,=0A-		=
			((l & 0x000fffff)|0x20000000));=0A-			=
	wrmsr(MSR_K7_CLK_CTL, (l & 0x000fffff)|0x20000000, h);=0A-		=
	}=0A-		}=0A-		set_bit(X86_FEATURE_K7, c->x86_capa=
bility);=0A-		break;=0A-=0A-	case 0xf:=0A-	/* Use K8 tuning =
for Fam10h and Fam11h */=0A-	case 0x10 ... 0x17:=0A-		set_bit(X86=
_FEATURE_K8, c->x86_capability);=0A+	case 0xf ... 0x17:=0A 		=
disable_c1e(NULL);=0A 		if (acpi_smi_cmd && (acpi_enable_value | =
acpi_disable_value))=0A 			pv_post_outb_hook =3D =
check_disable_c1e;=0A--- a/xen/arch/x86/cpu/intel.c=0A+++ b/xen/arch/x86/cp=
u/intel.c=0A@@ -192,7 +192,6 @@ static int __devinit num_cpu_cores(struc=0A=
 static void __devinit init_intel(struct cpuinfo_x86 *c)=0A {=0A 	=
unsigned int l2 =3D 0;=0A-	char *p =3D NULL;=0A =0A 	/* Detect =
the extended topology information if available */=0A 	detect_extended_top=
ology(c);=0A@@ -210,37 +209,6 @@ static void __devinit init_intel(struct =
=0A 	if ((c->x86<<8 | c->x86_model<<4 | c->x86_mask) < 0x633)=0A 		=
clear_bit(X86_FEATURE_SEP, c->x86_capability);=0A =0A-	/* Names for the =
Pentium II/Celeron processors =0A-	   detectable only by also =
checking the cache size.=0A-	   Dixon is NOT a Celeron. */=0A-	if =
(c->x86 =3D=3D 6) {=0A-		switch (c->x86_model) {=0A-		=
case 5:=0A-			if (c->x86_mask =3D=3D 0) {=0A-			=
	if (l2 =3D=3D 0)=0A-					p =3D =
"Celeron (Covington)";=0A-				else if (l2 =3D=3D =
256)=0A-					p =3D "Mobile Pentium II =
(Dixon)";=0A-			}=0A-			break;=0A-		=
	=0A-		case 6:=0A-			if (l2 =3D=3D =
128)=0A-				p =3D "Celeron (Mendocino)";=0A-	=
		else if (c->x86_mask =3D=3D 0 || c->x86_mask =3D=3D 5)=0A-	=
			p =3D "Celeron-A";=0A-			break;=0A-	=
		=0A-		case 8:=0A-			if (l2 =
=3D=3D 128)=0A-				p =3D "Celeron (Coppermine)";=0A-	=
		break;=0A-		}=0A-	}=0A-=0A-	if ( p =
)=0A-		safe_strcpy(c->x86_model_id, p);=0A-=0A 	if ( =
!cpu_has(c, X86_FEATURE_XTOPOLOGY) )=0A 	{=0A 		c->x86_max_=
cores =3D num_cpu_cores(c);=0A@@ -275,10 +243,6 @@ static void __devinit =
init_intel(struct =0A 	}=0A #endif=0A =0A-	if (c->x86 =3D=3D 15)=0A-	=
	set_bit(X86_FEATURE_P4, c->x86_capability);=0A-	if (c->x86 =3D=3D =
6) =0A-		set_bit(X86_FEATURE_P3, c->x86_capability);=0A 	if =
((c->x86 =3D=3D 0xf && c->x86_model >=3D 0x03) ||=0A 		(c->x86 =
=3D=3D 0x6 && c->x86_model >=3D 0x0e))=0A 		set_bit(X86_FEATURE=
_CONSTANT_TSC, c->x86_capability);=0A--- a/xen/include/asm-x86/cpufeature.h=
=0A+++ b/xen/include/asm-x86/cpufeature.h=0A@@ -64,15 +64,6 @@=0A =0A /* =
Other features, Linux-defined mapping, word 3 */=0A /* This range is used =
for feature bits which conflict or are synthesized */=0A-#define X86_FEATUR=
E_CXMMX	(3*32+ 0) /* Cyrix MMX extensions */=0A-#define X86_FEATURE_K6_MTRR=
	(3*32+ 1) /* AMD K6 nonstandard MTRRs */=0A-#define X86_FEATURE_CYR=
IX_ARR	(3*32+ 2) /* Cyrix ARRs (=3D MTRRs) */=0A-#define X86_FEATURE_CENTA=
UR_MCR	(3*32+ 3) /* Centaur MCRs (=3D MTRRs) */=0A-/* cpu types for =
specific tunings: */=0A-#define X86_FEATURE_K8		(3*32+ 4) /* =
Opteron, Athlon64 */=0A-#define X86_FEATURE_K7		(3*32+ 5) /* =
Athlon */=0A-#define X86_FEATURE_P3		(3*32+ 6) /* P3 */=0A-#defi=
ne X86_FEATURE_P4		(3*32+ 7) /* P4 */=0A #define X86_FEATURE_C=
ONSTANT_TSC (3*32+ 8) /* TSC ticks at a constant rate */=0A #define =
X86_FEATURE_NONSTOP_TSC	(3*32+ 9) /* TSC does not stop in C states */=0A =
#define X86_FEATURE_ARAT	(3*32+ 10) /* Always running APIC timer =
*/=0A
--=__Part74454D42.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

--=__Part74454D42.0__=--


From xen-devel-bounces@lists.xen.org Thu Sep 27 15:01:31 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Sep 2012 15:01:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1THFaa-0008LU-UY; Thu, 27 Sep 2012 15:01: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 1THFaZ-0008LL-DW
	for xen-devel@lists.xen.org; Thu, 27 Sep 2012 15:01:19 +0000
Received: from [85.158.137.99:31703] by server-3.bemta-3.messagelabs.com id
	E7/37-25962-E3A64605; Thu, 27 Sep 2012 15:01:18 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-2.tower-217.messagelabs.com!1348758076!19261882!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8329 invoked from network); 27 Sep 2012 15:01:16 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-2.tower-217.messagelabs.com with SMTP;
	27 Sep 2012 15:01:16 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 27 Sep 2012 16:01:16 +0100
Message-Id: <50648672020000780009E45F@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 27 Sep 2012 16:01:38 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part74454D42.0__="
Subject: [Xen-devel] [PATCH] x86: remove further code applicable to 32-bit
 CPUs 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>
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.

--=__Part74454D42.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

On the AMD side, anything prior to family 0xf can now be ignored, as
well as very low model numbers of family 6 on the Intel side.

Apart from that, there were several made up CPU features that turned
out entirely unused throughout the tree.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/arch/x86/cpu/amd.c
+++ b/xen/arch/x86/cpu/amd.c
@@ -180,7 +180,7 @@ static void __devinit set_cpuidmask(cons
 	if (c->x86 >=3D 0x10) {
 		wrmsr(MSR_K8_FEATURE_MASK, feat_edx, feat_ecx);
 		wrmsr(MSR_K8_EXT_FEATURE_MASK, extfeat_edx, extfeat_ecx);
-	} else if (c->x86 =3D=3D 0x0f) {
+	} else {
 		wrmsr_amd(MSR_K8_FEATURE_MASK, feat_edx, feat_ecx);
 		wrmsr_amd(MSR_K8_EXT_FEATURE_MASK, extfeat_edx, extfeat_ecx=
);
 	}
@@ -234,14 +234,7 @@ int cpu_has_amd_erratum(const struct cpu
 /* Can this system suffer from TSC drift due to C1 clock ramping? */
 static int c1_ramping_may_cause_clock_drift(struct cpuinfo_x86 *c)=20
 {=20
-	if (c->x86 < 0xf) {
-		/*
-		 * TSC drift doesn't exist on 7th Gen or less
-		 * However, OS still needs to consider effects
-		 * of P-state changes on TSC
-		 */
-		return 0;
-	} else if (cpuid_edx(0x80000007) & (1<<8)) {
+	if (cpuid_edx(0x80000007) & (1<<8)) {
 		/*
 		 * CPUID.AdvPowerMgmtInfo.TscInvariant
 		 * EDX bit 8, 8000_0007
@@ -416,41 +409,7 @@ static void __devinit init_amd(struct cp
=20
 	switch(c->x86)
 	{
-	case 6: /* An Athlon/Duron */
-=20
-		/* Bit 15 of Athlon specific MSR 15, needs to be 0
-		 * to enable SSE on Palomino/Morgan/Barton CPU's.
-		 * If the BIOS didn't enable it already, enable it here.
-		 */
-		if (c->x86_model >=3D 6 && c->x86_model <=3D 10) {
-			if (!cpu_has(c, X86_FEATURE_XMM)) {
-				printk(KERN_INFO "Enabling disabled K7/SSE =
Support.\n");
-				rdmsr(MSR_K7_HWCR, l, h);
-				l &=3D ~0x00008000;
-				wrmsr(MSR_K7_HWCR, l, h);
-				set_bit(X86_FEATURE_XMM, c->x86_capability)=
;
-			}
-		}
-
-		/* It's been determined by AMD that Athlons since model 8 =
stepping 1
-		 * are more robust with CLK_CTL set to 200xxxxx instead of =
600xxxxx
-		 * As per AMD technical note 27212 0.2
-		 */
-		if ((c->x86_model =3D=3D 8 && c->x86_mask>=3D1) || =
(c->x86_model > 8)) {
-			rdmsr(MSR_K7_CLK_CTL, l, h);
-			if ((l & 0xfff00000) !=3D 0x20000000) {
-				printk ("CPU: CLK_CTL MSR was %x. =
Reprogramming to %x\n", l,
-					((l & 0x000fffff)|0x20000000));
-				wrmsr(MSR_K7_CLK_CTL, (l & 0x000fffff)|0x20=
000000, h);
-			}
-		}
-		set_bit(X86_FEATURE_K7, c->x86_capability);
-		break;
-
-	case 0xf:
-	/* Use K8 tuning for Fam10h and Fam11h */
-	case 0x10 ... 0x17:
-		set_bit(X86_FEATURE_K8, c->x86_capability);
+	case 0xf ... 0x17:
 		disable_c1e(NULL);
 		if (acpi_smi_cmd && (acpi_enable_value | acpi_disable_value=
))
 			pv_post_outb_hook =3D check_disable_c1e;
--- a/xen/arch/x86/cpu/intel.c
+++ b/xen/arch/x86/cpu/intel.c
@@ -192,7 +192,6 @@ static int __devinit num_cpu_cores(struc
 static void __devinit init_intel(struct cpuinfo_x86 *c)
 {
 	unsigned int l2 =3D 0;
-	char *p =3D NULL;
=20
 	/* Detect the extended topology information if available */
 	detect_extended_topology(c);
@@ -210,37 +209,6 @@ static void __devinit init_intel(struct=20
 	if ((c->x86<<8 | c->x86_model<<4 | c->x86_mask) < 0x633)
 		clear_bit(X86_FEATURE_SEP, c->x86_capability);
=20
-	/* Names for the Pentium II/Celeron processors=20
-	   detectable only by also checking the cache size.
-	   Dixon is NOT a Celeron. */
-	if (c->x86 =3D=3D 6) {
-		switch (c->x86_model) {
-		case 5:
-			if (c->x86_mask =3D=3D 0) {
-				if (l2 =3D=3D 0)
-					p =3D "Celeron (Covington)";
-				else if (l2 =3D=3D 256)
-					p =3D "Mobile Pentium II (Dixon)";
-			}
-			break;
-		=09
-		case 6:
-			if (l2 =3D=3D 128)
-				p =3D "Celeron (Mendocino)";
-			else if (c->x86_mask =3D=3D 0 || c->x86_mask =
=3D=3D 5)
-				p =3D "Celeron-A";
-			break;
-		=09
-		case 8:
-			if (l2 =3D=3D 128)
-				p =3D "Celeron (Coppermine)";
-			break;
-		}
-	}
-
-	if ( p )
-		safe_strcpy(c->x86_model_id, p);
-
 	if ( !cpu_has(c, X86_FEATURE_XTOPOLOGY) )
 	{
 		c->x86_max_cores =3D num_cpu_cores(c);
@@ -275,10 +243,6 @@ static void __devinit init_intel(struct=20
 	}
 #endif
=20
-	if (c->x86 =3D=3D 15)
-		set_bit(X86_FEATURE_P4, c->x86_capability);
-	if (c->x86 =3D=3D 6)=20
-		set_bit(X86_FEATURE_P3, c->x86_capability);
 	if ((c->x86 =3D=3D 0xf && c->x86_model >=3D 0x03) ||
 		(c->x86 =3D=3D 0x6 && c->x86_model >=3D 0x0e))
 		set_bit(X86_FEATURE_CONSTANT_TSC, c->x86_capability);
--- a/xen/include/asm-x86/cpufeature.h
+++ b/xen/include/asm-x86/cpufeature.h
@@ -64,15 +64,6 @@
=20
 /* Other features, Linux-defined mapping, word 3 */
 /* This range is used for feature bits which conflict or are synthesized =
*/
-#define X86_FEATURE_CXMMX	(3*32+ 0) /* Cyrix MMX extensions */
-#define X86_FEATURE_K6_MTRR	(3*32+ 1) /* AMD K6 nonstandard MTRRs */
-#define X86_FEATURE_CYRIX_ARR	(3*32+ 2) /* Cyrix ARRs (=3D MTRRs) */
-#define X86_FEATURE_CENTAUR_MCR	(3*32+ 3) /* Centaur MCRs (=3D =
MTRRs) */
-/* cpu types for specific tunings: */
-#define X86_FEATURE_K8		(3*32+ 4) /* Opteron, Athlon64 */
-#define X86_FEATURE_K7		(3*32+ 5) /* Athlon */
-#define X86_FEATURE_P3		(3*32+ 6) /* P3 */
-#define X86_FEATURE_P4		(3*32+ 7) /* P4 */
 #define X86_FEATURE_CONSTANT_TSC (3*32+ 8) /* TSC ticks at a constant =
rate */
 #define X86_FEATURE_NONSTOP_TSC	(3*32+ 9) /* TSC does not stop in =
C states */
 #define X86_FEATURE_ARAT	(3*32+ 10) /* Always running APIC timer */



--=__Part74454D42.0__=
Content-Type: text/plain; name="x86-no-PIII.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="x86-no-PIII.patch"

x86: remove further code applicable to 32-bit CPUs only=0A=0AOn the AMD =
side, anything prior to family 0xf can now be ignored, as=0Awell as very =
low model numbers of family 6 on the Intel side.=0A=0AApart from that, =
there were several made up CPU features that turned=0Aout entirely unused =
throughout the tree.=0A=0ASigned-off-by: Jan Beulich <jbeulich@suse.com>=0A=
=0A--- a/xen/arch/x86/cpu/amd.c=0A+++ b/xen/arch/x86/cpu/amd.c=0A@@ -180,7 =
+180,7 @@ static void __devinit set_cpuidmask(cons=0A 	if (c->x86 >=3D =
0x10) {=0A 		wrmsr(MSR_K8_FEATURE_MASK, feat_edx, feat_ecx);=0A =
		wrmsr(MSR_K8_EXT_FEATURE_MASK, extfeat_edx, extfeat_ecx);=
=0A-	} else if (c->x86 =3D=3D 0x0f) {=0A+	} else {=0A 		=
wrmsr_amd(MSR_K8_FEATURE_MASK, feat_edx, feat_ecx);=0A 		wrmsr_amd(M=
SR_K8_EXT_FEATURE_MASK, extfeat_edx, extfeat_ecx);=0A 	}=0A@@ -234,14 =
+234,7 @@ int cpu_has_amd_erratum(const struct cpu=0A /* Can this system =
suffer from TSC drift due to C1 clock ramping? */=0A static int c1_ramping_=
may_cause_clock_drift(struct cpuinfo_x86 *c) =0A { =0A-	if (c->x86 < 0xf) =
{=0A-		/*=0A-		 * TSC drift doesn't exist on 7th Gen or =
less=0A-		 * However, OS still needs to consider effects=0A-	=
	 * of P-state changes on TSC=0A-		 */=0A-		=
return 0;=0A-	} else if (cpuid_edx(0x80000007) & (1<<8)) {=0A+	if =
(cpuid_edx(0x80000007) & (1<<8)) {=0A 		/*=0A 		 * =
CPUID.AdvPowerMgmtInfo.TscInvariant=0A 		 * EDX bit 8, 8000_0007=0A@=
@ -416,41 +409,7 @@ static void __devinit init_amd(struct cp=0A =0A 	=
switch(c->x86)=0A 	{=0A-	case 6: /* An Athlon/Duron */=0A- =0A-		=
/* Bit 15 of Athlon specific MSR 15, needs to be 0=0A-		 * to =
enable SSE on Palomino/Morgan/Barton CPU's.=0A-		 * If the BIOS =
didn't enable it already, enable it here.=0A-		 */=0A-		if =
(c->x86_model >=3D 6 && c->x86_model <=3D 10) {=0A-			if =
(!cpu_has(c, X86_FEATURE_XMM)) {=0A-				printk(KERN=
_INFO "Enabling disabled K7/SSE Support.\n");=0A-				=
rdmsr(MSR_K7_HWCR, l, h);=0A-				l &=3D ~0x00008000;=
=0A-				wrmsr(MSR_K7_HWCR, l, h);=0A-			=
	set_bit(X86_FEATURE_XMM, c->x86_capability);=0A-			=
}=0A-		}=0A-=0A-		/* It's been determined by AMD =
that Athlons since model 8 stepping 1=0A-		 * are more robust =
with CLK_CTL set to 200xxxxx instead of 600xxxxx=0A-		 * As per =
AMD technical note 27212 0.2=0A-		 */=0A-		if =
((c->x86_model =3D=3D 8 && c->x86_mask>=3D1) || (c->x86_model > 8)) {=0A-	=
		rdmsr(MSR_K7_CLK_CTL, l, h);=0A-			if =
((l & 0xfff00000) !=3D 0x20000000) {=0A-				=
printk ("CPU: CLK_CTL MSR was %x. Reprogramming to %x\n", l,=0A-		=
			((l & 0x000fffff)|0x20000000));=0A-			=
	wrmsr(MSR_K7_CLK_CTL, (l & 0x000fffff)|0x20000000, h);=0A-		=
	}=0A-		}=0A-		set_bit(X86_FEATURE_K7, c->x86_capa=
bility);=0A-		break;=0A-=0A-	case 0xf:=0A-	/* Use K8 tuning =
for Fam10h and Fam11h */=0A-	case 0x10 ... 0x17:=0A-		set_bit(X86=
_FEATURE_K8, c->x86_capability);=0A+	case 0xf ... 0x17:=0A 		=
disable_c1e(NULL);=0A 		if (acpi_smi_cmd && (acpi_enable_value | =
acpi_disable_value))=0A 			pv_post_outb_hook =3D =
check_disable_c1e;=0A--- a/xen/arch/x86/cpu/intel.c=0A+++ b/xen/arch/x86/cp=
u/intel.c=0A@@ -192,7 +192,6 @@ static int __devinit num_cpu_cores(struc=0A=
 static void __devinit init_intel(struct cpuinfo_x86 *c)=0A {=0A 	=
unsigned int l2 =3D 0;=0A-	char *p =3D NULL;=0A =0A 	/* Detect =
the extended topology information if available */=0A 	detect_extended_top=
ology(c);=0A@@ -210,37 +209,6 @@ static void __devinit init_intel(struct =
=0A 	if ((c->x86<<8 | c->x86_model<<4 | c->x86_mask) < 0x633)=0A 		=
clear_bit(X86_FEATURE_SEP, c->x86_capability);=0A =0A-	/* Names for the =
Pentium II/Celeron processors =0A-	   detectable only by also =
checking the cache size.=0A-	   Dixon is NOT a Celeron. */=0A-	if =
(c->x86 =3D=3D 6) {=0A-		switch (c->x86_model) {=0A-		=
case 5:=0A-			if (c->x86_mask =3D=3D 0) {=0A-			=
	if (l2 =3D=3D 0)=0A-					p =3D =
"Celeron (Covington)";=0A-				else if (l2 =3D=3D =
256)=0A-					p =3D "Mobile Pentium II =
(Dixon)";=0A-			}=0A-			break;=0A-		=
	=0A-		case 6:=0A-			if (l2 =3D=3D =
128)=0A-				p =3D "Celeron (Mendocino)";=0A-	=
		else if (c->x86_mask =3D=3D 0 || c->x86_mask =3D=3D 5)=0A-	=
			p =3D "Celeron-A";=0A-			break;=0A-	=
		=0A-		case 8:=0A-			if (l2 =
=3D=3D 128)=0A-				p =3D "Celeron (Coppermine)";=0A-	=
		break;=0A-		}=0A-	}=0A-=0A-	if ( p =
)=0A-		safe_strcpy(c->x86_model_id, p);=0A-=0A 	if ( =
!cpu_has(c, X86_FEATURE_XTOPOLOGY) )=0A 	{=0A 		c->x86_max_=
cores =3D num_cpu_cores(c);=0A@@ -275,10 +243,6 @@ static void __devinit =
init_intel(struct =0A 	}=0A #endif=0A =0A-	if (c->x86 =3D=3D 15)=0A-	=
	set_bit(X86_FEATURE_P4, c->x86_capability);=0A-	if (c->x86 =3D=3D =
6) =0A-		set_bit(X86_FEATURE_P3, c->x86_capability);=0A 	if =
((c->x86 =3D=3D 0xf && c->x86_model >=3D 0x03) ||=0A 		(c->x86 =
=3D=3D 0x6 && c->x86_model >=3D 0x0e))=0A 		set_bit(X86_FEATURE=
_CONSTANT_TSC, c->x86_capability);=0A--- a/xen/include/asm-x86/cpufeature.h=
=0A+++ b/xen/include/asm-x86/cpufeature.h=0A@@ -64,15 +64,6 @@=0A =0A /* =
Other features, Linux-defined mapping, word 3 */=0A /* This range is used =
for feature bits which conflict or are synthesized */=0A-#define X86_FEATUR=
E_CXMMX	(3*32+ 0) /* Cyrix MMX extensions */=0A-#define X86_FEATURE_K6_MTRR=
	(3*32+ 1) /* AMD K6 nonstandard MTRRs */=0A-#define X86_FEATURE_CYR=
IX_ARR	(3*32+ 2) /* Cyrix ARRs (=3D MTRRs) */=0A-#define X86_FEATURE_CENTA=
UR_MCR	(3*32+ 3) /* Centaur MCRs (=3D MTRRs) */=0A-/* cpu types for =
specific tunings: */=0A-#define X86_FEATURE_K8		(3*32+ 4) /* =
Opteron, Athlon64 */=0A-#define X86_FEATURE_K7		(3*32+ 5) /* =
Athlon */=0A-#define X86_FEATURE_P3		(3*32+ 6) /* P3 */=0A-#defi=
ne X86_FEATURE_P4		(3*32+ 7) /* P4 */=0A #define X86_FEATURE_C=
ONSTANT_TSC (3*32+ 8) /* TSC ticks at a constant rate */=0A #define =
X86_FEATURE_NONSTOP_TSC	(3*32+ 9) /* TSC does not stop in C states */=0A =
#define X86_FEATURE_ARAT	(3*32+ 10) /* Always running APIC timer =
*/=0A
--=__Part74454D42.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

--=__Part74454D42.0__=--


From xen-devel-bounces@lists.xen.org Thu Sep 27 15:02:07 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Sep 2012 15:02:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1THFbC-0008P0-CN; Thu, 27 Sep 2012 15:01:58 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1THFbB-0008Oo-7e
	for xen-devel@lists.xensource.com; Thu, 27 Sep 2012 15:01:57 +0000
Received: from [85.158.137.99:18037] by server-14.bemta-3.messagelabs.com id
	0B/A9-25886-46A64605; Thu, 27 Sep 2012 15:01:56 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-13.tower-217.messagelabs.com!1348758115!19402858!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24692 invoked from network); 27 Sep 2012 15:01:55 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-13.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 27 Sep 2012 15:01:55 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1THFb8-00039R-KC; Thu, 27 Sep 2012 15:01:54 +0000
Date: Thu, 27 Sep 2012 16:01:54 +0100
From: Tim Deegan <tim@xen.org>
To: Cutter 409 <cutter409@gmail.com>
Message-ID: <20120927150154.GH8831@ocelot.phlegethon.org>
References: <CAG4Ohu_KDy-bDR8Os71RXwQ6Q9QtRUZ3kSTirdpHBtZfqwaLrw@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAG4Ohu_KDy-bDR8Os71RXwQ6Q9QtRUZ3kSTirdpHBtZfqwaLrw@mail.gmail.com>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] SVM Trap Flag exiting?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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:37 -0400 on 25 Sep (1348573069), Cutter 409 wrote:
> I'm having a really hard time trying to accomplish something that seems
> generally simple. I want to single step some code in an SVM guest.
> 
> My current method essentially does the following:
> 
> From a domctl:
>    * Pause the target VCPU
>    * vmcb_set_exception_intercepts(vmcb,
> vmcb_get_exception_intercepts(vmcb) | (1U << TRAP_debug) );
>    * v->arch.guest_context.user_regs.rflags |= X86_EFLAGS_TF;
>    * I've also tried vmcb->rflags |= X86_EFLAGS_TF;
>    * Unpause the VCPU
> 
> But the VMEXIT_EXCEPTION_DB case doesn't ever seem to get called. Is there
> something I'm missing here?

Hard to tell without seeing your patch.  Did you see the code in
svm_do_resume that clears TRAP_debug from the intercept mask if it
doesn't think there's a debugger attached?

Have you considered using the existing debugger_attached mechanism
rather than adding your own?

Tim

> I've also tried setting both versions of rflags in svm_do_resume() but it
> doesn't make a difference.The guest doesn't crash either, so I'm assuming
> TF is just not getting set.
> 
> Any thoughts would be greatly appreciated.
> 
> Thanks!

> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Sep 27 15:02:07 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Sep 2012 15:02:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1THFbC-0008P0-CN; Thu, 27 Sep 2012 15:01:58 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1THFbB-0008Oo-7e
	for xen-devel@lists.xensource.com; Thu, 27 Sep 2012 15:01:57 +0000
Received: from [85.158.137.99:18037] by server-14.bemta-3.messagelabs.com id
	0B/A9-25886-46A64605; Thu, 27 Sep 2012 15:01:56 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-13.tower-217.messagelabs.com!1348758115!19402858!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24692 invoked from network); 27 Sep 2012 15:01:55 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-13.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 27 Sep 2012 15:01:55 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1THFb8-00039R-KC; Thu, 27 Sep 2012 15:01:54 +0000
Date: Thu, 27 Sep 2012 16:01:54 +0100
From: Tim Deegan <tim@xen.org>
To: Cutter 409 <cutter409@gmail.com>
Message-ID: <20120927150154.GH8831@ocelot.phlegethon.org>
References: <CAG4Ohu_KDy-bDR8Os71RXwQ6Q9QtRUZ3kSTirdpHBtZfqwaLrw@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAG4Ohu_KDy-bDR8Os71RXwQ6Q9QtRUZ3kSTirdpHBtZfqwaLrw@mail.gmail.com>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] SVM Trap Flag exiting?
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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:37 -0400 on 25 Sep (1348573069), Cutter 409 wrote:
> I'm having a really hard time trying to accomplish something that seems
> generally simple. I want to single step some code in an SVM guest.
> 
> My current method essentially does the following:
> 
> From a domctl:
>    * Pause the target VCPU
>    * vmcb_set_exception_intercepts(vmcb,
> vmcb_get_exception_intercepts(vmcb) | (1U << TRAP_debug) );
>    * v->arch.guest_context.user_regs.rflags |= X86_EFLAGS_TF;
>    * I've also tried vmcb->rflags |= X86_EFLAGS_TF;
>    * Unpause the VCPU
> 
> But the VMEXIT_EXCEPTION_DB case doesn't ever seem to get called. Is there
> something I'm missing here?

Hard to tell without seeing your patch.  Did you see the code in
svm_do_resume that clears TRAP_debug from the intercept mask if it
doesn't think there's a debugger attached?

Have you considered using the existing debugger_attached mechanism
rather than adding your own?

Tim

> I've also tried setting both versions of rflags in svm_do_resume() but it
> doesn't make a difference.The guest doesn't crash either, so I'm assuming
> TF is just not getting set.
> 
> Any thoughts would be greatly appreciated.
> 
> Thanks!

> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Sep 27 15:04:28 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Sep 2012 15:04:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1THFdS-0000ED-TX; Thu, 27 Sep 2012 15:04: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 1THFdR-0000E1-Am
	for xen-devel@lists.xen.org; Thu, 27 Sep 2012 15:04:17 +0000
Received: from [85.158.137.99:54470] by server-10.bemta-3.messagelabs.com id
	FE/3E-02525-0FA64605; Thu, 27 Sep 2012 15:04:16 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-13.tower-217.messagelabs.com!1348758255!19403337!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2707 invoked from network); 27 Sep 2012 15:04:15 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-13.tower-217.messagelabs.com with SMTP;
	27 Sep 2012 15:04:15 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 27 Sep 2012 16:04:14 +0100
Message-Id: <50648725020000780009E462@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 27 Sep 2012 16:04:37 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Andrew Cooper" <andrew.cooper3@citrix.com>
References: <506483CC020000780009E42C@nat28.tlf.novell.com>
	<5064695B.1010805@citrix.com>
In-Reply-To: <5064695B.1010805@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] x86/IRQ: fix valid-old-vector checks in
 __assign_irq_vector()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.09.12 at 16:57, Andrew Cooper <andrew.cooper3@citrix.com> wrote:

> On 27/09/12 15:50, Jan Beulich wrote:
>> There are two greater-than-zero checks for the old vector retrieved,
>> which don't work when a negative value got stashed into the respective
>> arch_irq_desc field. The effect of this was that for interrupts that
>> are intended to get their affinity adjusted the first time before the
>> first interrupt occurs, the affinity change would fail, because the
>> original vector assignment would have caused the move_in_progress flag
>> to get set (which causes subsequent re-assignments to fail until it
>> gets cleared, which only happens from the ->ack() actor, i.e. when an
>> interrupt actually occurred).
>>
>> This addresses a problem introduced in c/s 23816:7f357e1ef60a (by
>> changing IRQ_VECTOR_UNASSIGNED from 0 to -1).
>>
>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
>> ---
>> I have to admit that I don't understand why the value got changed in
>> the first place: 0 is as invalid a value as -1 for a vector to be used
>> for delivering hardware interrupts.
> 
> http://lists.xen.org/archives/html/xen-devel/2011-09/msg00193.html 
> 
> It was a suggestion for consistency with using -1 elsewhere in the irq
> code to mean unassigned.

Not really - there George suggested to use IRQ_VECTOR_UNASSIGNED,
but not to make that resolve to -1. My claim is that this manifest
constant could easily resolve to zero instead.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 27 15:04:28 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Sep 2012 15:04:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1THFdS-0000ED-TX; Thu, 27 Sep 2012 15:04: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 1THFdR-0000E1-Am
	for xen-devel@lists.xen.org; Thu, 27 Sep 2012 15:04:17 +0000
Received: from [85.158.137.99:54470] by server-10.bemta-3.messagelabs.com id
	FE/3E-02525-0FA64605; Thu, 27 Sep 2012 15:04:16 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-13.tower-217.messagelabs.com!1348758255!19403337!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2707 invoked from network); 27 Sep 2012 15:04:15 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-13.tower-217.messagelabs.com with SMTP;
	27 Sep 2012 15:04:15 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 27 Sep 2012 16:04:14 +0100
Message-Id: <50648725020000780009E462@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 27 Sep 2012 16:04:37 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Andrew Cooper" <andrew.cooper3@citrix.com>
References: <506483CC020000780009E42C@nat28.tlf.novell.com>
	<5064695B.1010805@citrix.com>
In-Reply-To: <5064695B.1010805@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH] x86/IRQ: fix valid-old-vector checks in
 __assign_irq_vector()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.09.12 at 16:57, Andrew Cooper <andrew.cooper3@citrix.com> wrote:

> On 27/09/12 15:50, Jan Beulich wrote:
>> There are two greater-than-zero checks for the old vector retrieved,
>> which don't work when a negative value got stashed into the respective
>> arch_irq_desc field. The effect of this was that for interrupts that
>> are intended to get their affinity adjusted the first time before the
>> first interrupt occurs, the affinity change would fail, because the
>> original vector assignment would have caused the move_in_progress flag
>> to get set (which causes subsequent re-assignments to fail until it
>> gets cleared, which only happens from the ->ack() actor, i.e. when an
>> interrupt actually occurred).
>>
>> This addresses a problem introduced in c/s 23816:7f357e1ef60a (by
>> changing IRQ_VECTOR_UNASSIGNED from 0 to -1).
>>
>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
>> ---
>> I have to admit that I don't understand why the value got changed in
>> the first place: 0 is as invalid a value as -1 for a vector to be used
>> for delivering hardware interrupts.
> 
> http://lists.xen.org/archives/html/xen-devel/2011-09/msg00193.html 
> 
> It was a suggestion for consistency with using -1 elsewhere in the irq
> code to mean unassigned.

Not really - there George suggested to use IRQ_VECTOR_UNASSIGNED,
but not to make that resolve to -1. My claim is that this manifest
constant could easily resolve to zero instead.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 27 15:25:09 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Sep 2012 15:25:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1THFxL-0000W4-TG; Thu, 27 Sep 2012 15:24:51 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <george.shuklin@gmail.com>) id 1THFxK-0000Vz-TP
	for xen-devel@lists.xen.org; Thu, 27 Sep 2012 15:24:51 +0000
Received: from [85.158.143.99:6039] by server-2.bemta-4.messagelabs.com id
	22/D3-06610-2CF64605; Thu, 27 Sep 2012 15:24:50 +0000
X-Env-Sender: george.shuklin@gmail.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1348759489!20784276!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-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6894 invoked from network); 27 Sep 2012 15:24:49 -0000
Received: from mail-bk0-f45.google.com (HELO mail-bk0-f45.google.com)
	(209.85.214.45)
	by server-16.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Sep 2012 15:24:49 -0000
Received: by bkcjf3 with SMTP id jf3so1583496bkc.32
	for <xen-devel@lists.xen.org>; Thu, 27 Sep 2012 08:24:49 -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=BSi1kEKgOKr4JEP/5264PwMShBYD5YIjVac45J+DyV0=;
	b=KGnd8QQisigGkmDs31+H/C+ewc7gAzbuGYTq76Nn1D4rBzHk3HPpp5BXF6x94Srkkk
	tD+igqjJMp1af39GzJUi3DzdAGILRCiRY7Kx2+rWv+fT8qiiplcGWDR5kQ+DigtcPL9X
	ugo7BP9Q9MtKtnKFVlTgjv3U3G1QSXqJiH34svce5LBMCQbuqDdkHwtBfTy88XD+/gIi
	kVzXQutUQ2fe94Tx4jqlHeRDUI9QoRtHPVawH5itaCi3b7mbEWQG4X3oFW3PLxrbq9Pj
	Sjua6XjVZ/YCrUBXBJYPdhSzETDexOp8iJaOKRJY1MqGTLyJ5cT87imtjh8zZHO/fQPj
	bizw==
Received: by 10.152.122.9 with SMTP id lo9mr3549777lab.41.1348759488666;
	Thu, 27 Sep 2012 08:24:48 -0700 (PDT)
Received: from [192.168.40.104] (officecvt.selectel.ru. [188.93.16.50])
	by mx.google.com with ESMTPS id ey2sm1831179lbb.12.2012.09.27.08.24.47
	(version=SSLv3 cipher=OTHER); Thu, 27 Sep 2012 08:24:48 -0700 (PDT)
Message-ID: <50646FBF.9000501@gmail.com>
Date: Thu, 27 Sep 2012 19:24:47 +0400
From: George Shuklin <george.shuklin@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:15.0) Gecko/20120911 Thunderbird/15.0.1
MIME-Version: 1.0
To: xen-devel@lists.xen.org
References: <53b8c758-2675-42a7-b63f-4f9ad0006d84@default>
In-Reply-To: <53b8c758-2675-42a7-b63f-4f9ad0006d84@default>
Subject: Re: [Xen-devel] domain creation vs querying free memory (xend and
 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-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

bm90IHN1cmUgYWJvdXQgeGwveG0sIGJ1dCB4YXBpIHBlcmZvcm1zIG9uZSBzdGFydCBhdCB0aW1l
LCBzbyB0aGVyZSBpcyAKbm8gcmFjZSBiZXR3ZWVuIGRvbWFpbnMgZm9yIG1lbW9yeSBvciBvdGhl
ciByZXNvdXJjZXMuCgoyNy4wOS4yMDEyIDAxOjE3LCBEYW4gTWFnZW5oZWltZXIg0L/QuNGI0LXR
gjoKPiBJIHdhcyBhc2tlZCBhIHF1ZXN0aW9uIHRoYXQgc2VlbXMgbGlrZSBpdCBzaG91bGQgYmUg
b2J2aW91cwo+IGJ1dCBpdCBkb2Vzbid0IHNlZW0gdG8gYmUsIGF0IGxlYXN0IGluIHhtLWxhbmQu
ICBJJ2xsIGxvb2sKPiBpbnRvIGl0IGZ1cnRoZXIsIGFzIHdlbGwgYXMgZm9yIHhsLCBidXQgSSB0
aG91Z2h0IEknZCBhc2sKPiBmaXJzdCB0byBzZWUgaWYgdGhlcmUgaXMgYSBrbm93biBhbnN3ZXIg
b3IgaWYgdGhpcyBpcyBhIGtub3duCj4gcHJvYmxlbToKPgo+IFN1cHBvc2UgdGhhdCB4bS94bCBj
cmVhdGUgaXMgaXNzdWVkIG9uIGEgbGFyZ2UtbWVtb3J5Cj4gZG9tYWluIChQViBvciBIVk0gb3Is
IGZ1dHVyZSwgUFZIKS4gIEl0IHRha2VzIGF3aGlsZQo+IGZvciB0aGlzIGRvbWFpbiB0byBsYXVu
Y2ggYW5kIGR1cmluZyBhdCBsZWFzdCBwYXJ0IG9mIHRoaXMKPiB0aW1lLCB0aGUgdG9vbHNldCBo
YXNuJ3QgeWV0IHJlcXVlc3RlZCBhbGwgb2YgdGhlCj4gcmVxdWlyZWQgbWVtb3J5IGZyb20gdGhl
IGh5cGVydmlzb3IgdG8gY29tcGxldGUgdGhlCj4gbGF1bmNoIG9mIHRoZSBkb21haW4uLi4gIG9y
IHBlcmhhcHMgdGhlIHRvb2xzZXQgaGFzLAo+IGJ1dCB0aGUgaHlwZXJ2aXNvciBpcyBzbG93IGFi
b3V0IGNhbGxpbmcgdGhlIGxvbmcgc2VxdWVuY2UKPiBvZiBwYWdlIGFsbG9jYXRpb25zIChlLmcu
IG1heWJlIGJlY2F1c2UgaXQgaXMgemVyb2luZwo+IGVhY2ggcGFnZT8pLgo+Cj4gVGhlbiBpdCBp
cyBkZXNpcmVkIHRvIGxhdW5jaCBhIHNlY29uZCBsYXJnZS1tZW1vcnkgZG9tYWluLgo+IFRoZSB0
b29scyBjYW4gcXVlcnkgWGVuIHRvIHNlZSBpZiB0aGVyZSBpcyBzdWZmaWNpZW50IFJBTQo+IGFu
ZCB0aGVyZSBpcywgYmVjYXVzZSB0aGUgZmlyc3QgbGF1bmNoIGhhcyBub3QgeWV0Cj4gYWxsb2Nh
dGVkIGFsbCB0aGUgUkFNIGFzc2lnbmVkIHRvIGl0Lgo+Cj4gQnV0IHRoZSBzZWNvbmQgZG9tYWlu
IGxhdW5jaCBmYWlscywgcG9zc2libHkgYWZ0ZXIKPiBzZXZlcmFsIG1pbnV0ZXMgYmVjYXVzZSwg
YWN0dWFsbHksIHRoZXJlIGlzbid0IGVub3VnaAo+IHBoeXNpY2FsIFJBTSBmb3IgYm90aC4KPgo+
IERvZXMgdGhpcyBtYWtlIHNlbnNlPyAgU2hvdWxkIHRoZSB0b29scyAicmVzZXJ2ZSIKPiBtYXht
ZW0gYXMgYSAidHJhbnNhY3Rpb24iIGFuZC9vciBlbnN1cmUgdGhhdCAieG0veGwKPiBmcmVlIiBj
YWxscyBhY2NvdW50IGZvciB0aGUgZW50aXJlIHJlcXVlc3RlZCBhbW91bnQKPiBvZiBSQU0/ICBP
ciBtYXliZSB4bCBfZG9lc18gd29yayB0aGlzIHdheT8KPgo+IFRoYW5rcyBmb3IgYW55IGNvbW1l
bnRzIG9yIGRpc2N1c3Npb24hCj4KPiBEYW4KPgo+IF9fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fCj4gWGVuLWRldmVsIG1haWxpbmcgbGlzdAo+IFhlbi1kZXZl
bEBsaXN0cy54ZW4ub3JnCj4gaHR0cDovL2xpc3RzLnhlbi5vcmcveGVuLWRldmVsCgoKX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxp
bmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwOi8vbGlzdHMueGVuLm9yZy94ZW4t
ZGV2ZWwK

From xen-devel-bounces@lists.xen.org Thu Sep 27 15:25:09 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Sep 2012 15:25:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1THFxL-0000W4-TG; Thu, 27 Sep 2012 15:24:51 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <george.shuklin@gmail.com>) id 1THFxK-0000Vz-TP
	for xen-devel@lists.xen.org; Thu, 27 Sep 2012 15:24:51 +0000
Received: from [85.158.143.99:6039] by server-2.bemta-4.messagelabs.com id
	22/D3-06610-2CF64605; Thu, 27 Sep 2012 15:24:50 +0000
X-Env-Sender: george.shuklin@gmail.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1348759489!20784276!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-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6894 invoked from network); 27 Sep 2012 15:24:49 -0000
Received: from mail-bk0-f45.google.com (HELO mail-bk0-f45.google.com)
	(209.85.214.45)
	by server-16.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Sep 2012 15:24:49 -0000
Received: by bkcjf3 with SMTP id jf3so1583496bkc.32
	for <xen-devel@lists.xen.org>; Thu, 27 Sep 2012 08:24:49 -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=BSi1kEKgOKr4JEP/5264PwMShBYD5YIjVac45J+DyV0=;
	b=KGnd8QQisigGkmDs31+H/C+ewc7gAzbuGYTq76Nn1D4rBzHk3HPpp5BXF6x94Srkkk
	tD+igqjJMp1af39GzJUi3DzdAGILRCiRY7Kx2+rWv+fT8qiiplcGWDR5kQ+DigtcPL9X
	ugo7BP9Q9MtKtnKFVlTgjv3U3G1QSXqJiH34svce5LBMCQbuqDdkHwtBfTy88XD+/gIi
	kVzXQutUQ2fe94Tx4jqlHeRDUI9QoRtHPVawH5itaCi3b7mbEWQG4X3oFW3PLxrbq9Pj
	Sjua6XjVZ/YCrUBXBJYPdhSzETDexOp8iJaOKRJY1MqGTLyJ5cT87imtjh8zZHO/fQPj
	bizw==
Received: by 10.152.122.9 with SMTP id lo9mr3549777lab.41.1348759488666;
	Thu, 27 Sep 2012 08:24:48 -0700 (PDT)
Received: from [192.168.40.104] (officecvt.selectel.ru. [188.93.16.50])
	by mx.google.com with ESMTPS id ey2sm1831179lbb.12.2012.09.27.08.24.47
	(version=SSLv3 cipher=OTHER); Thu, 27 Sep 2012 08:24:48 -0700 (PDT)
Message-ID: <50646FBF.9000501@gmail.com>
Date: Thu, 27 Sep 2012 19:24:47 +0400
From: George Shuklin <george.shuklin@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:15.0) Gecko/20120911 Thunderbird/15.0.1
MIME-Version: 1.0
To: xen-devel@lists.xen.org
References: <53b8c758-2675-42a7-b63f-4f9ad0006d84@default>
In-Reply-To: <53b8c758-2675-42a7-b63f-4f9ad0006d84@default>
Subject: Re: [Xen-devel] domain creation vs querying free memory (xend and
 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-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

bm90IHN1cmUgYWJvdXQgeGwveG0sIGJ1dCB4YXBpIHBlcmZvcm1zIG9uZSBzdGFydCBhdCB0aW1l
LCBzbyB0aGVyZSBpcyAKbm8gcmFjZSBiZXR3ZWVuIGRvbWFpbnMgZm9yIG1lbW9yeSBvciBvdGhl
ciByZXNvdXJjZXMuCgoyNy4wOS4yMDEyIDAxOjE3LCBEYW4gTWFnZW5oZWltZXIg0L/QuNGI0LXR
gjoKPiBJIHdhcyBhc2tlZCBhIHF1ZXN0aW9uIHRoYXQgc2VlbXMgbGlrZSBpdCBzaG91bGQgYmUg
b2J2aW91cwo+IGJ1dCBpdCBkb2Vzbid0IHNlZW0gdG8gYmUsIGF0IGxlYXN0IGluIHhtLWxhbmQu
ICBJJ2xsIGxvb2sKPiBpbnRvIGl0IGZ1cnRoZXIsIGFzIHdlbGwgYXMgZm9yIHhsLCBidXQgSSB0
aG91Z2h0IEknZCBhc2sKPiBmaXJzdCB0byBzZWUgaWYgdGhlcmUgaXMgYSBrbm93biBhbnN3ZXIg
b3IgaWYgdGhpcyBpcyBhIGtub3duCj4gcHJvYmxlbToKPgo+IFN1cHBvc2UgdGhhdCB4bS94bCBj
cmVhdGUgaXMgaXNzdWVkIG9uIGEgbGFyZ2UtbWVtb3J5Cj4gZG9tYWluIChQViBvciBIVk0gb3Is
IGZ1dHVyZSwgUFZIKS4gIEl0IHRha2VzIGF3aGlsZQo+IGZvciB0aGlzIGRvbWFpbiB0byBsYXVu
Y2ggYW5kIGR1cmluZyBhdCBsZWFzdCBwYXJ0IG9mIHRoaXMKPiB0aW1lLCB0aGUgdG9vbHNldCBo
YXNuJ3QgeWV0IHJlcXVlc3RlZCBhbGwgb2YgdGhlCj4gcmVxdWlyZWQgbWVtb3J5IGZyb20gdGhl
IGh5cGVydmlzb3IgdG8gY29tcGxldGUgdGhlCj4gbGF1bmNoIG9mIHRoZSBkb21haW4uLi4gIG9y
IHBlcmhhcHMgdGhlIHRvb2xzZXQgaGFzLAo+IGJ1dCB0aGUgaHlwZXJ2aXNvciBpcyBzbG93IGFi
b3V0IGNhbGxpbmcgdGhlIGxvbmcgc2VxdWVuY2UKPiBvZiBwYWdlIGFsbG9jYXRpb25zIChlLmcu
IG1heWJlIGJlY2F1c2UgaXQgaXMgemVyb2luZwo+IGVhY2ggcGFnZT8pLgo+Cj4gVGhlbiBpdCBp
cyBkZXNpcmVkIHRvIGxhdW5jaCBhIHNlY29uZCBsYXJnZS1tZW1vcnkgZG9tYWluLgo+IFRoZSB0
b29scyBjYW4gcXVlcnkgWGVuIHRvIHNlZSBpZiB0aGVyZSBpcyBzdWZmaWNpZW50IFJBTQo+IGFu
ZCB0aGVyZSBpcywgYmVjYXVzZSB0aGUgZmlyc3QgbGF1bmNoIGhhcyBub3QgeWV0Cj4gYWxsb2Nh
dGVkIGFsbCB0aGUgUkFNIGFzc2lnbmVkIHRvIGl0Lgo+Cj4gQnV0IHRoZSBzZWNvbmQgZG9tYWlu
IGxhdW5jaCBmYWlscywgcG9zc2libHkgYWZ0ZXIKPiBzZXZlcmFsIG1pbnV0ZXMgYmVjYXVzZSwg
YWN0dWFsbHksIHRoZXJlIGlzbid0IGVub3VnaAo+IHBoeXNpY2FsIFJBTSBmb3IgYm90aC4KPgo+
IERvZXMgdGhpcyBtYWtlIHNlbnNlPyAgU2hvdWxkIHRoZSB0b29scyAicmVzZXJ2ZSIKPiBtYXht
ZW0gYXMgYSAidHJhbnNhY3Rpb24iIGFuZC9vciBlbnN1cmUgdGhhdCAieG0veGwKPiBmcmVlIiBj
YWxscyBhY2NvdW50IGZvciB0aGUgZW50aXJlIHJlcXVlc3RlZCBhbW91bnQKPiBvZiBSQU0/ICBP
ciBtYXliZSB4bCBfZG9lc18gd29yayB0aGlzIHdheT8KPgo+IFRoYW5rcyBmb3IgYW55IGNvbW1l
bnRzIG9yIGRpc2N1c3Npb24hCj4KPiBEYW4KPgo+IF9fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fCj4gWGVuLWRldmVsIG1haWxpbmcgbGlzdAo+IFhlbi1kZXZl
bEBsaXN0cy54ZW4ub3JnCj4gaHR0cDovL2xpc3RzLnhlbi5vcmcveGVuLWRldmVsCgoKX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxp
bmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwOi8vbGlzdHMueGVuLm9yZy94ZW4t
ZGV2ZWwK

From xen-devel-bounces@lists.xen.org Thu Sep 27 15:25:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Sep 2012 15:25:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1THFy1-0000YY-CC; Thu, 27 Sep 2012 15:25:33 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1THFxz-0000YO-Gh
	for xen-devel@lists.xen.org; Thu, 27 Sep 2012 15:25:31 +0000
Received: from [85.158.139.211:53587] by server-2.bemta-5.messagelabs.com id
	0F/C0-28944-9EF64605; Thu, 27 Sep 2012 15:25:29 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-3.tower-206.messagelabs.com!1348759529!20195131!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32093 invoked from network); 27 Sep 2012 15:25:29 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-3.tower-206.messagelabs.com with SMTP;
	27 Sep 2012 15:25:29 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 27 Sep 2012 16:25:28 +0100
Message-Id: <50648C21020000780009E478@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 27 Sep 2012 16:25:53 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ben Guthro" <ben@guthro.net>
References: <CAOvdn6UCF2A3yP1cqWn=dxwr0ayRbr+rg+xj8META9Dm0+CoNw@mail.gmail.com>
	<CC868168.3FD29%keir.xen@gmail.com>
	<CAOvdn6U-JyLvt96gkLkqzi088tU9_ktv4D+fkJac_BKVe05Y-w@mail.gmail.com>
	<CAOvdn6V+s3AbRzsu8VArbmrZou=im9SqvPf-9Wpif_BrNMv=yg@mail.gmail.com>
	<50617297020000780009D8AA@nat28.tlf.novell.com>
	<CAOvdn6Vsnbcd7m8mh3tSgn3KaEoeiOyVD1mr3uQ3bN=rF=pDUQ@mail.gmail.com>
	<5062F880020000780009DF3B@nat28.tlf.novell.com>
	<CAOvdn6VyAVg24=c1OxqttxuGFyN_NzpfZ7RoCYc2mVF84c5big@mail.gmail.com>
	<50641E86020000780009E2E3@nat28.tlf.novell.com>
	<CAOvdn6VE13fOSjrKU4Ryr=344u+YwygASj6z1ag_U-x-qvOC9g@mail.gmail.com>
In-Reply-To: <CAOvdn6VE13fOSjrKU4Ryr=344u+YwygASj6z1ag_U-x-qvOC9g@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Keir Fraser <keir.xen@gmail.com>, John Baboval <john.baboval@citrix.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen4.2 S3 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 27.09.12 at 14:12, Ben Guthro <ben@guthro.net> wrote:
> On Thu, Sep 27, 2012 at 3:38 AM, Jan Beulich <JBeulich@suse.com> wrote:
>> > (XEN) microcode: collect_cpu_info for CPU0
>> > (XEN) microcode: collect_cpu_info : sig=0x10676, pf=0x80, rev=0x60c
>> > (XEN) microcode: collect_cpu_info for CPU1
>> > (XEN) microcode: collect_cpu_info : sig=0x10676, pf=0x80, rev=0x60f
>>
>> And in the end we see that both cores run on different revisions.
>>
>>
> very interesting. I had overlooked that.

Could you give the below patch a try?

Jan

x86/ucode: fix Intel case of resume handling on boot CPU

Checking the stored version doesn't tell us anything about the need to
apply the update (during resume, what is stored doesn't necessarily
match what is loaded).

Note that the check can be removed altogether because once switched to
use what was read from the CPU (uci->cpu_sig.rev, as used in the
subsequent pr_debug()), it would become redundant with the checks that
lead to microcode_update_match() returning the indication that an
update should be applied.

Note further that this was not an issue on APs since they start with
uci->mc.mc_intel being NULL.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/arch/x86/microcode_intel.c
+++ b/xen/arch/x86/microcode_intel.c
@@ -261,8 +261,6 @@ static int get_matching_microcode(const 
     }
     return 0;
  find:
-    if ( uci->mc.mc_intel && uci->mc.mc_intel->hdr.rev >= mc_header->rev )
-        return 0;
     pr_debug("microcode: CPU%d found a matching microcode update with"
              " version %#x (current=%#x)\n",
              cpu, mc_header->rev, uci->cpu_sig.rev);




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 27 15:25:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Sep 2012 15:25:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1THFy1-0000YY-CC; Thu, 27 Sep 2012 15:25:33 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1THFxz-0000YO-Gh
	for xen-devel@lists.xen.org; Thu, 27 Sep 2012 15:25:31 +0000
Received: from [85.158.139.211:53587] by server-2.bemta-5.messagelabs.com id
	0F/C0-28944-9EF64605; Thu, 27 Sep 2012 15:25:29 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-3.tower-206.messagelabs.com!1348759529!20195131!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32093 invoked from network); 27 Sep 2012 15:25:29 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-3.tower-206.messagelabs.com with SMTP;
	27 Sep 2012 15:25:29 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 27 Sep 2012 16:25:28 +0100
Message-Id: <50648C21020000780009E478@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 27 Sep 2012 16:25:53 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ben Guthro" <ben@guthro.net>
References: <CAOvdn6UCF2A3yP1cqWn=dxwr0ayRbr+rg+xj8META9Dm0+CoNw@mail.gmail.com>
	<CC868168.3FD29%keir.xen@gmail.com>
	<CAOvdn6U-JyLvt96gkLkqzi088tU9_ktv4D+fkJac_BKVe05Y-w@mail.gmail.com>
	<CAOvdn6V+s3AbRzsu8VArbmrZou=im9SqvPf-9Wpif_BrNMv=yg@mail.gmail.com>
	<50617297020000780009D8AA@nat28.tlf.novell.com>
	<CAOvdn6Vsnbcd7m8mh3tSgn3KaEoeiOyVD1mr3uQ3bN=rF=pDUQ@mail.gmail.com>
	<5062F880020000780009DF3B@nat28.tlf.novell.com>
	<CAOvdn6VyAVg24=c1OxqttxuGFyN_NzpfZ7RoCYc2mVF84c5big@mail.gmail.com>
	<50641E86020000780009E2E3@nat28.tlf.novell.com>
	<CAOvdn6VE13fOSjrKU4Ryr=344u+YwygASj6z1ag_U-x-qvOC9g@mail.gmail.com>
In-Reply-To: <CAOvdn6VE13fOSjrKU4Ryr=344u+YwygASj6z1ag_U-x-qvOC9g@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Keir Fraser <keir.xen@gmail.com>, John Baboval <john.baboval@citrix.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen4.2 S3 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 27.09.12 at 14:12, Ben Guthro <ben@guthro.net> wrote:
> On Thu, Sep 27, 2012 at 3:38 AM, Jan Beulich <JBeulich@suse.com> wrote:
>> > (XEN) microcode: collect_cpu_info for CPU0
>> > (XEN) microcode: collect_cpu_info : sig=0x10676, pf=0x80, rev=0x60c
>> > (XEN) microcode: collect_cpu_info for CPU1
>> > (XEN) microcode: collect_cpu_info : sig=0x10676, pf=0x80, rev=0x60f
>>
>> And in the end we see that both cores run on different revisions.
>>
>>
> very interesting. I had overlooked that.

Could you give the below patch a try?

Jan

x86/ucode: fix Intel case of resume handling on boot CPU

Checking the stored version doesn't tell us anything about the need to
apply the update (during resume, what is stored doesn't necessarily
match what is loaded).

Note that the check can be removed altogether because once switched to
use what was read from the CPU (uci->cpu_sig.rev, as used in the
subsequent pr_debug()), it would become redundant with the checks that
lead to microcode_update_match() returning the indication that an
update should be applied.

Note further that this was not an issue on APs since they start with
uci->mc.mc_intel being NULL.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/arch/x86/microcode_intel.c
+++ b/xen/arch/x86/microcode_intel.c
@@ -261,8 +261,6 @@ static int get_matching_microcode(const 
     }
     return 0;
  find:
-    if ( uci->mc.mc_intel && uci->mc.mc_intel->hdr.rev >= mc_header->rev )
-        return 0;
     pr_debug("microcode: CPU%d found a matching microcode update with"
              " version %#x (current=%#x)\n",
              cpu, mc_header->rev, uci->cpu_sig.rev);




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 27 15:28:36 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Sep 2012 15:28: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 1THG0k-0000im-Ux; Thu, 27 Sep 2012 15:28:22 +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 1THG0j-0000if-EG
	for xen-devel@lists.xen.org; Thu, 27 Sep 2012 15:28:21 +0000
Received: from [85.158.139.83:32054] by server-12.bemta-5.messagelabs.com id
	9C/AC-20729-49074605; Thu, 27 Sep 2012 15:28:20 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1348759700!30218884!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-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10553 invoked from network); 27 Sep 2012 15:28:20 -0000
Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com)
	(74.125.83.45)
	by server-15.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Sep 2012 15:28:20 -0000
Received: by eekb47 with SMTP id b47so1065171eek.32
	for <xen-devel@lists.xen.org>; Thu, 27 Sep 2012 08:28:20 -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=DfWt6mAzi65E+bUPv9oMXmD7+I7J1skumanBlxcn62U=;
	b=J6QNyJirCaue4cFqfw/u8qbgCSzW3zTB4U3AOKyo9cQLGVrcoasCdXR40MGSwHaUTh
	OckzoWrTXrYMWbOcb58bHt5zr13RVkeXx0t4tJNdwSrYd9y4nK5J/otN8l69ODgKoWMB
	VlgvUUUgg5H77SktpChIR2Kfj3zo2yIuvbmGJ683coLPP167kSe/822JlM6+cQEag7nJ
	DazHIKLijnu0nLkXez+of1emjNLyCde9KVdBapduQ6Nj+gxCVIlBoFZbD6zn8hUsmrsU
	vevAEQyL3VtRdHfzc+67YlBfnzlKHIumB4SC+V7txqXjwfYNHaFPc49K0BOlPusATpEc
	0LaA==
Received: by 10.14.178.1 with SMTP id e1mr5932971eem.38.1348759700031;
	Thu, 27 Sep 2012 08:28:20 -0700 (PDT)
Received: from [192.168.1.69]
	(host86-160-224-180.range86-160.btcentralplus.com. [86.160.224.180])
	by mx.google.com with ESMTPS id k49sm18522116een.4.2012.09.27.08.28.17
	(version=SSLv3 cipher=OTHER); Thu, 27 Sep 2012 08:28:19 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Thu, 27 Sep 2012 16:28:15 +0100
From: Keir Fraser <keir.xen@gmail.com>
To: Jan Beulich <JBeulich@suse.com>,
	xen-devel <xen-devel@lists.xen.org>
Message-ID: <CC8A2F1F.400C1%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [PATCH] x86/HPET: don't disable interrupt delivery
	right after setting it up
Thread-Index: Ac2cxLZSpM/wnNz3cEaYf94pRCbhYg==
In-Reply-To: <50648161020000780009E418@nat28.tlf.novell.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] [PATCH] x86/HPET: don't disable interrupt delivery
 right after setting it up
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 27/09/2012 15:40, "Jan Beulich" <JBeulich@suse.com> wrote:

> We shouldn't clear HPET_TN_FSB right after we (indirectly, via
> request_irq()) enabled it for the channels we intend to use for
> broadcasts.
> 
> This fixes a regression introduced by c/s 25103:0b0e42dc4f0a.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Acked-by: Keir Fraser <keir@xen.org>

> ---
> This fixes the MWAIT idle driver problem on the box that I was able to
> (artificially) reproduce it with. Hence I subsequently intend to revert
> 25960:6bf8b882df8f, but I'm not intending to do this before getting a
> push there.
> 
> I'm surprised that this didn't hit anyone so far with the ACPI-based
> idle driver...
> 
> --- 2012-09-21.orig/xen/arch/x86/hpet.c 2012-09-27 16:10:35.000000000 +0200
> +++ 2012-09-21/xen/arch/x86/hpet.c 2012-09-27 16:10:07.000000000 +0200
> @@ -533,7 +533,7 @@ void __init hpet_broadcast_init(void)
>      {
>          /* set HPET Tn as oneshot */
>          cfg = hpet_read32(HPET_Tn_CFG(hpet_events[i].idx));
> -        cfg &= ~(HPET_TN_LEVEL | HPET_TN_PERIODIC | HPET_TN_FSB);
> +        cfg &= ~(HPET_TN_LEVEL | HPET_TN_PERIODIC);
>          cfg |= HPET_TN_ENABLE | HPET_TN_32BIT;
>          hpet_write32(cfg, HPET_Tn_CFG(hpet_events[i].idx));
>  
> @@ -590,7 +590,7 @@ void hpet_broadcast_resume(void)
>  
>          /* set HPET Tn as oneshot */
>          cfg = hpet_read32(HPET_Tn_CFG(hpet_events[i].idx));
> -        cfg &= ~(HPET_TN_LEVEL | HPET_TN_PERIODIC | HPET_TN_FSB);
> +        cfg &= ~(HPET_TN_LEVEL | HPET_TN_PERIODIC);
>          cfg |= HPET_TN_ENABLE | HPET_TN_32BIT;
>          hpet_write32(cfg, HPET_Tn_CFG(hpet_events[i].idx));
>  
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Sep 27 15:28:36 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Sep 2012 15:28: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 1THG0k-0000im-Ux; Thu, 27 Sep 2012 15:28:22 +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 1THG0j-0000if-EG
	for xen-devel@lists.xen.org; Thu, 27 Sep 2012 15:28:21 +0000
Received: from [85.158.139.83:32054] by server-12.bemta-5.messagelabs.com id
	9C/AC-20729-49074605; Thu, 27 Sep 2012 15:28:20 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1348759700!30218884!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-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10553 invoked from network); 27 Sep 2012 15:28:20 -0000
Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com)
	(74.125.83.45)
	by server-15.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Sep 2012 15:28:20 -0000
Received: by eekb47 with SMTP id b47so1065171eek.32
	for <xen-devel@lists.xen.org>; Thu, 27 Sep 2012 08:28:20 -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=DfWt6mAzi65E+bUPv9oMXmD7+I7J1skumanBlxcn62U=;
	b=J6QNyJirCaue4cFqfw/u8qbgCSzW3zTB4U3AOKyo9cQLGVrcoasCdXR40MGSwHaUTh
	OckzoWrTXrYMWbOcb58bHt5zr13RVkeXx0t4tJNdwSrYd9y4nK5J/otN8l69ODgKoWMB
	VlgvUUUgg5H77SktpChIR2Kfj3zo2yIuvbmGJ683coLPP167kSe/822JlM6+cQEag7nJ
	DazHIKLijnu0nLkXez+of1emjNLyCde9KVdBapduQ6Nj+gxCVIlBoFZbD6zn8hUsmrsU
	vevAEQyL3VtRdHfzc+67YlBfnzlKHIumB4SC+V7txqXjwfYNHaFPc49K0BOlPusATpEc
	0LaA==
Received: by 10.14.178.1 with SMTP id e1mr5932971eem.38.1348759700031;
	Thu, 27 Sep 2012 08:28:20 -0700 (PDT)
Received: from [192.168.1.69]
	(host86-160-224-180.range86-160.btcentralplus.com. [86.160.224.180])
	by mx.google.com with ESMTPS id k49sm18522116een.4.2012.09.27.08.28.17
	(version=SSLv3 cipher=OTHER); Thu, 27 Sep 2012 08:28:19 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Thu, 27 Sep 2012 16:28:15 +0100
From: Keir Fraser <keir.xen@gmail.com>
To: Jan Beulich <JBeulich@suse.com>,
	xen-devel <xen-devel@lists.xen.org>
Message-ID: <CC8A2F1F.400C1%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [PATCH] x86/HPET: don't disable interrupt delivery
	right after setting it up
Thread-Index: Ac2cxLZSpM/wnNz3cEaYf94pRCbhYg==
In-Reply-To: <50648161020000780009E418@nat28.tlf.novell.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] [PATCH] x86/HPET: don't disable interrupt delivery
 right after setting it up
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 27/09/2012 15:40, "Jan Beulich" <JBeulich@suse.com> wrote:

> We shouldn't clear HPET_TN_FSB right after we (indirectly, via
> request_irq()) enabled it for the channels we intend to use for
> broadcasts.
> 
> This fixes a regression introduced by c/s 25103:0b0e42dc4f0a.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Acked-by: Keir Fraser <keir@xen.org>

> ---
> This fixes the MWAIT idle driver problem on the box that I was able to
> (artificially) reproduce it with. Hence I subsequently intend to revert
> 25960:6bf8b882df8f, but I'm not intending to do this before getting a
> push there.
> 
> I'm surprised that this didn't hit anyone so far with the ACPI-based
> idle driver...
> 
> --- 2012-09-21.orig/xen/arch/x86/hpet.c 2012-09-27 16:10:35.000000000 +0200
> +++ 2012-09-21/xen/arch/x86/hpet.c 2012-09-27 16:10:07.000000000 +0200
> @@ -533,7 +533,7 @@ void __init hpet_broadcast_init(void)
>      {
>          /* set HPET Tn as oneshot */
>          cfg = hpet_read32(HPET_Tn_CFG(hpet_events[i].idx));
> -        cfg &= ~(HPET_TN_LEVEL | HPET_TN_PERIODIC | HPET_TN_FSB);
> +        cfg &= ~(HPET_TN_LEVEL | HPET_TN_PERIODIC);
>          cfg |= HPET_TN_ENABLE | HPET_TN_32BIT;
>          hpet_write32(cfg, HPET_Tn_CFG(hpet_events[i].idx));
>  
> @@ -590,7 +590,7 @@ void hpet_broadcast_resume(void)
>  
>          /* set HPET Tn as oneshot */
>          cfg = hpet_read32(HPET_Tn_CFG(hpet_events[i].idx));
> -        cfg &= ~(HPET_TN_LEVEL | HPET_TN_PERIODIC | HPET_TN_FSB);
> +        cfg &= ~(HPET_TN_LEVEL | HPET_TN_PERIODIC);
>          cfg |= HPET_TN_ENABLE | HPET_TN_32BIT;
>          hpet_write32(cfg, HPET_Tn_CFG(hpet_events[i].idx));
>  
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Sep 27 15:29:50 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Sep 2012 15: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 1THG20-0000qq-In; Thu, 27 Sep 2012 15:29:40 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1THG1z-0000qW-FY
	for xen-devel@lists.xen.org; Thu, 27 Sep 2012 15:29:39 +0000
Received: from [85.158.139.211:22344] by server-12.bemta-5.messagelabs.com id
	53/4F-20729-2E074605; Thu, 27 Sep 2012 15:29:38 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-5.tower-206.messagelabs.com!1348759777!20169793!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-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23132 invoked from network); 27 Sep 2012 15:29:38 -0000
Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com)
	(74.125.83.45)
	by server-5.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Sep 2012 15:29:38 -0000
Received: by eekb47 with SMTP id b47so1066046eek.32
	for <xen-devel@lists.xen.org>; Thu, 27 Sep 2012 08:29:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=nunkAAz1MCv0L36UyfhVGESkO3daw0/xqAszORAnxqw=;
	b=GxDvtTlTQsrsCnoCH7J2om6WYtyOAw13RNkQ5f2U2tAyVNEYdsPMT7+7Ca+aoZiO3d
	r6DaKX7MEC8Tu/RdrIeWWFWG99Qr98qlsu2tKZLYYWGpVtfuW7prKli7yUbjrx0W2rge
	EygBpj2I/imEsgAA48qR9Vg0npq67pf8+X7KUjzG+SHmw4w1ge6VLz4kqwbtd3oP4pOX
	1kq/0oSy9Tzz8iG0wOocnjjimQiqIydJEd5v9U/bYW5pORacg8CpJ8aKxZEgjs6HVjMG
	DC6oNM6HnCaJC9NB2JAsSbg8KiYD2Zt4vLOXgFvkoBajnV01VgY5/0SArw1MyytU63LP
	NCWA==
Received: by 10.14.213.201 with SMTP id a49mr6435212eep.4.1348759777893;
	Thu, 27 Sep 2012 08:29:37 -0700 (PDT)
Received: from [192.168.1.69]
	(host86-160-224-180.range86-160.btcentralplus.com. [86.160.224.180])
	by mx.google.com with ESMTPS id u47sm18547498eep.1.2012.09.27.08.29.36
	(version=SSLv3 cipher=OTHER); Thu, 27 Sep 2012 08:29:37 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Thu, 27 Sep 2012 16:29:34 +0100
From: Keir Fraser <keir.xen@gmail.com>
To: Jan Beulich <JBeulich@suse.com>,
	xen-devel <xen-devel@lists.xen.org>
Message-ID: <CC8A2F6E.400C2%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [PATCH] x86/IRQ: fix valid-old-vector checks in
	__assign_irq_vector()
Thread-Index: Ac2cxOVpVI2f0psYAkWNChIm4ZSqCA==
In-Reply-To: <506483CC020000780009E42C@nat28.tlf.novell.com>
Mime-version: 1.0
Cc: Andrew Cooper <andrew.cooper3@citrix.com>
Subject: Re: [Xen-devel] [PATCH] x86/IRQ: fix valid-old-vector checks in
 __assign_irq_vector()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/09/2012 15:50, "Jan Beulich" <JBeulich@suse.com> wrote:

> There are two greater-than-zero checks for the old vector retrieved,
> which don't work when a negative value got stashed into the respective
> arch_irq_desc field. The effect of this was that for interrupts that
> are intended to get their affinity adjusted the first time before the
> first interrupt occurs, the affinity change would fail, because the
> original vector assignment would have caused the move_in_progress flag
> to get set (which causes subsequent re-assignments to fail until it
> gets cleared, which only happens from the ->ack() actor, i.e. when an
> interrupt actually occurred).
> 
> This addresses a problem introduced in c/s 23816:7f357e1ef60a (by
> changing IRQ_VECTOR_UNASSIGNED from 0 to -1).
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Acked-by: Keir Fraser <keir@xen.org>

> ---
> I have to admit that I don't understand why the value got changed in
> the first place: 0 is as invalid a value as -1 for a vector to be used
> for delivering hardware interrupts.
> 
> --- 2012-09-21.orig/xen/arch/x86/irq.c 2012-09-19 08:48:33.000000000 +0200
> +++ 2012-09-21/xen/arch/x86/irq.c 2012-09-27 13:33:45.000000000 +0200
> @@ -430,8 +430,7 @@ static int __assign_irq_vector(
>       * 0x80, because int 0x80 is hm, kind of importantish. ;)
>       */
>      static int current_vector = FIRST_DYNAMIC_VECTOR, current_offset = 0;
> -    unsigned int old_vector;
> -    int cpu, err;
> +    int cpu, err, old_vector;
>      cpumask_t tmp_mask;
>      vmask_t *irq_used_vectors = NULL;
>  
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Sep 27 15:29:50 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Sep 2012 15: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 1THG20-0000qq-In; Thu, 27 Sep 2012 15:29:40 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1THG1z-0000qW-FY
	for xen-devel@lists.xen.org; Thu, 27 Sep 2012 15:29:39 +0000
Received: from [85.158.139.211:22344] by server-12.bemta-5.messagelabs.com id
	53/4F-20729-2E074605; Thu, 27 Sep 2012 15:29:38 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-5.tower-206.messagelabs.com!1348759777!20169793!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-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23132 invoked from network); 27 Sep 2012 15:29:38 -0000
Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com)
	(74.125.83.45)
	by server-5.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Sep 2012 15:29:38 -0000
Received: by eekb47 with SMTP id b47so1066046eek.32
	for <xen-devel@lists.xen.org>; Thu, 27 Sep 2012 08:29:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=nunkAAz1MCv0L36UyfhVGESkO3daw0/xqAszORAnxqw=;
	b=GxDvtTlTQsrsCnoCH7J2om6WYtyOAw13RNkQ5f2U2tAyVNEYdsPMT7+7Ca+aoZiO3d
	r6DaKX7MEC8Tu/RdrIeWWFWG99Qr98qlsu2tKZLYYWGpVtfuW7prKli7yUbjrx0W2rge
	EygBpj2I/imEsgAA48qR9Vg0npq67pf8+X7KUjzG+SHmw4w1ge6VLz4kqwbtd3oP4pOX
	1kq/0oSy9Tzz8iG0wOocnjjimQiqIydJEd5v9U/bYW5pORacg8CpJ8aKxZEgjs6HVjMG
	DC6oNM6HnCaJC9NB2JAsSbg8KiYD2Zt4vLOXgFvkoBajnV01VgY5/0SArw1MyytU63LP
	NCWA==
Received: by 10.14.213.201 with SMTP id a49mr6435212eep.4.1348759777893;
	Thu, 27 Sep 2012 08:29:37 -0700 (PDT)
Received: from [192.168.1.69]
	(host86-160-224-180.range86-160.btcentralplus.com. [86.160.224.180])
	by mx.google.com with ESMTPS id u47sm18547498eep.1.2012.09.27.08.29.36
	(version=SSLv3 cipher=OTHER); Thu, 27 Sep 2012 08:29:37 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Thu, 27 Sep 2012 16:29:34 +0100
From: Keir Fraser <keir.xen@gmail.com>
To: Jan Beulich <JBeulich@suse.com>,
	xen-devel <xen-devel@lists.xen.org>
Message-ID: <CC8A2F6E.400C2%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [PATCH] x86/IRQ: fix valid-old-vector checks in
	__assign_irq_vector()
Thread-Index: Ac2cxOVpVI2f0psYAkWNChIm4ZSqCA==
In-Reply-To: <506483CC020000780009E42C@nat28.tlf.novell.com>
Mime-version: 1.0
Cc: Andrew Cooper <andrew.cooper3@citrix.com>
Subject: Re: [Xen-devel] [PATCH] x86/IRQ: fix valid-old-vector checks in
 __assign_irq_vector()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/09/2012 15:50, "Jan Beulich" <JBeulich@suse.com> wrote:

> There are two greater-than-zero checks for the old vector retrieved,
> which don't work when a negative value got stashed into the respective
> arch_irq_desc field. The effect of this was that for interrupts that
> are intended to get their affinity adjusted the first time before the
> first interrupt occurs, the affinity change would fail, because the
> original vector assignment would have caused the move_in_progress flag
> to get set (which causes subsequent re-assignments to fail until it
> gets cleared, which only happens from the ->ack() actor, i.e. when an
> interrupt actually occurred).
> 
> This addresses a problem introduced in c/s 23816:7f357e1ef60a (by
> changing IRQ_VECTOR_UNASSIGNED from 0 to -1).
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Acked-by: Keir Fraser <keir@xen.org>

> ---
> I have to admit that I don't understand why the value got changed in
> the first place: 0 is as invalid a value as -1 for a vector to be used
> for delivering hardware interrupts.
> 
> --- 2012-09-21.orig/xen/arch/x86/irq.c 2012-09-19 08:48:33.000000000 +0200
> +++ 2012-09-21/xen/arch/x86/irq.c 2012-09-27 13:33:45.000000000 +0200
> @@ -430,8 +430,7 @@ static int __assign_irq_vector(
>       * 0x80, because int 0x80 is hm, kind of importantish. ;)
>       */
>      static int current_vector = FIRST_DYNAMIC_VECTOR, current_offset = 0;
> -    unsigned int old_vector;
> -    int cpu, err;
> +    int cpu, err, old_vector;
>      cpumask_t tmp_mask;
>      vmask_t *irq_used_vectors = NULL;
>  
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Sep 27 15:31:31 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Sep 2012 15: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 1THG3b-00010P-2r; Thu, 27 Sep 2012 15:31:19 +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 1THG3Z-00010F-VS
	for xen-devel@lists.xen.org; Thu, 27 Sep 2012 15:31:18 +0000
Received: from [85.158.139.211:36616] by server-12.bemta-5.messagelabs.com id
	09/D2-20729-54174605; Thu, 27 Sep 2012 15:31:17 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-2.tower-206.messagelabs.com!1348759874!20195062!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-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2704 invoked from network); 27 Sep 2012 15:31:14 -0000
Received: from mail-ey0-f173.google.com (HELO mail-ey0-f173.google.com)
	(209.85.215.173)
	by server-2.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Sep 2012 15:31:14 -0000
Received: by eaaa1 with SMTP id a1so746248eaa.32
	for <xen-devel@lists.xen.org>; Thu, 27 Sep 2012 08:31:14 -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=gJR8gHMgCRLYobDUYc8ge2+fJ+agOA3KZHKF0WZZog8=;
	b=FqIsJl2Y3+wGBw0P4hl1uyMAt52Gxbb8FZwVWICJ4woxJIQOPDxABtncIwjd+YuZd8
	oaDJM6wPSdYVGSTnMROJGgEozQ2kmEmvseLak5XJGZA66zfT7E9VEuLrZK8TLsOH4mwq
	tDB2rQGn6CWkYk1tBxMaG/eY6Sv6bC5nLP6IFgfpywZjWp96QwtYu4iXXF5Ao+dyCMUU
	0c8mYrZqiBpz4HB3MTfpOpfF75W1Ui8OGpJ+btRA3qE97nrH8gVd+y1F/dXwGXc8a7KC
	Omt1jq37l0W5aKvTUVN/yh/pUMf6IgD7utNxHCdwJz1lBKXQiZiMuYrMIbQ8OqUqoMhK
	KVOw==
Received: by 10.14.203.70 with SMTP id e46mr6468811eeo.2.1348759873965;
	Thu, 27 Sep 2012 08:31:13 -0700 (PDT)
Received: from [192.168.1.69]
	(host86-160-224-180.range86-160.btcentralplus.com. [86.160.224.180])
	by mx.google.com with ESMTPS id t1sm18549610eeo.3.2012.09.27.08.31.10
	(version=SSLv3 cipher=OTHER); Thu, 27 Sep 2012 08:31:12 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Thu, 27 Sep 2012 16:31:06 +0100
From: Keir Fraser <keir.xen@gmail.com>
To: Jan Beulich <JBeulich@suse.com>,
	xen-devel <xen-devel@lists.xen.org>
Message-ID: <CC8A2FCA.400C3%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [PATCH] x86/HPET: don't needlessly set up channels
	for broadcast
Thread-Index: Ac2cxRw/gCmtRdK17EOSIToiiF56yA==
In-Reply-To: <506484FA020000780009E43D@nat28.tlf.novell.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] [PATCH] x86/HPET: don't needlessly set up channels
 for broadcast
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/09/2012 15:55, "Jan Beulich" <JBeulich@suse.com> wrote:

> When there are more FSB delivery capable HPET channels than CPU cores
> (or threads), we can simply use a dedicated channel per CPU. This
> avoids wasting the resources to handle the excess channels (including
> the pointless triggering of the respective interrupt on each
> wraparound) as well as the ping-pong of the interrupts' affinities
> (when getting assigned to different CPUs).
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Acked-by: Keir Fraser <keir@xen.org>

> --- a/xen/arch/x86/hpet.c
> +++ b/xen/arch/x86/hpet.c
> @@ -369,7 +369,7 @@ static void __init hpet_fsb_cap_lookup(v
>      if ( !hpet_events )
>          return;
>  
> -    for ( i = 0; i < num_chs; i++ )
> +    for ( i = 0; i < num_chs && num_hpets_used < nr_cpu_ids; i++ )
>      {
>          struct hpet_event_channel *ch = &hpet_events[num_hpets_used];
>          u32 cfg = hpet_read32(HPET_Tn_CFG(i));
> @@ -408,6 +408,9 @@ static struct hpet_event_channel *hpet_g
>      if ( num_hpets_used == 0 )
>          return hpet_events;
>  
> +    if ( num_hpets_used >= nr_cpu_ids )
> +        return &hpet_events[cpu];
> +
>      do {
>          next = next_channel;
>          if ( (i = next + 1) == num_hpets_used )
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Sep 27 15:31:31 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Sep 2012 15: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 1THG3b-00010P-2r; Thu, 27 Sep 2012 15:31:19 +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 1THG3Z-00010F-VS
	for xen-devel@lists.xen.org; Thu, 27 Sep 2012 15:31:18 +0000
Received: from [85.158.139.211:36616] by server-12.bemta-5.messagelabs.com id
	09/D2-20729-54174605; Thu, 27 Sep 2012 15:31:17 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-2.tower-206.messagelabs.com!1348759874!20195062!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-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2704 invoked from network); 27 Sep 2012 15:31:14 -0000
Received: from mail-ey0-f173.google.com (HELO mail-ey0-f173.google.com)
	(209.85.215.173)
	by server-2.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Sep 2012 15:31:14 -0000
Received: by eaaa1 with SMTP id a1so746248eaa.32
	for <xen-devel@lists.xen.org>; Thu, 27 Sep 2012 08:31:14 -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=gJR8gHMgCRLYobDUYc8ge2+fJ+agOA3KZHKF0WZZog8=;
	b=FqIsJl2Y3+wGBw0P4hl1uyMAt52Gxbb8FZwVWICJ4woxJIQOPDxABtncIwjd+YuZd8
	oaDJM6wPSdYVGSTnMROJGgEozQ2kmEmvseLak5XJGZA66zfT7E9VEuLrZK8TLsOH4mwq
	tDB2rQGn6CWkYk1tBxMaG/eY6Sv6bC5nLP6IFgfpywZjWp96QwtYu4iXXF5Ao+dyCMUU
	0c8mYrZqiBpz4HB3MTfpOpfF75W1Ui8OGpJ+btRA3qE97nrH8gVd+y1F/dXwGXc8a7KC
	Omt1jq37l0W5aKvTUVN/yh/pUMf6IgD7utNxHCdwJz1lBKXQiZiMuYrMIbQ8OqUqoMhK
	KVOw==
Received: by 10.14.203.70 with SMTP id e46mr6468811eeo.2.1348759873965;
	Thu, 27 Sep 2012 08:31:13 -0700 (PDT)
Received: from [192.168.1.69]
	(host86-160-224-180.range86-160.btcentralplus.com. [86.160.224.180])
	by mx.google.com with ESMTPS id t1sm18549610eeo.3.2012.09.27.08.31.10
	(version=SSLv3 cipher=OTHER); Thu, 27 Sep 2012 08:31:12 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Thu, 27 Sep 2012 16:31:06 +0100
From: Keir Fraser <keir.xen@gmail.com>
To: Jan Beulich <JBeulich@suse.com>,
	xen-devel <xen-devel@lists.xen.org>
Message-ID: <CC8A2FCA.400C3%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [PATCH] x86/HPET: don't needlessly set up channels
	for broadcast
Thread-Index: Ac2cxRw/gCmtRdK17EOSIToiiF56yA==
In-Reply-To: <506484FA020000780009E43D@nat28.tlf.novell.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] [PATCH] x86/HPET: don't needlessly set up channels
 for broadcast
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/09/2012 15:55, "Jan Beulich" <JBeulich@suse.com> wrote:

> When there are more FSB delivery capable HPET channels than CPU cores
> (or threads), we can simply use a dedicated channel per CPU. This
> avoids wasting the resources to handle the excess channels (including
> the pointless triggering of the respective interrupt on each
> wraparound) as well as the ping-pong of the interrupts' affinities
> (when getting assigned to different CPUs).
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Acked-by: Keir Fraser <keir@xen.org>

> --- a/xen/arch/x86/hpet.c
> +++ b/xen/arch/x86/hpet.c
> @@ -369,7 +369,7 @@ static void __init hpet_fsb_cap_lookup(v
>      if ( !hpet_events )
>          return;
>  
> -    for ( i = 0; i < num_chs; i++ )
> +    for ( i = 0; i < num_chs && num_hpets_used < nr_cpu_ids; i++ )
>      {
>          struct hpet_event_channel *ch = &hpet_events[num_hpets_used];
>          u32 cfg = hpet_read32(HPET_Tn_CFG(i));
> @@ -408,6 +408,9 @@ static struct hpet_event_channel *hpet_g
>      if ( num_hpets_used == 0 )
>          return hpet_events;
>  
> +    if ( num_hpets_used >= nr_cpu_ids )
> +        return &hpet_events[cpu];
> +
>      do {
>          next = next_channel;
>          if ( (i = next + 1) == num_hpets_used )
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Sep 27 15:31:43 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Sep 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 1THG3p-00012T-FB; Thu, 27 Sep 2012 15:31: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 1THG3n-00011t-Di
	for xen-devel@lists.xen.org; Thu, 27 Sep 2012 15:31:31 +0000
Received: from [85.158.143.35:19602] by server-2.bemta-4.messagelabs.com id
	55/2D-06610-25174605; Thu, 27 Sep 2012 15:31:30 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1348759889!13021462!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-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13500 invoked from network); 27 Sep 2012 15:31:29 -0000
Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com)
	(74.125.83.45)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Sep 2012 15:31:29 -0000
Received: by eekb47 with SMTP id b47so1067403eek.32
	for <xen-devel@lists.xen.org>; Thu, 27 Sep 2012 08:31:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=user-agent:date:subject:from:to:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=TOJQ6SGkuE+W9HW1VvJl5OTUcqTMsc04bXTdZdmJw0E=;
	b=PZoJ8wi3QnpaMAbGGmaAqYdUjlpFHSuxUJdw1SVGJtU+h7iAPGT0xaB+qfuEVAZwNi
	oM7zNzsAVuoL4XDIx3ghDQabpRReXGvdZJa9p6P+EK8xTWzvj9kOqxPcXlmRu8+Hv4tz
	+NYpkshGvoKndjZQTOiCTZxk+Ss7UMoGntFiFMRusBNEAQdL/R+lditfeNQoGBK4bZe2
	s7AS4D5LbUmbbn61qIShz7xPmnIt5g33T/Y6Ga83UEzXiddUHzwfPgAab75x5U1spRYA
	6Gdziw4Qz1IqzTMwZ9rCmdQOJQG0BHvCM+MWVkX+VgN+O4jby+tjsDCuRNt0gcBQLihv
	25ew==
Received: by 10.14.218.134 with SMTP id k6mr6380787eep.14.1348759889145;
	Thu, 27 Sep 2012 08:31:29 -0700 (PDT)
Received: from [192.168.1.69]
	(host86-160-224-180.range86-160.btcentralplus.com. [86.160.224.180])
	by mx.google.com with ESMTPS id z3sm18461157eel.15.2012.09.27.08.31.27
	(version=SSLv3 cipher=OTHER); Thu, 27 Sep 2012 08:31:28 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Thu, 27 Sep 2012 16:31:24 +0100
From: Keir Fraser <keir.xen@gmail.com>
To: Jan Beulich <JBeulich@suse.com>,
	xen-devel <xen-devel@lists.xen.org>
Message-ID: <CC8A2FDC.400C4%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [PATCH] x86: remove further code applicable to
	32-bit CPUs only
Thread-Index: Ac2cxSb52X/OWvnzyEazZl7ih58SnQ==
In-Reply-To: <50648672020000780009E45F@nat28.tlf.novell.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] [PATCH] x86: remove further code applicable to
 32-bit CPUs only
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 27/09/2012 16:01, "Jan Beulich" <JBeulich@suse.com> wrote:

> On the AMD side, anything prior to family 0xf can now be ignored, as
> well as very low model numbers of family 6 on the Intel side.
> 
> Apart from that, there were several made up CPU features that turned
> out entirely unused throughout the tree.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Acked-by: Keir Fraser <keir@xen.org>

> --- a/xen/arch/x86/cpu/amd.c
> +++ b/xen/arch/x86/cpu/amd.c
> @@ -180,7 +180,7 @@ static void __devinit set_cpuidmask(cons
> if (c->x86 >= 0x10) {
> wrmsr(MSR_K8_FEATURE_MASK, feat_edx, feat_ecx);
> wrmsr(MSR_K8_EXT_FEATURE_MASK, extfeat_edx, extfeat_ecx);
> - } else if (c->x86 == 0x0f) {
> + } else {
> wrmsr_amd(MSR_K8_FEATURE_MASK, feat_edx, feat_ecx);
> wrmsr_amd(MSR_K8_EXT_FEATURE_MASK, extfeat_edx, extfeat_ecx);
> }
> @@ -234,14 +234,7 @@ int cpu_has_amd_erratum(const struct cpu
>  /* Can this system suffer from TSC drift due to C1 clock ramping? */
>  static int c1_ramping_may_cause_clock_drift(struct cpuinfo_x86 *c)
>  { 
> - if (c->x86 < 0xf) {
> -  /*
> -   * TSC drift doesn't exist on 7th Gen or less
> -   * However, OS still needs to consider effects
> -   * of P-state changes on TSC
> -   */
> -  return 0;
> - } else if (cpuid_edx(0x80000007) & (1<<8)) {
> + if (cpuid_edx(0x80000007) & (1<<8)) {
> /*
> * CPUID.AdvPowerMgmtInfo.TscInvariant
> * EDX bit 8, 8000_0007
> @@ -416,41 +409,7 @@ static void __devinit init_amd(struct cp
>  
> switch(c->x86)
> {
> - case 6: /* An Athlon/Duron */
> - 
> -  /* Bit 15 of Athlon specific MSR 15, needs to be 0
> -   * to enable SSE on Palomino/Morgan/Barton CPU's.
> -   * If the BIOS didn't enable it already, enable it here.
> -   */
> -  if (c->x86_model >= 6 && c->x86_model <= 10) {
> -   if (!cpu_has(c, X86_FEATURE_XMM)) {
> -    printk(KERN_INFO "Enabling disabled K7/SSE Support.\n");
> -    rdmsr(MSR_K7_HWCR, l, h);
> -    l &= ~0x00008000;
> -    wrmsr(MSR_K7_HWCR, l, h);
> -    set_bit(X86_FEATURE_XMM, c->x86_capability);
> -   }
> -  }
> -
> -  /* It's been determined by AMD that Athlons since model 8 stepping 1
> -   * are more robust with CLK_CTL set to 200xxxxx instead of 600xxxxx
> -   * As per AMD technical note 27212 0.2
> -   */
> -  if ((c->x86_model == 8 && c->x86_mask>=1) || (c->x86_model > 8)) {
> -   rdmsr(MSR_K7_CLK_CTL, l, h);
> -   if ((l & 0xfff00000) != 0x20000000) {
> -    printk ("CPU: CLK_CTL MSR was %x. Reprogramming to %x\n", l,
> -     ((l & 0x000fffff)|0x20000000));
> -    wrmsr(MSR_K7_CLK_CTL, (l & 0x000fffff)|0x20000000, h);
> -   }
> -  }
> -  set_bit(X86_FEATURE_K7, c->x86_capability);
> -  break;
> -
> - case 0xf:
> - /* Use K8 tuning for Fam10h and Fam11h */
> - case 0x10 ... 0x17:
> -  set_bit(X86_FEATURE_K8, c->x86_capability);
> + case 0xf ... 0x17:
> disable_c1e(NULL);
> if (acpi_smi_cmd && (acpi_enable_value | acpi_disable_value))
> pv_post_outb_hook = check_disable_c1e;
> --- a/xen/arch/x86/cpu/intel.c
> +++ b/xen/arch/x86/cpu/intel.c
> @@ -192,7 +192,6 @@ static int __devinit num_cpu_cores(struc
>  static void __devinit init_intel(struct cpuinfo_x86 *c)
>  {
> unsigned int l2 = 0;
> - char *p = NULL;
>  
> /* Detect the extended topology information if available */
> detect_extended_topology(c);
> @@ -210,37 +209,6 @@ static void __devinit init_intel(struct
> if ((c->x86<<8 | c->x86_model<<4 | c->x86_mask) < 0x633)
> clear_bit(X86_FEATURE_SEP, c->x86_capability);
>  
> - /* Names for the Pentium II/Celeron processors
> -    detectable only by also checking the cache size.
> -    Dixon is NOT a Celeron. */
> - if (c->x86 == 6) {
> -  switch (c->x86_model) {
> -  case 5:
> -   if (c->x86_mask == 0) {
> -    if (l2 == 0)
> -     p = "Celeron (Covington)";
> -    else if (l2 == 256)
> -     p = "Mobile Pentium II (Dixon)";
> -   }
> -   break;
> -   
> -  case 6:
> -   if (l2 == 128)
> -    p = "Celeron (Mendocino)";
> -   else if (c->x86_mask == 0 || c->x86_mask == 5)
> -    p = "Celeron-A";
> -   break;
> -   
> -  case 8:
> -   if (l2 == 128)
> -    p = "Celeron (Coppermine)";
> -   break;
> -  }
> - }
> -
> - if ( p )
> -  safe_strcpy(c->x86_model_id, p);
> -
> if ( !cpu_has(c, X86_FEATURE_XTOPOLOGY) )
> {
> c->x86_max_cores = num_cpu_cores(c);
> @@ -275,10 +243,6 @@ static void __devinit init_intel(struct
> }
>  #endif
>  
> - if (c->x86 == 15)
> -  set_bit(X86_FEATURE_P4, c->x86_capability);
> - if (c->x86 == 6)
> -  set_bit(X86_FEATURE_P3, c->x86_capability);
> if ((c->x86 == 0xf && c->x86_model >= 0x03) ||
> (c->x86 == 0x6 && c->x86_model >= 0x0e))
> set_bit(X86_FEATURE_CONSTANT_TSC, c->x86_capability);
> --- a/xen/include/asm-x86/cpufeature.h
> +++ b/xen/include/asm-x86/cpufeature.h
> @@ -64,15 +64,6 @@
>  
>  /* Other features, Linux-defined mapping, word 3 */
>  /* This range is used for feature bits which conflict or are synthesized */
> -#define X86_FEATURE_CXMMX (3*32+ 0) /* Cyrix MMX extensions */
> -#define X86_FEATURE_K6_MTRR (3*32+ 1) /* AMD K6 nonstandard MTRRs */
> -#define X86_FEATURE_CYRIX_ARR (3*32+ 2) /* Cyrix ARRs (= MTRRs) */
> -#define X86_FEATURE_CENTAUR_MCR (3*32+ 3) /* Centaur MCRs (= MTRRs) */
> -/* cpu types for specific tunings: */
> -#define X86_FEATURE_K8  (3*32+ 4) /* Opteron, Athlon64 */
> -#define X86_FEATURE_K7  (3*32+ 5) /* Athlon */
> -#define X86_FEATURE_P3  (3*32+ 6) /* P3 */
> -#define X86_FEATURE_P4  (3*32+ 7) /* P4 */
>  #define X86_FEATURE_CONSTANT_TSC (3*32+ 8) /* TSC ticks at a constant rate */
>  #define X86_FEATURE_NONSTOP_TSC (3*32+ 9) /* TSC does not stop in C states */
>  #define X86_FEATURE_ARAT (3*32+ 10) /* Always running APIC timer */
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Sep 27 15:31:43 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Sep 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 1THG3p-00012T-FB; Thu, 27 Sep 2012 15:31: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 1THG3n-00011t-Di
	for xen-devel@lists.xen.org; Thu, 27 Sep 2012 15:31:31 +0000
Received: from [85.158.143.35:19602] by server-2.bemta-4.messagelabs.com id
	55/2D-06610-25174605; Thu, 27 Sep 2012 15:31:30 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1348759889!13021462!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-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13500 invoked from network); 27 Sep 2012 15:31:29 -0000
Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com)
	(74.125.83.45)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Sep 2012 15:31:29 -0000
Received: by eekb47 with SMTP id b47so1067403eek.32
	for <xen-devel@lists.xen.org>; Thu, 27 Sep 2012 08:31:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=user-agent:date:subject:from:to:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=TOJQ6SGkuE+W9HW1VvJl5OTUcqTMsc04bXTdZdmJw0E=;
	b=PZoJ8wi3QnpaMAbGGmaAqYdUjlpFHSuxUJdw1SVGJtU+h7iAPGT0xaB+qfuEVAZwNi
	oM7zNzsAVuoL4XDIx3ghDQabpRReXGvdZJa9p6P+EK8xTWzvj9kOqxPcXlmRu8+Hv4tz
	+NYpkshGvoKndjZQTOiCTZxk+Ss7UMoGntFiFMRusBNEAQdL/R+lditfeNQoGBK4bZe2
	s7AS4D5LbUmbbn61qIShz7xPmnIt5g33T/Y6Ga83UEzXiddUHzwfPgAab75x5U1spRYA
	6Gdziw4Qz1IqzTMwZ9rCmdQOJQG0BHvCM+MWVkX+VgN+O4jby+tjsDCuRNt0gcBQLihv
	25ew==
Received: by 10.14.218.134 with SMTP id k6mr6380787eep.14.1348759889145;
	Thu, 27 Sep 2012 08:31:29 -0700 (PDT)
Received: from [192.168.1.69]
	(host86-160-224-180.range86-160.btcentralplus.com. [86.160.224.180])
	by mx.google.com with ESMTPS id z3sm18461157eel.15.2012.09.27.08.31.27
	(version=SSLv3 cipher=OTHER); Thu, 27 Sep 2012 08:31:28 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Thu, 27 Sep 2012 16:31:24 +0100
From: Keir Fraser <keir.xen@gmail.com>
To: Jan Beulich <JBeulich@suse.com>,
	xen-devel <xen-devel@lists.xen.org>
Message-ID: <CC8A2FDC.400C4%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [PATCH] x86: remove further code applicable to
	32-bit CPUs only
Thread-Index: Ac2cxSb52X/OWvnzyEazZl7ih58SnQ==
In-Reply-To: <50648672020000780009E45F@nat28.tlf.novell.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] [PATCH] x86: remove further code applicable to
 32-bit CPUs only
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 27/09/2012 16:01, "Jan Beulich" <JBeulich@suse.com> wrote:

> On the AMD side, anything prior to family 0xf can now be ignored, as
> well as very low model numbers of family 6 on the Intel side.
> 
> Apart from that, there were several made up CPU features that turned
> out entirely unused throughout the tree.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Acked-by: Keir Fraser <keir@xen.org>

> --- a/xen/arch/x86/cpu/amd.c
> +++ b/xen/arch/x86/cpu/amd.c
> @@ -180,7 +180,7 @@ static void __devinit set_cpuidmask(cons
> if (c->x86 >= 0x10) {
> wrmsr(MSR_K8_FEATURE_MASK, feat_edx, feat_ecx);
> wrmsr(MSR_K8_EXT_FEATURE_MASK, extfeat_edx, extfeat_ecx);
> - } else if (c->x86 == 0x0f) {
> + } else {
> wrmsr_amd(MSR_K8_FEATURE_MASK, feat_edx, feat_ecx);
> wrmsr_amd(MSR_K8_EXT_FEATURE_MASK, extfeat_edx, extfeat_ecx);
> }
> @@ -234,14 +234,7 @@ int cpu_has_amd_erratum(const struct cpu
>  /* Can this system suffer from TSC drift due to C1 clock ramping? */
>  static int c1_ramping_may_cause_clock_drift(struct cpuinfo_x86 *c)
>  { 
> - if (c->x86 < 0xf) {
> -  /*
> -   * TSC drift doesn't exist on 7th Gen or less
> -   * However, OS still needs to consider effects
> -   * of P-state changes on TSC
> -   */
> -  return 0;
> - } else if (cpuid_edx(0x80000007) & (1<<8)) {
> + if (cpuid_edx(0x80000007) & (1<<8)) {
> /*
> * CPUID.AdvPowerMgmtInfo.TscInvariant
> * EDX bit 8, 8000_0007
> @@ -416,41 +409,7 @@ static void __devinit init_amd(struct cp
>  
> switch(c->x86)
> {
> - case 6: /* An Athlon/Duron */
> - 
> -  /* Bit 15 of Athlon specific MSR 15, needs to be 0
> -   * to enable SSE on Palomino/Morgan/Barton CPU's.
> -   * If the BIOS didn't enable it already, enable it here.
> -   */
> -  if (c->x86_model >= 6 && c->x86_model <= 10) {
> -   if (!cpu_has(c, X86_FEATURE_XMM)) {
> -    printk(KERN_INFO "Enabling disabled K7/SSE Support.\n");
> -    rdmsr(MSR_K7_HWCR, l, h);
> -    l &= ~0x00008000;
> -    wrmsr(MSR_K7_HWCR, l, h);
> -    set_bit(X86_FEATURE_XMM, c->x86_capability);
> -   }
> -  }
> -
> -  /* It's been determined by AMD that Athlons since model 8 stepping 1
> -   * are more robust with CLK_CTL set to 200xxxxx instead of 600xxxxx
> -   * As per AMD technical note 27212 0.2
> -   */
> -  if ((c->x86_model == 8 && c->x86_mask>=1) || (c->x86_model > 8)) {
> -   rdmsr(MSR_K7_CLK_CTL, l, h);
> -   if ((l & 0xfff00000) != 0x20000000) {
> -    printk ("CPU: CLK_CTL MSR was %x. Reprogramming to %x\n", l,
> -     ((l & 0x000fffff)|0x20000000));
> -    wrmsr(MSR_K7_CLK_CTL, (l & 0x000fffff)|0x20000000, h);
> -   }
> -  }
> -  set_bit(X86_FEATURE_K7, c->x86_capability);
> -  break;
> -
> - case 0xf:
> - /* Use K8 tuning for Fam10h and Fam11h */
> - case 0x10 ... 0x17:
> -  set_bit(X86_FEATURE_K8, c->x86_capability);
> + case 0xf ... 0x17:
> disable_c1e(NULL);
> if (acpi_smi_cmd && (acpi_enable_value | acpi_disable_value))
> pv_post_outb_hook = check_disable_c1e;
> --- a/xen/arch/x86/cpu/intel.c
> +++ b/xen/arch/x86/cpu/intel.c
> @@ -192,7 +192,6 @@ static int __devinit num_cpu_cores(struc
>  static void __devinit init_intel(struct cpuinfo_x86 *c)
>  {
> unsigned int l2 = 0;
> - char *p = NULL;
>  
> /* Detect the extended topology information if available */
> detect_extended_topology(c);
> @@ -210,37 +209,6 @@ static void __devinit init_intel(struct
> if ((c->x86<<8 | c->x86_model<<4 | c->x86_mask) < 0x633)
> clear_bit(X86_FEATURE_SEP, c->x86_capability);
>  
> - /* Names for the Pentium II/Celeron processors
> -    detectable only by also checking the cache size.
> -    Dixon is NOT a Celeron. */
> - if (c->x86 == 6) {
> -  switch (c->x86_model) {
> -  case 5:
> -   if (c->x86_mask == 0) {
> -    if (l2 == 0)
> -     p = "Celeron (Covington)";
> -    else if (l2 == 256)
> -     p = "Mobile Pentium II (Dixon)";
> -   }
> -   break;
> -   
> -  case 6:
> -   if (l2 == 128)
> -    p = "Celeron (Mendocino)";
> -   else if (c->x86_mask == 0 || c->x86_mask == 5)
> -    p = "Celeron-A";
> -   break;
> -   
> -  case 8:
> -   if (l2 == 128)
> -    p = "Celeron (Coppermine)";
> -   break;
> -  }
> - }
> -
> - if ( p )
> -  safe_strcpy(c->x86_model_id, p);
> -
> if ( !cpu_has(c, X86_FEATURE_XTOPOLOGY) )
> {
> c->x86_max_cores = num_cpu_cores(c);
> @@ -275,10 +243,6 @@ static void __devinit init_intel(struct
> }
>  #endif
>  
> - if (c->x86 == 15)
> -  set_bit(X86_FEATURE_P4, c->x86_capability);
> - if (c->x86 == 6)
> -  set_bit(X86_FEATURE_P3, c->x86_capability);
> if ((c->x86 == 0xf && c->x86_model >= 0x03) ||
> (c->x86 == 0x6 && c->x86_model >= 0x0e))
> set_bit(X86_FEATURE_CONSTANT_TSC, c->x86_capability);
> --- a/xen/include/asm-x86/cpufeature.h
> +++ b/xen/include/asm-x86/cpufeature.h
> @@ -64,15 +64,6 @@
>  
>  /* Other features, Linux-defined mapping, word 3 */
>  /* This range is used for feature bits which conflict or are synthesized */
> -#define X86_FEATURE_CXMMX (3*32+ 0) /* Cyrix MMX extensions */
> -#define X86_FEATURE_K6_MTRR (3*32+ 1) /* AMD K6 nonstandard MTRRs */
> -#define X86_FEATURE_CYRIX_ARR (3*32+ 2) /* Cyrix ARRs (= MTRRs) */
> -#define X86_FEATURE_CENTAUR_MCR (3*32+ 3) /* Centaur MCRs (= MTRRs) */
> -/* cpu types for specific tunings: */
> -#define X86_FEATURE_K8  (3*32+ 4) /* Opteron, Athlon64 */
> -#define X86_FEATURE_K7  (3*32+ 5) /* Athlon */
> -#define X86_FEATURE_P3  (3*32+ 6) /* P3 */
> -#define X86_FEATURE_P4  (3*32+ 7) /* P4 */
>  #define X86_FEATURE_CONSTANT_TSC (3*32+ 8) /* TSC ticks at a constant rate */
>  #define X86_FEATURE_NONSTOP_TSC (3*32+ 9) /* TSC does not stop in C states */
>  #define X86_FEATURE_ARAT (3*32+ 10) /* Always running APIC timer */
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Sep 27 15:33:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Sep 2012 15: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 1THG58-0001Cu-Uy; Thu, 27 Sep 2012 15:32:54 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dan.magenheimer@oracle.com>) id 1THG57-0001Cl-JT
	for xen-devel@lists.xen.org; Thu, 27 Sep 2012 15:32:53 +0000
Received: from [85.158.137.99:33686] by server-8.bemta-3.messagelabs.com id
	AE/A9-16337-4A174605; Thu, 27 Sep 2012 15:32:52 +0000
X-Env-Sender: dan.magenheimer@oracle.com
X-Msg-Ref: server-14.tower-217.messagelabs.com!1348759970!19357389!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDc3ODg1Mg==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3601 invoked from network); 27 Sep 2012 15:32:51 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-14.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 27 Sep 2012 15:32:51 -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 q8RFWlBH019222
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 27 Sep 2012 15:32:47 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
	q8RFWkLB011352
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 27 Sep 2012 15:32:46 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
	q8RFWkuK030871; Thu, 27 Sep 2012 10:32:46 -0500
MIME-Version: 1.0
Message-ID: <b60910c6-06f7-42d1-a474-bdaaae7a61a9@default>
Date: Thu, 27 Sep 2012 08:32:35 -0700 (PDT)
From: Dan Magenheimer <dan.magenheimer@oracle.com>
To: Konrad Wilk <konrad.wilk@oracle.com>, mike.mcclurg@citrix.com,
	anil@recoil.org
References: <53b8c758-2675-42a7-b63f-4f9ad0006d84@default>
	<20120927112624.GA8576@phenom.dumpdata.com>
In-Reply-To: <20120927112624.GA8576@phenom.dumpdata.com>
X-Priority: 3
X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.7  (607090) [OL
	12.0.6661.5003 (x86)]
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: Kurt Hackel <kurt.hackel@oracle.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] domain creation vs querying free memory (xend and
	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

> From: Konrad Rzeszutek Wilk
> Subject: Re: domain creation vs querying free memory (xend and xl)
> 
> On Wed, Sep 26, 2012 at 02:17:06PM -0700, Dan Magenheimer wrote:
> > I was asked a question that seems like it should be obvious
> > but it doesn't seem to be, at least in xm-land.  I'll look
> > into it further, as well as for xl, but I thought I'd ask
> > first to see if there is a known answer or if this is a known
> > problem:
> >
> > Suppose that xm/xl create is issued on a large-memory
> > domain (PV or HVM or, future, PVH).  It takes awhile
> > for this domain to launch and during at least part of this
> > time, the toolset hasn't yet requested all of the
> > required memory from the hypervisor to complete the
> > launch of the domain...  or perhaps the toolset has,
> > but the hypervisor is slow about calling the long sequence
> > of page allocations (e.g. maybe because it is zeroing
> > each page?).
> >
> > Then it is desired to launch a second large-memory domain.
> > The tools can query Xen to see if there is sufficient RAM
> > and there is, because the first launch has not yet
> > allocated all the RAM assigned to it.
> >
> > But the second domain launch fails, possibly after
> > several minutes because, actually, there isn't enough
> > physical RAM for both.
> >
> > Does this make sense?  Should the tools "reserve"
> > maxmem as a "transaction" and/or ensure that "xm/xl
> > free" calls account for the entire requested amount
> > of RAM?  Or maybe xl _does_ work this way?
> 
> So say "freeze" the amount of free memory. Lets CC the XCP folks

Hmmm... the problem is the opposite (I think, since I don't
have hardware at hand to reproduce it).

Assume a machine has 2TB of physical RAM and a "xm create"
is started to launch a 1TB guest called "X".  While X is
being launched, another thread watches "xm free" and sees
that it slowly goes down from 1.995TB.  That thread does not
know what the eventual "floor" will be.  Now a third thread
does a "xm create" to launch a second 1TB guest "Y".
The "xm create" asks the hypervisor and sees, yep, there
is, at this moment, 1.376TB of free memory so it commences
launching the guest.

Because the hypervisor and dom0 consume some RAM, both
of these "xm create" will eventually fail, possibly
after several minutes.

Seems like a "xm unreserved" is needed, similar to "xm free"
but takes into account the tools' knowledge of what RAM is
in the process of being reserved for launching domains,
not just the allocation requests the hypervisor has already
processed.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 27 15:33:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Sep 2012 15: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 1THG58-0001Cu-Uy; Thu, 27 Sep 2012 15:32:54 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dan.magenheimer@oracle.com>) id 1THG57-0001Cl-JT
	for xen-devel@lists.xen.org; Thu, 27 Sep 2012 15:32:53 +0000
Received: from [85.158.137.99:33686] by server-8.bemta-3.messagelabs.com id
	AE/A9-16337-4A174605; Thu, 27 Sep 2012 15:32:52 +0000
X-Env-Sender: dan.magenheimer@oracle.com
X-Msg-Ref: server-14.tower-217.messagelabs.com!1348759970!19357389!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDc3ODg1Mg==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3601 invoked from network); 27 Sep 2012 15:32:51 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-14.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 27 Sep 2012 15:32:51 -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 q8RFWlBH019222
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 27 Sep 2012 15:32:47 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
	q8RFWkLB011352
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 27 Sep 2012 15:32:46 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
	q8RFWkuK030871; Thu, 27 Sep 2012 10:32:46 -0500
MIME-Version: 1.0
Message-ID: <b60910c6-06f7-42d1-a474-bdaaae7a61a9@default>
Date: Thu, 27 Sep 2012 08:32:35 -0700 (PDT)
From: Dan Magenheimer <dan.magenheimer@oracle.com>
To: Konrad Wilk <konrad.wilk@oracle.com>, mike.mcclurg@citrix.com,
	anil@recoil.org
References: <53b8c758-2675-42a7-b63f-4f9ad0006d84@default>
	<20120927112624.GA8576@phenom.dumpdata.com>
In-Reply-To: <20120927112624.GA8576@phenom.dumpdata.com>
X-Priority: 3
X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.7  (607090) [OL
	12.0.6661.5003 (x86)]
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: Kurt Hackel <kurt.hackel@oracle.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] domain creation vs querying free memory (xend and
	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

> From: Konrad Rzeszutek Wilk
> Subject: Re: domain creation vs querying free memory (xend and xl)
> 
> On Wed, Sep 26, 2012 at 02:17:06PM -0700, Dan Magenheimer wrote:
> > I was asked a question that seems like it should be obvious
> > but it doesn't seem to be, at least in xm-land.  I'll look
> > into it further, as well as for xl, but I thought I'd ask
> > first to see if there is a known answer or if this is a known
> > problem:
> >
> > Suppose that xm/xl create is issued on a large-memory
> > domain (PV or HVM or, future, PVH).  It takes awhile
> > for this domain to launch and during at least part of this
> > time, the toolset hasn't yet requested all of the
> > required memory from the hypervisor to complete the
> > launch of the domain...  or perhaps the toolset has,
> > but the hypervisor is slow about calling the long sequence
> > of page allocations (e.g. maybe because it is zeroing
> > each page?).
> >
> > Then it is desired to launch a second large-memory domain.
> > The tools can query Xen to see if there is sufficient RAM
> > and there is, because the first launch has not yet
> > allocated all the RAM assigned to it.
> >
> > But the second domain launch fails, possibly after
> > several minutes because, actually, there isn't enough
> > physical RAM for both.
> >
> > Does this make sense?  Should the tools "reserve"
> > maxmem as a "transaction" and/or ensure that "xm/xl
> > free" calls account for the entire requested amount
> > of RAM?  Or maybe xl _does_ work this way?
> 
> So say "freeze" the amount of free memory. Lets CC the XCP folks

Hmmm... the problem is the opposite (I think, since I don't
have hardware at hand to reproduce it).

Assume a machine has 2TB of physical RAM and a "xm create"
is started to launch a 1TB guest called "X".  While X is
being launched, another thread watches "xm free" and sees
that it slowly goes down from 1.995TB.  That thread does not
know what the eventual "floor" will be.  Now a third thread
does a "xm create" to launch a second 1TB guest "Y".
The "xm create" asks the hypervisor and sees, yep, there
is, at this moment, 1.376TB of free memory so it commences
launching the guest.

Because the hypervisor and dom0 consume some RAM, both
of these "xm create" will eventually fail, possibly
after several minutes.

Seems like a "xm unreserved" is needed, similar to "xm free"
but takes into account the tools' knowledge of what RAM is
in the process of being reserved for launching domains,
not just the allocation requests the hypervisor has already
processed.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 27 15:33:09 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Sep 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 1THG5D-0001Da-C3; Thu, 27 Sep 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 <ben.guthro@gmail.com>) id 1THG5B-0001DH-Kd
	for xen-devel@lists.xen.org; Thu, 27 Sep 2012 15:32:57 +0000
Received: from [85.158.143.35:27949] by server-1.bemta-4.messagelabs.com id
	96/88-05684-8A174605; Thu, 27 Sep 2012 15:32:56 +0000
X-Env-Sender: ben.guthro@gmail.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1348759973!18746117!1
X-Originating-IP: [209.85.223.173]
X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_20_30,HTML_MESSAGE,
	RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2122 invoked from network); 27 Sep 2012 15:32:54 -0000
Received: from mail-ie0-f173.google.com (HELO mail-ie0-f173.google.com)
	(209.85.223.173)
	by server-13.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Sep 2012 15:32:54 -0000
Received: by iea17 with SMTP id 17so6027854iea.32
	for <xen-devel@lists.xen.org>; Thu, 27 Sep 2012 08:32:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
	bh=ydVJYTHNAdKRk7xfcxY55c0WatLfKVG4yV+kzqNGi3M=;
	b=igaMMDvufY7bNl1N1h/ZsI9Bq/uT+meys10j8f3W4QVpbjaiBhz1l1FamgxI81nJqE
	R8UGOfxCWn6A9qdhJwaOroa6bYM4u6WpLxGJ6u7NTQIYWAZ/4q1L06+0F55yZlpIcIne
	o6HzLmAX0z1KLN2k/DFJAcY04rQe+Gcyr3b32xWLOULlnio6bCgPgZZDfo4ECAlo65PL
	ZQFba+7mfDRvUBG0t6QlkPi3jzVJpaaJxUW+PvFXh0iejNluWrcMYhiDUquk5HkwpHod
	1BN0Mrn9ckzHUylq9Lcf2EJiVXyPwribUT/1z2VR1f/h3A3BpioiR5RauUtu7aNoEaG6
	rCdA==
MIME-Version: 1.0
Received: by 10.50.183.200 with SMTP id eo8mr14768381igc.54.1348759972697;
	Thu, 27 Sep 2012 08:32:52 -0700 (PDT)
Received: by 10.64.55.132 with HTTP; Thu, 27 Sep 2012 08:32:52 -0700 (PDT)
In-Reply-To: <50648C21020000780009E478@nat28.tlf.novell.com>
References: <CAOvdn6UCF2A3yP1cqWn=dxwr0ayRbr+rg+xj8META9Dm0+CoNw@mail.gmail.com>
	<CC868168.3FD29%keir.xen@gmail.com>
	<CAOvdn6U-JyLvt96gkLkqzi088tU9_ktv4D+fkJac_BKVe05Y-w@mail.gmail.com>
	<CAOvdn6V+s3AbRzsu8VArbmrZou=im9SqvPf-9Wpif_BrNMv=yg@mail.gmail.com>
	<50617297020000780009D8AA@nat28.tlf.novell.com>
	<CAOvdn6Vsnbcd7m8mh3tSgn3KaEoeiOyVD1mr3uQ3bN=rF=pDUQ@mail.gmail.com>
	<5062F880020000780009DF3B@nat28.tlf.novell.com>
	<CAOvdn6VyAVg24=c1OxqttxuGFyN_NzpfZ7RoCYc2mVF84c5big@mail.gmail.com>
	<50641E86020000780009E2E3@nat28.tlf.novell.com>
	<CAOvdn6VE13fOSjrKU4Ryr=344u+YwygASj6z1ag_U-x-qvOC9g@mail.gmail.com>
	<50648C21020000780009E478@nat28.tlf.novell.com>
Date: Thu, 27 Sep 2012 11:32:52 -0400
X-Google-Sender-Auth: OycRnc3xOJ1E6uRbSys9KNdWFFU
Message-ID: <CAOvdn6VKrPzWLdETq10ihytDjyOjK55ShnRnCS6V112aYE=VJg@mail.gmail.com>
From: Ben Guthro <ben@guthro.net>
To: Jan Beulich <JBeulich@suse.com>
Cc: Keir Fraser <keir.xen@gmail.com>, John Baboval <john.baboval@citrix.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen4.2 S3 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: multipart/mixed; boundary="===============5080747942231164041=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============5080747942231164041==
Content-Type: multipart/alternative; boundary=14dae93404350f56ef04cab0a70b

--14dae93404350f56ef04cab0a70b
Content-Type: text/plain; charset=ISO-8859-1

ACK.

I now see microcode updates for both CPUs.


[   47.612719] Disabling non-boot CPUs ...
(XEN) Preparing system for ACPI S3 state.
(XEN) Disabling non-boot CPUs ...
(XEN) Breaking vcpu affinity for domain 0 vcpu 1
(XEN) Entering ACPI S3 state.
(XEN) mce_intel.c:1239: MCA Capability: BCAST 1 SER 0 CMCI 0 firstbank 1
extended MCE MSR 0
(XEN) CMCI: CPU0 has no CMCI support
(XEN) CPU0: Thermal monitoring enabled (TM2)
(XEN) Finishing wakeup from ACPI S3 state.
(XEN) microcode: CPU0 updated from revision 0x60c to 0x60f, date =
2010-09-29
(XEN) Enabling non-boot CPUs  ...
(XEN) Booting processor 1/1 eip 8a000
(XEN) Initializing CPU#1
(XEN) CPU: L1 I cache: 32K, L1 D cache: 32K
(XEN) CPU: L2 cache: 3072K
(XEN) CPU: Physical Processor ID: 0
(XEN) CPU: Processor Core ID: 1
(XEN) CMCI: CPU1 has no CMCI support
(XEN) CPU1: Thermal monitoring enabled (TM2)
(XEN) CPU1: Intel(R) Core(TM)2 Duo CPU     P8400  @ 2.26GHz stepping 06
(XEN) microcode: CPU1 updated from revision 0x60c to 0x60f, date =
2010-09-29
[   47.720054] ACPI: Low-level resume complete


On Thu, Sep 27, 2012 at 11:25 AM, Jan Beulich <JBeulich@suse.com> wrote:

> >>> On 27.09.12 at 14:12, Ben Guthro <ben@guthro.net> wrote:
> > On Thu, Sep 27, 2012 at 3:38 AM, Jan Beulich <JBeulich@suse.com> wrote:
> >> > (XEN) microcode: collect_cpu_info for CPU0
> >> > (XEN) microcode: collect_cpu_info : sig=0x10676, pf=0x80, rev=0x60c
> >> > (XEN) microcode: collect_cpu_info for CPU1
> >> > (XEN) microcode: collect_cpu_info : sig=0x10676, pf=0x80, rev=0x60f
> >>
> >> And in the end we see that both cores run on different revisions.
> >>
> >>
> > very interesting. I had overlooked that.
>
> Could you give the below patch a try?
>
> Jan
>
> x86/ucode: fix Intel case of resume handling on boot CPU
>
> Checking the stored version doesn't tell us anything about the need to
> apply the update (during resume, what is stored doesn't necessarily
> match what is loaded).
>
> Note that the check can be removed altogether because once switched to
> use what was read from the CPU (uci->cpu_sig.rev, as used in the
> subsequent pr_debug()), it would become redundant with the checks that
> lead to microcode_update_match() returning the indication that an
> update should be applied.
>
> Note further that this was not an issue on APs since they start with
> uci->mc.mc_intel being NULL.
>
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
>
> --- a/xen/arch/x86/microcode_intel.c
> +++ b/xen/arch/x86/microcode_intel.c
> @@ -261,8 +261,6 @@ static int get_matching_microcode(const
>      }
>      return 0;
>   find:
> -    if ( uci->mc.mc_intel && uci->mc.mc_intel->hdr.rev >= mc_header->rev )
> -        return 0;
>      pr_debug("microcode: CPU%d found a matching microcode update with"
>               " version %#x (current=%#x)\n",
>               cpu, mc_header->rev, uci->cpu_sig.rev);
>
>
>
>

--14dae93404350f56ef04cab0a70b
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

ACK.<div><br></div><div>I now see microcode updates for both CPUs.</div><di=
v><br></div><div><br></div><div><div>[ =A0 47.612719] Disabling non-boot CP=
Us ...</div><div>(XEN) Preparing system for ACPI S3 state.</div><div>(XEN) =
Disabling non-boot CPUs ...</div>
<div>(XEN) Breaking vcpu affinity for domain 0 vcpu 1</div><div>(XEN) Enter=
ing ACPI S3 state.</div><div>(XEN) mce_intel.c:1239: MCA Capability: BCAST =
1 SER 0 CMCI 0 firstbank 1 extended MCE MSR 0</div><div>(XEN) CMCI: CPU0 ha=
s no CMCI support</div>
<div>(XEN) CPU0: Thermal monitoring enabled (TM2)</div><div>(XEN) Finishing=
 wakeup from ACPI S3 state.</div><div>(XEN) microcode: CPU0 updated from re=
vision 0x60c to 0x60f, date =3D 2010-09-29=A0</div><div>(XEN) Enabling non-=
boot CPUs =A0...</div>
<div>(XEN) Booting processor 1/1 eip 8a000</div><div>(XEN) Initializing CPU=
#1</div><div>(XEN) CPU: L1 I cache: 32K, L1 D cache: 32K</div><div>(XEN) CP=
U: L2 cache: 3072K</div><div>(XEN) CPU: Physical Processor ID: 0</div><div>
(XEN) CPU: Processor Core ID: 1</div><div>(XEN) CMCI: CPU1 has no CMCI supp=
ort</div><div>(XEN) CPU1: Thermal monitoring enabled (TM2)</div><div>(XEN) =
CPU1: Intel(R) Core(TM)2 Duo CPU =A0 =A0 P8400 =A0@ 2.26GHz stepping 06</di=
v>
<div>(XEN) microcode: CPU1 updated from revision 0x60c to 0x60f, date =3D 2=
010-09-29=A0</div><div>[ =A0 47.720054] ACPI: Low-level resume complete</di=
v><div><br></div><br><div class=3D"gmail_quote">On Thu, Sep 27, 2012 at 11:=
25 AM, Jan Beulich <span dir=3D"ltr">&lt;<a href=3D"mailto:JBeulich@suse.co=
m" target=3D"_blank">JBeulich@suse.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 27.09.12 a=
t 14:12, Ben Guthro &lt;<a href=3D"mailto:ben@guthro.net">ben@guthro.net</a=
>&gt; wrote:<br>

&gt; On Thu, Sep 27, 2012 at 3:38 AM, Jan Beulich &lt;<a href=3D"mailto:JBe=
ulich@suse.com">JBeulich@suse.com</a>&gt; wrote:<br>
</div><div class=3D"im">&gt;&gt; &gt; (XEN) microcode: collect_cpu_info for=
 CPU0<br>
&gt;&gt; &gt; (XEN) microcode: collect_cpu_info : sig=3D0x10676, pf=3D0x80,=
 rev=3D0x60c<br>
&gt;&gt; &gt; (XEN) microcode: collect_cpu_info for CPU1<br>
&gt;&gt; &gt; (XEN) microcode: collect_cpu_info : sig=3D0x10676, pf=3D0x80,=
 rev=3D0x60f<br>
&gt;&gt;<br>
&gt;&gt; And in the end we see that both cores run on different revisions.<=
br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt; very interesting. I had overlooked that.<br>
<br>
</div>Could you give the below patch a try?<br>
<br>
Jan<br>
<br>
x86/ucode: fix Intel case of resume handling on boot CPU<br>
<br>
Checking the stored version doesn&#39;t tell us anything about the need to<=
br>
apply the update (during resume, what is stored doesn&#39;t necessarily<br>
match what is loaded).<br>
<br>
Note that the check can be removed altogether because once switched to<br>
use what was read from the CPU (uci-&gt;cpu_sig.rev, as used in the<br>
subsequent pr_debug()), it would become redundant with the checks that<br>
lead to microcode_update_match() returning the indication that an<br>
update should be applied.<br>
<br>
Note further that this was not an issue on APs since they start with<br>
uci-&gt;mc.mc_intel being NULL.<br>
<br>
Signed-off-by: Jan Beulich &lt;<a href=3D"mailto:jbeulich@suse.com">jbeulic=
h@suse.com</a>&gt;<br>
<br>
--- a/xen/arch/x86/microcode_intel.c<br>
+++ b/xen/arch/x86/microcode_intel.c<br>
@@ -261,8 +261,6 @@ static int get_matching_microcode(const<br>
=A0 =A0 =A0}<br>
=A0 =A0 =A0return 0;<br>
=A0 find:<br>
- =A0 =A0if ( uci-&gt;mc.mc_intel &amp;&amp; uci-&gt;mc.mc_intel-&gt;hdr.re=
v &gt;=3D mc_header-&gt;rev )<br>
- =A0 =A0 =A0 =A0return 0;<br>
=A0 =A0 =A0pr_debug(&quot;microcode: CPU%d found a matching microcode updat=
e with&quot;<br>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 &quot; version %#x (current=3D%#x)\n&quot;,<br>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 cpu, mc_header-&gt;rev, uci-&gt;cpu_sig.rev);<b=
r>
<br>
<br>
<br>
</blockquote></div><br></div>

--14dae93404350f56ef04cab0a70b--


--===============5080747942231164041==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============5080747942231164041==--


From xen-devel-bounces@lists.xen.org Thu Sep 27 15:33:09 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Sep 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 1THG5D-0001Da-C3; Thu, 27 Sep 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 <ben.guthro@gmail.com>) id 1THG5B-0001DH-Kd
	for xen-devel@lists.xen.org; Thu, 27 Sep 2012 15:32:57 +0000
Received: from [85.158.143.35:27949] by server-1.bemta-4.messagelabs.com id
	96/88-05684-8A174605; Thu, 27 Sep 2012 15:32:56 +0000
X-Env-Sender: ben.guthro@gmail.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1348759973!18746117!1
X-Originating-IP: [209.85.223.173]
X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_20_30,HTML_MESSAGE,
	RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2122 invoked from network); 27 Sep 2012 15:32:54 -0000
Received: from mail-ie0-f173.google.com (HELO mail-ie0-f173.google.com)
	(209.85.223.173)
	by server-13.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Sep 2012 15:32:54 -0000
Received: by iea17 with SMTP id 17so6027854iea.32
	for <xen-devel@lists.xen.org>; Thu, 27 Sep 2012 08:32:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
	bh=ydVJYTHNAdKRk7xfcxY55c0WatLfKVG4yV+kzqNGi3M=;
	b=igaMMDvufY7bNl1N1h/ZsI9Bq/uT+meys10j8f3W4QVpbjaiBhz1l1FamgxI81nJqE
	R8UGOfxCWn6A9qdhJwaOroa6bYM4u6WpLxGJ6u7NTQIYWAZ/4q1L06+0F55yZlpIcIne
	o6HzLmAX0z1KLN2k/DFJAcY04rQe+Gcyr3b32xWLOULlnio6bCgPgZZDfo4ECAlo65PL
	ZQFba+7mfDRvUBG0t6QlkPi3jzVJpaaJxUW+PvFXh0iejNluWrcMYhiDUquk5HkwpHod
	1BN0Mrn9ckzHUylq9Lcf2EJiVXyPwribUT/1z2VR1f/h3A3BpioiR5RauUtu7aNoEaG6
	rCdA==
MIME-Version: 1.0
Received: by 10.50.183.200 with SMTP id eo8mr14768381igc.54.1348759972697;
	Thu, 27 Sep 2012 08:32:52 -0700 (PDT)
Received: by 10.64.55.132 with HTTP; Thu, 27 Sep 2012 08:32:52 -0700 (PDT)
In-Reply-To: <50648C21020000780009E478@nat28.tlf.novell.com>
References: <CAOvdn6UCF2A3yP1cqWn=dxwr0ayRbr+rg+xj8META9Dm0+CoNw@mail.gmail.com>
	<CC868168.3FD29%keir.xen@gmail.com>
	<CAOvdn6U-JyLvt96gkLkqzi088tU9_ktv4D+fkJac_BKVe05Y-w@mail.gmail.com>
	<CAOvdn6V+s3AbRzsu8VArbmrZou=im9SqvPf-9Wpif_BrNMv=yg@mail.gmail.com>
	<50617297020000780009D8AA@nat28.tlf.novell.com>
	<CAOvdn6Vsnbcd7m8mh3tSgn3KaEoeiOyVD1mr3uQ3bN=rF=pDUQ@mail.gmail.com>
	<5062F880020000780009DF3B@nat28.tlf.novell.com>
	<CAOvdn6VyAVg24=c1OxqttxuGFyN_NzpfZ7RoCYc2mVF84c5big@mail.gmail.com>
	<50641E86020000780009E2E3@nat28.tlf.novell.com>
	<CAOvdn6VE13fOSjrKU4Ryr=344u+YwygASj6z1ag_U-x-qvOC9g@mail.gmail.com>
	<50648C21020000780009E478@nat28.tlf.novell.com>
Date: Thu, 27 Sep 2012 11:32:52 -0400
X-Google-Sender-Auth: OycRnc3xOJ1E6uRbSys9KNdWFFU
Message-ID: <CAOvdn6VKrPzWLdETq10ihytDjyOjK55ShnRnCS6V112aYE=VJg@mail.gmail.com>
From: Ben Guthro <ben@guthro.net>
To: Jan Beulich <JBeulich@suse.com>
Cc: Keir Fraser <keir.xen@gmail.com>, John Baboval <john.baboval@citrix.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Xen4.2 S3 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: multipart/mixed; boundary="===============5080747942231164041=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============5080747942231164041==
Content-Type: multipart/alternative; boundary=14dae93404350f56ef04cab0a70b

--14dae93404350f56ef04cab0a70b
Content-Type: text/plain; charset=ISO-8859-1

ACK.

I now see microcode updates for both CPUs.


[   47.612719] Disabling non-boot CPUs ...
(XEN) Preparing system for ACPI S3 state.
(XEN) Disabling non-boot CPUs ...
(XEN) Breaking vcpu affinity for domain 0 vcpu 1
(XEN) Entering ACPI S3 state.
(XEN) mce_intel.c:1239: MCA Capability: BCAST 1 SER 0 CMCI 0 firstbank 1
extended MCE MSR 0
(XEN) CMCI: CPU0 has no CMCI support
(XEN) CPU0: Thermal monitoring enabled (TM2)
(XEN) Finishing wakeup from ACPI S3 state.
(XEN) microcode: CPU0 updated from revision 0x60c to 0x60f, date =
2010-09-29
(XEN) Enabling non-boot CPUs  ...
(XEN) Booting processor 1/1 eip 8a000
(XEN) Initializing CPU#1
(XEN) CPU: L1 I cache: 32K, L1 D cache: 32K
(XEN) CPU: L2 cache: 3072K
(XEN) CPU: Physical Processor ID: 0
(XEN) CPU: Processor Core ID: 1
(XEN) CMCI: CPU1 has no CMCI support
(XEN) CPU1: Thermal monitoring enabled (TM2)
(XEN) CPU1: Intel(R) Core(TM)2 Duo CPU     P8400  @ 2.26GHz stepping 06
(XEN) microcode: CPU1 updated from revision 0x60c to 0x60f, date =
2010-09-29
[   47.720054] ACPI: Low-level resume complete


On Thu, Sep 27, 2012 at 11:25 AM, Jan Beulich <JBeulich@suse.com> wrote:

> >>> On 27.09.12 at 14:12, Ben Guthro <ben@guthro.net> wrote:
> > On Thu, Sep 27, 2012 at 3:38 AM, Jan Beulich <JBeulich@suse.com> wrote:
> >> > (XEN) microcode: collect_cpu_info for CPU0
> >> > (XEN) microcode: collect_cpu_info : sig=0x10676, pf=0x80, rev=0x60c
> >> > (XEN) microcode: collect_cpu_info for CPU1
> >> > (XEN) microcode: collect_cpu_info : sig=0x10676, pf=0x80, rev=0x60f
> >>
> >> And in the end we see that both cores run on different revisions.
> >>
> >>
> > very interesting. I had overlooked that.
>
> Could you give the below patch a try?
>
> Jan
>
> x86/ucode: fix Intel case of resume handling on boot CPU
>
> Checking the stored version doesn't tell us anything about the need to
> apply the update (during resume, what is stored doesn't necessarily
> match what is loaded).
>
> Note that the check can be removed altogether because once switched to
> use what was read from the CPU (uci->cpu_sig.rev, as used in the
> subsequent pr_debug()), it would become redundant with the checks that
> lead to microcode_update_match() returning the indication that an
> update should be applied.
>
> Note further that this was not an issue on APs since they start with
> uci->mc.mc_intel being NULL.
>
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
>
> --- a/xen/arch/x86/microcode_intel.c
> +++ b/xen/arch/x86/microcode_intel.c
> @@ -261,8 +261,6 @@ static int get_matching_microcode(const
>      }
>      return 0;
>   find:
> -    if ( uci->mc.mc_intel && uci->mc.mc_intel->hdr.rev >= mc_header->rev )
> -        return 0;
>      pr_debug("microcode: CPU%d found a matching microcode update with"
>               " version %#x (current=%#x)\n",
>               cpu, mc_header->rev, uci->cpu_sig.rev);
>
>
>
>

--14dae93404350f56ef04cab0a70b
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

ACK.<div><br></div><div>I now see microcode updates for both CPUs.</div><di=
v><br></div><div><br></div><div><div>[ =A0 47.612719] Disabling non-boot CP=
Us ...</div><div>(XEN) Preparing system for ACPI S3 state.</div><div>(XEN) =
Disabling non-boot CPUs ...</div>
<div>(XEN) Breaking vcpu affinity for domain 0 vcpu 1</div><div>(XEN) Enter=
ing ACPI S3 state.</div><div>(XEN) mce_intel.c:1239: MCA Capability: BCAST =
1 SER 0 CMCI 0 firstbank 1 extended MCE MSR 0</div><div>(XEN) CMCI: CPU0 ha=
s no CMCI support</div>
<div>(XEN) CPU0: Thermal monitoring enabled (TM2)</div><div>(XEN) Finishing=
 wakeup from ACPI S3 state.</div><div>(XEN) microcode: CPU0 updated from re=
vision 0x60c to 0x60f, date =3D 2010-09-29=A0</div><div>(XEN) Enabling non-=
boot CPUs =A0...</div>
<div>(XEN) Booting processor 1/1 eip 8a000</div><div>(XEN) Initializing CPU=
#1</div><div>(XEN) CPU: L1 I cache: 32K, L1 D cache: 32K</div><div>(XEN) CP=
U: L2 cache: 3072K</div><div>(XEN) CPU: Physical Processor ID: 0</div><div>
(XEN) CPU: Processor Core ID: 1</div><div>(XEN) CMCI: CPU1 has no CMCI supp=
ort</div><div>(XEN) CPU1: Thermal monitoring enabled (TM2)</div><div>(XEN) =
CPU1: Intel(R) Core(TM)2 Duo CPU =A0 =A0 P8400 =A0@ 2.26GHz stepping 06</di=
v>
<div>(XEN) microcode: CPU1 updated from revision 0x60c to 0x60f, date =3D 2=
010-09-29=A0</div><div>[ =A0 47.720054] ACPI: Low-level resume complete</di=
v><div><br></div><br><div class=3D"gmail_quote">On Thu, Sep 27, 2012 at 11:=
25 AM, Jan Beulich <span dir=3D"ltr">&lt;<a href=3D"mailto:JBeulich@suse.co=
m" target=3D"_blank">JBeulich@suse.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 27.09.12 a=
t 14:12, Ben Guthro &lt;<a href=3D"mailto:ben@guthro.net">ben@guthro.net</a=
>&gt; wrote:<br>

&gt; On Thu, Sep 27, 2012 at 3:38 AM, Jan Beulich &lt;<a href=3D"mailto:JBe=
ulich@suse.com">JBeulich@suse.com</a>&gt; wrote:<br>
</div><div class=3D"im">&gt;&gt; &gt; (XEN) microcode: collect_cpu_info for=
 CPU0<br>
&gt;&gt; &gt; (XEN) microcode: collect_cpu_info : sig=3D0x10676, pf=3D0x80,=
 rev=3D0x60c<br>
&gt;&gt; &gt; (XEN) microcode: collect_cpu_info for CPU1<br>
&gt;&gt; &gt; (XEN) microcode: collect_cpu_info : sig=3D0x10676, pf=3D0x80,=
 rev=3D0x60f<br>
&gt;&gt;<br>
&gt;&gt; And in the end we see that both cores run on different revisions.<=
br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt; very interesting. I had overlooked that.<br>
<br>
</div>Could you give the below patch a try?<br>
<br>
Jan<br>
<br>
x86/ucode: fix Intel case of resume handling on boot CPU<br>
<br>
Checking the stored version doesn&#39;t tell us anything about the need to<=
br>
apply the update (during resume, what is stored doesn&#39;t necessarily<br>
match what is loaded).<br>
<br>
Note that the check can be removed altogether because once switched to<br>
use what was read from the CPU (uci-&gt;cpu_sig.rev, as used in the<br>
subsequent pr_debug()), it would become redundant with the checks that<br>
lead to microcode_update_match() returning the indication that an<br>
update should be applied.<br>
<br>
Note further that this was not an issue on APs since they start with<br>
uci-&gt;mc.mc_intel being NULL.<br>
<br>
Signed-off-by: Jan Beulich &lt;<a href=3D"mailto:jbeulich@suse.com">jbeulic=
h@suse.com</a>&gt;<br>
<br>
--- a/xen/arch/x86/microcode_intel.c<br>
+++ b/xen/arch/x86/microcode_intel.c<br>
@@ -261,8 +261,6 @@ static int get_matching_microcode(const<br>
=A0 =A0 =A0}<br>
=A0 =A0 =A0return 0;<br>
=A0 find:<br>
- =A0 =A0if ( uci-&gt;mc.mc_intel &amp;&amp; uci-&gt;mc.mc_intel-&gt;hdr.re=
v &gt;=3D mc_header-&gt;rev )<br>
- =A0 =A0 =A0 =A0return 0;<br>
=A0 =A0 =A0pr_debug(&quot;microcode: CPU%d found a matching microcode updat=
e with&quot;<br>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 &quot; version %#x (current=3D%#x)\n&quot;,<br>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 cpu, mc_header-&gt;rev, uci-&gt;cpu_sig.rev);<b=
r>
<br>
<br>
<br>
</blockquote></div><br></div>

--14dae93404350f56ef04cab0a70b--


--===============5080747942231164041==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============5080747942231164041==--


From xen-devel-bounces@lists.xen.org Thu Sep 27 15:41:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Sep 2012 15:41: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 1THGCw-0001nC-Iz; Thu, 27 Sep 2012 15:40:58 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jordi.cucurull@scytl.com>) id 1THGCw-0001n7-5U
	for xen-devel@lists.xen.org; Thu, 27 Sep 2012 15:40:58 +0000
Received: from [85.158.137.99:46742] by server-10.bemta-3.messagelabs.com id
	C4/6E-02525-98374605; Thu, 27 Sep 2012 15:40:57 +0000
X-Env-Sender: jordi.cucurull@scytl.com
X-Msg-Ref: server-5.tower-217.messagelabs.com!1348760456!14641139!1
X-Originating-IP: [217.111.179.100]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18294 invoked from network); 27 Sep 2012 15:40:56 -0000
Received: from mail3.scytl.com (HELO mail3.scytl.com) (217.111.179.100)
	by server-5.tower-217.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 27 Sep 2012 15:40:56 -0000
Received: from [10.0.16.210] (217.111.178.66) by mail3.scytl.com (Axigen)
	with (DHE-RSA-CAMELLIA256-SHA encrypted) ESMTPSA id 1F8299;
	Thu, 27 Sep 2012 17:40:55 +0200
Message-ID: <50647387.5080607@scytl.com>
Date: Thu, 27 Sep 2012 17:40:55 +0200
From: Jordi Cucurull Juan <jordi.cucurull@scytl.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0)
	Gecko/20120721 Thunderbird/14.0
MIME-Version: 1.0
To: xen-devel@lists.xen.org
X-AxigenSpam-Level: 5
Cc: Jordi Cucurull Juan <jordi.cucurull@scytl.com>
Subject: [Xen-devel] Compile Xen with VTPM support
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Dear all,

I am trying to compile Xen 4.2.0 with VTPM support. The documentation 
available inside Xen is from 2006. I am wondering if the current steps 
to enable VTPM support are the same written in the documentation or they 
have changed.

Is it enough with setting the "--enable-vtpm" argument during the 
configure process? Furthermore, at that time Xen was providing the Linux 
Kernel as part of its sources. Have the current kernels to be patched to 
include the Xen VTPM drivers? If it is the case, where can we find the 
patches?

Thank you in advance!
Jordi.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 27 15:41:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Sep 2012 15:41: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 1THGCw-0001nC-Iz; Thu, 27 Sep 2012 15:40:58 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jordi.cucurull@scytl.com>) id 1THGCw-0001n7-5U
	for xen-devel@lists.xen.org; Thu, 27 Sep 2012 15:40:58 +0000
Received: from [85.158.137.99:46742] by server-10.bemta-3.messagelabs.com id
	C4/6E-02525-98374605; Thu, 27 Sep 2012 15:40:57 +0000
X-Env-Sender: jordi.cucurull@scytl.com
X-Msg-Ref: server-5.tower-217.messagelabs.com!1348760456!14641139!1
X-Originating-IP: [217.111.179.100]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18294 invoked from network); 27 Sep 2012 15:40:56 -0000
Received: from mail3.scytl.com (HELO mail3.scytl.com) (217.111.179.100)
	by server-5.tower-217.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 27 Sep 2012 15:40:56 -0000
Received: from [10.0.16.210] (217.111.178.66) by mail3.scytl.com (Axigen)
	with (DHE-RSA-CAMELLIA256-SHA encrypted) ESMTPSA id 1F8299;
	Thu, 27 Sep 2012 17:40:55 +0200
Message-ID: <50647387.5080607@scytl.com>
Date: Thu, 27 Sep 2012 17:40:55 +0200
From: Jordi Cucurull Juan <jordi.cucurull@scytl.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0)
	Gecko/20120721 Thunderbird/14.0
MIME-Version: 1.0
To: xen-devel@lists.xen.org
X-AxigenSpam-Level: 5
Cc: Jordi Cucurull Juan <jordi.cucurull@scytl.com>
Subject: [Xen-devel] Compile Xen with VTPM support
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Dear all,

I am trying to compile Xen 4.2.0 with VTPM support. The documentation 
available inside Xen is from 2006. I am wondering if the current steps 
to enable VTPM support are the same written in the documentation or they 
have changed.

Is it enough with setting the "--enable-vtpm" argument during the 
configure process? Furthermore, at that time Xen was providing the Linux 
Kernel as part of its sources. Have the current kernels to be patched to 
include the Xen VTPM drivers? If it is the case, where can we find the 
patches?

Thank you in advance!
Jordi.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 27 15:44:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Sep 2012 15: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 1THGGR-0001uN-7P; Thu, 27 Sep 2012 15:44:35 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <matthew.fioravante@jhuapl.edu>) id 1THGGP-0001uH-Ve
	for xen-devel@lists.xen.org; Thu, 27 Sep 2012 15:44:34 +0000
Received: from [85.158.138.51:60433] by server-15.bemta-3.messagelabs.com id
	40/DC-18313-16474605; Thu, 27 Sep 2012 15:44:33 +0000
X-Env-Sender: matthew.fioravante@jhuapl.edu
X-Msg-Ref: server-6.tower-174.messagelabs.com!1348760671!24193730!1
X-Originating-IP: [128.244.251.36]
X-SpamReason: No, hits=0.0 required=7.0 tests=UNPARSEABLE_RELAY
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20196 invoked from network); 27 Sep 2012 15:44:32 -0000
Received: from pilot.jhuapl.edu (HELO jhuapl.edu) (128.244.251.36)
	by server-6.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 27 Sep 2012 15:44:32 -0000
Received: from ([128.244.207.89])
	by pilot.jhuapl.edu with ESMTP with TLS id 63GHCH1.153794388;
	Thu, 27 Sep 2012 11:44:26 -0400
Message-ID: <5064740B.5030402@jhuapl.edu>
Date: Thu, 27 Sep 2012 11:43:07 -0400
From: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120827 Thunderbird/15.0
MIME-Version: 1.0
To: Jordi Cucurull Juan <jordi.cucurull@scytl.com>
References: <50647387.5080607@scytl.com>
In-Reply-To: <50647387.5080607@scytl.com>
X-Enigmail-Version: 1.4.4
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Compile Xen with VTPM support
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0802754678943858608=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a cryptographically signed message in MIME format.

--===============0802754678943858608==
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms070906060700070906070601"

This is a cryptographically signed message in MIME format.

--------------ms070906060700070906070601
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

The current (old) vtpm implementation still sort of works. You have to
use xm and find a linux kernel with the tpmfront and tpmback drivers. I
believe the original xen 2.6.18 kernel has them. There may or may not be
newer kernels with these drivers.

docs/misc/vtpm.txt should have everything you need to use it.

That being said I'm in the process of submitting my new vtpm
implementation. So keep an eye on that activity if you're interested.

On 09/27/2012 11:40 AM, Jordi Cucurull Juan wrote:
> Dear all,
>
> I am trying to compile Xen 4.2.0 with VTPM support. The documentation=20
> available inside Xen is from 2006. I am wondering if the current steps =

> to enable VTPM support are the same written in the documentation or the=
y=20
> have changed.
>
> Is it enough with setting the "--enable-vtpm" argument during the=20
> configure process? Furthermore, at that time Xen was providing the Linu=
x=20
> Kernel as part of its sources. Have the current kernels to be patched t=
o=20
> include the Xen VTPM drivers? If it is the case, where can we find the =

> patches?
>
> Thank you in advance!
> Jordi.
>
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel



--------------ms070906060700070906070601
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIDyjCC
A8YwggMvoAMCAQICBD/xyf0wDQYJKoZIhvcNAQEFBQAwLzELMAkGA1UEBhMCVVMxDzANBgNV
BAoTBkpIVUFQTDEPMA0GA1UECxMGQklTRENBMB4XDTEwMDYxMTE4MjIwNloXDTEzMDYxMTE4
NTIwNlowZjELMAkGA1UEBhMCVVMxDzANBgNVBAoTBkpIVUFQTDEPMA0GA1UECxMGUGVvcGxl
MTUwFgYDVQQLEw9WUE5Hcm91cC1CSVNEQ0EwGwYDVQQDExRNYXR0aGV3IEUgRmlvcmF2YW50
ZTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAnpbwVSP6o1Nb5lcW7dd3yTo9iBJdi7qz
4nANOMFPK7JOy5npKN1iiousl28U/scUJES55gPwAWYJK3uVyQAsA4adgDKi5DoD1UHDQEwp
bY7iHLJeq0NPr4BqYNqnCFPbE6HC8zSJrr4qKn+gVUQT39SIFqdiIPJwZL8FYTRQ/zsCAwEA
AaOCAbYwggGyMAsGA1UdDwQEAwIHgDArBgNVHRAEJDAigA8yMDEwMDYxMTE4MjIwNlqBDzIw
MTIwNzE3MjI1MjA2WjAbBg0rBgEEAbMlCwMBAQEBBAoWCGZpb3JhbWUxMBsGDSsGAQQBsyUL
AwEBAQIEChIIMDAxMDQyNjEwWAYJYIZIAYb6ax4BBEsMSVRoZSBwcml2YXRlIGtleSBjb3Jy
ZXNwb25kaW5nIHRvIHRoaXMgY2VydGlmaWNhdGUgbWF5IGhhdmUgYmVlbiBleHBvcnRlZC4w
KAYDVR0RBCEwH4EdTWF0dGhldy5GaW9yYXZhbnRlQGpodWFwbC5lZHUwUgYDVR0fBEswSTBH
oEWgQ6RBMD8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJU0RD
QTEOMAwGA1UEAxMFQ1JMNTYwHwYDVR0jBBgwFoAUCDUpmxH52EU2CyWmF2EJMB1yqeswHQYD
VR0OBBYEFO6LYxg6r9wHZ+zdQtBHn1dZ/YTNMAkGA1UdEwQCMAAwGQYJKoZIhvZ9B0EABAww
ChsEVjcuMQMCBLAwDQYJKoZIhvcNAQEFBQADgYEAJO9HQh4YNChVLzuZqK5ARJARD8JoujGZ
fdo75quvg2jXFQe2sEjvLnxJZgm/pv8fdZakq48CWwjYHKuvIp7sDjTEsQfo+y7SpN/N2NvJ
WU5SqfK1VgYtNLRRoGJUB5Q1aZ+Dg95g3kqpyfpUMISJL8IKVLtJVfN4fggFVUYZ9wwxggGr
MIIBpwIBATA3MC8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJ
U0RDQQIEP/HJ/TAJBgUrDgMCGgUAoIHLMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ
KoZIhvcNAQkFMQ8XDTEyMDkyNzE1NDMwN1owIwYJKoZIhvcNAQkEMRYEFFTDxh5X/NDhDc9G
0ehCJiNndab9MGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAK
BggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI
KoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEgYCOW8qgLnPIrxFCJoXvi8HtSKnUperY/SBF
c6Jk5l2g+uN+NfRWEF4QqnLCyhZ3WUHbOE0P2FcvdUZO/kUm9uJO+YLNn5j4uSyMLzR7ixlG
KqKT7Gh2qE3KZJdAc25f4sg78+PBLSuku4JzaLAQ3tVOf4yRuLzGzcAG4VojNtzGhQAAAAAA
AA==
--------------ms070906060700070906070601--


--===============0802754678943858608==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============0802754678943858608==--


From xen-devel-bounces@lists.xen.org Thu Sep 27 15:44:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Sep 2012 15: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 1THGGR-0001uN-7P; Thu, 27 Sep 2012 15:44:35 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <matthew.fioravante@jhuapl.edu>) id 1THGGP-0001uH-Ve
	for xen-devel@lists.xen.org; Thu, 27 Sep 2012 15:44:34 +0000
Received: from [85.158.138.51:60433] by server-15.bemta-3.messagelabs.com id
	40/DC-18313-16474605; Thu, 27 Sep 2012 15:44:33 +0000
X-Env-Sender: matthew.fioravante@jhuapl.edu
X-Msg-Ref: server-6.tower-174.messagelabs.com!1348760671!24193730!1
X-Originating-IP: [128.244.251.36]
X-SpamReason: No, hits=0.0 required=7.0 tests=UNPARSEABLE_RELAY
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20196 invoked from network); 27 Sep 2012 15:44:32 -0000
Received: from pilot.jhuapl.edu (HELO jhuapl.edu) (128.244.251.36)
	by server-6.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 27 Sep 2012 15:44:32 -0000
Received: from ([128.244.207.89])
	by pilot.jhuapl.edu with ESMTP with TLS id 63GHCH1.153794388;
	Thu, 27 Sep 2012 11:44:26 -0400
Message-ID: <5064740B.5030402@jhuapl.edu>
Date: Thu, 27 Sep 2012 11:43:07 -0400
From: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120827 Thunderbird/15.0
MIME-Version: 1.0
To: Jordi Cucurull Juan <jordi.cucurull@scytl.com>
References: <50647387.5080607@scytl.com>
In-Reply-To: <50647387.5080607@scytl.com>
X-Enigmail-Version: 1.4.4
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Compile Xen with VTPM support
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0802754678943858608=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a cryptographically signed message in MIME format.

--===============0802754678943858608==
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms070906060700070906070601"

This is a cryptographically signed message in MIME format.

--------------ms070906060700070906070601
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

The current (old) vtpm implementation still sort of works. You have to
use xm and find a linux kernel with the tpmfront and tpmback drivers. I
believe the original xen 2.6.18 kernel has them. There may or may not be
newer kernels with these drivers.

docs/misc/vtpm.txt should have everything you need to use it.

That being said I'm in the process of submitting my new vtpm
implementation. So keep an eye on that activity if you're interested.

On 09/27/2012 11:40 AM, Jordi Cucurull Juan wrote:
> Dear all,
>
> I am trying to compile Xen 4.2.0 with VTPM support. The documentation=20
> available inside Xen is from 2006. I am wondering if the current steps =

> to enable VTPM support are the same written in the documentation or the=
y=20
> have changed.
>
> Is it enough with setting the "--enable-vtpm" argument during the=20
> configure process? Furthermore, at that time Xen was providing the Linu=
x=20
> Kernel as part of its sources. Have the current kernels to be patched t=
o=20
> include the Xen VTPM drivers? If it is the case, where can we find the =

> patches?
>
> Thank you in advance!
> Jordi.
>
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel



--------------ms070906060700070906070601
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIDyjCC
A8YwggMvoAMCAQICBD/xyf0wDQYJKoZIhvcNAQEFBQAwLzELMAkGA1UEBhMCVVMxDzANBgNV
BAoTBkpIVUFQTDEPMA0GA1UECxMGQklTRENBMB4XDTEwMDYxMTE4MjIwNloXDTEzMDYxMTE4
NTIwNlowZjELMAkGA1UEBhMCVVMxDzANBgNVBAoTBkpIVUFQTDEPMA0GA1UECxMGUGVvcGxl
MTUwFgYDVQQLEw9WUE5Hcm91cC1CSVNEQ0EwGwYDVQQDExRNYXR0aGV3IEUgRmlvcmF2YW50
ZTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAnpbwVSP6o1Nb5lcW7dd3yTo9iBJdi7qz
4nANOMFPK7JOy5npKN1iiousl28U/scUJES55gPwAWYJK3uVyQAsA4adgDKi5DoD1UHDQEwp
bY7iHLJeq0NPr4BqYNqnCFPbE6HC8zSJrr4qKn+gVUQT39SIFqdiIPJwZL8FYTRQ/zsCAwEA
AaOCAbYwggGyMAsGA1UdDwQEAwIHgDArBgNVHRAEJDAigA8yMDEwMDYxMTE4MjIwNlqBDzIw
MTIwNzE3MjI1MjA2WjAbBg0rBgEEAbMlCwMBAQEBBAoWCGZpb3JhbWUxMBsGDSsGAQQBsyUL
AwEBAQIEChIIMDAxMDQyNjEwWAYJYIZIAYb6ax4BBEsMSVRoZSBwcml2YXRlIGtleSBjb3Jy
ZXNwb25kaW5nIHRvIHRoaXMgY2VydGlmaWNhdGUgbWF5IGhhdmUgYmVlbiBleHBvcnRlZC4w
KAYDVR0RBCEwH4EdTWF0dGhldy5GaW9yYXZhbnRlQGpodWFwbC5lZHUwUgYDVR0fBEswSTBH
oEWgQ6RBMD8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJU0RD
QTEOMAwGA1UEAxMFQ1JMNTYwHwYDVR0jBBgwFoAUCDUpmxH52EU2CyWmF2EJMB1yqeswHQYD
VR0OBBYEFO6LYxg6r9wHZ+zdQtBHn1dZ/YTNMAkGA1UdEwQCMAAwGQYJKoZIhvZ9B0EABAww
ChsEVjcuMQMCBLAwDQYJKoZIhvcNAQEFBQADgYEAJO9HQh4YNChVLzuZqK5ARJARD8JoujGZ
fdo75quvg2jXFQe2sEjvLnxJZgm/pv8fdZakq48CWwjYHKuvIp7sDjTEsQfo+y7SpN/N2NvJ
WU5SqfK1VgYtNLRRoGJUB5Q1aZ+Dg95g3kqpyfpUMISJL8IKVLtJVfN4fggFVUYZ9wwxggGr
MIIBpwIBATA3MC8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJ
U0RDQQIEP/HJ/TAJBgUrDgMCGgUAoIHLMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ
KoZIhvcNAQkFMQ8XDTEyMDkyNzE1NDMwN1owIwYJKoZIhvcNAQkEMRYEFFTDxh5X/NDhDc9G
0ehCJiNndab9MGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAK
BggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI
KoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEgYCOW8qgLnPIrxFCJoXvi8HtSKnUperY/SBF
c6Jk5l2g+uN+NfRWEF4QqnLCyhZ3WUHbOE0P2FcvdUZO/kUm9uJO+YLNn5j4uSyMLzR7ixlG
KqKT7Gh2qE3KZJdAc25f4sg78+PBLSuku4JzaLAQ3tVOf4yRuLzGzcAG4VojNtzGhQAAAAAA
AA==
--------------ms070906060700070906070601--


--===============0802754678943858608==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============0802754678943858608==--


From xen-devel-bounces@lists.xen.org Thu Sep 27 15:50:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Sep 2012 15:50:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1THGLX-00024q-WA; Thu, 27 Sep 2012 15:49:51 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <oliver.chick@citrix.com>) id 1THGLW-00024j-0w
	for xen-devel@lists.xen.org; Thu, 27 Sep 2012 15:49:50 +0000
Received: from [85.158.143.99:42479] by server-1.bemta-4.messagelabs.com id
	78/4F-05684-D9574605; Thu, 27 Sep 2012 15:49:49 +0000
X-Env-Sender: oliver.chick@citrix.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1348760988!31685805!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTE5OTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13956 invoked from network); 27 Sep 2012 15:49:48 -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;
	27 Sep 2012 15:49:48 -0000
X-IronPort-AV: E=Sophos;i="4.80,496,1344211200"; d="scan'208";a="14810385"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Sep 2012 15:49:22 +0000
Received: from [10.80.2.50] (10.80.2.50) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Thu, 27 Sep 2012 16:49:22 +0100
Message-ID: <1348760961.2371.8.camel@oliverchick-Precision-WorkStation-T3400>
From: Oliver Chick <oliver.chick@citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Thu, 27 Sep 2012 16:49:21 +0100
In-Reply-To: <20120921184123.GA27502@phenom.dumpdata.com>
References: <1348242767-23732-1-git-send-email-oliver.chick@citrix.com>
	<20120921184123.GA27502@phenom.dumpdata.com>
X-Mailer: Evolution 3.2.3-0ubuntu6 
MIME-Version: 1.0
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v2] Persistent grant maps for xen blk drivers
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi Konrad,

I have applied my patch to your #linux-next, and compiled. I don't
experience the same problem that you do - both PV and HVM boot and work.

Do you have anything special in your setup that might help me reproduce
the problem?


On Fri, 2012-09-21 at 19:41 +0100, Konrad Rzeszutek Wilk wrote:
> On Fri, Sep 21, 2012 at 04:52:47PM +0100, Oliver Chick wrote:
> > This patch implements persistent grants for the xen-blk{front,back}
> > mechanism. The effect of this change is to reduce the number of unmap
> > operations performed, since they cause a (costly) TLB shootdown. This
> > allows the I/O performance to scale better when a large number of VMs
> > are performing I/O.
> 
> So I applied your patch to my #linux-next and I got this (the dom0 is the
> same as the domU)
> I get this when using an PVHVM (*)and PV guest:
> # fdisk /dev/xvda
> [   28.594049] BUG: unable to handle kernel NULL pointer dereference at 0000000000000008
> [   28.595028] IP: [<ffffffffa003fe9a>] blkif_interrupt+0x3aa/0x5d0 [xen_blkfront]
> [   28.595028] PGD dcaf0067 PUD 7fb5e067 PMD 0 
> [   28.595028] Oops: 0000 [#1] SMP 
> [   28.595028] Modules linked in: iscsi_boot_sysfs iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi libcrc32c crc32c sg sr_mod cdrom ata_generic ata_piix crc32c_intel libata scsi_mod xen_blkfront xen_netfront fb_sys_fops sysimgblt sysfillrect syscopyarea xen_kbdfront xenfs xen_privcmd [last unloaded: dump_dma]
> [   28.595028] CPU 0 
> [   28.595028] Pid: 0, comm: swapper/0 Tainted: G           O 3.6.0-rc6upstream-00196-ge45cba2 #1 Xen HVM domU
> [   28.595028] RIP: 0010:[<ffffffffa003fe9a>]  [<ffffffffa003fe9a>] blkif_interrupt+0x3aa/0x5d0 [xen_blkfront]
> [   28.595028] RSP: 0018:ffff88010fc03da8  EFLAGS: 00010002
> [   28.595028] RAX: 0000000000000000 RBX: ffffffff81a00000 RCX: ffff88010af5f140
> [   28.595028] RDX: ffff88010af5f080 RSI: ffff8800dbbf8210 RDI: ffff8800dc679c00
> [   28.595028] RBP: ffff88010fc03e28 R08: 0000000000000001 R09: 0000000000000011
> [   28.595028] R10: 0000000000000000 R11: 0000000000000000 R12: 6db6db6db6db6db7
> [   28.595028] R13: ffff88010af5f1a8 R14: 0000000000000004 R15: 0000000000000000
> [   28.595028] FS:  0000000000000000(0000) GS:ffff88010fc00000(0000) knlGS:0000000000000000
> [   28.595028] CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
> [   28.595028] CR2: 0000000000000008 CR3: 00000000d4ac0000 CR4: 00000000000006f0
> [   28.595028] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> [   28.595028] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
> [   28.595028] Process swapper/0 (pid: 0, threadinfo ffffffff81a00000, task ffffffff81a13420)
> [   28.595028] Stack:
> [   28.595028]  0000000000000086 ffff8800d9951060 ffff8800d9953000 0000000881376d09
> [   28.595028]  0000000000000008 0000000a81376f2d 0000000000000000 ffff8800dbbf8210
> [   28.595028]  ffff8800dbbf8000 ffff88010af5f140 ffff88010fc03e08 ffff8800dcc4e3c0
> [   28.595028] Call Trace:
> [   28.595028]  <IRQ> 
> [   28.595028]  [<ffffffff8110dcdc>] handle_irq_event_percpu+0x7c/0x240
> [   28.595028]  [<ffffffff8110df02>] handle_irq_event+0x62/0x90
> [   28.595028]  [<ffffffff8111178e>] handle_edge_irq+0x8e/0x160
> [   28.595028]  [<ffffffff81376ac4>] __xen_evtchn_do_upcall+0x1c4/0x2a0
> [   28.595028]  [<ffffffff813775ba>] xen_evtchn_do_upcall+0x2a/0x40
> [   28.595028]  [<ffffffff816314ba>] xen_hvm_callback_vector+0x6a/0x70
> [   28.595028]  <EOI> 
> [   28.595028]  [<ffffffff8107b3a6>] ? native_safe_halt+0x6/0x10
> [   28.595028]  [<ffffffff810555da>] default_idle+0x4a/0x210
> [   28.595028]  [<ffffffff81054d79>] cpu_idle+0x99/0xe0
> [   28.595028]  [<ffffffff816015da>] rest_init+0x8a/0xa0
> [   28.595028]  [<ffffffff81abcd72>] start_kernel+0x383/0x390
> [   28.595028]  [<ffffffff81abc80d>] ? kernel_init+0x1e8/0x1e8
> [   28.595028]  [<ffffffff81abc356>] x86_64_start_reservations+0x131/0x136
> [   28.595028]  [<ffffffff81abc45e>] x86_64_start_kernel+0x103/0x112
> [   28.595028] Code: 00 49 83 c5 10 41 8b 45 08 41 03 45 0c 3d 00 10 00 00 0f 87 7e 01 00 00 48 8b 75 b8 49 63 c6 41 83 c6 01 48 8b 84 c6 d0 00 00 00 <48> 8b 40 08 83 43 1c 01 48 8d 14 c5 00 00 00 00 48 c1 e0 06 48 
> [   28.595028] RIP  [<ffffffffa003fe9a>] blkif_interrupt+0x3aa/0x5d0 [xen_blkfront]
> [   28.595028]  RSP <ffff88010fc03da8>
> [   28.595028] CR2: 0000000000000008
> [   28.595028] ---[ end trace 49f5630a34777570 ]---
> [   28.595028] Kernel panic - not syncing: Fatal exception in interrupt
> [   28.595028] Rebooting in 60 seconds..
> 
> *: With a PVHVM guest I get
> 
> [  261.927218] privcmd_fault: vma=ffff88002a31dce8 7f4edc095000-7f4edc195000, pgoff=c8, uv=00007f4edc15d000
> 
> thought if I applied your patch on top of v3.6-rc6 I didn't see the privcmd_fault but
> I did see the guest crash.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 27 15:50:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Sep 2012 15:50:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1THGLX-00024q-WA; Thu, 27 Sep 2012 15:49:51 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <oliver.chick@citrix.com>) id 1THGLW-00024j-0w
	for xen-devel@lists.xen.org; Thu, 27 Sep 2012 15:49:50 +0000
Received: from [85.158.143.99:42479] by server-1.bemta-4.messagelabs.com id
	78/4F-05684-D9574605; Thu, 27 Sep 2012 15:49:49 +0000
X-Env-Sender: oliver.chick@citrix.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1348760988!31685805!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTE5OTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13956 invoked from network); 27 Sep 2012 15:49:48 -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;
	27 Sep 2012 15:49:48 -0000
X-IronPort-AV: E=Sophos;i="4.80,496,1344211200"; d="scan'208";a="14810385"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Sep 2012 15:49:22 +0000
Received: from [10.80.2.50] (10.80.2.50) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.279.1;
	Thu, 27 Sep 2012 16:49:22 +0100
Message-ID: <1348760961.2371.8.camel@oliverchick-Precision-WorkStation-T3400>
From: Oliver Chick <oliver.chick@citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Thu, 27 Sep 2012 16:49:21 +0100
In-Reply-To: <20120921184123.GA27502@phenom.dumpdata.com>
References: <1348242767-23732-1-git-send-email-oliver.chick@citrix.com>
	<20120921184123.GA27502@phenom.dumpdata.com>
X-Mailer: Evolution 3.2.3-0ubuntu6 
MIME-Version: 1.0
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH v2] Persistent grant maps for xen blk drivers
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Hi Konrad,

I have applied my patch to your #linux-next, and compiled. I don't
experience the same problem that you do - both PV and HVM boot and work.

Do you have anything special in your setup that might help me reproduce
the problem?


On Fri, 2012-09-21 at 19:41 +0100, Konrad Rzeszutek Wilk wrote:
> On Fri, Sep 21, 2012 at 04:52:47PM +0100, Oliver Chick wrote:
> > This patch implements persistent grants for the xen-blk{front,back}
> > mechanism. The effect of this change is to reduce the number of unmap
> > operations performed, since they cause a (costly) TLB shootdown. This
> > allows the I/O performance to scale better when a large number of VMs
> > are performing I/O.
> 
> So I applied your patch to my #linux-next and I got this (the dom0 is the
> same as the domU)
> I get this when using an PVHVM (*)and PV guest:
> # fdisk /dev/xvda
> [   28.594049] BUG: unable to handle kernel NULL pointer dereference at 0000000000000008
> [   28.595028] IP: [<ffffffffa003fe9a>] blkif_interrupt+0x3aa/0x5d0 [xen_blkfront]
> [   28.595028] PGD dcaf0067 PUD 7fb5e067 PMD 0 
> [   28.595028] Oops: 0000 [#1] SMP 
> [   28.595028] Modules linked in: iscsi_boot_sysfs iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi libcrc32c crc32c sg sr_mod cdrom ata_generic ata_piix crc32c_intel libata scsi_mod xen_blkfront xen_netfront fb_sys_fops sysimgblt sysfillrect syscopyarea xen_kbdfront xenfs xen_privcmd [last unloaded: dump_dma]
> [   28.595028] CPU 0 
> [   28.595028] Pid: 0, comm: swapper/0 Tainted: G           O 3.6.0-rc6upstream-00196-ge45cba2 #1 Xen HVM domU
> [   28.595028] RIP: 0010:[<ffffffffa003fe9a>]  [<ffffffffa003fe9a>] blkif_interrupt+0x3aa/0x5d0 [xen_blkfront]
> [   28.595028] RSP: 0018:ffff88010fc03da8  EFLAGS: 00010002
> [   28.595028] RAX: 0000000000000000 RBX: ffffffff81a00000 RCX: ffff88010af5f140
> [   28.595028] RDX: ffff88010af5f080 RSI: ffff8800dbbf8210 RDI: ffff8800dc679c00
> [   28.595028] RBP: ffff88010fc03e28 R08: 0000000000000001 R09: 0000000000000011
> [   28.595028] R10: 0000000000000000 R11: 0000000000000000 R12: 6db6db6db6db6db7
> [   28.595028] R13: ffff88010af5f1a8 R14: 0000000000000004 R15: 0000000000000000
> [   28.595028] FS:  0000000000000000(0000) GS:ffff88010fc00000(0000) knlGS:0000000000000000
> [   28.595028] CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
> [   28.595028] CR2: 0000000000000008 CR3: 00000000d4ac0000 CR4: 00000000000006f0
> [   28.595028] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> [   28.595028] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
> [   28.595028] Process swapper/0 (pid: 0, threadinfo ffffffff81a00000, task ffffffff81a13420)
> [   28.595028] Stack:
> [   28.595028]  0000000000000086 ffff8800d9951060 ffff8800d9953000 0000000881376d09
> [   28.595028]  0000000000000008 0000000a81376f2d 0000000000000000 ffff8800dbbf8210
> [   28.595028]  ffff8800dbbf8000 ffff88010af5f140 ffff88010fc03e08 ffff8800dcc4e3c0
> [   28.595028] Call Trace:
> [   28.595028]  <IRQ> 
> [   28.595028]  [<ffffffff8110dcdc>] handle_irq_event_percpu+0x7c/0x240
> [   28.595028]  [<ffffffff8110df02>] handle_irq_event+0x62/0x90
> [   28.595028]  [<ffffffff8111178e>] handle_edge_irq+0x8e/0x160
> [   28.595028]  [<ffffffff81376ac4>] __xen_evtchn_do_upcall+0x1c4/0x2a0
> [   28.595028]  [<ffffffff813775ba>] xen_evtchn_do_upcall+0x2a/0x40
> [   28.595028]  [<ffffffff816314ba>] xen_hvm_callback_vector+0x6a/0x70
> [   28.595028]  <EOI> 
> [   28.595028]  [<ffffffff8107b3a6>] ? native_safe_halt+0x6/0x10
> [   28.595028]  [<ffffffff810555da>] default_idle+0x4a/0x210
> [   28.595028]  [<ffffffff81054d79>] cpu_idle+0x99/0xe0
> [   28.595028]  [<ffffffff816015da>] rest_init+0x8a/0xa0
> [   28.595028]  [<ffffffff81abcd72>] start_kernel+0x383/0x390
> [   28.595028]  [<ffffffff81abc80d>] ? kernel_init+0x1e8/0x1e8
> [   28.595028]  [<ffffffff81abc356>] x86_64_start_reservations+0x131/0x136
> [   28.595028]  [<ffffffff81abc45e>] x86_64_start_kernel+0x103/0x112
> [   28.595028] Code: 00 49 83 c5 10 41 8b 45 08 41 03 45 0c 3d 00 10 00 00 0f 87 7e 01 00 00 48 8b 75 b8 49 63 c6 41 83 c6 01 48 8b 84 c6 d0 00 00 00 <48> 8b 40 08 83 43 1c 01 48 8d 14 c5 00 00 00 00 48 c1 e0 06 48 
> [   28.595028] RIP  [<ffffffffa003fe9a>] blkif_interrupt+0x3aa/0x5d0 [xen_blkfront]
> [   28.595028]  RSP <ffff88010fc03da8>
> [   28.595028] CR2: 0000000000000008
> [   28.595028] ---[ end trace 49f5630a34777570 ]---
> [   28.595028] Kernel panic - not syncing: Fatal exception in interrupt
> [   28.595028] Rebooting in 60 seconds..
> 
> *: With a PVHVM guest I get
> 
> [  261.927218] privcmd_fault: vma=ffff88002a31dce8 7f4edc095000-7f4edc195000, pgoff=c8, uv=00007f4edc15d000
> 
> thought if I applied your patch on top of v3.6-rc6 I didn't see the privcmd_fault but
> I did see the guest crash.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 27 15:52:55 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Sep 2012 15:52: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 1THGOG-0002CA-IY; Thu, 27 Sep 2012 15:52:40 +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 1THGOE-0002C2-7D
	for xen-devel@lists.xen.org; Thu, 27 Sep 2012 15:52:38 +0000
Received: from [85.158.139.211:23288] by server-14.bemta-5.messagelabs.com id
	CA/2D-05772-54674605; Thu, 27 Sep 2012 15:52:37 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-13.tower-206.messagelabs.com!1348761154!16233975!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzE5Njc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32388 invoked from network); 27 Sep 2012 15:52:36 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-13.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Sep 2012 15:52:36 -0000
X-IronPort-AV: E=Sophos;i="4.80,496,1344211200"; d="scan'208";a="39399154"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Sep 2012 15:49:18 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1;
	Thu, 27 Sep 2012 11:49:18 -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 1THG62-0004nt-FI	for
	xen-devel@lists.xen.org; Thu, 27 Sep 2012 16:33:50 +0100
Message-ID: <506471DE.4090708@citrix.com>
Date: Thu, 27 Sep 2012 16:33:50 +0100
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120912 Thunderbird/15.0.1
MIME-Version: 1.0
To: xen-devel@lists.xen.org
References: <506483CC020000780009E42C@nat28.tlf.novell.com>
	<5064695B.1010805@citrix.com>
	<50648725020000780009E462@nat28.tlf.novell.com>
In-Reply-To: <50648725020000780009E462@nat28.tlf.novell.com>
X-Enigmail-Version: 1.4.4
Subject: Re: [Xen-devel] [PATCH] x86/IRQ: fix valid-old-vector checks in
	__assign_irq_vector()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/09/12 16:04, Jan Beulich wrote:
>>>> On 27.09.12 at 16:57, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
>> On 27/09/12 15:50, Jan Beulich wrote:
>>> There are two greater-than-zero checks for the old vector retrieved,
>>> which don't work when a negative value got stashed into the respective
>>> arch_irq_desc field. The effect of this was that for interrupts that
>>> are intended to get their affinity adjusted the first time before the
>>> first interrupt occurs, the affinity change would fail, because the
>>> original vector assignment would have caused the move_in_progress flag
>>> to get set (which causes subsequent re-assignments to fail until it
>>> gets cleared, which only happens from the ->ack() actor, i.e. when an
>>> interrupt actually occurred).
>>>
>>> This addresses a problem introduced in c/s 23816:7f357e1ef60a (by
>>> changing IRQ_VECTOR_UNASSIGNED from 0 to -1).
>>>
>>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
>>> ---
>>> I have to admit that I don't understand why the value got changed in
>>> the first place: 0 is as invalid a value as -1 for a vector to be used
>>> for delivering hardware interrupts.
>> http://lists.xen.org/archives/html/xen-devel/2011-09/msg00193.html 
>>
>> It was a suggestion for consistency with using -1 elsewhere in the irq
>> code to mean unassigned.
> Not really - there George suggested to use IRQ_VECTOR_UNASSIGNED,
> but not to make that resolve to -1. My claim is that this manifest
> constant could easily resolve to zero instead.
>
> Jan

Ah - it was in the following email.

"Yes - I missed that.  However, IRQ_VECTOR_UNASSIGNED should be -1
instead of 0, as the first 32 entries of irq_vector have 0 entries which
are not unassigned."

Which was my justification of using -1 as opposed to 0.

>
>
> _______________________________________________
> 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 Thu Sep 27 15:52:55 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Sep 2012 15:52: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 1THGOG-0002CA-IY; Thu, 27 Sep 2012 15:52:40 +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 1THGOE-0002C2-7D
	for xen-devel@lists.xen.org; Thu, 27 Sep 2012 15:52:38 +0000
Received: from [85.158.139.211:23288] by server-14.bemta-5.messagelabs.com id
	CA/2D-05772-54674605; Thu, 27 Sep 2012 15:52:37 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-13.tower-206.messagelabs.com!1348761154!16233975!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxNzE5Njc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32388 invoked from network); 27 Sep 2012 15:52:36 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-13.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Sep 2012 15:52:36 -0000
X-IronPort-AV: E=Sophos;i="4.80,496,1344211200"; d="scan'208";a="39399154"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Sep 2012 15:49:18 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1;
	Thu, 27 Sep 2012 11:49:18 -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 1THG62-0004nt-FI	for
	xen-devel@lists.xen.org; Thu, 27 Sep 2012 16:33:50 +0100
Message-ID: <506471DE.4090708@citrix.com>
Date: Thu, 27 Sep 2012 16:33:50 +0100
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120912 Thunderbird/15.0.1
MIME-Version: 1.0
To: xen-devel@lists.xen.org
References: <506483CC020000780009E42C@nat28.tlf.novell.com>
	<5064695B.1010805@citrix.com>
	<50648725020000780009E462@nat28.tlf.novell.com>
In-Reply-To: <50648725020000780009E462@nat28.tlf.novell.com>
X-Enigmail-Version: 1.4.4
Subject: Re: [Xen-devel] [PATCH] x86/IRQ: fix valid-old-vector checks in
	__assign_irq_vector()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/09/12 16:04, Jan Beulich wrote:
>>>> On 27.09.12 at 16:57, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
>> On 27/09/12 15:50, Jan Beulich wrote:
>>> There are two greater-than-zero checks for the old vector retrieved,
>>> which don't work when a negative value got stashed into the respective
>>> arch_irq_desc field. The effect of this was that for interrupts that
>>> are intended to get their affinity adjusted the first time before the
>>> first interrupt occurs, the affinity change would fail, because the
>>> original vector assignment would have caused the move_in_progress flag
>>> to get set (which causes subsequent re-assignments to fail until it
>>> gets cleared, which only happens from the ->ack() actor, i.e. when an
>>> interrupt actually occurred).
>>>
>>> This addresses a problem introduced in c/s 23816:7f357e1ef60a (by
>>> changing IRQ_VECTOR_UNASSIGNED from 0 to -1).
>>>
>>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
>>> ---
>>> I have to admit that I don't understand why the value got changed in
>>> the first place: 0 is as invalid a value as -1 for a vector to be used
>>> for delivering hardware interrupts.
>> http://lists.xen.org/archives/html/xen-devel/2011-09/msg00193.html 
>>
>> It was a suggestion for consistency with using -1 elsewhere in the irq
>> code to mean unassigned.
> Not really - there George suggested to use IRQ_VECTOR_UNASSIGNED,
> but not to make that resolve to -1. My claim is that this manifest
> constant could easily resolve to zero instead.
>
> Jan

Ah - it was in the following email.

"Yes - I missed that.  However, IRQ_VECTOR_UNASSIGNED should be -1
instead of 0, as the first 32 entries of irq_vector have 0 entries which
are not unassigned."

Which was my justification of using -1 as opposed to 0.

>
>
> _______________________________________________
> 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 Thu Sep 27 15:59:07 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Sep 2012 15:59:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1THGUH-0002Xi-2K; Thu, 27 Sep 2012 15:58:53 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mrsanna1@gmail.com>) id 1THGQN-0002JC-R9
	for xen-devel@lists.xensource.com; Thu, 27 Sep 2012 15:54:52 +0000
Received: from [85.158.139.83:62399] by server-11.bemta-5.messagelabs.com id
	44/CE-13866-BC674605; Thu, 27 Sep 2012 15:54:51 +0000
X-Env-Sender: mrsanna1@gmail.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1348761289!32241157!1
X-Originating-IP: [209.85.212.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1225 invoked from network); 27 Sep 2012 15:54:50 -0000
Received: from mail-vb0-f43.google.com (HELO mail-vb0-f43.google.com)
	(209.85.212.43)
	by server-12.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Sep 2012 15:54:50 -0000
Received: by vbbfq11 with SMTP id fq11so2593218vbb.30
	for <multiple recipients>; Thu, 27 Sep 2012 08:54:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=KlG5w16g2rW49mskdLvsisNgmthetfkSy5RgMokk26A=;
	b=g16EFRwD7PKUsYfx2QpM7luT+KyKnRaZHnoIOcKXiRKTw9y71liglYH3/7O8CFzS7T
	Y96F9GlkLnN9RHw6juE55hOcCvCDVdOz/95N/X9LgK0e1hcFjwkWIdNHCtxbc6abZ4xI
	bsGxrcIb1iPck9n5Ej3Gtl06+eCKqUpli5YN6BmwIWPbgK8TZObQeHk4s8xjdLv+EcRt
	GDXprPYx9CeqEa+eOYJntMEO/5MshhzI2tvi9NHI5Y/m4hu1jtRKQTX4WD6lj3jtiob+
	/7cIs80zPeU361VB5Quvdq/P/Gshopy6CcCAO07UPszrg6eTZeTRYYCCznv9bi2McBoi
	BY+g==
MIME-Version: 1.0
Received: by 10.220.205.200 with SMTP id fr8mr2378179vcb.34.1348761288807;
	Thu, 27 Sep 2012 08:54:48 -0700 (PDT)
Received: by 10.58.207.75 with HTTP; Thu, 27 Sep 2012 08:54:48 -0700 (PDT)
In-Reply-To: <AANLkTinK94GDOF_GeaVs50wK0u8EdZ2rtzPuh65ca8qR@mail.gmail.com>
References: <68c41dd8-9195-41b0-83d7-9242b8eff809@default>
	<AANLkTi=NFebVsnj_09+SpCZUo_bNTnTyJLAoR5sfbwZa@mail.gmail.com>
	<AANLkTikptc2POrKQgJuoVZRdwJTo64DJ_hm12KuPky4D@mail.gmail.com>
	<b1ca6ddc-ca69-447e-93e9-8d36d1ff4a43@default>
	<AANLkTinK94GDOF_GeaVs50wK0u8EdZ2rtzPuh65ca8qR@mail.gmail.com>
Date: Thu, 27 Sep 2012 17:54:48 +0200
Message-ID: <CAE17a0UPyzsNn=ps9MxarkGg=ns8dCpVz0qBDvesT2AOskwfVg@mail.gmail.com>
From: Mauro <mrsanna1@gmail.com>
To: Olivier Hanesse <olivier.hanesse@gmail.com>
X-Mailman-Approved-At: Thu, 27 Sep 2012 15:58:51 +0000
Cc: Dan Magenheimer <dan.magenheimer@oracle.com>, xen-devel@lists.xensource.com,
	Keir Fraser <keir@xen.org>, Jeremy Fitzhardinge <jeremy@goop.org>,
	Keir Fraser <keir.xen@gmail.com>,
	Xen Users <xen-users@lists.xensource.com>,
	Mark Adams <mark@campbell-lange.net>
Subject: Re: [Xen-devel] [Xen-users] Re:  Xen 4 TSC problems
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 28 February 2011 16:54, Olivier Hanesse <olivier.hanesse@gmail.com> wrote:
> Yes this is what I mean.
> I am glad to hear that it isn't a bad sign :)
> I thought of a bad sign, because on system with "reliable TSC", this counter
> is always 0.

Hey men.
I have exactly the same problem.
I have two cluster nodes.
Server are two HP Proliant DL 580 G4 with four Quad Core Intel(R)
Xeon(R) CPU E7330  @ 2.40GHz.
I'm running debian squeeze in dom0s end domUs.
xm info:

host                   : xen-p01
release                : 2.6.32-5-xen-amd64
version                : #1 SMP Sun May 6 08:57:29 UTC 2012
machine                : x86_64
nr_cpus                : 16
nr_nodes               : 1
cores_per_socket       : 4
threads_per_core       : 1
cpu_mhz                : 2400
hw_caps                :
bfebfbff:20100800:00000000:00000940:0004e3bd:00000000:00000001:00000000
virt_caps              : hvm
total_memory           : 65532
free_memory            : 40317
node_to_cpu            : node0:0-15
node_to_memory         : node0:40317
node_to_dma32_mem      : node0:3256
max_node_id            : 0
xen_major              : 4
xen_minor              : 0
xen_extra              : .1
xen_caps               : xen-3.0-x86_64 xen-3.0-x86_32p hvm-3.0-x86_32
hvm-3.0-x86_32p hvm-3.0-x86_64
xen_scheduler          : credit
xen_pagesize           : 4096
platform_params        : virt_start=0xffff800000000000
xen_changeset          : unavailable
xen_commandline        : placeholder dom0_mem=3072M loglvl=warning
guest_loglvl=warning
cc_compiler            : gcc version 4.4.5 (Debian 4.4.5-8)
cc_compile_by          : ultrotter
cc_compile_domain      : debian.org
cc_compile_date        : Sat Sep  8 19:15:46 UTC 2012
xend_config_format     : 4

I'm experiencing weekly a clock jump ahead of about 50 minutes on dom0.
I'm seriously in trouble because it cause every time a reboot of one
of the two nodes clusters.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 27 15:59:07 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Sep 2012 15:59:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1THGUH-0002Xi-2K; Thu, 27 Sep 2012 15:58:53 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mrsanna1@gmail.com>) id 1THGQN-0002JC-R9
	for xen-devel@lists.xensource.com; Thu, 27 Sep 2012 15:54:52 +0000
Received: from [85.158.139.83:62399] by server-11.bemta-5.messagelabs.com id
	44/CE-13866-BC674605; Thu, 27 Sep 2012 15:54:51 +0000
X-Env-Sender: mrsanna1@gmail.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1348761289!32241157!1
X-Originating-IP: [209.85.212.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1225 invoked from network); 27 Sep 2012 15:54:50 -0000
Received: from mail-vb0-f43.google.com (HELO mail-vb0-f43.google.com)
	(209.85.212.43)
	by server-12.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Sep 2012 15:54:50 -0000
Received: by vbbfq11 with SMTP id fq11so2593218vbb.30
	for <multiple recipients>; Thu, 27 Sep 2012 08:54:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=KlG5w16g2rW49mskdLvsisNgmthetfkSy5RgMokk26A=;
	b=g16EFRwD7PKUsYfx2QpM7luT+KyKnRaZHnoIOcKXiRKTw9y71liglYH3/7O8CFzS7T
	Y96F9GlkLnN9RHw6juE55hOcCvCDVdOz/95N/X9LgK0e1hcFjwkWIdNHCtxbc6abZ4xI
	bsGxrcIb1iPck9n5Ej3Gtl06+eCKqUpli5YN6BmwIWPbgK8TZObQeHk4s8xjdLv+EcRt
	GDXprPYx9CeqEa+eOYJntMEO/5MshhzI2tvi9NHI5Y/m4hu1jtRKQTX4WD6lj3jtiob+
	/7cIs80zPeU361VB5Quvdq/P/Gshopy6CcCAO07UPszrg6eTZeTRYYCCznv9bi2McBoi
	BY+g==
MIME-Version: 1.0
Received: by 10.220.205.200 with SMTP id fr8mr2378179vcb.34.1348761288807;
	Thu, 27 Sep 2012 08:54:48 -0700 (PDT)
Received: by 10.58.207.75 with HTTP; Thu, 27 Sep 2012 08:54:48 -0700 (PDT)
In-Reply-To: <AANLkTinK94GDOF_GeaVs50wK0u8EdZ2rtzPuh65ca8qR@mail.gmail.com>
References: <68c41dd8-9195-41b0-83d7-9242b8eff809@default>
	<AANLkTi=NFebVsnj_09+SpCZUo_bNTnTyJLAoR5sfbwZa@mail.gmail.com>
	<AANLkTikptc2POrKQgJuoVZRdwJTo64DJ_hm12KuPky4D@mail.gmail.com>
	<b1ca6ddc-ca69-447e-93e9-8d36d1ff4a43@default>
	<AANLkTinK94GDOF_GeaVs50wK0u8EdZ2rtzPuh65ca8qR@mail.gmail.com>
Date: Thu, 27 Sep 2012 17:54:48 +0200
Message-ID: <CAE17a0UPyzsNn=ps9MxarkGg=ns8dCpVz0qBDvesT2AOskwfVg@mail.gmail.com>
From: Mauro <mrsanna1@gmail.com>
To: Olivier Hanesse <olivier.hanesse@gmail.com>
X-Mailman-Approved-At: Thu, 27 Sep 2012 15:58:51 +0000
Cc: Dan Magenheimer <dan.magenheimer@oracle.com>, xen-devel@lists.xensource.com,
	Keir Fraser <keir@xen.org>, Jeremy Fitzhardinge <jeremy@goop.org>,
	Keir Fraser <keir.xen@gmail.com>,
	Xen Users <xen-users@lists.xensource.com>,
	Mark Adams <mark@campbell-lange.net>
Subject: Re: [Xen-devel] [Xen-users] Re:  Xen 4 TSC problems
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 28 February 2011 16:54, Olivier Hanesse <olivier.hanesse@gmail.com> wrote:
> Yes this is what I mean.
> I am glad to hear that it isn't a bad sign :)
> I thought of a bad sign, because on system with "reliable TSC", this counter
> is always 0.

Hey men.
I have exactly the same problem.
I have two cluster nodes.
Server are two HP Proliant DL 580 G4 with four Quad Core Intel(R)
Xeon(R) CPU E7330  @ 2.40GHz.
I'm running debian squeeze in dom0s end domUs.
xm info:

host                   : xen-p01
release                : 2.6.32-5-xen-amd64
version                : #1 SMP Sun May 6 08:57:29 UTC 2012
machine                : x86_64
nr_cpus                : 16
nr_nodes               : 1
cores_per_socket       : 4
threads_per_core       : 1
cpu_mhz                : 2400
hw_caps                :
bfebfbff:20100800:00000000:00000940:0004e3bd:00000000:00000001:00000000
virt_caps              : hvm
total_memory           : 65532
free_memory            : 40317
node_to_cpu            : node0:0-15
node_to_memory         : node0:40317
node_to_dma32_mem      : node0:3256
max_node_id            : 0
xen_major              : 4
xen_minor              : 0
xen_extra              : .1
xen_caps               : xen-3.0-x86_64 xen-3.0-x86_32p hvm-3.0-x86_32
hvm-3.0-x86_32p hvm-3.0-x86_64
xen_scheduler          : credit
xen_pagesize           : 4096
platform_params        : virt_start=0xffff800000000000
xen_changeset          : unavailable
xen_commandline        : placeholder dom0_mem=3072M loglvl=warning
guest_loglvl=warning
cc_compiler            : gcc version 4.4.5 (Debian 4.4.5-8)
cc_compile_by          : ultrotter
cc_compile_domain      : debian.org
cc_compile_date        : Sat Sep  8 19:15:46 UTC 2012
xend_config_format     : 4

I'm experiencing weekly a clock jump ahead of about 50 minutes on dom0.
I'm seriously in trouble because it cause every time a reboot of one
of the two nodes clusters.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 27 15:59:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Sep 2012 15:59:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1THGV4-0002cm-GZ; Thu, 27 Sep 2012 15:59:42 +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 1THGV2-0002cD-Ag
	for xen-devel@lists.xen.org; Thu, 27 Sep 2012 15:59:40 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1348761573!5627069!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7971 invoked from network); 27 Sep 2012 15:59:33 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-14.tower-27.messagelabs.com with SMTP;
	27 Sep 2012 15:59:33 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 27 Sep 2012 16:59:33 +0100
Message-Id: <5064941C020000780009E4CA@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 27 Sep 2012 16:59:56 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
References: <CAOvdn6UCF2A3yP1cqWn=dxwr0ayRbr+rg+xj8META9Dm0+CoNw@mail.gmail.com>
	<CC868168.3FD29%keir.xen@gmail.com>
	<CAOvdn6U-JyLvt96gkLkqzi088tU9_ktv4D+fkJac_BKVe05Y-w@mail.gmail.com>
	<CAOvdn6V+s3AbRzsu8VArbmrZou=im9SqvPf-9Wpif_BrNMv=yg@mail.gmail.com>
	<50617297020000780009D8AA@nat28.tlf.novell.com>
	<CAOvdn6Vsnbcd7m8mh3tSgn3KaEoeiOyVD1mr3uQ3bN=rF=pDUQ@mail.gmail.com>
	<5062F880020000780009DF3B@nat28.tlf.novell.com>
	<CAOvdn6VyAVg24=c1OxqttxuGFyN_NzpfZ7RoCYc2mVF84c5big@mail.gmail.com>
	<50641E86020000780009E2E3@nat28.tlf.novell.com>
	<CAOvdn6VE13fOSjrKU4Ryr=344u+YwygASj6z1ag_U-x-qvOC9g@mail.gmail.com>
	<50648C21020000780009E478@nat28.tlf.novell.com>
	<CAOvdn6VKrPzWLdETq10ihytDjyOjK55ShnRnCS6V112aYE=VJg@mail.gmail.com>
In-Reply-To: <CAOvdn6VKrPzWLdETq10ihytDjyOjK55ShnRnCS6V112aYE=VJg@mail.gmail.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__PartC7F6FEEC.1__="
Cc: Ben Guthro <ben@guthro.net>
Subject: [Xen-devel] [PATCH] x86/ucode: fix Intel case of resume handling on
 boot 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>
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.

--=__PartC7F6FEEC.1__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Checking the stored version doesn't tell us anything about the need to
apply the update (during resume, what is stored doesn't necessarily
match what is loaded).

Note that the check can be removed altogether because once switched to
use what was read from the CPU (uci->cpu_sig.rev, as used in the
subsequent pr_debug()), it would become redundant with the checks that
lead to microcode_update_match() returning the indication that an
update should be applied.

Note further that this was not an issue on APs since they start with
uci->mc.mc_intel being NULL.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Tested-by: Ben Guthro <ben@guthro.net>

--- a/xen/arch/x86/microcode_intel.c
+++ b/xen/arch/x86/microcode_intel.c
@@ -261,8 +261,6 @@ static int get_matching_microcode(const=20
     }
     return 0;
  find:
-    if ( uci->mc.mc_intel && uci->mc.mc_intel->hdr.rev >=3D mc_header->rev=
 )
-        return 0;
     pr_debug("microcode: CPU%d found a matching microcode update with"
              " version %#x (current=3D%#x)\n",
              cpu, mc_header->rev, uci->cpu_sig.rev);




--=__PartC7F6FEEC.1__=
Content-Type: text/plain; name="x86-ucode-Intel-resume.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="x86-ucode-Intel-resume.patch"

x86/ucode: fix Intel case of resume handling on boot CPU=0A=0AChecking the =
stored version doesn't tell us anything about the need to=0Aapply the =
update (during resume, what is stored doesn't necessarily=0Amatch what is =
loaded).=0A=0ANote that the check can be removed altogether because once =
switched to=0Ause what was read from the CPU (uci->cpu_sig.rev, as used in =
the=0Asubsequent pr_debug()), it would become redundant with the checks =
that=0Alead to microcode_update_match() returning the indication that =
an=0Aupdate should be applied.=0A=0ANote further that this was not an =
issue on APs since they start with=0Auci->mc.mc_intel being NULL.=0A=0ASign=
ed-off-by: Jan Beulich <jbeulich@suse.com>=0ATested-by: Ben Guthro =
<ben@guthro.net>=0A=0A--- a/xen/arch/x86/microcode_intel.c=0A+++ b/xen/arch=
/x86/microcode_intel.c=0A@@ -261,8 +261,6 @@ static int get_matching_microc=
ode(const =0A     }=0A     return 0;=0A  find:=0A-    if ( uci->mc.mc_intel=
 && uci->mc.mc_intel->hdr.rev >=3D mc_header->rev )=0A-        return =
0;=0A     pr_debug("microcode: CPU%d found a matching microcode update =
with"=0A              " version %#x (current=3D%#x)\n",=0A              =
cpu, mc_header->rev, uci->cpu_sig.rev);=0A
--=__PartC7F6FEEC.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

--=__PartC7F6FEEC.1__=--


From xen-devel-bounces@lists.xen.org Thu Sep 27 15:59:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Sep 2012 15:59:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1THGV4-0002cm-GZ; Thu, 27 Sep 2012 15:59:42 +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 1THGV2-0002cD-Ag
	for xen-devel@lists.xen.org; Thu, 27 Sep 2012 15:59:40 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1348761573!5627069!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7971 invoked from network); 27 Sep 2012 15:59:33 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-14.tower-27.messagelabs.com with SMTP;
	27 Sep 2012 15:59:33 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 27 Sep 2012 16:59:33 +0100
Message-Id: <5064941C020000780009E4CA@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 27 Sep 2012 16:59:56 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
References: <CAOvdn6UCF2A3yP1cqWn=dxwr0ayRbr+rg+xj8META9Dm0+CoNw@mail.gmail.com>
	<CC868168.3FD29%keir.xen@gmail.com>
	<CAOvdn6U-JyLvt96gkLkqzi088tU9_ktv4D+fkJac_BKVe05Y-w@mail.gmail.com>
	<CAOvdn6V+s3AbRzsu8VArbmrZou=im9SqvPf-9Wpif_BrNMv=yg@mail.gmail.com>
	<50617297020000780009D8AA@nat28.tlf.novell.com>
	<CAOvdn6Vsnbcd7m8mh3tSgn3KaEoeiOyVD1mr3uQ3bN=rF=pDUQ@mail.gmail.com>
	<5062F880020000780009DF3B@nat28.tlf.novell.com>
	<CAOvdn6VyAVg24=c1OxqttxuGFyN_NzpfZ7RoCYc2mVF84c5big@mail.gmail.com>
	<50641E86020000780009E2E3@nat28.tlf.novell.com>
	<CAOvdn6VE13fOSjrKU4Ryr=344u+YwygASj6z1ag_U-x-qvOC9g@mail.gmail.com>
	<50648C21020000780009E478@nat28.tlf.novell.com>
	<CAOvdn6VKrPzWLdETq10ihytDjyOjK55ShnRnCS6V112aYE=VJg@mail.gmail.com>
In-Reply-To: <CAOvdn6VKrPzWLdETq10ihytDjyOjK55ShnRnCS6V112aYE=VJg@mail.gmail.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__PartC7F6FEEC.1__="
Cc: Ben Guthro <ben@guthro.net>
Subject: [Xen-devel] [PATCH] x86/ucode: fix Intel case of resume handling on
 boot 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>
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.

--=__PartC7F6FEEC.1__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Checking the stored version doesn't tell us anything about the need to
apply the update (during resume, what is stored doesn't necessarily
match what is loaded).

Note that the check can be removed altogether because once switched to
use what was read from the CPU (uci->cpu_sig.rev, as used in the
subsequent pr_debug()), it would become redundant with the checks that
lead to microcode_update_match() returning the indication that an
update should be applied.

Note further that this was not an issue on APs since they start with
uci->mc.mc_intel being NULL.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Tested-by: Ben Guthro <ben@guthro.net>

--- a/xen/arch/x86/microcode_intel.c
+++ b/xen/arch/x86/microcode_intel.c
@@ -261,8 +261,6 @@ static int get_matching_microcode(const=20
     }
     return 0;
  find:
-    if ( uci->mc.mc_intel && uci->mc.mc_intel->hdr.rev >=3D mc_header->rev=
 )
-        return 0;
     pr_debug("microcode: CPU%d found a matching microcode update with"
              " version %#x (current=3D%#x)\n",
              cpu, mc_header->rev, uci->cpu_sig.rev);




--=__PartC7F6FEEC.1__=
Content-Type: text/plain; name="x86-ucode-Intel-resume.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="x86-ucode-Intel-resume.patch"

x86/ucode: fix Intel case of resume handling on boot CPU=0A=0AChecking the =
stored version doesn't tell us anything about the need to=0Aapply the =
update (during resume, what is stored doesn't necessarily=0Amatch what is =
loaded).=0A=0ANote that the check can be removed altogether because once =
switched to=0Ause what was read from the CPU (uci->cpu_sig.rev, as used in =
the=0Asubsequent pr_debug()), it would become redundant with the checks =
that=0Alead to microcode_update_match() returning the indication that =
an=0Aupdate should be applied.=0A=0ANote further that this was not an =
issue on APs since they start with=0Auci->mc.mc_intel being NULL.=0A=0ASign=
ed-off-by: Jan Beulich <jbeulich@suse.com>=0ATested-by: Ben Guthro =
<ben@guthro.net>=0A=0A--- a/xen/arch/x86/microcode_intel.c=0A+++ b/xen/arch=
/x86/microcode_intel.c=0A@@ -261,8 +261,6 @@ static int get_matching_microc=
ode(const =0A     }=0A     return 0;=0A  find:=0A-    if ( uci->mc.mc_intel=
 && uci->mc.mc_intel->hdr.rev >=3D mc_header->rev )=0A-        return =
0;=0A     pr_debug("microcode: CPU%d found a matching microcode update =
with"=0A              " version %#x (current=3D%#x)\n",=0A              =
cpu, mc_header->rev, uci->cpu_sig.rev);=0A
--=__PartC7F6FEEC.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

--=__PartC7F6FEEC.1__=--


From xen-devel-bounces@lists.xen.org Thu Sep 27 16:03:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Sep 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 1THGY7-0003J6-9X; Thu, 27 Sep 2012 16:02:51 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1THGY5-0003Ix-LZ
	for xen-devel@lists.xen.org; Thu, 27 Sep 2012 16:02:49 +0000
Received: from [85.158.139.83:21955] by server-9.bemta-5.messagelabs.com id
	90/30-14846-8A874605; Thu, 27 Sep 2012 16:02:48 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1348761768!28141865!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6599 invoked from network); 27 Sep 2012 16:02:48 -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;
	27 Sep 2012 16:02:48 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 27 Sep 2012 17:02:49 +0100
Message-Id: <506494DD020000780009E4DF@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 27 Sep 2012 17:03:09 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Andrew Cooper" <andrew.cooper3@citrix.com>
References: <506483CC020000780009E42C@nat28.tlf.novell.com>
	<5064695B.1010805@citrix.com>
	<50648725020000780009E462@nat28.tlf.novell.com>
	<506471DE.4090708@citrix.com>
In-Reply-To: <506471DE.4090708@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] x86/IRQ: fix valid-old-vector checks in
 __assign_irq_vector()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.09.12 at 17:33, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
> On 27/09/12 16:04, Jan Beulich wrote:
>>>>> On 27.09.12 at 16:57, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
>>> On 27/09/12 15:50, Jan Beulich wrote:
>>>> There are two greater-than-zero checks for the old vector retrieved,
>>>> which don't work when a negative value got stashed into the respective
>>>> arch_irq_desc field. The effect of this was that for interrupts that
>>>> are intended to get their affinity adjusted the first time before the
>>>> first interrupt occurs, the affinity change would fail, because the
>>>> original vector assignment would have caused the move_in_progress flag
>>>> to get set (which causes subsequent re-assignments to fail until it
>>>> gets cleared, which only happens from the ->ack() actor, i.e. when an
>>>> interrupt actually occurred).
>>>>
>>>> This addresses a problem introduced in c/s 23816:7f357e1ef60a (by
>>>> changing IRQ_VECTOR_UNASSIGNED from 0 to -1).
>>>>
>>>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
>>>> ---
>>>> I have to admit that I don't understand why the value got changed in
>>>> the first place: 0 is as invalid a value as -1 for a vector to be used
>>>> for delivering hardware interrupts.
>>> http://lists.xen.org/archives/html/xen-devel/2011-09/msg00193.html 
>>>
>>> It was a suggestion for consistency with using -1 elsewhere in the irq
>>> code to mean unassigned.
>> Not really - there George suggested to use IRQ_VECTOR_UNASSIGNED,
>> but not to make that resolve to -1. My claim is that this manifest
>> constant could easily resolve to zero instead.
>>
>> Jan
> 
> Ah - it was in the following email.
> 
> "Yes - I missed that.  However, IRQ_VECTOR_UNASSIGNED should be -1
> instead of 0, as the first 32 entries of irq_vector have 0 entries which
> are not unassigned."
> 
> Which was my justification of using -1 as opposed to 0.

With irq_vector[] not even in existence anymore, I wonder
whether we shouldn't go back to zero.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 27 16:03:05 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Sep 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 1THGY7-0003J6-9X; Thu, 27 Sep 2012 16:02:51 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1THGY5-0003Ix-LZ
	for xen-devel@lists.xen.org; Thu, 27 Sep 2012 16:02:49 +0000
Received: from [85.158.139.83:21955] by server-9.bemta-5.messagelabs.com id
	90/30-14846-8A874605; Thu, 27 Sep 2012 16:02:48 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1348761768!28141865!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6599 invoked from network); 27 Sep 2012 16:02:48 -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;
	27 Sep 2012 16:02:48 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 27 Sep 2012 17:02:49 +0100
Message-Id: <506494DD020000780009E4DF@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 27 Sep 2012 17:03:09 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Andrew Cooper" <andrew.cooper3@citrix.com>
References: <506483CC020000780009E42C@nat28.tlf.novell.com>
	<5064695B.1010805@citrix.com>
	<50648725020000780009E462@nat28.tlf.novell.com>
	<506471DE.4090708@citrix.com>
In-Reply-To: <506471DE.4090708@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] x86/IRQ: fix valid-old-vector checks in
 __assign_irq_vector()
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.09.12 at 17:33, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
> On 27/09/12 16:04, Jan Beulich wrote:
>>>>> On 27.09.12 at 16:57, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
>>> On 27/09/12 15:50, Jan Beulich wrote:
>>>> There are two greater-than-zero checks for the old vector retrieved,
>>>> which don't work when a negative value got stashed into the respective
>>>> arch_irq_desc field. The effect of this was that for interrupts that
>>>> are intended to get their affinity adjusted the first time before the
>>>> first interrupt occurs, the affinity change would fail, because the
>>>> original vector assignment would have caused the move_in_progress flag
>>>> to get set (which causes subsequent re-assignments to fail until it
>>>> gets cleared, which only happens from the ->ack() actor, i.e. when an
>>>> interrupt actually occurred).
>>>>
>>>> This addresses a problem introduced in c/s 23816:7f357e1ef60a (by
>>>> changing IRQ_VECTOR_UNASSIGNED from 0 to -1).
>>>>
>>>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
>>>> ---
>>>> I have to admit that I don't understand why the value got changed in
>>>> the first place: 0 is as invalid a value as -1 for a vector to be used
>>>> for delivering hardware interrupts.
>>> http://lists.xen.org/archives/html/xen-devel/2011-09/msg00193.html 
>>>
>>> It was a suggestion for consistency with using -1 elsewhere in the irq
>>> code to mean unassigned.
>> Not really - there George suggested to use IRQ_VECTOR_UNASSIGNED,
>> but not to make that resolve to -1. My claim is that this manifest
>> constant could easily resolve to zero instead.
>>
>> Jan
> 
> Ah - it was in the following email.
> 
> "Yes - I missed that.  However, IRQ_VECTOR_UNASSIGNED should be -1
> instead of 0, as the first 32 entries of irq_vector have 0 entries which
> are not unassigned."
> 
> Which was my justification of using -1 as opposed to 0.

With irq_vector[] not even in existence anymore, I wonder
whether we shouldn't go back to zero.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 27 16:06:33 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Sep 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 1THGbS-0003hL-I0; Thu, 27 Sep 2012 16:06:18 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1THGbQ-0003h5-NK
	for xen-devel@lists.xen.org; Thu, 27 Sep 2012 16:06:16 +0000
Received: from [85.158.137.99:38738] by server-10.bemta-3.messagelabs.com id
	B8/B7-02525-77974605; Thu, 27 Sep 2012 16:06:15 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-9.tower-217.messagelabs.com!1348761975!16235561!1
X-Originating-IP: [74.125.83.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7328 invoked from network); 27 Sep 2012 16:06:15 -0000
Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com)
	(74.125.83.45)
	by server-9.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Sep 2012 16:06:15 -0000
Received: by eekb47 with SMTP id b47so1089483eek.32
	for <xen-devel@lists.xen.org>; Thu, 27 Sep 2012 09:06:15 -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=c1t6yglxC6JdwrbsCzIVYwnhvmk5+3ZM04zISq1eQsU=;
	b=lZRr6iu122ze2h2spwaSwTF1coWB1kFkTDu0N+YKMyOJOd3TziEDgjE10P6sIFwsaB
	VKW+lsV55XE5JcRc+zO4L+YE+a2ir30E40I3aFmPTA7Y33KvSAWniyobGoXBVnwOfZM+
	e0zgafyOCvJlhcIDvh1fQOqMDrw5fhsCrxS1nGgUAMBc8s/TAbAxcFcazCDW55Mpjz7J
	Ee2QS9Sl2QtG11x2gfkWMsLmJGRM32qpem9L4RlzU+ROxMXaYbYU2r5+W5UzVCFBvOzD
	vK14JiSNTNaqQlaQNsBP2AcMVbhJ20gczD4vUo4YfZNplPP8pC6v8ZWPw59IAuv38Uwl
	pLGg==
Received: by 10.14.213.197 with SMTP id a45mr6593969eep.3.1348761975144;
	Thu, 27 Sep 2012 09:06:15 -0700 (PDT)
Received: from [192.168.1.3] (host86-160-224-180.range86-160.btcentralplus.com.
	[86.160.224.180])
	by mx.google.com with ESMTPS id e42sm18752275eem.8.2012.09.27.09.06.09
	(version=SSLv3 cipher=OTHER); Thu, 27 Sep 2012 09:06:11 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.33.0.120411
Date: Thu, 27 Sep 2012 17:06:02 +0100
From: Keir Fraser <keir@xen.org>
To: Jan Beulich <JBeulich@suse.com>,
	xen-devel <xen-devel@lists.xen.org>
Message-ID: <CC8A37FA.4D17B%keir@xen.org>
Thread-Topic: [Xen-devel] [PATCH] x86/ucode: fix Intel case of resume handling
	on boot CPU
Thread-Index: Ac2cyf2PwoU/0ouxYUmpSl/lSAF9+g==
In-Reply-To: <5064941C020000780009E4CA@nat28.tlf.novell.com>
Mime-version: 1.0
Cc: Ben Guthro <ben@guthro.net>
Subject: Re: [Xen-devel] [PATCH] x86/ucode: fix Intel case of resume
 handling on boot 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 27/09/2012 16:59, "Jan Beulich" <JBeulich@suse.com> wrote:

> Checking the stored version doesn't tell us anything about the need to
> apply the update (during resume, what is stored doesn't necessarily
> match what is loaded).
> 
> Note that the check can be removed altogether because once switched to
> use what was read from the CPU (uci->cpu_sig.rev, as used in the
> subsequent pr_debug()), it would become redundant with the checks that
> lead to microcode_update_match() returning the indication that an
> update should be applied.
> 
> Note further that this was not an issue on APs since they start with
> uci->mc.mc_intel being NULL.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> Tested-by: Ben Guthro <ben@guthro.net>

Acked-by: Keir Fraser <keir@xen.org>

> --- a/xen/arch/x86/microcode_intel.c
> +++ b/xen/arch/x86/microcode_intel.c
> @@ -261,8 +261,6 @@ static int get_matching_microcode(const
>      }
>      return 0;
>   find:
> -    if ( uci->mc.mc_intel && uci->mc.mc_intel->hdr.rev >= mc_header->rev )
> -        return 0;
>      pr_debug("microcode: CPU%d found a matching microcode update with"
>               " version %#x (current=%#x)\n",
>               cpu, mc_header->rev, uci->cpu_sig.rev);
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Sep 27 16:06:33 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Sep 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 1THGbS-0003hL-I0; Thu, 27 Sep 2012 16:06:18 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1THGbQ-0003h5-NK
	for xen-devel@lists.xen.org; Thu, 27 Sep 2012 16:06:16 +0000
Received: from [85.158.137.99:38738] by server-10.bemta-3.messagelabs.com id
	B8/B7-02525-77974605; Thu, 27 Sep 2012 16:06:15 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-9.tower-217.messagelabs.com!1348761975!16235561!1
X-Originating-IP: [74.125.83.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7328 invoked from network); 27 Sep 2012 16:06:15 -0000
Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com)
	(74.125.83.45)
	by server-9.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Sep 2012 16:06:15 -0000
Received: by eekb47 with SMTP id b47so1089483eek.32
	for <xen-devel@lists.xen.org>; Thu, 27 Sep 2012 09:06:15 -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=c1t6yglxC6JdwrbsCzIVYwnhvmk5+3ZM04zISq1eQsU=;
	b=lZRr6iu122ze2h2spwaSwTF1coWB1kFkTDu0N+YKMyOJOd3TziEDgjE10P6sIFwsaB
	VKW+lsV55XE5JcRc+zO4L+YE+a2ir30E40I3aFmPTA7Y33KvSAWniyobGoXBVnwOfZM+
	e0zgafyOCvJlhcIDvh1fQOqMDrw5fhsCrxS1nGgUAMBc8s/TAbAxcFcazCDW55Mpjz7J
	Ee2QS9Sl2QtG11x2gfkWMsLmJGRM32qpem9L4RlzU+ROxMXaYbYU2r5+W5UzVCFBvOzD
	vK14JiSNTNaqQlaQNsBP2AcMVbhJ20gczD4vUo4YfZNplPP8pC6v8ZWPw59IAuv38Uwl
	pLGg==
Received: by 10.14.213.197 with SMTP id a45mr6593969eep.3.1348761975144;
	Thu, 27 Sep 2012 09:06:15 -0700 (PDT)
Received: from [192.168.1.3] (host86-160-224-180.range86-160.btcentralplus.com.
	[86.160.224.180])
	by mx.google.com with ESMTPS id e42sm18752275eem.8.2012.09.27.09.06.09
	(version=SSLv3 cipher=OTHER); Thu, 27 Sep 2012 09:06:11 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.33.0.120411
Date: Thu, 27 Sep 2012 17:06:02 +0100
From: Keir Fraser <keir@xen.org>
To: Jan Beulich <JBeulich@suse.com>,
	xen-devel <xen-devel@lists.xen.org>
Message-ID: <CC8A37FA.4D17B%keir@xen.org>
Thread-Topic: [Xen-devel] [PATCH] x86/ucode: fix Intel case of resume handling
	on boot CPU
Thread-Index: Ac2cyf2PwoU/0ouxYUmpSl/lSAF9+g==
In-Reply-To: <5064941C020000780009E4CA@nat28.tlf.novell.com>
Mime-version: 1.0
Cc: Ben Guthro <ben@guthro.net>
Subject: Re: [Xen-devel] [PATCH] x86/ucode: fix Intel case of resume
 handling on boot 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 27/09/2012 16:59, "Jan Beulich" <JBeulich@suse.com> wrote:

> Checking the stored version doesn't tell us anything about the need to
> apply the update (during resume, what is stored doesn't necessarily
> match what is loaded).
> 
> Note that the check can be removed altogether because once switched to
> use what was read from the CPU (uci->cpu_sig.rev, as used in the
> subsequent pr_debug()), it would become redundant with the checks that
> lead to microcode_update_match() returning the indication that an
> update should be applied.
> 
> Note further that this was not an issue on APs since they start with
> uci->mc.mc_intel being NULL.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> Tested-by: Ben Guthro <ben@guthro.net>

Acked-by: Keir Fraser <keir@xen.org>

> --- a/xen/arch/x86/microcode_intel.c
> +++ b/xen/arch/x86/microcode_intel.c
> @@ -261,8 +261,6 @@ static int get_matching_microcode(const
>      }
>      return 0;
>   find:
> -    if ( uci->mc.mc_intel && uci->mc.mc_intel->hdr.rev >= mc_header->rev )
> -        return 0;
>      pr_debug("microcode: CPU%d found a matching microcode update with"
>               " version %#x (current=%#x)\n",
>               cpu, mc_header->rev, uci->cpu_sig.rev);
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Sep 27 16:12:07 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Sep 2012 16:12: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 1THGgs-00043q-BE; Thu, 27 Sep 2012 16:11:54 +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 1THGgq-00043j-Qj
	for xen-devel@lists.xen.org; Thu, 27 Sep 2012 16:11:53 +0000
Received: from [85.158.143.35:18638] by server-1.bemta-4.messagelabs.com id
	CC/09-05684-8CA74605; Thu, 27 Sep 2012 16:11:52 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-16.tower-21.messagelabs.com!1348762311!13948923!1
X-Originating-IP: [63.239.67.9]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9146 invoked from network); 27 Sep 2012 16:11:51 -0000
Received: from emvm-gh1-uea08.nsa.gov (HELO nsa.gov) (63.239.67.9)
	by server-16.tower-21.messagelabs.com with SMTP;
	27 Sep 2012 16:11:51 -0000
X-TM-IMSS-Message-ID: <872b3e0200191449@nsa.gov>
Received: from tarius.tycho.ncsc.mil ([144.51.3.1]) by nsa.gov ([63.239.67.9])
	with ESMTP (TREND IMSS SMTP Service 7.1) id 872b3e0200191449 ;
	Thu, 27 Sep 2012 12:12:10 -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 q8RGBna8028562; 
	Thu, 27 Sep 2012 12:11:49 -0400
Message-ID: <50647AC5.9080905@tycho.nsa.gov>
Date: Thu, 27 Sep 2012 12:11:49 -0400
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Organization: National Security Agency
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120911 Thunderbird/15.0.1
MIME-Version: 1.0
To: Tim Deegan <tim@xen.org>
References: <1347895425-17959-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1347895425-17959-19-git-send-email-dgdegra@tycho.nsa.gov>
	<20120927130956.GE8831@ocelot.phlegethon.org>
In-Reply-To: <20120927130956.GE8831@ocelot.phlegethon.org>
Cc: Joe Epstein <jepstein98@gmail.com>, keir@xen.org,
	Jan Beulich <jbeulich@suse.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 18/23] arch/x86: Add missing mem_sharing XSM
 hooks
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 09/27/2012 09:09 AM, Tim Deegan wrote:
> Cc'ing Joe, the author of the original check I'm talking about below. 
> 
> At 11:23 -0400 on 17 Sep (1347881020), Daniel De Graaf wrote:
>> diff --git a/xen/arch/x86/domctl.c b/xen/arch/x86/domctl.c
>> index 24e2d93..7062f02 100644
>> --- a/xen/arch/x86/domctl.c
>> +++ b/xen/arch/x86/domctl.c
>> @@ -1447,10 +1447,8 @@ long arch_do_domctl(
>>          d = rcu_lock_domain_by_id(domctl->domain);
>>          if ( d != NULL )
>>          {
>> -            ret = xsm_mem_event(d);
>> -            if ( !ret )
>> -                ret = mem_event_domctl(d, &domctl->u.mem_event_op,
>> -                                       guest_handle_cast(u_domctl, void));
>> +            ret = mem_event_domctl(d, &domctl->u.mem_event_op,
>> +                                   guest_handle_cast(u_domctl, void));
>>              rcu_unlock_domain(d);
>>              copy_to_guest(u_domctl, domctl, 1);
>>          } 
>> @@ -1506,7 +1504,7 @@ long arch_do_domctl(
>>          d = rcu_lock_domain_by_id(domctl->domain);
>>          if ( d != NULL )
>>          {
>> -            ret = xsm_mem_event(d);
>> +            ret = xsm_mem_event_setup(d);
>>              if ( !ret ) {
>>                  p2m = p2m_get_hostp2m(d);
>>                  p2m->access_required = domctl->u.access_required.access_required;
> 
> [...]
> 
>> diff --git a/xen/include/xsm/dummy.h b/xen/include/xsm/dummy.h
>> index 626a332..5fb0afe 100644
>> --- a/xen/include/xsm/dummy.h
>> +++ b/xen/include/xsm/dummy.h
>> @@ -551,16 +551,37 @@ static XSM_DEFAULT(int, hvm_inject_msi) (struct domain *d)
>>      return 0;
>>  }
>>  
>> -static XSM_DEFAULT(int, mem_event) (struct domain *d)
>> +static XSM_DEFAULT(int, mem_event_setup) (struct domain *d)
>>  {
>>      return 0;
>>  }
> 
> I think this ought to be at least IS_PRIV_FOR.  I can see the original
> code allowed all callers to use it, but surely it ought to be only for
> the tools.  Since only the tools can actually set the mem-access rights
> (and so this is pretty much a noop) I don't think this causes any
> substantial problem but we might as well adjust it anyway.
> 
> Tim.

Because this is a domctl, it already requires IS_PRIV as checked by 
xsm_domctl (and was already checked before this series).

-- 
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 Sep 27 16:12:07 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Sep 2012 16:12: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 1THGgs-00043q-BE; Thu, 27 Sep 2012 16:11:54 +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 1THGgq-00043j-Qj
	for xen-devel@lists.xen.org; Thu, 27 Sep 2012 16:11:53 +0000
Received: from [85.158.143.35:18638] by server-1.bemta-4.messagelabs.com id
	CC/09-05684-8CA74605; Thu, 27 Sep 2012 16:11:52 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-16.tower-21.messagelabs.com!1348762311!13948923!1
X-Originating-IP: [63.239.67.9]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9146 invoked from network); 27 Sep 2012 16:11:51 -0000
Received: from emvm-gh1-uea08.nsa.gov (HELO nsa.gov) (63.239.67.9)
	by server-16.tower-21.messagelabs.com with SMTP;
	27 Sep 2012 16:11:51 -0000
X-TM-IMSS-Message-ID: <872b3e0200191449@nsa.gov>
Received: from tarius.tycho.ncsc.mil ([144.51.3.1]) by nsa.gov ([63.239.67.9])
	with ESMTP (TREND IMSS SMTP Service 7.1) id 872b3e0200191449 ;
	Thu, 27 Sep 2012 12:12:10 -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 q8RGBna8028562; 
	Thu, 27 Sep 2012 12:11:49 -0400
Message-ID: <50647AC5.9080905@tycho.nsa.gov>
Date: Thu, 27 Sep 2012 12:11:49 -0400
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Organization: National Security Agency
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120911 Thunderbird/15.0.1
MIME-Version: 1.0
To: Tim Deegan <tim@xen.org>
References: <1347895425-17959-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1347895425-17959-19-git-send-email-dgdegra@tycho.nsa.gov>
	<20120927130956.GE8831@ocelot.phlegethon.org>
In-Reply-To: <20120927130956.GE8831@ocelot.phlegethon.org>
Cc: Joe Epstein <jepstein98@gmail.com>, keir@xen.org,
	Jan Beulich <jbeulich@suse.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 18/23] arch/x86: Add missing mem_sharing XSM
 hooks
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 09/27/2012 09:09 AM, Tim Deegan wrote:
> Cc'ing Joe, the author of the original check I'm talking about below. 
> 
> At 11:23 -0400 on 17 Sep (1347881020), Daniel De Graaf wrote:
>> diff --git a/xen/arch/x86/domctl.c b/xen/arch/x86/domctl.c
>> index 24e2d93..7062f02 100644
>> --- a/xen/arch/x86/domctl.c
>> +++ b/xen/arch/x86/domctl.c
>> @@ -1447,10 +1447,8 @@ long arch_do_domctl(
>>          d = rcu_lock_domain_by_id(domctl->domain);
>>          if ( d != NULL )
>>          {
>> -            ret = xsm_mem_event(d);
>> -            if ( !ret )
>> -                ret = mem_event_domctl(d, &domctl->u.mem_event_op,
>> -                                       guest_handle_cast(u_domctl, void));
>> +            ret = mem_event_domctl(d, &domctl->u.mem_event_op,
>> +                                   guest_handle_cast(u_domctl, void));
>>              rcu_unlock_domain(d);
>>              copy_to_guest(u_domctl, domctl, 1);
>>          } 
>> @@ -1506,7 +1504,7 @@ long arch_do_domctl(
>>          d = rcu_lock_domain_by_id(domctl->domain);
>>          if ( d != NULL )
>>          {
>> -            ret = xsm_mem_event(d);
>> +            ret = xsm_mem_event_setup(d);
>>              if ( !ret ) {
>>                  p2m = p2m_get_hostp2m(d);
>>                  p2m->access_required = domctl->u.access_required.access_required;
> 
> [...]
> 
>> diff --git a/xen/include/xsm/dummy.h b/xen/include/xsm/dummy.h
>> index 626a332..5fb0afe 100644
>> --- a/xen/include/xsm/dummy.h
>> +++ b/xen/include/xsm/dummy.h
>> @@ -551,16 +551,37 @@ static XSM_DEFAULT(int, hvm_inject_msi) (struct domain *d)
>>      return 0;
>>  }
>>  
>> -static XSM_DEFAULT(int, mem_event) (struct domain *d)
>> +static XSM_DEFAULT(int, mem_event_setup) (struct domain *d)
>>  {
>>      return 0;
>>  }
> 
> I think this ought to be at least IS_PRIV_FOR.  I can see the original
> code allowed all callers to use it, but surely it ought to be only for
> the tools.  Since only the tools can actually set the mem-access rights
> (and so this is pretty much a noop) I don't think this causes any
> substantial problem but we might as well adjust it anyway.
> 
> Tim.

Because this is a domctl, it already requires IS_PRIV as checked by 
xsm_domctl (and was already checked before this series).

-- 
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 Sep 27 16:13:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Sep 2012 16:13: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 1THGic-0004Ax-SW; Thu, 27 Sep 2012 16:13:42 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <singapore.mr.teo.en.ming@gmail.com>)
	id 1THGic-0004Al-00
	for xen-devel@lists.xen.org; Thu, 27 Sep 2012 16:13:42 +0000
Received: from [85.158.143.99:12123] by server-2.bemta-4.messagelabs.com id
	FF/C1-06610-53B74605; Thu, 27 Sep 2012 16:13:41 +0000
X-Env-Sender: singapore.mr.teo.en.ming@gmail.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1348762410!26743314!1
X-Originating-IP: [209.85.160.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	ML_RADAR_SPEW_LINKS_8,RCVD_BY_IP,spamassassin: ,async_handler: 
	YXN5bmNfZGVsYXk6IDcwNDQ0NjcgKHRpbWVvdXQp\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12541 invoked from network); 27 Sep 2012 16:13:32 -0000
Received: from mail-pb0-f45.google.com (HELO mail-pb0-f45.google.com)
	(209.85.160.45)
	by server-4.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Sep 2012 16:13:32 -0000
Received: by pbbrp2 with SMTP id rp2so3960385pbb.32
	for <multiple recipients>; Thu, 27 Sep 2012 09:13:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=message-id:disposition-notification-to:date:from:user-agent
	:mime-version:to:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=wFpnTG8LK1kuq6nC5q57RHTuObyYITBK3j2RAsDroxs=;
	b=F+inHybduULz/MKGLcsWCFxdPVSr4jd17HqC1l486TYMaZXVd8fhQJWg5VTnkg0zOM
	sa8z1Dp1xptacoq0kIuAyLPVqwL2m291rabhRB1HVUqx05+QSIVa2ENChrAQzXHnBHin
	UkMGwSxyGNai0uIEAsF49YkoVj7RBkrHKkMroND0wQycQPw1wr7AN+Pxk3MsQDl7awRA
	4mkAmJXW8KW/2vfldSLSSkhg733A03DJ6kIh/ms4sTXeq4qKRWCCSt0br+8n6l5biHcR
	xOHvV/bBv1oJgg7Rk8H7l34QC68IWbrXHWxLbu5qMyxKSe9I7Lxfec8xchC0C9aUZA82
	8w8Q==
Received: by 10.66.77.40 with SMTP id p8mr10461161paw.78.1348762410398;
	Thu, 27 Sep 2012 09:13:30 -0700 (PDT)
Received: from [192.168.1.2] (cm141.gamma206.maxonline.com.sg.
	[202.156.206.141])
	by mx.google.com with ESMTPS id w4sm3923219pav.27.2012.09.27.09.13.27
	(version=SSLv3 cipher=OTHER); Thu, 27 Sep 2012 09:13:29 -0700 (PDT)
Message-ID: <50647B26.9080903@gmail.com>
Date: Fri, 28 Sep 2012 00:13:26 +0800
From: "Teo En Ming (Zhang Enming)" <singapore.mr.teo.en.ming@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
MIME-Version: 1.0
To: "Mikhail I. Izmestev" <izmmishao5@gmail.com>, 
	"xen-users@lists.xen.org" <xen-users@lists.xen.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>, 
	"Teo En Ming (Zhang Enming)" <singapore.mr.teo.en.ming@gmail.com>
References: <CAAREfm2hodHQ9XOdtn31gQzhyoyJgDmBapiYJgmSHO6Okh2NNg@mail.gmail.com>
	<50645166.2000200@gmail.com>
In-Reply-To: <50645166.2000200@gmail.com>
Subject: Re: [Xen-devel] [Xen-users] Success VGA passthrough on windows 7
 x64 with Xen 4.2.1-pre
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-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/09/2012 21:15, Mikhail I. Izmestev wrote:
> Hi,
>
> 27.09.2012 15:03, Dariusz Krempa wrote:
>> I'm glad i can report that today i have 100% success with VGA
>> passthrough on windows 7 64-bit. That nasty yellow triangle with error
>> 43 disappeared and my GTX560 has 7.8 points in aero index, also Gpu-z
>> and Cpu-z see vga card properly and unigine heaven benchmark have no
>> problem with it.
>> Now i have to figure which particular option let me to do this. Most
>> likely it was turned off msi_translate in DomU config, but i will make
>> more test and i will share with full information today later. Cause
>> i'm newbie with Xen and linux if there is some particular information
>> i can share with, then please tell me and i will try to do that.
>>
>> http://tinypic.com/r/33djtwz/6
>
> One day before I have tried to do this without luck.
>
> My configuration:
> MB: GA-Z77X-D3H with latest bios (F15)
> CPU: core i5-2400
> two GPU GTX560 on 16x and 8x pcie ports (both works on 8x when two used).
>
> DomU: win7 x64 pro
>
> I have tried to do this with XCP 1.5b and XenServer 6.0 Free trial.
>
> There is dmesg for host:
> [root@xenserver-render ~]# xe host-dmesg | grep -i virtualisation
> (XEN) I/O virtualisation enabled
> (XEN)  - APIC MMIO access virtualisation
>
> I just have "nasty yellow triangle with error 43" :)
>
> So I'm interested in your experience and solution.
>
> Mikhail.
>
> _______________________________________________
> Xen-users mailing list
> Xen-users@lists.xen.org
> http://lists.xen.org/xen-users
>

Dear Dariusz Krempa,

I am also interested in knowing how you get the "nasty yellow triangle 
with error 43" to disappear.

In addition, may I know which guide did you follow in getting VGA 
passthrough to work 100%?

Thank you very much.

-- 
Yours sincerely,

Mr. Teo En Ming (Zhang Enming)
Singapore


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 27 16:13:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Sep 2012 16:13: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 1THGic-0004Ax-SW; Thu, 27 Sep 2012 16:13:42 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <singapore.mr.teo.en.ming@gmail.com>)
	id 1THGic-0004Al-00
	for xen-devel@lists.xen.org; Thu, 27 Sep 2012 16:13:42 +0000
Received: from [85.158.143.99:12123] by server-2.bemta-4.messagelabs.com id
	FF/C1-06610-53B74605; Thu, 27 Sep 2012 16:13:41 +0000
X-Env-Sender: singapore.mr.teo.en.ming@gmail.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1348762410!26743314!1
X-Originating-IP: [209.85.160.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	ML_RADAR_SPEW_LINKS_8,RCVD_BY_IP,spamassassin: ,async_handler: 
	YXN5bmNfZGVsYXk6IDcwNDQ0NjcgKHRpbWVvdXQp\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12541 invoked from network); 27 Sep 2012 16:13:32 -0000
Received: from mail-pb0-f45.google.com (HELO mail-pb0-f45.google.com)
	(209.85.160.45)
	by server-4.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Sep 2012 16:13:32 -0000
Received: by pbbrp2 with SMTP id rp2so3960385pbb.32
	for <multiple recipients>; Thu, 27 Sep 2012 09:13:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=message-id:disposition-notification-to:date:from:user-agent
	:mime-version:to:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=wFpnTG8LK1kuq6nC5q57RHTuObyYITBK3j2RAsDroxs=;
	b=F+inHybduULz/MKGLcsWCFxdPVSr4jd17HqC1l486TYMaZXVd8fhQJWg5VTnkg0zOM
	sa8z1Dp1xptacoq0kIuAyLPVqwL2m291rabhRB1HVUqx05+QSIVa2ENChrAQzXHnBHin
	UkMGwSxyGNai0uIEAsF49YkoVj7RBkrHKkMroND0wQycQPw1wr7AN+Pxk3MsQDl7awRA
	4mkAmJXW8KW/2vfldSLSSkhg733A03DJ6kIh/ms4sTXeq4qKRWCCSt0br+8n6l5biHcR
	xOHvV/bBv1oJgg7Rk8H7l34QC68IWbrXHWxLbu5qMyxKSe9I7Lxfec8xchC0C9aUZA82
	8w8Q==
Received: by 10.66.77.40 with SMTP id p8mr10461161paw.78.1348762410398;
	Thu, 27 Sep 2012 09:13:30 -0700 (PDT)
Received: from [192.168.1.2] (cm141.gamma206.maxonline.com.sg.
	[202.156.206.141])
	by mx.google.com with ESMTPS id w4sm3923219pav.27.2012.09.27.09.13.27
	(version=SSLv3 cipher=OTHER); Thu, 27 Sep 2012 09:13:29 -0700 (PDT)
Message-ID: <50647B26.9080903@gmail.com>
Date: Fri, 28 Sep 2012 00:13:26 +0800
From: "Teo En Ming (Zhang Enming)" <singapore.mr.teo.en.ming@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
MIME-Version: 1.0
To: "Mikhail I. Izmestev" <izmmishao5@gmail.com>, 
	"xen-users@lists.xen.org" <xen-users@lists.xen.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>, 
	"Teo En Ming (Zhang Enming)" <singapore.mr.teo.en.ming@gmail.com>
References: <CAAREfm2hodHQ9XOdtn31gQzhyoyJgDmBapiYJgmSHO6Okh2NNg@mail.gmail.com>
	<50645166.2000200@gmail.com>
In-Reply-To: <50645166.2000200@gmail.com>
Subject: Re: [Xen-devel] [Xen-users] Success VGA passthrough on windows 7
 x64 with Xen 4.2.1-pre
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-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/09/2012 21:15, Mikhail I. Izmestev wrote:
> Hi,
>
> 27.09.2012 15:03, Dariusz Krempa wrote:
>> I'm glad i can report that today i have 100% success with VGA
>> passthrough on windows 7 64-bit. That nasty yellow triangle with error
>> 43 disappeared and my GTX560 has 7.8 points in aero index, also Gpu-z
>> and Cpu-z see vga card properly and unigine heaven benchmark have no
>> problem with it.
>> Now i have to figure which particular option let me to do this. Most
>> likely it was turned off msi_translate in DomU config, but i will make
>> more test and i will share with full information today later. Cause
>> i'm newbie with Xen and linux if there is some particular information
>> i can share with, then please tell me and i will try to do that.
>>
>> http://tinypic.com/r/33djtwz/6
>
> One day before I have tried to do this without luck.
>
> My configuration:
> MB: GA-Z77X-D3H with latest bios (F15)
> CPU: core i5-2400
> two GPU GTX560 on 16x and 8x pcie ports (both works on 8x when two used).
>
> DomU: win7 x64 pro
>
> I have tried to do this with XCP 1.5b and XenServer 6.0 Free trial.
>
> There is dmesg for host:
> [root@xenserver-render ~]# xe host-dmesg | grep -i virtualisation
> (XEN) I/O virtualisation enabled
> (XEN)  - APIC MMIO access virtualisation
>
> I just have "nasty yellow triangle with error 43" :)
>
> So I'm interested in your experience and solution.
>
> Mikhail.
>
> _______________________________________________
> Xen-users mailing list
> Xen-users@lists.xen.org
> http://lists.xen.org/xen-users
>

Dear Dariusz Krempa,

I am also interested in knowing how you get the "nasty yellow triangle 
with error 43" to disappear.

In addition, may I know which guide did you follow in getting VGA 
passthrough to work 100%?

Thank you very much.

-- 
Yours sincerely,

Mr. Teo En Ming (Zhang Enming)
Singapore


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 27 16:27:22 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Sep 2012 16:27: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 1THGvc-0004z9-G2; Thu, 27 Sep 2012 16:27:08 +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 1THGvb-0004yz-N8
	for xen-devel@lists.xen.org; Thu, 27 Sep 2012 16:27:07 +0000
Received: from [85.158.138.51:42479] by server-7.bemta-3.messagelabs.com id
	E8/74-15765-A5E74605; Thu, 27 Sep 2012 16:27:06 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-2.tower-174.messagelabs.com!1348763222!32184549!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21220 invoked from network); 27 Sep 2012 16:27:04 -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; 27 Sep 2012 16:27:04 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1THGvU-0003MD-T4; Thu, 27 Sep 2012 16:27:00 +0000
Date: Thu, 27 Sep 2012 17:27:00 +0100
From: Tim Deegan <tim@xen.org>
To: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Message-ID: <20120927162700.GI8831@ocelot.phlegethon.org>
References: <1347895425-17959-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1347895425-17959-19-git-send-email-dgdegra@tycho.nsa.gov>
	<20120927130956.GE8831@ocelot.phlegethon.org>
	<50647AC5.9080905@tycho.nsa.gov>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <50647AC5.9080905@tycho.nsa.gov>
User-Agent: Mutt/1.4.2.1i
Cc: Joe Epstein <jepstein98@gmail.com>, keir@xen.org,
	Jan Beulich <jbeulich@suse.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 18/23] arch/x86: Add missing mem_sharing XSM
	hooks
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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:11 -0400 on 27 Sep (1348747909), Daniel De Graaf wrote:
> > I think this ought to be at least IS_PRIV_FOR.  I can see the original
> > code allowed all callers to use it, but surely it ought to be only for
> > the tools.  Since only the tools can actually set the mem-access rights
> > (and so this is pretty much a noop) I don't think this causes any
> > substantial problem but we might as well adjust it anyway.
> > 
> > Tim.
> 
> Because this is a domctl, it already requires IS_PRIV as checked by 
> xsm_domctl (and was already checked before this series).

OK; in that case you have my ack on this. 

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 27 16:27:22 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Sep 2012 16:27: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 1THGvc-0004z9-G2; Thu, 27 Sep 2012 16:27:08 +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 1THGvb-0004yz-N8
	for xen-devel@lists.xen.org; Thu, 27 Sep 2012 16:27:07 +0000
Received: from [85.158.138.51:42479] by server-7.bemta-3.messagelabs.com id
	E8/74-15765-A5E74605; Thu, 27 Sep 2012 16:27:06 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-2.tower-174.messagelabs.com!1348763222!32184549!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21220 invoked from network); 27 Sep 2012 16:27:04 -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; 27 Sep 2012 16:27:04 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1THGvU-0003MD-T4; Thu, 27 Sep 2012 16:27:00 +0000
Date: Thu, 27 Sep 2012 17:27:00 +0100
From: Tim Deegan <tim@xen.org>
To: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Message-ID: <20120927162700.GI8831@ocelot.phlegethon.org>
References: <1347895425-17959-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1347895425-17959-19-git-send-email-dgdegra@tycho.nsa.gov>
	<20120927130956.GE8831@ocelot.phlegethon.org>
	<50647AC5.9080905@tycho.nsa.gov>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <50647AC5.9080905@tycho.nsa.gov>
User-Agent: Mutt/1.4.2.1i
Cc: Joe Epstein <jepstein98@gmail.com>, keir@xen.org,
	Jan Beulich <jbeulich@suse.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 18/23] arch/x86: Add missing mem_sharing XSM
	hooks
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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:11 -0400 on 27 Sep (1348747909), Daniel De Graaf wrote:
> > I think this ought to be at least IS_PRIV_FOR.  I can see the original
> > code allowed all callers to use it, but surely it ought to be only for
> > the tools.  Since only the tools can actually set the mem-access rights
> > (and so this is pretty much a noop) I don't think this causes any
> > substantial problem but we might as well adjust it anyway.
> > 
> > Tim.
> 
> Because this is a domctl, it already requires IS_PRIV as checked by 
> xsm_domctl (and was already checked before this series).

OK; in that case you have my ack on this. 

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 27 17:12:01 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Sep 2012 17:12:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1THHck-0006JI-Dx; Thu, 27 Sep 2012 17:11:42 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <imperiaonline4@gmail.com>)
	id 1THHJr-0005nk-5N; Thu, 27 Sep 2012 16:52:11 +0000
X-Env-Sender: imperiaonline4@gmail.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1348764723!9321948!1
X-Originating-IP: [209.85.214.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31901 invoked from network); 27 Sep 2012 16:52:04 -0000
Received: from mail-ob0-f173.google.com (HELO mail-ob0-f173.google.com)
	(209.85.214.173)
	by server-8.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Sep 2012 16:52:04 -0000
Received: by obbta14 with SMTP id ta14so2672212obb.32
	for <multiple recipients>; Thu, 27 Sep 2012 09:52: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
	:content-type; bh=R1ba6vW1QaAyIOlAiMT/UQjOLVEfTm4gsTR43NC6gpU=;
	b=VbuMkWBbul5+bKtxsDTXHo3oxDnRe45Bk9S9q1jK+/+6S/gsBs+znYj5ICPqQG88kI
	igdgS2LJC+AlWrbn/kSdpCwhFPwPv38knqB+4/qYGQ3vUBI+jwRCddeivYuxbuv9VtJG
	6q4PSkh4LyzXdbsmN+OAHGWFkR9g/dOn/e/2VxLiCTwWihLG91AXcSYYP/m5zMO+Xcy/
	QSN1rOavEEt+GK+58/tx5TGElSoNixeQEOyVAMdVBigfWcetVa+VJ+7C/5UU9yThaCbq
	XbsjW5l/yW2Y0GORYRRJPlESxqz4Hp0etWMOsJF27VrOJq+AjP7Qzg1O0ALAqUoivHbR
	hK8g==
MIME-Version: 1.0
Received: by 10.182.172.74 with SMTP id ba10mr3600591obc.83.1348764723170;
	Thu, 27 Sep 2012 09:52:03 -0700 (PDT)
Received: by 10.60.146.236 with HTTP; Thu, 27 Sep 2012 09:52:03 -0700 (PDT)
In-Reply-To: <50647B26.9080903@gmail.com>
References: <CAAREfm2hodHQ9XOdtn31gQzhyoyJgDmBapiYJgmSHO6Okh2NNg@mail.gmail.com>
	<50645166.2000200@gmail.com> <50647B26.9080903@gmail.com>
Date: Thu, 27 Sep 2012 18:52:03 +0200
Message-ID: <CAAREfm1h6Y=ezKmwpSFhByC1P0m9LH-bmz5LkvL5p=WickTQ7A@mail.gmail.com>
From: Dariusz Krempa <imperiaonline4@gmail.com>
To: "xen-users@lists.xen.org" <xen-users@lists.xen.org>, 
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
X-Mailman-Approved-At: Thu, 27 Sep 2012 17:11:41 +0000
Subject: Re: [Xen-devel] [Xen-users] Success VGA passthrough on windows 7
	x64 with Xen 4.2.1-pre
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> Dear Dariusz Krempa,
>
> I am also interested in knowing how you get the "nasty yellow triangle with
> error 43" to disappear.
>
> In addition, may I know which guide did you follow in getting VGA
> passthrough to work 100%?
>
> Thank you very much.
>
> --
> Yours sincerely,
>
> Mr. Teo En Ming (Zhang Enming)
> Singapore
>
>
>
> _______________________________________________
> Xen-users mailing list
> Xen-users@lists.xen.org
> http://lists.xen.org/xen-users

I started with guide from You dated 25 march 2012 to build Dom0 and
Xen 4.2, but with few modifications this time.
1) I used kernel 3.6-rc7 for Dom0 -->
http://kernel.org/pub/linux/kernel/v3.x/testing/linux-3.6-rc7.tar.bz2
2) I used Xen from http://xenbits.xen.org/hg/staging/xen-unstable.hg/
3) VGA patch from David's Gis rev 25240
4) I used pciback to hide my gtx560 from Dom0, and for a while i have
had second gfx - hd4850, but now i removed it and i have only gtx560,
still working

and finally I think I know what make that error 43 disappeared. At
first I did comment those lines in DomU config:

#pci_msitranslate = 1
#pci_power_mgmt = 1
#xen_platform_pci=1
#xen_extended_power_mgmt=1

When i had success with installation i start to remove comments and
the one which is nasty is pci_msitranslate. This make some other
problems, like not working USB ports, but ...

If any other information will be needed please let me know.

Hardware:
asus P8H67
asus GTX560 DCII top
4GB ram

System:
ubuntu 12.04
Dom0 kernel 3.6-rc7
DomU windows 7 x64
nvidia drivers 275.33 - but possibly 275.50 also will work

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 27 17:12:01 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Sep 2012 17:12:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1THHck-0006JI-Dx; Thu, 27 Sep 2012 17:11:42 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <imperiaonline4@gmail.com>)
	id 1THHJr-0005nk-5N; Thu, 27 Sep 2012 16:52:11 +0000
X-Env-Sender: imperiaonline4@gmail.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1348764723!9321948!1
X-Originating-IP: [209.85.214.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31901 invoked from network); 27 Sep 2012 16:52:04 -0000
Received: from mail-ob0-f173.google.com (HELO mail-ob0-f173.google.com)
	(209.85.214.173)
	by server-8.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Sep 2012 16:52:04 -0000
Received: by obbta14 with SMTP id ta14so2672212obb.32
	for <multiple recipients>; Thu, 27 Sep 2012 09:52: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
	:content-type; bh=R1ba6vW1QaAyIOlAiMT/UQjOLVEfTm4gsTR43NC6gpU=;
	b=VbuMkWBbul5+bKtxsDTXHo3oxDnRe45Bk9S9q1jK+/+6S/gsBs+znYj5ICPqQG88kI
	igdgS2LJC+AlWrbn/kSdpCwhFPwPv38knqB+4/qYGQ3vUBI+jwRCddeivYuxbuv9VtJG
	6q4PSkh4LyzXdbsmN+OAHGWFkR9g/dOn/e/2VxLiCTwWihLG91AXcSYYP/m5zMO+Xcy/
	QSN1rOavEEt+GK+58/tx5TGElSoNixeQEOyVAMdVBigfWcetVa+VJ+7C/5UU9yThaCbq
	XbsjW5l/yW2Y0GORYRRJPlESxqz4Hp0etWMOsJF27VrOJq+AjP7Qzg1O0ALAqUoivHbR
	hK8g==
MIME-Version: 1.0
Received: by 10.182.172.74 with SMTP id ba10mr3600591obc.83.1348764723170;
	Thu, 27 Sep 2012 09:52:03 -0700 (PDT)
Received: by 10.60.146.236 with HTTP; Thu, 27 Sep 2012 09:52:03 -0700 (PDT)
In-Reply-To: <50647B26.9080903@gmail.com>
References: <CAAREfm2hodHQ9XOdtn31gQzhyoyJgDmBapiYJgmSHO6Okh2NNg@mail.gmail.com>
	<50645166.2000200@gmail.com> <50647B26.9080903@gmail.com>
Date: Thu, 27 Sep 2012 18:52:03 +0200
Message-ID: <CAAREfm1h6Y=ezKmwpSFhByC1P0m9LH-bmz5LkvL5p=WickTQ7A@mail.gmail.com>
From: Dariusz Krempa <imperiaonline4@gmail.com>
To: "xen-users@lists.xen.org" <xen-users@lists.xen.org>, 
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
X-Mailman-Approved-At: Thu, 27 Sep 2012 17:11:41 +0000
Subject: Re: [Xen-devel] [Xen-users] Success VGA passthrough on windows 7
	x64 with Xen 4.2.1-pre
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> Dear Dariusz Krempa,
>
> I am also interested in knowing how you get the "nasty yellow triangle with
> error 43" to disappear.
>
> In addition, may I know which guide did you follow in getting VGA
> passthrough to work 100%?
>
> Thank you very much.
>
> --
> Yours sincerely,
>
> Mr. Teo En Ming (Zhang Enming)
> Singapore
>
>
>
> _______________________________________________
> Xen-users mailing list
> Xen-users@lists.xen.org
> http://lists.xen.org/xen-users

I started with guide from You dated 25 march 2012 to build Dom0 and
Xen 4.2, but with few modifications this time.
1) I used kernel 3.6-rc7 for Dom0 -->
http://kernel.org/pub/linux/kernel/v3.x/testing/linux-3.6-rc7.tar.bz2
2) I used Xen from http://xenbits.xen.org/hg/staging/xen-unstable.hg/
3) VGA patch from David's Gis rev 25240
4) I used pciback to hide my gtx560 from Dom0, and for a while i have
had second gfx - hd4850, but now i removed it and i have only gtx560,
still working

and finally I think I know what make that error 43 disappeared. At
first I did comment those lines in DomU config:

#pci_msitranslate = 1
#pci_power_mgmt = 1
#xen_platform_pci=1
#xen_extended_power_mgmt=1

When i had success with installation i start to remove comments and
the one which is nasty is pci_msitranslate. This make some other
problems, like not working USB ports, but ...

If any other information will be needed please let me know.

Hardware:
asus P8H67
asus GTX560 DCII top
4GB ram

System:
ubuntu 12.04
Dom0 kernel 3.6-rc7
DomU windows 7 x64
nvidia drivers 275.33 - but possibly 275.50 also will work

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 27 17:12:09 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Sep 2012 17:12:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1THHcx-0006Kg-TW; Thu, 27 Sep 2012 17:11:55 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <matthew.fioravante@jhuapl.edu>) id 1THHcv-0006Js-6W
	for xen-devel@lists.xen.org; Thu, 27 Sep 2012 17:11:53 +0000
Received: from [85.158.143.99:8568] by server-1.bemta-4.messagelabs.com id
	82/11-05684-8D884605; Thu, 27 Sep 2012 17:11:52 +0000
X-Env-Sender: matthew.fioravante@jhuapl.edu
X-Msg-Ref: server-15.tower-216.messagelabs.com!1348765909!32023001!1
X-Originating-IP: [128.244.251.36]
X-SpamReason: No, hits=0.0 required=7.0 tests=UNPARSEABLE_RELAY
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10296 invoked from network); 27 Sep 2012 17:11:51 -0000
Received: from pilot.jhuapl.edu (HELO jhuapl.edu) (128.244.251.36)
	by server-15.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 27 Sep 2012 17:11:51 -0000
Received: from ([128.244.207.89])
	by pilot.jhuapl.edu with ESMTP with TLS id 63GHCH1.153802920;
	Thu, 27 Sep 2012 13:11:28 -0400
From: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
To: xen-devel@lists.xen.org, samuel.thibault@ens-lyon.org,
	Ian.Campbell@citrix.com
Date: Thu, 27 Sep 2012 13:09:57 -0400
Message-Id: <1348765802-11314-3-git-send-email-matthew.fioravante@jhuapl.edu>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <1348765802-11314-1-git-send-email-matthew.fioravante@jhuapl.edu>
References: <1348765802-11314-1-git-send-email-matthew.fioravante@jhuapl.edu>
Cc: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
Subject: [Xen-devel] [PATCH 03/11] Add endian, byteswap,
	and wordsize macros to mini-os
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/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 addes byte swapping macros and endian support to mini-os.

Signed-off-by: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
Acked-by: Samuel Thibault <samuel.thibault@ens-lyon.org>

diff --git a/extras/mini-os/include/byteorder.h b/extras/mini-os/include/byteorder.h
new file mode 100644
index 0000000..c0e29df
--- /dev/null
+++ b/extras/mini-os/include/byteorder.h
@@ -0,0 +1,36 @@
+#ifndef MINIOS_BYTEORDER_H
+#define MINIOS_BYTEORDER_H
+
+#include <mini-os/byteswap.h>
+#include <mini-os/endian.h>
+
+#if __BYTE_ORDER == __LITTLE_ENDIAN
+#define be16_to_cpu(v) bswap_16(v)
+#define be32_to_cpu(v) bswap_32(v)
+#define be64_to_cpu(v) bswap_64(v)
+
+#define le16_to_cpu(v) (v)
+#define le32_to_cpu(v) (v)
+#define le64_to_cpu(v) (v)
+
+#else /*__BIG_ENDIAN*/
+#define be16_to_cpu(v) (v)
+#define be32_to_cpu(v) (v)
+#define be64_to_cpu(v) (v)
+
+#define le16_to_cpu(v) bswap_16(v)
+#define le32_to_cpu(v) bswap_32(v)
+#define le64_to_cpu(v) bswap_64(v)
+
+#endif
+
+#define cpu_to_be16(v) be16_to_cpu(v)
+#define cpu_to_be32(v) be32_to_cpu(v)
+#define cpu_to_be64(v) be64_to_cpu(v)
+
+#define cpu_to_le16(v) le16_to_cpu(v)
+#define cpu_to_le32(v) le32_to_cpu(v)
+#define cpu_to_le64(v) le64_to_cpu(v)
+
+
+#endif
diff --git a/extras/mini-os/include/byteswap.h b/extras/mini-os/include/byteswap.h
index 46821ae..992c8bd 100644
--- a/extras/mini-os/include/byteswap.h
+++ b/extras/mini-os/include/byteswap.h
@@ -4,30 +4,36 @@
 /* Unfortunately not provided by newlib.  */
 
 #include <mini-os/types.h>
-static inline uint16_t bswap_16(uint16_t x)
-{
-    return
-    ((((x) & 0xff00) >> 8) | (((x) & 0xff) << 8));
-}
-
-static inline uint32_t bswap_32(uint32_t x)
-{
-    return
-    ((((x) & 0xff000000) >> 24) | (((x) & 0x00ff0000) >>  8) |
-     (((x) & 0x0000ff00) <<  8) | (((x) & 0x000000ff) << 24));
-}
-
-static inline uint64_t bswap_64(uint64_t x)
-{
-    return
-    ((((x) & 0xff00000000000000ULL) >> 56) |
-     (((x) & 0x00ff000000000000ULL) >> 40) |
-     (((x) & 0x0000ff0000000000ULL) >> 24) |
-     (((x) & 0x000000ff00000000ULL) >>  8) |
-     (((x) & 0x00000000ff000000ULL) <<  8) |
-     (((x) & 0x0000000000ff0000ULL) << 24) |
-     (((x) & 0x000000000000ff00ULL) << 40) |
-     (((x) & 0x00000000000000ffULL) << 56));
-}
+
+#define bswap_16(x) ((uint16_t)(                         \
+	         (((uint16_t)(x) & (uint16_t)0x00ffU) << 8) |                  \
+	         (((uint16_t)(x) & (uint16_t)0xff00U) >> 8)))
+
+/* Use gcc optimized versions if they exist */
+#if __GNUC__ > 4 || (__GNUC__ == 4 && __GNUC_MINOR__ >= 3)
+#define bswap_32(v) __builtin_bswap32(v)
+#define bswap_64(v) __builtin_bswap64(v)
+#else
+
+#define bswap_32(x) ((uint32_t)(                         \
+	         (((uint32_t)(x) & (uint32_t)0x000000ffUL) << 24) |            \
+	         (((uint32_t)(x) & (uint32_t)0x0000ff00UL) <<  8) |            \
+	         (((uint32_t)(x) & (uint32_t)0x00ff0000UL) >>  8) |            \
+	         (((uint32_t)(x) & (uint32_t)0xff000000UL) >> 24)))
+
+#define bswap_64(x) ((uint64_t)(                         \
+	         (((uint64_t)(x) & (uint64_t)0x00000000000000ffULL) << 56) |   \
+	         (((uint64_t)(x) & (uint64_t)0x000000000000ff00ULL) << 40) |   \
+	         (((uint64_t)(x) & (uint64_t)0x0000000000ff0000ULL) << 24) |   \
+	         (((uint64_t)(x) & (uint64_t)0x00000000ff000000ULL) <<  8) |   \
+	         (((uint64_t)(x) & (uint64_t)0x000000ff00000000ULL) >>  8) |   \
+	         (((uint64_t)(x) & (uint64_t)0x0000ff0000000000ULL) >> 24) |   \
+	         (((uint64_t)(x) & (uint64_t)0x00ff000000000000ULL) >> 40) |   \
+	         (((uint64_t)(x) & (uint64_t)0xff00000000000000ULL) >> 56)))
+
+#endif
+
+
+
 
 #endif /* _BYTESWAP_H */
diff --git a/extras/mini-os/include/endian.h b/extras/mini-os/include/endian.h
new file mode 100644
index 0000000..cdf432b
--- /dev/null
+++ b/extras/mini-os/include/endian.h
@@ -0,0 +1,15 @@
+#ifndef	_ENDIAN_H_
+#define	_ENDIAN_H_
+
+#define	__LITTLE_ENDIAN	1234
+#define	__BIG_ENDIAN	4321
+#define	__PDP_ENDIAN	3412
+
+#define ARCH_ENDIAN_H
+/* This will define __BYTE_ORDER for the current arch */
+#include <arch_endian.h>
+#undef ARCH_ENDIAN_H
+
+#include <arch_wordsize.h>
+
+#endif	/* endian.h */
diff --git a/extras/mini-os/include/ia64/arch_endian.h b/extras/mini-os/include/ia64/arch_endian.h
new file mode 100644
index 0000000..0771683
--- /dev/null
+++ b/extras/mini-os/include/ia64/arch_endian.h
@@ -0,0 +1,7 @@
+#ifndef	ARCH_ENDIAN_H
+#error "Do not include arch_endian by itself, include endian.h"
+#else
+
+#define __BYTE_ORDER __LITTLE_ENDIAN
+
+#endif
diff --git a/extras/mini-os/include/ia64/arch_wordsize.h b/extras/mini-os/include/ia64/arch_wordsize.h
new file mode 100644
index 0000000..1b5a00f
--- /dev/null
+++ b/extras/mini-os/include/ia64/arch_wordsize.h
@@ -0,0 +1 @@
+#define __WORDSIZE 64
diff --git a/extras/mini-os/include/x86/arch_endian.h b/extras/mini-os/include/x86/arch_endian.h
new file mode 100644
index 0000000..0771683
--- /dev/null
+++ b/extras/mini-os/include/x86/arch_endian.h
@@ -0,0 +1,7 @@
+#ifndef	ARCH_ENDIAN_H
+#error "Do not include arch_endian by itself, include endian.h"
+#else
+
+#define __BYTE_ORDER __LITTLE_ENDIAN
+
+#endif
diff --git a/extras/mini-os/include/x86/x86_32/arch_wordsize.h b/extras/mini-os/include/x86/x86_32/arch_wordsize.h
new file mode 100644
index 0000000..b47eee9
--- /dev/null
+++ b/extras/mini-os/include/x86/x86_32/arch_wordsize.h
@@ -0,0 +1 @@
+#define __WORDSIZE 32
diff --git a/extras/mini-os/include/x86/x86_64/arch_wordsize.h b/extras/mini-os/include/x86/x86_64/arch_wordsize.h
new file mode 100644
index 0000000..3048136
--- /dev/null
+++ b/extras/mini-os/include/x86/x86_64/arch_wordsize.h
@@ -0,0 +1,2 @@
+#define __WORDSIZE 64
+#define __WORDSIZE_COMPAT32 1
-- 
1.7.9.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 27 17:12:09 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Sep 2012 17:12:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1THHcx-0006Kg-TW; Thu, 27 Sep 2012 17:11:55 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <matthew.fioravante@jhuapl.edu>) id 1THHcv-0006Js-6W
	for xen-devel@lists.xen.org; Thu, 27 Sep 2012 17:11:53 +0000
Received: from [85.158.143.99:8568] by server-1.bemta-4.messagelabs.com id
	82/11-05684-8D884605; Thu, 27 Sep 2012 17:11:52 +0000
X-Env-Sender: matthew.fioravante@jhuapl.edu
X-Msg-Ref: server-15.tower-216.messagelabs.com!1348765909!32023001!1
X-Originating-IP: [128.244.251.36]
X-SpamReason: No, hits=0.0 required=7.0 tests=UNPARSEABLE_RELAY
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10296 invoked from network); 27 Sep 2012 17:11:51 -0000
Received: from pilot.jhuapl.edu (HELO jhuapl.edu) (128.244.251.36)
	by server-15.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 27 Sep 2012 17:11:51 -0000
Received: from ([128.244.207.89])
	by pilot.jhuapl.edu with ESMTP with TLS id 63GHCH1.153802920;
	Thu, 27 Sep 2012 13:11:28 -0400
From: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
To: xen-devel@lists.xen.org, samuel.thibault@ens-lyon.org,
	Ian.Campbell@citrix.com
Date: Thu, 27 Sep 2012 13:09:57 -0400
Message-Id: <1348765802-11314-3-git-send-email-matthew.fioravante@jhuapl.edu>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <1348765802-11314-1-git-send-email-matthew.fioravante@jhuapl.edu>
References: <1348765802-11314-1-git-send-email-matthew.fioravante@jhuapl.edu>
Cc: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
Subject: [Xen-devel] [PATCH 03/11] Add endian, byteswap,
	and wordsize macros to mini-os
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/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 addes byte swapping macros and endian support to mini-os.

Signed-off-by: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
Acked-by: Samuel Thibault <samuel.thibault@ens-lyon.org>

diff --git a/extras/mini-os/include/byteorder.h b/extras/mini-os/include/byteorder.h
new file mode 100644
index 0000000..c0e29df
--- /dev/null
+++ b/extras/mini-os/include/byteorder.h
@@ -0,0 +1,36 @@
+#ifndef MINIOS_BYTEORDER_H
+#define MINIOS_BYTEORDER_H
+
+#include <mini-os/byteswap.h>
+#include <mini-os/endian.h>
+
+#if __BYTE_ORDER == __LITTLE_ENDIAN
+#define be16_to_cpu(v) bswap_16(v)
+#define be32_to_cpu(v) bswap_32(v)
+#define be64_to_cpu(v) bswap_64(v)
+
+#define le16_to_cpu(v) (v)
+#define le32_to_cpu(v) (v)
+#define le64_to_cpu(v) (v)
+
+#else /*__BIG_ENDIAN*/
+#define be16_to_cpu(v) (v)
+#define be32_to_cpu(v) (v)
+#define be64_to_cpu(v) (v)
+
+#define le16_to_cpu(v) bswap_16(v)
+#define le32_to_cpu(v) bswap_32(v)
+#define le64_to_cpu(v) bswap_64(v)
+
+#endif
+
+#define cpu_to_be16(v) be16_to_cpu(v)
+#define cpu_to_be32(v) be32_to_cpu(v)
+#define cpu_to_be64(v) be64_to_cpu(v)
+
+#define cpu_to_le16(v) le16_to_cpu(v)
+#define cpu_to_le32(v) le32_to_cpu(v)
+#define cpu_to_le64(v) le64_to_cpu(v)
+
+
+#endif
diff --git a/extras/mini-os/include/byteswap.h b/extras/mini-os/include/byteswap.h
index 46821ae..992c8bd 100644
--- a/extras/mini-os/include/byteswap.h
+++ b/extras/mini-os/include/byteswap.h
@@ -4,30 +4,36 @@
 /* Unfortunately not provided by newlib.  */
 
 #include <mini-os/types.h>
-static inline uint16_t bswap_16(uint16_t x)
-{
-    return
-    ((((x) & 0xff00) >> 8) | (((x) & 0xff) << 8));
-}
-
-static inline uint32_t bswap_32(uint32_t x)
-{
-    return
-    ((((x) & 0xff000000) >> 24) | (((x) & 0x00ff0000) >>  8) |
-     (((x) & 0x0000ff00) <<  8) | (((x) & 0x000000ff) << 24));
-}
-
-static inline uint64_t bswap_64(uint64_t x)
-{
-    return
-    ((((x) & 0xff00000000000000ULL) >> 56) |
-     (((x) & 0x00ff000000000000ULL) >> 40) |
-     (((x) & 0x0000ff0000000000ULL) >> 24) |
-     (((x) & 0x000000ff00000000ULL) >>  8) |
-     (((x) & 0x00000000ff000000ULL) <<  8) |
-     (((x) & 0x0000000000ff0000ULL) << 24) |
-     (((x) & 0x000000000000ff00ULL) << 40) |
-     (((x) & 0x00000000000000ffULL) << 56));
-}
+
+#define bswap_16(x) ((uint16_t)(                         \
+	         (((uint16_t)(x) & (uint16_t)0x00ffU) << 8) |                  \
+	         (((uint16_t)(x) & (uint16_t)0xff00U) >> 8)))
+
+/* Use gcc optimized versions if they exist */
+#if __GNUC__ > 4 || (__GNUC__ == 4 && __GNUC_MINOR__ >= 3)
+#define bswap_32(v) __builtin_bswap32(v)
+#define bswap_64(v) __builtin_bswap64(v)
+#else
+
+#define bswap_32(x) ((uint32_t)(                         \
+	         (((uint32_t)(x) & (uint32_t)0x000000ffUL) << 24) |            \
+	         (((uint32_t)(x) & (uint32_t)0x0000ff00UL) <<  8) |            \
+	         (((uint32_t)(x) & (uint32_t)0x00ff0000UL) >>  8) |            \
+	         (((uint32_t)(x) & (uint32_t)0xff000000UL) >> 24)))
+
+#define bswap_64(x) ((uint64_t)(                         \
+	         (((uint64_t)(x) & (uint64_t)0x00000000000000ffULL) << 56) |   \
+	         (((uint64_t)(x) & (uint64_t)0x000000000000ff00ULL) << 40) |   \
+	         (((uint64_t)(x) & (uint64_t)0x0000000000ff0000ULL) << 24) |   \
+	         (((uint64_t)(x) & (uint64_t)0x00000000ff000000ULL) <<  8) |   \
+	         (((uint64_t)(x) & (uint64_t)0x000000ff00000000ULL) >>  8) |   \
+	         (((uint64_t)(x) & (uint64_t)0x0000ff0000000000ULL) >> 24) |   \
+	         (((uint64_t)(x) & (uint64_t)0x00ff000000000000ULL) >> 40) |   \
+	         (((uint64_t)(x) & (uint64_t)0xff00000000000000ULL) >> 56)))
+
+#endif
+
+
+
 
 #endif /* _BYTESWAP_H */
diff --git a/extras/mini-os/include/endian.h b/extras/mini-os/include/endian.h
new file mode 100644
index 0000000..cdf432b
--- /dev/null
+++ b/extras/mini-os/include/endian.h
@@ -0,0 +1,15 @@
+#ifndef	_ENDIAN_H_
+#define	_ENDIAN_H_
+
+#define	__LITTLE_ENDIAN	1234
+#define	__BIG_ENDIAN	4321
+#define	__PDP_ENDIAN	3412
+
+#define ARCH_ENDIAN_H
+/* This will define __BYTE_ORDER for the current arch */
+#include <arch_endian.h>
+#undef ARCH_ENDIAN_H
+
+#include <arch_wordsize.h>
+
+#endif	/* endian.h */
diff --git a/extras/mini-os/include/ia64/arch_endian.h b/extras/mini-os/include/ia64/arch_endian.h
new file mode 100644
index 0000000..0771683
--- /dev/null
+++ b/extras/mini-os/include/ia64/arch_endian.h
@@ -0,0 +1,7 @@
+#ifndef	ARCH_ENDIAN_H
+#error "Do not include arch_endian by itself, include endian.h"
+#else
+
+#define __BYTE_ORDER __LITTLE_ENDIAN
+
+#endif
diff --git a/extras/mini-os/include/ia64/arch_wordsize.h b/extras/mini-os/include/ia64/arch_wordsize.h
new file mode 100644
index 0000000..1b5a00f
--- /dev/null
+++ b/extras/mini-os/include/ia64/arch_wordsize.h
@@ -0,0 +1 @@
+#define __WORDSIZE 64
diff --git a/extras/mini-os/include/x86/arch_endian.h b/extras/mini-os/include/x86/arch_endian.h
new file mode 100644
index 0000000..0771683
--- /dev/null
+++ b/extras/mini-os/include/x86/arch_endian.h
@@ -0,0 +1,7 @@
+#ifndef	ARCH_ENDIAN_H
+#error "Do not include arch_endian by itself, include endian.h"
+#else
+
+#define __BYTE_ORDER __LITTLE_ENDIAN
+
+#endif
diff --git a/extras/mini-os/include/x86/x86_32/arch_wordsize.h b/extras/mini-os/include/x86/x86_32/arch_wordsize.h
new file mode 100644
index 0000000..b47eee9
--- /dev/null
+++ b/extras/mini-os/include/x86/x86_32/arch_wordsize.h
@@ -0,0 +1 @@
+#define __WORDSIZE 32
diff --git a/extras/mini-os/include/x86/x86_64/arch_wordsize.h b/extras/mini-os/include/x86/x86_64/arch_wordsize.h
new file mode 100644
index 0000000..3048136
--- /dev/null
+++ b/extras/mini-os/include/x86/x86_64/arch_wordsize.h
@@ -0,0 +1,2 @@
+#define __WORDSIZE 64
+#define __WORDSIZE_COMPAT32 1
-- 
1.7.9.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 27 17:12:09 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Sep 2012 17:12:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1THHcw-0006KK-QL; Thu, 27 Sep 2012 17:11:54 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <matthew.fioravante@jhuapl.edu>) id 1THHcu-0006Jo-NZ
	for xen-devel@lists.xen.org; Thu, 27 Sep 2012 17:11:52 +0000
Received: from [85.158.139.211:52200] by server-3.bemta-5.messagelabs.com id
	FB/98-16108-7D884605; Thu, 27 Sep 2012 17:11:51 +0000
X-Env-Sender: matthew.fioravante@jhuapl.edu
X-Msg-Ref: server-15.tower-206.messagelabs.com!1348765909!20273396!1
X-Originating-IP: [128.244.251.36]
X-SpamReason: No, hits=0.0 required=7.0 tests=UNPARSEABLE_RELAY
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16103 invoked from network); 27 Sep 2012 17:11:51 -0000
Received: from pilot.jhuapl.edu (HELO jhuapl.edu) (128.244.251.36)
	by server-15.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 27 Sep 2012 17:11:51 -0000
Received: from ([128.244.207.89])
	by pilot.jhuapl.edu with ESMTP with TLS id 63GHCH1.153802928;
	Thu, 27 Sep 2012 13:11:28 -0400
From: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
To: xen-devel@lists.xen.org, samuel.thibault@ens-lyon.org,
	Ian.Campbell@citrix.com
Date: Thu, 27 Sep 2012 13:10:01 -0400
Message-Id: <1348765802-11314-7-git-send-email-matthew.fioravante@jhuapl.edu>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <1348765802-11314-1-git-send-email-matthew.fioravante@jhuapl.edu>
References: <1348765802-11314-1-git-send-email-matthew.fioravante@jhuapl.edu>
Cc: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
Subject: [Xen-devel] [PATCH 07/11] setup fpu and sse in mini-os
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This patch adds floating point and sse support to mini-os by
initializing the floating point unit and the see unit during
domain boot up.

Signed-off-by: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
Acked-by: Samuel Thibault <samuel.thibault@ens-lyon.org>

diff --git a/extras/mini-os/arch/x86/setup.c b/extras/mini-os/arch/x86/setup.c
index 923901e..54046d3 100644
--- a/extras/mini-os/arch/x86/setup.c
+++ b/extras/mini-os/arch/x86/setup.c
@@ -74,9 +74,28 @@ shared_info_t *map_shared_info(unsigned long pa)
 	return (shared_info_t *)shared_info;
 }
 
+static inline void fpu_init(void) {
+	asm volatile("fninit");
+}
+
+#ifdef __SSE__
+static inline void sse_init(void) {
+	unsigned long status = 0x1f80;
+	asm volatile("ldmxcsr %0" : : "m" (status));
+}
+#else
+#define sse_init()
+#endif
+
 void
 arch_init(start_info_t *si)
 {
+	/*Initialize floating point unit */
+        fpu_init();
+
+        /* Initialize SSE */
+        sse_init();
+
 	/* Copy the start_info struct to a globally-accessible area. */
 	/* WARN: don't do printk before here, it uses information from
 	   shared_info. Use xprintk instead. */
@@ -99,6 +118,7 @@ arch_init(start_info_t *si)
 		(unsigned long)failsafe_callback, 0);
 #endif
 
+
 }
 
 void
-- 
1.7.9.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 27 17:12:09 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Sep 2012 17:12:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1THHcw-0006KK-QL; Thu, 27 Sep 2012 17:11:54 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <matthew.fioravante@jhuapl.edu>) id 1THHcu-0006Jo-NZ
	for xen-devel@lists.xen.org; Thu, 27 Sep 2012 17:11:52 +0000
Received: from [85.158.139.211:52200] by server-3.bemta-5.messagelabs.com id
	FB/98-16108-7D884605; Thu, 27 Sep 2012 17:11:51 +0000
X-Env-Sender: matthew.fioravante@jhuapl.edu
X-Msg-Ref: server-15.tower-206.messagelabs.com!1348765909!20273396!1
X-Originating-IP: [128.244.251.36]
X-SpamReason: No, hits=0.0 required=7.0 tests=UNPARSEABLE_RELAY
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16103 invoked from network); 27 Sep 2012 17:11:51 -0000
Received: from pilot.jhuapl.edu (HELO jhuapl.edu) (128.244.251.36)
	by server-15.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 27 Sep 2012 17:11:51 -0000
Received: from ([128.244.207.89])
	by pilot.jhuapl.edu with ESMTP with TLS id 63GHCH1.153802928;
	Thu, 27 Sep 2012 13:11:28 -0400
From: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
To: xen-devel@lists.xen.org, samuel.thibault@ens-lyon.org,
	Ian.Campbell@citrix.com
Date: Thu, 27 Sep 2012 13:10:01 -0400
Message-Id: <1348765802-11314-7-git-send-email-matthew.fioravante@jhuapl.edu>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <1348765802-11314-1-git-send-email-matthew.fioravante@jhuapl.edu>
References: <1348765802-11314-1-git-send-email-matthew.fioravante@jhuapl.edu>
Cc: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
Subject: [Xen-devel] [PATCH 07/11] setup fpu and sse in mini-os
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This patch adds floating point and sse support to mini-os by
initializing the floating point unit and the see unit during
domain boot up.

Signed-off-by: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
Acked-by: Samuel Thibault <samuel.thibault@ens-lyon.org>

diff --git a/extras/mini-os/arch/x86/setup.c b/extras/mini-os/arch/x86/setup.c
index 923901e..54046d3 100644
--- a/extras/mini-os/arch/x86/setup.c
+++ b/extras/mini-os/arch/x86/setup.c
@@ -74,9 +74,28 @@ shared_info_t *map_shared_info(unsigned long pa)
 	return (shared_info_t *)shared_info;
 }
 
+static inline void fpu_init(void) {
+	asm volatile("fninit");
+}
+
+#ifdef __SSE__
+static inline void sse_init(void) {
+	unsigned long status = 0x1f80;
+	asm volatile("ldmxcsr %0" : : "m" (status));
+}
+#else
+#define sse_init()
+#endif
+
 void
 arch_init(start_info_t *si)
 {
+	/*Initialize floating point unit */
+        fpu_init();
+
+        /* Initialize SSE */
+        sse_init();
+
 	/* Copy the start_info struct to a globally-accessible area. */
 	/* WARN: don't do printk before here, it uses information from
 	   shared_info. Use xprintk instead. */
@@ -99,6 +118,7 @@ arch_init(start_info_t *si)
 		(unsigned long)failsafe_callback, 0);
 #endif
 
+
 }
 
 void
-- 
1.7.9.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 27 17:12:09 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Sep 2012 17:12:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1THHd1-0006MR-Ju; Thu, 27 Sep 2012 17:11:59 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <matthew.fioravante@jhuapl.edu>) id 1THHcz-0006L3-C7
	for xen-devel@lists.xen.org; Thu, 27 Sep 2012 17:11:58 +0000
Received: from [85.158.139.83:6566] by server-4.bemta-5.messagelabs.com id
	25/E6-20767-CD884605; Thu, 27 Sep 2012 17:11:56 +0000
X-Env-Sender: matthew.fioravante@jhuapl.edu
X-Msg-Ref: server-4.tower-182.messagelabs.com!1348765910!27902458!1
X-Originating-IP: [128.244.251.36]
X-SpamReason: No, hits=0.0 required=7.0 tests=UNPARSEABLE_RELAY
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12757 invoked from network); 27 Sep 2012 17:11:51 -0000
Received: from pilot.jhuapl.edu (HELO jhuapl.edu) (128.244.251.36)
	by server-4.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 27 Sep 2012 17:11:51 -0000
Received: from ([128.244.207.89])
	by pilot.jhuapl.edu with ESMTP with TLS id 63GHCH1.153802930;
	Thu, 27 Sep 2012 13:11:28 -0400
From: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
To: xen-devel@lists.xen.org, samuel.thibault@ens-lyon.org,
	Ian.Campbell@citrix.com
Date: Thu, 27 Sep 2012 13:10:02 -0400
Message-Id: <1348765802-11314-8-git-send-email-matthew.fioravante@jhuapl.edu>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <1348765802-11314-1-git-send-email-matthew.fioravante@jhuapl.edu>
References: <1348765802-11314-1-git-send-email-matthew.fioravante@jhuapl.edu>
Cc: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
Subject: [Xen-devel] [PATCH 08/11] add tpmfront, tpm_tis,
	and tpmback drivers to mini-os
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This patch adds 3 new drivers to mini-os.

tpmfront - paravirtualized tpm frontend driver
tpmback - paravirtualized tpm backend driver
tpm_tis - hardware tpm driver

Unfortunately these drivers were derived from GPL
licensed linux kernel drivers so they must carry
the GPL license. However, since mini-os now
supports conditional compilation, hopefully these
drivers can be included into the xen tree and
conditionally removed from non-gpl projects.
By default they are disabled in the makefile.

Signed-off-by: Matthew Fioravante <matthew.fioravante@jhuapl.edu>

diff --git a/extras/mini-os/Makefile b/extras/mini-os/Makefile
index b4236e8..02fab14 100644
--- a/extras/mini-os/Makefile
+++ b/extras/mini-os/Makefile
@@ -22,6 +22,9 @@ CONFIG_QEMU_XS_ARGS ?= n
 CONFIG_TEST ?= n
 CONFIG_PCIFRONT ?= n
 CONFIG_BLKFRONT ?= y
+CONFIG_TPMFRONT ?= n
+CONFIG_TPM_TIS ?= n
+CONFIG_TPMBACK ?= n
 CONFIG_NETFRONT ?= y
 CONFIG_FBFRONT ?= y
 CONFIG_KBDFRONT ?= y
@@ -36,6 +39,9 @@ flags-$(CONFIG_SPARSE_BSS) += -DCONFIG_SPARSE_BSS
 flags-$(CONFIG_QEMU_XS_ARGS) += -DCONFIG_QEMU_XS_ARGS
 flags-$(CONFIG_PCIFRONT) += -DCONFIG_PCIFRONT
 flags-$(CONFIG_BLKFRONT) += -DCONFIG_BLKFRONT
+flags-$(CONFIG_TPMFRONT) += -DCONFIG_TPMFRONT
+flags-$(CONFIG_TPM_TIS) += -DCONFIG_TPM_TIS
+flags-$(CONFIG_TPMBACK) += -DCONFIG_TPMBACK
 flags-$(CONFIG_NETFRONT) += -DCONFIG_NETFRONT
 flags-$(CONFIG_KBDFRONT) += -DCONFIG_KBDFRONT
 flags-$(CONFIG_FBFRONT) += -DCONFIG_FBFRONT
@@ -67,6 +73,9 @@ TARGET := mini-os
 SUBDIRS := lib xenbus console
 
 src-$(CONFIG_BLKFRONT) += blkfront.c
+src-$(CONFIG_TPMFRONT) += tpmfront.c
+src-$(CONFIG_TPM_TIS) += tpm_tis.c
+src-$(CONFIG_TPMBACK) += tpmback.c
 src-y += daytime.c
 src-y += events.c
 src-$(CONFIG_FBFRONT) += fbfront.c
diff --git a/extras/mini-os/include/lib.h b/extras/mini-os/include/lib.h
index d4641b6..935bede 100644
--- a/extras/mini-os/include/lib.h
+++ b/extras/mini-os/include/lib.h
@@ -142,6 +142,8 @@ enum fd_type {
     FTYPE_FB,
     FTYPE_MEM,
     FTYPE_SAVEFILE,
+    FTYPE_TPMFRONT,
+    FTYPE_TPM_TIS,
 };
 
 LIST_HEAD(evtchn_port_list, evtchn_port_info);
@@ -185,6 +187,20 @@ extern struct file {
 	struct {
 	    struct consfront_dev *dev;
 	} cons;
+#ifdef CONFIG_TPMFRONT
+	struct {
+	   struct tpmfront_dev *dev;
+	   int respgot;
+	   off_t offset;
+	} tpmfront;
+#endif
+#ifdef CONFIG_TPM_TIS
+	struct {
+	   struct tpm_chip *dev;
+	   int respgot;
+	   off_t offset;
+	} tpm_tis;
+#endif
 #ifdef CONFIG_XENBUS
         struct {
             /* To each xenbus FD is associated a queue of watch events for this
diff --git a/extras/mini-os/include/tpm_tis.h b/extras/mini-os/include/tpm_tis.h
new file mode 100644
index 0000000..b463cea
--- /dev/null
+++ b/extras/mini-os/include/tpm_tis.h
@@ -0,0 +1,74 @@
+/*
+ * Copyright (c) 2010-2012 United States Government, as represented by
+ * the Secretary of Defense.  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 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.
+ *
+ * Based upon the files:
+ *  drivers/char/tpm/tpm_tis.c
+ *  drivers/char/tpm/tpm.c
+ * from the Linux kernel, which are Copyright (C) 2006 IBM Corporation
+ */
+#ifndef TPM_TIS_H
+#define TPM_TIS_H
+
+#include <mini-os/types.h>
+#include <mini-os/byteorder.h>
+
+#define TPM_TIS_EN_LOCL0 1
+#define TPM_TIS_EN_LOCL1 (1 << 1)
+#define TPM_TIS_EN_LOCL2 (1 << 2)
+#define TPM_TIS_EN_LOCL3 (1 << 3)
+#define TPM_TIS_EN_LOCL4 (1 << 4)
+#define TPM_TIS_EN_LOCLALL (TPM_TIS_EN_LOCL0 | TPM_TIS_EN_LOCL1  | TPM_TIS_EN_LOCL2 | TPM_TIS_EN_LOCL3 | TPM_TIS_EN_LOCL4)
+#define TPM_TIS_LOCL_INT_TO_FLAG(x) (1 << x)
+#define TPM_BASEADDR 0xFED40000
+#define TPM_PROBE_IRQ 0xFFFF
+
+struct tpm_chip;
+
+struct tpm_chip* init_tpm_tis(unsigned long baseaddr, int localities, unsigned int irq);
+void shutdown_tpm_tis(struct tpm_chip* tpm);
+
+int tpm_tis_request_locality(struct tpm_chip* tpm, int locality);
+int tpm_tis_cmd(struct tpm_chip* tpm, uint8_t* req, size_t reqlen, uint8_t** resp, size_t* resplen);
+
+#ifdef HAVE_LIBC
+#include <sys/stat.h>
+#include <fcntl.h>
+/* POSIX IO functions:
+ * use tpm_tis_open() to get a file descriptor to the tpm device
+ * use write() on the fd to send a command to the backend. You must
+ * include the entire command in a single call to write().
+ * use read() on the fd to read the response. You can use
+ * fstat() to get the size of the response and lseek() to seek on it.
+ */
+int tpm_tis_open(struct tpm_chip* tpm);
+int tpm_tis_posix_read(int fd, uint8_t* buf, size_t count);
+int tpm_tis_posix_write(int fd, const uint8_t* buf, size_t count);
+int tpm_tis_posix_fstat(int fd, struct stat* buf);
+#endif
+
+#endif
diff --git a/extras/mini-os/include/tpmback.h b/extras/mini-os/include/tpmback.h
new file mode 100644
index 0000000..bc41d2c
--- /dev/null
+++ b/extras/mini-os/include/tpmback.h
@@ -0,0 +1,106 @@
+/*
+ * Copyright (c) 2010-2012 United States Government, as represented by
+ * the Secretary of Defense.  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 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.
+ *
+ * Based upon the files:
+ *  drivers/xen/tpmbk.c
+ * from the Linux kernel, which are Copyright (C) 2006 IBM Corporation
+ */
+#include <xen/io/tpmif.h>
+#include <xen/io/xenbus.h>
+#include <mini-os/types.h>
+#include <xen/xen.h>
+#ifndef TPMBACK_H
+#define TPMBACK_H
+
+struct tpmcmd {
+   domid_t domid;		/* Domid of the frontend */
+   unsigned int handle;	/* Handle of the frontend */
+   char* uuid;			/* uuid of the tpm interface - allocated internally, dont free it */
+
+   unsigned int req_len;		/* Size of the command in buf - set by tpmback driver */
+   uint8_t* req;			/* tpm command bits, allocated by driver, DON'T FREE IT */
+   unsigned int resp_len;	/* Size of the outgoing command,
+				   you set this before passing the cmd object to tpmback_resp */
+   uint8_t* resp;		/* Buffer for response - YOU MUST ALLOCATE IT, YOU MUST ALSO FREE IT */
+};
+typedef struct tpmcmd tpmcmd_t;
+
+/* Initialize the tpm backend driver
+ * @exclusive_domname - This is NULL terminated list of vtpm uuid strings. If this list
+ * 			is non-empty, then only frontend domains with vtpm uuid's matching
+ * 			entries in this list will be allowed to connect.
+ * 			Other connections will be immediatly closed.
+ * 			Set this argument to NULL to allow any vtpm to connect.
+ */
+void init_tpmback(char** exclusive_uuids);
+/* Shutdown tpm backend driver */
+void shutdown_tpmback(void);
+
+/* Blocks until a tpm command is sent from any front end.
+ * Returns a pointer to the tpm command to handle.
+ * Do not try to free this pointer or the req buffer
+ * This function will return NULL if the tpm backend driver
+ * is shutdown or any other error occurs */
+tpmcmd_t* tpmback_req_any(void);
+
+/* Blocks until a tpm command from the frontend at domid/handle
+ * is sent.
+ * Returns NULL if domid/handle is not connected, tpmback is
+ * shutdown or shutting down, or if there is an error
+ */
+tpmcmd_t* tpmback_req(domid_t domid, unsigned int handle);
+
+/* Send the response to the tpm command back to the frontend
+ * This function will free the tpmcmd object, but you must free the resp
+ * buffer yourself */
+void tpmback_resp(tpmcmd_t* tpmcmd);
+
+/* Waits for the first frontend to connect and then sets domid and handle appropriately.
+ * If one or more frontends are already connected, this will set domid and handle to one
+ * of them arbitrarily. The main use for this function is to wait until a single
+ * frontend connection has occured.
+ * returns 0 on success, non-zero on failure */
+int tpmback_wait_for_frontend_connect(domid_t *domid, unsigned int *handle);
+
+/* returns the number of frontends connected */
+int tpmback_num_frontends(void);
+
+/* Returns the uuid of the specified frontend, NULL on error */
+char* tpmback_get_uuid(domid_t domid, unsigned int handle);
+
+/* Specify a function to call when a new tpm device connects */
+void tpmback_set_open_callback(void (*cb)(domid_t, unsigned int));
+
+/* Specify a function to call when a tpm device disconnects */
+void tpmback_set_close_callback(void (*cb)(domid_t, unsigned int));
+
+//Not Implemented
+void tpmback_set_suspend_callback(void (*cb)(domid_t, unsigned int));
+void tpmback_set_resume_callback(void (*cb)(domid_t, unsigned int));
+
+#endif
diff --git a/extras/mini-os/include/tpmfront.h b/extras/mini-os/include/tpmfront.h
new file mode 100644
index 0000000..eccaacc
--- /dev/null
+++ b/extras/mini-os/include/tpmfront.h
@@ -0,0 +1,105 @@
+/*
+ * Copyright (c) 2010-2012 United States Government, as represented by
+ * the Secretary of Defense.  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 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.
+ *
+ * Based upon the files:
+ *  drivers/char/tpm/tpm_vtpm.c
+ *  drivers/char/tpm/tpm_xen.c
+ * from the Linux kernel, which are Copyright (C) 2006 IBM Corporation
+ */
+#ifndef TPMFRONT_H
+#define TPMFRONT_H
+
+#include <mini-os/types.h>
+#include <mini-os/os.h>
+#include <mini-os/events.h>
+#include <mini-os/wait.h>
+#include <xen/xen.h>
+#include <xen/io/xenbus.h>
+#include <xen/io/tpmif.h>
+
+struct tpmfront_dev {
+   grant_ref_t ring_ref;
+   evtchn_port_t evtchn;
+
+   tpmif_tx_interface_t* tx;
+
+   void** pages;
+
+   domid_t bedomid;
+   char* nodename;
+   char* bepath;
+
+   XenbusState state;
+
+   uint8_t waiting;
+   struct wait_queue_head waitq;
+
+   uint8_t* respbuf;
+   size_t resplen;
+
+#ifdef HAVE_LIBC
+   int fd;
+#endif
+
+};
+
+
+/*Initialize frontend */
+struct tpmfront_dev* init_tpmfront(const char* nodename);
+/*Shutdown frontend */
+void shutdown_tpmfront(struct tpmfront_dev* dev);
+
+/* Send a tpm command to the backend and wait for the response
+ *
+ * @dev - frontend device
+ * @req - request buffer
+ * @reqlen - length of request buffer
+ * @resp - *resp will be set to internal response buffer, don't free it! Value is undefined on error
+ * @resplen - *resplen will be set to the length of the response. Value is undefined on error
+ *
+ * returns 0 on success, non zero on failure.
+ * */
+int tpmfront_cmd(struct tpmfront_dev* dev, uint8_t* req, size_t reqlen, uint8_t** resp, size_t* resplen);
+
+#ifdef HAVE_LIBC
+#include <sys/stat.h>
+/* POSIX IO functions:
+ * use tpmfront_open() to get a file descriptor to the tpm device
+ * use write() on the fd to send a command to the backend. You must
+ * include the entire command in a single call to write().
+ * use read() on the fd to read the response. You can use
+ * fstat() to get the size of the response and lseek() to seek on it.
+ */
+int tpmfront_open(struct tpmfront_dev* dev);
+int tpmfront_posix_read(int fd, uint8_t* buf, size_t count);
+int tpmfront_posix_write(int fd, const uint8_t* buf, size_t count);
+int tpmfront_posix_fstat(int fd, struct stat* buf);
+#endif
+
+
+#endif
diff --git a/extras/mini-os/lib/sys.c b/extras/mini-os/lib/sys.c
index 6cb97b1..d212969 100644
--- a/extras/mini-os/lib/sys.c
+++ b/extras/mini-os/lib/sys.c
@@ -27,6 +27,8 @@
 #include <netfront.h>
 #include <blkfront.h>
 #include <fbfront.h>
+#include <tpmfront.h>
+#include <tpm_tis.h>
 #include <xenbus.h>
 #include <xenstore.h>
 
@@ -294,6 +296,16 @@ int read(int fd, void *buf, size_t nbytes)
 	    return blkfront_posix_read(fd, buf, nbytes);
         }
 #endif
+#ifdef CONFIG_TPMFRONT
+        case FTYPE_TPMFRONT: {
+	    return tpmfront_posix_read(fd, buf, nbytes);
+        }
+#endif
+#ifdef CONFIG_TPM_TIS
+        case FTYPE_TPM_TIS: {
+	    return tpm_tis_posix_read(fd, buf, nbytes);
+        }
+#endif
 	default:
 	    break;
     }
@@ -330,6 +342,14 @@ int write(int fd, const void *buf, size_t nbytes)
 	case FTYPE_BLK:
 	    return blkfront_posix_write(fd, buf, nbytes);
 #endif
+#ifdef CONFIG_TPMFRONT
+	case FTYPE_TPMFRONT:
+	    return tpmfront_posix_write(fd, buf, nbytes);
+#endif
+#ifdef CONFIG_TPM_TIS
+	case FTYPE_TPM_TIS:
+	    return tpm_tis_posix_write(fd, buf, nbytes);
+#endif
 	default:
 	    break;
     }
@@ -341,8 +361,16 @@ int write(int fd, const void *buf, size_t nbytes)
 off_t lseek(int fd, off_t offset, int whence)
 {
     switch(files[fd].type) {
+#if defined(CONFIG_BLKFRONT) || defined(CONFIG_TPMFRONT) || defined(CONFIG_TPM_TIS)
 #ifdef CONFIG_BLKFRONT
        case FTYPE_BLK:
+#endif
+#ifdef CONFIG_TPMFRNT
+       case FTYPE_TPMFRONT:
+#endif
+#ifdef CONFIG_TPM_TIS
+       case FTYPE_TPM_TIS:
+#endif
 	  switch (whence) {
 	     case SEEK_SET:
 		files[fd].file.offset = offset;
@@ -420,6 +448,18 @@ int close(int fd)
 	    files[fd].type = FTYPE_NONE;
 	    return 0;
 #endif
+#ifdef CONFIG_TPMFRONT
+	case FTYPE_TPMFRONT:
+            shutdown_tpmfront(files[fd].tpmfront.dev);
+	    files[fd].type = FTYPE_NONE;
+	    return 0;
+#endif
+#ifdef CONFIG_TPM_TIS
+	case FTYPE_TPM_TIS:
+            shutdown_tpm_tis(files[fd].tpm_tis.dev);
+	    files[fd].type = FTYPE_NONE;
+	    return 0;
+#endif
 #ifdef CONFIG_KBDFRONT
 	case FTYPE_KBD:
             shutdown_kbdfront(files[fd].kbd.dev);
@@ -489,6 +529,14 @@ int fstat(int fd, struct stat *buf)
 	case FTYPE_BLK:
 	   return blkfront_posix_fstat(fd, buf);
 #endif
+#ifdef CONFIG_TPMFRONT
+	case FTYPE_TPMFRONT:
+	   return tpmfront_posix_fstat(fd, buf);
+#endif
+#ifdef CONFIG_TPM_TIS
+	case FTYPE_TPM_TIS:
+	   return tpm_tis_posix_fstat(fd, buf);
+#endif
 	default:
 	    break;
     }
diff --git a/extras/mini-os/tpm_tis.c b/extras/mini-os/tpm_tis.c
new file mode 100644
index 0000000..2acb2dc
--- /dev/null
+++ b/extras/mini-os/tpm_tis.c
@@ -0,0 +1,1355 @@
+/*
+ * Copyright (c) 2010-2012 United States Government, as represented by
+ * the Secretary of Defense.  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 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.
+ *
+ * Based upon the files:
+ *  drivers/char/tpm/tpm_tis.c
+ *  drivers/char/tpm/tpm.c
+ * from the Linux kernel, which are Copyright (C) 2006 IBM Corporation
+ */
+#include <mini-os/ioremap.h>
+#include <mini-os/iorw.h>
+#include <mini-os/tpm_tis.h>
+#include <mini-os/os.h>
+#include <mini-os/sched.h>
+#include <mini-os/byteorder.h>
+#include <mini-os/events.h>
+#include <mini-os/wait.h>
+#include <mini-os/xmalloc.h>
+#include <errno.h>
+#include <stdbool.h>
+
+#ifndef min
+	#define min( a, b ) ( ((a) < (b)) ? (a) : (b) )
+#endif
+
+#define TPM_HEADER_SIZE 10
+
+#define TPM_BUFSIZE 2048
+
+struct tpm_input_header {
+        uint16_t  tag;
+        uint32_t  length;
+        uint32_t  ordinal;
+}__attribute__((packed));
+
+struct tpm_output_header {
+        uint16_t  tag;
+        uint32_t  length;
+        uint32_t  return_code;
+}__attribute__((packed));
+
+struct  stclear_flags_t {
+        uint16_t  tag;
+        uint8_t      deactivated;
+        uint8_t      disableForceClear;
+        uint8_t      physicalPresence;
+        uint8_t      physicalPresenceLock;
+        uint8_t      bGlobalLock;
+}__attribute__((packed));
+
+struct  tpm_version_t {
+        uint8_t      Major;
+        uint8_t      Minor;
+        uint8_t      revMajor;
+        uint8_t      revMinor;
+}__attribute__((packed));
+
+struct  tpm_version_1_2_t {
+        uint16_t  tag;
+        uint8_t      Major;
+        uint8_t      Minor;
+        uint8_t      revMajor;
+        uint8_t      revMinor;
+}__attribute__((packed));
+
+struct  timeout_t {
+        uint32_t  a;
+        uint32_t  b;
+        uint32_t  c;
+        uint32_t  d;
+}__attribute__((packed));
+
+struct duration_t {
+        uint32_t  tpm_short;
+        uint32_t  tpm_medium;
+        uint32_t  tpm_long;
+}__attribute__((packed));
+
+struct permanent_flags_t {
+        uint16_t  tag;
+        uint8_t      disable;
+        uint8_t      ownership;
+        uint8_t      deactivated;
+        uint8_t      readPubek;
+        uint8_t      disableOwnerClear;
+        uint8_t      allowMaintenance;
+        uint8_t      physicalPresenceLifetimeLock;
+        uint8_t      physicalPresenceHWEnable;
+        uint8_t      physicalPresenceCMDEnable;
+        uint8_t      CEKPUsed;
+        uint8_t      TPMpost;
+        uint8_t      TPMpostLock;
+        uint8_t      FIPS;
+        uint8_t      operator;
+        uint8_t      enableRevokeEK;
+        uint8_t      nvLocked;
+        uint8_t      readSRKPub;
+        uint8_t      tpmEstablished;
+        uint8_t      maintenanceDone;
+        uint8_t      disableFullDALogicInfo;
+}__attribute__((packed));
+
+typedef union {
+        struct  permanent_flags_t perm_flags;
+        struct  stclear_flags_t stclear_flags;
+        bool    owned;
+        uint32_t  num_pcrs;
+        struct  tpm_version_t   tpm_version;
+        struct  tpm_version_1_2_t tpm_version_1_2;
+        uint32_t  manufacturer_id;
+        struct timeout_t  timeout;
+        struct duration_t duration;
+} cap_t;
+
+struct  tpm_getcap_params_in {
+        uint32_t  cap;
+        uint32_t  subcap_size;
+        uint32_t  subcap;
+}__attribute__((packed));
+
+struct  tpm_getcap_params_out {
+        uint32_t  cap_size;
+        cap_t   cap;
+}__attribute__((packed));
+
+struct  tpm_readpubek_params_out {
+        uint8_t      algorithm[4];
+        uint8_t      encscheme[2];
+        uint8_t      sigscheme[2];
+        uint32_t  paramsize;
+        uint8_t      parameters[12]; /*assuming RSA*/
+        uint32_t  keysize;
+        uint8_t      modulus[256];
+        uint8_t      checksum[20];
+}__attribute__((packed));
+
+typedef union {
+        struct  tpm_input_header in;
+        struct  tpm_output_header out;
+} tpm_cmd_header;
+
+#define TPM_DIGEST_SIZE 20
+struct tpm_pcrread_out {
+        uint8_t      pcr_result[TPM_DIGEST_SIZE];
+}__attribute__((packed));
+
+struct tpm_pcrread_in {
+        uint32_t  pcr_idx;
+}__attribute__((packed));
+
+struct tpm_pcrextend_in {
+        uint32_t  pcr_idx;
+        uint8_t      hash[TPM_DIGEST_SIZE];
+}__attribute__((packed));
+
+typedef union {
+        struct  tpm_getcap_params_out getcap_out;
+        struct  tpm_readpubek_params_out readpubek_out;
+        uint8_t      readpubek_out_buffer[sizeof(struct tpm_readpubek_params_out)];
+        struct  tpm_getcap_params_in getcap_in;
+        struct  tpm_pcrread_in  pcrread_in;
+        struct  tpm_pcrread_out pcrread_out;
+        struct  tpm_pcrextend_in pcrextend_in;
+} tpm_cmd_params;
+
+struct tpm_cmd_t {
+        tpm_cmd_header  header;
+        tpm_cmd_params  params;
+}__attribute__((packed));
+
+
+enum tpm_duration {
+   TPM_SHORT = 0,
+   TPM_MEDIUM = 1,
+   TPM_LONG = 2,
+   TPM_UNDEFINED,
+};
+
+#define TPM_MAX_ORDINAL 243
+#define TPM_MAX_PROTECTED_ORDINAL 12
+#define TPM_PROTECTED_ORDINAL_MASK 0xFF
+
+extern const uint8_t tpm_protected_ordinal_duration[TPM_MAX_PROTECTED_ORDINAL];
+extern const uint8_t tpm_ordinal_duration[TPM_MAX_ORDINAL];
+
+#define TPM_DIGEST_SIZE 20
+#define TPM_ERROR_SIZE 10
+#define TPM_RET_CODE_IDX 6
+
+/* tpm_capabilities */
+#define TPM_CAP_FLAG cpu_to_be32(4)
+#define TPM_CAP_PROP cpu_to_be32(5)
+#define CAP_VERSION_1_1 cpu_to_be32(0x06)
+#define CAP_VERSION_1_2 cpu_to_be32(0x1A)
+
+/* tpm_sub_capabilities */
+#define TPM_CAP_PROP_PCR cpu_to_be32(0x101)
+#define TPM_CAP_PROP_MANUFACTURER cpu_to_be32(0x103)
+#define TPM_CAP_FLAG_PERM cpu_to_be32(0x108)
+#define TPM_CAP_FLAG_VOL cpu_to_be32(0x109)
+#define TPM_CAP_PROP_OWNER cpu_to_be32(0x111)
+#define TPM_CAP_PROP_TIS_TIMEOUT cpu_to_be32(0x115)
+#define TPM_CAP_PROP_TIS_DURATION cpu_to_be32(0x120)
+
+
+#define TPM_INTERNAL_RESULT_SIZE 200
+#define TPM_TAG_RQU_COMMAND cpu_to_be16(193)
+#define TPM_ORD_GET_CAP cpu_to_be32(101)
+
+extern const struct tpm_input_header tpm_getcap_header;
+
+
+
+const uint8_t tpm_protected_ordinal_duration[TPM_MAX_PROTECTED_ORDINAL] = {
+   TPM_UNDEFINED,          /* 0 */
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,          /* 5 */
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_SHORT,              /* 10 */
+   TPM_SHORT,
+};
+
+const uint8_t tpm_ordinal_duration[TPM_MAX_ORDINAL] = {
+   TPM_UNDEFINED,          /* 0 */
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,          /* 5 */
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_SHORT,              /* 10 */
+   TPM_SHORT,
+   TPM_MEDIUM,
+   TPM_LONG,
+   TPM_LONG,
+   TPM_MEDIUM,             /* 15 */
+   TPM_SHORT,
+   TPM_SHORT,
+   TPM_MEDIUM,
+   TPM_LONG,
+   TPM_SHORT,              /* 20 */
+   TPM_SHORT,
+   TPM_MEDIUM,
+   TPM_MEDIUM,
+   TPM_MEDIUM,
+   TPM_SHORT,              /* 25 */
+   TPM_SHORT,
+   TPM_MEDIUM,
+   TPM_SHORT,
+   TPM_SHORT,
+   TPM_MEDIUM,             /* 30 */
+   TPM_LONG,
+   TPM_MEDIUM,
+   TPM_SHORT,
+   TPM_SHORT,
+   TPM_SHORT,              /* 35 */
+   TPM_MEDIUM,
+   TPM_MEDIUM,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_MEDIUM,             /* 40 */
+   TPM_LONG,
+   TPM_MEDIUM,
+   TPM_SHORT,
+   TPM_SHORT,
+   TPM_SHORT,              /* 45 */
+   TPM_SHORT,
+   TPM_SHORT,
+   TPM_SHORT,
+   TPM_LONG,
+   TPM_MEDIUM,             /* 50 */
+   TPM_MEDIUM,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,          /* 55 */
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_MEDIUM,             /* 60 */
+   TPM_MEDIUM,
+   TPM_MEDIUM,
+   TPM_SHORT,
+   TPM_SHORT,
+   TPM_MEDIUM,             /* 65 */
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_SHORT,              /* 70 */
+   TPM_SHORT,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,          /* 75 */
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_LONG,               /* 80 */
+   TPM_UNDEFINED,
+   TPM_MEDIUM,
+   TPM_LONG,
+   TPM_SHORT,
+   TPM_UNDEFINED,          /* 85 */
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_SHORT,              /* 90 */
+   TPM_SHORT,
+   TPM_SHORT,
+   TPM_SHORT,
+   TPM_SHORT,
+   TPM_UNDEFINED,          /* 95 */
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_MEDIUM,             /* 100 */
+   TPM_SHORT,
+   TPM_SHORT,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,          /* 105 */
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_SHORT,              /* 110 */
+   TPM_SHORT,
+   TPM_SHORT,
+   TPM_SHORT,
+   TPM_SHORT,
+   TPM_SHORT,              /* 115 */
+   TPM_SHORT,
+   TPM_SHORT,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_LONG,               /* 120 */
+   TPM_LONG,
+   TPM_MEDIUM,
+   TPM_UNDEFINED,
+   TPM_SHORT,
+   TPM_SHORT,              /* 125 */
+   TPM_SHORT,
+   TPM_LONG,
+   TPM_SHORT,
+   TPM_SHORT,
+   TPM_SHORT,              /* 130 */
+   TPM_MEDIUM,
+   TPM_UNDEFINED,
+   TPM_SHORT,
+   TPM_MEDIUM,
+   TPM_UNDEFINED,          /* 135 */
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_SHORT,              /* 140 */
+   TPM_SHORT,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,          /* 145 */
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_SHORT,              /* 150 */
+   TPM_MEDIUM,
+   TPM_MEDIUM,
+   TPM_SHORT,
+   TPM_SHORT,
+   TPM_UNDEFINED,          /* 155 */
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_SHORT,              /* 160 */
+   TPM_SHORT,
+   TPM_SHORT,
+   TPM_SHORT,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,          /* 165 */
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_LONG,               /* 170 */
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,          /* 175 */
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_MEDIUM,             /* 180 */
+   TPM_SHORT,
+   TPM_MEDIUM,
+   TPM_MEDIUM,
+   TPM_MEDIUM,
+   TPM_MEDIUM,             /* 185 */
+   TPM_SHORT,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,          /* 190 */
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,          /* 195 */
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_SHORT,              /* 200 */
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_SHORT,
+   TPM_SHORT,              /* 205 */
+   TPM_SHORT,
+   TPM_SHORT,
+   TPM_SHORT,
+   TPM_SHORT,
+   TPM_MEDIUM,             /* 210 */
+   TPM_UNDEFINED,
+   TPM_MEDIUM,
+   TPM_MEDIUM,
+   TPM_MEDIUM,
+   TPM_UNDEFINED,          /* 215 */
+   TPM_MEDIUM,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_SHORT,
+   TPM_SHORT,              /* 220 */
+   TPM_SHORT,
+   TPM_SHORT,
+   TPM_SHORT,
+   TPM_SHORT,
+   TPM_UNDEFINED,          /* 225 */
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_SHORT,              /* 230 */
+   TPM_LONG,
+   TPM_MEDIUM,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,          /* 235 */
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_SHORT,              /* 240 */
+   TPM_UNDEFINED,
+   TPM_MEDIUM,
+};
+
+const struct tpm_input_header tpm_getcap_header = {
+        .tag = TPM_TAG_RQU_COMMAND,
+        .length = cpu_to_be32(22),
+        .ordinal = TPM_ORD_GET_CAP
+};
+
+
+enum tis_access {
+   TPM_ACCESS_VALID = 0x80,
+   TPM_ACCESS_ACTIVE_LOCALITY = 0x20,	/* (R) */
+   TPM_ACCESS_RELINQUISH_LOCALITY = 0x20,/* (W) */
+   TPM_ACCESS_REQUEST_PENDING = 0x04,	/* (W) */
+   TPM_ACCESS_REQUEST_USE = 0x02,	/* (W) */
+};
+
+enum tis_status {
+   TPM_STS_VALID = 0x80,		/* (R) */
+   TPM_STS_COMMAND_READY = 0x40,	/* (R) */
+   TPM_STS_DATA_AVAIL = 0x10,		/* (R) */
+   TPM_STS_DATA_EXPECT = 0x08,		/* (R) */
+   TPM_STS_GO = 0x20,			/* (W) */
+};
+
+enum tis_int_flags {
+   TPM_GLOBAL_INT_ENABLE = 0x80000000,
+   TPM_INTF_BURST_COUNT_STATIC = 0x100,
+   TPM_INTF_CMD_READY_INT = 0x080,
+   TPM_INTF_INT_EDGE_FALLING = 0x040,
+   TPM_INTF_INT_EDGE_RISING = 0x020,
+   TPM_INTF_INT_LEVEL_LOW = 0x010,
+   TPM_INTF_INT_LEVEL_HIGH = 0x008,
+   TPM_INTF_LOCALITY_CHANGE_INT = 0x004,
+   TPM_INTF_STS_VALID_INT = 0x002,
+   TPM_INTF_DATA_AVAIL_INT = 0x001,
+};
+
+enum tis_defaults {
+   TIS_MEM_BASE = 0xFED40000,
+   TIS_MEM_LEN  = 0x5000,
+   TIS_SHORT_TIMEOUT = 750, /*ms*/
+   TIS_LONG_TIMEOUT = 2000, /*2 sec */
+};
+
+#define TPM_TIMEOUT 5
+
+#define TPM_ACCESS(t, l)                   (((uint8_t*)t->pages[l]) + 0x0000)
+#define TPM_INT_ENABLE(t, l)               ((uint32_t*)(((uint8_t*)t->pages[l]) + 0x0008))
+#define TPM_INT_VECTOR(t, l)               (((uint8_t*)t->pages[l]) + 0x000C)
+#define TPM_INT_STATUS(t, l)               (((uint8_t*)t->pages[l]) + 0x0010)
+#define TPM_INTF_CAPS(t, l)                ((uint32_t*)(((uint8_t*)t->pages[l]) + 0x0014))
+#define TPM_STS(t, l)                      ((uint8_t*)(((uint8_t*)t->pages[l]) + 0x0018))
+#define TPM_DATA_FIFO(t, l)                (((uint8_t*)t->pages[l]) + 0x0024)
+
+#define TPM_DID_VID(t, l)                  ((uint32_t*)(((uint8_t*)t->pages[l]) + 0x0F00))
+#define TPM_RID(t, l)                      (((uint8_t*)t->pages[l]) + 0x0F04)
+
+struct tpm_chip {
+   int enabled_localities;
+   int locality;
+   unsigned long baseaddr;
+   uint8_t* pages[5];
+   int did, vid, rid;
+
+   uint8_t data_buffer[TPM_BUFSIZE];
+   int data_len;
+
+   s_time_t timeout_a, timeout_b, timeout_c, timeout_d;
+   s_time_t duration[3];
+
+#ifdef HAVE_LIBC
+   int fd;
+#endif
+
+   unsigned int irq;
+   struct wait_queue_head read_queue;
+   struct wait_queue_head int_queue;
+};
+
+
+static void __init_tpm_chip(struct tpm_chip* tpm) {
+   tpm->enabled_localities = TPM_TIS_EN_LOCLALL;
+   tpm->locality = -1;
+   tpm->baseaddr = 0;
+   tpm->pages[0] = tpm->pages[1] = tpm->pages[2] = tpm->pages[3] = tpm->pages[4] = NULL;
+   tpm->vid = 0;
+   tpm->did = 0;
+   tpm->irq = 0;
+   init_waitqueue_head(&tpm->read_queue);
+   init_waitqueue_head(&tpm->int_queue);
+
+   tpm->data_len = -1;
+
+#ifdef HAVE_LIBC
+   tpm->fd = -1;
+#endif
+}
+
+/*
+ * Returns max number of nsecs to wait
+ */
+s_time_t tpm_calc_ordinal_duration(struct tpm_chip *chip,
+      uint32_t ordinal)
+{
+   int duration_idx = TPM_UNDEFINED;
+   s_time_t duration = 0;
+
+   if (ordinal < TPM_MAX_ORDINAL)
+      duration_idx = tpm_ordinal_duration[ordinal];
+   else if ((ordinal & TPM_PROTECTED_ORDINAL_MASK) <
+	 TPM_MAX_PROTECTED_ORDINAL)
+      duration_idx =
+	 tpm_protected_ordinal_duration[ordinal &
+	 TPM_PROTECTED_ORDINAL_MASK];
+
+   if (duration_idx != TPM_UNDEFINED) {
+      duration = chip->duration[duration_idx];
+   }
+
+   if (duration <= 0) {
+      return SECONDS(120);
+   }
+   else
+   {
+      return duration;
+   }
+}
+
+
+static int locality_enabled(struct tpm_chip* tpm, int l) {
+   return tpm->enabled_localities & (1 << l);
+}
+
+static int check_locality(struct tpm_chip* tpm, int l) {
+   if(locality_enabled(tpm, l) && (ioread8(TPM_ACCESS(tpm, l)) &
+	    (TPM_ACCESS_ACTIVE_LOCALITY | TPM_ACCESS_VALID)) ==
+	 (TPM_ACCESS_ACTIVE_LOCALITY | TPM_ACCESS_VALID)) {
+      return l;
+   }
+   return -1;
+}
+
+void release_locality(struct tpm_chip* tpm, int l, int force)
+{
+   if (locality_enabled(tpm, l) && (force || (ioread8(TPM_ACCESS(tpm, l)) &
+	       (TPM_ACCESS_REQUEST_PENDING | TPM_ACCESS_VALID)) ==
+	    (TPM_ACCESS_REQUEST_PENDING | TPM_ACCESS_VALID))) {
+      iowrite8(TPM_ACCESS(tpm, l), TPM_ACCESS_RELINQUISH_LOCALITY);
+   }
+}
+
+int tpm_tis_request_locality(struct tpm_chip* tpm, int l) {
+
+   s_time_t stop;
+   /*Make sure locality is valid */
+   if(!locality_enabled(tpm, l)) {
+      printk("tpm_tis_change_locality() Tried to change to locality %d, but it is disabled or invalid!\n", l);
+      return -1;
+   }
+   /* Check if we already have the current locality */
+   if(check_locality(tpm, l) >= 0) {
+      return tpm->locality = l;
+   }
+   /* Set the new locality*/
+   iowrite8(TPM_ACCESS(tpm, l), TPM_ACCESS_REQUEST_USE);
+
+   if(tpm->irq) {
+      /* Wait for interrupt */
+      wait_event_deadline(tpm->int_queue, (check_locality(tpm, l) >= 0), NOW() + tpm->timeout_a);
+
+      /* FIXME: Handle timeout event, should return error in that case */
+      return l;
+   } else {
+      /* Wait for burstcount */
+      stop = NOW() + tpm->timeout_a;
+      do {
+	 if(check_locality(tpm, l) >= 0) {
+	    return tpm->locality = l;
+	 }
+	 msleep(TPM_TIMEOUT);
+      } while(NOW() < stop);
+   }
+
+   printk("REQ LOCALITY FAILURE\n");
+   return -1;
+}
+
+static uint8_t tpm_tis_status(struct tpm_chip* tpm) {
+   return ioread8(TPM_STS(tpm, tpm->locality));
+}
+
+/* This causes the current command to be aborted */
+static void tpm_tis_ready(struct tpm_chip* tpm) {
+   iowrite8(TPM_STS(tpm, tpm->locality), TPM_STS_COMMAND_READY);
+}
+#define tpm_tis_cancel_cmd(v) tpm_tis_ready(v)
+
+static int get_burstcount(struct tpm_chip* tpm) {
+   s_time_t stop;
+   int burstcnt;
+
+   stop = NOW() + tpm->timeout_d;
+   do {
+      burstcnt = ioread8((TPM_STS(tpm, tpm->locality) + 1));
+      burstcnt += ioread8(TPM_STS(tpm, tpm->locality) + 2) << 8;
+
+      if (burstcnt) {
+	 return burstcnt;
+      }
+      msleep(TPM_TIMEOUT);
+   } while(NOW() < stop);
+   return -EBUSY;
+}
+
+static int wait_for_stat(struct tpm_chip* tpm, uint8_t mask,
+      unsigned long timeout, struct wait_queue_head* queue) {
+   s_time_t stop;
+   uint8_t status;
+
+   status = tpm_tis_status(tpm);
+   if((status & mask) == mask) {
+      return 0;
+   }
+
+   if(tpm->irq) {
+      wait_event_deadline(*queue, ((tpm_tis_status(tpm) & mask) == mask), timeout);
+      /* FIXME: Check for timeout and return -ETIME */
+      return 0;
+   } else {
+      stop = NOW() + timeout;
+      do {
+	 msleep(TPM_TIMEOUT);
+	 status = tpm_tis_status(tpm);
+	 if((status & mask) == mask)
+	    return 0;
+      } while( NOW() < stop);
+   }
+   return -ETIME;
+}
+
+static int recv_data(struct tpm_chip* tpm, uint8_t* buf, size_t count) {
+   int size = 0;
+   int burstcnt;
+   while( size < count &&
+	 wait_for_stat(tpm,
+	    TPM_STS_DATA_AVAIL | TPM_STS_VALID,
+	    tpm->timeout_c,
+	    &tpm->read_queue)
+	 == 0) {
+      burstcnt = get_burstcount(tpm);
+      for(; burstcnt > 0 && size < count; --burstcnt)
+      {
+	 buf[size++] = ioread8(TPM_DATA_FIFO(tpm, tpm->locality));
+      }
+   }
+   return size;
+}
+
+int tpm_tis_recv(struct tpm_chip* tpm, uint8_t* buf, size_t count) {
+   int size = 0;
+   int expected, status;
+
+   if (count < TPM_HEADER_SIZE) {
+      size = -EIO;
+      goto out;
+   }
+
+   /* read first 10 bytes, including tag, paramsize, and result */
+   if((size =
+	    recv_data(tpm, buf, TPM_HEADER_SIZE)) < TPM_HEADER_SIZE) {
+      printk("Error reading tpm cmd header\n");
+      goto out;
+   }
+
+   expected = be32_to_cpu(*((uint32_t*)(buf + 2)));
+   if(expected > count) {
+      size = -EIO;
+      goto out;
+   }
+
+   if((size += recv_data(tpm, & buf[TPM_HEADER_SIZE],
+	       expected - TPM_HEADER_SIZE)) < expected) {
+      printk("Unable to read rest of tpm command size=%d expected=%d\n", size, expected);
+      size = -ETIME;
+      goto out;
+   }
+
+   wait_for_stat(tpm, TPM_STS_VALID, tpm->timeout_c, &tpm->int_queue);
+   status = tpm_tis_status(tpm);
+   if(status & TPM_STS_DATA_AVAIL) {
+      printk("Error: left over data\n");
+      size = -EIO;
+      goto out;
+   }
+
+out:
+   tpm_tis_ready(tpm);
+   release_locality(tpm, tpm->locality, 0);
+   return size;
+}
+int tpm_tis_send(struct tpm_chip* tpm, uint8_t* buf, size_t len) {
+   int rc;
+   int status, burstcnt = 0;
+   int count = 0;
+   uint32_t ordinal;
+
+   if(tpm_tis_request_locality(tpm, tpm->locality) < 0) {
+      return -EBUSY;
+   }
+
+   status = tpm_tis_status(tpm);
+   if((status & TPM_STS_COMMAND_READY) == 0) {
+      tpm_tis_ready(tpm);
+      if(wait_for_stat(tpm, TPM_STS_COMMAND_READY, tpm->timeout_b, &tpm->int_queue) < 0) {
+	 rc = -ETIME;
+	 goto out_err;
+      }
+   }
+
+   while(count < len - 1) {
+      burstcnt = get_burstcount(tpm);
+      for(;burstcnt > 0 && count < len -1; --burstcnt) {
+	 iowrite8(TPM_DATA_FIFO(tpm, tpm->locality), buf[count++]);
+      }
+
+      wait_for_stat(tpm, TPM_STS_VALID, tpm->timeout_c, &tpm->int_queue);
+      status = tpm_tis_status(tpm);
+      if((status & TPM_STS_DATA_EXPECT) == 0) {
+	 rc = -EIO;
+	 goto out_err;
+      }
+   }
+
+   /*Write last byte*/
+   iowrite8(TPM_DATA_FIFO(tpm, tpm->locality), buf[count]);
+   wait_for_stat(tpm, TPM_STS_VALID, tpm->timeout_c, &tpm->read_queue);
+   status = tpm_tis_status(tpm);
+   if((status & TPM_STS_DATA_EXPECT) != 0) {
+      rc = -EIO;
+      goto out_err;
+   }
+
+   /*go and do it*/
+   iowrite8(TPM_STS(tpm, tpm->locality), TPM_STS_GO);
+
+   if(tpm->irq) {
+      /*Wait for interrupt */
+      ordinal = be32_to_cpu(*(buf + 6));
+      if(wait_for_stat(tpm,
+	       TPM_STS_DATA_AVAIL | TPM_STS_VALID,
+	       tpm_calc_ordinal_duration(tpm, ordinal),
+	       &tpm->read_queue) < 0) {
+	 rc = -ETIME;
+	 goto out_err;
+      }
+   }
+#ifdef HAVE_LIBC
+   if(tpm->fd >= 0) {
+      files[tpm->fd].read = 0;
+      files[tpm->fd].tpm_tis.respgot = 0;
+      files[tpm->fd].tpm_tis.offset = 0;
+   }
+#endif
+   return len;
+
+out_err:
+   tpm_tis_ready(tpm);
+   release_locality(tpm, tpm->locality, 0);
+   return rc;
+}
+
+static void tpm_tis_irq_handler(evtchn_port_t port, struct pt_regs *regs, void* data)
+{
+   struct tpm_chip* tpm = data;
+   uint32_t interrupt;
+   int i;
+
+   interrupt = ioread32(TPM_INT_STATUS(tpm, tpm->locality));
+   if(interrupt == 0) {
+      return;
+   }
+
+   if(interrupt & TPM_INTF_DATA_AVAIL_INT) {
+      wake_up(&tpm->read_queue);
+   }
+   if(interrupt & TPM_INTF_LOCALITY_CHANGE_INT) {
+      for(i = 0; i < 5; ++i) {
+	 if(check_locality(tpm, i) >= 0) {
+	    break;
+	 }
+      }
+   }
+   if(interrupt & (TPM_INTF_LOCALITY_CHANGE_INT | TPM_INTF_STS_VALID_INT |
+	    TPM_INTF_CMD_READY_INT)) {
+      wake_up(&tpm->int_queue);
+   }
+
+   /* Clear interrupts handled with TPM_EOI */
+   iowrite32(TPM_INT_STATUS(tpm, tpm->locality), interrupt);
+   ioread32(TPM_INT_STATUS(tpm, tpm->locality));
+   return;
+}
+
+/*
+ * Internal kernel interface to transmit TPM commands
+ */
+static ssize_t tpm_transmit(struct tpm_chip *chip, const uint8_t *buf,
+      size_t bufsiz)
+{
+   ssize_t rc;
+   uint32_t count, ordinal;
+   s_time_t stop;
+
+   count = be32_to_cpu(*((uint32_t *) (buf + 2)));
+   ordinal = be32_to_cpu(*((uint32_t *) (buf + 6)));
+   if (count == 0)
+      return -ENODATA;
+   if (count > bufsiz) {
+      printk("Error: invalid count value %x %zx \n", count, bufsiz);
+      return -E2BIG;
+   }
+
+   //down(&chip->tpm_mutex);
+
+   if ((rc = tpm_tis_send(chip, (uint8_t *) buf, count)) < 0) {
+      printk("tpm_transmit: tpm_send: error %zd\n", rc);
+      goto out;
+   }
+
+   if (chip->irq)
+      goto out_recv;
+
+   stop = NOW() + tpm_calc_ordinal_duration(chip, ordinal);
+   do {
+      uint8_t status = tpm_tis_status(chip);
+      if ((status & (TPM_STS_DATA_AVAIL | TPM_STS_VALID)) ==
+	    (TPM_STS_DATA_AVAIL | TPM_STS_VALID))
+	 goto out_recv;
+
+      if ((status == TPM_STS_COMMAND_READY)) {
+	 printk("TPM Error: Operation Canceled\n");
+	 rc = -ECANCELED;
+	 goto out;
+      }
+
+      msleep(TPM_TIMEOUT);    /* CHECK */
+      rmb();
+   } while (NOW() < stop);
+
+   /* Cancel the command */
+   tpm_tis_cancel_cmd(chip);
+   printk("TPM Operation Timed out\n");
+   rc = -ETIME;
+   goto out;
+
+out_recv:
+   if((rc = tpm_tis_recv(chip, (uint8_t *) buf, bufsiz)) < 0) {
+      printk("tpm_transmit: tpm_recv: error %d\n", rc);
+   }
+out:
+   //up(&chip->tpm_mutex);
+   return rc;
+}
+
+static ssize_t transmit_cmd(struct tpm_chip *chip, struct tpm_cmd_t *cmd,
+                            int len, const char *desc)
+{
+        int err;
+
+        len = tpm_transmit(chip,(uint8_t *) cmd, len);
+        if (len <  0)
+                return len;
+        if (len == TPM_ERROR_SIZE) {
+                err = be32_to_cpu(cmd->header.out.return_code);
+                printk("A TPM error (%d) occurred %s\n", err, desc);
+                return err;
+        }
+        return 0;
+}
+
+void tpm_get_timeouts(struct tpm_chip *chip)
+{
+   struct tpm_cmd_t tpm_cmd;
+   struct timeout_t *timeout_cap;
+   struct duration_t *duration_cap;
+   ssize_t rc;
+   uint32_t timeout;
+
+   tpm_cmd.header.in = tpm_getcap_header;
+   tpm_cmd.params.getcap_in.cap = TPM_CAP_PROP;
+   tpm_cmd.params.getcap_in.subcap_size = cpu_to_be32(4);
+   tpm_cmd.params.getcap_in.subcap = TPM_CAP_PROP_TIS_TIMEOUT;
+
+   if((rc = transmit_cmd(chip, &tpm_cmd, TPM_INTERNAL_RESULT_SIZE,
+	 "attempting to determine the timeouts")) != 0) {
+      printk("transmit failed %d\n", rc);
+      goto duration;
+   }
+
+   if (be32_to_cpu(tpm_cmd.params.getcap_out.cap_size)
+	 != 4 * sizeof(uint32_t)) {
+      printk("Out len check failure %lu \n", be32_to_cpu(tpm_cmd.header.out.length));
+      goto duration;
+   }
+
+   timeout_cap = &tpm_cmd.params.getcap_out.cap.timeout;
+   /* Don't overwrite default if value is 0 */
+   timeout = be32_to_cpu(timeout_cap->a);
+   if (timeout)
+      chip->timeout_a = MICROSECS(timeout); /*Convert to msec */
+   timeout = be32_to_cpu(timeout_cap->b);
+   if (timeout)
+      chip->timeout_b = MICROSECS(timeout); /*Convert to msec */
+   timeout = be32_to_cpu(timeout_cap->c);
+   if (timeout)
+      chip->timeout_c = MICROSECS(timeout); /*Convert to msec */
+   timeout = be32_to_cpu(timeout_cap->d);
+   if (timeout)
+      chip->timeout_d = MICROSECS(timeout); /*Convert to msec */
+
+duration:
+   tpm_cmd.header.in = tpm_getcap_header;
+   tpm_cmd.params.getcap_in.cap = TPM_CAP_PROP;
+   tpm_cmd.params.getcap_in.subcap_size = cpu_to_be32(4);
+   tpm_cmd.params.getcap_in.subcap = TPM_CAP_PROP_TIS_DURATION;
+
+   if((rc = transmit_cmd(chip, &tpm_cmd, TPM_INTERNAL_RESULT_SIZE,
+	 "attempting to determine the durations")) < 0) {
+      return;
+   }
+
+   if (be32_to_cpu(tpm_cmd.params.getcap_out.cap_size)
+	 != 3 * sizeof(uint32_t)) {
+      return;
+   }
+        duration_cap = &tpm_cmd.params.getcap_out.cap.duration;
+        chip->duration[TPM_SHORT] = be32_to_cpu(duration_cap->tpm_short);
+        /* The Broadcom BCM0102 chipset in a Dell Latitude D820 gets the above
+         * value wrong and apparently reports msecs rather than usecs. So we
+         * fix up the resulting too-small TPM_SHORT value to make things work.
+         */
+        if (chip->duration[TPM_SHORT] < 10) {
+	   chip->duration[TPM_SHORT] = MILLISECS(chip->duration[TPM_SHORT]);
+	} else {
+	   chip->duration[TPM_SHORT] = MICROSECS(chip->duration[TPM_SHORT]);
+	}
+
+        chip->duration[TPM_MEDIUM] = MICROSECS(be32_to_cpu(duration_cap->tpm_medium));
+        chip->duration[TPM_LONG] = MICROSECS(be32_to_cpu(duration_cap->tpm_long));
+}
+
+
+
+void tpm_continue_selftest(struct tpm_chip* chip) {
+   uint8_t data[] = {
+      0, 193,                 /* TPM_TAG_RQU_COMMAND */
+      0, 0, 0, 10,            /* length */
+      0, 0, 0, 83,            /* TPM_ORD_GetCapability */
+   };
+
+   tpm_transmit(chip, data, sizeof(data));
+}
+
+ssize_t tpm_getcap(struct tpm_chip *chip, uint32_t subcap_id, cap_t *cap,
+                   const char *desc)
+{
+        struct tpm_cmd_t tpm_cmd;
+        int rc;
+
+        tpm_cmd.header.in = tpm_getcap_header;
+        if (subcap_id == CAP_VERSION_1_1 || subcap_id == CAP_VERSION_1_2) {
+                tpm_cmd.params.getcap_in.cap = subcap_id;
+                /*subcap field not necessary */
+                tpm_cmd.params.getcap_in.subcap_size = cpu_to_be32(0);
+                tpm_cmd.header.in.length -= cpu_to_be32(sizeof(uint32_t));
+        } else {
+                if (subcap_id == TPM_CAP_FLAG_PERM ||
+                    subcap_id == TPM_CAP_FLAG_VOL)
+                        tpm_cmd.params.getcap_in.cap = TPM_CAP_FLAG;
+                else
+                        tpm_cmd.params.getcap_in.cap = TPM_CAP_PROP;
+                tpm_cmd.params.getcap_in.subcap_size = cpu_to_be32(4);
+                tpm_cmd.params.getcap_in.subcap = subcap_id;
+        }
+        rc = transmit_cmd(chip, &tpm_cmd, TPM_INTERNAL_RESULT_SIZE, desc);
+        if (!rc)
+                *cap = tpm_cmd.params.getcap_out.cap;
+        return rc;
+}
+
+
+struct tpm_chip* init_tpm_tis(unsigned long baseaddr, int localities, unsigned int irq)
+{
+   int i;
+   unsigned long addr;
+   struct tpm_chip* tpm = NULL;
+   uint32_t didvid;
+   uint32_t intfcaps;
+   uint32_t intmask;
+
+   printk("============= Init TPM TIS Driver ==============\n");
+
+   /*Sanity check the localities input */
+   if(localities & ~TPM_TIS_EN_LOCLALL) {
+      printk("init_tpm_tis() Invalid locality specification! %X\n", localities);
+      goto abort_egress;
+   }
+
+   printk("IOMEM Machine Base Address: %lX\n", baseaddr);
+
+   /* Create the tpm data structure */
+   tpm = malloc(sizeof(struct tpm_chip));
+   __init_tpm_chip(tpm);
+
+   /* Set the enabled localities - if 0 we leave default as all enabled */
+   if(localities != 0) {
+      tpm->enabled_localities = localities;
+   }
+   printk("Enabled Localities: ");
+   for(i = 0; i < 5; ++i) {
+      if(locality_enabled(tpm, i)) {
+	 printk("%d ", i);
+      }
+   }
+   printk("\n");
+
+   /* Set the base machine address */
+   tpm->baseaddr = baseaddr;
+
+   /* Set default timeouts */
+   tpm->timeout_a = MILLISECS(TIS_SHORT_TIMEOUT);
+   tpm->timeout_b = MILLISECS(TIS_LONG_TIMEOUT);
+   tpm->timeout_c = MILLISECS(TIS_SHORT_TIMEOUT);
+   tpm->timeout_d = MILLISECS(TIS_SHORT_TIMEOUT);
+
+   /*Map the mmio pages */
+   addr = tpm->baseaddr;
+   for(i = 0; i < 5; ++i) {
+      if(locality_enabled(tpm, i)) {
+	 /* Map the page in now */
+	 if((tpm->pages[i] = ioremap_nocache(addr, PAGE_SIZE)) == NULL) {
+	    printk("Unable to map iomem page a address %p\n", addr);
+	    goto abort_egress;
+	 }
+
+	 /* Set default locality to the first enabled one */
+	 if (tpm->locality < 0) {
+	    if(tpm_tis_request_locality(tpm, i) < 0) {
+	       printk("Unable to request locality %d??\n", i);
+	       goto abort_egress;
+	    }
+	 }
+      }
+      addr += PAGE_SIZE;
+   }
+
+
+   /* Get the vendor and device ids */
+   didvid = ioread32(TPM_DID_VID(tpm, tpm->locality));
+   tpm->did = didvid >> 16;
+   tpm->vid = didvid & 0xFFFF;
+
+
+   /* Get the revision id */
+   tpm->rid = ioread8(TPM_RID(tpm, tpm->locality));
+
+   printk("1.2 TPM (device-id=0x%X vendor-id = %X rev-id = %X)\n", tpm->did, tpm->vid, tpm->rid);
+
+   intfcaps = ioread32(TPM_INTF_CAPS(tpm, tpm->locality));
+   printk("TPM interface capabilities (0x%x):\n", intfcaps);
+   if (intfcaps & TPM_INTF_BURST_COUNT_STATIC)
+      printk("\tBurst Count Static\n");
+   if (intfcaps & TPM_INTF_CMD_READY_INT)
+      printk("\tCommand Ready Int Support\n");
+   if (intfcaps & TPM_INTF_INT_EDGE_FALLING)
+      printk("\tInterrupt Edge Falling\n");
+   if (intfcaps & TPM_INTF_INT_EDGE_RISING)
+      printk("\tInterrupt Edge Rising\n");
+   if (intfcaps & TPM_INTF_INT_LEVEL_LOW)
+      printk("\tInterrupt Level Low\n");
+   if (intfcaps & TPM_INTF_INT_LEVEL_HIGH)
+      printk("\tInterrupt Level High\n");
+   if (intfcaps & TPM_INTF_LOCALITY_CHANGE_INT)
+      printk("\tLocality Change Int Support\n");
+   if (intfcaps & TPM_INTF_STS_VALID_INT)
+      printk("\tSts Valid Int Support\n");
+   if (intfcaps & TPM_INTF_DATA_AVAIL_INT)
+      printk("\tData Avail Int Support\n");
+
+   /*Interupt setup */
+   intmask = ioread32(TPM_INT_ENABLE(tpm, tpm->locality));
+
+   intmask |= TPM_INTF_CMD_READY_INT
+      | TPM_INTF_LOCALITY_CHANGE_INT | TPM_INTF_DATA_AVAIL_INT
+      | TPM_INTF_STS_VALID_INT;
+
+   iowrite32(TPM_INT_ENABLE(tpm, tpm->locality), intmask);
+
+   /*If interupts are enabled, handle it */
+   if(irq) {
+      if(irq != TPM_PROBE_IRQ) {
+	 tpm->irq = irq;
+      } else {
+	 /*FIXME add irq probing feature later */
+	 printk("IRQ probing not implemented\n");
+      }
+   }
+
+   if(tpm->irq) {
+      iowrite8(TPM_INT_VECTOR(tpm, tpm->locality), tpm->irq);
+
+      if(bind_pirq(tpm->irq, 1, tpm_tis_irq_handler, tpm) != 0) {
+	 printk("Unabled to request irq: %u for use\n", tpm->irq);
+	 printk("Will use polling mode\n");
+	 tpm->irq = 0;
+      } else {
+	 /* Clear all existing */
+	 iowrite32(TPM_INT_STATUS(tpm, tpm->locality), ioread32(TPM_INT_STATUS(tpm, tpm->locality)));
+
+	 /* Turn on interrupts */
+	 iowrite32(TPM_INT_ENABLE(tpm, tpm->locality), intmask | TPM_GLOBAL_INT_ENABLE);
+      }
+   }
+
+   tpm_get_timeouts(tpm);
+   tpm_continue_selftest(tpm);
+
+
+   return tpm;
+abort_egress:
+   if(tpm != NULL) {
+      shutdown_tpm_tis(tpm);
+   }
+   return NULL;
+}
+
+void shutdown_tpm_tis(struct tpm_chip* tpm){
+   int i;
+
+   printk("Shutting down tpm_tis device\n");
+
+   iowrite32(TPM_INT_ENABLE(tpm, tpm->locality), ~TPM_GLOBAL_INT_ENABLE);
+
+   /*Unmap all of the mmio pages */
+   for(i = 0; i < 5; ++i) {
+      if(tpm->pages[i] != NULL) {
+	 iounmap(tpm->pages[i], PAGE_SIZE);
+	 tpm->pages[i] = NULL;
+      }
+   }
+   free(tpm);
+   return;
+}
+
+
+int tpm_tis_cmd(struct tpm_chip* tpm, uint8_t* req, size_t reqlen, uint8_t** resp, size_t* resplen)
+{
+   if(tpm->locality < 0) {
+      printk("tpm_tis_cmd() failed! locality not set!\n");
+      return -1;
+   }
+   if(reqlen > TPM_BUFSIZE) {
+      reqlen = TPM_BUFSIZE;
+   }
+   memcpy(tpm->data_buffer, req, reqlen);
+   *resplen = tpm_transmit(tpm, tpm->data_buffer, TPM_BUFSIZE);
+
+   *resp = malloc(*resplen);
+   memcpy(*resp, tpm->data_buffer, *resplen);
+   return 0;
+}
+
+#ifdef HAVE_LIBC
+int tpm_tis_open(struct tpm_chip* tpm)
+{
+   /* Silently prevent multiple opens */
+   if(tpm->fd != -1) {
+      return tpm->fd;
+   }
+
+   tpm->fd = alloc_fd(FTYPE_TPM_TIS);
+   printk("tpm_tis_open() -> %d\n", tpm->fd);
+   files[tpm->fd].tpm_tis.dev = tpm;
+   files[tpm->fd].tpm_tis.offset = 0;
+   files[tpm->fd].tpm_tis.respgot = 0;
+   return tpm->fd;
+}
+
+int tpm_tis_posix_write(int fd, const uint8_t* buf, size_t count)
+{
+   struct tpm_chip* tpm;
+   tpm = files[fd].tpm_tis.dev;
+
+   if(tpm->locality < 0) {
+      printk("tpm_tis_posix_write() failed! locality not set!\n");
+      errno = EINPROGRESS;
+      return -1;
+   }
+   if(count == 0) {
+      return 0;
+   }
+
+   /* Return an error if we are already processing a command */
+   if(count > TPM_BUFSIZE) {
+      count = TPM_BUFSIZE;
+   }
+   /* Send the command now */
+   memcpy(tpm->data_buffer, buf, count);
+   if((tpm->data_len = tpm_transmit(tpm, tpm->data_buffer, TPM_BUFSIZE)) < 0) {
+      errno = EIO;
+      return -1;
+   }
+   return count;
+}
+
+int tpm_tis_posix_read(int fd, uint8_t* buf, size_t count)
+{
+   int rc;
+   struct tpm_chip* tpm;
+   tpm = files[fd].tpm_tis.dev;
+
+   if(count == 0) {
+      return 0;
+   }
+
+   /* If there is no tpm resp to read, return EIO */
+   if(tpm->data_len < 0) {
+      errno = EIO;
+      return -1;
+   }
+
+
+   /* Handle EOF case */
+   if(files[fd].tpm_tis.offset >= tpm->data_len) {
+      rc = 0;
+   } else {
+      rc = min(tpm->data_len - files[fd].tpm_tis.offset, count);
+      memcpy(buf, tpm->data_buffer + files[fd].tpm_tis.offset, rc);
+   }
+   files[fd].tpm_tis.offset += rc;
+   /* Reset the data pending flag */
+   return rc;
+}
+int tpm_tis_posix_fstat(int fd, struct stat* buf)
+{
+   struct tpm_chip* tpm;
+   tpm = files[fd].tpm_tis.dev;
+
+   buf->st_mode = O_RDWR;
+   buf->st_uid = 0;
+   buf->st_gid = 0;
+   buf->st_size = be32_to_cpu(*((uint32_t*)(tpm->data_buffer + 2)));
+   buf->st_atime = buf->st_mtime = buf->st_ctime = time(NULL);
+   return 0;
+}
+
+
+#endif
diff --git a/extras/mini-os/tpmback.c b/extras/mini-os/tpmback.c
new file mode 100644
index 0000000..c709019
--- /dev/null
+++ b/extras/mini-os/tpmback.c
@@ -0,0 +1,1125 @@
+/*
+ * Copyright (c) 2010-2012 United States Government, as represented by
+ * the Secretary of Defense.  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 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.
+ *
+ * Based upon the files:
+ *  drivers/xen/tpmbk.c
+ * from the Linux kernel, which are Copyright (C) 2006 IBM Corporation
+ */
+#include <mini-os/os.h>
+#include <mini-os/xenbus.h>
+#include <mini-os/events.h>
+#include <errno.h>
+#include <mini-os/gnttab.h>
+#include <xen/io/xenbus.h>
+#include <xen/io/tpmif.h>
+#include <xen/io/protocols.h>
+#include <mini-os/xmalloc.h>
+#include <time.h>
+#include <mini-os/tpmback.h>
+#include <mini-os/lib.h>
+#include <fcntl.h>
+#include <mini-os/mm.h>
+#include <mini-os/posix/sys/mman.h>
+#include <mini-os/semaphore.h>
+#include <mini-os/wait.h>
+
+
+#ifndef HAVE_LIBC
+#define strtoul simple_strtoul
+#endif
+
+//#define TPMBACK_PRINT_DEBUG
+#ifdef TPMBACK_PRINT_DEBUG
+#define TPMBACK_DEBUG(fmt,...) printk("Tpmback:Debug("__FILE__":%d) " fmt, __LINE__, ##__VA_ARGS__)
+#define TPMBACK_DEBUG_MORE(fmt,...) printk(fmt, ##__VA_ARGS__)
+#else
+#define TPMBACK_DEBUG(fmt,...)
+#endif
+#define TPMBACK_ERR(fmt,...) printk("Tpmback:Error " fmt, ##__VA_ARGS__)
+#define TPMBACK_LOG(fmt,...) printk("Tpmback:Info " fmt, ##__VA_ARGS__)
+
+#define min(a,b) (((a) < (b)) ? (a) : (b))
+
+/* Default size of the tpmif array at initialization */
+#define DEF_ARRAY_SIZE 1
+
+/* tpmif and tpmdev flags */
+#define TPMIF_CLOSED 1
+#define TPMIF_REQ_READY 2
+
+struct tpmif {
+   domid_t domid;
+   unsigned int handle;
+
+   char* fe_path;
+   char* fe_state_path;
+
+   /* Locally bound event channel*/
+   evtchn_port_t evtchn;
+
+   /* Shared page */
+   tpmif_tx_interface_t* tx;
+
+   /* pointer to TPMIF_RX_RING_SIZE pages */
+   void** pages;
+
+   enum xenbus_state state;
+   enum { DISCONNECTED, DISCONNECTING, CONNECTED } status;
+
+   char* uuid;
+
+   /* state flags */
+   int flags;
+};
+typedef struct tpmif tpmif_t;
+
+struct tpmback_dev {
+
+   tpmif_t** tpmlist;
+   unsigned long num_tpms;
+   unsigned long num_alloc;
+
+   struct gntmap map;
+
+   /* True if at least one tpmif has a request to be handled */
+   int flags;
+
+   /* exclusive domains, see init_tpmback comment in tpmback.h */
+   char** exclusive_uuids;
+
+   xenbus_event_queue events;
+
+   /* Callbacks */
+   void (*open_callback)(domid_t, unsigned int);
+   void (*close_callback)(domid_t, unsigned int);
+   void (*suspend_callback)(domid_t, unsigned int);
+   void (*resume_callback)(domid_t, unsigned int);
+};
+typedef struct tpmback_dev tpmback_dev_t;
+
+enum { EV_NONE, EV_NEWFE, EV_STCHNG } tpm_ev_enum;
+
+/* Global objects */
+static struct thread* eventthread = NULL;
+static tpmback_dev_t gtpmdev = {
+   .tpmlist = NULL,
+   .num_tpms = 0,
+   .num_alloc = 0,
+   .flags = TPMIF_CLOSED,
+   .events = NULL,
+   .open_callback = NULL,
+   .close_callback = NULL,
+   .suspend_callback = NULL,
+   .resume_callback = NULL,
+};
+struct wait_queue_head waitq;
+int globalinit = 0;
+
+/************************************
+ * TPMIF SORTED ARRAY FUNCTIONS
+ * tpmback_dev_t.tpmlist is a sorted array, sorted by domid and then handle number
+ * Duplicates are not allowed
+ * **********************************/
+
+inline void tpmif_req_ready(tpmif_t* tpmif) {
+   tpmif->flags |= TPMIF_REQ_READY;
+   gtpmdev.flags |= TPMIF_REQ_READY;
+}
+
+inline void tpmdev_check_req(void) {
+   int i;
+   int flags;
+   local_irq_save(flags);
+   for(i = 0; i < gtpmdev.num_tpms; ++i) {
+      if(gtpmdev.tpmlist[i]->flags & TPMIF_REQ_READY) {
+	 gtpmdev.flags |= TPMIF_REQ_READY;
+	 local_irq_restore(flags);
+	 return;
+      }
+   }
+   gtpmdev.flags &= ~TPMIF_REQ_READY;
+   local_irq_restore(flags);
+}
+
+inline void tpmif_req_finished(tpmif_t* tpmif) {
+   tpmif->flags &= ~TPMIF_REQ_READY;
+   tpmdev_check_req();
+}
+
+int __get_tpmif_index(int st, int n, domid_t domid, unsigned int handle)
+{
+   int i = st + n /2;
+   tpmif_t* tmp;
+
+   if( n <= 0 )
+      return -1;
+
+   tmp = gtpmdev.tpmlist[i];
+   if(domid == tmp->domid && tmp->handle == handle) {
+      return i;
+   } else if ( (domid < tmp->domid) ||
+	 (domid == tmp->domid && handle < tmp->handle)) {
+      return __get_tpmif_index(st, n/2, domid, handle);
+   } else {
+      return __get_tpmif_index(i + 1, n/2 - ((n +1) % 2), domid, handle);
+   }
+}
+
+/* Returns the array index of the tpmif domid/handle. Returns -1 if no such tpmif exists */
+int get_tpmif_index(domid_t domid, unsigned int handle)
+{
+   int flags;
+   int index;
+   local_irq_save(flags);
+   index = __get_tpmif_index(0, gtpmdev.num_tpms, domid, handle);
+   local_irq_restore(flags);
+   return index;
+}
+
+/* Returns the tpmif domid/handle or NULL if none exists */
+tpmif_t* get_tpmif(domid_t domid, unsigned int handle)
+{
+   int flags;
+   int i;
+   tpmif_t* ret;
+   local_irq_save(flags);
+   i = get_tpmif_index(domid, handle);
+   if (i < 0) {
+      ret = NULL;
+   } else {
+      ret = gtpmdev.tpmlist[i];
+   }
+   local_irq_restore(flags);
+   return ret;
+}
+
+/* Remove the given tpmif. Returns 0 if it was removed, -1 if it was not removed */
+int remove_tpmif(tpmif_t* tpmif)
+{
+   int i, j;
+   char* err;
+   int flags;
+   local_irq_save(flags);
+
+   /* Find the index in the array if it exists */
+   i = get_tpmif_index(tpmif->domid, tpmif->handle);
+   if (i < 0) {
+      goto error;
+   }
+
+   /* Remove the interface from the list */
+   for(j = i; j < gtpmdev.num_tpms - 1; ++j) {
+      gtpmdev.tpmlist[j] = gtpmdev.tpmlist[j+1];
+   }
+   gtpmdev.tpmlist[j] = NULL;
+   --gtpmdev.num_tpms;
+
+   /* If removed tpm was the only ready tpm, then we need to check and turn off the ready flag */
+   tpmdev_check_req();
+
+   local_irq_restore(flags);
+
+   /* Stop listening for events on this tpm interface */
+   if((err = xenbus_unwatch_path_token(XBT_NIL, tpmif->fe_state_path, tpmif->fe_state_path))) {
+      TPMBACK_ERR("Unable to unwatch path token `%s' Error was %s Ignoring..\n", tpmif->fe_state_path, err);
+      free(err);
+   }
+
+   return 0;
+error:
+   local_irq_restore(flags);
+   return -1;
+}
+
+/* Insert tpmif into dev->tpmlist. Returns 0 on success and non zero on error.
+ * It is an error to insert a tpmif with the same domid and handle
+ * number
+ * as something already in the list */
+int insert_tpmif(tpmif_t* tpmif)
+{
+   int flags;
+   unsigned int i, j;
+   tpmif_t* tmp;
+   char* err;
+
+   local_irq_save(flags);
+
+   /*Check if we need to allocate more space */
+   if (gtpmdev.num_tpms == gtpmdev.num_alloc) {
+      gtpmdev.num_alloc *= 2;
+      gtpmdev.tpmlist = realloc(gtpmdev.tpmlist, gtpmdev.num_alloc);
+   }
+
+   /*Find where to put the new interface */
+   for(i = 0; i < gtpmdev.num_tpms; ++i)
+   {
+      tmp = gtpmdev.tpmlist[i];
+      if(tpmif->domid == tmp->domid && tpmif->handle == tmp->handle) {
+	 TPMBACK_ERR("Tried to insert duplicate tpm interface %u/%u\n", (unsigned int) tpmif->domid, tpmif->handle);
+	 goto error;
+      }
+      if((tpmif->domid < tmp->domid) ||
+	    (tpmif->domid == tmp->domid && tpmif->handle < tmp->handle)) {
+	 break;
+      }
+   }
+
+   /*Shift all the tpm pointers past i down one */
+   for(j = gtpmdev.num_tpms; j > i; --j) {
+      gtpmdev.tpmlist[j] = gtpmdev.tpmlist[j-1];
+   }
+
+   /*Add the new interface */
+   gtpmdev.tpmlist[i] = tpmif;
+   ++gtpmdev.num_tpms;
+
+   /*Should not be needed, anything inserted with ready flag is probably an error */
+   tpmdev_check_req();
+
+   local_irq_restore(flags);
+
+   /*Listen for state changes on the new interface */
+   if((err = xenbus_watch_path_token(XBT_NIL, tpmif->fe_state_path, tpmif->fe_state_path, &gtpmdev.events)))
+   {
+      /* if we got an error here we should carefully remove the interface and then return */
+      TPMBACK_ERR("Unable to watch path token `%s' Error was %s\n", tpmif->fe_state_path, err);
+      free(err);
+      remove_tpmif(tpmif);
+      goto error_post_irq;
+   }
+
+   return 0;
+error:
+   local_irq_restore(flags);
+error_post_irq:
+   return -1;
+}
+
+
+/*****************
+ * CHANGE BACKEND STATE
+ * *****************/
+/*Attempts to change the backend state in xenstore
+ * returns 0 on success and non-zero on error */
+int tpmif_change_state(tpmif_t* tpmif, enum xenbus_state state)
+{
+   char path[512];
+   char *value;
+   char *err;
+   enum xenbus_state readst;
+   TPMBACK_DEBUG("Backend state change %u/%u from=%d to=%d\n", (unsigned int) tpmif->domid, tpmif->handle, tpmif->state, state);
+   if (tpmif->state == state)
+      return 0;
+
+   snprintf(path, 512, "backend/vtpm/%u/%u/state", (unsigned int) tpmif->domid, tpmif->handle);
+
+   if((err = xenbus_read(XBT_NIL, path, &value))) {
+      TPMBACK_ERR("Unable to read backend state %s, error was %s\n", path, err);
+      free(err);
+      return -1;
+   }
+   if(sscanf(value, "%d", &readst) != 1) {
+      TPMBACK_ERR("Non integer value (%s) in %s ??\n", value, path);
+      free(value);
+      return -1;
+   }
+   free(value);
+
+   /* It's possible that the backend state got updated by hotplug or something else behind our back */
+   if(readst != tpmif->state) {
+      TPMBACK_DEBUG("tpm interface state was %d but xenstore state was %d!\n", tpmif->state, readst);
+      tpmif->state = readst;
+   }
+
+   /*If if the state isnt changing, then we dont update xenstore b/c we dont want to fire extraneous events */
+   if(tpmif->state == state) {
+      return 0;
+   }
+
+   /*update xenstore*/
+   snprintf(path, 512, "backend/vtpm/%u/%u", (unsigned int) tpmif->domid, tpmif->handle);
+   if((err = xenbus_printf(XBT_NIL, path, "state", "%u", state))) {
+      TPMBACK_ERR("Error writing to xenstore %s, error was %s new state=%d\n", path, err, state);
+      free(err);
+      return -1;
+   }
+
+   tpmif->state = state;
+
+   return 0;
+}
+/**********************************
+ * TPMIF CREATION AND DELETION
+ * *******************************/
+inline tpmif_t* __init_tpmif(domid_t domid, unsigned int handle)
+{
+   tpmif_t* tpmif;
+   tpmif = malloc(sizeof(*tpmif));
+   tpmif->domid = domid;
+   tpmif->handle = handle;
+   tpmif->fe_path = NULL;
+   tpmif->fe_state_path = NULL;
+   tpmif->state = XenbusStateInitialising;
+   tpmif->status = DISCONNECTED;
+   tpmif->tx = NULL;
+   tpmif->pages = NULL;
+   tpmif->flags = 0;
+   tpmif->uuid = NULL;
+   return tpmif;
+}
+
+void __free_tpmif(tpmif_t* tpmif)
+{
+   if(tpmif->pages) {
+      free(tpmif->pages);
+   }
+   if(tpmif->fe_path) {
+      free(tpmif->fe_path);
+   }
+   if(tpmif->fe_state_path) {
+      free(tpmif->fe_state_path);
+   }
+   if(tpmif->uuid) {
+      free(tpmif->uuid);
+   }
+   free(tpmif);
+}
+/* Creates a new tpm interface, adds it to the sorted array and returns it.
+ * returns NULL on error
+ * If the tpm interface already exists, it is returned*/
+tpmif_t* new_tpmif(domid_t domid, unsigned int handle)
+{
+   tpmif_t* tpmif;
+   char* err;
+   char path[512];
+
+   /* Make sure we haven't already created this tpm
+    * Double events can occur */
+   if((tpmif = get_tpmif(domid, handle)) != NULL) {
+      return tpmif;
+   }
+
+   tpmif = __init_tpmif(domid, handle);
+
+   /* Get the uuid from xenstore */
+   snprintf(path, 512, "backend/vtpm/%u/%u/uuid", (unsigned int) domid, handle);
+   if((err = xenbus_read(XBT_NIL, path, &tpmif->uuid))) {
+      TPMBACK_ERR("Error reading %s, Error = %s\n", path, err);
+      free(err);
+      goto error;
+   }
+
+   /* Do the exclusive uuid check now */
+   if(gtpmdev.exclusive_uuids != NULL) {
+      char** ptr;
+
+      /* Check that its in the whitelist */
+      for(ptr = gtpmdev.exclusive_uuids; *ptr != NULL; ++ptr) {
+	 if(!strcmp(tpmif->uuid, *ptr)) {
+	    break;
+	 }
+      }
+      /* If *ptr == NULL then we went through the whole list without a match, so close the connection */
+      if(*ptr == NULL) {
+	 tpmif_change_state(tpmif, XenbusStateClosed);
+	 TPMBACK_ERR("Frontend %u/%u tried to connect with invalid uuid=%s\n", (unsigned int) domid, handle, tpmif->uuid);
+	 goto error;
+      }
+   }
+
+   /* allocate pages to be used for shared mapping */
+   if((tpmif->pages = malloc(sizeof(void*) * TPMIF_TX_RING_SIZE)) == NULL) {
+      goto error;
+   }
+   memset(tpmif->pages, 0, sizeof(void*) * TPMIF_TX_RING_SIZE);
+
+   if(tpmif_change_state(tpmif, XenbusStateInitWait)) {
+      goto error;
+   }
+
+   snprintf(path, 512, "backend/vtpm/%u/%u/frontend", (unsigned int) domid, handle);
+   if((err = xenbus_read(XBT_NIL, path, &tpmif->fe_path))) {
+      TPMBACK_ERR("Error creating new tpm instance xenbus_read(%s), Error = %s", path, err);
+      free(err);
+      goto error;
+   }
+
+   /*Set the state path */
+   tpmif->fe_state_path = malloc(strlen(tpmif->fe_path) + 7);
+   strcpy(tpmif->fe_state_path, tpmif->fe_path);
+   strcat(tpmif->fe_state_path, "/state");
+
+   if(insert_tpmif(tpmif)) {
+      goto error;
+   }
+   TPMBACK_DEBUG("New tpmif %u/%u\n", (unsigned int) tpmif->domid, tpmif->handle);
+   /* Do the callback now */
+   if(gtpmdev.open_callback) {
+      gtpmdev.open_callback(tpmif->domid, tpmif->handle);
+   }
+   return tpmif;
+error:
+   __free_tpmif(tpmif);
+   return NULL;
+
+}
+
+/* Removes tpmif from dev->tpmlist and frees it's memory usage */
+void free_tpmif(tpmif_t* tpmif)
+{
+   char* err;
+   char path[512];
+   TPMBACK_DEBUG("Free tpmif %u/%u\n", (unsigned int) tpmif->domid, tpmif->handle);
+   if(tpmif->flags & TPMIF_CLOSED) {
+      TPMBACK_ERR("Tried to free an instance twice! Theres a bug somewhere!\n");
+      BUG();
+   }
+   tpmif->flags = TPMIF_CLOSED;
+
+   tpmif_change_state(tpmif, XenbusStateClosing);
+
+   /* Unmap share page and unbind event channel */
+   if(tpmif->status == CONNECTED) {
+      tpmif->status = DISCONNECTING;
+      mask_evtchn(tpmif->evtchn);
+
+      if(gntmap_munmap(&gtpmdev.map, (unsigned long)tpmif->tx, 1)) {
+	 TPMBACK_ERR("%u/%u Error occured while trying to unmap shared page\n", (unsigned int) tpmif->domid, tpmif->handle);
+      }
+
+      unbind_evtchn(tpmif->evtchn);
+   }
+   tpmif->status = DISCONNECTED;
+   tpmif_change_state(tpmif, XenbusStateClosed);
+
+   /* Do the callback now */
+   if(gtpmdev.close_callback) {
+      gtpmdev.close_callback(tpmif->domid, tpmif->handle);
+   }
+
+   /* remove from array */
+   remove_tpmif(tpmif);
+
+   /* Wake up anyone possibly waiting on this interface and let them exit */
+   wake_up(&waitq);
+   schedule();
+
+   /* Remove the old xenbus entries */
+   snprintf(path, 512, "backend/vtpm/%u/%u", (unsigned int) tpmif->domid, tpmif->handle);
+   if((err = xenbus_rm(XBT_NIL, path))) {
+      TPMBACK_ERR("Error cleaning up xenbus entries path=%s error=%s\n", path, err);
+      free(err);
+   }
+
+   TPMBACK_LOG("Frontend %u/%u disconnected\n", (unsigned int) tpmif->domid, tpmif->handle);
+
+   /* free memory */
+   __free_tpmif(tpmif);
+
+}
+
+/**********************
+ * REMAINING TPMBACK FUNCTIONS
+ * ********************/
+
+/*Event channel handler */
+void tpmback_handler(evtchn_port_t port, struct pt_regs *regs, void *data)
+{
+   tpmif_t* tpmif = (tpmif_t*) data;
+   tpmif_tx_request_t* tx = &tpmif->tx->ring[0].req;
+   /* Throw away 0 size events, these can trigger from event channel unmasking */
+   if(tx->size == 0)
+      return;
+
+   TPMBACK_DEBUG("EVENT CHANNEL FIRE %u/%u\n", (unsigned int) tpmif->domid, tpmif->handle);
+   tpmif_req_ready(tpmif);
+   wake_up(&waitq);
+
+}
+
+/* Connect to frontend */
+int connect_fe(tpmif_t* tpmif)
+{
+   char path[512];
+   char* err, *value;
+   uint32_t domid;
+   grant_ref_t ringref;
+   evtchn_port_t evtchn;
+
+   /* If already connected then quit */
+   if (tpmif->status == CONNECTED) {
+      TPMBACK_DEBUG("%u/%u tried to connect while it was already connected?\n", (unsigned int) tpmif->domid, tpmif->handle);
+      return 0;
+   }
+
+   /* Fetch the grant reference */
+   snprintf(path, 512, "%s/ring-ref", tpmif->fe_path);
+   if((err = xenbus_read(XBT_NIL, path, &value))) {
+      TPMBACK_ERR("Error creating new tpm instance xenbus_read(%s) Error = %s", path, err);
+      free(err);
+      return -1;
+   }
+   if(sscanf(value, "%d", &ringref) != 1) {
+      TPMBACK_ERR("Non integer value (%s) in %s ??\n", value, path);
+      free(value);
+      return -1;
+   }
+   free(value);
+
+
+   /* Fetch the event channel*/
+   snprintf(path, 512, "%s/event-channel", tpmif->fe_path);
+   if((err = xenbus_read(XBT_NIL, path, &value))) {
+      TPMBACK_ERR("Error creating new tpm instance xenbus_read(%s) Error = %s", path, err);
+      free(err);
+      return -1;
+   }
+   if(sscanf(value, "%d", &evtchn) != 1) {
+      TPMBACK_ERR("Non integer value (%s) in %s ??\n", value, path);
+      free(value);
+      return -1;
+   }
+   free(value);
+
+   domid = tpmif->domid;
+   if((tpmif->tx = gntmap_map_grant_refs(&gtpmdev.map, 1, &domid, 0, &ringref, PROT_READ | PROT_WRITE)) == NULL) {
+      TPMBACK_ERR("Failed to map grant reference %u/%u\n", (unsigned int) tpmif->domid, tpmif->handle);
+      return -1;
+   }
+   memset(tpmif->tx, 0, PAGE_SIZE);
+
+   /*Bind the event channel */
+   if((evtchn_bind_interdomain(tpmif->domid, evtchn, tpmback_handler, tpmif, &tpmif->evtchn)))
+   {
+      TPMBACK_ERR("%u/%u Unable to bind to interdomain event channel!\n", (unsigned int) tpmif->domid, tpmif->handle);
+      goto error_post_map;
+   }
+   unmask_evtchn(tpmif->evtchn);
+
+   /* Write the ready flag and change status to connected */
+   snprintf(path, 512, "backend/vtpm/%u/%u", (unsigned int) tpmif->domid, tpmif->handle);
+   if((err = xenbus_printf(XBT_NIL, path, "ready", "%u", 1))) {
+      TPMBACK_ERR("%u/%u Unable to write ready flag on connect_fe()\n", (unsigned int) tpmif->domid, tpmif->handle);
+      free(err);
+      goto error_post_evtchn;
+   }
+   tpmif->status = CONNECTED;
+   if((tpmif_change_state(tpmif, XenbusStateConnected))){
+      goto error_post_evtchn;
+   }
+
+   TPMBACK_LOG("Frontend %u/%u connected\n", (unsigned int) tpmif->domid, tpmif->handle);
+
+   return 0;
+error_post_evtchn:
+   mask_evtchn(tpmif->evtchn);
+   unbind_evtchn(tpmif->evtchn);
+error_post_map:
+   gntmap_munmap(&gtpmdev.map, (unsigned long)tpmif->tx, 1);
+   return -1;
+}
+
+static int frontend_changed(tpmif_t* tpmif)
+{
+   int state = xenbus_read_integer(tpmif->fe_state_path);
+   if(state < 0) {
+      state = XenbusStateUnknown;
+   }
+
+   TPMBACK_DEBUG("Frontend %u/%u state changed to %d\n", (unsigned int) tpmif->domid, tpmif->handle, state);
+
+   switch (state) {
+      case XenbusStateInitialising:
+      case XenbusStateInitialised:
+	 break;
+
+      case XenbusStateConnected:
+	 if(connect_fe(tpmif)) {
+	    TPMBACK_ERR("Failed to connect to front end %u/%u\n", (unsigned int) tpmif->domid, tpmif->handle);
+	    tpmif_change_state(tpmif, XenbusStateClosed);
+	    return -1;
+	 }
+	 break;
+
+      case XenbusStateClosing:
+	 tpmif_change_state(tpmif, XenbusStateClosing);
+	 break;
+
+      case XenbusStateUnknown: /* keep it here */
+      case XenbusStateClosed:
+	 free_tpmif(tpmif);
+	 break;
+
+      default:
+	 TPMBACK_DEBUG("BAD STATE CHANGE %u/%u state = %d for tpmif\n", (unsigned int) tpmif->domid, tpmif->handle, state);
+	 return -1;
+   }
+   return 0;
+}
+
+
+/* parses the string that comes out of xenbus_watch_wait_return. */
+static int parse_eventstr(const char* evstr, domid_t* domid, unsigned int* handle)
+{
+   int ret;
+   char cmd[40];
+   char* err;
+   char* value;
+   unsigned int udomid = 0;
+   tpmif_t* tpmif;
+   /* First check for new frontends, this occurs when /backend/vtpm/<domid>/<handle> gets created. Note we what the sscanf to fail on the last %s */
+   if (sscanf(evstr, "backend/vtpm/%u/%u/%40s", &udomid, handle, cmd) == 2) {
+      *domid = udomid;
+      /* Make sure the entry exists, if this event triggers because the entry dissapeared then ignore it */
+      if((err = xenbus_read(XBT_NIL, evstr, &value))) {
+	 free(err);
+	 return EV_NONE;
+      }
+      free(value);
+      /* Make sure the tpmif entry does not already exist, this should not happen */
+      if((tpmif = get_tpmif(*domid, *handle)) != NULL) {
+	 TPMBACK_DEBUG("Duplicate tpm entries! %u %u\n", tpmif->domid, tpmif->handle);
+	 return EV_NONE;
+      }
+      return EV_NEWFE;
+   } else if((ret = sscanf(evstr, "/local/domain/%u/device/vtpm/%u/%40s", &udomid, handle, cmd)) == 3) {
+      *domid = udomid;
+      if (!strcmp(cmd, "state"))
+	 return EV_STCHNG;
+   }
+   return EV_NONE;
+}
+
+void handle_backend_event(char* evstr) {
+   tpmif_t* tpmif;
+   domid_t domid;
+   unsigned int handle;
+   int event;
+
+   TPMBACK_DEBUG("Xenbus Event: %s\n", evstr);
+
+   event = parse_eventstr(evstr, &domid, &handle);
+
+   switch(event) {
+      case EV_NEWFE:
+	 if(new_tpmif(domid, handle) == NULL) {
+	    TPMBACK_ERR("Failed to create new tpm instance %u/%u\n", (unsigned int) domid, handle);
+	 }
+	 wake_up(&waitq);
+	 break;
+      case EV_STCHNG:
+	 if((tpmif = get_tpmif(domid, handle))) {
+	    frontend_changed(tpmif);
+	 } else {
+	    TPMBACK_DEBUG("Event Received for non-existant tpm! instance=%u/%u xenbus_event=%s\n", (unsigned int) domid, handle, evstr);
+	 }
+	 break;
+   }
+}
+
+/* Runs through the given path and creates events recursively
+ * for all of its children.
+ * @path - xenstore path to scan */
+static void generate_backend_events(const char* path)
+{
+   char* err;
+   int i, len;
+   char **dirs;
+   char *entry;
+
+   if((err = xenbus_ls(XBT_NIL, path, &dirs)) != NULL) {
+      free(err);
+      return;
+   }
+
+   for(i = 0; dirs[i] != NULL; ++i) {
+      len = strlen(path) + strlen(dirs[i]) + 2;
+      entry = malloc(len);
+      snprintf(entry, len, "%s/%s", path, dirs[i]);
+
+      /* Generate and handle event for the entry itself */
+      handle_backend_event(entry);
+
+      /* Do children */
+      generate_backend_events(entry);
+
+      /* Cleanup */
+      free(entry);
+      free(dirs[i]);
+   }
+   free(dirs);
+   return;
+}
+
+char* tpmback_get_uuid(domid_t domid, unsigned int handle)
+{
+   tpmif_t* tpmif;
+   if((tpmif = get_tpmif(domid, handle)) == NULL) {
+      TPMBACK_DEBUG("get_uuid() failed, %u/%u is an invalid frontend\n", (unsigned int) domid, handle);
+      return NULL;
+   }
+
+   return tpmif->uuid;
+}
+
+void tpmback_set_open_callback(void (*cb)(domid_t, unsigned int))
+{
+   gtpmdev.open_callback = cb;
+}
+void tpmback_set_close_callback(void (*cb)(domid_t, unsigned int))
+{
+   gtpmdev.close_callback = cb;
+}
+void tpmback_set_suspend_callback(void (*cb)(domid_t, unsigned int))
+{
+   gtpmdev.suspend_callback = cb;
+}
+void tpmback_set_resume_callback(void (*cb)(domid_t, unsigned int))
+{
+   gtpmdev.resume_callback = cb;
+}
+
+static void event_listener(void)
+{
+   const char* bepath = "backend/vtpm";
+   char **path;
+   char* err;
+
+   /* Setup the backend device watch */
+   if((err = xenbus_watch_path_token(XBT_NIL, bepath, bepath, &gtpmdev.events)) != NULL) {
+      TPMBACK_ERR("xenbus_watch_path_token(%s) failed with error %s!\n", bepath, err);
+      free(err);
+      goto egress;
+   }
+
+   /* Check for any frontends that connected before we set the watch.
+    * This is almost guaranteed to happen if both domains are started
+    * immediatly one after the other.
+    * We do this by manually generating events on everything in the backend
+    * path */
+   generate_backend_events(bepath);
+
+   /* Wait and listen for changes in frontend connections */
+   while(1) {
+      path = xenbus_wait_for_watch_return(&gtpmdev.events);
+
+      /*If quit flag was set then exit */
+      if(gtpmdev.flags & TPMIF_CLOSED) {
+	 TPMBACK_DEBUG("listener thread got quit event. Exiting..\n");
+	 free(path);
+	 break;
+      }
+      handle_backend_event(*path);
+      free(path);
+
+   }
+
+   if((err = xenbus_unwatch_path_token(XBT_NIL, bepath, bepath)) != NULL) {
+      free(err);
+   }
+egress:
+   return;
+}
+
+void event_thread(void* p) {
+   event_listener();
+}
+
+void init_tpmback(char** exclusive_uuids)
+{
+   if(!globalinit) {
+      init_waitqueue_head(&waitq);
+      globalinit = 1;
+   }
+   printk("============= Init TPM BACK ================\n");
+   gtpmdev.tpmlist = malloc(sizeof(tpmif_t*) * DEF_ARRAY_SIZE);
+   gtpmdev.num_alloc = DEF_ARRAY_SIZE;
+   gtpmdev.num_tpms = 0;
+   gtpmdev.flags = 0;
+   gtpmdev.exclusive_uuids = exclusive_uuids;
+
+   gtpmdev.open_callback = gtpmdev.close_callback = NULL;
+   gtpmdev.suspend_callback = gtpmdev.resume_callback = NULL;
+
+   eventthread = create_thread("tpmback-listener", event_thread, NULL);
+
+}
+
+void shutdown_tpmback(void)
+{
+   /* Disable callbacks */
+   gtpmdev.open_callback = gtpmdev.close_callback = NULL;
+   gtpmdev.suspend_callback = gtpmdev.resume_callback = NULL;
+
+   TPMBACK_LOG("Shutting down tpm backend\n");
+   /* Set the quit flag */
+   gtpmdev.flags = TPMIF_CLOSED;
+
+   //printk("num tpms is %d\n", gtpmdev.num_tpms);
+   /*Free all backend instances */
+   while(gtpmdev.num_tpms) {
+      free_tpmif(gtpmdev.tpmlist[0]);
+   }
+   free(gtpmdev.tpmlist);
+   gtpmdev.tpmlist = NULL;
+   gtpmdev.num_alloc = 0;
+
+   /* Wake up anyone possibly waiting on the device and let them exit */
+   wake_up(&waitq);
+   schedule();
+}
+
+inline void init_tpmcmd(tpmcmd_t* tpmcmd, domid_t domid, unsigned int handle, char* uuid)
+{
+   tpmcmd->domid = domid;
+   tpmcmd->handle = handle;
+   tpmcmd->uuid = uuid;
+   tpmcmd->req = NULL;
+   tpmcmd->req_len = 0;
+   tpmcmd->resp = NULL;
+   tpmcmd->resp_len = 0;
+}
+
+tpmcmd_t* get_request(tpmif_t* tpmif) {
+   tpmcmd_t* cmd;
+   tpmif_tx_request_t* tx;
+   int offset;
+   int tocopy;
+   int i;
+   uint32_t domid;
+   int flags;
+
+   local_irq_save(flags);
+
+   /* Allocate the cmd object to hold the data */
+   if((cmd = malloc(sizeof(*cmd))) == NULL) {
+      goto error;
+   }
+   init_tpmcmd(cmd, tpmif->domid, tpmif->handle, tpmif->uuid);
+
+   tx = &tpmif->tx->ring[0].req;
+   cmd->req_len = tx->size;
+   /* Allocate the buffer */
+   if(cmd->req_len) {
+      if((cmd->req = malloc(cmd->req_len)) == NULL) {
+	 goto error;
+      }
+   }
+   /* Copy the bits from the shared pages */
+   offset = 0;
+   for(i = 0; i < TPMIF_TX_RING_SIZE && offset < cmd->req_len; ++i) {
+      tx = &tpmif->tx->ring[i].req;
+
+      /* Map the page with the data */
+      domid = (uint32_t)tpmif->domid;
+      if((tpmif->pages[i] = gntmap_map_grant_refs(&gtpmdev.map, 1, &domid, 0, &tx->ref, PROT_READ)) == NULL) {
+	 TPMBACK_ERR("%u/%u Unable to map shared page during read!\n", (unsigned int) tpmif->domid, tpmif->handle);
+	 goto error;
+      }
+
+      /* do the copy now */
+      tocopy = min(cmd->req_len - offset, PAGE_SIZE);
+      memcpy(&cmd->req[offset], tpmif->pages[i], tocopy);
+      offset += tocopy;
+
+      /* release the page */
+      gntmap_munmap(&gtpmdev.map, (unsigned long)tpmif->pages[i], 1);
+
+   }
+
+#ifdef TPMBACK_PRINT_DEBUG
+   TPMBACK_DEBUG("Received Tpm Command from %u/%u of size %u", (unsigned int) tpmif->domid, tpmif->handle, cmd->req_len);
+   for(i = 0; i < cmd->req_len; ++i) {
+      if (!(i % 30)) {
+	 TPMBACK_DEBUG_MORE("\n");
+      }
+      TPMBACK_DEBUG_MORE("%02hhX ", cmd->req[i]);
+   }
+   TPMBACK_DEBUG_MORE("\n\n");
+#endif
+
+   local_irq_restore(flags);
+   return cmd;
+error:
+   if(cmd != NULL) {
+      if (cmd->req != NULL) {
+	 free(cmd->req);
+	 cmd->req = NULL;
+      }
+      free(cmd);
+      cmd = NULL;
+   }
+   local_irq_restore(flags);
+   return NULL;
+
+}
+
+void send_response(tpmcmd_t* cmd, tpmif_t* tpmif)
+{
+   tpmif_tx_request_t* tx;
+   int offset;
+   int i;
+   uint32_t domid;
+   int tocopy;
+   int flags;
+
+   local_irq_save(flags);
+
+   tx = &tpmif->tx->ring[0].req;
+   tx->size = cmd->resp_len;
+
+   offset = 0;
+   for(i = 0; i < TPMIF_TX_RING_SIZE && offset < cmd->resp_len; ++i) {
+      tx = &tpmif->tx->ring[i].req;
+
+      /* Map the page with the data */
+      domid = (uint32_t)tpmif->domid;
+      if((tpmif->pages[i] = gntmap_map_grant_refs(&gtpmdev.map, 1, &domid, 0, &tx->ref, PROT_WRITE)) == NULL) {
+	 TPMBACK_ERR("%u/%u Unable to map shared page during write!\n", (unsigned int) tpmif->domid, tpmif->handle);
+	 goto error;
+      }
+
+      /* do the copy now */
+      tocopy = min(cmd->resp_len - offset, PAGE_SIZE);
+      memcpy(tpmif->pages[i], &cmd->resp[offset], tocopy);
+      offset += tocopy;
+
+      /* release the page */
+      gntmap_munmap(&gtpmdev.map, (unsigned long)tpmif->pages[i], 1);
+
+   }
+
+#ifdef TPMBACK_PRINT_DEBUG
+   TPMBACK_DEBUG("Sent response to %u/%u of size %u", (unsigned int) tpmif->domid, tpmif->handle, cmd->resp_len);
+   for(i = 0; i < cmd->resp_len; ++i) {
+      if (!(i % 30)) {
+	 TPMBACK_DEBUG_MORE("\n");
+      }
+      TPMBACK_DEBUG_MORE("%02hhX ", cmd->resp[i]);
+   }
+   TPMBACK_DEBUG_MORE("\n\n");
+#endif
+   /* clear the ready flag and send the event channel notice to the frontend */
+   tpmif_req_finished(tpmif);
+   notify_remote_via_evtchn(tpmif->evtchn);
+error:
+   local_irq_restore(flags);
+   return;
+}
+
+tpmcmd_t* tpmback_req_any(void)
+{
+   int i;
+   /* Block until something has a request */
+   wait_event(waitq, (gtpmdev.flags & (TPMIF_REQ_READY | TPMIF_CLOSED)));
+
+   /* Check if were shutting down */
+   if(gtpmdev.flags & TPMIF_CLOSED) {
+      /* if something was waiting for us to give up the queue so it can shutdown, let it finish */
+      schedule();
+      return NULL;
+   }
+
+   for(i = 0; i < gtpmdev.num_tpms; ++i) {
+      if(gtpmdev.tpmlist[i]->flags & TPMIF_REQ_READY) {
+	 return get_request(gtpmdev.tpmlist[i]);
+      }
+   }
+
+   TPMBACK_ERR("backend request ready flag was set but no interfaces were actually ready\n");
+   return NULL;
+}
+
+tpmcmd_t* tpmback_req(domid_t domid, unsigned int handle)
+{
+   tpmif_t* tpmif;
+   tpmif = get_tpmif(domid, handle);
+   if(tpmif == NULL) {
+      return NULL;
+   }
+
+   wait_event(waitq, (tpmif->flags & (TPMIF_REQ_READY | TPMIF_CLOSED) || gtpmdev.flags & TPMIF_CLOSED));
+
+   /* Check if were shutting down */
+   if(tpmif->flags & TPMIF_CLOSED || gtpmdev.flags & TPMIF_CLOSED) {
+      /* if something was waiting for us to give up the queue so it can free this instance, let it finish */
+      schedule();
+      return NULL;
+   }
+
+   return get_request(tpmif);
+}
+
+void tpmback_resp(tpmcmd_t* tpmcmd)
+{
+   tpmif_t* tpmif;
+
+   /* Get the associated interface, if it doesnt exist then just quit */
+   tpmif = get_tpmif(tpmcmd->domid, tpmcmd->handle);
+   if(tpmif == NULL) {
+      TPMBACK_ERR("Tried to send a reponse to non existant frontend %u/%u\n", (unsigned int) tpmcmd->domid, tpmcmd->handle);
+      goto end;
+   }
+
+   if(!(tpmif->flags & TPMIF_REQ_READY)) {
+      TPMBACK_ERR("Tried to send response to a frontend that was not waiting for one %u/%u\n", (unsigned int) tpmcmd->domid, tpmcmd->handle);
+      goto end;
+   }
+
+   /* Send response to frontend */
+   send_response(tpmcmd, tpmif);
+
+end:
+   if(tpmcmd->req != NULL) {
+      free(tpmcmd->req);
+   }
+   free(tpmcmd);
+   return;
+}
+
+int tpmback_wait_for_frontend_connect(domid_t *domid, unsigned int *handle)
+{
+   tpmif_t* tpmif;
+   int flags;
+   wait_event(waitq, ((gtpmdev.num_tpms > 0) || gtpmdev.flags & TPMIF_CLOSED));
+   if(gtpmdev.flags & TPMIF_CLOSED) {
+      return -1;
+   }
+   local_irq_save(flags);
+   tpmif = gtpmdev.tpmlist[0];
+   *domid = tpmif->domid;
+   *handle = tpmif->handle;
+   local_irq_restore(flags);
+
+   return 0;
+}
+
+int tpmback_num_frontends(void)
+{
+   return gtpmdev.num_tpms;
+}
diff --git a/extras/mini-os/tpmfront.c b/extras/mini-os/tpmfront.c
new file mode 100644
index 0000000..a2f9175
--- /dev/null
+++ b/extras/mini-os/tpmfront.c
@@ -0,0 +1,617 @@
+/*
+ * Copyright (c) 2010-2012 United States Government, as represented by
+ * the Secretary of Defense.  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 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.
+ *
+ * Based upon the files:
+ *  drivers/char/tpm/tpm_vtpm.c
+ *  drivers/char/tpm/tpm_xen.c
+ * from the Linux kernel, which are Copyright (C) 2006 IBM Corporation
+ */
+#include <mini-os/os.h>
+#include <mini-os/xenbus.h>
+#include <mini-os/xmalloc.h>
+#include <mini-os/events.h>
+#include <mini-os/wait.h>
+#include <mini-os/gnttab.h>
+#include <xen/io/xenbus.h>
+#include <xen/io/tpmif.h>
+#include <mini-os/tpmfront.h>
+#include <fcntl.h>
+
+//#define TPMFRONT_PRINT_DEBUG
+#ifdef TPMFRONT_PRINT_DEBUG
+#define TPMFRONT_DEBUG(fmt,...) printk("Tpmfront:Debug("__FILE__":%d) " fmt, __LINE__, ##__VA_ARGS__)
+#define TPMFRONT_DEBUG_MORE(fmt,...) printk(fmt, ##__VA_ARGS__)
+#else
+#define TPMFRONT_DEBUG(fmt,...)
+#endif
+#define TPMFRONT_ERR(fmt,...) printk("Tpmfront:Error " fmt, ##__VA_ARGS__)
+#define TPMFRONT_LOG(fmt,...) printk("Tpmfront:Info " fmt, ##__VA_ARGS__)
+
+#define min(a,b) (((a) < (b)) ? (a) : (b))
+
+void tpmfront_handler(evtchn_port_t port, struct pt_regs *regs, void *data) {
+   struct tpmfront_dev* dev = (struct tpmfront_dev*) data;
+   /*If we get a response when we didnt make a request, just ignore it */
+   if(!dev->waiting) {
+      return;
+   }
+
+   dev->waiting = 0;
+#ifdef HAVE_LIBC
+   if(dev->fd >= 0) {
+      files[dev->fd].read = 1;
+   }
+#endif
+   wake_up(&dev->waitq);
+}
+
+static int publish_xenbus(struct tpmfront_dev* dev) {
+   xenbus_transaction_t xbt;
+   int retry;
+   char* err;
+   /* Write the grant reference and event channel to xenstore */
+again:
+   if((err = xenbus_transaction_start(&xbt))) {
+      TPMFRONT_ERR("Unable to start xenbus transaction, error was %s\n", err);
+      free(err);
+      return -1;
+   }
+
+   if((err = xenbus_printf(xbt, dev->nodename, "ring-ref", "%u", (unsigned int) dev->ring_ref))) {
+      TPMFRONT_ERR("Unable to write %s/ring-ref, error was %s\n", dev->nodename, err);
+      free(err);
+      goto abort_transaction;
+   }
+
+   if((err = xenbus_printf(xbt, dev->nodename, "event-channel", "%u", (unsigned int) dev->evtchn))) {
+      TPMFRONT_ERR("Unable to write %s/event-channel, error was %s\n", dev->nodename, err);
+      free(err);
+      goto abort_transaction;
+   }
+
+   if((err = xenbus_transaction_end(xbt, 0, &retry))) {
+      TPMFRONT_ERR("Unable to complete xenbus transaction, error was %s\n", err);
+      free(err);
+      return -1;
+   }
+   if(retry) {
+      goto again;
+   }
+
+   return 0;
+abort_transaction:
+   if((err = xenbus_transaction_end(xbt, 1, &retry))) {
+      free(err);
+   }
+   return -1;
+}
+
+static int wait_for_backend_connect(xenbus_event_queue* events, char* path)
+{
+   int state;
+
+   TPMFRONT_LOG("Waiting for backend connection..\n");
+   /* Wait for the backend to connect */
+   while(1) {
+      state = xenbus_read_integer(path);
+      if ( state < 0)
+	 state = XenbusStateUnknown;
+      switch(state) {
+	 /* Bad states, we quit with error */
+	 case XenbusStateUnknown:
+	 case XenbusStateClosing:
+	 case XenbusStateClosed:
+	    TPMFRONT_ERR("Unable to connect to backend\n");
+	    return -1;
+	 /* If backend is connected then break out of loop */
+	 case XenbusStateConnected:
+	    TPMFRONT_LOG("Backend Connected\n");
+	    return 0;
+	 default:
+	    xenbus_wait_for_watch(events);
+      }
+   }
+
+}
+
+static int wait_for_backend_closed(xenbus_event_queue* events, char* path)
+{
+   int state;
+
+   TPMFRONT_LOG("Waiting for backend to close..\n");
+   while(1) {
+      state = xenbus_read_integer(path);
+      if ( state < 0)
+	 state = XenbusStateUnknown;
+      switch(state) {
+	 case XenbusStateUnknown:
+	    TPMFRONT_ERR("Backend Unknown state, forcing shutdown\n");
+	    return -1;
+	 case XenbusStateClosed:
+	    TPMFRONT_LOG("Backend Closed\n");
+	    return 0;
+	 default:
+	    xenbus_wait_for_watch(events);
+      }
+   }
+
+}
+
+static int wait_for_backend_state_changed(struct tpmfront_dev* dev, XenbusState state) {
+   char* err;
+   int ret = 0;
+   xenbus_event_queue events = NULL;
+   char path[512];
+
+   snprintf(path, 512, "%s/state", dev->bepath);
+   /*Setup the watch to wait for the backend */
+   if((err = xenbus_watch_path_token(XBT_NIL, path, path, &events))) {
+      TPMFRONT_ERR("Could not set a watch on %s, error was %s\n", path, err);
+      free(err);
+      return -1;
+   }
+
+   /* Do the actual wait loop now */
+   switch(state) {
+      case XenbusStateConnected:
+	 ret = wait_for_backend_connect(&events, path);
+	 break;
+      case XenbusStateClosed:
+	 ret = wait_for_backend_closed(&events, path);
+	 break;
+      default:
+	 break;
+   }
+
+   if((err = xenbus_unwatch_path_token(XBT_NIL, path, path))) {
+      TPMFRONT_ERR("Unable to unwatch %s, error was %s, ignoring..\n", path, err);
+      free(err);
+   }
+   return ret;
+}
+
+static int tpmfront_connect(struct tpmfront_dev* dev)
+{
+   char* err;
+   /* Create shared page */
+   dev->tx = (tpmif_tx_interface_t*) alloc_page();
+   if(dev->tx == NULL) {
+      TPMFRONT_ERR("Unable to allocate page for shared memory\n");
+      goto error;
+   }
+   memset(dev->tx, 0, PAGE_SIZE);
+   dev->ring_ref = gnttab_grant_access(dev->bedomid, virt_to_mfn(dev->tx), 0);
+   TPMFRONT_DEBUG("grant ref is %lu\n", (unsigned long) dev->ring_ref);
+
+   /*Create event channel */
+   if(evtchn_alloc_unbound(dev->bedomid, tpmfront_handler, dev, &dev->evtchn)) {
+      TPMFRONT_ERR("Unable to allocate event channel\n");
+      goto error_postmap;
+   }
+   unmask_evtchn(dev->evtchn);
+   TPMFRONT_DEBUG("event channel is %lu\n", (unsigned long) dev->evtchn);
+
+   /* Write the entries to xenstore */
+   if(publish_xenbus(dev)) {
+      goto error_postevtchn;
+   }
+
+   /* Change state to connected */
+   dev->state = XenbusStateConnected;
+
+   /* Tell the backend that we are ready */
+   if((err = xenbus_printf(XBT_NIL, dev->nodename, "state", "%u", dev->state))) {
+      TPMFRONT_ERR("Unable to write to xenstore %s/state, value=%u", dev->nodename, XenbusStateConnected);
+      free(err);
+      goto error;
+   }
+
+   return 0;
+error_postevtchn:
+      mask_evtchn(dev->evtchn);
+      unbind_evtchn(dev->evtchn);
+error_postmap:
+      gnttab_end_access(dev->ring_ref);
+      free_page(dev->tx);
+error:
+   return -1;
+}
+
+struct tpmfront_dev* init_tpmfront(const char* _nodename)
+{
+   struct tpmfront_dev* dev;
+   const char* nodename;
+   char path[512];
+   char* value, *err;
+   unsigned long long ival;
+   int i;
+
+   printk("============= Init TPM Front ================\n");
+
+   dev = malloc(sizeof(struct tpmfront_dev));
+   memset(dev, 0, sizeof(struct tpmfront_dev));
+
+#ifdef HAVE_LIBC
+   dev->fd = -1;
+#endif
+
+   nodename = _nodename ? _nodename : "device/vtpm/0";
+   dev->nodename = strdup(nodename);
+
+   init_waitqueue_head(&dev->waitq);
+
+   /* Get backend domid */
+   snprintf(path, 512, "%s/backend-id", dev->nodename);
+   if((err = xenbus_read(XBT_NIL, path, &value))) {
+      TPMFRONT_ERR("Unable to read %s during tpmfront initialization! error = %s\n", path, err);
+      free(err);
+      goto error;
+   }
+   if(sscanf(value, "%llu", &ival) != 1) {
+      TPMFRONT_ERR("%s has non-integer value (%s)\n", path, value);
+      free(value);
+      goto error;
+   }
+   free(value);
+   dev->bedomid = ival;
+
+   /* Get backend xenstore path */
+   snprintf(path, 512, "%s/backend", dev->nodename);
+   if((err = xenbus_read(XBT_NIL, path, &dev->bepath))) {
+      TPMFRONT_ERR("Unable to read %s during tpmfront initialization! error = %s\n", path, err);
+      free(err);
+      goto error;
+   }
+
+   /* Create and publish grant reference and event channel */
+   if (tpmfront_connect(dev)) {
+      goto error;
+   }
+
+   /* Wait for backend to connect */
+   if( wait_for_backend_state_changed(dev, XenbusStateConnected)) {
+      goto error;
+   }
+
+   /* Allocate pages that will contain the messages */
+   dev->pages = malloc(sizeof(void*) * TPMIF_TX_RING_SIZE);
+   if(dev->pages == NULL) {
+      goto error;
+   }
+   memset(dev->pages, 0, sizeof(void*) * TPMIF_TX_RING_SIZE);
+   for(i = 0; i < TPMIF_TX_RING_SIZE; ++i) {
+      dev->pages[i] = (void*)alloc_page();
+      if(dev->pages[i] == NULL) {
+	 goto error;
+      }
+   }
+
+   TPMFRONT_LOG("Initialization Completed successfully\n");
+
+   return dev;
+
+error:
+   shutdown_tpmfront(dev);
+   return NULL;
+}
+void shutdown_tpmfront(struct tpmfront_dev* dev)
+{
+   char* err;
+   char path[512];
+   int i;
+   tpmif_tx_request_t* tx;
+   if(dev == NULL) {
+      return;
+   }
+   TPMFRONT_LOG("Shutting down tpmfront\n");
+   /* disconnect */
+   if(dev->state == XenbusStateConnected) {
+      dev->state = XenbusStateClosing;
+      //FIXME: Transaction for this?
+      /* Tell backend we are closing */
+      if((err = xenbus_printf(XBT_NIL, dev->nodename, "state", "%u", (unsigned int) dev->state))) {
+	 free(err);
+      }
+
+      /* Clean up xenstore entries */
+      snprintf(path, 512, "%s/event-channel", dev->nodename);
+      if((err = xenbus_rm(XBT_NIL, path))) {
+	 free(err);
+      }
+      snprintf(path, 512, "%s/ring-ref", dev->nodename);
+      if((err = xenbus_rm(XBT_NIL, path))) {
+	 free(err);
+      }
+
+      /* Tell backend we are closed */
+      dev->state = XenbusStateClosed;
+      if((err = xenbus_printf(XBT_NIL, dev->nodename, "state", "%u", (unsigned int) dev->state))) {
+	 TPMFRONT_ERR("Unable to write to %s, error was %s", dev->nodename, err);
+	 free(err);
+      }
+
+      /* Wait for the backend to close and unmap shared pages, ignore any errors */
+      wait_for_backend_state_changed(dev, XenbusStateClosed);
+
+      /* Cleanup any shared pages */
+      if(dev->pages) {
+	 for(i = 0; i < TPMIF_TX_RING_SIZE; ++i) {
+	    if(dev->pages[i]) {
+	       tx = &dev->tx->ring[i].req;
+	       if(tx->ref != 0) {
+		  gnttab_end_access(tx->ref);
+	       }
+	       free_page(dev->pages[i]);
+	    }
+	 }
+	 free(dev->pages);
+      }
+
+      /* Close event channel and unmap shared page */
+      mask_evtchn(dev->evtchn);
+      unbind_evtchn(dev->evtchn);
+      gnttab_end_access(dev->ring_ref);
+
+      free_page(dev->tx);
+
+   }
+
+   /* Cleanup memory usage */
+   if(dev->respbuf) {
+      free(dev->respbuf);
+   }
+   if(dev->bepath) {
+      free(dev->bepath);
+   }
+   if(dev->nodename) {
+      free(dev->nodename);
+   }
+   free(dev);
+}
+
+int tpmfront_send(struct tpmfront_dev* dev, const uint8_t* msg, size_t length)
+{
+   int i;
+   tpmif_tx_request_t* tx = NULL;
+   /* Error Checking */
+   if(dev == NULL || dev->state != XenbusStateConnected) {
+      TPMFRONT_ERR("Tried to send message through disconnected frontend\n");
+      return -1;
+   }
+
+#ifdef TPMFRONT_PRINT_DEBUG
+   TPMFRONT_DEBUG("Sending Msg to backend size=%u", (unsigned int) length);
+   for(i = 0; i < length; ++i) {
+      if(!(i % 30)) {
+	 TPMFRONT_DEBUG_MORE("\n");
+      }
+      TPMFRONT_DEBUG_MORE("%02X ", msg[i]);
+   }
+   TPMFRONT_DEBUG_MORE("\n");
+#endif
+
+   /* Copy to shared pages now */
+   for(i = 0; length > 0 && i < TPMIF_TX_RING_SIZE; ++i) {
+      /* Share the page */
+      tx = &dev->tx->ring[i].req;
+      tx->unused = 0;
+      tx->addr = virt_to_mach(dev->pages[i]);
+      tx->ref = gnttab_grant_access(dev->bedomid, virt_to_mfn(dev->pages[i]), 0);
+      /* Copy the bits to the page */
+      tx->size = length > PAGE_SIZE ? PAGE_SIZE : length;
+      memcpy(dev->pages[i], &msg[i * PAGE_SIZE], tx->size);
+
+      /* Update counters */
+      length -= tx->size;
+   }
+   dev->waiting = 1;
+   dev->resplen = 0;
+#ifdef HAVE_LIBC
+   if(dev->fd >= 0) {
+      files[dev->fd].read = 0;
+      files[dev->fd].tpmfront.respgot = 0;
+      files[dev->fd].tpmfront.offset = 0;
+   }
+#endif
+   notify_remote_via_evtchn(dev->evtchn);
+   return 0;
+}
+int tpmfront_recv(struct tpmfront_dev* dev, uint8_t** msg, size_t *length)
+{
+   tpmif_tx_request_t* tx;
+   int i;
+   if(dev == NULL || dev->state != XenbusStateConnected) {
+      TPMFRONT_ERR("Tried to receive message from disconnected frontend\n");
+      return -1;
+   }
+   /*Wait for the response */
+   wait_event(dev->waitq, (!dev->waiting));
+
+   /* Initialize */
+   *msg = NULL;
+   *length = 0;
+
+   /* special case, just quit */
+   tx = &dev->tx->ring[0].req;
+   if(tx->size == 0 ) {
+       goto quit;
+   }
+   /* Get the total size */
+   tx = &dev->tx->ring[0].req;
+   for(i = 0; i < TPMIF_TX_RING_SIZE && tx->size > 0; ++i) {
+      tx = &dev->tx->ring[i].req;
+      *length += tx->size;
+   }
+   /* Alloc the buffer */
+   if(dev->respbuf) {
+      free(dev->respbuf);
+   }
+   *msg = dev->respbuf = malloc(*length);
+   dev->resplen = *length;
+   /* Copy the bits */
+   tx = &dev->tx->ring[0].req;
+   for(i = 0; i < TPMIF_TX_RING_SIZE && tx->size > 0; ++i) {
+      tx = &dev->tx->ring[i].req;
+      memcpy(&(*msg)[i * PAGE_SIZE], dev->pages[i], tx->size);
+      gnttab_end_access(tx->ref);
+      tx->ref = 0;
+   }
+#ifdef TPMFRONT_PRINT_DEBUG
+   TPMFRONT_DEBUG("Received response from backend size=%u", (unsigned int) *length);
+   for(i = 0; i < *length; ++i) {
+      if(!(i % 30)) {
+	 TPMFRONT_DEBUG_MORE("\n");
+      }
+      TPMFRONT_DEBUG_MORE("%02X ", (*msg)[i]);
+   }
+   TPMFRONT_DEBUG_MORE("\n");
+#endif
+#ifdef HAVE_LIBC
+   if(dev->fd >= 0) {
+      files[dev->fd].tpmfront.respgot = 1;
+   }
+#endif
+quit:
+   return 0;
+}
+
+int tpmfront_cmd(struct tpmfront_dev* dev, uint8_t* req, size_t reqlen, uint8_t** resp, size_t* resplen)
+{
+   int rc;
+   if((rc = tpmfront_send(dev, req, reqlen))) {
+      return rc;
+   }
+   if((rc = tpmfront_recv(dev, resp, resplen))) {
+      return rc;
+   }
+
+   return 0;
+}
+
+#ifdef HAVE_LIBC
+#include <errno.h>
+int tpmfront_open(struct tpmfront_dev* dev)
+{
+   /* Silently prevent multiple opens */
+   if(dev->fd != -1) {
+      return dev->fd;
+   }
+
+   dev->fd = alloc_fd(FTYPE_TPMFRONT);
+   printk("tpmfront_open(%s) -> %d\n", dev->nodename, dev->fd);
+   files[dev->fd].tpmfront.dev = dev;
+   files[dev->fd].tpmfront.offset = 0;
+   files[dev->fd].tpmfront.respgot = 0;
+   return dev->fd;
+}
+
+int tpmfront_posix_write(int fd, const uint8_t* buf, size_t count)
+{
+   int rc;
+   struct tpmfront_dev* dev;
+   dev = files[fd].tpmfront.dev;
+
+   if(count == 0) {
+      return 0;
+   }
+
+   /* Return an error if we are already processing a command */
+   if(dev->waiting) {
+      errno = EINPROGRESS;
+      return -1;
+   }
+   /* Send the command now */
+   if((rc = tpmfront_send(dev, buf, count)) != 0) {
+      errno = EIO;
+      return -1;
+   }
+   return count;
+}
+
+int tpmfront_posix_read(int fd, uint8_t* buf, size_t count)
+{
+   int rc;
+   uint8_t* dummybuf;
+   size_t dummysz;
+   struct tpmfront_dev* dev;
+
+   dev = files[fd].tpmfront.dev;
+
+   if(count == 0) {
+      return 0;
+   }
+
+   /* get the response if we haven't already */
+   if(files[dev->fd].tpmfront.respgot == 0) {
+      if ((rc = tpmfront_recv(dev, &dummybuf, &dummysz)) != 0) {
+	 errno = EIO;
+	 return -1;
+      }
+   }
+
+   /* handle EOF case */
+   if(files[dev->fd].tpmfront.offset >= dev->resplen) {
+      return 0;
+   }
+
+   /* Compute the number of bytes and do the copy operation */
+   if((rc = min(count, dev->resplen - files[dev->fd].tpmfront.offset)) != 0) {
+      memcpy(buf, dev->respbuf + files[dev->fd].tpmfront.offset, rc);
+      files[dev->fd].tpmfront.offset += rc;
+   }
+
+   return rc;
+}
+
+int tpmfront_posix_fstat(int fd, struct stat* buf)
+{
+   uint8_t* dummybuf;
+   size_t dummysz;
+   int rc;
+   struct tpmfront_dev* dev = files[fd].tpmfront.dev;
+
+   /* If we have a response waiting, then read it now from the backend
+    * so we can get its length*/
+   if(dev->waiting || (files[dev->fd].read == 1 && !files[dev->fd].tpmfront.respgot)) {
+      if ((rc = tpmfront_recv(dev, &dummybuf, &dummysz)) != 0) {
+	 errno = EIO;
+	 return -1;
+      }
+   }
+
+   buf->st_mode = O_RDWR;
+   buf->st_uid = 0;
+   buf->st_gid = 0;
+   buf->st_size = dev->resplen;
+   buf->st_atime = buf->st_mtime = buf->st_ctime = time(NULL);
+
+   return 0;
+}
+
+
+#endif
-- 
1.7.9.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 27 17:12:09 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Sep 2012 17:12:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1THHd1-0006MR-Ju; Thu, 27 Sep 2012 17:11:59 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <matthew.fioravante@jhuapl.edu>) id 1THHcz-0006L3-C7
	for xen-devel@lists.xen.org; Thu, 27 Sep 2012 17:11:58 +0000
Received: from [85.158.139.83:6566] by server-4.bemta-5.messagelabs.com id
	25/E6-20767-CD884605; Thu, 27 Sep 2012 17:11:56 +0000
X-Env-Sender: matthew.fioravante@jhuapl.edu
X-Msg-Ref: server-4.tower-182.messagelabs.com!1348765910!27902458!1
X-Originating-IP: [128.244.251.36]
X-SpamReason: No, hits=0.0 required=7.0 tests=UNPARSEABLE_RELAY
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12757 invoked from network); 27 Sep 2012 17:11:51 -0000
Received: from pilot.jhuapl.edu (HELO jhuapl.edu) (128.244.251.36)
	by server-4.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 27 Sep 2012 17:11:51 -0000
Received: from ([128.244.207.89])
	by pilot.jhuapl.edu with ESMTP with TLS id 63GHCH1.153802930;
	Thu, 27 Sep 2012 13:11:28 -0400
From: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
To: xen-devel@lists.xen.org, samuel.thibault@ens-lyon.org,
	Ian.Campbell@citrix.com
Date: Thu, 27 Sep 2012 13:10:02 -0400
Message-Id: <1348765802-11314-8-git-send-email-matthew.fioravante@jhuapl.edu>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <1348765802-11314-1-git-send-email-matthew.fioravante@jhuapl.edu>
References: <1348765802-11314-1-git-send-email-matthew.fioravante@jhuapl.edu>
Cc: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
Subject: [Xen-devel] [PATCH 08/11] add tpmfront, tpm_tis,
	and tpmback drivers to mini-os
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This patch adds 3 new drivers to mini-os.

tpmfront - paravirtualized tpm frontend driver
tpmback - paravirtualized tpm backend driver
tpm_tis - hardware tpm driver

Unfortunately these drivers were derived from GPL
licensed linux kernel drivers so they must carry
the GPL license. However, since mini-os now
supports conditional compilation, hopefully these
drivers can be included into the xen tree and
conditionally removed from non-gpl projects.
By default they are disabled in the makefile.

Signed-off-by: Matthew Fioravante <matthew.fioravante@jhuapl.edu>

diff --git a/extras/mini-os/Makefile b/extras/mini-os/Makefile
index b4236e8..02fab14 100644
--- a/extras/mini-os/Makefile
+++ b/extras/mini-os/Makefile
@@ -22,6 +22,9 @@ CONFIG_QEMU_XS_ARGS ?= n
 CONFIG_TEST ?= n
 CONFIG_PCIFRONT ?= n
 CONFIG_BLKFRONT ?= y
+CONFIG_TPMFRONT ?= n
+CONFIG_TPM_TIS ?= n
+CONFIG_TPMBACK ?= n
 CONFIG_NETFRONT ?= y
 CONFIG_FBFRONT ?= y
 CONFIG_KBDFRONT ?= y
@@ -36,6 +39,9 @@ flags-$(CONFIG_SPARSE_BSS) += -DCONFIG_SPARSE_BSS
 flags-$(CONFIG_QEMU_XS_ARGS) += -DCONFIG_QEMU_XS_ARGS
 flags-$(CONFIG_PCIFRONT) += -DCONFIG_PCIFRONT
 flags-$(CONFIG_BLKFRONT) += -DCONFIG_BLKFRONT
+flags-$(CONFIG_TPMFRONT) += -DCONFIG_TPMFRONT
+flags-$(CONFIG_TPM_TIS) += -DCONFIG_TPM_TIS
+flags-$(CONFIG_TPMBACK) += -DCONFIG_TPMBACK
 flags-$(CONFIG_NETFRONT) += -DCONFIG_NETFRONT
 flags-$(CONFIG_KBDFRONT) += -DCONFIG_KBDFRONT
 flags-$(CONFIG_FBFRONT) += -DCONFIG_FBFRONT
@@ -67,6 +73,9 @@ TARGET := mini-os
 SUBDIRS := lib xenbus console
 
 src-$(CONFIG_BLKFRONT) += blkfront.c
+src-$(CONFIG_TPMFRONT) += tpmfront.c
+src-$(CONFIG_TPM_TIS) += tpm_tis.c
+src-$(CONFIG_TPMBACK) += tpmback.c
 src-y += daytime.c
 src-y += events.c
 src-$(CONFIG_FBFRONT) += fbfront.c
diff --git a/extras/mini-os/include/lib.h b/extras/mini-os/include/lib.h
index d4641b6..935bede 100644
--- a/extras/mini-os/include/lib.h
+++ b/extras/mini-os/include/lib.h
@@ -142,6 +142,8 @@ enum fd_type {
     FTYPE_FB,
     FTYPE_MEM,
     FTYPE_SAVEFILE,
+    FTYPE_TPMFRONT,
+    FTYPE_TPM_TIS,
 };
 
 LIST_HEAD(evtchn_port_list, evtchn_port_info);
@@ -185,6 +187,20 @@ extern struct file {
 	struct {
 	    struct consfront_dev *dev;
 	} cons;
+#ifdef CONFIG_TPMFRONT
+	struct {
+	   struct tpmfront_dev *dev;
+	   int respgot;
+	   off_t offset;
+	} tpmfront;
+#endif
+#ifdef CONFIG_TPM_TIS
+	struct {
+	   struct tpm_chip *dev;
+	   int respgot;
+	   off_t offset;
+	} tpm_tis;
+#endif
 #ifdef CONFIG_XENBUS
         struct {
             /* To each xenbus FD is associated a queue of watch events for this
diff --git a/extras/mini-os/include/tpm_tis.h b/extras/mini-os/include/tpm_tis.h
new file mode 100644
index 0000000..b463cea
--- /dev/null
+++ b/extras/mini-os/include/tpm_tis.h
@@ -0,0 +1,74 @@
+/*
+ * Copyright (c) 2010-2012 United States Government, as represented by
+ * the Secretary of Defense.  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 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.
+ *
+ * Based upon the files:
+ *  drivers/char/tpm/tpm_tis.c
+ *  drivers/char/tpm/tpm.c
+ * from the Linux kernel, which are Copyright (C) 2006 IBM Corporation
+ */
+#ifndef TPM_TIS_H
+#define TPM_TIS_H
+
+#include <mini-os/types.h>
+#include <mini-os/byteorder.h>
+
+#define TPM_TIS_EN_LOCL0 1
+#define TPM_TIS_EN_LOCL1 (1 << 1)
+#define TPM_TIS_EN_LOCL2 (1 << 2)
+#define TPM_TIS_EN_LOCL3 (1 << 3)
+#define TPM_TIS_EN_LOCL4 (1 << 4)
+#define TPM_TIS_EN_LOCLALL (TPM_TIS_EN_LOCL0 | TPM_TIS_EN_LOCL1  | TPM_TIS_EN_LOCL2 | TPM_TIS_EN_LOCL3 | TPM_TIS_EN_LOCL4)
+#define TPM_TIS_LOCL_INT_TO_FLAG(x) (1 << x)
+#define TPM_BASEADDR 0xFED40000
+#define TPM_PROBE_IRQ 0xFFFF
+
+struct tpm_chip;
+
+struct tpm_chip* init_tpm_tis(unsigned long baseaddr, int localities, unsigned int irq);
+void shutdown_tpm_tis(struct tpm_chip* tpm);
+
+int tpm_tis_request_locality(struct tpm_chip* tpm, int locality);
+int tpm_tis_cmd(struct tpm_chip* tpm, uint8_t* req, size_t reqlen, uint8_t** resp, size_t* resplen);
+
+#ifdef HAVE_LIBC
+#include <sys/stat.h>
+#include <fcntl.h>
+/* POSIX IO functions:
+ * use tpm_tis_open() to get a file descriptor to the tpm device
+ * use write() on the fd to send a command to the backend. You must
+ * include the entire command in a single call to write().
+ * use read() on the fd to read the response. You can use
+ * fstat() to get the size of the response and lseek() to seek on it.
+ */
+int tpm_tis_open(struct tpm_chip* tpm);
+int tpm_tis_posix_read(int fd, uint8_t* buf, size_t count);
+int tpm_tis_posix_write(int fd, const uint8_t* buf, size_t count);
+int tpm_tis_posix_fstat(int fd, struct stat* buf);
+#endif
+
+#endif
diff --git a/extras/mini-os/include/tpmback.h b/extras/mini-os/include/tpmback.h
new file mode 100644
index 0000000..bc41d2c
--- /dev/null
+++ b/extras/mini-os/include/tpmback.h
@@ -0,0 +1,106 @@
+/*
+ * Copyright (c) 2010-2012 United States Government, as represented by
+ * the Secretary of Defense.  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 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.
+ *
+ * Based upon the files:
+ *  drivers/xen/tpmbk.c
+ * from the Linux kernel, which are Copyright (C) 2006 IBM Corporation
+ */
+#include <xen/io/tpmif.h>
+#include <xen/io/xenbus.h>
+#include <mini-os/types.h>
+#include <xen/xen.h>
+#ifndef TPMBACK_H
+#define TPMBACK_H
+
+struct tpmcmd {
+   domid_t domid;		/* Domid of the frontend */
+   unsigned int handle;	/* Handle of the frontend */
+   char* uuid;			/* uuid of the tpm interface - allocated internally, dont free it */
+
+   unsigned int req_len;		/* Size of the command in buf - set by tpmback driver */
+   uint8_t* req;			/* tpm command bits, allocated by driver, DON'T FREE IT */
+   unsigned int resp_len;	/* Size of the outgoing command,
+				   you set this before passing the cmd object to tpmback_resp */
+   uint8_t* resp;		/* Buffer for response - YOU MUST ALLOCATE IT, YOU MUST ALSO FREE IT */
+};
+typedef struct tpmcmd tpmcmd_t;
+
+/* Initialize the tpm backend driver
+ * @exclusive_domname - This is NULL terminated list of vtpm uuid strings. If this list
+ * 			is non-empty, then only frontend domains with vtpm uuid's matching
+ * 			entries in this list will be allowed to connect.
+ * 			Other connections will be immediatly closed.
+ * 			Set this argument to NULL to allow any vtpm to connect.
+ */
+void init_tpmback(char** exclusive_uuids);
+/* Shutdown tpm backend driver */
+void shutdown_tpmback(void);
+
+/* Blocks until a tpm command is sent from any front end.
+ * Returns a pointer to the tpm command to handle.
+ * Do not try to free this pointer or the req buffer
+ * This function will return NULL if the tpm backend driver
+ * is shutdown or any other error occurs */
+tpmcmd_t* tpmback_req_any(void);
+
+/* Blocks until a tpm command from the frontend at domid/handle
+ * is sent.
+ * Returns NULL if domid/handle is not connected, tpmback is
+ * shutdown or shutting down, or if there is an error
+ */
+tpmcmd_t* tpmback_req(domid_t domid, unsigned int handle);
+
+/* Send the response to the tpm command back to the frontend
+ * This function will free the tpmcmd object, but you must free the resp
+ * buffer yourself */
+void tpmback_resp(tpmcmd_t* tpmcmd);
+
+/* Waits for the first frontend to connect and then sets domid and handle appropriately.
+ * If one or more frontends are already connected, this will set domid and handle to one
+ * of them arbitrarily. The main use for this function is to wait until a single
+ * frontend connection has occured.
+ * returns 0 on success, non-zero on failure */
+int tpmback_wait_for_frontend_connect(domid_t *domid, unsigned int *handle);
+
+/* returns the number of frontends connected */
+int tpmback_num_frontends(void);
+
+/* Returns the uuid of the specified frontend, NULL on error */
+char* tpmback_get_uuid(domid_t domid, unsigned int handle);
+
+/* Specify a function to call when a new tpm device connects */
+void tpmback_set_open_callback(void (*cb)(domid_t, unsigned int));
+
+/* Specify a function to call when a tpm device disconnects */
+void tpmback_set_close_callback(void (*cb)(domid_t, unsigned int));
+
+//Not Implemented
+void tpmback_set_suspend_callback(void (*cb)(domid_t, unsigned int));
+void tpmback_set_resume_callback(void (*cb)(domid_t, unsigned int));
+
+#endif
diff --git a/extras/mini-os/include/tpmfront.h b/extras/mini-os/include/tpmfront.h
new file mode 100644
index 0000000..eccaacc
--- /dev/null
+++ b/extras/mini-os/include/tpmfront.h
@@ -0,0 +1,105 @@
+/*
+ * Copyright (c) 2010-2012 United States Government, as represented by
+ * the Secretary of Defense.  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 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.
+ *
+ * Based upon the files:
+ *  drivers/char/tpm/tpm_vtpm.c
+ *  drivers/char/tpm/tpm_xen.c
+ * from the Linux kernel, which are Copyright (C) 2006 IBM Corporation
+ */
+#ifndef TPMFRONT_H
+#define TPMFRONT_H
+
+#include <mini-os/types.h>
+#include <mini-os/os.h>
+#include <mini-os/events.h>
+#include <mini-os/wait.h>
+#include <xen/xen.h>
+#include <xen/io/xenbus.h>
+#include <xen/io/tpmif.h>
+
+struct tpmfront_dev {
+   grant_ref_t ring_ref;
+   evtchn_port_t evtchn;
+
+   tpmif_tx_interface_t* tx;
+
+   void** pages;
+
+   domid_t bedomid;
+   char* nodename;
+   char* bepath;
+
+   XenbusState state;
+
+   uint8_t waiting;
+   struct wait_queue_head waitq;
+
+   uint8_t* respbuf;
+   size_t resplen;
+
+#ifdef HAVE_LIBC
+   int fd;
+#endif
+
+};
+
+
+/*Initialize frontend */
+struct tpmfront_dev* init_tpmfront(const char* nodename);
+/*Shutdown frontend */
+void shutdown_tpmfront(struct tpmfront_dev* dev);
+
+/* Send a tpm command to the backend and wait for the response
+ *
+ * @dev - frontend device
+ * @req - request buffer
+ * @reqlen - length of request buffer
+ * @resp - *resp will be set to internal response buffer, don't free it! Value is undefined on error
+ * @resplen - *resplen will be set to the length of the response. Value is undefined on error
+ *
+ * returns 0 on success, non zero on failure.
+ * */
+int tpmfront_cmd(struct tpmfront_dev* dev, uint8_t* req, size_t reqlen, uint8_t** resp, size_t* resplen);
+
+#ifdef HAVE_LIBC
+#include <sys/stat.h>
+/* POSIX IO functions:
+ * use tpmfront_open() to get a file descriptor to the tpm device
+ * use write() on the fd to send a command to the backend. You must
+ * include the entire command in a single call to write().
+ * use read() on the fd to read the response. You can use
+ * fstat() to get the size of the response and lseek() to seek on it.
+ */
+int tpmfront_open(struct tpmfront_dev* dev);
+int tpmfront_posix_read(int fd, uint8_t* buf, size_t count);
+int tpmfront_posix_write(int fd, const uint8_t* buf, size_t count);
+int tpmfront_posix_fstat(int fd, struct stat* buf);
+#endif
+
+
+#endif
diff --git a/extras/mini-os/lib/sys.c b/extras/mini-os/lib/sys.c
index 6cb97b1..d212969 100644
--- a/extras/mini-os/lib/sys.c
+++ b/extras/mini-os/lib/sys.c
@@ -27,6 +27,8 @@
 #include <netfront.h>
 #include <blkfront.h>
 #include <fbfront.h>
+#include <tpmfront.h>
+#include <tpm_tis.h>
 #include <xenbus.h>
 #include <xenstore.h>
 
@@ -294,6 +296,16 @@ int read(int fd, void *buf, size_t nbytes)
 	    return blkfront_posix_read(fd, buf, nbytes);
         }
 #endif
+#ifdef CONFIG_TPMFRONT
+        case FTYPE_TPMFRONT: {
+	    return tpmfront_posix_read(fd, buf, nbytes);
+        }
+#endif
+#ifdef CONFIG_TPM_TIS
+        case FTYPE_TPM_TIS: {
+	    return tpm_tis_posix_read(fd, buf, nbytes);
+        }
+#endif
 	default:
 	    break;
     }
@@ -330,6 +342,14 @@ int write(int fd, const void *buf, size_t nbytes)
 	case FTYPE_BLK:
 	    return blkfront_posix_write(fd, buf, nbytes);
 #endif
+#ifdef CONFIG_TPMFRONT
+	case FTYPE_TPMFRONT:
+	    return tpmfront_posix_write(fd, buf, nbytes);
+#endif
+#ifdef CONFIG_TPM_TIS
+	case FTYPE_TPM_TIS:
+	    return tpm_tis_posix_write(fd, buf, nbytes);
+#endif
 	default:
 	    break;
     }
@@ -341,8 +361,16 @@ int write(int fd, const void *buf, size_t nbytes)
 off_t lseek(int fd, off_t offset, int whence)
 {
     switch(files[fd].type) {
+#if defined(CONFIG_BLKFRONT) || defined(CONFIG_TPMFRONT) || defined(CONFIG_TPM_TIS)
 #ifdef CONFIG_BLKFRONT
        case FTYPE_BLK:
+#endif
+#ifdef CONFIG_TPMFRNT
+       case FTYPE_TPMFRONT:
+#endif
+#ifdef CONFIG_TPM_TIS
+       case FTYPE_TPM_TIS:
+#endif
 	  switch (whence) {
 	     case SEEK_SET:
 		files[fd].file.offset = offset;
@@ -420,6 +448,18 @@ int close(int fd)
 	    files[fd].type = FTYPE_NONE;
 	    return 0;
 #endif
+#ifdef CONFIG_TPMFRONT
+	case FTYPE_TPMFRONT:
+            shutdown_tpmfront(files[fd].tpmfront.dev);
+	    files[fd].type = FTYPE_NONE;
+	    return 0;
+#endif
+#ifdef CONFIG_TPM_TIS
+	case FTYPE_TPM_TIS:
+            shutdown_tpm_tis(files[fd].tpm_tis.dev);
+	    files[fd].type = FTYPE_NONE;
+	    return 0;
+#endif
 #ifdef CONFIG_KBDFRONT
 	case FTYPE_KBD:
             shutdown_kbdfront(files[fd].kbd.dev);
@@ -489,6 +529,14 @@ int fstat(int fd, struct stat *buf)
 	case FTYPE_BLK:
 	   return blkfront_posix_fstat(fd, buf);
 #endif
+#ifdef CONFIG_TPMFRONT
+	case FTYPE_TPMFRONT:
+	   return tpmfront_posix_fstat(fd, buf);
+#endif
+#ifdef CONFIG_TPM_TIS
+	case FTYPE_TPM_TIS:
+	   return tpm_tis_posix_fstat(fd, buf);
+#endif
 	default:
 	    break;
     }
diff --git a/extras/mini-os/tpm_tis.c b/extras/mini-os/tpm_tis.c
new file mode 100644
index 0000000..2acb2dc
--- /dev/null
+++ b/extras/mini-os/tpm_tis.c
@@ -0,0 +1,1355 @@
+/*
+ * Copyright (c) 2010-2012 United States Government, as represented by
+ * the Secretary of Defense.  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 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.
+ *
+ * Based upon the files:
+ *  drivers/char/tpm/tpm_tis.c
+ *  drivers/char/tpm/tpm.c
+ * from the Linux kernel, which are Copyright (C) 2006 IBM Corporation
+ */
+#include <mini-os/ioremap.h>
+#include <mini-os/iorw.h>
+#include <mini-os/tpm_tis.h>
+#include <mini-os/os.h>
+#include <mini-os/sched.h>
+#include <mini-os/byteorder.h>
+#include <mini-os/events.h>
+#include <mini-os/wait.h>
+#include <mini-os/xmalloc.h>
+#include <errno.h>
+#include <stdbool.h>
+
+#ifndef min
+	#define min( a, b ) ( ((a) < (b)) ? (a) : (b) )
+#endif
+
+#define TPM_HEADER_SIZE 10
+
+#define TPM_BUFSIZE 2048
+
+struct tpm_input_header {
+        uint16_t  tag;
+        uint32_t  length;
+        uint32_t  ordinal;
+}__attribute__((packed));
+
+struct tpm_output_header {
+        uint16_t  tag;
+        uint32_t  length;
+        uint32_t  return_code;
+}__attribute__((packed));
+
+struct  stclear_flags_t {
+        uint16_t  tag;
+        uint8_t      deactivated;
+        uint8_t      disableForceClear;
+        uint8_t      physicalPresence;
+        uint8_t      physicalPresenceLock;
+        uint8_t      bGlobalLock;
+}__attribute__((packed));
+
+struct  tpm_version_t {
+        uint8_t      Major;
+        uint8_t      Minor;
+        uint8_t      revMajor;
+        uint8_t      revMinor;
+}__attribute__((packed));
+
+struct  tpm_version_1_2_t {
+        uint16_t  tag;
+        uint8_t      Major;
+        uint8_t      Minor;
+        uint8_t      revMajor;
+        uint8_t      revMinor;
+}__attribute__((packed));
+
+struct  timeout_t {
+        uint32_t  a;
+        uint32_t  b;
+        uint32_t  c;
+        uint32_t  d;
+}__attribute__((packed));
+
+struct duration_t {
+        uint32_t  tpm_short;
+        uint32_t  tpm_medium;
+        uint32_t  tpm_long;
+}__attribute__((packed));
+
+struct permanent_flags_t {
+        uint16_t  tag;
+        uint8_t      disable;
+        uint8_t      ownership;
+        uint8_t      deactivated;
+        uint8_t      readPubek;
+        uint8_t      disableOwnerClear;
+        uint8_t      allowMaintenance;
+        uint8_t      physicalPresenceLifetimeLock;
+        uint8_t      physicalPresenceHWEnable;
+        uint8_t      physicalPresenceCMDEnable;
+        uint8_t      CEKPUsed;
+        uint8_t      TPMpost;
+        uint8_t      TPMpostLock;
+        uint8_t      FIPS;
+        uint8_t      operator;
+        uint8_t      enableRevokeEK;
+        uint8_t      nvLocked;
+        uint8_t      readSRKPub;
+        uint8_t      tpmEstablished;
+        uint8_t      maintenanceDone;
+        uint8_t      disableFullDALogicInfo;
+}__attribute__((packed));
+
+typedef union {
+        struct  permanent_flags_t perm_flags;
+        struct  stclear_flags_t stclear_flags;
+        bool    owned;
+        uint32_t  num_pcrs;
+        struct  tpm_version_t   tpm_version;
+        struct  tpm_version_1_2_t tpm_version_1_2;
+        uint32_t  manufacturer_id;
+        struct timeout_t  timeout;
+        struct duration_t duration;
+} cap_t;
+
+struct  tpm_getcap_params_in {
+        uint32_t  cap;
+        uint32_t  subcap_size;
+        uint32_t  subcap;
+}__attribute__((packed));
+
+struct  tpm_getcap_params_out {
+        uint32_t  cap_size;
+        cap_t   cap;
+}__attribute__((packed));
+
+struct  tpm_readpubek_params_out {
+        uint8_t      algorithm[4];
+        uint8_t      encscheme[2];
+        uint8_t      sigscheme[2];
+        uint32_t  paramsize;
+        uint8_t      parameters[12]; /*assuming RSA*/
+        uint32_t  keysize;
+        uint8_t      modulus[256];
+        uint8_t      checksum[20];
+}__attribute__((packed));
+
+typedef union {
+        struct  tpm_input_header in;
+        struct  tpm_output_header out;
+} tpm_cmd_header;
+
+#define TPM_DIGEST_SIZE 20
+struct tpm_pcrread_out {
+        uint8_t      pcr_result[TPM_DIGEST_SIZE];
+}__attribute__((packed));
+
+struct tpm_pcrread_in {
+        uint32_t  pcr_idx;
+}__attribute__((packed));
+
+struct tpm_pcrextend_in {
+        uint32_t  pcr_idx;
+        uint8_t      hash[TPM_DIGEST_SIZE];
+}__attribute__((packed));
+
+typedef union {
+        struct  tpm_getcap_params_out getcap_out;
+        struct  tpm_readpubek_params_out readpubek_out;
+        uint8_t      readpubek_out_buffer[sizeof(struct tpm_readpubek_params_out)];
+        struct  tpm_getcap_params_in getcap_in;
+        struct  tpm_pcrread_in  pcrread_in;
+        struct  tpm_pcrread_out pcrread_out;
+        struct  tpm_pcrextend_in pcrextend_in;
+} tpm_cmd_params;
+
+struct tpm_cmd_t {
+        tpm_cmd_header  header;
+        tpm_cmd_params  params;
+}__attribute__((packed));
+
+
+enum tpm_duration {
+   TPM_SHORT = 0,
+   TPM_MEDIUM = 1,
+   TPM_LONG = 2,
+   TPM_UNDEFINED,
+};
+
+#define TPM_MAX_ORDINAL 243
+#define TPM_MAX_PROTECTED_ORDINAL 12
+#define TPM_PROTECTED_ORDINAL_MASK 0xFF
+
+extern const uint8_t tpm_protected_ordinal_duration[TPM_MAX_PROTECTED_ORDINAL];
+extern const uint8_t tpm_ordinal_duration[TPM_MAX_ORDINAL];
+
+#define TPM_DIGEST_SIZE 20
+#define TPM_ERROR_SIZE 10
+#define TPM_RET_CODE_IDX 6
+
+/* tpm_capabilities */
+#define TPM_CAP_FLAG cpu_to_be32(4)
+#define TPM_CAP_PROP cpu_to_be32(5)
+#define CAP_VERSION_1_1 cpu_to_be32(0x06)
+#define CAP_VERSION_1_2 cpu_to_be32(0x1A)
+
+/* tpm_sub_capabilities */
+#define TPM_CAP_PROP_PCR cpu_to_be32(0x101)
+#define TPM_CAP_PROP_MANUFACTURER cpu_to_be32(0x103)
+#define TPM_CAP_FLAG_PERM cpu_to_be32(0x108)
+#define TPM_CAP_FLAG_VOL cpu_to_be32(0x109)
+#define TPM_CAP_PROP_OWNER cpu_to_be32(0x111)
+#define TPM_CAP_PROP_TIS_TIMEOUT cpu_to_be32(0x115)
+#define TPM_CAP_PROP_TIS_DURATION cpu_to_be32(0x120)
+
+
+#define TPM_INTERNAL_RESULT_SIZE 200
+#define TPM_TAG_RQU_COMMAND cpu_to_be16(193)
+#define TPM_ORD_GET_CAP cpu_to_be32(101)
+
+extern const struct tpm_input_header tpm_getcap_header;
+
+
+
+const uint8_t tpm_protected_ordinal_duration[TPM_MAX_PROTECTED_ORDINAL] = {
+   TPM_UNDEFINED,          /* 0 */
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,          /* 5 */
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_SHORT,              /* 10 */
+   TPM_SHORT,
+};
+
+const uint8_t tpm_ordinal_duration[TPM_MAX_ORDINAL] = {
+   TPM_UNDEFINED,          /* 0 */
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,          /* 5 */
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_SHORT,              /* 10 */
+   TPM_SHORT,
+   TPM_MEDIUM,
+   TPM_LONG,
+   TPM_LONG,
+   TPM_MEDIUM,             /* 15 */
+   TPM_SHORT,
+   TPM_SHORT,
+   TPM_MEDIUM,
+   TPM_LONG,
+   TPM_SHORT,              /* 20 */
+   TPM_SHORT,
+   TPM_MEDIUM,
+   TPM_MEDIUM,
+   TPM_MEDIUM,
+   TPM_SHORT,              /* 25 */
+   TPM_SHORT,
+   TPM_MEDIUM,
+   TPM_SHORT,
+   TPM_SHORT,
+   TPM_MEDIUM,             /* 30 */
+   TPM_LONG,
+   TPM_MEDIUM,
+   TPM_SHORT,
+   TPM_SHORT,
+   TPM_SHORT,              /* 35 */
+   TPM_MEDIUM,
+   TPM_MEDIUM,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_MEDIUM,             /* 40 */
+   TPM_LONG,
+   TPM_MEDIUM,
+   TPM_SHORT,
+   TPM_SHORT,
+   TPM_SHORT,              /* 45 */
+   TPM_SHORT,
+   TPM_SHORT,
+   TPM_SHORT,
+   TPM_LONG,
+   TPM_MEDIUM,             /* 50 */
+   TPM_MEDIUM,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,          /* 55 */
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_MEDIUM,             /* 60 */
+   TPM_MEDIUM,
+   TPM_MEDIUM,
+   TPM_SHORT,
+   TPM_SHORT,
+   TPM_MEDIUM,             /* 65 */
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_SHORT,              /* 70 */
+   TPM_SHORT,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,          /* 75 */
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_LONG,               /* 80 */
+   TPM_UNDEFINED,
+   TPM_MEDIUM,
+   TPM_LONG,
+   TPM_SHORT,
+   TPM_UNDEFINED,          /* 85 */
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_SHORT,              /* 90 */
+   TPM_SHORT,
+   TPM_SHORT,
+   TPM_SHORT,
+   TPM_SHORT,
+   TPM_UNDEFINED,          /* 95 */
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_MEDIUM,             /* 100 */
+   TPM_SHORT,
+   TPM_SHORT,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,          /* 105 */
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_SHORT,              /* 110 */
+   TPM_SHORT,
+   TPM_SHORT,
+   TPM_SHORT,
+   TPM_SHORT,
+   TPM_SHORT,              /* 115 */
+   TPM_SHORT,
+   TPM_SHORT,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_LONG,               /* 120 */
+   TPM_LONG,
+   TPM_MEDIUM,
+   TPM_UNDEFINED,
+   TPM_SHORT,
+   TPM_SHORT,              /* 125 */
+   TPM_SHORT,
+   TPM_LONG,
+   TPM_SHORT,
+   TPM_SHORT,
+   TPM_SHORT,              /* 130 */
+   TPM_MEDIUM,
+   TPM_UNDEFINED,
+   TPM_SHORT,
+   TPM_MEDIUM,
+   TPM_UNDEFINED,          /* 135 */
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_SHORT,              /* 140 */
+   TPM_SHORT,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,          /* 145 */
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_SHORT,              /* 150 */
+   TPM_MEDIUM,
+   TPM_MEDIUM,
+   TPM_SHORT,
+   TPM_SHORT,
+   TPM_UNDEFINED,          /* 155 */
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_SHORT,              /* 160 */
+   TPM_SHORT,
+   TPM_SHORT,
+   TPM_SHORT,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,          /* 165 */
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_LONG,               /* 170 */
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,          /* 175 */
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_MEDIUM,             /* 180 */
+   TPM_SHORT,
+   TPM_MEDIUM,
+   TPM_MEDIUM,
+   TPM_MEDIUM,
+   TPM_MEDIUM,             /* 185 */
+   TPM_SHORT,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,          /* 190 */
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,          /* 195 */
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_SHORT,              /* 200 */
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_SHORT,
+   TPM_SHORT,              /* 205 */
+   TPM_SHORT,
+   TPM_SHORT,
+   TPM_SHORT,
+   TPM_SHORT,
+   TPM_MEDIUM,             /* 210 */
+   TPM_UNDEFINED,
+   TPM_MEDIUM,
+   TPM_MEDIUM,
+   TPM_MEDIUM,
+   TPM_UNDEFINED,          /* 215 */
+   TPM_MEDIUM,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_SHORT,
+   TPM_SHORT,              /* 220 */
+   TPM_SHORT,
+   TPM_SHORT,
+   TPM_SHORT,
+   TPM_SHORT,
+   TPM_UNDEFINED,          /* 225 */
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_SHORT,              /* 230 */
+   TPM_LONG,
+   TPM_MEDIUM,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,          /* 235 */
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_UNDEFINED,
+   TPM_SHORT,              /* 240 */
+   TPM_UNDEFINED,
+   TPM_MEDIUM,
+};
+
+const struct tpm_input_header tpm_getcap_header = {
+        .tag = TPM_TAG_RQU_COMMAND,
+        .length = cpu_to_be32(22),
+        .ordinal = TPM_ORD_GET_CAP
+};
+
+
+enum tis_access {
+   TPM_ACCESS_VALID = 0x80,
+   TPM_ACCESS_ACTIVE_LOCALITY = 0x20,	/* (R) */
+   TPM_ACCESS_RELINQUISH_LOCALITY = 0x20,/* (W) */
+   TPM_ACCESS_REQUEST_PENDING = 0x04,	/* (W) */
+   TPM_ACCESS_REQUEST_USE = 0x02,	/* (W) */
+};
+
+enum tis_status {
+   TPM_STS_VALID = 0x80,		/* (R) */
+   TPM_STS_COMMAND_READY = 0x40,	/* (R) */
+   TPM_STS_DATA_AVAIL = 0x10,		/* (R) */
+   TPM_STS_DATA_EXPECT = 0x08,		/* (R) */
+   TPM_STS_GO = 0x20,			/* (W) */
+};
+
+enum tis_int_flags {
+   TPM_GLOBAL_INT_ENABLE = 0x80000000,
+   TPM_INTF_BURST_COUNT_STATIC = 0x100,
+   TPM_INTF_CMD_READY_INT = 0x080,
+   TPM_INTF_INT_EDGE_FALLING = 0x040,
+   TPM_INTF_INT_EDGE_RISING = 0x020,
+   TPM_INTF_INT_LEVEL_LOW = 0x010,
+   TPM_INTF_INT_LEVEL_HIGH = 0x008,
+   TPM_INTF_LOCALITY_CHANGE_INT = 0x004,
+   TPM_INTF_STS_VALID_INT = 0x002,
+   TPM_INTF_DATA_AVAIL_INT = 0x001,
+};
+
+enum tis_defaults {
+   TIS_MEM_BASE = 0xFED40000,
+   TIS_MEM_LEN  = 0x5000,
+   TIS_SHORT_TIMEOUT = 750, /*ms*/
+   TIS_LONG_TIMEOUT = 2000, /*2 sec */
+};
+
+#define TPM_TIMEOUT 5
+
+#define TPM_ACCESS(t, l)                   (((uint8_t*)t->pages[l]) + 0x0000)
+#define TPM_INT_ENABLE(t, l)               ((uint32_t*)(((uint8_t*)t->pages[l]) + 0x0008))
+#define TPM_INT_VECTOR(t, l)               (((uint8_t*)t->pages[l]) + 0x000C)
+#define TPM_INT_STATUS(t, l)               (((uint8_t*)t->pages[l]) + 0x0010)
+#define TPM_INTF_CAPS(t, l)                ((uint32_t*)(((uint8_t*)t->pages[l]) + 0x0014))
+#define TPM_STS(t, l)                      ((uint8_t*)(((uint8_t*)t->pages[l]) + 0x0018))
+#define TPM_DATA_FIFO(t, l)                (((uint8_t*)t->pages[l]) + 0x0024)
+
+#define TPM_DID_VID(t, l)                  ((uint32_t*)(((uint8_t*)t->pages[l]) + 0x0F00))
+#define TPM_RID(t, l)                      (((uint8_t*)t->pages[l]) + 0x0F04)
+
+struct tpm_chip {
+   int enabled_localities;
+   int locality;
+   unsigned long baseaddr;
+   uint8_t* pages[5];
+   int did, vid, rid;
+
+   uint8_t data_buffer[TPM_BUFSIZE];
+   int data_len;
+
+   s_time_t timeout_a, timeout_b, timeout_c, timeout_d;
+   s_time_t duration[3];
+
+#ifdef HAVE_LIBC
+   int fd;
+#endif
+
+   unsigned int irq;
+   struct wait_queue_head read_queue;
+   struct wait_queue_head int_queue;
+};
+
+
+static void __init_tpm_chip(struct tpm_chip* tpm) {
+   tpm->enabled_localities = TPM_TIS_EN_LOCLALL;
+   tpm->locality = -1;
+   tpm->baseaddr = 0;
+   tpm->pages[0] = tpm->pages[1] = tpm->pages[2] = tpm->pages[3] = tpm->pages[4] = NULL;
+   tpm->vid = 0;
+   tpm->did = 0;
+   tpm->irq = 0;
+   init_waitqueue_head(&tpm->read_queue);
+   init_waitqueue_head(&tpm->int_queue);
+
+   tpm->data_len = -1;
+
+#ifdef HAVE_LIBC
+   tpm->fd = -1;
+#endif
+}
+
+/*
+ * Returns max number of nsecs to wait
+ */
+s_time_t tpm_calc_ordinal_duration(struct tpm_chip *chip,
+      uint32_t ordinal)
+{
+   int duration_idx = TPM_UNDEFINED;
+   s_time_t duration = 0;
+
+   if (ordinal < TPM_MAX_ORDINAL)
+      duration_idx = tpm_ordinal_duration[ordinal];
+   else if ((ordinal & TPM_PROTECTED_ORDINAL_MASK) <
+	 TPM_MAX_PROTECTED_ORDINAL)
+      duration_idx =
+	 tpm_protected_ordinal_duration[ordinal &
+	 TPM_PROTECTED_ORDINAL_MASK];
+
+   if (duration_idx != TPM_UNDEFINED) {
+      duration = chip->duration[duration_idx];
+   }
+
+   if (duration <= 0) {
+      return SECONDS(120);
+   }
+   else
+   {
+      return duration;
+   }
+}
+
+
+static int locality_enabled(struct tpm_chip* tpm, int l) {
+   return tpm->enabled_localities & (1 << l);
+}
+
+static int check_locality(struct tpm_chip* tpm, int l) {
+   if(locality_enabled(tpm, l) && (ioread8(TPM_ACCESS(tpm, l)) &
+	    (TPM_ACCESS_ACTIVE_LOCALITY | TPM_ACCESS_VALID)) ==
+	 (TPM_ACCESS_ACTIVE_LOCALITY | TPM_ACCESS_VALID)) {
+      return l;
+   }
+   return -1;
+}
+
+void release_locality(struct tpm_chip* tpm, int l, int force)
+{
+   if (locality_enabled(tpm, l) && (force || (ioread8(TPM_ACCESS(tpm, l)) &
+	       (TPM_ACCESS_REQUEST_PENDING | TPM_ACCESS_VALID)) ==
+	    (TPM_ACCESS_REQUEST_PENDING | TPM_ACCESS_VALID))) {
+      iowrite8(TPM_ACCESS(tpm, l), TPM_ACCESS_RELINQUISH_LOCALITY);
+   }
+}
+
+int tpm_tis_request_locality(struct tpm_chip* tpm, int l) {
+
+   s_time_t stop;
+   /*Make sure locality is valid */
+   if(!locality_enabled(tpm, l)) {
+      printk("tpm_tis_change_locality() Tried to change to locality %d, but it is disabled or invalid!\n", l);
+      return -1;
+   }
+   /* Check if we already have the current locality */
+   if(check_locality(tpm, l) >= 0) {
+      return tpm->locality = l;
+   }
+   /* Set the new locality*/
+   iowrite8(TPM_ACCESS(tpm, l), TPM_ACCESS_REQUEST_USE);
+
+   if(tpm->irq) {
+      /* Wait for interrupt */
+      wait_event_deadline(tpm->int_queue, (check_locality(tpm, l) >= 0), NOW() + tpm->timeout_a);
+
+      /* FIXME: Handle timeout event, should return error in that case */
+      return l;
+   } else {
+      /* Wait for burstcount */
+      stop = NOW() + tpm->timeout_a;
+      do {
+	 if(check_locality(tpm, l) >= 0) {
+	    return tpm->locality = l;
+	 }
+	 msleep(TPM_TIMEOUT);
+      } while(NOW() < stop);
+   }
+
+   printk("REQ LOCALITY FAILURE\n");
+   return -1;
+}
+
+static uint8_t tpm_tis_status(struct tpm_chip* tpm) {
+   return ioread8(TPM_STS(tpm, tpm->locality));
+}
+
+/* This causes the current command to be aborted */
+static void tpm_tis_ready(struct tpm_chip* tpm) {
+   iowrite8(TPM_STS(tpm, tpm->locality), TPM_STS_COMMAND_READY);
+}
+#define tpm_tis_cancel_cmd(v) tpm_tis_ready(v)
+
+static int get_burstcount(struct tpm_chip* tpm) {
+   s_time_t stop;
+   int burstcnt;
+
+   stop = NOW() + tpm->timeout_d;
+   do {
+      burstcnt = ioread8((TPM_STS(tpm, tpm->locality) + 1));
+      burstcnt += ioread8(TPM_STS(tpm, tpm->locality) + 2) << 8;
+
+      if (burstcnt) {
+	 return burstcnt;
+      }
+      msleep(TPM_TIMEOUT);
+   } while(NOW() < stop);
+   return -EBUSY;
+}
+
+static int wait_for_stat(struct tpm_chip* tpm, uint8_t mask,
+      unsigned long timeout, struct wait_queue_head* queue) {
+   s_time_t stop;
+   uint8_t status;
+
+   status = tpm_tis_status(tpm);
+   if((status & mask) == mask) {
+      return 0;
+   }
+
+   if(tpm->irq) {
+      wait_event_deadline(*queue, ((tpm_tis_status(tpm) & mask) == mask), timeout);
+      /* FIXME: Check for timeout and return -ETIME */
+      return 0;
+   } else {
+      stop = NOW() + timeout;
+      do {
+	 msleep(TPM_TIMEOUT);
+	 status = tpm_tis_status(tpm);
+	 if((status & mask) == mask)
+	    return 0;
+      } while( NOW() < stop);
+   }
+   return -ETIME;
+}
+
+static int recv_data(struct tpm_chip* tpm, uint8_t* buf, size_t count) {
+   int size = 0;
+   int burstcnt;
+   while( size < count &&
+	 wait_for_stat(tpm,
+	    TPM_STS_DATA_AVAIL | TPM_STS_VALID,
+	    tpm->timeout_c,
+	    &tpm->read_queue)
+	 == 0) {
+      burstcnt = get_burstcount(tpm);
+      for(; burstcnt > 0 && size < count; --burstcnt)
+      {
+	 buf[size++] = ioread8(TPM_DATA_FIFO(tpm, tpm->locality));
+      }
+   }
+   return size;
+}
+
+int tpm_tis_recv(struct tpm_chip* tpm, uint8_t* buf, size_t count) {
+   int size = 0;
+   int expected, status;
+
+   if (count < TPM_HEADER_SIZE) {
+      size = -EIO;
+      goto out;
+   }
+
+   /* read first 10 bytes, including tag, paramsize, and result */
+   if((size =
+	    recv_data(tpm, buf, TPM_HEADER_SIZE)) < TPM_HEADER_SIZE) {
+      printk("Error reading tpm cmd header\n");
+      goto out;
+   }
+
+   expected = be32_to_cpu(*((uint32_t*)(buf + 2)));
+   if(expected > count) {
+      size = -EIO;
+      goto out;
+   }
+
+   if((size += recv_data(tpm, & buf[TPM_HEADER_SIZE],
+	       expected - TPM_HEADER_SIZE)) < expected) {
+      printk("Unable to read rest of tpm command size=%d expected=%d\n", size, expected);
+      size = -ETIME;
+      goto out;
+   }
+
+   wait_for_stat(tpm, TPM_STS_VALID, tpm->timeout_c, &tpm->int_queue);
+   status = tpm_tis_status(tpm);
+   if(status & TPM_STS_DATA_AVAIL) {
+      printk("Error: left over data\n");
+      size = -EIO;
+      goto out;
+   }
+
+out:
+   tpm_tis_ready(tpm);
+   release_locality(tpm, tpm->locality, 0);
+   return size;
+}
+int tpm_tis_send(struct tpm_chip* tpm, uint8_t* buf, size_t len) {
+   int rc;
+   int status, burstcnt = 0;
+   int count = 0;
+   uint32_t ordinal;
+
+   if(tpm_tis_request_locality(tpm, tpm->locality) < 0) {
+      return -EBUSY;
+   }
+
+   status = tpm_tis_status(tpm);
+   if((status & TPM_STS_COMMAND_READY) == 0) {
+      tpm_tis_ready(tpm);
+      if(wait_for_stat(tpm, TPM_STS_COMMAND_READY, tpm->timeout_b, &tpm->int_queue) < 0) {
+	 rc = -ETIME;
+	 goto out_err;
+      }
+   }
+
+   while(count < len - 1) {
+      burstcnt = get_burstcount(tpm);
+      for(;burstcnt > 0 && count < len -1; --burstcnt) {
+	 iowrite8(TPM_DATA_FIFO(tpm, tpm->locality), buf[count++]);
+      }
+
+      wait_for_stat(tpm, TPM_STS_VALID, tpm->timeout_c, &tpm->int_queue);
+      status = tpm_tis_status(tpm);
+      if((status & TPM_STS_DATA_EXPECT) == 0) {
+	 rc = -EIO;
+	 goto out_err;
+      }
+   }
+
+   /*Write last byte*/
+   iowrite8(TPM_DATA_FIFO(tpm, tpm->locality), buf[count]);
+   wait_for_stat(tpm, TPM_STS_VALID, tpm->timeout_c, &tpm->read_queue);
+   status = tpm_tis_status(tpm);
+   if((status & TPM_STS_DATA_EXPECT) != 0) {
+      rc = -EIO;
+      goto out_err;
+   }
+
+   /*go and do it*/
+   iowrite8(TPM_STS(tpm, tpm->locality), TPM_STS_GO);
+
+   if(tpm->irq) {
+      /*Wait for interrupt */
+      ordinal = be32_to_cpu(*(buf + 6));
+      if(wait_for_stat(tpm,
+	       TPM_STS_DATA_AVAIL | TPM_STS_VALID,
+	       tpm_calc_ordinal_duration(tpm, ordinal),
+	       &tpm->read_queue) < 0) {
+	 rc = -ETIME;
+	 goto out_err;
+      }
+   }
+#ifdef HAVE_LIBC
+   if(tpm->fd >= 0) {
+      files[tpm->fd].read = 0;
+      files[tpm->fd].tpm_tis.respgot = 0;
+      files[tpm->fd].tpm_tis.offset = 0;
+   }
+#endif
+   return len;
+
+out_err:
+   tpm_tis_ready(tpm);
+   release_locality(tpm, tpm->locality, 0);
+   return rc;
+}
+
+static void tpm_tis_irq_handler(evtchn_port_t port, struct pt_regs *regs, void* data)
+{
+   struct tpm_chip* tpm = data;
+   uint32_t interrupt;
+   int i;
+
+   interrupt = ioread32(TPM_INT_STATUS(tpm, tpm->locality));
+   if(interrupt == 0) {
+      return;
+   }
+
+   if(interrupt & TPM_INTF_DATA_AVAIL_INT) {
+      wake_up(&tpm->read_queue);
+   }
+   if(interrupt & TPM_INTF_LOCALITY_CHANGE_INT) {
+      for(i = 0; i < 5; ++i) {
+	 if(check_locality(tpm, i) >= 0) {
+	    break;
+	 }
+      }
+   }
+   if(interrupt & (TPM_INTF_LOCALITY_CHANGE_INT | TPM_INTF_STS_VALID_INT |
+	    TPM_INTF_CMD_READY_INT)) {
+      wake_up(&tpm->int_queue);
+   }
+
+   /* Clear interrupts handled with TPM_EOI */
+   iowrite32(TPM_INT_STATUS(tpm, tpm->locality), interrupt);
+   ioread32(TPM_INT_STATUS(tpm, tpm->locality));
+   return;
+}
+
+/*
+ * Internal kernel interface to transmit TPM commands
+ */
+static ssize_t tpm_transmit(struct tpm_chip *chip, const uint8_t *buf,
+      size_t bufsiz)
+{
+   ssize_t rc;
+   uint32_t count, ordinal;
+   s_time_t stop;
+
+   count = be32_to_cpu(*((uint32_t *) (buf + 2)));
+   ordinal = be32_to_cpu(*((uint32_t *) (buf + 6)));
+   if (count == 0)
+      return -ENODATA;
+   if (count > bufsiz) {
+      printk("Error: invalid count value %x %zx \n", count, bufsiz);
+      return -E2BIG;
+   }
+
+   //down(&chip->tpm_mutex);
+
+   if ((rc = tpm_tis_send(chip, (uint8_t *) buf, count)) < 0) {
+      printk("tpm_transmit: tpm_send: error %zd\n", rc);
+      goto out;
+   }
+
+   if (chip->irq)
+      goto out_recv;
+
+   stop = NOW() + tpm_calc_ordinal_duration(chip, ordinal);
+   do {
+      uint8_t status = tpm_tis_status(chip);
+      if ((status & (TPM_STS_DATA_AVAIL | TPM_STS_VALID)) ==
+	    (TPM_STS_DATA_AVAIL | TPM_STS_VALID))
+	 goto out_recv;
+
+      if ((status == TPM_STS_COMMAND_READY)) {
+	 printk("TPM Error: Operation Canceled\n");
+	 rc = -ECANCELED;
+	 goto out;
+      }
+
+      msleep(TPM_TIMEOUT);    /* CHECK */
+      rmb();
+   } while (NOW() < stop);
+
+   /* Cancel the command */
+   tpm_tis_cancel_cmd(chip);
+   printk("TPM Operation Timed out\n");
+   rc = -ETIME;
+   goto out;
+
+out_recv:
+   if((rc = tpm_tis_recv(chip, (uint8_t *) buf, bufsiz)) < 0) {
+      printk("tpm_transmit: tpm_recv: error %d\n", rc);
+   }
+out:
+   //up(&chip->tpm_mutex);
+   return rc;
+}
+
+static ssize_t transmit_cmd(struct tpm_chip *chip, struct tpm_cmd_t *cmd,
+                            int len, const char *desc)
+{
+        int err;
+
+        len = tpm_transmit(chip,(uint8_t *) cmd, len);
+        if (len <  0)
+                return len;
+        if (len == TPM_ERROR_SIZE) {
+                err = be32_to_cpu(cmd->header.out.return_code);
+                printk("A TPM error (%d) occurred %s\n", err, desc);
+                return err;
+        }
+        return 0;
+}
+
+void tpm_get_timeouts(struct tpm_chip *chip)
+{
+   struct tpm_cmd_t tpm_cmd;
+   struct timeout_t *timeout_cap;
+   struct duration_t *duration_cap;
+   ssize_t rc;
+   uint32_t timeout;
+
+   tpm_cmd.header.in = tpm_getcap_header;
+   tpm_cmd.params.getcap_in.cap = TPM_CAP_PROP;
+   tpm_cmd.params.getcap_in.subcap_size = cpu_to_be32(4);
+   tpm_cmd.params.getcap_in.subcap = TPM_CAP_PROP_TIS_TIMEOUT;
+
+   if((rc = transmit_cmd(chip, &tpm_cmd, TPM_INTERNAL_RESULT_SIZE,
+	 "attempting to determine the timeouts")) != 0) {
+      printk("transmit failed %d\n", rc);
+      goto duration;
+   }
+
+   if (be32_to_cpu(tpm_cmd.params.getcap_out.cap_size)
+	 != 4 * sizeof(uint32_t)) {
+      printk("Out len check failure %lu \n", be32_to_cpu(tpm_cmd.header.out.length));
+      goto duration;
+   }
+
+   timeout_cap = &tpm_cmd.params.getcap_out.cap.timeout;
+   /* Don't overwrite default if value is 0 */
+   timeout = be32_to_cpu(timeout_cap->a);
+   if (timeout)
+      chip->timeout_a = MICROSECS(timeout); /*Convert to msec */
+   timeout = be32_to_cpu(timeout_cap->b);
+   if (timeout)
+      chip->timeout_b = MICROSECS(timeout); /*Convert to msec */
+   timeout = be32_to_cpu(timeout_cap->c);
+   if (timeout)
+      chip->timeout_c = MICROSECS(timeout); /*Convert to msec */
+   timeout = be32_to_cpu(timeout_cap->d);
+   if (timeout)
+      chip->timeout_d = MICROSECS(timeout); /*Convert to msec */
+
+duration:
+   tpm_cmd.header.in = tpm_getcap_header;
+   tpm_cmd.params.getcap_in.cap = TPM_CAP_PROP;
+   tpm_cmd.params.getcap_in.subcap_size = cpu_to_be32(4);
+   tpm_cmd.params.getcap_in.subcap = TPM_CAP_PROP_TIS_DURATION;
+
+   if((rc = transmit_cmd(chip, &tpm_cmd, TPM_INTERNAL_RESULT_SIZE,
+	 "attempting to determine the durations")) < 0) {
+      return;
+   }
+
+   if (be32_to_cpu(tpm_cmd.params.getcap_out.cap_size)
+	 != 3 * sizeof(uint32_t)) {
+      return;
+   }
+        duration_cap = &tpm_cmd.params.getcap_out.cap.duration;
+        chip->duration[TPM_SHORT] = be32_to_cpu(duration_cap->tpm_short);
+        /* The Broadcom BCM0102 chipset in a Dell Latitude D820 gets the above
+         * value wrong and apparently reports msecs rather than usecs. So we
+         * fix up the resulting too-small TPM_SHORT value to make things work.
+         */
+        if (chip->duration[TPM_SHORT] < 10) {
+	   chip->duration[TPM_SHORT] = MILLISECS(chip->duration[TPM_SHORT]);
+	} else {
+	   chip->duration[TPM_SHORT] = MICROSECS(chip->duration[TPM_SHORT]);
+	}
+
+        chip->duration[TPM_MEDIUM] = MICROSECS(be32_to_cpu(duration_cap->tpm_medium));
+        chip->duration[TPM_LONG] = MICROSECS(be32_to_cpu(duration_cap->tpm_long));
+}
+
+
+
+void tpm_continue_selftest(struct tpm_chip* chip) {
+   uint8_t data[] = {
+      0, 193,                 /* TPM_TAG_RQU_COMMAND */
+      0, 0, 0, 10,            /* length */
+      0, 0, 0, 83,            /* TPM_ORD_GetCapability */
+   };
+
+   tpm_transmit(chip, data, sizeof(data));
+}
+
+ssize_t tpm_getcap(struct tpm_chip *chip, uint32_t subcap_id, cap_t *cap,
+                   const char *desc)
+{
+        struct tpm_cmd_t tpm_cmd;
+        int rc;
+
+        tpm_cmd.header.in = tpm_getcap_header;
+        if (subcap_id == CAP_VERSION_1_1 || subcap_id == CAP_VERSION_1_2) {
+                tpm_cmd.params.getcap_in.cap = subcap_id;
+                /*subcap field not necessary */
+                tpm_cmd.params.getcap_in.subcap_size = cpu_to_be32(0);
+                tpm_cmd.header.in.length -= cpu_to_be32(sizeof(uint32_t));
+        } else {
+                if (subcap_id == TPM_CAP_FLAG_PERM ||
+                    subcap_id == TPM_CAP_FLAG_VOL)
+                        tpm_cmd.params.getcap_in.cap = TPM_CAP_FLAG;
+                else
+                        tpm_cmd.params.getcap_in.cap = TPM_CAP_PROP;
+                tpm_cmd.params.getcap_in.subcap_size = cpu_to_be32(4);
+                tpm_cmd.params.getcap_in.subcap = subcap_id;
+        }
+        rc = transmit_cmd(chip, &tpm_cmd, TPM_INTERNAL_RESULT_SIZE, desc);
+        if (!rc)
+                *cap = tpm_cmd.params.getcap_out.cap;
+        return rc;
+}
+
+
+struct tpm_chip* init_tpm_tis(unsigned long baseaddr, int localities, unsigned int irq)
+{
+   int i;
+   unsigned long addr;
+   struct tpm_chip* tpm = NULL;
+   uint32_t didvid;
+   uint32_t intfcaps;
+   uint32_t intmask;
+
+   printk("============= Init TPM TIS Driver ==============\n");
+
+   /*Sanity check the localities input */
+   if(localities & ~TPM_TIS_EN_LOCLALL) {
+      printk("init_tpm_tis() Invalid locality specification! %X\n", localities);
+      goto abort_egress;
+   }
+
+   printk("IOMEM Machine Base Address: %lX\n", baseaddr);
+
+   /* Create the tpm data structure */
+   tpm = malloc(sizeof(struct tpm_chip));
+   __init_tpm_chip(tpm);
+
+   /* Set the enabled localities - if 0 we leave default as all enabled */
+   if(localities != 0) {
+      tpm->enabled_localities = localities;
+   }
+   printk("Enabled Localities: ");
+   for(i = 0; i < 5; ++i) {
+      if(locality_enabled(tpm, i)) {
+	 printk("%d ", i);
+      }
+   }
+   printk("\n");
+
+   /* Set the base machine address */
+   tpm->baseaddr = baseaddr;
+
+   /* Set default timeouts */
+   tpm->timeout_a = MILLISECS(TIS_SHORT_TIMEOUT);
+   tpm->timeout_b = MILLISECS(TIS_LONG_TIMEOUT);
+   tpm->timeout_c = MILLISECS(TIS_SHORT_TIMEOUT);
+   tpm->timeout_d = MILLISECS(TIS_SHORT_TIMEOUT);
+
+   /*Map the mmio pages */
+   addr = tpm->baseaddr;
+   for(i = 0; i < 5; ++i) {
+      if(locality_enabled(tpm, i)) {
+	 /* Map the page in now */
+	 if((tpm->pages[i] = ioremap_nocache(addr, PAGE_SIZE)) == NULL) {
+	    printk("Unable to map iomem page a address %p\n", addr);
+	    goto abort_egress;
+	 }
+
+	 /* Set default locality to the first enabled one */
+	 if (tpm->locality < 0) {
+	    if(tpm_tis_request_locality(tpm, i) < 0) {
+	       printk("Unable to request locality %d??\n", i);
+	       goto abort_egress;
+	    }
+	 }
+      }
+      addr += PAGE_SIZE;
+   }
+
+
+   /* Get the vendor and device ids */
+   didvid = ioread32(TPM_DID_VID(tpm, tpm->locality));
+   tpm->did = didvid >> 16;
+   tpm->vid = didvid & 0xFFFF;
+
+
+   /* Get the revision id */
+   tpm->rid = ioread8(TPM_RID(tpm, tpm->locality));
+
+   printk("1.2 TPM (device-id=0x%X vendor-id = %X rev-id = %X)\n", tpm->did, tpm->vid, tpm->rid);
+
+   intfcaps = ioread32(TPM_INTF_CAPS(tpm, tpm->locality));
+   printk("TPM interface capabilities (0x%x):\n", intfcaps);
+   if (intfcaps & TPM_INTF_BURST_COUNT_STATIC)
+      printk("\tBurst Count Static\n");
+   if (intfcaps & TPM_INTF_CMD_READY_INT)
+      printk("\tCommand Ready Int Support\n");
+   if (intfcaps & TPM_INTF_INT_EDGE_FALLING)
+      printk("\tInterrupt Edge Falling\n");
+   if (intfcaps & TPM_INTF_INT_EDGE_RISING)
+      printk("\tInterrupt Edge Rising\n");
+   if (intfcaps & TPM_INTF_INT_LEVEL_LOW)
+      printk("\tInterrupt Level Low\n");
+   if (intfcaps & TPM_INTF_INT_LEVEL_HIGH)
+      printk("\tInterrupt Level High\n");
+   if (intfcaps & TPM_INTF_LOCALITY_CHANGE_INT)
+      printk("\tLocality Change Int Support\n");
+   if (intfcaps & TPM_INTF_STS_VALID_INT)
+      printk("\tSts Valid Int Support\n");
+   if (intfcaps & TPM_INTF_DATA_AVAIL_INT)
+      printk("\tData Avail Int Support\n");
+
+   /*Interupt setup */
+   intmask = ioread32(TPM_INT_ENABLE(tpm, tpm->locality));
+
+   intmask |= TPM_INTF_CMD_READY_INT
+      | TPM_INTF_LOCALITY_CHANGE_INT | TPM_INTF_DATA_AVAIL_INT
+      | TPM_INTF_STS_VALID_INT;
+
+   iowrite32(TPM_INT_ENABLE(tpm, tpm->locality), intmask);
+
+   /*If interupts are enabled, handle it */
+   if(irq) {
+      if(irq != TPM_PROBE_IRQ) {
+	 tpm->irq = irq;
+      } else {
+	 /*FIXME add irq probing feature later */
+	 printk("IRQ probing not implemented\n");
+      }
+   }
+
+   if(tpm->irq) {
+      iowrite8(TPM_INT_VECTOR(tpm, tpm->locality), tpm->irq);
+
+      if(bind_pirq(tpm->irq, 1, tpm_tis_irq_handler, tpm) != 0) {
+	 printk("Unabled to request irq: %u for use\n", tpm->irq);
+	 printk("Will use polling mode\n");
+	 tpm->irq = 0;
+      } else {
+	 /* Clear all existing */
+	 iowrite32(TPM_INT_STATUS(tpm, tpm->locality), ioread32(TPM_INT_STATUS(tpm, tpm->locality)));
+
+	 /* Turn on interrupts */
+	 iowrite32(TPM_INT_ENABLE(tpm, tpm->locality), intmask | TPM_GLOBAL_INT_ENABLE);
+      }
+   }
+
+   tpm_get_timeouts(tpm);
+   tpm_continue_selftest(tpm);
+
+
+   return tpm;
+abort_egress:
+   if(tpm != NULL) {
+      shutdown_tpm_tis(tpm);
+   }
+   return NULL;
+}
+
+void shutdown_tpm_tis(struct tpm_chip* tpm){
+   int i;
+
+   printk("Shutting down tpm_tis device\n");
+
+   iowrite32(TPM_INT_ENABLE(tpm, tpm->locality), ~TPM_GLOBAL_INT_ENABLE);
+
+   /*Unmap all of the mmio pages */
+   for(i = 0; i < 5; ++i) {
+      if(tpm->pages[i] != NULL) {
+	 iounmap(tpm->pages[i], PAGE_SIZE);
+	 tpm->pages[i] = NULL;
+      }
+   }
+   free(tpm);
+   return;
+}
+
+
+int tpm_tis_cmd(struct tpm_chip* tpm, uint8_t* req, size_t reqlen, uint8_t** resp, size_t* resplen)
+{
+   if(tpm->locality < 0) {
+      printk("tpm_tis_cmd() failed! locality not set!\n");
+      return -1;
+   }
+   if(reqlen > TPM_BUFSIZE) {
+      reqlen = TPM_BUFSIZE;
+   }
+   memcpy(tpm->data_buffer, req, reqlen);
+   *resplen = tpm_transmit(tpm, tpm->data_buffer, TPM_BUFSIZE);
+
+   *resp = malloc(*resplen);
+   memcpy(*resp, tpm->data_buffer, *resplen);
+   return 0;
+}
+
+#ifdef HAVE_LIBC
+int tpm_tis_open(struct tpm_chip* tpm)
+{
+   /* Silently prevent multiple opens */
+   if(tpm->fd != -1) {
+      return tpm->fd;
+   }
+
+   tpm->fd = alloc_fd(FTYPE_TPM_TIS);
+   printk("tpm_tis_open() -> %d\n", tpm->fd);
+   files[tpm->fd].tpm_tis.dev = tpm;
+   files[tpm->fd].tpm_tis.offset = 0;
+   files[tpm->fd].tpm_tis.respgot = 0;
+   return tpm->fd;
+}
+
+int tpm_tis_posix_write(int fd, const uint8_t* buf, size_t count)
+{
+   struct tpm_chip* tpm;
+   tpm = files[fd].tpm_tis.dev;
+
+   if(tpm->locality < 0) {
+      printk("tpm_tis_posix_write() failed! locality not set!\n");
+      errno = EINPROGRESS;
+      return -1;
+   }
+   if(count == 0) {
+      return 0;
+   }
+
+   /* Return an error if we are already processing a command */
+   if(count > TPM_BUFSIZE) {
+      count = TPM_BUFSIZE;
+   }
+   /* Send the command now */
+   memcpy(tpm->data_buffer, buf, count);
+   if((tpm->data_len = tpm_transmit(tpm, tpm->data_buffer, TPM_BUFSIZE)) < 0) {
+      errno = EIO;
+      return -1;
+   }
+   return count;
+}
+
+int tpm_tis_posix_read(int fd, uint8_t* buf, size_t count)
+{
+   int rc;
+   struct tpm_chip* tpm;
+   tpm = files[fd].tpm_tis.dev;
+
+   if(count == 0) {
+      return 0;
+   }
+
+   /* If there is no tpm resp to read, return EIO */
+   if(tpm->data_len < 0) {
+      errno = EIO;
+      return -1;
+   }
+
+
+   /* Handle EOF case */
+   if(files[fd].tpm_tis.offset >= tpm->data_len) {
+      rc = 0;
+   } else {
+      rc = min(tpm->data_len - files[fd].tpm_tis.offset, count);
+      memcpy(buf, tpm->data_buffer + files[fd].tpm_tis.offset, rc);
+   }
+   files[fd].tpm_tis.offset += rc;
+   /* Reset the data pending flag */
+   return rc;
+}
+int tpm_tis_posix_fstat(int fd, struct stat* buf)
+{
+   struct tpm_chip* tpm;
+   tpm = files[fd].tpm_tis.dev;
+
+   buf->st_mode = O_RDWR;
+   buf->st_uid = 0;
+   buf->st_gid = 0;
+   buf->st_size = be32_to_cpu(*((uint32_t*)(tpm->data_buffer + 2)));
+   buf->st_atime = buf->st_mtime = buf->st_ctime = time(NULL);
+   return 0;
+}
+
+
+#endif
diff --git a/extras/mini-os/tpmback.c b/extras/mini-os/tpmback.c
new file mode 100644
index 0000000..c709019
--- /dev/null
+++ b/extras/mini-os/tpmback.c
@@ -0,0 +1,1125 @@
+/*
+ * Copyright (c) 2010-2012 United States Government, as represented by
+ * the Secretary of Defense.  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 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.
+ *
+ * Based upon the files:
+ *  drivers/xen/tpmbk.c
+ * from the Linux kernel, which are Copyright (C) 2006 IBM Corporation
+ */
+#include <mini-os/os.h>
+#include <mini-os/xenbus.h>
+#include <mini-os/events.h>
+#include <errno.h>
+#include <mini-os/gnttab.h>
+#include <xen/io/xenbus.h>
+#include <xen/io/tpmif.h>
+#include <xen/io/protocols.h>
+#include <mini-os/xmalloc.h>
+#include <time.h>
+#include <mini-os/tpmback.h>
+#include <mini-os/lib.h>
+#include <fcntl.h>
+#include <mini-os/mm.h>
+#include <mini-os/posix/sys/mman.h>
+#include <mini-os/semaphore.h>
+#include <mini-os/wait.h>
+
+
+#ifndef HAVE_LIBC
+#define strtoul simple_strtoul
+#endif
+
+//#define TPMBACK_PRINT_DEBUG
+#ifdef TPMBACK_PRINT_DEBUG
+#define TPMBACK_DEBUG(fmt,...) printk("Tpmback:Debug("__FILE__":%d) " fmt, __LINE__, ##__VA_ARGS__)
+#define TPMBACK_DEBUG_MORE(fmt,...) printk(fmt, ##__VA_ARGS__)
+#else
+#define TPMBACK_DEBUG(fmt,...)
+#endif
+#define TPMBACK_ERR(fmt,...) printk("Tpmback:Error " fmt, ##__VA_ARGS__)
+#define TPMBACK_LOG(fmt,...) printk("Tpmback:Info " fmt, ##__VA_ARGS__)
+
+#define min(a,b) (((a) < (b)) ? (a) : (b))
+
+/* Default size of the tpmif array at initialization */
+#define DEF_ARRAY_SIZE 1
+
+/* tpmif and tpmdev flags */
+#define TPMIF_CLOSED 1
+#define TPMIF_REQ_READY 2
+
+struct tpmif {
+   domid_t domid;
+   unsigned int handle;
+
+   char* fe_path;
+   char* fe_state_path;
+
+   /* Locally bound event channel*/
+   evtchn_port_t evtchn;
+
+   /* Shared page */
+   tpmif_tx_interface_t* tx;
+
+   /* pointer to TPMIF_RX_RING_SIZE pages */
+   void** pages;
+
+   enum xenbus_state state;
+   enum { DISCONNECTED, DISCONNECTING, CONNECTED } status;
+
+   char* uuid;
+
+   /* state flags */
+   int flags;
+};
+typedef struct tpmif tpmif_t;
+
+struct tpmback_dev {
+
+   tpmif_t** tpmlist;
+   unsigned long num_tpms;
+   unsigned long num_alloc;
+
+   struct gntmap map;
+
+   /* True if at least one tpmif has a request to be handled */
+   int flags;
+
+   /* exclusive domains, see init_tpmback comment in tpmback.h */
+   char** exclusive_uuids;
+
+   xenbus_event_queue events;
+
+   /* Callbacks */
+   void (*open_callback)(domid_t, unsigned int);
+   void (*close_callback)(domid_t, unsigned int);
+   void (*suspend_callback)(domid_t, unsigned int);
+   void (*resume_callback)(domid_t, unsigned int);
+};
+typedef struct tpmback_dev tpmback_dev_t;
+
+enum { EV_NONE, EV_NEWFE, EV_STCHNG } tpm_ev_enum;
+
+/* Global objects */
+static struct thread* eventthread = NULL;
+static tpmback_dev_t gtpmdev = {
+   .tpmlist = NULL,
+   .num_tpms = 0,
+   .num_alloc = 0,
+   .flags = TPMIF_CLOSED,
+   .events = NULL,
+   .open_callback = NULL,
+   .close_callback = NULL,
+   .suspend_callback = NULL,
+   .resume_callback = NULL,
+};
+struct wait_queue_head waitq;
+int globalinit = 0;
+
+/************************************
+ * TPMIF SORTED ARRAY FUNCTIONS
+ * tpmback_dev_t.tpmlist is a sorted array, sorted by domid and then handle number
+ * Duplicates are not allowed
+ * **********************************/
+
+inline void tpmif_req_ready(tpmif_t* tpmif) {
+   tpmif->flags |= TPMIF_REQ_READY;
+   gtpmdev.flags |= TPMIF_REQ_READY;
+}
+
+inline void tpmdev_check_req(void) {
+   int i;
+   int flags;
+   local_irq_save(flags);
+   for(i = 0; i < gtpmdev.num_tpms; ++i) {
+      if(gtpmdev.tpmlist[i]->flags & TPMIF_REQ_READY) {
+	 gtpmdev.flags |= TPMIF_REQ_READY;
+	 local_irq_restore(flags);
+	 return;
+      }
+   }
+   gtpmdev.flags &= ~TPMIF_REQ_READY;
+   local_irq_restore(flags);
+}
+
+inline void tpmif_req_finished(tpmif_t* tpmif) {
+   tpmif->flags &= ~TPMIF_REQ_READY;
+   tpmdev_check_req();
+}
+
+int __get_tpmif_index(int st, int n, domid_t domid, unsigned int handle)
+{
+   int i = st + n /2;
+   tpmif_t* tmp;
+
+   if( n <= 0 )
+      return -1;
+
+   tmp = gtpmdev.tpmlist[i];
+   if(domid == tmp->domid && tmp->handle == handle) {
+      return i;
+   } else if ( (domid < tmp->domid) ||
+	 (domid == tmp->domid && handle < tmp->handle)) {
+      return __get_tpmif_index(st, n/2, domid, handle);
+   } else {
+      return __get_tpmif_index(i + 1, n/2 - ((n +1) % 2), domid, handle);
+   }
+}
+
+/* Returns the array index of the tpmif domid/handle. Returns -1 if no such tpmif exists */
+int get_tpmif_index(domid_t domid, unsigned int handle)
+{
+   int flags;
+   int index;
+   local_irq_save(flags);
+   index = __get_tpmif_index(0, gtpmdev.num_tpms, domid, handle);
+   local_irq_restore(flags);
+   return index;
+}
+
+/* Returns the tpmif domid/handle or NULL if none exists */
+tpmif_t* get_tpmif(domid_t domid, unsigned int handle)
+{
+   int flags;
+   int i;
+   tpmif_t* ret;
+   local_irq_save(flags);
+   i = get_tpmif_index(domid, handle);
+   if (i < 0) {
+      ret = NULL;
+   } else {
+      ret = gtpmdev.tpmlist[i];
+   }
+   local_irq_restore(flags);
+   return ret;
+}
+
+/* Remove the given tpmif. Returns 0 if it was removed, -1 if it was not removed */
+int remove_tpmif(tpmif_t* tpmif)
+{
+   int i, j;
+   char* err;
+   int flags;
+   local_irq_save(flags);
+
+   /* Find the index in the array if it exists */
+   i = get_tpmif_index(tpmif->domid, tpmif->handle);
+   if (i < 0) {
+      goto error;
+   }
+
+   /* Remove the interface from the list */
+   for(j = i; j < gtpmdev.num_tpms - 1; ++j) {
+      gtpmdev.tpmlist[j] = gtpmdev.tpmlist[j+1];
+   }
+   gtpmdev.tpmlist[j] = NULL;
+   --gtpmdev.num_tpms;
+
+   /* If removed tpm was the only ready tpm, then we need to check and turn off the ready flag */
+   tpmdev_check_req();
+
+   local_irq_restore(flags);
+
+   /* Stop listening for events on this tpm interface */
+   if((err = xenbus_unwatch_path_token(XBT_NIL, tpmif->fe_state_path, tpmif->fe_state_path))) {
+      TPMBACK_ERR("Unable to unwatch path token `%s' Error was %s Ignoring..\n", tpmif->fe_state_path, err);
+      free(err);
+   }
+
+   return 0;
+error:
+   local_irq_restore(flags);
+   return -1;
+}
+
+/* Insert tpmif into dev->tpmlist. Returns 0 on success and non zero on error.
+ * It is an error to insert a tpmif with the same domid and handle
+ * number
+ * as something already in the list */
+int insert_tpmif(tpmif_t* tpmif)
+{
+   int flags;
+   unsigned int i, j;
+   tpmif_t* tmp;
+   char* err;
+
+   local_irq_save(flags);
+
+   /*Check if we need to allocate more space */
+   if (gtpmdev.num_tpms == gtpmdev.num_alloc) {
+      gtpmdev.num_alloc *= 2;
+      gtpmdev.tpmlist = realloc(gtpmdev.tpmlist, gtpmdev.num_alloc);
+   }
+
+   /*Find where to put the new interface */
+   for(i = 0; i < gtpmdev.num_tpms; ++i)
+   {
+      tmp = gtpmdev.tpmlist[i];
+      if(tpmif->domid == tmp->domid && tpmif->handle == tmp->handle) {
+	 TPMBACK_ERR("Tried to insert duplicate tpm interface %u/%u\n", (unsigned int) tpmif->domid, tpmif->handle);
+	 goto error;
+      }
+      if((tpmif->domid < tmp->domid) ||
+	    (tpmif->domid == tmp->domid && tpmif->handle < tmp->handle)) {
+	 break;
+      }
+   }
+
+   /*Shift all the tpm pointers past i down one */
+   for(j = gtpmdev.num_tpms; j > i; --j) {
+      gtpmdev.tpmlist[j] = gtpmdev.tpmlist[j-1];
+   }
+
+   /*Add the new interface */
+   gtpmdev.tpmlist[i] = tpmif;
+   ++gtpmdev.num_tpms;
+
+   /*Should not be needed, anything inserted with ready flag is probably an error */
+   tpmdev_check_req();
+
+   local_irq_restore(flags);
+
+   /*Listen for state changes on the new interface */
+   if((err = xenbus_watch_path_token(XBT_NIL, tpmif->fe_state_path, tpmif->fe_state_path, &gtpmdev.events)))
+   {
+      /* if we got an error here we should carefully remove the interface and then return */
+      TPMBACK_ERR("Unable to watch path token `%s' Error was %s\n", tpmif->fe_state_path, err);
+      free(err);
+      remove_tpmif(tpmif);
+      goto error_post_irq;
+   }
+
+   return 0;
+error:
+   local_irq_restore(flags);
+error_post_irq:
+   return -1;
+}
+
+
+/*****************
+ * CHANGE BACKEND STATE
+ * *****************/
+/*Attempts to change the backend state in xenstore
+ * returns 0 on success and non-zero on error */
+int tpmif_change_state(tpmif_t* tpmif, enum xenbus_state state)
+{
+   char path[512];
+   char *value;
+   char *err;
+   enum xenbus_state readst;
+   TPMBACK_DEBUG("Backend state change %u/%u from=%d to=%d\n", (unsigned int) tpmif->domid, tpmif->handle, tpmif->state, state);
+   if (tpmif->state == state)
+      return 0;
+
+   snprintf(path, 512, "backend/vtpm/%u/%u/state", (unsigned int) tpmif->domid, tpmif->handle);
+
+   if((err = xenbus_read(XBT_NIL, path, &value))) {
+      TPMBACK_ERR("Unable to read backend state %s, error was %s\n", path, err);
+      free(err);
+      return -1;
+   }
+   if(sscanf(value, "%d", &readst) != 1) {
+      TPMBACK_ERR("Non integer value (%s) in %s ??\n", value, path);
+      free(value);
+      return -1;
+   }
+   free(value);
+
+   /* It's possible that the backend state got updated by hotplug or something else behind our back */
+   if(readst != tpmif->state) {
+      TPMBACK_DEBUG("tpm interface state was %d but xenstore state was %d!\n", tpmif->state, readst);
+      tpmif->state = readst;
+   }
+
+   /*If if the state isnt changing, then we dont update xenstore b/c we dont want to fire extraneous events */
+   if(tpmif->state == state) {
+      return 0;
+   }
+
+   /*update xenstore*/
+   snprintf(path, 512, "backend/vtpm/%u/%u", (unsigned int) tpmif->domid, tpmif->handle);
+   if((err = xenbus_printf(XBT_NIL, path, "state", "%u", state))) {
+      TPMBACK_ERR("Error writing to xenstore %s, error was %s new state=%d\n", path, err, state);
+      free(err);
+      return -1;
+   }
+
+   tpmif->state = state;
+
+   return 0;
+}
+/**********************************
+ * TPMIF CREATION AND DELETION
+ * *******************************/
+inline tpmif_t* __init_tpmif(domid_t domid, unsigned int handle)
+{
+   tpmif_t* tpmif;
+   tpmif = malloc(sizeof(*tpmif));
+   tpmif->domid = domid;
+   tpmif->handle = handle;
+   tpmif->fe_path = NULL;
+   tpmif->fe_state_path = NULL;
+   tpmif->state = XenbusStateInitialising;
+   tpmif->status = DISCONNECTED;
+   tpmif->tx = NULL;
+   tpmif->pages = NULL;
+   tpmif->flags = 0;
+   tpmif->uuid = NULL;
+   return tpmif;
+}
+
+void __free_tpmif(tpmif_t* tpmif)
+{
+   if(tpmif->pages) {
+      free(tpmif->pages);
+   }
+   if(tpmif->fe_path) {
+      free(tpmif->fe_path);
+   }
+   if(tpmif->fe_state_path) {
+      free(tpmif->fe_state_path);
+   }
+   if(tpmif->uuid) {
+      free(tpmif->uuid);
+   }
+   free(tpmif);
+}
+/* Creates a new tpm interface, adds it to the sorted array and returns it.
+ * returns NULL on error
+ * If the tpm interface already exists, it is returned*/
+tpmif_t* new_tpmif(domid_t domid, unsigned int handle)
+{
+   tpmif_t* tpmif;
+   char* err;
+   char path[512];
+
+   /* Make sure we haven't already created this tpm
+    * Double events can occur */
+   if((tpmif = get_tpmif(domid, handle)) != NULL) {
+      return tpmif;
+   }
+
+   tpmif = __init_tpmif(domid, handle);
+
+   /* Get the uuid from xenstore */
+   snprintf(path, 512, "backend/vtpm/%u/%u/uuid", (unsigned int) domid, handle);
+   if((err = xenbus_read(XBT_NIL, path, &tpmif->uuid))) {
+      TPMBACK_ERR("Error reading %s, Error = %s\n", path, err);
+      free(err);
+      goto error;
+   }
+
+   /* Do the exclusive uuid check now */
+   if(gtpmdev.exclusive_uuids != NULL) {
+      char** ptr;
+
+      /* Check that its in the whitelist */
+      for(ptr = gtpmdev.exclusive_uuids; *ptr != NULL; ++ptr) {
+	 if(!strcmp(tpmif->uuid, *ptr)) {
+	    break;
+	 }
+      }
+      /* If *ptr == NULL then we went through the whole list without a match, so close the connection */
+      if(*ptr == NULL) {
+	 tpmif_change_state(tpmif, XenbusStateClosed);
+	 TPMBACK_ERR("Frontend %u/%u tried to connect with invalid uuid=%s\n", (unsigned int) domid, handle, tpmif->uuid);
+	 goto error;
+      }
+   }
+
+   /* allocate pages to be used for shared mapping */
+   if((tpmif->pages = malloc(sizeof(void*) * TPMIF_TX_RING_SIZE)) == NULL) {
+      goto error;
+   }
+   memset(tpmif->pages, 0, sizeof(void*) * TPMIF_TX_RING_SIZE);
+
+   if(tpmif_change_state(tpmif, XenbusStateInitWait)) {
+      goto error;
+   }
+
+   snprintf(path, 512, "backend/vtpm/%u/%u/frontend", (unsigned int) domid, handle);
+   if((err = xenbus_read(XBT_NIL, path, &tpmif->fe_path))) {
+      TPMBACK_ERR("Error creating new tpm instance xenbus_read(%s), Error = %s", path, err);
+      free(err);
+      goto error;
+   }
+
+   /*Set the state path */
+   tpmif->fe_state_path = malloc(strlen(tpmif->fe_path) + 7);
+   strcpy(tpmif->fe_state_path, tpmif->fe_path);
+   strcat(tpmif->fe_state_path, "/state");
+
+   if(insert_tpmif(tpmif)) {
+      goto error;
+   }
+   TPMBACK_DEBUG("New tpmif %u/%u\n", (unsigned int) tpmif->domid, tpmif->handle);
+   /* Do the callback now */
+   if(gtpmdev.open_callback) {
+      gtpmdev.open_callback(tpmif->domid, tpmif->handle);
+   }
+   return tpmif;
+error:
+   __free_tpmif(tpmif);
+   return NULL;
+
+}
+
+/* Removes tpmif from dev->tpmlist and frees it's memory usage */
+void free_tpmif(tpmif_t* tpmif)
+{
+   char* err;
+   char path[512];
+   TPMBACK_DEBUG("Free tpmif %u/%u\n", (unsigned int) tpmif->domid, tpmif->handle);
+   if(tpmif->flags & TPMIF_CLOSED) {
+      TPMBACK_ERR("Tried to free an instance twice! Theres a bug somewhere!\n");
+      BUG();
+   }
+   tpmif->flags = TPMIF_CLOSED;
+
+   tpmif_change_state(tpmif, XenbusStateClosing);
+
+   /* Unmap share page and unbind event channel */
+   if(tpmif->status == CONNECTED) {
+      tpmif->status = DISCONNECTING;
+      mask_evtchn(tpmif->evtchn);
+
+      if(gntmap_munmap(&gtpmdev.map, (unsigned long)tpmif->tx, 1)) {
+	 TPMBACK_ERR("%u/%u Error occured while trying to unmap shared page\n", (unsigned int) tpmif->domid, tpmif->handle);
+      }
+
+      unbind_evtchn(tpmif->evtchn);
+   }
+   tpmif->status = DISCONNECTED;
+   tpmif_change_state(tpmif, XenbusStateClosed);
+
+   /* Do the callback now */
+   if(gtpmdev.close_callback) {
+      gtpmdev.close_callback(tpmif->domid, tpmif->handle);
+   }
+
+   /* remove from array */
+   remove_tpmif(tpmif);
+
+   /* Wake up anyone possibly waiting on this interface and let them exit */
+   wake_up(&waitq);
+   schedule();
+
+   /* Remove the old xenbus entries */
+   snprintf(path, 512, "backend/vtpm/%u/%u", (unsigned int) tpmif->domid, tpmif->handle);
+   if((err = xenbus_rm(XBT_NIL, path))) {
+      TPMBACK_ERR("Error cleaning up xenbus entries path=%s error=%s\n", path, err);
+      free(err);
+   }
+
+   TPMBACK_LOG("Frontend %u/%u disconnected\n", (unsigned int) tpmif->domid, tpmif->handle);
+
+   /* free memory */
+   __free_tpmif(tpmif);
+
+}
+
+/**********************
+ * REMAINING TPMBACK FUNCTIONS
+ * ********************/
+
+/*Event channel handler */
+void tpmback_handler(evtchn_port_t port, struct pt_regs *regs, void *data)
+{
+   tpmif_t* tpmif = (tpmif_t*) data;
+   tpmif_tx_request_t* tx = &tpmif->tx->ring[0].req;
+   /* Throw away 0 size events, these can trigger from event channel unmasking */
+   if(tx->size == 0)
+      return;
+
+   TPMBACK_DEBUG("EVENT CHANNEL FIRE %u/%u\n", (unsigned int) tpmif->domid, tpmif->handle);
+   tpmif_req_ready(tpmif);
+   wake_up(&waitq);
+
+}
+
+/* Connect to frontend */
+int connect_fe(tpmif_t* tpmif)
+{
+   char path[512];
+   char* err, *value;
+   uint32_t domid;
+   grant_ref_t ringref;
+   evtchn_port_t evtchn;
+
+   /* If already connected then quit */
+   if (tpmif->status == CONNECTED) {
+      TPMBACK_DEBUG("%u/%u tried to connect while it was already connected?\n", (unsigned int) tpmif->domid, tpmif->handle);
+      return 0;
+   }
+
+   /* Fetch the grant reference */
+   snprintf(path, 512, "%s/ring-ref", tpmif->fe_path);
+   if((err = xenbus_read(XBT_NIL, path, &value))) {
+      TPMBACK_ERR("Error creating new tpm instance xenbus_read(%s) Error = %s", path, err);
+      free(err);
+      return -1;
+   }
+   if(sscanf(value, "%d", &ringref) != 1) {
+      TPMBACK_ERR("Non integer value (%s) in %s ??\n", value, path);
+      free(value);
+      return -1;
+   }
+   free(value);
+
+
+   /* Fetch the event channel*/
+   snprintf(path, 512, "%s/event-channel", tpmif->fe_path);
+   if((err = xenbus_read(XBT_NIL, path, &value))) {
+      TPMBACK_ERR("Error creating new tpm instance xenbus_read(%s) Error = %s", path, err);
+      free(err);
+      return -1;
+   }
+   if(sscanf(value, "%d", &evtchn) != 1) {
+      TPMBACK_ERR("Non integer value (%s) in %s ??\n", value, path);
+      free(value);
+      return -1;
+   }
+   free(value);
+
+   domid = tpmif->domid;
+   if((tpmif->tx = gntmap_map_grant_refs(&gtpmdev.map, 1, &domid, 0, &ringref, PROT_READ | PROT_WRITE)) == NULL) {
+      TPMBACK_ERR("Failed to map grant reference %u/%u\n", (unsigned int) tpmif->domid, tpmif->handle);
+      return -1;
+   }
+   memset(tpmif->tx, 0, PAGE_SIZE);
+
+   /*Bind the event channel */
+   if((evtchn_bind_interdomain(tpmif->domid, evtchn, tpmback_handler, tpmif, &tpmif->evtchn)))
+   {
+      TPMBACK_ERR("%u/%u Unable to bind to interdomain event channel!\n", (unsigned int) tpmif->domid, tpmif->handle);
+      goto error_post_map;
+   }
+   unmask_evtchn(tpmif->evtchn);
+
+   /* Write the ready flag and change status to connected */
+   snprintf(path, 512, "backend/vtpm/%u/%u", (unsigned int) tpmif->domid, tpmif->handle);
+   if((err = xenbus_printf(XBT_NIL, path, "ready", "%u", 1))) {
+      TPMBACK_ERR("%u/%u Unable to write ready flag on connect_fe()\n", (unsigned int) tpmif->domid, tpmif->handle);
+      free(err);
+      goto error_post_evtchn;
+   }
+   tpmif->status = CONNECTED;
+   if((tpmif_change_state(tpmif, XenbusStateConnected))){
+      goto error_post_evtchn;
+   }
+
+   TPMBACK_LOG("Frontend %u/%u connected\n", (unsigned int) tpmif->domid, tpmif->handle);
+
+   return 0;
+error_post_evtchn:
+   mask_evtchn(tpmif->evtchn);
+   unbind_evtchn(tpmif->evtchn);
+error_post_map:
+   gntmap_munmap(&gtpmdev.map, (unsigned long)tpmif->tx, 1);
+   return -1;
+}
+
+static int frontend_changed(tpmif_t* tpmif)
+{
+   int state = xenbus_read_integer(tpmif->fe_state_path);
+   if(state < 0) {
+      state = XenbusStateUnknown;
+   }
+
+   TPMBACK_DEBUG("Frontend %u/%u state changed to %d\n", (unsigned int) tpmif->domid, tpmif->handle, state);
+
+   switch (state) {
+      case XenbusStateInitialising:
+      case XenbusStateInitialised:
+	 break;
+
+      case XenbusStateConnected:
+	 if(connect_fe(tpmif)) {
+	    TPMBACK_ERR("Failed to connect to front end %u/%u\n", (unsigned int) tpmif->domid, tpmif->handle);
+	    tpmif_change_state(tpmif, XenbusStateClosed);
+	    return -1;
+	 }
+	 break;
+
+      case XenbusStateClosing:
+	 tpmif_change_state(tpmif, XenbusStateClosing);
+	 break;
+
+      case XenbusStateUnknown: /* keep it here */
+      case XenbusStateClosed:
+	 free_tpmif(tpmif);
+	 break;
+
+      default:
+	 TPMBACK_DEBUG("BAD STATE CHANGE %u/%u state = %d for tpmif\n", (unsigned int) tpmif->domid, tpmif->handle, state);
+	 return -1;
+   }
+   return 0;
+}
+
+
+/* parses the string that comes out of xenbus_watch_wait_return. */
+static int parse_eventstr(const char* evstr, domid_t* domid, unsigned int* handle)
+{
+   int ret;
+   char cmd[40];
+   char* err;
+   char* value;
+   unsigned int udomid = 0;
+   tpmif_t* tpmif;
+   /* First check for new frontends, this occurs when /backend/vtpm/<domid>/<handle> gets created. Note we what the sscanf to fail on the last %s */
+   if (sscanf(evstr, "backend/vtpm/%u/%u/%40s", &udomid, handle, cmd) == 2) {
+      *domid = udomid;
+      /* Make sure the entry exists, if this event triggers because the entry dissapeared then ignore it */
+      if((err = xenbus_read(XBT_NIL, evstr, &value))) {
+	 free(err);
+	 return EV_NONE;
+      }
+      free(value);
+      /* Make sure the tpmif entry does not already exist, this should not happen */
+      if((tpmif = get_tpmif(*domid, *handle)) != NULL) {
+	 TPMBACK_DEBUG("Duplicate tpm entries! %u %u\n", tpmif->domid, tpmif->handle);
+	 return EV_NONE;
+      }
+      return EV_NEWFE;
+   } else if((ret = sscanf(evstr, "/local/domain/%u/device/vtpm/%u/%40s", &udomid, handle, cmd)) == 3) {
+      *domid = udomid;
+      if (!strcmp(cmd, "state"))
+	 return EV_STCHNG;
+   }
+   return EV_NONE;
+}
+
+void handle_backend_event(char* evstr) {
+   tpmif_t* tpmif;
+   domid_t domid;
+   unsigned int handle;
+   int event;
+
+   TPMBACK_DEBUG("Xenbus Event: %s\n", evstr);
+
+   event = parse_eventstr(evstr, &domid, &handle);
+
+   switch(event) {
+      case EV_NEWFE:
+	 if(new_tpmif(domid, handle) == NULL) {
+	    TPMBACK_ERR("Failed to create new tpm instance %u/%u\n", (unsigned int) domid, handle);
+	 }
+	 wake_up(&waitq);
+	 break;
+      case EV_STCHNG:
+	 if((tpmif = get_tpmif(domid, handle))) {
+	    frontend_changed(tpmif);
+	 } else {
+	    TPMBACK_DEBUG("Event Received for non-existant tpm! instance=%u/%u xenbus_event=%s\n", (unsigned int) domid, handle, evstr);
+	 }
+	 break;
+   }
+}
+
+/* Runs through the given path and creates events recursively
+ * for all of its children.
+ * @path - xenstore path to scan */
+static void generate_backend_events(const char* path)
+{
+   char* err;
+   int i, len;
+   char **dirs;
+   char *entry;
+
+   if((err = xenbus_ls(XBT_NIL, path, &dirs)) != NULL) {
+      free(err);
+      return;
+   }
+
+   for(i = 0; dirs[i] != NULL; ++i) {
+      len = strlen(path) + strlen(dirs[i]) + 2;
+      entry = malloc(len);
+      snprintf(entry, len, "%s/%s", path, dirs[i]);
+
+      /* Generate and handle event for the entry itself */
+      handle_backend_event(entry);
+
+      /* Do children */
+      generate_backend_events(entry);
+
+      /* Cleanup */
+      free(entry);
+      free(dirs[i]);
+   }
+   free(dirs);
+   return;
+}
+
+char* tpmback_get_uuid(domid_t domid, unsigned int handle)
+{
+   tpmif_t* tpmif;
+   if((tpmif = get_tpmif(domid, handle)) == NULL) {
+      TPMBACK_DEBUG("get_uuid() failed, %u/%u is an invalid frontend\n", (unsigned int) domid, handle);
+      return NULL;
+   }
+
+   return tpmif->uuid;
+}
+
+void tpmback_set_open_callback(void (*cb)(domid_t, unsigned int))
+{
+   gtpmdev.open_callback = cb;
+}
+void tpmback_set_close_callback(void (*cb)(domid_t, unsigned int))
+{
+   gtpmdev.close_callback = cb;
+}
+void tpmback_set_suspend_callback(void (*cb)(domid_t, unsigned int))
+{
+   gtpmdev.suspend_callback = cb;
+}
+void tpmback_set_resume_callback(void (*cb)(domid_t, unsigned int))
+{
+   gtpmdev.resume_callback = cb;
+}
+
+static void event_listener(void)
+{
+   const char* bepath = "backend/vtpm";
+   char **path;
+   char* err;
+
+   /* Setup the backend device watch */
+   if((err = xenbus_watch_path_token(XBT_NIL, bepath, bepath, &gtpmdev.events)) != NULL) {
+      TPMBACK_ERR("xenbus_watch_path_token(%s) failed with error %s!\n", bepath, err);
+      free(err);
+      goto egress;
+   }
+
+   /* Check for any frontends that connected before we set the watch.
+    * This is almost guaranteed to happen if both domains are started
+    * immediatly one after the other.
+    * We do this by manually generating events on everything in the backend
+    * path */
+   generate_backend_events(bepath);
+
+   /* Wait and listen for changes in frontend connections */
+   while(1) {
+      path = xenbus_wait_for_watch_return(&gtpmdev.events);
+
+      /*If quit flag was set then exit */
+      if(gtpmdev.flags & TPMIF_CLOSED) {
+	 TPMBACK_DEBUG("listener thread got quit event. Exiting..\n");
+	 free(path);
+	 break;
+      }
+      handle_backend_event(*path);
+      free(path);
+
+   }
+
+   if((err = xenbus_unwatch_path_token(XBT_NIL, bepath, bepath)) != NULL) {
+      free(err);
+   }
+egress:
+   return;
+}
+
+void event_thread(void* p) {
+   event_listener();
+}
+
+void init_tpmback(char** exclusive_uuids)
+{
+   if(!globalinit) {
+      init_waitqueue_head(&waitq);
+      globalinit = 1;
+   }
+   printk("============= Init TPM BACK ================\n");
+   gtpmdev.tpmlist = malloc(sizeof(tpmif_t*) * DEF_ARRAY_SIZE);
+   gtpmdev.num_alloc = DEF_ARRAY_SIZE;
+   gtpmdev.num_tpms = 0;
+   gtpmdev.flags = 0;
+   gtpmdev.exclusive_uuids = exclusive_uuids;
+
+   gtpmdev.open_callback = gtpmdev.close_callback = NULL;
+   gtpmdev.suspend_callback = gtpmdev.resume_callback = NULL;
+
+   eventthread = create_thread("tpmback-listener", event_thread, NULL);
+
+}
+
+void shutdown_tpmback(void)
+{
+   /* Disable callbacks */
+   gtpmdev.open_callback = gtpmdev.close_callback = NULL;
+   gtpmdev.suspend_callback = gtpmdev.resume_callback = NULL;
+
+   TPMBACK_LOG("Shutting down tpm backend\n");
+   /* Set the quit flag */
+   gtpmdev.flags = TPMIF_CLOSED;
+
+   //printk("num tpms is %d\n", gtpmdev.num_tpms);
+   /*Free all backend instances */
+   while(gtpmdev.num_tpms) {
+      free_tpmif(gtpmdev.tpmlist[0]);
+   }
+   free(gtpmdev.tpmlist);
+   gtpmdev.tpmlist = NULL;
+   gtpmdev.num_alloc = 0;
+
+   /* Wake up anyone possibly waiting on the device and let them exit */
+   wake_up(&waitq);
+   schedule();
+}
+
+inline void init_tpmcmd(tpmcmd_t* tpmcmd, domid_t domid, unsigned int handle, char* uuid)
+{
+   tpmcmd->domid = domid;
+   tpmcmd->handle = handle;
+   tpmcmd->uuid = uuid;
+   tpmcmd->req = NULL;
+   tpmcmd->req_len = 0;
+   tpmcmd->resp = NULL;
+   tpmcmd->resp_len = 0;
+}
+
+tpmcmd_t* get_request(tpmif_t* tpmif) {
+   tpmcmd_t* cmd;
+   tpmif_tx_request_t* tx;
+   int offset;
+   int tocopy;
+   int i;
+   uint32_t domid;
+   int flags;
+
+   local_irq_save(flags);
+
+   /* Allocate the cmd object to hold the data */
+   if((cmd = malloc(sizeof(*cmd))) == NULL) {
+      goto error;
+   }
+   init_tpmcmd(cmd, tpmif->domid, tpmif->handle, tpmif->uuid);
+
+   tx = &tpmif->tx->ring[0].req;
+   cmd->req_len = tx->size;
+   /* Allocate the buffer */
+   if(cmd->req_len) {
+      if((cmd->req = malloc(cmd->req_len)) == NULL) {
+	 goto error;
+      }
+   }
+   /* Copy the bits from the shared pages */
+   offset = 0;
+   for(i = 0; i < TPMIF_TX_RING_SIZE && offset < cmd->req_len; ++i) {
+      tx = &tpmif->tx->ring[i].req;
+
+      /* Map the page with the data */
+      domid = (uint32_t)tpmif->domid;
+      if((tpmif->pages[i] = gntmap_map_grant_refs(&gtpmdev.map, 1, &domid, 0, &tx->ref, PROT_READ)) == NULL) {
+	 TPMBACK_ERR("%u/%u Unable to map shared page during read!\n", (unsigned int) tpmif->domid, tpmif->handle);
+	 goto error;
+      }
+
+      /* do the copy now */
+      tocopy = min(cmd->req_len - offset, PAGE_SIZE);
+      memcpy(&cmd->req[offset], tpmif->pages[i], tocopy);
+      offset += tocopy;
+
+      /* release the page */
+      gntmap_munmap(&gtpmdev.map, (unsigned long)tpmif->pages[i], 1);
+
+   }
+
+#ifdef TPMBACK_PRINT_DEBUG
+   TPMBACK_DEBUG("Received Tpm Command from %u/%u of size %u", (unsigned int) tpmif->domid, tpmif->handle, cmd->req_len);
+   for(i = 0; i < cmd->req_len; ++i) {
+      if (!(i % 30)) {
+	 TPMBACK_DEBUG_MORE("\n");
+      }
+      TPMBACK_DEBUG_MORE("%02hhX ", cmd->req[i]);
+   }
+   TPMBACK_DEBUG_MORE("\n\n");
+#endif
+
+   local_irq_restore(flags);
+   return cmd;
+error:
+   if(cmd != NULL) {
+      if (cmd->req != NULL) {
+	 free(cmd->req);
+	 cmd->req = NULL;
+      }
+      free(cmd);
+      cmd = NULL;
+   }
+   local_irq_restore(flags);
+   return NULL;
+
+}
+
+void send_response(tpmcmd_t* cmd, tpmif_t* tpmif)
+{
+   tpmif_tx_request_t* tx;
+   int offset;
+   int i;
+   uint32_t domid;
+   int tocopy;
+   int flags;
+
+   local_irq_save(flags);
+
+   tx = &tpmif->tx->ring[0].req;
+   tx->size = cmd->resp_len;
+
+   offset = 0;
+   for(i = 0; i < TPMIF_TX_RING_SIZE && offset < cmd->resp_len; ++i) {
+      tx = &tpmif->tx->ring[i].req;
+
+      /* Map the page with the data */
+      domid = (uint32_t)tpmif->domid;
+      if((tpmif->pages[i] = gntmap_map_grant_refs(&gtpmdev.map, 1, &domid, 0, &tx->ref, PROT_WRITE)) == NULL) {
+	 TPMBACK_ERR("%u/%u Unable to map shared page during write!\n", (unsigned int) tpmif->domid, tpmif->handle);
+	 goto error;
+      }
+
+      /* do the copy now */
+      tocopy = min(cmd->resp_len - offset, PAGE_SIZE);
+      memcpy(tpmif->pages[i], &cmd->resp[offset], tocopy);
+      offset += tocopy;
+
+      /* release the page */
+      gntmap_munmap(&gtpmdev.map, (unsigned long)tpmif->pages[i], 1);
+
+   }
+
+#ifdef TPMBACK_PRINT_DEBUG
+   TPMBACK_DEBUG("Sent response to %u/%u of size %u", (unsigned int) tpmif->domid, tpmif->handle, cmd->resp_len);
+   for(i = 0; i < cmd->resp_len; ++i) {
+      if (!(i % 30)) {
+	 TPMBACK_DEBUG_MORE("\n");
+      }
+      TPMBACK_DEBUG_MORE("%02hhX ", cmd->resp[i]);
+   }
+   TPMBACK_DEBUG_MORE("\n\n");
+#endif
+   /* clear the ready flag and send the event channel notice to the frontend */
+   tpmif_req_finished(tpmif);
+   notify_remote_via_evtchn(tpmif->evtchn);
+error:
+   local_irq_restore(flags);
+   return;
+}
+
+tpmcmd_t* tpmback_req_any(void)
+{
+   int i;
+   /* Block until something has a request */
+   wait_event(waitq, (gtpmdev.flags & (TPMIF_REQ_READY | TPMIF_CLOSED)));
+
+   /* Check if were shutting down */
+   if(gtpmdev.flags & TPMIF_CLOSED) {
+      /* if something was waiting for us to give up the queue so it can shutdown, let it finish */
+      schedule();
+      return NULL;
+   }
+
+   for(i = 0; i < gtpmdev.num_tpms; ++i) {
+      if(gtpmdev.tpmlist[i]->flags & TPMIF_REQ_READY) {
+	 return get_request(gtpmdev.tpmlist[i]);
+      }
+   }
+
+   TPMBACK_ERR("backend request ready flag was set but no interfaces were actually ready\n");
+   return NULL;
+}
+
+tpmcmd_t* tpmback_req(domid_t domid, unsigned int handle)
+{
+   tpmif_t* tpmif;
+   tpmif = get_tpmif(domid, handle);
+   if(tpmif == NULL) {
+      return NULL;
+   }
+
+   wait_event(waitq, (tpmif->flags & (TPMIF_REQ_READY | TPMIF_CLOSED) || gtpmdev.flags & TPMIF_CLOSED));
+
+   /* Check if were shutting down */
+   if(tpmif->flags & TPMIF_CLOSED || gtpmdev.flags & TPMIF_CLOSED) {
+      /* if something was waiting for us to give up the queue so it can free this instance, let it finish */
+      schedule();
+      return NULL;
+   }
+
+   return get_request(tpmif);
+}
+
+void tpmback_resp(tpmcmd_t* tpmcmd)
+{
+   tpmif_t* tpmif;
+
+   /* Get the associated interface, if it doesnt exist then just quit */
+   tpmif = get_tpmif(tpmcmd->domid, tpmcmd->handle);
+   if(tpmif == NULL) {
+      TPMBACK_ERR("Tried to send a reponse to non existant frontend %u/%u\n", (unsigned int) tpmcmd->domid, tpmcmd->handle);
+      goto end;
+   }
+
+   if(!(tpmif->flags & TPMIF_REQ_READY)) {
+      TPMBACK_ERR("Tried to send response to a frontend that was not waiting for one %u/%u\n", (unsigned int) tpmcmd->domid, tpmcmd->handle);
+      goto end;
+   }
+
+   /* Send response to frontend */
+   send_response(tpmcmd, tpmif);
+
+end:
+   if(tpmcmd->req != NULL) {
+      free(tpmcmd->req);
+   }
+   free(tpmcmd);
+   return;
+}
+
+int tpmback_wait_for_frontend_connect(domid_t *domid, unsigned int *handle)
+{
+   tpmif_t* tpmif;
+   int flags;
+   wait_event(waitq, ((gtpmdev.num_tpms > 0) || gtpmdev.flags & TPMIF_CLOSED));
+   if(gtpmdev.flags & TPMIF_CLOSED) {
+      return -1;
+   }
+   local_irq_save(flags);
+   tpmif = gtpmdev.tpmlist[0];
+   *domid = tpmif->domid;
+   *handle = tpmif->handle;
+   local_irq_restore(flags);
+
+   return 0;
+}
+
+int tpmback_num_frontends(void)
+{
+   return gtpmdev.num_tpms;
+}
diff --git a/extras/mini-os/tpmfront.c b/extras/mini-os/tpmfront.c
new file mode 100644
index 0000000..a2f9175
--- /dev/null
+++ b/extras/mini-os/tpmfront.c
@@ -0,0 +1,617 @@
+/*
+ * Copyright (c) 2010-2012 United States Government, as represented by
+ * the Secretary of Defense.  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 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.
+ *
+ * Based upon the files:
+ *  drivers/char/tpm/tpm_vtpm.c
+ *  drivers/char/tpm/tpm_xen.c
+ * from the Linux kernel, which are Copyright (C) 2006 IBM Corporation
+ */
+#include <mini-os/os.h>
+#include <mini-os/xenbus.h>
+#include <mini-os/xmalloc.h>
+#include <mini-os/events.h>
+#include <mini-os/wait.h>
+#include <mini-os/gnttab.h>
+#include <xen/io/xenbus.h>
+#include <xen/io/tpmif.h>
+#include <mini-os/tpmfront.h>
+#include <fcntl.h>
+
+//#define TPMFRONT_PRINT_DEBUG
+#ifdef TPMFRONT_PRINT_DEBUG
+#define TPMFRONT_DEBUG(fmt,...) printk("Tpmfront:Debug("__FILE__":%d) " fmt, __LINE__, ##__VA_ARGS__)
+#define TPMFRONT_DEBUG_MORE(fmt,...) printk(fmt, ##__VA_ARGS__)
+#else
+#define TPMFRONT_DEBUG(fmt,...)
+#endif
+#define TPMFRONT_ERR(fmt,...) printk("Tpmfront:Error " fmt, ##__VA_ARGS__)
+#define TPMFRONT_LOG(fmt,...) printk("Tpmfront:Info " fmt, ##__VA_ARGS__)
+
+#define min(a,b) (((a) < (b)) ? (a) : (b))
+
+void tpmfront_handler(evtchn_port_t port, struct pt_regs *regs, void *data) {
+   struct tpmfront_dev* dev = (struct tpmfront_dev*) data;
+   /*If we get a response when we didnt make a request, just ignore it */
+   if(!dev->waiting) {
+      return;
+   }
+
+   dev->waiting = 0;
+#ifdef HAVE_LIBC
+   if(dev->fd >= 0) {
+      files[dev->fd].read = 1;
+   }
+#endif
+   wake_up(&dev->waitq);
+}
+
+static int publish_xenbus(struct tpmfront_dev* dev) {
+   xenbus_transaction_t xbt;
+   int retry;
+   char* err;
+   /* Write the grant reference and event channel to xenstore */
+again:
+   if((err = xenbus_transaction_start(&xbt))) {
+      TPMFRONT_ERR("Unable to start xenbus transaction, error was %s\n", err);
+      free(err);
+      return -1;
+   }
+
+   if((err = xenbus_printf(xbt, dev->nodename, "ring-ref", "%u", (unsigned int) dev->ring_ref))) {
+      TPMFRONT_ERR("Unable to write %s/ring-ref, error was %s\n", dev->nodename, err);
+      free(err);
+      goto abort_transaction;
+   }
+
+   if((err = xenbus_printf(xbt, dev->nodename, "event-channel", "%u", (unsigned int) dev->evtchn))) {
+      TPMFRONT_ERR("Unable to write %s/event-channel, error was %s\n", dev->nodename, err);
+      free(err);
+      goto abort_transaction;
+   }
+
+   if((err = xenbus_transaction_end(xbt, 0, &retry))) {
+      TPMFRONT_ERR("Unable to complete xenbus transaction, error was %s\n", err);
+      free(err);
+      return -1;
+   }
+   if(retry) {
+      goto again;
+   }
+
+   return 0;
+abort_transaction:
+   if((err = xenbus_transaction_end(xbt, 1, &retry))) {
+      free(err);
+   }
+   return -1;
+}
+
+static int wait_for_backend_connect(xenbus_event_queue* events, char* path)
+{
+   int state;
+
+   TPMFRONT_LOG("Waiting for backend connection..\n");
+   /* Wait for the backend to connect */
+   while(1) {
+      state = xenbus_read_integer(path);
+      if ( state < 0)
+	 state = XenbusStateUnknown;
+      switch(state) {
+	 /* Bad states, we quit with error */
+	 case XenbusStateUnknown:
+	 case XenbusStateClosing:
+	 case XenbusStateClosed:
+	    TPMFRONT_ERR("Unable to connect to backend\n");
+	    return -1;
+	 /* If backend is connected then break out of loop */
+	 case XenbusStateConnected:
+	    TPMFRONT_LOG("Backend Connected\n");
+	    return 0;
+	 default:
+	    xenbus_wait_for_watch(events);
+      }
+   }
+
+}
+
+static int wait_for_backend_closed(xenbus_event_queue* events, char* path)
+{
+   int state;
+
+   TPMFRONT_LOG("Waiting for backend to close..\n");
+   while(1) {
+      state = xenbus_read_integer(path);
+      if ( state < 0)
+	 state = XenbusStateUnknown;
+      switch(state) {
+	 case XenbusStateUnknown:
+	    TPMFRONT_ERR("Backend Unknown state, forcing shutdown\n");
+	    return -1;
+	 case XenbusStateClosed:
+	    TPMFRONT_LOG("Backend Closed\n");
+	    return 0;
+	 default:
+	    xenbus_wait_for_watch(events);
+      }
+   }
+
+}
+
+static int wait_for_backend_state_changed(struct tpmfront_dev* dev, XenbusState state) {
+   char* err;
+   int ret = 0;
+   xenbus_event_queue events = NULL;
+   char path[512];
+
+   snprintf(path, 512, "%s/state", dev->bepath);
+   /*Setup the watch to wait for the backend */
+   if((err = xenbus_watch_path_token(XBT_NIL, path, path, &events))) {
+      TPMFRONT_ERR("Could not set a watch on %s, error was %s\n", path, err);
+      free(err);
+      return -1;
+   }
+
+   /* Do the actual wait loop now */
+   switch(state) {
+      case XenbusStateConnected:
+	 ret = wait_for_backend_connect(&events, path);
+	 break;
+      case XenbusStateClosed:
+	 ret = wait_for_backend_closed(&events, path);
+	 break;
+      default:
+	 break;
+   }
+
+   if((err = xenbus_unwatch_path_token(XBT_NIL, path, path))) {
+      TPMFRONT_ERR("Unable to unwatch %s, error was %s, ignoring..\n", path, err);
+      free(err);
+   }
+   return ret;
+}
+
+static int tpmfront_connect(struct tpmfront_dev* dev)
+{
+   char* err;
+   /* Create shared page */
+   dev->tx = (tpmif_tx_interface_t*) alloc_page();
+   if(dev->tx == NULL) {
+      TPMFRONT_ERR("Unable to allocate page for shared memory\n");
+      goto error;
+   }
+   memset(dev->tx, 0, PAGE_SIZE);
+   dev->ring_ref = gnttab_grant_access(dev->bedomid, virt_to_mfn(dev->tx), 0);
+   TPMFRONT_DEBUG("grant ref is %lu\n", (unsigned long) dev->ring_ref);
+
+   /*Create event channel */
+   if(evtchn_alloc_unbound(dev->bedomid, tpmfront_handler, dev, &dev->evtchn)) {
+      TPMFRONT_ERR("Unable to allocate event channel\n");
+      goto error_postmap;
+   }
+   unmask_evtchn(dev->evtchn);
+   TPMFRONT_DEBUG("event channel is %lu\n", (unsigned long) dev->evtchn);
+
+   /* Write the entries to xenstore */
+   if(publish_xenbus(dev)) {
+      goto error_postevtchn;
+   }
+
+   /* Change state to connected */
+   dev->state = XenbusStateConnected;
+
+   /* Tell the backend that we are ready */
+   if((err = xenbus_printf(XBT_NIL, dev->nodename, "state", "%u", dev->state))) {
+      TPMFRONT_ERR("Unable to write to xenstore %s/state, value=%u", dev->nodename, XenbusStateConnected);
+      free(err);
+      goto error;
+   }
+
+   return 0;
+error_postevtchn:
+      mask_evtchn(dev->evtchn);
+      unbind_evtchn(dev->evtchn);
+error_postmap:
+      gnttab_end_access(dev->ring_ref);
+      free_page(dev->tx);
+error:
+   return -1;
+}
+
+struct tpmfront_dev* init_tpmfront(const char* _nodename)
+{
+   struct tpmfront_dev* dev;
+   const char* nodename;
+   char path[512];
+   char* value, *err;
+   unsigned long long ival;
+   int i;
+
+   printk("============= Init TPM Front ================\n");
+
+   dev = malloc(sizeof(struct tpmfront_dev));
+   memset(dev, 0, sizeof(struct tpmfront_dev));
+
+#ifdef HAVE_LIBC
+   dev->fd = -1;
+#endif
+
+   nodename = _nodename ? _nodename : "device/vtpm/0";
+   dev->nodename = strdup(nodename);
+
+   init_waitqueue_head(&dev->waitq);
+
+   /* Get backend domid */
+   snprintf(path, 512, "%s/backend-id", dev->nodename);
+   if((err = xenbus_read(XBT_NIL, path, &value))) {
+      TPMFRONT_ERR("Unable to read %s during tpmfront initialization! error = %s\n", path, err);
+      free(err);
+      goto error;
+   }
+   if(sscanf(value, "%llu", &ival) != 1) {
+      TPMFRONT_ERR("%s has non-integer value (%s)\n", path, value);
+      free(value);
+      goto error;
+   }
+   free(value);
+   dev->bedomid = ival;
+
+   /* Get backend xenstore path */
+   snprintf(path, 512, "%s/backend", dev->nodename);
+   if((err = xenbus_read(XBT_NIL, path, &dev->bepath))) {
+      TPMFRONT_ERR("Unable to read %s during tpmfront initialization! error = %s\n", path, err);
+      free(err);
+      goto error;
+   }
+
+   /* Create and publish grant reference and event channel */
+   if (tpmfront_connect(dev)) {
+      goto error;
+   }
+
+   /* Wait for backend to connect */
+   if( wait_for_backend_state_changed(dev, XenbusStateConnected)) {
+      goto error;
+   }
+
+   /* Allocate pages that will contain the messages */
+   dev->pages = malloc(sizeof(void*) * TPMIF_TX_RING_SIZE);
+   if(dev->pages == NULL) {
+      goto error;
+   }
+   memset(dev->pages, 0, sizeof(void*) * TPMIF_TX_RING_SIZE);
+   for(i = 0; i < TPMIF_TX_RING_SIZE; ++i) {
+      dev->pages[i] = (void*)alloc_page();
+      if(dev->pages[i] == NULL) {
+	 goto error;
+      }
+   }
+
+   TPMFRONT_LOG("Initialization Completed successfully\n");
+
+   return dev;
+
+error:
+   shutdown_tpmfront(dev);
+   return NULL;
+}
+void shutdown_tpmfront(struct tpmfront_dev* dev)
+{
+   char* err;
+   char path[512];
+   int i;
+   tpmif_tx_request_t* tx;
+   if(dev == NULL) {
+      return;
+   }
+   TPMFRONT_LOG("Shutting down tpmfront\n");
+   /* disconnect */
+   if(dev->state == XenbusStateConnected) {
+      dev->state = XenbusStateClosing;
+      //FIXME: Transaction for this?
+      /* Tell backend we are closing */
+      if((err = xenbus_printf(XBT_NIL, dev->nodename, "state", "%u", (unsigned int) dev->state))) {
+	 free(err);
+      }
+
+      /* Clean up xenstore entries */
+      snprintf(path, 512, "%s/event-channel", dev->nodename);
+      if((err = xenbus_rm(XBT_NIL, path))) {
+	 free(err);
+      }
+      snprintf(path, 512, "%s/ring-ref", dev->nodename);
+      if((err = xenbus_rm(XBT_NIL, path))) {
+	 free(err);
+      }
+
+      /* Tell backend we are closed */
+      dev->state = XenbusStateClosed;
+      if((err = xenbus_printf(XBT_NIL, dev->nodename, "state", "%u", (unsigned int) dev->state))) {
+	 TPMFRONT_ERR("Unable to write to %s, error was %s", dev->nodename, err);
+	 free(err);
+      }
+
+      /* Wait for the backend to close and unmap shared pages, ignore any errors */
+      wait_for_backend_state_changed(dev, XenbusStateClosed);
+
+      /* Cleanup any shared pages */
+      if(dev->pages) {
+	 for(i = 0; i < TPMIF_TX_RING_SIZE; ++i) {
+	    if(dev->pages[i]) {
+	       tx = &dev->tx->ring[i].req;
+	       if(tx->ref != 0) {
+		  gnttab_end_access(tx->ref);
+	       }
+	       free_page(dev->pages[i]);
+	    }
+	 }
+	 free(dev->pages);
+      }
+
+      /* Close event channel and unmap shared page */
+      mask_evtchn(dev->evtchn);
+      unbind_evtchn(dev->evtchn);
+      gnttab_end_access(dev->ring_ref);
+
+      free_page(dev->tx);
+
+   }
+
+   /* Cleanup memory usage */
+   if(dev->respbuf) {
+      free(dev->respbuf);
+   }
+   if(dev->bepath) {
+      free(dev->bepath);
+   }
+   if(dev->nodename) {
+      free(dev->nodename);
+   }
+   free(dev);
+}
+
+int tpmfront_send(struct tpmfront_dev* dev, const uint8_t* msg, size_t length)
+{
+   int i;
+   tpmif_tx_request_t* tx = NULL;
+   /* Error Checking */
+   if(dev == NULL || dev->state != XenbusStateConnected) {
+      TPMFRONT_ERR("Tried to send message through disconnected frontend\n");
+      return -1;
+   }
+
+#ifdef TPMFRONT_PRINT_DEBUG
+   TPMFRONT_DEBUG("Sending Msg to backend size=%u", (unsigned int) length);
+   for(i = 0; i < length; ++i) {
+      if(!(i % 30)) {
+	 TPMFRONT_DEBUG_MORE("\n");
+      }
+      TPMFRONT_DEBUG_MORE("%02X ", msg[i]);
+   }
+   TPMFRONT_DEBUG_MORE("\n");
+#endif
+
+   /* Copy to shared pages now */
+   for(i = 0; length > 0 && i < TPMIF_TX_RING_SIZE; ++i) {
+      /* Share the page */
+      tx = &dev->tx->ring[i].req;
+      tx->unused = 0;
+      tx->addr = virt_to_mach(dev->pages[i]);
+      tx->ref = gnttab_grant_access(dev->bedomid, virt_to_mfn(dev->pages[i]), 0);
+      /* Copy the bits to the page */
+      tx->size = length > PAGE_SIZE ? PAGE_SIZE : length;
+      memcpy(dev->pages[i], &msg[i * PAGE_SIZE], tx->size);
+
+      /* Update counters */
+      length -= tx->size;
+   }
+   dev->waiting = 1;
+   dev->resplen = 0;
+#ifdef HAVE_LIBC
+   if(dev->fd >= 0) {
+      files[dev->fd].read = 0;
+      files[dev->fd].tpmfront.respgot = 0;
+      files[dev->fd].tpmfront.offset = 0;
+   }
+#endif
+   notify_remote_via_evtchn(dev->evtchn);
+   return 0;
+}
+int tpmfront_recv(struct tpmfront_dev* dev, uint8_t** msg, size_t *length)
+{
+   tpmif_tx_request_t* tx;
+   int i;
+   if(dev == NULL || dev->state != XenbusStateConnected) {
+      TPMFRONT_ERR("Tried to receive message from disconnected frontend\n");
+      return -1;
+   }
+   /*Wait for the response */
+   wait_event(dev->waitq, (!dev->waiting));
+
+   /* Initialize */
+   *msg = NULL;
+   *length = 0;
+
+   /* special case, just quit */
+   tx = &dev->tx->ring[0].req;
+   if(tx->size == 0 ) {
+       goto quit;
+   }
+   /* Get the total size */
+   tx = &dev->tx->ring[0].req;
+   for(i = 0; i < TPMIF_TX_RING_SIZE && tx->size > 0; ++i) {
+      tx = &dev->tx->ring[i].req;
+      *length += tx->size;
+   }
+   /* Alloc the buffer */
+   if(dev->respbuf) {
+      free(dev->respbuf);
+   }
+   *msg = dev->respbuf = malloc(*length);
+   dev->resplen = *length;
+   /* Copy the bits */
+   tx = &dev->tx->ring[0].req;
+   for(i = 0; i < TPMIF_TX_RING_SIZE && tx->size > 0; ++i) {
+      tx = &dev->tx->ring[i].req;
+      memcpy(&(*msg)[i * PAGE_SIZE], dev->pages[i], tx->size);
+      gnttab_end_access(tx->ref);
+      tx->ref = 0;
+   }
+#ifdef TPMFRONT_PRINT_DEBUG
+   TPMFRONT_DEBUG("Received response from backend size=%u", (unsigned int) *length);
+   for(i = 0; i < *length; ++i) {
+      if(!(i % 30)) {
+	 TPMFRONT_DEBUG_MORE("\n");
+      }
+      TPMFRONT_DEBUG_MORE("%02X ", (*msg)[i]);
+   }
+   TPMFRONT_DEBUG_MORE("\n");
+#endif
+#ifdef HAVE_LIBC
+   if(dev->fd >= 0) {
+      files[dev->fd].tpmfront.respgot = 1;
+   }
+#endif
+quit:
+   return 0;
+}
+
+int tpmfront_cmd(struct tpmfront_dev* dev, uint8_t* req, size_t reqlen, uint8_t** resp, size_t* resplen)
+{
+   int rc;
+   if((rc = tpmfront_send(dev, req, reqlen))) {
+      return rc;
+   }
+   if((rc = tpmfront_recv(dev, resp, resplen))) {
+      return rc;
+   }
+
+   return 0;
+}
+
+#ifdef HAVE_LIBC
+#include <errno.h>
+int tpmfront_open(struct tpmfront_dev* dev)
+{
+   /* Silently prevent multiple opens */
+   if(dev->fd != -1) {
+      return dev->fd;
+   }
+
+   dev->fd = alloc_fd(FTYPE_TPMFRONT);
+   printk("tpmfront_open(%s) -> %d\n", dev->nodename, dev->fd);
+   files[dev->fd].tpmfront.dev = dev;
+   files[dev->fd].tpmfront.offset = 0;
+   files[dev->fd].tpmfront.respgot = 0;
+   return dev->fd;
+}
+
+int tpmfront_posix_write(int fd, const uint8_t* buf, size_t count)
+{
+   int rc;
+   struct tpmfront_dev* dev;
+   dev = files[fd].tpmfront.dev;
+
+   if(count == 0) {
+      return 0;
+   }
+
+   /* Return an error if we are already processing a command */
+   if(dev->waiting) {
+      errno = EINPROGRESS;
+      return -1;
+   }
+   /* Send the command now */
+   if((rc = tpmfront_send(dev, buf, count)) != 0) {
+      errno = EIO;
+      return -1;
+   }
+   return count;
+}
+
+int tpmfront_posix_read(int fd, uint8_t* buf, size_t count)
+{
+   int rc;
+   uint8_t* dummybuf;
+   size_t dummysz;
+   struct tpmfront_dev* dev;
+
+   dev = files[fd].tpmfront.dev;
+
+   if(count == 0) {
+      return 0;
+   }
+
+   /* get the response if we haven't already */
+   if(files[dev->fd].tpmfront.respgot == 0) {
+      if ((rc = tpmfront_recv(dev, &dummybuf, &dummysz)) != 0) {
+	 errno = EIO;
+	 return -1;
+      }
+   }
+
+   /* handle EOF case */
+   if(files[dev->fd].tpmfront.offset >= dev->resplen) {
+      return 0;
+   }
+
+   /* Compute the number of bytes and do the copy operation */
+   if((rc = min(count, dev->resplen - files[dev->fd].tpmfront.offset)) != 0) {
+      memcpy(buf, dev->respbuf + files[dev->fd].tpmfront.offset, rc);
+      files[dev->fd].tpmfront.offset += rc;
+   }
+
+   return rc;
+}
+
+int tpmfront_posix_fstat(int fd, struct stat* buf)
+{
+   uint8_t* dummybuf;
+   size_t dummysz;
+   int rc;
+   struct tpmfront_dev* dev = files[fd].tpmfront.dev;
+
+   /* If we have a response waiting, then read it now from the backend
+    * so we can get its length*/
+   if(dev->waiting || (files[dev->fd].read == 1 && !files[dev->fd].tpmfront.respgot)) {
+      if ((rc = tpmfront_recv(dev, &dummybuf, &dummysz)) != 0) {
+	 errno = EIO;
+	 return -1;
+      }
+   }
+
+   buf->st_mode = O_RDWR;
+   buf->st_uid = 0;
+   buf->st_gid = 0;
+   buf->st_size = dev->resplen;
+   buf->st_atime = buf->st_mtime = buf->st_ctime = time(NULL);
+
+   return 0;
+}
+
+
+#endif
-- 
1.7.9.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 27 17:12:09 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Sep 2012 17:12:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1THHcx-0006KZ-Hg; Thu, 27 Sep 2012 17:11:55 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <matthew.fioravante@jhuapl.edu>) id 1THHcv-0006Jr-7P
	for xen-devel@lists.xen.org; Thu, 27 Sep 2012 17:11:53 +0000
Received: from [85.158.139.83:6368] by server-7.bemta-5.messagelabs.com id
	7F/01-00431-8D884605; Thu, 27 Sep 2012 17:11:52 +0000
X-Env-Sender: matthew.fioravante@jhuapl.edu
X-Msg-Ref: server-16.tower-182.messagelabs.com!1348765910!25090468!1
X-Originating-IP: [128.244.251.36]
X-SpamReason: No, hits=0.0 required=7.0 tests=UNPARSEABLE_RELAY
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1086 invoked from network); 27 Sep 2012 17:11:51 -0000
Received: from pilot.jhuapl.edu (HELO jhuapl.edu) (128.244.251.36)
	by server-16.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 27 Sep 2012 17:11:51 -0000
Received: from ([128.244.207.89])
	by pilot.jhuapl.edu with ESMTP with TLS id 63GHCH1.153802922;
	Thu, 27 Sep 2012 13:11:28 -0400
From: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
To: xen-devel@lists.xen.org, samuel.thibault@ens-lyon.org,
	Ian.Campbell@citrix.com
Date: Thu, 27 Sep 2012 13:09:58 -0400
Message-Id: <1348765802-11314-4-git-send-email-matthew.fioravante@jhuapl.edu>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <1348765802-11314-1-git-send-email-matthew.fioravante@jhuapl.edu>
References: <1348765802-11314-1-git-send-email-matthew.fioravante@jhuapl.edu>
Cc: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
Subject: [Xen-devel] [PATCH 04/11] Disable the mfn_is_ram() check,
	it doesn't work correctly on all 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

This patch disables the mfn_is_ram check in mini-os. The current check
is insufficient and fails on some systems with larger than 4gb memory.

Signed-off-by: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
Acked-by: Samuel Thibault <samuel.thibault@ens-lyon.org>

diff --git a/extras/mini-os/arch/x86/mm.c b/extras/mini-os/arch/x86/mm.c
index 80aceac..5813a08 100644
--- a/extras/mini-os/arch/x86/mm.c
+++ b/extras/mini-os/arch/x86/mm.c
@@ -850,6 +850,8 @@ unsigned long alloc_contig_pages(int order, unsigned int addr_bits)
 static long system_ram_end_mfn;
 int mfn_is_ram(unsigned long mfn)
 {
+   /* This is broken on systems with large ammounts of ram. Always return 0 for now */
+    return 0;
     /* very crude check if a given MFN is memory or not. Probably should
      * make this a little more sophisticated ;) */
     return (mfn <= system_ram_end_mfn) ? 1 : 0;
-- 
1.7.9.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 27 17:12:09 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Sep 2012 17:12:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1THHcx-0006KZ-Hg; Thu, 27 Sep 2012 17:11:55 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <matthew.fioravante@jhuapl.edu>) id 1THHcv-0006Jr-7P
	for xen-devel@lists.xen.org; Thu, 27 Sep 2012 17:11:53 +0000
Received: from [85.158.139.83:6368] by server-7.bemta-5.messagelabs.com id
	7F/01-00431-8D884605; Thu, 27 Sep 2012 17:11:52 +0000
X-Env-Sender: matthew.fioravante@jhuapl.edu
X-Msg-Ref: server-16.tower-182.messagelabs.com!1348765910!25090468!1
X-Originating-IP: [128.244.251.36]
X-SpamReason: No, hits=0.0 required=7.0 tests=UNPARSEABLE_RELAY
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1086 invoked from network); 27 Sep 2012 17:11:51 -0000
Received: from pilot.jhuapl.edu (HELO jhuapl.edu) (128.244.251.36)
	by server-16.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 27 Sep 2012 17:11:51 -0000
Received: from ([128.244.207.89])
	by pilot.jhuapl.edu with ESMTP with TLS id 63GHCH1.153802922;
	Thu, 27 Sep 2012 13:11:28 -0400
From: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
To: xen-devel@lists.xen.org, samuel.thibault@ens-lyon.org,
	Ian.Campbell@citrix.com
Date: Thu, 27 Sep 2012 13:09:58 -0400
Message-Id: <1348765802-11314-4-git-send-email-matthew.fioravante@jhuapl.edu>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <1348765802-11314-1-git-send-email-matthew.fioravante@jhuapl.edu>
References: <1348765802-11314-1-git-send-email-matthew.fioravante@jhuapl.edu>
Cc: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
Subject: [Xen-devel] [PATCH 04/11] Disable the mfn_is_ram() check,
	it doesn't work correctly on all 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

This patch disables the mfn_is_ram check in mini-os. The current check
is insufficient and fails on some systems with larger than 4gb memory.

Signed-off-by: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
Acked-by: Samuel Thibault <samuel.thibault@ens-lyon.org>

diff --git a/extras/mini-os/arch/x86/mm.c b/extras/mini-os/arch/x86/mm.c
index 80aceac..5813a08 100644
--- a/extras/mini-os/arch/x86/mm.c
+++ b/extras/mini-os/arch/x86/mm.c
@@ -850,6 +850,8 @@ unsigned long alloc_contig_pages(int order, unsigned int addr_bits)
 static long system_ram_end_mfn;
 int mfn_is_ram(unsigned long mfn)
 {
+   /* This is broken on systems with large ammounts of ram. Always return 0 for now */
+    return 0;
     /* very crude check if a given MFN is memory or not. Probably should
      * make this a little more sophisticated ;) */
     return (mfn <= system_ram_end_mfn) ? 1 : 0;
-- 
1.7.9.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 27 17:12:10 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Sep 2012 17:12:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1THHd1-0006ME-80; Thu, 27 Sep 2012 17:11:59 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <matthew.fioravante@jhuapl.edu>) id 1THHcz-0006Jn-AY
	for xen-devel@lists.xen.org; Thu, 27 Sep 2012 17:11:57 +0000
X-Env-Sender: matthew.fioravante@jhuapl.edu
X-Msg-Ref: server-9.tower-27.messagelabs.com!1348765909!8913845!1
X-Originating-IP: [128.244.251.36]
X-SpamReason: No, hits=0.0 required=7.0 tests=UNPARSEABLE_RELAY
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6327 invoked from network); 27 Sep 2012 17:11:50 -0000
Received: from pilot.jhuapl.edu (HELO jhuapl.edu) (128.244.251.36)
	by server-9.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 27 Sep 2012 17:11:50 -0000
Received: from ([128.244.207.89])
	by pilot.jhuapl.edu with ESMTP with TLS id 63GHCH1.153802924;
	Thu, 27 Sep 2012 13:11:28 -0400
From: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
To: xen-devel@lists.xen.org, samuel.thibault@ens-lyon.org,
	Ian.Campbell@citrix.com
Date: Thu, 27 Sep 2012 13:09:59 -0400
Message-Id: <1348765802-11314-5-git-send-email-matthew.fioravante@jhuapl.edu>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <1348765802-11314-1-git-send-email-matthew.fioravante@jhuapl.edu>
References: <1348765802-11314-1-git-send-email-matthew.fioravante@jhuapl.edu>
Cc: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
Subject: [Xen-devel] [PATCH 05/11] add CONFIG_XC conditional
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This patch adds a CONFIG_XC option to mini-os, to allow conditional
support for libxc for mini-os domains.

Signed-off-by: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
Acked-by: Samuel Thibault <samuel.thibault@ens-lyon.org>

diff --git a/extras/mini-os/Makefile b/extras/mini-os/Makefile
index c425f76..b4236e8 100644
--- a/extras/mini-os/Makefile
+++ b/extras/mini-os/Makefile
@@ -27,6 +27,7 @@ CONFIG_FBFRONT ?= y
 CONFIG_KBDFRONT ?= y
 CONFIG_CONSFRONT ?= y
 CONFIG_XENBUS ?= y
+CONFIG_XC ?=y
 CONFIG_LWIP ?= $(lwip)
 
 # Export config items as compiler directives
diff --git a/extras/mini-os/lib/sys.c b/extras/mini-os/lib/sys.c
index 7ddbbf8..6cb97b1 100644
--- a/extras/mini-os/lib/sys.c
+++ b/extras/mini-os/lib/sys.c
@@ -397,6 +397,7 @@ int close(int fd)
 	    return res;
 	}
 #endif
+#ifdef CONFIG_XC
 	case FTYPE_XC:
 	    minios_interface_close_fd(fd);
 	    return 0;
@@ -406,6 +407,7 @@ int close(int fd)
 	case FTYPE_GNTMAP:
 	    minios_gnttab_close_fd(fd);
 	    return 0;
+#endif
 #ifdef CONFIG_NETFRONT
 	case FTYPE_TAP:
 	    shutdown_netfront(files[fd].tap.dev);
@@ -1195,10 +1197,13 @@ void *mmap(void *start, size_t length, int prot, int flags, int fd, off_t offset
 
     if (fd == -1)
         return map_zero(n, 1);
+#ifdef CONFIG_XC
     else if (files[fd].type == FTYPE_XC) {
         unsigned long zero = 0;
         return map_frames_ex(&zero, n, 0, 0, 1, DOMID_SELF, NULL, 0);
-    } else if (files[fd].type == FTYPE_MEM) {
+    }
+#endif
+    else if (files[fd].type == FTYPE_MEM) {
         unsigned long first_mfn = offset >> PAGE_SHIFT;
         return map_frames_ex(&first_mfn, n, 0, 1, 1, DOMID_IO, NULL, _PAGE_PRESENT|_PAGE_RW);
     } else ASSERT(0);
-- 
1.7.9.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 27 17:12:10 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Sep 2012 17:12:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1THHd1-0006ME-80; Thu, 27 Sep 2012 17:11:59 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <matthew.fioravante@jhuapl.edu>) id 1THHcz-0006Jn-AY
	for xen-devel@lists.xen.org; Thu, 27 Sep 2012 17:11:57 +0000
X-Env-Sender: matthew.fioravante@jhuapl.edu
X-Msg-Ref: server-9.tower-27.messagelabs.com!1348765909!8913845!1
X-Originating-IP: [128.244.251.36]
X-SpamReason: No, hits=0.0 required=7.0 tests=UNPARSEABLE_RELAY
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6327 invoked from network); 27 Sep 2012 17:11:50 -0000
Received: from pilot.jhuapl.edu (HELO jhuapl.edu) (128.244.251.36)
	by server-9.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 27 Sep 2012 17:11:50 -0000
Received: from ([128.244.207.89])
	by pilot.jhuapl.edu with ESMTP with TLS id 63GHCH1.153802924;
	Thu, 27 Sep 2012 13:11:28 -0400
From: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
To: xen-devel@lists.xen.org, samuel.thibault@ens-lyon.org,
	Ian.Campbell@citrix.com
Date: Thu, 27 Sep 2012 13:09:59 -0400
Message-Id: <1348765802-11314-5-git-send-email-matthew.fioravante@jhuapl.edu>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <1348765802-11314-1-git-send-email-matthew.fioravante@jhuapl.edu>
References: <1348765802-11314-1-git-send-email-matthew.fioravante@jhuapl.edu>
Cc: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
Subject: [Xen-devel] [PATCH 05/11] add CONFIG_XC conditional
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This patch adds a CONFIG_XC option to mini-os, to allow conditional
support for libxc for mini-os domains.

Signed-off-by: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
Acked-by: Samuel Thibault <samuel.thibault@ens-lyon.org>

diff --git a/extras/mini-os/Makefile b/extras/mini-os/Makefile
index c425f76..b4236e8 100644
--- a/extras/mini-os/Makefile
+++ b/extras/mini-os/Makefile
@@ -27,6 +27,7 @@ CONFIG_FBFRONT ?= y
 CONFIG_KBDFRONT ?= y
 CONFIG_CONSFRONT ?= y
 CONFIG_XENBUS ?= y
+CONFIG_XC ?=y
 CONFIG_LWIP ?= $(lwip)
 
 # Export config items as compiler directives
diff --git a/extras/mini-os/lib/sys.c b/extras/mini-os/lib/sys.c
index 7ddbbf8..6cb97b1 100644
--- a/extras/mini-os/lib/sys.c
+++ b/extras/mini-os/lib/sys.c
@@ -397,6 +397,7 @@ int close(int fd)
 	    return res;
 	}
 #endif
+#ifdef CONFIG_XC
 	case FTYPE_XC:
 	    minios_interface_close_fd(fd);
 	    return 0;
@@ -406,6 +407,7 @@ int close(int fd)
 	case FTYPE_GNTMAP:
 	    minios_gnttab_close_fd(fd);
 	    return 0;
+#endif
 #ifdef CONFIG_NETFRONT
 	case FTYPE_TAP:
 	    shutdown_netfront(files[fd].tap.dev);
@@ -1195,10 +1197,13 @@ void *mmap(void *start, size_t length, int prot, int flags, int fd, off_t offset
 
     if (fd == -1)
         return map_zero(n, 1);
+#ifdef CONFIG_XC
     else if (files[fd].type == FTYPE_XC) {
         unsigned long zero = 0;
         return map_frames_ex(&zero, n, 0, 0, 1, DOMID_SELF, NULL, 0);
-    } else if (files[fd].type == FTYPE_MEM) {
+    }
+#endif
+    else if (files[fd].type == FTYPE_MEM) {
         unsigned long first_mfn = offset >> PAGE_SHIFT;
         return map_frames_ex(&first_mfn, n, 0, 1, 1, DOMID_IO, NULL, _PAGE_PRESENT|_PAGE_RW);
     } else ASSERT(0);
-- 
1.7.9.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 27 17:12:10 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Sep 2012 17:12:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1THHcy-0006Kn-AE; Thu, 27 Sep 2012 17:11:56 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <matthew.fioravante@jhuapl.edu>) id 1THHcv-0006Jx-Cl
	for xen-devel@lists.xen.org; Thu, 27 Sep 2012 17:11:53 +0000
Received: from [85.158.143.35:19238] by server-3.bemta-4.messagelabs.com id
	11/19-10986-8D884605; Thu, 27 Sep 2012 17:11:52 +0000
X-Env-Sender: matthew.fioravante@jhuapl.edu
X-Msg-Ref: server-16.tower-21.messagelabs.com!1348765910!13955185!1
X-Originating-IP: [128.244.251.36]
X-SpamReason: No, hits=1.4 required=7.0 tests=INFO_TLD,UNPARSEABLE_RELAY
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17717 invoked from network); 27 Sep 2012 17:11:51 -0000
Received: from pilot.jhuapl.edu (HELO jhuapl.edu) (128.244.251.36)
	by server-16.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 27 Sep 2012 17:11:51 -0000
Received: from ([128.244.207.89])
	by pilot.jhuapl.edu with ESMTP with TLS id 63GHCH1.153802918;
	Thu, 27 Sep 2012 13:11:28 -0400
From: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
To: xen-devel@lists.xen.org, samuel.thibault@ens-lyon.org,
	Ian.Campbell@citrix.com
Date: Thu, 27 Sep 2012 13:09:56 -0400
Message-Id: <1348765802-11314-2-git-send-email-matthew.fioravante@jhuapl.edu>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <1348765802-11314-1-git-send-email-matthew.fioravante@jhuapl.edu>
References: <1348765802-11314-1-git-send-email-matthew.fioravante@jhuapl.edu>
Cc: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
Subject: [Xen-devel] [PATCH 02/11] add posix io for blkfront
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This patch adds posix io support (read,write,lseek) to block devices
using blkfront.

Signed-off-by: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
Acked-by: Samuel Thibault <samuel.thibault@ens-lyon.org>

diff --git a/extras/mini-os/blkfront.c b/extras/mini-os/blkfront.c
index 74b8b26..66c65c9 100644
--- a/extras/mini-os/blkfront.c
+++ b/extras/mini-os/blkfront.c
@@ -392,6 +392,7 @@ void blkfront_aio(struct blkfront_aiocb *aiocbp, int write)
 static void blkfront_aio_cb(struct blkfront_aiocb *aiocbp, int ret)
 {
     aiocbp->data = (void*) 1;
+    aiocbp->aio_cb = NULL;
 }
 
 void blkfront_io(struct blkfront_aiocb *aiocbp, int write)
@@ -547,9 +548,150 @@ moretodo:
 #ifdef HAVE_LIBC
 int blkfront_open(struct blkfront_dev *dev)
 {
+    /* Silently prevent multiple opens */
+    if(dev->fd != -1) {
+       return dev->fd;
+    }
     dev->fd = alloc_fd(FTYPE_BLK);
     printk("blk_open(%s) -> %d\n", dev->nodename, dev->fd);
     files[dev->fd].blk.dev = dev;
+    files[dev->fd].blk.offset = 0;
     return dev->fd;
 }
+
+int blkfront_posix_rwop(int fd, uint8_t* buf, size_t count, int write)
+{
+   struct blkfront_dev* dev = files[fd].blk.dev;
+   off_t offset = files[fd].blk.offset;
+   struct blkfront_aiocb aiocb;
+   unsigned long long disksize = dev->info.sectors * dev->info.sector_size;
+   unsigned int blocksize = dev->info.sector_size;
+
+   int blknum;
+   int blkoff;
+   size_t bytes;
+   int rc = 0;
+   int alignedbuf = 0;
+   uint8_t* copybuf = NULL;
+
+   /* RW 0 bytes is just a NOP */
+   if(count == 0) {
+      return 0;
+   }
+   /* Check for NULL buffer */
+   if( buf == NULL ) {
+      errno = EFAULT;
+      return -1;
+   }
+
+   /* Write mode checks */
+   if(write) {
+      /*Make sure we have write permission */
+      if(dev->info.info & VDISK_READONLY || (dev->info.mode != O_RDWR  && dev->info.mode !=  O_WRONLY)) {
+         errno = EACCES;
+         return -1;
+      }
+      /*Make sure disk is big enough for this write */
+      if(offset + count > disksize) {
+         errno = ENOSPC;
+         return -1;
+      }
+   }
+   /* Read mode checks */
+   else
+   {
+      /*If the requested read is bigger than the disk, just
+       * read as much as we can until the end */
+      if(offset + count > disksize) {
+         count = offset >= disksize ? 0 : disksize - offset;
+      }
+   }
+   /* Determine which block to start at and which offset inside of it */
+   blknum = offset / blocksize;
+   blkoff = offset % blocksize;
+
+   /* Optimization: We need to check if buf is aligned to the sector size.
+    * This is somewhat tricky code. We have to add the blocksize - block offset
+    * because the first block may be a partial block and then for every subsequent
+    * block rw the buffer will be offset.*/
+   if(!((uintptr_t) (buf +(blocksize -  blkoff)) & (dev->info.sector_size-1))) {
+      alignedbuf = 1;
+   }
+
+   /* Setup aiocb block object */
+   aiocb.aio_dev = dev;
+   aiocb.aio_nbytes = blocksize;
+   aiocb.aio_offset = blknum * blocksize;
+   aiocb.aio_cb = NULL;
+   aiocb.data = NULL;
+
+   /* If our buffer is unaligned or its aligned but we will need to rw a partial block
+    * then a copy will have to be done */
+   if(!alignedbuf || blkoff != 0 || count % blocksize != 0) {
+      copybuf = _xmalloc(blocksize, dev->info.sector_size);
+   }
+
+   rc = count;
+   while(count > 0) {
+      /* determine how many bytes to read/write from/to the current block buffer */
+      bytes = count > (blocksize - blkoff) ? blocksize - blkoff : count;
+
+      /* read operation */
+      if(!write) {
+         if (alignedbuf && bytes >= blocksize) {
+            /* If aligned and were reading a whole block, just read right into buf */
+            aiocb.aio_buf = buf;
+            blkfront_read(&aiocb);
+         } else {
+            /* If not then we have to do a copy */
+            aiocb.aio_buf = copybuf;
+            blkfront_read(&aiocb);
+            memcpy(buf, &copybuf[blkoff], bytes);
+         }
+      }
+      /* Write operation */
+      else {
+         if(alignedbuf && bytes >= blocksize) {
+            /* If aligned and were writing a whole block, just write directly from buf */
+            aiocb.aio_buf = buf;
+            blkfront_write(&aiocb);
+         } else {
+            /* If not then we have to do a copy. */
+            aiocb.aio_buf = copybuf;
+            /* If we're writing a partial block, we need to read the current contents first
+             * so we don't overwrite the extra bits with garbage */
+            if(blkoff != 0 || bytes < blocksize) {
+               blkfront_read(&aiocb);
+            }
+            memcpy(&copybuf[blkoff], buf, bytes);
+            blkfront_write(&aiocb);
+         }
+      }
+      /* Will start at beginning of all remaining blocks */
+      blkoff = 0;
+
+      /* Increment counters and continue */
+      count -= bytes;
+      buf += bytes;
+      aiocb.aio_offset += blocksize;
+   }
+
+   free(copybuf);
+   files[fd].blk.offset += rc;
+   return rc;
+
+}
+
+int blkfront_posix_fstat(int fd, struct stat* buf)
+{
+   struct blkfront_dev* dev = files[fd].blk.dev;
+
+   buf->st_mode = dev->info.mode;
+   buf->st_uid = 0;
+   buf->st_gid = 0;
+   buf->st_size = dev->info.sectors * dev->info.sector_size;
+   buf->st_atime = buf->st_mtime = buf->st_ctime = time(NULL);
+
+   return 0;
+}
 #endif
diff --git a/extras/mini-os/include/blkfront.h b/extras/mini-os/include/blkfront.h
index 724137e..3528af9 100644
--- a/extras/mini-os/include/blkfront.h
+++ b/extras/mini-os/include/blkfront.h
@@ -28,7 +28,17 @@ struct blkfront_info
 };
 struct blkfront_dev *init_blkfront(char *nodename, struct blkfront_info *info);
 #ifdef HAVE_LIBC
+#include <sys/stat.h>
+/* POSIX IO functions:
+ * use blkfront_open() to get a file descriptor to the block device
+ * Don't use the other blkfront posix functions here directly, instead use
+ * read(), write(), lseek() and fstat() on the file descriptor
+ */
 int blkfront_open(struct blkfront_dev *dev);
+int blkfront_posix_rwop(int fd, uint8_t* buf, size_t count, int write);
+#define blkfront_posix_write(fd, buf, count) blkfront_posix_rwop(fd, (uint8_t*)buf, count, 1)
+#define blkfront_posix_read(fd, buf, count) blkfront_posix_rwop(fd, (uint8_t*)buf, count, 0)
+int blkfront_posix_fstat(int fd, struct stat* buf);
 #endif
 void blkfront_aio(struct blkfront_aiocb *aiocbp, int write);
 #define blkfront_aio_read(aiocbp) blkfront_aio(aiocbp, 0)
diff --git a/extras/mini-os/include/lib.h b/extras/mini-os/include/lib.h
index 1af2717..d4641b6 100644
--- a/extras/mini-os/include/lib.h
+++ b/extras/mini-os/include/lib.h
@@ -174,6 +174,7 @@ extern struct file {
 	} tap;
 	struct {
 	    struct blkfront_dev *dev;
+            off_t offset;
 	} blk;
 	struct {
 	    struct kbdfront_dev *dev;
diff --git a/extras/mini-os/lib/sys.c b/extras/mini-os/lib/sys.c
index a7d35d6..7ddbbf8 100644
--- a/extras/mini-os/lib/sys.c
+++ b/extras/mini-os/lib/sys.c
@@ -289,6 +289,11 @@ int read(int fd, void *buf, size_t nbytes)
 	    return ret * sizeof(union xenfb_in_event);
         }
 #endif
+#ifdef CONFIG_BLKFRONT
+        case FTYPE_BLK: {
+	    return blkfront_posix_read(fd, buf, nbytes);
+        }
+#endif
 	default:
 	    break;
     }
@@ -321,6 +326,10 @@ int write(int fd, const void *buf, size_t nbytes)
 	    netfront_xmit(files[fd].tap.dev, (void*) buf, nbytes);
 	    return nbytes;
 #endif
+#ifdef CONFIG_BLKFRONT
+	case FTYPE_BLK:
+	    return blkfront_posix_write(fd, buf, nbytes);
+#endif
 	default:
 	    break;
     }
@@ -331,8 +340,37 @@ int write(int fd, const void *buf, size_t nbytes)
 
 off_t lseek(int fd, off_t offset, int whence)
 {
-    errno = ESPIPE;
-    return (off_t) -1;
+    switch(files[fd].type) {
+#ifdef CONFIG_BLKFRONT
+       case FTYPE_BLK:
+	  switch (whence) {
+	     case SEEK_SET:
+		files[fd].file.offset = offset;
+		break;
+	     case SEEK_CUR:
+		files[fd].file.offset += offset;
+		break;
+	     case SEEK_END:
+		{
+		   struct stat st;
+		   int ret;
+		   ret = fstat(fd, &st);
+		   if (ret)
+		      return -1;
+		   files[fd].file.offset = st.st_size + offset;
+		   break;
+		}
+	     default:
+		errno = EINVAL;
+		return -1;
+	  }
+	  return files[fd].file.offset;
+	  break;
+#endif
+       default: /* Not implemented on this FTYPE */
+	  errno = ESPIPE;
+	  return (off_t) -1;
+    }
 }
 
 int fsync(int fd) {
@@ -445,6 +483,10 @@ int fstat(int fd, struct stat *buf)
 	    buf->st_ctime = time(NULL);
 	    return 0;
 	}
+#ifdef CONFIG_BLKFRONT
+	case FTYPE_BLK:
+	   return blkfront_posix_fstat(fd, buf);
+#endif
 	default:
 	    break;
     }
-- 
1.7.9.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 27 17:12:10 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Sep 2012 17:12:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1THHcy-0006Kn-AE; Thu, 27 Sep 2012 17:11:56 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <matthew.fioravante@jhuapl.edu>) id 1THHcv-0006Jx-Cl
	for xen-devel@lists.xen.org; Thu, 27 Sep 2012 17:11:53 +0000
Received: from [85.158.143.35:19238] by server-3.bemta-4.messagelabs.com id
	11/19-10986-8D884605; Thu, 27 Sep 2012 17:11:52 +0000
X-Env-Sender: matthew.fioravante@jhuapl.edu
X-Msg-Ref: server-16.tower-21.messagelabs.com!1348765910!13955185!1
X-Originating-IP: [128.244.251.36]
X-SpamReason: No, hits=1.4 required=7.0 tests=INFO_TLD,UNPARSEABLE_RELAY
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17717 invoked from network); 27 Sep 2012 17:11:51 -0000
Received: from pilot.jhuapl.edu (HELO jhuapl.edu) (128.244.251.36)
	by server-16.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 27 Sep 2012 17:11:51 -0000
Received: from ([128.244.207.89])
	by pilot.jhuapl.edu with ESMTP with TLS id 63GHCH1.153802918;
	Thu, 27 Sep 2012 13:11:28 -0400
From: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
To: xen-devel@lists.xen.org, samuel.thibault@ens-lyon.org,
	Ian.Campbell@citrix.com
Date: Thu, 27 Sep 2012 13:09:56 -0400
Message-Id: <1348765802-11314-2-git-send-email-matthew.fioravante@jhuapl.edu>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <1348765802-11314-1-git-send-email-matthew.fioravante@jhuapl.edu>
References: <1348765802-11314-1-git-send-email-matthew.fioravante@jhuapl.edu>
Cc: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
Subject: [Xen-devel] [PATCH 02/11] add posix io for blkfront
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This patch adds posix io support (read,write,lseek) to block devices
using blkfront.

Signed-off-by: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
Acked-by: Samuel Thibault <samuel.thibault@ens-lyon.org>

diff --git a/extras/mini-os/blkfront.c b/extras/mini-os/blkfront.c
index 74b8b26..66c65c9 100644
--- a/extras/mini-os/blkfront.c
+++ b/extras/mini-os/blkfront.c
@@ -392,6 +392,7 @@ void blkfront_aio(struct blkfront_aiocb *aiocbp, int write)
 static void blkfront_aio_cb(struct blkfront_aiocb *aiocbp, int ret)
 {
     aiocbp->data = (void*) 1;
+    aiocbp->aio_cb = NULL;
 }
 
 void blkfront_io(struct blkfront_aiocb *aiocbp, int write)
@@ -547,9 +548,150 @@ moretodo:
 #ifdef HAVE_LIBC
 int blkfront_open(struct blkfront_dev *dev)
 {
+    /* Silently prevent multiple opens */
+    if(dev->fd != -1) {
+       return dev->fd;
+    }
     dev->fd = alloc_fd(FTYPE_BLK);
     printk("blk_open(%s) -> %d\n", dev->nodename, dev->fd);
     files[dev->fd].blk.dev = dev;
+    files[dev->fd].blk.offset = 0;
     return dev->fd;
 }
+
+int blkfront_posix_rwop(int fd, uint8_t* buf, size_t count, int write)
+{
+   struct blkfront_dev* dev = files[fd].blk.dev;
+   off_t offset = files[fd].blk.offset;
+   struct blkfront_aiocb aiocb;
+   unsigned long long disksize = dev->info.sectors * dev->info.sector_size;
+   unsigned int blocksize = dev->info.sector_size;
+
+   int blknum;
+   int blkoff;
+   size_t bytes;
+   int rc = 0;
+   int alignedbuf = 0;
+   uint8_t* copybuf = NULL;
+
+   /* RW 0 bytes is just a NOP */
+   if(count == 0) {
+      return 0;
+   }
+   /* Check for NULL buffer */
+   if( buf == NULL ) {
+      errno = EFAULT;
+      return -1;
+   }
+
+   /* Write mode checks */
+   if(write) {
+      /*Make sure we have write permission */
+      if(dev->info.info & VDISK_READONLY || (dev->info.mode != O_RDWR  && dev->info.mode !=  O_WRONLY)) {
+         errno = EACCES;
+         return -1;
+      }
+      /*Make sure disk is big enough for this write */
+      if(offset + count > disksize) {
+         errno = ENOSPC;
+         return -1;
+      }
+   }
+   /* Read mode checks */
+   else
+   {
+      /*If the requested read is bigger than the disk, just
+       * read as much as we can until the end */
+      if(offset + count > disksize) {
+         count = offset >= disksize ? 0 : disksize - offset;
+      }
+   }
+   /* Determine which block to start at and which offset inside of it */
+   blknum = offset / blocksize;
+   blkoff = offset % blocksize;
+
+   /* Optimization: We need to check if buf is aligned to the sector size.
+    * This is somewhat tricky code. We have to add the blocksize - block offset
+    * because the first block may be a partial block and then for every subsequent
+    * block rw the buffer will be offset.*/
+   if(!((uintptr_t) (buf +(blocksize -  blkoff)) & (dev->info.sector_size-1))) {
+      alignedbuf = 1;
+   }
+
+   /* Setup aiocb block object */
+   aiocb.aio_dev = dev;
+   aiocb.aio_nbytes = blocksize;
+   aiocb.aio_offset = blknum * blocksize;
+   aiocb.aio_cb = NULL;
+   aiocb.data = NULL;
+
+   /* If our buffer is unaligned or its aligned but we will need to rw a partial block
+    * then a copy will have to be done */
+   if(!alignedbuf || blkoff != 0 || count % blocksize != 0) {
+      copybuf = _xmalloc(blocksize, dev->info.sector_size);
+   }
+
+   rc = count;
+   while(count > 0) {
+      /* determine how many bytes to read/write from/to the current block buffer */
+      bytes = count > (blocksize - blkoff) ? blocksize - blkoff : count;
+
+      /* read operation */
+      if(!write) {
+         if (alignedbuf && bytes >= blocksize) {
+            /* If aligned and were reading a whole block, just read right into buf */
+            aiocb.aio_buf = buf;
+            blkfront_read(&aiocb);
+         } else {
+            /* If not then we have to do a copy */
+            aiocb.aio_buf = copybuf;
+            blkfront_read(&aiocb);
+            memcpy(buf, &copybuf[blkoff], bytes);
+         }
+      }
+      /* Write operation */
+      else {
+         if(alignedbuf && bytes >= blocksize) {
+            /* If aligned and were writing a whole block, just write directly from buf */
+            aiocb.aio_buf = buf;
+            blkfront_write(&aiocb);
+         } else {
+            /* If not then we have to do a copy. */
+            aiocb.aio_buf = copybuf;
+            /* If we're writing a partial block, we need to read the current contents first
+             * so we don't overwrite the extra bits with garbage */
+            if(blkoff != 0 || bytes < blocksize) {
+               blkfront_read(&aiocb);
+            }
+            memcpy(&copybuf[blkoff], buf, bytes);
+            blkfront_write(&aiocb);
+         }
+      }
+      /* Will start at beginning of all remaining blocks */
+      blkoff = 0;
+
+      /* Increment counters and continue */
+      count -= bytes;
+      buf += bytes;
+      aiocb.aio_offset += blocksize;
+   }
+
+   free(copybuf);
+   files[fd].blk.offset += rc;
+   return rc;
+
+}
+
+int blkfront_posix_fstat(int fd, struct stat* buf)
+{
+   struct blkfront_dev* dev = files[fd].blk.dev;
+
+   buf->st_mode = dev->info.mode;
+   buf->st_uid = 0;
+   buf->st_gid = 0;
+   buf->st_size = dev->info.sectors * dev->info.sector_size;
+   buf->st_atime = buf->st_mtime = buf->st_ctime = time(NULL);
+
+   return 0;
+}
 #endif
diff --git a/extras/mini-os/include/blkfront.h b/extras/mini-os/include/blkfront.h
index 724137e..3528af9 100644
--- a/extras/mini-os/include/blkfront.h
+++ b/extras/mini-os/include/blkfront.h
@@ -28,7 +28,17 @@ struct blkfront_info
 };
 struct blkfront_dev *init_blkfront(char *nodename, struct blkfront_info *info);
 #ifdef HAVE_LIBC
+#include <sys/stat.h>
+/* POSIX IO functions:
+ * use blkfront_open() to get a file descriptor to the block device
+ * Don't use the other blkfront posix functions here directly, instead use
+ * read(), write(), lseek() and fstat() on the file descriptor
+ */
 int blkfront_open(struct blkfront_dev *dev);
+int blkfront_posix_rwop(int fd, uint8_t* buf, size_t count, int write);
+#define blkfront_posix_write(fd, buf, count) blkfront_posix_rwop(fd, (uint8_t*)buf, count, 1)
+#define blkfront_posix_read(fd, buf, count) blkfront_posix_rwop(fd, (uint8_t*)buf, count, 0)
+int blkfront_posix_fstat(int fd, struct stat* buf);
 #endif
 void blkfront_aio(struct blkfront_aiocb *aiocbp, int write);
 #define blkfront_aio_read(aiocbp) blkfront_aio(aiocbp, 0)
diff --git a/extras/mini-os/include/lib.h b/extras/mini-os/include/lib.h
index 1af2717..d4641b6 100644
--- a/extras/mini-os/include/lib.h
+++ b/extras/mini-os/include/lib.h
@@ -174,6 +174,7 @@ extern struct file {
 	} tap;
 	struct {
 	    struct blkfront_dev *dev;
+            off_t offset;
 	} blk;
 	struct {
 	    struct kbdfront_dev *dev;
diff --git a/extras/mini-os/lib/sys.c b/extras/mini-os/lib/sys.c
index a7d35d6..7ddbbf8 100644
--- a/extras/mini-os/lib/sys.c
+++ b/extras/mini-os/lib/sys.c
@@ -289,6 +289,11 @@ int read(int fd, void *buf, size_t nbytes)
 	    return ret * sizeof(union xenfb_in_event);
         }
 #endif
+#ifdef CONFIG_BLKFRONT
+        case FTYPE_BLK: {
+	    return blkfront_posix_read(fd, buf, nbytes);
+        }
+#endif
 	default:
 	    break;
     }
@@ -321,6 +326,10 @@ int write(int fd, const void *buf, size_t nbytes)
 	    netfront_xmit(files[fd].tap.dev, (void*) buf, nbytes);
 	    return nbytes;
 #endif
+#ifdef CONFIG_BLKFRONT
+	case FTYPE_BLK:
+	    return blkfront_posix_write(fd, buf, nbytes);
+#endif
 	default:
 	    break;
     }
@@ -331,8 +340,37 @@ int write(int fd, const void *buf, size_t nbytes)
 
 off_t lseek(int fd, off_t offset, int whence)
 {
-    errno = ESPIPE;
-    return (off_t) -1;
+    switch(files[fd].type) {
+#ifdef CONFIG_BLKFRONT
+       case FTYPE_BLK:
+	  switch (whence) {
+	     case SEEK_SET:
+		files[fd].file.offset = offset;
+		break;
+	     case SEEK_CUR:
+		files[fd].file.offset += offset;
+		break;
+	     case SEEK_END:
+		{
+		   struct stat st;
+		   int ret;
+		   ret = fstat(fd, &st);
+		   if (ret)
+		      return -1;
+		   files[fd].file.offset = st.st_size + offset;
+		   break;
+		}
+	     default:
+		errno = EINVAL;
+		return -1;
+	  }
+	  return files[fd].file.offset;
+	  break;
+#endif
+       default: /* Not implemented on this FTYPE */
+	  errno = ESPIPE;
+	  return (off_t) -1;
+    }
 }
 
 int fsync(int fd) {
@@ -445,6 +483,10 @@ int fstat(int fd, struct stat *buf)
 	    buf->st_ctime = time(NULL);
 	    return 0;
 	}
+#ifdef CONFIG_BLKFRONT
+	case FTYPE_BLK:
+	   return blkfront_posix_fstat(fd, buf);
+#endif
 	default:
 	    break;
     }
-- 
1.7.9.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 27 17:12:10 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Sep 2012 17:12:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1THHcx-0006KR-5f; Thu, 27 Sep 2012 17:11:55 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <matthew.fioravante@jhuapl.edu>) id 1THHcv-0006Jo-4D
	for xen-devel@lists.xen.org; Thu, 27 Sep 2012 17:11:53 +0000
Received: from [85.158.139.83:6374] by server-3.bemta-5.messagelabs.com id
	4E/98-16108-8D884605; Thu, 27 Sep 2012 17:11:52 +0000
X-Env-Sender: matthew.fioravante@jhuapl.edu
X-Msg-Ref: server-2.tower-182.messagelabs.com!1348765910!29589457!1
X-Originating-IP: [128.244.251.36]
X-SpamReason: No, hits=0.0 required=7.0 tests=UNPARSEABLE_RELAY
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1197 invoked from network); 27 Sep 2012 17:11:51 -0000
Received: from pilot.jhuapl.edu (HELO jhuapl.edu) (128.244.251.36)
	by server-2.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 27 Sep 2012 17:11:51 -0000
Received: from ([128.244.207.89])
	by pilot.jhuapl.edu with ESMTP with TLS id 63GHCH1.153802916;
	Thu, 27 Sep 2012 13:11:28 -0400
From: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
To: xen-devel@lists.xen.org, samuel.thibault@ens-lyon.org,
	Ian.Campbell@citrix.com
Date: Thu, 27 Sep 2012 13:09:55 -0400
Message-Id: <1348765802-11314-1-git-send-email-matthew.fioravante@jhuapl.edu>
X-Mailer: git-send-email 1.7.9.5
Cc: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
Subject: [Xen-devel] [PATCH 01/11] Add ioread/iowrite functions to mini-os
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This patch adds iowritexx() and ioreadxx() functions for interacting
with hardware memory to mini-os. The functions are available in a header
iorw.h

Signed-off-by: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
Acked-by: Samuel Thibault <samuel.thibault@ens-lyon.org>

diff --git a/extras/mini-os/arch/ia64/iorw.c b/extras/mini-os/arch/ia64/iorw.c
new file mode 100644
index 0000000..aa58807
--- /dev/null
+++ b/extras/mini-os/arch/ia64/iorw.c
@@ -0,0 +1,48 @@
+#include <mini-os/iorw.h>
+#include <mini-os/console.h>
+
+void iowrite8(volatile void* addr, uint8_t val)
+{
+   printk("iorw not implemented!!\n");
+   BUG();
+}
+void iowrite16(volatile void* addr, uint16_t val)
+{
+   printk("iorw not implemented!!\n");
+   BUG();
+}
+void iowrite32(volatile void* addr, uint32_t val)
+{
+   printk("iorw not implemented!!\n");
+   BUG();
+}
+void iowrite64(volatile void* addr, uint64_t val)
+{
+   printk("iorw not implemented!!\n");
+   BUG();
+}
+
+uint8_t ioread8(volatile void* addr)
+{
+   printk("iorw not implemented!!\n");
+   BUG();
+   return 0;
+}
+uint16_t ioread16(volatile void* addr)
+{
+   printk("iorw not implemented!!\n");
+   BUG();
+   return 0;
+}
+uint32_t ioread32(volatile void* addr)
+{
+   printk("iorw not implemented!!\n");
+   BUG();
+   return 0;
+}
+uint64_t ioread64(volatile void* addr)
+{
+   printk("iorw not implemented!!\n");
+   BUG();
+   return 0;
+}
diff --git a/extras/mini-os/arch/x86/iorw.c b/extras/mini-os/arch/x86/iorw.c
new file mode 100644
index 0000000..3080769
--- /dev/null
+++ b/extras/mini-os/arch/x86/iorw.c
@@ -0,0 +1,35 @@
+#include <mini-os/iorw.h>
+
+void iowrite8(volatile void* addr, uint8_t val)
+{
+   *((volatile uint8_t*)addr) = val;
+}
+void iowrite16(volatile void* addr, uint16_t val)
+{
+   *((volatile uint16_t*)addr) = val;
+}
+void iowrite32(volatile void* addr, uint32_t val)
+{
+   *((volatile uint32_t*)addr) = val;
+}
+void iowrite64(volatile void* addr, uint64_t val)
+{
+   *((volatile uint64_t*)addr) = val;
+}
+
+uint8_t ioread8(volatile void* addr)
+{
+   return *((volatile uint8_t*) addr);
+}
+uint16_t ioread16(volatile void* addr)
+{
+   return *((volatile uint16_t*) addr);
+}
+uint32_t ioread32(volatile void* addr)
+{
+   return *((volatile uint32_t*) addr);
+}
+uint64_t ioread64(volatile void* addr)
+{
+   return *((volatile uint64_t*) addr);
+}
diff --git a/extras/mini-os/include/iorw.h b/extras/mini-os/include/iorw.h
new file mode 100644
index 0000000..d5ec065
--- /dev/null
+++ b/extras/mini-os/include/iorw.h
@@ -0,0 +1,16 @@
+#ifndef MINIOS_IORW_H
+#define MINIOS_IORW_H
+
+#include <mini-os/types.h>
+
+void iowrite8(volatile void* addr, uint8_t val);
+void iowrite16(volatile void* addr, uint16_t val);
+void iowrite32(volatile void* addr, uint32_t val);
+void iowrite64(volatile void* addr, uint64_t val);
+
+uint8_t ioread8(volatile void* addr);
+uint16_t ioread16(volatile void* addr);
+uint32_t ioread32(volatile void* addr);
+uint64_t ioread64(volatile void* addr);
+
+#endif
-- 
1.7.9.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 27 17:12:10 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Sep 2012 17:12:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1THHcy-0006Kx-Mi; Thu, 27 Sep 2012 17:11:56 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <matthew.fioravante@jhuapl.edu>) id 1THHcv-0006Jr-KU
	for xen-devel@lists.xen.org; Thu, 27 Sep 2012 17:11:53 +0000
Received: from [85.158.139.83:6373] by server-7.bemta-5.messagelabs.com id
	BF/01-00431-8D884605; Thu, 27 Sep 2012 17:11:52 +0000
X-Env-Sender: matthew.fioravante@jhuapl.edu
X-Msg-Ref: server-2.tower-182.messagelabs.com!1348765910!29589456!1
X-Originating-IP: [128.244.251.36]
X-SpamReason: No, hits=0.0 required=7.0 tests=UNPARSEABLE_RELAY
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1198 invoked from network); 27 Sep 2012 17:11:51 -0000
Received: from pilot.jhuapl.edu (HELO jhuapl.edu) (128.244.251.36)
	by server-2.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 27 Sep 2012 17:11:51 -0000
Received: from ([128.244.207.89])
	by pilot.jhuapl.edu with ESMTP with TLS id 63GHCH1.153802926;
	Thu, 27 Sep 2012 13:11:28 -0400
From: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
To: xen-devel@lists.xen.org, samuel.thibault@ens-lyon.org,
	Ian.Campbell@citrix.com
Date: Thu, 27 Sep 2012 13:10:00 -0400
Message-Id: <1348765802-11314-6-git-send-email-matthew.fioravante@jhuapl.edu>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <1348765802-11314-1-git-send-email-matthew.fioravante@jhuapl.edu>
References: <1348765802-11314-1-git-send-email-matthew.fioravante@jhuapl.edu>
Cc: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
Subject: [Xen-devel] [PATCH 06/11] add select definition to sys/time.h when
	HAVE_LIBC is defined
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This patch adds the select function to sys/time.h when HAVE_LIBC is
defined, which is according to standard (see the select() manpage).

Signed-off-by: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
Acked-by: Samuel Thibault <samuel.thibault@ens-lyon.org>

diff --git a/extras/mini-os/include/sys/time.h b/extras/mini-os/include/sys/time.h
index d6623a4..3be3653 100644
--- a/extras/mini-os/include/sys/time.h
+++ b/extras/mini-os/include/sys/time.h
@@ -22,6 +22,7 @@
 
 #ifdef HAVE_LIBC
 #include_next <sys/time.h>
+
 #else
 struct timespec {
     time_t      tv_sec;
@@ -37,6 +38,10 @@ struct timeval {
 };
 
 int      gettimeofday(struct timeval *tv, void *tz);
+
+#endif
+#ifdef HAVE_LIBC
+#include <sys/select.h>
 #endif
 
 #endif /* _MINIOS_SYS_TIME_H_ */
-- 
1.7.9.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 27 17:12:10 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Sep 2012 17:12:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1THHcx-0006KR-5f; Thu, 27 Sep 2012 17:11:55 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <matthew.fioravante@jhuapl.edu>) id 1THHcv-0006Jo-4D
	for xen-devel@lists.xen.org; Thu, 27 Sep 2012 17:11:53 +0000
Received: from [85.158.139.83:6374] by server-3.bemta-5.messagelabs.com id
	4E/98-16108-8D884605; Thu, 27 Sep 2012 17:11:52 +0000
X-Env-Sender: matthew.fioravante@jhuapl.edu
X-Msg-Ref: server-2.tower-182.messagelabs.com!1348765910!29589457!1
X-Originating-IP: [128.244.251.36]
X-SpamReason: No, hits=0.0 required=7.0 tests=UNPARSEABLE_RELAY
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1197 invoked from network); 27 Sep 2012 17:11:51 -0000
Received: from pilot.jhuapl.edu (HELO jhuapl.edu) (128.244.251.36)
	by server-2.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 27 Sep 2012 17:11:51 -0000
Received: from ([128.244.207.89])
	by pilot.jhuapl.edu with ESMTP with TLS id 63GHCH1.153802916;
	Thu, 27 Sep 2012 13:11:28 -0400
From: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
To: xen-devel@lists.xen.org, samuel.thibault@ens-lyon.org,
	Ian.Campbell@citrix.com
Date: Thu, 27 Sep 2012 13:09:55 -0400
Message-Id: <1348765802-11314-1-git-send-email-matthew.fioravante@jhuapl.edu>
X-Mailer: git-send-email 1.7.9.5
Cc: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
Subject: [Xen-devel] [PATCH 01/11] Add ioread/iowrite functions to mini-os
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This patch adds iowritexx() and ioreadxx() functions for interacting
with hardware memory to mini-os. The functions are available in a header
iorw.h

Signed-off-by: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
Acked-by: Samuel Thibault <samuel.thibault@ens-lyon.org>

diff --git a/extras/mini-os/arch/ia64/iorw.c b/extras/mini-os/arch/ia64/iorw.c
new file mode 100644
index 0000000..aa58807
--- /dev/null
+++ b/extras/mini-os/arch/ia64/iorw.c
@@ -0,0 +1,48 @@
+#include <mini-os/iorw.h>
+#include <mini-os/console.h>
+
+void iowrite8(volatile void* addr, uint8_t val)
+{
+   printk("iorw not implemented!!\n");
+   BUG();
+}
+void iowrite16(volatile void* addr, uint16_t val)
+{
+   printk("iorw not implemented!!\n");
+   BUG();
+}
+void iowrite32(volatile void* addr, uint32_t val)
+{
+   printk("iorw not implemented!!\n");
+   BUG();
+}
+void iowrite64(volatile void* addr, uint64_t val)
+{
+   printk("iorw not implemented!!\n");
+   BUG();
+}
+
+uint8_t ioread8(volatile void* addr)
+{
+   printk("iorw not implemented!!\n");
+   BUG();
+   return 0;
+}
+uint16_t ioread16(volatile void* addr)
+{
+   printk("iorw not implemented!!\n");
+   BUG();
+   return 0;
+}
+uint32_t ioread32(volatile void* addr)
+{
+   printk("iorw not implemented!!\n");
+   BUG();
+   return 0;
+}
+uint64_t ioread64(volatile void* addr)
+{
+   printk("iorw not implemented!!\n");
+   BUG();
+   return 0;
+}
diff --git a/extras/mini-os/arch/x86/iorw.c b/extras/mini-os/arch/x86/iorw.c
new file mode 100644
index 0000000..3080769
--- /dev/null
+++ b/extras/mini-os/arch/x86/iorw.c
@@ -0,0 +1,35 @@
+#include <mini-os/iorw.h>
+
+void iowrite8(volatile void* addr, uint8_t val)
+{
+   *((volatile uint8_t*)addr) = val;
+}
+void iowrite16(volatile void* addr, uint16_t val)
+{
+   *((volatile uint16_t*)addr) = val;
+}
+void iowrite32(volatile void* addr, uint32_t val)
+{
+   *((volatile uint32_t*)addr) = val;
+}
+void iowrite64(volatile void* addr, uint64_t val)
+{
+   *((volatile uint64_t*)addr) = val;
+}
+
+uint8_t ioread8(volatile void* addr)
+{
+   return *((volatile uint8_t*) addr);
+}
+uint16_t ioread16(volatile void* addr)
+{
+   return *((volatile uint16_t*) addr);
+}
+uint32_t ioread32(volatile void* addr)
+{
+   return *((volatile uint32_t*) addr);
+}
+uint64_t ioread64(volatile void* addr)
+{
+   return *((volatile uint64_t*) addr);
+}
diff --git a/extras/mini-os/include/iorw.h b/extras/mini-os/include/iorw.h
new file mode 100644
index 0000000..d5ec065
--- /dev/null
+++ b/extras/mini-os/include/iorw.h
@@ -0,0 +1,16 @@
+#ifndef MINIOS_IORW_H
+#define MINIOS_IORW_H
+
+#include <mini-os/types.h>
+
+void iowrite8(volatile void* addr, uint8_t val);
+void iowrite16(volatile void* addr, uint16_t val);
+void iowrite32(volatile void* addr, uint32_t val);
+void iowrite64(volatile void* addr, uint64_t val);
+
+uint8_t ioread8(volatile void* addr);
+uint16_t ioread16(volatile void* addr);
+uint32_t ioread32(volatile void* addr);
+uint64_t ioread64(volatile void* addr);
+
+#endif
-- 
1.7.9.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 27 17:12:10 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Sep 2012 17:12:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1THHcy-0006Kx-Mi; Thu, 27 Sep 2012 17:11:56 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <matthew.fioravante@jhuapl.edu>) id 1THHcv-0006Jr-KU
	for xen-devel@lists.xen.org; Thu, 27 Sep 2012 17:11:53 +0000
Received: from [85.158.139.83:6373] by server-7.bemta-5.messagelabs.com id
	BF/01-00431-8D884605; Thu, 27 Sep 2012 17:11:52 +0000
X-Env-Sender: matthew.fioravante@jhuapl.edu
X-Msg-Ref: server-2.tower-182.messagelabs.com!1348765910!29589456!1
X-Originating-IP: [128.244.251.36]
X-SpamReason: No, hits=0.0 required=7.0 tests=UNPARSEABLE_RELAY
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1198 invoked from network); 27 Sep 2012 17:11:51 -0000
Received: from pilot.jhuapl.edu (HELO jhuapl.edu) (128.244.251.36)
	by server-2.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 27 Sep 2012 17:11:51 -0000
Received: from ([128.244.207.89])
	by pilot.jhuapl.edu with ESMTP with TLS id 63GHCH1.153802926;
	Thu, 27 Sep 2012 13:11:28 -0400
From: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
To: xen-devel@lists.xen.org, samuel.thibault@ens-lyon.org,
	Ian.Campbell@citrix.com
Date: Thu, 27 Sep 2012 13:10:00 -0400
Message-Id: <1348765802-11314-6-git-send-email-matthew.fioravante@jhuapl.edu>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <1348765802-11314-1-git-send-email-matthew.fioravante@jhuapl.edu>
References: <1348765802-11314-1-git-send-email-matthew.fioravante@jhuapl.edu>
Cc: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
Subject: [Xen-devel] [PATCH 06/11] add select definition to sys/time.h when
	HAVE_LIBC is defined
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This patch adds the select function to sys/time.h when HAVE_LIBC is
defined, which is according to standard (see the select() manpage).

Signed-off-by: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
Acked-by: Samuel Thibault <samuel.thibault@ens-lyon.org>

diff --git a/extras/mini-os/include/sys/time.h b/extras/mini-os/include/sys/time.h
index d6623a4..3be3653 100644
--- a/extras/mini-os/include/sys/time.h
+++ b/extras/mini-os/include/sys/time.h
@@ -22,6 +22,7 @@
 
 #ifdef HAVE_LIBC
 #include_next <sys/time.h>
+
 #else
 struct timespec {
     time_t      tv_sec;
@@ -37,6 +38,10 @@ struct timeval {
 };
 
 int      gettimeofday(struct timeval *tv, void *tz);
+
+#endif
+#ifdef HAVE_LIBC
+#include <sys/select.h>
 #endif
 
 #endif /* _MINIOS_SYS_TIME_H_ */
-- 
1.7.9.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 27 17:12:35 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Sep 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 1THHdW-0006fM-CC; Thu, 27 Sep 2012 17:12:30 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <matthew.fioravante@jhuapl.edu>) id 1THHdU-0006dr-F8
	for xen-devel@lists.xen.org; Thu, 27 Sep 2012 17:12:28 +0000
Received: from [85.158.138.51:32976] by server-10.bemta-3.messagelabs.com id
	79/00-02525-BF884605; Thu, 27 Sep 2012 17:12:27 +0000
X-Env-Sender: matthew.fioravante@jhuapl.edu
X-Msg-Ref: server-4.tower-174.messagelabs.com!1348765945!31735760!1
X-Originating-IP: [128.244.251.36]
X-SpamReason: No, hits=0.0 required=7.0 tests=UNPARSEABLE_RELAY
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2735 invoked from network); 27 Sep 2012 17:12:26 -0000
Received: from pilot.jhuapl.edu (HELO jhuapl.edu) (128.244.251.36)
	by server-4.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 27 Sep 2012 17:12:26 -0000
Received: from ([128.244.207.89])
	by pilot.jhuapl.edu with ESMTP with TLS id 63GHCH1.153803005;
	Thu, 27 Sep 2012 13:12:20 -0400
From: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
To: xen-devel@lists.xen.org,
	Ian.Campbell@citrix.com
Date: Thu, 27 Sep 2012 13:10:58 -0400
Message-Id: <1348765860-11359-1-git-send-email-matthew.fioravante@jhuapl.edu>
X-Mailer: git-send-email 1.7.9.5
Cc: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
Subject: [Xen-devel] [PATCH 09/11] add iomem support to 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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This patch adds a new option for xen config files for
directly mapping hardware io memory into a vm.

Signed-off-by: Matthew Fioravante <matthew.fioravante@jhuapl.edu>

diff --git a/docs/man/xl.cfg.pod.5 b/docs/man/xl.cfg.pod.5
index 013270d..428da21 100644
--- a/docs/man/xl.cfg.pod.5
+++ b/docs/man/xl.cfg.pod.5
@@ -496,6 +496,17 @@ is given in hexadecimal and may either a span e.g. C<2f8-2ff>
 It is recommended to use this option only for trusted VMs under
 administrator control.
 
+=item B<iomem=[ "IOMEM_START,NUM_PAGES", "IOMEM_START,NUM_PAGES", ... ]>
+
+Allow guest to access specific hardware I/O memory pages. B<IOMEM_START>
+is a physical page number. B<NUM_PAGES> is the number
+of pages beginning with B<START_PAGE> to allow access. Both values
+must be given in hexadecimal.
+
+It is recommended to use this option only for trusted VMs under
+administrator control.
+
+
 =item B<irqs=[ NUMBER, NUMBER, ... ]>
 
 Allow a guest to access specific physical IRQs.
diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index ef17f05..6cb586b 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -963,6 +963,24 @@ static void domcreate_launch_dm(libxl__egc *egc, libxl__multidev *multidev,
         }
     }
 
+    for (i = 0; i < d_config->b_info.num_iomem; i++) {
+        libxl_iomem_range *io = &d_config->b_info.iomem[i];
+
+        LOG(DEBUG, "dom%d iomem %"PRIx64"-%"PRIx64,
+            domid, io->start, io->start + io->number - 1);
+
+        ret = xc_domain_iomem_permission(CTX->xch, domid,
+                                          io->start, io->number, 1);
+        if ( ret<0 ) {
+            LOGE(ERROR,
+                 "failed give dom%d access to iomem range %"PRIx64"-%"PRIx64,
+                 domid, io->start, io->start + io->number - 1);
+            ret = ERROR_FAIL;
+        }
+    }
+
+
+
     for (i = 0; i < d_config->num_nics; i++) {
         /* We have to init the nic here, because we still haven't
          * called libxl_device_nic_add at this point, but qemu needs
diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
index 6d5c578..cf83c60 100644
--- a/tools/libxl/libxl_types.idl
+++ b/tools/libxl/libxl_types.idl
@@ -140,6 +140,11 @@ libxl_ioport_range = Struct("ioport_range", [
     ("number", uint32),
     ])
 
+libxl_iomem_range = Struct("iomem_range", [
+    ("start", uint64),
+    ("number", uint64),
+    ])
+
 libxl_vga_interface_info = Struct("vga_interface_info", [
     ("kind",    libxl_vga_interface_type),
     ])
@@ -284,6 +289,7 @@ libxl_domain_build_info = Struct("domain_build_info",[
 
     ("ioports",          Array(libxl_ioport_range, "num_ioports")),
     ("irqs",             Array(uint32, "num_irqs")),
+    ("iomem",            Array(libxl_iomem_range, "num_iomem")),
 
     ("u", KeyedUnion(None, libxl_domain_type, "type",
                 [("hvm", Struct(None, [("firmware",         string),
diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index 1627cac..fe8e925 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -574,8 +574,8 @@ static void parse_config_data(const char *config_source,
     long l;
     XLU_Config *config;
     XLU_ConfigList *cpus, *vbds, *nics, *pcis, *cvfbs, *cpuids;
-    XLU_ConfigList *ioports, *irqs;
-    int num_ioports, num_irqs;
+    XLU_ConfigList *ioports, *irqs, *iomem;
+    int num_ioports, num_irqs, num_iomem;
     int pci_power_mgmt = 0;
     int pci_msitranslate = 0;
     int pci_permissive = 0;
@@ -1005,6 +1005,30 @@ static void parse_config_data(const char *config_source,
         }
     }
 
+    if (!xlu_cfg_get_list(config, "iomem", &iomem, &num_iomem, 0)) {
+        b_info->num_iomem = num_iomem;
+        b_info->iomem = calloc(num_iomem, sizeof(*b_info->iomem));
+        if (b_info->iomem == NULL) {
+            fprintf(stderr, "unable to allocate memory for iomem\n");
+            exit(-1);
+        }
+        for (i = 0; i < num_iomem; i++) {
+            buf = xlu_cfg_get_listitem (iomem, i);
+            if (!buf) {
+                fprintf(stderr,
+                        "xl: Unable to get element %d in iomem list\n", i);
+                exit(1);
+            }
+            if(sscanf(buf, "%" SCNx64",%" SCNx64, &b_info->iomem[i].start, &b_info->iomem[i].number) != 2) {
+               fprintf(stderr,
+                       "xl: Invalid argument parsing iomem: %s\n", buf);
+               exit(1);
+            }
+        }
+    }
+
+
+
     if (!xlu_cfg_get_list (config, "disk", &vbds, 0, 0)) {
         d_config->num_disks = 0;
         d_config->disks = NULL;
-- 
1.7.9.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 27 17:12:35 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Sep 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 1THHdW-0006fM-CC; Thu, 27 Sep 2012 17:12:30 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <matthew.fioravante@jhuapl.edu>) id 1THHdU-0006dr-F8
	for xen-devel@lists.xen.org; Thu, 27 Sep 2012 17:12:28 +0000
Received: from [85.158.138.51:32976] by server-10.bemta-3.messagelabs.com id
	79/00-02525-BF884605; Thu, 27 Sep 2012 17:12:27 +0000
X-Env-Sender: matthew.fioravante@jhuapl.edu
X-Msg-Ref: server-4.tower-174.messagelabs.com!1348765945!31735760!1
X-Originating-IP: [128.244.251.36]
X-SpamReason: No, hits=0.0 required=7.0 tests=UNPARSEABLE_RELAY
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2735 invoked from network); 27 Sep 2012 17:12:26 -0000
Received: from pilot.jhuapl.edu (HELO jhuapl.edu) (128.244.251.36)
	by server-4.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 27 Sep 2012 17:12:26 -0000
Received: from ([128.244.207.89])
	by pilot.jhuapl.edu with ESMTP with TLS id 63GHCH1.153803005;
	Thu, 27 Sep 2012 13:12:20 -0400
From: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
To: xen-devel@lists.xen.org,
	Ian.Campbell@citrix.com
Date: Thu, 27 Sep 2012 13:10:58 -0400
Message-Id: <1348765860-11359-1-git-send-email-matthew.fioravante@jhuapl.edu>
X-Mailer: git-send-email 1.7.9.5
Cc: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
Subject: [Xen-devel] [PATCH 09/11] add iomem support to 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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This patch adds a new option for xen config files for
directly mapping hardware io memory into a vm.

Signed-off-by: Matthew Fioravante <matthew.fioravante@jhuapl.edu>

diff --git a/docs/man/xl.cfg.pod.5 b/docs/man/xl.cfg.pod.5
index 013270d..428da21 100644
--- a/docs/man/xl.cfg.pod.5
+++ b/docs/man/xl.cfg.pod.5
@@ -496,6 +496,17 @@ is given in hexadecimal and may either a span e.g. C<2f8-2ff>
 It is recommended to use this option only for trusted VMs under
 administrator control.
 
+=item B<iomem=[ "IOMEM_START,NUM_PAGES", "IOMEM_START,NUM_PAGES", ... ]>
+
+Allow guest to access specific hardware I/O memory pages. B<IOMEM_START>
+is a physical page number. B<NUM_PAGES> is the number
+of pages beginning with B<START_PAGE> to allow access. Both values
+must be given in hexadecimal.
+
+It is recommended to use this option only for trusted VMs under
+administrator control.
+
+
 =item B<irqs=[ NUMBER, NUMBER, ... ]>
 
 Allow a guest to access specific physical IRQs.
diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index ef17f05..6cb586b 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -963,6 +963,24 @@ static void domcreate_launch_dm(libxl__egc *egc, libxl__multidev *multidev,
         }
     }
 
+    for (i = 0; i < d_config->b_info.num_iomem; i++) {
+        libxl_iomem_range *io = &d_config->b_info.iomem[i];
+
+        LOG(DEBUG, "dom%d iomem %"PRIx64"-%"PRIx64,
+            domid, io->start, io->start + io->number - 1);
+
+        ret = xc_domain_iomem_permission(CTX->xch, domid,
+                                          io->start, io->number, 1);
+        if ( ret<0 ) {
+            LOGE(ERROR,
+                 "failed give dom%d access to iomem range %"PRIx64"-%"PRIx64,
+                 domid, io->start, io->start + io->number - 1);
+            ret = ERROR_FAIL;
+        }
+    }
+
+
+
     for (i = 0; i < d_config->num_nics; i++) {
         /* We have to init the nic here, because we still haven't
          * called libxl_device_nic_add at this point, but qemu needs
diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
index 6d5c578..cf83c60 100644
--- a/tools/libxl/libxl_types.idl
+++ b/tools/libxl/libxl_types.idl
@@ -140,6 +140,11 @@ libxl_ioport_range = Struct("ioport_range", [
     ("number", uint32),
     ])
 
+libxl_iomem_range = Struct("iomem_range", [
+    ("start", uint64),
+    ("number", uint64),
+    ])
+
 libxl_vga_interface_info = Struct("vga_interface_info", [
     ("kind",    libxl_vga_interface_type),
     ])
@@ -284,6 +289,7 @@ libxl_domain_build_info = Struct("domain_build_info",[
 
     ("ioports",          Array(libxl_ioport_range, "num_ioports")),
     ("irqs",             Array(uint32, "num_irqs")),
+    ("iomem",            Array(libxl_iomem_range, "num_iomem")),
 
     ("u", KeyedUnion(None, libxl_domain_type, "type",
                 [("hvm", Struct(None, [("firmware",         string),
diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index 1627cac..fe8e925 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -574,8 +574,8 @@ static void parse_config_data(const char *config_source,
     long l;
     XLU_Config *config;
     XLU_ConfigList *cpus, *vbds, *nics, *pcis, *cvfbs, *cpuids;
-    XLU_ConfigList *ioports, *irqs;
-    int num_ioports, num_irqs;
+    XLU_ConfigList *ioports, *irqs, *iomem;
+    int num_ioports, num_irqs, num_iomem;
     int pci_power_mgmt = 0;
     int pci_msitranslate = 0;
     int pci_permissive = 0;
@@ -1005,6 +1005,30 @@ static void parse_config_data(const char *config_source,
         }
     }
 
+    if (!xlu_cfg_get_list(config, "iomem", &iomem, &num_iomem, 0)) {
+        b_info->num_iomem = num_iomem;
+        b_info->iomem = calloc(num_iomem, sizeof(*b_info->iomem));
+        if (b_info->iomem == NULL) {
+            fprintf(stderr, "unable to allocate memory for iomem\n");
+            exit(-1);
+        }
+        for (i = 0; i < num_iomem; i++) {
+            buf = xlu_cfg_get_listitem (iomem, i);
+            if (!buf) {
+                fprintf(stderr,
+                        "xl: Unable to get element %d in iomem list\n", i);
+                exit(1);
+            }
+            if(sscanf(buf, "%" SCNx64",%" SCNx64, &b_info->iomem[i].start, &b_info->iomem[i].number) != 2) {
+               fprintf(stderr,
+                       "xl: Invalid argument parsing iomem: %s\n", buf);
+               exit(1);
+            }
+        }
+    }
+
+
+
     if (!xlu_cfg_get_list (config, "disk", &vbds, 0, 0)) {
         d_config->num_disks = 0;
         d_config->disks = NULL;
-- 
1.7.9.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 27 17:12:35 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Sep 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 1THHdX-0006g9-Ow; Thu, 27 Sep 2012 17:12:31 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <matthew.fioravante@jhuapl.edu>) id 1THHdW-0006eV-1R
	for xen-devel@lists.xen.org; Thu, 27 Sep 2012 17:12:30 +0000
Received: from [85.158.138.51:33014] by server-8.bemta-3.messagelabs.com id
	6B/6A-16337-DF884605; Thu, 27 Sep 2012 17:12:29 +0000
X-Env-Sender: matthew.fioravante@jhuapl.edu
X-Msg-Ref: server-6.tower-174.messagelabs.com!1348765945!24203542!1
X-Originating-IP: [128.244.251.36]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG,
	UNPARSEABLE_RELAY
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18339 invoked from network); 27 Sep 2012 17:12:26 -0000
Received: from pilot.jhuapl.edu (HELO jhuapl.edu) (128.244.251.36)
	by server-6.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 27 Sep 2012 17:12:26 -0000
Received: from ([128.244.207.89])
	by pilot.jhuapl.edu with ESMTP with TLS id 63GHCH1.153803009;
	Thu, 27 Sep 2012 13:12:20 -0400
From: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
To: xen-devel@lists.xen.org,
	Ian.Campbell@citrix.com
Date: Thu, 27 Sep 2012 13:11:00 -0400
Message-Id: <1348765860-11359-3-git-send-email-matthew.fioravante@jhuapl.edu>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <1348765860-11359-1-git-send-email-matthew.fioravante@jhuapl.edu>
References: <1348765860-11359-1-git-send-email-matthew.fioravante@jhuapl.edu>
Cc: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
Subject: [Xen-devel] [PATCH 11/11] add vtpm support to 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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This patch adds vtpm support to libxl. It adds vtpm parsing to config
files and 3 new xl commands:
vtpm-attach
vtpm-detach
vtpm-list

Signed-off-by: Matthew Fioravante <matthew.fioravante@jhuapl.edu>

diff --git a/docs/man/xl.cfg.pod.5 b/docs/man/xl.cfg.pod.5
index 428da21..edeeefa 100644
--- a/docs/man/xl.cfg.pod.5
+++ b/docs/man/xl.cfg.pod.5
@@ -298,6 +298,35 @@ 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>.
 
+=item B<vtpm=[ "VTPM_SPEC_STRING", "VTPM_SPEC_STRING", ...]>
+
+Specifies the virtual trusted platform module to be
+provided to the guest. Please see F<docs/misc/vtpm.txt>
+for more details.
+
+Each B<VTPM_SPEC_STRING> is a comma-separated list of C<KEY=VALUE>
+settings, from the following list:
+
+=over 4
+
+=item C<backend=DOMAIN>
+
+Specify the backend domain name of id. This value must be
+set if you are using the vtpm domain model. If this domain
+is a guest, the backend should be set to the vtpm domain name.
+If this domain is a vtpm, the backend should be set to the
+vtpm manager domain name. The default value is domain 0,
+which should be used if you are running the vtpm process model.
+
+=item C<uuid=UUID>
+
+Specify the uuid of this vtpm device. The uuid is used to uniquely
+identify the vtpm device. You can create one using the uuidgen
+program on unix systems. If left unspecified, a new uuid
+will be randomly generated every time the domain boots.
+
+=back
+
 =item B<vfb=[ "VFB_SPEC_STRING", "VFB_SPEC_STRING", ...]>
 
 Specifies the paravirtual framebuffer devices which should be supplied
diff --git a/docs/man/xl.pod.1 b/docs/man/xl.pod.1
index 25ce777..be9ad4c 100644
--- a/docs/man/xl.pod.1
+++ b/docs/man/xl.pod.1
@@ -1101,6 +1101,31 @@ List virtual network interfaces for a domain.
 
 =back
 
+=head2 VTPM DEVICES
+
+=over 4
+
+=item B<vtpm-attach> I<domain-id> I<vtpm-device>
+
+Creates a new vtpm device in the domain specified by I<domain-id>.
+I<vtpm-device> describes the device to attach, using the same format as the
+B<vtpm> string in the domain config file. See L<xl.cfg> for
+more information.
+
+=item B<vtpm-detach> I<domain-id> I<devid|uuid>
+
+Removes the vtpm device from the domain specified by I<domain-id>.
+I<devid> is the numeric device id given to the virtual trusted
+platform module device. You will need to run B<xl vtpm-list> to determine that number.
+Alternatively the I<uuid> of the vtpm can be used to
+select the virtual device to detach.
+
+=item B<vtpm-list> I<domain-id>
+
+List virtual trusted platform modules for a domain.
+
+=back
+
 =head1 PCI PASS-THROUGH
 
 =over 4
diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 1606eb1..f613487 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -1726,6 +1726,246 @@ out:
 }
 
 /******************************************************************************/
+int libxl__device_vtpm_setdefault(libxl__gc *gc, libxl_device_vtpm *vtpm)
+{
+   if(libxl_uuid_is_nil(&vtpm->uuid)) {
+      libxl_uuid_generate(&vtpm->uuid);
+   }
+   return 0;
+}
+
+static int libxl__device_from_vtpm(libxl__gc *gc, uint32_t domid,
+                                   libxl_device_vtpm *vtpm,
+                                   libxl__device *device)
+{
+   device->backend_devid   = vtpm->devid;
+   device->backend_domid   = vtpm->backend_domid;
+   device->backend_kind    = LIBXL__DEVICE_KIND_VTPM;
+   device->devid           = vtpm->devid;
+   device->domid           = domid;
+   device->kind            = LIBXL__DEVICE_KIND_VTPM;
+
+   return 0;
+}
+
+void libxl__device_vtpm_add(libxl__egc *egc, uint32_t domid,
+                           libxl_device_vtpm *vtpm,
+                           libxl__ao_device *aodev)
+{
+    STATE_AO_GC(aodev->ao);
+    flexarray_t *front;
+    flexarray_t *back;
+    libxl__device *device;
+    char *dompath, **l;
+    unsigned int nb, rc;
+
+    rc = libxl__device_vtpm_setdefault(gc, vtpm);
+    if (rc) goto out;
+
+    front = flexarray_make(16, 1);
+    if (!front) {
+        rc = ERROR_NOMEM;
+        goto out;
+    }
+    back = flexarray_make(16, 1);
+    if (!back) {
+        rc = ERROR_NOMEM;
+        goto out;
+    }
+
+    if(vtpm->devid == -1) {
+        if (!(dompath = libxl__xs_get_dompath(gc, domid))) {
+            rc = ERROR_FAIL;
+            goto out_free;
+        }
+        l = libxl__xs_directory(gc, XBT_NULL, libxl__sprintf(gc, "%s/device/vtpm", dompath), &nb);
+        if(l == NULL || nb == 0) {
+            vtpm->devid = 0;
+        } else {
+            vtpm->devid = strtoul(l[nb - 1], NULL, 10) + 1;
+        }
+    }
+
+    GCNEW(device);
+    rc = libxl__device_from_vtpm(gc, domid, vtpm, device);
+    if ( rc != 0 ) goto out_free;
+
+    flexarray_append(back, "frontend-id");
+    flexarray_append(back, libxl__sprintf(gc, "%d", domid));
+    flexarray_append(back, "online");
+    flexarray_append(back, "1");
+    flexarray_append(back, "state");
+    flexarray_append(back, libxl__sprintf(gc, "%d", 1));
+
+    flexarray_append(back, "uuid");
+    flexarray_append(back, libxl__sprintf(gc, LIBXL_UUID_FMT, LIBXL_UUID_BYTES(vtpm->uuid)));
+    flexarray_append(back, "instance"); /* MAYBE CAN GET RID OF THIS */
+    flexarray_append(back, "0");
+    flexarray_append(back, "pref_instance"); /* MAYBE CAN GET RID OF THIS */
+    flexarray_append(back, "0");
+    flexarray_append(back, "resume");
+    flexarray_append(back, "False");
+    flexarray_append(back, "ready"); /* MAYBE CAN GET RID OF THIS */
+    flexarray_append(back, "1");
+
+    flexarray_append(front, "backend-id");
+    flexarray_append(front, libxl__sprintf(gc, "%d", vtpm->backend_domid));
+    flexarray_append(front, "state");
+    flexarray_append(front, libxl__sprintf(gc, "%d", 1));
+    flexarray_append(front, "handle");
+    flexarray_append(front, libxl__sprintf(gc, "%d", vtpm->devid));
+
+    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));
+
+    aodev->dev = device;
+    aodev->action = DEVICE_CONNECT;
+    libxl__wait_device_connection(egc, aodev);
+
+    rc = 0;
+out_free:
+    flexarray_free(back);
+    flexarray_free(front);
+out:
+    aodev->rc = rc;
+    if(rc) aodev->callback(egc, aodev);
+    return;
+}
+
+static void libxl__device_vtpm_from_xs_fe(libxl__gc *gc,
+                                          const char* fe_path,
+                                          libxl_device_vtpm *vtpm)
+{
+   char* tmp;
+
+   memset(vtpm, 0, sizeof(*vtpm));
+   tmp = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/handle", fe_path));
+   if (tmp) {
+      vtpm->devid = atoi(tmp);
+   }
+   tmp = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/backend-id", fe_path));
+   if(tmp) {
+      vtpm->backend_domid = atoi(tmp);
+   }
+   tmp = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/uuid", fe_path));
+   if(tmp) {
+      libxl_uuid_from_string(&(vtpm->uuid), tmp);
+   }
+}
+
+libxl_device_vtpm *libxl_device_vtpm_list(libxl_ctx *ctx, uint32_t domid, int *num)
+{
+    GC_INIT(ctx);
+
+    libxl_device_vtpm* vtpms = NULL;
+    char* fe_path = NULL;
+    char** dir = NULL;
+    unsigned int ndirs = 0;
+
+    *num = 0;
+
+    fe_path = libxl__sprintf(gc, "%s/device/vtpm", libxl__xs_get_dompath(gc, domid));
+    dir = libxl__xs_directory(gc, XBT_NULL, fe_path, &ndirs);
+    if(dir) {
+       vtpms = malloc(sizeof(*vtpms) * ndirs);
+       libxl_device_vtpm* vtpm;
+       libxl_device_vtpm* end = vtpms + ndirs;
+       for(vtpm = vtpms; vtpm < end; ++vtpm, ++dir) {
+          const char* path = libxl__sprintf(gc, "%s/%s", fe_path, *dir);
+          libxl__device_vtpm_from_xs_fe(gc, path, vtpm);
+       }
+    }
+    *num = ndirs;
+
+    GC_FREE;
+    return vtpms;
+}
+
+int libxl_device_vtpm_getinfo(libxl_ctx *ctx, uint32_t domid,
+                               libxl_device_vtpm *vtpm, libxl_vtpminfo *vtpminfo)
+{
+    GC_INIT(ctx);
+    char *dompath, *vtpmpath;
+    char *val;
+    int rc = 0;
+
+    libxl_vtpminfo_init(vtpminfo);
+    dompath = libxl__xs_get_dompath(gc, domid);
+    vtpminfo->devid = vtpm->devid;
+
+    vtpmpath = libxl__sprintf(gc, "%s/device/vtpm/%d", dompath, vtpminfo->devid);
+    vtpminfo->backend = xs_read(ctx->xsh, XBT_NULL,
+                                libxl__sprintf(gc, "%s/backend", vtpmpath), NULL);
+    if (!vtpminfo->backend) {
+        goto err;
+    }
+    if(!libxl__xs_read(gc, XBT_NULL, vtpminfo->backend)) {
+       goto err;
+    }
+
+    val = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/backend-id", vtpmpath));
+    vtpminfo->backend_id = val ? strtoul(val, NULL, 10) : -1;
+    val = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/state", vtpmpath));
+    vtpminfo->state = val ? strtoul(val, NULL, 10) : -1;
+    val = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/event-channel", vtpmpath));
+    vtpminfo->evtch = val ? strtoul(val, NULL, 10) : -1;
+    val = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/ring-ref", vtpmpath));
+    vtpminfo->rref = val ? strtoul(val, NULL, 10) : -1;
+    vtpminfo->frontend = xs_read(ctx->xsh, XBT_NULL,
+                                 libxl__sprintf(gc, "%s/frontend", vtpminfo->backend), NULL);
+    val = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/frontend-id", vtpminfo->backend));
+    vtpminfo->frontend_id = val ? strtoul(val, NULL, 10) : -1;
+
+    val = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/uuid", vtpminfo->backend));
+    if(val == NULL) {
+       LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "%s/uuid does not exist!\n", vtpminfo->backend);
+       goto err;
+    }
+    if(libxl_uuid_from_string(&(vtpminfo->uuid), val)) {
+       LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "%s/uuid is a malformed uuid?? (%s) Probably a bug!\n", vtpminfo->backend, val);
+       goto err;
+    }
+
+    goto exit;
+err:
+    rc = ERROR_FAIL;
+exit:
+    GC_FREE;
+    return rc;
+}
+
+int libxl_devid_to_device_vtpm(libxl_ctx *ctx, uint32_t domid,
+                              int devid, libxl_device_vtpm *vtpm)
+{
+    libxl_device_vtpm *vtpms;
+    int nb, i;
+    int rc;
+
+    vtpms = libxl_device_vtpm_list(ctx, domid, &nb);
+    if (!vtpms)
+        return ERROR_FAIL;
+
+    memset(vtpm, 0, sizeof (libxl_device_vtpm));
+    rc = 1;
+    for (i = 0; i < nb; ++i) {
+        if(devid == vtpms[i].devid) {
+            vtpm->backend_domid = vtpms[i].backend_domid;
+            vtpm->devid = vtpms[i].devid;
+            libxl_uuid_copy(&vtpm->uuid, &vtpms[i].uuid);
+            rc = 0;
+            break;
+        }
+    }
+
+    for (i=0; i<nb; i++)
+        libxl_device_vtpm_dispose(&vtpms[i]);
+    free(vtpms);
+    return rc;
+}
+
+
+/******************************************************************************/
 
 int libxl__device_disk_setdefault(libxl__gc *gc, libxl_device_disk *disk)
 {
@@ -3174,6 +3414,10 @@ DEFINE_DEVICE_REMOVE(vkb, destroy, 1)
 DEFINE_DEVICE_REMOVE(vfb, remove, 0)
 DEFINE_DEVICE_REMOVE(vfb, destroy, 1)
 
+/* vtpm */
+DEFINE_DEVICE_REMOVE(vtpm, remove, 0)
+DEFINE_DEVICE_REMOVE(vtpm, destroy, 1)
+
 #undef DEFINE_DEVICE_REMOVE
 
 /******************************************************************************/
@@ -3208,6 +3452,9 @@ DEFINE_DEVICE_ADD(disk)
 /* nic */
 DEFINE_DEVICE_ADD(nic)
 
+/* vtpm */
+DEFINE_DEVICE_ADD(vtpm)
+
 #undef DEFINE_DEVICE_ADD
 
 /******************************************************************************/
diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index 7a7c419..3cb9ff8 100644
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -478,13 +478,14 @@ typedef struct {
     libxl_domain_create_info c_info;
     libxl_domain_build_info b_info;
 
-    int num_disks, num_nics, num_pcidevs, num_vfbs, num_vkbs;
+    int num_disks, num_nics, num_pcidevs, num_vfbs, num_vkbs, num_vtpms;
 
     libxl_device_disk *disks;
     libxl_device_nic *nics;
     libxl_device_pci *pcidevs;
     libxl_device_vfb *vfbs;
     libxl_device_vkb *vkbs;
+    libxl_device_vtpm *vtpms;
 
     libxl_action_on_shutdown on_poweroff;
     libxl_action_on_shutdown on_reboot;
@@ -745,6 +746,23 @@ 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,
                               libxl_device_nic *nic, libxl_nicinfo *nicinfo);
 
+/* Virtual TPMs */
+int libxl_device_vtpm_add(libxl_ctx *ctx, uint32_t domid, libxl_device_vtpm *vtpm,
+                          const libxl_asyncop_how *ao_how)
+                          LIBXL_EXTERNAL_CALLERS_ONLY;
+int libxl_device_vtpm_remove(libxl_ctx *ctx, uint32_t domid,
+                            libxl_device_vtpm *vtpm,
+                            const libxl_asyncop_how *ao_how)
+                            LIBXL_EXTERNAL_CALLERS_ONLY;
+int libxl_device_vtpm_destroy(libxl_ctx *ctx, uint32_t domid,
+                              libxl_device_vtpm *vtpm,
+                              const libxl_asyncop_how *ao_how)
+                              LIBXL_EXTERNAL_CALLERS_ONLY;
+
+libxl_device_vtpm *libxl_device_vtpm_list(libxl_ctx *ctx, uint32_t domid, int *num);
+int libxl_device_vtpm_getinfo(libxl_ctx *ctx, uint32_t domid,
+                               libxl_device_vtpm *vtpm, libxl_vtpminfo *vtpminfo);
+
 /* Keyboard */
 int libxl_device_vkb_add(libxl_ctx *ctx, uint32_t domid, libxl_device_vkb *vkb,
                          const libxl_asyncop_how *ao_how)
diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index 6cb586b..0eb6a9e 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -55,6 +55,10 @@ void libxl_domain_config_dispose(libxl_domain_config *d_config)
         libxl_device_vkb_dispose(&d_config->vkbs[i]);
     free(d_config->vkbs);
 
+    for (i=0; i<d_config->num_vtpms; i++)
+       libxl_device_vtpm_dispose(&d_config->vtpms[i]);
+    free(d_config->vtpms);
+
     libxl_domain_create_info_dispose(&d_config->c_info);
     libxl_domain_build_info_dispose(&d_config->b_info);
 }
@@ -601,6 +605,8 @@ static void domcreate_bootloader_done(libxl__egc *egc,
 static void domcreate_launch_dm(libxl__egc *egc, libxl__multidev *aodevs,
                                 int ret);
 
+static void domcreate_attach_vtpms(libxl__egc *egc, libxl__multidev *multidev,
+                                   int ret);
 static void domcreate_attach_pci(libxl__egc *egc, libxl__multidev *aodevs,
                                  int ret);
 
@@ -1084,13 +1090,13 @@ static void domcreate_devmodel_started(libxl__egc *egc,
     if (d_config->num_nics > 0) {
         /* Attach nics */
         libxl__multidev_begin(ao, &dcs->multidev);
-        dcs->multidev.callback = domcreate_attach_pci;
+        dcs->multidev.callback = domcreate_attach_vtpms;
         libxl__add_nics(egc, ao, domid, d_config, &dcs->multidev);
         libxl__multidev_prepared(egc, &dcs->multidev, 0);
         return;
     }
 
-    domcreate_attach_pci(egc, &dcs->multidev, 0);
+    domcreate_attach_vtpms(egc, &dcs->multidev, 0);
     return;
 
 error_out:
@@ -1098,6 +1104,36 @@ error_out:
     domcreate_complete(egc, dcs, ret);
 }
 
+static void domcreate_attach_vtpms(libxl__egc *egc, libxl__multidev *multidev, int ret) {
+   libxl__domain_create_state *dcs = CONTAINER_OF(multidev, *dcs, multidev);
+   STATE_AO_GC(dcs->ao);
+   int domid = dcs->guest_domid;
+
+   libxl_domain_config* const d_config = dcs->guest_config;
+
+   if(ret) {
+      LOG(ERROR, "unable to add nic devices");
+      goto error_out;
+   }
+
+    /* Plug vtpm devices */
+    if (d_config->num_vtpms > 0) {
+        /* Attach vtpms */
+        libxl__multidev_begin(ao, &dcs->multidev);
+        dcs->multidev.callback = domcreate_attach_pci;
+        libxl__add_vtpms(egc, ao, domid, d_config, &dcs->multidev);
+        libxl__multidev_prepared(egc, &dcs->multidev, 0);
+        return;
+    }
+
+   domcreate_attach_pci(egc, multidev, 0);
+   return;
+
+error_out:
+   assert(ret);
+   domcreate_complete(egc, dcs, ret);
+}
+
 static void domcreate_attach_pci(libxl__egc *egc, libxl__multidev *multidev,
                                  int ret)
 {
@@ -1111,7 +1147,7 @@ static void domcreate_attach_pci(libxl__egc *egc, libxl__multidev *multidev,
     libxl_domain_config *const d_config = dcs->guest_config;
 
     if (ret) {
-        LOG(ERROR, "unable to add nic devices");
+        LOG(ERROR, "unable to add vtpm devices");
         goto error_out;
     }
 
diff --git a/tools/libxl/libxl_device.c b/tools/libxl/libxl_device.c
index c3283f1..47a29f0 100644
--- a/tools/libxl/libxl_device.c
+++ b/tools/libxl/libxl_device.c
@@ -515,6 +515,7 @@ void libxl__multidev_prepared(libxl__egc *egc,
 
 DEFINE_DEVICES_ADD(disk)
 DEFINE_DEVICES_ADD(nic)
+DEFINE_DEVICES_ADD(vtpm)
 
 #undef DEFINE_DEVICES_ADD
 
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index b6f54ba..e9a7cbb 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -954,6 +954,7 @@ _hidden int libxl__device_disk_setdefault(libxl__gc *gc,
                                           libxl_device_disk *disk);
 _hidden int libxl__device_nic_setdefault(libxl__gc *gc, libxl_device_nic *nic,
                                          uint32_t domid);
+_hidden int libxl__device_vtpm_setdefault(libxl__gc *gc, libxl_device_vtpm *vtpm);
 _hidden int libxl__device_vfb_setdefault(libxl__gc *gc, libxl_device_vfb *vfb);
 _hidden int libxl__device_vkb_setdefault(libxl__gc *gc, libxl_device_vkb *vkb);
 _hidden int libxl__device_pci_setdefault(libxl__gc *gc, libxl_device_pci *pci);
@@ -1975,6 +1976,10 @@ _hidden void libxl__device_nic_add(libxl__egc *egc, uint32_t domid,
                                    libxl_device_nic *nic,
                                    libxl__ao_device *aodev);
 
+_hidden void libxl__device_vtpm_add(libxl__egc *egc, uint32_t domid,
+                                   libxl_device_vtpm *vtpm,
+                                   libxl__ao_device *aodev);
+
 /* Internal function to connect a vkb device */
 _hidden int libxl__device_vkb_add(libxl__gc *gc, uint32_t domid,
                                   libxl_device_vkb *vkb);
@@ -2407,6 +2412,10 @@ _hidden void libxl__add_nics(libxl__egc *egc, libxl__ao *ao, uint32_t domid,
                              libxl_domain_config *d_config,
                              libxl__multidev *multidev);
 
+_hidden void libxl__add_vtpms(libxl__egc *egc, libxl__ao *ao, uint32_t domid,
+                             libxl_domain_config *d_config,
+                             libxl__multidev *multidev);
+
 /*----- device model creation -----*/
 
 /* First layer; wraps libxl__spawn_spawn. */
diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
index de111a6..7eac4a8 100644
--- a/tools/libxl/libxl_types.idl
+++ b/tools/libxl/libxl_types.idl
@@ -395,6 +395,12 @@ libxl_device_pci = Struct("device_pci", [
     ("permissive", bool),
     ])
 
+libxl_device_vtpm = Struct("device_vtpm", [
+    ("backend_domid",    libxl_domid),
+    ("devid",            libxl_devid),
+    ("uuid",             libxl_uuid),
+])
+
 libxl_diskinfo = Struct("diskinfo", [
     ("backend", string),
     ("backend_id", uint32),
@@ -418,6 +424,18 @@ libxl_nicinfo = Struct("nicinfo", [
     ("rref_rx", integer),
     ], dir=DIR_OUT)
 
+libxl_vtpminfo = Struct("vtpminfo", [
+    ("backend", string),
+    ("backend_id", uint32),
+    ("frontend", string),
+    ("frontend_id", uint32),
+    ("devid", libxl_devid),
+    ("state", integer),
+    ("evtch", integer),
+    ("rref", integer),
+    ("uuid", libxl_uuid),
+    ], dir=DIR_OUT)
+
 libxl_vcpuinfo = Struct("vcpuinfo", [
     ("vcpuid", uint32),
     ("cpu", uint32),
diff --git a/tools/libxl/libxl_types_internal.idl b/tools/libxl/libxl_types_internal.idl
index 5ac8c9c..c40120e 100644
--- a/tools/libxl/libxl_types_internal.idl
+++ b/tools/libxl/libxl_types_internal.idl
@@ -19,6 +19,7 @@ libxl__device_kind = Enumeration("device_kind", [
     (5, "VFB"),
     (6, "VKBD"),
     (7, "CONSOLE"),
+    (8, "VTPM"),
     ])
 
 libxl__console_backend = Enumeration("console_backend", [
diff --git a/tools/libxl/libxl_utils.c b/tools/libxl/libxl_utils.c
index 55cd299..73a158a 100644
--- a/tools/libxl/libxl_utils.c
+++ b/tools/libxl/libxl_utils.c
@@ -463,6 +463,35 @@ int libxl_pipe(libxl_ctx *ctx, int pipes[2])
     return 0;
 }
 
+int libxl_uuid_to_device_vtpm(libxl_ctx *ctx, uint32_t domid,
+                            libxl_uuid* uuid, libxl_device_vtpm *vtpm)
+{
+    libxl_device_vtpm *vtpms;
+    int nb, i;
+    int rc;
+
+    vtpms = libxl_device_vtpm_list(ctx, domid, &nb);
+    if (!vtpms)
+        return ERROR_FAIL;
+
+    memset(vtpm, 0, sizeof (libxl_device_vtpm));
+    rc = 1;
+    for (i = 0; i < nb; ++i) {
+        if(!libxl_uuid_compare(uuid, &vtpms[i].uuid)) {
+            vtpm->backend_domid = vtpms[i].backend_domid;
+            vtpm->devid = vtpms[i].devid;
+            libxl_uuid_copy(&vtpm->uuid, &vtpms[i].uuid);
+            rc = 0;
+            break;
+        }
+    }
+
+    for (i=0; i<nb; i++)
+        libxl_device_vtpm_dispose(&vtpms[i]);
+    free(vtpms);
+    return rc;
+}
+
 int libxl_mac_to_device_nic(libxl_ctx *ctx, uint32_t domid,
                             const char *mac, libxl_device_nic *nic)
 {
diff --git a/tools/libxl/libxl_utils.h b/tools/libxl/libxl_utils.h
index 83aaac7..40f3f30 100644
--- a/tools/libxl/libxl_utils.h
+++ b/tools/libxl/libxl_utils.h
@@ -64,6 +64,11 @@ int libxl_devid_to_device_nic(libxl_ctx *ctx, uint32_t domid, int devid,
 int libxl_vdev_to_device_disk(libxl_ctx *ctx, uint32_t domid, const char *vdev,
                                libxl_device_disk *disk);
 
+int libxl_uuid_to_device_vtpm(libxl_ctx *ctx, uint32_t domid,
+                               libxl_uuid *uuid, libxl_device_vtpm *vtpm);
+int libxl_devid_to_device_vtpm(libxl_ctx *ctx, uint32_t domid,
+                               int devid, libxl_device_vtpm *vtpm);
+
 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. */
diff --git a/tools/libxl/xl.h b/tools/libxl/xl.h
index 0b2f848..be6f38b 100644
--- a/tools/libxl/xl.h
+++ b/tools/libxl/xl.h
@@ -79,6 +79,9 @@ int main_networkdetach(int argc, char **argv);
 int main_blockattach(int argc, char **argv);
 int main_blocklist(int argc, char **argv);
 int main_blockdetach(int argc, char **argv);
+int main_vtpmattach(int argc, char **argv);
+int main_vtpmlist(int argc, char **argv);
+int main_vtpmdetach(int argc, char **argv);
 int main_uptime(int argc, char **argv);
 int main_tmem_list(int argc, char **argv);
 int main_tmem_freeze(int argc, char **argv);
diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index fe8e925..3f02f6d 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -573,7 +573,7 @@ static void parse_config_data(const char *config_source,
     const char *buf;
     long l;
     XLU_Config *config;
-    XLU_ConfigList *cpus, *vbds, *nics, *pcis, *cvfbs, *cpuids;
+    XLU_ConfigList *cpus, *vbds, *nics, *pcis, *cvfbs, *cpuids, *vtpms;
     XLU_ConfigList *ioports, *irqs, *iomem;
     int num_ioports, num_irqs, num_iomem;
     int pci_power_mgmt = 0;
@@ -1045,6 +1045,47 @@ static void parse_config_data(const char *config_source,
         }
     }
 
+    if (!xlu_cfg_get_list(config, "vtpm", &vtpms, 0, 0)) {
+        d_config->num_vtpms = 0;
+        d_config->vtpms = NULL;
+        while ((buf = xlu_cfg_get_listitem (vtpms, d_config->num_vtpms)) != NULL) {
+            libxl_device_vtpm *vtpm;
+            char * buf2 = strdup(buf);
+            char *p, *p2;
+
+            d_config->vtpms = (libxl_device_vtpm *) realloc(d_config->vtpms, sizeof(libxl_device_vtpm) * (d_config->num_vtpms+1));
+            vtpm = d_config->vtpms + d_config->num_vtpms;
+            libxl_device_vtpm_init(vtpm);
+            vtpm->devid = d_config->num_vtpms;
+
+            p = strtok(buf2, ",");
+            if (!p)
+                goto skip_vtpm;
+            do {
+                while(*p == ' ')
+                    ++p;
+                if ((p2 = strchr(p, '=')) == NULL)
+                    break;
+                *p2 = '\0';
+                if (!strcmp(p, "backend")) {
+                    if(domain_qualifier_to_domid(p2 + 1, &(vtpm->backend_domid), 0))
+                    {
+                        fprintf(stderr, "Specified backend domain does not exist, defaulting to Dom0\n");
+                        vtpm->backend_domid = 0;
+                    }
+                } else if(!strcmp(p, "uuid")) {
+                    if( libxl_uuid_from_string(&vtpm->uuid, p2 + 1) ) {
+                        fprintf(stderr, "Failed to parse vtpm UUID: %s\n", p2 + 1);
+                        exit(1);
+                    }
+                }
+            } while ((p = strtok(NULL, ",")) != NULL);
+skip_vtpm:
+            free(buf2);
+            d_config->num_vtpms++;
+        }
+    }
+
     if (!xlu_cfg_get_list (config, "vif", &nics, 0, 0)) {
         d_config->num_nics = 0;
         d_config->nics = NULL;
@@ -1070,7 +1111,7 @@ static void parse_config_data(const char *config_source,
 
             p = strtok(buf2, ",");
             if (!p)
-                goto skip;
+                goto skip_nic;
             do {
                 while (*p == ' ')
                     p++;
@@ -1134,7 +1175,7 @@ static void parse_config_data(const char *config_source,
                     fprintf(stderr, "the accel parameter for vifs is currently not supported\n");
                 }
             } while ((p = strtok(NULL, ",")) != NULL);
-skip:
+skip_nic:
             free(buf2);
             d_config->num_nics++;
         }
@@ -5570,6 +5611,131 @@ int main_blockdetach(int argc, char **argv)
     return rc;
 }
 
+int main_vtpmattach(int argc, char **argv)
+{
+    int opt;
+    libxl_device_vtpm vtpm;
+    char *oparg;
+    unsigned int val;
+    uint32_t domid;
+
+    if ((opt = def_getopt(argc, argv, "", "vtpm-attach", 1)) != -1)
+        return opt;
+
+    if (domain_qualifier_to_domid(argv[optind], &domid, 0) < 0) {
+        fprintf(stderr, "%s is an invalid domain identifier\n", argv[optind]);
+        return 1;
+    }
+    ++optind;
+
+    libxl_device_vtpm_init(&vtpm);
+    for (argv += optind, argc -= optind; argc > 0; ++argv, --argc) {
+        if (MATCH_OPTION("uuid", *argv, oparg)) {
+            if(libxl_uuid_from_string(&(vtpm.uuid), oparg)) {
+                fprintf(stderr, "Invalid uuid specified (%s)\n", oparg);
+                return 1;
+            }
+        } else if (MATCH_OPTION("backend", *argv, oparg)) {
+            if(domain_qualifier_to_domid(oparg, &val, 0)) {
+                fprintf(stderr, "Specified backend domain does not exist, defaulting to Dom0\n");
+                val = 0;
+            }
+            vtpm.backend_domid = val;
+        } else {
+            fprintf(stderr, "unrecognized argument `%s'\n", *argv);
+            return 1;
+        }
+    }
+
+    if(dryrun_only) {
+       char* json = libxl_device_vtpm_to_json(ctx, &vtpm);
+       printf("vtpm: %s\n", json);
+       free(json);
+       libxl_device_vtpm_dispose(&vtpm);
+       if (ferror(stdout) || fflush(stdout)) { perror("stdout"); exit(-1); }
+       return 0;
+    }
+
+    if (libxl_device_vtpm_add(ctx, domid, &vtpm, 0)) {
+        fprintf(stderr, "libxl_device_vtpm_add failed.\n");
+        return 1;
+    }
+    libxl_device_vtpm_dispose(&vtpm);
+    return 0;
+}
+
+int main_vtpmlist(int argc, char **argv)
+{
+    int opt;
+    libxl_device_vtpm *vtpms;
+    libxl_vtpminfo vtpminfo;
+    int nb, i;
+
+    if ((opt = def_getopt(argc, argv, "", "vtpm-list", 1)) != -1)
+        return opt;
+
+    /*      Idx  BE   UUID   Hdl  Sta  evch rref  BE-path */
+    printf("%-3s %-2s %-36s %-6s %-5s %-6s %-5s %-10s\n",
+           "Idx", "BE", "Uuid", "handle", "state", "evt-ch", "ring-ref", "BE-path");
+    for (argv += optind, argc -= optind; argc > 0; --argc, ++argv) {
+        uint32_t domid;
+        if (domain_qualifier_to_domid(*argv, &domid, 0) < 0) {
+            fprintf(stderr, "%s is an invalid domain identifier\n", *argv);
+            continue;
+        }
+        if (!(vtpms = libxl_device_vtpm_list(ctx, domid, &nb))) {
+            continue;
+        }
+        for (i = 0; i < nb; ++i) {
+           if(!libxl_device_vtpm_getinfo(ctx, domid, &vtpms[i], &vtpminfo)) {
+              /*      Idx  BE     UUID             Hdl Sta evch rref BE-path*/
+              printf("%-3d %-2d " LIBXL_UUID_FMT " %6d %5d %6d %8d %-30s\n",
+                    vtpminfo.devid, vtpminfo.backend_id,
+                    LIBXL_UUID_BYTES(vtpminfo.uuid),
+                    vtpminfo.devid, vtpminfo.state, vtpminfo.evtch,
+                    vtpminfo.rref, vtpminfo.backend);
+
+              libxl_vtpminfo_dispose(&vtpminfo);
+           }
+           libxl_device_vtpm_dispose(&vtpms[i]);
+        }
+        free(vtpms);
+    }
+    return 0;
+}
+
+int main_vtpmdetach(int argc, char **argv)
+{
+    uint32_t domid;
+    int opt, rc=0;
+    libxl_device_vtpm vtpm;
+    libxl_uuid uuid;
+
+    if ((opt = def_getopt(argc, argv, "", "vtpm-detach", 2)) != -1)
+        return opt;
+
+    domid = find_domain(argv[optind]);
+
+    if ( libxl_uuid_from_string(&uuid, argv[optind+1])) {
+        if (libxl_devid_to_device_vtpm(ctx, domid, atoi(argv[optind+1]), &vtpm)) {
+            fprintf(stderr, "Unknown device %s.\n", argv[optind+1]);
+            return 1;
+        }
+    } else {
+        if (libxl_uuid_to_device_vtpm(ctx, domid, &uuid, &vtpm)) {
+            fprintf(stderr, "Unknown device %s.\n", argv[optind+1]);
+            return 1;
+        }
+    }
+    rc = libxl_device_vtpm_remove(ctx, domid, &vtpm, 0);
+    if (rc) {
+        fprintf(stderr, "libxl_device_vtpm_remove failed.\n");
+    }
+    libxl_device_vtpm_dispose(&vtpm);
+    return rc;
+}
+
+
 static char *uptime_to_string(unsigned long uptime, int short_mode)
 {
     int sec, min, hour, day;
diff --git a/tools/libxl/xl_cmdtable.c b/tools/libxl/xl_cmdtable.c
index 85ea768..7c018eb 100644
--- a/tools/libxl/xl_cmdtable.c
+++ b/tools/libxl/xl_cmdtable.c
@@ -338,6 +338,21 @@ struct cmd_spec cmd_table[] = {
       "Destroy a domain's virtual block device",
       "<Domain> <DevId>",
     },
+    { "vtpm-attach",
+      &main_vtpmattach, 0, 1,
+      "Create a new virtual TPM device",
+      "<Domain> [uuid=<uuid>] [backend=<BackDomain>]",
+    },
+    { "vtpm-list",
+      &main_vtpmlist, 0, 0,
+      "List virtual TPM devices for a domain",
+      "<Domain(s)>",
+    },
+    { "vtpm-detach",
+      &main_vtpmdetach, 0, 1,
+      "Destroy a domain's virtual TPM device",
+      "<Domain> <DevId|uuid>",
+    },
     { "uptime",
       &main_uptime, 0, 0,
       "Print uptime for all/some domains",
-- 
1.7.9.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 27 17:12:35 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Sep 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 1THHdX-0006g9-Ow; Thu, 27 Sep 2012 17:12:31 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <matthew.fioravante@jhuapl.edu>) id 1THHdW-0006eV-1R
	for xen-devel@lists.xen.org; Thu, 27 Sep 2012 17:12:30 +0000
Received: from [85.158.138.51:33014] by server-8.bemta-3.messagelabs.com id
	6B/6A-16337-DF884605; Thu, 27 Sep 2012 17:12:29 +0000
X-Env-Sender: matthew.fioravante@jhuapl.edu
X-Msg-Ref: server-6.tower-174.messagelabs.com!1348765945!24203542!1
X-Originating-IP: [128.244.251.36]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG,
	UNPARSEABLE_RELAY
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18339 invoked from network); 27 Sep 2012 17:12:26 -0000
Received: from pilot.jhuapl.edu (HELO jhuapl.edu) (128.244.251.36)
	by server-6.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 27 Sep 2012 17:12:26 -0000
Received: from ([128.244.207.89])
	by pilot.jhuapl.edu with ESMTP with TLS id 63GHCH1.153803009;
	Thu, 27 Sep 2012 13:12:20 -0400
From: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
To: xen-devel@lists.xen.org,
	Ian.Campbell@citrix.com
Date: Thu, 27 Sep 2012 13:11:00 -0400
Message-Id: <1348765860-11359-3-git-send-email-matthew.fioravante@jhuapl.edu>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <1348765860-11359-1-git-send-email-matthew.fioravante@jhuapl.edu>
References: <1348765860-11359-1-git-send-email-matthew.fioravante@jhuapl.edu>
Cc: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
Subject: [Xen-devel] [PATCH 11/11] add vtpm support to 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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This patch adds vtpm support to libxl. It adds vtpm parsing to config
files and 3 new xl commands:
vtpm-attach
vtpm-detach
vtpm-list

Signed-off-by: Matthew Fioravante <matthew.fioravante@jhuapl.edu>

diff --git a/docs/man/xl.cfg.pod.5 b/docs/man/xl.cfg.pod.5
index 428da21..edeeefa 100644
--- a/docs/man/xl.cfg.pod.5
+++ b/docs/man/xl.cfg.pod.5
@@ -298,6 +298,35 @@ 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>.
 
+=item B<vtpm=[ "VTPM_SPEC_STRING", "VTPM_SPEC_STRING", ...]>
+
+Specifies the virtual trusted platform module to be
+provided to the guest. Please see F<docs/misc/vtpm.txt>
+for more details.
+
+Each B<VTPM_SPEC_STRING> is a comma-separated list of C<KEY=VALUE>
+settings, from the following list:
+
+=over 4
+
+=item C<backend=DOMAIN>
+
+Specify the backend domain name of id. This value must be
+set if you are using the vtpm domain model. If this domain
+is a guest, the backend should be set to the vtpm domain name.
+If this domain is a vtpm, the backend should be set to the
+vtpm manager domain name. The default value is domain 0,
+which should be used if you are running the vtpm process model.
+
+=item C<uuid=UUID>
+
+Specify the uuid of this vtpm device. The uuid is used to uniquely
+identify the vtpm device. You can create one using the uuidgen
+program on unix systems. If left unspecified, a new uuid
+will be randomly generated every time the domain boots.
+
+=back
+
 =item B<vfb=[ "VFB_SPEC_STRING", "VFB_SPEC_STRING", ...]>
 
 Specifies the paravirtual framebuffer devices which should be supplied
diff --git a/docs/man/xl.pod.1 b/docs/man/xl.pod.1
index 25ce777..be9ad4c 100644
--- a/docs/man/xl.pod.1
+++ b/docs/man/xl.pod.1
@@ -1101,6 +1101,31 @@ List virtual network interfaces for a domain.
 
 =back
 
+=head2 VTPM DEVICES
+
+=over 4
+
+=item B<vtpm-attach> I<domain-id> I<vtpm-device>
+
+Creates a new vtpm device in the domain specified by I<domain-id>.
+I<vtpm-device> describes the device to attach, using the same format as the
+B<vtpm> string in the domain config file. See L<xl.cfg> for
+more information.
+
+=item B<vtpm-detach> I<domain-id> I<devid|uuid>
+
+Removes the vtpm device from the domain specified by I<domain-id>.
+I<devid> is the numeric device id given to the virtual trusted
+platform module device. You will need to run B<xl vtpm-list> to determine that number.
+Alternatively the I<uuid> of the vtpm can be used to
+select the virtual device to detach.
+
+=item B<vtpm-list> I<domain-id>
+
+List virtual trusted platform modules for a domain.
+
+=back
+
 =head1 PCI PASS-THROUGH
 
 =over 4
diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 1606eb1..f613487 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -1726,6 +1726,246 @@ out:
 }
 
 /******************************************************************************/
+int libxl__device_vtpm_setdefault(libxl__gc *gc, libxl_device_vtpm *vtpm)
+{
+   if(libxl_uuid_is_nil(&vtpm->uuid)) {
+      libxl_uuid_generate(&vtpm->uuid);
+   }
+   return 0;
+}
+
+static int libxl__device_from_vtpm(libxl__gc *gc, uint32_t domid,
+                                   libxl_device_vtpm *vtpm,
+                                   libxl__device *device)
+{
+   device->backend_devid   = vtpm->devid;
+   device->backend_domid   = vtpm->backend_domid;
+   device->backend_kind    = LIBXL__DEVICE_KIND_VTPM;
+   device->devid           = vtpm->devid;
+   device->domid           = domid;
+   device->kind            = LIBXL__DEVICE_KIND_VTPM;
+
+   return 0;
+}
+
+void libxl__device_vtpm_add(libxl__egc *egc, uint32_t domid,
+                           libxl_device_vtpm *vtpm,
+                           libxl__ao_device *aodev)
+{
+    STATE_AO_GC(aodev->ao);
+    flexarray_t *front;
+    flexarray_t *back;
+    libxl__device *device;
+    char *dompath, **l;
+    unsigned int nb, rc;
+
+    rc = libxl__device_vtpm_setdefault(gc, vtpm);
+    if (rc) goto out;
+
+    front = flexarray_make(16, 1);
+    if (!front) {
+        rc = ERROR_NOMEM;
+        goto out;
+    }
+    back = flexarray_make(16, 1);
+    if (!back) {
+        rc = ERROR_NOMEM;
+        goto out;
+    }
+
+    if(vtpm->devid == -1) {
+        if (!(dompath = libxl__xs_get_dompath(gc, domid))) {
+            rc = ERROR_FAIL;
+            goto out_free;
+        }
+        l = libxl__xs_directory(gc, XBT_NULL, libxl__sprintf(gc, "%s/device/vtpm", dompath), &nb);
+        if(l == NULL || nb == 0) {
+            vtpm->devid = 0;
+        } else {
+            vtpm->devid = strtoul(l[nb - 1], NULL, 10) + 1;
+        }
+    }
+
+    GCNEW(device);
+    rc = libxl__device_from_vtpm(gc, domid, vtpm, device);
+    if ( rc != 0 ) goto out_free;
+
+    flexarray_append(back, "frontend-id");
+    flexarray_append(back, libxl__sprintf(gc, "%d", domid));
+    flexarray_append(back, "online");
+    flexarray_append(back, "1");
+    flexarray_append(back, "state");
+    flexarray_append(back, libxl__sprintf(gc, "%d", 1));
+
+    flexarray_append(back, "uuid");
+    flexarray_append(back, libxl__sprintf(gc, LIBXL_UUID_FMT, LIBXL_UUID_BYTES(vtpm->uuid)));
+    flexarray_append(back, "instance"); /* MAYBE CAN GET RID OF THIS */
+    flexarray_append(back, "0");
+    flexarray_append(back, "pref_instance"); /* MAYBE CAN GET RID OF THIS */
+    flexarray_append(back, "0");
+    flexarray_append(back, "resume");
+    flexarray_append(back, "False");
+    flexarray_append(back, "ready"); /* MAYBE CAN GET RID OF THIS */
+    flexarray_append(back, "1");
+
+    flexarray_append(front, "backend-id");
+    flexarray_append(front, libxl__sprintf(gc, "%d", vtpm->backend_domid));
+    flexarray_append(front, "state");
+    flexarray_append(front, libxl__sprintf(gc, "%d", 1));
+    flexarray_append(front, "handle");
+    flexarray_append(front, libxl__sprintf(gc, "%d", vtpm->devid));
+
+    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));
+
+    aodev->dev = device;
+    aodev->action = DEVICE_CONNECT;
+    libxl__wait_device_connection(egc, aodev);
+
+    rc = 0;
+out_free:
+    flexarray_free(back);
+    flexarray_free(front);
+out:
+    aodev->rc = rc;
+    if(rc) aodev->callback(egc, aodev);
+    return;
+}
+
+static void libxl__device_vtpm_from_xs_fe(libxl__gc *gc,
+                                          const char* fe_path,
+                                          libxl_device_vtpm *vtpm)
+{
+   char* tmp;
+
+   memset(vtpm, 0, sizeof(*vtpm));
+   tmp = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/handle", fe_path));
+   if (tmp) {
+      vtpm->devid = atoi(tmp);
+   }
+   tmp = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/backend-id", fe_path));
+   if(tmp) {
+      vtpm->backend_domid = atoi(tmp);
+   }
+   tmp = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/uuid", fe_path));
+   if(tmp) {
+      libxl_uuid_from_string(&(vtpm->uuid), tmp);
+   }
+}
+
+libxl_device_vtpm *libxl_device_vtpm_list(libxl_ctx *ctx, uint32_t domid, int *num)
+{
+    GC_INIT(ctx);
+
+    libxl_device_vtpm* vtpms = NULL;
+    char* fe_path = NULL;
+    char** dir = NULL;
+    unsigned int ndirs = 0;
+
+    *num = 0;
+
+    fe_path = libxl__sprintf(gc, "%s/device/vtpm", libxl__xs_get_dompath(gc, domid));
+    dir = libxl__xs_directory(gc, XBT_NULL, fe_path, &ndirs);
+    if(dir) {
+       vtpms = malloc(sizeof(*vtpms) * ndirs);
+       libxl_device_vtpm* vtpm;
+       libxl_device_vtpm* end = vtpms + ndirs;
+       for(vtpm = vtpms; vtpm < end; ++vtpm, ++dir) {
+          const char* path = libxl__sprintf(gc, "%s/%s", fe_path, *dir);
+          libxl__device_vtpm_from_xs_fe(gc, path, vtpm);
+       }
+    }
+    *num = ndirs;
+
+    GC_FREE;
+    return vtpms;
+}
+
+int libxl_device_vtpm_getinfo(libxl_ctx *ctx, uint32_t domid,
+                               libxl_device_vtpm *vtpm, libxl_vtpminfo *vtpminfo)
+{
+    GC_INIT(ctx);
+    char *dompath, *vtpmpath;
+    char *val;
+    int rc = 0;
+
+    libxl_vtpminfo_init(vtpminfo);
+    dompath = libxl__xs_get_dompath(gc, domid);
+    vtpminfo->devid = vtpm->devid;
+
+    vtpmpath = libxl__sprintf(gc, "%s/device/vtpm/%d", dompath, vtpminfo->devid);
+    vtpminfo->backend = xs_read(ctx->xsh, XBT_NULL,
+                                libxl__sprintf(gc, "%s/backend", vtpmpath), NULL);
+    if (!vtpminfo->backend) {
+        goto err;
+    }
+    if(!libxl__xs_read(gc, XBT_NULL, vtpminfo->backend)) {
+       goto err;
+    }
+
+    val = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/backend-id", vtpmpath));
+    vtpminfo->backend_id = val ? strtoul(val, NULL, 10) : -1;
+    val = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/state", vtpmpath));
+    vtpminfo->state = val ? strtoul(val, NULL, 10) : -1;
+    val = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/event-channel", vtpmpath));
+    vtpminfo->evtch = val ? strtoul(val, NULL, 10) : -1;
+    val = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/ring-ref", vtpmpath));
+    vtpminfo->rref = val ? strtoul(val, NULL, 10) : -1;
+    vtpminfo->frontend = xs_read(ctx->xsh, XBT_NULL,
+                                 libxl__sprintf(gc, "%s/frontend", vtpminfo->backend), NULL);
+    val = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/frontend-id", vtpminfo->backend));
+    vtpminfo->frontend_id = val ? strtoul(val, NULL, 10) : -1;
+
+    val = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/uuid", vtpminfo->backend));
+    if(val == NULL) {
+       LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "%s/uuid does not exist!\n", vtpminfo->backend);
+       goto err;
+    }
+    if(libxl_uuid_from_string(&(vtpminfo->uuid), val)) {
+       LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "%s/uuid is a malformed uuid?? (%s) Probably a bug!\n", vtpminfo->backend, val);
+       goto err;
+    }
+
+    goto exit;
+err:
+    rc = ERROR_FAIL;
+exit:
+    GC_FREE;
+    return rc;
+}
+
+int libxl_devid_to_device_vtpm(libxl_ctx *ctx, uint32_t domid,
+                              int devid, libxl_device_vtpm *vtpm)
+{
+    libxl_device_vtpm *vtpms;
+    int nb, i;
+    int rc;
+
+    vtpms = libxl_device_vtpm_list(ctx, domid, &nb);
+    if (!vtpms)
+        return ERROR_FAIL;
+
+    memset(vtpm, 0, sizeof (libxl_device_vtpm));
+    rc = 1;
+    for (i = 0; i < nb; ++i) {
+        if(devid == vtpms[i].devid) {
+            vtpm->backend_domid = vtpms[i].backend_domid;
+            vtpm->devid = vtpms[i].devid;
+            libxl_uuid_copy(&vtpm->uuid, &vtpms[i].uuid);
+            rc = 0;
+            break;
+        }
+    }
+
+    for (i=0; i<nb; i++)
+        libxl_device_vtpm_dispose(&vtpms[i]);
+    free(vtpms);
+    return rc;
+}
+
+
+/******************************************************************************/
 
 int libxl__device_disk_setdefault(libxl__gc *gc, libxl_device_disk *disk)
 {
@@ -3174,6 +3414,10 @@ DEFINE_DEVICE_REMOVE(vkb, destroy, 1)
 DEFINE_DEVICE_REMOVE(vfb, remove, 0)
 DEFINE_DEVICE_REMOVE(vfb, destroy, 1)
 
+/* vtpm */
+DEFINE_DEVICE_REMOVE(vtpm, remove, 0)
+DEFINE_DEVICE_REMOVE(vtpm, destroy, 1)
+
 #undef DEFINE_DEVICE_REMOVE
 
 /******************************************************************************/
@@ -3208,6 +3452,9 @@ DEFINE_DEVICE_ADD(disk)
 /* nic */
 DEFINE_DEVICE_ADD(nic)
 
+/* vtpm */
+DEFINE_DEVICE_ADD(vtpm)
+
 #undef DEFINE_DEVICE_ADD
 
 /******************************************************************************/
diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index 7a7c419..3cb9ff8 100644
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -478,13 +478,14 @@ typedef struct {
     libxl_domain_create_info c_info;
     libxl_domain_build_info b_info;
 
-    int num_disks, num_nics, num_pcidevs, num_vfbs, num_vkbs;
+    int num_disks, num_nics, num_pcidevs, num_vfbs, num_vkbs, num_vtpms;
 
     libxl_device_disk *disks;
     libxl_device_nic *nics;
     libxl_device_pci *pcidevs;
     libxl_device_vfb *vfbs;
     libxl_device_vkb *vkbs;
+    libxl_device_vtpm *vtpms;
 
     libxl_action_on_shutdown on_poweroff;
     libxl_action_on_shutdown on_reboot;
@@ -745,6 +746,23 @@ 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,
                               libxl_device_nic *nic, libxl_nicinfo *nicinfo);
 
+/* Virtual TPMs */
+int libxl_device_vtpm_add(libxl_ctx *ctx, uint32_t domid, libxl_device_vtpm *vtpm,
+                          const libxl_asyncop_how *ao_how)
+                          LIBXL_EXTERNAL_CALLERS_ONLY;
+int libxl_device_vtpm_remove(libxl_ctx *ctx, uint32_t domid,
+                            libxl_device_vtpm *vtpm,
+                            const libxl_asyncop_how *ao_how)
+                            LIBXL_EXTERNAL_CALLERS_ONLY;
+int libxl_device_vtpm_destroy(libxl_ctx *ctx, uint32_t domid,
+                              libxl_device_vtpm *vtpm,
+                              const libxl_asyncop_how *ao_how)
+                              LIBXL_EXTERNAL_CALLERS_ONLY;
+
+libxl_device_vtpm *libxl_device_vtpm_list(libxl_ctx *ctx, uint32_t domid, int *num);
+int libxl_device_vtpm_getinfo(libxl_ctx *ctx, uint32_t domid,
+                               libxl_device_vtpm *vtpm, libxl_vtpminfo *vtpminfo);
+
 /* Keyboard */
 int libxl_device_vkb_add(libxl_ctx *ctx, uint32_t domid, libxl_device_vkb *vkb,
                          const libxl_asyncop_how *ao_how)
diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index 6cb586b..0eb6a9e 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -55,6 +55,10 @@ void libxl_domain_config_dispose(libxl_domain_config *d_config)
         libxl_device_vkb_dispose(&d_config->vkbs[i]);
     free(d_config->vkbs);
 
+    for (i=0; i<d_config->num_vtpms; i++)
+       libxl_device_vtpm_dispose(&d_config->vtpms[i]);
+    free(d_config->vtpms);
+
     libxl_domain_create_info_dispose(&d_config->c_info);
     libxl_domain_build_info_dispose(&d_config->b_info);
 }
@@ -601,6 +605,8 @@ static void domcreate_bootloader_done(libxl__egc *egc,
 static void domcreate_launch_dm(libxl__egc *egc, libxl__multidev *aodevs,
                                 int ret);
 
+static void domcreate_attach_vtpms(libxl__egc *egc, libxl__multidev *multidev,
+                                   int ret);
 static void domcreate_attach_pci(libxl__egc *egc, libxl__multidev *aodevs,
                                  int ret);
 
@@ -1084,13 +1090,13 @@ static void domcreate_devmodel_started(libxl__egc *egc,
     if (d_config->num_nics > 0) {
         /* Attach nics */
         libxl__multidev_begin(ao, &dcs->multidev);
-        dcs->multidev.callback = domcreate_attach_pci;
+        dcs->multidev.callback = domcreate_attach_vtpms;
         libxl__add_nics(egc, ao, domid, d_config, &dcs->multidev);
         libxl__multidev_prepared(egc, &dcs->multidev, 0);
         return;
     }
 
-    domcreate_attach_pci(egc, &dcs->multidev, 0);
+    domcreate_attach_vtpms(egc, &dcs->multidev, 0);
     return;
 
 error_out:
@@ -1098,6 +1104,36 @@ error_out:
     domcreate_complete(egc, dcs, ret);
 }
 
+static void domcreate_attach_vtpms(libxl__egc *egc, libxl__multidev *multidev, int ret) {
+   libxl__domain_create_state *dcs = CONTAINER_OF(multidev, *dcs, multidev);
+   STATE_AO_GC(dcs->ao);
+   int domid = dcs->guest_domid;
+
+   libxl_domain_config* const d_config = dcs->guest_config;
+
+   if(ret) {
+      LOG(ERROR, "unable to add nic devices");
+      goto error_out;
+   }
+
+    /* Plug vtpm devices */
+    if (d_config->num_vtpms > 0) {
+        /* Attach vtpms */
+        libxl__multidev_begin(ao, &dcs->multidev);
+        dcs->multidev.callback = domcreate_attach_pci;
+        libxl__add_vtpms(egc, ao, domid, d_config, &dcs->multidev);
+        libxl__multidev_prepared(egc, &dcs->multidev, 0);
+        return;
+    }
+
+   domcreate_attach_pci(egc, multidev, 0);
+   return;
+
+error_out:
+   assert(ret);
+   domcreate_complete(egc, dcs, ret);
+}
+
 static void domcreate_attach_pci(libxl__egc *egc, libxl__multidev *multidev,
                                  int ret)
 {
@@ -1111,7 +1147,7 @@ static void domcreate_attach_pci(libxl__egc *egc, libxl__multidev *multidev,
     libxl_domain_config *const d_config = dcs->guest_config;
 
     if (ret) {
-        LOG(ERROR, "unable to add nic devices");
+        LOG(ERROR, "unable to add vtpm devices");
         goto error_out;
     }
 
diff --git a/tools/libxl/libxl_device.c b/tools/libxl/libxl_device.c
index c3283f1..47a29f0 100644
--- a/tools/libxl/libxl_device.c
+++ b/tools/libxl/libxl_device.c
@@ -515,6 +515,7 @@ void libxl__multidev_prepared(libxl__egc *egc,
 
 DEFINE_DEVICES_ADD(disk)
 DEFINE_DEVICES_ADD(nic)
+DEFINE_DEVICES_ADD(vtpm)
 
 #undef DEFINE_DEVICES_ADD
 
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index b6f54ba..e9a7cbb 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -954,6 +954,7 @@ _hidden int libxl__device_disk_setdefault(libxl__gc *gc,
                                           libxl_device_disk *disk);
 _hidden int libxl__device_nic_setdefault(libxl__gc *gc, libxl_device_nic *nic,
                                          uint32_t domid);
+_hidden int libxl__device_vtpm_setdefault(libxl__gc *gc, libxl_device_vtpm *vtpm);
 _hidden int libxl__device_vfb_setdefault(libxl__gc *gc, libxl_device_vfb *vfb);
 _hidden int libxl__device_vkb_setdefault(libxl__gc *gc, libxl_device_vkb *vkb);
 _hidden int libxl__device_pci_setdefault(libxl__gc *gc, libxl_device_pci *pci);
@@ -1975,6 +1976,10 @@ _hidden void libxl__device_nic_add(libxl__egc *egc, uint32_t domid,
                                    libxl_device_nic *nic,
                                    libxl__ao_device *aodev);
 
+_hidden void libxl__device_vtpm_add(libxl__egc *egc, uint32_t domid,
+                                   libxl_device_vtpm *vtpm,
+                                   libxl__ao_device *aodev);
+
 /* Internal function to connect a vkb device */
 _hidden int libxl__device_vkb_add(libxl__gc *gc, uint32_t domid,
                                   libxl_device_vkb *vkb);
@@ -2407,6 +2412,10 @@ _hidden void libxl__add_nics(libxl__egc *egc, libxl__ao *ao, uint32_t domid,
                              libxl_domain_config *d_config,
                              libxl__multidev *multidev);
 
+_hidden void libxl__add_vtpms(libxl__egc *egc, libxl__ao *ao, uint32_t domid,
+                             libxl_domain_config *d_config,
+                             libxl__multidev *multidev);
+
 /*----- device model creation -----*/
 
 /* First layer; wraps libxl__spawn_spawn. */
diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
index de111a6..7eac4a8 100644
--- a/tools/libxl/libxl_types.idl
+++ b/tools/libxl/libxl_types.idl
@@ -395,6 +395,12 @@ libxl_device_pci = Struct("device_pci", [
     ("permissive", bool),
     ])
 
+libxl_device_vtpm = Struct("device_vtpm", [
+    ("backend_domid",    libxl_domid),
+    ("devid",            libxl_devid),
+    ("uuid",             libxl_uuid),
+])
+
 libxl_diskinfo = Struct("diskinfo", [
     ("backend", string),
     ("backend_id", uint32),
@@ -418,6 +424,18 @@ libxl_nicinfo = Struct("nicinfo", [
     ("rref_rx", integer),
     ], dir=DIR_OUT)
 
+libxl_vtpminfo = Struct("vtpminfo", [
+    ("backend", string),
+    ("backend_id", uint32),
+    ("frontend", string),
+    ("frontend_id", uint32),
+    ("devid", libxl_devid),
+    ("state", integer),
+    ("evtch", integer),
+    ("rref", integer),
+    ("uuid", libxl_uuid),
+    ], dir=DIR_OUT)
+
 libxl_vcpuinfo = Struct("vcpuinfo", [
     ("vcpuid", uint32),
     ("cpu", uint32),
diff --git a/tools/libxl/libxl_types_internal.idl b/tools/libxl/libxl_types_internal.idl
index 5ac8c9c..c40120e 100644
--- a/tools/libxl/libxl_types_internal.idl
+++ b/tools/libxl/libxl_types_internal.idl
@@ -19,6 +19,7 @@ libxl__device_kind = Enumeration("device_kind", [
     (5, "VFB"),
     (6, "VKBD"),
     (7, "CONSOLE"),
+    (8, "VTPM"),
     ])
 
 libxl__console_backend = Enumeration("console_backend", [
diff --git a/tools/libxl/libxl_utils.c b/tools/libxl/libxl_utils.c
index 55cd299..73a158a 100644
--- a/tools/libxl/libxl_utils.c
+++ b/tools/libxl/libxl_utils.c
@@ -463,6 +463,35 @@ int libxl_pipe(libxl_ctx *ctx, int pipes[2])
     return 0;
 }
 
+int libxl_uuid_to_device_vtpm(libxl_ctx *ctx, uint32_t domid,
+                            libxl_uuid* uuid, libxl_device_vtpm *vtpm)
+{
+    libxl_device_vtpm *vtpms;
+    int nb, i;
+    int rc;
+
+    vtpms = libxl_device_vtpm_list(ctx, domid, &nb);
+    if (!vtpms)
+        return ERROR_FAIL;
+
+    memset(vtpm, 0, sizeof (libxl_device_vtpm));
+    rc = 1;
+    for (i = 0; i < nb; ++i) {
+        if(!libxl_uuid_compare(uuid, &vtpms[i].uuid)) {
+            vtpm->backend_domid = vtpms[i].backend_domid;
+            vtpm->devid = vtpms[i].devid;
+            libxl_uuid_copy(&vtpm->uuid, &vtpms[i].uuid);
+            rc = 0;
+            break;
+        }
+    }
+
+    for (i=0; i<nb; i++)
+        libxl_device_vtpm_dispose(&vtpms[i]);
+    free(vtpms);
+    return rc;
+}
+
 int libxl_mac_to_device_nic(libxl_ctx *ctx, uint32_t domid,
                             const char *mac, libxl_device_nic *nic)
 {
diff --git a/tools/libxl/libxl_utils.h b/tools/libxl/libxl_utils.h
index 83aaac7..40f3f30 100644
--- a/tools/libxl/libxl_utils.h
+++ b/tools/libxl/libxl_utils.h
@@ -64,6 +64,11 @@ int libxl_devid_to_device_nic(libxl_ctx *ctx, uint32_t domid, int devid,
 int libxl_vdev_to_device_disk(libxl_ctx *ctx, uint32_t domid, const char *vdev,
                                libxl_device_disk *disk);
 
+int libxl_uuid_to_device_vtpm(libxl_ctx *ctx, uint32_t domid,
+                               libxl_uuid *uuid, libxl_device_vtpm *vtpm);
+int libxl_devid_to_device_vtpm(libxl_ctx *ctx, uint32_t domid,
+                               int devid, libxl_device_vtpm *vtpm);
+
 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. */
diff --git a/tools/libxl/xl.h b/tools/libxl/xl.h
index 0b2f848..be6f38b 100644
--- a/tools/libxl/xl.h
+++ b/tools/libxl/xl.h
@@ -79,6 +79,9 @@ int main_networkdetach(int argc, char **argv);
 int main_blockattach(int argc, char **argv);
 int main_blocklist(int argc, char **argv);
 int main_blockdetach(int argc, char **argv);
+int main_vtpmattach(int argc, char **argv);
+int main_vtpmlist(int argc, char **argv);
+int main_vtpmdetach(int argc, char **argv);
 int main_uptime(int argc, char **argv);
 int main_tmem_list(int argc, char **argv);
 int main_tmem_freeze(int argc, char **argv);
diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index fe8e925..3f02f6d 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -573,7 +573,7 @@ static void parse_config_data(const char *config_source,
     const char *buf;
     long l;
     XLU_Config *config;
-    XLU_ConfigList *cpus, *vbds, *nics, *pcis, *cvfbs, *cpuids;
+    XLU_ConfigList *cpus, *vbds, *nics, *pcis, *cvfbs, *cpuids, *vtpms;
     XLU_ConfigList *ioports, *irqs, *iomem;
     int num_ioports, num_irqs, num_iomem;
     int pci_power_mgmt = 0;
@@ -1045,6 +1045,47 @@ static void parse_config_data(const char *config_source,
         }
     }
 
+    if (!xlu_cfg_get_list(config, "vtpm", &vtpms, 0, 0)) {
+        d_config->num_vtpms = 0;
+        d_config->vtpms = NULL;
+        while ((buf = xlu_cfg_get_listitem (vtpms, d_config->num_vtpms)) != NULL) {
+            libxl_device_vtpm *vtpm;
+            char * buf2 = strdup(buf);
+            char *p, *p2;
+
+            d_config->vtpms = (libxl_device_vtpm *) realloc(d_config->vtpms, sizeof(libxl_device_vtpm) * (d_config->num_vtpms+1));
+            vtpm = d_config->vtpms + d_config->num_vtpms;
+            libxl_device_vtpm_init(vtpm);
+            vtpm->devid = d_config->num_vtpms;
+
+            p = strtok(buf2, ",");
+            if (!p)
+                goto skip_vtpm;
+            do {
+                while(*p == ' ')
+                    ++p;
+                if ((p2 = strchr(p, '=')) == NULL)
+                    break;
+                *p2 = '\0';
+                if (!strcmp(p, "backend")) {
+                    if(domain_qualifier_to_domid(p2 + 1, &(vtpm->backend_domid), 0))
+                    {
+                        fprintf(stderr, "Specified backend domain does not exist, defaulting to Dom0\n");
+                        vtpm->backend_domid = 0;
+                    }
+                } else if(!strcmp(p, "uuid")) {
+                    if( libxl_uuid_from_string(&vtpm->uuid, p2 + 1) ) {
+                        fprintf(stderr, "Failed to parse vtpm UUID: %s\n", p2 + 1);
+                        exit(1);
+                    }
+                }
+            } while ((p = strtok(NULL, ",")) != NULL);
+skip_vtpm:
+            free(buf2);
+            d_config->num_vtpms++;
+        }
+    }
+
     if (!xlu_cfg_get_list (config, "vif", &nics, 0, 0)) {
         d_config->num_nics = 0;
         d_config->nics = NULL;
@@ -1070,7 +1111,7 @@ static void parse_config_data(const char *config_source,
 
             p = strtok(buf2, ",");
             if (!p)
-                goto skip;
+                goto skip_nic;
             do {
                 while (*p == ' ')
                     p++;
@@ -1134,7 +1175,7 @@ static void parse_config_data(const char *config_source,
                     fprintf(stderr, "the accel parameter for vifs is currently not supported\n");
                 }
             } while ((p = strtok(NULL, ",")) != NULL);
-skip:
+skip_nic:
             free(buf2);
             d_config->num_nics++;
         }
@@ -5570,6 +5611,131 @@ int main_blockdetach(int argc, char **argv)
     return rc;
 }
 
+int main_vtpmattach(int argc, char **argv)
+{
+    int opt;
+    libxl_device_vtpm vtpm;
+    char *oparg;
+    unsigned int val;
+    uint32_t domid;
+
+    if ((opt = def_getopt(argc, argv, "", "vtpm-attach", 1)) != -1)
+        return opt;
+
+    if (domain_qualifier_to_domid(argv[optind], &domid, 0) < 0) {
+        fprintf(stderr, "%s is an invalid domain identifier\n", argv[optind]);
+        return 1;
+    }
+    ++optind;
+
+    libxl_device_vtpm_init(&vtpm);
+    for (argv += optind, argc -= optind; argc > 0; ++argv, --argc) {
+        if (MATCH_OPTION("uuid", *argv, oparg)) {
+            if(libxl_uuid_from_string(&(vtpm.uuid), oparg)) {
+                fprintf(stderr, "Invalid uuid specified (%s)\n", oparg);
+                return 1;
+            }
+        } else if (MATCH_OPTION("backend", *argv, oparg)) {
+            if(domain_qualifier_to_domid(oparg, &val, 0)) {
+                fprintf(stderr, "Specified backend domain does not exist, defaulting to Dom0\n");
+                val = 0;
+            }
+            vtpm.backend_domid = val;
+        } else {
+            fprintf(stderr, "unrecognized argument `%s'\n", *argv);
+            return 1;
+        }
+    }
+
+    if(dryrun_only) {
+       char* json = libxl_device_vtpm_to_json(ctx, &vtpm);
+       printf("vtpm: %s\n", json);
+       free(json);
+       libxl_device_vtpm_dispose(&vtpm);
+       if (ferror(stdout) || fflush(stdout)) { perror("stdout"); exit(-1); }
+       return 0;
+    }
+
+    if (libxl_device_vtpm_add(ctx, domid, &vtpm, 0)) {
+        fprintf(stderr, "libxl_device_vtpm_add failed.\n");
+        return 1;
+    }
+    libxl_device_vtpm_dispose(&vtpm);
+    return 0;
+}
+
+int main_vtpmlist(int argc, char **argv)
+{
+    int opt;
+    libxl_device_vtpm *vtpms;
+    libxl_vtpminfo vtpminfo;
+    int nb, i;
+
+    if ((opt = def_getopt(argc, argv, "", "vtpm-list", 1)) != -1)
+        return opt;
+
+    /*      Idx  BE   UUID   Hdl  Sta  evch rref  BE-path */
+    printf("%-3s %-2s %-36s %-6s %-5s %-6s %-5s %-10s\n",
+           "Idx", "BE", "Uuid", "handle", "state", "evt-ch", "ring-ref", "BE-path");
+    for (argv += optind, argc -= optind; argc > 0; --argc, ++argv) {
+        uint32_t domid;
+        if (domain_qualifier_to_domid(*argv, &domid, 0) < 0) {
+            fprintf(stderr, "%s is an invalid domain identifier\n", *argv);
+            continue;
+        }
+        if (!(vtpms = libxl_device_vtpm_list(ctx, domid, &nb))) {
+            continue;
+        }
+        for (i = 0; i < nb; ++i) {
+           if(!libxl_device_vtpm_getinfo(ctx, domid, &vtpms[i], &vtpminfo)) {
+              /*      Idx  BE     UUID             Hdl Sta evch rref BE-path*/
+              printf("%-3d %-2d " LIBXL_UUID_FMT " %6d %5d %6d %8d %-30s\n",
+                    vtpminfo.devid, vtpminfo.backend_id,
+                    LIBXL_UUID_BYTES(vtpminfo.uuid),
+                    vtpminfo.devid, vtpminfo.state, vtpminfo.evtch,
+                    vtpminfo.rref, vtpminfo.backend);
+
+              libxl_vtpminfo_dispose(&vtpminfo);
+           }
+           libxl_device_vtpm_dispose(&vtpms[i]);
+        }
+        free(vtpms);
+    }
+    return 0;
+}
+
+int main_vtpmdetach(int argc, char **argv)
+{
+    uint32_t domid;
+    int opt, rc=0;
+    libxl_device_vtpm vtpm;
+    libxl_uuid uuid;
+
+    if ((opt = def_getopt(argc, argv, "", "vtpm-detach", 2)) != -1)
+        return opt;
+
+    domid = find_domain(argv[optind]);
+
+    if ( libxl_uuid_from_string(&uuid, argv[optind+1])) {
+        if (libxl_devid_to_device_vtpm(ctx, domid, atoi(argv[optind+1]), &vtpm)) {
+            fprintf(stderr, "Unknown device %s.\n", argv[optind+1]);
+            return 1;
+        }
+    } else {
+        if (libxl_uuid_to_device_vtpm(ctx, domid, &uuid, &vtpm)) {
+            fprintf(stderr, "Unknown device %s.\n", argv[optind+1]);
+            return 1;
+        }
+    }
+    rc = libxl_device_vtpm_remove(ctx, domid, &vtpm, 0);
+    if (rc) {
+        fprintf(stderr, "libxl_device_vtpm_remove failed.\n");
+    }
+    libxl_device_vtpm_dispose(&vtpm);
+    return rc;
+}
+
+
 static char *uptime_to_string(unsigned long uptime, int short_mode)
 {
     int sec, min, hour, day;
diff --git a/tools/libxl/xl_cmdtable.c b/tools/libxl/xl_cmdtable.c
index 85ea768..7c018eb 100644
--- a/tools/libxl/xl_cmdtable.c
+++ b/tools/libxl/xl_cmdtable.c
@@ -338,6 +338,21 @@ struct cmd_spec cmd_table[] = {
       "Destroy a domain's virtual block device",
       "<Domain> <DevId>",
     },
+    { "vtpm-attach",
+      &main_vtpmattach, 0, 1,
+      "Create a new virtual TPM device",
+      "<Domain> [uuid=<uuid>] [backend=<BackDomain>]",
+    },
+    { "vtpm-list",
+      &main_vtpmlist, 0, 0,
+      "List virtual TPM devices for a domain",
+      "<Domain(s)>",
+    },
+    { "vtpm-detach",
+      &main_vtpmdetach, 0, 1,
+      "Destroy a domain's virtual TPM device",
+      "<Domain> <DevId|uuid>",
+    },
     { "uptime",
       &main_uptime, 0, 0,
       "Print uptime for all/some domains",
-- 
1.7.9.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 27 17:12:37 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Sep 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 1THHdZ-0006h7-C8; Thu, 27 Sep 2012 17:12:33 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <matthew.fioravante@jhuapl.edu>) id 1THHdX-0006fq-Nl
	for xen-devel@lists.xen.org; Thu, 27 Sep 2012 17:12:32 +0000
Received: from [85.158.137.99:29268] by server-2.bemta-3.messagelabs.com id
	23/27-16514-EF884605; Thu, 27 Sep 2012 17:12:30 +0000
X-Env-Sender: matthew.fioravante@jhuapl.edu
X-Msg-Ref: server-13.tower-217.messagelabs.com!1348765948!19420031!1
X-Originating-IP: [128.244.251.36]
X-SpamReason: No, hits=0.0 required=7.0 tests=UNPARSEABLE_RELAY
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8239 invoked from network); 27 Sep 2012 17:12:29 -0000
Received: from pilot.jhuapl.edu (HELO jhuapl.edu) (128.244.251.36)
	by server-13.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 27 Sep 2012 17:12:29 -0000
Received: from ([128.244.207.89])
	by pilot.jhuapl.edu with ESMTP with TLS id 63GHCH1.153803007;
	Thu, 27 Sep 2012 13:12:20 -0400
From: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
To: xen-devel@lists.xen.org,
	Ian.Campbell@citrix.com
Date: Thu, 27 Sep 2012 13:10:59 -0400
Message-Id: <1348765860-11359-2-git-send-email-matthew.fioravante@jhuapl.edu>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <1348765860-11359-1-git-send-email-matthew.fioravante@jhuapl.edu>
References: <1348765860-11359-1-git-send-email-matthew.fioravante@jhuapl.edu>
Cc: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
Subject: [Xen-devel] [PATCH 10/11] make devid a type so it is initialized
	properly
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Previously device ids in libxl were treated as integers meaning they
were being initialized to 0, which is a valid device id. This patch
makes devid its own type in libxl and initializes it to -1, an invalid
value.

This fixes a bug where if you try to do a xl DEV-attach multiple
time it will continuously try to reattach device 0 instead of
generating a new device id.

Signed-off-by: Matthew Fioravante <matthew.fioravante@jhuapl.edu>

diff --git a/tools/libxl/gentest.py b/tools/libxl/gentest.py
index 2915f71..84b4fd7 100644
--- a/tools/libxl/gentest.py
+++ b/tools/libxl/gentest.py
@@ -60,7 +60,7 @@ def gen_rand_init(ty, v, indent = "    ", parent = None):
                                         passby=idl.PASS_BY_REFERENCE))
     elif ty.typename in ["libxl_uuid", "libxl_mac", "libxl_hwcap"]:
         s += "rand_bytes((uint8_t *)%s, sizeof(*%s));\n" % (v,v)
-    elif ty.typename in ["libxl_domid"] or isinstance(ty, idl.Number):
+    elif ty.typename in ["libxl_domid", "libxl_devid"] or isinstance(ty, idl.Number):
         s += "%s = rand() %% (sizeof(%s)*8);\n" % \
              (ty.pass_arg(v, parent is None),
               ty.pass_arg(v, parent is None))
diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index 599c7f1..7a7c419 100644
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -307,6 +307,7 @@ void libxl_cpuid_dispose(libxl_cpuid_policy_list *cpuid_list);
 #define LIBXL_PCI_FUNC_ALL (~0U)
 
 typedef uint32_t libxl_domid;
+typedef int libxl_devid;
 
 /*
  * Formatting Enumerations.
diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
index cf83c60..de111a6 100644
--- a/tools/libxl/libxl_types.idl
+++ b/tools/libxl/libxl_types.idl
@@ -8,6 +8,7 @@ namespace("libxl_")
 libxl_defbool = Builtin("defbool", passby=PASS_BY_REFERENCE)
 
 libxl_domid = Builtin("domid", json_fn = "yajl_gen_integer", autogenerate_json = False)
+libxl_devid = Builtin("devid", json_fn = "yajl_gen_integer", autogenerate_json = False, signed = True, init_val="-1")
 libxl_uuid = Builtin("uuid", passby=PASS_BY_REFERENCE)
 libxl_mac = Builtin("mac", passby=PASS_BY_REFERENCE)
 libxl_bitmap = Builtin("bitmap", dispose_fn="libxl_bitmap_dispose", passby=PASS_BY_REFERENCE)
@@ -343,7 +344,7 @@ libxl_domain_build_info = Struct("domain_build_info",[
 
 libxl_device_vfb = Struct("device_vfb", [
     ("backend_domid", libxl_domid),
-    ("devid",         integer),
+    ("devid",         libxl_devid),
     ("vnc",           libxl_vnc_info),
     ("sdl",           libxl_sdl_info),
     # set keyboard layout, default is en-us keyboard
@@ -352,7 +353,7 @@ libxl_device_vfb = Struct("device_vfb", [
 
 libxl_device_vkb = Struct("device_vkb", [
     ("backend_domid", libxl_domid),
-    ("devid", integer),
+    ("devid", libxl_devid),
     ])
 
 libxl_device_disk = Struct("device_disk", [
@@ -369,7 +370,7 @@ libxl_device_disk = Struct("device_disk", [
 
 libxl_device_nic = Struct("device_nic", [
     ("backend_domid", libxl_domid),
-    ("devid", integer),
+    ("devid", libxl_devid),
     ("mtu", integer),
     ("model", string),
     ("mac", libxl_mac),
@@ -399,7 +400,7 @@ libxl_diskinfo = Struct("diskinfo", [
     ("backend_id", uint32),
     ("frontend", string),
     ("frontend_id", uint32),
-    ("devid", integer),
+    ("devid", libxl_devid),
     ("state", integer),
     ("evtch", integer),
     ("rref", integer),
@@ -410,7 +411,7 @@ libxl_nicinfo = Struct("nicinfo", [
     ("backend_id", uint32),
     ("frontend", string),
     ("frontend_id", uint32),
-    ("devid", integer),
+    ("devid", libxl_devid),
     ("state", integer),
     ("evtch", integer),
     ("rref_tx", integer),
diff --git a/tools/ocaml/libs/xl/genwrap.py b/tools/ocaml/libs/xl/genwrap.py
index 42f374e..97d088d 100644
--- a/tools/ocaml/libs/xl/genwrap.py
+++ b/tools/ocaml/libs/xl/genwrap.py
@@ -10,6 +10,7 @@ builtins = {
     "int":                  ("int",                    "%(c)s = Int_val(%(o)s)",            "Val_int(%(c)s)"  ),
     "char *":               ("string",                 "%(c)s = dup_String_val(gc, %(o)s)", "caml_copy_string(%(c)s)"),
     "libxl_domid":          ("domid",                  "%(c)s = Int_val(%(o)s)",            "Val_int(%(c)s)"  ),
+    "libxl_devid":          ("devid",                  "%(c)s = Int_val(%(o)s)",            "Val_int(%(c)s)"  ),
     "libxl_defbool":        ("bool option",            "%(c)s = Defbool_val(%(o)s)",        "Val_defbool(%(c)s)" ),
     "libxl_uuid":           ("int array",              "Uuid_val(gc, lg, &%(c)s, %(o)s)",   "Val_uuid(&%(c)s)"),
     "libxl_key_value_list": ("(string * string) list", None,                                None),
@@ -41,8 +42,8 @@ def stub_fn_name(ty, name):
     return "stub_xl_%s_%s" % (ty.rawname,name)
     
 def ocaml_type_of(ty):
-    if ty.rawname == "domid":
-        return "domid"
+    if ty.rawname in ["domid","devid"]:
+        return ty.rawname
     elif isinstance(ty,idl.UInt):
         if ty.width in [8, 16]:
             # handle as ints
diff --git a/tools/ocaml/libs/xl/xenlight.ml.in b/tools/ocaml/libs/xl/xenlight.ml.in
index c47623c..dcc1a38 100644
--- a/tools/ocaml/libs/xl/xenlight.ml.in
+++ b/tools/ocaml/libs/xl/xenlight.ml.in
@@ -16,6 +16,7 @@
 exception Error of string
 
 type domid = int
+type devid = int
 
 (* @@LIBXL_TYPES@@ *)
 
diff --git a/tools/ocaml/libs/xl/xenlight.mli.in b/tools/ocaml/libs/xl/xenlight.mli.in
index 4717bac..3fd0165 100644
--- a/tools/ocaml/libs/xl/xenlight.mli.in
+++ b/tools/ocaml/libs/xl/xenlight.mli.in
@@ -16,6 +16,7 @@
 exception Error of string
 
 type domid = int
+type devid = int
 
 (* @@LIBXL_TYPES@@ *)
 
diff --git a/tools/python/xen/lowlevel/xl/xl.c b/tools/python/xen/lowlevel/xl/xl.c
index 0551c76..32f982a 100644
--- a/tools/python/xen/lowlevel/xl/xl.c
+++ b/tools/python/xen/lowlevel/xl/xl.c
@@ -281,6 +281,11 @@ int attrib__libxl_domid_set(PyObject *v, libxl_domid *domid) {
     return 0;
 }
 
+int attrib__libxl_devid_set(PyObject *v, libxl_devid *devid) {
+   *devid = PyInt_AsLong(v);
+   return 0;
+}
+
 int attrib__struct_in_addr_set(PyObject *v, struct in_addr *pptr)
 {
     PyErr_SetString(PyExc_NotImplementedError, "Setting in_addr");
@@ -342,6 +347,10 @@ PyObject *attrib__libxl_domid_get(libxl_domid *domid) {
     return PyInt_FromLong(*domid);
 }
 
+PyObject *attrib__libxl_devid_get(libxl_devid *devid) {
+    return PyInt_FromLong(*devid);
+}
+
 PyObject *attrib__struct_in_addr_get(struct in_addr *pptr)
 {
     PyErr_SetString(PyExc_NotImplementedError, "Getting in_addr");
-- 
1.7.9.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 27 17:12:37 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Sep 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 1THHdZ-0006h7-C8; Thu, 27 Sep 2012 17:12:33 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <matthew.fioravante@jhuapl.edu>) id 1THHdX-0006fq-Nl
	for xen-devel@lists.xen.org; Thu, 27 Sep 2012 17:12:32 +0000
Received: from [85.158.137.99:29268] by server-2.bemta-3.messagelabs.com id
	23/27-16514-EF884605; Thu, 27 Sep 2012 17:12:30 +0000
X-Env-Sender: matthew.fioravante@jhuapl.edu
X-Msg-Ref: server-13.tower-217.messagelabs.com!1348765948!19420031!1
X-Originating-IP: [128.244.251.36]
X-SpamReason: No, hits=0.0 required=7.0 tests=UNPARSEABLE_RELAY
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8239 invoked from network); 27 Sep 2012 17:12:29 -0000
Received: from pilot.jhuapl.edu (HELO jhuapl.edu) (128.244.251.36)
	by server-13.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 27 Sep 2012 17:12:29 -0000
Received: from ([128.244.207.89])
	by pilot.jhuapl.edu with ESMTP with TLS id 63GHCH1.153803007;
	Thu, 27 Sep 2012 13:12:20 -0400
From: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
To: xen-devel@lists.xen.org,
	Ian.Campbell@citrix.com
Date: Thu, 27 Sep 2012 13:10:59 -0400
Message-Id: <1348765860-11359-2-git-send-email-matthew.fioravante@jhuapl.edu>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <1348765860-11359-1-git-send-email-matthew.fioravante@jhuapl.edu>
References: <1348765860-11359-1-git-send-email-matthew.fioravante@jhuapl.edu>
Cc: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
Subject: [Xen-devel] [PATCH 10/11] make devid a type so it is initialized
	properly
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Previously device ids in libxl were treated as integers meaning they
were being initialized to 0, which is a valid device id. This patch
makes devid its own type in libxl and initializes it to -1, an invalid
value.

This fixes a bug where if you try to do a xl DEV-attach multiple
time it will continuously try to reattach device 0 instead of
generating a new device id.

Signed-off-by: Matthew Fioravante <matthew.fioravante@jhuapl.edu>

diff --git a/tools/libxl/gentest.py b/tools/libxl/gentest.py
index 2915f71..84b4fd7 100644
--- a/tools/libxl/gentest.py
+++ b/tools/libxl/gentest.py
@@ -60,7 +60,7 @@ def gen_rand_init(ty, v, indent = "    ", parent = None):
                                         passby=idl.PASS_BY_REFERENCE))
     elif ty.typename in ["libxl_uuid", "libxl_mac", "libxl_hwcap"]:
         s += "rand_bytes((uint8_t *)%s, sizeof(*%s));\n" % (v,v)
-    elif ty.typename in ["libxl_domid"] or isinstance(ty, idl.Number):
+    elif ty.typename in ["libxl_domid", "libxl_devid"] or isinstance(ty, idl.Number):
         s += "%s = rand() %% (sizeof(%s)*8);\n" % \
              (ty.pass_arg(v, parent is None),
               ty.pass_arg(v, parent is None))
diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index 599c7f1..7a7c419 100644
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -307,6 +307,7 @@ void libxl_cpuid_dispose(libxl_cpuid_policy_list *cpuid_list);
 #define LIBXL_PCI_FUNC_ALL (~0U)
 
 typedef uint32_t libxl_domid;
+typedef int libxl_devid;
 
 /*
  * Formatting Enumerations.
diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
index cf83c60..de111a6 100644
--- a/tools/libxl/libxl_types.idl
+++ b/tools/libxl/libxl_types.idl
@@ -8,6 +8,7 @@ namespace("libxl_")
 libxl_defbool = Builtin("defbool", passby=PASS_BY_REFERENCE)
 
 libxl_domid = Builtin("domid", json_fn = "yajl_gen_integer", autogenerate_json = False)
+libxl_devid = Builtin("devid", json_fn = "yajl_gen_integer", autogenerate_json = False, signed = True, init_val="-1")
 libxl_uuid = Builtin("uuid", passby=PASS_BY_REFERENCE)
 libxl_mac = Builtin("mac", passby=PASS_BY_REFERENCE)
 libxl_bitmap = Builtin("bitmap", dispose_fn="libxl_bitmap_dispose", passby=PASS_BY_REFERENCE)
@@ -343,7 +344,7 @@ libxl_domain_build_info = Struct("domain_build_info",[
 
 libxl_device_vfb = Struct("device_vfb", [
     ("backend_domid", libxl_domid),
-    ("devid",         integer),
+    ("devid",         libxl_devid),
     ("vnc",           libxl_vnc_info),
     ("sdl",           libxl_sdl_info),
     # set keyboard layout, default is en-us keyboard
@@ -352,7 +353,7 @@ libxl_device_vfb = Struct("device_vfb", [
 
 libxl_device_vkb = Struct("device_vkb", [
     ("backend_domid", libxl_domid),
-    ("devid", integer),
+    ("devid", libxl_devid),
     ])
 
 libxl_device_disk = Struct("device_disk", [
@@ -369,7 +370,7 @@ libxl_device_disk = Struct("device_disk", [
 
 libxl_device_nic = Struct("device_nic", [
     ("backend_domid", libxl_domid),
-    ("devid", integer),
+    ("devid", libxl_devid),
     ("mtu", integer),
     ("model", string),
     ("mac", libxl_mac),
@@ -399,7 +400,7 @@ libxl_diskinfo = Struct("diskinfo", [
     ("backend_id", uint32),
     ("frontend", string),
     ("frontend_id", uint32),
-    ("devid", integer),
+    ("devid", libxl_devid),
     ("state", integer),
     ("evtch", integer),
     ("rref", integer),
@@ -410,7 +411,7 @@ libxl_nicinfo = Struct("nicinfo", [
     ("backend_id", uint32),
     ("frontend", string),
     ("frontend_id", uint32),
-    ("devid", integer),
+    ("devid", libxl_devid),
     ("state", integer),
     ("evtch", integer),
     ("rref_tx", integer),
diff --git a/tools/ocaml/libs/xl/genwrap.py b/tools/ocaml/libs/xl/genwrap.py
index 42f374e..97d088d 100644
--- a/tools/ocaml/libs/xl/genwrap.py
+++ b/tools/ocaml/libs/xl/genwrap.py
@@ -10,6 +10,7 @@ builtins = {
     "int":                  ("int",                    "%(c)s = Int_val(%(o)s)",            "Val_int(%(c)s)"  ),
     "char *":               ("string",                 "%(c)s = dup_String_val(gc, %(o)s)", "caml_copy_string(%(c)s)"),
     "libxl_domid":          ("domid",                  "%(c)s = Int_val(%(o)s)",            "Val_int(%(c)s)"  ),
+    "libxl_devid":          ("devid",                  "%(c)s = Int_val(%(o)s)",            "Val_int(%(c)s)"  ),
     "libxl_defbool":        ("bool option",            "%(c)s = Defbool_val(%(o)s)",        "Val_defbool(%(c)s)" ),
     "libxl_uuid":           ("int array",              "Uuid_val(gc, lg, &%(c)s, %(o)s)",   "Val_uuid(&%(c)s)"),
     "libxl_key_value_list": ("(string * string) list", None,                                None),
@@ -41,8 +42,8 @@ def stub_fn_name(ty, name):
     return "stub_xl_%s_%s" % (ty.rawname,name)
     
 def ocaml_type_of(ty):
-    if ty.rawname == "domid":
-        return "domid"
+    if ty.rawname in ["domid","devid"]:
+        return ty.rawname
     elif isinstance(ty,idl.UInt):
         if ty.width in [8, 16]:
             # handle as ints
diff --git a/tools/ocaml/libs/xl/xenlight.ml.in b/tools/ocaml/libs/xl/xenlight.ml.in
index c47623c..dcc1a38 100644
--- a/tools/ocaml/libs/xl/xenlight.ml.in
+++ b/tools/ocaml/libs/xl/xenlight.ml.in
@@ -16,6 +16,7 @@
 exception Error of string
 
 type domid = int
+type devid = int
 
 (* @@LIBXL_TYPES@@ *)
 
diff --git a/tools/ocaml/libs/xl/xenlight.mli.in b/tools/ocaml/libs/xl/xenlight.mli.in
index 4717bac..3fd0165 100644
--- a/tools/ocaml/libs/xl/xenlight.mli.in
+++ b/tools/ocaml/libs/xl/xenlight.mli.in
@@ -16,6 +16,7 @@
 exception Error of string
 
 type domid = int
+type devid = int
 
 (* @@LIBXL_TYPES@@ *)
 
diff --git a/tools/python/xen/lowlevel/xl/xl.c b/tools/python/xen/lowlevel/xl/xl.c
index 0551c76..32f982a 100644
--- a/tools/python/xen/lowlevel/xl/xl.c
+++ b/tools/python/xen/lowlevel/xl/xl.c
@@ -281,6 +281,11 @@ int attrib__libxl_domid_set(PyObject *v, libxl_domid *domid) {
     return 0;
 }
 
+int attrib__libxl_devid_set(PyObject *v, libxl_devid *devid) {
+   *devid = PyInt_AsLong(v);
+   return 0;
+}
+
 int attrib__struct_in_addr_set(PyObject *v, struct in_addr *pptr)
 {
     PyErr_SetString(PyExc_NotImplementedError, "Setting in_addr");
@@ -342,6 +347,10 @@ PyObject *attrib__libxl_domid_get(libxl_domid *domid) {
     return PyInt_FromLong(*domid);
 }
 
+PyObject *attrib__libxl_devid_get(libxl_devid *devid) {
+    return PyInt_FromLong(*devid);
+}
+
 PyObject *attrib__struct_in_addr_get(struct in_addr *pptr)
 {
     PyErr_SetString(PyExc_NotImplementedError, "Getting in_addr");
-- 
1.7.9.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 27 18:07:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Sep 2012 18:07: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 1THIUK-0000si-Af; Thu, 27 Sep 2012 18:07:04 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <SRS0=Sf9V=H2=oracle.com=daniel.kiper@net-space.pl>)
	id 1THIUH-0000rD-An
	for xen-devel@lists.xensource.com; Thu, 27 Sep 2012 18:07:01 +0000
Received: from [85.158.138.51:42607] by server-10.bemta-3.messagelabs.com id
	5C/3A-02525-4C594605; Thu, 27 Sep 2012 18:07:00 +0000
X-Env-Sender: SRS0=Sf9V=H2=oracle.com=daniel.kiper@net-space.pl
X-Msg-Ref: server-14.tower-174.messagelabs.com!1348769218!25906058!7
X-Originating-IP: [89.174.63.77]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31600 invoked from network); 27 Sep 2012 18:07:00 -0000
Received: from router-fw.net-space.pl (HELO router-fw.net-space.pl)
	(89.174.63.77)
	by server-14.tower-174.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 27 Sep 2012 18:07:00 -0000
Received: from dev-00.local.net-space.pl ([192.168.1.5]:54110 "EHLO
	localhost.localdomain" TLS-CIPHER: <none>)
	by router-fw-old.local.net-space.pl with ESMTP id S1623305Ab2I0SGj
	(ORCPT <rfc822;xen-devel@lists.xensource.com>);
	Thu, 27 Sep 2012 20:06:39 +0200
From: Daniel Kiper <daniel.kiper@oracle.com>
To: konrad.wilk@oracle.com, andrew.cooper3@citrix.com,
	jbeulich@suse.com, linux-kernel@vger.kernel.org,
	xen-devel@lists.xensource.com
Date: Thu, 27 Sep 2012 20:06:37 +0200
Message-Id: <1348769198-29580-11-git-send-email-daniel.kiper@oracle.com>
X-Mailer: git-send-email 1.5.6.5
In-Reply-To: <1348769198-29580-10-git-send-email-daniel.kiper@oracle.com>
References: <1348769198-29580-1-git-send-email-daniel.kiper@oracle.com>
	<1348769198-29580-2-git-send-email-daniel.kiper@oracle.com>
	<1348769198-29580-3-git-send-email-daniel.kiper@oracle.com>
	<1348769198-29580-4-git-send-email-daniel.kiper@oracle.com>
	<1348769198-29580-5-git-send-email-daniel.kiper@oracle.com>
	<1348769198-29580-6-git-send-email-daniel.kiper@oracle.com>
	<1348769198-29580-7-git-send-email-daniel.kiper@oracle.com>
	<1348769198-29580-8-git-send-email-daniel.kiper@oracle.com>
	<1348769198-29580-9-git-send-email-daniel.kiper@oracle.com>
	<1348769198-29580-10-git-send-email-daniel.kiper@oracle.com>
X-Bogosity: No, spamicity=0.000114
Cc: Daniel Kiper <daniel.kiper@oracle.com>
Subject: [Xen-devel] [PATCH 10/11] drivers/xen: Export vmcoreinfo through
	sysfs
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Export vmcoreinfo through sysfs.

Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
---
 drivers/xen/sys-hypervisor.c |   42 +++++++++++++++++++++++++++++++++++++++++-
 1 files changed, 41 insertions(+), 1 deletions(-)

diff --git a/drivers/xen/sys-hypervisor.c b/drivers/xen/sys-hypervisor.c
index fdb6d22..0111ad0 100644
--- a/drivers/xen/sys-hypervisor.c
+++ b/drivers/xen/sys-hypervisor.c
@@ -355,6 +355,41 @@ static void xen_properties_destroy(void)
 	sysfs_remove_group(hypervisor_kobj, &xen_properties_group);
 }
 
+#ifdef CONFIG_KEXEC
+static ssize_t vmcoreinfo_show(struct hyp_sysfs_attr *attr, char *buffer)
+{
+	return sprintf(buffer, "%lx %lx\n", xen_vmcoreinfo_maddr,
+						xen_vmcoreinfo_max_size);
+}
+
+HYPERVISOR_ATTR_RO(vmcoreinfo);
+
+static int __init xen_vmcoreinfo_init(void)
+{
+	if (!xen_vmcoreinfo_max_size)
+		return 0;
+
+	return sysfs_create_file(hypervisor_kobj, &vmcoreinfo_attr.attr);
+}
+
+static void xen_vmcoreinfo_destroy(void)
+{
+	if (!xen_vmcoreinfo_max_size)
+		return;
+
+	sysfs_remove_file(hypervisor_kobj, &vmcoreinfo_attr.attr);
+}
+#else
+static int __init xen_vmcoreinfo_init(void)
+{
+	return 0;
+}
+
+static void xen_vmcoreinfo_destroy(void)
+{
+}
+#endif
+
 static int __init hyper_sysfs_init(void)
 {
 	int ret;
@@ -377,9 +412,14 @@ static int __init hyper_sysfs_init(void)
 	ret = xen_properties_init();
 	if (ret)
 		goto prop_out;
+	ret = xen_vmcoreinfo_init();
+	if (ret)
+		goto vmcoreinfo_out;
 
 	goto out;
 
+vmcoreinfo_out:
+	xen_properties_destroy();
 prop_out:
 	xen_sysfs_uuid_destroy();
 uuid_out:
@@ -394,12 +434,12 @@ out:
 
 static void __exit hyper_sysfs_exit(void)
 {
+	xen_vmcoreinfo_destroy();
 	xen_properties_destroy();
 	xen_compilation_destroy();
 	xen_sysfs_uuid_destroy();
 	xen_sysfs_version_destroy();
 	xen_sysfs_type_destroy();
-
 }
 module_init(hyper_sysfs_init);
 module_exit(hyper_sysfs_exit);
-- 
1.5.6.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 27 18:07:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Sep 2012 18:07: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 1THIUK-0000si-Af; Thu, 27 Sep 2012 18:07:04 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <SRS0=Sf9V=H2=oracle.com=daniel.kiper@net-space.pl>)
	id 1THIUH-0000rD-An
	for xen-devel@lists.xensource.com; Thu, 27 Sep 2012 18:07:01 +0000
Received: from [85.158.138.51:42607] by server-10.bemta-3.messagelabs.com id
	5C/3A-02525-4C594605; Thu, 27 Sep 2012 18:07:00 +0000
X-Env-Sender: SRS0=Sf9V=H2=oracle.com=daniel.kiper@net-space.pl
X-Msg-Ref: server-14.tower-174.messagelabs.com!1348769218!25906058!7
X-Originating-IP: [89.174.63.77]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31600 invoked from network); 27 Sep 2012 18:07:00 -0000
Received: from router-fw.net-space.pl (HELO router-fw.net-space.pl)
	(89.174.63.77)
	by server-14.tower-174.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 27 Sep 2012 18:07:00 -0000
Received: from dev-00.local.net-space.pl ([192.168.1.5]:54110 "EHLO
	localhost.localdomain" TLS-CIPHER: <none>)
	by router-fw-old.local.net-space.pl with ESMTP id S1623305Ab2I0SGj
	(ORCPT <rfc822;xen-devel@lists.xensource.com>);
	Thu, 27 Sep 2012 20:06:39 +0200
From: Daniel Kiper <daniel.kiper@oracle.com>
To: konrad.wilk@oracle.com, andrew.cooper3@citrix.com,
	jbeulich@suse.com, linux-kernel@vger.kernel.org,
	xen-devel@lists.xensource.com
Date: Thu, 27 Sep 2012 20:06:37 +0200
Message-Id: <1348769198-29580-11-git-send-email-daniel.kiper@oracle.com>
X-Mailer: git-send-email 1.5.6.5
In-Reply-To: <1348769198-29580-10-git-send-email-daniel.kiper@oracle.com>
References: <1348769198-29580-1-git-send-email-daniel.kiper@oracle.com>
	<1348769198-29580-2-git-send-email-daniel.kiper@oracle.com>
	<1348769198-29580-3-git-send-email-daniel.kiper@oracle.com>
	<1348769198-29580-4-git-send-email-daniel.kiper@oracle.com>
	<1348769198-29580-5-git-send-email-daniel.kiper@oracle.com>
	<1348769198-29580-6-git-send-email-daniel.kiper@oracle.com>
	<1348769198-29580-7-git-send-email-daniel.kiper@oracle.com>
	<1348769198-29580-8-git-send-email-daniel.kiper@oracle.com>
	<1348769198-29580-9-git-send-email-daniel.kiper@oracle.com>
	<1348769198-29580-10-git-send-email-daniel.kiper@oracle.com>
X-Bogosity: No, spamicity=0.000114
Cc: Daniel Kiper <daniel.kiper@oracle.com>
Subject: [Xen-devel] [PATCH 10/11] drivers/xen: Export vmcoreinfo through
	sysfs
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Export vmcoreinfo through sysfs.

Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
---
 drivers/xen/sys-hypervisor.c |   42 +++++++++++++++++++++++++++++++++++++++++-
 1 files changed, 41 insertions(+), 1 deletions(-)

diff --git a/drivers/xen/sys-hypervisor.c b/drivers/xen/sys-hypervisor.c
index fdb6d22..0111ad0 100644
--- a/drivers/xen/sys-hypervisor.c
+++ b/drivers/xen/sys-hypervisor.c
@@ -355,6 +355,41 @@ static void xen_properties_destroy(void)
 	sysfs_remove_group(hypervisor_kobj, &xen_properties_group);
 }
 
+#ifdef CONFIG_KEXEC
+static ssize_t vmcoreinfo_show(struct hyp_sysfs_attr *attr, char *buffer)
+{
+	return sprintf(buffer, "%lx %lx\n", xen_vmcoreinfo_maddr,
+						xen_vmcoreinfo_max_size);
+}
+
+HYPERVISOR_ATTR_RO(vmcoreinfo);
+
+static int __init xen_vmcoreinfo_init(void)
+{
+	if (!xen_vmcoreinfo_max_size)
+		return 0;
+
+	return sysfs_create_file(hypervisor_kobj, &vmcoreinfo_attr.attr);
+}
+
+static void xen_vmcoreinfo_destroy(void)
+{
+	if (!xen_vmcoreinfo_max_size)
+		return;
+
+	sysfs_remove_file(hypervisor_kobj, &vmcoreinfo_attr.attr);
+}
+#else
+static int __init xen_vmcoreinfo_init(void)
+{
+	return 0;
+}
+
+static void xen_vmcoreinfo_destroy(void)
+{
+}
+#endif
+
 static int __init hyper_sysfs_init(void)
 {
 	int ret;
@@ -377,9 +412,14 @@ static int __init hyper_sysfs_init(void)
 	ret = xen_properties_init();
 	if (ret)
 		goto prop_out;
+	ret = xen_vmcoreinfo_init();
+	if (ret)
+		goto vmcoreinfo_out;
 
 	goto out;
 
+vmcoreinfo_out:
+	xen_properties_destroy();
 prop_out:
 	xen_sysfs_uuid_destroy();
 uuid_out:
@@ -394,12 +434,12 @@ out:
 
 static void __exit hyper_sysfs_exit(void)
 {
+	xen_vmcoreinfo_destroy();
 	xen_properties_destroy();
 	xen_compilation_destroy();
 	xen_sysfs_uuid_destroy();
 	xen_sysfs_version_destroy();
 	xen_sysfs_type_destroy();
-
 }
 module_init(hyper_sysfs_init);
 module_exit(hyper_sysfs_exit);
-- 
1.5.6.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 27 18:07:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Sep 2012 18:07: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 1THIUM-0000ul-Vo; Thu, 27 Sep 2012 18:07:06 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <SRS0=Sf9V=H2=oracle.com=daniel.kiper@net-space.pl>)
	id 1THIUI-0000r0-UT
	for xen-devel@lists.xensource.com; Thu, 27 Sep 2012 18:07:03 +0000
Received: from [85.158.138.51:42653] by server-8.bemta-3.messagelabs.com id
	B3/33-16337-5C594605; Thu, 27 Sep 2012 18:07:01 +0000
X-Env-Sender: SRS0=Sf9V=H2=oracle.com=daniel.kiper@net-space.pl
X-Msg-Ref: server-14.tower-174.messagelabs.com!1348769218!25906058!9
X-Originating-IP: [89.174.63.77]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31627 invoked from network); 27 Sep 2012 18:07:00 -0000
Received: from router-fw.net-space.pl (HELO router-fw.net-space.pl)
	(89.174.63.77)
	by server-14.tower-174.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 27 Sep 2012 18:07:00 -0000
Received: from dev-00.local.net-space.pl ([192.168.1.5]:54110 "EHLO
	localhost.localdomain" TLS-CIPHER: <none>)
	by router-fw-old.local.net-space.pl with ESMTP id S1623299Ab2I0SGj
	(ORCPT <rfc822;xen-devel@lists.xensource.com>);
	Thu, 27 Sep 2012 20:06:39 +0200
From: Daniel Kiper <daniel.kiper@oracle.com>
To: konrad.wilk@oracle.com, andrew.cooper3@citrix.com,
	jbeulich@suse.com, linux-kernel@vger.kernel.org,
	xen-devel@lists.xensource.com
Date: Thu, 27 Sep 2012 20:06:33 +0200
Message-Id: <1348769198-29580-7-git-send-email-daniel.kiper@oracle.com>
X-Mailer: git-send-email 1.5.6.5
In-Reply-To: <1348769198-29580-6-git-send-email-daniel.kiper@oracle.com>
References: <1348769198-29580-1-git-send-email-daniel.kiper@oracle.com>
	<1348769198-29580-2-git-send-email-daniel.kiper@oracle.com>
	<1348769198-29580-3-git-send-email-daniel.kiper@oracle.com>
	<1348769198-29580-4-git-send-email-daniel.kiper@oracle.com>
	<1348769198-29580-5-git-send-email-daniel.kiper@oracle.com>
	<1348769198-29580-6-git-send-email-daniel.kiper@oracle.com>
X-Bogosity: No, spamicity=0.001861
Cc: Daniel Kiper <daniel.kiper@oracle.com>
Subject: [Xen-devel] [PATCH 06/11] x86/xen: Add i386 kexec/kdump
	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>
MIME-Version: 1.0
Content-Type: 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 i386 kexec/kdump implementation.

Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
---
 arch/x86/xen/machine_kexec_32.c   |  245 ++++++++++++++++++++++++++++
 arch/x86/xen/relocate_kernel_32.S |  323 +++++++++++++++++++++++++++++++++++++
 2 files changed, 568 insertions(+), 0 deletions(-)
 create mode 100644 arch/x86/xen/machine_kexec_32.c
 create mode 100644 arch/x86/xen/relocate_kernel_32.S

diff --git a/arch/x86/xen/machine_kexec_32.c b/arch/x86/xen/machine_kexec_32.c
new file mode 100644
index 0000000..6b5141e
--- /dev/null
+++ b/arch/x86/xen/machine_kexec_32.c
@@ -0,0 +1,245 @@
+/*
+ * Copyright (c) 2011 Daniel Kiper
+ * Copyright (c) 2012 Daniel Kiper, Oracle Corporation
+ *
+ * kexec/kdump implementation for Xen was written by Daniel Kiper.
+ * Initial work on it was sponsored by Google under Google Summer
+ * of Code 2011 program and Citrix. Konrad Rzeszutek Wilk from Oracle
+ * was the mentor for this project.
+ *
+ * Some ideas are taken from:
+ *   - native kexec/kdump implementation,
+ *   - kexec/kdump implementation for Xen Linux Kernel Ver. 2.6.18,
+ *   - PV-GRUB.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License along
+ * with this program.  If not, see <http://www.gnu.org/licenses/>.
+ */
+
+#include <linux/errno.h>
+#include <linux/init.h>
+#include <linux/kernel.h>
+#include <linux/kexec.h>
+#include <linux/mm.h>
+#include <linux/string.h>
+
+#include <xen/xen.h>
+#include <xen/xen-ops.h>
+
+#include <asm/xen/hypercall.h>
+#include <asm/xen/kexec.h>
+#include <asm/xen/page.h>
+
+#define __ma(vaddr)	(virt_to_machine(vaddr).maddr)
+
+static struct page *kimage_alloc_pages(gfp_t gfp_mask,
+					unsigned int order,
+					unsigned long limit)
+{
+	struct page *pages;
+	unsigned int address_bits, i;
+
+	pages = alloc_pages(gfp_mask, order);
+
+	if (!pages)
+		return NULL;
+
+	address_bits = (limit == ULONG_MAX) ? BITS_PER_LONG : ilog2(limit);
+
+	/* Relocate set of pages below given limit. */
+	if (xen_create_contiguous_region((unsigned long)page_address(pages),
+							order, address_bits)) {
+		__free_pages(pages, order);
+		return NULL;
+	}
+
+	pages->mapping = NULL;
+	set_page_private(pages, order);
+
+	for (i = 0; i < (1 << order); ++i)
+		SetPageReserved(pages + i);
+
+	return pages;
+}
+
+static void kimage_free_pages(struct page *page)
+{
+	unsigned int i, order;
+
+	order = page_private(page);
+
+	for (i = 0; i < (1 << order); ++i)
+		ClearPageReserved(page + i);
+
+	xen_destroy_contiguous_region((unsigned long)page_address(page), order);
+	__free_pages(page, order);
+}
+
+static unsigned long xen_page_to_mfn(struct page *page)
+{
+	return pfn_to_mfn(page_to_pfn(page));
+}
+
+static struct page *xen_mfn_to_page(unsigned long mfn)
+{
+	return pfn_to_page(mfn_to_pfn(mfn));
+}
+
+static unsigned long xen_virt_to_machine(volatile void *address)
+{
+	return virt_to_machine(address).maddr;
+}
+
+static void *xen_machine_to_virt(unsigned long address)
+{
+	return phys_to_virt(machine_to_phys(XMADDR(address)).paddr);
+}
+
+static void free_transition_pgtable(struct kimage *image)
+{
+	free_page((unsigned long)image->arch.pgd);
+	free_page((unsigned long)image->arch.pmd0);
+	free_page((unsigned long)image->arch.pmd1);
+	free_page((unsigned long)image->arch.pte0);
+	free_page((unsigned long)image->arch.pte1);
+}
+
+static int alloc_transition_pgtable(struct kimage *image)
+{
+	image->arch.pgd = (pgd_t *)get_zeroed_page(GFP_KERNEL);
+
+	if (!image->arch.pgd)
+		goto err;
+
+	image->arch.pmd0 = (pmd_t *)get_zeroed_page(GFP_KERNEL);
+
+	if (!image->arch.pmd0)
+		goto err;
+
+	image->arch.pmd1 = (pmd_t *)get_zeroed_page(GFP_KERNEL);
+
+	if (!image->arch.pmd1)
+		goto err;
+
+	image->arch.pte0 = (pte_t *)get_zeroed_page(GFP_KERNEL);
+
+	if (!image->arch.pte0)
+		goto err;
+
+	image->arch.pte1 = (pte_t *)get_zeroed_page(GFP_KERNEL);
+
+	if (!image->arch.pte1)
+		goto err;
+
+	return 0;
+
+err:
+	free_transition_pgtable(image);
+
+	return -ENOMEM;
+}
+
+static int machine_xen_kexec_prepare(struct kimage *image)
+{
+#ifdef CONFIG_KEXEC_JUMP
+	if (image->preserve_context) {
+		pr_info_once("kexec: Context preservation is not "
+				"supported in Xen domains.\n");
+		return -ENOSYS;
+	}
+#endif
+
+	return alloc_transition_pgtable(image);
+}
+
+static int machine_xen_kexec_load(struct kimage *image)
+{
+	void *control_page;
+	struct xen_kexec_load xkl = {};
+
+	if (!image)
+		return 0;
+
+	control_page = page_address(image->control_code_page);
+	memcpy(control_page, xen_relocate_kernel, xen_kexec_control_code_size);
+
+	xkl.type = image->type;
+	xkl.image.page_list[XK_MA_CONTROL_PAGE] = __ma(control_page);
+	xkl.image.page_list[XK_MA_TABLE_PAGE] = 0; /* Unused. */
+	xkl.image.page_list[XK_MA_PGD_PAGE] = __ma(image->arch.pgd);
+	xkl.image.page_list[XK_MA_PUD0_PAGE] = 0; /* Unused. */
+	xkl.image.page_list[XK_MA_PUD1_PAGE] = 0; /* Unused. */
+	xkl.image.page_list[XK_MA_PMD0_PAGE] = __ma(image->arch.pmd0);
+	xkl.image.page_list[XK_MA_PMD1_PAGE] = __ma(image->arch.pmd1);
+	xkl.image.page_list[XK_MA_PTE0_PAGE] = __ma(image->arch.pte0);
+	xkl.image.page_list[XK_MA_PTE1_PAGE] = __ma(image->arch.pte1);
+	xkl.image.indirection_page = image->head;
+	xkl.image.start_address = image->start;
+
+	return HYPERVISOR_kexec_op(KEXEC_CMD_kexec_load, &xkl);
+}
+
+static void machine_xen_kexec_cleanup(struct kimage *image)
+{
+	free_transition_pgtable(image);
+}
+
+static void machine_xen_kexec_unload(struct kimage *image)
+{
+	int rc;
+	struct xen_kexec_load xkl = {};
+
+	if (!image)
+		return;
+
+	xkl.type = image->type;
+	rc = HYPERVISOR_kexec_op(KEXEC_CMD_kexec_unload, &xkl);
+
+	WARN(rc, "kexec: %s: HYPERVISOR_kexec_op(): %i\n", __func__, rc);
+}
+
+static void machine_xen_kexec_shutdown(void)
+{
+}
+
+static void machine_xen_kexec(struct kimage *image)
+{
+	int rc;
+	struct xen_kexec_exec xke = {};
+
+	xke.type = image->type;
+	rc = HYPERVISOR_kexec_op(KEXEC_CMD_kexec, &xke);
+
+	pr_emerg("kexec: %s: HYPERVISOR_kexec_op(): %i\n", __func__, rc);
+	BUG();
+}
+
+void __init xen_init_kexec_ops(void)
+{
+	if (!xen_initial_domain())
+		return;
+
+	kexec_ops.always_use_normal_alloc = true;
+	kexec_ops.kimage_alloc_pages = kimage_alloc_pages;
+	kexec_ops.kimage_free_pages = kimage_free_pages;
+	kexec_ops.page_to_pfn = xen_page_to_mfn;
+	kexec_ops.pfn_to_page = xen_mfn_to_page;
+	kexec_ops.virt_to_phys = xen_virt_to_machine;
+	kexec_ops.phys_to_virt = xen_machine_to_virt;
+	kexec_ops.machine_kexec_prepare = machine_xen_kexec_prepare;
+	kexec_ops.machine_kexec_load = machine_xen_kexec_load;
+	kexec_ops.machine_kexec_cleanup = machine_xen_kexec_cleanup;
+	kexec_ops.machine_kexec_unload = machine_xen_kexec_unload;
+	kexec_ops.machine_kexec_shutdown = machine_xen_kexec_shutdown;
+	kexec_ops.machine_kexec = machine_xen_kexec;
+}
diff --git a/arch/x86/xen/relocate_kernel_32.S b/arch/x86/xen/relocate_kernel_32.S
new file mode 100644
index 0000000..0e81830
--- /dev/null
+++ b/arch/x86/xen/relocate_kernel_32.S
@@ -0,0 +1,323 @@
+/*
+ * Copyright (c) 2002-2005 Eric Biederman <ebiederm@xmission.com>
+ * Copyright (c) 2011 Daniel Kiper
+ * Copyright (c) 2012 Daniel Kiper, Oracle Corporation
+ *
+ * kexec/kdump implementation for Xen was written by Daniel Kiper.
+ * Initial work on it was sponsored by Google under Google Summer
+ * of Code 2011 program and Citrix. Konrad Rzeszutek Wilk from Oracle
+ * was the mentor for this project.
+ *
+ * Some ideas are taken from:
+ *   - native kexec/kdump implementation,
+ *   - kexec/kdump implementation for Xen Linux Kernel Ver. 2.6.18,
+ *   - PV-GRUB.
+ *
+ * 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 veesion 2 of the License, or
+ * (at your option) any later veesion.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License along
+ * with this program.  If not, see <http://www.gnu.org/licenses/>.
+ */
+
+#include <asm/cache.h>
+#include <asm/page_types.h>
+#include <asm/pgtable_types.h>
+#include <asm/processor-flags.h>
+
+#include <asm/xen/kexec.h>
+
+#define ARG_INDIRECTION_PAGE	0x4
+#define ARG_PAGE_LIST		0x8
+#define ARG_START_ADDRESS	0xc
+
+#define PTR(x)	(x << 2)
+
+	.text
+	.align	PAGE_SIZE
+	.globl	xen_kexec_control_code_size, xen_relocate_kernel
+
+xen_relocate_kernel:
+	/*
+	 * Must be relocatable PIC code callable as a C function.
+	 *
+	 * This function is called by Xen but here hypervisor is dead.
+	 * We are playing on bare metal.
+	 *
+	 * Every machine address passed to this function through
+	 * page_list (e.g. XK_MA_CONTROL_PAGE) is established
+	 * by dom0 during kexec load phase.
+	 *
+	 * Every virtual address passed to this function through page_list
+	 * (e.g. XK_VA_CONTROL_PAGE) is established by hypervisor during
+	 * HYPERVISOR_kexec_op(KEXEC_CMD_kexec_load) hypercall.
+	 *
+	 * 0x4(%esp) - indirection_page,
+	 * 0x8(%esp) - page_list,
+	 * 0xc(%esp) - start_address,
+	 * 0x10(%esp) - cpu_has_pae (ignored),
+	 * 0x14(%esp) - preserve_context (ignored).
+	 */
+
+	/* Zero out flags, and disable interrupts. */
+	pushl	$0
+	popfl
+
+	/* Get page_list address. */
+	movl	ARG_PAGE_LIST(%esp), %esi
+
+	/*
+	 * Map the control page at its virtual address
+	 * in transition page table.
+	 */
+	movl	PTR(XK_VA_CONTROL_PAGE)(%esi), %eax
+
+	/* Get PGD address and PGD entry index. */
+	movl	PTR(XK_VA_PGD_PAGE)(%esi), %ebx
+	movl	%eax, %ecx
+	shrl	$PGDIR_SHIFT, %ecx
+	andl	$(PTRS_PER_PGD - 1), %ecx
+
+	/* Fill PGD entry with PMD0 reference. */
+	movl	PTR(XK_MA_PMD0_PAGE)(%esi), %edx
+	orl	$_PAGE_PRESENT, %edx
+	movl	%edx, (%ebx, %ecx, 8)
+
+	/* Get PMD0 address and PMD0 entry index. */
+	movl	PTR(XK_VA_PMD0_PAGE)(%esi), %ebx
+	movl	%eax, %ecx
+	shrl	$PMD_SHIFT, %ecx
+	andl	$(PTRS_PER_PMD - 1), %ecx
+
+	/* Fill PMD0 entry with PTE0 reference. */
+	movl	PTR(XK_MA_PTE0_PAGE)(%esi), %edx
+	orl	$_KERNPG_TABLE, %edx
+	movl	%edx, (%ebx, %ecx, 8)
+
+	/* Get PTE0 address and PTE0 entry index. */
+	movl	PTR(XK_VA_PTE0_PAGE)(%esi), %ebx
+	movl	%eax, %ecx
+	shrl	$PAGE_SHIFT, %ecx
+	andl	$(PTRS_PER_PTE - 1), %ecx
+
+	/* Fill PTE0 entry with control page reference. */
+	movl	PTR(XK_MA_CONTROL_PAGE)(%esi), %edx
+	orl	$__PAGE_KERNEL_EXEC, %edx
+	movl	%edx, (%ebx, %ecx, 8)
+
+	/*
+	 * Identity map the control page at its machine address
+	 * in transition page table.
+	 */
+	movl	PTR(XK_MA_CONTROL_PAGE)(%esi), %eax
+
+	/* Get PGD address and PGD entry index. */
+	movl	PTR(XK_VA_PGD_PAGE)(%esi), %ebx
+	movl	%eax, %ecx
+	shrl	$PGDIR_SHIFT, %ecx
+	andl	$(PTRS_PER_PGD - 1), %ecx
+
+	/* Fill PGD entry with PMD1 reference. */
+	movl	PTR(XK_MA_PMD1_PAGE)(%esi), %edx
+	orl	$_PAGE_PRESENT, %edx
+	movl	%edx, (%ebx, %ecx, 8)
+
+	/* Get PMD1 address and PMD1 entry index. */
+	movl	PTR(XK_VA_PMD1_PAGE)(%esi), %ebx
+	movl	%eax, %ecx
+	shrl	$PMD_SHIFT, %ecx
+	andl	$(PTRS_PER_PMD - 1), %ecx
+
+	/* Fill PMD1 entry with PTE1 reference. */
+	movl	PTR(XK_MA_PTE1_PAGE)(%esi), %edx
+	orl	$_KERNPG_TABLE, %edx
+	movl	%edx, (%ebx, %ecx, 8)
+
+	/* Get PTE1 address and PTE1 entry index. */
+	movl	PTR(XK_VA_PTE1_PAGE)(%esi), %ebx
+	movl	%eax, %ecx
+	shrl	$PAGE_SHIFT, %ecx
+	andl	$(PTRS_PER_PTE - 1), %ecx
+
+	/* Fill PTE1 entry with control page reference. */
+	movl	PTR(XK_MA_CONTROL_PAGE)(%esi), %edx
+	orl	$__PAGE_KERNEL_EXEC, %edx
+	movl	%edx, (%ebx, %ecx, 8)
+
+	/*
+	 * Get machine address of control page now.
+	 * This is impossible after page table switch.
+	 */
+	movl	PTR(XK_MA_CONTROL_PAGE)(%esi), %ebx
+
+	/* Get machine address of transition page table now too. */
+	movl	PTR(XK_MA_PGD_PAGE)(%esi), %ecx
+
+	/* Get start_address too. */
+	movl	ARG_START_ADDRESS(%esp), %edx
+
+	/* Get indirection_page address too. */
+	movl	ARG_INDIRECTION_PAGE(%esp), %edi
+
+	/* Switch to transition page table. */
+	movl	%ecx, %cr3
+
+	/* Load IDT. */
+	lidtl	(idt_48 - xen_relocate_kernel)(%ebx)
+
+	/* Load GDT. */
+	leal	(gdt - xen_relocate_kernel)(%ebx), %eax
+	movl	%eax, (gdt_48 - xen_relocate_kernel + 2)(%ebx)
+	lgdtl	(gdt_48 - xen_relocate_kernel)(%ebx)
+
+	/* Load data segment registers. */
+	movl	$(gdt_ds - gdt), %eax
+	movl	%eax, %ds
+	movl	%eax, %es
+	movl	%eax, %fs
+	movl	%eax, %gs
+	movl	%eax, %ss
+
+	/* Setup a new stack at the end of machine address of control page. */
+	leal	PAGE_SIZE(%ebx), %esp
+
+	/* Store start_address on the stack. */
+	pushl   %edx
+
+	/* Jump to identity mapped page. */
+	pushl	$0
+	pushl	$(gdt_cs - gdt)
+	addl	$(identity_mapped - xen_relocate_kernel), %ebx
+	pushl	%ebx
+	iretl
+
+identity_mapped:
+	/*
+	 * Set %cr0 to a known state:
+	 *   - disable alignment check,
+	 *   - disable floating point emulation,
+	 *   - disable paging,
+	 *   - no task switch,
+	 *   - disable write protect,
+	 *   - enable protected mode.
+	 */
+	movl	%cr0, %eax
+	andl	$~(X86_CR0_AM | X86_CR0_EM | X86_CR0_PG | X86_CR0_TS | X86_CR0_WP), %eax
+	orl	$(X86_CR0_PE), %eax
+	movl	%eax, %cr0
+
+	/* Set %cr4 to a known state. */
+	xorl	%eax, %eax
+	movl	%eax, %cr4
+
+	jmp	1f
+
+1:
+	/* Flush the TLB (needed?). */
+	movl	%eax, %cr3
+
+	/* Do the copies. */
+	movl	%edi, %ecx	/* Put the indirection_page in %ecx. */
+	xorl	%edi, %edi
+	xorl	%esi, %esi
+	jmp	1f
+
+0:
+	/*
+	 * Top, read another doubleword from the indirection page.
+	 * Indirection page is an array which contains source
+	 * and destination address pairs. If all pairs could
+	 * not fit in one page then at the end of given
+	 * indirection page is pointer to next one.
+	 * Copy is stopped when done indicator
+	 * is found in indirection page.
+	 */
+	movl	(%ebx), %ecx
+	addl	$4, %ebx
+
+1:
+	testl	$0x1, %ecx	/* Is it a destination page? */
+	jz	2f
+
+	movl	%ecx, %edi
+	andl	$PAGE_MASK, %edi
+	jmp	0b
+
+2:
+	testl	$0x2, %ecx	/* Is it an indirection page? */
+	jz	2f
+
+	movl	%ecx, %ebx
+	andl	$PAGE_MASK, %ebx
+	jmp	0b
+
+2:
+	testl	$0x4, %ecx	/* Is it the done indicator? */
+	jz	2f
+	jmp	3f
+
+2:
+	testl	$0x8, %ecx	/* Is it the source indicator? */
+	jz	0b		/* Ignore it otherwise. */
+
+	movl	%ecx, %esi
+	andl	$PAGE_MASK, %esi
+	movl	$1024, %ecx
+
+	/* Copy page. */
+	rep	movsl
+	jmp	0b
+
+3:
+	/*
+	 * To be certain of avoiding problems with self-modifying code
+	 * I need to execute a serializing instruction here.
+	 * So I flush the TLB by reloading %cr3 here, it's handy,
+	 * and not processor dependent.
+	 */
+	xorl	%eax, %eax
+	movl	%eax, %cr3
+
+	/*
+	 * Set all of the registers to known values.
+	 * Leave %esp alone.
+	 */
+	xorl	%ebx, %ebx
+	xorl    %ecx, %ecx
+	xorl    %edx, %edx
+	xorl    %esi, %esi
+	xorl    %edi, %edi
+	xorl    %ebp, %ebp
+
+	/* Jump to start_address. */
+	retl
+
+	.align	L1_CACHE_BYTES
+
+gdt:
+	.quad	0x0000000000000000	/* NULL descriptor. */
+
+gdt_cs:
+	.quad	0x00cf9a000000ffff	/* 4 GiB code segment at 0x00000000. */
+
+gdt_ds:
+	.quad	0x00cf92000000ffff	/* 4 GiB data segment at 0x00000000. */
+gdt_end:
+
+gdt_48:
+	.word	gdt_end - gdt - 1	/* GDT limit. */
+	.long	0			/* GDT base - filled in by code above. */
+
+idt_48:
+	.word	0			/* IDT limit. */
+	.long	0			/* IDT base. */
+
+xen_kexec_control_code_size:
+	.long	. - xen_relocate_kernel
-- 
1.5.6.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 27 18:07:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Sep 2012 18:07: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 1THIUM-0000ul-Vo; Thu, 27 Sep 2012 18:07:06 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <SRS0=Sf9V=H2=oracle.com=daniel.kiper@net-space.pl>)
	id 1THIUI-0000r0-UT
	for xen-devel@lists.xensource.com; Thu, 27 Sep 2012 18:07:03 +0000
Received: from [85.158.138.51:42653] by server-8.bemta-3.messagelabs.com id
	B3/33-16337-5C594605; Thu, 27 Sep 2012 18:07:01 +0000
X-Env-Sender: SRS0=Sf9V=H2=oracle.com=daniel.kiper@net-space.pl
X-Msg-Ref: server-14.tower-174.messagelabs.com!1348769218!25906058!9
X-Originating-IP: [89.174.63.77]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31627 invoked from network); 27 Sep 2012 18:07:00 -0000
Received: from router-fw.net-space.pl (HELO router-fw.net-space.pl)
	(89.174.63.77)
	by server-14.tower-174.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 27 Sep 2012 18:07:00 -0000
Received: from dev-00.local.net-space.pl ([192.168.1.5]:54110 "EHLO
	localhost.localdomain" TLS-CIPHER: <none>)
	by router-fw-old.local.net-space.pl with ESMTP id S1623299Ab2I0SGj
	(ORCPT <rfc822;xen-devel@lists.xensource.com>);
	Thu, 27 Sep 2012 20:06:39 +0200
From: Daniel Kiper <daniel.kiper@oracle.com>
To: konrad.wilk@oracle.com, andrew.cooper3@citrix.com,
	jbeulich@suse.com, linux-kernel@vger.kernel.org,
	xen-devel@lists.xensource.com
Date: Thu, 27 Sep 2012 20:06:33 +0200
Message-Id: <1348769198-29580-7-git-send-email-daniel.kiper@oracle.com>
X-Mailer: git-send-email 1.5.6.5
In-Reply-To: <1348769198-29580-6-git-send-email-daniel.kiper@oracle.com>
References: <1348769198-29580-1-git-send-email-daniel.kiper@oracle.com>
	<1348769198-29580-2-git-send-email-daniel.kiper@oracle.com>
	<1348769198-29580-3-git-send-email-daniel.kiper@oracle.com>
	<1348769198-29580-4-git-send-email-daniel.kiper@oracle.com>
	<1348769198-29580-5-git-send-email-daniel.kiper@oracle.com>
	<1348769198-29580-6-git-send-email-daniel.kiper@oracle.com>
X-Bogosity: No, spamicity=0.001861
Cc: Daniel Kiper <daniel.kiper@oracle.com>
Subject: [Xen-devel] [PATCH 06/11] x86/xen: Add i386 kexec/kdump
	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>
MIME-Version: 1.0
Content-Type: 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 i386 kexec/kdump implementation.

Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
---
 arch/x86/xen/machine_kexec_32.c   |  245 ++++++++++++++++++++++++++++
 arch/x86/xen/relocate_kernel_32.S |  323 +++++++++++++++++++++++++++++++++++++
 2 files changed, 568 insertions(+), 0 deletions(-)
 create mode 100644 arch/x86/xen/machine_kexec_32.c
 create mode 100644 arch/x86/xen/relocate_kernel_32.S

diff --git a/arch/x86/xen/machine_kexec_32.c b/arch/x86/xen/machine_kexec_32.c
new file mode 100644
index 0000000..6b5141e
--- /dev/null
+++ b/arch/x86/xen/machine_kexec_32.c
@@ -0,0 +1,245 @@
+/*
+ * Copyright (c) 2011 Daniel Kiper
+ * Copyright (c) 2012 Daniel Kiper, Oracle Corporation
+ *
+ * kexec/kdump implementation for Xen was written by Daniel Kiper.
+ * Initial work on it was sponsored by Google under Google Summer
+ * of Code 2011 program and Citrix. Konrad Rzeszutek Wilk from Oracle
+ * was the mentor for this project.
+ *
+ * Some ideas are taken from:
+ *   - native kexec/kdump implementation,
+ *   - kexec/kdump implementation for Xen Linux Kernel Ver. 2.6.18,
+ *   - PV-GRUB.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License along
+ * with this program.  If not, see <http://www.gnu.org/licenses/>.
+ */
+
+#include <linux/errno.h>
+#include <linux/init.h>
+#include <linux/kernel.h>
+#include <linux/kexec.h>
+#include <linux/mm.h>
+#include <linux/string.h>
+
+#include <xen/xen.h>
+#include <xen/xen-ops.h>
+
+#include <asm/xen/hypercall.h>
+#include <asm/xen/kexec.h>
+#include <asm/xen/page.h>
+
+#define __ma(vaddr)	(virt_to_machine(vaddr).maddr)
+
+static struct page *kimage_alloc_pages(gfp_t gfp_mask,
+					unsigned int order,
+					unsigned long limit)
+{
+	struct page *pages;
+	unsigned int address_bits, i;
+
+	pages = alloc_pages(gfp_mask, order);
+
+	if (!pages)
+		return NULL;
+
+	address_bits = (limit == ULONG_MAX) ? BITS_PER_LONG : ilog2(limit);
+
+	/* Relocate set of pages below given limit. */
+	if (xen_create_contiguous_region((unsigned long)page_address(pages),
+							order, address_bits)) {
+		__free_pages(pages, order);
+		return NULL;
+	}
+
+	pages->mapping = NULL;
+	set_page_private(pages, order);
+
+	for (i = 0; i < (1 << order); ++i)
+		SetPageReserved(pages + i);
+
+	return pages;
+}
+
+static void kimage_free_pages(struct page *page)
+{
+	unsigned int i, order;
+
+	order = page_private(page);
+
+	for (i = 0; i < (1 << order); ++i)
+		ClearPageReserved(page + i);
+
+	xen_destroy_contiguous_region((unsigned long)page_address(page), order);
+	__free_pages(page, order);
+}
+
+static unsigned long xen_page_to_mfn(struct page *page)
+{
+	return pfn_to_mfn(page_to_pfn(page));
+}
+
+static struct page *xen_mfn_to_page(unsigned long mfn)
+{
+	return pfn_to_page(mfn_to_pfn(mfn));
+}
+
+static unsigned long xen_virt_to_machine(volatile void *address)
+{
+	return virt_to_machine(address).maddr;
+}
+
+static void *xen_machine_to_virt(unsigned long address)
+{
+	return phys_to_virt(machine_to_phys(XMADDR(address)).paddr);
+}
+
+static void free_transition_pgtable(struct kimage *image)
+{
+	free_page((unsigned long)image->arch.pgd);
+	free_page((unsigned long)image->arch.pmd0);
+	free_page((unsigned long)image->arch.pmd1);
+	free_page((unsigned long)image->arch.pte0);
+	free_page((unsigned long)image->arch.pte1);
+}
+
+static int alloc_transition_pgtable(struct kimage *image)
+{
+	image->arch.pgd = (pgd_t *)get_zeroed_page(GFP_KERNEL);
+
+	if (!image->arch.pgd)
+		goto err;
+
+	image->arch.pmd0 = (pmd_t *)get_zeroed_page(GFP_KERNEL);
+
+	if (!image->arch.pmd0)
+		goto err;
+
+	image->arch.pmd1 = (pmd_t *)get_zeroed_page(GFP_KERNEL);
+
+	if (!image->arch.pmd1)
+		goto err;
+
+	image->arch.pte0 = (pte_t *)get_zeroed_page(GFP_KERNEL);
+
+	if (!image->arch.pte0)
+		goto err;
+
+	image->arch.pte1 = (pte_t *)get_zeroed_page(GFP_KERNEL);
+
+	if (!image->arch.pte1)
+		goto err;
+
+	return 0;
+
+err:
+	free_transition_pgtable(image);
+
+	return -ENOMEM;
+}
+
+static int machine_xen_kexec_prepare(struct kimage *image)
+{
+#ifdef CONFIG_KEXEC_JUMP
+	if (image->preserve_context) {
+		pr_info_once("kexec: Context preservation is not "
+				"supported in Xen domains.\n");
+		return -ENOSYS;
+	}
+#endif
+
+	return alloc_transition_pgtable(image);
+}
+
+static int machine_xen_kexec_load(struct kimage *image)
+{
+	void *control_page;
+	struct xen_kexec_load xkl = {};
+
+	if (!image)
+		return 0;
+
+	control_page = page_address(image->control_code_page);
+	memcpy(control_page, xen_relocate_kernel, xen_kexec_control_code_size);
+
+	xkl.type = image->type;
+	xkl.image.page_list[XK_MA_CONTROL_PAGE] = __ma(control_page);
+	xkl.image.page_list[XK_MA_TABLE_PAGE] = 0; /* Unused. */
+	xkl.image.page_list[XK_MA_PGD_PAGE] = __ma(image->arch.pgd);
+	xkl.image.page_list[XK_MA_PUD0_PAGE] = 0; /* Unused. */
+	xkl.image.page_list[XK_MA_PUD1_PAGE] = 0; /* Unused. */
+	xkl.image.page_list[XK_MA_PMD0_PAGE] = __ma(image->arch.pmd0);
+	xkl.image.page_list[XK_MA_PMD1_PAGE] = __ma(image->arch.pmd1);
+	xkl.image.page_list[XK_MA_PTE0_PAGE] = __ma(image->arch.pte0);
+	xkl.image.page_list[XK_MA_PTE1_PAGE] = __ma(image->arch.pte1);
+	xkl.image.indirection_page = image->head;
+	xkl.image.start_address = image->start;
+
+	return HYPERVISOR_kexec_op(KEXEC_CMD_kexec_load, &xkl);
+}
+
+static void machine_xen_kexec_cleanup(struct kimage *image)
+{
+	free_transition_pgtable(image);
+}
+
+static void machine_xen_kexec_unload(struct kimage *image)
+{
+	int rc;
+	struct xen_kexec_load xkl = {};
+
+	if (!image)
+		return;
+
+	xkl.type = image->type;
+	rc = HYPERVISOR_kexec_op(KEXEC_CMD_kexec_unload, &xkl);
+
+	WARN(rc, "kexec: %s: HYPERVISOR_kexec_op(): %i\n", __func__, rc);
+}
+
+static void machine_xen_kexec_shutdown(void)
+{
+}
+
+static void machine_xen_kexec(struct kimage *image)
+{
+	int rc;
+	struct xen_kexec_exec xke = {};
+
+	xke.type = image->type;
+	rc = HYPERVISOR_kexec_op(KEXEC_CMD_kexec, &xke);
+
+	pr_emerg("kexec: %s: HYPERVISOR_kexec_op(): %i\n", __func__, rc);
+	BUG();
+}
+
+void __init xen_init_kexec_ops(void)
+{
+	if (!xen_initial_domain())
+		return;
+
+	kexec_ops.always_use_normal_alloc = true;
+	kexec_ops.kimage_alloc_pages = kimage_alloc_pages;
+	kexec_ops.kimage_free_pages = kimage_free_pages;
+	kexec_ops.page_to_pfn = xen_page_to_mfn;
+	kexec_ops.pfn_to_page = xen_mfn_to_page;
+	kexec_ops.virt_to_phys = xen_virt_to_machine;
+	kexec_ops.phys_to_virt = xen_machine_to_virt;
+	kexec_ops.machine_kexec_prepare = machine_xen_kexec_prepare;
+	kexec_ops.machine_kexec_load = machine_xen_kexec_load;
+	kexec_ops.machine_kexec_cleanup = machine_xen_kexec_cleanup;
+	kexec_ops.machine_kexec_unload = machine_xen_kexec_unload;
+	kexec_ops.machine_kexec_shutdown = machine_xen_kexec_shutdown;
+	kexec_ops.machine_kexec = machine_xen_kexec;
+}
diff --git a/arch/x86/xen/relocate_kernel_32.S b/arch/x86/xen/relocate_kernel_32.S
new file mode 100644
index 0000000..0e81830
--- /dev/null
+++ b/arch/x86/xen/relocate_kernel_32.S
@@ -0,0 +1,323 @@
+/*
+ * Copyright (c) 2002-2005 Eric Biederman <ebiederm@xmission.com>
+ * Copyright (c) 2011 Daniel Kiper
+ * Copyright (c) 2012 Daniel Kiper, Oracle Corporation
+ *
+ * kexec/kdump implementation for Xen was written by Daniel Kiper.
+ * Initial work on it was sponsored by Google under Google Summer
+ * of Code 2011 program and Citrix. Konrad Rzeszutek Wilk from Oracle
+ * was the mentor for this project.
+ *
+ * Some ideas are taken from:
+ *   - native kexec/kdump implementation,
+ *   - kexec/kdump implementation for Xen Linux Kernel Ver. 2.6.18,
+ *   - PV-GRUB.
+ *
+ * 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 veesion 2 of the License, or
+ * (at your option) any later veesion.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License along
+ * with this program.  If not, see <http://www.gnu.org/licenses/>.
+ */
+
+#include <asm/cache.h>
+#include <asm/page_types.h>
+#include <asm/pgtable_types.h>
+#include <asm/processor-flags.h>
+
+#include <asm/xen/kexec.h>
+
+#define ARG_INDIRECTION_PAGE	0x4
+#define ARG_PAGE_LIST		0x8
+#define ARG_START_ADDRESS	0xc
+
+#define PTR(x)	(x << 2)
+
+	.text
+	.align	PAGE_SIZE
+	.globl	xen_kexec_control_code_size, xen_relocate_kernel
+
+xen_relocate_kernel:
+	/*
+	 * Must be relocatable PIC code callable as a C function.
+	 *
+	 * This function is called by Xen but here hypervisor is dead.
+	 * We are playing on bare metal.
+	 *
+	 * Every machine address passed to this function through
+	 * page_list (e.g. XK_MA_CONTROL_PAGE) is established
+	 * by dom0 during kexec load phase.
+	 *
+	 * Every virtual address passed to this function through page_list
+	 * (e.g. XK_VA_CONTROL_PAGE) is established by hypervisor during
+	 * HYPERVISOR_kexec_op(KEXEC_CMD_kexec_load) hypercall.
+	 *
+	 * 0x4(%esp) - indirection_page,
+	 * 0x8(%esp) - page_list,
+	 * 0xc(%esp) - start_address,
+	 * 0x10(%esp) - cpu_has_pae (ignored),
+	 * 0x14(%esp) - preserve_context (ignored).
+	 */
+
+	/* Zero out flags, and disable interrupts. */
+	pushl	$0
+	popfl
+
+	/* Get page_list address. */
+	movl	ARG_PAGE_LIST(%esp), %esi
+
+	/*
+	 * Map the control page at its virtual address
+	 * in transition page table.
+	 */
+	movl	PTR(XK_VA_CONTROL_PAGE)(%esi), %eax
+
+	/* Get PGD address and PGD entry index. */
+	movl	PTR(XK_VA_PGD_PAGE)(%esi), %ebx
+	movl	%eax, %ecx
+	shrl	$PGDIR_SHIFT, %ecx
+	andl	$(PTRS_PER_PGD - 1), %ecx
+
+	/* Fill PGD entry with PMD0 reference. */
+	movl	PTR(XK_MA_PMD0_PAGE)(%esi), %edx
+	orl	$_PAGE_PRESENT, %edx
+	movl	%edx, (%ebx, %ecx, 8)
+
+	/* Get PMD0 address and PMD0 entry index. */
+	movl	PTR(XK_VA_PMD0_PAGE)(%esi), %ebx
+	movl	%eax, %ecx
+	shrl	$PMD_SHIFT, %ecx
+	andl	$(PTRS_PER_PMD - 1), %ecx
+
+	/* Fill PMD0 entry with PTE0 reference. */
+	movl	PTR(XK_MA_PTE0_PAGE)(%esi), %edx
+	orl	$_KERNPG_TABLE, %edx
+	movl	%edx, (%ebx, %ecx, 8)
+
+	/* Get PTE0 address and PTE0 entry index. */
+	movl	PTR(XK_VA_PTE0_PAGE)(%esi), %ebx
+	movl	%eax, %ecx
+	shrl	$PAGE_SHIFT, %ecx
+	andl	$(PTRS_PER_PTE - 1), %ecx
+
+	/* Fill PTE0 entry with control page reference. */
+	movl	PTR(XK_MA_CONTROL_PAGE)(%esi), %edx
+	orl	$__PAGE_KERNEL_EXEC, %edx
+	movl	%edx, (%ebx, %ecx, 8)
+
+	/*
+	 * Identity map the control page at its machine address
+	 * in transition page table.
+	 */
+	movl	PTR(XK_MA_CONTROL_PAGE)(%esi), %eax
+
+	/* Get PGD address and PGD entry index. */
+	movl	PTR(XK_VA_PGD_PAGE)(%esi), %ebx
+	movl	%eax, %ecx
+	shrl	$PGDIR_SHIFT, %ecx
+	andl	$(PTRS_PER_PGD - 1), %ecx
+
+	/* Fill PGD entry with PMD1 reference. */
+	movl	PTR(XK_MA_PMD1_PAGE)(%esi), %edx
+	orl	$_PAGE_PRESENT, %edx
+	movl	%edx, (%ebx, %ecx, 8)
+
+	/* Get PMD1 address and PMD1 entry index. */
+	movl	PTR(XK_VA_PMD1_PAGE)(%esi), %ebx
+	movl	%eax, %ecx
+	shrl	$PMD_SHIFT, %ecx
+	andl	$(PTRS_PER_PMD - 1), %ecx
+
+	/* Fill PMD1 entry with PTE1 reference. */
+	movl	PTR(XK_MA_PTE1_PAGE)(%esi), %edx
+	orl	$_KERNPG_TABLE, %edx
+	movl	%edx, (%ebx, %ecx, 8)
+
+	/* Get PTE1 address and PTE1 entry index. */
+	movl	PTR(XK_VA_PTE1_PAGE)(%esi), %ebx
+	movl	%eax, %ecx
+	shrl	$PAGE_SHIFT, %ecx
+	andl	$(PTRS_PER_PTE - 1), %ecx
+
+	/* Fill PTE1 entry with control page reference. */
+	movl	PTR(XK_MA_CONTROL_PAGE)(%esi), %edx
+	orl	$__PAGE_KERNEL_EXEC, %edx
+	movl	%edx, (%ebx, %ecx, 8)
+
+	/*
+	 * Get machine address of control page now.
+	 * This is impossible after page table switch.
+	 */
+	movl	PTR(XK_MA_CONTROL_PAGE)(%esi), %ebx
+
+	/* Get machine address of transition page table now too. */
+	movl	PTR(XK_MA_PGD_PAGE)(%esi), %ecx
+
+	/* Get start_address too. */
+	movl	ARG_START_ADDRESS(%esp), %edx
+
+	/* Get indirection_page address too. */
+	movl	ARG_INDIRECTION_PAGE(%esp), %edi
+
+	/* Switch to transition page table. */
+	movl	%ecx, %cr3
+
+	/* Load IDT. */
+	lidtl	(idt_48 - xen_relocate_kernel)(%ebx)
+
+	/* Load GDT. */
+	leal	(gdt - xen_relocate_kernel)(%ebx), %eax
+	movl	%eax, (gdt_48 - xen_relocate_kernel + 2)(%ebx)
+	lgdtl	(gdt_48 - xen_relocate_kernel)(%ebx)
+
+	/* Load data segment registers. */
+	movl	$(gdt_ds - gdt), %eax
+	movl	%eax, %ds
+	movl	%eax, %es
+	movl	%eax, %fs
+	movl	%eax, %gs
+	movl	%eax, %ss
+
+	/* Setup a new stack at the end of machine address of control page. */
+	leal	PAGE_SIZE(%ebx), %esp
+
+	/* Store start_address on the stack. */
+	pushl   %edx
+
+	/* Jump to identity mapped page. */
+	pushl	$0
+	pushl	$(gdt_cs - gdt)
+	addl	$(identity_mapped - xen_relocate_kernel), %ebx
+	pushl	%ebx
+	iretl
+
+identity_mapped:
+	/*
+	 * Set %cr0 to a known state:
+	 *   - disable alignment check,
+	 *   - disable floating point emulation,
+	 *   - disable paging,
+	 *   - no task switch,
+	 *   - disable write protect,
+	 *   - enable protected mode.
+	 */
+	movl	%cr0, %eax
+	andl	$~(X86_CR0_AM | X86_CR0_EM | X86_CR0_PG | X86_CR0_TS | X86_CR0_WP), %eax
+	orl	$(X86_CR0_PE), %eax
+	movl	%eax, %cr0
+
+	/* Set %cr4 to a known state. */
+	xorl	%eax, %eax
+	movl	%eax, %cr4
+
+	jmp	1f
+
+1:
+	/* Flush the TLB (needed?). */
+	movl	%eax, %cr3
+
+	/* Do the copies. */
+	movl	%edi, %ecx	/* Put the indirection_page in %ecx. */
+	xorl	%edi, %edi
+	xorl	%esi, %esi
+	jmp	1f
+
+0:
+	/*
+	 * Top, read another doubleword from the indirection page.
+	 * Indirection page is an array which contains source
+	 * and destination address pairs. If all pairs could
+	 * not fit in one page then at the end of given
+	 * indirection page is pointer to next one.
+	 * Copy is stopped when done indicator
+	 * is found in indirection page.
+	 */
+	movl	(%ebx), %ecx
+	addl	$4, %ebx
+
+1:
+	testl	$0x1, %ecx	/* Is it a destination page? */
+	jz	2f
+
+	movl	%ecx, %edi
+	andl	$PAGE_MASK, %edi
+	jmp	0b
+
+2:
+	testl	$0x2, %ecx	/* Is it an indirection page? */
+	jz	2f
+
+	movl	%ecx, %ebx
+	andl	$PAGE_MASK, %ebx
+	jmp	0b
+
+2:
+	testl	$0x4, %ecx	/* Is it the done indicator? */
+	jz	2f
+	jmp	3f
+
+2:
+	testl	$0x8, %ecx	/* Is it the source indicator? */
+	jz	0b		/* Ignore it otherwise. */
+
+	movl	%ecx, %esi
+	andl	$PAGE_MASK, %esi
+	movl	$1024, %ecx
+
+	/* Copy page. */
+	rep	movsl
+	jmp	0b
+
+3:
+	/*
+	 * To be certain of avoiding problems with self-modifying code
+	 * I need to execute a serializing instruction here.
+	 * So I flush the TLB by reloading %cr3 here, it's handy,
+	 * and not processor dependent.
+	 */
+	xorl	%eax, %eax
+	movl	%eax, %cr3
+
+	/*
+	 * Set all of the registers to known values.
+	 * Leave %esp alone.
+	 */
+	xorl	%ebx, %ebx
+	xorl    %ecx, %ecx
+	xorl    %edx, %edx
+	xorl    %esi, %esi
+	xorl    %edi, %edi
+	xorl    %ebp, %ebp
+
+	/* Jump to start_address. */
+	retl
+
+	.align	L1_CACHE_BYTES
+
+gdt:
+	.quad	0x0000000000000000	/* NULL descriptor. */
+
+gdt_cs:
+	.quad	0x00cf9a000000ffff	/* 4 GiB code segment at 0x00000000. */
+
+gdt_ds:
+	.quad	0x00cf92000000ffff	/* 4 GiB data segment at 0x00000000. */
+gdt_end:
+
+gdt_48:
+	.word	gdt_end - gdt - 1	/* GDT limit. */
+	.long	0			/* GDT base - filled in by code above. */
+
+idt_48:
+	.word	0			/* IDT limit. */
+	.long	0			/* IDT base. */
+
+xen_kexec_control_code_size:
+	.long	. - xen_relocate_kernel
-- 
1.5.6.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 27 18:07:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Sep 2012 18:07: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 1THIUJ-0000s8-5D; Thu, 27 Sep 2012 18:07:03 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <SRS0=Sf9V=H2=oracle.com=daniel.kiper@net-space.pl>)
	id 1THIUG-0000r0-Fv
	for xen-devel@lists.xensource.com; Thu, 27 Sep 2012 18:07:00 +0000
Received: from [85.158.138.51:42574] by server-8.bemta-3.messagelabs.com id
	AD/23-16337-3C594605; Thu, 27 Sep 2012 18:06:59 +0000
X-Env-Sender: SRS0=Sf9V=H2=oracle.com=daniel.kiper@net-space.pl
X-Msg-Ref: server-14.tower-174.messagelabs.com!1348769218!25906058!2
X-Originating-IP: [89.174.63.77]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31563 invoked from network); 27 Sep 2012 18:06:58 -0000
Received: from router-fw.net-space.pl (HELO router-fw.net-space.pl)
	(89.174.63.77)
	by server-14.tower-174.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 27 Sep 2012 18:06:58 -0000
Received: from dev-00.local.net-space.pl ([192.168.1.5]:54110 "EHLO
	localhost.localdomain" TLS-CIPHER: <none>)
	by router-fw-old.local.net-space.pl with ESMTP id S1623296Ab2I0SGj
	(ORCPT <rfc822;xen-devel@lists.xensource.com>);
	Thu, 27 Sep 2012 20:06:39 +0200
From: Daniel Kiper <daniel.kiper@oracle.com>
To: konrad.wilk@oracle.com, andrew.cooper3@citrix.com,
	jbeulich@suse.com, linux-kernel@vger.kernel.org,
	xen-devel@lists.xensource.com
Date: Thu, 27 Sep 2012 20:06:30 +0200
Message-Id: <1348769198-29580-4-git-send-email-daniel.kiper@oracle.com>
X-Mailer: git-send-email 1.5.6.5
In-Reply-To: <1348769198-29580-3-git-send-email-daniel.kiper@oracle.com>
References: <1348769198-29580-1-git-send-email-daniel.kiper@oracle.com>
	<1348769198-29580-2-git-send-email-daniel.kiper@oracle.com>
	<1348769198-29580-3-git-send-email-daniel.kiper@oracle.com>
X-Bogosity: No, spamicity=0.016045
Cc: Daniel Kiper <daniel.kiper@oracle.com>
Subject: [Xen-devel] [PATCH 03/11] xen: Introduce architecture independent
	data for kexec/kdump
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 architecture independent constants and structures
required by Xen kexec/kdump implementation.

Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
---
 include/xen/interface/xen.h |   33 +++++++++++++++++++++++++++++++++
 1 files changed, 33 insertions(+), 0 deletions(-)

diff --git a/include/xen/interface/xen.h b/include/xen/interface/xen.h
index 0801468..ac19f9e 100644
--- a/include/xen/interface/xen.h
+++ b/include/xen/interface/xen.h
@@ -58,6 +58,7 @@
 #define __HYPERVISOR_event_channel_op     32
 #define __HYPERVISOR_physdev_op           33
 #define __HYPERVISOR_hvm_op               34
+#define __HYPERVISOR_kexec_op             37
 #define __HYPERVISOR_tmem_op              38
 
 /* Architecture-specific hypercall definitions. */
@@ -232,7 +233,39 @@ DEFINE_GUEST_HANDLE_STRUCT(mmuext_op);
 #define VMASST_TYPE_pae_extended_cr3     3
 #define MAX_VMASST_TYPE 3
 
+/*
+ * Commands to HYPERVISOR_kexec_op().
+ */
+#define KEXEC_CMD_kexec			0
+#define KEXEC_CMD_kexec_load		1
+#define KEXEC_CMD_kexec_unload		2
+#define KEXEC_CMD_kexec_get_range	3
+
+/*
+ * Memory ranges for kdump (utilized by HYPERVISOR_kexec_op()).
+ */
+#define KEXEC_RANGE_MA_CRASH		0
+#define KEXEC_RANGE_MA_XEN		1
+#define KEXEC_RANGE_MA_CPU		2
+#define KEXEC_RANGE_MA_XENHEAP		3
+#define KEXEC_RANGE_MA_BOOT_PARAM	4
+#define KEXEC_RANGE_MA_EFI_MEMMAP	5
+#define KEXEC_RANGE_MA_VMCOREINFO	6
+
 #ifndef __ASSEMBLY__
+struct xen_kexec_exec {
+	int type;
+};
+
+struct xen_kexec_range {
+	int range;
+	int nr;
+	unsigned long size;
+	unsigned long start;
+};
+
+extern unsigned long xen_vmcoreinfo_maddr;
+extern unsigned long xen_vmcoreinfo_max_size;
 
 typedef uint16_t domid_t;
 
-- 
1.5.6.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 27 18:07:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Sep 2012 18:07: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 1THIUJ-0000sW-UL; Thu, 27 Sep 2012 18:07:03 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <SRS0=Sf9V=H2=oracle.com=daniel.kiper@net-space.pl>)
	id 1THIUH-0000r6-7y
	for xen-devel@lists.xensource.com; Thu, 27 Sep 2012 18:07:01 +0000
Received: from [85.158.138.51:42601] by server-12.bemta-3.messagelabs.com id
	15/AE-23730-4C594605; Thu, 27 Sep 2012 18:07:00 +0000
X-Env-Sender: SRS0=Sf9V=H2=oracle.com=daniel.kiper@net-space.pl
X-Msg-Ref: server-14.tower-174.messagelabs.com!1348769218!25906058!6
X-Originating-IP: [89.174.63.77]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31595 invoked from network); 27 Sep 2012 18:06:59 -0000
Received: from router-fw.net-space.pl (HELO router-fw.net-space.pl)
	(89.174.63.77)
	by server-14.tower-174.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 27 Sep 2012 18:06:59 -0000
Received: from dev-00.local.net-space.pl ([192.168.1.5]:54110 "EHLO
	localhost.localdomain" TLS-CIPHER: <none>)
	by router-fw-old.local.net-space.pl with ESMTP id S1623304Ab2I0SGj
	(ORCPT <rfc822;xen-devel@lists.xensource.com>);
	Thu, 27 Sep 2012 20:06:39 +0200
From: Daniel Kiper <daniel.kiper@oracle.com>
To: konrad.wilk@oracle.com, andrew.cooper3@citrix.com,
	jbeulich@suse.com, linux-kernel@vger.kernel.org,
	xen-devel@lists.xensource.com
Date: Thu, 27 Sep 2012 20:06:36 +0200
Message-Id: <1348769198-29580-10-git-send-email-daniel.kiper@oracle.com>
X-Mailer: git-send-email 1.5.6.5
In-Reply-To: <1348769198-29580-9-git-send-email-daniel.kiper@oracle.com>
References: <1348769198-29580-1-git-send-email-daniel.kiper@oracle.com>
	<1348769198-29580-2-git-send-email-daniel.kiper@oracle.com>
	<1348769198-29580-3-git-send-email-daniel.kiper@oracle.com>
	<1348769198-29580-4-git-send-email-daniel.kiper@oracle.com>
	<1348769198-29580-5-git-send-email-daniel.kiper@oracle.com>
	<1348769198-29580-6-git-send-email-daniel.kiper@oracle.com>
	<1348769198-29580-7-git-send-email-daniel.kiper@oracle.com>
	<1348769198-29580-8-git-send-email-daniel.kiper@oracle.com>
	<1348769198-29580-9-git-send-email-daniel.kiper@oracle.com>
X-Bogosity: No, spamicity=0.000281
Cc: Daniel Kiper <daniel.kiper@oracle.com>
Subject: [Xen-devel] [PATCH 09/11] x86/xen/enlighten: Add init and crash
	kexec/kdump hooks
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 init and crash kexec/kdump hooks.

Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
---
 arch/x86/xen/enlighten.c |   12 ++++++++++++
 1 files changed, 12 insertions(+), 0 deletions(-)

diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
index 1fbe75a..5043d77 100644
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -31,6 +31,7 @@
 #include <linux/pci.h>
 #include <linux/gfp.h>
 #include <linux/memblock.h>
+#include <linux/kexec.h>
 
 #include <xen/xen.h>
 #include <xen/interface/xen.h>
@@ -66,6 +67,7 @@
 #include <asm/hypervisor.h>
 #include <asm/mwait.h>
 #include <asm/pci_x86.h>
+#include <asm/xen/kexec.h>
 
 #ifdef CONFIG_ACPI
 #include <linux/acpi.h>
@@ -1237,6 +1239,12 @@ static void xen_machine_power_off(void)
 
 static void xen_crash_shutdown(struct pt_regs *regs)
 {
+#ifdef CONFIG_KEXEC
+	if (kexec_crash_image) {
+		crash_save_cpu(regs, safe_smp_processor_id());
+		return;
+	}
+#endif
 	xen_reboot(SHUTDOWN_crash);
 }
 
@@ -1315,6 +1323,10 @@ asmlinkage void __init xen_start_kernel(void)
 
 	xen_init_mmu_ops();
 
+#ifdef CONFIG_KEXEC
+	xen_init_kexec_ops();
+#endif
+
 	/* Prevent unwanted bits from being set in PTEs. */
 	__supported_pte_mask &= ~_PAGE_GLOBAL;
 #if 0
-- 
1.5.6.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 27 18:07:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Sep 2012 18:07: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 1THIUJ-0000s8-5D; Thu, 27 Sep 2012 18:07:03 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <SRS0=Sf9V=H2=oracle.com=daniel.kiper@net-space.pl>)
	id 1THIUG-0000r0-Fv
	for xen-devel@lists.xensource.com; Thu, 27 Sep 2012 18:07:00 +0000
Received: from [85.158.138.51:42574] by server-8.bemta-3.messagelabs.com id
	AD/23-16337-3C594605; Thu, 27 Sep 2012 18:06:59 +0000
X-Env-Sender: SRS0=Sf9V=H2=oracle.com=daniel.kiper@net-space.pl
X-Msg-Ref: server-14.tower-174.messagelabs.com!1348769218!25906058!2
X-Originating-IP: [89.174.63.77]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31563 invoked from network); 27 Sep 2012 18:06:58 -0000
Received: from router-fw.net-space.pl (HELO router-fw.net-space.pl)
	(89.174.63.77)
	by server-14.tower-174.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 27 Sep 2012 18:06:58 -0000
Received: from dev-00.local.net-space.pl ([192.168.1.5]:54110 "EHLO
	localhost.localdomain" TLS-CIPHER: <none>)
	by router-fw-old.local.net-space.pl with ESMTP id S1623296Ab2I0SGj
	(ORCPT <rfc822;xen-devel@lists.xensource.com>);
	Thu, 27 Sep 2012 20:06:39 +0200
From: Daniel Kiper <daniel.kiper@oracle.com>
To: konrad.wilk@oracle.com, andrew.cooper3@citrix.com,
	jbeulich@suse.com, linux-kernel@vger.kernel.org,
	xen-devel@lists.xensource.com
Date: Thu, 27 Sep 2012 20:06:30 +0200
Message-Id: <1348769198-29580-4-git-send-email-daniel.kiper@oracle.com>
X-Mailer: git-send-email 1.5.6.5
In-Reply-To: <1348769198-29580-3-git-send-email-daniel.kiper@oracle.com>
References: <1348769198-29580-1-git-send-email-daniel.kiper@oracle.com>
	<1348769198-29580-2-git-send-email-daniel.kiper@oracle.com>
	<1348769198-29580-3-git-send-email-daniel.kiper@oracle.com>
X-Bogosity: No, spamicity=0.016045
Cc: Daniel Kiper <daniel.kiper@oracle.com>
Subject: [Xen-devel] [PATCH 03/11] xen: Introduce architecture independent
	data for kexec/kdump
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 architecture independent constants and structures
required by Xen kexec/kdump implementation.

Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
---
 include/xen/interface/xen.h |   33 +++++++++++++++++++++++++++++++++
 1 files changed, 33 insertions(+), 0 deletions(-)

diff --git a/include/xen/interface/xen.h b/include/xen/interface/xen.h
index 0801468..ac19f9e 100644
--- a/include/xen/interface/xen.h
+++ b/include/xen/interface/xen.h
@@ -58,6 +58,7 @@
 #define __HYPERVISOR_event_channel_op     32
 #define __HYPERVISOR_physdev_op           33
 #define __HYPERVISOR_hvm_op               34
+#define __HYPERVISOR_kexec_op             37
 #define __HYPERVISOR_tmem_op              38
 
 /* Architecture-specific hypercall definitions. */
@@ -232,7 +233,39 @@ DEFINE_GUEST_HANDLE_STRUCT(mmuext_op);
 #define VMASST_TYPE_pae_extended_cr3     3
 #define MAX_VMASST_TYPE 3
 
+/*
+ * Commands to HYPERVISOR_kexec_op().
+ */
+#define KEXEC_CMD_kexec			0
+#define KEXEC_CMD_kexec_load		1
+#define KEXEC_CMD_kexec_unload		2
+#define KEXEC_CMD_kexec_get_range	3
+
+/*
+ * Memory ranges for kdump (utilized by HYPERVISOR_kexec_op()).
+ */
+#define KEXEC_RANGE_MA_CRASH		0
+#define KEXEC_RANGE_MA_XEN		1
+#define KEXEC_RANGE_MA_CPU		2
+#define KEXEC_RANGE_MA_XENHEAP		3
+#define KEXEC_RANGE_MA_BOOT_PARAM	4
+#define KEXEC_RANGE_MA_EFI_MEMMAP	5
+#define KEXEC_RANGE_MA_VMCOREINFO	6
+
 #ifndef __ASSEMBLY__
+struct xen_kexec_exec {
+	int type;
+};
+
+struct xen_kexec_range {
+	int range;
+	int nr;
+	unsigned long size;
+	unsigned long start;
+};
+
+extern unsigned long xen_vmcoreinfo_maddr;
+extern unsigned long xen_vmcoreinfo_max_size;
 
 typedef uint16_t domid_t;
 
-- 
1.5.6.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 27 18:07:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Sep 2012 18:07: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 1THIUL-0000tC-4u; Thu, 27 Sep 2012 18:07:05 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <SRS0=Sf9V=H2=oracle.com=daniel.kiper@net-space.pl>)
	id 1THIUI-0000r0-24
	for xen-devel@lists.xensource.com; Thu, 27 Sep 2012 18:07:02 +0000
Received: from [85.158.138.51:42641] by server-8.bemta-3.messagelabs.com id
	F2/33-16337-5C594605; Thu, 27 Sep 2012 18:07:01 +0000
X-Env-Sender: SRS0=Sf9V=H2=oracle.com=daniel.kiper@net-space.pl
X-Msg-Ref: server-14.tower-174.messagelabs.com!1348769218!25906058!12
X-Originating-IP: [89.174.63.77]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31666 invoked from network); 27 Sep 2012 18:07:01 -0000
Received: from router-fw.net-space.pl (HELO router-fw.net-space.pl)
	(89.174.63.77)
	by server-14.tower-174.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 27 Sep 2012 18:07:01 -0000
Received: from dev-00.local.net-space.pl ([192.168.1.5]:54110 "EHLO
	localhost.localdomain" TLS-CIPHER: <none>)
	by router-fw-old.local.net-space.pl with ESMTP id S1623306Ab2I0SGk
	(ORCPT <rfc822;xen-devel@lists.xensource.com>);
	Thu, 27 Sep 2012 20:06:40 +0200
From: Daniel Kiper <daniel.kiper@oracle.com>
To: konrad.wilk@oracle.com, andrew.cooper3@citrix.com,
	jbeulich@suse.com, linux-kernel@vger.kernel.org,
	xen-devel@lists.xensource.com
Date: Thu, 27 Sep 2012 20:06:38 +0200
Message-Id: <1348769198-29580-12-git-send-email-daniel.kiper@oracle.com>
X-Mailer: git-send-email 1.5.6.5
In-Reply-To: <1348769198-29580-11-git-send-email-daniel.kiper@oracle.com>
References: <1348769198-29580-1-git-send-email-daniel.kiper@oracle.com>
	<1348769198-29580-2-git-send-email-daniel.kiper@oracle.com>
	<1348769198-29580-3-git-send-email-daniel.kiper@oracle.com>
	<1348769198-29580-4-git-send-email-daniel.kiper@oracle.com>
	<1348769198-29580-5-git-send-email-daniel.kiper@oracle.com>
	<1348769198-29580-6-git-send-email-daniel.kiper@oracle.com>
	<1348769198-29580-7-git-send-email-daniel.kiper@oracle.com>
	<1348769198-29580-8-git-send-email-daniel.kiper@oracle.com>
	<1348769198-29580-9-git-send-email-daniel.kiper@oracle.com>
	<1348769198-29580-10-git-send-email-daniel.kiper@oracle.com>
	<1348769198-29580-11-git-send-email-daniel.kiper@oracle.com>
X-Bogosity: No, spamicity=0.015652
Cc: Daniel Kiper <daniel.kiper@oracle.com>
Subject: [Xen-devel] [PATCH 11/11] x86: Add Xen kexec control code size
	check to linker 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>
MIME-Version: 1.0
Content-Type: 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 kexec control code size check to linker script.

Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
---
 arch/x86/kernel/vmlinux.lds.S |    7 ++++++-
 1 files changed, 6 insertions(+), 1 deletions(-)

diff --git a/arch/x86/kernel/vmlinux.lds.S b/arch/x86/kernel/vmlinux.lds.S
index 22a1530..f18786a 100644
--- a/arch/x86/kernel/vmlinux.lds.S
+++ b/arch/x86/kernel/vmlinux.lds.S
@@ -360,5 +360,10 @@ INIT_PER_CPU(irq_stack_union);
 
 . = ASSERT(kexec_control_code_size <= KEXEC_CONTROL_CODE_MAX_SIZE,
            "kexec control code size is too big");
-#endif
 
+#ifdef CONFIG_XEN
+. = ASSERT(xen_kexec_control_code_size - xen_relocate_kernel <=
+		KEXEC_CONTROL_CODE_MAX_SIZE,
+		"Xen kexec control code size is too big");
+#endif
+#endif
-- 
1.5.6.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 27 18:07:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Sep 2012 18:07: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 1THIUJ-0000sW-UL; Thu, 27 Sep 2012 18:07:03 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <SRS0=Sf9V=H2=oracle.com=daniel.kiper@net-space.pl>)
	id 1THIUH-0000r6-7y
	for xen-devel@lists.xensource.com; Thu, 27 Sep 2012 18:07:01 +0000
Received: from [85.158.138.51:42601] by server-12.bemta-3.messagelabs.com id
	15/AE-23730-4C594605; Thu, 27 Sep 2012 18:07:00 +0000
X-Env-Sender: SRS0=Sf9V=H2=oracle.com=daniel.kiper@net-space.pl
X-Msg-Ref: server-14.tower-174.messagelabs.com!1348769218!25906058!6
X-Originating-IP: [89.174.63.77]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31595 invoked from network); 27 Sep 2012 18:06:59 -0000
Received: from router-fw.net-space.pl (HELO router-fw.net-space.pl)
	(89.174.63.77)
	by server-14.tower-174.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 27 Sep 2012 18:06:59 -0000
Received: from dev-00.local.net-space.pl ([192.168.1.5]:54110 "EHLO
	localhost.localdomain" TLS-CIPHER: <none>)
	by router-fw-old.local.net-space.pl with ESMTP id S1623304Ab2I0SGj
	(ORCPT <rfc822;xen-devel@lists.xensource.com>);
	Thu, 27 Sep 2012 20:06:39 +0200
From: Daniel Kiper <daniel.kiper@oracle.com>
To: konrad.wilk@oracle.com, andrew.cooper3@citrix.com,
	jbeulich@suse.com, linux-kernel@vger.kernel.org,
	xen-devel@lists.xensource.com
Date: Thu, 27 Sep 2012 20:06:36 +0200
Message-Id: <1348769198-29580-10-git-send-email-daniel.kiper@oracle.com>
X-Mailer: git-send-email 1.5.6.5
In-Reply-To: <1348769198-29580-9-git-send-email-daniel.kiper@oracle.com>
References: <1348769198-29580-1-git-send-email-daniel.kiper@oracle.com>
	<1348769198-29580-2-git-send-email-daniel.kiper@oracle.com>
	<1348769198-29580-3-git-send-email-daniel.kiper@oracle.com>
	<1348769198-29580-4-git-send-email-daniel.kiper@oracle.com>
	<1348769198-29580-5-git-send-email-daniel.kiper@oracle.com>
	<1348769198-29580-6-git-send-email-daniel.kiper@oracle.com>
	<1348769198-29580-7-git-send-email-daniel.kiper@oracle.com>
	<1348769198-29580-8-git-send-email-daniel.kiper@oracle.com>
	<1348769198-29580-9-git-send-email-daniel.kiper@oracle.com>
X-Bogosity: No, spamicity=0.000281
Cc: Daniel Kiper <daniel.kiper@oracle.com>
Subject: [Xen-devel] [PATCH 09/11] x86/xen/enlighten: Add init and crash
	kexec/kdump hooks
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 init and crash kexec/kdump hooks.

Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
---
 arch/x86/xen/enlighten.c |   12 ++++++++++++
 1 files changed, 12 insertions(+), 0 deletions(-)

diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
index 1fbe75a..5043d77 100644
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -31,6 +31,7 @@
 #include <linux/pci.h>
 #include <linux/gfp.h>
 #include <linux/memblock.h>
+#include <linux/kexec.h>
 
 #include <xen/xen.h>
 #include <xen/interface/xen.h>
@@ -66,6 +67,7 @@
 #include <asm/hypervisor.h>
 #include <asm/mwait.h>
 #include <asm/pci_x86.h>
+#include <asm/xen/kexec.h>
 
 #ifdef CONFIG_ACPI
 #include <linux/acpi.h>
@@ -1237,6 +1239,12 @@ static void xen_machine_power_off(void)
 
 static void xen_crash_shutdown(struct pt_regs *regs)
 {
+#ifdef CONFIG_KEXEC
+	if (kexec_crash_image) {
+		crash_save_cpu(regs, safe_smp_processor_id());
+		return;
+	}
+#endif
 	xen_reboot(SHUTDOWN_crash);
 }
 
@@ -1315,6 +1323,10 @@ asmlinkage void __init xen_start_kernel(void)
 
 	xen_init_mmu_ops();
 
+#ifdef CONFIG_KEXEC
+	xen_init_kexec_ops();
+#endif
+
 	/* Prevent unwanted bits from being set in PTEs. */
 	__supported_pte_mask &= ~_PAGE_GLOBAL;
 #if 0
-- 
1.5.6.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 27 18:07:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Sep 2012 18:07: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 1THIUL-0000td-U8; Thu, 27 Sep 2012 18:07:05 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <SRS0=Sf9V=H2=oracle.com=daniel.kiper@net-space.pl>)
	id 1THIUH-0000rB-VA
	for xen-devel@lists.xensource.com; Thu, 27 Sep 2012 18:07:02 +0000
Received: from [85.158.138.51:42622] by server-15.bemta-3.messagelabs.com id
	E5/DD-18313-5C594605; Thu, 27 Sep 2012 18:07:01 +0000
X-Env-Sender: SRS0=Sf9V=H2=oracle.com=daniel.kiper@net-space.pl
X-Msg-Ref: server-14.tower-174.messagelabs.com!1348769218!25906058!5
X-Originating-IP: [89.174.63.77]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31584 invoked from network); 27 Sep 2012 18:06:59 -0000
Received: from router-fw.net-space.pl (HELO router-fw.net-space.pl)
	(89.174.63.77)
	by server-14.tower-174.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 27 Sep 2012 18:06:59 -0000
Received: from dev-00.local.net-space.pl ([192.168.1.5]:54110 "EHLO
	localhost.localdomain" TLS-CIPHER: <none>)
	by router-fw-old.local.net-space.pl with ESMTP id S1623300Ab2I0SGj
	(ORCPT <rfc822;xen-devel@lists.xensource.com>);
	Thu, 27 Sep 2012 20:06:39 +0200
From: Daniel Kiper <daniel.kiper@oracle.com>
To: konrad.wilk@oracle.com, andrew.cooper3@citrix.com,
	jbeulich@suse.com, linux-kernel@vger.kernel.org,
	xen-devel@lists.xensource.com
Date: Thu, 27 Sep 2012 20:06:34 +0200
Message-Id: <1348769198-29580-8-git-send-email-daniel.kiper@oracle.com>
X-Mailer: git-send-email 1.5.6.5
In-Reply-To: <1348769198-29580-7-git-send-email-daniel.kiper@oracle.com>
References: <1348769198-29580-1-git-send-email-daniel.kiper@oracle.com>
	<1348769198-29580-2-git-send-email-daniel.kiper@oracle.com>
	<1348769198-29580-3-git-send-email-daniel.kiper@oracle.com>
	<1348769198-29580-4-git-send-email-daniel.kiper@oracle.com>
	<1348769198-29580-5-git-send-email-daniel.kiper@oracle.com>
	<1348769198-29580-6-git-send-email-daniel.kiper@oracle.com>
	<1348769198-29580-7-git-send-email-daniel.kiper@oracle.com>
X-Bogosity: No, spamicity=0.001479
Cc: Daniel Kiper <daniel.kiper@oracle.com>
Subject: [Xen-devel] [PATCH 07/11] x86/xen: Add x86_64 kexec/kdump
	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>
MIME-Version: 1.0
Content-Type: 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 x86_64 kexec/kdump implementation.

Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
---
 arch/x86/xen/machine_kexec_64.c   |  301 ++++++++++++++++++++++++++++++++++++
 arch/x86/xen/relocate_kernel_64.S |  309 +++++++++++++++++++++++++++++++++++++
 2 files changed, 610 insertions(+), 0 deletions(-)
 create mode 100644 arch/x86/xen/machine_kexec_64.c
 create mode 100644 arch/x86/xen/relocate_kernel_64.S

diff --git a/arch/x86/xen/machine_kexec_64.c b/arch/x86/xen/machine_kexec_64.c
new file mode 100644
index 0000000..f87ffe0
--- /dev/null
+++ b/arch/x86/xen/machine_kexec_64.c
@@ -0,0 +1,301 @@
+/*
+ * Copyright (c) 2011 Daniel Kiper
+ * Copyright (c) 2012 Daniel Kiper, Oracle Corporation
+ *
+ * kexec/kdump implementation for Xen was written by Daniel Kiper.
+ * Initial work on it was sponsored by Google under Google Summer
+ * of Code 2011 program and Citrix. Konrad Rzeszutek Wilk from Oracle
+ * was the mentor for this project.
+ *
+ * Some ideas are taken from:
+ *   - native kexec/kdump implementation,
+ *   - kexec/kdump implementation for Xen Linux Kernel Ver. 2.6.18,
+ *   - PV-GRUB.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License along
+ * with this program.  If not, see <http://www.gnu.org/licenses/>.
+ */
+
+#include <linux/errno.h>
+#include <linux/init.h>
+#include <linux/kernel.h>
+#include <linux/kexec.h>
+#include <linux/mm.h>
+#include <linux/string.h>
+
+#include <xen/interface/memory.h>
+#include <xen/xen.h>
+
+#include <asm/xen/hypercall.h>
+#include <asm/xen/kexec.h>
+#include <asm/xen/page.h>
+
+#define __ma(vaddr)	(virt_to_machine(vaddr).maddr)
+
+static unsigned long xen_page_to_mfn(struct page *page)
+{
+	return pfn_to_mfn(page_to_pfn(page));
+}
+
+static struct page *xen_mfn_to_page(unsigned long mfn)
+{
+	return pfn_to_page(mfn_to_pfn(mfn));
+}
+
+static unsigned long xen_virt_to_machine(volatile void *address)
+{
+	return virt_to_machine(address).maddr;
+}
+
+static void *xen_machine_to_virt(unsigned long address)
+{
+	return phys_to_virt(machine_to_phys(XMADDR(address)).paddr);
+}
+
+static void init_level2_page(pmd_t *pmd, unsigned long addr)
+{
+	unsigned long end_addr = addr + PUD_SIZE;
+
+	while (addr < end_addr) {
+		native_set_pmd(pmd++, native_make_pmd(addr | __PAGE_KERNEL_LARGE_EXEC));
+		addr += PMD_SIZE;
+	}
+}
+
+static int init_level3_page(struct kimage *image, pud_t *pud,
+				unsigned long addr, unsigned long last_addr)
+{
+	pmd_t *pmd;
+	struct page *page;
+	unsigned long end_addr = addr + PGDIR_SIZE;
+
+	while ((addr < last_addr) && (addr < end_addr)) {
+		page = kimage_alloc_control_pages(image, 0);
+
+		if (!page)
+			return -ENOMEM;
+
+		pmd = page_address(page);
+		init_level2_page(pmd, addr);
+		native_set_pud(pud++, native_make_pud(__ma(pmd) | _KERNPG_TABLE));
+		addr += PUD_SIZE;
+	}
+
+	/* Clear the unused entries. */
+	while (addr < end_addr) {
+		native_pud_clear(pud++);
+		addr += PUD_SIZE;
+	}
+
+	return 0;
+}
+
+
+static int init_level4_page(struct kimage *image, pgd_t *pgd,
+				unsigned long addr, unsigned long last_addr)
+{
+	int rc;
+	pud_t *pud;
+	struct page *page;
+	unsigned long end_addr = addr + PTRS_PER_PGD * PGDIR_SIZE;
+
+	while ((addr < last_addr) && (addr < end_addr)) {
+		page = kimage_alloc_control_pages(image, 0);
+
+		if (!page)
+			return -ENOMEM;
+
+		pud = page_address(page);
+		rc = init_level3_page(image, pud, addr, last_addr);
+
+		if (rc)
+			return rc;
+
+		native_set_pgd(pgd++, native_make_pgd(__ma(pud) | _KERNPG_TABLE));
+		addr += PGDIR_SIZE;
+	}
+
+	/* Clear the unused entries. */
+	while (addr < end_addr) {
+		native_pgd_clear(pgd++);
+		addr += PGDIR_SIZE;
+	}
+
+	return 0;
+}
+
+static void free_transition_pgtable(struct kimage *image)
+{
+	free_page((unsigned long)image->arch.pgd);
+	free_page((unsigned long)image->arch.pud0);
+	free_page((unsigned long)image->arch.pud1);
+	free_page((unsigned long)image->arch.pmd0);
+	free_page((unsigned long)image->arch.pmd1);
+	free_page((unsigned long)image->arch.pte0);
+	free_page((unsigned long)image->arch.pte1);
+}
+
+static int alloc_transition_pgtable(struct kimage *image)
+{
+	image->arch.pgd = (pgd_t *)get_zeroed_page(GFP_KERNEL);
+
+	if (!image->arch.pgd)
+		goto err;
+
+	image->arch.pud0 = (pud_t *)get_zeroed_page(GFP_KERNEL);
+
+	if (!image->arch.pud0)
+		goto err;
+
+	image->arch.pud1 = (pud_t *)get_zeroed_page(GFP_KERNEL);
+
+	if (!image->arch.pud1)
+		goto err;
+
+	image->arch.pmd0 = (pmd_t *)get_zeroed_page(GFP_KERNEL);
+
+	if (!image->arch.pmd0)
+		goto err;
+
+	image->arch.pmd1 = (pmd_t *)get_zeroed_page(GFP_KERNEL);
+
+	if (!image->arch.pmd1)
+		goto err;
+
+	image->arch.pte0 = (pte_t *)get_zeroed_page(GFP_KERNEL);
+
+	if (!image->arch.pte0)
+		goto err;
+
+	image->arch.pte1 = (pte_t *)get_zeroed_page(GFP_KERNEL);
+
+	if (!image->arch.pte1)
+		goto err;
+
+	return 0;
+
+err:
+	free_transition_pgtable(image);
+
+	return -ENOMEM;
+}
+
+static int init_pgtable(struct kimage *image, pgd_t *pgd)
+{
+	int rc;
+	unsigned long max_mfn;
+
+	max_mfn = HYPERVISOR_memory_op(XENMEM_maximum_ram_page, NULL);
+
+	rc = init_level4_page(image, pgd, 0, PFN_PHYS(max_mfn));
+
+	if (rc)
+		return rc;
+
+	return alloc_transition_pgtable(image);
+}
+
+static int machine_xen_kexec_prepare(struct kimage *image)
+{
+#ifdef CONFIG_KEXEC_JUMP
+	if (image->preserve_context) {
+		pr_info_once("kexec: Context preservation is not "
+				"supported in Xen domains.\n");
+		return -ENOSYS;
+	}
+#endif
+
+	return init_pgtable(image, page_address(image->control_code_page));
+}
+
+static int machine_xen_kexec_load(struct kimage *image)
+{
+	void *control_page, *table_page;
+	struct xen_kexec_load xkl = {};
+
+	if (!image)
+		return 0;
+
+	table_page = page_address(image->control_code_page);
+	control_page = table_page + PAGE_SIZE;
+
+	memcpy(control_page, xen_relocate_kernel, xen_kexec_control_code_size);
+
+	xkl.type = image->type;
+	xkl.image.page_list[XK_MA_CONTROL_PAGE] = __ma(control_page);
+	xkl.image.page_list[XK_MA_TABLE_PAGE] = __ma(table_page);
+	xkl.image.page_list[XK_MA_PGD_PAGE] = __ma(image->arch.pgd);
+	xkl.image.page_list[XK_MA_PUD0_PAGE] = __ma(image->arch.pud0);
+	xkl.image.page_list[XK_MA_PUD1_PAGE] = __ma(image->arch.pud1);
+	xkl.image.page_list[XK_MA_PMD0_PAGE] = __ma(image->arch.pmd0);
+	xkl.image.page_list[XK_MA_PMD1_PAGE] = __ma(image->arch.pmd1);
+	xkl.image.page_list[XK_MA_PTE0_PAGE] = __ma(image->arch.pte0);
+	xkl.image.page_list[XK_MA_PTE1_PAGE] = __ma(image->arch.pte1);
+	xkl.image.indirection_page = image->head;
+	xkl.image.start_address = image->start;
+
+	return HYPERVISOR_kexec_op(KEXEC_CMD_kexec_load, &xkl);
+}
+
+static void machine_xen_kexec_cleanup(struct kimage *image)
+{
+	free_transition_pgtable(image);
+}
+
+static void machine_xen_kexec_unload(struct kimage *image)
+{
+	int rc;
+	struct xen_kexec_load xkl = {};
+
+	if (!image)
+		return;
+
+	xkl.type = image->type;
+	rc = HYPERVISOR_kexec_op(KEXEC_CMD_kexec_unload, &xkl);
+
+	WARN(rc, "kexec: %s: HYPERVISOR_kexec_op(): %i\n", __func__, rc);
+}
+
+static void machine_xen_kexec_shutdown(void)
+{
+}
+
+static void machine_xen_kexec(struct kimage *image)
+{
+	int rc;
+	struct xen_kexec_exec xke = {};
+
+	xke.type = image->type;
+	rc = HYPERVISOR_kexec_op(KEXEC_CMD_kexec, &xke);
+
+	pr_emerg("kexec: %s: HYPERVISOR_kexec_op(): %i\n", __func__, rc);
+	BUG();
+}
+
+void __init xen_init_kexec_ops(void)
+{
+	if (!xen_initial_domain())
+		return;
+
+	kexec_ops.always_use_normal_alloc = true;
+	kexec_ops.page_to_pfn = xen_page_to_mfn;
+	kexec_ops.pfn_to_page = xen_mfn_to_page;
+	kexec_ops.virt_to_phys = xen_virt_to_machine;
+	kexec_ops.phys_to_virt = xen_machine_to_virt;
+	kexec_ops.machine_kexec_prepare = machine_xen_kexec_prepare;
+	kexec_ops.machine_kexec_load = machine_xen_kexec_load;
+	kexec_ops.machine_kexec_cleanup = machine_xen_kexec_cleanup;
+	kexec_ops.machine_kexec_unload = machine_xen_kexec_unload;
+	kexec_ops.machine_kexec_shutdown = machine_xen_kexec_shutdown;
+	kexec_ops.machine_kexec = machine_xen_kexec;
+}
diff --git a/arch/x86/xen/relocate_kernel_64.S b/arch/x86/xen/relocate_kernel_64.S
new file mode 100644
index 0000000..8f641f1
--- /dev/null
+++ b/arch/x86/xen/relocate_kernel_64.S
@@ -0,0 +1,309 @@
+/*
+ * Copyright (c) 2002-2005 Eric Biederman <ebiederm@xmission.com>
+ * Copyright (c) 2011 Daniel Kiper
+ * Copyright (c) 2012 Daniel Kiper, Oracle Corporation
+ *
+ * kexec/kdump implementation for Xen was written by Daniel Kiper.
+ * Initial work on it was sponsored by Google under Google Summer
+ * of Code 2011 program and Citrix. Konrad Rzeszutek Wilk from Oracle
+ * was the mentor for this project.
+ *
+ * Some ideas are taken from:
+ *   - native kexec/kdump implementation,
+ *   - kexec/kdump implementation for Xen Linux Kernel Ver. 2.6.18,
+ *   - PV-GRUB.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License along
+ * with this program.  If not, see <http://www.gnu.org/licenses/>.
+ */
+
+#include <asm/page_types.h>
+#include <asm/pgtable_types.h>
+#include <asm/processor-flags.h>
+
+#include <asm/xen/kexec.h>
+
+#define PTR(x)	(x << 3)
+
+	.text
+	.code64
+	.globl	xen_kexec_control_code_size, xen_relocate_kernel
+
+xen_relocate_kernel:
+	/*
+	 * Must be relocatable PIC code callable as a C function.
+	 *
+	 * This function is called by Xen but here hypervisor is dead.
+	 * We are playing on bare metal.
+	 *
+	 * Every machine address passed to this function through
+	 * page_list (e.g. XK_MA_CONTROL_PAGE) is established
+	 * by dom0 during kexec load phase.
+	 *
+	 * Every virtual address passed to this function through page_list
+	 * (e.g. XK_VA_CONTROL_PAGE) is established by hypervisor during
+	 * HYPERVISOR_kexec_op(KEXEC_CMD_kexec_load) hypercall.
+	 *
+	 * %rdi - indirection_page,
+	 * %rsi - page_list,
+	 * %rdx - start_address,
+	 * %ecx - preserve_context (ignored).
+	 */
+
+	/* Zero out flags, and disable interrupts. */
+	pushq	$0
+	popfq
+
+	/*
+	 * Map the control page at its virtual address
+	 * in transition page table.
+	 */
+	movq	PTR(XK_VA_CONTROL_PAGE)(%rsi), %r8
+
+	/* Get PGD address and PGD entry index. */
+	movq	PTR(XK_VA_PGD_PAGE)(%rsi), %r9
+	movq	%r8, %r10
+	shrq	$PGDIR_SHIFT, %r10
+	andq	$(PTRS_PER_PGD - 1), %r10
+
+	/* Fill PGD entry with PUD0 reference. */
+	movq	PTR(XK_MA_PUD0_PAGE)(%rsi), %r11
+	orq	$_KERNPG_TABLE, %r11
+	movq	%r11, (%r9, %r10, 8)
+
+	/* Get PUD0 address and PUD0 entry index. */
+	movq	PTR(XK_VA_PUD0_PAGE)(%rsi), %r9
+	movq	%r8, %r10
+	shrq	$PUD_SHIFT, %r10
+	andq	$(PTRS_PER_PUD - 1), %r10
+
+	/* Fill PUD0 entry with PMD0 reference. */
+	movq	PTR(XK_MA_PMD0_PAGE)(%rsi), %r11
+	orq	$_KERNPG_TABLE, %r11
+	movq	%r11, (%r9, %r10, 8)
+
+	/* Get PMD0 address and PMD0 entry index. */
+	movq	PTR(XK_VA_PMD0_PAGE)(%rsi), %r9
+	movq	%r8, %r10
+	shrq	$PMD_SHIFT, %r10
+	andq	$(PTRS_PER_PMD - 1), %r10
+
+	/* Fill PMD0 entry with PTE0 reference. */
+	movq	PTR(XK_MA_PTE0_PAGE)(%rsi), %r11
+	orq	$_KERNPG_TABLE, %r11
+	movq	%r11, (%r9, %r10, 8)
+
+	/* Get PTE0 address and PTE0 entry index. */
+	movq	PTR(XK_VA_PTE0_PAGE)(%rsi), %r9
+	movq	%r8, %r10
+	shrq	$PAGE_SHIFT, %r10
+	andq	$(PTRS_PER_PTE - 1), %r10
+
+	/* Fill PTE0 entry with control page reference. */
+	movq	PTR(XK_MA_CONTROL_PAGE)(%rsi), %r11
+	orq	$__PAGE_KERNEL_EXEC, %r11
+	movq	%r11, (%r9, %r10, 8)
+
+	/*
+	 * Identity map the control page at its machine address
+	 * in transition page table.
+	 */
+	movq	PTR(XK_MA_CONTROL_PAGE)(%rsi), %r8
+
+	/* Get PGD address and PGD entry index. */
+	movq	PTR(XK_VA_PGD_PAGE)(%rsi), %r9
+	movq	%r8, %r10
+	shrq	$PGDIR_SHIFT, %r10
+	andq	$(PTRS_PER_PGD - 1), %r10
+
+	/* Fill PGD entry with PUD1 reference. */
+	movq	PTR(XK_MA_PUD1_PAGE)(%rsi), %r11
+	orq	$_KERNPG_TABLE, %r11
+	movq	%r11, (%r9, %r10, 8)
+
+	/* Get PUD1 address and PUD1 entry index. */
+	movq	PTR(XK_VA_PUD1_PAGE)(%rsi), %r9
+	movq	%r8, %r10
+	shrq	$PUD_SHIFT, %r10
+	andq	$(PTRS_PER_PUD - 1), %r10
+
+	/* Fill PUD1 entry with PMD1 reference. */
+	movq	PTR(XK_MA_PMD1_PAGE)(%rsi), %r11
+	orq	$_KERNPG_TABLE, %r11
+	movq	%r11, (%r9, %r10, 8)
+
+	/* Get PMD1 address and PMD1 entry index. */
+	movq	PTR(XK_VA_PMD1_PAGE)(%rsi), %r9
+	movq	%r8, %r10
+	shrq	$PMD_SHIFT, %r10
+	andq	$(PTRS_PER_PMD - 1), %r10
+
+	/* Fill PMD1 entry with PTE1 reference. */
+	movq	PTR(XK_MA_PTE1_PAGE)(%rsi), %r11
+	orq	$_KERNPG_TABLE, %r11
+	movq	%r11, (%r9, %r10, 8)
+
+	/* Get PTE1 address and PTE1 entry index. */
+	movq	PTR(XK_VA_PTE1_PAGE)(%rsi), %r9
+	movq	%r8, %r10
+	shrq	$PAGE_SHIFT, %r10
+	andq	$(PTRS_PER_PTE - 1), %r10
+
+	/* Fill PTE1 entry with control page reference. */
+	movq	PTR(XK_MA_CONTROL_PAGE)(%rsi), %r11
+	orq	$__PAGE_KERNEL_EXEC, %r11
+	movq	%r11, (%r9, %r10, 8)
+
+	/*
+	 * Get machine address of control page now.
+	 * This is impossible after page table switch.
+	 */
+	movq	PTR(XK_MA_CONTROL_PAGE)(%rsi), %r8
+
+	/* Get machine address of identity page table now too. */
+	movq	PTR(XK_MA_TABLE_PAGE)(%rsi), %r9
+
+	/* Get machine address of transition page table now too. */
+	movq	PTR(XK_MA_PGD_PAGE)(%rsi), %r10
+
+	/* Switch to transition page table. */
+	movq	%r10, %cr3
+
+	/* Setup a new stack at the end of machine address of control page. */
+	leaq	PAGE_SIZE(%r8), %rsp
+
+	/* Store start_address on the stack. */
+	pushq   %rdx
+
+	/* Jump to identity mapped page. */
+	addq	$(identity_mapped - xen_relocate_kernel), %r8
+	jmpq	*%r8
+
+identity_mapped:
+	/* Switch to identity page table. */
+	movq	%r9, %cr3
+
+	/*
+	 * Set %cr0 to a known state:
+	 *   - disable alignment check,
+	 *   - disable floating point emulation,
+	 *   - no task switch,
+	 *   - disable write protect,
+	 *   - enable protected mode,
+	 *   - enable paging.
+	 */
+	movq	%cr0, %rax
+	andq	$~(X86_CR0_AM | X86_CR0_EM | X86_CR0_TS | X86_CR0_WP), %rax
+	orl	$(X86_CR0_PE | X86_CR0_PG), %eax
+	movq	%rax, %cr0
+
+	/*
+	 * Set %cr4 to a known state:
+	 *   - enable physical address extension.
+	 */
+	movq	$X86_CR4_PAE, %rax
+	movq	%rax, %cr4
+
+	jmp	1f
+
+1:
+	/* Flush the TLB (needed?). */
+	movq	%r9, %cr3
+
+	/* Do the copies. */
+	movq	%rdi, %rcx	/* Put the indirection_page in %rcx. */
+	xorq	%rdi, %rdi
+	xorq	%rsi, %rsi
+	jmp	1f
+
+0:
+	/*
+	 * Top, read another quadword from the indirection page.
+	 * Indirection page is an array which contains source
+	 * and destination address pairs. If all pairs could
+	 * not fit in one page then at the end of given
+	 * indirection page is pointer to next one.
+	 * Copy is stopped when done indicator
+	 * is found in indirection page.
+	 */
+	movq	(%rbx), %rcx
+	addq	$8, %rbx
+
+1:
+	testq	$0x1, %rcx	/* Is it a destination page? */
+	jz	2f
+
+	movq	%rcx, %rdi
+	andq	$PAGE_MASK, %rdi
+	jmp	0b
+
+2:
+	testq	$0x2, %rcx	/* Is it an indirection page? */
+	jz	2f
+
+	movq	%rcx, %rbx
+	andq	$PAGE_MASK, %rbx
+	jmp	0b
+
+2:
+	testq	$0x4, %rcx	/* Is it the done indicator? */
+	jz	2f
+	jmp	3f
+
+2:
+	testq	$0x8, %rcx	/* Is it the source indicator? */
+	jz	0b		/* Ignore it otherwise. */
+
+	movq	%rcx, %rsi
+	andq	$PAGE_MASK, %rsi
+	movq	$512, %rcx
+
+	/* Copy page. */
+	rep	movsq
+	jmp	0b
+
+3:
+	/*
+	 * To be certain of avoiding problems with self-modifying code
+	 * I need to execute a serializing instruction here.
+	 * So I flush the TLB by reloading %cr3 here, it's handy,
+	 * and not processor dependent.
+	 */
+	movq	%cr3, %rax
+	movq	%rax, %cr3
+
+	/*
+	 * Set all of the registers to known values.
+	 * Leave %rsp alone.
+	 */
+	xorq	%rax, %rax
+	xorq	%rbx, %rbx
+	xorq    %rcx, %rcx
+	xorq    %rdx, %rdx
+	xorq    %rsi, %rsi
+	xorq    %rdi, %rdi
+	xorq    %rbp, %rbp
+	xorq	%r8, %r8
+	xorq	%r9, %r9
+	xorq	%r10, %r10
+	xorq	%r11, %r11
+	xorq	%r12, %r12
+	xorq	%r13, %r13
+	xorq	%r14, %r14
+	xorq	%r15, %r15
+
+	/* Jump to start_address. */
+	retq
+
+xen_kexec_control_code_size:
+	.long	. - xen_relocate_kernel
-- 
1.5.6.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 27 18:07:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Sep 2012 18:07: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 1THIUL-0000tC-4u; Thu, 27 Sep 2012 18:07:05 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <SRS0=Sf9V=H2=oracle.com=daniel.kiper@net-space.pl>)
	id 1THIUI-0000r0-24
	for xen-devel@lists.xensource.com; Thu, 27 Sep 2012 18:07:02 +0000
Received: from [85.158.138.51:42641] by server-8.bemta-3.messagelabs.com id
	F2/33-16337-5C594605; Thu, 27 Sep 2012 18:07:01 +0000
X-Env-Sender: SRS0=Sf9V=H2=oracle.com=daniel.kiper@net-space.pl
X-Msg-Ref: server-14.tower-174.messagelabs.com!1348769218!25906058!12
X-Originating-IP: [89.174.63.77]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31666 invoked from network); 27 Sep 2012 18:07:01 -0000
Received: from router-fw.net-space.pl (HELO router-fw.net-space.pl)
	(89.174.63.77)
	by server-14.tower-174.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 27 Sep 2012 18:07:01 -0000
Received: from dev-00.local.net-space.pl ([192.168.1.5]:54110 "EHLO
	localhost.localdomain" TLS-CIPHER: <none>)
	by router-fw-old.local.net-space.pl with ESMTP id S1623306Ab2I0SGk
	(ORCPT <rfc822;xen-devel@lists.xensource.com>);
	Thu, 27 Sep 2012 20:06:40 +0200
From: Daniel Kiper <daniel.kiper@oracle.com>
To: konrad.wilk@oracle.com, andrew.cooper3@citrix.com,
	jbeulich@suse.com, linux-kernel@vger.kernel.org,
	xen-devel@lists.xensource.com
Date: Thu, 27 Sep 2012 20:06:38 +0200
Message-Id: <1348769198-29580-12-git-send-email-daniel.kiper@oracle.com>
X-Mailer: git-send-email 1.5.6.5
In-Reply-To: <1348769198-29580-11-git-send-email-daniel.kiper@oracle.com>
References: <1348769198-29580-1-git-send-email-daniel.kiper@oracle.com>
	<1348769198-29580-2-git-send-email-daniel.kiper@oracle.com>
	<1348769198-29580-3-git-send-email-daniel.kiper@oracle.com>
	<1348769198-29580-4-git-send-email-daniel.kiper@oracle.com>
	<1348769198-29580-5-git-send-email-daniel.kiper@oracle.com>
	<1348769198-29580-6-git-send-email-daniel.kiper@oracle.com>
	<1348769198-29580-7-git-send-email-daniel.kiper@oracle.com>
	<1348769198-29580-8-git-send-email-daniel.kiper@oracle.com>
	<1348769198-29580-9-git-send-email-daniel.kiper@oracle.com>
	<1348769198-29580-10-git-send-email-daniel.kiper@oracle.com>
	<1348769198-29580-11-git-send-email-daniel.kiper@oracle.com>
X-Bogosity: No, spamicity=0.015652
Cc: Daniel Kiper <daniel.kiper@oracle.com>
Subject: [Xen-devel] [PATCH 11/11] x86: Add Xen kexec control code size
	check to linker 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>
MIME-Version: 1.0
Content-Type: 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 kexec control code size check to linker script.

Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
---
 arch/x86/kernel/vmlinux.lds.S |    7 ++++++-
 1 files changed, 6 insertions(+), 1 deletions(-)

diff --git a/arch/x86/kernel/vmlinux.lds.S b/arch/x86/kernel/vmlinux.lds.S
index 22a1530..f18786a 100644
--- a/arch/x86/kernel/vmlinux.lds.S
+++ b/arch/x86/kernel/vmlinux.lds.S
@@ -360,5 +360,10 @@ INIT_PER_CPU(irq_stack_union);
 
 . = ASSERT(kexec_control_code_size <= KEXEC_CONTROL_CODE_MAX_SIZE,
            "kexec control code size is too big");
-#endif
 
+#ifdef CONFIG_XEN
+. = ASSERT(xen_kexec_control_code_size - xen_relocate_kernel <=
+		KEXEC_CONTROL_CODE_MAX_SIZE,
+		"Xen kexec control code size is too big");
+#endif
+#endif
-- 
1.5.6.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 27 18:07:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Sep 2012 18:07: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 1THIUL-0000td-U8; Thu, 27 Sep 2012 18:07:05 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <SRS0=Sf9V=H2=oracle.com=daniel.kiper@net-space.pl>)
	id 1THIUH-0000rB-VA
	for xen-devel@lists.xensource.com; Thu, 27 Sep 2012 18:07:02 +0000
Received: from [85.158.138.51:42622] by server-15.bemta-3.messagelabs.com id
	E5/DD-18313-5C594605; Thu, 27 Sep 2012 18:07:01 +0000
X-Env-Sender: SRS0=Sf9V=H2=oracle.com=daniel.kiper@net-space.pl
X-Msg-Ref: server-14.tower-174.messagelabs.com!1348769218!25906058!5
X-Originating-IP: [89.174.63.77]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31584 invoked from network); 27 Sep 2012 18:06:59 -0000
Received: from router-fw.net-space.pl (HELO router-fw.net-space.pl)
	(89.174.63.77)
	by server-14.tower-174.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 27 Sep 2012 18:06:59 -0000
Received: from dev-00.local.net-space.pl ([192.168.1.5]:54110 "EHLO
	localhost.localdomain" TLS-CIPHER: <none>)
	by router-fw-old.local.net-space.pl with ESMTP id S1623300Ab2I0SGj
	(ORCPT <rfc822;xen-devel@lists.xensource.com>);
	Thu, 27 Sep 2012 20:06:39 +0200
From: Daniel Kiper <daniel.kiper@oracle.com>
To: konrad.wilk@oracle.com, andrew.cooper3@citrix.com,
	jbeulich@suse.com, linux-kernel@vger.kernel.org,
	xen-devel@lists.xensource.com
Date: Thu, 27 Sep 2012 20:06:34 +0200
Message-Id: <1348769198-29580-8-git-send-email-daniel.kiper@oracle.com>
X-Mailer: git-send-email 1.5.6.5
In-Reply-To: <1348769198-29580-7-git-send-email-daniel.kiper@oracle.com>
References: <1348769198-29580-1-git-send-email-daniel.kiper@oracle.com>
	<1348769198-29580-2-git-send-email-daniel.kiper@oracle.com>
	<1348769198-29580-3-git-send-email-daniel.kiper@oracle.com>
	<1348769198-29580-4-git-send-email-daniel.kiper@oracle.com>
	<1348769198-29580-5-git-send-email-daniel.kiper@oracle.com>
	<1348769198-29580-6-git-send-email-daniel.kiper@oracle.com>
	<1348769198-29580-7-git-send-email-daniel.kiper@oracle.com>
X-Bogosity: No, spamicity=0.001479
Cc: Daniel Kiper <daniel.kiper@oracle.com>
Subject: [Xen-devel] [PATCH 07/11] x86/xen: Add x86_64 kexec/kdump
	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>
MIME-Version: 1.0
Content-Type: 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 x86_64 kexec/kdump implementation.

Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
---
 arch/x86/xen/machine_kexec_64.c   |  301 ++++++++++++++++++++++++++++++++++++
 arch/x86/xen/relocate_kernel_64.S |  309 +++++++++++++++++++++++++++++++++++++
 2 files changed, 610 insertions(+), 0 deletions(-)
 create mode 100644 arch/x86/xen/machine_kexec_64.c
 create mode 100644 arch/x86/xen/relocate_kernel_64.S

diff --git a/arch/x86/xen/machine_kexec_64.c b/arch/x86/xen/machine_kexec_64.c
new file mode 100644
index 0000000..f87ffe0
--- /dev/null
+++ b/arch/x86/xen/machine_kexec_64.c
@@ -0,0 +1,301 @@
+/*
+ * Copyright (c) 2011 Daniel Kiper
+ * Copyright (c) 2012 Daniel Kiper, Oracle Corporation
+ *
+ * kexec/kdump implementation for Xen was written by Daniel Kiper.
+ * Initial work on it was sponsored by Google under Google Summer
+ * of Code 2011 program and Citrix. Konrad Rzeszutek Wilk from Oracle
+ * was the mentor for this project.
+ *
+ * Some ideas are taken from:
+ *   - native kexec/kdump implementation,
+ *   - kexec/kdump implementation for Xen Linux Kernel Ver. 2.6.18,
+ *   - PV-GRUB.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License along
+ * with this program.  If not, see <http://www.gnu.org/licenses/>.
+ */
+
+#include <linux/errno.h>
+#include <linux/init.h>
+#include <linux/kernel.h>
+#include <linux/kexec.h>
+#include <linux/mm.h>
+#include <linux/string.h>
+
+#include <xen/interface/memory.h>
+#include <xen/xen.h>
+
+#include <asm/xen/hypercall.h>
+#include <asm/xen/kexec.h>
+#include <asm/xen/page.h>
+
+#define __ma(vaddr)	(virt_to_machine(vaddr).maddr)
+
+static unsigned long xen_page_to_mfn(struct page *page)
+{
+	return pfn_to_mfn(page_to_pfn(page));
+}
+
+static struct page *xen_mfn_to_page(unsigned long mfn)
+{
+	return pfn_to_page(mfn_to_pfn(mfn));
+}
+
+static unsigned long xen_virt_to_machine(volatile void *address)
+{
+	return virt_to_machine(address).maddr;
+}
+
+static void *xen_machine_to_virt(unsigned long address)
+{
+	return phys_to_virt(machine_to_phys(XMADDR(address)).paddr);
+}
+
+static void init_level2_page(pmd_t *pmd, unsigned long addr)
+{
+	unsigned long end_addr = addr + PUD_SIZE;
+
+	while (addr < end_addr) {
+		native_set_pmd(pmd++, native_make_pmd(addr | __PAGE_KERNEL_LARGE_EXEC));
+		addr += PMD_SIZE;
+	}
+}
+
+static int init_level3_page(struct kimage *image, pud_t *pud,
+				unsigned long addr, unsigned long last_addr)
+{
+	pmd_t *pmd;
+	struct page *page;
+	unsigned long end_addr = addr + PGDIR_SIZE;
+
+	while ((addr < last_addr) && (addr < end_addr)) {
+		page = kimage_alloc_control_pages(image, 0);
+
+		if (!page)
+			return -ENOMEM;
+
+		pmd = page_address(page);
+		init_level2_page(pmd, addr);
+		native_set_pud(pud++, native_make_pud(__ma(pmd) | _KERNPG_TABLE));
+		addr += PUD_SIZE;
+	}
+
+	/* Clear the unused entries. */
+	while (addr < end_addr) {
+		native_pud_clear(pud++);
+		addr += PUD_SIZE;
+	}
+
+	return 0;
+}
+
+
+static int init_level4_page(struct kimage *image, pgd_t *pgd,
+				unsigned long addr, unsigned long last_addr)
+{
+	int rc;
+	pud_t *pud;
+	struct page *page;
+	unsigned long end_addr = addr + PTRS_PER_PGD * PGDIR_SIZE;
+
+	while ((addr < last_addr) && (addr < end_addr)) {
+		page = kimage_alloc_control_pages(image, 0);
+
+		if (!page)
+			return -ENOMEM;
+
+		pud = page_address(page);
+		rc = init_level3_page(image, pud, addr, last_addr);
+
+		if (rc)
+			return rc;
+
+		native_set_pgd(pgd++, native_make_pgd(__ma(pud) | _KERNPG_TABLE));
+		addr += PGDIR_SIZE;
+	}
+
+	/* Clear the unused entries. */
+	while (addr < end_addr) {
+		native_pgd_clear(pgd++);
+		addr += PGDIR_SIZE;
+	}
+
+	return 0;
+}
+
+static void free_transition_pgtable(struct kimage *image)
+{
+	free_page((unsigned long)image->arch.pgd);
+	free_page((unsigned long)image->arch.pud0);
+	free_page((unsigned long)image->arch.pud1);
+	free_page((unsigned long)image->arch.pmd0);
+	free_page((unsigned long)image->arch.pmd1);
+	free_page((unsigned long)image->arch.pte0);
+	free_page((unsigned long)image->arch.pte1);
+}
+
+static int alloc_transition_pgtable(struct kimage *image)
+{
+	image->arch.pgd = (pgd_t *)get_zeroed_page(GFP_KERNEL);
+
+	if (!image->arch.pgd)
+		goto err;
+
+	image->arch.pud0 = (pud_t *)get_zeroed_page(GFP_KERNEL);
+
+	if (!image->arch.pud0)
+		goto err;
+
+	image->arch.pud1 = (pud_t *)get_zeroed_page(GFP_KERNEL);
+
+	if (!image->arch.pud1)
+		goto err;
+
+	image->arch.pmd0 = (pmd_t *)get_zeroed_page(GFP_KERNEL);
+
+	if (!image->arch.pmd0)
+		goto err;
+
+	image->arch.pmd1 = (pmd_t *)get_zeroed_page(GFP_KERNEL);
+
+	if (!image->arch.pmd1)
+		goto err;
+
+	image->arch.pte0 = (pte_t *)get_zeroed_page(GFP_KERNEL);
+
+	if (!image->arch.pte0)
+		goto err;
+
+	image->arch.pte1 = (pte_t *)get_zeroed_page(GFP_KERNEL);
+
+	if (!image->arch.pte1)
+		goto err;
+
+	return 0;
+
+err:
+	free_transition_pgtable(image);
+
+	return -ENOMEM;
+}
+
+static int init_pgtable(struct kimage *image, pgd_t *pgd)
+{
+	int rc;
+	unsigned long max_mfn;
+
+	max_mfn = HYPERVISOR_memory_op(XENMEM_maximum_ram_page, NULL);
+
+	rc = init_level4_page(image, pgd, 0, PFN_PHYS(max_mfn));
+
+	if (rc)
+		return rc;
+
+	return alloc_transition_pgtable(image);
+}
+
+static int machine_xen_kexec_prepare(struct kimage *image)
+{
+#ifdef CONFIG_KEXEC_JUMP
+	if (image->preserve_context) {
+		pr_info_once("kexec: Context preservation is not "
+				"supported in Xen domains.\n");
+		return -ENOSYS;
+	}
+#endif
+
+	return init_pgtable(image, page_address(image->control_code_page));
+}
+
+static int machine_xen_kexec_load(struct kimage *image)
+{
+	void *control_page, *table_page;
+	struct xen_kexec_load xkl = {};
+
+	if (!image)
+		return 0;
+
+	table_page = page_address(image->control_code_page);
+	control_page = table_page + PAGE_SIZE;
+
+	memcpy(control_page, xen_relocate_kernel, xen_kexec_control_code_size);
+
+	xkl.type = image->type;
+	xkl.image.page_list[XK_MA_CONTROL_PAGE] = __ma(control_page);
+	xkl.image.page_list[XK_MA_TABLE_PAGE] = __ma(table_page);
+	xkl.image.page_list[XK_MA_PGD_PAGE] = __ma(image->arch.pgd);
+	xkl.image.page_list[XK_MA_PUD0_PAGE] = __ma(image->arch.pud0);
+	xkl.image.page_list[XK_MA_PUD1_PAGE] = __ma(image->arch.pud1);
+	xkl.image.page_list[XK_MA_PMD0_PAGE] = __ma(image->arch.pmd0);
+	xkl.image.page_list[XK_MA_PMD1_PAGE] = __ma(image->arch.pmd1);
+	xkl.image.page_list[XK_MA_PTE0_PAGE] = __ma(image->arch.pte0);
+	xkl.image.page_list[XK_MA_PTE1_PAGE] = __ma(image->arch.pte1);
+	xkl.image.indirection_page = image->head;
+	xkl.image.start_address = image->start;
+
+	return HYPERVISOR_kexec_op(KEXEC_CMD_kexec_load, &xkl);
+}
+
+static void machine_xen_kexec_cleanup(struct kimage *image)
+{
+	free_transition_pgtable(image);
+}
+
+static void machine_xen_kexec_unload(struct kimage *image)
+{
+	int rc;
+	struct xen_kexec_load xkl = {};
+
+	if (!image)
+		return;
+
+	xkl.type = image->type;
+	rc = HYPERVISOR_kexec_op(KEXEC_CMD_kexec_unload, &xkl);
+
+	WARN(rc, "kexec: %s: HYPERVISOR_kexec_op(): %i\n", __func__, rc);
+}
+
+static void machine_xen_kexec_shutdown(void)
+{
+}
+
+static void machine_xen_kexec(struct kimage *image)
+{
+	int rc;
+	struct xen_kexec_exec xke = {};
+
+	xke.type = image->type;
+	rc = HYPERVISOR_kexec_op(KEXEC_CMD_kexec, &xke);
+
+	pr_emerg("kexec: %s: HYPERVISOR_kexec_op(): %i\n", __func__, rc);
+	BUG();
+}
+
+void __init xen_init_kexec_ops(void)
+{
+	if (!xen_initial_domain())
+		return;
+
+	kexec_ops.always_use_normal_alloc = true;
+	kexec_ops.page_to_pfn = xen_page_to_mfn;
+	kexec_ops.pfn_to_page = xen_mfn_to_page;
+	kexec_ops.virt_to_phys = xen_virt_to_machine;
+	kexec_ops.phys_to_virt = xen_machine_to_virt;
+	kexec_ops.machine_kexec_prepare = machine_xen_kexec_prepare;
+	kexec_ops.machine_kexec_load = machine_xen_kexec_load;
+	kexec_ops.machine_kexec_cleanup = machine_xen_kexec_cleanup;
+	kexec_ops.machine_kexec_unload = machine_xen_kexec_unload;
+	kexec_ops.machine_kexec_shutdown = machine_xen_kexec_shutdown;
+	kexec_ops.machine_kexec = machine_xen_kexec;
+}
diff --git a/arch/x86/xen/relocate_kernel_64.S b/arch/x86/xen/relocate_kernel_64.S
new file mode 100644
index 0000000..8f641f1
--- /dev/null
+++ b/arch/x86/xen/relocate_kernel_64.S
@@ -0,0 +1,309 @@
+/*
+ * Copyright (c) 2002-2005 Eric Biederman <ebiederm@xmission.com>
+ * Copyright (c) 2011 Daniel Kiper
+ * Copyright (c) 2012 Daniel Kiper, Oracle Corporation
+ *
+ * kexec/kdump implementation for Xen was written by Daniel Kiper.
+ * Initial work on it was sponsored by Google under Google Summer
+ * of Code 2011 program and Citrix. Konrad Rzeszutek Wilk from Oracle
+ * was the mentor for this project.
+ *
+ * Some ideas are taken from:
+ *   - native kexec/kdump implementation,
+ *   - kexec/kdump implementation for Xen Linux Kernel Ver. 2.6.18,
+ *   - PV-GRUB.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License along
+ * with this program.  If not, see <http://www.gnu.org/licenses/>.
+ */
+
+#include <asm/page_types.h>
+#include <asm/pgtable_types.h>
+#include <asm/processor-flags.h>
+
+#include <asm/xen/kexec.h>
+
+#define PTR(x)	(x << 3)
+
+	.text
+	.code64
+	.globl	xen_kexec_control_code_size, xen_relocate_kernel
+
+xen_relocate_kernel:
+	/*
+	 * Must be relocatable PIC code callable as a C function.
+	 *
+	 * This function is called by Xen but here hypervisor is dead.
+	 * We are playing on bare metal.
+	 *
+	 * Every machine address passed to this function through
+	 * page_list (e.g. XK_MA_CONTROL_PAGE) is established
+	 * by dom0 during kexec load phase.
+	 *
+	 * Every virtual address passed to this function through page_list
+	 * (e.g. XK_VA_CONTROL_PAGE) is established by hypervisor during
+	 * HYPERVISOR_kexec_op(KEXEC_CMD_kexec_load) hypercall.
+	 *
+	 * %rdi - indirection_page,
+	 * %rsi - page_list,
+	 * %rdx - start_address,
+	 * %ecx - preserve_context (ignored).
+	 */
+
+	/* Zero out flags, and disable interrupts. */
+	pushq	$0
+	popfq
+
+	/*
+	 * Map the control page at its virtual address
+	 * in transition page table.
+	 */
+	movq	PTR(XK_VA_CONTROL_PAGE)(%rsi), %r8
+
+	/* Get PGD address and PGD entry index. */
+	movq	PTR(XK_VA_PGD_PAGE)(%rsi), %r9
+	movq	%r8, %r10
+	shrq	$PGDIR_SHIFT, %r10
+	andq	$(PTRS_PER_PGD - 1), %r10
+
+	/* Fill PGD entry with PUD0 reference. */
+	movq	PTR(XK_MA_PUD0_PAGE)(%rsi), %r11
+	orq	$_KERNPG_TABLE, %r11
+	movq	%r11, (%r9, %r10, 8)
+
+	/* Get PUD0 address and PUD0 entry index. */
+	movq	PTR(XK_VA_PUD0_PAGE)(%rsi), %r9
+	movq	%r8, %r10
+	shrq	$PUD_SHIFT, %r10
+	andq	$(PTRS_PER_PUD - 1), %r10
+
+	/* Fill PUD0 entry with PMD0 reference. */
+	movq	PTR(XK_MA_PMD0_PAGE)(%rsi), %r11
+	orq	$_KERNPG_TABLE, %r11
+	movq	%r11, (%r9, %r10, 8)
+
+	/* Get PMD0 address and PMD0 entry index. */
+	movq	PTR(XK_VA_PMD0_PAGE)(%rsi), %r9
+	movq	%r8, %r10
+	shrq	$PMD_SHIFT, %r10
+	andq	$(PTRS_PER_PMD - 1), %r10
+
+	/* Fill PMD0 entry with PTE0 reference. */
+	movq	PTR(XK_MA_PTE0_PAGE)(%rsi), %r11
+	orq	$_KERNPG_TABLE, %r11
+	movq	%r11, (%r9, %r10, 8)
+
+	/* Get PTE0 address and PTE0 entry index. */
+	movq	PTR(XK_VA_PTE0_PAGE)(%rsi), %r9
+	movq	%r8, %r10
+	shrq	$PAGE_SHIFT, %r10
+	andq	$(PTRS_PER_PTE - 1), %r10
+
+	/* Fill PTE0 entry with control page reference. */
+	movq	PTR(XK_MA_CONTROL_PAGE)(%rsi), %r11
+	orq	$__PAGE_KERNEL_EXEC, %r11
+	movq	%r11, (%r9, %r10, 8)
+
+	/*
+	 * Identity map the control page at its machine address
+	 * in transition page table.
+	 */
+	movq	PTR(XK_MA_CONTROL_PAGE)(%rsi), %r8
+
+	/* Get PGD address and PGD entry index. */
+	movq	PTR(XK_VA_PGD_PAGE)(%rsi), %r9
+	movq	%r8, %r10
+	shrq	$PGDIR_SHIFT, %r10
+	andq	$(PTRS_PER_PGD - 1), %r10
+
+	/* Fill PGD entry with PUD1 reference. */
+	movq	PTR(XK_MA_PUD1_PAGE)(%rsi), %r11
+	orq	$_KERNPG_TABLE, %r11
+	movq	%r11, (%r9, %r10, 8)
+
+	/* Get PUD1 address and PUD1 entry index. */
+	movq	PTR(XK_VA_PUD1_PAGE)(%rsi), %r9
+	movq	%r8, %r10
+	shrq	$PUD_SHIFT, %r10
+	andq	$(PTRS_PER_PUD - 1), %r10
+
+	/* Fill PUD1 entry with PMD1 reference. */
+	movq	PTR(XK_MA_PMD1_PAGE)(%rsi), %r11
+	orq	$_KERNPG_TABLE, %r11
+	movq	%r11, (%r9, %r10, 8)
+
+	/* Get PMD1 address and PMD1 entry index. */
+	movq	PTR(XK_VA_PMD1_PAGE)(%rsi), %r9
+	movq	%r8, %r10
+	shrq	$PMD_SHIFT, %r10
+	andq	$(PTRS_PER_PMD - 1), %r10
+
+	/* Fill PMD1 entry with PTE1 reference. */
+	movq	PTR(XK_MA_PTE1_PAGE)(%rsi), %r11
+	orq	$_KERNPG_TABLE, %r11
+	movq	%r11, (%r9, %r10, 8)
+
+	/* Get PTE1 address and PTE1 entry index. */
+	movq	PTR(XK_VA_PTE1_PAGE)(%rsi), %r9
+	movq	%r8, %r10
+	shrq	$PAGE_SHIFT, %r10
+	andq	$(PTRS_PER_PTE - 1), %r10
+
+	/* Fill PTE1 entry with control page reference. */
+	movq	PTR(XK_MA_CONTROL_PAGE)(%rsi), %r11
+	orq	$__PAGE_KERNEL_EXEC, %r11
+	movq	%r11, (%r9, %r10, 8)
+
+	/*
+	 * Get machine address of control page now.
+	 * This is impossible after page table switch.
+	 */
+	movq	PTR(XK_MA_CONTROL_PAGE)(%rsi), %r8
+
+	/* Get machine address of identity page table now too. */
+	movq	PTR(XK_MA_TABLE_PAGE)(%rsi), %r9
+
+	/* Get machine address of transition page table now too. */
+	movq	PTR(XK_MA_PGD_PAGE)(%rsi), %r10
+
+	/* Switch to transition page table. */
+	movq	%r10, %cr3
+
+	/* Setup a new stack at the end of machine address of control page. */
+	leaq	PAGE_SIZE(%r8), %rsp
+
+	/* Store start_address on the stack. */
+	pushq   %rdx
+
+	/* Jump to identity mapped page. */
+	addq	$(identity_mapped - xen_relocate_kernel), %r8
+	jmpq	*%r8
+
+identity_mapped:
+	/* Switch to identity page table. */
+	movq	%r9, %cr3
+
+	/*
+	 * Set %cr0 to a known state:
+	 *   - disable alignment check,
+	 *   - disable floating point emulation,
+	 *   - no task switch,
+	 *   - disable write protect,
+	 *   - enable protected mode,
+	 *   - enable paging.
+	 */
+	movq	%cr0, %rax
+	andq	$~(X86_CR0_AM | X86_CR0_EM | X86_CR0_TS | X86_CR0_WP), %rax
+	orl	$(X86_CR0_PE | X86_CR0_PG), %eax
+	movq	%rax, %cr0
+
+	/*
+	 * Set %cr4 to a known state:
+	 *   - enable physical address extension.
+	 */
+	movq	$X86_CR4_PAE, %rax
+	movq	%rax, %cr4
+
+	jmp	1f
+
+1:
+	/* Flush the TLB (needed?). */
+	movq	%r9, %cr3
+
+	/* Do the copies. */
+	movq	%rdi, %rcx	/* Put the indirection_page in %rcx. */
+	xorq	%rdi, %rdi
+	xorq	%rsi, %rsi
+	jmp	1f
+
+0:
+	/*
+	 * Top, read another quadword from the indirection page.
+	 * Indirection page is an array which contains source
+	 * and destination address pairs. If all pairs could
+	 * not fit in one page then at the end of given
+	 * indirection page is pointer to next one.
+	 * Copy is stopped when done indicator
+	 * is found in indirection page.
+	 */
+	movq	(%rbx), %rcx
+	addq	$8, %rbx
+
+1:
+	testq	$0x1, %rcx	/* Is it a destination page? */
+	jz	2f
+
+	movq	%rcx, %rdi
+	andq	$PAGE_MASK, %rdi
+	jmp	0b
+
+2:
+	testq	$0x2, %rcx	/* Is it an indirection page? */
+	jz	2f
+
+	movq	%rcx, %rbx
+	andq	$PAGE_MASK, %rbx
+	jmp	0b
+
+2:
+	testq	$0x4, %rcx	/* Is it the done indicator? */
+	jz	2f
+	jmp	3f
+
+2:
+	testq	$0x8, %rcx	/* Is it the source indicator? */
+	jz	0b		/* Ignore it otherwise. */
+
+	movq	%rcx, %rsi
+	andq	$PAGE_MASK, %rsi
+	movq	$512, %rcx
+
+	/* Copy page. */
+	rep	movsq
+	jmp	0b
+
+3:
+	/*
+	 * To be certain of avoiding problems with self-modifying code
+	 * I need to execute a serializing instruction here.
+	 * So I flush the TLB by reloading %cr3 here, it's handy,
+	 * and not processor dependent.
+	 */
+	movq	%cr3, %rax
+	movq	%rax, %cr3
+
+	/*
+	 * Set all of the registers to known values.
+	 * Leave %rsp alone.
+	 */
+	xorq	%rax, %rax
+	xorq	%rbx, %rbx
+	xorq    %rcx, %rcx
+	xorq    %rdx, %rdx
+	xorq    %rsi, %rsi
+	xorq    %rdi, %rdi
+	xorq    %rbp, %rbp
+	xorq	%r8, %r8
+	xorq	%r9, %r9
+	xorq	%r10, %r10
+	xorq	%r11, %r11
+	xorq	%r12, %r12
+	xorq	%r13, %r13
+	xorq	%r14, %r14
+	xorq	%r15, %r15
+
+	/* Jump to start_address. */
+	retq
+
+xen_kexec_control_code_size:
+	.long	. - xen_relocate_kernel
-- 
1.5.6.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 27 18:07:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Sep 2012 18:07: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 1THIUL-0000tS-HK; Thu, 27 Sep 2012 18:07:05 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <SRS0=Sf9V=H2=oracle.com=daniel.kiper@net-space.pl>)
	id 1THIUI-0000rd-91
	for xen-devel@lists.xensource.com; Thu, 27 Sep 2012 18:07:02 +0000
Received: from [85.158.138.51:8405] by server-7.bemta-3.messagelabs.com id
	DC/2C-15765-5C594605; Thu, 27 Sep 2012 18:07:01 +0000
X-Env-Sender: SRS0=Sf9V=H2=oracle.com=daniel.kiper@net-space.pl
X-Msg-Ref: server-14.tower-174.messagelabs.com!1348769218!25906058!10
X-Originating-IP: [89.174.63.77]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31645 invoked from network); 27 Sep 2012 18:07:00 -0000
Received: from router-fw.net-space.pl (HELO router-fw.net-space.pl)
	(89.174.63.77)
	by server-14.tower-174.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 27 Sep 2012 18:07:00 -0000
Received: from dev-00.local.net-space.pl ([192.168.1.5]:54110 "EHLO
	localhost.localdomain" TLS-CIPHER: <none>)
	by router-fw-old.local.net-space.pl with ESMTP id S1623298Ab2I0SGj
	(ORCPT <rfc822;xen-devel@lists.xensource.com>);
	Thu, 27 Sep 2012 20:06:39 +0200
From: Daniel Kiper <daniel.kiper@oracle.com>
To: konrad.wilk@oracle.com, andrew.cooper3@citrix.com,
	jbeulich@suse.com, linux-kernel@vger.kernel.org,
	xen-devel@lists.xensource.com
Date: Thu, 27 Sep 2012 20:06:32 +0200
Message-Id: <1348769198-29580-6-git-send-email-daniel.kiper@oracle.com>
X-Mailer: git-send-email 1.5.6.5
In-Reply-To: <1348769198-29580-5-git-send-email-daniel.kiper@oracle.com>
References: <1348769198-29580-1-git-send-email-daniel.kiper@oracle.com>
	<1348769198-29580-2-git-send-email-daniel.kiper@oracle.com>
	<1348769198-29580-3-git-send-email-daniel.kiper@oracle.com>
	<1348769198-29580-4-git-send-email-daniel.kiper@oracle.com>
	<1348769198-29580-5-git-send-email-daniel.kiper@oracle.com>
X-Bogosity: No, spamicity=0.000000
Cc: Daniel Kiper <daniel.kiper@oracle.com>
Subject: [Xen-devel] [PATCH 05/11] x86/xen: Register resources required by
	kexec-tools
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Register resources required by kexec-tools.

Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
---
 arch/x86/xen/kexec.c |  150 ++++++++++++++++++++++++++++++++++++++++++++++++++
 1 files changed, 150 insertions(+), 0 deletions(-)
 create mode 100644 arch/x86/xen/kexec.c

diff --git a/arch/x86/xen/kexec.c b/arch/x86/xen/kexec.c
new file mode 100644
index 0000000..eb0108b
--- /dev/null
+++ b/arch/x86/xen/kexec.c
@@ -0,0 +1,150 @@
+/*
+ * Copyright (c) 2011 Daniel Kiper
+ * Copyright (c) 2012 Daniel Kiper, Oracle Corporation
+ *
+ * kexec/kdump implementation for Xen was written by Daniel Kiper.
+ * Initial work on it was sponsored by Google under Google Summer
+ * of Code 2011 program and Citrix. Konrad Rzeszutek Wilk from Oracle
+ * was the mentor for this project.
+ *
+ * Some ideas are taken from:
+ *   - native kexec/kdump implementation,
+ *   - kexec/kdump implementation for Xen Linux Kernel Ver. 2.6.18,
+ *   - PV-GRUB.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License along
+ * with this program.  If not, see <http://www.gnu.org/licenses/>.
+ */
+
+#include <linux/errno.h>
+#include <linux/init.h>
+#include <linux/ioport.h>
+#include <linux/kernel.h>
+#include <linux/kexec.h>
+#include <linux/slab.h>
+#include <linux/string.h>
+
+#include <xen/interface/platform.h>
+#include <xen/interface/xen.h>
+#include <xen/xen.h>
+
+#include <asm/xen/hypercall.h>
+
+unsigned long xen_vmcoreinfo_maddr = 0;
+unsigned long xen_vmcoreinfo_max_size = 0;
+
+static int __init xen_init_kexec_resources(void)
+{
+	int rc;
+	static struct resource xen_hypervisor_res = {
+		.name = "Hypervisor code and data",
+		.flags = IORESOURCE_BUSY | IORESOURCE_MEM
+	};
+	struct resource *cpu_res;
+	struct xen_kexec_range xkr;
+	struct xen_platform_op cpuinfo_op;
+	uint32_t cpus, i;
+
+	if (!xen_initial_domain())
+		return 0;
+
+	if (strstr(boot_command_line, "crashkernel="))
+		pr_info("kexec: Ignoring crashkernel option. "
+			"It should be passed to Xen hypervisor.\n");
+
+	/* Register Crash kernel resource. */
+	xkr.range = KEXEC_RANGE_MA_CRASH;
+	rc = HYPERVISOR_kexec_op(KEXEC_CMD_kexec_get_range, &xkr);
+
+	if (rc) {
+		pr_info("kexec: %s: HYPERVISOR_kexec_op(KEXEC_RANGE_MA_CRASH)"
+			": %i\n", __func__, rc);
+		return rc;
+	}
+
+	if (!xkr.size)
+		return 0;
+
+	crashk_res.start = xkr.start;
+	crashk_res.end = xkr.start + xkr.size - 1;
+	insert_resource(&iomem_resource, &crashk_res);
+
+	/* Register Hypervisor code and data resource. */
+	xkr.range = KEXEC_RANGE_MA_XEN;
+	rc = HYPERVISOR_kexec_op(KEXEC_CMD_kexec_get_range, &xkr);
+
+	if (rc) {
+		pr_info("kexec: %s: HYPERVISOR_kexec_op(KEXEC_RANGE_MA_XEN)"
+			": %i\n", __func__, rc);
+		return rc;
+	}
+
+	xen_hypervisor_res.start = xkr.start;
+	xen_hypervisor_res.end = xkr.start + xkr.size - 1;
+	insert_resource(&iomem_resource, &xen_hypervisor_res);
+
+	/* Determine maximum number of physical CPUs. */
+	cpuinfo_op.cmd = XENPF_get_cpuinfo;
+	cpuinfo_op.u.pcpu_info.xen_cpuid = 0;
+	rc = HYPERVISOR_dom0_op(&cpuinfo_op);
+
+	if (rc) {
+		pr_info("kexec: %s: HYPERVISOR_dom0_op(): %i\n", __func__, rc);
+		return rc;
+	}
+
+	cpus = cpuinfo_op.u.pcpu_info.max_present + 1;
+
+	/* Register CPUs Crash note resources. */
+	cpu_res = kcalloc(cpus, sizeof(struct resource), GFP_KERNEL);
+
+	if (!cpu_res) {
+		pr_info("kexec: %s: kcalloc(): %i\n", __func__, -ENOMEM);
+		return -ENOMEM;
+	}
+
+	for (i = 0; i < cpus; ++i) {
+		xkr.range = KEXEC_RANGE_MA_CPU;
+		xkr.nr = i;
+		rc = HYPERVISOR_kexec_op(KEXEC_CMD_kexec_get_range, &xkr);
+
+		if (rc) {
+			pr_info("kexec: %s: cpu: %u: HYPERVISOR_kexec_op"
+				"(KEXEC_RANGE_MA_XEN): %i\n", __func__, i, rc);
+			continue;
+		}
+
+		cpu_res->name = "Crash note";
+		cpu_res->start = xkr.start;
+		cpu_res->end = xkr.start + xkr.size - 1;
+		cpu_res->flags = IORESOURCE_BUSY | IORESOURCE_MEM;
+		insert_resource(&iomem_resource, cpu_res++);
+	}
+
+	/* Get vmcoreinfo address and maximum allowed size. */
+	xkr.range = KEXEC_RANGE_MA_VMCOREINFO;
+	rc = HYPERVISOR_kexec_op(KEXEC_CMD_kexec_get_range, &xkr);
+
+	if (rc) {
+		pr_info("kexec: %s: HYPERVISOR_kexec_op(KEXEC_RANGE_MA_VMCOREINFO)"
+			": %i\n", __func__, rc);
+		return rc;
+	}
+
+	xen_vmcoreinfo_maddr = xkr.start;
+	xen_vmcoreinfo_max_size = xkr.size;
+
+	return 0;
+}
+
+core_initcall(xen_init_kexec_resources);
-- 
1.5.6.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 27 18:07:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Sep 2012 18:07: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 1THIUM-0000tx-A7; Thu, 27 Sep 2012 18:07:06 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <SRS0=Sf9V=H2=oracle.com=daniel.kiper@net-space.pl>)
	id 1THIUI-0000rg-Ca
	for xen-devel@lists.xensource.com; Thu, 27 Sep 2012 18:07:02 +0000
Received: from [85.158.138.51:42642] by server-9.bemta-3.messagelabs.com id
	74/92-20338-5C594605; Thu, 27 Sep 2012 18:07:01 +0000
X-Env-Sender: SRS0=Sf9V=H2=oracle.com=daniel.kiper@net-space.pl
X-Msg-Ref: server-14.tower-174.messagelabs.com!1348769218!25906058!11
X-Originating-IP: [89.174.63.77]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31661 invoked from network); 27 Sep 2012 18:07:00 -0000
Received: from router-fw.net-space.pl (HELO router-fw.net-space.pl)
	(89.174.63.77)
	by server-14.tower-174.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 27 Sep 2012 18:07:00 -0000
Received: from dev-00.local.net-space.pl ([192.168.1.5]:54110 "EHLO
	localhost.localdomain" TLS-CIPHER: <none>)
	by router-fw-old.local.net-space.pl with ESMTP id S1623297Ab2I0SGj
	(ORCPT <rfc822;xen-devel@lists.xensource.com>);
	Thu, 27 Sep 2012 20:06:39 +0200
From: Daniel Kiper <daniel.kiper@oracle.com>
To: konrad.wilk@oracle.com, andrew.cooper3@citrix.com,
	jbeulich@suse.com, linux-kernel@vger.kernel.org,
	xen-devel@lists.xensource.com
Date: Thu, 27 Sep 2012 20:06:31 +0200
Message-Id: <1348769198-29580-5-git-send-email-daniel.kiper@oracle.com>
X-Mailer: git-send-email 1.5.6.5
In-Reply-To: <1348769198-29580-4-git-send-email-daniel.kiper@oracle.com>
References: <1348769198-29580-1-git-send-email-daniel.kiper@oracle.com>
	<1348769198-29580-2-git-send-email-daniel.kiper@oracle.com>
	<1348769198-29580-3-git-send-email-daniel.kiper@oracle.com>
	<1348769198-29580-4-git-send-email-daniel.kiper@oracle.com>
X-Bogosity: No, spamicity=0.000000
Cc: Daniel Kiper <daniel.kiper@oracle.com>
Subject: [Xen-devel] [PATCH 04/11] x86/xen: Introduce architecture dependent
	data for kexec/kdump
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 architecture dependent constants, structures and
functions required by Xen kexec/kdump implementation.

Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
---
 arch/x86/include/asm/xen/hypercall.h |    6 +++
 arch/x86/include/asm/xen/kexec.h     |   83 ++++++++++++++++++++++++++++++++++
 2 files changed, 89 insertions(+), 0 deletions(-)
 create mode 100644 arch/x86/include/asm/xen/kexec.h

diff --git a/arch/x86/include/asm/xen/hypercall.h b/arch/x86/include/asm/xen/hypercall.h
index 59c226d..553544c 100644
--- a/arch/x86/include/asm/xen/hypercall.h
+++ b/arch/x86/include/asm/xen/hypercall.h
@@ -466,6 +466,12 @@ HYPERVISOR_hvm_op(int op, void *arg)
 }
 
 static inline int
+HYPERVISOR_kexec_op(unsigned long op, void *args)
+{
+	return _hypercall2(int, kexec_op, op, args);
+}
+
+static inline int
 HYPERVISOR_tmem_op(
 	struct tmem_op *op)
 {
diff --git a/arch/x86/include/asm/xen/kexec.h b/arch/x86/include/asm/xen/kexec.h
new file mode 100644
index 0000000..3349031
--- /dev/null
+++ b/arch/x86/include/asm/xen/kexec.h
@@ -0,0 +1,83 @@
+/*
+ * Copyright (c) 2011 Daniel Kiper
+ * Copyright (c) 2012 Daniel Kiper, Oracle Corporation
+ *
+ * kexec/kdump implementation for Xen was written by Daniel Kiper.
+ * Initial work on it was sponsored by Google under Google Summer
+ * of Code 2011 program and Citrix. Konrad Rzeszutek Wilk from Oracle
+ * was the mentor for this project.
+ *
+ * Some ideas are taken from:
+ *   - native kexec/kdump implementation,
+ *   - kexec/kdump implementation for Xen Linux Kernel Ver. 2.6.18,
+ *   - PV-GRUB.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License along
+ * with this program.  If not, see <http://www.gnu.org/licenses/>.
+ */
+
+#ifndef _ASM_X86_XEN_KEXEC_H
+#define _ASM_X86_XEN_KEXEC_H
+
+#include <linux/init.h>
+
+#define KEXEC_XEN_NO_PAGES	17
+
+#define XK_MA_CONTROL_PAGE	0
+#define XK_VA_CONTROL_PAGE	1
+#define XK_MA_PGD_PAGE		2
+#define XK_VA_PGD_PAGE		3
+#define XK_MA_PUD0_PAGE		4
+#define XK_VA_PUD0_PAGE		5
+#define XK_MA_PUD1_PAGE		6
+#define XK_VA_PUD1_PAGE		7
+#define XK_MA_PMD0_PAGE		8
+#define XK_VA_PMD0_PAGE		9
+#define XK_MA_PMD1_PAGE		10
+#define XK_VA_PMD1_PAGE		11
+#define XK_MA_PTE0_PAGE		12
+#define XK_VA_PTE0_PAGE		13
+#define XK_MA_PTE1_PAGE		14
+#define XK_VA_PTE1_PAGE		15
+#define XK_MA_TABLE_PAGE	16
+
+#ifndef __ASSEMBLY__
+struct xen_kexec_image {
+	unsigned long page_list[KEXEC_XEN_NO_PAGES];
+	unsigned long indirection_page;
+	unsigned long start_address;
+};
+
+struct xen_kexec_load {
+	int type;
+	struct xen_kexec_image image;
+};
+
+extern unsigned int xen_kexec_control_code_size;
+
+extern void __init xen_init_kexec_ops(void);
+
+#ifdef CONFIG_X86_32
+extern void xen_relocate_kernel(unsigned long indirection_page,
+				unsigned long *page_list,
+				unsigned long start_address,
+				unsigned int has_pae,
+				unsigned int preserve_context);
+#else
+extern void xen_relocate_kernel(unsigned long indirection_page,
+				unsigned long *page_list,
+				unsigned long start_address,
+				unsigned int preserve_context);
+#endif
+#endif
+#endif /* _ASM_X86_XEN_KEXEC_H */
-- 
1.5.6.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 27 18:07:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Sep 2012 18:07: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 1THIUI-0000rs-Ow; Thu, 27 Sep 2012 18:07:02 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <SRS0=Sf9V=H2=oracle.com=daniel.kiper@net-space.pl>)
	id 1THIUG-0000r1-GC
	for xen-devel@lists.xensource.com; Thu, 27 Sep 2012 18:07:00 +0000
Received: from [85.158.138.51:8341] by server-5.bemta-3.messagelabs.com id
	3A/20-00589-3C594605; Thu, 27 Sep 2012 18:06:59 +0000
X-Env-Sender: SRS0=Sf9V=H2=oracle.com=daniel.kiper@net-space.pl
X-Msg-Ref: server-14.tower-174.messagelabs.com!1348769218!25906058!3
X-Originating-IP: [89.174.63.77]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31568 invoked from network); 27 Sep 2012 18:06:59 -0000
Received: from router-fw.net-space.pl (HELO router-fw.net-space.pl)
	(89.174.63.77)
	by server-14.tower-174.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 27 Sep 2012 18:06:59 -0000
Received: from dev-00.local.net-space.pl ([192.168.1.5]:54110 "EHLO
	localhost.localdomain" TLS-CIPHER: <none>)
	by router-fw-old.local.net-space.pl with ESMTP id S1623295Ab2I0SGj
	(ORCPT <rfc822;xen-devel@lists.xensource.com>);
	Thu, 27 Sep 2012 20:06:39 +0200
From: Daniel Kiper <daniel.kiper@oracle.com>
To: konrad.wilk@oracle.com, andrew.cooper3@citrix.com,
	jbeulich@suse.com, linux-kernel@vger.kernel.org,
	xen-devel@lists.xensource.com
Date: Thu, 27 Sep 2012 20:06:29 +0200
Message-Id: <1348769198-29580-3-git-send-email-daniel.kiper@oracle.com>
X-Mailer: git-send-email 1.5.6.5
In-Reply-To: <1348769198-29580-2-git-send-email-daniel.kiper@oracle.com>
References: <1348769198-29580-1-git-send-email-daniel.kiper@oracle.com>
	<1348769198-29580-2-git-send-email-daniel.kiper@oracle.com>
X-Bogosity: No, spamicity=0.020762
Cc: Daniel Kiper <daniel.kiper@oracle.com>
Subject: [Xen-devel] [PATCH 02/11] x86/kexec: Add extra pointers to
	transition page table PGD, PUD, PMD and PTE
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Some implementations (e.g. Xen PVOPS) could not use part of identity page table
to construct transition page table. It means that they require separate PUDs,
PMDs and PTEs for virtual and physical (identity) mapping. To satisfy that
requirement add extra pointer to PGD, PUD, PMD and PTE and align existing code.

Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
---
 arch/x86/include/asm/kexec.h       |   10 +++++++---
 arch/x86/kernel/machine_kexec_64.c |   12 ++++++------
 2 files changed, 13 insertions(+), 9 deletions(-)

diff --git a/arch/x86/include/asm/kexec.h b/arch/x86/include/asm/kexec.h
index 317ff17..3cf5600 100644
--- a/arch/x86/include/asm/kexec.h
+++ b/arch/x86/include/asm/kexec.h
@@ -157,9 +157,13 @@ struct kimage_arch {
 };
 #else
 struct kimage_arch {
-	pud_t *pud;
-	pmd_t *pmd;
-	pte_t *pte;
+	pgd_t *pgd;
+	pud_t *pud0;
+	pud_t *pud1;
+	pmd_t *pmd0;
+	pmd_t *pmd1;
+	pte_t *pte0;
+	pte_t *pte1;
 };
 #endif
 
diff --git a/arch/x86/kernel/machine_kexec_64.c b/arch/x86/kernel/machine_kexec_64.c
index b3ea9db..976e54b 100644
--- a/arch/x86/kernel/machine_kexec_64.c
+++ b/arch/x86/kernel/machine_kexec_64.c
@@ -137,9 +137,9 @@ out:
 
 static void free_transition_pgtable(struct kimage *image)
 {
-	free_page((unsigned long)image->arch.pud);
-	free_page((unsigned long)image->arch.pmd);
-	free_page((unsigned long)image->arch.pte);
+	free_page((unsigned long)image->arch.pud0);
+	free_page((unsigned long)image->arch.pmd0);
+	free_page((unsigned long)image->arch.pte0);
 }
 
 static int init_transition_pgtable(struct kimage *image, pgd_t *pgd)
@@ -157,7 +157,7 @@ static int init_transition_pgtable(struct kimage *image, pgd_t *pgd)
 		pud = (pud_t *)get_zeroed_page(GFP_KERNEL);
 		if (!pud)
 			goto err;
-		image->arch.pud = pud;
+		image->arch.pud0 = pud;
 		set_pgd(pgd, __pgd(__pa(pud) | _KERNPG_TABLE));
 	}
 	pud = pud_offset(pgd, vaddr);
@@ -165,7 +165,7 @@ static int init_transition_pgtable(struct kimage *image, pgd_t *pgd)
 		pmd = (pmd_t *)get_zeroed_page(GFP_KERNEL);
 		if (!pmd)
 			goto err;
-		image->arch.pmd = pmd;
+		image->arch.pmd0 = pmd;
 		set_pud(pud, __pud(__pa(pmd) | _KERNPG_TABLE));
 	}
 	pmd = pmd_offset(pud, vaddr);
@@ -173,7 +173,7 @@ static int init_transition_pgtable(struct kimage *image, pgd_t *pgd)
 		pte = (pte_t *)get_zeroed_page(GFP_KERNEL);
 		if (!pte)
 			goto err;
-		image->arch.pte = pte;
+		image->arch.pte0 = pte;
 		set_pmd(pmd, __pmd(__pa(pte) | _KERNPG_TABLE));
 	}
 	pte = pte_offset_kernel(pmd, vaddr);
-- 
1.5.6.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 27 18:07:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Sep 2012 18:07: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 1THIUJ-0000sL-HC; Thu, 27 Sep 2012 18:07:03 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <SRS0=Sf9V=H2=oracle.com=daniel.kiper@net-space.pl>)
	id 1THIUG-0000qz-VM
	for xen-devel@lists.xensource.com; Thu, 27 Sep 2012 18:07:01 +0000
Received: from [85.158.138.51:42609] by server-3.bemta-3.messagelabs.com id
	E7/A2-25962-4C594605; Thu, 27 Sep 2012 18:07:00 +0000
X-Env-Sender: SRS0=Sf9V=H2=oracle.com=daniel.kiper@net-space.pl
X-Msg-Ref: server-14.tower-174.messagelabs.com!1348769218!25906058!8
X-Originating-IP: [89.174.63.77]
X-SpamReason: No, hits=0.0 required=7.0 tests=UPPERCASE_25_50
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31616 invoked from network); 27 Sep 2012 18:07:00 -0000
Received: from router-fw.net-space.pl (HELO router-fw.net-space.pl)
	(89.174.63.77)
	by server-14.tower-174.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 27 Sep 2012 18:07:00 -0000
Received: from dev-00.local.net-space.pl ([192.168.1.5]:54110 "EHLO
	localhost.localdomain" TLS-CIPHER: <none>)
	by router-fw-old.local.net-space.pl with ESMTP id S1623303Ab2I0SGj
	(ORCPT <rfc822;xen-devel@lists.xensource.com>);
	Thu, 27 Sep 2012 20:06:39 +0200
From: Daniel Kiper <daniel.kiper@oracle.com>
To: konrad.wilk@oracle.com, andrew.cooper3@citrix.com,
	jbeulich@suse.com, linux-kernel@vger.kernel.org,
	xen-devel@lists.xensource.com
Date: Thu, 27 Sep 2012 20:06:35 +0200
Message-Id: <1348769198-29580-9-git-send-email-daniel.kiper@oracle.com>
X-Mailer: git-send-email 1.5.6.5
In-Reply-To: <1348769198-29580-8-git-send-email-daniel.kiper@oracle.com>
References: <1348769198-29580-1-git-send-email-daniel.kiper@oracle.com>
	<1348769198-29580-2-git-send-email-daniel.kiper@oracle.com>
	<1348769198-29580-3-git-send-email-daniel.kiper@oracle.com>
	<1348769198-29580-4-git-send-email-daniel.kiper@oracle.com>
	<1348769198-29580-5-git-send-email-daniel.kiper@oracle.com>
	<1348769198-29580-6-git-send-email-daniel.kiper@oracle.com>
	<1348769198-29580-7-git-send-email-daniel.kiper@oracle.com>
	<1348769198-29580-8-git-send-email-daniel.kiper@oracle.com>
X-Bogosity: No, spamicity=0.414951
Cc: Daniel Kiper <daniel.kiper@oracle.com>
Subject: [Xen-devel] [PATCH 08/11] x86/xen: Add kexec/kdump makefile rules
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 kexec/kdump makefile rules.

Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
---
 arch/x86/xen/Makefile |    3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/arch/x86/xen/Makefile b/arch/x86/xen/Makefile
index 96ab2c0..7a5db44 100644
--- a/arch/x86/xen/Makefile
+++ b/arch/x86/xen/Makefile
@@ -22,3 +22,6 @@ obj-$(CONFIG_PARAVIRT_SPINLOCKS)+= spinlock.o
 obj-$(CONFIG_XEN_DEBUG_FS)	+= debugfs.o
 obj-$(CONFIG_XEN_DOM0)		+= apic.o vga.o
 obj-$(CONFIG_SWIOTLB_XEN)	+= pci-swiotlb-xen.o
+obj-$(CONFIG_KEXEC)		+= kexec.o
+obj-$(CONFIG_KEXEC)		+= machine_kexec_$(BITS).o
+obj-$(CONFIG_KEXEC)		+= relocate_kernel_$(BITS).o
-- 
1.5.6.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 27 18:07:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Sep 2012 18:07: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 1THIUM-0000tx-A7; Thu, 27 Sep 2012 18:07:06 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <SRS0=Sf9V=H2=oracle.com=daniel.kiper@net-space.pl>)
	id 1THIUI-0000rg-Ca
	for xen-devel@lists.xensource.com; Thu, 27 Sep 2012 18:07:02 +0000
Received: from [85.158.138.51:42642] by server-9.bemta-3.messagelabs.com id
	74/92-20338-5C594605; Thu, 27 Sep 2012 18:07:01 +0000
X-Env-Sender: SRS0=Sf9V=H2=oracle.com=daniel.kiper@net-space.pl
X-Msg-Ref: server-14.tower-174.messagelabs.com!1348769218!25906058!11
X-Originating-IP: [89.174.63.77]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31661 invoked from network); 27 Sep 2012 18:07:00 -0000
Received: from router-fw.net-space.pl (HELO router-fw.net-space.pl)
	(89.174.63.77)
	by server-14.tower-174.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 27 Sep 2012 18:07:00 -0000
Received: from dev-00.local.net-space.pl ([192.168.1.5]:54110 "EHLO
	localhost.localdomain" TLS-CIPHER: <none>)
	by router-fw-old.local.net-space.pl with ESMTP id S1623297Ab2I0SGj
	(ORCPT <rfc822;xen-devel@lists.xensource.com>);
	Thu, 27 Sep 2012 20:06:39 +0200
From: Daniel Kiper <daniel.kiper@oracle.com>
To: konrad.wilk@oracle.com, andrew.cooper3@citrix.com,
	jbeulich@suse.com, linux-kernel@vger.kernel.org,
	xen-devel@lists.xensource.com
Date: Thu, 27 Sep 2012 20:06:31 +0200
Message-Id: <1348769198-29580-5-git-send-email-daniel.kiper@oracle.com>
X-Mailer: git-send-email 1.5.6.5
In-Reply-To: <1348769198-29580-4-git-send-email-daniel.kiper@oracle.com>
References: <1348769198-29580-1-git-send-email-daniel.kiper@oracle.com>
	<1348769198-29580-2-git-send-email-daniel.kiper@oracle.com>
	<1348769198-29580-3-git-send-email-daniel.kiper@oracle.com>
	<1348769198-29580-4-git-send-email-daniel.kiper@oracle.com>
X-Bogosity: No, spamicity=0.000000
Cc: Daniel Kiper <daniel.kiper@oracle.com>
Subject: [Xen-devel] [PATCH 04/11] x86/xen: Introduce architecture dependent
	data for kexec/kdump
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 architecture dependent constants, structures and
functions required by Xen kexec/kdump implementation.

Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
---
 arch/x86/include/asm/xen/hypercall.h |    6 +++
 arch/x86/include/asm/xen/kexec.h     |   83 ++++++++++++++++++++++++++++++++++
 2 files changed, 89 insertions(+), 0 deletions(-)
 create mode 100644 arch/x86/include/asm/xen/kexec.h

diff --git a/arch/x86/include/asm/xen/hypercall.h b/arch/x86/include/asm/xen/hypercall.h
index 59c226d..553544c 100644
--- a/arch/x86/include/asm/xen/hypercall.h
+++ b/arch/x86/include/asm/xen/hypercall.h
@@ -466,6 +466,12 @@ HYPERVISOR_hvm_op(int op, void *arg)
 }
 
 static inline int
+HYPERVISOR_kexec_op(unsigned long op, void *args)
+{
+	return _hypercall2(int, kexec_op, op, args);
+}
+
+static inline int
 HYPERVISOR_tmem_op(
 	struct tmem_op *op)
 {
diff --git a/arch/x86/include/asm/xen/kexec.h b/arch/x86/include/asm/xen/kexec.h
new file mode 100644
index 0000000..3349031
--- /dev/null
+++ b/arch/x86/include/asm/xen/kexec.h
@@ -0,0 +1,83 @@
+/*
+ * Copyright (c) 2011 Daniel Kiper
+ * Copyright (c) 2012 Daniel Kiper, Oracle Corporation
+ *
+ * kexec/kdump implementation for Xen was written by Daniel Kiper.
+ * Initial work on it was sponsored by Google under Google Summer
+ * of Code 2011 program and Citrix. Konrad Rzeszutek Wilk from Oracle
+ * was the mentor for this project.
+ *
+ * Some ideas are taken from:
+ *   - native kexec/kdump implementation,
+ *   - kexec/kdump implementation for Xen Linux Kernel Ver. 2.6.18,
+ *   - PV-GRUB.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License along
+ * with this program.  If not, see <http://www.gnu.org/licenses/>.
+ */
+
+#ifndef _ASM_X86_XEN_KEXEC_H
+#define _ASM_X86_XEN_KEXEC_H
+
+#include <linux/init.h>
+
+#define KEXEC_XEN_NO_PAGES	17
+
+#define XK_MA_CONTROL_PAGE	0
+#define XK_VA_CONTROL_PAGE	1
+#define XK_MA_PGD_PAGE		2
+#define XK_VA_PGD_PAGE		3
+#define XK_MA_PUD0_PAGE		4
+#define XK_VA_PUD0_PAGE		5
+#define XK_MA_PUD1_PAGE		6
+#define XK_VA_PUD1_PAGE		7
+#define XK_MA_PMD0_PAGE		8
+#define XK_VA_PMD0_PAGE		9
+#define XK_MA_PMD1_PAGE		10
+#define XK_VA_PMD1_PAGE		11
+#define XK_MA_PTE0_PAGE		12
+#define XK_VA_PTE0_PAGE		13
+#define XK_MA_PTE1_PAGE		14
+#define XK_VA_PTE1_PAGE		15
+#define XK_MA_TABLE_PAGE	16
+
+#ifndef __ASSEMBLY__
+struct xen_kexec_image {
+	unsigned long page_list[KEXEC_XEN_NO_PAGES];
+	unsigned long indirection_page;
+	unsigned long start_address;
+};
+
+struct xen_kexec_load {
+	int type;
+	struct xen_kexec_image image;
+};
+
+extern unsigned int xen_kexec_control_code_size;
+
+extern void __init xen_init_kexec_ops(void);
+
+#ifdef CONFIG_X86_32
+extern void xen_relocate_kernel(unsigned long indirection_page,
+				unsigned long *page_list,
+				unsigned long start_address,
+				unsigned int has_pae,
+				unsigned int preserve_context);
+#else
+extern void xen_relocate_kernel(unsigned long indirection_page,
+				unsigned long *page_list,
+				unsigned long start_address,
+				unsigned int preserve_context);
+#endif
+#endif
+#endif /* _ASM_X86_XEN_KEXEC_H */
-- 
1.5.6.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 27 18:07:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Sep 2012 18:07: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 1THIUH-0000rS-Jl; Thu, 27 Sep 2012 18:07:01 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <SRS0=Sf9V=H2=oracle.com=daniel.kiper@net-space.pl>)
	id 1THIUG-0000qz-3Z
	for xen-devel@lists.xensource.com; Thu, 27 Sep 2012 18:07:00 +0000
Received: from [85.158.138.51:42568] by server-3.bemta-3.messagelabs.com id
	C3/A2-25962-3C594605; Thu, 27 Sep 2012 18:06:59 +0000
X-Env-Sender: SRS0=Sf9V=H2=oracle.com=daniel.kiper@net-space.pl
X-Msg-Ref: server-14.tower-174.messagelabs.com!1348769218!25906058!1
X-Originating-IP: [89.174.63.77]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31561 invoked from network); 27 Sep 2012 18:06:58 -0000
Received: from router-fw.net-space.pl (HELO router-fw.net-space.pl)
	(89.174.63.77)
	by server-14.tower-174.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 27 Sep 2012 18:06:58 -0000
Received: from dev-00.local.net-space.pl ([192.168.1.5]:54110 "EHLO
	localhost.localdomain" TLS-CIPHER: <none>)
	by router-fw-old.local.net-space.pl with ESMTP id S1623110Ab2I0SGi
	(ORCPT <rfc822;xen-devel@lists.xensource.com>);
	Thu, 27 Sep 2012 20:06:38 +0200
From: Daniel Kiper <daniel.kiper@oracle.com>
To: konrad.wilk@oracle.com, andrew.cooper3@citrix.com,
	jbeulich@suse.com, linux-kernel@vger.kernel.org,
	xen-devel@lists.xensource.com
Date: Thu, 27 Sep 2012 20:06:27 +0200
Message-Id: <1348769198-29580-1-git-send-email-daniel.kiper@oracle.com>
X-Mailer: git-send-email 1.5.6.5
X-Bogosity: No, spamicity=0.074274
Subject: [Xen-devel] [PATCH 00/11] xen: Initial kexec/kdump 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>
MIME-Version: 1.0
Content-Type: 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 set of patches contains initial kexec/kdump implementation for Xen.
Currently only dom0 is supported, however, almost all infrustructure
required for domU support is ready.

Daniel

 arch/x86/include/asm/kexec.h         |   10 +-
 arch/x86/include/asm/xen/hypercall.h |    6 +
 arch/x86/include/asm/xen/kexec.h     |   83 +++++++++
 arch/x86/kernel/machine_kexec_64.c   |   12 +-
 arch/x86/kernel/vmlinux.lds.S        |    7 +-
 arch/x86/xen/Makefile                |    3 +
 arch/x86/xen/enlighten.c             |   12 ++
 arch/x86/xen/kexec.c                 |  150 ++++++++++++++++
 arch/x86/xen/machine_kexec_32.c      |  245 ++++++++++++++++++++++++++
 arch/x86/xen/machine_kexec_64.c      |  301 +++++++++++++++++++++++++++++++
 arch/x86/xen/relocate_kernel_32.S    |  323 ++++++++++++++++++++++++++++++++++
 arch/x86/xen/relocate_kernel_64.S    |  309 ++++++++++++++++++++++++++++++++
 drivers/xen/sys-hypervisor.c         |   42 +++++-
 include/linux/kexec.h                |   18 ++
 include/xen/interface/xen.h          |   33 ++++
 kernel/kexec.c                       |  125 ++++++++++----
 16 files changed, 1636 insertions(+), 43 deletions(-)

Daniel Kiper (11):
      kexec: introduce kexec_ops struct
      x86/kexec: Add extra pointers to transition page table PGD, PUD, PMD and PTE
      xen: Introduce architecture independent data for kexec/kdump
      x86/xen: Introduce architecture dependent data for kexec/kdump
      x86/xen: Register resources required by kexec-tools
      x86/xen: Add i386 kexec/kdump implementation
      x86/xen: Add x86_64 kexec/kdump implementation
      x86/xen: Add kexec/kdump makefile rules
      x86/xen/enlighten: Add init and crash kexec/kdump hooks
      drivers/xen: Export vmcoreinfo through sysfs
      x86: Add Xen kexec control code size check to linker script

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 27 18:07:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Sep 2012 18:07: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 1THIUI-0000rs-Ow; Thu, 27 Sep 2012 18:07:02 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <SRS0=Sf9V=H2=oracle.com=daniel.kiper@net-space.pl>)
	id 1THIUG-0000r1-GC
	for xen-devel@lists.xensource.com; Thu, 27 Sep 2012 18:07:00 +0000
Received: from [85.158.138.51:8341] by server-5.bemta-3.messagelabs.com id
	3A/20-00589-3C594605; Thu, 27 Sep 2012 18:06:59 +0000
X-Env-Sender: SRS0=Sf9V=H2=oracle.com=daniel.kiper@net-space.pl
X-Msg-Ref: server-14.tower-174.messagelabs.com!1348769218!25906058!3
X-Originating-IP: [89.174.63.77]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31568 invoked from network); 27 Sep 2012 18:06:59 -0000
Received: from router-fw.net-space.pl (HELO router-fw.net-space.pl)
	(89.174.63.77)
	by server-14.tower-174.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 27 Sep 2012 18:06:59 -0000
Received: from dev-00.local.net-space.pl ([192.168.1.5]:54110 "EHLO
	localhost.localdomain" TLS-CIPHER: <none>)
	by router-fw-old.local.net-space.pl with ESMTP id S1623295Ab2I0SGj
	(ORCPT <rfc822;xen-devel@lists.xensource.com>);
	Thu, 27 Sep 2012 20:06:39 +0200
From: Daniel Kiper <daniel.kiper@oracle.com>
To: konrad.wilk@oracle.com, andrew.cooper3@citrix.com,
	jbeulich@suse.com, linux-kernel@vger.kernel.org,
	xen-devel@lists.xensource.com
Date: Thu, 27 Sep 2012 20:06:29 +0200
Message-Id: <1348769198-29580-3-git-send-email-daniel.kiper@oracle.com>
X-Mailer: git-send-email 1.5.6.5
In-Reply-To: <1348769198-29580-2-git-send-email-daniel.kiper@oracle.com>
References: <1348769198-29580-1-git-send-email-daniel.kiper@oracle.com>
	<1348769198-29580-2-git-send-email-daniel.kiper@oracle.com>
X-Bogosity: No, spamicity=0.020762
Cc: Daniel Kiper <daniel.kiper@oracle.com>
Subject: [Xen-devel] [PATCH 02/11] x86/kexec: Add extra pointers to
	transition page table PGD, PUD, PMD and PTE
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Some implementations (e.g. Xen PVOPS) could not use part of identity page table
to construct transition page table. It means that they require separate PUDs,
PMDs and PTEs for virtual and physical (identity) mapping. To satisfy that
requirement add extra pointer to PGD, PUD, PMD and PTE and align existing code.

Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
---
 arch/x86/include/asm/kexec.h       |   10 +++++++---
 arch/x86/kernel/machine_kexec_64.c |   12 ++++++------
 2 files changed, 13 insertions(+), 9 deletions(-)

diff --git a/arch/x86/include/asm/kexec.h b/arch/x86/include/asm/kexec.h
index 317ff17..3cf5600 100644
--- a/arch/x86/include/asm/kexec.h
+++ b/arch/x86/include/asm/kexec.h
@@ -157,9 +157,13 @@ struct kimage_arch {
 };
 #else
 struct kimage_arch {
-	pud_t *pud;
-	pmd_t *pmd;
-	pte_t *pte;
+	pgd_t *pgd;
+	pud_t *pud0;
+	pud_t *pud1;
+	pmd_t *pmd0;
+	pmd_t *pmd1;
+	pte_t *pte0;
+	pte_t *pte1;
 };
 #endif
 
diff --git a/arch/x86/kernel/machine_kexec_64.c b/arch/x86/kernel/machine_kexec_64.c
index b3ea9db..976e54b 100644
--- a/arch/x86/kernel/machine_kexec_64.c
+++ b/arch/x86/kernel/machine_kexec_64.c
@@ -137,9 +137,9 @@ out:
 
 static void free_transition_pgtable(struct kimage *image)
 {
-	free_page((unsigned long)image->arch.pud);
-	free_page((unsigned long)image->arch.pmd);
-	free_page((unsigned long)image->arch.pte);
+	free_page((unsigned long)image->arch.pud0);
+	free_page((unsigned long)image->arch.pmd0);
+	free_page((unsigned long)image->arch.pte0);
 }
 
 static int init_transition_pgtable(struct kimage *image, pgd_t *pgd)
@@ -157,7 +157,7 @@ static int init_transition_pgtable(struct kimage *image, pgd_t *pgd)
 		pud = (pud_t *)get_zeroed_page(GFP_KERNEL);
 		if (!pud)
 			goto err;
-		image->arch.pud = pud;
+		image->arch.pud0 = pud;
 		set_pgd(pgd, __pgd(__pa(pud) | _KERNPG_TABLE));
 	}
 	pud = pud_offset(pgd, vaddr);
@@ -165,7 +165,7 @@ static int init_transition_pgtable(struct kimage *image, pgd_t *pgd)
 		pmd = (pmd_t *)get_zeroed_page(GFP_KERNEL);
 		if (!pmd)
 			goto err;
-		image->arch.pmd = pmd;
+		image->arch.pmd0 = pmd;
 		set_pud(pud, __pud(__pa(pmd) | _KERNPG_TABLE));
 	}
 	pmd = pmd_offset(pud, vaddr);
@@ -173,7 +173,7 @@ static int init_transition_pgtable(struct kimage *image, pgd_t *pgd)
 		pte = (pte_t *)get_zeroed_page(GFP_KERNEL);
 		if (!pte)
 			goto err;
-		image->arch.pte = pte;
+		image->arch.pte0 = pte;
 		set_pmd(pmd, __pmd(__pa(pte) | _KERNPG_TABLE));
 	}
 	pte = pte_offset_kernel(pmd, vaddr);
-- 
1.5.6.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 27 18:07:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Sep 2012 18:07: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 1THIUL-0000tS-HK; Thu, 27 Sep 2012 18:07:05 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <SRS0=Sf9V=H2=oracle.com=daniel.kiper@net-space.pl>)
	id 1THIUI-0000rd-91
	for xen-devel@lists.xensource.com; Thu, 27 Sep 2012 18:07:02 +0000
Received: from [85.158.138.51:8405] by server-7.bemta-3.messagelabs.com id
	DC/2C-15765-5C594605; Thu, 27 Sep 2012 18:07:01 +0000
X-Env-Sender: SRS0=Sf9V=H2=oracle.com=daniel.kiper@net-space.pl
X-Msg-Ref: server-14.tower-174.messagelabs.com!1348769218!25906058!10
X-Originating-IP: [89.174.63.77]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31645 invoked from network); 27 Sep 2012 18:07:00 -0000
Received: from router-fw.net-space.pl (HELO router-fw.net-space.pl)
	(89.174.63.77)
	by server-14.tower-174.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 27 Sep 2012 18:07:00 -0000
Received: from dev-00.local.net-space.pl ([192.168.1.5]:54110 "EHLO
	localhost.localdomain" TLS-CIPHER: <none>)
	by router-fw-old.local.net-space.pl with ESMTP id S1623298Ab2I0SGj
	(ORCPT <rfc822;xen-devel@lists.xensource.com>);
	Thu, 27 Sep 2012 20:06:39 +0200
From: Daniel Kiper <daniel.kiper@oracle.com>
To: konrad.wilk@oracle.com, andrew.cooper3@citrix.com,
	jbeulich@suse.com, linux-kernel@vger.kernel.org,
	xen-devel@lists.xensource.com
Date: Thu, 27 Sep 2012 20:06:32 +0200
Message-Id: <1348769198-29580-6-git-send-email-daniel.kiper@oracle.com>
X-Mailer: git-send-email 1.5.6.5
In-Reply-To: <1348769198-29580-5-git-send-email-daniel.kiper@oracle.com>
References: <1348769198-29580-1-git-send-email-daniel.kiper@oracle.com>
	<1348769198-29580-2-git-send-email-daniel.kiper@oracle.com>
	<1348769198-29580-3-git-send-email-daniel.kiper@oracle.com>
	<1348769198-29580-4-git-send-email-daniel.kiper@oracle.com>
	<1348769198-29580-5-git-send-email-daniel.kiper@oracle.com>
X-Bogosity: No, spamicity=0.000000
Cc: Daniel Kiper <daniel.kiper@oracle.com>
Subject: [Xen-devel] [PATCH 05/11] x86/xen: Register resources required by
	kexec-tools
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Register resources required by kexec-tools.

Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
---
 arch/x86/xen/kexec.c |  150 ++++++++++++++++++++++++++++++++++++++++++++++++++
 1 files changed, 150 insertions(+), 0 deletions(-)
 create mode 100644 arch/x86/xen/kexec.c

diff --git a/arch/x86/xen/kexec.c b/arch/x86/xen/kexec.c
new file mode 100644
index 0000000..eb0108b
--- /dev/null
+++ b/arch/x86/xen/kexec.c
@@ -0,0 +1,150 @@
+/*
+ * Copyright (c) 2011 Daniel Kiper
+ * Copyright (c) 2012 Daniel Kiper, Oracle Corporation
+ *
+ * kexec/kdump implementation for Xen was written by Daniel Kiper.
+ * Initial work on it was sponsored by Google under Google Summer
+ * of Code 2011 program and Citrix. Konrad Rzeszutek Wilk from Oracle
+ * was the mentor for this project.
+ *
+ * Some ideas are taken from:
+ *   - native kexec/kdump implementation,
+ *   - kexec/kdump implementation for Xen Linux Kernel Ver. 2.6.18,
+ *   - PV-GRUB.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License along
+ * with this program.  If not, see <http://www.gnu.org/licenses/>.
+ */
+
+#include <linux/errno.h>
+#include <linux/init.h>
+#include <linux/ioport.h>
+#include <linux/kernel.h>
+#include <linux/kexec.h>
+#include <linux/slab.h>
+#include <linux/string.h>
+
+#include <xen/interface/platform.h>
+#include <xen/interface/xen.h>
+#include <xen/xen.h>
+
+#include <asm/xen/hypercall.h>
+
+unsigned long xen_vmcoreinfo_maddr = 0;
+unsigned long xen_vmcoreinfo_max_size = 0;
+
+static int __init xen_init_kexec_resources(void)
+{
+	int rc;
+	static struct resource xen_hypervisor_res = {
+		.name = "Hypervisor code and data",
+		.flags = IORESOURCE_BUSY | IORESOURCE_MEM
+	};
+	struct resource *cpu_res;
+	struct xen_kexec_range xkr;
+	struct xen_platform_op cpuinfo_op;
+	uint32_t cpus, i;
+
+	if (!xen_initial_domain())
+		return 0;
+
+	if (strstr(boot_command_line, "crashkernel="))
+		pr_info("kexec: Ignoring crashkernel option. "
+			"It should be passed to Xen hypervisor.\n");
+
+	/* Register Crash kernel resource. */
+	xkr.range = KEXEC_RANGE_MA_CRASH;
+	rc = HYPERVISOR_kexec_op(KEXEC_CMD_kexec_get_range, &xkr);
+
+	if (rc) {
+		pr_info("kexec: %s: HYPERVISOR_kexec_op(KEXEC_RANGE_MA_CRASH)"
+			": %i\n", __func__, rc);
+		return rc;
+	}
+
+	if (!xkr.size)
+		return 0;
+
+	crashk_res.start = xkr.start;
+	crashk_res.end = xkr.start + xkr.size - 1;
+	insert_resource(&iomem_resource, &crashk_res);
+
+	/* Register Hypervisor code and data resource. */
+	xkr.range = KEXEC_RANGE_MA_XEN;
+	rc = HYPERVISOR_kexec_op(KEXEC_CMD_kexec_get_range, &xkr);
+
+	if (rc) {
+		pr_info("kexec: %s: HYPERVISOR_kexec_op(KEXEC_RANGE_MA_XEN)"
+			": %i\n", __func__, rc);
+		return rc;
+	}
+
+	xen_hypervisor_res.start = xkr.start;
+	xen_hypervisor_res.end = xkr.start + xkr.size - 1;
+	insert_resource(&iomem_resource, &xen_hypervisor_res);
+
+	/* Determine maximum number of physical CPUs. */
+	cpuinfo_op.cmd = XENPF_get_cpuinfo;
+	cpuinfo_op.u.pcpu_info.xen_cpuid = 0;
+	rc = HYPERVISOR_dom0_op(&cpuinfo_op);
+
+	if (rc) {
+		pr_info("kexec: %s: HYPERVISOR_dom0_op(): %i\n", __func__, rc);
+		return rc;
+	}
+
+	cpus = cpuinfo_op.u.pcpu_info.max_present + 1;
+
+	/* Register CPUs Crash note resources. */
+	cpu_res = kcalloc(cpus, sizeof(struct resource), GFP_KERNEL);
+
+	if (!cpu_res) {
+		pr_info("kexec: %s: kcalloc(): %i\n", __func__, -ENOMEM);
+		return -ENOMEM;
+	}
+
+	for (i = 0; i < cpus; ++i) {
+		xkr.range = KEXEC_RANGE_MA_CPU;
+		xkr.nr = i;
+		rc = HYPERVISOR_kexec_op(KEXEC_CMD_kexec_get_range, &xkr);
+
+		if (rc) {
+			pr_info("kexec: %s: cpu: %u: HYPERVISOR_kexec_op"
+				"(KEXEC_RANGE_MA_XEN): %i\n", __func__, i, rc);
+			continue;
+		}
+
+		cpu_res->name = "Crash note";
+		cpu_res->start = xkr.start;
+		cpu_res->end = xkr.start + xkr.size - 1;
+		cpu_res->flags = IORESOURCE_BUSY | IORESOURCE_MEM;
+		insert_resource(&iomem_resource, cpu_res++);
+	}
+
+	/* Get vmcoreinfo address and maximum allowed size. */
+	xkr.range = KEXEC_RANGE_MA_VMCOREINFO;
+	rc = HYPERVISOR_kexec_op(KEXEC_CMD_kexec_get_range, &xkr);
+
+	if (rc) {
+		pr_info("kexec: %s: HYPERVISOR_kexec_op(KEXEC_RANGE_MA_VMCOREINFO)"
+			": %i\n", __func__, rc);
+		return rc;
+	}
+
+	xen_vmcoreinfo_maddr = xkr.start;
+	xen_vmcoreinfo_max_size = xkr.size;
+
+	return 0;
+}
+
+core_initcall(xen_init_kexec_resources);
-- 
1.5.6.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 27 18:07:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Sep 2012 18:07: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 1THIUK-0000su-Og; Thu, 27 Sep 2012 18:07:04 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <SRS0=Sf9V=H2=oracle.com=daniel.kiper@net-space.pl>)
	id 1THIUH-0000rB-9D
	for xen-devel@lists.xensource.com; Thu, 27 Sep 2012 18:07:01 +0000
Received: from [85.158.138.51:42602] by server-15.bemta-3.messagelabs.com id
	24/DD-18313-4C594605; Thu, 27 Sep 2012 18:07:00 +0000
X-Env-Sender: SRS0=Sf9V=H2=oracle.com=daniel.kiper@net-space.pl
X-Msg-Ref: server-14.tower-174.messagelabs.com!1348769218!25906058!4
X-Originating-IP: [89.174.63.77]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31576 invoked from network); 27 Sep 2012 18:06:59 -0000
Received: from router-fw.net-space.pl (HELO router-fw.net-space.pl)
	(89.174.63.77)
	by server-14.tower-174.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 27 Sep 2012 18:06:59 -0000
Received: from dev-00.local.net-space.pl ([192.168.1.5]:54110 "EHLO
	localhost.localdomain" TLS-CIPHER: <none>)
	by router-fw-old.local.net-space.pl with ESMTP id S1623162Ab2I0SGj
	(ORCPT <rfc822;xen-devel@lists.xensource.com>);
	Thu, 27 Sep 2012 20:06:39 +0200
From: Daniel Kiper <daniel.kiper@oracle.com>
To: konrad.wilk@oracle.com, andrew.cooper3@citrix.com,
	jbeulich@suse.com, linux-kernel@vger.kernel.org,
	xen-devel@lists.xensource.com
Date: Thu, 27 Sep 2012 20:06:28 +0200
Message-Id: <1348769198-29580-2-git-send-email-daniel.kiper@oracle.com>
X-Mailer: git-send-email 1.5.6.5
In-Reply-To: <1348769198-29580-1-git-send-email-daniel.kiper@oracle.com>
References: <1348769198-29580-1-git-send-email-daniel.kiper@oracle.com>
X-Bogosity: No, spamicity=0.000030
Cc: Daniel Kiper <daniel.kiper@oracle.com>
Subject: [Xen-devel] [PATCH 01/11] kexec: introduce kexec_ops struct
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Some kexec/kdump implementations (e.g. Xen PVOPS) on different archs could
not use default functions or require some changes in behavior of kexec/kdump
generic code. To cope with that problem kexec_ops struct was introduced.
It allows a developer to replace all or some functions and control some
functionality of kexec/kdump generic code.

Default behavior of kexec/kdump generic code is not changed.

Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
---
 include/linux/kexec.h |   18 +++++++
 kernel/kexec.c        |  125 ++++++++++++++++++++++++++++++++++++-------------
 2 files changed, 111 insertions(+), 32 deletions(-)

diff --git a/include/linux/kexec.h b/include/linux/kexec.h
index 37c5f72..beb08ca 100644
--- a/include/linux/kexec.h
+++ b/include/linux/kexec.h
@@ -165,7 +165,25 @@ struct kimage {
 #endif
 };
 
+struct kexec_ops {
+	bool always_use_normal_alloc;
+	struct page *(*kimage_alloc_pages)(gfp_t gfp_mask,
+						unsigned int order,
+						unsigned long limit);
+	void (*kimage_free_pages)(struct page *page);
+	unsigned long (*page_to_pfn)(struct page *page);
+	struct page *(*pfn_to_page)(unsigned long pfn);
+	unsigned long (*virt_to_phys)(volatile void *address);
+	void *(*phys_to_virt)(unsigned long address);
+	int (*machine_kexec_prepare)(struct kimage *image);
+	int (*machine_kexec_load)(struct kimage *image);
+	void (*machine_kexec_cleanup)(struct kimage *image);
+	void (*machine_kexec_unload)(struct kimage *image);
+	void (*machine_kexec_shutdown)(void);
+	void (*machine_kexec)(struct kimage *image);
+};
 
+extern struct kexec_ops kexec_ops;
 
 /* kexec interface functions */
 extern void machine_kexec(struct kimage *image);
diff --git a/kernel/kexec.c b/kernel/kexec.c
index 0668d58..98556f3 100644
--- a/kernel/kexec.c
+++ b/kernel/kexec.c
@@ -56,6 +56,47 @@ struct resource crashk_res = {
 	.flags = IORESOURCE_BUSY | IORESOURCE_MEM
 };
 
+static struct page *kimage_alloc_pages(gfp_t gfp_mask,
+					unsigned int order,
+					unsigned long limit);
+static void kimage_free_pages(struct page *page);
+
+static unsigned long generic_page_to_pfn(struct page *page)
+{
+	return page_to_pfn(page);
+}
+
+static struct page *generic_pfn_to_page(unsigned long pfn)
+{
+	return pfn_to_page(pfn);
+}
+
+static unsigned long generic_virt_to_phys(volatile void *address)
+{
+	return virt_to_phys(address);
+}
+
+static void *generic_phys_to_virt(unsigned long address)
+{
+	return phys_to_virt(address);
+}
+
+struct kexec_ops kexec_ops = {
+	.always_use_normal_alloc = false,
+	.kimage_alloc_pages = kimage_alloc_pages,
+	.kimage_free_pages = kimage_free_pages,
+	.page_to_pfn = generic_page_to_pfn,
+	.pfn_to_page = generic_pfn_to_page,
+	.virt_to_phys = generic_virt_to_phys,
+	.phys_to_virt = generic_phys_to_virt,
+	.machine_kexec_prepare = machine_kexec_prepare,
+	.machine_kexec_load = NULL,
+	.machine_kexec_cleanup = machine_kexec_cleanup,
+	.machine_kexec_unload = NULL,
+	.machine_kexec_shutdown = machine_shutdown,
+	.machine_kexec = machine_kexec
+};
+
 int kexec_should_crash(struct task_struct *p)
 {
 	if (in_interrupt() || !p->pid || is_global_init(p) || panic_on_oops)
@@ -355,7 +396,9 @@ static int kimage_is_destination_range(struct kimage *image,
 	return 0;
 }
 
-static struct page *kimage_alloc_pages(gfp_t gfp_mask, unsigned int order)
+static struct page *kimage_alloc_pages(gfp_t gfp_mask,
+					unsigned int order,
+					unsigned long limit)
 {
 	struct page *pages;
 
@@ -392,7 +435,7 @@ static void kimage_free_page_list(struct list_head *list)
 
 		page = list_entry(pos, struct page, lru);
 		list_del(&page->lru);
-		kimage_free_pages(page);
+		(*kexec_ops.kimage_free_pages)(page);
 	}
 }
 
@@ -425,10 +468,11 @@ static struct page *kimage_alloc_normal_control_pages(struct kimage *image,
 	do {
 		unsigned long pfn, epfn, addr, eaddr;
 
-		pages = kimage_alloc_pages(GFP_KERNEL, order);
+		pages = (*kexec_ops.kimage_alloc_pages)(GFP_KERNEL, order,
+							KEXEC_CONTROL_MEMORY_LIMIT);
 		if (!pages)
 			break;
-		pfn   = page_to_pfn(pages);
+		pfn   = (*kexec_ops.page_to_pfn)(pages);
 		epfn  = pfn + count;
 		addr  = pfn << PAGE_SHIFT;
 		eaddr = epfn << PAGE_SHIFT;
@@ -515,7 +559,7 @@ static struct page *kimage_alloc_crash_control_pages(struct kimage *image,
 		}
 		/* If I don't overlap any segments I have found my hole! */
 		if (i == image->nr_segments) {
-			pages = pfn_to_page(hole_start >> PAGE_SHIFT);
+			pages = (*kexec_ops.pfn_to_page)(hole_start >> PAGE_SHIFT);
 			break;
 		}
 	}
@@ -532,12 +576,13 @@ struct page *kimage_alloc_control_pages(struct kimage *image,
 	struct page *pages = NULL;
 
 	switch (image->type) {
+	case KEXEC_TYPE_CRASH:
+		if (!kexec_ops.always_use_normal_alloc) {
+			pages = kimage_alloc_crash_control_pages(image, order);
+			break;
+		}
 	case KEXEC_TYPE_DEFAULT:
 		pages = kimage_alloc_normal_control_pages(image, order);
-		break;
-	case KEXEC_TYPE_CRASH:
-		pages = kimage_alloc_crash_control_pages(image, order);
-		break;
 	}
 
 	return pages;
@@ -557,7 +602,7 @@ static int kimage_add_entry(struct kimage *image, kimage_entry_t entry)
 			return -ENOMEM;
 
 		ind_page = page_address(page);
-		*image->entry = virt_to_phys(ind_page) | IND_INDIRECTION;
+		*image->entry = (*kexec_ops.virt_to_phys)(ind_page) | IND_INDIRECTION;
 		image->entry = ind_page;
 		image->last_entry = ind_page +
 				      ((PAGE_SIZE/sizeof(kimage_entry_t)) - 1);
@@ -616,14 +661,14 @@ static void kimage_terminate(struct kimage *image)
 #define for_each_kimage_entry(image, ptr, entry) \
 	for (ptr = &image->head; (entry = *ptr) && !(entry & IND_DONE); \
 		ptr = (entry & IND_INDIRECTION)? \
-			phys_to_virt((entry & PAGE_MASK)): ptr +1)
+			(*kexec_ops.phys_to_virt)((entry & PAGE_MASK)): ptr +1)
 
 static void kimage_free_entry(kimage_entry_t entry)
 {
 	struct page *page;
 
-	page = pfn_to_page(entry >> PAGE_SHIFT);
-	kimage_free_pages(page);
+	page = (*kexec_ops.pfn_to_page)(entry >> PAGE_SHIFT);
+	(*kexec_ops.kimage_free_pages)(page);
 }
 
 static void kimage_free(struct kimage *image)
@@ -653,7 +698,7 @@ static void kimage_free(struct kimage *image)
 		kimage_free_entry(ind);
 
 	/* Handle any machine specific cleanup */
-	machine_kexec_cleanup(image);
+	(*kexec_ops.machine_kexec_cleanup)(image);
 
 	/* Free the kexec control pages... */
 	kimage_free_page_list(&image->control_pages);
@@ -709,7 +754,7 @@ static struct page *kimage_alloc_page(struct kimage *image,
 	 * have a match.
 	 */
 	list_for_each_entry(page, &image->dest_pages, lru) {
-		addr = page_to_pfn(page) << PAGE_SHIFT;
+		addr = (*kexec_ops.page_to_pfn)(page) << PAGE_SHIFT;
 		if (addr == destination) {
 			list_del(&page->lru);
 			return page;
@@ -720,16 +765,17 @@ static struct page *kimage_alloc_page(struct kimage *image,
 		kimage_entry_t *old;
 
 		/* Allocate a page, if we run out of memory give up */
-		page = kimage_alloc_pages(gfp_mask, 0);
+		page = (*kexec_ops.kimage_alloc_pages)(gfp_mask, 0,
+							KEXEC_SOURCE_MEMORY_LIMIT);
 		if (!page)
 			return NULL;
 		/* If the page cannot be used file it away */
-		if (page_to_pfn(page) >
+		if ((*kexec_ops.page_to_pfn)(page) >
 				(KEXEC_SOURCE_MEMORY_LIMIT >> PAGE_SHIFT)) {
 			list_add(&page->lru, &image->unuseable_pages);
 			continue;
 		}
-		addr = page_to_pfn(page) << PAGE_SHIFT;
+		addr = (*kexec_ops.page_to_pfn)(page) << PAGE_SHIFT;
 
 		/* If it is the destination page we want use it */
 		if (addr == destination)
@@ -752,7 +798,7 @@ static struct page *kimage_alloc_page(struct kimage *image,
 			struct page *old_page;
 
 			old_addr = *old & PAGE_MASK;
-			old_page = pfn_to_page(old_addr >> PAGE_SHIFT);
+			old_page = (*kexec_ops.pfn_to_page)(old_addr >> PAGE_SHIFT);
 			copy_highpage(page, old_page);
 			*old = addr | (*old & ~PAGE_MASK);
 
@@ -762,7 +808,7 @@ static struct page *kimage_alloc_page(struct kimage *image,
 			 */
 			if (!(gfp_mask & __GFP_HIGHMEM) &&
 			    PageHighMem(old_page)) {
-				kimage_free_pages(old_page);
+				(*kexec_ops.kimage_free_pages)(old_page);
 				continue;
 			}
 			addr = old_addr;
@@ -808,7 +854,7 @@ static int kimage_load_normal_segment(struct kimage *image,
 			result  = -ENOMEM;
 			goto out;
 		}
-		result = kimage_add_page(image, page_to_pfn(page)
+		result = kimage_add_page(image, (*kexec_ops.page_to_pfn)(page)
 								<< PAGE_SHIFT);
 		if (result < 0)
 			goto out;
@@ -862,7 +908,7 @@ static int kimage_load_crash_segment(struct kimage *image,
 		char *ptr;
 		size_t uchunk, mchunk;
 
-		page = pfn_to_page(maddr >> PAGE_SHIFT);
+		page = (*kexec_ops.pfn_to_page)(maddr >> PAGE_SHIFT);
 		if (!page) {
 			result  = -ENOMEM;
 			goto out;
@@ -901,12 +947,13 @@ static int kimage_load_segment(struct kimage *image,
 	int result = -ENOMEM;
 
 	switch (image->type) {
+	case KEXEC_TYPE_CRASH:
+		if (!kexec_ops.always_use_normal_alloc) {
+			result = kimage_load_crash_segment(image, segment);
+			break;
+		}
 	case KEXEC_TYPE_DEFAULT:
 		result = kimage_load_normal_segment(image, segment);
-		break;
-	case KEXEC_TYPE_CRASH:
-		result = kimage_load_crash_segment(image, segment);
-		break;
 	}
 
 	return result;
@@ -994,6 +1041,8 @@ SYSCALL_DEFINE4(kexec_load, unsigned long, entry, unsigned long, nr_segments,
 			/* Free any current crash dump kernel before
 			 * we corrupt it.
 			 */
+			if (kexec_ops.machine_kexec_unload)
+				(*kexec_ops.machine_kexec_unload)(image);
 			kimage_free(xchg(&kexec_crash_image, NULL));
 			result = kimage_crash_alloc(&image, entry,
 						     nr_segments, segments);
@@ -1004,7 +1053,7 @@ SYSCALL_DEFINE4(kexec_load, unsigned long, entry, unsigned long, nr_segments,
 
 		if (flags & KEXEC_PRESERVE_CONTEXT)
 			image->preserve_context = 1;
-		result = machine_kexec_prepare(image);
+		result = (*kexec_ops.machine_kexec_prepare)(image);
 		if (result)
 			goto out;
 
@@ -1017,11 +1066,23 @@ SYSCALL_DEFINE4(kexec_load, unsigned long, entry, unsigned long, nr_segments,
 		if (flags & KEXEC_ON_CRASH)
 			crash_unmap_reserved_pages();
 	}
+
+	if (kexec_ops.machine_kexec_load) {
+		result = (*kexec_ops.machine_kexec_load)(image);
+
+		if (result)
+			goto out;
+	}
+
 	/* Install the new kernel, and  Uninstall the old */
 	image = xchg(dest_image, image);
 
 out:
 	mutex_unlock(&kexec_mutex);
+
+	if (kexec_ops.machine_kexec_unload)
+		(*kexec_ops.machine_kexec_unload)(image);
+
 	kimage_free(image);
 
 	return result;
@@ -1095,7 +1156,7 @@ void crash_kexec(struct pt_regs *regs)
 			crash_setup_regs(&fixed_regs, regs);
 			crash_save_vmcoreinfo();
 			machine_crash_shutdown(&fixed_regs);
-			machine_kexec(kexec_crash_image);
+			(*kexec_ops.machine_kexec)(kexec_crash_image);
 		}
 		mutex_unlock(&kexec_mutex);
 	}
@@ -1117,8 +1178,8 @@ void __weak crash_free_reserved_phys_range(unsigned long begin,
 	unsigned long addr;
 
 	for (addr = begin; addr < end; addr += PAGE_SIZE) {
-		ClearPageReserved(pfn_to_page(addr >> PAGE_SHIFT));
-		init_page_count(pfn_to_page(addr >> PAGE_SHIFT));
+		ClearPageReserved((*kexec_ops.pfn_to_page)(addr >> PAGE_SHIFT));
+		init_page_count((*kexec_ops.pfn_to_page)(addr >> PAGE_SHIFT));
 		free_page((unsigned long)__va(addr));
 		totalram_pages++;
 	}
@@ -1572,10 +1633,10 @@ int kernel_kexec(void)
 	{
 		kernel_restart_prepare(NULL);
 		printk(KERN_EMERG "Starting new kernel\n");
-		machine_shutdown();
+		(*kexec_ops.machine_kexec_shutdown)();
 	}
 
-	machine_kexec(kexec_image);
+	(*kexec_ops.machine_kexec)(kexec_image);
 
 #ifdef CONFIG_KEXEC_JUMP
 	if (kexec_image->preserve_context) {
-- 
1.5.6.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 27 18:07:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Sep 2012 18:07: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 1THIUJ-0000sL-HC; Thu, 27 Sep 2012 18:07:03 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <SRS0=Sf9V=H2=oracle.com=daniel.kiper@net-space.pl>)
	id 1THIUG-0000qz-VM
	for xen-devel@lists.xensource.com; Thu, 27 Sep 2012 18:07:01 +0000
Received: from [85.158.138.51:42609] by server-3.bemta-3.messagelabs.com id
	E7/A2-25962-4C594605; Thu, 27 Sep 2012 18:07:00 +0000
X-Env-Sender: SRS0=Sf9V=H2=oracle.com=daniel.kiper@net-space.pl
X-Msg-Ref: server-14.tower-174.messagelabs.com!1348769218!25906058!8
X-Originating-IP: [89.174.63.77]
X-SpamReason: No, hits=0.0 required=7.0 tests=UPPERCASE_25_50
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31616 invoked from network); 27 Sep 2012 18:07:00 -0000
Received: from router-fw.net-space.pl (HELO router-fw.net-space.pl)
	(89.174.63.77)
	by server-14.tower-174.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 27 Sep 2012 18:07:00 -0000
Received: from dev-00.local.net-space.pl ([192.168.1.5]:54110 "EHLO
	localhost.localdomain" TLS-CIPHER: <none>)
	by router-fw-old.local.net-space.pl with ESMTP id S1623303Ab2I0SGj
	(ORCPT <rfc822;xen-devel@lists.xensource.com>);
	Thu, 27 Sep 2012 20:06:39 +0200
From: Daniel Kiper <daniel.kiper@oracle.com>
To: konrad.wilk@oracle.com, andrew.cooper3@citrix.com,
	jbeulich@suse.com, linux-kernel@vger.kernel.org,
	xen-devel@lists.xensource.com
Date: Thu, 27 Sep 2012 20:06:35 +0200
Message-Id: <1348769198-29580-9-git-send-email-daniel.kiper@oracle.com>
X-Mailer: git-send-email 1.5.6.5
In-Reply-To: <1348769198-29580-8-git-send-email-daniel.kiper@oracle.com>
References: <1348769198-29580-1-git-send-email-daniel.kiper@oracle.com>
	<1348769198-29580-2-git-send-email-daniel.kiper@oracle.com>
	<1348769198-29580-3-git-send-email-daniel.kiper@oracle.com>
	<1348769198-29580-4-git-send-email-daniel.kiper@oracle.com>
	<1348769198-29580-5-git-send-email-daniel.kiper@oracle.com>
	<1348769198-29580-6-git-send-email-daniel.kiper@oracle.com>
	<1348769198-29580-7-git-send-email-daniel.kiper@oracle.com>
	<1348769198-29580-8-git-send-email-daniel.kiper@oracle.com>
X-Bogosity: No, spamicity=0.414951
Cc: Daniel Kiper <daniel.kiper@oracle.com>
Subject: [Xen-devel] [PATCH 08/11] x86/xen: Add kexec/kdump makefile rules
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 kexec/kdump makefile rules.

Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
---
 arch/x86/xen/Makefile |    3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/arch/x86/xen/Makefile b/arch/x86/xen/Makefile
index 96ab2c0..7a5db44 100644
--- a/arch/x86/xen/Makefile
+++ b/arch/x86/xen/Makefile
@@ -22,3 +22,6 @@ obj-$(CONFIG_PARAVIRT_SPINLOCKS)+= spinlock.o
 obj-$(CONFIG_XEN_DEBUG_FS)	+= debugfs.o
 obj-$(CONFIG_XEN_DOM0)		+= apic.o vga.o
 obj-$(CONFIG_SWIOTLB_XEN)	+= pci-swiotlb-xen.o
+obj-$(CONFIG_KEXEC)		+= kexec.o
+obj-$(CONFIG_KEXEC)		+= machine_kexec_$(BITS).o
+obj-$(CONFIG_KEXEC)		+= relocate_kernel_$(BITS).o
-- 
1.5.6.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 27 18:07:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Sep 2012 18:07: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 1THIUH-0000rS-Jl; Thu, 27 Sep 2012 18:07:01 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <SRS0=Sf9V=H2=oracle.com=daniel.kiper@net-space.pl>)
	id 1THIUG-0000qz-3Z
	for xen-devel@lists.xensource.com; Thu, 27 Sep 2012 18:07:00 +0000
Received: from [85.158.138.51:42568] by server-3.bemta-3.messagelabs.com id
	C3/A2-25962-3C594605; Thu, 27 Sep 2012 18:06:59 +0000
X-Env-Sender: SRS0=Sf9V=H2=oracle.com=daniel.kiper@net-space.pl
X-Msg-Ref: server-14.tower-174.messagelabs.com!1348769218!25906058!1
X-Originating-IP: [89.174.63.77]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31561 invoked from network); 27 Sep 2012 18:06:58 -0000
Received: from router-fw.net-space.pl (HELO router-fw.net-space.pl)
	(89.174.63.77)
	by server-14.tower-174.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 27 Sep 2012 18:06:58 -0000
Received: from dev-00.local.net-space.pl ([192.168.1.5]:54110 "EHLO
	localhost.localdomain" TLS-CIPHER: <none>)
	by router-fw-old.local.net-space.pl with ESMTP id S1623110Ab2I0SGi
	(ORCPT <rfc822;xen-devel@lists.xensource.com>);
	Thu, 27 Sep 2012 20:06:38 +0200
From: Daniel Kiper <daniel.kiper@oracle.com>
To: konrad.wilk@oracle.com, andrew.cooper3@citrix.com,
	jbeulich@suse.com, linux-kernel@vger.kernel.org,
	xen-devel@lists.xensource.com
Date: Thu, 27 Sep 2012 20:06:27 +0200
Message-Id: <1348769198-29580-1-git-send-email-daniel.kiper@oracle.com>
X-Mailer: git-send-email 1.5.6.5
X-Bogosity: No, spamicity=0.074274
Subject: [Xen-devel] [PATCH 00/11] xen: Initial kexec/kdump 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>
MIME-Version: 1.0
Content-Type: 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 set of patches contains initial kexec/kdump implementation for Xen.
Currently only dom0 is supported, however, almost all infrustructure
required for domU support is ready.

Daniel

 arch/x86/include/asm/kexec.h         |   10 +-
 arch/x86/include/asm/xen/hypercall.h |    6 +
 arch/x86/include/asm/xen/kexec.h     |   83 +++++++++
 arch/x86/kernel/machine_kexec_64.c   |   12 +-
 arch/x86/kernel/vmlinux.lds.S        |    7 +-
 arch/x86/xen/Makefile                |    3 +
 arch/x86/xen/enlighten.c             |   12 ++
 arch/x86/xen/kexec.c                 |  150 ++++++++++++++++
 arch/x86/xen/machine_kexec_32.c      |  245 ++++++++++++++++++++++++++
 arch/x86/xen/machine_kexec_64.c      |  301 +++++++++++++++++++++++++++++++
 arch/x86/xen/relocate_kernel_32.S    |  323 ++++++++++++++++++++++++++++++++++
 arch/x86/xen/relocate_kernel_64.S    |  309 ++++++++++++++++++++++++++++++++
 drivers/xen/sys-hypervisor.c         |   42 +++++-
 include/linux/kexec.h                |   18 ++
 include/xen/interface/xen.h          |   33 ++++
 kernel/kexec.c                       |  125 ++++++++++----
 16 files changed, 1636 insertions(+), 43 deletions(-)

Daniel Kiper (11):
      kexec: introduce kexec_ops struct
      x86/kexec: Add extra pointers to transition page table PGD, PUD, PMD and PTE
      xen: Introduce architecture independent data for kexec/kdump
      x86/xen: Introduce architecture dependent data for kexec/kdump
      x86/xen: Register resources required by kexec-tools
      x86/xen: Add i386 kexec/kdump implementation
      x86/xen: Add x86_64 kexec/kdump implementation
      x86/xen: Add kexec/kdump makefile rules
      x86/xen/enlighten: Add init and crash kexec/kdump hooks
      drivers/xen: Export vmcoreinfo through sysfs
      x86: Add Xen kexec control code size check to linker script

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 27 18:07:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Sep 2012 18:07: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 1THIUK-0000su-Og; Thu, 27 Sep 2012 18:07:04 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <SRS0=Sf9V=H2=oracle.com=daniel.kiper@net-space.pl>)
	id 1THIUH-0000rB-9D
	for xen-devel@lists.xensource.com; Thu, 27 Sep 2012 18:07:01 +0000
Received: from [85.158.138.51:42602] by server-15.bemta-3.messagelabs.com id
	24/DD-18313-4C594605; Thu, 27 Sep 2012 18:07:00 +0000
X-Env-Sender: SRS0=Sf9V=H2=oracle.com=daniel.kiper@net-space.pl
X-Msg-Ref: server-14.tower-174.messagelabs.com!1348769218!25906058!4
X-Originating-IP: [89.174.63.77]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31576 invoked from network); 27 Sep 2012 18:06:59 -0000
Received: from router-fw.net-space.pl (HELO router-fw.net-space.pl)
	(89.174.63.77)
	by server-14.tower-174.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 27 Sep 2012 18:06:59 -0000
Received: from dev-00.local.net-space.pl ([192.168.1.5]:54110 "EHLO
	localhost.localdomain" TLS-CIPHER: <none>)
	by router-fw-old.local.net-space.pl with ESMTP id S1623162Ab2I0SGj
	(ORCPT <rfc822;xen-devel@lists.xensource.com>);
	Thu, 27 Sep 2012 20:06:39 +0200
From: Daniel Kiper <daniel.kiper@oracle.com>
To: konrad.wilk@oracle.com, andrew.cooper3@citrix.com,
	jbeulich@suse.com, linux-kernel@vger.kernel.org,
	xen-devel@lists.xensource.com
Date: Thu, 27 Sep 2012 20:06:28 +0200
Message-Id: <1348769198-29580-2-git-send-email-daniel.kiper@oracle.com>
X-Mailer: git-send-email 1.5.6.5
In-Reply-To: <1348769198-29580-1-git-send-email-daniel.kiper@oracle.com>
References: <1348769198-29580-1-git-send-email-daniel.kiper@oracle.com>
X-Bogosity: No, spamicity=0.000030
Cc: Daniel Kiper <daniel.kiper@oracle.com>
Subject: [Xen-devel] [PATCH 01/11] kexec: introduce kexec_ops struct
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Some kexec/kdump implementations (e.g. Xen PVOPS) on different archs could
not use default functions or require some changes in behavior of kexec/kdump
generic code. To cope with that problem kexec_ops struct was introduced.
It allows a developer to replace all or some functions and control some
functionality of kexec/kdump generic code.

Default behavior of kexec/kdump generic code is not changed.

Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
---
 include/linux/kexec.h |   18 +++++++
 kernel/kexec.c        |  125 ++++++++++++++++++++++++++++++++++++-------------
 2 files changed, 111 insertions(+), 32 deletions(-)

diff --git a/include/linux/kexec.h b/include/linux/kexec.h
index 37c5f72..beb08ca 100644
--- a/include/linux/kexec.h
+++ b/include/linux/kexec.h
@@ -165,7 +165,25 @@ struct kimage {
 #endif
 };
 
+struct kexec_ops {
+	bool always_use_normal_alloc;
+	struct page *(*kimage_alloc_pages)(gfp_t gfp_mask,
+						unsigned int order,
+						unsigned long limit);
+	void (*kimage_free_pages)(struct page *page);
+	unsigned long (*page_to_pfn)(struct page *page);
+	struct page *(*pfn_to_page)(unsigned long pfn);
+	unsigned long (*virt_to_phys)(volatile void *address);
+	void *(*phys_to_virt)(unsigned long address);
+	int (*machine_kexec_prepare)(struct kimage *image);
+	int (*machine_kexec_load)(struct kimage *image);
+	void (*machine_kexec_cleanup)(struct kimage *image);
+	void (*machine_kexec_unload)(struct kimage *image);
+	void (*machine_kexec_shutdown)(void);
+	void (*machine_kexec)(struct kimage *image);
+};
 
+extern struct kexec_ops kexec_ops;
 
 /* kexec interface functions */
 extern void machine_kexec(struct kimage *image);
diff --git a/kernel/kexec.c b/kernel/kexec.c
index 0668d58..98556f3 100644
--- a/kernel/kexec.c
+++ b/kernel/kexec.c
@@ -56,6 +56,47 @@ struct resource crashk_res = {
 	.flags = IORESOURCE_BUSY | IORESOURCE_MEM
 };
 
+static struct page *kimage_alloc_pages(gfp_t gfp_mask,
+					unsigned int order,
+					unsigned long limit);
+static void kimage_free_pages(struct page *page);
+
+static unsigned long generic_page_to_pfn(struct page *page)
+{
+	return page_to_pfn(page);
+}
+
+static struct page *generic_pfn_to_page(unsigned long pfn)
+{
+	return pfn_to_page(pfn);
+}
+
+static unsigned long generic_virt_to_phys(volatile void *address)
+{
+	return virt_to_phys(address);
+}
+
+static void *generic_phys_to_virt(unsigned long address)
+{
+	return phys_to_virt(address);
+}
+
+struct kexec_ops kexec_ops = {
+	.always_use_normal_alloc = false,
+	.kimage_alloc_pages = kimage_alloc_pages,
+	.kimage_free_pages = kimage_free_pages,
+	.page_to_pfn = generic_page_to_pfn,
+	.pfn_to_page = generic_pfn_to_page,
+	.virt_to_phys = generic_virt_to_phys,
+	.phys_to_virt = generic_phys_to_virt,
+	.machine_kexec_prepare = machine_kexec_prepare,
+	.machine_kexec_load = NULL,
+	.machine_kexec_cleanup = machine_kexec_cleanup,
+	.machine_kexec_unload = NULL,
+	.machine_kexec_shutdown = machine_shutdown,
+	.machine_kexec = machine_kexec
+};
+
 int kexec_should_crash(struct task_struct *p)
 {
 	if (in_interrupt() || !p->pid || is_global_init(p) || panic_on_oops)
@@ -355,7 +396,9 @@ static int kimage_is_destination_range(struct kimage *image,
 	return 0;
 }
 
-static struct page *kimage_alloc_pages(gfp_t gfp_mask, unsigned int order)
+static struct page *kimage_alloc_pages(gfp_t gfp_mask,
+					unsigned int order,
+					unsigned long limit)
 {
 	struct page *pages;
 
@@ -392,7 +435,7 @@ static void kimage_free_page_list(struct list_head *list)
 
 		page = list_entry(pos, struct page, lru);
 		list_del(&page->lru);
-		kimage_free_pages(page);
+		(*kexec_ops.kimage_free_pages)(page);
 	}
 }
 
@@ -425,10 +468,11 @@ static struct page *kimage_alloc_normal_control_pages(struct kimage *image,
 	do {
 		unsigned long pfn, epfn, addr, eaddr;
 
-		pages = kimage_alloc_pages(GFP_KERNEL, order);
+		pages = (*kexec_ops.kimage_alloc_pages)(GFP_KERNEL, order,
+							KEXEC_CONTROL_MEMORY_LIMIT);
 		if (!pages)
 			break;
-		pfn   = page_to_pfn(pages);
+		pfn   = (*kexec_ops.page_to_pfn)(pages);
 		epfn  = pfn + count;
 		addr  = pfn << PAGE_SHIFT;
 		eaddr = epfn << PAGE_SHIFT;
@@ -515,7 +559,7 @@ static struct page *kimage_alloc_crash_control_pages(struct kimage *image,
 		}
 		/* If I don't overlap any segments I have found my hole! */
 		if (i == image->nr_segments) {
-			pages = pfn_to_page(hole_start >> PAGE_SHIFT);
+			pages = (*kexec_ops.pfn_to_page)(hole_start >> PAGE_SHIFT);
 			break;
 		}
 	}
@@ -532,12 +576,13 @@ struct page *kimage_alloc_control_pages(struct kimage *image,
 	struct page *pages = NULL;
 
 	switch (image->type) {
+	case KEXEC_TYPE_CRASH:
+		if (!kexec_ops.always_use_normal_alloc) {
+			pages = kimage_alloc_crash_control_pages(image, order);
+			break;
+		}
 	case KEXEC_TYPE_DEFAULT:
 		pages = kimage_alloc_normal_control_pages(image, order);
-		break;
-	case KEXEC_TYPE_CRASH:
-		pages = kimage_alloc_crash_control_pages(image, order);
-		break;
 	}
 
 	return pages;
@@ -557,7 +602,7 @@ static int kimage_add_entry(struct kimage *image, kimage_entry_t entry)
 			return -ENOMEM;
 
 		ind_page = page_address(page);
-		*image->entry = virt_to_phys(ind_page) | IND_INDIRECTION;
+		*image->entry = (*kexec_ops.virt_to_phys)(ind_page) | IND_INDIRECTION;
 		image->entry = ind_page;
 		image->last_entry = ind_page +
 				      ((PAGE_SIZE/sizeof(kimage_entry_t)) - 1);
@@ -616,14 +661,14 @@ static void kimage_terminate(struct kimage *image)
 #define for_each_kimage_entry(image, ptr, entry) \
 	for (ptr = &image->head; (entry = *ptr) && !(entry & IND_DONE); \
 		ptr = (entry & IND_INDIRECTION)? \
-			phys_to_virt((entry & PAGE_MASK)): ptr +1)
+			(*kexec_ops.phys_to_virt)((entry & PAGE_MASK)): ptr +1)
 
 static void kimage_free_entry(kimage_entry_t entry)
 {
 	struct page *page;
 
-	page = pfn_to_page(entry >> PAGE_SHIFT);
-	kimage_free_pages(page);
+	page = (*kexec_ops.pfn_to_page)(entry >> PAGE_SHIFT);
+	(*kexec_ops.kimage_free_pages)(page);
 }
 
 static void kimage_free(struct kimage *image)
@@ -653,7 +698,7 @@ static void kimage_free(struct kimage *image)
 		kimage_free_entry(ind);
 
 	/* Handle any machine specific cleanup */
-	machine_kexec_cleanup(image);
+	(*kexec_ops.machine_kexec_cleanup)(image);
 
 	/* Free the kexec control pages... */
 	kimage_free_page_list(&image->control_pages);
@@ -709,7 +754,7 @@ static struct page *kimage_alloc_page(struct kimage *image,
 	 * have a match.
 	 */
 	list_for_each_entry(page, &image->dest_pages, lru) {
-		addr = page_to_pfn(page) << PAGE_SHIFT;
+		addr = (*kexec_ops.page_to_pfn)(page) << PAGE_SHIFT;
 		if (addr == destination) {
 			list_del(&page->lru);
 			return page;
@@ -720,16 +765,17 @@ static struct page *kimage_alloc_page(struct kimage *image,
 		kimage_entry_t *old;
 
 		/* Allocate a page, if we run out of memory give up */
-		page = kimage_alloc_pages(gfp_mask, 0);
+		page = (*kexec_ops.kimage_alloc_pages)(gfp_mask, 0,
+							KEXEC_SOURCE_MEMORY_LIMIT);
 		if (!page)
 			return NULL;
 		/* If the page cannot be used file it away */
-		if (page_to_pfn(page) >
+		if ((*kexec_ops.page_to_pfn)(page) >
 				(KEXEC_SOURCE_MEMORY_LIMIT >> PAGE_SHIFT)) {
 			list_add(&page->lru, &image->unuseable_pages);
 			continue;
 		}
-		addr = page_to_pfn(page) << PAGE_SHIFT;
+		addr = (*kexec_ops.page_to_pfn)(page) << PAGE_SHIFT;
 
 		/* If it is the destination page we want use it */
 		if (addr == destination)
@@ -752,7 +798,7 @@ static struct page *kimage_alloc_page(struct kimage *image,
 			struct page *old_page;
 
 			old_addr = *old & PAGE_MASK;
-			old_page = pfn_to_page(old_addr >> PAGE_SHIFT);
+			old_page = (*kexec_ops.pfn_to_page)(old_addr >> PAGE_SHIFT);
 			copy_highpage(page, old_page);
 			*old = addr | (*old & ~PAGE_MASK);
 
@@ -762,7 +808,7 @@ static struct page *kimage_alloc_page(struct kimage *image,
 			 */
 			if (!(gfp_mask & __GFP_HIGHMEM) &&
 			    PageHighMem(old_page)) {
-				kimage_free_pages(old_page);
+				(*kexec_ops.kimage_free_pages)(old_page);
 				continue;
 			}
 			addr = old_addr;
@@ -808,7 +854,7 @@ static int kimage_load_normal_segment(struct kimage *image,
 			result  = -ENOMEM;
 			goto out;
 		}
-		result = kimage_add_page(image, page_to_pfn(page)
+		result = kimage_add_page(image, (*kexec_ops.page_to_pfn)(page)
 								<< PAGE_SHIFT);
 		if (result < 0)
 			goto out;
@@ -862,7 +908,7 @@ static int kimage_load_crash_segment(struct kimage *image,
 		char *ptr;
 		size_t uchunk, mchunk;
 
-		page = pfn_to_page(maddr >> PAGE_SHIFT);
+		page = (*kexec_ops.pfn_to_page)(maddr >> PAGE_SHIFT);
 		if (!page) {
 			result  = -ENOMEM;
 			goto out;
@@ -901,12 +947,13 @@ static int kimage_load_segment(struct kimage *image,
 	int result = -ENOMEM;
 
 	switch (image->type) {
+	case KEXEC_TYPE_CRASH:
+		if (!kexec_ops.always_use_normal_alloc) {
+			result = kimage_load_crash_segment(image, segment);
+			break;
+		}
 	case KEXEC_TYPE_DEFAULT:
 		result = kimage_load_normal_segment(image, segment);
-		break;
-	case KEXEC_TYPE_CRASH:
-		result = kimage_load_crash_segment(image, segment);
-		break;
 	}
 
 	return result;
@@ -994,6 +1041,8 @@ SYSCALL_DEFINE4(kexec_load, unsigned long, entry, unsigned long, nr_segments,
 			/* Free any current crash dump kernel before
 			 * we corrupt it.
 			 */
+			if (kexec_ops.machine_kexec_unload)
+				(*kexec_ops.machine_kexec_unload)(image);
 			kimage_free(xchg(&kexec_crash_image, NULL));
 			result = kimage_crash_alloc(&image, entry,
 						     nr_segments, segments);
@@ -1004,7 +1053,7 @@ SYSCALL_DEFINE4(kexec_load, unsigned long, entry, unsigned long, nr_segments,
 
 		if (flags & KEXEC_PRESERVE_CONTEXT)
 			image->preserve_context = 1;
-		result = machine_kexec_prepare(image);
+		result = (*kexec_ops.machine_kexec_prepare)(image);
 		if (result)
 			goto out;
 
@@ -1017,11 +1066,23 @@ SYSCALL_DEFINE4(kexec_load, unsigned long, entry, unsigned long, nr_segments,
 		if (flags & KEXEC_ON_CRASH)
 			crash_unmap_reserved_pages();
 	}
+
+	if (kexec_ops.machine_kexec_load) {
+		result = (*kexec_ops.machine_kexec_load)(image);
+
+		if (result)
+			goto out;
+	}
+
 	/* Install the new kernel, and  Uninstall the old */
 	image = xchg(dest_image, image);
 
 out:
 	mutex_unlock(&kexec_mutex);
+
+	if (kexec_ops.machine_kexec_unload)
+		(*kexec_ops.machine_kexec_unload)(image);
+
 	kimage_free(image);
 
 	return result;
@@ -1095,7 +1156,7 @@ void crash_kexec(struct pt_regs *regs)
 			crash_setup_regs(&fixed_regs, regs);
 			crash_save_vmcoreinfo();
 			machine_crash_shutdown(&fixed_regs);
-			machine_kexec(kexec_crash_image);
+			(*kexec_ops.machine_kexec)(kexec_crash_image);
 		}
 		mutex_unlock(&kexec_mutex);
 	}
@@ -1117,8 +1178,8 @@ void __weak crash_free_reserved_phys_range(unsigned long begin,
 	unsigned long addr;
 
 	for (addr = begin; addr < end; addr += PAGE_SIZE) {
-		ClearPageReserved(pfn_to_page(addr >> PAGE_SHIFT));
-		init_page_count(pfn_to_page(addr >> PAGE_SHIFT));
+		ClearPageReserved((*kexec_ops.pfn_to_page)(addr >> PAGE_SHIFT));
+		init_page_count((*kexec_ops.pfn_to_page)(addr >> PAGE_SHIFT));
 		free_page((unsigned long)__va(addr));
 		totalram_pages++;
 	}
@@ -1572,10 +1633,10 @@ int kernel_kexec(void)
 	{
 		kernel_restart_prepare(NULL);
 		printk(KERN_EMERG "Starting new kernel\n");
-		machine_shutdown();
+		(*kexec_ops.machine_kexec_shutdown)();
 	}
 
-	machine_kexec(kexec_image);
+	(*kexec_ops.machine_kexec)(kexec_image);
 
 #ifdef CONFIG_KEXEC_JUMP
 	if (kexec_image->preserve_context) {
-- 
1.5.6.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 27 18:18:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Sep 2012 18:18:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1THIeq-0002h7-5z; Thu, 27 Sep 2012 18:17: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 1THIen-0002h2-RX
	for xen-devel@lists.xensource.com; Thu, 27 Sep 2012 18:17:54 +0000
Received: from [85.158.137.99:42129] by server-11.bemta-3.messagelabs.com id
	E5/09-21460-15894605; Thu, 27 Sep 2012 18:17:53 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-217.messagelabs.com!1348769872!17035975!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTE5OTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3449 invoked from network); 27 Sep 2012 18:17:52 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Sep 2012 18:17:52 -0000
X-IronPort-AV: E=Sophos;i="4.80,496,1344211200"; d="scan'208";a="14814009"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Sep 2012 18:17: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.279.1; Thu, 27 Sep 2012 19:17: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 1THIek-00014u-Ru;
	Thu, 27 Sep 2012 18:17:50 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1THIek-0003zf-I1;
	Thu, 27 Sep 2012 19:17:50 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-13898-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 27 Sep 2012 19:17:50 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13898: 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 13898 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13898/

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-pv            3 host-install(3)         broken REGR. vs. 13825

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore            fail   like 13825
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail like 13823
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail like 13825

Tests which did not succeed, but are not blocking:
 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-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  6bf8b882df8f
baseline version:
 xen                  d364becfb083

------------------------------------------------------------
People who touched revisions under test:
  Bastian Blank <waldi@debian.org>
  Ben Guthro <ben@guthro.net>
  Christoph Egger <Christoph.Egger@amd.com>
  Christoph Egger <Christoph.Egger@amd.com> (on just this change)
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Keir Fraser <keir@xen.org>
  Liu, Jinsong <jinsong.liu@intel.com>
  Olaf Hering <olaf@aepfle.de>
------------------------------------------------------------

jobs:
 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-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-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           broken  
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-amd64-amd64-xl-win                                      fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

(No revision log; it would be 505 lines long.)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 27 18:18:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Sep 2012 18:18:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1THIeq-0002h7-5z; Thu, 27 Sep 2012 18:17: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 1THIen-0002h2-RX
	for xen-devel@lists.xensource.com; Thu, 27 Sep 2012 18:17:54 +0000
Received: from [85.158.137.99:42129] by server-11.bemta-3.messagelabs.com id
	E5/09-21460-15894605; Thu, 27 Sep 2012 18:17:53 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-217.messagelabs.com!1348769872!17035975!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTE5OTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3449 invoked from network); 27 Sep 2012 18:17:52 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Sep 2012 18:17:52 -0000
X-IronPort-AV: E=Sophos;i="4.80,496,1344211200"; d="scan'208";a="14814009"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Sep 2012 18:17: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.279.1; Thu, 27 Sep 2012 19:17: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 1THIek-00014u-Ru;
	Thu, 27 Sep 2012 18:17:50 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1THIek-0003zf-I1;
	Thu, 27 Sep 2012 19:17:50 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-13898-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 27 Sep 2012 19:17:50 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13898: 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 13898 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13898/

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-pv            3 host-install(3)         broken REGR. vs. 13825

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore            fail   like 13825
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail like 13823
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail like 13825

Tests which did not succeed, but are not blocking:
 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-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  6bf8b882df8f
baseline version:
 xen                  d364becfb083

------------------------------------------------------------
People who touched revisions under test:
  Bastian Blank <waldi@debian.org>
  Ben Guthro <ben@guthro.net>
  Christoph Egger <Christoph.Egger@amd.com>
  Christoph Egger <Christoph.Egger@amd.com> (on just this change)
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Keir Fraser <keir@xen.org>
  Liu, Jinsong <jinsong.liu@intel.com>
  Olaf Hering <olaf@aepfle.de>
------------------------------------------------------------

jobs:
 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-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-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           broken  
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-amd64-amd64-xl-win                                      fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

(No revision log; it would be 505 lines long.)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 27 18:42:33 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Sep 2012 18: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 1THJ2J-0003H6-5h; Thu, 27 Sep 2012 18:42:11 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <singapore.mr.teo.en.ming@gmail.com>)
	id 1THJ2H-0003Gj-KC
	for xen-devel@lists.xen.org; Thu, 27 Sep 2012 18:42:09 +0000
Received: from [85.158.139.211:38998] by server-3.bemta-5.messagelabs.com id
	93/14-16108-00E94605; Thu, 27 Sep 2012 18:42:08 +0000
X-Env-Sender: singapore.mr.teo.en.ming@gmail.com
X-Msg-Ref: server-2.tower-206.messagelabs.com!1348771326!20213955!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-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22255 invoked from network); 27 Sep 2012 18:42:08 -0000
Received: from mail-pb0-f45.google.com (HELO mail-pb0-f45.google.com)
	(209.85.160.45)
	by server-2.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Sep 2012 18:42:08 -0000
Received: by pbbrp2 with SMTP id rp2so4145194pbb.32
	for <multiple recipients>; Thu, 27 Sep 2012 11:42:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=message-id:disposition-notification-to:date:from:user-agent
	:mime-version:to:subject:content-type:content-transfer-encoding;
	bh=9I0JTUx4ComYhqA6PgNg31tqzKqPiVTp1Z4jVK7BkRA=;
	b=hIhmmSQV/2WgcmNPWwt3wZaF43r4qBzSKGkLKauCyVyk0JTa7Y/oPBev1OEoOSQDTy
	fN2cfQ4ExCbvSxw1L6ShpFU7GVaNdhedYycUDcv+H4tS1nsAZrdCqZDFuB1ukmL5+NRN
	M5OxWlV/NQImaLHyhHJ4BhCb3TlFhJoGBgz7QlNuyIWHvhVAVxKS5JQhwPUo8lxCYAj7
	oEVqXej0+f+/gBijk4yl5zb34kyDw/RZOYGztvn1qGeHr3lgUqlJL3pLOEKiJDm7Uqze
	No7NgLl1+7jxqGcigc4hVBAogywati4e87VKmczymCEsszoIdUcSJJqDwrvLObau2cT0
	qUfA==
Received: by 10.66.79.36 with SMTP id g4mr11539951pax.67.1348771326058;
	Thu, 27 Sep 2012 11:42:06 -0700 (PDT)
Received: from [192.168.1.2] (cm141.gamma206.maxonline.com.sg.
	[202.156.206.141])
	by mx.google.com with ESMTPS id nt7sm4213188pbb.33.2012.09.27.11.42.04
	(version=SSLv3 cipher=OTHER); Thu, 27 Sep 2012 11:42:05 -0700 (PDT)
Message-ID: <50649DFA.6020004@gmail.com>
Date: Fri, 28 Sep 2012 02:42:02 +0800
From: "Teo En Ming (Zhang Enming)" <singapore.mr.teo.en.ming@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
MIME-Version: 1.0
To: "xen-users@lists.xen.org" <xen-users@lists.xen.org>, 
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	"Teo En Ming (Zhang Enming)" <singapore.mr.teo.en.ming@gmail.com>
Subject: [Xen-devel] xl: symbol lookup error: xl: undefined symbol:
	libxl_childproc_setmode
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
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,

I have just compiled xen 4.2.1-pre changeset 25862 from sources. When I 
tried to execute "sudo xl list" or "sudo xl info", it gave me the 
following error:

xl: symbol lookup error: xl: undefined symbol: libxl_childproc_setmode

Anybody knows how to solve this problem?

Thank you very much.

-- 
Yours sincerely,

Mr. Teo En Ming (Zhang Enming)
Singapore


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 27 18:42:33 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Sep 2012 18: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 1THJ2J-0003H6-5h; Thu, 27 Sep 2012 18:42:11 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <singapore.mr.teo.en.ming@gmail.com>)
	id 1THJ2H-0003Gj-KC
	for xen-devel@lists.xen.org; Thu, 27 Sep 2012 18:42:09 +0000
Received: from [85.158.139.211:38998] by server-3.bemta-5.messagelabs.com id
	93/14-16108-00E94605; Thu, 27 Sep 2012 18:42:08 +0000
X-Env-Sender: singapore.mr.teo.en.ming@gmail.com
X-Msg-Ref: server-2.tower-206.messagelabs.com!1348771326!20213955!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-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22255 invoked from network); 27 Sep 2012 18:42:08 -0000
Received: from mail-pb0-f45.google.com (HELO mail-pb0-f45.google.com)
	(209.85.160.45)
	by server-2.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Sep 2012 18:42:08 -0000
Received: by pbbrp2 with SMTP id rp2so4145194pbb.32
	for <multiple recipients>; Thu, 27 Sep 2012 11:42:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=message-id:disposition-notification-to:date:from:user-agent
	:mime-version:to:subject:content-type:content-transfer-encoding;
	bh=9I0JTUx4ComYhqA6PgNg31tqzKqPiVTp1Z4jVK7BkRA=;
	b=hIhmmSQV/2WgcmNPWwt3wZaF43r4qBzSKGkLKauCyVyk0JTa7Y/oPBev1OEoOSQDTy
	fN2cfQ4ExCbvSxw1L6ShpFU7GVaNdhedYycUDcv+H4tS1nsAZrdCqZDFuB1ukmL5+NRN
	M5OxWlV/NQImaLHyhHJ4BhCb3TlFhJoGBgz7QlNuyIWHvhVAVxKS5JQhwPUo8lxCYAj7
	oEVqXej0+f+/gBijk4yl5zb34kyDw/RZOYGztvn1qGeHr3lgUqlJL3pLOEKiJDm7Uqze
	No7NgLl1+7jxqGcigc4hVBAogywati4e87VKmczymCEsszoIdUcSJJqDwrvLObau2cT0
	qUfA==
Received: by 10.66.79.36 with SMTP id g4mr11539951pax.67.1348771326058;
	Thu, 27 Sep 2012 11:42:06 -0700 (PDT)
Received: from [192.168.1.2] (cm141.gamma206.maxonline.com.sg.
	[202.156.206.141])
	by mx.google.com with ESMTPS id nt7sm4213188pbb.33.2012.09.27.11.42.04
	(version=SSLv3 cipher=OTHER); Thu, 27 Sep 2012 11:42:05 -0700 (PDT)
Message-ID: <50649DFA.6020004@gmail.com>
Date: Fri, 28 Sep 2012 02:42:02 +0800
From: "Teo En Ming (Zhang Enming)" <singapore.mr.teo.en.ming@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
MIME-Version: 1.0
To: "xen-users@lists.xen.org" <xen-users@lists.xen.org>, 
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	"Teo En Ming (Zhang Enming)" <singapore.mr.teo.en.ming@gmail.com>
Subject: [Xen-devel] xl: symbol lookup error: xl: undefined symbol:
	libxl_childproc_setmode
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
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,

I have just compiled xen 4.2.1-pre changeset 25862 from sources. When I 
tried to execute "sudo xl list" or "sudo xl info", it gave me the 
following error:

xl: symbol lookup error: xl: undefined symbol: libxl_childproc_setmode

Anybody knows how to solve this problem?

Thank you very much.

-- 
Yours sincerely,

Mr. Teo En Ming (Zhang Enming)
Singapore


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 27 19:00:59 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Sep 2012 19:00: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 1THJKD-0004An-8f; Thu, 27 Sep 2012 19:00:41 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ikozhukhov@gmail.com>) id 1THJKC-0004Ah-Jg
	for xen-devel@lists.xen.org; Thu, 27 Sep 2012 19:00:40 +0000
Received: from [85.158.143.99:32437] by server-3.bemta-4.messagelabs.com id
	B0/0C-10986-752A4605; Thu, 27 Sep 2012 19:00:39 +0000
X-Env-Sender: ikozhukhov@gmail.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1348772439!23915001!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-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10659 invoked from network); 27 Sep 2012 19:00:39 -0000
Received: from mail-bk0-f45.google.com (HELO mail-bk0-f45.google.com)
	(209.85.214.45)
	by server-12.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Sep 2012 19:00:39 -0000
Received: by bkcjf3 with SMTP id jf3so1961379bkc.32
	for <multiple recipients>; Thu, 27 Sep 2012 12:00:39 -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:in-reply-to
	:mime-version:content-type:content-transfer-encoding;
	bh=LBsJLsq19n26zPcPFleVD/DXSnIXdxilwmuDp+EIOZ4=;
	b=SQvFOr2TFgxyukQrkaesl5fHXZhvwVhxzStk3ddLT0dxZ/hzbnlQpqjIzdKDLoaLTp
	GKYDTCIzN6tHke4hqDiJwFoRH3u23ZzzGCjYP3F2oqBJhiirh4sF+8MeNmwiQYCKpQhJ
	APFII2J/dtNr1yPAeR8E2iUxYftH3qWpDH1jHFf/ZGiiitx2MrokpMyfEY1SEsapxXkO
	kXqfqiUx2KMcFhivj+i/niezkQUsm/AvY3IlfH3AWTA7qhi+uobNdUrN1dsWyb/tpHiW
	eIqa52B5Q2+enWZSNzodJu9nWWWQk6VV3sBg1LE/qa6KKVg8bGC7kOts9kmjxcZhzLX8
	kvBg==
Received: by 10.152.162.97 with SMTP id xz1mr3998133lab.38.1348772438820;
	Thu, 27 Sep 2012 12:00:38 -0700 (PDT)
Received: from [172.16.90.16] ([91.204.58.44])
	by mx.google.com with ESMTPS id o7sm1963166lbg.4.2012.09.27.12.00.34
	(version=SSLv3 cipher=OTHER); Thu, 27 Sep 2012 12:00:37 -0700 (PDT)
User-Agent: Microsoft-MacOutlook/14.2.4.120824
Date: Thu, 27 Sep 2012 23:00:30 +0400
From: Igor Kozhukhov <ikozhukhov@gmail.com>
To: "Teo En Ming (Zhang Enming)" <singapore.mr.teo.en.ming@gmail.com>,
	"xen-users@lists.xen.org" <xen-users@lists.xen.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Message-ID: <CC8A8A6F.2F444%ikozhukhov@gmail.com>
Thread-Topic: [Xen-devel] xl: symbol lookup error: xl: undefined symbol:
	libxl_childproc_setmode
In-Reply-To: <50649DFA.6020004@gmail.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] xl: symbol lookup error: xl: undefined symbol:
 libxl_childproc_setmode
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Could you please provide more info:
- What is your distribution - RHEL, CentOS, Debian, Ubuntu ?
- what distribution version?
- do you have full build logs ? - take a look it for libxl build.
- do you have your own package with xen or you have used old package for
upgrade by new build ?

---
Best regards,
Igor Kozhukhov
IRC# igork




On 9/27/12 10:42 PM, "Teo En Ming (Zhang Enming)"
<singapore.mr.teo.en.ming@gmail.com> wrote:

>Hi,
>
>I have just compiled xen 4.2.1-pre changeset 25862 from sources. When I
>tried to execute "sudo xl list" or "sudo xl info", it gave me the
>following error:
>
>xl: symbol lookup error: xl: undefined symbol: libxl_childproc_setmode
>
>Anybody knows how to solve this problem?
>
>Thank you very much.
>
>-- 
>Yours sincerely,
>
>Mr. Teo En Ming (Zhang Enming)
>Singapore
>
>
>_______________________________________________
>Xen-devel mailing list
>Xen-devel@lists.xen.org
>http://lists.xen.org/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 Sep 27 19:00:59 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Sep 2012 19:00: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 1THJKD-0004An-8f; Thu, 27 Sep 2012 19:00:41 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ikozhukhov@gmail.com>) id 1THJKC-0004Ah-Jg
	for xen-devel@lists.xen.org; Thu, 27 Sep 2012 19:00:40 +0000
Received: from [85.158.143.99:32437] by server-3.bemta-4.messagelabs.com id
	B0/0C-10986-752A4605; Thu, 27 Sep 2012 19:00:39 +0000
X-Env-Sender: ikozhukhov@gmail.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1348772439!23915001!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-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10659 invoked from network); 27 Sep 2012 19:00:39 -0000
Received: from mail-bk0-f45.google.com (HELO mail-bk0-f45.google.com)
	(209.85.214.45)
	by server-12.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Sep 2012 19:00:39 -0000
Received: by bkcjf3 with SMTP id jf3so1961379bkc.32
	for <multiple recipients>; Thu, 27 Sep 2012 12:00:39 -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:in-reply-to
	:mime-version:content-type:content-transfer-encoding;
	bh=LBsJLsq19n26zPcPFleVD/DXSnIXdxilwmuDp+EIOZ4=;
	b=SQvFOr2TFgxyukQrkaesl5fHXZhvwVhxzStk3ddLT0dxZ/hzbnlQpqjIzdKDLoaLTp
	GKYDTCIzN6tHke4hqDiJwFoRH3u23ZzzGCjYP3F2oqBJhiirh4sF+8MeNmwiQYCKpQhJ
	APFII2J/dtNr1yPAeR8E2iUxYftH3qWpDH1jHFf/ZGiiitx2MrokpMyfEY1SEsapxXkO
	kXqfqiUx2KMcFhivj+i/niezkQUsm/AvY3IlfH3AWTA7qhi+uobNdUrN1dsWyb/tpHiW
	eIqa52B5Q2+enWZSNzodJu9nWWWQk6VV3sBg1LE/qa6KKVg8bGC7kOts9kmjxcZhzLX8
	kvBg==
Received: by 10.152.162.97 with SMTP id xz1mr3998133lab.38.1348772438820;
	Thu, 27 Sep 2012 12:00:38 -0700 (PDT)
Received: from [172.16.90.16] ([91.204.58.44])
	by mx.google.com with ESMTPS id o7sm1963166lbg.4.2012.09.27.12.00.34
	(version=SSLv3 cipher=OTHER); Thu, 27 Sep 2012 12:00:37 -0700 (PDT)
User-Agent: Microsoft-MacOutlook/14.2.4.120824
Date: Thu, 27 Sep 2012 23:00:30 +0400
From: Igor Kozhukhov <ikozhukhov@gmail.com>
To: "Teo En Ming (Zhang Enming)" <singapore.mr.teo.en.ming@gmail.com>,
	"xen-users@lists.xen.org" <xen-users@lists.xen.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Message-ID: <CC8A8A6F.2F444%ikozhukhov@gmail.com>
Thread-Topic: [Xen-devel] xl: symbol lookup error: xl: undefined symbol:
	libxl_childproc_setmode
In-Reply-To: <50649DFA.6020004@gmail.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] xl: symbol lookup error: xl: undefined symbol:
 libxl_childproc_setmode
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Could you please provide more info:
- What is your distribution - RHEL, CentOS, Debian, Ubuntu ?
- what distribution version?
- do you have full build logs ? - take a look it for libxl build.
- do you have your own package with xen or you have used old package for
upgrade by new build ?

---
Best regards,
Igor Kozhukhov
IRC# igork




On 9/27/12 10:42 PM, "Teo En Ming (Zhang Enming)"
<singapore.mr.teo.en.ming@gmail.com> wrote:

>Hi,
>
>I have just compiled xen 4.2.1-pre changeset 25862 from sources. When I
>tried to execute "sudo xl list" or "sudo xl info", it gave me the
>following error:
>
>xl: symbol lookup error: xl: undefined symbol: libxl_childproc_setmode
>
>Anybody knows how to solve this problem?
>
>Thank you very much.
>
>-- 
>Yours sincerely,
>
>Mr. Teo En Ming (Zhang Enming)
>Singapore
>
>
>_______________________________________________
>Xen-devel mailing list
>Xen-devel@lists.xen.org
>http://lists.xen.org/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 Sep 27 19:28:44 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Sep 2012 19:28:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1THJl5-0004sL-Ba; Thu, 27 Sep 2012 19:28:27 +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 1THJl3-0004sC-JP
	for xen-devel@lists.xensource.com; Thu, 27 Sep 2012 19:28:25 +0000
Received: from [85.158.143.99:15352] by server-1.bemta-4.messagelabs.com id
	EA/51-05684-8D8A4605; Thu, 27 Sep 2012 19:28:24 +0000
X-Env-Sender: dan.magenheimer@oracle.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1348774103!22433321!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzY4ODAw\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1801 invoked from network); 27 Sep 2012 19:28:24 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-14.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 27 Sep 2012 19:28:24 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q8RJSBfj006707
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 27 Sep 2012 19:28:12 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
	q8RJS7a7001175
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 27 Sep 2012 19:28:08 GMT
Received: from abhmt117.oracle.com (abhmt117.oracle.com [141.146.116.69])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q8RJS5jG003863; Thu, 27 Sep 2012 14:28:05 -0500
MIME-Version: 1.0
Message-ID: <65395f62-74e5-4910-b701-8df629c2ce3b@default>
Date: Thu, 27 Sep 2012 12:27:53 -0700 (PDT)
From: Dan Magenheimer <dan.magenheimer@oracle.com>
To: Mauro <mrsanna1@gmail.com>, Olivier Hanesse <olivier.hanesse@gmail.com>
References: <68c41dd8-9195-41b0-83d7-9242b8eff809@default>
	<AANLkTi=NFebVsnj_09+SpCZUo_bNTnTyJLAoR5sfbwZa@mail.gmail.com>
	<AANLkTikptc2POrKQgJuoVZRdwJTo64DJ_hm12KuPky4D@mail.gmail.com>
	<b1ca6ddc-ca69-447e-93e9-8d36d1ff4a43@default>
	<AANLkTinK94GDOF_GeaVs50wK0u8EdZ2rtzPuh65ca8qR@mail.gmail.com>
	<CAE17a0UPyzsNn=ps9MxarkGg=ns8dCpVz0qBDvesT2AOskwfVg@mail.gmail.com>
In-Reply-To: <CAE17a0UPyzsNn=ps9MxarkGg=ns8dCpVz0qBDvesT2AOskwfVg@mail.gmail.com>
X-Priority: 3
X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.7  (607090) [OL
	12.0.6661.5003 (x86)]
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: Jeremy Fitzhardinge <jeremy@goop.org>, xen-devel@lists.xensource.com,
	Keir Fraser <keir@xen.org>, Keir Fraser <keir.xen@gmail.com>,
	Xen Users <xen-users@lists.xensource.com>,
	Mark Adams <mark@campbell-lange.net>
Subject: Re: [Xen-devel] [Xen-users] Re:  Xen 4 TSC problems
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> From: Mauro [mailto:mrsanna1@gmail.com]
> Sent: Thursday, September 27, 2012 9:55 AM
> To: Olivier Hanesse
> Cc: Dan Magenheimer; Jeremy Fitzhardinge; xen-devel@lists.xensource.com; Keir Fraser; Jan Beulich;
> Keir Fraser; Xen Users; Mark Adams
> Subject: Re: [Xen-users] Re: [Xen-devel] Xen 4 TSC problems
> 
> On 28 February 2011 16:54, Olivier Hanesse <olivier.hanesse@gmail.com> wrote:
> > Yes this is what I mean.
> > I am glad to hear that it isn't a bad sign :)
> > I thought of a bad sign, because on system with "reliable TSC", this counter
> > is always 0.
> 
> Hey men.
> I have exactly the same problem.
> I have two cluster nodes.
> Server are two HP Proliant DL 580 G4 with four Quad Core Intel(R)
> Xeon(R) CPU E7330  @ 2.40GHz.
> I'm running debian squeeze in dom0s end domUs.

Hi Mauro --

There's been a lot of work on clocks since 4.0 (by other Xen developers,
not me).  I don't think this specific problem was ever reproduced
by a developer so I don't think anyone knows if it has been
already fixed or not, nor are there any plans to backport all the
timer work to 4.0.

You might try upgrading your Xen hypervisor to the just-released
Xen 4.2 [1] and see if the problem goes away.  If the problem still
exists in 4.2, it may be easier to get some developer to pay attention
to it.  It may be specific hardware or processors or power
management or firmware or even dom0 kernel, so the first thing
to do is try later hypervisor bits.

Sorry I can't be more helpful.  Good luck!

Dan

[1] Sorry, I'm not familiar with the 4.0->4.2 upgrade process
so you may want to confirm with others.

> xm info:
> 
> host                   : xen-p01
> release                : 2.6.32-5-xen-amd64
> version                : #1 SMP Sun May 6 08:57:29 UTC 2012
> machine                : x86_64
> nr_cpus                : 16
> nr_nodes               : 1
> cores_per_socket       : 4
> threads_per_core       : 1
> cpu_mhz                : 2400
> hw_caps                :
> bfebfbff:20100800:00000000:00000940:0004e3bd:00000000:00000001:00000000
> virt_caps              : hvm
> total_memory           : 65532
> free_memory            : 40317
> node_to_cpu            : node0:0-15
> node_to_memory         : node0:40317
> node_to_dma32_mem      : node0:3256
> max_node_id            : 0
> xen_major              : 4
> xen_minor              : 0
> xen_extra              : .1
> xen_caps               : xen-3.0-x86_64 xen-3.0-x86_32p hvm-3.0-x86_32
> hvm-3.0-x86_32p hvm-3.0-x86_64
> xen_scheduler          : credit
> xen_pagesize           : 4096
> platform_params        : virt_start=0xffff800000000000
> xen_changeset          : unavailable
> xen_commandline        : placeholder dom0_mem=3072M loglvl=warning
> guest_loglvl=warning
> cc_compiler            : gcc version 4.4.5 (Debian 4.4.5-8)
> cc_compile_by          : ultrotter
> cc_compile_domain      : debian.org
> cc_compile_date        : Sat Sep  8 19:15:46 UTC 2012
> xend_config_format     : 4
> 
> I'm experiencing weekly a clock jump ahead of about 50 minutes on dom0.
> I'm seriously in trouble because it cause every time a reboot of one
> of the two nodes clusters.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 27 19:28:44 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Sep 2012 19:28:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1THJl5-0004sL-Ba; Thu, 27 Sep 2012 19:28:27 +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 1THJl3-0004sC-JP
	for xen-devel@lists.xensource.com; Thu, 27 Sep 2012 19:28:25 +0000
Received: from [85.158.143.99:15352] by server-1.bemta-4.messagelabs.com id
	EA/51-05684-8D8A4605; Thu, 27 Sep 2012 19:28:24 +0000
X-Env-Sender: dan.magenheimer@oracle.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1348774103!22433321!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzY4ODAw\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1801 invoked from network); 27 Sep 2012 19:28:24 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-14.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 27 Sep 2012 19:28:24 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q8RJSBfj006707
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 27 Sep 2012 19:28:12 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
	q8RJS7a7001175
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 27 Sep 2012 19:28:08 GMT
Received: from abhmt117.oracle.com (abhmt117.oracle.com [141.146.116.69])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q8RJS5jG003863; Thu, 27 Sep 2012 14:28:05 -0500
MIME-Version: 1.0
Message-ID: <65395f62-74e5-4910-b701-8df629c2ce3b@default>
Date: Thu, 27 Sep 2012 12:27:53 -0700 (PDT)
From: Dan Magenheimer <dan.magenheimer@oracle.com>
To: Mauro <mrsanna1@gmail.com>, Olivier Hanesse <olivier.hanesse@gmail.com>
References: <68c41dd8-9195-41b0-83d7-9242b8eff809@default>
	<AANLkTi=NFebVsnj_09+SpCZUo_bNTnTyJLAoR5sfbwZa@mail.gmail.com>
	<AANLkTikptc2POrKQgJuoVZRdwJTo64DJ_hm12KuPky4D@mail.gmail.com>
	<b1ca6ddc-ca69-447e-93e9-8d36d1ff4a43@default>
	<AANLkTinK94GDOF_GeaVs50wK0u8EdZ2rtzPuh65ca8qR@mail.gmail.com>
	<CAE17a0UPyzsNn=ps9MxarkGg=ns8dCpVz0qBDvesT2AOskwfVg@mail.gmail.com>
In-Reply-To: <CAE17a0UPyzsNn=ps9MxarkGg=ns8dCpVz0qBDvesT2AOskwfVg@mail.gmail.com>
X-Priority: 3
X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.7  (607090) [OL
	12.0.6661.5003 (x86)]
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: Jeremy Fitzhardinge <jeremy@goop.org>, xen-devel@lists.xensource.com,
	Keir Fraser <keir@xen.org>, Keir Fraser <keir.xen@gmail.com>,
	Xen Users <xen-users@lists.xensource.com>,
	Mark Adams <mark@campbell-lange.net>
Subject: Re: [Xen-devel] [Xen-users] Re:  Xen 4 TSC problems
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

> From: Mauro [mailto:mrsanna1@gmail.com]
> Sent: Thursday, September 27, 2012 9:55 AM
> To: Olivier Hanesse
> Cc: Dan Magenheimer; Jeremy Fitzhardinge; xen-devel@lists.xensource.com; Keir Fraser; Jan Beulich;
> Keir Fraser; Xen Users; Mark Adams
> Subject: Re: [Xen-users] Re: [Xen-devel] Xen 4 TSC problems
> 
> On 28 February 2011 16:54, Olivier Hanesse <olivier.hanesse@gmail.com> wrote:
> > Yes this is what I mean.
> > I am glad to hear that it isn't a bad sign :)
> > I thought of a bad sign, because on system with "reliable TSC", this counter
> > is always 0.
> 
> Hey men.
> I have exactly the same problem.
> I have two cluster nodes.
> Server are two HP Proliant DL 580 G4 with four Quad Core Intel(R)
> Xeon(R) CPU E7330  @ 2.40GHz.
> I'm running debian squeeze in dom0s end domUs.

Hi Mauro --

There's been a lot of work on clocks since 4.0 (by other Xen developers,
not me).  I don't think this specific problem was ever reproduced
by a developer so I don't think anyone knows if it has been
already fixed or not, nor are there any plans to backport all the
timer work to 4.0.

You might try upgrading your Xen hypervisor to the just-released
Xen 4.2 [1] and see if the problem goes away.  If the problem still
exists in 4.2, it may be easier to get some developer to pay attention
to it.  It may be specific hardware or processors or power
management or firmware or even dom0 kernel, so the first thing
to do is try later hypervisor bits.

Sorry I can't be more helpful.  Good luck!

Dan

[1] Sorry, I'm not familiar with the 4.0->4.2 upgrade process
so you may want to confirm with others.

> xm info:
> 
> host                   : xen-p01
> release                : 2.6.32-5-xen-amd64
> version                : #1 SMP Sun May 6 08:57:29 UTC 2012
> machine                : x86_64
> nr_cpus                : 16
> nr_nodes               : 1
> cores_per_socket       : 4
> threads_per_core       : 1
> cpu_mhz                : 2400
> hw_caps                :
> bfebfbff:20100800:00000000:00000940:0004e3bd:00000000:00000001:00000000
> virt_caps              : hvm
> total_memory           : 65532
> free_memory            : 40317
> node_to_cpu            : node0:0-15
> node_to_memory         : node0:40317
> node_to_dma32_mem      : node0:3256
> max_node_id            : 0
> xen_major              : 4
> xen_minor              : 0
> xen_extra              : .1
> xen_caps               : xen-3.0-x86_64 xen-3.0-x86_32p hvm-3.0-x86_32
> hvm-3.0-x86_32p hvm-3.0-x86_64
> xen_scheduler          : credit
> xen_pagesize           : 4096
> platform_params        : virt_start=0xffff800000000000
> xen_changeset          : unavailable
> xen_commandline        : placeholder dom0_mem=3072M loglvl=warning
> guest_loglvl=warning
> cc_compiler            : gcc version 4.4.5 (Debian 4.4.5-8)
> cc_compile_by          : ultrotter
> cc_compile_domain      : debian.org
> cc_compile_date        : Sat Sep  8 19:15:46 UTC 2012
> xend_config_format     : 4
> 
> I'm experiencing weekly a clock jump ahead of about 50 minutes on dom0.
> I'm seriously in trouble because it cause every time a reboot of one
> of the two nodes clusters.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 27 20:12:11 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Sep 2012 20:12:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1THKR0-0005wu-LC; Thu, 27 Sep 2012 20:11:46 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <linux@eikelenboom.it>) id 1THKQy-0005wm-M6
	for xen-devel@lists.xensource.com; Thu, 27 Sep 2012 20:11:45 +0000
Received: from [85.158.137.99:44735] by server-13.bemta-3.messagelabs.com id
	C4/B8-11249-FF2B4605; Thu, 27 Sep 2012 20:11:43 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-14.tower-217.messagelabs.com!1348776701!19384062!1
X-Originating-IP: [188.40.164.121]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5289 invoked from network); 27 Sep 2012 20:11:41 -0000
Received: from static.121.164.40.188.clients.your-server.de (HELO
	smtp.eikelenboom.it) (188.40.164.121)
	by server-14.tower-217.messagelabs.com with AES256-SHA encrypted SMTP;
	27 Sep 2012 20:11:41 -0000
Received: from 50-64-ftth.onsneteindhoven.nl ([88.159.64.50]:60611
	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 1THKRn-0005Bh-CH; Thu, 27 Sep 2012 22:12:35 +0200
Date: Thu, 27 Sep 2012 22:11:37 +0200
From: Sander Eikelenboom <linux@eikelenboom.it>
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <158082007.20120927221137@eikelenboom.it>
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1348586949.12592.10.camel@zakaz.uk.xensource.com>
References: <patchbomb.1346960486@xentest.example.org>
	<1348565712.3452.141.camel@zakaz.uk.xensource.com>
	<15210025463.20120925171143@eikelenboom.it>
	<1348586949.12592.10.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Type: multipart/mixed;
 boundary="----------10B1260E631D4699E"
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 0 of 3] xl and hotplug: Introduce and use
	shutdown and reboot xm compatibility options
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

------------10B1260E631D4699E
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

=0D=0ATuesday, September 25, 2012, 5:29:09 PM, you wrote:

> On Tue, 2012-09-25 at 16:11 +0100, Sander Eikelenboom wrote:

>> The only relative simple implementation i thought of was direct
>> shutting down all, and when the -w parameter was set, just loop and
>> wait on events until the only running domain is domain-0.
>> Although this exactly does what has to be done, it somehow sounds a
>> bit dirty.

> I think you can allocate an array of libxl_evenable_domain_death*, of
> nr_doms in size and then as you shutdown each domain call
> libxl_evenable_domain_death for it too.

> Then you loop waiting for destroy events, calling
> libxl_evdisable_domain_death as each domain dies, while counting back
> from nr_doms until 0. When it reaches 0 everything you asked for has
> been shutdown.

> Or something like that, I've not actually implemented it ;-)

> Ian.

It's time to call defeat, without proper C skills it seems a bit too hard t=
o figure it out.
Can't seem to get the hang of how to keep a reference to libxl_evgen_domain=
_death
and use it to check if the domid of the event is the same as that from a do=
main we are waiting to shutdown.
The rest of the code doesn't give me much pointers since all commands seem =
to operate on a single domid at once.

The concoction below leads to:
xl_cmdimpl.c: In function =C3=A2shutdown_domain=C3=A2:
xl_cmdimpl.c:2766: error: dereferencing pointer to incomplete type


--------------------------- tools/libxl/xl_cmdimpl.c ----------------------=
-----
index 1627cac..b900811 100644
@@ -2684,67 +2684,98 @@ static void destroy_domain(uint32_t domid)
     }
     rc =3D libxl_domain_destroy(ctx, domid, 0);
     if (rc) { fprintf(stderr,"destroy failed (rc=3D%d)\n",rc); exit(-1); }
 }
=20
-static void shutdown_domain(uint32_t domid, int wait_for_it,
-                            int fallback_trigger)
+static int shutdown_domain(const libxl_dominfo *dominfo, int nb_domain,
+                            int wait_for_it, int fallback_trigger)
 {
-    int rc;
-    libxl_event *event;
+    int i, rc, nb_shutdown_pending;
+    int ret =3D 0;
+    libxl_evgen_domain_death *domains_wait_shutdown[nb_domain];
+      =20
+    for (i =3D 0; i < nb_domain; i++) {
+        uint32_t domid =3D dominfo[i].domid;
+        if(!libxl_domid_valid_guest(domid))
+            continue;
=20
-    rc=3Dlibxl_domain_shutdown(ctx, domid);
-    if (rc =3D=3D ERROR_NOPARAVIRT) {
-        if (fallback_trigger) {
-            fprintf(stderr, "PV control interface not available:"
-                    " sending ACPI power button event.\n");
-            rc =3D libxl_send_trigger(ctx, domid, LIBXL_TRIGGER_POWER, 0);
-        } else {
-            fprintf(stderr, "PV control interface not available:"
-                    " external graceful shutdown not possible.\n");
-            fprintf(stderr, "Use \"-F\" to fallback to ACPI power event.\n=
");
+        rc =3D libxl_domain_shutdown(ctx, domid);
+
+        if (rc =3D=3D ERROR_NOPARAVIRT) {
+            if (fallback_trigger) {
+                fprintf(stderr, "PV control interface not available:"
+                        " sending ACPI power button event.\n");
+                rc =3D libxl_send_trigger(ctx, domid, LIBXL_TRIGGER_POWER,=
 0);
+            } else {
+                fprintf(stderr, "PV control interface not available:"
+                        " external graceful shutdown not possible.\n");
+                fprintf(stderr,
+                    "Use \"-F\" to fallback to ACPI power event.\n");
+            }
+        }
+       =20
+        if (rc) {
+            fprintf(stderr,"shutdown of domain %d failed (rc=3D%d)\n", dom=
id, rc);
+            ret =3D -1;
+            continue;
+        }
+
+        if (wait_for_it) {
+            rc =3D libxl_evenable_domain_death(ctx, domid, 0, &domains_wai=
t_shutdown[i]);
+            if (rc) {
+                fprintf(stderr,"wait for death of domain %d failed"
+                    " (evgen, rc=3D%d)\n", domid, rc);
+                ret =3D -1;
+            } else {
+                nb_shutdown_pending++;
+            }=20
         }
-    }
-    if (rc) {
-        fprintf(stderr,"shutdown failed (rc=3D%d)\n",rc);exit(-1);
     }
=20
     if (wait_for_it) {
-        libxl_evgen_domain_death *deathw;
+        while (nb_shutdown_pending > 0) {
+            libxl_event *event;
+            rc =3D libxl_event_wait(ctx, &event, LIBXL_EVENTMASK_ALL, 0,0);
+            if (rc) {
+                LOG("Failed to get event (rc=3D%d)", rc);
+                return -1;
+            }
=20
-        rc =3D libxl_evenable_domain_death(ctx, domid, 0, &deathw);
-        if (rc) {
-            fprintf(stderr,"wait for death failed (evgen, rc=3D%d)\n",rc);
-            exit(-1);
-        }
+            uint32_t event_domid =3D event->domid;
+            switch (event->type) {
=20
-        for (;;) {
-            rc =3D domain_wait_event(domid, &event);
-            if (rc) exit(-1);
+                case LIBXL_EVENT_TYPE_DOMAIN_DEATH:
+                    LOG("Domain %d has been destroyed", event_domid);
+                    break;
=20
-            switch (event->type) {
+                case LIBXL_EVENT_TYPE_DOMAIN_SHUTDOWN:
+                    LOG("Domain %d has been shut down, reason code %d %x",
+                        event_domid,
+                        event->u.domain_shutdown.shutdown_reason,
+                        event->u.domain_shutdown.shutdown_reason);
+                    break;
=20
-            case LIBXL_EVENT_TYPE_DOMAIN_DEATH:
-                LOG("Domain %d has been destroyed", domid);
-                goto done;
+                default:
+                    continue;
+                    break;
+            }
=20
-            case LIBXL_EVENT_TYPE_DOMAIN_SHUTDOWN:
-                LOG("Domain %d has been shut down, reason code %d %x", dom=
id,
-                    event->u.domain_shutdown.shutdown_reason,
-                    event->u.domain_shutdown.shutdown_reason);
-                goto done;
+            for (i =3D 0; i < nb_domain; i++) {
+                if (!domains_wait_shutdown[i])
+                    continue;
=20
-            default:
-                LOG("Unexpected event type %d", event->type);
-                break;
+                if (domains_wait_shutdown[i]->domid =3D=3D event_domid){
+                    libxl_evdisable_domain_death(ctx, domains_wait_shutdow=
n[i]);
+                    domains_wait_shutdown[i] =3D NULL;
+                    nb_shutdown_pending--;
+                }
             }
             libxl_event_free(ctx, event);
         }
-    done:
-        libxl_event_free(ctx, event);
-        libxl_evdisable_domain_death(ctx, deathw);
     }
+
+    return ret;
 }
=20
 static void reboot_domain(uint32_t domid, int fallback_trigger)
 {
     int rc;
@@ -3674,29 +3705,82 @@ int main_destroy(int argc, char **argv)
     return 0;
 }
=20
 int main_shutdown(int argc, char **argv)
 {
+    libxl_dominfo dominfo_buf;
+    libxl_dominfo *dominfo, *dominfo_free =3D NULL;
+    int nb_domain, rc;
     int opt;
+    int option_index =3D 0;
+    int all =3D 0;
     int wait_for_it =3D 0;
     int fallback_trigger =3D 0;
+    static struct option long_options[] =3D {
+        {"all", 0, 0, 'a'},
+        {"wait", 0, 0, 'w'},
+        {0, 0, 0, 0}
+    };
=20
-    while ((opt =3D def_getopt(argc, argv, "wF", "shutdown", 1)) !=3D -1) {
+    while ((opt =3D getopt_long(argc, argv, "awF", long_options, &option_i=
ndex)) !=3D -1) {
         switch (opt) {
         case 0: case 2:
             return opt;
+        case 'a':
+            all =3D 1;
+            break;
         case 'w':
             wait_for_it =3D 1;
             break;
         case 'F':
             fallback_trigger =3D 1;
             break;
         }
     }
=20
-    shutdown_domain(find_domain(argv[optind]), wait_for_it, fallback_trigg=
er);
-    return 0;
+    if (!argv[optind] && !all) {
+        fprintf(stderr, "You must specify -a or a valid domain id.\n\n");
+        return opt;
+    }
+
+    if (all) {
+        dominfo =3D libxl_list_domain(ctx, &nb_domain);
+        if (!dominfo) {
+            fprintf(stderr, "libxl_domain_infolist failed.\n");
+            return -1;
+        }
+        dominfo_free =3D dominfo;
+    } else {
+        uint32_t domid =3D find_domain(argv[optind]);
+        if (domid =3D=3D 0) {
+            fprintf(stderr, "Error: Domain-0 can't be shutdown by this com=
mand\n");
+            return -1;
+        }
+
+        rc =3D libxl_domain_info(ctx, &dominfo_buf, domid);
+
+        if (rc =3D=3D ERROR_INVAL) {
+            fprintf(stderr, "Error: Domain \'%s\' does not exist.\n",
+                argv[optind]);
+            return -rc;
+        }
+        if (rc) {
+            fprintf(stderr, "libxl_domain_info failed (code %d).\n", rc);
+            return -rc;
+        }
+        dominfo =3D &dominfo_buf;
+        nb_domain =3D 1;
+    }
+
+    rc =3D shutdown_domain(dominfo, nb_domain, wait_for_it, fallback_trigg=
er);
+
+    if (dominfo_free)
+        libxl_dominfo_list_free(dominfo_free, nb_domain);
+    else
+        libxl_dominfo_dispose(dominfo);
+
+    return -rc;
 }
=20
 int main_reboot(int argc, char **argv)
 {
     int opt;





------------10B1260E631D4699E
Content-Type: application/octet-stream;
 name="patch.diff"
Content-transfer-encoding: base64
Content-Disposition: attachment;
 filename="patch.diff"

ZGlmZiAtLWdpdCBhL3Rvb2xzL2xpYnhsL3hsX2NtZGltcGwuYyBiL3Rvb2xzL2xpYnhsL3hs
X2NtZGltcGwuYwppbmRleCAxNjI3Y2FjLi5iOTAwODExIDEwMDY0NAotLS0gYS90b29scy9s
aWJ4bC94bF9jbWRpbXBsLmMKKysrIGIvdG9vbHMvbGlieGwveGxfY21kaW1wbC5jCkBAIC0y
Njg2LDYzICsyNjg2LDk0IEBAIHN0YXRpYyB2b2lkIGRlc3Ryb3lfZG9tYWluKHVpbnQzMl90
IGRvbWlkKQogICAgIGlmIChyYykgeyBmcHJpbnRmKHN0ZGVyciwiZGVzdHJveSBmYWlsZWQg
KHJjPSVkKVxuIixyYyk7IGV4aXQoLTEpOyB9CiB9CiAKLXN0YXRpYyB2b2lkIHNodXRkb3du
X2RvbWFpbih1aW50MzJfdCBkb21pZCwgaW50IHdhaXRfZm9yX2l0LAotICAgICAgICAgICAg
ICAgICAgICAgICAgICAgIGludCBmYWxsYmFja190cmlnZ2VyKQorc3RhdGljIGludCBzaHV0
ZG93bl9kb21haW4oY29uc3QgbGlieGxfZG9taW5mbyAqZG9taW5mbywgaW50IG5iX2RvbWFp
biwKKyAgICAgICAgICAgICAgICAgICAgICAgICAgICBpbnQgd2FpdF9mb3JfaXQsIGludCBm
YWxsYmFja190cmlnZ2VyKQogewotICAgIGludCByYzsKLSAgICBsaWJ4bF9ldmVudCAqZXZl
bnQ7CisgICAgaW50IGksIHJjLCBuYl9zaHV0ZG93bl9wZW5kaW5nOworICAgIGludCByZXQg
PSAwOworICAgIGxpYnhsX2V2Z2VuX2RvbWFpbl9kZWF0aCAqZG9tYWluc193YWl0X3NodXRk
b3duW25iX2RvbWFpbl07CisgICAgICAgCisgICAgZm9yIChpID0gMDsgaSA8IG5iX2RvbWFp
bjsgaSsrKSB7CisgICAgICAgIHVpbnQzMl90IGRvbWlkID0gZG9taW5mb1tpXS5kb21pZDsK
KyAgICAgICAgaWYoIWxpYnhsX2RvbWlkX3ZhbGlkX2d1ZXN0KGRvbWlkKSkKKyAgICAgICAg
ICAgIGNvbnRpbnVlOwogCi0gICAgcmM9bGlieGxfZG9tYWluX3NodXRkb3duKGN0eCwgZG9t
aWQpOwotICAgIGlmIChyYyA9PSBFUlJPUl9OT1BBUkFWSVJUKSB7Ci0gICAgICAgIGlmIChm
YWxsYmFja190cmlnZ2VyKSB7Ci0gICAgICAgICAgICBmcHJpbnRmKHN0ZGVyciwgIlBWIGNv
bnRyb2wgaW50ZXJmYWNlIG5vdCBhdmFpbGFibGU6IgotICAgICAgICAgICAgICAgICAgICAi
IHNlbmRpbmcgQUNQSSBwb3dlciBidXR0b24gZXZlbnQuXG4iKTsKLSAgICAgICAgICAgIHJj
ID0gbGlieGxfc2VuZF90cmlnZ2VyKGN0eCwgZG9taWQsIExJQlhMX1RSSUdHRVJfUE9XRVIs
IDApOwotICAgICAgICB9IGVsc2UgewotICAgICAgICAgICAgZnByaW50ZihzdGRlcnIsICJQ
ViBjb250cm9sIGludGVyZmFjZSBub3QgYXZhaWxhYmxlOiIKLSAgICAgICAgICAgICAgICAg
ICAgIiBleHRlcm5hbCBncmFjZWZ1bCBzaHV0ZG93biBub3QgcG9zc2libGUuXG4iKTsKLSAg
ICAgICAgICAgIGZwcmludGYoc3RkZXJyLCAiVXNlIFwiLUZcIiB0byBmYWxsYmFjayB0byBB
Q1BJIHBvd2VyIGV2ZW50LlxuIik7CisgICAgICAgIHJjID0gbGlieGxfZG9tYWluX3NodXRk
b3duKGN0eCwgZG9taWQpOworCisgICAgICAgIGlmIChyYyA9PSBFUlJPUl9OT1BBUkFWSVJU
KSB7CisgICAgICAgICAgICBpZiAoZmFsbGJhY2tfdHJpZ2dlcikgeworICAgICAgICAgICAg
ICAgIGZwcmludGYoc3RkZXJyLCAiUFYgY29udHJvbCBpbnRlcmZhY2Ugbm90IGF2YWlsYWJs
ZToiCisgICAgICAgICAgICAgICAgICAgICAgICAiIHNlbmRpbmcgQUNQSSBwb3dlciBidXR0
b24gZXZlbnQuXG4iKTsKKyAgICAgICAgICAgICAgICByYyA9IGxpYnhsX3NlbmRfdHJpZ2dl
cihjdHgsIGRvbWlkLCBMSUJYTF9UUklHR0VSX1BPV0VSLCAwKTsKKyAgICAgICAgICAgIH0g
ZWxzZSB7CisgICAgICAgICAgICAgICAgZnByaW50ZihzdGRlcnIsICJQViBjb250cm9sIGlu
dGVyZmFjZSBub3QgYXZhaWxhYmxlOiIKKyAgICAgICAgICAgICAgICAgICAgICAgICIgZXh0
ZXJuYWwgZ3JhY2VmdWwgc2h1dGRvd24gbm90IHBvc3NpYmxlLlxuIik7CisgICAgICAgICAg
ICAgICAgZnByaW50ZihzdGRlcnIsCisgICAgICAgICAgICAgICAgICAgICJVc2UgXCItRlwi
IHRvIGZhbGxiYWNrIHRvIEFDUEkgcG93ZXIgZXZlbnQuXG4iKTsKKyAgICAgICAgICAgIH0K
KyAgICAgICAgfQorICAgICAgICAKKyAgICAgICAgaWYgKHJjKSB7CisgICAgICAgICAgICBm
cHJpbnRmKHN0ZGVyciwic2h1dGRvd24gb2YgZG9tYWluICVkIGZhaWxlZCAocmM9JWQpXG4i
LCBkb21pZCwgcmMpOworICAgICAgICAgICAgcmV0ID0gLTE7CisgICAgICAgICAgICBjb250
aW51ZTsKKyAgICAgICAgfQorCisgICAgICAgIGlmICh3YWl0X2Zvcl9pdCkgeworICAgICAg
ICAgICAgcmMgPSBsaWJ4bF9ldmVuYWJsZV9kb21haW5fZGVhdGgoY3R4LCBkb21pZCwgMCwg
JmRvbWFpbnNfd2FpdF9zaHV0ZG93bltpXSk7CisgICAgICAgICAgICBpZiAocmMpIHsKKyAg
ICAgICAgICAgICAgICBmcHJpbnRmKHN0ZGVyciwid2FpdCBmb3IgZGVhdGggb2YgZG9tYWlu
ICVkIGZhaWxlZCIKKyAgICAgICAgICAgICAgICAgICAgIiAoZXZnZW4sIHJjPSVkKVxuIiwg
ZG9taWQsIHJjKTsKKyAgICAgICAgICAgICAgICByZXQgPSAtMTsKKyAgICAgICAgICAgIH0g
ZWxzZSB7CisgICAgICAgICAgICAgICAgbmJfc2h1dGRvd25fcGVuZGluZysrOworICAgICAg
ICAgICAgfSAKICAgICAgICAgfQotICAgIH0KLSAgICBpZiAocmMpIHsKLSAgICAgICAgZnBy
aW50ZihzdGRlcnIsInNodXRkb3duIGZhaWxlZCAocmM9JWQpXG4iLHJjKTtleGl0KC0xKTsK
ICAgICB9CiAKICAgICBpZiAod2FpdF9mb3JfaXQpIHsKLSAgICAgICAgbGlieGxfZXZnZW5f
ZG9tYWluX2RlYXRoICpkZWF0aHc7CisgICAgICAgIHdoaWxlIChuYl9zaHV0ZG93bl9wZW5k
aW5nID4gMCkgeworICAgICAgICAgICAgbGlieGxfZXZlbnQgKmV2ZW50OworICAgICAgICAg
ICAgcmMgPSBsaWJ4bF9ldmVudF93YWl0KGN0eCwgJmV2ZW50LCBMSUJYTF9FVkVOVE1BU0tf
QUxMLCAwLDApOworICAgICAgICAgICAgaWYgKHJjKSB7CisgICAgICAgICAgICAgICAgTE9H
KCJGYWlsZWQgdG8gZ2V0IGV2ZW50IChyYz0lZCkiLCByYyk7CisgICAgICAgICAgICAgICAg
cmV0dXJuIC0xOworICAgICAgICAgICAgfQogCi0gICAgICAgIHJjID0gbGlieGxfZXZlbmFi
bGVfZG9tYWluX2RlYXRoKGN0eCwgZG9taWQsIDAsICZkZWF0aHcpOwotICAgICAgICBpZiAo
cmMpIHsKLSAgICAgICAgICAgIGZwcmludGYoc3RkZXJyLCJ3YWl0IGZvciBkZWF0aCBmYWls
ZWQgKGV2Z2VuLCByYz0lZClcbiIscmMpOwotICAgICAgICAgICAgZXhpdCgtMSk7Ci0gICAg
ICAgIH0KKyAgICAgICAgICAgIHVpbnQzMl90IGV2ZW50X2RvbWlkID0gZXZlbnQtPmRvbWlk
OworICAgICAgICAgICAgc3dpdGNoIChldmVudC0+dHlwZSkgewogCi0gICAgICAgIGZvciAo
OzspIHsKLSAgICAgICAgICAgIHJjID0gZG9tYWluX3dhaXRfZXZlbnQoZG9taWQsICZldmVu
dCk7Ci0gICAgICAgICAgICBpZiAocmMpIGV4aXQoLTEpOworICAgICAgICAgICAgICAgIGNh
c2UgTElCWExfRVZFTlRfVFlQRV9ET01BSU5fREVBVEg6CisgICAgICAgICAgICAgICAgICAg
IExPRygiRG9tYWluICVkIGhhcyBiZWVuIGRlc3Ryb3llZCIsIGV2ZW50X2RvbWlkKTsKKyAg
ICAgICAgICAgICAgICAgICAgYnJlYWs7CiAKLSAgICAgICAgICAgIHN3aXRjaCAoZXZlbnQt
PnR5cGUpIHsKKyAgICAgICAgICAgICAgICBjYXNlIExJQlhMX0VWRU5UX1RZUEVfRE9NQUlO
X1NIVVRET1dOOgorICAgICAgICAgICAgICAgICAgICBMT0coIkRvbWFpbiAlZCBoYXMgYmVl
biBzaHV0IGRvd24sIHJlYXNvbiBjb2RlICVkICV4IiwKKyAgICAgICAgICAgICAgICAgICAg
ICAgIGV2ZW50X2RvbWlkLAorICAgICAgICAgICAgICAgICAgICAgICAgZXZlbnQtPnUuZG9t
YWluX3NodXRkb3duLnNodXRkb3duX3JlYXNvbiwKKyAgICAgICAgICAgICAgICAgICAgICAg
IGV2ZW50LT51LmRvbWFpbl9zaHV0ZG93bi5zaHV0ZG93bl9yZWFzb24pOworICAgICAgICAg
ICAgICAgICAgICBicmVhazsKIAotICAgICAgICAgICAgY2FzZSBMSUJYTF9FVkVOVF9UWVBF
X0RPTUFJTl9ERUFUSDoKLSAgICAgICAgICAgICAgICBMT0coIkRvbWFpbiAlZCBoYXMgYmVl
biBkZXN0cm95ZWQiLCBkb21pZCk7Ci0gICAgICAgICAgICAgICAgZ290byBkb25lOworICAg
ICAgICAgICAgICAgIGRlZmF1bHQ6CisgICAgICAgICAgICAgICAgICAgIGNvbnRpbnVlOwor
ICAgICAgICAgICAgICAgICAgICBicmVhazsKKyAgICAgICAgICAgIH0KIAotICAgICAgICAg
ICAgY2FzZSBMSUJYTF9FVkVOVF9UWVBFX0RPTUFJTl9TSFVURE9XTjoKLSAgICAgICAgICAg
ICAgICBMT0coIkRvbWFpbiAlZCBoYXMgYmVlbiBzaHV0IGRvd24sIHJlYXNvbiBjb2RlICVk
ICV4IiwgZG9taWQsCi0gICAgICAgICAgICAgICAgICAgIGV2ZW50LT51LmRvbWFpbl9zaHV0
ZG93bi5zaHV0ZG93bl9yZWFzb24sCi0gICAgICAgICAgICAgICAgICAgIGV2ZW50LT51LmRv
bWFpbl9zaHV0ZG93bi5zaHV0ZG93bl9yZWFzb24pOwotICAgICAgICAgICAgICAgIGdvdG8g
ZG9uZTsKKyAgICAgICAgICAgIGZvciAoaSA9IDA7IGkgPCBuYl9kb21haW47IGkrKykgewor
ICAgICAgICAgICAgICAgIGlmICghZG9tYWluc193YWl0X3NodXRkb3duW2ldKQorICAgICAg
ICAgICAgICAgICAgICBjb250aW51ZTsKIAotICAgICAgICAgICAgZGVmYXVsdDoKLSAgICAg
ICAgICAgICAgICBMT0coIlVuZXhwZWN0ZWQgZXZlbnQgdHlwZSAlZCIsIGV2ZW50LT50eXBl
KTsKLSAgICAgICAgICAgICAgICBicmVhazsKKyAgICAgICAgICAgICAgICBpZiAoZG9tYWlu
c193YWl0X3NodXRkb3duW2ldLT5kb21pZCA9PSBldmVudF9kb21pZCl7CisgICAgICAgICAg
ICAgICAgICAgIGxpYnhsX2V2ZGlzYWJsZV9kb21haW5fZGVhdGgoY3R4LCBkb21haW5zX3dh
aXRfc2h1dGRvd25baV0pOworICAgICAgICAgICAgICAgICAgICBkb21haW5zX3dhaXRfc2h1
dGRvd25baV0gPSBOVUxMOworICAgICAgICAgICAgICAgICAgICBuYl9zaHV0ZG93bl9wZW5k
aW5nLS07CisgICAgICAgICAgICAgICAgfQogICAgICAgICAgICAgfQogICAgICAgICAgICAg
bGlieGxfZXZlbnRfZnJlZShjdHgsIGV2ZW50KTsKICAgICAgICAgfQotICAgIGRvbmU6Ci0g
ICAgICAgIGxpYnhsX2V2ZW50X2ZyZWUoY3R4LCBldmVudCk7Ci0gICAgICAgIGxpYnhsX2V2
ZGlzYWJsZV9kb21haW5fZGVhdGgoY3R4LCBkZWF0aHcpOwogICAgIH0KKworICAgIHJldHVy
biByZXQ7CiB9CiAKIHN0YXRpYyB2b2lkIHJlYm9vdF9kb21haW4odWludDMyX3QgZG9taWQs
IGludCBmYWxsYmFja190cmlnZ2VyKQpAQCAtMzY3NiwxNCArMzcwNywyNyBAQCBpbnQgbWFp
bl9kZXN0cm95KGludCBhcmdjLCBjaGFyICoqYXJndikKIAogaW50IG1haW5fc2h1dGRvd24o
aW50IGFyZ2MsIGNoYXIgKiphcmd2KQogeworICAgIGxpYnhsX2RvbWluZm8gZG9taW5mb19i
dWY7CisgICAgbGlieGxfZG9taW5mbyAqZG9taW5mbywgKmRvbWluZm9fZnJlZSA9IE5VTEw7
CisgICAgaW50IG5iX2RvbWFpbiwgcmM7CiAgICAgaW50IG9wdDsKKyAgICBpbnQgb3B0aW9u
X2luZGV4ID0gMDsKKyAgICBpbnQgYWxsID0gMDsKICAgICBpbnQgd2FpdF9mb3JfaXQgPSAw
OwogICAgIGludCBmYWxsYmFja190cmlnZ2VyID0gMDsKKyAgICBzdGF0aWMgc3RydWN0IG9w
dGlvbiBsb25nX29wdGlvbnNbXSA9IHsKKyAgICAgICAgeyJhbGwiLCAwLCAwLCAnYSd9LAor
ICAgICAgICB7IndhaXQiLCAwLCAwLCAndyd9LAorICAgICAgICB7MCwgMCwgMCwgMH0KKyAg
ICB9OwogCi0gICAgd2hpbGUgKChvcHQgPSBkZWZfZ2V0b3B0KGFyZ2MsIGFyZ3YsICJ3RiIs
ICJzaHV0ZG93biIsIDEpKSAhPSAtMSkgeworICAgIHdoaWxlICgob3B0ID0gZ2V0b3B0X2xv
bmcoYXJnYywgYXJndiwgImF3RiIsIGxvbmdfb3B0aW9ucywgJm9wdGlvbl9pbmRleCkpICE9
IC0xKSB7CiAgICAgICAgIHN3aXRjaCAob3B0KSB7CiAgICAgICAgIGNhc2UgMDogY2FzZSAy
OgogICAgICAgICAgICAgcmV0dXJuIG9wdDsKKyAgICAgICAgY2FzZSAnYSc6CisgICAgICAg
ICAgICBhbGwgPSAxOworICAgICAgICAgICAgYnJlYWs7CiAgICAgICAgIGNhc2UgJ3cnOgog
ICAgICAgICAgICAgd2FpdF9mb3JfaXQgPSAxOwogICAgICAgICAgICAgYnJlYWs7CkBAIC0z
NjkzLDggKzM3MzcsNDggQEAgaW50IG1haW5fc2h1dGRvd24oaW50IGFyZ2MsIGNoYXIgKiph
cmd2KQogICAgICAgICB9CiAgICAgfQogCi0gICAgc2h1dGRvd25fZG9tYWluKGZpbmRfZG9t
YWluKGFyZ3Zbb3B0aW5kXSksIHdhaXRfZm9yX2l0LCBmYWxsYmFja190cmlnZ2VyKTsKLSAg
ICByZXR1cm4gMDsKKyAgICBpZiAoIWFyZ3Zbb3B0aW5kXSAmJiAhYWxsKSB7CisgICAgICAg
IGZwcmludGYoc3RkZXJyLCAiWW91IG11c3Qgc3BlY2lmeSAtYSBvciBhIHZhbGlkIGRvbWFp
biBpZC5cblxuIik7CisgICAgICAgIHJldHVybiBvcHQ7CisgICAgfQorCisgICAgaWYgKGFs
bCkgeworICAgICAgICBkb21pbmZvID0gbGlieGxfbGlzdF9kb21haW4oY3R4LCAmbmJfZG9t
YWluKTsKKyAgICAgICAgaWYgKCFkb21pbmZvKSB7CisgICAgICAgICAgICBmcHJpbnRmKHN0
ZGVyciwgImxpYnhsX2RvbWFpbl9pbmZvbGlzdCBmYWlsZWQuXG4iKTsKKyAgICAgICAgICAg
IHJldHVybiAtMTsKKyAgICAgICAgfQorICAgICAgICBkb21pbmZvX2ZyZWUgPSBkb21pbmZv
OworICAgIH0gZWxzZSB7CisgICAgICAgIHVpbnQzMl90IGRvbWlkID0gZmluZF9kb21haW4o
YXJndltvcHRpbmRdKTsKKyAgICAgICAgaWYgKGRvbWlkID09IDApIHsKKyAgICAgICAgICAg
IGZwcmludGYoc3RkZXJyLCAiRXJyb3I6IERvbWFpbi0wIGNhbid0IGJlIHNodXRkb3duIGJ5
IHRoaXMgY29tbWFuZFxuIik7CisgICAgICAgICAgICByZXR1cm4gLTE7CisgICAgICAgIH0K
KworICAgICAgICByYyA9IGxpYnhsX2RvbWFpbl9pbmZvKGN0eCwgJmRvbWluZm9fYnVmLCBk
b21pZCk7CisKKyAgICAgICAgaWYgKHJjID09IEVSUk9SX0lOVkFMKSB7CisgICAgICAgICAg
ICBmcHJpbnRmKHN0ZGVyciwgIkVycm9yOiBEb21haW4gXCclc1wnIGRvZXMgbm90IGV4aXN0
LlxuIiwKKyAgICAgICAgICAgICAgICBhcmd2W29wdGluZF0pOworICAgICAgICAgICAgcmV0
dXJuIC1yYzsKKyAgICAgICAgfQorICAgICAgICBpZiAocmMpIHsKKyAgICAgICAgICAgIGZw
cmludGYoc3RkZXJyLCAibGlieGxfZG9tYWluX2luZm8gZmFpbGVkIChjb2RlICVkKS5cbiIs
IHJjKTsKKyAgICAgICAgICAgIHJldHVybiAtcmM7CisgICAgICAgIH0KKyAgICAgICAgZG9t
aW5mbyA9ICZkb21pbmZvX2J1ZjsKKyAgICAgICAgbmJfZG9tYWluID0gMTsKKyAgICB9CisK
KyAgICByYyA9IHNodXRkb3duX2RvbWFpbihkb21pbmZvLCBuYl9kb21haW4sIHdhaXRfZm9y
X2l0LCBmYWxsYmFja190cmlnZ2VyKTsKKworICAgIGlmIChkb21pbmZvX2ZyZWUpCisgICAg
ICAgIGxpYnhsX2RvbWluZm9fbGlzdF9mcmVlKGRvbWluZm9fZnJlZSwgbmJfZG9tYWluKTsK
KyAgICBlbHNlCisgICAgICAgIGxpYnhsX2RvbWluZm9fZGlzcG9zZShkb21pbmZvKTsKKwor
ICAgIHJldHVybiAtcmM7CiB9CiAKIGludCBtYWluX3JlYm9vdChpbnQgYXJnYywgY2hhciAq
KmFyZ3YpCg==
------------10B1260E631D4699E
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

------------10B1260E631D4699E--



From xen-devel-bounces@lists.xen.org Thu Sep 27 20:12:11 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Sep 2012 20:12:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1THKR0-0005wu-LC; Thu, 27 Sep 2012 20:11:46 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <linux@eikelenboom.it>) id 1THKQy-0005wm-M6
	for xen-devel@lists.xensource.com; Thu, 27 Sep 2012 20:11:45 +0000
Received: from [85.158.137.99:44735] by server-13.bemta-3.messagelabs.com id
	C4/B8-11249-FF2B4605; Thu, 27 Sep 2012 20:11:43 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-14.tower-217.messagelabs.com!1348776701!19384062!1
X-Originating-IP: [188.40.164.121]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5289 invoked from network); 27 Sep 2012 20:11:41 -0000
Received: from static.121.164.40.188.clients.your-server.de (HELO
	smtp.eikelenboom.it) (188.40.164.121)
	by server-14.tower-217.messagelabs.com with AES256-SHA encrypted SMTP;
	27 Sep 2012 20:11:41 -0000
Received: from 50-64-ftth.onsneteindhoven.nl ([88.159.64.50]:60611
	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 1THKRn-0005Bh-CH; Thu, 27 Sep 2012 22:12:35 +0200
Date: Thu, 27 Sep 2012 22:11:37 +0200
From: Sander Eikelenboom <linux@eikelenboom.it>
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <158082007.20120927221137@eikelenboom.it>
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1348586949.12592.10.camel@zakaz.uk.xensource.com>
References: <patchbomb.1346960486@xentest.example.org>
	<1348565712.3452.141.camel@zakaz.uk.xensource.com>
	<15210025463.20120925171143@eikelenboom.it>
	<1348586949.12592.10.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Type: multipart/mixed;
 boundary="----------10B1260E631D4699E"
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 0 of 3] xl and hotplug: Introduce and use
	shutdown and reboot xm compatibility options
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

------------10B1260E631D4699E
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

=0D=0ATuesday, September 25, 2012, 5:29:09 PM, you wrote:

> On Tue, 2012-09-25 at 16:11 +0100, Sander Eikelenboom wrote:

>> The only relative simple implementation i thought of was direct
>> shutting down all, and when the -w parameter was set, just loop and
>> wait on events until the only running domain is domain-0.
>> Although this exactly does what has to be done, it somehow sounds a
>> bit dirty.

> I think you can allocate an array of libxl_evenable_domain_death*, of
> nr_doms in size and then as you shutdown each domain call
> libxl_evenable_domain_death for it too.

> Then you loop waiting for destroy events, calling
> libxl_evdisable_domain_death as each domain dies, while counting back
> from nr_doms until 0. When it reaches 0 everything you asked for has
> been shutdown.

> Or something like that, I've not actually implemented it ;-)

> Ian.

It's time to call defeat, without proper C skills it seems a bit too hard t=
o figure it out.
Can't seem to get the hang of how to keep a reference to libxl_evgen_domain=
_death
and use it to check if the domid of the event is the same as that from a do=
main we are waiting to shutdown.
The rest of the code doesn't give me much pointers since all commands seem =
to operate on a single domid at once.

The concoction below leads to:
xl_cmdimpl.c: In function =C3=A2shutdown_domain=C3=A2:
xl_cmdimpl.c:2766: error: dereferencing pointer to incomplete type


--------------------------- tools/libxl/xl_cmdimpl.c ----------------------=
-----
index 1627cac..b900811 100644
@@ -2684,67 +2684,98 @@ static void destroy_domain(uint32_t domid)
     }
     rc =3D libxl_domain_destroy(ctx, domid, 0);
     if (rc) { fprintf(stderr,"destroy failed (rc=3D%d)\n",rc); exit(-1); }
 }
=20
-static void shutdown_domain(uint32_t domid, int wait_for_it,
-                            int fallback_trigger)
+static int shutdown_domain(const libxl_dominfo *dominfo, int nb_domain,
+                            int wait_for_it, int fallback_trigger)
 {
-    int rc;
-    libxl_event *event;
+    int i, rc, nb_shutdown_pending;
+    int ret =3D 0;
+    libxl_evgen_domain_death *domains_wait_shutdown[nb_domain];
+      =20
+    for (i =3D 0; i < nb_domain; i++) {
+        uint32_t domid =3D dominfo[i].domid;
+        if(!libxl_domid_valid_guest(domid))
+            continue;
=20
-    rc=3Dlibxl_domain_shutdown(ctx, domid);
-    if (rc =3D=3D ERROR_NOPARAVIRT) {
-        if (fallback_trigger) {
-            fprintf(stderr, "PV control interface not available:"
-                    " sending ACPI power button event.\n");
-            rc =3D libxl_send_trigger(ctx, domid, LIBXL_TRIGGER_POWER, 0);
-        } else {
-            fprintf(stderr, "PV control interface not available:"
-                    " external graceful shutdown not possible.\n");
-            fprintf(stderr, "Use \"-F\" to fallback to ACPI power event.\n=
");
+        rc =3D libxl_domain_shutdown(ctx, domid);
+
+        if (rc =3D=3D ERROR_NOPARAVIRT) {
+            if (fallback_trigger) {
+                fprintf(stderr, "PV control interface not available:"
+                        " sending ACPI power button event.\n");
+                rc =3D libxl_send_trigger(ctx, domid, LIBXL_TRIGGER_POWER,=
 0);
+            } else {
+                fprintf(stderr, "PV control interface not available:"
+                        " external graceful shutdown not possible.\n");
+                fprintf(stderr,
+                    "Use \"-F\" to fallback to ACPI power event.\n");
+            }
+        }
+       =20
+        if (rc) {
+            fprintf(stderr,"shutdown of domain %d failed (rc=3D%d)\n", dom=
id, rc);
+            ret =3D -1;
+            continue;
+        }
+
+        if (wait_for_it) {
+            rc =3D libxl_evenable_domain_death(ctx, domid, 0, &domains_wai=
t_shutdown[i]);
+            if (rc) {
+                fprintf(stderr,"wait for death of domain %d failed"
+                    " (evgen, rc=3D%d)\n", domid, rc);
+                ret =3D -1;
+            } else {
+                nb_shutdown_pending++;
+            }=20
         }
-    }
-    if (rc) {
-        fprintf(stderr,"shutdown failed (rc=3D%d)\n",rc);exit(-1);
     }
=20
     if (wait_for_it) {
-        libxl_evgen_domain_death *deathw;
+        while (nb_shutdown_pending > 0) {
+            libxl_event *event;
+            rc =3D libxl_event_wait(ctx, &event, LIBXL_EVENTMASK_ALL, 0,0);
+            if (rc) {
+                LOG("Failed to get event (rc=3D%d)", rc);
+                return -1;
+            }
=20
-        rc =3D libxl_evenable_domain_death(ctx, domid, 0, &deathw);
-        if (rc) {
-            fprintf(stderr,"wait for death failed (evgen, rc=3D%d)\n",rc);
-            exit(-1);
-        }
+            uint32_t event_domid =3D event->domid;
+            switch (event->type) {
=20
-        for (;;) {
-            rc =3D domain_wait_event(domid, &event);
-            if (rc) exit(-1);
+                case LIBXL_EVENT_TYPE_DOMAIN_DEATH:
+                    LOG("Domain %d has been destroyed", event_domid);
+                    break;
=20
-            switch (event->type) {
+                case LIBXL_EVENT_TYPE_DOMAIN_SHUTDOWN:
+                    LOG("Domain %d has been shut down, reason code %d %x",
+                        event_domid,
+                        event->u.domain_shutdown.shutdown_reason,
+                        event->u.domain_shutdown.shutdown_reason);
+                    break;
=20
-            case LIBXL_EVENT_TYPE_DOMAIN_DEATH:
-                LOG("Domain %d has been destroyed", domid);
-                goto done;
+                default:
+                    continue;
+                    break;
+            }
=20
-            case LIBXL_EVENT_TYPE_DOMAIN_SHUTDOWN:
-                LOG("Domain %d has been shut down, reason code %d %x", dom=
id,
-                    event->u.domain_shutdown.shutdown_reason,
-                    event->u.domain_shutdown.shutdown_reason);
-                goto done;
+            for (i =3D 0; i < nb_domain; i++) {
+                if (!domains_wait_shutdown[i])
+                    continue;
=20
-            default:
-                LOG("Unexpected event type %d", event->type);
-                break;
+                if (domains_wait_shutdown[i]->domid =3D=3D event_domid){
+                    libxl_evdisable_domain_death(ctx, domains_wait_shutdow=
n[i]);
+                    domains_wait_shutdown[i] =3D NULL;
+                    nb_shutdown_pending--;
+                }
             }
             libxl_event_free(ctx, event);
         }
-    done:
-        libxl_event_free(ctx, event);
-        libxl_evdisable_domain_death(ctx, deathw);
     }
+
+    return ret;
 }
=20
 static void reboot_domain(uint32_t domid, int fallback_trigger)
 {
     int rc;
@@ -3674,29 +3705,82 @@ int main_destroy(int argc, char **argv)
     return 0;
 }
=20
 int main_shutdown(int argc, char **argv)
 {
+    libxl_dominfo dominfo_buf;
+    libxl_dominfo *dominfo, *dominfo_free =3D NULL;
+    int nb_domain, rc;
     int opt;
+    int option_index =3D 0;
+    int all =3D 0;
     int wait_for_it =3D 0;
     int fallback_trigger =3D 0;
+    static struct option long_options[] =3D {
+        {"all", 0, 0, 'a'},
+        {"wait", 0, 0, 'w'},
+        {0, 0, 0, 0}
+    };
=20
-    while ((opt =3D def_getopt(argc, argv, "wF", "shutdown", 1)) !=3D -1) {
+    while ((opt =3D getopt_long(argc, argv, "awF", long_options, &option_i=
ndex)) !=3D -1) {
         switch (opt) {
         case 0: case 2:
             return opt;
+        case 'a':
+            all =3D 1;
+            break;
         case 'w':
             wait_for_it =3D 1;
             break;
         case 'F':
             fallback_trigger =3D 1;
             break;
         }
     }
=20
-    shutdown_domain(find_domain(argv[optind]), wait_for_it, fallback_trigg=
er);
-    return 0;
+    if (!argv[optind] && !all) {
+        fprintf(stderr, "You must specify -a or a valid domain id.\n\n");
+        return opt;
+    }
+
+    if (all) {
+        dominfo =3D libxl_list_domain(ctx, &nb_domain);
+        if (!dominfo) {
+            fprintf(stderr, "libxl_domain_infolist failed.\n");
+            return -1;
+        }
+        dominfo_free =3D dominfo;
+    } else {
+        uint32_t domid =3D find_domain(argv[optind]);
+        if (domid =3D=3D 0) {
+            fprintf(stderr, "Error: Domain-0 can't be shutdown by this com=
mand\n");
+            return -1;
+        }
+
+        rc =3D libxl_domain_info(ctx, &dominfo_buf, domid);
+
+        if (rc =3D=3D ERROR_INVAL) {
+            fprintf(stderr, "Error: Domain \'%s\' does not exist.\n",
+                argv[optind]);
+            return -rc;
+        }
+        if (rc) {
+            fprintf(stderr, "libxl_domain_info failed (code %d).\n", rc);
+            return -rc;
+        }
+        dominfo =3D &dominfo_buf;
+        nb_domain =3D 1;
+    }
+
+    rc =3D shutdown_domain(dominfo, nb_domain, wait_for_it, fallback_trigg=
er);
+
+    if (dominfo_free)
+        libxl_dominfo_list_free(dominfo_free, nb_domain);
+    else
+        libxl_dominfo_dispose(dominfo);
+
+    return -rc;
 }
=20
 int main_reboot(int argc, char **argv)
 {
     int opt;





------------10B1260E631D4699E
Content-Type: application/octet-stream;
 name="patch.diff"
Content-transfer-encoding: base64
Content-Disposition: attachment;
 filename="patch.diff"

ZGlmZiAtLWdpdCBhL3Rvb2xzL2xpYnhsL3hsX2NtZGltcGwuYyBiL3Rvb2xzL2xpYnhsL3hs
X2NtZGltcGwuYwppbmRleCAxNjI3Y2FjLi5iOTAwODExIDEwMDY0NAotLS0gYS90b29scy9s
aWJ4bC94bF9jbWRpbXBsLmMKKysrIGIvdG9vbHMvbGlieGwveGxfY21kaW1wbC5jCkBAIC0y
Njg2LDYzICsyNjg2LDk0IEBAIHN0YXRpYyB2b2lkIGRlc3Ryb3lfZG9tYWluKHVpbnQzMl90
IGRvbWlkKQogICAgIGlmIChyYykgeyBmcHJpbnRmKHN0ZGVyciwiZGVzdHJveSBmYWlsZWQg
KHJjPSVkKVxuIixyYyk7IGV4aXQoLTEpOyB9CiB9CiAKLXN0YXRpYyB2b2lkIHNodXRkb3du
X2RvbWFpbih1aW50MzJfdCBkb21pZCwgaW50IHdhaXRfZm9yX2l0LAotICAgICAgICAgICAg
ICAgICAgICAgICAgICAgIGludCBmYWxsYmFja190cmlnZ2VyKQorc3RhdGljIGludCBzaHV0
ZG93bl9kb21haW4oY29uc3QgbGlieGxfZG9taW5mbyAqZG9taW5mbywgaW50IG5iX2RvbWFp
biwKKyAgICAgICAgICAgICAgICAgICAgICAgICAgICBpbnQgd2FpdF9mb3JfaXQsIGludCBm
YWxsYmFja190cmlnZ2VyKQogewotICAgIGludCByYzsKLSAgICBsaWJ4bF9ldmVudCAqZXZl
bnQ7CisgICAgaW50IGksIHJjLCBuYl9zaHV0ZG93bl9wZW5kaW5nOworICAgIGludCByZXQg
PSAwOworICAgIGxpYnhsX2V2Z2VuX2RvbWFpbl9kZWF0aCAqZG9tYWluc193YWl0X3NodXRk
b3duW25iX2RvbWFpbl07CisgICAgICAgCisgICAgZm9yIChpID0gMDsgaSA8IG5iX2RvbWFp
bjsgaSsrKSB7CisgICAgICAgIHVpbnQzMl90IGRvbWlkID0gZG9taW5mb1tpXS5kb21pZDsK
KyAgICAgICAgaWYoIWxpYnhsX2RvbWlkX3ZhbGlkX2d1ZXN0KGRvbWlkKSkKKyAgICAgICAg
ICAgIGNvbnRpbnVlOwogCi0gICAgcmM9bGlieGxfZG9tYWluX3NodXRkb3duKGN0eCwgZG9t
aWQpOwotICAgIGlmIChyYyA9PSBFUlJPUl9OT1BBUkFWSVJUKSB7Ci0gICAgICAgIGlmIChm
YWxsYmFja190cmlnZ2VyKSB7Ci0gICAgICAgICAgICBmcHJpbnRmKHN0ZGVyciwgIlBWIGNv
bnRyb2wgaW50ZXJmYWNlIG5vdCBhdmFpbGFibGU6IgotICAgICAgICAgICAgICAgICAgICAi
IHNlbmRpbmcgQUNQSSBwb3dlciBidXR0b24gZXZlbnQuXG4iKTsKLSAgICAgICAgICAgIHJj
ID0gbGlieGxfc2VuZF90cmlnZ2VyKGN0eCwgZG9taWQsIExJQlhMX1RSSUdHRVJfUE9XRVIs
IDApOwotICAgICAgICB9IGVsc2UgewotICAgICAgICAgICAgZnByaW50ZihzdGRlcnIsICJQ
ViBjb250cm9sIGludGVyZmFjZSBub3QgYXZhaWxhYmxlOiIKLSAgICAgICAgICAgICAgICAg
ICAgIiBleHRlcm5hbCBncmFjZWZ1bCBzaHV0ZG93biBub3QgcG9zc2libGUuXG4iKTsKLSAg
ICAgICAgICAgIGZwcmludGYoc3RkZXJyLCAiVXNlIFwiLUZcIiB0byBmYWxsYmFjayB0byBB
Q1BJIHBvd2VyIGV2ZW50LlxuIik7CisgICAgICAgIHJjID0gbGlieGxfZG9tYWluX3NodXRk
b3duKGN0eCwgZG9taWQpOworCisgICAgICAgIGlmIChyYyA9PSBFUlJPUl9OT1BBUkFWSVJU
KSB7CisgICAgICAgICAgICBpZiAoZmFsbGJhY2tfdHJpZ2dlcikgeworICAgICAgICAgICAg
ICAgIGZwcmludGYoc3RkZXJyLCAiUFYgY29udHJvbCBpbnRlcmZhY2Ugbm90IGF2YWlsYWJs
ZToiCisgICAgICAgICAgICAgICAgICAgICAgICAiIHNlbmRpbmcgQUNQSSBwb3dlciBidXR0
b24gZXZlbnQuXG4iKTsKKyAgICAgICAgICAgICAgICByYyA9IGxpYnhsX3NlbmRfdHJpZ2dl
cihjdHgsIGRvbWlkLCBMSUJYTF9UUklHR0VSX1BPV0VSLCAwKTsKKyAgICAgICAgICAgIH0g
ZWxzZSB7CisgICAgICAgICAgICAgICAgZnByaW50ZihzdGRlcnIsICJQViBjb250cm9sIGlu
dGVyZmFjZSBub3QgYXZhaWxhYmxlOiIKKyAgICAgICAgICAgICAgICAgICAgICAgICIgZXh0
ZXJuYWwgZ3JhY2VmdWwgc2h1dGRvd24gbm90IHBvc3NpYmxlLlxuIik7CisgICAgICAgICAg
ICAgICAgZnByaW50ZihzdGRlcnIsCisgICAgICAgICAgICAgICAgICAgICJVc2UgXCItRlwi
IHRvIGZhbGxiYWNrIHRvIEFDUEkgcG93ZXIgZXZlbnQuXG4iKTsKKyAgICAgICAgICAgIH0K
KyAgICAgICAgfQorICAgICAgICAKKyAgICAgICAgaWYgKHJjKSB7CisgICAgICAgICAgICBm
cHJpbnRmKHN0ZGVyciwic2h1dGRvd24gb2YgZG9tYWluICVkIGZhaWxlZCAocmM9JWQpXG4i
LCBkb21pZCwgcmMpOworICAgICAgICAgICAgcmV0ID0gLTE7CisgICAgICAgICAgICBjb250
aW51ZTsKKyAgICAgICAgfQorCisgICAgICAgIGlmICh3YWl0X2Zvcl9pdCkgeworICAgICAg
ICAgICAgcmMgPSBsaWJ4bF9ldmVuYWJsZV9kb21haW5fZGVhdGgoY3R4LCBkb21pZCwgMCwg
JmRvbWFpbnNfd2FpdF9zaHV0ZG93bltpXSk7CisgICAgICAgICAgICBpZiAocmMpIHsKKyAg
ICAgICAgICAgICAgICBmcHJpbnRmKHN0ZGVyciwid2FpdCBmb3IgZGVhdGggb2YgZG9tYWlu
ICVkIGZhaWxlZCIKKyAgICAgICAgICAgICAgICAgICAgIiAoZXZnZW4sIHJjPSVkKVxuIiwg
ZG9taWQsIHJjKTsKKyAgICAgICAgICAgICAgICByZXQgPSAtMTsKKyAgICAgICAgICAgIH0g
ZWxzZSB7CisgICAgICAgICAgICAgICAgbmJfc2h1dGRvd25fcGVuZGluZysrOworICAgICAg
ICAgICAgfSAKICAgICAgICAgfQotICAgIH0KLSAgICBpZiAocmMpIHsKLSAgICAgICAgZnBy
aW50ZihzdGRlcnIsInNodXRkb3duIGZhaWxlZCAocmM9JWQpXG4iLHJjKTtleGl0KC0xKTsK
ICAgICB9CiAKICAgICBpZiAod2FpdF9mb3JfaXQpIHsKLSAgICAgICAgbGlieGxfZXZnZW5f
ZG9tYWluX2RlYXRoICpkZWF0aHc7CisgICAgICAgIHdoaWxlIChuYl9zaHV0ZG93bl9wZW5k
aW5nID4gMCkgeworICAgICAgICAgICAgbGlieGxfZXZlbnQgKmV2ZW50OworICAgICAgICAg
ICAgcmMgPSBsaWJ4bF9ldmVudF93YWl0KGN0eCwgJmV2ZW50LCBMSUJYTF9FVkVOVE1BU0tf
QUxMLCAwLDApOworICAgICAgICAgICAgaWYgKHJjKSB7CisgICAgICAgICAgICAgICAgTE9H
KCJGYWlsZWQgdG8gZ2V0IGV2ZW50IChyYz0lZCkiLCByYyk7CisgICAgICAgICAgICAgICAg
cmV0dXJuIC0xOworICAgICAgICAgICAgfQogCi0gICAgICAgIHJjID0gbGlieGxfZXZlbmFi
bGVfZG9tYWluX2RlYXRoKGN0eCwgZG9taWQsIDAsICZkZWF0aHcpOwotICAgICAgICBpZiAo
cmMpIHsKLSAgICAgICAgICAgIGZwcmludGYoc3RkZXJyLCJ3YWl0IGZvciBkZWF0aCBmYWls
ZWQgKGV2Z2VuLCByYz0lZClcbiIscmMpOwotICAgICAgICAgICAgZXhpdCgtMSk7Ci0gICAg
ICAgIH0KKyAgICAgICAgICAgIHVpbnQzMl90IGV2ZW50X2RvbWlkID0gZXZlbnQtPmRvbWlk
OworICAgICAgICAgICAgc3dpdGNoIChldmVudC0+dHlwZSkgewogCi0gICAgICAgIGZvciAo
OzspIHsKLSAgICAgICAgICAgIHJjID0gZG9tYWluX3dhaXRfZXZlbnQoZG9taWQsICZldmVu
dCk7Ci0gICAgICAgICAgICBpZiAocmMpIGV4aXQoLTEpOworICAgICAgICAgICAgICAgIGNh
c2UgTElCWExfRVZFTlRfVFlQRV9ET01BSU5fREVBVEg6CisgICAgICAgICAgICAgICAgICAg
IExPRygiRG9tYWluICVkIGhhcyBiZWVuIGRlc3Ryb3llZCIsIGV2ZW50X2RvbWlkKTsKKyAg
ICAgICAgICAgICAgICAgICAgYnJlYWs7CiAKLSAgICAgICAgICAgIHN3aXRjaCAoZXZlbnQt
PnR5cGUpIHsKKyAgICAgICAgICAgICAgICBjYXNlIExJQlhMX0VWRU5UX1RZUEVfRE9NQUlO
X1NIVVRET1dOOgorICAgICAgICAgICAgICAgICAgICBMT0coIkRvbWFpbiAlZCBoYXMgYmVl
biBzaHV0IGRvd24sIHJlYXNvbiBjb2RlICVkICV4IiwKKyAgICAgICAgICAgICAgICAgICAg
ICAgIGV2ZW50X2RvbWlkLAorICAgICAgICAgICAgICAgICAgICAgICAgZXZlbnQtPnUuZG9t
YWluX3NodXRkb3duLnNodXRkb3duX3JlYXNvbiwKKyAgICAgICAgICAgICAgICAgICAgICAg
IGV2ZW50LT51LmRvbWFpbl9zaHV0ZG93bi5zaHV0ZG93bl9yZWFzb24pOworICAgICAgICAg
ICAgICAgICAgICBicmVhazsKIAotICAgICAgICAgICAgY2FzZSBMSUJYTF9FVkVOVF9UWVBF
X0RPTUFJTl9ERUFUSDoKLSAgICAgICAgICAgICAgICBMT0coIkRvbWFpbiAlZCBoYXMgYmVl
biBkZXN0cm95ZWQiLCBkb21pZCk7Ci0gICAgICAgICAgICAgICAgZ290byBkb25lOworICAg
ICAgICAgICAgICAgIGRlZmF1bHQ6CisgICAgICAgICAgICAgICAgICAgIGNvbnRpbnVlOwor
ICAgICAgICAgICAgICAgICAgICBicmVhazsKKyAgICAgICAgICAgIH0KIAotICAgICAgICAg
ICAgY2FzZSBMSUJYTF9FVkVOVF9UWVBFX0RPTUFJTl9TSFVURE9XTjoKLSAgICAgICAgICAg
ICAgICBMT0coIkRvbWFpbiAlZCBoYXMgYmVlbiBzaHV0IGRvd24sIHJlYXNvbiBjb2RlICVk
ICV4IiwgZG9taWQsCi0gICAgICAgICAgICAgICAgICAgIGV2ZW50LT51LmRvbWFpbl9zaHV0
ZG93bi5zaHV0ZG93bl9yZWFzb24sCi0gICAgICAgICAgICAgICAgICAgIGV2ZW50LT51LmRv
bWFpbl9zaHV0ZG93bi5zaHV0ZG93bl9yZWFzb24pOwotICAgICAgICAgICAgICAgIGdvdG8g
ZG9uZTsKKyAgICAgICAgICAgIGZvciAoaSA9IDA7IGkgPCBuYl9kb21haW47IGkrKykgewor
ICAgICAgICAgICAgICAgIGlmICghZG9tYWluc193YWl0X3NodXRkb3duW2ldKQorICAgICAg
ICAgICAgICAgICAgICBjb250aW51ZTsKIAotICAgICAgICAgICAgZGVmYXVsdDoKLSAgICAg
ICAgICAgICAgICBMT0coIlVuZXhwZWN0ZWQgZXZlbnQgdHlwZSAlZCIsIGV2ZW50LT50eXBl
KTsKLSAgICAgICAgICAgICAgICBicmVhazsKKyAgICAgICAgICAgICAgICBpZiAoZG9tYWlu
c193YWl0X3NodXRkb3duW2ldLT5kb21pZCA9PSBldmVudF9kb21pZCl7CisgICAgICAgICAg
ICAgICAgICAgIGxpYnhsX2V2ZGlzYWJsZV9kb21haW5fZGVhdGgoY3R4LCBkb21haW5zX3dh
aXRfc2h1dGRvd25baV0pOworICAgICAgICAgICAgICAgICAgICBkb21haW5zX3dhaXRfc2h1
dGRvd25baV0gPSBOVUxMOworICAgICAgICAgICAgICAgICAgICBuYl9zaHV0ZG93bl9wZW5k
aW5nLS07CisgICAgICAgICAgICAgICAgfQogICAgICAgICAgICAgfQogICAgICAgICAgICAg
bGlieGxfZXZlbnRfZnJlZShjdHgsIGV2ZW50KTsKICAgICAgICAgfQotICAgIGRvbmU6Ci0g
ICAgICAgIGxpYnhsX2V2ZW50X2ZyZWUoY3R4LCBldmVudCk7Ci0gICAgICAgIGxpYnhsX2V2
ZGlzYWJsZV9kb21haW5fZGVhdGgoY3R4LCBkZWF0aHcpOwogICAgIH0KKworICAgIHJldHVy
biByZXQ7CiB9CiAKIHN0YXRpYyB2b2lkIHJlYm9vdF9kb21haW4odWludDMyX3QgZG9taWQs
IGludCBmYWxsYmFja190cmlnZ2VyKQpAQCAtMzY3NiwxNCArMzcwNywyNyBAQCBpbnQgbWFp
bl9kZXN0cm95KGludCBhcmdjLCBjaGFyICoqYXJndikKIAogaW50IG1haW5fc2h1dGRvd24o
aW50IGFyZ2MsIGNoYXIgKiphcmd2KQogeworICAgIGxpYnhsX2RvbWluZm8gZG9taW5mb19i
dWY7CisgICAgbGlieGxfZG9taW5mbyAqZG9taW5mbywgKmRvbWluZm9fZnJlZSA9IE5VTEw7
CisgICAgaW50IG5iX2RvbWFpbiwgcmM7CiAgICAgaW50IG9wdDsKKyAgICBpbnQgb3B0aW9u
X2luZGV4ID0gMDsKKyAgICBpbnQgYWxsID0gMDsKICAgICBpbnQgd2FpdF9mb3JfaXQgPSAw
OwogICAgIGludCBmYWxsYmFja190cmlnZ2VyID0gMDsKKyAgICBzdGF0aWMgc3RydWN0IG9w
dGlvbiBsb25nX29wdGlvbnNbXSA9IHsKKyAgICAgICAgeyJhbGwiLCAwLCAwLCAnYSd9LAor
ICAgICAgICB7IndhaXQiLCAwLCAwLCAndyd9LAorICAgICAgICB7MCwgMCwgMCwgMH0KKyAg
ICB9OwogCi0gICAgd2hpbGUgKChvcHQgPSBkZWZfZ2V0b3B0KGFyZ2MsIGFyZ3YsICJ3RiIs
ICJzaHV0ZG93biIsIDEpKSAhPSAtMSkgeworICAgIHdoaWxlICgob3B0ID0gZ2V0b3B0X2xv
bmcoYXJnYywgYXJndiwgImF3RiIsIGxvbmdfb3B0aW9ucywgJm9wdGlvbl9pbmRleCkpICE9
IC0xKSB7CiAgICAgICAgIHN3aXRjaCAob3B0KSB7CiAgICAgICAgIGNhc2UgMDogY2FzZSAy
OgogICAgICAgICAgICAgcmV0dXJuIG9wdDsKKyAgICAgICAgY2FzZSAnYSc6CisgICAgICAg
ICAgICBhbGwgPSAxOworICAgICAgICAgICAgYnJlYWs7CiAgICAgICAgIGNhc2UgJ3cnOgog
ICAgICAgICAgICAgd2FpdF9mb3JfaXQgPSAxOwogICAgICAgICAgICAgYnJlYWs7CkBAIC0z
NjkzLDggKzM3MzcsNDggQEAgaW50IG1haW5fc2h1dGRvd24oaW50IGFyZ2MsIGNoYXIgKiph
cmd2KQogICAgICAgICB9CiAgICAgfQogCi0gICAgc2h1dGRvd25fZG9tYWluKGZpbmRfZG9t
YWluKGFyZ3Zbb3B0aW5kXSksIHdhaXRfZm9yX2l0LCBmYWxsYmFja190cmlnZ2VyKTsKLSAg
ICByZXR1cm4gMDsKKyAgICBpZiAoIWFyZ3Zbb3B0aW5kXSAmJiAhYWxsKSB7CisgICAgICAg
IGZwcmludGYoc3RkZXJyLCAiWW91IG11c3Qgc3BlY2lmeSAtYSBvciBhIHZhbGlkIGRvbWFp
biBpZC5cblxuIik7CisgICAgICAgIHJldHVybiBvcHQ7CisgICAgfQorCisgICAgaWYgKGFs
bCkgeworICAgICAgICBkb21pbmZvID0gbGlieGxfbGlzdF9kb21haW4oY3R4LCAmbmJfZG9t
YWluKTsKKyAgICAgICAgaWYgKCFkb21pbmZvKSB7CisgICAgICAgICAgICBmcHJpbnRmKHN0
ZGVyciwgImxpYnhsX2RvbWFpbl9pbmZvbGlzdCBmYWlsZWQuXG4iKTsKKyAgICAgICAgICAg
IHJldHVybiAtMTsKKyAgICAgICAgfQorICAgICAgICBkb21pbmZvX2ZyZWUgPSBkb21pbmZv
OworICAgIH0gZWxzZSB7CisgICAgICAgIHVpbnQzMl90IGRvbWlkID0gZmluZF9kb21haW4o
YXJndltvcHRpbmRdKTsKKyAgICAgICAgaWYgKGRvbWlkID09IDApIHsKKyAgICAgICAgICAg
IGZwcmludGYoc3RkZXJyLCAiRXJyb3I6IERvbWFpbi0wIGNhbid0IGJlIHNodXRkb3duIGJ5
IHRoaXMgY29tbWFuZFxuIik7CisgICAgICAgICAgICByZXR1cm4gLTE7CisgICAgICAgIH0K
KworICAgICAgICByYyA9IGxpYnhsX2RvbWFpbl9pbmZvKGN0eCwgJmRvbWluZm9fYnVmLCBk
b21pZCk7CisKKyAgICAgICAgaWYgKHJjID09IEVSUk9SX0lOVkFMKSB7CisgICAgICAgICAg
ICBmcHJpbnRmKHN0ZGVyciwgIkVycm9yOiBEb21haW4gXCclc1wnIGRvZXMgbm90IGV4aXN0
LlxuIiwKKyAgICAgICAgICAgICAgICBhcmd2W29wdGluZF0pOworICAgICAgICAgICAgcmV0
dXJuIC1yYzsKKyAgICAgICAgfQorICAgICAgICBpZiAocmMpIHsKKyAgICAgICAgICAgIGZw
cmludGYoc3RkZXJyLCAibGlieGxfZG9tYWluX2luZm8gZmFpbGVkIChjb2RlICVkKS5cbiIs
IHJjKTsKKyAgICAgICAgICAgIHJldHVybiAtcmM7CisgICAgICAgIH0KKyAgICAgICAgZG9t
aW5mbyA9ICZkb21pbmZvX2J1ZjsKKyAgICAgICAgbmJfZG9tYWluID0gMTsKKyAgICB9CisK
KyAgICByYyA9IHNodXRkb3duX2RvbWFpbihkb21pbmZvLCBuYl9kb21haW4sIHdhaXRfZm9y
X2l0LCBmYWxsYmFja190cmlnZ2VyKTsKKworICAgIGlmIChkb21pbmZvX2ZyZWUpCisgICAg
ICAgIGxpYnhsX2RvbWluZm9fbGlzdF9mcmVlKGRvbWluZm9fZnJlZSwgbmJfZG9tYWluKTsK
KyAgICBlbHNlCisgICAgICAgIGxpYnhsX2RvbWluZm9fZGlzcG9zZShkb21pbmZvKTsKKwor
ICAgIHJldHVybiAtcmM7CiB9CiAKIGludCBtYWluX3JlYm9vdChpbnQgYXJnYywgY2hhciAq
KmFyZ3YpCg==
------------10B1260E631D4699E
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

------------10B1260E631D4699E--



From xen-devel-bounces@lists.xen.org Thu Sep 27 21:29:16 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Sep 2012 21:29: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 1THLdW-0006wA-Bs; Thu, 27 Sep 2012 21:28:46 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olivier.hanesse@gmail.com>)
	id 1THLdU-0006w1-Tw; Thu, 27 Sep 2012 21:28:45 +0000
X-Env-Sender: olivier.hanesse@gmail.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1348781316!7098834!1
X-Originating-IP: [209.85.214.171]
X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7762 invoked from network); 27 Sep 2012 21:28:38 -0000
Received: from mail-ob0-f171.google.com (HELO mail-ob0-f171.google.com)
	(209.85.214.171)
	by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Sep 2012 21:28:38 -0000
Received: by obc16 with SMTP id 16so3280606obc.30
	for <multiple recipients>; Thu, 27 Sep 2012 14:28: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=QsUEQU6eWE3foUSYZ5Mnkj/D3HBa5PfMvRxRhzmQ6Ik=;
	b=bK+i0ldB/TojOOxfTEc2ZWXxb0rO8U3pN2sT1Bf3Zc3OnSeaWNgISX0jAXK79ypK9+
	WiFfjbUnj/cxYAkVu0moqhXraZWZhJMzOsWGbxs6DiAr048uAjwtNbl3iaOc5hyead1S
	tWk7bNhLPau7pHSQ12rOfkAxv2iooI9Go7DBGx5LYEG61N6Ew8ik2CWzLBusEzGjp2Gu
	URihTDOmVXcvqrBrAy+9o9EDOMG/lpiK5ohDy95B6vG9racKoe/uXX69Vl4aYyPvXdq8
	0JJsvX5nBOJTY250Ju2Ol6h8WBO7TUrdMOm9tQYVoTx2u76DlsBDaOE7UtvBR9l6udEQ
	IqZw==
MIME-Version: 1.0
Received: by 10.60.7.36 with SMTP id g4mr4217300oea.112.1348781316158; Thu, 27
	Sep 2012 14:28:36 -0700 (PDT)
Received: by 10.76.33.199 with HTTP; Thu, 27 Sep 2012 14:28:36 -0700 (PDT)
In-Reply-To: <65395f62-74e5-4910-b701-8df629c2ce3b@default>
References: <68c41dd8-9195-41b0-83d7-9242b8eff809@default>
	<AANLkTi=NFebVsnj_09+SpCZUo_bNTnTyJLAoR5sfbwZa@mail.gmail.com>
	<AANLkTikptc2POrKQgJuoVZRdwJTo64DJ_hm12KuPky4D@mail.gmail.com>
	<b1ca6ddc-ca69-447e-93e9-8d36d1ff4a43@default>
	<AANLkTinK94GDOF_GeaVs50wK0u8EdZ2rtzPuh65ca8qR@mail.gmail.com>
	<CAE17a0UPyzsNn=ps9MxarkGg=ns8dCpVz0qBDvesT2AOskwfVg@mail.gmail.com>
	<65395f62-74e5-4910-b701-8df629c2ce3b@default>
Date: Thu, 27 Sep 2012 23:28:36 +0200
Message-ID: <CABx4GKrQxOOQo_uUXSFvy0nzdMp1A_qc=_e4K+88GkB7xv=9nw@mail.gmail.com>
From: Olivier Hanesse <olivier.hanesse@gmail.com>
To: Dan Magenheimer <dan.magenheimer@oracle.com>
Cc: Jeremy Fitzhardinge <jeremy@goop.org>, xen-devel@lists.xensource.com,
	Keir Fraser <keir@xen.org>, Keir Fraser <keir.xen@gmail.com>,
	Mauro <mrsanna1@gmail.com>, Xen Users <xen-users@lists.xensource.com>,
	Mark Adams <mark@campbell-lange.net>
Subject: Re: [Xen-devel] [Xen-users] Re:  Xen 4 TSC problems
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1496806874817463489=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============1496806874817463489==
Content-Type: multipart/alternative; boundary=e89a8f64347c3ab36704cab59f37

--e89a8f64347c3ab36704cab59f37
Content-Type: text/plain; charset=ISO-8859-1

Hello,

>From my point of view, this was a kind of xen hardware
"incompatibility/bug" : I was able to reproduce this bug on more than 50
identical servers, but not on another farm of servers with a different
hardware.
Xen version, Debian Kernel was exactly the same on both farm.

Regards

Olivier

2012/9/27 Dan Magenheimer <dan.magenheimer@oracle.com>

> > From: Mauro [mailto:mrsanna1@gmail.com]
> > Sent: Thursday, September 27, 2012 9:55 AM
> > To: Olivier Hanesse
> > Cc: Dan Magenheimer; Jeremy Fitzhardinge; xen-devel@lists.xensource.com;
> Keir Fraser; Jan Beulich;
> > Keir Fraser; Xen Users; Mark Adams
> > Subject: Re: [Xen-users] Re: [Xen-devel] Xen 4 TSC problems
> >
> > On 28 February 2011 16:54, Olivier Hanesse <olivier.hanesse@gmail.com>
> wrote:
> > > Yes this is what I mean.
> > > I am glad to hear that it isn't a bad sign :)
> > > I thought of a bad sign, because on system with "reliable TSC", this
> counter
> > > is always 0.
> >
> > Hey men.
> > I have exactly the same problem.
> > I have two cluster nodes.
> > Server are two HP Proliant DL 580 G4 with four Quad Core Intel(R)
> > Xeon(R) CPU E7330  @ 2.40GHz.
> > I'm running debian squeeze in dom0s end domUs.
>
> Hi Mauro --
>
> There's been a lot of work on clocks since 4.0 (by other Xen developers,
> not me).  I don't think this specific problem was ever reproduced
> by a developer so I don't think anyone knows if it has been
> already fixed or not, nor are there any plans to backport all the
> timer work to 4.0.
>
> You might try upgrading your Xen hypervisor to the just-released
> Xen 4.2 [1] and see if the problem goes away.  If the problem still
> exists in 4.2, it may be easier to get some developer to pay attention
> to it.  It may be specific hardware or processors or power
> management or firmware or even dom0 kernel, so the first thing
> to do is try later hypervisor bits.
>
> Sorry I can't be more helpful.  Good luck!
>
> Dan
>
> [1] Sorry, I'm not familiar with the 4.0->4.2 upgrade process
> so you may want to confirm with others.
>
> > xm info:
> >
> > host                   : xen-p01
> > release                : 2.6.32-5-xen-amd64
> > version                : #1 SMP Sun May 6 08:57:29 UTC 2012
> > machine                : x86_64
> > nr_cpus                : 16
> > nr_nodes               : 1
> > cores_per_socket       : 4
> > threads_per_core       : 1
> > cpu_mhz                : 2400
> > hw_caps                :
> > bfebfbff:20100800:00000000:00000940:0004e3bd:00000000:00000001:00000000
> > virt_caps              : hvm
> > total_memory           : 65532
> > free_memory            : 40317
> > node_to_cpu            : node0:0-15
> > node_to_memory         : node0:40317
> > node_to_dma32_mem      : node0:3256
> > max_node_id            : 0
> > xen_major              : 4
> > xen_minor              : 0
> > xen_extra              : .1
> > xen_caps               : xen-3.0-x86_64 xen-3.0-x86_32p hvm-3.0-x86_32
> > hvm-3.0-x86_32p hvm-3.0-x86_64
> > xen_scheduler          : credit
> > xen_pagesize           : 4096
> > platform_params        : virt_start=0xffff800000000000
> > xen_changeset          : unavailable
> > xen_commandline        : placeholder dom0_mem=3072M loglvl=warning
> > guest_loglvl=warning
> > cc_compiler            : gcc version 4.4.5 (Debian 4.4.5-8)
> > cc_compile_by          : ultrotter
> > cc_compile_domain      : debian.org
> > cc_compile_date        : Sat Sep  8 19:15:46 UTC 2012
> > xend_config_format     : 4
> >
> > I'm experiencing weekly a clock jump ahead of about 50 minutes on dom0.
> > I'm seriously in trouble because it cause every time a reboot of one
> > of the two nodes clusters.
>

--e89a8f64347c3ab36704cab59f37
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hello,=A0<div><br></div><div>From my point of view, this was a kind of xen =
hardware &quot;incompatibility/bug&quot; : I was able to reproduce this bug=
 on more than 50 identical servers, but not on another farm of servers with=
 a different hardware.</div>
<div>Xen version, Debian Kernel was exactly the same on both farm.</div><di=
v><br>Regards</div><div><br></div><div>Olivier</div><div><br></div><div><di=
v class=3D"gmail_quote">2012/9/27 Dan Magenheimer <span dir=3D"ltr">&lt;<a =
href=3D"mailto:dan.magenheimer@oracle.com" target=3D"_blank">dan.magenheime=
r@oracle.com</a>&gt;</span><br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">&gt; From: Mauro [mailto:<a href=3D"mailto:m=
rsanna1@gmail.com">mrsanna1@gmail.com</a>]<br>
&gt; Sent: Thursday, September 27, 2012 9:55 AM<br>
&gt; To: Olivier Hanesse<br>
&gt; Cc: Dan Magenheimer; Jeremy Fitzhardinge; <a href=3D"mailto:xen-devel@=
lists.xensource.com">xen-devel@lists.xensource.com</a>; Keir Fraser; Jan Be=
ulich;<br>
&gt; Keir Fraser; Xen Users; Mark Adams<br>
&gt; Subject: Re: [Xen-users] Re: [Xen-devel] Xen 4 TSC problems<br>
<div class=3D"im">&gt;<br>
&gt; On 28 February 2011 16:54, Olivier Hanesse &lt;<a href=3D"mailto:olivi=
er.hanesse@gmail.com">olivier.hanesse@gmail.com</a>&gt; wrote:<br>
&gt; &gt; Yes this is what I mean.<br>
&gt; &gt; I am glad to hear that it isn&#39;t a bad sign :)<br>
&gt; &gt; I thought of a bad sign, because on system with &quot;reliable TS=
C&quot;, this counter<br>
&gt; &gt; is always 0.<br>
&gt;<br>
&gt; Hey men.<br>
&gt; I have exactly the same problem.<br>
&gt; I have two cluster nodes.<br>
&gt; Server are two HP Proliant DL 580 G4 with four Quad Core Intel(R)<br>
&gt; Xeon(R) CPU E7330 =A0@ 2.40GHz.<br>
&gt; I&#39;m running debian squeeze in dom0s end domUs.<br>
<br>
</div>Hi Mauro --<br>
<br>
There&#39;s been a lot of work on clocks since 4.0 (by other Xen developers=
,<br>
not me). =A0I don&#39;t think this specific problem was ever reproduced<br>
by a developer so I don&#39;t think anyone knows if it has been<br>
already fixed or not, nor are there any plans to backport all the<br>
timer work to 4.0.<br>
<br>
You might try upgrading your Xen hypervisor to the just-released<br>
Xen 4.2 [1] and see if the problem goes away. =A0If the problem still<br>
exists in 4.2, it may be easier to get some developer to pay attention<br>
to it. =A0It may be specific hardware or processors or power<br>
management or firmware or even dom0 kernel, so the first thing<br>
to do is try later hypervisor bits.<br>
<br>
Sorry I can&#39;t be more helpful. =A0Good luck!<br>
<br>
Dan<br>
<br>
[1] Sorry, I&#39;m not familiar with the 4.0-&gt;4.2 upgrade process<br>
so you may want to confirm with others.<br>
<div class=3D"HOEnZb"><div class=3D"h5"><br>
&gt; xm info:<br>
&gt;<br>
&gt; host =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 : xen-p01<br>
&gt; release =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0: 2.6.32-5-xen-amd64<br>
&gt; version =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0: #1 SMP Sun May 6 08:57:29 UTC=
 2012<br>
&gt; machine =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0: x86_64<br>
&gt; nr_cpus =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0: 16<br>
&gt; nr_nodes =A0 =A0 =A0 =A0 =A0 =A0 =A0 : 1<br>
&gt; cores_per_socket =A0 =A0 =A0 : 4<br>
&gt; threads_per_core =A0 =A0 =A0 : 1<br>
&gt; cpu_mhz =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0: 2400<br>
&gt; hw_caps =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0:<br>
&gt; bfebfbff:20100800:00000000:00000940:0004e3bd:00000000:00000001:0000000=
0<br>
&gt; virt_caps =A0 =A0 =A0 =A0 =A0 =A0 =A0: hvm<br>
&gt; total_memory =A0 =A0 =A0 =A0 =A0 : 65532<br>
&gt; free_memory =A0 =A0 =A0 =A0 =A0 =A0: 40317<br>
&gt; node_to_cpu =A0 =A0 =A0 =A0 =A0 =A0: node0:0-15<br>
&gt; node_to_memory =A0 =A0 =A0 =A0 : node0:40317<br>
&gt; node_to_dma32_mem =A0 =A0 =A0: node0:3256<br>
&gt; max_node_id =A0 =A0 =A0 =A0 =A0 =A0: 0<br>
&gt; xen_major =A0 =A0 =A0 =A0 =A0 =A0 =A0: 4<br>
&gt; xen_minor =A0 =A0 =A0 =A0 =A0 =A0 =A0: 0<br>
&gt; xen_extra =A0 =A0 =A0 =A0 =A0 =A0 =A0: .1<br>
&gt; xen_caps =A0 =A0 =A0 =A0 =A0 =A0 =A0 : xen-3.0-x86_64 xen-3.0-x86_32p =
hvm-3.0-x86_32<br>
&gt; hvm-3.0-x86_32p hvm-3.0-x86_64<br>
&gt; xen_scheduler =A0 =A0 =A0 =A0 =A0: credit<br>
&gt; xen_pagesize =A0 =A0 =A0 =A0 =A0 : 4096<br>
&gt; platform_params =A0 =A0 =A0 =A0: virt_start=3D0xffff800000000000<br>
&gt; xen_changeset =A0 =A0 =A0 =A0 =A0: unavailable<br>
&gt; xen_commandline =A0 =A0 =A0 =A0: placeholder dom0_mem=3D3072M loglvl=
=3Dwarning<br>
&gt; guest_loglvl=3Dwarning<br>
&gt; cc_compiler =A0 =A0 =A0 =A0 =A0 =A0: gcc version 4.4.5 (Debian 4.4.5-8=
)<br>
&gt; cc_compile_by =A0 =A0 =A0 =A0 =A0: ultrotter<br>
&gt; cc_compile_domain =A0 =A0 =A0: <a href=3D"http://debian.org" target=3D=
"_blank">debian.org</a><br>
&gt; cc_compile_date =A0 =A0 =A0 =A0: Sat Sep =A08 19:15:46 UTC 2012<br>
&gt; xend_config_format =A0 =A0 : 4<br>
&gt;<br>
&gt; I&#39;m experiencing weekly a clock jump ahead of about 50 minutes on =
dom0.<br>
&gt; I&#39;m seriously in trouble because it cause every time a reboot of o=
ne<br>
&gt; of the two nodes clusters.<br>
</div></div></blockquote></div><br></div>

--e89a8f64347c3ab36704cab59f37--


--===============1496806874817463489==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============1496806874817463489==--


From xen-devel-bounces@lists.xen.org Thu Sep 27 21:29:16 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Sep 2012 21:29: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 1THLdW-0006wA-Bs; Thu, 27 Sep 2012 21:28:46 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olivier.hanesse@gmail.com>)
	id 1THLdU-0006w1-Tw; Thu, 27 Sep 2012 21:28:45 +0000
X-Env-Sender: olivier.hanesse@gmail.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1348781316!7098834!1
X-Originating-IP: [209.85.214.171]
X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7762 invoked from network); 27 Sep 2012 21:28:38 -0000
Received: from mail-ob0-f171.google.com (HELO mail-ob0-f171.google.com)
	(209.85.214.171)
	by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Sep 2012 21:28:38 -0000
Received: by obc16 with SMTP id 16so3280606obc.30
	for <multiple recipients>; Thu, 27 Sep 2012 14:28: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=QsUEQU6eWE3foUSYZ5Mnkj/D3HBa5PfMvRxRhzmQ6Ik=;
	b=bK+i0ldB/TojOOxfTEc2ZWXxb0rO8U3pN2sT1Bf3Zc3OnSeaWNgISX0jAXK79ypK9+
	WiFfjbUnj/cxYAkVu0moqhXraZWZhJMzOsWGbxs6DiAr048uAjwtNbl3iaOc5hyead1S
	tWk7bNhLPau7pHSQ12rOfkAxv2iooI9Go7DBGx5LYEG61N6Ew8ik2CWzLBusEzGjp2Gu
	URihTDOmVXcvqrBrAy+9o9EDOMG/lpiK5ohDy95B6vG9racKoe/uXX69Vl4aYyPvXdq8
	0JJsvX5nBOJTY250Ju2Ol6h8WBO7TUrdMOm9tQYVoTx2u76DlsBDaOE7UtvBR9l6udEQ
	IqZw==
MIME-Version: 1.0
Received: by 10.60.7.36 with SMTP id g4mr4217300oea.112.1348781316158; Thu, 27
	Sep 2012 14:28:36 -0700 (PDT)
Received: by 10.76.33.199 with HTTP; Thu, 27 Sep 2012 14:28:36 -0700 (PDT)
In-Reply-To: <65395f62-74e5-4910-b701-8df629c2ce3b@default>
References: <68c41dd8-9195-41b0-83d7-9242b8eff809@default>
	<AANLkTi=NFebVsnj_09+SpCZUo_bNTnTyJLAoR5sfbwZa@mail.gmail.com>
	<AANLkTikptc2POrKQgJuoVZRdwJTo64DJ_hm12KuPky4D@mail.gmail.com>
	<b1ca6ddc-ca69-447e-93e9-8d36d1ff4a43@default>
	<AANLkTinK94GDOF_GeaVs50wK0u8EdZ2rtzPuh65ca8qR@mail.gmail.com>
	<CAE17a0UPyzsNn=ps9MxarkGg=ns8dCpVz0qBDvesT2AOskwfVg@mail.gmail.com>
	<65395f62-74e5-4910-b701-8df629c2ce3b@default>
Date: Thu, 27 Sep 2012 23:28:36 +0200
Message-ID: <CABx4GKrQxOOQo_uUXSFvy0nzdMp1A_qc=_e4K+88GkB7xv=9nw@mail.gmail.com>
From: Olivier Hanesse <olivier.hanesse@gmail.com>
To: Dan Magenheimer <dan.magenheimer@oracle.com>
Cc: Jeremy Fitzhardinge <jeremy@goop.org>, xen-devel@lists.xensource.com,
	Keir Fraser <keir@xen.org>, Keir Fraser <keir.xen@gmail.com>,
	Mauro <mrsanna1@gmail.com>, Xen Users <xen-users@lists.xensource.com>,
	Mark Adams <mark@campbell-lange.net>
Subject: Re: [Xen-devel] [Xen-users] Re:  Xen 4 TSC problems
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1496806874817463489=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============1496806874817463489==
Content-Type: multipart/alternative; boundary=e89a8f64347c3ab36704cab59f37

--e89a8f64347c3ab36704cab59f37
Content-Type: text/plain; charset=ISO-8859-1

Hello,

>From my point of view, this was a kind of xen hardware
"incompatibility/bug" : I was able to reproduce this bug on more than 50
identical servers, but not on another farm of servers with a different
hardware.
Xen version, Debian Kernel was exactly the same on both farm.

Regards

Olivier

2012/9/27 Dan Magenheimer <dan.magenheimer@oracle.com>

> > From: Mauro [mailto:mrsanna1@gmail.com]
> > Sent: Thursday, September 27, 2012 9:55 AM
> > To: Olivier Hanesse
> > Cc: Dan Magenheimer; Jeremy Fitzhardinge; xen-devel@lists.xensource.com;
> Keir Fraser; Jan Beulich;
> > Keir Fraser; Xen Users; Mark Adams
> > Subject: Re: [Xen-users] Re: [Xen-devel] Xen 4 TSC problems
> >
> > On 28 February 2011 16:54, Olivier Hanesse <olivier.hanesse@gmail.com>
> wrote:
> > > Yes this is what I mean.
> > > I am glad to hear that it isn't a bad sign :)
> > > I thought of a bad sign, because on system with "reliable TSC", this
> counter
> > > is always 0.
> >
> > Hey men.
> > I have exactly the same problem.
> > I have two cluster nodes.
> > Server are two HP Proliant DL 580 G4 with four Quad Core Intel(R)
> > Xeon(R) CPU E7330  @ 2.40GHz.
> > I'm running debian squeeze in dom0s end domUs.
>
> Hi Mauro --
>
> There's been a lot of work on clocks since 4.0 (by other Xen developers,
> not me).  I don't think this specific problem was ever reproduced
> by a developer so I don't think anyone knows if it has been
> already fixed or not, nor are there any plans to backport all the
> timer work to 4.0.
>
> You might try upgrading your Xen hypervisor to the just-released
> Xen 4.2 [1] and see if the problem goes away.  If the problem still
> exists in 4.2, it may be easier to get some developer to pay attention
> to it.  It may be specific hardware or processors or power
> management or firmware or even dom0 kernel, so the first thing
> to do is try later hypervisor bits.
>
> Sorry I can't be more helpful.  Good luck!
>
> Dan
>
> [1] Sorry, I'm not familiar with the 4.0->4.2 upgrade process
> so you may want to confirm with others.
>
> > xm info:
> >
> > host                   : xen-p01
> > release                : 2.6.32-5-xen-amd64
> > version                : #1 SMP Sun May 6 08:57:29 UTC 2012
> > machine                : x86_64
> > nr_cpus                : 16
> > nr_nodes               : 1
> > cores_per_socket       : 4
> > threads_per_core       : 1
> > cpu_mhz                : 2400
> > hw_caps                :
> > bfebfbff:20100800:00000000:00000940:0004e3bd:00000000:00000001:00000000
> > virt_caps              : hvm
> > total_memory           : 65532
> > free_memory            : 40317
> > node_to_cpu            : node0:0-15
> > node_to_memory         : node0:40317
> > node_to_dma32_mem      : node0:3256
> > max_node_id            : 0
> > xen_major              : 4
> > xen_minor              : 0
> > xen_extra              : .1
> > xen_caps               : xen-3.0-x86_64 xen-3.0-x86_32p hvm-3.0-x86_32
> > hvm-3.0-x86_32p hvm-3.0-x86_64
> > xen_scheduler          : credit
> > xen_pagesize           : 4096
> > platform_params        : virt_start=0xffff800000000000
> > xen_changeset          : unavailable
> > xen_commandline        : placeholder dom0_mem=3072M loglvl=warning
> > guest_loglvl=warning
> > cc_compiler            : gcc version 4.4.5 (Debian 4.4.5-8)
> > cc_compile_by          : ultrotter
> > cc_compile_domain      : debian.org
> > cc_compile_date        : Sat Sep  8 19:15:46 UTC 2012
> > xend_config_format     : 4
> >
> > I'm experiencing weekly a clock jump ahead of about 50 minutes on dom0.
> > I'm seriously in trouble because it cause every time a reboot of one
> > of the two nodes clusters.
>

--e89a8f64347c3ab36704cab59f37
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hello,=A0<div><br></div><div>From my point of view, this was a kind of xen =
hardware &quot;incompatibility/bug&quot; : I was able to reproduce this bug=
 on more than 50 identical servers, but not on another farm of servers with=
 a different hardware.</div>
<div>Xen version, Debian Kernel was exactly the same on both farm.</div><di=
v><br>Regards</div><div><br></div><div>Olivier</div><div><br></div><div><di=
v class=3D"gmail_quote">2012/9/27 Dan Magenheimer <span dir=3D"ltr">&lt;<a =
href=3D"mailto:dan.magenheimer@oracle.com" target=3D"_blank">dan.magenheime=
r@oracle.com</a>&gt;</span><br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">&gt; From: Mauro [mailto:<a href=3D"mailto:m=
rsanna1@gmail.com">mrsanna1@gmail.com</a>]<br>
&gt; Sent: Thursday, September 27, 2012 9:55 AM<br>
&gt; To: Olivier Hanesse<br>
&gt; Cc: Dan Magenheimer; Jeremy Fitzhardinge; <a href=3D"mailto:xen-devel@=
lists.xensource.com">xen-devel@lists.xensource.com</a>; Keir Fraser; Jan Be=
ulich;<br>
&gt; Keir Fraser; Xen Users; Mark Adams<br>
&gt; Subject: Re: [Xen-users] Re: [Xen-devel] Xen 4 TSC problems<br>
<div class=3D"im">&gt;<br>
&gt; On 28 February 2011 16:54, Olivier Hanesse &lt;<a href=3D"mailto:olivi=
er.hanesse@gmail.com">olivier.hanesse@gmail.com</a>&gt; wrote:<br>
&gt; &gt; Yes this is what I mean.<br>
&gt; &gt; I am glad to hear that it isn&#39;t a bad sign :)<br>
&gt; &gt; I thought of a bad sign, because on system with &quot;reliable TS=
C&quot;, this counter<br>
&gt; &gt; is always 0.<br>
&gt;<br>
&gt; Hey men.<br>
&gt; I have exactly the same problem.<br>
&gt; I have two cluster nodes.<br>
&gt; Server are two HP Proliant DL 580 G4 with four Quad Core Intel(R)<br>
&gt; Xeon(R) CPU E7330 =A0@ 2.40GHz.<br>
&gt; I&#39;m running debian squeeze in dom0s end domUs.<br>
<br>
</div>Hi Mauro --<br>
<br>
There&#39;s been a lot of work on clocks since 4.0 (by other Xen developers=
,<br>
not me). =A0I don&#39;t think this specific problem was ever reproduced<br>
by a developer so I don&#39;t think anyone knows if it has been<br>
already fixed or not, nor are there any plans to backport all the<br>
timer work to 4.0.<br>
<br>
You might try upgrading your Xen hypervisor to the just-released<br>
Xen 4.2 [1] and see if the problem goes away. =A0If the problem still<br>
exists in 4.2, it may be easier to get some developer to pay attention<br>
to it. =A0It may be specific hardware or processors or power<br>
management or firmware or even dom0 kernel, so the first thing<br>
to do is try later hypervisor bits.<br>
<br>
Sorry I can&#39;t be more helpful. =A0Good luck!<br>
<br>
Dan<br>
<br>
[1] Sorry, I&#39;m not familiar with the 4.0-&gt;4.2 upgrade process<br>
so you may want to confirm with others.<br>
<div class=3D"HOEnZb"><div class=3D"h5"><br>
&gt; xm info:<br>
&gt;<br>
&gt; host =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 : xen-p01<br>
&gt; release =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0: 2.6.32-5-xen-amd64<br>
&gt; version =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0: #1 SMP Sun May 6 08:57:29 UTC=
 2012<br>
&gt; machine =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0: x86_64<br>
&gt; nr_cpus =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0: 16<br>
&gt; nr_nodes =A0 =A0 =A0 =A0 =A0 =A0 =A0 : 1<br>
&gt; cores_per_socket =A0 =A0 =A0 : 4<br>
&gt; threads_per_core =A0 =A0 =A0 : 1<br>
&gt; cpu_mhz =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0: 2400<br>
&gt; hw_caps =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0:<br>
&gt; bfebfbff:20100800:00000000:00000940:0004e3bd:00000000:00000001:0000000=
0<br>
&gt; virt_caps =A0 =A0 =A0 =A0 =A0 =A0 =A0: hvm<br>
&gt; total_memory =A0 =A0 =A0 =A0 =A0 : 65532<br>
&gt; free_memory =A0 =A0 =A0 =A0 =A0 =A0: 40317<br>
&gt; node_to_cpu =A0 =A0 =A0 =A0 =A0 =A0: node0:0-15<br>
&gt; node_to_memory =A0 =A0 =A0 =A0 : node0:40317<br>
&gt; node_to_dma32_mem =A0 =A0 =A0: node0:3256<br>
&gt; max_node_id =A0 =A0 =A0 =A0 =A0 =A0: 0<br>
&gt; xen_major =A0 =A0 =A0 =A0 =A0 =A0 =A0: 4<br>
&gt; xen_minor =A0 =A0 =A0 =A0 =A0 =A0 =A0: 0<br>
&gt; xen_extra =A0 =A0 =A0 =A0 =A0 =A0 =A0: .1<br>
&gt; xen_caps =A0 =A0 =A0 =A0 =A0 =A0 =A0 : xen-3.0-x86_64 xen-3.0-x86_32p =
hvm-3.0-x86_32<br>
&gt; hvm-3.0-x86_32p hvm-3.0-x86_64<br>
&gt; xen_scheduler =A0 =A0 =A0 =A0 =A0: credit<br>
&gt; xen_pagesize =A0 =A0 =A0 =A0 =A0 : 4096<br>
&gt; platform_params =A0 =A0 =A0 =A0: virt_start=3D0xffff800000000000<br>
&gt; xen_changeset =A0 =A0 =A0 =A0 =A0: unavailable<br>
&gt; xen_commandline =A0 =A0 =A0 =A0: placeholder dom0_mem=3D3072M loglvl=
=3Dwarning<br>
&gt; guest_loglvl=3Dwarning<br>
&gt; cc_compiler =A0 =A0 =A0 =A0 =A0 =A0: gcc version 4.4.5 (Debian 4.4.5-8=
)<br>
&gt; cc_compile_by =A0 =A0 =A0 =A0 =A0: ultrotter<br>
&gt; cc_compile_domain =A0 =A0 =A0: <a href=3D"http://debian.org" target=3D=
"_blank">debian.org</a><br>
&gt; cc_compile_date =A0 =A0 =A0 =A0: Sat Sep =A08 19:15:46 UTC 2012<br>
&gt; xend_config_format =A0 =A0 : 4<br>
&gt;<br>
&gt; I&#39;m experiencing weekly a clock jump ahead of about 50 minutes on =
dom0.<br>
&gt; I&#39;m seriously in trouble because it cause every time a reboot of o=
ne<br>
&gt; of the two nodes clusters.<br>
</div></div></blockquote></div><br></div>

--e89a8f64347c3ab36704cab59f37--


--===============1496806874817463489==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============1496806874817463489==--


From xen-devel-bounces@lists.xen.org Thu Sep 27 22:05:33 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Sep 2012 22: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 1THMCd-0007bu-MD; Thu, 27 Sep 2012 22:05:03 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mrsanna1@gmail.com>) id 1THLqR-0007Bf-LF
	for xen-devel@lists.xensource.com; Thu, 27 Sep 2012 21:42:07 +0000
Received: from [85.158.139.211:19125] by server-14.bemta-5.messagelabs.com id
	3D/0B-05772-E28C4605; Thu, 27 Sep 2012 21:42:06 +0000
X-Env-Sender: mrsanna1@gmail.com
X-Msg-Ref: server-13.tower-206.messagelabs.com!1348782125!16262943!1
X-Originating-IP: [209.85.220.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5354 invoked from network); 27 Sep 2012 21:42:06 -0000
Received: from mail-vc0-f171.google.com (HELO mail-vc0-f171.google.com)
	(209.85.220.171)
	by server-13.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Sep 2012 21:42:06 -0000
Received: by vcmm18 with SMTP id m18so3275070vcm.30
	for <multiple recipients>; Thu, 27 Sep 2012 14:42:05 -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=6u/CWOMDIWFn0pMcOa4MFkHslWKhQfUNGeq/2jWGYow=;
	b=X5i1JQjQjSS5mZ+qRPViXSafcjDVH64K73F+C/grHojoZp8nkmb7mbJpPuI5gf3hBt
	OS+BupUGGK3UypUKcTIl6MARFwSNAIZmJfpx/x4GS3Wg6KqV6jB8PGqJUEGYfgfDGiQq
	hw6U8qupdbvFNf60oaMoI+aARyFkUi/dBmMNr0g3UGobR5oAv+7NSv6bCrHpUjTztbe4
	xwU6kK0THVh6k2vkaZ6XlDzwykfwv+0cKnG7DWE8GLU+gnM9FcwnHxI3X4asunx2uIIa
	z6BzJ8BeT4W8ubcd68nYcCmMEN0L6ud90oNqF0t0F7909GXEuSIExPnLLFv7Oa24yDKg
	krSw==
MIME-Version: 1.0
Received: by 10.220.116.9 with SMTP id k9mr2991072vcq.0.1348782125006; Thu, 27
	Sep 2012 14:42:05 -0700 (PDT)
Received: by 10.58.207.75 with HTTP; Thu, 27 Sep 2012 14:42:04 -0700 (PDT)
In-Reply-To: <CABx4GKrQxOOQo_uUXSFvy0nzdMp1A_qc=_e4K+88GkB7xv=9nw@mail.gmail.com>
References: <68c41dd8-9195-41b0-83d7-9242b8eff809@default>
	<AANLkTi=NFebVsnj_09+SpCZUo_bNTnTyJLAoR5sfbwZa@mail.gmail.com>
	<AANLkTikptc2POrKQgJuoVZRdwJTo64DJ_hm12KuPky4D@mail.gmail.com>
	<b1ca6ddc-ca69-447e-93e9-8d36d1ff4a43@default>
	<AANLkTinK94GDOF_GeaVs50wK0u8EdZ2rtzPuh65ca8qR@mail.gmail.com>
	<CAE17a0UPyzsNn=ps9MxarkGg=ns8dCpVz0qBDvesT2AOskwfVg@mail.gmail.com>
	<65395f62-74e5-4910-b701-8df629c2ce3b@default>
	<CABx4GKrQxOOQo_uUXSFvy0nzdMp1A_qc=_e4K+88GkB7xv=9nw@mail.gmail.com>
Date: Thu, 27 Sep 2012 23:42:04 +0200
Message-ID: <CAE17a0VkMuUEG9VaM7AFrwcsEjVBq9RfvTWz1_KmscAyCxeAbA@mail.gmail.com>
From: Mauro <mrsanna1@gmail.com>
To: Olivier Hanesse <olivier.hanesse@gmail.com>
X-Mailman-Approved-At: Thu, 27 Sep 2012 22:05:02 +0000
Cc: Dan Magenheimer <dan.magenheimer@oracle.com>, xen-devel@lists.xensource.com,
	Keir Fraser <keir@xen.org>, Jeremy Fitzhardinge <jeremy@goop.org>,
	Keir Fraser <keir.xen@gmail.com>,
	Xen Users <xen-users@lists.xensource.com>,
	Mark Adams <mark@campbell-lange.net>
Subject: Re: [Xen-devel] [Xen-users] Re:  Xen 4 TSC problems
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 27 September 2012 23:28, Olivier Hanesse <olivier.hanesse@gmail.com> wrote:
> Hello,
>
> From my point of view, this was a kind of xen hardware "incompatibility/bug"
> : I was able to reproduce this bug on more than 50 identical servers, but
> not on another farm of servers with a different hardware.
> Xen version, Debian Kernel was exactly the same on both farm.

Yes I think so.
The problem is where I use debian squeeze with xen 4.0.
In another server with the same hardware but with debian lenny and xen
3.0 I have no problems.
I've read that a workaround is to set clocksource=pit on the xen boot
line in the grub conf, I hope this works because I can't change hardware.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 27 22:05:33 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Sep 2012 22: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 1THMCd-0007bu-MD; Thu, 27 Sep 2012 22:05:03 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mrsanna1@gmail.com>) id 1THLqR-0007Bf-LF
	for xen-devel@lists.xensource.com; Thu, 27 Sep 2012 21:42:07 +0000
Received: from [85.158.139.211:19125] by server-14.bemta-5.messagelabs.com id
	3D/0B-05772-E28C4605; Thu, 27 Sep 2012 21:42:06 +0000
X-Env-Sender: mrsanna1@gmail.com
X-Msg-Ref: server-13.tower-206.messagelabs.com!1348782125!16262943!1
X-Originating-IP: [209.85.220.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5354 invoked from network); 27 Sep 2012 21:42:06 -0000
Received: from mail-vc0-f171.google.com (HELO mail-vc0-f171.google.com)
	(209.85.220.171)
	by server-13.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Sep 2012 21:42:06 -0000
Received: by vcmm18 with SMTP id m18so3275070vcm.30
	for <multiple recipients>; Thu, 27 Sep 2012 14:42:05 -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=6u/CWOMDIWFn0pMcOa4MFkHslWKhQfUNGeq/2jWGYow=;
	b=X5i1JQjQjSS5mZ+qRPViXSafcjDVH64K73F+C/grHojoZp8nkmb7mbJpPuI5gf3hBt
	OS+BupUGGK3UypUKcTIl6MARFwSNAIZmJfpx/x4GS3Wg6KqV6jB8PGqJUEGYfgfDGiQq
	hw6U8qupdbvFNf60oaMoI+aARyFkUi/dBmMNr0g3UGobR5oAv+7NSv6bCrHpUjTztbe4
	xwU6kK0THVh6k2vkaZ6XlDzwykfwv+0cKnG7DWE8GLU+gnM9FcwnHxI3X4asunx2uIIa
	z6BzJ8BeT4W8ubcd68nYcCmMEN0L6ud90oNqF0t0F7909GXEuSIExPnLLFv7Oa24yDKg
	krSw==
MIME-Version: 1.0
Received: by 10.220.116.9 with SMTP id k9mr2991072vcq.0.1348782125006; Thu, 27
	Sep 2012 14:42:05 -0700 (PDT)
Received: by 10.58.207.75 with HTTP; Thu, 27 Sep 2012 14:42:04 -0700 (PDT)
In-Reply-To: <CABx4GKrQxOOQo_uUXSFvy0nzdMp1A_qc=_e4K+88GkB7xv=9nw@mail.gmail.com>
References: <68c41dd8-9195-41b0-83d7-9242b8eff809@default>
	<AANLkTi=NFebVsnj_09+SpCZUo_bNTnTyJLAoR5sfbwZa@mail.gmail.com>
	<AANLkTikptc2POrKQgJuoVZRdwJTo64DJ_hm12KuPky4D@mail.gmail.com>
	<b1ca6ddc-ca69-447e-93e9-8d36d1ff4a43@default>
	<AANLkTinK94GDOF_GeaVs50wK0u8EdZ2rtzPuh65ca8qR@mail.gmail.com>
	<CAE17a0UPyzsNn=ps9MxarkGg=ns8dCpVz0qBDvesT2AOskwfVg@mail.gmail.com>
	<65395f62-74e5-4910-b701-8df629c2ce3b@default>
	<CABx4GKrQxOOQo_uUXSFvy0nzdMp1A_qc=_e4K+88GkB7xv=9nw@mail.gmail.com>
Date: Thu, 27 Sep 2012 23:42:04 +0200
Message-ID: <CAE17a0VkMuUEG9VaM7AFrwcsEjVBq9RfvTWz1_KmscAyCxeAbA@mail.gmail.com>
From: Mauro <mrsanna1@gmail.com>
To: Olivier Hanesse <olivier.hanesse@gmail.com>
X-Mailman-Approved-At: Thu, 27 Sep 2012 22:05:02 +0000
Cc: Dan Magenheimer <dan.magenheimer@oracle.com>, xen-devel@lists.xensource.com,
	Keir Fraser <keir@xen.org>, Jeremy Fitzhardinge <jeremy@goop.org>,
	Keir Fraser <keir.xen@gmail.com>,
	Xen Users <xen-users@lists.xensource.com>,
	Mark Adams <mark@campbell-lange.net>
Subject: Re: [Xen-devel] [Xen-users] Re:  Xen 4 TSC problems
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 27 September 2012 23:28, Olivier Hanesse <olivier.hanesse@gmail.com> wrote:
> Hello,
>
> From my point of view, this was a kind of xen hardware "incompatibility/bug"
> : I was able to reproduce this bug on more than 50 identical servers, but
> not on another farm of servers with a different hardware.
> Xen version, Debian Kernel was exactly the same on both farm.

Yes I think so.
The problem is where I use debian squeeze with xen 4.0.
In another server with the same hardware but with debian lenny and xen
3.0 I have no problems.
I've read that a workaround is to set clocksource=pit on the xen boot
line in the grub conf, I hope this works because I can't change hardware.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 27 22:24:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Sep 2012 22:24: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 1THMUq-0007qQ-IE; Thu, 27 Sep 2012 22:23: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 1THMUo-0007qJ-GE
	for xen-devel@lists.xensource.com; Thu, 27 Sep 2012 22:23:50 +0000
Received: from [85.158.137.99:7072] by server-14.bemta-3.messagelabs.com id
	82/69-25886-5F1D4605; Thu, 27 Sep 2012 22:23:49 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-217.messagelabs.com!1348784628!19393292!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTE5OTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32593 invoked from network); 27 Sep 2012 22:23:49 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Sep 2012 22:23:49 -0000
X-IronPort-AV: E=Sophos;i="4.80,498,1344211200"; d="scan'208";a="14816286"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Sep 2012 22:23: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.279.1; Thu, 27 Sep 2012 23:23: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 1THMUm-0002OT-CD;
	Thu, 27 Sep 2012 22:23:48 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1THMUm-0003Fi-08;
	Thu, 27 Sep 2012 23:23:48 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-13899-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 27 Sep 2012 23:23:48 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13899: 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 13899 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13899/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore            fail   like 13825
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail like 13823
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail like 13825

Tests which did not succeed, but are not blocking:
 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-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  6bf8b882df8f
baseline version:
 xen                  d364becfb083

------------------------------------------------------------
People who touched revisions under test:
  Bastian Blank <waldi@debian.org>
  Ben Guthro <ben@guthro.net>
  Christoph Egger <Christoph.Egger@amd.com>
  Christoph Egger <Christoph.Egger@amd.com> (on just this change)
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Keir Fraser <keir@xen.org>
  Liu, Jinsong <jinsong.liu@intel.com>
  Olaf Hering <olaf@aepfle.de>
------------------------------------------------------------

jobs:
 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-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-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-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-amd64-amd64-xl-win                                      fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=xen-unstable
+ revision=6bf8b882df8f
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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 6bf8b882df8f
+ branch=xen-unstable
+ revision=6bf8b882df8f
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-unstable
+ '[' xxen = xlinux ']'
+ linuxbranch=linux
+ : master
+ : tested/2.6.39.x
+ . ap-common
++ : xen@xenbits.xensource.com
++ : http://xenbits.xen.org/hg/staging/xen-unstable.hg
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : xen@xenbits.xensource.com:git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.xen-unstable
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-unstable.git
++ : daily-cron.xen-unstable
+ TREE_LINUX=xen@xenbits.xensource.com:git/linux-pvops.git
+ TREE_QEMU_UPSTREAM=xen@xenbits.xensource.com:git/qemu-upstream-unstable.git
+ info_linux_tree xen-unstable
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/xen-unstable.hg
+ hg push -r 6bf8b882df8f 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 137 changes to 104 files

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Thu Sep 27 22:24:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 27 Sep 2012 22:24: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 1THMUq-0007qQ-IE; Thu, 27 Sep 2012 22:23: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 1THMUo-0007qJ-GE
	for xen-devel@lists.xensource.com; Thu, 27 Sep 2012 22:23:50 +0000
Received: from [85.158.137.99:7072] by server-14.bemta-3.messagelabs.com id
	82/69-25886-5F1D4605; Thu, 27 Sep 2012 22:23:49 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-217.messagelabs.com!1348784628!19393292!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTE5OTU=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32593 invoked from network); 27 Sep 2012 22:23:49 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Sep 2012 22:23:49 -0000
X-IronPort-AV: E=Sophos;i="4.80,498,1344211200"; d="scan'208";a="14816286"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Sep 2012 22:23: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.279.1; Thu, 27 Sep 2012 23:23: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 1THMUm-0002OT-CD;
	Thu, 27 Sep 2012 22:23:48 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1THMUm-0003Fi-08;
	Thu, 27 Sep 2012 23:23:48 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-13899-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 27 Sep 2012 23:23:48 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13899: 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 13899 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13899/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore            fail   like 13825
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail like 13823
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail like 13825

Tests which did not succeed, but are not blocking:
 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-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  6bf8b882df8f
baseline version:
 xen                  d364becfb083

------------------------------------------------------------
People who touched revisions under test:
  Bastian Blank <waldi@debian.org>
  Ben Guthro <ben@guthro.net>
  Christoph Egger <Christoph.Egger@amd.com>
  Christoph Egger <Christoph.Egger@amd.com> (on just this change)
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Keir Fraser <keir@xen.org>
  Liu, Jinsong <jinsong.liu@intel.com>
  Olaf Hering <olaf@aepfle.de>
------------------------------------------------------------

jobs:
 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-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-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-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-amd64-amd64-xl-win                                      fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=xen-unstable
+ revision=6bf8b882df8f
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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 6bf8b882df8f
+ branch=xen-unstable
+ revision=6bf8b882df8f
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-unstable
+ '[' xxen = xlinux ']'
+ linuxbranch=linux
+ : master
+ : tested/2.6.39.x
+ . ap-common
++ : xen@xenbits.xensource.com
++ : http://xenbits.xen.org/hg/staging/xen-unstable.hg
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : xen@xenbits.xensource.com:git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.xen-unstable
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-unstable.git
++ : daily-cron.xen-unstable
+ TREE_LINUX=xen@xenbits.xensource.com:git/linux-pvops.git
+ TREE_QEMU_UPSTREAM=xen@xenbits.xensource.com:git/qemu-upstream-unstable.git
+ info_linux_tree xen-unstable
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/xen-unstable.hg
+ hg push -r 6bf8b882df8f 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 137 changes to 104 files

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 28 04:52:25 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Sep 2012 04:52:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1THSYK-0007js-QJ; Fri, 28 Sep 2012 04:51:52 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1THSYJ-0007jn-EY
	for xen-devel@lists.xensource.com; Fri, 28 Sep 2012 04:51:51 +0000
Received: from [85.158.139.83:33626] by server-7.bemta-5.messagelabs.com id
	85/C7-00431-6EC25605; Fri, 28 Sep 2012 04:51:50 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1348807910!30283863!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTIwOTc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17116 invoked from network); 28 Sep 2012 04:51:50 -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;
	28 Sep 2012 04:51:50 -0000
X-IronPort-AV: E=Sophos;i="4.80,498,1344211200"; d="scan'208";a="14819054"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Sep 2012 04:51:48 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Fri, 28 Sep 2012 05:51: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 1THSYG-0005Ru-GU;
	Fri, 28 Sep 2012 04:51:48 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1THSYG-0006bC-3Q;
	Fri, 28 Sep 2012 05:51:48 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-13900-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 28 Sep 2012 05:51:48 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13900: 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 13900 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13900/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore            fail   like 13899
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail like 13899
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail like 13899

Tests which did not succeed, but are not blocking:
 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-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  6bf8b882df8f
baseline version:
 xen                  6bf8b882df8f

jobs:
 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-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-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-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-amd64-amd64-xl-win                                      fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Published tested tree is already up to date.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 28 04:52:25 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Sep 2012 04:52:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1THSYK-0007js-QJ; Fri, 28 Sep 2012 04:51:52 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1THSYJ-0007jn-EY
	for xen-devel@lists.xensource.com; Fri, 28 Sep 2012 04:51:51 +0000
Received: from [85.158.139.83:33626] by server-7.bemta-5.messagelabs.com id
	85/C7-00431-6EC25605; Fri, 28 Sep 2012 04:51:50 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1348807910!30283863!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTIwOTc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17116 invoked from network); 28 Sep 2012 04:51:50 -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;
	28 Sep 2012 04:51:50 -0000
X-IronPort-AV: E=Sophos;i="4.80,498,1344211200"; d="scan'208";a="14819054"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Sep 2012 04:51:48 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Fri, 28 Sep 2012 05:51: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 1THSYG-0005Ru-GU;
	Fri, 28 Sep 2012 04:51:48 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1THSYG-0006bC-3Q;
	Fri, 28 Sep 2012 05:51:48 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-13900-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 28 Sep 2012 05:51:48 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13900: 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 13900 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13900/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore            fail   like 13899
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail like 13899
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail like 13899

Tests which did not succeed, but are not blocking:
 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-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  6bf8b882df8f
baseline version:
 xen                  6bf8b882df8f

jobs:
 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-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-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-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-amd64-amd64-xl-win                                      fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Published tested tree is already up to date.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 28 05:15:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Sep 2012 05: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 1THSv0-0008D0-7t; Fri, 28 Sep 2012 05:15:18 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <lethalduck@gmail.com>) id 1THQfq-0007AX-30
	for xen-devel@lists.xen.org; Fri, 28 Sep 2012 02:51:30 +0000
X-Env-Sender: lethalduck@gmail.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1348800681!8951433!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-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8729 invoked from network); 28 Sep 2012 02:51:22 -0000
Received: from mail-vb0-f45.google.com (HELO mail-vb0-f45.google.com)
	(209.85.212.45)
	by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Sep 2012 02:51:22 -0000
Received: by vbip1 with SMTP id p1so3226632vbi.32
	for <xen-devel@lists.xen.org>; Thu, 27 Sep 2012 19:51:21 -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=d6OxRswavK68s+t7jOs3kXti2bFAoueNE3DtBRiEthU=;
	b=NMLF0/8eLk+b0xgVBw9+NijulSmG+gOc84mAsUVZHYVJFDMqKRnUbCqI+jdbuHMog/
	F/dECtwf3FCJrQKMtxPv8D4iAolGzimFuCyKOoVyGiw+7ceBu4A77ixZ4e+ZKdVpH/g8
	hN72Ir9l/Zr13LS1oFyStp//FACn0pPGLwAPu5qGKzP0/+IeZvAlpmSVNPsX9EDTW/g2
	RxD3UB8FRtprV70hFhk0zjlfDgnNgcTGWJBd7K+sdChGgIqP106kJsIEN3ZDqcZqYsTK
	Lb0pYKdlbdLBwYHzKV3C7ppBCfBJ/vhZmZOc24V4CcuQsCTx6yOnQwHQC+btf9q1CTGp
	FLug==
MIME-Version: 1.0
Received: by 10.220.40.14 with SMTP id i14mr3291595vce.68.1348800681166; Thu,
	27 Sep 2012 19:51:21 -0700 (PDT)
Received: by 10.220.4.36 with HTTP; Thu, 27 Sep 2012 19:51:21 -0700 (PDT)
Date: Thu, 27 Sep 2012 22:51:21 -0400
Message-ID: <CAPGwcLKjHOgwEGjDpQcymUjkv4eAzOVxN5mOKAtQ2UE3Bc4g9Q@mail.gmail.com>
From: L D <lethalduck@gmail.com>
To: xen-devel@lists.xen.org
X-Mailman-Approved-At: Fri, 28 Sep 2012 05:15:16 +0000
Subject: [Xen-devel] Xen 4.2 and USB
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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!
So I compiled and am running the 4.2 release...did the ./configure;
make world; make install
It works, and am running an ati vga passthrough windows system, except
for usb and sound...

I have a couple of questions, if you can help me with some of these it
would be appreciated.

How do I run qemu upstream in this release? I'm trying to have sound
in win7 64bit sound but I can't get qemu upstream to work.
Anybody have success with win7 sound?
I'm using device_model_override='/usr/lib/xen/bin/qemu-system-i386'

What happened to the command xm usb-add, there is no xl usb-add
equivalent?? I need to do this for my usb keyboard and mouse.
Also any particular reason we can specify a list of pci devices to
passthru but not a list for usbdevices?? The config will only pass 1
usbdevice, we should be able to pass a list of usbdevices no?
As an alternative I tried to passthru the pci usb controllers but
windows recognizes the controllers but for some reason does not
recognize the usb keyboard/mouse as being attached.
Finally how do I connect to the qemu console?? ctrl-alt-shift-2,1 just
show me blank screens (console=1), I have no way to pass additional
usb devices by usb-adding them.

Thanks
Paul

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 28 05:15:47 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Sep 2012 05: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 1THSv0-0008D0-7t; Fri, 28 Sep 2012 05:15:18 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <lethalduck@gmail.com>) id 1THQfq-0007AX-30
	for xen-devel@lists.xen.org; Fri, 28 Sep 2012 02:51:30 +0000
X-Env-Sender: lethalduck@gmail.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1348800681!8951433!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-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8729 invoked from network); 28 Sep 2012 02:51:22 -0000
Received: from mail-vb0-f45.google.com (HELO mail-vb0-f45.google.com)
	(209.85.212.45)
	by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Sep 2012 02:51:22 -0000
Received: by vbip1 with SMTP id p1so3226632vbi.32
	for <xen-devel@lists.xen.org>; Thu, 27 Sep 2012 19:51:21 -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=d6OxRswavK68s+t7jOs3kXti2bFAoueNE3DtBRiEthU=;
	b=NMLF0/8eLk+b0xgVBw9+NijulSmG+gOc84mAsUVZHYVJFDMqKRnUbCqI+jdbuHMog/
	F/dECtwf3FCJrQKMtxPv8D4iAolGzimFuCyKOoVyGiw+7ceBu4A77ixZ4e+ZKdVpH/g8
	hN72Ir9l/Zr13LS1oFyStp//FACn0pPGLwAPu5qGKzP0/+IeZvAlpmSVNPsX9EDTW/g2
	RxD3UB8FRtprV70hFhk0zjlfDgnNgcTGWJBd7K+sdChGgIqP106kJsIEN3ZDqcZqYsTK
	Lb0pYKdlbdLBwYHzKV3C7ppBCfBJ/vhZmZOc24V4CcuQsCTx6yOnQwHQC+btf9q1CTGp
	FLug==
MIME-Version: 1.0
Received: by 10.220.40.14 with SMTP id i14mr3291595vce.68.1348800681166; Thu,
	27 Sep 2012 19:51:21 -0700 (PDT)
Received: by 10.220.4.36 with HTTP; Thu, 27 Sep 2012 19:51:21 -0700 (PDT)
Date: Thu, 27 Sep 2012 22:51:21 -0400
Message-ID: <CAPGwcLKjHOgwEGjDpQcymUjkv4eAzOVxN5mOKAtQ2UE3Bc4g9Q@mail.gmail.com>
From: L D <lethalduck@gmail.com>
To: xen-devel@lists.xen.org
X-Mailman-Approved-At: Fri, 28 Sep 2012 05:15:16 +0000
Subject: [Xen-devel] Xen 4.2 and USB
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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!
So I compiled and am running the 4.2 release...did the ./configure;
make world; make install
It works, and am running an ati vga passthrough windows system, except
for usb and sound...

I have a couple of questions, if you can help me with some of these it
would be appreciated.

How do I run qemu upstream in this release? I'm trying to have sound
in win7 64bit sound but I can't get qemu upstream to work.
Anybody have success with win7 sound?
I'm using device_model_override='/usr/lib/xen/bin/qemu-system-i386'

What happened to the command xm usb-add, there is no xl usb-add
equivalent?? I need to do this for my usb keyboard and mouse.
Also any particular reason we can specify a list of pci devices to
passthru but not a list for usbdevices?? The config will only pass 1
usbdevice, we should be able to pass a list of usbdevices no?
As an alternative I tried to passthru the pci usb controllers but
windows recognizes the controllers but for some reason does not
recognize the usb keyboard/mouse as being attached.
Finally how do I connect to the qemu console?? ctrl-alt-shift-2,1 just
show me blank screens (console=1), I have no way to pass additional
usb devices by usb-adding them.

Thanks
Paul

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 28 07:38:21 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Sep 2012 07:38:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1THV8s-000133-0l; Fri, 28 Sep 2012 07:37:46 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jordi.cucurull@scytl.com>) id 1THV8q-00012y-Pp
	for xen-devel@lists.xen.org; Fri, 28 Sep 2012 07:37:44 +0000
Received: from [85.158.139.211:38242] by server-15.bemta-5.messagelabs.com id
	E6/2C-19430-8C355605; Fri, 28 Sep 2012 07:37:44 +0000
X-Env-Sender: jordi.cucurull@scytl.com
X-Msg-Ref: server-16.tower-206.messagelabs.com!1348817863!20317174!1
X-Originating-IP: [217.111.179.100]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20387 invoked from network); 28 Sep 2012 07:37:43 -0000
Received: from mail3.scytl.com (HELO mail3.scytl.com) (217.111.179.100)
	by server-16.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 28 Sep 2012 07:37:43 -0000
Received: from [10.0.16.210] (217.111.178.66) by mail3.scytl.com (Axigen)
	with (DHE-RSA-CAMELLIA256-SHA encrypted) ESMTPSA id 3D368E;
	Fri, 28 Sep 2012 09:37:41 +0200
Message-ID: <506553C5.3090507@scytl.com>
Date: Fri, 28 Sep 2012 09:37:41 +0200
From: Jordi Cucurull Juan <jordi.cucurull@scytl.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0)
	Gecko/20120721 Thunderbird/14.0
MIME-Version: 1.0
To: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
References: <50647387.5080607@scytl.com> <5064740B.5030402@jhuapl.edu>
In-Reply-To: <5064740B.5030402@jhuapl.edu>
X-AxigenSpam-Level: 5
Cc: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
Subject: Re: [Xen-devel] Compile Xen with VTPM support
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 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

Hi Matthew,

As a rough approximation, when are you planning to submit the new vtpm =

implementation? In the new coming weeks, months, year?

And, is this new vtpm going to be linked to the physical tpm of the =

machine or is going to be totally independent of it?

Best,
Jordi


On 09/27/2012 05:43 PM, Matthew Fioravante wrote:
> The current (old) vtpm implementation still sort of works. You have to
> use xm and find a linux kernel with the tpmfront and tpmback drivers. I
> believe the original xen 2.6.18 kernel has them. There may or may not be
> newer kernels with these drivers.
>
> docs/misc/vtpm.txt should have everything you need to use it.
>
> That being said I'm in the process of submitting my new vtpm
> implementation. So keep an eye on that activity if you're interested.
>
> On 09/27/2012 11:40 AM, Jordi Cucurull Juan wrote:
>> Dear all,
>>
>> I am trying to compile Xen 4.2.0 with VTPM support. The documentation
>> available inside Xen is from 2006. I am wondering if the current steps
>> to enable VTPM support are the same written in the documentation or they
>> have changed.
>>
>> Is it enough with setting the "--enable-vtpm" argument during the
>> configure process? Furthermore, at that time Xen was providing the Linux
>> Kernel as part of its sources. Have the current kernels to be patched to
>> include the Xen VTPM drivers? If it is the case, where can we find the
>> patches?
>>
>> Thank you in advance!
>> Jordi.
>>
>>
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xen.org
>> http://lists.xen.org/xen-devel
>


-- =

Jordi Cucurull Juan
Researcher
Scytl Secure Electronic Voting
Pla=E7a Gal=B7la Placidia, 1-3, 1st floor =B7 08006 Barcelona
Phone:     + 34 934 230 324
Fax        + 34 933 251 028
jordi.cucurull@scytl.com
http://www.scytl.com


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 28 07:38:21 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Sep 2012 07:38:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1THV8s-000133-0l; Fri, 28 Sep 2012 07:37:46 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jordi.cucurull@scytl.com>) id 1THV8q-00012y-Pp
	for xen-devel@lists.xen.org; Fri, 28 Sep 2012 07:37:44 +0000
Received: from [85.158.139.211:38242] by server-15.bemta-5.messagelabs.com id
	E6/2C-19430-8C355605; Fri, 28 Sep 2012 07:37:44 +0000
X-Env-Sender: jordi.cucurull@scytl.com
X-Msg-Ref: server-16.tower-206.messagelabs.com!1348817863!20317174!1
X-Originating-IP: [217.111.179.100]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20387 invoked from network); 28 Sep 2012 07:37:43 -0000
Received: from mail3.scytl.com (HELO mail3.scytl.com) (217.111.179.100)
	by server-16.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 28 Sep 2012 07:37:43 -0000
Received: from [10.0.16.210] (217.111.178.66) by mail3.scytl.com (Axigen)
	with (DHE-RSA-CAMELLIA256-SHA encrypted) ESMTPSA id 3D368E;
	Fri, 28 Sep 2012 09:37:41 +0200
Message-ID: <506553C5.3090507@scytl.com>
Date: Fri, 28 Sep 2012 09:37:41 +0200
From: Jordi Cucurull Juan <jordi.cucurull@scytl.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0)
	Gecko/20120721 Thunderbird/14.0
MIME-Version: 1.0
To: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
References: <50647387.5080607@scytl.com> <5064740B.5030402@jhuapl.edu>
In-Reply-To: <5064740B.5030402@jhuapl.edu>
X-AxigenSpam-Level: 5
Cc: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
Subject: Re: [Xen-devel] Compile Xen with VTPM support
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 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

Hi Matthew,

As a rough approximation, when are you planning to submit the new vtpm =

implementation? In the new coming weeks, months, year?

And, is this new vtpm going to be linked to the physical tpm of the =

machine or is going to be totally independent of it?

Best,
Jordi


On 09/27/2012 05:43 PM, Matthew Fioravante wrote:
> The current (old) vtpm implementation still sort of works. You have to
> use xm and find a linux kernel with the tpmfront and tpmback drivers. I
> believe the original xen 2.6.18 kernel has them. There may or may not be
> newer kernels with these drivers.
>
> docs/misc/vtpm.txt should have everything you need to use it.
>
> That being said I'm in the process of submitting my new vtpm
> implementation. So keep an eye on that activity if you're interested.
>
> On 09/27/2012 11:40 AM, Jordi Cucurull Juan wrote:
>> Dear all,
>>
>> I am trying to compile Xen 4.2.0 with VTPM support. The documentation
>> available inside Xen is from 2006. I am wondering if the current steps
>> to enable VTPM support are the same written in the documentation or they
>> have changed.
>>
>> Is it enough with setting the "--enable-vtpm" argument during the
>> configure process? Furthermore, at that time Xen was providing the Linux
>> Kernel as part of its sources. Have the current kernels to be patched to
>> include the Xen VTPM drivers? If it is the case, where can we find the
>> patches?
>>
>> Thank you in advance!
>> Jordi.
>>
>>
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xen.org
>> http://lists.xen.org/xen-devel
>


-- =

Jordi Cucurull Juan
Researcher
Scytl Secure Electronic Voting
Pla=E7a Gal=B7la Placidia, 1-3, 1st floor =B7 08006 Barcelona
Phone:     + 34 934 230 324
Fax        + 34 933 251 028
jordi.cucurull@scytl.com
http://www.scytl.com


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 28 07:49:24 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Sep 2012 07:49:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1THVJg-0001H2-CS; Fri, 28 Sep 2012 07:48:56 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1THVJf-0001Gx-3y
	for xen-devel@lists.xen.org; Fri, 28 Sep 2012 07:48:55 +0000
Received: from [85.158.143.35:58989] by server-2.bemta-4.messagelabs.com id
	79/76-06610-66655605; Fri, 28 Sep 2012 07:48:54 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1348818533!4483393!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1986 invoked from network); 28 Sep 2012 07:48:53 -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;
	28 Sep 2012 07:48:53 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 28 Sep 2012 08:48:53 +0100
Message-Id: <5065729C020000780009E63B@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 28 Sep 2012 08:49:16 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Daniel Kiper" <daniel.kiper@oracle.com>
References: <1348769198-29580-1-git-send-email-daniel.kiper@oracle.com>
	<1348769198-29580-2-git-send-email-daniel.kiper@oracle.com>
In-Reply-To: <1348769198-29580-2-git-send-email-daniel.kiper@oracle.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: andrew.cooper3@citrix.com, konrad.wilk@oracle.com,
	linux-kernel@vger.kernel.org, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 01/11] kexec: introduce kexec_ops struct
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.09.12 at 20:06, Daniel Kiper <daniel.kiper@oracle.com> wrote:
> Some kexec/kdump implementations (e.g. Xen PVOPS) on different archs could
> not use default functions or require some changes in behavior of kexec/kdump
> generic code. To cope with that problem kexec_ops struct was introduced.
> It allows a developer to replace all or some functions and control some
> functionality of kexec/kdump generic code.

I'm not convinced that doing this at the architecture independent
layer is really necessary/desirable. Nevertheless, if that's the right
place, then everything else looks good to me, except for a
cosmetic thing:

> @@ -392,7 +435,7 @@ static void kimage_free_page_list(struct list_head *list)
>  
>  		page = list_entry(pos, struct page, lru);
>  		list_del(&page->lru);
> -		kimage_free_pages(page);
> +		(*kexec_ops.kimage_free_pages)(page);

These constructs are generally better readable without the
explicit yet redundant indirection:

		kexec_ops.kimage_free_pages(page);

Jan



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 28 07:49:24 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Sep 2012 07:49:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1THVJg-0001H2-CS; Fri, 28 Sep 2012 07:48:56 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1THVJf-0001Gx-3y
	for xen-devel@lists.xen.org; Fri, 28 Sep 2012 07:48:55 +0000
Received: from [85.158.143.35:58989] by server-2.bemta-4.messagelabs.com id
	79/76-06610-66655605; Fri, 28 Sep 2012 07:48:54 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1348818533!4483393!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1986 invoked from network); 28 Sep 2012 07:48:53 -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;
	28 Sep 2012 07:48:53 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 28 Sep 2012 08:48:53 +0100
Message-Id: <5065729C020000780009E63B@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 28 Sep 2012 08:49:16 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Daniel Kiper" <daniel.kiper@oracle.com>
References: <1348769198-29580-1-git-send-email-daniel.kiper@oracle.com>
	<1348769198-29580-2-git-send-email-daniel.kiper@oracle.com>
In-Reply-To: <1348769198-29580-2-git-send-email-daniel.kiper@oracle.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: andrew.cooper3@citrix.com, konrad.wilk@oracle.com,
	linux-kernel@vger.kernel.org, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 01/11] kexec: introduce kexec_ops struct
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.09.12 at 20:06, Daniel Kiper <daniel.kiper@oracle.com> wrote:
> Some kexec/kdump implementations (e.g. Xen PVOPS) on different archs could
> not use default functions or require some changes in behavior of kexec/kdump
> generic code. To cope with that problem kexec_ops struct was introduced.
> It allows a developer to replace all or some functions and control some
> functionality of kexec/kdump generic code.

I'm not convinced that doing this at the architecture independent
layer is really necessary/desirable. Nevertheless, if that's the right
place, then everything else looks good to me, except for a
cosmetic thing:

> @@ -392,7 +435,7 @@ static void kimage_free_page_list(struct list_head *list)
>  
>  		page = list_entry(pos, struct page, lru);
>  		list_del(&page->lru);
> -		kimage_free_pages(page);
> +		(*kexec_ops.kimage_free_pages)(page);

These constructs are generally better readable without the
explicit yet redundant indirection:

		kexec_ops.kimage_free_pages(page);

Jan



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 28 07:57:31 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Sep 2012 07:57:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1THVRH-0001QF-9J; Fri, 28 Sep 2012 07:56: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 1THVRF-0001QA-80
	for xen-devel@lists.xen.org; Fri, 28 Sep 2012 07:56:45 +0000
Received: from [85.158.143.35:49680] by server-3.bemta-4.messagelabs.com id
	86/2A-10986-C3855605; Fri, 28 Sep 2012 07:56:44 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1348818986!13409927!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29609 invoked from network); 28 Sep 2012 07:56:26 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-11.tower-21.messagelabs.com with SMTP;
	28 Sep 2012 07:56:26 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 28 Sep 2012 08:56:25 +0100
Message-Id: <50657462020000780009E64A@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 28 Sep 2012 08:56:50 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Daniel Kiper" <daniel.kiper@oracle.com>
References: <1348769198-29580-1-git-send-email-daniel.kiper@oracle.com>
	<1348769198-29580-2-git-send-email-daniel.kiper@oracle.com>
	<1348769198-29580-3-git-send-email-daniel.kiper@oracle.com>
In-Reply-To: <1348769198-29580-3-git-send-email-daniel.kiper@oracle.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: andrew.cooper3@citrix.com, konrad.wilk@oracle.com,
	linux-kernel@vger.kernel.org, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 02/11] x86/kexec: Add extra pointers to
 transition page table PGD, PUD, PMD and PTE
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.09.12 at 20:06, Daniel Kiper <daniel.kiper@oracle.com> wrote:
> Some implementations (e.g. Xen PVOPS) could not use part of identity page 
> table
> to construct transition page table. It means that they require separate 
> PUDs,
> PMDs and PTEs for virtual and physical (identity) mapping. To satisfy that
> requirement add extra pointer to PGD, PUD, PMD and PTE and align existing 
> code.

I'm puzzled by this - why would you need to reintroduce what had
been dropped a long time ago, when the forward ported kernels
don't need it? Xen itself doesn't need the extra entries, their
presence is purely a requirement of the specific kernel
implementation afaict.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 28 07:57:31 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Sep 2012 07:57:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1THVRH-0001QF-9J; Fri, 28 Sep 2012 07:56: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 1THVRF-0001QA-80
	for xen-devel@lists.xen.org; Fri, 28 Sep 2012 07:56:45 +0000
Received: from [85.158.143.35:49680] by server-3.bemta-4.messagelabs.com id
	86/2A-10986-C3855605; Fri, 28 Sep 2012 07:56:44 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1348818986!13409927!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29609 invoked from network); 28 Sep 2012 07:56:26 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-11.tower-21.messagelabs.com with SMTP;
	28 Sep 2012 07:56:26 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 28 Sep 2012 08:56:25 +0100
Message-Id: <50657462020000780009E64A@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 28 Sep 2012 08:56:50 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Daniel Kiper" <daniel.kiper@oracle.com>
References: <1348769198-29580-1-git-send-email-daniel.kiper@oracle.com>
	<1348769198-29580-2-git-send-email-daniel.kiper@oracle.com>
	<1348769198-29580-3-git-send-email-daniel.kiper@oracle.com>
In-Reply-To: <1348769198-29580-3-git-send-email-daniel.kiper@oracle.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: andrew.cooper3@citrix.com, konrad.wilk@oracle.com,
	linux-kernel@vger.kernel.org, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 02/11] x86/kexec: Add extra pointers to
 transition page table PGD, PUD, PMD and PTE
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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.09.12 at 20:06, Daniel Kiper <daniel.kiper@oracle.com> wrote:
> Some implementations (e.g. Xen PVOPS) could not use part of identity page 
> table
> to construct transition page table. It means that they require separate 
> PUDs,
> PMDs and PTEs for virtual and physical (identity) mapping. To satisfy that
> requirement add extra pointer to PGD, PUD, PMD and PTE and align existing 
> code.

I'm puzzled by this - why would you need to reintroduce what had
been dropped a long time ago, when the forward ported kernels
don't need it? Xen itself doesn't need the extra entries, their
presence is purely a requirement of the specific kernel
implementation afaict.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 28 08:12:02 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Sep 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 1THVfX-00029G-Ci; Fri, 28 Sep 2012 08:11:31 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1THVfV-00029B-0m
	for xen-devel@lists.xen.org; Fri, 28 Sep 2012 08:11:29 +0000
Received: from [85.158.139.83:48919] by server-3.bemta-5.messagelabs.com id
	5D/0A-16108-0BB55605; Fri, 28 Sep 2012 08:11:28 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1348819886!31964374!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20844 invoked from network); 28 Sep 2012 08:11:26 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-13.tower-182.messagelabs.com with SMTP;
	28 Sep 2012 08:11:26 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 28 Sep 2012 09:11:25 +0100
Message-Id: <506577E3020000780009E65B@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 28 Sep 2012 09:11:47 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Daniel Kiper" <daniel.kiper@oracle.com>
References: <1348769198-29580-1-git-send-email-daniel.kiper@oracle.com>
	<1348769198-29580-2-git-send-email-daniel.kiper@oracle.com>
	<1348769198-29580-3-git-send-email-daniel.kiper@oracle.com>
	<1348769198-29580-4-git-send-email-daniel.kiper@oracle.com>
	<1348769198-29580-5-git-send-email-daniel.kiper@oracle.com>
	<1348769198-29580-6-git-send-email-daniel.kiper@oracle.com>
	<1348769198-29580-7-git-send-email-daniel.kiper@oracle.com>
In-Reply-To: <1348769198-29580-7-git-send-email-daniel.kiper@oracle.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__PartD5E4EDD3.1__="
Cc: andrew.cooper3@citrix.com, konrad.wilk@oracle.com,
	linux-kernel@vger.kernel.org, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 06/11] x86/xen: Add i386 kexec/kdump
	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

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.

--=__PartD5E4EDD3.1__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

>>> On 27.09.12 at 20:06, Daniel Kiper <daniel.kiper@oracle.com> wrote:
> Add i386 kexec/kdump implementation.

So this as well as the subsequent patch introduces quite a bit of
duplicate code. The old 2.6.18 kernel had an initial pair of cleanup
patches (attached in their forward ported form for 3.6-rc6) that
would allow reducing the amount of duplication, particularly by
eliminating the need to clone relocate_kernel_??.S altogether.

Additionally, in the PAE case (which is the only relevant one for
a 32-bit Xen kernel) I'm missing the address restriction
enforcement for the PGD, without which the __ma() conversion
result may not fit into the field it gets stored into.

Finally, as noticed in an earlier patch already, you appear to
re-introduce stuff long dropped from the kernel - the forward
ported kernels get away with just setting PA_CONTROL_PAGE,
PA_PGD, and PA_SWAP_PAGE in the page list. Since the number
and purpose of the pages is established entirely by the guest
kernel, all you need to obey is that the hypervisor expects
alternating PA_/VA_ pairs (where the VA_ ones can be left
unpopulated). Perhaps taking a look at a recent SLES kernel
would help...

Jan


--=__PartD5E4EDD3.1__=
Content-Type: text/plain; name="kexec-move-segment-code-x86_64.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="kexec-move-segment-code-x86_64.patch"

Subject: kexec: Move asm segment handling code to the assembly file =
(x86_64)=0AFrom: http://xenbits.xensource.com/xen-unstable.hg (tip =
13816)=0APatch-mainline: n/a=0A=0AThis patch moves the idt, gdt, and =
segment handling code from machine_kexec.c=0Ato relocate_kernel.S.  The =
main reason behind this move is to avoid code =0Aduplication in the Xen =
hypervisor. With this patch all code required to kexec=0Ais put on the =
control page.=0A=0AOn top of that this patch also counts as a cleanup - I =
think it is much=0Anicer to write assembly directly in assembly files than =
wrap inline assembly=0Ain C functions for no apparent reason.=0A=0ASigned-o=
ff-by: Magnus Damm <magnus@valinux.co.jp>=0AAcked-by: jbeulich@novell.com=
=0A=0A Applies to 2.6.19-rc1.=0A jb: fixed up register usage for 2.6.30 =
(bnc#545206)=0A=0A--- head-2011-08-09.orig/arch/x86/kernel/machine_kexec_64=
.c	2011-08-09 10:21:04.000000000 +0200=0A+++ head-2011-08-09/arch/x86/=
kernel/machine_kexec_64.c	2010-04-15 09:38:56.000000000 +0200=0A@@ =
-203,47 +203,6 @@ static int init_pgtable(struct kimage *i=0A 	return =
init_transition_pgtable(image, level4p);=0A }=0A =0A-static void set_idt(vo=
id *newidt, u16 limit)=0A-{=0A-	struct desc_ptr curidt;=0A-=0A-	/* x86-64 =
supports unaliged loads & stores */=0A-	curidt.size    =3D limit;=0A-	=
curidt.address =3D (unsigned long)newidt;=0A-=0A-	__asm__ __volatile_=
_ (=0A-		"lidtq %0\n"=0A-		: : "m" (curidt)=0A-		=
);=0A-};=0A-=0A-=0A-static void set_gdt(void *newgdt, u16 limit)=0A-{=0A-	=
struct desc_ptr curgdt;=0A-=0A-	/* x86-64 supports unaligned loads & =
stores */=0A-	curgdt.size    =3D limit;=0A-	curgdt.address =3D =
(unsigned long)newgdt;=0A-=0A-	__asm__ __volatile__ (=0A-		=
"lgdtq %0\n"=0A-		: : "m" (curgdt)=0A-		);=0A-};=0A=
-=0A-static void load_segments(void)=0A-{=0A-	__asm__ __volatile__ (=0A-	=
	"\tmovl %0,%%ds\n"=0A-		"\tmovl %0,%%es\n"=0A-		=
"\tmovl %0,%%ss\n"=0A-		"\tmovl %0,%%fs\n"=0A-		"\tmovl =
%0,%%gs\n"=0A-		: : "a" (__KERNEL_DS) : "memory"=0A-		=
);=0A-}=0A-=0A int machine_kexec_prepare(struct kimage *image)=0A {=0A 	=
unsigned long start_pgtable;=0A@@ -311,24 +270,6 @@ void machine_kexec(stru=
ct kimage *image)=0A 		page_list[PA_SWAP_PAGE] =3D (page_to_pfn(im=
age->swap_page)=0A 						<< =
PAGE_SHIFT);=0A =0A-	/*=0A-	 * The segment registers are funny things, =
they have both a=0A-	 * visible and an invisible part.  Whenever the =
visible part is=0A-	 * set to a specific selector, the invisible part =
is loaded=0A-	 * with from a table in memory.  At no other time is =
the=0A-	 * descriptor table in memory accessed.=0A-	 *=0A-	 * I take =
advantage of this here by force loading the=0A-	 * segments, before I zap =
the gdt with an invalid value.=0A-	 */=0A-	load_segments();=0A-	=
/*=0A-	 * The gdt & idt are now invalid.=0A-	 * If you want to load =
them you must set up your own idt & gdt.=0A-	 */=0A-	set_gdt(phys_to_vir=
t(0), 0);=0A-	set_idt(phys_to_virt(0), 0);=0A-=0A 	/* now call it =
*/=0A 	image->start =3D relocate_kernel((unsigned long)image->head,=0A 	=
			       (unsigned long)page_list,=0A--- head-2011-08=
-09.orig/arch/x86/kernel/relocate_kernel_64.S	2011-08-09 10:19:07.0000000=
00 +0200=0A+++ head-2011-08-09/arch/x86/kernel/relocate_kernel_64.S	=
2011-08-09 10:21:24.000000000 +0200=0A@@ -91,13 +91,30 @@ relocate_kernel:=
=0A 	/* Switch to the identity mapped page tables */=0A 	movq	=
%r9, %cr3=0A =0A+	/* setup idt */=0A+	lidtq	idt_80 - relocate_k=
ernel(%r8)=0A+=0A+	/* setup gdt */=0A+	leaq	gdt - relocate_kern=
el(%r8), %rax=0A+	movq	%rax, (gdt_80 - relocate_kernel) + =
2(%r8)=0A+	lgdtq	gdt_80 - relocate_kernel(%r8)=0A+=0A+	/* setup =
data segment registers */=0A+	xorl	%eax, %eax=0A+	movl	%eax, =
%ds=0A+	movl	%eax, %es=0A+	movl	%eax, %fs=0A+	movl	%eax, =
%gs=0A+	movl	%eax, %ss=0A+=0A 	/* setup a new stack at the end of =
the physical control page */=0A 	lea	PAGE_SIZE(%r8), %rsp=0A =
=0A-	/* jump to identity mapped page */=0A+	/* load new code segment =
and jump to identity mapped page */=0A 	addq	$(identity_mapped - =
relocate_kernel), %r8=0A+	pushq	$(gdt_cs - gdt)=0A 	pushq	=
%r8=0A-	ret=0A+	lretq=0A =0A identity_mapped:=0A 	/* set return =
address to 0 if not preserving context */=0A@@ -264,5 +281,20 @@ swap_pages=
:=0A 3:=0A 	ret=0A =0A+	.align  16=0A+gdt:=0A+	.quad	0x000000000=
0000000	/* NULL descriptor */=0A+gdt_cs:=0A+	.quad   0x00af9a000000ffff=
=0A+gdt_end:=0A+=0A+gdt_80:=0A+	.word	gdt_end - gdt - 1	/* limit =
*/=0A+	.quad	0			/* base - filled in by code above =
*/=0A+=0A+idt_80:=0A+	.word	0			/* limit */=0A+	=
.quad	0			/* base */=0A+=0A 	.globl kexec_contro=
l_code_size=0A .set kexec_control_code_size, . - relocate_kernel=0A
--=__PartD5E4EDD3.1__=
Content-Type: text/plain; name="kexec-move-segment-code-i386.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="kexec-move-segment-code-i386.patch"

Subject: kexec: Move asm segment handling code to the assembly file =
(i386)=0AFrom: http://xenbits.xensource.com/xen-unstable.hg (tip 13816)=0AP=
atch-mainline: n/a=0A=0AThis patch moves the idt, gdt, and segment =
handling code from machine_kexec.c=0Ato relocate_kernel.S. The main reason =
behind this move is to avoid code =0Aduplication in the Xen hypervisor. =
With this patch all code required to kexec=0Ais put on the control =
page.=0A=0AOn top of that this patch also counts as a cleanup - I think it =
is much=0Anicer to write assembly directly in assembly files than wrap =
inline assembly=0Ain C functions for no apparent reason.=0A=0ASigned-off-by=
: Magnus Damm <magnus@valinux.co.jp>=0AAcked-by: jbeulich@novell.com=0A=0A =
Applies to 2.6.19-rc1.=0A jb: fixed up register usage (paralleling what's =
needed for 2.6.30 on x86-64)=0A=0A--- head.orig/arch/x86/kernel/machine_kex=
ec_32.c	2012-04-10 14:24:22.000000000 +0200=0A+++ head/arch/x86/kernel/mach=
ine_kexec_32.c	2012-04-10 14:50:08.000000000 +0200=0A@@ -26,48 +26,6 =
@@=0A #include <asm/cacheflush.h>=0A #include <asm/debugreg.h>=0A =
=0A-static void set_idt(void *newidt, __u16 limit)=0A-{=0A-	struct =
desc_ptr curidt;=0A-=0A-	/* ia32 supports unaliged loads & stores =
*/=0A-	curidt.size    =3D limit;=0A-	curidt.address =3D (unsigned =
long)newidt;=0A-=0A-	load_idt(&curidt);=0A-}=0A-=0A-=0A-static void =
set_gdt(void *newgdt, __u16 limit)=0A-{=0A-	struct desc_ptr curgdt;=0A-=
=0A-	/* ia32 supports unaligned loads & stores */=0A-	curgdt.size=
    =3D limit;=0A-	curgdt.address =3D (unsigned long)newgdt;=0A-=0A-	=
load_gdt(&curgdt);=0A-}=0A-=0A-static void load_segments(void)=0A-{=0A-#def=
ine __STR(X) #X=0A-#define STR(X) __STR(X)=0A-=0A-	__asm__ __volatile_=
_ (=0A-		"\tljmp $"STR(__KERNEL_CS)",$1f\n"=0A-		"\t1:\n"=0A=
-		"\tmovl $"STR(__KERNEL_DS)",%%eax\n"=0A-		=
"\tmovl %%eax,%%ds\n"=0A-		"\tmovl %%eax,%%es\n"=0A-		=
"\tmovl %%eax,%%fs\n"=0A-		"\tmovl %%eax,%%gs\n"=0A-		=
"\tmovl %%eax,%%ss\n"=0A-		: : : "eax", "memory");=0A-#undef =
STR=0A-#undef __STR=0A-}=0A-=0A static void machine_kexec_free_page_tables(=
struct kimage *image)=0A {=0A 	free_page((unsigned long)image->arch.pgd);=
=0A@@ -227,24 +185,6 @@ void machine_kexec(struct kimage *image)=0A 		=
page_list[PA_SWAP_PAGE] =3D (page_to_pfn(image->swap_page)=0A 			=
			<< PAGE_SHIFT);=0A =0A-	/*=0A-	 * The segment =
registers are funny things, they have both a=0A-	 * visible and an =
invisible part.  Whenever the visible part is=0A-	 * set to a =
specific selector, the invisible part is loaded=0A-	 * with from a =
table in memory.  At no other time is the=0A-	 * descriptor table in =
memory accessed.=0A-	 *=0A-	 * I take advantage of this here by force =
loading the=0A-	 * segments, before I zap the gdt with an invalid =
value.=0A-	 */=0A-	load_segments();=0A-	/*=0A-	 * The gdt & idt =
are now invalid.=0A-	 * If you want to load them you must set up your =
own idt & gdt.=0A-	 */=0A-	set_gdt(phys_to_virt(0), 0);=0A-	=
set_idt(phys_to_virt(0), 0);=0A-=0A 	/* now call it */=0A 	image->star=
t =3D relocate_kernel_ptr((unsigned long)image->head,=0A 			=
		   (unsigned long)page_list,=0A--- head.orig/arch/x86/kerne=
l/relocate_kernel_32.S	2011-10-24 09:10:05.000000000 +0200=0A+++ =
head/arch/x86/kernel/relocate_kernel_32.S	2011-08-09 10:21:17.0000000=
00 +0200=0A@@ -87,14 +87,32 @@ relocate_kernel:=0A 	movl	PTR(PA_PGD)=
(%ebp), %eax=0A 	movl	%eax, %cr3=0A =0A+	/* setup idt =
*/=0A+	lidtl	idt_48 - relocate_kernel(%edi)=0A+=0A+	/* setup gdt =
*/=0A+	leal	gdt - relocate_kernel(%edi), %eax=0A+	movl	%eax, =
(gdt_48 - relocate_kernel) + 2(%edi)=0A+	lgdtl	gdt_48 - relocate_k=
ernel(%edi)=0A+=0A+	/* setup data segment registers */=0A+	mov	=
$(gdt_ds - gdt), %eax=0A+	mov	%eax, %ds=0A+	mov	%eax, =
%es=0A+	mov	%eax, %fs=0A+	mov	%eax, %gs=0A+	mov	%eax, =
%ss=0A+=0A 	/* setup a new stack at the end of the physical control =
page */=0A 	lea	PAGE_SIZE(%edi), %esp=0A =0A-	/* jump to =
identity mapped page */=0A+	/* load new code segment and jump to =
identity mapped page */=0A+	pushl	$0=0A+	pushl	$(gdt_cs - gdt)=0A =
	movl    %edi, %eax=0A 	addl    $(identity_mapped - relocate_kernel=
), %eax=0A 	pushl   %eax=0A-	ret=0A+	iretl=0A =0A identity_mappe=
d:=0A 	/* set return address to 0 if not preserving context */=0A@@ =
-273,5 +291,22 @@ swap_pages:=0A 	popl	%ebp=0A 	ret=0A =
=0A+	.align	16=0A+gdt:=0A+	.quad	0x0000000000000000	/* NULL =
descriptor */=0A+gdt_cs:=0A+	.quad	0x00cf9a000000ffff	/* kernel =
4GB code at 0x00000000 */=0A+gdt_ds:=0A+	.quad	0x00cf92000000ffff	=
/* kernel 4GB data at 0x00000000 */=0A+gdt_end:=0A+=0A+gdt_48:=0A+	=
.word	gdt_end - gdt - 1	/* limit */=0A+	.long	0			=
/* base - filled in by code above */=0A+=0A+idt_48:=0A+	.word	0		=
	/* limit */=0A+	.long	0			/* base */=0A+=0A 	=
.globl kexec_control_code_size=0A .set kexec_control_code_size, . - =
relocate_kernel=0A
--=__PartD5E4EDD3.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

--=__PartD5E4EDD3.1__=--


From xen-devel-bounces@lists.xen.org Fri Sep 28 08:12:02 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Sep 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 1THVfX-00029G-Ci; Fri, 28 Sep 2012 08:11:31 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1THVfV-00029B-0m
	for xen-devel@lists.xen.org; Fri, 28 Sep 2012 08:11:29 +0000
Received: from [85.158.139.83:48919] by server-3.bemta-5.messagelabs.com id
	5D/0A-16108-0BB55605; Fri, 28 Sep 2012 08:11:28 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1348819886!31964374!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20844 invoked from network); 28 Sep 2012 08:11:26 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-13.tower-182.messagelabs.com with SMTP;
	28 Sep 2012 08:11:26 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 28 Sep 2012 09:11:25 +0100
Message-Id: <506577E3020000780009E65B@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 28 Sep 2012 09:11:47 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Daniel Kiper" <daniel.kiper@oracle.com>
References: <1348769198-29580-1-git-send-email-daniel.kiper@oracle.com>
	<1348769198-29580-2-git-send-email-daniel.kiper@oracle.com>
	<1348769198-29580-3-git-send-email-daniel.kiper@oracle.com>
	<1348769198-29580-4-git-send-email-daniel.kiper@oracle.com>
	<1348769198-29580-5-git-send-email-daniel.kiper@oracle.com>
	<1348769198-29580-6-git-send-email-daniel.kiper@oracle.com>
	<1348769198-29580-7-git-send-email-daniel.kiper@oracle.com>
In-Reply-To: <1348769198-29580-7-git-send-email-daniel.kiper@oracle.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__PartD5E4EDD3.1__="
Cc: andrew.cooper3@citrix.com, konrad.wilk@oracle.com,
	linux-kernel@vger.kernel.org, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 06/11] x86/xen: Add i386 kexec/kdump
	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

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.

--=__PartD5E4EDD3.1__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

>>> On 27.09.12 at 20:06, Daniel Kiper <daniel.kiper@oracle.com> wrote:
> Add i386 kexec/kdump implementation.

So this as well as the subsequent patch introduces quite a bit of
duplicate code. The old 2.6.18 kernel had an initial pair of cleanup
patches (attached in their forward ported form for 3.6-rc6) that
would allow reducing the amount of duplication, particularly by
eliminating the need to clone relocate_kernel_??.S altogether.

Additionally, in the PAE case (which is the only relevant one for
a 32-bit Xen kernel) I'm missing the address restriction
enforcement for the PGD, without which the __ma() conversion
result may not fit into the field it gets stored into.

Finally, as noticed in an earlier patch already, you appear to
re-introduce stuff long dropped from the kernel - the forward
ported kernels get away with just setting PA_CONTROL_PAGE,
PA_PGD, and PA_SWAP_PAGE in the page list. Since the number
and purpose of the pages is established entirely by the guest
kernel, all you need to obey is that the hypervisor expects
alternating PA_/VA_ pairs (where the VA_ ones can be left
unpopulated). Perhaps taking a look at a recent SLES kernel
would help...

Jan


--=__PartD5E4EDD3.1__=
Content-Type: text/plain; name="kexec-move-segment-code-x86_64.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="kexec-move-segment-code-x86_64.patch"

Subject: kexec: Move asm segment handling code to the assembly file =
(x86_64)=0AFrom: http://xenbits.xensource.com/xen-unstable.hg (tip =
13816)=0APatch-mainline: n/a=0A=0AThis patch moves the idt, gdt, and =
segment handling code from machine_kexec.c=0Ato relocate_kernel.S.  The =
main reason behind this move is to avoid code =0Aduplication in the Xen =
hypervisor. With this patch all code required to kexec=0Ais put on the =
control page.=0A=0AOn top of that this patch also counts as a cleanup - I =
think it is much=0Anicer to write assembly directly in assembly files than =
wrap inline assembly=0Ain C functions for no apparent reason.=0A=0ASigned-o=
ff-by: Magnus Damm <magnus@valinux.co.jp>=0AAcked-by: jbeulich@novell.com=
=0A=0A Applies to 2.6.19-rc1.=0A jb: fixed up register usage for 2.6.30 =
(bnc#545206)=0A=0A--- head-2011-08-09.orig/arch/x86/kernel/machine_kexec_64=
.c	2011-08-09 10:21:04.000000000 +0200=0A+++ head-2011-08-09/arch/x86/=
kernel/machine_kexec_64.c	2010-04-15 09:38:56.000000000 +0200=0A@@ =
-203,47 +203,6 @@ static int init_pgtable(struct kimage *i=0A 	return =
init_transition_pgtable(image, level4p);=0A }=0A =0A-static void set_idt(vo=
id *newidt, u16 limit)=0A-{=0A-	struct desc_ptr curidt;=0A-=0A-	/* x86-64 =
supports unaliged loads & stores */=0A-	curidt.size    =3D limit;=0A-	=
curidt.address =3D (unsigned long)newidt;=0A-=0A-	__asm__ __volatile_=
_ (=0A-		"lidtq %0\n"=0A-		: : "m" (curidt)=0A-		=
);=0A-};=0A-=0A-=0A-static void set_gdt(void *newgdt, u16 limit)=0A-{=0A-	=
struct desc_ptr curgdt;=0A-=0A-	/* x86-64 supports unaligned loads & =
stores */=0A-	curgdt.size    =3D limit;=0A-	curgdt.address =3D =
(unsigned long)newgdt;=0A-=0A-	__asm__ __volatile__ (=0A-		=
"lgdtq %0\n"=0A-		: : "m" (curgdt)=0A-		);=0A-};=0A=
-=0A-static void load_segments(void)=0A-{=0A-	__asm__ __volatile__ (=0A-	=
	"\tmovl %0,%%ds\n"=0A-		"\tmovl %0,%%es\n"=0A-		=
"\tmovl %0,%%ss\n"=0A-		"\tmovl %0,%%fs\n"=0A-		"\tmovl =
%0,%%gs\n"=0A-		: : "a" (__KERNEL_DS) : "memory"=0A-		=
);=0A-}=0A-=0A int machine_kexec_prepare(struct kimage *image)=0A {=0A 	=
unsigned long start_pgtable;=0A@@ -311,24 +270,6 @@ void machine_kexec(stru=
ct kimage *image)=0A 		page_list[PA_SWAP_PAGE] =3D (page_to_pfn(im=
age->swap_page)=0A 						<< =
PAGE_SHIFT);=0A =0A-	/*=0A-	 * The segment registers are funny things, =
they have both a=0A-	 * visible and an invisible part.  Whenever the =
visible part is=0A-	 * set to a specific selector, the invisible part =
is loaded=0A-	 * with from a table in memory.  At no other time is =
the=0A-	 * descriptor table in memory accessed.=0A-	 *=0A-	 * I take =
advantage of this here by force loading the=0A-	 * segments, before I zap =
the gdt with an invalid value.=0A-	 */=0A-	load_segments();=0A-	=
/*=0A-	 * The gdt & idt are now invalid.=0A-	 * If you want to load =
them you must set up your own idt & gdt.=0A-	 */=0A-	set_gdt(phys_to_vir=
t(0), 0);=0A-	set_idt(phys_to_virt(0), 0);=0A-=0A 	/* now call it =
*/=0A 	image->start =3D relocate_kernel((unsigned long)image->head,=0A 	=
			       (unsigned long)page_list,=0A--- head-2011-08=
-09.orig/arch/x86/kernel/relocate_kernel_64.S	2011-08-09 10:19:07.0000000=
00 +0200=0A+++ head-2011-08-09/arch/x86/kernel/relocate_kernel_64.S	=
2011-08-09 10:21:24.000000000 +0200=0A@@ -91,13 +91,30 @@ relocate_kernel:=
=0A 	/* Switch to the identity mapped page tables */=0A 	movq	=
%r9, %cr3=0A =0A+	/* setup idt */=0A+	lidtq	idt_80 - relocate_k=
ernel(%r8)=0A+=0A+	/* setup gdt */=0A+	leaq	gdt - relocate_kern=
el(%r8), %rax=0A+	movq	%rax, (gdt_80 - relocate_kernel) + =
2(%r8)=0A+	lgdtq	gdt_80 - relocate_kernel(%r8)=0A+=0A+	/* setup =
data segment registers */=0A+	xorl	%eax, %eax=0A+	movl	%eax, =
%ds=0A+	movl	%eax, %es=0A+	movl	%eax, %fs=0A+	movl	%eax, =
%gs=0A+	movl	%eax, %ss=0A+=0A 	/* setup a new stack at the end of =
the physical control page */=0A 	lea	PAGE_SIZE(%r8), %rsp=0A =
=0A-	/* jump to identity mapped page */=0A+	/* load new code segment =
and jump to identity mapped page */=0A 	addq	$(identity_mapped - =
relocate_kernel), %r8=0A+	pushq	$(gdt_cs - gdt)=0A 	pushq	=
%r8=0A-	ret=0A+	lretq=0A =0A identity_mapped:=0A 	/* set return =
address to 0 if not preserving context */=0A@@ -264,5 +281,20 @@ swap_pages=
:=0A 3:=0A 	ret=0A =0A+	.align  16=0A+gdt:=0A+	.quad	0x000000000=
0000000	/* NULL descriptor */=0A+gdt_cs:=0A+	.quad   0x00af9a000000ffff=
=0A+gdt_end:=0A+=0A+gdt_80:=0A+	.word	gdt_end - gdt - 1	/* limit =
*/=0A+	.quad	0			/* base - filled in by code above =
*/=0A+=0A+idt_80:=0A+	.word	0			/* limit */=0A+	=
.quad	0			/* base */=0A+=0A 	.globl kexec_contro=
l_code_size=0A .set kexec_control_code_size, . - relocate_kernel=0A
--=__PartD5E4EDD3.1__=
Content-Type: text/plain; name="kexec-move-segment-code-i386.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="kexec-move-segment-code-i386.patch"

Subject: kexec: Move asm segment handling code to the assembly file =
(i386)=0AFrom: http://xenbits.xensource.com/xen-unstable.hg (tip 13816)=0AP=
atch-mainline: n/a=0A=0AThis patch moves the idt, gdt, and segment =
handling code from machine_kexec.c=0Ato relocate_kernel.S. The main reason =
behind this move is to avoid code =0Aduplication in the Xen hypervisor. =
With this patch all code required to kexec=0Ais put on the control =
page.=0A=0AOn top of that this patch also counts as a cleanup - I think it =
is much=0Anicer to write assembly directly in assembly files than wrap =
inline assembly=0Ain C functions for no apparent reason.=0A=0ASigned-off-by=
: Magnus Damm <magnus@valinux.co.jp>=0AAcked-by: jbeulich@novell.com=0A=0A =
Applies to 2.6.19-rc1.=0A jb: fixed up register usage (paralleling what's =
needed for 2.6.30 on x86-64)=0A=0A--- head.orig/arch/x86/kernel/machine_kex=
ec_32.c	2012-04-10 14:24:22.000000000 +0200=0A+++ head/arch/x86/kernel/mach=
ine_kexec_32.c	2012-04-10 14:50:08.000000000 +0200=0A@@ -26,48 +26,6 =
@@=0A #include <asm/cacheflush.h>=0A #include <asm/debugreg.h>=0A =
=0A-static void set_idt(void *newidt, __u16 limit)=0A-{=0A-	struct =
desc_ptr curidt;=0A-=0A-	/* ia32 supports unaliged loads & stores =
*/=0A-	curidt.size    =3D limit;=0A-	curidt.address =3D (unsigned =
long)newidt;=0A-=0A-	load_idt(&curidt);=0A-}=0A-=0A-=0A-static void =
set_gdt(void *newgdt, __u16 limit)=0A-{=0A-	struct desc_ptr curgdt;=0A-=
=0A-	/* ia32 supports unaligned loads & stores */=0A-	curgdt.size=
    =3D limit;=0A-	curgdt.address =3D (unsigned long)newgdt;=0A-=0A-	=
load_gdt(&curgdt);=0A-}=0A-=0A-static void load_segments(void)=0A-{=0A-#def=
ine __STR(X) #X=0A-#define STR(X) __STR(X)=0A-=0A-	__asm__ __volatile_=
_ (=0A-		"\tljmp $"STR(__KERNEL_CS)",$1f\n"=0A-		"\t1:\n"=0A=
-		"\tmovl $"STR(__KERNEL_DS)",%%eax\n"=0A-		=
"\tmovl %%eax,%%ds\n"=0A-		"\tmovl %%eax,%%es\n"=0A-		=
"\tmovl %%eax,%%fs\n"=0A-		"\tmovl %%eax,%%gs\n"=0A-		=
"\tmovl %%eax,%%ss\n"=0A-		: : : "eax", "memory");=0A-#undef =
STR=0A-#undef __STR=0A-}=0A-=0A static void machine_kexec_free_page_tables(=
struct kimage *image)=0A {=0A 	free_page((unsigned long)image->arch.pgd);=
=0A@@ -227,24 +185,6 @@ void machine_kexec(struct kimage *image)=0A 		=
page_list[PA_SWAP_PAGE] =3D (page_to_pfn(image->swap_page)=0A 			=
			<< PAGE_SHIFT);=0A =0A-	/*=0A-	 * The segment =
registers are funny things, they have both a=0A-	 * visible and an =
invisible part.  Whenever the visible part is=0A-	 * set to a =
specific selector, the invisible part is loaded=0A-	 * with from a =
table in memory.  At no other time is the=0A-	 * descriptor table in =
memory accessed.=0A-	 *=0A-	 * I take advantage of this here by force =
loading the=0A-	 * segments, before I zap the gdt with an invalid =
value.=0A-	 */=0A-	load_segments();=0A-	/*=0A-	 * The gdt & idt =
are now invalid.=0A-	 * If you want to load them you must set up your =
own idt & gdt.=0A-	 */=0A-	set_gdt(phys_to_virt(0), 0);=0A-	=
set_idt(phys_to_virt(0), 0);=0A-=0A 	/* now call it */=0A 	image->star=
t =3D relocate_kernel_ptr((unsigned long)image->head,=0A 			=
		   (unsigned long)page_list,=0A--- head.orig/arch/x86/kerne=
l/relocate_kernel_32.S	2011-10-24 09:10:05.000000000 +0200=0A+++ =
head/arch/x86/kernel/relocate_kernel_32.S	2011-08-09 10:21:17.0000000=
00 +0200=0A@@ -87,14 +87,32 @@ relocate_kernel:=0A 	movl	PTR(PA_PGD)=
(%ebp), %eax=0A 	movl	%eax, %cr3=0A =0A+	/* setup idt =
*/=0A+	lidtl	idt_48 - relocate_kernel(%edi)=0A+=0A+	/* setup gdt =
*/=0A+	leal	gdt - relocate_kernel(%edi), %eax=0A+	movl	%eax, =
(gdt_48 - relocate_kernel) + 2(%edi)=0A+	lgdtl	gdt_48 - relocate_k=
ernel(%edi)=0A+=0A+	/* setup data segment registers */=0A+	mov	=
$(gdt_ds - gdt), %eax=0A+	mov	%eax, %ds=0A+	mov	%eax, =
%es=0A+	mov	%eax, %fs=0A+	mov	%eax, %gs=0A+	mov	%eax, =
%ss=0A+=0A 	/* setup a new stack at the end of the physical control =
page */=0A 	lea	PAGE_SIZE(%edi), %esp=0A =0A-	/* jump to =
identity mapped page */=0A+	/* load new code segment and jump to =
identity mapped page */=0A+	pushl	$0=0A+	pushl	$(gdt_cs - gdt)=0A =
	movl    %edi, %eax=0A 	addl    $(identity_mapped - relocate_kernel=
), %eax=0A 	pushl   %eax=0A-	ret=0A+	iretl=0A =0A identity_mappe=
d:=0A 	/* set return address to 0 if not preserving context */=0A@@ =
-273,5 +291,22 @@ swap_pages:=0A 	popl	%ebp=0A 	ret=0A =
=0A+	.align	16=0A+gdt:=0A+	.quad	0x0000000000000000	/* NULL =
descriptor */=0A+gdt_cs:=0A+	.quad	0x00cf9a000000ffff	/* kernel =
4GB code at 0x00000000 */=0A+gdt_ds:=0A+	.quad	0x00cf92000000ffff	=
/* kernel 4GB data at 0x00000000 */=0A+gdt_end:=0A+=0A+gdt_48:=0A+	=
.word	gdt_end - gdt - 1	/* limit */=0A+	.long	0			=
/* base - filled in by code above */=0A+=0A+idt_48:=0A+	.word	0		=
	/* limit */=0A+	.long	0			/* base */=0A+=0A 	=
.globl kexec_control_code_size=0A .set kexec_control_code_size, . - =
relocate_kernel=0A
--=__PartD5E4EDD3.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

--=__PartD5E4EDD3.1__=--


From xen-devel-bounces@lists.xen.org Fri Sep 28 08:20:49 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Sep 2012 08: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 1THVnV-0002Ns-Ll; Fri, 28 Sep 2012 08:19: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 1THVnU-0002Nn-Cn
	for xen-devel@lists.xen.org; Fri, 28 Sep 2012 08:19:44 +0000
Received: from [85.158.139.211:47638] by server-9.bemta-5.messagelabs.com id
	8E/A6-14846-F9D55605; Fri, 28 Sep 2012 08:19:43 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-4.tower-206.messagelabs.com!1348820382!20305144!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12119 invoked from network); 28 Sep 2012 08:19:42 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-4.tower-206.messagelabs.com with SMTP;
	28 Sep 2012 08:19:42 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 28 Sep 2012 09:19:41 +0100
Message-Id: <506579D5020000780009E66E@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 28 Sep 2012 09:20:05 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Jun Nakajima" <jun.nakajima@intel.com>
References: <5056F7AB020000780009BB19@nat28.tlf.novell.com>
In-Reply-To: <5056F7AB020000780009BB19@nat28.tlf.novell.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__PartA5949DA5.1__="
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: [Xen-devel] Ping: [PATCH] x86/Intel: add further support for Ivy
 Bridge CPU models
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
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.

--=__PartA5949DA5.1__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

x86/Intel: add further support for Ivy Bridge CPU models

And some initial Haswell ones at once.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/arch/x86/acpi/cpu_idle.c
+++ b/xen/arch/x86/acpi/cpu_idle.c
@@ -128,11 +128,15 @@ static void do_get_hw_residencies(void *
=20
     switch ( c->x86_model )
     {
-    /* Ivy bridge */
-    case 0x3A:
     /* Sandy bridge */
     case 0x2A:
     case 0x2D:
+    /* Ivy bridge */
+    case 0x3A:
+    case 0x3E:
+    /* Haswell */
+    case 0x3c:
+    case 0x45:
         GET_PC2_RES(hw_res->pc2);
         GET_CC7_RES(hw_res->cc7);
         /* fall through */
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -1746,7 +1746,9 @@ static const struct lbr_info *last_branc
         /* Sandy Bridge */
         case 42: case 45:
         /* Ivy Bridge */
-        case 58:
+        case 58: case 62:
+        /* Haswell */
+        case 60: case 69:
             return nh_lbr;
             break;
         /* Atom */
--- a/xen/arch/x86/hvm/vmx/vpmu_core2.c
+++ b/xen/arch/x86/hvm/vmx/vpmu_core2.c
@@ -747,6 +747,7 @@ int vmx_vpmu_initialise(struct vcpu *v,=20
         case 46:
         case 47:
         case 58:
+        case 62:
             ret =3D core2_vpmu_initialise(v, vpmu_flags);
             if ( !ret )
                 vpmu->arch_vpmu_ops =3D &core2_vpmu_ops;




--=__PartA5949DA5.1__=
Content-Type: text/plain; name="x86-IvyBridge.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="x86-IvyBridge.patch"

x86/Intel: add further support for Ivy Bridge CPU models=0A=0AAnd some =
initial Haswell ones at once.=0A=0ASigned-off-by: Jan Beulich <jbeulich@sus=
e.com>=0A=0A--- a/xen/arch/x86/acpi/cpu_idle.c=0A+++ b/xen/arch/x86/acpi/cp=
u_idle.c=0A@@ -128,11 +128,15 @@ static void do_get_hw_residencies(void =
*=0A =0A     switch ( c->x86_model )=0A     {=0A-    /* Ivy bridge */=0A-  =
  case 0x3A:=0A     /* Sandy bridge */=0A     case 0x2A:=0A     case =
0x2D:=0A+    /* Ivy bridge */=0A+    case 0x3A:=0A+    case 0x3E:=0A+    =
/* Haswell */=0A+    case 0x3c:=0A+    case 0x45:=0A         GET_PC2_RES(hw=
_res->pc2);=0A         GET_CC7_RES(hw_res->cc7);=0A         /* fall =
through */=0A--- a/xen/arch/x86/hvm/vmx/vmx.c=0A+++ b/xen/arch/x86/hvm/vmx/=
vmx.c=0A@@ -1746,7 +1746,9 @@ static const struct lbr_info *last_branc=0A  =
       /* Sandy Bridge */=0A         case 42: case 45:=0A         /* Ivy =
Bridge */=0A-        case 58:=0A+        case 58: case 62:=0A+        /* =
Haswell */=0A+        case 60: case 69:=0A             return nh_lbr;=0A   =
          break;=0A         /* Atom */=0A--- a/xen/arch/x86/hvm/vmx/vpmu_co=
re2.c=0A+++ b/xen/arch/x86/hvm/vmx/vpmu_core2.c=0A@@ -747,6 +747,7 @@ int =
vmx_vpmu_initialise(struct vcpu *v, =0A         case 46:=0A         case =
47:=0A         case 58:=0A+        case 62:=0A             ret =3D =
core2_vpmu_initialise(v, vpmu_flags);=0A             if ( !ret )=0A        =
         vpmu->arch_vpmu_ops =3D &core2_vpmu_ops;=0A
--=__PartA5949DA5.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

--=__PartA5949DA5.1__=--


From xen-devel-bounces@lists.xen.org Fri Sep 28 08:20:49 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Sep 2012 08: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 1THVnV-0002Ns-Ll; Fri, 28 Sep 2012 08:19: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 1THVnU-0002Nn-Cn
	for xen-devel@lists.xen.org; Fri, 28 Sep 2012 08:19:44 +0000
Received: from [85.158.139.211:47638] by server-9.bemta-5.messagelabs.com id
	8E/A6-14846-F9D55605; Fri, 28 Sep 2012 08:19:43 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-4.tower-206.messagelabs.com!1348820382!20305144!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12119 invoked from network); 28 Sep 2012 08:19:42 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-4.tower-206.messagelabs.com with SMTP;
	28 Sep 2012 08:19:42 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 28 Sep 2012 09:19:41 +0100
Message-Id: <506579D5020000780009E66E@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 28 Sep 2012 09:20:05 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "Jun Nakajima" <jun.nakajima@intel.com>
References: <5056F7AB020000780009BB19@nat28.tlf.novell.com>
In-Reply-To: <5056F7AB020000780009BB19@nat28.tlf.novell.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__PartA5949DA5.1__="
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: [Xen-devel] Ping: [PATCH] x86/Intel: add further support for Ivy
 Bridge CPU models
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
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.

--=__PartA5949DA5.1__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

x86/Intel: add further support for Ivy Bridge CPU models

And some initial Haswell ones at once.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/arch/x86/acpi/cpu_idle.c
+++ b/xen/arch/x86/acpi/cpu_idle.c
@@ -128,11 +128,15 @@ static void do_get_hw_residencies(void *
=20
     switch ( c->x86_model )
     {
-    /* Ivy bridge */
-    case 0x3A:
     /* Sandy bridge */
     case 0x2A:
     case 0x2D:
+    /* Ivy bridge */
+    case 0x3A:
+    case 0x3E:
+    /* Haswell */
+    case 0x3c:
+    case 0x45:
         GET_PC2_RES(hw_res->pc2);
         GET_CC7_RES(hw_res->cc7);
         /* fall through */
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -1746,7 +1746,9 @@ static const struct lbr_info *last_branc
         /* Sandy Bridge */
         case 42: case 45:
         /* Ivy Bridge */
-        case 58:
+        case 58: case 62:
+        /* Haswell */
+        case 60: case 69:
             return nh_lbr;
             break;
         /* Atom */
--- a/xen/arch/x86/hvm/vmx/vpmu_core2.c
+++ b/xen/arch/x86/hvm/vmx/vpmu_core2.c
@@ -747,6 +747,7 @@ int vmx_vpmu_initialise(struct vcpu *v,=20
         case 46:
         case 47:
         case 58:
+        case 62:
             ret =3D core2_vpmu_initialise(v, vpmu_flags);
             if ( !ret )
                 vpmu->arch_vpmu_ops =3D &core2_vpmu_ops;




--=__PartA5949DA5.1__=
Content-Type: text/plain; name="x86-IvyBridge.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="x86-IvyBridge.patch"

x86/Intel: add further support for Ivy Bridge CPU models=0A=0AAnd some =
initial Haswell ones at once.=0A=0ASigned-off-by: Jan Beulich <jbeulich@sus=
e.com>=0A=0A--- a/xen/arch/x86/acpi/cpu_idle.c=0A+++ b/xen/arch/x86/acpi/cp=
u_idle.c=0A@@ -128,11 +128,15 @@ static void do_get_hw_residencies(void =
*=0A =0A     switch ( c->x86_model )=0A     {=0A-    /* Ivy bridge */=0A-  =
  case 0x3A:=0A     /* Sandy bridge */=0A     case 0x2A:=0A     case =
0x2D:=0A+    /* Ivy bridge */=0A+    case 0x3A:=0A+    case 0x3E:=0A+    =
/* Haswell */=0A+    case 0x3c:=0A+    case 0x45:=0A         GET_PC2_RES(hw=
_res->pc2);=0A         GET_CC7_RES(hw_res->cc7);=0A         /* fall =
through */=0A--- a/xen/arch/x86/hvm/vmx/vmx.c=0A+++ b/xen/arch/x86/hvm/vmx/=
vmx.c=0A@@ -1746,7 +1746,9 @@ static const struct lbr_info *last_branc=0A  =
       /* Sandy Bridge */=0A         case 42: case 45:=0A         /* Ivy =
Bridge */=0A-        case 58:=0A+        case 58: case 62:=0A+        /* =
Haswell */=0A+        case 60: case 69:=0A             return nh_lbr;=0A   =
          break;=0A         /* Atom */=0A--- a/xen/arch/x86/hvm/vmx/vpmu_co=
re2.c=0A+++ b/xen/arch/x86/hvm/vmx/vpmu_core2.c=0A@@ -747,6 +747,7 @@ int =
vmx_vpmu_initialise(struct vcpu *v, =0A         case 46:=0A         case =
47:=0A         case 58:=0A+        case 62:=0A             ret =3D =
core2_vpmu_initialise(v, vpmu_flags);=0A             if ( !ret )=0A        =
         vpmu->arch_vpmu_ops =3D &core2_vpmu_ops;=0A
--=__PartA5949DA5.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

--=__PartA5949DA5.1__=--


From xen-devel-bounces@lists.xen.org Fri Sep 28 08:22:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Sep 2012 08:22:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1THVoz-0002U5-B5; Fri, 28 Sep 2012 08:21:17 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1THVox-0002Tw-Vu
	for xen-devel@lists.xen.org; Fri, 28 Sep 2012 08:21:16 +0000
Received: from [85.158.139.211:62006] by server-6.bemta-5.messagelabs.com id
	C9/31-14717-BFD55605; Fri, 28 Sep 2012 08:21:15 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-16.tower-206.messagelabs.com!1348820473!20323892!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5665 invoked from network); 28 Sep 2012 08:21:13 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-16.tower-206.messagelabs.com with SMTP;
	28 Sep 2012 08:21:13 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 28 Sep 2012 09:21:13 +0100
Message-Id: <50657A31020000780009E672@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 28 Sep 2012 09:21:37 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
References: <505C6C93020000780009CF0C@nat28.tlf.novell.com>
In-Reply-To: <505C6C93020000780009CF0C@nat28.tlf.novell.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part02333A01.0__="
Subject: [Xen-devel] Ping: [PATCH] x86: replace literal numbers
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
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.

--=__Part02333A01.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

In various cases, 256 was being used instead of NR_VECTORS or a derived
ARRAY_SIZE() expression. In one case (guest_has_trap_callback()), a
wrong (unrelated) constant was used instead of NR_VECTORS.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -374,8 +374,9 @@ int switch_compat(struct domain *d)
=20
 static inline bool_t standalone_trap_ctxt(struct vcpu *v)
 {
-    BUILD_BUG_ON(256 * sizeof(*v->arch.pv_vcpu.trap_ctxt) > PAGE_SIZE);
-    return 256 * sizeof(*v->arch.pv_vcpu.trap_ctxt) + sizeof(*v) > =
PAGE_SIZE;
+    BUILD_BUG_ON(NR_VECTORS * sizeof(*v->arch.pv_vcpu.trap_ctxt) > =
PAGE_SIZE);
+    return NR_VECTORS * sizeof(*v->arch.pv_vcpu.trap_ctxt) + sizeof(*v)
+           > PAGE_SIZE;
 }
=20
 int vcpu_initialise(struct vcpu *v)
@@ -432,7 +433,7 @@ int vcpu_initialise(struct vcpu *v)
         }
         else
             v->arch.pv_vcpu.trap_ctxt =3D (void *)v + PAGE_SIZE -
-                256 * sizeof(*v->arch.pv_vcpu.trap_ctxt);
+                NR_VECTORS * sizeof(*v->arch.pv_vcpu.trap_ctxt);
=20
         /* PV guests by default have a 100Hz ticker. */
         v->periodic_period =3D MILLISECS(10);
@@ -702,7 +703,7 @@ int arch_set_info_guest(
             fixup_guest_stack_selector(d, c.nat->kernel_ss);
             fixup_guest_code_selector(d, c.nat->user_regs.cs);
=20
-            for ( i =3D 0; i < 256; i++ )
+            for ( i =3D 0; i < ARRAY_SIZE(c.nat->trap_ctxt); i++ )
             {
                 if ( !is_canonical_address(c.nat->trap_ctxt[i].address) )
                     return -EINVAL;
@@ -725,7 +726,7 @@ int arch_set_info_guest(
             fixup_guest_code_selector(d, c.cmp->event_callback_cs);
             fixup_guest_code_selector(d, c.cmp->failsafe_callback_cs);
=20
-            for ( i =3D 0; i < 256; i++ )
+            for ( i =3D 0; i < ARRAY_SIZE(c.cmp->trap_ctxt); i++ )
                 fixup_guest_code_selector(d, c.cmp->trap_ctxt[i].cs);
=20
             /* LDT safety checks. */
--- a/xen/arch/x86/traps.c
+++ b/xen/arch/x86/traps.c
@@ -3506,7 +3506,7 @@ int guest_has_trap_callback(struct domai
     BUG_ON(vcpuid >=3D d->max_vcpus);
=20
     /* Sanity check - XXX should be more fine grained. */
-    BUG_ON(trap_nr > TRAP_syscall);
+    BUG_ON(trap_nr >=3D NR_VECTORS);
=20
     v =3D d->vcpu[vcpuid];
     t =3D &v->arch.pv_vcpu.trap_ctxt[trap_nr];
@@ -3574,7 +3574,7 @@ long do_set_trap_table(XEN_GUEST_HANDLE(
     /* If no table is presented then clear the entire virtual IDT. */
     if ( guest_handle_is_null(traps) )
     {
-        memset(dst, 0, 256 * sizeof(*dst));
+        memset(dst, 0, NR_VECTORS * sizeof(*dst));
         init_int80_direct_trap(curr);
         return 0;
     }
--- a/xen/arch/x86/x86_64/compat/traps.c
+++ b/xen/arch/x86/x86_64/compat/traps.c
@@ -317,7 +317,7 @@ int compat_set_trap_table(XEN_GUEST_HAND
     /* If no table is presented then clear the entire virtual IDT. */
     if ( guest_handle_is_null(traps) )
     {
-        memset(dst, 0, 256 * sizeof(*dst));
+        memset(dst, 0, NR_VECTORS * sizeof(*dst));
         return 0;
     }
=20




--=__Part02333A01.0__=
Content-Type: text/plain; name="x86-use-NR_VECTORS.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="x86-use-NR_VECTORS.patch"

x86: replace literal numbers=0A=0AIn various cases, 256 was being used =
instead of NR_VECTORS or a derived=0AARRAY_SIZE() expression. In one case =
(guest_has_trap_callback()), a=0Awrong (unrelated) constant was used =
instead of NR_VECTORS.=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@@ =
-374,8 +374,9 @@ int switch_compat(struct domain *d)=0A =0A static inline =
bool_t standalone_trap_ctxt(struct vcpu *v)=0A {=0A-    BUILD_BUG_ON(256 * =
sizeof(*v->arch.pv_vcpu.trap_ctxt) > PAGE_SIZE);=0A-    return 256 * =
sizeof(*v->arch.pv_vcpu.trap_ctxt) + sizeof(*v) > PAGE_SIZE;=0A+    =
BUILD_BUG_ON(NR_VECTORS * sizeof(*v->arch.pv_vcpu.trap_ctxt) > PAGE_SIZE);=
=0A+    return NR_VECTORS * sizeof(*v->arch.pv_vcpu.trap_ctxt) + sizeof(*v)=
=0A+           > PAGE_SIZE;=0A }=0A =0A int vcpu_initialise(struct vcpu =
*v)=0A@@ -432,7 +433,7 @@ int vcpu_initialise(struct vcpu *v)=0A         =
}=0A         else=0A             v->arch.pv_vcpu.trap_ctxt =3D (void *)v + =
PAGE_SIZE -=0A-                256 * sizeof(*v->arch.pv_vcpu.trap_ctxt);=0A=
+                NR_VECTORS * sizeof(*v->arch.pv_vcpu.trap_ctxt);=0A =0A   =
      /* PV guests by default have a 100Hz ticker. */=0A         v->periodi=
c_period =3D MILLISECS(10);=0A@@ -702,7 +703,7 @@ int arch_set_info_guest(=
=0A             fixup_guest_stack_selector(d, c.nat->kernel_ss);=0A        =
     fixup_guest_code_selector(d, c.nat->user_regs.cs);=0A =0A-            =
for ( i =3D 0; i < 256; i++ )=0A+            for ( i =3D 0; i < ARRAY_SIZE(=
c.nat->trap_ctxt); i++ )=0A             {=0A                 if ( =
!is_canonical_address(c.nat->trap_ctxt[i].address) )=0A                    =
 return -EINVAL;=0A@@ -725,7 +726,7 @@ int arch_set_info_guest(=0A         =
    fixup_guest_code_selector(d, c.cmp->event_callback_cs);=0A             =
fixup_guest_code_selector(d, c.cmp->failsafe_callback_cs);=0A =0A-         =
   for ( i =3D 0; i < 256; i++ )=0A+            for ( i =3D 0; i < =
ARRAY_SIZE(c.cmp->trap_ctxt); i++ )=0A                 fixup_guest_code_sel=
ector(d, c.cmp->trap_ctxt[i].cs);=0A =0A             /* LDT safety checks. =
*/=0A--- a/xen/arch/x86/traps.c=0A+++ b/xen/arch/x86/traps.c=0A@@ -3506,7 =
+3506,7 @@ int guest_has_trap_callback(struct domai=0A     BUG_ON(vcpuid =
>=3D d->max_vcpus);=0A =0A     /* Sanity check - XXX should be more fine =
grained. */=0A-    BUG_ON(trap_nr > TRAP_syscall);=0A+    BUG_ON(trap_nr =
>=3D NR_VECTORS);=0A =0A     v =3D d->vcpu[vcpuid];=0A     t =3D &v->arch.p=
v_vcpu.trap_ctxt[trap_nr];=0A@@ -3574,7 +3574,7 @@ long do_set_trap_table(X=
EN_GUEST_HANDLE(=0A     /* If no table is presented then clear the entire =
virtual IDT. */=0A     if ( guest_handle_is_null(traps) )=0A     {=0A-     =
   memset(dst, 0, 256 * sizeof(*dst));=0A+        memset(dst, 0, NR_VECTORS=
 * sizeof(*dst));=0A         init_int80_direct_trap(curr);=0A         =
return 0;=0A     }=0A--- a/xen/arch/x86/x86_64/compat/traps.c=0A+++ =
b/xen/arch/x86/x86_64/compat/traps.c=0A@@ -317,7 +317,7 @@ int compat_set_t=
rap_table(XEN_GUEST_HAND=0A     /* If no table is presented then clear the =
entire virtual IDT. */=0A     if ( guest_handle_is_null(traps) )=0A     =
{=0A-        memset(dst, 0, 256 * sizeof(*dst));=0A+        memset(dst, 0, =
NR_VECTORS * sizeof(*dst));=0A         return 0;=0A     }=0A =0A
--=__Part02333A01.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

--=__Part02333A01.0__=--


From xen-devel-bounces@lists.xen.org Fri Sep 28 08:22:13 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Sep 2012 08:22:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1THVoz-0002U5-B5; Fri, 28 Sep 2012 08:21:17 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1THVox-0002Tw-Vu
	for xen-devel@lists.xen.org; Fri, 28 Sep 2012 08:21:16 +0000
Received: from [85.158.139.211:62006] by server-6.bemta-5.messagelabs.com id
	C9/31-14717-BFD55605; Fri, 28 Sep 2012 08:21:15 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-16.tower-206.messagelabs.com!1348820473!20323892!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5665 invoked from network); 28 Sep 2012 08:21:13 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-16.tower-206.messagelabs.com with SMTP;
	28 Sep 2012 08:21:13 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 28 Sep 2012 09:21:13 +0100
Message-Id: <50657A31020000780009E672@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 28 Sep 2012 09:21:37 +0100
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xen.org>
References: <505C6C93020000780009CF0C@nat28.tlf.novell.com>
In-Reply-To: <505C6C93020000780009CF0C@nat28.tlf.novell.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part02333A01.0__="
Subject: [Xen-devel] Ping: [PATCH] x86: replace literal numbers
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
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.

--=__Part02333A01.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

In various cases, 256 was being used instead of NR_VECTORS or a derived
ARRAY_SIZE() expression. In one case (guest_has_trap_callback()), a
wrong (unrelated) constant was used instead of NR_VECTORS.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -374,8 +374,9 @@ int switch_compat(struct domain *d)
=20
 static inline bool_t standalone_trap_ctxt(struct vcpu *v)
 {
-    BUILD_BUG_ON(256 * sizeof(*v->arch.pv_vcpu.trap_ctxt) > PAGE_SIZE);
-    return 256 * sizeof(*v->arch.pv_vcpu.trap_ctxt) + sizeof(*v) > =
PAGE_SIZE;
+    BUILD_BUG_ON(NR_VECTORS * sizeof(*v->arch.pv_vcpu.trap_ctxt) > =
PAGE_SIZE);
+    return NR_VECTORS * sizeof(*v->arch.pv_vcpu.trap_ctxt) + sizeof(*v)
+           > PAGE_SIZE;
 }
=20
 int vcpu_initialise(struct vcpu *v)
@@ -432,7 +433,7 @@ int vcpu_initialise(struct vcpu *v)
         }
         else
             v->arch.pv_vcpu.trap_ctxt =3D (void *)v + PAGE_SIZE -
-                256 * sizeof(*v->arch.pv_vcpu.trap_ctxt);
+                NR_VECTORS * sizeof(*v->arch.pv_vcpu.trap_ctxt);
=20
         /* PV guests by default have a 100Hz ticker. */
         v->periodic_period =3D MILLISECS(10);
@@ -702,7 +703,7 @@ int arch_set_info_guest(
             fixup_guest_stack_selector(d, c.nat->kernel_ss);
             fixup_guest_code_selector(d, c.nat->user_regs.cs);
=20
-            for ( i =3D 0; i < 256; i++ )
+            for ( i =3D 0; i < ARRAY_SIZE(c.nat->trap_ctxt); i++ )
             {
                 if ( !is_canonical_address(c.nat->trap_ctxt[i].address) )
                     return -EINVAL;
@@ -725,7 +726,7 @@ int arch_set_info_guest(
             fixup_guest_code_selector(d, c.cmp->event_callback_cs);
             fixup_guest_code_selector(d, c.cmp->failsafe_callback_cs);
=20
-            for ( i =3D 0; i < 256; i++ )
+            for ( i =3D 0; i < ARRAY_SIZE(c.cmp->trap_ctxt); i++ )
                 fixup_guest_code_selector(d, c.cmp->trap_ctxt[i].cs);
=20
             /* LDT safety checks. */
--- a/xen/arch/x86/traps.c
+++ b/xen/arch/x86/traps.c
@@ -3506,7 +3506,7 @@ int guest_has_trap_callback(struct domai
     BUG_ON(vcpuid >=3D d->max_vcpus);
=20
     /* Sanity check - XXX should be more fine grained. */
-    BUG_ON(trap_nr > TRAP_syscall);
+    BUG_ON(trap_nr >=3D NR_VECTORS);
=20
     v =3D d->vcpu[vcpuid];
     t =3D &v->arch.pv_vcpu.trap_ctxt[trap_nr];
@@ -3574,7 +3574,7 @@ long do_set_trap_table(XEN_GUEST_HANDLE(
     /* If no table is presented then clear the entire virtual IDT. */
     if ( guest_handle_is_null(traps) )
     {
-        memset(dst, 0, 256 * sizeof(*dst));
+        memset(dst, 0, NR_VECTORS * sizeof(*dst));
         init_int80_direct_trap(curr);
         return 0;
     }
--- a/xen/arch/x86/x86_64/compat/traps.c
+++ b/xen/arch/x86/x86_64/compat/traps.c
@@ -317,7 +317,7 @@ int compat_set_trap_table(XEN_GUEST_HAND
     /* If no table is presented then clear the entire virtual IDT. */
     if ( guest_handle_is_null(traps) )
     {
-        memset(dst, 0, 256 * sizeof(*dst));
+        memset(dst, 0, NR_VECTORS * sizeof(*dst));
         return 0;
     }
=20




--=__Part02333A01.0__=
Content-Type: text/plain; name="x86-use-NR_VECTORS.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="x86-use-NR_VECTORS.patch"

x86: replace literal numbers=0A=0AIn various cases, 256 was being used =
instead of NR_VECTORS or a derived=0AARRAY_SIZE() expression. In one case =
(guest_has_trap_callback()), a=0Awrong (unrelated) constant was used =
instead of NR_VECTORS.=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@@ =
-374,8 +374,9 @@ int switch_compat(struct domain *d)=0A =0A static inline =
bool_t standalone_trap_ctxt(struct vcpu *v)=0A {=0A-    BUILD_BUG_ON(256 * =
sizeof(*v->arch.pv_vcpu.trap_ctxt) > PAGE_SIZE);=0A-    return 256 * =
sizeof(*v->arch.pv_vcpu.trap_ctxt) + sizeof(*v) > PAGE_SIZE;=0A+    =
BUILD_BUG_ON(NR_VECTORS * sizeof(*v->arch.pv_vcpu.trap_ctxt) > PAGE_SIZE);=
=0A+    return NR_VECTORS * sizeof(*v->arch.pv_vcpu.trap_ctxt) + sizeof(*v)=
=0A+           > PAGE_SIZE;=0A }=0A =0A int vcpu_initialise(struct vcpu =
*v)=0A@@ -432,7 +433,7 @@ int vcpu_initialise(struct vcpu *v)=0A         =
}=0A         else=0A             v->arch.pv_vcpu.trap_ctxt =3D (void *)v + =
PAGE_SIZE -=0A-                256 * sizeof(*v->arch.pv_vcpu.trap_ctxt);=0A=
+                NR_VECTORS * sizeof(*v->arch.pv_vcpu.trap_ctxt);=0A =0A   =
      /* PV guests by default have a 100Hz ticker. */=0A         v->periodi=
c_period =3D MILLISECS(10);=0A@@ -702,7 +703,7 @@ int arch_set_info_guest(=
=0A             fixup_guest_stack_selector(d, c.nat->kernel_ss);=0A        =
     fixup_guest_code_selector(d, c.nat->user_regs.cs);=0A =0A-            =
for ( i =3D 0; i < 256; i++ )=0A+            for ( i =3D 0; i < ARRAY_SIZE(=
c.nat->trap_ctxt); i++ )=0A             {=0A                 if ( =
!is_canonical_address(c.nat->trap_ctxt[i].address) )=0A                    =
 return -EINVAL;=0A@@ -725,7 +726,7 @@ int arch_set_info_guest(=0A         =
    fixup_guest_code_selector(d, c.cmp->event_callback_cs);=0A             =
fixup_guest_code_selector(d, c.cmp->failsafe_callback_cs);=0A =0A-         =
   for ( i =3D 0; i < 256; i++ )=0A+            for ( i =3D 0; i < =
ARRAY_SIZE(c.cmp->trap_ctxt); i++ )=0A                 fixup_guest_code_sel=
ector(d, c.cmp->trap_ctxt[i].cs);=0A =0A             /* LDT safety checks. =
*/=0A--- a/xen/arch/x86/traps.c=0A+++ b/xen/arch/x86/traps.c=0A@@ -3506,7 =
+3506,7 @@ int guest_has_trap_callback(struct domai=0A     BUG_ON(vcpuid =
>=3D d->max_vcpus);=0A =0A     /* Sanity check - XXX should be more fine =
grained. */=0A-    BUG_ON(trap_nr > TRAP_syscall);=0A+    BUG_ON(trap_nr =
>=3D NR_VECTORS);=0A =0A     v =3D d->vcpu[vcpuid];=0A     t =3D &v->arch.p=
v_vcpu.trap_ctxt[trap_nr];=0A@@ -3574,7 +3574,7 @@ long do_set_trap_table(X=
EN_GUEST_HANDLE(=0A     /* If no table is presented then clear the entire =
virtual IDT. */=0A     if ( guest_handle_is_null(traps) )=0A     {=0A-     =
   memset(dst, 0, 256 * sizeof(*dst));=0A+        memset(dst, 0, NR_VECTORS=
 * sizeof(*dst));=0A         init_int80_direct_trap(curr);=0A         =
return 0;=0A     }=0A--- a/xen/arch/x86/x86_64/compat/traps.c=0A+++ =
b/xen/arch/x86/x86_64/compat/traps.c=0A@@ -317,7 +317,7 @@ int compat_set_t=
rap_table(XEN_GUEST_HAND=0A     /* If no table is presented then clear the =
entire virtual IDT. */=0A     if ( guest_handle_is_null(traps) )=0A     =
{=0A-        memset(dst, 0, 256 * sizeof(*dst));=0A+        memset(dst, 0, =
NR_VECTORS * sizeof(*dst));=0A         return 0;=0A     }=0A =0A
--=__Part02333A01.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

--=__Part02333A01.0__=--


From xen-devel-bounces@lists.xen.org Fri Sep 28 08:38:59 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Sep 2012 08: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 1THW5A-0002jZ-Up; Fri, 28 Sep 2012 08:38: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 1THW5A-0002jU-2K
	for xen-devel@lists.xen.org; Fri, 28 Sep 2012 08:38:00 +0000
Received: from [85.158.139.83:33663] by server-16.bemta-5.messagelabs.com id
	F7/7F-05998-7E165605; Fri, 28 Sep 2012 08:37:59 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1348821478!25288002!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-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26406 invoked from network); 28 Sep 2012 08:37:58 -0000
Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com)
	(74.125.83.45)
	by server-11.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Sep 2012 08:37:58 -0000
Received: by eekb47 with SMTP id b47so1405429eek.32
	for <xen-devel@lists.xen.org>; Fri, 28 Sep 2012 01:37:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=user-agent:date:subject:from:to:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=HTq8nV3d9TkroSc6wYv9otxO0i9j7tsH/ypuPleNzd4=;
	b=Do9mTAvu9UXAhWgv/JElvz+3sMJ45SY0o9iLiGE4LriqQpWy1EpqGzPuwCOymRNCgF
	X/mA3YpTQL9u8zmoUBvvCci8Lg2J4CYUIb+DoU9Ha/kZtpaUm0FFoMexWsfTTvOwQHNj
	KGHs53LMVLnLR2egnVRSUGlqzQL+3VtpkStePK3+YI2kSa2vNLj/T3xKB1MkGjEso1AM
	RIKReXJZqdmHmpuyvnrUV0Fyd0xCuIyQ1ZWVA5+RiX5KHWiQFCwg8vOEGx8Yd4trsC4G
	ggS8pyP2+wgdk+hz9aONIMAVZwjOaPDGn1C0EhVh+sEAYwNecV138PZ5wH2bu+8GCP/Z
	gWqA==
Received: by 10.14.203.70 with SMTP id e46mr9224415eeo.2.1348821478201;
	Fri, 28 Sep 2012 01:37:58 -0700 (PDT)
Received: from [192.168.1.69]
	(host86-160-224-180.range86-160.btcentralplus.com. [86.160.224.180])
	by mx.google.com with ESMTPS id 46sm24062302eef.17.2012.09.28.01.37.56
	(version=SSLv3 cipher=OTHER); Fri, 28 Sep 2012 01:37:57 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Fri, 28 Sep 2012 09:37:53 +0100
From: Keir Fraser <keir.xen@gmail.com>
To: Jan Beulich <JBeulich@suse.com>,
	xen-devel <xen-devel@lists.xen.org>
Message-ID: <CC8B2071.40176%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] Ping: [PATCH] x86: replace literal numbers
Thread-Index: Ac2dVIzhUxvbr8JHoUCvWxU3rdvItA==
In-Reply-To: <50657A31020000780009E672@nat28.tlf.novell.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] Ping: [PATCH] x86: replace literal numbers
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 28/09/2012 09:21, "Jan Beulich" <JBeulich@suse.com> wrote:

> In various cases, 256 was being used instead of NR_VECTORS or a derived
> ARRAY_SIZE() expression. In one case (guest_has_trap_callback()), a
> wrong (unrelated) constant was used instead of NR_VECTORS.
> 
> 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
> @@ -374,8 +374,9 @@ int switch_compat(struct domain *d)
>  
>  static inline bool_t standalone_trap_ctxt(struct vcpu *v)
>  {
> -    BUILD_BUG_ON(256 * sizeof(*v->arch.pv_vcpu.trap_ctxt) > PAGE_SIZE);
> -    return 256 * sizeof(*v->arch.pv_vcpu.trap_ctxt) + sizeof(*v) > PAGE_SIZE;
> +    BUILD_BUG_ON(NR_VECTORS * sizeof(*v->arch.pv_vcpu.trap_ctxt) >
> PAGE_SIZE);
> +    return NR_VECTORS * sizeof(*v->arch.pv_vcpu.trap_ctxt) + sizeof(*v)
> +           > PAGE_SIZE;
>  }
>  
>  int vcpu_initialise(struct vcpu *v)
> @@ -432,7 +433,7 @@ int vcpu_initialise(struct vcpu *v)
>          }
>          else
>              v->arch.pv_vcpu.trap_ctxt = (void *)v + PAGE_SIZE -
> -                256 * sizeof(*v->arch.pv_vcpu.trap_ctxt);
> +                NR_VECTORS * sizeof(*v->arch.pv_vcpu.trap_ctxt);
>  
>          /* PV guests by default have a 100Hz ticker. */
>          v->periodic_period = MILLISECS(10);
> @@ -702,7 +703,7 @@ int arch_set_info_guest(
>              fixup_guest_stack_selector(d, c.nat->kernel_ss);
>              fixup_guest_code_selector(d, c.nat->user_regs.cs);
>  
> -            for ( i = 0; i < 256; i++ )
> +            for ( i = 0; i < ARRAY_SIZE(c.nat->trap_ctxt); i++ )
>              {
>                  if ( !is_canonical_address(c.nat->trap_ctxt[i].address) )
>                      return -EINVAL;
> @@ -725,7 +726,7 @@ int arch_set_info_guest(
>              fixup_guest_code_selector(d, c.cmp->event_callback_cs);
>              fixup_guest_code_selector(d, c.cmp->failsafe_callback_cs);
>  
> -            for ( i = 0; i < 256; i++ )
> +            for ( i = 0; i < ARRAY_SIZE(c.cmp->trap_ctxt); i++ )
>                  fixup_guest_code_selector(d, c.cmp->trap_ctxt[i].cs);
>  
>              /* LDT safety checks. */
> --- a/xen/arch/x86/traps.c
> +++ b/xen/arch/x86/traps.c
> @@ -3506,7 +3506,7 @@ int guest_has_trap_callback(struct domai
>      BUG_ON(vcpuid >= d->max_vcpus);
>  
>      /* Sanity check - XXX should be more fine grained. */
> -    BUG_ON(trap_nr > TRAP_syscall);
> +    BUG_ON(trap_nr >= NR_VECTORS);
>  
>      v = d->vcpu[vcpuid];
>      t = &v->arch.pv_vcpu.trap_ctxt[trap_nr];
> @@ -3574,7 +3574,7 @@ long do_set_trap_table(XEN_GUEST_HANDLE(
>      /* If no table is presented then clear the entire virtual IDT. */
>      if ( guest_handle_is_null(traps) )
>      {
> -        memset(dst, 0, 256 * sizeof(*dst));
> +        memset(dst, 0, NR_VECTORS * sizeof(*dst));
>          init_int80_direct_trap(curr);
>          return 0;
>      }
> --- a/xen/arch/x86/x86_64/compat/traps.c
> +++ b/xen/arch/x86/x86_64/compat/traps.c
> @@ -317,7 +317,7 @@ int compat_set_trap_table(XEN_GUEST_HAND
>      /* If no table is presented then clear the entire virtual IDT. */
>      if ( guest_handle_is_null(traps) )
>      {
> -        memset(dst, 0, 256 * sizeof(*dst));
> +        memset(dst, 0, NR_VECTORS * sizeof(*dst));
>          return 0;
>      }
>  
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 28 08:38:59 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Sep 2012 08: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 1THW5A-0002jZ-Up; Fri, 28 Sep 2012 08:38: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 1THW5A-0002jU-2K
	for xen-devel@lists.xen.org; Fri, 28 Sep 2012 08:38:00 +0000
Received: from [85.158.139.83:33663] by server-16.bemta-5.messagelabs.com id
	F7/7F-05998-7E165605; Fri, 28 Sep 2012 08:37:59 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1348821478!25288002!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-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26406 invoked from network); 28 Sep 2012 08:37:58 -0000
Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com)
	(74.125.83.45)
	by server-11.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Sep 2012 08:37:58 -0000
Received: by eekb47 with SMTP id b47so1405429eek.32
	for <xen-devel@lists.xen.org>; Fri, 28 Sep 2012 01:37:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=user-agent:date:subject:from:to:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=HTq8nV3d9TkroSc6wYv9otxO0i9j7tsH/ypuPleNzd4=;
	b=Do9mTAvu9UXAhWgv/JElvz+3sMJ45SY0o9iLiGE4LriqQpWy1EpqGzPuwCOymRNCgF
	X/mA3YpTQL9u8zmoUBvvCci8Lg2J4CYUIb+DoU9Ha/kZtpaUm0FFoMexWsfTTvOwQHNj
	KGHs53LMVLnLR2egnVRSUGlqzQL+3VtpkStePK3+YI2kSa2vNLj/T3xKB1MkGjEso1AM
	RIKReXJZqdmHmpuyvnrUV0Fyd0xCuIyQ1ZWVA5+RiX5KHWiQFCwg8vOEGx8Yd4trsC4G
	ggS8pyP2+wgdk+hz9aONIMAVZwjOaPDGn1C0EhVh+sEAYwNecV138PZ5wH2bu+8GCP/Z
	gWqA==
Received: by 10.14.203.70 with SMTP id e46mr9224415eeo.2.1348821478201;
	Fri, 28 Sep 2012 01:37:58 -0700 (PDT)
Received: from [192.168.1.69]
	(host86-160-224-180.range86-160.btcentralplus.com. [86.160.224.180])
	by mx.google.com with ESMTPS id 46sm24062302eef.17.2012.09.28.01.37.56
	(version=SSLv3 cipher=OTHER); Fri, 28 Sep 2012 01:37:57 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Fri, 28 Sep 2012 09:37:53 +0100
From: Keir Fraser <keir.xen@gmail.com>
To: Jan Beulich <JBeulich@suse.com>,
	xen-devel <xen-devel@lists.xen.org>
Message-ID: <CC8B2071.40176%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] Ping: [PATCH] x86: replace literal numbers
Thread-Index: Ac2dVIzhUxvbr8JHoUCvWxU3rdvItA==
In-Reply-To: <50657A31020000780009E672@nat28.tlf.novell.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] Ping: [PATCH] x86: replace literal numbers
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 28/09/2012 09:21, "Jan Beulich" <JBeulich@suse.com> wrote:

> In various cases, 256 was being used instead of NR_VECTORS or a derived
> ARRAY_SIZE() expression. In one case (guest_has_trap_callback()), a
> wrong (unrelated) constant was used instead of NR_VECTORS.
> 
> 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
> @@ -374,8 +374,9 @@ int switch_compat(struct domain *d)
>  
>  static inline bool_t standalone_trap_ctxt(struct vcpu *v)
>  {
> -    BUILD_BUG_ON(256 * sizeof(*v->arch.pv_vcpu.trap_ctxt) > PAGE_SIZE);
> -    return 256 * sizeof(*v->arch.pv_vcpu.trap_ctxt) + sizeof(*v) > PAGE_SIZE;
> +    BUILD_BUG_ON(NR_VECTORS * sizeof(*v->arch.pv_vcpu.trap_ctxt) >
> PAGE_SIZE);
> +    return NR_VECTORS * sizeof(*v->arch.pv_vcpu.trap_ctxt) + sizeof(*v)
> +           > PAGE_SIZE;
>  }
>  
>  int vcpu_initialise(struct vcpu *v)
> @@ -432,7 +433,7 @@ int vcpu_initialise(struct vcpu *v)
>          }
>          else
>              v->arch.pv_vcpu.trap_ctxt = (void *)v + PAGE_SIZE -
> -                256 * sizeof(*v->arch.pv_vcpu.trap_ctxt);
> +                NR_VECTORS * sizeof(*v->arch.pv_vcpu.trap_ctxt);
>  
>          /* PV guests by default have a 100Hz ticker. */
>          v->periodic_period = MILLISECS(10);
> @@ -702,7 +703,7 @@ int arch_set_info_guest(
>              fixup_guest_stack_selector(d, c.nat->kernel_ss);
>              fixup_guest_code_selector(d, c.nat->user_regs.cs);
>  
> -            for ( i = 0; i < 256; i++ )
> +            for ( i = 0; i < ARRAY_SIZE(c.nat->trap_ctxt); i++ )
>              {
>                  if ( !is_canonical_address(c.nat->trap_ctxt[i].address) )
>                      return -EINVAL;
> @@ -725,7 +726,7 @@ int arch_set_info_guest(
>              fixup_guest_code_selector(d, c.cmp->event_callback_cs);
>              fixup_guest_code_selector(d, c.cmp->failsafe_callback_cs);
>  
> -            for ( i = 0; i < 256; i++ )
> +            for ( i = 0; i < ARRAY_SIZE(c.cmp->trap_ctxt); i++ )
>                  fixup_guest_code_selector(d, c.cmp->trap_ctxt[i].cs);
>  
>              /* LDT safety checks. */
> --- a/xen/arch/x86/traps.c
> +++ b/xen/arch/x86/traps.c
> @@ -3506,7 +3506,7 @@ int guest_has_trap_callback(struct domai
>      BUG_ON(vcpuid >= d->max_vcpus);
>  
>      /* Sanity check - XXX should be more fine grained. */
> -    BUG_ON(trap_nr > TRAP_syscall);
> +    BUG_ON(trap_nr >= NR_VECTORS);
>  
>      v = d->vcpu[vcpuid];
>      t = &v->arch.pv_vcpu.trap_ctxt[trap_nr];
> @@ -3574,7 +3574,7 @@ long do_set_trap_table(XEN_GUEST_HANDLE(
>      /* If no table is presented then clear the entire virtual IDT. */
>      if ( guest_handle_is_null(traps) )
>      {
> -        memset(dst, 0, 256 * sizeof(*dst));
> +        memset(dst, 0, NR_VECTORS * sizeof(*dst));
>          init_int80_direct_trap(curr);
>          return 0;
>      }
> --- a/xen/arch/x86/x86_64/compat/traps.c
> +++ b/xen/arch/x86/x86_64/compat/traps.c
> @@ -317,7 +317,7 @@ int compat_set_trap_table(XEN_GUEST_HAND
>      /* If no table is presented then clear the entire virtual IDT. */
>      if ( guest_handle_is_null(traps) )
>      {
> -        memset(dst, 0, 256 * sizeof(*dst));
> +        memset(dst, 0, NR_VECTORS * sizeof(*dst));
>          return 0;
>      }
>  
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 28 10:17:23 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Sep 2012 10:17: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 1THXcn-0003BN-RH; Fri, 28 Sep 2012 10:16:49 +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 1THXcl-0003BF-Tn
	for xen-devel@lists.xen.org; Fri, 28 Sep 2012 10:16:48 +0000
Received: from [85.158.139.83:52621] by server-15.bemta-5.messagelabs.com id
	18/D6-19430-F0975605; Fri, 28 Sep 2012 10:16:47 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1348827405!27999621!1
X-Originating-IP: [74.125.83.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28855 invoked from network); 28 Sep 2012 10:16:46 -0000
Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com)
	(74.125.83.45)
	by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Sep 2012 10:16:46 -0000
Received: by eekb47 with SMTP id b47so1457177eek.32
	for <xen-devel@lists.xen.org>; Fri, 28 Sep 2012 03:16:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
	bh=coTlIGlxMYChHRBqEEjD/D9dEoqcbNN1rCuf4dA7Bw4=;
	b=qg1xWBbpstV061k3DquKkmx2xee1n0H1Ehaty3Cmo3TrHylL1ihdgHR47ylbzaxl45
	6QhzFlMcF2YAGzSuCTy2ZvxYW51lQ5RRP0H5kTKnqh2UBCQxMr+5cNvZTk9VsZdYz6t1
	nqrDRMZMHl9tatwpdYAj/HAV2YR8k3dak3ELKWz6xvob3rpyQqkhynxV7gDLXOncbxPK
	1J0+YLYAeyViRbdO/xZAMEbvsvUrZb4mg1PXgRs02tyjvOs8wipRb/lldX74g9/Vbc2s
	SvBzE/b34EAVz8c3wMSd8K+802qbJPJjRw1SP9s+uTJZO6FWrK06dLB/IqVmaK1y7PHw
	CGTA==
MIME-Version: 1.0
Received: by 10.14.212.72 with SMTP id x48mr9200103eeo.40.1348827405614; Fri,
	28 Sep 2012 03:16:45 -0700 (PDT)
Received: by 10.14.215.195 with HTTP; Fri, 28 Sep 2012 03:16:45 -0700 (PDT)
In-Reply-To: <1348765802-11314-1-git-send-email-matthew.fioravante@jhuapl.edu>
References: <1348765802-11314-1-git-send-email-matthew.fioravante@jhuapl.edu>
Date: Fri, 28 Sep 2012 11:16:45 +0100
X-Google-Sender-Auth: lROmhDwJujF3Eu6UhFVOmFd0Wa8
Message-ID: <CAFLBxZYaDJZW7rXTnzo4UtxJbfggZz86Szw4O=30q2RxtNocBg@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
Cc: samuel.thibault@ens-lyon.org, Ian.Campbell@citrix.com,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 01/11] Add ioread/iowrite functions to
	mini-os
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Sep 27, 2012 at 6:09 PM, Matthew Fioravante
<matthew.fioravante@jhuapl.edu> wrote:
> This patch adds iowritexx() and ioreadxx() functions for interacting
> with hardware memory to mini-os. The functions are available in a header
> iorw.h
>
> Signed-off-by: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
> Acked-by: Samuel Thibault <samuel.thibault@ens-lyon.org>
>
> diff --git a/extras/mini-os/arch/ia64/iorw.c b/extras/mini-os/arch/ia64/iorw.c

Is there any reason to have the ia64 stuff? ia64 isn't supported in
Xen anymore, AFAIK.

 -George

> new file mode 100644
> index 0000000..aa58807
> --- /dev/null
> +++ b/extras/mini-os/arch/ia64/iorw.c
> @@ -0,0 +1,48 @@
> +#include <mini-os/iorw.h>
> +#include <mini-os/console.h>
> +
> +void iowrite8(volatile void* addr, uint8_t val)
> +{
> +   printk("iorw not implemented!!\n");
> +   BUG();
> +}
> +void iowrite16(volatile void* addr, uint16_t val)
> +{
> +   printk("iorw not implemented!!\n");
> +   BUG();
> +}
> +void iowrite32(volatile void* addr, uint32_t val)
> +{
> +   printk("iorw not implemented!!\n");
> +   BUG();
> +}
> +void iowrite64(volatile void* addr, uint64_t val)
> +{
> +   printk("iorw not implemented!!\n");
> +   BUG();
> +}
> +
> +uint8_t ioread8(volatile void* addr)
> +{
> +   printk("iorw not implemented!!\n");
> +   BUG();
> +   return 0;
> +}
> +uint16_t ioread16(volatile void* addr)
> +{
> +   printk("iorw not implemented!!\n");
> +   BUG();
> +   return 0;
> +}
> +uint32_t ioread32(volatile void* addr)
> +{
> +   printk("iorw not implemented!!\n");
> +   BUG();
> +   return 0;
> +}
> +uint64_t ioread64(volatile void* addr)
> +{
> +   printk("iorw not implemented!!\n");
> +   BUG();
> +   return 0;
> +}
> diff --git a/extras/mini-os/arch/x86/iorw.c b/extras/mini-os/arch/x86/iorw.c
> new file mode 100644
> index 0000000..3080769
> --- /dev/null
> +++ b/extras/mini-os/arch/x86/iorw.c
> @@ -0,0 +1,35 @@
> +#include <mini-os/iorw.h>
> +
> +void iowrite8(volatile void* addr, uint8_t val)
> +{
> +   *((volatile uint8_t*)addr) = val;
> +}
> +void iowrite16(volatile void* addr, uint16_t val)
> +{
> +   *((volatile uint16_t*)addr) = val;
> +}
> +void iowrite32(volatile void* addr, uint32_t val)
> +{
> +   *((volatile uint32_t*)addr) = val;
> +}
> +void iowrite64(volatile void* addr, uint64_t val)
> +{
> +   *((volatile uint64_t*)addr) = val;
> +}
> +
> +uint8_t ioread8(volatile void* addr)
> +{
> +   return *((volatile uint8_t*) addr);
> +}
> +uint16_t ioread16(volatile void* addr)
> +{
> +   return *((volatile uint16_t*) addr);
> +}
> +uint32_t ioread32(volatile void* addr)
> +{
> +   return *((volatile uint32_t*) addr);
> +}
> +uint64_t ioread64(volatile void* addr)
> +{
> +   return *((volatile uint64_t*) addr);
> +}
> diff --git a/extras/mini-os/include/iorw.h b/extras/mini-os/include/iorw.h
> new file mode 100644
> index 0000000..d5ec065
> --- /dev/null
> +++ b/extras/mini-os/include/iorw.h
> @@ -0,0 +1,16 @@
> +#ifndef MINIOS_IORW_H
> +#define MINIOS_IORW_H
> +
> +#include <mini-os/types.h>
> +
> +void iowrite8(volatile void* addr, uint8_t val);
> +void iowrite16(volatile void* addr, uint16_t val);
> +void iowrite32(volatile void* addr, uint32_t val);
> +void iowrite64(volatile void* addr, uint64_t val);
> +
> +uint8_t ioread8(volatile void* addr);
> +uint16_t ioread16(volatile void* addr);
> +uint32_t ioread32(volatile void* addr);
> +uint64_t ioread64(volatile void* addr);
> +
> +#endif
> --
> 1.7.9.5
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 28 10:17:23 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Sep 2012 10:17: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 1THXcn-0003BN-RH; Fri, 28 Sep 2012 10:16:49 +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 1THXcl-0003BF-Tn
	for xen-devel@lists.xen.org; Fri, 28 Sep 2012 10:16:48 +0000
Received: from [85.158.139.83:52621] by server-15.bemta-5.messagelabs.com id
	18/D6-19430-F0975605; Fri, 28 Sep 2012 10:16:47 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1348827405!27999621!1
X-Originating-IP: [74.125.83.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28855 invoked from network); 28 Sep 2012 10:16:46 -0000
Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com)
	(74.125.83.45)
	by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Sep 2012 10:16:46 -0000
Received: by eekb47 with SMTP id b47so1457177eek.32
	for <xen-devel@lists.xen.org>; Fri, 28 Sep 2012 03:16:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
	bh=coTlIGlxMYChHRBqEEjD/D9dEoqcbNN1rCuf4dA7Bw4=;
	b=qg1xWBbpstV061k3DquKkmx2xee1n0H1Ehaty3Cmo3TrHylL1ihdgHR47ylbzaxl45
	6QhzFlMcF2YAGzSuCTy2ZvxYW51lQ5RRP0H5kTKnqh2UBCQxMr+5cNvZTk9VsZdYz6t1
	nqrDRMZMHl9tatwpdYAj/HAV2YR8k3dak3ELKWz6xvob3rpyQqkhynxV7gDLXOncbxPK
	1J0+YLYAeyViRbdO/xZAMEbvsvUrZb4mg1PXgRs02tyjvOs8wipRb/lldX74g9/Vbc2s
	SvBzE/b34EAVz8c3wMSd8K+802qbJPJjRw1SP9s+uTJZO6FWrK06dLB/IqVmaK1y7PHw
	CGTA==
MIME-Version: 1.0
Received: by 10.14.212.72 with SMTP id x48mr9200103eeo.40.1348827405614; Fri,
	28 Sep 2012 03:16:45 -0700 (PDT)
Received: by 10.14.215.195 with HTTP; Fri, 28 Sep 2012 03:16:45 -0700 (PDT)
In-Reply-To: <1348765802-11314-1-git-send-email-matthew.fioravante@jhuapl.edu>
References: <1348765802-11314-1-git-send-email-matthew.fioravante@jhuapl.edu>
Date: Fri, 28 Sep 2012 11:16:45 +0100
X-Google-Sender-Auth: lROmhDwJujF3Eu6UhFVOmFd0Wa8
Message-ID: <CAFLBxZYaDJZW7rXTnzo4UtxJbfggZz86Szw4O=30q2RxtNocBg@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
Cc: samuel.thibault@ens-lyon.org, Ian.Campbell@citrix.com,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 01/11] Add ioread/iowrite functions to
	mini-os
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Sep 27, 2012 at 6:09 PM, Matthew Fioravante
<matthew.fioravante@jhuapl.edu> wrote:
> This patch adds iowritexx() and ioreadxx() functions for interacting
> with hardware memory to mini-os. The functions are available in a header
> iorw.h
>
> Signed-off-by: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
> Acked-by: Samuel Thibault <samuel.thibault@ens-lyon.org>
>
> diff --git a/extras/mini-os/arch/ia64/iorw.c b/extras/mini-os/arch/ia64/iorw.c

Is there any reason to have the ia64 stuff? ia64 isn't supported in
Xen anymore, AFAIK.

 -George

> new file mode 100644
> index 0000000..aa58807
> --- /dev/null
> +++ b/extras/mini-os/arch/ia64/iorw.c
> @@ -0,0 +1,48 @@
> +#include <mini-os/iorw.h>
> +#include <mini-os/console.h>
> +
> +void iowrite8(volatile void* addr, uint8_t val)
> +{
> +   printk("iorw not implemented!!\n");
> +   BUG();
> +}
> +void iowrite16(volatile void* addr, uint16_t val)
> +{
> +   printk("iorw not implemented!!\n");
> +   BUG();
> +}
> +void iowrite32(volatile void* addr, uint32_t val)
> +{
> +   printk("iorw not implemented!!\n");
> +   BUG();
> +}
> +void iowrite64(volatile void* addr, uint64_t val)
> +{
> +   printk("iorw not implemented!!\n");
> +   BUG();
> +}
> +
> +uint8_t ioread8(volatile void* addr)
> +{
> +   printk("iorw not implemented!!\n");
> +   BUG();
> +   return 0;
> +}
> +uint16_t ioread16(volatile void* addr)
> +{
> +   printk("iorw not implemented!!\n");
> +   BUG();
> +   return 0;
> +}
> +uint32_t ioread32(volatile void* addr)
> +{
> +   printk("iorw not implemented!!\n");
> +   BUG();
> +   return 0;
> +}
> +uint64_t ioread64(volatile void* addr)
> +{
> +   printk("iorw not implemented!!\n");
> +   BUG();
> +   return 0;
> +}
> diff --git a/extras/mini-os/arch/x86/iorw.c b/extras/mini-os/arch/x86/iorw.c
> new file mode 100644
> index 0000000..3080769
> --- /dev/null
> +++ b/extras/mini-os/arch/x86/iorw.c
> @@ -0,0 +1,35 @@
> +#include <mini-os/iorw.h>
> +
> +void iowrite8(volatile void* addr, uint8_t val)
> +{
> +   *((volatile uint8_t*)addr) = val;
> +}
> +void iowrite16(volatile void* addr, uint16_t val)
> +{
> +   *((volatile uint16_t*)addr) = val;
> +}
> +void iowrite32(volatile void* addr, uint32_t val)
> +{
> +   *((volatile uint32_t*)addr) = val;
> +}
> +void iowrite64(volatile void* addr, uint64_t val)
> +{
> +   *((volatile uint64_t*)addr) = val;
> +}
> +
> +uint8_t ioread8(volatile void* addr)
> +{
> +   return *((volatile uint8_t*) addr);
> +}
> +uint16_t ioread16(volatile void* addr)
> +{
> +   return *((volatile uint16_t*) addr);
> +}
> +uint32_t ioread32(volatile void* addr)
> +{
> +   return *((volatile uint32_t*) addr);
> +}
> +uint64_t ioread64(volatile void* addr)
> +{
> +   return *((volatile uint64_t*) addr);
> +}
> diff --git a/extras/mini-os/include/iorw.h b/extras/mini-os/include/iorw.h
> new file mode 100644
> index 0000000..d5ec065
> --- /dev/null
> +++ b/extras/mini-os/include/iorw.h
> @@ -0,0 +1,16 @@
> +#ifndef MINIOS_IORW_H
> +#define MINIOS_IORW_H
> +
> +#include <mini-os/types.h>
> +
> +void iowrite8(volatile void* addr, uint8_t val);
> +void iowrite16(volatile void* addr, uint16_t val);
> +void iowrite32(volatile void* addr, uint32_t val);
> +void iowrite64(volatile void* addr, uint64_t val);
> +
> +uint8_t ioread8(volatile void* addr);
> +uint16_t ioread16(volatile void* addr);
> +uint32_t ioread32(volatile void* addr);
> +uint64_t ioread64(volatile void* addr);
> +
> +#endif
> --
> 1.7.9.5
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 28 10:22:23 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Sep 2012 10:22:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1THXhe-0003JP-M1; Fri, 28 Sep 2012 10:21:50 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony.perard@citrix.com>) id 1THXhc-0003JK-KK
	for xen-devel@lists.xen.org; Fri, 28 Sep 2012 10:21:48 +0000
Received: from [85.158.139.83:30334] by server-9.bemta-5.messagelabs.com id
	A8/51-14846-B3A75605; Fri, 28 Sep 2012 10:21:47 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1348827705!30334025!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNzgzODM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32345 invoked from network); 28 Sep 2012 10:21:46 -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;
	28 Sep 2012 10:21:46 -0000
X-IronPort-AV: E=Sophos;i="4.80,501,1344211200"; d="scan'208";a="209671018"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Sep 2012 10:21:45 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Fri, 28 Sep 2012 06:21:44 -0400
Received: from [10.80.3.61]	by ukmail1.uk.xensource.com with esmtp (Exim 4.69)
	(envelope-from <anthony.perard@citrix.com>)	id 1THXhY-0004yA-Dx;
	Fri, 28 Sep 2012 11:21:44 +0100
Message-ID: <50657A38.5070109@citrix.com>
Date: Fri, 28 Sep 2012 11:21:44 +0100
From: Anthony PERARD <anthony.perard@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120910 Thunderbird/15.0.1
MIME-Version: 1.0
To: L D <lethalduck@gmail.com>
References: <CAPGwcLKjHOgwEGjDpQcymUjkv4eAzOVxN5mOKAtQ2UE3Bc4g9Q@mail.gmail.com>
In-Reply-To: <CAPGwcLKjHOgwEGjDpQcymUjkv4eAzOVxN5mOKAtQ2UE3Bc4g9Q@mail.gmail.com>
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Xen 4.2 and USB
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 09/28/2012 03:51 AM, L D wrote:
> Hello!
> So I compiled and am running the 4.2 release...did the ./configure;
> make world; make install
> It works, and am running an ati vga passthrough windows system, except
> for usb and sound...
> 
> I have a couple of questions, if you can help me with some of these it
> would be appreciated.
> 
> How do I run qemu upstream in this release? I'm trying to have sound
> in win7 64bit sound but I can't get qemu upstream to work.
> Anybody have success with win7 sound?
> I'm using device_model_override='/usr/lib/xen/bin/qemu-system-i386'

To use qemu upstream, you should use:
device_model_version = "qemu-xen"

Here, device_model_override is not needed. But PCI/VGA passthrough is
not supported by the QEMU upstream shipped with Xen 4.2.

> Finally how do I connect to the qemu console?? ctrl-alt-shift-2,1 just
> show me blank screens (console=1), I have no way to pass additional
> usb devices by usb-adding them.

For consoles: use
shell$ xl console domain

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 Sep 28 10:22:23 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Sep 2012 10:22:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1THXhe-0003JP-M1; Fri, 28 Sep 2012 10:21:50 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony.perard@citrix.com>) id 1THXhc-0003JK-KK
	for xen-devel@lists.xen.org; Fri, 28 Sep 2012 10:21:48 +0000
Received: from [85.158.139.83:30334] by server-9.bemta-5.messagelabs.com id
	A8/51-14846-B3A75605; Fri, 28 Sep 2012 10:21:47 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1348827705!30334025!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNzgzODM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32345 invoked from network); 28 Sep 2012 10:21:46 -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;
	28 Sep 2012 10:21:46 -0000
X-IronPort-AV: E=Sophos;i="4.80,501,1344211200"; d="scan'208";a="209671018"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Sep 2012 10:21:45 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.65) with Microsoft SMTP Server id 8.3.279.1;
	Fri, 28 Sep 2012 06:21:44 -0400
Received: from [10.80.3.61]	by ukmail1.uk.xensource.com with esmtp (Exim 4.69)
	(envelope-from <anthony.perard@citrix.com>)	id 1THXhY-0004yA-Dx;
	Fri, 28 Sep 2012 11:21:44 +0100
Message-ID: <50657A38.5070109@citrix.com>
Date: Fri, 28 Sep 2012 11:21:44 +0100
From: Anthony PERARD <anthony.perard@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120910 Thunderbird/15.0.1
MIME-Version: 1.0
To: L D <lethalduck@gmail.com>
References: <CAPGwcLKjHOgwEGjDpQcymUjkv4eAzOVxN5mOKAtQ2UE3Bc4g9Q@mail.gmail.com>
In-Reply-To: <CAPGwcLKjHOgwEGjDpQcymUjkv4eAzOVxN5mOKAtQ2UE3Bc4g9Q@mail.gmail.com>
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Xen 4.2 and USB
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 09/28/2012 03:51 AM, L D wrote:
> Hello!
> So I compiled and am running the 4.2 release...did the ./configure;
> make world; make install
> It works, and am running an ati vga passthrough windows system, except
> for usb and sound...
> 
> I have a couple of questions, if you can help me with some of these it
> would be appreciated.
> 
> How do I run qemu upstream in this release? I'm trying to have sound
> in win7 64bit sound but I can't get qemu upstream to work.
> Anybody have success with win7 sound?
> I'm using device_model_override='/usr/lib/xen/bin/qemu-system-i386'

To use qemu upstream, you should use:
device_model_version = "qemu-xen"

Here, device_model_override is not needed. But PCI/VGA passthrough is
not supported by the QEMU upstream shipped with Xen 4.2.

> Finally how do I connect to the qemu console?? ctrl-alt-shift-2,1 just
> show me blank screens (console=1), I have no way to pass additional
> usb devices by usb-adding them.

For consoles: use
shell$ xl console domain

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 Sep 28 10:35:52 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Sep 2012 10: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 1THXuk-0003Ut-0o; Fri, 28 Sep 2012 10:35:22 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <zhenzhong.duan@oracle.com>) id 1THXuj-0003Uo-01
	for xen-devel@lists.xen.org; Fri, 28 Sep 2012 10:35:21 +0000
X-Env-Sender: zhenzhong.duan@oracle.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1348828512!3417692!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDc4MTcyOA==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16009 invoked from network); 28 Sep 2012 10:35:14 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-11.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 28 Sep 2012 10:35:14 -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 q8SAZ9j4022552
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 28 Sep 2012 10:35:10 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
	q8SAZ8O8011664
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 28 Sep 2012 10:35:09 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
	q8SAZ8KL029406; Fri, 28 Sep 2012 05:35:08 -0500
Received: from [10.191.15.244] (/10.191.15.244)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 28 Sep 2012 03:35:08 -0700
Message-ID: <50657D4B.9040303@oracle.com>
Date: Fri, 28 Sep 2012 18:34:51 +0800
From: Zhenzhong Duan <zhenzhong.duan@oracle.com>
Organization: oracle
User-Agent: Mozilla/5.0 (Windows NT 5.1;
	rv:12.0) Gecko/20120428 Thunderbird/12.0.1
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
References: <505C3647.1030003@oracle.com>
	<20120921143430.GA3522@phenom.dumpdata.com>
	<5062C16A.1020306@oracle.com>
	<20120926123534.GF7356@phenom.dumpdata.com>
	<5063EAFB.1070307@oracle.com>
	<20120927115918.GE8832@phenom.dumpdata.com>
In-Reply-To: <20120927115918.GE8832@phenom.dumpdata.com>
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: Konrad Rzeszutek Wilk <konrad@kernel.org>,
	Dan Magenheimer <dan.magenheimer@oracle.com>,
	Feng Jin <joe.jin@oracle.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] an issue with 'xm save'
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: zhenzhong.duan@oracle.com
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 2012-09-27 19:59, Konrad Rzeszutek Wilk wrote:
> On Thu, Sep 27, 2012 at 01:58:19PM +0800, Zhenzhong Duan wrote:
>>
>> On 2012-09-26 20:35, Konrad Rzeszutek Wilk wrote:
>>> On Wed, Sep 26, 2012 at 04:48:42PM +0800, Zhenzhong Duan wrote:
>>>> Konrad Rzeszutek Wilk wrote:
>>>>> On Fri, Sep 21, 2012 at 05:41:27PM +0800, Zhenzhong Duan wrote:
>>>>>> Hi maintainers,
>>>>>>
>>>>>> I found there is an issue when 'xm save' a pvm guest. See below:
>>>>>>
>>>>>> When I do save then restore once, CPU(%) in xentop showed around 99%.
>>>>>> When I do that second time, CPU(%) showed 199%
>>>>>>
>>>>>> top in dom0 showed:
>>>>>>      PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
>>>>>>     20946 root      18  -2 10984 1284  964 S 19.8  0.3   0:48.93 block
>>>>>>     4939 root      18  -2 10984 1288  964 S 19.5  0.3   1:34.68 block
>>>>>>
>>>>>> I could kill the block process, then all look normal again.
>>>>> What is the 'block' process? If you attach 'perf' to it do you get an idea
>>>>> of what it is spinning at?
>>>> It's /etc/xen/scripts/block
>>>> I add 'set -x' to /etc/xen/scripts/block, found it blocked at claim_lock.
>>>> When domU was created first time, claim_lock/release_lock finished quickly,
>>>> when 'xm save' was called, claim_lock spin in its own while loop.
>>>> I can ensure no other domU create/save/etc happen when I test.
>>> OK, so how come you have two block processes? Is it b/c you have two
>>> disks attached to the guest? The are multiple claim_lock in the shell
>>> script - do you know where each of two threads are spinning? Are they
>>> spinning on the same function?
>> In above test, I run save/restore twice, so two block processes.
>> In other test, run save/restore once, there is only one block process.
>> After do 'xm save', I see block process spin at line 328:
>> 321   remove)
>> 322     case $t in
>> 323       phy)
>> 324         exit 0
>> 325         ;;
>> 326
>> 327       file)
>> 328         claim_lock "block"
>> 329         node=$(xenstore_read "$XENBUS_PATH/node")
>> 330         losetup -d "$node"
>> 331         release_lock "block"
>> 332         exit 0
>> 333         ;;
> So with the patches in OVM - do they have this fixed? Can they be upstreamed
> or are the dependent on some magic OVM sauce?
After replace locking.sh with OVM's, it worked.
But xen-tools evolved to use flock based locking currently. We can't 
revert back.
It seems changeset 25595:497e2fe49455 bring the issue.
Finally, I came with a small patch that workaround the issue.

diff -r d364becfb083 tools/hotplug/Linux/locking.sh
--- a/tools/hotplug/Linux/locking.sh    Thu Sep 20 13:31:19 2012 +0200
+++ b/tools/hotplug/Linux/locking.sh    Fri Sep 28 18:27:31 2012 +0800
@@ -66,6 +66,7 @@
  release_lock()
  {
      _setlockfd $1
+    flock -u $_lockfd
      rm "$_lockfile"
  }

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 28 10:35:52 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Sep 2012 10: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 1THXuk-0003Ut-0o; Fri, 28 Sep 2012 10:35:22 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <zhenzhong.duan@oracle.com>) id 1THXuj-0003Uo-01
	for xen-devel@lists.xen.org; Fri, 28 Sep 2012 10:35:21 +0000
X-Env-Sender: zhenzhong.duan@oracle.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1348828512!3417692!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDc4MTcyOA==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16009 invoked from network); 28 Sep 2012 10:35:14 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-11.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 28 Sep 2012 10:35:14 -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 q8SAZ9j4022552
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 28 Sep 2012 10:35:10 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
	q8SAZ8O8011664
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 28 Sep 2012 10:35:09 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
	q8SAZ8KL029406; Fri, 28 Sep 2012 05:35:08 -0500
Received: from [10.191.15.244] (/10.191.15.244)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 28 Sep 2012 03:35:08 -0700
Message-ID: <50657D4B.9040303@oracle.com>
Date: Fri, 28 Sep 2012 18:34:51 +0800
From: Zhenzhong Duan <zhenzhong.duan@oracle.com>
Organization: oracle
User-Agent: Mozilla/5.0 (Windows NT 5.1;
	rv:12.0) Gecko/20120428 Thunderbird/12.0.1
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
References: <505C3647.1030003@oracle.com>
	<20120921143430.GA3522@phenom.dumpdata.com>
	<5062C16A.1020306@oracle.com>
	<20120926123534.GF7356@phenom.dumpdata.com>
	<5063EAFB.1070307@oracle.com>
	<20120927115918.GE8832@phenom.dumpdata.com>
In-Reply-To: <20120927115918.GE8832@phenom.dumpdata.com>
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: Konrad Rzeszutek Wilk <konrad@kernel.org>,
	Dan Magenheimer <dan.magenheimer@oracle.com>,
	Feng Jin <joe.jin@oracle.com>, xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] an issue with 'xm save'
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: zhenzhong.duan@oracle.com
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 2012-09-27 19:59, Konrad Rzeszutek Wilk wrote:
> On Thu, Sep 27, 2012 at 01:58:19PM +0800, Zhenzhong Duan wrote:
>>
>> On 2012-09-26 20:35, Konrad Rzeszutek Wilk wrote:
>>> On Wed, Sep 26, 2012 at 04:48:42PM +0800, Zhenzhong Duan wrote:
>>>> Konrad Rzeszutek Wilk wrote:
>>>>> On Fri, Sep 21, 2012 at 05:41:27PM +0800, Zhenzhong Duan wrote:
>>>>>> Hi maintainers,
>>>>>>
>>>>>> I found there is an issue when 'xm save' a pvm guest. See below:
>>>>>>
>>>>>> When I do save then restore once, CPU(%) in xentop showed around 99%.
>>>>>> When I do that second time, CPU(%) showed 199%
>>>>>>
>>>>>> top in dom0 showed:
>>>>>>      PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
>>>>>>     20946 root      18  -2 10984 1284  964 S 19.8  0.3   0:48.93 block
>>>>>>     4939 root      18  -2 10984 1288  964 S 19.5  0.3   1:34.68 block
>>>>>>
>>>>>> I could kill the block process, then all look normal again.
>>>>> What is the 'block' process? If you attach 'perf' to it do you get an idea
>>>>> of what it is spinning at?
>>>> It's /etc/xen/scripts/block
>>>> I add 'set -x' to /etc/xen/scripts/block, found it blocked at claim_lock.
>>>> When domU was created first time, claim_lock/release_lock finished quickly,
>>>> when 'xm save' was called, claim_lock spin in its own while loop.
>>>> I can ensure no other domU create/save/etc happen when I test.
>>> OK, so how come you have two block processes? Is it b/c you have two
>>> disks attached to the guest? The are multiple claim_lock in the shell
>>> script - do you know where each of two threads are spinning? Are they
>>> spinning on the same function?
>> In above test, I run save/restore twice, so two block processes.
>> In other test, run save/restore once, there is only one block process.
>> After do 'xm save', I see block process spin at line 328:
>> 321   remove)
>> 322     case $t in
>> 323       phy)
>> 324         exit 0
>> 325         ;;
>> 326
>> 327       file)
>> 328         claim_lock "block"
>> 329         node=$(xenstore_read "$XENBUS_PATH/node")
>> 330         losetup -d "$node"
>> 331         release_lock "block"
>> 332         exit 0
>> 333         ;;
> So with the patches in OVM - do they have this fixed? Can they be upstreamed
> or are the dependent on some magic OVM sauce?
After replace locking.sh with OVM's, it worked.
But xen-tools evolved to use flock based locking currently. We can't 
revert back.
It seems changeset 25595:497e2fe49455 bring the issue.
Finally, I came with a small patch that workaround the issue.

diff -r d364becfb083 tools/hotplug/Linux/locking.sh
--- a/tools/hotplug/Linux/locking.sh    Thu Sep 20 13:31:19 2012 +0200
+++ b/tools/hotplug/Linux/locking.sh    Fri Sep 28 18:27:31 2012 +0800
@@ -66,6 +66,7 @@
  release_lock()
  {
      _setlockfd $1
+    flock -u $_lockfd
      rm "$_lockfile"
  }

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 28 10:37:58 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Sep 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 1THXwh-0003bh-MW; Fri, 28 Sep 2012 10:37:23 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dunlapg@gmail.com>) id 1THXwg-0003bZ-9X
	for xen-devel@lists.xen.org; Fri, 28 Sep 2012 10:37:22 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1348828594!5723357!1
X-Originating-IP: [209.85.215.173]
X-SpamReason: No, hits=1.7 required=7.0 tests=INFO_TLD,RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17620 invoked from network); 28 Sep 2012 10:36:35 -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;
	28 Sep 2012 10:36:35 -0000
Received: by eaaa1 with SMTP id a1so1048564eaa.32
	for <xen-devel@lists.xen.org>; Fri, 28 Sep 2012 03:36: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;
	bh=na0BQW+A8dQOCzZJdg5ycaHzNLUbEXt38UpolvOHjsg=;
	b=Oe7EMBeGkddAhwcvLMA4xJ/h30H3T3gBkFB1egkAITD3hSg1Mm5blufXm6h3/v1O7h
	RY5P/74pUHLxQUyykbIqJXfAdNiAoLX5gn5R1MZcRXCEnTuq1GV1WmkvnMO4cDlKJAlE
	9T8NEzzg8Y7AQ5tq5Oi+vAg3DZiHqaeqps95F2z+At4n7SLmNxipJwkHEnsqRsCe+Wkq
	360nhl2zCC0aW/oRCAA+MZ662YC9kqVz85p9yIv/hPsI7SPFZXrxpnQxvIPn0Sh3QE2C
	ng+FFQbUHPTHc8bYfl33eW8waD58E4hUHnk2nBor7Y/SVa2lI4qqn5CDhf5OOcWWF+X5
	AnmQ==
MIME-Version: 1.0
Received: by 10.14.204.72 with SMTP id g48mr9359368eeo.45.1348828594359; Fri,
	28 Sep 2012 03:36:34 -0700 (PDT)
Received: by 10.14.215.195 with HTTP; Fri, 28 Sep 2012 03:36:34 -0700 (PDT)
In-Reply-To: <1348765802-11314-2-git-send-email-matthew.fioravante@jhuapl.edu>
References: <1348765802-11314-1-git-send-email-matthew.fioravante@jhuapl.edu>
	<1348765802-11314-2-git-send-email-matthew.fioravante@jhuapl.edu>
Date: Fri, 28 Sep 2012 11:36:34 +0100
X-Google-Sender-Auth: Z2OY-BqHFWbqQY2Zoh6jX-2Dfg0
Message-ID: <CAFLBxZa77g9nvd9kiUD15e=x9w+ug6yc5Q__ZPyS63e0CiFdPA@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
Cc: samuel.thibault@ens-lyon.org, Ian.Campbell@citrix.com,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 02/11] add posix io for blkfront
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Sep 27, 2012 at 6:09 PM, Matthew Fioravante
<matthew.fioravante@jhuapl.edu> wrote:
> This patch adds posix io support (read,write,lseek) to block devices
> using blkfront.
>
> Signed-off-by: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
> Acked-by: Samuel Thibault <samuel.thibault@ens-lyon.org>

There seems to be a lot of inconsistent use of whitespace in this one
(i.e,. tabs vs spaces) -- but that seems to be true of mini-os as a
whole, so it's not too surprising. :-)  It would be nice if new code
at least could conform to the Xen style, which is no tabs, 4-space
indentation.  (I note that when big chunks of new code are added, as
in blkfront.c, you do follow this convention.)  (Unless Samuel thinks
attempting to match the patchwork of style is more important...)

 -George

>
> diff --git a/extras/mini-os/blkfront.c b/extras/mini-os/blkfront.c
> index 74b8b26..66c65c9 100644
> --- a/extras/mini-os/blkfront.c
> +++ b/extras/mini-os/blkfront.c
> @@ -392,6 +392,7 @@ void blkfront_aio(struct blkfront_aiocb *aiocbp, int write)
>  static void blkfront_aio_cb(struct blkfront_aiocb *aiocbp, int ret)
>  {
>      aiocbp->data = (void*) 1;
> +    aiocbp->aio_cb = NULL;
>  }
>
>  void blkfront_io(struct blkfront_aiocb *aiocbp, int write)
> @@ -547,9 +548,150 @@ moretodo:
>  #ifdef HAVE_LIBC
>  int blkfront_open(struct blkfront_dev *dev)
>  {
> +    /* Silently prevent multiple opens */
> +    if(dev->fd != -1) {
> +       return dev->fd;
> +    }
>      dev->fd = alloc_fd(FTYPE_BLK);
>      printk("blk_open(%s) -> %d\n", dev->nodename, dev->fd);
>      files[dev->fd].blk.dev = dev;
> +    files[dev->fd].blk.offset = 0;
>      return dev->fd;
>  }
> +
> +int blkfront_posix_rwop(int fd, uint8_t* buf, size_t count, int write)
> +{
> +   struct blkfront_dev* dev = files[fd].blk.dev;
> +   off_t offset = files[fd].blk.offset;
> +   struct blkfront_aiocb aiocb;
> +   unsigned long long disksize = dev->info.sectors * dev->info.sector_size;
> +   unsigned int blocksize = dev->info.sector_size;
> +
> +   int blknum;
> +   int blkoff;
> +   size_t bytes;
> +   int rc = 0;
> +   int alignedbuf = 0;
> +   uint8_t* copybuf = NULL;
> +
> +   /* RW 0 bytes is just a NOP */
> +   if(count == 0) {
> +      return 0;
> +   }
> +   /* Check for NULL buffer */
> +   if( buf == NULL ) {
> +      errno = EFAULT;
> +      return -1;
> +   }
> +
> +   /* Write mode checks */
> +   if(write) {
> +      /*Make sure we have write permission */
> +      if(dev->info.info & VDISK_READONLY || (dev->info.mode != O_RDWR  && dev->info.mode !=  O_WRONLY)) {
> +         errno = EACCES;
> +         return -1;
> +      }
> +      /*Make sure disk is big enough for this write */
> +      if(offset + count > disksize) {
> +         errno = ENOSPC;
> +         return -1;
> +      }
> +   }
> +   /* Read mode checks */
> +   else
> +   {
> +      /*If the requested read is bigger than the disk, just
> +       * read as much as we can until the end */
> +      if(offset + count > disksize) {
> +         count = offset >= disksize ? 0 : disksize - offset;
> +      }
> +   }
> +   /* Determine which block to start at and which offset inside of it */
> +   blknum = offset / blocksize;
> +   blkoff = offset % blocksize;
> +
> +   /* Optimization: We need to check if buf is aligned to the sector size.
> +    * This is somewhat tricky code. We have to add the blocksize - block offset
> +    * because the first block may be a partial block and then for every subsequent
> +    * block rw the buffer will be offset.*/
> +   if(!((uintptr_t) (buf +(blocksize -  blkoff)) & (dev->info.sector_size-1))) {
> +      alignedbuf = 1;
> +   }
> +
> +   /* Setup aiocb block object */
> +   aiocb.aio_dev = dev;
> +   aiocb.aio_nbytes = blocksize;
> +   aiocb.aio_offset = blknum * blocksize;
> +   aiocb.aio_cb = NULL;
> +   aiocb.data = NULL;
> +
> +   /* If our buffer is unaligned or its aligned but we will need to rw a partial block
> +    * then a copy will have to be done */
> +   if(!alignedbuf || blkoff != 0 || count % blocksize != 0) {
> +      copybuf = _xmalloc(blocksize, dev->info.sector_size);
> +   }
> +
> +   rc = count;
> +   while(count > 0) {
> +      /* determine how many bytes to read/write from/to the current block buffer */
> +      bytes = count > (blocksize - blkoff) ? blocksize - blkoff : count;
> +
> +      /* read operation */
> +      if(!write) {
> +         if (alignedbuf && bytes >= blocksize) {
> +            /* If aligned and were reading a whole block, just read right into buf */
> +            aiocb.aio_buf = buf;
> +            blkfront_read(&aiocb);
> +         } else {
> +            /* If not then we have to do a copy */
> +            aiocb.aio_buf = copybuf;
> +            blkfront_read(&aiocb);
> +            memcpy(buf, &copybuf[blkoff], bytes);
> +         }
> +      }
> +      /* Write operation */
> +      else {
> +         if(alignedbuf && bytes >= blocksize) {
> +            /* If aligned and were writing a whole block, just write directly from buf */
> +            aiocb.aio_buf = buf;
> +            blkfront_write(&aiocb);
> +         } else {
> +            /* If not then we have to do a copy. */
> +            aiocb.aio_buf = copybuf;
> +            /* If we're writing a partial block, we need to read the current contents first
> +             * so we don't overwrite the extra bits with garbage */
> +            if(blkoff != 0 || bytes < blocksize) {
> +               blkfront_read(&aiocb);
> +            }
> +            memcpy(&copybuf[blkoff], buf, bytes);
> +            blkfront_write(&aiocb);
> +         }
> +      }
> +      /* Will start at beginning of all remaining blocks */
> +      blkoff = 0;
> +
> +      /* Increment counters and continue */
> +      count -= bytes;
> +      buf += bytes;
> +      aiocb.aio_offset += blocksize;
> +   }
> +
> +   free(copybuf);
> +   files[fd].blk.offset += rc;
> +   return rc;
> +
> +}
> +
> +int blkfront_posix_fstat(int fd, struct stat* buf)
> +{
> +   struct blkfront_dev* dev = files[fd].blk.dev;
> +
> +   buf->st_mode = dev->info.mode;
> +   buf->st_uid = 0;
> +   buf->st_gid = 0;
> +   buf->st_size = dev->info.sectors * dev->info.sector_size;
> +   buf->st_atime = buf->st_mtime = buf->st_ctime = time(NULL);
> +
> +   return 0;
> +}
>  #endif
> diff --git a/extras/mini-os/include/blkfront.h b/extras/mini-os/include/blkfront.h
> index 724137e..3528af9 100644
> --- a/extras/mini-os/include/blkfront.h
> +++ b/extras/mini-os/include/blkfront.h
> @@ -28,7 +28,17 @@ struct blkfront_info
>  };
>  struct blkfront_dev *init_blkfront(char *nodename, struct blkfront_info *info);
>  #ifdef HAVE_LIBC
> +#include <sys/stat.h>
> +/* POSIX IO functions:
> + * use blkfront_open() to get a file descriptor to the block device
> + * Don't use the other blkfront posix functions here directly, instead use
> + * read(), write(), lseek() and fstat() on the file descriptor
> + */
>  int blkfront_open(struct blkfront_dev *dev);
> +int blkfront_posix_rwop(int fd, uint8_t* buf, size_t count, int write);
> +#define blkfront_posix_write(fd, buf, count) blkfront_posix_rwop(fd, (uint8_t*)buf, count, 1)
> +#define blkfront_posix_read(fd, buf, count) blkfront_posix_rwop(fd, (uint8_t*)buf, count, 0)
> +int blkfront_posix_fstat(int fd, struct stat* buf);
>  #endif
>  void blkfront_aio(struct blkfront_aiocb *aiocbp, int write);
>  #define blkfront_aio_read(aiocbp) blkfront_aio(aiocbp, 0)
> diff --git a/extras/mini-os/include/lib.h b/extras/mini-os/include/lib.h
> index 1af2717..d4641b6 100644
> --- a/extras/mini-os/include/lib.h
> +++ b/extras/mini-os/include/lib.h
> @@ -174,6 +174,7 @@ extern struct file {
>         } tap;
>         struct {
>             struct blkfront_dev *dev;
> +            off_t offset;
>         } blk;
>         struct {
>             struct kbdfront_dev *dev;
> diff --git a/extras/mini-os/lib/sys.c b/extras/mini-os/lib/sys.c
> index a7d35d6..7ddbbf8 100644
> --- a/extras/mini-os/lib/sys.c
> +++ b/extras/mini-os/lib/sys.c
> @@ -289,6 +289,11 @@ int read(int fd, void *buf, size_t nbytes)
>             return ret * sizeof(union xenfb_in_event);
>          }
>  #endif
> +#ifdef CONFIG_BLKFRONT
> +        case FTYPE_BLK: {
> +           return blkfront_posix_read(fd, buf, nbytes);
> +        }
> +#endif
>         default:
>             break;
>      }
> @@ -321,6 +326,10 @@ int write(int fd, const void *buf, size_t nbytes)
>             netfront_xmit(files[fd].tap.dev, (void*) buf, nbytes);
>             return nbytes;
>  #endif
> +#ifdef CONFIG_BLKFRONT
> +       case FTYPE_BLK:
> +           return blkfront_posix_write(fd, buf, nbytes);
> +#endif
>         default:
>             break;
>      }
> @@ -331,8 +340,37 @@ int write(int fd, const void *buf, size_t nbytes)
>
>  off_t lseek(int fd, off_t offset, int whence)
>  {
> -    errno = ESPIPE;
> -    return (off_t) -1;
> +    switch(files[fd].type) {
> +#ifdef CONFIG_BLKFRONT
> +       case FTYPE_BLK:
> +         switch (whence) {
> +            case SEEK_SET:
> +               files[fd].file.offset = offset;
> +               break;
> +            case SEEK_CUR:
> +               files[fd].file.offset += offset;
> +               break;
> +            case SEEK_END:
> +               {
> +                  struct stat st;
> +                  int ret;
> +                  ret = fstat(fd, &st);
> +                  if (ret)
> +                     return -1;
> +                  files[fd].file.offset = st.st_size + offset;
> +                  break;
> +               }
> +            default:
> +               errno = EINVAL;
> +               return -1;
> +         }
> +         return files[fd].file.offset;
> +         break;
> +#endif
> +       default: /* Not implemented on this FTYPE */
> +         errno = ESPIPE;
> +         return (off_t) -1;
> +    }
>  }
>
>  int fsync(int fd) {
> @@ -445,6 +483,10 @@ int fstat(int fd, struct stat *buf)
>             buf->st_ctime = time(NULL);
>             return 0;
>         }
> +#ifdef CONFIG_BLKFRONT
> +       case FTYPE_BLK:
> +          return blkfront_posix_fstat(fd, buf);
> +#endif
>         default:
>             break;
>      }
> --
> 1.7.9.5
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 28 10:37:58 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Sep 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 1THXwh-0003bh-MW; Fri, 28 Sep 2012 10:37:23 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dunlapg@gmail.com>) id 1THXwg-0003bZ-9X
	for xen-devel@lists.xen.org; Fri, 28 Sep 2012 10:37:22 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1348828594!5723357!1
X-Originating-IP: [209.85.215.173]
X-SpamReason: No, hits=1.7 required=7.0 tests=INFO_TLD,RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17620 invoked from network); 28 Sep 2012 10:36:35 -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;
	28 Sep 2012 10:36:35 -0000
Received: by eaaa1 with SMTP id a1so1048564eaa.32
	for <xen-devel@lists.xen.org>; Fri, 28 Sep 2012 03:36: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;
	bh=na0BQW+A8dQOCzZJdg5ycaHzNLUbEXt38UpolvOHjsg=;
	b=Oe7EMBeGkddAhwcvLMA4xJ/h30H3T3gBkFB1egkAITD3hSg1Mm5blufXm6h3/v1O7h
	RY5P/74pUHLxQUyykbIqJXfAdNiAoLX5gn5R1MZcRXCEnTuq1GV1WmkvnMO4cDlKJAlE
	9T8NEzzg8Y7AQ5tq5Oi+vAg3DZiHqaeqps95F2z+At4n7SLmNxipJwkHEnsqRsCe+Wkq
	360nhl2zCC0aW/oRCAA+MZ662YC9kqVz85p9yIv/hPsI7SPFZXrxpnQxvIPn0Sh3QE2C
	ng+FFQbUHPTHc8bYfl33eW8waD58E4hUHnk2nBor7Y/SVa2lI4qqn5CDhf5OOcWWF+X5
	AnmQ==
MIME-Version: 1.0
Received: by 10.14.204.72 with SMTP id g48mr9359368eeo.45.1348828594359; Fri,
	28 Sep 2012 03:36:34 -0700 (PDT)
Received: by 10.14.215.195 with HTTP; Fri, 28 Sep 2012 03:36:34 -0700 (PDT)
In-Reply-To: <1348765802-11314-2-git-send-email-matthew.fioravante@jhuapl.edu>
References: <1348765802-11314-1-git-send-email-matthew.fioravante@jhuapl.edu>
	<1348765802-11314-2-git-send-email-matthew.fioravante@jhuapl.edu>
Date: Fri, 28 Sep 2012 11:36:34 +0100
X-Google-Sender-Auth: Z2OY-BqHFWbqQY2Zoh6jX-2Dfg0
Message-ID: <CAFLBxZa77g9nvd9kiUD15e=x9w+ug6yc5Q__ZPyS63e0CiFdPA@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
Cc: samuel.thibault@ens-lyon.org, Ian.Campbell@citrix.com,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 02/11] add posix io for blkfront
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Sep 27, 2012 at 6:09 PM, Matthew Fioravante
<matthew.fioravante@jhuapl.edu> wrote:
> This patch adds posix io support (read,write,lseek) to block devices
> using blkfront.
>
> Signed-off-by: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
> Acked-by: Samuel Thibault <samuel.thibault@ens-lyon.org>

There seems to be a lot of inconsistent use of whitespace in this one
(i.e,. tabs vs spaces) -- but that seems to be true of mini-os as a
whole, so it's not too surprising. :-)  It would be nice if new code
at least could conform to the Xen style, which is no tabs, 4-space
indentation.  (I note that when big chunks of new code are added, as
in blkfront.c, you do follow this convention.)  (Unless Samuel thinks
attempting to match the patchwork of style is more important...)

 -George

>
> diff --git a/extras/mini-os/blkfront.c b/extras/mini-os/blkfront.c
> index 74b8b26..66c65c9 100644
> --- a/extras/mini-os/blkfront.c
> +++ b/extras/mini-os/blkfront.c
> @@ -392,6 +392,7 @@ void blkfront_aio(struct blkfront_aiocb *aiocbp, int write)
>  static void blkfront_aio_cb(struct blkfront_aiocb *aiocbp, int ret)
>  {
>      aiocbp->data = (void*) 1;
> +    aiocbp->aio_cb = NULL;
>  }
>
>  void blkfront_io(struct blkfront_aiocb *aiocbp, int write)
> @@ -547,9 +548,150 @@ moretodo:
>  #ifdef HAVE_LIBC
>  int blkfront_open(struct blkfront_dev *dev)
>  {
> +    /* Silently prevent multiple opens */
> +    if(dev->fd != -1) {
> +       return dev->fd;
> +    }
>      dev->fd = alloc_fd(FTYPE_BLK);
>      printk("blk_open(%s) -> %d\n", dev->nodename, dev->fd);
>      files[dev->fd].blk.dev = dev;
> +    files[dev->fd].blk.offset = 0;
>      return dev->fd;
>  }
> +
> +int blkfront_posix_rwop(int fd, uint8_t* buf, size_t count, int write)
> +{
> +   struct blkfront_dev* dev = files[fd].blk.dev;
> +   off_t offset = files[fd].blk.offset;
> +   struct blkfront_aiocb aiocb;
> +   unsigned long long disksize = dev->info.sectors * dev->info.sector_size;
> +   unsigned int blocksize = dev->info.sector_size;
> +
> +   int blknum;
> +   int blkoff;
> +   size_t bytes;
> +   int rc = 0;
> +   int alignedbuf = 0;
> +   uint8_t* copybuf = NULL;
> +
> +   /* RW 0 bytes is just a NOP */
> +   if(count == 0) {
> +      return 0;
> +   }
> +   /* Check for NULL buffer */
> +   if( buf == NULL ) {
> +      errno = EFAULT;
> +      return -1;
> +   }
> +
> +   /* Write mode checks */
> +   if(write) {
> +      /*Make sure we have write permission */
> +      if(dev->info.info & VDISK_READONLY || (dev->info.mode != O_RDWR  && dev->info.mode !=  O_WRONLY)) {
> +         errno = EACCES;
> +         return -1;
> +      }
> +      /*Make sure disk is big enough for this write */
> +      if(offset + count > disksize) {
> +         errno = ENOSPC;
> +         return -1;
> +      }
> +   }
> +   /* Read mode checks */
> +   else
> +   {
> +      /*If the requested read is bigger than the disk, just
> +       * read as much as we can until the end */
> +      if(offset + count > disksize) {
> +         count = offset >= disksize ? 0 : disksize - offset;
> +      }
> +   }
> +   /* Determine which block to start at and which offset inside of it */
> +   blknum = offset / blocksize;
> +   blkoff = offset % blocksize;
> +
> +   /* Optimization: We need to check if buf is aligned to the sector size.
> +    * This is somewhat tricky code. We have to add the blocksize - block offset
> +    * because the first block may be a partial block and then for every subsequent
> +    * block rw the buffer will be offset.*/
> +   if(!((uintptr_t) (buf +(blocksize -  blkoff)) & (dev->info.sector_size-1))) {
> +      alignedbuf = 1;
> +   }
> +
> +   /* Setup aiocb block object */
> +   aiocb.aio_dev = dev;
> +   aiocb.aio_nbytes = blocksize;
> +   aiocb.aio_offset = blknum * blocksize;
> +   aiocb.aio_cb = NULL;
> +   aiocb.data = NULL;
> +
> +   /* If our buffer is unaligned or its aligned but we will need to rw a partial block
> +    * then a copy will have to be done */
> +   if(!alignedbuf || blkoff != 0 || count % blocksize != 0) {
> +      copybuf = _xmalloc(blocksize, dev->info.sector_size);
> +   }
> +
> +   rc = count;
> +   while(count > 0) {
> +      /* determine how many bytes to read/write from/to the current block buffer */
> +      bytes = count > (blocksize - blkoff) ? blocksize - blkoff : count;
> +
> +      /* read operation */
> +      if(!write) {
> +         if (alignedbuf && bytes >= blocksize) {
> +            /* If aligned and were reading a whole block, just read right into buf */
> +            aiocb.aio_buf = buf;
> +            blkfront_read(&aiocb);
> +         } else {
> +            /* If not then we have to do a copy */
> +            aiocb.aio_buf = copybuf;
> +            blkfront_read(&aiocb);
> +            memcpy(buf, &copybuf[blkoff], bytes);
> +         }
> +      }
> +      /* Write operation */
> +      else {
> +         if(alignedbuf && bytes >= blocksize) {
> +            /* If aligned and were writing a whole block, just write directly from buf */
> +            aiocb.aio_buf = buf;
> +            blkfront_write(&aiocb);
> +         } else {
> +            /* If not then we have to do a copy. */
> +            aiocb.aio_buf = copybuf;
> +            /* If we're writing a partial block, we need to read the current contents first
> +             * so we don't overwrite the extra bits with garbage */
> +            if(blkoff != 0 || bytes < blocksize) {
> +               blkfront_read(&aiocb);
> +            }
> +            memcpy(&copybuf[blkoff], buf, bytes);
> +            blkfront_write(&aiocb);
> +         }
> +      }
> +      /* Will start at beginning of all remaining blocks */
> +      blkoff = 0;
> +
> +      /* Increment counters and continue */
> +      count -= bytes;
> +      buf += bytes;
> +      aiocb.aio_offset += blocksize;
> +   }
> +
> +   free(copybuf);
> +   files[fd].blk.offset += rc;
> +   return rc;
> +
> +}
> +
> +int blkfront_posix_fstat(int fd, struct stat* buf)
> +{
> +   struct blkfront_dev* dev = files[fd].blk.dev;
> +
> +   buf->st_mode = dev->info.mode;
> +   buf->st_uid = 0;
> +   buf->st_gid = 0;
> +   buf->st_size = dev->info.sectors * dev->info.sector_size;
> +   buf->st_atime = buf->st_mtime = buf->st_ctime = time(NULL);
> +
> +   return 0;
> +}
>  #endif
> diff --git a/extras/mini-os/include/blkfront.h b/extras/mini-os/include/blkfront.h
> index 724137e..3528af9 100644
> --- a/extras/mini-os/include/blkfront.h
> +++ b/extras/mini-os/include/blkfront.h
> @@ -28,7 +28,17 @@ struct blkfront_info
>  };
>  struct blkfront_dev *init_blkfront(char *nodename, struct blkfront_info *info);
>  #ifdef HAVE_LIBC
> +#include <sys/stat.h>
> +/* POSIX IO functions:
> + * use blkfront_open() to get a file descriptor to the block device
> + * Don't use the other blkfront posix functions here directly, instead use
> + * read(), write(), lseek() and fstat() on the file descriptor
> + */
>  int blkfront_open(struct blkfront_dev *dev);
> +int blkfront_posix_rwop(int fd, uint8_t* buf, size_t count, int write);
> +#define blkfront_posix_write(fd, buf, count) blkfront_posix_rwop(fd, (uint8_t*)buf, count, 1)
> +#define blkfront_posix_read(fd, buf, count) blkfront_posix_rwop(fd, (uint8_t*)buf, count, 0)
> +int blkfront_posix_fstat(int fd, struct stat* buf);
>  #endif
>  void blkfront_aio(struct blkfront_aiocb *aiocbp, int write);
>  #define blkfront_aio_read(aiocbp) blkfront_aio(aiocbp, 0)
> diff --git a/extras/mini-os/include/lib.h b/extras/mini-os/include/lib.h
> index 1af2717..d4641b6 100644
> --- a/extras/mini-os/include/lib.h
> +++ b/extras/mini-os/include/lib.h
> @@ -174,6 +174,7 @@ extern struct file {
>         } tap;
>         struct {
>             struct blkfront_dev *dev;
> +            off_t offset;
>         } blk;
>         struct {
>             struct kbdfront_dev *dev;
> diff --git a/extras/mini-os/lib/sys.c b/extras/mini-os/lib/sys.c
> index a7d35d6..7ddbbf8 100644
> --- a/extras/mini-os/lib/sys.c
> +++ b/extras/mini-os/lib/sys.c
> @@ -289,6 +289,11 @@ int read(int fd, void *buf, size_t nbytes)
>             return ret * sizeof(union xenfb_in_event);
>          }
>  #endif
> +#ifdef CONFIG_BLKFRONT
> +        case FTYPE_BLK: {
> +           return blkfront_posix_read(fd, buf, nbytes);
> +        }
> +#endif
>         default:
>             break;
>      }
> @@ -321,6 +326,10 @@ int write(int fd, const void *buf, size_t nbytes)
>             netfront_xmit(files[fd].tap.dev, (void*) buf, nbytes);
>             return nbytes;
>  #endif
> +#ifdef CONFIG_BLKFRONT
> +       case FTYPE_BLK:
> +           return blkfront_posix_write(fd, buf, nbytes);
> +#endif
>         default:
>             break;
>      }
> @@ -331,8 +340,37 @@ int write(int fd, const void *buf, size_t nbytes)
>
>  off_t lseek(int fd, off_t offset, int whence)
>  {
> -    errno = ESPIPE;
> -    return (off_t) -1;
> +    switch(files[fd].type) {
> +#ifdef CONFIG_BLKFRONT
> +       case FTYPE_BLK:
> +         switch (whence) {
> +            case SEEK_SET:
> +               files[fd].file.offset = offset;
> +               break;
> +            case SEEK_CUR:
> +               files[fd].file.offset += offset;
> +               break;
> +            case SEEK_END:
> +               {
> +                  struct stat st;
> +                  int ret;
> +                  ret = fstat(fd, &st);
> +                  if (ret)
> +                     return -1;
> +                  files[fd].file.offset = st.st_size + offset;
> +                  break;
> +               }
> +            default:
> +               errno = EINVAL;
> +               return -1;
> +         }
> +         return files[fd].file.offset;
> +         break;
> +#endif
> +       default: /* Not implemented on this FTYPE */
> +         errno = ESPIPE;
> +         return (off_t) -1;
> +    }
>  }
>
>  int fsync(int fd) {
> @@ -445,6 +483,10 @@ int fstat(int fd, struct stat *buf)
>             buf->st_ctime = time(NULL);
>             return 0;
>         }
> +#ifdef CONFIG_BLKFRONT
> +       case FTYPE_BLK:
> +          return blkfront_posix_fstat(fd, buf);
> +#endif
>         default:
>             break;
>      }
> --
> 1.7.9.5
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 28 10:49:07 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Sep 2012 10: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 1THY7i-0003p0-SY; Fri, 28 Sep 2012 10:48:46 +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 1THY7h-0003os-G2
	for xen-devel@lists.xen.org; Fri, 28 Sep 2012 10:48:45 +0000
Received: from [85.158.139.211:9438] by server-9.bemta-5.messagelabs.com id
	3A/8D-14846-C8085605; Fri, 28 Sep 2012 10:48:44 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-4.tower-206.messagelabs.com!1348829324!20329532!1
X-Originating-IP: [74.125.83.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21793 invoked from network); 28 Sep 2012 10:48:44 -0000
Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com)
	(74.125.83.45)
	by server-4.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Sep 2012 10:48:44 -0000
Received: by eekb47 with SMTP id b47so1474275eek.32
	for <xen-devel@lists.xen.org>; Fri, 28 Sep 2012 03:48:44 -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=MXfMZkbr51A/V+WEBtegHhBE+qxAB9rXOL2nYWpflTk=;
	b=ytR4jcPBN4s1mwEbyEvADiupbJwvtdUOSgw5HeaK4VoZ8q1av5BmQB1ztXGzxYFdxE
	UaCiYsuUtm2FBaYIaiJSwHryBGz0ouKFSmRALKKK+2TCFRQ53gBPZeE+1emqToBuS+kV
	OTh/VyOmA8KTWas1h98W0+EDYlZv4q0c6SQ/mFiWzv94SEOhJToWBF+myjoAOxr0jeEh
	kDLsXVsuQZpQ0+omjsBcSl1nvBgz9GbvuuMQ8PY9/xgkRhQCllz0n+eA7Li+F2KvlJDU
	rzGEb4uSg8rGyItdnGyScrn8O3PP2YEoWc+WoGD+GrB+6K5d4bkmXy1WbF1vksCCp00e
	xMXQ==
MIME-Version: 1.0
Received: by 10.14.209.129 with SMTP id s1mr9460101eeo.24.1348829323959; Fri,
	28 Sep 2012 03:48:43 -0700 (PDT)
Received: by 10.14.215.195 with HTTP; Fri, 28 Sep 2012 03:48:43 -0700 (PDT)
In-Reply-To: <1348765802-11314-3-git-send-email-matthew.fioravante@jhuapl.edu>
References: <1348765802-11314-1-git-send-email-matthew.fioravante@jhuapl.edu>
	<1348765802-11314-3-git-send-email-matthew.fioravante@jhuapl.edu>
Date: Fri, 28 Sep 2012 11:48:43 +0100
X-Google-Sender-Auth: 7u7NXnXSIyQn8i8Cdc88peVMSXA
Message-ID: <CAFLBxZZ+SAKHN35b1d4F+_hGt9eLete0fqhOzQ+NZ7Rpx-42-w@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
Cc: samuel.thibault@ens-lyon.org, Ian.Campbell@citrix.com,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 03/11] Add endian, byteswap,
 and wordsize macros to mini-os
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Sep 27, 2012 at 6:09 PM, Matthew Fioravante
<matthew.fioravante@jhuapl.edu> wrote:
> This patch addes byte swapping macros and endian support to mini-os.
>
> Signed-off-by: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
> Acked-by: Samuel Thibault <samuel.thibault@ens-lyon.org>
>
[snip]
> diff --git a/extras/mini-os/include/byteswap.h b/extras/mini-os/include/byteswap.h
> index 46821ae..992c8bd 100644
> --- a/extras/mini-os/include/byteswap.h
> +++ b/extras/mini-os/include/byteswap.h
> @@ -4,30 +4,36 @@
>  /* Unfortunately not provided by newlib.  */
>
>  #include <mini-os/types.h>
> -static inline uint16_t bswap_16(uint16_t x)
> -{
> -    return
> -    ((((x) & 0xff00) >> 8) | (((x) & 0xff) << 8));
> -}
> -
> -static inline uint32_t bswap_32(uint32_t x)
> -{
> -    return
> -    ((((x) & 0xff000000) >> 24) | (((x) & 0x00ff0000) >>  8) |
> -     (((x) & 0x0000ff00) <<  8) | (((x) & 0x000000ff) << 24));
> -}
> -
> -static inline uint64_t bswap_64(uint64_t x)
> -{
> -    return
> -    ((((x) & 0xff00000000000000ULL) >> 56) |
> -     (((x) & 0x00ff000000000000ULL) >> 40) |
> -     (((x) & 0x0000ff0000000000ULL) >> 24) |
> -     (((x) & 0x000000ff00000000ULL) >>  8) |
> -     (((x) & 0x00000000ff000000ULL) <<  8) |
> -     (((x) & 0x0000000000ff0000ULL) << 24) |
> -     (((x) & 0x000000000000ff00ULL) << 40) |
> -     (((x) & 0x00000000000000ffULL) << 56));
> -}
> +
> +#define bswap_16(x) ((uint16_t)(                         \
> +                (((uint16_t)(x) & (uint16_t)0x00ffU) << 8) |                  \
> +                (((uint16_t)(x) & (uint16_t)0xff00U) >> 8)))
> +
> +/* Use gcc optimized versions if they exist */
> +#if __GNUC__ > 4 || (__GNUC__ == 4 && __GNUC_MINOR__ >= 3)
> +#define bswap_32(v) __builtin_bswap32(v)
> +#define bswap_64(v) __builtin_bswap64(v)
> +#else
> +
> +#define bswap_32(x) ((uint32_t)(                         \
> +                (((uint32_t)(x) & (uint32_t)0x000000ffUL) << 24) |            \
> +                (((uint32_t)(x) & (uint32_t)0x0000ff00UL) <<  8) |            \
> +                (((uint32_t)(x) & (uint32_t)0x00ff0000UL) >>  8) |            \
> +                (((uint32_t)(x) & (uint32_t)0xff000000UL) >> 24)))
> +
> +#define bswap_64(x) ((uint64_t)(                         \
> +                (((uint64_t)(x) & (uint64_t)0x00000000000000ffULL) << 56) |   \
> +                (((uint64_t)(x) & (uint64_t)0x000000000000ff00ULL) << 40) |   \
> +                (((uint64_t)(x) & (uint64_t)0x0000000000ff0000ULL) << 24) |   \
> +                (((uint64_t)(x) & (uint64_t)0x00000000ff000000ULL) <<  8) |   \
> +                (((uint64_t)(x) & (uint64_t)0x000000ff00000000ULL) >>  8) |   \
> +                (((uint64_t)(x) & (uint64_t)0x0000ff0000000000ULL) >> 24) |   \
> +                (((uint64_t)(x) & (uint64_t)0x00ff000000000000ULL) >> 40) |   \
> +                (((uint64_t)(x) & (uint64_t)0xff00000000000000ULL) >> 56)))
> +
> +#endif

I think it would be worth adding to the commit message your rationale
for changing from static inline to #defines, which you gave in
response to Samuel in the last iteration of this patch.

[snip]

> diff --git a/extras/mini-os/include/ia64/arch_endian.h b/extras/mini-os/include/ia64/arch_endian.h
> new file mode 100644
> index 0000000..0771683
> --- /dev/null
> +++ b/extras/mini-os/include/ia64/arch_endian.h
> @@ -0,0 +1,7 @@
> +#ifndef        ARCH_ENDIAN_H
> +#error "Do not include arch_endian by itself, include endian.h"
> +#else
> +
> +#define __BYTE_ORDER __LITTLE_ENDIAN
> +
> +#endif
> diff --git a/extras/mini-os/include/ia64/arch_wordsize.h b/extras/mini-os/include/ia64/arch_wordsize.h
> new file mode 100644
> index 0000000..1b5a00f
> --- /dev/null
> +++ b/extras/mini-os/include/ia64/arch_wordsize.h
> @@ -0,0 +1 @@
> +#define __WORDSIZE 64

Again, is there a reason to include the ia64 files?

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 28 10:49:07 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Sep 2012 10: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 1THY7i-0003p0-SY; Fri, 28 Sep 2012 10:48:46 +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 1THY7h-0003os-G2
	for xen-devel@lists.xen.org; Fri, 28 Sep 2012 10:48:45 +0000
Received: from [85.158.139.211:9438] by server-9.bemta-5.messagelabs.com id
	3A/8D-14846-C8085605; Fri, 28 Sep 2012 10:48:44 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-4.tower-206.messagelabs.com!1348829324!20329532!1
X-Originating-IP: [74.125.83.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21793 invoked from network); 28 Sep 2012 10:48:44 -0000
Received: from mail-ee0-f45.google.com (HELO mail-ee0-f45.google.com)
	(74.125.83.45)
	by server-4.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Sep 2012 10:48:44 -0000
Received: by eekb47 with SMTP id b47so1474275eek.32
	for <xen-devel@lists.xen.org>; Fri, 28 Sep 2012 03:48:44 -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=MXfMZkbr51A/V+WEBtegHhBE+qxAB9rXOL2nYWpflTk=;
	b=ytR4jcPBN4s1mwEbyEvADiupbJwvtdUOSgw5HeaK4VoZ8q1av5BmQB1ztXGzxYFdxE
	UaCiYsuUtm2FBaYIaiJSwHryBGz0ouKFSmRALKKK+2TCFRQ53gBPZeE+1emqToBuS+kV
	OTh/VyOmA8KTWas1h98W0+EDYlZv4q0c6SQ/mFiWzv94SEOhJToWBF+myjoAOxr0jeEh
	kDLsXVsuQZpQ0+omjsBcSl1nvBgz9GbvuuMQ8PY9/xgkRhQCllz0n+eA7Li+F2KvlJDU
	rzGEb4uSg8rGyItdnGyScrn8O3PP2YEoWc+WoGD+GrB+6K5d4bkmXy1WbF1vksCCp00e
	xMXQ==
MIME-Version: 1.0
Received: by 10.14.209.129 with SMTP id s1mr9460101eeo.24.1348829323959; Fri,
	28 Sep 2012 03:48:43 -0700 (PDT)
Received: by 10.14.215.195 with HTTP; Fri, 28 Sep 2012 03:48:43 -0700 (PDT)
In-Reply-To: <1348765802-11314-3-git-send-email-matthew.fioravante@jhuapl.edu>
References: <1348765802-11314-1-git-send-email-matthew.fioravante@jhuapl.edu>
	<1348765802-11314-3-git-send-email-matthew.fioravante@jhuapl.edu>
Date: Fri, 28 Sep 2012 11:48:43 +0100
X-Google-Sender-Auth: 7u7NXnXSIyQn8i8Cdc88peVMSXA
Message-ID: <CAFLBxZZ+SAKHN35b1d4F+_hGt9eLete0fqhOzQ+NZ7Rpx-42-w@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
Cc: samuel.thibault@ens-lyon.org, Ian.Campbell@citrix.com,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 03/11] Add endian, byteswap,
 and wordsize macros to mini-os
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Sep 27, 2012 at 6:09 PM, Matthew Fioravante
<matthew.fioravante@jhuapl.edu> wrote:
> This patch addes byte swapping macros and endian support to mini-os.
>
> Signed-off-by: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
> Acked-by: Samuel Thibault <samuel.thibault@ens-lyon.org>
>
[snip]
> diff --git a/extras/mini-os/include/byteswap.h b/extras/mini-os/include/byteswap.h
> index 46821ae..992c8bd 100644
> --- a/extras/mini-os/include/byteswap.h
> +++ b/extras/mini-os/include/byteswap.h
> @@ -4,30 +4,36 @@
>  /* Unfortunately not provided by newlib.  */
>
>  #include <mini-os/types.h>
> -static inline uint16_t bswap_16(uint16_t x)
> -{
> -    return
> -    ((((x) & 0xff00) >> 8) | (((x) & 0xff) << 8));
> -}
> -
> -static inline uint32_t bswap_32(uint32_t x)
> -{
> -    return
> -    ((((x) & 0xff000000) >> 24) | (((x) & 0x00ff0000) >>  8) |
> -     (((x) & 0x0000ff00) <<  8) | (((x) & 0x000000ff) << 24));
> -}
> -
> -static inline uint64_t bswap_64(uint64_t x)
> -{
> -    return
> -    ((((x) & 0xff00000000000000ULL) >> 56) |
> -     (((x) & 0x00ff000000000000ULL) >> 40) |
> -     (((x) & 0x0000ff0000000000ULL) >> 24) |
> -     (((x) & 0x000000ff00000000ULL) >>  8) |
> -     (((x) & 0x00000000ff000000ULL) <<  8) |
> -     (((x) & 0x0000000000ff0000ULL) << 24) |
> -     (((x) & 0x000000000000ff00ULL) << 40) |
> -     (((x) & 0x00000000000000ffULL) << 56));
> -}
> +
> +#define bswap_16(x) ((uint16_t)(                         \
> +                (((uint16_t)(x) & (uint16_t)0x00ffU) << 8) |                  \
> +                (((uint16_t)(x) & (uint16_t)0xff00U) >> 8)))
> +
> +/* Use gcc optimized versions if they exist */
> +#if __GNUC__ > 4 || (__GNUC__ == 4 && __GNUC_MINOR__ >= 3)
> +#define bswap_32(v) __builtin_bswap32(v)
> +#define bswap_64(v) __builtin_bswap64(v)
> +#else
> +
> +#define bswap_32(x) ((uint32_t)(                         \
> +                (((uint32_t)(x) & (uint32_t)0x000000ffUL) << 24) |            \
> +                (((uint32_t)(x) & (uint32_t)0x0000ff00UL) <<  8) |            \
> +                (((uint32_t)(x) & (uint32_t)0x00ff0000UL) >>  8) |            \
> +                (((uint32_t)(x) & (uint32_t)0xff000000UL) >> 24)))
> +
> +#define bswap_64(x) ((uint64_t)(                         \
> +                (((uint64_t)(x) & (uint64_t)0x00000000000000ffULL) << 56) |   \
> +                (((uint64_t)(x) & (uint64_t)0x000000000000ff00ULL) << 40) |   \
> +                (((uint64_t)(x) & (uint64_t)0x0000000000ff0000ULL) << 24) |   \
> +                (((uint64_t)(x) & (uint64_t)0x00000000ff000000ULL) <<  8) |   \
> +                (((uint64_t)(x) & (uint64_t)0x000000ff00000000ULL) >>  8) |   \
> +                (((uint64_t)(x) & (uint64_t)0x0000ff0000000000ULL) >> 24) |   \
> +                (((uint64_t)(x) & (uint64_t)0x00ff000000000000ULL) >> 40) |   \
> +                (((uint64_t)(x) & (uint64_t)0xff00000000000000ULL) >> 56)))
> +
> +#endif

I think it would be worth adding to the commit message your rationale
for changing from static inline to #defines, which you gave in
response to Samuel in the last iteration of this patch.

[snip]

> diff --git a/extras/mini-os/include/ia64/arch_endian.h b/extras/mini-os/include/ia64/arch_endian.h
> new file mode 100644
> index 0000000..0771683
> --- /dev/null
> +++ b/extras/mini-os/include/ia64/arch_endian.h
> @@ -0,0 +1,7 @@
> +#ifndef        ARCH_ENDIAN_H
> +#error "Do not include arch_endian by itself, include endian.h"
> +#else
> +
> +#define __BYTE_ORDER __LITTLE_ENDIAN
> +
> +#endif
> diff --git a/extras/mini-os/include/ia64/arch_wordsize.h b/extras/mini-os/include/ia64/arch_wordsize.h
> new file mode 100644
> index 0000000..1b5a00f
> --- /dev/null
> +++ b/extras/mini-os/include/ia64/arch_wordsize.h
> @@ -0,0 +1 @@
> +#define __WORDSIZE 64

Again, is there a reason to include the ia64 files?

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 28 10:52:44 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Sep 2012 10: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 1THYB7-0003vw-GZ; Fri, 28 Sep 2012 10:52:17 +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 1THYB6-0003vq-LJ
	for xen-devel@lists.xen.org; Fri, 28 Sep 2012 10:52:16 +0000
Received: from [85.158.137.99:36716] by server-12.bemta-3.messagelabs.com id
	79/2B-23730-F5185605; Fri, 28 Sep 2012 10:52:15 +0000
X-Env-Sender: lars.kurth.xen@gmail.com
X-Msg-Ref: server-11.tower-217.messagelabs.com!1348829534!18291485!1
X-Originating-IP: [209.85.214.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11584 invoked from network); 28 Sep 2012 10:52:15 -0000
Received: from mail-bk0-f45.google.com (HELO mail-bk0-f45.google.com)
	(209.85.214.45)
	by server-11.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Sep 2012 10:52:15 -0000
Received: by bkcjf3 with SMTP id jf3so2842799bkc.32
	for <xen-devel@lists.xen.org>; Fri, 28 Sep 2012 03:52:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:message-id:date:from:reply-to:user-agent:mime-version:to
	:subject:content-type:content-transfer-encoding;
	bh=OpMJB63yorIeodxciEqFl7mtgsaY4exTgOzrieuFwr0=;
	b=z6WzVZ/BNcB0ySDmV+5izm5B5NSzpzNlDbbKvO5y2r2+JMr4mEMGk48s0K+vQfT88N
	5qmTiUTtttPLDerHSak/URrqDqSSMbMLfkjpXXyVlIew5phvn1Abd9+zFbZ+Fv6rVeWd
	qtjA1TPwixS7L0mfW+J234PcYQgeI3zClvCic/e1sjLL3M8KmrWfHArF82DCijrXGtP0
	ytTeKKRW8J3T8n40TfLqpInJCI/qfAjqOC4nodkDo5E4ZAhGRe9H6X5F+hhUmGsZ9c4U
	bxFnrXJ0bufQ0TEii9h0YT1hQIlHzqJyXDOvnSHSdY/9bh81I2WGfeMJfxZJZ6EzHmM5
	lY/g==
Received: by 10.204.157.6 with SMTP id z6mr3369093bkw.25.1348829534792;
	Fri, 28 Sep 2012 03:52:14 -0700 (PDT)
Received: from [172.16.26.11] (b0fb5b35.bb.sky.com. [176.251.91.53])
	by mx.google.com with ESMTPS id j24sm6336403bkv.0.2012.09.28.03.52.13
	(version=SSLv3 cipher=OTHER); Fri, 28 Sep 2012 03:52:14 -0700 (PDT)
Message-ID: <5065815C.5000408@xen.org>
Date: Fri, 28 Sep 2012 11:52:12 +0100
From: Lars Kurth <lars.kurth@xen.org>
User-Agent: Mozilla/5.0 (Windows NT 6.1;
	rv:15.0) Gecko/20120907 Thunderbird/15.0.1
MIME-Version: 1.0
To: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: [Xen-devel] Xen dedicated meeting space at LinuxCon EU in BCN,
 Nov 8th AM - need your input
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,

I have a small meeting room (capacity 22 people) in Barcelona in the 
LinuxCon venue (LinuxCon is from Nov 5-9) on Nov 8th for about 4 hours 
(9:00 - 13:00). I have a number of options to make use of the room:
a) Use it for Xen presentations targetting users
b) Use it for a developer meet-up (face-2-face, hackathon, ...)
c) Half-half
d) Use it for Xen presentations targetting users and a "meet the devs 
surgery" afterwards (i.e. come with feature suggestions, issues, etc.) 
and get help from the Devs that are there

I number of Cambridge folks will be at LinuxCon. The first questions is 
whether anybody else will be at LinuxCon (and whether thus a face-2-face 
makes sense). I need to make a decision by the end of next week at the 
latest. If we can get a minimum of 8 developers together, a) or c) makes 
sense.

Here is what I need you to do:
- If you are at LinuxCon and am interested please respond with "+YES"
- If you do not have any conrete plans to attend LinuxCon yet, but would 
consider reply with "+MAYBE"

Thank you

Regards
Lars

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 28 10:52:44 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Sep 2012 10: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 1THYB7-0003vw-GZ; Fri, 28 Sep 2012 10:52:17 +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 1THYB6-0003vq-LJ
	for xen-devel@lists.xen.org; Fri, 28 Sep 2012 10:52:16 +0000
Received: from [85.158.137.99:36716] by server-12.bemta-3.messagelabs.com id
	79/2B-23730-F5185605; Fri, 28 Sep 2012 10:52:15 +0000
X-Env-Sender: lars.kurth.xen@gmail.com
X-Msg-Ref: server-11.tower-217.messagelabs.com!1348829534!18291485!1
X-Originating-IP: [209.85.214.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11584 invoked from network); 28 Sep 2012 10:52:15 -0000
Received: from mail-bk0-f45.google.com (HELO mail-bk0-f45.google.com)
	(209.85.214.45)
	by server-11.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Sep 2012 10:52:15 -0000
Received: by bkcjf3 with SMTP id jf3so2842799bkc.32
	for <xen-devel@lists.xen.org>; Fri, 28 Sep 2012 03:52:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=sender:message-id:date:from:reply-to:user-agent:mime-version:to
	:subject:content-type:content-transfer-encoding;
	bh=OpMJB63yorIeodxciEqFl7mtgsaY4exTgOzrieuFwr0=;
	b=z6WzVZ/BNcB0ySDmV+5izm5B5NSzpzNlDbbKvO5y2r2+JMr4mEMGk48s0K+vQfT88N
	5qmTiUTtttPLDerHSak/URrqDqSSMbMLfkjpXXyVlIew5phvn1Abd9+zFbZ+Fv6rVeWd
	qtjA1TPwixS7L0mfW+J234PcYQgeI3zClvCic/e1sjLL3M8KmrWfHArF82DCijrXGtP0
	ytTeKKRW8J3T8n40TfLqpInJCI/qfAjqOC4nodkDo5E4ZAhGRe9H6X5F+hhUmGsZ9c4U
	bxFnrXJ0bufQ0TEii9h0YT1hQIlHzqJyXDOvnSHSdY/9bh81I2WGfeMJfxZJZ6EzHmM5
	lY/g==
Received: by 10.204.157.6 with SMTP id z6mr3369093bkw.25.1348829534792;
	Fri, 28 Sep 2012 03:52:14 -0700 (PDT)
Received: from [172.16.26.11] (b0fb5b35.bb.sky.com. [176.251.91.53])
	by mx.google.com with ESMTPS id j24sm6336403bkv.0.2012.09.28.03.52.13
	(version=SSLv3 cipher=OTHER); Fri, 28 Sep 2012 03:52:14 -0700 (PDT)
Message-ID: <5065815C.5000408@xen.org>
Date: Fri, 28 Sep 2012 11:52:12 +0100
From: Lars Kurth <lars.kurth@xen.org>
User-Agent: Mozilla/5.0 (Windows NT 6.1;
	rv:15.0) Gecko/20120907 Thunderbird/15.0.1
MIME-Version: 1.0
To: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: [Xen-devel] Xen dedicated meeting space at LinuxCon EU in BCN,
 Nov 8th AM - need your input
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,

I have a small meeting room (capacity 22 people) in Barcelona in the 
LinuxCon venue (LinuxCon is from Nov 5-9) on Nov 8th for about 4 hours 
(9:00 - 13:00). I have a number of options to make use of the room:
a) Use it for Xen presentations targetting users
b) Use it for a developer meet-up (face-2-face, hackathon, ...)
c) Half-half
d) Use it for Xen presentations targetting users and a "meet the devs 
surgery" afterwards (i.e. come with feature suggestions, issues, etc.) 
and get help from the Devs that are there

I number of Cambridge folks will be at LinuxCon. The first questions is 
whether anybody else will be at LinuxCon (and whether thus a face-2-face 
makes sense). I need to make a decision by the end of next week at the 
latest. If we can get a minimum of 8 developers together, a) or c) makes 
sense.

Here is what I need you to do:
- If you are at LinuxCon and am interested please respond with "+YES"
- If you do not have any conrete plans to attend LinuxCon yet, but would 
consider reply with "+MAYBE"

Thank you

Regards
Lars

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 28 11:18:32 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Sep 2012 11:18:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1THYaC-0004Cc-0Q; Fri, 28 Sep 2012 11:18:12 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dunlapg@gmail.com>) id 1THYaA-0004CU-8v
	for xen-devel@lists.xen.org; Fri, 28 Sep 2012 11:18:10 +0000
Received: from [85.158.139.211:56686] by server-4.bemta-5.messagelabs.com id
	7B/C9-20767-17785605; Fri, 28 Sep 2012 11:18:09 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-6.tower-206.messagelabs.com!1348831088!20322968!1
X-Originating-IP: [209.85.215.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22929 invoked from network); 28 Sep 2012 11:18:08 -0000
Received: from mail-ey0-f173.google.com (HELO mail-ey0-f173.google.com)
	(209.85.215.173)
	by server-6.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Sep 2012 11:18:08 -0000
Received: by eaaa1 with SMTP id a1so1064413eaa.32
	for <xen-devel@lists.xen.org>; Fri, 28 Sep 2012 04:18:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
	bh=k/ZNhMe3DTntFwHUgBPl+jAWlr92wusss3Tn9VhTvks=;
	b=viDKnvcO0O+yOanRtW4sB9q9s4xhzXt1qDuXE2dQeYJos/CSgFt9OuQv1k8loVv45o
	aS2+1s3ugqhSCeY2Srh2oT74BTC0RkXOn+twpn4Aj1LmT4q3GSmW+gW76Br+Dr9or5oc
	cHKIecyAxDIs0r7ZzOjW6iUXs2TmElWrTN4wbUIv43DJz0TxU9UyGNw4IZ+MFqUFg/Rk
	9kd4gnWcrVA+E9Nu10I4glept9NQr2HgUpTUA1c898p76gi1xbpSZvkcVjuBsofOfhYN
	eFO5IOum3swOCb0EQxWuRr3fEwJ8rdZaU32FZUKzikCLSt/hPod1t80K836lW60gaXYS
	zOvg==
MIME-Version: 1.0
Received: by 10.14.209.129 with SMTP id s1mr9562770eeo.24.1348831088210; Fri,
	28 Sep 2012 04:18:08 -0700 (PDT)
Received: by 10.14.215.195 with HTTP; Fri, 28 Sep 2012 04:18:08 -0700 (PDT)
In-Reply-To: <1348765802-11314-5-git-send-email-matthew.fioravante@jhuapl.edu>
References: <1348765802-11314-1-git-send-email-matthew.fioravante@jhuapl.edu>
	<1348765802-11314-5-git-send-email-matthew.fioravante@jhuapl.edu>
Date: Fri, 28 Sep 2012 12:18:08 +0100
X-Google-Sender-Auth: BJUjPWAN3VQPFaHFpCOLiOJ9lrM
Message-ID: <CAFLBxZbND=Uer5JuwA3aaz4KSPahLDPeeBkDCCkOo7M84q7OAA@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
Cc: samuel.thibault@ens-lyon.org, Ian.Campbell@citrix.com,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 05/11] add CONFIG_XC conditional
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Sep 27, 2012 at 6:09 PM, Matthew Fioravante
<matthew.fioravante@jhuapl.edu> wrote:
> This patch adds a CONFIG_XC option to mini-os, to allow conditional
> support for libxc for mini-os domains.
>
> Signed-off-by: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
> Acked-by: Samuel Thibault <samuel.thibault@ens-lyon.org>

Hmm... Samuel said, "Apart from that, Acked-by:", but you didn't
address the "that" that he mentioned.  In that circumstance, I don't
think addding the "Acked-by" to the commit message is really
appropriate -- it implies that the patch was approved as-is, when in
fact he was only saying that he agreed that these changes were all
right, but that perhaps there needed to be more.

Can you address his question?

 -George

>
> diff --git a/extras/mini-os/Makefile b/extras/mini-os/Makefile
> index c425f76..b4236e8 100644
> --- a/extras/mini-os/Makefile
> +++ b/extras/mini-os/Makefile
> @@ -27,6 +27,7 @@ CONFIG_FBFRONT ?= y
>  CONFIG_KBDFRONT ?= y
>  CONFIG_CONSFRONT ?= y
>  CONFIG_XENBUS ?= y
> +CONFIG_XC ?=y
>  CONFIG_LWIP ?= $(lwip)
>
>  # Export config items as compiler directives
> diff --git a/extras/mini-os/lib/sys.c b/extras/mini-os/lib/sys.c
> index 7ddbbf8..6cb97b1 100644
> --- a/extras/mini-os/lib/sys.c
> +++ b/extras/mini-os/lib/sys.c
> @@ -397,6 +397,7 @@ int close(int fd)
>             return res;
>         }
>  #endif
> +#ifdef CONFIG_XC
>         case FTYPE_XC:
>             minios_interface_close_fd(fd);
>             return 0;
> @@ -406,6 +407,7 @@ int close(int fd)
>         case FTYPE_GNTMAP:
>             minios_gnttab_close_fd(fd);
>             return 0;
> +#endif
>  #ifdef CONFIG_NETFRONT
>         case FTYPE_TAP:
>             shutdown_netfront(files[fd].tap.dev);
> @@ -1195,10 +1197,13 @@ void *mmap(void *start, size_t length, int prot, int flags, int fd, off_t offset
>
>      if (fd == -1)
>          return map_zero(n, 1);
> +#ifdef CONFIG_XC
>      else if (files[fd].type == FTYPE_XC) {
>          unsigned long zero = 0;
>          return map_frames_ex(&zero, n, 0, 0, 1, DOMID_SELF, NULL, 0);
> -    } else if (files[fd].type == FTYPE_MEM) {
> +    }
> +#endif
> +    else if (files[fd].type == FTYPE_MEM) {
>          unsigned long first_mfn = offset >> PAGE_SHIFT;
>          return map_frames_ex(&first_mfn, n, 0, 1, 1, DOMID_IO, NULL, _PAGE_PRESENT|_PAGE_RW);
>      } else ASSERT(0);
> --
> 1.7.9.5
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 28 11:18:32 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Sep 2012 11:18:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1THYaC-0004Cc-0Q; Fri, 28 Sep 2012 11:18:12 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dunlapg@gmail.com>) id 1THYaA-0004CU-8v
	for xen-devel@lists.xen.org; Fri, 28 Sep 2012 11:18:10 +0000
Received: from [85.158.139.211:56686] by server-4.bemta-5.messagelabs.com id
	7B/C9-20767-17785605; Fri, 28 Sep 2012 11:18:09 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-6.tower-206.messagelabs.com!1348831088!20322968!1
X-Originating-IP: [209.85.215.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22929 invoked from network); 28 Sep 2012 11:18:08 -0000
Received: from mail-ey0-f173.google.com (HELO mail-ey0-f173.google.com)
	(209.85.215.173)
	by server-6.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Sep 2012 11:18:08 -0000
Received: by eaaa1 with SMTP id a1so1064413eaa.32
	for <xen-devel@lists.xen.org>; Fri, 28 Sep 2012 04:18:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
	bh=k/ZNhMe3DTntFwHUgBPl+jAWlr92wusss3Tn9VhTvks=;
	b=viDKnvcO0O+yOanRtW4sB9q9s4xhzXt1qDuXE2dQeYJos/CSgFt9OuQv1k8loVv45o
	aS2+1s3ugqhSCeY2Srh2oT74BTC0RkXOn+twpn4Aj1LmT4q3GSmW+gW76Br+Dr9or5oc
	cHKIecyAxDIs0r7ZzOjW6iUXs2TmElWrTN4wbUIv43DJz0TxU9UyGNw4IZ+MFqUFg/Rk
	9kd4gnWcrVA+E9Nu10I4glept9NQr2HgUpTUA1c898p76gi1xbpSZvkcVjuBsofOfhYN
	eFO5IOum3swOCb0EQxWuRr3fEwJ8rdZaU32FZUKzikCLSt/hPod1t80K836lW60gaXYS
	zOvg==
MIME-Version: 1.0
Received: by 10.14.209.129 with SMTP id s1mr9562770eeo.24.1348831088210; Fri,
	28 Sep 2012 04:18:08 -0700 (PDT)
Received: by 10.14.215.195 with HTTP; Fri, 28 Sep 2012 04:18:08 -0700 (PDT)
In-Reply-To: <1348765802-11314-5-git-send-email-matthew.fioravante@jhuapl.edu>
References: <1348765802-11314-1-git-send-email-matthew.fioravante@jhuapl.edu>
	<1348765802-11314-5-git-send-email-matthew.fioravante@jhuapl.edu>
Date: Fri, 28 Sep 2012 12:18:08 +0100
X-Google-Sender-Auth: BJUjPWAN3VQPFaHFpCOLiOJ9lrM
Message-ID: <CAFLBxZbND=Uer5JuwA3aaz4KSPahLDPeeBkDCCkOo7M84q7OAA@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
Cc: samuel.thibault@ens-lyon.org, Ian.Campbell@citrix.com,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 05/11] add CONFIG_XC conditional
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Sep 27, 2012 at 6:09 PM, Matthew Fioravante
<matthew.fioravante@jhuapl.edu> wrote:
> This patch adds a CONFIG_XC option to mini-os, to allow conditional
> support for libxc for mini-os domains.
>
> Signed-off-by: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
> Acked-by: Samuel Thibault <samuel.thibault@ens-lyon.org>

Hmm... Samuel said, "Apart from that, Acked-by:", but you didn't
address the "that" that he mentioned.  In that circumstance, I don't
think addding the "Acked-by" to the commit message is really
appropriate -- it implies that the patch was approved as-is, when in
fact he was only saying that he agreed that these changes were all
right, but that perhaps there needed to be more.

Can you address his question?

 -George

>
> diff --git a/extras/mini-os/Makefile b/extras/mini-os/Makefile
> index c425f76..b4236e8 100644
> --- a/extras/mini-os/Makefile
> +++ b/extras/mini-os/Makefile
> @@ -27,6 +27,7 @@ CONFIG_FBFRONT ?= y
>  CONFIG_KBDFRONT ?= y
>  CONFIG_CONSFRONT ?= y
>  CONFIG_XENBUS ?= y
> +CONFIG_XC ?=y
>  CONFIG_LWIP ?= $(lwip)
>
>  # Export config items as compiler directives
> diff --git a/extras/mini-os/lib/sys.c b/extras/mini-os/lib/sys.c
> index 7ddbbf8..6cb97b1 100644
> --- a/extras/mini-os/lib/sys.c
> +++ b/extras/mini-os/lib/sys.c
> @@ -397,6 +397,7 @@ int close(int fd)
>             return res;
>         }
>  #endif
> +#ifdef CONFIG_XC
>         case FTYPE_XC:
>             minios_interface_close_fd(fd);
>             return 0;
> @@ -406,6 +407,7 @@ int close(int fd)
>         case FTYPE_GNTMAP:
>             minios_gnttab_close_fd(fd);
>             return 0;
> +#endif
>  #ifdef CONFIG_NETFRONT
>         case FTYPE_TAP:
>             shutdown_netfront(files[fd].tap.dev);
> @@ -1195,10 +1197,13 @@ void *mmap(void *start, size_t length, int prot, int flags, int fd, off_t offset
>
>      if (fd == -1)
>          return map_zero(n, 1);
> +#ifdef CONFIG_XC
>      else if (files[fd].type == FTYPE_XC) {
>          unsigned long zero = 0;
>          return map_frames_ex(&zero, n, 0, 0, 1, DOMID_SELF, NULL, 0);
> -    } else if (files[fd].type == FTYPE_MEM) {
> +    }
> +#endif
> +    else if (files[fd].type == FTYPE_MEM) {
>          unsigned long first_mfn = offset >> PAGE_SHIFT;
>          return map_frames_ex(&first_mfn, n, 0, 1, 1, DOMID_IO, NULL, _PAGE_PRESENT|_PAGE_RW);
>      } else ASSERT(0);
> --
> 1.7.9.5
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 28 12:52:54 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Sep 2012 12:52:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1THa3H-0004gc-Ni; Fri, 28 Sep 2012 12:52:19 +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 1THa3G-0004gX-1j
	for xen-devel@lists.xen.org; Fri, 28 Sep 2012 12:52:18 +0000
Received: from [85.158.137.99:25861] by server-12.bemta-3.messagelabs.com id
	80/58-23730-18D95605; Fri, 28 Sep 2012 12:52:17 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-4.tower-217.messagelabs.com!1348836736!19519696!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA1MTg5ODQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8953 invoked from network); 28 Sep 2012 12:52:16 -0000
Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25)
	by server-4.tower-217.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 28 Sep 2012 12:52: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 AA4412B33;
	Fri, 28 Sep 2012 15:52:15 +0300 (EEST)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id 7458F2005D; Fri, 28 Sep 2012 15:52:15 +0300 (EEST)
Date: Fri, 28 Sep 2012 15:52:15 +0300
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: Anthony PERARD <anthony.perard@citrix.com>
Message-ID: <20120928125215.GS8912@reaktio.net>
References: <CAPGwcLKjHOgwEGjDpQcymUjkv4eAzOVxN5mOKAtQ2UE3Bc4g9Q@mail.gmail.com>
	<50657A38.5070109@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <50657A38.5070109@citrix.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: L D <lethalduck@gmail.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Xen 4.2 and USB
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Sep 28, 2012 at 11:21:44AM +0100, Anthony PERARD wrote:
> On 09/28/2012 03:51 AM, L D wrote:
> > Hello!
> > So I compiled and am running the 4.2 release...did the ./configure;
> > make world; make install
> > It works, and am running an ati vga passthrough windows system, except
> > for usb and sound...
> > 
> > I have a couple of questions, if you can help me with some of these it
> > would be appreciated.
> > 
> > How do I run qemu upstream in this release? I'm trying to have sound
> > in win7 64bit sound but I can't get qemu upstream to work.
> > Anybody have success with win7 sound?
> > I'm using device_model_override='/usr/lib/xen/bin/qemu-system-i386'
> 
> To use qemu upstream, you should use:
> device_model_version = "qemu-xen"
> 
> Here, device_model_override is not needed. 

> But PCI/VGA passthrough is
> not supported by the QEMU upstream shipped with Xen 4.2.
> 

But I think the most recent version of upstream Qemu supports Xen PCI passthru, right? 
(but not the 1.0 (?) version of upstream qemu that's included in Xen 4.2).


> > Finally how do I connect to the qemu console?? ctrl-alt-shift-2,1 just
> > show me blank screens (console=1), I have no way to pass additional
> > usb devices by usb-adding them.
> 
> For consoles: use
> shell$ xl console domain
> 

I think the console= option for xl/libxl is not yet supported/developed.

-- Pasi


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 28 12:52:54 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Sep 2012 12:52:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1THa3H-0004gc-Ni; Fri, 28 Sep 2012 12:52:19 +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 1THa3G-0004gX-1j
	for xen-devel@lists.xen.org; Fri, 28 Sep 2012 12:52:18 +0000
Received: from [85.158.137.99:25861] by server-12.bemta-3.messagelabs.com id
	80/58-23730-18D95605; Fri, 28 Sep 2012 12:52:17 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-4.tower-217.messagelabs.com!1348836736!19519696!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA1MTg5ODQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8953 invoked from network); 28 Sep 2012 12:52:16 -0000
Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25)
	by server-4.tower-217.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 28 Sep 2012 12:52: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 AA4412B33;
	Fri, 28 Sep 2012 15:52:15 +0300 (EEST)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id 7458F2005D; Fri, 28 Sep 2012 15:52:15 +0300 (EEST)
Date: Fri, 28 Sep 2012 15:52:15 +0300
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: Anthony PERARD <anthony.perard@citrix.com>
Message-ID: <20120928125215.GS8912@reaktio.net>
References: <CAPGwcLKjHOgwEGjDpQcymUjkv4eAzOVxN5mOKAtQ2UE3Bc4g9Q@mail.gmail.com>
	<50657A38.5070109@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <50657A38.5070109@citrix.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: L D <lethalduck@gmail.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Xen 4.2 and USB
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Sep 28, 2012 at 11:21:44AM +0100, Anthony PERARD wrote:
> On 09/28/2012 03:51 AM, L D wrote:
> > Hello!
> > So I compiled and am running the 4.2 release...did the ./configure;
> > make world; make install
> > It works, and am running an ati vga passthrough windows system, except
> > for usb and sound...
> > 
> > I have a couple of questions, if you can help me with some of these it
> > would be appreciated.
> > 
> > How do I run qemu upstream in this release? I'm trying to have sound
> > in win7 64bit sound but I can't get qemu upstream to work.
> > Anybody have success with win7 sound?
> > I'm using device_model_override='/usr/lib/xen/bin/qemu-system-i386'
> 
> To use qemu upstream, you should use:
> device_model_version = "qemu-xen"
> 
> Here, device_model_override is not needed. 

> But PCI/VGA passthrough is
> not supported by the QEMU upstream shipped with Xen 4.2.
> 

But I think the most recent version of upstream Qemu supports Xen PCI passthru, right? 
(but not the 1.0 (?) version of upstream qemu that's included in Xen 4.2).


> > Finally how do I connect to the qemu console?? ctrl-alt-shift-2,1 just
> > show me blank screens (console=1), I have no way to pass additional
> > usb devices by usb-adding them.
> 
> For consoles: use
> shell$ xl console domain
> 

I think the console= option for xl/libxl is not yet supported/developed.

-- Pasi


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 28 12:55:50 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Sep 2012 12:55:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1THa6D-0004n9-AC; Fri, 28 Sep 2012 12:55:21 +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 1THa6C-0004n3-AY
	for xen-devel@lists.xen.org; Fri, 28 Sep 2012 12:55:20 +0000
Received: from [85.158.143.35:28158] by server-1.bemta-4.messagelabs.com id
	D3/3D-05684-73E95605; Fri, 28 Sep 2012 12:55:19 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-6.tower-21.messagelabs.com!1348836917!20283203!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA1MTg5ODQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24481 invoked from network); 28 Sep 2012 12:55:18 -0000
Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25)
	by server-6.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 28 Sep 2012 12:55:18 -0000
X-Originating-Ip: [194.89.68.22]
Received: from ydin.reaktio.net (reaktio.net [194.89.68.22])
	by smtp.tele.fi (Postfix) with ESMTP id 1E7611DEF;
	Fri, 28 Sep 2012 15:55:17 +0300 (EEST)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id 05DCC2005D; Fri, 28 Sep 2012 15:55:17 +0300 (EEST)
Date: Fri, 28 Sep 2012 15:55:16 +0300
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: Anthony PERARD <anthony.perard@citrix.com>
Message-ID: <20120928125516.GT8912@reaktio.net>
References: <CAPGwcLKjHOgwEGjDpQcymUjkv4eAzOVxN5mOKAtQ2UE3Bc4g9Q@mail.gmail.com>
	<50657A38.5070109@citrix.com> <20120928125215.GS8912@reaktio.net>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120928125215.GS8912@reaktio.net>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: L D <lethalduck@gmail.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Xen 4.2 and USB
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="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, Sep 28, 2012 at 03:52:15PM +0300, Pasi K=E4rkk=E4inen wrote:
> =

> > > Finally how do I connect to the qemu console?? ctrl-alt-shift-2,1 just
> > > show me blank screens (console=3D1), I have no way to pass additional
> > > usb devices by usb-adding them.
> > =

> > For consoles: use
> > shell$ xl console domain
> > =

> =

> I think the console=3D option for xl/libxl is not yet supported/developed.
> =


Uhm, sorry, I meant to say that "monitor=3D1" option is not yet supported,
but you probably weren't asking for that.

"xl console" gives you the PV/text console, and you can use VNC viewer
to connect to the graphical console, as usual? =


-- Pasi


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 28 12:55:50 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Sep 2012 12:55:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1THa6D-0004n9-AC; Fri, 28 Sep 2012 12:55:21 +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 1THa6C-0004n3-AY
	for xen-devel@lists.xen.org; Fri, 28 Sep 2012 12:55:20 +0000
Received: from [85.158.143.35:28158] by server-1.bemta-4.messagelabs.com id
	D3/3D-05684-73E95605; Fri, 28 Sep 2012 12:55:19 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-6.tower-21.messagelabs.com!1348836917!20283203!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA1MTg5ODQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24481 invoked from network); 28 Sep 2012 12:55:18 -0000
Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25)
	by server-6.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 28 Sep 2012 12:55:18 -0000
X-Originating-Ip: [194.89.68.22]
Received: from ydin.reaktio.net (reaktio.net [194.89.68.22])
	by smtp.tele.fi (Postfix) with ESMTP id 1E7611DEF;
	Fri, 28 Sep 2012 15:55:17 +0300 (EEST)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id 05DCC2005D; Fri, 28 Sep 2012 15:55:17 +0300 (EEST)
Date: Fri, 28 Sep 2012 15:55:16 +0300
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: Anthony PERARD <anthony.perard@citrix.com>
Message-ID: <20120928125516.GT8912@reaktio.net>
References: <CAPGwcLKjHOgwEGjDpQcymUjkv4eAzOVxN5mOKAtQ2UE3Bc4g9Q@mail.gmail.com>
	<50657A38.5070109@citrix.com> <20120928125215.GS8912@reaktio.net>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120928125215.GS8912@reaktio.net>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: L D <lethalduck@gmail.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Xen 4.2 and USB
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="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, Sep 28, 2012 at 03:52:15PM +0300, Pasi K=E4rkk=E4inen wrote:
> =

> > > Finally how do I connect to the qemu console?? ctrl-alt-shift-2,1 just
> > > show me blank screens (console=3D1), I have no way to pass additional
> > > usb devices by usb-adding them.
> > =

> > For consoles: use
> > shell$ xl console domain
> > =

> =

> I think the console=3D option for xl/libxl is not yet supported/developed.
> =


Uhm, sorry, I meant to say that "monitor=3D1" option is not yet supported,
but you probably weren't asking for that.

"xl console" gives you the PV/text console, and you can use VNC viewer
to connect to the graphical console, as usual? =


-- Pasi


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 28 13:04:38 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Sep 2012 13:04: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 1THaEr-00051h-AX; Fri, 28 Sep 2012 13:04:17 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony.perard@gmail.com>) id 1THaEp-00051Z-IK
	for xen-devel@lists.xen.org; Fri, 28 Sep 2012 13:04:15 +0000
X-Env-Sender: anthony.perard@gmail.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1348837365!5055933!1
X-Originating-IP: [209.85.223.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28505 invoked from network); 28 Sep 2012 13:02:46 -0000
Received: from mail-ie0-f173.google.com (HELO mail-ie0-f173.google.com)
	(209.85.223.173)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Sep 2012 13:02:46 -0000
Received: by iea17 with SMTP id 17so9087274iea.32
	for <xen-devel@lists.xen.org>; Fri, 28 Sep 2012 06:02:44 -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
	:content-transfer-encoding;
	bh=sU1UBnS4QsszUzNDYhpP6QOx75tO6g9eRx6TeSYYrhQ=;
	b=QQijZy/o3dQ0cj5M3KVNOZMxtzqCFvOKzI49C4R8fQ6SpoRizw5dq+qNQEwOCMdOAr
	DiRNEy3ldGs4hUKRXw2GMSL6uzHfOwQevOVpLzBHhL98v5YBVNq07psAMbJl1fUmxgBc
	0+hJxQPnzKJm0vdleVA9kt40RbAA0FWm+r+yz8YM3z+rgzTe1eYtf80aWWXQ7oZBtYMe
	Wv7AIxR2Q4Zy1DhtGRyOEFUTfOWWFQ7BBjQ1PaYK6o0anFe60NCwTIdDtQjhJ9aR+NPU
	ghVOlvPDFwmC+3TdTyiphQxVpVyuwOMY+3sTwp2wK4k8G/ZGAZD5yA5JWHZf/k4W8QUz
	8+3w==
Received: by 10.50.168.69 with SMTP id zu5mr1546452igb.23.1348837364723; Fri,
	28 Sep 2012 06:02:44 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.64.126.131 with HTTP; Fri, 28 Sep 2012 06:02:14 -0700 (PDT)
In-Reply-To: <20120928125215.GS8912@reaktio.net>
References: <CAPGwcLKjHOgwEGjDpQcymUjkv4eAzOVxN5mOKAtQ2UE3Bc4g9Q@mail.gmail.com>
	<50657A38.5070109@citrix.com> <20120928125215.GS8912@reaktio.net>
From: Anthony PERARD <anthony.perard@citrix.com>
Date: Fri, 28 Sep 2012 14:02:14 +0100
X-Google-Sender-Auth: k9px-t2ILdRpyOLETkhPh5xGJlM
Message-ID: <CAJJyHjJqVitnvsa8noyd0Rxn=3zSmEVzmU0JG7=iVyzBi3XKEA@mail.gmail.com>
To: =?UTF-8?B?UGFzaSBLw6Rya2vDpGluZW4=?= <pasik@iki.fi>
Cc: L D <lethalduck@gmail.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Xen 4.2 and USB
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gRnJpLCBTZXAgMjgsIDIwMTIgYXQgMTo1MiBQTSwgUGFzaSBLw6Rya2vDpGluZW4gPHBhc2lr
QGlraS5maT4gd3JvdGU6Cj4gQnV0IEkgdGhpbmsgdGhlIG1vc3QgcmVjZW50IHZlcnNpb24gb2Yg
dXBzdHJlYW0gUWVtdSBzdXBwb3J0cyBYZW4gUENJIHBhc3N0aHJ1LCByaWdodD8KCkluZGVlZC4g
QnV0IEkgbmV2ZXIgdHJpZWQgVkdBIHBhc3N0aHJvdWdoLgoKLS0gCkFudGhvbnkgUEVSQVJECgpf
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpYZW4tZGV2ZWwg
bWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW4ub3JnCmh0dHA6Ly9saXN0cy54ZW4ub3Jn
L3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xen.org Fri Sep 28 13:04:38 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Sep 2012 13:04: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 1THaEr-00051h-AX; Fri, 28 Sep 2012 13:04:17 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony.perard@gmail.com>) id 1THaEp-00051Z-IK
	for xen-devel@lists.xen.org; Fri, 28 Sep 2012 13:04:15 +0000
X-Env-Sender: anthony.perard@gmail.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1348837365!5055933!1
X-Originating-IP: [209.85.223.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28505 invoked from network); 28 Sep 2012 13:02:46 -0000
Received: from mail-ie0-f173.google.com (HELO mail-ie0-f173.google.com)
	(209.85.223.173)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Sep 2012 13:02:46 -0000
Received: by iea17 with SMTP id 17so9087274iea.32
	for <xen-devel@lists.xen.org>; Fri, 28 Sep 2012 06:02:44 -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
	:content-transfer-encoding;
	bh=sU1UBnS4QsszUzNDYhpP6QOx75tO6g9eRx6TeSYYrhQ=;
	b=QQijZy/o3dQ0cj5M3KVNOZMxtzqCFvOKzI49C4R8fQ6SpoRizw5dq+qNQEwOCMdOAr
	DiRNEy3ldGs4hUKRXw2GMSL6uzHfOwQevOVpLzBHhL98v5YBVNq07psAMbJl1fUmxgBc
	0+hJxQPnzKJm0vdleVA9kt40RbAA0FWm+r+yz8YM3z+rgzTe1eYtf80aWWXQ7oZBtYMe
	Wv7AIxR2Q4Zy1DhtGRyOEFUTfOWWFQ7BBjQ1PaYK6o0anFe60NCwTIdDtQjhJ9aR+NPU
	ghVOlvPDFwmC+3TdTyiphQxVpVyuwOMY+3sTwp2wK4k8G/ZGAZD5yA5JWHZf/k4W8QUz
	8+3w==
Received: by 10.50.168.69 with SMTP id zu5mr1546452igb.23.1348837364723; Fri,
	28 Sep 2012 06:02:44 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.64.126.131 with HTTP; Fri, 28 Sep 2012 06:02:14 -0700 (PDT)
In-Reply-To: <20120928125215.GS8912@reaktio.net>
References: <CAPGwcLKjHOgwEGjDpQcymUjkv4eAzOVxN5mOKAtQ2UE3Bc4g9Q@mail.gmail.com>
	<50657A38.5070109@citrix.com> <20120928125215.GS8912@reaktio.net>
From: Anthony PERARD <anthony.perard@citrix.com>
Date: Fri, 28 Sep 2012 14:02:14 +0100
X-Google-Sender-Auth: k9px-t2ILdRpyOLETkhPh5xGJlM
Message-ID: <CAJJyHjJqVitnvsa8noyd0Rxn=3zSmEVzmU0JG7=iVyzBi3XKEA@mail.gmail.com>
To: =?UTF-8?B?UGFzaSBLw6Rya2vDpGluZW4=?= <pasik@iki.fi>
Cc: L D <lethalduck@gmail.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Xen 4.2 and USB
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gRnJpLCBTZXAgMjgsIDIwMTIgYXQgMTo1MiBQTSwgUGFzaSBLw6Rya2vDpGluZW4gPHBhc2lr
QGlraS5maT4gd3JvdGU6Cj4gQnV0IEkgdGhpbmsgdGhlIG1vc3QgcmVjZW50IHZlcnNpb24gb2Yg
dXBzdHJlYW0gUWVtdSBzdXBwb3J0cyBYZW4gUENJIHBhc3N0aHJ1LCByaWdodD8KCkluZGVlZC4g
QnV0IEkgbmV2ZXIgdHJpZWQgVkdBIHBhc3N0aHJvdWdoLgoKLS0gCkFudGhvbnkgUEVSQVJECgpf
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpYZW4tZGV2ZWwg
bWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW4ub3JnCmh0dHA6Ly9saXN0cy54ZW4ub3Jn
L3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xen.org Fri Sep 28 13:23:54 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Sep 2012 13:23: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 1THaXU-0005CG-25; Fri, 28 Sep 2012 13:23:32 +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 1THaXS-0005CB-00
	for xen-devel@lists.xen.org; Fri, 28 Sep 2012 13:23:30 +0000
Received: from [85.158.139.211:9711] by server-5.bemta-5.messagelabs.com id
	64/01-21075-1D4A5605; Fri, 28 Sep 2012 13:23:29 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-11.tower-206.messagelabs.com!1348838608!20345578!1
X-Originating-IP: [209.85.215.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15687 invoked from network); 28 Sep 2012 13:23:28 -0000
Received: from mail-ey0-f173.google.com (HELO mail-ey0-f173.google.com)
	(209.85.215.173)
	by server-11.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Sep 2012 13:23:28 -0000
Received: by eaaa1 with SMTP id a1so1111567eaa.32
	for <xen-devel@lists.xen.org>; Fri, 28 Sep 2012 06:23:28 -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=upbPNhhJpaopW+SaHUZNuWBqdGNIfhlT4/O3VUtQFTQ=;
	b=ztvY879N3KZt2J5udzlDV95doWtsT+YMxp0PVjckTXqlqOfINuMdw5sOYUSTlUNw1a
	MuLq+yjakDkM3tPqjXUyns6V0cok7BgqWk/nDcKDir4rIlkORrAAHyS5fRvqsskIQcka
	JBdu0hx2tRkmmowfXLXqCSWj43fNe/UuUdeafR3AhsZtUNHMhpHpJNdGZ5alaZm3o5cJ
	W88OLR6YG6/bfbLWs3lLEvpr4+dhrEmC3KGgXRRDF4/RBnV+FNhicIqRjLXt5fPSwgg3
	USgC/HXlBM+rT5jdGPmIwy9tGo9K80EOAnzFdSMh3l476IA4+Pvbd7DTtFQBN7+XXVBC
	51KQ==
MIME-Version: 1.0
Received: by 10.14.200.134 with SMTP id z6mr7931581een.33.1348838607995; Fri,
	28 Sep 2012 06:23:27 -0700 (PDT)
Received: by 10.14.215.195 with HTTP; Fri, 28 Sep 2012 06:23:27 -0700 (PDT)
In-Reply-To: <1348765860-11359-2-git-send-email-matthew.fioravante@jhuapl.edu>
References: <1348765860-11359-1-git-send-email-matthew.fioravante@jhuapl.edu>
	<1348765860-11359-2-git-send-email-matthew.fioravante@jhuapl.edu>
Date: Fri, 28 Sep 2012 14:23:27 +0100
X-Google-Sender-Auth: t9Qrdw0rijTZIlLhiD99hWXxocQ
Message-ID: <CAFLBxZZr4w9v-ttE9b9QDGRbxc3GbEgNsfQf=2LZsn4gAAih2A@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
Cc: Ian.Campbell@citrix.com, Jan Beulich <JBeulich@suse.com>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 10/11] make devid a type so it is
	initialized properly
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Sep 27, 2012 at 6:10 PM, Matthew Fioravante
<matthew.fioravante@jhuapl.edu> wrote:
> Previously device ids in libxl were treated as integers meaning they
> were being initialized to 0, which is a valid device id. This patch
> makes devid its own type in libxl and initializes it to -1, an invalid
> value.
>
> This fixes a bug where if you try to do a xl DEV-attach multiple
> time it will continuously try to reattach device 0 instead of
> generating a new device id.
>
> Signed-off-by: Matthew Fioravante <matthew.fioravante@jhuapl.edu>

Reviewed-by: George Dunlap <george.dunlap@eu.citrix.com>

Should this be backported to 4.2-testing?

 -George

>
> diff --git a/tools/libxl/gentest.py b/tools/libxl/gentest.py
> index 2915f71..84b4fd7 100644
> --- a/tools/libxl/gentest.py
> +++ b/tools/libxl/gentest.py
> @@ -60,7 +60,7 @@ def gen_rand_init(ty, v, indent = "    ", parent = None):
>                                          passby=idl.PASS_BY_REFERENCE))
>      elif ty.typename in ["libxl_uuid", "libxl_mac", "libxl_hwcap"]:
>          s += "rand_bytes((uint8_t *)%s, sizeof(*%s));\n" % (v,v)
> -    elif ty.typename in ["libxl_domid"] or isinstance(ty, idl.Number):
> +    elif ty.typename in ["libxl_domid", "libxl_devid"] or isinstance(ty, idl.Number):
>          s += "%s = rand() %% (sizeof(%s)*8);\n" % \
>               (ty.pass_arg(v, parent is None),
>                ty.pass_arg(v, parent is None))
> diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
> index 599c7f1..7a7c419 100644
> --- a/tools/libxl/libxl.h
> +++ b/tools/libxl/libxl.h
> @@ -307,6 +307,7 @@ void libxl_cpuid_dispose(libxl_cpuid_policy_list *cpuid_list);
>  #define LIBXL_PCI_FUNC_ALL (~0U)
>
>  typedef uint32_t libxl_domid;
> +typedef int libxl_devid;
>
>  /*
>   * Formatting Enumerations.
> diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
> index cf83c60..de111a6 100644
> --- a/tools/libxl/libxl_types.idl
> +++ b/tools/libxl/libxl_types.idl
> @@ -8,6 +8,7 @@ namespace("libxl_")
>  libxl_defbool = Builtin("defbool", passby=PASS_BY_REFERENCE)
>
>  libxl_domid = Builtin("domid", json_fn = "yajl_gen_integer", autogenerate_json = False)
> +libxl_devid = Builtin("devid", json_fn = "yajl_gen_integer", autogenerate_json = False, signed = True, init_val="-1")
>  libxl_uuid = Builtin("uuid", passby=PASS_BY_REFERENCE)
>  libxl_mac = Builtin("mac", passby=PASS_BY_REFERENCE)
>  libxl_bitmap = Builtin("bitmap", dispose_fn="libxl_bitmap_dispose", passby=PASS_BY_REFERENCE)
> @@ -343,7 +344,7 @@ libxl_domain_build_info = Struct("domain_build_info",[
>
>  libxl_device_vfb = Struct("device_vfb", [
>      ("backend_domid", libxl_domid),
> -    ("devid",         integer),
> +    ("devid",         libxl_devid),
>      ("vnc",           libxl_vnc_info),
>      ("sdl",           libxl_sdl_info),
>      # set keyboard layout, default is en-us keyboard
> @@ -352,7 +353,7 @@ libxl_device_vfb = Struct("device_vfb", [
>
>  libxl_device_vkb = Struct("device_vkb", [
>      ("backend_domid", libxl_domid),
> -    ("devid", integer),
> +    ("devid", libxl_devid),
>      ])
>
>  libxl_device_disk = Struct("device_disk", [
> @@ -369,7 +370,7 @@ libxl_device_disk = Struct("device_disk", [
>
>  libxl_device_nic = Struct("device_nic", [
>      ("backend_domid", libxl_domid),
> -    ("devid", integer),
> +    ("devid", libxl_devid),
>      ("mtu", integer),
>      ("model", string),
>      ("mac", libxl_mac),
> @@ -399,7 +400,7 @@ libxl_diskinfo = Struct("diskinfo", [
>      ("backend_id", uint32),
>      ("frontend", string),
>      ("frontend_id", uint32),
> -    ("devid", integer),
> +    ("devid", libxl_devid),
>      ("state", integer),
>      ("evtch", integer),
>      ("rref", integer),
> @@ -410,7 +411,7 @@ libxl_nicinfo = Struct("nicinfo", [
>      ("backend_id", uint32),
>      ("frontend", string),
>      ("frontend_id", uint32),
> -    ("devid", integer),
> +    ("devid", libxl_devid),
>      ("state", integer),
>      ("evtch", integer),
>      ("rref_tx", integer),
> diff --git a/tools/ocaml/libs/xl/genwrap.py b/tools/ocaml/libs/xl/genwrap.py
> index 42f374e..97d088d 100644
> --- a/tools/ocaml/libs/xl/genwrap.py
> +++ b/tools/ocaml/libs/xl/genwrap.py
> @@ -10,6 +10,7 @@ builtins = {
>      "int":                  ("int",                    "%(c)s = Int_val(%(o)s)",            "Val_int(%(c)s)"  ),
>      "char *":               ("string",                 "%(c)s = dup_String_val(gc, %(o)s)", "caml_copy_string(%(c)s)"),
>      "libxl_domid":          ("domid",                  "%(c)s = Int_val(%(o)s)",            "Val_int(%(c)s)"  ),
> +    "libxl_devid":          ("devid",                  "%(c)s = Int_val(%(o)s)",            "Val_int(%(c)s)"  ),
>      "libxl_defbool":        ("bool option",            "%(c)s = Defbool_val(%(o)s)",        "Val_defbool(%(c)s)" ),
>      "libxl_uuid":           ("int array",              "Uuid_val(gc, lg, &%(c)s, %(o)s)",   "Val_uuid(&%(c)s)"),
>      "libxl_key_value_list": ("(string * string) list", None,                                None),
> @@ -41,8 +42,8 @@ def stub_fn_name(ty, name):
>      return "stub_xl_%s_%s" % (ty.rawname,name)
>
>  def ocaml_type_of(ty):
> -    if ty.rawname == "domid":
> -        return "domid"
> +    if ty.rawname in ["domid","devid"]:
> +        return ty.rawname
>      elif isinstance(ty,idl.UInt):
>          if ty.width in [8, 16]:
>              # handle as ints
> diff --git a/tools/ocaml/libs/xl/xenlight.ml.in b/tools/ocaml/libs/xl/xenlight.ml.in
> index c47623c..dcc1a38 100644
> --- a/tools/ocaml/libs/xl/xenlight.ml.in
> +++ b/tools/ocaml/libs/xl/xenlight.ml.in
> @@ -16,6 +16,7 @@
>  exception Error of string
>
>  type domid = int
> +type devid = int
>
>  (* @@LIBXL_TYPES@@ *)
>
> diff --git a/tools/ocaml/libs/xl/xenlight.mli.in b/tools/ocaml/libs/xl/xenlight.mli.in
> index 4717bac..3fd0165 100644
> --- a/tools/ocaml/libs/xl/xenlight.mli.in
> +++ b/tools/ocaml/libs/xl/xenlight.mli.in
> @@ -16,6 +16,7 @@
>  exception Error of string
>
>  type domid = int
> +type devid = int
>
>  (* @@LIBXL_TYPES@@ *)
>
> diff --git a/tools/python/xen/lowlevel/xl/xl.c b/tools/python/xen/lowlevel/xl/xl.c
> index 0551c76..32f982a 100644
> --- a/tools/python/xen/lowlevel/xl/xl.c
> +++ b/tools/python/xen/lowlevel/xl/xl.c
> @@ -281,6 +281,11 @@ int attrib__libxl_domid_set(PyObject *v, libxl_domid *domid) {
>      return 0;
>  }
>
> +int attrib__libxl_devid_set(PyObject *v, libxl_devid *devid) {
> +   *devid = PyInt_AsLong(v);
> +   return 0;
> +}
> +
>  int attrib__struct_in_addr_set(PyObject *v, struct in_addr *pptr)
>  {
>      PyErr_SetString(PyExc_NotImplementedError, "Setting in_addr");
> @@ -342,6 +347,10 @@ PyObject *attrib__libxl_domid_get(libxl_domid *domid) {
>      return PyInt_FromLong(*domid);
>  }
>
> +PyObject *attrib__libxl_devid_get(libxl_devid *devid) {
> +    return PyInt_FromLong(*devid);
> +}
> +
>  PyObject *attrib__struct_in_addr_get(struct in_addr *pptr)
>  {
>      PyErr_SetString(PyExc_NotImplementedError, "Getting in_addr");
> --
> 1.7.9.5
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 28 13:23:54 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Sep 2012 13:23: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 1THaXU-0005CG-25; Fri, 28 Sep 2012 13:23:32 +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 1THaXS-0005CB-00
	for xen-devel@lists.xen.org; Fri, 28 Sep 2012 13:23:30 +0000
Received: from [85.158.139.211:9711] by server-5.bemta-5.messagelabs.com id
	64/01-21075-1D4A5605; Fri, 28 Sep 2012 13:23:29 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-11.tower-206.messagelabs.com!1348838608!20345578!1
X-Originating-IP: [209.85.215.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15687 invoked from network); 28 Sep 2012 13:23:28 -0000
Received: from mail-ey0-f173.google.com (HELO mail-ey0-f173.google.com)
	(209.85.215.173)
	by server-11.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Sep 2012 13:23:28 -0000
Received: by eaaa1 with SMTP id a1so1111567eaa.32
	for <xen-devel@lists.xen.org>; Fri, 28 Sep 2012 06:23:28 -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=upbPNhhJpaopW+SaHUZNuWBqdGNIfhlT4/O3VUtQFTQ=;
	b=ztvY879N3KZt2J5udzlDV95doWtsT+YMxp0PVjckTXqlqOfINuMdw5sOYUSTlUNw1a
	MuLq+yjakDkM3tPqjXUyns6V0cok7BgqWk/nDcKDir4rIlkORrAAHyS5fRvqsskIQcka
	JBdu0hx2tRkmmowfXLXqCSWj43fNe/UuUdeafR3AhsZtUNHMhpHpJNdGZ5alaZm3o5cJ
	W88OLR6YG6/bfbLWs3lLEvpr4+dhrEmC3KGgXRRDF4/RBnV+FNhicIqRjLXt5fPSwgg3
	USgC/HXlBM+rT5jdGPmIwy9tGo9K80EOAnzFdSMh3l476IA4+Pvbd7DTtFQBN7+XXVBC
	51KQ==
MIME-Version: 1.0
Received: by 10.14.200.134 with SMTP id z6mr7931581een.33.1348838607995; Fri,
	28 Sep 2012 06:23:27 -0700 (PDT)
Received: by 10.14.215.195 with HTTP; Fri, 28 Sep 2012 06:23:27 -0700 (PDT)
In-Reply-To: <1348765860-11359-2-git-send-email-matthew.fioravante@jhuapl.edu>
References: <1348765860-11359-1-git-send-email-matthew.fioravante@jhuapl.edu>
	<1348765860-11359-2-git-send-email-matthew.fioravante@jhuapl.edu>
Date: Fri, 28 Sep 2012 14:23:27 +0100
X-Google-Sender-Auth: t9Qrdw0rijTZIlLhiD99hWXxocQ
Message-ID: <CAFLBxZZr4w9v-ttE9b9QDGRbxc3GbEgNsfQf=2LZsn4gAAih2A@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
Cc: Ian.Campbell@citrix.com, Jan Beulich <JBeulich@suse.com>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 10/11] make devid a type so it is
	initialized properly
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Sep 27, 2012 at 6:10 PM, Matthew Fioravante
<matthew.fioravante@jhuapl.edu> wrote:
> Previously device ids in libxl were treated as integers meaning they
> were being initialized to 0, which is a valid device id. This patch
> makes devid its own type in libxl and initializes it to -1, an invalid
> value.
>
> This fixes a bug where if you try to do a xl DEV-attach multiple
> time it will continuously try to reattach device 0 instead of
> generating a new device id.
>
> Signed-off-by: Matthew Fioravante <matthew.fioravante@jhuapl.edu>

Reviewed-by: George Dunlap <george.dunlap@eu.citrix.com>

Should this be backported to 4.2-testing?

 -George

>
> diff --git a/tools/libxl/gentest.py b/tools/libxl/gentest.py
> index 2915f71..84b4fd7 100644
> --- a/tools/libxl/gentest.py
> +++ b/tools/libxl/gentest.py
> @@ -60,7 +60,7 @@ def gen_rand_init(ty, v, indent = "    ", parent = None):
>                                          passby=idl.PASS_BY_REFERENCE))
>      elif ty.typename in ["libxl_uuid", "libxl_mac", "libxl_hwcap"]:
>          s += "rand_bytes((uint8_t *)%s, sizeof(*%s));\n" % (v,v)
> -    elif ty.typename in ["libxl_domid"] or isinstance(ty, idl.Number):
> +    elif ty.typename in ["libxl_domid", "libxl_devid"] or isinstance(ty, idl.Number):
>          s += "%s = rand() %% (sizeof(%s)*8);\n" % \
>               (ty.pass_arg(v, parent is None),
>                ty.pass_arg(v, parent is None))
> diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
> index 599c7f1..7a7c419 100644
> --- a/tools/libxl/libxl.h
> +++ b/tools/libxl/libxl.h
> @@ -307,6 +307,7 @@ void libxl_cpuid_dispose(libxl_cpuid_policy_list *cpuid_list);
>  #define LIBXL_PCI_FUNC_ALL (~0U)
>
>  typedef uint32_t libxl_domid;
> +typedef int libxl_devid;
>
>  /*
>   * Formatting Enumerations.
> diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
> index cf83c60..de111a6 100644
> --- a/tools/libxl/libxl_types.idl
> +++ b/tools/libxl/libxl_types.idl
> @@ -8,6 +8,7 @@ namespace("libxl_")
>  libxl_defbool = Builtin("defbool", passby=PASS_BY_REFERENCE)
>
>  libxl_domid = Builtin("domid", json_fn = "yajl_gen_integer", autogenerate_json = False)
> +libxl_devid = Builtin("devid", json_fn = "yajl_gen_integer", autogenerate_json = False, signed = True, init_val="-1")
>  libxl_uuid = Builtin("uuid", passby=PASS_BY_REFERENCE)
>  libxl_mac = Builtin("mac", passby=PASS_BY_REFERENCE)
>  libxl_bitmap = Builtin("bitmap", dispose_fn="libxl_bitmap_dispose", passby=PASS_BY_REFERENCE)
> @@ -343,7 +344,7 @@ libxl_domain_build_info = Struct("domain_build_info",[
>
>  libxl_device_vfb = Struct("device_vfb", [
>      ("backend_domid", libxl_domid),
> -    ("devid",         integer),
> +    ("devid",         libxl_devid),
>      ("vnc",           libxl_vnc_info),
>      ("sdl",           libxl_sdl_info),
>      # set keyboard layout, default is en-us keyboard
> @@ -352,7 +353,7 @@ libxl_device_vfb = Struct("device_vfb", [
>
>  libxl_device_vkb = Struct("device_vkb", [
>      ("backend_domid", libxl_domid),
> -    ("devid", integer),
> +    ("devid", libxl_devid),
>      ])
>
>  libxl_device_disk = Struct("device_disk", [
> @@ -369,7 +370,7 @@ libxl_device_disk = Struct("device_disk", [
>
>  libxl_device_nic = Struct("device_nic", [
>      ("backend_domid", libxl_domid),
> -    ("devid", integer),
> +    ("devid", libxl_devid),
>      ("mtu", integer),
>      ("model", string),
>      ("mac", libxl_mac),
> @@ -399,7 +400,7 @@ libxl_diskinfo = Struct("diskinfo", [
>      ("backend_id", uint32),
>      ("frontend", string),
>      ("frontend_id", uint32),
> -    ("devid", integer),
> +    ("devid", libxl_devid),
>      ("state", integer),
>      ("evtch", integer),
>      ("rref", integer),
> @@ -410,7 +411,7 @@ libxl_nicinfo = Struct("nicinfo", [
>      ("backend_id", uint32),
>      ("frontend", string),
>      ("frontend_id", uint32),
> -    ("devid", integer),
> +    ("devid", libxl_devid),
>      ("state", integer),
>      ("evtch", integer),
>      ("rref_tx", integer),
> diff --git a/tools/ocaml/libs/xl/genwrap.py b/tools/ocaml/libs/xl/genwrap.py
> index 42f374e..97d088d 100644
> --- a/tools/ocaml/libs/xl/genwrap.py
> +++ b/tools/ocaml/libs/xl/genwrap.py
> @@ -10,6 +10,7 @@ builtins = {
>      "int":                  ("int",                    "%(c)s = Int_val(%(o)s)",            "Val_int(%(c)s)"  ),
>      "char *":               ("string",                 "%(c)s = dup_String_val(gc, %(o)s)", "caml_copy_string(%(c)s)"),
>      "libxl_domid":          ("domid",                  "%(c)s = Int_val(%(o)s)",            "Val_int(%(c)s)"  ),
> +    "libxl_devid":          ("devid",                  "%(c)s = Int_val(%(o)s)",            "Val_int(%(c)s)"  ),
>      "libxl_defbool":        ("bool option",            "%(c)s = Defbool_val(%(o)s)",        "Val_defbool(%(c)s)" ),
>      "libxl_uuid":           ("int array",              "Uuid_val(gc, lg, &%(c)s, %(o)s)",   "Val_uuid(&%(c)s)"),
>      "libxl_key_value_list": ("(string * string) list", None,                                None),
> @@ -41,8 +42,8 @@ def stub_fn_name(ty, name):
>      return "stub_xl_%s_%s" % (ty.rawname,name)
>
>  def ocaml_type_of(ty):
> -    if ty.rawname == "domid":
> -        return "domid"
> +    if ty.rawname in ["domid","devid"]:
> +        return ty.rawname
>      elif isinstance(ty,idl.UInt):
>          if ty.width in [8, 16]:
>              # handle as ints
> diff --git a/tools/ocaml/libs/xl/xenlight.ml.in b/tools/ocaml/libs/xl/xenlight.ml.in
> index c47623c..dcc1a38 100644
> --- a/tools/ocaml/libs/xl/xenlight.ml.in
> +++ b/tools/ocaml/libs/xl/xenlight.ml.in
> @@ -16,6 +16,7 @@
>  exception Error of string
>
>  type domid = int
> +type devid = int
>
>  (* @@LIBXL_TYPES@@ *)
>
> diff --git a/tools/ocaml/libs/xl/xenlight.mli.in b/tools/ocaml/libs/xl/xenlight.mli.in
> index 4717bac..3fd0165 100644
> --- a/tools/ocaml/libs/xl/xenlight.mli.in
> +++ b/tools/ocaml/libs/xl/xenlight.mli.in
> @@ -16,6 +16,7 @@
>  exception Error of string
>
>  type domid = int
> +type devid = int
>
>  (* @@LIBXL_TYPES@@ *)
>
> diff --git a/tools/python/xen/lowlevel/xl/xl.c b/tools/python/xen/lowlevel/xl/xl.c
> index 0551c76..32f982a 100644
> --- a/tools/python/xen/lowlevel/xl/xl.c
> +++ b/tools/python/xen/lowlevel/xl/xl.c
> @@ -281,6 +281,11 @@ int attrib__libxl_domid_set(PyObject *v, libxl_domid *domid) {
>      return 0;
>  }
>
> +int attrib__libxl_devid_set(PyObject *v, libxl_devid *devid) {
> +   *devid = PyInt_AsLong(v);
> +   return 0;
> +}
> +
>  int attrib__struct_in_addr_set(PyObject *v, struct in_addr *pptr)
>  {
>      PyErr_SetString(PyExc_NotImplementedError, "Setting in_addr");
> @@ -342,6 +347,10 @@ PyObject *attrib__libxl_domid_get(libxl_domid *domid) {
>      return PyInt_FromLong(*domid);
>  }
>
> +PyObject *attrib__libxl_devid_get(libxl_devid *devid) {
> +    return PyInt_FromLong(*devid);
> +}
> +
>  PyObject *attrib__struct_in_addr_get(struct in_addr *pptr)
>  {
>      PyErr_SetString(PyExc_NotImplementedError, "Getting in_addr");
> --
> 1.7.9.5
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 28 13:57:40 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Sep 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 1THb43-0005Op-R0; Fri, 28 Sep 2012 13:57:11 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <matthew.fioravante@jhuapl.edu>) id 1THb42-0005Oh-7E
	for xen-devel@lists.xen.org; Fri, 28 Sep 2012 13:57:10 +0000
X-Env-Sender: matthew.fioravante@jhuapl.edu
X-Msg-Ref: server-13.tower-27.messagelabs.com!1348840621!11633506!1
X-Originating-IP: [128.244.251.36]
X-SpamReason: No, hits=0.0 required=7.0 tests=UNPARSEABLE_RELAY
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8697 invoked from network); 28 Sep 2012 13:57:02 -0000
Received: from pilot.jhuapl.edu (HELO jhuapl.edu) (128.244.251.36)
	by server-13.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 28 Sep 2012 13:57:02 -0000
Received: from ([128.244.207.89])
	by pilot.jhuapl.edu with ESMTP with TLS id 63GHCH1.153870643;
	Fri, 28 Sep 2012 09:56:56 -0400
Message-ID: <5065AC58.4010309@jhuapl.edu>
Date: Fri, 28 Sep 2012 09:55:36 -0400
From: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120827 Thunderbird/15.0
MIME-Version: 1.0
To: Jordi Cucurull Juan <jordi.cucurull@scytl.com>
References: <50647387.5080607@scytl.com> <5064740B.5030402@jhuapl.edu>
	<506553C5.3090507@scytl.com>
In-Reply-To: <506553C5.3090507@scytl.com>
X-Enigmail-Version: 1.4.4
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Compile Xen with VTPM support
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============6592589027676442266=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a cryptographically signed message in MIME format.

--===============6592589027676442266==
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms090407090000030604030709"

This is a cryptographically signed message in MIME format.

--------------ms090407090000030604030709
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

It uses the physical tpm. Hopefully they should all be in within a
month. Were working on it now.

On 09/28/2012 03:37 AM, Jordi Cucurull Juan wrote:
> Hi Matthew,
>
> As a rough approximation, when are you planning to submit the new vtpm =

> implementation? In the new coming weeks, months, year?
>
> And, is this new vtpm going to be linked to the physical tpm of the=20
> machine or is going to be totally independent of it?
>
> Best,
> Jordi
>
>
> On 09/27/2012 05:43 PM, Matthew Fioravante wrote:
>> The current (old) vtpm implementation still sort of works. You have to=

>> use xm and find a linux kernel with the tpmfront and tpmback drivers. =
I
>> believe the original xen 2.6.18 kernel has them. There may or may not =
be
>> newer kernels with these drivers.
>>
>> docs/misc/vtpm.txt should have everything you need to use it.
>>
>> That being said I'm in the process of submitting my new vtpm
>> implementation. So keep an eye on that activity if you're interested.
>>
>> On 09/27/2012 11:40 AM, Jordi Cucurull Juan wrote:
>>> Dear all,
>>>
>>> I am trying to compile Xen 4.2.0 with VTPM support. The documentation=

>>> available inside Xen is from 2006. I am wondering if the current step=
s
>>> to enable VTPM support are the same written in the documentation or t=
hey
>>> have changed.
>>>
>>> Is it enough with setting the "--enable-vtpm" argument during the
>>> configure process? Furthermore, at that time Xen was providing the Li=
nux
>>> Kernel as part of its sources. Have the current kernels to be patched=
 to
>>> include the Xen VTPM drivers? If it is the case, where can we find th=
e
>>> patches?
>>>
>>> Thank you in advance!
>>> Jordi.
>>>
>>>
>>>
>>> _______________________________________________
>>> Xen-devel mailing list
>>> Xen-devel@lists.xen.org
>>> http://lists.xen.org/xen-devel
>



--------------ms090407090000030604030709
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIDyjCC
A8YwggMvoAMCAQICBD/xyf0wDQYJKoZIhvcNAQEFBQAwLzELMAkGA1UEBhMCVVMxDzANBgNV
BAoTBkpIVUFQTDEPMA0GA1UECxMGQklTRENBMB4XDTEwMDYxMTE4MjIwNloXDTEzMDYxMTE4
NTIwNlowZjELMAkGA1UEBhMCVVMxDzANBgNVBAoTBkpIVUFQTDEPMA0GA1UECxMGUGVvcGxl
MTUwFgYDVQQLEw9WUE5Hcm91cC1CSVNEQ0EwGwYDVQQDExRNYXR0aGV3IEUgRmlvcmF2YW50
ZTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAnpbwVSP6o1Nb5lcW7dd3yTo9iBJdi7qz
4nANOMFPK7JOy5npKN1iiousl28U/scUJES55gPwAWYJK3uVyQAsA4adgDKi5DoD1UHDQEwp
bY7iHLJeq0NPr4BqYNqnCFPbE6HC8zSJrr4qKn+gVUQT39SIFqdiIPJwZL8FYTRQ/zsCAwEA
AaOCAbYwggGyMAsGA1UdDwQEAwIHgDArBgNVHRAEJDAigA8yMDEwMDYxMTE4MjIwNlqBDzIw
MTIwNzE3MjI1MjA2WjAbBg0rBgEEAbMlCwMBAQEBBAoWCGZpb3JhbWUxMBsGDSsGAQQBsyUL
AwEBAQIEChIIMDAxMDQyNjEwWAYJYIZIAYb6ax4BBEsMSVRoZSBwcml2YXRlIGtleSBjb3Jy
ZXNwb25kaW5nIHRvIHRoaXMgY2VydGlmaWNhdGUgbWF5IGhhdmUgYmVlbiBleHBvcnRlZC4w
KAYDVR0RBCEwH4EdTWF0dGhldy5GaW9yYXZhbnRlQGpodWFwbC5lZHUwUgYDVR0fBEswSTBH
oEWgQ6RBMD8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJU0RD
QTEOMAwGA1UEAxMFQ1JMNTYwHwYDVR0jBBgwFoAUCDUpmxH52EU2CyWmF2EJMB1yqeswHQYD
VR0OBBYEFO6LYxg6r9wHZ+zdQtBHn1dZ/YTNMAkGA1UdEwQCMAAwGQYJKoZIhvZ9B0EABAww
ChsEVjcuMQMCBLAwDQYJKoZIhvcNAQEFBQADgYEAJO9HQh4YNChVLzuZqK5ARJARD8JoujGZ
fdo75quvg2jXFQe2sEjvLnxJZgm/pv8fdZakq48CWwjYHKuvIp7sDjTEsQfo+y7SpN/N2NvJ
WU5SqfK1VgYtNLRRoGJUB5Q1aZ+Dg95g3kqpyfpUMISJL8IKVLtJVfN4fggFVUYZ9wwxggGr
MIIBpwIBATA3MC8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJ
U0RDQQIEP/HJ/TAJBgUrDgMCGgUAoIHLMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ
KoZIhvcNAQkFMQ8XDTEyMDkyODEzNTUzNlowIwYJKoZIhvcNAQkEMRYEFAZSJ3bVBYxij2oM
qfdvHaxMvcPGMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAK
BggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI
KoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEgYBrlFpuRs6+ycK9fyjGHhJWKNkB2S6D3lLc
R0WxlDeURCpGgcXlux5/Bq747oUYh5/QHaVTc8cBIFGYhmEW2K7E7ceCeFIoeQHih929iLdV
6Mi0ugFzxcTZdiWzxpSXDwpoFbOZ9xwLLUJKV1rlnKGww2Fz/pCc8x0dz/MaY4RvNwAAAAAA
AA==
--------------ms090407090000030604030709--


--===============6592589027676442266==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============6592589027676442266==--


From xen-devel-bounces@lists.xen.org Fri Sep 28 13:57:40 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Sep 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 1THb43-0005Op-R0; Fri, 28 Sep 2012 13:57:11 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <matthew.fioravante@jhuapl.edu>) id 1THb42-0005Oh-7E
	for xen-devel@lists.xen.org; Fri, 28 Sep 2012 13:57:10 +0000
X-Env-Sender: matthew.fioravante@jhuapl.edu
X-Msg-Ref: server-13.tower-27.messagelabs.com!1348840621!11633506!1
X-Originating-IP: [128.244.251.36]
X-SpamReason: No, hits=0.0 required=7.0 tests=UNPARSEABLE_RELAY
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8697 invoked from network); 28 Sep 2012 13:57:02 -0000
Received: from pilot.jhuapl.edu (HELO jhuapl.edu) (128.244.251.36)
	by server-13.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 28 Sep 2012 13:57:02 -0000
Received: from ([128.244.207.89])
	by pilot.jhuapl.edu with ESMTP with TLS id 63GHCH1.153870643;
	Fri, 28 Sep 2012 09:56:56 -0400
Message-ID: <5065AC58.4010309@jhuapl.edu>
Date: Fri, 28 Sep 2012 09:55:36 -0400
From: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120827 Thunderbird/15.0
MIME-Version: 1.0
To: Jordi Cucurull Juan <jordi.cucurull@scytl.com>
References: <50647387.5080607@scytl.com> <5064740B.5030402@jhuapl.edu>
	<506553C5.3090507@scytl.com>
In-Reply-To: <506553C5.3090507@scytl.com>
X-Enigmail-Version: 1.4.4
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Compile Xen with VTPM support
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============6592589027676442266=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a cryptographically signed message in MIME format.

--===============6592589027676442266==
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms090407090000030604030709"

This is a cryptographically signed message in MIME format.

--------------ms090407090000030604030709
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

It uses the physical tpm. Hopefully they should all be in within a
month. Were working on it now.

On 09/28/2012 03:37 AM, Jordi Cucurull Juan wrote:
> Hi Matthew,
>
> As a rough approximation, when are you planning to submit the new vtpm =

> implementation? In the new coming weeks, months, year?
>
> And, is this new vtpm going to be linked to the physical tpm of the=20
> machine or is going to be totally independent of it?
>
> Best,
> Jordi
>
>
> On 09/27/2012 05:43 PM, Matthew Fioravante wrote:
>> The current (old) vtpm implementation still sort of works. You have to=

>> use xm and find a linux kernel with the tpmfront and tpmback drivers. =
I
>> believe the original xen 2.6.18 kernel has them. There may or may not =
be
>> newer kernels with these drivers.
>>
>> docs/misc/vtpm.txt should have everything you need to use it.
>>
>> That being said I'm in the process of submitting my new vtpm
>> implementation. So keep an eye on that activity if you're interested.
>>
>> On 09/27/2012 11:40 AM, Jordi Cucurull Juan wrote:
>>> Dear all,
>>>
>>> I am trying to compile Xen 4.2.0 with VTPM support. The documentation=

>>> available inside Xen is from 2006. I am wondering if the current step=
s
>>> to enable VTPM support are the same written in the documentation or t=
hey
>>> have changed.
>>>
>>> Is it enough with setting the "--enable-vtpm" argument during the
>>> configure process? Furthermore, at that time Xen was providing the Li=
nux
>>> Kernel as part of its sources. Have the current kernels to be patched=
 to
>>> include the Xen VTPM drivers? If it is the case, where can we find th=
e
>>> patches?
>>>
>>> Thank you in advance!
>>> Jordi.
>>>
>>>
>>>
>>> _______________________________________________
>>> Xen-devel mailing list
>>> Xen-devel@lists.xen.org
>>> http://lists.xen.org/xen-devel
>



--------------ms090407090000030604030709
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIDyjCC
A8YwggMvoAMCAQICBD/xyf0wDQYJKoZIhvcNAQEFBQAwLzELMAkGA1UEBhMCVVMxDzANBgNV
BAoTBkpIVUFQTDEPMA0GA1UECxMGQklTRENBMB4XDTEwMDYxMTE4MjIwNloXDTEzMDYxMTE4
NTIwNlowZjELMAkGA1UEBhMCVVMxDzANBgNVBAoTBkpIVUFQTDEPMA0GA1UECxMGUGVvcGxl
MTUwFgYDVQQLEw9WUE5Hcm91cC1CSVNEQ0EwGwYDVQQDExRNYXR0aGV3IEUgRmlvcmF2YW50
ZTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAnpbwVSP6o1Nb5lcW7dd3yTo9iBJdi7qz
4nANOMFPK7JOy5npKN1iiousl28U/scUJES55gPwAWYJK3uVyQAsA4adgDKi5DoD1UHDQEwp
bY7iHLJeq0NPr4BqYNqnCFPbE6HC8zSJrr4qKn+gVUQT39SIFqdiIPJwZL8FYTRQ/zsCAwEA
AaOCAbYwggGyMAsGA1UdDwQEAwIHgDArBgNVHRAEJDAigA8yMDEwMDYxMTE4MjIwNlqBDzIw
MTIwNzE3MjI1MjA2WjAbBg0rBgEEAbMlCwMBAQEBBAoWCGZpb3JhbWUxMBsGDSsGAQQBsyUL
AwEBAQIEChIIMDAxMDQyNjEwWAYJYIZIAYb6ax4BBEsMSVRoZSBwcml2YXRlIGtleSBjb3Jy
ZXNwb25kaW5nIHRvIHRoaXMgY2VydGlmaWNhdGUgbWF5IGhhdmUgYmVlbiBleHBvcnRlZC4w
KAYDVR0RBCEwH4EdTWF0dGhldy5GaW9yYXZhbnRlQGpodWFwbC5lZHUwUgYDVR0fBEswSTBH
oEWgQ6RBMD8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJU0RD
QTEOMAwGA1UEAxMFQ1JMNTYwHwYDVR0jBBgwFoAUCDUpmxH52EU2CyWmF2EJMB1yqeswHQYD
VR0OBBYEFO6LYxg6r9wHZ+zdQtBHn1dZ/YTNMAkGA1UdEwQCMAAwGQYJKoZIhvZ9B0EABAww
ChsEVjcuMQMCBLAwDQYJKoZIhvcNAQEFBQADgYEAJO9HQh4YNChVLzuZqK5ARJARD8JoujGZ
fdo75quvg2jXFQe2sEjvLnxJZgm/pv8fdZakq48CWwjYHKuvIp7sDjTEsQfo+y7SpN/N2NvJ
WU5SqfK1VgYtNLRRoGJUB5Q1aZ+Dg95g3kqpyfpUMISJL8IKVLtJVfN4fggFVUYZ9wwxggGr
MIIBpwIBATA3MC8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJ
U0RDQQIEP/HJ/TAJBgUrDgMCGgUAoIHLMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ
KoZIhvcNAQkFMQ8XDTEyMDkyODEzNTUzNlowIwYJKoZIhvcNAQkEMRYEFAZSJ3bVBYxij2oM
qfdvHaxMvcPGMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAK
BggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI
KoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEgYBrlFpuRs6+ycK9fyjGHhJWKNkB2S6D3lLc
R0WxlDeURCpGgcXlux5/Bq747oUYh5/QHaVTc8cBIFGYhmEW2K7E7ceCeFIoeQHih929iLdV
6Mi0ugFzxcTZdiWzxpSXDwpoFbOZ9xwLLUJKV1rlnKGww2Fz/pCc8x0dz/MaY4RvNwAAAAAA
AA==
--------------ms090407090000030604030709--


--===============6592589027676442266==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============6592589027676442266==--


From xen-devel-bounces@lists.xen.org Fri Sep 28 13:59:21 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Sep 2012 13:59:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1THb5l-0005Sy-B2; Fri, 28 Sep 2012 13:58:57 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <matthew.fioravante@jhuapl.edu>) id 1THb5k-0005Ss-6Z
	for xen-devel@lists.xen.org; Fri, 28 Sep 2012 13:58:56 +0000
Received: from [85.158.143.99:42500] by server-1.bemta-4.messagelabs.com id
	CC/1B-05684-F1DA5605; Fri, 28 Sep 2012 13:58:55 +0000
X-Env-Sender: matthew.fioravante@jhuapl.edu
X-Msg-Ref: server-9.tower-216.messagelabs.com!1348840733!32184632!1
X-Originating-IP: [128.244.251.36]
X-SpamReason: No, hits=0.0 required=7.0 tests=UNPARSEABLE_RELAY
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9446 invoked from network); 28 Sep 2012 13:58:54 -0000
Received: from pilot.jhuapl.edu (HELO jhuapl.edu) (128.244.251.36)
	by server-9.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 28 Sep 2012 13:58:54 -0000
Received: from ([128.244.207.89])
	by pilot.jhuapl.edu with ESMTP with TLS id 63GHCH1.153870791;
	Fri, 28 Sep 2012 09:58:31 -0400
Message-ID: <5065ACB7.3040902@jhuapl.edu>
Date: Fri, 28 Sep 2012 09:57:11 -0400
From: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120827 Thunderbird/15.0
MIME-Version: 1.0
To: George Dunlap <George.Dunlap@eu.citrix.com>
References: <1348765802-11314-1-git-send-email-matthew.fioravante@jhuapl.edu>
	<CAFLBxZYaDJZW7rXTnzo4UtxJbfggZz86Szw4O=30q2RxtNocBg@mail.gmail.com>
In-Reply-To: <CAFLBxZYaDJZW7rXTnzo4UtxJbfggZz86Szw4O=30q2RxtNocBg@mail.gmail.com>
X-Enigmail-Version: 1.4.4
Cc: "samuel.thibault@ens-lyon.org" <samuel.thibault@ens-lyon.org>,
	"Ian.Campbell@citrix.com" <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 01/11] Add ioread/iowrite functions to
	mini-os
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============6042815001863481987=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a cryptographically signed message in MIME format.

--===============6042815001863481987==
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms030803060304020706070800"

This is a cryptographically signed message in MIME format.

--------------ms030803060304020706070800
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On 09/28/2012 06:16 AM, George Dunlap wrote:
> On Thu, Sep 27, 2012 at 6:09 PM, Matthew Fioravante
> <matthew.fioravante@jhuapl.edu> wrote:
>> This patch adds iowritexx() and ioreadxx() functions for interacting
>> with hardware memory to mini-os. The functions are available in a head=
er
>> iorw.h
>>
>> Signed-off-by: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
>> Acked-by: Samuel Thibault <samuel.thibault@ens-lyon.org>
>>
>> diff --git a/extras/mini-os/arch/ia64/iorw.c b/extras/mini-os/arch/ia6=
4/iorw.c
> Is there any reason to have the ia64 stuff? ia64 isn't supported in
> Xen anymore, AFAIK.
Maybe not. But until ia64 support is removed from mini-os the function
bodies should exist so stuff will compile.
>  -George
>
>> new file mode 100644
>> index 0000000..aa58807
>> --- /dev/null
>> +++ b/extras/mini-os/arch/ia64/iorw.c
>> @@ -0,0 +1,48 @@
>> +#include <mini-os/iorw.h>
>> +#include <mini-os/console.h>
>> +
>> +void iowrite8(volatile void* addr, uint8_t val)
>> +{
>> +   printk("iorw not implemented!!\n");
>> +   BUG();
>> +}
>> +void iowrite16(volatile void* addr, uint16_t val)
>> +{
>> +   printk("iorw not implemented!!\n");
>> +   BUG();
>> +}
>> +void iowrite32(volatile void* addr, uint32_t val)
>> +{
>> +   printk("iorw not implemented!!\n");
>> +   BUG();
>> +}
>> +void iowrite64(volatile void* addr, uint64_t val)
>> +{
>> +   printk("iorw not implemented!!\n");
>> +   BUG();
>> +}
>> +
>> +uint8_t ioread8(volatile void* addr)
>> +{
>> +   printk("iorw not implemented!!\n");
>> +   BUG();
>> +   return 0;
>> +}
>> +uint16_t ioread16(volatile void* addr)
>> +{
>> +   printk("iorw not implemented!!\n");
>> +   BUG();
>> +   return 0;
>> +}
>> +uint32_t ioread32(volatile void* addr)
>> +{
>> +   printk("iorw not implemented!!\n");
>> +   BUG();
>> +   return 0;
>> +}
>> +uint64_t ioread64(volatile void* addr)
>> +{
>> +   printk("iorw not implemented!!\n");
>> +   BUG();
>> +   return 0;
>> +}
>> diff --git a/extras/mini-os/arch/x86/iorw.c b/extras/mini-os/arch/x86/=
iorw.c
>> new file mode 100644
>> index 0000000..3080769
>> --- /dev/null
>> +++ b/extras/mini-os/arch/x86/iorw.c
>> @@ -0,0 +1,35 @@
>> +#include <mini-os/iorw.h>
>> +
>> +void iowrite8(volatile void* addr, uint8_t val)
>> +{
>> +   *((volatile uint8_t*)addr) =3D val;
>> +}
>> +void iowrite16(volatile void* addr, uint16_t val)
>> +{
>> +   *((volatile uint16_t*)addr) =3D val;
>> +}
>> +void iowrite32(volatile void* addr, uint32_t val)
>> +{
>> +   *((volatile uint32_t*)addr) =3D val;
>> +}
>> +void iowrite64(volatile void* addr, uint64_t val)
>> +{
>> +   *((volatile uint64_t*)addr) =3D val;
>> +}
>> +
>> +uint8_t ioread8(volatile void* addr)
>> +{
>> +   return *((volatile uint8_t*) addr);
>> +}
>> +uint16_t ioread16(volatile void* addr)
>> +{
>> +   return *((volatile uint16_t*) addr);
>> +}
>> +uint32_t ioread32(volatile void* addr)
>> +{
>> +   return *((volatile uint32_t*) addr);
>> +}
>> +uint64_t ioread64(volatile void* addr)
>> +{
>> +   return *((volatile uint64_t*) addr);
>> +}
>> diff --git a/extras/mini-os/include/iorw.h b/extras/mini-os/include/io=
rw.h
>> new file mode 100644
>> index 0000000..d5ec065
>> --- /dev/null
>> +++ b/extras/mini-os/include/iorw.h
>> @@ -0,0 +1,16 @@
>> +#ifndef MINIOS_IORW_H
>> +#define MINIOS_IORW_H
>> +
>> +#include <mini-os/types.h>
>> +
>> +void iowrite8(volatile void* addr, uint8_t val);
>> +void iowrite16(volatile void* addr, uint16_t val);
>> +void iowrite32(volatile void* addr, uint32_t val);
>> +void iowrite64(volatile void* addr, uint64_t val);
>> +
>> +uint8_t ioread8(volatile void* addr);
>> +uint16_t ioread16(volatile void* addr);
>> +uint32_t ioread32(volatile void* addr);
>> +uint64_t ioread64(volatile void* addr);
>> +
>> +#endif
>> --
>> 1.7.9.5
>>
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xen.org
>> http://lists.xen.org/xen-devel



--------------ms030803060304020706070800
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIDyjCC
A8YwggMvoAMCAQICBD/xyf0wDQYJKoZIhvcNAQEFBQAwLzELMAkGA1UEBhMCVVMxDzANBgNV
BAoTBkpIVUFQTDEPMA0GA1UECxMGQklTRENBMB4XDTEwMDYxMTE4MjIwNloXDTEzMDYxMTE4
NTIwNlowZjELMAkGA1UEBhMCVVMxDzANBgNVBAoTBkpIVUFQTDEPMA0GA1UECxMGUGVvcGxl
MTUwFgYDVQQLEw9WUE5Hcm91cC1CSVNEQ0EwGwYDVQQDExRNYXR0aGV3IEUgRmlvcmF2YW50
ZTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAnpbwVSP6o1Nb5lcW7dd3yTo9iBJdi7qz
4nANOMFPK7JOy5npKN1iiousl28U/scUJES55gPwAWYJK3uVyQAsA4adgDKi5DoD1UHDQEwp
bY7iHLJeq0NPr4BqYNqnCFPbE6HC8zSJrr4qKn+gVUQT39SIFqdiIPJwZL8FYTRQ/zsCAwEA
AaOCAbYwggGyMAsGA1UdDwQEAwIHgDArBgNVHRAEJDAigA8yMDEwMDYxMTE4MjIwNlqBDzIw
MTIwNzE3MjI1MjA2WjAbBg0rBgEEAbMlCwMBAQEBBAoWCGZpb3JhbWUxMBsGDSsGAQQBsyUL
AwEBAQIEChIIMDAxMDQyNjEwWAYJYIZIAYb6ax4BBEsMSVRoZSBwcml2YXRlIGtleSBjb3Jy
ZXNwb25kaW5nIHRvIHRoaXMgY2VydGlmaWNhdGUgbWF5IGhhdmUgYmVlbiBleHBvcnRlZC4w
KAYDVR0RBCEwH4EdTWF0dGhldy5GaW9yYXZhbnRlQGpodWFwbC5lZHUwUgYDVR0fBEswSTBH
oEWgQ6RBMD8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJU0RD
QTEOMAwGA1UEAxMFQ1JMNTYwHwYDVR0jBBgwFoAUCDUpmxH52EU2CyWmF2EJMB1yqeswHQYD
VR0OBBYEFO6LYxg6r9wHZ+zdQtBHn1dZ/YTNMAkGA1UdEwQCMAAwGQYJKoZIhvZ9B0EABAww
ChsEVjcuMQMCBLAwDQYJKoZIhvcNAQEFBQADgYEAJO9HQh4YNChVLzuZqK5ARJARD8JoujGZ
fdo75quvg2jXFQe2sEjvLnxJZgm/pv8fdZakq48CWwjYHKuvIp7sDjTEsQfo+y7SpN/N2NvJ
WU5SqfK1VgYtNLRRoGJUB5Q1aZ+Dg95g3kqpyfpUMISJL8IKVLtJVfN4fggFVUYZ9wwxggGr
MIIBpwIBATA3MC8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJ
U0RDQQIEP/HJ/TAJBgUrDgMCGgUAoIHLMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ
KoZIhvcNAQkFMQ8XDTEyMDkyODEzNTcxMVowIwYJKoZIhvcNAQkEMRYEFF96nPMuUFb14Lsl
+TyU1h/JFPhtMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAK
BggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI
KoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEgYCC9FXWiWEvkDeDR6cE8YGCnIeksLL8NUKb
Yly4fhEnv11F/j3+eMriZAkA2nvRMmZ+2ZwKK1sDtshw5s+CV0vxyCpiDPA8BtHzRKQgz99d
bcSpHTj94eA1IYn+4eCJfIi+wsAY3lEBPU0THwrpW91Gyn6CPxnpltYOrRDYBIJcMQAAAAAA
AA==
--------------ms030803060304020706070800--


--===============6042815001863481987==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============6042815001863481987==--


From xen-devel-bounces@lists.xen.org Fri Sep 28 13:59:21 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Sep 2012 13:59:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1THb5l-0005Sy-B2; Fri, 28 Sep 2012 13:58:57 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <matthew.fioravante@jhuapl.edu>) id 1THb5k-0005Ss-6Z
	for xen-devel@lists.xen.org; Fri, 28 Sep 2012 13:58:56 +0000
Received: from [85.158.143.99:42500] by server-1.bemta-4.messagelabs.com id
	CC/1B-05684-F1DA5605; Fri, 28 Sep 2012 13:58:55 +0000
X-Env-Sender: matthew.fioravante@jhuapl.edu
X-Msg-Ref: server-9.tower-216.messagelabs.com!1348840733!32184632!1
X-Originating-IP: [128.244.251.36]
X-SpamReason: No, hits=0.0 required=7.0 tests=UNPARSEABLE_RELAY
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9446 invoked from network); 28 Sep 2012 13:58:54 -0000
Received: from pilot.jhuapl.edu (HELO jhuapl.edu) (128.244.251.36)
	by server-9.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 28 Sep 2012 13:58:54 -0000
Received: from ([128.244.207.89])
	by pilot.jhuapl.edu with ESMTP with TLS id 63GHCH1.153870791;
	Fri, 28 Sep 2012 09:58:31 -0400
Message-ID: <5065ACB7.3040902@jhuapl.edu>
Date: Fri, 28 Sep 2012 09:57:11 -0400
From: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120827 Thunderbird/15.0
MIME-Version: 1.0
To: George Dunlap <George.Dunlap@eu.citrix.com>
References: <1348765802-11314-1-git-send-email-matthew.fioravante@jhuapl.edu>
	<CAFLBxZYaDJZW7rXTnzo4UtxJbfggZz86Szw4O=30q2RxtNocBg@mail.gmail.com>
In-Reply-To: <CAFLBxZYaDJZW7rXTnzo4UtxJbfggZz86Szw4O=30q2RxtNocBg@mail.gmail.com>
X-Enigmail-Version: 1.4.4
Cc: "samuel.thibault@ens-lyon.org" <samuel.thibault@ens-lyon.org>,
	"Ian.Campbell@citrix.com" <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 01/11] Add ioread/iowrite functions to
	mini-os
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============6042815001863481987=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a cryptographically signed message in MIME format.

--===============6042815001863481987==
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms030803060304020706070800"

This is a cryptographically signed message in MIME format.

--------------ms030803060304020706070800
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On 09/28/2012 06:16 AM, George Dunlap wrote:
> On Thu, Sep 27, 2012 at 6:09 PM, Matthew Fioravante
> <matthew.fioravante@jhuapl.edu> wrote:
>> This patch adds iowritexx() and ioreadxx() functions for interacting
>> with hardware memory to mini-os. The functions are available in a head=
er
>> iorw.h
>>
>> Signed-off-by: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
>> Acked-by: Samuel Thibault <samuel.thibault@ens-lyon.org>
>>
>> diff --git a/extras/mini-os/arch/ia64/iorw.c b/extras/mini-os/arch/ia6=
4/iorw.c
> Is there any reason to have the ia64 stuff? ia64 isn't supported in
> Xen anymore, AFAIK.
Maybe not. But until ia64 support is removed from mini-os the function
bodies should exist so stuff will compile.
>  -George
>
>> new file mode 100644
>> index 0000000..aa58807
>> --- /dev/null
>> +++ b/extras/mini-os/arch/ia64/iorw.c
>> @@ -0,0 +1,48 @@
>> +#include <mini-os/iorw.h>
>> +#include <mini-os/console.h>
>> +
>> +void iowrite8(volatile void* addr, uint8_t val)
>> +{
>> +   printk("iorw not implemented!!\n");
>> +   BUG();
>> +}
>> +void iowrite16(volatile void* addr, uint16_t val)
>> +{
>> +   printk("iorw not implemented!!\n");
>> +   BUG();
>> +}
>> +void iowrite32(volatile void* addr, uint32_t val)
>> +{
>> +   printk("iorw not implemented!!\n");
>> +   BUG();
>> +}
>> +void iowrite64(volatile void* addr, uint64_t val)
>> +{
>> +   printk("iorw not implemented!!\n");
>> +   BUG();
>> +}
>> +
>> +uint8_t ioread8(volatile void* addr)
>> +{
>> +   printk("iorw not implemented!!\n");
>> +   BUG();
>> +   return 0;
>> +}
>> +uint16_t ioread16(volatile void* addr)
>> +{
>> +   printk("iorw not implemented!!\n");
>> +   BUG();
>> +   return 0;
>> +}
>> +uint32_t ioread32(volatile void* addr)
>> +{
>> +   printk("iorw not implemented!!\n");
>> +   BUG();
>> +   return 0;
>> +}
>> +uint64_t ioread64(volatile void* addr)
>> +{
>> +   printk("iorw not implemented!!\n");
>> +   BUG();
>> +   return 0;
>> +}
>> diff --git a/extras/mini-os/arch/x86/iorw.c b/extras/mini-os/arch/x86/=
iorw.c
>> new file mode 100644
>> index 0000000..3080769
>> --- /dev/null
>> +++ b/extras/mini-os/arch/x86/iorw.c
>> @@ -0,0 +1,35 @@
>> +#include <mini-os/iorw.h>
>> +
>> +void iowrite8(volatile void* addr, uint8_t val)
>> +{
>> +   *((volatile uint8_t*)addr) =3D val;
>> +}
>> +void iowrite16(volatile void* addr, uint16_t val)
>> +{
>> +   *((volatile uint16_t*)addr) =3D val;
>> +}
>> +void iowrite32(volatile void* addr, uint32_t val)
>> +{
>> +   *((volatile uint32_t*)addr) =3D val;
>> +}
>> +void iowrite64(volatile void* addr, uint64_t val)
>> +{
>> +   *((volatile uint64_t*)addr) =3D val;
>> +}
>> +
>> +uint8_t ioread8(volatile void* addr)
>> +{
>> +   return *((volatile uint8_t*) addr);
>> +}
>> +uint16_t ioread16(volatile void* addr)
>> +{
>> +   return *((volatile uint16_t*) addr);
>> +}
>> +uint32_t ioread32(volatile void* addr)
>> +{
>> +   return *((volatile uint32_t*) addr);
>> +}
>> +uint64_t ioread64(volatile void* addr)
>> +{
>> +   return *((volatile uint64_t*) addr);
>> +}
>> diff --git a/extras/mini-os/include/iorw.h b/extras/mini-os/include/io=
rw.h
>> new file mode 100644
>> index 0000000..d5ec065
>> --- /dev/null
>> +++ b/extras/mini-os/include/iorw.h
>> @@ -0,0 +1,16 @@
>> +#ifndef MINIOS_IORW_H
>> +#define MINIOS_IORW_H
>> +
>> +#include <mini-os/types.h>
>> +
>> +void iowrite8(volatile void* addr, uint8_t val);
>> +void iowrite16(volatile void* addr, uint16_t val);
>> +void iowrite32(volatile void* addr, uint32_t val);
>> +void iowrite64(volatile void* addr, uint64_t val);
>> +
>> +uint8_t ioread8(volatile void* addr);
>> +uint16_t ioread16(volatile void* addr);
>> +uint32_t ioread32(volatile void* addr);
>> +uint64_t ioread64(volatile void* addr);
>> +
>> +#endif
>> --
>> 1.7.9.5
>>
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xen.org
>> http://lists.xen.org/xen-devel



--------------ms030803060304020706070800
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIDyjCC
A8YwggMvoAMCAQICBD/xyf0wDQYJKoZIhvcNAQEFBQAwLzELMAkGA1UEBhMCVVMxDzANBgNV
BAoTBkpIVUFQTDEPMA0GA1UECxMGQklTRENBMB4XDTEwMDYxMTE4MjIwNloXDTEzMDYxMTE4
NTIwNlowZjELMAkGA1UEBhMCVVMxDzANBgNVBAoTBkpIVUFQTDEPMA0GA1UECxMGUGVvcGxl
MTUwFgYDVQQLEw9WUE5Hcm91cC1CSVNEQ0EwGwYDVQQDExRNYXR0aGV3IEUgRmlvcmF2YW50
ZTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAnpbwVSP6o1Nb5lcW7dd3yTo9iBJdi7qz
4nANOMFPK7JOy5npKN1iiousl28U/scUJES55gPwAWYJK3uVyQAsA4adgDKi5DoD1UHDQEwp
bY7iHLJeq0NPr4BqYNqnCFPbE6HC8zSJrr4qKn+gVUQT39SIFqdiIPJwZL8FYTRQ/zsCAwEA
AaOCAbYwggGyMAsGA1UdDwQEAwIHgDArBgNVHRAEJDAigA8yMDEwMDYxMTE4MjIwNlqBDzIw
MTIwNzE3MjI1MjA2WjAbBg0rBgEEAbMlCwMBAQEBBAoWCGZpb3JhbWUxMBsGDSsGAQQBsyUL
AwEBAQIEChIIMDAxMDQyNjEwWAYJYIZIAYb6ax4BBEsMSVRoZSBwcml2YXRlIGtleSBjb3Jy
ZXNwb25kaW5nIHRvIHRoaXMgY2VydGlmaWNhdGUgbWF5IGhhdmUgYmVlbiBleHBvcnRlZC4w
KAYDVR0RBCEwH4EdTWF0dGhldy5GaW9yYXZhbnRlQGpodWFwbC5lZHUwUgYDVR0fBEswSTBH
oEWgQ6RBMD8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJU0RD
QTEOMAwGA1UEAxMFQ1JMNTYwHwYDVR0jBBgwFoAUCDUpmxH52EU2CyWmF2EJMB1yqeswHQYD
VR0OBBYEFO6LYxg6r9wHZ+zdQtBHn1dZ/YTNMAkGA1UdEwQCMAAwGQYJKoZIhvZ9B0EABAww
ChsEVjcuMQMCBLAwDQYJKoZIhvcNAQEFBQADgYEAJO9HQh4YNChVLzuZqK5ARJARD8JoujGZ
fdo75quvg2jXFQe2sEjvLnxJZgm/pv8fdZakq48CWwjYHKuvIp7sDjTEsQfo+y7SpN/N2NvJ
WU5SqfK1VgYtNLRRoGJUB5Q1aZ+Dg95g3kqpyfpUMISJL8IKVLtJVfN4fggFVUYZ9wwxggGr
MIIBpwIBATA3MC8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJ
U0RDQQIEP/HJ/TAJBgUrDgMCGgUAoIHLMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ
KoZIhvcNAQkFMQ8XDTEyMDkyODEzNTcxMVowIwYJKoZIhvcNAQkEMRYEFF96nPMuUFb14Lsl
+TyU1h/JFPhtMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAK
BggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI
KoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEgYCC9FXWiWEvkDeDR6cE8YGCnIeksLL8NUKb
Yly4fhEnv11F/j3+eMriZAkA2nvRMmZ+2ZwKK1sDtshw5s+CV0vxyCpiDPA8BtHzRKQgz99d
bcSpHTj94eA1IYn+4eCJfIi+wsAY3lEBPU0THwrpW91Gyn6CPxnpltYOrRDYBIJcMQAAAAAA
AA==
--------------ms030803060304020706070800--


--===============6042815001863481987==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============6042815001863481987==--


From xen-devel-bounces@lists.xen.org Fri Sep 28 14:01:45 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Sep 2012 14: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 1THb8B-0005gq-2G; Fri, 28 Sep 2012 14:01:27 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <matthew.fioravante@jhuapl.edu>) id 1THb89-0005gi-Dd
	for xen-devel@lists.xen.org; Fri, 28 Sep 2012 14:01:25 +0000
Received: from [85.158.143.35:49545] by server-3.bemta-4.messagelabs.com id
	BB/FC-10986-4BDA5605; Fri, 28 Sep 2012 14:01:24 +0000
X-Env-Sender: matthew.fioravante@jhuapl.edu
X-Msg-Ref: server-2.tower-21.messagelabs.com!1348840877!9277912!1
X-Originating-IP: [128.244.251.36]
X-SpamReason: No, hits=0.0 required=7.0 tests=UNPARSEABLE_RELAY
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7578 invoked from network); 28 Sep 2012 14:01:18 -0000
Received: from pilot.jhuapl.edu (HELO jhuapl.edu) (128.244.251.36)
	by server-2.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 28 Sep 2012 14:01:18 -0000
Received: from ([128.244.207.89])
	by pilot.jhuapl.edu with ESMTP with TLS id 63GHCH1.153871004;
	Fri, 28 Sep 2012 10:00:57 -0400
Message-ID: <5065AD49.7040101@jhuapl.edu>
Date: Fri, 28 Sep 2012 09:59:37 -0400
From: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120827 Thunderbird/15.0
MIME-Version: 1.0
To: George Dunlap <George.Dunlap@eu.citrix.com>
References: <1348765802-11314-1-git-send-email-matthew.fioravante@jhuapl.edu>
	<1348765802-11314-5-git-send-email-matthew.fioravante@jhuapl.edu>
	<CAFLBxZbND=Uer5JuwA3aaz4KSPahLDPeeBkDCCkOo7M84q7OAA@mail.gmail.com>
In-Reply-To: <CAFLBxZbND=Uer5JuwA3aaz4KSPahLDPeeBkDCCkOo7M84q7OAA@mail.gmail.com>
X-Enigmail-Version: 1.4.4
Cc: "samuel.thibault@ens-lyon.org" <samuel.thibault@ens-lyon.org>,
	"Ian.Campbell@citrix.com" <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 05/11] add CONFIG_XC conditional
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============8001752028130860862=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a cryptographically signed message in MIME format.

--===============8001752028130860862==
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms080606040504060300050006"

This is a cryptographically signed message in MIME format.

--------------ms080606040504060300050006
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On 09/28/2012 07:18 AM, George Dunlap wrote:
> On Thu, Sep 27, 2012 at 6:09 PM, Matthew Fioravante
> <matthew.fioravante@jhuapl.edu> wrote:
>> This patch adds a CONFIG_XC option to mini-os, to allow conditional
>> support for libxc for mini-os domains.
>>
>> Signed-off-by: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
>> Acked-by: Samuel Thibault <samuel.thibault@ens-lyon.org>
> Hmm... Samuel said, "Apart from that, Acked-by:", but you didn't
> address the "that" that he mentioned.  In that circumstance, I don't
> think addding the "Acked-by" to the commit message is really
> appropriate -- it implies that the patch was approved as-is, when in
> fact he was only saying that he agreed that these changes were all
> right, but that perhaps there needed to be more.
>
> Can you address his question?
I'll look into it. I assumed Acked-by in the message meant it was
officially acked. Sorry about that.
>  -George
>
>> diff --git a/extras/mini-os/Makefile b/extras/mini-os/Makefile
>> index c425f76..b4236e8 100644
>> --- a/extras/mini-os/Makefile
>> +++ b/extras/mini-os/Makefile
>> @@ -27,6 +27,7 @@ CONFIG_FBFRONT ?=3D y
>>  CONFIG_KBDFRONT ?=3D y
>>  CONFIG_CONSFRONT ?=3D y
>>  CONFIG_XENBUS ?=3D y
>> +CONFIG_XC ?=3Dy
>>  CONFIG_LWIP ?=3D $(lwip)
>>
>>  # Export config items as compiler directives
>> diff --git a/extras/mini-os/lib/sys.c b/extras/mini-os/lib/sys.c
>> index 7ddbbf8..6cb97b1 100644
>> --- a/extras/mini-os/lib/sys.c
>> +++ b/extras/mini-os/lib/sys.c
>> @@ -397,6 +397,7 @@ int close(int fd)
>>             return res;
>>         }
>>  #endif
>> +#ifdef CONFIG_XC
>>         case FTYPE_XC:
>>             minios_interface_close_fd(fd);
>>             return 0;
>> @@ -406,6 +407,7 @@ int close(int fd)
>>         case FTYPE_GNTMAP:
>>             minios_gnttab_close_fd(fd);
>>             return 0;
>> +#endif
>>  #ifdef CONFIG_NETFRONT
>>         case FTYPE_TAP:
>>             shutdown_netfront(files[fd].tap.dev);
>> @@ -1195,10 +1197,13 @@ void *mmap(void *start, size_t length, int pro=
t, int flags, int fd, off_t offset
>>
>>      if (fd =3D=3D -1)
>>          return map_zero(n, 1);
>> +#ifdef CONFIG_XC
>>      else if (files[fd].type =3D=3D FTYPE_XC) {
>>          unsigned long zero =3D 0;
>>          return map_frames_ex(&zero, n, 0, 0, 1, DOMID_SELF, NULL, 0);=

>> -    } else if (files[fd].type =3D=3D FTYPE_MEM) {
>> +    }
>> +#endif
>> +    else if (files[fd].type =3D=3D FTYPE_MEM) {
>>          unsigned long first_mfn =3D offset >> PAGE_SHIFT;
>>          return map_frames_ex(&first_mfn, n, 0, 1, 1, DOMID_IO, NULL, =
_PAGE_PRESENT|_PAGE_RW);
>>      } else ASSERT(0);
>> --
>> 1.7.9.5
>>
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xen.org
>> http://lists.xen.org/xen-devel



--------------ms080606040504060300050006
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIDyjCC
A8YwggMvoAMCAQICBD/xyf0wDQYJKoZIhvcNAQEFBQAwLzELMAkGA1UEBhMCVVMxDzANBgNV
BAoTBkpIVUFQTDEPMA0GA1UECxMGQklTRENBMB4XDTEwMDYxMTE4MjIwNloXDTEzMDYxMTE4
NTIwNlowZjELMAkGA1UEBhMCVVMxDzANBgNVBAoTBkpIVUFQTDEPMA0GA1UECxMGUGVvcGxl
MTUwFgYDVQQLEw9WUE5Hcm91cC1CSVNEQ0EwGwYDVQQDExRNYXR0aGV3IEUgRmlvcmF2YW50
ZTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAnpbwVSP6o1Nb5lcW7dd3yTo9iBJdi7qz
4nANOMFPK7JOy5npKN1iiousl28U/scUJES55gPwAWYJK3uVyQAsA4adgDKi5DoD1UHDQEwp
bY7iHLJeq0NPr4BqYNqnCFPbE6HC8zSJrr4qKn+gVUQT39SIFqdiIPJwZL8FYTRQ/zsCAwEA
AaOCAbYwggGyMAsGA1UdDwQEAwIHgDArBgNVHRAEJDAigA8yMDEwMDYxMTE4MjIwNlqBDzIw
MTIwNzE3MjI1MjA2WjAbBg0rBgEEAbMlCwMBAQEBBAoWCGZpb3JhbWUxMBsGDSsGAQQBsyUL
AwEBAQIEChIIMDAxMDQyNjEwWAYJYIZIAYb6ax4BBEsMSVRoZSBwcml2YXRlIGtleSBjb3Jy
ZXNwb25kaW5nIHRvIHRoaXMgY2VydGlmaWNhdGUgbWF5IGhhdmUgYmVlbiBleHBvcnRlZC4w
KAYDVR0RBCEwH4EdTWF0dGhldy5GaW9yYXZhbnRlQGpodWFwbC5lZHUwUgYDVR0fBEswSTBH
oEWgQ6RBMD8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJU0RD
QTEOMAwGA1UEAxMFQ1JMNTYwHwYDVR0jBBgwFoAUCDUpmxH52EU2CyWmF2EJMB1yqeswHQYD
VR0OBBYEFO6LYxg6r9wHZ+zdQtBHn1dZ/YTNMAkGA1UdEwQCMAAwGQYJKoZIhvZ9B0EABAww
ChsEVjcuMQMCBLAwDQYJKoZIhvcNAQEFBQADgYEAJO9HQh4YNChVLzuZqK5ARJARD8JoujGZ
fdo75quvg2jXFQe2sEjvLnxJZgm/pv8fdZakq48CWwjYHKuvIp7sDjTEsQfo+y7SpN/N2NvJ
WU5SqfK1VgYtNLRRoGJUB5Q1aZ+Dg95g3kqpyfpUMISJL8IKVLtJVfN4fggFVUYZ9wwxggGr
MIIBpwIBATA3MC8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJ
U0RDQQIEP/HJ/TAJBgUrDgMCGgUAoIHLMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ
KoZIhvcNAQkFMQ8XDTEyMDkyODEzNTkzN1owIwYJKoZIhvcNAQkEMRYEFN1gF7m3AmBBp0yr
+M10EFo9Oy5RMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAK
BggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI
KoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEgYBOVd7hqhBWY+RvcDj5bm8NgYfbJQlkwwQ8
re8mg1Tn6CWoRRm4D6yCwVNsCLav6BaDV6B9kn2VNxXCKE0++mcs2JYnqcwK5i//ocr+8fAh
jr9b5l3i4DDlgkIlWN0hd0BfsT3/ibc4hxZLhqVLoWZK3xWvi61Yx9XyJJDnIZW+cQAAAAAA
AA==
--------------ms080606040504060300050006--


--===============8001752028130860862==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============8001752028130860862==--


From xen-devel-bounces@lists.xen.org Fri Sep 28 14:01:45 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Sep 2012 14: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 1THb8B-0005gq-2G; Fri, 28 Sep 2012 14:01:27 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <matthew.fioravante@jhuapl.edu>) id 1THb89-0005gi-Dd
	for xen-devel@lists.xen.org; Fri, 28 Sep 2012 14:01:25 +0000
Received: from [85.158.143.35:49545] by server-3.bemta-4.messagelabs.com id
	BB/FC-10986-4BDA5605; Fri, 28 Sep 2012 14:01:24 +0000
X-Env-Sender: matthew.fioravante@jhuapl.edu
X-Msg-Ref: server-2.tower-21.messagelabs.com!1348840877!9277912!1
X-Originating-IP: [128.244.251.36]
X-SpamReason: No, hits=0.0 required=7.0 tests=UNPARSEABLE_RELAY
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7578 invoked from network); 28 Sep 2012 14:01:18 -0000
Received: from pilot.jhuapl.edu (HELO jhuapl.edu) (128.244.251.36)
	by server-2.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 28 Sep 2012 14:01:18 -0000
Received: from ([128.244.207.89])
	by pilot.jhuapl.edu with ESMTP with TLS id 63GHCH1.153871004;
	Fri, 28 Sep 2012 10:00:57 -0400
Message-ID: <5065AD49.7040101@jhuapl.edu>
Date: Fri, 28 Sep 2012 09:59:37 -0400
From: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120827 Thunderbird/15.0
MIME-Version: 1.0
To: George Dunlap <George.Dunlap@eu.citrix.com>
References: <1348765802-11314-1-git-send-email-matthew.fioravante@jhuapl.edu>
	<1348765802-11314-5-git-send-email-matthew.fioravante@jhuapl.edu>
	<CAFLBxZbND=Uer5JuwA3aaz4KSPahLDPeeBkDCCkOo7M84q7OAA@mail.gmail.com>
In-Reply-To: <CAFLBxZbND=Uer5JuwA3aaz4KSPahLDPeeBkDCCkOo7M84q7OAA@mail.gmail.com>
X-Enigmail-Version: 1.4.4
Cc: "samuel.thibault@ens-lyon.org" <samuel.thibault@ens-lyon.org>,
	"Ian.Campbell@citrix.com" <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 05/11] add CONFIG_XC conditional
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============8001752028130860862=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a cryptographically signed message in MIME format.

--===============8001752028130860862==
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms080606040504060300050006"

This is a cryptographically signed message in MIME format.

--------------ms080606040504060300050006
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On 09/28/2012 07:18 AM, George Dunlap wrote:
> On Thu, Sep 27, 2012 at 6:09 PM, Matthew Fioravante
> <matthew.fioravante@jhuapl.edu> wrote:
>> This patch adds a CONFIG_XC option to mini-os, to allow conditional
>> support for libxc for mini-os domains.
>>
>> Signed-off-by: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
>> Acked-by: Samuel Thibault <samuel.thibault@ens-lyon.org>
> Hmm... Samuel said, "Apart from that, Acked-by:", but you didn't
> address the "that" that he mentioned.  In that circumstance, I don't
> think addding the "Acked-by" to the commit message is really
> appropriate -- it implies that the patch was approved as-is, when in
> fact he was only saying that he agreed that these changes were all
> right, but that perhaps there needed to be more.
>
> Can you address his question?
I'll look into it. I assumed Acked-by in the message meant it was
officially acked. Sorry about that.
>  -George
>
>> diff --git a/extras/mini-os/Makefile b/extras/mini-os/Makefile
>> index c425f76..b4236e8 100644
>> --- a/extras/mini-os/Makefile
>> +++ b/extras/mini-os/Makefile
>> @@ -27,6 +27,7 @@ CONFIG_FBFRONT ?=3D y
>>  CONFIG_KBDFRONT ?=3D y
>>  CONFIG_CONSFRONT ?=3D y
>>  CONFIG_XENBUS ?=3D y
>> +CONFIG_XC ?=3Dy
>>  CONFIG_LWIP ?=3D $(lwip)
>>
>>  # Export config items as compiler directives
>> diff --git a/extras/mini-os/lib/sys.c b/extras/mini-os/lib/sys.c
>> index 7ddbbf8..6cb97b1 100644
>> --- a/extras/mini-os/lib/sys.c
>> +++ b/extras/mini-os/lib/sys.c
>> @@ -397,6 +397,7 @@ int close(int fd)
>>             return res;
>>         }
>>  #endif
>> +#ifdef CONFIG_XC
>>         case FTYPE_XC:
>>             minios_interface_close_fd(fd);
>>             return 0;
>> @@ -406,6 +407,7 @@ int close(int fd)
>>         case FTYPE_GNTMAP:
>>             minios_gnttab_close_fd(fd);
>>             return 0;
>> +#endif
>>  #ifdef CONFIG_NETFRONT
>>         case FTYPE_TAP:
>>             shutdown_netfront(files[fd].tap.dev);
>> @@ -1195,10 +1197,13 @@ void *mmap(void *start, size_t length, int pro=
t, int flags, int fd, off_t offset
>>
>>      if (fd =3D=3D -1)
>>          return map_zero(n, 1);
>> +#ifdef CONFIG_XC
>>      else if (files[fd].type =3D=3D FTYPE_XC) {
>>          unsigned long zero =3D 0;
>>          return map_frames_ex(&zero, n, 0, 0, 1, DOMID_SELF, NULL, 0);=

>> -    } else if (files[fd].type =3D=3D FTYPE_MEM) {
>> +    }
>> +#endif
>> +    else if (files[fd].type =3D=3D FTYPE_MEM) {
>>          unsigned long first_mfn =3D offset >> PAGE_SHIFT;
>>          return map_frames_ex(&first_mfn, n, 0, 1, 1, DOMID_IO, NULL, =
_PAGE_PRESENT|_PAGE_RW);
>>      } else ASSERT(0);
>> --
>> 1.7.9.5
>>
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xen.org
>> http://lists.xen.org/xen-devel



--------------ms080606040504060300050006
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIDyjCC
A8YwggMvoAMCAQICBD/xyf0wDQYJKoZIhvcNAQEFBQAwLzELMAkGA1UEBhMCVVMxDzANBgNV
BAoTBkpIVUFQTDEPMA0GA1UECxMGQklTRENBMB4XDTEwMDYxMTE4MjIwNloXDTEzMDYxMTE4
NTIwNlowZjELMAkGA1UEBhMCVVMxDzANBgNVBAoTBkpIVUFQTDEPMA0GA1UECxMGUGVvcGxl
MTUwFgYDVQQLEw9WUE5Hcm91cC1CSVNEQ0EwGwYDVQQDExRNYXR0aGV3IEUgRmlvcmF2YW50
ZTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAnpbwVSP6o1Nb5lcW7dd3yTo9iBJdi7qz
4nANOMFPK7JOy5npKN1iiousl28U/scUJES55gPwAWYJK3uVyQAsA4adgDKi5DoD1UHDQEwp
bY7iHLJeq0NPr4BqYNqnCFPbE6HC8zSJrr4qKn+gVUQT39SIFqdiIPJwZL8FYTRQ/zsCAwEA
AaOCAbYwggGyMAsGA1UdDwQEAwIHgDArBgNVHRAEJDAigA8yMDEwMDYxMTE4MjIwNlqBDzIw
MTIwNzE3MjI1MjA2WjAbBg0rBgEEAbMlCwMBAQEBBAoWCGZpb3JhbWUxMBsGDSsGAQQBsyUL
AwEBAQIEChIIMDAxMDQyNjEwWAYJYIZIAYb6ax4BBEsMSVRoZSBwcml2YXRlIGtleSBjb3Jy
ZXNwb25kaW5nIHRvIHRoaXMgY2VydGlmaWNhdGUgbWF5IGhhdmUgYmVlbiBleHBvcnRlZC4w
KAYDVR0RBCEwH4EdTWF0dGhldy5GaW9yYXZhbnRlQGpodWFwbC5lZHUwUgYDVR0fBEswSTBH
oEWgQ6RBMD8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJU0RD
QTEOMAwGA1UEAxMFQ1JMNTYwHwYDVR0jBBgwFoAUCDUpmxH52EU2CyWmF2EJMB1yqeswHQYD
VR0OBBYEFO6LYxg6r9wHZ+zdQtBHn1dZ/YTNMAkGA1UdEwQCMAAwGQYJKoZIhvZ9B0EABAww
ChsEVjcuMQMCBLAwDQYJKoZIhvcNAQEFBQADgYEAJO9HQh4YNChVLzuZqK5ARJARD8JoujGZ
fdo75quvg2jXFQe2sEjvLnxJZgm/pv8fdZakq48CWwjYHKuvIp7sDjTEsQfo+y7SpN/N2NvJ
WU5SqfK1VgYtNLRRoGJUB5Q1aZ+Dg95g3kqpyfpUMISJL8IKVLtJVfN4fggFVUYZ9wwxggGr
MIIBpwIBATA3MC8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJ
U0RDQQIEP/HJ/TAJBgUrDgMCGgUAoIHLMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ
KoZIhvcNAQkFMQ8XDTEyMDkyODEzNTkzN1owIwYJKoZIhvcNAQkEMRYEFN1gF7m3AmBBp0yr
+M10EFo9Oy5RMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAK
BggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI
KoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEgYBOVd7hqhBWY+RvcDj5bm8NgYfbJQlkwwQ8
re8mg1Tn6CWoRRm4D6yCwVNsCLav6BaDV6B9kn2VNxXCKE0++mcs2JYnqcwK5i//ocr+8fAh
jr9b5l3i4DDlgkIlWN0hd0BfsT3/ibc4hxZLhqVLoWZK3xWvi61Yx9XyJJDnIZW+cQAAAAAA
AA==
--------------ms080606040504060300050006--


--===============8001752028130860862==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============8001752028130860862==--


From xen-devel-bounces@lists.xen.org Fri Sep 28 14:03:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Sep 2012 14:03:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1THb9Z-0005ni-IE; Fri, 28 Sep 2012 14:02:53 +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 1THb9Y-0005nX-52
	for xen-devel@lists.xen.org; Fri, 28 Sep 2012 14:02:52 +0000
Received: from [85.158.139.83:12795] by server-8.bemta-5.messagelabs.com id
	7F/87-18073-B0EA5605; Fri, 28 Sep 2012 14:02:51 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1348840969!25229205!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzcxNjk5\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24537 invoked from network); 28 Sep 2012 14:02:50 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-16.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 28 Sep 2012 14:02:50 -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 q8SE2eZj014155
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 28 Sep 2012 14:02:41 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q8SE2dOX012966
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 28 Sep 2012 14:02:40 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
	q8SE2d0U017495; Fri, 28 Sep 2012 09:02:39 -0500
Received: from localhost.localdomain (/10.154.179.198)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 28 Sep 2012 07:02:38 -0700
Date: Fri, 28 Sep 2012 10:01:10 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Zhenzhong Duan <zhenzhong.duan@oracle.com>, ian.jackson@eu.citrix.com
Message-ID: <20120928140109.GA7483@localhost.localdomain>
References: <505C3647.1030003@oracle.com>
	<20120921143430.GA3522@phenom.dumpdata.com>
	<5062C16A.1020306@oracle.com>
	<20120926123534.GF7356@phenom.dumpdata.com>
	<5063EAFB.1070307@oracle.com>
	<20120927115918.GE8832@phenom.dumpdata.com>
	<50657D4B.9040303@oracle.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <50657D4B.9040303@oracle.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: Konrad Rzeszutek Wilk <konrad@kernel.org>,
	Dan Magenheimer <dan.magenheimer@oracle.com>,
	Feng Jin <joe.jin@oracle.com>, xen-devel <xen-devel@lists.xen.org>
Subject: [Xen-devel] Is: Contention in block script when doing guest saving.
 Was:Re: an issue with 'xm save'
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Sep 28, 2012 at 06:34:51PM +0800, Zhenzhong Duan wrote:
> On 2012-09-27 19:59, Konrad Rzeszutek Wilk wrote:
> >On Thu, Sep 27, 2012 at 01:58:19PM +0800, Zhenzhong Duan wrote:
> >>
> >>On 2012-09-26 20:35, Konrad Rzeszutek Wilk wrote:
> >>>On Wed, Sep 26, 2012 at 04:48:42PM +0800, Zhenzhong Duan wrote:
> >>>>Konrad Rzeszutek Wilk wrote:
> >>>>>On Fri, Sep 21, 2012 at 05:41:27PM +0800, Zhenzhong Duan wrote:
> >>>>>>Hi maintainers,
> >>>>>>
> >>>>>>I found there is an issue when 'xm save' a pvm guest. See below:
> >>>>>>
> >>>>>>When I do save then restore once, CPU(%) in xentop showed around 99%.
> >>>>>>When I do that second time, CPU(%) showed 199%
> >>>>>>
> >>>>>>top in dom0 showed:
> >>>>>>     PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
> >>>>>>    20946 root      18  -2 10984 1284  964 S 19.8  0.3   0:48.93 block
> >>>>>>    4939 root      18  -2 10984 1288  964 S 19.5  0.3   1:34.68 block
> >>>>>>
> >>>>>>I could kill the block process, then all look normal again.
> >>>>>What is the 'block' process? If you attach 'perf' to it do you get an idea
> >>>>>of what it is spinning at?
> >>>>It's /etc/xen/scripts/block
> >>>>I add 'set -x' to /etc/xen/scripts/block, found it blocked at claim_lock.
> >>>>When domU was created first time, claim_lock/release_lock finished quickly,
> >>>>when 'xm save' was called, claim_lock spin in its own while loop.
> >>>>I can ensure no other domU create/save/etc happen when I test.
> >>>OK, so how come you have two block processes? Is it b/c you have two
> >>>disks attached to the guest? The are multiple claim_lock in the shell
> >>>script - do you know where each of two threads are spinning? Are they
> >>>spinning on the same function?
> >>In above test, I run save/restore twice, so two block processes.
> >>In other test, run save/restore once, there is only one block process.
> >>After do 'xm save', I see block process spin at line 328:
> >>321   remove)
> >>322     case $t in
> >>323       phy)
> >>324         exit 0
> >>325         ;;
> >>326
> >>327       file)
> >>328         claim_lock "block"
> >>329         node=$(xenstore_read "$XENBUS_PATH/node")
> >>330         losetup -d "$node"
> >>331         release_lock "block"
> >>332         exit 0
> >>333         ;;
> >So with the patches in OVM - do they have this fixed? Can they be upstreamed
> >or are the dependent on some magic OVM sauce?
> After replace locking.sh with OVM's, it worked.
> But xen-tools evolved to use flock based locking currently. We can't
> revert back.
> It seems changeset 25595:497e2fe49455 bring the issue.
> Finally, I came with a small patch that workaround the issue.

Ian, any thoughts on how this can be fixed properly? The locking
is quite heavy and causes two scripts that do deal with blocks
to spin for a long time.

> 
> diff -r d364becfb083 tools/hotplug/Linux/locking.sh
> --- a/tools/hotplug/Linux/locking.sh    Thu Sep 20 13:31:19 2012 +0200
> +++ b/tools/hotplug/Linux/locking.sh    Fri Sep 28 18:27:31 2012 +0800
> @@ -66,6 +66,7 @@
>  release_lock()
>  {
>      _setlockfd $1
> +    flock -u $_lockfd
>      rm "$_lockfile"
>  }

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 28 14:03:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Sep 2012 14:03:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1THb9Z-0005ni-IE; Fri, 28 Sep 2012 14:02:53 +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 1THb9Y-0005nX-52
	for xen-devel@lists.xen.org; Fri, 28 Sep 2012 14:02:52 +0000
Received: from [85.158.139.83:12795] by server-8.bemta-5.messagelabs.com id
	7F/87-18073-B0EA5605; Fri, 28 Sep 2012 14:02:51 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1348840969!25229205!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzcxNjk5\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24537 invoked from network); 28 Sep 2012 14:02:50 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-16.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 28 Sep 2012 14:02:50 -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 q8SE2eZj014155
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 28 Sep 2012 14:02:41 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q8SE2dOX012966
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 28 Sep 2012 14:02:40 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
	q8SE2d0U017495; Fri, 28 Sep 2012 09:02:39 -0500
Received: from localhost.localdomain (/10.154.179.198)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 28 Sep 2012 07:02:38 -0700
Date: Fri, 28 Sep 2012 10:01:10 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Zhenzhong Duan <zhenzhong.duan@oracle.com>, ian.jackson@eu.citrix.com
Message-ID: <20120928140109.GA7483@localhost.localdomain>
References: <505C3647.1030003@oracle.com>
	<20120921143430.GA3522@phenom.dumpdata.com>
	<5062C16A.1020306@oracle.com>
	<20120926123534.GF7356@phenom.dumpdata.com>
	<5063EAFB.1070307@oracle.com>
	<20120927115918.GE8832@phenom.dumpdata.com>
	<50657D4B.9040303@oracle.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <50657D4B.9040303@oracle.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: Konrad Rzeszutek Wilk <konrad@kernel.org>,
	Dan Magenheimer <dan.magenheimer@oracle.com>,
	Feng Jin <joe.jin@oracle.com>, xen-devel <xen-devel@lists.xen.org>
Subject: [Xen-devel] Is: Contention in block script when doing guest saving.
 Was:Re: an issue with 'xm save'
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Sep 28, 2012 at 06:34:51PM +0800, Zhenzhong Duan wrote:
> On 2012-09-27 19:59, Konrad Rzeszutek Wilk wrote:
> >On Thu, Sep 27, 2012 at 01:58:19PM +0800, Zhenzhong Duan wrote:
> >>
> >>On 2012-09-26 20:35, Konrad Rzeszutek Wilk wrote:
> >>>On Wed, Sep 26, 2012 at 04:48:42PM +0800, Zhenzhong Duan wrote:
> >>>>Konrad Rzeszutek Wilk wrote:
> >>>>>On Fri, Sep 21, 2012 at 05:41:27PM +0800, Zhenzhong Duan wrote:
> >>>>>>Hi maintainers,
> >>>>>>
> >>>>>>I found there is an issue when 'xm save' a pvm guest. See below:
> >>>>>>
> >>>>>>When I do save then restore once, CPU(%) in xentop showed around 99%.
> >>>>>>When I do that second time, CPU(%) showed 199%
> >>>>>>
> >>>>>>top in dom0 showed:
> >>>>>>     PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
> >>>>>>    20946 root      18  -2 10984 1284  964 S 19.8  0.3   0:48.93 block
> >>>>>>    4939 root      18  -2 10984 1288  964 S 19.5  0.3   1:34.68 block
> >>>>>>
> >>>>>>I could kill the block process, then all look normal again.
> >>>>>What is the 'block' process? If you attach 'perf' to it do you get an idea
> >>>>>of what it is spinning at?
> >>>>It's /etc/xen/scripts/block
> >>>>I add 'set -x' to /etc/xen/scripts/block, found it blocked at claim_lock.
> >>>>When domU was created first time, claim_lock/release_lock finished quickly,
> >>>>when 'xm save' was called, claim_lock spin in its own while loop.
> >>>>I can ensure no other domU create/save/etc happen when I test.
> >>>OK, so how come you have two block processes? Is it b/c you have two
> >>>disks attached to the guest? The are multiple claim_lock in the shell
> >>>script - do you know where each of two threads are spinning? Are they
> >>>spinning on the same function?
> >>In above test, I run save/restore twice, so two block processes.
> >>In other test, run save/restore once, there is only one block process.
> >>After do 'xm save', I see block process spin at line 328:
> >>321   remove)
> >>322     case $t in
> >>323       phy)
> >>324         exit 0
> >>325         ;;
> >>326
> >>327       file)
> >>328         claim_lock "block"
> >>329         node=$(xenstore_read "$XENBUS_PATH/node")
> >>330         losetup -d "$node"
> >>331         release_lock "block"
> >>332         exit 0
> >>333         ;;
> >So with the patches in OVM - do they have this fixed? Can they be upstreamed
> >or are the dependent on some magic OVM sauce?
> After replace locking.sh with OVM's, it worked.
> But xen-tools evolved to use flock based locking currently. We can't
> revert back.
> It seems changeset 25595:497e2fe49455 bring the issue.
> Finally, I came with a small patch that workaround the issue.

Ian, any thoughts on how this can be fixed properly? The locking
is quite heavy and causes two scripts that do deal with blocks
to spin for a long time.

> 
> diff -r d364becfb083 tools/hotplug/Linux/locking.sh
> --- a/tools/hotplug/Linux/locking.sh    Thu Sep 20 13:31:19 2012 +0200
> +++ b/tools/hotplug/Linux/locking.sh    Fri Sep 28 18:27:31 2012 +0800
> @@ -66,6 +66,7 @@
>  release_lock()
>  {
>      _setlockfd $1
> +    flock -u $_lockfd
>      rm "$_lockfile"
>  }

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 28 14:09:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Sep 2012 14:09:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1THbFG-00063Y-BL; Fri, 28 Sep 2012 14:08:46 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <linux@eikelenboom.it>) id 1THbFE-00063T-UP
	for xen-devel@lists.xen.org; Fri, 28 Sep 2012 14:08:45 +0000
Received: from [85.158.139.83:61771] by server-11.bemta-5.messagelabs.com id
	3C/5A-13866-C6FA5605; Fri, 28 Sep 2012 14:08:44 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-9.tower-182.messagelabs.com!1348841323!31903903!1
X-Originating-IP: [188.40.164.121]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14995 invoked from network); 28 Sep 2012 14:08:43 -0000
Received: from static.121.164.40.188.clients.your-server.de (HELO
	smtp.eikelenboom.it) (188.40.164.121)
	by server-9.tower-182.messagelabs.com with AES256-SHA encrypted SMTP;
	28 Sep 2012 14:08:43 -0000
Received: from 50-64-ftth.onsneteindhoven.nl ([88.159.64.50]:55041
	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 1THbG3-0004zG-9O; Fri, 28 Sep 2012 16:09:35 +0200
Date: Fri, 28 Sep 2012 16:08:36 +0200
From: Sander Eikelenboom <linux@eikelenboom.it>
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <388095299.20120928160836@eikelenboom.it>
To: "Jan Beulich" <JBeulich@suse.com>
In-Reply-To: <505AEB2D020000780009C81F@nat28.tlf.novell.com>
References: <7914B38A4445B34AA16EB9F1352942F1012F0F6F4B98@SJCPMAILBOX01.citrite.net>
	<CC681CDD.3D966%keir.xen@gmail.com>
	<40501859.20120902104331@eikelenboom.it>
	<5044849002000078000982EA@nat28.tlf.novell.com>
	<4610648186.20120904090841@eikelenboom.it>
	<5045CDF302000078000985FB@nat28.tlf.novell.com>
	<4710608674.20120904101330@eikelenboom.it>
	<505AEB2D020000780009C81F@nat28.tlf.novell.com>
MIME-Version: 1.0
Cc: Jeremy Fitzhardinge <jeremy@goop.org>, ehabkost@redhat.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	"wei.wang2@amd.com" <wei.wang2@amd.com>, Keir Fraser <keir.xen@gmail.com>,
	Santosh Jodh <Santosh.Jodh@citrix.com>
Subject: Re: [Xen-devel] Using debug-key 'o:  Dump IOMMU p2m table,
	locks up machine
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


Thursday, September 20, 2012, 10:08:45 AM, you wrote:

> Ping?

Perhaps changing the subject or starting a new thread altogether for this would provoke more reaction ?

>>>> On 04.09.12 at 11:26, Jan Beulich wrote:
>>>>> On 04.09.12 at 10:13, Sander Eikelenboom <linux@eikelenboom.it> wrote:
>> > Hmm don't know how to get the file/line, only thing i have found is:
>> > 
>> > serveerstertje:/boot# gdb xen-syms-4.2.0-rc4-pre
>> > GNU gdb (GDB) 7.0.1-debian
>> > Copyright (C) 2009 Free Software Foundation, Inc.
>> > License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
>> > This is free software: you are free to change and redistribute it.
>> > There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
>> > and "show warranty" for details.
>> > This GDB was configured as "x86_64-linux-gnu".
>> > For bug reporting instructions, please see:
>> > <http://www.gnu.org/software/gdb/bugs/>...
>> > Reading symbols from /boot/xen-syms-4.2.0-rc4-pre...done.
>> > (gdb) x/i 0xffff82c48015c9ee
>> > 0xffff82c48015c9ee <context_switch+916>:        mov    %edx,%gs
>> > (gdb)
>> 
>> I'm not really a gdb expert, so I don't know off the top of my
>> head either. I thought I said in a previous reply that people
>> generally appear to use the addr2line utility for that purpose.
>> 
>> But the disassembly already tells us where precisely the
>> problem is: The selector value (0x0063) attempted to be put
>> into %gs is apparently wrong in the context of the current
>> GDT. Now, that's GDT_ENTRY_TLS_MIN on the Linux side,
>> and ought to be valid. I'm surprised the guest (and the current
>> process in it) survives this (as the failure here results in a failsafe
>> callback into the guest).
>> 
>> Looking at the Linux side of things, this has been that way
>> forever, and I think has always been broken: On x86-64, it
>> should also clear %gs here (since 32-bit processes use it for
>> their TLS, and there's nothing wrong for a 64-bit process to put
>> something in there either), albeit not via loadsegment(), but
>> through xen_load_gs_index(). And I neither see why on 32-bit
>> it only clears %gs - %fs can as much hold a selector that might
>> get invalidated with the TLS descriptor updates. Eduardo,
>> Jeremy, Konrad?
>> 
>> Jan
>> 






_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 28 14:09:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Sep 2012 14:09:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1THbFG-00063Y-BL; Fri, 28 Sep 2012 14:08:46 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <linux@eikelenboom.it>) id 1THbFE-00063T-UP
	for xen-devel@lists.xen.org; Fri, 28 Sep 2012 14:08:45 +0000
Received: from [85.158.139.83:61771] by server-11.bemta-5.messagelabs.com id
	3C/5A-13866-C6FA5605; Fri, 28 Sep 2012 14:08:44 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-9.tower-182.messagelabs.com!1348841323!31903903!1
X-Originating-IP: [188.40.164.121]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14995 invoked from network); 28 Sep 2012 14:08:43 -0000
Received: from static.121.164.40.188.clients.your-server.de (HELO
	smtp.eikelenboom.it) (188.40.164.121)
	by server-9.tower-182.messagelabs.com with AES256-SHA encrypted SMTP;
	28 Sep 2012 14:08:43 -0000
Received: from 50-64-ftth.onsneteindhoven.nl ([88.159.64.50]:55041
	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 1THbG3-0004zG-9O; Fri, 28 Sep 2012 16:09:35 +0200
Date: Fri, 28 Sep 2012 16:08:36 +0200
From: Sander Eikelenboom <linux@eikelenboom.it>
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <388095299.20120928160836@eikelenboom.it>
To: "Jan Beulich" <JBeulich@suse.com>
In-Reply-To: <505AEB2D020000780009C81F@nat28.tlf.novell.com>
References: <7914B38A4445B34AA16EB9F1352942F1012F0F6F4B98@SJCPMAILBOX01.citrite.net>
	<CC681CDD.3D966%keir.xen@gmail.com>
	<40501859.20120902104331@eikelenboom.it>
	<5044849002000078000982EA@nat28.tlf.novell.com>
	<4610648186.20120904090841@eikelenboom.it>
	<5045CDF302000078000985FB@nat28.tlf.novell.com>
	<4710608674.20120904101330@eikelenboom.it>
	<505AEB2D020000780009C81F@nat28.tlf.novell.com>
MIME-Version: 1.0
Cc: Jeremy Fitzhardinge <jeremy@goop.org>, ehabkost@redhat.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	"wei.wang2@amd.com" <wei.wang2@amd.com>, Keir Fraser <keir.xen@gmail.com>,
	Santosh Jodh <Santosh.Jodh@citrix.com>
Subject: Re: [Xen-devel] Using debug-key 'o:  Dump IOMMU p2m table,
	locks up machine
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


Thursday, September 20, 2012, 10:08:45 AM, you wrote:

> Ping?

Perhaps changing the subject or starting a new thread altogether for this would provoke more reaction ?

>>>> On 04.09.12 at 11:26, Jan Beulich wrote:
>>>>> On 04.09.12 at 10:13, Sander Eikelenboom <linux@eikelenboom.it> wrote:
>> > Hmm don't know how to get the file/line, only thing i have found is:
>> > 
>> > serveerstertje:/boot# gdb xen-syms-4.2.0-rc4-pre
>> > GNU gdb (GDB) 7.0.1-debian
>> > Copyright (C) 2009 Free Software Foundation, Inc.
>> > License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
>> > This is free software: you are free to change and redistribute it.
>> > There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
>> > and "show warranty" for details.
>> > This GDB was configured as "x86_64-linux-gnu".
>> > For bug reporting instructions, please see:
>> > <http://www.gnu.org/software/gdb/bugs/>...
>> > Reading symbols from /boot/xen-syms-4.2.0-rc4-pre...done.
>> > (gdb) x/i 0xffff82c48015c9ee
>> > 0xffff82c48015c9ee <context_switch+916>:        mov    %edx,%gs
>> > (gdb)
>> 
>> I'm not really a gdb expert, so I don't know off the top of my
>> head either. I thought I said in a previous reply that people
>> generally appear to use the addr2line utility for that purpose.
>> 
>> But the disassembly already tells us where precisely the
>> problem is: The selector value (0x0063) attempted to be put
>> into %gs is apparently wrong in the context of the current
>> GDT. Now, that's GDT_ENTRY_TLS_MIN on the Linux side,
>> and ought to be valid. I'm surprised the guest (and the current
>> process in it) survives this (as the failure here results in a failsafe
>> callback into the guest).
>> 
>> Looking at the Linux side of things, this has been that way
>> forever, and I think has always been broken: On x86-64, it
>> should also clear %gs here (since 32-bit processes use it for
>> their TLS, and there's nothing wrong for a 64-bit process to put
>> something in there either), albeit not via loadsegment(), but
>> through xen_load_gs_index(). And I neither see why on 32-bit
>> it only clears %gs - %fs can as much hold a selector that might
>> get invalidated with the TLS descriptor updates. Eduardo,
>> Jeremy, Konrad?
>> 
>> Jan
>> 






_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 28 14:14:46 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Sep 2012 14:14:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1THbKl-0006CD-40; Fri, 28 Sep 2012 14:14: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 1THbKj-0006C8-UG
	for xen-devel@lists.xen.org; Fri, 28 Sep 2012 14:14:26 +0000
Received: from [85.158.143.35:54674] by server-2.bemta-4.messagelabs.com id
	C9/62-06610-1C0B5605; Fri, 28 Sep 2012 14:14:25 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1348841662!10899427!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTIyOTk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7503 invoked from network); 28 Sep 2012 14:14:23 -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;
	28 Sep 2012 14:14:23 -0000
X-IronPort-AV: E=Sophos;i="4.80,502,1344211200"; d="scan'208";a="14835091"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Sep 2012 14:14: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.279.1; Fri, 28 Sep 2012 15:14: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
	1THbKg-0001lQ-6D; Fri, 28 Sep 2012 14:14:22 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1THbKf-0001Zm-V1;
	Fri, 28 Sep 2012 15:14:22 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20581.45245.846208.289785@mariner.uk.xensource.com>
Date: Fri, 28 Sep 2012 15:14:21 +0100
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
In-Reply-To: <20120928140109.GA7483@localhost.localdomain>
References: <505C3647.1030003@oracle.com>
	<20120921143430.GA3522@phenom.dumpdata.com>
	<5062C16A.1020306@oracle.com>
	<20120926123534.GF7356@phenom.dumpdata.com>
	<5063EAFB.1070307@oracle.com>
	<20120927115918.GE8832@phenom.dumpdata.com>
	<50657D4B.9040303@oracle.com>
	<20120928140109.GA7483@localhost.localdomain>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Konrad Rzeszutek Wilk <konrad@kernel.org>,
	Dan Magenheimer <dan.magenheimer@oracle.com>,
	Feng Jin <joe.jin@oracle.com>, Zhenzhong Duan <zhenzhong.duan@oracle.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Is: Contention in block script when doing guest
 saving. Was:Re: an issue with 'xm save'
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Konrad Rzeszutek Wilk writes ("Is: Contention in block script when doing guest saving. Was:Re: [Xen-devel] an issue with 'xm save'"):
> On Fri, Sep 28, 2012 at 06:34:51PM +0800, Zhenzhong Duan wrote:
> > After replace locking.sh with OVM's, it worked.
> > But xen-tools evolved to use flock based locking currently. We can't
> > revert back.
> > It seems changeset 25595:497e2fe49455 bring the issue.
> > Finally, I came with a small patch that workaround the issue.
> 
> Ian, any thoughts on how this can be fixed properly? The locking
> is quite heavy and causes two scripts that do deal with blocks
> to spin for a long time.

The algorithm is not supposed to spin.  If it spins there is a bug, I
think.

Can you show me a transcript of the spinning happening with "set -x"
in force ?

> > diff -r d364becfb083 tools/hotplug/Linux/locking.sh
> > --- a/tools/hotplug/Linux/locking.sh    Thu Sep 20 13:31:19 2012 +0200
> > +++ b/tools/hotplug/Linux/locking.sh    Fri Sep 28 18:27:31 2012 +0800
> > @@ -66,6 +66,7 @@
> >  release_lock()
> >  {
> >      _setlockfd $1
> > +    flock -u $_lockfd
> >      rm "$_lockfile"

I'm not sure I understand how this would help.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 28 14:14:46 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Sep 2012 14:14:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1THbKl-0006CD-40; Fri, 28 Sep 2012 14:14: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 1THbKj-0006C8-UG
	for xen-devel@lists.xen.org; Fri, 28 Sep 2012 14:14:26 +0000
Received: from [85.158.143.35:54674] by server-2.bemta-4.messagelabs.com id
	C9/62-06610-1C0B5605; Fri, 28 Sep 2012 14:14:25 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1348841662!10899427!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTIyOTk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7503 invoked from network); 28 Sep 2012 14:14:23 -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;
	28 Sep 2012 14:14:23 -0000
X-IronPort-AV: E=Sophos;i="4.80,502,1344211200"; d="scan'208";a="14835091"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Sep 2012 14:14: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.279.1; Fri, 28 Sep 2012 15:14: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
	1THbKg-0001lQ-6D; Fri, 28 Sep 2012 14:14:22 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1THbKf-0001Zm-V1;
	Fri, 28 Sep 2012 15:14:22 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20581.45245.846208.289785@mariner.uk.xensource.com>
Date: Fri, 28 Sep 2012 15:14:21 +0100
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
In-Reply-To: <20120928140109.GA7483@localhost.localdomain>
References: <505C3647.1030003@oracle.com>
	<20120921143430.GA3522@phenom.dumpdata.com>
	<5062C16A.1020306@oracle.com>
	<20120926123534.GF7356@phenom.dumpdata.com>
	<5063EAFB.1070307@oracle.com>
	<20120927115918.GE8832@phenom.dumpdata.com>
	<50657D4B.9040303@oracle.com>
	<20120928140109.GA7483@localhost.localdomain>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Konrad Rzeszutek Wilk <konrad@kernel.org>,
	Dan Magenheimer <dan.magenheimer@oracle.com>,
	Feng Jin <joe.jin@oracle.com>, Zhenzhong Duan <zhenzhong.duan@oracle.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Is: Contention in block script when doing guest
 saving. Was:Re: an issue with 'xm save'
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Konrad Rzeszutek Wilk writes ("Is: Contention in block script when doing guest saving. Was:Re: [Xen-devel] an issue with 'xm save'"):
> On Fri, Sep 28, 2012 at 06:34:51PM +0800, Zhenzhong Duan wrote:
> > After replace locking.sh with OVM's, it worked.
> > But xen-tools evolved to use flock based locking currently. We can't
> > revert back.
> > It seems changeset 25595:497e2fe49455 bring the issue.
> > Finally, I came with a small patch that workaround the issue.
> 
> Ian, any thoughts on how this can be fixed properly? The locking
> is quite heavy and causes two scripts that do deal with blocks
> to spin for a long time.

The algorithm is not supposed to spin.  If it spins there is a bug, I
think.

Can you show me a transcript of the spinning happening with "set -x"
in force ?

> > diff -r d364becfb083 tools/hotplug/Linux/locking.sh
> > --- a/tools/hotplug/Linux/locking.sh    Thu Sep 20 13:31:19 2012 +0200
> > +++ b/tools/hotplug/Linux/locking.sh    Fri Sep 28 18:27:31 2012 +0800
> > @@ -66,6 +66,7 @@
> >  release_lock()
> >  {
> >      _setlockfd $1
> > +    flock -u $_lockfd
> >      rm "$_lockfile"

I'm not sure I understand how this would help.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 28 14:46:50 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Sep 2012 14: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 1THbpn-0006iI-KI; Fri, 28 Sep 2012 14:46:31 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <zhenzhong.duan@oracle.com>) id 1THbpl-0006iA-9s
	for xen-devel@lists.xen.org; Fri, 28 Sep 2012 14:46:29 +0000
Received: from [85.158.138.51:13339] by server-16.bemta-3.messagelabs.com id
	BC/B4-09129-448B5605; Fri, 28 Sep 2012 14:46:28 +0000
X-Env-Sender: zhenzhong.duan@oracle.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1348843582!32347870!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzcxNjk5\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16173 invoked from network); 28 Sep 2012 14:46:24 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-11.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 28 Sep 2012 14:46:24 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q8SEkEeg001376
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 28 Sep 2012 14:46:15 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
	q8SEkDsO026097
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 28 Sep 2012 14:46:14 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
	q8SEkD4M032319; Fri, 28 Sep 2012 09:46:13 -0500
Received: from [10.191.7.62] (/10.191.7.62)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 28 Sep 2012 07:46:11 -0700
Message-ID: <5065B82B.8080003@oracle.com>
Date: Fri, 28 Sep 2012 22:46:03 +0800
From: Zhenzhong Duan <zhenzhong.duan@oracle.com>
Organization: oracle
User-Agent: Mozilla/5.0 (Windows NT 5.1;
	rv:12.0) Gecko/20120428 Thunderbird/12.0.1
MIME-Version: 1.0
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
References: <505C3647.1030003@oracle.com>
	<20120921143430.GA3522@phenom.dumpdata.com>
	<5062C16A.1020306@oracle.com>
	<20120926123534.GF7356@phenom.dumpdata.com>
	<5063EAFB.1070307@oracle.com>
	<20120927115918.GE8832@phenom.dumpdata.com>
	<50657D4B.9040303@oracle.com>
	<20120928140109.GA7483@localhost.localdomain>
	<20581.45245.846208.289785@mariner.uk.xensource.com>
In-Reply-To: <20581.45245.846208.289785@mariner.uk.xensource.com>
Content-Type: multipart/mixed; boundary="------------090605080908040808080902"
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: Konrad Rzeszutek Wilk <konrad@kernel.org>,
	Dan Magenheimer <dan.magenheimer@oracle.com>,
	xen-devel <xen-devel@lists.xen.org>, Feng Jin <joe.jin@oracle.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] Is: Contention in block script when doing guest
 saving. Was:Re: an issue with 'xm save'
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: zhenzhong.duan@oracle.com
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a multi-part message in MIME format.
--------------090605080908040808080902
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

On 2012-09-28 22:14, Ian Jackson wrote:
> Konrad Rzeszutek Wilk writes ("Is: Contention in block script when doing guest saving. Was:Re: [Xen-devel] an issue with 'xm save'"):
>> On Fri, Sep 28, 2012 at 06:34:51PM +0800, Zhenzhong Duan wrote:
>>> After replace locking.sh with OVM's, it worked.
>>> But xen-tools evolved to use flock based locking currently. We can't
>>> revert back.
>>> It seems changeset 25595:497e2fe49455 bring the issue.
>>> Finally, I came with a small patch that workaround the issue.
>> Ian, any thoughts on how this can be fixed properly? The locking
>> is quite heavy and causes two scripts that do deal with blocks
>> to spin for a long time.
> The algorithm is not supposed to spin.  If it spins there is a bug, I
> think.
>
> Can you show me a transcript of the spinning happening with "set -x"
> in force ?
Hi Ian,
Attachment is part of xen-hotplug.log that will show the spin.
Original file is nearly 7G big. I fetch first 1000 lines.

Below is steps I did:
1. delete xen-hotplug.log
2. reboot dom0
3. add "set -x" to head of block script.
4.create first PV guest
5. save guest
6. get first 1000 lines from xen-hotplug.log

thanks
zduan

--------------090605080908040808080902
Content-Type: text/plain; charset=gb18030;
 name="xen-hotplug.log"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename="xen-hotplug.log"

[root@zhenzhong1 tmp]# head -n 1000 /var/log/xen/xen-hotplug.log
+++ export PATH=/usr/bin:/usr/sbin:/usr/lib/xen/bin:/usr/lib/xen/bin:/sbin:/bin:/usr/bin:/usr/sbin:/usr/local/bin:/bin:/usr/bin
+++ PATH=/usr/bin:/usr/sbin:/usr/lib/xen/bin:/usr/lib/xen/bin:/sbin:/bin:/usr/bin:/usr/sbin:/usr/local/bin:/bin:/usr/bin
+++ export LANG=POSIX
+++ LANG=POSIX
++++ set
++++ grep '^LC_'
++++ cut -d= -f1
+++ unset
+++ trap sigerr ERR
+++ log debug add XENBUS_PATH=backend/vbd/1/51712
+++ local level=debug
+++ shift
+++ logger -p daemon.debug -- /etc/xen/scripts/block: add XENBUS_PATH=backend/vbd/1/51712
++ findCommand add
++ for arg in '"$@"'
++ expr index add =
++ command=add
++ return
++ '[' add '!=' add ']'
++ XENBUS_PATH=backend/vbd/1/51712
++ xenstore_read_default backend/vbd/1/51712/type MISSING
++ xenstore-read backend/vbd/1/51712/type
+ t=file
+ case "$command" in
++ xenstore_read_default backend/vbd/1/51712/physical-device MISSING
++ xenstore-read backend/vbd/1/51712/physical-device
++ echo MISSING
+ phys=MISSING
+ '[' MISSING '!=' MISSING ']'
+ '[' -n file ']'
++ xenstore_read backend/vbd/1/51712/params
+++ xenstore-read backend/vbd/1/51712/params
++ local v=/mnt/sda6/OVM_OL5U7_X86_64_PVM_10GB/System.img
++ '[' /mnt/sda6/OVM_OL5U7_X86_64_PVM_10GB/System.img '!=' '' ']'
++ echo /mnt/sda6/OVM_OL5U7_X86_64_PVM_10GB/System.img
+ p=/mnt/sda6/OVM_OL5U7_X86_64_PVM_10GB/System.img
++ xenstore_read backend/vbd/1/51712/mode
+++ xenstore-read backend/vbd/1/51712/mode
++ local v=w
++ '[' w '!=' '' ']'
++ echo w
+ mode=w
++ xenstore_read backend/vbd/1/51712/frontend-id
+++ xenstore-read backend/vbd/1/51712/frontend-id
++ local v=1
++ '[' 1 '!=' '' ']'
++ echo 1
+ FRONTEND_ID=1
++ xenstore_read_default /local/domain/1/vm unknown
++ xenstore-read /local/domain/1/vm
+ FRONTEND_UUID=/vm/cc02077f-d327-cdf2-4876-91bb7ece8cc8
+ case $t in
++ readlink -f /mnt/sda6/OVM_OL5U7_X86_64_PVM_10GB/System.img
+ file=/mnt/sda6/OVM_OL5U7_X86_64_PVM_10GB/System.img
+ test -f /mnt/sda6/OVM_OL5U7_X86_64_PVM_10GB/System.img
++ canonicalise_mode w
++ local mode=w
++ expr index w w
++ expr index w '!'
++ echo w
+ mode=w
+ claim_lock block
+ mkdir -p /var/run/xen-hotplug
+ _setlockfd block
+ local i
+ (( i = 0 ))
+ (( i < 0 ))
+ _lockdict[$i]=block
+ let _lockfd=200+i
+ _lockfile=/var/run/xen-hotplug/block
+ local rightfile
+ true
+ eval 'exec 200>>/var/run/xen-hotplug/block'
++ exec
+ flock -x 200
++ perl -e '
            open STDIN, "<&200" or die $!;
            my $fd_inum = (stat STDIN)[1]; die $! unless defined $fd_inum;
            my $file_inum = (stat $ARGV[0])[1];
            print "y\n" if $fd_inum eq $file_inum;
                             ' /var/run/xen-hotplug/block
+ rightfile=y
+ '[' xy = xy ']'
+ break
++ xenstore_read_default backend/vbd/1/51712/state unknown
++ xenstore-read backend/vbd/1/51712/state
+ xenbus_state=2
+ '[' 2 '!=' 2 ']'
+ '[' w = w ']'
+ stat /mnt/sda6/OVM_OL5U7_X86_64_PVM_10GB/System.img -c %A
+ grep -q w
+ '[' xw '!=' 'x!' ']'
++ stat -c %i /mnt/sda6/OVM_OL5U7_X86_64_PVM_10GB/System.img
+ inode=835587
++ stat -c %D /mnt/sda6/OVM_OL5U7_X86_64_PVM_10GB/System.img
+ dev=806
+ '[' -z 835587 ']'
+ '[' -z 806 ']'
++ losetup -a
++ sed -n -e 's@^\([^:]\+\)\(:[[:blank:]]\[0*806\]:835587[[:blank:]](.*)\)@\1@p'
+ shared_list=
++ losetup -f
+ loopdev=/dev/loop0
+ '[' /dev/loop0 = '' ']'
+ LANG=C
+ losetup -h
+ grep read-only
+ roflag=-w
+ roflag=
+ roflag=
+ do_or_die losetup /dev/loop0 /mnt/sda6/OVM_OL5U7_X86_64_PVM_10GB/System.img
+ losetup /dev/loop0 /mnt/sda6/OVM_OL5U7_X86_64_PVM_10GB/System.img
+ xenstore_write backend/vbd/1/51712/node /dev/loop0
+ _xenstore_write backend/vbd/1/51712/node /dev/loop0
+ log debug 'Writing backend/vbd/1/51712/node' '/dev/loop0 to xenstore.'
+ local level=debug
+ shift
+ logger -p daemon.debug -- /etc/xen/scripts/block: 'Writing backend/vbd/1/51712/node' '/dev/loop0 to xenstore.'
+ xenstore-write backend/vbd/1/51712/node /dev/loop0
+ write_dev /dev/loop0
+ local mm
++ device_major_minor /dev/loop0
++ stat -L -c %t:%T /dev/loop0
+ mm=7:0
+ '[' -z 7:0 ']'
+ xenstore_write backend/vbd/1/51712/physical-device 7:0
+ _xenstore_write backend/vbd/1/51712/physical-device 7:0
+ log debug 'Writing backend/vbd/1/51712/physical-device' '7:0 to xenstore.'
+ local level=debug
+ shift
+ logger -p daemon.debug -- /etc/xen/scripts/block: 'Writing backend/vbd/1/51712/physical-device' '7:0 to xenstore.'
+ xenstore-write backend/vbd/1/51712/physical-device 7:0
+ success
+ xenstore_write backend/vbd/1/51712/hotplug-status connected
+ _xenstore_write backend/vbd/1/51712/hotplug-status connected
+ log debug 'Writing backend/vbd/1/51712/hotplug-status' 'connected to xenstore.'
+ local level=debug
+ shift
+ logger -p daemon.debug -- /etc/xen/scripts/block: 'Writing backend/vbd/1/51712/hotplug-status' 'connected to xenstore.'
+ xenstore-write backend/vbd/1/51712/hotplug-status connected
+ release_lock block
+ _setlockfd block
+ local i
+ (( i = 0 ))
+ (( i < 5 ))
+ '[' -z block -o block = block ']'
+ break
+ _lockdict[$i]=block
+ let _lockfd=200+i
+ _lockfile=/var/run/xen-hotplug/block
+ rm /var/run/xen-hotplug/block
+ exit 0
+++ export PATH=/usr/bin:/usr/sbin:/usr/lib/xen/bin:/usr/lib/xen/bin:/sbin:/bin:/usr/bin:/usr/sbin:/usr/local/bin:/bin:/usr/bin
+++ PATH=/usr/bin:/usr/sbin:/usr/lib/xen/bin:/usr/lib/xen/bin:/sbin:/bin:/usr/bin:/usr/sbin:/usr/local/bin:/bin:/usr/bin
+++ export LANG=POSIX
+++ LANG=POSIX
++++ cut -d= -f1
++++ grep '^LC_'
++++ set
+++ unset
+++ trap sigerr ERR
+++ log debug remove XENBUS_PATH=backend/vbd/1/51712
+++ local level=debug
+++ shift
+++ logger -p daemon.debug -- /etc/xen/scripts/block: remove XENBUS_PATH=backend/vbd/1/51712
++ findCommand remove
++ for arg in '"$@"'
++ expr index remove =
++ command=remove
++ return
++ '[' remove '!=' add ']'
++ '[' remove '!=' remove ']'
++ XENBUS_PATH=backend/vbd/1/51712
++ xenstore_read_default backend/vbd/1/51712/type MISSING
++ xenstore-read backend/vbd/1/51712/type
+ t=file
+ case "$command" in
+ case $t in
+ claim_lock block
+ mkdir -p /var/run/xen-hotplug
+ _setlockfd block
+ local i
+ (( i = 0 ))
+ (( i < 0 ))
+ _lockdict[$i]=block
+ let _lockfd=200+i
+ _lockfile=/var/run/xen-hotplug/block
+ local rightfile
+ true
+ eval 'exec 200>>/var/run/xen-hotplug/block'
++ exec
+ flock -x 200
++ perl -e '
            open STDIN, "<&200" or die $!;
            my $fd_inum = (stat STDIN)[1]; die $! unless defined $fd_inum;
            my $file_inum = (stat $ARGV[0])[1];
            print "y\n" if $fd_inum eq $file_inum;
                             ' /var/run/xen-hotplug/block
+ rightfile=
+ '[' x = xy ']'
+ true
+ eval 'exec 200>>/var/run/xen-hotplug/block'
++ exec
+ flock -x 200
++ perl -e '
            open STDIN, "<&200" or die $!;
            my $fd_inum = (stat STDIN)[1]; die $! unless defined $fd_inum;
            my $file_inum = (stat $ARGV[0])[1];
            print "y\n" if $fd_inum eq $file_inum;
                             ' /var/run/xen-hotplug/block
+ rightfile=
+ '[' x = xy ']'
+ true
+ eval 'exec 200>>/var/run/xen-hotplug/block'
++ exec
+ flock -x 200
++ perl -e '
            open STDIN, "<&200" or die $!;
            my $fd_inum = (stat STDIN)[1]; die $! unless defined $fd_inum;
            my $file_inum = (stat $ARGV[0])[1];
            print "y\n" if $fd_inum eq $file_inum;
                             ' /var/run/xen-hotplug/block
+ rightfile=
+ '[' x = xy ']'
+ true
+ eval 'exec 200>>/var/run/xen-hotplug/block'
++ exec
+ flock -x 200
++ perl -e '
            open STDIN, "<&200" or die $!;
            my $fd_inum = (stat STDIN)[1]; die $! unless defined $fd_inum;
            my $file_inum = (stat $ARGV[0])[1];
            print "y\n" if $fd_inum eq $file_inum;
                             ' /var/run/xen-hotplug/block
+ rightfile=
+ '[' x = xy ']'
+ true
+ eval 'exec 200>>/var/run/xen-hotplug/block'
++ exec
+ flock -x 200
++ perl -e '
            open STDIN, "<&200" or die $!;
            my $fd_inum = (stat STDIN)[1]; die $! unless defined $fd_inum;
            my $file_inum = (stat $ARGV[0])[1];
            print "y\n" if $fd_inum eq $file_inum;
                             ' /var/run/xen-hotplug/block
+ rightfile=
+ '[' x = xy ']'
+ true
+ eval 'exec 200>>/var/run/xen-hotplug/block'
++ exec
+ flock -x 200
++ perl -e '
            open STDIN, "<&200" or die $!;
            my $fd_inum = (stat STDIN)[1]; die $! unless defined $fd_inum;
            my $file_inum = (stat $ARGV[0])[1];
            print "y\n" if $fd_inum eq $file_inum;
                             ' /var/run/xen-hotplug/block
+ rightfile=
+ '[' x = xy ']'
+ true
+ eval 'exec 200>>/var/run/xen-hotplug/block'
++ exec
+ flock -x 200
++ perl -e '
            open STDIN, "<&200" or die $!;
            my $fd_inum = (stat STDIN)[1]; die $! unless defined $fd_inum;
            my $file_inum = (stat $ARGV[0])[1];
            print "y\n" if $fd_inum eq $file_inum;
                             ' /var/run/xen-hotplug/block
+ rightfile=
+ '[' x = xy ']'
+ true
+ eval 'exec 200>>/var/run/xen-hotplug/block'
++ exec
+ flock -x 200
++ perl -e '
            open STDIN, "<&200" or die $!;
            my $fd_inum = (stat STDIN)[1]; die $! unless defined $fd_inum;
            my $file_inum = (stat $ARGV[0])[1];
            print "y\n" if $fd_inum eq $file_inum;
                             ' /var/run/xen-hotplug/block
+ rightfile=
+ '[' x = xy ']'
+ true
+ eval 'exec 200>>/var/run/xen-hotplug/block'
++ exec
+ flock -x 200
++ perl -e '
            open STDIN, "<&200" or die $!;
            my $fd_inum = (stat STDIN)[1]; die $! unless defined $fd_inum;
            my $file_inum = (stat $ARGV[0])[1];
            print "y\n" if $fd_inum eq $file_inum;
                             ' /var/run/xen-hotplug/block
+ rightfile=
+ '[' x = xy ']'
+ true
+ eval 'exec 200>>/var/run/xen-hotplug/block'
++ exec
+ flock -x 200
++ perl -e '
            open STDIN, "<&200" or die $!;
            my $fd_inum = (stat STDIN)[1]; die $! unless defined $fd_inum;
            my $file_inum = (stat $ARGV[0])[1];
            print "y\n" if $fd_inum eq $file_inum;
                             ' /var/run/xen-hotplug/block
+ rightfile=
+ '[' x = xy ']'
+ true
+ eval 'exec 200>>/var/run/xen-hotplug/block'
++ exec
+ flock -x 200
++ perl -e '
            open STDIN, "<&200" or die $!;
            my $fd_inum = (stat STDIN)[1]; die $! unless defined $fd_inum;
            my $file_inum = (stat $ARGV[0])[1];
            print "y\n" if $fd_inum eq $file_inum;
                             ' /var/run/xen-hotplug/block
+ rightfile=
+ '[' x = xy ']'
+ true
+ eval 'exec 200>>/var/run/xen-hotplug/block'
++ exec
+ flock -x 200
++ perl -e '
            open STDIN, "<&200" or die $!;
            my $fd_inum = (stat STDIN)[1]; die $! unless defined $fd_inum;
            my $file_inum = (stat $ARGV[0])[1];
            print "y\n" if $fd_inum eq $file_inum;
                             ' /var/run/xen-hotplug/block
+ rightfile=
+ '[' x = xy ']'
+ true
+ eval 'exec 200>>/var/run/xen-hotplug/block'
++ exec
+ flock -x 200
++ perl -e '
            open STDIN, "<&200" or die $!;
            my $fd_inum = (stat STDIN)[1]; die $! unless defined $fd_inum;
            my $file_inum = (stat $ARGV[0])[1];
            print "y\n" if $fd_inum eq $file_inum;
                             ' /var/run/xen-hotplug/block
+ rightfile=
+ '[' x = xy ']'
+ true
+ eval 'exec 200>>/var/run/xen-hotplug/block'
++ exec
+ flock -x 200
++ perl -e '
            open STDIN, "<&200" or die $!;
            my $fd_inum = (stat STDIN)[1]; die $! unless defined $fd_inum;
            my $file_inum = (stat $ARGV[0])[1];
            print "y\n" if $fd_inum eq $file_inum;
                             ' /var/run/xen-hotplug/block
+ rightfile=
+ '[' x = xy ']'
+ true
+ eval 'exec 200>>/var/run/xen-hotplug/block'
++ exec
+ flock -x 200
++ perl -e '
            open STDIN, "<&200" or die $!;
            my $fd_inum = (stat STDIN)[1]; die $! unless defined $fd_inum;
            my $file_inum = (stat $ARGV[0])[1];
            print "y\n" if $fd_inum eq $file_inum;
                             ' /var/run/xen-hotplug/block
+ rightfile=
+ '[' x = xy ']'
+ true
+ eval 'exec 200>>/var/run/xen-hotplug/block'
++ exec
+ flock -x 200
++ perl -e '
            open STDIN, "<&200" or die $!;
            my $fd_inum = (stat STDIN)[1]; die $! unless defined $fd_inum;
            my $file_inum = (stat $ARGV[0])[1];
            print "y\n" if $fd_inum eq $file_inum;
                             ' /var/run/xen-hotplug/block
+ rightfile=
+ '[' x = xy ']'
+ true
+ eval 'exec 200>>/var/run/xen-hotplug/block'
++ exec
+ flock -x 200
++ perl -e '
            open STDIN, "<&200" or die $!;
            my $fd_inum = (stat STDIN)[1]; die $! unless defined $fd_inum;
            my $file_inum = (stat $ARGV[0])[1];
            print "y\n" if $fd_inum eq $file_inum;
                             ' /var/run/xen-hotplug/block
+ rightfile=
+ '[' x = xy ']'
+ true
+ eval 'exec 200>>/var/run/xen-hotplug/block'
++ exec
+ flock -x 200
++ perl -e '
            open STDIN, "<&200" or die $!;
            my $fd_inum = (stat STDIN)[1]; die $! unless defined $fd_inum;
            my $file_inum = (stat $ARGV[0])[1];
            print "y\n" if $fd_inum eq $file_inum;
                             ' /var/run/xen-hotplug/block
+ rightfile=
+ '[' x = xy ']'
+ true
+ eval 'exec 200>>/var/run/xen-hotplug/block'
++ exec
+ flock -x 200
++ perl -e '
            open STDIN, "<&200" or die $!;
            my $fd_inum = (stat STDIN)[1]; die $! unless defined $fd_inum;
            my $file_inum = (stat $ARGV[0])[1];
            print "y\n" if $fd_inum eq $file_inum;
                             ' /var/run/xen-hotplug/block
+ rightfile=
+ '[' x = xy ']'
+ true
+ eval 'exec 200>>/var/run/xen-hotplug/block'
++ exec
+ flock -x 200
++ perl -e '
            open STDIN, "<&200" or die $!;
            my $fd_inum = (stat STDIN)[1]; die $! unless defined $fd_inum;
            my $file_inum = (stat $ARGV[0])[1];
            print "y\n" if $fd_inum eq $file_inum;
                             ' /var/run/xen-hotplug/block
+ rightfile=
+ '[' x = xy ']'
+ true
+ eval 'exec 200>>/var/run/xen-hotplug/block'
++ exec
+ flock -x 200
++ perl -e '
            open STDIN, "<&200" or die $!;
            my $fd_inum = (stat STDIN)[1]; die $! unless defined $fd_inum;
            my $file_inum = (stat $ARGV[0])[1];
            print "y\n" if $fd_inum eq $file_inum;
                             ' /var/run/xen-hotplug/block
+ rightfile=
+ '[' x = xy ']'
+ true
+ eval 'exec 200>>/var/run/xen-hotplug/block'
++ exec
+ flock -x 200
++ perl -e '
            open STDIN, "<&200" or die $!;
            my $fd_inum = (stat STDIN)[1]; die $! unless defined $fd_inum;
            my $file_inum = (stat $ARGV[0])[1];
            print "y\n" if $fd_inum eq $file_inum;
                             ' /var/run/xen-hotplug/block
+ rightfile=
+ '[' x = xy ']'
+ true
+ eval 'exec 200>>/var/run/xen-hotplug/block'
++ exec
+ flock -x 200
++ perl -e '
            open STDIN, "<&200" or die $!;
            my $fd_inum = (stat STDIN)[1]; die $! unless defined $fd_inum;
            my $file_inum = (stat $ARGV[0])[1];
            print "y\n" if $fd_inum eq $file_inum;
                             ' /var/run/xen-hotplug/block
+ rightfile=
+ '[' x = xy ']'
+ true
+ eval 'exec 200>>/var/run/xen-hotplug/block'
++ exec
+ flock -x 200
++ perl -e '
            open STDIN, "<&200" or die $!;
            my $fd_inum = (stat STDIN)[1]; die $! unless defined $fd_inum;
            my $file_inum = (stat $ARGV[0])[1];
            print "y\n" if $fd_inum eq $file_inum;
                             ' /var/run/xen-hotplug/block
+ rightfile=
+ '[' x = xy ']'
+ true
+ eval 'exec 200>>/var/run/xen-hotplug/block'
++ exec
+ flock -x 200
++ perl -e '
            open STDIN, "<&200" or die $!;
            my $fd_inum = (stat STDIN)[1]; die $! unless defined $fd_inum;
            my $file_inum = (stat $ARGV[0])[1];
            print "y\n" if $fd_inum eq $file_inum;
                             ' /var/run/xen-hotplug/block
+ rightfile=
+ '[' x = xy ']'
+ true
+ eval 'exec 200>>/var/run/xen-hotplug/block'
++ exec
+ flock -x 200
++ perl -e '
            open STDIN, "<&200" or die $!;
            my $fd_inum = (stat STDIN)[1]; die $! unless defined $fd_inum;
            my $file_inum = (stat $ARGV[0])[1];
            print "y\n" if $fd_inum eq $file_inum;
                             ' /var/run/xen-hotplug/block
+ rightfile=
+ '[' x = xy ']'
+ true
+ eval 'exec 200>>/var/run/xen-hotplug/block'
++ exec
+ flock -x 200
++ perl -e '
            open STDIN, "<&200" or die $!;
            my $fd_inum = (stat STDIN)[1]; die $! unless defined $fd_inum;
            my $file_inum = (stat $ARGV[0])[1];
            print "y\n" if $fd_inum eq $file_inum;
                             ' /var/run/xen-hotplug/block
+ rightfile=
+ '[' x = xy ']'
+ true
+ eval 'exec 200>>/var/run/xen-hotplug/block'
++ exec
+ flock -x 200
++ perl -e '
            open STDIN, "<&200" or die $!;
            my $fd_inum = (stat STDIN)[1]; die $! unless defined $fd_inum;
            my $file_inum = (stat $ARGV[0])[1];
            print "y\n" if $fd_inum eq $file_inum;
                             ' /var/run/xen-hotplug/block
+ rightfile=
+ '[' x = xy ']'
+ true
+ eval 'exec 200>>/var/run/xen-hotplug/block'
++ exec
+ flock -x 200
++ perl -e '
            open STDIN, "<&200" or die $!;
            my $fd_inum = (stat STDIN)[1]; die $! unless defined $fd_inum;
            my $file_inum = (stat $ARGV[0])[1];
            print "y\n" if $fd_inum eq $file_inum;
                             ' /var/run/xen-hotplug/block
+ rightfile=
+ '[' x = xy ']'
+ true
+ eval 'exec 200>>/var/run/xen-hotplug/block'
++ exec
+ flock -x 200
++ perl -e '
            open STDIN, "<&200" or die $!;
            my $fd_inum = (stat STDIN)[1]; die $! unless defined $fd_inum;
            my $file_inum = (stat $ARGV[0])[1];
            print "y\n" if $fd_inum eq $file_inum;
                             ' /var/run/xen-hotplug/block
+ rightfile=
+ '[' x = xy ']'
+ true
+ eval 'exec 200>>/var/run/xen-hotplug/block'
++ exec
+ flock -x 200
++ perl -e '
            open STDIN, "<&200" or die $!;
            my $fd_inum = (stat STDIN)[1]; die $! unless defined $fd_inum;
            my $file_inum = (stat $ARGV[0])[1];
            print "y\n" if $fd_inum eq $file_inum;
                             ' /var/run/xen-hotplug/block
+ rightfile=
+ '[' x = xy ']'
+ true
+ eval 'exec 200>>/var/run/xen-hotplug/block'
++ exec
+ flock -x 200
++ perl -e '
            open STDIN, "<&200" or die $!;
            my $fd_inum = (stat STDIN)[1]; die $! unless defined $fd_inum;
            my $file_inum = (stat $ARGV[0])[1];
            print "y\n" if $fd_inum eq $file_inum;
                             ' /var/run/xen-hotplug/block
+ rightfile=
+ '[' x = xy ']'
+ true
+ eval 'exec 200>>/var/run/xen-hotplug/block'
++ exec
+ flock -x 200
++ perl -e '
            open STDIN, "<&200" or die $!;
            my $fd_inum = (stat STDIN)[1]; die $! unless defined $fd_inum;
            my $file_inum = (stat $ARGV[0])[1];
            print "y\n" if $fd_inum eq $file_inum;
                             ' /var/run/xen-hotplug/block
+ rightfile=
+ '[' x = xy ']'
+ true
+ eval 'exec 200>>/var/run/xen-hotplug/block'
++ exec
+ flock -x 200
++ perl -e '
            open STDIN, "<&200" or die $!;
            my $fd_inum = (stat STDIN)[1]; die $! unless defined $fd_inum;
            my $file_inum = (stat $ARGV[0])[1];
            print "y\n" if $fd_inum eq $file_inum;
                             ' /var/run/xen-hotplug/block
+ rightfile=
+ '[' x = xy ']'
+ true
+ eval 'exec 200>>/var/run/xen-hotplug/block'
++ exec
+ flock -x 200
++ perl -e '
            open STDIN, "<&200" or die $!;
            my $fd_inum = (stat STDIN)[1]; die $! unless defined $fd_inum;
            my $file_inum = (stat $ARGV[0])[1];
            print "y\n" if $fd_inum eq $file_inum;
                             ' /var/run/xen-hotplug/block
+ rightfile=
+ '[' x = xy ']'
+ true
+ eval 'exec 200>>/var/run/xen-hotplug/block'
++ exec
+ flock -x 200
++ perl -e '
            open STDIN, "<&200" or die $!;
            my $fd_inum = (stat STDIN)[1]; die $! unless defined $fd_inum;
            my $file_inum = (stat $ARGV[0])[1];
            print "y\n" if $fd_inum eq $file_inum;
                             ' /var/run/xen-hotplug/block
+ rightfile=
+ '[' x = xy ']'
+ true
+ eval 'exec 200>>/var/run/xen-hotplug/block'
++ exec
+ flock -x 200
++ perl -e '
            open STDIN, "<&200" or die $!;
            my $fd_inum = (stat STDIN)[1]; die $! unless defined $fd_inum;
            my $file_inum = (stat $ARGV[0])[1];
            print "y\n" if $fd_inum eq $file_inum;
                             ' /var/run/xen-hotplug/block
+ rightfile=
+ '[' x = xy ']'
+ true
+ eval 'exec 200>>/var/run/xen-hotplug/block'
++ exec
+ flock -x 200
++ perl -e '
            open STDIN, "<&200" or die $!;
            my $fd_inum = (stat STDIN)[1]; die $! unless defined $fd_inum;
            my $file_inum = (stat $ARGV[0])[1];
            print "y\n" if $fd_inum eq $file_inum;
                             ' /var/run/xen-hotplug/block
+ rightfile=
+ '[' x = xy ']'
+ true
+ eval 'exec 200>>/var/run/xen-hotplug/block'
++ exec
+ flock -x 200
++ perl -e '
            open STDIN, "<&200" or die $!;
            my $fd_inum = (stat STDIN)[1]; die $! unless defined $fd_inum;
            my $file_inum = (stat $ARGV[0])[1];
            print "y\n" if $fd_inum eq $file_inum;
                             ' /var/run/xen-hotplug/block
+ rightfile=
+ '[' x = xy ']'
+ true
+ eval 'exec 200>>/var/run/xen-hotplug/block'
++ exec
+ flock -x 200
++ perl -e '
            open STDIN, "<&200" or die $!;
            my $fd_inum = (stat STDIN)[1]; die $! unless defined $fd_inum;
            my $file_inum = (stat $ARGV[0])[1];
            print "y\n" if $fd_inum eq $file_inum;
                             ' /var/run/xen-hotplug/block
+ rightfile=
+ '[' x = xy ']'
+ true
+ eval 'exec 200>>/var/run/xen-hotplug/block'
++ exec
+ flock -x 200
++ perl -e '
            open STDIN, "<&200" or die $!;
            my $fd_inum = (stat STDIN)[1]; die $! unless defined $fd_inum;
            my $file_inum = (stat $ARGV[0])[1];
            print "y\n" if $fd_inum eq $file_inum;
                             ' /var/run/xen-hotplug/block
+ rightfile=
+ '[' x = xy ']'
+ true
+ eval 'exec 200>>/var/run/xen-hotplug/block'
++ exec
+ flock -x 200
++ perl -e '
            open STDIN, "<&200" or die $!;
            my $fd_inum = (stat STDIN)[1]; die $! unless defined $fd_inum;
            my $file_inum = (stat $ARGV[0])[1];
            print "y\n" if $fd_inum eq $file_inum;
                             ' /var/run/xen-hotplug/block
+ rightfile=
+ '[' x = xy ']'
+ true
+ eval 'exec 200>>/var/run/xen-hotplug/block'
++ exec
+ flock -x 200
++ perl -e '
            open STDIN, "<&200" or die $!;
            my $fd_inum = (stat STDIN)[1]; die $! unless defined $fd_inum;
            my $file_inum = (stat $ARGV[0])[1];
            print "y\n" if $fd_inum eq $file_inum;
                             ' /var/run/xen-hotplug/block
+ rightfile=
+ '[' x = xy ']'
+ true
+ eval 'exec 200>>/var/run/xen-hotplug/block'
++ exec
+ flock -x 200
++ perl -e '
            open STDIN, "<&200" or die $!;
            my $fd_inum = (stat STDIN)[1]; die $! unless defined $fd_inum;
            my $file_inum = (stat $ARGV[0])[1];
            print "y\n" if $fd_inum eq $file_inum;
                             ' /var/run/xen-hotplug/block
+ rightfile=
+ '[' x = xy ']'
+ true
+ eval 'exec 200>>/var/run/xen-hotplug/block'
++ exec
+ flock -x 200
++ perl -e '
            open STDIN, "<&200" or die $!;
            my $fd_inum = (stat STDIN)[1]; die $! unless defined $fd_inum;
            my $file_inum = (stat $ARGV[0])[1];
            print "y\n" if $fd_inum eq $file_inum;
                             ' /var/run/xen-hotplug/block
+ rightfile=
+ '[' x = xy ']'
+ true
+ eval 'exec 200>>/var/run/xen-hotplug/block'
++ exec
+ flock -x 200
++ perl -e '
            open STDIN, "<&200" or die $!;
            my $fd_inum = (stat STDIN)[1]; die $! unless defined $fd_inum;
            my $file_inum = (stat $ARGV[0])[1];
            print "y\n" if $fd_inum eq $file_inum;
                             ' /var/run/xen-hotplug/block
+ rightfile=
+ '[' x = xy ']'
+ true
+ eval 'exec 200>>/var/run/xen-hotplug/block'
++ exec
+ flock -x 200
++ perl -e '
            open STDIN, "<&200" or die $!;
            my $fd_inum = (stat STDIN)[1]; die $! unless defined $fd_inum;
            my $file_inum = (stat $ARGV[0])[1];
            print "y\n" if $fd_inum eq $file_inum;
                             ' /var/run/xen-hotplug/block
+ rightfile=
+ '[' x = xy ']'
+ true
+ eval 'exec 200>>/var/run/xen-hotplug/block'
++ exec
+ flock -x 200
++ perl -e '
            open STDIN, "<&200" or die $!;
            my $fd_inum = (stat STDIN)[1]; die $! unless defined $fd_inum;
            my $file_inum = (stat $ARGV[0])[1];
            print "y\n" if $fd_inum eq $file_inum;
                             ' /var/run/xen-hotplug/block
+ rightfile=
+ '[' x = xy ']'
+ true
+ eval 'exec 200>>/var/run/xen-hotplug/block'
++ exec
+ flock -x 200
++ perl -e '
            open STDIN, "<&200" or die $!;
            my $fd_inum = (stat STDIN)[1]; die $! unless defined $fd_inum;
            my $file_inum = (stat $ARGV[0])[1];
            print "y\n" if $fd_inum eq $file_inum;
                             ' /var/run/xen-hotplug/block
+ rightfile=
+ '[' x = xy ']'
+ true
+ eval 'exec 200>>/var/run/xen-hotplug/block'
++ exec
+ flock -x 200
++ perl -e '
            open STDIN, "<&200" or die $!;
            my $fd_inum = (stat STDIN)[1]; die $! unless defined $fd_inum;
            my $file_inum = (stat $ARGV[0])[1];
            print "y\n" if $fd_inum eq $file_inum;
                             ' /var/run/xen-hotplug/block
+ rightfile=
+ '[' x = xy ']'
+ true
+ eval 'exec 200>>/var/run/xen-hotplug/block'
++ exec
+ flock -x 200
++ perl -e '
            open STDIN, "<&200" or die $!;
            my $fd_inum = (stat STDIN)[1]; die $! unless defined $fd_inum;
            my $file_inum = (stat $ARGV[0])[1];
            print "y\n" if $fd_inum eq $file_inum;
                             ' /var/run/xen-hotplug/block
+ rightfile=
+ '[' x = xy ']'
+ true
+ eval 'exec 200>>/var/run/xen-hotplug/block'
++ exec
+ flock -x 200
++ perl -e '
            open STDIN, "<&200" or die $!;
            my $fd_inum = (stat STDIN)[1]; die $! unless defined $fd_inum;
            my $file_inum = (stat $ARGV[0])[1];
            print "y\n" if $fd_inum eq $file_inum;
                             ' /var/run/xen-hotplug/block
+ rightfile=
+ '[' x = xy ']'
+ true
+ eval 'exec 200>>/var/run/xen-hotplug/block'
++ exec
+ flock -x 200
++ perl -e '
            open STDIN, "<&200" or die $!;
            my $fd_inum = (stat STDIN)[1]; die $! unless defined $fd_inum;
            my $file_inum = (stat $ARGV[0])[1];
            print "y\n" if $fd_inum eq $file_inum;
                             ' /var/run/xen-hotplug/block
+ rightfile=
+ '[' x = xy ']'
+ true
+ eval 'exec 200>>/var/run/xen-hotplug/block'
++ exec
+ flock -x 200
++ perl -e '
            open STDIN, "<&200" or die $!;
            my $fd_inum = (stat STDIN)[1]; die $! unless defined $fd_inum;
            my $file_inum = (stat $ARGV[0])[1];
            print "y\n" if $fd_inum eq $file_inum;
                             ' /var/run/xen-hotplug/block
+ rightfile=
+ '[' x = xy ']'
+ true
+ eval 'exec 200>>/var/run/xen-hotplug/block'
++ exec
+ flock -x 200
++ perl -e '
            open STDIN, "<&200" or die $!;
            my $fd_inum = (stat STDIN)[1]; die $! unless defined $fd_inum;
            my $file_inum = (stat $ARGV[0])[1];
            print "y\n" if $fd_inum eq $file_inum;
                             ' /var/run/xen-hotplug/block
+ rightfile=
+ '[' x = xy ']'
+ true
+ eval 'exec 200>>/var/run/xen-hotplug/block'
++ exec
+ flock -x 200
++ perl -e '
            open STDIN, "<&200" or die $!;
            my $fd_inum = (stat STDIN)[1]; die $! unless defined $fd_inum;
            my $file_inum = (stat $ARGV[0])[1];
            print "y\n" if $fd_inum eq $file_inum;
                             ' /var/run/xen-hotplug/block
+ rightfile=
+ '[' x = xy ']'
+ true
+ eval 'exec 200>>/var/run/xen-hotplug/block'
++ exec
+ flock -x 200
++ perl -e '
            open STDIN, "<&200" or die $!;
            my $fd_inum = (stat STDIN)[1]; die $! unless defined $fd_inum;
            my $file_inum = (stat $ARGV[0])[1];
            print "y\n" if $fd_inum eq $file_inum;
                             ' /var/run/xen-hotplug/block
+ rightfile=
+ '[' x = xy ']'
+ true
+ eval 'exec 200>>/var/run/xen-hotplug/block'
++ exec
+ flock -x 200
++ perl -e '
            open STDIN, "<&200" or die $!;
            my $fd_inum = (stat STDIN)[1]; die $! unless defined $fd_inum;
            my $file_inum = (stat $ARGV[0])[1];
            print "y\n" if $fd_inum eq $file_inum;
                             ' /var/run/xen-hotplug/block
+ rightfile=
+ '[' x = xy ']'
+ true
+ eval 'exec 200>>/var/run/xen-hotplug/block'
++ exec
+ flock -x 200
++ perl -e '
            open STDIN, "<&200" or die $!;
            my $fd_inum = (stat STDIN)[1]; die $! unless defined $fd_inum;
            my $file_inum = (stat $ARGV[0])[1];
            print "y\n" if $fd_inum eq $file_inum;
                             ' /var/run/xen-hotplug/block
+ rightfile=
+ '[' x = xy ']'
+ true
+ eval 'exec 200>>/var/run/xen-hotplug/block'
++ exec
+ flock -x 200
++ perl -e '
            open STDIN, "<&200" or die $!;
            my $fd_inum = (stat STDIN)[1]; die $! unless defined $fd_inum;
            my $file_inum = (stat $ARGV[0])[1];
            print "y\n" if $fd_inum eq $file_inum;
                             ' /var/run/xen-hotplug/block
+ rightfile=
+ '[' x = xy ']'
+ true
+ eval 'exec 200>>/var/run/xen-hotplug/block'
++ exec
+ flock -x 200
++ perl -e '
            open STDIN, "<&200" or die $!;
            my $fd_inum = (stat STDIN)[1]; die $! unless defined $fd_inum;
            my $file_inum = (stat $ARGV[0])[1];
            print "y\n" if $fd_inum eq $file_inum;
                             ' /var/run/xen-hotplug/block
+ rightfile=
+ '[' x = xy ']'
+ true
+ eval 'exec 200>>/var/run/xen-hotplug/block'
++ exec
+ flock -x 200
++ perl -e '
            open STDIN, "<&200" or die $!;
            my $fd_inum = (stat STDIN)[1]; die $! unless defined $fd_inum;
            my $file_inum = (stat $ARGV[0])[1];
            print "y\n" if $fd_inum eq $file_inum;
                             ' /var/run/xen-hotplug/block
+ rightfile=
+ '[' x = xy ']'
+ true
+ eval 'exec 200>>/var/run/xen-hotplug/block'
++ exec
+ flock -x 200
++ perl -e '
            open STDIN, "<&200" or die $!;
            my $fd_inum = (stat STDIN)[1]; die $! unless defined $fd_inum;
            my $file_inum = (stat $ARGV[0])[1];
            print "y\n" if $fd_inum eq $file_inum;
                             ' /var/run/xen-hotplug/block
+ rightfile=
+ '[' x = xy ']'
+ true
+ eval 'exec 200>>/var/run/xen-hotplug/block'
++ exec
+ flock -x 200
++ perl -e '
            open STDIN, "<&200" or die $!;
            my $fd_inum = (stat STDIN)[1]; die $! unless defined $fd_inum;
            my $file_inum = (stat $ARGV[0])[1];
            print "y\n" if $fd_inum eq $file_inum;
                             ' /var/run/xen-hotplug/block
+ rightfile=
+ '[' x = xy ']'
+ true
+ eval 'exec 200>>/var/run/xen-hotplug/block'
++ exec
+ flock -x 200
++ perl -e '
            open STDIN, "<&200" or die $!;
            my $fd_inum = (stat STDIN)[1]; die $! unless defined $fd_inum;
            my $file_inum = (stat $ARGV[0])[1];
            print "y\n" if $fd_inum eq $file_inum;
                             ' /var/run/xen-hotplug/block
+ rightfile=
+ '[' x = xy ']'
+ true
+ eval 'exec 200>>/var/run/xen-hotplug/block'
++ exec
+ flock -x 200
++ perl -e '
            open STDIN, "<&200" or die $!;
            my $fd_inum = (stat STDIN)[1]; die $! unless defined $fd_inum;
            my $file_inum = (stat $ARGV[0])[1];
            print "y\n" if $fd_inum eq $file_inum;
                             ' /var/run/xen-hotplug/block
+ rightfile=
+ '[' x = xy ']'
+ true
+ eval 'exec 200>>/var/run/xen-hotplug/block'
++ exec
+ flock -x 200
++ perl -e '
            open STDIN, "<&200" or die $!;
            my $fd_inum = (stat STDIN)[1]; die $! unless defined $fd_inum;
            my $file_inum = (stat $ARGV[0])[1];
            print "y\n" if $fd_inum eq $file_inum;
                             ' /var/run/xen-hotplug/block
+ rightfile=
+ '[' x = xy ']'
+ true
+ eval 'exec 200>>/var/run/xen-hotplug/block'
++ exec
+ flock -x 200
++ perl -e '
            open STDIN, "<&200" or die $!;
            my $fd_inum = (stat STDIN)[1]; die $! unless defined $fd_inum;
            my $file_inum = (stat $ARGV[0])[1];
[root@zhenzhong1 tmp]#

--------------090605080908040808080902
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--------------090605080908040808080902--


From xen-devel-bounces@lists.xen.org Fri Sep 28 14:46:50 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Sep 2012 14: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 1THbpn-0006iI-KI; Fri, 28 Sep 2012 14:46:31 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <zhenzhong.duan@oracle.com>) id 1THbpl-0006iA-9s
	for xen-devel@lists.xen.org; Fri, 28 Sep 2012 14:46:29 +0000
Received: from [85.158.138.51:13339] by server-16.bemta-3.messagelabs.com id
	BC/B4-09129-448B5605; Fri, 28 Sep 2012 14:46:28 +0000
X-Env-Sender: zhenzhong.duan@oracle.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1348843582!32347870!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzcxNjk5\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16173 invoked from network); 28 Sep 2012 14:46:24 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-11.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 28 Sep 2012 14:46:24 -0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q8SEkEeg001376
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 28 Sep 2012 14:46:15 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
	q8SEkDsO026097
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 28 Sep 2012 14:46:14 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
	q8SEkD4M032319; Fri, 28 Sep 2012 09:46:13 -0500
Received: from [10.191.7.62] (/10.191.7.62)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 28 Sep 2012 07:46:11 -0700
Message-ID: <5065B82B.8080003@oracle.com>
Date: Fri, 28 Sep 2012 22:46:03 +0800
From: Zhenzhong Duan <zhenzhong.duan@oracle.com>
Organization: oracle
User-Agent: Mozilla/5.0 (Windows NT 5.1;
	rv:12.0) Gecko/20120428 Thunderbird/12.0.1
MIME-Version: 1.0
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
References: <505C3647.1030003@oracle.com>
	<20120921143430.GA3522@phenom.dumpdata.com>
	<5062C16A.1020306@oracle.com>
	<20120926123534.GF7356@phenom.dumpdata.com>
	<5063EAFB.1070307@oracle.com>
	<20120927115918.GE8832@phenom.dumpdata.com>
	<50657D4B.9040303@oracle.com>
	<20120928140109.GA7483@localhost.localdomain>
	<20581.45245.846208.289785@mariner.uk.xensource.com>
In-Reply-To: <20581.45245.846208.289785@mariner.uk.xensource.com>
Content-Type: multipart/mixed; boundary="------------090605080908040808080902"
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: Konrad Rzeszutek Wilk <konrad@kernel.org>,
	Dan Magenheimer <dan.magenheimer@oracle.com>,
	xen-devel <xen-devel@lists.xen.org>, Feng Jin <joe.jin@oracle.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] Is: Contention in block script when doing guest
 saving. Was:Re: an issue with 'xm save'
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: zhenzhong.duan@oracle.com
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a multi-part message in MIME format.
--------------090605080908040808080902
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

On 2012-09-28 22:14, Ian Jackson wrote:
> Konrad Rzeszutek Wilk writes ("Is: Contention in block script when doing guest saving. Was:Re: [Xen-devel] an issue with 'xm save'"):
>> On Fri, Sep 28, 2012 at 06:34:51PM +0800, Zhenzhong Duan wrote:
>>> After replace locking.sh with OVM's, it worked.
>>> But xen-tools evolved to use flock based locking currently. We can't
>>> revert back.
>>> It seems changeset 25595:497e2fe49455 bring the issue.
>>> Finally, I came with a small patch that workaround the issue.
>> Ian, any thoughts on how this can be fixed properly? The locking
>> is quite heavy and causes two scripts that do deal with blocks
>> to spin for a long time.
> The algorithm is not supposed to spin.  If it spins there is a bug, I
> think.
>
> Can you show me a transcript of the spinning happening with "set -x"
> in force ?
Hi Ian,
Attachment is part of xen-hotplug.log that will show the spin.
Original file is nearly 7G big. I fetch first 1000 lines.

Below is steps I did:
1. delete xen-hotplug.log
2. reboot dom0
3. add "set -x" to head of block script.
4.create first PV guest
5. save guest
6. get first 1000 lines from xen-hotplug.log

thanks
zduan

--------------090605080908040808080902
Content-Type: text/plain; charset=gb18030;
 name="xen-hotplug.log"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename="xen-hotplug.log"

[root@zhenzhong1 tmp]# head -n 1000 /var/log/xen/xen-hotplug.log
+++ export PATH=/usr/bin:/usr/sbin:/usr/lib/xen/bin:/usr/lib/xen/bin:/sbin:/bin:/usr/bin:/usr/sbin:/usr/local/bin:/bin:/usr/bin
+++ PATH=/usr/bin:/usr/sbin:/usr/lib/xen/bin:/usr/lib/xen/bin:/sbin:/bin:/usr/bin:/usr/sbin:/usr/local/bin:/bin:/usr/bin
+++ export LANG=POSIX
+++ LANG=POSIX
++++ set
++++ grep '^LC_'
++++ cut -d= -f1
+++ unset
+++ trap sigerr ERR
+++ log debug add XENBUS_PATH=backend/vbd/1/51712
+++ local level=debug
+++ shift
+++ logger -p daemon.debug -- /etc/xen/scripts/block: add XENBUS_PATH=backend/vbd/1/51712
++ findCommand add
++ for arg in '"$@"'
++ expr index add =
++ command=add
++ return
++ '[' add '!=' add ']'
++ XENBUS_PATH=backend/vbd/1/51712
++ xenstore_read_default backend/vbd/1/51712/type MISSING
++ xenstore-read backend/vbd/1/51712/type
+ t=file
+ case "$command" in
++ xenstore_read_default backend/vbd/1/51712/physical-device MISSING
++ xenstore-read backend/vbd/1/51712/physical-device
++ echo MISSING
+ phys=MISSING
+ '[' MISSING '!=' MISSING ']'
+ '[' -n file ']'
++ xenstore_read backend/vbd/1/51712/params
+++ xenstore-read backend/vbd/1/51712/params
++ local v=/mnt/sda6/OVM_OL5U7_X86_64_PVM_10GB/System.img
++ '[' /mnt/sda6/OVM_OL5U7_X86_64_PVM_10GB/System.img '!=' '' ']'
++ echo /mnt/sda6/OVM_OL5U7_X86_64_PVM_10GB/System.img
+ p=/mnt/sda6/OVM_OL5U7_X86_64_PVM_10GB/System.img
++ xenstore_read backend/vbd/1/51712/mode
+++ xenstore-read backend/vbd/1/51712/mode
++ local v=w
++ '[' w '!=' '' ']'
++ echo w
+ mode=w
++ xenstore_read backend/vbd/1/51712/frontend-id
+++ xenstore-read backend/vbd/1/51712/frontend-id
++ local v=1
++ '[' 1 '!=' '' ']'
++ echo 1
+ FRONTEND_ID=1
++ xenstore_read_default /local/domain/1/vm unknown
++ xenstore-read /local/domain/1/vm
+ FRONTEND_UUID=/vm/cc02077f-d327-cdf2-4876-91bb7ece8cc8
+ case $t in
++ readlink -f /mnt/sda6/OVM_OL5U7_X86_64_PVM_10GB/System.img
+ file=/mnt/sda6/OVM_OL5U7_X86_64_PVM_10GB/System.img
+ test -f /mnt/sda6/OVM_OL5U7_X86_64_PVM_10GB/System.img
++ canonicalise_mode w
++ local mode=w
++ expr index w w
++ expr index w '!'
++ echo w
+ mode=w
+ claim_lock block
+ mkdir -p /var/run/xen-hotplug
+ _setlockfd block
+ local i
+ (( i = 0 ))
+ (( i < 0 ))
+ _lockdict[$i]=block
+ let _lockfd=200+i
+ _lockfile=/var/run/xen-hotplug/block
+ local rightfile
+ true
+ eval 'exec 200>>/var/run/xen-hotplug/block'
++ exec
+ flock -x 200
++ perl -e '
            open STDIN, "<&200" or die $!;
            my $fd_inum = (stat STDIN)[1]; die $! unless defined $fd_inum;
            my $file_inum = (stat $ARGV[0])[1];
            print "y\n" if $fd_inum eq $file_inum;
                             ' /var/run/xen-hotplug/block
+ rightfile=y
+ '[' xy = xy ']'
+ break
++ xenstore_read_default backend/vbd/1/51712/state unknown
++ xenstore-read backend/vbd/1/51712/state
+ xenbus_state=2
+ '[' 2 '!=' 2 ']'
+ '[' w = w ']'
+ stat /mnt/sda6/OVM_OL5U7_X86_64_PVM_10GB/System.img -c %A
+ grep -q w
+ '[' xw '!=' 'x!' ']'
++ stat -c %i /mnt/sda6/OVM_OL5U7_X86_64_PVM_10GB/System.img
+ inode=835587
++ stat -c %D /mnt/sda6/OVM_OL5U7_X86_64_PVM_10GB/System.img
+ dev=806
+ '[' -z 835587 ']'
+ '[' -z 806 ']'
++ losetup -a
++ sed -n -e 's@^\([^:]\+\)\(:[[:blank:]]\[0*806\]:835587[[:blank:]](.*)\)@\1@p'
+ shared_list=
++ losetup -f
+ loopdev=/dev/loop0
+ '[' /dev/loop0 = '' ']'
+ LANG=C
+ losetup -h
+ grep read-only
+ roflag=-w
+ roflag=
+ roflag=
+ do_or_die losetup /dev/loop0 /mnt/sda6/OVM_OL5U7_X86_64_PVM_10GB/System.img
+ losetup /dev/loop0 /mnt/sda6/OVM_OL5U7_X86_64_PVM_10GB/System.img
+ xenstore_write backend/vbd/1/51712/node /dev/loop0
+ _xenstore_write backend/vbd/1/51712/node /dev/loop0
+ log debug 'Writing backend/vbd/1/51712/node' '/dev/loop0 to xenstore.'
+ local level=debug
+ shift
+ logger -p daemon.debug -- /etc/xen/scripts/block: 'Writing backend/vbd/1/51712/node' '/dev/loop0 to xenstore.'
+ xenstore-write backend/vbd/1/51712/node /dev/loop0
+ write_dev /dev/loop0
+ local mm
++ device_major_minor /dev/loop0
++ stat -L -c %t:%T /dev/loop0
+ mm=7:0
+ '[' -z 7:0 ']'
+ xenstore_write backend/vbd/1/51712/physical-device 7:0
+ _xenstore_write backend/vbd/1/51712/physical-device 7:0
+ log debug 'Writing backend/vbd/1/51712/physical-device' '7:0 to xenstore.'
+ local level=debug
+ shift
+ logger -p daemon.debug -- /etc/xen/scripts/block: 'Writing backend/vbd/1/51712/physical-device' '7:0 to xenstore.'
+ xenstore-write backend/vbd/1/51712/physical-device 7:0
+ success
+ xenstore_write backend/vbd/1/51712/hotplug-status connected
+ _xenstore_write backend/vbd/1/51712/hotplug-status connected
+ log debug 'Writing backend/vbd/1/51712/hotplug-status' 'connected to xenstore.'
+ local level=debug
+ shift
+ logger -p daemon.debug -- /etc/xen/scripts/block: 'Writing backend/vbd/1/51712/hotplug-status' 'connected to xenstore.'
+ xenstore-write backend/vbd/1/51712/hotplug-status connected
+ release_lock block
+ _setlockfd block
+ local i
+ (( i = 0 ))
+ (( i < 5 ))
+ '[' -z block -o block = block ']'
+ break
+ _lockdict[$i]=block
+ let _lockfd=200+i
+ _lockfile=/var/run/xen-hotplug/block
+ rm /var/run/xen-hotplug/block
+ exit 0
+++ export PATH=/usr/bin:/usr/sbin:/usr/lib/xen/bin:/usr/lib/xen/bin:/sbin:/bin:/usr/bin:/usr/sbin:/usr/local/bin:/bin:/usr/bin
+++ PATH=/usr/bin:/usr/sbin:/usr/lib/xen/bin:/usr/lib/xen/bin:/sbin:/bin:/usr/bin:/usr/sbin:/usr/local/bin:/bin:/usr/bin
+++ export LANG=POSIX
+++ LANG=POSIX
++++ cut -d= -f1
++++ grep '^LC_'
++++ set
+++ unset
+++ trap sigerr ERR
+++ log debug remove XENBUS_PATH=backend/vbd/1/51712
+++ local level=debug
+++ shift
+++ logger -p daemon.debug -- /etc/xen/scripts/block: remove XENBUS_PATH=backend/vbd/1/51712
++ findCommand remove
++ for arg in '"$@"'
++ expr index remove =
++ command=remove
++ return
++ '[' remove '!=' add ']'
++ '[' remove '!=' remove ']'
++ XENBUS_PATH=backend/vbd/1/51712
++ xenstore_read_default backend/vbd/1/51712/type MISSING
++ xenstore-read backend/vbd/1/51712/type
+ t=file
+ case "$command" in
+ case $t in
+ claim_lock block
+ mkdir -p /var/run/xen-hotplug
+ _setlockfd block
+ local i
+ (( i = 0 ))
+ (( i < 0 ))
+ _lockdict[$i]=block
+ let _lockfd=200+i
+ _lockfile=/var/run/xen-hotplug/block
+ local rightfile
+ true
+ eval 'exec 200>>/var/run/xen-hotplug/block'
++ exec
+ flock -x 200
++ perl -e '
            open STDIN, "<&200" or die $!;
            my $fd_inum = (stat STDIN)[1]; die $! unless defined $fd_inum;
            my $file_inum = (stat $ARGV[0])[1];
            print "y\n" if $fd_inum eq $file_inum;
                             ' /var/run/xen-hotplug/block
+ rightfile=
+ '[' x = xy ']'
+ true
+ eval 'exec 200>>/var/run/xen-hotplug/block'
++ exec
+ flock -x 200
++ perl -e '
            open STDIN, "<&200" or die $!;
            my $fd_inum = (stat STDIN)[1]; die $! unless defined $fd_inum;
            my $file_inum = (stat $ARGV[0])[1];
            print "y\n" if $fd_inum eq $file_inum;
                             ' /var/run/xen-hotplug/block
+ rightfile=
+ '[' x = xy ']'
+ true
+ eval 'exec 200>>/var/run/xen-hotplug/block'
++ exec
+ flock -x 200
++ perl -e '
            open STDIN, "<&200" or die $!;
            my $fd_inum = (stat STDIN)[1]; die $! unless defined $fd_inum;
            my $file_inum = (stat $ARGV[0])[1];
            print "y\n" if $fd_inum eq $file_inum;
                             ' /var/run/xen-hotplug/block
+ rightfile=
+ '[' x = xy ']'
+ true
+ eval 'exec 200>>/var/run/xen-hotplug/block'
++ exec
+ flock -x 200
++ perl -e '
            open STDIN, "<&200" or die $!;
            my $fd_inum = (stat STDIN)[1]; die $! unless defined $fd_inum;
            my $file_inum = (stat $ARGV[0])[1];
            print "y\n" if $fd_inum eq $file_inum;
                             ' /var/run/xen-hotplug/block
+ rightfile=
+ '[' x = xy ']'
+ true
+ eval 'exec 200>>/var/run/xen-hotplug/block'
++ exec
+ flock -x 200
++ perl -e '
            open STDIN, "<&200" or die $!;
            my $fd_inum = (stat STDIN)[1]; die $! unless defined $fd_inum;
            my $file_inum = (stat $ARGV[0])[1];
            print "y\n" if $fd_inum eq $file_inum;
                             ' /var/run/xen-hotplug/block
+ rightfile=
+ '[' x = xy ']'
+ true
+ eval 'exec 200>>/var/run/xen-hotplug/block'
++ exec
+ flock -x 200
++ perl -e '
            open STDIN, "<&200" or die $!;
            my $fd_inum = (stat STDIN)[1]; die $! unless defined $fd_inum;
            my $file_inum = (stat $ARGV[0])[1];
            print "y\n" if $fd_inum eq $file_inum;
                             ' /var/run/xen-hotplug/block
+ rightfile=
+ '[' x = xy ']'
+ true
+ eval 'exec 200>>/var/run/xen-hotplug/block'
++ exec
+ flock -x 200
++ perl -e '
            open STDIN, "<&200" or die $!;
            my $fd_inum = (stat STDIN)[1]; die $! unless defined $fd_inum;
            my $file_inum = (stat $ARGV[0])[1];
            print "y\n" if $fd_inum eq $file_inum;
                             ' /var/run/xen-hotplug/block
+ rightfile=
+ '[' x = xy ']'
+ true
+ eval 'exec 200>>/var/run/xen-hotplug/block'
++ exec
+ flock -x 200
++ perl -e '
            open STDIN, "<&200" or die $!;
            my $fd_inum = (stat STDIN)[1]; die $! unless defined $fd_inum;
            my $file_inum = (stat $ARGV[0])[1];
            print "y\n" if $fd_inum eq $file_inum;
                             ' /var/run/xen-hotplug/block
+ rightfile=
+ '[' x = xy ']'
+ true
+ eval 'exec 200>>/var/run/xen-hotplug/block'
++ exec
+ flock -x 200
++ perl -e '
            open STDIN, "<&200" or die $!;
            my $fd_inum = (stat STDIN)[1]; die $! unless defined $fd_inum;
            my $file_inum = (stat $ARGV[0])[1];
            print "y\n" if $fd_inum eq $file_inum;
                             ' /var/run/xen-hotplug/block
+ rightfile=
+ '[' x = xy ']'
+ true
+ eval 'exec 200>>/var/run/xen-hotplug/block'
++ exec
+ flock -x 200
++ perl -e '
            open STDIN, "<&200" or die $!;
            my $fd_inum = (stat STDIN)[1]; die $! unless defined $fd_inum;
            my $file_inum = (stat $ARGV[0])[1];
            print "y\n" if $fd_inum eq $file_inum;
                             ' /var/run/xen-hotplug/block
+ rightfile=
+ '[' x = xy ']'
+ true
+ eval 'exec 200>>/var/run/xen-hotplug/block'
++ exec
+ flock -x 200
++ perl -e '
            open STDIN, "<&200" or die $!;
            my $fd_inum = (stat STDIN)[1]; die $! unless defined $fd_inum;
            my $file_inum = (stat $ARGV[0])[1];
            print "y\n" if $fd_inum eq $file_inum;
                             ' /var/run/xen-hotplug/block
+ rightfile=
+ '[' x = xy ']'
+ true
+ eval 'exec 200>>/var/run/xen-hotplug/block'
++ exec
+ flock -x 200
++ perl -e '
            open STDIN, "<&200" or die $!;
            my $fd_inum = (stat STDIN)[1]; die $! unless defined $fd_inum;
            my $file_inum = (stat $ARGV[0])[1];
            print "y\n" if $fd_inum eq $file_inum;
                             ' /var/run/xen-hotplug/block
+ rightfile=
+ '[' x = xy ']'
+ true
+ eval 'exec 200>>/var/run/xen-hotplug/block'
++ exec
+ flock -x 200
++ perl -e '
            open STDIN, "<&200" or die $!;
            my $fd_inum = (stat STDIN)[1]; die $! unless defined $fd_inum;
            my $file_inum = (stat $ARGV[0])[1];
            print "y\n" if $fd_inum eq $file_inum;
                             ' /var/run/xen-hotplug/block
+ rightfile=
+ '[' x = xy ']'
+ true
+ eval 'exec 200>>/var/run/xen-hotplug/block'
++ exec
+ flock -x 200
++ perl -e '
            open STDIN, "<&200" or die $!;
            my $fd_inum = (stat STDIN)[1]; die $! unless defined $fd_inum;
            my $file_inum = (stat $ARGV[0])[1];
            print "y\n" if $fd_inum eq $file_inum;
                             ' /var/run/xen-hotplug/block
+ rightfile=
+ '[' x = xy ']'
+ true
+ eval 'exec 200>>/var/run/xen-hotplug/block'
++ exec
+ flock -x 200
++ perl -e '
            open STDIN, "<&200" or die $!;
            my $fd_inum = (stat STDIN)[1]; die $! unless defined $fd_inum;
            my $file_inum = (stat $ARGV[0])[1];
            print "y\n" if $fd_inum eq $file_inum;
                             ' /var/run/xen-hotplug/block
+ rightfile=
+ '[' x = xy ']'
+ true
+ eval 'exec 200>>/var/run/xen-hotplug/block'
++ exec
+ flock -x 200
++ perl -e '
            open STDIN, "<&200" or die $!;
            my $fd_inum = (stat STDIN)[1]; die $! unless defined $fd_inum;
            my $file_inum = (stat $ARGV[0])[1];
            print "y\n" if $fd_inum eq $file_inum;
                             ' /var/run/xen-hotplug/block
+ rightfile=
+ '[' x = xy ']'
+ true
+ eval 'exec 200>>/var/run/xen-hotplug/block'
++ exec
+ flock -x 200
++ perl -e '
            open STDIN, "<&200" or die $!;
            my $fd_inum = (stat STDIN)[1]; die $! unless defined $fd_inum;
            my $file_inum = (stat $ARGV[0])[1];
            print "y\n" if $fd_inum eq $file_inum;
                             ' /var/run/xen-hotplug/block
+ rightfile=
+ '[' x = xy ']'
+ true
+ eval 'exec 200>>/var/run/xen-hotplug/block'
++ exec
+ flock -x 200
++ perl -e '
            open STDIN, "<&200" or die $!;
            my $fd_inum = (stat STDIN)[1]; die $! unless defined $fd_inum;
            my $file_inum = (stat $ARGV[0])[1];
            print "y\n" if $fd_inum eq $file_inum;
                             ' /var/run/xen-hotplug/block
+ rightfile=
+ '[' x = xy ']'
+ true
+ eval 'exec 200>>/var/run/xen-hotplug/block'
++ exec
+ flock -x 200
++ perl -e '
            open STDIN, "<&200" or die $!;
            my $fd_inum = (stat STDIN)[1]; die $! unless defined $fd_inum;
            my $file_inum = (stat $ARGV[0])[1];
            print "y\n" if $fd_inum eq $file_inum;
                             ' /var/run/xen-hotplug/block
+ rightfile=
+ '[' x = xy ']'
+ true
+ eval 'exec 200>>/var/run/xen-hotplug/block'
++ exec
+ flock -x 200
++ perl -e '
            open STDIN, "<&200" or die $!;
            my $fd_inum = (stat STDIN)[1]; die $! unless defined $fd_inum;
            my $file_inum = (stat $ARGV[0])[1];
            print "y\n" if $fd_inum eq $file_inum;
                             ' /var/run/xen-hotplug/block
+ rightfile=
+ '[' x = xy ']'
+ true
+ eval 'exec 200>>/var/run/xen-hotplug/block'
++ exec
+ flock -x 200
++ perl -e '
            open STDIN, "<&200" or die $!;
            my $fd_inum = (stat STDIN)[1]; die $! unless defined $fd_inum;
            my $file_inum = (stat $ARGV[0])[1];
            print "y\n" if $fd_inum eq $file_inum;
                             ' /var/run/xen-hotplug/block
+ rightfile=
+ '[' x = xy ']'
+ true
+ eval 'exec 200>>/var/run/xen-hotplug/block'
++ exec
+ flock -x 200
++ perl -e '
            open STDIN, "<&200" or die $!;
            my $fd_inum = (stat STDIN)[1]; die $! unless defined $fd_inum;
            my $file_inum = (stat $ARGV[0])[1];
            print "y\n" if $fd_inum eq $file_inum;
                             ' /var/run/xen-hotplug/block
+ rightfile=
+ '[' x = xy ']'
+ true
+ eval 'exec 200>>/var/run/xen-hotplug/block'
++ exec
+ flock -x 200
++ perl -e '
            open STDIN, "<&200" or die $!;
            my $fd_inum = (stat STDIN)[1]; die $! unless defined $fd_inum;
            my $file_inum = (stat $ARGV[0])[1];
            print "y\n" if $fd_inum eq $file_inum;
                             ' /var/run/xen-hotplug/block
+ rightfile=
+ '[' x = xy ']'
+ true
+ eval 'exec 200>>/var/run/xen-hotplug/block'
++ exec
+ flock -x 200
++ perl -e '
            open STDIN, "<&200" or die $!;
            my $fd_inum = (stat STDIN)[1]; die $! unless defined $fd_inum;
            my $file_inum = (stat $ARGV[0])[1];
            print "y\n" if $fd_inum eq $file_inum;
                             ' /var/run/xen-hotplug/block
+ rightfile=
+ '[' x = xy ']'
+ true
+ eval 'exec 200>>/var/run/xen-hotplug/block'
++ exec
+ flock -x 200
++ perl -e '
            open STDIN, "<&200" or die $!;
            my $fd_inum = (stat STDIN)[1]; die $! unless defined $fd_inum;
            my $file_inum = (stat $ARGV[0])[1];
            print "y\n" if $fd_inum eq $file_inum;
                             ' /var/run/xen-hotplug/block
+ rightfile=
+ '[' x = xy ']'
+ true
+ eval 'exec 200>>/var/run/xen-hotplug/block'
++ exec
+ flock -x 200
++ perl -e '
            open STDIN, "<&200" or die $!;
            my $fd_inum = (stat STDIN)[1]; die $! unless defined $fd_inum;
            my $file_inum = (stat $ARGV[0])[1];
            print "y\n" if $fd_inum eq $file_inum;
                             ' /var/run/xen-hotplug/block
+ rightfile=
+ '[' x = xy ']'
+ true
+ eval 'exec 200>>/var/run/xen-hotplug/block'
++ exec
+ flock -x 200
++ perl -e '
            open STDIN, "<&200" or die $!;
            my $fd_inum = (stat STDIN)[1]; die $! unless defined $fd_inum;
            my $file_inum = (stat $ARGV[0])[1];
            print "y\n" if $fd_inum eq $file_inum;
                             ' /var/run/xen-hotplug/block
+ rightfile=
+ '[' x = xy ']'
+ true
+ eval 'exec 200>>/var/run/xen-hotplug/block'
++ exec
+ flock -x 200
++ perl -e '
            open STDIN, "<&200" or die $!;
            my $fd_inum = (stat STDIN)[1]; die $! unless defined $fd_inum;
            my $file_inum = (stat $ARGV[0])[1];
            print "y\n" if $fd_inum eq $file_inum;
                             ' /var/run/xen-hotplug/block
+ rightfile=
+ '[' x = xy ']'
+ true
+ eval 'exec 200>>/var/run/xen-hotplug/block'
++ exec
+ flock -x 200
++ perl -e '
            open STDIN, "<&200" or die $!;
            my $fd_inum = (stat STDIN)[1]; die $! unless defined $fd_inum;
            my $file_inum = (stat $ARGV[0])[1];
            print "y\n" if $fd_inum eq $file_inum;
                             ' /var/run/xen-hotplug/block
+ rightfile=
+ '[' x = xy ']'
+ true
+ eval 'exec 200>>/var/run/xen-hotplug/block'
++ exec
+ flock -x 200
++ perl -e '
            open STDIN, "<&200" or die $!;
            my $fd_inum = (stat STDIN)[1]; die $! unless defined $fd_inum;
            my $file_inum = (stat $ARGV[0])[1];
            print "y\n" if $fd_inum eq $file_inum;
                             ' /var/run/xen-hotplug/block
+ rightfile=
+ '[' x = xy ']'
+ true
+ eval 'exec 200>>/var/run/xen-hotplug/block'
++ exec
+ flock -x 200
++ perl -e '
            open STDIN, "<&200" or die $!;
            my $fd_inum = (stat STDIN)[1]; die $! unless defined $fd_inum;
            my $file_inum = (stat $ARGV[0])[1];
            print "y\n" if $fd_inum eq $file_inum;
                             ' /var/run/xen-hotplug/block
+ rightfile=
+ '[' x = xy ']'
+ true
+ eval 'exec 200>>/var/run/xen-hotplug/block'
++ exec
+ flock -x 200
++ perl -e '
            open STDIN, "<&200" or die $!;
            my $fd_inum = (stat STDIN)[1]; die $! unless defined $fd_inum;
            my $file_inum = (stat $ARGV[0])[1];
            print "y\n" if $fd_inum eq $file_inum;
                             ' /var/run/xen-hotplug/block
+ rightfile=
+ '[' x = xy ']'
+ true
+ eval 'exec 200>>/var/run/xen-hotplug/block'
++ exec
+ flock -x 200
++ perl -e '
            open STDIN, "<&200" or die $!;
            my $fd_inum = (stat STDIN)[1]; die $! unless defined $fd_inum;
            my $file_inum = (stat $ARGV[0])[1];
            print "y\n" if $fd_inum eq $file_inum;
                             ' /var/run/xen-hotplug/block
+ rightfile=
+ '[' x = xy ']'
+ true
+ eval 'exec 200>>/var/run/xen-hotplug/block'
++ exec
+ flock -x 200
++ perl -e '
            open STDIN, "<&200" or die $!;
            my $fd_inum = (stat STDIN)[1]; die $! unless defined $fd_inum;
            my $file_inum = (stat $ARGV[0])[1];
            print "y\n" if $fd_inum eq $file_inum;
                             ' /var/run/xen-hotplug/block
+ rightfile=
+ '[' x = xy ']'
+ true
+ eval 'exec 200>>/var/run/xen-hotplug/block'
++ exec
+ flock -x 200
++ perl -e '
            open STDIN, "<&200" or die $!;
            my $fd_inum = (stat STDIN)[1]; die $! unless defined $fd_inum;
            my $file_inum = (stat $ARGV[0])[1];
            print "y\n" if $fd_inum eq $file_inum;
                             ' /var/run/xen-hotplug/block
+ rightfile=
+ '[' x = xy ']'
+ true
+ eval 'exec 200>>/var/run/xen-hotplug/block'
++ exec
+ flock -x 200
++ perl -e '
            open STDIN, "<&200" or die $!;
            my $fd_inum = (stat STDIN)[1]; die $! unless defined $fd_inum;
            my $file_inum = (stat $ARGV[0])[1];
            print "y\n" if $fd_inum eq $file_inum;
                             ' /var/run/xen-hotplug/block
+ rightfile=
+ '[' x = xy ']'
+ true
+ eval 'exec 200>>/var/run/xen-hotplug/block'
++ exec
+ flock -x 200
++ perl -e '
            open STDIN, "<&200" or die $!;
            my $fd_inum = (stat STDIN)[1]; die $! unless defined $fd_inum;
            my $file_inum = (stat $ARGV[0])[1];
            print "y\n" if $fd_inum eq $file_inum;
                             ' /var/run/xen-hotplug/block
+ rightfile=
+ '[' x = xy ']'
+ true
+ eval 'exec 200>>/var/run/xen-hotplug/block'
++ exec
+ flock -x 200
++ perl -e '
            open STDIN, "<&200" or die $!;
            my $fd_inum = (stat STDIN)[1]; die $! unless defined $fd_inum;
            my $file_inum = (stat $ARGV[0])[1];
            print "y\n" if $fd_inum eq $file_inum;
                             ' /var/run/xen-hotplug/block
+ rightfile=
+ '[' x = xy ']'
+ true
+ eval 'exec 200>>/var/run/xen-hotplug/block'
++ exec
+ flock -x 200
++ perl -e '
            open STDIN, "<&200" or die $!;
            my $fd_inum = (stat STDIN)[1]; die $! unless defined $fd_inum;
            my $file_inum = (stat $ARGV[0])[1];
            print "y\n" if $fd_inum eq $file_inum;
                             ' /var/run/xen-hotplug/block
+ rightfile=
+ '[' x = xy ']'
+ true
+ eval 'exec 200>>/var/run/xen-hotplug/block'
++ exec
+ flock -x 200
++ perl -e '
            open STDIN, "<&200" or die $!;
            my $fd_inum = (stat STDIN)[1]; die $! unless defined $fd_inum;
            my $file_inum = (stat $ARGV[0])[1];
            print "y\n" if $fd_inum eq $file_inum;
                             ' /var/run/xen-hotplug/block
+ rightfile=
+ '[' x = xy ']'
+ true
+ eval 'exec 200>>/var/run/xen-hotplug/block'
++ exec
+ flock -x 200
++ perl -e '
            open STDIN, "<&200" or die $!;
            my $fd_inum = (stat STDIN)[1]; die $! unless defined $fd_inum;
            my $file_inum = (stat $ARGV[0])[1];
            print "y\n" if $fd_inum eq $file_inum;
                             ' /var/run/xen-hotplug/block
+ rightfile=
+ '[' x = xy ']'
+ true
+ eval 'exec 200>>/var/run/xen-hotplug/block'
++ exec
+ flock -x 200
++ perl -e '
            open STDIN, "<&200" or die $!;
            my $fd_inum = (stat STDIN)[1]; die $! unless defined $fd_inum;
            my $file_inum = (stat $ARGV[0])[1];
            print "y\n" if $fd_inum eq $file_inum;
                             ' /var/run/xen-hotplug/block
+ rightfile=
+ '[' x = xy ']'
+ true
+ eval 'exec 200>>/var/run/xen-hotplug/block'
++ exec
+ flock -x 200
++ perl -e '
            open STDIN, "<&200" or die $!;
            my $fd_inum = (stat STDIN)[1]; die $! unless defined $fd_inum;
            my $file_inum = (stat $ARGV[0])[1];
            print "y\n" if $fd_inum eq $file_inum;
                             ' /var/run/xen-hotplug/block
+ rightfile=
+ '[' x = xy ']'
+ true
+ eval 'exec 200>>/var/run/xen-hotplug/block'
++ exec
+ flock -x 200
++ perl -e '
            open STDIN, "<&200" or die $!;
            my $fd_inum = (stat STDIN)[1]; die $! unless defined $fd_inum;
            my $file_inum = (stat $ARGV[0])[1];
            print "y\n" if $fd_inum eq $file_inum;
                             ' /var/run/xen-hotplug/block
+ rightfile=
+ '[' x = xy ']'
+ true
+ eval 'exec 200>>/var/run/xen-hotplug/block'
++ exec
+ flock -x 200
++ perl -e '
            open STDIN, "<&200" or die $!;
            my $fd_inum = (stat STDIN)[1]; die $! unless defined $fd_inum;
            my $file_inum = (stat $ARGV[0])[1];
            print "y\n" if $fd_inum eq $file_inum;
                             ' /var/run/xen-hotplug/block
+ rightfile=
+ '[' x = xy ']'
+ true
+ eval 'exec 200>>/var/run/xen-hotplug/block'
++ exec
+ flock -x 200
++ perl -e '
            open STDIN, "<&200" or die $!;
            my $fd_inum = (stat STDIN)[1]; die $! unless defined $fd_inum;
            my $file_inum = (stat $ARGV[0])[1];
            print "y\n" if $fd_inum eq $file_inum;
                             ' /var/run/xen-hotplug/block
+ rightfile=
+ '[' x = xy ']'
+ true
+ eval 'exec 200>>/var/run/xen-hotplug/block'
++ exec
+ flock -x 200
++ perl -e '
            open STDIN, "<&200" or die $!;
            my $fd_inum = (stat STDIN)[1]; die $! unless defined $fd_inum;
            my $file_inum = (stat $ARGV[0])[1];
            print "y\n" if $fd_inum eq $file_inum;
                             ' /var/run/xen-hotplug/block
+ rightfile=
+ '[' x = xy ']'
+ true
+ eval 'exec 200>>/var/run/xen-hotplug/block'
++ exec
+ flock -x 200
++ perl -e '
            open STDIN, "<&200" or die $!;
            my $fd_inum = (stat STDIN)[1]; die $! unless defined $fd_inum;
            my $file_inum = (stat $ARGV[0])[1];
            print "y\n" if $fd_inum eq $file_inum;
                             ' /var/run/xen-hotplug/block
+ rightfile=
+ '[' x = xy ']'
+ true
+ eval 'exec 200>>/var/run/xen-hotplug/block'
++ exec
+ flock -x 200
++ perl -e '
            open STDIN, "<&200" or die $!;
            my $fd_inum = (stat STDIN)[1]; die $! unless defined $fd_inum;
            my $file_inum = (stat $ARGV[0])[1];
            print "y\n" if $fd_inum eq $file_inum;
                             ' /var/run/xen-hotplug/block
+ rightfile=
+ '[' x = xy ']'
+ true
+ eval 'exec 200>>/var/run/xen-hotplug/block'
++ exec
+ flock -x 200
++ perl -e '
            open STDIN, "<&200" or die $!;
            my $fd_inum = (stat STDIN)[1]; die $! unless defined $fd_inum;
            my $file_inum = (stat $ARGV[0])[1];
            print "y\n" if $fd_inum eq $file_inum;
                             ' /var/run/xen-hotplug/block
+ rightfile=
+ '[' x = xy ']'
+ true
+ eval 'exec 200>>/var/run/xen-hotplug/block'
++ exec
+ flock -x 200
++ perl -e '
            open STDIN, "<&200" or die $!;
            my $fd_inum = (stat STDIN)[1]; die $! unless defined $fd_inum;
            my $file_inum = (stat $ARGV[0])[1];
            print "y\n" if $fd_inum eq $file_inum;
                             ' /var/run/xen-hotplug/block
+ rightfile=
+ '[' x = xy ']'
+ true
+ eval 'exec 200>>/var/run/xen-hotplug/block'
++ exec
+ flock -x 200
++ perl -e '
            open STDIN, "<&200" or die $!;
            my $fd_inum = (stat STDIN)[1]; die $! unless defined $fd_inum;
            my $file_inum = (stat $ARGV[0])[1];
            print "y\n" if $fd_inum eq $file_inum;
                             ' /var/run/xen-hotplug/block
+ rightfile=
+ '[' x = xy ']'
+ true
+ eval 'exec 200>>/var/run/xen-hotplug/block'
++ exec
+ flock -x 200
++ perl -e '
            open STDIN, "<&200" or die $!;
            my $fd_inum = (stat STDIN)[1]; die $! unless defined $fd_inum;
            my $file_inum = (stat $ARGV[0])[1];
            print "y\n" if $fd_inum eq $file_inum;
                             ' /var/run/xen-hotplug/block
+ rightfile=
+ '[' x = xy ']'
+ true
+ eval 'exec 200>>/var/run/xen-hotplug/block'
++ exec
+ flock -x 200
++ perl -e '
            open STDIN, "<&200" or die $!;
            my $fd_inum = (stat STDIN)[1]; die $! unless defined $fd_inum;
            my $file_inum = (stat $ARGV[0])[1];
            print "y\n" if $fd_inum eq $file_inum;
                             ' /var/run/xen-hotplug/block
+ rightfile=
+ '[' x = xy ']'
+ true
+ eval 'exec 200>>/var/run/xen-hotplug/block'
++ exec
+ flock -x 200
++ perl -e '
            open STDIN, "<&200" or die $!;
            my $fd_inum = (stat STDIN)[1]; die $! unless defined $fd_inum;
            my $file_inum = (stat $ARGV[0])[1];
            print "y\n" if $fd_inum eq $file_inum;
                             ' /var/run/xen-hotplug/block
+ rightfile=
+ '[' x = xy ']'
+ true
+ eval 'exec 200>>/var/run/xen-hotplug/block'
++ exec
+ flock -x 200
++ perl -e '
            open STDIN, "<&200" or die $!;
            my $fd_inum = (stat STDIN)[1]; die $! unless defined $fd_inum;
            my $file_inum = (stat $ARGV[0])[1];
            print "y\n" if $fd_inum eq $file_inum;
                             ' /var/run/xen-hotplug/block
+ rightfile=
+ '[' x = xy ']'
+ true
+ eval 'exec 200>>/var/run/xen-hotplug/block'
++ exec
+ flock -x 200
++ perl -e '
            open STDIN, "<&200" or die $!;
            my $fd_inum = (stat STDIN)[1]; die $! unless defined $fd_inum;
            my $file_inum = (stat $ARGV[0])[1];
            print "y\n" if $fd_inum eq $file_inum;
                             ' /var/run/xen-hotplug/block
+ rightfile=
+ '[' x = xy ']'
+ true
+ eval 'exec 200>>/var/run/xen-hotplug/block'
++ exec
+ flock -x 200
++ perl -e '
            open STDIN, "<&200" or die $!;
            my $fd_inum = (stat STDIN)[1]; die $! unless defined $fd_inum;
            my $file_inum = (stat $ARGV[0])[1];
            print "y\n" if $fd_inum eq $file_inum;
                             ' /var/run/xen-hotplug/block
+ rightfile=
+ '[' x = xy ']'
+ true
+ eval 'exec 200>>/var/run/xen-hotplug/block'
++ exec
+ flock -x 200
++ perl -e '
            open STDIN, "<&200" or die $!;
            my $fd_inum = (stat STDIN)[1]; die $! unless defined $fd_inum;
            my $file_inum = (stat $ARGV[0])[1];
            print "y\n" if $fd_inum eq $file_inum;
                             ' /var/run/xen-hotplug/block
+ rightfile=
+ '[' x = xy ']'
+ true
+ eval 'exec 200>>/var/run/xen-hotplug/block'
++ exec
+ flock -x 200
++ perl -e '
            open STDIN, "<&200" or die $!;
            my $fd_inum = (stat STDIN)[1]; die $! unless defined $fd_inum;
            my $file_inum = (stat $ARGV[0])[1];
            print "y\n" if $fd_inum eq $file_inum;
                             ' /var/run/xen-hotplug/block
+ rightfile=
+ '[' x = xy ']'
+ true
+ eval 'exec 200>>/var/run/xen-hotplug/block'
++ exec
+ flock -x 200
++ perl -e '
            open STDIN, "<&200" or die $!;
            my $fd_inum = (stat STDIN)[1]; die $! unless defined $fd_inum;
            my $file_inum = (stat $ARGV[0])[1];
            print "y\n" if $fd_inum eq $file_inum;
                             ' /var/run/xen-hotplug/block
+ rightfile=
+ '[' x = xy ']'
+ true
+ eval 'exec 200>>/var/run/xen-hotplug/block'
++ exec
+ flock -x 200
++ perl -e '
            open STDIN, "<&200" or die $!;
            my $fd_inum = (stat STDIN)[1]; die $! unless defined $fd_inum;
            my $file_inum = (stat $ARGV[0])[1];
            print "y\n" if $fd_inum eq $file_inum;
                             ' /var/run/xen-hotplug/block
+ rightfile=
+ '[' x = xy ']'
+ true
+ eval 'exec 200>>/var/run/xen-hotplug/block'
++ exec
+ flock -x 200
++ perl -e '
            open STDIN, "<&200" or die $!;
            my $fd_inum = (stat STDIN)[1]; die $! unless defined $fd_inum;
            my $file_inum = (stat $ARGV[0])[1];
            print "y\n" if $fd_inum eq $file_inum;
                             ' /var/run/xen-hotplug/block
+ rightfile=
+ '[' x = xy ']'
+ true
+ eval 'exec 200>>/var/run/xen-hotplug/block'
++ exec
+ flock -x 200
++ perl -e '
            open STDIN, "<&200" or die $!;
            my $fd_inum = (stat STDIN)[1]; die $! unless defined $fd_inum;
            my $file_inum = (stat $ARGV[0])[1];
            print "y\n" if $fd_inum eq $file_inum;
                             ' /var/run/xen-hotplug/block
+ rightfile=
+ '[' x = xy ']'
+ true
+ eval 'exec 200>>/var/run/xen-hotplug/block'
++ exec
+ flock -x 200
++ perl -e '
            open STDIN, "<&200" or die $!;
            my $fd_inum = (stat STDIN)[1]; die $! unless defined $fd_inum;
            my $file_inum = (stat $ARGV[0])[1];
            print "y\n" if $fd_inum eq $file_inum;
                             ' /var/run/xen-hotplug/block
+ rightfile=
+ '[' x = xy ']'
+ true
+ eval 'exec 200>>/var/run/xen-hotplug/block'
++ exec
+ flock -x 200
++ perl -e '
            open STDIN, "<&200" or die $!;
            my $fd_inum = (stat STDIN)[1]; die $! unless defined $fd_inum;
            my $file_inum = (stat $ARGV[0])[1];
            print "y\n" if $fd_inum eq $file_inum;
                             ' /var/run/xen-hotplug/block
+ rightfile=
+ '[' x = xy ']'
+ true
+ eval 'exec 200>>/var/run/xen-hotplug/block'
++ exec
+ flock -x 200
++ perl -e '
            open STDIN, "<&200" or die $!;
            my $fd_inum = (stat STDIN)[1]; die $! unless defined $fd_inum;
            my $file_inum = (stat $ARGV[0])[1];
            print "y\n" if $fd_inum eq $file_inum;
                             ' /var/run/xen-hotplug/block
+ rightfile=
+ '[' x = xy ']'
+ true
+ eval 'exec 200>>/var/run/xen-hotplug/block'
++ exec
+ flock -x 200
++ perl -e '
            open STDIN, "<&200" or die $!;
            my $fd_inum = (stat STDIN)[1]; die $! unless defined $fd_inum;
            my $file_inum = (stat $ARGV[0])[1];
[root@zhenzhong1 tmp]#

--------------090605080908040808080902
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--------------090605080908040808080902--


From xen-devel-bounces@lists.xen.org Fri Sep 28 15:03:51 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Sep 2012 15:03:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1THc6G-0006xQ-Fl; Fri, 28 Sep 2012 15:03:32 +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 1THc6F-0006xL-BC
	for xen-devel@lists.xen.org; Fri, 28 Sep 2012 15:03:31 +0000
Received: from [85.158.137.99:54790] by server-8.bemta-3.messagelabs.com id
	49/0E-16337-24CB5605; Fri, 28 Sep 2012 15:03:30 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-2.tower-217.messagelabs.com!1348844609!19412872!1
X-Originating-IP: [209.85.215.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27210 invoked from network); 28 Sep 2012 15:03:29 -0000
Received: from mail-ey0-f173.google.com (HELO mail-ey0-f173.google.com)
	(209.85.215.173)
	by server-2.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Sep 2012 15:03:29 -0000
Received: by eaaa1 with SMTP id a1so1152862eaa.32
	for <xen-devel@lists.xen.org>; Fri, 28 Sep 2012 08:03:28 -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=V9WW0RgnuQSUC6kHv0QrPhCjJWQF1GHu+99CiAMBIlY=;
	b=MZ6O91AY1jHPZc+IHMPqyG4R68SitYIlPOwU3vzvMrPWIqPiepuMIIpZhXyfxI6OJx
	AjXmBuhupZmElqnJSI6sxKIIXR2FGwelaqRUc/VplUKhfK2o8KBUTgTd1qREWTCYMFqc
	Cj5K/ZTJFVvE7pWYHxQw5lbg0mVrMDjShY88OjyEgajJOVSaw6nIEF6t40bRE1QGac+w
	cD83R4vOyQLq3Tx/ObnRryGJTkNHnC3ib8NO/mbeweA1zkYRhzEqd7C5PGM+w29/XExy
	ODJa7OpuEjqJh4aJUzKlTy5lBbJtcYSxs5SHuUDGwFjDmhym1eNf8skZv8AaIt5z1k/B
	wM5Q==
MIME-Version: 1.0
Received: by 10.14.212.72 with SMTP id x48mr10235167eeo.40.1348844608805; Fri,
	28 Sep 2012 08:03:28 -0700 (PDT)
Received: by 10.14.215.195 with HTTP; Fri, 28 Sep 2012 08:03:28 -0700 (PDT)
In-Reply-To: <1348765860-11359-3-git-send-email-matthew.fioravante@jhuapl.edu>
References: <1348765860-11359-1-git-send-email-matthew.fioravante@jhuapl.edu>
	<1348765860-11359-3-git-send-email-matthew.fioravante@jhuapl.edu>
Date: Fri, 28 Sep 2012 16:03:28 +0100
X-Google-Sender-Auth: DfHDV3rCi-J0h3sybLoVeW4_ABY
Message-ID: <CAFLBxZbvK0WxHhQgY79vCG21fd8b4i=vuVhtFjrpN-saXM61bA@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
Cc: Ian.Campbell@citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 11/11] add vtpm support to 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

On Thu, Sep 27, 2012 at 6:11 PM, Matthew Fioravante
<matthew.fioravante@jhuapl.edu> wrote:
> This patch adds vtpm support to libxl. It adds vtpm parsing to config
> files and 3 new xl commands:
> vtpm-attach
> vtpm-detach
> vtpm-list
>
> Signed-off-by: Matthew Fioravante <matthew.fioravante@jhuapl.edu>

Overall looks good to me -- just a few comments below about the config
file handling (see below).

Thanks for all your work on this.

> @@ -601,6 +605,8 @@ static void domcreate_bootloader_done(libxl__egc *egc,
>  static void domcreate_launch_dm(libxl__egc *egc, libxl__multidev *aodevs,
>                                  int ret);
>
> +static void domcreate_attach_vtpms(libxl__egc *egc, libxl__multidev *multidev,
> +                                   int ret);
>  static void domcreate_attach_pci(libxl__egc *egc, libxl__multidev *aodevs,
>                                   int ret);
>
> @@ -1084,13 +1090,13 @@ static void domcreate_devmodel_started(libxl__egc *egc,
>      if (d_config->num_nics > 0) {
>          /* Attach nics */
>          libxl__multidev_begin(ao, &dcs->multidev);
> -        dcs->multidev.callback = domcreate_attach_pci;
> +        dcs->multidev.callback = domcreate_attach_vtpms;

Wow -- what a weird convention you've had to try to figure out and
modify here.  Well done. :-)

>          libxl__add_nics(egc, ao, domid, d_config, &dcs->multidev);
>          libxl__multidev_prepared(egc, &dcs->multidev, 0);
>          return;
>      }
>
> -    domcreate_attach_pci(egc, &dcs->multidev, 0);
> +    domcreate_attach_vtpms(egc, &dcs->multidev, 0);
>      return;
>
>  error_out:
> @@ -1098,6 +1104,36 @@ error_out:
>      domcreate_complete(egc, dcs, ret);
>  }
>
> +static void domcreate_attach_vtpms(libxl__egc *egc, libxl__multidev *multidev, int ret) {
> +   libxl__domain_create_state *dcs = CONTAINER_OF(multidev, *dcs, multidev);
> +   STATE_AO_GC(dcs->ao);
> +   int domid = dcs->guest_domid;
> +
> +   libxl_domain_config* const d_config = dcs->guest_config;
> +
> +   if(ret) {
> +      LOG(ERROR, "unable to add nic devices");
> +      goto error_out;
> +   }
> +
> +    /* Plug vtpm devices */
> +    if (d_config->num_vtpms > 0) {
> +        /* Attach vtpms */
> +        libxl__multidev_begin(ao, &dcs->multidev);
> +        dcs->multidev.callback = domcreate_attach_pci;
> +        libxl__add_vtpms(egc, ao, domid, d_config, &dcs->multidev);
> +        libxl__multidev_prepared(egc, &dcs->multidev, 0);
> +        return;
> +    }
> +
> +   domcreate_attach_pci(egc, multidev, 0);
> +   return;
> +
> +error_out:
> +   assert(ret);
> +   domcreate_complete(egc, dcs, ret);
> +}
> +
>  static void domcreate_attach_pci(libxl__egc *egc, libxl__multidev *multidev,
>                                   int ret)
>  {
> @@ -1111,7 +1147,7 @@ static void domcreate_attach_pci(libxl__egc *egc, libxl__multidev *multidev,
>      libxl_domain_config *const d_config = dcs->guest_config;
>
>      if (ret) {
> -        LOG(ERROR, "unable to add nic devices");
> +        LOG(ERROR, "unable to add vtpm devices");
>          goto error_out;
>      }
>
[snip]
> @@ -1045,6 +1045,47 @@ static void parse_config_data(const char *config_source,
>          }
>      }
>
> +    if (!xlu_cfg_get_list(config, "vtpm", &vtpms, 0, 0)) {
> +        d_config->num_vtpms = 0;
> +        d_config->vtpms = NULL;
> +        while ((buf = xlu_cfg_get_listitem (vtpms, d_config->num_vtpms)) != NULL) {
> +            libxl_device_vtpm *vtpm;
> +            char * buf2 = strdup(buf);
> +            char *p, *p2;
> +
> +            d_config->vtpms = (libxl_device_vtpm *) realloc(d_config->vtpms, sizeof(libxl_device_vtpm) * (d_config->num_vtpms+1));
> +            vtpm = d_config->vtpms + d_config->num_vtpms;
> +            libxl_device_vtpm_init(vtpm);
> +            vtpm->devid = d_config->num_vtpms;
> +
> +            p = strtok(buf2, ",");
> +            if (!p)
> +                goto skip_vtpm;

Is the purpose of this so that you can have "empty" vtpm slots?
(Since even when skipping, you still increment the num_vtpms counter?)

> +            do {
> +                while(*p == ' ')
> +                    ++p;
> +                if ((p2 = strchr(p, '=')) == NULL)
> +                    break;
> +                *p2 = '\0';
> +                if (!strcmp(p, "backend")) {
> +                    if(domain_qualifier_to_domid(p2 + 1, &(vtpm->backend_domid), 0))
> +                    {
> +                        fprintf(stderr, "Specified backend domain does not exist, defaulting to Dom0\n");
> +                        vtpm->backend_domid = 0;

So wait; if someone specifies a domain, and that turns out not to
work, you just change it to 0?  It seems like if the *specified*
domain doesn't exist, the command should fail instead of choosing
something at random.

> +                    }
> +                } else if(!strcmp(p, "uuid")) {
> +                    if( libxl_uuid_from_string(&vtpm->uuid, p2 + 1) ) {
> +                        fprintf(stderr, "Failed to parse vtpm UUID: %s\n", p2 + 1);
> +                        exit(1);
> +                    }
> +                }

If I'm parsing this right, it looks like you will just silently ignore
other arguments -- it seems like throwing an error would be better;
especially to catch things like typos.  Otherwise, if someone does
something like "uid=[whatever]", it will act like uuid isn't there and
create a new one, instead of alerting the user to the fact that he'd
made a typo in the config file.

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 28 15:03:51 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Sep 2012 15:03:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1THc6G-0006xQ-Fl; Fri, 28 Sep 2012 15:03:32 +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 1THc6F-0006xL-BC
	for xen-devel@lists.xen.org; Fri, 28 Sep 2012 15:03:31 +0000
Received: from [85.158.137.99:54790] by server-8.bemta-3.messagelabs.com id
	49/0E-16337-24CB5605; Fri, 28 Sep 2012 15:03:30 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-2.tower-217.messagelabs.com!1348844609!19412872!1
X-Originating-IP: [209.85.215.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27210 invoked from network); 28 Sep 2012 15:03:29 -0000
Received: from mail-ey0-f173.google.com (HELO mail-ey0-f173.google.com)
	(209.85.215.173)
	by server-2.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Sep 2012 15:03:29 -0000
Received: by eaaa1 with SMTP id a1so1152862eaa.32
	for <xen-devel@lists.xen.org>; Fri, 28 Sep 2012 08:03:28 -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=V9WW0RgnuQSUC6kHv0QrPhCjJWQF1GHu+99CiAMBIlY=;
	b=MZ6O91AY1jHPZc+IHMPqyG4R68SitYIlPOwU3vzvMrPWIqPiepuMIIpZhXyfxI6OJx
	AjXmBuhupZmElqnJSI6sxKIIXR2FGwelaqRUc/VplUKhfK2o8KBUTgTd1qREWTCYMFqc
	Cj5K/ZTJFVvE7pWYHxQw5lbg0mVrMDjShY88OjyEgajJOVSaw6nIEF6t40bRE1QGac+w
	cD83R4vOyQLq3Tx/ObnRryGJTkNHnC3ib8NO/mbeweA1zkYRhzEqd7C5PGM+w29/XExy
	ODJa7OpuEjqJh4aJUzKlTy5lBbJtcYSxs5SHuUDGwFjDmhym1eNf8skZv8AaIt5z1k/B
	wM5Q==
MIME-Version: 1.0
Received: by 10.14.212.72 with SMTP id x48mr10235167eeo.40.1348844608805; Fri,
	28 Sep 2012 08:03:28 -0700 (PDT)
Received: by 10.14.215.195 with HTTP; Fri, 28 Sep 2012 08:03:28 -0700 (PDT)
In-Reply-To: <1348765860-11359-3-git-send-email-matthew.fioravante@jhuapl.edu>
References: <1348765860-11359-1-git-send-email-matthew.fioravante@jhuapl.edu>
	<1348765860-11359-3-git-send-email-matthew.fioravante@jhuapl.edu>
Date: Fri, 28 Sep 2012 16:03:28 +0100
X-Google-Sender-Auth: DfHDV3rCi-J0h3sybLoVeW4_ABY
Message-ID: <CAFLBxZbvK0WxHhQgY79vCG21fd8b4i=vuVhtFjrpN-saXM61bA@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
Cc: Ian.Campbell@citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 11/11] add vtpm support to 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

On Thu, Sep 27, 2012 at 6:11 PM, Matthew Fioravante
<matthew.fioravante@jhuapl.edu> wrote:
> This patch adds vtpm support to libxl. It adds vtpm parsing to config
> files and 3 new xl commands:
> vtpm-attach
> vtpm-detach
> vtpm-list
>
> Signed-off-by: Matthew Fioravante <matthew.fioravante@jhuapl.edu>

Overall looks good to me -- just a few comments below about the config
file handling (see below).

Thanks for all your work on this.

> @@ -601,6 +605,8 @@ static void domcreate_bootloader_done(libxl__egc *egc,
>  static void domcreate_launch_dm(libxl__egc *egc, libxl__multidev *aodevs,
>                                  int ret);
>
> +static void domcreate_attach_vtpms(libxl__egc *egc, libxl__multidev *multidev,
> +                                   int ret);
>  static void domcreate_attach_pci(libxl__egc *egc, libxl__multidev *aodevs,
>                                   int ret);
>
> @@ -1084,13 +1090,13 @@ static void domcreate_devmodel_started(libxl__egc *egc,
>      if (d_config->num_nics > 0) {
>          /* Attach nics */
>          libxl__multidev_begin(ao, &dcs->multidev);
> -        dcs->multidev.callback = domcreate_attach_pci;
> +        dcs->multidev.callback = domcreate_attach_vtpms;

Wow -- what a weird convention you've had to try to figure out and
modify here.  Well done. :-)

>          libxl__add_nics(egc, ao, domid, d_config, &dcs->multidev);
>          libxl__multidev_prepared(egc, &dcs->multidev, 0);
>          return;
>      }
>
> -    domcreate_attach_pci(egc, &dcs->multidev, 0);
> +    domcreate_attach_vtpms(egc, &dcs->multidev, 0);
>      return;
>
>  error_out:
> @@ -1098,6 +1104,36 @@ error_out:
>      domcreate_complete(egc, dcs, ret);
>  }
>
> +static void domcreate_attach_vtpms(libxl__egc *egc, libxl__multidev *multidev, int ret) {
> +   libxl__domain_create_state *dcs = CONTAINER_OF(multidev, *dcs, multidev);
> +   STATE_AO_GC(dcs->ao);
> +   int domid = dcs->guest_domid;
> +
> +   libxl_domain_config* const d_config = dcs->guest_config;
> +
> +   if(ret) {
> +      LOG(ERROR, "unable to add nic devices");
> +      goto error_out;
> +   }
> +
> +    /* Plug vtpm devices */
> +    if (d_config->num_vtpms > 0) {
> +        /* Attach vtpms */
> +        libxl__multidev_begin(ao, &dcs->multidev);
> +        dcs->multidev.callback = domcreate_attach_pci;
> +        libxl__add_vtpms(egc, ao, domid, d_config, &dcs->multidev);
> +        libxl__multidev_prepared(egc, &dcs->multidev, 0);
> +        return;
> +    }
> +
> +   domcreate_attach_pci(egc, multidev, 0);
> +   return;
> +
> +error_out:
> +   assert(ret);
> +   domcreate_complete(egc, dcs, ret);
> +}
> +
>  static void domcreate_attach_pci(libxl__egc *egc, libxl__multidev *multidev,
>                                   int ret)
>  {
> @@ -1111,7 +1147,7 @@ static void domcreate_attach_pci(libxl__egc *egc, libxl__multidev *multidev,
>      libxl_domain_config *const d_config = dcs->guest_config;
>
>      if (ret) {
> -        LOG(ERROR, "unable to add nic devices");
> +        LOG(ERROR, "unable to add vtpm devices");
>          goto error_out;
>      }
>
[snip]
> @@ -1045,6 +1045,47 @@ static void parse_config_data(const char *config_source,
>          }
>      }
>
> +    if (!xlu_cfg_get_list(config, "vtpm", &vtpms, 0, 0)) {
> +        d_config->num_vtpms = 0;
> +        d_config->vtpms = NULL;
> +        while ((buf = xlu_cfg_get_listitem (vtpms, d_config->num_vtpms)) != NULL) {
> +            libxl_device_vtpm *vtpm;
> +            char * buf2 = strdup(buf);
> +            char *p, *p2;
> +
> +            d_config->vtpms = (libxl_device_vtpm *) realloc(d_config->vtpms, sizeof(libxl_device_vtpm) * (d_config->num_vtpms+1));
> +            vtpm = d_config->vtpms + d_config->num_vtpms;
> +            libxl_device_vtpm_init(vtpm);
> +            vtpm->devid = d_config->num_vtpms;
> +
> +            p = strtok(buf2, ",");
> +            if (!p)
> +                goto skip_vtpm;

Is the purpose of this so that you can have "empty" vtpm slots?
(Since even when skipping, you still increment the num_vtpms counter?)

> +            do {
> +                while(*p == ' ')
> +                    ++p;
> +                if ((p2 = strchr(p, '=')) == NULL)
> +                    break;
> +                *p2 = '\0';
> +                if (!strcmp(p, "backend")) {
> +                    if(domain_qualifier_to_domid(p2 + 1, &(vtpm->backend_domid), 0))
> +                    {
> +                        fprintf(stderr, "Specified backend domain does not exist, defaulting to Dom0\n");
> +                        vtpm->backend_domid = 0;

So wait; if someone specifies a domain, and that turns out not to
work, you just change it to 0?  It seems like if the *specified*
domain doesn't exist, the command should fail instead of choosing
something at random.

> +                    }
> +                } else if(!strcmp(p, "uuid")) {
> +                    if( libxl_uuid_from_string(&vtpm->uuid, p2 + 1) ) {
> +                        fprintf(stderr, "Failed to parse vtpm UUID: %s\n", p2 + 1);
> +                        exit(1);
> +                    }
> +                }

If I'm parsing this right, it looks like you will just silently ignore
other arguments -- it seems like throwing an error would be better;
especially to catch things like typos.  Otherwise, if someone does
something like "uid=[whatever]", it will act like uuid isn't there and
create a new one, instead of alerting the user to the fact that he'd
made a typo in the config file.

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 28 15:07:18 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Sep 2012 15: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 1THc9a-00074S-7c; Fri, 28 Sep 2012 15:06:58 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1THc9Z-00074N-ES
	for xen-devel@lists.xensource.com; Fri, 28 Sep 2012 15:06:57 +0000
Received: from [85.158.139.211:41626] by server-2.bemta-5.messagelabs.com id
	A7/51-28944-01DB5605; Fri, 28 Sep 2012 15:06:56 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-206.messagelabs.com!1348844815!20324459!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTIyOTk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2539 invoked from network); 28 Sep 2012 15:06:55 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Sep 2012 15:06:55 -0000
X-IronPort-AV: E=Sophos;i="4.80,502,1344211200"; d="scan'208";a="14836934"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Sep 2012 15:06: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.279.1; Fri, 28 Sep 2012 16:06: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 1THc9H-00024c-C9;
	Fri, 28 Sep 2012 15:06:39 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1THc9H-00067m-0n;
	Fri, 28 Sep 2012 16:06:39 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-13901-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 28 Sep 2012 16:06:39 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13901: 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 13901 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13901/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf      5 xen-boot                  fail REGR. vs. 13900
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore            fail   like 13900
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail like 13900
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail like 13900

Tests which did not succeed, but are not blocking:
 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-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  bd953fda6106
baseline version:
 xen                  6bf8b882df8f

------------------------------------------------------------
People who touched revisions under test:
  Ben Guthro <ben@guthro.net>
  Jan Beulich <jbeulich@suse.com>
  Keir Fraser <keir@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-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-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-amd64-amd64-xl-win                                      fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=xen-unstable
+ revision=bd953fda6106
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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 bd953fda6106
+ branch=xen-unstable
+ revision=bd953fda6106
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-unstable
+ '[' xxen = xlinux ']'
+ linuxbranch=linux
+ : master
+ : tested/2.6.39.x
+ . ap-common
++ : xen@xenbits.xensource.com
++ : http://xenbits.xen.org/hg/staging/xen-unstable.hg
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : xen@xenbits.xensource.com:git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.xen-unstable
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-unstable.git
++ : daily-cron.xen-unstable
+ TREE_LINUX=xen@xenbits.xensource.com:git/linux-pvops.git
+ TREE_QEMU_UPSTREAM=xen@xenbits.xensource.com:git/qemu-upstream-unstable.git
+ info_linux_tree xen-unstable
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/xen-unstable.hg
+ hg push -r bd953fda6106 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 11 changes to 10 files

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 28 15:07:18 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Sep 2012 15: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 1THc9a-00074S-7c; Fri, 28 Sep 2012 15:06:58 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1THc9Z-00074N-ES
	for xen-devel@lists.xensource.com; Fri, 28 Sep 2012 15:06:57 +0000
Received: from [85.158.139.211:41626] by server-2.bemta-5.messagelabs.com id
	A7/51-28944-01DB5605; Fri, 28 Sep 2012 15:06:56 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-206.messagelabs.com!1348844815!20324459!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTIyOTk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2539 invoked from network); 28 Sep 2012 15:06:55 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Sep 2012 15:06:55 -0000
X-IronPort-AV: E=Sophos;i="4.80,502,1344211200"; d="scan'208";a="14836934"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Sep 2012 15:06: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.279.1; Fri, 28 Sep 2012 16:06: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 1THc9H-00024c-C9;
	Fri, 28 Sep 2012 15:06:39 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1THc9H-00067m-0n;
	Fri, 28 Sep 2012 16:06:39 +0100
To: xen-devel@lists.xensource.com
Message-ID: <osstest-13901-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 28 Sep 2012 16:06:39 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13901: 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 13901 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13901/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf      5 xen-boot                  fail REGR. vs. 13900
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore            fail   like 13900
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail like 13900
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail like 13900

Tests which did not succeed, but are not blocking:
 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-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  bd953fda6106
baseline version:
 xen                  6bf8b882df8f

------------------------------------------------------------
People who touched revisions under test:
  Ben Guthro <ben@guthro.net>
  Jan Beulich <jbeulich@suse.com>
  Keir Fraser <keir@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-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-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-amd64-amd64-xl-win                                      fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=xen-unstable
+ revision=bd953fda6106
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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 bd953fda6106
+ branch=xen-unstable
+ revision=bd953fda6106
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-unstable
+ '[' xxen = xlinux ']'
+ linuxbranch=linux
+ : master
+ : tested/2.6.39.x
+ . ap-common
++ : xen@xenbits.xensource.com
++ : http://xenbits.xen.org/hg/staging/xen-unstable.hg
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : xen@xenbits.xensource.com:git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.xen-unstable
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-unstable.git
++ : daily-cron.xen-unstable
+ TREE_LINUX=xen@xenbits.xensource.com:git/linux-pvops.git
+ TREE_QEMU_UPSTREAM=xen@xenbits.xensource.com:git/qemu-upstream-unstable.git
+ info_linux_tree xen-unstable
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/xen-unstable.hg
+ hg push -r bd953fda6106 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 11 changes to 10 files

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 28 15:07:36 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Sep 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 1THc9x-00076f-OT; Fri, 28 Sep 2012 15:07:21 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dunlapg@gmail.com>) id 1THc9v-00075e-UI
	for xen-devel@lists.xen.org; Fri, 28 Sep 2012 15:07:20 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1348844833!9040028!1
X-Originating-IP: [209.85.215.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11812 invoked from network); 28 Sep 2012 15:07:13 -0000
Received: from mail-ey0-f173.google.com (HELO mail-ey0-f173.google.com)
	(209.85.215.173)
	by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Sep 2012 15:07:13 -0000
Received: by eaaa1 with SMTP id a1so1154252eaa.32
	for <xen-devel@lists.xen.org>; Fri, 28 Sep 2012 08:07:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
	bh=i3taPRvFWhTy6LfarmEJPhPQhZWPkxqPFpOBAf7TGNE=;
	b=ET0+bfUGKhD6lUPS1rp1VSkiwRYamWAcgKnv1otrQd7YiQjYRAtIe7yR5uT87XnpjP
	x3zkh1B39/A0j7KZh0onArb/tuSz/nl7sYqAdni68zWWrX6XYJCa+pOyITkQZiohZm2V
	Ak73qYGZe8XoxcFTgUgyQ6J/NqsObc7ZZ3lkXHSpzOsOWka/nOEyrvmP66np8quQAWwG
	BmrwqAosXJ11kgxYY3jWFiijT0mflxzD8HSLQwzUVgtW6UKLfqpno82J3nAqIBSCxAbl
	cAUID8jQ4gSrTKIMqOkssCyIne/IomGUJNnCYhCDVzXOKzkvXRXUuuoKVTq5qXJzcOXd
	CjQg==
MIME-Version: 1.0
Received: by 10.14.204.72 with SMTP id g48mr10357864eeo.45.1348844833190; Fri,
	28 Sep 2012 08:07:13 -0700 (PDT)
Received: by 10.14.215.195 with HTTP; Fri, 28 Sep 2012 08:07:13 -0700 (PDT)
In-Reply-To: <1348765860-11359-1-git-send-email-matthew.fioravante@jhuapl.edu>
References: <1348765860-11359-1-git-send-email-matthew.fioravante@jhuapl.edu>
Date: Fri, 28 Sep 2012 16:07:13 +0100
X-Google-Sender-Auth: 2gWWhaTPxnA1CVi1FY6XeeE6vIM
Message-ID: <CAFLBxZYQHFVC6BMg+8mHJ9Zr=9MMvOxOdn9FnWc3QX1Wvux6-A@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
Cc: Ian.Campbell@citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 09/11] add iomem support to 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

On Thu, Sep 27, 2012 at 6:10 PM, Matthew Fioravante
<matthew.fioravante@jhuapl.edu> wrote:
> This patch adds a new option for xen config files for
> directly mapping hardware io memory into a vm.
>
> Signed-off-by: Matthew Fioravante <matthew.fioravante@jhuapl.edu>

Looks good to me.

Reviewed-by: George Dunlap <george.dunlap@eu.citrix.com>

>
> diff --git a/docs/man/xl.cfg.pod.5 b/docs/man/xl.cfg.pod.5
> index 013270d..428da21 100644
> --- a/docs/man/xl.cfg.pod.5
> +++ b/docs/man/xl.cfg.pod.5
> @@ -496,6 +496,17 @@ is given in hexadecimal and may either a span e.g. C<2f8-2ff>
>  It is recommended to use this option only for trusted VMs under
>  administrator control.
>
> +=item B<iomem=[ "IOMEM_START,NUM_PAGES", "IOMEM_START,NUM_PAGES", ... ]>
> +
> +Allow guest to access specific hardware I/O memory pages. B<IOMEM_START>
> +is a physical page number. B<NUM_PAGES> is the number
> +of pages beginning with B<START_PAGE> to allow access. Both values
> +must be given in hexadecimal.
> +
> +It is recommended to use this option only for trusted VMs under
> +administrator control.
> +
> +
>  =item B<irqs=[ NUMBER, NUMBER, ... ]>
>
>  Allow a guest to access specific physical IRQs.
> diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
> index ef17f05..6cb586b 100644
> --- a/tools/libxl/libxl_create.c
> +++ b/tools/libxl/libxl_create.c
> @@ -963,6 +963,24 @@ static void domcreate_launch_dm(libxl__egc *egc, libxl__multidev *multidev,
>          }
>      }
>
> +    for (i = 0; i < d_config->b_info.num_iomem; i++) {
> +        libxl_iomem_range *io = &d_config->b_info.iomem[i];
> +
> +        LOG(DEBUG, "dom%d iomem %"PRIx64"-%"PRIx64,
> +            domid, io->start, io->start + io->number - 1);
> +
> +        ret = xc_domain_iomem_permission(CTX->xch, domid,
> +                                          io->start, io->number, 1);
> +        if ( ret<0 ) {
> +            LOGE(ERROR,
> +                 "failed give dom%d access to iomem range %"PRIx64"-%"PRIx64,
> +                 domid, io->start, io->start + io->number - 1);
> +            ret = ERROR_FAIL;
> +        }
> +    }
> +
> +
> +
>      for (i = 0; i < d_config->num_nics; i++) {
>          /* We have to init the nic here, because we still haven't
>           * called libxl_device_nic_add at this point, but qemu needs
> diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
> index 6d5c578..cf83c60 100644
> --- a/tools/libxl/libxl_types.idl
> +++ b/tools/libxl/libxl_types.idl
> @@ -140,6 +140,11 @@ libxl_ioport_range = Struct("ioport_range", [
>      ("number", uint32),
>      ])
>
> +libxl_iomem_range = Struct("iomem_range", [
> +    ("start", uint64),
> +    ("number", uint64),
> +    ])
> +
>  libxl_vga_interface_info = Struct("vga_interface_info", [
>      ("kind",    libxl_vga_interface_type),
>      ])
> @@ -284,6 +289,7 @@ libxl_domain_build_info = Struct("domain_build_info",[
>
>      ("ioports",          Array(libxl_ioport_range, "num_ioports")),
>      ("irqs",             Array(uint32, "num_irqs")),
> +    ("iomem",            Array(libxl_iomem_range, "num_iomem")),
>
>      ("u", KeyedUnion(None, libxl_domain_type, "type",
>                  [("hvm", Struct(None, [("firmware",         string),
> diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
> index 1627cac..fe8e925 100644
> --- a/tools/libxl/xl_cmdimpl.c
> +++ b/tools/libxl/xl_cmdimpl.c
> @@ -574,8 +574,8 @@ static void parse_config_data(const char *config_source,
>      long l;
>      XLU_Config *config;
>      XLU_ConfigList *cpus, *vbds, *nics, *pcis, *cvfbs, *cpuids;
> -    XLU_ConfigList *ioports, *irqs;
> -    int num_ioports, num_irqs;
> +    XLU_ConfigList *ioports, *irqs, *iomem;
> +    int num_ioports, num_irqs, num_iomem;
>      int pci_power_mgmt = 0;
>      int pci_msitranslate = 0;
>      int pci_permissive = 0;
> @@ -1005,6 +1005,30 @@ static void parse_config_data(const char *config_source,
>          }
>      }
>
> +    if (!xlu_cfg_get_list(config, "iomem", &iomem, &num_iomem, 0)) {
> +        b_info->num_iomem = num_iomem;
> +        b_info->iomem = calloc(num_iomem, sizeof(*b_info->iomem));
> +        if (b_info->iomem == NULL) {
> +            fprintf(stderr, "unable to allocate memory for iomem\n");
> +            exit(-1);
> +        }
> +        for (i = 0; i < num_iomem; i++) {
> +            buf = xlu_cfg_get_listitem (iomem, i);
> +            if (!buf) {
> +                fprintf(stderr,
> +                        "xl: Unable to get element %d in iomem list\n", i);
> +                exit(1);
> +            }
> +            if(sscanf(buf, "%" SCNx64",%" SCNx64, &b_info->iomem[i].start, &b_info->iomem[i].number) != 2) {
> +               fprintf(stderr,
> +                       "xl: Invalid argument parsing iomem: %s\n", buf);
> +               exit(1);
> +            }
> +        }
> +    }
> +
> +
> +
>      if (!xlu_cfg_get_list (config, "disk", &vbds, 0, 0)) {
>          d_config->num_disks = 0;
>          d_config->disks = NULL;
> --
> 1.7.9.5
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 28 15:07:36 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Sep 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 1THc9x-00076f-OT; Fri, 28 Sep 2012 15:07:21 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dunlapg@gmail.com>) id 1THc9v-00075e-UI
	for xen-devel@lists.xen.org; Fri, 28 Sep 2012 15:07:20 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1348844833!9040028!1
X-Originating-IP: [209.85.215.173]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11812 invoked from network); 28 Sep 2012 15:07:13 -0000
Received: from mail-ey0-f173.google.com (HELO mail-ey0-f173.google.com)
	(209.85.215.173)
	by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Sep 2012 15:07:13 -0000
Received: by eaaa1 with SMTP id a1so1154252eaa.32
	for <xen-devel@lists.xen.org>; Fri, 28 Sep 2012 08:07:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
	bh=i3taPRvFWhTy6LfarmEJPhPQhZWPkxqPFpOBAf7TGNE=;
	b=ET0+bfUGKhD6lUPS1rp1VSkiwRYamWAcgKnv1otrQd7YiQjYRAtIe7yR5uT87XnpjP
	x3zkh1B39/A0j7KZh0onArb/tuSz/nl7sYqAdni68zWWrX6XYJCa+pOyITkQZiohZm2V
	Ak73qYGZe8XoxcFTgUgyQ6J/NqsObc7ZZ3lkXHSpzOsOWka/nOEyrvmP66np8quQAWwG
	BmrwqAosXJ11kgxYY3jWFiijT0mflxzD8HSLQwzUVgtW6UKLfqpno82J3nAqIBSCxAbl
	cAUID8jQ4gSrTKIMqOkssCyIne/IomGUJNnCYhCDVzXOKzkvXRXUuuoKVTq5qXJzcOXd
	CjQg==
MIME-Version: 1.0
Received: by 10.14.204.72 with SMTP id g48mr10357864eeo.45.1348844833190; Fri,
	28 Sep 2012 08:07:13 -0700 (PDT)
Received: by 10.14.215.195 with HTTP; Fri, 28 Sep 2012 08:07:13 -0700 (PDT)
In-Reply-To: <1348765860-11359-1-git-send-email-matthew.fioravante@jhuapl.edu>
References: <1348765860-11359-1-git-send-email-matthew.fioravante@jhuapl.edu>
Date: Fri, 28 Sep 2012 16:07:13 +0100
X-Google-Sender-Auth: 2gWWhaTPxnA1CVi1FY6XeeE6vIM
Message-ID: <CAFLBxZYQHFVC6BMg+8mHJ9Zr=9MMvOxOdn9FnWc3QX1Wvux6-A@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
Cc: Ian.Campbell@citrix.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 09/11] add iomem support to 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

On Thu, Sep 27, 2012 at 6:10 PM, Matthew Fioravante
<matthew.fioravante@jhuapl.edu> wrote:
> This patch adds a new option for xen config files for
> directly mapping hardware io memory into a vm.
>
> Signed-off-by: Matthew Fioravante <matthew.fioravante@jhuapl.edu>

Looks good to me.

Reviewed-by: George Dunlap <george.dunlap@eu.citrix.com>

>
> diff --git a/docs/man/xl.cfg.pod.5 b/docs/man/xl.cfg.pod.5
> index 013270d..428da21 100644
> --- a/docs/man/xl.cfg.pod.5
> +++ b/docs/man/xl.cfg.pod.5
> @@ -496,6 +496,17 @@ is given in hexadecimal and may either a span e.g. C<2f8-2ff>
>  It is recommended to use this option only for trusted VMs under
>  administrator control.
>
> +=item B<iomem=[ "IOMEM_START,NUM_PAGES", "IOMEM_START,NUM_PAGES", ... ]>
> +
> +Allow guest to access specific hardware I/O memory pages. B<IOMEM_START>
> +is a physical page number. B<NUM_PAGES> is the number
> +of pages beginning with B<START_PAGE> to allow access. Both values
> +must be given in hexadecimal.
> +
> +It is recommended to use this option only for trusted VMs under
> +administrator control.
> +
> +
>  =item B<irqs=[ NUMBER, NUMBER, ... ]>
>
>  Allow a guest to access specific physical IRQs.
> diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
> index ef17f05..6cb586b 100644
> --- a/tools/libxl/libxl_create.c
> +++ b/tools/libxl/libxl_create.c
> @@ -963,6 +963,24 @@ static void domcreate_launch_dm(libxl__egc *egc, libxl__multidev *multidev,
>          }
>      }
>
> +    for (i = 0; i < d_config->b_info.num_iomem; i++) {
> +        libxl_iomem_range *io = &d_config->b_info.iomem[i];
> +
> +        LOG(DEBUG, "dom%d iomem %"PRIx64"-%"PRIx64,
> +            domid, io->start, io->start + io->number - 1);
> +
> +        ret = xc_domain_iomem_permission(CTX->xch, domid,
> +                                          io->start, io->number, 1);
> +        if ( ret<0 ) {
> +            LOGE(ERROR,
> +                 "failed give dom%d access to iomem range %"PRIx64"-%"PRIx64,
> +                 domid, io->start, io->start + io->number - 1);
> +            ret = ERROR_FAIL;
> +        }
> +    }
> +
> +
> +
>      for (i = 0; i < d_config->num_nics; i++) {
>          /* We have to init the nic here, because we still haven't
>           * called libxl_device_nic_add at this point, but qemu needs
> diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
> index 6d5c578..cf83c60 100644
> --- a/tools/libxl/libxl_types.idl
> +++ b/tools/libxl/libxl_types.idl
> @@ -140,6 +140,11 @@ libxl_ioport_range = Struct("ioport_range", [
>      ("number", uint32),
>      ])
>
> +libxl_iomem_range = Struct("iomem_range", [
> +    ("start", uint64),
> +    ("number", uint64),
> +    ])
> +
>  libxl_vga_interface_info = Struct("vga_interface_info", [
>      ("kind",    libxl_vga_interface_type),
>      ])
> @@ -284,6 +289,7 @@ libxl_domain_build_info = Struct("domain_build_info",[
>
>      ("ioports",          Array(libxl_ioport_range, "num_ioports")),
>      ("irqs",             Array(uint32, "num_irqs")),
> +    ("iomem",            Array(libxl_iomem_range, "num_iomem")),
>
>      ("u", KeyedUnion(None, libxl_domain_type, "type",
>                  [("hvm", Struct(None, [("firmware",         string),
> diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
> index 1627cac..fe8e925 100644
> --- a/tools/libxl/xl_cmdimpl.c
> +++ b/tools/libxl/xl_cmdimpl.c
> @@ -574,8 +574,8 @@ static void parse_config_data(const char *config_source,
>      long l;
>      XLU_Config *config;
>      XLU_ConfigList *cpus, *vbds, *nics, *pcis, *cvfbs, *cpuids;
> -    XLU_ConfigList *ioports, *irqs;
> -    int num_ioports, num_irqs;
> +    XLU_ConfigList *ioports, *irqs, *iomem;
> +    int num_ioports, num_irqs, num_iomem;
>      int pci_power_mgmt = 0;
>      int pci_msitranslate = 0;
>      int pci_permissive = 0;
> @@ -1005,6 +1005,30 @@ static void parse_config_data(const char *config_source,
>          }
>      }
>
> +    if (!xlu_cfg_get_list(config, "iomem", &iomem, &num_iomem, 0)) {
> +        b_info->num_iomem = num_iomem;
> +        b_info->iomem = calloc(num_iomem, sizeof(*b_info->iomem));
> +        if (b_info->iomem == NULL) {
> +            fprintf(stderr, "unable to allocate memory for iomem\n");
> +            exit(-1);
> +        }
> +        for (i = 0; i < num_iomem; i++) {
> +            buf = xlu_cfg_get_listitem (iomem, i);
> +            if (!buf) {
> +                fprintf(stderr,
> +                        "xl: Unable to get element %d in iomem list\n", i);
> +                exit(1);
> +            }
> +            if(sscanf(buf, "%" SCNx64",%" SCNx64, &b_info->iomem[i].start, &b_info->iomem[i].number) != 2) {
> +               fprintf(stderr,
> +                       "xl: Invalid argument parsing iomem: %s\n", buf);
> +               exit(1);
> +            }
> +        }
> +    }
> +
> +
> +
>      if (!xlu_cfg_get_list (config, "disk", &vbds, 0, 0)) {
>          d_config->num_disks = 0;
>          d_config->disks = NULL;
> --
> 1.7.9.5
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 28 15:27:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Sep 2012 15:27:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1THcSp-0007cc-8C; Fri, 28 Sep 2012 15:26:51 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <matthew.fioravante@jhuapl.edu>) id 1THcSn-0007cV-Qc
	for xen-devel@lists.xen.org; Fri, 28 Sep 2012 15:26:50 +0000
Received: from [85.158.138.51:3888] by server-7.bemta-3.messagelabs.com id
	92/30-15765-8B1C5605; Fri, 28 Sep 2012 15:26:48 +0000
X-Env-Sender: matthew.fioravante@jhuapl.edu
X-Msg-Ref: server-9.tower-174.messagelabs.com!1348846006!30679952!1
X-Originating-IP: [128.244.251.36]
X-SpamReason: No, hits=0.0 required=7.0 tests=UNPARSEABLE_RELAY
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29695 invoked from network); 28 Sep 2012 15:26:48 -0000
Received: from pilot.jhuapl.edu (HELO jhuapl.edu) (128.244.251.36)
	by server-9.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 28 Sep 2012 15:26:48 -0000
Received: from ([128.244.207.89])
	by pilot.jhuapl.edu with ESMTP with TLS id 63GHCH1.153880884;
	Fri, 28 Sep 2012 11:26:28 -0400
From: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
To: xen-devel@lists.xen.org, Ian.Campbell@citrix.com,
	samuel.thibault@ens-lyon.org
Date: Fri, 28 Sep 2012 11:24:57 -0400
Message-Id: <1348845897-4797-1-git-send-email-matthew.fioravante@jhuapl.edu>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <5065AD49.7040101@jhuapl.edu>
References: <5065AD49.7040101@jhuapl.edu>
Cc: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
Subject: [Xen-devel] [PATCH 05/11] add CONFIG_XC conditional
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This patch adds a CONFIG_XC option to mini-os, to allow conditional
support for libxc for mini-os domains.

Signed-off-by: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
Acked-by: Samuel Thibault <samuel.thibault@ens-lyon.org>
---
 * Disable linking against libxc if its disabled

diff --git a/extras/mini-os/Makefile b/extras/mini-os/Makefile
index c425f76..2422db3 100644
--- a/extras/mini-os/Makefile
+++ b/extras/mini-os/Makefile
@@ -27,6 +27,7 @@ CONFIG_FBFRONT ?= y
 CONFIG_KBDFRONT ?= y
 CONFIG_CONSFRONT ?= y
 CONFIG_XENBUS ?= y
+CONFIG_XC ?=y
 CONFIG_LWIP ?= $(lwip)
 
 # Export config items as compiler directives
@@ -144,7 +145,9 @@ endif
 OBJS := $(filter-out $(OBJ_DIR)/lwip%.o $(LWO), $(OBJS))
 
 ifeq ($(libc),y)
+ifeq ($(CONFIG_XC),y)
 APP_LDLIBS += -L$(XEN_ROOT)/stubdom/libxc-$(XEN_TARGET_ARCH) -whole-archive -lxenguest -lxenctrl -no-whole-archive
+endif
 APP_LDLIBS += -lpci
 APP_LDLIBS += -lz
 APP_LDLIBS += -lm
diff --git a/extras/mini-os/lib/sys.c b/extras/mini-os/lib/sys.c
index 7ddbbf8..6cb97b1 100644
--- a/extras/mini-os/lib/sys.c
+++ b/extras/mini-os/lib/sys.c
@@ -397,6 +397,7 @@ int close(int fd)
 	    return res;
 	}
 #endif
+#ifdef CONFIG_XC
 	case FTYPE_XC:
 	    minios_interface_close_fd(fd);
 	    return 0;
@@ -406,6 +407,7 @@ int close(int fd)
 	case FTYPE_GNTMAP:
 	    minios_gnttab_close_fd(fd);
 	    return 0;
+#endif
 #ifdef CONFIG_NETFRONT
 	case FTYPE_TAP:
 	    shutdown_netfront(files[fd].tap.dev);
@@ -1195,10 +1197,13 @@ void *mmap(void *start, size_t length, int prot, int flags, int fd, off_t offset
 
     if (fd == -1)
         return map_zero(n, 1);
+#ifdef CONFIG_XC
     else if (files[fd].type == FTYPE_XC) {
         unsigned long zero = 0;
         return map_frames_ex(&zero, n, 0, 0, 1, DOMID_SELF, NULL, 0);
-    } else if (files[fd].type == FTYPE_MEM) {
+    }
+#endif
+    else if (files[fd].type == FTYPE_MEM) {
         unsigned long first_mfn = offset >> PAGE_SHIFT;
         return map_frames_ex(&first_mfn, n, 0, 1, 1, DOMID_IO, NULL, _PAGE_PRESENT|_PAGE_RW);
     } else ASSERT(0);
-- 
1.7.9.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 28 15:27:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Sep 2012 15:27:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1THcSp-0007cc-8C; Fri, 28 Sep 2012 15:26:51 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <matthew.fioravante@jhuapl.edu>) id 1THcSn-0007cV-Qc
	for xen-devel@lists.xen.org; Fri, 28 Sep 2012 15:26:50 +0000
Received: from [85.158.138.51:3888] by server-7.bemta-3.messagelabs.com id
	92/30-15765-8B1C5605; Fri, 28 Sep 2012 15:26:48 +0000
X-Env-Sender: matthew.fioravante@jhuapl.edu
X-Msg-Ref: server-9.tower-174.messagelabs.com!1348846006!30679952!1
X-Originating-IP: [128.244.251.36]
X-SpamReason: No, hits=0.0 required=7.0 tests=UNPARSEABLE_RELAY
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29695 invoked from network); 28 Sep 2012 15:26:48 -0000
Received: from pilot.jhuapl.edu (HELO jhuapl.edu) (128.244.251.36)
	by server-9.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 28 Sep 2012 15:26:48 -0000
Received: from ([128.244.207.89])
	by pilot.jhuapl.edu with ESMTP with TLS id 63GHCH1.153880884;
	Fri, 28 Sep 2012 11:26:28 -0400
From: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
To: xen-devel@lists.xen.org, Ian.Campbell@citrix.com,
	samuel.thibault@ens-lyon.org
Date: Fri, 28 Sep 2012 11:24:57 -0400
Message-Id: <1348845897-4797-1-git-send-email-matthew.fioravante@jhuapl.edu>
X-Mailer: git-send-email 1.7.9.5
In-Reply-To: <5065AD49.7040101@jhuapl.edu>
References: <5065AD49.7040101@jhuapl.edu>
Cc: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
Subject: [Xen-devel] [PATCH 05/11] add CONFIG_XC conditional
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This patch adds a CONFIG_XC option to mini-os, to allow conditional
support for libxc for mini-os domains.

Signed-off-by: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
Acked-by: Samuel Thibault <samuel.thibault@ens-lyon.org>
---
 * Disable linking against libxc if its disabled

diff --git a/extras/mini-os/Makefile b/extras/mini-os/Makefile
index c425f76..2422db3 100644
--- a/extras/mini-os/Makefile
+++ b/extras/mini-os/Makefile
@@ -27,6 +27,7 @@ CONFIG_FBFRONT ?= y
 CONFIG_KBDFRONT ?= y
 CONFIG_CONSFRONT ?= y
 CONFIG_XENBUS ?= y
+CONFIG_XC ?=y
 CONFIG_LWIP ?= $(lwip)
 
 # Export config items as compiler directives
@@ -144,7 +145,9 @@ endif
 OBJS := $(filter-out $(OBJ_DIR)/lwip%.o $(LWO), $(OBJS))
 
 ifeq ($(libc),y)
+ifeq ($(CONFIG_XC),y)
 APP_LDLIBS += -L$(XEN_ROOT)/stubdom/libxc-$(XEN_TARGET_ARCH) -whole-archive -lxenguest -lxenctrl -no-whole-archive
+endif
 APP_LDLIBS += -lpci
 APP_LDLIBS += -lz
 APP_LDLIBS += -lm
diff --git a/extras/mini-os/lib/sys.c b/extras/mini-os/lib/sys.c
index 7ddbbf8..6cb97b1 100644
--- a/extras/mini-os/lib/sys.c
+++ b/extras/mini-os/lib/sys.c
@@ -397,6 +397,7 @@ int close(int fd)
 	    return res;
 	}
 #endif
+#ifdef CONFIG_XC
 	case FTYPE_XC:
 	    minios_interface_close_fd(fd);
 	    return 0;
@@ -406,6 +407,7 @@ int close(int fd)
 	case FTYPE_GNTMAP:
 	    minios_gnttab_close_fd(fd);
 	    return 0;
+#endif
 #ifdef CONFIG_NETFRONT
 	case FTYPE_TAP:
 	    shutdown_netfront(files[fd].tap.dev);
@@ -1195,10 +1197,13 @@ void *mmap(void *start, size_t length, int prot, int flags, int fd, off_t offset
 
     if (fd == -1)
         return map_zero(n, 1);
+#ifdef CONFIG_XC
     else if (files[fd].type == FTYPE_XC) {
         unsigned long zero = 0;
         return map_frames_ex(&zero, n, 0, 0, 1, DOMID_SELF, NULL, 0);
-    } else if (files[fd].type == FTYPE_MEM) {
+    }
+#endif
+    else if (files[fd].type == FTYPE_MEM) {
         unsigned long first_mfn = offset >> PAGE_SHIFT;
         return map_frames_ex(&first_mfn, n, 0, 1, 1, DOMID_IO, NULL, _PAGE_PRESENT|_PAGE_RW);
     } else ASSERT(0);
-- 
1.7.9.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 28 15:28:28 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Sep 2012 15:28: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 1THcU6-0007go-NG; Fri, 28 Sep 2012 15:28:10 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <matthew.fioravante@jhuapl.edu>) id 1THcU5-0007gh-MB
	for xen-devel@lists.xen.org; Fri, 28 Sep 2012 15:28:09 +0000
Received: from [85.158.138.51:14648] by server-1.bemta-3.messagelabs.com id
	3D/96-16425-802C5605; Fri, 28 Sep 2012 15:28:08 +0000
X-Env-Sender: matthew.fioravante@jhuapl.edu
X-Msg-Ref: server-6.tower-174.messagelabs.com!1348846086!24338313!1
X-Originating-IP: [128.244.251.36]
X-SpamReason: No, hits=0.0 required=7.0 tests=UNPARSEABLE_RELAY
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17098 invoked from network); 28 Sep 2012 15:28:07 -0000
Received: from pilot.jhuapl.edu (HELO jhuapl.edu) (128.244.251.36)
	by server-6.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 28 Sep 2012 15:28:07 -0000
Received: from ([128.244.207.89])
	by pilot.jhuapl.edu with ESMTP with TLS id 63GHCH1.153880970;
	Fri, 28 Sep 2012 11:27:48 -0400
Message-ID: <5065C1A4.2030706@jhuapl.edu>
Date: Fri, 28 Sep 2012 11:26:28 -0400
From: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120827 Thunderbird/15.0
MIME-Version: 1.0
To: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>, 
	"Ian.Campbell@citrix.com" <Ian.Campbell@citrix.com>,
	"samuel.thibault@ens-lyon.org" <samuel.thibault@ens-lyon.org>
References: <5065AD49.7040101@jhuapl.edu>
	<1348845897-4797-1-git-send-email-matthew.fioravante@jhuapl.edu>
In-Reply-To: <1348845897-4797-1-git-send-email-matthew.fioravante@jhuapl.edu>
X-Enigmail-Version: 1.4.4
Subject: Re: [Xen-devel] [PATCH 05/11] add CONFIG_XC conditional
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0447427028759252729=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a cryptographically signed message in MIME format.

--===============0447427028759252729==
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms090605090209030902060901"

This is a cryptographically signed message in MIME format.

--------------ms090605090209030902060901
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Also will note that I tested this change against c-stubdom with a libxc
function. It fails to link when CONFIG_XC=3Dn so the change works.

On 09/28/2012 11:24 AM, Matthew Fioravante wrote:
> This patch adds a CONFIG_XC option to mini-os, to allow conditional
> support for libxc for mini-os domains.
>
> Signed-off-by: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
> Acked-by: Samuel Thibault <samuel.thibault@ens-lyon.org>
> ---
>  * Disable linking against libxc if its disabled
>
> diff --git a/extras/mini-os/Makefile b/extras/mini-os/Makefile
> index c425f76..2422db3 100644
> --- a/extras/mini-os/Makefile
> +++ b/extras/mini-os/Makefile
> @@ -27,6 +27,7 @@ CONFIG_FBFRONT ?=3D y
>  CONFIG_KBDFRONT ?=3D y
>  CONFIG_CONSFRONT ?=3D y
>  CONFIG_XENBUS ?=3D y
> +CONFIG_XC ?=3Dy
>  CONFIG_LWIP ?=3D $(lwip)
> =20
>  # Export config items as compiler directives
> @@ -144,7 +145,9 @@ endif
>  OBJS :=3D $(filter-out $(OBJ_DIR)/lwip%.o $(LWO), $(OBJS))
> =20
>  ifeq ($(libc),y)
> +ifeq ($(CONFIG_XC),y)
>  APP_LDLIBS +=3D -L$(XEN_ROOT)/stubdom/libxc-$(XEN_TARGET_ARCH) -whole-=
archive -lxenguest -lxenctrl -no-whole-archive
> +endif
>  APP_LDLIBS +=3D -lpci
>  APP_LDLIBS +=3D -lz
>  APP_LDLIBS +=3D -lm
> diff --git a/extras/mini-os/lib/sys.c b/extras/mini-os/lib/sys.c
> index 7ddbbf8..6cb97b1 100644
> --- a/extras/mini-os/lib/sys.c
> +++ b/extras/mini-os/lib/sys.c
> @@ -397,6 +397,7 @@ int close(int fd)
>  	    return res;
>  	}
>  #endif
> +#ifdef CONFIG_XC
>  	case FTYPE_XC:
>  	    minios_interface_close_fd(fd);
>  	    return 0;
> @@ -406,6 +407,7 @@ int close(int fd)
>  	case FTYPE_GNTMAP:
>  	    minios_gnttab_close_fd(fd);
>  	    return 0;
> +#endif
>  #ifdef CONFIG_NETFRONT
>  	case FTYPE_TAP:
>  	    shutdown_netfront(files[fd].tap.dev);
> @@ -1195,10 +1197,13 @@ void *mmap(void *start, size_t length, int prot=
, int flags, int fd, off_t offset
> =20
>      if (fd =3D=3D -1)
>          return map_zero(n, 1);
> +#ifdef CONFIG_XC
>      else if (files[fd].type =3D=3D FTYPE_XC) {
>          unsigned long zero =3D 0;
>          return map_frames_ex(&zero, n, 0, 0, 1, DOMID_SELF, NULL, 0);
> -    } else if (files[fd].type =3D=3D FTYPE_MEM) {
> +    }
> +#endif
> +    else if (files[fd].type =3D=3D FTYPE_MEM) {
>          unsigned long first_mfn =3D offset >> PAGE_SHIFT;
>          return map_frames_ex(&first_mfn, n, 0, 1, 1, DOMID_IO, NULL, _=
PAGE_PRESENT|_PAGE_RW);
>      } else ASSERT(0);



--------------ms090605090209030902060901
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIDyjCC
A8YwggMvoAMCAQICBD/xyf0wDQYJKoZIhvcNAQEFBQAwLzELMAkGA1UEBhMCVVMxDzANBgNV
BAoTBkpIVUFQTDEPMA0GA1UECxMGQklTRENBMB4XDTEwMDYxMTE4MjIwNloXDTEzMDYxMTE4
NTIwNlowZjELMAkGA1UEBhMCVVMxDzANBgNVBAoTBkpIVUFQTDEPMA0GA1UECxMGUGVvcGxl
MTUwFgYDVQQLEw9WUE5Hcm91cC1CSVNEQ0EwGwYDVQQDExRNYXR0aGV3IEUgRmlvcmF2YW50
ZTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAnpbwVSP6o1Nb5lcW7dd3yTo9iBJdi7qz
4nANOMFPK7JOy5npKN1iiousl28U/scUJES55gPwAWYJK3uVyQAsA4adgDKi5DoD1UHDQEwp
bY7iHLJeq0NPr4BqYNqnCFPbE6HC8zSJrr4qKn+gVUQT39SIFqdiIPJwZL8FYTRQ/zsCAwEA
AaOCAbYwggGyMAsGA1UdDwQEAwIHgDArBgNVHRAEJDAigA8yMDEwMDYxMTE4MjIwNlqBDzIw
MTIwNzE3MjI1MjA2WjAbBg0rBgEEAbMlCwMBAQEBBAoWCGZpb3JhbWUxMBsGDSsGAQQBsyUL
AwEBAQIEChIIMDAxMDQyNjEwWAYJYIZIAYb6ax4BBEsMSVRoZSBwcml2YXRlIGtleSBjb3Jy
ZXNwb25kaW5nIHRvIHRoaXMgY2VydGlmaWNhdGUgbWF5IGhhdmUgYmVlbiBleHBvcnRlZC4w
KAYDVR0RBCEwH4EdTWF0dGhldy5GaW9yYXZhbnRlQGpodWFwbC5lZHUwUgYDVR0fBEswSTBH
oEWgQ6RBMD8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJU0RD
QTEOMAwGA1UEAxMFQ1JMNTYwHwYDVR0jBBgwFoAUCDUpmxH52EU2CyWmF2EJMB1yqeswHQYD
VR0OBBYEFO6LYxg6r9wHZ+zdQtBHn1dZ/YTNMAkGA1UdEwQCMAAwGQYJKoZIhvZ9B0EABAww
ChsEVjcuMQMCBLAwDQYJKoZIhvcNAQEFBQADgYEAJO9HQh4YNChVLzuZqK5ARJARD8JoujGZ
fdo75quvg2jXFQe2sEjvLnxJZgm/pv8fdZakq48CWwjYHKuvIp7sDjTEsQfo+y7SpN/N2NvJ
WU5SqfK1VgYtNLRRoGJUB5Q1aZ+Dg95g3kqpyfpUMISJL8IKVLtJVfN4fggFVUYZ9wwxggGr
MIIBpwIBATA3MC8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJ
U0RDQQIEP/HJ/TAJBgUrDgMCGgUAoIHLMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ
KoZIhvcNAQkFMQ8XDTEyMDkyODE1MjYyOFowIwYJKoZIhvcNAQkEMRYEFCfTwtr5z97WEglv
l9tpBZ51rss/MGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAK
BggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI
KoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEgYBmnHwkI8aTAljmNfdUyI6Ke+jQCVuJIQmb
/L3th3GfRwC97Y2TlaHpXO3LdLq/5kYPSswMDwPZesCGdM3nTzdvbUPeOCJHEF6VXhifPSsO
mhupx0jBK8PX3HCAJ57YRZY5YYOuExKodZC/xuqWzffR08fL9wINHQjQdzLwRLBrUQAAAAAA
AA==
--------------ms090605090209030902060901--


--===============0447427028759252729==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============0447427028759252729==--


From xen-devel-bounces@lists.xen.org Fri Sep 28 15:28:28 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Sep 2012 15:28: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 1THcU6-0007go-NG; Fri, 28 Sep 2012 15:28:10 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <matthew.fioravante@jhuapl.edu>) id 1THcU5-0007gh-MB
	for xen-devel@lists.xen.org; Fri, 28 Sep 2012 15:28:09 +0000
Received: from [85.158.138.51:14648] by server-1.bemta-3.messagelabs.com id
	3D/96-16425-802C5605; Fri, 28 Sep 2012 15:28:08 +0000
X-Env-Sender: matthew.fioravante@jhuapl.edu
X-Msg-Ref: server-6.tower-174.messagelabs.com!1348846086!24338313!1
X-Originating-IP: [128.244.251.36]
X-SpamReason: No, hits=0.0 required=7.0 tests=UNPARSEABLE_RELAY
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17098 invoked from network); 28 Sep 2012 15:28:07 -0000
Received: from pilot.jhuapl.edu (HELO jhuapl.edu) (128.244.251.36)
	by server-6.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 28 Sep 2012 15:28:07 -0000
Received: from ([128.244.207.89])
	by pilot.jhuapl.edu with ESMTP with TLS id 63GHCH1.153880970;
	Fri, 28 Sep 2012 11:27:48 -0400
Message-ID: <5065C1A4.2030706@jhuapl.edu>
Date: Fri, 28 Sep 2012 11:26:28 -0400
From: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120827 Thunderbird/15.0
MIME-Version: 1.0
To: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>, 
	"Ian.Campbell@citrix.com" <Ian.Campbell@citrix.com>,
	"samuel.thibault@ens-lyon.org" <samuel.thibault@ens-lyon.org>
References: <5065AD49.7040101@jhuapl.edu>
	<1348845897-4797-1-git-send-email-matthew.fioravante@jhuapl.edu>
In-Reply-To: <1348845897-4797-1-git-send-email-matthew.fioravante@jhuapl.edu>
X-Enigmail-Version: 1.4.4
Subject: Re: [Xen-devel] [PATCH 05/11] add CONFIG_XC conditional
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0447427028759252729=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a cryptographically signed message in MIME format.

--===============0447427028759252729==
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms090605090209030902060901"

This is a cryptographically signed message in MIME format.

--------------ms090605090209030902060901
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Also will note that I tested this change against c-stubdom with a libxc
function. It fails to link when CONFIG_XC=3Dn so the change works.

On 09/28/2012 11:24 AM, Matthew Fioravante wrote:
> This patch adds a CONFIG_XC option to mini-os, to allow conditional
> support for libxc for mini-os domains.
>
> Signed-off-by: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
> Acked-by: Samuel Thibault <samuel.thibault@ens-lyon.org>
> ---
>  * Disable linking against libxc if its disabled
>
> diff --git a/extras/mini-os/Makefile b/extras/mini-os/Makefile
> index c425f76..2422db3 100644
> --- a/extras/mini-os/Makefile
> +++ b/extras/mini-os/Makefile
> @@ -27,6 +27,7 @@ CONFIG_FBFRONT ?=3D y
>  CONFIG_KBDFRONT ?=3D y
>  CONFIG_CONSFRONT ?=3D y
>  CONFIG_XENBUS ?=3D y
> +CONFIG_XC ?=3Dy
>  CONFIG_LWIP ?=3D $(lwip)
> =20
>  # Export config items as compiler directives
> @@ -144,7 +145,9 @@ endif
>  OBJS :=3D $(filter-out $(OBJ_DIR)/lwip%.o $(LWO), $(OBJS))
> =20
>  ifeq ($(libc),y)
> +ifeq ($(CONFIG_XC),y)
>  APP_LDLIBS +=3D -L$(XEN_ROOT)/stubdom/libxc-$(XEN_TARGET_ARCH) -whole-=
archive -lxenguest -lxenctrl -no-whole-archive
> +endif
>  APP_LDLIBS +=3D -lpci
>  APP_LDLIBS +=3D -lz
>  APP_LDLIBS +=3D -lm
> diff --git a/extras/mini-os/lib/sys.c b/extras/mini-os/lib/sys.c
> index 7ddbbf8..6cb97b1 100644
> --- a/extras/mini-os/lib/sys.c
> +++ b/extras/mini-os/lib/sys.c
> @@ -397,6 +397,7 @@ int close(int fd)
>  	    return res;
>  	}
>  #endif
> +#ifdef CONFIG_XC
>  	case FTYPE_XC:
>  	    minios_interface_close_fd(fd);
>  	    return 0;
> @@ -406,6 +407,7 @@ int close(int fd)
>  	case FTYPE_GNTMAP:
>  	    minios_gnttab_close_fd(fd);
>  	    return 0;
> +#endif
>  #ifdef CONFIG_NETFRONT
>  	case FTYPE_TAP:
>  	    shutdown_netfront(files[fd].tap.dev);
> @@ -1195,10 +1197,13 @@ void *mmap(void *start, size_t length, int prot=
, int flags, int fd, off_t offset
> =20
>      if (fd =3D=3D -1)
>          return map_zero(n, 1);
> +#ifdef CONFIG_XC
>      else if (files[fd].type =3D=3D FTYPE_XC) {
>          unsigned long zero =3D 0;
>          return map_frames_ex(&zero, n, 0, 0, 1, DOMID_SELF, NULL, 0);
> -    } else if (files[fd].type =3D=3D FTYPE_MEM) {
> +    }
> +#endif
> +    else if (files[fd].type =3D=3D FTYPE_MEM) {
>          unsigned long first_mfn =3D offset >> PAGE_SHIFT;
>          return map_frames_ex(&first_mfn, n, 0, 1, 1, DOMID_IO, NULL, _=
PAGE_PRESENT|_PAGE_RW);
>      } else ASSERT(0);



--------------ms090605090209030902060901
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIDyjCC
A8YwggMvoAMCAQICBD/xyf0wDQYJKoZIhvcNAQEFBQAwLzELMAkGA1UEBhMCVVMxDzANBgNV
BAoTBkpIVUFQTDEPMA0GA1UECxMGQklTRENBMB4XDTEwMDYxMTE4MjIwNloXDTEzMDYxMTE4
NTIwNlowZjELMAkGA1UEBhMCVVMxDzANBgNVBAoTBkpIVUFQTDEPMA0GA1UECxMGUGVvcGxl
MTUwFgYDVQQLEw9WUE5Hcm91cC1CSVNEQ0EwGwYDVQQDExRNYXR0aGV3IEUgRmlvcmF2YW50
ZTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAnpbwVSP6o1Nb5lcW7dd3yTo9iBJdi7qz
4nANOMFPK7JOy5npKN1iiousl28U/scUJES55gPwAWYJK3uVyQAsA4adgDKi5DoD1UHDQEwp
bY7iHLJeq0NPr4BqYNqnCFPbE6HC8zSJrr4qKn+gVUQT39SIFqdiIPJwZL8FYTRQ/zsCAwEA
AaOCAbYwggGyMAsGA1UdDwQEAwIHgDArBgNVHRAEJDAigA8yMDEwMDYxMTE4MjIwNlqBDzIw
MTIwNzE3MjI1MjA2WjAbBg0rBgEEAbMlCwMBAQEBBAoWCGZpb3JhbWUxMBsGDSsGAQQBsyUL
AwEBAQIEChIIMDAxMDQyNjEwWAYJYIZIAYb6ax4BBEsMSVRoZSBwcml2YXRlIGtleSBjb3Jy
ZXNwb25kaW5nIHRvIHRoaXMgY2VydGlmaWNhdGUgbWF5IGhhdmUgYmVlbiBleHBvcnRlZC4w
KAYDVR0RBCEwH4EdTWF0dGhldy5GaW9yYXZhbnRlQGpodWFwbC5lZHUwUgYDVR0fBEswSTBH
oEWgQ6RBMD8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJU0RD
QTEOMAwGA1UEAxMFQ1JMNTYwHwYDVR0jBBgwFoAUCDUpmxH52EU2CyWmF2EJMB1yqeswHQYD
VR0OBBYEFO6LYxg6r9wHZ+zdQtBHn1dZ/YTNMAkGA1UdEwQCMAAwGQYJKoZIhvZ9B0EABAww
ChsEVjcuMQMCBLAwDQYJKoZIhvcNAQEFBQADgYEAJO9HQh4YNChVLzuZqK5ARJARD8JoujGZ
fdo75quvg2jXFQe2sEjvLnxJZgm/pv8fdZakq48CWwjYHKuvIp7sDjTEsQfo+y7SpN/N2NvJ
WU5SqfK1VgYtNLRRoGJUB5Q1aZ+Dg95g3kqpyfpUMISJL8IKVLtJVfN4fggFVUYZ9wwxggGr
MIIBpwIBATA3MC8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJ
U0RDQQIEP/HJ/TAJBgUrDgMCGgUAoIHLMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ
KoZIhvcNAQkFMQ8XDTEyMDkyODE1MjYyOFowIwYJKoZIhvcNAQkEMRYEFCfTwtr5z97WEglv
l9tpBZ51rss/MGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAK
BggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI
KoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEgYBmnHwkI8aTAljmNfdUyI6Ke+jQCVuJIQmb
/L3th3GfRwC97Y2TlaHpXO3LdLq/5kYPSswMDwPZesCGdM3nTzdvbUPeOCJHEF6VXhifPSsO
mhupx0jBK8PX3HCAJ57YRZY5YYOuExKodZC/xuqWzffR08fL9wINHQjQdzLwRLBrUQAAAAAA
AA==
--------------ms090605090209030902060901--


--===============0447427028759252729==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============0447427028759252729==--


From xen-devel-bounces@lists.xen.org Fri Sep 28 15:44:45 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Sep 2012 15: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 1THcjp-0007zM-LR; Fri, 28 Sep 2012 15:44:25 +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 1THcjp-0007zH-0o
	for xen-devel@lists.xen.org; Fri, 28 Sep 2012 15:44:25 +0000
Received: from [85.158.139.211:26605] by server-1.bemta-5.messagelabs.com id
	F6/27-09825-8D5C5605; Fri, 28 Sep 2012 15:44:24 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-16.tower-206.messagelabs.com!1348847062!20389956!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNzgzODM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20353 invoked from network); 28 Sep 2012 15:44:23 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-16.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Sep 2012 15:44:23 -0000
X-IronPort-AV: E=Sophos;i="4.80,502,1344211200"; d="scan'208";a="209710471"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Sep 2012 15:44:01 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1;
	Fri, 28 Sep 2012 11:44:01 -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 1THcjQ-0001VO-VL;
	Fri, 28 Sep 2012 16:44:00 +0100
Message-ID: <5065C4B4.4020100@eu.citrix.com>
Date: Fri, 28 Sep 2012 16:39:32 +0100
From: George Dunlap <george.dunlap@eu.citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120827 Thunderbird/15.0
MIME-Version: 1.0
To: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
References: <1348765802-11314-1-git-send-email-matthew.fioravante@jhuapl.edu>
	<CAFLBxZYaDJZW7rXTnzo4UtxJbfggZz86Szw4O=30q2RxtNocBg@mail.gmail.com>
	<5065ACB7.3040902@jhuapl.edu>
In-Reply-To: <5065ACB7.3040902@jhuapl.edu>
Cc: "samuel.thibault@ens-lyon.org" <samuel.thibault@ens-lyon.org>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 01/11] Add ioread/iowrite functions to
	mini-os
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 28/09/12 14:57, Matthew Fioravante wrote:
> On 09/28/2012 06:16 AM, George Dunlap wrote:
>> On Thu, Sep 27, 2012 at 6:09 PM, Matthew Fioravante
>> <matthew.fioravante@jhuapl.edu> wrote:
>>> This patch adds iowritexx() and ioreadxx() functions for interacting
>>> with hardware memory to mini-os. The functions are available in a header
>>> iorw.h
>>>
>>> Signed-off-by: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
>>> Acked-by: Samuel Thibault <samuel.thibault@ens-lyon.org>
>>>
>>> diff --git a/extras/mini-os/arch/ia64/iorw.c b/extras/mini-os/arch/ia64/iorw.c
>> Is there any reason to have the ia64 stuff? ia64 isn't supported in
>> Xen anymore, AFAIK.
> Maybe not. But until ia64 support is removed from mini-os the function
> bodies should exist so stuff will compile.
Ah, right.  :-)  Then:

  Reviewed-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 Sep 28 15:44:45 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Sep 2012 15: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 1THcjp-0007zM-LR; Fri, 28 Sep 2012 15:44:25 +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 1THcjp-0007zH-0o
	for xen-devel@lists.xen.org; Fri, 28 Sep 2012 15:44:25 +0000
Received: from [85.158.139.211:26605] by server-1.bemta-5.messagelabs.com id
	F6/27-09825-8D5C5605; Fri, 28 Sep 2012 15:44:24 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-16.tower-206.messagelabs.com!1348847062!20389956!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyNzgzODM=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20353 invoked from network); 28 Sep 2012 15:44:23 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-16.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Sep 2012 15:44:23 -0000
X-IronPort-AV: E=Sophos;i="4.80,502,1344211200"; d="scan'208";a="209710471"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Sep 2012 15:44:01 +0000
Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com
	(10.13.107.66) with Microsoft SMTP Server id 8.3.279.1;
	Fri, 28 Sep 2012 11:44:01 -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 1THcjQ-0001VO-VL;
	Fri, 28 Sep 2012 16:44:00 +0100
Message-ID: <5065C4B4.4020100@eu.citrix.com>
Date: Fri, 28 Sep 2012 16:39:32 +0100
From: George Dunlap <george.dunlap@eu.citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120827 Thunderbird/15.0
MIME-Version: 1.0
To: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
References: <1348765802-11314-1-git-send-email-matthew.fioravante@jhuapl.edu>
	<CAFLBxZYaDJZW7rXTnzo4UtxJbfggZz86Szw4O=30q2RxtNocBg@mail.gmail.com>
	<5065ACB7.3040902@jhuapl.edu>
In-Reply-To: <5065ACB7.3040902@jhuapl.edu>
Cc: "samuel.thibault@ens-lyon.org" <samuel.thibault@ens-lyon.org>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 01/11] Add ioread/iowrite functions to
	mini-os
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 28/09/12 14:57, Matthew Fioravante wrote:
> On 09/28/2012 06:16 AM, George Dunlap wrote:
>> On Thu, Sep 27, 2012 at 6:09 PM, Matthew Fioravante
>> <matthew.fioravante@jhuapl.edu> wrote:
>>> This patch adds iowritexx() and ioreadxx() functions for interacting
>>> with hardware memory to mini-os. The functions are available in a header
>>> iorw.h
>>>
>>> Signed-off-by: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
>>> Acked-by: Samuel Thibault <samuel.thibault@ens-lyon.org>
>>>
>>> diff --git a/extras/mini-os/arch/ia64/iorw.c b/extras/mini-os/arch/ia64/iorw.c
>> Is there any reason to have the ia64 stuff? ia64 isn't supported in
>> Xen anymore, AFAIK.
> Maybe not. But until ia64 support is removed from mini-os the function
> bodies should exist so stuff will compile.
Ah, right.  :-)  Then:

  Reviewed-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 Sep 28 16:00:09 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Sep 2012 16:00:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1THcyj-0008A6-8v; Fri, 28 Sep 2012 15:59:49 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1THcyh-0008A1-Ka
	for xen-devel@lists.xensource.com; Fri, 28 Sep 2012 15:59:48 +0000
Received: from [85.158.143.35:15256] by server-3.bemta-4.messagelabs.com id
	54/65-10986-379C5605; Fri, 28 Sep 2012 15:59:47 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1348847985!3917205!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDc4MTcyOA==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28196 invoked from network); 28 Sep 2012 15:59:46 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-5.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 28 Sep 2012 15:59:46 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q8SFxdmE016580
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 28 Sep 2012 15:59:40 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
	q8SFxckZ008306
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 28 Sep 2012 15:59:39 GMT
Received: from abhmt117.oracle.com (abhmt117.oracle.com [141.146.116.69])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q8SFxaZY012136; Fri, 28 Sep 2012 10:59:36 -0500
Received: from localhost.localdomain (/10.154.179.198)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 28 Sep 2012 08:59:31 -0700
Date: Fri, 28 Sep 2012 12:07:42 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Daniel Kiper <daniel.kiper@oracle.com>
Message-ID: <20120928160728.GA16262@localhost.localdomain>
References: <1348769198-29580-1-git-send-email-daniel.kiper@oracle.com>
	<1348769198-29580-2-git-send-email-daniel.kiper@oracle.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1348769198-29580-2-git-send-email-daniel.kiper@oracle.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: andrew.cooper3@citrix.com, xen-devel@lists.xensource.com,
	linux-kernel@vger.kernel.org, jbeulich@suse.com
Subject: Re: [Xen-devel] [PATCH 01/11] kexec: introduce kexec_ops struct
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Sep 27, 2012 at 08:06:28PM +0200, Daniel Kiper wrote:
> Some kexec/kdump implementations (e.g. Xen PVOPS) on different archs could
> not use default functions or require some changes in behavior of kexec/kdump
> generic code. To cope with that problem kexec_ops struct was introduced.
> It allows a developer to replace all or some functions and control some
> functionality of kexec/kdump generic code.
> 
> Default behavior of kexec/kdump generic code is not changed.
> 
> Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
> ---
>  include/linux/kexec.h |   18 +++++++
>  kernel/kexec.c        |  125 ++++++++++++++++++++++++++++++++++++-------------
>  2 files changed, 111 insertions(+), 32 deletions(-)
> 
> diff --git a/include/linux/kexec.h b/include/linux/kexec.h
> index 37c5f72..beb08ca 100644
> --- a/include/linux/kexec.h
> +++ b/include/linux/kexec.h
> @@ -165,7 +165,25 @@ struct kimage {
>  #endif
>  };
>  
> +struct kexec_ops {
> +	bool always_use_normal_alloc;

So most of these are self-explanatory. But the bool is not that clear
to me. Could you include a documentation comment explaining
its purpose and its implications?

> +	struct page *(*kimage_alloc_pages)(gfp_t gfp_mask,
> +						unsigned int order,
> +						unsigned long limit);
> +	void (*kimage_free_pages)(struct page *page);
> +	unsigned long (*page_to_pfn)(struct page *page);
> +	struct page *(*pfn_to_page)(unsigned long pfn);
> +	unsigned long (*virt_to_phys)(volatile void *address);
> +	void *(*phys_to_virt)(unsigned long address);
> +	int (*machine_kexec_prepare)(struct kimage *image);
> +	int (*machine_kexec_load)(struct kimage *image);
> +	void (*machine_kexec_cleanup)(struct kimage *image);
> +	void (*machine_kexec_unload)(struct kimage *image);
> +	void (*machine_kexec_shutdown)(void);
> +	void (*machine_kexec)(struct kimage *image);
> +};
>  
> +extern struct kexec_ops kexec_ops;

Is this neccessary?

>  
>  /* kexec interface functions */
>  extern void machine_kexec(struct kimage *image);
> diff --git a/kernel/kexec.c b/kernel/kexec.c
> index 0668d58..98556f3 100644
> --- a/kernel/kexec.c
> +++ b/kernel/kexec.c
> @@ -56,6 +56,47 @@ struct resource crashk_res = {
>  	.flags = IORESOURCE_BUSY | IORESOURCE_MEM
>  };
>  
> +static struct page *kimage_alloc_pages(gfp_t gfp_mask,
> +					unsigned int order,
> +					unsigned long limit);
> +static void kimage_free_pages(struct page *page);
> +
> +static unsigned long generic_page_to_pfn(struct page *page)
> +{
> +	return page_to_pfn(page);
> +}
> +
> +static struct page *generic_pfn_to_page(unsigned long pfn)
> +{
> +	return pfn_to_page(pfn);
> +}
> +
> +static unsigned long generic_virt_to_phys(volatile void *address)
> +{
> +	return virt_to_phys(address);
> +}
> +
> +static void *generic_phys_to_virt(unsigned long address)
> +{
> +	return phys_to_virt(address);
> +}
> +
> +struct kexec_ops kexec_ops = {
> +	.always_use_normal_alloc = false,
> +	.kimage_alloc_pages = kimage_alloc_pages,
> +	.kimage_free_pages = kimage_free_pages,
> +	.page_to_pfn = generic_page_to_pfn,
> +	.pfn_to_page = generic_pfn_to_page,
> +	.virt_to_phys = generic_virt_to_phys,
> +	.phys_to_virt = generic_phys_to_virt,
> +	.machine_kexec_prepare = machine_kexec_prepare,
> +	.machine_kexec_load = NULL,

Instead of NULL should they just point to some nop function?

> +	.machine_kexec_cleanup = machine_kexec_cleanup,
> +	.machine_kexec_unload = NULL,
> +	.machine_kexec_shutdown = machine_shutdown,
> +	.machine_kexec = machine_kexec
> +};
> +
>  int kexec_should_crash(struct task_struct *p)
>  {
>  	if (in_interrupt() || !p->pid || is_global_init(p) || panic_on_oops)
> @@ -355,7 +396,9 @@ static int kimage_is_destination_range(struct kimage *image,
>  	return 0;
>  }
>  
> -static struct page *kimage_alloc_pages(gfp_t gfp_mask, unsigned int order)
> +static struct page *kimage_alloc_pages(gfp_t gfp_mask,
> +					unsigned int order,
> +					unsigned long limit)
>  {
>  	struct page *pages;
>  
> @@ -392,7 +435,7 @@ static void kimage_free_page_list(struct list_head *list)
>  
>  		page = list_entry(pos, struct page, lru);
>  		list_del(&page->lru);
> -		kimage_free_pages(page);
> +		(*kexec_ops.kimage_free_pages)(page);
>  	}
>  }
>  
> @@ -425,10 +468,11 @@ static struct page *kimage_alloc_normal_control_pages(struct kimage *image,
>  	do {
>  		unsigned long pfn, epfn, addr, eaddr;
>  
> -		pages = kimage_alloc_pages(GFP_KERNEL, order);
> +		pages = (*kexec_ops.kimage_alloc_pages)(GFP_KERNEL, order,
> +							KEXEC_CONTROL_MEMORY_LIMIT);
>  		if (!pages)
>  			break;
> -		pfn   = page_to_pfn(pages);
> +		pfn   = (*kexec_ops.page_to_pfn)(pages);
>  		epfn  = pfn + count;
>  		addr  = pfn << PAGE_SHIFT;
>  		eaddr = epfn << PAGE_SHIFT;
> @@ -515,7 +559,7 @@ static struct page *kimage_alloc_crash_control_pages(struct kimage *image,
>  		}
>  		/* If I don't overlap any segments I have found my hole! */
>  		if (i == image->nr_segments) {
> -			pages = pfn_to_page(hole_start >> PAGE_SHIFT);
> +			pages = (*kexec_ops.pfn_to_page)(hole_start >> PAGE_SHIFT);
>  			break;
>  		}
>  	}
> @@ -532,12 +576,13 @@ struct page *kimage_alloc_control_pages(struct kimage *image,
>  	struct page *pages = NULL;
>  
>  	switch (image->type) {
> +	case KEXEC_TYPE_CRASH:
> +		if (!kexec_ops.always_use_normal_alloc) {
> +			pages = kimage_alloc_crash_control_pages(image, order);
> +			break;
> +		}
>  	case KEXEC_TYPE_DEFAULT:
>  		pages = kimage_alloc_normal_control_pages(image, order);
> -		break;
> -	case KEXEC_TYPE_CRASH:
> -		pages = kimage_alloc_crash_control_pages(image, order);
> -		break;
>  	}
>  
>  	return pages;
> @@ -557,7 +602,7 @@ static int kimage_add_entry(struct kimage *image, kimage_entry_t entry)
>  			return -ENOMEM;
>  
>  		ind_page = page_address(page);
> -		*image->entry = virt_to_phys(ind_page) | IND_INDIRECTION;
> +		*image->entry = (*kexec_ops.virt_to_phys)(ind_page) | IND_INDIRECTION;
>  		image->entry = ind_page;
>  		image->last_entry = ind_page +
>  				      ((PAGE_SIZE/sizeof(kimage_entry_t)) - 1);
> @@ -616,14 +661,14 @@ static void kimage_terminate(struct kimage *image)
>  #define for_each_kimage_entry(image, ptr, entry) \
>  	for (ptr = &image->head; (entry = *ptr) && !(entry & IND_DONE); \
>  		ptr = (entry & IND_INDIRECTION)? \
> -			phys_to_virt((entry & PAGE_MASK)): ptr +1)
> +			(*kexec_ops.phys_to_virt)((entry & PAGE_MASK)): ptr +1)
>  
>  static void kimage_free_entry(kimage_entry_t entry)
>  {
>  	struct page *page;
>  
> -	page = pfn_to_page(entry >> PAGE_SHIFT);
> -	kimage_free_pages(page);
> +	page = (*kexec_ops.pfn_to_page)(entry >> PAGE_SHIFT);
> +	(*kexec_ops.kimage_free_pages)(page);
>  }
>  
>  static void kimage_free(struct kimage *image)
> @@ -653,7 +698,7 @@ static void kimage_free(struct kimage *image)
>  		kimage_free_entry(ind);
>  
>  	/* Handle any machine specific cleanup */
> -	machine_kexec_cleanup(image);
> +	(*kexec_ops.machine_kexec_cleanup)(image);
>  
>  	/* Free the kexec control pages... */
>  	kimage_free_page_list(&image->control_pages);
> @@ -709,7 +754,7 @@ static struct page *kimage_alloc_page(struct kimage *image,
>  	 * have a match.
>  	 */
>  	list_for_each_entry(page, &image->dest_pages, lru) {
> -		addr = page_to_pfn(page) << PAGE_SHIFT;
> +		addr = (*kexec_ops.page_to_pfn)(page) << PAGE_SHIFT;
>  		if (addr == destination) {
>  			list_del(&page->lru);
>  			return page;
> @@ -720,16 +765,17 @@ static struct page *kimage_alloc_page(struct kimage *image,
>  		kimage_entry_t *old;
>  
>  		/* Allocate a page, if we run out of memory give up */
> -		page = kimage_alloc_pages(gfp_mask, 0);
> +		page = (*kexec_ops.kimage_alloc_pages)(gfp_mask, 0,
> +							KEXEC_SOURCE_MEMORY_LIMIT);
>  		if (!page)
>  			return NULL;
>  		/* If the page cannot be used file it away */
> -		if (page_to_pfn(page) >
> +		if ((*kexec_ops.page_to_pfn)(page) >
>  				(KEXEC_SOURCE_MEMORY_LIMIT >> PAGE_SHIFT)) {
>  			list_add(&page->lru, &image->unuseable_pages);
>  			continue;
>  		}
> -		addr = page_to_pfn(page) << PAGE_SHIFT;
> +		addr = (*kexec_ops.page_to_pfn)(page) << PAGE_SHIFT;
>  
>  		/* If it is the destination page we want use it */
>  		if (addr == destination)
> @@ -752,7 +798,7 @@ static struct page *kimage_alloc_page(struct kimage *image,
>  			struct page *old_page;
>  
>  			old_addr = *old & PAGE_MASK;
> -			old_page = pfn_to_page(old_addr >> PAGE_SHIFT);
> +			old_page = (*kexec_ops.pfn_to_page)(old_addr >> PAGE_SHIFT);
>  			copy_highpage(page, old_page);
>  			*old = addr | (*old & ~PAGE_MASK);
>  
> @@ -762,7 +808,7 @@ static struct page *kimage_alloc_page(struct kimage *image,
>  			 */
>  			if (!(gfp_mask & __GFP_HIGHMEM) &&
>  			    PageHighMem(old_page)) {
> -				kimage_free_pages(old_page);
> +				(*kexec_ops.kimage_free_pages)(old_page);
>  				continue;
>  			}
>  			addr = old_addr;
> @@ -808,7 +854,7 @@ static int kimage_load_normal_segment(struct kimage *image,
>  			result  = -ENOMEM;
>  			goto out;
>  		}
> -		result = kimage_add_page(image, page_to_pfn(page)
> +		result = kimage_add_page(image, (*kexec_ops.page_to_pfn)(page)
>  								<< PAGE_SHIFT);
>  		if (result < 0)
>  			goto out;
> @@ -862,7 +908,7 @@ static int kimage_load_crash_segment(struct kimage *image,
>  		char *ptr;
>  		size_t uchunk, mchunk;
>  
> -		page = pfn_to_page(maddr >> PAGE_SHIFT);
> +		page = (*kexec_ops.pfn_to_page)(maddr >> PAGE_SHIFT);
>  		if (!page) {
>  			result  = -ENOMEM;
>  			goto out;
> @@ -901,12 +947,13 @@ static int kimage_load_segment(struct kimage *image,
>  	int result = -ENOMEM;
>  
>  	switch (image->type) {
> +	case KEXEC_TYPE_CRASH:
> +		if (!kexec_ops.always_use_normal_alloc) {
> +			result = kimage_load_crash_segment(image, segment);
> +			break;
> +		}
>  	case KEXEC_TYPE_DEFAULT:
>  		result = kimage_load_normal_segment(image, segment);
> -		break;
> -	case KEXEC_TYPE_CRASH:
> -		result = kimage_load_crash_segment(image, segment);
> -		break;
>  	}
>  
>  	return result;
> @@ -994,6 +1041,8 @@ SYSCALL_DEFINE4(kexec_load, unsigned long, entry, unsigned long, nr_segments,
>  			/* Free any current crash dump kernel before
>  			 * we corrupt it.
>  			 */
> +			if (kexec_ops.machine_kexec_unload)
> +				(*kexec_ops.machine_kexec_unload)(image);
>  			kimage_free(xchg(&kexec_crash_image, NULL));
>  			result = kimage_crash_alloc(&image, entry,
>  						     nr_segments, segments);
> @@ -1004,7 +1053,7 @@ SYSCALL_DEFINE4(kexec_load, unsigned long, entry, unsigned long, nr_segments,
>  
>  		if (flags & KEXEC_PRESERVE_CONTEXT)
>  			image->preserve_context = 1;
> -		result = machine_kexec_prepare(image);
> +		result = (*kexec_ops.machine_kexec_prepare)(image);
>  		if (result)
>  			goto out;
>  
> @@ -1017,11 +1066,23 @@ SYSCALL_DEFINE4(kexec_load, unsigned long, entry, unsigned long, nr_segments,
>  		if (flags & KEXEC_ON_CRASH)
>  			crash_unmap_reserved_pages();
>  	}
> +
> +	if (kexec_ops.machine_kexec_load) {
> +		result = (*kexec_ops.machine_kexec_load)(image);
> +
> +		if (result)
> +			goto out;
> +	}
> +
>  	/* Install the new kernel, and  Uninstall the old */
>  	image = xchg(dest_image, image);
>  
>  out:
>  	mutex_unlock(&kexec_mutex);
> +
> +	if (kexec_ops.machine_kexec_unload)
> +		(*kexec_ops.machine_kexec_unload)(image);
> +
>  	kimage_free(image);
>  
>  	return result;
> @@ -1095,7 +1156,7 @@ void crash_kexec(struct pt_regs *regs)
>  			crash_setup_regs(&fixed_regs, regs);
>  			crash_save_vmcoreinfo();
>  			machine_crash_shutdown(&fixed_regs);
> -			machine_kexec(kexec_crash_image);
> +			(*kexec_ops.machine_kexec)(kexec_crash_image);
>  		}
>  		mutex_unlock(&kexec_mutex);
>  	}
> @@ -1117,8 +1178,8 @@ void __weak crash_free_reserved_phys_range(unsigned long begin,
>  	unsigned long addr;
>  
>  	for (addr = begin; addr < end; addr += PAGE_SIZE) {
> -		ClearPageReserved(pfn_to_page(addr >> PAGE_SHIFT));
> -		init_page_count(pfn_to_page(addr >> PAGE_SHIFT));
> +		ClearPageReserved((*kexec_ops.pfn_to_page)(addr >> PAGE_SHIFT));
> +		init_page_count((*kexec_ops.pfn_to_page)(addr >> PAGE_SHIFT));
>  		free_page((unsigned long)__va(addr));
>  		totalram_pages++;
>  	}
> @@ -1572,10 +1633,10 @@ int kernel_kexec(void)
>  	{
>  		kernel_restart_prepare(NULL);
>  		printk(KERN_EMERG "Starting new kernel\n");
> -		machine_shutdown();
> +		(*kexec_ops.machine_kexec_shutdown)();
>  	}
>  
> -	machine_kexec(kexec_image);
> +	(*kexec_ops.machine_kexec)(kexec_image);
>  
>  #ifdef CONFIG_KEXEC_JUMP
>  	if (kexec_image->preserve_context) {
> -- 
> 1.5.6.5

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 28 16:00:09 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Sep 2012 16:00:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1THcyj-0008A6-8v; Fri, 28 Sep 2012 15:59:49 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1THcyh-0008A1-Ka
	for xen-devel@lists.xensource.com; Fri, 28 Sep 2012 15:59:48 +0000
Received: from [85.158.143.35:15256] by server-3.bemta-4.messagelabs.com id
	54/65-10986-379C5605; Fri, 28 Sep 2012 15:59:47 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1348847985!3917205!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDc4MTcyOA==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28196 invoked from network); 28 Sep 2012 15:59:46 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-5.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 28 Sep 2012 15:59:46 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q8SFxdmE016580
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 28 Sep 2012 15:59:40 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
	q8SFxckZ008306
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 28 Sep 2012 15:59:39 GMT
Received: from abhmt117.oracle.com (abhmt117.oracle.com [141.146.116.69])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q8SFxaZY012136; Fri, 28 Sep 2012 10:59:36 -0500
Received: from localhost.localdomain (/10.154.179.198)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 28 Sep 2012 08:59:31 -0700
Date: Fri, 28 Sep 2012 12:07:42 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Daniel Kiper <daniel.kiper@oracle.com>
Message-ID: <20120928160728.GA16262@localhost.localdomain>
References: <1348769198-29580-1-git-send-email-daniel.kiper@oracle.com>
	<1348769198-29580-2-git-send-email-daniel.kiper@oracle.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1348769198-29580-2-git-send-email-daniel.kiper@oracle.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: andrew.cooper3@citrix.com, xen-devel@lists.xensource.com,
	linux-kernel@vger.kernel.org, jbeulich@suse.com
Subject: Re: [Xen-devel] [PATCH 01/11] kexec: introduce kexec_ops struct
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Sep 27, 2012 at 08:06:28PM +0200, Daniel Kiper wrote:
> Some kexec/kdump implementations (e.g. Xen PVOPS) on different archs could
> not use default functions or require some changes in behavior of kexec/kdump
> generic code. To cope with that problem kexec_ops struct was introduced.
> It allows a developer to replace all or some functions and control some
> functionality of kexec/kdump generic code.
> 
> Default behavior of kexec/kdump generic code is not changed.
> 
> Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
> ---
>  include/linux/kexec.h |   18 +++++++
>  kernel/kexec.c        |  125 ++++++++++++++++++++++++++++++++++++-------------
>  2 files changed, 111 insertions(+), 32 deletions(-)
> 
> diff --git a/include/linux/kexec.h b/include/linux/kexec.h
> index 37c5f72..beb08ca 100644
> --- a/include/linux/kexec.h
> +++ b/include/linux/kexec.h
> @@ -165,7 +165,25 @@ struct kimage {
>  #endif
>  };
>  
> +struct kexec_ops {
> +	bool always_use_normal_alloc;

So most of these are self-explanatory. But the bool is not that clear
to me. Could you include a documentation comment explaining
its purpose and its implications?

> +	struct page *(*kimage_alloc_pages)(gfp_t gfp_mask,
> +						unsigned int order,
> +						unsigned long limit);
> +	void (*kimage_free_pages)(struct page *page);
> +	unsigned long (*page_to_pfn)(struct page *page);
> +	struct page *(*pfn_to_page)(unsigned long pfn);
> +	unsigned long (*virt_to_phys)(volatile void *address);
> +	void *(*phys_to_virt)(unsigned long address);
> +	int (*machine_kexec_prepare)(struct kimage *image);
> +	int (*machine_kexec_load)(struct kimage *image);
> +	void (*machine_kexec_cleanup)(struct kimage *image);
> +	void (*machine_kexec_unload)(struct kimage *image);
> +	void (*machine_kexec_shutdown)(void);
> +	void (*machine_kexec)(struct kimage *image);
> +};
>  
> +extern struct kexec_ops kexec_ops;

Is this neccessary?

>  
>  /* kexec interface functions */
>  extern void machine_kexec(struct kimage *image);
> diff --git a/kernel/kexec.c b/kernel/kexec.c
> index 0668d58..98556f3 100644
> --- a/kernel/kexec.c
> +++ b/kernel/kexec.c
> @@ -56,6 +56,47 @@ struct resource crashk_res = {
>  	.flags = IORESOURCE_BUSY | IORESOURCE_MEM
>  };
>  
> +static struct page *kimage_alloc_pages(gfp_t gfp_mask,
> +					unsigned int order,
> +					unsigned long limit);
> +static void kimage_free_pages(struct page *page);
> +
> +static unsigned long generic_page_to_pfn(struct page *page)
> +{
> +	return page_to_pfn(page);
> +}
> +
> +static struct page *generic_pfn_to_page(unsigned long pfn)
> +{
> +	return pfn_to_page(pfn);
> +}
> +
> +static unsigned long generic_virt_to_phys(volatile void *address)
> +{
> +	return virt_to_phys(address);
> +}
> +
> +static void *generic_phys_to_virt(unsigned long address)
> +{
> +	return phys_to_virt(address);
> +}
> +
> +struct kexec_ops kexec_ops = {
> +	.always_use_normal_alloc = false,
> +	.kimage_alloc_pages = kimage_alloc_pages,
> +	.kimage_free_pages = kimage_free_pages,
> +	.page_to_pfn = generic_page_to_pfn,
> +	.pfn_to_page = generic_pfn_to_page,
> +	.virt_to_phys = generic_virt_to_phys,
> +	.phys_to_virt = generic_phys_to_virt,
> +	.machine_kexec_prepare = machine_kexec_prepare,
> +	.machine_kexec_load = NULL,

Instead of NULL should they just point to some nop function?

> +	.machine_kexec_cleanup = machine_kexec_cleanup,
> +	.machine_kexec_unload = NULL,
> +	.machine_kexec_shutdown = machine_shutdown,
> +	.machine_kexec = machine_kexec
> +};
> +
>  int kexec_should_crash(struct task_struct *p)
>  {
>  	if (in_interrupt() || !p->pid || is_global_init(p) || panic_on_oops)
> @@ -355,7 +396,9 @@ static int kimage_is_destination_range(struct kimage *image,
>  	return 0;
>  }
>  
> -static struct page *kimage_alloc_pages(gfp_t gfp_mask, unsigned int order)
> +static struct page *kimage_alloc_pages(gfp_t gfp_mask,
> +					unsigned int order,
> +					unsigned long limit)
>  {
>  	struct page *pages;
>  
> @@ -392,7 +435,7 @@ static void kimage_free_page_list(struct list_head *list)
>  
>  		page = list_entry(pos, struct page, lru);
>  		list_del(&page->lru);
> -		kimage_free_pages(page);
> +		(*kexec_ops.kimage_free_pages)(page);
>  	}
>  }
>  
> @@ -425,10 +468,11 @@ static struct page *kimage_alloc_normal_control_pages(struct kimage *image,
>  	do {
>  		unsigned long pfn, epfn, addr, eaddr;
>  
> -		pages = kimage_alloc_pages(GFP_KERNEL, order);
> +		pages = (*kexec_ops.kimage_alloc_pages)(GFP_KERNEL, order,
> +							KEXEC_CONTROL_MEMORY_LIMIT);
>  		if (!pages)
>  			break;
> -		pfn   = page_to_pfn(pages);
> +		pfn   = (*kexec_ops.page_to_pfn)(pages);
>  		epfn  = pfn + count;
>  		addr  = pfn << PAGE_SHIFT;
>  		eaddr = epfn << PAGE_SHIFT;
> @@ -515,7 +559,7 @@ static struct page *kimage_alloc_crash_control_pages(struct kimage *image,
>  		}
>  		/* If I don't overlap any segments I have found my hole! */
>  		if (i == image->nr_segments) {
> -			pages = pfn_to_page(hole_start >> PAGE_SHIFT);
> +			pages = (*kexec_ops.pfn_to_page)(hole_start >> PAGE_SHIFT);
>  			break;
>  		}
>  	}
> @@ -532,12 +576,13 @@ struct page *kimage_alloc_control_pages(struct kimage *image,
>  	struct page *pages = NULL;
>  
>  	switch (image->type) {
> +	case KEXEC_TYPE_CRASH:
> +		if (!kexec_ops.always_use_normal_alloc) {
> +			pages = kimage_alloc_crash_control_pages(image, order);
> +			break;
> +		}
>  	case KEXEC_TYPE_DEFAULT:
>  		pages = kimage_alloc_normal_control_pages(image, order);
> -		break;
> -	case KEXEC_TYPE_CRASH:
> -		pages = kimage_alloc_crash_control_pages(image, order);
> -		break;
>  	}
>  
>  	return pages;
> @@ -557,7 +602,7 @@ static int kimage_add_entry(struct kimage *image, kimage_entry_t entry)
>  			return -ENOMEM;
>  
>  		ind_page = page_address(page);
> -		*image->entry = virt_to_phys(ind_page) | IND_INDIRECTION;
> +		*image->entry = (*kexec_ops.virt_to_phys)(ind_page) | IND_INDIRECTION;
>  		image->entry = ind_page;
>  		image->last_entry = ind_page +
>  				      ((PAGE_SIZE/sizeof(kimage_entry_t)) - 1);
> @@ -616,14 +661,14 @@ static void kimage_terminate(struct kimage *image)
>  #define for_each_kimage_entry(image, ptr, entry) \
>  	for (ptr = &image->head; (entry = *ptr) && !(entry & IND_DONE); \
>  		ptr = (entry & IND_INDIRECTION)? \
> -			phys_to_virt((entry & PAGE_MASK)): ptr +1)
> +			(*kexec_ops.phys_to_virt)((entry & PAGE_MASK)): ptr +1)
>  
>  static void kimage_free_entry(kimage_entry_t entry)
>  {
>  	struct page *page;
>  
> -	page = pfn_to_page(entry >> PAGE_SHIFT);
> -	kimage_free_pages(page);
> +	page = (*kexec_ops.pfn_to_page)(entry >> PAGE_SHIFT);
> +	(*kexec_ops.kimage_free_pages)(page);
>  }
>  
>  static void kimage_free(struct kimage *image)
> @@ -653,7 +698,7 @@ static void kimage_free(struct kimage *image)
>  		kimage_free_entry(ind);
>  
>  	/* Handle any machine specific cleanup */
> -	machine_kexec_cleanup(image);
> +	(*kexec_ops.machine_kexec_cleanup)(image);
>  
>  	/* Free the kexec control pages... */
>  	kimage_free_page_list(&image->control_pages);
> @@ -709,7 +754,7 @@ static struct page *kimage_alloc_page(struct kimage *image,
>  	 * have a match.
>  	 */
>  	list_for_each_entry(page, &image->dest_pages, lru) {
> -		addr = page_to_pfn(page) << PAGE_SHIFT;
> +		addr = (*kexec_ops.page_to_pfn)(page) << PAGE_SHIFT;
>  		if (addr == destination) {
>  			list_del(&page->lru);
>  			return page;
> @@ -720,16 +765,17 @@ static struct page *kimage_alloc_page(struct kimage *image,
>  		kimage_entry_t *old;
>  
>  		/* Allocate a page, if we run out of memory give up */
> -		page = kimage_alloc_pages(gfp_mask, 0);
> +		page = (*kexec_ops.kimage_alloc_pages)(gfp_mask, 0,
> +							KEXEC_SOURCE_MEMORY_LIMIT);
>  		if (!page)
>  			return NULL;
>  		/* If the page cannot be used file it away */
> -		if (page_to_pfn(page) >
> +		if ((*kexec_ops.page_to_pfn)(page) >
>  				(KEXEC_SOURCE_MEMORY_LIMIT >> PAGE_SHIFT)) {
>  			list_add(&page->lru, &image->unuseable_pages);
>  			continue;
>  		}
> -		addr = page_to_pfn(page) << PAGE_SHIFT;
> +		addr = (*kexec_ops.page_to_pfn)(page) << PAGE_SHIFT;
>  
>  		/* If it is the destination page we want use it */
>  		if (addr == destination)
> @@ -752,7 +798,7 @@ static struct page *kimage_alloc_page(struct kimage *image,
>  			struct page *old_page;
>  
>  			old_addr = *old & PAGE_MASK;
> -			old_page = pfn_to_page(old_addr >> PAGE_SHIFT);
> +			old_page = (*kexec_ops.pfn_to_page)(old_addr >> PAGE_SHIFT);
>  			copy_highpage(page, old_page);
>  			*old = addr | (*old & ~PAGE_MASK);
>  
> @@ -762,7 +808,7 @@ static struct page *kimage_alloc_page(struct kimage *image,
>  			 */
>  			if (!(gfp_mask & __GFP_HIGHMEM) &&
>  			    PageHighMem(old_page)) {
> -				kimage_free_pages(old_page);
> +				(*kexec_ops.kimage_free_pages)(old_page);
>  				continue;
>  			}
>  			addr = old_addr;
> @@ -808,7 +854,7 @@ static int kimage_load_normal_segment(struct kimage *image,
>  			result  = -ENOMEM;
>  			goto out;
>  		}
> -		result = kimage_add_page(image, page_to_pfn(page)
> +		result = kimage_add_page(image, (*kexec_ops.page_to_pfn)(page)
>  								<< PAGE_SHIFT);
>  		if (result < 0)
>  			goto out;
> @@ -862,7 +908,7 @@ static int kimage_load_crash_segment(struct kimage *image,
>  		char *ptr;
>  		size_t uchunk, mchunk;
>  
> -		page = pfn_to_page(maddr >> PAGE_SHIFT);
> +		page = (*kexec_ops.pfn_to_page)(maddr >> PAGE_SHIFT);
>  		if (!page) {
>  			result  = -ENOMEM;
>  			goto out;
> @@ -901,12 +947,13 @@ static int kimage_load_segment(struct kimage *image,
>  	int result = -ENOMEM;
>  
>  	switch (image->type) {
> +	case KEXEC_TYPE_CRASH:
> +		if (!kexec_ops.always_use_normal_alloc) {
> +			result = kimage_load_crash_segment(image, segment);
> +			break;
> +		}
>  	case KEXEC_TYPE_DEFAULT:
>  		result = kimage_load_normal_segment(image, segment);
> -		break;
> -	case KEXEC_TYPE_CRASH:
> -		result = kimage_load_crash_segment(image, segment);
> -		break;
>  	}
>  
>  	return result;
> @@ -994,6 +1041,8 @@ SYSCALL_DEFINE4(kexec_load, unsigned long, entry, unsigned long, nr_segments,
>  			/* Free any current crash dump kernel before
>  			 * we corrupt it.
>  			 */
> +			if (kexec_ops.machine_kexec_unload)
> +				(*kexec_ops.machine_kexec_unload)(image);
>  			kimage_free(xchg(&kexec_crash_image, NULL));
>  			result = kimage_crash_alloc(&image, entry,
>  						     nr_segments, segments);
> @@ -1004,7 +1053,7 @@ SYSCALL_DEFINE4(kexec_load, unsigned long, entry, unsigned long, nr_segments,
>  
>  		if (flags & KEXEC_PRESERVE_CONTEXT)
>  			image->preserve_context = 1;
> -		result = machine_kexec_prepare(image);
> +		result = (*kexec_ops.machine_kexec_prepare)(image);
>  		if (result)
>  			goto out;
>  
> @@ -1017,11 +1066,23 @@ SYSCALL_DEFINE4(kexec_load, unsigned long, entry, unsigned long, nr_segments,
>  		if (flags & KEXEC_ON_CRASH)
>  			crash_unmap_reserved_pages();
>  	}
> +
> +	if (kexec_ops.machine_kexec_load) {
> +		result = (*kexec_ops.machine_kexec_load)(image);
> +
> +		if (result)
> +			goto out;
> +	}
> +
>  	/* Install the new kernel, and  Uninstall the old */
>  	image = xchg(dest_image, image);
>  
>  out:
>  	mutex_unlock(&kexec_mutex);
> +
> +	if (kexec_ops.machine_kexec_unload)
> +		(*kexec_ops.machine_kexec_unload)(image);
> +
>  	kimage_free(image);
>  
>  	return result;
> @@ -1095,7 +1156,7 @@ void crash_kexec(struct pt_regs *regs)
>  			crash_setup_regs(&fixed_regs, regs);
>  			crash_save_vmcoreinfo();
>  			machine_crash_shutdown(&fixed_regs);
> -			machine_kexec(kexec_crash_image);
> +			(*kexec_ops.machine_kexec)(kexec_crash_image);
>  		}
>  		mutex_unlock(&kexec_mutex);
>  	}
> @@ -1117,8 +1178,8 @@ void __weak crash_free_reserved_phys_range(unsigned long begin,
>  	unsigned long addr;
>  
>  	for (addr = begin; addr < end; addr += PAGE_SIZE) {
> -		ClearPageReserved(pfn_to_page(addr >> PAGE_SHIFT));
> -		init_page_count(pfn_to_page(addr >> PAGE_SHIFT));
> +		ClearPageReserved((*kexec_ops.pfn_to_page)(addr >> PAGE_SHIFT));
> +		init_page_count((*kexec_ops.pfn_to_page)(addr >> PAGE_SHIFT));
>  		free_page((unsigned long)__va(addr));
>  		totalram_pages++;
>  	}
> @@ -1572,10 +1633,10 @@ int kernel_kexec(void)
>  	{
>  		kernel_restart_prepare(NULL);
>  		printk(KERN_EMERG "Starting new kernel\n");
> -		machine_shutdown();
> +		(*kexec_ops.machine_kexec_shutdown)();
>  	}
>  
> -	machine_kexec(kexec_image);
> +	(*kexec_ops.machine_kexec)(kexec_image);
>  
>  #ifdef CONFIG_KEXEC_JUMP
>  	if (kexec_image->preserve_context) {
> -- 
> 1.5.6.5

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 28 16:02:22 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Sep 2012 16: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 1THd0q-0000CW-QM; Fri, 28 Sep 2012 16:02: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 1THd0p-0000CR-Kh
	for xen-devel@lists.xensource.com; Fri, 28 Sep 2012 16:01:59 +0000
Received: from [85.158.143.35:65444] by server-1.bemta-4.messagelabs.com id
	6C/C4-05684-6F9C5605; Fri, 28 Sep 2012 16:01:58 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1348848117!13182918!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzcxNjk5\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25944 invoked from network); 28 Sep 2012 16:01:58 -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; 28 Sep 2012 16:01:58 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q8SG1sGG031800
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 28 Sep 2012 16:01:55 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
	q8SG1sRM023987
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 28 Sep 2012 16:01:54 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
	q8SG1sbq026696; Fri, 28 Sep 2012 11:01:54 -0500
Received: from localhost.localdomain (/10.154.179.198)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 28 Sep 2012 09:01:53 -0700
Date: Fri, 28 Sep 2012 12:10:17 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Daniel Kiper <daniel.kiper@oracle.com>
Message-ID: <20120928161016.GB16262@localhost.localdomain>
References: <1348769198-29580-1-git-send-email-daniel.kiper@oracle.com>
	<1348769198-29580-2-git-send-email-daniel.kiper@oracle.com>
	<1348769198-29580-3-git-send-email-daniel.kiper@oracle.com>
	<1348769198-29580-4-git-send-email-daniel.kiper@oracle.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1348769198-29580-4-git-send-email-daniel.kiper@oracle.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: andrew.cooper3@citrix.com, xen-devel@lists.xensource.com,
	linux-kernel@vger.kernel.org, jbeulich@suse.com
Subject: Re: [Xen-devel] [PATCH 03/11] xen: Introduce architecture
 independent data for kexec/kdump
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Sep 27, 2012 at 08:06:30PM +0200, Daniel Kiper wrote:
> Introduce architecture independent constants and structures

Don't you mean 'dependent constants'?

> required by Xen kexec/kdump implementation.
> 
> Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
> ---
>  include/xen/interface/xen.h |   33 +++++++++++++++++++++++++++++++++
>  1 files changed, 33 insertions(+), 0 deletions(-)
> 
> diff --git a/include/xen/interface/xen.h b/include/xen/interface/xen.h
> index 0801468..ac19f9e 100644
> --- a/include/xen/interface/xen.h
> +++ b/include/xen/interface/xen.h
> @@ -58,6 +58,7 @@
>  #define __HYPERVISOR_event_channel_op     32
>  #define __HYPERVISOR_physdev_op           33
>  #define __HYPERVISOR_hvm_op               34
> +#define __HYPERVISOR_kexec_op             37
>  #define __HYPERVISOR_tmem_op              38
>  
>  /* Architecture-specific hypercall definitions. */
> @@ -232,7 +233,39 @@ DEFINE_GUEST_HANDLE_STRUCT(mmuext_op);
>  #define VMASST_TYPE_pae_extended_cr3     3
>  #define MAX_VMASST_TYPE 3
>  
> +/*
> + * Commands to HYPERVISOR_kexec_op().
> + */
> +#define KEXEC_CMD_kexec			0
> +#define KEXEC_CMD_kexec_load		1
> +#define KEXEC_CMD_kexec_unload		2
> +#define KEXEC_CMD_kexec_get_range	3
> +
> +/*
> + * Memory ranges for kdump (utilized by HYPERVISOR_kexec_op()).
> + */
> +#define KEXEC_RANGE_MA_CRASH		0
> +#define KEXEC_RANGE_MA_XEN		1
> +#define KEXEC_RANGE_MA_CPU		2
> +#define KEXEC_RANGE_MA_XENHEAP		3
> +#define KEXEC_RANGE_MA_BOOT_PARAM	4
> +#define KEXEC_RANGE_MA_EFI_MEMMAP	5
> +#define KEXEC_RANGE_MA_VMCOREINFO	6
> +
>  #ifndef __ASSEMBLY__
> +struct xen_kexec_exec {
> +	int type;
> +};
> +
> +struct xen_kexec_range {
> +	int range;
> +	int nr;
> +	unsigned long size;
> +	unsigned long start;
> +};

Might want to include an little blurb saying what we expect
in case of running a 32-bit domain on a 64-bit hypervisor
where the start might be past 4GB?

> +
> +extern unsigned long xen_vmcoreinfo_maddr;
> +extern unsigned long xen_vmcoreinfo_max_size;
>  
>  typedef uint16_t domid_t;
>  
> -- 
> 1.5.6.5

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 28 16:02:22 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Sep 2012 16: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 1THd0q-0000CW-QM; Fri, 28 Sep 2012 16:02: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 1THd0p-0000CR-Kh
	for xen-devel@lists.xensource.com; Fri, 28 Sep 2012 16:01:59 +0000
Received: from [85.158.143.35:65444] by server-1.bemta-4.messagelabs.com id
	6C/C4-05684-6F9C5605; Fri, 28 Sep 2012 16:01:58 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1348848117!13182918!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNzcxNjk5\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25944 invoked from network); 28 Sep 2012 16:01:58 -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; 28 Sep 2012 16:01:58 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with
	ESMTP id q8SG1sGG031800
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 28 Sep 2012 16:01:55 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
	q8SG1sRM023987
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 28 Sep 2012 16:01:54 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
	q8SG1sbq026696; Fri, 28 Sep 2012 11:01:54 -0500
Received: from localhost.localdomain (/10.154.179.198)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 28 Sep 2012 09:01:53 -0700
Date: Fri, 28 Sep 2012 12:10:17 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Daniel Kiper <daniel.kiper@oracle.com>
Message-ID: <20120928161016.GB16262@localhost.localdomain>
References: <1348769198-29580-1-git-send-email-daniel.kiper@oracle.com>
	<1348769198-29580-2-git-send-email-daniel.kiper@oracle.com>
	<1348769198-29580-3-git-send-email-daniel.kiper@oracle.com>
	<1348769198-29580-4-git-send-email-daniel.kiper@oracle.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1348769198-29580-4-git-send-email-daniel.kiper@oracle.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: andrew.cooper3@citrix.com, xen-devel@lists.xensource.com,
	linux-kernel@vger.kernel.org, jbeulich@suse.com
Subject: Re: [Xen-devel] [PATCH 03/11] xen: Introduce architecture
 independent data for kexec/kdump
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Sep 27, 2012 at 08:06:30PM +0200, Daniel Kiper wrote:
> Introduce architecture independent constants and structures

Don't you mean 'dependent constants'?

> required by Xen kexec/kdump implementation.
> 
> Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
> ---
>  include/xen/interface/xen.h |   33 +++++++++++++++++++++++++++++++++
>  1 files changed, 33 insertions(+), 0 deletions(-)
> 
> diff --git a/include/xen/interface/xen.h b/include/xen/interface/xen.h
> index 0801468..ac19f9e 100644
> --- a/include/xen/interface/xen.h
> +++ b/include/xen/interface/xen.h
> @@ -58,6 +58,7 @@
>  #define __HYPERVISOR_event_channel_op     32
>  #define __HYPERVISOR_physdev_op           33
>  #define __HYPERVISOR_hvm_op               34
> +#define __HYPERVISOR_kexec_op             37
>  #define __HYPERVISOR_tmem_op              38
>  
>  /* Architecture-specific hypercall definitions. */
> @@ -232,7 +233,39 @@ DEFINE_GUEST_HANDLE_STRUCT(mmuext_op);
>  #define VMASST_TYPE_pae_extended_cr3     3
>  #define MAX_VMASST_TYPE 3
>  
> +/*
> + * Commands to HYPERVISOR_kexec_op().
> + */
> +#define KEXEC_CMD_kexec			0
> +#define KEXEC_CMD_kexec_load		1
> +#define KEXEC_CMD_kexec_unload		2
> +#define KEXEC_CMD_kexec_get_range	3
> +
> +/*
> + * Memory ranges for kdump (utilized by HYPERVISOR_kexec_op()).
> + */
> +#define KEXEC_RANGE_MA_CRASH		0
> +#define KEXEC_RANGE_MA_XEN		1
> +#define KEXEC_RANGE_MA_CPU		2
> +#define KEXEC_RANGE_MA_XENHEAP		3
> +#define KEXEC_RANGE_MA_BOOT_PARAM	4
> +#define KEXEC_RANGE_MA_EFI_MEMMAP	5
> +#define KEXEC_RANGE_MA_VMCOREINFO	6
> +
>  #ifndef __ASSEMBLY__
> +struct xen_kexec_exec {
> +	int type;
> +};
> +
> +struct xen_kexec_range {
> +	int range;
> +	int nr;
> +	unsigned long size;
> +	unsigned long start;
> +};

Might want to include an little blurb saying what we expect
in case of running a 32-bit domain on a 64-bit hypervisor
where the start might be past 4GB?

> +
> +extern unsigned long xen_vmcoreinfo_maddr;
> +extern unsigned long xen_vmcoreinfo_max_size;
>  
>  typedef uint16_t domid_t;
>  
> -- 
> 1.5.6.5

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 28 16:07:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Sep 2012 16: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 1THd6G-0000P1-IX; Fri, 28 Sep 2012 16:07:36 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <matthew.fioravante@jhuapl.edu>) id 1THd6E-0000Ov-5k
	for xen-devel@lists.xen.org; Fri, 28 Sep 2012 16:07:34 +0000
Received: from [85.158.137.99:18513] by server-14.bemta-3.messagelabs.com id
	81/17-25886-54BC5605; Fri, 28 Sep 2012 16:07:33 +0000
X-Env-Sender: matthew.fioravante@jhuapl.edu
X-Msg-Ref: server-10.tower-217.messagelabs.com!1348848449!19429606!1
X-Originating-IP: [128.244.251.36]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG,
	UNPARSEABLE_RELAY
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27042 invoked from network); 28 Sep 2012 16:07:30 -0000
Received: from pilot.jhuapl.edu (HELO jhuapl.edu) (128.244.251.36)
	by server-10.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 28 Sep 2012 16:07:30 -0000
Received: from ([128.244.207.89])
	by pilot.jhuapl.edu with ESMTP with TLS id 63GHCH1.153884838;
	Fri, 28 Sep 2012 12:07:21 -0400
Message-ID: <5065CAE9.30602@jhuapl.edu>
Date: Fri, 28 Sep 2012 12:06:01 -0400
From: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120827 Thunderbird/15.0
MIME-Version: 1.0
To: George Dunlap <George.Dunlap@eu.citrix.com>
References: <1348765860-11359-1-git-send-email-matthew.fioravante@jhuapl.edu>
	<1348765860-11359-3-git-send-email-matthew.fioravante@jhuapl.edu>
	<CAFLBxZbvK0WxHhQgY79vCG21fd8b4i=vuVhtFjrpN-saXM61bA@mail.gmail.com>
In-Reply-To: <CAFLBxZbvK0WxHhQgY79vCG21fd8b4i=vuVhtFjrpN-saXM61bA@mail.gmail.com>
X-Enigmail-Version: 1.4.4
Cc: "Ian.Campbell@citrix.com" <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 11/11] add vtpm support to libxl
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============3695380679684712031=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a cryptographically signed message in MIME format.

--===============3695380679684712031==
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms020402040708000707080800"

This is a cryptographically signed message in MIME format.

--------------ms020402040708000707080800
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On 09/28/2012 11:03 AM, George Dunlap wrote:
> On Thu, Sep 27, 2012 at 6:11 PM, Matthew Fioravante
> <matthew.fioravante@jhuapl.edu> wrote:
>> This patch adds vtpm support to libxl. It adds vtpm parsing to config
>> files and 3 new xl commands:
>> vtpm-attach
>> vtpm-detach
>> vtpm-list
>>
>> Signed-off-by: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
> Overall looks good to me -- just a few comments below about the config
> file handling (see below).
>
> Thanks for all your work on this.
>
>> @@ -601,6 +605,8 @@ static void domcreate_bootloader_done(libxl__egc *=
egc,
>>  static void domcreate_launch_dm(libxl__egc *egc, libxl__multidev *aod=
evs,
>>                                  int ret);
>>
>> +static void domcreate_attach_vtpms(libxl__egc *egc, libxl__multidev *=
multidev,
>> +                                   int ret);
>>  static void domcreate_attach_pci(libxl__egc *egc, libxl__multidev *ao=
devs,
>>                                   int ret);
>>
>> @@ -1084,13 +1090,13 @@ static void domcreate_devmodel_started(libxl__=
egc *egc,
>>      if (d_config->num_nics > 0) {
>>          /* Attach nics */
>>          libxl__multidev_begin(ao, &dcs->multidev);
>> -        dcs->multidev.callback =3D domcreate_attach_pci;
>> +        dcs->multidev.callback =3D domcreate_attach_vtpms;
> Wow -- what a weird convention you've had to try to figure out and
> modify here.  Well done. :-)
It was really tricky. Is there no better way to handle asynchronous
code? This method seems really error prone and almost impossible to follo=
w.
>
>>          libxl__add_nics(egc, ao, domid, d_config, &dcs->multidev);
>>          libxl__multidev_prepared(egc, &dcs->multidev, 0);
>>          return;
>>      }
>>
>> -    domcreate_attach_pci(egc, &dcs->multidev, 0);
>> +    domcreate_attach_vtpms(egc, &dcs->multidev, 0);
>>      return;
>>
>>  error_out:
>> @@ -1098,6 +1104,36 @@ error_out:
>>      domcreate_complete(egc, dcs, ret);
>>  }
>>
>> +static void domcreate_attach_vtpms(libxl__egc *egc, libxl__multidev *=
multidev, int ret) {
>> +   libxl__domain_create_state *dcs =3D CONTAINER_OF(multidev, *dcs, m=
ultidev);
>> +   STATE_AO_GC(dcs->ao);
>> +   int domid =3D dcs->guest_domid;
>> +
>> +   libxl_domain_config* const d_config =3D dcs->guest_config;
>> +
>> +   if(ret) {
>> +      LOG(ERROR, "unable to add nic devices");
>> +      goto error_out;
>> +   }
>> +
>> +    /* Plug vtpm devices */
>> +    if (d_config->num_vtpms > 0) {
>> +        /* Attach vtpms */
>> +        libxl__multidev_begin(ao, &dcs->multidev);
>> +        dcs->multidev.callback =3D domcreate_attach_pci;
>> +        libxl__add_vtpms(egc, ao, domid, d_config, &dcs->multidev);
>> +        libxl__multidev_prepared(egc, &dcs->multidev, 0);
>> +        return;
>> +    }
>> +
>> +   domcreate_attach_pci(egc, multidev, 0);
>> +   return;
>> +
>> +error_out:
>> +   assert(ret);
>> +   domcreate_complete(egc, dcs, ret);
>> +}
>> +
>>  static void domcreate_attach_pci(libxl__egc *egc, libxl__multidev *mu=
ltidev,
>>                                   int ret)
>>  {
>> @@ -1111,7 +1147,7 @@ static void domcreate_attach_pci(libxl__egc *egc=
, libxl__multidev *multidev,
>>      libxl_domain_config *const d_config =3D dcs->guest_config;
>>
>>      if (ret) {
>> -        LOG(ERROR, "unable to add nic devices");
>> +        LOG(ERROR, "unable to add vtpm devices");
>>          goto error_out;
>>      }
>>
> [snip]
>> @@ -1045,6 +1045,47 @@ static void parse_config_data(const char *confi=
g_source,
>>          }
>>      }
>>
>> +    if (!xlu_cfg_get_list(config, "vtpm", &vtpms, 0, 0)) {
>> +        d_config->num_vtpms =3D 0;
>> +        d_config->vtpms =3D NULL;
>> +        while ((buf =3D xlu_cfg_get_listitem (vtpms, d_config->num_vt=
pms)) !=3D NULL) {
>> +            libxl_device_vtpm *vtpm;
>> +            char * buf2 =3D strdup(buf);
>> +            char *p, *p2;
>> +
>> +            d_config->vtpms =3D (libxl_device_vtpm *) realloc(d_confi=
g->vtpms, sizeof(libxl_device_vtpm) * (d_config->num_vtpms+1));
>> +            vtpm =3D d_config->vtpms + d_config->num_vtpms;
>> +            libxl_device_vtpm_init(vtpm);
>> +            vtpm->devid =3D d_config->num_vtpms;
>> +
>> +            p =3D strtok(buf2, ",");
>> +            if (!p)
>> +                goto skip_vtpm;
> Is the purpose of this so that you can have "empty" vtpm slots?
> (Since even when skipping, you still increment the num_vtpms counter?)
That would make a default vtpm with a randomly generated uuid and
backend=3Ddom0. Considering that were getting rid of the process model, i=
t
probably makes sense to force the user to specify a backend domain id
because no vtpm device will ever connect to dom0 anymore.

See comments about uuid below.
>
>> +            do {
>> +                while(*p =3D=3D ' ')
>> +                    ++p;
>> +                if ((p2 =3D strchr(p, '=3D')) =3D=3D NULL)
>> +                    break;
>> +                *p2 =3D '\0';
>> +                if (!strcmp(p, "backend")) {
>> +                    if(domain_qualifier_to_domid(p2 + 1, &(vtpm->back=
end_domid), 0))
>> +                    {
>> +                        fprintf(stderr, "Specified backend domain doe=
s not exist, defaulting to Dom0\n");
>> +                        vtpm->backend_domid =3D 0;
> So wait; if someone specifies a domain, and that turns out not to
> work, you just change it to 0?  It seems like if the *specified*
> domain doesn't exist, the command should fail instead of choosing
> something at random.
I agree.
>
>> +                    }
>> +                } else if(!strcmp(p, "uuid")) {
>> +                    if( libxl_uuid_from_string(&vtpm->uuid, p2 + 1) )=
 {
>> +                        fprintf(stderr, "Failed to parse vtpm UUID: %=
s\n", p2 + 1);
>> +                        exit(1);
>> +                    }
>> +                }
> If I'm parsing this right, it looks like you will just silently ignore
> other arguments -- it seems like throwing an error would be better;
> especially to catch things like typos.  Otherwise, if someone does
> something like "uid=3D[whatever]", it will act like uuid isn't there an=
d
> create a new one, instead of alerting the user to the fact that he'd
> made a typo in the config file.
The behavior here is there if the user passes an invalid uuid string it
will fail with a parse error, but if the user does not specify a uuid at
all, one will be randomly generated. Random generation happens in the
vtpm types constructor in the xl type system.

This brings up a bigger wart in the vtpm implementation.

Its kind of confusing now because the linux guest uses a tpmfront/back
pair to talk to the vtpm, and then vtpm uses another tpmfront/back pair
to talk to the manager. You have to specify the uuid on the vtpm's
tpmfront device because that is the device the manager sees. You do not
have to specify one on the linux domains device.

I'd argue that now, especially with the process model gone, the uuid
should be a parameter of the vtpm itself and not the tpmfront/back
communication channels.

The problem is that this uuid needs to specified by the "control domain"
or dom0. By attaching the uuid to the device, the manager can trust the
uuid attached to whoever is trying to connect to him.

One idea is to make the uuid a commandline parameter for the mini-os
domain and have the vtpm pass the id down to the manager. That means
however that any rogue domain could potentially connect to the manager
and send him someone elses uuid, and thus being able to access the vtpms
stored secrets.

However one could argue that no domain would be able to connect to the
manager to do this anyway because they would have to create a
tpmfront/back device pair and the only way to do that is to break into
the "control domain." If one can do this, then one could just as easily
set their device uuid to whatever they want.

I hope all that made sense. Do you see any flaws in my reasoning? If so
I should probably get uuids out of the vtpm devices and simplify this
whole thing.


>
>  -George



--------------ms020402040708000707080800
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIDyjCC
A8YwggMvoAMCAQICBD/xyf0wDQYJKoZIhvcNAQEFBQAwLzELMAkGA1UEBhMCVVMxDzANBgNV
BAoTBkpIVUFQTDEPMA0GA1UECxMGQklTRENBMB4XDTEwMDYxMTE4MjIwNloXDTEzMDYxMTE4
NTIwNlowZjELMAkGA1UEBhMCVVMxDzANBgNVBAoTBkpIVUFQTDEPMA0GA1UECxMGUGVvcGxl
MTUwFgYDVQQLEw9WUE5Hcm91cC1CSVNEQ0EwGwYDVQQDExRNYXR0aGV3IEUgRmlvcmF2YW50
ZTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAnpbwVSP6o1Nb5lcW7dd3yTo9iBJdi7qz
4nANOMFPK7JOy5npKN1iiousl28U/scUJES55gPwAWYJK3uVyQAsA4adgDKi5DoD1UHDQEwp
bY7iHLJeq0NPr4BqYNqnCFPbE6HC8zSJrr4qKn+gVUQT39SIFqdiIPJwZL8FYTRQ/zsCAwEA
AaOCAbYwggGyMAsGA1UdDwQEAwIHgDArBgNVHRAEJDAigA8yMDEwMDYxMTE4MjIwNlqBDzIw
MTIwNzE3MjI1MjA2WjAbBg0rBgEEAbMlCwMBAQEBBAoWCGZpb3JhbWUxMBsGDSsGAQQBsyUL
AwEBAQIEChIIMDAxMDQyNjEwWAYJYIZIAYb6ax4BBEsMSVRoZSBwcml2YXRlIGtleSBjb3Jy
ZXNwb25kaW5nIHRvIHRoaXMgY2VydGlmaWNhdGUgbWF5IGhhdmUgYmVlbiBleHBvcnRlZC4w
KAYDVR0RBCEwH4EdTWF0dGhldy5GaW9yYXZhbnRlQGpodWFwbC5lZHUwUgYDVR0fBEswSTBH
oEWgQ6RBMD8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJU0RD
QTEOMAwGA1UEAxMFQ1JMNTYwHwYDVR0jBBgwFoAUCDUpmxH52EU2CyWmF2EJMB1yqeswHQYD
VR0OBBYEFO6LYxg6r9wHZ+zdQtBHn1dZ/YTNMAkGA1UdEwQCMAAwGQYJKoZIhvZ9B0EABAww
ChsEVjcuMQMCBLAwDQYJKoZIhvcNAQEFBQADgYEAJO9HQh4YNChVLzuZqK5ARJARD8JoujGZ
fdo75quvg2jXFQe2sEjvLnxJZgm/pv8fdZakq48CWwjYHKuvIp7sDjTEsQfo+y7SpN/N2NvJ
WU5SqfK1VgYtNLRRoGJUB5Q1aZ+Dg95g3kqpyfpUMISJL8IKVLtJVfN4fggFVUYZ9wwxggGr
MIIBpwIBATA3MC8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJ
U0RDQQIEP/HJ/TAJBgUrDgMCGgUAoIHLMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ
KoZIhvcNAQkFMQ8XDTEyMDkyODE2MDYwMVowIwYJKoZIhvcNAQkEMRYEFNIfLvKkGMOnk7A6
R71FJwslJK9VMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAK
BggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI
KoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEgYALhtVVjz0Wn0Pd1hnlS7/uSh86DWsdP40B
I1HsTsIVinrgJtB5FAsuFB16y1pLf0mKTIKMwWm/USdVN47bxXGwZlxSaFEpggB3BzdyBs2y
xrlz5EhnRo/vQ7PyRosEYOgKZ1v5Xwntz2MameDUcWls/RU4iLZGkksnG9bx+dWwQAAAAAAA
AA==
--------------ms020402040708000707080800--


--===============3695380679684712031==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============3695380679684712031==--


From xen-devel-bounces@lists.xen.org Fri Sep 28 16:07:57 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Sep 2012 16: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 1THd6G-0000P1-IX; Fri, 28 Sep 2012 16:07:36 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <matthew.fioravante@jhuapl.edu>) id 1THd6E-0000Ov-5k
	for xen-devel@lists.xen.org; Fri, 28 Sep 2012 16:07:34 +0000
Received: from [85.158.137.99:18513] by server-14.bemta-3.messagelabs.com id
	81/17-25886-54BC5605; Fri, 28 Sep 2012 16:07:33 +0000
X-Env-Sender: matthew.fioravante@jhuapl.edu
X-Msg-Ref: server-10.tower-217.messagelabs.com!1348848449!19429606!1
X-Originating-IP: [128.244.251.36]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG,
	UNPARSEABLE_RELAY
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27042 invoked from network); 28 Sep 2012 16:07:30 -0000
Received: from pilot.jhuapl.edu (HELO jhuapl.edu) (128.244.251.36)
	by server-10.tower-217.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 28 Sep 2012 16:07:30 -0000
Received: from ([128.244.207.89])
	by pilot.jhuapl.edu with ESMTP with TLS id 63GHCH1.153884838;
	Fri, 28 Sep 2012 12:07:21 -0400
Message-ID: <5065CAE9.30602@jhuapl.edu>
Date: Fri, 28 Sep 2012 12:06:01 -0400
From: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120827 Thunderbird/15.0
MIME-Version: 1.0
To: George Dunlap <George.Dunlap@eu.citrix.com>
References: <1348765860-11359-1-git-send-email-matthew.fioravante@jhuapl.edu>
	<1348765860-11359-3-git-send-email-matthew.fioravante@jhuapl.edu>
	<CAFLBxZbvK0WxHhQgY79vCG21fd8b4i=vuVhtFjrpN-saXM61bA@mail.gmail.com>
In-Reply-To: <CAFLBxZbvK0WxHhQgY79vCG21fd8b4i=vuVhtFjrpN-saXM61bA@mail.gmail.com>
X-Enigmail-Version: 1.4.4
Cc: "Ian.Campbell@citrix.com" <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 11/11] add vtpm support to libxl
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============3695380679684712031=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a cryptographically signed message in MIME format.

--===============3695380679684712031==
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms020402040708000707080800"

This is a cryptographically signed message in MIME format.

--------------ms020402040708000707080800
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On 09/28/2012 11:03 AM, George Dunlap wrote:
> On Thu, Sep 27, 2012 at 6:11 PM, Matthew Fioravante
> <matthew.fioravante@jhuapl.edu> wrote:
>> This patch adds vtpm support to libxl. It adds vtpm parsing to config
>> files and 3 new xl commands:
>> vtpm-attach
>> vtpm-detach
>> vtpm-list
>>
>> Signed-off-by: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
> Overall looks good to me -- just a few comments below about the config
> file handling (see below).
>
> Thanks for all your work on this.
>
>> @@ -601,6 +605,8 @@ static void domcreate_bootloader_done(libxl__egc *=
egc,
>>  static void domcreate_launch_dm(libxl__egc *egc, libxl__multidev *aod=
evs,
>>                                  int ret);
>>
>> +static void domcreate_attach_vtpms(libxl__egc *egc, libxl__multidev *=
multidev,
>> +                                   int ret);
>>  static void domcreate_attach_pci(libxl__egc *egc, libxl__multidev *ao=
devs,
>>                                   int ret);
>>
>> @@ -1084,13 +1090,13 @@ static void domcreate_devmodel_started(libxl__=
egc *egc,
>>      if (d_config->num_nics > 0) {
>>          /* Attach nics */
>>          libxl__multidev_begin(ao, &dcs->multidev);
>> -        dcs->multidev.callback =3D domcreate_attach_pci;
>> +        dcs->multidev.callback =3D domcreate_attach_vtpms;
> Wow -- what a weird convention you've had to try to figure out and
> modify here.  Well done. :-)
It was really tricky. Is there no better way to handle asynchronous
code? This method seems really error prone and almost impossible to follo=
w.
>
>>          libxl__add_nics(egc, ao, domid, d_config, &dcs->multidev);
>>          libxl__multidev_prepared(egc, &dcs->multidev, 0);
>>          return;
>>      }
>>
>> -    domcreate_attach_pci(egc, &dcs->multidev, 0);
>> +    domcreate_attach_vtpms(egc, &dcs->multidev, 0);
>>      return;
>>
>>  error_out:
>> @@ -1098,6 +1104,36 @@ error_out:
>>      domcreate_complete(egc, dcs, ret);
>>  }
>>
>> +static void domcreate_attach_vtpms(libxl__egc *egc, libxl__multidev *=
multidev, int ret) {
>> +   libxl__domain_create_state *dcs =3D CONTAINER_OF(multidev, *dcs, m=
ultidev);
>> +   STATE_AO_GC(dcs->ao);
>> +   int domid =3D dcs->guest_domid;
>> +
>> +   libxl_domain_config* const d_config =3D dcs->guest_config;
>> +
>> +   if(ret) {
>> +      LOG(ERROR, "unable to add nic devices");
>> +      goto error_out;
>> +   }
>> +
>> +    /* Plug vtpm devices */
>> +    if (d_config->num_vtpms > 0) {
>> +        /* Attach vtpms */
>> +        libxl__multidev_begin(ao, &dcs->multidev);
>> +        dcs->multidev.callback =3D domcreate_attach_pci;
>> +        libxl__add_vtpms(egc, ao, domid, d_config, &dcs->multidev);
>> +        libxl__multidev_prepared(egc, &dcs->multidev, 0);
>> +        return;
>> +    }
>> +
>> +   domcreate_attach_pci(egc, multidev, 0);
>> +   return;
>> +
>> +error_out:
>> +   assert(ret);
>> +   domcreate_complete(egc, dcs, ret);
>> +}
>> +
>>  static void domcreate_attach_pci(libxl__egc *egc, libxl__multidev *mu=
ltidev,
>>                                   int ret)
>>  {
>> @@ -1111,7 +1147,7 @@ static void domcreate_attach_pci(libxl__egc *egc=
, libxl__multidev *multidev,
>>      libxl_domain_config *const d_config =3D dcs->guest_config;
>>
>>      if (ret) {
>> -        LOG(ERROR, "unable to add nic devices");
>> +        LOG(ERROR, "unable to add vtpm devices");
>>          goto error_out;
>>      }
>>
> [snip]
>> @@ -1045,6 +1045,47 @@ static void parse_config_data(const char *confi=
g_source,
>>          }
>>      }
>>
>> +    if (!xlu_cfg_get_list(config, "vtpm", &vtpms, 0, 0)) {
>> +        d_config->num_vtpms =3D 0;
>> +        d_config->vtpms =3D NULL;
>> +        while ((buf =3D xlu_cfg_get_listitem (vtpms, d_config->num_vt=
pms)) !=3D NULL) {
>> +            libxl_device_vtpm *vtpm;
>> +            char * buf2 =3D strdup(buf);
>> +            char *p, *p2;
>> +
>> +            d_config->vtpms =3D (libxl_device_vtpm *) realloc(d_confi=
g->vtpms, sizeof(libxl_device_vtpm) * (d_config->num_vtpms+1));
>> +            vtpm =3D d_config->vtpms + d_config->num_vtpms;
>> +            libxl_device_vtpm_init(vtpm);
>> +            vtpm->devid =3D d_config->num_vtpms;
>> +
>> +            p =3D strtok(buf2, ",");
>> +            if (!p)
>> +                goto skip_vtpm;
> Is the purpose of this so that you can have "empty" vtpm slots?
> (Since even when skipping, you still increment the num_vtpms counter?)
That would make a default vtpm with a randomly generated uuid and
backend=3Ddom0. Considering that were getting rid of the process model, i=
t
probably makes sense to force the user to specify a backend domain id
because no vtpm device will ever connect to dom0 anymore.

See comments about uuid below.
>
>> +            do {
>> +                while(*p =3D=3D ' ')
>> +                    ++p;
>> +                if ((p2 =3D strchr(p, '=3D')) =3D=3D NULL)
>> +                    break;
>> +                *p2 =3D '\0';
>> +                if (!strcmp(p, "backend")) {
>> +                    if(domain_qualifier_to_domid(p2 + 1, &(vtpm->back=
end_domid), 0))
>> +                    {
>> +                        fprintf(stderr, "Specified backend domain doe=
s not exist, defaulting to Dom0\n");
>> +                        vtpm->backend_domid =3D 0;
> So wait; if someone specifies a domain, and that turns out not to
> work, you just change it to 0?  It seems like if the *specified*
> domain doesn't exist, the command should fail instead of choosing
> something at random.
I agree.
>
>> +                    }
>> +                } else if(!strcmp(p, "uuid")) {
>> +                    if( libxl_uuid_from_string(&vtpm->uuid, p2 + 1) )=
 {
>> +                        fprintf(stderr, "Failed to parse vtpm UUID: %=
s\n", p2 + 1);
>> +                        exit(1);
>> +                    }
>> +                }
> If I'm parsing this right, it looks like you will just silently ignore
> other arguments -- it seems like throwing an error would be better;
> especially to catch things like typos.  Otherwise, if someone does
> something like "uid=3D[whatever]", it will act like uuid isn't there an=
d
> create a new one, instead of alerting the user to the fact that he'd
> made a typo in the config file.
The behavior here is there if the user passes an invalid uuid string it
will fail with a parse error, but if the user does not specify a uuid at
all, one will be randomly generated. Random generation happens in the
vtpm types constructor in the xl type system.

This brings up a bigger wart in the vtpm implementation.

Its kind of confusing now because the linux guest uses a tpmfront/back
pair to talk to the vtpm, and then vtpm uses another tpmfront/back pair
to talk to the manager. You have to specify the uuid on the vtpm's
tpmfront device because that is the device the manager sees. You do not
have to specify one on the linux domains device.

I'd argue that now, especially with the process model gone, the uuid
should be a parameter of the vtpm itself and not the tpmfront/back
communication channels.

The problem is that this uuid needs to specified by the "control domain"
or dom0. By attaching the uuid to the device, the manager can trust the
uuid attached to whoever is trying to connect to him.

One idea is to make the uuid a commandline parameter for the mini-os
domain and have the vtpm pass the id down to the manager. That means
however that any rogue domain could potentially connect to the manager
and send him someone elses uuid, and thus being able to access the vtpms
stored secrets.

However one could argue that no domain would be able to connect to the
manager to do this anyway because they would have to create a
tpmfront/back device pair and the only way to do that is to break into
the "control domain." If one can do this, then one could just as easily
set their device uuid to whatever they want.

I hope all that made sense. Do you see any flaws in my reasoning? If so
I should probably get uuids out of the vtpm devices and simplify this
whole thing.


>
>  -George



--------------ms020402040708000707080800
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIDyjCC
A8YwggMvoAMCAQICBD/xyf0wDQYJKoZIhvcNAQEFBQAwLzELMAkGA1UEBhMCVVMxDzANBgNV
BAoTBkpIVUFQTDEPMA0GA1UECxMGQklTRENBMB4XDTEwMDYxMTE4MjIwNloXDTEzMDYxMTE4
NTIwNlowZjELMAkGA1UEBhMCVVMxDzANBgNVBAoTBkpIVUFQTDEPMA0GA1UECxMGUGVvcGxl
MTUwFgYDVQQLEw9WUE5Hcm91cC1CSVNEQ0EwGwYDVQQDExRNYXR0aGV3IEUgRmlvcmF2YW50
ZTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAnpbwVSP6o1Nb5lcW7dd3yTo9iBJdi7qz
4nANOMFPK7JOy5npKN1iiousl28U/scUJES55gPwAWYJK3uVyQAsA4adgDKi5DoD1UHDQEwp
bY7iHLJeq0NPr4BqYNqnCFPbE6HC8zSJrr4qKn+gVUQT39SIFqdiIPJwZL8FYTRQ/zsCAwEA
AaOCAbYwggGyMAsGA1UdDwQEAwIHgDArBgNVHRAEJDAigA8yMDEwMDYxMTE4MjIwNlqBDzIw
MTIwNzE3MjI1MjA2WjAbBg0rBgEEAbMlCwMBAQEBBAoWCGZpb3JhbWUxMBsGDSsGAQQBsyUL
AwEBAQIEChIIMDAxMDQyNjEwWAYJYIZIAYb6ax4BBEsMSVRoZSBwcml2YXRlIGtleSBjb3Jy
ZXNwb25kaW5nIHRvIHRoaXMgY2VydGlmaWNhdGUgbWF5IGhhdmUgYmVlbiBleHBvcnRlZC4w
KAYDVR0RBCEwH4EdTWF0dGhldy5GaW9yYXZhbnRlQGpodWFwbC5lZHUwUgYDVR0fBEswSTBH
oEWgQ6RBMD8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJU0RD
QTEOMAwGA1UEAxMFQ1JMNTYwHwYDVR0jBBgwFoAUCDUpmxH52EU2CyWmF2EJMB1yqeswHQYD
VR0OBBYEFO6LYxg6r9wHZ+zdQtBHn1dZ/YTNMAkGA1UdEwQCMAAwGQYJKoZIhvZ9B0EABAww
ChsEVjcuMQMCBLAwDQYJKoZIhvcNAQEFBQADgYEAJO9HQh4YNChVLzuZqK5ARJARD8JoujGZ
fdo75quvg2jXFQe2sEjvLnxJZgm/pv8fdZakq48CWwjYHKuvIp7sDjTEsQfo+y7SpN/N2NvJ
WU5SqfK1VgYtNLRRoGJUB5Q1aZ+Dg95g3kqpyfpUMISJL8IKVLtJVfN4fggFVUYZ9wwxggGr
MIIBpwIBATA3MC8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJ
U0RDQQIEP/HJ/TAJBgUrDgMCGgUAoIHLMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ
KoZIhvcNAQkFMQ8XDTEyMDkyODE2MDYwMVowIwYJKoZIhvcNAQkEMRYEFNIfLvKkGMOnk7A6
R71FJwslJK9VMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAK
BggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI
KoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEgYALhtVVjz0Wn0Pd1hnlS7/uSh86DWsdP40B
I1HsTsIVinrgJtB5FAsuFB16y1pLf0mKTIKMwWm/USdVN47bxXGwZlxSaFEpggB3BzdyBs2y
xrlz5EhnRo/vQ7PyRosEYOgKZ1v5Xwntz2MameDUcWls/RU4iLZGkksnG9bx+dWwQAAAAAAA
AA==
--------------ms020402040708000707080800--


--===============3695380679684712031==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============3695380679684712031==--


From xen-devel-bounces@lists.xen.org Fri Sep 28 16:08:36 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Sep 2012 16:08:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1THd6x-0000SS-4u; Fri, 28 Sep 2012 16:08:19 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <raistlin@linux.it>) id 1THd6v-0000Rx-F7
	for xen-devel@lists.xen.org; Fri, 28 Sep 2012 16:08:17 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-3.tower-27.messagelabs.com!1348848490!10799766!1
X-Originating-IP: [193.205.80.99]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26776 invoked from network); 28 Sep 2012 16:08:11 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-3.tower-27.messagelabs.com with SMTP;
	28 Sep 2012 16:08:11 -0000
Received: from [213.136.170.103] (account d.faggioli@sssup.it HELO
	[192.168.0.20]) by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 81598558; Fri, 28 Sep 2012 18:08:10 +0200
Message-ID: <1348848483.3153.23.camel@Abyss>
From: Dario Faggioli <raistlin@linux.it>
To: George Shuklin <george.shuklin@gmail.com>
Date: Fri, 28 Sep 2012 18:08:03 +0200
In-Reply-To: <50646FBF.9000501@gmail.com>
References: <53b8c758-2675-42a7-b63f-4f9ad0006d84@default>
	<50646FBF.9000501@gmail.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] domain creation vs querying free memory (xend and
 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: multipart/mixed; boundary="===============0566294968547215967=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--===============0566294968547215967==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-HRi2zSrxLSIwtxRaohyp"


--=-HRi2zSrxLSIwtxRaohyp
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, 2012-09-27 at 19:24 +0400, George Shuklin wrote:=20
> not sure about xl/xm, but xapi performs one start at time, so there is=
=20
> no race between domains for memory or other resources.
>=20
IIRC, xl has a vary coarse grain locking mechanism in place for domain
creation too. As a result of that, you shouldn't be able to create two
domains at the same time, which should be enough for preventing the
situation described in the original e-mail for occurring.

Looking at acquire_lock() and release_lock() (and at where they are
called) in xl code should clarify whether or not that is enough to
actually avoid the race (which I think it is, but I might be wrong :-D).

That being said, there still is the room for races, although not wrt
domain creation, as, for instance, there isn't any synchronization
between creation and ballooning, which both manipulate memory. So, maybe
thinking about some kind of reservation-based/transactional mechanism at
some level might make actual sense.

Unfortunately, I've no idea about how xm works in that respect.

Hope this at least help clarifying the situation a bit. :-)

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)



--=-HRi2zSrxLSIwtxRaohyp
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)

iEYEABECAAYFAlBly2MACgkQk4XaBE3IOsTKgACfeejc+RdRhhGR3uW1HDQVY4Gm
krgAnjGBp2Es8sRvCH2T6JGx+ddWbjdV
=QcG8
-----END PGP SIGNATURE-----

--=-HRi2zSrxLSIwtxRaohyp--



--===============0566294968547215967==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============0566294968547215967==--



From xen-devel-bounces@lists.xen.org Fri Sep 28 16:08:36 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Sep 2012 16:08:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1THd6x-0000SS-4u; Fri, 28 Sep 2012 16:08:19 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <raistlin@linux.it>) id 1THd6v-0000Rx-F7
	for xen-devel@lists.xen.org; Fri, 28 Sep 2012 16:08:17 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-3.tower-27.messagelabs.com!1348848490!10799766!1
X-Originating-IP: [193.205.80.99]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26776 invoked from network); 28 Sep 2012 16:08:11 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-3.tower-27.messagelabs.com with SMTP;
	28 Sep 2012 16:08:11 -0000
Received: from [213.136.170.103] (account d.faggioli@sssup.it HELO
	[192.168.0.20]) by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 81598558; Fri, 28 Sep 2012 18:08:10 +0200
Message-ID: <1348848483.3153.23.camel@Abyss>
From: Dario Faggioli <raistlin@linux.it>
To: George Shuklin <george.shuklin@gmail.com>
Date: Fri, 28 Sep 2012 18:08:03 +0200
In-Reply-To: <50646FBF.9000501@gmail.com>
References: <53b8c758-2675-42a7-b63f-4f9ad0006d84@default>
	<50646FBF.9000501@gmail.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] domain creation vs querying free memory (xend and
 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: multipart/mixed; boundary="===============0566294968547215967=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org


--===============0566294968547215967==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-HRi2zSrxLSIwtxRaohyp"


--=-HRi2zSrxLSIwtxRaohyp
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, 2012-09-27 at 19:24 +0400, George Shuklin wrote:=20
> not sure about xl/xm, but xapi performs one start at time, so there is=
=20
> no race between domains for memory or other resources.
>=20
IIRC, xl has a vary coarse grain locking mechanism in place for domain
creation too. As a result of that, you shouldn't be able to create two
domains at the same time, which should be enough for preventing the
situation described in the original e-mail for occurring.

Looking at acquire_lock() and release_lock() (and at where they are
called) in xl code should clarify whether or not that is enough to
actually avoid the race (which I think it is, but I might be wrong :-D).

That being said, there still is the room for races, although not wrt
domain creation, as, for instance, there isn't any synchronization
between creation and ballooning, which both manipulate memory. So, maybe
thinking about some kind of reservation-based/transactional mechanism at
some level might make actual sense.

Unfortunately, I've no idea about how xm works in that respect.

Hope this at least help clarifying the situation a bit. :-)

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)



--=-HRi2zSrxLSIwtxRaohyp
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)

iEYEABECAAYFAlBly2MACgkQk4XaBE3IOsTKgACfeejc+RdRhhGR3uW1HDQVY4Gm
krgAnjGBp2Es8sRvCH2T6JGx+ddWbjdV
=QcG8
-----END PGP SIGNATURE-----

--=-HRi2zSrxLSIwtxRaohyp--



--===============0566294968547215967==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============0566294968547215967==--



From xen-devel-bounces@lists.xen.org Fri Sep 28 16:12:48 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Sep 2012 16: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 1THdB3-0000hU-Qu; Fri, 28 Sep 2012 16:12:33 +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 1THdB2-0000hN-5s
	for xen-devel@lists.xensource.com; Fri, 28 Sep 2012 16:12:32 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1348848744!5081440!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDc4MTcyOA==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24234 invoked from network); 28 Sep 2012 16:12:25 -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; 28 Sep 2012 16:12: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 q8SGCLAa031263
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 28 Sep 2012 16:12:22 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
	q8SGCKxQ006859
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 28 Sep 2012 16:12:20 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
	q8SGCJnI022055; Fri, 28 Sep 2012 11:12:19 -0500
Received: from localhost.localdomain (/10.154.179.198)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 28 Sep 2012 09:12:16 -0700
Date: Fri, 28 Sep 2012 12:21:35 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Daniel Kiper <daniel.kiper@oracle.com>
Message-ID: <20120928162132.GC16262@localhost.localdomain>
References: <1348769198-29580-1-git-send-email-daniel.kiper@oracle.com>
	<1348769198-29580-2-git-send-email-daniel.kiper@oracle.com>
	<1348769198-29580-3-git-send-email-daniel.kiper@oracle.com>
	<1348769198-29580-4-git-send-email-daniel.kiper@oracle.com>
	<1348769198-29580-5-git-send-email-daniel.kiper@oracle.com>
	<1348769198-29580-6-git-send-email-daniel.kiper@oracle.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1348769198-29580-6-git-send-email-daniel.kiper@oracle.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: andrew.cooper3@citrix.com, xen-devel@lists.xensource.com,
	linux-kernel@vger.kernel.org, jbeulich@suse.com
Subject: Re: [Xen-devel] [PATCH 05/11] x86/xen: Register resources required
	by kexec-tools
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Sep 27, 2012 at 08:06:32PM +0200, Daniel Kiper wrote:
> Register resources required by kexec-tools.
> 
> Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
> ---
>  arch/x86/xen/kexec.c |  150 ++++++++++++++++++++++++++++++++++++++++++++++++++
>  1 files changed, 150 insertions(+), 0 deletions(-)
>  create mode 100644 arch/x86/xen/kexec.c
> 
> diff --git a/arch/x86/xen/kexec.c b/arch/x86/xen/kexec.c
> new file mode 100644
> index 0000000..eb0108b
> --- /dev/null
> +++ b/arch/x86/xen/kexec.c
> @@ -0,0 +1,150 @@
> +/*
> + * Copyright (c) 2011 Daniel Kiper
> + * Copyright (c) 2012 Daniel Kiper, Oracle Corporation
> + *
> + * kexec/kdump implementation for Xen was written by Daniel Kiper.
> + * Initial work on it was sponsored by Google under Google Summer
> + * of Code 2011 program and Citrix. Konrad Rzeszutek Wilk from Oracle
> + * was the mentor for this project.
> + *
> + * Some ideas are taken from:
> + *   - native kexec/kdump implementation,
> + *   - kexec/kdump implementation for Xen Linux Kernel Ver. 2.6.18,
> + *   - PV-GRUB.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License along
> + * with this program.  If not, see <http://www.gnu.org/licenses/>.
> + */
> +
> +#include <linux/errno.h>
> +#include <linux/init.h>
> +#include <linux/ioport.h>
> +#include <linux/kernel.h>
> +#include <linux/kexec.h>
> +#include <linux/slab.h>
> +#include <linux/string.h>
> +
> +#include <xen/interface/platform.h>
> +#include <xen/interface/xen.h>
> +#include <xen/xen.h>
> +
> +#include <asm/xen/hypercall.h>
> +
> +unsigned long xen_vmcoreinfo_maddr = 0;
> +unsigned long xen_vmcoreinfo_max_size = 0;
> +
> +static int __init xen_init_kexec_resources(void)
> +{
> +	int rc;
> +	static struct resource xen_hypervisor_res = {
> +		.name = "Hypervisor code and data",
> +		.flags = IORESOURCE_BUSY | IORESOURCE_MEM
> +	};
> +	struct resource *cpu_res;
> +	struct xen_kexec_range xkr;
> +	struct xen_platform_op cpuinfo_op;
> +	uint32_t cpus, i;
> +
> +	if (!xen_initial_domain())
> +		return 0;
> +
> +	if (strstr(boot_command_line, "crashkernel="))
> +		pr_info("kexec: Ignoring crashkernel option. "

pr_warn?

> +			"It should be passed to Xen hypervisor.\n");
> +
> +	/* Register Crash kernel resource. */
> +	xkr.range = KEXEC_RANGE_MA_CRASH;
> +	rc = HYPERVISOR_kexec_op(KEXEC_CMD_kexec_get_range, &xkr);
> +
> +	if (rc) {
> +		pr_info("kexec: %s: HYPERVISOR_kexec_op(KEXEC_RANGE_MA_CRASH)"
> +			": %i\n", __func__, rc);

Perhaps pr_warn?
> +		return rc;
> +	}
> +
> +	if (!xkr.size)
> +		return 0;
> +
> +	crashk_res.start = xkr.start;
> +	crashk_res.end = xkr.start + xkr.size - 1;
> +	insert_resource(&iomem_resource, &crashk_res);
> +
> +	/* Register Hypervisor code and data resource. */
> +	xkr.range = KEXEC_RANGE_MA_XEN;
> +	rc = HYPERVISOR_kexec_op(KEXEC_CMD_kexec_get_range, &xkr);
> +
> +	if (rc) {
> +		pr_info("kexec: %s: HYPERVISOR_kexec_op(KEXEC_RANGE_MA_XEN)"

pr_warn
> +			": %i\n", __func__, rc);
> +		return rc;
> +	}
> +
> +	xen_hypervisor_res.start = xkr.start;
> +	xen_hypervisor_res.end = xkr.start + xkr.size - 1;
> +	insert_resource(&iomem_resource, &xen_hypervisor_res);
> +
> +	/* Determine maximum number of physical CPUs. */
> +	cpuinfo_op.cmd = XENPF_get_cpuinfo;
> +	cpuinfo_op.u.pcpu_info.xen_cpuid = 0;
> +	rc = HYPERVISOR_dom0_op(&cpuinfo_op);
> +
> +	if (rc) {
> +		pr_info("kexec: %s: HYPERVISOR_dom0_op(): %i\n", __func__, rc);

pr_warn.
> +		return rc;
> +	}
> +
> +	cpus = cpuinfo_op.u.pcpu_info.max_present + 1;

Do we care about the hotplug CPUs?
> +
> +	/* Register CPUs Crash note resources. */
> +	cpu_res = kcalloc(cpus, sizeof(struct resource), GFP_KERNEL);
> +
> +	if (!cpu_res) {
> +		pr_info("kexec: %s: kcalloc(): %i\n", __func__, -ENOMEM);
> +		return -ENOMEM;
> +	}
> +
> +	for (i = 0; i < cpus; ++i) {

Any specific reason for using '++i' instead of 'i++' ?

> +		xkr.range = KEXEC_RANGE_MA_CPU;
> +		xkr.nr = i;
> +		rc = HYPERVISOR_kexec_op(KEXEC_CMD_kexec_get_range, &xkr);
> +
> +		if (rc) {
> +			pr_info("kexec: %s: cpu: %u: HYPERVISOR_kexec_op"
> +				"(KEXEC_RANGE_MA_XEN): %i\n", __func__, i, rc);
> +			continue;
> +		}
> +
> +		cpu_res->name = "Crash note";
> +		cpu_res->start = xkr.start;
> +		cpu_res->end = xkr.start + xkr.size - 1;
> +		cpu_res->flags = IORESOURCE_BUSY | IORESOURCE_MEM;
> +		insert_resource(&iomem_resource, cpu_res++);
> +	}
> +
> +	/* Get vmcoreinfo address and maximum allowed size. */
> +	xkr.range = KEXEC_RANGE_MA_VMCOREINFO;
> +	rc = HYPERVISOR_kexec_op(KEXEC_CMD_kexec_get_range, &xkr);
> +
> +	if (rc) {
> +		pr_info("kexec: %s: HYPERVISOR_kexec_op(KEXEC_RANGE_MA_VMCOREINFO)"
> +			": %i\n", __func__, rc);
> +		return rc;
> +	}
> +
> +	xen_vmcoreinfo_maddr = xkr.start;
> +	xen_vmcoreinfo_max_size = xkr.size;
> +
> +	return 0;
> +}
> +
> +core_initcall(xen_init_kexec_resources);
> -- 
> 1.5.6.5

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 28 16:12:48 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Sep 2012 16: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 1THdB3-0000hU-Qu; Fri, 28 Sep 2012 16:12:33 +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 1THdB2-0000hN-5s
	for xen-devel@lists.xensource.com; Fri, 28 Sep 2012 16:12:32 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1348848744!5081440!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDc4MTcyOA==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24234 invoked from network); 28 Sep 2012 16:12:25 -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; 28 Sep 2012 16:12: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 q8SGCLAa031263
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 28 Sep 2012 16:12:22 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
	q8SGCKxQ006859
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 28 Sep 2012 16:12:20 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
	q8SGCJnI022055; Fri, 28 Sep 2012 11:12:19 -0500
Received: from localhost.localdomain (/10.154.179.198)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 28 Sep 2012 09:12:16 -0700
Date: Fri, 28 Sep 2012 12:21:35 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Daniel Kiper <daniel.kiper@oracle.com>
Message-ID: <20120928162132.GC16262@localhost.localdomain>
References: <1348769198-29580-1-git-send-email-daniel.kiper@oracle.com>
	<1348769198-29580-2-git-send-email-daniel.kiper@oracle.com>
	<1348769198-29580-3-git-send-email-daniel.kiper@oracle.com>
	<1348769198-29580-4-git-send-email-daniel.kiper@oracle.com>
	<1348769198-29580-5-git-send-email-daniel.kiper@oracle.com>
	<1348769198-29580-6-git-send-email-daniel.kiper@oracle.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1348769198-29580-6-git-send-email-daniel.kiper@oracle.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: andrew.cooper3@citrix.com, xen-devel@lists.xensource.com,
	linux-kernel@vger.kernel.org, jbeulich@suse.com
Subject: Re: [Xen-devel] [PATCH 05/11] x86/xen: Register resources required
	by kexec-tools
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Sep 27, 2012 at 08:06:32PM +0200, Daniel Kiper wrote:
> Register resources required by kexec-tools.
> 
> Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
> ---
>  arch/x86/xen/kexec.c |  150 ++++++++++++++++++++++++++++++++++++++++++++++++++
>  1 files changed, 150 insertions(+), 0 deletions(-)
>  create mode 100644 arch/x86/xen/kexec.c
> 
> diff --git a/arch/x86/xen/kexec.c b/arch/x86/xen/kexec.c
> new file mode 100644
> index 0000000..eb0108b
> --- /dev/null
> +++ b/arch/x86/xen/kexec.c
> @@ -0,0 +1,150 @@
> +/*
> + * Copyright (c) 2011 Daniel Kiper
> + * Copyright (c) 2012 Daniel Kiper, Oracle Corporation
> + *
> + * kexec/kdump implementation for Xen was written by Daniel Kiper.
> + * Initial work on it was sponsored by Google under Google Summer
> + * of Code 2011 program and Citrix. Konrad Rzeszutek Wilk from Oracle
> + * was the mentor for this project.
> + *
> + * Some ideas are taken from:
> + *   - native kexec/kdump implementation,
> + *   - kexec/kdump implementation for Xen Linux Kernel Ver. 2.6.18,
> + *   - PV-GRUB.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License along
> + * with this program.  If not, see <http://www.gnu.org/licenses/>.
> + */
> +
> +#include <linux/errno.h>
> +#include <linux/init.h>
> +#include <linux/ioport.h>
> +#include <linux/kernel.h>
> +#include <linux/kexec.h>
> +#include <linux/slab.h>
> +#include <linux/string.h>
> +
> +#include <xen/interface/platform.h>
> +#include <xen/interface/xen.h>
> +#include <xen/xen.h>
> +
> +#include <asm/xen/hypercall.h>
> +
> +unsigned long xen_vmcoreinfo_maddr = 0;
> +unsigned long xen_vmcoreinfo_max_size = 0;
> +
> +static int __init xen_init_kexec_resources(void)
> +{
> +	int rc;
> +	static struct resource xen_hypervisor_res = {
> +		.name = "Hypervisor code and data",
> +		.flags = IORESOURCE_BUSY | IORESOURCE_MEM
> +	};
> +	struct resource *cpu_res;
> +	struct xen_kexec_range xkr;
> +	struct xen_platform_op cpuinfo_op;
> +	uint32_t cpus, i;
> +
> +	if (!xen_initial_domain())
> +		return 0;
> +
> +	if (strstr(boot_command_line, "crashkernel="))
> +		pr_info("kexec: Ignoring crashkernel option. "

pr_warn?

> +			"It should be passed to Xen hypervisor.\n");
> +
> +	/* Register Crash kernel resource. */
> +	xkr.range = KEXEC_RANGE_MA_CRASH;
> +	rc = HYPERVISOR_kexec_op(KEXEC_CMD_kexec_get_range, &xkr);
> +
> +	if (rc) {
> +		pr_info("kexec: %s: HYPERVISOR_kexec_op(KEXEC_RANGE_MA_CRASH)"
> +			": %i\n", __func__, rc);

Perhaps pr_warn?
> +		return rc;
> +	}
> +
> +	if (!xkr.size)
> +		return 0;
> +
> +	crashk_res.start = xkr.start;
> +	crashk_res.end = xkr.start + xkr.size - 1;
> +	insert_resource(&iomem_resource, &crashk_res);
> +
> +	/* Register Hypervisor code and data resource. */
> +	xkr.range = KEXEC_RANGE_MA_XEN;
> +	rc = HYPERVISOR_kexec_op(KEXEC_CMD_kexec_get_range, &xkr);
> +
> +	if (rc) {
> +		pr_info("kexec: %s: HYPERVISOR_kexec_op(KEXEC_RANGE_MA_XEN)"

pr_warn
> +			": %i\n", __func__, rc);
> +		return rc;
> +	}
> +
> +	xen_hypervisor_res.start = xkr.start;
> +	xen_hypervisor_res.end = xkr.start + xkr.size - 1;
> +	insert_resource(&iomem_resource, &xen_hypervisor_res);
> +
> +	/* Determine maximum number of physical CPUs. */
> +	cpuinfo_op.cmd = XENPF_get_cpuinfo;
> +	cpuinfo_op.u.pcpu_info.xen_cpuid = 0;
> +	rc = HYPERVISOR_dom0_op(&cpuinfo_op);
> +
> +	if (rc) {
> +		pr_info("kexec: %s: HYPERVISOR_dom0_op(): %i\n", __func__, rc);

pr_warn.
> +		return rc;
> +	}
> +
> +	cpus = cpuinfo_op.u.pcpu_info.max_present + 1;

Do we care about the hotplug CPUs?
> +
> +	/* Register CPUs Crash note resources. */
> +	cpu_res = kcalloc(cpus, sizeof(struct resource), GFP_KERNEL);
> +
> +	if (!cpu_res) {
> +		pr_info("kexec: %s: kcalloc(): %i\n", __func__, -ENOMEM);
> +		return -ENOMEM;
> +	}
> +
> +	for (i = 0; i < cpus; ++i) {

Any specific reason for using '++i' instead of 'i++' ?

> +		xkr.range = KEXEC_RANGE_MA_CPU;
> +		xkr.nr = i;
> +		rc = HYPERVISOR_kexec_op(KEXEC_CMD_kexec_get_range, &xkr);
> +
> +		if (rc) {
> +			pr_info("kexec: %s: cpu: %u: HYPERVISOR_kexec_op"
> +				"(KEXEC_RANGE_MA_XEN): %i\n", __func__, i, rc);
> +			continue;
> +		}
> +
> +		cpu_res->name = "Crash note";
> +		cpu_res->start = xkr.start;
> +		cpu_res->end = xkr.start + xkr.size - 1;
> +		cpu_res->flags = IORESOURCE_BUSY | IORESOURCE_MEM;
> +		insert_resource(&iomem_resource, cpu_res++);
> +	}
> +
> +	/* Get vmcoreinfo address and maximum allowed size. */
> +	xkr.range = KEXEC_RANGE_MA_VMCOREINFO;
> +	rc = HYPERVISOR_kexec_op(KEXEC_CMD_kexec_get_range, &xkr);
> +
> +	if (rc) {
> +		pr_info("kexec: %s: HYPERVISOR_kexec_op(KEXEC_RANGE_MA_VMCOREINFO)"
> +			": %i\n", __func__, rc);
> +		return rc;
> +	}
> +
> +	xen_vmcoreinfo_maddr = xkr.start;
> +	xen_vmcoreinfo_max_size = xkr.size;
> +
> +	return 0;
> +}
> +
> +core_initcall(xen_init_kexec_resources);
> -- 
> 1.5.6.5

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 28 16:29:34 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Sep 2012 16: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 1THdRG-0000tq-DP; Fri, 28 Sep 2012 16:29:18 +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 1THdRE-0000tl-DD
	for xen-devel@lists.xensource.com; Fri, 28 Sep 2012 16:29:16 +0000
Received: from [85.158.139.211:51101] by server-8.bemta-5.messagelabs.com id
	1B/D0-18073-B50D5605; Fri, 28 Sep 2012 16:29:15 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-10.tower-206.messagelabs.com!1348849753!20333988!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDc4MTcyOA==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13602 invoked from network); 28 Sep 2012 16:29:14 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-10.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 28 Sep 2012 16:29:14 -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 q8SGTBfj017576
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 28 Sep 2012 16:29:11 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q8SGTAmq022534
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 28 Sep 2012 16:29:10 GMT
Received: from abhmt110.oracle.com (abhmt110.oracle.com [141.146.116.62])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q8SGTAlk004588; Fri, 28 Sep 2012 11:29:10 -0500
Received: from localhost.localdomain (/10.154.179.198)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 28 Sep 2012 09:29:05 -0700
Date: Fri, 28 Sep 2012 12:39:44 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Daniel Kiper <daniel.kiper@oracle.com>
Message-ID: <20120928163941.GD16262@localhost.localdomain>
References: <1348769198-29580-1-git-send-email-daniel.kiper@oracle.com>
	<1348769198-29580-2-git-send-email-daniel.kiper@oracle.com>
	<1348769198-29580-3-git-send-email-daniel.kiper@oracle.com>
	<1348769198-29580-4-git-send-email-daniel.kiper@oracle.com>
	<1348769198-29580-5-git-send-email-daniel.kiper@oracle.com>
	<1348769198-29580-6-git-send-email-daniel.kiper@oracle.com>
	<1348769198-29580-7-git-send-email-daniel.kiper@oracle.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1348769198-29580-7-git-send-email-daniel.kiper@oracle.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: andrew.cooper3@citrix.com, xen-devel@lists.xensource.com,
	linux-kernel@vger.kernel.org, jbeulich@suse.com
Subject: Re: [Xen-devel] [PATCH 06/11] x86/xen: Add i386 kexec/kdump
	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 Thu, Sep 27, 2012 at 08:06:33PM +0200, Daniel Kiper wrote:
> Add i386 kexec/kdump implementation.
> 
> Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
> ---
>  arch/x86/xen/machine_kexec_32.c   |  245 ++++++++++++++++++++++++++++
>  arch/x86/xen/relocate_kernel_32.S |  323 +++++++++++++++++++++++++++++++++++++
>  2 files changed, 568 insertions(+), 0 deletions(-)
>  create mode 100644 arch/x86/xen/machine_kexec_32.c
>  create mode 100644 arch/x86/xen/relocate_kernel_32.S
> 
> diff --git a/arch/x86/xen/machine_kexec_32.c b/arch/x86/xen/machine_kexec_32.c
> new file mode 100644
> index 0000000..6b5141e
> --- /dev/null
> +++ b/arch/x86/xen/machine_kexec_32.c
> @@ -0,0 +1,245 @@
> +/*
> + * Copyright (c) 2011 Daniel Kiper
> + * Copyright (c) 2012 Daniel Kiper, Oracle Corporation
> + *
> + * kexec/kdump implementation for Xen was written by Daniel Kiper.
> + * Initial work on it was sponsored by Google under Google Summer
> + * of Code 2011 program and Citrix. Konrad Rzeszutek Wilk from Oracle
> + * was the mentor for this project.
> + *
> + * Some ideas are taken from:
> + *   - native kexec/kdump implementation,
> + *   - kexec/kdump implementation for Xen Linux Kernel Ver. 2.6.18,
> + *   - PV-GRUB.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License along
> + * with this program.  If not, see <http://www.gnu.org/licenses/>.
> + */
> +
> +#include <linux/errno.h>
> +#include <linux/init.h>
> +#include <linux/kernel.h>
> +#include <linux/kexec.h>
> +#include <linux/mm.h>
> +#include <linux/string.h>
> +
> +#include <xen/xen.h>
> +#include <xen/xen-ops.h>
> +
> +#include <asm/xen/hypercall.h>
> +#include <asm/xen/kexec.h>
> +#include <asm/xen/page.h>
> +
> +#define __ma(vaddr)	(virt_to_machine(vaddr).maddr)
> +
> +static struct page *kimage_alloc_pages(gfp_t gfp_mask,
> +					unsigned int order,
> +					unsigned long limit)
> +{
> +	struct page *pages;
> +	unsigned int address_bits, i;
> +
> +	pages = alloc_pages(gfp_mask, order);
> +
> +	if (!pages)
> +		return NULL;
> +
> +	address_bits = (limit == ULONG_MAX) ? BITS_PER_LONG : ilog2(limit);
> +
> +	/* Relocate set of pages below given limit. */
> +	if (xen_create_contiguous_region((unsigned long)page_address(pages),
> +							order, address_bits)) {
> +		__free_pages(pages, order);
> +		return NULL;
> +	}
> +
> +	pages->mapping = NULL;

It shouldn't matter (as you did the alloc_page) but could you
add:
	BUG_ON(PagePrivate(pages))
in case somebody did do something weird beforehand.

> +	set_page_private(pages, order);
> +
> +	for (i = 0; i < (1 << order); ++i)
> +		SetPageReserved(pages + i);
> +
> +	return pages;
> +}
> +
> +static void kimage_free_pages(struct page *page)
> +{
> +	unsigned int i, order;
> +
> +	order = page_private(page);
> +
> +	for (i = 0; i < (1 << order); ++i)
> +		ClearPageReserved(page + i);
> +
> +	xen_destroy_contiguous_region((unsigned long)page_address(page), order);
> +	__free_pages(page, order);
> +}
> +
> +static unsigned long xen_page_to_mfn(struct page *page)
> +{
> +	return pfn_to_mfn(page_to_pfn(page));
> +}
> +
> +static struct page *xen_mfn_to_page(unsigned long mfn)
> +{
> +	return pfn_to_page(mfn_to_pfn(mfn));
> +}
> +
> +static unsigned long xen_virt_to_machine(volatile void *address)
> +{
> +	return virt_to_machine(address).maddr;
> +}
> +
> +static void *xen_machine_to_virt(unsigned long address)
> +{
> +	return phys_to_virt(machine_to_phys(XMADDR(address)).paddr);
> +}
> +
> +static void free_transition_pgtable(struct kimage *image)
> +{
> +	free_page((unsigned long)image->arch.pgd);
> +	free_page((unsigned long)image->arch.pmd0);
> +	free_page((unsigned long)image->arch.pmd1);
> +	free_page((unsigned long)image->arch.pte0);
> +	free_page((unsigned long)image->arch.pte1);
> +}
> +
> +static int alloc_transition_pgtable(struct kimage *image)
> +{
> +	image->arch.pgd = (pgd_t *)get_zeroed_page(GFP_KERNEL);
> +
> +	if (!image->arch.pgd)
> +		goto err;
> +
> +	image->arch.pmd0 = (pmd_t *)get_zeroed_page(GFP_KERNEL);
> +
> +	if (!image->arch.pmd0)
> +		goto err;
> +
> +	image->arch.pmd1 = (pmd_t *)get_zeroed_page(GFP_KERNEL);
> +
> +	if (!image->arch.pmd1)
> +		goto err;
> +
> +	image->arch.pte0 = (pte_t *)get_zeroed_page(GFP_KERNEL);
> +
> +	if (!image->arch.pte0)
> +		goto err;
> +
> +	image->arch.pte1 = (pte_t *)get_zeroed_page(GFP_KERNEL);
> +
> +	if (!image->arch.pte1)
> +		goto err;
> +
> +	return 0;
> +
> +err:
> +	free_transition_pgtable(image);
> +
> +	return -ENOMEM;
> +}
> +
> +static int machine_xen_kexec_prepare(struct kimage *image)
> +{
> +#ifdef CONFIG_KEXEC_JUMP
> +	if (image->preserve_context) {
> +		pr_info_once("kexec: Context preservation is not "
> +				"supported in Xen domains.\n");
> +		return -ENOSYS;
> +	}
> +#endif
> +
> +	return alloc_transition_pgtable(image);
> +}
> +
> +static int machine_xen_kexec_load(struct kimage *image)
> +{
> +	void *control_page;
> +	struct xen_kexec_load xkl = {};
> +
> +	if (!image)
> +		return 0;

Not -EINVAL?

> +
> +	control_page = page_address(image->control_code_page);
> +	memcpy(control_page, xen_relocate_kernel, xen_kexec_control_code_size);
> +
> +	xkl.type = image->type;
> +	xkl.image.page_list[XK_MA_CONTROL_PAGE] = __ma(control_page);
> +	xkl.image.page_list[XK_MA_TABLE_PAGE] = 0; /* Unused. */
> +	xkl.image.page_list[XK_MA_PGD_PAGE] = __ma(image->arch.pgd);
> +	xkl.image.page_list[XK_MA_PUD0_PAGE] = 0; /* Unused. */
> +	xkl.image.page_list[XK_MA_PUD1_PAGE] = 0; /* Unused. */
> +	xkl.image.page_list[XK_MA_PMD0_PAGE] = __ma(image->arch.pmd0);
> +	xkl.image.page_list[XK_MA_PMD1_PAGE] = __ma(image->arch.pmd1);
> +	xkl.image.page_list[XK_MA_PTE0_PAGE] = __ma(image->arch.pte0);
> +	xkl.image.page_list[XK_MA_PTE1_PAGE] = __ma(image->arch.pte1);
> +	xkl.image.indirection_page = image->head;
> +	xkl.image.start_address = image->start;
> +
> +	return HYPERVISOR_kexec_op(KEXEC_CMD_kexec_load, &xkl);
> +}
> +
> +static void machine_xen_kexec_cleanup(struct kimage *image)
> +{
> +	free_transition_pgtable(image);
> +}
> +
> +static void machine_xen_kexec_unload(struct kimage *image)
> +{
> +	int rc;
> +	struct xen_kexec_load xkl = {};
> +
> +	if (!image)
> +		return;
> +
> +	xkl.type = image->type;
> +	rc = HYPERVISOR_kexec_op(KEXEC_CMD_kexec_unload, &xkl);
> +
> +	WARN(rc, "kexec: %s: HYPERVISOR_kexec_op(): %i\n", __func__, rc);
> +}
> +
> +static void machine_xen_kexec_shutdown(void)
> +{
> +}
> +
> +static void machine_xen_kexec(struct kimage *image)
> +{
> +	int rc;
> +	struct xen_kexec_exec xke = {};
> +
> +	xke.type = image->type;
> +	rc = HYPERVISOR_kexec_op(KEXEC_CMD_kexec, &xke);
> +
> +	pr_emerg("kexec: %s: HYPERVISOR_kexec_op(): %i\n", __func__, rc);
> +	BUG();
> +}
> +
> +void __init xen_init_kexec_ops(void)
> +{
> +	if (!xen_initial_domain())
> +		return;
> +
> +	kexec_ops.always_use_normal_alloc = true;
> +	kexec_ops.kimage_alloc_pages = kimage_alloc_pages;
> +	kexec_ops.kimage_free_pages = kimage_free_pages;
> +	kexec_ops.page_to_pfn = xen_page_to_mfn;
> +	kexec_ops.pfn_to_page = xen_mfn_to_page;
> +	kexec_ops.virt_to_phys = xen_virt_to_machine;
> +	kexec_ops.phys_to_virt = xen_machine_to_virt;
> +	kexec_ops.machine_kexec_prepare = machine_xen_kexec_prepare;
> +	kexec_ops.machine_kexec_load = machine_xen_kexec_load;
> +	kexec_ops.machine_kexec_cleanup = machine_xen_kexec_cleanup;
> +	kexec_ops.machine_kexec_unload = machine_xen_kexec_unload;
> +	kexec_ops.machine_kexec_shutdown = machine_xen_kexec_shutdown;
> +	kexec_ops.machine_kexec = machine_xen_kexec;
> +}
> diff --git a/arch/x86/xen/relocate_kernel_32.S b/arch/x86/xen/relocate_kernel_32.S
> new file mode 100644
> index 0000000..0e81830
> --- /dev/null
> +++ b/arch/x86/xen/relocate_kernel_32.S
> @@ -0,0 +1,323 @@
> +/*
> + * Copyright (c) 2002-2005 Eric Biederman <ebiederm@xmission.com>
> + * Copyright (c) 2011 Daniel Kiper
> + * Copyright (c) 2012 Daniel Kiper, Oracle Corporation
> + *
> + * kexec/kdump implementation for Xen was written by Daniel Kiper.
> + * Initial work on it was sponsored by Google under Google Summer
> + * of Code 2011 program and Citrix. Konrad Rzeszutek Wilk from Oracle
> + * was the mentor for this project.
> + *
> + * Some ideas are taken from:
> + *   - native kexec/kdump implementation,
> + *   - kexec/kdump implementation for Xen Linux Kernel Ver. 2.6.18,
> + *   - PV-GRUB.
> + *
> + * 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 veesion 2 of the License, or
> + * (at your option) any later veesion.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License along
> + * with this program.  If not, see <http://www.gnu.org/licenses/>.
> + */
> +
> +#include <asm/cache.h>
> +#include <asm/page_types.h>
> +#include <asm/pgtable_types.h>
> +#include <asm/processor-flags.h>
> +
> +#include <asm/xen/kexec.h>
> +
> +#define ARG_INDIRECTION_PAGE	0x4
> +#define ARG_PAGE_LIST		0x8
> +#define ARG_START_ADDRESS	0xc
> +
> +#define PTR(x)	(x << 2)
> +
> +	.text
> +	.align	PAGE_SIZE
> +	.globl	xen_kexec_control_code_size, xen_relocate_kernel
> +
> +xen_relocate_kernel:
> +	/*
> +	 * Must be relocatable PIC code callable as a C function.
> +	 *
> +	 * This function is called by Xen but here hypervisor is dead.
> +	 * We are playing on bare metal.
> +	 *
> +	 * Every machine address passed to this function through
> +	 * page_list (e.g. XK_MA_CONTROL_PAGE) is established
> +	 * by dom0 during kexec load phase.
> +	 *
> +	 * Every virtual address passed to this function through page_list
> +	 * (e.g. XK_VA_CONTROL_PAGE) is established by hypervisor during
> +	 * HYPERVISOR_kexec_op(KEXEC_CMD_kexec_load) hypercall.
> +	 *
> +	 * 0x4(%esp) - indirection_page,
> +	 * 0x8(%esp) - page_list,
> +	 * 0xc(%esp) - start_address,
> +	 * 0x10(%esp) - cpu_has_pae (ignored),
> +	 * 0x14(%esp) - preserve_context (ignored).
> +	 */
> +
> +	/* Zero out flags, and disable interrupts. */
> +	pushl	$0
> +	popfl
> +
> +	/* Get page_list address. */
> +	movl	ARG_PAGE_LIST(%esp), %esi
> +
> +	/*
> +	 * Map the control page at its virtual address
> +	 * in transition page table.
> +	 */
> +	movl	PTR(XK_VA_CONTROL_PAGE)(%esi), %eax
> +
> +	/* Get PGD address and PGD entry index. */
> +	movl	PTR(XK_VA_PGD_PAGE)(%esi), %ebx
> +	movl	%eax, %ecx
> +	shrl	$PGDIR_SHIFT, %ecx
> +	andl	$(PTRS_PER_PGD - 1), %ecx
> +
> +	/* Fill PGD entry with PMD0 reference. */
> +	movl	PTR(XK_MA_PMD0_PAGE)(%esi), %edx
> +	orl	$_PAGE_PRESENT, %edx
> +	movl	%edx, (%ebx, %ecx, 8)
> +
> +	/* Get PMD0 address and PMD0 entry index. */
> +	movl	PTR(XK_VA_PMD0_PAGE)(%esi), %ebx
> +	movl	%eax, %ecx
> +	shrl	$PMD_SHIFT, %ecx
> +	andl	$(PTRS_PER_PMD - 1), %ecx
> +
> +	/* Fill PMD0 entry with PTE0 reference. */
> +	movl	PTR(XK_MA_PTE0_PAGE)(%esi), %edx
> +	orl	$_KERNPG_TABLE, %edx
> +	movl	%edx, (%ebx, %ecx, 8)
> +
> +	/* Get PTE0 address and PTE0 entry index. */
> +	movl	PTR(XK_VA_PTE0_PAGE)(%esi), %ebx
> +	movl	%eax, %ecx
> +	shrl	$PAGE_SHIFT, %ecx
> +	andl	$(PTRS_PER_PTE - 1), %ecx
> +
> +	/* Fill PTE0 entry with control page reference. */
> +	movl	PTR(XK_MA_CONTROL_PAGE)(%esi), %edx
> +	orl	$__PAGE_KERNEL_EXEC, %edx
> +	movl	%edx, (%ebx, %ecx, 8)
> +
> +	/*
> +	 * Identity map the control page at its machine address
> +	 * in transition page table.
> +	 */
> +	movl	PTR(XK_MA_CONTROL_PAGE)(%esi), %eax
> +
> +	/* Get PGD address and PGD entry index. */
> +	movl	PTR(XK_VA_PGD_PAGE)(%esi), %ebx
> +	movl	%eax, %ecx
> +	shrl	$PGDIR_SHIFT, %ecx
> +	andl	$(PTRS_PER_PGD - 1), %ecx
> +
> +	/* Fill PGD entry with PMD1 reference. */
> +	movl	PTR(XK_MA_PMD1_PAGE)(%esi), %edx
> +	orl	$_PAGE_PRESENT, %edx
> +	movl	%edx, (%ebx, %ecx, 8)
> +
> +	/* Get PMD1 address and PMD1 entry index. */
> +	movl	PTR(XK_VA_PMD1_PAGE)(%esi), %ebx
> +	movl	%eax, %ecx
> +	shrl	$PMD_SHIFT, %ecx
> +	andl	$(PTRS_PER_PMD - 1), %ecx
> +
> +	/* Fill PMD1 entry with PTE1 reference. */
> +	movl	PTR(XK_MA_PTE1_PAGE)(%esi), %edx
> +	orl	$_KERNPG_TABLE, %edx
> +	movl	%edx, (%ebx, %ecx, 8)
> +
> +	/* Get PTE1 address and PTE1 entry index. */
> +	movl	PTR(XK_VA_PTE1_PAGE)(%esi), %ebx
> +	movl	%eax, %ecx
> +	shrl	$PAGE_SHIFT, %ecx
> +	andl	$(PTRS_PER_PTE - 1), %ecx
> +
> +	/* Fill PTE1 entry with control page reference. */
> +	movl	PTR(XK_MA_CONTROL_PAGE)(%esi), %edx
> +	orl	$__PAGE_KERNEL_EXEC, %edx
> +	movl	%edx, (%ebx, %ecx, 8)
> +
> +	/*
> +	 * Get machine address of control page now.
> +	 * This is impossible after page table switch.
> +	 */
> +	movl	PTR(XK_MA_CONTROL_PAGE)(%esi), %ebx
> +
> +	/* Get machine address of transition page table now too. */
> +	movl	PTR(XK_MA_PGD_PAGE)(%esi), %ecx
> +
> +	/* Get start_address too. */
> +	movl	ARG_START_ADDRESS(%esp), %edx
> +
> +	/* Get indirection_page address too. */
> +	movl	ARG_INDIRECTION_PAGE(%esp), %edi
> +
> +	/* Switch to transition page table. */
> +	movl	%ecx, %cr3
> +
> +	/* Load IDT. */
> +	lidtl	(idt_48 - xen_relocate_kernel)(%ebx)
> +
> +	/* Load GDT. */
> +	leal	(gdt - xen_relocate_kernel)(%ebx), %eax
> +	movl	%eax, (gdt_48 - xen_relocate_kernel + 2)(%ebx)
> +	lgdtl	(gdt_48 - xen_relocate_kernel)(%ebx)
> +
> +	/* Load data segment registers. */
> +	movl	$(gdt_ds - gdt), %eax
> +	movl	%eax, %ds
> +	movl	%eax, %es
> +	movl	%eax, %fs
> +	movl	%eax, %gs
> +	movl	%eax, %ss
> +
> +	/* Setup a new stack at the end of machine address of control page. */
> +	leal	PAGE_SIZE(%ebx), %esp
> +
> +	/* Store start_address on the stack. */
> +	pushl   %edx
> +
> +	/* Jump to identity mapped page. */
> +	pushl	$0
> +	pushl	$(gdt_cs - gdt)
> +	addl	$(identity_mapped - xen_relocate_kernel), %ebx
> +	pushl	%ebx
> +	iretl
> +
> +identity_mapped:
> +	/*
> +	 * Set %cr0 to a known state:
> +	 *   - disable alignment check,
> +	 *   - disable floating point emulation,
> +	 *   - disable paging,
> +	 *   - no task switch,
> +	 *   - disable write protect,
> +	 *   - enable protected mode.
> +	 */
> +	movl	%cr0, %eax
> +	andl	$~(X86_CR0_AM | X86_CR0_EM | X86_CR0_PG | X86_CR0_TS | X86_CR0_WP), %eax
> +	orl	$(X86_CR0_PE), %eax
> +	movl	%eax, %cr0
> +
> +	/* Set %cr4 to a known state. */
> +	xorl	%eax, %eax
> +	movl	%eax, %cr4
> +
> +	jmp	1f
> +
> +1:
> +	/* Flush the TLB (needed?). */
> +	movl	%eax, %cr3
> +
> +	/* Do the copies. */
> +	movl	%edi, %ecx	/* Put the indirection_page in %ecx. */
> +	xorl	%edi, %edi
> +	xorl	%esi, %esi
> +	jmp	1f
> +
> +0:
> +	/*
> +	 * Top, read another doubleword from the indirection page.
> +	 * Indirection page is an array which contains source
> +	 * and destination address pairs. If all pairs could
> +	 * not fit in one page then at the end of given
> +	 * indirection page is pointer to next one.
> +	 * Copy is stopped when done indicator
> +	 * is found in indirection page.
> +	 */
> +	movl	(%ebx), %ecx
> +	addl	$4, %ebx
> +
> +1:
> +	testl	$0x1, %ecx	/* Is it a destination page? */
> +	jz	2f
> +
> +	movl	%ecx, %edi
> +	andl	$PAGE_MASK, %edi
> +	jmp	0b
> +
> +2:
> +	testl	$0x2, %ecx	/* Is it an indirection page? */
> +	jz	2f
> +
> +	movl	%ecx, %ebx
> +	andl	$PAGE_MASK, %ebx
> +	jmp	0b
> +
> +2:
> +	testl	$0x4, %ecx	/* Is it the done indicator? */
> +	jz	2f
> +	jmp	3f
> +
> +2:
> +	testl	$0x8, %ecx	/* Is it the source indicator? */
> +	jz	0b		/* Ignore it otherwise. */
> +
> +	movl	%ecx, %esi
> +	andl	$PAGE_MASK, %esi
> +	movl	$1024, %ecx
> +
> +	/* Copy page. */
> +	rep	movsl
> +	jmp	0b
> +
> +3:
> +	/*
> +	 * To be certain of avoiding problems with self-modifying code
> +	 * I need to execute a serializing instruction here.
> +	 * So I flush the TLB by reloading %cr3 here, it's handy,
> +	 * and not processor dependent.
> +	 */
> +	xorl	%eax, %eax
> +	movl	%eax, %cr3
> +
> +	/*
> +	 * Set all of the registers to known values.
> +	 * Leave %esp alone.
> +	 */
> +	xorl	%ebx, %ebx
> +	xorl    %ecx, %ecx
> +	xorl    %edx, %edx
> +	xorl    %esi, %esi
> +	xorl    %edi, %edi
> +	xorl    %ebp, %ebp
> +
> +	/* Jump to start_address. */
> +	retl
> +
> +	.align	L1_CACHE_BYTES
> +
> +gdt:
> +	.quad	0x0000000000000000	/* NULL descriptor. */
> +
> +gdt_cs:
> +	.quad	0x00cf9a000000ffff	/* 4 GiB code segment at 0x00000000. */
> +
> +gdt_ds:
> +	.quad	0x00cf92000000ffff	/* 4 GiB data segment at 0x00000000. */
> +gdt_end:
> +
> +gdt_48:
> +	.word	gdt_end - gdt - 1	/* GDT limit. */
> +	.long	0			/* GDT base - filled in by code above. */
> +
> +idt_48:
> +	.word	0			/* IDT limit. */
> +	.long	0			/* IDT base. */
> +
> +xen_kexec_control_code_size:
> +	.long	. - xen_relocate_kernel
> -- 
> 1.5.6.5

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 28 16:29:34 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Sep 2012 16: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 1THdRG-0000tq-DP; Fri, 28 Sep 2012 16:29:18 +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 1THdRE-0000tl-DD
	for xen-devel@lists.xensource.com; Fri, 28 Sep 2012 16:29:16 +0000
Received: from [85.158.139.211:51101] by server-8.bemta-5.messagelabs.com id
	1B/D0-18073-B50D5605; Fri, 28 Sep 2012 16:29:15 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-10.tower-206.messagelabs.com!1348849753!20333988!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDc4MTcyOA==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13602 invoked from network); 28 Sep 2012 16:29:14 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-10.tower-206.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 28 Sep 2012 16:29:14 -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 q8SGTBfj017576
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 28 Sep 2012 16:29:11 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q8SGTAmq022534
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 28 Sep 2012 16:29:10 GMT
Received: from abhmt110.oracle.com (abhmt110.oracle.com [141.146.116.62])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q8SGTAlk004588; Fri, 28 Sep 2012 11:29:10 -0500
Received: from localhost.localdomain (/10.154.179.198)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 28 Sep 2012 09:29:05 -0700
Date: Fri, 28 Sep 2012 12:39:44 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Daniel Kiper <daniel.kiper@oracle.com>
Message-ID: <20120928163941.GD16262@localhost.localdomain>
References: <1348769198-29580-1-git-send-email-daniel.kiper@oracle.com>
	<1348769198-29580-2-git-send-email-daniel.kiper@oracle.com>
	<1348769198-29580-3-git-send-email-daniel.kiper@oracle.com>
	<1348769198-29580-4-git-send-email-daniel.kiper@oracle.com>
	<1348769198-29580-5-git-send-email-daniel.kiper@oracle.com>
	<1348769198-29580-6-git-send-email-daniel.kiper@oracle.com>
	<1348769198-29580-7-git-send-email-daniel.kiper@oracle.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1348769198-29580-7-git-send-email-daniel.kiper@oracle.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: andrew.cooper3@citrix.com, xen-devel@lists.xensource.com,
	linux-kernel@vger.kernel.org, jbeulich@suse.com
Subject: Re: [Xen-devel] [PATCH 06/11] x86/xen: Add i386 kexec/kdump
	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 Thu, Sep 27, 2012 at 08:06:33PM +0200, Daniel Kiper wrote:
> Add i386 kexec/kdump implementation.
> 
> Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
> ---
>  arch/x86/xen/machine_kexec_32.c   |  245 ++++++++++++++++++++++++++++
>  arch/x86/xen/relocate_kernel_32.S |  323 +++++++++++++++++++++++++++++++++++++
>  2 files changed, 568 insertions(+), 0 deletions(-)
>  create mode 100644 arch/x86/xen/machine_kexec_32.c
>  create mode 100644 arch/x86/xen/relocate_kernel_32.S
> 
> diff --git a/arch/x86/xen/machine_kexec_32.c b/arch/x86/xen/machine_kexec_32.c
> new file mode 100644
> index 0000000..6b5141e
> --- /dev/null
> +++ b/arch/x86/xen/machine_kexec_32.c
> @@ -0,0 +1,245 @@
> +/*
> + * Copyright (c) 2011 Daniel Kiper
> + * Copyright (c) 2012 Daniel Kiper, Oracle Corporation
> + *
> + * kexec/kdump implementation for Xen was written by Daniel Kiper.
> + * Initial work on it was sponsored by Google under Google Summer
> + * of Code 2011 program and Citrix. Konrad Rzeszutek Wilk from Oracle
> + * was the mentor for this project.
> + *
> + * Some ideas are taken from:
> + *   - native kexec/kdump implementation,
> + *   - kexec/kdump implementation for Xen Linux Kernel Ver. 2.6.18,
> + *   - PV-GRUB.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License along
> + * with this program.  If not, see <http://www.gnu.org/licenses/>.
> + */
> +
> +#include <linux/errno.h>
> +#include <linux/init.h>
> +#include <linux/kernel.h>
> +#include <linux/kexec.h>
> +#include <linux/mm.h>
> +#include <linux/string.h>
> +
> +#include <xen/xen.h>
> +#include <xen/xen-ops.h>
> +
> +#include <asm/xen/hypercall.h>
> +#include <asm/xen/kexec.h>
> +#include <asm/xen/page.h>
> +
> +#define __ma(vaddr)	(virt_to_machine(vaddr).maddr)
> +
> +static struct page *kimage_alloc_pages(gfp_t gfp_mask,
> +					unsigned int order,
> +					unsigned long limit)
> +{
> +	struct page *pages;
> +	unsigned int address_bits, i;
> +
> +	pages = alloc_pages(gfp_mask, order);
> +
> +	if (!pages)
> +		return NULL;
> +
> +	address_bits = (limit == ULONG_MAX) ? BITS_PER_LONG : ilog2(limit);
> +
> +	/* Relocate set of pages below given limit. */
> +	if (xen_create_contiguous_region((unsigned long)page_address(pages),
> +							order, address_bits)) {
> +		__free_pages(pages, order);
> +		return NULL;
> +	}
> +
> +	pages->mapping = NULL;

It shouldn't matter (as you did the alloc_page) but could you
add:
	BUG_ON(PagePrivate(pages))
in case somebody did do something weird beforehand.

> +	set_page_private(pages, order);
> +
> +	for (i = 0; i < (1 << order); ++i)
> +		SetPageReserved(pages + i);
> +
> +	return pages;
> +}
> +
> +static void kimage_free_pages(struct page *page)
> +{
> +	unsigned int i, order;
> +
> +	order = page_private(page);
> +
> +	for (i = 0; i < (1 << order); ++i)
> +		ClearPageReserved(page + i);
> +
> +	xen_destroy_contiguous_region((unsigned long)page_address(page), order);
> +	__free_pages(page, order);
> +}
> +
> +static unsigned long xen_page_to_mfn(struct page *page)
> +{
> +	return pfn_to_mfn(page_to_pfn(page));
> +}
> +
> +static struct page *xen_mfn_to_page(unsigned long mfn)
> +{
> +	return pfn_to_page(mfn_to_pfn(mfn));
> +}
> +
> +static unsigned long xen_virt_to_machine(volatile void *address)
> +{
> +	return virt_to_machine(address).maddr;
> +}
> +
> +static void *xen_machine_to_virt(unsigned long address)
> +{
> +	return phys_to_virt(machine_to_phys(XMADDR(address)).paddr);
> +}
> +
> +static void free_transition_pgtable(struct kimage *image)
> +{
> +	free_page((unsigned long)image->arch.pgd);
> +	free_page((unsigned long)image->arch.pmd0);
> +	free_page((unsigned long)image->arch.pmd1);
> +	free_page((unsigned long)image->arch.pte0);
> +	free_page((unsigned long)image->arch.pte1);
> +}
> +
> +static int alloc_transition_pgtable(struct kimage *image)
> +{
> +	image->arch.pgd = (pgd_t *)get_zeroed_page(GFP_KERNEL);
> +
> +	if (!image->arch.pgd)
> +		goto err;
> +
> +	image->arch.pmd0 = (pmd_t *)get_zeroed_page(GFP_KERNEL);
> +
> +	if (!image->arch.pmd0)
> +		goto err;
> +
> +	image->arch.pmd1 = (pmd_t *)get_zeroed_page(GFP_KERNEL);
> +
> +	if (!image->arch.pmd1)
> +		goto err;
> +
> +	image->arch.pte0 = (pte_t *)get_zeroed_page(GFP_KERNEL);
> +
> +	if (!image->arch.pte0)
> +		goto err;
> +
> +	image->arch.pte1 = (pte_t *)get_zeroed_page(GFP_KERNEL);
> +
> +	if (!image->arch.pte1)
> +		goto err;
> +
> +	return 0;
> +
> +err:
> +	free_transition_pgtable(image);
> +
> +	return -ENOMEM;
> +}
> +
> +static int machine_xen_kexec_prepare(struct kimage *image)
> +{
> +#ifdef CONFIG_KEXEC_JUMP
> +	if (image->preserve_context) {
> +		pr_info_once("kexec: Context preservation is not "
> +				"supported in Xen domains.\n");
> +		return -ENOSYS;
> +	}
> +#endif
> +
> +	return alloc_transition_pgtable(image);
> +}
> +
> +static int machine_xen_kexec_load(struct kimage *image)
> +{
> +	void *control_page;
> +	struct xen_kexec_load xkl = {};
> +
> +	if (!image)
> +		return 0;

Not -EINVAL?

> +
> +	control_page = page_address(image->control_code_page);
> +	memcpy(control_page, xen_relocate_kernel, xen_kexec_control_code_size);
> +
> +	xkl.type = image->type;
> +	xkl.image.page_list[XK_MA_CONTROL_PAGE] = __ma(control_page);
> +	xkl.image.page_list[XK_MA_TABLE_PAGE] = 0; /* Unused. */
> +	xkl.image.page_list[XK_MA_PGD_PAGE] = __ma(image->arch.pgd);
> +	xkl.image.page_list[XK_MA_PUD0_PAGE] = 0; /* Unused. */
> +	xkl.image.page_list[XK_MA_PUD1_PAGE] = 0; /* Unused. */
> +	xkl.image.page_list[XK_MA_PMD0_PAGE] = __ma(image->arch.pmd0);
> +	xkl.image.page_list[XK_MA_PMD1_PAGE] = __ma(image->arch.pmd1);
> +	xkl.image.page_list[XK_MA_PTE0_PAGE] = __ma(image->arch.pte0);
> +	xkl.image.page_list[XK_MA_PTE1_PAGE] = __ma(image->arch.pte1);
> +	xkl.image.indirection_page = image->head;
> +	xkl.image.start_address = image->start;
> +
> +	return HYPERVISOR_kexec_op(KEXEC_CMD_kexec_load, &xkl);
> +}
> +
> +static void machine_xen_kexec_cleanup(struct kimage *image)
> +{
> +	free_transition_pgtable(image);
> +}
> +
> +static void machine_xen_kexec_unload(struct kimage *image)
> +{
> +	int rc;
> +	struct xen_kexec_load xkl = {};
> +
> +	if (!image)
> +		return;
> +
> +	xkl.type = image->type;
> +	rc = HYPERVISOR_kexec_op(KEXEC_CMD_kexec_unload, &xkl);
> +
> +	WARN(rc, "kexec: %s: HYPERVISOR_kexec_op(): %i\n", __func__, rc);
> +}
> +
> +static void machine_xen_kexec_shutdown(void)
> +{
> +}
> +
> +static void machine_xen_kexec(struct kimage *image)
> +{
> +	int rc;
> +	struct xen_kexec_exec xke = {};
> +
> +	xke.type = image->type;
> +	rc = HYPERVISOR_kexec_op(KEXEC_CMD_kexec, &xke);
> +
> +	pr_emerg("kexec: %s: HYPERVISOR_kexec_op(): %i\n", __func__, rc);
> +	BUG();
> +}
> +
> +void __init xen_init_kexec_ops(void)
> +{
> +	if (!xen_initial_domain())
> +		return;
> +
> +	kexec_ops.always_use_normal_alloc = true;
> +	kexec_ops.kimage_alloc_pages = kimage_alloc_pages;
> +	kexec_ops.kimage_free_pages = kimage_free_pages;
> +	kexec_ops.page_to_pfn = xen_page_to_mfn;
> +	kexec_ops.pfn_to_page = xen_mfn_to_page;
> +	kexec_ops.virt_to_phys = xen_virt_to_machine;
> +	kexec_ops.phys_to_virt = xen_machine_to_virt;
> +	kexec_ops.machine_kexec_prepare = machine_xen_kexec_prepare;
> +	kexec_ops.machine_kexec_load = machine_xen_kexec_load;
> +	kexec_ops.machine_kexec_cleanup = machine_xen_kexec_cleanup;
> +	kexec_ops.machine_kexec_unload = machine_xen_kexec_unload;
> +	kexec_ops.machine_kexec_shutdown = machine_xen_kexec_shutdown;
> +	kexec_ops.machine_kexec = machine_xen_kexec;
> +}
> diff --git a/arch/x86/xen/relocate_kernel_32.S b/arch/x86/xen/relocate_kernel_32.S
> new file mode 100644
> index 0000000..0e81830
> --- /dev/null
> +++ b/arch/x86/xen/relocate_kernel_32.S
> @@ -0,0 +1,323 @@
> +/*
> + * Copyright (c) 2002-2005 Eric Biederman <ebiederm@xmission.com>
> + * Copyright (c) 2011 Daniel Kiper
> + * Copyright (c) 2012 Daniel Kiper, Oracle Corporation
> + *
> + * kexec/kdump implementation for Xen was written by Daniel Kiper.
> + * Initial work on it was sponsored by Google under Google Summer
> + * of Code 2011 program and Citrix. Konrad Rzeszutek Wilk from Oracle
> + * was the mentor for this project.
> + *
> + * Some ideas are taken from:
> + *   - native kexec/kdump implementation,
> + *   - kexec/kdump implementation for Xen Linux Kernel Ver. 2.6.18,
> + *   - PV-GRUB.
> + *
> + * 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 veesion 2 of the License, or
> + * (at your option) any later veesion.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License along
> + * with this program.  If not, see <http://www.gnu.org/licenses/>.
> + */
> +
> +#include <asm/cache.h>
> +#include <asm/page_types.h>
> +#include <asm/pgtable_types.h>
> +#include <asm/processor-flags.h>
> +
> +#include <asm/xen/kexec.h>
> +
> +#define ARG_INDIRECTION_PAGE	0x4
> +#define ARG_PAGE_LIST		0x8
> +#define ARG_START_ADDRESS	0xc
> +
> +#define PTR(x)	(x << 2)
> +
> +	.text
> +	.align	PAGE_SIZE
> +	.globl	xen_kexec_control_code_size, xen_relocate_kernel
> +
> +xen_relocate_kernel:
> +	/*
> +	 * Must be relocatable PIC code callable as a C function.
> +	 *
> +	 * This function is called by Xen but here hypervisor is dead.
> +	 * We are playing on bare metal.
> +	 *
> +	 * Every machine address passed to this function through
> +	 * page_list (e.g. XK_MA_CONTROL_PAGE) is established
> +	 * by dom0 during kexec load phase.
> +	 *
> +	 * Every virtual address passed to this function through page_list
> +	 * (e.g. XK_VA_CONTROL_PAGE) is established by hypervisor during
> +	 * HYPERVISOR_kexec_op(KEXEC_CMD_kexec_load) hypercall.
> +	 *
> +	 * 0x4(%esp) - indirection_page,
> +	 * 0x8(%esp) - page_list,
> +	 * 0xc(%esp) - start_address,
> +	 * 0x10(%esp) - cpu_has_pae (ignored),
> +	 * 0x14(%esp) - preserve_context (ignored).
> +	 */
> +
> +	/* Zero out flags, and disable interrupts. */
> +	pushl	$0
> +	popfl
> +
> +	/* Get page_list address. */
> +	movl	ARG_PAGE_LIST(%esp), %esi
> +
> +	/*
> +	 * Map the control page at its virtual address
> +	 * in transition page table.
> +	 */
> +	movl	PTR(XK_VA_CONTROL_PAGE)(%esi), %eax
> +
> +	/* Get PGD address and PGD entry index. */
> +	movl	PTR(XK_VA_PGD_PAGE)(%esi), %ebx
> +	movl	%eax, %ecx
> +	shrl	$PGDIR_SHIFT, %ecx
> +	andl	$(PTRS_PER_PGD - 1), %ecx
> +
> +	/* Fill PGD entry with PMD0 reference. */
> +	movl	PTR(XK_MA_PMD0_PAGE)(%esi), %edx
> +	orl	$_PAGE_PRESENT, %edx
> +	movl	%edx, (%ebx, %ecx, 8)
> +
> +	/* Get PMD0 address and PMD0 entry index. */
> +	movl	PTR(XK_VA_PMD0_PAGE)(%esi), %ebx
> +	movl	%eax, %ecx
> +	shrl	$PMD_SHIFT, %ecx
> +	andl	$(PTRS_PER_PMD - 1), %ecx
> +
> +	/* Fill PMD0 entry with PTE0 reference. */
> +	movl	PTR(XK_MA_PTE0_PAGE)(%esi), %edx
> +	orl	$_KERNPG_TABLE, %edx
> +	movl	%edx, (%ebx, %ecx, 8)
> +
> +	/* Get PTE0 address and PTE0 entry index. */
> +	movl	PTR(XK_VA_PTE0_PAGE)(%esi), %ebx
> +	movl	%eax, %ecx
> +	shrl	$PAGE_SHIFT, %ecx
> +	andl	$(PTRS_PER_PTE - 1), %ecx
> +
> +	/* Fill PTE0 entry with control page reference. */
> +	movl	PTR(XK_MA_CONTROL_PAGE)(%esi), %edx
> +	orl	$__PAGE_KERNEL_EXEC, %edx
> +	movl	%edx, (%ebx, %ecx, 8)
> +
> +	/*
> +	 * Identity map the control page at its machine address
> +	 * in transition page table.
> +	 */
> +	movl	PTR(XK_MA_CONTROL_PAGE)(%esi), %eax
> +
> +	/* Get PGD address and PGD entry index. */
> +	movl	PTR(XK_VA_PGD_PAGE)(%esi), %ebx
> +	movl	%eax, %ecx
> +	shrl	$PGDIR_SHIFT, %ecx
> +	andl	$(PTRS_PER_PGD - 1), %ecx
> +
> +	/* Fill PGD entry with PMD1 reference. */
> +	movl	PTR(XK_MA_PMD1_PAGE)(%esi), %edx
> +	orl	$_PAGE_PRESENT, %edx
> +	movl	%edx, (%ebx, %ecx, 8)
> +
> +	/* Get PMD1 address and PMD1 entry index. */
> +	movl	PTR(XK_VA_PMD1_PAGE)(%esi), %ebx
> +	movl	%eax, %ecx
> +	shrl	$PMD_SHIFT, %ecx
> +	andl	$(PTRS_PER_PMD - 1), %ecx
> +
> +	/* Fill PMD1 entry with PTE1 reference. */
> +	movl	PTR(XK_MA_PTE1_PAGE)(%esi), %edx
> +	orl	$_KERNPG_TABLE, %edx
> +	movl	%edx, (%ebx, %ecx, 8)
> +
> +	/* Get PTE1 address and PTE1 entry index. */
> +	movl	PTR(XK_VA_PTE1_PAGE)(%esi), %ebx
> +	movl	%eax, %ecx
> +	shrl	$PAGE_SHIFT, %ecx
> +	andl	$(PTRS_PER_PTE - 1), %ecx
> +
> +	/* Fill PTE1 entry with control page reference. */
> +	movl	PTR(XK_MA_CONTROL_PAGE)(%esi), %edx
> +	orl	$__PAGE_KERNEL_EXEC, %edx
> +	movl	%edx, (%ebx, %ecx, 8)
> +
> +	/*
> +	 * Get machine address of control page now.
> +	 * This is impossible after page table switch.
> +	 */
> +	movl	PTR(XK_MA_CONTROL_PAGE)(%esi), %ebx
> +
> +	/* Get machine address of transition page table now too. */
> +	movl	PTR(XK_MA_PGD_PAGE)(%esi), %ecx
> +
> +	/* Get start_address too. */
> +	movl	ARG_START_ADDRESS(%esp), %edx
> +
> +	/* Get indirection_page address too. */
> +	movl	ARG_INDIRECTION_PAGE(%esp), %edi
> +
> +	/* Switch to transition page table. */
> +	movl	%ecx, %cr3
> +
> +	/* Load IDT. */
> +	lidtl	(idt_48 - xen_relocate_kernel)(%ebx)
> +
> +	/* Load GDT. */
> +	leal	(gdt - xen_relocate_kernel)(%ebx), %eax
> +	movl	%eax, (gdt_48 - xen_relocate_kernel + 2)(%ebx)
> +	lgdtl	(gdt_48 - xen_relocate_kernel)(%ebx)
> +
> +	/* Load data segment registers. */
> +	movl	$(gdt_ds - gdt), %eax
> +	movl	%eax, %ds
> +	movl	%eax, %es
> +	movl	%eax, %fs
> +	movl	%eax, %gs
> +	movl	%eax, %ss
> +
> +	/* Setup a new stack at the end of machine address of control page. */
> +	leal	PAGE_SIZE(%ebx), %esp
> +
> +	/* Store start_address on the stack. */
> +	pushl   %edx
> +
> +	/* Jump to identity mapped page. */
> +	pushl	$0
> +	pushl	$(gdt_cs - gdt)
> +	addl	$(identity_mapped - xen_relocate_kernel), %ebx
> +	pushl	%ebx
> +	iretl
> +
> +identity_mapped:
> +	/*
> +	 * Set %cr0 to a known state:
> +	 *   - disable alignment check,
> +	 *   - disable floating point emulation,
> +	 *   - disable paging,
> +	 *   - no task switch,
> +	 *   - disable write protect,
> +	 *   - enable protected mode.
> +	 */
> +	movl	%cr0, %eax
> +	andl	$~(X86_CR0_AM | X86_CR0_EM | X86_CR0_PG | X86_CR0_TS | X86_CR0_WP), %eax
> +	orl	$(X86_CR0_PE), %eax
> +	movl	%eax, %cr0
> +
> +	/* Set %cr4 to a known state. */
> +	xorl	%eax, %eax
> +	movl	%eax, %cr4
> +
> +	jmp	1f
> +
> +1:
> +	/* Flush the TLB (needed?). */
> +	movl	%eax, %cr3
> +
> +	/* Do the copies. */
> +	movl	%edi, %ecx	/* Put the indirection_page in %ecx. */
> +	xorl	%edi, %edi
> +	xorl	%esi, %esi
> +	jmp	1f
> +
> +0:
> +	/*
> +	 * Top, read another doubleword from the indirection page.
> +	 * Indirection page is an array which contains source
> +	 * and destination address pairs. If all pairs could
> +	 * not fit in one page then at the end of given
> +	 * indirection page is pointer to next one.
> +	 * Copy is stopped when done indicator
> +	 * is found in indirection page.
> +	 */
> +	movl	(%ebx), %ecx
> +	addl	$4, %ebx
> +
> +1:
> +	testl	$0x1, %ecx	/* Is it a destination page? */
> +	jz	2f
> +
> +	movl	%ecx, %edi
> +	andl	$PAGE_MASK, %edi
> +	jmp	0b
> +
> +2:
> +	testl	$0x2, %ecx	/* Is it an indirection page? */
> +	jz	2f
> +
> +	movl	%ecx, %ebx
> +	andl	$PAGE_MASK, %ebx
> +	jmp	0b
> +
> +2:
> +	testl	$0x4, %ecx	/* Is it the done indicator? */
> +	jz	2f
> +	jmp	3f
> +
> +2:
> +	testl	$0x8, %ecx	/* Is it the source indicator? */
> +	jz	0b		/* Ignore it otherwise. */
> +
> +	movl	%ecx, %esi
> +	andl	$PAGE_MASK, %esi
> +	movl	$1024, %ecx
> +
> +	/* Copy page. */
> +	rep	movsl
> +	jmp	0b
> +
> +3:
> +	/*
> +	 * To be certain of avoiding problems with self-modifying code
> +	 * I need to execute a serializing instruction here.
> +	 * So I flush the TLB by reloading %cr3 here, it's handy,
> +	 * and not processor dependent.
> +	 */
> +	xorl	%eax, %eax
> +	movl	%eax, %cr3
> +
> +	/*
> +	 * Set all of the registers to known values.
> +	 * Leave %esp alone.
> +	 */
> +	xorl	%ebx, %ebx
> +	xorl    %ecx, %ecx
> +	xorl    %edx, %edx
> +	xorl    %esi, %esi
> +	xorl    %edi, %edi
> +	xorl    %ebp, %ebp
> +
> +	/* Jump to start_address. */
> +	retl
> +
> +	.align	L1_CACHE_BYTES
> +
> +gdt:
> +	.quad	0x0000000000000000	/* NULL descriptor. */
> +
> +gdt_cs:
> +	.quad	0x00cf9a000000ffff	/* 4 GiB code segment at 0x00000000. */
> +
> +gdt_ds:
> +	.quad	0x00cf92000000ffff	/* 4 GiB data segment at 0x00000000. */
> +gdt_end:
> +
> +gdt_48:
> +	.word	gdt_end - gdt - 1	/* GDT limit. */
> +	.long	0			/* GDT base - filled in by code above. */
> +
> +idt_48:
> +	.word	0			/* IDT limit. */
> +	.long	0			/* IDT base. */
> +
> +xen_kexec_control_code_size:
> +	.long	. - xen_relocate_kernel
> -- 
> 1.5.6.5

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 28 16:39:18 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Sep 2012 16:39:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1THdah-00015n-Lg; Fri, 28 Sep 2012 16:39:03 +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 1THdag-00015i-Dt
	for xen-devel@lists.xen.org; Fri, 28 Sep 2012 16:39:02 +0000
Received: from [85.158.139.83:20848] by server-9.bemta-5.messagelabs.com id
	D5/0C-14846-5A2D5605; Fri, 28 Sep 2012 16:39:01 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1348850340!29750717!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-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19687 invoked from network); 28 Sep 2012 16:39:00 -0000
Received: from mail-ey0-f173.google.com (HELO mail-ey0-f173.google.com)
	(209.85.215.173)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Sep 2012 16:39:00 -0000
Received: by eaaa1 with SMTP id a1so1190475eaa.32
	for <xen-devel@lists.xen.org>; Fri, 28 Sep 2012 09:39: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=UzCRvs0t4JRnyxrSLlALaJXz8XfV6/zeJVT+LrVPh84=;
	b=enWOc+LPsKS3BlDLlK+Vff3AEiUivL0qutBcR1PcETryYVog8VAv0rQsejmVy/HJS5
	S5WpamWDqvZ/Kdh2knDPwlCsTSrybxeAqBIf/1e+JO+xuN6pZYH2qzNU3tfycmdJK2Dd
	g303sjiis743peDGyUgPwnQ91VVFPOEgHftgVDepE0AiGBM4SneDBEv3/6SjTW0eCHBY
	spoiZsaQvn7VkNBQaedND0mfx4J7zAjj7SGV2UYKEDL1Vtl3udXiGTgblUVNzohwTu9r
	2UAM7TI923HjIX1HGvcAQ/ZZ1BP+5js3AkzB2FtyzabZRoa2QztGja820Mbp3EvIFzkX
	BkFg==
MIME-Version: 1.0
Received: by 10.14.212.72 with SMTP id x48mr10574434eeo.40.1348850340634; Fri,
	28 Sep 2012 09:39:00 -0700 (PDT)
Received: by 10.14.215.195 with HTTP; Fri, 28 Sep 2012 09:39:00 -0700 (PDT)
In-Reply-To: <5065CAE9.30602@jhuapl.edu>
References: <1348765860-11359-1-git-send-email-matthew.fioravante@jhuapl.edu>
	<1348765860-11359-3-git-send-email-matthew.fioravante@jhuapl.edu>
	<CAFLBxZbvK0WxHhQgY79vCG21fd8b4i=vuVhtFjrpN-saXM61bA@mail.gmail.com>
	<5065CAE9.30602@jhuapl.edu>
Date: Fri, 28 Sep 2012 17:39:00 +0100
X-Google-Sender-Auth: zmOM8XOTmhW2BJRl3MNDi7BDd1k
Message-ID: <CAFLBxZYzn0zru_JW0372yzi2f5N0-nfPfd3HDrBKV1G41aoVZQ@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
Cc: "Ian.Campbell@citrix.com" <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 11/11] add vtpm support to 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

On Fri, Sep 28, 2012 at 5:06 PM, Matthew Fioravante
<matthew.fioravante@jhuapl.edu> wrote:
> On 09/28/2012 11:03 AM, George Dunlap wrote:
>> On Thu, Sep 27, 2012 at 6:11 PM, Matthew Fioravante
>> <matthew.fioravante@jhuapl.edu> wrote:
>>> This patch adds vtpm support to libxl. It adds vtpm parsing to config
>>> files and 3 new xl commands:
>>> vtpm-attach
>>> vtpm-detach
>>> vtpm-list
>>>
>>> Signed-off-by: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
>> Overall looks good to me -- just a few comments below about the config
>> file handling (see below).
>>
>> Thanks for all your work on this.
>>
>>> @@ -601,6 +605,8 @@ static void domcreate_bootloader_done(libxl__egc *egc,
>>>  static void domcreate_launch_dm(libxl__egc *egc, libxl__multidev *aodevs,
>>>                                  int ret);
>>>
>>> +static void domcreate_attach_vtpms(libxl__egc *egc, libxl__multidev *multidev,
>>> +                                   int ret);
>>>  static void domcreate_attach_pci(libxl__egc *egc, libxl__multidev *aodevs,
>>>                                   int ret);
>>>
>>> @@ -1084,13 +1090,13 @@ static void domcreate_devmodel_started(libxl__egc *egc,
>>>      if (d_config->num_nics > 0) {
>>>          /* Attach nics */
>>>          libxl__multidev_begin(ao, &dcs->multidev);
>>> -        dcs->multidev.callback = domcreate_attach_pci;
>>> +        dcs->multidev.callback = domcreate_attach_vtpms;
>> Wow -- what a weird convention you've had to try to figure out and
>> modify here.  Well done. :-)
> It was really tricky. Is there no better way to handle asynchronous
> code? This method seems really error prone and almost impossible to follow.

Well I didn't write it. :-)  I haven't taken the time to figure out
why it might have been written that way; but at first glance, I tend
to agree with you.  For about 10 minutes I was convinced you had made
some kind of weird error, by sprinkling "vtpm" around things that
obviously were supposed to be about nics and pci devices, until I
realized you were just following the existing "call chain" convention.

>>> +            p = strtok(buf2, ",");
>>> +            if (!p)
>>> +                goto skip_vtpm;
>> Is the purpose of this so that you can have "empty" vtpm slots?
>> (Since even when skipping, you still increment the num_vtpms counter?)
> That would make a default vtpm with a randomly generated uuid and
> backend=dom0. Considering that were getting rid of the process model, it
> probably makes sense to force the user to specify a backend domain id
> because no vtpm device will ever connect to dom0 anymore.

Ah, right.  Either way is OK with me, but a comment would be useful. :-)

>>
>>> +                    }
>>> +                } else if(!strcmp(p, "uuid")) {
>>> +                    if( libxl_uuid_from_string(&vtpm->uuid, p2 + 1) ) {
>>> +                        fprintf(stderr, "Failed to parse vtpm UUID: %s\n", p2 + 1);
>>> +                        exit(1);
>>> +                    }
>>> +                }
>> If I'm parsing this right, it looks like you will just silently ignore
>> other arguments -- it seems like throwing an error would be better;
>> especially to catch things like typos.  Otherwise, if someone does
>> something like "uid=[whatever]", it will act like uuid isn't there and
>> create a new one, instead of alerting the user to the fact that he'd
>> made a typo in the config file.
> The behavior here is there if the user passes an invalid uuid string it
> will fail with a parse error, but if the user does not specify a uuid at
> all, one will be randomly generated. Random generation happens in the
> vtpm types constructor in the xl type system.

I think you misunderstood my comment; I'm not actually talking about
the uuid clause that's there, but the "none of the above" clause
that's missing.  The code says (in pseudocode):

if("backend")
 parse backend;
else if("uuid")
 parse uuid;

But what if it's neither "backend" or "uuid", but something else --
say, "uid" or "backedn"?  Then instead of giving an error, it will
just skip that argument and go on to the next one; and if the user
*intended* to type "backend" instead of "backedn", it will silently
use the default, giving her no clue as to what the problem might be.
I'm proposing adding (again in pseudocode):

else
  error("Unrecognized argument: %s\n", p);

Does that make sense?

> This brings up a bigger wart in the vtpm implementation.

It's 5:30pm on a Friday, so I'm going to put off grokking the rest of
this until Monday morning. :-)

Have a good weekend,
 -George

>
> Its kind of confusing now because the linux guest uses a tpmfront/back
> pair to talk to the vtpm, and then vtpm uses another tpmfront/back pair
> to talk to the manager. You have to specify the uuid on the vtpm's
> tpmfront device because that is the device the manager sees. You do not
> have to specify one on the linux domains device.
>
> I'd argue that now, especially with the process model gone, the uuid
> should be a parameter of the vtpm itself and not the tpmfront/back
> communication channels.
>
> The problem is that this uuid needs to specified by the "control domain"
> or dom0. By attaching the uuid to the device, the manager can trust the
> uuid attached to whoever is trying to connect to him.
>
> One idea is to make the uuid a commandline parameter for the mini-os
> domain and have the vtpm pass the id down to the manager. That means
> however that any rogue domain could potentially connect to the manager
> and send him someone elses uuid, and thus being able to access the vtpms
> stored secrets.
>
> However one could argue that no domain would be able to connect to the
> manager to do this anyway because they would have to create a
> tpmfront/back device pair and the only way to do that is to break into
> the "control domain." If one can do this, then one could just as easily
> set their device uuid to whatever they want.
>
> I hope all that made sense. Do you see any flaws in my reasoning? If so
> I should probably get uuids out of the vtpm devices and simplify this
> whole thing.
>
>
>>
>>  -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 Fri Sep 28 16:39:18 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Sep 2012 16:39:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1THdah-00015n-Lg; Fri, 28 Sep 2012 16:39:03 +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 1THdag-00015i-Dt
	for xen-devel@lists.xen.org; Fri, 28 Sep 2012 16:39:02 +0000
Received: from [85.158.139.83:20848] by server-9.bemta-5.messagelabs.com id
	D5/0C-14846-5A2D5605; Fri, 28 Sep 2012 16:39:01 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1348850340!29750717!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-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19687 invoked from network); 28 Sep 2012 16:39:00 -0000
Received: from mail-ey0-f173.google.com (HELO mail-ey0-f173.google.com)
	(209.85.215.173)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Sep 2012 16:39:00 -0000
Received: by eaaa1 with SMTP id a1so1190475eaa.32
	for <xen-devel@lists.xen.org>; Fri, 28 Sep 2012 09:39: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=UzCRvs0t4JRnyxrSLlALaJXz8XfV6/zeJVT+LrVPh84=;
	b=enWOc+LPsKS3BlDLlK+Vff3AEiUivL0qutBcR1PcETryYVog8VAv0rQsejmVy/HJS5
	S5WpamWDqvZ/Kdh2knDPwlCsTSrybxeAqBIf/1e+JO+xuN6pZYH2qzNU3tfycmdJK2Dd
	g303sjiis743peDGyUgPwnQ91VVFPOEgHftgVDepE0AiGBM4SneDBEv3/6SjTW0eCHBY
	spoiZsaQvn7VkNBQaedND0mfx4J7zAjj7SGV2UYKEDL1Vtl3udXiGTgblUVNzohwTu9r
	2UAM7TI923HjIX1HGvcAQ/ZZ1BP+5js3AkzB2FtyzabZRoa2QztGja820Mbp3EvIFzkX
	BkFg==
MIME-Version: 1.0
Received: by 10.14.212.72 with SMTP id x48mr10574434eeo.40.1348850340634; Fri,
	28 Sep 2012 09:39:00 -0700 (PDT)
Received: by 10.14.215.195 with HTTP; Fri, 28 Sep 2012 09:39:00 -0700 (PDT)
In-Reply-To: <5065CAE9.30602@jhuapl.edu>
References: <1348765860-11359-1-git-send-email-matthew.fioravante@jhuapl.edu>
	<1348765860-11359-3-git-send-email-matthew.fioravante@jhuapl.edu>
	<CAFLBxZbvK0WxHhQgY79vCG21fd8b4i=vuVhtFjrpN-saXM61bA@mail.gmail.com>
	<5065CAE9.30602@jhuapl.edu>
Date: Fri, 28 Sep 2012 17:39:00 +0100
X-Google-Sender-Auth: zmOM8XOTmhW2BJRl3MNDi7BDd1k
Message-ID: <CAFLBxZYzn0zru_JW0372yzi2f5N0-nfPfd3HDrBKV1G41aoVZQ@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
Cc: "Ian.Campbell@citrix.com" <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 11/11] add vtpm support to 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

On Fri, Sep 28, 2012 at 5:06 PM, Matthew Fioravante
<matthew.fioravante@jhuapl.edu> wrote:
> On 09/28/2012 11:03 AM, George Dunlap wrote:
>> On Thu, Sep 27, 2012 at 6:11 PM, Matthew Fioravante
>> <matthew.fioravante@jhuapl.edu> wrote:
>>> This patch adds vtpm support to libxl. It adds vtpm parsing to config
>>> files and 3 new xl commands:
>>> vtpm-attach
>>> vtpm-detach
>>> vtpm-list
>>>
>>> Signed-off-by: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
>> Overall looks good to me -- just a few comments below about the config
>> file handling (see below).
>>
>> Thanks for all your work on this.
>>
>>> @@ -601,6 +605,8 @@ static void domcreate_bootloader_done(libxl__egc *egc,
>>>  static void domcreate_launch_dm(libxl__egc *egc, libxl__multidev *aodevs,
>>>                                  int ret);
>>>
>>> +static void domcreate_attach_vtpms(libxl__egc *egc, libxl__multidev *multidev,
>>> +                                   int ret);
>>>  static void domcreate_attach_pci(libxl__egc *egc, libxl__multidev *aodevs,
>>>                                   int ret);
>>>
>>> @@ -1084,13 +1090,13 @@ static void domcreate_devmodel_started(libxl__egc *egc,
>>>      if (d_config->num_nics > 0) {
>>>          /* Attach nics */
>>>          libxl__multidev_begin(ao, &dcs->multidev);
>>> -        dcs->multidev.callback = domcreate_attach_pci;
>>> +        dcs->multidev.callback = domcreate_attach_vtpms;
>> Wow -- what a weird convention you've had to try to figure out and
>> modify here.  Well done. :-)
> It was really tricky. Is there no better way to handle asynchronous
> code? This method seems really error prone and almost impossible to follow.

Well I didn't write it. :-)  I haven't taken the time to figure out
why it might have been written that way; but at first glance, I tend
to agree with you.  For about 10 minutes I was convinced you had made
some kind of weird error, by sprinkling "vtpm" around things that
obviously were supposed to be about nics and pci devices, until I
realized you were just following the existing "call chain" convention.

>>> +            p = strtok(buf2, ",");
>>> +            if (!p)
>>> +                goto skip_vtpm;
>> Is the purpose of this so that you can have "empty" vtpm slots?
>> (Since even when skipping, you still increment the num_vtpms counter?)
> That would make a default vtpm with a randomly generated uuid and
> backend=dom0. Considering that were getting rid of the process model, it
> probably makes sense to force the user to specify a backend domain id
> because no vtpm device will ever connect to dom0 anymore.

Ah, right.  Either way is OK with me, but a comment would be useful. :-)

>>
>>> +                    }
>>> +                } else if(!strcmp(p, "uuid")) {
>>> +                    if( libxl_uuid_from_string(&vtpm->uuid, p2 + 1) ) {
>>> +                        fprintf(stderr, "Failed to parse vtpm UUID: %s\n", p2 + 1);
>>> +                        exit(1);
>>> +                    }
>>> +                }
>> If I'm parsing this right, it looks like you will just silently ignore
>> other arguments -- it seems like throwing an error would be better;
>> especially to catch things like typos.  Otherwise, if someone does
>> something like "uid=[whatever]", it will act like uuid isn't there and
>> create a new one, instead of alerting the user to the fact that he'd
>> made a typo in the config file.
> The behavior here is there if the user passes an invalid uuid string it
> will fail with a parse error, but if the user does not specify a uuid at
> all, one will be randomly generated. Random generation happens in the
> vtpm types constructor in the xl type system.

I think you misunderstood my comment; I'm not actually talking about
the uuid clause that's there, but the "none of the above" clause
that's missing.  The code says (in pseudocode):

if("backend")
 parse backend;
else if("uuid")
 parse uuid;

But what if it's neither "backend" or "uuid", but something else --
say, "uid" or "backedn"?  Then instead of giving an error, it will
just skip that argument and go on to the next one; and if the user
*intended* to type "backend" instead of "backedn", it will silently
use the default, giving her no clue as to what the problem might be.
I'm proposing adding (again in pseudocode):

else
  error("Unrecognized argument: %s\n", p);

Does that make sense?

> This brings up a bigger wart in the vtpm implementation.

It's 5:30pm on a Friday, so I'm going to put off grokking the rest of
this until Monday morning. :-)

Have a good weekend,
 -George

>
> Its kind of confusing now because the linux guest uses a tpmfront/back
> pair to talk to the vtpm, and then vtpm uses another tpmfront/back pair
> to talk to the manager. You have to specify the uuid on the vtpm's
> tpmfront device because that is the device the manager sees. You do not
> have to specify one on the linux domains device.
>
> I'd argue that now, especially with the process model gone, the uuid
> should be a parameter of the vtpm itself and not the tpmfront/back
> communication channels.
>
> The problem is that this uuid needs to specified by the "control domain"
> or dom0. By attaching the uuid to the device, the manager can trust the
> uuid attached to whoever is trying to connect to him.
>
> One idea is to make the uuid a commandline parameter for the mini-os
> domain and have the vtpm pass the id down to the manager. That means
> however that any rogue domain could potentially connect to the manager
> and send him someone elses uuid, and thus being able to access the vtpms
> stored secrets.
>
> However one could argue that no domain would be able to connect to the
> manager to do this anyway because they would have to create a
> tpmfront/back device pair and the only way to do that is to break into
> the "control domain." If one can do this, then one could just as easily
> set their device uuid to whatever they want.
>
> I hope all that made sense. Do you see any flaws in my reasoning? If so
> I should probably get uuids out of the vtpm devices and simplify this
> whole thing.
>
>
>>
>>  -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 Fri Sep 28 16:43:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Sep 2012 16: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 1THdeQ-0001Cz-AH; Fri, 28 Sep 2012 16:42:54 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <matthew.fioravante@jhuapl.edu>) id 1THdeP-0001Ct-1A
	for xen-devel@lists.xen.org; Fri, 28 Sep 2012 16:42:53 +0000
Received: from [85.158.143.99:52934] by server-3.bemta-4.messagelabs.com id
	2A/5A-10986-C83D5605; Fri, 28 Sep 2012 16:42:52 +0000
X-Env-Sender: matthew.fioravante@jhuapl.edu
X-Msg-Ref: server-13.tower-216.messagelabs.com!1348850570!31260483!1
X-Originating-IP: [128.244.251.36]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG,
	UNPARSEABLE_RELAY
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7209 invoked from network); 28 Sep 2012 16:42:51 -0000
Received: from pilot.jhuapl.edu (HELO jhuapl.edu) (128.244.251.36)
	by server-13.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 28 Sep 2012 16:42:51 -0000
Received: from ([128.244.207.89])
	by pilot.jhuapl.edu with ESMTP with TLS id 63GHCH1.153888242;
	Fri, 28 Sep 2012 12:42:43 -0400
Message-ID: <5065D333.6080600@jhuapl.edu>
Date: Fri, 28 Sep 2012 12:41:23 -0400
From: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120827 Thunderbird/15.0
MIME-Version: 1.0
To: George Dunlap <George.Dunlap@eu.citrix.com>
References: <1348765860-11359-1-git-send-email-matthew.fioravante@jhuapl.edu>
	<1348765860-11359-3-git-send-email-matthew.fioravante@jhuapl.edu>
	<CAFLBxZbvK0WxHhQgY79vCG21fd8b4i=vuVhtFjrpN-saXM61bA@mail.gmail.com>
	<5065CAE9.30602@jhuapl.edu>
	<CAFLBxZYzn0zru_JW0372yzi2f5N0-nfPfd3HDrBKV1G41aoVZQ@mail.gmail.com>
In-Reply-To: <CAFLBxZYzn0zru_JW0372yzi2f5N0-nfPfd3HDrBKV1G41aoVZQ@mail.gmail.com>
X-Enigmail-Version: 1.4.4
Cc: "Ian.Campbell@citrix.com" <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 11/11] add vtpm support to libxl
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============3801910640797618453=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a cryptographically signed message in MIME format.

--===============3801910640797618453==
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms060707050104030509050603"

This is a cryptographically signed message in MIME format.

--------------ms060707050104030509050603
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On 09/28/2012 12:39 PM, George Dunlap wrote:
> On Fri, Sep 28, 2012 at 5:06 PM, Matthew Fioravante
> <matthew.fioravante@jhuapl.edu> wrote:
>> On 09/28/2012 11:03 AM, George Dunlap wrote:
>>> On Thu, Sep 27, 2012 at 6:11 PM, Matthew Fioravante
>>> <matthew.fioravante@jhuapl.edu> wrote:
>>>> This patch adds vtpm support to libxl. It adds vtpm parsing to confi=
g
>>>> files and 3 new xl commands:
>>>> vtpm-attach
>>>> vtpm-detach
>>>> vtpm-list
>>>>
>>>> Signed-off-by: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
>>> Overall looks good to me -- just a few comments below about the confi=
g
>>> file handling (see below).
>>>
>>> Thanks for all your work on this.
>>>
>>>> @@ -601,6 +605,8 @@ static void domcreate_bootloader_done(libxl__egc=
 *egc,
>>>>  static void domcreate_launch_dm(libxl__egc *egc, libxl__multidev *a=
odevs,
>>>>                                  int ret);
>>>>
>>>> +static void domcreate_attach_vtpms(libxl__egc *egc, libxl__multidev=
 *multidev,
>>>> +                                   int ret);
>>>>  static void domcreate_attach_pci(libxl__egc *egc, libxl__multidev *=
aodevs,
>>>>                                   int ret);
>>>>
>>>> @@ -1084,13 +1090,13 @@ static void domcreate_devmodel_started(libxl=
__egc *egc,
>>>>      if (d_config->num_nics > 0) {
>>>>          /* Attach nics */
>>>>          libxl__multidev_begin(ao, &dcs->multidev);
>>>> -        dcs->multidev.callback =3D domcreate_attach_pci;
>>>> +        dcs->multidev.callback =3D domcreate_attach_vtpms;
>>> Wow -- what a weird convention you've had to try to figure out and
>>> modify here.  Well done. :-)
>> It was really tricky. Is there no better way to handle asynchronous
>> code? This method seems really error prone and almost impossible to fo=
llow.
> Well I didn't write it. :-)  I haven't taken the time to figure out
> why it might have been written that way; but at first glance, I tend
> to agree with you.  For about 10 minutes I was convinced you had made
> some kind of weird error, by sprinkling "vtpm" around things that
> obviously were supposed to be about nics and pci devices, until I
> realized you were just following the existing "call chain" convention.
>
>>>> +            p =3D strtok(buf2, ",");
>>>> +            if (!p)
>>>> +                goto skip_vtpm;
>>> Is the purpose of this so that you can have "empty" vtpm slots?
>>> (Since even when skipping, you still increment the num_vtpms counter?=
)
>> That would make a default vtpm with a randomly generated uuid and
>> backend=3Ddom0. Considering that were getting rid of the process model=
, it
>> probably makes sense to force the user to specify a backend domain id
>> because no vtpm device will ever connect to dom0 anymore.
> Ah, right.  Either way is OK with me, but a comment would be useful. :-=
)
>
>>>> +                    }
>>>> +                } else if(!strcmp(p, "uuid")) {
>>>> +                    if( libxl_uuid_from_string(&vtpm->uuid, p2 + 1)=
 ) {
>>>> +                        fprintf(stderr, "Failed to parse vtpm UUID:=
 %s\n", p2 + 1);
>>>> +                        exit(1);
>>>> +                    }
>>>> +                }
>>> If I'm parsing this right, it looks like you will just silently ignor=
e
>>> other arguments -- it seems like throwing an error would be better;
>>> especially to catch things like typos.  Otherwise, if someone does
>>> something like "uid=3D[whatever]", it will act like uuid isn't there =
and
>>> create a new one, instead of alerting the user to the fact that he'd
>>> made a typo in the config file.
>> The behavior here is there if the user passes an invalid uuid string i=
t
>> will fail with a parse error, but if the user does not specify a uuid =
at
>> all, one will be randomly generated. Random generation happens in the
>> vtpm types constructor in the xl type system.
> I think you misunderstood my comment; I'm not actually talking about
> the uuid clause that's there, but the "none of the above" clause
> that's missing.  The code says (in pseudocode):
>
> if("backend")
>  parse backend;
> else if("uuid")
>  parse uuid;
>
> But what if it's neither "backend" or "uuid", but something else --
> say, "uid" or "backedn"?  Then instead of giving an error, it will
> just skip that argument and go on to the next one; and if the user
> *intended* to type "backend" instead of "backedn", it will silently
> use the default, giving her no clue as to what the problem might be.
> I'm proposing adding (again in pseudocode):
>
> else
>   error("Unrecognized argument: %s\n", p);
>
> Does that make sense?
>
Yeah, didn't see that. Good catch.
>> This brings up a bigger wart in the vtpm implementation.
> It's 5:30pm on a Friday, so I'm going to put off grokking the rest of
> this until Monday morning. :-)
Agreed, enjoy your weekend :)
> Have a good weekend,
>  -George
>
>> Its kind of confusing now because the linux guest uses a tpmfront/back=

>> pair to talk to the vtpm, and then vtpm uses another tpmfront/back pai=
r
>> to talk to the manager. You have to specify the uuid on the vtpm's
>> tpmfront device because that is the device the manager sees. You do no=
t
>> have to specify one on the linux domains device.
>>
>> I'd argue that now, especially with the process model gone, the uuid
>> should be a parameter of the vtpm itself and not the tpmfront/back
>> communication channels.
>>
>> The problem is that this uuid needs to specified by the "control domai=
n"
>> or dom0. By attaching the uuid to the device, the manager can trust th=
e
>> uuid attached to whoever is trying to connect to him.
>>
>> One idea is to make the uuid a commandline parameter for the mini-os
>> domain and have the vtpm pass the id down to the manager. That means
>> however that any rogue domain could potentially connect to the manager=

>> and send him someone elses uuid, and thus being able to access the vtp=
ms
>> stored secrets.
>>
>> However one could argue that no domain would be able to connect to the=

>> manager to do this anyway because they would have to create a
>> tpmfront/back device pair and the only way to do that is to break into=

>> the "control domain." If one can do this, then one could just as easil=
y
>> set their device uuid to whatever they want.
>>
>> I hope all that made sense. Do you see any flaws in my reasoning? If s=
o
>> I should probably get uuids out of the vtpm devices and simplify this
>> whole thing.
>>
>>
>>>  -George
>>
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xen.org
>> http://lists.xen.org/xen-devel
>>



--------------ms060707050104030509050603
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIDyjCC
A8YwggMvoAMCAQICBD/xyf0wDQYJKoZIhvcNAQEFBQAwLzELMAkGA1UEBhMCVVMxDzANBgNV
BAoTBkpIVUFQTDEPMA0GA1UECxMGQklTRENBMB4XDTEwMDYxMTE4MjIwNloXDTEzMDYxMTE4
NTIwNlowZjELMAkGA1UEBhMCVVMxDzANBgNVBAoTBkpIVUFQTDEPMA0GA1UECxMGUGVvcGxl
MTUwFgYDVQQLEw9WUE5Hcm91cC1CSVNEQ0EwGwYDVQQDExRNYXR0aGV3IEUgRmlvcmF2YW50
ZTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAnpbwVSP6o1Nb5lcW7dd3yTo9iBJdi7qz
4nANOMFPK7JOy5npKN1iiousl28U/scUJES55gPwAWYJK3uVyQAsA4adgDKi5DoD1UHDQEwp
bY7iHLJeq0NPr4BqYNqnCFPbE6HC8zSJrr4qKn+gVUQT39SIFqdiIPJwZL8FYTRQ/zsCAwEA
AaOCAbYwggGyMAsGA1UdDwQEAwIHgDArBgNVHRAEJDAigA8yMDEwMDYxMTE4MjIwNlqBDzIw
MTIwNzE3MjI1MjA2WjAbBg0rBgEEAbMlCwMBAQEBBAoWCGZpb3JhbWUxMBsGDSsGAQQBsyUL
AwEBAQIEChIIMDAxMDQyNjEwWAYJYIZIAYb6ax4BBEsMSVRoZSBwcml2YXRlIGtleSBjb3Jy
ZXNwb25kaW5nIHRvIHRoaXMgY2VydGlmaWNhdGUgbWF5IGhhdmUgYmVlbiBleHBvcnRlZC4w
KAYDVR0RBCEwH4EdTWF0dGhldy5GaW9yYXZhbnRlQGpodWFwbC5lZHUwUgYDVR0fBEswSTBH
oEWgQ6RBMD8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJU0RD
QTEOMAwGA1UEAxMFQ1JMNTYwHwYDVR0jBBgwFoAUCDUpmxH52EU2CyWmF2EJMB1yqeswHQYD
VR0OBBYEFO6LYxg6r9wHZ+zdQtBHn1dZ/YTNMAkGA1UdEwQCMAAwGQYJKoZIhvZ9B0EABAww
ChsEVjcuMQMCBLAwDQYJKoZIhvcNAQEFBQADgYEAJO9HQh4YNChVLzuZqK5ARJARD8JoujGZ
fdo75quvg2jXFQe2sEjvLnxJZgm/pv8fdZakq48CWwjYHKuvIp7sDjTEsQfo+y7SpN/N2NvJ
WU5SqfK1VgYtNLRRoGJUB5Q1aZ+Dg95g3kqpyfpUMISJL8IKVLtJVfN4fggFVUYZ9wwxggGr
MIIBpwIBATA3MC8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJ
U0RDQQIEP/HJ/TAJBgUrDgMCGgUAoIHLMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ
KoZIhvcNAQkFMQ8XDTEyMDkyODE2NDEyM1owIwYJKoZIhvcNAQkEMRYEFCN+KTw9dop14I+L
7RJSxdQo1hpeMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAK
BggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI
KoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEgYAhO79Qoe+L2gOZcj6QW91IeJjbLmqUvB79
P0tnBhVC0Jwns61Wp18jcD0lhWGlAzphhIHgt0+o86U1ybyWDOwJNB3T7p3xVG8wE7aixYn5
R/Cz2t7Qw4i3n7R4GCNduGjVhncLC6o6Rl+ixEaBR9sQHGUW1I4OZQG5o2i/EsaIfQAAAAAA
AA==
--------------ms060707050104030509050603--


--===============3801910640797618453==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============3801910640797618453==--


From xen-devel-bounces@lists.xen.org Fri Sep 28 16:43:12 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Sep 2012 16: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 1THdeQ-0001Cz-AH; Fri, 28 Sep 2012 16:42:54 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <matthew.fioravante@jhuapl.edu>) id 1THdeP-0001Ct-1A
	for xen-devel@lists.xen.org; Fri, 28 Sep 2012 16:42:53 +0000
Received: from [85.158.143.99:52934] by server-3.bemta-4.messagelabs.com id
	2A/5A-10986-C83D5605; Fri, 28 Sep 2012 16:42:52 +0000
X-Env-Sender: matthew.fioravante@jhuapl.edu
X-Msg-Ref: server-13.tower-216.messagelabs.com!1348850570!31260483!1
X-Originating-IP: [128.244.251.36]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG,
	UNPARSEABLE_RELAY
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7209 invoked from network); 28 Sep 2012 16:42:51 -0000
Received: from pilot.jhuapl.edu (HELO jhuapl.edu) (128.244.251.36)
	by server-13.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 28 Sep 2012 16:42:51 -0000
Received: from ([128.244.207.89])
	by pilot.jhuapl.edu with ESMTP with TLS id 63GHCH1.153888242;
	Fri, 28 Sep 2012 12:42:43 -0400
Message-ID: <5065D333.6080600@jhuapl.edu>
Date: Fri, 28 Sep 2012 12:41:23 -0400
From: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120827 Thunderbird/15.0
MIME-Version: 1.0
To: George Dunlap <George.Dunlap@eu.citrix.com>
References: <1348765860-11359-1-git-send-email-matthew.fioravante@jhuapl.edu>
	<1348765860-11359-3-git-send-email-matthew.fioravante@jhuapl.edu>
	<CAFLBxZbvK0WxHhQgY79vCG21fd8b4i=vuVhtFjrpN-saXM61bA@mail.gmail.com>
	<5065CAE9.30602@jhuapl.edu>
	<CAFLBxZYzn0zru_JW0372yzi2f5N0-nfPfd3HDrBKV1G41aoVZQ@mail.gmail.com>
In-Reply-To: <CAFLBxZYzn0zru_JW0372yzi2f5N0-nfPfd3HDrBKV1G41aoVZQ@mail.gmail.com>
X-Enigmail-Version: 1.4.4
Cc: "Ian.Campbell@citrix.com" <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 11/11] add vtpm support to libxl
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============3801910640797618453=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a cryptographically signed message in MIME format.

--===============3801910640797618453==
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms060707050104030509050603"

This is a cryptographically signed message in MIME format.

--------------ms060707050104030509050603
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On 09/28/2012 12:39 PM, George Dunlap wrote:
> On Fri, Sep 28, 2012 at 5:06 PM, Matthew Fioravante
> <matthew.fioravante@jhuapl.edu> wrote:
>> On 09/28/2012 11:03 AM, George Dunlap wrote:
>>> On Thu, Sep 27, 2012 at 6:11 PM, Matthew Fioravante
>>> <matthew.fioravante@jhuapl.edu> wrote:
>>>> This patch adds vtpm support to libxl. It adds vtpm parsing to confi=
g
>>>> files and 3 new xl commands:
>>>> vtpm-attach
>>>> vtpm-detach
>>>> vtpm-list
>>>>
>>>> Signed-off-by: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
>>> Overall looks good to me -- just a few comments below about the confi=
g
>>> file handling (see below).
>>>
>>> Thanks for all your work on this.
>>>
>>>> @@ -601,6 +605,8 @@ static void domcreate_bootloader_done(libxl__egc=
 *egc,
>>>>  static void domcreate_launch_dm(libxl__egc *egc, libxl__multidev *a=
odevs,
>>>>                                  int ret);
>>>>
>>>> +static void domcreate_attach_vtpms(libxl__egc *egc, libxl__multidev=
 *multidev,
>>>> +                                   int ret);
>>>>  static void domcreate_attach_pci(libxl__egc *egc, libxl__multidev *=
aodevs,
>>>>                                   int ret);
>>>>
>>>> @@ -1084,13 +1090,13 @@ static void domcreate_devmodel_started(libxl=
__egc *egc,
>>>>      if (d_config->num_nics > 0) {
>>>>          /* Attach nics */
>>>>          libxl__multidev_begin(ao, &dcs->multidev);
>>>> -        dcs->multidev.callback =3D domcreate_attach_pci;
>>>> +        dcs->multidev.callback =3D domcreate_attach_vtpms;
>>> Wow -- what a weird convention you've had to try to figure out and
>>> modify here.  Well done. :-)
>> It was really tricky. Is there no better way to handle asynchronous
>> code? This method seems really error prone and almost impossible to fo=
llow.
> Well I didn't write it. :-)  I haven't taken the time to figure out
> why it might have been written that way; but at first glance, I tend
> to agree with you.  For about 10 minutes I was convinced you had made
> some kind of weird error, by sprinkling "vtpm" around things that
> obviously were supposed to be about nics and pci devices, until I
> realized you were just following the existing "call chain" convention.
>
>>>> +            p =3D strtok(buf2, ",");
>>>> +            if (!p)
>>>> +                goto skip_vtpm;
>>> Is the purpose of this so that you can have "empty" vtpm slots?
>>> (Since even when skipping, you still increment the num_vtpms counter?=
)
>> That would make a default vtpm with a randomly generated uuid and
>> backend=3Ddom0. Considering that were getting rid of the process model=
, it
>> probably makes sense to force the user to specify a backend domain id
>> because no vtpm device will ever connect to dom0 anymore.
> Ah, right.  Either way is OK with me, but a comment would be useful. :-=
)
>
>>>> +                    }
>>>> +                } else if(!strcmp(p, "uuid")) {
>>>> +                    if( libxl_uuid_from_string(&vtpm->uuid, p2 + 1)=
 ) {
>>>> +                        fprintf(stderr, "Failed to parse vtpm UUID:=
 %s\n", p2 + 1);
>>>> +                        exit(1);
>>>> +                    }
>>>> +                }
>>> If I'm parsing this right, it looks like you will just silently ignor=
e
>>> other arguments -- it seems like throwing an error would be better;
>>> especially to catch things like typos.  Otherwise, if someone does
>>> something like "uid=3D[whatever]", it will act like uuid isn't there =
and
>>> create a new one, instead of alerting the user to the fact that he'd
>>> made a typo in the config file.
>> The behavior here is there if the user passes an invalid uuid string i=
t
>> will fail with a parse error, but if the user does not specify a uuid =
at
>> all, one will be randomly generated. Random generation happens in the
>> vtpm types constructor in the xl type system.
> I think you misunderstood my comment; I'm not actually talking about
> the uuid clause that's there, but the "none of the above" clause
> that's missing.  The code says (in pseudocode):
>
> if("backend")
>  parse backend;
> else if("uuid")
>  parse uuid;
>
> But what if it's neither "backend" or "uuid", but something else --
> say, "uid" or "backedn"?  Then instead of giving an error, it will
> just skip that argument and go on to the next one; and if the user
> *intended* to type "backend" instead of "backedn", it will silently
> use the default, giving her no clue as to what the problem might be.
> I'm proposing adding (again in pseudocode):
>
> else
>   error("Unrecognized argument: %s\n", p);
>
> Does that make sense?
>
Yeah, didn't see that. Good catch.
>> This brings up a bigger wart in the vtpm implementation.
> It's 5:30pm on a Friday, so I'm going to put off grokking the rest of
> this until Monday morning. :-)
Agreed, enjoy your weekend :)
> Have a good weekend,
>  -George
>
>> Its kind of confusing now because the linux guest uses a tpmfront/back=

>> pair to talk to the vtpm, and then vtpm uses another tpmfront/back pai=
r
>> to talk to the manager. You have to specify the uuid on the vtpm's
>> tpmfront device because that is the device the manager sees. You do no=
t
>> have to specify one on the linux domains device.
>>
>> I'd argue that now, especially with the process model gone, the uuid
>> should be a parameter of the vtpm itself and not the tpmfront/back
>> communication channels.
>>
>> The problem is that this uuid needs to specified by the "control domai=
n"
>> or dom0. By attaching the uuid to the device, the manager can trust th=
e
>> uuid attached to whoever is trying to connect to him.
>>
>> One idea is to make the uuid a commandline parameter for the mini-os
>> domain and have the vtpm pass the id down to the manager. That means
>> however that any rogue domain could potentially connect to the manager=

>> and send him someone elses uuid, and thus being able to access the vtp=
ms
>> stored secrets.
>>
>> However one could argue that no domain would be able to connect to the=

>> manager to do this anyway because they would have to create a
>> tpmfront/back device pair and the only way to do that is to break into=

>> the "control domain." If one can do this, then one could just as easil=
y
>> set their device uuid to whatever they want.
>>
>> I hope all that made sense. Do you see any flaws in my reasoning? If s=
o
>> I should probably get uuids out of the vtpm devices and simplify this
>> whole thing.
>>
>>
>>>  -George
>>
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xen.org
>> http://lists.xen.org/xen-devel
>>



--------------ms060707050104030509050603
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIDyjCC
A8YwggMvoAMCAQICBD/xyf0wDQYJKoZIhvcNAQEFBQAwLzELMAkGA1UEBhMCVVMxDzANBgNV
BAoTBkpIVUFQTDEPMA0GA1UECxMGQklTRENBMB4XDTEwMDYxMTE4MjIwNloXDTEzMDYxMTE4
NTIwNlowZjELMAkGA1UEBhMCVVMxDzANBgNVBAoTBkpIVUFQTDEPMA0GA1UECxMGUGVvcGxl
MTUwFgYDVQQLEw9WUE5Hcm91cC1CSVNEQ0EwGwYDVQQDExRNYXR0aGV3IEUgRmlvcmF2YW50
ZTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAnpbwVSP6o1Nb5lcW7dd3yTo9iBJdi7qz
4nANOMFPK7JOy5npKN1iiousl28U/scUJES55gPwAWYJK3uVyQAsA4adgDKi5DoD1UHDQEwp
bY7iHLJeq0NPr4BqYNqnCFPbE6HC8zSJrr4qKn+gVUQT39SIFqdiIPJwZL8FYTRQ/zsCAwEA
AaOCAbYwggGyMAsGA1UdDwQEAwIHgDArBgNVHRAEJDAigA8yMDEwMDYxMTE4MjIwNlqBDzIw
MTIwNzE3MjI1MjA2WjAbBg0rBgEEAbMlCwMBAQEBBAoWCGZpb3JhbWUxMBsGDSsGAQQBsyUL
AwEBAQIEChIIMDAxMDQyNjEwWAYJYIZIAYb6ax4BBEsMSVRoZSBwcml2YXRlIGtleSBjb3Jy
ZXNwb25kaW5nIHRvIHRoaXMgY2VydGlmaWNhdGUgbWF5IGhhdmUgYmVlbiBleHBvcnRlZC4w
KAYDVR0RBCEwH4EdTWF0dGhldy5GaW9yYXZhbnRlQGpodWFwbC5lZHUwUgYDVR0fBEswSTBH
oEWgQ6RBMD8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJU0RD
QTEOMAwGA1UEAxMFQ1JMNTYwHwYDVR0jBBgwFoAUCDUpmxH52EU2CyWmF2EJMB1yqeswHQYD
VR0OBBYEFO6LYxg6r9wHZ+zdQtBHn1dZ/YTNMAkGA1UdEwQCMAAwGQYJKoZIhvZ9B0EABAww
ChsEVjcuMQMCBLAwDQYJKoZIhvcNAQEFBQADgYEAJO9HQh4YNChVLzuZqK5ARJARD8JoujGZ
fdo75quvg2jXFQe2sEjvLnxJZgm/pv8fdZakq48CWwjYHKuvIp7sDjTEsQfo+y7SpN/N2NvJ
WU5SqfK1VgYtNLRRoGJUB5Q1aZ+Dg95g3kqpyfpUMISJL8IKVLtJVfN4fggFVUYZ9wwxggGr
MIIBpwIBATA3MC8xCzAJBgNVBAYTAlVTMQ8wDQYDVQQKEwZKSFVBUEwxDzANBgNVBAsTBkJJ
U0RDQQIEP/HJ/TAJBgUrDgMCGgUAoIHLMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ
KoZIhvcNAQkFMQ8XDTEyMDkyODE2NDEyM1owIwYJKoZIhvcNAQkEMRYEFCN+KTw9dop14I+L
7RJSxdQo1hpeMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAK
BggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI
KoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEgYAhO79Qoe+L2gOZcj6QW91IeJjbLmqUvB79
P0tnBhVC0Jwns61Wp18jcD0lhWGlAzphhIHgt0+o86U1ybyWDOwJNB3T7p3xVG8wE7aixYn5
R/Cz2t7Qw4i3n7R4GCNduGjVhncLC6o6Rl+ixEaBR9sQHGUW1I4OZQG5o2i/EsaIfQAAAAAA
AA==
--------------ms060707050104030509050603--


--===============3801910640797618453==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============3801910640797618453==--


From xen-devel-bounces@lists.xen.org Fri Sep 28 17:12:55 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Sep 2012 17: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 1THe75-0001Sr-TA; Fri, 28 Sep 2012 17: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 1THe75-0001Sm-51
	for xen-devel@lists.xen.org; Fri, 28 Sep 2012 17:12:31 +0000
Received: from [85.158.143.99:64060] by server-1.bemta-4.messagelabs.com id
	F4/F8-05684-E7AD5605; Fri, 28 Sep 2012 17:12:30 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1348852349!23988078!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTIyOTk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24164 invoked from network); 28 Sep 2012 17:12:29 -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;
	28 Sep 2012 17:12:29 -0000
X-IronPort-AV: E=Sophos;i="4.80,503,1344211200"; d="scan'208";a="14839357"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Sep 2012 17:12: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.279.1; Fri, 28 Sep 2012 18:12: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
	1THe71-0002zV-F9; Fri, 28 Sep 2012 17:12:27 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1THe71-0001qU-BS;
	Fri, 28 Sep 2012 18:12:27 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20581.55931.246130.308384@mariner.uk.xensource.com>
Date: Fri, 28 Sep 2012 18:12:27 +0100
To: Dan Magenheimer <dan.magenheimer@oracle.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <53b8c758-2675-42a7-b63f-4f9ad0006d84@default>
References: <53b8c758-2675-42a7-b63f-4f9ad0006d84@default>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Kurt Hackel <kurt.hackel@oracle.com>, Konrad Wilk <konrad.wilk@oracle.com>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] domain creation vs querying free memory (xend and
	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

Dan Magenheimer writes ("[Xen-devel] domain creation vs querying free memory (xend and xl)"):
> But the second domain launch fails, possibly after
> several minutes because, actually, there isn't enough
> physical RAM for both.

This is a real problem.  The solution is not easy, and may not make it
for 4.3.  It would involve a rework of the memory handling code in
libxl.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 28 17:12:55 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Sep 2012 17: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 1THe75-0001Sr-TA; Fri, 28 Sep 2012 17: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 1THe75-0001Sm-51
	for xen-devel@lists.xen.org; Fri, 28 Sep 2012 17:12:31 +0000
Received: from [85.158.143.99:64060] by server-1.bemta-4.messagelabs.com id
	F4/F8-05684-E7AD5605; Fri, 28 Sep 2012 17:12:30 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1348852349!23988078!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTIyOTk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24164 invoked from network); 28 Sep 2012 17:12:29 -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;
	28 Sep 2012 17:12:29 -0000
X-IronPort-AV: E=Sophos;i="4.80,503,1344211200"; d="scan'208";a="14839357"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Sep 2012 17:12: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.279.1; Fri, 28 Sep 2012 18:12: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
	1THe71-0002zV-F9; Fri, 28 Sep 2012 17:12:27 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1THe71-0001qU-BS;
	Fri, 28 Sep 2012 18:12:27 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20581.55931.246130.308384@mariner.uk.xensource.com>
Date: Fri, 28 Sep 2012 18:12:27 +0100
To: Dan Magenheimer <dan.magenheimer@oracle.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <53b8c758-2675-42a7-b63f-4f9ad0006d84@default>
References: <53b8c758-2675-42a7-b63f-4f9ad0006d84@default>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Kurt Hackel <kurt.hackel@oracle.com>, Konrad Wilk <konrad.wilk@oracle.com>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] domain creation vs querying free memory (xend and
	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

Dan Magenheimer writes ("[Xen-devel] domain creation vs querying free memory (xend and xl)"):
> But the second domain launch fails, possibly after
> several minutes because, actually, there isn't enough
> physical RAM for both.

This is a real problem.  The solution is not easy, and may not make it
for 4.3.  It would involve a rework of the memory handling code in
libxl.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 28 17:17:18 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Sep 2012 17:17:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1THeBF-0001aF-Hy; Fri, 28 Sep 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 <Ian.Jackson@eu.citrix.com>) id 1THeBE-0001a9-OH
	for xen-devel@lists.xen.org; Fri, 28 Sep 2012 17:16:48 +0000
Received: from [85.158.143.35:36782] by server-1.bemta-4.messagelabs.com id
	73/5B-05684-08BD5605; Fri, 28 Sep 2012 17:16:48 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1348852602!14193040!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTIyOTk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14062 invoked from network); 28 Sep 2012 17:16:43 -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;
	28 Sep 2012 17:16:43 -0000
X-IronPort-AV: E=Sophos;i="4.80,503,1344211200"; d="scan'208";a="14839479"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Sep 2012 17:16: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.279.1; Fri, 28 Sep 2012 18:16: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
	1THeB7-00030r-Tv; Fri, 28 Sep 2012 17:16:41 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1THeB7-0001r4-QI;
	Fri, 28 Sep 2012 18:16:41 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20581.56185.438929.702646@mariner.uk.xensource.com>
Date: Fri, 28 Sep 2012 18:16:41 +0100
To: Keir Fraser <keir.xen@gmail.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <CC8A0E9F.400A6%keir.xen@gmail.com>
References: <CAOqnZH5qZAHOw2xLZXNF6KT6qGiqJmYR-L9BLaviBkjAOCAPFA@mail.gmail.com>
	<CC8A0E9F.400A6%keir.xen@gmail.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Lars Kurth <lars.kurth.xen@gmail.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [ANNOUNCE] Switching to git for primary Xen
 repositories
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 writes:
> Our plan therefore, with the 4.2.0 release soon out of the way, is
> to switch to git for all of our primary repositories. We will plan
> to mirror development activity into the old mercurial repositories
> at least in the short term.

So if we're having a vote on this, as discussed:

+1

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 28 17:17:18 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Sep 2012 17:17:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1THeBF-0001aF-Hy; Fri, 28 Sep 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 <Ian.Jackson@eu.citrix.com>) id 1THeBE-0001a9-OH
	for xen-devel@lists.xen.org; Fri, 28 Sep 2012 17:16:48 +0000
Received: from [85.158.143.35:36782] by server-1.bemta-4.messagelabs.com id
	73/5B-05684-08BD5605; Fri, 28 Sep 2012 17:16:48 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1348852602!14193040!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTIyOTk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14062 invoked from network); 28 Sep 2012 17:16:43 -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;
	28 Sep 2012 17:16:43 -0000
X-IronPort-AV: E=Sophos;i="4.80,503,1344211200"; d="scan'208";a="14839479"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Sep 2012 17:16: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.279.1; Fri, 28 Sep 2012 18:16: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
	1THeB7-00030r-Tv; Fri, 28 Sep 2012 17:16:41 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1THeB7-0001r4-QI;
	Fri, 28 Sep 2012 18:16:41 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20581.56185.438929.702646@mariner.uk.xensource.com>
Date: Fri, 28 Sep 2012 18:16:41 +0100
To: Keir Fraser <keir.xen@gmail.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <CC8A0E9F.400A6%keir.xen@gmail.com>
References: <CAOqnZH5qZAHOw2xLZXNF6KT6qGiqJmYR-L9BLaviBkjAOCAPFA@mail.gmail.com>
	<CC8A0E9F.400A6%keir.xen@gmail.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Lars Kurth <lars.kurth.xen@gmail.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [ANNOUNCE] Switching to git for primary Xen
 repositories
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 writes:
> Our plan therefore, with the 4.2.0 release soon out of the way, is
> to switch to git for all of our primary repositories. We will plan
> to mirror development activity into the old mercurial repositories
> at least in the short term.

So if we're having a vote on this, as discussed:

+1

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 28 17:17:32 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Sep 2012 17: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 1THeBc-0001bo-Uw; Fri, 28 Sep 2012 17:17: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 1THeBb-0001bU-0c
	for xen-devel@lists.xen.org; Fri, 28 Sep 2012 17:17:11 +0000
Received: from [85.158.139.211:32551] by server-11.bemta-5.messagelabs.com id
	81/C6-13866-69BD5605; Fri, 28 Sep 2012 17:17:10 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-206.messagelabs.com!1348852629!16386332!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTIyOTk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31754 invoked from network); 28 Sep 2012 17:17:09 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Sep 2012 17:17:09 -0000
X-IronPort-AV: E=Sophos;i="4.80,503,1344211200"; d="scan'208";a="14839499"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Sep 2012 17:17: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.279.1; Fri, 28 Sep 2012 18:17: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
	1THeBV-000316-07; Fri, 28 Sep 2012 17:17:05 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1THeBU-0001rM-SF;
	Fri, 28 Sep 2012 18:17:04 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20581.56208.778068.919227@mariner.uk.xensource.com>
Date: Fri, 28 Sep 2012 18:17:04 +0100
To: lars.kurth@xen.org
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <5065815C.5000408@xen.org>
References: <5065815C.5000408@xen.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] Xen dedicated meeting space at LinuxCon EU in BCN,
 Nov 8th AM - need your input
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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] Xen dedicated meeting space at LinuxCon EU in BCN, Nov 8th AM - need your input"):
> Here is what I need you to do:
> - If you are at LinuxCon and am interested please respond with "+YES"
> - If you do not have any conrete plans to attend LinuxCon yet, but would 
> consider reply with "+MAYBE"

As you know I'll be there:

+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 Sep 28 17:17:32 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Sep 2012 17: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 1THeBc-0001bo-Uw; Fri, 28 Sep 2012 17:17: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 1THeBb-0001bU-0c
	for xen-devel@lists.xen.org; Fri, 28 Sep 2012 17:17:11 +0000
Received: from [85.158.139.211:32551] by server-11.bemta-5.messagelabs.com id
	81/C6-13866-69BD5605; Fri, 28 Sep 2012 17:17:10 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-206.messagelabs.com!1348852629!16386332!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTIyOTk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31754 invoked from network); 28 Sep 2012 17:17:09 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Sep 2012 17:17:09 -0000
X-IronPort-AV: E=Sophos;i="4.80,503,1344211200"; d="scan'208";a="14839499"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Sep 2012 17:17: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.279.1; Fri, 28 Sep 2012 18:17: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
	1THeBV-000316-07; Fri, 28 Sep 2012 17:17:05 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1THeBU-0001rM-SF;
	Fri, 28 Sep 2012 18:17:04 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20581.56208.778068.919227@mariner.uk.xensource.com>
Date: Fri, 28 Sep 2012 18:17:04 +0100
To: lars.kurth@xen.org
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <5065815C.5000408@xen.org>
References: <5065815C.5000408@xen.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] Xen dedicated meeting space at LinuxCon EU in BCN,
 Nov 8th AM - need your input
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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] Xen dedicated meeting space at LinuxCon EU in BCN, Nov 8th AM - need your input"):
> Here is what I need you to do:
> - If you are at LinuxCon and am interested please respond with "+YES"
> - If you do not have any conrete plans to attend LinuxCon yet, but would 
> consider reply with "+MAYBE"

As you know I'll be there:

+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 Sep 28 17:22:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Sep 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 1THeGM-0001v2-UW; Fri, 28 Sep 2012 17:22: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 1THeGL-0001uv-C9
	for xen-devel@lists.xen.org; Fri, 28 Sep 2012 17:22:05 +0000
Received: from [85.158.139.83:40791] by server-8.bemta-5.messagelabs.com id
	CA/56-18073-CBCD5605; Fri, 28 Sep 2012 17:22:04 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1348852924!28067517!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTIyOTk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20909 invoked from network); 28 Sep 2012 17:22:04 -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 Sep 2012 17:22:04 -0000
X-IronPort-AV: E=Sophos;i="4.80,503,1344211200"; d="scan'208";a="14839711"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Sep 2012 17:22: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.279.1; Fri, 28 Sep 2012 18:22: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
	1THeGJ-00032a-GM; Fri, 28 Sep 2012 17:22:03 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1THeGJ-0001ri-Cm;
	Fri, 28 Sep 2012 18:22:03 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20581.56505.946303.990641@mariner.uk.xensource.com>
Date: Fri, 28 Sep 2012 18:22:01 +0100
To: Anthony PERARD <anthony.perard@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1348666294-18182-2-git-send-email-anthony.perard@citrix.com>
References: <1348666294-18182-1-git-send-email-anthony.perard@citrix.com>
	<1348666294-18182-2-git-send-email-anthony.perard@citrix.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>, Xen Devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 1/2] libxl_json: Use libxl alloc 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

Anthony PERARD writes ("[Xen-devel] [PATCH 1/2] libxl_json: Use libxl alloc function"):
> This patch makes use of the libxl allocation API and removes the check for
> allocation failure.
> 
> This patch also assume that flexarray does not need to be freed as it will be
> gc'd in the next patch.

Is this really the right way to structure this series ?  It seems that
after applying only the first, the code has a memory leak.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 28 17:22:26 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Sep 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 1THeGM-0001v2-UW; Fri, 28 Sep 2012 17:22: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 1THeGL-0001uv-C9
	for xen-devel@lists.xen.org; Fri, 28 Sep 2012 17:22:05 +0000
Received: from [85.158.139.83:40791] by server-8.bemta-5.messagelabs.com id
	CA/56-18073-CBCD5605; Fri, 28 Sep 2012 17:22:04 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1348852924!28067517!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTIyOTk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20909 invoked from network); 28 Sep 2012 17:22:04 -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 Sep 2012 17:22:04 -0000
X-IronPort-AV: E=Sophos;i="4.80,503,1344211200"; d="scan'208";a="14839711"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Sep 2012 17:22: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.279.1; Fri, 28 Sep 2012 18:22: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
	1THeGJ-00032a-GM; Fri, 28 Sep 2012 17:22:03 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1THeGJ-0001ri-Cm;
	Fri, 28 Sep 2012 18:22:03 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20581.56505.946303.990641@mariner.uk.xensource.com>
Date: Fri, 28 Sep 2012 18:22:01 +0100
To: Anthony PERARD <anthony.perard@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1348666294-18182-2-git-send-email-anthony.perard@citrix.com>
References: <1348666294-18182-1-git-send-email-anthony.perard@citrix.com>
	<1348666294-18182-2-git-send-email-anthony.perard@citrix.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>, Xen Devel <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 1/2] libxl_json: Use libxl alloc 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

Anthony PERARD writes ("[Xen-devel] [PATCH 1/2] libxl_json: Use libxl alloc function"):
> This patch makes use of the libxl allocation API and removes the check for
> allocation failure.
> 
> This patch also assume that flexarray does not need to be freed as it will be
> gc'd in the next patch.

Is this really the right way to structure this series ?  It seems that
after applying only the first, the code has a memory leak.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 28 17:26:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Sep 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 1THeJv-00022M-Ic; Fri, 28 Sep 2012 17:25:47 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ketuzsezr@gmail.com>) id 1THeJu-00022H-Tn
	for xen-devel@lists.xen.org; Fri, 28 Sep 2012 17:25:47 +0000
Received: from [85.158.143.99:38175] by server-3.bemta-4.messagelabs.com id
	EE/95-10986-A9DD5605; Fri, 28 Sep 2012 17:25:46 +0000
X-Env-Sender: ketuzsezr@gmail.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1348853144!20935844!1
X-Originating-IP: [209.85.219.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8950 invoked from network); 28 Sep 2012 17:25:45 -0000
Received: from mail-oa0-f45.google.com (HELO mail-oa0-f45.google.com)
	(209.85.219.45)
	by server-16.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Sep 2012 17:25:45 -0000
Received: by oagi18 with SMTP id i18so4293502oag.32
	for <xen-devel@lists.xen.org>; Fri, 28 Sep 2012 10:25:44 -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=7V8bLllIM0smoACpWOkunnydxrMhEIbwP5OHeRjp5do=;
	b=rqGL5t1g5nBTcZ1+hwg0Tlg0YLTL+Y8fhM6DXQTaz12PT730AJhHrxqkLJotQYG216
	ahHp1lTyQtmPjoUqA3t/rogcl3sdOb4LVUD+6fAfsuhjgaEZivvA99ZXD2iHUTTNWBjP
	zPM9Xu0Vcs8rTbU/cTM8K3WlbK6Q+dSYgu/AgLjNwEPZlgsLkhKpXkaQ3Ipo8Xw7QPgo
	J+Oy1uIBZG7WDSBraQIg3+OjZHDbt3Q9HtxAkEVzRd0SP2MDVCQLQwe5ZEXfI2Z/dBZI
	KDbEnGBo/R5imk7LWvXVcf/1AKcO5JmijWBVnbx/CxJRrNAAW+uMVFxSzawdV1blsKV3
	W9mA==
Received: by 10.182.0.1 with SMTP id 1mr6333327oba.18.1348853144155;
	Fri, 28 Sep 2012 10:25:44 -0700 (PDT)
Received: from localhost.localdomain ([72.95.90.214])
	by mx.google.com with ESMTPS id y10sm6884270oed.12.2012.09.28.10.25.42
	(version=TLSv1/SSLv3 cipher=OTHER);
	Fri, 28 Sep 2012 10:25:43 -0700 (PDT)
Date: Fri, 28 Sep 2012 13:41:12 -0400
From: Konrad Rzeszutek Wilk <konrad@kernel.org>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20120928174111.GA17182@localhost.localdomain>
References: <1348662212-3559-1-git-send-email-paul.durrant@citrix.com>
	<1348662212-3559-2-git-send-email-paul.durrant@citrix.com>
	<20120926124915.GH7356@phenom.dumpdata.com>
	<5064253C020000780009E312@nat28.tlf.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <5064253C020000780009E312@nat28.tlf.novell.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: annie.li@oracle.com, Paul Durrant <paul.durrant@citrix.com>,
	steve.prochniak@oracle.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 1/2] Add a new pvdrivers header to serve as
 the register of product numbers.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Sep 27, 2012 at 09:06:52AM +0100, Jan Beulich wrote:
> >>> On 26.09.12 at 14:49, Konrad Rzeszutek Wilk <konrad@kernel.org> wrote:
> > On Wed, Sep 26, 2012 at 01:23:31PM +0100, Paul Durrant wrote:
> >> +#define	PVDRIVERS_XENSOURCE_WINDOWS_ID		0x0001	/* Citrix */
> >> +#define	PVDRIVERS_XENSOURCE_WINDOWS_NAME	"xensource-windows"
> >> +
> >> +#define	PVDRIVERS_GPLPV_WINDOWS_ID		0x0002	/* James Harper */
> >> +#define	PVDRIVERS_GPLPV_WINDOWS_NAME		"gplpv-windows"
> > 
> > And also the Oracle one :-)
> > 
> > The Novell one looks to be using 107?
> 
> Where did you spot that one? I was only able to locate use of
> 0xffff...

Let me doublecheck then. I saw it from the /var/log/xen/qemu.. being
printed. This was a Win2K guest.
> 
> 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 Sep 28 17:26:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Sep 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 1THeJv-00022M-Ic; Fri, 28 Sep 2012 17:25:47 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ketuzsezr@gmail.com>) id 1THeJu-00022H-Tn
	for xen-devel@lists.xen.org; Fri, 28 Sep 2012 17:25:47 +0000
Received: from [85.158.143.99:38175] by server-3.bemta-4.messagelabs.com id
	EE/95-10986-A9DD5605; Fri, 28 Sep 2012 17:25:46 +0000
X-Env-Sender: ketuzsezr@gmail.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1348853144!20935844!1
X-Originating-IP: [209.85.219.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8950 invoked from network); 28 Sep 2012 17:25:45 -0000
Received: from mail-oa0-f45.google.com (HELO mail-oa0-f45.google.com)
	(209.85.219.45)
	by server-16.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Sep 2012 17:25:45 -0000
Received: by oagi18 with SMTP id i18so4293502oag.32
	for <xen-devel@lists.xen.org>; Fri, 28 Sep 2012 10:25:44 -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=7V8bLllIM0smoACpWOkunnydxrMhEIbwP5OHeRjp5do=;
	b=rqGL5t1g5nBTcZ1+hwg0Tlg0YLTL+Y8fhM6DXQTaz12PT730AJhHrxqkLJotQYG216
	ahHp1lTyQtmPjoUqA3t/rogcl3sdOb4LVUD+6fAfsuhjgaEZivvA99ZXD2iHUTTNWBjP
	zPM9Xu0Vcs8rTbU/cTM8K3WlbK6Q+dSYgu/AgLjNwEPZlgsLkhKpXkaQ3Ipo8Xw7QPgo
	J+Oy1uIBZG7WDSBraQIg3+OjZHDbt3Q9HtxAkEVzRd0SP2MDVCQLQwe5ZEXfI2Z/dBZI
	KDbEnGBo/R5imk7LWvXVcf/1AKcO5JmijWBVnbx/CxJRrNAAW+uMVFxSzawdV1blsKV3
	W9mA==
Received: by 10.182.0.1 with SMTP id 1mr6333327oba.18.1348853144155;
	Fri, 28 Sep 2012 10:25:44 -0700 (PDT)
Received: from localhost.localdomain ([72.95.90.214])
	by mx.google.com with ESMTPS id y10sm6884270oed.12.2012.09.28.10.25.42
	(version=TLSv1/SSLv3 cipher=OTHER);
	Fri, 28 Sep 2012 10:25:43 -0700 (PDT)
Date: Fri, 28 Sep 2012 13:41:12 -0400
From: Konrad Rzeszutek Wilk <konrad@kernel.org>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20120928174111.GA17182@localhost.localdomain>
References: <1348662212-3559-1-git-send-email-paul.durrant@citrix.com>
	<1348662212-3559-2-git-send-email-paul.durrant@citrix.com>
	<20120926124915.GH7356@phenom.dumpdata.com>
	<5064253C020000780009E312@nat28.tlf.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <5064253C020000780009E312@nat28.tlf.novell.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: annie.li@oracle.com, Paul Durrant <paul.durrant@citrix.com>,
	steve.prochniak@oracle.com, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH 1/2] Add a new pvdrivers header to serve as
 the register of product numbers.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Sep 27, 2012 at 09:06:52AM +0100, Jan Beulich wrote:
> >>> On 26.09.12 at 14:49, Konrad Rzeszutek Wilk <konrad@kernel.org> wrote:
> > On Wed, Sep 26, 2012 at 01:23:31PM +0100, Paul Durrant wrote:
> >> +#define	PVDRIVERS_XENSOURCE_WINDOWS_ID		0x0001	/* Citrix */
> >> +#define	PVDRIVERS_XENSOURCE_WINDOWS_NAME	"xensource-windows"
> >> +
> >> +#define	PVDRIVERS_GPLPV_WINDOWS_ID		0x0002	/* James Harper */
> >> +#define	PVDRIVERS_GPLPV_WINDOWS_NAME		"gplpv-windows"
> > 
> > And also the Oracle one :-)
> > 
> > The Novell one looks to be using 107?
> 
> Where did you spot that one? I was only able to locate use of
> 0xffff...

Let me doublecheck then. I saw it from the /var/log/xen/qemu.. being
printed. This was a Win2K guest.
> 
> 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 Sep 28 17:27:22 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Sep 2012 17:27: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 1THeLB-00027n-18; Fri, 28 Sep 2012 17:27: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 1THeL9-00027b-IZ
	for xen-devel@lists.xen.org; Fri, 28 Sep 2012 17:27:03 +0000
Received: from [85.158.138.51:13152] by server-5.bemta-3.messagelabs.com id
	FE/03-00589-6EDD5605; Fri, 28 Sep 2012 17:27:02 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1348853222!30692109!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTIyOTk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30080 invoked from network); 28 Sep 2012 17:27:02 -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 Sep 2012 17:27:02 -0000
X-IronPort-AV: E=Sophos;i="4.80,503,1344211200"; d="scan'208";a="14839850"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Sep 2012 17:27:01 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Fri, 28 Sep 2012 18:27:01 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1THeL7-00034M-GX; Fri, 28 Sep 2012 17:27:01 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1THeL7-0001sE-Ci;
	Fri, 28 Sep 2012 18:27:01 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20581.56805.294140.556698@mariner.uk.xensource.com>
Date: Fri, 28 Sep 2012 18:27:01 +0100
To: Anthony PERARD <anthony.perard@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1348666294-18182-3-git-send-email-anthony.perard@citrix.com>
References: <1348666294-18182-1-git-send-email-anthony.perard@citrix.com>
	<1348666294-18182-3-git-send-email-anthony.perard@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 <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 2/2] libxl: Have flexarray using the GC
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Anthony PERARD writes ("[Xen-devel] [PATCH 2/2] libxl: Have flexarray using the GC"):
> This patch makes the flexarray function libxl__gc aware.
...
> -flexarray_t *flexarray_make(int size, int autogrow)
> +flexarray_t *flexarray_make(libxl__gc *gc, int size, int autogrow)
...
>  {
...
> +    array->gc = gc;

If gc is NOGC then this does the wrong thing.  Callers should be able
to specify NOGC for a flexarray which they want to survive across
multiple calls into libxl.

For this all to work correctly, including error handling, I think
flexarray_grow and its callers need to take a gc from the context.  It
would be wise to assert that the either 1. both the gc passed to make
and grow are NOGC or 2. they are the same.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 28 17:27:22 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Sep 2012 17:27: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 1THeLB-00027n-18; Fri, 28 Sep 2012 17:27: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 1THeL9-00027b-IZ
	for xen-devel@lists.xen.org; Fri, 28 Sep 2012 17:27:03 +0000
Received: from [85.158.138.51:13152] by server-5.bemta-3.messagelabs.com id
	FE/03-00589-6EDD5605; Fri, 28 Sep 2012 17:27:02 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1348853222!30692109!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTIyOTk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30080 invoked from network); 28 Sep 2012 17:27:02 -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 Sep 2012 17:27:02 -0000
X-IronPort-AV: E=Sophos;i="4.80,503,1344211200"; d="scan'208";a="14839850"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Sep 2012 17:27:01 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.279.1; Fri, 28 Sep 2012 18:27:01 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1THeL7-00034M-GX; Fri, 28 Sep 2012 17:27:01 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1THeL7-0001sE-Ci;
	Fri, 28 Sep 2012 18:27:01 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20581.56805.294140.556698@mariner.uk.xensource.com>
Date: Fri, 28 Sep 2012 18:27:01 +0100
To: Anthony PERARD <anthony.perard@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1348666294-18182-3-git-send-email-anthony.perard@citrix.com>
References: <1348666294-18182-1-git-send-email-anthony.perard@citrix.com>
	<1348666294-18182-3-git-send-email-anthony.perard@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 <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [PATCH 2/2] libxl: Have flexarray using the GC
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Anthony PERARD writes ("[Xen-devel] [PATCH 2/2] libxl: Have flexarray using the GC"):
> This patch makes the flexarray function libxl__gc aware.
...
> -flexarray_t *flexarray_make(int size, int autogrow)
> +flexarray_t *flexarray_make(libxl__gc *gc, int size, int autogrow)
...
>  {
...
> +    array->gc = gc;

If gc is NOGC then this does the wrong thing.  Callers should be able
to specify NOGC for a flexarray which they want to survive across
multiple calls into libxl.

For this all to work correctly, including error handling, I think
flexarray_grow and its callers need to take a gc from the context.  It
would be wise to assert that the either 1. both the gc passed to make
and grow are NOGC or 2. they are the same.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 28 17:51:52 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Sep 2012 17: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 1THeiu-0002P4-Ag; Fri, 28 Sep 2012 17:51: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 1THeit-0002Oz-4s
	for xen-devel@lists.xensource.com; Fri, 28 Sep 2012 17:51:35 +0000
Received: from [85.158.137.99:16258] by server-5.bemta-3.messagelabs.com id
	1E/62-00589-6A3E5605; Fri, 28 Sep 2012 17:51:34 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-217.messagelabs.com!1348854693!14190478!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTIyOTk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26505 invoked from network); 28 Sep 2012 17:51:34 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Sep 2012 17:51:34 -0000
X-IronPort-AV: E=Sophos;i="4.80,503,1344211200"; d="scan'208";a="14840234"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Sep 2012 17:51: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.279.1; Fri, 28 Sep 2012 18:51: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
	1THeiq-0003CE-SS; Fri, 28 Sep 2012 17:51:32 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1THeiq-0001tk-Ng;
	Fri, 28 Sep 2012 18:51:32 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20581.58276.573643.315620@mariner.uk.xensource.com>
Date: Fri, 28 Sep 2012 18:51:32 +0100
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <alpine.DEB.2.02.1209261241410.29232@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1209261241410.29232@kaball.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com, Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH v2] libxl/qemu-xen: use cache=writeback for
	IDE	and SCSI
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 v2] libxl/qemu-xen: use cache=writeback for IDE and SCSI"):
> Change caching mode from writethrough to writeback for upstream QEMU.
> 
> After a lengthy discussion, we came up with the conclusion that
> WRITEBACK is OK for IDE.
> See: http://marc.info/?l=xen-devel&m=133311527009773
> 
> Given that the same reasons apply to SCSI as well, change to writeback
> for SCSI too.

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 Sep 28 17:51:52 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Sep 2012 17: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 1THeiu-0002P4-Ag; Fri, 28 Sep 2012 17:51: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 1THeit-0002Oz-4s
	for xen-devel@lists.xensource.com; Fri, 28 Sep 2012 17:51:35 +0000
Received: from [85.158.137.99:16258] by server-5.bemta-3.messagelabs.com id
	1E/62-00589-6A3E5605; Fri, 28 Sep 2012 17:51:34 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-217.messagelabs.com!1348854693!14190478!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTIyOTk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26505 invoked from network); 28 Sep 2012 17:51:34 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-217.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Sep 2012 17:51:34 -0000
X-IronPort-AV: E=Sophos;i="4.80,503,1344211200"; d="scan'208";a="14840234"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Sep 2012 17:51: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.279.1; Fri, 28 Sep 2012 18:51: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
	1THeiq-0003CE-SS; Fri, 28 Sep 2012 17:51:32 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1THeiq-0001tk-Ng;
	Fri, 28 Sep 2012 18:51:32 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20581.58276.573643.315620@mariner.uk.xensource.com>
Date: Fri, 28 Sep 2012 18:51:32 +0100
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <alpine.DEB.2.02.1209261241410.29232@kaball.uk.xensource.com>
References: <alpine.DEB.2.02.1209261241410.29232@kaball.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com, Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH v2] libxl/qemu-xen: use cache=writeback for
	IDE	and SCSI
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 v2] libxl/qemu-xen: use cache=writeback for IDE and SCSI"):
> Change caching mode from writethrough to writeback for upstream QEMU.
> 
> After a lengthy discussion, we came up with the conclusion that
> WRITEBACK is OK for IDE.
> See: http://marc.info/?l=xen-devel&m=133311527009773
> 
> Given that the same reasons apply to SCSI as well, change to writeback
> for SCSI too.

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 Sep 28 17:55:10 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Sep 2012 17:55: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 1THem4-0002Wn-UV; Fri, 28 Sep 2012 17: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 1THem3-0002Wh-Lo
	for xen-devel@lists.xen.org; Fri, 28 Sep 2012 17:54:51 +0000
Received: from [85.158.143.35:58472] by server-1.bemta-4.messagelabs.com id
	96/9E-05684-B64E5605; Fri, 28 Sep 2012 17:54:51 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1348854890!16762739!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTIyOTk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20387 invoked from network); 28 Sep 2012 17:54:50 -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;
	28 Sep 2012 17:54:50 -0000
X-IronPort-AV: E=Sophos;i="4.80,503,1344211200"; d="scan'208";a="14840304"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Sep 2012 17:54: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.279.1; Fri, 28 Sep 2012 18:54: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
	1THem2-0003DG-9V; Fri, 28 Sep 2012 17:54:50 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1THem2-0001u4-5s;
	Fri, 28 Sep 2012 18:54:50 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20581.58473.910119.605510@mariner.uk.xensource.com>
Date: Fri, 28 Sep 2012 18:54:49 +0100
To: Paul Durrant <paul.durrant@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1348667438-28496-2-git-send-email-paul.durrant@citrix.com>
References: <1348667438-28496-1-git-send-email-paul.durrant@citrix.com>
	<1348667438-28496-2-git-send-email-paul.durrant@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 1/2] Add a new pvdrivers header to serve as
	the	register of product numbers.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Paul Durrant writes ("[Xen-devel] [PATCH 1/2] Add a new pvdrivers header to serve as the register of product numbers."):
> These product numbers are used by the QEMU blacklisting protocol in
> traditional QEMU and are currently coded directly into the xenstore.c
> source module. Since there are now multiple QEMUs this information
> should be pulled into a public header to avoid duplication/conflict.
> hvm-emulated-unplug.markdown has also been adjusted to reference the
> new header.

> +#define	PVDRIVERS_XENSOURCE_WINDOWS_ID		0x0001	/* Citrix */
> +#define	PVDRIVERS_XENSOURCE_WINDOWS_NAME	"xensource-windows"
> +
> +#define	PVDRIVERS_GPLPV_WINDOWS_ID		0x0002	/* James Harper */
> +#define	PVDRIVERS_GPLPV_WINDOWS_NAME		"gplpv-windows"
> +
> +#define	PVDRIVERS_EXPERIMENTAL_ID		0xffff
> +#define	PVDRIVERS_EXPERIMENTAL_NAME		"experimental"

This form for this list is very ill-suited to many obvious uses.  For
example it cannot be used to automatically generate a switch statement
or a table of values for printing.

Can I suggest

#define PVDRIVERS_ID_NAME_LIST(EACH)                      \
  EACH(WINDOWS, 0x0001 /* Citrix */, "xensource-windows") \
  ...

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 Fri Sep 28 17:55:10 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Sep 2012 17:55: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 1THem4-0002Wn-UV; Fri, 28 Sep 2012 17: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 1THem3-0002Wh-Lo
	for xen-devel@lists.xen.org; Fri, 28 Sep 2012 17:54:51 +0000
Received: from [85.158.143.35:58472] by server-1.bemta-4.messagelabs.com id
	96/9E-05684-B64E5605; Fri, 28 Sep 2012 17:54:51 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1348854890!16762739!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTIyOTk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20387 invoked from network); 28 Sep 2012 17:54:50 -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;
	28 Sep 2012 17:54:50 -0000
X-IronPort-AV: E=Sophos;i="4.80,503,1344211200"; d="scan'208";a="14840304"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Sep 2012 17:54: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.279.1; Fri, 28 Sep 2012 18:54: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
	1THem2-0003DG-9V; Fri, 28 Sep 2012 17:54:50 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1THem2-0001u4-5s;
	Fri, 28 Sep 2012 18:54:50 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20581.58473.910119.605510@mariner.uk.xensource.com>
Date: Fri, 28 Sep 2012 18:54:49 +0100
To: Paul Durrant <paul.durrant@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1348667438-28496-2-git-send-email-paul.durrant@citrix.com>
References: <1348667438-28496-1-git-send-email-paul.durrant@citrix.com>
	<1348667438-28496-2-git-send-email-paul.durrant@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 1/2] Add a new pvdrivers header to serve as
	the	register of product numbers.
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Paul Durrant writes ("[Xen-devel] [PATCH 1/2] Add a new pvdrivers header to serve as the register of product numbers."):
> These product numbers are used by the QEMU blacklisting protocol in
> traditional QEMU and are currently coded directly into the xenstore.c
> source module. Since there are now multiple QEMUs this information
> should be pulled into a public header to avoid duplication/conflict.
> hvm-emulated-unplug.markdown has also been adjusted to reference the
> new header.

> +#define	PVDRIVERS_XENSOURCE_WINDOWS_ID		0x0001	/* Citrix */
> +#define	PVDRIVERS_XENSOURCE_WINDOWS_NAME	"xensource-windows"
> +
> +#define	PVDRIVERS_GPLPV_WINDOWS_ID		0x0002	/* James Harper */
> +#define	PVDRIVERS_GPLPV_WINDOWS_NAME		"gplpv-windows"
> +
> +#define	PVDRIVERS_EXPERIMENTAL_ID		0xffff
> +#define	PVDRIVERS_EXPERIMENTAL_NAME		"experimental"

This form for this list is very ill-suited to many obvious uses.  For
example it cannot be used to automatically generate a switch statement
or a table of values for printing.

Can I suggest

#define PVDRIVERS_ID_NAME_LIST(EACH)                      \
  EACH(WINDOWS, 0x0001 /* Citrix */, "xensource-windows") \
  ...

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 Fri Sep 28 17:56:17 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Sep 2012 17:56: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 1THenF-0002cE-Cz; Fri, 28 Sep 2012 17:56:05 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1THenE-0002c9-QG
	for xen-devel@lists.xen.org; Fri, 28 Sep 2012 17:56:05 +0000
Received: from [85.158.139.211:25059] by server-11.bemta-5.messagelabs.com id
	3A/7B-13866-4B4E5605; Fri, 28 Sep 2012 17:56:04 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-206.messagelabs.com!1348854963!20353670!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTIyOTk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12572 invoked from network); 28 Sep 2012 17:56:03 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Sep 2012 17:56:03 -0000
X-IronPort-AV: E=Sophos;i="4.80,503,1344211200"; d="scan'208";a="14840335"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Sep 2012 17: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.279.1; Fri, 28 Sep 2012 18:55:58 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1THen8-0003Db-JH; Fri, 28 Sep 2012 17:55:58 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1THen8-0001uJ-Fu;
	Fri, 28 Sep 2012 18:55:58 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20581.58542.402088.878499@mariner.uk.xensource.com>
Date: Fri, 28 Sep 2012 18:55:58 +0100
To: Paul Durrant <paul.durrant@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1348667684-29202-1-git-send-email-paul.durrant@citrix.com>
References: <1348667684-29202-1-git-send-email-paul.durrant@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] Use new Xen public header for product
	numbers	and names
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Paul Durrant writes ("[Xen-devel] [PATCH] Use new Xen public header for product numbers and names"):
> xen/include/public/hvm/pvdrivers.h has been added as the
> register of product numbers used by the blacklisting protocol.
> Use the definitions therein rather then locally coded values.

This approach duplicates the list as is IMO not acceptable:

> +    case PVDRIVERS_XENSOURCE_WINDOWS_ID:
> +        product = PVDRIVERS_XENSOURCE_WINDOWS_NAME;
> +        break;
> +    case PVDRIVERS_GPLPV_WINDOWS_ID:
> +        product = PVDRIVERS_GPLPV_WINDOWS_NAME;
> +        break;
> +    case PVDRIVERS_LINUX_ID:
> +        product = PVDRIVERS_LINUX_NAME;
> +        break;
> +    case PVDRIVERS_EXPERIMENTAL_ID:
> +        product = PVDRIVERS_EXPERIMENTAL_NAME; 
> +        break;

We need to avoid this formulaic code which needs changing every time a
new entry is added.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 28 17:56:17 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Sep 2012 17:56: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 1THenF-0002cE-Cz; Fri, 28 Sep 2012 17:56:05 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1THenE-0002c9-QG
	for xen-devel@lists.xen.org; Fri, 28 Sep 2012 17:56:05 +0000
Received: from [85.158.139.211:25059] by server-11.bemta-5.messagelabs.com id
	3A/7B-13866-4B4E5605; Fri, 28 Sep 2012 17:56:04 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-206.messagelabs.com!1348854963!20353670!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTIyOTk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12572 invoked from network); 28 Sep 2012 17:56:03 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Sep 2012 17:56:03 -0000
X-IronPort-AV: E=Sophos;i="4.80,503,1344211200"; d="scan'208";a="14840335"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Sep 2012 17: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.279.1; Fri, 28 Sep 2012 18:55:58 +0100
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1THen8-0003Db-JH; Fri, 28 Sep 2012 17:55:58 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1THen8-0001uJ-Fu;
	Fri, 28 Sep 2012 18:55:58 +0100
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20581.58542.402088.878499@mariner.uk.xensource.com>
Date: Fri, 28 Sep 2012 18:55:58 +0100
To: Paul Durrant <paul.durrant@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1348667684-29202-1-git-send-email-paul.durrant@citrix.com>
References: <1348667684-29202-1-git-send-email-paul.durrant@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] Use new Xen public header for product
	numbers	and names
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Paul Durrant writes ("[Xen-devel] [PATCH] Use new Xen public header for product numbers and names"):
> xen/include/public/hvm/pvdrivers.h has been added as the
> register of product numbers used by the blacklisting protocol.
> Use the definitions therein rather then locally coded values.

This approach duplicates the list as is IMO not acceptable:

> +    case PVDRIVERS_XENSOURCE_WINDOWS_ID:
> +        product = PVDRIVERS_XENSOURCE_WINDOWS_NAME;
> +        break;
> +    case PVDRIVERS_GPLPV_WINDOWS_ID:
> +        product = PVDRIVERS_GPLPV_WINDOWS_NAME;
> +        break;
> +    case PVDRIVERS_LINUX_ID:
> +        product = PVDRIVERS_LINUX_NAME;
> +        break;
> +    case PVDRIVERS_EXPERIMENTAL_ID:
> +        product = PVDRIVERS_EXPERIMENTAL_NAME; 
> +        break;

We need to avoid this formulaic code which needs changing every time a
new entry is added.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 28 18:04:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Sep 2012 18: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 1THeuj-0002v4-BR; Fri, 28 Sep 2012 18:03:49 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ketuzsezr@gmail.com>) id 1THeuh-0002uz-QG
	for xen-devel@lists.xen.org; Fri, 28 Sep 2012 18:03:47 +0000
Received: from [85.158.143.99:43984] by server-3.bemta-4.messagelabs.com id
	52/39-10986-386E5605; Fri, 28 Sep 2012 18:03:47 +0000
X-Env-Sender: ketuzsezr@gmail.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1348855425!32210617!1
X-Originating-IP: [209.85.219.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27935 invoked from network); 28 Sep 2012 18:03:46 -0000
Received: from mail-oa0-f45.google.com (HELO mail-oa0-f45.google.com)
	(209.85.219.45)
	by server-9.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Sep 2012 18:03:46 -0000
Received: by oagi18 with SMTP id i18so4341414oag.32
	for <xen-devel@lists.xen.org>; Fri, 28 Sep 2012 11:03:44 -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=X5IO7hWnIlhdcmkBRe3DO/EDMvIiSblLocFbz+ZRnJo=;
	b=GSX6hASOJ2RBdw9g6tqq32i6R26NWua4Dn3R/FY+/MEyuZuupPJBTWgyGd9xlzlYoX
	J3gk7n8kYV/uRhBtYxSGY84iY72F6ltgj3XuIGWkKCqjMgnyVwlS27ZRWu7qiZBohb+6
	YFOH4PZzTNReVqBQYvPMe2e9w/hgbypMUhcTaVub+AzzXSx9zT3GXJ/zp9ZRnv2FzGqf
	dwVKjlv1g7P6MbJqHMMjFV39LqR9nXyD6pvEP1wXDaryIEqiAgRFI7SaHtc674FXmZDD
	mm2v2StV+e+KZaoxhCpOaePdOkueUPPeHFA/cM9wkBhZq4maR0H3+comGPvNmNO6GT8c
	MNBQ==
Received: by 10.60.172.201 with SMTP id be9mr6344589oec.141.1348855424792;
	Fri, 28 Sep 2012 11:03:44 -0700 (PDT)
Received: from localhost.localdomain ([72.95.90.214])
	by mx.google.com with ESMTPS id b5sm8937502obd.18.2012.09.28.11.03.43
	(version=TLSv1/SSLv3 cipher=OTHER);
	Fri, 28 Sep 2012 11:03:44 -0700 (PDT)
Date: Fri, 28 Sep 2012 14:22:27 -0400
From: Konrad Rzeszutek Wilk <konrad@kernel.org>
To: L D <lethalduck@gmail.com>
Message-ID: <20120928182226.GC17449@localhost.localdomain>
References: <CAPGwcLKjHOgwEGjDpQcymUjkv4eAzOVxN5mOKAtQ2UE3Bc4g9Q@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAPGwcLKjHOgwEGjDpQcymUjkv4eAzOVxN5mOKAtQ2UE3Bc4g9Q@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Xen 4.2 and USB
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Sep 27, 2012 at 10:51:21PM -0400, L D wrote:
> Hello!
> So I compiled and am running the 4.2 release...did the ./configure;
> make world; make install
> It works, and am running an ati vga passthrough windows system, except
> for usb and sound...
> 
> I have a couple of questions, if you can help me with some of these it
> would be appreciated.
> 
> How do I run qemu upstream in this release? I'm trying to have sound
> in win7 64bit sound but I can't get qemu upstream to work.
> Anybody have success with win7 sound?

Yes.  Look on the mailing list  - I mentioned what I needed to
do to enable PulseAudio on the host.

> I'm using device_model_override='/usr/lib/xen/bin/qemu-system-i386'

Why?
> 
> What happened to the command xm usb-add, there is no xl usb-add
> equivalent?? I need to do this for my usb keyboard and mouse.
> Also any particular reason we can specify a list of pci devices to
> passthru but not a list for usbdevices?? The config will only pass 1
> usbdevice, we should be able to pass a list of usbdevices no?

Could be that it never got implemented in 'xl'.
> As an alternative I tried to passthru the pci usb controllers but
> windows recognizes the controllers but for some reason does not
> recognize the usb keyboard/mouse as being attached.
> Finally how do I connect to the qemu console?? ctrl-alt-shift-2,1 just
> show me blank screens (console=1), I have no way to pass additional
> usb devices by usb-adding them.

Good. That is a security hole.
> 
> Thanks
> Paul
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Sep 28 18:04:03 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Sep 2012 18: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 1THeuj-0002v4-BR; Fri, 28 Sep 2012 18:03:49 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ketuzsezr@gmail.com>) id 1THeuh-0002uz-QG
	for xen-devel@lists.xen.org; Fri, 28 Sep 2012 18:03:47 +0000
Received: from [85.158.143.99:43984] by server-3.bemta-4.messagelabs.com id
	52/39-10986-386E5605; Fri, 28 Sep 2012 18:03:47 +0000
X-Env-Sender: ketuzsezr@gmail.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1348855425!32210617!1
X-Originating-IP: [209.85.219.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27935 invoked from network); 28 Sep 2012 18:03:46 -0000
Received: from mail-oa0-f45.google.com (HELO mail-oa0-f45.google.com)
	(209.85.219.45)
	by server-9.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Sep 2012 18:03:46 -0000
Received: by oagi18 with SMTP id i18so4341414oag.32
	for <xen-devel@lists.xen.org>; Fri, 28 Sep 2012 11:03:44 -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=X5IO7hWnIlhdcmkBRe3DO/EDMvIiSblLocFbz+ZRnJo=;
	b=GSX6hASOJ2RBdw9g6tqq32i6R26NWua4Dn3R/FY+/MEyuZuupPJBTWgyGd9xlzlYoX
	J3gk7n8kYV/uRhBtYxSGY84iY72F6ltgj3XuIGWkKCqjMgnyVwlS27ZRWu7qiZBohb+6
	YFOH4PZzTNReVqBQYvPMe2e9w/hgbypMUhcTaVub+AzzXSx9zT3GXJ/zp9ZRnv2FzGqf
	dwVKjlv1g7P6MbJqHMMjFV39LqR9nXyD6pvEP1wXDaryIEqiAgRFI7SaHtc674FXmZDD
	mm2v2StV+e+KZaoxhCpOaePdOkueUPPeHFA/cM9wkBhZq4maR0H3+comGPvNmNO6GT8c
	MNBQ==
Received: by 10.60.172.201 with SMTP id be9mr6344589oec.141.1348855424792;
	Fri, 28 Sep 2012 11:03:44 -0700 (PDT)
Received: from localhost.localdomain ([72.95.90.214])
	by mx.google.com with ESMTPS id b5sm8937502obd.18.2012.09.28.11.03.43
	(version=TLSv1/SSLv3 cipher=OTHER);
	Fri, 28 Sep 2012 11:03:44 -0700 (PDT)
Date: Fri, 28 Sep 2012 14:22:27 -0400
From: Konrad Rzeszutek Wilk <konrad@kernel.org>
To: L D <lethalduck@gmail.com>
Message-ID: <20120928182226.GC17449@localhost.localdomain>
References: <CAPGwcLKjHOgwEGjDpQcymUjkv4eAzOVxN5mOKAtQ2UE3Bc4g9Q@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAPGwcLKjHOgwEGjDpQcymUjkv4eAzOVxN5mOKAtQ2UE3Bc4g9Q@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Xen 4.2 and USB
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Thu, Sep 27, 2012 at 10:51:21PM -0400, L D wrote:
> Hello!
> So I compiled and am running the 4.2 release...did the ./configure;
> make world; make install
> It works, and am running an ati vga passthrough windows system, except
> for usb and sound...
> 
> I have a couple of questions, if you can help me with some of these it
> would be appreciated.
> 
> How do I run qemu upstream in this release? I'm trying to have sound
> in win7 64bit sound but I can't get qemu upstream to work.
> Anybody have success with win7 sound?

Yes.  Look on the mailing list  - I mentioned what I needed to
do to enable PulseAudio on the host.

> I'm using device_model_override='/usr/lib/xen/bin/qemu-system-i386'

Why?
> 
> What happened to the command xm usb-add, there is no xl usb-add
> equivalent?? I need to do this for my usb keyboard and mouse.
> Also any particular reason we can specify a list of pci devices to
> passthru but not a list for usbdevices?? The config will only pass 1
> usbdevice, we should be able to pass a list of usbdevices no?

Could be that it never got implemented in 'xl'.
> As an alternative I tried to passthru the pci usb controllers but
> windows recognizes the controllers but for some reason does not
> recognize the usb keyboard/mouse as being attached.
> Finally how do I connect to the qemu console?? ctrl-alt-shift-2,1 just
> show me blank screens (console=1), I have no way to pass additional
> usb devices by usb-adding them.

Good. That is a security hole.
> 
> Thanks
> Paul
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Sep 28 21:27:45 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Sep 2012 21:27: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 1THi5Z-0004IF-0q; Fri, 28 Sep 2012 21:27:13 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jeremy@goop.org>) id 1THi5Y-0004I7-9j
	for xen-devel@lists.xen.org; Fri, 28 Sep 2012 21:27:12 +0000
X-Env-Sender: jeremy@goop.org
X-Msg-Ref: server-10.tower-27.messagelabs.com!1348867624!7584604!1
X-Originating-IP: [74.207.240.146]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26612 invoked from network); 28 Sep 2012 21:27:05 -0000
Received: from claw.goop.org (HELO claw.goop.org) (74.207.240.146)
	by server-10.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 28 Sep 2012 21:27:05 -0000
Received: from saboo.goop.org (50-76-62-73-ip-static.hfc.comcastbusiness.net
	[50.76.62.73])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested) (Authenticated sender: smtp-saboo)
	by claw.goop.org (Postfix) with ESMTPSA id 964C39481;
	Fri, 28 Sep 2012 14:27:01 -0700 (PDT)
Received: from saboo.goop.org (localhost [IPv6:::1])
	by saboo.goop.org (Postfix) with ESMTP id 6EF2F20155;
	Fri, 28 Sep 2012 14:26:58 -0700 (PDT)
Message-ID: <50661622.5030302@goop.org>
Date: Fri, 28 Sep 2012 14:26:58 -0700
From: Jeremy Fitzhardinge <jeremy@goop.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120911 Thunderbird/15.0.1
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <7914B38A4445B34AA16EB9F1352942F1012F0F6F4B98@SJCPMAILBOX01.citrite.net>
	<CC681CDD.3D966%keir.xen@gmail.com>
	<40501859.20120902104331@eikelenboom.it>
	<5044849002000078000982EA@nat28.tlf.novell.com>
	<4610648186.20120904090841@eikelenboom.it>
	<5045CDF302000078000985FB@nat28.tlf.novell.com>
	<4710608674.20120904101330@eikelenboom.it>
	<505AEB2D020000780009C81F@nat28.tlf.novell.com>
In-Reply-To: <505AEB2D020000780009C81F@nat28.tlf.novell.com>
X-Enigmail-Version: 1.4.4
Cc: ehabkost@redhat.com, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	"wei.wang2@amd.com" <wei.wang2@amd.com>,
	Sander Eikelenboom <linux@eikelenboom.it>,
	Keir Fraser <keir.xen@gmail.com>, Santosh Jodh <Santosh.Jodh@citrix.com>
Subject: Re: [Xen-devel] Using debug-key 'o:  Dump IOMMU p2m table,
 locks up machine
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 09/20/2012 01:08 AM, Jan Beulich wrote:
> Ping?

I've been meaning to work up a reply, but I haven't had time to swap in
all the context again.

    J

>
>>>> On 04.09.12 at 11:26, Jan Beulich wrote:
>>>>> On 04.09.12 at 10:13, Sander Eikelenboom <linux@eikelenboom.it> wrote:
>>> Hmm don't know how to get the file/line, only thing i have found is:
>>>
>>> serveerstertje:/boot# gdb xen-syms-4.2.0-rc4-pre
>>> GNU gdb (GDB) 7.0.1-debian
>>> Copyright (C) 2009 Free Software Foundation, Inc.
>>> License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
>>> This is free software: you are free to change and redistribute it.
>>> There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
>>> and "show warranty" for details.
>>> This GDB was configured as "x86_64-linux-gnu".
>>> For bug reporting instructions, please see:
>>> <http://www.gnu.org/software/gdb/bugs/>...
>>> Reading symbols from /boot/xen-syms-4.2.0-rc4-pre...done.
>>> (gdb) x/i 0xffff82c48015c9ee
>>> 0xffff82c48015c9ee <context_switch+916>:        mov    %edx,%gs
>>> (gdb)
>> I'm not really a gdb expert, so I don't know off the top of my
>> head either. I thought I said in a previous reply that people
>> generally appear to use the addr2line utility for that purpose.
>>
>> But the disassembly already tells us where precisely the
>> problem is: The selector value (0x0063) attempted to be put
>> into %gs is apparently wrong in the context of the current
>> GDT. Now, that's GDT_ENTRY_TLS_MIN on the Linux side,
>> and ought to be valid. I'm surprised the guest (and the current
>> process in it) survives this (as the failure here results in a failsafe
>> callback into the guest).
>>
>> Looking at the Linux side of things, this has been that way
>> forever, and I think has always been broken: On x86-64, it
>> should also clear %gs here (since 32-bit processes use it for
>> their TLS, and there's nothing wrong for a 64-bit process to put
>> something in there either), albeit not via loadsegment(), but
>> through xen_load_gs_index(). And I neither see why on 32-bit
>> it only clears %gs - %fs can as much hold a selector that might
>> get invalidated with the TLS descriptor updates. Eduardo,
>> Jeremy, Konrad?
>>
>> Jan
>>
>
>


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Fri Sep 28 21:27:45 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 28 Sep 2012 21:27: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 1THi5Z-0004IF-0q; Fri, 28 Sep 2012 21:27:13 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jeremy@goop.org>) id 1THi5Y-0004I7-9j
	for xen-devel@lists.xen.org; Fri, 28 Sep 2012 21:27:12 +0000
X-Env-Sender: jeremy@goop.org
X-Msg-Ref: server-10.tower-27.messagelabs.com!1348867624!7584604!1
X-Originating-IP: [74.207.240.146]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26612 invoked from network); 28 Sep 2012 21:27:05 -0000
Received: from claw.goop.org (HELO claw.goop.org) (74.207.240.146)
	by server-10.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 28 Sep 2012 21:27:05 -0000
Received: from saboo.goop.org (50-76-62-73-ip-static.hfc.comcastbusiness.net
	[50.76.62.73])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested) (Authenticated sender: smtp-saboo)
	by claw.goop.org (Postfix) with ESMTPSA id 964C39481;
	Fri, 28 Sep 2012 14:27:01 -0700 (PDT)
Received: from saboo.goop.org (localhost [IPv6:::1])
	by saboo.goop.org (Postfix) with ESMTP id 6EF2F20155;
	Fri, 28 Sep 2012 14:26:58 -0700 (PDT)
Message-ID: <50661622.5030302@goop.org>
Date: Fri, 28 Sep 2012 14:26:58 -0700
From: Jeremy Fitzhardinge <jeremy@goop.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120911 Thunderbird/15.0.1
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <7914B38A4445B34AA16EB9F1352942F1012F0F6F4B98@SJCPMAILBOX01.citrite.net>
	<CC681CDD.3D966%keir.xen@gmail.com>
	<40501859.20120902104331@eikelenboom.it>
	<5044849002000078000982EA@nat28.tlf.novell.com>
	<4610648186.20120904090841@eikelenboom.it>
	<5045CDF302000078000985FB@nat28.tlf.novell.com>
	<4710608674.20120904101330@eikelenboom.it>
	<505AEB2D020000780009C81F@nat28.tlf.novell.com>
In-Reply-To: <505AEB2D020000780009C81F@nat28.tlf.novell.com>
X-Enigmail-Version: 1.4.4
Cc: ehabkost@redhat.com, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	"wei.wang2@amd.com" <wei.wang2@amd.com>,
	Sander Eikelenboom <linux@eikelenboom.it>,
	Keir Fraser <keir.xen@gmail.com>, Santosh Jodh <Santosh.Jodh@citrix.com>
Subject: Re: [Xen-devel] Using debug-key 'o:  Dump IOMMU p2m table,
 locks up machine
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 09/20/2012 01:08 AM, Jan Beulich wrote:
> Ping?

I've been meaning to work up a reply, but I haven't had time to swap in
all the context again.

    J

>
>>>> On 04.09.12 at 11:26, Jan Beulich wrote:
>>>>> On 04.09.12 at 10:13, Sander Eikelenboom <linux@eikelenboom.it> wrote:
>>> Hmm don't know how to get the file/line, only thing i have found is:
>>>
>>> serveerstertje:/boot# gdb xen-syms-4.2.0-rc4-pre
>>> GNU gdb (GDB) 7.0.1-debian
>>> Copyright (C) 2009 Free Software Foundation, Inc.
>>> License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
>>> This is free software: you are free to change and redistribute it.
>>> There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
>>> and "show warranty" for details.
>>> This GDB was configured as "x86_64-linux-gnu".
>>> For bug reporting instructions, please see:
>>> <http://www.gnu.org/software/gdb/bugs/>...
>>> Reading symbols from /boot/xen-syms-4.2.0-rc4-pre...done.
>>> (gdb) x/i 0xffff82c48015c9ee
>>> 0xffff82c48015c9ee <context_switch+916>:        mov    %edx,%gs
>>> (gdb)
>> I'm not really a gdb expert, so I don't know off the top of my
>> head either. I thought I said in a previous reply that people
>> generally appear to use the addr2line utility for that purpose.
>>
>> But the disassembly already tells us where precisely the
>> problem is: The selector value (0x0063) attempted to be put
>> into %gs is apparently wrong in the context of the current
>> GDT. Now, that's GDT_ENTRY_TLS_MIN on the Linux side,
>> and ought to be valid. I'm surprised the guest (and the current
>> process in it) survives this (as the failure here results in a failsafe
>> callback into the guest).
>>
>> Looking at the Linux side of things, this has been that way
>> forever, and I think has always been broken: On x86-64, it
>> should also clear %gs here (since 32-bit processes use it for
>> their TLS, and there's nothing wrong for a 64-bit process to put
>> something in there either), albeit not via loadsegment(), but
>> through xen_load_gs_index(). And I neither see why on 32-bit
>> it only clears %gs - %fs can as much hold a selector that might
>> get invalidated with the TLS descriptor updates. Eduardo,
>> Jeremy, Konrad?
>>
>> Jan
>>
>
>


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Sep 29 00:14:35 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 29 Sep 2012 00:14:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1THkgz-0005Yh-UV; Sat, 29 Sep 2012 00:14:01 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ar16@imapmail.org>) id 1THkgx-0005Yc-Fs
	for xen-devel@lists.xen.org; Sat, 29 Sep 2012 00:13:59 +0000
Received: from [85.158.143.99:22501] by server-2.bemta-4.messagelabs.com id
	3F/BB-06610-64D36605; Sat, 29 Sep 2012 00:13:58 +0000
X-Env-Sender: ar16@imapmail.org
X-Msg-Ref: server-14.tower-216.messagelabs.com!1348877637!22590222!1
X-Originating-IP: [66.111.4.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTExLjQuMjUgPT4gMjI3MTA=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4182 invoked from network); 29 Sep 2012 00:13:58 -0000
Received: from out1-smtp.messagingengine.com (HELO
	out1-smtp.messagingengine.com) (66.111.4.25)
	by server-14.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 29 Sep 2012 00:13:58 -0000
Received: from compute5.internal (compute5.nyi.mail.srv.osa [10.202.2.45])
	by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 2B2952012F
	for <xen-devel@lists.xen.org>; Fri, 28 Sep 2012 20:13:57 -0400 (EDT)
Received: from web1.nyi.mail.srv.osa ([10.202.2.211])
	by compute5.internal (MEProxy); Fri, 28 Sep 2012 20:13:57 -0400
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=imapmail.org; h=
	message-id:from:to:mime-version:content-transfer-encoding
	:content-type:subject:date; s=mesmtp; bh=Fi7c6KdZJOXZV0YBRyQWHAx
	I3wg=; b=hY5abHr6N4PhHbu4IzgmTO8tCzwutg76NoDng5h1oyRGBJDSGFsx4rb
	oRSDASqY8V5nA2+pQwMj7Vwlt3Re+KdiOnaUj8j+P1mKeIlXG24Gi03SxL03bW4p
	CzduAIJb3TIQfKEP/ihBOfs66rMbcMOIoXFESgmvvjQ6yvrewHis=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=
	messagingengine.com; h=message-id:from:to:mime-version
	:content-transfer-encoding:content-type:subject:date; s=smtpout;
	bh=Fi7c6KdZJOXZV0YBRyQWHAxI3wg=; b=j5ZezplIqKNWy2NtrmCutDJ4Lh3n
	+8qGb3jWfCoxCm0XpNmlcEJ+Tqr44pnS1alA+E925S4SzEAah1sAmZ6MHqdYsSgp
	Fl8S90dkTtwav5c0/ZS7QQ+jPrmDxgGsFZJXxHv8edAUsGXP/BzlsuArAqvFmVEl
	VAZni9iZrym7DiQ=
Received: by web1.nyi.mail.srv.osa (Postfix, from userid 99)
	id EB9AAA00348; Fri, 28 Sep 2012 20:13:56 -0400 (EDT)
Message-Id: <1348877636.5025.140661134113513.411BDE92@webmail.messagingengine.com>
X-Sasl-Enc: VwLm6WKhx7By7QTo8Eh6rT6/ug8I1AmY0tIS4nP7idkD 1348877636
From: ar16@imapmail.org
To: xen-devel@lists.xen.org
MIME-Version: 1.0
X-Mailer: MessagingEngine.com Webmail Interface
Date: Fri, 28 Sep 2012 17:13:56 -0700
Subject: [Xen-devel] Xen HVM Guest fails (errors) to launch on Opensuse
 12.2's Xen 4.2 + 'xl' toolstack
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Migrating from a stable/production install of Opensuse 12.1 + Xen
4.{1,2} + 'xm' toolstack to Opensuse 12.2 + Xen 4.2 + xl toolstack +
Opensuse 12.2 has been problematic.

To simplify troubleshooting, I'm  attempting to init a new/clean 12.2
Guest

The procedure is to init an HVM Guest, boot to a physically-attached
Opensuse 12.2 Install DVD, and install a new/clean 12.2 Guest.

Atm, the guest is failing to launch, with a series of errors:

	...
	libxl: error: libxl_create.c:901:domcreate_rebuild_done: cannot
	(re-)build domain: -3
	libxl: error: libxl_dm.c:1251:libxl__destroy_device_model: could
	not find device-model's pid for dom 6
	libxl: error: libxl.c:1429:libxl__destroy_domid:
	libxl__destroy_device_model failed for 6
	...

 @wiki (http://wiki.xen.org/wiki/Xen_4.2_Release_Notes) we're advised:

	"... it is strongly recommended that users evaluate Xen 4.2 with
	XL for their use cases and report any omissions or blockers
	...".

I was advised @ #xen to 'report' this to this list, rather than to our
distro (already done anyway @ 
https://bugzilla.novell.com/show_bug.cgi?id=782835).

System info,

	lsb_release -a
		LSB Version:    n/a
		Distributor ID: SUSE LINUX
		Description:    openSUSE 12.2 (x86_64)
		Release:        12.2
		Codename:       Mantis

	uname -a
		Linux test 3.4.6-2.10-xen #1 SMP Thu Jul 26 09:36:26 UTC
		2012 (641c197) x86_64 x86_64 x86_64 GNU/Linux

pkg info,

	rpm -qa | grep -i xen
		ipset-kmp-xen-6.12_k3.4.6_2.10-2.3.1.x86_64
		kernel-xen-3.4.6-2.10.1.x86_64
		kernel-xen-devel-3.4.6-2.10.1.x86_64
		patterns-openSUSE-xen_server-12.2-5.5.1.x86_64
		xen-4.2.0_01-204.1.x86_64
		xen-devel-4.2.0_01-204.1.x86_64
		xen-doc-html-4.2.0_01-204.1.x86_64
		xen-doc-pdf-4.2.0_01-204.1.x86_64
		xen-kmp-default-4.2.0_01_k3.4.6_2.10-204.1.x86_64
		xen-libs-4.2.0_01-204.1.x86_64
		xen-tools-4.2.0_01-204.1.x86_64

Xen/xl info,

	xl info
		host                   : test
		release                : 3.4.6-2.10-xen
		version                : #1 SMP Thu Jul 26 09:36:26 UTC
		2012 (641c197)
		machine                : x86_64
		nr_cpus                : 4
		max_cpu_id             : 5
		nr_nodes               : 1
		cores_per_socket       : 4
		threads_per_core       : 1
		cpu_mhz                : 2806
		hw_caps                :
		178bf3ff:efd3fbff:00000000:00001310:00802001:00000000:000037ff:00000000
		virt_caps              : hvm
		total_memory           : 7935
		free_memory            : 6844
		sharing_freed_memory   : 0
		sharing_used_memory    : 0
		free_cpus              : 0
		xen_major              : 4
		xen_minor              : 2
		xen_extra              : .0_01-204.1
		xen_caps               : xen-3.0-x86_64 xen-3.0-x86_32p
		hvm-3.0-x86_32 hvm-3.0-x86_32p hvm-3.0-x86_64
		xen_scheduler          : credit
		xen_pagesize           : 4096
		platform_params        : virt_start=0xffff800000000000
		xen_changeset          : 25844
		xen_commandline        : conring_size=64
		vga=gfx-1280x1024x16 log_buf_len=4M console=vga
		console_timestamps dom0_mem=1024M dom0_vcpus_pin=true
		dom0_max_vcpus=4 sched=credit apic_verbosity=verbose
		iommu=verbose cpuidle=1 cpufreq=xen clocksource=acpi
		numa=on
		cc_compiler            : gcc (SUSE Linux) 4.7.1 20120723
		[gcc-4_7-branch revision 189773
		cc_compile_by          : abuild
		cc_compile_domain      :
		cc_compile_date        : Fri Sep 28 15:30:52 UTC 2012
		xend_config_format     : 4

Verifying HVM availability,

	xl dmesg | grep -i hvm
		(XEN) [2012-09-28 22:53:56] HVM: ASIDs enabled.
		(XEN) [2012-09-28 22:53:56] HVM: SVM enabled
		(XEN) [2012-09-28 22:53:56] HVM: Hardware Assisted
		Paging (HAP) detected
		(XEN) [2012-09-28 22:53:56] HVM: HAP page sizes: 4kB,
		2MB, 1GB

The config I'm using,

	cat test.cfg
		name = 'test'
		builder = 'hvm'
		acpi = 1
		apic = 1
		boot = 'f'
		disk = [ 'phy:/dev/VG0/boot,xvda,w',
		'phy:/dev/VG0/swap,xvdb,w', 'phy:/dev/VG0/root,xvdc,w',
		'phy:/dev/cdrom,xvdd:cdrom,r',]
		vif          = [ 'mac=00:16:3E:55:00:01, model=rtl8139,
		type=ioemu, bridge=br0, vifname=vifO',]
		vfb          = [ 'type=vnc, vncdisplay=1,
		vnclisten=127.0.0.1' ]
		maxmem       = 1024
		vcpus        = 4
		localtime    = 0
		netif        = 'yes'
		on_shutdown  = 'destroy'
		on_reboot    = 'destroy'
		on_crash     = 'destroy'

The failing launch cmd,

	xl -vvv create -c /home/ar/test.cfg
		Parsing config from /home/ar/test.cfg
		libxl: debug: libxl_create.c:1173:do_domain_create: ao
		0x7e1c80: create: how=(nil) callback=(nil)
		poller=0x7e1ce0
		libxl: debug:
		libxl_device.c:229:libxl__device_disk_set_backend: Disk
		vdev=xvda spec.backend=unknown
		libxl: debug:
		libxl_device.c:265:libxl__device_disk_set_backend: Disk
		vdev=xvda, using backend phy
		libxl: debug:
		libxl_device.c:229:libxl__device_disk_set_backend: Disk
		vdev=xvdb spec.backend=unknown
		libxl: debug:
		libxl_device.c:265:libxl__device_disk_set_backend: Disk
		vdev=xvdb, using backend phy
		libxl: debug:
		libxl_device.c:229:libxl__device_disk_set_backend: Disk
		vdev=xvdc spec.backend=unknown
		libxl: debug:
		libxl_device.c:265:libxl__device_disk_set_backend: Disk
		vdev=xvdc, using backend phy
		libxl: debug:
		libxl_device.c:229:libxl__device_disk_set_backend: Disk
		vdev=xvdd spec.backend=unknown
		libxl: debug:
		libxl_device.c:265:libxl__device_disk_set_backend: Disk
		vdev=xvdd, using backend phy
		libxl: debug: libxl_create.c:677:initiate_domain_create:
		running bootloader
		libxl: debug:
		libxl_bootloader.c:321:libxl__bootloader_run: not a PV
		domain, skipping bootloader
		libxl: debug:
		libxl_event.c:561:libxl__ev_xswatch_deregister: watch
		w=0x7e2690: deregister unregistered
		libxl: debug:
		libxl_numa.c:435:libxl__get_numa_candidate: New best
		NUMA placement candidate found: nr_nodes=1, nr_cpus=4,
		nr_vcpus=8, free_memkb=6842
		libxl: detail: libxl_dom.c:192:numa_place_domain: NUMA
		placement candidate with 1 nodes, 4 cpus and 6842 KB
		free selected
		xc: detail: elf_parse_binary: phdr: paddr=0x100000
		memsz=0x9e028
		xc: detail: elf_parse_binary: memory: 0x100000 ->
		0x19e028
		xc: info: VIRTUAL MEMORY ARRANGEMENT:
		  Loader:        0000000000100000->000000000019e028
		  TOTAL:         0000000000000000->000000007f800000
		  ENTRY ADDRESS: 0000000000100000
		xc: info: PHYSICAL MEMORY ALLOCATION:
		  4KB PAGES: 0x0000000000000200
		  2MB PAGES: 0x00000000000003fb
		  1GB PAGES: 0x0000000000000000
		xc: detail: elf_load_binary: phdr 0 at 0x0x7f8d58910000
		-> 0x0x7f8d589a4eb5
		libxl: error: libxl_create.c:901:domcreate_rebuild_done:
		cannot (re-)build domain: -3
		libxl: error:
		libxl_dm.c:1251:libxl__destroy_device_model: could not
		find device-model's pid for dom 6
		libxl: error: libxl.c:1429:libxl__destroy_domid:
		libxl__destroy_device_model failed for 6
		libxl: debug: libxl_event.c:1497:libxl__ao_complete: ao
		0x7e1c80: complete, rc=-3
		libxl: debug: libxl_create.c:1186:do_domain_create: ao
		0x7e1c80: inprogress: poller=0x7e1ce0, flags=ic
		libxl: debug: libxl_event.c:1469:libxl__ao__destroy: ao
		0x7e1c80: destroy
		xc: debug: hypercall buffer: total allocations:871 total
		releases:871
		xc: debug: hypercall buffer: current allocations:0
		maximum allocations:4
		xc: debug: hypercall buffer: cache current size:4
		xc: debug: hypercall buffer: cache hits:863 misses:4
		toobig:4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Sep 29 00:14:35 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 29 Sep 2012 00:14:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1THkgz-0005Yh-UV; Sat, 29 Sep 2012 00:14:01 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ar16@imapmail.org>) id 1THkgx-0005Yc-Fs
	for xen-devel@lists.xen.org; Sat, 29 Sep 2012 00:13:59 +0000
Received: from [85.158.143.99:22501] by server-2.bemta-4.messagelabs.com id
	3F/BB-06610-64D36605; Sat, 29 Sep 2012 00:13:58 +0000
X-Env-Sender: ar16@imapmail.org
X-Msg-Ref: server-14.tower-216.messagelabs.com!1348877637!22590222!1
X-Originating-IP: [66.111.4.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTExLjQuMjUgPT4gMjI3MTA=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4182 invoked from network); 29 Sep 2012 00:13:58 -0000
Received: from out1-smtp.messagingengine.com (HELO
	out1-smtp.messagingengine.com) (66.111.4.25)
	by server-14.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 29 Sep 2012 00:13:58 -0000
Received: from compute5.internal (compute5.nyi.mail.srv.osa [10.202.2.45])
	by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 2B2952012F
	for <xen-devel@lists.xen.org>; Fri, 28 Sep 2012 20:13:57 -0400 (EDT)
Received: from web1.nyi.mail.srv.osa ([10.202.2.211])
	by compute5.internal (MEProxy); Fri, 28 Sep 2012 20:13:57 -0400
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=imapmail.org; h=
	message-id:from:to:mime-version:content-transfer-encoding
	:content-type:subject:date; s=mesmtp; bh=Fi7c6KdZJOXZV0YBRyQWHAx
	I3wg=; b=hY5abHr6N4PhHbu4IzgmTO8tCzwutg76NoDng5h1oyRGBJDSGFsx4rb
	oRSDASqY8V5nA2+pQwMj7Vwlt3Re+KdiOnaUj8j+P1mKeIlXG24Gi03SxL03bW4p
	CzduAIJb3TIQfKEP/ihBOfs66rMbcMOIoXFESgmvvjQ6yvrewHis=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=
	messagingengine.com; h=message-id:from:to:mime-version
	:content-transfer-encoding:content-type:subject:date; s=smtpout;
	bh=Fi7c6KdZJOXZV0YBRyQWHAxI3wg=; b=j5ZezplIqKNWy2NtrmCutDJ4Lh3n
	+8qGb3jWfCoxCm0XpNmlcEJ+Tqr44pnS1alA+E925S4SzEAah1sAmZ6MHqdYsSgp
	Fl8S90dkTtwav5c0/ZS7QQ+jPrmDxgGsFZJXxHv8edAUsGXP/BzlsuArAqvFmVEl
	VAZni9iZrym7DiQ=
Received: by web1.nyi.mail.srv.osa (Postfix, from userid 99)
	id EB9AAA00348; Fri, 28 Sep 2012 20:13:56 -0400 (EDT)
Message-Id: <1348877636.5025.140661134113513.411BDE92@webmail.messagingengine.com>
X-Sasl-Enc: VwLm6WKhx7By7QTo8Eh6rT6/ug8I1AmY0tIS4nP7idkD 1348877636
From: ar16@imapmail.org
To: xen-devel@lists.xen.org
MIME-Version: 1.0
X-Mailer: MessagingEngine.com Webmail Interface
Date: Fri, 28 Sep 2012 17:13:56 -0700
Subject: [Xen-devel] Xen HVM Guest fails (errors) to launch on Opensuse
 12.2's Xen 4.2 + 'xl' toolstack
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Migrating from a stable/production install of Opensuse 12.1 + Xen
4.{1,2} + 'xm' toolstack to Opensuse 12.2 + Xen 4.2 + xl toolstack +
Opensuse 12.2 has been problematic.

To simplify troubleshooting, I'm  attempting to init a new/clean 12.2
Guest

The procedure is to init an HVM Guest, boot to a physically-attached
Opensuse 12.2 Install DVD, and install a new/clean 12.2 Guest.

Atm, the guest is failing to launch, with a series of errors:

	...
	libxl: error: libxl_create.c:901:domcreate_rebuild_done: cannot
	(re-)build domain: -3
	libxl: error: libxl_dm.c:1251:libxl__destroy_device_model: could
	not find device-model's pid for dom 6
	libxl: error: libxl.c:1429:libxl__destroy_domid:
	libxl__destroy_device_model failed for 6
	...

 @wiki (http://wiki.xen.org/wiki/Xen_4.2_Release_Notes) we're advised:

	"... it is strongly recommended that users evaluate Xen 4.2 with
	XL for their use cases and report any omissions or blockers
	...".

I was advised @ #xen to 'report' this to this list, rather than to our
distro (already done anyway @ 
https://bugzilla.novell.com/show_bug.cgi?id=782835).

System info,

	lsb_release -a
		LSB Version:    n/a
		Distributor ID: SUSE LINUX
		Description:    openSUSE 12.2 (x86_64)
		Release:        12.2
		Codename:       Mantis

	uname -a
		Linux test 3.4.6-2.10-xen #1 SMP Thu Jul 26 09:36:26 UTC
		2012 (641c197) x86_64 x86_64 x86_64 GNU/Linux

pkg info,

	rpm -qa | grep -i xen
		ipset-kmp-xen-6.12_k3.4.6_2.10-2.3.1.x86_64
		kernel-xen-3.4.6-2.10.1.x86_64
		kernel-xen-devel-3.4.6-2.10.1.x86_64
		patterns-openSUSE-xen_server-12.2-5.5.1.x86_64
		xen-4.2.0_01-204.1.x86_64
		xen-devel-4.2.0_01-204.1.x86_64
		xen-doc-html-4.2.0_01-204.1.x86_64
		xen-doc-pdf-4.2.0_01-204.1.x86_64
		xen-kmp-default-4.2.0_01_k3.4.6_2.10-204.1.x86_64
		xen-libs-4.2.0_01-204.1.x86_64
		xen-tools-4.2.0_01-204.1.x86_64

Xen/xl info,

	xl info
		host                   : test
		release                : 3.4.6-2.10-xen
		version                : #1 SMP Thu Jul 26 09:36:26 UTC
		2012 (641c197)
		machine                : x86_64
		nr_cpus                : 4
		max_cpu_id             : 5
		nr_nodes               : 1
		cores_per_socket       : 4
		threads_per_core       : 1
		cpu_mhz                : 2806
		hw_caps                :
		178bf3ff:efd3fbff:00000000:00001310:00802001:00000000:000037ff:00000000
		virt_caps              : hvm
		total_memory           : 7935
		free_memory            : 6844
		sharing_freed_memory   : 0
		sharing_used_memory    : 0
		free_cpus              : 0
		xen_major              : 4
		xen_minor              : 2
		xen_extra              : .0_01-204.1
		xen_caps               : xen-3.0-x86_64 xen-3.0-x86_32p
		hvm-3.0-x86_32 hvm-3.0-x86_32p hvm-3.0-x86_64
		xen_scheduler          : credit
		xen_pagesize           : 4096
		platform_params        : virt_start=0xffff800000000000
		xen_changeset          : 25844
		xen_commandline        : conring_size=64
		vga=gfx-1280x1024x16 log_buf_len=4M console=vga
		console_timestamps dom0_mem=1024M dom0_vcpus_pin=true
		dom0_max_vcpus=4 sched=credit apic_verbosity=verbose
		iommu=verbose cpuidle=1 cpufreq=xen clocksource=acpi
		numa=on
		cc_compiler            : gcc (SUSE Linux) 4.7.1 20120723
		[gcc-4_7-branch revision 189773
		cc_compile_by          : abuild
		cc_compile_domain      :
		cc_compile_date        : Fri Sep 28 15:30:52 UTC 2012
		xend_config_format     : 4

Verifying HVM availability,

	xl dmesg | grep -i hvm
		(XEN) [2012-09-28 22:53:56] HVM: ASIDs enabled.
		(XEN) [2012-09-28 22:53:56] HVM: SVM enabled
		(XEN) [2012-09-28 22:53:56] HVM: Hardware Assisted
		Paging (HAP) detected
		(XEN) [2012-09-28 22:53:56] HVM: HAP page sizes: 4kB,
		2MB, 1GB

The config I'm using,

	cat test.cfg
		name = 'test'
		builder = 'hvm'
		acpi = 1
		apic = 1
		boot = 'f'
		disk = [ 'phy:/dev/VG0/boot,xvda,w',
		'phy:/dev/VG0/swap,xvdb,w', 'phy:/dev/VG0/root,xvdc,w',
		'phy:/dev/cdrom,xvdd:cdrom,r',]
		vif          = [ 'mac=00:16:3E:55:00:01, model=rtl8139,
		type=ioemu, bridge=br0, vifname=vifO',]
		vfb          = [ 'type=vnc, vncdisplay=1,
		vnclisten=127.0.0.1' ]
		maxmem       = 1024
		vcpus        = 4
		localtime    = 0
		netif        = 'yes'
		on_shutdown  = 'destroy'
		on_reboot    = 'destroy'
		on_crash     = 'destroy'

The failing launch cmd,

	xl -vvv create -c /home/ar/test.cfg
		Parsing config from /home/ar/test.cfg
		libxl: debug: libxl_create.c:1173:do_domain_create: ao
		0x7e1c80: create: how=(nil) callback=(nil)
		poller=0x7e1ce0
		libxl: debug:
		libxl_device.c:229:libxl__device_disk_set_backend: Disk
		vdev=xvda spec.backend=unknown
		libxl: debug:
		libxl_device.c:265:libxl__device_disk_set_backend: Disk
		vdev=xvda, using backend phy
		libxl: debug:
		libxl_device.c:229:libxl__device_disk_set_backend: Disk
		vdev=xvdb spec.backend=unknown
		libxl: debug:
		libxl_device.c:265:libxl__device_disk_set_backend: Disk
		vdev=xvdb, using backend phy
		libxl: debug:
		libxl_device.c:229:libxl__device_disk_set_backend: Disk
		vdev=xvdc spec.backend=unknown
		libxl: debug:
		libxl_device.c:265:libxl__device_disk_set_backend: Disk
		vdev=xvdc, using backend phy
		libxl: debug:
		libxl_device.c:229:libxl__device_disk_set_backend: Disk
		vdev=xvdd spec.backend=unknown
		libxl: debug:
		libxl_device.c:265:libxl__device_disk_set_backend: Disk
		vdev=xvdd, using backend phy
		libxl: debug: libxl_create.c:677:initiate_domain_create:
		running bootloader
		libxl: debug:
		libxl_bootloader.c:321:libxl__bootloader_run: not a PV
		domain, skipping bootloader
		libxl: debug:
		libxl_event.c:561:libxl__ev_xswatch_deregister: watch
		w=0x7e2690: deregister unregistered
		libxl: debug:
		libxl_numa.c:435:libxl__get_numa_candidate: New best
		NUMA placement candidate found: nr_nodes=1, nr_cpus=4,
		nr_vcpus=8, free_memkb=6842
		libxl: detail: libxl_dom.c:192:numa_place_domain: NUMA
		placement candidate with 1 nodes, 4 cpus and 6842 KB
		free selected
		xc: detail: elf_parse_binary: phdr: paddr=0x100000
		memsz=0x9e028
		xc: detail: elf_parse_binary: memory: 0x100000 ->
		0x19e028
		xc: info: VIRTUAL MEMORY ARRANGEMENT:
		  Loader:        0000000000100000->000000000019e028
		  TOTAL:         0000000000000000->000000007f800000
		  ENTRY ADDRESS: 0000000000100000
		xc: info: PHYSICAL MEMORY ALLOCATION:
		  4KB PAGES: 0x0000000000000200
		  2MB PAGES: 0x00000000000003fb
		  1GB PAGES: 0x0000000000000000
		xc: detail: elf_load_binary: phdr 0 at 0x0x7f8d58910000
		-> 0x0x7f8d589a4eb5
		libxl: error: libxl_create.c:901:domcreate_rebuild_done:
		cannot (re-)build domain: -3
		libxl: error:
		libxl_dm.c:1251:libxl__destroy_device_model: could not
		find device-model's pid for dom 6
		libxl: error: libxl.c:1429:libxl__destroy_domid:
		libxl__destroy_device_model failed for 6
		libxl: debug: libxl_event.c:1497:libxl__ao_complete: ao
		0x7e1c80: complete, rc=-3
		libxl: debug: libxl_create.c:1186:do_domain_create: ao
		0x7e1c80: inprogress: poller=0x7e1ce0, flags=ic
		libxl: debug: libxl_event.c:1469:libxl__ao__destroy: ao
		0x7e1c80: destroy
		xc: debug: hypercall buffer: total allocations:871 total
		releases:871
		xc: debug: hypercall buffer: current allocations:0
		maximum allocations:4
		xc: debug: hypercall buffer: cache current size:4
		xc: debug: hypercall buffer: cache hits:863 misses:4
		toobig:4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Sep 29 01:35:07 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 29 Sep 2012 01:35:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1THlwx-0001Ic-E3; Sat, 29 Sep 2012 01:34:35 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ar16@imapmail.org>) id 1THlww-0001IX-Cn
	for xen-devel@lists.xen.org; Sat, 29 Sep 2012 01:34:34 +0000
Received: from [85.158.143.99:5360] by server-1.bemta-4.messagelabs.com id
	8A/36-05684-92056605; Sat, 29 Sep 2012 01:34:33 +0000
X-Env-Sender: ar16@imapmail.org
X-Msg-Ref: server-5.tower-216.messagelabs.com!1348882472!31867196!1
X-Originating-IP: [66.111.4.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTExLjQuMjUgPT4gMjM4NjE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19919 invoked from network); 29 Sep 2012 01:34:33 -0000
Received: from out1-smtp.messagingengine.com (HELO
	out1-smtp.messagingengine.com) (66.111.4.25)
	by server-5.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 29 Sep 2012 01:34:33 -0000
Received: from compute4.internal (compute4.nyi.mail.srv.osa [10.202.2.44])
	by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 54AE7207C1
	for <xen-devel@lists.xen.org>; Fri, 28 Sep 2012 21:34:32 -0400 (EDT)
Received: from web1.nyi.mail.srv.osa ([10.202.2.211])
	by compute4.internal (MEProxy); Fri, 28 Sep 2012 21:34:32 -0400
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=imapmail.org; h=
	message-id:from:to:mime-version:content-transfer-encoding
	:content-type:in-reply-to:references:subject:date; s=mesmtp; bh=
	GLZewGvCqW14ynoME6SSP6ke7ns=; b=AuIxelSjE6PfvrDfIrs/sVAY+gSWxFmn
	XeSNHpYk8s6j18a5E+iRQ63noNiyAFxbYQypZdxgLp5F4wehc18xLd+axzkcuc1k
	9t7kGTuWRPO44PfmpTuZqTYUdXJWH5aNMJXSSblaxcpaHrUGG1w7diPkglyWZ5+J
	4rB6TTLkhQs=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=
	messagingengine.com; h=message-id:from:to:mime-version
	:content-transfer-encoding:content-type:in-reply-to:references
	:subject:date; s=smtpout; bh=GLZewGvCqW14ynoME6SSP6ke7ns=; b=qS0
	Dxl588gsaA6aeQHD6lOf0TrB8omOxcXdhKuilO/P7ZktHqv0VxmCW8duV5kKrPms
	ulDj6GMAfST9cNBpXahm8qlfnX/MZKK+T2CNjO/xZGocvbkNPIT7v2r+7zwBw9/S
	jg8UXBzLOeRMHsOp4yr9qchx3hGRmab6JGQuUOgk=
Received: by web1.nyi.mail.srv.osa (Postfix, from userid 99)
	id 235D9A00348; Fri, 28 Sep 2012 21:34:32 -0400 (EDT)
Message-Id: <1348882472.17803.140661134131069.4B02D98D@webmail.messagingengine.com>
X-Sasl-Enc: VhMaEEfk5qZLSEdQ8iAXntXpoasA5ZrlpBUKnU/w9hwq 1348882472
From: ar16@imapmail.org
To: xen-devel@lists.xen.org
MIME-Version: 1.0
X-Mailer: MessagingEngine.com Webmail Interface
In-Reply-To: <1348877636.5025.140661134113513.411BDE92@webmail.messagingengine.com>
References: <1348877636.5025.140661134113513.411BDE92@webmail.messagingengine.com>
Date: Fri, 28 Sep 2012 18:34:32 -0700
Subject: Re: [Xen-devel] Xen HVM Guest fails (errors) to launch on Opensuse
 12.2's Xen 4.2 + 'xl' toolstack
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Using exactly the same setup and configuration, but changing toolstack
from xl -> xm, i.e.

service xend start
xm create -c test.cfg

The Guest launches, and is accessible via VNC  (very slow response;
liklely a different issue)


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Sep 29 01:35:07 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 29 Sep 2012 01:35:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1THlwx-0001Ic-E3; Sat, 29 Sep 2012 01:34:35 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ar16@imapmail.org>) id 1THlww-0001IX-Cn
	for xen-devel@lists.xen.org; Sat, 29 Sep 2012 01:34:34 +0000
Received: from [85.158.143.99:5360] by server-1.bemta-4.messagelabs.com id
	8A/36-05684-92056605; Sat, 29 Sep 2012 01:34:33 +0000
X-Env-Sender: ar16@imapmail.org
X-Msg-Ref: server-5.tower-216.messagelabs.com!1348882472!31867196!1
X-Originating-IP: [66.111.4.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTExLjQuMjUgPT4gMjM4NjE=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19919 invoked from network); 29 Sep 2012 01:34:33 -0000
Received: from out1-smtp.messagingengine.com (HELO
	out1-smtp.messagingengine.com) (66.111.4.25)
	by server-5.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 29 Sep 2012 01:34:33 -0000
Received: from compute4.internal (compute4.nyi.mail.srv.osa [10.202.2.44])
	by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 54AE7207C1
	for <xen-devel@lists.xen.org>; Fri, 28 Sep 2012 21:34:32 -0400 (EDT)
Received: from web1.nyi.mail.srv.osa ([10.202.2.211])
	by compute4.internal (MEProxy); Fri, 28 Sep 2012 21:34:32 -0400
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=imapmail.org; h=
	message-id:from:to:mime-version:content-transfer-encoding
	:content-type:in-reply-to:references:subject:date; s=mesmtp; bh=
	GLZewGvCqW14ynoME6SSP6ke7ns=; b=AuIxelSjE6PfvrDfIrs/sVAY+gSWxFmn
	XeSNHpYk8s6j18a5E+iRQ63noNiyAFxbYQypZdxgLp5F4wehc18xLd+axzkcuc1k
	9t7kGTuWRPO44PfmpTuZqTYUdXJWH5aNMJXSSblaxcpaHrUGG1w7diPkglyWZ5+J
	4rB6TTLkhQs=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=
	messagingengine.com; h=message-id:from:to:mime-version
	:content-transfer-encoding:content-type:in-reply-to:references
	:subject:date; s=smtpout; bh=GLZewGvCqW14ynoME6SSP6ke7ns=; b=qS0
	Dxl588gsaA6aeQHD6lOf0TrB8omOxcXdhKuilO/P7ZktHqv0VxmCW8duV5kKrPms
	ulDj6GMAfST9cNBpXahm8qlfnX/MZKK+T2CNjO/xZGocvbkNPIT7v2r+7zwBw9/S
	jg8UXBzLOeRMHsOp4yr9qchx3hGRmab6JGQuUOgk=
Received: by web1.nyi.mail.srv.osa (Postfix, from userid 99)
	id 235D9A00348; Fri, 28 Sep 2012 21:34:32 -0400 (EDT)
Message-Id: <1348882472.17803.140661134131069.4B02D98D@webmail.messagingengine.com>
X-Sasl-Enc: VhMaEEfk5qZLSEdQ8iAXntXpoasA5ZrlpBUKnU/w9hwq 1348882472
From: ar16@imapmail.org
To: xen-devel@lists.xen.org
MIME-Version: 1.0
X-Mailer: MessagingEngine.com Webmail Interface
In-Reply-To: <1348877636.5025.140661134113513.411BDE92@webmail.messagingengine.com>
References: <1348877636.5025.140661134113513.411BDE92@webmail.messagingengine.com>
Date: Fri, 28 Sep 2012 18:34:32 -0700
Subject: Re: [Xen-devel] Xen HVM Guest fails (errors) to launch on Opensuse
 12.2's Xen 4.2 + 'xl' toolstack
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

Using exactly the same setup and configuration, but changing toolstack
from xl -> xm, i.e.

service xend start
xm create -c test.cfg

The Guest launches, and is accessible via VNC  (very slow response;
liklely a different issue)


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Sep 29 03:08:02 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 29 Sep 2012 03: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 1THnOx-0002ey-6I; Sat, 29 Sep 2012 03:07:35 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <aware.why@gmail.com>) id 1THnOv-0002et-2p
	for xen-devel@lists.xensource.com; Sat, 29 Sep 2012 03:07:33 +0000
Received: from [85.158.143.35:60045] by server-1.bemta-4.messagelabs.com id
	2F/BB-05684-4F566605; Sat, 29 Sep 2012 03:07:32 +0000
X-Env-Sender: aware.why@gmail.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1348888051!5890413!1
X-Originating-IP: [209.85.215.171]
X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12994 invoked from network); 29 Sep 2012 03:07:31 -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;
	29 Sep 2012 03:07:31 -0000
Received: by eaak14 with SMTP id k14so766716eaa.30
	for <xen-devel@lists.xensource.com>;
	Fri, 28 Sep 2012 20:07:30 -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=9zrWEm17yOYoVwdaNYU7+o/aWZokhfqWxKtB8XNWeNU=;
	b=XLBk4Icjv9fhCGs1Kj2nWwTb9X/BQfYGzPl6jqv+MZdsubfGzN/4W0o260juvSa3dS
	ojw5neNZZX+ZhWcbq2Pm7dAahdAAU1gHkA0I7y5madJgHGRgCg5oN6bQ8AWyAUw+uihb
	V7HD84e3jV3R6L0hAlNdVHZdBXaar3YmQRNeNZu7/YGJFHQ6rjw3MyFsEovw509zgbkN
	oCiRA/WwC7lUb+885tdJ/bCJZxO/llRrVPN9/DfID6DAashkbSVpF9a3my+OVXFFI7pK
	pSqA6/AyHwl7NSW0JkmhDWoT5Vr5RMAx1xsRCvoupBSTjKyysbWCW4jetkY/3bLKGRxK
	hpng==
MIME-Version: 1.0
Received: by 10.14.215.69 with SMTP id d45mr11987949eep.16.1348888050846; Fri,
	28 Sep 2012 20:07:30 -0700 (PDT)
Received: by 10.14.100.71 with HTTP; Fri, 28 Sep 2012 20:07:30 -0700 (PDT)
Date: Sat, 29 Sep 2012 11:07:30 +0800
Message-ID: <CA+ePHTB+_EjGgCZnbUK_cj1bT9D=ch79L04P9y5nh5dM=fvC0g@mail.gmail.com>
From: =?UTF-8?B?6ams56OK?= <aware.why@gmail.com>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] =?utf-8?b?44CQY29uZnVzZWTjgJF3aGF0IGRvZXMgeGNfbWFw?=
	=?utf-8?b?X2ZvcmVpZ25fYmF0Y2ggZG/vvJ8=?=
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1536625240398167016=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============1536625240398167016==
Content-Type: multipart/alternative; boundary=047d7b621f541cca0804cace794c

--047d7b621f541cca0804cace794c
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi=EF=BC=8C all
 In tools/libxc/xc_domain_save .c, one function called
 `map_and_save_p2m_table` where there exists a confusing problem, as is
shown below:

 621    live_p2m_frame_list =3D



 622        xc_map_foreign_batch(xc_handle, dom, PROT_READ,



 623                             p2m_frame_list_list,



 624                             P2M_FLL_ENTRIES);

memcpy(p2m_frame_list, live_p2m_frame_list, P2M_GUEST_FL_SIZE);

 654    p2m =3D xc_map_foreign_batch(xc_handle, dom, PROT_READ,



 655                               p2m_frame_list,



 656                               P2M_FL_ENTRIES);


maybe someone encountered the same problem, would you help me?

Besides, what's the difference between IOCTL_PRIVCMD_MMAP
and IOCTL_PRIVCMD_MMAPBATCH?


Thanks
bruce

--047d7b621f541cca0804cace794c
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: base64

SGnvvIwgYWxsPGRpdj7CoEluIHRvb2xzL2xpYnhjL3hjX2RvbWFpbl9zYXZlIC5jLCBvbmUgZnVu
Y3Rpb24gY2FsbGVkIMKgYG1hcF9hbmRfc2F2ZV9wMm1fdGFibGVgIHdoZXJlIHRoZXJlIGV4aXN0
cyBhIGNvbmZ1c2luZyBwcm9ibGVtLCBhcyBpcyBzaG93biBiZWxvdzo8L2Rpdj48ZGl2Pjxicj48
L2Rpdj48ZGl2PjxkaXY+wqA2MjEgwqAgwqBsaXZlX3AybV9mcmFtZV9saXN0ID0gwqAgwqAgwqAg
wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg
wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg
wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg
wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg
wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg
wqAgwqAgwqAgwqAgwqDCoDwvZGl2Pgo8ZGl2PsKgNjIyIMKgIMKgIMKgIMKgeGNfbWFwX2ZvcmVp
Z25fYmF0Y2goeGNfaGFuZGxlLCBkb20sIFBST1RfUkVBRCwgwqAgwqAgwqAgwqAgwqAgwqAgwqAg
wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg
wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg
wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg
wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg
wqAgwqAgwqAgwqAgwqDCoDwvZGl2Pgo8ZGl2PsKgNjIzIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg
IMKgIMKgIMKgIMKgIMKgIMKgIHAybV9mcmFtZV9saXN0X2xpc3QsIMKgIMKgIMKgIMKgIMKgIMKg
IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg
IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg
IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg
IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg
IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgwqA8L2Rpdj4KPGRpdj7CoDYyNCDCoCDCoCDCoCDC
oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBQMk1fRkxMX0VOVFJJRVMpO8KgPC9kaXY+
PC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj5tZW1jcHkocDJtX2ZyYW1lX2xpc3QsIGxpdmVfcDJt
X2ZyYW1lX2xpc3QsIFAyTV9HVUVTVF9GTF9TSVpFKTvCoDwvZGl2PjxkaXY+PGJyPjwvZGl2Pjxk
aXY+PGRpdj7CoDY1NCDCoCDCoHAybSA9IHhjX21hcF9mb3JlaWduX2JhdGNoKHhjX2hhbmRsZSwg
ZG9tLCBQUk9UX1JFQUQsIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg
IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg
IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg
IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg
IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgwqA8L2Rpdj4K
PGRpdj7CoDY1NSDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBw
Mm1fZnJhbWVfbGlzdCwgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg
wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg
wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg
wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg
wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg
wqAgwqAgwqA8L2Rpdj4KPGRpdj7CoDY1NiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC
oCDCoCDCoCDCoCDCoCBQMk1fRkxfRU5UUklFUyk7wqA8L2Rpdj48L2Rpdj48ZGl2Pjxicj48L2Rp
dj48ZGl2Pjxicj48L2Rpdj48ZGl2Pm1heWJlIHNvbWVvbmUgZW5jb3VudGVyZWQgdGhlIHNhbWUg
cHJvYmxlbSwgd291bGQgeW91IGhlbHAgbWU/PC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj5CZXNp
ZGVzLCB3aGF0JiMzOTtzIHRoZSBkaWZmZXJlbmNlIGJldHdlZW7CoElPQ1RMX1BSSVZDTURfTU1B
UCBhbmTCoElPQ1RMX1BSSVZDTURfTU1BUEJBVENIPzwvZGl2Pgo8ZGl2Pjxicj48L2Rpdj48ZGl2
Pjxicj48L2Rpdj48ZGl2PlRoYW5rczwvZGl2PjxkaXY+YnJ1Y2U8L2Rpdj4K
--047d7b621f541cca0804cace794c--


--===============1536625240398167016==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============1536625240398167016==--


From xen-devel-bounces@lists.xen.org Sat Sep 29 03:08:02 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 29 Sep 2012 03: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 1THnOx-0002ey-6I; Sat, 29 Sep 2012 03:07:35 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <aware.why@gmail.com>) id 1THnOv-0002et-2p
	for xen-devel@lists.xensource.com; Sat, 29 Sep 2012 03:07:33 +0000
Received: from [85.158.143.35:60045] by server-1.bemta-4.messagelabs.com id
	2F/BB-05684-4F566605; Sat, 29 Sep 2012 03:07:32 +0000
X-Env-Sender: aware.why@gmail.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1348888051!5890413!1
X-Originating-IP: [209.85.215.171]
X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12994 invoked from network); 29 Sep 2012 03:07:31 -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;
	29 Sep 2012 03:07:31 -0000
Received: by eaak14 with SMTP id k14so766716eaa.30
	for <xen-devel@lists.xensource.com>;
	Fri, 28 Sep 2012 20:07:30 -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=9zrWEm17yOYoVwdaNYU7+o/aWZokhfqWxKtB8XNWeNU=;
	b=XLBk4Icjv9fhCGs1Kj2nWwTb9X/BQfYGzPl6jqv+MZdsubfGzN/4W0o260juvSa3dS
	ojw5neNZZX+ZhWcbq2Pm7dAahdAAU1gHkA0I7y5madJgHGRgCg5oN6bQ8AWyAUw+uihb
	V7HD84e3jV3R6L0hAlNdVHZdBXaar3YmQRNeNZu7/YGJFHQ6rjw3MyFsEovw509zgbkN
	oCiRA/WwC7lUb+885tdJ/bCJZxO/llRrVPN9/DfID6DAashkbSVpF9a3my+OVXFFI7pK
	pSqA6/AyHwl7NSW0JkmhDWoT5Vr5RMAx1xsRCvoupBSTjKyysbWCW4jetkY/3bLKGRxK
	hpng==
MIME-Version: 1.0
Received: by 10.14.215.69 with SMTP id d45mr11987949eep.16.1348888050846; Fri,
	28 Sep 2012 20:07:30 -0700 (PDT)
Received: by 10.14.100.71 with HTTP; Fri, 28 Sep 2012 20:07:30 -0700 (PDT)
Date: Sat, 29 Sep 2012 11:07:30 +0800
Message-ID: <CA+ePHTB+_EjGgCZnbUK_cj1bT9D=ch79L04P9y5nh5dM=fvC0g@mail.gmail.com>
From: =?UTF-8?B?6ams56OK?= <aware.why@gmail.com>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] =?utf-8?b?44CQY29uZnVzZWTjgJF3aGF0IGRvZXMgeGNfbWFw?=
	=?utf-8?b?X2ZvcmVpZ25fYmF0Y2ggZG/vvJ8=?=
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1536625240398167016=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============1536625240398167016==
Content-Type: multipart/alternative; boundary=047d7b621f541cca0804cace794c

--047d7b621f541cca0804cace794c
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi=EF=BC=8C all
 In tools/libxc/xc_domain_save .c, one function called
 `map_and_save_p2m_table` where there exists a confusing problem, as is
shown below:

 621    live_p2m_frame_list =3D



 622        xc_map_foreign_batch(xc_handle, dom, PROT_READ,



 623                             p2m_frame_list_list,



 624                             P2M_FLL_ENTRIES);

memcpy(p2m_frame_list, live_p2m_frame_list, P2M_GUEST_FL_SIZE);

 654    p2m =3D xc_map_foreign_batch(xc_handle, dom, PROT_READ,



 655                               p2m_frame_list,



 656                               P2M_FL_ENTRIES);


maybe someone encountered the same problem, would you help me?

Besides, what's the difference between IOCTL_PRIVCMD_MMAP
and IOCTL_PRIVCMD_MMAPBATCH?


Thanks
bruce

--047d7b621f541cca0804cace794c
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: base64

SGnvvIwgYWxsPGRpdj7CoEluIHRvb2xzL2xpYnhjL3hjX2RvbWFpbl9zYXZlIC5jLCBvbmUgZnVu
Y3Rpb24gY2FsbGVkIMKgYG1hcF9hbmRfc2F2ZV9wMm1fdGFibGVgIHdoZXJlIHRoZXJlIGV4aXN0
cyBhIGNvbmZ1c2luZyBwcm9ibGVtLCBhcyBpcyBzaG93biBiZWxvdzo8L2Rpdj48ZGl2Pjxicj48
L2Rpdj48ZGl2PjxkaXY+wqA2MjEgwqAgwqBsaXZlX3AybV9mcmFtZV9saXN0ID0gwqAgwqAgwqAg
wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg
wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg
wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg
wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg
wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg
wqAgwqAgwqAgwqAgwqDCoDwvZGl2Pgo8ZGl2PsKgNjIyIMKgIMKgIMKgIMKgeGNfbWFwX2ZvcmVp
Z25fYmF0Y2goeGNfaGFuZGxlLCBkb20sIFBST1RfUkVBRCwgwqAgwqAgwqAgwqAgwqAgwqAgwqAg
wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg
wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg
wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg
wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg
wqAgwqAgwqAgwqAgwqDCoDwvZGl2Pgo8ZGl2PsKgNjIzIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg
IMKgIMKgIMKgIMKgIMKgIMKgIHAybV9mcmFtZV9saXN0X2xpc3QsIMKgIMKgIMKgIMKgIMKgIMKg
IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg
IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg
IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg
IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg
IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgwqA8L2Rpdj4KPGRpdj7CoDYyNCDCoCDCoCDCoCDC
oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBQMk1fRkxMX0VOVFJJRVMpO8KgPC9kaXY+
PC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj5tZW1jcHkocDJtX2ZyYW1lX2xpc3QsIGxpdmVfcDJt
X2ZyYW1lX2xpc3QsIFAyTV9HVUVTVF9GTF9TSVpFKTvCoDwvZGl2PjxkaXY+PGJyPjwvZGl2Pjxk
aXY+PGRpdj7CoDY1NCDCoCDCoHAybSA9IHhjX21hcF9mb3JlaWduX2JhdGNoKHhjX2hhbmRsZSwg
ZG9tLCBQUk9UX1JFQUQsIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg
IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg
IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg
IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg
IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgwqA8L2Rpdj4K
PGRpdj7CoDY1NSDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBw
Mm1fZnJhbWVfbGlzdCwgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg
wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg
wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg
wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg
wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg
wqAgwqAgwqA8L2Rpdj4KPGRpdj7CoDY1NiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC
oCDCoCDCoCDCoCDCoCBQMk1fRkxfRU5UUklFUyk7wqA8L2Rpdj48L2Rpdj48ZGl2Pjxicj48L2Rp
dj48ZGl2Pjxicj48L2Rpdj48ZGl2Pm1heWJlIHNvbWVvbmUgZW5jb3VudGVyZWQgdGhlIHNhbWUg
cHJvYmxlbSwgd291bGQgeW91IGhlbHAgbWU/PC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj5CZXNp
ZGVzLCB3aGF0JiMzOTtzIHRoZSBkaWZmZXJlbmNlIGJldHdlZW7CoElPQ1RMX1BSSVZDTURfTU1B
UCBhbmTCoElPQ1RMX1BSSVZDTURfTU1BUEJBVENIPzwvZGl2Pgo8ZGl2Pjxicj48L2Rpdj48ZGl2
Pjxicj48L2Rpdj48ZGl2PlRoYW5rczwvZGl2PjxkaXY+YnJ1Y2U8L2Rpdj4K
--047d7b621f541cca0804cace794c--


--===============1536625240398167016==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============1536625240398167016==--


From xen-devel-bounces@lists.xen.org Sat Sep 29 04:34:46 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 29 Sep 2012 04:34:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1THokt-00030o-Nl; Sat, 29 Sep 2012 04:34: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 1THoks-00030j-64
	for xen-devel@lists.xensource.com; Sat, 29 Sep 2012 04:34:18 +0000
Received: from [85.158.143.35:28163] by server-1.bemta-4.messagelabs.com id
	CA/EE-05684-94A76605; Sat, 29 Sep 2012 04:34:17 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1348893256!18953445!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTIzOTk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29597 invoked from network); 29 Sep 2012 04:34:16 -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 Sep 2012 04:34:16 -0000
X-IronPort-AV: E=Sophos;i="4.80,505,1344211200"; d="scan'208";a="14845157"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Sep 2012 04:34: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.279.1; Sat, 29 Sep 2012 05:34: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 1THokp-0006Vp-Dd;
	Sat, 29 Sep 2012 04:34:15 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1THokp-0008H6-6V;
	Sat, 29 Sep 2012 05:34:15 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-13902-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sat, 29 Sep 2012 05:34:15 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13902: 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 13902 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13902/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 13901
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore            fail   like 13901
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail like 13901
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail like 13901

Tests which did not succeed, but are not blocking:
 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-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  bd953fda6106
baseline version:
 xen                  bd953fda6106

jobs:
 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-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-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-amd64-amd64-xl-win                                      fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Published tested tree is already up to date.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Sep 29 04:34:46 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 29 Sep 2012 04:34:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1THokt-00030o-Nl; Sat, 29 Sep 2012 04:34: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 1THoks-00030j-64
	for xen-devel@lists.xensource.com; Sat, 29 Sep 2012 04:34:18 +0000
Received: from [85.158.143.35:28163] by server-1.bemta-4.messagelabs.com id
	CA/EE-05684-94A76605; Sat, 29 Sep 2012 04:34:17 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1348893256!18953445!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTIzOTk=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29597 invoked from network); 29 Sep 2012 04:34:16 -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 Sep 2012 04:34:16 -0000
X-IronPort-AV: E=Sophos;i="4.80,505,1344211200"; d="scan'208";a="14845157"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Sep 2012 04:34: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.279.1; Sat, 29 Sep 2012 05:34: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 1THokp-0006Vp-Dd;
	Sat, 29 Sep 2012 04:34:15 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1THokp-0008H6-6V;
	Sat, 29 Sep 2012 05:34:15 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-13902-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sat, 29 Sep 2012 05:34:15 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13902: 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 13902 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13902/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 13901
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore            fail   like 13901
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail like 13901
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail like 13901

Tests which did not succeed, but are not blocking:
 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-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  bd953fda6106
baseline version:
 xen                  bd953fda6106

jobs:
 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-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-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-amd64-amd64-xl-win                                      fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Published tested tree is already up to date.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Sep 29 05:03:55 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 29 Sep 2012 05:03:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1THpD7-0003hq-P3; Sat, 29 Sep 2012 05:03:29 +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 1THpD6-0003hl-A4
	for xen-devel@lists.xen.org; Sat, 29 Sep 2012 05:03:28 +0000
Received: from [85.158.143.35:60147] by server-1.bemta-4.messagelabs.com id
	F2/56-05684-F1186605; Sat, 29 Sep 2012 05:03:27 +0000
X-Env-Sender: msw@amazon.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1348895001!16799360!1
X-Originating-IP: [207.171.178.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA3LjE3MS4xNzguMjUgPT4gNzIzNjI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21532 invoked from network); 29 Sep 2012 05:03:23 -0000
Received: from smtp-fw-31001.amazon.com (HELO smtp-fw-31001.amazon.com)
	(207.171.178.25)
	by server-14.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Sep 2012 05:03:23 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=amazon.com; i=msw@amazon.com; q=dns/txt;
	s=amazon201209; t=1348895006; x=1380431006;
	h=mime-version:content-transfer-encoding:subject:
	message-id:date:from:to:cc;
	bh=LPXDfMJJ3Kl71p1ndUwTs0CLRd0dN8UmgK5C9PvRuHY=;
	b=fXAaEkR6cesAWIcB+9ArZOOjpIWMl0Hd19CrLAHSlZ1+qmc9ID748iv3
	BaxpQF/hiolwesR8UXtYiJ7lahR3u0KpDf+gQXWl/VOmZvW60+/YGUoP8
	P2G9zE0Aq0awGnKfLdp02q3+1wYw87X+6gkhaMmU9V2Y6Imlo+ud/xULP k=;
X-IronPort-AV: E=Sophos;i="4.80,506,1344211200"; d="scan'208";a="301515344"
Received: from smtp-in-0102.sea3.amazon.com ([10.224.19.46])
	by smtp-border-fw-out-31001.sea31.amazon.com with
	ESMTP/TLS/DHE-RSA-AES256-SHA; 29 Sep 2012 05:03:14 +0000
Received: from kaos-source-31003.sea31.amazon.com
	(kaos-source-31003.sea31.amazon.com [10.185.53.37])
	by smtp-in-0102.sea3.amazon.com (8.13.8/8.13.8) with ESMTP id
	q8T53D15009421; Sat, 29 Sep 2012 05:03:14 GMT
MIME-Version: 1.0
X-Mercurial-Node: 20f6976e28a1ce7e910e8385bdaba18c9d21b8cd
Message-Id: <20f6976e28a1ce7e910e.1348894953@kaos-source-31003.sea31.amazon.com>
User-Agent: Mercurial-patchbomb/2.1.1
Date: Sat, 29 Sep 2012 05:02:33 +0000
From: Matt Wilson <msw@amazon.com>
To: Keir Fraser <keir@xen.org>, Jan Beulich <jbeulich@suse.com>
Cc: xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH] xen/console: introduce a 'w' debug-key that
 dumps the console ring
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This patch adds a new 'w' debug-key, chosen from the limited remaining
keys only due to its proximity to 'q', that dumps the console ring to
configured console devices. It's useful to for tracking down how an
unresponsive system got into a broken state via serial console.

Signed-off-by: Matt Wilson <msw@amazon.com>

diff -r bd953fda6106 -r 20f6976e28a1 xen/drivers/char/console.c
--- a/xen/drivers/char/console.c	Fri Sep 28 10:59:41 2012 +0200
+++ b/xen/drivers/char/console.c	Sat Sep 29 05:00:05 2012 +0000
@@ -264,6 +264,49 @@ static void sercon_puts(const char *s)
         serial_puts(sercon_handle, s);
 }
 
+static void dump_console_ring_key(unsigned char key)
+{
+    uint32_t idx, len, sofar, c;
+    unsigned int order;
+    char *buf;
+
+    printk("'%c' pressed -> dumping console ring buffer (dmesg)\n", key);
+
+    /* create a buffer in which we'll copy the ring in the correct
+       order and NUL terminate */
+    order = get_order_from_bytes(conring_size + 1);
+    buf = alloc_xenheap_pages(order, 0);
+    if ( buf == NULL )
+    {
+        printk("unable to allocate memory!\n");
+        return;
+    }
+
+    c = conringc;
+    sofar = 0;
+    while ( (c != conringp) )
+    {
+        idx = CONRING_IDX_MASK(c);
+        len = conringp - c;
+        if ( (idx + len) > conring_size )
+            len = conring_size - idx;
+        memcpy(buf + sofar, &conring[idx], len);
+        sofar += len;
+        c += len;
+    }
+    buf[sofar] = '\0';
+
+    sercon_puts(buf);
+    vga_puts(buf);
+
+    free_xenheap_pages(buf, order);
+}
+
+static struct keyhandler dump_console_ring_keyhandler = {
+    .u.fn = dump_console_ring_key,
+    .desc = "synchronously dump console ring buffer (dmesg)"
+};
+
 /* CTRL-<switch_char> switches input direction between Xen and DOM0. */
 #define switch_code (opt_conswitch[0]-'a'+1)
 static int __read_mostly xen_rx = 1; /* FALSE => serial input passed to domain 0. */
@@ -661,6 +704,8 @@ void __init console_endboot(void)
     if ( opt_conswitch[1] == 'x' )
         xen_rx = !xen_rx;
 
+    register_keyhandler('w', &dump_console_ring_keyhandler);
+
     /* Serial input is directed to DOM0 by default. */
     switch_serial_input();
 }

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Sep 29 05:03:55 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 29 Sep 2012 05:03:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1THpD7-0003hq-P3; Sat, 29 Sep 2012 05:03:29 +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 1THpD6-0003hl-A4
	for xen-devel@lists.xen.org; Sat, 29 Sep 2012 05:03:28 +0000
Received: from [85.158.143.35:60147] by server-1.bemta-4.messagelabs.com id
	F2/56-05684-F1186605; Sat, 29 Sep 2012 05:03:27 +0000
X-Env-Sender: msw@amazon.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1348895001!16799360!1
X-Originating-IP: [207.171.178.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA3LjE3MS4xNzguMjUgPT4gNzIzNjI=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21532 invoked from network); 29 Sep 2012 05:03:23 -0000
Received: from smtp-fw-31001.amazon.com (HELO smtp-fw-31001.amazon.com)
	(207.171.178.25)
	by server-14.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Sep 2012 05:03:23 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=amazon.com; i=msw@amazon.com; q=dns/txt;
	s=amazon201209; t=1348895006; x=1380431006;
	h=mime-version:content-transfer-encoding:subject:
	message-id:date:from:to:cc;
	bh=LPXDfMJJ3Kl71p1ndUwTs0CLRd0dN8UmgK5C9PvRuHY=;
	b=fXAaEkR6cesAWIcB+9ArZOOjpIWMl0Hd19CrLAHSlZ1+qmc9ID748iv3
	BaxpQF/hiolwesR8UXtYiJ7lahR3u0KpDf+gQXWl/VOmZvW60+/YGUoP8
	P2G9zE0Aq0awGnKfLdp02q3+1wYw87X+6gkhaMmU9V2Y6Imlo+ud/xULP k=;
X-IronPort-AV: E=Sophos;i="4.80,506,1344211200"; d="scan'208";a="301515344"
Received: from smtp-in-0102.sea3.amazon.com ([10.224.19.46])
	by smtp-border-fw-out-31001.sea31.amazon.com with
	ESMTP/TLS/DHE-RSA-AES256-SHA; 29 Sep 2012 05:03:14 +0000
Received: from kaos-source-31003.sea31.amazon.com
	(kaos-source-31003.sea31.amazon.com [10.185.53.37])
	by smtp-in-0102.sea3.amazon.com (8.13.8/8.13.8) with ESMTP id
	q8T53D15009421; Sat, 29 Sep 2012 05:03:14 GMT
MIME-Version: 1.0
X-Mercurial-Node: 20f6976e28a1ce7e910e8385bdaba18c9d21b8cd
Message-Id: <20f6976e28a1ce7e910e.1348894953@kaos-source-31003.sea31.amazon.com>
User-Agent: Mercurial-patchbomb/2.1.1
Date: Sat, 29 Sep 2012 05:02:33 +0000
From: Matt Wilson <msw@amazon.com>
To: Keir Fraser <keir@xen.org>, Jan Beulich <jbeulich@suse.com>
Cc: xen-devel@lists.xen.org
Subject: [Xen-devel] [PATCH] xen/console: introduce a 'w' debug-key that
 dumps the console ring
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This patch adds a new 'w' debug-key, chosen from the limited remaining
keys only due to its proximity to 'q', that dumps the console ring to
configured console devices. It's useful to for tracking down how an
unresponsive system got into a broken state via serial console.

Signed-off-by: Matt Wilson <msw@amazon.com>

diff -r bd953fda6106 -r 20f6976e28a1 xen/drivers/char/console.c
--- a/xen/drivers/char/console.c	Fri Sep 28 10:59:41 2012 +0200
+++ b/xen/drivers/char/console.c	Sat Sep 29 05:00:05 2012 +0000
@@ -264,6 +264,49 @@ static void sercon_puts(const char *s)
         serial_puts(sercon_handle, s);
 }
 
+static void dump_console_ring_key(unsigned char key)
+{
+    uint32_t idx, len, sofar, c;
+    unsigned int order;
+    char *buf;
+
+    printk("'%c' pressed -> dumping console ring buffer (dmesg)\n", key);
+
+    /* create a buffer in which we'll copy the ring in the correct
+       order and NUL terminate */
+    order = get_order_from_bytes(conring_size + 1);
+    buf = alloc_xenheap_pages(order, 0);
+    if ( buf == NULL )
+    {
+        printk("unable to allocate memory!\n");
+        return;
+    }
+
+    c = conringc;
+    sofar = 0;
+    while ( (c != conringp) )
+    {
+        idx = CONRING_IDX_MASK(c);
+        len = conringp - c;
+        if ( (idx + len) > conring_size )
+            len = conring_size - idx;
+        memcpy(buf + sofar, &conring[idx], len);
+        sofar += len;
+        c += len;
+    }
+    buf[sofar] = '\0';
+
+    sercon_puts(buf);
+    vga_puts(buf);
+
+    free_xenheap_pages(buf, order);
+}
+
+static struct keyhandler dump_console_ring_keyhandler = {
+    .u.fn = dump_console_ring_key,
+    .desc = "synchronously dump console ring buffer (dmesg)"
+};
+
 /* CTRL-<switch_char> switches input direction between Xen and DOM0. */
 #define switch_code (opt_conswitch[0]-'a'+1)
 static int __read_mostly xen_rx = 1; /* FALSE => serial input passed to domain 0. */
@@ -661,6 +704,8 @@ void __init console_endboot(void)
     if ( opt_conswitch[1] == 'x' )
         xen_rx = !xen_rx;
 
+    register_keyhandler('w', &dump_console_ring_keyhandler);
+
     /* Serial input is directed to DOM0 by default. */
     switch_serial_input();
 }

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Sep 29 05:06:06 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 29 Sep 2012 05: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 1THpFH-0003oj-Eg; Sat, 29 Sep 2012 05:05: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 1THpFG-0003od-6s
	for xen-devel@lists.xen.org; Sat, 29 Sep 2012 05:05:42 +0000
Received: from [85.158.143.35:64397] by server-3.bemta-4.messagelabs.com id
	DB/20-10986-5A186605; Sat, 29 Sep 2012 05:05:41 +0000
X-Env-Sender: msw@amazon.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1348895139!13229367!1
X-Originating-IP: [207.171.184.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA3LjE3MS4xODQuMjUgPT4gMzE5ODgy\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1683 invoked from network); 29 Sep 2012 05:05:40 -0000
Received: from smtp-fw-9101.amazon.com (HELO smtp-fw-9101.amazon.com)
	(207.171.184.25)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Sep 2012 05:05:40 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=amazon.com; i=msw@amazon.com; q=dns/txt;
	s=amazon201209; t=1348895141; x=1380431141;
	h=date:from:to:cc:subject:message-id:references:
	mime-version:in-reply-to;
	bh=O77DJhPnFK4+n9d939L7lZuF078Yw2TVJT98ZbBgEdQ=;
	b=DlQ7OkljFXhMv+OtUpKMsYeRUg5xzyfCwQRfUuV3kAVHg8oel+UrYAeJ
	/XkXlIJ48GvUiyDAQ+zcwBvrjuouFp5BmbpoVfEGiXo1S+3N7taaHt/gI
	OWUww7Iho7DobeQOyFPtZd0hPFxHWPhUnQ4eqpkllR0Z0jHJzjmOR78ei c=;
X-IronPort-AV: E=Sophos;i="4.80,506,1344211200"; d="scan'208";a="1032853555"
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; 29 Sep 2012 05:04:59 +0000
Received: from ex10-hub-31006.ant.amazon.com (ex10-hub-31006.sea31.amazon.com
	[10.185.176.13])
	by smtp-in-9001.sea19.amazon.com (8.13.8/8.13.8) with ESMTP id
	q8T54xm1028140
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL);
	Sat, 29 Sep 2012 05:04:59 GMT
Received: from u002268147cd4502c336d.ant.amazon.com (10.224.80.42) by
	ex10-hub-31006.ant.amazon.com (10.185.176.13) with Microsoft SMTP
	Server id 14.2.247.3; Fri, 28 Sep 2012 22:04:58 -0700
Received: by u002268147cd4502c336d.ant.amazon.com (sSMTP sendmail emulation); 
	Fri, 28 Sep 2012 22:04:58 -0700
Date: Fri, 28 Sep 2012 22:04:57 -0700
From: Matt Wilson <msw@amazon.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Message-ID: <20120929050455.GA21253@u002268147cd4502c336d.ant.amazon.com>
References: <CAOqnZH5qZAHOw2xLZXNF6KT6qGiqJmYR-L9BLaviBkjAOCAPFA@mail.gmail.com>
	<CC8A0E9F.400A6%keir.xen@gmail.com>
	<20581.56185.438929.702646@mariner.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20581.56185.438929.702646@mariner.uk.xensource.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: Lars Kurth <lars.kurth.xen@gmail.com>, Keir Fraser <keir.xen@gmail.com>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [ANNOUNCE] Switching to git for primary Xen
 repositories
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Sep 28, 2012 at 06:16:41PM +0100, Ian Jackson wrote:
> Keir writes:
> > Our plan therefore, with the 4.2.0 release soon out of the way, is
> > to switch to git for all of our primary repositories. We will plan
> > to mirror development activity into the old mercurial repositories
> > at least in the short term.
> 
> So if we're having a vote on this, as discussed:
> 
> +1

Enthusiastic +1

Matt

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Sep 29 05:06:06 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 29 Sep 2012 05: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 1THpFH-0003oj-Eg; Sat, 29 Sep 2012 05:05: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 1THpFG-0003od-6s
	for xen-devel@lists.xen.org; Sat, 29 Sep 2012 05:05:42 +0000
Received: from [85.158.143.35:64397] by server-3.bemta-4.messagelabs.com id
	DB/20-10986-5A186605; Sat, 29 Sep 2012 05:05:41 +0000
X-Env-Sender: msw@amazon.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1348895139!13229367!1
X-Originating-IP: [207.171.184.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA3LjE3MS4xODQuMjUgPT4gMzE5ODgy\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1683 invoked from network); 29 Sep 2012 05:05:40 -0000
Received: from smtp-fw-9101.amazon.com (HELO smtp-fw-9101.amazon.com)
	(207.171.184.25)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Sep 2012 05:05:40 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=amazon.com; i=msw@amazon.com; q=dns/txt;
	s=amazon201209; t=1348895141; x=1380431141;
	h=date:from:to:cc:subject:message-id:references:
	mime-version:in-reply-to;
	bh=O77DJhPnFK4+n9d939L7lZuF078Yw2TVJT98ZbBgEdQ=;
	b=DlQ7OkljFXhMv+OtUpKMsYeRUg5xzyfCwQRfUuV3kAVHg8oel+UrYAeJ
	/XkXlIJ48GvUiyDAQ+zcwBvrjuouFp5BmbpoVfEGiXo1S+3N7taaHt/gI
	OWUww7Iho7DobeQOyFPtZd0hPFxHWPhUnQ4eqpkllR0Z0jHJzjmOR78ei c=;
X-IronPort-AV: E=Sophos;i="4.80,506,1344211200"; d="scan'208";a="1032853555"
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; 29 Sep 2012 05:04:59 +0000
Received: from ex10-hub-31006.ant.amazon.com (ex10-hub-31006.sea31.amazon.com
	[10.185.176.13])
	by smtp-in-9001.sea19.amazon.com (8.13.8/8.13.8) with ESMTP id
	q8T54xm1028140
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL);
	Sat, 29 Sep 2012 05:04:59 GMT
Received: from u002268147cd4502c336d.ant.amazon.com (10.224.80.42) by
	ex10-hub-31006.ant.amazon.com (10.185.176.13) with Microsoft SMTP
	Server id 14.2.247.3; Fri, 28 Sep 2012 22:04:58 -0700
Received: by u002268147cd4502c336d.ant.amazon.com (sSMTP sendmail emulation); 
	Fri, 28 Sep 2012 22:04:58 -0700
Date: Fri, 28 Sep 2012 22:04:57 -0700
From: Matt Wilson <msw@amazon.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Message-ID: <20120929050455.GA21253@u002268147cd4502c336d.ant.amazon.com>
References: <CAOqnZH5qZAHOw2xLZXNF6KT6qGiqJmYR-L9BLaviBkjAOCAPFA@mail.gmail.com>
	<CC8A0E9F.400A6%keir.xen@gmail.com>
	<20581.56185.438929.702646@mariner.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20581.56185.438929.702646@mariner.uk.xensource.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: Lars Kurth <lars.kurth.xen@gmail.com>, Keir Fraser <keir.xen@gmail.com>,
	xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [ANNOUNCE] Switching to git for primary Xen
 repositories
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Fri, Sep 28, 2012 at 06:16:41PM +0100, Ian Jackson wrote:
> Keir writes:
> > Our plan therefore, with the 4.2.0 release soon out of the way, is
> > to switch to git for all of our primary repositories. We will plan
> > to mirror development activity into the old mercurial repositories
> > at least in the short term.
> 
> So if we're having a vote on this, as discussed:
> 
> +1

Enthusiastic +1

Matt

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Sep 29 05:55:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 29 Sep 2012 05: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 1THq0U-00047K-PK; Sat, 29 Sep 2012 05:54: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 1THq0T-00047F-7J
	for xen-devel@lists.xen.org; Sat, 29 Sep 2012 05:54:29 +0000
Received: from [85.158.138.51:57471] by server-1.bemta-3.messagelabs.com id
	B3/B7-16425-41D86605; Sat, 29 Sep 2012 05:54:28 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1348898067!24345786!1
X-Originating-IP: [74.125.82.51]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5695 invoked from network); 29 Sep 2012 05:54:27 -0000
Received: from mail-wg0-f51.google.com (HELO mail-wg0-f51.google.com)
	(74.125.82.51)
	by server-3.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Sep 2012 05:54:27 -0000
Received: by wgbed3 with SMTP id ed3so972031wgb.32
	for <xen-devel@lists.xen.org>; Fri, 28 Sep 2012 22:54: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=lkUdbemgOFQgMCKfTNwOjAAttpaavEaZJgcmonRwfkI=;
	b=axEZ9iu0AOYXRQEvjOKxM43IPjGA804se3QUJdRsxvldBIlcLZtgo7GL3Gv4k5d/mf
	pLjXyzbb+mKgIotQfipCMX5RVR76NulOMW911Z8aO5T8DQbODGPIknGqeQvcNmHxitJT
	sgNLWEWpKVjSMeKWnLLLjiKN9BhLRDXyHzDLQDLKQ2PvU07KqBq/wYp//eu51Tw7l8IZ
	zgH4fGw/9DuQtAZin6rD3DlHwlzsc5/DQbfZlhznlSj+pSEV2+6WqbpMknfYOMhtcWs1
	9/G4KvdSreBcTgThg8pcnIPJygQT5erHSwBnviE0iVHqLUZ7bZO8LfEbW5KhAzKXtOkU
	xgpg==
Received: by 10.216.255.148 with SMTP id j20mr4355859wes.106.1348898067515;
	Fri, 28 Sep 2012 22:54:27 -0700 (PDT)
Received: from [192.168.1.69]
	(host86-183-156-141.range86-183.btcentralplus.com. [86.183.156.141])
	by mx.google.com with ESMTPS id t7sm3528683wix.6.2012.09.28.22.54.25
	(version=SSLv3 cipher=OTHER); Fri, 28 Sep 2012 22:54:26 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Sat, 29 Sep 2012 06:54:22 +0100
From: Keir Fraser <keir.xen@gmail.com>
To: Matt Wilson <msw@amazon.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Message-ID: <CC8C4B9E.40283%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [ANNOUNCE] Switching to git for primary Xen
	repositories
Thread-Index: Ac2eBt97A4O/t6Ry0UGorEjOJUpsCA==
In-Reply-To: <20120929050455.GA21253@u002268147cd4502c336d.ant.amazon.com>
Mime-version: 1.0
Cc: Lars Kurth <lars.kurth.xen@gmail.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [ANNOUNCE] Switching to git for primary Xen
 repositories
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/09/2012 06:04, "Matt Wilson" <msw@amazon.com> wrote:

> On Fri, Sep 28, 2012 at 06:16:41PM +0100, Ian Jackson wrote:
>> Keir writes:
>>> Our plan therefore, with the 4.2.0 release soon out of the way, is
>>> to switch to git for all of our primary repositories. We will plan
>>> to mirror development activity into the old mercurial repositories
>>> at least in the short term.
>> 
>> So if we're having a vote on this, as discussed:
>> 
>> +1
> 
> Enthusiastic +1

+1

> Matt



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Sep 29 05:55:04 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 29 Sep 2012 05: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 1THq0U-00047K-PK; Sat, 29 Sep 2012 05:54: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 1THq0T-00047F-7J
	for xen-devel@lists.xen.org; Sat, 29 Sep 2012 05:54:29 +0000
Received: from [85.158.138.51:57471] by server-1.bemta-3.messagelabs.com id
	B3/B7-16425-41D86605; Sat, 29 Sep 2012 05:54:28 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1348898067!24345786!1
X-Originating-IP: [74.125.82.51]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5695 invoked from network); 29 Sep 2012 05:54:27 -0000
Received: from mail-wg0-f51.google.com (HELO mail-wg0-f51.google.com)
	(74.125.82.51)
	by server-3.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Sep 2012 05:54:27 -0000
Received: by wgbed3 with SMTP id ed3so972031wgb.32
	for <xen-devel@lists.xen.org>; Fri, 28 Sep 2012 22:54: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=lkUdbemgOFQgMCKfTNwOjAAttpaavEaZJgcmonRwfkI=;
	b=axEZ9iu0AOYXRQEvjOKxM43IPjGA804se3QUJdRsxvldBIlcLZtgo7GL3Gv4k5d/mf
	pLjXyzbb+mKgIotQfipCMX5RVR76NulOMW911Z8aO5T8DQbODGPIknGqeQvcNmHxitJT
	sgNLWEWpKVjSMeKWnLLLjiKN9BhLRDXyHzDLQDLKQ2PvU07KqBq/wYp//eu51Tw7l8IZ
	zgH4fGw/9DuQtAZin6rD3DlHwlzsc5/DQbfZlhznlSj+pSEV2+6WqbpMknfYOMhtcWs1
	9/G4KvdSreBcTgThg8pcnIPJygQT5erHSwBnviE0iVHqLUZ7bZO8LfEbW5KhAzKXtOkU
	xgpg==
Received: by 10.216.255.148 with SMTP id j20mr4355859wes.106.1348898067515;
	Fri, 28 Sep 2012 22:54:27 -0700 (PDT)
Received: from [192.168.1.69]
	(host86-183-156-141.range86-183.btcentralplus.com. [86.183.156.141])
	by mx.google.com with ESMTPS id t7sm3528683wix.6.2012.09.28.22.54.25
	(version=SSLv3 cipher=OTHER); Fri, 28 Sep 2012 22:54:26 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Sat, 29 Sep 2012 06:54:22 +0100
From: Keir Fraser <keir.xen@gmail.com>
To: Matt Wilson <msw@amazon.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Message-ID: <CC8C4B9E.40283%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [ANNOUNCE] Switching to git for primary Xen
	repositories
Thread-Index: Ac2eBt97A4O/t6Ry0UGorEjOJUpsCA==
In-Reply-To: <20120929050455.GA21253@u002268147cd4502c336d.ant.amazon.com>
Mime-version: 1.0
Cc: Lars Kurth <lars.kurth.xen@gmail.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [ANNOUNCE] Switching to git for primary Xen
 repositories
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/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/09/2012 06:04, "Matt Wilson" <msw@amazon.com> wrote:

> On Fri, Sep 28, 2012 at 06:16:41PM +0100, Ian Jackson wrote:
>> Keir writes:
>>> Our plan therefore, with the 4.2.0 release soon out of the way, is
>>> to switch to git for all of our primary repositories. We will plan
>>> to mirror development activity into the old mercurial repositories
>>> at least in the short term.
>> 
>> So if we're having a vote on this, as discussed:
>> 
>> +1
> 
> Enthusiastic +1

+1

> Matt



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Sep 29 05:56:11 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 29 Sep 2012 05: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 1THq1k-0004BB-7a; Sat, 29 Sep 2012 05:55:48 +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 1THq1i-0004B0-TE
	for xen-devel@lists.xen.org; Sat, 29 Sep 2012 05:55:47 +0000
Received: from [85.158.138.51:30003] by server-12.bemta-3.messagelabs.com id
	43/39-23730-26D86605; Sat, 29 Sep 2012 05:55:46 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1348898145!32504015!1
X-Originating-IP: [74.125.82.51]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25491 invoked from network); 29 Sep 2012 05:55:45 -0000
Received: from mail-wg0-f51.google.com (HELO mail-wg0-f51.google.com)
	(74.125.82.51)
	by server-5.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Sep 2012 05:55:45 -0000
Received: by wgbed3 with SMTP id ed3so972483wgb.32
	for <xen-devel@lists.xen.org>; Fri, 28 Sep 2012 22:55:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=3E6RFS/42oki0QjFYcpKTUfYkFV6xtzYWREdHQ/XnJw=;
	b=LhG7SaJqU73zwweWVoIFuGHFhUuqzno1PpjbXO4B5iEVrgHY4GVdbA6nOl9zd/QR+P
	cqcJWoInnuJJbYrLa/TNwU2SCs94SUA29s/4QdihrsyV9qstuUOIwjYcIN/zGiRrhpSE
	wV/eh2/i38LL79ODQLwym5s6I0c8+6SHbUniMshr0UFX1bSV4f5z9pabCZANIHVDAyAW
	TfkFZD/oUpUCQXQaoxV+CSINwqD5pffsFuUG5HRccU/ykmoQI4QNcedtEZT/qL7EWM6K
	dbpW3JOWQ5yAJ92B+477GAt7eqbI3Yphy31rpEn1VPVwno4NrCx3Sn05bdTEKsCnk1m4
	TATw==
Received: by 10.216.41.195 with SMTP id h45mr4852639web.74.1348898145145;
	Fri, 28 Sep 2012 22:55:45 -0700 (PDT)
Received: from [192.168.1.69]
	(host86-183-156-141.range86-183.btcentralplus.com. [86.183.156.141])
	by mx.google.com with ESMTPS id ga2sm3550045wib.2.2012.09.28.22.55.43
	(version=SSLv3 cipher=OTHER); Fri, 28 Sep 2012 22:55:44 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Sat, 29 Sep 2012 06:55:41 +0100
From: Keir Fraser <keir.xen@gmail.com>
To: Matt Wilson <msw@amazon.com>,
	Jan Beulich <jbeulich@suse.com>
Message-ID: <CC8C4BED.40284%keir.xen@gmail.com>
Thread-Topic: [PATCH] xen/console: introduce a 'w' debug-key that dumps the
	console ring
Thread-Index: Ac2eBw6RMcJ+wQ4MAke2CEW+0v3qbA==
In-Reply-To: <20f6976e28a1ce7e910e.1348894953@kaos-source-31003.sea31.amazon.com>
Mime-version: 1.0
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] xen/console: introduce a 'w' debug-key that
 dumps the console ring
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 29/09/2012 06:02, "Matt Wilson" <msw@amazon.com> wrote:

> This patch adds a new 'w' debug-key, chosen from the limited remaining
> keys only due to its proximity to 'q', that dumps the console ring to
> configured console devices. It's useful to for tracking down how an
> unresponsive system got into a broken state via serial console.

Why wouldn't everything on the ring already have been sent to the configured
console devices?

 -- Keir

> Signed-off-by: Matt Wilson <msw@amazon.com>
> 
> diff -r bd953fda6106 -r 20f6976e28a1 xen/drivers/char/console.c
> --- a/xen/drivers/char/console.c Fri Sep 28 10:59:41 2012 +0200
> +++ b/xen/drivers/char/console.c Sat Sep 29 05:00:05 2012 +0000
> @@ -264,6 +264,49 @@ static void sercon_puts(const char *s)
>          serial_puts(sercon_handle, s);
>  }
>  
> +static void dump_console_ring_key(unsigned char key)
> +{
> +    uint32_t idx, len, sofar, c;
> +    unsigned int order;
> +    char *buf;
> +
> +    printk("'%c' pressed -> dumping console ring buffer (dmesg)\n", key);
> +
> +    /* create a buffer in which we'll copy the ring in the correct
> +       order and NUL terminate */
> +    order = get_order_from_bytes(conring_size + 1);
> +    buf = alloc_xenheap_pages(order, 0);
> +    if ( buf == NULL )
> +    {
> +        printk("unable to allocate memory!\n");
> +        return;
> +    }
> +
> +    c = conringc;
> +    sofar = 0;
> +    while ( (c != conringp) )
> +    {
> +        idx = CONRING_IDX_MASK(c);
> +        len = conringp - c;
> +        if ( (idx + len) > conring_size )
> +            len = conring_size - idx;
> +        memcpy(buf + sofar, &conring[idx], len);
> +        sofar += len;
> +        c += len;
> +    }
> +    buf[sofar] = '\0';
> +
> +    sercon_puts(buf);
> +    vga_puts(buf);
> +
> +    free_xenheap_pages(buf, order);
> +}
> +
> +static struct keyhandler dump_console_ring_keyhandler = {
> +    .u.fn = dump_console_ring_key,
> +    .desc = "synchronously dump console ring buffer (dmesg)"
> +};
> +
>  /* CTRL-<switch_char> switches input direction between Xen and DOM0. */
>  #define switch_code (opt_conswitch[0]-'a'+1)
>  static int __read_mostly xen_rx = 1; /* FALSE => serial input passed to
> domain 0. */
> @@ -661,6 +704,8 @@ void __init console_endboot(void)
>      if ( opt_conswitch[1] == 'x' )
>          xen_rx = !xen_rx;
>  
> +    register_keyhandler('w', &dump_console_ring_keyhandler);
> +
>      /* Serial input is directed to DOM0 by default. */
>      switch_serial_input();
>  }



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Sep 29 05:56:11 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 29 Sep 2012 05: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 1THq1k-0004BB-7a; Sat, 29 Sep 2012 05:55:48 +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 1THq1i-0004B0-TE
	for xen-devel@lists.xen.org; Sat, 29 Sep 2012 05:55:47 +0000
Received: from [85.158.138.51:30003] by server-12.bemta-3.messagelabs.com id
	43/39-23730-26D86605; Sat, 29 Sep 2012 05:55:46 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1348898145!32504015!1
X-Originating-IP: [74.125.82.51]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25491 invoked from network); 29 Sep 2012 05:55:45 -0000
Received: from mail-wg0-f51.google.com (HELO mail-wg0-f51.google.com)
	(74.125.82.51)
	by server-5.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Sep 2012 05:55:45 -0000
Received: by wgbed3 with SMTP id ed3so972483wgb.32
	for <xen-devel@lists.xen.org>; Fri, 28 Sep 2012 22:55:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=3E6RFS/42oki0QjFYcpKTUfYkFV6xtzYWREdHQ/XnJw=;
	b=LhG7SaJqU73zwweWVoIFuGHFhUuqzno1PpjbXO4B5iEVrgHY4GVdbA6nOl9zd/QR+P
	cqcJWoInnuJJbYrLa/TNwU2SCs94SUA29s/4QdihrsyV9qstuUOIwjYcIN/zGiRrhpSE
	wV/eh2/i38LL79ODQLwym5s6I0c8+6SHbUniMshr0UFX1bSV4f5z9pabCZANIHVDAyAW
	TfkFZD/oUpUCQXQaoxV+CSINwqD5pffsFuUG5HRccU/ykmoQI4QNcedtEZT/qL7EWM6K
	dbpW3JOWQ5yAJ92B+477GAt7eqbI3Yphy31rpEn1VPVwno4NrCx3Sn05bdTEKsCnk1m4
	TATw==
Received: by 10.216.41.195 with SMTP id h45mr4852639web.74.1348898145145;
	Fri, 28 Sep 2012 22:55:45 -0700 (PDT)
Received: from [192.168.1.69]
	(host86-183-156-141.range86-183.btcentralplus.com. [86.183.156.141])
	by mx.google.com with ESMTPS id ga2sm3550045wib.2.2012.09.28.22.55.43
	(version=SSLv3 cipher=OTHER); Fri, 28 Sep 2012 22:55:44 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Sat, 29 Sep 2012 06:55:41 +0100
From: Keir Fraser <keir.xen@gmail.com>
To: Matt Wilson <msw@amazon.com>,
	Jan Beulich <jbeulich@suse.com>
Message-ID: <CC8C4BED.40284%keir.xen@gmail.com>
Thread-Topic: [PATCH] xen/console: introduce a 'w' debug-key that dumps the
	console ring
Thread-Index: Ac2eBw6RMcJ+wQ4MAke2CEW+0v3qbA==
In-Reply-To: <20f6976e28a1ce7e910e.1348894953@kaos-source-31003.sea31.amazon.com>
Mime-version: 1.0
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] xen/console: introduce a 'w' debug-key that
 dumps the console ring
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 29/09/2012 06:02, "Matt Wilson" <msw@amazon.com> wrote:

> This patch adds a new 'w' debug-key, chosen from the limited remaining
> keys only due to its proximity to 'q', that dumps the console ring to
> configured console devices. It's useful to for tracking down how an
> unresponsive system got into a broken state via serial console.

Why wouldn't everything on the ring already have been sent to the configured
console devices?

 -- Keir

> Signed-off-by: Matt Wilson <msw@amazon.com>
> 
> diff -r bd953fda6106 -r 20f6976e28a1 xen/drivers/char/console.c
> --- a/xen/drivers/char/console.c Fri Sep 28 10:59:41 2012 +0200
> +++ b/xen/drivers/char/console.c Sat Sep 29 05:00:05 2012 +0000
> @@ -264,6 +264,49 @@ static void sercon_puts(const char *s)
>          serial_puts(sercon_handle, s);
>  }
>  
> +static void dump_console_ring_key(unsigned char key)
> +{
> +    uint32_t idx, len, sofar, c;
> +    unsigned int order;
> +    char *buf;
> +
> +    printk("'%c' pressed -> dumping console ring buffer (dmesg)\n", key);
> +
> +    /* create a buffer in which we'll copy the ring in the correct
> +       order and NUL terminate */
> +    order = get_order_from_bytes(conring_size + 1);
> +    buf = alloc_xenheap_pages(order, 0);
> +    if ( buf == NULL )
> +    {
> +        printk("unable to allocate memory!\n");
> +        return;
> +    }
> +
> +    c = conringc;
> +    sofar = 0;
> +    while ( (c != conringp) )
> +    {
> +        idx = CONRING_IDX_MASK(c);
> +        len = conringp - c;
> +        if ( (idx + len) > conring_size )
> +            len = conring_size - idx;
> +        memcpy(buf + sofar, &conring[idx], len);
> +        sofar += len;
> +        c += len;
> +    }
> +    buf[sofar] = '\0';
> +
> +    sercon_puts(buf);
> +    vga_puts(buf);
> +
> +    free_xenheap_pages(buf, order);
> +}
> +
> +static struct keyhandler dump_console_ring_keyhandler = {
> +    .u.fn = dump_console_ring_key,
> +    .desc = "synchronously dump console ring buffer (dmesg)"
> +};
> +
>  /* CTRL-<switch_char> switches input direction between Xen and DOM0. */
>  #define switch_code (opt_conswitch[0]-'a'+1)
>  static int __read_mostly xen_rx = 1; /* FALSE => serial input passed to
> domain 0. */
> @@ -661,6 +704,8 @@ void __init console_endboot(void)
>      if ( opt_conswitch[1] == 'x' )
>          xen_rx = !xen_rx;
>  
> +    register_keyhandler('w', &dump_console_ring_keyhandler);
> +
>      /* Serial input is directed to DOM0 by default. */
>      switch_serial_input();
>  }



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Sep 29 08:09:22 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 29 Sep 2012 08:09:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1THs6T-00061K-Rr; Sat, 29 Sep 2012 08:08:49 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olivier.hanesse@gmail.com>) id 1THs6S-00061B-Qc
	for xen-devel@lists.xensource.com; Sat, 29 Sep 2012 08:08:49 +0000
Received: from [85.158.138.51:22366] by server-13.bemta-3.messagelabs.com id
	30/7E-11249-F8CA6605; Sat, 29 Sep 2012 08:08:47 +0000
X-Env-Sender: olivier.hanesse@gmail.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1348906125!24499739!1
X-Originating-IP: [209.85.223.171]
X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11546 invoked from network); 29 Sep 2012 08:08:47 -0000
Received: from mail-ie0-f171.google.com (HELO mail-ie0-f171.google.com)
	(209.85.223.171)
	by server-12.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Sep 2012 08:08:47 -0000
Received: by iecs9 with SMTP id s9so11219887iec.30
	for <multiple recipients>; Sat, 29 Sep 2012 01:08:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=/bNPju4pbG3HzClnBKgdV/tm2QvImu5qgALMiQbuQPA=;
	b=jQ2+wmej4/P8PO2/XLyY3elQRjiYH8LMDCXdEV7ZLVO/Sf3G5MZ3RIVaIFZmZQZOZX
	lQG0m7GA0oJeHmwDoNInrW6t4J3rjDdwPPfiIeZ9ovv8If6ZKGxJJ2kLLsXgJ0yIVwJk
	l3MeL6Vt6TxJb6WGSAfriwV/YxBj987/R4bJvn8gr4X+SVMh4QbMWIsUNb9uMQy+xYb0
	3o3tivaQVJ9pjex1++1KViiq4LiwGWHtJe5qbDGMsIVUOfzXOGut1zIZ2C32hoN+R9Qp
	b0NU/T5XuwN6QC3WAj8GuJ9RTT0+9Kv0rl4ong0zEKeay/L1xmn/SqF9D88a7L/YuyGB
	6bRw==
MIME-Version: 1.0
Received: by 10.50.104.137 with SMTP id ge9mr870235igb.17.1348906125215; Sat,
	29 Sep 2012 01:08:45 -0700 (PDT)
Received: by 10.64.20.76 with HTTP; Sat, 29 Sep 2012 01:08:45 -0700 (PDT)
In-Reply-To: <CAE17a0VkMuUEG9VaM7AFrwcsEjVBq9RfvTWz1_KmscAyCxeAbA@mail.gmail.com>
References: <68c41dd8-9195-41b0-83d7-9242b8eff809@default>
	<AANLkTi=NFebVsnj_09+SpCZUo_bNTnTyJLAoR5sfbwZa@mail.gmail.com>
	<AANLkTikptc2POrKQgJuoVZRdwJTo64DJ_hm12KuPky4D@mail.gmail.com>
	<b1ca6ddc-ca69-447e-93e9-8d36d1ff4a43@default>
	<AANLkTinK94GDOF_GeaVs50wK0u8EdZ2rtzPuh65ca8qR@mail.gmail.com>
	<CAE17a0UPyzsNn=ps9MxarkGg=ns8dCpVz0qBDvesT2AOskwfVg@mail.gmail.com>
	<65395f62-74e5-4910-b701-8df629c2ce3b@default>
	<CABx4GKrQxOOQo_uUXSFvy0nzdMp1A_qc=_e4K+88GkB7xv=9nw@mail.gmail.com>
	<CAE17a0VkMuUEG9VaM7AFrwcsEjVBq9RfvTWz1_KmscAyCxeAbA@mail.gmail.com>
Date: Sat, 29 Sep 2012 10:08:45 +0200
Message-ID: <CABx4GKqrTEV7CEnAVUfYr-+yky8N5P1U29xDbrESH-mHB0iZhQ@mail.gmail.com>
From: Olivier Hanesse <olivier.hanesse@gmail.com>
To: Mauro <mrsanna1@gmail.com>
Cc: Dan Magenheimer <dan.magenheimer@oracle.com>, xen-devel@lists.xensource.com,
	Keir Fraser <keir@xen.org>, Jeremy Fitzhardinge <jeremy@goop.org>,
	Keir Fraser <keir.xen@gmail.com>,
	Xen Users <xen-users@lists.xensource.com>,
	Mark Adams <mark@campbell-lange.net>
Subject: Re: [Xen-devel] [Xen-users] Re:  Xen 4 TSC problems
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0135414908100069518=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============0135414908100069518==
Content-Type: multipart/alternative; boundary=e89a8f23585f6dc74e04cad2ae5f

--e89a8f23585f6dc74e04cad2ae5f
Content-Type: text/plain; charset=ISO-8859-1

It didn't work for me :(
clocksource=pit made another "time jump" (don't remember how much, but it
was worst than 50min)

2012/9/27 Mauro <mrsanna1@gmail.com>

> On 27 September 2012 23:28, Olivier Hanesse <olivier.hanesse@gmail.com>
> wrote:
> > Hello,
> >
> > From my point of view, this was a kind of xen hardware
> "incompatibility/bug"
> > : I was able to reproduce this bug on more than 50 identical servers, but
> > not on another farm of servers with a different hardware.
> > Xen version, Debian Kernel was exactly the same on both farm.
>
> Yes I think so.
> The problem is where I use debian squeeze with xen 4.0.
> In another server with the same hardware but with debian lenny and xen
> 3.0 I have no problems.
> I've read that a workaround is to set clocksource=pit on the xen boot
> line in the grub conf, I hope this works because I can't change hardware.
>

--e89a8f23585f6dc74e04cad2ae5f
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

It didn&#39;t work for me :(<div>clocksource=3Dpit made another &quot;time =
jump&quot; (don&#39;t remember how much, but it was worst than 50min)<br><b=
r><div class=3D"gmail_quote">2012/9/27 Mauro <span dir=3D"ltr">&lt;<a href=
=3D"mailto:mrsanna1@gmail.com" target=3D"_blank">mrsanna1@gmail.com</a>&gt;=
</span><br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div class=3D"im">On 27 September 2012 23:28=
, Olivier Hanesse &lt;<a href=3D"mailto:olivier.hanesse@gmail.com">olivier.=
hanesse@gmail.com</a>&gt; wrote:<br>

</div><div class=3D"im">&gt; Hello,<br>
&gt;<br>
&gt; From my point of view, this was a kind of xen hardware &quot;incompati=
bility/bug&quot;<br>
&gt; : I was able to reproduce this bug on more than 50 identical servers, =
but<br>
&gt; not on another farm of servers with a different hardware.<br>
&gt; Xen version, Debian Kernel was exactly the same on both farm.<br>
<br>
</div><div class=3D"im">Yes I think so.<br>
The problem is where I use debian squeeze with xen 4.0.<br>
In another server with the same hardware but with debian lenny and xen<br>
3.0 I have no problems.<br>
I&#39;ve read that a workaround is to set clocksource=3Dpit on the xen boot=
<br>
</div>line in the grub conf, I hope this works because I can&#39;t change h=
ardware.<br>
</blockquote></div><br></div>

--e89a8f23585f6dc74e04cad2ae5f--


--===============0135414908100069518==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============0135414908100069518==--


From xen-devel-bounces@lists.xen.org Sat Sep 29 08:09:22 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 29 Sep 2012 08:09:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1THs6T-00061K-Rr; Sat, 29 Sep 2012 08:08:49 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olivier.hanesse@gmail.com>) id 1THs6S-00061B-Qc
	for xen-devel@lists.xensource.com; Sat, 29 Sep 2012 08:08:49 +0000
Received: from [85.158.138.51:22366] by server-13.bemta-3.messagelabs.com id
	30/7E-11249-F8CA6605; Sat, 29 Sep 2012 08:08:47 +0000
X-Env-Sender: olivier.hanesse@gmail.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1348906125!24499739!1
X-Originating-IP: [209.85.223.171]
X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11546 invoked from network); 29 Sep 2012 08:08:47 -0000
Received: from mail-ie0-f171.google.com (HELO mail-ie0-f171.google.com)
	(209.85.223.171)
	by server-12.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Sep 2012 08:08:47 -0000
Received: by iecs9 with SMTP id s9so11219887iec.30
	for <multiple recipients>; Sat, 29 Sep 2012 01:08:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=/bNPju4pbG3HzClnBKgdV/tm2QvImu5qgALMiQbuQPA=;
	b=jQ2+wmej4/P8PO2/XLyY3elQRjiYH8LMDCXdEV7ZLVO/Sf3G5MZ3RIVaIFZmZQZOZX
	lQG0m7GA0oJeHmwDoNInrW6t4J3rjDdwPPfiIeZ9ovv8If6ZKGxJJ2kLLsXgJ0yIVwJk
	l3MeL6Vt6TxJb6WGSAfriwV/YxBj987/R4bJvn8gr4X+SVMh4QbMWIsUNb9uMQy+xYb0
	3o3tivaQVJ9pjex1++1KViiq4LiwGWHtJe5qbDGMsIVUOfzXOGut1zIZ2C32hoN+R9Qp
	b0NU/T5XuwN6QC3WAj8GuJ9RTT0+9Kv0rl4ong0zEKeay/L1xmn/SqF9D88a7L/YuyGB
	6bRw==
MIME-Version: 1.0
Received: by 10.50.104.137 with SMTP id ge9mr870235igb.17.1348906125215; Sat,
	29 Sep 2012 01:08:45 -0700 (PDT)
Received: by 10.64.20.76 with HTTP; Sat, 29 Sep 2012 01:08:45 -0700 (PDT)
In-Reply-To: <CAE17a0VkMuUEG9VaM7AFrwcsEjVBq9RfvTWz1_KmscAyCxeAbA@mail.gmail.com>
References: <68c41dd8-9195-41b0-83d7-9242b8eff809@default>
	<AANLkTi=NFebVsnj_09+SpCZUo_bNTnTyJLAoR5sfbwZa@mail.gmail.com>
	<AANLkTikptc2POrKQgJuoVZRdwJTo64DJ_hm12KuPky4D@mail.gmail.com>
	<b1ca6ddc-ca69-447e-93e9-8d36d1ff4a43@default>
	<AANLkTinK94GDOF_GeaVs50wK0u8EdZ2rtzPuh65ca8qR@mail.gmail.com>
	<CAE17a0UPyzsNn=ps9MxarkGg=ns8dCpVz0qBDvesT2AOskwfVg@mail.gmail.com>
	<65395f62-74e5-4910-b701-8df629c2ce3b@default>
	<CABx4GKrQxOOQo_uUXSFvy0nzdMp1A_qc=_e4K+88GkB7xv=9nw@mail.gmail.com>
	<CAE17a0VkMuUEG9VaM7AFrwcsEjVBq9RfvTWz1_KmscAyCxeAbA@mail.gmail.com>
Date: Sat, 29 Sep 2012 10:08:45 +0200
Message-ID: <CABx4GKqrTEV7CEnAVUfYr-+yky8N5P1U29xDbrESH-mHB0iZhQ@mail.gmail.com>
From: Olivier Hanesse <olivier.hanesse@gmail.com>
To: Mauro <mrsanna1@gmail.com>
Cc: Dan Magenheimer <dan.magenheimer@oracle.com>, xen-devel@lists.xensource.com,
	Keir Fraser <keir@xen.org>, Jeremy Fitzhardinge <jeremy@goop.org>,
	Keir Fraser <keir.xen@gmail.com>,
	Xen Users <xen-users@lists.xensource.com>,
	Mark Adams <mark@campbell-lange.net>
Subject: Re: [Xen-devel] [Xen-users] Re:  Xen 4 TSC problems
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0135414908100069518=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============0135414908100069518==
Content-Type: multipart/alternative; boundary=e89a8f23585f6dc74e04cad2ae5f

--e89a8f23585f6dc74e04cad2ae5f
Content-Type: text/plain; charset=ISO-8859-1

It didn't work for me :(
clocksource=pit made another "time jump" (don't remember how much, but it
was worst than 50min)

2012/9/27 Mauro <mrsanna1@gmail.com>

> On 27 September 2012 23:28, Olivier Hanesse <olivier.hanesse@gmail.com>
> wrote:
> > Hello,
> >
> > From my point of view, this was a kind of xen hardware
> "incompatibility/bug"
> > : I was able to reproduce this bug on more than 50 identical servers, but
> > not on another farm of servers with a different hardware.
> > Xen version, Debian Kernel was exactly the same on both farm.
>
> Yes I think so.
> The problem is where I use debian squeeze with xen 4.0.
> In another server with the same hardware but with debian lenny and xen
> 3.0 I have no problems.
> I've read that a workaround is to set clocksource=pit on the xen boot
> line in the grub conf, I hope this works because I can't change hardware.
>

--e89a8f23585f6dc74e04cad2ae5f
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

It didn&#39;t work for me :(<div>clocksource=3Dpit made another &quot;time =
jump&quot; (don&#39;t remember how much, but it was worst than 50min)<br><b=
r><div class=3D"gmail_quote">2012/9/27 Mauro <span dir=3D"ltr">&lt;<a href=
=3D"mailto:mrsanna1@gmail.com" target=3D"_blank">mrsanna1@gmail.com</a>&gt;=
</span><br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div class=3D"im">On 27 September 2012 23:28=
, Olivier Hanesse &lt;<a href=3D"mailto:olivier.hanesse@gmail.com">olivier.=
hanesse@gmail.com</a>&gt; wrote:<br>

</div><div class=3D"im">&gt; Hello,<br>
&gt;<br>
&gt; From my point of view, this was a kind of xen hardware &quot;incompati=
bility/bug&quot;<br>
&gt; : I was able to reproduce this bug on more than 50 identical servers, =
but<br>
&gt; not on another farm of servers with a different hardware.<br>
&gt; Xen version, Debian Kernel was exactly the same on both farm.<br>
<br>
</div><div class=3D"im">Yes I think so.<br>
The problem is where I use debian squeeze with xen 4.0.<br>
In another server with the same hardware but with debian lenny and xen<br>
3.0 I have no problems.<br>
I&#39;ve read that a workaround is to set clocksource=3Dpit on the xen boot=
<br>
</div>line in the grub conf, I hope this works because I can&#39;t change h=
ardware.<br>
</blockquote></div><br></div>

--e89a8f23585f6dc74e04cad2ae5f--


--===============0135414908100069518==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============0135414908100069518==--


From xen-devel-bounces@lists.xen.org Sat Sep 29 13:36:23 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 29 Sep 2012 13:36:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1THxCp-00088x-MS; Sat, 29 Sep 2012 13:35:43 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <singapore.mr.teo.en.ming@gmail.com>)
	id 1THxCo-00088o-0k
	for xen-devel@lists.xen.org; Sat, 29 Sep 2012 13:35:42 +0000
Received: from [85.158.139.83:26977] by server-6.bemta-5.messagelabs.com id
	FA/6B-14717-D29F6605; Sat, 29 Sep 2012 13:35:41 +0000
X-Env-Sender: singapore.mr.teo.en.ming@gmail.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1348925737!28139902!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-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2075 invoked from network); 29 Sep 2012 13:35:39 -0000
Received: from mail-pb0-f45.google.com (HELO mail-pb0-f45.google.com)
	(209.85.160.45)
	by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Sep 2012 13:35:39 -0000
Received: by pbbrp2 with SMTP id rp2so6423640pbb.32
	for <multiple recipients>; Sat, 29 Sep 2012 06:35:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=message-id:disposition-notification-to:date:from:user-agent
	:mime-version:to:subject:content-type:content-transfer-encoding;
	bh=roq+N0SaNSCE4iHI+O8aEU6GO7nWvPPVS6aptdRFR4c=;
	b=bmZeYZnP8aiSQoa510kkAxRi0iXhgcmF4OpcURuFn8sSP4texx6q9hDuLCLKL7jjOM
	tiyQoA5LuVfH/RbT6hg3sUHvDFbnGq4qhwTQVVpFTPu+yEJUb2swWfM/JPdy/5CZ5xdO
	LHuUd+WLrwxLqoJupTwfi/F5L6/ATvXoSMuyW13ILC0ocPRVRYHlaXN9UGmeJj4EHQJD
	g+7Sw133m3pDm248IVdVTA/uek98nC8eWs6YsD8oFA4B7iSqq0w51N7F1Ro9dPYkqUCm
	HTuWDj6iEJpaGzeH/jnPEj0liKN2NGgbTmsmRVrPLI3KwJXDK6U+Qfjw6eH+/OJEceXS
	fcdA==
Received: by 10.66.88.198 with SMTP id bi6mr24575918pab.23.1348925734243;
	Sat, 29 Sep 2012 06:35:34 -0700 (PDT)
Received: from [192.168.1.2] (cm152.gamma205.maxonline.com.sg.
	[202.156.205.152])
	by mx.google.com with ESMTPS id qa4sm7228355pbb.70.2012.09.29.06.35.31
	(version=SSLv3 cipher=OTHER); Sat, 29 Sep 2012 06:35:33 -0700 (PDT)
Message-ID: <5066F922.1090305@gmail.com>
Date: Sat, 29 Sep 2012 21:35:30 +0800
From: "Teo En Ming (Zhang Enming)" <singapore.mr.teo.en.ming@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120912 Thunderbird/15.0.1
MIME-Version: 1.0
To: "xen-users@lists.xen.org" <xen-users@lists.xen.org>, 
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	"Teo En Ming (Zhang Enming)" <singapore.mr.teo.en.ming@gmail.com>
Subject: [Xen-devel] Unable to start Windows 8 HVM guest with Xen VGA
 Passthrough with Xen 4.2.1-pre
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
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,

I have applied Xen VGA passthrough patches from David Techer's personal 
website to Xen 4.2.1-pre source tree. Everything compiled and installed 
smoothly. But when I tried to start Windows 8 HVM domU with VGA 
passthrough, it gave me the following error:

xc: error: unable to allocate memory to the HVM guest. (16: device or 
resource busy): Internal error.

There are no issues with Xen 4.2-unstable changeset 25099 however.

-- 
Yours sincerely,

Mr. Teo En Ming (Zhang Enming)
Singapore


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Sep 29 13:36:23 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 29 Sep 2012 13:36:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1THxCp-00088x-MS; Sat, 29 Sep 2012 13:35:43 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <singapore.mr.teo.en.ming@gmail.com>)
	id 1THxCo-00088o-0k
	for xen-devel@lists.xen.org; Sat, 29 Sep 2012 13:35:42 +0000
Received: from [85.158.139.83:26977] by server-6.bemta-5.messagelabs.com id
	FA/6B-14717-D29F6605; Sat, 29 Sep 2012 13:35:41 +0000
X-Env-Sender: singapore.mr.teo.en.ming@gmail.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1348925737!28139902!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-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2075 invoked from network); 29 Sep 2012 13:35:39 -0000
Received: from mail-pb0-f45.google.com (HELO mail-pb0-f45.google.com)
	(209.85.160.45)
	by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Sep 2012 13:35:39 -0000
Received: by pbbrp2 with SMTP id rp2so6423640pbb.32
	for <multiple recipients>; Sat, 29 Sep 2012 06:35:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=message-id:disposition-notification-to:date:from:user-agent
	:mime-version:to:subject:content-type:content-transfer-encoding;
	bh=roq+N0SaNSCE4iHI+O8aEU6GO7nWvPPVS6aptdRFR4c=;
	b=bmZeYZnP8aiSQoa510kkAxRi0iXhgcmF4OpcURuFn8sSP4texx6q9hDuLCLKL7jjOM
	tiyQoA5LuVfH/RbT6hg3sUHvDFbnGq4qhwTQVVpFTPu+yEJUb2swWfM/JPdy/5CZ5xdO
	LHuUd+WLrwxLqoJupTwfi/F5L6/ATvXoSMuyW13ILC0ocPRVRYHlaXN9UGmeJj4EHQJD
	g+7Sw133m3pDm248IVdVTA/uek98nC8eWs6YsD8oFA4B7iSqq0w51N7F1Ro9dPYkqUCm
	HTuWDj6iEJpaGzeH/jnPEj0liKN2NGgbTmsmRVrPLI3KwJXDK6U+Qfjw6eH+/OJEceXS
	fcdA==
Received: by 10.66.88.198 with SMTP id bi6mr24575918pab.23.1348925734243;
	Sat, 29 Sep 2012 06:35:34 -0700 (PDT)
Received: from [192.168.1.2] (cm152.gamma205.maxonline.com.sg.
	[202.156.205.152])
	by mx.google.com with ESMTPS id qa4sm7228355pbb.70.2012.09.29.06.35.31
	(version=SSLv3 cipher=OTHER); Sat, 29 Sep 2012 06:35:33 -0700 (PDT)
Message-ID: <5066F922.1090305@gmail.com>
Date: Sat, 29 Sep 2012 21:35:30 +0800
From: "Teo En Ming (Zhang Enming)" <singapore.mr.teo.en.ming@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120912 Thunderbird/15.0.1
MIME-Version: 1.0
To: "xen-users@lists.xen.org" <xen-users@lists.xen.org>, 
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	"Teo En Ming (Zhang Enming)" <singapore.mr.teo.en.ming@gmail.com>
Subject: [Xen-devel] Unable to start Windows 8 HVM guest with Xen VGA
 Passthrough with Xen 4.2.1-pre
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
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,

I have applied Xen VGA passthrough patches from David Techer's personal 
website to Xen 4.2.1-pre source tree. Everything compiled and installed 
smoothly. But when I tried to start Windows 8 HVM domU with VGA 
passthrough, it gave me the following error:

xc: error: unable to allocate memory to the HVM guest. (16: device or 
resource busy): Internal error.

There are no issues with Xen 4.2-unstable changeset 25099 however.

-- 
Yours sincerely,

Mr. Teo En Ming (Zhang Enming)
Singapore


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Sep 29 14:33:10 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 29 Sep 2012 14: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 1THy5v-0000dw-AG; Sat, 29 Sep 2012 14:32:39 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mrsanna1@gmail.com>) id 1THtYM-0006Ms-NC
	for xen-devel@lists.xensource.com; Sat, 29 Sep 2012 09:41:42 +0000
Received: from [85.158.138.51:44184] by server-10.bemta-3.messagelabs.com id
	F7/40-02525-552C6605; Sat, 29 Sep 2012 09:41:41 +0000
X-Env-Sender: mrsanna1@gmail.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1348911700!31931804!1
X-Originating-IP: [209.85.220.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11018 invoked from network); 29 Sep 2012 09:41:41 -0000
Received: from mail-vc0-f171.google.com (HELO mail-vc0-f171.google.com)
	(209.85.220.171)
	by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Sep 2012 09:41:41 -0000
Received: by vcmm18 with SMTP id m18so5282817vcm.30
	for <multiple recipients>; Sat, 29 Sep 2012 02:41:39 -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=QicbjTIQNJAK0q1m/rxd4jUc7f+dM9dwJRBq0N2ZGyg=;
	b=AlrxER6AtkHA+HeAj/1co2DRG/VxlLcyisaVN7fsKZg4C44rkQEHNjff34rqHKW2QD
	XVp8OT8xRbT8cKWaW+p06R1QebGeyIn5JTlrmoX3qKK3555Z5hKjnI29iXg3bL3f8dWy
	HUGKXbNc/D7Qw1Km3jAy50CNXEEXTpmErzpBoTVdDO/TBJtKFq7KkFcrami9CA9wBMek
	wtxp3n3rosWFa47WQf/3ntF5/JDUehoG900E3vuKqfMj9fr3/uitUxsWxJ1mQN8jByrl
	A1j6W64MbJjeDBr8iPd1ogcJiaEULTp4C/XaP76ttP0iR3FxgIjFu+Vw+593Yz+bE5kr
	8QrA==
MIME-Version: 1.0
Received: by 10.58.227.106 with SMTP id rz10mr5631255vec.19.1348911699689;
	Sat, 29 Sep 2012 02:41:39 -0700 (PDT)
Received: by 10.58.207.75 with HTTP; Sat, 29 Sep 2012 02:41:39 -0700 (PDT)
In-Reply-To: <CABx4GKqrTEV7CEnAVUfYr-+yky8N5P1U29xDbrESH-mHB0iZhQ@mail.gmail.com>
References: <68c41dd8-9195-41b0-83d7-9242b8eff809@default>
	<AANLkTi=NFebVsnj_09+SpCZUo_bNTnTyJLAoR5sfbwZa@mail.gmail.com>
	<AANLkTikptc2POrKQgJuoVZRdwJTo64DJ_hm12KuPky4D@mail.gmail.com>
	<b1ca6ddc-ca69-447e-93e9-8d36d1ff4a43@default>
	<AANLkTinK94GDOF_GeaVs50wK0u8EdZ2rtzPuh65ca8qR@mail.gmail.com>
	<CAE17a0UPyzsNn=ps9MxarkGg=ns8dCpVz0qBDvesT2AOskwfVg@mail.gmail.com>
	<65395f62-74e5-4910-b701-8df629c2ce3b@default>
	<CABx4GKrQxOOQo_uUXSFvy0nzdMp1A_qc=_e4K+88GkB7xv=9nw@mail.gmail.com>
	<CAE17a0VkMuUEG9VaM7AFrwcsEjVBq9RfvTWz1_KmscAyCxeAbA@mail.gmail.com>
	<CABx4GKqrTEV7CEnAVUfYr-+yky8N5P1U29xDbrESH-mHB0iZhQ@mail.gmail.com>
Date: Sat, 29 Sep 2012 11:41:39 +0200
Message-ID: <CAE17a0UYwqLxoZaVDgQCvUR2KQK4vvP3bkvsdrwgnsUp33xuNQ@mail.gmail.com>
From: Mauro <mrsanna1@gmail.com>
To: Olivier Hanesse <olivier.hanesse@gmail.com>
X-Mailman-Approved-At: Sat, 29 Sep 2012 14:32:38 +0000
Cc: Dan Magenheimer <dan.magenheimer@oracle.com>, xen-devel@lists.xensource.com,
	Keir Fraser <keir@xen.org>, Jeremy Fitzhardinge <jeremy@goop.org>,
	Keir Fraser <keir.xen@gmail.com>,
	Xen Users <xen-users@lists.xensource.com>,
	Mark Adams <mark@campbell-lange.net>
Subject: Re: [Xen-devel] [Xen-users] Re:  Xen 4 TSC problems
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 29 September 2012 10:08, Olivier Hanesse <olivier.hanesse@gmail.com> wrote:
> It didn't work for me :(
> clocksource=pit made another "time jump" (don't remember how much, but it
> was worst than 50min)

Damn.........so there isn't a solution, it is a huge problem.
What processors do you have?
I have HP Proliant DL580 G5 systems with four quad core Intel(R)
Xeon(R) CPU E7330  @ 2.40GHz and debian linux as s.o.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Sep 29 14:33:10 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 29 Sep 2012 14: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 1THy5v-0000dw-AG; Sat, 29 Sep 2012 14:32:39 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mrsanna1@gmail.com>) id 1THtYM-0006Ms-NC
	for xen-devel@lists.xensource.com; Sat, 29 Sep 2012 09:41:42 +0000
Received: from [85.158.138.51:44184] by server-10.bemta-3.messagelabs.com id
	F7/40-02525-552C6605; Sat, 29 Sep 2012 09:41:41 +0000
X-Env-Sender: mrsanna1@gmail.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1348911700!31931804!1
X-Originating-IP: [209.85.220.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11018 invoked from network); 29 Sep 2012 09:41:41 -0000
Received: from mail-vc0-f171.google.com (HELO mail-vc0-f171.google.com)
	(209.85.220.171)
	by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Sep 2012 09:41:41 -0000
Received: by vcmm18 with SMTP id m18so5282817vcm.30
	for <multiple recipients>; Sat, 29 Sep 2012 02:41:39 -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=QicbjTIQNJAK0q1m/rxd4jUc7f+dM9dwJRBq0N2ZGyg=;
	b=AlrxER6AtkHA+HeAj/1co2DRG/VxlLcyisaVN7fsKZg4C44rkQEHNjff34rqHKW2QD
	XVp8OT8xRbT8cKWaW+p06R1QebGeyIn5JTlrmoX3qKK3555Z5hKjnI29iXg3bL3f8dWy
	HUGKXbNc/D7Qw1Km3jAy50CNXEEXTpmErzpBoTVdDO/TBJtKFq7KkFcrami9CA9wBMek
	wtxp3n3rosWFa47WQf/3ntF5/JDUehoG900E3vuKqfMj9fr3/uitUxsWxJ1mQN8jByrl
	A1j6W64MbJjeDBr8iPd1ogcJiaEULTp4C/XaP76ttP0iR3FxgIjFu+Vw+593Yz+bE5kr
	8QrA==
MIME-Version: 1.0
Received: by 10.58.227.106 with SMTP id rz10mr5631255vec.19.1348911699689;
	Sat, 29 Sep 2012 02:41:39 -0700 (PDT)
Received: by 10.58.207.75 with HTTP; Sat, 29 Sep 2012 02:41:39 -0700 (PDT)
In-Reply-To: <CABx4GKqrTEV7CEnAVUfYr-+yky8N5P1U29xDbrESH-mHB0iZhQ@mail.gmail.com>
References: <68c41dd8-9195-41b0-83d7-9242b8eff809@default>
	<AANLkTi=NFebVsnj_09+SpCZUo_bNTnTyJLAoR5sfbwZa@mail.gmail.com>
	<AANLkTikptc2POrKQgJuoVZRdwJTo64DJ_hm12KuPky4D@mail.gmail.com>
	<b1ca6ddc-ca69-447e-93e9-8d36d1ff4a43@default>
	<AANLkTinK94GDOF_GeaVs50wK0u8EdZ2rtzPuh65ca8qR@mail.gmail.com>
	<CAE17a0UPyzsNn=ps9MxarkGg=ns8dCpVz0qBDvesT2AOskwfVg@mail.gmail.com>
	<65395f62-74e5-4910-b701-8df629c2ce3b@default>
	<CABx4GKrQxOOQo_uUXSFvy0nzdMp1A_qc=_e4K+88GkB7xv=9nw@mail.gmail.com>
	<CAE17a0VkMuUEG9VaM7AFrwcsEjVBq9RfvTWz1_KmscAyCxeAbA@mail.gmail.com>
	<CABx4GKqrTEV7CEnAVUfYr-+yky8N5P1U29xDbrESH-mHB0iZhQ@mail.gmail.com>
Date: Sat, 29 Sep 2012 11:41:39 +0200
Message-ID: <CAE17a0UYwqLxoZaVDgQCvUR2KQK4vvP3bkvsdrwgnsUp33xuNQ@mail.gmail.com>
From: Mauro <mrsanna1@gmail.com>
To: Olivier Hanesse <olivier.hanesse@gmail.com>
X-Mailman-Approved-At: Sat, 29 Sep 2012 14:32:38 +0000
Cc: Dan Magenheimer <dan.magenheimer@oracle.com>, xen-devel@lists.xensource.com,
	Keir Fraser <keir@xen.org>, Jeremy Fitzhardinge <jeremy@goop.org>,
	Keir Fraser <keir.xen@gmail.com>,
	Xen Users <xen-users@lists.xensource.com>,
	Mark Adams <mark@campbell-lange.net>
Subject: Re: [Xen-devel] [Xen-users] Re:  Xen 4 TSC problems
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 29 September 2012 10:08, Olivier Hanesse <olivier.hanesse@gmail.com> wrote:
> It didn't work for me :(
> clocksource=pit made another "time jump" (don't remember how much, but it
> was worst than 50min)

Damn.........so there isn't a solution, it is a huge problem.
What processors do you have?
I have HP Proliant DL580 G5 systems with four quad core Intel(R)
Xeon(R) CPU E7330  @ 2.40GHz and debian linux as s.o.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Sep 29 14:33:10 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 29 Sep 2012 14: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 1THy5v-0000e3-LH; Sat, 29 Sep 2012 14:32:39 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mrsanna1@gmail.com>) id 1THw1W-0007dl-Mt
	for xen-devel@lists.xensource.com; Sat, 29 Sep 2012 12:19:58 +0000
Received: from [85.158.138.51:48755] by server-16.bemta-3.messagelabs.com id
	2E/AF-09129-D67E6605; Sat, 29 Sep 2012 12:19:57 +0000
X-Env-Sender: mrsanna1@gmail.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1348921195!32359377!1
X-Originating-IP: [209.85.212.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7950 invoked from network); 29 Sep 2012 12:19:57 -0000
Received: from mail-vb0-f43.google.com (HELO mail-vb0-f43.google.com)
	(209.85.212.43)
	by server-16.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Sep 2012 12:19:57 -0000
Received: by vbbfq11 with SMTP id fq11so5026147vbb.30
	for <multiple recipients>; Sat, 29 Sep 2012 05:19:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=YrmqiR55CdaXWRvdqqPIsgslyhll5oJC550N1f7rV+o=;
	b=tWDjfZH51UPe/Ys9JDbIFSiQrvnZ0Dfvipp+2UV6eeX5e+PnudWuO0L6LLkzIxxgMs
	DnHz98WmgTFKzp1qsy0ChpsVt8c4aJrSJW5bQzwkCPu2hBofbnxi0FN7bRyEb7P6AL2Z
	f9B4P25fGfYmuRZkbMoDFoLkM6nqSal8Wycc61m0YnP+7+wNVFgYtMqIb2C0/+/dJDat
	OvZqE7dkktO2zhEyf9YnuElu9WvCwIC7ge0AXKc9igtDcmmw101OmjL/Fv6+Xc99Lk+h
	WKvlE7VN/ZCKvu0DVmx1Eb3hr+v6RXLgoNPR/57LyVzx3FS5jgCQcrLnro86Qm1+spl3
	BsLA==
MIME-Version: 1.0
Received: by 10.220.223.3 with SMTP id ii3mr5508109vcb.74.1348921195486; Sat,
	29 Sep 2012 05:19:55 -0700 (PDT)
Received: by 10.58.207.75 with HTTP; Sat, 29 Sep 2012 05:19:55 -0700 (PDT)
In-Reply-To: <CAE17a0UYwqLxoZaVDgQCvUR2KQK4vvP3bkvsdrwgnsUp33xuNQ@mail.gmail.com>
References: <68c41dd8-9195-41b0-83d7-9242b8eff809@default>
	<AANLkTi=NFebVsnj_09+SpCZUo_bNTnTyJLAoR5sfbwZa@mail.gmail.com>
	<AANLkTikptc2POrKQgJuoVZRdwJTo64DJ_hm12KuPky4D@mail.gmail.com>
	<b1ca6ddc-ca69-447e-93e9-8d36d1ff4a43@default>
	<AANLkTinK94GDOF_GeaVs50wK0u8EdZ2rtzPuh65ca8qR@mail.gmail.com>
	<CAE17a0UPyzsNn=ps9MxarkGg=ns8dCpVz0qBDvesT2AOskwfVg@mail.gmail.com>
	<65395f62-74e5-4910-b701-8df629c2ce3b@default>
	<CABx4GKrQxOOQo_uUXSFvy0nzdMp1A_qc=_e4K+88GkB7xv=9nw@mail.gmail.com>
	<CAE17a0VkMuUEG9VaM7AFrwcsEjVBq9RfvTWz1_KmscAyCxeAbA@mail.gmail.com>
	<CABx4GKqrTEV7CEnAVUfYr-+yky8N5P1U29xDbrESH-mHB0iZhQ@mail.gmail.com>
	<CAE17a0UYwqLxoZaVDgQCvUR2KQK4vvP3bkvsdrwgnsUp33xuNQ@mail.gmail.com>
Date: Sat, 29 Sep 2012 14:19:55 +0200
Message-ID: <CAE17a0UQocJjZc38c2805uYvdwR7e447UGH9ywcxMw1Ge3imfg@mail.gmail.com>
From: Mauro <mrsanna1@gmail.com>
To: Olivier Hanesse <olivier.hanesse@gmail.com>
X-Mailman-Approved-At: Sat, 29 Sep 2012 14:32:38 +0000
Cc: Dan Magenheimer <dan.magenheimer@oracle.com>, xen-devel@lists.xensource.com,
	Keir Fraser <keir@xen.org>, Jeremy Fitzhardinge <jeremy@goop.org>,
	Keir Fraser <keir.xen@gmail.com>,
	Xen Users <xen-users@lists.xensource.com>,
	Mark Adams <mark@campbell-lange.net>
Subject: Re: [Xen-devel] [Xen-users] Re:  Xen 4 TSC problems
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

It's happened another time, system date 50 minutes ahead.
There is really no solution?

root@xen-p02:~# date
sab 29 set 2012, 15.06.25, CEST

root@xen-p02:~# hwclock --debug
hwclock from util-linux-ng 2.17.2
Using /dev interface to clock.
Last drift adjustment done at 1348816781 seconds after 1969
Last calibration done at 1348816781 seconds after 1969
Hardware clock is on UTC time
Assuming hardware clock is kept in UTC time.
Waiting for clock tick...
...got clock tick
Time read from Hardware Clock: 2012/09/29 12:16:58
Hw clock time : 2012/09/29 12:16:58 = 1348921018 seconds since 1969
sab 29 set 2012 14:16:58 CEST  -0.751536 seconds

root@xen-p02:~# hwclock --show
sab 29 set 2012 14:17:12 CEST  -0.423643 seconds

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Sep 29 14:33:10 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 29 Sep 2012 14: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 1THy5v-0000e3-LH; Sat, 29 Sep 2012 14:32:39 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mrsanna1@gmail.com>) id 1THw1W-0007dl-Mt
	for xen-devel@lists.xensource.com; Sat, 29 Sep 2012 12:19:58 +0000
Received: from [85.158.138.51:48755] by server-16.bemta-3.messagelabs.com id
	2E/AF-09129-D67E6605; Sat, 29 Sep 2012 12:19:57 +0000
X-Env-Sender: mrsanna1@gmail.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1348921195!32359377!1
X-Originating-IP: [209.85.212.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7950 invoked from network); 29 Sep 2012 12:19:57 -0000
Received: from mail-vb0-f43.google.com (HELO mail-vb0-f43.google.com)
	(209.85.212.43)
	by server-16.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Sep 2012 12:19:57 -0000
Received: by vbbfq11 with SMTP id fq11so5026147vbb.30
	for <multiple recipients>; Sat, 29 Sep 2012 05:19:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=YrmqiR55CdaXWRvdqqPIsgslyhll5oJC550N1f7rV+o=;
	b=tWDjfZH51UPe/Ys9JDbIFSiQrvnZ0Dfvipp+2UV6eeX5e+PnudWuO0L6LLkzIxxgMs
	DnHz98WmgTFKzp1qsy0ChpsVt8c4aJrSJW5bQzwkCPu2hBofbnxi0FN7bRyEb7P6AL2Z
	f9B4P25fGfYmuRZkbMoDFoLkM6nqSal8Wycc61m0YnP+7+wNVFgYtMqIb2C0/+/dJDat
	OvZqE7dkktO2zhEyf9YnuElu9WvCwIC7ge0AXKc9igtDcmmw101OmjL/Fv6+Xc99Lk+h
	WKvlE7VN/ZCKvu0DVmx1Eb3hr+v6RXLgoNPR/57LyVzx3FS5jgCQcrLnro86Qm1+spl3
	BsLA==
MIME-Version: 1.0
Received: by 10.220.223.3 with SMTP id ii3mr5508109vcb.74.1348921195486; Sat,
	29 Sep 2012 05:19:55 -0700 (PDT)
Received: by 10.58.207.75 with HTTP; Sat, 29 Sep 2012 05:19:55 -0700 (PDT)
In-Reply-To: <CAE17a0UYwqLxoZaVDgQCvUR2KQK4vvP3bkvsdrwgnsUp33xuNQ@mail.gmail.com>
References: <68c41dd8-9195-41b0-83d7-9242b8eff809@default>
	<AANLkTi=NFebVsnj_09+SpCZUo_bNTnTyJLAoR5sfbwZa@mail.gmail.com>
	<AANLkTikptc2POrKQgJuoVZRdwJTo64DJ_hm12KuPky4D@mail.gmail.com>
	<b1ca6ddc-ca69-447e-93e9-8d36d1ff4a43@default>
	<AANLkTinK94GDOF_GeaVs50wK0u8EdZ2rtzPuh65ca8qR@mail.gmail.com>
	<CAE17a0UPyzsNn=ps9MxarkGg=ns8dCpVz0qBDvesT2AOskwfVg@mail.gmail.com>
	<65395f62-74e5-4910-b701-8df629c2ce3b@default>
	<CABx4GKrQxOOQo_uUXSFvy0nzdMp1A_qc=_e4K+88GkB7xv=9nw@mail.gmail.com>
	<CAE17a0VkMuUEG9VaM7AFrwcsEjVBq9RfvTWz1_KmscAyCxeAbA@mail.gmail.com>
	<CABx4GKqrTEV7CEnAVUfYr-+yky8N5P1U29xDbrESH-mHB0iZhQ@mail.gmail.com>
	<CAE17a0UYwqLxoZaVDgQCvUR2KQK4vvP3bkvsdrwgnsUp33xuNQ@mail.gmail.com>
Date: Sat, 29 Sep 2012 14:19:55 +0200
Message-ID: <CAE17a0UQocJjZc38c2805uYvdwR7e447UGH9ywcxMw1Ge3imfg@mail.gmail.com>
From: Mauro <mrsanna1@gmail.com>
To: Olivier Hanesse <olivier.hanesse@gmail.com>
X-Mailman-Approved-At: Sat, 29 Sep 2012 14:32:38 +0000
Cc: Dan Magenheimer <dan.magenheimer@oracle.com>, xen-devel@lists.xensource.com,
	Keir Fraser <keir@xen.org>, Jeremy Fitzhardinge <jeremy@goop.org>,
	Keir Fraser <keir.xen@gmail.com>,
	Xen Users <xen-users@lists.xensource.com>,
	Mark Adams <mark@campbell-lange.net>
Subject: Re: [Xen-devel] [Xen-users] Re:  Xen 4 TSC problems
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

It's happened another time, system date 50 minutes ahead.
There is really no solution?

root@xen-p02:~# date
sab 29 set 2012, 15.06.25, CEST

root@xen-p02:~# hwclock --debug
hwclock from util-linux-ng 2.17.2
Using /dev interface to clock.
Last drift adjustment done at 1348816781 seconds after 1969
Last calibration done at 1348816781 seconds after 1969
Hardware clock is on UTC time
Assuming hardware clock is kept in UTC time.
Waiting for clock tick...
...got clock tick
Time read from Hardware Clock: 2012/09/29 12:16:58
Hw clock time : 2012/09/29 12:16:58 = 1348921018 seconds since 1969
sab 29 set 2012 14:16:58 CEST  -0.751536 seconds

root@xen-p02:~# hwclock --show
sab 29 set 2012 14:17:12 CEST  -0.423643 seconds

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Sep 29 15:17:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 29 Sep 2012 15:17:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1THymb-0001S4-9f; Sat, 29 Sep 2012 15:16:45 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mrsanna1@gmail.com>) id 1THyj9-0001B3-PO
	for xen-devel@lists.xensource.com; Sat, 29 Sep 2012 15:13:12 +0000
Received: from [85.158.143.35:27723] by server-3.bemta-4.messagelabs.com id
	B7/E7-10986-70017605; Sat, 29 Sep 2012 15:13:11 +0000
X-Env-Sender: mrsanna1@gmail.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1348931588!11744757!1
X-Originating-IP: [209.85.220.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27180 invoked from network); 29 Sep 2012 15:13:09 -0000
Received: from mail-vc0-f171.google.com (HELO mail-vc0-f171.google.com)
	(209.85.220.171)
	by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Sep 2012 15:13:09 -0000
Received: by vcmm18 with SMTP id m18so5474568vcm.30
	for <multiple recipients>; Sat, 29 Sep 2012 08:13: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=GJiiKciB+AW37QQALJh016YNCl54lMppdyoHlLSf/tQ=;
	b=JUgB0qFqU0I+knq9Oe3VFqvKiTWGPRoZPQ4eRFHCBH4JvldommXTftJE8BMYFXoUbJ
	+BVssQv2u5R1sPKUOxuca0bCwkKzzanvQb0eKc9K3h2L8urpSp1Xw6VGdPFuSsTgErfZ
	GTKjuOR540yKSP17bl4hQI6n3ulg0BA8x7eLOsTRY3hRmNhJ3l2nzsHVDHb4HjPJHGwr
	+4bHDRNzT/Lrxp9stvVztDWcp0U8UAfhK7+a6PaNqLz03jD1Al/TI9s9bBxAjMzJl463
	gr5VQId+czj+Kc05V+7/qSeapWSC3GzbxLsB9zmS1VK41+snGoOGFQ9sIpaFlBGUxnsd
	UtIA==
MIME-Version: 1.0
Received: by 10.220.205.200 with SMTP id fr8mr5652534vcb.34.1348931588463;
	Sat, 29 Sep 2012 08:13:08 -0700 (PDT)
Received: by 10.58.207.75 with HTTP; Sat, 29 Sep 2012 08:13:08 -0700 (PDT)
In-Reply-To: <C98BB635.13B99%keir.xen@gmail.com>
References: <4D655A39.2040501@gmail.com>
	<C98BB635.13B99%keir.xen@gmail.com>
Date: Sat, 29 Sep 2012 17:13:08 +0200
Message-ID: <CAE17a0X3LqPi0-qyxa1w3zNT_Ux-pSrZNSYyVa_U1XvaVK7WxQ@mail.gmail.com>
From: Mauro <mrsanna1@gmail.com>
To: Keir Fraser <keir.xen@gmail.com>
X-Mailman-Approved-At: Sat, 29 Sep 2012 15:16:44 +0000
Cc: Dan Magenheimer <dan.magenheimer@oracle.com>, xen-devel@lists.xensource.com,
	Jeremy Fitzhardinge <jeremy@goop.org>,
	Olivier Hanesse <olivier.hanesse@gmail.com>,
	Xen Users <xen-users@lists.xensource.com>,
	Mark Adams <mark@campbell-lange.net>
Subject: Re: [Xen-devel] [Xen-users] Re:  Xen 4 TSC problems
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gMjQgRmVicnVhcnkgMjAxMSAwODoxNiwgS2VpciBGcmFzZXIgPGtlaXIueGVuQGdtYWlsLmNv
bT4gd3JvdGU6Cj4gUGxlYXNlIHNlbmQgWGVuIGJvb3Qgb3V0cHV0ICh4bSBkbWVzZykuIEdldHRp
bmcgaXQgZnJvbSBYZW4gMy4yIGFzIHdlbGwKPiB3b3VsZCBiZSBpbnRlcmVzdGluZywgaWYgeW91
IHN0aWxsIGhhdmUgaXQgaW5zdGFsbGVkIG9uIGFueSBvZiB0aGVzZQo+IG1hY2hpbmVzLgoKSWYg
aXQgY2FuIGJlIHVzZWZ1bCBoZXJlIGlzIHhtIGRtZXNmIG9mIHhlbiA0LjAgb24gYSBkZWJpYW4g
c3F1ZWV6ZSBzeXN0ZW06CgooWEVOKSBYZW4gdmVyc2lvbiA0LjAuMSAoRGViaWFuIDQuMC4xLTUu
NCkgKHVsdHJvdHRlckBkZWJpYW4ub3JnKSAoZ2NjCnZlcnNpb24gNC40LjUgKERlYmlhbiA0LjQu
NS04KSApIFNhdCBTZXAgIDggMTk6MTU6NDYgVVRDIDIwMTIKKFhFTikgQm9vdGxvYWRlcjogR1JV
QiAxLjk4KzIwMTAwODA0LTE0K3NxdWVlemUxCihYRU4pIENvbW1hbmQgbGluZTogcGxhY2Vob2xk
ZXIgZG9tMF9tZW09MzA3Mk0gbG9nbHZsPXdhcm5pbmcKZ3Vlc3RfbG9nbHZsPXdhcm5pbmcKKFhF
TikgVmlkZW8gaW5mb3JtYXRpb246CihYRU4pICBWR0EgaXMgdGV4dCBtb2RlIDgweDI1LCBmb250
IDh4MTYKKFhFTikgIFZCRS9EREMgbWV0aG9kczogVjI7IEVESUQgdHJhbnNmZXIgdGltZTogMiBz
ZWNvbmRzCihYRU4pIERpc2MgaW5mb3JtYXRpb246CihYRU4pICBGb3VuZCAyIE1CUiBzaWduYXR1
cmVzCihYRU4pICBGb3VuZCAyIEVERCBpbmZvcm1hdGlvbiBzdHJ1Y3R1cmVzCihYRU4pIFhlbi1l
ODIwIFJBTSBtYXA6CihYRU4pICAwMDAwMDAwMDAwMDAwMDAwIC0gMDAwMDAwMDAwMDA5ZjQwMCAo
dXNhYmxlKQooWEVOKSAgMDAwMDAwMDAwMDA5ZjQwMCAtIDAwMDAwMDAwMDAwYTAwMDAgKHJlc2Vy
dmVkKQooWEVOKSAgMDAwMDAwMDAwMDBmMDAwMCAtIDAwMDAwMDAwMDAxMDAwMDAgKHJlc2VydmVk
KQooWEVOKSAgMDAwMDAwMDAwMDEwMDAwMCAtIDAwMDAwMDAwY2ZkNDMwMDAgKHVzYWJsZSkKKFhF
TikgIDAwMDAwMDAwY2ZkNDMwMDAgLSAwMDAwMDAwMGNmZDRjMDAwIChBQ1BJIGRhdGEpCihYRU4p
ICAwMDAwMDAwMGNmZDRjMDAwIC0gMDAwMDAwMDBjZmQ0ZDAwMCAodXNhYmxlKQooWEVOKSAgMDAw
MDAwMDBjZmQ0ZDAwMCAtIDAwMDAwMDAwZDAwMDAwMDAgKHJlc2VydmVkKQooWEVOKSAgMDAwMDAw
MDBlMDAwMDAwMCAtIDAwMDAwMDAwZjAwMDAwMDAgKHJlc2VydmVkKQooWEVOKSAgMDAwMDAwMDBm
ZWMwMDAwMCAtIDAwMDAwMDAwZmVkMDAwMDAgKHJlc2VydmVkKQooWEVOKSAgMDAwMDAwMDBmZWUw
MDAwMCAtIDAwMDAwMDAwZmVlMTAwMDAgKHJlc2VydmVkKQooWEVOKSAgMDAwMDAwMDBmZmMwMDAw
MCAtIDAwMDAwMDAxMDAwMDAwMDAgKHJlc2VydmVkKQooWEVOKSAgMDAwMDAwMDEwMDAwMDAwMCAt
IDAwMDAwMDEwMmZmZmYwMDAgKHVzYWJsZSkKKFhFTikgQUNQSTogUlNEUCAwMDBGNEYyMCwgMDAy
NCAocjIgSFAgICAgKQooWEVOKSBBQ1BJOiBYU0RUIENGRDQzOTAwLCAwMDdDIChyMSBIUCAgICAg
UHJvTGlhbnQgICAgICAgIDIgICDvv70gICAgIDE2MkUpCihYRU4pIEFDUEk6IEZBQ1AgQ0ZENDM5
QzAsIDAwRjQgKHIzIEhQICAgICBQcm9MaWFudCAgICAgICAgMiAgIO+/vSAgICAgMTYyRSkKKFhF
TikgQUNQSTogRFNEVCBDRkQ0M0FDMCwgMzBDOSAocjEgSFAgICAgICAgICBEU0RUICAgICAgICAx
IElOVEwgMjAwMzAyMjgpCihYRU4pIEFDUEk6IEZBQ1MgQ0ZENDMxMDAsIDAwNDAKKFhFTikgQUNQ
STogU1BDUiBDRkQ0MzE0MCwgMDA1MCAocjEgSFAgICAgIFNQQ1JSQlNVICAgICAgICAxICAg77+9
ICAgICAxNjJFKQooWEVOKSBBQ1BJOiBNQ0ZHIENGRDQzMUMwLCAwMDNDIChyMSBIUCAgICAgUHJv
TGlhbnQgICAgICAgIDEgICAgICAgICAgICAgMCkKKFhFTikgQUNQSTogSFBFVCBDRkQ0MzIwMCwg
MDAzOCAocjEgSFAgICAgIFByb0xpYW50ICAgICAgICAyICAg77+9ICAgICAxNjJFKQooWEVOKSBB
Q1BJOiBGRkZGIENGRDQzMjQwLCAwMDY0IChyMiBIUCAgICAgUDYxICAgICAgICAgICAgIDIgICDv
v70gICAgIDE2MkUpCihYRU4pIEFDUEk6IFNQTUkgQ0ZENDMyQzAsIDAwNDAgKHI1IEhQICAgICBQ
cm9MaWFudCAgICAgICAgMSAgIO+/vSAgICAgMTYyRSkKKFhFTikgQUNQSTogRVJTVCBDRkQ0MzMw
MCwgMDFEMCAocjEgSFAgICAgIFByb0xpYW50ICAgICAgICAxICAg77+9ICAgICAxNjJFKQooWEVO
KSBBQ1BJOiBBUElDIENGRDQzNTAwLCAwMTc2IChyMSBIUCAgICAgUHJvTGlhbnQgICAgICAgIDIg
ICAgICAgICAgICAgMCkKKFhFTikgQUNQSTogRkZGRiBDRkQ0MzY4MCwgMDE3NiAocjEgSFAgICAg
IFByb0xpYW50ICAgICAgICAxICAg77+9ICAgICAxNjJFKQooWEVOKSBBQ1BJOiBCRVJUIENGRDQz
ODAwLCAwMDMwIChyMSBIUCAgICAgUHJvTGlhbnQgICAgICAgIDEgICDvv70gICAgIDE2MkUpCihY
RU4pIEFDUEk6IEhFU1QgQ0ZENDM4NDAsIDAwQkMgKHIxIEhQICAgICBQcm9MaWFudCAgICAgICAg
MSAgIO+/vSAgICAgMTYyRSkKKFhFTikgU3lzdGVtIFJBTTogNjU1MzJNQiAoNjcxMDU2NzJrQikK
KFhFTikgRG9tYWluIGhlYXAgaW5pdGlhbGlzZWQKKFhFTikgUHJvY2Vzc29yICMwIDY6MTUgQVBJ
QyB2ZXJzaW9uIDIwCihYRU4pIFByb2Nlc3NvciAjOCA2OjE1IEFQSUMgdmVyc2lvbiAyMAooWEVO
KSBQcm9jZXNzb3IgIzE2IDY6MTUgQVBJQyB2ZXJzaW9uIDIwCihYRU4pIFByb2Nlc3NvciAjMjQg
NjoxNSBBUElDIHZlcnNpb24gMjAKKFhFTikgUHJvY2Vzc29yICMxIDY6MTUgQVBJQyB2ZXJzaW9u
IDIwCihYRU4pIFByb2Nlc3NvciAjOSA2OjE1IEFQSUMgdmVyc2lvbiAyMAooWEVOKSBQcm9jZXNz
b3IgIzE3IDY6MTUgQVBJQyB2ZXJzaW9uIDIwCihYRU4pIFByb2Nlc3NvciAjMjUgNjoxNSBBUElD
IHZlcnNpb24gMjAKKFhFTikgUHJvY2Vzc29yICMyIDY6MTUgQVBJQyB2ZXJzaW9uIDIwCihYRU4p
IFByb2Nlc3NvciAjMTAgNjoxNSBBUElDIHZlcnNpb24gMjAKKFhFTikgUHJvY2Vzc29yICMxOCA2
OjE1IEFQSUMgdmVyc2lvbiAyMAooWEVOKSBQcm9jZXNzb3IgIzI2IDY6MTUgQVBJQyB2ZXJzaW9u
IDIwCihYRU4pIFByb2Nlc3NvciAjMyA2OjE1IEFQSUMgdmVyc2lvbiAyMAooWEVOKSBQcm9jZXNz
b3IgIzExIDY6MTUgQVBJQyB2ZXJzaW9uIDIwCihYRU4pIFByb2Nlc3NvciAjMTkgNjoxNSBBUElD
IHZlcnNpb24gMjAKKFhFTikgUHJvY2Vzc29yICMyNyA2OjE1IEFQSUMgdmVyc2lvbiAyMAooWEVO
KSBJT0FQSUNbMF06IGFwaWNfaWQgMSwgdmVyc2lvbiAzMiwgYWRkcmVzcyAweGZlYzAwMDAwLCBH
U0kgMC0yMwooWEVOKSBJT0FQSUNbMV06IGFwaWNfaWQgMiwgdmVyc2lvbiAzMiwgYWRkcmVzcyAw
eGZlYzgwMDAwLCBHU0kgMjQtNDcKKFhFTikgSU9BUElDWzJdOiBhcGljX2lkIDMsIHZlcnNpb24g
MzIsIGFkZHJlc3MgMHhmZWM4MTAwMCwgR1NJIDQ4LTcxCihYRU4pIElPQVBJQ1szXTogYXBpY19p
ZCA0LCB2ZXJzaW9uIDMyLCBhZGRyZXNzIDB4ZmVjODE4MDAsIEdTSSA3Mi05NQooWEVOKSBFbmFi
bGluZyBBUElDIG1vZGU6ICBQaHlzLiAgVXNpbmcgNCBJL08gQVBJQ3MKKFhFTikgVXNpbmcgc2No
ZWR1bGVyOiBTTVAgQ3JlZGl0IFNjaGVkdWxlciAoY3JlZGl0KQooWEVOKSBEZXRlY3RlZCAyNDAw
LjE0NSBNSHogcHJvY2Vzc29yLgooWEVOKSBJbml0aW5nIG1lbW9yeSBzaGFyaW5nLgooWEVOKSBW
TVg6IFN1cHBvcnRlZCBhZHZhbmNlZCBmZWF0dXJlczoKKFhFTikgIC0gQVBJQyBNTUlPIGFjY2Vz
cyB2aXJ0dWFsaXNhdGlvbgooWEVOKSAgLSBBUElDIFRQUiBzaGFkb3cKKFhFTikgIC0gVmlydHVh
bCBOTUkKKFhFTikgIC0gTVNSIGRpcmVjdC1hY2Nlc3MgYml0bWFwCihYRU4pIEhWTTogQVNJRHMg
ZGlzYWJsZWQuCihYRU4pIEhWTTogVk1YIGVuYWJsZWQKKFhFTikgSS9PIHZpcnR1YWxpc2F0aW9u
IGRpc2FibGVkCihYRU4pIFRvdGFsIG9mIDE2IHByb2Nlc3NvcnMgYWN0aXZhdGVkLgooWEVOKSBF
TkFCTElORyBJTy1BUElDIElSUXMKKFhFTikgIC0+IFVzaW5nIG5ldyBBQ0sgbWV0aG9kCihYRU4p
IGNoZWNraW5nIFRTQyBzeW5jaHJvbml6YXRpb24gYWNyb3NzIDE2IENQVXM6IHBhc3NlZC4KKFhF
TikgUGxhdGZvcm0gdGltZXIgaXMgMTQuMzE4TUh6IEhQRVQKKFhFTikgQWxsb2NhdGVkIGNvbnNv
bGUgcmluZyBvZiAzMiBLaUIuCihYRU4pIEJyb3VnaHQgdXAgMTYgQ1BVcwooWEVOKSAqKiogTE9B
RElORyBET01BSU4gMCAqKioKKFhFTikgIFhlbiAga2VybmVsOiA2NC1iaXQsIGxzYiwgY29tcGF0
MzIKKFhFTikgIERvbTAga2VybmVsOiA2NC1iaXQsIFBBRSwgbHNiLCBwYWRkciAweDEwMDAwMDAg
LT4gMHgxNzA4MDAwCihYRU4pIFBIWVNJQ0FMIE1FTU9SWSBBUlJBTkdFTUVOVDoKKFhFTikgIERv
bTAgYWxsb2MuOiAgIDAwMDAwMDA4M2MwMDAwMDAtPjAwMDAwMDA4NDAwMDAwMDAgKDc3MDA0OCBw
YWdlcwp0byBiZSBhbGxvY2F0ZWQpCihYRU4pIFZJUlRVQUwgTUVNT1JZIEFSUkFOR0VNRU5UOgoo
WEVOKSAgTG9hZGVkIGtlcm5lbDogZmZmZmZmZmY4MTAwMDAwMC0+ZmZmZmZmZmY4MTcwODAwMAoo
WEVOKSAgSW5pdC4gcmFtZGlzazogZmZmZmZmZmY4MTcwODAwMC0+ZmZmZmZmZmY4MWVmYjAwMAoo
WEVOKSAgUGh5cy1NYWNoIG1hcDogZmZmZmZmZmY4MWVmYjAwMC0+ZmZmZmZmZmY4MjRmYjAwMAoo
WEVOKSAgU3RhcnQgaW5mbzogICAgZmZmZmZmZmY4MjRmYjAwMC0+ZmZmZmZmZmY4MjRmYjRiNAoo
WEVOKSAgUGFnZSB0YWJsZXM6ICAgZmZmZmZmZmY4MjRmYzAwMC0+ZmZmZmZmZmY4MjUxMzAwMAoo
WEVOKSAgQm9vdCBzdGFjazogICAgZmZmZmZmZmY4MjUxMzAwMC0+ZmZmZmZmZmY4MjUxNDAwMAoo
WEVOKSAgVE9UQUw6ICAgICAgICAgZmZmZmZmZmY4MDAwMDAwMC0+ZmZmZmZmZmY4MjgwMDAwMAoo
WEVOKSAgRU5UUlkgQUREUkVTUzogZmZmZmZmZmY4MTUzMTIwMAooWEVOKSBEb20wIGhhcyBtYXhp
bXVtIDE2IFZDUFVzCihYRU4pIFNjcnViYmluZyBGcmVlIFJBTToKLi4uLi4uLi4uLi4uLi4uLi4u
Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u
Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u
Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u
Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u
Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u
Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u
Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u
Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u
Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u
Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u
Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi5kb25lLgooWEVOKSBYZW4gdHJhY2UgYnVmZmVy
czogZGlzYWJsZWQKKFhFTikgU3RkLiBMb2dsZXZlbDogRXJyb3JzIGFuZCB3YXJuaW5ncwooWEVO
KSBHdWVzdCBMb2dsZXZlbDogRXJyb3JzIGFuZCB3YXJuaW5ncwooWEVOKSBYZW4gaXMgcmVsaW5x
dWlzaGluZyBWR0EgY29uc29sZS4KKFhFTikgKioqIFNlcmlhbCBpbnB1dCAtPiBET00wICh0eXBl
ICdDVFJMLWEnIHRocmVlIHRpbWVzIHRvIHN3aXRjaAppbnB1dCB0byBYZW4pCihYRU4pIEZyZWVk
IDE3NmtCIGluaXQgbWVtb3J5LgooWEVOKSBQbGF0Zm9ybSB0aW1lciBhcHBlYXJzIHRvIGhhdmUg
dW5leHBlY3RlZGx5IHdyYXBwZWQgMTAgb3IgbW9yZSB0aW1lcy4KCgphbmQgaGVyZSBpcyB4bSBk
bWVzZyBvZiB4ZW4gMy4yIG9uIGEgZGViaWFuIGxlbm55IHN5c3RlbSBydW5uaW5nIG9uCnRoZSBz
YW1lIGhhcmR3YXJlLCBvbiB0aGlzIHN5c3RlbSBJIGRvbid0IGhhdmUgY2xvY2sgcHJvYmxlbXM6
CgooWEVOKSBYZW4gdmVyc2lvbiAzLjItMSAoRGViaWFuIDMuMi4xLTIpICh3YWxkaUBkZWJpYW4u
b3JnKSAoZ2NjCnZlcnNpb24gNC4zLjEgKERlYmlhbiA0LjMuMS0yKSApIFNhdCBKdW4gMjggMDk6
MzI6MTggVVRDIDIwMDgKKFhFTikgQ29tbWFuZCBsaW5lOgooWEVOKSBWaWRlbyBpbmZvcm1hdGlv
bjoKKFhFTikgIFZHQSBpcyB0ZXh0IG1vZGUgODB4MjUsIGZvbnQgOHgxNgooWEVOKSAgVkJFL0RE
QyBtZXRob2RzOiBWMjsgRURJRCB0cmFuc2ZlciB0aW1lOiAyIHNlY29uZHMKKFhFTikgRGlzYyBp
bmZvcm1hdGlvbjoKKFhFTikgIEZvdW5kIDIgTUJSIHNpZ25hdHVyZXMKKFhFTikgIEZvdW5kIDIg
RUREIGluZm9ybWF0aW9uIHN0cnVjdHVyZXMKKFhFTikgWGVuLWU4MjAgUkFNIG1hcDoKKFhFTikg
IDAwMDAwMDAwMDAwMDAwMDAgLSAwMDAwMDAwMDAwMDlmNDAwICh1c2FibGUpCihYRU4pICAwMDAw
MDAwMDAwMDlmNDAwIC0gMDAwMDAwMDAwMDBhMDAwMCAocmVzZXJ2ZWQpCihYRU4pICAwMDAwMDAw
MDAwMGYwMDAwIC0gMDAwMDAwMDAwMDEwMDAwMCAocmVzZXJ2ZWQpCihYRU4pICAwMDAwMDAwMDAw
MTAwMDAwIC0gMDAwMDAwMDBjZmQ0MzAwMCAodXNhYmxlKQooWEVOKSAgMDAwMDAwMDBjZmQ0MzAw
MCAtIDAwMDAwMDAwY2ZkNGMwMDAgKEFDUEkgZGF0YSkKKFhFTikgIDAwMDAwMDAwY2ZkNGMwMDAg
LSAwMDAwMDAwMGNmZDRkMDAwICh1c2FibGUpCihYRU4pICAwMDAwMDAwMGNmZDRkMDAwIC0gMDAw
MDAwMDBkMDAwMDAwMCAocmVzZXJ2ZWQpCihYRU4pICAwMDAwMDAwMGUwMDAwMDAwIC0gMDAwMDAw
MDBmMDAwMDAwMCAocmVzZXJ2ZWQpCihYRU4pICAwMDAwMDAwMGZlYzAwMDAwIC0gMDAwMDAwMDBm
ZWQwMDAwMCAocmVzZXJ2ZWQpCihYRU4pICAwMDAwMDAwMGZlZTAwMDAwIC0gMDAwMDAwMDBmZWUx
MDAwMCAocmVzZXJ2ZWQpCihYRU4pICAwMDAwMDAwMGZmYzAwMDAwIC0gMDAwMDAwMDEwMDAwMDAw
MCAocmVzZXJ2ZWQpCihYRU4pICAwMDAwMDAwMTAwMDAwMDAwIC0gMDAwMDAwMGYyZmZmZjAwMCAo
dXNhYmxlKQooWEVOKSBTeXN0ZW0gUkFNOiA2MTQzNk1CICg2MjkxMTM2OGtCKQooWEVOKSBYZW4g
aGVhcDogMTJNQiAoMTMxMjhrQikKKFhFTikgRG9tYWluIGhlYXAgaW5pdGlhbGlzZWQ6IERNQSB3
aWR0aCAzMiBiaXRzCihYRU4pIFByb2Nlc3NvciAjMCA2OjE1IEFQSUMgdmVyc2lvbiAyMAooWEVO
KSBQcm9jZXNzb3IgIzggNjoxNSBBUElDIHZlcnNpb24gMjAKKFhFTikgUHJvY2Vzc29yICMxNiA2
OjE1IEFQSUMgdmVyc2lvbiAyMAooWEVOKSBQcm9jZXNzb3IgIzI0IDY6MTUgQVBJQyB2ZXJzaW9u
IDIwCihYRU4pIFByb2Nlc3NvciAjMSA2OjE1IEFQSUMgdmVyc2lvbiAyMAooWEVOKSBQcm9jZXNz
b3IgIzkgNjoxNSBBUElDIHZlcnNpb24gMjAKKFhFTikgUHJvY2Vzc29yICMxNyA2OjE1IEFQSUMg
dmVyc2lvbiAyMAooWEVOKSBQcm9jZXNzb3IgIzI1IDY6MTUgQVBJQyB2ZXJzaW9uIDIwCihYRU4p
IFByb2Nlc3NvciAjMiA2OjE1IEFQSUMgdmVyc2lvbiAyMAooWEVOKSBQcm9jZXNzb3IgIzEwIDY6
MTUgQVBJQyB2ZXJzaW9uIDIwCihYRU4pIFByb2Nlc3NvciAjMTggNjoxNSBBUElDIHZlcnNpb24g
MjAKKFhFTikgUHJvY2Vzc29yICMyNiA2OjE1IEFQSUMgdmVyc2lvbiAyMAooWEVOKSBQcm9jZXNz
b3IgIzMgNjoxNSBBUElDIHZlcnNpb24gMjAKKFhFTikgUHJvY2Vzc29yICMxMSA2OjE1IEFQSUMg
dmVyc2lvbiAyMAooWEVOKSBQcm9jZXNzb3IgIzE5IDY6MTUgQVBJQyB2ZXJzaW9uIDIwCihYRU4p
IFByb2Nlc3NvciAjMjcgNjoxNSBBUElDIHZlcnNpb24gMjAKKFhFTikgSU9BUElDWzBdOiBhcGlj
X2lkIDEsIHZlcnNpb24gMzIsIGFkZHJlc3MgMHhmZWMwMDAwMCwgR1NJIDAtMjMKKFhFTikgSU9B
UElDWzFdOiBhcGljX2lkIDIsIHZlcnNpb24gMzIsIGFkZHJlc3MgMHhmZWM4MDAwMCwgR1NJIDI0
LTQ3CihYRU4pIElPQVBJQ1syXTogYXBpY19pZCAzLCB2ZXJzaW9uIDMyLCBhZGRyZXNzIDB4ZmVj
ODEwMDAsIEdTSSA0OC03MQooWEVOKSBJT0FQSUNbM106IGFwaWNfaWQgNCwgdmVyc2lvbiAzMiwg
YWRkcmVzcyAweGZlYzgxODAwLCBHU0kgNzItOTUKKFhFTikgRW5hYmxpbmcgQVBJQyBtb2RlOiAg
UGh5cy4gIFVzaW5nIDQgSS9PIEFQSUNzCihYRU4pIFVzaW5nIHNjaGVkdWxlcjogU01QIENyZWRp
dCBTY2hlZHVsZXIgKGNyZWRpdCkKKFhFTikgRGV0ZWN0ZWQgMjQwMC4xMzYgTUh6IHByb2Nlc3Nv
ci4KKFhFTikgSFZNOiBWTVggZW5hYmxlZAooWEVOKSBDUFUwOiBJbnRlbChSKSBYZW9uKFIpIENQ
VSAgICAgICAgICAgRTczMzAgIEAgMi40MEdIeiBzdGVwcGluZyAwYgooWEVOKSBCb290aW5nIHBy
b2Nlc3NvciAxLzggZWlwIDhjMDAwCihYRU4pIENQVTE6IEludGVsKFIpIFhlb24oUikgQ1BVICAg
ICAgICAgICBFNzMzMCAgQCAyLjQwR0h6IHN0ZXBwaW5nIDBiCihYRU4pIEJvb3RpbmcgcHJvY2Vz
c29yIDIvMTYgZWlwIDhjMDAwCihYRU4pIENQVTI6IEludGVsKFIpIFhlb24oUikgQ1BVICAgICAg
ICAgICBFNzMzMCAgQCAyLjQwR0h6IHN0ZXBwaW5nIDBiCihYRU4pIEJvb3RpbmcgcHJvY2Vzc29y
IDMvMjQgZWlwIDhjMDAwCihYRU4pIENQVTM6IEludGVsKFIpIFhlb24oUikgQ1BVICAgICAgICAg
ICBFNzMzMCAgQCAyLjQwR0h6IHN0ZXBwaW5nIDBiCihYRU4pIEJvb3RpbmcgcHJvY2Vzc29yIDQv
MSBlaXAgOGMwMDAKKFhFTikgQ1BVNDogSW50ZWwoUikgWGVvbihSKSBDUFUgICAgICAgICAgIEU3
MzMwICBAIDIuNDBHSHogc3RlcHBpbmcgMGIKKFhFTikgQm9vdGluZyBwcm9jZXNzb3IgNS85IGVp
cCA4YzAwMAooWEVOKSBDUFU1OiBJbnRlbChSKSBYZW9uKFIpIENQVSAgICAgICAgICAgRTczMzAg
IEAgMi40MEdIeiBzdGVwcGluZyAwYgooWEVOKSBCb290aW5nIHByb2Nlc3NvciA2LzE3IGVpcCA4
YzAwMAooWEVOKSBDUFU2OiBJbnRlbChSKSBYZW9uKFIpIENQVSAgICAgICAgICAgRTczMzAgIEAg
Mi40MEdIeiBzdGVwcGluZyAwYgooWEVOKSBCb290aW5nIHByb2Nlc3NvciA3LzI1IGVpcCA4YzAw
MAooWEVOKSBDUFU3OiBJbnRlbChSKSBYZW9uKFIpIENQVSAgICAgICAgICAgRTczMzAgIEAgMi40
MEdIeiBzdGVwcGluZyAwYgooWEVOKSBCb290aW5nIHByb2Nlc3NvciA4LzIgZWlwIDhjMDAwCihY
RU4pIENQVTg6IEludGVsKFIpIFhlb24oUikgQ1BVICAgICAgICAgICBFNzMzMCAgQCAyLjQwR0h6
IHN0ZXBwaW5nIDBiCihYRU4pIEJvb3RpbmcgcHJvY2Vzc29yIDkvMTAgZWlwIDhjMDAwCihYRU4p
IENQVTk6IEludGVsKFIpIFhlb24oUikgQ1BVICAgICAgICAgICBFNzMzMCAgQCAyLjQwR0h6IHN0
ZXBwaW5nIDBiCihYRU4pIEJvb3RpbmcgcHJvY2Vzc29yIDEwLzE4IGVpcCA4YzAwMAooWEVOKSBD
UFUxMDogSW50ZWwoUikgWGVvbihSKSBDUFUgICAgICAgICAgIEU3MzMwICBAIDIuNDBHSHogc3Rl
cHBpbmcgMGIKKFhFTikgQm9vdGluZyBwcm9jZXNzb3IgMTEvMjYgZWlwIDhjMDAwCihYRU4pIENQ
VTExOiBJbnRlbChSKSBYZW9uKFIpIENQVSAgICAgICAgICAgRTczMzAgIEAgMi40MEdIeiBzdGVw
cGluZyAwYgooWEVOKSBCb290aW5nIHByb2Nlc3NvciAxMi8zIGVpcCA4YzAwMAooWEVOKSBDUFUx
MjogSW50ZWwoUikgWGVvbihSKSBDUFUgICAgICAgICAgIEU3MzMwICBAIDIuNDBHSHogc3RlcHBp
bmcgMGIKKFhFTikgQm9vdGluZyBwcm9jZXNzb3IgMTMvMTEgZWlwIDhjMDAwCihYRU4pIENQVTEz
OiBJbnRlbChSKSBYZW9uKFIpIENQVSAgICAgICAgICAgRTczMzAgIEAgMi40MEdIeiBzdGVwcGlu
ZyAwYgooWEVOKSBCb290aW5nIHByb2Nlc3NvciAxNC8xOSBlaXAgOGMwMDAKKFhFTikgQ1BVMTQ6
IEludGVsKFIpIFhlb24oUikgQ1BVICAgICAgICAgICBFNzMzMCAgQCAyLjQwR0h6IHN0ZXBwaW5n
IDBiCihYRU4pIEJvb3RpbmcgcHJvY2Vzc29yIDE1LzI3IGVpcCA4YzAwMAooWEVOKSBDUFUxNTog
SW50ZWwoUikgWGVvbihSKSBDUFUgICAgICAgICAgIEU3MzMwICBAIDIuNDBHSHogc3RlcHBpbmcg
MGIKKFhFTikgVG90YWwgb2YgMTYgcHJvY2Vzc29ycyBhY3RpdmF0ZWQuCihYRU4pIEVOQUJMSU5H
IElPLUFQSUMgSVJRcwooWEVOKSAgLT4gVXNpbmcgbmV3IEFDSyBtZXRob2QKKFhFTikgUGxhdGZv
cm0gdGltZXIgb3ZlcmZsb3dzIGluIDE0OTk4IGppZmZpZXMuCihYRU4pIFBsYXRmb3JtIHRpbWVy
IGlzIDE0LjMxOE1IeiBIUEVUCihYRU4pIEJyb3VnaHQgdXAgMTYgQ1BVcwooWEVOKSBBTUQgSU9N
TVU6IERpc2FibGVkCihYRU4pICoqKiBMT0FESU5HIERPTUFJTiAwICoqKgooWEVOKSAgWGVuICBr
ZXJuZWw6IDY0LWJpdCwgbHNiLCBjb21wYXQzMgooWEVOKSAgRG9tMCBrZXJuZWw6IDY0LWJpdCwg
bHNiLCBwYWRkciAweDIwMDAwMCAtPiAweDYzMTkxOAooWEVOKSBQSFlTSUNBTCBNRU1PUlkgQVJS
QU5HRU1FTlQ6CihYRU4pICBEb20wIGFsbG9jLjogICAwMDAwMDAwOGUwMDAwMDAwLT4wMDAwMDAw
OGYwMDAwMDAwICgxNTQyMjU4NQpwYWdlcyB0byBiZSBhbGxvY2F0ZWQpCihYRU4pIFZJUlRVQUwg
TUVNT1JZIEFSUkFOR0VNRU5UOgooWEVOKSAgTG9hZGVkIGtlcm5lbDogZmZmZmZmZmY4MDIwMDAw
MC0+ZmZmZmZmZmY4MDYzMTkxOAooWEVOKSAgSW5pdC4gcmFtZGlzazogZmZmZmZmZmY4MDYzMjAw
MC0+ZmZmZmZmZmY4MGQ0MGUwMAooWEVOKSAgUGh5cy1NYWNoIG1hcDogZmZmZmZmZmY4MGQ0MTAw
MC0+ZmZmZmZmZmY4ODM2YjNjOAooWEVOKSAgU3RhcnQgaW5mbzogICAgZmZmZmZmZmY4ODM2YzAw
MC0+ZmZmZmZmZmY4ODM2YzRhNAooWEVOKSAgUGFnZSB0YWJsZXM6ICAgZmZmZmZmZmY4ODM2ZDAw
MC0+ZmZmZmZmZmY4ODNiNDAwMAooWEVOKSAgQm9vdCBzdGFjazogICAgZmZmZmZmZmY4ODNiNDAw
MC0+ZmZmZmZmZmY4ODNiNTAwMAooWEVOKSAgVE9UQUw6ICAgICAgICAgZmZmZmZmZmY4MDAwMDAw
MC0+ZmZmZmZmZmY4ODgwMDAwMAooWEVOKSAgRU5UUlkgQUREUkVTUzogZmZmZmZmZmY4MDIwMDAw
MAooWEVOKSBEb20wIGhhcyBtYXhpbXVtIDE2IFZDUFVzCihYRU4pIEluaXRyZCBsZW4gMHg3MGVl
MDAsIHN0YXJ0IGF0IDB4ZmZmZmZmZmY4MDYzMjAwMAooWEVOKSBTY3J1YmJpbmcgRnJlZSBSQU06
IC5kb25lLgooWEVOKSBYZW4gdHJhY2UgYnVmZmVyczogZGlzYWJsZWQKKFhFTikgU3RkLiBMb2ds
ZXZlbDogRXJyb3JzIGFuZCB3YXJuaW5ncwooWEVOKSBHdWVzdCBMb2dsZXZlbDogTm90aGluZyAo
UmF0ZS1saW1pdGVkOiBFcnJvcnMgYW5kIHdhcm5pbmdzKQooWEVOKSBYZW4gaXMgcmVsaW5xdWlz
aGluZyBWR0EgY29uc29sZS4KKFhFTikgKioqIFNlcmlhbCBpbnB1dCAtPiBET00wICh0eXBlICdD
VFJMLWEnIHRocmVlIHRpbWVzIHRvIHN3aXRjaAppbnB1dCB0byBYZW4pCihYRU4pIEZyZWVkIDEw
NGtCIGluaXQgbWVtb3J5LgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpo
dHRwOi8vbGlzdHMueGVuLm9yZy94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xen.org Sat Sep 29 15:17:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 29 Sep 2012 15:17:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1THymb-0001S4-9f; Sat, 29 Sep 2012 15:16:45 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mrsanna1@gmail.com>) id 1THyj9-0001B3-PO
	for xen-devel@lists.xensource.com; Sat, 29 Sep 2012 15:13:12 +0000
Received: from [85.158.143.35:27723] by server-3.bemta-4.messagelabs.com id
	B7/E7-10986-70017605; Sat, 29 Sep 2012 15:13:11 +0000
X-Env-Sender: mrsanna1@gmail.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1348931588!11744757!1
X-Originating-IP: [209.85.220.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27180 invoked from network); 29 Sep 2012 15:13:09 -0000
Received: from mail-vc0-f171.google.com (HELO mail-vc0-f171.google.com)
	(209.85.220.171)
	by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Sep 2012 15:13:09 -0000
Received: by vcmm18 with SMTP id m18so5474568vcm.30
	for <multiple recipients>; Sat, 29 Sep 2012 08:13: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=GJiiKciB+AW37QQALJh016YNCl54lMppdyoHlLSf/tQ=;
	b=JUgB0qFqU0I+knq9Oe3VFqvKiTWGPRoZPQ4eRFHCBH4JvldommXTftJE8BMYFXoUbJ
	+BVssQv2u5R1sPKUOxuca0bCwkKzzanvQb0eKc9K3h2L8urpSp1Xw6VGdPFuSsTgErfZ
	GTKjuOR540yKSP17bl4hQI6n3ulg0BA8x7eLOsTRY3hRmNhJ3l2nzsHVDHb4HjPJHGwr
	+4bHDRNzT/Lrxp9stvVztDWcp0U8UAfhK7+a6PaNqLz03jD1Al/TI9s9bBxAjMzJl463
	gr5VQId+czj+Kc05V+7/qSeapWSC3GzbxLsB9zmS1VK41+snGoOGFQ9sIpaFlBGUxnsd
	UtIA==
MIME-Version: 1.0
Received: by 10.220.205.200 with SMTP id fr8mr5652534vcb.34.1348931588463;
	Sat, 29 Sep 2012 08:13:08 -0700 (PDT)
Received: by 10.58.207.75 with HTTP; Sat, 29 Sep 2012 08:13:08 -0700 (PDT)
In-Reply-To: <C98BB635.13B99%keir.xen@gmail.com>
References: <4D655A39.2040501@gmail.com>
	<C98BB635.13B99%keir.xen@gmail.com>
Date: Sat, 29 Sep 2012 17:13:08 +0200
Message-ID: <CAE17a0X3LqPi0-qyxa1w3zNT_Ux-pSrZNSYyVa_U1XvaVK7WxQ@mail.gmail.com>
From: Mauro <mrsanna1@gmail.com>
To: Keir Fraser <keir.xen@gmail.com>
X-Mailman-Approved-At: Sat, 29 Sep 2012 15:16:44 +0000
Cc: Dan Magenheimer <dan.magenheimer@oracle.com>, xen-devel@lists.xensource.com,
	Jeremy Fitzhardinge <jeremy@goop.org>,
	Olivier Hanesse <olivier.hanesse@gmail.com>,
	Xen Users <xen-users@lists.xensource.com>,
	Mark Adams <mark@campbell-lange.net>
Subject: Re: [Xen-devel] [Xen-users] Re:  Xen 4 TSC problems
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gMjQgRmVicnVhcnkgMjAxMSAwODoxNiwgS2VpciBGcmFzZXIgPGtlaXIueGVuQGdtYWlsLmNv
bT4gd3JvdGU6Cj4gUGxlYXNlIHNlbmQgWGVuIGJvb3Qgb3V0cHV0ICh4bSBkbWVzZykuIEdldHRp
bmcgaXQgZnJvbSBYZW4gMy4yIGFzIHdlbGwKPiB3b3VsZCBiZSBpbnRlcmVzdGluZywgaWYgeW91
IHN0aWxsIGhhdmUgaXQgaW5zdGFsbGVkIG9uIGFueSBvZiB0aGVzZQo+IG1hY2hpbmVzLgoKSWYg
aXQgY2FuIGJlIHVzZWZ1bCBoZXJlIGlzIHhtIGRtZXNmIG9mIHhlbiA0LjAgb24gYSBkZWJpYW4g
c3F1ZWV6ZSBzeXN0ZW06CgooWEVOKSBYZW4gdmVyc2lvbiA0LjAuMSAoRGViaWFuIDQuMC4xLTUu
NCkgKHVsdHJvdHRlckBkZWJpYW4ub3JnKSAoZ2NjCnZlcnNpb24gNC40LjUgKERlYmlhbiA0LjQu
NS04KSApIFNhdCBTZXAgIDggMTk6MTU6NDYgVVRDIDIwMTIKKFhFTikgQm9vdGxvYWRlcjogR1JV
QiAxLjk4KzIwMTAwODA0LTE0K3NxdWVlemUxCihYRU4pIENvbW1hbmQgbGluZTogcGxhY2Vob2xk
ZXIgZG9tMF9tZW09MzA3Mk0gbG9nbHZsPXdhcm5pbmcKZ3Vlc3RfbG9nbHZsPXdhcm5pbmcKKFhF
TikgVmlkZW8gaW5mb3JtYXRpb246CihYRU4pICBWR0EgaXMgdGV4dCBtb2RlIDgweDI1LCBmb250
IDh4MTYKKFhFTikgIFZCRS9EREMgbWV0aG9kczogVjI7IEVESUQgdHJhbnNmZXIgdGltZTogMiBz
ZWNvbmRzCihYRU4pIERpc2MgaW5mb3JtYXRpb246CihYRU4pICBGb3VuZCAyIE1CUiBzaWduYXR1
cmVzCihYRU4pICBGb3VuZCAyIEVERCBpbmZvcm1hdGlvbiBzdHJ1Y3R1cmVzCihYRU4pIFhlbi1l
ODIwIFJBTSBtYXA6CihYRU4pICAwMDAwMDAwMDAwMDAwMDAwIC0gMDAwMDAwMDAwMDA5ZjQwMCAo
dXNhYmxlKQooWEVOKSAgMDAwMDAwMDAwMDA5ZjQwMCAtIDAwMDAwMDAwMDAwYTAwMDAgKHJlc2Vy
dmVkKQooWEVOKSAgMDAwMDAwMDAwMDBmMDAwMCAtIDAwMDAwMDAwMDAxMDAwMDAgKHJlc2VydmVk
KQooWEVOKSAgMDAwMDAwMDAwMDEwMDAwMCAtIDAwMDAwMDAwY2ZkNDMwMDAgKHVzYWJsZSkKKFhF
TikgIDAwMDAwMDAwY2ZkNDMwMDAgLSAwMDAwMDAwMGNmZDRjMDAwIChBQ1BJIGRhdGEpCihYRU4p
ICAwMDAwMDAwMGNmZDRjMDAwIC0gMDAwMDAwMDBjZmQ0ZDAwMCAodXNhYmxlKQooWEVOKSAgMDAw
MDAwMDBjZmQ0ZDAwMCAtIDAwMDAwMDAwZDAwMDAwMDAgKHJlc2VydmVkKQooWEVOKSAgMDAwMDAw
MDBlMDAwMDAwMCAtIDAwMDAwMDAwZjAwMDAwMDAgKHJlc2VydmVkKQooWEVOKSAgMDAwMDAwMDBm
ZWMwMDAwMCAtIDAwMDAwMDAwZmVkMDAwMDAgKHJlc2VydmVkKQooWEVOKSAgMDAwMDAwMDBmZWUw
MDAwMCAtIDAwMDAwMDAwZmVlMTAwMDAgKHJlc2VydmVkKQooWEVOKSAgMDAwMDAwMDBmZmMwMDAw
MCAtIDAwMDAwMDAxMDAwMDAwMDAgKHJlc2VydmVkKQooWEVOKSAgMDAwMDAwMDEwMDAwMDAwMCAt
IDAwMDAwMDEwMmZmZmYwMDAgKHVzYWJsZSkKKFhFTikgQUNQSTogUlNEUCAwMDBGNEYyMCwgMDAy
NCAocjIgSFAgICAgKQooWEVOKSBBQ1BJOiBYU0RUIENGRDQzOTAwLCAwMDdDIChyMSBIUCAgICAg
UHJvTGlhbnQgICAgICAgIDIgICDvv70gICAgIDE2MkUpCihYRU4pIEFDUEk6IEZBQ1AgQ0ZENDM5
QzAsIDAwRjQgKHIzIEhQICAgICBQcm9MaWFudCAgICAgICAgMiAgIO+/vSAgICAgMTYyRSkKKFhF
TikgQUNQSTogRFNEVCBDRkQ0M0FDMCwgMzBDOSAocjEgSFAgICAgICAgICBEU0RUICAgICAgICAx
IElOVEwgMjAwMzAyMjgpCihYRU4pIEFDUEk6IEZBQ1MgQ0ZENDMxMDAsIDAwNDAKKFhFTikgQUNQ
STogU1BDUiBDRkQ0MzE0MCwgMDA1MCAocjEgSFAgICAgIFNQQ1JSQlNVICAgICAgICAxICAg77+9
ICAgICAxNjJFKQooWEVOKSBBQ1BJOiBNQ0ZHIENGRDQzMUMwLCAwMDNDIChyMSBIUCAgICAgUHJv
TGlhbnQgICAgICAgIDEgICAgICAgICAgICAgMCkKKFhFTikgQUNQSTogSFBFVCBDRkQ0MzIwMCwg
MDAzOCAocjEgSFAgICAgIFByb0xpYW50ICAgICAgICAyICAg77+9ICAgICAxNjJFKQooWEVOKSBB
Q1BJOiBGRkZGIENGRDQzMjQwLCAwMDY0IChyMiBIUCAgICAgUDYxICAgICAgICAgICAgIDIgICDv
v70gICAgIDE2MkUpCihYRU4pIEFDUEk6IFNQTUkgQ0ZENDMyQzAsIDAwNDAgKHI1IEhQICAgICBQ
cm9MaWFudCAgICAgICAgMSAgIO+/vSAgICAgMTYyRSkKKFhFTikgQUNQSTogRVJTVCBDRkQ0MzMw
MCwgMDFEMCAocjEgSFAgICAgIFByb0xpYW50ICAgICAgICAxICAg77+9ICAgICAxNjJFKQooWEVO
KSBBQ1BJOiBBUElDIENGRDQzNTAwLCAwMTc2IChyMSBIUCAgICAgUHJvTGlhbnQgICAgICAgIDIg
ICAgICAgICAgICAgMCkKKFhFTikgQUNQSTogRkZGRiBDRkQ0MzY4MCwgMDE3NiAocjEgSFAgICAg
IFByb0xpYW50ICAgICAgICAxICAg77+9ICAgICAxNjJFKQooWEVOKSBBQ1BJOiBCRVJUIENGRDQz
ODAwLCAwMDMwIChyMSBIUCAgICAgUHJvTGlhbnQgICAgICAgIDEgICDvv70gICAgIDE2MkUpCihY
RU4pIEFDUEk6IEhFU1QgQ0ZENDM4NDAsIDAwQkMgKHIxIEhQICAgICBQcm9MaWFudCAgICAgICAg
MSAgIO+/vSAgICAgMTYyRSkKKFhFTikgU3lzdGVtIFJBTTogNjU1MzJNQiAoNjcxMDU2NzJrQikK
KFhFTikgRG9tYWluIGhlYXAgaW5pdGlhbGlzZWQKKFhFTikgUHJvY2Vzc29yICMwIDY6MTUgQVBJ
QyB2ZXJzaW9uIDIwCihYRU4pIFByb2Nlc3NvciAjOCA2OjE1IEFQSUMgdmVyc2lvbiAyMAooWEVO
KSBQcm9jZXNzb3IgIzE2IDY6MTUgQVBJQyB2ZXJzaW9uIDIwCihYRU4pIFByb2Nlc3NvciAjMjQg
NjoxNSBBUElDIHZlcnNpb24gMjAKKFhFTikgUHJvY2Vzc29yICMxIDY6MTUgQVBJQyB2ZXJzaW9u
IDIwCihYRU4pIFByb2Nlc3NvciAjOSA2OjE1IEFQSUMgdmVyc2lvbiAyMAooWEVOKSBQcm9jZXNz
b3IgIzE3IDY6MTUgQVBJQyB2ZXJzaW9uIDIwCihYRU4pIFByb2Nlc3NvciAjMjUgNjoxNSBBUElD
IHZlcnNpb24gMjAKKFhFTikgUHJvY2Vzc29yICMyIDY6MTUgQVBJQyB2ZXJzaW9uIDIwCihYRU4p
IFByb2Nlc3NvciAjMTAgNjoxNSBBUElDIHZlcnNpb24gMjAKKFhFTikgUHJvY2Vzc29yICMxOCA2
OjE1IEFQSUMgdmVyc2lvbiAyMAooWEVOKSBQcm9jZXNzb3IgIzI2IDY6MTUgQVBJQyB2ZXJzaW9u
IDIwCihYRU4pIFByb2Nlc3NvciAjMyA2OjE1IEFQSUMgdmVyc2lvbiAyMAooWEVOKSBQcm9jZXNz
b3IgIzExIDY6MTUgQVBJQyB2ZXJzaW9uIDIwCihYRU4pIFByb2Nlc3NvciAjMTkgNjoxNSBBUElD
IHZlcnNpb24gMjAKKFhFTikgUHJvY2Vzc29yICMyNyA2OjE1IEFQSUMgdmVyc2lvbiAyMAooWEVO
KSBJT0FQSUNbMF06IGFwaWNfaWQgMSwgdmVyc2lvbiAzMiwgYWRkcmVzcyAweGZlYzAwMDAwLCBH
U0kgMC0yMwooWEVOKSBJT0FQSUNbMV06IGFwaWNfaWQgMiwgdmVyc2lvbiAzMiwgYWRkcmVzcyAw
eGZlYzgwMDAwLCBHU0kgMjQtNDcKKFhFTikgSU9BUElDWzJdOiBhcGljX2lkIDMsIHZlcnNpb24g
MzIsIGFkZHJlc3MgMHhmZWM4MTAwMCwgR1NJIDQ4LTcxCihYRU4pIElPQVBJQ1szXTogYXBpY19p
ZCA0LCB2ZXJzaW9uIDMyLCBhZGRyZXNzIDB4ZmVjODE4MDAsIEdTSSA3Mi05NQooWEVOKSBFbmFi
bGluZyBBUElDIG1vZGU6ICBQaHlzLiAgVXNpbmcgNCBJL08gQVBJQ3MKKFhFTikgVXNpbmcgc2No
ZWR1bGVyOiBTTVAgQ3JlZGl0IFNjaGVkdWxlciAoY3JlZGl0KQooWEVOKSBEZXRlY3RlZCAyNDAw
LjE0NSBNSHogcHJvY2Vzc29yLgooWEVOKSBJbml0aW5nIG1lbW9yeSBzaGFyaW5nLgooWEVOKSBW
TVg6IFN1cHBvcnRlZCBhZHZhbmNlZCBmZWF0dXJlczoKKFhFTikgIC0gQVBJQyBNTUlPIGFjY2Vz
cyB2aXJ0dWFsaXNhdGlvbgooWEVOKSAgLSBBUElDIFRQUiBzaGFkb3cKKFhFTikgIC0gVmlydHVh
bCBOTUkKKFhFTikgIC0gTVNSIGRpcmVjdC1hY2Nlc3MgYml0bWFwCihYRU4pIEhWTTogQVNJRHMg
ZGlzYWJsZWQuCihYRU4pIEhWTTogVk1YIGVuYWJsZWQKKFhFTikgSS9PIHZpcnR1YWxpc2F0aW9u
IGRpc2FibGVkCihYRU4pIFRvdGFsIG9mIDE2IHByb2Nlc3NvcnMgYWN0aXZhdGVkLgooWEVOKSBF
TkFCTElORyBJTy1BUElDIElSUXMKKFhFTikgIC0+IFVzaW5nIG5ldyBBQ0sgbWV0aG9kCihYRU4p
IGNoZWNraW5nIFRTQyBzeW5jaHJvbml6YXRpb24gYWNyb3NzIDE2IENQVXM6IHBhc3NlZC4KKFhF
TikgUGxhdGZvcm0gdGltZXIgaXMgMTQuMzE4TUh6IEhQRVQKKFhFTikgQWxsb2NhdGVkIGNvbnNv
bGUgcmluZyBvZiAzMiBLaUIuCihYRU4pIEJyb3VnaHQgdXAgMTYgQ1BVcwooWEVOKSAqKiogTE9B
RElORyBET01BSU4gMCAqKioKKFhFTikgIFhlbiAga2VybmVsOiA2NC1iaXQsIGxzYiwgY29tcGF0
MzIKKFhFTikgIERvbTAga2VybmVsOiA2NC1iaXQsIFBBRSwgbHNiLCBwYWRkciAweDEwMDAwMDAg
LT4gMHgxNzA4MDAwCihYRU4pIFBIWVNJQ0FMIE1FTU9SWSBBUlJBTkdFTUVOVDoKKFhFTikgIERv
bTAgYWxsb2MuOiAgIDAwMDAwMDA4M2MwMDAwMDAtPjAwMDAwMDA4NDAwMDAwMDAgKDc3MDA0OCBw
YWdlcwp0byBiZSBhbGxvY2F0ZWQpCihYRU4pIFZJUlRVQUwgTUVNT1JZIEFSUkFOR0VNRU5UOgoo
WEVOKSAgTG9hZGVkIGtlcm5lbDogZmZmZmZmZmY4MTAwMDAwMC0+ZmZmZmZmZmY4MTcwODAwMAoo
WEVOKSAgSW5pdC4gcmFtZGlzazogZmZmZmZmZmY4MTcwODAwMC0+ZmZmZmZmZmY4MWVmYjAwMAoo
WEVOKSAgUGh5cy1NYWNoIG1hcDogZmZmZmZmZmY4MWVmYjAwMC0+ZmZmZmZmZmY4MjRmYjAwMAoo
WEVOKSAgU3RhcnQgaW5mbzogICAgZmZmZmZmZmY4MjRmYjAwMC0+ZmZmZmZmZmY4MjRmYjRiNAoo
WEVOKSAgUGFnZSB0YWJsZXM6ICAgZmZmZmZmZmY4MjRmYzAwMC0+ZmZmZmZmZmY4MjUxMzAwMAoo
WEVOKSAgQm9vdCBzdGFjazogICAgZmZmZmZmZmY4MjUxMzAwMC0+ZmZmZmZmZmY4MjUxNDAwMAoo
WEVOKSAgVE9UQUw6ICAgICAgICAgZmZmZmZmZmY4MDAwMDAwMC0+ZmZmZmZmZmY4MjgwMDAwMAoo
WEVOKSAgRU5UUlkgQUREUkVTUzogZmZmZmZmZmY4MTUzMTIwMAooWEVOKSBEb20wIGhhcyBtYXhp
bXVtIDE2IFZDUFVzCihYRU4pIFNjcnViYmluZyBGcmVlIFJBTToKLi4uLi4uLi4uLi4uLi4uLi4u
Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u
Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u
Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u
Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u
Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u
Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u
Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u
Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u
Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u
Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u
Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi5kb25lLgooWEVOKSBYZW4gdHJhY2UgYnVmZmVy
czogZGlzYWJsZWQKKFhFTikgU3RkLiBMb2dsZXZlbDogRXJyb3JzIGFuZCB3YXJuaW5ncwooWEVO
KSBHdWVzdCBMb2dsZXZlbDogRXJyb3JzIGFuZCB3YXJuaW5ncwooWEVOKSBYZW4gaXMgcmVsaW5x
dWlzaGluZyBWR0EgY29uc29sZS4KKFhFTikgKioqIFNlcmlhbCBpbnB1dCAtPiBET00wICh0eXBl
ICdDVFJMLWEnIHRocmVlIHRpbWVzIHRvIHN3aXRjaAppbnB1dCB0byBYZW4pCihYRU4pIEZyZWVk
IDE3NmtCIGluaXQgbWVtb3J5LgooWEVOKSBQbGF0Zm9ybSB0aW1lciBhcHBlYXJzIHRvIGhhdmUg
dW5leHBlY3RlZGx5IHdyYXBwZWQgMTAgb3IgbW9yZSB0aW1lcy4KCgphbmQgaGVyZSBpcyB4bSBk
bWVzZyBvZiB4ZW4gMy4yIG9uIGEgZGViaWFuIGxlbm55IHN5c3RlbSBydW5uaW5nIG9uCnRoZSBz
YW1lIGhhcmR3YXJlLCBvbiB0aGlzIHN5c3RlbSBJIGRvbid0IGhhdmUgY2xvY2sgcHJvYmxlbXM6
CgooWEVOKSBYZW4gdmVyc2lvbiAzLjItMSAoRGViaWFuIDMuMi4xLTIpICh3YWxkaUBkZWJpYW4u
b3JnKSAoZ2NjCnZlcnNpb24gNC4zLjEgKERlYmlhbiA0LjMuMS0yKSApIFNhdCBKdW4gMjggMDk6
MzI6MTggVVRDIDIwMDgKKFhFTikgQ29tbWFuZCBsaW5lOgooWEVOKSBWaWRlbyBpbmZvcm1hdGlv
bjoKKFhFTikgIFZHQSBpcyB0ZXh0IG1vZGUgODB4MjUsIGZvbnQgOHgxNgooWEVOKSAgVkJFL0RE
QyBtZXRob2RzOiBWMjsgRURJRCB0cmFuc2ZlciB0aW1lOiAyIHNlY29uZHMKKFhFTikgRGlzYyBp
bmZvcm1hdGlvbjoKKFhFTikgIEZvdW5kIDIgTUJSIHNpZ25hdHVyZXMKKFhFTikgIEZvdW5kIDIg
RUREIGluZm9ybWF0aW9uIHN0cnVjdHVyZXMKKFhFTikgWGVuLWU4MjAgUkFNIG1hcDoKKFhFTikg
IDAwMDAwMDAwMDAwMDAwMDAgLSAwMDAwMDAwMDAwMDlmNDAwICh1c2FibGUpCihYRU4pICAwMDAw
MDAwMDAwMDlmNDAwIC0gMDAwMDAwMDAwMDBhMDAwMCAocmVzZXJ2ZWQpCihYRU4pICAwMDAwMDAw
MDAwMGYwMDAwIC0gMDAwMDAwMDAwMDEwMDAwMCAocmVzZXJ2ZWQpCihYRU4pICAwMDAwMDAwMDAw
MTAwMDAwIC0gMDAwMDAwMDBjZmQ0MzAwMCAodXNhYmxlKQooWEVOKSAgMDAwMDAwMDBjZmQ0MzAw
MCAtIDAwMDAwMDAwY2ZkNGMwMDAgKEFDUEkgZGF0YSkKKFhFTikgIDAwMDAwMDAwY2ZkNGMwMDAg
LSAwMDAwMDAwMGNmZDRkMDAwICh1c2FibGUpCihYRU4pICAwMDAwMDAwMGNmZDRkMDAwIC0gMDAw
MDAwMDBkMDAwMDAwMCAocmVzZXJ2ZWQpCihYRU4pICAwMDAwMDAwMGUwMDAwMDAwIC0gMDAwMDAw
MDBmMDAwMDAwMCAocmVzZXJ2ZWQpCihYRU4pICAwMDAwMDAwMGZlYzAwMDAwIC0gMDAwMDAwMDBm
ZWQwMDAwMCAocmVzZXJ2ZWQpCihYRU4pICAwMDAwMDAwMGZlZTAwMDAwIC0gMDAwMDAwMDBmZWUx
MDAwMCAocmVzZXJ2ZWQpCihYRU4pICAwMDAwMDAwMGZmYzAwMDAwIC0gMDAwMDAwMDEwMDAwMDAw
MCAocmVzZXJ2ZWQpCihYRU4pICAwMDAwMDAwMTAwMDAwMDAwIC0gMDAwMDAwMGYyZmZmZjAwMCAo
dXNhYmxlKQooWEVOKSBTeXN0ZW0gUkFNOiA2MTQzNk1CICg2MjkxMTM2OGtCKQooWEVOKSBYZW4g
aGVhcDogMTJNQiAoMTMxMjhrQikKKFhFTikgRG9tYWluIGhlYXAgaW5pdGlhbGlzZWQ6IERNQSB3
aWR0aCAzMiBiaXRzCihYRU4pIFByb2Nlc3NvciAjMCA2OjE1IEFQSUMgdmVyc2lvbiAyMAooWEVO
KSBQcm9jZXNzb3IgIzggNjoxNSBBUElDIHZlcnNpb24gMjAKKFhFTikgUHJvY2Vzc29yICMxNiA2
OjE1IEFQSUMgdmVyc2lvbiAyMAooWEVOKSBQcm9jZXNzb3IgIzI0IDY6MTUgQVBJQyB2ZXJzaW9u
IDIwCihYRU4pIFByb2Nlc3NvciAjMSA2OjE1IEFQSUMgdmVyc2lvbiAyMAooWEVOKSBQcm9jZXNz
b3IgIzkgNjoxNSBBUElDIHZlcnNpb24gMjAKKFhFTikgUHJvY2Vzc29yICMxNyA2OjE1IEFQSUMg
dmVyc2lvbiAyMAooWEVOKSBQcm9jZXNzb3IgIzI1IDY6MTUgQVBJQyB2ZXJzaW9uIDIwCihYRU4p
IFByb2Nlc3NvciAjMiA2OjE1IEFQSUMgdmVyc2lvbiAyMAooWEVOKSBQcm9jZXNzb3IgIzEwIDY6
MTUgQVBJQyB2ZXJzaW9uIDIwCihYRU4pIFByb2Nlc3NvciAjMTggNjoxNSBBUElDIHZlcnNpb24g
MjAKKFhFTikgUHJvY2Vzc29yICMyNiA2OjE1IEFQSUMgdmVyc2lvbiAyMAooWEVOKSBQcm9jZXNz
b3IgIzMgNjoxNSBBUElDIHZlcnNpb24gMjAKKFhFTikgUHJvY2Vzc29yICMxMSA2OjE1IEFQSUMg
dmVyc2lvbiAyMAooWEVOKSBQcm9jZXNzb3IgIzE5IDY6MTUgQVBJQyB2ZXJzaW9uIDIwCihYRU4p
IFByb2Nlc3NvciAjMjcgNjoxNSBBUElDIHZlcnNpb24gMjAKKFhFTikgSU9BUElDWzBdOiBhcGlj
X2lkIDEsIHZlcnNpb24gMzIsIGFkZHJlc3MgMHhmZWMwMDAwMCwgR1NJIDAtMjMKKFhFTikgSU9B
UElDWzFdOiBhcGljX2lkIDIsIHZlcnNpb24gMzIsIGFkZHJlc3MgMHhmZWM4MDAwMCwgR1NJIDI0
LTQ3CihYRU4pIElPQVBJQ1syXTogYXBpY19pZCAzLCB2ZXJzaW9uIDMyLCBhZGRyZXNzIDB4ZmVj
ODEwMDAsIEdTSSA0OC03MQooWEVOKSBJT0FQSUNbM106IGFwaWNfaWQgNCwgdmVyc2lvbiAzMiwg
YWRkcmVzcyAweGZlYzgxODAwLCBHU0kgNzItOTUKKFhFTikgRW5hYmxpbmcgQVBJQyBtb2RlOiAg
UGh5cy4gIFVzaW5nIDQgSS9PIEFQSUNzCihYRU4pIFVzaW5nIHNjaGVkdWxlcjogU01QIENyZWRp
dCBTY2hlZHVsZXIgKGNyZWRpdCkKKFhFTikgRGV0ZWN0ZWQgMjQwMC4xMzYgTUh6IHByb2Nlc3Nv
ci4KKFhFTikgSFZNOiBWTVggZW5hYmxlZAooWEVOKSBDUFUwOiBJbnRlbChSKSBYZW9uKFIpIENQ
VSAgICAgICAgICAgRTczMzAgIEAgMi40MEdIeiBzdGVwcGluZyAwYgooWEVOKSBCb290aW5nIHBy
b2Nlc3NvciAxLzggZWlwIDhjMDAwCihYRU4pIENQVTE6IEludGVsKFIpIFhlb24oUikgQ1BVICAg
ICAgICAgICBFNzMzMCAgQCAyLjQwR0h6IHN0ZXBwaW5nIDBiCihYRU4pIEJvb3RpbmcgcHJvY2Vz
c29yIDIvMTYgZWlwIDhjMDAwCihYRU4pIENQVTI6IEludGVsKFIpIFhlb24oUikgQ1BVICAgICAg
ICAgICBFNzMzMCAgQCAyLjQwR0h6IHN0ZXBwaW5nIDBiCihYRU4pIEJvb3RpbmcgcHJvY2Vzc29y
IDMvMjQgZWlwIDhjMDAwCihYRU4pIENQVTM6IEludGVsKFIpIFhlb24oUikgQ1BVICAgICAgICAg
ICBFNzMzMCAgQCAyLjQwR0h6IHN0ZXBwaW5nIDBiCihYRU4pIEJvb3RpbmcgcHJvY2Vzc29yIDQv
MSBlaXAgOGMwMDAKKFhFTikgQ1BVNDogSW50ZWwoUikgWGVvbihSKSBDUFUgICAgICAgICAgIEU3
MzMwICBAIDIuNDBHSHogc3RlcHBpbmcgMGIKKFhFTikgQm9vdGluZyBwcm9jZXNzb3IgNS85IGVp
cCA4YzAwMAooWEVOKSBDUFU1OiBJbnRlbChSKSBYZW9uKFIpIENQVSAgICAgICAgICAgRTczMzAg
IEAgMi40MEdIeiBzdGVwcGluZyAwYgooWEVOKSBCb290aW5nIHByb2Nlc3NvciA2LzE3IGVpcCA4
YzAwMAooWEVOKSBDUFU2OiBJbnRlbChSKSBYZW9uKFIpIENQVSAgICAgICAgICAgRTczMzAgIEAg
Mi40MEdIeiBzdGVwcGluZyAwYgooWEVOKSBCb290aW5nIHByb2Nlc3NvciA3LzI1IGVpcCA4YzAw
MAooWEVOKSBDUFU3OiBJbnRlbChSKSBYZW9uKFIpIENQVSAgICAgICAgICAgRTczMzAgIEAgMi40
MEdIeiBzdGVwcGluZyAwYgooWEVOKSBCb290aW5nIHByb2Nlc3NvciA4LzIgZWlwIDhjMDAwCihY
RU4pIENQVTg6IEludGVsKFIpIFhlb24oUikgQ1BVICAgICAgICAgICBFNzMzMCAgQCAyLjQwR0h6
IHN0ZXBwaW5nIDBiCihYRU4pIEJvb3RpbmcgcHJvY2Vzc29yIDkvMTAgZWlwIDhjMDAwCihYRU4p
IENQVTk6IEludGVsKFIpIFhlb24oUikgQ1BVICAgICAgICAgICBFNzMzMCAgQCAyLjQwR0h6IHN0
ZXBwaW5nIDBiCihYRU4pIEJvb3RpbmcgcHJvY2Vzc29yIDEwLzE4IGVpcCA4YzAwMAooWEVOKSBD
UFUxMDogSW50ZWwoUikgWGVvbihSKSBDUFUgICAgICAgICAgIEU3MzMwICBAIDIuNDBHSHogc3Rl
cHBpbmcgMGIKKFhFTikgQm9vdGluZyBwcm9jZXNzb3IgMTEvMjYgZWlwIDhjMDAwCihYRU4pIENQ
VTExOiBJbnRlbChSKSBYZW9uKFIpIENQVSAgICAgICAgICAgRTczMzAgIEAgMi40MEdIeiBzdGVw
cGluZyAwYgooWEVOKSBCb290aW5nIHByb2Nlc3NvciAxMi8zIGVpcCA4YzAwMAooWEVOKSBDUFUx
MjogSW50ZWwoUikgWGVvbihSKSBDUFUgICAgICAgICAgIEU3MzMwICBAIDIuNDBHSHogc3RlcHBp
bmcgMGIKKFhFTikgQm9vdGluZyBwcm9jZXNzb3IgMTMvMTEgZWlwIDhjMDAwCihYRU4pIENQVTEz
OiBJbnRlbChSKSBYZW9uKFIpIENQVSAgICAgICAgICAgRTczMzAgIEAgMi40MEdIeiBzdGVwcGlu
ZyAwYgooWEVOKSBCb290aW5nIHByb2Nlc3NvciAxNC8xOSBlaXAgOGMwMDAKKFhFTikgQ1BVMTQ6
IEludGVsKFIpIFhlb24oUikgQ1BVICAgICAgICAgICBFNzMzMCAgQCAyLjQwR0h6IHN0ZXBwaW5n
IDBiCihYRU4pIEJvb3RpbmcgcHJvY2Vzc29yIDE1LzI3IGVpcCA4YzAwMAooWEVOKSBDUFUxNTog
SW50ZWwoUikgWGVvbihSKSBDUFUgICAgICAgICAgIEU3MzMwICBAIDIuNDBHSHogc3RlcHBpbmcg
MGIKKFhFTikgVG90YWwgb2YgMTYgcHJvY2Vzc29ycyBhY3RpdmF0ZWQuCihYRU4pIEVOQUJMSU5H
IElPLUFQSUMgSVJRcwooWEVOKSAgLT4gVXNpbmcgbmV3IEFDSyBtZXRob2QKKFhFTikgUGxhdGZv
cm0gdGltZXIgb3ZlcmZsb3dzIGluIDE0OTk4IGppZmZpZXMuCihYRU4pIFBsYXRmb3JtIHRpbWVy
IGlzIDE0LjMxOE1IeiBIUEVUCihYRU4pIEJyb3VnaHQgdXAgMTYgQ1BVcwooWEVOKSBBTUQgSU9N
TVU6IERpc2FibGVkCihYRU4pICoqKiBMT0FESU5HIERPTUFJTiAwICoqKgooWEVOKSAgWGVuICBr
ZXJuZWw6IDY0LWJpdCwgbHNiLCBjb21wYXQzMgooWEVOKSAgRG9tMCBrZXJuZWw6IDY0LWJpdCwg
bHNiLCBwYWRkciAweDIwMDAwMCAtPiAweDYzMTkxOAooWEVOKSBQSFlTSUNBTCBNRU1PUlkgQVJS
QU5HRU1FTlQ6CihYRU4pICBEb20wIGFsbG9jLjogICAwMDAwMDAwOGUwMDAwMDAwLT4wMDAwMDAw
OGYwMDAwMDAwICgxNTQyMjU4NQpwYWdlcyB0byBiZSBhbGxvY2F0ZWQpCihYRU4pIFZJUlRVQUwg
TUVNT1JZIEFSUkFOR0VNRU5UOgooWEVOKSAgTG9hZGVkIGtlcm5lbDogZmZmZmZmZmY4MDIwMDAw
MC0+ZmZmZmZmZmY4MDYzMTkxOAooWEVOKSAgSW5pdC4gcmFtZGlzazogZmZmZmZmZmY4MDYzMjAw
MC0+ZmZmZmZmZmY4MGQ0MGUwMAooWEVOKSAgUGh5cy1NYWNoIG1hcDogZmZmZmZmZmY4MGQ0MTAw
MC0+ZmZmZmZmZmY4ODM2YjNjOAooWEVOKSAgU3RhcnQgaW5mbzogICAgZmZmZmZmZmY4ODM2YzAw
MC0+ZmZmZmZmZmY4ODM2YzRhNAooWEVOKSAgUGFnZSB0YWJsZXM6ICAgZmZmZmZmZmY4ODM2ZDAw
MC0+ZmZmZmZmZmY4ODNiNDAwMAooWEVOKSAgQm9vdCBzdGFjazogICAgZmZmZmZmZmY4ODNiNDAw
MC0+ZmZmZmZmZmY4ODNiNTAwMAooWEVOKSAgVE9UQUw6ICAgICAgICAgZmZmZmZmZmY4MDAwMDAw
MC0+ZmZmZmZmZmY4ODgwMDAwMAooWEVOKSAgRU5UUlkgQUREUkVTUzogZmZmZmZmZmY4MDIwMDAw
MAooWEVOKSBEb20wIGhhcyBtYXhpbXVtIDE2IFZDUFVzCihYRU4pIEluaXRyZCBsZW4gMHg3MGVl
MDAsIHN0YXJ0IGF0IDB4ZmZmZmZmZmY4MDYzMjAwMAooWEVOKSBTY3J1YmJpbmcgRnJlZSBSQU06
IC5kb25lLgooWEVOKSBYZW4gdHJhY2UgYnVmZmVyczogZGlzYWJsZWQKKFhFTikgU3RkLiBMb2ds
ZXZlbDogRXJyb3JzIGFuZCB3YXJuaW5ncwooWEVOKSBHdWVzdCBMb2dsZXZlbDogTm90aGluZyAo
UmF0ZS1saW1pdGVkOiBFcnJvcnMgYW5kIHdhcm5pbmdzKQooWEVOKSBYZW4gaXMgcmVsaW5xdWlz
aGluZyBWR0EgY29uc29sZS4KKFhFTikgKioqIFNlcmlhbCBpbnB1dCAtPiBET00wICh0eXBlICdD
VFJMLWEnIHRocmVlIHRpbWVzIHRvIHN3aXRjaAppbnB1dCB0byBYZW4pCihYRU4pIEZyZWVkIDEw
NGtCIGluaXQgbWVtb3J5LgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpo
dHRwOi8vbGlzdHMueGVuLm9yZy94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xen.org Sat Sep 29 16:10:17 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 29 Sep 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 1THzbw-0002e0-43; Sat, 29 Sep 2012 16:09:48 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <singapore.mr.teo.en.ming@gmail.com>)
	id 1THzbu-0002dp-9Y; Sat, 29 Sep 2012 16:09:46 +0000
X-Env-Sender: singapore.mr.teo.en.ming@gmail.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1348934977!7639841!1
X-Originating-IP: [209.85.220.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4583 invoked from network); 29 Sep 2012 16:09:39 -0000
Received: from mail-pa0-f45.google.com (HELO mail-pa0-f45.google.com)
	(209.85.220.45)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Sep 2012 16:09:39 -0000
Received: by padfb10 with SMTP id fb10so3147816pad.32
	for <multiple recipients>; Sat, 29 Sep 2012 09:09: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:cc:subject
	:references:in-reply-to:content-type;
	bh=qRfFtARMCGhTFZFnk1WcoJ8EVH1Q2JJayUgnjKpLVLk=;
	b=povE/bgFNJE8NxgETMp2aKJDQ2rDcpvoQ9LHd9P+ZiZ+YDsdpJNw3GF1f8vMdxg7Ot
	l87K2NwIHc4RcNNeiOvkoOw593fVEKnub4ZO3ldPDgaxUwoxRAf3ONNq2FqPZKxdeHD8
	T7+xBGkGeCbbEaGACIUTBmQNrY8dl8X/mKlZt65ebGE7ayuugW3Ydhc5estMO5OPslUj
	OTnfB/qmm0L6JUblijF69xoANYZd/DjpayK5FSKeAapYbkA+Bft7EUS9IKQIiXiRzDOa
	QzBLI2Quqc5d9YDRP5D/xGFQ6jCIuIlvqiT+zKe7AQiPhoYsxWwLMucg9Ah4rnxPjJqI
	9QXA==
Received: by 10.68.224.133 with SMTP id rc5mr28518968pbc.130.1348934976787;
	Sat, 29 Sep 2012 09:09:36 -0700 (PDT)
Received: from [192.168.1.2] (cm152.gamma205.maxonline.com.sg.
	[202.156.205.152])
	by mx.google.com with ESMTPS id b4sm7398767pbw.28.2012.09.29.09.09.34
	(version=SSLv3 cipher=OTHER); Sat, 29 Sep 2012 09:09:35 -0700 (PDT)
Message-ID: <50671D3D.1010304@gmail.com>
Date: Sun, 30 Sep 2012 00:09:33 +0800
From: "Teo En Ming (Zhang Enming)" <singapore.mr.teo.en.ming@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120912 Thunderbird/15.0.1
MIME-Version: 1.0
To: "Teo En Ming (Zhang Enming)" <singapore.mr.teo.en.ming@gmail.com>
References: <5066F922.1090305@gmail.com>
In-Reply-To: <5066F922.1090305@gmail.com>
Content-Type: multipart/mixed; boundary="------------070102050809000405040603"
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] Unable to start Windows 8 HVM guest with Xen VGA
 Passthrough with Xen 4.2.1-pre
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<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.
--------------070102050809000405040603
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

On 29/09/2012 21:35, Teo En Ming (Zhang Enming) wrote:
> Hi,
>
> I have applied Xen VGA passthrough patches from David Techer's
> personal website to Xen 4.2.1-pre source tree. Everything compiled and
> installed smoothly. But when I tried to start Windows 8 HVM domU with
> VGA passthrough, it gave me the following error:
>
> xc: error: unable to allocate memory to the HVM guest. (16: device or
> resource busy): Internal error.
>
> There are no issues with Xen 4.2-unstable changeset 25099 however.
>

Attached are screenshots of the errors for Xen 4.2.1-pre and Xen 
configuration files.

The following are links to screenshots of the errors for Xen 4.2.1-pre.

http://i45.tinypic.com/2j3s7pj.jpg

http://i45.tinypic.com/95myc3.jpg

-- 
Yours sincerely,

Mr. Teo En Ming (Zhang Enming)
Singapore



--------------070102050809000405040603
Content-Type: text/plain; charset=UTF-8;
 name="start-windows"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
 filename="start-windows"

IyEvYmluL3NoCnNldCAteAojCiMgU3RhcnRzIFNob3Jld2FsbCBGaXJld2FsbApzdWRvIHNl
cnZpY2Ugc2hvcmV3YWxsIHJlc3RhcnQKIwojIExvYWRzIHBjaS1zdHViIGtlcm5lbCBtb2R1
bGUKc3VkbyBtb2Rwcm9iZSBwY2ktc3R1YgojCiMgUGFzc3Rocm91Z2ggRVZHQSBHZWZvcmNl
IEdUWCA1NjAgMSBHQiBHRERSNQojCmVjaG8gIlBhc3N0aHJvdWdoIEVWR0EgR2Vmb3JjZSBH
VFggNTYwIDEgR0IgR0REUjUiCnN1ZG8gY2htb2Qgbyt3IC9zeXMvYnVzL3BjaS9kcml2ZXJz
L3BjaS1zdHViL25ld19pZApzdWRvIGNobW9kIG8rdyAvc3lzL2J1cy9wY2kvZGV2aWNlcy8w
MDAwOjAxOjAwLjAvZHJpdmVyL3VuYmluZApzdWRvIGNobW9kIG8rdyAvc3lzL2J1cy9wY2kv
ZHJpdmVycy9wY2ktc3R1Yi9iaW5kCmVjaG8gIjEwZGUgMTIwMSIgPiAvc3lzL2J1cy9wY2kv
ZHJpdmVycy9wY2ktc3R1Yi9uZXdfaWQKZWNobyAiMDAwMDowMTowMC4wIiA+IC9zeXMvYnVz
L3BjaS9kZXZpY2VzLzAwMDA6MDE6MDAuMC9kcml2ZXIvdW5iaW5kCmVjaG8gIjAwMDA6MDE6
MDAuMCIgPiAvc3lzL2J1cy9wY2kvZHJpdmVycy9wY2ktc3R1Yi9iaW5kCiMKIyBQYXNzdGhy
b3VnaCBJbnRlbCBIRCBBdWRpbyBDb250cm9sbGVyCiMKZWNobyAiUGFzc3Rocm91Z2ggSW50
ZWwgSEQgQXVkaW8gQ29udHJvbGxlci4iCnN1ZG8gY2htb2Qgbyt3IC9zeXMvYnVzL3BjaS9k
cml2ZXJzL3BjaS1zdHViL25ld19pZApzdWRvIGNobW9kIG8rdyAvc3lzL2J1cy9wY2kvZGV2
aWNlcy8wMDAwOjAwOjFiLjAvZHJpdmVyL3VuYmluZApzdWRvIGNobW9kIG8rdyAvc3lzL2J1
cy9wY2kvZHJpdmVycy9wY2ktc3R1Yi9iaW5kCmVjaG8gIjgwODYgM2E2ZSIgPiAvc3lzL2J1
cy9wY2kvZHJpdmVycy9wY2ktc3R1Yi9uZXdfaWQKZWNobyAiMDAwMDowMDoxYi4wIiA+IC9z
eXMvYnVzL3BjaS9kZXZpY2VzLzAwMDA6MDA6MWIuMC9kcml2ZXIvdW5iaW5kCmVjaG8gIjAw
MDA6MDA6MWIuMCIgPiAvc3lzL2J1cy9wY2kvZHJpdmVycy9wY2ktc3R1Yi9iaW5kCiMKIyBT
bGVlcCBmb3IgMTAgc2VjcwojCnNsZWVwIDEwCiMKIyBQYXNzdGhyb3VnaCBVU0IgQ29udHJv
bGxlciAjMQojCmVjaG8gIlBhc3N0aHJvdWdoIFVTQiBDb250cm9sbGVyICMxLiIKc3VkbyBj
aG1vZCBvK3cgL3N5cy9idXMvcGNpL2RyaXZlcnMvcGNpLXN0dWIvbmV3X2lkCnN1ZG8gY2ht
b2Qgbyt3IC9zeXMvYnVzL3BjaS9kZXZpY2VzLzAwMDA6MDA6MWEuMC9kcml2ZXIvdW5iaW5k
CnN1ZG8gY2htb2Qgbyt3IC9zeXMvYnVzL3BjaS9kcml2ZXJzL3BjaS1zdHViL2JpbmQKZWNo
byAiODA4NiAzYTY3IiA+IC9zeXMvYnVzL3BjaS9kcml2ZXJzL3BjaS1zdHViL25ld19pZApl
Y2hvICIwMDAwOjAwOjFhLjAiID4gL3N5cy9idXMvcGNpL2RldmljZXMvMDAwMDowMDoxYS4w
L2RyaXZlci91bmJpbmQKZWNobyAiMDAwMDowMDoxYS4wIiA+IC9zeXMvYnVzL3BjaS9kcml2
ZXJzL3BjaS1zdHViL2JpbmQKIwojIFBhc3N0aHJvdWdoIFVTQiBDb250cm9sbGVyICMyCiMK
ZWNobyAiUGFzc3Rocm91Z2ggVVNCIENvbnRyb2xsZXIgIzIuIgpzdWRvIGNobW9kIG8rdyAv
c3lzL2J1cy9wY2kvZHJpdmVycy9wY2ktc3R1Yi9uZXdfaWQKc3VkbyBjaG1vZCBvK3cgL3N5
cy9idXMvcGNpL2RldmljZXMvMDAwMDowMDoxYS4xL2RyaXZlci91bmJpbmQKc3VkbyBjaG1v
ZCBvK3cgL3N5cy9idXMvcGNpL2RyaXZlcnMvcGNpLXN0dWIvYmluZAplY2hvICI4MDg2IDNh
NjgiID4gL3N5cy9idXMvcGNpL2RyaXZlcnMvcGNpLXN0dWIvbmV3X2lkCmVjaG8gIjAwMDA6
MDA6MWEuMSIgPiAvc3lzL2J1cy9wY2kvZGV2aWNlcy8wMDAwOjAwOjFhLjEvZHJpdmVyL3Vu
YmluZAplY2hvICIwMDAwOjAwOjFhLjEiID4gL3N5cy9idXMvcGNpL2RyaXZlcnMvcGNpLXN0
dWIvYmluZAojCiMgUGFzc3Rocm91Z2ggVVNCIENvbnRyb2xsZXIgIzMKIwplY2hvICJQYXNz
dGhyb3VnaCBVU0IgQ29udHJvbGxlciAjMy4iCnN1ZG8gY2htb2Qgbyt3IC9zeXMvYnVzL3Bj
aS9kcml2ZXJzL3BjaS1zdHViL25ld19pZApzdWRvIGNobW9kIG8rdyAvc3lzL2J1cy9wY2kv
ZGV2aWNlcy8wMDAwOjAwOjFhLjIvZHJpdmVyL3VuYmluZApzdWRvIGNobW9kIG8rdyAvc3lz
L2J1cy9wY2kvZHJpdmVycy9wY2ktc3R1Yi9iaW5kCmVjaG8gIjgwODYgM2E2OSIgPiAvc3lz
L2J1cy9wY2kvZHJpdmVycy9wY2ktc3R1Yi9uZXdfaWQKZWNobyAiMDAwMDowMDoxYS4yIiA+
IC9zeXMvYnVzL3BjaS9kZXZpY2VzLzAwMDA6MDA6MWEuMi9kcml2ZXIvdW5iaW5kCmVjaG8g
IjAwMDA6MDA6MWEuMiIgPiAvc3lzL2J1cy9wY2kvZHJpdmVycy9wY2ktc3R1Yi9iaW5kCiMK
IyBQYXNzdGhyb3VnaCBVU0IgQ29udHJvbGxlciAjNAojCmVjaG8gIlBhc3N0aHJvdWdoIFVT
QiBDb250cm9sbGVyICM0LiIKc3VkbyBjaG1vZCBvK3cgL3N5cy9idXMvcGNpL2RyaXZlcnMv
cGNpLXN0dWIvbmV3X2lkCnN1ZG8gY2htb2Qgbyt3IC9zeXMvYnVzL3BjaS9kZXZpY2VzLzAw
MDA6MDA6MWEuNy9kcml2ZXIvdW5iaW5kCnN1ZG8gY2htb2Qgbyt3IC9zeXMvYnVzL3BjaS9k
cml2ZXJzL3BjaS1zdHViL2JpbmQKZWNobyAiODA4NiAzYTZjIiA+IC9zeXMvYnVzL3BjaS9k
cml2ZXJzL3BjaS1zdHViL25ld19pZAplY2hvICIwMDAwOjAwOjFhLjciID4gL3N5cy9idXMv
cGNpL2RldmljZXMvMDAwMDowMDoxYS43L2RyaXZlci91bmJpbmQKZWNobyAiMDAwMDowMDox
YS43IiA+IC9zeXMvYnVzL3BjaS9kcml2ZXJzL3BjaS1zdHViL2JpbmQKIwojIFBhc3N0aHJv
dWdoIFVTQiBDb250cm9sbGVyICM1CiMKZWNobyAiUGFzc3Rocm91Z2ggVVNCIENvbnRyb2xs
ZXIgIzUuIgpzdWRvIGNobW9kIG8rdyAvc3lzL2J1cy9wY2kvZHJpdmVycy9wY2ktc3R1Yi9u
ZXdfaWQKc3VkbyBjaG1vZCBvK3cgL3N5cy9idXMvcGNpL2RldmljZXMvMDAwMDowMDoxZC4w
L2RyaXZlci91bmJpbmQKc3VkbyBjaG1vZCBvK3cgL3N5cy9idXMvcGNpL2RyaXZlcnMvcGNp
LXN0dWIvYmluZAplY2hvICI4MDg2IDNhNjQiID4gL3N5cy9idXMvcGNpL2RyaXZlcnMvcGNp
LXN0dWIvbmV3X2lkCmVjaG8gIjAwMDA6MDA6MWQuMCIgPiAvc3lzL2J1cy9wY2kvZGV2aWNl
cy8wMDAwOjAwOjFkLjAvZHJpdmVyL3VuYmluZAplY2hvICIwMDAwOjAwOjFkLjAiID4gL3N5
cy9idXMvcGNpL2RyaXZlcnMvcGNpLXN0dWIvYmluZAojCiMgUGFzc3Rocm91Z2ggVVNCIENv
bnRyb2xsZXIgIzYKIwplY2hvICJQYXNzdGhyb3VnaCBVU0IgQ29udHJvbGxlciAjNi4iCnN1
ZG8gY2htb2Qgbyt3IC9zeXMvYnVzL3BjaS9kcml2ZXJzL3BjaS1zdHViL25ld19pZApzdWRv
IGNobW9kIG8rdyAvc3lzL2J1cy9wY2kvZGV2aWNlcy8wMDAwOjAwOjFkLjEvZHJpdmVyL3Vu
YmluZApzdWRvIGNobW9kIG8rdyAvc3lzL2J1cy9wY2kvZHJpdmVycy9wY2ktc3R1Yi9iaW5k
CmVjaG8gIjgwODYgM2E2NSIgPiAvc3lzL2J1cy9wY2kvZHJpdmVycy9wY2ktc3R1Yi9uZXdf
aWQKZWNobyAiMDAwMDowMDoxZC4xIiA+IC9zeXMvYnVzL3BjaS9kZXZpY2VzLzAwMDA6MDA6
MWQuMS9kcml2ZXIvdW5iaW5kCmVjaG8gIjAwMDA6MDA6MWQuMSIgPiAvc3lzL2J1cy9wY2kv
ZHJpdmVycy9wY2ktc3R1Yi9iaW5kCiMKIyBQYXNzdGhyb3VnaCBVU0IgQ29udHJvbGxlciAj
NwojCmVjaG8gIlBhc3N0aHJvdWdoIFVTQiBDb250cm9sbGVyICM3LiIKc3VkbyBjaG1vZCBv
K3cgL3N5cy9idXMvcGNpL2RyaXZlcnMvcGNpLXN0dWIvbmV3X2lkCnN1ZG8gY2htb2Qgbyt3
IC9zeXMvYnVzL3BjaS9kZXZpY2VzLzAwMDA6MDA6MWQuMi9kcml2ZXIvdW5iaW5kCnN1ZG8g
Y2htb2Qgbyt3IC9zeXMvYnVzL3BjaS9kcml2ZXJzL3BjaS1zdHViL2JpbmQKZWNobyAiODA4
NiAzYTY2IiA+IC9zeXMvYnVzL3BjaS9kcml2ZXJzL3BjaS1zdHViL25ld19pZAplY2hvICIw
MDAwOjAwOjFkLjIiID4gL3N5cy9idXMvcGNpL2RldmljZXMvMDAwMDowMDoxZC4yL2RyaXZl
ci91bmJpbmQKZWNobyAiMDAwMDowMDoxZC4yIiA+IC9zeXMvYnVzL3BjaS9kcml2ZXJzL3Bj
aS1zdHViL2JpbmQKIwojIFBhc3N0aHJvdWdoIFVTQiBDb250cm9sbGVyICM4CiMKZWNobyAi
UGFzc3Rocm91Z2ggVVNCIENvbnRyb2xsZXIgIzguIgpzdWRvIGNobW9kIG8rdyAvc3lzL2J1
cy9wY2kvZHJpdmVycy9wY2ktc3R1Yi9uZXdfaWQKc3VkbyBjaG1vZCBvK3cgL3N5cy9idXMv
cGNpL2RldmljZXMvMDAwMDowMDoxZC43L2RyaXZlci91bmJpbmQKc3VkbyBjaG1vZCBvK3cg
L3N5cy9idXMvcGNpL2RyaXZlcnMvcGNpLXN0dWIvYmluZAplY2hvICI4MDg2IDNhNmEiID4g
L3N5cy9idXMvcGNpL2RyaXZlcnMvcGNpLXN0dWIvbmV3X2lkCmVjaG8gIjAwMDA6MDA6MWQu
NyIgPiAvc3lzL2J1cy9wY2kvZGV2aWNlcy8wMDAwOjAwOjFkLjcvZHJpdmVyL3VuYmluZApl
Y2hvICIwMDAwOjAwOjFkLjciID4gL3N5cy9idXMvcGNpL2RyaXZlcnMvcGNpLXN0dWIvYmlu
ZAoKIwojIFdhaXQgZm9yIDEwIHNlY29uZHMKIwpzbGVlcCAxMAojCiMgU3RhcnQgV2luZG93
cyBIVk0gZG9tVSB3aXRoIFZHQSBQYXNzdGhyb3VnaAojCiNzdWRvIHhsIGNyZWF0ZSAvZXRj
L3hlbi9XaW5kb3dzWFBIb21lRWRpdGlvblNQMwpzdWRvIHhsIGNyZWF0ZSAvZXRjL3hlbi93
aW5kb3dzOAoK
--------------070102050809000405040603
Content-Type: text/plain; charset=UTF-8;
 name="windows8"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
 filename="windows8"

IyBYTCBkb21haW4gY29uZmlndXJhdGlvbiBmaWxlIGZvciBXaW5kb3dzIDggQ29uc3VtZXIg
UHJldmlldyA2NC1iaXQgRW5nbGlzaCBIVk0gZG9tVQojIFBsZWFzZSByZWZlciB0byAibWFu
IHhsLmNmZyIgZm9yIGZ1cnRoZXIgZXhwbGFuYXRpb25zLgojIFNlZSBhbHNvIGRvY3MvbWlz
Yy94bC1uZXR3b3JrLWNvbmZpZ3VyYXRpb24ubWFya2Rvd24gYW5kCiMgZG9jcy9taXNjL3hs
LWRpc2stY29uZmlndXJhdGlvbi50eHQKIyBXcml0dGVuIGJ5IFRlbyBFbiBNaW5nIChaaGFu
ZyBFbm1pbmcpCiMgRW1haWw6IHRlby5lbi5taW5nQGdtYWlsLmNvbQojIE1vYmlsZSBQaG9u
ZTogKzY1LTgzNjktMjYxOAojIENvdW50cnk6IFNpbmdhcG9yZQojIERhdGU6IDE4IE1hciAy
MDEyIFN1bgpuYW1lPSJXaW5kb3dzOCIKIyBQcm9kdWN0IEtleTogRE5KWEotN1hCVzgtMjM3
OFQtWDIyVFgtQktHN0oKYnVpbGRlcj0iaHZtIgp2Y3B1cz0yCm1lbW9yeT0yMDQ4Cm9uX3Bv
d2Vyb2ZmPSJkZXN0cm95Igpvbl9yZWJvb3Q9InJlc3RhcnQiCm9uX2NyYXNoPSJkZXN0cm95
IgpkaXNrPVsgJ2Zvcm1hdD1yYXcsIHZkZXY9aGRhLCBhY2Nlc3M9cncsIHRhcmdldD0vZXRj
L3hlbi9pbWFnZXMvd2luZG93czguaW1nJywgJ2Zvcm1hdD1yYXcsIHZkZXY9aGRjLCBhY2Nl
c3M9cm8sIGRldnR5cGU9Y2Ryb20sIHRhcmdldD0vaG9tZS90ZW8tZW4tbWluZy9XaW5kb3dz
OC1SZWxlYXNlUHJldmlldy02NGJpdC1FbmdsaXNoLmlzbycgXQojdmlmPVsgJ2JyaWRnZT12
aXJicjAsdHlwZT1pb2VtdSxtb2RlbD1lMTAwMCcgXQojYm9vdD1bY3xkfG5dCiNTZWxlY3Rz
IHRoZSBlbXVsYXRlZCB2aXJ0dWFsIGRldmljZSB0byBib290IGZyb20uIE9wdGlvbnMgYXJl
IGhhcmQgZGlzayAoYyksIGNkLXJvbSAoZCkgb3IgbmV0d29yay9QWEUgKG4pLgojTXVsdGlw
bGUgb3B0aW9ucyBjYW4gYmUgZ2l2ZW4gYW5kIHdpbGwgYmUgYXR0ZW1wdGVkIGluIHRoZSBv
cmRlciB0aGV5IGFyZSBnaXZlbi4gZS5nLiB0byBib290IGZyb20gY2Qtcm9tCiNidXQgZmFs
bGJhY2sgdG8gdGhlIGhhcmQgZGlzayB5b3UgY2FuIGdpdmUgZGMuIFRoZSBkZWZhdWx0IGlz
IGNkLgpib290PSJkYyIKYWNwaT0xCiN4ZW5fcGxhdGZvcm1fcGNpPTEKI3ZpcmlkaWFuPTEK
I3N0ZHZnYT0xCnZuYz0xCnZuY2xpc3Rlbj0iMTkyLjE2OC4xLjIiCnZuY2Rpc3BsYXk9MAp2
bmN1bnVzZWQ9MQp2bmNwYXNzd2Q9IiIKc2RsPTAKdXNiPTEKdXNiZGV2aWNlPSJ0YWJsZXQi
CiMgRW5hYmxlIFhlbiBWR0EgUGFzc3Rocm91Z2gKZ2Z4X3Bhc3N0aHJ1PTEKIyBWR0EgUGFz
c3Rocm91Z2ggRVZHQSBHZWZvcmNlIEdUWCA1NjAgMSBHQiBHRERSNS4KcGNpID0gWyAnMDE6
MDAuMCcsJzAwOjFiLjAnLCcwMDoxYS4wJywnMDA6MWEuMScsJzAwOjFhLjInLCcwMDoxYS43
JywnMDA6MWQuMCcsJzAwOjFkLjEnLCcwMDoxZC4yJywnMDA6MWQuNycgXQojIFBDSSBQYXNz
dGhyb3VnaCBJbnRlbCBIRCBBdWRpbyBDb250cm9sbGVyLgojcGNpID0gWyAnMDA6MWIuMCcg
XQojIFBDSSBQYXNzdGhyb3VnaCBhbGwgdGhlIFVTQiBDb250cm9sbGVycy4KIyBwY2kgPSBb
ICcwMDoxYS4wJywnMDA6MWEuMScsJzAwOjFhLjInLCcwMDoxYS43JywnMDA6MWQuMCcsJzAw
OjFkLjEnLCcwMDoxZC4yJywnMDA6MWQuNycgXQoKCg==
--------------070102050809000405040603
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--------------070102050809000405040603--


From xen-devel-bounces@lists.xen.org Sat Sep 29 16:10:17 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 29 Sep 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 1THzbw-0002e0-43; Sat, 29 Sep 2012 16:09:48 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <singapore.mr.teo.en.ming@gmail.com>)
	id 1THzbu-0002dp-9Y; Sat, 29 Sep 2012 16:09:46 +0000
X-Env-Sender: singapore.mr.teo.en.ming@gmail.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1348934977!7639841!1
X-Originating-IP: [209.85.220.45]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4583 invoked from network); 29 Sep 2012 16:09:39 -0000
Received: from mail-pa0-f45.google.com (HELO mail-pa0-f45.google.com)
	(209.85.220.45)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Sep 2012 16:09:39 -0000
Received: by padfb10 with SMTP id fb10so3147816pad.32
	for <multiple recipients>; Sat, 29 Sep 2012 09:09: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:cc:subject
	:references:in-reply-to:content-type;
	bh=qRfFtARMCGhTFZFnk1WcoJ8EVH1Q2JJayUgnjKpLVLk=;
	b=povE/bgFNJE8NxgETMp2aKJDQ2rDcpvoQ9LHd9P+ZiZ+YDsdpJNw3GF1f8vMdxg7Ot
	l87K2NwIHc4RcNNeiOvkoOw593fVEKnub4ZO3ldPDgaxUwoxRAf3ONNq2FqPZKxdeHD8
	T7+xBGkGeCbbEaGACIUTBmQNrY8dl8X/mKlZt65ebGE7ayuugW3Ydhc5estMO5OPslUj
	OTnfB/qmm0L6JUblijF69xoANYZd/DjpayK5FSKeAapYbkA+Bft7EUS9IKQIiXiRzDOa
	QzBLI2Quqc5d9YDRP5D/xGFQ6jCIuIlvqiT+zKe7AQiPhoYsxWwLMucg9Ah4rnxPjJqI
	9QXA==
Received: by 10.68.224.133 with SMTP id rc5mr28518968pbc.130.1348934976787;
	Sat, 29 Sep 2012 09:09:36 -0700 (PDT)
Received: from [192.168.1.2] (cm152.gamma205.maxonline.com.sg.
	[202.156.205.152])
	by mx.google.com with ESMTPS id b4sm7398767pbw.28.2012.09.29.09.09.34
	(version=SSLv3 cipher=OTHER); Sat, 29 Sep 2012 09:09:35 -0700 (PDT)
Message-ID: <50671D3D.1010304@gmail.com>
Date: Sun, 30 Sep 2012 00:09:33 +0800
From: "Teo En Ming (Zhang Enming)" <singapore.mr.teo.en.ming@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120912 Thunderbird/15.0.1
MIME-Version: 1.0
To: "Teo En Ming (Zhang Enming)" <singapore.mr.teo.en.ming@gmail.com>
References: <5066F922.1090305@gmail.com>
In-Reply-To: <5066F922.1090305@gmail.com>
Content-Type: multipart/mixed; boundary="------------070102050809000405040603"
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] Unable to start Windows 8 HVM guest with Xen VGA
 Passthrough with Xen 4.2.1-pre
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<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.
--------------070102050809000405040603
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

On 29/09/2012 21:35, Teo En Ming (Zhang Enming) wrote:
> Hi,
>
> I have applied Xen VGA passthrough patches from David Techer's
> personal website to Xen 4.2.1-pre source tree. Everything compiled and
> installed smoothly. But when I tried to start Windows 8 HVM domU with
> VGA passthrough, it gave me the following error:
>
> xc: error: unable to allocate memory to the HVM guest. (16: device or
> resource busy): Internal error.
>
> There are no issues with Xen 4.2-unstable changeset 25099 however.
>

Attached are screenshots of the errors for Xen 4.2.1-pre and Xen 
configuration files.

The following are links to screenshots of the errors for Xen 4.2.1-pre.

http://i45.tinypic.com/2j3s7pj.jpg

http://i45.tinypic.com/95myc3.jpg

-- 
Yours sincerely,

Mr. Teo En Ming (Zhang Enming)
Singapore



--------------070102050809000405040603
Content-Type: text/plain; charset=UTF-8;
 name="start-windows"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
 filename="start-windows"

IyEvYmluL3NoCnNldCAteAojCiMgU3RhcnRzIFNob3Jld2FsbCBGaXJld2FsbApzdWRvIHNl
cnZpY2Ugc2hvcmV3YWxsIHJlc3RhcnQKIwojIExvYWRzIHBjaS1zdHViIGtlcm5lbCBtb2R1
bGUKc3VkbyBtb2Rwcm9iZSBwY2ktc3R1YgojCiMgUGFzc3Rocm91Z2ggRVZHQSBHZWZvcmNl
IEdUWCA1NjAgMSBHQiBHRERSNQojCmVjaG8gIlBhc3N0aHJvdWdoIEVWR0EgR2Vmb3JjZSBH
VFggNTYwIDEgR0IgR0REUjUiCnN1ZG8gY2htb2Qgbyt3IC9zeXMvYnVzL3BjaS9kcml2ZXJz
L3BjaS1zdHViL25ld19pZApzdWRvIGNobW9kIG8rdyAvc3lzL2J1cy9wY2kvZGV2aWNlcy8w
MDAwOjAxOjAwLjAvZHJpdmVyL3VuYmluZApzdWRvIGNobW9kIG8rdyAvc3lzL2J1cy9wY2kv
ZHJpdmVycy9wY2ktc3R1Yi9iaW5kCmVjaG8gIjEwZGUgMTIwMSIgPiAvc3lzL2J1cy9wY2kv
ZHJpdmVycy9wY2ktc3R1Yi9uZXdfaWQKZWNobyAiMDAwMDowMTowMC4wIiA+IC9zeXMvYnVz
L3BjaS9kZXZpY2VzLzAwMDA6MDE6MDAuMC9kcml2ZXIvdW5iaW5kCmVjaG8gIjAwMDA6MDE6
MDAuMCIgPiAvc3lzL2J1cy9wY2kvZHJpdmVycy9wY2ktc3R1Yi9iaW5kCiMKIyBQYXNzdGhy
b3VnaCBJbnRlbCBIRCBBdWRpbyBDb250cm9sbGVyCiMKZWNobyAiUGFzc3Rocm91Z2ggSW50
ZWwgSEQgQXVkaW8gQ29udHJvbGxlci4iCnN1ZG8gY2htb2Qgbyt3IC9zeXMvYnVzL3BjaS9k
cml2ZXJzL3BjaS1zdHViL25ld19pZApzdWRvIGNobW9kIG8rdyAvc3lzL2J1cy9wY2kvZGV2
aWNlcy8wMDAwOjAwOjFiLjAvZHJpdmVyL3VuYmluZApzdWRvIGNobW9kIG8rdyAvc3lzL2J1
cy9wY2kvZHJpdmVycy9wY2ktc3R1Yi9iaW5kCmVjaG8gIjgwODYgM2E2ZSIgPiAvc3lzL2J1
cy9wY2kvZHJpdmVycy9wY2ktc3R1Yi9uZXdfaWQKZWNobyAiMDAwMDowMDoxYi4wIiA+IC9z
eXMvYnVzL3BjaS9kZXZpY2VzLzAwMDA6MDA6MWIuMC9kcml2ZXIvdW5iaW5kCmVjaG8gIjAw
MDA6MDA6MWIuMCIgPiAvc3lzL2J1cy9wY2kvZHJpdmVycy9wY2ktc3R1Yi9iaW5kCiMKIyBT
bGVlcCBmb3IgMTAgc2VjcwojCnNsZWVwIDEwCiMKIyBQYXNzdGhyb3VnaCBVU0IgQ29udHJv
bGxlciAjMQojCmVjaG8gIlBhc3N0aHJvdWdoIFVTQiBDb250cm9sbGVyICMxLiIKc3VkbyBj
aG1vZCBvK3cgL3N5cy9idXMvcGNpL2RyaXZlcnMvcGNpLXN0dWIvbmV3X2lkCnN1ZG8gY2ht
b2Qgbyt3IC9zeXMvYnVzL3BjaS9kZXZpY2VzLzAwMDA6MDA6MWEuMC9kcml2ZXIvdW5iaW5k
CnN1ZG8gY2htb2Qgbyt3IC9zeXMvYnVzL3BjaS9kcml2ZXJzL3BjaS1zdHViL2JpbmQKZWNo
byAiODA4NiAzYTY3IiA+IC9zeXMvYnVzL3BjaS9kcml2ZXJzL3BjaS1zdHViL25ld19pZApl
Y2hvICIwMDAwOjAwOjFhLjAiID4gL3N5cy9idXMvcGNpL2RldmljZXMvMDAwMDowMDoxYS4w
L2RyaXZlci91bmJpbmQKZWNobyAiMDAwMDowMDoxYS4wIiA+IC9zeXMvYnVzL3BjaS9kcml2
ZXJzL3BjaS1zdHViL2JpbmQKIwojIFBhc3N0aHJvdWdoIFVTQiBDb250cm9sbGVyICMyCiMK
ZWNobyAiUGFzc3Rocm91Z2ggVVNCIENvbnRyb2xsZXIgIzIuIgpzdWRvIGNobW9kIG8rdyAv
c3lzL2J1cy9wY2kvZHJpdmVycy9wY2ktc3R1Yi9uZXdfaWQKc3VkbyBjaG1vZCBvK3cgL3N5
cy9idXMvcGNpL2RldmljZXMvMDAwMDowMDoxYS4xL2RyaXZlci91bmJpbmQKc3VkbyBjaG1v
ZCBvK3cgL3N5cy9idXMvcGNpL2RyaXZlcnMvcGNpLXN0dWIvYmluZAplY2hvICI4MDg2IDNh
NjgiID4gL3N5cy9idXMvcGNpL2RyaXZlcnMvcGNpLXN0dWIvbmV3X2lkCmVjaG8gIjAwMDA6
MDA6MWEuMSIgPiAvc3lzL2J1cy9wY2kvZGV2aWNlcy8wMDAwOjAwOjFhLjEvZHJpdmVyL3Vu
YmluZAplY2hvICIwMDAwOjAwOjFhLjEiID4gL3N5cy9idXMvcGNpL2RyaXZlcnMvcGNpLXN0
dWIvYmluZAojCiMgUGFzc3Rocm91Z2ggVVNCIENvbnRyb2xsZXIgIzMKIwplY2hvICJQYXNz
dGhyb3VnaCBVU0IgQ29udHJvbGxlciAjMy4iCnN1ZG8gY2htb2Qgbyt3IC9zeXMvYnVzL3Bj
aS9kcml2ZXJzL3BjaS1zdHViL25ld19pZApzdWRvIGNobW9kIG8rdyAvc3lzL2J1cy9wY2kv
ZGV2aWNlcy8wMDAwOjAwOjFhLjIvZHJpdmVyL3VuYmluZApzdWRvIGNobW9kIG8rdyAvc3lz
L2J1cy9wY2kvZHJpdmVycy9wY2ktc3R1Yi9iaW5kCmVjaG8gIjgwODYgM2E2OSIgPiAvc3lz
L2J1cy9wY2kvZHJpdmVycy9wY2ktc3R1Yi9uZXdfaWQKZWNobyAiMDAwMDowMDoxYS4yIiA+
IC9zeXMvYnVzL3BjaS9kZXZpY2VzLzAwMDA6MDA6MWEuMi9kcml2ZXIvdW5iaW5kCmVjaG8g
IjAwMDA6MDA6MWEuMiIgPiAvc3lzL2J1cy9wY2kvZHJpdmVycy9wY2ktc3R1Yi9iaW5kCiMK
IyBQYXNzdGhyb3VnaCBVU0IgQ29udHJvbGxlciAjNAojCmVjaG8gIlBhc3N0aHJvdWdoIFVT
QiBDb250cm9sbGVyICM0LiIKc3VkbyBjaG1vZCBvK3cgL3N5cy9idXMvcGNpL2RyaXZlcnMv
cGNpLXN0dWIvbmV3X2lkCnN1ZG8gY2htb2Qgbyt3IC9zeXMvYnVzL3BjaS9kZXZpY2VzLzAw
MDA6MDA6MWEuNy9kcml2ZXIvdW5iaW5kCnN1ZG8gY2htb2Qgbyt3IC9zeXMvYnVzL3BjaS9k
cml2ZXJzL3BjaS1zdHViL2JpbmQKZWNobyAiODA4NiAzYTZjIiA+IC9zeXMvYnVzL3BjaS9k
cml2ZXJzL3BjaS1zdHViL25ld19pZAplY2hvICIwMDAwOjAwOjFhLjciID4gL3N5cy9idXMv
cGNpL2RldmljZXMvMDAwMDowMDoxYS43L2RyaXZlci91bmJpbmQKZWNobyAiMDAwMDowMDox
YS43IiA+IC9zeXMvYnVzL3BjaS9kcml2ZXJzL3BjaS1zdHViL2JpbmQKIwojIFBhc3N0aHJv
dWdoIFVTQiBDb250cm9sbGVyICM1CiMKZWNobyAiUGFzc3Rocm91Z2ggVVNCIENvbnRyb2xs
ZXIgIzUuIgpzdWRvIGNobW9kIG8rdyAvc3lzL2J1cy9wY2kvZHJpdmVycy9wY2ktc3R1Yi9u
ZXdfaWQKc3VkbyBjaG1vZCBvK3cgL3N5cy9idXMvcGNpL2RldmljZXMvMDAwMDowMDoxZC4w
L2RyaXZlci91bmJpbmQKc3VkbyBjaG1vZCBvK3cgL3N5cy9idXMvcGNpL2RyaXZlcnMvcGNp
LXN0dWIvYmluZAplY2hvICI4MDg2IDNhNjQiID4gL3N5cy9idXMvcGNpL2RyaXZlcnMvcGNp
LXN0dWIvbmV3X2lkCmVjaG8gIjAwMDA6MDA6MWQuMCIgPiAvc3lzL2J1cy9wY2kvZGV2aWNl
cy8wMDAwOjAwOjFkLjAvZHJpdmVyL3VuYmluZAplY2hvICIwMDAwOjAwOjFkLjAiID4gL3N5
cy9idXMvcGNpL2RyaXZlcnMvcGNpLXN0dWIvYmluZAojCiMgUGFzc3Rocm91Z2ggVVNCIENv
bnRyb2xsZXIgIzYKIwplY2hvICJQYXNzdGhyb3VnaCBVU0IgQ29udHJvbGxlciAjNi4iCnN1
ZG8gY2htb2Qgbyt3IC9zeXMvYnVzL3BjaS9kcml2ZXJzL3BjaS1zdHViL25ld19pZApzdWRv
IGNobW9kIG8rdyAvc3lzL2J1cy9wY2kvZGV2aWNlcy8wMDAwOjAwOjFkLjEvZHJpdmVyL3Vu
YmluZApzdWRvIGNobW9kIG8rdyAvc3lzL2J1cy9wY2kvZHJpdmVycy9wY2ktc3R1Yi9iaW5k
CmVjaG8gIjgwODYgM2E2NSIgPiAvc3lzL2J1cy9wY2kvZHJpdmVycy9wY2ktc3R1Yi9uZXdf
aWQKZWNobyAiMDAwMDowMDoxZC4xIiA+IC9zeXMvYnVzL3BjaS9kZXZpY2VzLzAwMDA6MDA6
MWQuMS9kcml2ZXIvdW5iaW5kCmVjaG8gIjAwMDA6MDA6MWQuMSIgPiAvc3lzL2J1cy9wY2kv
ZHJpdmVycy9wY2ktc3R1Yi9iaW5kCiMKIyBQYXNzdGhyb3VnaCBVU0IgQ29udHJvbGxlciAj
NwojCmVjaG8gIlBhc3N0aHJvdWdoIFVTQiBDb250cm9sbGVyICM3LiIKc3VkbyBjaG1vZCBv
K3cgL3N5cy9idXMvcGNpL2RyaXZlcnMvcGNpLXN0dWIvbmV3X2lkCnN1ZG8gY2htb2Qgbyt3
IC9zeXMvYnVzL3BjaS9kZXZpY2VzLzAwMDA6MDA6MWQuMi9kcml2ZXIvdW5iaW5kCnN1ZG8g
Y2htb2Qgbyt3IC9zeXMvYnVzL3BjaS9kcml2ZXJzL3BjaS1zdHViL2JpbmQKZWNobyAiODA4
NiAzYTY2IiA+IC9zeXMvYnVzL3BjaS9kcml2ZXJzL3BjaS1zdHViL25ld19pZAplY2hvICIw
MDAwOjAwOjFkLjIiID4gL3N5cy9idXMvcGNpL2RldmljZXMvMDAwMDowMDoxZC4yL2RyaXZl
ci91bmJpbmQKZWNobyAiMDAwMDowMDoxZC4yIiA+IC9zeXMvYnVzL3BjaS9kcml2ZXJzL3Bj
aS1zdHViL2JpbmQKIwojIFBhc3N0aHJvdWdoIFVTQiBDb250cm9sbGVyICM4CiMKZWNobyAi
UGFzc3Rocm91Z2ggVVNCIENvbnRyb2xsZXIgIzguIgpzdWRvIGNobW9kIG8rdyAvc3lzL2J1
cy9wY2kvZHJpdmVycy9wY2ktc3R1Yi9uZXdfaWQKc3VkbyBjaG1vZCBvK3cgL3N5cy9idXMv
cGNpL2RldmljZXMvMDAwMDowMDoxZC43L2RyaXZlci91bmJpbmQKc3VkbyBjaG1vZCBvK3cg
L3N5cy9idXMvcGNpL2RyaXZlcnMvcGNpLXN0dWIvYmluZAplY2hvICI4MDg2IDNhNmEiID4g
L3N5cy9idXMvcGNpL2RyaXZlcnMvcGNpLXN0dWIvbmV3X2lkCmVjaG8gIjAwMDA6MDA6MWQu
NyIgPiAvc3lzL2J1cy9wY2kvZGV2aWNlcy8wMDAwOjAwOjFkLjcvZHJpdmVyL3VuYmluZApl
Y2hvICIwMDAwOjAwOjFkLjciID4gL3N5cy9idXMvcGNpL2RyaXZlcnMvcGNpLXN0dWIvYmlu
ZAoKIwojIFdhaXQgZm9yIDEwIHNlY29uZHMKIwpzbGVlcCAxMAojCiMgU3RhcnQgV2luZG93
cyBIVk0gZG9tVSB3aXRoIFZHQSBQYXNzdGhyb3VnaAojCiNzdWRvIHhsIGNyZWF0ZSAvZXRj
L3hlbi9XaW5kb3dzWFBIb21lRWRpdGlvblNQMwpzdWRvIHhsIGNyZWF0ZSAvZXRjL3hlbi93
aW5kb3dzOAoK
--------------070102050809000405040603
Content-Type: text/plain; charset=UTF-8;
 name="windows8"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
 filename="windows8"

IyBYTCBkb21haW4gY29uZmlndXJhdGlvbiBmaWxlIGZvciBXaW5kb3dzIDggQ29uc3VtZXIg
UHJldmlldyA2NC1iaXQgRW5nbGlzaCBIVk0gZG9tVQojIFBsZWFzZSByZWZlciB0byAibWFu
IHhsLmNmZyIgZm9yIGZ1cnRoZXIgZXhwbGFuYXRpb25zLgojIFNlZSBhbHNvIGRvY3MvbWlz
Yy94bC1uZXR3b3JrLWNvbmZpZ3VyYXRpb24ubWFya2Rvd24gYW5kCiMgZG9jcy9taXNjL3hs
LWRpc2stY29uZmlndXJhdGlvbi50eHQKIyBXcml0dGVuIGJ5IFRlbyBFbiBNaW5nIChaaGFu
ZyBFbm1pbmcpCiMgRW1haWw6IHRlby5lbi5taW5nQGdtYWlsLmNvbQojIE1vYmlsZSBQaG9u
ZTogKzY1LTgzNjktMjYxOAojIENvdW50cnk6IFNpbmdhcG9yZQojIERhdGU6IDE4IE1hciAy
MDEyIFN1bgpuYW1lPSJXaW5kb3dzOCIKIyBQcm9kdWN0IEtleTogRE5KWEotN1hCVzgtMjM3
OFQtWDIyVFgtQktHN0oKYnVpbGRlcj0iaHZtIgp2Y3B1cz0yCm1lbW9yeT0yMDQ4Cm9uX3Bv
d2Vyb2ZmPSJkZXN0cm95Igpvbl9yZWJvb3Q9InJlc3RhcnQiCm9uX2NyYXNoPSJkZXN0cm95
IgpkaXNrPVsgJ2Zvcm1hdD1yYXcsIHZkZXY9aGRhLCBhY2Nlc3M9cncsIHRhcmdldD0vZXRj
L3hlbi9pbWFnZXMvd2luZG93czguaW1nJywgJ2Zvcm1hdD1yYXcsIHZkZXY9aGRjLCBhY2Nl
c3M9cm8sIGRldnR5cGU9Y2Ryb20sIHRhcmdldD0vaG9tZS90ZW8tZW4tbWluZy9XaW5kb3dz
OC1SZWxlYXNlUHJldmlldy02NGJpdC1FbmdsaXNoLmlzbycgXQojdmlmPVsgJ2JyaWRnZT12
aXJicjAsdHlwZT1pb2VtdSxtb2RlbD1lMTAwMCcgXQojYm9vdD1bY3xkfG5dCiNTZWxlY3Rz
IHRoZSBlbXVsYXRlZCB2aXJ0dWFsIGRldmljZSB0byBib290IGZyb20uIE9wdGlvbnMgYXJl
IGhhcmQgZGlzayAoYyksIGNkLXJvbSAoZCkgb3IgbmV0d29yay9QWEUgKG4pLgojTXVsdGlw
bGUgb3B0aW9ucyBjYW4gYmUgZ2l2ZW4gYW5kIHdpbGwgYmUgYXR0ZW1wdGVkIGluIHRoZSBv
cmRlciB0aGV5IGFyZSBnaXZlbi4gZS5nLiB0byBib290IGZyb20gY2Qtcm9tCiNidXQgZmFs
bGJhY2sgdG8gdGhlIGhhcmQgZGlzayB5b3UgY2FuIGdpdmUgZGMuIFRoZSBkZWZhdWx0IGlz
IGNkLgpib290PSJkYyIKYWNwaT0xCiN4ZW5fcGxhdGZvcm1fcGNpPTEKI3ZpcmlkaWFuPTEK
I3N0ZHZnYT0xCnZuYz0xCnZuY2xpc3Rlbj0iMTkyLjE2OC4xLjIiCnZuY2Rpc3BsYXk9MAp2
bmN1bnVzZWQ9MQp2bmNwYXNzd2Q9IiIKc2RsPTAKdXNiPTEKdXNiZGV2aWNlPSJ0YWJsZXQi
CiMgRW5hYmxlIFhlbiBWR0EgUGFzc3Rocm91Z2gKZ2Z4X3Bhc3N0aHJ1PTEKIyBWR0EgUGFz
c3Rocm91Z2ggRVZHQSBHZWZvcmNlIEdUWCA1NjAgMSBHQiBHRERSNS4KcGNpID0gWyAnMDE6
MDAuMCcsJzAwOjFiLjAnLCcwMDoxYS4wJywnMDA6MWEuMScsJzAwOjFhLjInLCcwMDoxYS43
JywnMDA6MWQuMCcsJzAwOjFkLjEnLCcwMDoxZC4yJywnMDA6MWQuNycgXQojIFBDSSBQYXNz
dGhyb3VnaCBJbnRlbCBIRCBBdWRpbyBDb250cm9sbGVyLgojcGNpID0gWyAnMDA6MWIuMCcg
XQojIFBDSSBQYXNzdGhyb3VnaCBhbGwgdGhlIFVTQiBDb250cm9sbGVycy4KIyBwY2kgPSBb
ICcwMDoxYS4wJywnMDA6MWEuMScsJzAwOjFhLjInLCcwMDoxYS43JywnMDA6MWQuMCcsJzAw
OjFkLjEnLCcwMDoxZC4yJywnMDA6MWQuNycgXQoKCg==
--------------070102050809000405040603
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--------------070102050809000405040603--


From xen-devel-bounces@lists.xen.org Sat Sep 29 16:22:54 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 29 Sep 2012 16:22:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1THzoF-00034D-5b; Sat, 29 Sep 2012 16:22:31 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <cdelorme@gmail.com>)
	id 1THzoE-000342-5K; Sat, 29 Sep 2012 16:22:30 +0000
X-Env-Sender: cdelorme@gmail.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1348935742!5866305!1
X-Originating-IP: [209.85.214.173]
X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20374 invoked from network); 29 Sep 2012 16:22:23 -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;
	29 Sep 2012 16:22:23 -0000
Received: by obbwc18 with SMTP id wc18so2390814obb.32
	for <multiple recipients>; Sat, 29 Sep 2012 09:22:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=cuthgEU24jdUcadhi8XBWi8lXF439BTxjfsq7aabTtg=;
	b=b6u+ed3N81uS408n88iXUYQAKQSiaqE4p9jAt6LaTnQVy0IqKfd5hKxcujG46n4w/R
	QkH2A2HSt08FdaQD1dtw8ZP2nzFFLi1TE1QkmAHIpNM2dFry5xXotcllfqWRjjMWjiLA
	ITTVB/4ehJEBxUpQQ0CkNF9bvPtJFxfrtaXn0v9XYinSDg+0mAc+1lDxWX1auHSY++4D
	C0ASxGWoLM7J6Hp/d3IITNZGKXL78enbaGzNwMylI5KjUOn8CM+MqbWMm7cHKmcdXHd3
	dQmMrO8lKpNS68e79jUJURznnrBdkNciiQPBc1KiVLe93bULFq9aZYfHqUqSrWl5zUoG
	XTcg==
MIME-Version: 1.0
Received: by 10.60.170.229 with SMTP id ap5mr8193776oec.101.1348935741806;
	Sat, 29 Sep 2012 09:22:21 -0700 (PDT)
Received: by 10.76.19.148 with HTTP; Sat, 29 Sep 2012 09:22:21 -0700 (PDT)
In-Reply-To: <50671D3D.1010304@gmail.com>
References: <5066F922.1090305@gmail.com>
	<50671D3D.1010304@gmail.com>
Date: Sat, 29 Sep 2012 12:22:21 -0400
Message-ID: <CAA7N5Rawke3g9hirWZBgoZ7JZFV9h_y44yYADuVigi3QZe9cdw@mail.gmail.com>
From: Casey DeLorme <cdelorme@gmail.com>
To: "Teo En Ming (Zhang Enming)" <singapore.mr.teo.en.ming@gmail.com>
Cc: "xen-users@lists.xen.org" <xen-users@lists.xen.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [Xen-users] Unable to start Windows 8 HVM guest
 with Xen VGA Passthrough with Xen 4.2.1-pre
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============4275605394819524407=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============4275605394819524407==
Content-Type: multipart/alternative; boundary=bcaec54b4ac0b7182a04cad993db

--bcaec54b4ac0b7182a04cad993db
Content-Type: text/plain; charset=ISO-8859-1

Hello Teo,

That output is identical to the errors I had a few days ago, which was
related to available RAM.

Ian helped me debug it, said xl was having a ballooning problem and
couldn't free up enough RAM in time to start my HVM.

His suggested solution was to assign a fixed amount of RAM to Dom0 and turn
off ballooning.

Prior to this I had been letting Dom0 take all the RAM, but this problem
was fixed by adding dom0_mem to grub.cfg and setting a fixed value.

Have you tried re-running the xl create command after the first error?
There are commands to move RAM around at run-time as well that you could
try.

~Casey

On Sat, Sep 29, 2012 at 12:09 PM, Teo En Ming (Zhang Enming) <
singapore.mr.teo.en.ming@gmail.com> wrote:

> On 29/09/2012 21:35, Teo En Ming (Zhang Enming) wrote:
>
>> Hi,
>>
>> I have applied Xen VGA passthrough patches from David Techer's
>> personal website to Xen 4.2.1-pre source tree. Everything compiled and
>> installed smoothly. But when I tried to start Windows 8 HVM domU with
>> VGA passthrough, it gave me the following error:
>>
>> xc: error: unable to allocate memory to the HVM guest. (16: device or
>> resource busy): Internal error.
>>
>> There are no issues with Xen 4.2-unstable changeset 25099 however.
>>
>>
> Attached are screenshots of the errors for Xen 4.2.1-pre and Xen
> configuration files.
>
> The following are links to screenshots of the errors for Xen 4.2.1-pre.
>
> http://i45.tinypic.com/**2j3s7pj.jpg <http://i45.tinypic.com/2j3s7pj.jpg>
>
> http://i45.tinypic.com/95myc3.**jpg <http://i45.tinypic.com/95myc3.jpg>
>
>
> --
> Yours sincerely,
>
> Mr. Teo En Ming (Zhang Enming)
> Singapore
>
>
>
> _______________________________________________
> Xen-users mailing list
> Xen-users@lists.xen.org
> http://lists.xen.org/xen-users
>

--bcaec54b4ac0b7182a04cad993db
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div><div>Hello Teo,</div><div><br></div><div>That output is identical to t=
he errors I had a few days ago, which was related to available RAM.</div><d=
iv><br></div><div>Ian helped me debug it, said xl was having a ballooning p=
roblem and couldn&#39;t free up enough RAM in time to start my HVM.</div>
<div><br></div><div>His suggested solution was to assign a fixed amount of =
RAM to Dom0 and turn off ballooning.</div><div><br></div><div>Prior to this=
 I had been letting Dom0 take all the RAM, but this problem was fixed by ad=
ding dom0_mem to grub.cfg and setting a fixed value.</div>
<div><br></div><div>Have you tried re-running the xl create command after t=
he first error? There are commands to move RAM around at run-time as well t=
hat you could try.</div><div><br></div><div>~Casey</div></div><div><br>
<div class=3D"gmail_quote">On Sat, Sep 29, 2012 at 12:09 PM, Teo En Ming (Z=
hang Enming) <span dir=3D"ltr">&lt;<a href=3D"mailto:singapore.mr.teo.en.mi=
ng@gmail.com" target=3D"_blank">singapore.mr.teo.en.ming@gmail.com</a>&gt;<=
/span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div class=3D"im">On 29/09/2012 21:35, Teo E=
n Ming (Zhang Enming) 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 applied Xen VGA passthrough patches from David Techer&#39;s<br>
personal website to Xen 4.2.1-pre source tree. Everything compiled and<br>
installed smoothly. But when I tried to start Windows 8 HVM domU with<br>
VGA passthrough, it gave me the following error:<br>
<br>
xc: error: unable to allocate memory to the HVM guest. (16: device or<br>
resource busy): Internal error.<br>
<br>
There are no issues with Xen 4.2-unstable changeset 25099 however.<br>
<br>
</blockquote>
<br></div>
Attached are screenshots of the errors for Xen 4.2.1-pre and Xen configurat=
ion files.<br>
<br>
The following are links to screenshots of the errors for Xen 4.2.1-pre.<br>
<br>
<a href=3D"http://i45.tinypic.com/2j3s7pj.jpg" target=3D"_blank">http://i45=
.tinypic.com/<u></u>2j3s7pj.jpg</a><br>
<br>
<a href=3D"http://i45.tinypic.com/95myc3.jpg" target=3D"_blank">http://i45.=
tinypic.com/95myc3.<u></u>jpg</a><div class=3D"HOEnZb"><div class=3D"h5"><b=
r>
<br>
-- <br>
Yours sincerely,<br>
<br>
Mr. Teo En Ming (Zhang Enming)<br>
Singapore<br>
<br>
<br>
</div></div><br>_______________________________________________<br>
Xen-users mailing list<br>
<a href=3D"mailto:Xen-users@lists.xen.org">Xen-users@lists.xen.org</a><br>
<a href=3D"http://lists.xen.org/xen-users" target=3D"_blank">http://lists.x=
en.org/xen-users</a><br></blockquote></div><br></div>

--bcaec54b4ac0b7182a04cad993db--


--===============4275605394819524407==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============4275605394819524407==--


From xen-devel-bounces@lists.xen.org Sat Sep 29 16:22:54 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 29 Sep 2012 16:22:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1THzoF-00034D-5b; Sat, 29 Sep 2012 16:22:31 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <cdelorme@gmail.com>)
	id 1THzoE-000342-5K; Sat, 29 Sep 2012 16:22:30 +0000
X-Env-Sender: cdelorme@gmail.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1348935742!5866305!1
X-Originating-IP: [209.85.214.173]
X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20374 invoked from network); 29 Sep 2012 16:22:23 -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;
	29 Sep 2012 16:22:23 -0000
Received: by obbwc18 with SMTP id wc18so2390814obb.32
	for <multiple recipients>; Sat, 29 Sep 2012 09:22:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=cuthgEU24jdUcadhi8XBWi8lXF439BTxjfsq7aabTtg=;
	b=b6u+ed3N81uS408n88iXUYQAKQSiaqE4p9jAt6LaTnQVy0IqKfd5hKxcujG46n4w/R
	QkH2A2HSt08FdaQD1dtw8ZP2nzFFLi1TE1QkmAHIpNM2dFry5xXotcllfqWRjjMWjiLA
	ITTVB/4ehJEBxUpQQ0CkNF9bvPtJFxfrtaXn0v9XYinSDg+0mAc+1lDxWX1auHSY++4D
	C0ASxGWoLM7J6Hp/d3IITNZGKXL78enbaGzNwMylI5KjUOn8CM+MqbWMm7cHKmcdXHd3
	dQmMrO8lKpNS68e79jUJURznnrBdkNciiQPBc1KiVLe93bULFq9aZYfHqUqSrWl5zUoG
	XTcg==
MIME-Version: 1.0
Received: by 10.60.170.229 with SMTP id ap5mr8193776oec.101.1348935741806;
	Sat, 29 Sep 2012 09:22:21 -0700 (PDT)
Received: by 10.76.19.148 with HTTP; Sat, 29 Sep 2012 09:22:21 -0700 (PDT)
In-Reply-To: <50671D3D.1010304@gmail.com>
References: <5066F922.1090305@gmail.com>
	<50671D3D.1010304@gmail.com>
Date: Sat, 29 Sep 2012 12:22:21 -0400
Message-ID: <CAA7N5Rawke3g9hirWZBgoZ7JZFV9h_y44yYADuVigi3QZe9cdw@mail.gmail.com>
From: Casey DeLorme <cdelorme@gmail.com>
To: "Teo En Ming (Zhang Enming)" <singapore.mr.teo.en.ming@gmail.com>
Cc: "xen-users@lists.xen.org" <xen-users@lists.xen.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [Xen-users] Unable to start Windows 8 HVM guest
 with Xen VGA Passthrough with Xen 4.2.1-pre
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============4275605394819524407=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============4275605394819524407==
Content-Type: multipart/alternative; boundary=bcaec54b4ac0b7182a04cad993db

--bcaec54b4ac0b7182a04cad993db
Content-Type: text/plain; charset=ISO-8859-1

Hello Teo,

That output is identical to the errors I had a few days ago, which was
related to available RAM.

Ian helped me debug it, said xl was having a ballooning problem and
couldn't free up enough RAM in time to start my HVM.

His suggested solution was to assign a fixed amount of RAM to Dom0 and turn
off ballooning.

Prior to this I had been letting Dom0 take all the RAM, but this problem
was fixed by adding dom0_mem to grub.cfg and setting a fixed value.

Have you tried re-running the xl create command after the first error?
There are commands to move RAM around at run-time as well that you could
try.

~Casey

On Sat, Sep 29, 2012 at 12:09 PM, Teo En Ming (Zhang Enming) <
singapore.mr.teo.en.ming@gmail.com> wrote:

> On 29/09/2012 21:35, Teo En Ming (Zhang Enming) wrote:
>
>> Hi,
>>
>> I have applied Xen VGA passthrough patches from David Techer's
>> personal website to Xen 4.2.1-pre source tree. Everything compiled and
>> installed smoothly. But when I tried to start Windows 8 HVM domU with
>> VGA passthrough, it gave me the following error:
>>
>> xc: error: unable to allocate memory to the HVM guest. (16: device or
>> resource busy): Internal error.
>>
>> There are no issues with Xen 4.2-unstable changeset 25099 however.
>>
>>
> Attached are screenshots of the errors for Xen 4.2.1-pre and Xen
> configuration files.
>
> The following are links to screenshots of the errors for Xen 4.2.1-pre.
>
> http://i45.tinypic.com/**2j3s7pj.jpg <http://i45.tinypic.com/2j3s7pj.jpg>
>
> http://i45.tinypic.com/95myc3.**jpg <http://i45.tinypic.com/95myc3.jpg>
>
>
> --
> Yours sincerely,
>
> Mr. Teo En Ming (Zhang Enming)
> Singapore
>
>
>
> _______________________________________________
> Xen-users mailing list
> Xen-users@lists.xen.org
> http://lists.xen.org/xen-users
>

--bcaec54b4ac0b7182a04cad993db
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div><div>Hello Teo,</div><div><br></div><div>That output is identical to t=
he errors I had a few days ago, which was related to available RAM.</div><d=
iv><br></div><div>Ian helped me debug it, said xl was having a ballooning p=
roblem and couldn&#39;t free up enough RAM in time to start my HVM.</div>
<div><br></div><div>His suggested solution was to assign a fixed amount of =
RAM to Dom0 and turn off ballooning.</div><div><br></div><div>Prior to this=
 I had been letting Dom0 take all the RAM, but this problem was fixed by ad=
ding dom0_mem to grub.cfg and setting a fixed value.</div>
<div><br></div><div>Have you tried re-running the xl create command after t=
he first error? There are commands to move RAM around at run-time as well t=
hat you could try.</div><div><br></div><div>~Casey</div></div><div><br>
<div class=3D"gmail_quote">On Sat, Sep 29, 2012 at 12:09 PM, Teo En Ming (Z=
hang Enming) <span dir=3D"ltr">&lt;<a href=3D"mailto:singapore.mr.teo.en.mi=
ng@gmail.com" target=3D"_blank">singapore.mr.teo.en.ming@gmail.com</a>&gt;<=
/span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div class=3D"im">On 29/09/2012 21:35, Teo E=
n Ming (Zhang Enming) 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 applied Xen VGA passthrough patches from David Techer&#39;s<br>
personal website to Xen 4.2.1-pre source tree. Everything compiled and<br>
installed smoothly. But when I tried to start Windows 8 HVM domU with<br>
VGA passthrough, it gave me the following error:<br>
<br>
xc: error: unable to allocate memory to the HVM guest. (16: device or<br>
resource busy): Internal error.<br>
<br>
There are no issues with Xen 4.2-unstable changeset 25099 however.<br>
<br>
</blockquote>
<br></div>
Attached are screenshots of the errors for Xen 4.2.1-pre and Xen configurat=
ion files.<br>
<br>
The following are links to screenshots of the errors for Xen 4.2.1-pre.<br>
<br>
<a href=3D"http://i45.tinypic.com/2j3s7pj.jpg" target=3D"_blank">http://i45=
.tinypic.com/<u></u>2j3s7pj.jpg</a><br>
<br>
<a href=3D"http://i45.tinypic.com/95myc3.jpg" target=3D"_blank">http://i45.=
tinypic.com/95myc3.<u></u>jpg</a><div class=3D"HOEnZb"><div class=3D"h5"><b=
r>
<br>
-- <br>
Yours sincerely,<br>
<br>
Mr. Teo En Ming (Zhang Enming)<br>
Singapore<br>
<br>
<br>
</div></div><br>_______________________________________________<br>
Xen-users mailing list<br>
<a href=3D"mailto:Xen-users@lists.xen.org">Xen-users@lists.xen.org</a><br>
<a href=3D"http://lists.xen.org/xen-users" target=3D"_blank">http://lists.x=
en.org/xen-users</a><br></blockquote></div><br></div>

--bcaec54b4ac0b7182a04cad993db--


--===============4275605394819524407==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============4275605394819524407==--


From xen-devel-bounces@lists.xen.org Sat Sep 29 16:49:54 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 29 Sep 2012 16: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 1TI0EL-0003e2-2r; Sat, 29 Sep 2012 16:49:29 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <singapore.mr.teo.en.ming@gmail.com>)
	id 1TI0EK-0003dt-4K
	for xen-devel@lists.xen.org; Sat, 29 Sep 2012 16:49:28 +0000
Received: from [85.158.143.99:55155] by server-3.bemta-4.messagelabs.com id
	5E/AC-10986-79627605; Sat, 29 Sep 2012 16:49:27 +0000
X-Env-Sender: singapore.mr.teo.en.ming@gmail.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1348937364!24726773!1
X-Originating-IP: [209.85.210.45]
X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_50_60,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32060 invoked from network); 29 Sep 2012 16:49:26 -0000
Received: from mail-da0-f45.google.com (HELO mail-da0-f45.google.com)
	(209.85.210.45)
	by server-11.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Sep 2012 16:49:26 -0000
Received: by dadn15 with SMTP id n15so1003766dad.32
	for <multiple recipients>; Sat, 29 Sep 2012 09:49:23 -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;
	bh=Jd8L5JGVJjdhIVTOYcyZYwrbqKwpvpe+GLYdH9SIfs8=;
	b=QToabueoqyq0y3r10Y+OOrasOAN0mEv8jWb5ucGz2f7AzMbKdTqBbjkhILZ4wSNE07
	uQPp966QRYU0I4nRWLCL/Sbuqzaye0o7Au1qQRqGIIoqGwkQpLLR+nxgNqzduW1bdbWL
	Qh9UxDXawJQBxTohgwWggNhADBZngSlu8n/b+A190bBrG0rckeKrc0LbkfL6VPNYr/aH
	M7obehNmWu3ZTN7ds3pievnCtowevhcgs7RvY98z05OqrTxgfubvWngMUviibHbtibFr
	2P/c0LQ33EAx1gYUCHaiCXcpD9s3d0WCa//LxILBgoK9gK3u2ggNRep+A4czAtrtTMfK
	Jybg==
Received: by 10.68.237.232 with SMTP id vf8mr28822881pbc.65.1348937363750;
	Sat, 29 Sep 2012 09:49:23 -0700 (PDT)
Received: from [192.168.1.2] (cm152.gamma205.maxonline.com.sg.
	[202.156.205.152])
	by mx.google.com with ESMTPS id j9sm7404814pav.15.2012.09.29.09.49.21
	(version=SSLv3 cipher=OTHER); Sat, 29 Sep 2012 09:49:23 -0700 (PDT)
Message-ID: <50672690.9070504@gmail.com>
Date: Sun, 30 Sep 2012 00:49:20 +0800
From: "Teo En Ming (Zhang Enming)" <singapore.mr.teo.en.ming@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120912 Thunderbird/15.0.1
MIME-Version: 1.0
To: Casey DeLorme <cdelorme@gmail.com>
References: <5066F922.1090305@gmail.com> <50671D3D.1010304@gmail.com>
	<CAA7N5Rawke3g9hirWZBgoZ7JZFV9h_y44yYADuVigi3QZe9cdw@mail.gmail.com>
In-Reply-To: <CAA7N5Rawke3g9hirWZBgoZ7JZFV9h_y44yYADuVigi3QZe9cdw@mail.gmail.com>
Cc: "xen-users@lists.xen.org" <xen-users@lists.xen.org>,
	"Teo En Ming \(Zhang Enming\)" <singapore.mr.teo.en.ming@gmail.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [Xen-users] Unable to start Windows 8 HVM guest
 with Xen VGA Passthrough with Xen 4.2.1-pre
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============2508089987017332698=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a multi-part message in MIME format.
--===============2508089987017332698==
Content-Type: multipart/alternative;
 boundary="------------070007050000080102040302"

This is a multi-part message in MIME format.
--------------070007050000080102040302
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Dear Casey,

I had dom0_mem set to 1024 and 4096 as well, but it did not help. I am 
still getting the errors.

I have 6 GB of memory installed. How much memory should I assign to 
dom0_mem?

Thank you for your prompt reply.

-- 
Yours sincerely,

Mr. Teo En Ming (Zhang Enming)
Singapore


On 30/09/2012 00:22, Casey DeLorme wrote:
> Hello Teo,
>
> That output is identical to the errors I had a few days ago, which was 
> related to available RAM.
>
> Ian helped me debug it, said xl was having a ballooning problem and 
> couldn't free up enough RAM in time to start my HVM.
>
> His suggested solution was to assign a fixed amount of RAM to Dom0 and 
> turn off ballooning.
>
> Prior to this I had been letting Dom0 take all the RAM, but this 
> problem was fixed by adding dom0_mem to grub.cfg and setting a fixed 
> value.
>
> Have you tried re-running the xl create command after the first error? 
> There are commands to move RAM around at run-time as well that you 
> could try.
>
> ~Casey
>
> On Sat, Sep 29, 2012 at 12:09 PM, Teo En Ming (Zhang Enming) 
> <singapore.mr.teo.en.ming@gmail.com 
> <mailto:singapore.mr.teo.en.ming@gmail.com>> wrote:
>
>     On 29/09/2012 21:35, Teo En Ming (Zhang Enming) wrote:
>
>         Hi,
>
>         I have applied Xen VGA passthrough patches from David Techer's
>         personal website to Xen 4.2.1-pre source tree. Everything
>         compiled and
>         installed smoothly. But when I tried to start Windows 8 HVM
>         domU with
>         VGA passthrough, it gave me the following error:
>
>         xc: error: unable to allocate memory to the HVM guest. (16:
>         device or
>         resource busy): Internal error.
>
>         There are no issues with Xen 4.2-unstable changeset 25099 however.
>
>
>     Attached are screenshots of the errors for Xen 4.2.1-pre and Xen
>     configuration files.
>
>     The following are links to screenshots of the errors for Xen
>     4.2.1-pre.
>
>     http://i45.tinypic.com/2j3s7pj.jpg
>
>     http://i45.tinypic.com/95myc3.jpg
>
>
>     -- 
>     Yours sincerely,
>
>     Mr. Teo En Ming (Zhang Enming)
>     Singapore
>
>
>
>     _______________________________________________
>     Xen-users mailing list
>     Xen-users@lists.xen.org <mailto:Xen-users@lists.xen.org>
>     http://lists.xen.org/xen-users
>
>



--------------070007050000080102040302
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">Dear Casey,<br>
      <br>
      I had dom0_mem set to 1024 and 4096 as well, but it did not help.
      I am still getting the errors.<br>
      <br>
      I have 6 GB of memory installed. How much memory should I assign
      to dom0_mem?<br>
      <br>
      Thank you for your prompt reply.<br>
      <br>
      <pre class="moz-signature" cols="72">-- 
Yours sincerely,

Mr. Teo En Ming (Zhang Enming)
Singapore</pre>
      <br>
      On 30/09/2012 00:22, Casey DeLorme wrote:<br>
    </div>
    <blockquote
cite="mid:CAA7N5Rawke3g9hirWZBgoZ7JZFV9h_y44yYADuVigi3QZe9cdw@mail.gmail.com"
      type="cite">
      <div>
        <div>Hello Teo,</div>
        <div><br>
        </div>
        <div>That output is identical to the errors I had a few days
          ago, which was related to available RAM.</div>
        <div><br>
        </div>
        <div>Ian helped me debug it, said xl was having a ballooning
          problem and couldn't free up enough RAM in time to start my
          HVM.</div>
        <div><br>
        </div>
        <div>His suggested solution was to assign a fixed amount of RAM
          to Dom0 and turn off ballooning.</div>
        <div><br>
        </div>
        <div>Prior to this I had been letting Dom0 take all the RAM, but
          this problem was fixed by adding dom0_mem to grub.cfg and
          setting a fixed value.</div>
        <div><br>
        </div>
        <div>Have you tried re-running the xl create command after the
          first error? There are commands to move RAM around at run-time
          as well that you could try.</div>
        <div><br>
        </div>
        <div>~Casey</div>
      </div>
      <div><br>
        <div class="gmail_quote">On Sat, Sep 29, 2012 at 12:09 PM, Teo
          En Ming (Zhang Enming) <span dir="ltr">&lt;<a
              moz-do-not-send="true"
              href="mailto:singapore.mr.teo.en.ming@gmail.com"
              target="_blank">singapore.mr.teo.en.ming@gmail.com</a>&gt;</span>
          wrote:<br>
          <blockquote class="gmail_quote" style="margin:0 0 0
            .8ex;border-left:1px #ccc solid;padding-left:1ex">
            <div class="im">On 29/09/2012 21:35, Teo En Ming (Zhang
              Enming) wrote:<br>
              <blockquote class="gmail_quote" style="margin:0 0 0
                .8ex;border-left:1px #ccc solid;padding-left:1ex">
                Hi,<br>
                <br>
                I have applied Xen VGA passthrough patches from David
                Techer's<br>
                personal website to Xen 4.2.1-pre source tree.
                Everything compiled and<br>
                installed smoothly. But when I tried to start Windows 8
                HVM domU with<br>
                VGA passthrough, it gave me the following error:<br>
                <br>
                xc: error: unable to allocate memory to the HVM guest.
                (16: device or<br>
                resource busy): Internal error.<br>
                <br>
                There are no issues with Xen 4.2-unstable changeset
                25099 however.<br>
                <br>
              </blockquote>
              <br>
            </div>
            Attached are screenshots of the errors for Xen 4.2.1-pre and
            Xen configuration files.<br>
            <br>
            The following are links to screenshots of the errors for Xen
            4.2.1-pre.<br>
            <br>
            <a moz-do-not-send="true"
              href="http://i45.tinypic.com/2j3s7pj.jpg" target="_blank">http://i45.tinypic.com/2j3s7pj.jpg</a><br>
            <br>
            <a moz-do-not-send="true"
              href="http://i45.tinypic.com/95myc3.jpg" target="_blank">http://i45.tinypic.com/95myc3.jpg</a>
            <div class="HOEnZb">
              <div class="h5"><br>
                <br>
                -- <br>
                Yours sincerely,<br>
                <br>
                Mr. Teo En Ming (Zhang Enming)<br>
                Singapore<br>
                <br>
                <br>
              </div>
            </div>
            <br>
            _______________________________________________<br>
            Xen-users mailing list<br>
            <a moz-do-not-send="true"
              href="mailto:Xen-users@lists.xen.org">Xen-users@lists.xen.org</a><br>
            <a moz-do-not-send="true"
              href="http://lists.xen.org/xen-users" target="_blank">http://lists.xen.org/xen-users</a><br>
          </blockquote>
        </div>
        <br>
      </div>
    </blockquote>
    <br>
    <br>
    <pre class="moz-signature" cols="72">
</pre>
  </body>
</html>

--------------070007050000080102040302--


--===============2508089987017332698==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============2508089987017332698==--


From xen-devel-bounces@lists.xen.org Sat Sep 29 16:49:54 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 29 Sep 2012 16: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 1TI0EL-0003e2-2r; Sat, 29 Sep 2012 16:49:29 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <singapore.mr.teo.en.ming@gmail.com>)
	id 1TI0EK-0003dt-4K
	for xen-devel@lists.xen.org; Sat, 29 Sep 2012 16:49:28 +0000
Received: from [85.158.143.99:55155] by server-3.bemta-4.messagelabs.com id
	5E/AC-10986-79627605; Sat, 29 Sep 2012 16:49:27 +0000
X-Env-Sender: singapore.mr.teo.en.ming@gmail.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1348937364!24726773!1
X-Originating-IP: [209.85.210.45]
X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_50_60,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32060 invoked from network); 29 Sep 2012 16:49:26 -0000
Received: from mail-da0-f45.google.com (HELO mail-da0-f45.google.com)
	(209.85.210.45)
	by server-11.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Sep 2012 16:49:26 -0000
Received: by dadn15 with SMTP id n15so1003766dad.32
	for <multiple recipients>; Sat, 29 Sep 2012 09:49:23 -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;
	bh=Jd8L5JGVJjdhIVTOYcyZYwrbqKwpvpe+GLYdH9SIfs8=;
	b=QToabueoqyq0y3r10Y+OOrasOAN0mEv8jWb5ucGz2f7AzMbKdTqBbjkhILZ4wSNE07
	uQPp966QRYU0I4nRWLCL/Sbuqzaye0o7Au1qQRqGIIoqGwkQpLLR+nxgNqzduW1bdbWL
	Qh9UxDXawJQBxTohgwWggNhADBZngSlu8n/b+A190bBrG0rckeKrc0LbkfL6VPNYr/aH
	M7obehNmWu3ZTN7ds3pievnCtowevhcgs7RvY98z05OqrTxgfubvWngMUviibHbtibFr
	2P/c0LQ33EAx1gYUCHaiCXcpD9s3d0WCa//LxILBgoK9gK3u2ggNRep+A4czAtrtTMfK
	Jybg==
Received: by 10.68.237.232 with SMTP id vf8mr28822881pbc.65.1348937363750;
	Sat, 29 Sep 2012 09:49:23 -0700 (PDT)
Received: from [192.168.1.2] (cm152.gamma205.maxonline.com.sg.
	[202.156.205.152])
	by mx.google.com with ESMTPS id j9sm7404814pav.15.2012.09.29.09.49.21
	(version=SSLv3 cipher=OTHER); Sat, 29 Sep 2012 09:49:23 -0700 (PDT)
Message-ID: <50672690.9070504@gmail.com>
Date: Sun, 30 Sep 2012 00:49:20 +0800
From: "Teo En Ming (Zhang Enming)" <singapore.mr.teo.en.ming@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:15.0) Gecko/20120912 Thunderbird/15.0.1
MIME-Version: 1.0
To: Casey DeLorme <cdelorme@gmail.com>
References: <5066F922.1090305@gmail.com> <50671D3D.1010304@gmail.com>
	<CAA7N5Rawke3g9hirWZBgoZ7JZFV9h_y44yYADuVigi3QZe9cdw@mail.gmail.com>
In-Reply-To: <CAA7N5Rawke3g9hirWZBgoZ7JZFV9h_y44yYADuVigi3QZe9cdw@mail.gmail.com>
Cc: "xen-users@lists.xen.org" <xen-users@lists.xen.org>,
	"Teo En Ming \(Zhang Enming\)" <singapore.mr.teo.en.ming@gmail.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [Xen-users] Unable to start Windows 8 HVM guest
 with Xen VGA Passthrough with Xen 4.2.1-pre
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============2508089987017332698=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

This is a multi-part message in MIME format.
--===============2508089987017332698==
Content-Type: multipart/alternative;
 boundary="------------070007050000080102040302"

This is a multi-part message in MIME format.
--------------070007050000080102040302
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Dear Casey,

I had dom0_mem set to 1024 and 4096 as well, but it did not help. I am 
still getting the errors.

I have 6 GB of memory installed. How much memory should I assign to 
dom0_mem?

Thank you for your prompt reply.

-- 
Yours sincerely,

Mr. Teo En Ming (Zhang Enming)
Singapore


On 30/09/2012 00:22, Casey DeLorme wrote:
> Hello Teo,
>
> That output is identical to the errors I had a few days ago, which was 
> related to available RAM.
>
> Ian helped me debug it, said xl was having a ballooning problem and 
> couldn't free up enough RAM in time to start my HVM.
>
> His suggested solution was to assign a fixed amount of RAM to Dom0 and 
> turn off ballooning.
>
> Prior to this I had been letting Dom0 take all the RAM, but this 
> problem was fixed by adding dom0_mem to grub.cfg and setting a fixed 
> value.
>
> Have you tried re-running the xl create command after the first error? 
> There are commands to move RAM around at run-time as well that you 
> could try.
>
> ~Casey
>
> On Sat, Sep 29, 2012 at 12:09 PM, Teo En Ming (Zhang Enming) 
> <singapore.mr.teo.en.ming@gmail.com 
> <mailto:singapore.mr.teo.en.ming@gmail.com>> wrote:
>
>     On 29/09/2012 21:35, Teo En Ming (Zhang Enming) wrote:
>
>         Hi,
>
>         I have applied Xen VGA passthrough patches from David Techer's
>         personal website to Xen 4.2.1-pre source tree. Everything
>         compiled and
>         installed smoothly. But when I tried to start Windows 8 HVM
>         domU with
>         VGA passthrough, it gave me the following error:
>
>         xc: error: unable to allocate memory to the HVM guest. (16:
>         device or
>         resource busy): Internal error.
>
>         There are no issues with Xen 4.2-unstable changeset 25099 however.
>
>
>     Attached are screenshots of the errors for Xen 4.2.1-pre and Xen
>     configuration files.
>
>     The following are links to screenshots of the errors for Xen
>     4.2.1-pre.
>
>     http://i45.tinypic.com/2j3s7pj.jpg
>
>     http://i45.tinypic.com/95myc3.jpg
>
>
>     -- 
>     Yours sincerely,
>
>     Mr. Teo En Ming (Zhang Enming)
>     Singapore
>
>
>
>     _______________________________________________
>     Xen-users mailing list
>     Xen-users@lists.xen.org <mailto:Xen-users@lists.xen.org>
>     http://lists.xen.org/xen-users
>
>



--------------070007050000080102040302
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">Dear Casey,<br>
      <br>
      I had dom0_mem set to 1024 and 4096 as well, but it did not help.
      I am still getting the errors.<br>
      <br>
      I have 6 GB of memory installed. How much memory should I assign
      to dom0_mem?<br>
      <br>
      Thank you for your prompt reply.<br>
      <br>
      <pre class="moz-signature" cols="72">-- 
Yours sincerely,

Mr. Teo En Ming (Zhang Enming)
Singapore</pre>
      <br>
      On 30/09/2012 00:22, Casey DeLorme wrote:<br>
    </div>
    <blockquote
cite="mid:CAA7N5Rawke3g9hirWZBgoZ7JZFV9h_y44yYADuVigi3QZe9cdw@mail.gmail.com"
      type="cite">
      <div>
        <div>Hello Teo,</div>
        <div><br>
        </div>
        <div>That output is identical to the errors I had a few days
          ago, which was related to available RAM.</div>
        <div><br>
        </div>
        <div>Ian helped me debug it, said xl was having a ballooning
          problem and couldn't free up enough RAM in time to start my
          HVM.</div>
        <div><br>
        </div>
        <div>His suggested solution was to assign a fixed amount of RAM
          to Dom0 and turn off ballooning.</div>
        <div><br>
        </div>
        <div>Prior to this I had been letting Dom0 take all the RAM, but
          this problem was fixed by adding dom0_mem to grub.cfg and
          setting a fixed value.</div>
        <div><br>
        </div>
        <div>Have you tried re-running the xl create command after the
          first error? There are commands to move RAM around at run-time
          as well that you could try.</div>
        <div><br>
        </div>
        <div>~Casey</div>
      </div>
      <div><br>
        <div class="gmail_quote">On Sat, Sep 29, 2012 at 12:09 PM, Teo
          En Ming (Zhang Enming) <span dir="ltr">&lt;<a
              moz-do-not-send="true"
              href="mailto:singapore.mr.teo.en.ming@gmail.com"
              target="_blank">singapore.mr.teo.en.ming@gmail.com</a>&gt;</span>
          wrote:<br>
          <blockquote class="gmail_quote" style="margin:0 0 0
            .8ex;border-left:1px #ccc solid;padding-left:1ex">
            <div class="im">On 29/09/2012 21:35, Teo En Ming (Zhang
              Enming) wrote:<br>
              <blockquote class="gmail_quote" style="margin:0 0 0
                .8ex;border-left:1px #ccc solid;padding-left:1ex">
                Hi,<br>
                <br>
                I have applied Xen VGA passthrough patches from David
                Techer's<br>
                personal website to Xen 4.2.1-pre source tree.
                Everything compiled and<br>
                installed smoothly. But when I tried to start Windows 8
                HVM domU with<br>
                VGA passthrough, it gave me the following error:<br>
                <br>
                xc: error: unable to allocate memory to the HVM guest.
                (16: device or<br>
                resource busy): Internal error.<br>
                <br>
                There are no issues with Xen 4.2-unstable changeset
                25099 however.<br>
                <br>
              </blockquote>
              <br>
            </div>
            Attached are screenshots of the errors for Xen 4.2.1-pre and
            Xen configuration files.<br>
            <br>
            The following are links to screenshots of the errors for Xen
            4.2.1-pre.<br>
            <br>
            <a moz-do-not-send="true"
              href="http://i45.tinypic.com/2j3s7pj.jpg" target="_blank">http://i45.tinypic.com/2j3s7pj.jpg</a><br>
            <br>
            <a moz-do-not-send="true"
              href="http://i45.tinypic.com/95myc3.jpg" target="_blank">http://i45.tinypic.com/95myc3.jpg</a>
            <div class="HOEnZb">
              <div class="h5"><br>
                <br>
                -- <br>
                Yours sincerely,<br>
                <br>
                Mr. Teo En Ming (Zhang Enming)<br>
                Singapore<br>
                <br>
                <br>
              </div>
            </div>
            <br>
            _______________________________________________<br>
            Xen-users mailing list<br>
            <a moz-do-not-send="true"
              href="mailto:Xen-users@lists.xen.org">Xen-users@lists.xen.org</a><br>
            <a moz-do-not-send="true"
              href="http://lists.xen.org/xen-users" target="_blank">http://lists.xen.org/xen-users</a><br>
          </blockquote>
        </div>
        <br>
      </div>
    </blockquote>
    <br>
    <br>
    <pre class="moz-signature" cols="72">
</pre>
  </body>
</html>

--------------070007050000080102040302--


--===============2508089987017332698==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============2508089987017332698==--


From xen-devel-bounces@lists.xen.org Sat Sep 29 17:25:40 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 29 Sep 2012 17: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 1TI0mz-0004nc-Uc; Sat, 29 Sep 2012 17:25:17 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <cdelorme@gmail.com>) id 1TI0my-0004nS-FP
	for xen-devel@lists.xen.org; Sat, 29 Sep 2012 17:25:16 +0000
Received: from [85.158.139.211:62098] by server-3.bemta-5.messagelabs.com id
	60/3D-16108-BFE27605; Sat, 29 Sep 2012 17:25:15 +0000
X-Env-Sender: cdelorme@gmail.com
X-Msg-Ref: server-12.tower-206.messagelabs.com!1348939513!19434243!1
X-Originating-IP: [209.85.214.173]
X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_20_30,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31529 invoked from network); 29 Sep 2012 17:25:14 -0000
Received: from mail-ob0-f173.google.com (HELO mail-ob0-f173.google.com)
	(209.85.214.173)
	by server-12.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Sep 2012 17:25:14 -0000
Received: by obbwc18 with SMTP id wc18so2426769obb.32
	for <multiple recipients>; Sat, 29 Sep 2012 10:25:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=97FDdDUhzKRADBgV7n/16cU5654oQdWA1zbFOxmPFKI=;
	b=SPKRCCWrTzWtwcFSPF5+8snWVWZiJMuhZMIcoBBgE+epGk+Ti95z76Xpa8HUHCdAy6
	ijuaI4aBa9jm1EXI8OvmiqoxL0EysqLsIhoBJHhxstXy3tvqg6HaKywIuroxxpVHpxJ4
	4ddtiSbyIoLURNQMdpSCB+ZdXuBifjf5+2TVGXrm3TevVr5RaNMRkW5NPJFAlMa4/naw
	44qBxjK+J0Dee8InHdd/TjTqbY2UgnZN69P0QT/oLycarnutByBxZ1QgmiZSjoW1/UVT
	55pbyCKJu6AeDxRqn0zTL98xd2VtMamtpHb+wAyMcxacLKLZ5/lNZBEUWuVzNyISCkV2
	gmzQ==
MIME-Version: 1.0
Received: by 10.60.172.235 with SMTP id bf11mr8124760oec.30.1348939512753;
	Sat, 29 Sep 2012 10:25:12 -0700 (PDT)
Received: by 10.76.19.148 with HTTP; Sat, 29 Sep 2012 10:25:12 -0700 (PDT)
In-Reply-To: <50672690.9070504@gmail.com>
References: <5066F922.1090305@gmail.com> <50671D3D.1010304@gmail.com>
	<CAA7N5Rawke3g9hirWZBgoZ7JZFV9h_y44yYADuVigi3QZe9cdw@mail.gmail.com>
	<50672690.9070504@gmail.com>
Date: Sat, 29 Sep 2012 13:25:12 -0400
Message-ID: <CAA7N5RZ7wVj2CntaKR0W86=jkPBuO7zygGNR0Dc4KCapfVN=sA@mail.gmail.com>
From: Casey DeLorme <cdelorme@gmail.com>
To: "Teo En Ming (Zhang Enming)" <singapore.mr.teo.en.ming@gmail.com>
Cc: "xen-users@lists.xen.org" <xen-users@lists.xen.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [Xen-users] Unable to start Windows 8 HVM guest
 with Xen VGA Passthrough with Xen 4.2.1-pre
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============2676412278552510416=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============2676412278552510416==
Content-Type: multipart/alternative; boundary=bcaec54ee8387b2d6b04cada7487

--bcaec54ee8387b2d6b04cada7487
Content-Type: text/plain; charset=ISO-8859-1

I am working with 32GB, so you probably don't want to model your
configuration after mine.  My problem was memory was not being freed from
Dom0 fast enough.

If you have already lowered Dom0 memory, checked it with xl info, and are
still having problems launching, then it might be something else.

My assumption is the memory assigned in the configuration is not a 1:1 map
to what is required.

---

I decided to run some tests to see how Xen used my memory.

Starting with Dom0 and ipfire running, I ran xl info, got the diff, and
then xl list and compared the two to find that xl info shows 500MB more
memory used up.

I started Windows, and again roughly 500MB unaccounted for.

---

So, based on that information I can assume Xen requires half a gigabyte to
work with in the backend for its normal responsibilities.

The wiki has a best practices which shows 512MB set for Dom0:
http://wiki.xen.org/wiki/Xen_Best_Practices


I would try setting 512MB in your grub configuration like the above, check
available RAM after your reload using `xl info`, making sure you have more
than the 2GB set in the HVM configuration.

If it still doesn't work, then it must be something different.  You could
also try lowering the memory in your DomU configuration as an alternative,
just to see if it works.

--bcaec54ee8387b2d6b04cada7487
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div><div>I am working with 32GB, so you probably don&#39;t want to model y=
our configuration after mine. =A0My problem was memory was not being freed =
from Dom0 fast enough.</div></div><div><div><br></div><div>If you have alre=
ady lowered Dom0 memory, checked it with xl info, and are still having prob=
lems launching, then it might be something else.</div>
<div><br></div><div>My assumption is the memory assigned in the configurati=
on is not a 1:1 map to what is required.</div><div><br></div><div>---</div>=
<div><br></div><div>I decided to run some tests to see how Xen used my memo=
ry.</div>
<div><br></div><div>Starting with Dom0 and ipfire running, I ran xl info, g=
ot the diff, and then xl list and compared the two to find that xl info sho=
ws 500MB more memory used up.</div><div><br></div><div>I started Windows, a=
nd again roughly 500MB unaccounted for.</div>
<div><br></div><div>---</div><div><br></div><div>So, based on that informat=
ion I can assume Xen requires half a gigabyte to work with in the backend f=
or its normal responsibilities.</div><div><br></div><div>The wiki has a bes=
t practices which shows 512MB set for Dom0:</div>
<div><a href=3D"http://wiki.xen.org/wiki/Xen_Best_Practices">http://wiki.xe=
n.org/wiki/Xen_Best_Practices</a></div><div><br></div><div><br></div><div>I=
 would try setting 512MB in your grub configuration like the above, check a=
vailable RAM after your reload using `xl info`, making sure you have more t=
han the 2GB set in the HVM configuration.</div>
<div><br></div><div>If it still doesn&#39;t work, then it must be something=
 different. =A0You could also try lowering the memory in your DomU configur=
ation as an alternative, just to see if it works.</div></div>

--bcaec54ee8387b2d6b04cada7487--


--===============2676412278552510416==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============2676412278552510416==--


From xen-devel-bounces@lists.xen.org Sat Sep 29 17:25:40 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 29 Sep 2012 17: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 1TI0mz-0004nc-Uc; Sat, 29 Sep 2012 17:25:17 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <cdelorme@gmail.com>) id 1TI0my-0004nS-FP
	for xen-devel@lists.xen.org; Sat, 29 Sep 2012 17:25:16 +0000
Received: from [85.158.139.211:62098] by server-3.bemta-5.messagelabs.com id
	60/3D-16108-BFE27605; Sat, 29 Sep 2012 17:25:15 +0000
X-Env-Sender: cdelorme@gmail.com
X-Msg-Ref: server-12.tower-206.messagelabs.com!1348939513!19434243!1
X-Originating-IP: [209.85.214.173]
X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_20_30,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31529 invoked from network); 29 Sep 2012 17:25:14 -0000
Received: from mail-ob0-f173.google.com (HELO mail-ob0-f173.google.com)
	(209.85.214.173)
	by server-12.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Sep 2012 17:25:14 -0000
Received: by obbwc18 with SMTP id wc18so2426769obb.32
	for <multiple recipients>; Sat, 29 Sep 2012 10:25:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=97FDdDUhzKRADBgV7n/16cU5654oQdWA1zbFOxmPFKI=;
	b=SPKRCCWrTzWtwcFSPF5+8snWVWZiJMuhZMIcoBBgE+epGk+Ti95z76Xpa8HUHCdAy6
	ijuaI4aBa9jm1EXI8OvmiqoxL0EysqLsIhoBJHhxstXy3tvqg6HaKywIuroxxpVHpxJ4
	4ddtiSbyIoLURNQMdpSCB+ZdXuBifjf5+2TVGXrm3TevVr5RaNMRkW5NPJFAlMa4/naw
	44qBxjK+J0Dee8InHdd/TjTqbY2UgnZN69P0QT/oLycarnutByBxZ1QgmiZSjoW1/UVT
	55pbyCKJu6AeDxRqn0zTL98xd2VtMamtpHb+wAyMcxacLKLZ5/lNZBEUWuVzNyISCkV2
	gmzQ==
MIME-Version: 1.0
Received: by 10.60.172.235 with SMTP id bf11mr8124760oec.30.1348939512753;
	Sat, 29 Sep 2012 10:25:12 -0700 (PDT)
Received: by 10.76.19.148 with HTTP; Sat, 29 Sep 2012 10:25:12 -0700 (PDT)
In-Reply-To: <50672690.9070504@gmail.com>
References: <5066F922.1090305@gmail.com> <50671D3D.1010304@gmail.com>
	<CAA7N5Rawke3g9hirWZBgoZ7JZFV9h_y44yYADuVigi3QZe9cdw@mail.gmail.com>
	<50672690.9070504@gmail.com>
Date: Sat, 29 Sep 2012 13:25:12 -0400
Message-ID: <CAA7N5RZ7wVj2CntaKR0W86=jkPBuO7zygGNR0Dc4KCapfVN=sA@mail.gmail.com>
From: Casey DeLorme <cdelorme@gmail.com>
To: "Teo En Ming (Zhang Enming)" <singapore.mr.teo.en.ming@gmail.com>
Cc: "xen-users@lists.xen.org" <xen-users@lists.xen.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] [Xen-users] Unable to start Windows 8 HVM guest
 with Xen VGA Passthrough with Xen 4.2.1-pre
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============2676412278552510416=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============2676412278552510416==
Content-Type: multipart/alternative; boundary=bcaec54ee8387b2d6b04cada7487

--bcaec54ee8387b2d6b04cada7487
Content-Type: text/plain; charset=ISO-8859-1

I am working with 32GB, so you probably don't want to model your
configuration after mine.  My problem was memory was not being freed from
Dom0 fast enough.

If you have already lowered Dom0 memory, checked it with xl info, and are
still having problems launching, then it might be something else.

My assumption is the memory assigned in the configuration is not a 1:1 map
to what is required.

---

I decided to run some tests to see how Xen used my memory.

Starting with Dom0 and ipfire running, I ran xl info, got the diff, and
then xl list and compared the two to find that xl info shows 500MB more
memory used up.

I started Windows, and again roughly 500MB unaccounted for.

---

So, based on that information I can assume Xen requires half a gigabyte to
work with in the backend for its normal responsibilities.

The wiki has a best practices which shows 512MB set for Dom0:
http://wiki.xen.org/wiki/Xen_Best_Practices


I would try setting 512MB in your grub configuration like the above, check
available RAM after your reload using `xl info`, making sure you have more
than the 2GB set in the HVM configuration.

If it still doesn't work, then it must be something different.  You could
also try lowering the memory in your DomU configuration as an alternative,
just to see if it works.

--bcaec54ee8387b2d6b04cada7487
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div><div>I am working with 32GB, so you probably don&#39;t want to model y=
our configuration after mine. =A0My problem was memory was not being freed =
from Dom0 fast enough.</div></div><div><div><br></div><div>If you have alre=
ady lowered Dom0 memory, checked it with xl info, and are still having prob=
lems launching, then it might be something else.</div>
<div><br></div><div>My assumption is the memory assigned in the configurati=
on is not a 1:1 map to what is required.</div><div><br></div><div>---</div>=
<div><br></div><div>I decided to run some tests to see how Xen used my memo=
ry.</div>
<div><br></div><div>Starting with Dom0 and ipfire running, I ran xl info, g=
ot the diff, and then xl list and compared the two to find that xl info sho=
ws 500MB more memory used up.</div><div><br></div><div>I started Windows, a=
nd again roughly 500MB unaccounted for.</div>
<div><br></div><div>---</div><div><br></div><div>So, based on that informat=
ion I can assume Xen requires half a gigabyte to work with in the backend f=
or its normal responsibilities.</div><div><br></div><div>The wiki has a bes=
t practices which shows 512MB set for Dom0:</div>
<div><a href=3D"http://wiki.xen.org/wiki/Xen_Best_Practices">http://wiki.xe=
n.org/wiki/Xen_Best_Practices</a></div><div><br></div><div><br></div><div>I=
 would try setting 512MB in your grub configuration like the above, check a=
vailable RAM after your reload using `xl info`, making sure you have more t=
han the 2GB set in the HVM configuration.</div>
<div><br></div><div>If it still doesn&#39;t work, then it must be something=
 different. =A0You could also try lowering the memory in your DomU configur=
ation as an alternative, just to see if it works.</div></div>

--bcaec54ee8387b2d6b04cada7487--


--===============2676412278552510416==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============2676412278552510416==--


From xen-devel-bounces@lists.xen.org Sat Sep 29 18:50:06 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 29 Sep 2012 18:50:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TI26a-0005vx-Aq; Sat, 29 Sep 2012 18:49:36 +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 1TI26Y-0005vs-9U
	for xen-devel@lists.xen.org; Sat, 29 Sep 2012 18:49:34 +0000
Received: from [85.158.139.211:45592] by server-12.bemta-5.messagelabs.com id
	FB/FC-20729-DB247605; Sat, 29 Sep 2012 18:49:33 +0000
X-Env-Sender: msw@amazon.com
X-Msg-Ref: server-10.tower-206.messagelabs.com!1348944571!20416291!1
X-Originating-IP: [72.21.198.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNzIuMjEuMTk4LjI1ID0+IDE4Mjk1NA==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9747 invoked from network); 29 Sep 2012 18:49:32 -0000
Received: from smtp-fw-4101.amazon.com (HELO smtp-fw-4101.amazon.com)
	(72.21.198.25)
	by server-10.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Sep 2012 18:49:32 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=amazon.com; i=msw@amazon.com; q=dns/txt;
	s=amazon201209; t=1348944572; x=1380480572;
	h=date:from:to:cc:subject:message-id:references:
	mime-version:in-reply-to;
	bh=SY04lusH83s9L7bAMnzKb1wIlvfo+JimqBTKmwCNaJ0=;
	b=gk0/4+f1G6Ndi2tW2GQIHRqa9KCbSZWwn5rLtmacxePTTxoWLOhumMZX
	EeTYAGifN5J3FxU5OfPnLje6JfgnHEr1+WuuRUKRA5F1DWks+w+cR884/
	Q7ab428mEgMK/KsundfigznN0pgofSjo0B24H34Ai1O8lzmbqBkdLopYf Q=;
X-IronPort-AV: E=Sophos;i="4.80,509,1344211200"; d="scan'208";a="803555853"
Received: from smtp-in-9003.sea19.amazon.com ([10.186.104.20])
	by smtp-border-fw-out-4101.iad4.amazon.com with
	ESMTP/TLS/DHE-RSA-AES256-SHA; 29 Sep 2012 18:49:23 +0000
Received: from ex10-hub-9001.ant.amazon.com (ex10-hub-9001.ant.amazon.com
	[10.185.137.58])
	by smtp-in-9003.sea19.amazon.com (8.13.8/8.13.8) with ESMTP id
	q8TInMDa009102
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL);
	Sat, 29 Sep 2012 18:49:22 GMT
Received: from u002268147cd4502c336d.ant.amazon.com (10.224.80.42) by
	ex10-hub-9001.ant.amazon.com (10.185.137.58) with Microsoft SMTP Server
	id 14.2.247.3; Sat, 29 Sep 2012 11:49:18 -0700
Received: by u002268147cd4502c336d.ant.amazon.com (sSMTP sendmail emulation); 
	Sat, 29 Sep 2012 11:49:18 -0700
Date: Sat, 29 Sep 2012 11:49:18 -0700
From: Matt Wilson <msw@amazon.com>
To: Keir Fraser <keir.xen@gmail.com>
Message-ID: <20120929184916.GB21253@u002268147cd4502c336d.ant.amazon.com>
References: <20f6976e28a1ce7e910e.1348894953@kaos-source-31003.sea31.amazon.com>
	<CC8C4BED.40284%keir.xen@gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CC8C4BED.40284%keir.xen@gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: Jan Beulich <jbeulich@suse.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] xen/console: introduce a 'w' debug-key that
 dumps the console ring
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Sat, Sep 29, 2012 at 06:55:41AM +0100, Keir Fraser wrote:
> On 29/09/2012 06:02, "Matt Wilson" <msw@amazon.com> wrote:
> 
> > This patch adds a new 'w' debug-key, chosen from the limited remaining
> > keys only due to its proximity to 'q', that dumps the console ring to
> > configured console devices. It's useful to for tracking down how an
> > unresponsive system got into a broken state via serial console.
> 
> Why wouldn't everything on the ring already have been sent to the configured
> console devices?

It would have been. But what if no one was looking, or dom0 cleared
the console, or placed it into a scrolling mode that prevents a
virtual terminal from placing output into a scrollback buffer. With
this patch, you can connect to a serial console after a machine
becomes unresponsive and gather clues on what went wrong.

Matt

> > Signed-off-by: Matt Wilson <msw@amazon.com>
> > 
> > diff -r bd953fda6106 -r 20f6976e28a1 xen/drivers/char/console.c
> > --- a/xen/drivers/char/console.c Fri Sep 28 10:59:41 2012 +0200
> > +++ b/xen/drivers/char/console.c Sat Sep 29 05:00:05 2012 +0000
> > @@ -264,6 +264,49 @@ static void sercon_puts(const char *s)
> >          serial_puts(sercon_handle, s);
> >  }
> >  
> > +static void dump_console_ring_key(unsigned char key)
> > +{
> > +    uint32_t idx, len, sofar, c;
> > +    unsigned int order;
> > +    char *buf;
> > +
> > +    printk("'%c' pressed -> dumping console ring buffer (dmesg)\n", key);
> > +
> > +    /* create a buffer in which we'll copy the ring in the correct
> > +       order and NUL terminate */
> > +    order = get_order_from_bytes(conring_size + 1);
> > +    buf = alloc_xenheap_pages(order, 0);
> > +    if ( buf == NULL )
> > +    {
> > +        printk("unable to allocate memory!\n");
> > +        return;
> > +    }
> > +
> > +    c = conringc;
> > +    sofar = 0;
> > +    while ( (c != conringp) )
> > +    {
> > +        idx = CONRING_IDX_MASK(c);
> > +        len = conringp - c;
> > +        if ( (idx + len) > conring_size )
> > +            len = conring_size - idx;
> > +        memcpy(buf + sofar, &conring[idx], len);
> > +        sofar += len;
> > +        c += len;
> > +    }
> > +    buf[sofar] = '\0';
> > +
> > +    sercon_puts(buf);
> > +    vga_puts(buf);
> > +
> > +    free_xenheap_pages(buf, order);
> > +}
> > +
> > +static struct keyhandler dump_console_ring_keyhandler = {
> > +    .u.fn = dump_console_ring_key,
> > +    .desc = "synchronously dump console ring buffer (dmesg)"
> > +};
> > +
> >  /* CTRL-<switch_char> switches input direction between Xen and DOM0. */
> >  #define switch_code (opt_conswitch[0]-'a'+1)
> >  static int __read_mostly xen_rx = 1; /* FALSE => serial input passed to
> > domain 0. */
> > @@ -661,6 +704,8 @@ void __init console_endboot(void)
> >      if ( opt_conswitch[1] == 'x' )
> >          xen_rx = !xen_rx;
> >  
> > +    register_keyhandler('w', &dump_console_ring_keyhandler);
> > +
> >      /* Serial input is directed to DOM0 by default. */
> >      switch_serial_input();
> >  }
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sat Sep 29 18:50:06 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 29 Sep 2012 18:50:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TI26a-0005vx-Aq; Sat, 29 Sep 2012 18:49:36 +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 1TI26Y-0005vs-9U
	for xen-devel@lists.xen.org; Sat, 29 Sep 2012 18:49:34 +0000
Received: from [85.158.139.211:45592] by server-12.bemta-5.messagelabs.com id
	FB/FC-20729-DB247605; Sat, 29 Sep 2012 18:49:33 +0000
X-Env-Sender: msw@amazon.com
X-Msg-Ref: server-10.tower-206.messagelabs.com!1348944571!20416291!1
X-Originating-IP: [72.21.198.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNzIuMjEuMTk4LjI1ID0+IDE4Mjk1NA==\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9747 invoked from network); 29 Sep 2012 18:49:32 -0000
Received: from smtp-fw-4101.amazon.com (HELO smtp-fw-4101.amazon.com)
	(72.21.198.25)
	by server-10.tower-206.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Sep 2012 18:49:32 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=amazon.com; i=msw@amazon.com; q=dns/txt;
	s=amazon201209; t=1348944572; x=1380480572;
	h=date:from:to:cc:subject:message-id:references:
	mime-version:in-reply-to;
	bh=SY04lusH83s9L7bAMnzKb1wIlvfo+JimqBTKmwCNaJ0=;
	b=gk0/4+f1G6Ndi2tW2GQIHRqa9KCbSZWwn5rLtmacxePTTxoWLOhumMZX
	EeTYAGifN5J3FxU5OfPnLje6JfgnHEr1+WuuRUKRA5F1DWks+w+cR884/
	Q7ab428mEgMK/KsundfigznN0pgofSjo0B24H34Ai1O8lzmbqBkdLopYf Q=;
X-IronPort-AV: E=Sophos;i="4.80,509,1344211200"; d="scan'208";a="803555853"
Received: from smtp-in-9003.sea19.amazon.com ([10.186.104.20])
	by smtp-border-fw-out-4101.iad4.amazon.com with
	ESMTP/TLS/DHE-RSA-AES256-SHA; 29 Sep 2012 18:49:23 +0000
Received: from ex10-hub-9001.ant.amazon.com (ex10-hub-9001.ant.amazon.com
	[10.185.137.58])
	by smtp-in-9003.sea19.amazon.com (8.13.8/8.13.8) with ESMTP id
	q8TInMDa009102
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL);
	Sat, 29 Sep 2012 18:49:22 GMT
Received: from u002268147cd4502c336d.ant.amazon.com (10.224.80.42) by
	ex10-hub-9001.ant.amazon.com (10.185.137.58) with Microsoft SMTP Server
	id 14.2.247.3; Sat, 29 Sep 2012 11:49:18 -0700
Received: by u002268147cd4502c336d.ant.amazon.com (sSMTP sendmail emulation); 
	Sat, 29 Sep 2012 11:49:18 -0700
Date: Sat, 29 Sep 2012 11:49:18 -0700
From: Matt Wilson <msw@amazon.com>
To: Keir Fraser <keir.xen@gmail.com>
Message-ID: <20120929184916.GB21253@u002268147cd4502c336d.ant.amazon.com>
References: <20f6976e28a1ce7e910e.1348894953@kaos-source-31003.sea31.amazon.com>
	<CC8C4BED.40284%keir.xen@gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CC8C4BED.40284%keir.xen@gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: Jan Beulich <jbeulich@suse.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [PATCH] xen/console: introduce a 'w' debug-key that
 dumps the console ring
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Sat, Sep 29, 2012 at 06:55:41AM +0100, Keir Fraser wrote:
> On 29/09/2012 06:02, "Matt Wilson" <msw@amazon.com> wrote:
> 
> > This patch adds a new 'w' debug-key, chosen from the limited remaining
> > keys only due to its proximity to 'q', that dumps the console ring to
> > configured console devices. It's useful to for tracking down how an
> > unresponsive system got into a broken state via serial console.
> 
> Why wouldn't everything on the ring already have been sent to the configured
> console devices?

It would have been. But what if no one was looking, or dom0 cleared
the console, or placed it into a scrolling mode that prevents a
virtual terminal from placing output into a scrollback buffer. With
this patch, you can connect to a serial console after a machine
becomes unresponsive and gather clues on what went wrong.

Matt

> > Signed-off-by: Matt Wilson <msw@amazon.com>
> > 
> > diff -r bd953fda6106 -r 20f6976e28a1 xen/drivers/char/console.c
> > --- a/xen/drivers/char/console.c Fri Sep 28 10:59:41 2012 +0200
> > +++ b/xen/drivers/char/console.c Sat Sep 29 05:00:05 2012 +0000
> > @@ -264,6 +264,49 @@ static void sercon_puts(const char *s)
> >          serial_puts(sercon_handle, s);
> >  }
> >  
> > +static void dump_console_ring_key(unsigned char key)
> > +{
> > +    uint32_t idx, len, sofar, c;
> > +    unsigned int order;
> > +    char *buf;
> > +
> > +    printk("'%c' pressed -> dumping console ring buffer (dmesg)\n", key);
> > +
> > +    /* create a buffer in which we'll copy the ring in the correct
> > +       order and NUL terminate */
> > +    order = get_order_from_bytes(conring_size + 1);
> > +    buf = alloc_xenheap_pages(order, 0);
> > +    if ( buf == NULL )
> > +    {
> > +        printk("unable to allocate memory!\n");
> > +        return;
> > +    }
> > +
> > +    c = conringc;
> > +    sofar = 0;
> > +    while ( (c != conringp) )
> > +    {
> > +        idx = CONRING_IDX_MASK(c);
> > +        len = conringp - c;
> > +        if ( (idx + len) > conring_size )
> > +            len = conring_size - idx;
> > +        memcpy(buf + sofar, &conring[idx], len);
> > +        sofar += len;
> > +        c += len;
> > +    }
> > +    buf[sofar] = '\0';
> > +
> > +    sercon_puts(buf);
> > +    vga_puts(buf);
> > +
> > +    free_xenheap_pages(buf, order);
> > +}
> > +
> > +static struct keyhandler dump_console_ring_keyhandler = {
> > +    .u.fn = dump_console_ring_key,
> > +    .desc = "synchronously dump console ring buffer (dmesg)"
> > +};
> > +
> >  /* CTRL-<switch_char> switches input direction between Xen and DOM0. */
> >  #define switch_code (opt_conswitch[0]-'a'+1)
> >  static int __read_mostly xen_rx = 1; /* FALSE => serial input passed to
> > domain 0. */
> > @@ -661,6 +704,8 @@ void __init console_endboot(void)
> >      if ( opt_conswitch[1] == 'x' )
> >          xen_rx = !xen_rx;
> >  
> > +    register_keyhandler('w', &dump_console_ring_keyhandler);
> > +
> >      /* Serial input is directed to DOM0 by default. */
> >      switch_serial_input();
> >  }
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Sep 30 02:33:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 30 Sep 2012 02:33:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TI9Kc-0004FO-NP; Sun, 30 Sep 2012 02:32:34 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <joseph.glanville@orionvm.com.au>) id 1TI9Ka-0004FJ-OP
	for xen-devel@lists.xen.org; Sun, 30 Sep 2012 02:32:32 +0000
X-Env-Sender: joseph.glanville@orionvm.com.au
X-Msg-Ref: server-6.tower-27.messagelabs.com!1348972343!7316804!1
X-Originating-IP: [209.85.219.45]
X-SpamReason: No, hits=0.6 required=7.0 tests=MAILTO_TO_SPAM_ADDR, RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11841 invoked from network); 30 Sep 2012 02:32:24 -0000
Received: from mail-oa0-f45.google.com (HELO mail-oa0-f45.google.com)
	(209.85.219.45)
	by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Sep 2012 02:32:24 -0000
Received: by oagi18 with SMTP id i18so5521807oag.32
	for <xen-devel@lists.xen.org>; Sat, 29 Sep 2012 19:32:23 -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=aeDyKp2FgzZJ0YTSfqMTMq6TB5VpTHXHS0zYDaXauiM=;
	b=C3wNwhlQqMlVXxmZKBZu8OhimKvjuKO/mk3HnthpXabO+3P/moXoXso2oM397hgvNj
	Z2Hn4iwDNH7gjpBT382EKE0qHN38PWoLSdbqH+nBijA3PZ17jDC0rwPwrob+JE0+B4t7
	bpSV26mmUW7+mRCikeIYJHgh3acX3CTiHhBasqbS17RMvH4hW+H5wkzg04oBBE9TL6fQ
	1IkdSIdUJRr0SvNqbjZT1b23NI2W7xCBND5F60eeAlvCxNX12QT4ZjaCr/ezuKLdW+SY
	TixOctbZT6Z2/UkK+GjfAz/7ziGEZlTUoMvh5XGOTTiqgxF3Y3KBZrT2inHF35GmSvG7
	taVQ==
MIME-Version: 1.0
Received: by 10.60.171.164 with SMTP id av4mr3200143oec.59.1348972343010; Sat,
	29 Sep 2012 19:32:23 -0700 (PDT)
Received: by 10.182.60.97 with HTTP; Sat, 29 Sep 2012 19:32:22 -0700 (PDT)
X-Originating-IP: [121.44.64.127]
In-Reply-To: <1348882472.17803.140661134131069.4B02D98D@webmail.messagingengine.com>
References: <1348877636.5025.140661134113513.411BDE92@webmail.messagingengine.com>
	<1348882472.17803.140661134131069.4B02D98D@webmail.messagingengine.com>
Date: Sun, 30 Sep 2012 12:32:22 +1000
Message-ID: <CAOzFzEjDZD9uLOjNCkmzUJYnEy7UPgMLwjQKFK7UgxX+1sXJ1Q@mail.gmail.com>
From: Joseph Glanville <joseph.glanville@orionvm.com.au>
To: ar16@imapmail.org
X-Gm-Message-State: ALoCoQkPp5V7BBEuA1V1LJ9CWmfbhcY3wEEFVLxNlYUg5a02G1MZk9SvhlW2Zg1lhGgTVv+nDNz6
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Xen HVM Guest fails (errors) to launch on Opensuse
 12.2's Xen 4.2 + 'xl' toolstack
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 29 September 2012 11:34,  <ar16@imapmail.org> wrote:
> Using exactly the same setup and configuration, but changing toolstack
> from xl -> xm, i.e.
>
> service xend start
> xm create -c test.cfg
>
> The Guest launches, and is accessible via VNC  (very slow response;
> liklely a different issue)
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

Hi,

Does changing the guest disk specification to hda/hdb/hdc/hdd syntax
correct the problem?

Also, can you post the qemu-dm logs for that domain? (usually in
/var/log/xen/qemu-dm-*)

Joseph.

-- 
CTO | Orion Virtualisation Solutions | www.orionvm.com.au
Phone: 1300 56 99 52 | Mobile: 0428 754 846

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Sep 30 02:33:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 30 Sep 2012 02:33:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TI9Kc-0004FO-NP; Sun, 30 Sep 2012 02:32:34 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <joseph.glanville@orionvm.com.au>) id 1TI9Ka-0004FJ-OP
	for xen-devel@lists.xen.org; Sun, 30 Sep 2012 02:32:32 +0000
X-Env-Sender: joseph.glanville@orionvm.com.au
X-Msg-Ref: server-6.tower-27.messagelabs.com!1348972343!7316804!1
X-Originating-IP: [209.85.219.45]
X-SpamReason: No, hits=0.6 required=7.0 tests=MAILTO_TO_SPAM_ADDR, RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11841 invoked from network); 30 Sep 2012 02:32:24 -0000
Received: from mail-oa0-f45.google.com (HELO mail-oa0-f45.google.com)
	(209.85.219.45)
	by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Sep 2012 02:32:24 -0000
Received: by oagi18 with SMTP id i18so5521807oag.32
	for <xen-devel@lists.xen.org>; Sat, 29 Sep 2012 19:32:23 -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=aeDyKp2FgzZJ0YTSfqMTMq6TB5VpTHXHS0zYDaXauiM=;
	b=C3wNwhlQqMlVXxmZKBZu8OhimKvjuKO/mk3HnthpXabO+3P/moXoXso2oM397hgvNj
	Z2Hn4iwDNH7gjpBT382EKE0qHN38PWoLSdbqH+nBijA3PZ17jDC0rwPwrob+JE0+B4t7
	bpSV26mmUW7+mRCikeIYJHgh3acX3CTiHhBasqbS17RMvH4hW+H5wkzg04oBBE9TL6fQ
	1IkdSIdUJRr0SvNqbjZT1b23NI2W7xCBND5F60eeAlvCxNX12QT4ZjaCr/ezuKLdW+SY
	TixOctbZT6Z2/UkK+GjfAz/7ziGEZlTUoMvh5XGOTTiqgxF3Y3KBZrT2inHF35GmSvG7
	taVQ==
MIME-Version: 1.0
Received: by 10.60.171.164 with SMTP id av4mr3200143oec.59.1348972343010; Sat,
	29 Sep 2012 19:32:23 -0700 (PDT)
Received: by 10.182.60.97 with HTTP; Sat, 29 Sep 2012 19:32:22 -0700 (PDT)
X-Originating-IP: [121.44.64.127]
In-Reply-To: <1348882472.17803.140661134131069.4B02D98D@webmail.messagingengine.com>
References: <1348877636.5025.140661134113513.411BDE92@webmail.messagingengine.com>
	<1348882472.17803.140661134131069.4B02D98D@webmail.messagingengine.com>
Date: Sun, 30 Sep 2012 12:32:22 +1000
Message-ID: <CAOzFzEjDZD9uLOjNCkmzUJYnEy7UPgMLwjQKFK7UgxX+1sXJ1Q@mail.gmail.com>
From: Joseph Glanville <joseph.glanville@orionvm.com.au>
To: ar16@imapmail.org
X-Gm-Message-State: ALoCoQkPp5V7BBEuA1V1LJ9CWmfbhcY3wEEFVLxNlYUg5a02G1MZk9SvhlW2Zg1lhGgTVv+nDNz6
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Xen HVM Guest fails (errors) to launch on Opensuse
 12.2's Xen 4.2 + 'xl' toolstack
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On 29 September 2012 11:34,  <ar16@imapmail.org> wrote:
> Using exactly the same setup and configuration, but changing toolstack
> from xl -> xm, i.e.
>
> service xend start
> xm create -c test.cfg
>
> The Guest launches, and is accessible via VNC  (very slow response;
> liklely a different issue)
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

Hi,

Does changing the guest disk specification to hda/hdb/hdc/hdd syntax
correct the problem?

Also, can you post the qemu-dm logs for that domain? (usually in
/var/log/xen/qemu-dm-*)

Joseph.

-- 
CTO | Orion Virtualisation Solutions | www.orionvm.com.au
Phone: 1300 56 99 52 | Mobile: 0428 754 846

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Sep 30 05:05:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 30 Sep 2012 05: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 1TIBhp-0004yb-80; Sun, 30 Sep 2012 05:04: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 1TIBhn-0004yW-Vp
	for xen-devel@lists.xensource.com; Sun, 30 Sep 2012 05:04:40 +0000
Received: from [85.158.143.35:36924] by server-3.bemta-4.messagelabs.com id
	46/96-10986-7E2D7605; Sun, 30 Sep 2012 05:04:39 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1348981478!13298765!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTI1NDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 567 invoked from network); 30 Sep 2012 05:04:38 -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;
	30 Sep 2012 05:04:38 -0000
X-IronPort-AV: E=Sophos;i="4.80,511,1344211200"; d="scan'208";a="14851009"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Sep 2012 05:04: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.279.1; Sun, 30 Sep 2012 06:04:36 +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 1TIBhk-0005n2-Iw;
	Sun, 30 Sep 2012 05:04:36 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1TIBhk-00016e-20;
	Sun, 30 Sep 2012 06:04:36 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-13903-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sun, 30 Sep 2012 06:04:36 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13903: 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 13903 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13903/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 13902
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore            fail   like 13902
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail like 13902
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail like 13902

Tests which did not succeed, but are not blocking:
 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-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  bd953fda6106
baseline version:
 xen                  bd953fda6106

jobs:
 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-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-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-amd64-amd64-xl-win                                      fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Published tested tree is already up to date.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Sep 30 05:05:14 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 30 Sep 2012 05: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 1TIBhp-0004yb-80; Sun, 30 Sep 2012 05:04: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 1TIBhn-0004yW-Vp
	for xen-devel@lists.xensource.com; Sun, 30 Sep 2012 05:04:40 +0000
Received: from [85.158.143.35:36924] by server-3.bemta-4.messagelabs.com id
	46/96-10986-7E2D7605; Sun, 30 Sep 2012 05:04:39 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1348981478!13298765!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiAxMTI1NDg=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 567 invoked from network); 30 Sep 2012 05:04:38 -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;
	30 Sep 2012 05:04:38 -0000
X-IronPort-AV: E=Sophos;i="4.80,511,1344211200"; d="scan'208";a="14851009"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Sep 2012 05:04: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.279.1; Sun, 30 Sep 2012 06:04:36 +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 1TIBhk-0005n2-Iw;
	Sun, 30 Sep 2012 05:04:36 +0000
Received: from osstest by woking.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1TIBhk-00016e-20;
	Sun, 30 Sep 2012 06:04:36 +0100
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-13903-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sun, 30 Sep 2012 06:04:36 +0100
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 13903: 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 13903 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13903/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 13902
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore            fail   like 13902
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail like 13902
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail like 13902

Tests which did not succeed, but are not blocking:
 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-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  bd953fda6106
baseline version:
 xen                  bd953fda6106

jobs:
 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-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-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-amd64-amd64-xl-win                                      fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Published tested tree is already up to date.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Sep 30 06:23:00 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 30 Sep 2012 06: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 1TICv9-0005Rx-1Z; Sun, 30 Sep 2012 06:22:31 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ar16@imapmail.org>) id 1TICv7-0005Rk-BO
	for xen-devel@lists.xen.org; Sun, 30 Sep 2012 06:22:29 +0000
Received: from [85.158.139.83:3647] by server-8.bemta-5.messagelabs.com id
	37/25-18073-425E7605; Sun, 30 Sep 2012 06:22:28 +0000
X-Env-Sender: ar16@imapmail.org
X-Msg-Ref: server-9.tower-182.messagelabs.com!1348986147!32049285!1
X-Originating-IP: [66.111.4.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTExLjQuMjUgPT4gMjQ5Mjc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8563 invoked from network); 30 Sep 2012 06:22:28 -0000
Received: from out1-smtp.messagingengine.com (HELO
	out1-smtp.messagingengine.com) (66.111.4.25)
	by server-9.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 30 Sep 2012 06:22:28 -0000
Received: from compute3.internal (compute3.nyi.mail.srv.osa [10.202.2.43])
	by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 33BB5204D7;
	Sun, 30 Sep 2012 02:22:27 -0400 (EDT)
Received: from web1.nyi.mail.srv.osa ([10.202.2.211])
	by compute3.internal (MEProxy); Sun, 30 Sep 2012 02:22:27 -0400
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=imapmail.org; h=
	message-id:from:to:cc:mime-version:content-transfer-encoding
	:content-type:subject:date:in-reply-to:references; s=mesmtp; bh=
	O+LGewoREZxaR2RV/tWySSKlezk=; b=hbGKYla8shE8vn/feTxoMMYHUg2ICw4r
	JWuT101jz+qgeRkg7rF+k1YCd3lN82E5IuZbFtWLBS7FCidBOOJt8S9Phs8H1IJR
	H8vmKfN1Gs46FEPxlHjM92ZYWFxhCxryjYfObcMpEcoTHXAsfCVzJdyI6UTCRuXD
	jiDdcKX4l54=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=
	messagingengine.com; h=message-id:from:to:cc:mime-version
	:content-transfer-encoding:content-type:subject:date:in-reply-to
	:references; s=smtpout; bh=O+LGewoREZxaR2RV/tWySSKlezk=; b=EvuFK
	ocUSKzeMvbDUxeI0Jefs6yLvnmLOHln5Cd3HL7RK4qRthUnZVB/2WKYSM+1AG2ic
	DbvBXeuGYayVGubmYCKM5aLVY/rVWRYcO9ajjLAuzn3LPxEHP5MTTsgFr/8PGMRa
	7VvH0QoPdwLlkCrAwFwvH/YSHBnf2d/dxHEEjA=
Received: by web1.nyi.mail.srv.osa (Postfix, from userid 99)
	id EB424A0036F; Sun, 30 Sep 2012 02:22:26 -0400 (EDT)
Message-Id: <1348986146.22942.140661134484341.6F996F0F@webmail.messagingengine.com>
X-Sasl-Enc: K6daSN/NKVBr5BfoB/UHb/mtbYqtxX1YzA/yeKx6GXI2 1348986146
From: ar16@imapmail.org
To: Joseph Glanville <joseph.glanville@orionvm.com.au>
MIME-Version: 1.0
X-Mailer: MessagingEngine.com Webmail Interface
Date: Sat, 29 Sep 2012 23:22:26 -0700
In-Reply-To: <CAOzFzEjDZD9uLOjNCkmzUJYnEy7UPgMLwjQKFK7UgxX+1sXJ1Q@mail.gmail.com>
References: <1348877636.5025.140661134113513.411BDE92@webmail.messagingengine.com>
	<1348882472.17803.140661134131069.4B02D98D@webmail.messagingengine.com>
	<CAOzFzEjDZD9uLOjNCkmzUJYnEy7UPgMLwjQKFK7UgxX+1sXJ1Q@mail.gmail.com>
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Xen HVM Guest fails (errors) to launch on Opensuse
 12.2's Xen 4.2 + 'xl' toolstack
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

hi

On Sat, Sep 29, 2012, at 07:32 PM, Joseph Glanville wrote:
> Does changing the guest disk specification to hda/hdb/hdc/hdd syntax
> correct the problem?

no, it does not.

with config --

	...
	disk  = [       'phy:/dev/VG0/boot,hda,w',
				'phy:/dev/VG0/swap,hdb,w',
				'phy:/dev/VG0/root,hdc,w',
				'phy:/dev/cdrom,hdd:cdrom,r',
	...

executing

	xl -vvv create -c /home/ar/test.cfg

still returns,

	Parsing config from /home/ar/test.cfg
	libxl: debug: libxl_create.c:1173:do_domain_create: ao 0xd278e0:
	create: how=(nil) callback=(nil) poller=0xd281f0
	libxl: debug: libxl_device.c:229:libxl__device_disk_set_backend:
	Disk vdev=hda spec.backend=unknown
	libxl: debug: libxl_device.c:265:libxl__device_disk_set_backend:
	Disk vdev=hda, using backend phy
	libxl: debug: libxl_device.c:229:libxl__device_disk_set_backend:
	Disk vdev=hdb spec.backend=unknown
	libxl: debug: libxl_device.c:265:libxl__device_disk_set_backend:
	Disk vdev=hdb, using backend phy
	libxl: debug: libxl_device.c:229:libxl__device_disk_set_backend:
	Disk vdev=hdc spec.backend=unknown
	libxl: debug: libxl_device.c:265:libxl__device_disk_set_backend:
	Disk vdev=hdc, using backend phy
	libxl: debug: libxl_device.c:229:libxl__device_disk_set_backend:
	Disk vdev=hdd spec.backend=unknown
	libxl: debug: libxl_device.c:265:libxl__device_disk_set_backend:
	Disk vdev=hdd, using backend phy
	libxl: debug: libxl_create.c:677:initiate_domain_create: running
	bootloader
	libxl: debug: libxl_bootloader.c:321:libxl__bootloader_run: not
	a PV domain, skipping bootloader
	libxl: debug: libxl_event.c:561:libxl__ev_xswatch_deregister:
	watch w=0xd28790: deregister unregistered
	libxl: debug: libxl_numa.c:435:libxl__get_numa_candidate: New
	best NUMA placement candidate found: nr_nodes=1, nr_cpus=4,
	nr_vcpus=5, free_memkb=6841
	libxl: detail: libxl_dom.c:192:numa_place_domain: NUMA placement
	candidate with 1 nodes, 4 cpus and 6841 KB free selected
	xc: detail: elf_parse_binary: phdr: paddr=0x100000 memsz=0x9e028
	xc: detail: elf_parse_binary: memory: 0x100000 -> 0x19e028
	xc: info: VIRTUAL MEMORY ARRANGEMENT:
	  Loader:        0000000000100000->000000000019e028
	  TOTAL:         0000000000000000->000000003f000000
	  ENTRY ADDRESS: 0000000000100000
	xc: info: PHYSICAL MEMORY ALLOCATION:
	  4KB PAGES: 0x0000000000000200
	  2MB PAGES: 0x00000000000001f7
	  1GB PAGES: 0x0000000000000000
	xc: detail: elf_load_binary: phdr 0 at 0x0x7f9da35c1000 ->
	0x0x7f9da3655eb5
	libxl: error: libxl_create.c:901:domcreate_rebuild_done: cannot
	(re-)build domain: -3
	libxl: error: libxl_dm.c:1251:libxl__destroy_device_model: could
	not find device-model's pid for dom 70
	libxl: error: libxl.c:1429:libxl__destroy_domid:
	libxl__destroy_device_model failed for 70
	libxl: debug: libxl_event.c:1497:libxl__ao_complete: ao
	0xd278e0: complete, rc=-3
	libxl: debug: libxl_create.c:1186:do_domain_create: ao 0xd278e0:
	inprogress: poller=0xd281f0, flags=ic
	libxl: debug: libxl_event.c:1469:libxl__ao__destroy: ao
	0xd278e0: destroy
	xc: debug: hypercall buffer: total allocations:482 total
	releases:482
	xc: debug: hypercall buffer: current allocations:0 maximum
	allocations:4
	xc: debug: hypercall buffer: cache current size:4
	xc: debug: hypercall buffer: cache hits:474 misses:4 toobig:4

> Also, can you post the qemu-dm logs for that domain? (usually in
> /var/log/xen/qemu-dm-*)

cat /var/log/xen/qemu-dm-test.log
	domid: 69
	Using file /dev/VG0/boot in read-write mode
	Using file /dev/VG0/swap in read-write mode
	Using file /dev/VG0/root in read-write mode
	Using file /dev/cdrom in read-only mode
	Watching /local/domain/0/device-model/69/logdirty/cmd
	Watching /local/domain/0/device-model/69/command
	Watching /local/domain/69/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 = 4c29586f-89bd-8c01-e00a-5af6a7ce8267
	Time offset set 0
	char device redirected to /dev/pts/3
	xen be: console-0: xen be: console-0: initialise() failed
	initialise() failed
	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/69/xen_extended_power_mgmt):
	read error
	xs_read(): vncpasswd get error.
	/vm/4c29586f-89bd-8c01-e00a-5af6a7ce8267/vncpasswd.
	medium change watch on `hdd' (index: 3): /dev/cdrom
	I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0,
	size: 0
	Log-dirty: no command yet.
	xen be: console-0: xen be: console-0: initialise() failed
	initialise() failed
	vcpu-set: watch node error.
	xen be: console-0: xen be: console-0: initialise() failed
	initialise() failed
	xs_read(/local/domain/69/log-throttling): read error
	qemu: ignoring not-understood drive
	`/local/domain/69/log-throttling'
	medium change watch on `/local/domain/69/log-throttling' -
	unknown device, ignored
	xen be: console-0: xen be: console-0: initialise() failed
	initialise() failed

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Sep 30 06:23:00 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 30 Sep 2012 06: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 1TICv9-0005Rx-1Z; Sun, 30 Sep 2012 06:22:31 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ar16@imapmail.org>) id 1TICv7-0005Rk-BO
	for xen-devel@lists.xen.org; Sun, 30 Sep 2012 06:22:29 +0000
Received: from [85.158.139.83:3647] by server-8.bemta-5.messagelabs.com id
	37/25-18073-425E7605; Sun, 30 Sep 2012 06:22:28 +0000
X-Env-Sender: ar16@imapmail.org
X-Msg-Ref: server-9.tower-182.messagelabs.com!1348986147!32049285!1
X-Originating-IP: [66.111.4.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTExLjQuMjUgPT4gMjQ5Mjc=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8563 invoked from network); 30 Sep 2012 06:22:28 -0000
Received: from out1-smtp.messagingengine.com (HELO
	out1-smtp.messagingengine.com) (66.111.4.25)
	by server-9.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 30 Sep 2012 06:22:28 -0000
Received: from compute3.internal (compute3.nyi.mail.srv.osa [10.202.2.43])
	by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 33BB5204D7;
	Sun, 30 Sep 2012 02:22:27 -0400 (EDT)
Received: from web1.nyi.mail.srv.osa ([10.202.2.211])
	by compute3.internal (MEProxy); Sun, 30 Sep 2012 02:22:27 -0400
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=imapmail.org; h=
	message-id:from:to:cc:mime-version:content-transfer-encoding
	:content-type:subject:date:in-reply-to:references; s=mesmtp; bh=
	O+LGewoREZxaR2RV/tWySSKlezk=; b=hbGKYla8shE8vn/feTxoMMYHUg2ICw4r
	JWuT101jz+qgeRkg7rF+k1YCd3lN82E5IuZbFtWLBS7FCidBOOJt8S9Phs8H1IJR
	H8vmKfN1Gs46FEPxlHjM92ZYWFxhCxryjYfObcMpEcoTHXAsfCVzJdyI6UTCRuXD
	jiDdcKX4l54=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=
	messagingengine.com; h=message-id:from:to:cc:mime-version
	:content-transfer-encoding:content-type:subject:date:in-reply-to
	:references; s=smtpout; bh=O+LGewoREZxaR2RV/tWySSKlezk=; b=EvuFK
	ocUSKzeMvbDUxeI0Jefs6yLvnmLOHln5Cd3HL7RK4qRthUnZVB/2WKYSM+1AG2ic
	DbvBXeuGYayVGubmYCKM5aLVY/rVWRYcO9ajjLAuzn3LPxEHP5MTTsgFr/8PGMRa
	7VvH0QoPdwLlkCrAwFwvH/YSHBnf2d/dxHEEjA=
Received: by web1.nyi.mail.srv.osa (Postfix, from userid 99)
	id EB424A0036F; Sun, 30 Sep 2012 02:22:26 -0400 (EDT)
Message-Id: <1348986146.22942.140661134484341.6F996F0F@webmail.messagingengine.com>
X-Sasl-Enc: K6daSN/NKVBr5BfoB/UHb/mtbYqtxX1YzA/yeKx6GXI2 1348986146
From: ar16@imapmail.org
To: Joseph Glanville <joseph.glanville@orionvm.com.au>
MIME-Version: 1.0
X-Mailer: MessagingEngine.com Webmail Interface
Date: Sat, 29 Sep 2012 23:22:26 -0700
In-Reply-To: <CAOzFzEjDZD9uLOjNCkmzUJYnEy7UPgMLwjQKFK7UgxX+1sXJ1Q@mail.gmail.com>
References: <1348877636.5025.140661134113513.411BDE92@webmail.messagingengine.com>
	<1348882472.17803.140661134131069.4B02D98D@webmail.messagingengine.com>
	<CAOzFzEjDZD9uLOjNCkmzUJYnEy7UPgMLwjQKFK7UgxX+1sXJ1Q@mail.gmail.com>
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Xen HVM Guest fails (errors) to launch on Opensuse
 12.2's Xen 4.2 + 'xl' toolstack
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

hi

On Sat, Sep 29, 2012, at 07:32 PM, Joseph Glanville wrote:
> Does changing the guest disk specification to hda/hdb/hdc/hdd syntax
> correct the problem?

no, it does not.

with config --

	...
	disk  = [       'phy:/dev/VG0/boot,hda,w',
				'phy:/dev/VG0/swap,hdb,w',
				'phy:/dev/VG0/root,hdc,w',
				'phy:/dev/cdrom,hdd:cdrom,r',
	...

executing

	xl -vvv create -c /home/ar/test.cfg

still returns,

	Parsing config from /home/ar/test.cfg
	libxl: debug: libxl_create.c:1173:do_domain_create: ao 0xd278e0:
	create: how=(nil) callback=(nil) poller=0xd281f0
	libxl: debug: libxl_device.c:229:libxl__device_disk_set_backend:
	Disk vdev=hda spec.backend=unknown
	libxl: debug: libxl_device.c:265:libxl__device_disk_set_backend:
	Disk vdev=hda, using backend phy
	libxl: debug: libxl_device.c:229:libxl__device_disk_set_backend:
	Disk vdev=hdb spec.backend=unknown
	libxl: debug: libxl_device.c:265:libxl__device_disk_set_backend:
	Disk vdev=hdb, using backend phy
	libxl: debug: libxl_device.c:229:libxl__device_disk_set_backend:
	Disk vdev=hdc spec.backend=unknown
	libxl: debug: libxl_device.c:265:libxl__device_disk_set_backend:
	Disk vdev=hdc, using backend phy
	libxl: debug: libxl_device.c:229:libxl__device_disk_set_backend:
	Disk vdev=hdd spec.backend=unknown
	libxl: debug: libxl_device.c:265:libxl__device_disk_set_backend:
	Disk vdev=hdd, using backend phy
	libxl: debug: libxl_create.c:677:initiate_domain_create: running
	bootloader
	libxl: debug: libxl_bootloader.c:321:libxl__bootloader_run: not
	a PV domain, skipping bootloader
	libxl: debug: libxl_event.c:561:libxl__ev_xswatch_deregister:
	watch w=0xd28790: deregister unregistered
	libxl: debug: libxl_numa.c:435:libxl__get_numa_candidate: New
	best NUMA placement candidate found: nr_nodes=1, nr_cpus=4,
	nr_vcpus=5, free_memkb=6841
	libxl: detail: libxl_dom.c:192:numa_place_domain: NUMA placement
	candidate with 1 nodes, 4 cpus and 6841 KB free selected
	xc: detail: elf_parse_binary: phdr: paddr=0x100000 memsz=0x9e028
	xc: detail: elf_parse_binary: memory: 0x100000 -> 0x19e028
	xc: info: VIRTUAL MEMORY ARRANGEMENT:
	  Loader:        0000000000100000->000000000019e028
	  TOTAL:         0000000000000000->000000003f000000
	  ENTRY ADDRESS: 0000000000100000
	xc: info: PHYSICAL MEMORY ALLOCATION:
	  4KB PAGES: 0x0000000000000200
	  2MB PAGES: 0x00000000000001f7
	  1GB PAGES: 0x0000000000000000
	xc: detail: elf_load_binary: phdr 0 at 0x0x7f9da35c1000 ->
	0x0x7f9da3655eb5
	libxl: error: libxl_create.c:901:domcreate_rebuild_done: cannot
	(re-)build domain: -3
	libxl: error: libxl_dm.c:1251:libxl__destroy_device_model: could
	not find device-model's pid for dom 70
	libxl: error: libxl.c:1429:libxl__destroy_domid:
	libxl__destroy_device_model failed for 70
	libxl: debug: libxl_event.c:1497:libxl__ao_complete: ao
	0xd278e0: complete, rc=-3
	libxl: debug: libxl_create.c:1186:do_domain_create: ao 0xd278e0:
	inprogress: poller=0xd281f0, flags=ic
	libxl: debug: libxl_event.c:1469:libxl__ao__destroy: ao
	0xd278e0: destroy
	xc: debug: hypercall buffer: total allocations:482 total
	releases:482
	xc: debug: hypercall buffer: current allocations:0 maximum
	allocations:4
	xc: debug: hypercall buffer: cache current size:4
	xc: debug: hypercall buffer: cache hits:474 misses:4 toobig:4

> Also, can you post the qemu-dm logs for that domain? (usually in
> /var/log/xen/qemu-dm-*)

cat /var/log/xen/qemu-dm-test.log
	domid: 69
	Using file /dev/VG0/boot in read-write mode
	Using file /dev/VG0/swap in read-write mode
	Using file /dev/VG0/root in read-write mode
	Using file /dev/cdrom in read-only mode
	Watching /local/domain/0/device-model/69/logdirty/cmd
	Watching /local/domain/0/device-model/69/command
	Watching /local/domain/69/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 = 4c29586f-89bd-8c01-e00a-5af6a7ce8267
	Time offset set 0
	char device redirected to /dev/pts/3
	xen be: console-0: xen be: console-0: initialise() failed
	initialise() failed
	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/69/xen_extended_power_mgmt):
	read error
	xs_read(): vncpasswd get error.
	/vm/4c29586f-89bd-8c01-e00a-5af6a7ce8267/vncpasswd.
	medium change watch on `hdd' (index: 3): /dev/cdrom
	I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0,
	size: 0
	Log-dirty: no command yet.
	xen be: console-0: xen be: console-0: initialise() failed
	initialise() failed
	vcpu-set: watch node error.
	xen be: console-0: xen be: console-0: initialise() failed
	initialise() failed
	xs_read(/local/domain/69/log-throttling): read error
	qemu: ignoring not-understood drive
	`/local/domain/69/log-throttling'
	medium change watch on `/local/domain/69/log-throttling' -
	unknown device, ignored
	xen be: console-0: xen be: console-0: initialise() failed
	initialise() failed

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Sep 30 15:13:58 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 30 Sep 2012 15:13:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TILCw-0000aS-Ea; Sun, 30 Sep 2012 15:13:26 +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 1TILCv-0000aK-2I; Sun, 30 Sep 2012 15:13:25 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-5.tower-27.messagelabs.com!1349017997!6806956!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA1MjEyOTQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1054 invoked from network); 30 Sep 2012 15:13:17 -0000
Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25)
	by server-5.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 30 Sep 2012 15:13: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 2304E13DB;
	Sun, 30 Sep 2012 18:13:14 +0300 (EEST)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id 7DA7B2005D; Sun, 30 Sep 2012 18:13:14 +0300 (EEST)
Date: Sun, 30 Sep 2012 18:13:14 +0300
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: Mauro <mrsanna1@gmail.com>
Message-ID: <20120930151314.GU8912@reaktio.net>
References: <AANLkTikptc2POrKQgJuoVZRdwJTo64DJ_hm12KuPky4D@mail.gmail.com>
	<b1ca6ddc-ca69-447e-93e9-8d36d1ff4a43@default>
	<AANLkTinK94GDOF_GeaVs50wK0u8EdZ2rtzPuh65ca8qR@mail.gmail.com>
	<CAE17a0UPyzsNn=ps9MxarkGg=ns8dCpVz0qBDvesT2AOskwfVg@mail.gmail.com>
	<65395f62-74e5-4910-b701-8df629c2ce3b@default>
	<CABx4GKrQxOOQo_uUXSFvy0nzdMp1A_qc=_e4K+88GkB7xv=9nw@mail.gmail.com>
	<CAE17a0VkMuUEG9VaM7AFrwcsEjVBq9RfvTWz1_KmscAyCxeAbA@mail.gmail.com>
	<CABx4GKqrTEV7CEnAVUfYr-+yky8N5P1U29xDbrESH-mHB0iZhQ@mail.gmail.com>
	<CAE17a0UYwqLxoZaVDgQCvUR2KQK4vvP3bkvsdrwgnsUp33xuNQ@mail.gmail.com>
	<CAE17a0UQocJjZc38c2805uYvdwR7e447UGH9ywcxMw1Ge3imfg@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAE17a0UQocJjZc38c2805uYvdwR7e447UGH9ywcxMw1Ge3imfg@mail.gmail.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: Dan Magenheimer <dan.magenheimer@oracle.com>, xen-devel@lists.xensource.com,
	Keir Fraser <keir@xen.org>, Jeremy Fitzhardinge <jeremy@goop.org>,
	Olivier Hanesse <olivier.hanesse@gmail.com>,
	Keir Fraser <keir.xen@gmail.com>,
	Xen Users <xen-users@lists.xensource.com>,
	Mark Adams <mark@campbell-lange.net>
Subject: Re: [Xen-devel] [Xen-users] Re:  Xen 4 TSC problems
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Sat, Sep 29, 2012 at 02:19:55PM +0200, Mauro wrote:
> It's happened another time, system date 50 minutes ahead.
> There is really no solution?
> 

Try with a recent Xen hypervisor version. Xen 4.1.3 or 4.2.0.
It helps a lot to know if the issue is still in the latest hypervisor versions or not.

4.0.1 is quite old already.. and besides 4.0.4 is the latest version in 4.0 branch.

-- Pasi

> root@xen-p02:~# date
> sab 29 set 2012, 15.06.25, CEST
> 
> root@xen-p02:~# hwclock --debug
> hwclock from util-linux-ng 2.17.2
> Using /dev interface to clock.
> Last drift adjustment done at 1348816781 seconds after 1969
> Last calibration done at 1348816781 seconds after 1969
> Hardware clock is on UTC time
> Assuming hardware clock is kept in UTC time.
> Waiting for clock tick...
> ...got clock tick
> Time read from Hardware Clock: 2012/09/29 12:16:58
> Hw clock time : 2012/09/29 12:16:58 = 1348921018 seconds since 1969
> sab 29 set 2012 14:16:58 CEST  -0.751536 seconds
> 
> root@xen-p02:~# hwclock --show
> sab 29 set 2012 14:17:12 CEST  -0.423643 seconds
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Sep 30 15:13:58 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 30 Sep 2012 15:13:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TILCw-0000aS-Ea; Sun, 30 Sep 2012 15:13:26 +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 1TILCv-0000aK-2I; Sun, 30 Sep 2012 15:13:25 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-5.tower-27.messagelabs.com!1349017997!6806956!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA1MjEyOTQ=\n
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1054 invoked from network); 30 Sep 2012 15:13:17 -0000
Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25)
	by server-5.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 30 Sep 2012 15:13: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 2304E13DB;
	Sun, 30 Sep 2012 18:13:14 +0300 (EEST)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id 7DA7B2005D; Sun, 30 Sep 2012 18:13:14 +0300 (EEST)
Date: Sun, 30 Sep 2012 18:13:14 +0300
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: Mauro <mrsanna1@gmail.com>
Message-ID: <20120930151314.GU8912@reaktio.net>
References: <AANLkTikptc2POrKQgJuoVZRdwJTo64DJ_hm12KuPky4D@mail.gmail.com>
	<b1ca6ddc-ca69-447e-93e9-8d36d1ff4a43@default>
	<AANLkTinK94GDOF_GeaVs50wK0u8EdZ2rtzPuh65ca8qR@mail.gmail.com>
	<CAE17a0UPyzsNn=ps9MxarkGg=ns8dCpVz0qBDvesT2AOskwfVg@mail.gmail.com>
	<65395f62-74e5-4910-b701-8df629c2ce3b@default>
	<CABx4GKrQxOOQo_uUXSFvy0nzdMp1A_qc=_e4K+88GkB7xv=9nw@mail.gmail.com>
	<CAE17a0VkMuUEG9VaM7AFrwcsEjVBq9RfvTWz1_KmscAyCxeAbA@mail.gmail.com>
	<CABx4GKqrTEV7CEnAVUfYr-+yky8N5P1U29xDbrESH-mHB0iZhQ@mail.gmail.com>
	<CAE17a0UYwqLxoZaVDgQCvUR2KQK4vvP3bkvsdrwgnsUp33xuNQ@mail.gmail.com>
	<CAE17a0UQocJjZc38c2805uYvdwR7e447UGH9ywcxMw1Ge3imfg@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAE17a0UQocJjZc38c2805uYvdwR7e447UGH9ywcxMw1Ge3imfg@mail.gmail.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: Dan Magenheimer <dan.magenheimer@oracle.com>, xen-devel@lists.xensource.com,
	Keir Fraser <keir@xen.org>, Jeremy Fitzhardinge <jeremy@goop.org>,
	Olivier Hanesse <olivier.hanesse@gmail.com>,
	Keir Fraser <keir.xen@gmail.com>,
	Xen Users <xen-users@lists.xensource.com>,
	Mark Adams <mark@campbell-lange.net>
Subject: Re: [Xen-devel] [Xen-users] Re:  Xen 4 TSC problems
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

On Sat, Sep 29, 2012 at 02:19:55PM +0200, Mauro wrote:
> It's happened another time, system date 50 minutes ahead.
> There is really no solution?
> 

Try with a recent Xen hypervisor version. Xen 4.1.3 or 4.2.0.
It helps a lot to know if the issue is still in the latest hypervisor versions or not.

4.0.1 is quite old already.. and besides 4.0.4 is the latest version in 4.0 branch.

-- Pasi

> root@xen-p02:~# date
> sab 29 set 2012, 15.06.25, CEST
> 
> root@xen-p02:~# hwclock --debug
> hwclock from util-linux-ng 2.17.2
> Using /dev interface to clock.
> Last drift adjustment done at 1348816781 seconds after 1969
> Last calibration done at 1348816781 seconds after 1969
> Hardware clock is on UTC time
> Assuming hardware clock is kept in UTC time.
> Waiting for clock tick...
> ...got clock tick
> Time read from Hardware Clock: 2012/09/29 12:16:58
> Hw clock time : 2012/09/29 12:16:58 = 1348921018 seconds since 1969
> sab 29 set 2012 14:16:58 CEST  -0.751536 seconds
> 
> root@xen-p02:~# hwclock --show
> sab 29 set 2012 14:17:12 CEST  -0.423643 seconds
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/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 Sep 30 20:02:19 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 30 Sep 2012 20: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 1TIPhi-0002rQ-Sd; Sun, 30 Sep 2012 20:01:30 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mrsanna1@gmail.com>) id 1TIP7D-0002PV-4H
	for xen-devel@lists.xensource.com; Sun, 30 Sep 2012 19:23:47 +0000
Received: from [85.158.143.35:28224] by server-2.bemta-4.messagelabs.com id
	04/8A-06610-24C98605; Sun, 30 Sep 2012 19:23:46 +0000
X-Env-Sender: mrsanna1@gmail.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1349033024!14347235!1
X-Originating-IP: [209.85.220.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3107 invoked from network); 30 Sep 2012 19:23:45 -0000
Received: from mail-vc0-f171.google.com (HELO mail-vc0-f171.google.com)
	(209.85.220.171)
	by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Sep 2012 19:23:45 -0000
Received: by vcmm18 with SMTP id m18so6266401vcm.30
	for <multiple recipients>; Sun, 30 Sep 2012 12:23:44 -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=S6DOuzPTttiLRHgSDA5DcR9zBsABjWntkdBwVQc0bG0=;
	b=AbkHOyIHzdwrTIKcbyl/9ME+NjEbcn3DEvWZhz/hIbuiS+Ss0VQWMfP0qvcZU425IQ
	RQk7RrSO9cF7c4r63VnU5wgbl2UmVPH3/OddcMkf0hNugU58jyJRQg52pQ/9hZuhG+A4
	ZNkQE8Hwbb6TLupVobtUBLqY8vdVJiV4UBq4jx0jHnaWBhZ/6kpkeb8ka6OoLjAvivbH
	eK/fWpAy/7/1E5f+l01+uYuMzArvOh3leXxBJaYT4lHRPqtT4KtJuqrdWvXtC69AHm/Q
	wu+oBZqnR/IfxQP4zdXBvwEk4YWe0v5lAeWACt0oaeY/++od0QOYZC32BpXpSQ9gS0WA
	0Weg==
MIME-Version: 1.0
Received: by 10.52.69.132 with SMTP id e4mr5884953vdu.2.1349033024424; Sun, 30
	Sep 2012 12:23:44 -0700 (PDT)
Received: by 10.58.207.75 with HTTP; Sun, 30 Sep 2012 12:23:44 -0700 (PDT)
In-Reply-To: <20120930151314.GU8912@reaktio.net>
References: <AANLkTikptc2POrKQgJuoVZRdwJTo64DJ_hm12KuPky4D@mail.gmail.com>
	<b1ca6ddc-ca69-447e-93e9-8d36d1ff4a43@default>
	<AANLkTinK94GDOF_GeaVs50wK0u8EdZ2rtzPuh65ca8qR@mail.gmail.com>
	<CAE17a0UPyzsNn=ps9MxarkGg=ns8dCpVz0qBDvesT2AOskwfVg@mail.gmail.com>
	<65395f62-74e5-4910-b701-8df629c2ce3b@default>
	<CABx4GKrQxOOQo_uUXSFvy0nzdMp1A_qc=_e4K+88GkB7xv=9nw@mail.gmail.com>
	<CAE17a0VkMuUEG9VaM7AFrwcsEjVBq9RfvTWz1_KmscAyCxeAbA@mail.gmail.com>
	<CABx4GKqrTEV7CEnAVUfYr-+yky8N5P1U29xDbrESH-mHB0iZhQ@mail.gmail.com>
	<CAE17a0UYwqLxoZaVDgQCvUR2KQK4vvP3bkvsdrwgnsUp33xuNQ@mail.gmail.com>
	<CAE17a0UQocJjZc38c2805uYvdwR7e447UGH9ywcxMw1Ge3imfg@mail.gmail.com>
	<20120930151314.GU8912@reaktio.net>
Date: Sun, 30 Sep 2012 21:23:44 +0200
Message-ID: <CAE17a0WWvpwW-V5hQOgL1CiuVZFKyzhZVZfTVq74ZsJUo1SE8w@mail.gmail.com>
From: Mauro <mrsanna1@gmail.com>
To: =?UTF-8?B?UGFzaSBLw6Rya2vDpGluZW4=?= <pasik@iki.fi>
X-Mailman-Approved-At: Sun, 30 Sep 2012 20:01:28 +0000
Cc: Dan Magenheimer <dan.magenheimer@oracle.com>, xen-devel@lists.xensource.com,
	Keir Fraser <keir@xen.org>, Jeremy Fitzhardinge <jeremy@goop.org>,
	Olivier Hanesse <olivier.hanesse@gmail.com>,
	Keir Fraser <keir.xen@gmail.com>,
	Xen Users <xen-users@lists.xensource.com>,
	Mark Adams <mark@campbell-lange.net>
Subject: Re: [Xen-devel] [Xen-users] Re: Xen 4 TSC problems
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gMzAgU2VwdGVtYmVyIDIwMTIgMTc6MTMsIFBhc2kgS8Okcmtrw6RpbmVuIDxwYXNpa0Bpa2ku
Zmk+IHdyb3RlOgo+IE9uIFNhdCwgU2VwIDI5LCAyMDEyIGF0IDAyOjE5OjU1UE0gKzAyMDAsIE1h
dXJvIHdyb3RlOgo+PiBJdCdzIGhhcHBlbmVkIGFub3RoZXIgdGltZSwgc3lzdGVtIGRhdGUgNTAg
bWludXRlcyBhaGVhZC4KPj4gVGhlcmUgaXMgcmVhbGx5IG5vIHNvbHV0aW9uPwo+Pgo+Cj4gVHJ5
IHdpdGggYSByZWNlbnQgWGVuIGh5cGVydmlzb3IgdmVyc2lvbi4gWGVuIDQuMS4zIG9yIDQuMi4w
Lgo+IEl0IGhlbHBzIGEgbG90IHRvIGtub3cgaWYgdGhlIGlzc3VlIGlzIHN0aWxsIGluIHRoZSBs
YXRlc3QgaHlwZXJ2aXNvciB2ZXJzaW9ucyBvciBub3QuCgpJJ20gdXNpbmcgZGViaWFuIHNxdWVl
emUgeGVuIGtlcm5lbCBhbmQgdGhpcyBrZXJuZWwgaGFzIHhlbiA0LjAuCgpfX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0
Clhlbi1kZXZlbEBsaXN0cy54ZW4ub3JnCmh0dHA6Ly9saXN0cy54ZW4ub3JnL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xen.org Sun Sep 30 20:02:19 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 30 Sep 2012 20: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 1TIPhi-0002rQ-Sd; Sun, 30 Sep 2012 20:01:30 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mrsanna1@gmail.com>) id 1TIP7D-0002PV-4H
	for xen-devel@lists.xensource.com; Sun, 30 Sep 2012 19:23:47 +0000
Received: from [85.158.143.35:28224] by server-2.bemta-4.messagelabs.com id
	04/8A-06610-24C98605; Sun, 30 Sep 2012 19:23:46 +0000
X-Env-Sender: mrsanna1@gmail.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1349033024!14347235!1
X-Originating-IP: [209.85.220.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3107 invoked from network); 30 Sep 2012 19:23:45 -0000
Received: from mail-vc0-f171.google.com (HELO mail-vc0-f171.google.com)
	(209.85.220.171)
	by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Sep 2012 19:23:45 -0000
Received: by vcmm18 with SMTP id m18so6266401vcm.30
	for <multiple recipients>; Sun, 30 Sep 2012 12:23:44 -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=S6DOuzPTttiLRHgSDA5DcR9zBsABjWntkdBwVQc0bG0=;
	b=AbkHOyIHzdwrTIKcbyl/9ME+NjEbcn3DEvWZhz/hIbuiS+Ss0VQWMfP0qvcZU425IQ
	RQk7RrSO9cF7c4r63VnU5wgbl2UmVPH3/OddcMkf0hNugU58jyJRQg52pQ/9hZuhG+A4
	ZNkQE8Hwbb6TLupVobtUBLqY8vdVJiV4UBq4jx0jHnaWBhZ/6kpkeb8ka6OoLjAvivbH
	eK/fWpAy/7/1E5f+l01+uYuMzArvOh3leXxBJaYT4lHRPqtT4KtJuqrdWvXtC69AHm/Q
	wu+oBZqnR/IfxQP4zdXBvwEk4YWe0v5lAeWACt0oaeY/++od0QOYZC32BpXpSQ9gS0WA
	0Weg==
MIME-Version: 1.0
Received: by 10.52.69.132 with SMTP id e4mr5884953vdu.2.1349033024424; Sun, 30
	Sep 2012 12:23:44 -0700 (PDT)
Received: by 10.58.207.75 with HTTP; Sun, 30 Sep 2012 12:23:44 -0700 (PDT)
In-Reply-To: <20120930151314.GU8912@reaktio.net>
References: <AANLkTikptc2POrKQgJuoVZRdwJTo64DJ_hm12KuPky4D@mail.gmail.com>
	<b1ca6ddc-ca69-447e-93e9-8d36d1ff4a43@default>
	<AANLkTinK94GDOF_GeaVs50wK0u8EdZ2rtzPuh65ca8qR@mail.gmail.com>
	<CAE17a0UPyzsNn=ps9MxarkGg=ns8dCpVz0qBDvesT2AOskwfVg@mail.gmail.com>
	<65395f62-74e5-4910-b701-8df629c2ce3b@default>
	<CABx4GKrQxOOQo_uUXSFvy0nzdMp1A_qc=_e4K+88GkB7xv=9nw@mail.gmail.com>
	<CAE17a0VkMuUEG9VaM7AFrwcsEjVBq9RfvTWz1_KmscAyCxeAbA@mail.gmail.com>
	<CABx4GKqrTEV7CEnAVUfYr-+yky8N5P1U29xDbrESH-mHB0iZhQ@mail.gmail.com>
	<CAE17a0UYwqLxoZaVDgQCvUR2KQK4vvP3bkvsdrwgnsUp33xuNQ@mail.gmail.com>
	<CAE17a0UQocJjZc38c2805uYvdwR7e447UGH9ywcxMw1Ge3imfg@mail.gmail.com>
	<20120930151314.GU8912@reaktio.net>
Date: Sun, 30 Sep 2012 21:23:44 +0200
Message-ID: <CAE17a0WWvpwW-V5hQOgL1CiuVZFKyzhZVZfTVq74ZsJUo1SE8w@mail.gmail.com>
From: Mauro <mrsanna1@gmail.com>
To: =?UTF-8?B?UGFzaSBLw6Rya2vDpGluZW4=?= <pasik@iki.fi>
X-Mailman-Approved-At: Sun, 30 Sep 2012 20:01:28 +0000
Cc: Dan Magenheimer <dan.magenheimer@oracle.com>, xen-devel@lists.xensource.com,
	Keir Fraser <keir@xen.org>, Jeremy Fitzhardinge <jeremy@goop.org>,
	Olivier Hanesse <olivier.hanesse@gmail.com>,
	Keir Fraser <keir.xen@gmail.com>,
	Xen Users <xen-users@lists.xensource.com>,
	Mark Adams <mark@campbell-lange.net>
Subject: Re: [Xen-devel] [Xen-users] Re: Xen 4 TSC problems
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gMzAgU2VwdGVtYmVyIDIwMTIgMTc6MTMsIFBhc2kgS8Okcmtrw6RpbmVuIDxwYXNpa0Bpa2ku
Zmk+IHdyb3RlOgo+IE9uIFNhdCwgU2VwIDI5LCAyMDEyIGF0IDAyOjE5OjU1UE0gKzAyMDAsIE1h
dXJvIHdyb3RlOgo+PiBJdCdzIGhhcHBlbmVkIGFub3RoZXIgdGltZSwgc3lzdGVtIGRhdGUgNTAg
bWludXRlcyBhaGVhZC4KPj4gVGhlcmUgaXMgcmVhbGx5IG5vIHNvbHV0aW9uPwo+Pgo+Cj4gVHJ5
IHdpdGggYSByZWNlbnQgWGVuIGh5cGVydmlzb3IgdmVyc2lvbi4gWGVuIDQuMS4zIG9yIDQuMi4w
Lgo+IEl0IGhlbHBzIGEgbG90IHRvIGtub3cgaWYgdGhlIGlzc3VlIGlzIHN0aWxsIGluIHRoZSBs
YXRlc3QgaHlwZXJ2aXNvciB2ZXJzaW9ucyBvciBub3QuCgpJJ20gdXNpbmcgZGViaWFuIHNxdWVl
emUgeGVuIGtlcm5lbCBhbmQgdGhpcyBrZXJuZWwgaGFzIHhlbiA0LjAuCgpfX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0
Clhlbi1kZXZlbEBsaXN0cy54ZW4ub3JnCmh0dHA6Ly9saXN0cy54ZW4ub3JnL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xen.org Sun Sep 30 20:02:20 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 30 Sep 2012 20:02:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TIPhi-0002rJ-HF; Sun, 30 Sep 2012 20:01:30 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <james@dingwall.me.uk>) id 1TIM9N-0001rh-5k
	for xen-devel@lists.xen.org; Sun, 30 Sep 2012 16:13:49 +0000
Received: from [85.158.143.35:13891] by server-1.bemta-4.messagelabs.com id
	68/B6-05684-CBF68605; Sun, 30 Sep 2012 16:13:48 +0000
X-Env-Sender: james@dingwall.me.uk
X-Msg-Ref: server-9.tower-21.messagelabs.com!1349021627!5708353!1
X-Originating-IP: [81.103.221.48]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10158 invoked from network); 30 Sep 2012 16:13:47 -0000
Received: from mtaout02-winn.ispmail.ntl.com (HELO
	mtaout02-winn.ispmail.ntl.com) (81.103.221.48)
	by server-9.tower-21.messagelabs.com with SMTP;
	30 Sep 2012 16:13:47 -0000
Received: from know-smtpout-1.server.virginmedia.net ([62.254.123.2])
	by mtaout02-winn.ispmail.ntl.com
	(InterMail vM.7.08.04.00 201-2186-134-20080326) with ESMTP id
	<20120930161347.MMWZ1732.mtaout02-winn.ispmail.ntl.com@know-smtpout-1.server.virginmedia.net>
	for <xen-devel@lists.xen.org>; Sun, 30 Sep 2012 17:13:47 +0100
Received: from [82.32.104.97] (helo=dingwall.me.uk)
	by know-smtpout-1.server.virginmedia.net with esmtp (Exim 4.63)
	(envelope-from <james@dingwall.me.uk>) id 1TIM9K-000854-Ho
	for xen-devel@lists.xen.org; Sun, 30 Sep 2012 17:13:46 +0100
Received: (qmail 15873 invoked from network); 30 Sep 2012 16:13:46 -0000
Received: from behemoth.dingwall.me.uk (192.168.1.5)
	by mail0.xen.dingwall.me.uk with SMTP; 30 Sep 2012 16:13:46 -0000
Received: by behemoth.dingwall.me.uk (Postfix, from userid 1000)
	id 367EDD08C20; Sun, 30 Sep 2012 17:13:46 +0100 (BST)
Date: Sun, 30 Sep 2012 17:13:45 +0100
From: James Dingwall <james@dingwall.me.uk>
To: xen-devel@lists.xen.org
Message-ID: <20120930161345.GA31109@dingwall.me.uk>
MIME-Version: 1.0
Content-Disposition: inline
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Cloudmark-Analysis: v=1.1 cv=GaEGOwq9FwezmTggA+b6yC6zDZF2HYaK6RN/tSqdnVA=
	c=1 sm=0 a=wom5GMh1gUkA:10 a=OWi5QT2UpnQA:10 a=kj9zAlcOel0A:10
	a=CFJKkHzFcQURHE0lyYgA:9 a=CjuIK1q_8ugA:10
	a=HpAAvcLHHh0Zw7uRqdWCyQ==:117
X-Mailman-Approved-At: Sun, 30 Sep 2012 20:01:29 +0000
Subject: [Xen-devel] [james-xen@dingwall.me.uk: [Xen-users] Xen 4.2.0 - CPU
 Frequency Scaling]
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 didn't get any response on xen-users for this issue but so I'm hoping 
-devel can help.

I have had problems using cpu frequency scaling since the 
xen-acpi-processor code was added to the mainline kernel source.  I 
wasn't sure if the problem I was seeing was related to the old version 
(4.1.2) of Xen that I was using but now I'm on 4.2.0 and it still exists 
I thought I would check if I have a misconfiguration or if I have 
discovered a problem.  My system is a dual AMD Opteron(tm) Processor 
2423 HE on kernel 3.4.8.

The xen command line is:
 console=vga,com2 com2=115200,8n1 dom0_mem=max:2048M dom0_max_vcpus=2
dom0_vcpus_pin

The CPU scaling information reported by xenpm is below.  The problem
is that only cpuid 1 can be managed separately, all the others are
bundled together and cannot be handled independently which used to be
possible with the old xen kernel.  If further information would be
useful please let me know.

Thanks,
James

# xenpm get-cpufreq-para
cpu id               : 0
affected_cpus        : 0 2 3 4 5 6 7 8 9 10 11
cpuinfo frequency    : max [2000000] min [800000] cur [800000]
scaling_driver       :
scaling_avail_gov    : userspace performance powersave ondemand
current_governor     : ondemand
  ondemand specific  :
    sampling_rate    : max [10000000] min [10000] cur [20000]
    up_threshold     : 80
scaling_avail_freq   : 2000000 1500000 1300000 1000000 *800000
scaling frequency    : max [2000000] min [800000] cur [800000]

cpu id               : 1
affected_cpus        : 1
cpuinfo frequency    : max [2000000] min [800000] cur [800000]
scaling_driver       :
scaling_avail_gov    : userspace performance powersave ondemand
current_governor     : ondemand
  ondemand specific  :
    sampling_rate    : max [10000000] min [10000] cur [20000]
    up_threshold     : 80
scaling_avail_freq   : 2000000 1500000 1300000 1000000 *800000
scaling frequency    : max [2000000] min [800000] cur [800000]

cpu id               : 2
affected_cpus        : 0 2 3 4 5 6 7 8 9 10 11
cpuinfo frequency    : max [2000000] min [800000] cur [800000]
scaling_driver       :
scaling_avail_gov    : userspace performance powersave ondemand
current_governor     : ondemand
  ondemand specific  :
    sampling_rate    : max [10000000] min [10000] cur [20000]
    up_threshold     : 80
scaling_avail_freq   : 2000000 1500000 1300000 1000000 *800000
scaling frequency    : max [2000000] min [800000] cur [800000]

cpu id               : 3
affected_cpus        : 0 2 3 4 5 6 7 8 9 10 11
cpuinfo frequency    : max [2000000] min [800000] cur [800000]
scaling_driver       :
scaling_avail_gov    : userspace performance powersave ondemand
current_governor     : ondemand
  ondemand specific  :
    sampling_rate    : max [10000000] min [10000] cur [20000]
    up_threshold     : 80
scaling_avail_freq   : 2000000 1500000 1300000 1000000 *800000
scaling frequency    : max [2000000] min [800000] cur [800000]

cpu id               : 4
affected_cpus        : 0 2 3 4 5 6 7 8 9 10 11
cpuinfo frequency    : max [2000000] min [800000] cur [800000]
scaling_driver       :
scaling_avail_gov    : userspace performance powersave ondemand
current_governor     : ondemand
  ondemand specific  :
    sampling_rate    : max [10000000] min [10000] cur [20000]
    up_threshold     : 80
scaling_avail_freq   : 2000000 1500000 1300000 1000000 *800000
scaling frequency    : max [2000000] min [800000] cur [800000]

cpu id               : 5
affected_cpus        : 0 2 3 4 5 6 7 8 9 10 11
cpuinfo frequency    : max [2000000] min [800000] cur [800000]
scaling_driver       :
scaling_avail_gov    : userspace performance powersave ondemand
current_governor     : ondemand
  ondemand specific  :
    sampling_rate    : max [10000000] min [10000] cur [20000]
    up_threshold     : 80
scaling_avail_freq   : 2000000 1500000 1300000 1000000 *800000
scaling frequency    : max [2000000] min [800000] cur [800000]

cpu id               : 6
affected_cpus        : 0 2 3 4 5 6 7 8 9 10 11
cpuinfo frequency    : max [2000000] min [800000] cur [800000]
scaling_driver       :
scaling_avail_gov    : userspace performance powersave ondemand
current_governor     : ondemand
  ondemand specific  :
    sampling_rate    : max [10000000] min [10000] cur [20000]
    up_threshold     : 80
scaling_avail_freq   : 2000000 1500000 1300000 1000000 *800000
scaling frequency    : max [2000000] min [800000] cur [800000]

cpu id               : 7
affected_cpus        : 0 2 3 4 5 6 7 8 9 10 11
cpuinfo frequency    : max [2000000] min [800000] cur [800000]
scaling_driver       :
scaling_avail_gov    : userspace performance powersave ondemand
current_governor     : ondemand
  ondemand specific  :
    sampling_rate    : max [10000000] min [10000] cur [20000]
    up_threshold     : 80
scaling_avail_freq   : 2000000 1500000 1300000 1000000 *800000
scaling frequency    : max [2000000] min [800000] cur [800000]

cpu id               : 8
affected_cpus        : 0 2 3 4 5 6 7 8 9 10 11
cpuinfo frequency    : max [2000000] min [800000] cur [800000]
scaling_driver       :
scaling_avail_gov    : userspace performance powersave ondemand
current_governor     : ondemand
  ondemand specific  :
    sampling_rate    : max [10000000] min [10000] cur [20000]
    up_threshold     : 80
scaling_avail_freq   : 2000000 1500000 1300000 1000000 *800000
scaling frequency    : max [2000000] min [800000] cur [800000]

cpu id               : 9
affected_cpus        : 0 2 3 4 5 6 7 8 9 10 11
cpuinfo frequency    : max [2000000] min [800000] cur [800000]
scaling_driver       :
scaling_avail_gov    : userspace performance powersave ondemand
current_governor     : ondemand
  ondemand specific  :
    sampling_rate    : max [10000000] min [10000] cur [20000]
    up_threshold     : 80
scaling_avail_freq   : 2000000 1500000 1300000 1000000 *800000
scaling frequency    : max [2000000] min [800000] cur [800000]

cpu id               : 10
affected_cpus        : 0 2 3 4 5 6 7 8 9 10 11
cpuinfo frequency    : max [2000000] min [800000] cur [800000]
scaling_driver       :
scaling_avail_gov    : userspace performance powersave ondemand
current_governor     : ondemand
  ondemand specific  :
    sampling_rate    : max [10000000] min [10000] cur [20000]
    up_threshold     : 80
scaling_avail_freq   : 2000000 1500000 1300000 1000000 *800000
scaling frequency    : max [2000000] min [800000] cur [800000]

cpu id               : 11
affected_cpus        : 0 2 3 4 5 6 7 8 9 10 11
cpuinfo frequency    : max [2000000] min [800000] cur [800000]
scaling_driver       :
scaling_avail_gov    : userspace performance powersave ondemand
current_governor     : ondemand
  ondemand specific  :
    sampling_rate    : max [10000000] min [10000] cur [20000]
    up_threshold     : 80
scaling_avail_freq   : 2000000 1500000 1300000 1000000 *800000
scaling frequency    : max [2000000] min [800000] cur [800000]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Sep 30 20:02:20 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 30 Sep 2012 20:02:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TIPhi-0002rJ-HF; Sun, 30 Sep 2012 20:01:30 +0000
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <james@dingwall.me.uk>) id 1TIM9N-0001rh-5k
	for xen-devel@lists.xen.org; Sun, 30 Sep 2012 16:13:49 +0000
Received: from [85.158.143.35:13891] by server-1.bemta-4.messagelabs.com id
	68/B6-05684-CBF68605; Sun, 30 Sep 2012 16:13:48 +0000
X-Env-Sender: james@dingwall.me.uk
X-Msg-Ref: server-9.tower-21.messagelabs.com!1349021627!5708353!1
X-Originating-IP: [81.103.221.48]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10158 invoked from network); 30 Sep 2012 16:13:47 -0000
Received: from mtaout02-winn.ispmail.ntl.com (HELO
	mtaout02-winn.ispmail.ntl.com) (81.103.221.48)
	by server-9.tower-21.messagelabs.com with SMTP;
	30 Sep 2012 16:13:47 -0000
Received: from know-smtpout-1.server.virginmedia.net ([62.254.123.2])
	by mtaout02-winn.ispmail.ntl.com
	(InterMail vM.7.08.04.00 201-2186-134-20080326) with ESMTP id
	<20120930161347.MMWZ1732.mtaout02-winn.ispmail.ntl.com@know-smtpout-1.server.virginmedia.net>
	for <xen-devel@lists.xen.org>; Sun, 30 Sep 2012 17:13:47 +0100
Received: from [82.32.104.97] (helo=dingwall.me.uk)
	by know-smtpout-1.server.virginmedia.net with esmtp (Exim 4.63)
	(envelope-from <james@dingwall.me.uk>) id 1TIM9K-000854-Ho
	for xen-devel@lists.xen.org; Sun, 30 Sep 2012 17:13:46 +0100
Received: (qmail 15873 invoked from network); 30 Sep 2012 16:13:46 -0000
Received: from behemoth.dingwall.me.uk (192.168.1.5)
	by mail0.xen.dingwall.me.uk with SMTP; 30 Sep 2012 16:13:46 -0000
Received: by behemoth.dingwall.me.uk (Postfix, from userid 1000)
	id 367EDD08C20; Sun, 30 Sep 2012 17:13:46 +0100 (BST)
Date: Sun, 30 Sep 2012 17:13:45 +0100
From: James Dingwall <james@dingwall.me.uk>
To: xen-devel@lists.xen.org
Message-ID: <20120930161345.GA31109@dingwall.me.uk>
MIME-Version: 1.0
Content-Disposition: inline
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Cloudmark-Analysis: v=1.1 cv=GaEGOwq9FwezmTggA+b6yC6zDZF2HYaK6RN/tSqdnVA=
	c=1 sm=0 a=wom5GMh1gUkA:10 a=OWi5QT2UpnQA:10 a=kj9zAlcOel0A:10
	a=CFJKkHzFcQURHE0lyYgA:9 a=CjuIK1q_8ugA:10
	a=HpAAvcLHHh0Zw7uRqdWCyQ==:117
X-Mailman-Approved-At: Sun, 30 Sep 2012 20:01:29 +0000
Subject: [Xen-devel] [james-xen@dingwall.me.uk: [Xen-users] Xen 4.2.0 - CPU
 Frequency Scaling]
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: 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 didn't get any response on xen-users for this issue but so I'm hoping 
-devel can help.

I have had problems using cpu frequency scaling since the 
xen-acpi-processor code was added to the mainline kernel source.  I 
wasn't sure if the problem I was seeing was related to the old version 
(4.1.2) of Xen that I was using but now I'm on 4.2.0 and it still exists 
I thought I would check if I have a misconfiguration or if I have 
discovered a problem.  My system is a dual AMD Opteron(tm) Processor 
2423 HE on kernel 3.4.8.

The xen command line is:
 console=vga,com2 com2=115200,8n1 dom0_mem=max:2048M dom0_max_vcpus=2
dom0_vcpus_pin

The CPU scaling information reported by xenpm is below.  The problem
is that only cpuid 1 can be managed separately, all the others are
bundled together and cannot be handled independently which used to be
possible with the old xen kernel.  If further information would be
useful please let me know.

Thanks,
James

# xenpm get-cpufreq-para
cpu id               : 0
affected_cpus        : 0 2 3 4 5 6 7 8 9 10 11
cpuinfo frequency    : max [2000000] min [800000] cur [800000]
scaling_driver       :
scaling_avail_gov    : userspace performance powersave ondemand
current_governor     : ondemand
  ondemand specific  :
    sampling_rate    : max [10000000] min [10000] cur [20000]
    up_threshold     : 80
scaling_avail_freq   : 2000000 1500000 1300000 1000000 *800000
scaling frequency    : max [2000000] min [800000] cur [800000]

cpu id               : 1
affected_cpus        : 1
cpuinfo frequency    : max [2000000] min [800000] cur [800000]
scaling_driver       :
scaling_avail_gov    : userspace performance powersave ondemand
current_governor     : ondemand
  ondemand specific  :
    sampling_rate    : max [10000000] min [10000] cur [20000]
    up_threshold     : 80
scaling_avail_freq   : 2000000 1500000 1300000 1000000 *800000
scaling frequency    : max [2000000] min [800000] cur [800000]

cpu id               : 2
affected_cpus        : 0 2 3 4 5 6 7 8 9 10 11
cpuinfo frequency    : max [2000000] min [800000] cur [800000]
scaling_driver       :
scaling_avail_gov    : userspace performance powersave ondemand
current_governor     : ondemand
  ondemand specific  :
    sampling_rate    : max [10000000] min [10000] cur [20000]
    up_threshold     : 80
scaling_avail_freq   : 2000000 1500000 1300000 1000000 *800000
scaling frequency    : max [2000000] min [800000] cur [800000]

cpu id               : 3
affected_cpus        : 0 2 3 4 5 6 7 8 9 10 11
cpuinfo frequency    : max [2000000] min [800000] cur [800000]
scaling_driver       :
scaling_avail_gov    : userspace performance powersave ondemand
current_governor     : ondemand
  ondemand specific  :
    sampling_rate    : max [10000000] min [10000] cur [20000]
    up_threshold     : 80
scaling_avail_freq   : 2000000 1500000 1300000 1000000 *800000
scaling frequency    : max [2000000] min [800000] cur [800000]

cpu id               : 4
affected_cpus        : 0 2 3 4 5 6 7 8 9 10 11
cpuinfo frequency    : max [2000000] min [800000] cur [800000]
scaling_driver       :
scaling_avail_gov    : userspace performance powersave ondemand
current_governor     : ondemand
  ondemand specific  :
    sampling_rate    : max [10000000] min [10000] cur [20000]
    up_threshold     : 80
scaling_avail_freq   : 2000000 1500000 1300000 1000000 *800000
scaling frequency    : max [2000000] min [800000] cur [800000]

cpu id               : 5
affected_cpus        : 0 2 3 4 5 6 7 8 9 10 11
cpuinfo frequency    : max [2000000] min [800000] cur [800000]
scaling_driver       :
scaling_avail_gov    : userspace performance powersave ondemand
current_governor     : ondemand
  ondemand specific  :
    sampling_rate    : max [10000000] min [10000] cur [20000]
    up_threshold     : 80
scaling_avail_freq   : 2000000 1500000 1300000 1000000 *800000
scaling frequency    : max [2000000] min [800000] cur [800000]

cpu id               : 6
affected_cpus        : 0 2 3 4 5 6 7 8 9 10 11
cpuinfo frequency    : max [2000000] min [800000] cur [800000]
scaling_driver       :
scaling_avail_gov    : userspace performance powersave ondemand
current_governor     : ondemand
  ondemand specific  :
    sampling_rate    : max [10000000] min [10000] cur [20000]
    up_threshold     : 80
scaling_avail_freq   : 2000000 1500000 1300000 1000000 *800000
scaling frequency    : max [2000000] min [800000] cur [800000]

cpu id               : 7
affected_cpus        : 0 2 3 4 5 6 7 8 9 10 11
cpuinfo frequency    : max [2000000] min [800000] cur [800000]
scaling_driver       :
scaling_avail_gov    : userspace performance powersave ondemand
current_governor     : ondemand
  ondemand specific  :
    sampling_rate    : max [10000000] min [10000] cur [20000]
    up_threshold     : 80
scaling_avail_freq   : 2000000 1500000 1300000 1000000 *800000
scaling frequency    : max [2000000] min [800000] cur [800000]

cpu id               : 8
affected_cpus        : 0 2 3 4 5 6 7 8 9 10 11
cpuinfo frequency    : max [2000000] min [800000] cur [800000]
scaling_driver       :
scaling_avail_gov    : userspace performance powersave ondemand
current_governor     : ondemand
  ondemand specific  :
    sampling_rate    : max [10000000] min [10000] cur [20000]
    up_threshold     : 80
scaling_avail_freq   : 2000000 1500000 1300000 1000000 *800000
scaling frequency    : max [2000000] min [800000] cur [800000]

cpu id               : 9
affected_cpus        : 0 2 3 4 5 6 7 8 9 10 11
cpuinfo frequency    : max [2000000] min [800000] cur [800000]
scaling_driver       :
scaling_avail_gov    : userspace performance powersave ondemand
current_governor     : ondemand
  ondemand specific  :
    sampling_rate    : max [10000000] min [10000] cur [20000]
    up_threshold     : 80
scaling_avail_freq   : 2000000 1500000 1300000 1000000 *800000
scaling frequency    : max [2000000] min [800000] cur [800000]

cpu id               : 10
affected_cpus        : 0 2 3 4 5 6 7 8 9 10 11
cpuinfo frequency    : max [2000000] min [800000] cur [800000]
scaling_driver       :
scaling_avail_gov    : userspace performance powersave ondemand
current_governor     : ondemand
  ondemand specific  :
    sampling_rate    : max [10000000] min [10000] cur [20000]
    up_threshold     : 80
scaling_avail_freq   : 2000000 1500000 1300000 1000000 *800000
scaling frequency    : max [2000000] min [800000] cur [800000]

cpu id               : 11
affected_cpus        : 0 2 3 4 5 6 7 8 9 10 11
cpuinfo frequency    : max [2000000] min [800000] cur [800000]
scaling_driver       :
scaling_avail_gov    : userspace performance powersave ondemand
current_governor     : ondemand
  ondemand specific  :
    sampling_rate    : max [10000000] min [10000] cur [20000]
    up_threshold     : 80
scaling_avail_freq   : 2000000 1500000 1300000 1000000 *800000
scaling frequency    : max [2000000] min [800000] cur [800000]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

From xen-devel-bounces@lists.xen.org Sun Sep 30 20:18:33 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 30 Sep 2012 20:18:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TIPxn-0003Nb-O1; Sun, 30 Sep 2012 20:18:07 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <kiviniemi.valtteri@gmail.com>) id 1TIPxm-0003NG-OK
	for Xen-devel@lists.xen.org; Sun, 30 Sep 2012 20:18:07 +0000
Received: from [85.158.138.51:53414] by server-9.bemta-3.messagelabs.com id
	CB/68-20338-DF8A8605; Sun, 30 Sep 2012 20:18:05 +0000
X-Env-Sender: kiviniemi.valtteri@gmail.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1349036283!32484568!1
X-Originating-IP: [209.85.160.173]
X-SpamReason: No, hits=1.7 required=7.0 tests=BODY_RANDOM_LONG,
	HTML_20_30, HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14, RCVD_BY_IP,
	spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3231 invoked from network); 30 Sep 2012 20:18:04 -0000
Received: from mail-gh0-f173.google.com (HELO mail-gh0-f173.google.com)
	(209.85.160.173)
	by server-2.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Sep 2012 20:18:04 -0000
Received: by ghy16 with SMTP id 16so1423051ghy.32
	for <Xen-devel@lists.xen.org>; Sun, 30 Sep 2012 13:18:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:date:message-id:subject:from:to:content-type;
	bh=YTwTrFTUoNHuZv87/K5Wt43o+T+CehBtQrYViHM+Jq4=;
	b=I5eMiynzeYRxAD/Hx2cW0DyJLN6CgefsNM0ey9JlN4gVTquU6YVwPLnlWIXLApfTRb
	tqA67hH5E06NXI7U5Aqn/Il10/ORbUvMIU09NbxAM3B89cM4i4b5z/uHXcgZ5u8zz3XH
	2nC+Y8Jkg2Ywms7rkAWErxkhSHs77mxeot/B4pmUC49EC46DdMt285OtbeQsmA8O3Zks
	oei2IomjmkH6t+zq/c42c/eIK2OoyfN5G0mxKkaEu6NED3QIRyCvhGu4OtHOk68tYLMk
	3b+j6zxxN76s9fQLyEmEqHQ6cUfqVapDpwWgYjHL5AZrnhoSP9l7ny6qKspRns2v5CAx
	frJA==
MIME-Version: 1.0
Received: by 10.101.141.40 with SMTP id t40mr4123636ann.77.1349036283360; Sun,
	30 Sep 2012 13:18:03 -0700 (PDT)
Received: by 10.147.129.8 with HTTP; Sun, 30 Sep 2012 13:18:03 -0700 (PDT)
Date: Sun, 30 Sep 2012 23:18:03 +0300
Message-ID: <CAN=sCCFuDywL6h8mESz5iN+UBYp9sW7YvGCB0LpYJQWQM+2fHg@mail.gmail.com>
From: Valtteri Kiviniemi <kiviniemi.valtteri@gmail.com>
To: Xen-devel@lists.xen.org
Subject: [Xen-devel] Xen 4.0.4, kernel 3.5.0 HVM crash and kernel BUG
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============4802443310422188350=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============4802443310422188350==
Content-Type: multipart/alternative; boundary=0016e6d27c7d75758b04caf0fc5f

--0016e6d27c7d75758b04caf0fc5f
Content-Type: text/plain; charset=ISO-8859-1

Hi,

I'm trying to get Windows Server 2008 R2 installation booting on Xen 4.0.4.
Using the following config:

kernel = "/usr/lib/xen/boot/hvmloader"
builder = "hvm"
shadow_memory = "8"
memory = "4096"
name = "ts"
vcpus = "8"
cpus = ["0", "1", "2", "3", "4", "5", "6", "7"]
pae = "1"
acpi = "1"
apic = "1"
vfb = [ 'type=vnc, vnclisten=10.100.100.1, vncpasswd=xxxx' ]
xen_extended_power_mgmt = "0"
vif = [ "type=ioemu, mac=00:16:3e:d7:d7:5d, bridge=xenbr0" ]
disk = [ "phy:/dev/virtuals/ts,hda,w",
"file:/media/iso/windows_server_2008_r2_sp1.iso,hdc:cdrom,r" ]
on_poweroff = "destroy"
on_reboot = "restart"
on_crash = "restart"
viridian = "1"
device_model = "/usr/lib/xen/bin/qemu-dm"
boot = "dc"
snapshot = "0"
vncconsole = "1"
sdl = "0"
opengl = "0"
vnc = "1"
nographic = "0"
stdvga = "0"
tsc_mode = "1"
monitor = "0"
localtime = "1"
usb = "0"
keymap = "fi"
xen_platform_pci = "1"
pci_msitranslate = "1"
pci_power_mgmt = "0"

The domU will start booting just fine, but after a few minutes the VNC
screen goes black. After that when typing "xm destroy ts" it will trigger a
kernel BUG:

BUG: unable to handle kernel NULL pointer dereference at 0000000000000030
IP: [<ffffffff810c50c4>] iput+0x3e/0x195
PGD 0
Oops: 0000 [#1] SMP
CPU 6
Pid: 3571, comm: qemu-dm Not tainted 3.5.0-dom0 #1                  /DQ77MK
RIP: e030:[<ffffffff810c50c4>]  [<ffffffff810c50c4>] iput+0x3e/0x195
RSP: e02b:ffff8800389ffbf8  EFLAGS: 00010246
RAX: 0000000000000001 RBX: ffff8800377b0720 RCX: ffff8800501c0000
RDX: ffff8800501c0000 RSI: ffff8800377b0790 RDI: ffff8800377b0790
RBP: 0000000000000000 R08: ffffffff815cdd00 R09: 0000000000000016
R10: fefefefefefefeff R11: ffff8800377b0400 R12: 00000001000a3e0c
R13: 0000000000000000 R14: 00000001000a3e0c R15: ffff8800389ffc28
FS:  00007f1af70a8700(0000) GS:ffff880050180000(0000) knlGS:0000000000000000
CS:  e033 DS: 0000 ES: 0000 CR0: 000000008005003b
CR2: 0000000000000030 CR3: 000000000156d000 CR4: 0000000000002660
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process qemu-dm (pid: 3571, threadinfo ffff8800389fe000, task
ffff88003a721260)
Stack:
 ffff88003a6d6400 ffff8800377b0000 00000001000a3e0c ffffffff8133ce8f
 ffff8800377b0400 ffffffff8134b6cd ffff8800389ffc28 ffff8800389ffc28
 ffff8800377b00f8 ffff8800377b0680 ffff880038cdcd60 ffff8800377b0000
Call Trace:
 [<ffffffff8133ce8f>] ? sk_release_kernel+0x23/0x39
 [<ffffffff8134b6cd>] ? netdev_run_todo+0x1e9/0x206
 [<ffffffff8129798f>] ? tun_chr_close+0x4c/0x7b
 [<ffffffff810b39d3>] ? fput+0xe4/0x1c5
 [<ffffffff810b202c>] ? filp_close+0x61/0x68
 [<ffffffff81035e62>] ? put_files_struct+0x62/0xb9
 [<ffffffff81036374>] ? do_exit+0x24a/0x74c
 [<ffffffff81036906>] ? do_group_exit+0x6b/0x9d
 [<ffffffff8103ea0b>] ? get_signal_to_deliver+0x449/0x46e
 [<ffffffff81009fa5>] ? do_signal+0x28/0x4c4
 [<ffffffff81027079>] ? pvclock_clocksource_read+0x48/0xbf
 [<ffffffff8105b745>] ? ktime_get_ts+0x66/0xa8
 [<ffffffff810bfb18>] ? poll_select_copy_remaining+0xe0/0xf5
 [<ffffffff8100a48d>] ? do_notify_resume+0x3b/0x74
 [<ffffffff81411a70>] ? int_signal+0x12/0x17
Code: 00 00 00 40 74 02 0f 0b 48 8d 77 70 48 8d bf 08 01 00 00 e8 8b 71 10
00 85 c0 0f 84 5d 01 00 00 48 8b 6b 18 f6 83 80 00 00 00 08 <4c> 8b 65 30
74 11 be 68 05 00 00 48 c7 c7 8e df 4f 81 e8 bb d0
RIP  [<ffffffff810c50c4>] iput+0x3e/0x195
 RSP <ffff8800389ffbf8>
CR2: 0000000000000030
---[ end trace 67cc1654658fedcc ]---
Fixing recursive fault but reboot is needed!

I also tested Xen 4.2.0 and problem is the same. So is this a Xen bug or a
kernel bug? I am running vanilla kernel.org kernel 3.5.0 and my hardware is
Intel Core i7-3770 CPU and Intel DQ77MK motherboard with latest bios.

Best regards,
Valtteri Kiviniemi

--0016e6d27c7d75758b04caf0fc5f
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi,<br><br>I&#39;m trying to get Windows Server 2008 R2 installation bootin=
g on Xen 4.0.4. Using the following config:<br><br>kernel =3D &quot;/usr/li=
b/xen/boot/hvmloader&quot;<br>builder =3D &quot;hvm&quot;<br>shadow_memory =
=3D &quot;8&quot;<br>
memory =3D &quot;4096&quot;<br>name =3D &quot;ts&quot;<br>vcpus =3D &quot;8=
&quot;<br>cpus =3D [&quot;0&quot;, &quot;1&quot;, &quot;2&quot;, &quot;3&qu=
ot;, &quot;4&quot;, &quot;5&quot;, &quot;6&quot;, &quot;7&quot;]<br>pae =3D=
 &quot;1&quot;<br>
acpi =3D &quot;1&quot;<br>apic =3D &quot;1&quot;<br>vfb =3D [ &#39;type=3Dv=
nc, vnclisten=3D10.100.100.1, vncpasswd=3Dxxxx&#39; ]<br>xen_extended_power=
_mgmt =3D &quot;0&quot;<br>vif =3D [ &quot;type=3Dioemu, mac=3D00:16:3e:d7:=
d7:5d, bridge=3Dxenbr0&quot; ]<br>
disk =3D [ &quot;phy:/dev/virtuals/ts,hda,w&quot;, &quot;file:/media/iso/wi=
ndows_server_2008_r2_sp1.iso,hdc:cdrom,r&quot; ]<br>on_poweroff =3D &quot;d=
estroy&quot;<br>on_reboot =3D &quot;restart&quot;<br>on_crash =3D &quot;res=
tart&quot;<br>
viridian =3D &quot;1&quot;<br>device_model =3D &quot;/usr/lib/xen/bin/qemu-=
dm&quot;<br>boot =3D &quot;dc&quot;<br>snapshot =3D &quot;0&quot;<br>vnccon=
sole =3D &quot;1&quot;<br>sdl =3D &quot;0&quot;<br>opengl =3D &quot;0&quot;=
<br>vnc =3D &quot;1&quot;<br>
nographic =3D &quot;0&quot;<br>stdvga =3D &quot;0&quot;<br>tsc_mode =3D &qu=
ot;1&quot;<br>monitor =3D &quot;0&quot;<br>localtime =3D &quot;1&quot;<br>u=
sb =3D &quot;0&quot;<br>keymap =3D &quot;fi&quot;<br>xen_platform_pci =3D &=
quot;1&quot;<br>
pci_msitranslate =3D &quot;1&quot;<br>pci_power_mgmt =3D &quot;0&quot;<br><=
br>The domU will start booting just fine, but after a few minutes the VNC s=
creen goes black. After that when typing &quot;xm destroy ts&quot; it will =
trigger a kernel BUG:<br>
<br>BUG: unable to handle kernel NULL pointer dereference at 00000000000000=
30<br>IP: [&lt;ffffffff810c50c4&gt;] iput+0x3e/0x195<br>PGD 0<br>Oops: 0000=
 [#1] SMP<br>CPU 6<br>Pid: 3571, comm: qemu-dm Not tainted 3.5.0-dom0 #1=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 /DQ77MK<br>
RIP: e030:[&lt;ffffffff810c50c4&gt;]=A0 [&lt;ffffffff810c50c4&gt;] iput+0x3=
e/0x195<br>RSP: e02b:ffff8800389ffbf8=A0 EFLAGS: 00010246<br>RAX: 000000000=
0000001 RBX: ffff8800377b0720 RCX: ffff8800501c0000<br>RDX: ffff8800501c000=
0 RSI: ffff8800377b0790 RDI: ffff8800377b0790<br>
RBP: 0000000000000000 R08: ffffffff815cdd00 R09: 0000000000000016<br>R10: f=
efefefefefefeff R11: ffff8800377b0400 R12: 00000001000a3e0c<br>R13: 0000000=
000000000 R14: 00000001000a3e0c R15: ffff8800389ffc28<br>FS:=A0 00007f1af70=
a8700(0000) GS:ffff880050180000(0000) knlGS:0000000000000000<br>
CS:=A0 e033 DS: 0000 ES: 0000 CR0: 000000008005003b<br>CR2: 000000000000003=
0 CR3: 000000000156d000 CR4: 0000000000002660<br>DR0: 0000000000000000 DR1:=
 0000000000000000 DR2: 0000000000000000<br>DR3: 0000000000000000 DR6: 00000=
000ffff0ff0 DR7: 0000000000000400<br>
Process qemu-dm (pid: 3571, threadinfo ffff8800389fe000, task ffff88003a721=
260)<br>Stack:<br>=A0ffff88003a6d6400 ffff8800377b0000 00000001000a3e0c fff=
fffff8133ce8f<br>=A0ffff8800377b0400 ffffffff8134b6cd ffff8800389ffc28 ffff=
8800389ffc28<br>
=A0ffff8800377b00f8 ffff8800377b0680 ffff880038cdcd60 ffff8800377b0000<br>C=
all Trace:<br>=A0[&lt;ffffffff8133ce8f&gt;] ? sk_release_kernel+0x23/0x39<b=
r>=A0[&lt;ffffffff8134b6cd&gt;] ? netdev_run_todo+0x1e9/0x206<br>=A0[&lt;ff=
ffffff8129798f&gt;] ? tun_chr_close+0x4c/0x7b<br>
=A0[&lt;ffffffff810b39d3&gt;] ? fput+0xe4/0x1c5<br>=A0[&lt;ffffffff810b202c=
&gt;] ? filp_close+0x61/0x68<br>=A0[&lt;ffffffff81035e62&gt;] ? put_files_s=
truct+0x62/0xb9<br>=A0[&lt;ffffffff81036374&gt;] ? do_exit+0x24a/0x74c<br>=
=A0[&lt;ffffffff81036906&gt;] ? do_group_exit+0x6b/0x9d<br>
=A0[&lt;ffffffff8103ea0b&gt;] ? get_signal_to_deliver+0x449/0x46e<br>=A0[&l=
t;ffffffff81009fa5&gt;] ? do_signal+0x28/0x4c4<br>=A0[&lt;ffffffff81027079&=
gt;] ? pvclock_clocksource_read+0x48/0xbf<br>=A0[&lt;ffffffff8105b745&gt;] =
? ktime_get_ts+0x66/0xa8<br>
=A0[&lt;ffffffff810bfb18&gt;] ? poll_select_copy_remaining+0xe0/0xf5<br>=A0=
[&lt;ffffffff8100a48d&gt;] ? do_notify_resume+0x3b/0x74<br>=A0[&lt;ffffffff=
81411a70&gt;] ? int_signal+0x12/0x17<br>Code: 00 00 00 40 74 02 0f 0b 48 8d=
 77 70 48 8d bf 08 01 00 00 e8 8b 71 10 00 85 c0 0f 84 5d 01 00 00 48 8b 6b=
 18 f6 83 80 00 00 00 08 &lt;4c&gt; 8b 65 30 74 11 be 68 05 00 00 48 c7 c7 =
8e df 4f 81 e8 bb d0<br>
RIP=A0 [&lt;ffffffff810c50c4&gt;] iput+0x3e/0x195<br>=A0RSP &lt;ffff8800389=
ffbf8&gt;<br>CR2: 0000000000000030<br>---[ end trace 67cc1654658fedcc ]---<=
br>Fixing recursive fault but reboot is needed!<br><br>I also tested Xen 4.=
2.0 and problem is the same. So is this a Xen bug or a kernel bug? I am run=
ning vanilla <a href=3D"http://kernel.org">kernel.org</a> kernel 3.5.0 and =
my hardware is Intel Core i7-3770 CPU and Intel DQ77MK motherboard with lat=
est bios.<br>
<br>Best regards,<br>Valtteri Kiviniemi<br>

--0016e6d27c7d75758b04caf0fc5f--


--===============4802443310422188350==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============4802443310422188350==--


From xen-devel-bounces@lists.xen.org Sun Sep 30 20:18:33 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 30 Sep 2012 20:18:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TIPxn-0003Nb-O1; Sun, 30 Sep 2012 20:18:07 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <kiviniemi.valtteri@gmail.com>) id 1TIPxm-0003NG-OK
	for Xen-devel@lists.xen.org; Sun, 30 Sep 2012 20:18:07 +0000
Received: from [85.158.138.51:53414] by server-9.bemta-3.messagelabs.com id
	CB/68-20338-DF8A8605; Sun, 30 Sep 2012 20:18:05 +0000
X-Env-Sender: kiviniemi.valtteri@gmail.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1349036283!32484568!1
X-Originating-IP: [209.85.160.173]
X-SpamReason: No, hits=1.7 required=7.0 tests=BODY_RANDOM_LONG,
	HTML_20_30, HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14, RCVD_BY_IP,
	spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3231 invoked from network); 30 Sep 2012 20:18:04 -0000
Received: from mail-gh0-f173.google.com (HELO mail-gh0-f173.google.com)
	(209.85.160.173)
	by server-2.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Sep 2012 20:18:04 -0000
Received: by ghy16 with SMTP id 16so1423051ghy.32
	for <Xen-devel@lists.xen.org>; Sun, 30 Sep 2012 13:18:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:date:message-id:subject:from:to:content-type;
	bh=YTwTrFTUoNHuZv87/K5Wt43o+T+CehBtQrYViHM+Jq4=;
	b=I5eMiynzeYRxAD/Hx2cW0DyJLN6CgefsNM0ey9JlN4gVTquU6YVwPLnlWIXLApfTRb
	tqA67hH5E06NXI7U5Aqn/Il10/ORbUvMIU09NbxAM3B89cM4i4b5z/uHXcgZ5u8zz3XH
	2nC+Y8Jkg2Ywms7rkAWErxkhSHs77mxeot/B4pmUC49EC46DdMt285OtbeQsmA8O3Zks
	oei2IomjmkH6t+zq/c42c/eIK2OoyfN5G0mxKkaEu6NED3QIRyCvhGu4OtHOk68tYLMk
	3b+j6zxxN76s9fQLyEmEqHQ6cUfqVapDpwWgYjHL5AZrnhoSP9l7ny6qKspRns2v5CAx
	frJA==
MIME-Version: 1.0
Received: by 10.101.141.40 with SMTP id t40mr4123636ann.77.1349036283360; Sun,
	30 Sep 2012 13:18:03 -0700 (PDT)
Received: by 10.147.129.8 with HTTP; Sun, 30 Sep 2012 13:18:03 -0700 (PDT)
Date: Sun, 30 Sep 2012 23:18:03 +0300
Message-ID: <CAN=sCCFuDywL6h8mESz5iN+UBYp9sW7YvGCB0LpYJQWQM+2fHg@mail.gmail.com>
From: Valtteri Kiviniemi <kiviniemi.valtteri@gmail.com>
To: Xen-devel@lists.xen.org
Subject: [Xen-devel] Xen 4.0.4, kernel 3.5.0 HVM crash and kernel BUG
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============4802443310422188350=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============4802443310422188350==
Content-Type: multipart/alternative; boundary=0016e6d27c7d75758b04caf0fc5f

--0016e6d27c7d75758b04caf0fc5f
Content-Type: text/plain; charset=ISO-8859-1

Hi,

I'm trying to get Windows Server 2008 R2 installation booting on Xen 4.0.4.
Using the following config:

kernel = "/usr/lib/xen/boot/hvmloader"
builder = "hvm"
shadow_memory = "8"
memory = "4096"
name = "ts"
vcpus = "8"
cpus = ["0", "1", "2", "3", "4", "5", "6", "7"]
pae = "1"
acpi = "1"
apic = "1"
vfb = [ 'type=vnc, vnclisten=10.100.100.1, vncpasswd=xxxx' ]
xen_extended_power_mgmt = "0"
vif = [ "type=ioemu, mac=00:16:3e:d7:d7:5d, bridge=xenbr0" ]
disk = [ "phy:/dev/virtuals/ts,hda,w",
"file:/media/iso/windows_server_2008_r2_sp1.iso,hdc:cdrom,r" ]
on_poweroff = "destroy"
on_reboot = "restart"
on_crash = "restart"
viridian = "1"
device_model = "/usr/lib/xen/bin/qemu-dm"
boot = "dc"
snapshot = "0"
vncconsole = "1"
sdl = "0"
opengl = "0"
vnc = "1"
nographic = "0"
stdvga = "0"
tsc_mode = "1"
monitor = "0"
localtime = "1"
usb = "0"
keymap = "fi"
xen_platform_pci = "1"
pci_msitranslate = "1"
pci_power_mgmt = "0"

The domU will start booting just fine, but after a few minutes the VNC
screen goes black. After that when typing "xm destroy ts" it will trigger a
kernel BUG:

BUG: unable to handle kernel NULL pointer dereference at 0000000000000030
IP: [<ffffffff810c50c4>] iput+0x3e/0x195
PGD 0
Oops: 0000 [#1] SMP
CPU 6
Pid: 3571, comm: qemu-dm Not tainted 3.5.0-dom0 #1                  /DQ77MK
RIP: e030:[<ffffffff810c50c4>]  [<ffffffff810c50c4>] iput+0x3e/0x195
RSP: e02b:ffff8800389ffbf8  EFLAGS: 00010246
RAX: 0000000000000001 RBX: ffff8800377b0720 RCX: ffff8800501c0000
RDX: ffff8800501c0000 RSI: ffff8800377b0790 RDI: ffff8800377b0790
RBP: 0000000000000000 R08: ffffffff815cdd00 R09: 0000000000000016
R10: fefefefefefefeff R11: ffff8800377b0400 R12: 00000001000a3e0c
R13: 0000000000000000 R14: 00000001000a3e0c R15: ffff8800389ffc28
FS:  00007f1af70a8700(0000) GS:ffff880050180000(0000) knlGS:0000000000000000
CS:  e033 DS: 0000 ES: 0000 CR0: 000000008005003b
CR2: 0000000000000030 CR3: 000000000156d000 CR4: 0000000000002660
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process qemu-dm (pid: 3571, threadinfo ffff8800389fe000, task
ffff88003a721260)
Stack:
 ffff88003a6d6400 ffff8800377b0000 00000001000a3e0c ffffffff8133ce8f
 ffff8800377b0400 ffffffff8134b6cd ffff8800389ffc28 ffff8800389ffc28
 ffff8800377b00f8 ffff8800377b0680 ffff880038cdcd60 ffff8800377b0000
Call Trace:
 [<ffffffff8133ce8f>] ? sk_release_kernel+0x23/0x39
 [<ffffffff8134b6cd>] ? netdev_run_todo+0x1e9/0x206
 [<ffffffff8129798f>] ? tun_chr_close+0x4c/0x7b
 [<ffffffff810b39d3>] ? fput+0xe4/0x1c5
 [<ffffffff810b202c>] ? filp_close+0x61/0x68
 [<ffffffff81035e62>] ? put_files_struct+0x62/0xb9
 [<ffffffff81036374>] ? do_exit+0x24a/0x74c
 [<ffffffff81036906>] ? do_group_exit+0x6b/0x9d
 [<ffffffff8103ea0b>] ? get_signal_to_deliver+0x449/0x46e
 [<ffffffff81009fa5>] ? do_signal+0x28/0x4c4
 [<ffffffff81027079>] ? pvclock_clocksource_read+0x48/0xbf
 [<ffffffff8105b745>] ? ktime_get_ts+0x66/0xa8
 [<ffffffff810bfb18>] ? poll_select_copy_remaining+0xe0/0xf5
 [<ffffffff8100a48d>] ? do_notify_resume+0x3b/0x74
 [<ffffffff81411a70>] ? int_signal+0x12/0x17
Code: 00 00 00 40 74 02 0f 0b 48 8d 77 70 48 8d bf 08 01 00 00 e8 8b 71 10
00 85 c0 0f 84 5d 01 00 00 48 8b 6b 18 f6 83 80 00 00 00 08 <4c> 8b 65 30
74 11 be 68 05 00 00 48 c7 c7 8e df 4f 81 e8 bb d0
RIP  [<ffffffff810c50c4>] iput+0x3e/0x195
 RSP <ffff8800389ffbf8>
CR2: 0000000000000030
---[ end trace 67cc1654658fedcc ]---
Fixing recursive fault but reboot is needed!

I also tested Xen 4.2.0 and problem is the same. So is this a Xen bug or a
kernel bug? I am running vanilla kernel.org kernel 3.5.0 and my hardware is
Intel Core i7-3770 CPU and Intel DQ77MK motherboard with latest bios.

Best regards,
Valtteri Kiviniemi

--0016e6d27c7d75758b04caf0fc5f
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi,<br><br>I&#39;m trying to get Windows Server 2008 R2 installation bootin=
g on Xen 4.0.4. Using the following config:<br><br>kernel =3D &quot;/usr/li=
b/xen/boot/hvmloader&quot;<br>builder =3D &quot;hvm&quot;<br>shadow_memory =
=3D &quot;8&quot;<br>
memory =3D &quot;4096&quot;<br>name =3D &quot;ts&quot;<br>vcpus =3D &quot;8=
&quot;<br>cpus =3D [&quot;0&quot;, &quot;1&quot;, &quot;2&quot;, &quot;3&qu=
ot;, &quot;4&quot;, &quot;5&quot;, &quot;6&quot;, &quot;7&quot;]<br>pae =3D=
 &quot;1&quot;<br>
acpi =3D &quot;1&quot;<br>apic =3D &quot;1&quot;<br>vfb =3D [ &#39;type=3Dv=
nc, vnclisten=3D10.100.100.1, vncpasswd=3Dxxxx&#39; ]<br>xen_extended_power=
_mgmt =3D &quot;0&quot;<br>vif =3D [ &quot;type=3Dioemu, mac=3D00:16:3e:d7:=
d7:5d, bridge=3Dxenbr0&quot; ]<br>
disk =3D [ &quot;phy:/dev/virtuals/ts,hda,w&quot;, &quot;file:/media/iso/wi=
ndows_server_2008_r2_sp1.iso,hdc:cdrom,r&quot; ]<br>on_poweroff =3D &quot;d=
estroy&quot;<br>on_reboot =3D &quot;restart&quot;<br>on_crash =3D &quot;res=
tart&quot;<br>
viridian =3D &quot;1&quot;<br>device_model =3D &quot;/usr/lib/xen/bin/qemu-=
dm&quot;<br>boot =3D &quot;dc&quot;<br>snapshot =3D &quot;0&quot;<br>vnccon=
sole =3D &quot;1&quot;<br>sdl =3D &quot;0&quot;<br>opengl =3D &quot;0&quot;=
<br>vnc =3D &quot;1&quot;<br>
nographic =3D &quot;0&quot;<br>stdvga =3D &quot;0&quot;<br>tsc_mode =3D &qu=
ot;1&quot;<br>monitor =3D &quot;0&quot;<br>localtime =3D &quot;1&quot;<br>u=
sb =3D &quot;0&quot;<br>keymap =3D &quot;fi&quot;<br>xen_platform_pci =3D &=
quot;1&quot;<br>
pci_msitranslate =3D &quot;1&quot;<br>pci_power_mgmt =3D &quot;0&quot;<br><=
br>The domU will start booting just fine, but after a few minutes the VNC s=
creen goes black. After that when typing &quot;xm destroy ts&quot; it will =
trigger a kernel BUG:<br>
<br>BUG: unable to handle kernel NULL pointer dereference at 00000000000000=
30<br>IP: [&lt;ffffffff810c50c4&gt;] iput+0x3e/0x195<br>PGD 0<br>Oops: 0000=
 [#1] SMP<br>CPU 6<br>Pid: 3571, comm: qemu-dm Not tainted 3.5.0-dom0 #1=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 /DQ77MK<br>
RIP: e030:[&lt;ffffffff810c50c4&gt;]=A0 [&lt;ffffffff810c50c4&gt;] iput+0x3=
e/0x195<br>RSP: e02b:ffff8800389ffbf8=A0 EFLAGS: 00010246<br>RAX: 000000000=
0000001 RBX: ffff8800377b0720 RCX: ffff8800501c0000<br>RDX: ffff8800501c000=
0 RSI: ffff8800377b0790 RDI: ffff8800377b0790<br>
RBP: 0000000000000000 R08: ffffffff815cdd00 R09: 0000000000000016<br>R10: f=
efefefefefefeff R11: ffff8800377b0400 R12: 00000001000a3e0c<br>R13: 0000000=
000000000 R14: 00000001000a3e0c R15: ffff8800389ffc28<br>FS:=A0 00007f1af70=
a8700(0000) GS:ffff880050180000(0000) knlGS:0000000000000000<br>
CS:=A0 e033 DS: 0000 ES: 0000 CR0: 000000008005003b<br>CR2: 000000000000003=
0 CR3: 000000000156d000 CR4: 0000000000002660<br>DR0: 0000000000000000 DR1:=
 0000000000000000 DR2: 0000000000000000<br>DR3: 0000000000000000 DR6: 00000=
000ffff0ff0 DR7: 0000000000000400<br>
Process qemu-dm (pid: 3571, threadinfo ffff8800389fe000, task ffff88003a721=
260)<br>Stack:<br>=A0ffff88003a6d6400 ffff8800377b0000 00000001000a3e0c fff=
fffff8133ce8f<br>=A0ffff8800377b0400 ffffffff8134b6cd ffff8800389ffc28 ffff=
8800389ffc28<br>
=A0ffff8800377b00f8 ffff8800377b0680 ffff880038cdcd60 ffff8800377b0000<br>C=
all Trace:<br>=A0[&lt;ffffffff8133ce8f&gt;] ? sk_release_kernel+0x23/0x39<b=
r>=A0[&lt;ffffffff8134b6cd&gt;] ? netdev_run_todo+0x1e9/0x206<br>=A0[&lt;ff=
ffffff8129798f&gt;] ? tun_chr_close+0x4c/0x7b<br>
=A0[&lt;ffffffff810b39d3&gt;] ? fput+0xe4/0x1c5<br>=A0[&lt;ffffffff810b202c=
&gt;] ? filp_close+0x61/0x68<br>=A0[&lt;ffffffff81035e62&gt;] ? put_files_s=
truct+0x62/0xb9<br>=A0[&lt;ffffffff81036374&gt;] ? do_exit+0x24a/0x74c<br>=
=A0[&lt;ffffffff81036906&gt;] ? do_group_exit+0x6b/0x9d<br>
=A0[&lt;ffffffff8103ea0b&gt;] ? get_signal_to_deliver+0x449/0x46e<br>=A0[&l=
t;ffffffff81009fa5&gt;] ? do_signal+0x28/0x4c4<br>=A0[&lt;ffffffff81027079&=
gt;] ? pvclock_clocksource_read+0x48/0xbf<br>=A0[&lt;ffffffff8105b745&gt;] =
? ktime_get_ts+0x66/0xa8<br>
=A0[&lt;ffffffff810bfb18&gt;] ? poll_select_copy_remaining+0xe0/0xf5<br>=A0=
[&lt;ffffffff8100a48d&gt;] ? do_notify_resume+0x3b/0x74<br>=A0[&lt;ffffffff=
81411a70&gt;] ? int_signal+0x12/0x17<br>Code: 00 00 00 40 74 02 0f 0b 48 8d=
 77 70 48 8d bf 08 01 00 00 e8 8b 71 10 00 85 c0 0f 84 5d 01 00 00 48 8b 6b=
 18 f6 83 80 00 00 00 08 &lt;4c&gt; 8b 65 30 74 11 be 68 05 00 00 48 c7 c7 =
8e df 4f 81 e8 bb d0<br>
RIP=A0 [&lt;ffffffff810c50c4&gt;] iput+0x3e/0x195<br>=A0RSP &lt;ffff8800389=
ffbf8&gt;<br>CR2: 0000000000000030<br>---[ end trace 67cc1654658fedcc ]---<=
br>Fixing recursive fault but reboot is needed!<br><br>I also tested Xen 4.=
2.0 and problem is the same. So is this a Xen bug or a kernel bug? I am run=
ning vanilla <a href=3D"http://kernel.org">kernel.org</a> kernel 3.5.0 and =
my hardware is Intel Core i7-3770 CPU and Intel DQ77MK motherboard with lat=
est bios.<br>
<br>Best regards,<br>Valtteri Kiviniemi<br>

--0016e6d27c7d75758b04caf0fc5f--


--===============4802443310422188350==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============4802443310422188350==--


From xen-devel-bounces@lists.xen.org Sun Sep 30 21:16:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 30 Sep 2012 21:16:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TIQrX-0004nG-Gc; Sun, 30 Sep 2012 21:15:43 +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 1TIQrV-0004n2-E7
	for xen-devel@lists.xen.org; Sun, 30 Sep 2012 21:15:41 +0000
Received: from [85.158.138.51:23067] by server-1.bemta-3.messagelabs.com id
	81/58-16425-C76B8605; Sun, 30 Sep 2012 21:15:40 +0000
X-Env-Sender: ben.guthro@gmail.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1349039737!30848209!1
X-Originating-IP: [209.85.223.173]
X-SpamReason: No, hits=0.9 required=7.0 tests=HTML_40_50,HTML_MESSAGE,
	RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6282 invoked from network); 30 Sep 2012 21:15:38 -0000
Received: from mail-ie0-f173.google.com (HELO mail-ie0-f173.google.com)
	(209.85.223.173)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Sep 2012 21:15:38 -0000
Received: by iea17 with SMTP id 17so13879072iea.32
	for <xen-devel@lists.xen.org>; Sun, 30 Sep 2012 14:15: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=r4cCoyh+TJuw40uiyckxIU/CHboQysKqyL2YCVMbm7I=;
	b=d0fladPJDl99/yCc0dGBswAvnnxd1PyiziNe7CJvlVY65lTddEci4PWKdJSaWBZt6u
	Ga6C78R79PtPwO2D6Hb86k2byMfGSxgqWPkMf77VxSe8jJEvSfyII4YSB/lELIYAr5xh
	fscEoK79NUpgtUYwxa/M88qC1QkpFvfgQ9yGjuLrGWHPf+OAVzZDwaNmwLFdcaVV0KIz
	wWLECugmnqH66jRhHaDfdIjNjH+X3IR1M5bQTN+Ns4xlYGplGgvg0+HpG85yJzZdBodN
	geNqZ4dLEDQNpFt5T6Bm7+A6+WyCu8JNHaZEyMgx7kyYljG5ZZ3tcnvhHenwLlGonAwI
	j5HQ==
MIME-Version: 1.0
Received: by 10.50.236.72 with SMTP id us8mr3940342igc.70.1349039736705; Sun,
	30 Sep 2012 14:15:36 -0700 (PDT)
Received: by 10.64.55.132 with HTTP; Sun, 30 Sep 2012 14:15:36 -0700 (PDT)
In-Reply-To: <CC8C4B9E.40283%keir.xen@gmail.com>
References: <20120929050455.GA21253@u002268147cd4502c336d.ant.amazon.com>
	<CC8C4B9E.40283%keir.xen@gmail.com>
Date: Sun, 30 Sep 2012 17:15:36 -0400
X-Google-Sender-Auth: RL_O9uE_Sf6TXx06TmFz3sZlVLY
Message-ID: <CAOvdn6XXQe-vLWrNE9zSOQuo5K3H2jKBqXtFiPWEyHR1Z0N+CQ@mail.gmail.com>
From: Ben Guthro <ben@guthro.net>
To: Keir Fraser <keir.xen@gmail.com>
Cc: Lars Kurth <lars.kurth.xen@gmail.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Matt Wilson <msw@amazon.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [ANNOUNCE] Switching to git for primary Xen
	repositories
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============5141602956050049976=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============5141602956050049976==
Content-Type: multipart/alternative; boundary=14dae9340af34b51db04caf1ca36

--14dae9340af34b51db04caf1ca36
Content-Type: text/plain; charset=ISO-8859-1

+1 here.

Having the SCM system consistent with the other 2 projects intimately tied
with Xen (linux, and qemu) has definite advantages.

On Sat, Sep 29, 2012 at 1:54 AM, Keir Fraser <keir.xen@gmail.com> wrote:

> On 29/09/2012 06:04, "Matt Wilson" <msw@amazon.com> wrote:
>
> > On Fri, Sep 28, 2012 at 06:16:41PM +0100, Ian Jackson wrote:
> >> Keir writes:
> >>> Our plan therefore, with the 4.2.0 release soon out of the way, is
> >>> to switch to git for all of our primary repositories. We will plan
> >>> to mirror development activity into the old mercurial repositories
> >>> at least in the short term.
> >>
> >> So if we're having a vote on this, as discussed:
> >>
> >> +1
> >
> > Enthusiastic +1
>
> +1
>
> > Matt
>
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
>

--14dae9340af34b51db04caf1ca36
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

+1 here.<div><br></div><div>Having the SCM system consistent with the other=
 2 projects intimately tied with Xen (linux, and qemu) has definite advanta=
ges.<br><br><div class=3D"gmail_quote">On Sat, Sep 29, 2012 at 1:54 AM, Kei=
r Fraser <span dir=3D"ltr">&lt;<a href=3D"mailto:keir.xen@gmail.com" target=
=3D"_blank">keir.xen@gmail.com</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div class=3D"HOEnZb"><div class=3D"h5">On 2=
9/09/2012 06:04, &quot;Matt Wilson&quot; &lt;<a href=3D"mailto:msw@amazon.c=
om">msw@amazon.com</a>&gt; wrote:<br>

<br>
&gt; On Fri, Sep 28, 2012 at 06:16:41PM +0100, Ian Jackson wrote:<br>
&gt;&gt; Keir writes:<br>
&gt;&gt;&gt; Our plan therefore, with the 4.2.0 release soon out of the way=
, is<br>
&gt;&gt;&gt; to switch to git for all of our primary repositories. We will =
plan<br>
&gt;&gt;&gt; to mirror development activity into the old mercurial reposito=
ries<br>
&gt;&gt;&gt; at least in the short term.<br>
&gt;&gt;<br>
&gt;&gt; So if we&#39;re having a vote on this, as discussed:<br>
&gt;&gt;<br>
&gt;&gt; +1<br>
&gt;<br>
&gt; Enthusiastic +1<br>
<br>
+1<br>
<br>
&gt; Matt<br>
<br>
<br>
<br>
_______________________________________________<br>
Xen-devel mailing list<br>
<a href=3D"mailto:Xen-devel@lists.xen.org">Xen-devel@lists.xen.org</a><br>
<a href=3D"http://lists.xen.org/xen-devel" target=3D"_blank">http://lists.x=
en.org/xen-devel</a><br>
</div></div></blockquote></div><br></div>

--14dae9340af34b51db04caf1ca36--


--===============5141602956050049976==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============5141602956050049976==--


From xen-devel-bounces@lists.xen.org Sun Sep 30 21:16:08 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 30 Sep 2012 21:16:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xen.org>)
	id 1TIQrX-0004nG-Gc; Sun, 30 Sep 2012 21:15:43 +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 1TIQrV-0004n2-E7
	for xen-devel@lists.xen.org; Sun, 30 Sep 2012 21:15:41 +0000
Received: from [85.158.138.51:23067] by server-1.bemta-3.messagelabs.com id
	81/58-16425-C76B8605; Sun, 30 Sep 2012 21:15:40 +0000
X-Env-Sender: ben.guthro@gmail.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1349039737!30848209!1
X-Originating-IP: [209.85.223.173]
X-SpamReason: No, hits=0.9 required=7.0 tests=HTML_40_50,HTML_MESSAGE,
	RCVD_BY_IP
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6282 invoked from network); 30 Sep 2012 21:15:38 -0000
Received: from mail-ie0-f173.google.com (HELO mail-ie0-f173.google.com)
	(209.85.223.173)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Sep 2012 21:15:38 -0000
Received: by iea17 with SMTP id 17so13879072iea.32
	for <xen-devel@lists.xen.org>; Sun, 30 Sep 2012 14:15: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=r4cCoyh+TJuw40uiyckxIU/CHboQysKqyL2YCVMbm7I=;
	b=d0fladPJDl99/yCc0dGBswAvnnxd1PyiziNe7CJvlVY65lTddEci4PWKdJSaWBZt6u
	Ga6C78R79PtPwO2D6Hb86k2byMfGSxgqWPkMf77VxSe8jJEvSfyII4YSB/lELIYAr5xh
	fscEoK79NUpgtUYwxa/M88qC1QkpFvfgQ9yGjuLrGWHPf+OAVzZDwaNmwLFdcaVV0KIz
	wWLECugmnqH66jRhHaDfdIjNjH+X3IR1M5bQTN+Ns4xlYGplGgvg0+HpG85yJzZdBodN
	geNqZ4dLEDQNpFt5T6Bm7+A6+WyCu8JNHaZEyMgx7kyYljG5ZZ3tcnvhHenwLlGonAwI
	j5HQ==
MIME-Version: 1.0
Received: by 10.50.236.72 with SMTP id us8mr3940342igc.70.1349039736705; Sun,
	30 Sep 2012 14:15:36 -0700 (PDT)
Received: by 10.64.55.132 with HTTP; Sun, 30 Sep 2012 14:15:36 -0700 (PDT)
In-Reply-To: <CC8C4B9E.40283%keir.xen@gmail.com>
References: <20120929050455.GA21253@u002268147cd4502c336d.ant.amazon.com>
	<CC8C4B9E.40283%keir.xen@gmail.com>
Date: Sun, 30 Sep 2012 17:15:36 -0400
X-Google-Sender-Auth: RL_O9uE_Sf6TXx06TmFz3sZlVLY
Message-ID: <CAOvdn6XXQe-vLWrNE9zSOQuo5K3H2jKBqXtFiPWEyHR1Z0N+CQ@mail.gmail.com>
From: Ben Guthro <ben@guthro.net>
To: Keir Fraser <keir.xen@gmail.com>
Cc: Lars Kurth <lars.kurth.xen@gmail.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Matt Wilson <msw@amazon.com>, xen-devel@lists.xen.org
Subject: Re: [Xen-devel] [ANNOUNCE] Switching to git for primary Xen
	repositories
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============5141602956050049976=="
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

--===============5141602956050049976==
Content-Type: multipart/alternative; boundary=14dae9340af34b51db04caf1ca36

--14dae9340af34b51db04caf1ca36
Content-Type: text/plain; charset=ISO-8859-1

+1 here.

Having the SCM system consistent with the other 2 projects intimately tied
with Xen (linux, and qemu) has definite advantages.

On Sat, Sep 29, 2012 at 1:54 AM, Keir Fraser <keir.xen@gmail.com> wrote:

> On 29/09/2012 06:04, "Matt Wilson" <msw@amazon.com> wrote:
>
> > On Fri, Sep 28, 2012 at 06:16:41PM +0100, Ian Jackson wrote:
> >> Keir writes:
> >>> Our plan therefore, with the 4.2.0 release soon out of the way, is
> >>> to switch to git for all of our primary repositories. We will plan
> >>> to mirror development activity into the old mercurial repositories
> >>> at least in the short term.
> >>
> >> So if we're having a vote on this, as discussed:
> >>
> >> +1
> >
> > Enthusiastic +1
>
> +1
>
> > Matt
>
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
>

--14dae9340af34b51db04caf1ca36
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

+1 here.<div><br></div><div>Having the SCM system consistent with the other=
 2 projects intimately tied with Xen (linux, and qemu) has definite advanta=
ges.<br><br><div class=3D"gmail_quote">On Sat, Sep 29, 2012 at 1:54 AM, Kei=
r Fraser <span dir=3D"ltr">&lt;<a href=3D"mailto:keir.xen@gmail.com" target=
=3D"_blank">keir.xen@gmail.com</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div class=3D"HOEnZb"><div class=3D"h5">On 2=
9/09/2012 06:04, &quot;Matt Wilson&quot; &lt;<a href=3D"mailto:msw@amazon.c=
om">msw@amazon.com</a>&gt; wrote:<br>

<br>
&gt; On Fri, Sep 28, 2012 at 06:16:41PM +0100, Ian Jackson wrote:<br>
&gt;&gt; Keir writes:<br>
&gt;&gt;&gt; Our plan therefore, with the 4.2.0 release soon out of the way=
, is<br>
&gt;&gt;&gt; to switch to git for all of our primary repositories. We will =
plan<br>
&gt;&gt;&gt; to mirror development activity into the old mercurial reposito=
ries<br>
&gt;&gt;&gt; at least in the short term.<br>
&gt;&gt;<br>
&gt;&gt; So if we&#39;re having a vote on this, as discussed:<br>
&gt;&gt;<br>
&gt;&gt; +1<br>
&gt;<br>
&gt; Enthusiastic +1<br>
<br>
+1<br>
<br>
&gt; Matt<br>
<br>
<br>
<br>
_______________________________________________<br>
Xen-devel mailing list<br>
<a href=3D"mailto:Xen-devel@lists.xen.org">Xen-devel@lists.xen.org</a><br>
<a href=3D"http://lists.xen.org/xen-devel" target=3D"_blank">http://lists.x=
en.org/xen-devel</a><br>
</div></div></blockquote></div><br></div>

--14dae9340af34b51db04caf1ca36--


--===============5141602956050049976==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

--===============5141602956050049976==--


From xen-devel-bounces@lists.xen.org Sun Sep 30 21:24:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 30 Sep 2012 21:24: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 1TIQzQ-0005AD-L9; Sun, 30 Sep 2012 21:23:52 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mrsanna1@gmail.com>)
	id 1TIPz8-0003Z5-60; Sun, 30 Sep 2012 20:19:30 +0000
X-Env-Sender: mrsanna1@gmail.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1349036362!3621780!1
X-Originating-IP: [209.85.220.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12868 invoked from network); 30 Sep 2012 20:19:24 -0000
Received: from mail-vc0-f171.google.com (HELO mail-vc0-f171.google.com)
	(209.85.220.171)
	by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Sep 2012 20:19:24 -0000
Received: by vcmm18 with SMTP id m18so6296425vcm.30
	for <multiple recipients>; Sun, 30 Sep 2012 13:19:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type:content-transfer-encoding;
	bh=k80c23drYPmwBIfSbIkRjgxIW66HCVjzI/F9pIYGq50=;
	b=Wr+bt7z1LnUsSNJO7WkIbvGclf+xa/NiKPBg6bkUwH/S+N5dIH5BPBsIMvUE8YGPyt
	M40+T8Y3J2huKYakByP/SnuOkflaK+dNEAq1grwnCj03Cf0kHOQFpEcsMuszDZQvmap9
	eH/cQBCOKNzZ8VJzybD9GtKfuq1XpAQ8K5vX4tF+VeB8qd4SbbywRUpeUeaRMlfcUjmb
	C1UqzV/EJU4A5eL0BhlMJ8EtW+pUmuQmxuAlCN49e5LVf0Me4qHB63ECYOo1VCbNfF9R
	BGY3t8dJoqh78SK7oAgMm11aUgKFS6RdCE/ilcZX4RBWbPlkk1ICEVXilqE3mf/ZnRNR
	ut+A==
MIME-Version: 1.0
Received: by 10.52.93.238 with SMTP id cx14mr337653vdb.42.1349036362646; Sun,
	30 Sep 2012 13:19:22 -0700 (PDT)
Received: by 10.58.207.75 with HTTP; Sun, 30 Sep 2012 13:19:22 -0700 (PDT)
In-Reply-To: <CAE17a0WWvpwW-V5hQOgL1CiuVZFKyzhZVZfTVq74ZsJUo1SE8w@mail.gmail.com>
References: <AANLkTikptc2POrKQgJuoVZRdwJTo64DJ_hm12KuPky4D@mail.gmail.com>
	<b1ca6ddc-ca69-447e-93e9-8d36d1ff4a43@default>
	<AANLkTinK94GDOF_GeaVs50wK0u8EdZ2rtzPuh65ca8qR@mail.gmail.com>
	<CAE17a0UPyzsNn=ps9MxarkGg=ns8dCpVz0qBDvesT2AOskwfVg@mail.gmail.com>
	<65395f62-74e5-4910-b701-8df629c2ce3b@default>
	<CABx4GKrQxOOQo_uUXSFvy0nzdMp1A_qc=_e4K+88GkB7xv=9nw@mail.gmail.com>
	<CAE17a0VkMuUEG9VaM7AFrwcsEjVBq9RfvTWz1_KmscAyCxeAbA@mail.gmail.com>
	<CABx4GKqrTEV7CEnAVUfYr-+yky8N5P1U29xDbrESH-mHB0iZhQ@mail.gmail.com>
	<CAE17a0UYwqLxoZaVDgQCvUR2KQK4vvP3bkvsdrwgnsUp33xuNQ@mail.gmail.com>
	<CAE17a0UQocJjZc38c2805uYvdwR7e447UGH9ywcxMw1Ge3imfg@mail.gmail.com>
	<20120930151314.GU8912@reaktio.net>
	<CAE17a0WWvpwW-V5hQOgL1CiuVZFKyzhZVZfTVq74ZsJUo1SE8w@mail.gmail.com>
Date: Sun, 30 Sep 2012 22:19:22 +0200
Message-ID: <CAE17a0WvLyduj4V68qPJRLcjc5V7xZ=iTNprKWJyGAX_6RXC+Q@mail.gmail.com>
From: Mauro <mrsanna1@gmail.com>
To: =?UTF-8?B?UGFzaSBLw6Rya2vDpGluZW4=?= <pasik@iki.fi>
X-Mailman-Approved-At: Sun, 30 Sep 2012 21:23:52 +0000
Cc: Dan Magenheimer <dan.magenheimer@oracle.com>, xen-devel@lists.xensource.com,
	Keir Fraser <keir@xen.org>, Jeremy Fitzhardinge <jeremy@goop.org>,
	Olivier Hanesse <olivier.hanesse@gmail.com>,
	Keir Fraser <keir.xen@gmail.com>,
	Xen Users <xen-users@lists.xensource.com>,
	Mark Adams <mark@campbell-lange.net>
Subject: Re: [Xen-devel] [Xen-users] Re: Xen 4 TSC problems
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gMzAgU2VwdGVtYmVyIDIwMTIgMjE6MjMsIE1hdXJvIDxtcnNhbm5hMUBnbWFpbC5jb20+IHdy
b3RlOgo+IE9uIDMwIFNlcHRlbWJlciAyMDEyIDE3OjEzLCBQYXNpIEvDpHJra8OkaW5lbiA8cGFz
aWtAaWtpLmZpPiB3cm90ZToKPj4gT24gU2F0LCBTZXAgMjksIDIwMTIgYXQgMDI6MTk6NTVQTSAr
MDIwMCwgTWF1cm8gd3JvdGU6Cj4+PiBJdCdzIGhhcHBlbmVkIGFub3RoZXIgdGltZSwgc3lzdGVt
IGRhdGUgNTAgbWludXRlcyBhaGVhZC4KPj4+IFRoZXJlIGlzIHJlYWxseSBubyBzb2x1dGlvbj8K
Pj4+Cj4+Cj4+IFRyeSB3aXRoIGEgcmVjZW50IFhlbiBoeXBlcnZpc29yIHZlcnNpb24uIFhlbiA0
LjEuMyBvciA0LjIuMC4KPj4gSXQgaGVscHMgYSBsb3QgdG8ga25vdyBpZiB0aGUgaXNzdWUgaXMg
c3RpbGwgaW4gdGhlIGxhdGVzdCBoeXBlcnZpc29yIHZlcnNpb25zIG9yIG5vdC4KClRoZXJlIGlz
IHNvbWVvbmUgdGhhdCBoYWQgdGhlIHByb2JsZW0gYW5kIHNvbHZlZCB1c2luZyBhIHJlY2VudCB4
ZW4gaHlwZXJ2aXNvcj8KCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbi5vcmcKaHR0
cDovL2xpc3RzLnhlbi5vcmcveGVuLWRldmVsCg==

From xen-devel-bounces@lists.xen.org Sun Sep 30 21:24:15 2012
Return-path: <xen-devel-bounces@lists.xen.org>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 30 Sep 2012 21:24: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 1TIQzQ-0005AD-L9; Sun, 30 Sep 2012 21:23:52 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mrsanna1@gmail.com>)
	id 1TIPz8-0003Z5-60; Sun, 30 Sep 2012 20:19:30 +0000
X-Env-Sender: mrsanna1@gmail.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1349036362!3621780!1
X-Originating-IP: [209.85.220.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Received: 
X-StarScan-Version: 6.6.1.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12868 invoked from network); 30 Sep 2012 20:19:24 -0000
Received: from mail-vc0-f171.google.com (HELO mail-vc0-f171.google.com)
	(209.85.220.171)
	by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Sep 2012 20:19:24 -0000
Received: by vcmm18 with SMTP id m18so6296425vcm.30
	for <multiple recipients>; Sun, 30 Sep 2012 13:19:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type:content-transfer-encoding;
	bh=k80c23drYPmwBIfSbIkRjgxIW66HCVjzI/F9pIYGq50=;
	b=Wr+bt7z1LnUsSNJO7WkIbvGclf+xa/NiKPBg6bkUwH/S+N5dIH5BPBsIMvUE8YGPyt
	M40+T8Y3J2huKYakByP/SnuOkflaK+dNEAq1grwnCj03Cf0kHOQFpEcsMuszDZQvmap9
	eH/cQBCOKNzZ8VJzybD9GtKfuq1XpAQ8K5vX4tF+VeB8qd4SbbywRUpeUeaRMlfcUjmb
	C1UqzV/EJU4A5eL0BhlMJ8EtW+pUmuQmxuAlCN49e5LVf0Me4qHB63ECYOo1VCbNfF9R
	BGY3t8dJoqh78SK7oAgMm11aUgKFS6RdCE/ilcZX4RBWbPlkk1ICEVXilqE3mf/ZnRNR
	ut+A==
MIME-Version: 1.0
Received: by 10.52.93.238 with SMTP id cx14mr337653vdb.42.1349036362646; Sun,
	30 Sep 2012 13:19:22 -0700 (PDT)
Received: by 10.58.207.75 with HTTP; Sun, 30 Sep 2012 13:19:22 -0700 (PDT)
In-Reply-To: <CAE17a0WWvpwW-V5hQOgL1CiuVZFKyzhZVZfTVq74ZsJUo1SE8w@mail.gmail.com>
References: <AANLkTikptc2POrKQgJuoVZRdwJTo64DJ_hm12KuPky4D@mail.gmail.com>
	<b1ca6ddc-ca69-447e-93e9-8d36d1ff4a43@default>
	<AANLkTinK94GDOF_GeaVs50wK0u8EdZ2rtzPuh65ca8qR@mail.gmail.com>
	<CAE17a0UPyzsNn=ps9MxarkGg=ns8dCpVz0qBDvesT2AOskwfVg@mail.gmail.com>
	<65395f62-74e5-4910-b701-8df629c2ce3b@default>
	<CABx4GKrQxOOQo_uUXSFvy0nzdMp1A_qc=_e4K+88GkB7xv=9nw@mail.gmail.com>
	<CAE17a0VkMuUEG9VaM7AFrwcsEjVBq9RfvTWz1_KmscAyCxeAbA@mail.gmail.com>
	<CABx4GKqrTEV7CEnAVUfYr-+yky8N5P1U29xDbrESH-mHB0iZhQ@mail.gmail.com>
	<CAE17a0UYwqLxoZaVDgQCvUR2KQK4vvP3bkvsdrwgnsUp33xuNQ@mail.gmail.com>
	<CAE17a0UQocJjZc38c2805uYvdwR7e447UGH9ywcxMw1Ge3imfg@mail.gmail.com>
	<20120930151314.GU8912@reaktio.net>
	<CAE17a0WWvpwW-V5hQOgL1CiuVZFKyzhZVZfTVq74ZsJUo1SE8w@mail.gmail.com>
Date: Sun, 30 Sep 2012 22:19:22 +0200
Message-ID: <CAE17a0WvLyduj4V68qPJRLcjc5V7xZ=iTNprKWJyGAX_6RXC+Q@mail.gmail.com>
From: Mauro <mrsanna1@gmail.com>
To: =?UTF-8?B?UGFzaSBLw6Rya2vDpGluZW4=?= <pasik@iki.fi>
X-Mailman-Approved-At: Sun, 30 Sep 2012 21:23:52 +0000
Cc: Dan Magenheimer <dan.magenheimer@oracle.com>, xen-devel@lists.xensource.com,
	Keir Fraser <keir@xen.org>, Jeremy Fitzhardinge <jeremy@goop.org>,
	Olivier Hanesse <olivier.hanesse@gmail.com>,
	Keir Fraser <keir.xen@gmail.com>,
	Xen Users <xen-users@lists.xensource.com>,
	Mark Adams <mark@campbell-lange.net>
Subject: Re: [Xen-devel] [Xen-users] Re: Xen 4 TSC problems
X-BeenThere: xen-devel@lists.xen.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org

T24gMzAgU2VwdGVtYmVyIDIwMTIgMjE6MjMsIE1hdXJvIDxtcnNhbm5hMUBnbWFpbC5jb20+IHdy
b3RlOgo+IE9uIDMwIFNlcHRlbWJlciAyMDEyIDE3OjEzLCBQYXNpIEvDpHJra8OkaW5lbiA8cGFz
aWtAaWtpLmZpPiB3cm90ZToKPj4gT24gU2F0LCBTZXAgMjksIDIwMTIgYXQgMDI6MTk6NTVQTSAr
MDIwMCwgTWF1cm8gd3JvdGU6Cj4+PiBJdCdzIGhhcHBlbmVkIGFub3RoZXIgdGltZSwgc3lzdGVt
IGRhdGUgNTAgbWludXRlcyBhaGVhZC4KPj4+IFRoZXJlIGlzIHJlYWxseSBubyBzb2x1dGlvbj8K
Pj4+Cj4+Cj4+IFRyeSB3aXRoIGEgcmVjZW50IFhlbiBoeXBlcnZpc29yIHZlcnNpb24uIFhlbiA0
LjEuMyBvciA0LjIuMC4KPj4gSXQgaGVscHMgYSBsb3QgdG8ga25vdyBpZiB0aGUgaXNzdWUgaXMg
c3RpbGwgaW4gdGhlIGxhdGVzdCBoeXBlcnZpc29yIHZlcnNpb25zIG9yIG5vdC4KClRoZXJlIGlz
IHNvbWVvbmUgdGhhdCBoYWQgdGhlIHByb2JsZW0gYW5kIHNvbHZlZCB1c2luZyBhIHJlY2VudCB4
ZW4gaHlwZXJ2aXNvcj8KCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbi5vcmcKaHR0
cDovL2xpc3RzLnhlbi5vcmcveGVuLWRldmVsCg==